CUNECO BEHOVSANALYSE BØLGE 3 KONKLUSIONER OG RESULTATER

CUNECO BEHOVSANALYSE BØLGE 3 KONKLUSIONER OG RESULTATER cuneco en del af bips Dato 15. 12. 2011 Projektnr. Sign. MET 1. Indledning cuneco vil i en behovsanalyse afdække byggebranchens behov for standarder for digital udveksling af information. Behovsanalysen består af tre elementer: Bølge 1, BEHOV: Workshops for de enkelte aktører (byg- og driftsherrer, arkitekter, rådgivende ingeniører, udførende og byggematerialeproducenter). Bølge 2, BEHOV: Fokusgrupper på tværs af aktører inden for faserne programmering, projektering, udførsel og drift & vedligehold. Bølge 3, LØSNINGER: Fokusgrupper på tværs af aktører inden for faserne programmering, projektering, udførsel og drift & vedligehold. Dette dokument beskriver konklusionen af bølge 3 fokusgrupperne, som blev afholdt hos cuneco den 17. - 25. november 2011. Fokusgruppemøderne havde følgende deltagere: Programmeringsfasen Projekteringsfasen Udførselsfasen Driftsfasen Stine Tarhan, Gentofte Ejendomme. David Fink, smith hammer lassen architects. Leif Kaare Jensen, Rambøll. Christine Kalhauge, CO- WI. Markus Lampe, DTU Campus Service. Charlotte Degn, Århus Universitetshospital. Ole Kristian Kvarsvik, Nosyko. Bent Dalgaard Larsen, Dalux. Mette Carstad, Universitets- og Bygningsstyrelsen. Birte Bæk, Henning Larsen. Per Jyllnor, JYRO architects. Claus Dyrlund, Rambøll. Gert Jespersen, NCC. Martin Birk, Tekla. Nicolai Karved, Betech Data. Allan Løvgreen, Kemp & Lauritzen. Kenneth Asbjerg, Jakon. Stefan Brandt Johansen, E. Pihl & Søn. Claus Erik Nielsen, NCC. Jakob Brysting, Rockwool. Claus Johannesen, PLH Arkitekter. Magnus Therkildsen, CodeGroup. Lars Holmsgaard, Landsbyggefonden. Torben Trampe, KAB. Bryan Karlqvist, Københavns Ejendomme. Michael Ørsted, Københavns Lufthavne. Bjarne Christensen, YIT. Stefan Brorsen, Gottlieb Paludan. Christian Lundstrøm, Grontmij. Christian Overgaard, Grontmij. Ellena Lee, Jakon. Nicolai Karved, Betech Data. Torben Dalgaard, Dalux. cuneco står for fællesskab. Vi udvikler det fælles grundlag for digitaliseret samarbejde i byggeri, anlæg og drift. Målet er øget effektivitet og produktivitet gennem bedre udveksling af informationer. www.cuneco.dk Side 1 af 41

Fra cunecos side deltog: Torben Klitgaard, cuneco (facilitator) Gunnar Friborg, bips (facilitator) Søren Spile, cuneco (facilitator) Mette Øbro, cuneco (referent) Fokusgruppemødernes dagsorden: 1. Opsamling fra bølge 2 fokusgruppemøder 2. Diskussion af brugerscenarier 3. Værdiestimering 4. Opsamling på dagen Indhold Rapporten har følgende indhold: 1. Indledning s. 1 2. Konklusioner s. 3 3. Resultater s. 5 3.1. Udpegede standarder s. 5 3.2. cuneco serveren s. 14 3.3. Brugerscenarier cunecos løsningsforslag s. 15 3.4. Værdiskabelse s. 28 3.5. Forretningsmodel og betalingsform s. 35 3.6. Vurdering af brugerscenarier s. 38 Bilag 1: Udpegede standarder præsenteret i bølge 3 Bilag 2: Procesmodeller præsenteret i bølge 3 Bilag 3: Scenarier præsenteret i bølge 3 Side 2 af 41

2. Konklusioner 2.1. Udpegede standarder cunecos analyseteam har pba. de behov, der blev formuleret i bølge 1 og 2, udpeget en række standarder, der kan afhjælpe de påpegede problemer. Deltagerne i bølge 3 er blevet præsenteret for disse standarder og har overordnet accepteret dem som konklusion på bølge 1 og 2. Det drejer sig om følgende standarder: Standarder inden for cunecos indsatsområder Standard for funktionsarealer og rum og deres egenskaber og sammenhænge Standard for opsamling af driftsdata til brug for bygningsdrift og programmering Standard for informationsniveauer, udveksling og datagenbrug Standard for opmålingsregler og mængde- og dataudtræk ved udbud og tilbud Standard for anvendelse af klassifikation Standard for anvendelse af egenskabsdata Standarder inden for bips indsatsområder Bygningsmodellen opdatering af arbejdsmetoder og regler Beskrivelsesstruktur og -værktøj opdatering vedr. struktur og indhold Beskrivelsesstruktur og -værktøj opdatering vedr. funktionsudbud Standard for digitale tilbudslister Standarderne er nøjere beskrevet i bilag 1. 2.2. cunecos løsningsforslag Der er generelt opbakning til ideen om, at cunecos kommende standarder og produkter som benævnes Byggeriets Digitale Stamdata stilles til rådighed for branchen vha. en cloudbaseret løsning, hvor brugerne på forskellig vis kan hente materialet på en server, eller det er indbygget i softwareleverandørernes programmer. cuneco har på baggrund af de udpegede standarder udarbejdet otte scenarier, der viser eksempler på, hvordan brugerne i en konkret situation kan tænkes at arbejde med cunecos kommende standarder og produkter. Præsentationen af scenarierne har genereret en diskussion i de enkelte fokusgrupper om mulige løsninger, hvilket viser, at deltagerne generelt kan se for sig, at cunecos produkter kan indgå i deres hverdag på en meningsfyldt og værdiskabende måde. Scenariemetoden fungerer dog bedst, når deltagerne i høj grad kan se sig selv i de beskrevne scenarier. Side 3 af 41

Deltagerne vurderede de otte præsenterede scenarier i følgende rangorden:* Scenarie Gruppe Relevans Entreprenør modtager digitalt udbudsmateriale som Udførselsfasegruppen 4,6 grundlag for tilbud Driftsherre modtager digitalt materiale som grundlag Driftsfasegruppen 4,4 for drift Bygherrerådgiver udarbejder rum og arealprogram Programmeringsfasegruppen 4,0 til konkurrenceprojekt Rådgiver laver mængdesat tilbudsliste til digitalt Projekteringsfasegruppen 3,7 udbud Bygherrerådgiver verificerer krav vedr. areal og Programmeringsfasegruppen 3,6 økonomi i konkurrenceprojekt Entreprenør opretter produktionsgrundlag ud fra Udførselsfasegruppen 3,6 kalkulation Driftsherre registrerer driftsinformation som grundlag Driftsfasegruppen 3,2 for programmering Rådgiver laver udtræk til bygherren til verifikation af Projekteringsfasegruppen 2,0 opfyldelse af krav *Hver fokusgruppe er blevet præsenteret for to scenarier, der er relevante for den fase af byggeriet, gruppen repræsenterer, dvs. hhv. programmering, projektering, udførsel og drift. Scoren angiver gennemsnittet af deltagernes vurdering af scenariets relevans på en skala fra 1-5. Deltagernes begrundelse for deres vurdering kan summeres i tre punkter: Flere af scenarierne hænger tæt sammen og kan reelt reduceres til ét scenarie. De forskellige scenarier har mere kortsigtede og langsigtede perspektiver. Deltagerne foretrækker generelt de scenarier, der på kort sigt kan realiseres og skabe en gevinst, ud fra devisen: cuneco skal starte med at plukke de lavthængende frugter. cuneco skal være opmærksom på, hvor langt man skal bevæge sig hen mod at levere en service frem for blot at stille en standard til rådighed på en intelligent facon. 2.3. Værdiskabelse Deltagerne vurderer, at de beskrevne cuneco produkter kan skabe værdi for branchen ved at spare tid i den fase, de omhandler, men i høj grad også ved at spare tid i de efterfølgende faser og ved generelt at løfte kvaliteten af byggeprojekterne. Brugen af cunecos produkter vurderes således både at have direkte, indirekte og afledte effekter, hvor de indirekte og afledte effekter vurderes at være de største. Fx vil digitalt udbud med mængder spare de udførende for meget tid i tilbudsfasen, men har sin største gevinst i den efterfølgende fase, hvor det forbedrede datagrundlag kan bruges til at optimere produktionsplanlægnin- Side 4 af 41

gen, så der opnås en mere effektiv byggeproces med bedre logistik, færre fejl og mangler, lavere materialeforbrug o.lign. 2.4. Betalingsform Deltagerne har delvis forståelse for, at bips efter cunecos ophør vil have behov for brugerbetaling for at kunne drifte og videreudvikle cunecos produkter. Der bør iflg. deltagerne tilbydes en pallette af betalingsformer, som tilgodeser forskellige brugeres behov i forskellige situationer. Det skal fx være muligt for virksomheder, der ikke er medlem af bips, at få adgang til materialet på anden vis. En mulighed kunne være at opdele materialet i en gratis del med basisstandarder og en betalingsdel, hvor der tilbydes ekstra services af forskellig art. Projektspecifikke ydelser kunne være en mulighed, hvor man dog skal være opmærksom på, om cuneco/bips pådrager sig rådgiveransvar. Bygherrerne må ses som en særlig vigtig målgruppe, idet man kan forestille sig, at de stiller krav om brugen af cunecos produkter og samtidig stiller disse til rådighed for byggeprojektets parter. 3. Resultater I resten af rapporten refereres diskussionen på fokusgruppemøderne mere indgående. Referatet af de enkelte diskussioner gengiver ikke nogen samlet konklusion, men de individuelle kommentarer, som visse steder vil være modstridende, grundet deltagernes forskellige synspunkter og interesser. 3.1. Udpegede standarder cunecos analyseteam har pba. de behov, der blev formuleret i bølge 1 og 2, udpeget en række standarder, der kan afhjælpe de påpegede problemer: Standarder inden for cunecos indsatsområder Standard for funktionsarealer og rum og deres egenskaber og sammenhænge Standard for opsamling af driftsdata til brug for bygningsdrift og programmering Standard for informationsniveauer, udveksling og datagenbrug Standard for opmålingsregler og mængde- og dataudtræk ved udbud og tilbud Standard for anvendelse af klassifikation Standard for anvendelse af egenskabsdata Standarder inden for bips indsatsområder Bygningsmodellen opdatering af arbejdsmetoder og regler Beskrivelsesstruktur og -værktøj opdatering vedr. struktur og indhold Beskrivelsesstruktur og -værktøj opdatering vedr. funktionsudbud Standard for digitale tilbudslister Side 5 af 41

Standarderne er nærmere beskrevet i bilag 1. Standarderne blev præsenteret på bølge 3 fokusgrupperne sammen med en procesmodel over udvalgte processer, som fremgår af bilag 2. Deltagerne i bølge 3 var overordnet enige i, at de udpegede standarder afspejlede fokusgruppediskussionerne i bølge 2. Herudover var der følgende kommentarer til de udpegede standarder generelt: cuneco forudsætter, at flere standarder vil skabe øget effektivisering. Det handler om at få cunecos arbejde implementeret i værktøjerne, så det er selvkørende. Objektklasser og anvendelsesview mangler at blive omtalt. Der skal i løsningen lægges vægt på et let anvendeligt værktøj. Beskrivelsesafsnit mv. i byggeriet har en tendens til at opnå en stor detaljeringsgrad, hvilket ofte resulterer i et stort genbrug. Heraf følger en relativt stor mængde information, som ikke rettes eller er decideret unødvendig. Dette skulle gerne kunne håndteres i det fremtidige system. Efter gennemgangen af oversigten over standarderne fik hver fokusgruppe nøjere gennemgået to standarder, som var særligt relevante for den fase, gruppen var baseret på. Det drejer sig om følgende: Programmeringsfasegruppen: Standard for funktionsarealer og rum og deres egenskaber og sammenhænge Standard for informationsniveauer, udveksling og datagenbrug Projekteringsfasegruppen: Standard for opmålingsregler og mængde- og dataudtræk ved udbud og tilbud Standard for informationsniveauer, udveksling og datagenbrug Udførselsfasegruppen: Standard for opmålingsregler og mængde- og dataudtræk ved udbud og tilbud Standard for informationsniveauer, udveksling og datagenbrug Driftsfasegruppen: Standard for opsamling af driftsdata til brug for bygningsdrift og programmering Standard for informationsniveauer, udveksling og datagenbrug Nedenfor er diskussionen af de enkelte standarder gengivet. Side 6 af 41

3.1.1. Standard for funktionsarealer og rum og deres egenskaber og sammenhænge Standarden er beskrevet i bilag 1, s. 2. Deltagerne havde følgende kommentarer til standarden: Egenskabsdata Klassifikation er egenskaber, hvor én egenskab er ophævet til den vigtigste og bruges til klassifikation. Eksempler på relevante egenskabsdata for rum kunne være størrelse, funktion, luftskifte, brugerforhold, lejerforhold. Tingene skal adskilles fra hinanden, fx brugere fra funktion, så bygherren selv kan mappe de ting sammen, som han har brug for, lag for lag. Et rum har mange forskellige egenskabsdata, der skal kunne mappes sammen i forskellige fortolkninger, alt efter brugernes interesse. Egenskabsdata hænger tæt sammen med informationsniveau, og hvordan det bygges op gennem processen: hvilke egenskabsdata skal med i starten og hvilke skal man slutte med? Både mængden og præciseringen af egenskaberne øges i løbet af processen: i starten er kun 1/10 af egenskaberne lagt fast. Brutto-netto-areal Der opstår tit en diskussion af netto-bruttoarealer, idet hver part har sin egen fortolkning af begreberne. Uensartede opfattelser af netto-brutto-areal er en udfordring både i forhold til bedømmelse af konkurrenceprojekter og i forhold til benchmarking med lignende bygninger. Dansk Standard opererer med netto-arealer, men det er nettobrugsarealer bygherren interesserer sig for. Bygningsmodel og rum Det ville være hensigtsmæssigt at have større sammenhæng mellem rumskema og bygningstegning/model: Ved projekteringsfasen flyttes informationerne over i modellen, og det bliver en byrde at vedligeholde rumskemaet, som derfor ofte dør undervejs. Geometri og information skal skilles ad, så informationen ligger ved siden af modellen og kan blive selvstændigt vedligeholdt gennem byggeprocessen. Der skal være en sammenhæng mellem de to, som kunne være DBK eller noget andet. Adskillelsen gør det også muligt i driftsfasen at skifte geometrien ud til en mere simpel model, samtidig med at informationerne bibeholdes. Man kan også arbejde med delt geometri og egenskabsdata, hvor alle ruminformationer findes i modellen, men kan trækkes ud. Andet Den beskrevne standard er relevant i hele projekteringsforløbet, ikke kun i starten af byggeprocessen, idet byggeprogrammet er en bestilling, som lø- Side 7 af 41

bende præciseres eller justeres, når forudsætningerne ændres og fx krav og design kommer i modstrid med hinanden. Et dynamisk byggeprogram, hvor ændringerne i projektet dokumenteres løbende, ville være nyttigt. Mht. rumprogrammer er der en EU ISO-standard på vej, som er blevet anvendt på større byggerier i Danmark, og som cuneco bør undersøge. 3.1.2. Standard for opsamling af driftsdata til brug for bygningsdrift og programmering Standarden er beskrevet i bilag 1, s. 2. Deltagerne havde følgende kommentarer til standarden: Aktivitetslister Afleveringsdata skal gøres brugbare i driften ved at blive leveret i en struktureret form, hvorfra der kan genereres en aktivitetsliste. o Rådgiverne har ikke som udgangspunkt tilstrækkelig viden til at generere en relevant aktivitetsliste dette kræver bygningsejerens aktive medvirken (fx skal 200 aktivitetsbeskrivelser måske reduceres til 80 for at svare til driftens reelle behov). o Det vil dog være en fordel for driftsherren at modtage en digital, struktureret bruttoliste, som han selv kan viderebearbejde. o Driftsherrerne skal stille skarpere krav til, præcis hvilke data de har behov for. Aflevering af producentinformation Der mangler i modeltankegangen at blive taget højde for driftsdata, fx vedligeholdelsesmanualer. Hvordan skal disse producentinformationer komme ind i modellen? Fx via en webservice, hvor man kan trække vedligeholdelsesinformation over i modellen? Skal der udarbejdes en standard for, hvordan producenterne udarbejder en minimanual, der kan anvendes digitalt? Det tager lang tid for rådgiverne at indsætte vedligeholdelsesintervaller, økonomi og produktmanualer på afleveringsinformationen. Producenterne burde levere standardiserede rådata, som rådgiverne bare kan trække ind efter behov på det ønskede detaljeringsniveau. o Rådgiverne skal kunne tilføje byggerispecifik information til disse data. o Det kan imidlertid være uhensigtsmæssigt at fylde bygningsmodellen med alt for mange og for detaljerede informationer. Måske skal data fra producenterne udveksles ved siden af modellen? o Hvis al producentinformation lægges i bygningsmodellen, bliver der meget as-built materiale, rådgiverne skal rette til. (Det kan fx være, at en pumpe var i restordre, så der blev leveret en anden pumpe, så data skal ændres efterfølgende). Under alle omstændigheder kræves enten rådgivers eller bygningsejers bearbejdning af produktinformationen i forhold til produktets placering i Side 8 af 41

byggeriet, fx er vedligeholdelsesfrekvensen for udvendigt træværk afhængig af, om det er placeret på bygningens nord- eller sydside. Samlet set skal mange parter i spil for at definere de data, der er brug for i driften, både producenter, rådgivere og driftsherrerne. Fra drift til programmering I forhold til bl.a. energi og bæredygtighed er det en kæmpe hjælp at få driftserfaringer med over i programmeringsfasen. Det er svært at få klare erfaringstal fra driften til brug i programmeringsfasen, og en standard vil ikke løse problemet. Omsætningen af driftserfaring til programmering er primært relevant for store bygherrer, som råder over flere bygninger og løbende igangsætter nybyggeri Dokumentation af eksisterende bygninger Der er behov for en standard for, hvordan dokumentationen af gamle bygninger bringes op på et højere digitalt niveau. o Modellen skal gerne være fleksibel og kunne fungere med et lavt informationsniveau, så hvis man fx kun har rumdata for gamle bygninger, kan man nøjes med dette. Den præsenterede procesmodel Den komplekse procesmodel afspejler driftsherrernes hverdag. I procesmodellen bør der tilføjes aflevering af arealer og rum til drift og brug. Dog kun, hvis cuneco reelt har tænkt sig at lave materiale til slutbrugerne. Andet Kvalitetssikring er vigtigt, fx skal det sikres, at der er installeret præcis de benævnte produkter. Dette ligger dog uden for en standard. cuneco kan omtale 3D objektmodel som objektmodel, så dækker det bredere og inkluderer principielt også 2D, 4D osv. Essensen er at knytte alfanumeriske data sammen, som kan hægtes op på fx et rummeligt aspekt. 3.1.3. Standard for informationsniveauer, udveksling og datagenbrug Standarden er beskrevet i bilag 1, s. 4. Deltagerne havde følgende kommentarer til standarden: Udenlandske erfaringer Statsbygg i Norge har arbejdet med en IDM til programmeringsfasen igennem 3 år, som cuneco kan bygge videre på. Slutbrugerne Der er også behov for at definere et informationsniveau i forhold til slutbrugerne, som har andre informationsbehov end de professionelle aktører. Slutbrugerne skal ikke overinformeres, men skal modtage de relevante informationer om brugen af bygningen, så de bruger den korrekt. Dialogen Side 9 af 41

med slutbrugerne skal ske løbende og gerne så tidligt som muligt i byggeprocessen. Ombygning Der skal også tænkes i forhold til ombygning det er tit et diskussionspunkt, hvor omfattende og detaljeret dokumentationen af den eksisterende bygning skal være, for at rådgiverne på ombygningen kan arbejde videre ud fra det. Tolerancer Der er behov for tolerancenormer en angivelse af hvilken usikkerhed, målene i en bygningsmodel er angivet inden for. Dette skal med i definitionen af informationsniveauer: Der mangler på modelniveau en parameter, der angiver, hvor præcist elementerne i modellen er angivet. Det er nyttigt bl.a. i kommunikationen mellem rådgiverne at kende usikkerheden på angivelsen af et element, så fx ingeniøren får mulighed for at skubbe en søjle 5 cm. Sammenhæng med fasemodellen Måske er det nok at have informationsniveauer; måske behøves fasemodellen ikke længere, men er blot med til at skabe usikkerhed og konflikt? Der er en klar sammenhæng mellem informationsniveauer og faser, men den er svær at definere entydigt. Man skal holde fast i fasemodellen, idet den angiver et rationelt projekteringsforløb, hvor tingene gradvist konkretiseres i en iterativ proces. Informationsniveauerne skal fastlægges i en successiv proces: Et byggeri er ikke klart defineret fra starten af der sker en bearbejdelse i udbuddet. Standarden for informationsniveauer skal håndtere denne virkelighed. BIM-teknologiens muligheder skal udnyttes til at få flyttet beslutninger tidligere op i processen det er netop herved, at byggeriet kan opnå den ønskede effektivisering. I forhold til bygherrens beslutningsproces kan man ikke fastlægge, at bygherren i bestemte faser skal have bestemte informationsniveauer, da det afhænger meget af det enkelte byggeri (fx skal man fastlægge materialevalget meget tidligt i processen, hvis man vælger teglsten, mens man i forhold til en betonkonstruktion på facaden kan vente med beslutningen til meget sent i processen). Men man kan beskrive forskellige informationsniveauer, som bygherren kan bede om. Overfyldte bygningsmodeller Det vil være godt at definere præcist, hvilke informationer der skal hægtes op på modellen i hvilke faser, for at bygherren har det rette beslutningsgrundlag. Som det er i dag, lægger rådgiverne ofte tidligt meget information ind i modellen, fordi det kan lade sig gøre. Et fokus på need to know frem for nice to know vil skabe kvalitet frem for kvantitet i informationerne. Side 10 af 41

Det er i orden at udfylde de tomme felter i modellen, men det skal først opfattes som valide data på et bestemt tidspunkt i processen. Det er farligt at have for mange informationer i modellen, da de skaber forvirring og spildtid i de tværfaglige diskussioner. Rådgivere skræller ofte modellen for informationer før udbuddet for at sikre, at der ikke ligger produktspecifikke informationer i modellen, som ikke fremgår af tilbudslisten. Det handler også om tegnestuernes praksis at lære ikke at lægge mange informationer ind, blot fordi de er tilgængelige, men kun lægge de tekniske informationer ind, som er nødvendige. Så slipper man for at skulle fjerne informationer til udbuddet, og man undgår den forvirring, der kan opstå i processen med samarbejdspartnerne ved, at der ligger information i modellen, som ikke er gældende. Når de projekterende genbruger modeller fra tidligere byggerier, vil disse automatisk indeholde uaktuel information, som man er nødt til at fjerne. Bygherren er ikke interesseret i, at der i udbudssituationen er specificeret produkter i modellen, som bygherren ikke har bedt specifikt om. Det skaber forvirring blandt slutbrugerne, hvis modellerne i planlægningsfasen er for detaljerede, så slutbrugerne præsenteres for fx bestemte stoletyper og vægfarver og forventer, at dette vil være slutresultatet (mao. er et informationsniveau rettet mod slutbrugerne relevant). Mængden af information i en BIM-model er ikke i sig selv et problem. Der kan godt ligge mange informationer, som ikke er tilgængelige for de enkelte brugere (dvs. filtre er nødvendige). Blot skal nogen have taget stilling til informationerne. Produktspecifikke vs. generiske objekter Brugen af produktspecifikke biblioteker er farlig, da det giver designere og brugere den opfattelse, at man er låst fast på bestemte produkter (hvilket i dag er et problem på installationsområdet, hvor fx tekniske assistenter vælger at indsætte en bestemt pumpe, og ingeniøren efterfølgende ikke ved, om den er valgt pga. de tekniske egenskaber, eller fordi den passede i størrelsen). Det er derfor mere hensigtsmæssigt at arbejde generisk og først skifte de generiske objekter ud med konkrete produkter, når man reelt er nået dertil i processen. o Dette forudsætter, at producenterne eller softwarefirmaerne leverer generiske objekter. o Der findes ikke et CAD-værktøj, der kan indeholde alle de objekter, man har behov for i en projektering. Den eneste måde, man kan vedligeholde et produktkatalog på, er ved at lade producenten lave det. Klassifikation Mht. klassifikation er det ikke blot relevant at anvende begreberne bygninger, bygningsdele og rum, men også: o Bolig, som er en forvaltningsmæssig enhed for den almene sektor. o Flugtveje spreder sig over mange rum. Side 11 af 41

o o Veje (udendørsanlæg). Kommunerne har også andre relevante enheder end rum. Der skal være en klassifikation, så man kan finde fx alle pumper og deres placering på tværs af bygninger og rum. Andet Informationsniveaukrav kan være med til at sikre, at de overordnede mål for byggeriet, fx lavenergikrav, fastholdes gennem processen. Modelleringsregler skal kobles til informationsniveauer. 3.1.4. Standard for opmålingsregler og mængde- og dataudtræk ved udbud og tilbud Standarden er beskrevet i bilag 1, s. 6. Deltagerne havde følgende kommentarer til standarden: Udbudsformens betydning Tilbudslister er forskellige alt efter, om det er totalentreprise, fagentreprise eller OPP. Problemet med tilbudslister drejer sig især om funktionsudbud og graden af funktionsfastlæggelse af ydelsen. Det er fx nemt at gøre op i en tilbudsliste hvor mange vinduer, der skal være; det svære er hvilke funktionelle egenskaber, vinduerne skal have. Nye processer Cuneco tænker ud fra en gammeldags proces, hvor entreprenørerne først kom på banen, efter rådgiverne havde færdigprojekteret. Cuneco skulle i stedet fokusere på fremtidige processer. Tilbudslistens opbygning Der mangler en fælles standard for, hvor i tilbuddet de bydende skal placere deres ydelser fx på hvilke poster malerstigen og afdækningen af gulvet skal placeres. Som det er i dag, placerer entreprenørerne dem forskelligt, hvorfor tilbuddenes enkeltposter reelt ikke er sammenlignelige. Udbyder og bydende har forskellige formål med tilbudslisten og bruger den forskelligt: o Udbyder er primært interesseret i den endelige pris, men har også behov for en underinddeling i forhold til bygningsdele for at tjekke, om dele er projektet er blevet for dyre og evt. skal justeres. o Det kunne være en mulighed, at entreprenørerne ikke angiver tilbudspriser på samtlige poster (som alligevel ikke er reelt sammenlignelige), men én samlet pris pr. rum, hvori alle ydelser er medregnet. o Bygherren skal ikke definere, hvordan entreprenørerne skal udføre opgaven, det skal de selv kunne optimere (=argument imod at definere ydelser for specifikt). Side 12 af 41

o Tilbudslisten skal være med mængder, så de bydende ikke hver især skal tælle op, men gerne uden prissættelse af de enkelte mængder. Kvalitet og ikke kun pris er væsentlig i vurderingen af tilbud: o Evt. prækvalifikationskrav, arbejdsmiljøkrav o.lign. burde fremgå af tilbudslisten, så det sikres, at bygherren tager dem alvorligt i vurderingen af tilbuddene. o Værdibyg arbejder med vurdering pba. kvalitet kvalitet som tillægskriterium. Der mangler en fælles forståelse af, hvordan en tilbudsliste ser ud. Et udviklingsarbejde bør tage udgangspunkt i, hvordan udbyder og de bydende hver især gerne vil have strukturen bygget op, så den er egnet til deres respektive formål. Når der arbejdes med en standard for tilbudslister, bør processen gentænkes frem for blot at sætte strøm til gamle processer. Måske skal der nye elementer ind, som kan skabe værdi? Mængdeudtræk cuneco skal se på eksisterende standarder, fx hvilke mængder der kan opgøres i en IFC-model, så vi ikke skal opfinde tingene to gange og lave særlige, danske modeller. It-værktøjerne udtrækker mængder forskelligt. Der mangler en fælles, international standard for, hvordan det skal gøres. o Man skal ikke på den korte bane forvente, at cuneco kan påvirke de store softwareleverandører til at ændre deres værktøjer. Dvs. skal der ske noget hurtigt, må det baseres på de eksisterende værktøjer. o Når der på længere sigt forhåbentlig foreligger en international standard, vil kunderne lægge pres på deres leverandører om at indarbejde den. Produktkrav vedr. mængder Der skal i udbudsbetingelser/optællinger tages hensyn til, at forskellige produkter stiller forskellige krav, fx vedr. mængdeudtræk. Fx vil huldæk opgøres i bruttomængder (her taget som formbredde x elementlængde), mens vægge opgøres i de tegnede højde/ bredde. Dette er sammenhængende med produktionsmetode, idet huldæk altid støbes i fuld bredde, for senere at skæres til. Mens vægge støbes i den tegnede høje/bredde. Andet Cunecos udgangspunkt skal være, at det også fremover skal være muligt for branchen at anvende forskellige værktøjer. Side 13 af 41

3.2. cuneco serveren Deltagerne blev præsenteret for, hvordan cuneco planlægger at stille sit færdige materiale til rådighed for branchen, nemlig vha. en cloudbaseret løsning, hvor materialet Byggeriets Digitale Stamdata vil ligge på en server, hvorfra det kan hentes på forskellig vis, jf. figuren nedenfor. Der opstod i nogle af grupperne tvivl om, hvorvidt cuneco serveren indeholder statiske eller dynamiske data, om det er en modelserver eller en slags projektweb, og om serveren leverer it-services i konkurrence med softwareleverandørerne. Det blev derfor præciseret, at cuneco ønsker at samarbejde med branchens softwareleverandører, ikke at konkurrere. cunecos produkter tænkes indbygget i leverandørernes software, fx ved at leverandøren årligt betaler for dette. Idéen er, at serveren skal indeholde statisk information, som løbende opdateres. Den skal ikke opbevare projektspecifikke data og er ikke en modelserver, et projektweb ell. lign. Deltagerne accepterede på denne baggrund overordnet idéen om cuneco serveren: Det giver rigtig god mening Det er godt at skabe standarder og åbne op for, at flere softwareleverandører kan stikke snablen ind og få information Det blev i driftsgruppen foreslået cuneco at udvide sit forretningsområde ved at samle og bearbejde driftsdata og stille dem til rådighed for branchen, som herved får mulighed for benchmarking. Side 14 af 41

3.3. Brugerscenarier cunecos løsningsforslag Deltagerne blev præsenteret for en række brugerscenarier, der eksemplificerer, hvordan man kan forestille sig at kunne arbejde pba. cunecos standarder, når disse er færdigudviklet. Brugerscenarierne var udvalgt af cuneco pba. behovsdiskussionen i bølge 1 og 2. Scenarierne skal opfattes som beskrivelser af en mulig fremtid (ikke som en sandhed i sig selv), og inden for rammerne af disse beskrivelser diskuterede deltagerne en række mulige løsningsforslag til cuneco s slutprodukter/services. Scenariepræsentationen gav generelt en konstruktiv debat om mulige løsninger. Dog var nogle af deltagerne i projekteringsgruppen skeptiske over for de fremstillede scenarier, mens de var meget positive over for den bagvedliggende udvikling af informationsniveauer. I dette tilfælde fungerede scenariemetoden således mindre godt. Hver fokusgruppe fik gennemgået to brugerscenarier, som var relevante for den pågældende fase. Der blev gennemgået følgende scenarier: Programmeringsfasegruppen: 1. scenarie: Bygherrerådgiver udarbejder rum- og arealprogram for konkurrenceprojekt 2. scenarie: Bygherrerådgiver verificerer krav vedr. arealer og økonomi i konkurrenceprojekt Projekteringsfasegruppen: 3. scenarie: Rådgiver laver mængdesat tilbudsliste til digitalt udbud 4. scenarie: Rådgiver laver udtræk til bygherren til verifikation af opfyldelse af krav Udførselsfasegruppen: 5. scenarie: Entreprenør modtager digitalt udbudsmateriale som grundlag for tilbud 6. scenarie: Entreprenør opretter produktionsgrundlag ud fra kalkulation Driftsfasegruppen: 7. scenarie: Driftsherre modtager digitalt materiale som grundlag for drift 8. scenarie: Driftsherre registrerer driftsinformation som grundlag for programmering De otte scenarier fremgår af bilag 3. Scenarierne blev diskuteret ud fra punkterne: overordnet indtryk, it-egnethed, udbredelse og barrierer. Nedenfor gennemgås diskussionen af de enkelte scenarier. Side 15 af 41

3.3.1. Bygherrerådgiver udarbejder rum- og arealprogram for konkurrenceprojekt Scenariet fremgår af bilag 3, s. 1. Scenariet modtages relativt positivt med følgende kommentarer: Fordele og muligheder i scenariet Det er den eneste rigtige måde at gøre det på. Arkitekternes kreative proces skal køre parallelt med processen med at dokumentere rum. cuneco-serveren kunne indeholde eksempler på og erfaringsudveksling om rumprogrammer og herved give inspiration til den kreative proces. Scenariet giver værdi til bygherren: Når der er enighed om definitionen af arealer, bliver processen med at validere indkomne konkurrenceforslag mere ensartet og retfærdig og frigør kræfter til den kreative del. cuneco-serveren giver i scenariet en meget nyttig målbarhed. Man kan pba. rumkategorier og egenskaber visualisere ud fra en enkel volumenmodel, som endnu ikke har defineret rum, og teste fx den energimæssige eller økonomiske effekt af forskellige valgmuligheder. Simuleringer i den tidlige fase giver et godt grundlag for dialog med slutbrugerne. Det kan udvikle sig til et værktøj, hvor man kombinerer og udveksler projektinformation. Det ligger tæt op at et system, der bruges af de store bygherrer i USA. Elementer, der skal overvejes/justeres: Scenariet afspejler ikke virkeligheden, idet trin 1 er en meget iterativ proces, hvor bygherrens ønsker gradvist konkretiseres og omsættes til et byggeprogram. Bygherrens behov er løbende at kunne trykprøve, hvad man er nået frem til i denne proces, og om det matcher de indledende visioner. Den tidlige fase er kreativ og handler om idéudveksling mellem rådgiver og bygherre. Man skal et stykke hen i den første fase, før projektet er tilstrækkelig afklaret til, at rum, rumtyper og brugen af tabeller bliver relevant. Det kan ikke lade sig gøre at standardisere på et niveau, hvor man kan verificere. Man kan måske definere en standard i forhold til bygningstyper og standardrum en template med egenskaber som brugerne kan vælge at lægge ind i deres egen template. Store bygherrer vil under alle omstændigheder arbejde ud fra egne templates. IT-egnethed Scenariet vurderes at være meget it-egnet: Det virker super it-egnet det her Udfordringen er at udforme det på den rigtige måde, så det ikke ødelægger den kreative proces og skaber værdi. Det kræver en masse erfaringer at ramme rigtigt. Side 16 af 41

Barrierer Bygherren skal stille krav til rådgiverne om at benytte den relevante software de store arkitekter gør det af sig selv, men ikke de små og mellemstore. Rådgivernes egeninteresse i scenariet kan være lav, da effektiviseringen af deres processer vil resultere i lavere timeforbrug på deres ydelser og dermed lavere omsætning. 3.3.2.Bygherrerådgiver verificerer krav vedr. arealer og økonomi i konkurrenceprojekt Scenariet fremgår af bilag 3, s. 2. Dette scenarie modtages også positivt i programmeringsfasegruppen dog lidt mindre positivt end det første scenarie med følgende kommentarer: Fordele og muligheder i scenariet Scenariet er med succes gennemført i Norge hos Statsbygg, hvor der blev afleveret modeller i IFC-format til en modelserver, der ud over den beskrevne verifikation også testede energi og placering i omgivelserne. o Det norske system dækkede også særlige sikkerhedskrav. Sådanne krav vil dog ofte ligge i form af tekster/beskrivelser. Scenariet skaber værdi på flere måder: det vil gøre bygherrerne mere klare på, hvad de beder om, hvis de skal forholde sig til nogle strukturer, og denne klarhed gives videre til rådgiverne, hvorved kvaliteten i projektet øges: Man skaber meget ro om et projekt, når man beder om struktureret materiale Samtidig vil den ensartede struktur i de krav, som rådgiverne mødes med i konkurrenceprojekterne, øge effektiviteten på tegnestuerne og gøre det nemmere for dem at aflevere i 3D-modeller. Den beskrevne service kan fungere som bygherrens tjekliste og sikre, at alle rådgivere både store og små kommer igennem de nødvendige krav, hvorved kvaliteten af projekterne løftes. Scenariet skal ses inden for sit eget, afgrænsede scope, (som er verifikation af arealer og ikke arkitektonisk udtryk) og vil i denne sammenhæng give bygherren en meget værdifuld kvalitetssikring af konkurrencematerialet: Scenariet giver en helt uvurderlig kvalitetssikring, når man ikke skal sammenligne bananer og appelsiner Elementer, der skal overvejes/justeres: Der afleveres ikke altid (som scenariet beskriver) til konkurrencer i en 3Dmodel. Hvordan indgår bygherrens øvrige krav i scenariet, fx særlige krav til selve udførslen af byggeriet, krav til specielle rum o.lign.? Disse krav er vigtige, også for økonomien, og må ikke blive glemt i processen. Side 17 af 41

Det beskrevne system kan dække nogle krav, men ikke alle. Hvis systemet ikke dækker det meste (90%) og kræver mange opfølgende manuelle tjek, har det ikke værdi. Det beskrevne scenarie giver god mening, men omhandler kun et delelement i bedømmelsen, hvor bygherren sikrer, at han får det, som han har bedt om mht. rum og arealer. Om konkurrenceforslaget overordnet er godt i forhold til arkitektur, økonomisk sunde valg osv. besvares ikke. Det beskrevne scenarie er ikke så interessant set fra en arkitektsynsvinkel. Det beriger ikke arkitektens processer. It-egnethed Scenariet vurderes indirekte at være it-egnet. Barrierer Scenariet er baseret på 3D-modeller, men der er stadig mange mindre arkitektvirksomheder, som ikke arbejder i 3D. Der findes de nødvendige softwareværktøjer, problemet er branchens mindset. o 3D opfattes af mange som et fordyrende værktøj: Der er en fordom i branchen om, at 3D er svært og koster kassen o Der er dog tilslutning til cunecos synspunkt om, at cunecos kommende standarder vil sænke barrieren og gøre det lettere for de mindre virksomheder at være med, idet de ikke skal opfinde tingene selv. Arkitekterne har gerne meget travlt op mod afleveringen af et konkurrenceprojekt, så man skal passe på med at pålægge dem yderligere krav. Ikke blot af hensyn til deres belastning, men også af hensyn til kvaliteten af det afleverede materiale. Man kan fx risikere, at den afleverede 3D-model og arealbeskrivelserne ikke matcher, idet modellen er ændret i sidste øjeblik. 3.3.3. Rådgiver laver mængdesat tilbudsliste til digitalt udbud Scenariet fremgår af bilag 3, s. 3. Deltagerne i projekteringsfasegruppen kan overordnet se pointen med scenariet og dets bagvedliggende standarder, men har dog en række afklarende spørgsmål og forbehold. Fordele og muligheder i scenariet Fordelen ved scenariet er ikke kun, at der sker mindst muligt gentagelsesarbejde, når det er rådgiveren, der angiver mængder, men også at de udførende undgår en taktisk konkurrence på mængder, og at de udførende får en model, som de kan arbejde videre med i produktionsfasen. Scenariets verifikation (punkt 4) er også relevant i forhold til de første 3 punkter i scenariet: Internt i en virksomhed arbejder forskellige afdelinger med forskellige softwareværktøjer og kan have behov for at tjekke, at der er de rigtige enheder sat på fx i overgangen fra modelværktøj til kalkulation. Side 18 af 41

Scenariet er baseret på fagentrepriseudbud, mens totalentrepriser, OPP og funktionsudbud i fagentrepriser i større grad er fremtidens udbudsformer. Det er dog fornuftigt at starte med at løse de nuværende problemer. Scenariet kan også være relevant ved andre udbudsformer end fagentreprise, hvor det baseres på en model med lavt informationsniveau. Dette indebærer dog, at mængderne ledsages af mange beskrivelser og forklaringer i tekst (som kan danne basis for misforståelser). o Fx ved funktionsudbud kan rådgiveren angive en simpel model med et antal mængder, hvor der ved siden af beskrives mere præcist, hvad der skal gives tilbud på. Dette er dog ikke entydigt, og der mangler et direkte link mellem beskrivelser og tilbudslister. Informationsniveauer skal defineres i forhold til udbudsform, og der skal udvikles og placeres de rette egenskaber. Elementer, der skal overvejes/justeres Det er uklart, hvad punkt 4 dækker over ( cuneco-serveren verificerer, at der er angivet mængder med gyldige enheder for alle poster ). o Svar: et defineret informationsniveau på cuneco-serveren, som fortæller, at når der laves udbud efter den anvendte model, er der nogle bestemte informationer, der skal være angivet, for at det er konditionsmæssigt. Hvem udfører tjekket i punkt 2? ( tjek af, at alle typekoder i eksporten er til stede i bygningsdelsbeskrivelsen ). o Svar: Dette forventes rådgiverens software at kunne gøre på baggrund af cuneco standarder, som er indlejret i softwaren. Hvem har ansvaret i scenariet? cuneco/bips skal som interesseorganisation hellere levere et fast output end fungere som en dynamisk enhed. Hvad nu hvis organisationen ophører med at eksistere? Og pådrager cuneco/bips sig et juridisk ansvar? Cuneco skal ikke have ansvar det skal stadig være rådgivers ansvar. o Svar: Cuneco skal ikke opbevare projekter, kun standarder. Baggrunden for verifikationen er en IDM, der ligger hos cuneco, men den software, der udfører tjekket, skal ikke ligge hos cuneco. Om punkt 4: hvis det skal kontrolleres, at mængderne er rigtige i forhold til modellen, skal modellen så også kommunikeres? o Svar: tanken er blot, at serveren skal tjekke, at de rigtige enheder er anvendt, og hvis der er anvendt egenskabsdata, at det er de rigtige at formalia er i orden. Serveren skal ikke måle op i forhold til en model og tjekke, at det er de rigtige mængder; det vil være en opgave for softwareleverandørerne. Side 19 af 41

Man skal ikke sende en fil frem og tilbage, det skal være en API. Den største udfordring vil være at overbevise brugerne om, at outputtet er rigtigt at softwareprogrammet har anvendt opmålingsreglerne på den rigtige måde. Det skal være muligt at tjekke tjekkeren, så man skal have at vide, præcis hvordan der er målt op. (Ligesom rådgiverne i starten af en BIM-implementeringsproces typisk tjekker modelberegningerne manuelt, indtil de lærer at stole på, at beregningerne udføres korrekt). Man kan som bygherre ikke henvise til, at entreprenøren kan finde supplerende informationer i modellen man er nødt til at beskrive alle mængderne i tilbudslisten. Men det er fornuftigt at sende modellen med, så entreprenøren kan orientere sig i, hvor kompliceret byggeriet er. Scenariet er fastlagt ud fra en gammeldags, banal proces, hvor entreprenøren blot udfører det, han får besked på. Det egentlige problem med mængder og tilbudslister drejer sig ikke om de dumme = nemme mængder, men om de situationer, hvor entreprenøren er med til at fastlægge ydelsen (som A113 illustrerer). cuneco skal ikke levere it-services, men koncentrere sig om at udvikle de fælles standarder, som der er et meget stort behov for, og som i sig selv giver stor værdi for branchen. It-egnethed Softwareleverandørerne i gruppen ser ingen større problemer i forhold til scenariets it-egnethed. Barrierer Hvis de projekterende skal fastlægge brugbare mængder ud fra deres modeller, forudsætter det, at de projekterende har en viden, de formentligt ikke har. Fx har de udførende behov for, at en søjle i et hus er tegnet som en afbrudt søjle, så den kan trækkes ud som enkeltelementer ikke som en hel søjle eller som et stregsystem. o Dette kunne overkommes, hvis udbudsgrundlaget ikke var tilbudslisten, men en ordentlig ifc-model, som de bydende selv skulle trække information ud af. Praksis i dag er stadig, at der er store skotter mellem fasene i byggeprocessen, idet hver part laver sin egen model. Der burde være mere genbrug, uanset hvilket software parterne arbejder i. Man skal ikke forvente, at IFC kommer til at løse udvekslingsproblematikken optimalt - der vil altid være løsninger, som arbejder direkte sammen i de enkelte softwareværktøjer, som virker bedre. Side 20 af 41

3.3.4 Rådgiver laver udtræk til bygherren til verifikation af opfyldelse af krav Scenariet fremgår af bilag 3, s. 4. Scenariet får en blandet modtagelse med følgende kommentarer: Fordele og muligheder i scenariet Scenariet er genkendeligt og svarer til nuværende processer. Det er en god måde for rådgiveren til at få tjekket, om projektet lever op til de stillede krav. o IFC fungerer ikke perfekt, men er nødvendigt, for at parter med hver sin software kan tale sammen. Scenariet beskriver et simpelt tjek, som med tiden kan gøres smartere (ligesom visuel kollisionskontrol har udviklet sig til automatisk kollisionskontrol). cuneco kan evt. fylde indhold i Bygherreforeningens Kravkonfigurator. Elementer, der skal overvejes/justeres Scenariet forudsætter, at bygherren har lavet en digital kravmodel. Dette er imidlertid ikke en alment anvendt arbejdsmetode. Brugen af IFC skal ikke være et must i punkt 1-4, hvor der er tale om interne processer. Konvertering til IFC er en tidskrævende arbejdsproces og vil være fordyrende for projektet. Først i punkt 5, hvor der sker en ekstern udveksling, bør IFC være et krav. Det må være op til rådgiverne selv, hvordan de internt arbejder, dvs. der skal gerne være mulighed for direkte integration med forskellige it-værktøjer. o Muligvis kommer bygherren eller bygherrerådgiveren allerede på banen i punkt 2 og 3, i så fald kan det være fornuftigt at kræve brug af IFC (hvilket dog stadig vil fordyre processen). Scenariet er en pseudo it-problemstilling det virkelige problem er en fælles forventningsafstemning af, hvad der skal ligge som beslutningsgrundlag: hvilke informationer kan bygherren med rimelighed forvente at få? Det vil være fremmende for branchen, at man får lavet et sæt spilleregler i forhold til bygherren, der siger, at han kan forvente at få informationer om dette i denne fase, når han skal træffe beslutninger et redskab, så parterne kan få en dialog. o cuneco skal starte med at lave en fælles standard for krav ikke udvikle et lille værktøj til at verificere krav. 3.3.5. Entreprenør modtager digitalt udbudsmateriale som grundlag for tilbud: Scenariet fremgår af bilag 3, s. 5. Scenariet modtages meget positivt i udførselsfasegruppen med følgende kommentarer: Fordele og muligheder i scenariet Scenariet giver mange fordele for entreprenørerne: o Entreprenørerne vil kunne spare meget tid. Side 21 af 41

o o Det ensartede grundlag at give pris på fjerner usikkerheden. Man kan arbejde ud fra et mere informeret grundlag og herved skabe en mere optimal byggeproces. Scenariet kan og bør sættes i gang nu. Cuneco skal så hurtigt som muligt udvikle de nødvendige standarder for, at scenariet kan lade sig gøre. Der arbejdes i Norge på den beskrevne facon. Dele af scenariet kan realiseres nu, andre dele først på længere sigt. Scenariet kan godt sættes i gang nu, det er blot et spørgsmål om på hvilket niveau. cuneco skal gå i gang med en basal model, og så kan niveauet løftes hen ad vejen: Tag små steps, så det er til at håndtere : o En standard for digitale tilbudslister kan laves med det samme i excel, hvor mængderne skal stå i samme kolonne hele vejen ned o.lign. Dette kan de fleste systemer læse ind. o På længere sigt skal pdf erne væk, men et første step kunne være at opdele tilbudsmaterialet i det kontraktligt gældende, som pdf es, mens det øvrige materiale fungerer som støttemateriale. (Det foretrækkes dog allerede til en start at arbejde med redigerbare excellister). o At anvende IFC-viewere er en god måde at komme i gang på, men kan blive en begrænsning på et tidspunkt. o Rådgiver kan udbyde med de overordnede mængder (jf. nedenfor) jo mere overordnede, jo nemmere er det at komme i gang. Elementer, der skal overvejes/justeres Der bruges mange forskellige it-værktøjer til at udarbejde et udbudsmateriale med, dvs. det er komplekst at få det til at spille sammen men ikke umuligt. Rådgiverne kan i praksis kun udregne de overordnede mængder (fx gulvarealer, antal vinduer og kvadratmeter gipsvæg, ikke detaljer omkring overfladebeskrivelser, befæstelser, o.lign.). Det er således i realiteten begrænset, hvor mange informationer rådgiver kan bære ind i bygningsmodellen. cuneco skal erkende, at ikke alle informationer vil komme fra IFCmodellen og finde ud af, hvordan dette skal håndteres i praksis. o Selv med denne begrænsning vil scenariet være en kæmpe gevinst for de bydende. It-egnethed Scenariet giver ikke de store it-mæssige udfordringer. Mange af elementerne findes allerede i dag og skal blot bindes sammen Teknikken er på plads til det meste i scenariet: Punkt 1-4 findes, mens der skal bygges noget nyt op til punkt 5 og 6. Man skal starte med at lave en nem definition i excel. Side 22 af 41

Barrierer Ansvar for mængder: Hvem har ansvar for opmåling og mængder: udbyder eller de bydende? o Rådgiverne bør angive og have ansvar for de overordnede mængder, så alle byder på det samme grundlag. Hvis mængdeangivelsen senere viser sig at være forkert, må bygherren betale for de ekstra mængder. Ansvar for modellen: Rådgiverne har ikke lyst til at give modellen videre til entreprenørerne, hvis de har ansvar for den. o Barrieren kan på kort sigt overvindes ved, at det gøres klart, at modellen blot følger med som supplerende støtteinformation, mens den kontraktligt gældende information ligger i pdf-filerne. Alene dette vil være en stor hjælp for de udførende, som får meget større indsigt i projektet: Det giver så meget bedre viden og en bedre dialog i begyndelsen af processen, så byggeriet kan optimeres. Selv de halvdårlige modeller sparer os penge. o Bygherren bør stille krav til rådgiverne om, at de stiller modellen til rådighed på denne måde. Niveauet for tilbudslisten og for IFC-modellen kan følges ad: simpel tilbudsliste + simpel model vs. detaljeret tilbudsliste + detaljeret model. Ophavsrettigheder til modellen: Hvad sker der med rådgivers rettigheder til modellen, hvis den sendes ud i et åbent format? Scenariet er tænkt ud fra Bygherrekravene i Det Digitale Byggeri. Branchen har imidlertid vænnet sig til, at kravene fra Det Digitale Byggeri stilles uden at blive stadfæstet (ingen sanktioner, hvis de ikke overholdes) og er derfor ikke motiveret for at opgradere medarbejderne. Manglende viden om BIM på tværs af branchen. o Bygherrerne ved for lidt om BIM og stiller derfor ikke krav om anvendelsen eller er for uspecifikke i deres krav. o Der mangler en informationsniveau-standard, som hjælper bygherrerne med at stille krav til rådgivernes BIM-model, så der fastlægges det rigtige niveau, og modellen gøres egnet til at give videre til de udførende. 3.3.6. Entreprenør opretter produktionsgrundlag ud fra kalkulation Scenariet fremgår af bilag 3, s. 6. Scenariet kræver lidt mere forklaring end det foregående, men opfattes klart som interessant og relevant for entreprenørerne: Det giver supergod mening. Fordele og muligheder i scenariet Ideen i scenariet er at omarbejde kalkulationsinformation til produktionsinformation og på en nem måde få brugbar information ud til svendene. Side 23 af 41

o o Målet med scenariet er ikke at skabe et menneskeforbudt område, tværtimod er der behov for menneskelige vurderinger. Kalkulationsinformationen bidrager med ca. 80% af informationen i produktionskortet, mens den øvrige information vurderes i den enkelte situation af byggelederen, som pba. sin erfaring og metode justerer nettomængderne. Produktionskortet skal i sidste ende gerne findes i 3D og kunne medbringes på ipad. Elementer, der skal overvejes/justeres Udvælgelsen af konkrete produkter sker i scenariet i punkt 4 i praksis sker det imidlertid ofte allerede i kalkulationsprocessen, som går forud for scenariet, idet man har behov for de konkrete produkter for at kunne fastlægge prisen. I andre tilfælde fastlægges produkterne dog først senere som led i en optimeringsproces. It-egnethed Scenariet er it-egnet, men kræver, at mange forskellige elementer fungerer. Man skal derfor arbejde ud fra en tankegang om, at lidt bidrager med meget Det er ikke uden vanskeligheder at indlæse projektmaterialet, ligesom ændringer i projektmaterialet kan skabe problemer. Der skal laves link ud i klassifikation og egenskabsdata, så fx systemet automatisk kan hente præcis den rigtige monteringsanvisning (dette handler dog mere om klassifikationskoder end om it). Alternativt skal monteringsanvisninger hentes manuelt, hvilket dog ikke ødelægger scenariets værdi. Barrierer Scenariet kræver, at producenterne har knyttet klassifikationskoder på deres objekter. o Måske vil rådgivere og entreprenører på sigt bruge dette som udvælgelseskrav i forhold til produkterne? o Kan scenariet indfris ved, at producenterne sætter stregkoder på de solgte produkter, så håndværkerne kan kontakte producenten og få information om det specifikke produkt? Vil svendene føle, at de får begrænset deres frihed, eller vil de synes, det er rart at få skåret ud i pap, hvad de skal bygge? 3.3.7. Driftsherre modtager digitalt materiale som grundlag for drift Scenariet fremgår af bilag 3, s.7. Scenariets slutresultat at data afleveres digitalt i en relevant struktur vurderes meget positivt blandt driftsherrerne, mens der er diskussion om selve metoden. Deltagerne har således følgende kommentarer til scenariet: Side 24 af 41