KOMMENTARSKABELON. Vi har delt vores kommentarer til høringsudgaven af Metode og struktur for informationsniveauer

Transkript

1 KOMMENTARSKABELON Dato Dokument Høring: Metode og struktur for informationsniveauer Udfyldt af: Navn på med er afsnit til hver af de fremførte er Den informationsmængde, der flyder rundt mellem aktørerne i relation til bygninger og anlægs livscyklus er meget stor og relativt ustruktureret. I praksis er den standardiseret på et lavt niveau. Det kan derfor ikke undre, at aftaler knyttet til levering af information ofte er upræcise manglende. Denne informationsmængde er i sin helhed relativt dårligt forstået, og dårligt kortlagt. Indenfor visse områder er der de senere år sket fremskridt, men vi har ikke et samlet, anerkendt overblik over byggeriets informationsmængde og af de problemer, som byggeriets aktører har i omgangen med den. Vi hilser derfor denne metode til præcisering af information velkommen. Vi kan se en række udfordringer i at bringe metoden frem til at få den ønskede effekt, men vi har forhåbninger om, at det kan ske. Vi har delt vores er til høringsudgaven af Metode og struktur for informationsniveauer i følgende emner: Informationsniveaumetoden/-strukturen indhold og anvendelse Informationsniveaumetoden/-strukturen kompleksitet Informationsniveaumetoden/-strukturen international orientering Udviklingsmetode, grundlæggende teori Gyldighedsområdet Sammenhæng med andre standarder, andre cuneco-projekter, andre organisationer IKT-understøttelse Andet

2 med er afsnit til hver af de fremførte er Informationsniveaumetoden/-strukturen indhold og anvendelse For at kunne bruges som grundlag for at anvende informationsniveauer i praksis skal et være mere specifikt. Der skal være deciderede arbejdsmetoder med beskrivelser punkt for punkt. Vi skal kunne bruge det som en manual for niveau bestemmelse. Ellers får et karakter af en hensigtserklæring. Afsnit 4 Det er uklart, hvorfor der netop er valgt at tage udgangspunkt i 6 definitioner på informationsniveauer, når man ikke, som i de tidligere informationsniveauer efter 3D arbejdsmetode, har forholdt sig til byggeriets faser. Er der lavet en decideret overvejelse af antallet af optimale informationsniveauer, er antallet 6 valgt på baggrund af tidligere opdeling? Overvej om man kan bruge færre niveauer. Typisk, i dag, bliver kun 2/4 brugt. Niveau 1 er typisk ikke brugbart for nogen parter. Se også under Informationsniveaumetoden/-strukturen international orientering nedenfor. Afsnit 4 Informationsniveauer indeholder detaljeringsgrad per bygningsdel. Bliver der lavet en liste af informationer indeholdt på hvert informationsniveau per bygningsdelstype? Definer liste af bygningsdelstyper som cuneco laver detaljeringsniveau-liste for. Afsnit 4 Tabel 1 Teknisk Der er et stort spring i detaljeringsgrad mht. materialevalg. Der burde være et detaljeringsniveau, der placerings bestemmer søjle, men ikke definerer materiale type. Afsnit 4 Tabel 1 Er det tanken, at der for hver bygningsdel, til ethvert informationsniveau er en beskrivelse af detaljeringsniveauet? I eksemplet i tabel 1 er søjlens geometriske detaljering vist, men ikke beskrevet med ord. Eller er det tanken, at formegenskaben definerer dette? Afsnit 4 Tabel 2 Teknisk På niveau 5 er bolte angivet som en del af søjleobjektet er det rigtigt? Hvad med endepladen? Hvor stopper objektet i forhold til informationsniveauer? Side 17 Teknisk Det ville hjælpe på forståelsen, hvis der tydeligt stod, at eksempel-listen over informationsniveaukoder gælder for bygningsdele, for rum for begge disse klasser. Den gælder formentlig ikke for processer. Overvej opdelingen og beskrivelsen Se Kommentar-feltet. 2

3 med er afsnit Side 17 Teknisk Begrebet informationsniveau angiver tilsyneladende primært, hvilken information (omfang, konkretiserings- og detaljeringsniveau), der skal være til stede. til hver af de fremførte er Tag gerne stilling i metoden. Kan man bruge informationsniveau-begrebet til at beskrive præcist, hvad modtager må anvende informationen til? Kan man f.eks. for objekter i en 3D-model fortælle at informationen må anvendes til orientering, til mængdeopgørelse, til at bygge efter, osv.? Side 17 Teknisk Metoden angiver så vidt vi kan se ikke nogen kriterier for opdeling i egenskabsdatasæt. Hvis egenskabsdatasættene kun anvendes i forbindelse med informationsniveauer, bør der i denne rapport angives kriterier for opdeling i datasæt. Hvis de samme egenskabsdatasæt anvendes mere generelt bør kriterierne fastlægges i en anden relevant standard/metode. Kriterierne bør næppe overlades til de cuneco-projekter, der definerer egenskabsdatasættene. Afsnit 4.2 Side 18 Mht. successiv fastlæggelse af informationsniveau behov: Kan man ikke forstille sig en situation, hvor der er detaljekrav til bygningsdel, og informationsniveau udledes af detaljekrav? Afsnit 4.2 Hvordan kodes en bygningsdel, hvis der alene ønskes en geometrisk detaljering til eksempelvis niveau 4? Afsnit 4.3 Side 18 Fint at introducere views. Fint med definitionen på et view. Afsnit 4.3 Figur 5 Figuren/pile burde vendes, så det bliver mere tydeligt, at man opsætter et filter på en mængde data og får et view som resultat, der er en delmængde af informationen. Side 19, figur 6 Teknisk Måske kan dette uddybes: Der introduceres en ny klasse i resultatdomænet, Bygning. Som også har egenskaber egenskabsdatasæt, informationsniveauer, Kort beskrivelse af, at det kan være nødvendigt, og hensigtsmæssigt, i visse tilfælde at gøre det omvendt. Vend figur om, lav bedre flow. Se Kommentar-feltet 3

4 med er afsnit Side 19, 20 Teknisk Afsnit 4.5 Teknisk Figur 9 side 21 Teknisk Måske kan dette beskrives lidt klarere: til hver af de fremførte er Der knyttes informationsniveauer til views. Der er, så vidt vi kan se, tale om et selvstændigt view-informationsniveau. Viewet kræver bestemte informationsniveauer af de egenskabsdata/-sæt, der indgår i viewet. Men det er ikke nødvendigvis samme informationsniveau, som er tilknyttet viewet. Jf. denne sætning på side 20: Koderne i skemaet er tidligere forklaret i afsnit 4.2. F.eks. betyder B Væg-system på informationsniveau A2 B3, at Funktionskrav specificere på informationsniveau 2, og informationer i resultatområdet (B) på informationsniveau 3. Hvis det er rigtigt, er figur 8 lidt misvisende, om end ikke forkert. Her er der sammenfald mellem viewets og egenskabsdatasættenes informationsniveauer. Det virker urealistisk at håndtere projektspecifikke afvigelser med bogstaver. Hvad er betydningen af CACD3a? Er det tilladt at fjerne egenskaber kun at tilføje? Med andre ord er værktøjet optimeret mod dataskabelse dataforbrug? Små bogstaver bruges muligvis til to ting: At definere officielle underinddelinger alternative informationsniveaudefinitioner (dvs. som en del af standarden for informationsniveauer). At definere projektspecifikke udgaver af informationsniveauer. Beskriv gerne tydeligt, at views har eget informationsniveau, der ikke er det samme som informationsniveauerne for de indgående egenskabsdata/-sæt. Selvom der selvfølgelig etableres en sammenhæng gennem viewet. Hvis dette altså er rigtigt. Ellers skriv gerne tydeligt, at informationsniveauet for viewet og de indgående egenskabsdata/-sæt skal være de samme. Overvej fjernelse af brugerspecifikke afvigelse og anvis alternativ metode for dette, hvor niveauet defineres eksplicit gennem afkrydsningsskemaer (brugere skal alligevel slå op for at forstå, hvad der menes). Hvis det er rigtigt forstået, er denne sammenblanding uheldig. Se også en ovf. Afsnit 5 side 22 Teknisk Vedr. de seks trin nederst på siden: Det ville være hensigtsmæssigt at vise et eksempel på anvendelse af de seks trin. Afsnit 5.2 Er det tanken, at der udarbejdes paradigmer lign., således at man i en overgangsperiode eksempelvis kan forholde sig til, hvad der almindeligvis er indeholdt i et traditionelt hovedprojekt? Vis gerne et kort eksempel. 4

5 med er afsnit til hver af de fremførte er Informationsniveaumetoden/-strukturen kompleksitet Vi finder høringsrapporten relativt velskrevet og gennemarbejdet og et stykke hen ad vejen pædagogisk og forståelig. Men vi finder metoden og strukturen kompleks. Det skyldes to forhold: Begrebet informationsniveau er en abstrakt størrelse, som vi tror, skal tilfredsstille en række forskellige behov, der endnu ikke er fuldt eret. Vi frygter at kompleksiteten eksploderer, hvis man ikke passer på og at vi ender med så mange versioner af informationsniveauer, at vi rent faktisk er bedre stillet uden. Der er tilstræbt stor fleksibilitet i metode og struktur, og med fleksibilitetskravet følger yderligere kompleksitet. Der er områder, hvor vi simpelthen ikke har kunnet opnå den fornødne forståelse. Nogle af disse er udpeget nedenfor. Side 17 Teknisk Vedr. koderegeleksemplerne nederst på siden. Der står: Tilsvarende angiver BA3 B2, at produktegenskaber specificeres på informationsniveau 3 og de øvrige placering-, form-, og grænsefladeegenskaber i resultatområdet på informationsniveau 2. Det virker skræmmende. Det kan resultere i meget lange koder. Og koderne får variabel længde. Så vidt vi kan se, er denne kode (i hvert fald teoretisk) en mulighed (ud fra eksempellisten på side 17): CBAA1 CBAB1 CBAC1 CBAD1 CBA2 CB3 C2. Nogle er: Koder af denne kompleksitet er umenneskelige. Også selvom de generelt ikke bliver så komplekse som ovst. kodeeksempel. En gang imellem bliver de komplekse. Man skal desuden tilføje den rumlige dimension. Bygningsdele (og rum) af forskellig type kan på et givet tidspunkt være på forskellige informationsniveauer (indenfor en given egenskabsdatagruppe), jf. figur 3, side 9. Der er h ingen, der siger, at alle bygningsdele af samme type nødvendigvis skal have ( har) samme informationsniveau (indenfor en given egenskabsdatagruppe). Dvs. på et givet tidspunkt kan informationsniveauet variere f.eks. med bygningsdelstype og måske med etage, afsnit, rådgiver, Kompleksiteten har store konsekvenser for metodens og strukturens muligheder for IKT-understøttelse i praksis, se er under IKT-understøttelse nedenfor. 5

6 med er afsnit Side 17 Teknisk Tilføjelse til ovst. : til hver af de fremførte er Der er muligvis tale om en hierarkisk struktur med en slags nedarvning. Dvs. hvis der for et given egenskabsdatasæt ikke er specificeret et informationsniveau, anvendes informationsniveauet fra det nærmest overliggende egenskabsdatasæt/område. Disse regler skal specificeres præcist som en del af standarden (metoden/strukturen). Ellers vil de blive implementeret forskelligt i forskellige IT-systemer, projekter, organisationer Side 17 Teknisk Tilføjelse til tilføjelsen ovf.: Kan en egenskab tilhøre mere end ét egenskabsdatasæt. Kan f.eks. egenskaben købspris pr. stk. ex. moms både ligge i AA: Økonomi og i CC: Pris? Hvis ja: Konsekvensen er, at en egenskab kan have mere end ét informationsniveau på et givet tidspunkt, fordi der er mere end én nedarvningsvej. Det øger kompleksiteten. Man skal have en regel til at håndtere det, f.eks. at man vælger det højeste informationsniveau. Figur 4 på side 16 synes at indikere, at egenskabsdatagrupper kan overlappe indenfor et område, men ikke på tværs af områder. Men det er måske en overfortolkning af figuren? Hvis nej: Egenskabsdatasættene kan af og til få et utilstrækkeligt præg. Egenskabsdatasættene ser ud fra eksempellisten på side 17 i en vis udstrækning ud til at være formålsbestemt. Man kunne forestille sig forskellige formål overlapper mht. hvilke egenskaber, der understøtter formålene. Det kan føre til, at man må udelade naturligt hjemmehørende egenskaber fra et sæt, fordi det er valgt at placere dem i andre sæt. Det første sæt kan hermed ikke leve op til sit formål, f.eks. at understøtte brandsimulering. Iflg. denne sætning fra side 19 er Nej tilsyneladende valgt: hvorimod egenskabsdatasæt ikke kan være indeholdt i hinanden, og således indeholder klart adskilte egenskabsdata. Eller har vi misforstået dette? Problemstillingen kunne retfærdiggøre en præciserende beskrivelse. Metoden skal definere reglerne, ikke det senere cunecoprojekt, der fastlægger og koder de konkrete egenskabsdatasæt. Figur 13 & 14 side 25 Teknisk Her introduceres endnu et hierarki, bygningsdelshierarkiet (i tillæg til egenskabsdatasæt hierarkiet eksemplificeret på side 17). Dvs. man skal tolke to hierarkier (egenskabsdatasæt- og bygningsdelshierarkiet) for eksempel for at afklare om (og i hvilket omfang) en given egenskab for en given bygningsdel skal tildeles en værdi på et givet tidspunkt (hvis den altså er dækket af en informationsniveaukode på det givne tidspunkt det er alle egenskaber formentlig Se Kommentar-feltet. 6

7 med er afsnit til hver af de fremførte er ikke). Det fore os komplekst. Vi kan ikke gennemskue den generelle problemstilling. Ej h den praktiske, når man sidder ved skærmen og tilvejebringer egenskabsdata for bygningsdele. Et par er: Der er risiko for, at også en del andre vil finde det svært at gennemskue måske bortset fra ganske simple anvendelser af metoden. Det stiller krav til formidling, uddannelse, og IKT-understøttelse er et vigtigt middel til at få dette til at virke i praksis. Vha. IT kan man f.eks. støtte arkitekten i at registrere de egenskaber, der kræves, og man kan hjælpe entreprenøren med at validere, at de enkelte egenskaber er til stede på de enkelte bygningsdele, rum på det aftalte niveau. Det forudsætter, at man kan tilvejebringe IT-understøttelsen i og omkring de systemer, der er udbredt i branchen. Jf. nedenfor under IKT-understøttelse. Informationsniveaumetoden/-strukturen international orientering t Der er ikke eret et krav om, at metoden/strukturen for informationsniveauer skal være anvendelig i en international sammenhæng. Udeladelse af et sådant krav ser vi som en alvorlig mangel. Det er ikke nok, at hente inspiration i udenlandske og internationale standarder, metoder mv. som Bilag A Udviklingsmetode foreskriver. Det afgørende er i hvilken udstrækning den udviklede metode er kompatibel med tilsvarende udenlandske og internationale standarder. Det ser ikke ud til at være tilstræbt. Dokumenter hvilke krav der er til internationalisering. Afklar i hvilken grad kravene opfyldes af den udviklede metode/struktur. Det er ikke hensigtsmæssigt at anvende 6 forskellige informationsniveauer, når internationale standarder beskriver 5 informationsniveauer. Det gør det svært at bruge metoden i samarbejdet med internationale virksomheder. Der er tale om en meget teoretisk og uoverskuelig metode og struktur for informationsniveauer, hvor der er behov for en forklaring af nødvendigheden af de forskellige koder og hvem, der skal bruge dem. I første omgang kunne man opstille en light udgave med f.eks. informationsniveau (f.eks. ). Statsbygg har tidligere arbejdet med lister over informationsniveauer/egenskabsdata (se Statsbygg BIM manual version 1.0) men er tilsyneladende gået væk fra dette i seneste version (Statsbygg BIM manual version 1.2). Der er udarbejdet udførlige lister over indhold i LOD100 LOD500 som bør anvendes som inspiration i det videre arbejde for at sikre den internationale vinkel og bygge videre på allerede gennemført arbejde. Eksempel: MGuide/ -> References -> Object Element Matrix File Erfaringerne fra Norge bør inddrages i arbejdet, hvis det ikke allerede er sket. 7

8 med er afsnit til hver af de fremførte er Det er vigtigt at indhente er til metoden/strukturen fra relevante interessenter i andre lande. Desuden skal metoden/strukturen, når den er færdigudviklet, kunne anvendes af byggevirksomheder i udlandet. Endelig skal udenlandske IT-producenter have et udviklingsgrundlag for at kunne tilføre nødvendig IKT-understøttelse for metoden/strukturen (se nedenfor under IKTunderstøttelse ). Materialet bør som minimum oversættes til engelsk i forbindelse med høringen i stil med hvad vi har set hos Statsbygg i Norge. Udviklingsmetode, grundlæggende teori (Se også om Gyldighedsområde nedenfor) Bilag A Stor ros for, at I erer den metode, I har fulgt da I udviklede informationsniveaumetoden/-strukturen. Der har måske som oplæg til udviklingsprojektet for informationsniveauer været opgivet nogle mål, krav o.l. Hvis det er tilfældet, er det hensigtsmæssigt, at sådanne mål, krav mm. også eres. Metoden beskrives delvis vha. et eksempel. Samtidig virker det som om, eksemplet faktisk udgør anvendelsen af metoden til udvikling af den konkrete Metode og struktur for informationsniveauer. To er: 1) Hvis eksemplet skal opfattes som metoden anvendt til det konkrete formål, at udvikle en informationsniveaumetode til byggebranchen, bør den fremtræde sådan. Man bør fortælle, hvordan man reelt har anvendt metoden. Ikke som et eksempel. 2) Hvis eksemplet blot skal opfattes som eksempel, savner man beskrivelse af hvordan vigtige udviklingsmæssige beslutninger er taget. F.eks. Hvordan er man nået frem til, at netop de valgte klasser er de mest fornuftige at bruge informationsniveauer på? Hvordan er graden af internationalisering valgt? Og hvad er den valgte grad af internationalisering i øvrigt? Dvs. spørgsmål som: Hvilke internationale/udenlandske standarder/metoder findes på området og hvor relevante er de? Hvilke internationale/udenlandske standarder/metoder overholder CCS Informationsniveaumetoden? I hvilken udstrækning kan CCS Informationsniveauer/metoden bruges i udlandet? I hvilket grad kan tilsvarende udenlandske/internationale standarder/metoder 8

9 med er afsnit til hver af de fremførte er bruges sammen med CCS Informationsniveauer? Man savner i høj grad, at arbejdet funderes på en verdensopfattelse/- teoridannelser/begrebsapparat, som er fælles og beskrevet for alle cuneco og bips standarder. DBK 2006 har sin begrebsmodel og begrebskatalog (begge dele trænger til opdatering). ISO standarderne har sin verdensopfattelse. buildingsmart sin. Man bekender sig ofte i cuneco s arbejde til en form for objektorienteret analyse/design mm., som er en del af cuneco s verdensopfattelse. Men hver ny standard/metode, som cuneco fremstiller, med sin egen mere mindre dækkende beskrivelse af sit teorigrundlag, sine begreber osv. Det ville have store fordele, hvis man kunne sige: I denne standard beskæftiger vi os med det og det indenfor vores fælles cuneco-verdensbillede, vi anvender disse begreber indenfor det fælles begrebsapparat osv. Den faglige kvalitet ville stige, den enkelte standard kunne udvikles og opdateres hurtigere, og læserne ville få en gennemgående forståelsesramme. Indfør perspektiverende afsnit, der viser sammenhængen mellem begreberne og sandsynliggør at informationsniveauer vil komplettere de eksisterende systemer og kunne anvendes i sammenhæng med disse f.eks. kan informationsniveauer anvendes til at specificere modelviews og deliverables i IDM. Det er desuden essentielt, at der opnås synergi mellem buildingsmart værktøjer og informationsniveauer, så f.eks. værktøjer til kontrol af mod i forhold til MVD ligeledes kan anvendes med informationsniveauer. Figur 3, side 9 Der synes at være en slags implicit antagelse om, at hver projektfase afsluttes med en dominerende informationsaflevering. Det er nok ofte rigtigt (måske med undtagelse af D&V/forvaltningsfasen), men det vil jo afhænge af den konkrete faseopdeling i byggeprojektet. Den afsluttende informationsaflevering er imidlertid langt fra den eneste relevante informationsoverdragelse i en fase. Der overføres mange betydningsfulde informationspakker hen igennem de fleste faser, og informationen i disse informationspakker er ikke nødvendigvis på fasens afslutningsniveau. Eksempler: Rådgivere, der udveksler fagmod for at udføre tværgående kollisionskontrol, kan starte med lavere informationsniveauer, end de slutter med i projekteringsfasen. En hovedentreprenør, der anmoder om underhåndtilbud/overslag har muligvis lavere informationsniveauer til rådighed, end når han anmoder om endelige tilbud fra sine fagentreprenører. Den indkøbsplanlægning, der finder sted i tilbudsfasen, kan starte på et lavt niveau for materialer og materiel for et første overslag, men slutte på et højt niveau, når entreprenøren afgiver bindende tilbud. Det er tænkeligt, at tilbudsfasens omkostningsestimering slutter med et lavere informationsniveau end ønskeligt/defineret (travlhed, begrænsede erfaringer med bygningstypen, utilstrækkeligt udbudsmateriale, ). Men hvis det lavere informati- Overvej at knytte informationsniveau til et informationspakkebegreb. Der er, så vidt vi umiddelbart kan vurdere, ikke noget til hinder for det i metoden. 9

10 med er afsnit til hver af de fremførte er onsniveau er rimeligt velspecificeret, har tilbudsgiveren i hvert fald en indikation af usikkerheden i tilbuddet. Han kan evt. undlade at afgive tilbud, hvis informationsniveauet ikke kan bringes højt nok op. Side 9, nederst Der står: Hovedelementerne i informationsniveaumetoden er som illustreret ovenfor leverancespecifikationer samt informationsniveaudefinitioner for objekter som bygningsdele og rum. Desuden understøtter metoden også specifikation af informationsniveauer for processer. Vis gerne, hvordan informationsniveauer kan bruges på andre klasser, både nogle der afbilder fysiske og ikke-fysiske fænomener. To er: 1) for objekter som bygningsdele og rum. Bruges informationsniveaumetoden reelt på andet end bygningsdele og rum i dette? 2) Der er i dele af byggebranchen en opfattelse af, at objekter kun er fysiske (bygninger, rum, bygningsdele, ). Ikke-fysiske fænomener, som processer, roller, kompetencer, aftaler, kan med fordel også opfattes som objekter. Jf. teori om objektorienteret analyse/design. Side 15 Teknisk De tre grupper af egenskabsdata (Funktionskrav, Resultat og Produktion) er relevante for bygningsdele og rum (og sikkert også andre klasser), men næppe for klasser generelt. Skriv at grupperne anvendes for bygningsdele og rum. Bilag B Redaktionel Termer og definitioner Kunne man inkludere: Aktør Leverancespecifikation View Ikke-fysisk objekt 10

11 med er afsnit til hver af de fremførte er Gyldighedsområdet Det område, der gennem eksemplificering er dækket her primært information knyttet til bygningsdele er ikke uden betydning. Vi tror imidlertid, at den relativt generelle grundidé i metoden at specificere niveauer for egenskabsdata på objekter har meget videre, og måske endnu mere værdiskabende anvendelser. Så vidt vi kan udlede er det anvendte gyldighedsområde sammensat af gyldighed indenfor flere områder: Hvilke klasser og egenskabsdata dækkes? Bygningsdelstyper, til en vis grad rum. Processer er nævnt. Klassen Bygning optræder et enkelt sted. Klassen Tidsplan forveksles et sted med klassen Proces. Det konkrete bygningsdelstyper og egenskaber fastlægges i et senere projekt. Hvilke formelle formkrav stiller man til informationen? I høringsrapporten accepteres information i overensstemmelse med de traditionelle begreber, klasser og egenskabsdata. Men information, f.eks. i form af tekst og grafik ligger tilsyneladende udenfor gyldighedsområdet. Hvilke aktører ønsker man at støtte i hvilke processer/faser. Er ikke eksplicit fastlagt. Næppe alle. Er f.eks. materialeproducenter, offentlige myndigheder, lejere og deres processer med? Er udenlandske aktører, der arbejder på danske byggerier? Hvilke problemer ønsker man at afhjælpe? Eller lidt mere neutralt formuleret: Hvilke formål stræber man efter at opfylde med de kommende informationsniveauer. Helt sikkert ikke alle. Der er mange problemer forbundet med branchens informationsbrug, som man formentlig ikke har til hensigt at løse. Vi ser meget gerne en eksplicit angivelse af informationsniveaumetodens/-strukturens gyldighedsområde, f.eks. angivet ved de fire delområder nævnt i Kommentarfeltet. Gerne flere delområder, hvis det er hensigtsmæssigt. Da der foretages væsentlige valg her, er begrundelser for disse valg vigtige. Der kan med fordel skelnes mellem det gyldighedsområde, metoden er udviklet til i første omgang og det gyldighedsområde, man har til hensigt at videreudvikle metoden/strukturen til. Bl.a. Afsnit 1.1 og 1.2 Rapportens opbygning er sådan: Indledningsvis beskrives meget generelle ambitioner, formål og målgruppe. Efterfulgt af kapitel 2 til 5, der beskriver metoden og strukturen for informationsniveauer gennem ret konkrete eksempler primært baseret på bygningsdele. Afsluttende med en igen meget generel konklusion i kapitel 6. Denne opbygning var en kilde til forvirring hos os. Vi forslår, at man i indledningen dels fortæller, hvordan rapporten er bygget op. Dels fortæller, hvilken status eksempelfremstillingen har: At den udgør udviklingen af metoden/strukturen primært for bygningsdele. Dels fordi vi på baggrund af den generelle indledning troede vi ville få en generel beskrivelse af metoden og strukturen. I stedet fik vi en relativt afgrænset (om end ikke 11 Se også Kommentar-feltet.

12 med er afsnit uvæsentlig) anvendelse. til hver af de fremførte er Dels fordi, det efterhånden gik op for os, at eksemplerne reelt er mere end almindelige eksempler. Vi tror de repræsenterer en væsentlig del af udviklingen af metoden/strukturen, og at det primært er indenfor bygningsdele, vi vil se udviklingen i den kommende tid. Den meget generelle metode/struktur kræver nemlig konkret videreudvikling for at kunne anvendes indenfor nye områder. Metoden og strukturen forudsætter, at information kan angives som enkle, veldefinerede egenskabsdata på veldefinerede objekter. En stor del af den information, der anvendes i bygninger og anlægs livscyklus lever ikke op til denne forudsætning. Det gælder f.eks. De store mængder tekst, der f.eks. knyttes til bygninger, rum, bygningsdele, Tekst anvendes også i mange andre sammenhænge, f.eks. aftaler, procesbeskrivelser, planer, D&V-information. Tekstmæssig information vil have en betydelig udbredelse i mange år endnu i branchen. Her er et informationsniveaubegreb også relevant, men metoden giver ikke noget fingerpeg om, hvordan det kan ske. Det er en alvorlig indskrænkning. 2D-tegninger er normalt den form for model, der er juridisk bindende fra rådgivernes side. Dvs. grafisk information. Hvis der er en 3D model bag, leveres den ofte til orientering, hvis den overhovedet leveres. Vi kan ønske, at dette forhold vendes om, så det bliver 3D-modellen, der bliver den juridisk bindende originalmodel og 2D-tegningerne, bliver mekanisk produceret fra 3D-modellen. Det er imidlertid en udvikling, der må forventes at tage år. Der er behov for at knytte informationsniveauer til 2D-tegninger. Andre måder at registrere information på, der er anvendes i stigende grad, er fotos, video og lyd. Se Kommentar-feltet Afsnit 4 Side 12 Der står: Informationsniveaumetoden baseres på anvendelsen af informationsniveauer, der entydigt specificerer informationsleverancers omfang samt konkretiserings- og detaljeringsniveau for bygningsdele, rum og processer. Vi mener, at det er uhensigtsmæssigt at begrænse anvendelsen an informationsniveauer til bygningsdele, rum og processer. Metoden/strukturen bør kunne skabe værdi i forbindelse med mange andre klasser indenfor byggeriet, f.eks. materialer, materiel, entrepriser, kompetencer, forskellige typer af planer, aftaler, Lad det stå åbent, hvilke klasser, der med fordel kan defineres informationsniveauer for. Skriv gerne, at dette koncentrerer sig om bygningsdele og rum, og mere overfladisk med processer. Men at fremtidig udvikling af metoden vil inddrage andre områder. 12

13 med er afsnit til hver af de fremførte er Vi ser gerne metoden udviklet indenfor andre områder, især indenfor klasser og egenskaber i ressourcedomænet. 19 Der står: Desuden kan der for hvert view være behov for at specificere supplerende egenskabsdata, som fastlægges i den pågældende proces i det pågældende informationsniveau.. Er vi ikke tæt på en erkendelse af, at klasserne bygningsdele og rum ikke er nok. I det viste kalkulationseksempel (figur 6) kunne de supplerende egenskabsdata komme fra objekter i ressourcedomænet (aktuelle priser på et kalkuleret forbrug af materialer og andre ressourcer) fra faktiske priser på faktiske ressourceforbrug på tidligere opførte bygninger. Der er vel principielt ingen forskel på de informationer, viewet henter fra udvalget af bygningsdele, rum og bygninger og dem, viewet henter fra et udvalg af ressourcer og evt. tidligere opførte bygninger. Figur 19 side 30 Teknisk Figur 19 er et godt eksempel på, at informationsniveaubegrebet kan bruges på andet end bygningsdele og rum. Vi mener dog, at informationsniveauerne i eksemplet er knyttet til klassen Tidsplan, ikke til klassen Tidsplanlægningsproces. På samme måde som informationsniveauer for en bygningsdel er knyttet til bygningsdelen, og ikke til den/de processer, der frembringer bygningsdelen. Information (og hertil definerede informationsniveauer) for tidsplanlægningsprocessen kan være dens placering i tid (altså planlægningsprocessens, ikke den plan, den frembringer), dens varighed, dens ressourceforbrug, dens kompetencekrav, dens krav til planlægningssystem, metodekrav o.l. Man kan opfatte denne lille struktur som bestående af to klasser, Tidsplanlægningsprocessen og Tidsplanen (med hver deres sæt af informationsniveauer), med en relation imellem, Resulterer i / Er resultat af. På et givet tidspunkt kan informationsniveauet godt være højt for Planlægningsprocessen og lavt for Planen. Vi synes ikke, eksemplet bliver dårligere med denne synsvinkel. Se under Kommentar-feltet. Side 22 Det indikeres her (og andre steder), at informationsniveauer bruges til at specificere information, der overdrages fra én aktør til en anden. Vi mener, man bør overveje at bruge metoden internt. Selvom man overdrager information til sig selv, ser det ud som om, metoden kan have værdi. Man kan f.eks. have et antal milepæle/baselines hen igennem en projektfase. For en give milepæl/baseline kan man specificere, at en nærmere angivet klump information skal være på et nærme- Se Kommentar-feltet. 13

14 med er afsnit til hver af de fremførte er re angivet informationsniveau også selvom den ikke skal overdrages til en ekstern aktør. Afsnit 5.1 side 23 Det ville være livgivende, hvis man også kunne vise et eksempel på en leverancespecifikation for klasser i ressource- og/ procesdomænerne? Side 23 Teknisk Her introduceres begrebet komponent. Er det nødvendigt, kunne vi fortsætte med at bruge bygningsdel? Hvis det er nødvendigt, burde begrebet nok være introduceret tidligere. Under alle omstændigheder forudsættes her noget viden om CCS, som læseren måske ikke har. Bilag B Side 48 Informationsniveau: Omfang, konkretiserings- og detaljeringsniveau for informationer om bygningsobjekter. Se Kommentar-feltet. Kan CCS s bygningsdelsstruktur beskrives kort i et bilag, hvortil der kan henvises? Vi anbefaler at bruge informationsniveaubegrebet for alle fysiske og ikke-fysiske objekter i forbindelse med byggeri og anlæg. Ikke kun for bygningsobjekter, men også for f.eks. processer, roller, aftaler, begivenheder, Også selvom konkret metode og struktur endnu ikke er udviklet. (Alt er jo h ikke udviklet for bygningsobjekter (bygninger, bebyggelser, etager, lejligheder, er ikke dækket i høringsrapporten). Sammenhæng med andre standarder, andre cuneco-projekter, andre organisationer (se også afsnittet om international orientering ovf.) Der savnes et overblik over sammenhængen mellem Informationsniveaumetoden til CCS kodning med egenskabsdata, IKT aftaler, ydelsesbeskrivelser, arbejdsbeskrivelser etc. og andre relevante cuneco-tiltag, f.eks. i form af et billede af hvordan tingene overordnet tænkes at hænge sammen. Beskrivelse med tilhørende illustration, som viser denne sammenhæng. Vi anerkender ønsket om, at den generelle metode og struktur for informationsniveauer ikke forudsætter en bestemt fasemodel, bestemte ydelsesbeskrivelser osv. Men dels er der begrebsmæssige sammenhænge mellem de forskellige områder, som det vil 14

15 med er afsnit Afsnit 5.1 til hver af de fremførte er have værdi at få klarlagt og vist. Dels er der behov for retningslinjer for, hvordan de fremtidige informationsniveauer skal udvikles. Disse retningslinjer bør etableres, før den egentlige udvikling af informationsniveauer finder sted. Er der f.eks. værdi i at udvikle informationsniveauer, der passer til ydelsesbeskrivelserne? Tanken om at udarbejde en leverancespecifikation for det konkrete projekt ses som en rigtig god idé. Det er dog væsentligt at dette i videst muligt omfang bringes videre til Danske Ark, F.R.I., Dansk Byggeri, plus eventuelt flere for at tankegangen implementeres og sikres korrekt sammenholdt med byggeriets ydelsesbeskrivelser mv. Der er sammenhænge med og behov fra andre cuneco-projekter. Vi tror, at f.eks. projektet Specifikation af data til tilbudsgivning har brug for informationsniveaumetoden og -strukturen. Er der taget højde for, at andre (igangværende senere) cunecoprojekter kan stille krav til informationsniveaumetoden/-strukturen? Kommer der en senere projektfase, hvor sådanne krav kan behandles og føre til justering af metoden/strukturen? Skal næppe stå i rapporten, men i den projektinformation, der findes på cuneco.dk. IKT-understøttelse Hvis vi har forstået høringsrapporten rigtigt, er resultatet en kompliceret og til tider omfattende struktur, som det ofte vil være vanskeligt at holde styr på manuelt. Kompleksiteten i kodereglerne (som vi ikke kan gennemskue fuldt ud) er kommenteret ud fra et brugervenlighedsperspektiv ovf. under Informationsniveaumetoden/- strukturen kompleksitet. Vi tror ikke informationsniveaumetoden og -strukturen kan anvendes i praksis uden effektiv IKT-understøttelse. Der er ikke kun tale om at holde styr på den generiske kodestuktur. Der skal holdes styr på den konkrete struktur i datamaterialet for det konkrete byggeprojekt. Vi er på den anden side ikke overbevist om, at den nuværende udformning af metoden og strukturen i praksis kan IKT-understøttes effektivt. Det har ikke været muligt for os at foretage en tilstrækkelig vurdering på baggrund af den foreliggende beskrivelse. Den eksempelprægede fremstilling som kan have gode pædagogiske kvaliteter er ikke egnet til denne vurdering. Tiden har h ikke tilladt det. 15 1) Det er vigtigt for den IKTunderstøttelse, vi kan gøre os håb om i praksis, at metode og struktur defineres, så ganske almindelige IKT-udviklere og -brugere kan arbejde med strukturen. Dette bør stilles som et eksplicit krav til metoden/strukturen. 2) Regelsættet bag metoden og strukturen bør beskrives formelt og præcist, så en analyse af IKTegnetheden, som beskrevet i pkt. 1), kan foretages. Og så skal den foretages. 3) Der må etableres en troværdig plan for, hvordan branchen sikres den nødvendige IKTunderstøttelse (også) til anvendelsen af informationsniveauer.

16 med er afsnit Side 17 Teknisk Vedr. koderegeleksemplerne nederst på siden. Kompleksiteten har konsekvenser for den IKT-understøttelse, man kan forvente i praksis: Selvom kodereglerne gøres stringente (og det skal man sikre sig, de er) er sådanne koder generelt ikke IKT-venlige. IT-programmer skal jo være forberedt på enhver kodeopbygning, metoden/strukturen tillader, dvs. hele kompleksitetsspektret skal understøttes. Tænk i denne sammenhæng på, at vi bruger mange slags IT-folk i branchen Hovedparten af de BIM-værktøjer, vi anvender i den danske byggebranche, er udviklet af store softwareproducenter udenfor Danmark. Deres motivation til at udvikle løsninger specielt til det lille danske marked må formodes at være begrænset. Som minimum skal de dog have forståelige specifikationer. Derfor vil en engelsk udgave af materialet have betydning for realiseringen. Langt fra alle IKT-programmer bliver udviklet af store professionelle ITproducenter. En meget stor del af programmerne bliver sikkert udviklet tilpasset af in-house IT-afdelinger af forskellig størrelse mange med kun én nogle få ansatte. Der er også os selv, brugerne. Informationsniveauerne skal virke i de regneark, Word-filer, Access-databaser mv., vi selv opbygger. Man kan her tilføje tidsdimensionen: Det vil være en styrke for informationsniveaumetoden, at man kan anvende den hen igennem den enkelte fase ved 1) Dels at kunne specificere hvor informationsniveauerne planlægges at være ved givne milepæle indenfor fasen 2) Dels at kunne måle (maskinelt, dvs. vha. IKT-systemer) hvor man faktisk er. Det vil være uhyre nyttigt, hvis metoden/strukturen defineres sådan, at man maskinelt kan gennemlæse eksisterende data og fastslå, hvor projektet faktisk er mht. informationsniveauer. Og så sammenligne (igen maskinelt) med hvor man skulle være efter planen. Disse mellemtider vil sandsynligvis give mange og komplekse koder. til hver af de fremførte er Se Foreslået ændring i en ovenfor. Stil desuden det eksplicitte krav, at det faktiske informationsniveau i et konkret datamateriale maskinelt skal kunne måles og maskinelt kunne sammenlignes med det planlagte informationsniveau for materialet. Og verificér, at kravet er opfyldt. Oversæt materialet til engelsk. Udvikling af IKT-understøttelse vil være afhængig af en meget præcis designspecifikation. Eksempelfremstilingen i høringsrapporten, har sin værdi, men den er ikke direkte egnet som grundlag for IT-udvikling. Ved at fremstille præcise mod, regelspecifikationer osv. kan man befordre den nødvendige IT-udvikling. Man kan opnå dels, at designspecifikationen kun skal laves én gang i branchen, dels at IT-producenterne implementerer metoden of strukturen for informationsniveauer på samme måde i deres ITsystemer (noget der typisk er vanskeligt at opnå). Er en sådan designspecifikation på vej? På både dansk og engelsk? 16

17 med er afsnit til hver af de fremførte er Andet Afsnit 1 Figur 2, side 7 Teknisk? Det er svært at overbevise sig om, at informationsniveaumetoden skulle være nok til at undgå den situation, der illustreres på figuren. Der er enten noget galt med arkitekten ingeniørens kompetencer, hukommelse vilje til at leve op til aftalen. Der skal vist mere end informationsniveauer til for at redde den situation. Overvej et eksempel, der tydeligere indikerer, at informationsniveaumetoden/strukturen kan hjælpe. Afsnit 1.2 Side 8 Afsnit 3 Redaktionel Beskrivelsen: traditionelle Hardcore-Data er ikke speciel dækkende beskrivende. Fjern Hardcore-Data Der refereres til cunecos server, et begreb / en vision mange af os i bedste fald kun kender overfladisk. Der er tilløb til en beskrivelse i afsnit 5.4, men den har en underforstået karakter forudsætter, at læser allerede ved, hvad det er. Henvis gerne til en (kort) beskrivelse af cunecos server, f.eks. i et bilag. Afsnit 3 De tre scenarier er forfriskende og inspirerende men det er urealistisk at realisere dem alene med informationsniveauer anvendt på nogle få egenskaber for bygningsdele og rum. Dokumentets læsere er ikke naive, og vi risikerer, at åbenbart urealistiske scenarier får dem til at tage afstand fra ideen om informationsniveauer. Vi tror, at der skal betydelige indsatser til indenfor en række områder, ud over standarder og metoder. Det gælder f.eks. aftaler/jura, honorar, software og anden teknologi, kompetencer og formidling. Tag ikke inspirationen ud af scenarierne, men gør dem gerne mere realistiske. Afsnit 4.3 Side 18 Redaktionel De fleste processer i byggeriet kræver informationer for at kunne gennemføres Ja det giver næsten sig selv, gør det ikke? 17