Klik her for at læse Eksportrådets originale invitation til All Energy
Kandidatspeciale, Aalborg Universitet Digital aflevering til Driftsherren Kobling mellem byggeprojekt og bygningsdrift Lasse Møller 2012 Titelblad Titel Digital aflevering til Driftsherren Undertitel: Kobling mellem byggeprojekt og bygningsdrift Uddannelsesinstitution Aalborg Universitet Uddannelse Cand. Scient. Techn. i Byggeri og Anlæg med specialisering i Bygningsinformatik Opgave Kandidatspeciale, E2011 Forfattere Lasse Würtz Møller (lmolle10@student.aau.dk) Vejledere Ekstern lektor Kristian Birch Pedersen, Exigo Consult, Lektor Kjeld Svidt Oplag Digital publicering Udgivelsesdato 13. januar 2012 Sprog Dansk Sidetal 123 sider (i alt 155 med bilag) Anslag 227.927 anslag med mellemrum (for siderne 7-123) 2 Forord Denne rapport er et resultat af projektarbejdet på kandidatuddannelsen cand. scient. techn. i byggeri og anlæg med specialisering i bygningsinformatik (4. semester), og er specialeprojektet der afslutter uddannelsen. Arbejdet er udført i perioden den 1. september 2011 til den 13. januar 2012 ved det Ingeniør-, Natur- og Sundhedsvidenskabelige Fakultet, Aalborg Universitet. Projektet er sket under vejledning af ekstern lektor Kristian Birch Pedersen & lektor Kjeld Svidt. Projektet er på 30 ECTS point og tager udgangspunkt i spørgsmålet " Hvordan kan informationsudvekslingen mellem rådgiverne, entreprenørerne og driftsherren forbedres?" Rapporten henvender sig til personer, der har en grundlæggende byggeteknisk viden samt interesse for udviklingen og fremtiden i digitaliseringen af byggebranchen. Jeg vil gerne takke aarhus arkitekterne for at åbne deres kontor for mig i projektperioden og for at give mig adgang til casen, Odense City Center, samt for deres vejledning i forbindelse med projektet. Jeg vil også takke de involverede parter i casen, Odense City Center, (Steen og Strøm, Grontmij, Moe og Brødsgaard) for deres engagement i projektet samt de andre virksomheder, der har stillet til rådighed for interviews (Skanska, Teknisk Forvaltning (Aalborg Universitet), Dan-Ejendomme, Slots- og ejendomsstyrelsen og MT Højgaard). 13-01-2012 Lasse Møller ____________________ © Denne opgave er udarbejdet af en studerende ved Aalborg Universitet. Kopiering eller anden gengivelse af opgaven eller dele af den, er kun tilladt med forfatterens tilladelse. 3 Resumé Denne rapport undersøger, hvordan informationsudvekslingen mellem byggesagens parter og driftsherren kan forbedres. Der er taget udgangspunkt i driftsherren og dennes arbejde med Facilities Management, for at undersøge hvilket behov driftsherren har for informationer. Rapporten bygger på den opfattelse at bygningsmodeller og digitale værktøjer kan optimere byggesagen, afleveringen og den efterfølgende drift. Der er indledningsvist givet en introduktion til de grundlæggende begreber, aktører og samarbejdsformer, som er anvendt i rapporten. Dernæst er det undersøgt, hvilke projekter og løsninger der findes indenfor området. I rapporten er der udført en række interviews med driftsherrer, rådgivere og entreprenører for at belyse behov og problemstillinger, der er i forbindelse med den digitale aflevering. Der er udført tests på forskellige CAFM-systemer, og en analyse af hvordan de støtter driftsherren i dennes arbejde. Testen viser også hvilke data CAFM-systemerne kan modtage fra den digitale aflevering. Kravstillelsen er et vigtigt punkt for at sikre, at de rigtige krav til den digitale aflevering specificeres fra projektets start. I rapporten er der givet en præsentation af, hvordan en god kravstillelse stilles. Af analysen fremgår det, at driftsherren gerne vil have præcise, relevante, målrettede data om drift og vedligehold om det byggeri, han modtager. Det fremgår også, at driftsherrerne gerne vil modtage bygningsmodeller til dokumentation af byggeriet, men at bygningsmodellerne ikke skal indeholde D&V-data. Der er derfor præsenteret en løsning i rapporten, hvor D&V-informationerne afleveres i en database, der bygger på bygningsmodellens struktur, men som kan læses og redigeres i skemaform. For at hjælpe driftsherren, med at anskueliggøre udgifterne til driften og de økonomiske konsekvenser som valg i projekteringen har for driften, er der udformet et modelbaseret driftsbudget. Driftsbudgettet kan vise og sammenligne udgifterne til driften for flere forskellige bygninger. Der er udført en vurdering af de testede CAFM-systemer i forhold til hinanden. Der er ligeledes givet et forslag til, hvordan en applikation, der håndterer fejlmeldinger, kan se ud. Til slut i rapporten er der foretaget en evaluering af nogle af de løsningsforslag, der præsenteres i rapporten, i samarbejde med nogle af byggeriet parter. 4 Indholdsfortegnelse 1 2 3 4 Indledning .................................................................................................................................................. 7 1.1 Problemstilling ................................................................................................................................... 9 1.2 Problemafgrænsning ......................................................................................................................... 9 1.3 Metode ............................................................................................................................................ 10 Introduktion til begreber, aktører og samarbejdsformer ....................................................................... 14 2.1 Begrebet aflevering ......................................................................................................................... 14 2.2 Facility/Facilities Management, FM ................................................................................................ 14 2.3 Bygningsejeren, bygherren, driftsherren og deres behov............................................................... 17 2.4 Samarbejdsformer ........................................................................................................................... 19 2.5 Building Information Modeling, BIM ............................................................................................... 23 State of the art......................................................................................................................................... 26 3.1 BIM for byggeriet parter .................................................................................................................. 26 3.2 Behovet for bedre informationsudveksling..................................................................................... 31 3.3 Det digitale byggeri og bygherrekravene ........................................................................................ 34 3.4 DACaPo-projektet ............................................................................................................................ 37 3.5 COBie, Construction Operations Building information exchange ................................................... 39 3.6 Kravkonfigurator.............................................................................................................................. 41 3.7 Styring af proces, semantik og data ................................................................................................ 42 3.8 Dataformat ...................................................................................................................................... 43 3.9 Klassifikation .................................................................................................................................... 44 3.10 Proces .............................................................................................................................................. 46 3.11 Computer Aided Facilities Management, CAFM ............................................................................. 53 3.12 Arealstyringssytemer ....................................................................................................................... 56 3.13 Central Tilstandskontrol og Styring, CTS ......................................................................................... 57 3.14 Mindre applikationer til styring af aflevering .................................................................................. 57 Casebeskrivelse ....................................................................................................................................... 61 4.1 5 Organisationsdiagram ..................................................................................................................... 63 Analyse .................................................................................................................................................... 64 5.1 Analyse af driftsherren .................................................................................................................... 64 5.2 Analyse af rådgiver .......................................................................................................................... 71 5.3 Analyse af entreprenør .................................................................................................................... 75 5 5.4 Styring af processen fra Koncept til Aflevering ............................................................................... 79 5.5 Analyse af driften og CAFM-systemer ............................................................................................. 84 6 Løsningsforslag ........................................................................................................................................ 99 6.1 Introduktion til løsningsforslag........................................................................................................ 99 6.2 Kravstillelsen .................................................................................................................................. 102 6.3 Håndtering af D&V gennem byggeprojektet ................................................................................. 106 6.4 Afleveringen .................................................................................................................................. 117 6.5 Det optimale CAFM-system. .......................................................................................................... 117 7 Evaluering .............................................................................................................................................. 120 7.1 Evaluering med Aarhus Arkitekterne ............................................................................................ 120 7.2 Evaluering med Dan-Ejendomme a/s ............................................................................................ 120 7.3 Evaluering med Teknisk Forvaltning, AAU ..................................................................................... 121 8 Konklusion ............................................................................................................................................. 122 9 Perspektivering ...................................................................................................................................... 123 10 Bibliografi........................................................................................................................................... 124 11 Bilag ................................................................................................................................................... 129 11.1 Bilag A: Referat af interview med Teknisk forvaltning, AAU ......................................................... 130 11.2 Bilag B: Referat af interview med Slots- og EjendomsStyrelsen ................................................... 133 11.3 Bilag C: Referat af interview med Dan-Ejendomme a/s ................................................................ 135 11.4 Bilag D: Referat af interview med Steen og Strøm a/s .................................................................. 138 11.5 Bilag E: Referat af interview med Skanska a/s .............................................................................. 141 11.6 Bilag F: Referat af interview med Grontmij ................................................................................... 143 11.7 Bilag G: Referat af interview med Aarhus arkitekterne ................................................................ 146 11.8 Bilag H: Referat af interview med Moe og Brødsgaard a/s ........................................................... 149 11.9 Bilag I: Referat af interview med MT Højgaard a/s ....................................................................... 153 6 Kap: 1-2-3-4-5-6-7-8-9 Indledning 1 Indledning Driften og afleveringen af informationer til driftsherren er et område, der er blevet forsømt i forhold til andre dele af byggeriet i arbejdet med digitaliseringen af byggeriet (Bygherreforeningen, 2010). Ved at se på væksten indenfor drift af bygninger fremgår det, at den er stagnerende ligesom resten af byggebranchen (se figur 1). Der er derfor et tydeligt behov for at optimere branchen. Figur 1, Væksten i den generelle økonomi sammenlignet med byggeriets brancher, EBST 2011 De senere år har byggebranchen oplevet større fokus på brugen af de digitale værktøjer og metoder. Begreber som Informations- og KommunikationsTeknologi, IKT, digitalt byggeri og Building Information Modeling, BIM, er med tiden blevet en del af hverdagen i byggeriet. Der efterhånden en konsensus om, at den traditionelle måde at gøre tingene på kan forbedres, og at BIM er fremtiden i byggeriet. Flere og flere firmaer har på denne baggrund set muligheden i at effektivisere arbejdsgange ved at anvende digitale bygningsmodeller, som grundlaget i deres arbejde. (Bips, 2008, s. 6) BIM Handbook definerer BIM således: "Med henblik på denne bog, definerer vi BIM som en modelleringsteknologi og en række tilhørende processer til at producere, kommunikere og analysere bygningsmodeller. ” (Chuck Eastman, 2008) Hvis BIM skal fungere optimalt, er det nødvendigt, at der sker samarbejde om, hvordan informationsudvekslingen mellem aktørerne skal foregå. Der er flere organisationer både international og nationalt, der beskæftiger sig med dette arbejde. BuildingSMART står for at definere standarder for filformat, klassifikation og proces, der gælder på tværs af landegrænser. Dertil findes der en række nationale organisationer, 7 Indledning Kap: 1-2-3-4-5-6-7-8-9 som ligeledes arbejder indenfor dette felt. I Danmark har bips stået for dette arbejde sammen med ”Det Digitale Byggeri”. På denne baggrund er IKT-bekendtgørelsen1 blevet udviklet, som stiller konkrete krav til anvendelse af IKT i byggebranchen for offentlige bygherrer. Dermed tvinges byggebranchen til at anvende mere IKT, hvis de vil byde på de statslige projekter, der er omfattet af bekendtgørelsen. Dette projekt behandler den digitale aflevering til bygherren, og omhandler dermed både afleveringer der er omfattet af bestemmelserne i IKT-bekendtgørelsen, og afleveringer der ikke er. Bygherrerne er generelt opmærksomme på at kunne optimere driften af deres bygningsmasse, og derfor har nogle af de mest innovative bygherrer stor fokus på, hvordan øget digitalisering og anvendelse af bygningsmodeller kan hjælpe med denne optimering. (Bygherreforeningen, 2010, s. 3) En undersøgelse foretaget af National Institute of Stadards and Technology, NIST, viser at der årligt spildes 15 millarder $ i USA, som følge af dårlig informationsudveksling i byggeriet. Forudsat at problemerne er de samme i Danmark er der et stort potentiale for bygherrer og driftsherrer ved at sikre en bedre informationsudveksling da det er dem der i sidste ende betaler for den tabte værdi. (National Institute of Stadards and Technology , 2009) Figur 2, Informationsniveau ved traditionel tegningsbaseret aflevering (A-B) og BIM-baseret aflevering (C). BIM Handbook 2008 I BIM fokuseres der på at bevare de informationer, der bliver skabt gennem projektet. Figur 2 viser BIM Håndbogens (BIM Handbook) eksemplificering af forskellen mellem den traditionelle papirbaserede aflevering (A og B), hvor der tabes information løbende i projektet når information overgår fra en part til en anden, og den BIM-baserede aflevering (C), hvor den skabte information bevares gennem projektet. (Chuck Eastman, 2008) Det er denne graf er vigtig for at forstå potentialet at stille krav om modelbaseret digital aflevering – det er ganske enkelt ikke acceptabelt, at der er så meget information, der går tabt i løbet af projektet. 1 Bekendtgørelse nr. 1381 13.12.2010 om ”krav til anvendelse af Informations- og Kommunikationsteknologi i byggeri” 8 Kap: 1-2-3-4-5-6-7-8-9 Indledning 1.1 Problemstilling I den traditionelle arbejdsmetode sker det, at aflevering af informationer ofte sker i mange forskellige dokumenter med en uoverskuelig struktur. Samtidig er informationerne ofte ”døde” og skal bearbejdes, for at et andet system kan læse dem. Dette gør, at det tager driftsorganisationen lang tid at sortere i projektet for at finde de rigtige informationer og bearbejde dem, så de passer i deres driftssystem. Tankegangen med at anvende BIM i en byggesag er, at de informationer, der skabes, skal bevares og være konsistente. Ved at aflevere BIM-projektet digitalt kan bygherren nemmere finde og bruge informationerne fra projektet til driften. Det er dog stadig for diffust kun at stille krav til, at der skal afleveres digitalt. Der har været en del problemer for de bygherreorganisationer, der er omfattet af bygherrekravet om digital aflevering, med at definere deres behov overfor rådgiverne (Danvold, 2011). Ofte ses det at kravet bare er noteret i aftalegrundlaget, uden at der er taget yderlig stilling til, hvad bygherren gerne vil have ud af kravet. (Kaa, 2011), (YdingSørensen, 2011) Kravet skal følges op af en specifikation af, hvad bygherren har brug for, hvis bygherren skal kunne anvende projektmaterialet direkte i driften. Dertil skal afleveringen styres gennem hele projektet for at sikres det specificerede materiale afleveres. Dette giver anledning til følgende initierende spørgsmål for projektet: ”Hvordan kan informationsudvekslingen mellem rådgiverne, entreprenørerne og driftsherren forbedres?” 1.2 Problemafgrænsning Denne opgave behandler problemstillingerne omkring digital aflevering. En stor drivkraft for at dette emnes aktualitet er bygherrekravet om digital aflevering fra IKT-bekendtgørelsen, og derfor behandles dette også indgående i rapporten. I denne sammenhæng vil der være naturlige referencer til de 4 andre bygherrekrav, men det er ikke muligt i dette projekt at behandle alle krav dybdegående. I dette projekt er hovedvægten af empirien lagt på en konkret byggesag, casen Odense City Center (OCC). Der vil også være generelle eksempler fra byggebranchen, men disse er ikke behandlet så dybdegående som den konkrete byggesag. Konklusionerne fra denne rapport vil derfor bygge på de forudsætninger, der er til stede i casen. Projektet vil gøre brug af praktiske forsøg til at påvise, hvordan det kan lade sig gøre at sikre en god modelbaseret digital aflevering til driftsherren. 9 Kap: 1-2-3-4-5-6-7-8-9 Indledning 1.3 Metode Rapporten overordnede formål er at undersøge ”hvordan informationsudvekslingen mellem rådgiverne, entreprenørerne og driftsherren forbedres”. Der er taget udgangspunkt i Aarhus Arkitekternes arbejdsproces og deres engagement i byggesagen OCC, Odense City Center, men andre relevante aktører indenfor byggebranchen vil også blive inddraget. Den centrale metode for rapporten er Contextual Design. Denne metode vil især blive anvendt til at indsamle informationer og til at beskrive nuværende arbejdsgange. Det er ikke tanken, at denne rapport skal danne grundlag for udviklingen af et nyt system, men snarere belyse behovet til digitalisering, og vurdere hvilke applikationer, der understøtter behovet bedst muligt. Som citatet herunder viser, så er det ikke altid, at brugerne selv kan definere de systemer og applikationer, de har behov for. Det er derfor vigtigt at analysere brugernes behov og præsentere nye løsninger for dem. ”Når noget er så kompliceret, er det meget svært at designe produkter ud fra fokusgrupper. For det meste ved folk ikke hvad de ønsker, før man viser det til dem.” (Jobs, 1998) 1.3.1 Indsamling af empiri Det er i høj grad interviewene, der danner empirien i denne rapport. Der vil dog også inddrages undersøgelser foretaget af andre projekter samt egne observationer af afprøvninger. Sidstnævnte drejer sig især om de applikationer, der er undersøgt i forbindelse med projektet. Interviewene i denne rapport er foretaget på forskellige repræsentanter indenfor byggebranchen. Der er lagt op til at disse skal være semi-strukturerede, for at give plads til at de interviewede kan komme med deres egne erfaringer og synspunkter. 1.3.2 Grounded theory Der er i denne rapport anvendt metoden, Grounded Theory, som tilgang til empirien. Grounded Theory bygger på en videnskabsteoretisk opfattelse af, at verden kan beskrives ud fra nogle enkelte tilfælde. Det er denne iagttagelsse af verdenen, der danner grundlaget for at kunne opbygge og fremsætte teorier. (Hylander, 2005) Metoden er anvendt som grundlag for forståelse af videnskabsteori, som denne rapport bygger på. Som det er beskrevet i det følgende afsnit, så er der anvendt Contextual design til den mere praktiske tilgang, til det at udvælge og analyse på empiri samt at vælge og udvikle nyt software. 1.3.3 Contextual design Denne rapports praktiske tilgang til projektet bygger på metoden Contextual Design. Metoden er udviklet af Beyer og Holtzblatt, og bruges til at udvikle systemer, hvor der er særlig fokus på brugeren. Forskellen fra tidligere tankegange er, at systemudvikleren nok har en stor viden om den tekniske systemudvikling, men de egentlige arbejdsprocesser har den enkelte bruger langt bedre indblik i. Derfor er kardinalreglen at systemet skal udvikles i samarbejde med brugeren og til brugeren. (University of Twente, 2011) 10 Indledning Kap: 1-2-3-4-5-6-7-8-9 Contextual Design er delt op i 7 trin, for at give bedre overblik. Metoden består af følgende 7 trin: 1) Contextual Inquiry, 2) Work Modelling, 3) Consolidation, 4) Work redesign, 5) The User Enviroment Design, 6) Test with Customers, 7) Putting into practice. De enkelte trin er yderligt forklaret herunder. (Beyer, Holtzblatt, 1998) Contextual Inquiry (kontekstuel undersøgelse) er en undersøgelsesmetode, der bygger på den kvalitative tilgang til indsamling af data. Der lægges vægt på at observere og samtale med brugeren, mens denne arbejder i sit normale miljø. Hermed er det de problemstillinger, som brugeren til dagligt oplever, der kommer til at styre interviewet/observationen. Det er altså vigtigt at den interviewende ikke tager brugeren ud af dennes normale kontekst, men opsøger brugerens arbejdsstation. Work Modelling (Arbejdsmodellering) er en metode til at kortlægge de informationer, der er kommet ud af Contextual Inquiry. De indsamlede informationer fra interviewene analyseres, og de centrale problemstillinger og emner udvælges. På denne baggrund udarbejdes der arbejdsmodeller, der beskriver arbejdsopgaver og -miljø. Disse arbejdsmodeller er delt op i fem forskellige typer: Flow model – beskriver kommunikation, koordinering, interaktion, roller og ansvar mellem aktører. Sequence model – beskriver arbejdsgangene for den enkelte aktivitet. Cultural model – beskriver pres- og indflydelsesfaktorer i arbejdsmiljøet. Artifact model – beskriver de fysiske objekter der anvendes i arbejdsmiljøet. Physical model – beskriver den fysiske arbejdsplads. (Beyer & Holtzblatt, 1998) Consolidation (Konsolidering) er en metode til at samle de indsamlede undersøgelser i grupperinger. Det er vigtigt, at alle data bevares når flere sammenlignelige interviews sammenstilles. Der kan i denne forbindelse anvendes et affinity-diagram til at beskrive konsolideringen. Diagrammet er struktureret efter bottomup metoden. Dermed konsolideres der et helhedsbillede. Work redesign (innovation af arbejdsmetode) er det trin, hvor de konsoliderede arbejdsmodeller (work models) danner grundlag for forslag til ændringer af arbejdsgange. De fremsatte forslag vil typisk tage udgangspunkt i de problemstillinger, som er blevet kortlagt under interviewene, og vil som regel resultere i en ændring af organisationen og et nyt system. Denne fase kan deles op i yderlig 2 underfaser, visioning og storyboarding. Visioning handler om at fortælle historier om, hvordan systemet kan fungere fra brugerens synsvinkel. Storyboarding handler om at få visionerne gjort konkrete ved at udarbejde skitser over de forskellige scenarier, som systemet skal dække. The User Enviroment Design (Design af brugermiljø) er det trin, hvor interfacet mellem brugeren og systemet bliver designet. Der anvendes et User Enviroment Design diagram til at kortlægge de funktioner, som brugeren kan se, eller som er vigtige for brugeren. Det er ligeledes her at strukturen i systemet fastlægges efter de nye arbejdsgange, så det er et naturligt flow for brugerne. Dette diagram skal omfatte en beskrivelse af systemets enkelte dele og relationerne mellem dem, hvilket kan danne grundlaget for udvikling og design af det endelige system. Test with Customers (afprøvning med kunder) er den del, hvor de nye ideer bliver afprøvet med brugeren. Det kan både dreje sig om papirskitser og færdige dele af systemet, der afprøves. Dette er en vigtig del, der i nogle projekter bliver syltet lidt, men det kan spare mange ressourcer, at systemet er så gennemtestet som muligt, inden det implementeres i virksomheden. Dette er en iterativ proces der bør gentages til at det ønskede resultat er opnået. (Beyer & Holtzblatt, 1998) 11 Indledning Kap: 1-2-3-4-5-6-7-8-9 Putting into practice (implementering) sidste trin er at implementere systemet. Contextual Design beskriver ikke denne del så udførligt men andre metoder med samme fokus på involvering af brugeren kan med fordel anvendes. (Beyer & Holtzblatt, 1998) Det kan fx være John P. Kotters 8-trinsmodel for forandringsledelse. Modellen beskriver, hvordan en forandring (fx et nyt system) implementeres og forankres i en organisation. Det er i den forbindelse essentielt, at den brede organisation og ledelsen tager ejerskab for systemet. Hvis dette ikke sikres, risikeres det at systemet aldrig blevet implementeret ordentligt (Lægaard, 2009). Den måde systemdesignet foregår på i Contextual Design skulle dog gerne sikre, at der skabes ejerskab for systemet tidligt i processen. Contextual Design foreskriver, at der foretages undersøgelser (contextual inquiry) af 10-20 personer, for at kunne afdække brugernes normale arbejdsprocesser og behov. I dette projekt er der foretaget undersøgelser på ca. 8 personer. 1.3.4 Udvælgelse af software I ISO-standarden for IDM, som er udviklet af BuildingSMART, er der defineret tre forskellige tilgange til det at implementere nyt software i en organisation: ”Process discovery”, ”Business rule customized” og ”Reverse engineering”. I denne rapport er der anvendt som BuildingSMART kalder ”Reverse Engineering”. Ved denne tilgang forudsættes det, at der findes software, der kan understøtte informationsudvekslingen. Der startes med at definere det scenario, som skal understøttes, og derefter vælge det software, der passer bedst til behovet. Der er derfor udført undersøgelser over forskellige systemer og applikationer, der kan understøtte driftsherrerne og den digitale aflevering. (ISO 29481-1:2010) 12 Kap: 1-2-3-4-5-6-7-8-9 Indledning Læsevejledning Efter dette kapitel følger der 7 kapitler, som det er illustreret på figur 3. Kapitel 2 og 3 introducerer den grundlæggende teori, som danner grundlaget for resten af rapporten. De to følgende kapitler præsenterer empirien og analyserer på denne. Kapitel 6 og 7 giver et løsningsforslag på grundlag af de problemstillinger, der er fundet i den foregående analyse. Til slut konkluderes der på rapporten og gives en perspektivering på fremtiden indenfor digital aflevering. Sidst i rapporten er alle de anvendte kilder og bilag samlet. 2. Introduktion til begreber, aktører og samarbejdsformer •Afsnittet beskriver de grundlæggende begreber, aktører og samarbejdsformer for introducere læseren til det forståelsesgrundlag som rapporten bygger på. 3. State of the art •Afsnittet giver en præsenatation af hvad status er på området omkring digital aflevering. 4. Casebeskrivelse •Casebeskrivelsen giver en introduktion til det projekt som danner case og en del af den empiri der er anvendt i projektet. 5. Analyse •I analyse er empirien præsenteret og analyseret, hvilket danner grundlaget for det efterfølgende løsningsforslag. 6. Løsningsforslag •I Løsningsforslaget præsenteres der en række løsninger der kan være med til at løse nogle af de problemstillinger der fremgår af analysen. 7. Evaluering 8. og 9. Konklusion og perspektivering •I dette afsnit evalueres løsningsforslagene i samarbejde med nogle af de involverede parter •I konklusionen samles der op på projektets resultater, og efterfølgende perspektiveres der mulighederne for fremtidig udvikling på området. Figur 3, Oversigt over opbygningen af rapporten. 13 Introduktion til begreber, aktører og samarbejdsformer 2 Kap: 1-2-3-4-5-6-7-8-9 Introduktion til begreber, aktører og samarbejdsformer Dette afsnit giver en introduktion til de grundlæggende begreber, aktører og samarbejdsformer indenfor rapportens fokusområde. Afsnittet er med til at give en grundlæggende opfattelse af begreber, der ligger til grund for rapportens fokusområde. 2.1 Begrebet aflevering Ordet aflevering dækker i byggeriet over aflevering af et stykke arbejde og aflevering af dokumentation af det udførte arbejde. I denne rapport fokuseres der på afleveringen af dokumentationen. Dette skal forstås som en udveksling af informationer, der sker mellem bygherre (modtager af informationer) og rådgivere og entreprenører (overdrager af informationer). Dette skal ses ud fra den forståelse at der er en ”efterspørger” af et byggeri (bygningsejer, investor, ol.) og en leverandør af byggeriet (rådgivere, entreprenører ol.), mens bygherren og driftsherren er formidler mellem de to. (Jensen, Håndbog i Facilities Management, 2011, s. 120-123) En vigtig problemstilling indenfor aflevering er, at denne informationsudveksling har to formål: at dokumentere det afleverede byggeri (proces og produkt), og danne grundlag for bygherrens drift og vedligehold af bygningen. Den traditionelle forståelse af aflevering til bygherren bygger mest på den opfattelse, at det afleverede projekt skal dokumenteres. Med tiden er bygherren dog blevet mere opmærksom på at stille krav til det afleverede materiale. 2.2 Facility/Facilities Management, FM Begrebet Facility Management (eller Facilities Management), FM, er blevet mere og mere almindeligt at anvende i Danmark. Baggrunden for at anvende udtrykket er, at det beskriver en mere nuanceret forståelse af, hvad det vil sige at drive en bygning. FM bliver ofte blandet sammen med det mere traditionelle udtryk, Drift og Vedligehold, som bl.a. kendes fra ydelsesbeskrivelser og juridiske aftaler. FM dækker dog over et langt større område. Hvor Drift og Vedligehold kun knytter sig til bygninger, så er FM en ledelsesdisciplin, der dækker over alle de fysiske rammer for en virksomhed og de dertil knyttede servicefunktioner. (Jensen, Håndbog i Facilities Management, 2011) 14 Introduktion til begreber, aktører og samarbejdsformer Kap: 1-2-3-4-5-6-7-8-9 2.2.1 Definition DFM-netværket har besluttet sig for en definition i 1998, som skal give klart billede af, hvad FM dækker over: ”Facilities Management er koordineret styring af alle former for fysisk og teknologisk støtte til virksomhedens primære arbejdsprocesser: 1. Ejendomme og lokaler. Køb, salg, leje, vedligehold, lokaledisponering, møblering, klima, renhold, affald og sikkerhed. 2. Informationsteknologi. Computerudstyr – hardware og software, telefonanlæg, kopiering bibliotek. 3. Interne services. Post, kantine, reception, vagt/sikring, transport, rejser.” (Jensen, Håndbog i Facilities Management, 2011, s. 11) Når der dermed anvendes Facility eller Facilities Management som begreb i stedet for mere traditionelle danske begreber og ord, er det derfor fordi, at det dækker over et langt større område end selve bygningen. Det drejer sig om alle de faciliteter, der støtter den anvendelse, der er af bygningen. Set ud fra en byggeteknisk baggrund bliver der fokuseret meget på punkt 1 i den ovenstående liste, men de andre punkter er lige så vigtige for at støtte den anvendelse, der er af bygningen. En gennemgang af Gyldendals og Gads ordbøger (internetudgaver) giver en forklaring af facilitet eller faciliteter som noget, der gør livet lettere, mere bekvemt og/eller giver en fordel. Ud fra den forklaring er det nemt at forstå, at de punkter, der er nævnt af DFM-netværket herover, skal ses som et samlet område. (Gyldendals åbne encyklopædi, 2011) Figur 4, FM og virksomhedens kernefunktioner, Egen tilvirkning efter ”Håndbog i facilities management” FM skal dermed forstås som de supportfunktioner, der skal til for at ”facilitere” virksomhedens kernefunktioner, som figur 4 viser. Det er muligt at underinddele supportfunktioner i de tre områder, der tidligere er nævn: ejendomme og lokaler, IT og intern service. Det er igen muligt at underdele disse efter strategiske, taktiske og operationelle opgaver. 2.2.2 Arbejdet med Facility Management Arbejdet med FM har ændret sig meget over de sidste mange år. Som nævnt i det foregående afsnit, så er der kommet større fokus på alle de funktioner, der faciliterer kernefunktionen i virksomheden. Det har ført til at virksomheder har større fokus på dette område, og det er derfor blevet et selvstændigt arbejdsområde. Der er endda en tendens til, at det begynder at blive betragtet som et fagområde – altså et område der 15 Introduktion til begreber, aktører og samarbejdsformer Kap: 1-2-3-4-5-6-7-8-9 ikke kun har fælles genstandstandsområde, men hvor fællesskabet også deler uddannelsesbaggrund. Det kan her nævnes, at det på flere uddannelser er muligt at specialisere sig indenfor FM. (Jensen, Håndbog i Facilities Management, 2011, s. 22) Grunden til at FM er blevet et særskilt arbejdsområde har mange årsager, som bunder i den generelle udvikling i samfundet. Den store industrialisering af byggeriet i 1960’erne har gjort, at der i denne periode var større fokus på kvantitet end kvalitet, hvilket førte til bygninger med mange fejl. Dertil var bygningerne til stadighed blevet mere og mere komplicerede, og der var blevet fyldt med flere og flere tekniske installationer. Dertil har de forskellige økonomiske kriser gjort, at der var større fokus på at minimere de udgifter der forbundet med bygninger. Disse forhold har blandt andet gjort, at der har været behov for en professionel styring af FM-området. (Jensen, Håndbog i Facilities Management, 2011, s. 19) Der er ligeledes sket en institutionalisering af FM-området både nationalt og internationalt. I 1991 blev Dansk Facilities Management – netværk, DFM-netværk, dannet af nogle af de største bygningsejere i Danmark. Formålet med foreningen er: • At udvikle fagområdet Facilities Management • At udbrede kendskabet til fagområdet ved at formidle viden • At fremme samspillet mellem praksis, uddannelse og forskning • At være bindeleddet til Facilities Management internationalt. (Jensen, Håndbog i Facilities Management, 2011, s. 6) På den internationale scene kan interesseorganisationen, IFMA, nævnes, som blev dannet i USA i 1980, og som i dag har 19.000 medlemmer fordelt på 78 lande. Dertil kan der nævnes EuroFM, som er dannet af flere nationale FM-interesseorganisationer, blandt andet DFM. Et af formålene men EuroFM er at definere jobprofiler for FM, der kan bruges som grundlag for indholdet i uddannelser ol. (Jensen, Håndbog i Facilities Management, 2011, s. 23) 2.2.3 FM-værktøjer Der findes i dag mange forskellige FM-værktøjer som kan anvendes til at støtte forskellige områder indenfor FM. Disse systemer kaldes Computer Aided Facilities Management, CAFM. Som det følgende citat viser, er det ikke altid muligt at lave en skarp definition af, hvad der er CAFM-systemer, og hvad der ikke er. Mange organisationer anvender en broget sammensætning af softwaresystemer til at styre FM opgaver, som beskrevet herunder af Per Anker Jensen. There is a great diversity in the IT-systems that are used in the FM organizations with ERP-systems and specialized maintenance systems as the most wide spread, while the internationally well known FM-systems like Archibus and Aperture are used by very few organizations in Denmark. Custom-developed systems and combinations of different systems are used widely. (Jensen, Digital Handover of Data from Building Projects to Operation, 2006, s. 3) Som Per Anker Jensen beskriver i citatet, anvendes der ofte kunde-tilpassede CAFM-systemer eller en kombination af flere systemer i Danmark, mens de internationale FM-systemer kun har en meget begrænset udbredelse. Årsagen til dette er ikke helt klar. De mange forskellige lokale FM-systemer sammen med ud- 16 Introduktion til begreber, aktører og samarbejdsformer Kap: 1-2-3-4-5-6-7-8-9 bredt tilpasning af FM-systemerne gør, at det er svært at kortlægge brugen af CAFM-systemer. Der vil dog senere i rapporten blive givet en beskrivelse af et udsnit af disse systemer. 2.3 Bygningsejeren, bygherren, driftsherren og deres behov Når bygherren beskrives i forskellige litteraturer er denne ofte beskrevet som både bygherre og driftsherre. Forvirringen mellem byg- og driftsherrerollen, og om begge roller er inkluderet i betegnelsen bygherre, har gjort der sværere at kommunikere præcist indenfor branchen omkring byg- og driftsherrers behov. På den ene side er hver rolle klart defineret, hvor bygherren er bestilleren af byggeriet, mens driftsherren står for driften af det færdige byggeri. På den anden side er der mange forskellige sammensætninger af organisation og forskellige typer byggerier der gør, at bygherre- driftsherrefunktionerne kan være sammenblandet på alle mulige måder. (Jensen, Håndbog i Facilities Management, 2011, s. 120-121) En tredje rolle er bygningsejeren, som kan hænge tæt sammen med bygherrerollen, men det kan også være to separate roller, hvis bygningsejeren ikke har kompetencerne til at udfylde bygherrerollen. figur 5 viser de tre styrende roller i en byggesag, som alle kan være samlet i én rolle (nogle gange i samme person), eller være opdelt på forskellige måder. Figur 5, Oversiget over de styrende parter i en byggesage Teoretisk set behandles bygningsejeren, bygherren og driftsherren som veldefinerede roller. Dette er dog langt fra virkeligheden i mange byggesager. Ofte er der en kløft mellem bygherren/bestilleren af byggeriet og driftsherren. Der er en del virksomheder, der bygger for at sælge videre (fx Skanska), og dertil er der en del bygningsejere, der ikke selv administrerer og driver deres ejendomme (fx Pensionskasserne (se interview med Dan-Ejendomme)). Denne kløft kan skabe udfordringer i forhold til at stille de rigtige krav til D&Vdata i forbindelse med afleveringen, når det samtidigt er begrænset, hvad driftsherren modtager af informationer fra projektet, når det er afsluttet. 17 Introduktion til begreber, aktører og samarbejdsformer Kap: 1-2-3-4-5-6-7-8-9 2.3.1 Bygningsejerens behov Bygningsejeren er typisk mere distanceret fra selve byggesagen end bygherren og driftsherren. Det fremgår især i de tilfælde, hvor bygningsejeren ikke er den samme som brugeren af bygningen. Det kan fx være pensionskasserne, der ejer bygningen, men lejer den ud og har et andet selskab til at foretage al administration i forbindelse med driften af bygningen. Bygningsejeren, som rolle, vil derfor ofte fokusere på hvor meget værdi denne får ud af sin investering. 2.3.2 Bygherrens behov Der er forskelligt fokus fra bygherrens side og fra driftsherrens side. Den første har et kortsigtet perspektiv, mens den sidste har et langsigtet perspektiv. Bygherren vil fokusere på at levere et byggeri, der passer til det marked, han sigter imod, og samtidig få mest mulig kvalitet for pengene. For denne rolle gælder det om at styre et projekt til det punkt, hvor det kan tages i brug. De informationer, som bygherren har brug for, omhandler informationer om, hvordan bygningen ”performer”, og hvordan den svarer den markedssituation bygningen sigter imod. Det kan være analyser og beregninger, der viser at byggeriet overholder myndighedskrav og krav fra de kommende brugere. Det kan ligeledes dreje sig om at sikre, at kvaliteten lever op til det, som markedet efterspørger. Dertil skal det sikres, at overskudsgraden er tilfredsstillende i forhold til, hvad bygningen kan sælges for eller lejes ud til. 2.3.3 Driftsherrens behov Driftsherren skal derimod styre bygningen, fra den tages i brug og frem til det tidspunkt, hvor den enten skal renoveres eller rives ned. Driftsherren har derfor fokus på, hvordan han kan drive bygningen bedst muligt. Det er ikke nødvendigvis et behov, der kolliderer med bygherrens behov, men der kan dog være tilfælde, hvor der er modstridende interesser. Fx kan bygherren ønske en gulvoverflade ud fra brugernes ønsker til æstetik, mens driftsherren ønsker en anden overflade ud fra erfaringer med vedligehold. Derfor er det vigtigt at de organisationer, hvor bygherren ikke også er driftsherren, at der inddrages kompetencer, der kan kortlægge driftsherrens behov og meget gerne den konkrete driftsherre. Det, som driftsherren har brug for, er nogle præcise informationer, om den bygning han modtager, og et format der gør, at han nemt kan overføre informationerne til driften. Dette burde være ligetil, men i mange tilfælde er der ikke stillet præcise krav til afleveringen (Kaa, 2011). Dertil har mange rådgivere og entreprenører ikke fokus på driften af byggeriet (Kaa, 2011), (Carlsen, 2011). Der er behov for mere erfaring med den digitale målrettede aflevering. For at driftsherren nemt kan bruge driftsinformationerne, bliver de nødt til at være målrettet mod ham. Som det følgende citat beskriver, så er driftsherrens behov til digitale data først og fremmest informationer om drift og vedligehold af byggeriet. Almost all FM organizations expect an increased use of digital data in the coming years. The most important data to get in digital form are instructions for building operation and maintenance plans. (Jensen, Digital Handover of Data from Building Projects to Operation, 2006, s. 3) 18 Introduktion til begreber, aktører og samarbejdsformer Kap: 1-2-3-4-5-6-7-8-9 2.3.4 Potentialer for bygherren krav til digitalisering Der har traditionelt set været en del fokus på Drift & Vedligehold, når der skal stilles krav til hvilke informationer, som driftsherren har brug for. Efterhånden som den digitale aflevering bliver mere udbredt, er det sandsynligt, at der vil blive stillet krav om flere typer af informationer end D&V. Analysen senere i rapporten vil belyse forskellige emner, som kunne være interessante for driftsherren at fokusere på. 2.4 Samarbejdsformer Et af grundelementer for at sikre, at alle aktører bliver inddraget, og at de rigtige krav bliver stillet, er at anvende en samarbejdsform, der sikrer et godt samarbejde. De traditionelle samarbejdsformer er bygget op omkring, hvordan entrepriseformen er struktureret. Der er fire former for entrepriseudbud: Fagentreprise. Her forhandler bygherre direkte med de enkelte entreprenører, og bygherre står også for styring og koordinering af byggeriet. Storentreprise. Denne form minder meget om fagentreprise, men her er entreprenørerne samlet i grupper, så bygherren skal forholde sig til færre parter. (i mange tilfælde er storentreprise en undergruppe til fagentreprise) Hovedentreprise. I hovedentreprisen forhandler bygherren med én entreprenør, som står for hele udførelsesfasen. Totalentreprise. Her forhandles der med en entreprenør, som har ansvaret for både projektering og udførelse af byggeriet. 2.4.1 Tidligt/sent udbud. De tre førsteentrepriseformer samles ofte i det, der kaldes sent udbud. Her har bygherren selv kontakt til arkitekter, ingeniører og andre rådgivere. Dermed har bygherren god mulighed for at påvirke projektets udformning sent i projektet, der er dog mange parter, han skal forholde sig til, og det kræver en fokuseret styring af projektet for at sikre, at projektet opnår den ønskede kvalitet. Totalentrepriseformen bliver ofte anvendt i tidligt udbud. Her er der ikke udformet et tegningsmateriale ved udbuddet, som der er ved sent udbud. I stedet er det et byggeprogram, der danner grundlag for udbuddet. Det er derfor entreprenøren, der selv udformer tegninger o.l. projektmateriale typisk ved at hyre rådgivere til at støtte ham. Når der først er forhandlet en aftale mellem bygherren og entreprenøren, er der i princippet ikke mulighed for at komme med projektændringer. Det er derfor vigtigt, at bygherren har været meget specifik i sine ønsker til byggeriet i byggeprogrammet. Tidligt udbud kan også anvendes ved de andre entrepriseformer, hvor det ønskes at inddrage entreprenørernes kompetencer tidligt i byggesagen. 19 Introduktion til begreber, aktører og samarbejdsformer Kap: 1-2-3-4-5-6-7-8-9 Figur 6, Overblik over hvilke faser de forskellige udbudsformer dækker, http://www.ebst.dk/publikationer/Bedste_Praksismanual_om_totaloekonomi/html/chapter05.htm 2.4.2 OPP Offentlig – Privat Partnerskab, OPP, er en forholdsvis ny måde at organisere byggesager på. Som figur 6 viser, så samler OPP alle byggeriets faser i én organisation. Bygherren skal således kun forholde sig til organisation, og skal i princippet kun forholde sig til, hvilke krav de har til byggeriet. Fordelen i forhold til traditionelle byggesager er, at bygherren bestiller en samlet løsning, hvor OPP-organisationen står for de samme ydelser, som totalentreprenøren står for, samtidig med at de også står for drift og vedligehold af bygningen, samt finansiering af denne. Dermed betaler bygherren ikke for byggeriet, men betaler en årlig leje af bygningen. Det betyder, at bygherren mindsker den risiko, der er i forbindelse med opførelse af nye byggerier. Det foregår typisk ved at der er et konsortium beståede af en totalentreprenør, en driftsorganisation og et pengeinstitut, der sammen byder på et OPP-projekt. Bygherren er med inde over kravstillelsen, men derefter står OPP-konsortiet for resten. Det aftales i forbindelse med kontraktskrivelsen, hvor meget der skal betales i husleje, og hvor lang tid kontrakten gælder. 2.4.3 Waterfall processen og den iterative proces Den eksisterende proces i byggeriet er i høj grad bygget op omkring en waterfall-model. Dette kommer især til udtryk, når projektansvaret overgår fra en aktør til en anden. I de fleste byggesager er der mange forskellige aktører engageret, og projektansvaret kan således nå at skifte flere gange i projektets levetid. Derfor er de juridiske aftaler i byggeriet struktureret sådan, at der altid er defineret, hvem der har ansvaret for projektet på et givent tidspunkt. Dette kan være vigtigt for at sikre, at bygherre ikke bliver snydt, men det er ikke særlig fordrende for det gode samarbejde. Arbejdsprocessen omkring en byggesag har ændret sig en del over de sidste år, hvilket medfører at der undersøges hvilke tiltag der er nødvendige for at kunne understøtte den nye proces. Den nye arbejdsproces 20 Introduktion til begreber, aktører og samarbejdsformer Kap: 1-2-3-4-5-6-7-8-9 omhandler principper fra Building Information Modeling og 3D-projektering. For at kunne udnytte potentialerne ved BIM- og 3D-projektering er det tydeligt, at der bør ske en fundamental ændring af hele struktureringen af byggesagerne. Det behov er allerede anerkendt ved arbejdet omkring den nye ydelsesbeskrivelse, hvor et af formålene har været at få et fælles grundlag for hvordan der bør arbejdes med BIM og 3Dprojektering. Den iterative proces bygger på princippet om at kunne ”cirkle” tilbage, som vist i figur 7, til tidligere faser efterhånden som der opdages problemstillinger, der burde være afklaret tidligere i projektet. Med det stringente waterfall princip for den traditionelle organisering af byggesager og det juridiske grundlag de bygger på kan det være en udfordring at sikre, at der sker det samarbejde på tværs af aktører og ansvarsområder. Der er dog flere initiativer der forsøger at støtte samarbejdet og den fælles ansvarsfølelse i byggesager, som er beskrevet i de følgende afsnit. Nogle af dem er anvendt i en del år mens andre er forholdsvis nye og uafprøvede i Danmark. (Asbjørn Levring, Teknologisk institut, 2010) Figur 7, Den iterative proces, BIM-implementering og praktisk projekthåndtering 2.4.4 Partnering Partnering er en samarbejdsform der anvendes i projekter hvor der ønskes et øget samarbejde på tværs af faser og faggrænser. Samarbejdet bygger på, at parterne forpligtiger sig til at involvere sig i projektet i større grad. Fx bør entreprenøren inddrages allerede under projekteringen for at sikre problemstillinger omkring udførelse løses tidligt i projektet, ligeledes deltager rådgiverne i udførelsesfasen med henblik på at sikre en stadig optimering af funktionelle, arkitektoniske og tekniske forhold under byggeriet. Partneringaftalen er en hensigtserklæring der tilkendegiver at parter vil overholde de bestemmelser om samarbejde, der er aftalt. Der er dog ingen ændring af ansvarsforholdene i det underliggende kontraktgrund ligesom der ikke er direkte konsekvenser forbundet med at bryde bestemmelserne i partnering-aftalen. I nogle tilfælde er partnering-aftalen dog ledsaget af en incitamentsaftale, som beskriver, hvordan overskud og underskud skal dækkes af de involverede parter i fællesskab efter en fordelingsnøgle. Dette økonomiske incitament vil skærpe de involverede parters interesse i at samarbejde om at skabe det bedste mulige projekt, hvilket gerne skulle resultere i et bedre endeligt byggeri. (Foreningen af Rådgivende Ingeniører, FRI, 2005) 21 Introduktion til begreber, aktører og samarbejdsformer Kap: 1-2-3-4-5-6-7-8-9 Figur 8, Forløb ved tidligt valg af samarbejdspartnere, Partnering i praksis s. 7 Partnering-aftaler er ikke en omstrukturering af de almindelige entrepriseformer og kan for så vidt anvende i både tidligt og sent udbud. Det skal derfor ikke ses som et forsøg på at erstatte den eksisterende entrepriseformer, men som en støtte. Det er kun muligt at udbyde projekter med partnering ud fra kriteriet om ”økonomisk mest fordelagtige bud”, da projektet ikke er specificeret endnu. Efterhånden som der udføres flere og flere partnering-projekter vil samarbejdet gradvist blive udbygget jf. figur 9. Figur 9, Tre trin til fuldt udbygget partnering, Partnering i praksis s. 91 2.4.5 Integrated Project Delivery, IPD Integrated Project Delivery, IPD, er en samarbejdsform, der er udviklet i USA af American Institute of Architects, hvor alle de involverede parter i byggesagen engageres fra starten af projekt. Dette prioriteres, ligesom i ”partnering”, for at sikre at alle kompetencer inddrages i byggesagen på de relevante tidspunkter. Forskellen fra partnering er at incicamentsaftalderne er en integreret del af IPD-aftalen. Selve organiseringen af et IPD-projekt minder strukturelt om totalentreprise-formen. Som det fremgår af figur 10, så defineres et projekt med sent udbud (fx fagentreprise) i flere stadier: først defineres der hvad der skal bygges, dernæst hvordan det skal bygges, og derefter hvem der skal bygge det, hvorefter byggeriet bliver realiseret. I IPD samles ”hvad, hvordan og hvem” tidligt i projekt og således kan de relevante kompetencer udnyttes, når der behov for det. Forskellen fra totalentreprise er, at det ikke nødvendigvis er en entreprenør, der har projektledelsen. Et projekt udført som totalentreprise kan dertil godt have en meget hierarkisk organisation, hvor der i et IPD-projekt fokuseres på at styrke samarbejdet mellem de involverede parter. (AIA, California Council, 2008) 22 Introduktion til begreber, aktører og samarbejdsformer Kap: 1-2-3-4-5-6-7-8-9 Figur 10, Overblik over organisering af traditionelle projekter (øverst) og IPD-projekter (nederst), http://www.ipd-ca.net/PDFs/AIACC_1108FAQ.pdf 2.4.6 Valg af samarbejdsform Det er for så vidt ikke afgørende, hvilken samarbejdsform der vælges i forhold til driftsherren og den digitale aflevering. Det der er vigtigt er at sikre et godt samarbejde, og at de rigtige kompetencer inddrages på det rigtige tidspunkt. Det kan gøres ved valg af de rigtig samarbejdsparter eller ved at definere et aftalegrundlag og projektkrav, der sikrer dette. De værdier, som Partnering og IPD bygger på, er interessante i forhold til at sikre et godt projektsamarbejde og et godt byggeri. Det er dog en vurdering, der skal foretages i det enkelte projekt. 2.5 Building Information Modeling, BIM Begrebet Building Information Modeling, BIM, anvendes oftere og oftere i byggebranchen i dag. Der er efterhånden gået hen og blevet et ”buzz-word”, som de fleste virksomheder gerne vil associeres med. Der er dog nogen variation af, hvad folk mener begrebet dækker over. Dette kan skabe nogen forvirring, og der er ikke nogen endegyldig definition af begrebet. Det er blevet mere og mere almindeligt med 3D-modeller i projekteringen de senere år. Efterhånden som BIM bliver mere og mere udbredt, er der dog sket en vis begrebssammenblanding, mellem hvad der er 3Dmodeller, og hvad der er BIM. Der er ikke altid, at det er afgørende at skelne mellem disse, men i mange tilfælde kan det skabe forvirring om, hvad der menes. Det er vigtigt at forstå at 3D-modeller ikke nødvendigvis understøtter BIM. Der er ligeledes tilfælde, hvor BIM opfattes som en model. Dette er dog en halv sandhed, da BIM er proces, der støttes af en model. Derfor vil denne rapport anvende udtrykket ”bygningsmodeller” om de modeller, der anvendes i en BIM-proces. Den afgørende forskel mellem 3D-modeller og bygningsmodeller er ”I’et” i BIM. Altså den information der og intelligens, der knytter sig til de enkelte 23 Introduktion til begreber, aktører og samarbejdsformer Kap: 1-2-3-4-5-6-7-8-9 objekter og modellen som helhed. Der følger herunder nogle definitioner af BIM for at give et indtryk af begrebet. 2.5.1 BIM Handbook’s definition "Med henblik på denne bog, definerer vi BIM som en modelleringsteknologi og en række tilhørende processer til at producere, kommunikere og analysere bygningsmodeller. ” (Chuck Eastman, 2008) 2.5.2 Mortenson’s definition af BIM-teknologi BIM har sine rødder i CAD forskning fra årtier siden, men det har stadig ikke en enkelt, bredt accepteret definition. Vi ved MA Mortenson Company tænker på det som "en intelligent simulering af arkitektur". For at vi kan opnå en integreret levering, skal denne simulering udvise seks vigtige egenskaber. Det bør være: • Digital • Rummelig (3D) • Målbar (kvantificerbar, dimensionerbar og understøtte dataudtræk) • Fyldestgørende (sammenfattende og kommunikerende design-hensigter, bygningsperformance, bygbarhed og indeholdende sekventielle og økonomiske aspekter af metoder) • Tilgængelig (for hele organisationen dvs. både bygherre, arkitekt, ingeniør og entreprenør gennem et indbyrdes kompatibelt og intuitivt interface) • Vedvarende (brugbar gennem alle faser af byggeriets livsforløb) (Chuck Eastman, 2008) 2.5.3 Det digitale byggeris definition af BIM ”Informationsmodeller anvendes inden for flere og flere fagområder, som værktøj til at strukture og dele information og viden. I byggesektoren er Bygnings Informations Modellering, BIM, den nye metode til at tilvejebringe og samle de nødvendige informationer til en given proces. Modelleringen udmønter sig i en Bygnings Informations Model – en ”container” eller database med de nødvendige informationer til at håndtere de processer (bestille, opføre eller drive bygværket), som modellen er beregnet til. En bygningsinformationsmodel opbygges af objekter. Til hvert objekt kan knyttes egenskaber, informationer, som tilsammen definerer det pågældende objekt. De forskellige objekter relaterer sig indbyrdes til hinanden parametrisk – dvs at ændringer i ét objekt automatisk vil slå igennem i alle øvrige berørte objekter. BIM-metodikken giver alle relevante parter mulighed for selv at trække de informationer ud af modellen, som akkurat de har interesse i – på en måde, som sikrer, at alle arbejder ud fra det samme og gældende informationsgrundlag. De enkelte parter kan opbygge egne modeller til egne formål, lige som forskellige fagmodeller kan integreres i én fælles- eller mastermodel for den pågældende proces. 24 Introduktion til begreber, aktører og samarbejdsformer Kap: 1-2-3-4-5-6-7-8-9 I byggeriet er BIM-anvendelsen endnu især knyttet til geometriske 3D-modeller, som giver de projekterende mulighed for at visualisere deres løsninger, simulere forskellige muligheder og koordinere arkitekt-, konstruktions- og installationsprojekterne.” (Det Digitale Byggeri, 2011) 2.5.4 BuildingSMARTs definition af BIM ”Building Information Modelling (BIM) er en ny tilgang til at være i stand til at beskrive og vise de oplysninger, der kræves for design, konstruktion og drift af beregnede faciliteter. Den er i stand til at samle de forskellige tråde af oplysninger til brug i byggeriet i et enkelt operativt miljø og dermed reducere, og ofte fjerne, behovet for de mange forskellige typer af papirdokumenter, der i øjeblikket er i brug. Hvis man imidlertid vil bruge BIM effektivt, og for at fordelene af dets anvendelse skal blive frigivet, skal kvaliteten af kommunikationen mellem de forskellige deltagere i byggeprocessen forbedres. Hvis de nødvendige oplysninger er til rådighed, når det er nødvendigt, og kvaliteten af disse oplysninger er relevante, så byggeprocessen kan forbedres. For at dette kan ske, skal der være en fælles forståelse af byggeprocesser og de oplysninger, der er brug for og resultaterne af deres gennemførelse. The Industry Foundation Classes (IFC) giver en omfattende henvisning til samtlige oplysninger indenfor livscyklussen af et planlagt anlæg. IFC blev oprettet som en integreret helhed, som svar til identifikationen af forretningsmæssige behov udtrykt af den internationale byggebranche. Den indeholder ikke en omfattende henvisning til de enkelte processer i byggeriet. Argumenterne for omfattende henvisninger til processer i byggeriet er klar og overbevisende. Ved at integrere informationer med processen, er værdien af en sådan henvisning langt større, og det bliver et vigtigt redskab for virkelig at udnytte fordelene ved BIM.” (BuildingSMART, 2010) Som de viste citater belyser, så er der en del forskellige organisationer, der beskriver BIM. Det giver et nuanceret billede af begrebet, men det kan også være med til at skabe forvirring om, hvad BIM egentligt er. I denne rapport er det valgt at støtte sig til BIM Handbooks definition af BIM. 25 State of the art 3 Kap: 1-2-3-4-5-6-7-8-9 State of the art Formålet med følgende afsnit er at give et billede af, hvilket stade udviklingen I branchen er på. Symptomatisk er nye initiativer lang tid om at blive implementeret, hvis det overhovedet sker. Flere af disse projekter og initiativer minder om hinanden. Ofte skal et projekt eller en tankegang gennemarbejdes i flere omgange, før at det er modent til at blive implementeret i branchen. 3.1 BIM for byggeriet parter Som Michael LeFevre (2001) udtaler til tidsskriftet JBIM, så er det vigtig at kunne kommunikere potentialet ved anvendelse af BIM ud til branchen. Der kan være en tendens til at BIM er noget, nogle udvalgte aktører indenfor byggebranchen har taget til sig, og at mange af de arrangementer, der fortrinsvis støttes op af de personer, der har ”set lyset”. For at BIM skal fungere optimalt i branchen, er der dog behov for at alle arbejder med BIM. Udfordringen ligger i at overbevise bygningsejerne om, at BIM ikke ”bare” er en ny smart teknologi, men at der ligger en reel værdi i at projekter projekteres, udføres og drives efter BIM arbejdsmetoden. “Despite the growing momentum in BIM and virtual design and construction (VDC) circles, there is concern that BIM evangelists may be preaching to the choir. While we “get it” and readily share “it” with each other, are we still missing the majority who have not yet seen the light? How do we connect with owners, for instance, who, in all but a few notable exceptions, could care less about BIM?” (LeFevre, 2001, s. 14) Det er et af formålene med denne rapport, at kunne påvise fordele for byggeriets parter, at der er fordele, økonomiske såvel som kvalitative, ved at anvende BIM I hele byggeriets levetid. Da rapporten fokuserer på den digitale aflevering, fokuseres der især på driftsherren, men også til dels på bygherren, da der til dels er et sammenfald mellem de to roller, og da bygherrens kravstillelse er afgørende for driftsherren mulighed for at påvirke projektet. 3.1.1 BIM i forhold til Bygherre Mens andre aktører i byggeriet til dels har taget BIM til sig, så kniber det stadig med at overbevise bygherrerne om at anvende BIM i deres organisation. Traditionelt set har bygherrer ikke været ”change agents”, selvom de ofte er udsat for mange problemer med overskridelser af budgetter og tidsplaner, og problemer med kvaliteten af byggeriet. Skiftende markedsfaktorer har dog haft en indflydelse de senere år, og bygherren er tvunget til at have større fokus på byggeriet. (Chuck Eastman, 2008, s. 96) Rådgivere og entreprenører påpeger at bygherren ofte er kortsigtet og kræver løbende projektændringer, hvilket i sidste ende påvirker designkvaliteten, byggeudgifterne og tidsplanen. Ved at anvende BIM i byggeprojekter kan bygherren forvente at mange af disse problemer mindskes. Der er dog en udfordring i at på- 26 State of the art Kap: 1-2-3-4-5-6-7-8-9 vise overfor bygherren, at der er fordele for ham ved at implementere BIM. Der er en tendens til at udvikling sker på baggrund af markedspres. I stedet for at udvikling skal ske på baggrund af pres udefra, bør det være rådgivernes opgave at påvise de markedsfordele der foreligger ved anvende BIM overfor bygherren – både for udførslen af byggeriet og for hans egne arbejdsprocesser. Undersøgelser peger fx på at op mod 2/3 af alle projekter overskrider budgettet. Her kan BIM hjælpe ved levere mere præcise mængdeudtræk og prisoverslag, hvilket kan mindske posten ”risiko” eller ”uforudsete udgifter” som ofte er en stor del af del samlede budget. Der ligger i hele tilgangen til BIM, at data er mere konsistente, og at mange problemstillinger belyses tidligere i processen. (Chuck Eastman, 2008, s. 97) Figur 11, Arbejdsbyrden flyttes til tidligere i processen i forhold til traditionelle projekter, http://www.cenews.com/magazinearticle-cenews.com-10-2008-what_does_bim_mean_for_civil_engineers_-6098.html Som figur 11 viser, så opfordrer BIM-processen til, at arbejdsbyrden flyttes til tidligere i processen. Den blå linje (1) viser evne til at kunne lave projektændringer, den røde linje (2) viser udgifterne til at fortage ændringer, den sorte linje (3) viser arbejdsforbruget i traditionelle byggeprojekter, mens den grønne linje (4) viser arbejdsforbruget i byggeprojekter, hvor der anvendes BIM. Der er en del problemstillinger omkring udbetaling af honorar. Hvis arbejdsbyrden skal flyttes til tidligere i processen, er det vigtigt, at honorarfordelingen afspejler dette. Det kan ligeledes diskuteres om arbejdsbyrden er lige stor i de to tilfælde. Der kan være en risiko for at rådgiveren bruger hele sit honorar i starten af projekteringen, og at der dermed ikke er penge til at færdiggøre projektet. Dette vil dog ikke blive behandlet yderligt i denne rapport. For bygherren er der flere fordele, der kan nævnes, når der anvendes BIM. Ud over de mere præcise mængdeudtag og prisoverslag tidligt i projektet, kan der nævnes: bedre kommunikation, nemmere kontrol af projektmaterialet, flere analyser, ol. 3.1.2 BIM i forhold til driftsherre Der nævnes ofte de fordele, som bygherren får ved at stille krav om brugen af BIM i design- og konstruktionsfasen, men der er ligeledes væsentlige fordele, hvis han kan anvende BIM til FM-arbejdet. Problemet 27 State of the art Kap: 1-2-3-4-5-6-7-8-9 har været at påvise økonomien i den ændrede arbejdsgang. Det er forholdsvis nemt at påvise fordelene ved anvendelsen af BIM i projektering og udførsel, men ved FM kan afstanden mellem investering og fordel være stor samtidig med, at det er svært at adskille de forskellige påvirkende faktorer. Det er på mange måder logisk at starte med design- og konstruktionsfasen, da det er her det er nemmest at påvise økonomiske fordele ved at anvende BIM. Fordele som færre fejl og større effektivitet, der beskrives som direkte eller indirekte fordele ved at anvende BIM. De fordele som driftsherren drager af BIM beskrives ofte som afledte – dvs. at der foretages handlinger i projekteringen eller udførslen, hvor der er en formodet besparelse for driften eller kvaliteten af bygningen, men som kan være svære at kæde sammen med det udførte arbejde pga. de mange indvirkende faktorer. Danmarks Tekniske Universitet, DTU, er i gang med et projekt, der skal måle de økonomiske gevinster ved Det Digitale Byggeri. Projektet er vigtigt da bygherrer og driftsherrer mangler business cases, der kan overbevise dem om, at de kan drage nytte af at kræve en anvendelse af BIM i deres projekter. (BIMlab, Danmarks Tekniske Universitet, 2011) Der ligger en stor opgave for driftsherrerne skulle digitalisere deres arbejdsprocesser. Det er ikke bare et spørgsmål om at implementere et FM-system, der kan styre dette arbejde for de kommende projekter. Udfordringen ligger i, at de ofte har en stor bygningsmasse, hvor tegningsmaterialet skal digitaliseres, og kunne behandles af det nye FM-system, for at de kan udnytte potentialet fuldt ud. Rådgivere og entreprenører har ikke samme problemer ved deres implementering. De kan fra projekt til projekt beslutte, hvor meget digitalisering de vil anvende. For driftsherren er det ikke nok at stille krav til kommende projekter, han må også se på, hvordan den eksisterende bygningsmasse kan opdateres, da et driftssystem gerne skal indeholde hele bygningsmassen. For mange af de bygninger som driftsherrerne administrerer og driver, findes der ofte ikke digitale tegninger, og det er yderst sjældent, at der findes bygningsmodeller. Her findes der kun de papirtegninger, der er blevet afleveret i forbindelse med bygningens færdiggørelse. Derfor ligger der en stor opgave for driftsherrerne i at konvertere fysiske papirtegninger til et digitalt format, som kan håndteres i et digitalt system. Det er forskelligt om driftsherrerne vælger at stille krav til aflevering af 2D eller 3D til tegningsdokumentation, men der er en tendens til, at der vælges 3D i takt med, at de projekterende og udførende i større grad anvender 3D i deres arbejde. Fx er Teknisk forvaltning begyndt at stille krav til aflevering af bygningsmodeller i de sager, hvor de projekterende alligevel anvender bygningsmodeller i projekteringen. Som interviewet med Dan-Ejendomme viser, er der dog stadig mange rådgivere, der ikke anvender 3D eller bygningsmodeller i projekteringen, og det er vigtigt også at tage hensyn til disse parter. (Wernlund, 2011), (Andersen, 2011) Formålet for driftsherren med at digitalisere tegningsmaterialet er at kunne få et bedre overblik over arealer og rum end i den traditionelle styring. Bygherreforeningens digitaliseringsudvalg nævner nogle fordele ved at have en bedre, mere præcis arealstyring: Arealstyring baseret på en ensartet og ajourført registrering af kvadratmeternes udnyttelse og dertil knyttede driftsstatistikker er en nøgledisciplin. Denne viden udgør eksempelvis grundlaget for at: • mindske tomgangsleje (bedre overblik over, hvor der er ledige kvadratmeter) • lette kontraktsindgåelse med lejere (det er mere veldefineret, hvad lejer får) 28 State of the art Kap: 1-2-3-4-5-6-7-8-9 • mindske administrationsbyrden ved manuelle opgørelser • korrekt fordeling af brugsudgift (ved at koble geografisk placering i bygning med forbrugstal) • sikre den optimale fordeling af forskellige funktionaliteter (eksempelvis servicefunktioner og butikstyper) • optimere planlægning, eventuelt udbud samt udførelse af løbende drift og vedligehold. De valide ejendomsdata danner samtidig grundlag for driftsherrens strategier for, hvordan han fastholder og skaber mest mulig værdi i den betydelige investering, som ejendomsporteføljen udgør. Digitalisering og nøgletal tillægges derfor stor betydning i forhold til areal- og porteføljestyring. (Bygherreforeningen, 2010, s. 8) Arealstyringen kan dermed bruges både til at skabe overblik og styre den eksisterende bygningsmasse, men kan også bruges til at udforme den fremtidige strategi for driften. Benjamin Andersen (se bilaget i kapitel 11.3) fra Dan-Ejendomme nævner i den sammenhæng at erfaringsdata om kvadratmeterpriser, energiforbrug o.l. kan bruges til at udforme business cases, som kan bruges strategisk i forbindelse med nye projekter. Mange af de CAFM-systemer, som bygherrerne anvender i dag, har til formål at styre D&V. Opgaven med at styre arealer og rum foretages ofte i et andet program. Dette er dog to af de mere åbenlyse måder at digitalisere driftsherrens arbejdsprocesser. Det er processer, som for så vidt ikke er nye, men som før blev dårligt styret gennem mange forskellige dokumenter og tegninger. Det som der er sket er, at FM-systemer og arealhåndteringssystemer har samlet informationerne, så det er nemmere at få det samlede overblik og sammenstille oplysninger. Potentialet for anvendelsen af BIM-modeller i driftsfasen er dog langt større. Ud over at trække informationer fra BIM-modellen til hans FM-system, kan driftsherren bruge modellen til en lang række af analyser. Ligesom driftsherrerollen er gået fra kun at stå for D&V af den fysiske bygning til også at stå for alle de processer, der hører til at drive en bygning, så er der også begyndt at blive udbudt systemer, der kan behandle de processer, der sker i bygningen. Driftsherrerne efterspørger derfor digitale simulerings- og scenarieredskaber til at synliggøre og afveje disse sammenhænge. Redskaberne kan bruges til mange forskellige simuleringer / scenarier: • simulering af flow af eksempelvis mennesker, med henblik på at undgå kødannelser eller unødig transport, for at opnå kortest mulige adgangsveje • rumlige visualiseringer i 3D, der er lettere for slutbrugere at forholde sig til end plantegninger • simulering af det samlede energiforbrug og totaløkonomien ved eksempelvis forskellige bygningsudformninger og -orienteringer samt valg af forskellige energitiltag • sikre at de stadig mere omfattende regelsæt overholdes (eksempelvis krav ift. brand og tilgængelighed) • simulering af de samlede driftsomkostninger ved forskellige vedligeholdelsesniveauer Der er et stort behov for at få belyst de langsigtede økonomiske konsekvenser ved forskellige vedligeholdelsesniveauer. En række af især offentlige driftsherrer oplever, at det løbende vedligehold nedprioriteres til fordel for mere (politisk) synlige mærkesager, og at der derfor reelt kun udføres akutvedligehold. Resultatet 29 State of the art Kap: 1-2-3-4-5-6-7-8-9 er en både dyr og ineffektiv driftsindsats. Synliggørelse af omkostningerne ved manglende vedligehold (eventuelt kombineret med ændret regnskabspraksis med bygninger som finansielle aktiver) vil afhjælpe dette. (Bygherreforeningen, 2010, s. 10) Applikationer som AutoDesk Project Dasher, (Autodesk, 2011) kan analysere brugen af en bygning og derfor kan det være nemmere at styre energiforbrug, ventilationsbehov mm. Dette er systemer som stadig er meget nye for branchen og det er derfor svært at sige i hvor stor grad de vil blive anvendt. Der er dog et tydeligt potentiale for en bedre styring af bygninger af en tilpas høj kompleksitet. Her kan fx henvises til det følgende citat som viser at der er for lidt fokus på udgifterne til driften af bygninger: When looking at operational costs, it’s easy to assume energy is the biggest component since there has been such focus on energy efficiency. The federal government has initialed several energy reduction strategies; but what about the largest building cost—maintenance? Presently, BIM is being used during design and construction phases but needs to be applied throughout the lifecycle to include facilities management FM). Because we have been trapped in a two dimensional world, designs were produced solely for the creation of construction documents. There is a need to look beyond the two- to-three year design for construction phases and begin to use BIM for a design for maintenance strategy. (Foster, 2011) Der er dermed ifølge Birgitta Forster, som er Assistant Director ved BuildingSMART alliance, et behov for at kunne analysere og optimere på driften af bygninger. Figur 12, Mulighed for at anvende applikationer som Project Dasher til analyse af bygningens "performance", http://www.autodeskresearch.com/pages/dasher I flere byggesager kan der være problemer ved, at driftsherren ikke er inddraget i projektet tidligt nok processen. Dette medfører at driftsherren ikke får sine krav med i kravstillelsen til rådgiverne og entreprenørerne. I de byggesager, hvor driftsherren er involveret på et tidligt tidspunkt, er det ikke sikkert, at han har tilstrækkelig indflydelse til at påvirke kravstillelsen. Det er en udfordring for driftsherren at gøre sin indflydelse gældende, når der kan komme modstridende krav fra mange forskellige interessenter. En måde at anskueliggøre konsekvenserne af kravstillelsen i forhold til driften er at vise analyser over driftsudgifter ved forskellige krav. Applikationer som Project Dasher kan være ét analyseværktøj til at vise, hvordan en byg- 30 State of the art Kap: 1-2-3-4-5-6-7-8-9 ning anvendes, og hvilke problemstillinger der skal tages højde for. For at kunne forklare bygherreorganisationen hvilke omkostninger som valgene og omkostningerne i forbindelse med opførelse af byggeriet har, i forhold til omkostningerne i driften, kunne en applikation, der kan vise driftsudgifterne i byggeriets levetid være en stor hjælp. En af de udfordringer som driftsherren står overfor, er at det kan være svært at få folk til at bekymre sig om udgifter, der ligger langt ude i fremtiden. Ved at opstille udgifterne på en overskuelig måde, vil det være nemmere for driftsherren at overbevise resten af de involverede parter om at foretage valg, der tilgodeser driften. Det vil senere i rapporten blive undersøgt, hvordan en sådan applikation kan se ud. 3.2 Behovet for bedre informationsudveksling En undersøgelse fra National Institute og Standards and Technology, NIST, viser, at dårlig informationsudveksling er skyld i betydelige udgifter for byggebranchen. “The study determined that this was costing the industry about $15 billion per year due to the inefficiencies caused by the lack of interoperable data exchanges throughout the buildings’ lifecycle. A majority of this cost was caused by poor information handoffs during the construction to operations phases.” (Foster, 2011, s. 18) De beløb (for USA), der nævnes, gør, at det er et område, som alle bør fokusere på. Især bygherren og driftsherren, som efter al sandsynlighed betaler for det, bør tage initiativ til at forbedre denne proces. Som Per Anker Jensen beskriver det, så er den største barriere for en øget brug af Informations- og KommunikationsTeknologi, IKT, i byggebranchen: den manglende integration mellem IT-systemer, fælles standarder, menneskelige ressourcer og kompetencer. Derimod er integration mellem IT-systemer, utvetydige standarder, forbedret data struktur og forbedret tilgængelighed til data de største potentialer. (Jensen, Digital Handover of Data from Building Projects to Operation, 2006, s. 3) Meget af dette kan samles i begrebet informationsudveksling. Der er et generelt problem med informationsudvekslingen i branchen. Selvom mange virksomheder er begyndt at implementere dele af BIM (hovedsagligt modelleringsapplikationer) er branchen stadig struktureret omkring de traditionelle udvekslingsmetoder, som bygger på den papirbaserede tilgang til projektet. Der anvendes ofte den lineære udveksling, hvor aktørerne efter en endt fase overdrager informationer til den næste aktør i kæden. Informationerne er ofte papirbaserede, hvilket betyder, at der ofte vil være en del redundante data. Dertil kommer informationer, der kun findes i folks hoveder eller på skitser og notater. Ved opstart af næste fase er der derfor en del informationer, der skal bearbejdes eller genskabes, hvilket resulterer i faldende værdi af projektmaterialet og tab af værdi. Denne arbejdsmetode beskrives ofte som ”the wall” eller ”muren” på grund af den skarpe adskillelse mellem aktørerne i informationskæden. (Chuck Eastman, 2008, s. 117) 31 State of the art Kap: 1-2-3-4-5-6-7-8-9 Figur 13, Traditionel informationsudveksling, C109 Modelbaseret arbejdsmetode i bips, medlemsundersøgelse maj 2008 Der er et behov for at definere nye roller ved anvendelse af BIM. Det står klart, at der er behov for at der udvikles nye roller, nye samarbejdsformer og nye processer. (Bips, 2008, s. 32) BIM bygger på en forståelse af, at informationsudvekslingen skal ske på tværs af de traditionelle faser, samtidig med at projektinformation samles ét sted. Der ses flere tiltag for at strukturere og samle projektinformationen. Det er i de senere år blevet mere og mere almindeligt at anvende en form for projektweb til at opbevare informationer. Det løser en del problemstillinger – tegninger og dokumenter skal ikke længere sendes rundt efter behov, men kan tilgås på en central location. Figur 14 viser princippet for, hvordan informationsudvekslingen bør foregå i et BIM-projekt. Figur 14, Informationshåndtering med BIM, C109 Modelbaseret arbejdsmetode i bips, medlemsundersøgelse maj 2008 Strukturen i nogle projektweb-løsninger er dog stadig noget uoverskuelig, med mindre de enkelte brugere er godt inde i mappestrukturen. Den enkelte bruger skal vide, hvor den information han søger ligger, ellers kan det tage lang tid at finde den. Denne form for projektweb understøtter dog ikke direkte BIM- 32 State of the art Kap: 1-2-3-4-5-6-7-8-9 arbejdsmetoden. Ved at anvende en modelbaseret server, hvor alle informationer er linket til modellen, kan overblikket forbedres, og der kan spares meget tid på informationssøgning. Der findes modelserverløsninger på markedet, men de bruges kun begrænset. En barriere er, at de kræver en tilpasning til det enkelte firma, og erfarent IT-personel for at vedligeholde dem. (Chuck Eastman, 2008, s. 126) 3.2.1 Status på informationsudvekslingen i byggeriet Der er flere muligheder for at aflevere projektmaterialet til bygherren efter endt arbejde. Traditionelt er denne aflevering sket via papirformatet. Typisk i ringbind og kasser, som driftsherren så kan begynde at gennemgå for de informationer, han har brug for. Der er stadig mange projekter, hvor afleveringen foregår sådan – simpelthen fordi bygherrerne ikke stiller krav om andet. (Pedersen, 2011) Branchen har erkendt behovet for en bedre udveksling af informationer, som må siges at være baggrunden for flere af kravene i IKT-bekendtgørelsen og projektet ”Det Digitale Byggeri” (Erhvervministeriet, 2001). Efterhånden, som der er kommet mere og mere fokus på informationsudveksling, er der også kommet flere og flere løsninger til at håndtere informationsudvekslingen. Der har i en del år været løsninger til fælles digital opbevaring af projektmateriale, der kaldes projektweb. I Danmark er projektweb næsten blevet synonymt med byggeweb, da denne projektweb-løsning er blevet så udbredt, at mange ikke kender andre. En projektweb-løsning har den fordel, at den kan håndtere alle typer filer, der lægges op på den. Dertil er den webbaseret og kan derfor tilgås af alle projektet aktører (se figur 15). Problemet er at den stadig er dokumentbaseret, og derfor er der stor sandsynlighed for at projektinformationerne er redundante. Figur 15, Anvendelse af et projektweb, Figur 16, Skiftende databaser og projektweb, egen tilvirkning. egen tilvirkning Som mange andre løsninger (fx FM-systemer eller CAD-systemer) er et traditionelt projektweb ikke revolutionerende ny løsning, men en måde at effektivisere et eksisterende system. Som Henry Ford sagde det da han byggede sin første bil: Hvis jeg havde spurgt mine kunder om hvad de gerne ville have, ville de have sagt en hurtigere hest. (Ben Tremblay, 2009) Sådan er det med nye produkter. Der er nogen, der effektiviserer den måde folk allerede arbejder på, mens der er andre produkter, der fundamentalt ændrer arbejdsmetoden. Det er som regel nemmere at overbevise folk om at købe en ”hurtigere eller bedre hest”, mens overgangen til en helt ny teknologi, der forandrer den måde tingene bliver gjort på, kræver noget større tilvænning. Det er lidt den samme problemstilling, der er inden for byggebranchen. De projektwebløsninger, der anvendes, er nok med til at effektivisere informationsudvekslingen, men en egentlig revolution er det ikke. Den ideelle løsning hvor al information 33 State of the art Kap: 1-2-3-4-5-6-7-8-9 findes i en central database, uden redundant information, synes dog at ligge et stykke ud i fremtiden for byggeriet. En problemstilling, som ofte ses i byggesager, er, at projektweb ikke altid er stedet, hvor informationerne er først tilgængelige. Ofte har de forskellige aktører en lokal database, hvor deres egne informationer ligger, indtil de er klar til at blive delt med resten af projektets aktører. Derved kan projektets parter ikke være sikre på, at de nyeste informationer er tilgængelige. En information kan være ved at blive bearbejdet hos én part, mens en anden part kun kan se den information, der er tilgængelig på projektweb. Det er ligeledes en problemstilling at den centrale datalagring i nogle tilfælde flyttes til nye placeringer. Fx sker det ofte, at et projekt startes på en lokal server for derefter på et tidspunkt at blive flyttet til et projektweb. Dertil sker det, at projektet flyttes fra et projektweb til et andet, evt. gennem en lokal server (se figur 16). Derved kan det næsten ikke undgås, at der sker et tab af struktur og metadata. I forbindelse med byggeprojektet på Skejby sygehus har konsortiet bag forsøgt at optimere arbejdsgangene og informationsudvekslingen ved at oprette en separat tegnestue på byggepladsen. Dermed kan alle tilgå projektinformationer med det samme, hvilket sikrer, at byggeriets parter nemmere kan tilgå den nyeste information. Der er dog ikke uden problemer at alle arbejder i en fælles projektserver på samme tid. Som Tonni Elkjær siger det, ”så er fordelene ved at arbejde på denne måde at modellerne altid er opdaterede, mens ulemperne er at modellerne altid er opdaterede”. Det kræver en del disciplin at arbejde på denne måde. Rådgiverne i byggesagen er vant til, at der er en forsinkelse, før det arbejde, der udføres på tegnestuen, uploades til projektweb. Når der arbejdes på en fælles tegnestue, bliver de ændringer, der foretages i modellerne, straks opdateret på tværs af projektet. (Tonni Elkjær, 2011) Det er derfor tydeligt, at der også er problemer med at arbejde med et projektweb, der altid er opdateret. 3.3 Det digitale byggeri og bygherrekravene Det har i mange år været i byggebranchens interesse at arbejde med projekter, der oplyser om og fremmer brugen af digitale værktøjer. Brugen af digitale værktøjer kan være en af metoderne til at optimere byggebranchen, hvilket til alle tider er interessant for virksomheder, underordnet hvilken branche virksomheden tilhører. Der har både været private og offentlige projekter, der har haft til formål at digitalisere byggeriet, ligesom det i mange projekter er en kombination af både offentlige organer og private organisationer, der har deltaget i denne form for projekter. Siden begyndelsen af 1980’erne, hvor de første CAD-systemer blev implementeret på tegnestuerne, har der været visioner om et digitaliseret byggeriet. Allerede på dette tidspunkt var der intentioner med at anvende systemer til 3D-modelering, men teknologien var ikke tilstrækkeligt udviklet, og systemerne var for dyre. Derfor blev 2D-CAD-systemerne gradvist udbredt i branchen, mens 3D-modeleringssystemer kun havde begrænset udbredelse i mange år. I slutningen af 80’erne og starten af 90’erne blev gjort flere tiltag for at skabe fælles standarder for anvendelsen af digitale værktøjer. (Erhvervministeriet, 2001, s. 12) Projekterne koncentrerede sig om seks hovedområder som: • • CAD-anvendelse (lagstruktur, dataudveksling, manualer mv.) EDI (e-handel, produktinformation, specifikationer) 34 State of the art • • • • Kap: 1-2-3-4-5-6-7-8-9 Digitalisering af data (GIS, BBR, scanning mv.) IT-kultur og praksis Referencearkitektur (CAD-struktur, datamodeller mv.) Internationale relationer Disse projekter er grundlaget, hvorfra mange senere projekter udspringer. Der var dog ikke på dette tidspunkt den store koordinering mellem projekter, og der manglede dermed en samlet koordineret vision for digitaliseringen af byggeriet. (Erhvervministeriet, 2001, s. 11-14) Det første konkrete initiativ til projektet ”Det Digitale Byggeri” tager sit udspring omkring år 2000 og bygger på tre konkrete rapporter. • PPU-konsortiet: IT i byggeriets fremtid. PPU-konsortiet (proces- og produktudvikling i byggeriet) består af Højgaard & Schultz, Rambøll og Arkitektgruppen Aarhus. I 2000 udformede konsortiet en rapport, som beskriver byggebranchens erfaringer med projektweb, objektorienterede bygningsmodeller, digitale kataloger og mængdeudtræk. Der blev konkluderet, at der var en vilje til at anvende flere digitale værktøjer, men at det krævede en koordineret indsats for sikre IT-strukturen. • Ressourceområdeanalysen Bygge/Bolig Denne rapport er udformet af erhvervsministeriet i år 2000 og havde til formål at belyse udviklingspotentialerne i den danske byggesektor. Rapporten kom frem til tre markante udfordringer: 1. Slutbrugerne kunne ikke gennemskue eller regne med de priser, som de fik tilbudt. 2. Produktiviteten i byggesektoren var stagneret. 3. Der var alt for mange fejl i de byggerier som blev gennemført. Mange fejl blev først tydelige langt tid efter at byggerierne var færdige, og omkostningerne for at udbedre fejlene var uforholdsmæssigt store. (Jonas Maaløe Jespersen, 2008) Årsagen til fejlene skulle findes i de komplekse organisationsformer infrastrukturer i byggesager, som skabte misforståelser, forsinkelser og ugennemskuelighed. Hvilket resulterede i lav kvalitet til høje priser. • Taskforce-rapporten: Byggeriets fremtid I dette samme år blev der nedsat en taskforce-gruppe der havde til formål at undersøge baggrunden for Ressourceområdeanalysens konklusioner. Resultatet af arbejdet var, at der var behov for at forbedre grænsefladerne mellem de forskellige involverede parter. Hvis det kunne sikres, at alle parter har adgang til den rette information på det rette tidspunkt kunne branchen undgå spildtid, misforståelser og fejl. (Jonas Maaløe Jespersen, 2008) For at løse de problemstillinger, som rapporterne kom frem til, dannede Erhvervs- og byggestyrelsen i 2002 initiativet, ”Det Digitale Byggeri”. Strategien for Det Digitale Byggeri var at udvikle et fundament af standarder og fælles retningslinjer og krav for at lede en øget digitalisering i byggebranchen. Dertil skulle der udføres praktiske eksempler, der kunne beskrive erfaringer og dokumenter fordele og dermed danne ”best practice” for hele byggebranchen. 35 State of the art Kap: 1-2-3-4-5-6-7-8-9 I perioden 2004-2006 arbejdede fem forskellige konsortier og foreningen, bips, med at udvikle Det Digitale Fundament og bygherrekravene. De fem konsortier havde hver deres arbejdsområde og kan ses i særskilte rapporter: (Jonas Maaløe Jespersen, 2008) Figur 17, Overblik over arbejdet med at udvikle Det Digitale Fundament og bygherrekravene, http://www.hfb.dk/fileadmin/templates/hfb/dokumenter/artikler/Det_digitale_byggeri.pdf Som det fremgår af figur 17, havde bips ansvar for at udvikle Det Digitale Fundament, mens konsortierne havde ansvar for at udvikle de resterende bygeherrekrav. Dette arbejde resulterede i bekendtgørelsen 1365 om anvendelse af Informations- og kommunikationsteknologi i byggeriet, som opstiller 10 konkrete krav til byggesager for statslige bygherrer. Bekendtgørelsen trådte i kraft 1. januar 2007, om anvendelse af DBK (klassifikation), projektweb, digitale bygningsmodeller, digitalt udbud og digital aflevering. I januar 2011 blev bekendtgørelsen (nu nr. 1381) revideret for blandt andet at samle bygherrekravene i en mere overskuelig form. Det er intentionen, at bekendtgørelsen i den nærmeste fremtid også skal omfatte kommunale byggesager, og kravene vil dermed få langt større udbredelse. Det arbejde, som Det Digitale Byggeri har stået for og som cuneco nu står for, har været en drivkraft for digitaliseringen i branchen. Det er de færreste byggesager, der har været omfattet af bygherrekravene, men alligevel er der i mange byggesager anvendt principperne fra bekendtgørelsen og Det Digitale Byggeri. Dette understreger behovet for denne form for branchestandarder og ”best-practice” eksempler. 36 State of the art Kap: 1-2-3-4-5-6-7-8-9 I denne rapport er der fokuseret på den digitale aflevering, som er et område, som der ikke har været samme fokus på som fx projektweb, bygningsmodeller og DBK. Der er dog ved at komme større opmærksomhed på denne del af den digitale byggeproces. Arbejdet med digitalisering af byggeriet og ”Det Digitale Byggeri” er en løbende udvikling, og det vil tage mange år før de nye værktøjer og arbejdsprocesser har spredt sig til hele branchen. 3.4 DACaPo-projektet DACaPo-projektet var et 3-årigt udviklingsprojekt under ”Det Digitale Byggeri”, der har haft til formål at udvikle en standard for en kravspecifikation for digital aflevering. Projektet skal ses i forbindelse med den samlede vision om at udvikle en digital byggeproces i Danmark. Formålet var at skabe en standard for digital aflevering, hvor driftsherren kan genbruge data fra design og opførelse af byggeriet til den efterfølgende drift. I den traditionelle afleveringsproces kan der bruges meget arbejde på at omdanne det afleverede projektmateriale til information, der kan bruges af driftsherren. Kravspecifikationen gør det muligt at definere form, indhold og omfang til de digitale data denne modtager fra projektering og udførelse. Figur 18, udveksling fra projekterings- og udførelsessystem til en struktureret datamodel og videre til driftsherrens FMsystem. (Christianson, 2006) På dette tidspunkt foregik der allerede digital aflevering af projekter til bygherren. Der var dog forskel på hvor meget, og hvad der blev afleveret til bygherren. Ofte drejede det sig om ”as-built”-tegninger og projektmateriale, hvis primære formål er, at dokumentere det opførte byggeri. Dette materiale er relevant i forhold ved juridiske spørgsmål, og ved senere renovering eller ombygning, men til selve driften er disse informationer ikke optimale. Der skelnes i denne sammenhæng mellem ”as-built”-data og driftsdata. Asbuilt-data er uredigerbart og har til formål at dokumentere byggesagen, mens driftsdata er ”levende” data, der kan anvendes af driftsherren. Det drejer sig derfor om at udvælge de data, der skal bruges under driften af bygningen. Det er en beskrivelse af kravene til disse driftsdata, som kravspecifikationen giver. 37 State of the art Kap: 1-2-3-4-5-6-7-8-9 DACaPo-projektet har erkendt, at der er forskellige ønsker til, hvordan en digital aflevering skal foregå, alt efter den digitale modenhed af det enkelte projekts parter. De tre afleveringsmuligheder beskrevet i kravspecifikationen er: • • • XML baseret aflevering IFC baseret aflevering Direkte aflevering i FM-system Der kan være forskellige årsager til at der vælges en af disse metoder, men det væsentlige er, at den relevante information for driften så let som muligt overføres til driftsherrens FM-system. Figur 19, DACaPo-datamodel, (Christianson, 2006) Underordnet hvilken udveksling der vælges i projektet, er datamodellen det centrale i kravspecifikationen. Datamodellen, som ses på figur 19, bruges både til geometriske informationer og til mere statiske informationer, som dokumenter og skemaer. Ved at strukturere selve modellen og de dokumenter, der knytter sig dertil, sikres et større overblik for modtageren af informationen. Kravspecifikationen udkom i sin 2. revision i marts 2006 og er tænkt som en tillægsaftale til ABR89 eller AB92/ABT93, der skal beskrive kravene til den digitale aflevering. Der er ikke mange erfaringer med brugen af kravspecifikationen i byggebranchen, hvilket kan skyldes den begrænsede brug af 3Dmodeller på dette tidspunkt. (Christianson, 2006) DACaPo-projektet har dog haft stor betydning i forbindelse med udvikling af bygherrekravene. Hele strukturen omkring datamodellen og de 3 afleveringstyper lever videre i det digitale byggeris forståelse selvom selve kravspecifikationen ikke har fået stor udbredelse. I de interviews der er foretaget er der ikke nogen der har arbejdet med kravspecifikationen, eller har hørt om praktisk brug af den, Figur 20, DACaPo konceptuel model og datamodel, (Christianson, men efterhånden som der kommer større 2006) fokus på afleveringen, kan det ske at anvendelsen af XML-formaterne vil stige. 38 State of the art 3.5 Kap: 1-2-3-4-5-6-7-8-9 COBie, Construction Operations Building information exchange COBie er projekt som NBIMS, National Building Information Model Standard, har stået for. Projektgruppen startede op i december 2005 og består af NBIMS medlemmer og andre interessenter. Formålet med Cobie er at skabe en standard, der kan bruges til at indfange og vedholde informationer, der er relevante for driftsherren. Resultatet er COBie-datamodellen, som giver branchen et fælles grundlag for, hvad udvekslingen ved aflevering til bygherre skal indeholde. Baggrunden herfor er, at det er ressourcekrævende at indtaste informationer om driften ved afslutningen af projektet. COBie gør det nemmere at indsamle Figur 21, COBie - overblik over processen , driftsdata i løbet af projektet. Figur 21 viser den http://www.wbdg.org/resources/cobie.php principielle tanke i COBie. Her er der en opdeling af, hvilke data de projekterende skal bidrage med, og hvilke data som entreprenørerne skal bidrage med. Overordnet set er det rådgiverne, der sætter rammen for hvilke data, der skal leveres (i samarbejde med bygherren), og hvilke krav der er til dem. Derefter er det så entreprenørernes opgave at opdatere datamodellen med data for de specifikke produkter, som installeres i byggeriet. (National Institute of Building Sciences) Følgende er en beskrivelse af elementerne i COBie: Tidlig designfase (programmering/forslagsfaser): I den tidlige fase, som ofte kaldes programmeringsfasen, defineres de rum som er nødvendige for at bygherren kan specificere sine krav til projektet. I COBie-filen oplistes bygningerne i projektet. Som derefter hver opdateres med angivelse af en eller flere etager. For hver etage defineres de rum der indgår i etagen. I bygningen vil disse typisk have rum nr., mens de udendørs kan klassificeres efter deres funktion (fx parkeringsplads, terrasse ol.). Det er også i denne fase at systemerne skal defineres. Der er her tale om el-, Figur 22, COBie-filen i den tidlige ventilations-, varme-, kølesystemer ol. (National Institute of Building Sciences) designfase, http://www.wbdg.org/resource s/cobie.php 39 State of the art Kap: 1-2-3-4-5-6-7-8-9 Designfase med dokumentation af konstruktion (projekteringsfase): Efterhånden som projektet skrider frem vokser mængden af dokumentation også. I denne fase bliver det specificeret hvilke materialer, produkter og udstyr, der skal anvendes i bygningen. Traditionelt bliver denne information udtrukket manuelt i skemaer med mange fejl til følge. COBie tilbyder et samlet skema til at registrere de data, der er relevante for projektet. (National Institute of Building Sciences) Figur 23, COBie-filen i projekteringsfasen, http://www.wbdg.org/resourc es/cobie.php Entreprenørens kvalitetskontrol (projektgennemgang og opstart af byggeri): I denne fase modtager entreprenøren COBie datafilen og gennemgår projektet og melder tilbage til rådgiveren med eventuelle fejl eller problemstillinger. Entreprenøren skal opdatere COBie-filen med hvilke løsninger, der er valgt og linke den tilhørende information til COBie i form af dokumenter i pdf og tegninger i både redigerbare filer og pdf. Dette skal udføres for at dokumentere, at entreprenørens valg lever op til rådgivernes krav i projektet. Det er også i dette stadie, at entreprenøren skal bestemme om denne vil opdatere COBie informationerne løbende gennem udførelsen eller ved slutningen. For at understøtte COBie bedst muligt, er det vigtigt at afleveringen sker løbende i projektet. (National Institute of Building Sciences) Installation af produkter (udførelse): Når de specifikke produkter installeres i bygningen, skal COBie-filen opdateres med fabrikantens informationer, hvis det ikke allerede er sket tidligere. Fabrikanten og produktmodellen noteres under ”type”, mens serienummeret eller lignende form for ”tag” noteres under ”component” (se figur 24). I store projekter er der råd til at anvende kommercielle softwareløsninger, der kan varetage den løbende aflevering af data. I mindre projekter kan det regneark, der er udformet for COBie anvendes. I modsætning til de traditionelt anvendte bygningsdelslister, så samler COBie alle informationerne ét sted. Det bliver derved nemmere at udforme listen samt at foretage senere rettelser. (National Institute of Building Sciences) Figur 24, COBie-filen under udførelsesfasen, http://www.wbdg.org/resourc es/cobie.php Ibrugtagning af systemer: Efter at de specificerede produkter er installeret i bygningen (fx ventilationsaggregat) starter den fase der hedder ibrugtagning. Det er ofte her at fabrikantens garantiperiode starter fra, så det er vigtigt at dette dokumenteres. I denne fase er det vigtigt at alle de relevante informationer i forbindelse med driften bliver opdateret i COBie-filen. Dette drejer sig om drift- og vedligeholdelsesdata for de relevante produkter. Dertil kan der tilføjes informationer om brandsikkerhed, opstartsprocedurer, testplaner, nedlukningsprocedurer og planer for Figur 25, COBie-filen ved ibrugnødstilfælde. Som det fremgår af figur 25, så er der i denne fase tilføjet 3 nye tagning, http://www.wbdg.org/resourc es/cobie.php 40 State of the art Kap: 1-2-3-4-5-6-7-8-9 felter (Job, Resource og Spare). De planer der er nævnt herover indsættes under ”job”. For at kunne udføre disse planer kræver COBie, at der foreligger informationer om de kritiske ressourcer (”resource”) for at kunne udføre disse ”jobplaner”. Det vil ofte dreje sig om specielle materialer, værktøjer eller specialtræning af medarbejdere, der er nødvendige for at kunne udføre en speciel opgave. Dertil skal der oplyses om hvilke reservedele, der er nødvendige til drift og vedligehold af de forskellige produkter. Det er ofte at fabrikanter leverer lange planer til entreprenørerne om drift og vedligehold, men efterhånden som COBie bliver implementeret i branchen, er det meningen at fabrikanterne skal levere informationer der rettet mod det specifikke produkt. (National Institute of Building Sciences) 3.5.1 Anvendelse af COBie Arbejdet med udviklingen af COBie er forholdsvist nyt. Derfor er mange af de tilgængelige informationer og erfaringer om praktisk anvendelse af COBie fra pilotprojekter, som til dels har været med i udviklingen af COBie. Den grundlæggende rapport for udviklingen og afprøvningen af COBie er et projekt udført af US Army Corps of Engineers, som er en store amerikanske byg- og driftsherrer. Formålet med projektet var at dokumentere baggrunden og processen der blev brugt til at skabe og implementere pilotversionen af COBie specifikationen. I projektet er det beskrevet hvordan pilotversionen af COBie specifikationen blev implementeret. (Construction Engineering Research Laboratory (CERL), 2007) 3.6 Kravkonfigurator Kravkonfiguratoren er udviklet af Bygherreforeningens Digitaliseringsudvalg til at kunne specificere de data, som der er behov for i driften af byggeriet. Dette er sket i samarbejde med implementeringsudvalget for Det Digitale Byggeri og med senere støtte fra Boligfonden Kuben. Kravkonfiguratoren bruges til at integrere digital aflevering i den aktuelle byggesag, og er et praktisk redskab til at udforme en tillægsaftale til det eksisterende aftalegrundlag. Aftalen kan sammenlignes med IKTaftalen, som ligeledes er et redskab til at styre digitale informationer gennem en byggesag. Det kræver ikke særlige IT-kompetencer at anvende værktøjet, da det er udformet som en hjemmeside med veldefinerede punkter, som gennemgås i en logisk rækkefølge. Det, der er vigtigt, er at kortlægge hvilke informationer, der er essentielle for de aktiviteter, der skal foregå i driften. (Bygherreforeningen) Kravkonfiguratoren blev lanceret i sin endelige version i december 2008 og koster 800 kr. for bygherreforeningens medlemmer og 1600 kr. for ikke-medlemmer. (Bygherreforeningen, kravkonfigurator) 3.6.1 Kravkonfiguratoren i praksis Bygherreforeningen har stillet en licens til kravkonfiguratoren til rådighed, så det har været muligt at afprøve værktøjet. 41 State of the art Kap: 1-2-3-4-5-6-7-8-9 Figur 26, Eksempel fra egen afprøvning af kravkonfiguratoren, http://www.driftsdata.dk/Kravkonfigurator/ Som figur 26 viser, så er kravkonfiguratoren struktureret i fem overordnede punkter, som evt. indeholder underpunkter. Aftalen er bygget op som et paradigme, som det kendes fra andre aftaletyper (fx ABR89), hvor der er en standardtekst, der beskriver de generelle og typiske forhold i byggesagen. Det er dog muligt at redigere i alle tekstfelter, ligesom der er nogle felter, som der skal tages stilling til. Det anbefales at bygherren kortlægger behovet for data inden aftalen udfyldes, for at sikre relevansen af aftalen. I mange byggesager har bygherren problemer med at præcisere, hvordan den digitale aflevering skal foregå og hvilke behov driftsherren har til informationer og dataformater. Kravkonfiguratoren kan være et redskab, der kan støtte bygherre i dette arbejde og hjælpe med at strukturer den digitale aflevering. Det er ikke et redskab, der i sig selv kan løse udfordringerne ved digital aflevering, da der er mange andre forhold, som bygherren skal tage stilling til, men Kravkonfiguratoren virker umiddelbart som et godt paradigme for en aftale. 3.7 Styring af proces, semantik og data Der er et generelt behov i branchen for at kunne styre byggeprocessen, for at sikre at de ressourcer, der tilføres det enkelte projektet, udnyttes fuldt ud. Byggesager består ofte af komplekse organisationer, og for at sikre at de involverede parter ikke starter forfra ved hvert projekt, er det essentielt, at der er et fælles grundlag, som byggeriets parter kan trække på ved hvert nyt projekt. Dette kan både dreje sig om standarder, vejledninger og o.l., men også fælles opfattelser af virkeligheden og indforståede arbejdsgange, der bygger på erfaring og tradition. 42 State of the art Kap: 1-2-3-4-5-6-7-8-9 For at sikre en god informationshåndtering gennem byggeprojekter, er det vigtigt at der fokuseres på de faktorer, der er afgørende for den gode informationshåndtering. BuildingSMART beskriver tre grundelementer, som de mener er afgørende for et godt informationsflow: Digital opbevaring, Terminologi og Proces. Denne rapport anerkender, at det er de tre grundelementer, der skal være defineret for at kunne understøtte et godt byggeprojekt. Mange af de udbredte standarder (officielle og de-facto) og vejledninger, der ligger til grund for samarbejdet i byggebranchen i dag knytter sig til de samme tre grundelementer, som Figur 27, Interoperabilitet gennem standarder, BuildingSMART beskriver. Disse standarder og vejledninger er http://www.ifd-library.org/images/IFD_Library_ White_Paper _2008-04-10_I_.pdf dog fortrinsvis gældende nationalt eller regionalt Byggebranchen er en del af et globalt samfund, hvor parterne i højere og højere grad arbejder på tværs af landegrænser. Dette betyder, at der er behov for, at standardisere på internationalt niveau og ikke bare i de enkelte lande. BuildingSMART har i flere år arbejdet på at standardisere brugen af BIM-modeller og har i dag tre certificerede standarder; IFC (digital opbevaring/datamodel), IFD (terminologi/klassifikation), IDM (processerne). Ved afleveringen af byggeprojekter er der en tendens til, at der fokuseres på formatet af afleveringen, men for at sikre en god aflevering, er det vigtigt også at stille krav til de andre dele (klassifikation og processtyring). I IKT-bekendtgørelsen er der i kravene til digital aflevering især fokuseret på formatet. Krav til klassifikation er dog også nævnt, men som en del af byggeprojektet og ikke nødvendigvis afleveringen. For at sikre en god aflevering er det ikke nok at udforme en kravspecifikation, der specificerer krav til dataformat og klassifikation, det vigtige er at kunne styre processen fra start til slut. Der er i de følgende afsnit givet forklaringer og eksempler på, hvordan disse tre faktorer kan understøttes. 3.8 Dataformat Ved afleveringen kan der vælges forskellige formater til udveksling. Dette gælder både for udveksling af dokumenter og tegningsmateriale. Det materiale som driftsherrerne traditionelt har modtaget har haft til formål at dokumentere det afleverede byggeri, hvilket er vigtigt i forhold til evt. juridiske tvister. De professionelle driftsherrer, som er behandlet i denne rapport, er dog meget interesserede i at modtage information, som der kan ”arbejdes” med – både i forhold til driften og i senere projekter, hvor projektmaterialet i så fald kan anvendes. 3.8.1 Redigerbare formater Redigerbare formater skal forstås som formater, der kan arbejdes videre i. Det vil i de fleste tilfælde betyde, at filerne skal afleveres i deres proprietære formater. For dokumenter og regneark vil det typisk dreje sig om .doc- og .xsl-filer, mens der også findes åbne formater, som det er muligt at arbejde videre som .odt- 43 State of the art Kap: 1-2-3-4-5-6-7-8-9 filer. For tegninger kunne de redigerbare formater være .dwg- og .dgn-filer (AutoCAD og Microstation), mens det for modeller kunne være .rvt- og .pln-filer (Revit og ArchiCAD). Ud fra de interviews, der er foretaget i forbindelse med rapporten, står det klart, at AutoCAD og Revit er så udbredte applikationer i Danmark, at deres filformater ofte bruges i stedet for de åbne formater. 3.8.2 ”Låste” formater De ”låste” formater vil typisk være pdf-filer der anvendes til dokumentation af bygningen. Tankegangen bag afleveringen af pdf-filer af enten dokumenter eller tegninger er at der skal afleveres dokumentation der kan erstatte den tidligere fysiske papirbaserede aflevering. IFC-formatet er ligeledes et format som der ikke kan arbejdes direkte i, men anvendes til dokumentation af bygningen. Formaterne er dog ikke mere ”låste” end at kan der også redigeres i dem med pdf-editorer. Dertil kan filerne konverteres til andre formater, hvor der kan arbejdes videre med informationen ligesom. Der er mulighed for at låse pdf-filer med et password, men dette har vist sig meget let at bryde i praksis 2. 3.8.3 Industry Foundation Classes, IFC Industry Foundation Classes, IFC, er en standard for en datamodel til at opbevare og udveksle data mellem softwareapplikationer. Datamodellen indeholder information, der dækker mange forskellige discipliner, der skal dække hele byggeriets levetid. Standarden er udviklet af BuildingSMART og er certificeret efter ISO under ISO/PAS 16739. Formålet har været at sikre en ”åben” anvendelse af BIM, ved at tilbyde et format, som kan anvendes til udveksling. Softwareleverandørerne skal dermed ikke understøtte mange forskellige udvekslingsformater, men derimod kan de fleste behov understøttes af IFC. En fordel er, at standarden er åben og neutral, og er derved ikke en del af én bestemt softwareleverandørs implementeringsplan. BuildingSMART beskriver på denne baggrund sig selv som ”the home of open BIM”. (BuildingSMART, IFC, 2011) Datamodellen understøtter som nævnt hele byggeprocessen, men de fleste aktører kommer kun til at anvende de dele af IFC, der understøtter deres behov til udveksling. Det er vigtigt at disse behov til udveksling i forskellige situationer bliver beskrevet i såkaldte ”exchange requirements” 3, for at IFC kan understøtte alle processer på en tilfredsstillende måde. 3.9 Klassifikation Der er et behov i byggeriet for at kunne klassificere bygningsdele efter en standard således parterne nemt kan udveksle informationer og have et fælles forståelsesgrundlag. Der anvendes mange forskellige standarder i byggeriet, både nationalt og international. 2 3 Fx: http://www.pdfunlock.com/ En del af Information Delivery Manual 44 State of the art Kap: 1-2-3-4-5-6-7-8-9 3.9.1 SfB Samarbetskomitén för Byggnadsfrågor, SfB, er en klassificering der blev udviklet i Sverige og blev anvendt første gang i 1950. Klassifikationen fik stor udbredelse i udlandet og Danmark især fordi den blev internationalt anerkendt af CommissionInternationale du Batiment, CIB, i 1972. På trods af at klassifikationen er over 60 år gammel har den stadig stor udbredelse i Danmark. (Byggecentrum, 2008) 3.9.2 Dansk Bygge Klassifikation, DBK DBK er et fælles system til klassificering af information om byggeri og bygninger, der er udviklet af bips (byggeri - informationsteknologi - produktivitet – samarbejde) til Det Digitale byggeri. Standarden, lægger rammerne for at kunne klassificere alle dele af byggeriet fra programmering til bortskaffelse. DBK kan udover bygningsdele, bygninger og rum også klassificere aktører, processer, dokumenter, erfaringer og information mm. (Det Digitale Byggeri, 2010) En af de største diskussioner i forbindelse med Det Digitale Byggeri, har været omkring klassifikation i byggeriet, og hvor vidt der er behov for DBK. Der er parter, der mener at SfB eller andre lignende klassifikationer er mere anvendelige end DBK. En af problemstillingerne ved DBK er blandt andet, at det anvender en ”del-af” tankegang ved klassificering, hvor bygningsdelene navngives efter deres placering, og derved kan samme bygningsdel have forskellige navne alt efter placering i bygningen. (Jørgensen, 2011) (Det Digitale Byggeri, 2010) 3.9.3 Omniclass Omniclass er en amerikansk standard, som er under implementering i store dele af Nordamerika. Standarden er implementeret i mange amerikanske software-applikationer og har derfor en vis udbredelse også Danmark. I disse år hvor diskussionen går på om DBK er den rigtige klassifikation at anvende i Danmark, er der blevet stillet spørgsmål om, hvorvidt at Danmark skal have sin egen standard, eller om der skal anvendes en af de store internationale standarder i stedet. Set ud fra det synspunkt at byggebranchen, som så mange andre brancher, bliver mere og mere globaliseret, kan dette være værd at undersøge. 3.9.4 International Framework for Dictionaries, IFD IFD er BuildingSMART’s standard for en klassifikation af bygningsobjekter, og kan beskrives som en standard for terminologi biblioteker eller ontologier. (IFD Library for BuildingSMART) Standarden er ikke en klassifikation der er tiltænkt til direkte anvendelse i konkrete byggeprojekter, men som en mulighed for at kunne oversætte mellem forskellige applikationer. Udviklingen af standarden startede i 1999 i Vancouver ved et ISO-møde mellem forskellige organisationer, der står for udvikling af standarder. Her blev organisationerne enige om, at der var behov for en standardiseret terminologi for at kunne udveksle data mellem applikationer og på tværs af landegrænser mere effektivt. (R. Grant, CSI and IFD Library Group, 2008) Udviklingen af IFD skulle gøre det overflødigt, at alle lande skal anvende den samme klassifikation. Hvis DBK, OmniClass og andre klassifikationer understøtter IFD, så er det muligt at oversætte mellem dem 45 State of the art Kap: 1-2-3-4-5-6-7-8-9 forholdvis nemt. Når først det er defineret hvilke termer i fx DBK der dækker over hvilke termer i IFD kan dette anvendes i andre tilfælde. 3.10 Proces Det er med forskellige standarder og beskrivelser forsøgt at danne et generisk grundlag for arbejdsprocessen i byggeriet. En fælles opfattelse af hvordan byggeprocessen skal foregå er utrolig nødvendig for at sikre, at alle parter har samme grundlag for at forstå, hvilke opgaver de har i forbindelse med et byggeprojekt. Ydelsesbeskrivelsen og aftalegrundlaget(ABR89, AB92, ABT93, tillægsaftaler, ol.) har eksisteret i en del år. De har været med til at strukturere byggeprocessen, og det har været af stor betydning for at kunne sikre et bedre aftalegrundlag og dermed fremme et bedre informationsflow mellem byggeriets parter. Der er dog sket et paradigmeskift i byggeprocessen med den gradvise introduktion af BIM, og der er dermed behov for, at det nye paradigme for byggeprocessen indarbejdes i de eksisterende beskrivelser og aftaler. En forholdsvis ny måde at beskrive informationsflowet mellem byggeriets parter er ved at anvende Information Delivery Manual, IDM. Standarden kan bruges til at beskrive det nye informationsflow mellem byggeprocessen parter både på et generelt niveau for hele byggeriet så det kan indarbejdes i ydelsesbeskrivelsen og aftalegrundlaget. 3.10.1 Ydelsesbeskrivelsen Ydelsesbeskrivelsen er en af de mest grundlæggende standarder for projekteringsarbejdet i byggeprojekter. Der henvises i stort set alle aftaler til denne, for at beskrive de ydelser der knytter sig de forskellige rådgivere. Ydelsesbeskrivelsen beskriver dog først og fremmest rådgiverydelserne i forbindelse med projekteringen, mens andre dele af byggesagen kun er beskrevet ganske kort. Ydelsesbeskrivelsen beskriver fx kun rådgiverens rolle i forhold til driften i et kort afsnit. I de senere år er nyt software og nye arbejdsmetoder blevet introduceret på det danske marked, som kræver at der revideres i ydelsesbeskrivelsen. Med dette formål har en arbejdsgruppe arbejdet på en ny version af ydelsesbeskrivelsen, der er udgivet i en høringsudgave. Denne udgave gør dog ikke revolutionerende op med den traditionelle faseopdeling, som på mange måder er en hindring for at kunne udnytte potentialerne ved BIM. Den traditionelle faseopdeling bygger på det der indenfor softwareudvikling kaldes en waterfall proces, som på mange måder er en gammeldags tilgang til at udvikle nye projekter. Der er derimod mange fortalere for en mere iterativ udformning af ydelsesbeskrivelsen. (Nybo, 2011) 3.10.2 Aftalegrundlag (Rådgiveraftale og IKT-aftale) De juridiske aftaler mellem byggeriets parter er grundlaget for at sikre, at byggesagen forløber, som det er tiltænkt. Denne rapport præsenterer en række processer, som endnu ikke almindelig praksis indenfor byggebranchen, og derfor er det nødvendigt at udforme aftalegrundlaget sådan, at de understøtter den proces, der er tiltænkt. 46 State of the art Kap: 1-2-3-4-5-6-7-8-9 Bygherren har flere parter, som han skal skrive kontrakt med. Kontrakten med rådgiverne udformes som oftest ud fra ”Almindelige Betingelser for teknik Rådgivning og bistand”, ABR89, mens kontrakten med entreprenørerne typisk udformes efter ”Almindelige Betingelser for arbejder og leverancer i bygge- og anlægsvirksomheder”, AB92, eller ”Almindelige Betingelser for Totalentreprise”, ABT93, alt efter entrepriseform. 3.10.3 Information Delivery Manual, IDM IDM er en standard, der er udviklet af BuildingSMART til at beskrive processen i informationsflowet i et byggeprojekt. Sammen med IFD og IFC dækker IDM hele informationsudvekslingen i byggeriet, og tilsammen kan de være et stærkt værktøj til at håndtere informationsudvekslingen i byggeriet. Byggeprocessen er ofte langsom og ineffektiv, som beskrevet i kapitlet: ”Behovet for bedre informationsudveksling”. Informationer er ofte spredt i forskellige dokumenter, og de er ofte modstridende og redundante. IDM er metode, der kan gøre processen ved informationsudveksling mere effektiv, da en IDM kan beskrive det præcise behov til informationer på et bestemt tidspunkt i projektet. IDM er dermed afgørende for en effektiv BIMproces. (ISO, 2010) figur 28 giver et overblik over komponenterne i en IDM og sammenhængene imellem dem. Figur 28, Overblik over de relevante komponenter i IDM, ISO 29481-1:2010(E) Information delivery manual, s. 25 47 State of the art Kap: 1-2-3-4-5-6-7-8-9 I det følgende afsnit vil rapporten forklare de komponenter, som IDM er bygget op af. IDM-standarden skal beskrive den samlede byggeproces. Det er et komplekst område at beskrive, derfor gives der her en kort oversigt af komponenterne. • • • • • • • • Interaction Map (angiver rollefordeling i et projekt) Process Map – PM (angiver opgaver, relationer og udvekslinger) Exchange Requirements – ER (angiver hvilke informationer udvekslingerne skal indeholde) Functional Parts – FP (er det tekniske svar på ”ER” – det kunne være en attribut eller et objekt) Units of Functionality – UoF (samling af entities, relationer og egenskaber for en FP) Exchange Requirement Model (er den tekniske løsning på ER) Business rules (bruges til at variere brugen af et informationsskema uden at ændre i selve skemaet) Validation tests (kontrol af om udveksling fra software overholder ER model) 3.10.4 Interaction Map Et ”interaction map” er en beskrivelse af projektets involverede parter og deres rolle i projektet. Det vil i mange byggesager kaldes for et organisationsdiagram (som fx organisationsdiagrammet for OCC casen (se ”Organisationsdiagram”)). Det er vigtigt at have overblik over de forskellige parters rolle i byggesagen for kunne udforme resten af IDM’en. Det er også her, at det defineres, hvem der har rollen som ”bestiller”, ”afsender” og ”modtager” af forskellig information. 3.10.5 Process Map, PM Et ”process map” eller proceskort er en kortlægning af den proces, der ønskes beskrevet. Herunder alle aktiviteter og deres behov til informationsudveksling. Proceskortet minder på mange måder om traditionelle projekttidsplaner, der kan udføres som gantdiagrammer, da det også beskriver aktiviteter og deres sammenhænge. Forskellen er dog at hvor den traditionelle projekttidsplan beskriver sammenhængene ud fra deres rækkefølge i projektet, så beskriver proceskortet sammenhængene ud fra informationsudvekslingerne mellem parterne i projektet. Dertil er traditionelle projekttidsplaner ofte struktureret efter waterfall-princippet, mens proceskortet i IDM er struktureret efter den iterative proces, hvor der er mulighed for at kunne gå tilbage i processen, hvis der behov for det. Til at udforme et proceskort i IDM anbefales det an- Figur 29, IDM basic framework, ISO 29481-1:2010(E) Information delivery manual, s. 6 vende et BPMN-diagram 4, men det er ikke afgørende. Der er i kapitel 6.1.1 givet et eksempel på hvordan en IDM kan struktureres for en specifik sag. Dertil har Slots- og Ejendomsstyrelsen udformet en IDM for aflevering af arealer, som er beskrevet senere i dette kapitel. 4 Business Process Modeling Notation 48 State of the art 3.10.6 Kap: 1-2-3-4-5-6-7-8-9 Exchange Requirements, ER Exchange Requirements, ER, er en beskrivelse af en bestemt udveksling af informationer i proceskortet. Når parterne er blevet enige om udformningen af proceskortet, skal de enkelte informationsudvekslinger beskrives. Det er det, der kaldes for Exchange Requirements. ER er en ikke-teknisk beskrivelse af kravene til en bestemt informationsudveksling, der dermed ikke knytter sig til et bestemt dataformat. Exchange Requirements bør indeholde følgende: • Et navn der identificerer formålet • En beskrivelse, der giver en et overblik over formålet og indholdet (ISO, 2010, s. 8) 3.10.7 Functional Parts, FP Functional Parts, FP, er en beskrivelse af en enhed af information. som softwareudviklerne anvender til at understøtte et ER. En FP kan i mere almindelige termer beskrives som et stykke information, der er beskrevet i en model eller en del af en model. Det kan fx være et objekt eller en attribut. 3.10.8 Units of Functionality – UoF Units of Functionality er en samling af applikation entities, sammenhænge og property sets. Det er således UoF’erne der styrer fx navngivning og identifikation. 3.10.9 Exchange Requirement Model, ERM Exchange requirement model er den tekniske løsning eller svar på et exchange requirement. Hvor ER er tekstbaseret og uafhængig af et skema, så er ERM skemaafhængig, fordi den er skabt at skemaafhængige dele. ERM er således den datamodel, der svarer et ER. ”Exchange requirement modeller” er særlig betydningsfulde, da de er IDM-komponenter, der: • vil blive støttet inden for software applikationer • indgår i den model view definition, der er certificeret • er de komponenter, som business rules anvendes på • er de komponenter, over for hvilket valideringsforsøg kan anvendes (ISO, 2010, s. 12) 49 State of the art Kap: 1-2-3-4-5-6-7-8-9 Figur 30, sammenhængen i IDM mellem ER og ERM, ISO 29481-1:2010(E) Information delivery manual, s. 15 3.10.10 Business rules ”Business rules” beskriver operationer, definitioner og begrænsninger, der kan anvendes indenfor et sæt data i en bestemt byggeproces. De gør det muligt at udføre kontrol, der kan anvendes til: • brug af særlige entities • attributter og egenskaber, der skal gøres gældende (eller ikke-gældende) • værdier, værdiskalaerne eller værdigrænser, der bør observeres • afhængigheder mellem entities, attributter eller attributværdier (ISO, 2010, s. 13) Business rules kan dermed anvendes til at variere brugen af informationsskemaet, uden at der skal ændres i selve skemaet. I standarden nævnes der et eksempel, hvor der kan tilføjes en business rule der bestemmer at kontorer i bygningen ikke må være mindre end 10 m². Det vil ofte i den praktiske brug resultere i en fejlmeddelelse, som der skal tages stilling til. Derfor har det ikke nogen indflydelse på det underliggende informationsskema, hvis der er en business rule der bliver ændret, tilføjet eller slettet. 3.10.11 Validation tests Validation test er som navnet hentyder til måde at teste modellen, for at se om den er valid i forhold til de Exchange requirements, der er angivet. Testen udføres på den eksport, der sker fra en given softwareapplikation. Valideringsforsøg anvendes i forbindelse med: 50 State of the art Kap: 1-2-3-4-5-6-7-8-9 • at kontrollere, at eksport af oplysninger fra et "Business Information System" opfylder de kvalitetskriterier fastsat i udvekslingskravene (ER) • at forbedre kvaliteten af "Business Information Systemer" og systemløsninger • at give målinger, overfor hvilket krav for "Business Information Systemets" ydelse kan verificeres • sammenligninger mellem "Business Information Systemets", der opfylder de samme mål (når sammenlignet med samme test) (ISO, 2010, s. 15) 3.10.12 Udvikling af en IDM Når det er besluttet at udvikle en IDM bør der tages stilling til hvordan processen planlægges bedst muligt. ISO-standarden opstiller fire emner, der skal tages stilling til før den egentlige udvikling af en IDM: • • • • Definering af formålet Bestemmelse af tilgangen til udviklingen Identificering af ressourcer Etablering af en projektplan Herefter kan det egentlige arbejde med udvikling af en IDM begynde, hvilket kan ske ud fra tre forskellige tilgange: • Process discovery: Denne tilgang er den mest anvendte til udvikling af IDM. Den forudsætter, at der ikke findes nogen software, hvorfra der kan udtrækkes requirement eller exchange requirements, der kan tilpasses. Udviklingen er lineær med feedback mellem stadier i processen. • Business rule customized: Denne tilgang forudsætter, at det er nødvendigt at tilpasse exchange requirement og tilføre nye business rules. • Reverse engineering: Ved denne tilgang forudsættes det, at der findes software, der kan understøtte informationsudvekslingen. Der skal dog undersøge hvilket software, der kan understøtte den valgte exchange requirements. Det kan gøres ved at definere det scenario, som skal understøttes, og derefter vælge det software, der passer bedst. 3.10.13 Model View Definition - MVD. En Model View Definition er det tekniske svar på en IDM. En IDM skal kunne beskrive en bestemt forretningsgang og de informationsudvekslinger, der hører dertil. MVD eller IFC View Definition, som den også kaldes, er der svarer den informationsudveksling, der efterspørges i IDM’en. 51 State of the art 3.10.14 Kap: 1-2-3-4-5-6-7-8-9 IDM til kortlægning af informationsbehov IDM-standarden har mange forskellige anvendelsesområder. Det er de færreste, der kommer til at beskæftige sig direkte med hele standarden, men den er dog meget vigtig for den fremtidige digitale udvikling af byggebranchen. I løsningsforslaget i kapitel 6.1.2 er der udformet et BPMN-diagram ud fra principperne i IDM, der skal beskrive processen omkring afleverin. 3.10.15 IDM for Slots- og ejendomsstyrelsen, SES Der er foreløbig ikke foretaget mange forsøg med at anvende IDM i forbindelse med kravstillelsen i Danmark. Det foreløbig eneste offentligt kendte forsøg er foretaget af Slots- og ejendomsstyrelsen, SES. Baggrunden var, at SES gerne ville undersøge hvilke værktøjer, der kunne hjælpe dem med at leve op bygherrekravene i IKT-bekendtgørelsen. I forbindelse med en bygningskonstruktørs praktikophold hos styrelsen blev der mulighed for at udforme en IDM for ”Vejledning for aflevering af digital arealinformation”. Arbejdet er foretaget i foråret og sommeren 2010, den endelige IDM er udgivet 16/08-2010. Figur 31, Eksempel på BPMN-diagram i IDM, Vejledning for aflevering af digital arealinformation; SES 2010 52 State of the art 3.11 Kap: 1-2-3-4-5-6-7-8-9 Computer Aided Facilities Management, CAFM Softwareapplikationer, der behandler driften af en bygning, betegnes med det internationale ”Computer Aided Facilities Management, CAFM”. Systemerne har forskellige oprindelse, og forskellige områder de dækker. Der er nogle systemer, der forsøger at dække alle aspekter indenfor Facilities Management, mens andre systemer fokuserer på enkelte dele indenfor området. Dertil er der en del applikationer, som er startet med et enkelt anvendelsesområde og derefter har udvidet til andre relevante områder, og som derfor ligger et sted mellem ”totalsystemerne” og de specialiserede systemer. Fælles for systemerne er de forsøger at støtte driftsherren eller facility manageren i dennes arbejde. Der findes mange både nationale og internationale CAFM-systemer, der er i den følgende liste givet et udsnit af de mest kendte: • • • • • • • • • • • Dalux FM, ArchiBUS CoreFM, ArchiFM, TOKMO systems Onuma planning systems. FM systems LogFM Rambyg Caretaker Og mange flere På de følgende sider er der givet en præsentation af de applikationer, der er udvalgt til analysen. Applikationerne er udvalgt for at give en bred beskrivelse af hvilke typer af FM-systemer, der findes på markedet. Der er valgt et webbaseret system og et applikationsbaseret system, som begge er danske og det internationalt mest udbredte system. Det findes mange interessante systemer på markedet, men der har desværre ikke været muligt at undersøge flere end disse tre. 3.11.1 CoreFM CoreFM er et dansk FM-system, der er udviklet af samme firma, som også står bag projektwebløsningen, byggeweb. Systemet er udviklet til at kunne håndtere arealforvaltning, bygningsregistrering, drift og vedligehold, opgavestyring, dynamisk rapportering med mere. (CoreFM) 53 State of the art Kap: 1-2-3-4-5-6-7-8-9 CoreFM startede som et system til at håndtere arealer, men med tiden er systemet blevet udviklet i takt med at brugernes stigende krav og ønsker til systemet. Derfor er der i dag en bred vifte af applikationer, der kan støtte forskellige opgaver i forbindelse med Facilities Management. Det er muligt at vælge den sammensætning af produkter, som organisationen har brug for, og dermed målrette systemet til de opgaver, det skal understøtte. CoreFM består af følgende applikationer: • • • • • • • • CoreFM Hosting CoreFM Areal CoreFM Afdelinger CoreFM Objekter og forekomster CoreFM Bygningssyn CoreFM Planlægning CoreFM Brand CoreFM Vej og park Systemet er webbaseret og giver derfor en let tilgang fra alle computere med internetadgang. Systemet er udviklet i samarbejde med nogle af de større driftsherrer i Danmark, men er kommercielt system, der sælges til alle interesserede. Det har en forholdsvis stor udbredelse blandt driftsherrer i Danmark (anvendes bl.a. af to af de interviewede driftsherrer i denne rapport), hvilket kan skyldes den tætte relation til byggeweb. 3.11.2 LogFM LogFM er et danskudviklet FM-system til håndtering af FM opgaver. Udviklingen af systemet startede med opsætningen af en Acces database til håndtering af de relevante data. I slutningen af 2005 var den første udgave af det databaserede system færdigudviklet og gennemtestet. (LOGFM Aps.) Det er LogFM’s filosofi at driftsprogrammet skal udvikles direkte baseret på driftserfaringer og driftssammenhænge, det er bl.a. derfor at systemet er udviklet i ud fra Acces, da det giver muligheder for nemt at rette og tilføje i systemet. Dette kan dog også føre til meget store udgifter til vedligeholdelse og drift af systemet. LogFM er bygget op omkring en central database, der ligger på en server, mens selve applikationen og interfacet ligger på lokale computere. Systemet består af følgende moduler: • • • • • • Økonomi Kontakter Husk Arealer Vedligehold Stamdata 54 State of the art Kap: 1-2-3-4-5-6-7-8-9 LogFM anvendes af Teknisk Forvaltning på Aalborg universitet, Gentofte kommunes ejendomsforvaltning og Teknisk Forvaltning på DTU. Systemet er databasebaseret, som er installeret på en server og lokale interfaces, der skal installeres på de anvendte computere. Der arbejdes således med systemet på den lokale computer, men alle opdateringer af ejendomsdriften sker i database på serveren. Afprøvningen af LogFM er sket i samarbejde med Teknisk Forvaltning, AAU, og her er der sket en stor grad af tilpasning af systemet til deres behov i samarbejde med softwareudbyderen. Det er i høj grad et samarbejde med Teknisk Forvaltning der danner grundlag for den kommercielle udgave som kan købes af andre driftsherrer. 3.11.3 ArchiBUS ArchiBUS har eksisteret siden 1982 og er et amerikansk system, der har en global udbredelse, dog med en stærk base i hjemlandet USA. ArchiBUS er den største softwareudbyder af systemer til håndtering af ejendomme, infrastruktur og facilities management i verdenen. Samlet set bliver mere end 5 mio. ejendomme administreret gennem ArchiBUS, og deres firmaer sparer ifølge ArchiBUS op mod 34 % på facilities management relaterede udgifter. (ArchiBUS, 2011) ArchiBUS bliver af mange nævnt, som det førende FM-system på markedet 5, og systemet er da også et af de mest omfattende i verdenen. Systemer er bygget op af moduler, hvilket gør at en kunde kan implementere de dele af ArchiBUS, som denne har brug for, og dermed arbejde med et system, der er skræddersyet til de behov og arbejdsgange, som denne organisation har. Modulerne i ArchiBUS er følgende: • • • • • • • • • • • 5 Strategisk Master Planning: optimering af arealer og fremskrivning af arealbehov. Real Property and Lease: Strategisk overblik over ejendomsporteføljen og ind- og udlejningsmodul inkl. dokumenthåndtering og aftalehåndtering, samt omkostningsstyring. Projektmanagement: Modul til håndtering af ejendomprojekter, fx nybyg, renoveringer, energiprojekter eller andre projekter. Capital Budgeting: Styring af projekter og budgetter. Enviromental Sustainability: Mulighed for at opstille måleparametre og dermed dokumentere bæredygtigheden af en ejendomsportefølje. Energi: Giver mulighed for at kunne indsamle data fra forsyningsvirksomheder, CTS-systemer o.l. til benchmarking og dokumentation. Green Building: Udregning af CO₂-udledning og sammenligning mellem bygninger. Conditions Assesment: Modul til håndtering af tilstandsvurderinger for bygninger. Kan evt. anvendes sammen med Capital Budgeting, til prioritering af opgaver. Emergency Prepareness: Generering af evakueringsplaner og oversigter over farligt materiel. Building Operations: Modul til håndtering af planlagt vedligeholdelse ejendomme og tekniske installationer. Service Desk: Web adgang til brugere, hvor de kan bestille service og opgaver (fx fejl og mangler). Jf. interview med Danejendomme og Skanska 55 State of the art • • • • • • Kap: 1-2-3-4-5-6-7-8-9 On Demand Work: Modul til ordre-/rekvisitionsstyring af akutte arbejder for alt fra håndværksopgaver til service. Telecom & Cabel: Modul der skaber overblik over kabelføringen i ejendommen. Space Management: Arealregistrering, arealallokering til afdelinger og anvendelse, samt optimering af arealforbrug. Furniture & Equipment: Registrering og overblik over møbler og udstyr inkl. garantibeviser. Reservation & Hotelling: Modul til reservering lokale, ressourcer, udstyr o.l. Move: Mulighed for at flytte en person, en gruppe eller et rum med inventar. Modulet kan også håndtere større flytninger af fx en afdeling. (Informi GIS, 2011) 3.12 Arealstyringssytemer Mens flere CAFM-systemer har deres oprindelse i systemer, der er udviklet til at kunne styre D&V af bygninger og ejendomme, så findes der systemer, der i stedet har deres fokus på styring af arealer. De applikationer der er beskrevet herunder har begge et større anvendelsesområde end arealstyring, men det er det område de udviklet fra, og det er stadig deres kerneområde. Generelt virker det til, at der er en udvikling i retning af at softwareudbyderne gerne vil tilbyde applikationer, der dækker større dele af byggeriet og dermed udvide deres markedsandel. 3.12.1 Dalux Dalux er en softwareleverandør, der udbyder en række applikationer til byggesager og drift af bygninger. Hovedapplikationen er DaluxFM, men firmaet udbyder også nogle mindre applikationer til byggebranchen, som er beskrevet herunder: • • • • DaluxFM: Denne applikation fungerer som et CAFM-system, der kan styre en portefølje af bygninger. Dalux har deres udgangspunkt i styringen af arealer og bygningerne, men vil med denne applikation også gerne kunne tilbyde software, der kan styre alle dele af FM. Dalux Building View: I denne applikation er det muligt at præsentere bygninger i 3D i deres lokalmiljø til brug i konkurrencer, lokalplaner og lignende. Dalux BIM Checker: Denne applikation anvendes til at kontrollere om en BIM-model overholder kravene fra bygherren, IKT-bekendtgørelsen og IFC-formatet. Dalux Config: Det er muligt med denne applikation at designe modulbygninger i 3D til brug i forbindelse med simple byggerier, som fabrikshaller. Det er dermed nemt at foretage mængdeudtræk, prisoverslag og visualiseringer på et tidligt tidspunkt i byggesagen. (Dalux) 3.12.2 Onuma Onuma systems er et planlægningssystem til at styre processen med at skabe og vedligeholde en BIMmodel gennem en byggesag. Forskellen fra modelleringsværktøjer er at denne applikation er at Onuma systems kan anvendes til skematisk design, til at samle modeller, udføre analyser og styre porteføljer og 56 State of the art Kap: 1-2-3-4-5-6-7-8-9 arealer. Onuma systems er dermed mere end et arealstyringssystem og kan anvendes til at styre en BIMbyggesag gennem hele byggeriets levetid. (Onuma) 3.13 Central Tilstandskontrol og Styring, CTS Central Tilstandskontrol og Styring, CTS er et dansk begreb der dækker over computersystemer til overvågning, styring og regulering af de tekniske anlæg i en bygning. Systemerne kaldes i internationale sammenhænge for Building Management System, BMS. (Energiwiki) 3.13.1 Systemer, generelt Der er et bredt udvalg af systemer, der kan styre de tekniske anlæg i en bygning. Der er i denne rapport dog ikke gået dybden med de enkelte systemer. Det systemerne kan er at overvåge, styre og regulere forbruget af vand, varme og el samt ventilationsanlægget. 3.13.2 Integration mellem CTS-systemer og CAFM-systemer Som beskrevet i rapporten så er FM mere end styring af D&V af en bygning. FM handler om at styre alle de funktioner, der understøtter den primære funktion i bygningen. Derfor er der interessant at undersøge, hvordan CTS kan kobles sammen med CAFM-systemerne. Den umiddelbare fordel vil være, at det bliver nemmere at overskue forbruget i forhold til FM opgaver. 3.14 Mindre applikationer til styring af aflevering Der er en række mindre applikationer, der kan støtte byggeriet aflevering. En større opgave for entreprenørerne i forbindelse med afleveringen er at holde styr på fejl og mangler, i det byggeri der skal afleveres. Styringen af fejl og mangler kan være en uoverskuelig proces, især i større byggerier hvor der er mange entreprenører på byggepladsen. Interviewet med MT Højgaard (se kapitel 11.9) har gjort det klart, at der er en stor hjælp for entreprenørernes aflevering af et byggeri, at de har et værktøj, der kan styre og strukturere afhjælpningen af fejl og mangler. 57 State of the art 3.14.1 Kap: 1-2-3-4-5-6-7-8-9 Digitjek Digitjek er en applikation fra Logimatic (tidligere Byggesoft), der eksempelvis kan styre og systematisere mangelgennemgang. Det kræver, at der medbringes en computer eller en form for PDA, som kan registrere de fejl, svigt eller mangler, der måtte være ved gennemgangen. Applikationen anvender plantegninger til at lokalisere problemet, og der kan tilknyttes kommentarer og/eller billeder. Problemet bliver i samme omgang adresseret til den pågældende håndværker, så denne straks kan planlægge afhjælpningen af problemet. Systemet kan igen anvendes, når håndværkeren melder problemet afhjulpet fx ved hjælp af en sms besked. (Logimatic) Figur 32, Interface for Digitjek, http://www.byggesoft.dk/DigiTjek-produktark.pdf Logimatic nævner selv følgende fordele ved at anvende deres applikation: • • • • • Registrer mangler direkte på digitale tegninger for præcis angivelse af placering Distribuer nemt og hurtigt til alle involverede parter via indbygget adresseliste Find hurtigt relevant information via brugervenlige søgemuligheder Tilføj eventuelt billeder eller dokumenter til hver mangel for dokumentation Intet behov for internetadgang i forbindelse med gennemgang (Logimatic) Det er muligt at styre rettighederne i Digitjekt således at parterne i byggesagen kun har de relevante fejlmeldinger at forholde sig til. Digitjek giver således mulighed for nemt at styre antallet af fejl og mangler og dermed sikre at der hurtigere kan ske aflevering til bygherren. (Yding-Sørensen, 2011) 58 State of the art 3.14.2 Kap: 1-2-3-4-5-6-7-8-9 Fotodok Fotodok er ligeledes en appliaktion fra Logimatic, der kan anvendes til fotodokumentation. Applikationen kan anvendes i forbindelse med kvalitetssikring eller tilsynsrapporter. Fotodok kan køre på de fleste mobiltelefoner, og dermed sikres det, at værktøjet altid er til stede på byggepladsen. Logimatic nævner følgende fordele ved at anvende Fotodok: • • • • • • • Allerede på byggepladsen sammenknyttes billeder og tekst nemt og hurtigt via foruddefinerede tekster eller fritekst. Fotodokumentationen sendes automatisk fra mobiltelefonen til hjemmesiden, og kan hurtigt findes frem, når den skal bruges. Word-dokumenter med billede og tekst genereres nemt med et enkelt tryk på hjemmesiden. Billeder fra forskellige byggesager sammenblandes ikke, da de allerede på mobiltelefonen tilknyttes det rigtige projekt. Alle medarbejdere kan fotodokumentere deres arbejde med det samme. Den høje kvalitet sikres igennem hele byggeprojektet fra værktøj til dokumentation. Mindre administrationsarbejde på kontoret. (Logimatic) Figur 33, Interface i Fotodok samt eksporteret rapport fra Fotodok, http://www.youtube.com/watch?v=arxPe5uqym0&feature=player_embedded Fotodok kan anvendes til at strukturere kvalitetssikringen af byggeriet gennem en webbaseret database, som kan tilgås af de relevante parter. Applikationen kan ligeledes udforme rapporter for KS gennem foruddefinerede skabeloner i Word. 59 State of the art 3.14.3 Kap: 1-2-3-4-5-6-7-8-9 E TJEK E TJEK er et kvalitetssikringsværktøj, der kan anvendes på byggepladsen. Det er muligt nemt at oprette nye sager ud fra indbyggede skabeloner, der sikrer at erfaringer fra tidligere projekter inddrages i det nye projekt. Applikationen har et indbygget projektweb, hvor det er muligt at dele dokumenter, billeder mv. Det er muligt at styre rettighederne for de involverede parter således, at der kun er den relevante information til stede for dem. (BASIT) E TJEK kan også bruges til at aflevere byggesagen. Der udformes en rapport i systemet ud fra de indtastede informationer om kvalitetssikringen, som afleveres til bygherren. Figur 34, Interface i E TJEK, http://www.etjek.dk 60 Casebeskrivelse 4 Kap: 1-2-3-4-5-6-7-8-9 Casebeskrivelse I dette afsnit er der givet en kort beskrivelse af den anvendte case i rapporten. For yderlig information om casen henvises der til de interview, der er foretaget med de involverede parter. Den case, der er anvendt i denne rapport, er et citycenter i Odense, som forventes at stå færdigt i 2015. Baggrunden for at der er valgt netop denne case er, at der er stillet konkrete krav om digital aflevering. Aarhus Arkitekterne har i denne forbindelse været interesseret problemstillingerne omkring den digitale aflevering, så firmaet er i stand til at styre den digitale aflevering allerede fra et tidligt stadie i byggeprocessen. Aarhus Arkitekterne er dog kun en del af et større rådgiverteam, der løse opgaven med at projektere byggesagen og herunder styre den digitale aflevering. De involverede parter er: • • • • • • Steen og Strøm A/S, bygherre Steen og Strøm ejer og driver nogle af de største storcentre i Danmark, herunder Fields og Bruuns Galleri. På det nye City Center i Odense er Steen og Strøm dermed både bygherre og driftsherre. Moe og Brødsgaard A/S, bygherre og projektleder Moe og Brødsgaard er et rådgivende ingeniørfirma, som tilbyder en bred vifte af rådgiverydelser. I denne case fungerer Benoy: Skitserende arkitekt. Benoy er et hollandsk arkitektfirma der har stået for centerbyggerier over hele verden og er kendt for de særlige Benoy-kompetencer: dynamisk integration af historik, etnicitet, bymidtekultur, transportmønstre og kommercielle aktiviteter, oplyser udviklingsdirektør Karen Nielsen, Steen & Strøm Danmark. Aarhus arkitekterne Co-arkitekt og projekterende arkitekt. De skal stå for myndighedsprojekt og hovedprojekt og skal sørge for at danske regler og byggeskikke bliver overholdt. De overtager dermed arkitektydelserne fra Benoy efter skitsering. Grontmij A/S, rådgivende ingeniør. Grontmij er et rådgivende ingeniørfirma der i denne case skal levere alle ingeniørydelse i forbindelse med projektet. Skovhus Architects A/S, lokal arkitekt. Skovhus Architects er et lokal arkitektfirma, der skal hjælpe organisationen med lokalkendskab, og erfaring med kontakt til myndigheder og lokale interessenter. (Tv2 Fyn, 2011) Tilsammen skal de involverede parter udforme projektmaterialet til Danmarks største City Center, på ca 70.000 kvadratmeter. 61 Casebeskrivelse Kap: 1-2-3-4-5-6-7-8-9 Country Manager, Søren Brogaard fra Steen & Strøm Danmark udtaler: ”Vi er meget tilfredse med købet af byggegrunden, da vi længe har ønsket at udvikle og drive et shoppingcenter i Odense midtby. Med byens størrelse og status som landsdelscenter på Fyn har Odense savnet et stort, overdækket shoppingmiljø, som kan styrke midtbyens samlede detailhandelstilbud til Fyns borgere” (Steen og Strøm A/S) 62 Casebeskrivelse 4.1 Kap: 1-2-3-4-5-6-7-8-9 Organisationsdiagram 63 Kap: 1-2-3-4-5-6-7-8-9 Analyse 5 Analyse Der er foretaget en analyse af branchen indenfor digital aflevering. For at give et nuanceret billede er der fortaget interviews med forskellige typer af driftsherrer, samt forskellige rådgivere og en entreprenør. Dertil er der foretaget tests af CAFM-systemer for at undersøge, hvordan de kan støtte driften af bygninger. I dette kapitel er der anvendt metoderne: Contextual Inquiry, Work Modelling og Consolidation fra Contextual Design. Der er i det følgende afsnit udført analyse af aflevering i den danske byggebranche. Det er sket gennem interview med forskellige parter inden for byggebranchen. Der er udvalgt 5 driftsherrer/bygherrer, 3 rådgivere og 2 entreprenører, som tilsammen giver en indikation af, hvad status er i byggeriet i dag. Selve interviewene i deres fulde længde findes i ”kapitel 11, Bilag,” mens der i de følgende afsnit er samlet op på dem i de viste matrix’er. Efter hvert matrix er der samlet op på de centrale problemstillinger, der fremsættes af de interviewede personer. Problemstillingerne danner baggrund for de efterfølgende ”work models” og test af systemer. 5.1 Analyse af driftsherren Virksomhed/Område Hvordan er organisationen i de byggesager i er involveret i og hvilke konsekvenser har det for jeres evne til stille krav til afleveringen? Teknisk Forvaltning, AAU (TF) Der er en opdeling mellem UBST, der bestiller byggeriet og Teknisk Forvaltning, AAU, der driver byggeriet. Slots- og ejendomsstyrelsen (SES) SES er både bygherre og driftsherre, for de bygninger de ejer, og de byggesager de er involveret i. Der er lavet rammetaler med rådgivere. Dan-Ejendomme a/s (DE) DE administrerer ejendomme for andre. Virksomheden er derfor typisk ikke involveret i projekteringen af de bygninger, de administrerer. Steen og Strøm a/s (SS) SS er både bygherre og driftsherre for deres bygninger. Skanska a/s (SK) SK er et udviklingsselskab, der bygger for at sælge videre. SK er typisk driftsherre kortvarigt efter udført byggeri, hvorefter bygningen overdrages til en ny driftsherre 64 Kap: 1-2-3-4-5-6-7-8-9 Analyse 5.1.1 Konsolideret problemstilling for organisationen: Som interviewene viser, er der ikke en entydig organisation af bygherre og driftsherre i alle byggeriorganisationer. Teknisk forvaltning (AAU), Danejendomme og Skanska er alle en del af byggesager, hvor der er en opdeling mellem bygherre og driftsherre. Teknisk Forvaltning og Danejendomme er driftsherrer og oplever begge problemer med at få deres krav til driften igennem til bygherren. Skanska er typisk bygherre for de byggesager, de er involveret i og vil typisk forsøge at sælge bygningen kort tid efter, den er opført. Virksomhed/Område Driften af bygninger Teknisk Forvaltning, AAU TF forsøger at gøre data for FM mere tilgængelige. Det kan fx dreje sig om rapportering af fejl på bygninger, hvor TF har et ønske om, at dette kan foregå nemmere. Slots- og ejendomsstyrelsen SES har en bestiller-funktion, hvor de udfører tilsyn på deres bygninger, hvilket fører til udbud på de opgaver, der skal udføres. Dan-Ejendomme a/s Ansvaret for drift og vedligehold ligger hos projektlederen som understøttes af den enkelte vicevært eller bygningsinspektør. Herunder budgetterne for den enkelte bygning. Budgetterne bygger i høj grad på den ansvarlige driftsleders tilstandsvurdering. Steen og Strøm a/s SS har et centralt hovedkontor, hvor det overordnede arbejde planlægges og koordineres, mens den daglige drift varetages af de enkelte centre. For hvert center er der en driftsleder, som styrer nogle driftsfolk. Denne driftsleder er med til at udforme budgetter for dennes center og har også ansvaret for, at det bliver overholdt. Skanska a/s Den primære forretning for SK er at købe og udvikle ejendomme for derefter at sælge dem videre. Hvis markedssituationen ikke er rigtig, beholder de ejendommen, til markedet har ændret sig. Det er bl.a. derfor, at SK ejer og administrerer 20.000 m2 kontorer og p-kældre. 5.1.2 Konsolideret problemstilling for driften: Der er et behov for at gøre systemerne, der styrer driften, mere tilgængelige for flere interessenter. De interviewede driftsherrer har generelt en central organisation, der står for planlægningen af driften af bygningerne. Under denne centrale styreenhed er der et driftspersonel, der står for den praktiske drift af bygningerne. Dette driftspersonel har typisk en form for adgang til FM-systemet alt efter organisationen, men andre interessenter, som de almindelige brugere af bygningen, myndigheder og leverandører kunne med fordel også få en større adgang til data i FM-systemet. 65 Kap: 1-2-3-4-5-6-7-8-9 Analyse Virksomhed/Område Systemer Teknisk Forvaltning, AAU TF anvender LogFM til at styre og planlægge opgaver på D&V. I LogFM kan TF også styre økonomien for D&V af de forskellige bygninger. TF anvender en webbaseret applikation til at vise m2 og antal rum ud fra forskellige filtreringer (fakulteter, bygninger, lejemål ol.). Slots- og ejendomsstyrelsen Den centrale applikation for SES er Navision, som er deres økonomistyringsværktøj. De andre applikation bruges til at planlægge opgaver og skabe overblik. Det første system som SES implementerede var Ryhti der skulle håndtere energiudgifter, det er senere blevet brugt til flere forskellige anvendelser. Der anvendes Dalux FM til at administrere arealer. Dan-Ejendomme a/s BA udtaler: “Der findes ikke et dansk udviklet FM system, som i tilstrækkelig grad dækker hele vores behov”. DE anvender et system der hedder Unik bolig 4 til at administrere bygninger, herunder huslejeopkrævning og drift og vedligehold. Dertil anvender de et system, der hedder Software innovation til dokumenthåndtering og et system, der hedder Adventure DIOS, til opgavehåndtering i driften. Steen og Strøm a/s SS anvender CoreFM. I første omgang var det for at kunne håndtere tegninger, men senere er applikationen også anvendt til at styre drift og vedligehold samt styring af arealer. SS anvender et system, der hedder Finistra til at styre økonomien. En del af systemet hedder Visma som bruges til at producere regneark. Dette regneark bruges til styring af opgaver ved større renoveringer. Generelt bruges byggeweb til at planlægge arbejdet. Skanska a/s Meget af styringen er foregået gennem excel og de andre officeapplikationer. Skanska er dog ved at implementere CoreFM i forbindelse med et projekt, der er ved at blive afleveret. Det er vigtigt for SK at have de rigtige arealer i forbindelse med huslejeberegning. De undersøger derfor bl.a. Dalux’s arealhåndtering. 5.1.3 Konsolideret problemstilling anvendelsen af systemer: Der arbejdes med flere forskellige systemer til at styre FM i de driftsorganisationer, der er analyseret. Der anvendes forskellige systemer til at styre D&V, håndtering af arealer og økonomi. Det kan skabe problemer med at sikre at FM-data er valide. Ved anvendelse af flere forskellige systemer, kræver det stor disciplin at sørge for at data i de forskellige systemer er opdaterede. 66 Kap: 1-2-3-4-5-6-7-8-9 Analyse Virksomhed/Område Afleveringen Teknisk Forvaltning, AAU TF modtager dog både IFC og Revit/AutoCAD til dokumentation eller “as built” og opretter en kopi, som der arbejdes på i driften. RW mener at der er en generel problemstilling omkring, hvem der skal taste de specifikke oplysninger ind i modellen. Han mener, at der skal kigges på ydelsesbeskrivelsen, hvor der kun er krav til dokumentation og tegninger. Slots- og ejendomsstyrelsen I forhold til afleveringen har det været vigtigt for SES at få defineret hvilke bygningsdele, som de har behov for at modtage D&V-data om. Ved Bygherrekravene i 2007 (IKT-bekendtgørelse 1365) blev der lavet et forsøg med IDM som et værktøj til at beskrive kravene til aflevering af arealer. CD mener, at det er vigtigt ikke at være for specifik med at stille krav til aflevering. Fx er det problematisk at stille krav om specifikke dataformater som IFC, da det udelukker nogle. Dan-Ejendomme a/s De prøver dog at overbevise deres kunder om, at det er en god ide at stille krav til den digitale aflevering. En af de udfordringer, som DE møder ved digitalisering, er problematikken om, hvem der ejer data. En anden generel problematik, som DE står overfor, er, at det er bygherren, der opnår fordelene ved en øget digitalisering, men det er DE, der laver investeringen. Der er en kløft, mellem hvem der laver investeringen, og hvem der høster gevinsten. I de projekter hvor der er digital aflevering, stiller DE krav om D&V-data på de enkelte bygningsdele. Der stilles ikke krav om aflevering af arealer, da det kan skabe problemer omkring, hvordan opmålingen skal foretages. Derfor trækker DE selv arealerne ud af model eller tegninger. Steen og Strøm a/s SS vil gerne modtage D&V-data på de enkelte bygningsdele. Der er vigtig at de produktblade, der afleveres er på den specifikke bygningsdel. Generelt kræver det et stort engagement fra SS at sikre, at de rigtige D&Vdata specificeres og afleveres. Mange rådgivere har ikke så meget erfaring med hvilke D&V-data, der vigtige for BH. Skanska a/s I det projekt som SK lige har afleveret, stilles der krav om digital aflevering. Det var oprindeligt tanken, at der skulle afleveres direkte i CoreFM, men det viste sig at entreprenørerne ikke havde kompetencerne til at udføre denne opgave. Derfor afleveres der nu gennem byggeweb. Der er ikke stillet specifikke krav til D&V-data, men der er taget udgangspunkt i Ydelsesbeskrivelsen. Der har i det hele taget været en del problemer med at overbevise entreprenøren om, at afleveringen skulle foregå på en anden måde end den traditionelle. 67 Kap: 1-2-3-4-5-6-7-8-9 Analyse 5.1.4 Konsolideret problemstilling for afleveringen: Afleveringen er præget af, at der problemer med at stille de rigtige krav. I Steen og Strøm og SES tilfælde anvender de kravspecifikationer, der sikrer, at der er en form for ensartethed i det materiale, de modtager i forbindelse med afleveringen. I de andre tilfælde er der ikke samme styring af afleveringen af informationer, hvilket gør, at det er mere usikkert, hvad der bliver afleveret af data, og hvilket format det modtages i. Dertil er afleveringen et område, der kræver en løbende overvågning, da mange rådgivere og entreprenører er mere fokuserede på at designe og bygge end at aflevere informationer om byggeriet. Udover det almindelige behov for D&V-data, er der også et behov for informationer om arealer og rum i bygningen. Som det er nu, er det ofte informationer, som driftsherrerne selv skaber ud fra det afleverede materiale. Der er dog fra SES’s side lavet et forsøg på at beskrive kravene til aflevering af arealer, men det er usikkert, hvor meget det kommer til at blive anvendt. Virksomhed/Område Overførsel af data Teknisk Forvaltning, AAU De D&V-data som TF modtager fra entreprenøreren i forbindelse med afleveringen overføres ikke direkte til LogFM, men skal vurderes og “manipuleres” før det tastes ind i LogFM. Forstået på den måde at TF har nogle erfaringer med bestemte bygningsdele, som kan være forskellig fra den opfattelse som entreprenører eller producenten har af de samme bygningsdele. Slots- og ejendomsstyrelsen SES lader ikke rådgivere og entreprenører indtaste informationer direkte i deres systemer, da det er besværligt at håndtere nye brugere i systemet. I stedet stiller de krav om at alle bygningsdele afleveres i excel-skabelon, som tastes ind i systemet. Dan-Ejendomme a/s Der er en problematik i at stille krav om fx BIM modeller. Det fx et problem at det ikke kan importeres til FM-systemet. I de fleste byggesager vil der tilmed være en eller flere aktører, der ikke anvender 3D. Steen og Strøm a/s Overførsel af data fra byggeri til drift sker, ved at entreprenørerne indtaster informationerne direkte i CoreFM. Skanska a/s Det er ikke lykkes at få entreprenørerne til at taste D&V-data direkte ind i CoreFM. Det er derfor SK, der selv taster dette ind ud fra de bygningsdelskort og produktblade, de modtager. 5.1.5 Konsolideret problemstilling for overførsel af data: Der er ofte en del arbejde for driftsherren med at bearbejde og overføre data til dennes system. Af de driftsherrer, der er interviewet, er det kun Steen og Strøm, der lader entreprenørerne indtaste informationer direkte i FM-systemet. I de andre tilfælde ligger der et arbejde for driftsorganisationen i at tilpasse og indføre informationerne i systemet. 68 Kap: 1-2-3-4-5-6-7-8-9 Analyse I de organisationer, der er analyseret, står det klart, at de ikke er klar til at modtage D&V-information direkte i en model. Der modtages i nogle tilfælde modeller til tegningsdokumentation, men informationer om D&V overføres typisk ved indtastning i FM-systemet eller ved kopiering fra excel-ark eller andre formater. Virksomhed/Område Fremtiden Teknisk Forvaltning, AAU TF har et samarbejde med DTU omkring udvikling af et system, der kan rapportere fejlmeldinger via foruddefinerede skabeloner. Det vil gøre fejlmeldingen mere overskuelig og nemmere at planlægge opgaver for TF. TF arbejder på at kunne koble LogFM med CTS-systemerne i de enkelte bygninger. TF vil også gerne kunne håndtere udbud af regøring i LogFM. RW ser en mulighed for at rådgiverne udnytter muligheden for at koblebygningsobjekterne i modellerne til en URL-adresse. Slots- og ejendomsstyrelsen Bygherre skal blive bedre til at stille krav om digitalisering, men rådgivere skal og blive bedre til at rådgive deres bygherre om fordele og muligheder ved øget digitalisering. I forhold til de fremtidige krav om anvendelse af IFC ved aflevering tager SES det stille og roligt. Da de mest har renoveringsopgaver, mener de ikke at de bliver berørt af kravene. “BIM er et værktøj - det er bilen vi kører for at komme derhen, hvor vi gerne vil.” Dan-Ejendomme a/s Det skal ikke nødvendigvis være en enkelt applikation, der skal håndtere hele FM-processen, men det er vigtigt med en central database, hvor alle informationer bliver opdateret. Hvis data kunne sammenstilles på en mere dynamisk måde kan det anvendes i business cases ol. I fremtiden er vigtigt at få endnu bedre overblik over data, herunder at kunne holde styr på arealer og bygninger, samt at kunne anvende data mere dynamisk. Hvis der skal kigges langt ud i fremtiden, så er RFID-tags en interessant mulighed for at kunne koble de fysiske bygningskomponenter til deres digitale bygningsobjekter. Steen og Strøm a/s CC mener det er vigtigt at der sker en synergi mellem de forskellige opgaver. SS kigger i øjeblikket på hvordan interfacet er for de enkelte driftsfolk, så det bliver nemmere at melde opgaver ind til systemet. 69 Kap: 1-2-3-4-5-6-7-8-9 Analyse Skanska a/s På kort sigt skal SK være bedre til at stille specifikke krav om D&V-data til deres entreprenører. På længere sigt vil SK gerne kunne arbejde med BIM-modeller i forbindelse med FM. Eller GIS-modeller så information om de omkringkiggende bygninger kommer med. Dertil har AutoDesk et spændende program, der kan koble CTS og bygningsmodel, så det bliver nemmere at udføre analyser af en bygnings performance. 5.1.6 Konsolideret problemstilling for fremtiden: Driftsherrerne har generelt problemer med at stille de rigtige krav, men der er et behov for specifikke D&Vdata samt informationer om arealer. Der er flere af driftsherrerne, der mener, det er vigtigt, at der skabes en synergi mellem de opgaver, der ligger indenfor facilities management. Det nævnes blandt andet at der kan anvendes en database til at opbevare informationerne hvorfra flere applikationer kan hente og bruge data. Dertil søger flere af driftsherrerne at gøre FM-systemerne og –informationerne mere til tilgængelige for flere interessenter i driften. Flere af driftsherrerne mener også at informationerne om driften skal kunne udnyttes mere proaktivt til fx business cases og analyser af bygningers ”performance”. 70 Kap: 1-2-3-4-5-6-7-8-9 Analyse 5.2 Analyse af rådgiver Virksomhed/Område Organiseringen Moe & Brødsgaard Moe og Brødsgaard er i byggesagen Odense City Center både bygherrerådgiver og projektleder for rådgiverne. Grontmij Grontmij er hovedprojekterendeog står derfor bl.a. for at koordinere den digitale aflevering i samarbejde med de andre rådgivere. Aarhus arkitekterne Aarhus arkitekterne er den projekterende arkitekt på projektet. 5.2.1 Konsolideret problemstilling for organiseringen: Byggesagerne er ofte præget af, at der er mange parter der indgår i projektet, hvilket kan føre til mange usikkerheder og misforståelser. Dertil kan det være svært at styre datastrømmen mellem de mange involverede parter, således at driftsherren får et ensartet og relevant materiale til driften. Virksomhed/Område Afleveringen, generelt Moe & Brødsgaard Generelt er det i komplekse byggerier hvor der oftest stilles krav, hvilket hænger sammen med at der er en driftsmæssig fordel at hente. Grontmij Afleveringen foregår traditionelt ved, at der afleveres en del papkasser til bygherren/driftsherren, og foregår stadig i mange sager. Der er dog en del sager, hvor der afleveres en cd med projektmateriale. JP anslår at det foregår i ca. halvdelen af sagerne. Det er de færreste bygherrer/driftsherrer, der ved hvad de vil have, hvilket resulterer i at der er mange sager, hvor der ikke stillet krav til afleveringen. Aarhus arkitekterne Der er ikke meget fokus på digital aflevering og drift. Der er flere elementer, der skal tages hensyn til i en byggesag som økonomi og æstetik. 5.2.2 Konsolideret problemstilling for den afleveringen: Digital aflevering er stadig et nyt område som der indtil nu ikke har været meget fokus på. Det er ofte større komplekse byggerier, hvor der stiles krav da det er her de største og mest evidente fordele ved digitalisering er til stede. De fleste bygherrer og driftsherrer ved ikke, hvad de vil have, hvilket resulterer i uklarhed om, hvad der skal afleveres og hvordan. 71 Kap: 1-2-3-4-5-6-7-8-9 Analyse Virksomhed/Område Afleveringen i byggesagen, OCC Moe & Brødsgaard Der er i byggesagen også udpeget en facilitator der skal sørge for at den digitale aflevering sker efter de foreliggende aftaler. Det skal sikre at centeret kan køre fra dag 1, og at man ikke sidder med en cd-rom eller lignende og skal starte forfra. Derfor afleverer man i løbende i CoreFM. Det er vigtig at have udpeget en facilitator for at sikre af den digitale aflevering forløber som det er tiltænkt. Grontmij Der er i OCC-sagen valgt at bruge CoreFM som driftssystem. Der er dog ikke den kobling mellem byggeweb og CoreFM som man kunne ønske sig og derfor skal informationerne tastes ind i systemet. Grontmij har en driftsafdeling der er koblet på projektet og arbejder med kravspecifikationen. Aarhus arkitekterne Dette er en af problemstillingerne ved digital aflevering. Fra rådgivers side er det ikke muligt at definere specifikke bygningsdele da entreprenørerne skal have mulighed for at kunne vælge produkter. Det som rådgiverne definerer er kravene til bygningsdelene, hvilket kan være problematisk i forhold til modellen. 5.2.3 Konsolideret problemstilling for afleveringen i OCC: Det skal undersøges hvordan der kan arbejdes med bygningsdelene, hvor de er generiske i projekteringen men produktspecifikke i udførelsen. Det nævnes, at der anvendes byggeweb og at det godt kunne ønskes, at der var en kobling mellem byggeweb og CoreFM. Derfor afleveres ved indtastning i CoreFM. Til dette er der udpeget en facilitator, der skal sikre, at afleveringen forløber som ønsket. Virksomhed/Område Systemer Moe & Brødsgaard Der anvendes et projektweb til opbevare de digitale data, hvor man anvender brugerrettigheder til at styre at de rette parter har adgang til de rette informationer. Det er i aftalegrundlaget stillet krav om, at der afleveres en ”as-built”-model. Det er også her defineret at modellen er bygherrens og ikke rådgiverens, så der ikke opstår juridiske problemstillinger på et senere tidspunkt. 72 Kap: 1-2-3-4-5-6-7-8-9 Analyse Grontmij Driftsdata opbevares typisk på projektweb, hvis det er en del af aftalen i byggesagen. Det kan enten være som excel-skemaer eller pdf-filer. Det er dog tanken at entreprenørerne skal taste D&V-informationerne ind i CoreFM løbende, og dermed er det her at informationerne opvares under udførelsen. Aarhus arkitekterne Det er ofte excel, der anvendes til at skabe overblik over byggesagen. 5.2.4 Konsolideret problemstilling for systemer: Der anvendes et projektweb til at opbevare de digitale data. Dertil anvendes der modeller til at opbevare projektmaterialet. Driftsdata opbevares typisk på projektweb enten i form af pdf-filer eller excel-skemaer, dog skal entreprenørerne løbende indtaste informationerne i CoreFM, og dermed er det også her at driftsdata opbevares gennem udførelsen. Virksomhed/Område Overførsel af data Moe & Brødsgaard Det er udfordringer ved at sikre at ændringer når frem til de rigtige parter. Fx at ændringer hos entreprenører kommunikeres videre til ingeniører. Det er utroligt vigtigt at ”as-built”-modellen bliver opdateret med de helt rigtige komponenter. Grontmij Ingeniørerne afleverer projektmaterialet til bygherren efter rådgiver aftalen. Entreprenørerne skal taste informationerne direkte ind i CoreFM. Grontmij har en driftsafdeling der står for meget af arbejdet omkring driften og de er lige gået i gang med at kigge på kravspecifikationen. Aarhus arkitekterne Det er endnu ikke fastlagt hvordan afleveringen skal forløbe. Det er planlagt at entreprenørerne skal aflevere ved indtastning i CoreFM, men det kan ende med, at der afleveres i excel-skemaer, hvor informationerne overføres fra. 5.2.5 Konsolideret problemstilling for overførsel: Selve afleveringen af data er planlagt til at skulle indtastes i CoreFM. Der er dog usikkerhed om hvorvidt det kan lykkes eller om der afleveres i filer (fx excel) i stedet. Virksomhed/Område Fremtiden Moe & Brødsgaard Det er vigtigt at digital aflevering bliver brugt i flere sager, og at der kommer nogle standarder for, hvordan det skal gøres. Det kræver så, at der er flere der får øjnene op for fordelene ved digital aflevering. Især dem der bruger mange ressourcer på energi og driften, da det er her de største fordele ligger. 73 Kap: 1-2-3-4-5-6-7-8-9 Analyse Grontmij I fremtiden bør man kunne trække informationer fra modeller. Generelt skal der ske i større grad af automatisering, hvis man kan fjerne mange af de manuelle arbejdsgange kan man reducere antallet af fejl. Ved at anvende en model kan man koble den til en til en database der kan indeholde informationer om alle de data der er behov for, som D&V, brand og energi. Aarhus arkitekterne I fremtiden vil aflevering forhåbentligt også ske mere automatisk. SA regner dog med at der foreligger et afklaringsarbejde på 5-10 år, hvor der blandt andet skal gøres erfaringer samt arbejdes med ydelsesbeskrivelsen og aftalegrundlaget. 5.2.6 Konsolideret problemstilling for fremtiden: Det er vigtigt, at der skabes erfaringer for, hvordan der skal afleveres digitalt. Det kræver at bygherrer og driftsherrer får øjnene op for fordelene, samt at der udvikles på ydelsesbeskrivelsen og aftalegrundlaget. Det kunne være interessant, hvis afleveringen kunne automatiseres noget mere. Det vil kunne fjerne mange manuelle arbejdsgange og dermed reducere antallet af fejl. 74 Kap: 1-2-3-4-5-6-7-8-9 Analyse 5.3 Analyse af entreprenør Virksomhed/Område Organiseringen MT Højgaard MT Højgaard arbejder som oftest som total- eller hovedentreprenør. Virksomhed/Område Afleveringen MT Højgaard Der udformes en afleveringsmatrice som er en drejebog for hvordan afleveringen skal foregå. Det er vigtigt med en forventningsafstemning med bygherren. Hvis man ved, hvad der er vigtigt for bygherren, så er det nemmere at leve op til dennes forventninger, og dermed opleves sagen positiv for alle parter. Virksomhed/Område Systemer MT Højgaard Der anvendes et excel-ark, hvor der er mange informationer, og det kan blive meget uoverskueligt, men SfB-nr hjælper med, at gøre det overskueligt, da man tvinges til at gennemgå hele byggeriet. Afleveringen af informationer er ikke det, som entreprenørerne har fokus på, de er mere koncentrerede om at bygge. Virksomhed/Område Overførsel af data MT Højgaard Der er stadig byggesager, hvor der afleveres traditionelt på papir, mens der er i andre sager afleveres digitalt på enten cd-rom eller gennem projektweb. I nogle sager anvendes projektweb til tegninger og andre gange også til referater og lignende. Virksomhed/Område Fremtiden MT Højgaard I forhold til MTH så er alle digitale værktøjer, der kan spare tid meget interessante. ”Jo mere digitalt man kan arbejde jo bedre – hvis det er programmer, der virker.” Samlet problemstilling for entreprenøren: Det er vigtigt, at der sker en forventningsafstemning mellem bygherren og entreprenørerne, for at være sikker på at det der leveres, også er det, som der forventes fra bygherrens side, hvilket især kan være en problemstilling i de sager, hvor bygherren ikke har været særlig specifik med kravene til afleveringen. Det kan være uoverskueligt at holde styr på afleveringen, men SfB-klassifikationen hjælper MT Højgaard med at strukturere afleveringen. Entreprenørerne har ikke deres hovedfokus på afleveringen, men på at bygge. 75 5.3.1 Konsolideret flowmodel for afleveringen Figur 35, Konsolideret flowmodel for afleveringen 76 5.3.2 Konsolideret flowmodel for driften Figur 36, Konsolideret flowmodel for driften 77 Analyse Kap: 1-2-3-4-5-6-7-8-9 5.3.3 Konsolideret kulturel model Figur 37, Konsolideret kulturel model 5.3.4 Konsolideret fysisk model Figur 38, Konsolideret fysisk model 78 Kap: 1-2-3-4-5-6-7-8-9 Analyse 5.4 Styring af processen fra Koncept til Aflevering 5.4.1 Organiseringen Som det tydeligt fremgår af empirien, så er der en problemstilling ved organiseringen af byggesagerne i forhold til at kunne stille de rigtige krav til driften. Som figur 35 viser, så er der ofte en adskillelse mellem bygherrefunktionen og driftsherrefunktionen. Dermed er den part, der skal modtage den digitale aflevering, ikke involveret i byggesagen. Det vil alt andet lige gøre, at der er mindre fokus på afleveringen, og at det er sværere at stille konkrete relevante krav. 5.4.2 Kravstilelsen Som det fremgår af de analyserede parter, så er det en generel problemstilling ved at få stillet de rigtige krav til D&V-data. Der er nogle organisationer, der har været i stand til at fremstille en udførlig kravstillelse til den digitale aflevering, her tænkes der på Steen og Strøm og Slots- og Ejendomsstyrelsen, mens andre, som følge af forskellige faktorer, ikke har udført samme udførlige kravstillelse. I alle de undersøgte tilfælde er det et område, der præsenterer en del problemstillinger, som der er behov for en løsning for. Steen og Strøm og Slots- og Ejendomsstyrelsen har som nævnt en udførlig kravstillelse, som de kan anvende på alle projekter, og derved sikre at de modtager de rette data ved afleveringen. Det er dog ikke en garanti for, at afleveringen forløber problemfrit. Det er vigtigt at sikre, at der er en projektleder på projektet, der løbende følger op på arbejdet med den digitale aflevering. I de andre analyserede driftsorganisationer der ikke en generisk kravstillelse for afleveringen af data. Hos Dan-Ejendomme og Teknisk forvaltning, AAU er en af faktorerne for den manglende kravstillelse, at der er en organisatorisk opdeling mellem driftsherren og bygherren. Der skaber en udfordring for de to organisationer i at stille krav til afleveringen. Der er selvfølgelig en bygherre på byggesagen, men kløften mellem bygherre og driftsherre gør, at der ikke er den sparring om kravstillelsen, som der måske ville være internt i en organisation. I Teknisk Forvaltnings tilfælde driver de, de bygninger som universitetet lejer af Universitets- og bygningsstyrelsen, UBST, mens Danejendomme forvalter ejendomsporteføljer for andre virksomheder. Skanska er et udviklingsfirma. De bygger dermed ikke for at eje men for at sælge. Det er derfor sjældent, at den langsigtede driftsherre er involveret i kravstillelsen. Der er på denne baggrund behov for en generisk kravstillelse, der hjælper bygherren med at stille krav til den digitale aflevering i de tilfælde, hvor der ikke er involveret en driftsherre i projektet. Det kunne sikre at driftsherren bliver tilgodeset, selvom denne ikke er direkte involveret i byggesagen fra projektstart. 5.4.3 Styring af afleveringen gennem projektet Der er et behov for at kunne styre afleveringsprocessen gennem hele projektet. Den indledende kravstillelse er en god begyndelse til at sikre den gode aflevering, men for at sikre at afleveringen forløber, som tiltænkt, er der et behov for, at afleveringen også styres gennem byggesagen. Flere af de interviewede driftsherrer nævner, at rådgiverne og entreprenørerne har større fokus på at designe og bygge end at aflevere informationer om byggeriet. Det er der i sig selv ikke problematisk, da det er deres hovedopgave i byggesagen, men det betyder også at bygherren har en opgave med at sikre, at der også holdes fokus på afleveringen. 79 Analyse Kap: 1-2-3-4-5-6-7-8-9 Fra de interviews, der er foretaget, fremgår det, at det dog er de færreste bygherrer, der er i stand til dette. Det kan derfor være en god idé at udpege en person, der ansvarlig for dette. Hvis bygherren i sin egen organisation ikke har en person, der har kompetencerne til at udføre denne opgave, kan det være en opgave, der kan løses af bygherrerådgiveren eller en af de andre rådgivere i projektet. En af de problemstillinger, som der er i forbindelse med styringen af D&V-data gennem byggesagen, er, at bygningsdelene indtil licitationen ikke specificeret, som vist på figur 39. Det kan derfor være svært at beskrive D&V-informationerne for rådgiverne, da det de kan bestemme er kravene til D&V, mens entreprenørerne kan vælge produkter med lignende egenskaber, som dem der først var tiltænkt af rådgiverne. Figur 39, Overgang fra generiske beskrivelser og bygningsdele til produktspecifikke bygningsdele, egen tilvirkning 5.4.4 Informationsflow mellem aktører Den traditionelle processtyring af byggesager præsenterer en række udfordringer for at kunne sikre, at byggeriets parter effektivt kan udveksle informationer mellem hinanden. For det første er der ikke den nødvendige fokus på afleveringen af D&V-informationer til bygherren indenfor byggeriet. Det er en del som der traditionelt ikke er så stor fokus på som de andre dele af byggesagen. For det andet er der sker meget af informationsudveksling gennem mail hvilket spreder informationen ud i mange filer. Der er behov for, at der skabes en tradition for, hvordan der skal arbejdes med den digitale aflevering, således at de korrekte relevante informationer kan afleveres til driftsherren. Der er i kapitel 6, ”Løsningsforslag”, udformet et forslag til, hvordan informationsflowet kan styres. 80 Analyse Kap: 1-2-3-4-5-6-7-8-9 5.4.5 Vigtigheden af det samme projektweb Der er et generelt problem ved informationshåndteringen danske byggesager. Der er ofte redundans mellem den lokale database for de enkelte parter involveret i byggesagen, og det fælles projektweb der anvendes til i byggesagen. Dermed er der fare for, at det ikke er de relevante data, der findes på projektweb, men dette kan dog styres, hvis der fokus på det fra parternes side. I den konkrete sag, Odense City Center, var det fra starten planlagt, at der skulle anvendes byggeweb som projektweb. Dette er på mange måder meget naturligt, da Steen og Strøm har et tæt samarbejde med Byggeweb omkring CoreFM. Da der blev stillet krav om digital aflevering af informationer om byggeriet, blev firmaet Byggeweb involveret i byggesagen som konsulenter for at støtte med råd omkring den digitale aflevering. Rådgiverne mener dog ikke at byggeweb har leveret den nødvendige bistand i forbindelse med opstarten af byggesagen. Derfor er det besluttet at anvende et andet projektweb, der hedder IntraByg, for at komme i gang med projektet efter tidsplanen. Figur 40, Eksempel på skiftende brug af databaser, egen tilvirkning Dette valg præsenterer dog en del problemer, da det er besluttet at hele byggesagen skal forløbe digitalt. Det andet projektweb kan ikke foretage digital licitation, og derfor er der behov for, at der på et tidspunkt er behov for, at der anvendes byggeweb igen senere i projektet. Det er illustreret i figur 40, hvordan der anvendes forskellige databaser gennem et projekt. Problemet med de skiftende databaser er, at hver gang der skiftes database, er der noget metadata, der går tabt. I denne sag vil valget tilmed betyde, at der sand- 81 Analyse Kap: 1-2-3-4-5-6-7-8-9 synligvis skal arbejdes på IntraByg til at starte med, hvorefter projektet downloades til en lokal server og derefter oploades til byggeweb. Det er problematisk i forhold til at bevare en systematik i projektmaterialet, da der ved hver flytning af projektmaterialet sker et tab af metadata. Ved store byggesager som OCC er vigtigt at kunne bevare strukturen i projektmaterialet. For hvis der først kommer uorden i strukturen af data, kan det føre til stor forvirring blandt de involverede parter. Dette er både afgørende for byggesagen, og for det materiale der skal afleveres til driften. 5.4.6 Format Det er på mange måder mest formatet, der har været fokuseret på fra byggebranchens side. I IKTbekendtgørelsen er der præsenteret forskellige formater, som informationerne til driftsherren kan afleveres i. Det interessante i forhold til formatet af informationer er, at sikre at informationerne bliver gjort tilgængelige for alle parterne i byggeriet. Til dette nævnes IFC ofte, som det format, der binder byggeriet sammen (Bips, 2007) IFC er et centralt format i forhold til at kunne udveksle modelbaseret information mellem byggeriets parter, men der er behov for at kunne supplere IFC-formatet med andre åbne formater, der kan indeholde den information, som IFC ikke kan. 5.4.7 Klassifikation Klassifikationen er vigtig for at kunne strukturere informationerne, således at driftsherren kan anvende informationerne uden at skulle igennem en større bearbejdning af projektmaterialet. Det offentlige forsøger i stor grad at fremme brugen af DBK som klassifikation i den danske byggebranche. Brugen af DBK har været et stort diskussionsemne herhjemme i forbindelse med Det Digitale Byggeri. Der er mange, der mener, at det er et projekt, der unødvendig da der allerede findes klassifikationer der kan anvendes, dertil er der også nogle der mener at ubrugelig da ”del af”-strukturen ikke er anvendelig som klassifikation. (Jørgensen, 2011) Der er flere steder, hvor DBK bliver anvendt, da der stilles krav om det. Andre steder bliver det implementeret, fordi det betragtes, som en del af fremtiden i byggebranchen, og at den derfor med fordel allerede tages i brug nu. Der er dog også en del aktører, som holder fast SfB-klassifikationen. Det sker måske ikke ud fra den betragtning, at den er perfekt, men at DBK ikke er bedre, og at der derfor ikke er nogen grund til at skifte. Fx anvender MT Højgaard SfB-systemet i stedet for DBK og mener, at det dækker deres behov til en klassifikation. Der er ved de interviewede driftsherrer ligeledes sat spørgsmålstegn ved fremtiden for DBK. Der er en vis utilfredshed med, at så mange af ressourcerne i Det Digital Byggeri er gået til udviklingen af en ny standard, når der er så mange andre standarder, der kunne bruges, og der er så mange andre områder indenfor Det Digitale Byggeri, der mangler at blive behandlet. Det vigtige i byggesager er dog at sørge for, at der anvendes en klassifikation. Alternativet er at der er for stor usikkerhed om navngivningen og struktureringen af bygningsdelene. 82 Analyse Kap: 1-2-3-4-5-6-7-8-9 5.4.8 Kontrol af model/arbejde I byggesager, hvor der arbejdes med BIM, er der store muligheder for at anvende digitale bygningsmodeller til at udføre analyser og beregninger. For at anskueliggøre hvilke konsekvenser de beslutninger der foretages i byggesagen, har for den efterfølgende drift af byggeriet, er det oplagt også at anvende de digitale bygningsmodeller til at analysere på driften af bygningen. Det der ofte analyseres på områder som varmetab, lydforhold og brand, men omkostningerne af den almindelige drift og vedligehold er ofte ikke et område som der analyseres på. Det er denne rapports opfattelse, at der er en potentiel værdi for driften ved at udføre analyser af driftsbudgettet for bygningen, hvilket behandles videre i kapitel 6.3.5. 5.4.9 Afleveringen Afleveringen er præget af meget manuelt arbejde. Selvom der har været initiativer til at gøre afleveringen mere digital, fx fra Det Digitale Byggeri, så er de anvendte metoder i byggebranchen stadig præget af mange manuelle processer. Derfor er der stadig et stort potentiale for at kunne optimere denne del af byggeriet. I den foregående IKT-bekendtgørelse 6 var der tre metoder for den digitale aflevering: i en digital bygningsmodel baseret på DBK og åbne standarder som IFC, i DDB-XML eller ved direkte indtastning i driftsherrens CAFM-system. I den nyeste IKT-bekendtgørelse 7 er metoden med aflevering i XML dog udeladt, da det har vist sig at det ikke er en metode, der er blevet anvendt. I stedet kan der afleveres i: en bygningsmodel baseret på DBK og åbne standarder (som IFC), redigerbare, digitale dokumenter eller ved direkte indtastning i driftsherrens CAFM-system. Metoden med aflevering i XML var interessant, da data i XML nemt kunne overføres til driften, men rent teknisk var det svært for byggeriets parter at forstå denne metode. Det er ofte et format, der anvendes af dissideret IT-personel, mens de andre metoder er tilgængelige for flere aktører i byggebranchen. Afleveringen af dokumenter og indtastning i CAFM-systemet er forholdsvist lavpraktiske løsninger, som ikke kræver de store kompetencer fra de involverede parter, dog kan indtastningen i CAFM-systemet være en udfordring for de aktører, der arbejder meget lidt med IT-værktøjer til dagligt. Fremtiden indenfor digital aflevering er dog aflevering af digitale bygningsmodeller, hvis der tages udgangspunkt i IKT-bekendtgørelsen. Efter planen skal al aflevering efter den 1. januar 2014 foregå i digitale bygningsmodeller for alle statslige byggerier. Det er planen at alle offentlige byggerier til den tid også skal omfattes af IKT-bekendtgørelsen. Der er derfor interessant at undersøge hvordan afleveringen af digitale bygningsmodeller kan foregå. Der er i Kapitel 6, ”Løsningsforslag, givet et forslag til, hvordan denne aflevering kan foregå. 6 7 Bekendtgørelse 1365 Bekendtgørelse 1381 83 Kap: 1-2-3-4-5-6-7-8-9 Analyse 5.5 Analyse af driften og CAFM-systemer Indledning For at finde frem hvordan den digitale aflevering skal forløbe, er det vigtigt at undersøge de CAFM-systemer der skal modtage informationerne fra byggeprojektet. Der er udvalgt tre CAFM-systemer til at repræsentere markedet: CoreFM, LogFM og ArchiBUS. 5.5.1 Test af CAFM-systemer Import af data CoreFM LogFM ArchiBUS Direkte indtastning for entreprenører + +/- + Import af data fra excel + + + Import af data fra database som acces o.l. + + + Import af data gennem model - - +/- LogFM: Metoden med direkte indtastning har indtil videre ikke været anvendt, men Teknisk Forvaltning har planer om at forsøge de i kommende projekter. Teknisk set burde det være nemt at gennemføre. ArchiBUS: Det er ikke muligt at importere hele modeller i ArchiBUS, men der er en integration til Revit, hvor rim, inventar og udstyr kan udveksles. Håndtering af D&V-data CoreFM LogFM ArchiBUS Overskuelighed + + + Planlægning af opgaver + + + Kommunikation af opgaver til håndværkere + + + Indrapportering af evt fejl og mangler - - + 84 Kap: 1-2-3-4-5-6-7-8-9 Analyse Håndtering af Arealer CoreFM LogFM ArchiBUS Registrering af arealer + + + Registrering af inventar og udstyr + + + Udlejning/brug af lokaler - +/- + Brug af arealer til udbud - - + LogFM: I LogFM foregår noget af håndteringen kommunikationen af arealerne gennem den webbaserede applikation, Navigator, men selve registreringen af arealerne findes i LogFM. Sammenstilling af informationer CoreFM LogFM ArchiBUS Udformning af budgetter - + + Nøgletal for bygningen/porteføljen + + + Energi og forbrug CoreFM LogFM ArchiBUS Overblik over forbrug + + + Specificering forbrug på afdelinger, rum, personer + +/- + Kobling mellem CAFM og CTS +/- - + Mulighed for fremtidig analyse - - - CoreFM: CoreFM kan ikke på nuværende tidspunkt kobles med CTS systemer, men CoreFM mener at der kan oprettes et link til en database med CTS-data. LogFM: Der er planer om at specificere forbruget for institutterne på Aalborg Universitet over de kommende år, hvilket skal styres i LogFM. 85 Analyse Kap: 1-2-3-4-5-6-7-8-9 5.5.2 Test af CoreFM Testen af CoreFM er foretaget med en prøvelicens, der er stillet til rådighed af CoreFM. Forfatteren har dermed haft lejlighed til selv at afprøve systemet. Dertil har CoreFM deltaget ved at svare på spørgsmål om systemet. Import af data: Importen af D&V-data til CoreFM sker typisk ved indtastning i system, enten direkte af entreprenørerne eller med support fra CoreFM. Det er CoreFM’s opfattelse, at indtastningen er den bedste måde at inddrage entreprenørerne i afleveringsprocessen. CoreFM mener, at mange entreprenører ikke har samme fokus på at aflevere D&V-information, og derfor er det vigtigt, at det er en proces, der styres af bygherren eller dennes rådgivere for at sikre, at de rette informationer bliver afleveret til driften. Det, der skal afleveres til CoreFM, er ikke KS, as-built materiale eller lign. Det er D&V-data, der er vigtigt at modtage fra entreprenørerne. CoreFM mener, at det er informationer, der er problematiske at aflevere i IFC, da det typisk er rådgiverne, der står for modellen, og der derved kan blive uklarhed om ansvarsfordelingen. Det er derfor planen, at CoreFM også i fremtiden skal modtage data ved direkte indtastning af entreprenørerne. Der er mulighed for at importere XML-filer til CoreFM, hvis dette varetages af CoreFM’s supportafdeling. Figur 41, Overblik over typer af D&V i CoreFM, screenshot fra test af CoreFM. 86 Analyse Kap: 1-2-3-4-5-6-7-8-9 Håndtering af D&V-data: Der kan laves planer for D&V af bygninger gennem CoreFM, på baggrund af de oplysninger som er overført fra byggeprojektet. Systemet giver et godt overblik, over de opgaver der foreligger i forbindelse med D&V fordelt på forskellige typer af aktiviteter. Som figur 41 viser, så opdeles D&V-opgaverne i på forskellige typer af aktiviteter. En god funktion i modulet er, at der vises, hvis der er opgaver, der skal behandles (de røde tal ud fra hver type aktivitet). Håndtering af arealer: CoreFM blev oprindeligt udviklet for at kunne håndtere arealer, og arealmodulet er stadig en central del af systemet under navnet porteføjle. Koblingen mellem arealerne i byggeprojektet og CoreFM kan foregå ved at importere tegninger i dwg-formatet. Først skal tegningerne dog bearbejdes i AutoCAD, som CoreFM har udviklet et plug-in til. Alle rum skal tegnes op med lukkede polygoner, som tegnes ovenpå den eksisterende tegning. Polygonerne bruges til at registrere arealerne i CoreFM, mens den underliggende tegning også importeres med i CoreFM, og anvendes som en grafisk understøttelse af arealoversigten. I CoreFM anvendes de importerede polygoner til at bestemme arealerne fordelt på etager, bygninger, adresser og porteføljer. Figur 42, Visning af tegning i CoreFM, screenshot fra test af CoreFM. 87 Analyse Kap: 1-2-3-4-5-6-7-8-9 Sammenstilling af informationer: Der er mulighed for at producere rapporter over alle de informationer, der ligger i CoreFM. Da systemet er databasebaseret, er der en forholdsvis stor mulighed for at opstille de rapporter, som der behov for. Som figur 43 viser, er der mange muligheder for at opstille rapporter ud fra definerede skabeloner, hvilket giver mulighed for at anvende disse data i andre sammenhænge. Figur 43, Oversigt over rapporttyper i CoreFM, screenshot fra test af CoreFM. Energi: CoreFM giver mulighed for at indsamle informationer om bygningers energiforbrug (se figur 43), og derved sammenligne dem for at kunne optimere forbruget i porteføljen. Informationerne om energiforbrug ligger under økonomi, ligesom der kan registreres andre typer af forbrug i systemet. Der er ikke en direkte kobling til de enkelte målere i bygningen, men det skulle være muligt at hente informationerne et CTS-system eller en database. CoreFM udtaler dog, at det ikke er deres forretningsområde at konkurrere med CTS udbyderne eller overtage selve styringen af systemerne i bygningen. 88 Analyse Kap: 1-2-3-4-5-6-7-8-9 5.5.3 Test af LogFM Testen af LogFM er foretaget i samarbejde med Teknisk Forvaltning på Aalborg Universitet. Det har ikke været muligt at afprøve systemet ”hands-on”, men Teknisk Forvaltning har stillet sig til rådighed i form af en gennemgang af systemet. Ved gennemgangen deltog Rasmus Wernlund og Lone Bruhn fra Teknisk forvaltning. Selve testen foregik ved at Teknisk Forvaltning gennemgik LogFM ud fra de krav til funktionaliteter, som der er opstillet til i denne rapport. Dertil har Leif Linding Nielsen som er systemudvikler for LogFM bidraget med oplysninger om datastrukturen i systemet. Import af data: LogFM bygger på en datastruktur i en sql-database. Der er derfor mulighed for at importere data fra XLS, XML eller andre database strukturer. Det der er vigtigt er, at de modtagne data er struktureret korrekt, og at der ikke for mange informationer med i datamodellen. Det er ikke et spørgsmål om at få så mange data med som muligt, men de data der er valide. På nuværende tidspunkt importeres informationer ved at teknisk forvaltning modtager D&V materiale fra entreprenører i fx excel-skemaer og taster det ind i LogFM. Det skyldes, som det også fremgår af interviewet i bilag 11.1, at Teknisk forvaltning selv vil vurdere om levetidsvurderinger og lign. er realistiske. Dermed anvendes der kun metoden for aflevering af redigerbare, digitale dokumeter, af de metoder som er fremsat i IKT-bekendtgørelsen. TF arbejder dog med at kunne give entreprenører adgang til indtastning i LogFM. Udover informationerne om D&V afleveres der også tegninger eller modeller, hvis de er anvendt i projektet. Her lægger TF vægt på at der ikke kun afleveres en IFC-model. De vil også modtage den proprietære model, så der er mulighed for at kunne arbejde videre ved senere projekter. I forhold til de fremtidige krav om aflevering i IFC ser TF nogle udfordringer i forhold til at få alle informationer om fx D&V med i IFC-modellen. Som formatet er nu, er der for mangler i forhold properties for de enkelte bygningsdele. Det er en del af IFC, som mangler at blive udviklet på, før at TF tror på, at der kan afleveres i IFC alene. Håndtering af D&V-data: I LogFM oprettes der bygningsdelkort for fx vinduer på baggrund af de informationer, der leveres af entreprenøren ved afleveringen. Ved oprettelsen i LogFM fastlægges det også, med hvilke intervaller at bygningsdelene skal vedligeholdes (se figur 44). Det kan enten ske ud fra entreprenøren anbefalinger, men ofte sker det ud fra Teknisk Forvaltnings erfaringer med bestemte bygningsdele. Fra modulet for D&V kan opgaverne overføres til økonomimodulet, hvor opgaverne samles i aktiviteter. Det er også her, at det kan planlægges, hvordan opgaverne kan prioriteres i forhold til budgettet. De opgaver der ikke er råd til i det indeværende år kan udskydes ud fra prioriteringerne. Det er muligt at se, hvor meget der er budgetteret for planlagt vedligehold for de kommende år. 89 Analyse Kap: 1-2-3-4-5-6-7-8-9 Planlægningen af vedligehold virker godt, men teknisk forvaltning kunne godt tænke sig, at det var muligt, at se hvor meget der er brugt i forhold til budgettet og i det hele taget have en større udspecificering af økonomien for vedligehold. I forhold til det indvendige vedligehold så arbejder teknisk forvaltning med en cyklus, hvor et område med bygninger deles ind efter en 8-årig periode. Derefter sker der en typeinddeling af bygningerne i afsnit og rum. Planlægning af dette vedligehold skal dog justeres løbende, da der kan komme flytninger og lignende, der kræver at en bygning sættes i stand. Det lovpligtige vedligehold kan også styre i modulet. Det ligger som faste opgaver, som skal udføres, men det er en stor hjælp at kunne få overblik i LogFM. Figur 44, Overblik over planlagt vedligehold i LogFM, screenshot fra Teknisk Forvaltnings præsentation af LogFM Teknisk Forvaltning nævner, at de godt kunne ønske sig at der var en grafisk visning af planlægningen af vedligehold. Som det er nu, anvendes der printede tegninger til at lave farvekoder på. Dette kunne optimeres ved at have digitale tegninger, der synkroniserede med LogFM. Håndtering af arealer: I modulet for håndtering af arealer er der en registrering af alle arealer, som teknisk forvaltning administrerer. Det er dog forskelligt, hvor mange informationer der ligger på de enkelte bygninger, alt efter om det er bygninger, som ejes af UBST, eller det er bygninger, der lejes ”ude i byen”. 90 Analyse Kap: 1-2-3-4-5-6-7-8-9 Generelt findes der informationer om blandt andet placering af arealer, type af rum, størrelse af rum, og hvem der lejer det. Det giver mulighed filtrering af informationerne, således at der kan udformes mange forskellige opgørelser af arealerne. Figur 45, Filtrering af arealinformationer med mulighed for eksport til AutoCAD og excel, screenshot fra Teknisk Forvaltnings præsentation af LogFM Figur 46, Overblik over arealer i Navigator, screenshot fra Teknisk Forvaltnings præsentation af LogFM 91 Analyse Kap: 1-2-3-4-5-6-7-8-9 Teknisk Forvaltning anvender en webbaseret applikation, der hedder navigator til at kommunikere med institutterne omkring arealer. Her kan hvert institut nemt få overblik over hvilke arealer de lejer og lign. (se figur 45) Sammenstilling af informationer: LogFM bygger på en database, og det er dermed muligt at sammenstille informationer på mange måder. I LogFM er der rig mulighed for at anvende filtreringer i alle moduler, hvilket giver teknisk forvaltning rig mulighed for at tilgå præcis de informationer, der er behov for. På figur 45 er det vist, hvordan det er muligt at filtrere i LogFM. Denne funktion er til stede i alle skemavisninger af data, og giver en stor fleksibilitet i at kunne vise præcis de data der er relevante. Filtreringsfunktionen er forholdsvis omfattende i LogFM, hvilket er driftsorganisationen stor mulighed for at anvende data herfra i andre sammenhænge, fx i business cases. Energi: Der er i øjeblikket ikke nogen kontrol med forbruget for de enkelte fakulteter og institutter på Aalborg Universitet. I stedet fordeles det samlede forbrug ud på det samlede antal kvadratmeter og lægges ind i huslejen. Aalborg Universitet har dog en målsætning om at energiforbruget skal reduceres over de kommende år og derfor vil der i den kommende fremtid komme målinger på de enkelte institutter således at det er muligt at kontrollere det konkrete forbrug og dermed give institutterne større incitament for at reducere deres forbrug. 92 Analyse Kap: 1-2-3-4-5-6-7-8-9 5.5.4 Test af ArchiBUS Testen af ArchiBUS er foretaget på InformiGIS kontor i Charlottenlund. InformiGIS er softwareleverandør af forskellige produkter, bl.a. GIS-produkter. Firmaet har stillet en arbejdsstation med ArchiBUS installeret til rådighed for denne rapport, hvilket gav mulighed for at kunne teste ArchiBUS personligt. Der er muligt at arbejde med ArchiBUS i forskellige typer af applikationer: • • Web central: Webbaseret applikation til ArchiBUS som er tilgængelig gennem en browser. Smart-client: Lokal applikation hvor det er muligt at lave de lidt større ændringer i databasen, som integration med CAD/revit. Import af data: ArchiBUS har forskellige muligheder for at kunne importere data. InformiGIS fortæller, at de ofte hjælper deres kunder med at overføre data til ArchiBUS. Der er for så vidt ikke nogen begrænsninger, for hvilket format informationerne ligger i, så længe det er i skemaform. Dermed kan informationerne overføres til den database, som ArchiBUS bygger på. ArchiBUS har reklameret med at systemet kan integreres med Revit, hvilket er interessant i forhold til at kunne knytte byggeprojekt og driften sammen. Det, som ArchiBUS kan, er dog ikke at importere hele modellen, men at overføre imformationer om rum, inventar og udstyr mellem de to systemer, som det er vist på figur 47. Figur 47, Det er muligt at integrere rum, inventar og udstyr mellem revit og ArchiBUS, screenshot fra test af ArchiBUS. 93 Analyse Kap: 1-2-3-4-5-6-7-8-9 Integrationen fungerer bi-direktionelt, således at ændringer der foretages i det ene system opdateres i det andet. Dermed sikres det, at projektmaterialet altid er opdateret på samme niveau som CAFM-systemet. Integrationen omhandler: • • • Rum (Room nr, Room standard/category/type, room area, space allocation), Udstyr/equipment (Asset ID, Eq. Standard, Eq. Location), og møblering (F. ID, F Standard, F. location). Det kan også vælges at integrere med AutoCAD, men her er det kun tegninger, der udveksles. Fra InformiGIS’s side fremhæver de fordelen ved at kunne se den præcise placering af udstyr på plantegninger. Håndtering af D&V-data: I ArchiBUS er der rig mulighed for at kunne udforme D&V-planer for bygninger. Det kan udformes, ikke kun for bygningsdele, men også for udstyr og andre objekter i bygningen. På figur 48 er det vist, hvordan der oprettes en plan for vedligeholdelse af hver bygningsdel. Figur 48, Der kan udformes vedligeholdelsesplaner for alle bygningsdele og udstyr i bygningen, screenshot fra test af ArchiBUS. På baggrund af disse planer kan der udformes en tidsplan, hvor der indsættes afhængigheder mellem objekterne, således at de vedligeholdes ud fra en hensigtsmæssig samling af aktiviteter. 94 Analyse Kap: 1-2-3-4-5-6-7-8-9 ArchiBUS har også et modul, der hedder ServiceDesk, som gør det muligt at automatisere af arbejdsrequests. Det er muligt at oprette typer af opgaver fra managerens side, og den enkelte klient/bruger kan derefter vælge at lave en request på en type opgave, som manageren så godkender (se figur 49). Rollerne kan forklares således: • • Manageren: Opretter typer af opgaver. Definere hvilke informationer, der skal udfyldes af klienten. Godkender den request, som klienten laver. Klienten: Opretter en request på en opgave, alt efter hvilken type det er. Udførlig lokalisering. Typen af problem (elpære, rengøring, døre, ol.) På den måde bliver CAFM-systemet tilgængeligt for de enkelte interessenter, og kommunikationsvejene bliver kortere ved svigt i bygningen. Figur 49, Det er muligt at give adgang til interessenter for at lave servicerequests i ArchiBUS, screenshot fra test af ArchiBUS. Håndtering af arealer: Håndtering af arealer fordeler sig på to moduler i ArchiBUS: ”Property and lease management” og ”Space management”. I det første af de to er det muligt for driftsherren at få overblik over de bygninger, som han administrerer. Dertil er der her en samlet registrering af bygninger, rum, arealer, lejekontrakter mv. Fra dette modul er det ligeledes muligt at se udgifterne i forbindelse med de enkelte bygninger samt oversigt over kostpriser af bygninger og kontrakter for lejemål. På figur 50 er der vist, hvordan det er muligt at overskue en hel portefølje på en gang. I den konkrete visning kan driftsherren blandt andet se værdien af byg- 95 Analyse Kap: 1-2-3-4-5-6-7-8-9 ningerne, om det er nogle han selv ejer, eller om de er lejet, og hvor langt tid der er tilbage af lejekontrakterne. Der er dermed en udførlig oversigt, over hvilke udgifter de knytter sig til de enkelte lejemål, og dermed bliver det lettere at bestemme huslejen for lejemålene. Dette gælder både i forhold til de administrerede bygninger, men det er også muligt at kortlægge ressourceforbruget for de enkelte afdelinger. ArchiBUS er ikke ment som et økonomisystem, men som en måde at styre og skabe overblik over økonomi. Regninger og fakturaer skal stadig administreres af økonomiafdelingen. Figur 50, Portefølje management, screenshot fra test af ArchiBUS. I modulet ”Space management” er det nemt at danne sig et overblik, over hvor de enkelte afdelinger sidder henne. Der er også rig mulighed for at kunne styre placeringen af afdelinger og grupper og dermed optimere brugen af bygningerne og arbejdsgangene i afdelingerne. På figur 51 er det vist, hvordan ArchiBUS kan give en grafisk visning af de enkelte afdelinger på bygninger og etager. Som det er vist på figur 52 er det ligeledes muligt at få vist placeringen af enkelte personer i bygningen. Dette åbner op for en større udnyttelse af bygningerne, da det er muligt hurtigt at få vist hvilke rum, der er ledige i en bygning og tilføje nye personer til rummene. Generelt er der en stor mulighed i ArchiBUS, for at løse de problemstillinger mange bygningsejere har med at overskue deres bygninger og udnytte dem optimalt. 96 Analyse Kap: 1-2-3-4-5-6-7-8-9 Figur 51, grafisk visning af placering af afdelinger, screenshot fra test af ArchiBUS. Figur 52, grafisk visning af placeringen af enkeltpersoner, screenshot fra test af ArchiBUS. 97 Analyse Kap: 1-2-3-4-5-6-7-8-9 Sammenstilling af informationer: Der er rig mulighed for at kunne udforme rapporter i ArchiBUS. Systemet bygger, som de andre testede systemer, på en database, og dermed kan informationerne anvendes til udforme rapporter. Når det er sagt virker ArchiBUS til at kunne udføre forholdsvis mange typer af rapporter og understøtte dem med forskellige former for grafiske visninger, som fx diagrammet i figur 51. Denne del af systemet er vigtigt for at kunne kommunikere med interessenterne i bygningerne, der ikke har adgang til ArchiBUS, men også for at kunne give driftspersonellet større overblik. Energi: Det er muligt at koble CTS-systemer og ArchiBUS sammen, således at ArchiBUS udnytter data fra CTSsystemerne til at kunne analysere ressourceforbruget for porteføljen og de enkelte bygninger. Det giver en mulighed for at være proaktiv i forhold til energiforbruget, i stedet for at være reaktiv. Der er også mulighed for at kunne koble forbruget til de enkelte lejere, og dermed udforme regninger til de relevante lejere. Generelt er der en omfattende mulighed for styring af regninger i forhold til typer, lejemål og kalender. ArchiBUS kan udover at koble til CTS-systemer også kobles til vejrstationer og dermed kan der analyseres forbruget i forhold til vejret og det er muligt at være proaktiv i forhold til kommende vejrsituationer. Figur 53, Integration mellem ArchiBUS og vejrstationer, screenshot fra test af ArchiBUS foretaget af forfatteren. 98 Kap: 1-2-3-4-5-6-7-8-9 Løsningsforslag 6 Løsningsforslag I det følgende afsnit er der givet et løsningsforslag til, hvordan det er muligt at løse de udfordringer, som der er kortlagt i analysen i kapitel 5. I dette kapitel er der anvendt metoderne: Work redesign og User Enviroment Design fra Contextual Design. 6.1 Introduktion til løsningsforslag Løsningsforslaget er bygget op omkring modellen i figur 54. Det er rapportens intention at beskrive de centrale dele af processen omkring digital aflevering. Kravstillelsen er beskrevet i kapitel 3.26, hvor der fokuseres på hvordan det rigtige aftalegrundlag der sikrer at afleveringen af information udformes. Kravstillelse D&V gennem byggesagen Aflevering Drift Figur 54, Procesmodel over byggeriets faser i forhold til D&V 6.1.1 Informationsflow mellem aktører En vigtig faktor for et bedre informationsflow mellem de involverede aktører i en byggesag er at der udformes et fælles grundlag for hvordan afleveringen skal forløbe gennem et byggeprojekt. Her er IDM fra BuildingSMART et vigtigt redskab til at kunne beskrive det generelle udvekslinger der sker i byggeriet. Der er allerede blevet udviklet nogle få IDM’er for byggebranchen, som koncentrerer sig om udvekslinger i projekteringen og udførelse. Det er behov for at der skabes en tradition for at hvordan afleveringen skal forløbe. Traditioner starter med at der er nogen der handler og vise en ny retning. Det er ved at ske i branchen hvor bygherreforeningen og flere af de store driftsherrer kræver at det digitale byggeri i større grad beskæftiger sig med driften af bygninger. Der er derfor udformet et BPMN-diagram 8, der skal beskrive udvekslingen i forbindelse med afleveringen af D&V-data til driftsherren (se figur 55). Diagrammet er med til at beskrive de udvekslinger, der skal foretages mellem parterne gennem en byggesag. 8 Business Process Modeling Notation 99 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 1.1 Første proces er at udforme en generel kravspecifikation, der beskriver bygherrens krav og behov til aflevering af data fra byggeprojekt til driften. 1.2 Anden proces er at udforme de projektspecifikke krav, som udformes til det konkrete projekt. I dette proceskort udformes det af bygherrerådgiveren og sendes til bygherren for godkendelse. 1.3 Tredje proces er at vurdere de projektspecifikke krav, som bygherrerådgiveren har udformet for den konkrete byggesag. 1.4 Fjerde proces er, at rådgiverne udformer projektmaterialet for byggesagen. 1.5 Femte proces er, at rådgiverne skal udarbejde en bygningsmodel og en database for D&V og andre FM-data på baggrund af kravspecifikationen 1.6 Sjette proces er, at bygherrerådgiveren skal vurdere og godkende databasen for D&V og andre FM-data, der er udformet af rådgiverne. 1.7 Syvende proces er, at der startes på byggeperioden. 1.8 & 1.10 Ottende og tiende proces er, at der skal findes de informationer, der er stillet krav til i forhold til afleveringen. 1.9 & 1.11 Niende og elvte proces er at informationerne skal indtastes i den afleveringsmetode der er valgt. Såfremt underentreprenøren ikke har kompetencerne til at foretage afleveringen, kan hovedentreprenøren modtages informationerne på anden måde og gøre det for ham. 1.12 Tolvte proces er at informationerne afleveres i henhold til kravene. 1.13 Trettende proces er at det afleverede materiale skal vurderes i forhold til kravstillelsen. Hvis materialet ikke opfylder kravene bedes entreprenøren om at rette manglerne. 1.14 Fjortende proces er at opdaterer strukturen og retter mindre fejl i databasen. 1.15 Femtende proces er at driftsherren modtager materialet og importere det til dennes CAFMsystem. Diagrammet beskriver de processer der skal gennemføres for at kunne styre den digitale aflevering fra starten af byggesagen til starten på driften. Processerne i BPMN-diagrammet kan samles i fire centrale emner: Kravstillelsen (proces 1.1-1.3), styring af afleveringen gennem byggesagen (proces 1.4-1.6), afleveringen (proces 1.7-1.13) og driften (proces 1.14 (og frem)). De fire emner er behandlet i de efterfølgende kapitler, hvor der gives forslag til hvordan de kan styres gennem byggesagen. 100 6.1.2 BPMN-diagram over informationsflowet Figur 55, BPMN-diagram for styringen af den digitale aflevering. 101 Løsningsforslag 6.2 Kap: 1-2-3-4-5-6-7-8-9 Kravstillelsen Kravstillelsen er grundlaget for det efterfølgende arbejde, og derfor er det utroligt vigtig at sikre, at de rigtige krav stilles. Der er i løsningsforslaget fokuseret på tre områder, som tilsammen udgør den gode kravstillelsen: • • • et aftalegrundlag som sikrer de ydre rammer for arbejdet med afleveringen værktøjer til at udforme og kontrollere krav selve kravene til den digitale aflevering 6.2.1 Udformning af aftalegrundlaget for den digitale aflevering I sager, hvor der ikke er en almen beskrivelse af hvilke krav, der er til den digitale aflevering, anbefales det at anvende et værktøj, der sikrer, at der tages hensyn til denne del af byggesagen. Kravkonfiguratoren som er udviklet af bygherreforeningen kan hjælpe med at sikre, at der stilles de rette krav til driften. Der er i forbindelse med rapporten udformet en aftale i Kravkonfiguratoren. Kravkonfiguratoren er udformet som en hjemmeside, som kan findes på www.driftsdata.dk. Som det er nævnt tidligere i rapporten, er Kravkonfiguratoren en standardaftale for afleveringen, som kan bearbejdes gennem hjemmesiden og eksporteres til en tekstbehandlingsapplikation. Indholdet i aftalen er: 1. 2. 3. 4. 5. Parter: Hvor de involverede parter defineres Generelle bestemmelser: Her defineres de generelle bestemmelser for den digitale aflevering. Levering Terminer for levering Begreber og definitioner Der er udformet en standardtekst for hvert afsnit, som figur 56 viser, der kan anvendes generelt for projekter, mens der er fast definerede punkter, som der skal tages stilling til i hvert projekt. Det er en struktur, som minder meget om strukturen i fx ABR89. Det er forholdsvist nemt at arbejde i Kravkonfiguratoren. Den lineære struktur i aftalen sikrer, at alle punkter behandles i den rigtige rækkefølge. Det gælder i øvrigt som i de andre standardaftaler, at det ikke anbefales at ændre i standardteksten, med mindre at det er nødvendigt. 102 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 Figur 56, Eksempel på udformning af aftale for aflevering, screenshot fra udformning af aftale for aflevering foretaget af forfatteren i Kravkonfiguratoren. Kravkonfiguratoren kan løse nogle af de problemer, der har været med at kunne stille de rigtige krav til den digitale aflevering. Den ene problemstilling er der i mange byggesager er en adskillelse mellem bygherren og den efterfølgende driftsherre, og at der derfor ikke en involvering af driftsherren i byggesagen. Den anden problemstilling er, at der er mange sager, hvor bygherren ikke har kompetencerne til at stille krav til den digitale aflevering. I interviewet med Skanska fremgår det, at firmaet ikke har erfaringer med at stille krav til den digitale aflevering, og derfor ikke modtager det materiale de kunne ønske fra entreprenørerne (Kaa, 2011). Firmaet kunne med fordel anvende Kravkonfiguratoren til at beskrive deres behov på en struktureret måde, og således vil der være større sandsynlighed for at modtage det relevante materiale fra entreprenørerne. 103 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 6.2.2 Værktøjer til at styre den digitale aflevering Der findes en række applikationer, hvis hovedfunktion er at styre den digitale aflevering. Arbejdes der med bygningsmodeller i projekteringen, er det muligt at udforme med en kravmodel, der kan indeholde de krav, der er fra bygherren til byggeriet. I den traditionelle proces er det et byggeprogram, der danner grundlaget for den efterfølgende byggesag. Her defineres bygherrens krav til byggeriet, som dækker alle aspekter af byggeriet. Der findes flere digitale værktøjer, der kan anvendes til at opstille krav til, hvordan bygningen skal performe, som bygger på principperne fra BIM. Herunder er der givet to eksempler på sådanne værktøjer. Trelligence Affinity Affinity er en applikation, der anvendes til stille krav til et byggeri, og er dermed rettet mod programmeringsfasen. I Affinity kan der arbejdes med alle typer krav til et byggeri. Kravene oprettes ideelt som parametre, der kan ”forstås” af applikationen, men der kan også oprettes krav i almindelig tekst. I Affinity kan der både arbejdes med kravstillelsen visuelt og i skemaform. Herunder følger en typiske arbejdsgang i Affinity. • Generelle projektkrav: Projektet defineres og overordnede krav stilles til projektet – herunder pris og tid. • Rumprogrammering: Rummene defineres og der stilles krav på rumniveau. Det er her BH får et større overblik over hvor meget og hvad, der skal bygges. • Nærhedsdiagrammer: Bruges til at vise bygherres krav til cirkulation og sammenhænge i bygningen. • Skitsering på overordnet og rum niveau: (se figur 57) Denne funktion kan bruges til at kommunikere forslag til indretning med brugerne. Figur 57, Skitsering af byggeriet, screenshot fra Trelligence Affinity 104 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 Affinity er fuldt integreret med SketchUp, Revit Architecture og ArchiCAD, og kravmodellen kan derfor overføres til projekteringen, og det er muligt at udføre kontrol af mellem de to. (Trelligence, 2011) dRofus dRofus er en applikation til at styre kravene fra byggeprogrammet gennem en byggesag. Applikationen anvendes i flere større komplicerede byggerier til at holde styr kravene i forhold til projektmaterialet, fx anvendes der dRofus i forbindelse med projekteringen af det nye Skejby sygehus. dRofus nævner selv følgende områder som applikationen understøtter: • • • • Planlægning og kortlægning af arealer, rum og funktioner Registrering og overvågning af kravene til hvert enkelt rum Planlægning, priskontrol og udbud af møbler og udstyr Kontrol og visualisering af bygningsmodel gennem IFC dRofus kan dermed anvendes til at styre krav til areal, rum og funktioner samt møblering og udstyr, hvilket især giver værdi i sygehusbyggerier på grund af disse projekters store kompleksitet. (dRofus, 2011) 6.2.3 Indhold af kravene til den digitale aflevering Indholdet af bygherrens krav i byggeprogrammet er de konkrete krav, som bygherren har til den kvalitative og kvantitative udformning af byggeriet. Indholdet af disse krav kunne være: • • • • • • Byggeriets omfang Tidsplan Økonomi Forsyning Miljøforhold Og lignende… I forhold til driften kunne byggeprogrammet indeholde krav til: • • • • • • • Vedligeholdelse af bygningsdele, overflader, tekniske anlæg mm. Rengøring Kvalitet Levetidsbetragtninger Indeklima Forbrug Og lignende… Tilsammen danner kravene grundlaget for projekteringen, og de er ligeledes disse krav der tages udgangspunkt i forhold til om rådgiverne har levet op til bygherrens krav. Der kan være stor forskel på, hvor specifikke kravene er, hvilket både kan skyldes valget af entrepriseform, men også hvor ”frie tøjler” bygherren mener, at rådgiverne skal have under projekteringen. 105 Løsningsforslag 6.3 Kap: 1-2-3-4-5-6-7-8-9 Håndtering af D&V gennem byggeprojektet Rådgiverne og entreprenørerne har traditionelt ikke deres hovedfokus på aflevering af byggeriet. Hovedfokus ligger på at projektere og opføre et byggeri, der lever op til bygherrens krav. Det er dermed op til bygherren at sikre, at rådgiverne og entreprenørerne også har fokus på afleveringen. Med introduktionen af BIM i mange rådgivningsfirmaer og entreprenørfirmaer er det naturligt, at der afleveres i en digital bygningsmodel i stedet for traditionelle tegninger med tilhørende dokumenter. Der er i dette løsningsforslag præsenteret, hvordan der kan opsættes et projektmateriale, så det kan dokumentere produkt og proces af det afleverede byggeri. 6.3.1 Opsætningen af den digitale bygningsmodel Den digitale bygningsmodel er den centrale platform i projekteringen og udførelse af byggerier, der udføres som BIM-projekter. Det er derfor også bygningsmodellen, der er central i forhold til at kunne styre og opbevare de oplysninger om byggeriet, der skal leveres til driftsherren. I BIM er bygningsmodellen i forvejen containeren for de relevante informationer for byggeriet. Her samles informationerne om byggeriet løbende, således at modellen svarer til det faktiske ”as-built” byggeri. Bygningsmodellen skal struktureres efter en klassifikation for at sikre, at der kan ske en udveksling af informationer på tværs af systemer, arbejdsområder og parter. I BIM danner bygningsmodellen som sagt grundlaget for alt arbejde med projektet, og derfor kan det skabe stor usikkerhed, hvis bygningsdele og objekter navngives på forskellige måder. Det er derfor afgørende, at de involverede parter ved projektets start bliver enige om en klassifikation og en struktur, som skal anvendes i forbindelse med navngivning af projektinformationer, og at det løbende kontrolleres, at aftalerne overholdes. Det vil i denne rapport ikke blive behandlet, hvilke klassifikationer der bør anvendes, men at det er afgørende, at der anvendes en klassifikation, og at der er stor datadisciplin omkring navngivningen. Det er nærliggende at anbefale, at al information skal samles i bygningsmodellen, når der arbejdes i BIM. Dette er dog ikke anbefalet i denne rapport, da de almindeligt anvendte softwareapplikationer og arbejdsprocesser ikke understøtter arbejdet i en fællesmodel. Den typiske måde at arbejde modelbaseret i byggeriet er, som skitseret i figur 58, hvor der arbejdes i tre forskellige modeller, som i større eller mindre grad bliver kontrolleret mod hinanden. Dermed er der ofte ikke den fællesmodel, hvor alle informationerne samles, men derimod tre (eller flere) modeller, som indeholder hver sin information, men også indeholder redundant information, der går igen i flere modeller. Dertil er der ofte problemer med at bygningsmodellerne bliver for ”tunge” at arbejde i, når de indeholder for meget information. Ved at opbevare driftsdata i en selvstændig database sikres det, at bygningsmodellen ikke bliver yderlig belastet af informationerne om D&V og andre FM-data. Det er derfor i denne rapport valgt at undersøge, hvordan de D&V-informationerne, som driftsherren har behov for, kan samles centralt i et andet format, der kan supplere bygningsmodellen. Da de fleste CAFMsystemer bygger på en database, er det nærliggende at se på, hvordan der kan anvendes en database til at supplere bygningsmodellen. På den måde kan alle informationerne samles ét sted. 106 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 Figur 58, Modelbaseret arbejdsmetode i den danske byggebranche. 6.3.2 Opsætning af database for D&V- og FM-data Databasen er sat op for at kunne indeholde de data, som der ikke er indeholdt i modellen. Som Figur 59 viser bør bygningsmodellen indeholde alle bygningsdele i bygningen samt de grundlæggende egenskaber for disse. Databasen kan dertil indeholde informationerne om D&V, men for så vidt også andre informationer, som der er behov i driften, men der ikke er behov for at opbevare i modellen. Figur 59, Integration mellem bygningsmodel og database. Databasen kan med fordel oprettes på baggrund af modellen. Til dette kan der anvendes et af de værktøjer, der er beskrevet i det følgende afsnit. I disse værktøjer kan IFC-filer konverteres til regneark, der kan 107 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 læses i fx Office Excel. Dermed overføres strukturen fra bygningsmodellen i en skematisk form, som kan anvendes til at styre informationerne til driftsherren. Der er i det følgende afsnit både beskrevet, hvordan IFC-modeller kan konverteres til COBie og tilbage igen ved hjælp af AEC3 BIMServices toolkit, og hvordan IFC- modellen kan oversættes til et regneark ved hjælp af IFC File Analyzer. Hermed kan bygningsmodellen danne grundlaget for databasen, og det sikres dermed at bygningsdelene som udgangspunkt er navngivet og struktureret på samme måde. 6.3.3 Test af applikationer til konvertering af IFC-filer Transformation af IFC model til COBie: Firmaet AEC3 udbyder en software, som hedder BIMSERVICES, der kan styre og manipulere ”facility models” og skabe relationer mellem FM-data i forskellige formater. BIMSERVICES toolkit’et indeholder følgende separate applikationer: • Compliance1 o Til sammenligning af en bygningsmodel med de forventede datakrav. o Til sammenligning af en bygningsmodel mod lovkrav. o Til sammenligning af en bygningsmodel mod klientens krav. • Compare1 o Til sammenligning af to bygningsmodeller • Report1 o Til rapportering af det rummelige hieraki og dets indhold o Til rapportering af zoner og relaterede rum o Til rapportering af typer og antallet af komponenter o Til rapportering af systemer og deres tilhørende komponenter o Til rapportering af komponenter • Filter1 o Til systematisk at fjerne udvalgt data fra bygningsdata o Til hurtigt at fjerne unødvendig geometri før transformering • Transform1 o Til kortlægning af eksterne formatter til facility data o Til kortlægning af facility data til eksterne formater o Til generering af rapporter o Til sammenføjning af specifikke suplementerende modeller. (AEC3) 108 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 BIMSERVICES toolkit tilbyder en måde at arbejde med kravene til afleveringen gennem projekteringen og udførelsen er at kunne sammenligne kravene med projektmaterialet. I det tilfælde hvor der arbejdes modelbaseret er det muligt at kontrollere modellen mod kravene til aflevering af informationer til driftsherren. Med BIMSERVICES toolkit er det ligeledes muligt at udveksle data mellem modeller og mere tilgængelige formater som html og xml. Det er dertil muligt at transformere en IFC model til COBie, som derefter kan bearbejdes i et regneark. For at gøre dette anvendes BIMSERVICES toolkit og den applikation der hedder Transform1. COBie formatet gør det nemmere for de parter i byggesagen der ikke anvender modelleringsapplikationer at tilgå datamodellen og rette informationerne. Det er formålet med COBie-projektet at det skal implementeres i softwareapplikationerne således at der kan udveksles fra applikationerne direkte i COBie-formatet, men det er stadig begrænset hvilke applikationer der understøtter dette format. Transformation af IFC model til regneark: Der er i stedet anvendt muligheden for at transformere IFC-modellen til et regneark, hvilket kan hjælpe med driftsherren med at modtage modellen i et format, som han kan læse. Transformationen kan ske igennem IFC File Analyser som kan konvertere en IFC-fil til et regneark. I regnearket oprettes alle de typer af bygningsdele som findes i bygningsmodellen i hver sit ”worksheet”, som indeholder attributter for hver enkelt bygningsdel. Regnearket kan fx anvendes til at analysere forskellige IFC-filer mod hinanden. I modsætning til almindelige IFC viewere giver regneark den fordel at alle bygningsdelene og deres attributter kan overskues på én gang. (The National Institute of Standards and Technology, NIST, 2011) I denne rapport anvendes IFC File Analyzer til at konvertere en IFC til et regneark, som kan danne grundlag for den database der skal indeholde driftsinformationerne for byggeriet. Der er i figur 60 vist hvordan IFC File Analyser sættes op til konverteringen. IFC-filen åbnes i applikationen og derefter kan der opsættes regler for konverteringen som vist i figur 60. 109 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 Figur 60, Opsætning af konvertering af IFC til regneark, screenshot fra IFC file Analyzer Derefter trykkes der på ”Generate Spreadsheet”, og i løbet af få sekunder er der oprettet et regneark for IFC-filen. Figur 61 viser det regneark, der dannet på baggrund af IFC-filen. 110 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 Figur 61, Konverteret regneark fra IFC foretaget i IFC File Analyzer, screenshot fra Office Excel 6.3.4 Opsamling på databasestruktur Brugen af COBie formatet er interessant, da det virker til at formatet kan indeholde en mere rig information end de traditionelle regneark. Der er dog ikke nogen af de analyserede CAFM-systemer, der på nuværende tidspunkt understøtter COBie-formatet, og derfor er struktureringen efter denne standard i disse tilfælde ikke optimal. På sigt kan det dog anbefales, at der anvendes COBie til at styre informationerne til driftsherren. Standarden vil gøre det nemmere at udveksle informationer på en ensartet måde, og dermed spares der ressourcer med at skulle genopfinde strukturen ved hver ny aflevering. Indtil COBie bliver mere udbredt, anbefales det at anvende et regneark, der er skabt på baggrund af en IFCmodel. Derefter bør databasen sættes op i samarbejde med driftsherren, således at den ligner den struktur, der allerede anvendes i dennes CAFM-system. Dermed sikres det, at de data, der skabes i byggesagen, nemt kan overføres til driftsherrens CAFM-system. I databasen oprettes, der alle de attributter for bygningsdele, som driftsherren har behov for. Det kunne være informationer som: producent, leverandør, entreprenør, materialer, anskaffelse og garanti, anbefalinger om vedligeholdelse, eftersyn, rengøring, afprøvninger, godkendelser, produktblade, produktfotos, brugervejledning, driftsvejledning og afprøvningsvejledning. Databasen oprettes i projekteringen af rådgiveren med det formål at opstille kravene for entreprenørernes aflevering. 111 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 6.3.5 Brug af bygningsmodeller til analyse af driften For at anskueliggøre hvordan bygningen kommer til at fungere under driften, kan der fortages forskellige former for analyser under projekteringen. En del af disse analyser foretages allerede i de fleste byggesager, som varmetabsanalyser, brandanalyser og indeklima. Ved anvendelsen af bygningsmodeller i projekteringen er der kommet nye muligheder for at anvende modelbaserede analyseværktøjer, der har et mere komplet grundlag for disse analyser. Der er med anvendelse af bygningsmodeller i projekteringen, ligeledes kommet nye muligheder for at kontrollere bygningsmodellen mod de krav der er til bygningen. Det kan blandt andet gøres ved at anvendes de applikationer, der er nævnt i kapitel 6.2.2, men der kan også anvendes applikationer som Dalux BIM checker, Solibri eller Autodesk Navisworks. Et område som der ikke så ofte analyseres, er de udgifter, der er forbundet med driften af en bygning. Der er i det følgende afsnit udført et eksempel på, hvordan der kan udføres et modelbaseret driftsbudget. 6.3.6 Udformning af modelbaseret driftsbudget I alle byggesager udføres der løbende budgetter for udgifterne i forbindelse med opførelsen af byggeriet. For bedre at kunne overskue de økonomiske konsekvenser, som beslutninger i projekteringsfasen har for driften, er der herunder givet et eksempel på, hvordan der kan opstilles et budget for driften af bygningen. Denne opstilling af driftsbudgettet er foretaget i Vico Office. Vico Office er en softwareapplikation, hvori der kan foretages forskellige analyser indenfor planlægning og tidsstyring. I denne analyse anvendes den del af applikationen, der behandler prisberegning. Fordelen ved at anvende en applikation som Vico Office i forhold til fx Excel er, at den er modelbaseret, hvilket giver en tættere forbindelse mellem design og budget. Testen er foretaget med hjælp fra Exigo Consult (www.exigo.dk), som har stillet bygningsmodellen og en licens til Vico Office til rådighed. Import af model: Første trin er at importere modellen i systemet. Vico Office anvendes til at udføre overslag og beregninger på pris og tid på en model, men ikke til at modellere. Der importeres derfor en model fra et modelleringsprogram. Det kan enten ske gennem IFC-formatet eller gennem proprietære formater fra fx ArchiCAD eller Revit. I dette eksempel er der anvendt en villa til beregningen af driftsudgifterne på grund af overskueligheden af bygningen. Efter importen skal modellen gennemgås for inkonsistens af objekterne (se figur 62). Dvs. at sikre at bygningsdelene er klassificeret korrekt og ligger i det rigtige lag. Modellen burde være konsistent ved importen, men ofte vil der være nogle uregelmæssigheder i modellen, som skal rettes, hvilket der også var i dette tilfælde. 112 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 Figur 62, Opsætning af aktiviteter og bygningsdele i budgettet samt gennemgang af modellen for konsistens, screenshot fra udformning af driftsbudget foretaget af forfatteren i Vico Office. Opsætning af budget og ”target-priser” for driften: Andet skridt i processen er opsætning af et budget med de poster, der er beskrivende for udgifterne i forbindelse med driften. Der er anvendt et almindeligt excel-ark til at opsætte posterne, som der er anvendt til at beregne driftsudgifterne ud fra • • • • • Planlagt vedligehold Lovpligtigt vedligehold Ad-hoc vedligehold Rengøring Forbrug Hver af disse hovedaktiviteter er opdelt efter bygningsdele, som igen er opdelt på underaktiviteter. Der er taget udgangspunkt i den skabelon for driftsbudget, som kan hentes på Byggecentrums hjemmeside til at bestemme de typiske bygningsdele. I Vico Office opsættes der target-priser for bygningen. Som det fremgår af figur 63 kan target-priserne specificeres for alle de poster, der er skrevet ind i budgettet. I dette tilfælde er det dog valgt kun at gøre dette på et overordnet niveau. Udover at der dermed er en target-pris, som der kan arbejdes med i projektet, kan det også defineres, hvor stor en procentdel af udgifterne, der må gå til de enkelte poster. Dette kan fx bruges til at styre, hvor stor en del af udgifterne, der skal anvendes til vedligehold af bygningsdele, og hvor stor en del der skal anvendes til forbrug. 113 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 Figur 63, Opsætning af targetpriser for driften, screenshot fra udformning af driftsbudget foretaget af forfatteren i Vico Office. Kobling mellem aktiviteter, bygningsdele og mængder: Når aktiviteter og bygningsdele er oprettet i systemet, skal bygningsdelene kobles med bygningsdelene i den tidligere importerede model. I dette tilfælde var der en del inkonsistens i modellen, der først skulle behandles, for at der kunne ske en korrekt kobling mellem bygningsdelene i budgettet og bygningsdelene (objekterne) i modellen. Som det fremgår af figur 64 så sker koblingen fra budgettet, hvor der vælges en bygningsdel, som kan kobles med de geometriske informationer, der er indeholdt i hver bygningsdel i modellen. Denne applikation kan ”huske” forbindelsen mellem budgettet og bygningsdelene i modellen, og derfor er dette en aktivitet, der kun skal gentages for nye bygningsdele, hvis der importeres en opdateret model i systemet. Figur 64, Kobling af bygningsdele i driftsbudgettet med bygningsdele i modellen, screenshot fra udformning af driftsbudget foretaget af forfatteren i Vico Office. 114 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 Interval og unitpriser: De aktiviteter, der skal foretages i forbindelse med driften, findes ved hjælp af V&S-prisbøger fra Byggecentrum. Det er dermed først her at de konkrete underaktiviteter indsættes i budgettet, da det i stor udstrækning afhænger af, hvordan aktiviteterne er opdelt i prisbøgerne. Det er ikke altid at aktiviteterne er opdelt på samme måde, som det oprindeligt var tiltænkt i budgettet, og derfor sker der en vis tilpasning i denne proces. Det er ligeledes nødvendigt at anvende flere forskellige prisbøger for at finde de mest korrekte priser. Som det fremgår af figur 65, så er overførslen af enhedspriser fra V&S-prisbøgerne en manuel proces. Professionelle driftsherrer kan med fordel anvendes konkrete erfaringstal fra lignende bygninger og bygningsdele, hvis dette foreligger i organisationen. Figur 65, Kobling af bygningsdele i driftsbudgettet med enhedspriser fra V&S-prisbøgerne i Sigma, screenshot fra udformning af driftsbudget foretaget af forfatteren i Vico Office. Budgettet er for driften af bygning set over en periode på 30 år, og der skal dermed også foretages en vurdering af hvilke aktiviteter, der skal foretages i løbet af denne periode, og hvor ofte de skal foretages. Intervallet af aktiviteterne er justeret ved at anvende kolonnen ”consumption”. Hvis en aktivitet udføres hvert år, står der 30 i feltet. Hvis en aktivitet foretages hvert 10. år står der 2 i feltet ud fra den betragtning at aktiviteten foretages i år 10 og i år 20, mens der ikke foretages vedligehold i år 30, da der på dette tidspunkt sker en genopretning af bygningen, som erstatter vedligeholdelsesaktiviteter, der ellers skulle foretages på dette tidspunkt. 115 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 Waste faktor: Waste faktor kolonnen er i dette budget blevet anvendt til at justere priserne i forhold til udformningen af bygningen. Et eksempel kunne være, at ventilationsanlægget er udformet på en måde, så det er svært tilgængeligt og dermed tager længere til at udføre vedligeholdelse på. Et andet eksempel kunne være at vinduerne er placeret på steder, hvor de er svært tilgængelige, eller at deres udformning gør, at det tager længere tid at rengøre dem. Begge de nævnte eksempler er anvendt i budgettet til at opjustere priserne for de aktiviteter, der relaterer sig til ventilationsanlægget og vinduerne. Det endelige budget: Hermed er budgettet sat op, og det er muligt at aflæse de samlede driftsudgifter for bygningen. I dette budget er der medtaget rengøringsaktiviteter og forbrug af vand, varme og elektricitet. Det gør det muligt at sammenligne anlægsbudgettet med både vedligeholdelsesaktiviteter, rengøringsaktiviteter og forbrug. En interessant funktion i Vico Office er, at det vises, hvor stor en procentdel de forskellige aktiviteter udgør af de samlede udgifter, hvilket gør det nemmere at sammenligne størrelsen af de forskellige udgifter. Der kan ligeledes ske en sammenligning af budgettet med de target-priser, der blev opstillet i starten af budgettet. Dette vil dog især være relevant, når der foreligger erfaringstal fra drift af andre bygninger. Figur 66, Det endelige budget for driften af bygningen, screenshot fra udformning af driftsbudget foretaget af forfatteren i Vico Office. Driftsbudgettet kan med fordel anvendes sammen med de andre analyser, der foretages i løbet af byggesagen. Fx er det muligt at sammenstille driftsbudgettet med budgettet for anlægsudgifter, hvor det kan anskueliggøres, hvilke konsekvenser en 10 % reduktion af anlægsudgifterne har for de samlede driftsudgifter. Et andet eksempel kunne være, at lade driftsbudgettet vise, hvor meget en reduktion af varmetabet betyder for udgifterne til varme i driften af bygningen. Dermed kan det nemmere vurderes om en sådan investering kan betale sig, og om der er andre investeringer, der er mere fordelagtige at foretage. 116 Løsningsforslag 6.4 Kap: 1-2-3-4-5-6-7-8-9 Afleveringen Det som driftsherren har behov for præcise informationer om driften af den bygningen der skal afleveres, hvilket brugen af en database til opbevaring af D&V-data gerne skal sikre. Ved at anvende den model for aflevering, som der er præsenteret i denne rapport er langt den største del af indsamlingen af informationer til driftsherre allerede sket i løbet af byggesagen. Dermed bør selve afleveringen kun være et punkt hvor informationerne formelt overdrages til driftsherren. Det, som entreprenørerne skal gøre i løbet af byggeriet, er at opdatere databasen med de informationer, der opstillet i projekteringen. Ved at rådgiverne opstiller regler for databasen, kan entreprenøren se, hvis der er produkter, han har valgt, der ikke lever kravene i databasen. 6.5 Det optimale CAFM-system. Et af de områder, der er behandlet i denne rapport, er en analyse af, hvordan CAFM-systemerne kan støtte driftsherren i dennes arbejde. Som tidligere nævnt i rapporten anvendes der mange kunde-tilpassede systemer eller kombination af flere systemer i Danmark (se kapitel 2.2.3). Analysen viser, at der et ønske om at anvende en database, således at data altid er opdaterede og konsistente. Ved at anvende et CAFMsystem, der dækker alle opgaver, som driftsherren har, sikres det at informationerne samles ét sted. Alternativt kan der anvendes flere forskellige applikationer, der alle bygger på den samme database. 6.5.1 Vurdering af de testede CAFM-systemer I denne rapport er der testet tre forskellige CAFM-systemer, CoreFM, LogFM og ArchiBUS. Systemerne bygger alle tre på en database, hvilket sikrer et godt grundlag for at arbejde med driftsinformationerne på en dynamisk måde. Dertil er de alle tre CAFM-systemer forholdsvis omfattende og dækker store dele af driftsherrens arbejdsområde, og det meste arbejde kan derfor foregå i det samme system. Der er dog områder, som kunne understøttes bedre af CAFM-systemerne, hvilket der er givet et forslag til i det følgende afsnit. De CAFM-systemer, der er testet, har hver deres fordele og ulemper, hvilket der er samlet op på herunder: Der er i CoreFM valgt udelukkende at anvende en webbaseret brugerflade i modsætning til de to andre systemer. Det er ud fra den betragtning, at systemet dermed bliver tilgængeligt for de personer, der arbejder med driften. Ud fra den test der er foretaget af CAFM-systemerne, virker det dog til, at der ofres noget af funktionaliteten ved denne type brugerflade. Eg: ved hver gang der skal loades et nyt skærmbillede går der et par sekunder før den kaldte side kommer frem. Det kan virke som et mindre irritationsmoment, men i almindelig softwareudvikling er det ”load-time” mellem skærmbilleder afgørende for om brugerne vil anvende systemet. I de andre CAFM-systemer (LogFM og ArchiBUS) er brugerfladen installeret på den lokale computer, hvilket umiddelbart giver nogle fordele, når der arbejdes i systemet. For det første så loader skærmbillederne hurtigere end i CoreFM, hvilket gør det hurtigere at arbejde i systemet. For det andet så giver det umiddelbart mulighed for flere filtreringer af informationerne, og dermed også mulighed for en mere dynamisk visning af data. 117 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 CoreFM og LogFM ligner hinanden i forhold til antallet omfanget af moduler og funktioner, mens ArchiBUS er et noget mere omfattende system, med væsentligt flere moduler. Dette kan dog være en svær sammenligning, da systemerne ofte kundetilpassede, således at driftsherrerne selv vælger, hvilke moduler de ønsker at implementere fra den samlede applikation. Derfor kan to driftsherrer anvendes det samme CAFMsystem, mens indholdet af systemer kan være forskelligt alt efter deres behov. I forhold import af data fra bygningsmodeller er der ingen af systemerne, der har en fuld integration med IFC. ArchiBUS er det system, der har den tætteste integration med en bygningsmodel (rum, møblering og udstyr), men det må være et fremtidigt krav at CAFM-systemer har en bedre integration med bygningsmodeller. ArchiBUS er det mest omfattende system i testen med klart fest moduler og anvendelsesområder. Systemet kan anbefales til meget store driftsorganisationer, der ønsker et omfattende CAFM-system. Systemet har også nogle stærke funktioner for organisationer, der ønsker at anvendes driftsdata strategisk. LogFM er i høj grad et kunde-tilpasset system, som også udbydes kommercielt. Systemet kan anbefales til driftsherrer, der har en central organisation. Systemer er især godt til at håndtere filtreringer af informationer, hvilket giver driftsherren rig mulighed for at sammenstille mange former for data. CoreFM kan anbefales til organisationer, der lægger vægt på at CAFM-systemet skal have en meget høj tilgængelighed. Det kan fx være driftsherrer. som har mange decentrale opgaver. Systemet har især en stærk funktion i dets brugervenlighed, som ikke kræver opfattende IT-kompetencer for at anvende. Valget af CAFM-system skal selvfølgelig også vurderes ud fra et økonomisk perspektiv, hvilket kan være meget forskelligt fra system til system, og efter hvor stor en del af systemet, der ønskes implementeret i organisationen. 6.5.2 Forslag til funktion i CAFM-systemer Ud fra den analyse der er foretaget i kapitel 5.1, fremgår det, at der er behov for at kunne involvere brugerne mere i driften. Det bliver blandt andet nævnt, at der er behov for en applikation, der kan håndtere fejlmeldinger fra brugerne. I figur 67 er den traditionelle fejlmelding skitseret. Her fremgår det, at der er mange led, som informationen skal igennem, fra brugeren der registrerer problemet, til håndværkeren der løser problemet. Ved store organisationer kan kommunikationsvejene endda være endnu længere. Problemet med denne form for fejlmelding er, at der ved hver informationsudveksling kan der gå information tabt. Dertil risikeres det, at informationen stopper et sted i kæden og ikke når frem til den relevante person. 118 Løsningsforslag Kap: 1-2-3-4-5-6-7-8-9 Figur 67, Rich picture af hvordan fejlmeldinger foregår i dag. Der er mange led, der kan skæres ud af kæden, hvis brugeren, der registrerer fejlen, selv kan melde fejlen direkte til driftsherren gennem CAFM-systemet. Det kan ske ved at give brugeren en tilpasset adgang til CAFM-system, hvor denne kan indtaste fejlen, som det er vist i Figur 68. Figur 68, Rich picture af hvordan fejlmeldinger kan foregå ved ny funktionalitet i CAFM-system 119 Kap: 1-2-3-4-5-6-7-8-9 Evaluering 7 Evaluering Der er i det følgende afsnit foretaget en evaluering af nogle af de løsningsforslag, der er fremsat i kapitel 6. Evalueringen er foretaget i samarbejde med Aarhus Arkitekterne, Dan-Ejendomme og Teknisk Forvaltning på Aalborg Universitet. I dette kapitel er der anvendt metoden: Test with Customers fra Contextual Design. 7.1 Evaluering med Aarhus Arkitekterne Der er foretaget en evaluering i samarbejde med Søren Sti Andersen (SA) fra Aarhus arkitekterne for at kortlægge om løsningsforslaget har en praktisk værdi for firmaet. Evalueringen er foretaget på et møde hos Aarhus Arkitekterne, hvor løsningsforslaget blev præsenteret. På mødet blev det diskuteret, om løsningsforslaget med aflevering af en bygningsmodel og en tilhørende database kan have en værdi for afleveringen i en byggesag. Dertil blev det også diskuteret, hvorvidt løsningsforslaget med det modelbaserede driftsbudget kan værdi for Aarhus Arkitekterne. I forhold til den modelbaserede aflevering er SA enig i, at det kan være en god idé at opbevare D&V-data i en database separat fra modellen. Som det er nu er der allerede problemer med at modellerne bliver for ”tunge” at arbejde med, og derfor kan det være en god ide at opbevare driftsdata et andet sted. Det afgørende er dog, at det er de rigtige data, der bliver specificeret. I forhold byggesagen OCC forsøger firmaet at blive helt konkrete, når det gælder specificeringen af, hvilke D&V-data det er at bygherren efterspørger. Hvis ikke dette er på plads, er det underordnet, hvordan data bliver opbevaret. SA mener at det modelbaserede driftsbudget er en interessant tanke, men det er umiddelbart ikke noget, som Aarhus Arkitekterne vil anvende. Firmaet har ikke kompetencerne til at udforme driftsbudgetter og vil derfor hente andre rådgivere ind til dette, hvis det er et krav i en byggesag. SA mener, at det kræver stor erfaring med FM for at kunne udforme budgetter for driften. 7.2 Evaluering med Dan-Ejendomme a/s Der er i samarbejde med Benjamin B. Andersen (BA) fra Dan-Ejendomme foretaget en evaluering af det modelbaserede driftsbudget, der er opstillet i løsningsforslaget i kapitel 6. Evalueringen er foretaget via mail på baggrund af den udformede tekst i løsningsforslaget. BA udtaler at Vico Office har mange fordele, og princippet om en modelbaseret beregning er interessant. Udfordringen er ifølge BA ikke så meget teknik – som eksemplet også viser, så er det nok mere indhold og struktur, som er interessant. Forstået på denne måde, at det fremgår af eksemplet, at der er inkonsistens i den anvendte bygning, hvilket skyldes manglende struktur. 120 Evaluering Kap: 1-2-3-4-5-6-7-8-9 BA mener at selv meget simple værktøjer, som fx Unik (anvendes af Dan-Ejendomme) også nemt kan opstille driftsbudgetmodeller, hvilket Dan-Ejendomme bl.a. anvender i OPP-projekter. Dertil vil fx Sigma, Archibus m.fl. helt sikkert også kan opstille disse modeller eller blot Excel. Forudsætningen for en fornuftig model er i høj grad struktur, således at byg- og driftsherre, så de kan få valide data i velkonsolideret struktur, så modellen kan bruges til analyser, kravkontrol og i driften. BA mener at modeltankegangen er interessant, den skal blot for investeringskunder tænkes anderledes. Disse kunder ser meget på beliggenhed, kvadratmeterpris, den månedlige og især afkastet af investeringen. Derfor bør modellerne nok være lidt mere omfattende for at kunne bruges i denne sammenhæng. 7.3 Evaluering med Teknisk Forvaltning, AAU Der er i samarbejde med Rasmus Wernlund (RW) fra Teknisk Forvaltning på Aalborg Universitet foretaget en evaluering af det modelbaserede driftsbudget, der er opstillet i løsningsforslaget i kapitel 6. Evalueringen er foretaget telefonisk på baggrund af den udformede tekst i løsningsforslaget. RW starter med at sige, at virker meget interessant med et modelbaseret driftsbudget. Tanken, med at budgettet bygger på en model, vil være med til at sikre, at der er et godt, præcist grundlag at beregne driftsudgifterne ud fra. Det er også interessant, at der kan regnes på tid i samme applikation på samme model, hvilket giver gode muligheder for at skabe sammenhæng mellem prisberegning og tidsplanlægning. Teknisk Forvaltning har dog nogle organisatoriske udfordringer i de byggesager, som de er involverede i, da UBST er bygherre. Ofte så bliver Teknisk Forvaltning først involveret midt i byggesagen, og derfor er der ikke altid de store muligheder for at ændre i projektet. RW er generelt dog meget positiv overfor anvendelse af et modelbaseret driftsbudget, og mener at det kan have stor værdi for driftsherren. Teknisk Forvaltning overvejer, om de skal anvende Vico Office i konkrete byggesager og har derfor aftalt et møde for at få mere information om applikationen. 121 Konklusion og Perspektivering 8 Kap: 1-2-3-4-5-6-7-8-9 Konklusion Konklusionen samler op på de væsentlige konklusioner, som rapporten kommer frem til. Det er denne rapports konklusion, at der er et stort potentiale for at optimere afleveringen til driftsherren og driften af bygninger. Det er behov for en specifik, konkret, digital aflevering og ikke bare en digital aflevering af den traditionelle hyldemeter ringbind. Det fremgår af interviewene med driftsherrerne, rådgiverne og entreprenøren, at der er behov for mere fokus på den digitale aflevering. Der er for mange af byggeriet parter, der ved for lidt om digital aflevering, og dermed er der store udfordringer ved at sikre en god digital aflevering. Der er behov for en god kravstillelse fra projektets start. I mange sager er der problemer med at kunne stille krav, enten for kompetencerne ikke er til stede til at stille kravene, eller fordi at driftsherren ikke er tilstrækkeligt involveret i byggesagen. Først og fremmest skal bygherrerne overbevises om, at der er en værdi af en god digital aflevering. Dernæst skal der være fokus på at stille de rigtige krav i programmeringen, dette kan gøres ud fra en vurdering af de tre punkter i løsningsforslaget: aftalegrundlag for aflevering, værktøjer til styring af kravene og kravstillelsen til afleveringen. Ved at stille de rigtig krav fra starten af byggesagen og løbende styre og kontrollere arbejdet med at skabe informationerne til den digitale aflevering, er der stor sandsynlighed for at driftsherren modtager den information, som han har brug for. Ud fra analysen af driftsherrerne og CAFM-systemerne, CoreFM, LogFM og ArchiBUS står det klart at driftsherrerne ikke er klar til at anvende bygningsmodeller i arbejdet med Facilities Management. Derimod er de alle interesserede i at modtage bygningsmodeller til dokumentation af byggeriet. Da CAFM-systemerne ikke er klar til at modtage bygningsmodeller, er det i denne rapport foreslået, at der anvendes en database, der er struktureret efter bygningsmodellen, til at støtte bygningsmodellen. Denne database kan indeholde alle informationer, som ikke findes relevante eller nødvendige at opbevare i bygningsmodellen. Under projekteringen af byggeriet kan der med fordel foretages analyser, af hvordan bygningen ”performer” under driften. I denne rapport er der udført en opstilling af et modelbaseret driftsbudget, der kan overskue udgifterne for driften af bygningen over en 30-årig periode. Driftsbudgettet kan anvendes som argument for at foretage valg, der tilgodeser driften af bygningen. I driften af bygningen gælder det om at gøre informationerne om driften mere tilgængelig for flere interessenter i bygningen. Der er derfor givet et forslag, hvordan en applikation, der behandler interessenternes fejlmeldinger, kan designes. 122 Konklusion og Perspektivering 9 Kap: 1-2-3-4-5-6-7-8-9 Perspektivering Dette kapitel giver en introduktion til det videre arbejde og fremtiden for digital aflevering. Der er et stort fremtidigt potentiale for at optimere afleveringen til driftsherren og driften af bygninger. Anvendelsen af bygningsmodeller og Building Information Modeling i byggesager åbner op for nye muligheder for at anvende bygningsmodeller i driften af byggeriet. Bygningsmodellerne kan fx anvendes til at analysere på driften under projekteringen og dermed sikre en optimal drift af bygningen. Dertil kan bygningsmodellerne anvendes i afleveringen for at sikre, at informationerne er præcise og konsistente. Afleveringen af bygningsmodeller giver også driftsherren mulighed for at anvende en applikation til at analysere brugen af driftsherrens bygninger. En sådan applikation vil kunne analysere, hvordan en bygnings arealer udnyttes, og hvordan energiforbruget og andre typer af forbrug fordeler sig i bygningen, og dermed vil der kunne optimeres på udnyttelsen af arealer og det generelle ressourceforbrug. Der er for få CAFM-systemer, der understøtter importen af IFC, og det må formodes, at der i fremtiden bliver større muligheder for at anvende bygningsmodeller i CAFM-systemerne. Der er et potentiale i at anvende COBie i byggebranchen til at styre den digitale aflevering, men der er endnu for få CAFM-systemer, der understøtter COBie. Driftsherrerne kunne med fordel arbejde for at COBie implementeres i flere CAFMsystemer, således at standarden kan anvendes generelt i den digitale aflevering. Der er et stort potentiale for applikationer, der kan skabes kravmodeller både for den digitale aflevering men også for de generelle krav til bygningen. Dette vil sikre, at der er et præcist kravgrundlag at starte projekteringen fra. I driften er der behov for, at alle de applikationer, der anvendes, har en bedre integration af data. Der bliver større og større fokus på at fjerne redundant data og information, da det er spild af tid og kan skabes stor forvirring om validiteten af data. Der er derfor brug for at applikationerne arbejder sammen med en database. Et fremtidigt projekt, der kan have stor værdi for branchen, er udviklingen af flere Information Delivery Manuals, IDM, der beskriver arbejdsprocesser i byggeriet indenfor BIM. Især indenfor aflevering, hvor der er få parter, der har viden, og der mangler traditioner og eksempler for, hvordan en modelbaseret digital aflevering kan foregå, kan en IDM have stor værdi. Der aftalt med Aarhus Arkitekter, at der efter denne rapports afslutning skal arbejde videre med OCC byggesagen, med det formål at anvende rapportens konklusioner til at give en praktisk løsning på de problemstillinger, der er i forhold til den digitale aflevering i byggesagen. 123 10 Bibliografi AEC3. (u.d.). AEC3's hjemmeside. Hentede 5. December 2011 fra http://www.aec3.com/en/6/6_04.htm AIA, California Council. (2008). ipd-ca.net. Hentede 5. December 2011 fra http://www.ipdca.net/PDFs/AIACC_1108FAQ.pdf Andersen, B. B. (25. Oktober 2011). CAD ansvarlig, projektleder. ArchiBUS. (2011). Introducing the New ArchiBUS. Boston, Massachusetts, USA: ArchiBUS. Asbjørn Levring, Teknologisk institut. (2010). BIM-implementering og praktisk projekthåndtering. København: Implementeringsnetværket for Det Digitale Byggeri. Autodesk. (2011). Autodesk research. Hentede 17. Oktober 2011 fra http://www.autodeskresearch.com/pages/dasher BASIT. (u.d.). BASIT's hjemmeside. Hentede 26. December 2011 fra http://www.basit.dk/userfiles/file/Brochure%20ETjek%20Basit.pdf Ben Tremblay. (2009). Hentede 09. maj 2011 fra Ben Tremblay: http://bentremblay.com/en/if-id-asked-mycustomers-what-they-wanted-theyd-have-said-a-faster-horse Beyer, H., & Holtzblatt, K. (1998). Contextual Design, Defining customer-centered systems. San Francisco: Morgan Kaufmann Publishers. BIMlab, Danmarks Tekniske Universitet. (2011). Måling af økonomiske gevinster ved Det Digitale Byggeri (byggeriets digitalisering). Hentede 17. Oktober 2011 fra http://www.bim.byg.dtu.dk/Forskning/OEGvDDB.aspx Bips. (2007). F301, Introduktion til IFC. Ballerup: Bips. Bips. (2008). Modelbaseret arbejdsmetode i bips - medlemsundersøgelse maj 2008. Ballerup: bips. 124 BuildingSMART. (2010). BuildingSMART. Hentede 4. september 2011 fra http://buildingsmart.com/ buildingSMART Norway; Construction Specifications Canada (CSC); Construction Specifications Institute (CSI); STABU Foundation. (u.d.). IFD Library for BuildingSMART. Hentede 20. November 2011 fra http://www.ifd-library.org/index.php?title=Main_Page BuildingSMART, IFC. (2011). BuildingSMART. Hentede 20. November 2011 fra http://buildingsmart.com/standards/ifc Byggecentrum. (2008). Håndbog for bygningsindustrien. Hentede 7. December 2011 fra http://www.hfb.dk/fileadmin/templates/hfb/dokumenter/Oversigtsstof/sfb_systemet.pdf Bygherreforeningen. (2010). Byg- og Driftherrers Digitaliseringsbehov - Et værdibaseret digitaliseringsperspektiv. København: Bygherreforeningen. Bygherreforeningen. (u.d.). Bygherreforeningens hjemmeside. Hentede 6. December 2011 fra http://www.bygherreforeningen.dk Bygherreforeningen, kravkonfigurator. (u.d.). Kravkonfigurator for aftale om digitale data. Hentede 6. December 2011 fra http://www.driftsdata.dk/ Carlsen, C. (31. Oktober 2011). Property Manager, Steen og Strøm A/S. København. Christianson, P. (2006). Bygherrekrav - Digital Aflevering, Kravspecifikation - revision 2. Aalborg: DACAPO. Chuck Eastman, P. T. (2008). BIM Handbook. Construction Engineering Research Laboratory (CERL). (2007). Construction Operations Building Information Exchange (COBIE), Requirements Definition and Pilot Implementation Standard. U.S. Army Engineer Research and Development Center: Washington, DC. CoreFM. (u.d.). Om CoreFM. Hentede 21. November 2011 fra http://www.corefm.dk/corefmareal/servlet/CoreFMArealUserServlet?action=0;740120;740121;740198&id =0;4;40;-1&nexturl=%27jsp/homepage/std/presentation_frameset.jsp%27 125 Dalux. (u.d.). Dalux hjemmeside. Hentede 17. December 2011 fra http://dalux.dk/ Danvold, C. (24. Oktober 2011). Projektleder, Slots- og Ejendomsstyrelsen. Det Digitale Byggeri. (2010). DBK, Det Digitale Byggeri. Hentede 17. November 2011 fra http://www.detdigitalebyggeri.dk/tech-article/dbk-2006-%E2%80%93-dansk-bygge-klassifikation Det Digitale Byggeri. (2011). Det Digitale Byggeri. Hentede 24. Oktober 2011 fra Det Digitale Byggeri, implementeringsnetværket: http://www.detdigitalebyggeri.dk/tech-article/bim-%E2%80%93bygningsinformationsmodeller-og-modellering dRofus. (2011). dRofus, Product. Hentede 4. Januar 2012 fra http://drofus.no/en/product.html Energiwiki. (u.d.). Energiwiki. Hentede 11. 24 2011 fra http://energiwiki.dk/index.php/Automatik Erhvervministeriet. (2001). Det Digitale Byggeri - rapport fra en arbejdsgruppe. København: Erhvervsministreriet. Foreningen af Rådgivende Ingeniører, FRI. (2005). Partnering i praksis. Hentede 5. December 2011 fra http://www.frinet.dk/media/11622/partnering_i_praksis_2005.pdf Foster, B. (2011). BIM for Facility Management: Design for Maintenance Strategy. JBIM, Journal of Building Information Modeling . Gyldendals åbne encyklopædi. (2011). Den Store Danske. Hentede 25. September 2011 fra http://www.denstoredanske.dk/ Hylander, G. G. (2005). Grounded theory - et teorigenererende forskningsperspektiv. København: Hans Reitzels Forlag. Informi GIS. (2011). Informationsmateriale om ArchiBUS. Charlottenlund, Sjælland, Danmark: Informi GIS. ISO. (2010). ISO 29481-1:2010(E) Building information modelling, Information delivery manual, Part 1: Methodology and format. ISO. 126 Jensen, P. A. (2006). Digital Handover of Data from Building Projects to Operation. Kgs. Lyngby: Department of Civil Engineering, Technical University of Denmark. Jensen, P. A. (2011). Håndbog i Facilities Management (Årg. 3. udvidede udgave). Dansk Facilities Management - netværk. Jobs, S. (25. Maj 1998). BACK TO THE FUTURE AT APPLE. (Businessweek, Interviewer) Jonas Maaløe Jespersen, I. (2008). hfb.dk. Hentede 5. December 2011 fra Håndbog For Bygningsindustrien: http://www.hfb.dk/fileadmin/templates/hfb/dokumenter/artikler/Det_digitale_byggeri.pdf Jørgensen, K. A. (2011). The DBK Reference System, Why it is useless and needless. Aalborg: Aalborg Universitet. Kaa, I. (2. November 2011). Ejendomsudvikler, SKANSKA. Eget interview. København. Lægaard, J. (2009). Strategi i vindervirksomheder. København: Jyllands-Posten. LeFevre, M. (2001). No BIM for You: The Case for Not Doing BIM. JBIM, Journal of Building Information Modeling . LOGFM Aps. (u.d.). LOGFM Facilities Management. Hentede 24. 11 2011 fra http://logfm.dk/ Logimatic. (u.d.). Logimatic, tidligere byggesoft. Hentede 18. December 2011 fra http://www.byggesoft.dk/DigiTjek-produktark.pdf Logimatic. (u.d.). Logimatic, tidligere byggesoft. Hentede 21. December 2011 fra Fotodok: http://www.byggesoft.dk/FotoDok.html National Institute of Building Sciences. (u.d.). Whole Building Design Guide. Hentede 17. November 2011 fra http://www.wbdg.org/resources/cobie.php National Institute of Stadards and Technology . (2009). Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry. Gaithersburg, Maryland: U.S. DEPARTMENT OF COMMERCE. 127 Nybo, E. (2011). Ingeniørens hjemmeside. Hentede 15. November 2011 fra Ingeniøren/blogs: http://ing.dk/artikel/124098-nye-ydelsesbeskrivelser-for-byggeri-og-anlaeg-er-paakraevet Onuma. (u.d.). Onuma, Building Informed Enviroment. Hentede 11. December 2011 fra http://onuma.com/products/ Pedersen, J. (7. November 2011). CAD ansvarlig, planning og design, Grontmij. Eget interview. Århus. R. Grant, CSI and IFD Library Group. (2008). IFD Library White Paper. IFD Library for BuildingSMART. Rambøll. (u.d.). Rambyg. Hentede 24. 11 2011 fra http://www.rambyg.dk/ Steen og Strøm A/S. (u.d.). Newsmail, Et nyhetbrev fra Steen og Strøm A/S. Hentede 28. September 2011 fra http://www.steenstrom.com/Newsmail2-2011/SteenStrom-erhverver-byggegrund/ The National Institute of Standards and Technology, NIST. (2011). IFC File Analyser. Hentede 6. Januar 2012 fra http://www.nist.gov/el/msid/infotest/ifc-file-analyzer.cfm Tonni Elkjær, D. k. (26. September 2011). DNU - Det Ny Universitetshospital - Århus. Foredrag ved bipskonference, . Nyborg. Trelligence. (2011). Trelligence Affinity. Hentede 28. December 2011 fra http://www.trelligence.com/ Tv2 Fyn. (2011). Tv2 Fyn, Nyheder. Hentede 31. September 2011 fra http://www.tv2fyn.dk/article/314358:Holdet-bag-citycenter-er-fundet University of Twente. (2011). Contextual Design: University of Twente. Hentede 24. September 2011 fra http://www.utwente.nl/cw/theorieenoverzicht/Theory%20clusters/Communication%20and%20Informatio n%20Technology/contextual_design.doc/ Wernlund, R. (14. Oktober 2011). Bygningskonstruktør. Yding-Sørensen, S. (15. December 2011). Byggeleder, MT Højgaard. 128 11 Bilag I dette kapitel er referaterne af alle de udførte interviews samlet. Der er herunder givet en oversigt over bilagene. Indholdsfortegnelse for bilag: Bilag A: Referat af interview med Teknisk forvaltning, AAU 130 Bilag B: Referat af interview med Slots- og EjendomsStyrelsen 133 Bilag C: Referat af interview med Dan-Ejendomme a/s 135 Bilag D: Referat af interview med Steen og Strøm a/s 138 Bilag E: Referat af interview med Skanska a/s 141 Bilag F: Referat af interview med Grontmij 143 Bilag G: Referat af interview med Aarhus arkitekterne 146 Bilag H: Referat af interview med Moe og Brødsgaard a/s 149 Bilag I: Referat af interview med MT Højgaard a/s 153 129 11.1 Bilag A: Referat af interview med Teknisk forvaltning, AAU Dato for interview: d. 14.10.2011 Til stede: Lasse Møller, Aalborg universitet, Rasmus Wernlund (RW), Teknisk forvaltning (TF), Aalborg Universitet, Mette Andersen, Aalborg Universitet Organisationen: Der er et generelt problem i at driftsherren ofte bliver glemt. Det er som regel begrænset, hvad driftsherren får med fra projekteringen. Ved nye byggesager er det TF der står for driften, mens Universitets- og bygningsstyrelsen (UBST) er bygherre. Det er dermed UBST, der definerer krav + ydelsesbeskrivelse. Her er der sjældent konkrete krav til driftsdata. Derfor kræver rådgiverne ekstra honorar for aflevering af relevante driftsdata, hvis TF efterspørger det i løbet af projektet. Teknisk forvaltning står for D&V af de bygninger, som Aalborg Universitet lejer af UBST. Dermed er der en opdeling mellem bygherren og driftsafdelingen. Driften af Bygninger: TF driver som sagt Aalborg universitets bygninger. Dertil lejer universitetet en del bygninger rundt om i byen, som TF også administrerer. Det er forskelligt, hvor meget D&V som TF står for, alt efter lejekontraktens udformning. Det er derfor også forskelligt, hvor meget D&V-data, der ligger på de enkelte bygninger. Under sig har TF nogle driftsfolk, der står for den praktiske drift af bygningerne. Disse driftsfolk står den daglige drift, og det er dem der melder nye opgaver (fejlmeldinger) ind til TF. Der er ofte mange personer, der er involveret i fejlmeldinger. Det kan være en studerende, der melder en fejl til en studiesekretær, som melder videre til driftsfolk, som melder videre til TF. Dette er noget, som TF kigger på for at se, om det ikke kan gøres nemmere. Systemer: TF anvender LogFM til at styre og planlægge opgaver på D&V. I LogFM kan TF også styre økonomien for D&V af de forskellige bygninger. Der sker ved, at der bliver meldt opgaver ind fra brugere eller driftsfolk til TF i LogFM. Her vurderes og struktureres opgaverne, og der sendes en rekvisition på nye arbejder med pris gennem LogFM til udvalgte entreprenører. TF anvender en webbaseret applikation til at vise m2 og antal rum ud fra forskellige filtreringer (fakulteter, bygninger, lejemål ol.). Her vises oplysninger om tidslinjen for lejemålet. Det hjælper også de enkelte fakul- 130 teter til at få overblik over deres lejemål. Denne applikation er bygget på 2D-visning, som mange gange er det mest overskuelige, men TF kan se fordelen at have 3D-visninger til at vise hele bygninger og deres beliggenhed. Der anvendes CTS-styring til at holde styr på energiforbrug i bygninger. Afleveringen: TF modtager, ved modelbaseret projektering, 3 modeller, men bruger kun 2 - arkitektmodel og model af tekniske installationer (ikke konstruktionsmodel). De modtager dog både IFC og Revit/AutoCAD til dokumentation eller “as built” og opretter en kopi, som der arbejdes på i driften. Som følge af denne arbejdsgang, bliver der både arbejdet i tegningsmateriale og i LogFM. Dette kan skabe problemer omkring opdatering. For hvis der laves en rettelse det ene sted, skal TF også huske at opdatere det andet sted manuelt. Det er de færreste projekter hvor rådgiverne har kunnet levere projekter med D&V-data på bygningsobjekterne. Aletia har levet op til krav - døregenskaber på driftsdata. Dette var revit-projekt - og som følge heraf blev der afleveret i revit. RW mener at der er en generel problemstilling, omkring hvem der skal taste de specifikke oplysninger ind i modellen. Han mener, at der skal kigges på ydelsesbeskrivelsen, hvor der kun er krav til dokumentation og tegninger. Overførsel af data: De D&V-data som TF modtager fra entreprenøreren i forbindelse med afleveringen overføres ikke direkte til LogFM, men skal vurderes og “manipuleres” før det tastes ind i LogFM. Forstået på den måde at TF har nogle erfaringer med bestemte bygningsdele, som kan være forskellig fra den opfattelse som entreprenører eller producenten har af de samme bygningsdele. Strukturen, af de specifikke produktdatablade som kan anvendes i driften, er dermed en følge af det arbejde TF har lagt i at overføre D&V-data fra afleveringen til LogFM. Fremtiden: TF har et samarbejde med DTU omkring udvikling af et system, der kan rapportere fejlmeldinger via foruddefinerede skabeloner. Det vil gøre fejlmeldingen mere overskuelig og nemmere at planlægge opgaver for TF. Et andet projekt som TF arbejder på er at kunne koble LogFM med CTS-systemerne i de enkelte bygninger, så driftspersonellet kan styre CTS-funktionerne hjemmefra (ved aften- og weekendvagter). Ved kobling af LogFM og CTS-systemerne kan der også nemmere udføres måling af energiforbruget for de enkelte instituter. TF vil også gerne kunne håndtere udbud af regøring i LogFM. 131 RW ser en mulighed for at rådgiverne udnytter muligheden for at koblebygningsobjekterne i modellerne til en URL-adresse. 132 11.2 Bilag B: Referat af interview med Slots- og EjendomsStyrelsen Dato for interview: d. 24.10.2011 Til stede (pr. telefon): Lasse Møller, Aalborg universitet, Projektleder, Clars Danvold (CD), Slots- og ejendomsstyrelsen (SES) Driften af Bygninger: SES har fortrinsvis renoveringsopgaver som deres byggeopgaver, hvilket har indflydelse på de krav, de er underlagt, samt de beslutninger de foretager sig vedrørende digitalisering. SES er både byg- og driftsherre, hvilket betyder at der er økonomisk sammenhæng mellem kravene og de konsekvenser kravene har for driften. Der er ligesom mange andre offentlige bygherrer lavet rammeaftaler med rådgivere. I denne sammenhæng har SES en bestiller-funktion, hvor de udfører tilsyn på deres bygninger, hvilket fører til udbud på de opgaver der skal udføres. Systemer: Det første incitament, som SES havde for at indføre et system, der kunne styre FM-opgaver, var at kunne styre energiudgifterne bedre end tidligere. Til dette formål blev der indkøbt et system, der hedder Ryhti, gennem et finsk ingeniørfirma, der hedder Oluf Granlund. Dette system er sidenhen blevet en større del af SES’s arbejdsgange. Systemet håndterer bygningsdele, der er struktureret efter DBK. CD udtaler, at DBK anvendes som en “knagerække” til at skabe overblik og systematik, selvom det ikke er færdigudviklet. Et af de nyere områder som der fokuseres på hos SES er at skabe større overblik over arealer. SES administrerer en del nyere bygninger især i København, hvor der foreligger tegninger. I disse tilfælde er det nemt at opmåle arealer. SES administrerer dog fortrinsvis ældre bygninger, hvor der ikke findes digitale tegninger. Her kan det være problematisk at få overblik over arealer, men SES er i gang med at skanne tegninger ind og bearbejde dem, så de kan målsættes. I denne sammenhæng anvendes der Dalux FM til at administrere arealerne. Den centrale applikation for SES er dog Navision, som er deres økonomistyringsværktøj. De andre applikation bruges til at planlægge opgaver og skabe overblik. 133 Afleveringen: I forhold til afleveringen har det været vigtigt for SES at få defineret hvilke bygningsdele, som de har behov for at modtage D&V-data om. Det er dog ikke alle projekter, hvor intensionerne svarer til virkeligheden. Der er mange områder, som skal behandles i en byggesag, og for projektlederne er digitaliseringen endnu et krav af mange, der stilles i en travl hverdag, hvor der også skal holdes på tid og økonomi. Dertil er der mange opgaver, der er så små, at det ikke giver mening at stille krav til digitalisering. Ved Bygherrekravene i 2007 (IKT-bekendtgørelse 1365) blev der stillet en masse krav, som SES skulle forholde sig til. Der manglede dog kompetencer til at kunne omsætte kravene til praktik. Derfor blev der lavet et forsøg med IDM som et værktøj til at beskrive kravene til aflevering af arealer. Det generelle formål har været at kunne beskrive kravet til data i såvel tegninger som model. CD mener, at det er vigtigt ikke at være for specifik med at stille krav til aflevering. Fx er det problematisk at stille krav om specifikke dataformater som IFC, da det udelukker nogle. Overførsel af data SES lader ikke rådgivere og entreprenører indtaste informationer direkte i deres systemer, da det er besværligt at håndtere nye brugere i systemet. I stedet stiller de krav om at alle bygningsdele afleveres i excelskabelon, som tastes ind i systemet. IDM er et værktøj til at beskrive informationsflowet, men beslutningerne skal stadig tages af aktørerne. Fremtiden: Bygherre skal blive bedre til at stille krav om digitalisering, men rådgivere skal og blive bedre til at rådgive deres bygherre om fordele og muligheder ved øget digitalisering. Der ligger en “kultur-hurdle” i vejen. Man holder sig ofte til det sikre. Der er behov for, at der bliver taget større risiko både fra bygherre og rådgivers side. Problemet er at alle er lidt forvirrede angående BIM og den generelle digitalisering. I forhold til de fremtidige krav om anvendelse af IFC ved aflevering tager SES det stille og roligt. Da de mest har renoveringsopgaver, mener de ikke at de bliver berørt af kravene. CD slutter med at udtale at “BIM er et værktøj - det er bilen vi kører for at komme derhen, hvor vi gerne vil.” 134 11.3 Bilag C: Referat af interview med Dan-Ejendomme a/s Dato for interview: d. 25.10.2011 Til stede: Lasse Møller, Aalborg universitet, Projektleder, Benjamin B. Andersen (BA), Dan-Ejendomme a/s (DE) Organisationen: Benjamin Andersen er projektleder samt CAD-ansvarlig ved DE. Han administrerer en portefølje af ejendomme. Firmaet, Dan-Ejendomme a/s , er administrator for andres ejendomme, og har alle typer ejendomme i deres portefølje. Firmaet er delt op i: • Teknisk afdeling, der er delt op i et investerings- og et foreningssekment • Administrationsafdeling, der ligeledes er delt op i et investerings- og et foreningssekment DE’s kerneforretning er ejendomsadministration: dvs indkrævning af leje og udformning af lejekontrakter. DE har en vision om at yde 360 graders service, hvilket især tiltaler pensionskasserne. Firmaet er involveret i forskellige byggeprojekter. Det drejer sig ofte om bygninger de allerede administrerer, hvor der er behov for tilbygninger eller renoveringer. Dertil har DE deltaget i OPP og OPS projekter. DE virker både som bygherrerådgiver og som projekterende rådgiver ved byggesager indenfor deres eksisterende portefølje. Ved OPP og OPS projekter indgår de i konsortiet som Driftsherren. Driften af Bygninger: Ansvaret for drift og vedligehold ligger hos projektlederen som understøttes af den enkelte vicevært eller bygningsinspektør. Herunder budgetterne for den enkelte bygning. Budgetterne bygger i høj grad på den ansvarlige driftsleders tilstandsvurdering. Vedligeholdelsesdata bruges ikke så ofte, da DE forsøger at planlægge ud fra aktiviteter i stedet for bygningsdele. Derfor bruges der en aktivitetsbaseret tilstandsvurdering, som bygger på “bedste mands bedste bud”. Som i mange andre virksomheder har DE problemer med at overbevise ældre medarbejdere om fordelene ved digitalisering. Ved nye opgaver, som renoveringer og tilbygninger, som DE selv projekterer, modellerer de projektet op i revit. Det starter med at konvertere det relevante tegningsmateriale til en revit-model. Hvis tegningsmaterialet ikke er fyldestgørende, foretages der en opmåling. Bygningerne opmåles manuelt, det er overvejet at 135 anvende en laserskanning, men det er vurderet at det er for stor en udgift i forhold til fordelene ved det. Det er kun ved store gennemgribende renoveringer at hele bygningen modelleres op ellers modelleres kun det relevante område. Systemer: BA udtaler: “Der findes ikke et dansk udviklet FM system, som i tilstrækkelig grad dækker hele vores behov” DE anvender et system der hedder Unik bolig 4 til at administrere bygninger, herunder huslejeopkrævning og drift og vedligehold. Dertil anvender de et system, der hedder Software innovation til dokumenthåndtering og et system, der hedder Adventure DIOS, til opgavehåndtering i driften. Derudover anvender de Office-pakken. Der har været lidt problemer med Adventure DIOS systemet i forbindelse med at få opgaver ud til viceværterne og koordinere opgaver, derfor undersøger DE mulighederne for at håndtere opgaverne på en bedre måde. DE ser på mulighederne i andre systemer. Fx ser de på ArchiBUS til at håndtere opgavestyring og vil anvende det på et pilotprojekt i den nærmeste fremtid. Derudover ser de på CoreFM og Dalux FM. Det er vigtigt at data bliver demokratiseret. Brugerne skal kunne tilgå data - det må ikke bare være de erfarne IT-brugere i driftsorganisationen. Her ser de bl.a. på Dalux Building View. DE arbejder fx med den vejledning alle lejere modtager om deres lejemål, som der kan der være problemer med at holde den opdateret med nye komponenter. BA så gerne at opdateringen af denne kommer til at ske automatisk. Afleveringen: Det er sjældent, at der bliver stillet de store krav til digital aflevering fra bygherres side - det er ofte i OPPprojekter at Dan-Ejendomme a/s kan være med til at definere kravene. De prøver dog at overbevise deres kunder om, at det er en god ide at stille krav til den digitale aflevering. En af de udfordringer, som DE møder ved digitalisering, er problematikken om, hvem der ejer data. DE er begyndt at stille krav omkring digital aflevering - det er dog i sin vorden. En anden generel problematik, som DE står overfor, er, at det er bygherren, der opnår fordelene ved en øget digitalisering, men det er DE, der laver investeringen. Der er en kløft, mellem hvem der laver investeringen, og hvem der høster gevinsten. I de projekter hvor der er digital aflevering, stiller DE krav om D&V-data på de enkelte bygningsdele. Der stilles ikke krav om aflevering af arealer, da det kan skabe problemer omkring, hvordan opmålingen skal foretages. Derfor trækker DE selv arealerne ud af model eller tegninger. Ved aflevering af modeller, er det ofte modeller på niveau 3 eller 4 (bips informationsniveauer) DE gerne vil modtage - de er tilpas detaljerede til at kunne arbejde videre på dem. 136 Overførsel af data Der er en problematik i at stille krav om fx BIM modeller. Det fx et problem at det ikke kan importeres til FM-systemet. I de fleste byggesager vil der tilmed være en eller flere aktører, der ikke anvender 3D. Der er dog nogle byggesager, hvor der modtages revit-modeller til as-built dokumentation. Fremtiden: Fremtiden er ifølge BA at anvende integrerede systemer. Der skal ikke nødvendigvis være en enkelt applikation, der skal håndtere hele FM-processen, men det er vigtigt med en central database, hvor alle informationer bliver opdateret. Der kan man så have forskellige interfaces, der kan tilgå databasen. Hvis man kan skabe en sammenhæng af data på en central database, kan det give strategiske fordele. DE ligger inde med en stor viden om kvadratmeterpriser, D&V ol., men hvis det kunne sammenstilles på en mere dynamisk måde kan det anvendes i business cases ol. Netop gode business cases er vigtige for at overbevise bygherrer om fordelene ved øget digitalisering. BA mener at man skal bruge ideerne fra GIS-verdenen, som er database-baseret. I fremtiden er vigtigt at få endnu bedre overblik over data, herunder at kunne holde styr på arealer og bygninger, samt at kunne anvende data mere dynamisk. Hvis der skal kigges langt ud i fremtiden, så er RFID-tags en interessant mulighed for at kunne koble de fysiske bygningskomponenter til deres digitale bygningsobjekter. 137 11.4 Bilag D: Referat af interview med Steen og Strøm a/s Dato for interview: d. 31.10.2011 Til stede: Lasse Møller, Aalborg universitet, Property Manager, Christian Carlsen (CC), Steen og Strøm A/S (SS) Organisationen: CC er property manager for jylland - og arbejder med optimering af Drift og Vedligehold af centre. SS’s driftsafdeling er delt op i: • en afdeling der står for centerdriften, som igen er delt op i øst og vest. • en afdeling der står for mindre renoveringer og projekter under 25 mio. • en afdeling der står for større projekter over 25 mio. Ved hvert byggeprojekt sidder der en repræsentant fra de forskellige afdelinger i en projektgruppe for at sikre at alle interesser bliver belyst. Afdelingerne er: • Økonomi • Jura • Udvikling • Udlejning • Properties/Teknik • Analyse • Marketing • Commercial Det er udviklingsafdelingen som leder projektet. Byggesagen, Odense City Center, OCC, er organiseret på samme måde. Her er det Per Hald fra udviklingsafdelingen, der er projektleder. CC støtter Fin Chabert, som deltager i projektgruppen fra propertiesafdelingen. Driften af Bygninger: SS har et centralt hovedkontor, hvor det overordnede arbejde planlægges og koordineres, mens den daglige drift varetages af de enkelte centre. For hvert center er der en driftsleder, som styrer nogle driftsfolk. 138 Denne driftsleder er med til at udforme budgetter for dennes center og har også ansvaret for, at det bliver overholdt. CC’s opgave er bl.a. at støtte driftslederne samt at sørge for, at de har det rette fokus på drift og vedligehold. De vigtigste driftsopgaver for centrene er: • Drift og vedligehold af bygninger. • At styre arealudlejning • Holde øje med nye krav fra myndigheder og andre interessenter • At styre energiforbrug og økonomi Der er ikke en måling af, hvordan de enkelte på de enkelte driftsledere “performer”. Der er selvfølgelig en slags måling i form af overholdelse af budgetter, men SS ved at der løbende kommer nye krav, der gør, at budgetterne må ændres. Det er vigtigt hele tiden at optimere på energi forbrug og økonomi. Systemer: I 2001 indgik SS en aftale med CoreFM om at anvende deres FM-applikation. I første omgang var det for at kunne håndtere tegninger, men senere er applikationen også anvendt til at styre drift og vedligehold samt styring af arealer. Baggrunden for at anvende CoreFM var, at det på det tidspunkt blev vurderet til at være det system, der var længst fremme i udviklingen - dertil var det et vigtigt element, at der er en integration med byggeweb, således at informationer nemt kan overføres fra byggeprojekt til drift. SS anvender et system, der hedder Finistra til at styre økonomien. En del af systemet hedder Visma som bruges til at producere regneark. Dette regneark bruges til styring af opgaver ved større renoveringer. Generelt bruges byggeweb til at planlægge arbejdet. CC ser ikke nogen grund til at samle alle funktioner i et system. Der vil altid være systemer, der vil være gode til nogle enkelte dele – et samlet system vil ikke kunne konkurrere mod de specialiserede systemer. CC ser derfor heller ikke nogen grund til at koble CTS systemer med en bygningsmodel eller deres FMsystem. De systemer, der behandler CTS, er specialiserede til dette og vil derfor være bedst egnede. Generelt er det vigtigt at se på hvad der giver værdi. Afleveringen: SS vil gerne modtage D&V-data på de enkelte bygningsdele. Der er vigtig at de produktblade, der afleveres er på den specifikke bygningsdel, og at det ikke er hele produktkataloget, der afleveres. Dertil skal der afleveres en instruktion for den specifikke komponent (fx ventilationsanlæg), som beskriver anvendelsen. Dertil har SS deres egne opmålingsregler, som skal anvendes af entreprenørerne 139 Der anvendes forskellige programmer til at analysere kundestrømme ol. Disse analyser bruges til at kommunikere behov til rådgivere og entreprenører. SS stiller krav om at produktinformationer afleveres i pdf-format, samt at der indtastes de relevante informationer CoreFM. Derudover stiller de krav om at tegninger afleveres i redigerbare dwg-filer. OCC er det første projekt, hvor det forsøges at aflevere i en 3D-model (revit). Dette er dog kun til “as-built” dokumentation. Generelt kræver det et stort engagement fra SS at sikre, at de rigtige D&V-data specificeres og afleveres. Mange rådgivere har ikke så meget erfaring med hvilke D&V-data, der vigtige for BH. Det er ofte bygningsdelslisten der ikke er udfyldt tilfredsstillende. Derfor er SS meget fokuserede på at deltage i hele processen fra projektet start, således at de kan sikre at der er fokus på afleveringen. Det gælder for SS om at modtage den rette information. Det er nogle gange hvor der for lidt information, men der er også tilfælde hvor der er for meget information i forhold hvad der er brug for. Overførsel af data Overførsel af data fra byggeri til drift sker, ved at entreprenørerne indtaster informationerne direkte i CoreFM. I de tilfælde hvor mindre entreprenører ikke har kompetencerne til at løfte denne opgave, er det hovedentreprenørens ansvar at hjælpe underentreprenøren eller taste informationerne ind for ham. SS arbejder på en manual for en standardopgave, der kan danne grundlag for nye opgaver. Fremtiden: CC mener det er vigtigt at der sker en synergi mellem de forskellige opgaver. Der er konstant nye krav fra myndigheder, og fra de norske ejere. Frankrig? Det er vigtigt for SS hele tiden at undersøge udviklingen på markedet for FM-systemer. De bruger de til at presse CoreFM til løbende at udvikle deres system. De kigger i øjeblikket på hvordan interfacet er for de enkelte driftsfolk, så det bliver nemmere at melde opgaver ind til systemet. Det kan fx være tablets og smartphones. Det er generelt vigtigt at sikre brugervenligheden for alle brugere. 140 11.5 Bilag E: Referat af interview med Skanska a/s Dato for interview: d. 02.11.2011 Til stede (pr. telefon): Lasse Møller, Aalborg universitet, Ejendomsudvikler, Ib Kaa (IK), Skanska a/s (SK) Organisationen: Ib Kaa arbejder som ejendomsudvikler for Skanska. Skanska er en global koncern med 52.000 ansatte, der har to afdelinger i Danmark: en asfaltafdeling og en afdeling for erhvervsejendomme. Når Skanska nævnes i den følgende tekst menes der den danske afdeling for erhvervsejendomme. Afdelingen beskæftiger i dag 20 medarbejdere. Driften af Bygninger: Den primære forretning for SK er at købe og udvikle ejendomme for derefter at sælge dem videre. De finder ejendomme, som de mener, der har potentiale ud fra forskellige markedsanalyser. Derefter udvikler de ejendommen – dvs. laver lokalplan i samarbejde med kommunen, bygger en bygning og lejer den ud. Før de begynder at bygge skal 50 % af bygningen dog være udlejet. Når hele bygningen er lejet ud, forsøger de at sælge de den videre, givet at markedssituationen er rigtig. Hvis markedssituationen ikke er rigtig, beholder de ejendommen, til markedet har ændret sig. Det er bl.a. derfor, at SK ejer og administrerer 20.000 m2 kontorer og p-kældre. Systemer: SK har ikke haft deciderede driftssystemer indtil nu. Meget af styringen er foregået gennem excel og de andre office-applikationer. De er dog ved at implementere CoreFM i forbindelse med et projekt, der er ved at blive afleveret. SK har kigget på andre applikationer og gør det stadig, men vurderer at CoreFM på nuværende tidspunkt er det system, der bedst dækker deres behov for håndtering af D&V-data. SK ser derudover på applikationer, der kan håndtere deres arealer. Det er vigtig for SK at have de rigtige arealer i forbindelse med huslejeberegning. De undersøger bl.a. Dalux’s arealhåndtering. Det handler for SK om at finde et system, der passer til deres behov og kompetencer. ArchiBUS er et bedre system til at håndtere BIM-modeller, men det er ikke de udfordringer, som SK står overfor, men måske vil de bruge et lignende system i fremtiden. Det handler lige nu om at finde et system, som alle kan bruge, og kan håndtere det materiale der modtages. 141 Dertil er koblingen mellem byggeweb og CoreFM en ekstra grund til at valget faldt på CoreFM. I Danmark er byggeweb for de fleste synonym med projektweb, og det at der er samme firma, der står bag begge systemer gør at overførslen af data mellem de to bliver nemmere. Afleveringen: I det projekt som SK lige har afleveret stilles der krav om digital aflevering. Det var oprindeligt tanken, at der skulle afleveres direkte i CoreFM, men det viste sig at entreprenørerne ikke havde kompetencerne til at udføre denne opgave. Derfor afleveres der nu gennem byggeweb. Der er ikke stillet specifikke krav til D&V-data, men der er taget udgangspunkt i Ydelsesbeskrivelsen. SK har ikke været klar til at kunne være mere specifik i kravstillelsen. Der er stillet krav om at der afleveres et låst format (fx pdf) og et redigerbart format (fx odf, dwg). Afleveringen omfatter bygningsdelskort, evt. servicekontrakter og tilhørende produktblade. Der har været problemer med at modtage de specifikke produktblade, da entreprenørerne er vant til at aflevere hele produktkataloger. Der har i det hele taget været en del problemer med at overbevise entreprenøren om at afleveringen skulle foregå på en anden måde end den traditionelle. IK mener at det er en naturlig problemstilling: “entreprenøreren har hovedfokus på at bygge et hus og ikke på driften af det” Der er ikke brugt DBK eller SfB til klassifikation af bygningsdele, men SK’s eget system. Der er ikke en kobling mellem CTS og FM-systemet. Det kan måske komme i fremtiden, men det er ikke i fokus lige nu. Dertil fungerer CTS-styringen fint - det er andre områder, der skal fokuseres på lige nu. Overførsel af data: Det er som nævnt ikke lykkes at få entreprenørerne til at taste D&V-data direkte ind i CoreFM. Det er derfor SK, der selv taster dette ind ud fra de bygningsdelskort og produktblade, de modtager. Fremtiden: På kort sigt skal SK være bedre til at stille specifikke krav om D&V-data til deres entreprenører. På længere sigt vil SK gerne kunne arbejde med BIM-modeller i forbindelse med FM. Det burde måske nærmere være et GIS-system, så information om omkringliggende bygninger er med. Det kunne muligvis være Dalux der på længere sigt bliver valgt, hvis de fortsætter udviklingen. Dertil har AutoDesk et spændende program der kan koble CTS og bygningsmodel, så det bliver nemmere at udføre analyser af en bygnings performance. 142 11.6 Bilag F: Referat af interview med Grontmij Dato for interview: d. 07.11.2011 Til stede: Lasse Møller, Aalborg universitet, CAD-koordinator, Johnny Pedersen (JP), Grontmij Organisationen: Hvad er din rolle og din virksomheds rolle i denne byggesag? JP er CAD-koordinator indenfor afdelingen, planning og design og er uddannet bygningskonstruktør. Det er Rasmus der er projektleder for Grontmij på OCC-sagen og JP har foreløbig en støttefunktion, men vil senere deltage i sagen på fuld tid. Grontmij står for ingeniørydelserne i forbindelse med projektet. Det er Moe og Brødsgaard der er projekteringsleder men Grontmij er hovedprojekterendeog står derfor bl.a. for at koordinere den digitale aflevering i samarbejde med de andre rådgivere. Afleveringen generelt: Oplever i ofte at der stilles krav til digital af levering i de sager i er involveret i? Afleveringen foregår traditionelt ved at der afleveres en del papkasser til bygherren/driftsherren, og foregår stadig i mange sager. Der er dog en del sager hvor der afleveres en cd med projektmateriale. JP anslår at det foregår i ca. halvdelen af sagerne. Det er de færreste bygherrer/driftsherrer der ved hvad de vil have, hvilket resulterer i at der er mange sager hvor der ikke stillet krav til afleveringen. Hvordan sikrer i at de rigtige driftsdata bliver specificeret? De sager hvor der stilles krav er det ofte ydelsesbeskrivelsen der henvises til. Der er mange bygherrer/driftsherrer der ikke kender til standarderne fra byggeriet og derfor ikke ved hvordan de skal stille krav til anvendelsen af dem. 143 Afleveringen i denne sag: Hvordan har afleveringen foregået i denne byggesag? Der er i OCC-sagen valgt at bruge CoreFM som driftssystem. Der er dog ikke den kobling mellem byggeweb og CoreFM som man kunne ønske sig og derfor skal informationerne tastes ind i systemet. Der forelægger en generel ydelsesspecifikation. Hvordan har i arbejdet med at gøre den konkret for dette projekt? Grontmij har en driftsafdeling der er koblet på projektet og arbejder med kravspecifikationen. Det er dog stadig tidligt i projektet og derfor er processen ikke nået så langt endnu. Bliver det skelnet mellem ”as-built”-materiale og materiale der er tilpasset til bygherren? Det er som regel kun ”as-built”-informationer der bliver afleveret. Det kan godt lade sig gøre at aflevere information der er ”tilpasset” til driftsherren, men det kræver at der er et krav om det fra driftsherren. Hvordan sikrer i at entreprenørerne opfylder kravene om digital aflevering? Entreprenørerne taster selv informationerne ind i CoreFM, evt. med støtte fra folkene fra CoreFM. Det sker formodentligt ved at de har en pdf med informationer som de aflæser og taster ind eller ”copy/paster” fra filen. Systemer: Hvordan opbevares driftsdata igennem en byggesag? Driftsdata opbevares typisk på projektweb hvis det er en del af aftalen i byggesagen. Det kan enten være som excel-skemaer eller pdf-filer. Det er dog tanken at entreprenørerne skal taste D&V-informationerne ind i CoreFM løbende, og dermed er det her at informationerne opvares under udførelsen. Stilles der krav om at der skal anvendes en model i byggesager? Rådgiverne arbejder med modeller i henhold til IKT-aftalen, så ja, det er besluttet at der skal arbejdes med modeller i dette projekt. Det skal forsøges at anvende DBK-koder på objekter i dette projekt. JP ser et potentiale i dette. Hvis man kan få kodningen til at lykkedes på en god måde er det muligt at koble objekterne til en database fordi de eksisterer i en struktureret form. Det kunne fx være en database med D&V-data. Det vil også afhjælpe problemerne med at revit-filer har en tendens til at blive for ”tunge”. Der er i kravspecifikationen nævnt tegninger en del gange. Stiller SS krav om at der anvendes modeller i byggesagen? 144 Overførsel af data Hvordan styrer i overførelsen af data fra byggeprojekt til drift? Ingeniørerne afleverer projektmaterialet til bygherren efter rådgiver aftalen. Entreprenørerne skal taste informationerne direkte ind i CoreFM. Grontmij har en driftsafdeling der står for meget af arbejdet omkring driften og de er lige gået i gang med at kigge på kravspecifikationen. Fremtiden: Hvordan ser du fremtiden for den digitale aflevering? I fremtiden bør man kunne trække informationer fra modeller. Generelt skal der ske i større grad af automatisering hvis man kan fjerne mange af de manuelle arbejdsgange kan man reducere antallet af fejl. Ved at anvende en model kan man koble den til en til en database der kan indeholde informationer om alle de data der er behov for, som D&V, brand og energi. 145 11.7 Bilag G: Referat af interview med Aarhus arkitekterne Dato for interview: d. 23.11.2011 Til stede: Lasse Møller, Aalborg universitet, Arkitekt, Søren Sti Andersen (SA), Aarhus arkitekterne (AA) Organisationen: Hvad er din rolle og din virksomheds rolle i denne byggesag? SA er uddannet arkitekt og er ansat hos Aarhus arkitekterne hvor han har en stilling der er delt mellem 75% projektering og 25% undervisning i BIM. AA er den projekterende arkitekt på projektet. Grontmij har IKT-ledelsen i henhold til IKT-aftalen, men de to firmaer arbejder sammen om leve op til de IKT-krav der er stillet i projektet. Afleveringen generelt: Oplever i ofte at der stilles krav til digital af levering i de sager i er involveret i? Det er ofte ikke så specifikke krav der stilles til aflevering af D&V-informationer. Det er typisk et krav at det skal afleveres men derudover er der ikke specificeret mere. Der er ikke meget fokus på digital aflevering og drift. Der er flere elementer der skal tages hensyn til i en byggesag som økonomi og æstetik. Hvordan sikrer i at de rigtige driftsdata bliver specificeret? Det der er behov er specifikke produktblade på de bygningsdele der bliver afleveret. Fx for køkkener og vægge vil man ikke have hele produktkataloget, men den specifikke vejledning til det specifikke produkt. Afleveringen i denne sag: Hvordan skal afleveringen foregå i denne byggesag? Denne byggesag skal foregå digitalt. Der er et arbejde med at optimere AA så vi bedre kan leve op til kravene til digitalt byggeri hvilket bl.a. omfatter DBK, projektweb, digitalt udbud og licitation og digital aflevering. Det sidste punkt er der hvor AA har indgået samarbejde med forfatteren netop for at kortlægge hvad der skal gøre i forbindelse med digital aflevering. 146 AA har selv arbejdet med nogle af de andre dele af digitalt byggeri. Fx har SA arbejdet med at skabe families i Revit med DBK-koder som kan anvendes på tværs af projekter. Bliver det skelnet mellem ”as-built”-materiale og materiale der er tilpasset til bygherren? Der sker som regel ikke den store tilpasning af projektmaterialet. Det opdateres til as-built og afleveres. Det er selvfølgeligt klart at hvis bygherren har specifikke ønsker til udformning af brandplaner og lign. så kan hav få dette. Dette foregår i henhold til kontrakten. Hvordan sikrer i at entreprenørerne opfylder kravene om digital aflevering? Dette er en af problemstillingerne ved digital aflevering. Fra rådgivers side er det ikke muligt at definere specifikke bygningsdele da entreprenørerne skal have mulighed for at kunne vælge produkter. Det som rådgiverne definerer er kravene til bygningsdelene, hvilket kan være problematisk i forhold til modellen. Systemer: Hvordan opbevares driftsdata igennem en byggesag? Det er ofte excel der anvendes til at skabe overblik over byggesagen. Stilles der krav om at der skal anvendes en model i byggesager? Der skal anvendes modeller i projektet i henhold til IKT-aftalen. AA har ikke en lang erfaring med brugen af modeller i projekteringen, derfor bliver det en godt for tegnestue at drage nogle erfaringer fra dette projekt, som kan anvendes på sigt. Overførsel af data: Hvordan styrer i overførelsen af data fra byggeprojekt til drift? Det er endnu ikke fastlagt hvordan afleveringen skal forløbe. Det er planlagt at entreprenørerne skal aflevere ved indtastning i CoreFM, men det kan ende med, at der afleveres i excel-skemaer, hvor informationerne overføres fra. Hvor ser du de største udfordringer i forhold til den digitale aflevering? Der er et sammenstød mellem arkitekter og BIM-folk. Det er ofte meget præcise data der er brug for i en bygningsmodel, men arkitekter også fokuserer meget i udefinerbare værdier som æstetik og følelser. De mener ikke at det er alt der kan koges ned til konkrete data. 147 Fremtiden: Hvordan ser du fremtiden for den digitale aflevering? Det er meget vigtigt for driften med digital aflevering. Byggesagen varer måske 3 år, mens driften af bygningen varer op til 100 år. Dertil ligger kun 20% af udgifterne i byggefasen mens de resterende 80% ligger i driften. Derfor burde der være et stort enticement for bygherre for at al aflevering skal ske digitalt. I fremtiden vil aflevering forhåbentligt også ske mere automatisk. SA regner dog med at der foreligger et afklaringsarbejde på 5-10 år hvor der blandt andet skal gøres erfaringer samt arbejdes med ydelsesbeskrivelsen og aftalegrundlaget. 148 11.8 Bilag H: Referat af interview med Moe og Brødsgaard a/s Dato for interview: d. 29.11.2011 Til stede: Lasse Møller, Aalborg universitet, Bygherrerådgiver, Lars Boch, Moe og Brødsgaard A/S (MB) Organisationen: Hvad er din rolle og din virksomheds rolle i denne byggesag? Lars Boch er bygherrerådgiver for det rådgivende ingeniørfirma, Moe og Brødsgaard A/S. Han har en uddannelsesmæssig baggrund som teknikumingeniør og konstruktionsingeniør. Dertil har han erfaring fra entreprenørbranchen og fra bygherrebranchen. Moe og Brødsgaard er i byggesagen Odense City Center både bygherrerådgiver og projektleder for rådgiverne. Det er ikke en uvant rolle for MB, og det ses i mange sager de påtager sig begge roller. Afleveringen i denne sag: Hvordan har afleveringen foregået i denne byggesag? Bygherren, Steen og Strøm (SS), har et digitalt system som kører gennem byggeweb som hedder coreFM, som de anvender til at styre alle deres centre. Derfor lægger SS stor vægt på at al aflevering skal kunne bruges i deres FM-system, dvs. i det korrekte format og på en måde så det er til at bruge. Alle komponenter skal registreres i deres system. SS har udformet en kravspecifikation der skal være med til at sikre at de rigtige data bliver afleveret. Der er i byggesagen også udpeget en facilitator der skal sørge for at den digitale aflevering sker efter de foreliggende aftaler. I dette tilfælde er det Grontmij der har denne opgave. Det skal sikre at centeret kan køre fra dag 1, og at man ikke sidder med en cd-rom eller lignende og skal starte forfra. Derfor afleverer man i løbende i CoreFM. Det er vigtig at have udpeget en facilitator for at sikre af den digitale aflevering forløber som det er tiltænkt. Der forelægger en generel ydelsesspecifikation. Hvordan har i arbejdet med at gøre den konkret for dette projekt? Byggesagen er indtil videre kun i dispositionsfasen, så der er ikke gået i dybden med at gøre kravspecifikationen specifik endnu. Der har været talt op hvilke tiltag og fokuspunkter parterne skal i gang med og hvordan projektet og de enkelte bygningsdele skal navngives. Der er valgt en dansk standard som kan bruges under projektering og udførsel og som også kan anvendes i driften i CoreFM. 149 Det er en fælles opgave for rådgiverne at gøre kravspecifikationen projektspecifik, men det overordnede ansvar ligger hos projekteringsledelsen (Moe og Brødsgaard). Det er ingeniørens opgave at komme med et forslag til hvordan de enkelte bygningsdele skal beskrives, og så er det op til bygherren at godkende det. Det er byggeprogrammet der beskriver de forskellige ydelser og kravene til hvordan bygningen teknisk set skal strikkes sammen. Heri er der også en beskrivelse af de niveauer af information, som de enkelte bygningsdele skal leveres i. Byggeprogrammet er ved at blive færdiggjort nu efter at dispositionsforslaget er færdiggjort. Bliver det skelnet mellem ”as-built”-materiale og materiale der er tilpasset til bygherren? Bygherren vil ikke have mange ringmapper med projektmateriale på hylden – det er uoverskueligt og svært for forskellige folk at finde det de skal bruge. Det er derfor meget bedre med digital adgang til tegninger og lignende. Det der sker i denne sag er netop at man tilpasser noget materiale til bygherren. Fx ”renses” tegninger og opdateres med informationer om hvor de relevante komponenter befinder sig. Det er ikke muligt på trykte tegninger, men ved digitale tegninger har man en slags stifinder der kan vise hvor tingene er. Hvordan sikrer i at entreprenørerne opfylder kravene om digital aflevering? Som bygherrerådgiver er det vigtigt for MB at sikre sig at entreprenørerne har en organisation der kan løse kravene om digital aflevering. Hvis de ikke kan løfte opgaven er MB nød til at gå ind og hjælpe dem. Det vil være et kriterium for udvælgelsen at den enkelte entreprenør kan aflevere digitalt, men hvordan specifikt kommer til at foregå er ikke løst endnu. Afleveringen generelt: Er det ofte at i oplever at der stilles krav til digital af levering i de sager i er involveret i? I komplekse byggerier som storcentre, er der stor fokus på de udgifter der er i forbindelse med driften, fx til energi, og derfor er der et stort behov for FM-systemer til at styre dette. Generelt er det i komplekse byggerier hvor der oftest stilles krav, hvilket hænger sammen med at der er en driftsmæssig fordel at hente. Hvordan sikrer i at de rigtige driftsdata bliver specificeret? Den part der har ansvaret med at overdrage den digitale aflevering udfører nogle kontroller af projektmaterialet, fx kollisions- og konsistenskontroller. De sender så besked om evt. fejl og mangler den relevante aktør. Det vil altid være nogle ting som ikke er helt som det skal være, men det er en proces, hvor man løbende retter op på projektet. 150 Systemer: Hvordan opbevares driftsdata igennem en byggesag? Der anvendes et projektweb til opbevare de digitale data, hvor man anvender brugerrettigheder til at styre at de rette parter har adgang til de rette informationer. Dette anvendes også i forbindelse med digitalt udbud, så entreprenørerne kan hente de informationer de skal bruge. Stilles der krav om at der skal anvendes en model i byggesager? Det er vurdering i den enkelte sager om der stilles krav til anvendelse af modeller. Det er noget der skal give værdi for projektet. Det er også et spørgsmål og rådgiverne har kompetencerne til at anvende modeller. Der er i kravspecifikationen nævnt tegninger en del gange. Stiller SS krav om at der anvendes modeller i byggesagen? Der foreligger, ud over kravspecifikationen, et aftalegrundlag der beskriver hvilke krav der er til projektmateriale. Dertil skal parterne løbende holde sig opdateret med kommunikationen i byggesagen om rettelser og lignende. Det er i aftalegrundlaget stillet krav om at der afleveres en ”as-built”-model. Det er også her defineret at modellen er bygherrens og ikke rådgiverens, så der ikke opstår juridiske problemstillinger på et senere tidspunkt. Det er vigtig for at kunne arbejde videre med senere tilbygninger og renoveringer. Overførsel af data Hvordan styrer i overførelsen af data fra byggeprojekt til drift? Det kommer an på hvad bygherren ønsker. I denne sag har bygherren et tæt samarbejde med CoreFM, som skal administrere en del af det. MB vil udføre en kvalitetssikring på overførelsen af data. Er det din oplevelse at det lykkedes at overføre informationer til CoreFM på en tilfredsstillende måde? I mange byggesager er der behov for at entreprenørerne bliver støttet. Der er ikke to parter der indtaster på helt den samme måde så der er behov for at der er nogen der skaber en form for konvergens, og sikre tingene taster data ind på den rigtige måde. Det sikre at driftsfolkene kan anvende det i sidste ende. Hvor ser du de største udfordringer i forhold til den digitale aflevering? Det er udfordringer ved at sikre at ændringer når frem til de rigtige parter. Fx at ændringer hos entreprenører kommunikeres videre til ingeniører. Det er utroligt vigtigt at ”as-built”-modellen bliver opdateret med de helt rigtige komponenter. 151 Fremtiden: Hvordan ser du fremtiden for den digitale aflevering? Det er fremtiden med digital aflevering. Det er vigtigt at det bliver brugt i flere sager og at der kommer nogle standarder for hvordan det skal gøres. Det kræver så at der er flere der får øjnene op for fordelene ved digital aflevering. Især dem der bruger mange ressourcer på energi og driften, da det er her de største fordele ligger. 152 11.9 Bilag I: Referat af interview med MT Højgaard a/s Dato for interview: d. 15.12.2011 Til stede: Lasse Møller, Aalborg universitet, Byggeleder, Susan Yding-Sørensen (SY), MT Højgaard (MTH) Organisationen: Hvad er din rolle i virksomheden? Susan Yding-Sørensen er uddannet konstruktionsingeniør og arbejder som entreprise-/byggeleder ved MT Højgaard. Hun arbejder på nuværende tidspunkt med opførelsen af bygningerne i Light House-projektet på Aarhus Havn. Hvad er dit firma’s rolle i dette projekt? MT Højgaard er totalentreprenør på dette projekt og arbejder som oftest som totalentreprenør eller hovedentreprenør. Afleveringen: Hvor stor fokus har i på den fremtidige drift af de byggesager i er involveret i? Der udformes en afleveringsmatrice som er en drejebog for hvordan afleveringen skal foregå. Dertil udformes der beboermapper hvor der er en beskrivelse af vedligehold for de bygningsdele der findes i lejligheden. Drejebogen udformes på baggrund af udbudsmaterialet. Det er en meget udførlig beskrivelse af alt hvad der afleveres. Herunder er der beskrevet alle de specifikke tests der skal foretages i forbindelse med byggeriet. Hvad gør i for at sikre at de rigtige D&V-data bliver afleveret til bygherren? Her anvendes drejebogen. Hver entrepriseleder har ansvar for at styre et antal entrepriser og denne gennemgås systematisk. Der anvendes SfB-systemet til at klassifisere bygningsdelene og det hele samles i et excel-ark hvor informationerne er struktureret ens. Dertil hører der de specifikke produktblade. For de bygningsdele der er særligt tekniske foretages der en gennemgang med den kommende vicevært for at sikre at han forstår hvor bygningen skal drives. Hvor stort fokus er der fra bygherrens side på at stille specifikke krav til afleveringen af informationer? 153 Det er meget forskelligt fra bygherre til bygherre. SY har lige deltaget i et projekt for Aarhus kommune, hvor de var meget specifikke. Det er generelt vigtigt at få en god snak fra projektstart om hvad der er af forventninger til afleveringen af informationer. Der kan fx være krav om at der skal afleveres D&V- informationer på alt, men der er det vigtigt at finde ud af hvad det egentligt er der menes. Hvordan skelner i mellem “as-built” og “tilpasset til bygherren”? Driftspesonellet skal selvfølgelig have nogle planer af flugtveje ol. Det er dog ofte rådgiverne der udformer denne form for materiale. Det kommer igen an på hvad der står i udbudsmaterialet, hvad der skal leveres til bygherren. Det er vigtig med en forventningsafstemning med bygherren. Der har fx lige været en sag hvor bygherren var meget interesseret i at få as-built tegningerne så hurtigt som muligt pga. tidligere erfaringer med at det har været besværligt at få fat i tegningerne. Hvis man ved hvad der er vigtigt for bygherren så er det nemmere at leve op til dennes forventninger og dermed opleves sagen positiv for alle parter. Bearbejder i projektmaterialet inden det afleveres? MTH arbejder ikke i projektmaterialet. Det er et spørgsmål om ansvar, og tegningerne er rådgivernes ansvar. MTH kan selvfølgelig komme med kommentarer ol. Har i arbejdet med modelbaserede projekter? SY har ikke arbejdet med projekter hvor der anvendt modeller. MTH er i gang med et BIM-projekt på Moesgaard museum, hvor der er mange arbejdsgange der bliver nemmere, men det er stadig på et ”viewer”niveau hvor der ikke sker bearbejdning af modellen fra entreprenørens side. Hvordan er jeres rolle i forhold til andre entreprenører? Materialet samles i excel og pdf formater. Der er en person fra MTH der samler alt data i en samlet mappe, som brændes på en cd-rom og afleveres til bygherren. Der er også stadig sager hvor der afleveres på papir, men det bliver færre og færre. MTH samler al information fra underentreprenørerne. Den person fra MTH der samler informationerne sørger for at have en dialog med underentreprenørerne for at sikre at der afleveres korrekt. Der gennemgås i samme omgang også KS-mapperne fra hver entreprenør. Systemer: Hvilke systemer anvender i til at styre afleveringen af D&V-data? Det er en stor opgave at styre informationerne der skal afleveres. Der anvendes et excel-ark hvor der er mange informationer og det kan blive meget uoverskueligt, men SfB-nr hjælper med gøre det overskueligt da man tvinges til at gennemgå hele byggeriet. Når først bygningsdelene er specificeret er det spørgsmål 154 om at opdatere skemaet løbende når dele af byggeriet afleveres. Det kan være et kæmpe arbejde med at rykke entreprenørerne for informationer, så det vigtigt hele tiden at være opmærksom på afleveringen. Afleveringen af informationer er ikke det som entreprenørerne har fokus på, de er mere koncentrerede om at bygge. Ved at forklare dem konsekvenserne (ift. produktansvar) af en manglende vejledning til D&V af deres bygningsdele eller materialer, kan de dog se betydningen af aflevering af informationer af D&V. MTH anvender også et system til at håndtere fejl og mangler i byggeriet der hedder Digitjek. Det hjælper dem med at holde styr på fejl og mangler gennem byggeriet, hvilket gør at afleveringen kan ske hurtigere. Bruger i en model til at opbevare data eller udvekse data fra? Der er ikke anvendt modeller i de sager som SY har været involveret i. Overførsel af data Hvordan overfører i data fra projekt til til drift? I denne byggesag (Light House) skal der afleveres på en cd-rom. SY har deltaget i byggesager hvor der er anvendt forskellige former for projektweb, men ikke byggeweb. I den sidste sag hun deltog i for Aarhus kommune, skulle der afleveres i ”container” som er et system hvor al information for kommunen ligger. Der var dog problemer med at organiseringen og struktureringen af de mapper som MTH skulle aflevere i. Da MTH derefter kontaktede Aarhus kommune for at høre hvad de skulle gøre med det klargjorte afleveringsmateriale, aftalte man at MTH bare skulle aflevere de cd-rom’er hvor materialet lå og så lagde Aarhus kommune selv materialet ind i systemet. Der er meget forskelligt om der anvendes projektweb. Der er stadig byggesager hvor der afleveres traditionelt på papir, mens der er i andre sager afleveres digitalt på enten cd-rom eller gennem projektweb. I nogle sager anvendes projektweb til tegninger og andre gange også til referater og lignende. I Light Houseprojektet anvendes der et projekthotel til tegninger, hvilket sparer en del tid og penge ift. tryk af tegninger. Fremtiden: Hvordan ser du afleveringen kan foregå i fremtiden (se gerne 5-10 år frem)? Der er et stort potentialet for at digitalisere afleveringen. De fleste viceværter sidder alligevel foran en computer, så det giver god mening at aflevere materialet digitalt. Viceværten arbejder alligevel med computeren og styrer mange af bygningssystemerne. I forhold til MTH så er alle digitale værktøjer der kan spare tid meget interessante. Der er meget papir der kan spares væk. ”Jo mere digitalt man kan arbejde jo bedre – hvis det er programmer der virker.” Det har været lidt problemer med at man i MTH har prøvet nogle programmer der ikke har virket godt nok. 155
© Copyright 2024