Referat af fkusgruppemøde m afleverings- g driftsfasen 31.10. cunec en del af bips Dat 1.11. 2011 Prjektnr. Sign. MET 1. Baggrund cunec vil i en behvsanalyse afdække byggebranchens behv sm udgangspunkt fr arbejdet med at udvikle standarder fr digital udveksling af infrmatin. Behvsanalysen består af følgende elementer: Wrkshps fr de enkelte aktører: Byg- g driftsherrer, arkitekter, rådgivende ingeniører, udførende g byggematerialeprducenter. T fkusgrupper på tværs af aktører inden fr faserne: prgrammering, prjektering, udførsel g drift & vedligehld. Dette dkument beskriver det første fkusgruppemøde m afleverings- g driftsfasen, sm blev afhldt den 31.10. 2011 hs cunec. Mødet havde følgende deltagere: Lars Hlmsgaard, Landsbyggefnden Trben Trampe, KAB Jhn Crell Nilssn, Sltsg Ejendmsstyrelsen Bryan Karlqvist, Københavns Ejendmme Michael Ørsted, Københavns Lufthavne Henrik Carlsen, B. Nygaard Sørensen Bjarne Christensen, YIT Stefan Brrsen, Gttlieb Paludan Christian Lundstrøm, Grntmij Ellena Lee, Jakn Jørgen Abildgaard, Jakn Trben Klitgaard, cunec (facilitatr) Gunnar Fribrg, bips (facilitatr) Lars Hvam, DTU (plægshlder) Mette Øbr, cunec (referent) Anette Prindahl (prcesmdel-referent) Mødet havde følgende dagsrden: 1. Diskussin af case v. Lars Hvam 2. Behvsidentifikatin: Hvad er fasens største udfrdringer vedr. udveksling g genbrug af data? v. Trben Klitgaard 3. Gennemgang af de enkelte udfrdringer v. Gunnar Fribrg 4. Opsamling g priritering v. Trben Klitgaard cunec står fr fællesskab. Vi udvikler det fælles grundlag fr digitaliseret samarbejde i byggeri, anlæg g drift. Målet er øget effektivitet g prduktivitet gennem bedre udveksling af infrmatiner. www.cunec.dk Side 1 af 15
Nedenfr refereres mødets diskussiner. Bemærk, at referatet ikke angiver en samlet knklusin m de enkelte punkter, men deltagernes individuelle kmmentarer, sm kan være mdstridende grundet deltagernes frskellige synspunkter g interesser. 2. Diskussin af case Lars Hvam fremlagde en case, sm ud fra en aktuel byggesag illustrerer, hvr der kan pstå prblemer i frhld til indsamling g aflevering af D&V-data, g hvrdan en standard kan gøre en frskel. (Casen er nøjere beskrevet på http://cunec.dk/behvsanalyse). I casen indsamler en ttalentreprenør materiale fra de andre aktører, dvs. rådgivere, fagentreprenører g prducenter, der skal indgå i en D&V-database til bygherren. Ttalentreprenøren pretter et bygningsdelskrt, en struktur fr krtet g en prces fr indsamling af data, herunder hvem har ansvar fr pretning, udfyldning, kvalitetssikring sv. Strukturen fr bygningsdelskrtet g prcessen fastlægges af ttalentreprenøren uden basis i en standard, hvilket betyder, at de øvrige aktører risikerer i hvert nyt prjekt at skulle frhlde sig til nye strukturer g prcesser, hvilket er tidskrævende g giver basis fr fejl. Der er heller ikke på frhånd en fælles frståelse af, hvilke D&V egenskabsdata, bygherren efterspørger, g hvrdan disse skal klassificeres. Iflg. Lars Hvam ville det være mere hensigtsmæssigt, hvis der var en standard fr klassifikatin af bygningsdele g egenskabsdata, sm tg udgangspunkt i driftsfasens behv. En standard fr ydelser g ansvarsfrdeling (à la A113 fr betnelementer), sm fastlagde prcesfrløbet g gjrde det klart, at hvem der har ansvar fr hvad, ville desuden skabe større klarhed. Sådanne standarder ville skabe større ensartethed, spare tid g give bedre datakvalitet. Deltagerne kunne genkende prblematikken g havde følgende kmmentarer til casen: Man skal tænke 3D-bjektmdeller ind i prblematikken på længere sigt vil bygningsstrukturen g bygningsdelskrt genereres ud fra en 3D-mdel. Der skal gså stilles krav m bestemte filfrmater, sm gør det muligt fr D&V-flkene at redigere i de mdtagne dkumenter (ikke pdf-filer sm nu). Bygherrerne skal allerede i udbuddet stille krav til afleveringsmaterialet det gør de ikke i dag. Bygherrerne er generelt fr dårlige til at stille krav. Byg- g driftsherrer er fte ikke i starten af prcessen afklaret med, hvilke infrmatiner de vil have behv fr i afleveringen. Side 2 af 15
Den typiske afleveringssituatin i dag er, at bygherren mdtager mange mapper med infrmatin, sm alligevel ikke bruges. Denne situatin er frustrerende både fr mdtager g fr afsender: Sm entreprenør plever vi fte at levere D&V-materiale, sm brugerne i hverdagen ikke bruger, frdi der står fr mange ting, de ikke kan frhlde sig til Vi får typisk 6-7 mapper kvalitetssikringsmateriale, sm vi ikke aner, hvad vi skal bruge til Byggeprcessen genererer mange flere data, end driften skal bruge. Alle disse data afleveres sm as-built-infrmatin, men herudver skal bygherrerne udpege, hvilke af disse mange data, de reelt skal bruge i driften. Der er behv fr, at bygherrerne laver en standard fr krav til afleveringen, så der kmmer større ensartethed: Vi kan ikke kmme videre uden en standard I frhld til 3D-mdeller skal der være en standard fr at sætte filer p mellem bygningsmdellen g driftsmdellen: Man kan få 7 mia. bygningsdele, man ikke kan bruge i et D&V-system Tænkt inden fr en digital verden er prblemet ikke mængden af data, men struktureringen af data, sm gør det muligt at finde de data, man er interesseret i. Er struktureringen i rden, giver det mening fr bygherrer af fremtidshensyn at indsamle alle de data, sm er tilgængelige, selvm de p.t. ikke ved, hvad de skal anvende dem til. Strukturering er således en frudsætning fr, at dataene bliver anvendelige: Vi vil typisk have alle data, men hvis vi ikke får det struktureret, kan vi ikke bruge det En anden frdel ved at pbevare data på en intelligent digital måde er, at man kan få adgang til data hvr sm helst: Vi kan ikke slæbe 10 ringbind med ud til en pumpe, der er i stykker, men vi har vres tablet g kan hente infrmatin m pumpen på stedet Lad s gå væk fra dumme tegninger g dkumenter g så få lavet rådata, sm vi vha. sftware kan få ud, hvr de skal bruges En ulempe ved at råde ver mange data er, at de skal vedligehldes fr at være nget værd fx skal driftsherren huske at ændre i sit D&V-system, hvis en pumpe udskiftes. Der er risik fr, at driftsherren drukner i data. Især hvis data ligger samlet ét sted, hvr de relevante infrmatiner skal findes i 6. klnne. Det vil være mere hensigtsmæssigt, hvis infrmatinen først kmmer frem, når Side 3 af 15
man peger på den, eller via et nummer, der peger på infrmatinen på Internettet ell. lign. Der skal findes en gylden mellemvej mange driftsflk har str erfaring med at vedligehlde deres bygninger g føler ikke, at de har brug fr ret meget infrmatin. En fremtidig standard må ikke udelukkende bygges p på 3D-mdeller, sm primært er relevant ved større nybyggerier g ikke ved renvering g mindre prjekter: Hvis man udskifter et luftfilter, skal man have infrmatin ind fra håndværkeren, g det bliver ikke via en BIM-mdel En digital aflevering vil bestå af både autmatiske g manuelle prcesser fra en BIM-mdel får man kun de bjekter, sm er med i mdellen. Driftsherrerne har behv fr driftsdata, sm ikke er tegnet med i mdellen på frhånd. En måde at løse prblemet med mdtagelsen af stre mængder ubrugelige data er at bede entreprenøren eller rådgiveren m selv at taste data ind i driftsherrens D&V-system: Det bliver meget tydeligt fr dem, hvad vi skal bruge, når de taster det ind de spørger: hvad skal I bruge det til? Og vi svarer: ikke til nget Dette er dg uhensigtsmæssigt fr entreprenørerne, der skal lære at kende alle de frskellige systemer, der skal tastes ind i. En standard vil være mere hensigtsmæssig. Andre steder lægger driftsflkene selv infrmatinen ind både frdi den ikke kan verføres autmatisk, men gså fr at sikre validitet g mængden af data: Hvis det bare blev læst ind autmatisk, så mister driften grebet m, hvad der fregår Mange stre, prfessinelle bygherrer arbejder stadig med 2D g dumme tegninger bl.a. frdi dkumentatinen fr ældre bygninger ligger i papir. Desuden passer dette niveau bedst til driftsflkene på ejendmskntrerne. Et D&V-system til styring af vedligehldelse kræver reelt meget få infrmatiner m de enkelte ejendmme fr at give værdi. Den nuværende prces, hvr rådgiverne i afleveringssituatinen søger driftsinfrmatin m de anvendte prdukter enten i mapper eller ved pkald til prducenten, er uhensigtsmæssig. Det ville være smartere, hvis rådgiverne fx kunne lægge prdukterne i en database g linke direkte til de prducenter, der råder ver dataene. Det ville være hensigtsmæssigt, hvis entreprenører g rådgivere afleverede via redigerbare frmater, så driftsherren kan genanvende data til fx Side 4 af 15
driftsplaner g budgetter i stedet fr at være tvunget til fx at genindtaste infrmatin fra et bygningsdelskrt i pdf. I en kmmende standard skal man derfr have sig fr øje, hvad frmålet er med afleveringen hvad skal driftsafdelingen have at vide i frhld til deres vedligehldelse? (= hvrnår skal hvad laves, g hvad kster det?) Øknmien er meget vigtig fr driftsherrerne, sm skal lave retvisende vedligehldelsesbudgetter g fx kunne svare på, hvilken betydning en udskiftning har fr ttaløknmien. Det er således vigtigt fr driftsherren at have mulighed fr at knytte prisdata på efter afleveringen. Det ville være hensigtsmæssigt med en standard fr, hvrdan prducenterne leverer D&V-infrmatin m deres prdukter ja til webservice, nej til pdf. Det kunne være en standard fr, hvrdan prducenten filtrerer infrmatinen, idet frskellige brugere har brug fr frskellig infrmatin (fx arkitekten kntra varmemesteren). Det skal versættes til et infrmatinssprg, sm den enkelte bruger kan frstå. En fremtidig klassifikatin skal både være relevant fr de stre, prfessinelle bygherrer g fr de mindre bygherrer, sm kører på et lavere teknisk niveau. En fremtidig klassifikatin relateret til driftsfasen skal perere med frskellige niveauer et verrdnet niveau, hvr tingene beskrives på et verrdnet niveau fr dem, der alligevel selv går ud g måler med tmmelstk g et mere detaljeret niveau fr dem, der magter at gå dybere ned. Det skal stadig være muligt fr driftsflkene, sm har været vant til SfB, at rientere sig i den nye klassifikatin: Det må ikke blive fr vldsmt, så almindelige mennesker ikke kan se, hvr de er henne 3. Behvsidentifikatin cunec har i de frudgående wrkshps i bølge 1 afdækket følgende primære behv i afleverings- g driftsfasen: 1. Standard fr digital aflevering - autmatisk indlæsning af as-built infrmatin i driftssystemer 2. Egenskabsdatasæt fr driftsbjekter 3. Indarbejdelse af bygningsdriftens behv i prgrammeringsfasen Deltagerne var verrdnet enige i disse behv g havde følgende supplerende bemærkninger: Egenskabsdata fr driftsbjekter er centralt g er basis fr de t andre punkter hvis man har det rigtige egenskabsdatasæt, sm driftsflk har været med til at bestemme, kan det sikres, at man autmatisk fra BIMmdellen kan hente infrmatinen ud g gøre den peratinel. Side 5 af 15
Indarbejdelse af bygningsdriftens behv i prgrammeringsfasen handler meget m ttaløknmi. Øknmiens betydning fr driften undervurderes fte. Det er vigtigt, at driftspersnerne har indflydelse på prgrammeringsfasen g inddrages rganisatrisk i beslutningerne. Punkt 3 bør ændres til: Indarbejdelse af bygningsdriftens databehv i prgrammeringsfasen. Tilgængelighed af data er gså et vigtigt punkt. Levetid g vedligehld er umgængelig parametre fr driftsherrerne. Bygherrer vil gerne løbende have infrmatin til bygningsmdellen fra rådgivere g udførende, så de selv kan tjekke, m deres krav til fx klima er pfyldt (dvs. data skal ikke blt afleveres ved slutningen af prjektet). Efterfølgende blev de tre emner diskuteret enkeltvis ud fra punkterne: beskrivelse af prblemet, årsager til prblemet g hvilke typer standarder, der kan afhjælpe prblemet. Diskussinen er gengivet i næste afsnit. 4. Gennemgang af de enkelte udfrdringer 4.1. Standard fr digital aflevering Uden en standard skal bygherren ved hvert nyt prjekt internt i rganisatinen diskutere, hvad der skal afleveres, g hvrdan driften vil have det. Driftsherrerne mdtager data i så frskellige frmater g på så frskellig måde, at de har svært ved at trække substansen ud af det g lægge det ind i deres FM-systemer. Hvis afleveringsdataene ikke gøres brugbare i driften helst i frm af en aktivitetsliste bliver vedligehldet i realiteten ikke udført sm beskrevet. Driftsherren har en dårlig sag ver fr entreprenøren, hvis nget går i stykker, frdi han kan henvise til afleveringsinfrmatin, sm står ubrugt i driftsherrens mapper. Ikke-brugbar afleveringsinfrmatin leder således til manglende vedligehld g knflikter. Materialet skal helst afleveres i en database, sm driftsherren kan trække rådata ud af, frem fr i en pdf-fil. En BIM-mdel er et gdt sted at hænge dataene p på. Side 6 af 15
Byggeprcessen genererer dg kun as-built-infrmatin til BIM-mdellen, g ikke alle de driftsdata, sm driften har behv fr fx vedligehldelsesinfrmatin. Driftsherrerne arbejder med frskellige FM-systemer g gør tingene frskelligt. Det synes dg at være de færreste driftsherrer, sm arbejder med 3D. Ingen af fkusgruppens driftsherrer arbejder således med driftssystemer baseret på 3D. cunecs kmmende prdukter skal tage højde fr, at driftsflkene generelt ikke arbejder i 3D på nuværende tidspunkt: Hvis der km en løsning fra cunec, der var bygget p mkring vektrdata, ville vi ikke kunne bruge det så har vi t frmater, der ikke hænger sammen. Selvm vi siger, vi har en rummelig mdel, har vi stadigvæk føringsveje g ventilatin i 2D Driftsherrerne har på længere sigt en udfrdring med at få data fra eksisterende bygninger ind i BIM-mdeller: Jeg har data på bliger fra 1950 erne. De har intet med en BIM-mdel at gøre, det er vandskadede tegninger i en kælder. Fra de udførendes side plever man gså frskellige krav til afleveringen fra prjekt til prjekt, hvilket både er tidskrævende g giver dårligere kvalitet, end hvis det kørte efter en fælles standard. Ofte kmmer bygherren først med krav til afleveringen, når entreprenøren har afleveret sit første udkast, sm frkastes. Entreprenøren er tilbøjelig til at aflevere så meget sm muligt, så det ser ud af nget, hvilket betyder, at bygherrerne får en masse data, de ikke kan bruge til nget. Da entreprenøren ikke kender bygherrens reelle krav, gætter han på, hvilke krav han skal stille videre til sine underleverandører: Hvis man fik en standard, kunne leverandøren kmme med infrmatin, der kan bruges til nget tit skal man kippe g klistre, eller man afleverer nget, hvr det er 4 linjer, der skal bruges, men det fylder 10 sider i pdf-filen fra leverandøren Der mangler en standard g en basisstruktur, sm kan gøre det klart lige fra starten af prcessen, hvem der skal levere hvad hvrnår, så det bliver klart fr alle de aktører, der skal levere data til afleveringen, lige fra rådgivere g ttalentreprenører ver fagentreprenører til prducenter. IKT-aftalen dækker ikke dette behv, da den kun kører mellem rådgivere g (ttal)entreprenører den udleveres ikke til underentreprenører g leverandører. Side 7 af 15
Afleveringsinfrmatinen, der samles p løbende, kan enten afleveres i bygherrens eget DV-system eller i en datamdel, sm udleveres i frbindelse med udbuddet, hvr man kan lægge infrmatin ind frskellige steder fra. Der findes 10-11 DV-systemer på markedet, sm er webbaserede g kan udfylde denne pgave. Ingen af systemerne har imidlertid udarbejdet en IDM fr, hvrdan data skal se ud i bygningsmdellen, fr at det kan mdtages i DV-systemet: Der mangler, når man prjekterer i 3D, en IDM, sm frtæller, hvrdan data skal lægges i 3D-mdellen, fr at det kan bruges i et DVsystem 2 år senere Det vil dg nk være fr dyrt fr de mindre leverandører af DVsystemer at implementere disse ting. Når de udførende skal arbejde videre digitalt med infrmatin fra prducenter g leverandører fx i frm af et prduktinskrt, har de behv fr, at infrmatinen er struktureret. Der er således behv fr en standard fr, hvrdan prducenterne leverer infrmatin. Det ville være smart, hvis man på basis af en standard fr digital aflevering kunne trække al vedligehldelsesinfrmatin vedr. fx teknik eller døre ud af DV-systemet. Der skal være en standard, hvr både prducenter g leverandører autmatisk fylder ud i det ønskede frmat, så man slipper fr tasteri: Hvis vi sm bygherrer skal stille krav til alle vres entreprenører m at taste ind i vres system, så skal vi betale fr en udvikling, vi ikke ønsker Det skal være et åbent udvekslingsfrmat lige nu er det plagt med en XMLstruktur, sm har mange elastikker g er nem at tilgå, senere kan det evt. blive en webløsning. Det vigtigste er, at frmatet er åbent. Standarden må ikke være fr rigid alle bygherrer har særegne bygningselementer, sm ikke kan indgå i en standard. Prducenterne skal stille skalerbare data til rådighed hvr brugerne selv kan vælge hvilket infrmatinsniveau, de ønsker sm rådgiverne kan anvende direkte i deres bygningsmdeller. Der skal være en standard til prducenterne fr egenskabsdata fr bjekter. Det skal være en åben standard både ud g ind af mdellen, så man kan vælge frit på markedet. Et fremtidigt scenarie, når standarderne er på plads, kunne være, at rådgiveren afleverer en BIM-mdel, hvr der linkes til data fra leverandøren. Herfra skal der måske vha. IFC versættes til driftsherrens DV-system. Dg vil rådgiveren typisk ikke før udbudssituatinen lægge sig fast på knkrete prdukter, men arbejde ud fra generelle bjekter. Det Side 8 af 15
er således først mdellen i udførelsesfasen, der skal fdres med de knkrete data g blive til as-built-mdellen. Driftsherrerne i fkusgruppen har generelt ikke erfaring med IFC, men mdtager evt. datamdeller i prprietære frmater. Driftsherrerne i gruppen kan gdt frestille på længere sigt at stille det sm krav til leverandørerne, at de skal levere i et bestemt datafrmat, men sm niveauet er i dag, giver det ikke mening: Flk kan ikke mange af de ting, vi har talt m i dag. Det er j meget primitivt i virkeligheden. Bare at få et prjekt igennem en prjektweb kan være nyt g meget avanceret fr mange Men at have en standard vil presse udviklingen i den ønskede retning.: Stille g rligt stiger verliggeren. Der er t lejre af driftsflk: de meget udviklingsrienterede, sm interesserer sig fr fremtiden, g hvrdan man kan trække data ud af en BIM-mdel g dem, der interesserer sig fr de daglige prblemer g ikke er særlig digitalt rienterede. Udviklingsprcessen frhales fte, frdi de t lejre taler frbi hinanden. Det vil være bedre at drive udviklingsprcessen i t mdi, hvr det ene fkuserer på endemålet g det andet på at få prcessen i gang. Det vil iflg. Deltagerne være muligt fr driftsherrerne at blive enige m, hvilke bygningsdele man typisk drifter på, dvs. der er en relevant fællesmængde at standardisere ud fra. Dette gælder dg særligt i frhld til udvendig vedligehld, idet ansvaret fr det indvendige vedligehld kan ligge hs evt. lejere. Man enes m, at antallet af fælles, typiske bygningsdele er ca. 100-120. Man skal skelne mellem as-built niveauet, der mhandler alle data, der indgår i byggeriet, kntra det niveau, der mhandler de data, der skal bruges til den daglige drift. Disse niveauer er dg ikke veldefinerede g blandes fte sammen. As-built-materialet bruges dels til 5 års eftersyn, dels i frbindelse med mbygninger. Driftsdataene kunne i sig selv være på t niveauer, et avanceret g et simpelt, hvr det simple benævner fx et vindue, mens det avancerede gså nævner mål, fastgørelse.lign. Disse t niveauer tager både højde fr driftsherrernes frskellige kmpetencer g behv. Fx er behvet fr detaljeret infrmatin størst hs bygherrer med mange ens bygninger/rum. 4.2. Egenskabsdatasæt fr driftsbjekter Der kan i princippet være mange relevante egenskabsdata fr de enkelte bygningsdele, g hver aktør har brug fr hver sine egenskabsdata. Side 9 af 15
Deltagerne har kun i mindre grad internt i deres rganisatiner arbejdet med, hvilke egenskabsdata de har behv fr, g hvrdan de får fat i dem. Ngen bruger bygningsdelskrt sm ramme fr de data, der skal ind. Egenskabsdata er generelt svært fr medarbejderne at verskue g frhlde sig til. I frhld til driften er det relativt få infrmatiner, der er behv fr på det enkelte prdukt, såsm levetid g hvrdan funktinen sikres. Driftsherrerne vil gerne mdtage data fra prducenterne m prdukternes levetid, g hvrdan de skal vedligehldes med mulighed fr selv løbende at mdificere data ud fra egne erfaringer. Mht. driftens prcesser arbejder man med begreber sm vedligehldelsesinterval, driftsinterval, udskiftningsinterval. Man vil ud fra bygningsdelskrt g principperne fr vedligehld kunne pege på hvilke typer af infrmatin, sm er interessante at trække ud, hvis de findes i byggeprjektet, enten i prduktinfrmatinen eller i udførelsen. Driftsherrerne har på strategisk plan behv fr at styre vedligehld g mbygning g kan dermed have behv fr principper fr, hvrdan man budgetterer ud fra data g trækker data ud højere ppe på makrniveau fx fr at kunne gdtgøre driftsbudgettet. Driftsherrerne kan være i tvivl m validiteten af prducentens data, hvis prducenten selv angiver tal fr levetid, vedligehldelsesinterval, pris sv. Sm udgangspunkt har driftsherrerne dg ikke andet valg, hvis de vil arbejde struktureret med de data, der findes g fx kunne beregne ttaløknmi. Man håber imidlertid, at der på sigt kan kmme en certificering, sm sikrer, at data er krrekte: I princippet kan prducenterne lve hvad sm helst g slippe af sted med det, fr de kan altid sige, at vi ikke har vedligehldt det gdt nk I den daglige drift arbejder man dg ikke direkte ud fra prducenternes anvisninger, men justerer pba. egne erfaringer (sm fx kan være, at prducenterne fr at sikre sig verdriver prduktets vedligehldelseskrav). Det reelle vedligehldelsesbehv afhænger meget af brugen af prduktet (hvr mange mennesker bruger det, hvr fte sv.) Driftsherrerne justerer således selv på data løbende, men justerer gså fra starten af, så de sikrer sig, at data passer til deres specifikke situatin. Fx er der frskel på, hvr tit vinduer skal males, alt efter m de sidder på nrdeller sydsiden (dvs. placeringen af prduktet er en infrmatin, driftsherren har behv fr i den digitale aflevering). Side 10 af 15
Mderatr spørger, da der er meget frskellige bygningsdele g frskellige driftsegenskaber, m man skal definere principper fr, hvrdan man finder egenskabssæt, eller m man skal tage en bygningsdel ad gangen g afklare, hvad der er relevant fr driften? Iflg. deltagerne kan man hurtigt finde et minimumsniveau fr vedligehld: Driftsfasen skal grundlæggende bare bruge, hvad der skal gøres, g med hvilken frekvens Man kunne knytte flere aktiviteter til bygningsdelen, fx hvr tit skal nget tjekkes, minimumsvedligehld sv. 2-5 aktiviteter pr. bygningsdel vil være et relevant antal. Et autmatisk genereret DV-system kan dg ikke stå alene, men skal suppleres med en vurdering, fx i frhld til akut vedligehld. Driftsherrerne vil gerne have basisinfrmatin fra afleveringen, sm kan bruges til fx efterfølgende malerbehandling af vinduer, så det ikke er nødvendigt at tilkalde en rådgiver.lign., når vinduerne skal malerbehandles efter 5 år, men infrmatinen kan sendes direkte ud til entreprenøren. I princippet skal alle de infrmatiner, ngen synes er værd at lægge i en pdf g sætte i ringbind, lægges ind i egenskabsdatasættet. Det handler blt m at strukturere data, så man kan finde det, g man selv kan vælge hvilken pakke, man vil have. 2-5 aktiviteter er ikke tilstrækkeligt. Man afventer g frventer en hurtig udvikling på mrådet at ngen starter med at definere egenskaber fr bygningsdelene i et vist mfang: Ellers har vi helt generisk tmme bygningsmdeller med data, vi ikke tør gå i gang med Hvad angår egenskabsdata fr rum g bygninger i frhld til driftsfasen, strukturerer ngle af deltagerne data efter t frskellige aspekter: et rumligt aspekt (lkalisering) g et bygningsdelsaspekt. Én arbejder med at lave funktinsudbud fr det indre vedligehld af rum, hvr der skal defineres niveauer fr, hvrdan rummene skal prethldes (dvs. udfaldskrav til velfungerende rum). En anden hæfter egenskaber på både bjekter g rum Man skal huske, når man laver egenskabsdata, at rum flytter sig fx flyttes væggene i en kntrbygning efter 2-3 år. Der sker en variatin ver tid. Der er gså brug fr antal kvadratmeter, så man fx kan trække data ud i frhld til leje- g rengøringsaftaler. Side 11 af 15
Hvad angår anvendelse af klassifikatinssystemer, anvender t af driftsdeltagerne DBK. Frnemmelsen er, at branchen venter med at bruge den, frdi man frventer, den snart bliver ændret. Rådgiverne kan ikke bruge bygningspdelingen i DBK. DBK er ikke velegnet til udførselsfasen. Man har erfaret manglende bygningsdele i DBK DBK blev kørt ud til 3. niveau, men man havde behv fr nget i 5.-6. lag, sm så blev sat ind med navn i parentes. Der er behv fr en standardstruktur frem fr en færdig liste, så man kan se, hvrdan man skal beskrive nget: Måske er ikke alle dele skrevet, ngen er lavet sm eksempler, men jeg kan lave mine egne, hvis jeg bare følger denne pskrift Man behøver ikke få alle driftsdata lagt ind i bygningsmdellen, de skal blt ligge tilgængelige, så man kan kmmunikere med dem. Det ville være gdt, hvis der kunne knyttes egenskabsdatasæt til frskellige bjekter, g driftsherrerne kunne hente hinandens egenskabsdatasæt g knytte disse til egne bjekter. cunec skal starte med kernen, dvs. beskrive et system, sm branchen ver tid kan frbedre. 4.3. Indarbejdelse af bygningsdriftens behv i prgrammeringsfasen Det er en udfrdring at få driften tidligt invlveret, så de få krav, sm driften reelt har, kmmer med i en tidlig mdel, g man allerede i prgrammeringsfasen kan følge p på, m kravene pfyldes: Det kan være nget så banalt sm at sikre, at der installeres de målere, der skal til, fr at driftsflkene kan lave varmeregnskab Der mangler en effektiv måde at inddrage driftsflkene i prcessen på, da byggeafdelingen g driftsafdelingen typisk er adskilt rganisatrisk. Man skal både finde de rigtige mennesker at inddrage, g den rigtige mødefrm. Det handler m samarbejdet på tværs af rganisatinen, dvs. er et rganisatrisk prblem. Det kan fx løses ved at lave et rganisatrisk bindeled mellem driften g byggeprjekterne, der hjælper med at trække erfaringer ud af driftsflkene. Det handler dels m data, dels m at tænke frnuftigt : Datamæssigt handler det m psamling af data vedr. driften af bygningsdele, hvilket Side 12 af 15
starter tidligt i prgrammeringsfasen på nøgletalsniveau, hvr man kan trække flere g flere data ud i løbet af byggeprcessen. At tænke frnuftigt handler m at tænke prjekteringen igennem ud fra driftens synsvinkel, så man fx ikke tegner vinduer, sm er umulige at pudse eller ekstremt dyre at udskifte. Ofte kendes driftsherren ikke i prgrammeringsfasen, men udpeges senere i prcessen. Dvs. der er ingen, sm rådgiverne eller ttalentreprenøren kan gå i dialg med m driftens behv. Her ville en standardisering hjælpe (en standard fr driftsinfrmatin), idet der så på frhånd er taget stilling til nget et grundlag at tage udgangspunkt i. Omvendt er det ikke hensigtsmæssigt fr bygherren på frhånd at være fr specifik med, hvad han vil have, idet han skal være åben ver fr arkitekternes input: Jeg kan gdt lave en manual i dag m, hvad der skal i bygningen, g aflevere den til en arkitekt, men så får jeg bare de samme kedelige huse bygget hver gang, g pludselig er de ting, jeg har peget på, ikke det rigtige længere, frdi jeg ikke følger med i udviklingen Hvis man bare kan lave egenskabsdatasæt på et brugbart niveau, sm fx kmmunerne kan bruge, er vi nået langt. Mderatr spørger, m det er relevant, at bygherren i udbuddet definerer, hvad han gerne vil vide nget m fx levetiden fr undertag kntra vertag hvrved egenskabsdatasættene gøres peratinelle i en tidlig fase. Deltagerne bekræfter dette. Driftsflkene kunne stille krav m, hvad de vil vide i frbindelse med byggeriet de har erfaringen g kender de typiske prblemstillinger. Ofte er bygherrens bygge- g driftsbudgetter t separate kasser, g udbuddet baseres på pris. Fr 5-10% mere ville bygherren kunne få et bedre prjekt med billigere drift g større levetid, men denne dialg fører entreprenør g bygherre sm ftest først efter, at entreprenøren er valgt. Et større fkus på ttaløknmi ville afhjælpe denne situatin. Der mangler en standard fr, hvrdan man beregner ttaløknmien. Dette gøres i dag frskelligt, hvrved tilbuddene reelt ikke er sammenlignelige. De bydende ønsker dg ikke at skulle beregne flere gratis ting i tilbudsfasen, end de allerede gør: Det er snart blevet et frprjekt, man laver Det almene byggeri har en standard fr ttaløknmisk beregning, sm dg kun mfatter klimaskærmen. Side 13 af 15
De driftsmæssige krav, der stilles til rådgiverne, er typisk ikke hæftet p på DV-systemer. Rådgiverne får ikke klar besked m, hvilken infrmatin der ønskes. Det vil generelt være en frdel at få større fkus på driftens behv i prgrammeringsfasen. 5. Priritering af behv Afslutningsvist pririterede deltagerne de diskuterede behv i frhld til, hvr vigtige de er fr branchen at få løst. Deltagerne fik hver især 10 pints, sm de kunne frdele på emnerne. Tabellen viser den samlede pintfrdeling. Område Kmmentarer Pints Egenskabsdatasæt fr driftsbjekter Egenskabsdata er frudsætningen fr de andre ting, ellers kan man ikke tale m udveksling af digitale data (+) 48 Der skal være standarder fr data, så de kan bruges igen i frskellige systemer (+) Egenskabsdatasæt er frudsætningen fr, at der kan ske en autmatisk indlæsning, hvilket må være målet (+) Det er udviklingen fremadrettet, at man får et fælles sprg g kan lave autmatikken (+) Egenskabsdata fr driftsbjekter gavner driften fremadrettet, ved at man nemt kan se, hvrdan en bygningsdel skal driftes, så man sparer tid på ikke at slå p i byggemanualer (+) Det vil skabe str værdi fr rådgiverne, hvis de kan få brugbare prduktbjekter fra prducenterne, sm kan føres direkte ind i BIM-mdellen. Dette kræver, at der stilles krav til prducenternes data (+) Det gælder m at strukturere data bedre, så bliver de mere nyttige fr driften (+) Det er fr driftsherren vigtigere via egenskabsdata at kunne se alle bygningerne i driften, end det er at få afleveret data til driften (+) Driftsherrerne kan m nødvendigt lave deres egne egenskabsdatasæt, dvs. man kan gdt få digital aflevering uden at have egenskabsdatasæt. Det vigtigste er, at data flyder igennem systemerne (-) Side 14 af 15
Standard fr digital aflevering - autmatisk indlæsning af as-built infrmatin i driftssystemer En standard fr digital aflevering er vigtig (+) En standard vil være meget nyttig fr dem, der skal aflevere (+) Ensartethed i afleveringen er et strt ønske fr dem, der arbejder med dette i deres hverdag (+) Det giver værdi fr bygherren at mdtage materiale ud fra en standard (+) Det skal være åbne frmater, der kan læses uafhængigt af systemet g nget, der linkes til den mest pdaterede infrmatin, der findes m prdukterne. Det kan være en BIM-mdel eller en database, sm vedligehldes af driftsherren, når byggeriet først er i drift. Digital aflevering burde i bekendtgørelsen g andre steder mtales sm: Aflevering af digitale data 45 Indarbejdelse af bygningsdriftens behv i prgrammeringsfasen Man skal tage de flk i ed, sm arbejder med driften i dagligdagen de kan sidde med guldkrt, sm andre ikke får øje på (+) Driftsflkene skal trækkes ind ved, at der er en standard, sm de skal frhlde sig til (+) Dette er et rganisatrisk prblem g ligger uden fr cunecs regi (-) 17 Side 15 af 15