HÅNDTERING AF DIGITALE BYGGEOBJEKTER

HÅNDTERING AF DIGITALE BYGGEOBJEKTER 7. SEMESTER SPECIALE SIGMUNDUR FRÝDAHL HYLLESTAD VEJLEDER: DEE DLAMINI BYGNINGSKONSTRUKTØRUDDANNELSEN VIA UNIVERSITY COLLEGE, CAMPUS ÅRHUS 04-04-2014

TITELBLAD RAPPORT TITEL: Håndtering af digitale byggeobjekter VEJLEDER: Dee Dlamini FORFATTER: Sigmundur Frýdahl Hyllestad DATO/UNDERSKRIFT: 04-04-2014 STUDIENUMMER: 179851 OPLAG: Digital publicering SIDETAL (à 2400 anslag): 27,8 sider = 66.627 anslag GENEREL INFORMATION: All rights reserved - ingen del af denne publikation må gengives uden forudgående tilladelse fra forfatteren. BEMÆRK: Dette speciale er udarbejdet som en del af uddannelsen til bygningskonstruktør alt ansvar vedrørende rådgivning, instruktion eller konklusion fraskrives Side 1 af 33

Forord Denne rapport er udarbejdet som afsluttende speciale til bygningskonstruktøruddannelsen på VIA University College i Århus, foråret 2014. Rapportens formål er at belyse hvordan objekthåndtering og klassifikation, samt egenskabsdata kan anvendes i en byggesag, og hvordan aftaleforholdene skal se ud for at opfylde IKT-bekendtgørelsens 4. I den forbindelse vil jeg i særdeleshed takke Martin Romby fra Århus Arkitekterne og Jacob Güldner fra Grontmij for at stille op til interviews der har været essentielle for denne rapports udarbejdelse. Derudover vil jeg takke min vejleder Dee Dlamini, samt mine medstuderende for indsigt og viden der har gjort rapportskrivningen lettere. En tak skal også rettes til min kæreste Mette for at være behjælpelig med korrekturlæsning. Side 2 af 33

Abstract This is the final report for the education to become a constructing architect. My problem statement has been how the building industry can live up to the demands in the ICT-announcement 4 which is about object management and classification in a digital building scenario. I have researched why BIM and ICT is necessary, digital objects, classification systems and how ICT agreements should be made. My findings has been that BIM has a great potential for cost savings in all aspects of the building process, provided that the proper agreements are made and that the participants live up to that which is agreed upon. Furthermore I have found that technical ability and soft- and hardware has to be on a sufficient level to reap the benefits of BIM. Side 3 af 33

Indholdsfortegnelse 1 Indledning... 7 1.1 Baggrundsinformation og præsentation af emne... 7 1.2 Begrundelse for emnevalg og fagligt formål... 7 1.3 Problemformulerings spørgsmål... 7 1.4 Afgrænsning... 7 1.5 Valg af teoretisk grundlag og kilder... 8 1.6 Valg af metode og empiri... 8 1.7 Rapportens struktur og argumentation... 8 2 IKT og BIM i byggeriet... 8 2.1 IKT-bekendtgørelserne... 8 2.2 Udfordringer og muligheder ved digitalt byggeri... 9 2.3 BIM i bygningens livscyklus... 10 2.3.1 BIM, BAM, BOOM... 11 2.4 Case: UCC Nordsjælland... 12 2.4.1 Gevinster ved modelbaseret projektering, udførsel og drift... 12 2.4.2 Risici... 12 2.4.3 Resultater... 13 2.5 Delkonklusion... 13 3 Digitale byggeobjekter... 14 3.1 Definition af objekter... 14 3.1.1 Komponent objekter... 15 3.1.2 Rumobjekter... 15 3.1.3 Systemobjekter... 15 3.1.4 Abstrakte objekter... 15 3.2 Håndtering af byggeobjekter... 15 3.3 Objektdatabase... 16 3.4 Objekthåndtering på DNV Gødstrup... 16 3.5 Delkonklusion... 17 4 Klassifikationssystemer... 17 4.1 Samarbetskomitén för Byggnadsfrågor (SfB)... 18 4.2 Dansk Bygge Klassifikation (DBK)... 18 Side 4 af 33

4.3 Cuneco Classification System (CCS)... 19 4.3.1 Klassifikationstabeller... 19 4.3.2 CCS aspekter... 19 4.3.3 Kodeeksempel... 20 4.4 Forvaltning Klassifikation (FK)... 20 4.4.1 Kodens opbygning... 21 4.4.2 Kontoplaner... 21 4.5 Mappingtabeller... 22 4.6 Sammenligning af systemerne... 22 4.7 Delkonklusion... 23 5 Egenskabsdata... 23 5.1 Bips C214... 24 5.1.1 Dynamiske og Konstante egenskaber... 24 5.1.2 Type- og forekomstegenskaber... 24 5.2 Relevante egenskaber ift. drift og vedligehold... 24 5.3 Egenskabsdata i praksis... 25 5.4 Delkonklusion... 26 6 Koordinering af IKT... 26 6.1 Danske Ark og FRIs Ydelsesbeskrivelse 2012... 26 6.2 Bips F102 Byggeriets IKT-specifikationer... 26 6.2.1 Ydelsesspecifikation... 27 6.2.2 IKT-teknisk specifikation... 27 6.3 Information Delivery Manual... 28 6.4 Kontraktgrundlag i praksis... 29 6.5 Delkonklusion... 29 7 Konklusion... 29 7.1 Perspektivering... 30 7.2 Metodekritik... 31 8 Referencer... 32 9 Bilag... 33 Side 5 af 33

Billedliste Figur 1. Fordelene ved BIM stiger over tid og kan give store besparelser i projektering, udførsel og drift.... 11 Figur 2. Diagram der viser arbejdsgangen i at linke bygningsmodellen med projektbiblioteket. Databasen indeholder alle informationer om projektet, og kan trækkes ud til de fagspecifikke modeller, kalkulationsark, tilbudslister osv.... 17 Figur 3. Egenskaber fortæller noget om objekterne i projektet bips.... 23 Figur 4. Eksempel på udfyldelse af punkt 2.4 i ydelsesspecifikationen, med uddybning af særlige forhold... 27 Figur 5: Tabel fra bips F102. Sammenhæng mellem IKT-projektspecifikke paradigmer og deres målgrupper.... 28 Side 6 af 33

1 Indledning 1.1 Baggrundsinformation og præsentation af emne Denne rapport er udarbejdet som 7. semesters speciale på bygningskonstruktøruddannelsen i Århus. Emnet for specialet tager afsæt i 4 af IKT-bekendtgørelserne, og omhandler rådgiverens strukturering og klassificering af digitale byggeobjekter. 1.2 Begrundelse for emnevalg og fagligt formål Mange tegnestuer har ikke en struktureret håndtering af deres digitale byggeobjekter. Fra mit praktiksted i Tórshavn, Færøerne ved jeg at det kan være en udfordring at at arbejde med 3D-bygnignsmodeller hvis man er vant til 2D-tegninger. I IKT-bekendtgørelsernes 4 stilles der krav om struktureret håndtering af digitale byggeobjekter i offentligt byggeri. Så hvis de tegnestuer fortsat vil være konkurrencedygtige på større kommunale- og almene byggerier, kræver det en strategi for håndtering af digitale byggeobjekter. Udover at opfylde kravet, vil en struktureret håndtering forhåbentlig også bevirke at tegnestuen får et mere effektivt workflow i udarbejdelsen af deres 3D-modeller, med økonomisk gevinst til følge. Formålet med denne rapport er, at undersøge hvordan en tegnestue kan forbedre sin håndtering af digitale byggeobjekter, gerne på en måde så det er realistisk for mindre tegnestuer at være med. 1.3 Problemformulerings spørgsmål Med udgangspunkt i IKT-bekendtgørelsernes 4 har jeg valgt at mit hovedspørgsmål skal være: Hvorfor skal digitale byggeobjekter struktureres, og hvordan kan struktureringen forbedres så kravene i IKT-bekendtgørelsernes 4 kan overholdes? 1.4 Afgrænsning Jeg har valgt at mit fokus skal være på håndtering af digitale byggeobjekter hos rådgiveren. Derfor vil jeg i rapporten ikke komme ind på hvordan håndtering foregår ved drift og vedligehold, bygherrer, entreprenører og producenter. Det skyldes at rådgiverens bygningsmodel helst skal kunne ligge til grund for de andre aktørers arbejde, og derfor spiller en central rolle for entreprenørens beregning af tilbud eller styring af drift og vedligehold. Det vil sige at en vellykket byggesag starter med at rådgiveren har en gennemtænkt BIM-strategi, og derfor er min vurdering at jeg personligt vil få mest ud af at udarbejde rapporten fra rådgiverens synsvinkel. Grunden til at det er 4 jeg beskæftiger mig med er, at håndtering af digitale byggeobjekter var noget af det der skabte udfordringer i forhold til digitalt byggeri hos min praktikvirksomhed. Derfor vil jeg ikke fokusere på de andre paragraffer, selvom de utvivlsomt også har stor relevans for IKT i byggeriet. Side 7 af 33

1.5 Valg af teoretisk grundlag og kilder I Danmark er det bips og Cuneco der står for udviklingen af digitalt byggeri, derfor vil mit teoretiske grundlag i høj grad stamme fra rapporter, artikler og oplæg derfra. Bips er en medlemsdrevet non-profit forening, hvor medlemmerne består af aktører fra byggebranchen. Cuneco ledes af bips og er et udviklingsprojekt til fremme for produktivitet i byggeriet. 1.6 Valg af metode og empiri Ved hjælp af interviews vil jeg forsøge at få et overblik over problemstillingen, og forhåbentlig være i stand til at analysere mig frem til, hvilke udfordringer der kan være med håndteringen af digitale byggeobjekter. Jeg vil primært lave interviews hos større rådgivningsfirmaer, som jeg ved har en metode til objekthåndtering og klassifikation. Udover det vil jeg studere relevante rapporter og artikler inden for feltet og sammenholde med mine egne data. Den indsamlede data kommer primært til at være kvalitativ, da mine interviews skal hjælpe mig til at forstå de forskellige metoder til strukturering af digitale byggeobjekter. Det vil sige at mine kilders udsagn kommer til at spille en central rolle i rapportens grundlag. 1.7 Rapportens struktur og argumentation I det første kapitel opstilles rammerne for rapporten hvor med problemformulering og afgrænsning, desuden redegøres der for valg af metode og empiri. I hovedafsnittet vil jeg fremsætte den relevante teori til forståelse af emnet. Jeg anvender interviews, rapporter eller artikler som kilder til at belyse problemstillingen, for at have et grundlag for min analyse og konklusion. Teori- og empiriafsnittene tager udgangspunkt i IKTbekendtgørelsernes 4, så de begreber der nævnes i 4 også vil blive behandlet i rapporten. I konklusionen vil jeg opsummere mine undersøgelser og forsøge at udpege hvilke udfordringer og muligheder der er i forhold til klassificering og objekthåndtering. 2 IKT og BIM i byggeriet Med introduktionen af BIM som arbejdsmetode ændres projekteringsprocessen i forhold til den traditionelle proces. Det afføder blandt andet at der opstår behov for koordinering af IKT-forholdende, for at kunne udnytte potentialet i BIM. I forbindelse med offentligt og alment byggeri findes der lovkrav som bygherren skal stille til en given byggesag. 2.1 IKT-bekendtgørelserne Den 1. april 2013 trådte de nye bekendtgørelser vedrørende IKT i kraft. De to bekendtgørelser, BEK nr. 118 og BEK nr. 119 er udgivet af henholdsvis Klima-, Energi- og Bygningsministeriet og Ministeriet for By, Bolig og Landdistrikter og vil i det følgende samlet blive kaldt IKT-bekendtgørelserne. Bekendtgørelserne omhandler henholdsvis offentligt og alment byggeri. De økonomiske grænseværdier for hvornår bekendtgørelserne er gældende er angivet i de tre første paragraffer. For alment byggeri er grænsen 20 mio. kr. og for offentligt byggeri er grænsen 5 mio. kr. Side 8 af 33

Herefter er ordlyden af de resterende paragraffer ens. Bekendtgørelserne angiver de IKTkrav som bygherren skal stille i byggesagerne, med det formål at bygherren skal få mest muligt for pengene. Denne rapport omhandler primært 4 med følgende ordlyd: 4. Bygherren skal stille krav om, at digitale byggeobjekter gennem hele byggesagen struktureres, klassificeres, navngives, kodes og identificeres ensartet i en nærmere bestemt detaljeringsgrad. Bygherren skal i den forbindelse stille krav om, at byggeobjekterne forsynes med de informationer og egenskaber, der er relevante for den efterfølgende forvaltning, drift og vedligehold. Stk. 2. Bygherren skal sikre, at der fastsættes retningslinjer for håndteringen af digitale byggeobjekter gennem hele byggesagens forløb. (Retsinformation, 2014) Paragraffen betyder, at bygherren skal stille krav om, at de digitale byggeobjekter i projektet skal håndteres ensartet for, at projektets informationer kan udveksles så effektivt som muligt, det vil sige at der skal anvendes et klassifikationssystem, for eksempel SfB eller CCS. Desuden skal byggeobjekterne struktureres så der er overblik over dem, for eksempel ved at anvende en objektdatabase, hvor alle objekter er sorteret ud fra det valgte klassifikationssystem. Desuden skal der stilles krav til at modellen indeholder information er der relevant, for at bygherren efter aflevering har et grundlag for at udføre drift og vedligehold i et egnet IT-system. Stk. 2 i paragraffen skal sikre at der er entydige retningslinjer for hvordan digitale byggeobjekter håndteres, så der ikke opstår uenigheder i løbet af projektet. Dette kan for eksempel sikres gennem udarbejdelse af IKT-aftaler, der angiver hvem der har ansvar for hvilke IKT-områder i byggesagen. 2.2 Udfordringer og muligheder ved digitalt byggeri I rapporten De udførende virksomheders potentiale, udfordringer og krav til digitalt udbud fra juni 2012 udgivet af Dansk Byggeri konkluderes det blandt andet at der mangler en standardiseret struktur for udbudsmaterialet. Det bevirker at den digitale tilbudsproces ikke fungerer optimalt. Det vil sige at den bydende går glip af nogle besparelser, der i sidste ende ville komme bygherren til gode, fordi tilbudspriserne vil blive lavere. Rapporten er udarbejdet da IKT-bekendtgørelsen fra 2010 var gældende, men alligevel fremhæves nogle punkter der er relevante for 4. Dette er blandt andet, at der skal være standarder og struktur for information og data i tilbudsmaterialet. Desuden skal 3D bygningsmodeller indeholde information og data om bygningsdele, derudover skal bygningsdelene være entydigt identificerbare (Dansk Byggeri, 2012). For entreprenørens vedkommende er det vigtigste at bygningsdelene er kodet systematisk og konsekvent. mener Kristian Birch fra Exigo Consult der rådgiver entreprenører i BIM (bips nyt, 2013). I samme artikel nævner han at det er underordnet Side 9 af 33

hvilket klassifikationssystem man bruger så længe der bliver kodet ensartet. En korrekt kodet model kan være grundlag for udarbejdelse af bemandingsplaner og mængdeberegning. Kristian Birch udtaler: Hvis 80-90 % af bygningsdelene er klassificeret korrekt, så er der tale om en succes. Desværre er det modsatte tit tilfældet. (Kristian Birch) Han forklarer endvidere at en utilstrækkeligt struktureret model medfører ekstraarbejde, hvis den skal anvendes af entreprenøren, og ofte vil det kunne betale sig at tegne modellen op fra bunden. Bygherren skal specificere hvilke IKT-ydelser der ønskes i byggesagen, men selvom det er gjort klart i kontraktgrundlaget er det ikke sikkert at rådgiverne overholder kravene mener Kristian Birch. Det kan skyldes at rådgiveren mangler den fornødne viden om IT-systemerne til at kunne opfylde kravene. Desuden kan det skyldes at rådgiveren udfører bygningsmodellen så dens informationer kan anvendes i deres egen projektering, men ikke som datagrundlag for tilbudsberegning (Dansk Byggeri, 2012). I et interview med Jacob Güldner (Bilag 2) påpeger han, at honoraret skal følge med de ekstra ydelser og ansvar der pålægges rådgiveren i forbindelse med en BIM-baseret arbejdsmetode. Så selvom rådgiveren har de nødvendige kompetencer, skal det afspejles i honoraret, for at det giver mening for rådgiveren at medtage ydelsen. For at rådgiveren skal have muligheder for at leve op til bygherrens IKT-krav kræver det desuden investering i efteruddannelse og software. Det kan være en bekostelig affære, men det er nødvendigt for at virksomheden fortsat skal kunne byde på større offentlige og almene opgaver. I et interview med Martin Romby (Bilag 1), BIM-koordinator hos Aarhus Arkitekterne udtaler han: hvad vil du helst; vil du smide 200000 kr. efter noget software og uddannelse. Eller vil du stå tilbage og ikke kunne byde på nogen projekter? (Martin Romby) Han uddyber ved at sige at private bygherrer efterhånden vil få øjnene op for at arbejde mere og mere digitalt. Så hvis man ikke foretager investeringerne i tide risikerer man at virksomheden dør, da man vil være udelukket fra at kunne byde på et stort antal projekter. 2.3 BIM i bygningens livscyklus I den danske byggebranche anslås det at udgifterne til et byggeri kan fordeles i forholdet 1:10:89, på henholdsvis projekterings-, udførsels- og driftsfasen. Det vil sige at 1 % af udgifterne går til projektering, 10 % går til udførsel og 89 % går til drift og vedligehold fordelt over hele bygningens levetid. Forholdet 1:10 er regnet ud fra at rådgivningsomkostninger cirka svarer til 10 % af byggesummen. Forholdet 10:89 er et gennemsnit udregnet fra en bygnings levetid på 30, 50 eller 100 år. Det vil sige at der findes et stort besparingspotentiale hvis man kan optimere driftsfasen. Udregningerne er teoretiske, men giver et billede af det potentiale der ligger i BIM i forhold til facilities management (FM), hvis processen optimeres. Side 10 af 33

Ved at man fra starten indtænker brugen af bygningsmodellen til drift og vedligehold kan informationerne i modellen overføres til bygherrens driftssystem og dermed bruges til at styre driften (Hermund, 2011). 2.3.1 BIM, BAM, BOOM Patrick MacLeamy, administrerende direktør i arkitekt-/ ingeniørfirmaet HOK, forklarer princippet med BIM i hele bygningens levetid ved at omkostningerne i udførslen er 20 gange projekteringsomkostningerne og omkostningerne i driftsfasen er 60 gange projekteringsomkostningerne, hvilket tillempet giver forholdet 1:25:74. Hans holdning er at det virkelige potentiale ved BIM ikke ligger i projekteringen, men ligger i udførsels- og i særdeleshed i driftsfasen. Dette udtrykker han ved begreberne BIM, BAM, BOOM. Hvor BIM er den model der bruges i projekteringen. BAM står for Building Assembly Model (BygningsSamlings Model) og bruges til planlægning, koordinering af underentreprenører og så videre. Patrick MacLeamys holdning er at brugen af BIM og BAM samlet kan give en besparelse på op til 30 % på byggeomkostningerne. Ved at udnytte modellerne fra de tidligere faser kan bygherren optimere driften ved hjælp af en driftsmodel, som Patrick MacLeamy kalder BOOM der står for Building Operation and Optimization Model, (Bygnings Drift og OptimeringsModel) og bruges til styring af energiforbrug og planlagt vedligehold. Han mener at der i driften kan spares nok penge til at betale for en stor del af byggeriet. Potentialet i BIM, siger han er at man får bedre design, bedre udførsel og bedre drift (HOK, 2010). Figur 1. Fordelene ved BIM stiger over tid og kan give store besparelser i projektering, udførsel og drift. Side 11 af 33

2.4 Case: UCC Nordsjælland I 2012 finansierede Klima-, Energi-, og Bygningsministeret et forskningsprojekt der blev udført af DTU Byg, med det formål at måle de økonomiske gevinster i Det Digitale Byggeri (DTU Byg, 2012). I den forbindelse blev der udarbejdet en case omhandlende BIM hos driftsherre og byg- og driftsherrerådgiver. Casen følger byggeriet af Campus Nordsjælland i Hillerød, et 5500 m² stort campusbyggeri til University College Capital Nordsjælland (UCC Nordsjælland). I casen fungerer bygherrerådgiveren, Archiwise, som konsulent i forhold til 3D-arbejdsmetoden, hvor bygherren mangler de fornødne kompetencer. Der er omkostninger forbundet med implementeringen af IKT-konceptet som man ikke ville have hvis projektet blev udført på traditionel vis. Archiwise skal honoreres med 695.000 kr. for de IKT-ydelser der er i casen. Desuden skal driftsherren investere i brugertræning samt hard- og software, hvilket er opgjort til 520.000 kr. Disse investeringer er nødvendige for at kunne understøtte det leverede IKT-koncept. Desuden er driftsomkostninger i den forbindelse opgjort til 70.000 kr. årligt. Den samlede anlægssum er cirka 65. mio. kr. De målte gevinster er hæftet med en vis usikkerhed og er baseret på erfaringer fra tidligere projekter. 2.4.1 Gevinster ved modelbaseret projektering, udførsel og drift I projekteringen er der gevinster at hente blandt andet ved at den modelbaserede projektering gør det nemmere at opdage fejl i projektet, hvilket har medført en anslået gevinst på 1.200.000 kr., fordi man på et tidligt stadie har rettet fejl der ellers ville komme på byggepladsen. Der er også gevinst at hente ved at indtænke drift i 3D-modellen fra starten, da man dermed har mulighed for at styre driftsdata mere effektivt. Gevinsten er på 250.000 kr. I udbuds- og tilbudsfasen er der også gevinster at hente, blandt andet ved at den modelbaserede projektering har givet et bedre datagrundlag og dermed en 7.560.000 kr. lavere tilbudspris, hvilket svarer til 15 % af entreprisesummen I udførslen er der en gevinst at hente på 307.000 kr. fordi 3D-modellen kan bruges til at styre hvilke leverancer der er udført, hvilket medfører en bedre økonomistyring. I drift og vedligehold findes den største gevinst for bygherren, da det er vurderet at udgifterne mindskes med 15 % til D&V. Det svarer til 5.500.000 kr. årligt for drift og 3.500.000 kr. for vedligehold. Alle disse gevinster er noget der kommer bygherren til gavn. Derudover er der andre gevinster der tilfalder rådgiver og entreprenør, samt gevinster der ikke er prissat. For eksempel bedre generering af tilbudslister, kompetenceløft hos driftsherren i forhold til driftsmodeller og bedre overblik ved projektændringer. 2.4.2 Risici Ved implementering af nye arbejdsmetoder vil der være risikomomenter at tage højde for. Side 12 af 33

I projekteringen kan det være svært at koordinere informationer mellem fagene. Dels fordi der kan være forskellige kompetenceniveauer i virksomhederne, og fordi parterne ikke nødvendigvis anvender samme software. Begge dele er noget der kan risikere at hæmme dataudveksling mellem fagene. Desuden er rollefordelingen anderledes, hvilket også besværliggør IKT-koordineringen. I forbindelse med udbud og tilbud vil en mangelfuld bygningsmodel medføre fejl i mængdeudtag, derfor skal man sikre at modellen er struktureret på en sådan måde at den kan anvendes til formålet. Desuden kan der være manglende ansvarsfordeling i den forbindelse, da rådgiveren sjældent er villig til at påtage sig ansvaret for mængdeudtag hvis det ikke honoreres. I udførslen risikerer man at entreprenøren og den der leverer IKT-ydelserne ikke får kommunikeret optimalt, hvis rollefordeling og aftaleforhold ikke er på plads. Desuden kan det være en hæmsko hvis entreprenøren ikke har det rette soft- og hardware på byggepladsen. I forbindelse med drift og vedligehold kan det være vanskeligt, at finde medarbejdere der kan arbejde med modelbaserede værktøjer, fordi udbuddet af uddannelser på området er meget beskedent. Desuden findes der ikke branchestandarder på området, hvilket kan gøre det svært at overføre data mellem systemerne. 2.4.3 Resultater Når en ny arbejdsmetode skal implementeres kræver det en investering i hard- software og opkvalificering af medarbejdere. Samtidig er der nogle risikomomenter man skal tage højde for, for at få mest muligt udbytte af de gevinster der er at hente. I casen er omkostningerne til implementering anslået til 938.000 kr. og de målte gevinster der tilfalder driftsherren er 18.317.000 kr. Dette resulterer i en nettogevinst for driftsherren på 17.397.000 kr. over en periode på 15 år, forudsat at datagrundlaget er tilstrækkeligt og at det vedligeholdes. 2.5 Delkonklusion Der ligger et stort potentiale i at anvende BIM gennem hele bygningens levetid. Særligt i forbindelse med drift og vedligehold er der store gevinster at hente, da en bygning skal vedligeholdes over mange år. Ved at anvende driftsdata leveret fra rådgiver og entreprenør til driftsherrens driftssystem, er der mulighed for at optimere processerne i forbindelse med drift og vedligehold. I projekteringen og udførslen er der også gevinster at hente ved at det er muligt at skabe mere ensartet projektmateriale, hvilket blandt andet gør det muligt at opdage fejl tidligere og kalkulere priser mere præcist. For at udnyttet potentialet i BIM kræver det dog at aktørerne besidder de fornødne kompetencer. Det er gældende hos rådgiverne, fordi det er hos rådgiveren at processen starter, hvilket vil sige at hvis rådgiverens arbejde med BIM ikke er godt nok, kan entreprenøren og bygherren ikke bruge bygningsmodellerne og informationerne som de er Side 13 af 33

tiltænkt. Entreprenøren må også have BIM-kompetencer for at kunne anvende bygningsmodeller som grundlag for tilbudsgivning og processtyring i udførslen. Bygherren må også have de fornødne kompetencer for at anvende de informationer der leveres til driftsmodellen. BIM-implementeringen kræver investering i software, hardware og uddannelse. Men det er nødvendigt for at kunne opfylde IKT-bekendtgørelsernes krav. For rådgivere og entreprenører kan det handle om virksomhedens overlevelse, fordi man risikerer at blive udelukket fra at byde på projekter hvis man ikke har de fornødne BIM-kompetencer. 3 Digitale byggeobjekter I 4 af IKT-bekendtgørelserne stilles der krav om håndtering af digitale byggobjekter. Formålet er at projekterende, udførende og bygherrer i så stort et omfang som muligt har adgang til information om byggeobjekterne. Desuden skal informationerne let kunne overdrages til driftsherren ved byggeriets aflevering. Ved at anvende en ensartet struktur udnyttes fordelene ved BIM, fordi alle objekter kan genfindes og anvendes flere steder, for eksempel på tilbudslister og i beskrivelser (MBBL, 2013). 3.1 Definition af objekter Når man arbejder med BIM opbygges den digitale bygningsmodel af objekter. I modsætning til 2D CAD eller håndtegninger, indeholder objekterne oplysninger om bygningen. Det vil sige at objekterne ikke bare er geometri der repræsenterer bygningen visuelt. Objekterne siger også noget om bygningens egenskaber, for eksempel U-værdi eller brandklasse. I BIM terminologi er et objekt ikke kun bygningsdele, det kan også være mere abstrakte ting. For eksempel kan et rum anses som et objekt i bygningsmodellen som kan indeholde egenskaber. På samme som 3D-objekter indeholder egenskaber, findes der også 2D-objekter der også kan have egenskaber tilknyttet. 2D-objekter anvendes kun i detaljetegninger, men kan låses sammen med 3D-geometrien. Det betyder at når et objekt ændres, vil 2D-objektet tilpasse sig de nye forhold, så man på den måde hele tiden har opdaterede detaljetegninger. Et objekt kan derfor defineres som en forekomst i bygningsmodellen som indeholder information om byggeriet. Denne måde at arbejde på er objektbaseret, fordi egenskaberne tilknyttes objektet og derefter kan trækkes ud og bruges i forskellige softwaresystemer. Det står i modsætning til at arbejde dokumentbaseret hvor egenskaberne beskrives i dokumenter og dermed ikke er tilknyttet objekterne i bygningsmodellen (MBBL, 2013). I bips publikation C214, Guide om objekter skelnes der mellem fire forskellige typer objekter: Komponentobjekter, bygningsdele Rumobjekter, brugsrum Systemobjekter, delsystemer Abstrakte objekter, modelleringsværktøj Side 14 af 33

3.1.1 Komponent objekter Hovedparten af de bygningsdele som bygningsmodellen udgøres af, kan betegnes som komponentobjekter. Det kan for eksempel være objekter, som er bygget op af lag så som vægge, dæk eller tage. Det kan også være selvstændige objekter, så som døre eller vinduer. 3.1.2 Rumobjekter Rumobjekter er en mere abstrakt objekttype, da disse ikke eksisterer fysisk, men afgrænses af modellens bygningsdele. Grunden til at de er til stede i modellen er, at man, på lige fod med andre objekter, kan tilknytte relevante egenskaber, så som anvendelseskategori eller areal. 3.1.3 Systemobjekter Visse objekter er sammensat af flere underobjekter og af praktiske årsager vil det være mere effektivt at modellere det som et objekt. En curtain wall er et eksempel på et systemobjekt, hvor glasset og sprosserne er underobjekter der indgår i systemet. Hvis man skal modellere glas og sprosser for sig, vil det være meget tidskrævende uden at det skaber merværdi for projektet. 3.1.4 Abstrakte objekter Nogle gange har man brug for objekter der hverken er rum eller bygningsdele. Disse kaldes abstrakte objekter, da de ikke eksisterer fysisk, men kun i modellen. Hvis for eksempel har bruge for at vide, hvor mange huller der er af en bestemt type, kan man have et hul-objekt som kan bruges til mængdeudtræk. Det kan også være en angivelse af plads foran en adgangsdør, hvor man ved hjælp af kollisionskontrol vil sikre at man kan komme til med en kørestol. Når et objekt oprettes får det påhæftet en type, som vælges ud fra den template, som objektet oprettes i. Hvis et vinduesobjekt oprettes korrekt vil det for eksempel i Revit have typen Window og det vil derfor optræde i et vinduesskema. Hvis det derimod ikke er oprettet korrekt vil objekt have en forkert type og dermed blive sorteret i det forkerte skema. 3.2 Håndtering af byggeobjekter I en objektbaseret arbejdsproces vil man ideelt set ikke have brug for klassifikation, da informationer kan udveksles problemløst mellem de forskellige systemer. Til at udveksle informationer mellem forskellige systemer med forskellige filformater kan IFC-formatet anvendes. Et IFC-kompatibelt program kan producere en IFC-fil der kan indlæses af et andet IFC-kompatibelt program. Hvert objekt tildeles et unikt ID, GUID (Global Unique IDentifier), og ud fra det kan programmerne finde ud af type, placering, funktion og så videre, hvilket gør de forskellige programmer i stand til at oversætte og anvende informationerne (MBBL, 2013). Da byggebranchen i øjeblikket opererer delvist objektbaseret og delvist dokumentbaseret er der stadig brug for et klassifikationssystem og entydig navngivning, for at man kan udveksle til dokumentbaserede systemer, så som Word, Excel eller AutoCAD. På den måde har man Side 15 af 33

mulighed for at arbejde med objekterne i et blandet miljø og stadig have en sammenhæng mellem systemerne, selvom de ikke alle understøtter IFC. Formålet med kravet er dermed at man kan udveksle information mellem systemer, både objekt- og dokumentbaserede, uden tab af information. Dette kan gøres ved at anvende ét system til ensartet navngivning og klassifikation. Man kan også anvende flere systemer der er indbyrdes kompatible og mappe mellem dem. Det vil sige at man at oversætter entydigt fra ét system til et andet (MBBL, 2013). 3.3 Objektdatabase I en dokumentbaseret arbejdsmetode kan informationer, om eksempelvis en bygningsdel, være spredt ud over flere dokumenter. Det medfører en risiko for at der optræder modstridende oplysninger i projektmaterialet. For at undgå det, forklarer Martin Romby, oprettes der for hvert projekt en informationsdatabase hvor alle informationer opbevares. Ved at hvert objekt tildeles et unikt ID har man mulighed for at linke informationerne fra databasen over i sin bygningsmodel. Jacob Güldner fortæller at de bruger databasen til at styre udbud, hvor hver bygningsdel blandt andet kan tildeles enhedspriser, bygningsdelsbeskrivelser og målregler. Endvidere kan databasen bruges til at optimere den pågældende bygningsdel, ved at angive forskellige parametre. Som eksempel bruger han en pæl som skal monteres i jorden, der påhæftes nogle parametre, så som asfaltering, kapning eller dykning, der bruges til at styre hvordan den skal udføres. På den måde kan det beskrives ret præcist hvordan pælen skal udføres. Han nævner også at byggebranchen endnu arbejder i overvejende grad med dokumentbaserede beskrivelsessystemer, hvor bygningsdelene beskrives i et dokument, men at der arbejdes på at få egenskaberne ført over i database i stedet, så man har mulighed for at lave udtræk. Han nævner at informationen helst ikke skal stå to steder da man risikerer at have modstridende information. Han udtaler: lige pludselig ændrer du noget et sted og så står entreprenøren med to forskellige ting, hvad er det så lige vi går efter, så vil han tage det der er mest fordelagtigt for ham. (Jacob Güldner) 3.4 Objekthåndtering på DNV Gødstrup Ved Herning er der ved at blive opført et nyt hospital til akutmodtagelse med et etageareal på 130.000 m². Til projekteringen er der anvendt Sigma som projektbibliotek og der bruges Revit som modelleringsværktøj. Projektbiblioteket indeholder alle de ydelser der indgår i projektet og ved hjælp af et tilføjelsesprogram er det muligt at koble Revit og Sigma sammen. Projektbiblioteket fungerer som en database for projektets informationer. Jacob Güldner forklarer at når de forskellige aktører i projektet har flere forskellige fagmodeller med informationer der skal koordineres, kræver det disciplin i forhold til objekthåndteringen. I databasen holdes informationerne samlet ét sted, så man altid kan finde de sande informationer. De forskellige objekter er opdelt efter fag og ved hjælp af CCS bindes bygningsdelene i databasen sammen med det tilsvarende objekt i Revit. Side 16 af 33

Sammenkædningen mellem Revit og Sigma skal gøres én gang for hver bygningsdel, hvorefter projekteringen kører videre. Dette gøres ret tidligt i projektet og derfor kender man ikke nødvendigvis den eksakte opbygning af bygningsdelene, men klassifikationskoden er gennemgående i alle faser. Modellen kan herefter bruges til at udarbejde tilbudslister og den kan udveksles til entreprenøren gennem IFC. Det er også muligt løbende at holde økonomien opdateret ved at stille bygningsdelene op i et kalkulationsark, der løbende kan opdateres fra Revit. Til projektet anvendes CCS, men Jacob Güldner påpeger at det i princippet er ligegyldigt om man anvender CCS, DBK eller SfB, så længe der er en ensartet struktur (Cuneco, 2013). Figur 2. Diagram der viser arbejdsgangen i at linke bygningsmodellen med projektbiblioteket. Databasen indeholder alle informationer om projektet, og kan trækkes ud til de fagspecifikke modeller, kalkulationsark, tilbudslister osv. 3.5 Delkonklusion Objekter anvendes til opbygning af en bygningsmodel. For at kunne udnytte potentialet i en objektbaseret arbejdsmetode er det nødvendigt med en struktureret håndtering af objekterne fordi det blandt andet gør det nemmere at udføre mængdeudtag, kalkulation og kollisionskontrol. Mange processer i byggebranchen foregår stadig dokumentbaseret (Word, Excel osv.) hvilket gør det nødvendigt med ensartet struktur af objekterne fordi information om et objekt kan være spredt ud over flere dokumenter, og hvis navngivning eller klassifikation ikke er ensartet risikerer man at ende op med modstridende oplysninger. Én måde at strukturere information er ved at have en database der indeholder alle byggesagens objekter, som herefter kan sammenkædes med bygningsmodellen. På den måde er det muligt holde informationerne samlet ét sted, dermed kan det undgås at der findes modstridende informationer i projektmaterialet. 4 Klassifikationssystemer IKT-bekendtgørelserne stiller krav til at digitale byggeobjekter skal kodes og klassificeres. Formålet er at få en ensartet struktur hele vejen igennem byggesagen. Ved at bygningsdelen har en entydig kode kan den identificeres i de forskellige systemer hvor den optræder, både i bygningsmodellen og i forskellige dokumenter som tilbudslister eller beskrivelser. Det vil sige at klassifikationssystemet både skal være anvendeligt i objektbaserede og dokumentbaserede systemer. Side 17 af 33

I vejledning til bekendtgørelserne der er udgivet af Bygningsstyrelsen i 2013 anbefales det at der anvendes et klassifikationssystem, der tager udgangspunkt i ISO 12006-2 og ISO/PAS 16739:2005. ISO 12006-2 er en standard for klassifikation af information i byggeriet. ISO/PAS 16739:2005 beskriver IFC-formatet og hvordan modeller og BIM-data udveksles i byggeriet. Med et klassifikationssystem der tager udgangspunkt i disse to standarder betyder det i princippet at informationerne kan oversættes til andre systemer der lever op til de samme standarder, hvilket gør det muligt at oversætte fra et system til et andet (Cuneco, 2012). I vejledningen til IKT-bekendtgørelserne anbefales det at lade sig inspirere af SfB, CCS eller Forvaltnings Klassifikation (FK). Men det er også muligt at anvende andre systemer, hvis det vurderes at være mere hensigtsmæssigt. 4.1 Samarbetskomitén för Byggnadsfrågor (SfB) SfB-systemet er udviklet i 1950 erne i Sverige og blev udgivet i Danmark af Byggecentrum i 1988 (Byggecentrum, 2012). Systemet er veletableret og anvendes mange steder, for eksempel er V&S prisbøgerne struktureret efter SfB. SfB-systemet er bygget op af tre tabeller, en bygningsdelstabel, en konstruktionstabel og en ressourcetabel. I koden afspejles hver tabel af et facet. Det første facet er bygningsdelen og angives af et tal i parentes, fx (21) som angiver at der er tale om en ydervæg. Det næste facet skrives med et stort bogstav og angiver konstruktionstypen, fx F som angiver at der er tale om en muret konstruktion. Det tredje facet angiver ressourcetypen og skrives med et lille bogstav efterfulgt af et tal, fx g2, som angiver at materialet er tegl. Det vil sige at koden (21) F g2 henviser til en ydervæg opmuret i tegl (Byggecentrum, 2012). Med SfB har man ikke mulighed for at kode brugsrum eller egenskabsdata (MBBL, 2013), og er dermed ikke fuldt ud brugbart i en objektbaseret arbejdsmetode. Desuden har det ikke været opdateret i omkring 20 år (Byggecentrum, 2012). Det betyder at SfB ikke lever op til nutidige standarder, til gengæld er det meget udbredt i Danmark. 4.2 Dansk Bygge Klassifikation (DBK) DBK er det første klassifikationssystem udviklet specifikt til dansk byggeri. Systemet er delt op i fire domæner: Resultatdomænet (bebyggelser, bygninger, rum og bygningsdele - alt det, der bliver resultatet af byggeprocessen) Procesdomænet (delprocesserne i byggeriets forskellige faser) Resursedomænet (fag, entrepriser, materialer, materiel og dokumenter) Egenskabsdomænet (klassificering af egenskaber). De tre første domæner relaterer sig til hinanden ved at ressourcer (Resursedomænet) indgår i byggeriets processer (Procesdomænet), hvilket resulterer i et færdigt resultat (Resultatdomænet). Til objekter i hvert domæne kan der tilknyttes egenskaber fra egenskabsdomænet. DBK varetages af bips, og erstattes af CCS. Side 18 af 33

4.3 Cuneco Classification System (CCS) CCS er en del af udviklingsprojektet Cuneco, som ledes af bips (Cuneco, 2014), med forskellige organisationer fra byggebranchen som projektdeltagere, så som bygherrer, rådgivere og producenter. Projektet blev startet i 2011 og forventes afsluttet i midten af 2014, hvorefter systemet bliver udgivet. CCS erstatter dermed DBK-systemet. CCS er opbygget således at latinske bogstaver altid bruges som klassifikationskode og tal altid bruges som løbenumre, i modsætning til DBK og SfB hvor både tal og bogstaver bruges til klassifikation. 4.3.1 Klassifikationstabeller Der findes syv forskellige klassifikationstabeller til at strukturere de forskellige objekttyper. Hver tabel har hvert sit præfiks. I tabellen nedenunder ses sammenhængen mellem præfiks og tabel. Præfiks <A> <B> <C> <D> <E> <F> <G> Klassifikationstabel Bygværker Fysiske rum Brugsrum Bygningsdele Materiel Byggevarer Aktører Under hver tabel identificeres de forskellige objekter med en bogstav kode, som siger noget om hvilket objekt der er tale om. Hvert objekt kan tildeles en kode som bestemmes ud fra objektklassen. Hvert objekt kan tildeles en klassifikation. Hvis der for eksempel er tale om en søjle, kan man i tabellen Bygningsdele finde koden for en søjle som er ULE og dermed er koden for en søjle <D>ULE. 4.3.2 CCS aspekter Desuden kan hvert objekt inddeles i fem forskellige aspekter. Man kan for eksempel identificere et vindue ved dets type, produkt, placering og funktion. Man kan desuden identificere en gruppe af bygningsdele eller brugsrum, fx et vægsystem eller en etage. Hvert aspekt har et præfiks, der udover at fortælle hvilket aspekt der er tale om, også fortæller om der er tale om brugsrum eller bygningsdele. Typeaspekt (% for bygningsdele, %% for rum) o Gruppe af bygningsdele eller rum med samme klassifikation (fx vinduer eller badeværelse) Produktaspekt (# for bygningsdele, ## for rum) o Bygningsdel eller rum der ses som specifikt objekt (fx vindue nr. 1 eller vindue nr. 15) Side 19 af 33

Sammensat produktaspekt (- for bygningsdele, -- for rum) o Identificerer bygningsdele eller rum som en del af flere bygningsdele eller bygværker (fx vægsystem 1. Vinduesparti 3, vindue 2) Placeringsaspekt (+ for bygningsdele, ++ for rum) o Betegner et bestemt sted i bygningen (fx brugsrum 4 på 2. Etage) Funktionsaspekt (= for bygningsdele, == for rum) o Betegner en bygningsdel eller rum som en del af funktionel sammenhæng (fx ventilationssystem 1, røgventil 1) (bips, 2012) Udover de fem hovedaspekter kan der tilføjes projektspecifikke aspekter, hvis det viser sig at de eksisterende aspekter er utilstrækkelige til at beskrive objekterne. Man behøver ikke anvende samtlige aspekter i hver byggesag, hvis det vurderes ikke at være nødvendigt at anvende. 4.3.3 Kodeeksempel Ved at kombinere klasser fra klassifikationstabellerne og et af de fem aspekttyper er det muligt klassificere et objekt ret grundigt (Cuneco, 2012). Et eksempel på en kode kan være: #ULE6/%ULE2 # angiver at der er tale om et specifikt objekt, i dette tilfælde søjle nr. 6. % angiver hvilken type søjle der er tale om, i dette tilfælde søjle, type 2 Ved at bruge en skråstreg kombineres de to aspekter, og derfor kan koden læses som: Søjle type 2, nr. 6 På den måde kan objekter klassificeres, med det formål at have en ensartet kodestruktur hele vejen gennem projektet. Ikke kun for bygningsdele, men også mere abstrakte objekter som rum eller aktører. 4.4 Forvaltning Klassifikation (FK) FK er udviklet af Landsbyggefonden og Kommunernes Landsforening, med digitalisering af ejendomsforvaltning for øje. Det vil sige at det ikke er udviklet til projektering og udførsel, men til drift og vedligehold af alment byggeri. FK er udviklet fordi SfB er forældet og DBK har vist sig ikke at være funktionelt i forhold til ejendomsforvaltning. FK kan anvendes sideløbende med SfB eller CCS, da det forventes at FK stemmer overens med disse to systemer. Hvis for eksempel CCS anvendes som klassifikation i byggesagen, kan man tilføje den tilsvarende FK-kode som egenskabsdata (MBBL, 2013). I bekendgørelse nr. 1540, Bekendtgørelse om drift af almene boliger, stilles der i 61 stk. 4, står der vedligeholdelsesog fornyelsesplaner skal udformes i overensstemmelse med et klassifikationssystem for forvaltning, hvis Landsbyggefonden kræver det. Dette krav kan FK opfylde. Side 20 af 33

I forhold til SfB er FK udarbejdet så det har mulighed for at blive anvendt i en objektbaseret proces, hvis det anvendes i sit fulde omfang, hvilket er beskrevet i ni hæfter. Hæfterne beskriver de forskellige områder af FK og hvordan de anvendes (Landsbyggefonden, 2012). Hæfte 1, Vejledning er en vejledning til FK og giver en samlet indgang til systemet. Hæfte 2, Ressourcer og processer beskriver hvordan materiel og ressourcer der indgår i byggesagen kan struktureres. Hæfte 3, Form og Anvendelse bruges til at beskrive bygværkets type og hvad det bruges til. Hæfte 4, Metode til styring af vedligehold beskriver hvordan tilstandsregistrering kan udføres i henhold til FK. Hæfte 5, Bygningsdelstavle er en liste med bygningsdele med dertilhørende klassifikationskode der anvendes i FK. Hæfte 6, Egenskabsdata beskriver de egenskaber der kan være relevante at tilknytte et objekt. Hæfte 7, Mappingtabel bygningsdel gør det muligt at oversætte bygningsdele fra SfB til FK og fra tidligere kontoplaner til FK. Hæfte 8, Kontoplaner viser sammenhængen mellem bygningsdele og dertilhørende konti som udgifterne placeres under. Hæfte 9, Begrebskatalog indeholder en ordliste med begreber der forekommer i FK. 4.4.1 Kodens opbygning Kodestrukturen er ret simpel og bygger på forkortelser. Bygningsdelstavlen er delt op i to hovedkategorier: Bygningsdele i terræn og Bygningsdele i bygning. Hver med sin underinddeling af kategorier, konstruktion eller tekniske anlæg for eksempel. Et vindue vil med FK få tildelt koden bk.vin, hvor b står for Bygningsdele i bygning, k står for Konstruktion og vin er en forkortelse af vindue. 4.4.2 Kontoplaner I forbindelse med FK er der udarbejdet kontoplaner, kaldet konto 115 og 116, og forholder sig til bygningsdelene. Kontoplanerne bruges af den pågældende ejendomsforvaltning til at styre udgifterne i forbindelse med vedligehold. Det vil sige at når en bygningsdel i en almen bolig skal istandsættes, kan udgiften placeres i den konto der hører til. Kontoplanerne er opdelt i 23 konti, som er sorteret i seks hovedgrupper alt efter aktivitetens karakter. De seks hovedgrupper ses herunder: Terræn Bygning, klimaskærm Bygning, bolig- / erhvervsenhed Bygning, fælles indvendig Bygnings, tekniske anlæg / installationer Materiel Side 21 af 33

Det vil altså sige at når en bygningsdel skal vedligeholdes placeres den under den relevante konto. Dog er det sådan at vedligehold af en bygningsdel kan placeres i flere konti, alt efter aktivitetens karakter. Et eksempel kan være et vindue der skal males, både indvendig og udvendig. Da vil den udvendige maling skulle konteres under Bygning, klimaskærm og den indvendige maling skal konteres under Bygning, fælles indvendig. På den måde vil udgifter der relaterer sig til hinanden blive placeret i samme konto med det for øje at man har mulighed for nemt at opstille nøgletal. 4.5 Mappingtabeller Da der findes flere forskellige klassifikationssystemer kan det ind i mellem være relevant at skulle oversætte fra et system til et andet. Et eksempel kan være en bygning, hvor bygningsdelene er klassificeret med SfB, men skal indgå i en ejendomsforvaltning, hvormed det er nødvendigt at oversætte til FK. For at oversættelsen foregår struktureret og ensartet findes der såkaldte mappingtabeller der fungerer som ordbog mellem de forskellige systemer. Princippet er ret enkelt og er opbygget så det minder om en ordbog, ved at man har koden fra et system på den i en kolonne, og en tilsvarende kode fra det andet system i en anden kolonne. I øjeblikket findes der tabeller for mapping mellem SfB og DBK, samt mellem SfB og FK. Endnu er der ikke udgivet mappingtabeller for CCS. 4.6 Sammenligning af systemerne Som tidligere nævnt er SfB efterhånden et gammelt system, der ikke er blevet opdateret i flere år. Desuden indeholder SfB ikke mulighed for klassificering af egenskabsdata, som er et behov der er kommet efter at de objektbaserede arbejdsmetoder er blevet introduceret. Derfor er SfB i første omgang blevet afløst af DBK. Men det har også vist sig ikke at være helt uden problemer. Martin Romby (Bilag 1) og Jacob Güldner (Bilag 2) nævner begge at softwareleverandørerne ikke har været taget med på råd da DBK blev udviklet. Det har gjort det besværligt at udvikle software der kan understøtte DBK tilfredsstillende. Det skyldes at koderne er opbygget på en måde der gør det besværligt for softwaresystemer at læse koden. Det er undgået ved CCS hvor man fra starten har inkluderet softwareleverandører, blandt andet Graphisoft som udvikler Archicad og Betech Data som forhandler Autodesk produkter i Danmark. I en rapport udarbejdet af Anders Ekholm fra Lunds Universitet (Ekholm, 2011) påpeger han eksempelvis at et objekt kodet med DBK godt kan have flere forskellige klassificerende koder. Som eksempel nævner han mineraluldsisolering i væg, hvor han skriver at det kan kodes som -205.A16 Isolering af typen Mineraluldsisolering i Vægsystem, eller -205.01.A07 Isolering af typen Mineraluldsisolering i Vægkonstruktion i Vægsystem. Det kan være et problem fordi det samme klassifikationssystem dermed kan kode samme objekt på forskellig vis, hvilket ikke skaber ensartethed, og kan skabe problemer i forhold til integration med software, hvis koden ikke er stabil. Han nævner at det ikke nødvendigvis bliver et problem i praksis. Side 22 af 33

Jacob Güldner fremhæver at det der adskiller CCS fra SfB og DBK, er at CCS udelukkende er et identificerende klassifikationssystem, hvorimod SfB og DBK også er beskrivende. En identificerende kode oplyser udelukkende hvilken type bygningsdel der er tale om, for eksempel en væg. Når koden er beskrivende indeholder den også information om hvad bygningsdelen er opbygget af, et eksempel kan være en væg af tegl. Det kan skabe problemer hvis bygningsdelens opbygning ændres, for eksempel fra tegl til beton, da vil koden i SfB og DBK også ændres. Det kan risikere at skabe forvirring i kodesystemet. Den problematik undgås i CCS, da koden udelukkende fortæller at det er en væg, den fortæller altså ikke noget om bygningsdelens bestanddele. I CCS vil oplysninger om bygningsdelens bestanddele derfor være en del af objektets egenskaber, som dermed kan ændres uden at koden ændres. I øjeblikket er CCS dog stadig under udvikling, hvilket for Jacob Güldner betyder at CCS på nuværende tidspunkt ikke kan mere end SfB eller DBK. Men når CCS er færdigudviklet skal det gerne kunne klassificere egenskabsdata og dermed skille sig ud. 4.7 Delkonklusion Et klassifikationssystem er nødvendigt for at holde styr på informationerne i en byggesag. Indtil videre kan SfB, DBK og CCS det samme og derfor kan man i princippet anvende et hvilket som helst system, så længe det anvendes konsekvent og struktureret. Når CCS er færdigudviklet kan det bruges til at klassificere flere objekttyper end de andre systemer der er nævnt, derfor er det muligt at CCS på sigt i højere grad kan skabe merværdi for et projekt. Desuden vedligeholdes CCS fortsat, mens SfB og DBK ikke bliver videreudviklet. Dog FK kan i høj grad være relevant at anvende til alment byggeri da det er udviklet specifikt til ejendomsforvaltning. Det gør det nemmere for driftsherren efterfølgende at styre drift og vedligehold, hvilket i sidste ende er et af formålene ved at bygherren stiller krav om anvendelse af klassifikation. 5 Egenskabsdata Når man arbejder objektbaseret, er det muligt at tilknytte egenskaber til objekterne. Egenskaber kan både påhæftes konkrete objekter så som bygningsdele, eller mere abstrakte objekter som rum og fortæller noget om objektet. Det vil sige at de informationer man skal bruge i projektering, udførsel og drift kan fyldes på modellen og derefter trækkes ud efter behov. Både abstrakte og konkrete objekter kan have egenskaber tilknyttet. Eksempelvis kan relevante egenskaber for en dør være materiale, farve, U-værdi og så videre. For et rum kan eksempler på egenskaber være areal, anvendelseskategori, overflade og så videre være relevant. Figur 3. Egenskaber fortæller noget om objekterne i projektet bips. Side 23 af 33

5.1 Bips C214 Bips C214, guide til objekter, er en vejledning til at arbejde med objekterne i en bygningsmodel. Herunder beskrives der forskellige typer egenskaber, som de defineres af bips. 5.1.1 Dynamiske og Konstante egenskaber En egenskab har et navn og en værdi tilknyttet, navnet ligger fast, men værdien kan variere. I nogle tilfælde kan værdien dog godt være fastlåst. Ud fra dette princip skelnes der i bips C214 Guide om objekter, mellem to typer egenskaber: dynamiske og konstante egenskaber. Dynamiske egenskaber har værdier der kan ændres. Hvis man bruger et rumobjekt som eksempel kan der være en egenskab tilknyttet der hedder Areal. Egenskabens værdi kan ændres, og kan for eksempel være 25 m² eller 43 m². Dynamiske egenskaber kaldes også parametriske egenskaber, hvilket bare betyder at værdien kan ændres. Areal eller dimension er egenskaber der ændrer på geometrien af et objekt. Men materiale eller bygningsfysiske egenskaber anses også for dynamiske egenskaber, da man kan ændre udseende eller ydeevne på en bygningsdel. Konstante egenskaber har værdier der ikke kan ændres. Et dørobjekt kan for eksempel have en egenskab der angiver dimensionen på karmprofilen, der ofte vil være fast. Dette vil ofte være tilfældet ved objekter der kommer fra en producent, fordi de egenskaber der er tilknyttet er de faktiske egenskaber for det fysiske produkt. 5.1.2 Type- og forekomstegenskaber En egenskab kan have relation til andre egenskaber i et objekt eller til omgivende objekter. Ud fra det skelnes der mellem typeegenskaber og forekomstegenskaber. Typeegenskaber fortæller noget om et objekts udformning eller udseende. For eksempel hængselplacering, materiale eller dimensioner. Ved at arbejde med dynamiske egenskaber kan man kopiere et objekt og ændre egenskaberne og på den måde hurtigt rette objekterne til, så de passer til projektet. Forekomstegenskaber bruges til at beskrive relationen mellem det pågældende objekt og omgivende objekter. Det kan være placering i forhold til etage eller placering i forhold til andre bygningsdele. (bips, 2013) 5.2 Relevante egenskaber ift. drift og vedligehold Bygherren skal iht. IKT-bekendtgørelsen 4 stille krav om at byggeobjekterne forsynes med egenskaber der er relevante for den efterfølgende forvaltning, drift og vedligehold. Ved at bygningsmodellen er forsynet med egenskaber, har driftsherren efterfølgende mulighed for at bruge modellen i software der anvendes til drift og vedligehold. Det kan være forskelligt fra byggesag til byggesag, hvilke egenskaber der er relevante. Det aftales inden projekteringen påbegyndes hvilke egenskaber der skal tilknyttes modellen og skal Side 24 af 33

specificeres i aftalegrundlaget hvor der angives retningslinjer for IKT-anvendelse i projektet (Bilag 1). Der bør ikke stilles krav om flere egenskaber end det er nødvendigt i forhold til anvendelse i forvaltningens drift og vedligeholdelses software. Det betyder ikke at man ikke kan anvende flere egenskaber, de indgår bare ikke i kontrakten. For at bygherren har størst mulig gavn af de egenskaber der anvendes skal projektets egenskaber struktureres, det kan enten være en simpel liste med egenskaberne ordnet alfabetisk. Det kan også ordnes i en mere kompleks struktur, alt efter omfanget af relevante egenskaber. Desuden skal der holdes styr på hvilke egenskaber der knytter sig til de forskellige objektklasser. For eksempel vil rumobjekter have egenskaber som areal, overflademateriale eller anvendelse og bygningsdelsobjekter kan have egenskaber så som materiale, produktnavn eller placering (MBBL, 2013). 5.3 Egenskabsdata i praksis Hvis brugen af egenskabsdata skal skabe merværdi i en byggeproces kræver det koordinering mellem parterne. Det skyldes at de egenskaber der anvendes i projekteringen ikke nødvendigvis er de samme der anvendes i udførslen og driften. Jacob Güldner (Bilag 2) påpeger at der i øjeblikket er meget få erfaringer med driftsdata. Derfor, mener han, at rådgiveren og bygherren må indgå i et samarbejde om at indkredse hvilke data der skal afleveres, for at undgå at rådgiveren laver for meget arbejde som han ikke honoreres for eller at rådgiveren får færre data end aftalt. Han siger endvidere på sygehuse (DNV Gødstrup og RKB Riget) hvor Grontmij er rådgivere, har bygherren stort fokus på driftssystemer og driftsdata. Men fordi der ikke er nogen branchestandard må man prøve sig frem for at finde ud hvilke data og driftssystemer der skal bruges. Han udtaler: Det er jo nemt nok at skrive [-], i selve IKT-aftalen at der skal afleveres driftsdata for 3D-modellen. (Jacob Güldner) Det vil sige at selvom driftsdata er indtænkt i IKT-aftalerne, opfyldes det aftalte ikke altid, og fordi der ikke er ret mange erfaringer omkring driftsdata, må rådgiveren og bygherren indgå i dialog og dermed finde frem til hvad der skal leveres. Martin Romby nævner (Bilag 1) desuden at entreprenører og bygherrer ikke er lige så langt fremme med BIM, som rådgiverne er. Dog nævner Martin Romby at de største entreprenørfirmaer i Danmark er godt med og Jacob Güldner nævner også at der bliver arbejdet meget med emnet hos de store entreprenører. At bygherren ikke er så langt med BIM viser sig ved at driftsafdelingen ikke altid er gearet til at modtage driftsdata fra bygningsmodellen. Derfor kan det være svært for bygherren at vide hvilke egenskaber der skal stilles krav til i udbuddet. I stedet for bliver det en kontinuerlig proces, hvor man hen ad vejen finder ud af hvordan egenskaberne skal struktureres. Hvilke egenskaber der skal anvendes, og hvordan de struktureres defineres i IKTspecifikationerne. Et udgangspunkt kan være Byggeskadefondens vejledning til IKTbekendtgørelserne. I vejledningen anbefales det at anvende den struktur for egenskabsdata Side 25 af 33

som klassifikationssystemet anvender. Hvis systemet ikke indeholder egenskabsdata anbefales det at vælge FK s struktur for egenskabsdata som er beskrevet i Hæfte 6, Egenskabsdata. 5.4 Delkonklusion Egenskabsdata kan anvendes i alle faser af en byggesag. Selvom IKT-bekendtgørelserne stiller krav til egenskaber der er relevante for drift og vedligehold, er det ikke sikkert at bygherren ved hvilke egenskaber der er relevante. Derfor må rådgiveren og bygherren igennem dialog finde ud af, hvilke egenskaber der skal anvendes. Endnu findes der ingen branchestandard for egenskabsdata og derfor skal håndteringen aftales fra sag til sag. 6 Koordinering af IKT IKT-bekendtgørelserne 4 Stk. 2 lyder: Bygherren skal sikre, at der fastsættes retningslinjer for håndteringen af digitale byggeobjekter gennem hele byggesagens forløb. (Retsinformation, 2014) Det betyder i praksis at der i en given byggesag skal foreligge aftaleforhold og specifikationer der gør det klart hvordan digitale byggeobjekter håndteres. Det digitale aftalegrundlag kan udarbejdes på baggrund af Danske Ark og FRIs Ydelsesbeskrivelser fra 2012, Bips F102 Byggeriets IKT-specifikationer og manualer for informationsleverance (IDM). De tre dele der kan udgøre aftalegrundlaget, vil i det følgende blive uddybet. 6.1 Danske Ark og FRIs Ydelsesbeskrivelse 2012 Ydelsesbeskrivelsen kan anvendes til at fastsætte de overordnede rammer for rådgivning og ydelser i en byggesag. Herunder IKT-ydelser specificeret i afsnit 2.2 der omhandler ydelser forbundet med IKT-ledelse, med henblik på at IKT-lederen skal have ansvaret for den digitale koordinering. Hvilket betyder at IKT-lederen skal sørge for at der som minimum foreligger IKT-specifikationer omhandlende 3D-bygningsmodeller, kommunikation, datasikkerhed, udbud og data. Desuden skal IKT-lederen deltage i projekteringsmøder og udarbejdelse af tidsplan med henblik på at varetage IKT-samarbejdet. I afsnit 8, Andre ydelser, beskrives blandt andet yderligere ydelser der kan indgå i forhold til IKT, som omfatter klassifikation, digital kommunikation, etablering af kommunikationsplatform, digital projektering, digitalt udbud og tilbud, mængdefortegnelser og digital aflevering (FRI og Danske Ark, 2012). 6.2 Bips F102 Byggeriets IKT-specifikationer Byggeriets IKT-specifikationer anvendes til at definere det digitale aftalegrundlag i en byggesag. Byggeriets IKT-specifikationer er todelt og angiver henholdsvis grundlaget for IKTydelserne og de IKT-tekniske ydelser der skal specificeres (bips, 2013). Del 1 beskriver hvad der skal leveres og del 2 beskriver hvordan det skal leveres. Side 26 af 33

Ved at IKT-specifikationerne er delt i to er der mulighed for i del 1 at specificere de overordnede IKT-forhold, og dermed på et tidligt tidpunkt få fælles retningslinjer for projektet, og i del 2 er muligt at detaljere specifikationerne og om nødvendigt revidere dem løbende igennem projektet. 6.2.1 Ydelsesspecifikation Ydelsesspecifikationen omhandler hvilke ydelser der skal leveres består af en vejledning og en basisbeskrivelse samt en projektspecifik beskrivelse, som har til formål at specificere de projekterendes digitale ydelser på en byggesag. Bygherren kan fremsætte krav om anvendelse af ydelsesspecifikationen eller det kan være en del af aftalegrundlaget mellem de projekterende parter. Basisbeskrivelsen vedligeholdes af bips, og danner grundlag for IKTspecifikationen og er gældende selvom alle punkterne ikke nødvendigvis er relevante i forhold til den aktuelle sag. Ydelsesspecifikationen er opbygget så de ydelser der skal indgå, tilvælges i form af afkrydsning, med eventuelt angivelse af særlige forhold. For at opfylde kravene i IKT-bekendtgørelsen 4 skal der stilles krav om anvendelse af klassifikation af bygningsmodeller. Informationer i bygningsmodeller skal klassificeres i henhold til retningslinjerne i punkt 2.4 der omhandler klassifikation hvor det angives i hvilket omfang klassifikation skal anvendes i de forskellige faser. Figur 4. Eksempel på udfyldelse af punkt 2.4 i ydelsesspecifikationen, med uddybning af særlige forhold. Desuden skal det i punkt 4.3 omhandlende udbudsmaterialets struktur tilvælges at udbudsmaterialet skal klassificeres og det skal følge udbudsspecifikationen. 6.2.2 IKT-teknisk specifikation IKT-teknisk specifikation omhandler tekniske og praktiske forhold i IKT-samarbejdet. Denne del består af fire områder: kommunikation, CAD, udbud og aflevering. Som tilsammen har det formål at detaljere de rammer der er for IKT-håndtering. De fire områder har hver deres målgruppe, for at gøre informationsmængden mere overskuelig. I CAD-specifikationen defineres det hvordan egenskabsdata og digitale byggeobjekter skal håndteres i projektet, som er relevant for rådgiveren til at opfylde 4 i IKT-bekendtgørelserne. Tabellen nedenfor viser de fire IKT-tekniske områder og deres målgruppe. Side 27 af 33

Figur 5: Tabel fra bips F102. Sammenhæng mellem IKT-projektspecifikke paradigmer og deres målgrupper. 6.3 Information Delivery Manual I byggeindustrien bringes mange forskellige virksomheder og myndigheder sammen i forskellige projektspecifikke organisationer. For at kunne arbejde effektivt er det nødvendigt, at alle deltagere i organisationen ved, hvilke informationer der skal udveksles og afleveres. Til dette formål kan en Information Delivery Manual (IDM) anvendes. En IDM fastsætter retningslinjer for hvordan information udveksles i forskellige processer i en byggesag. ISO 29481-1:2010 Building information modelling - Information delivery manual - Part 1: Methodology and format" er en standard udviklet af buildingsmart for at have en metode til at indkredse og præcisere processer og informationsstrømme i løbet af en bygnings levetid. Metoden er en accepteret som en ISO-standard. Det forventes, at yderligere materiale vil blive tilføjet til den standard for at gøre det mere konkret i forhold til dokumentation af informationsudveksling, samt at have veldefinerede stadier i en kommunikationsproces mellem parterne (BuildingSMART.org, 2014). Metodikken kan bruges til at dokumentere eksisterende eller nye processer og beskrive de dertil hørende oplysninger, som skal udveksles mellem parterne. Outputtet fra standarden kan derefter blive anvendt til at angive en mere detaljeret specifikation. For at en IDM kan være funktionel skal den understøttes af software, da formålet med den er at sikre at relevante data kommunikerer på en sådan måde at data kan udveksles mellem forskellige softwaresystemer. Flere af IDM-projekterne har ført til specifikationer, der er blevet testet i virkelige byggeprojekter eller konkurrencer. Konceptet bliver fortsat udforsket og der arbejdes på at udvikle funktionelle IDM er. På nogle områder mangler der struktur og dokumentation for processerne, hvilket dermed gør det vanskeligt at udvikle en IDM til det pågældende område. Derfor må man i tilfælde af manglende struktur blive enige om relevante krav og aktiviteter der skal udføres (BuildingSMART.org, 2014). Side 28 af 33