Implementering af IKT-bekendtgørelserne i den daglige drift ved hjælp af driftssystemer

Transkript

1 Bygningskonstruktøruddannelsen Implementering af IKT-bekendtgørelserne i den daglige drift ved hjælp af driftssystemer 7. semester speciale Navn: Dennis Bønnelykke Christensen Vejleder: Henrik Windbirk Skole: VIA University College, Aarhus

2

3 Forord Specialet er udarbejdet i forbindelse med 7. semester pensum på bygningskonstruktøruddannelsen. Dette speciale omfatter bygherrens udfordringer og muligheder i henhold til IKT-bekendtgørelsen, hvor der vil blive fokuseret på, hvordan drift og vedligehold bliver effektiviseret og digitaliseret. Specialet skal belyse, hvordan drift og vedligehold kan blive effektiviseret igennem forskellige værktøjer. Det er vigtigt at forstå, hvilken effekt et velfungerende driftssystem har ikke kun for bygherren men også for alle de øvrige parter i byggeriet. For at understøtte det teoretiske med det praktiske vil specialet bl.a. anvende informationer fra et udvalg af relevante aktører indenfor dette område. Specialet vil starte med at tage udgangspunkt i IKT-bekendtgørelserne, hvorefter der vil blive lagt fokus på, hvilke udspring bekendtgørelserne har haft ved at se på, hvordan kravene bliver understøttet og overholdt optimalt af driftssystemer. Emnet er meget aktuelt, da hele verden er mere eller mindre digitaliseret, hvorfor virksomheder konstant bliver udfordret både i forhold til nye krav men også i forhold til, hvordan de sikrer sig den mest effektiviserede proces, der stemmer overens med alle aspekter i forbindelse med byggeriet og efterfølgende (før-nu-efter). Det har været vigtigt at skabe det fulde overblik over, hvordan driftssystemer faktisk fungerer i praksis i forhold til at kunne påvise et oprigtigt billede af de udfordringer og muligheder det skaber for virksomheder i dag. Grobunden for de praktiske informationer fremgår af Arbejdernes Andels Boligforening, hvortil der skal lyde en særlig tak for indblikket i deres drift og vedligehold. Derudover skal Mikkel Leth Gregersen fra NTI CAD Center og Birgitte Nissen have en stor tak for hhv. at give et indblik i, hvad Mdoc FM kan bidrage med i driftsorganisationer og sætte mig ind i, hvordan de kører deres drift og vedligehold i Region Midtjylland. Til slut vil jeg gerne takke min studievejleder Henrik Windbirk for en god dialog vedrørende specialet. 2

4 Abstract This thesis is concerned with the demands of the IKT-announcements in with the owner has to stand position in connection to the day-to-day running and maintenance. The main purpose of the paper is to create a greater picture of how larger organizations can increase efficiency and affectivity but at the same time both gains a higher level of quality and diminishing costs. The thesis will try to uncover these different tools like several operating systems, and show how they work; both in theory and in practice. Arbejdernes Andels Boligforening (AAB) will be a main point of which practical information will be retrieved in this way, it ensures that the reader obtains the best possible understanding of how these tools works out in the real world. Furthermore, the paper examines; - The intentions behind the IKT-announcements and how organizations fulfill these demands by operating systems. - Opportunities and limits by the use of the operating system Mdoc FM. - How to implement object-based building models within the operating system; disadvantages and advantages. - The impact on AAB of the implementation of the operating system Mdoc FM. In order to analyze and get a proper examination, it has been of great importance to remain objective and gain reliable sources in order to retrieve the most truthful picture of the reality. The theoretical base is within the IKT-announcement and different literature concerning, among other thing, Facility Management. Additionally, interviews have been made of several persons, which have great significance for this subject. By use of this kind of sources, it becomes possible to gain a higher level of both internal and external validity throughout the thesis. To understand and get the optimal experience of this paper, it is relevant to understand the structure. It will take the reader through a journey, where there will be build more and more depth to increase the understanding and make the optimal possibility for the reader to make interpretation of the subject based on a truth base. Through the analysis, it has become clear that the IKT-announcement have been building blocks to a higher standard and pushed the digitalization forward within the building branch by use of customized operating systems. Furthermore, these systems have enabled organizations to a more efficient and effective working environment both within the organization and between partners. 3

5 Despite of the advantages mentioned, it is important to remember that there are some limitation and obstacles in regards to implementing an operating system. For instance, it is not yet possible to retrieve price data, and there is a lot of work for the organization to go from non-operating system to a fully supporting object-based building modeling system. 4

6 Indholdsfortegnelse Billedliste Indledning Problemformuleringsspørgsmål Afgrænsning Valg af teoretisk grundlag og kilder Valg af metode og empiri Videnskabsteoretisk tilgang Rapportens struktur og argumentation IKT-bekendtgørelserne Baggrund IKT-bekendtgørelsernes formål Kort beskrivelse af paragrafferne i IKT-bekendtgørelsen Delkonklusion IKT implementeret i virksomheden Styringssystemer Facilities Management (FM) Computer-Aided Facilites Management (CAFM) Delkonklusion Driftssystemer Hvad kendetegner et driftssystem Generelt om driftssystemet MdocFM Bag om Mdoc FM s udvikling Delkonklusion Objektbaseret bygningsmodellering (BIM) Revit Architecture IFC (Industry Foundation Classes) Fremtiden Et mere offentligt perspektiv Delkonklusion Konklusion Metodekritik Kildeliste Bilagsoversigt

7 Billedliste Figur 1 - Den videnskabelige model (Andersen 2008 s. 25) Figur 2 - FM-funktionen, FM-leverancer og virksomhedens kernefunktioner (Anker Jensen, Håndbog i facilities management, 2011, s. 14) Figur 3 - FM i relation til virksomhedens hovedelementer (Anker Jensen, Håndbog i facilities management, 2011, s. 12) Figur 4 - Mdoc FM brugerflade udlånt af AAB jvf. bilag

8 1. Indledning Som en del af det afsluttende 7. semesters pensum på bygningskonstruktøruddannelsen, har jeg udarbejdet mit speciale. Indholdet af specialet er valgt pga. egen interesse for emnet, samt at det har faglig relevans inden for byggebranchen. Hovedemnet i specialet vil omhandle de nye IKT-bekendtgørelser og hvordan de integreres i den daglige drift ved hjælp af driftssystemer. Jeg har valgt at arbejde med dette, da jeg på mit 6. semester var i praktik hos Arbejdernes Andels Boligforening, hvorfra jeg fik smag for brugen af Facility Management systemer. De har været i gang med at implementere et driftssystem, der skal kunne give overblik over alle deres afdelinger samt på lejemålsniveau i boligforeningen. Dette gøres ved hjælp af de objektbaserede bygningsmodeller, som de modtager i forbindelse med IKT-støttede byggerier. Det spændende ved dette er, hvordan de ny krav i IKT-bekendtgørelserne indarbejdes i den daglige drift samt hvilke informationer, der er nødvendige for at både bygherren og driftsherren kan bruge disse til den efterfølgende drift og vedligehold. Derfor vil det blive undersøgt, hvorvidt der findes driftssystemer, der kan anvende informationerne som leveres i forbindelse med aflevering af byggeriet og hvordan de indarbejdes. Dette gøres for både at få indblik i, hvordan IKT-bekendtgørelserne har haft indflydelse på det generelle byggeri, men også hvordan de er med til at presse udviklingen indenfor et mere digitaliseret kommunikationsniveau mellem byggeriets parter. Generelt set må man indrømme, at den efterfølgende drift og vedligehold af bygninger har været overset i forhold til projekteringsfasen og udførelsesfasen. Rent økonomisk er driftsfasen den dyreste, hvorfor det derfor kunne være interessant at undersøge, hvilke muligheder der er indenfor drift og vedligeholdelsesfasen. Det undersøges, hvordan virksomheder (specielt med henblik på AAB) kan effektivisere deres vidensdeling samt få et bedre data-flow, som kan skabe bedre muligheder indenfor drift og vedligehold. Specialet skal anses som en undersøgelse, der tager udgangspunkt i aktuelle problemstillinger iht. drift og vedligehold lige fra de begrænsninger og muligheder IKT-bekendtgørelserne sætter til, hvordan disse redskaber er med til at skabe fremtiden med endnu bedre værktøjer. Det er en rapport, der henvender sig til andre studerende samt fagfolk med interesse indenfor optimering af arbejdsprocessen i forbindelse med drift og vedligehold. I større træk omhandler specialet optimeringen og effektivisering af alle faser; både før byggeriet, under byggeriet og efter byggeriet er færdigbygget. 7

9 1.1 Problemformuleringsspørgsmål Specialet er, som nævnt tidligere, bygget på ønsket om at opnå en bredere viden om, hvordan virksomheder kan optimere alle byggeriets faser gennem forskellige værktøjer, der alle understøtter IKT-bekendtgørelserne. Heraf udspringer følgende problemformulering: Hvilke krav skal bygherre tage stilling til i forbindelse med de nye IKT-bekendtgørelser og kan disse integreres i den daglige drift og vedligehold ved hjælp af driftssystemer? For at opnå det optimale på den givne problemstilling, er der dannet underemner for at skabe overblik og danne det bedst mulige fundament for undersøgelsen. - IKT-bekendtgørelsernes baggrund og deres formål i forhold til bygherren samt fokus på, hvordan de kan blive implementeret gennem driftssystemer. - Driftssystemer som redskaber til at fremme og effektivisere vedligehold. - Analysere hvordan driftssystemet Mdoc FM fungerer som driftssystem - herunder funktioner, muligheder og begrænsninger. - Belyse hvilke programmer der understøtter driftssystemet i forbindelse med objektbaserede bygningsmodeller, og hvordan har det indflydelse på den overordnede drift og vedligehold. - Påvise driftssystemets indflydelse i praksis med AAB som bygherre vha. interviews fra udvalgte aktører i dette specifikke felt. - Danne sammenligning af håndtering af IKT-kravene mellem det almene byggeri og offentlige byggeri. 1.2 Afgrænsning Specialet tager udgangspunkt i en af de større bygherrer/driftsherrer i byggebranchen, Arbejdernes Andels Boligforening. Dette er fordi, at der gerne vil undersøges påvirkningerne af implementering af driftssystemer, som understøtter IKT-kravene i henhold til drift og vedligehold. Dette giver et mere realistisk billede, da større bygherrer/driftsherrer oftest har bedre investeringsmuligheder til den bedst mulige implementering. Ydermere vil der bliver lagt størst fokus på driftssystemet Mdoc FM samt Revit, eftersom disse ligger til grund for selve analysen af muligheder og udfordringer ved implementering af driftssystemet i praksis. Der er igennem specialet taget udgangspunkt i IKT-bekendtgørelse nr. 119 for alment byggeri (AAB som eksempel) samt nr. 118 for offentligt byggeri (Region Midtjylland som eksempel). Disse er begge identiske bortset fra 1, 2, og 12. Specialet har udelukkende fokus på selve implementeringen af driftssystemer, der understøtter IKT-kravene i henhold til drift og vedligehold, derfor vil der ikke blive lagt større fokus på juridiske problemstillinger i forbindelse med objektbaserede bygningsmodeller. 8

10 1.3 Valg af teoretisk grundlag og kilder Det har været af yderst vigtighed, at de valgte kilder undersøges bedst muligt for at kunne opretholde troværdighed og validitet i specialet. Dermed er materiale blevet indsamlet med et hvis kritisk niveau, der sikrer en høj kvalitet af litteratur. Det primære teoretiske materiale er IKT-bekendtgørelserne, der bliver udarbejdet af bygningsstyrelsen, hvor det både gælder bekendtgørelserne for det offentlige og almene byggeri. Ydermere har det været vigtigt at finde litteratur, der yderligere supplerer specialets fokus på driftssystemer, hvilket har været igennem bøger (se kildeliste). Det har også været nyttigt at anvende hjemmesider, der understøtter specialet og bidrager med yderligere dybde til opgaven som f.eks. Anvendelse af hjemmesider, artikler osv. har både været til ren baggrundsviden men også for at sikre, at informationen er nutidig. 1.4 Valg af metode og empiri Dataindsamlingen til dette speciale har primært foregået gennem interviews med forskellige aktører. Denne fremgangsmåde er blevet anset som den mest optimale, da det er svært at finde de praktiske problemstillinger i forbindelse med implementering af driftssystemer på nettet, bøger eller andet litteratur. Det har været et mål, at interviewene skulle give et større indblik i den virkelige verden samt belyse områder, hvorpå virksomheder står med problemer. Måden, hvorpå interviewene er blevet udformet, har været med specifikt henblik på at lede den interviewede dybere ind i virksomhedens problemstillinger. Interviewene har været struktureret på sådan vis, at alle de relevant emner bliver berørt med forskellige supplerende underspørgsmål til at underbygge og uddybe den interviewedes mening/svar. Det empiriske data er blandt andet indhentet via interviews med arkitekt og ejendomsadministrator i AAB og projektleder i Region Midtjylland. På den både har det været muligt at anskaffe data, der både afspejler muligheder, fremtiden samt udfordringer i forbindelse med implementering af driftssystemer. I og med at virksomheden sætter deres eget præg på driftssystemet, har det været til opgave for forfatteren at have et objektivt og kritisk syn, da rapporten skal være troværdig og valid. Som nævnt tidligere er det teoretiske data blevet indhentet for at danne grundlag for den analytiske del med empirisk argumentation. Det har været vigtigt at undersøge og forstå teorien, som specialet bygger på, før empirien er blevet indhentet. På denne måde er det muligt at skabe et konkluderende niveau, der er baseret på analyse af teori og empirisk fortolkning. 9

11 1.5 Videnskabsteoretisk tilgang Der er blevet arbejde ud fra Den videnskabelige model (Andersen, 2008), da der er blevet arbejdet ud fra interviews, hvor der har været flere empiriske underspørgsmål. Figur 1 - Den videnskabelige model (Andersen 2008 s. 25) Som overstående model viser, arbejder elementerne mellem hinanden og er lige afhængige af hinanden. Dette gør, at der under arbejdsprocessen arbejdes med flere elementer på samme tid som oftest afsluttes med en delkonklusion. Den kontinuerlige indhentning, fortolkning og analysering af dataene kan ende ud i, at forståelsen for emnet bliver ændret fuldstændig. 1.6 Rapportens struktur og argumentation Den tilgængelige rapportguide for bygningskonstruktøruddannelsen 1 har været grobund for specialets struktur. Dette er grundet behovet for at skabe overblik og et naturligt flow i specialet. Specialet er struktureret på sådan vis, at der startes ud med at give læser mulighed for at forstå emnevalget, problemformuleringen samt forståelse for, hvordan specialet skal læses. Derefter kommer hoveddelen, som indeholder afsnit, der har til formål at give fordybelse og indblik i de emner, som problemformuleringen tager op. Dette gøres, for at gøre det muligt at diskutere problemstillingerne i specialet på baggrund af fortolkning og analyse. I den sidste del besvares problemformuleringen på baggrund af fortolkning og analyse af teoretisk og empirisk data i form af konklusion og perspektivering. Ved at bevæge sig dybere og dybere ned i materialet for afslutningsvist at kunne drage den mest optimale kritiske konklusion baseret på validt data, forsøger specialets opbygning at bære læseren igennem på den mest overskuelige vis. 1 Rapportguide for bygningskonstruktøruddannelsen version. 3 VIA University College 10

12 2. IKT-bekendtgørelserne Bekendtgørelse om anvendelse af informations- og kommunikationsteknologi (IKTbekendtgørelsen) 2.1 Baggrund I 2003 var Det Digitale Byggeri et af de flere initiativer i den byggepolitiske handlingsplan Staten som bygherre. Dette initiativ har resulteret i flere bygherre-krav, som er formuleret i IKT-bekendtgørelsen, som blandt andet består af specifikke standarder og værktøjer. Bygherrekravene er blevet dannet grundet efterspørgsel om mere ensformige krav, der kan være base for IT-anvendelse i byggeriet. Ydermere har formålet med Det Digitale Fundament været en mere centraliseret vidensdeling igennem fælles informationssystematik, der optimerer forudsætningerne for overførsel af digital data mellem alle parter involveret i byggeriet. Et af de klare mål med bygherrekravene har været at skabe højere effektivitet samt en højere standard af kvalitet, som opnås ved at danne dette fælles arbejdssprog mellem alle parterne i byggeret. Dette er blevet endnu mere omfattende, da folketinget d. 1. juni 2011 vedtog Lov om Offentlig Byggevirksomhed, som omfatter, at både kommuner og regioner skal anvende de selv samme produktivitetsfremmende og omkostningsbesparende værktøjer, som tidligere kun har været underlagt det statslige byggeri i overensstemmelse med IKT-bekendtgørelsen. Dette gør, at dansk byggeri generelt får en højere og ensartet standard samt bliver forventningsafstemt i forhold til forventninger mellem parter i byggeret og kvalitet. IKT-bekendtgørelserne er blevet et mere og mere centraliseret regelsæt, som sætter standarden og er med til at opfylde brugernes ønske om ensartet kravstillelse. Dette kan bl.a. ses ved, at kravene er blevet implementeret af Bygningsstyrelsen og Ministeriet for By, Bolig og Landdistrikter indenfor almen byggeri og for stat, regioner og kommuner. Det vil sige; overordnet har der været ønske om digitaliseringen af fælles krav og retningslinjer for at kunne optimere og effektivisere vidensdelingen, samt højne kvaliteten i byggeriet. Det betyder, at alle parter i byggeret er bevidste om, hvilke standarder der arbejdes ud fra. Kravene har gjort det muligt at skabe større overblik i forbindelse med Det Digitale Byggeri samt at udarbejde forskellige platforme, der forbinder alle parter gennem det fælles arbejdssprog. (Bygningsstyrelsen, 2013) 11

13 2.2 IKT-bekendtgørelsernes formål En del af formålet med IKT-bekendtgørelserne er blevet berørt i tidligere afsnit, men det er vigtigt, at der også kommer fokus på den fælles værdiskabelse, der opstår ved anvendelse af IKT i alle byggeriets faser. Kravene giver også anledning til at fremme innovation indenfor byggeriet, da bygherre skal tage stilling til disse i henhold til, hvilke metoder og processer der kan spille overens med IKT-bekendtgørelsernes krav. Der er udarbejdet to IKTbekendtgørelser for henholdsvis offentligt (nr. 118) og alment byggeri (nr. 119). (Klima, 2013) Kravene er identiske fra 3 til og med 11 og omfatter: 3. IKT-koordinering 4. Håndtering af digitale byggeobjekter 5. Digital kommunikation og projektweb mv. 6. Anvendelse af digitale bygningsmodeller 7. Anvendelse af objektbaseret bygningsmodellering under projektering og udførelse. 8. Digitalt udbud og tilbud 9. Udbud med mængder 10. Digital leverance ved byggeriets aflevering 11. Digital mangelinformation Forskellen ligger i 1 og 2, som omfatter anvendelsesområdet, hvornår IKTbekendtgørelserne omfattes af byggeriet og 12 vedrørende ikrafttræden af bekendtgørelsen. Det er ligeledes vigtigt at belyse, hvordan disse krav ligger op til optimering indenfor leverancesystemet, hvilket bl.a. indbefatter rådgivere, projekterende, udførende, byggevareproducenter. (Bygningsstyrelsen, 2013) 2.3 Kort beskrivelse af paragrafferne i IKT-bekendtgørelsen 3 IKT-koordinering Dette er for at sikre, at kravene bliver overholdt af alle byggeriets parter. Ofte udarbejdes der helt specifikke regelsæt, dog med IKT-bekendtgørelsen som mindstekrav. En IKTkoordinator kan enten ansættes udefra eller en af bygherrens egne, hvilket har den fordel, at koordinatoren kender virksomheden. 4. Håndtering af digitale byggeobjekter Det er vigtigt, at der er nok information til rådighed om byggeprojektet til rådgivere og udførende både i forbindelse med projektering og udførelsen. Derudover har det stor betydning for drift og vedligehold, at det digitale byggeobjekt håndteres bedst muligt i forhold til vidensdeling og dataudveksling. 5. Digital kommunikation og projektweb mv. Dette krav har til formål at formidle bedst muligt alt digitalt data, som er anvendeligt i forbindelse med byggeriet både under og efter opførelse. Dette skaber overblik for alle parter i 12

14 byggeriet samt struktureret vidensdeling. Parternes forskellige ansvar bliver dermed lettere at definere, opfylde og følge. 6. Anvendelse af digitale bygningsmodeller Her bliver det muligt for bygherre/driftsherre at skabe de bedste beslutninger i henhold til nye byggerier vha. en digital, objektbaseret bygningsmodel. Dette gør det meget nemmere at bedømme, hvorvidt det præsenterede projekt lever op til bygherrens krav. 7. Anvendelse af objektbaseret bygningsmodellering under projektering og udførelse. Ved at anvende objektbaseret bygningsmodeller under projektering og udførelse bliver kvalitetsforbedring udnyttet til fuldt potentiale. Det er muligt at se, hvordan forskellige materialer kan blive udnyttet, da man knytter egenskaber/informationer til byggeobjekterne. Dette skaber stort overblik ved udførelsen af byggeriet. Der kan derudover laves kollisionskontroller ved at kombinere de forskellige fagmodeller til den fælles bygningsmodel. 8. Digitalt udbud og tilbud Ved interesse for byggeriet skal det være muligt at tilkendegive alle informationer vedrørende byggeriet som grunder det pågældende tilbud. Alle disse informationer skal kunne nedhentes fra den digitale platform. Derfor er det vigtigt, at al information vedrørende byggeriet bliver tilkendegivet og digitaliseret. 9. Udbud med mængder For at udnytte objektbaserede bygningsmodellers fulde potentiale er det en unik mulighed at udtage mængder fra disse i stedet for den traditionelle og omkostningsfulde opmålingsarbejde. Derudover hænger det også sammen med, at man ønsker ensartethed for at have mindre risiko ved sammenligning af tilbud. 10. Digital leverance ved byggeriets aflevering Det er vigtigt, at den digitale leverance ved byggeriets aflevering bliver opfyldt, da dette er basen for drift og vedligeholdelse af byggeriet. Ved at have alle informationerne centraliseret er det lettere at finde materialer i henhold til vedligeholdelse. Derudover bliver det muligt at holde informationer om byggeriet konstant opdateret. 11. Digital mangelinformation For systematisk at kunne udbedre mangler ved byggeriet, skal bygherre lave digitale mangellister. Derudover har dette krav til formål at skabe erfaring og opbevaring af informationer i relation til mangler. På den måde kan tidligere fejl og mangler skabe viden, der gør, at disse ikke kommer til at ske igen. 13

15 2.4 Delkonklusion Disse forskellige paragraffer i IKT-bekendtgørelserne har stor betydning for samtlige parter inden for byggeriet. Hvis vi kigger på 10, er det utrolig vigtigt, at bygherre sætter sig sammen med sin driftsherre og helt præcist finder ud af, hvilke informationer bygherren skal have ved aflevering af byggeriet, da det kan få konsekvenser for efterfølgende drift og vedligehold af bygningen. Det er derfor af stor interesse for driftsherren, at disse informationer bliver afleveret, så man kan holde bygningen intakt i mange år frem. I vejledningerne til IKT-bekendtgørelserne er det yderligere formuleret, at paragrafferne kan inddeles efter, hvorvidt de har indflydelse på bygherren, driftsherren, kvaliteten samt produktiviteten i leverancesystemet. Det vil sige, paragrafferne berører rådgivere, projekterende, udførende og byggevareproducenter. Efter redegørelse af IKT-bekendtgørelserne og et dybere indblik i, hvordan de bidrager til digitalisering af informationer iht. byggeriet, stiller det også spørgsmål til, hvordan man som organisation bedst muligt skaber et system, der kan understøtte alle kravene specielt i relation til digitaliseringen og centraliseringen af information. 3. IKT implementeret i virksomheden I følgende afsnit vil det blive fremhævet, hvordan en organisation kan danne en infrastruktur, som stemmer overens med IKT-kravene. Dette vil lede frem til, hvordan drifts-systemer (specielt Mdoc FM) fremmer og udnytter kvaliteterne i IKT-bekendtgørelsen. For at skabe større forståelse og overblik over, hvorfra driftssystemer udspringer, vil der blive kastet et blik på facilities management og computer aided facilties management. 3.1 Styringssystemer Facilities Management (FM) Begrebet Facilities Management bruges i mange forskellige sammenhænge og kan defineres forskelligt. Mange opfatter FM som ny måde at beskrive drift og vedligehold af bygninger. FM er blevet almindeligt at anvende i Danmark. Grundet de høje krav til bygningers arkitektoniske udformning og modstandsdygtighed overfor de klimatiske udsving i Skandinavien, har de byggetekniske aspekter af ejendomsdrift stor fokus i arbejdet med FM i de nordiske lande. (Anker Jensen, Nielsen, & Balslev Nielsen, Facilities management best practice i norden, 2008, s. 15) FM dækker over en mere nuanceret forståelse af, hvad det vil sige at drive en bygning og bliver ofte blandet sammen med det traditionelle udtryk Drift og Vedligehold, som kendes fra ydelsesbeskrivelsen 2. FM adskiller sig dog ved at dække over et langt større område ved at være en ledelsesdisciplin, der strækker over alle de fysiske rammer for en virksomhed og de 2 Ydelsesbeskrivelse for byggeri og planlægning

16 dertil knyttede servicefunktioner. (Anker Jensen, Håndbog i facilities management, 2011, s. 11 pkt. 1.2) DFM s 3 definition af FM lyder: 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. (Anker Jensen, Håndbog i facilities management, 2011, s. 11) Denne definition gør det klart, at FM dækker over et langt større område end selve bygningen ved at omfatte alle faciliteter, som støtter anvendelsen af bygningen som f.eks. sikkerhed, arealforvaltning og kantinedrift. Som illustreret i figur 2 behøver virksomheden ikke nødvendigvis selv at stå for opgaven af FM-funktionen, men kan derimod vælge at udlicitere opgaven til andre leverandører. Figur 2 - FM-funktionen, FM-leverancer og virksomhedens kernefunktioner (Anker Jensen, Håndbog i facilities management, 2011, s. 14) 3 Dansk Facilities Management 15

17 FM-funktionen kan beskrives som et samspil mellem de tre aspekter; Medarbejdere, virksomhedens mål og arbejdspladsen faciliteter, som det ses i figur 3. Figur 3 - FM i relation til virksomhedens hovedelementer (Anker Jensen, Håndbog i facilities management, 2011, s. 12) Dette betyder nødvendigvis ikke, at FM kun er et styrringsredskab, der benyttes indenfor drift og vedligeholdelse af bygninger. Det kan derimod også anvendes indenfor andre fagområder. Da dette speciale primært omhandler brugen af FM i forbindelse med drift og vedligehold i IKT-støttet byggeri, tages der derfor ikke yderligere dybere stilling til anden brug af FM. FM er på den måde et forsøg på at samle decentrale og ustrukturerede støttefunktioner, da det kan skabe en større effektivisering gennem øget struktur og stordriftsfordele. I og med at verden bliver mere og mere digitaliseret er det ikke optimalt med meget manuelt arbejde i kontakten mellem afdelinger, der giver spildtid ved vidensdeling. Derimod er computer-aided facilities management et udtryk, der formår at gøre facilities management langt mere effektiv og produktiv. Ydermere hjælper det også med at understøtte IKT-kravet i 3, da kommunikation på tværs af afdelinger og parter bliver betydeligt forbedret. 16

18 3.1.2 Computer-Aided Facilites Management (CAFM) CAFM har fokus på at få digitaliseret hele driften og vedligeholdelse i den pågældende virksomhed ved hjælp af informationsteknologi. Virksomheden vil gerne sikre, at deres aktiver bliver udnyttet til deres fulde potentiale så billigt som muligt samtidig med, at man gerne ser, at CAMF giver muligheder og bidrager til byggeriet igennem hele levetiden. Systemet danner et fundament, der gør det muligt for virksomheden at følge, styre, planlægge og reportere på projekter (f.eks. lejemål eller afdelinger). Informationen vil blive fordelt og gemt for alle i virksomheden til at se, hvilket også er grobund for innovation, da det bliver lettere at modtage inputs fra forskellige personer i virksomheden angående et projekt. Det er ikke muligt at danne ét CAFM-system, der kan dække alle virksomheders behov. Systemet bliver ofte skræddersyet til hver enkelt virksomhed med specifikke funktioner, moduler og app s. Produktivitet og effektivitet bliver markant forhøjet med et velfungerende CAMF-system, da viden bliver fordelt meget hurtigere og præcist. Dette kræver, at virksomheden også vil investere i vedligehold og udvikling af systemet (senere vises, hvordan AAB har taklet dette). Der er adskillelige fordele ved at benytte et velsyet CAMF-system: Overblik: virksomheden kan holde styr på ejendomsporteføljer under én platform. Omkostningsbesparelse: grundet den stigende effektivisering og muligheden for at prøve forskellige ting i forbindelse med objektbaseret modellering, bliver der både sparet tid og penge. Informationer omkring ejendomsporteføljen vil altid være lagret og til at finde i tilfælde af bl.a. renovering, vedligehold, ombygning osv. Planlægning af f.eks. hele byggeprocessen danner overblik for alle parter i byggeret. Sikkerhed: det er væsentligt, at CAMF gør det muligt at følge ejendomsporteføljerne og f.eks. formindsker risikoen for fejl grundet manglende opsyn. Vidensdeling: alt information bliver fordelt på tværs af virksomheden, hvilket eliminerer overflødig information dvs. man kan ikke risikere at indhente den samme information to gange. Proaktive: virksomheden har mulighed for at være på forkant forud for evt. mangler og fejl. (WBDG, 2013) Delkonklusion Det er nu blevet vist, hvordan virksomheder holder bedst muligt styr på drift og vedligehold igennem FM og CAMF. CAMF er en slags udbygning af FM, hvor det bliver muligt at centralisere data digitalt og formindske manuelle fejl. Ydermere, hvis man også forbinder IKT-kravene, er yderbygningen på FM (CAFM) til stor nytte, da kommunikationen bliver langt hurtigere og præcis. I afsnittet er der endnu ikke blevet belyst, hvilke systemer, der hører under CAMF: sådanne systemer bliver kaldt driftssystemer og har som primære formål at danne et digitalt fundament, der kan varetage virksomhedens opgaver effektivt. 17

19 3.2 Driftssystemer Der vil nu blive lagt fokus på driftssystemer, samt hvordan disse er med til at støtte IKTbekendtgørelserne og skabe et bedre data-flow i virksomheden. Det er ikke nok at se på driftssystemerne ren teoretisk, derfor er der lagt vægt på, hvordan det virker i praksis med specielt henblik på implementering og anvendelsen af Mdoc FM i Arbejdernes Andels Boligforening i Århus (AAB). Dette gør det muligt at øjne de udfordringer og forcer som medfølger ved implementering af et driftssystem i praksis. Der vil derfor blive udredt for, hvad og hvordan et driftssystem fungerer Hvad kendetegner et driftssystem Et driftssystem er en IT-baseret software, som kan varetage og overskueliggøre virksomhedens drift og vedligeholdelsesopgaver beskrevet i ovenstående afsnit vedrørende CAFM. Der findes i dag forskellige driftssystemer; nedenfor er der illustreret et udsnit af de mange driftssystemer: MainManager FM Archi FM Dalux FM Mdoc FM Der kan nævnes mange flere driftssystemer, men de nævnte er nogle af de førende i Danmark i dag. Specialet vil, uden at favorisere, tage udgangspunkt i Mdoc FM, da det er det eneste driftssystem forfatteren har dybere og bredere kendskab til. Mdoc FM driftssystemet vil blive beskrevet på baggrund af tilegnet viden fra internettet og af interviews med Mikkel Leth Gregersen fra NTI CAD Center samt ansatte fra AAB Generelt om driftssystemet MdocFM Mdoc FM er et dansk drifts- og vedligeholdelsessystem som samler alle bygningernes informationer ét sted. Systemet findes både som en klient- og webbaseret løsning med adgang til ejendomsporteføljerne for driftsmedarbejdere i virksomheden og eventuelle andre brugere. Mdoc FM kan, og er udviklet til at styre alle drifts- og vedligeholdelsessituationer i virksomheden. Mdoc FM kan håndtere informationer vedrørende planlagt vedligehold, ad hoc vedligehold, arealer og driftsregnskaber mv., derudover er der mulighed for at tilkøbe yderlige moduler, som eventuelt kan komplementere og supplere den pågældende virksomhed. Mdoc FM giver mulighed for at skabe et overblik over virksomhedens Facility Management opgaver. Det kan desuden være med til at minimere udgifterne samt skabe større værdi for virksomheden i forhold til styring af deres drift og vedligeholdelsesinformationer. (Center, Mdoc.dk) Udviklingen af Mdoc FM er, forklarer Mikkel Leth Gregersen fra NTI CAD Center, at der altid har været et behov for at kunne digitalisere ens bygningsmasse men samtidig også at kunne forudsige, hvor mange penge der skal bruges på drift og vedligehold ud i fremtiden. 18

20 Mdoc FM lagrer alle driftsinformationer sådan, at det er nemt tilgængeligt for alle i virksomheden. Ved at samle alle driftsinformationer ét sted har medarbejderne mulighed for at genanvende disse, hvilket er med til at optimere og effektivisere virksomhedens fremtidige drift og vedligeholdelsesinformationer nu og fremover. Sammen med dette vil der også automatisk blive skabt en større vidensdeling blandt medarbejder og afdelinger. En af funktionerne i Mdoc FM er, at systemet selv genererer automatiske remindere på arbejdsopgaver, så det sikres, at medarbejderne når i hus med sine opgaver til tiden. Mdoc FM s samlede Facility Management løsning er hvor man får samlet alle informationerne beskrevet nedenfor: Stamdata o Generel beskrivelse af virksomhedens ejendomsporteføljer herunder afdelinger/lejemål med mulighed for billede dokumentation og tegningsmateriale. Alle generelle informationer noteres ind for at kunne anvendes senere. Kontakter o Alle med tilknytning til virksomheden inklusiv leverandører noteres ind i systemet for at kunne komme i kontakt med alle relevante medarbejder i forbindelse med en opgave. Disse kontakter kan godt blive tilført Mdoc FMdriftssystemet ved en dataudveksling mellem virksomhedens nuværende system. Oplysningerne vedrørende leverandører skal bruges i forbindelse med udarbejdelsen af rekvisitioner. Vedligehold/ byggesyn o Her findes de relevante oplysninger omkring ejendomsporteføljerne. Her er der mulighed for at vælge hvilken ejendom/afdeling/lejemål og dernæst mulighed for at vælge de tilknyttede bygningsdelskort. På bygningsdelskortene kan man se generelle oplysninger samt økonomi, levetider, billeder mv. Ud fra alle de tilknyttede bygningsdelskort kan der genereres 10 års eller 50 års bygningssynsoversigt: disse oversigter illustreres i søljediagrammer, hvor man kan se, hvor mange penge der planlagt til vedligeholdelse. Disse oversigter kan helt afhængigt af hvilket omfang der specificeres lave rapport for hele organisationen eller på lejlighedsniveau. Økonomien på hvert enkelt bygningsdel skal være indeksreguleret så prisen ikke er den samme om 20 år. Økonomi o Her kan man sende rekvisitioner ud af virksomheden. Der er mulighed for at se, hvilke rekvisitioner der er aktive samt afsluttede. Der kan tilknyttes fakturaer direkte i systemet samt få et overblik over budgetter for afdelingerne. 19

21 Arealer o CAD-integrationen kan oprette netto- og bruttoarealer fra en tegningsfil eller fra en direkte integration mellem Revit 4 og Mdoc FM systemet. Mdoc FM har udviklet et plugin til Revit, hvorfra det nu er muligt at eksportere informationer vedrørende byggeobjekter i modellen samt de planer der oprettet i den objektbaserede bygningsmodel. På samme måde kan man fra Mdoc FM driftssystemet eksportere informationer tilbage i Revit modellen. ToDo o Det fungerer som en personlig kalender, som man kender fra Outlook. Her kan ses hvilke opgaver du har gang i, og hvilke der kommer ud i fremtiden. Det er denne funktion som generer remindere på en opgave. Vagt og Ferie planer o Her indberetter hver enkelte medarbejder, hvornår han/hun afholder ferie. Dette giver overblik for samtlige medarbejder. Kvalitetssikring o Her får medarbejderne sine arbejdssedler, hvorfra det er muligt at lave kvalitetssikringer af ens eget arbejdet. Denne funktion er dog lavet i forhold til, hvis virksomheden har VVS eller El-installatører ansat, da de skal sikre, at de har de relevante certifikater til udførelsen af et stykke arbejde. (FM) Alle disse information er vigtige for at opretholde sine bygninger intakte mange år ud i fremtiden samt skabe overblik for medarbejdere i hele virksomheden. Mdoc FM-driftssystemet er bygget op, som et åbent databasesystem. Virksomheden har derfor mulighed for at integrere deres øvrige systemer. For at dette kan lade sig gøre, skal der laves en udveksling af data mellem disse systemer og Mdoc FM. Figur 4 Mdoc FM brugerflade udlånt af AAB jvf. bilag 7 Ifølge Mikkel Leth Gregersen har 4 i IKT-bekendtgørelserne haft den største indflydelse, da denne træffer beslutningen omkring informationer på byggeobjekterne med henblik på efterfølgende drift og vedligehold. Hvis bygningsobjekterne skal genbruges, er det vigtigt, at 4 Jf. afsnit

22 al information på bygningsobjektet er velstruktureret for at kunne findes i systemet. (interview med Mikkel Leth bilag 2, s.3) Bag om Mdoc FM s udvikling NTI CAD Center, som har udviklet Mdoc, valgte i starten af 2012 at opkøbe det tidligere LogFM, som dengang var et af de mere førende driftssystemer i Danmark. Ved sammenlægning af disse to programmer kommer det fremover til at være kendt som Mdoc FM. NTI CAD Centers administrerende direktør Jesper Kalko udtaler følgende: Det er med storglæde, at vi nu kan levere den ubetinget bedste og mest brugervenlige løsning til FM. Vi har gennem mange år været førende indenfor CAD 5 til byggeriet. Med sammensmeltningen mellem LogFM og Mdoc FM får vi en løsning, som vil hjælpe alle brugere frem mod en mere optimal håndtering af deres Facility Management. (Center, NTI CADcenter A/S køber LogFM - og sammenlægger produktet med Mdoc FM, 2012) Med dette betyder det nu, at Mdoc FM kan levere én samlet Facility Management løsning til virksomhederne. Driftssystemet er med til at optimere og effektivisere virksomhedens/ organisationens ejendomsporteføljer, samtidig med at det sikrer, at informationer kun bliver lagret ét sted, så man undgår redundante informationer. Som Jesper Kalko fortæller, har NTI CAD Center været førende inde for CAD til byggeriet. Det har derfor ført til, at Mdoc FM nu også kan levere en løsning, hvor Revit-modellen kan implementeres i Mdoc FM-driftssystemet. Bygherren har dermed mulighed for at genanvende informationer/egenskaber, som byggeobjekterne indeholder i den samlede objektbaserede bygningsmodel til drift og vedligehold i Mdoc FM-driftssystemet. For at Mdoc FM-driftssystemet kan bruge informationerne, som er knyttet op på de forskellige byggeobjekter i bygningsmodellen, kræves det, at bygningsmodellen er opbygget korrekt. For at sikre dette, skal det derfor udspecificeres i IKT-aftalen mellem de forskellige parter i henhold til bygherren/driftsherren, så de har mulighed for at bruge Revit-modellen optimalt i forhold til den efterfølgende drift og vedligehold. AAB har valgt at få implementeret Mdoc FM i deres organisation og har i den forbindelse afprøvet integrationen mellem Revit-modellen og Mdoc FM. Leif Kruse, der er inspektør i projektafdeling i AAB samt hovedansvarlig for implementeringen af Mdoc FM, udtaler: Vi har kun prøvet at køre afd. 75 nede på havnen. Det var så der, vi fik små 100 lejlighedskort, hvilket var alt for meget. Så begyndte vi at snakke families. Så får vi det begrænset, så vi kun har stykker pr. lejlighed i stedet. Det var nogle teknikker, vi benyttede efter. Så har vi gået tilbage og revideret de tegninger, vi allerede havde i Revit 3D til det niveau, som vi nu lærte fra projektet på havnen. (interview med Leif Kruse, bilag 1 s. 9) 5 Computer Aided Design 21

23 Det kræves derfor, at man har styr på sin klassificering og informationsniveauet på sine byggeobjekter inden disse eksporteres til Mdoc FM. De har derudover senere konstateret, at bygningsmodellen, som de modtog fra projekterende, ikke var ordentlig bearbejdet; køkkenet var tegnet i 2D, hvorfor tegnestuen i projektafdelinger selv har tegnet den resterende bygningsmodel op til det niveau, som AAB har brug for i forbindelse deres drift og vedligehold i virksomheden, men også så bygningsmodellen og dens byggeobjekter kan eksporteres som tiltænkt til Mdoc FM-driftssystemet. Som udtalt tidligere er der mange forskellige former for driftssystemer. Eftersom der er taget udgangspunkt i AAB for at skabe bedst indblik i, hvordan et driftssystem fungerer og støtter kravene IKT-bekendtgørelserne, vil det blive belyst, hvorfor lige præcis Mdoc FM er blevet implementeret i virksomheden. Inden AAB kendte til Mdoc FM, havde de alle deres drift og vedligeholdelsesinformationer i Excel-ark (se bilag 5). I forbindelse med et møde i Vejle, præsenterede NTI CAD Center deres driftssystem Mdoc FM. Efter dybere information og indblik i programmet var AAB overbevist om, at sådan et driftssystem ville kunne korrelere perfekt til deres vision og mission for virksomheden både nu og i fremtiden. En af de væsentligste grunde til, at Mdoc FM blev valgt, var fordi driftssystemet kunne integreres med deres øvrige informationer fra andre databaser på den måde mindskede man manuel indtastning. Mdoc FM-driftssystemet har i takt med de nye IKT-bekendtgørelser været nødt til at udvikle deres system, for på den måde at stemme overens med IKT-bekendtgørelsernes krav. Mikkel Leth Gregersen, Facility Management consultant i Mdoc FM, udtaler som følgende: Det kommer sig helt sikkert af, at der nu er blevet stillet krav om det igennem IKT-bekendtgørelserne. Blandt andet kravet om informationer og klassificering på objekterne har vi enormt stort fokus på lige nu. (interview med Mikkel Leth, bilag 2 s. 2) Især informationerne på bygningsobjekterne har stor betydning for om bygherren/ driftsherren kan bruge disse i den efterfølgende drift og vedligehold af bygningerne. I forhold til klassificering af objekter findes der mange forskellige klassifikationssystemer. Nogle af de mere kendte er SfB, DBK, CCS klassifikationen. SfB er nok det mest udbredte klassifikationsværktøj. Dette er også blevet anvendt i forbindelse med AAB s tidligere drift og vedligeholdelse. (interview med Leif Kruse, bilag 1 s. 6) Der er dog sket en markant forandring på dette område, da almene boligorganisationer nu skal bruge Statens Forvaltnings Klassifikation. Dette skaber en mere ensformig klassificering for samtlige almene boligorganisationer. Det betyder, at AAB nu fremadrettet skal sørge for, at der i deres IKT-aftale står, at byggeobjekter skal navngives og klassificeres efter Statens Forvaltnings Klassifikation. Da klassifikationssystemet er forholdsvis nyt, har det resulteret i, at de projekterende først har været nødt til at sætte sig ind i systemet. Da projekterende altid har anvendt de tidligere 22

24 nævnte klassifikationssystemer, har dette været endnu en udfordring at implementere i virksomheden (interview med Elizabeta Lahu, bilag 1 s. 2) Dermed skal AAB være sikker på, at objekterne i forbindelse med de næste nye IKT-støttede byggerier skal være forsynet med Statens forvaltningsklassifikation, så klassifikationen passer ind i Mdoc FM-driftssystem ved aflevering af bygningsmodellen. For at bygherren kan sikre dette, er det vigtigt, at han tager stilling til informationerne på byggeobjekterne i 4, sådan så at han modtager det ved aflevering af byggeriet i 10. Disse paragraffer skaber optimal drift af bygningen og har stor indflydelse på efterfølgende drift og vedligehold. Dette har været ensbetydende med, at de i forbindelse med implementeringen af Mdoc FMdriftssystemet har været nødt til at sikre sig, at systemet understøtter Statens forvaltningsklassifikation. AAB har derfor været med til, at NTI CAD Center har udviklet Mdoc FM, så det nu kan klassificeres efter Statens Forvaltnings Klassifikation. Den ansvarlige for tegnestuen samt IKT-ansvarlige i AAB, arkitekten Elizabeta Lahu, fortæller i et interview vigtigheden i at beskrive klassifikationssystemerne i IKT-aftalen for hvert enkelt projekt, der bliver påbegyndt. Det vil sige en beskrivelse af hhv. virksomhedens og den projekterendes klassificering. Overraskende nok er der ikke mange, der kender til de gældende klassifikationer som det almene byggeri er underlagt, hvilket til tider godt kan skabe problemer i forhold til projektering og udarbejdelse af de objektbaserede bygningsmodeller (interview med Elizabeta Lahu, bilag 1 s. 2). Statens Forvaltnings Klassifikation er kun beregnet til de almene boligorganisationer og drejer sig kun om drift og vedligehold og ikke under projektering og udførelse. Det betyder, at de projekterende stadigvæk selv skal bruge deres egne klassifikationssystemer for, at de kan finde rundt i deres byggeobjekter og objektbaserede bygningsmodeller. En af ulemperne ved Mdoc FM-driftssystemet er, at virksomhederne ikke endnu har mulighed for at trække erfaringstal fra eksempelvis V&S prisdatabøgerne, men kun kan gøre brug af virksomhedens/organisationens egne erfaringstal, som de har opbygget igennem tiden på deres bygningsdele. Mikkel Leth Gregersen forklarer dog, at det er noget, som de arbejder på i øjeblikket. Derudover fortæller han også, at de er i gang med at gøre det muligt at hente digitale aflæsninger fra målere Delkonklusion Som det ovenstående afsnit (3.2) belyser, kan driftssystemet Mdoc FM være en god investering i drift og vedligeholdelsesorganisationer. Da man sikrer alle virksomhedens driftsinformationer i én samlet database, så sikres og forebygges den fremtidige drift og vedligehold af ejendomsporteføljer. Derudover er det vigtigt, at alle parter inden for byggeriet arbejder ud fra samme vilkår. Disse skulle gerne fremgå i den specifikke IKT-aftale, der udarbejdes af bygherre og hans eventuelle bygherrerådgiver. Ved ikke at arbejde ud fra samme vilkår skaber det tidsspild i form af dobbeltarbejde og hele ideen med at effektivisere arbejdsgangen vha. driftssystemer forringes. 23

25 Som nævnt anvender AAB programmet Revit, som er et objektbaseret bygningsmodelleringsprogram. Det er ikke alle organisationer, der vælger at danne dette sammenspil men i stedet nøjes med IFC-formater til drift og vedligehold. Derfor vil det blive uddybet, hvilken betydning det har for virksomheden at anvende objektbaseret bygningsmodellering i det kommende afsnit. 3.3 Objektbaseret bygningsmodellering (BIM) I 4 i IKT-bekendtgørelserne skal bygherre sikre, at der anvendes digitale byggeobjekter gennem hele byggesagen. Dette gøres ved at modellere i CAD-programmer som understøtter objektbaseret bygningsmodellering. Begrebet objektbaseret bygningsmodellering kaldes også i daglig tale BIM som på engelsk betyder Building Information Modeling. BIM er blevet mere og mere anvendt, da flere og flere elementer i byggeriets programmerings- og projekteringsfasen bliver digitaliseret i takt med computerbaserede værktøjer som CAD mfl. i stigende grad har fundet anvendelse i objektbaserede bygningsmodeller. Et af de bærende elementer i BIM er den geometriske visualisering af bygningen, men derudover er der den væsentligste forskel, at man bevæger sig væk fra de papirbaserede tegninger og over i 3D-objektorienteret bygningsmodeller. Dette betyder, at linjerne i modellen nu kan tildeles informationer og dermed gøres de mere intelligente. BIM er en model og arbejdsmetode til at digitalisere processen af byggeriet fra ide til drift. Den objektbaserede bygningsmodel vil være omdrejningspunktet for alle parter indenfor byggeriet. Begrebet gavner desuden kommunikationen mellem de forskellige aktører under byggeriet. Dette gøres ved at anvende en fælles BIM-model på byggeprojekt (på den måde undgås dobbeltarbejde). Dette er yderligere understøttet af BIM eksperter bag BIM Handbook : The earlier the model can be developed and shared, the more useful it will be. The design-build approach provides an excellent opportunity to exploit BIM technology, because a single entity is responsible for design and construction and both areas participate during the design phase. (Eastman, Teicholaz, Sacks, & Liston, 2008, s. 7) Dette skal forstås på den måde, at hver enkelt aktør ikke skal genoptegne/modellere bygningen fra bunden af, men i stedet kan fællesmodellen overdrages fra én aktør til anden. Kommunikationens fordele ved at benytte sig af fælles BIM-modeller frem for traditionel projektering er vist nedenfor på figur 3. 24

26 Figur 3 - Kommunikation mellem byggeriets aktører med til højre og uden til venstre - anvendelse af BIM Modellen til venstre viser, hvordan informationerne løber helt ustruktureret mellem byggeriets parter dette tager både længere tid og skaber større risiko for, at parterne ikke modtager den samme information, hvilket kan resultere i yderligere forsinkelser i forbindelse med byggeriet. Til højre ses anvendelsen af BIM: informationerne bliver centraliseret og alle parter får den samme information på samme tid, hvilket er grobund for et mere flydende samarbejde mellem parterne med mindre risiko for misforståelser og forkerte information på tværs af byggeriets parter Revit Architecture Revit Architecture er et CAD-program, som understøtter ovenstående afsnit med hensyn til at modellering af byggeobjekter og bygningsmodeller. AAB har valgt at anvende Revit Architecture som tegningsprogram på tegnestuen, da Revit kan arbejde direkte sammen med Mdoc FM-driftssystemet. Revit er bygget op omkring familiys, som til sidst ender ud med en objektbaseret bygningsmodel. Familiys er det samme som byggeobjekter. Familiys kan være alt fra vægge, vinduer, døre, tage mv. I Revit er det muligt at tildele familiys specifikke informationer/egenskaber, som kan være i forskellige detaljeringsgrader og informationsniveauer. Alt efter bygherren/driftsherrens behov kan byggeobjekterne skræddersys med de informationer/egenskaber, som er relevante for driften af bygningsdelene. Ved aflevering af den objektbaseret bygningsmodel skal det derfor sikres, at den er læsbar for bygherren og driftsherren. Der er derfor stillet krav i IKT-bekendtgørelsens 10 om, at alt materiale vedrørende byggesagen afleveres i IFC-format inklusiv den objektbaserede bygningsmodel. Mange virksomheder har ikke midlerne til at anvende BIM-programmer internt, selvom det er langt klogere en andre alternativer som f.eks. Industry Foundation Classes. For at få en 25

27 forståelse af fordelene ved BIM gives der et indblik i et gratis alternativ. Det vises senere, hvordan det virker i praksis (også i sammenlignelse med en BIM model). 4. IFC (Industry Foundation Classes) IFC er en standard datamodel, der kan opbevare og udveksle byggeprocesrelaterede data mellem forskellige IT-systemer og platforme uafhængigt af hinanden. IFC-formatet er udviklet af den internationale organisation buildingsmart, tidligere International Alliance of Interoperability (IAI) og er certificeret efter ISO under ISO 16739:2013. (buildingsmart) Formålet med IFC-modelen har været at sikre en åben anvendelse og udveksling af de objektbaserede bygningsmodeller mellem byggeriets parter. Softwareleverandørerne behøver derfor ikke at understøtte en masse andre udvekslingsformater, da IFC-formatet kan understøtte de fleste behov - dette er muligt fordi standarden er åben, neutral og uafhængig af en bestemt softwareleverandør. På baggrund af det ovenstående beskriver organisationen buildingsmart sig selv som the home of open BIM. (buildingsmart) Formålet er endvidere at sikre filer, dokumenter og ikke mindst at de objektbaseret bygningsmodeller er langtidsholdbarer og læsbarer. Derudover skal modellerne være mulige til anvendelse til f.eks. FM i bygningsdriften i forbindelse med eventuelle moderniseringer, tilbygninger eller ved renoveringsarbejder. (Bygningsstyrelsen, 2013). Ved brug af IFC forsvinder der nogle informationer, fortæller Leif Kruse. Dette udvekslingsformat opfylder kravene i henhold til 10 i IKT-bekendtgørelserne. AAB har ikke været interesseret i kun at anvende IFC, da det begrænser mulighederne for at genanvende og redigere de objektbaserede bygningsmodeller. Det er vigtigt at være på forkant for udviklingen, hvis man som virksomhed vil sikrer sig en plads på markedet. Derfor vil der nu blive lagt fokus på fremtiden i forbindelse med drift og vedligehold, hertil specielt indenfor det almene byggeri. 5. Fremtiden AAB har undervejs i forbindelse med implementeringen af driftssystemet Mdoc FM udviklet en app til tablets i samarbejde med NTI CAD Center og med støtte fra Ministerieriet for By, Bolig og Landdistrikter. Denne app skal være med til at give AAB endnu større overblik over deres drift og vedligeholdelsesopgaver på lejlighedsniveau. App en som kaldes DOtAB (jf. bilag 4) står for driftsoptimeringer til almene boliger. DOtABens funktion skal bygge op omkring QR-koder. På den måde kan kameraet i tablet en scanne QR-koden. Koden skal opsættes i hvert enkelt lejemål og være kodet op på lejemålet og dens oplysninger som hentes ud fra Mdoc FM s database. Disse oplysninger kan stamme fra de byggeobjekter, som er eksporteret gennem bygningsmodellen til Mdoc FM. Når ejendomsfunktionæren scanner koden, får han oplysninger på lejemålet at se, hvorefter han har mulighed for at oprette en sag på en af de respektive bygningsdele. 26

28 Ved at ejendomsfunktionæren nu har mulighed for at gøre det hele ude fra lejemålet, mindsker man tidsforbruget, idet han førhen skulle tage billeder med fotografiapparatet og notere informationerne ned på papir og derefter først hjem på kontoret og lave rekvisitionen. Eftersom der er omkring 8500 lejemål i Arbejdernes Andels Boligforening, kan det helt sikkert være med til at optimere og effektivisere den daglige arbejdsgang for ejendomsfunktionærerne i driften. Derudover har disse nyttige oplysninger også det formål, at alle i AAB får et større overblik over afdelinger og lejemålenes drift- og vedligeholdsstand. Der er flere muligheder med den nye DOtAB, da men både kan tage billeder direkte fra tablet en samt optage en lyd og vælge standart fraser. Disse oplysninger, som ejendomsfunktionæren udfylder på den specifikke bygningsdel, bliver lagret som nye informationer under stamdata for denne bygningsdel. På den måde har man et godt overblik over bygningsdelens levetid, hvor det er muligt at se historikken for bygningsdelen. Når ejendomsfunktionæren har udfyldt det han kan i forbindelse med en reparation af bygningsdelen, bliver der automatisk dannet en rekvisition. Den optræder ude som en aktivitet på hans dashboard (overblik for den enkelte). DOtAB ens interface er designet så alle har mulighed for at bruge den uden for mange knapper. Den skal kunne bruges af alle ejendomsfunktionærer uden særlig IT-kundskaber. Der er som sagt muligheder og fordele i app en og der kan skabes yderligere muligheder i at udvikle DOtAB en, så den også kan anvendes til syn af lejemålene. Lige nu skal ejendomsfunktionæren have sin computer, printer og fotografiapparat med ud i lejemålet når han skal syne. Man kunne godt forstille sig, at dette kan gøres på en smartere måde, hvis alt blev gjort fra DOtAB en. Det betyder så også, at den enkelte beboer i AAB får mulighed for at se de relevante dokumenter for afdelingen og lejeforhold. Det kræver dog, at der skal sættes retningslinjer for, hvilke oplysninger den enkelte i AAB skal kunne se og bruge. Man kunne eventuelt også forstille sig, at den bliver udviklet så den også fungerer på mobiltelefoner, da mange i dag ejer en smartphone. Organisationer for alment byggeri er meget økonomisk bevidste og vil gerne gøre noget til den laveste pris for forbrugeren og samtidig opretholde en høj kvalitet. DOtAB er endnu et værktøj, der kan lette på budgettet, men dette er ikke det eneste omkostningsmindskende værktøj AAB har haft under udvikling. I forbindelse med de sidste byggesager har AAB haft deres materiale ude på en digital platform som hedder ibinder, som er kompatibel med Mdoc FM-systemet. Dette stemmer også passende overens med 5 vedrørende digital kommunikation og projektweb mv. De har dog valgt at udvikle deres egen digitale platform i forbindelse med udbud, da de ikke vil betale de summer, som de andre leverandøre af digitale platforme vil have. De vil derfor udvikle en platform, som de selv råder over og i forbindelse med byggerier har mulighed for at ligge deres materialer og dokumenter ud til de interessetilkendegivende. 27

29 Overstående har givet indblik i de muligheder og fremtidsplaner, som de teknologiske forbedringer har båret med sig i forbindelse med Mdoc FM. Fokus har været på, hvordan AAB hele tiden prøver at forbedre og få sammenspillet mellem deres platforme til at arbejde sammen for at opnå det mest optimale output. Det er også vigtigt at belyse, hvordan andre virksomheder har valgt at håndtere IKT-bekendtgørelsens krav. Afsnit 5.1 sammenligner det almene byggeris udfordringer og muligheder med det offentlige byggeri iht. IKT-kravene og implementering af driftssystemer. 5.1 Et mere offentligt perspektiv Mdoc FM er kompatibelt med IFC-formatet, hvilket vil sige, at Mdoc FM understøtter kravet om brugen af IFC-formater. Det betyder, at bygherre har mulighed for at implementere de driftsinformationer, han modtager i bygningsmodellen i forbindelse med aflevering af byggeriet. Formålet med at kunne digitalisere alle sine arbejdsgange i forhold til den samlede anvendelse af IKT i byggeriet stemmer godt overens med de FM-systemerne, der eksisterer i dag. CAFMsystemer som Mdoc FM er nemlig yderligere med til at anvende disse digitale informationer. Disse bliver en integreret del af, hvad det vil sige at drifte digitalt. I forhold til klassificering af bygningsobjekterne og dens informationer i 4 i IKTbekendtgørelsen er det vigtig, at de kan genkendes i CAFM-systemerne. Disse er med til at skabe overblik over, hvor objekter er placeret i den samlede objektbaserede bygningsmodel. Ved at tildele objekter et unik ID. har driftssystemet mulighed for at genkende den i driftssystemet. Mdoc FM understøtter, som tidligere nævnt, klassifikationssystemer som SfB (Statens Forvaltnings Klassifikation) og CCS, så uanset hvilken form for klassifikationssystem bygherren vælger, kan driftssystemet anvende disse. I forhold til 10 om digital leverance ved byggeriets aflevering har AAB valgt at de også vil modtage den digitale bygningsmodel som Revit-fil (rvt-format), da de har mulighed for at bruge denne på et senere tidspunkt ved ombygninger, tilbygning og kan på den måde videre modellere på den objektbaserede bygningsmodel. IKT-bekendtgørelserne har helt bestemt været med til at sætte fokus på digitalisering af hele det samlede byggeri, men derudover har den for AAB også været med til at rykke dem det næste skridt: nu er de i fuld gang med udviklingen af nye smarte digitale værktøjer til forbedret styring af deres Facility Management. Efter at have fået en bredere forståelse omkring det almene byggeri er det vigtigt også at forholde sig til det offentlige byggeri. Ved at gøre dette, dannes der et større overblik over IKT-bekendtgørelsernes indvirkning samt de forskellige løsninger i forbindelse med at overholde kravene. For at sætte implementering af driftssystemer i et støre perspektiv, fortæller Birgitte fra Region Midtjylland at IKT-bekendtgørelserne også har haft indflydelse på deres Facility Management, da de også er ved at implementere et driftssystem. De har dog valgt at anvende 28

30 et andet CAFM-system i forhold til Mdoc FM MainManager. Forklaring på valget af dette driftssystem er grundet en kravspecifikation, de lavede i samarbejde med NIRAS. (interview med Birgitte Nissen, bilag. s. 4) Birgitte har arbejdet med drift og vedligehold i over 20 år. Hun er uddannet arkitekt indenfor by og bygning, men har valgt at springe over i drift og vedligeholdelsesbranchen (offentligt byggeri). I dag sidder hun som projektleder i Region Midtjylland. Hun fortæller, at hun er fra tiden, hvor man havde det hele i papir og mapper, som blev taget med ud på byggepladsen, der skulle besigtiges sammenlignet med i dag, hvor alt foregår over computere, telefon og tablets. De har endnu ikke prøvet at eksportere informationer fra deres objektbaserede bygningsmodeller fra de nuværende hospitalsbyggerier, men de har derimod lavet tre testmodeller, hvor de først prøver at få det til at virke der, inden de bruger deres egne driftsinformationer. I forhold til 3 fortæller hun, at det er de enkelte projektafdelinger, der står for at få afleveret det samlede byggeri indenfor paragrafferne i IKT-bekendtgørelsen. Hun uddyber, at IKT-bekendtgørelsen har haft en stor betydning for deres drift og vedligehold, da de tekniske chefer inden for regionen har valgt at få implementeret et driftssystem, som kan indeholde alle deres relevante informationer vedrørende drift og vedligehold. Hun nævner desuden, at IKT-bekendtgørelsen har haft betydning for, at de nu kan samarbejder på tværs af regioner og afdelinger. En af de største fordele, ifølge Birgitte, er, at man konstant er parat, hvis der skulle bygges i morgen. De objektbaserede bygningsmodeller er hele tiden opdateret og kan sendes i udbud, hvilket man ikke tidligere har kunne gøre. Man har grupper som er på tværs af organisationen, så man sidder nu til bords med hinanden på landsplan og udveksler erfaringer, og det har IKT bekendtgørelsen været med til, så du kan ikke pille en eneste paragraf ud, for de hænger alle sammen. (interview med Birgitte Nissen, bilag 3 s. 2) Kommunikationsforbedringer ses også inden for dette felt med et velfungerende driftssystem. Dette er både digitalt, men også hvor de mødes og diskuterer, hvordan drift og vedligehold skal kørers i regionerne. I forhold til 4 og håndteringen af deres digitale byggeobjekter, sætter de ikke nogle grænser for, hvor meget information der er på byggeobjekterne. Det betyder i forhold til 10, at når de modtager deres materiale vedrørende byggesagen, har de altså en bygningsmodel, der fyldt med informationer. Det vil sige, at de ikke udspecificere, hvilke byggeobjekter der skal anvendes til drift og vedligehold, samt hvilke informationer de ønsker. De har derimod udarbejdet en liste over hvilke information og hvilke byggeobjekter, de ønsker til drift og 29

31 vedligehold. Denne liste samt bygningsmodellen bliver sendt op til Norge, hvor de har en rådgiver siddende. Det skal fortælles, at de ikke modtager bygningsmodellen i Revit-format men i stedet IFCformat, hvilket er et krav i forbindelse med den digitale aflevering af byggeriet i 10. Dette indebærer, at de ikke har mulighed for at redigere i den objektbaseret bygningsmodel ligesom AAB. Men hensyn til navngivning, kodning, klassificering af byggeobjekterne, har de nu gang i to hospitalsbyggerier, hvor det ene er med CCS klassifikationssystemet og det andet med SfB. Ved hospitalsbyggeriet, hvor de bruger CCS, har de kunne se en besparelse i prisen forhold til det samlede byggeri. De driftsansatte i region Midtjylland har kun været vant til at arbejde med SfB kodning. Det betyder derfor, at de med det nye hospitalsbyggeri nu skal vende sig til CCS. De vil dog udvikle deres driftssystem, så man kan se begge klassifikationer. Det er de på nuværende tidspunkt i gang med at søge penge til. 5.2 Delkonklusion Begge organisationer har set muligheder i at bruge de krav, der bliver stillet i IKTbekendtgørelserne for at kunne effektivisere deres drift og vedligehold. Der ses endnu en forskel mellem organisationerne, da AAB i deres IKT-aftale udspecificerer hvilke byggeobjekter, de vil have informationer på og på hvilket niveau. Dermed modtager de ikke en bygningsmodel, der er overfyldt med informationer. IKT-bekendtgørelserne for henholdsvis offentlig og alment byggeri har haft stor indflydelse på interviewpersonernes fremadrettede drift og vedligehold. Begge har valgt at implementere et driftssystem, der kan bruges i forhold til de krav, der fremgår i IKT-bekendtgørelserne. I disse driftssystemer kan de bruge Facility Management. 6. Konklusion Med et stort indblik i AAB har det været muligt at undersøge IKT-bekendtgørelsens indvirkning på det almene byggeri. Det er tydeligt at mærke på organisationen, at bekendtgørelsen har sat standarderne for, hvordan drift og vedligehold skal fungere i virksomheden. Efter fordybelse i styringssystemerne FM og CAMF blev det vist, hvor driftssystemerne udspringer fra. Specialet har som nævnt haft fokus på driftssystemet Mdoc FM, da AAB har anvendt dette. I det store hele er fordelen ved at anvende et driftssystem som Mdoc FM, at det skaber et større overblik over virksomhedens informationer. Man får foræret informationer ved hjælp af den objektbaserede bygningsmodel men samtidig kan man også trække informationer andre steder fra. 30

32 En af ulemperne ved Mdoc FM er, at det ikke er muligt for virksomhederne at trække priser ud fra systemet, for på den måde at hjælpe virksomheden med at prissætte deres bygningsdele. Mikkel påpeger dog, at dette er under udvikling det kræver noget tid inden det helt er på plads, men det bliver endnu en måde, hvorpå virksomhederne kan hente erfaringstal. IKT-bekendtgørelserne er med til at sætte dagsorden og skubbe en mere digitaliseret drift og vedligeholdelse i gang både indenfor offentligt og alment byggeri. Dette kan specielt ses i AAB, hvor de har udviklet den nye DOtAB app, der er med til at sikre en endnu bedre drift og vedligehold. Interviewet med Birgitte har givet et indblik i, hvordan de kører deres drift og vedligehold i region Midtjylland og indenfor det offentlige byggeri. Deres driftssystemer er ligesom AAB s med til at skabe overblik over de forskellige bygninger og afdelinger. Ved hjælp af kravene om IKT-anvendelsen har det været med til, at AAB og Region Midtjylland har valgt at få integreret et driftssystem, som kan være med til at imødekomme deres ønsker til drift og vedligehold. I forbindelse med effektivisering af vidensdeling har driftssystemerne gjort, at man kan dele og centralisere viden på tværs af alle afdelinger og parter det giver altså et væsentligt bedre data-flow. Derudover er det vigtigt, at hver enkelt virksomhed har styr på, hvilke klassifikationer der skal anvendes. Dette er specielt ved brug af byggeobjekter og de objektbaseret bygningsmodeller i driftssystemer. Det er dermed gjort klart, at bygherre har mange forskellige krav at skulle tilfredsstille i forhold til IKT-bekendtgørelsen, hvor værktøjer som driftssystemer (f.eks. Mdoc FM) og tegneprogrammer (Revit Architecture) har gjort, at IKT-kravene er blevet integreret i den daglige drift og vedligehold. Metodekritik Gennem opgaven er der blevet gjort brug af forskelligt litteratur og informationer. Ved hjælp af interviews fra relevante personer indenfor dette emne har det være muligt at skabe et realistisk og troværdig billede af, hvordan driftssystemer er med til at støtte IKTbekendtgørelserne og skabe et bedre fundament for drift og vedligehold. Det kan godt diskuteres om der skulle være lavet flere interviews, for på den måde at opnå bedre mulighed for generalisering af resultaterne i denne rapport. Det ville have været interessant at have et mere internationalt standpunkt for at se, hvordan standarder indenfor almen og offentlig byggeri differentierer lande i mellem. Grundet tidsrammet har dette ikke været muligt. Det har været svært at finde den mest optimale måde at skabe overblik gennem opgaven. Men ved at starte med at danne en base, har det været muligt at bygge yderligere på og skabe forståelse og nå en hvis dybde med meget indsigt. 31

33 Det har fungeret godt at danne disse konklusioner undervejs for at huske at opretholde det store synspunkt gennem specialet. 32

34 7. Kildeliste Anker Jensen, P. (2011). Håndbog i facilities management. Dansk facilities management - netværk. Anker Jensen, P., Nielsen, K., & Balslev Nielsen, S. (2008). Facilities management best practice i norden. Esbjerg: Center for Facilities Management - Realdania Forskning, DTU Management, Danmarks Tekniske Universitet. buildingsmart. (u.d.). Industry Foundation Classes (IFC). Hentede fra buildingsmart: Bygningsstyrelsen. (2013). Vejledning til bekendtgørelse om anvendelse af informations- og kommunikationsteknologi i alment byggeri. Center, N. C. (06. Februar 2012). NTI CADcenter A/S køber LogFM - og sammenlægger produktet med Mdoc FM. Hentede fra Nti.dk: Center, N. C. (u.d.). Mdoc.dk. Hentede fra Mdoc FM: Eastman, C., Teicholaz, P., Sacks, R., & Liston, K. (2008). BIM HANDBOOK. Canada: John Wiley & Sons, Inc., Hobroken, New Jersey. FM, M. (u.d.). Præsentation af Mdoc FM. Hentede fra Mdoc FM: Klima, -E. o. ( ). IKT bekendtgørelserne. Hentede fra retsinformation: 0 Ministeriet for by, b. o. (31. December 2013). Den almene forsøgspulje. Hentede fra Den almene forsøgspulje: WBDG, g. -W. ( ). Computer-Aided Facilities Management (CAFM). Hentede fra WBDG: 33

35 8. Bilagsoversigt Bilag 1 Interview med Leif Kruse og Elisabeta Lahu fra Arbejdernes Andels Boligforening Bilag 2 Interview med Mikkel Leth Gregersen fra NTI CAD Center, Risskov Bilag 3 Interview med Birgitte Nissen fra Region Midtjylland Bilag 4 DOtAB Bilag 5 Håndtering af AAB s driftsinformationer Bilag 6 Pentagon Bilag 7 Mdoc FM brugerflade 34

36 Bilag 1 Interview med Leif Kruse og Elisabeta Lahu Arbejdernes Andels Boligforening Emne: IKT-bekendtgørelsen og dens påvirkning på drift og vedligehold Dato: kl Sted: Langelandsgade 50, 8000 Aarhus C - projektafdelingen Interview personer: Interviewer: Leif Kruse (LK) Elisabeta Lahu (EL) Dennis Bønnelykke Christensen (DBC) Christian Vestesen (CV) DBC/CV: Hvilke krav og love skal AAB i dag overholde mht. drift og vedligehold? LK/EL: Udleveret papir. Vedledning om drift af almene boliger. Hvis I går ind og søger på nettet, ligger hele loven der. Bagerst sidder vores kontoplaner, der viser hvordan man skal gøre. Den blev så ændret da man fik den nye forvaltnings klassifikation. Det udleveret ark viser hvordan den nye Forvaltnings Klassifikation 2.2 griber ind i vejledning om drift af boliger. I kan finde hvordan regnskaber og budgetter og PV skemaer er angivet i den her bog, hvordan skal virke. Vi er de områder, der er mest lovlåst i Danmark. Der er ikke ret store muligheder for os. Der står i hvordan det BURDE være, men spørger man rundt, så er der ikke mange der følger den. DBC/CV: Så går vi til den nye IKT bekendtgørelse. Hvilke tanker gør I i forbindelse med IKT koordinering på et projekt? EL: Bygherre skal sikre at andre udføre hvad der står i 3, og i fleste tilfælde er det projektlederen eller projekteringslederen. Det skal så specificeres i IKT aftalen hvem der står for hvad. DBC/CV: Er IKT aftalen en I selv har formuleret eller bruger I fx bips? EL: De sidste to projekter har vi brugt paradigmer fra Bascons, der er mere overskuelige. Bips har for mange punkter og er meget uoverskuelig. Den vi har brugt er kun på 10 sider, hvor Bips er på cirka 30. Vi bruger ikke Bips, selvom jeg har kigget på det og lavet nogle prøver på det, men det er ligesom det ikke rigtige fungerer. DBC/CV: Så det er bygherrerådgiveren, der står for at videregive de informationer i forhold til de andre parter. EL: I afd. 25 har vi lavet en fælles IKT aftale, hvor vi sagde hvad vi vil. Så lavede de den og sendte til mig, som jeg så rettede, indtil det så godt ud. I afd. 24 har jeg så lavet den og sendt, og så har de kommenteret den eller rettet i den, indtil begge var tilfredse. I alt har vi lavet, hvis vi tæller afd. 75 med, og der havde vi et problem. Vi fik ikke sheets og detaljer med, selvom der stod at det skal 1

37 afleveres i original format. Der stod bare ikke der skulle afleveres detaljer og sheets, og derfor skulle vi betale ekstra for det. DBC/CV: Hvad har IKT bekendtgørelse betydet for jeres drift og vedligehold? Fordele og ulemper. EL: Hvis vi kigger lidt på det vi tegner, hvor alle bygninger skal klassificeres og navngives, så er det bare tidskrævende. Det kan man godt sige, er en ulempe. Man skal ind og tegne og løfte informationsniveaet på de forskellige bygningsdele, fx hvis de skal bruges til drift på et senere tidspunkt. Så ja, ulempen er den her tidskrævende proces. Men der er klart flere fordele. DBC/CV: Så du mener, der er flere fordele end ulemper, fx hvis du ser den i forhold til den gamle IKT bekendtgørelse? EL: I begyndelsen bruger man selvfølgelig mere tid på at klassificere og kode, men ligeså snart man er færdig med en bygning i 3D og sender den videre til drift, så er det meget nemmere at lave ændringer, ændre koden fx nummer for hvidevare. Så arbejder de bare videre på det. DBC/CV: Så man kan sige at arbejdsgangen er blevet forbedret efter den nye IKT bekendtgørelse er trådt i kraft? EL: Ja, helt bestemt. DBC/CV: Hvilke specifikke paragraffer, hvilken har haft størst indflydelse på drift og vedligehold? EL: Mest 10 med digital leverance med digital aflevering. Det er den der har stor betydning. Når man får de her as built tegninger, der skal stå præcist hvad de skal indeholde der skal stå klassificering. Vi har også helt præcist skrevet i IKT aftalen hvilke bygningsdele der skal have hvilket informationsniveau, så en tegning ikke løftes til niveau 6 fra niveau 2. Det er forskellige bygningsdele vi skal bruge til drift, og det er s dem vi skal have på niveau 6. DBC/CV: I skal melde ud fra starten hvilke specifikke dele I har vedligehold på? Ja, det står i IKT aftalen under 10 hvilke ting, vi vil have på niveau 6. DBC/CV: I går ind og definere hver enkelt bygningsdel, så I undgår for at få for meget information? Ja, vi specificerer dem vi vil have på niveau 6. Det vi har brug for er dem vi skal bruge til drift. DBC/CV: Hvad med i forhold til klassificeringen. Der er jo mange systemer. Vi bruger Forvaltnings Klassifikationen, men Cuneco er i gang med deres CCS. Det kan være på et tidspunkt får vi en fælles klassifikation. Det er bare ikke helt færdigt. Det er blevet testet, men er ikke helt færdigt. Det er godt at have to klassifikationer på en tegning, så Forvaltnings Klassifikation og så CCS eller hvad de nu bruger. Den anden bruger de så til CCS, og fordelen ved CCS at det beskriver type-id og placering. Er meget specifik. I forhold til Forvaltning Klassifikationen, så er der gruppe, der hedder hvidevarer og det er det. Ingen placering. CCS har komfur for sig, både type, nummer og placering. Vi ved også at et komfur er i den her lejlighed, fordi vi også skriver lejlighedsnummer ud fra forvaltnings klassifikation. Når CCS er færdig kan det være, at det kan oversættes til Forvaltnings Klassifikation. 2

38 DBC/CV: Så når I skal i gang med et nyt projekt, så kan I godt melde ud fra starten at I gerne vil have Forvaltnings Klassifikation, så sørger I for at de specificere efter det? Ja, men får vi et nyt projekt skal skrive vi ønsker to klassifikationer på vores objekter. Forvaltnings Klassifikationen og så det klassifikationssystem de bruger, i forbindelse med udbudsmaterialet. Statens Forvaltnings Klassifikationen hjælper ikke dem så meget. DBC/CV: Forvaltnings Klassifikationen bruges primært ved ejendomsportefølje og drift og ikke så meget ved projektering? Nej, men jeg har været på IKT uddannelse, og vi skal bruge Forvaltnings Klassifikation. De er lovgivning. DBC/CV: Har der været problemer med de projekterende, at de har haft svært ved klassificere med Forvaltnings Klassifikation? LK/EL: De får den her liste, men der er overhovedet ikke ret mange, der kender til den klassifikation overhovedet. Vi er underlagt at det skal være sådan. Hvis de vil arbejde for os, så skal de lære den. De spørger hele tiden om vi bruger Bips, men det er den vi kører efter. Og du kan se, at når der er seks ting, der går ind under den samme forkortelse, så skal man hver fald finde nogle andre måder at beskrive emnet på, så man er sikker på at få det man gerne vil have. Hvis du bare læser bygningsinventar hvidevarer, så ved du jo ikke om det er et komfur eller ovn, men der står kun bygningsinventar i kodningen. Jeg forstår slet ikke de skiftede vores SfB kodning ud med det der, da SfB kan sagtens bruge til at arbejde videre på. Det der er bare lavet om. Når de bliver færdige med de her CCS, så bliver der ingen problemer med at oversætte fra Forvaltnings Klassifikation til CCS, da det igen er type-id, osv. de så bare bruger. DBC/CV: Ja, vi har lidt være inde på det, men hvordan I sikrer at I ikke får for mange informationer i jeres model. Det er penslet ud i IKT aftalen. Vi skal ikke betale mere end nødvendigt. DBC/CV: Samtidigt heller ikke betale for lidt, fx som du sagde med detaljer og sheets. Det gælder om ramme præcist. EL: Præcis, detaljeringsgrad. Vi tegner selv i Revit, og når vi får alle de her tegninger, så tegner vi selv alle de rum og gøre dem færdige. Så betaler vi for det færdige arbejde, da vi ikke kan projektere i Revit. Så tegner vi selv resten færdigt. DBC/CV: Hvad er jeres holdning til IFC formatet, der er blevet et lovkrav i den nye IKT bekendtgørelse? EL: Ja, når man laver som IFC format, så kan bruge de her gratisprogrammer, fx Solibri, som alle kan downloade. Så kan man gå gennem bygningen i 3D. Vi bruger mere Autodesk 3D program, Design Review. Jeg tror den er bedre, hvis man skal sende de her plantegninger. Det er ligesom PDF for dem, for så man kan printe ud og det hele. Der står det er IFC eller en lign. Format, så det er bare noget hvor man kan se det i 3D men også se de her plantegninger. DBC/CV: Kan man bruge 3D modellen hvis den bliver afleveret i IFC? Så kan man ikke gå ind og arbejde i den, på samme som hvis du havde fået modermodellen? Det kunne vel også 3

39 være en ulempe? EL: Alle dem der skal rette tegningerne, har et program til det. Det er mest dem, der ikke har tegningerne. Fx entreprenøren. Alle andre udveksler deres fagtegninger, så de har deres tegninger, og der står helt præcist hvad de kan rette. Når de er færdige, så gemmer de det i et IFC format. DBC/CV: Når I modtager et IFC format med 3D modellen og du bruger den i Revit, kan du så godt få lov til at ændre i den? EL: Nej, ligeså snart de er færdige med de her as bulit tegninger, så skal de sende en sidste IFC fil. Den IFC bruger man også til at printe tegninger. Men det skal være as built. Selvfølgelig når de er i processen, så skal også være den her historik hvilken version er tegningen. Også i det her projektweb, så skal vi også sikre alle ved præcis hvilke tegninger, der er de nyeste tegninger. Så ved man ikke om de er gældende eller om det er. DBC/CV: Har I lavet andre tiltag i forhold til IKT bekendtgørelsen, der har hjulpet jer fx med driften? Nogle apps? Det vi gør med vores Dotap, som vi har udviklet for Ministeriet, den er vi ved at begynde at rulle ud i vores lejligheder og teste på vores maskiner. Indtil videre har vi lagt små billeder og vi har oprettet nogle med bygningsdele. Jeg regner med når jeg er færdig, så har jeg omkring data, der er fotograferet ind, som vi kan via Mdoc FM hente ud på de maskiner (ipads), som vores lokale inspektører bruger, og så vi selv herinde kan via den byggesynsapp, DotAp, og den som NTI har lagt ud på nettet. Der er så lige det problem, at den byggesynsapps NTI har, gemmer billederne i samme database som Mdoc FM, hvilket betyder at en søgetid kan komme op på 6-7 minutter, så lige i øjeblikket er vi ved at vi skal have billederne væk fra databasen igen og over på et andet sted, så de ikke tynger databassen, når vi henter data. Der får vi undersøgt vores SKL database, om det er bedst at gemme på en fast server eller om vi kan arbejde med virtuelle servere. Det er specielt når vi kører med vores 50 års oversigt. I starten brugt det omkring 5 min. for at få et skærmbillede. Nu bruger det kun 1 min for et skærmbillede, men det er stadig længe hvis vi skal vise en demo. Så er vi ved at udvikle en webbaseret Mdoc FM i stedet for det nuværende clientversion. Jeg har fået den seneste nye version her til morgen. Det er en version, hvor man kan få sine arbejdsopgaver når vi laver PV skemaer for 58 afdelinger, kan vi via forvaltningsklassifikationskoderne definere hvem der er sagsansvarlig. Når man så har en række ved siden, der beskriver hvilken afdeling det drejer sig om, så ved vores system herinde, at en inspektør der har 7 forskellige, kan klikke op på arbejdsopgaverne og så får han et dashboard, hvor han imellem felterne på dashboardet kan se hvilke arbejdsopgaver, der er i gang og hvilke der ikke er påbegyndt endnu. Så kan styre det vha. et dashboard. Så kan de få meget dårligt samvittighed, der viser at den enkelte inspektør er langt bagefter. Vi kan også kombinere det med vores byggesagsstyring, så hver gang der kommer en regning, så dukker den op på dashboardet. Den fortæller at du har brugt 80% af pengene til arbejdsopaven, så der kan man også via dashboardet se om man er ved at være færdig. Det bliver lukket op sådan, at hvis du bliver valgt som afd.formand, og du kan så også følge hvor mange rektifikationer, der er skrevet og hvor langt er arbejdet kommet på de forskellige PV opgaver. Vi er meget undervejs til at vi kan lave en virkelig synlig model, som alle kan se og forstå hvad vi går og laver. Mange hører bare Mdoc FM og går i sort med det samme. Vi arbejder også på at få lagt synsplanlægning ind i Mdoc FM, hvor du kan gå ud i lejligheden og få opdateret bygningsdelskortene og få synsrapporten frem. Fx lige på den specifikke lejlighed har man lige lavet den arbejdsoperation, og når makkeren kommer ud og opdaterer med QR koden, så 4

40 får makkeren de oplysninger du havde lavet dagen før, så han også er 100% opdateret. Vi er snart ved at være færdig med at have sat alle QR koderne op. Hver varmemester bliver så lært op i de forskellige afdelinger. Vi får helt sikkert noget ud af det, ikke i dag men i morgen. Det er det vi får ud af de informationer. Vi prøvede med afd. 75, hvor vi prøvede at hente informationer direkte fra Revit, men da der ikke var specificeret hvilke informationer vi skulle bruge, fik vi en helt bunke af informationer. Alle de informationer skal luses ud og det er så det, de laver inde på tegnestuen og de definerer de begreber, vi vil vide. De begreber tegner de ind i vores tegninger. Vi har taget en beslutning om hvad der er væsentligt, og det tegner tegnestuen ind i alle de tegninger, som de sidder og laver. Det er det vi får defineret, når vi hæver niveauet fra 2 til 6. Vi skulle gerne være omkring det hele om år. DBC/CV: Først og fremmest er det alpha-omega, at i får udarbejdet de ting, I har vedligeholdelse på? LF/LE: Ja, det er dem vi får defineret. Vi har valgt at vi laver alle køkkener som grupper, undtagen vasken og andre hvidevare. Så når det er grupper, så tager den ikke det med, så vi undgår at få de overflødige informationer på underskabe og håndtag fx. Vi får jo også efterhånden som systemet bliver lavet, listen over vinduerne, hvor håndværkeren ringer til fabrikken, hvor der kommer produktionstegninger. Dem får vi jo. Dem skal vi bare have sendt og hæftet på vores bygningsdelskort. Så kender vi jo glasmål, stangmål og det hele. Det kommer jo fra de lister, de har. Så er der ingen grund til at vi skal gå ud og måle og finde ud af efterhånden som vi kommer rundt i de forskellige afdelinger. Så får vi, via IKT, dem til at lægge de oplysninger ind på vores bygningsdelskort. De kan ligeså godt lægge dem ind. De har dem jo lukket op. Det er noget vi ligger over til den udførende, så kan vi også bruge det som kvalitetssikring. Det er altså noget, men det tager tid jo. DBC/CV: De vedligeholdelser der kommer på fx et vindue, bliver det linket op på objekterne i 3D modellen eller kommer det i en IFC fil, som I så senere kan bruge til drift og vedligehold? LK/EL: Altså det der er meningen, er at ham der leverer vinduerne skriver at beslagene skal justeres to gange hver andet år, så er det når varmemesteren åbner op på vinduet, så kommer det frem at han skal huske at justerer dem, eller i langtidsplanlægningen skal man jo lægge i tournus at han skal huske justerer dem. Så den drift og vedligeholdelsesvejledning som entreprenøren på det objekt, han installerer, skal lægges ind i vores PV planlægning, så vi kan får sat pengene af til det. Det kniber nogle gange lidt. Man skal være frygtelig disciplineret fremover. Det kan ikke gå som for 10 år siden hvor vi arbejdede efter runde tal. Det hele kræver dokumentation i dag. Med hensyn til tegninger, når vi hæver niveaet fra 2 til 6. Når vi klikker på vinduet, så er der nogle parametre vi skal skrive. Om de linker det eller skriver det, så ved vi præcis hvilken håndtag- eller dørleverandør. Vi skal også have noget inde fra tegningerne, men hvis vi får det hele samlet et sted, så bliver det måske et problem, når man åbner den. Hvis man åbner den for en lejlighed, så får man måske 20 ting, hvor kun en af tingene er brugbare. DBC/CV: Har I prøvet om det kan lade sig gøre at uploade et PDF til et bygningsdelskort? LK: Det kan det i webversionen men ikke client versionen. Det er så åndssvagt, hvis du kører 6 sider PDF igennem. Så viser den kun side, hvorimod på webversionen viser den alle siderne. Der sker en forbedring og udvikling. Om 1 til 2 år arbejder vi kun i webversionen og så findes client versionen nok ikke. 5

41 DBC/CV: Linker den ind på et bygningsdelskort, er der så mulighed for at man åbner PDF en ligesom billeder eller hvordan? LK: Det bliver ligesom når du bladrer i vores lejlighedsmapper. Man skal klikke hver gang man skal have en ny side. Der sker meget lige for tiden, hvor vi holder møder og stiller spørgsmål, og så går de hjem og retter, og så mødes vi igen. Der er masse modeller undervejs, men vi ska lige have bunden med. Når vi har lagt dataene ind, så kan vi forfine dataene, som vi er i gang med. Førhen lagde vi dem som fx tag, men i dag hedder det tagbelægning og taghætter, osv. Ifølge Forvaltnings Klassifikationen. Hver bygningsdel får sit eget ID nummer. Sådan et bygningsdelskort skal opgraderes fra 1 til fx 5 bygningsdelskort uden det skaber kludder i økonomien. I starten tegnede vi en afdeling ind, og så fandt vi så ud af at det kunne vi ikke bruge til noget, så vi har lært noget om hvordan det skal deles i forhold til FK og hvad vi vil have ud af det. Vi skal passe på vi ikke gør så meget, at vi taber overblikket igen. DBC/CV: Du nævnte før, det lød som om der var problemer med de udførende og hvad de afleverede til jer. Kan man sige I har mere fået en fælles agenda med rådgivere og afstanden mellem jer og udførende er større? LK: Vi skal faktisk først køre digitalt udbud over 20 mio., hvorimod i det offentlige er det over 5 mio., så inden vi møder de første sager, hvor vi har krav om IKT, så skal vi lærer det og finde ud af hvad det er for noget. Klostervangen har vi bygherrerådgiver på, hvor vi så er bedre tunet end vi var ved afd. 24. vi skal alle sammen lære sådanne ting, og vi klogerer. Afdeling 25 har vi selv tegnet, og vi har sendt tegninger til dem, så skal de bare arbejde videre på dem. Når den kommer tilbage, så læser vi ikke deres tegning og bruger den. Sker der nogle ændringer derover, så tegner vi dem selv, fordi vi har råderetten, så læser vi bare den as built, så forsvinder de rettelser, der er kommet undervejs. Vi har arbejdet med new construction og exiting i Revit jeg vil gerne have alt det der er nyt ind i min tegning, og så bagefter rette en væg, hvis der fx er kommet et vindue. Det skal gøres den vej. Vi har jo 1200 flytninger om året, hvor vi kontroller at lejemålene ser ud som de gør. Vælter de en væg, og vi så kommer og ser væggen er væg, så må vi tegne lejemålene op igen, så vi får dem kontrolleret. Vi har tidligere oplevet en blok, hvor tegningerne overhovedet ikke passede og det kan man jo ikke vise til en indflytter, som tror han får det ene, men så egentlig får noget helt andet. Tegnestuen forsøger at tegne de tegninger ind vi har i kælderen, så vi får dem opdateret. DBC/CV: Hvorfor har I valgt Mdoc FM og hvad har det haft af betydning? LK: Før Mdoc FM har vi haft vores vedligeholdelse i Excel ark. Vi har elektroniske data helt tilbage i Dengang sorterede man formålskoder, der var vores eget klassificeringssystem. Det kan vi bruge til økonomiske betragtninger. Når vedligeholdelsesudgiften bliver højere end rentetabet, så kan man gå ind og sige, at det er mere fornuftigt at bruge pengene nu. De data og kurver kan vi stille op helt tilbage fra Vi har mange års erfaring med det. Da de startede med SfB klassificering i 87, så erstattede vi bare formålskoderne med SfB. Alt vores gamle vedligeholdelses kørte vi i et Excel regneark, og for at de var ens, havde vi nøgletal. Så havde vi fået en pris fra rørlæggeren, så skrev vi hvis vi skulle bruge 200 radiatorer, at 200 x nøgletal x pris. Det har vi så i dag lagt over i Forvaltnings Klassifikationen, som kom første gang i Da den kom, begyndte vi at sige, at hvis det skal laves til det der, så begyndte vi at finde ud af hvad vi skulle gøre. Så så vi en demo fra NTI i Vejle, hvor de havde købt et system (Mdoc FM), så sagde vi. Det skal vi have! De væsentligste ved Mdoc FM er, at meget kan vi læse ind fra de databaser, vi 6

42 har i forvejen. Fx med app en, DOtAB. I stedet for at vi skulle læse alle data over i et andet program, så kunne vi læse vores data direkte over i det i stedet for manuel indtastning. DBC/CV: Så det var mere automatisk at anvende Mdoc FM end fx COWIs Caretaker? LK: Ja. Afdeling 24 skulle køres i ibinder, men det var så sindssygt dyrt. Det kan ikke passe, at det skal koste så meget. Vi har den holdning, at alt det vi ved, skal vi have hos os selv. Vi har nu lavet en udbudsportal, så vi ikke er afhængige af ibinder eller Byggeweb. DBC/CV: Ja, det mener jeg også er et krav i IKT bekendtgørelsen. At man samler det et sted. Det er jo stadig et minimumskrav. LK: Ja, det er noget vi har udviklet. Det betyder så at de Revit tegninger vi har ligger vi derinde, og når de så er revideret eller lign. så får vi dem jo tilbage. Når entreprenøren installerer et eller andet, så kan han ligeså lægge VVS nr. eller lign. ind. Så er vi fri for at lede efter det senere hen til bygningsvedligeholdelsen. Når vi opretter en byggesagsstyring, så lægger vi nogle oplysninger derind og der bliver et link mellem den og udbudsportalen, så når noget skriver noget ind i byggesagsstyringen, så kommer det direkte over i udbudsbrevet over i udbudsportalen. Den henter selv det du selv har skrevet over som en del af udbudsmaterialet. Hvis vi har nogle aftaler med håndværkere, så søger vi fx på hust og får Hustømrene, så kommer deres oplysninger også ind i byggesagen og udbudsportalen. DBC/CV: Hvilke funktioner har Mdoc FM og hvilke bruger i? Økonomi, vedligeholdelsesplaner? LK: Lige pt. bruger vi kun bygningsvedligeholdelsen. Vi starter med det, så vi ikke mister overblikket. Mdoc FM har også et økonomisystem, men de er helt vilde med at bruge det nuværende, så det kan vi ikke bare lige udskifte. Vi udveksler økonomiske data og langtidsplanlægning på PV via en webpart med KTP, som arbejder videre med det deroppe. Det kan meget det program, men vi bruger kun en lille del af selve programmet. Når de data er fyldt ind, kan vi altid begynde at supplere. DBC/CV: Det er vel også en del af bygningsmodellen, at man kan bruge de arealer som man har navngivet i forhold til gulvareal, vægoverflader, osv. Ja, det er noget der kommer derind. Det kan vi bruge med syn. Hvis vi også tager udearealer, osv., så ved vi også hvor meget udeareal vi har, så kan vi lægge det ind i modellen, så man kan se på hvert enkelt afdeling hvad de har af udearealer og sådan. Det seneste vi har gjort, er at vi lagt 3D tegninger ind i Mdoc FM og hvis du kommer en dag og siger, at jeg skal ud i den afdeling og have en kældertegning. Så kan du nøjes med at trykke på modellen, så får du en kældertegning. Hvis du så skal have stueplanen, så trykker du bare på 3D modellen, hvor du kan klikke at du vil have den ene tegning eller den anden. Vi læser Revit tegninger direkte ind i Mdoc FM fra databasen, hvor tegningerne ligger. Så du kan gå ind på en hjemmeside hvor du bare kan kigge afd. 6, så kan du finde alle tegningerne derinde. DBC/CV: Det er næste skridt? 7

43 Det er ved at blive lavet nu. Det er det der kommer på et af vores dashboards. Der har vi så lige sendt to afdelinger ud til test ude ved NTI, hvor de er ved at lave et dashboard, hvor de ligger dem ind, så vi kan se hvad der sker. En etageafdeling og vores villaafdeling omkring Riisvangen, så det er to forskellige typer afdelinger. Det er vi ved at teste nu, så vi er sikker på at vi får det hele med. Det bliver en hjælp til en ansøger, der kan gå ind på den samme tegninger, hvor man så kan få alle oplysninger på et sted. Vores drøm i arkitektgruppen er, at det når alle informationer engang bliver færdige i Mdoc FM, så når de bagefter skal syne og de så ændrer på et komfur, så skal de kunne komme tilbage og så bagefter opdateres det automatisk tilbage til Revit tegninger. Der skal laves noget smart, for vi kan ikke ændre geometrien. De skal så udfylde nogle oplysninger i stedet: type, vvs nummer. Når de så kommer i Mdoc FM, så kommer de som parametre i families i Mdoc FM, og så skal det kunne vises i Mdoc FM, hvor man kan klikke på 1, 2, 3, 4 komfurer og så opdateres tegninger. Ligeså snart der er noget der er ændret i Mdoc FM, så skal den overfører det til Revit og så skal vi have en angivelse en farve fx at nu er den færdig, så vi slipper for at åbne tegningerne hele tiden. Så får jeg måske en og jeg ændrer det, så det ikke står og blinker mere. Men det er den vej vi skal. DBC/CV: I har ikke prøvet at arbejde hernede på tegnestuen. Altså med at få et plugin ud til Mdoc FM? Jo, han har hentet det. Der er to afdelinger, han har hentet oplysninger ind i Mdoc FM. Afd. 25 og 30. DBC/CV: Fungerede det optimalt? Han siger det ser godt ud. De skal jo også lære at bygge det program efter hvad de skal søge efter over hos os. Det er noget, de udvikler specielt til os, og så det kan være de måske kan bruge det til andre. Vi tester det, og så for at lave så lidt manuelt arbejde som overhovedet muligt. Alle de fejl vi finder når vi indlæser data, som er smuttet igennem systemet før. Vi får rettet op på rigtig meget, bl.a. nogle afdelinger tror de har rigtig mange penge tilbage, men pga. manuel indtastning så har de lavet fejl og det har systemet nu fundet og er begyndt at rette op på. Vi tester og udvikler. DBC/CV: Det fungerer ikke automatisk endnu? Nej, så langt er vi ikke kommet. Nu skal vi have de data ind først og vi udvikler sideløbende. Det er ikke noget med det bare læses ind og så fungerer. Vi har også en testserver, hvor tester det hele på, så vi er sikker på testen ikke ødelægger noget at det vi har oprettet. Når vi kommer og siger til NTI, at vi har en god idé, så tester vi det og finder ud af hvordan det reagerer. Det gælder om at få opdateret vores database i Mdoc FM og det er så pga. den QR kode teknologi, at så starter vi med at alt det vi har vedligeholdelsespligten på indvendigt, som bliver til data med tilhørende fotos. Så kan vi bagefter begynde at sige hvad vi har vaskeriet og legeredskaber. Så kan måske få en QR kode hver, og så inddeles derefter. Så kan vi udbygge informationsniveauet eller man kan gå ned i et værkstedslager, hvor man går ind og siger man får en QR kode, hvor der så står noget en hammer og traktor. Når det oprettes, så kan ligeså godt ligge sikkerhedsmanualen og brugermanualen ind, så den næste der scanner koden, får han alle oplysninger. Vi ved godt hvor vi er på vej hen, men tingene tager tid. DBC/CV: Har I arbejdet med integrationen af Revit til Mdoc FM? 8

44 LK/LE: Vi har kun prøvet at køre afd. 75 nede på havnen. Det var så der vi fik små 100 lejlighedskort, hvilket var alt for meget. Så begyndte vi at snakke families. Så får vi det begrænset, så vi kun har stykker pr. lejlighed i stedet. Det var nogle teknikker vi benyttede efter. Så har vi gået tilbage og revideret de tegninger vi allerede i Revit 3D til det niveau, som vi nu lærte fra projektet på havnen. De erfaringer I har taget med derfra med opbygning af families og sådan noget. I har ikke fået nogle vejledninger til hvordan i skulle opbygge dem fra NTI. De må have en forudsætning for hvordan de skal bygges op? Vi skulle dele dem for at de kunne læse de rigtige informationer, fx komfur og hvidevare for sig. Før har vi lavet køkkenet det samme, hvor komfur og det hele var sammen. Men så skulle vi dele dem for at vi kunne læse det. Det vi også gjorde på havnen, var at vi tog den tegning, som rådgiveren havde sendt til os. Der fandt vi også ud af at de ikke var så skrappe til at tegne i Revit. For at det skulle være hurtigt, så har de brugt 2D tegninger for fx køkkenet og badeværelset. Så skulle vi selv tegne det op i 3D. DBC/CV: Kunne man så ikke forestille sig at i stedet for at I sidder og tegner og skal rette det en rådgiver sender til jer og I må vel ikke projektere selv, I skrev specifikt i IKT aftalen hvordan vi ville have det? Den havde vi ikke dengang nede på havnen. Der var den ikke trådt i kraft. Det er så nogle ting, vi har lært undervejs, som vi så samler op og hvordan vi får til at fungere i vores regi. Der er kommet væltende noget fra højre som bryder ind i vores daglige arbejdsrutine; den IKT bekendtgørelse. Der er nogle ting vi ikke kunne nå at rette på de 3-4 dage. Vi har lært noget efter den nye IKT bekendtgørelse, hvilket er noget der har givet noget ekstraarbejde. Nu har vi lært så meget, så siger vi næste gang, at de skal huske at! Så passer det i vores system. Det kan godt være de tegner i et andet 3D program, men det skal afleveres så vi kan læse det i Revit. Nogle informationer forsvinder dog gennem IFC. De der konverteringsprogrammer virker altså heller ikke efter hensigten. Vi må ikke sige at SKAL læses i Revit, men vi har sagt det skal afleveres så VI KAN læse det i Revit. Det er jo så der IFC en kommer ind. Det var ikke imponerende det vi så da vi i Odense til konference mht. IFC formattet. DBC/CV: Så man lidt sige, at efter IKT en er kommet, fra før hvor der var langt mellem rådgiver og bygherre, så er det softwaren der sætter begrænsninger nu? LK/EL: Softwaren, ja. Hvis vi har en tegning, vi tegner i Revit. Det vi håber på at gøre når vi er bedre inde i det, når vi skal bygge 300 kollegieboliger nede på Godsbanen. Allerede når projektet går i gang og de begynder at snakke om hvordan det skal se, så er vi allerede i gang med at tegne lejlighedstegningerne. Inden det er færdigt, så er vi jo begyndt at leje det ud og regnet ud hvad huslejen bliver. Vi er jo begyndt at lave bygningsdelskort og begyndt at langtidsplanlægge, så når det står dernede, så har vi allerede tegnet det heroppe via det informationer vi kræver af rådgiver og entreprenør. Når de ved at de har bestilt vinduer, så skal vi have den information med det samme, så vi kan arbejde med det i vores model i Revit heroppe. Vi skal ikke have det as built, så får vi det først et halvt år efter det er gået i gang. Det er jo for sent, så har vi jo lejet det hele ud. Vi bliver jo nødt til at arbejde med nogle budgetplanlægninger, så ligeså snart de ved køkken og sanitet, så vi kan arbejde det ind i modellen. Jo bedre modellen er indarbejdet, jo bedre kan vi lave et budget. Det er det der kommer til at ske dernede. Ligeså snart rådgiveren begynder at tegne, så ved vi hvordan 9

45 det ser ud. I Mdoc FM, som så laver langtidsbudgettet. Det er det der sker nu her, når vi skal i gang. Det er noget af den erfaring vi har lært fra havnen. Nu kan så nå at komme foran. Nu samler vi ikke op på nogle projekter, nu kan vi via erfaringen begynde at stille krav allerede inden de går i jorden. Det skal være sådan at vi ved ud fra niveau 2, så skal vi kunne levere tegninger til bygningsudvalget, så de kan sige at vi skal have IKEA køkken og fine klinker på gulvet. Vi har prøvet at lave sådan en videofilm gennem 3D, hvor de så opdager at der mangler da skuffer eller det skab står forkert. Det billigste er jo være besluttet og præcis inden entreprenøren starter, for han kræver 500kr for at skifte eller indsætte fx skuffer i køkkenet. Så må vi tilpasse køkkenet eller andre ting, og det er nogle af de ting man kan se på en video, når det er tegnet op. Vi kan udluse fejl allerede inden det er opbygget. Det er også noget entreprenøren kan bruge i Solibri fx og se om der er kollisioner med VVS rør og bærende stål. På den måde håber vi på at komme foran og undgå fejl. DBC/CV: Det må have været dyrt at udvikle. Har det været det værd? LK/LE: Revit har været fantastisk og har været et løft i vores strategi og ansigt ud ad til. Det er bl.a. nemmere for folk at se deres lejlighed i 3D. DBC/CV: I bruger vel ikke kun Revit i forbindelse med drift og vedligehold, men kan også bruges i forbindelse med udlejning? LK/LE: Du kan få en lejlighedstegning, hvor man ser skæve hjørner og runde buer som en Revit tegning, så man kan se: hvordan helvede møblerer jeg den her lejlighed? Det er også nemmere at se vindueshøjden på. DBC/CV: Kunne man ikke forestille sig med walkthroughs i Revit, så de kan få en 3D gennemgang? Det er næste skridt. Vi sender dig en lejlighedstegning og et gratisprogram, der kan åbne 3D. Så kan vi vise hvilke skillevægge, du må fjerne. Så kan du også se hvordan det ser ud, hvis du maler din væg rød. Når indlæser tegningen, er der vedhæftet et program, der er gratis, der kan vise 3D af lejligheden. Det er noget af det store arbejde tegnestuen laver ud fra Revit. Vi hæver serviceniveauet med det her. Vi skal bare have tegningerne med først før vi går videre. DBC/CV: Hvordan er de andre boligforeningers niveau? LK/EL: Vi er langt foran og de er imponeret. Vi har jo vores ting for os selv. Det gør det meget smartere. Hvor andre har deres tegninger liggende hos nogen, der har tegnet det for dem. Så koster pludselig penge hver gang de skal have adgang til dem. Nu fx Årstiderne i Silkeborg. De får sendt deres tegninger langt væk for at få dem rettet og hvis du så har en indflytning, så får de en tegning, er måske ikke er opdateret endnu fordi det tre måneder før den kommer retur. Vi kan få det lavet meget hurtigt os selv. Det er fordelen ved vores egen tegnestue. DBC/CV: Når I navngiver families selv. Det er der vel også et formål at gøre mht. driftssystemet. LK/EL: Ja, så får vi også et system. Så navngiver vi dem komfur_ og så den type, det er. Det vi bruger dem til over i driften, så når vi laver en langtidsplanlægning. Der skriver vi, der er 380 komfurer og 380 lejligheder, der har hver deres komfur. Hvis det ene skal skiftes i 2014 og et andet skal skiftes i 2013, men søgeprogrammet går på komfur_type, så kan vi se i programmet, at der kun skal skiftes 378 komfurer. Så kan vi et mere nøjagtigt tilbud til licitationen. Programmet søger selv i 10

46 lejlighedskortene. Hovedkortet siger måske 380, men fordi lejlighedskortene er opdateret og families er skrevet med den rette kode, så kan det være det kun er 378 komfurer. (Eksempel: toilet_ifö-2-6). DBC/CV: Hvad kan man bruge bygningsdelskort til i FM systemet hos AAB? Dem bruger vi, når vi er færdige med opdatere dem, så ved vi helt sikkert hvor komfuret står i hvilken lejlighed. I villa afdelingerne skifter man tingene individuelt ret ofte, og hvis han flytter om et halvt år, så i stedet for at han tager det nye med og ikke det gamle, så man kan se på bygningsdelskortet, hvor der er et foto af det nye, at: hov, det er da vist forkert det her. DBC/CV: Det må også have givet et meget større overblik i forhold til afdelingernes økonomi? LK/EL: Ja for pokker. Vi har afdelingerne rundt omkring og den viden, der ligger inde med, skal deles med os andre. Det skal også være sådan, at det jeg lavede for fem år siden, skal ligge derinde så kommer der en ny, kan finde det og få en opdateret viden. DBC/CV: Så I genanvender informationerne? LK/EL: Yes! Vi vidensdeler så vidt det er muligt. Hvis en har arbejdet alene, så skal de andre omkring stadig vide det! Man bruger frygteligt meget tid på at lede, og det vil vi gerne undgå ved at placere vores viden et sted hvor det er tilgængeligt for alle. DBC/CV: Byggesagsstyring over Mdoc FM. De id er bygningsdelene har, som man tilknytter byggesagsstyringen. De informationer man har lagt ind vedr. økonomien på den bygningsdel? LK/EL: Det er ved at blive lavet sådan, at hvis du har sat 5 mil. af på ID et og lavet byggesagen, så får byggesagen at vide, at måske kun kostet 4,75mio. Vi er ved at lave et program der siger, at de ID er du tilknytter til en arbejdsopgave skal du i tilbudslisten definerer prisen p den enkelte ID og når du skriver fakturaen, skal du fakturer i forhold til ID. Så når vi læser tilbage, så kommer den og siger at det er så mange penge værd. Så er vi ved at få lavet det sådan, at det kan lave succes kalkulation, så det ene vindue koster 3000 og det andet koster 7000kr, så middelværdien er omkring 5000kr pr. vindue. Senere kan det benyttes når man skal udskifte andre vinduer. NTI er ved at lave succes kalkulation på bygningsdele i en database delt med Aalborg Universitet. Deler erfaringerne simpelthen. Når arbejdsopgaven er færdig, så er ID et opdateret og er ID et også med i en anden opgave, så er ID et også opdateret deri. Det er så også en afgren af Revit og Mdoc FMs udvikling. 11

47 Bilag 2 Interview med Mikkel Leth Gregersen fra NTI CAD Center, Risskov Emne: IKT-bekendtgørelsen og Mdoc FM- systemet Dato: kl Sted: Julsøvej, 8240 Risskov NTI CAD Center - Aarhus Interview person: Interviewer: Mikkel Leth Gregersen (MLG) Dennis Bønnelykke Christensen (DBC) DBC: Hvorfor udvikle Mdoc FM? MLG: Jamen, det gjorde vi fordi, der er et behov for at kunne digitalisere sin bygningsmasse og samtidig forudsige, hvor mange penge der skal bruges på drift og vedligehold et vis antal år ud i fremtiden. Derudover var der et behov for kunne holde styr på alle sine bygningsdele i og omkring vores bygningsportefølje. Alt efter hvem vores kunder er, så er der forskellige behov til Mdoc FM-systemet. Vi har nogle offentlige bygherrer som i første omgang kun har brug for at få et overblik over deres m 2 på deres ejendomsporteføljer og så har vi blandt andet nogle boligforeninger, som har brug for at kunne styre det meget mere detaljeret på lejemålsniveau, så behovet fra vores kunder af er primært for at kunne digitalisere deres bygningsportefølje. DBC: Hvem er målgruppen? MLG: Det er meget bredt, vi spænder fra enkelte bygninger til 950 ejendomme hos vores kunder, så det er meget forskelligt, hvad Mdoc FM-systemet bruges til. Nogen kunder er helt nede i dybden og bruger det til at sende rekvisitioner og styre økonomi i, hvorimod andre udelukkende bruger det til at skabe overblik over deres ejendomsportefølje. Vi har sågar også en entreprenør, som bruger Mdoc FM til offentlige OPP-projekter. Han har budt ind på retten i Roskilde, som han skal drive i 26 år. Han skal bruge Mdoc FM-systemet, til at sende rapporter til bygherre for at dokumentere, at han har udført nogle forskellige arbejder indenfor nogle forskellige tidsintervaller. Det har vi været med til at udvikle i nogle moduler, så han nu har mulighed for at kunne gøre det de næste 26 år. DBC: Hvorfor var der brug for Mdoc FM? MLG: Jeg tror i bund og grund altid der har været et behov for at kunne styre drift og vedligeholdelsen af sine bygninger. Tidligere har det foregået i Excel-ark og små programmer, som en enkelt mand har udviklet. Men i dag er der kommet meget mere fokus på Facilitiy Management, hvilket betyder, at de små programmer og Excel-ark ikke længere kan gøre det. 1

48 Vi er nød til at kunne samle alle vores data fra Revit-modeller, økonomi-systemer og energisystemer et samlet sted. Det giver et større overblik og så kan Excel-arkene ikke længere følge med. DBC: Der var altså rigtig meget brug af Excel-ark inden Mdoc FM? MLG: Ja, vi har konstateret ved kundebesøg, at der har været brugt rigtig meget Excel og indscannede tegninger. Der er stadigvæk nogle steder, hvor det er sådan. Det betyder ofte, at der ikke er ordentlig styr på økonomien i forbindelse med drift og vedligeholdelsen af deres ejendomsportefølje. Det er der så efterfølgende kommet et behov for styre centralt og digital. DBC: Har de to nye IKT-bekendtgørelser haft indflydelse på Mdoc FM? MLG: Ja det er helt stensikkert. Vi kan se, at der lige pludselig er kommet et større fokus på IFCfiler, Revit-modeller og genbrug af disse data. Det kommer sig helt sikkert af, at der nu er blevet stillet krav om det igennem IKT-bekendtgørelserne. Blandt andet kravet om informationer og klassificering på objekterne har vi enormt stort fokus på lige nu. I drift og vedligeholdelsessituationer er det alfa og omega, at vores klassifikationer er i orden, så man har mulighed for at se, hvad der er hvad, fordi der her er tale om dataobjekter. Dataobjekter kan ikke på samme måde give et visuelt overblik over ens bygningsdele, som man kan i en 3D-model. Det er derfor utrolig vigtigt, at et vindue er klassificeret som et vindue og en dør er klassificeret som en dør. DBC: Er det for at kunne lave mængdeudtræk i Modc FM-systemet? MLG: Ja, men også for at kan identificere objekterne og ikke mindst prissætte dem på hvert enkelt objekt. Det har i praksis betydning for om den ejendomsfunktionærer ser de rigtige bygningsdele på hans tablet i forbindelse med syn. Det der afgør, om det er en el-tavle, er klassifikationen og navnet på den bygningsdel. Da bygningsdelene optræder på mange forskellige platforme, så det er virkelig vigtig, at klassifikationen er korrekt og det samme i forhold til at objekterne. De skal være struktureret samt være brugt på den rigtige måde. Det betyder, at man skal bruge et tag som et tag og ikke bruge et tag som en bordplade. Der ser vi en gang i mellem, at der bliver fusket lidt med familiys i Revit-modellen. Det er som om, at mange bruger generic models som en eller anden affaldskategori til sine objekter, men det betyder så bare, at Mdoc FM ikke kan identificere objektet, fordi det er noget, andet en det egentlig er. Vi har en gang i mellem set, at nogen modellere døre som vinduer, fordi man har valgt en vindues familiy i Revit-modellen, men bliver så brugt som en dør. Man kan derfor stille sig selv det spørgsmål, om det så er god drift og vedligehold, når døren i virkeligheden er et vindue. Det er derfor vigtigt, at man holder tungen lige i munden, når man modellere i Revit samt med sin klassificering af objekterne.. 2

49 DBC: Hvilken paragraf i IKT-bekendtgørelserne har haft størst indflydelse? MLG: 4 har i hvert fald, da den omhandler bygningsobjekterne. Der er kommet et stort fokus på informationer på objekterne. De skal være rigtige og de skal være velstruktureret, så man kan genbruge dem igen. Jeg har hjulpet forskellige organisationer med at stille krav om, hvilke informationer der skal afleveres til objekterne. Det har jeg blandt andet gjort til University College Lillebælt. Her har vi stillet krav til, hvilke informationer objekterne skal forsynes med for, at vi sikre, at vi får de relevante oplysninger i forhold til drift og vedligeholdelse af dem. Det er f.eks. informationer vedr. producenten, indbygnings år mv. DBC: Er det forskelligt fra organisation til organisation, hvad de har drift og vedligehold på? Det er vel ikke altid bygninger? Et eksempel: Hvis det nu var et sygehus, så kunne det godt være, at de havde mere fokus på deres inventar? MLG: Ja, men i princippet så er en bygningsdel for os også et stykke inventar. Dette kunne også være stole eller dette kunne også nogle maskiner til nogle sygehuse eller noget i den stil. Det kan være alt lige fra, man skal flytte på tingene til et almindeligt eftersyn af tingene. DBC: Hvilke fordele er der ved at anvende Mdoc FM? MLG: Jamen, det er jo et stort spørgsmål. Det skaber for det første et større overblik over sine data, som kan være samlet fra flere forskellige steder. Revit-modellen er et sted, hvor vi får data foræret i form af nogle arealer samt data omkring bygningsdele. Derudover kan man få foræret data fra økonomi- og energisystemer. Det kan skabe overblik for medarbejderne, så de kan gøre deres arbejde i forhold til Facility Management. Varmemesteren kan se det han har brug for og i samme system kan økonomimedarbejderne arbejde med de data, varmemesteren har meldt ind i Mdoc FM. Hvis varmemesteren er ude og syne en afdeling og registrerer at fugerne i murværket er misvedligeholdt. Det videreformidler varmemesteren så igennem Mdoc FM, hvor den økonomiansvarlige nu skal tage stilling til, om der er penge nok til at få udarbejdet opgaven med det samme eller om der skal henlægges til opgaven i de næste par år. Det giver overblik for hele organisationen, at de nu kan arbejde og se hinandens arbejder i ét samlet system. Tidligere har man måske gjort sådan i nogle Excel-ark, hvor man har udvekslet tingene, men nu kan de alle sammen logge ind i det samme system og se konsekvensen af varmemesterens arbejde. For at Mdoc FM- systemet skal fungere bedre, går vi nu fra nogle enkelte klientløsninger til én webbaseret-løsning, så alle kan logge på fra det samme sted og tilgå samme portal som styres fra et sted. DBC: Hvad mangler Mdoc FM? MLG: Jamen, det er jo svært at sige, men vi kunne godt tænke os, at vi i fremtiden havde noget mere integration f.eks. V&S priskalkulation, så vi på den måde havde nogen erfaringstal både fra for vores kunder men også fra en prisdatabase. Det er ikke kun priser men også arbejdsbeskrivelser, 3

50 så det giver større sammenhæng mellem pris og arbejde. Det vil give en erfaring at trække på, når der fastsættes priser på fremtidige opgaver. Vi mangler også at kunne hente digitale aflæsninger af målere, men det kommer, så vi kan fjernaflæse el,vand og varme centralt direkte til Mdoc FMsystemet. Det er vi dog i gang med at lave, vi har allerede en test setup oppe at køre, hvor vi med pir målere kan måle bevægelse, temperatur og wattforbrug på hvert rum. DBC: Hvilke fordele/ulemper kan der være ved integration ml. Revit-modellen og Mdoc FM? MLG: Fordelen er helt klart, at man kan genbruge nogle af de data, der er skabt i Revit-modellen. Det mindsker arbejdet med registreringsarbejdet i starten, så man hurtig kan komme i gang med at føre drift og vedligehold på sin bygning. Ulemperne er, at man skal være noget mere konsekvent i sin Revit-modellering. Man skal sørge for, at man har styr på sine objekter og en anden ting er, at man ikke bare skal tro, at man kan trykke på en knap og så kan man drifte på en 3D-model. Vi skal ligesom tage stilling til, hvad det er, vi vil drifte på, fordi hvis du bare siger, du vil drifte på alle objekterne, så får du importeret alt for mange bygningsdele (så kan vi nemt snakke 2000 objekter og hvis vi snakker 2000 objekter for hvert enkelt bygning, så får de kunder, der har flere hundrede ejendomme rigtig rigtig mange objekter og rigtig meget data, der skal vedligeholdes). Så man skal finde et eller andet niveau, hvor man har det man har brug for og ikke mere). Det hele handler om organisationernes behov. De større kunder vi har, de vil få svært ved at styre deres objekter fra Revit-modellen i Mdoc FM, fordi der vil være så meget data, der skal vedligeholdes og det skal det. Så er det den kære ejendomsfunktionær ud i afdelingen, der skal sørge for, at data en er vedligeholdt eller et central ejendomscenter der skal sørge for det.. og langt hen af vejen så tror jeg, det overrasker organisationerne, at der rent faktisk er nogle, der skal arbejde med det her. Så de kan ikke bare hælde over og det er udfordringen at få det kogt ned til en eller anden datamængde, som der i virkeligheden er behov for. DBC: Hvordan fungerer interaktionen ml. Revit-modellen og Mdoc FM? MLG: Jamen Der er jo altid rum til forbedringer, men hvad jeg hører derude, så er det et rimeligt godt værktøj. Det fungerer på den måde, at vi er ligeglade med, hvad man kalder sine parametre i Revit. Man kan selv mappe dem over, så hvis man henter et vindue ned fra Revit City og har tilknyttet 10 parametre man ikke skal bruge til noget, så vælger man bare den fra, når man mapper objekter fra Revit-modellen til Mdoc FM. Hvis man har en 1:1 relation, det vil sige, at man har ét rum Revitmodellen og ét i Mdoc FM, så kan man kører parametre frem og tilbage, som man vil. Det vil sige, at man hele tiden har opdateret data i sin Revit-model. Det kan være lidt af en udfordring ved nogle bygningsdele, hvor vi håndterer dem anderledes end Revit-modellen f.eks. indvendig overflader i en drift og vedligeholdelses situation. Der er vi jo i den grad interesseret i at 4

51 vide, hvilke overflader vi har og hvor mange m 2 overflader vi har. Det betyder så, at vi bliver nød til at nedbryde vægobjekterne i forhold til rummet og på den måde får en summeret overfladeareal på de valgte objekter. Det betyder jo, at vi splitter objekter op i forhold til Revit-modellen, så den ikke er 1:1 mere. Det fungere på den måde, at det er et database-link fra Revit-modellen, så når du trykker på eksport med de valgte indstillinger, så eksportere den rå data direkte over i vores database fra Revitmodellen. Det er en direkte udveksling at data.. DBC: Kravet til IFC-formatet ved digital aflevering i IKT-bekendtgørelse kan altså ikke bruges ved import af data direkte i Mdoc FM? MLG: Jo, altså.. Det her problem har vi ikke mødt endnu, men det kommer vi til møde.. så det bliver noget vi kan. Vi har en IFC-viewer, hvor man kan se de informationer, der lagt på, men man skal igennem Revit-modellen for at få det fulde udbytte, man vil have. DBC: Det skal altså være et krav, at bygherren skal have Revit modermodellen med i forbindelse med aflevering af byggeriet? MLG: Nej, vi kan også godt gøre det i IFC-formatet, men man får bare mest ud af det i Revitmodellen, fordi så har du mulighed for at arbejde videre på modellen senere. IFC-filen er bare et udvekslingsformat, hvilket vil sige, at man skal have en eller anden platform for at kunne arbejde med filerne. Hvis man bare havde et værktøj, hvor man kunne importere IFC-filerne i og skulle flytte på nogle vægge, rum eller slette ting og fjerne nogle objekter, så vil man få nogle udfordringer.. så man er nød til at have en eller anden form for platform, der hænger sammen med Mdoc FM, hvor man kan få sine data fra. Hvis man derimod importerer IFC-filen til Revit-modellen, kan man derfra videreformidle dataene til Mdoc FM. DBC: Hvilke krav er der til Revit i forhold til integrationen af Mdoc FM? MLG: Det vigtigste i en Revit-model er at holde orden i den. Vi ser nogle gange, at der er 200 views. Det er ikke urealistisk at se nogen gange og man mister lidt overblikket. Dernæst er det vigtigt at have overblik over sin Revit-model. Det drejer sig om opbygningen, klassificering, navngivning og koder det er med til at give en bedre export af data. Derfor råder vi vores kunder til at sørge for at tjekke Revit-modellen igennem løbende. Der skal være orden i Revit-modellen og objekterne skal selvfølgelig være klassificeret, så vi kan bruge dem. Det bliver ret hurtigt synligt, for når vi ligger dem over i Mdoc FM, så kan man se de objekter, der ikke er klassificeret, da de udmunder sig i tomme objekter.. og opbygningen der er det vigtigt at bruge objektet, som det er tiltænkt.. altså en dør som dør og vindue som vindue og gulv som gulv og ikke gulv som bordplade. DBC: Det stiller altså store krav til opbygningen af familiys i Revit? MLG: Ja, det gør det. Altså.. jeg ved ikke om det stiller store krav.. men stiller i hvert fald nogle krav til, hvordan de er brugt. Vi er lidt ligeglade med, om det er et simpelt vindue og om der er 5

52 tegnet sprosser og alt sådan noget på. Det vi gerne vil have er, at det er et vindue og at der er en klassifikation, så de kan bruges. Det har tidligere været sådan, at vi klassificerede i vores kode et vinduesobjekt til enten SfB eller CCS, når man importerede dem, men lige pludselig så ser vi muligheden for at eller så har vi ændret det til, at man selv skal bruge den klassifikation, der er i modellerne fordi der nu er kommet mere fokus på det og det betyder jo, at man kan angive et vindue som vinduesparti for eksempel. Det er kommet i den grad, fordi CCS er blevet en del mere detaljeret end SfB så kan man gøre den slags ting og det stiller jo lige nøjagtig krav til, at klassifikationer skal hedde det rigtige. DBC: Hvad med i forhold til Alment nyttigt boligbyggeri, hvor der er krav om Statens forvaltnings klassifikation? MLG: Jamen, den kan vi også godt understøtte. Det kræver jo selvfølgelig også, at den er brugt rigtig for at den kan læses korrekt ind i Mdoc FM. DBC: Så det vil altså sige, at hvis ens familiys i Revit er navngivet efter CCSklassifikationssystem og importeres til Mdoc FM, så kan man godt ændre det i Mdoc FM? MLG: Ja det kan man godt, hvis man vil bruge Statens Forvaltnings Klassifikation, så skal det være Statens Forvaltnings Klassifikation, der angivet på sine objekter i Revit. Det er enormt vigtigt, at man ikke blander de forskellige systemer så nogle objekter er efter Statens Forvaltnings Klassifikation, CCS eller SfB. Det kræver stringent struktur i sin måde at klassificere sine objekter. DBC: Hvad vil være den nødvendige detaljeringsgrad? MLG: Jamen, det vil typisk være, hvad det er for et vindue og hvem har lavet det. Det betyder, at vi ved hvilke oplysninger, leverandørerne skal levere for at kunne fører drift og vedligehold på bygningsdelene. Derudover kan det man forlange. at leverandørerne skal levere oplysninger omkring u-værdi og g-værdi mv. hvis det var et vindue. Det er helt op til den enkelte kunde at finde ud af, hvilke informationer de har behov for, for at de kan drifte optimalt på deres ejendomsportefølje. Men samtidig skal man også huske ikke at overhælde Mdoc FM-systemet med for mange overflødige data, da der er nogen som skal holde disse data vedlige. De vil altså sige, hvis man skifter et vindue, så skal man altså også skifte vinduet i Mdoc FM-systemet. DBC: Hvordan sørger man for, at kun de nødvendige informationer fra Revit-modellen føres over i Mdoc FM? MLG: I forhold til det er det vigtigt, at der blevet stillet krav om de informationer, der skal være indeholdt i Revit-modellen ved aflevering, medmindre at kunden selv vil finde dem. Det var tidligere sådan at de andre værktøjer til Revit-modellen skulle være navngivet stringent efter nogle parametre, som skulle hedde noget bestemt for at værktøjerne kunne bruge dem. Der var derfor tit fejl i forbindelse med eksporten af dataen, så vi valgt at udvikle et værktøj, hvor kunden selv kan rette i disse og navngive dem som de vil, hvilke har givet større frihed. I princippet kan du tage navnet fra Revit-modellen og ligge over i u-værdien ind i vores system, hvis det er det man vil. 6

53 Det er enormt fleksibelt, for så kan kunden sætte deres egne regler op, som de har lyst til. Det betyder, at vi ikke her fra skal sidde og diktere nogle regler til, hvordan de gerne vil have deres ting afleveret. I sidste uge fik jeg et opkald fra en kunde, som havde hentet nogle familiys ned fra nettet, som hun vil bruge i sin Revit-model. Hun var dog bekymret for, om alle informationer der låst til familiyen, ville have indflydelse på hendes Mdoc FM-system. I eksport værktøjet (i Revit) kan man jo helt selv bestemme, hvilke informationer man vil overføre fra sin Revit-model. DBC: Så man kan altså selv vælge ud, hvilke data man vil have med over i Mdoc FM ud fra sine familiys? MLG: Ja, det fungere således, at man har en export-funktion, tegnings-funktion og parametrefunktion i vores integrationsværktøj til Mdoc FM fra Revit-modellen. I export-funktionen importerer du objekter til Mdoc FM. Objekterne er kendetegnet som rum, bruttoetagearealer og bygningsdele. I øjeblikket operere vi med vinduer, døre, vægge, gulv, lofter og tage, men det varer ikke længe før, vi har mulighed for at få installationer med over i Mdoc FM-systemet. Når du eksportere din objekter til Mdoc FM, bliver der skabt en GUID på dataobjekterne i vores system og Revit-modellen. Det generer den for at kunne identificere dataen på objekterne og opretholde et link imellem to objekter. Efterfølgende kan man se, at det er overført tomme objekter. Objekterne indeholder kun ganske få informationer. Det er klassifikationen og navnet på objektet. Navnet er det, du har kaldt dine familiys i Revit-modellen. Du skal derfor med parametre-værktøjet vælge hvilke informationer, du vil have med over på dine bygningsdele. Det vil typisk være informationerne omkring, hvad det er for et vindue, hvem har produceret det og en beskrivelse mv. Du skal derfor mappe disse oplysning over på objektet. Det kan lade sig gøre, fordi at der tidligere er skabt en GUID på objekterne, så systemet kan skelne mellem objekterne fra Revitmodellen. Til sidst skal du bruge dit tegnings-værktøj. Når du eksporterer dataen fra Revit-modellen vedrørende tegningerne, generes der nogle SWG-filer, som er 2D tegninger. Disse er XML-baseret filer, hvilket betyder, at kan bruges i en browser uden særlig god internetforbindelse. Det betyder, der er mulighed for at bruge og anvende tegningerne på mobiltelefoner uden det hakker i tegningsfilen. Det tror jeg langt hen er vejen er behovet. DBC: Hvis man retter informationerne i Mdoc FM-systemet, synkroniseres der derefter med Revit-modellen? MLG: Ja, man skal bare være opmærksom på, at de steder, hvor det er 1:1 kan de give problemer. Hvis du har et vindue i Mdoc FM, og du har et vindue i Revit-modellen, kan man mappe parametrene tilbage igen ved at køre en synkronisering mellem disse. Den tager dataen fra vores database og ligger det over i Revit-modellen. Dog er der nogle yderligere udfordringer ved brug at familiys med parameret instance, fordi? 7

54 Men hvis tager et vindue, hvor du har taget nogle familiy parametre og mappet over, så har du skilt et vindue ud til 10 vinduer lige pludselig. Det betyder så, at hvis du ændrer informationerne i et af de 10 vinduer og derefter vil mappe dem tilbage, så bliver udfordring, at forskellige informationer dukker op. Derfor vil den advare om du stadigvæk ønsker at flytte dine informationer. Hvis du vælger at sige ja, vil dine tidligere informationer på objekterne blive overskrevet. Så du kan altid ligge dem over som et instance parametre? DBC: Så man skal ligge sine familiys over som instance i stedet for type-parametre? MLG: Det kan man gøre.. det vil jeg arbejde på bliver smartere, men det er der, hvor vi er lige nu og man skal jo huske, at der hele tiden er noget, der udvikler sig. Vi har i øjeblikket nogle større kunder inde nu, som har meget fokus på det, så det kommer sikkert til at gå stærkere. Det skal vi arbejde med det næste halve år. DBC: Hvordan ser du fremtiden indenfor Mdoc FM? MLG: Jamen, vi har rigtig travlt lige nu, og det er blevet rigtig stort lige pludselig. Lige nu er vi to der sidder med implementering af Mdoc FM-systemet og så har vi en udviklingschef. Derudover har vi 5 fuldtidsudviklere på Mdoc FM, så det siger sig selv, at det begynder at gå stærkt! Vi har fået nogle kunder som har nogle specifikke behov i form af moduler, som også kan bruges af andre brugere. Vi kigger lige nu på at lave en digital afleveringsportal, hvor kundernes data kan blive lagret samtidig med, at der sker en kvalitetssikring af filer, dokumenter og ikke mindst Revitmodellen inden det bliver afleveret til kunderne. Det er et slag projektweb. De forskellige parter der er på projektet, kan med et login gå ind og arbejde med informationerne og lagre deres data. DBC: Kan Mdoc FM understøtte alle former for klassificeringssystemer? MLG: Ja, vi har nogle kunder som bruger DBK-klassifikationssystemet og andre der bruger SfB. Langt de fleste bruger stadigvæk SfB-klassifikationssystemet og nogle få som bruger CCS. Ud fra det kan man sige, at CCS er et klassifikationssystem med mange flere parametre end de andre. Det vi bruger lige nu er klassifikations-koderne, altså qqa det åbne og lukkede komponenter, der er et vindue. Vi skal passe på med, at vi ikke sætter alle mulige i gang med at bruge nogle ting som en gang bliver lavet om på - også for vores kunders synspunkt. Så det er på nu værende tidspunkt kun klassifikations-koderne, vi bruger. DBC: Er det pga. SfB er mere minded på det dokumentbaseret, hvor vi nu går over imod objektbaseret klassifikation? MLG: Ja, men SfB fungerer fint. Det er noget mere simpelt, og det er det vores kunder har været vant til at bruge, så det er det, de langt fleste stadigvæk bruger. De er ikke interesseret i, at skulle ud og bruge nye klassifikationssystemer som f.eks. Statens Forvaltnings Klassifikationssystem, CCS eller DBK. De kan sagtens nøjes med deres sædvandelige måde at klassificere deres bygningsdele på. DBC: Har IKT-bekendtgørelse haft indflydelse på brugen af 3D-modeller i forhold til Mdoc FM-systemet? MLG: Ja, det er mit indtryk. Vi har nogle, som er foregangsløber på det punkt f.eks. Arbejdernes 8

55 Andels Boligforening. De yder en indsats for at hele tiden gøre det bedre selv, så de er også med til at skubbe os, når der kommer sådan nogle kunder. Dem har vi nogle stykker af efterhånden. De vil hele tiden noget mere, og det er jo rart. Arbejdernes Andels Boligforening er jo med til at udvikle nogle ting som for eksempel app s. Det er for eksempel i samarbejdet med dem, at vi har lavet app en DOtAB. 9

56 Bilag 3 Interview med Birgitte Nissen fra Region Midt Jylland Emne: IKT-bekendtgørelsen og drift og vedligehold med Main Manager Dato: kl Sted: Møllegade 1, 8000 Aarhus Interview person: Interviewer: Birgitte Nissen (BN) Dennis Bønnelykke Christensen (DBC) Kort omkring Birgitte Nissen: Birgitte har arbejdet med drift og vedligehold i over 20 år. Hun er uddannet arkitekt, men inden for by bygning. Men fordi hun har en holdning til drift og vedligehold, som hun synes er meget spændende hoppede hun over i den genre. Det er der ikke ret mange der beskæftiger sig med nemlig, derfor arbejder hun stadigvæk med drift og vedligehold. Jeg er jo startet fra da man lavede mapper, og havde dem under armen når man skulle ud og besigtige bygninger til i dag, hvor man sidder foran en computer og kan hive BIM modeller ind i FM-systemer og lave drift og vedligehold på de objekter der ligger indeni modellerne. DBC: Hvilke krav og love skal Region Midt Jylland overholde i dag i forhold til drift og vedligehold? BN: Er det økonomisk, fordi der skal vi i forhold til IKT-bekendtgørelsen drifte digitalt, og det er vi på vej til. Man har driftet tidligere, men ikke så effektivt som vi nu søsætter. DBC: Hvilke tanker gør I i forbindelse med IKT-koordinering på et projekt? BN: Det er jo et bredt spørgsmål. I dag projekterer der man digitalt, om man gør egentligt i princippet alt digitalt i hele projektfasen, opførselsfasen samt bygger store afprøvningsmodeller i 1:1, som egentlig også er lidt digitalt. Jeg har ikke været derude endnu, fordi så skal vi ud og besøge en projektafdeling, men jeg har kontakt til projektafdelingen, fordi de skal aflevere deres BIM modeller så jeg får lidt en fornemmelse af hvad de arbejder med. BIM modeller kan være meget forskellige, så det bliver lidt en kunst at få dem ind i et vedligeholdelsessystem, når de datamæssigt, altså klassifikationer er sat forskelligt op, så vi laver først testforsøg, hvor vi tager den ene efter den anden og så prøver vi af. DBC: Hvem står for IKT koordinering? BN: Det gør de enkelte projektafdelinger, og ude på hospitalerne der er en driftsafdeling, og så er der en projektafdeling, som kun kører de nye og store hospitalsbyggerier, og det er dem der ansvarlige for at de afleveres i forhold til IKT-bekendtgørelsen. 1

57 DBC: Hvad har IKT-bekendtgørelse haft af betydning for jeres drift og vedligehold? BN: Jeg tror den har været et beslutningsgrundlag for de tekniske cheffer. Nu vil de prøve og kører et driftssystem sammen, og det er jo unikt. DBC: Hvilke konsekvenser har IKT-bekendtgørelsen haft samt har den medfødt nogle nye tiltag i forhold til jeres drift og vedligehold end tidligere? BN: En mulighed for samarbejde, man har jo altid været lidt kasse tænkende. Det skal man jo også være når man er tekniskchef på et hospital, men nu har man pludselig mulighed for a tænke sammen med et andet hospital, selvom de ligger på hver sin side af Jylland, og det er jo lidt det samme jeg svare på sidste spørgsmål. Det giver overblik, man får også produkt overblik, og hvad kan det betale sig og skifte til, hvis det er de samme elementer der hele tiden går. DBC: Helt konkret fordele og ulemper i forhold til IKT-bekendtgørelsen? BN: Fordelen det er man er hele tiden parat dvs. hvis man skulle bygge i morgen, så havde man en model der var opdateret, og som man bare kunne sende i udbud. Det har man ikke kunne gøre tidligere. Ulemperne, der kan et stort system være sårebart, men det skal jeg jo sikre, at det ikke bliver, og der er nogen der satser på at det er mange systemer, og det gør vi der hvor der er bedre systemer til andet.. medio-tekniskudstyr det drifter de også i de tekniske afdelinger. Det kan godt være vi beholder det i ét system. Økonomien der ligger et super veludviklet økonomisystem, og det tror jeg man beholder, men ligger ikke økonomien ind, fordi så er man ikke så sårebar der, men man skal bare have systemerne til at kunne snakke sammen, så de har samme konto koder eller at man får økonomisystemet til at ret sig mere mod det offentlige. Det er der jo nogle hospitaler der er begyndt på. DBC: Hvilke paragraffer har haft størst indflydelse i forbindelse med nye projekter? BN: Der er vi jo ude på projektafdelinger, og der sidder jeg jo ikke, så det kan jeg desværre ikke svare dig på. Men jeg kan jo se, at man ikke kan prioritere, fordi det jo er en sammenhæng. IKTbekendtgørelse tager hele paletten fra du sætter den først streg til du går i drift, og de er jo alle sammen lige vigtige. Også det at man udveksler digitalt, man har jo de der webplatforme, hvor de sidder og udveksler deres digitale materiale med hinanden. Jeg har dropbox, og samtidig med det, er man begyndt at spare på tværs af regioner ud fra det man laver i dag. Man har grupper som er tværs af organisationen, så man nu sidder til bords med hinanden på landsplan og udveksler erfaringer, og det har IKT-bekendtgørelsen været med til, så du kan ikke pille en eneste paragraf ud, for de hænger alle sammen. DBC: Hvordan sikre I ikke får for mange informationer ved aflevering i forhold til bygningsmodellen og dens objekter? BN: Den får lov til at have ligeså mange informationer, som den har. Fordi man kan jo ikke tegne noget der er for meget. Den dag, hvor man så kører over i drift, så piller man dem ud man drifter, så der har vi en liste, som fortæller, hvilke der skal med over i drift, og så sætter vi et flueben ved dem. Så kører vi dem op til anden rådgiver, der sidder i Norge, og så kommer de elementer tilbage over i vores drift og vedligeholdssystem. BIM modellen bliver lagt derude med alle sine elementer, og 2

58 også hvor meget beton der brugt har vi jo ikke brug for at vide, og når man så næste gang skal i gang med og udvide, så tager man den igen ind og arbejder videre med den. Men det kan godt være den skal opdeles, når man laver nogle hospitalsbyggeri, som er vildt store, at man så nød til at opdele den, fordi den er tung, men vi hiver den ind som IFC-model. DBC: Er IFC-formatet kompatibelt med jeres drift og vedligeholdelsessystem (MainManager)? BN: Ja. IFC-modellen er ikke så tung, når man skal drifte, men den er stadig tung DBC: Hvad er detaljeringsgraden på jeres modeller, når I modtager modellen? BN: Det ved jeg ikke, jeg har ikke fået nogle af modellerne ind endnu, og nogle af de første etaper er pælefunderinger, som jeg har set. Man går da ned og fortæller mig om det er en firkantet eller rund pæl, der er rammet ned. Jeg mangler at få de næste ind, men jeg ved ikke om BIM-modellerne er nede i den der store detaljeringsgrad, men sideløbende har de altså nogle små systemer, hvor alle objekter bliver indtastet, med alle deres objektdata, så om vi henter informationer fra BIMmodellerne, eller om vi henter dem fra siden af. Alle data til drift er der. DBC: Kan man bruge informationer på IFC-filen til drift? BN: Det kan man fint. Vi har uploadet modeller og datamængden kommer fint ud, men der er meget. Vi har ikke lagt det ind endnu, det er der, hvor man skal sætte flueben ved hvilke informationer vi gerne vil have. DBC: Men I melder ikke selv ud fra starten af, hvilke informationer objekterne i modellem skal indeholde samt detaljeringgrader inden I sender det udbud? Men modtager i stedet hele modellen og så efterfølgende sætter flueben ved hvilke informationer i ønsker? BN: Nej, det er de første modeller, dem får vi tilbage uden at de er sorteret i. De næste udbud, som køres der har vi en IKT-specifikation, på hvordan vi vil have det taste ind, og hvor mange objekter de skal taste informationer ind på. Og der kommer det til at kører på den måde, at det er rådgiverne der ligger modellen ind. Vi kommer ikke til at lave noget, og så er det entreprenørerne der ligger datamængden ind, og det håber jeg, kommer til at kører smertefrit. DBC: Har I arbejdet med andre tiltag der er udover minimumskravene i IKTbekendtgørelsen, det kunne f.eks. være nogle app s til tablets, som kunne være med til at hjælpe jer med driften? BN: Der er lige udviklet en app, som de kan have med ud, når de drifter og som fungerer på både Ipad en og telefonen, og så man tematisere, så man får nogle andre overblik over drift dvs. brand og rengøring. Det er vi ved at søsætte nu, fordi rengøringen også synes det er veldigt interessant, for her kan de gå rundt og så kan de i stedet for, at der nummerer derpå, så kan de jo se rummene, og hvad det er for en gruppe, og hvilke man skal gøre rent i dag, og hvilke man må springe over. Vi får overblik over flytninger samt afdelinger det kører over systemet i dag, så det giver overblik. DBC: Hvilke systemer er det de kører i dag? BN: Jeg ved ikke hvad rengørings programmet hedder, men det er lidt bikset har jeg hørt. 3

59 DBC: Hvordan har jeres drift og vedligeholdelsen fungeret førhen? BN: Det foregået pr. hospital og i nogle programmer der hedder medusa og maximo og der har været papirarkiver nede i kælderen, og så havde man også caretaker, som så ikke er blevet implementeret i hele regionen. Den er mere blevet brugt som en overordnet målepind, når man har lavet bygningsregistrering eller bygningsgennemgang. Og så har de et energiprogram, som jeg ikke lige kan huske hvad hedder, men det er på tværs af hele regionen. Men hvis det virker fornuftigt så sejler vi ikke om der, så ligger vi den på samme platform. DBC: I har altså ikke en fælles måde at kører jeres drift og vedligehold på, samt hvilke programmer i anvender? Det er ikke sådan at I videns deler mellem de andre regioner, så man kunne finde en fælles måde at gøre tingene på, så der er mulighed for at sammenligne hinandens data? BN: Jo, vi spare med de andre regioner, om hvordan man laver udbud med et drifts og vedligeholdelsessystem f.eks. for det betyder noget at man har en kravsspecifikation der helt ned i detaljen. Hvad man vil have ind i det er system, og det er jo modsat set man kigger på,hvad det er jeg vil have af output, og så skaber man sig en, det kan egentlig godt sammenlignes lidt med når man bygger et hus, men nu er det her altså et vedligeholdelsessystem, hvad vil vi have. Og vi sparer med de andre i forhold til at lave bygningssyn fordi bygninger jo ikke er så forskellige, altså i sidste ende så er bygning og bygningsdele osv. Og så er det også væsentligt at vedkommende går igennem og at man får det hele med så man er enig om nogle levetider og måske også nogle generelle priser så man får noget fornuftigt materiale ind. Tit og ofte så er det nyuddannede der er ude og besigtige, det for så noget erfaring så hopper de jo videre og bliver til folk der sidder i projektafdelingerne. DBC: Hvorfor har I lige præcis valgt MainManager og hvad har det haft af betydning? BN: Der har været tilknyttet en rådgiver, det er NIRAS, som har lavet kravspecifikationen i forhold til nogle workshops med alle de tekniske cheffer, og det er dem der har valgt MainManger ud fra den her kravspecifikation. Det har også været pga. programmet har kunnet alle de her ting, og der hvor det ikke har kunnet noget, har vi udarbejdet en liste, som de så er i gang med at udvikle. Valget af driftssystemet havde samtidig noget at gøre med at det havde en vis størrelsesorden. DBC: Hvilke funktioner bruger I i MainManager? BN: Vi vil starte med vedligeholdelsesdelen, det betyder også planlægning af vedligehold, for at give, det der overblik. Vi skal gennemføre et bygningssyn i forhold til vedligeholdelsescirkulæret. Det skal vi i 2015, så der får vi en mængde data ind plus, at vi har vores driftsdata, og det skal ind dvs. at bygningerne fungere i det daglige. Den blå mand ved at han nu skal op og tjekke det område samt kender arbejdsopgaverne. Sygeplejersken kan melde ind, det er den første platform, og når den kører, så kigger vi på den næste. DBC: Så det først I får til at fungere i jeres drift og vedligeholdelsessystem er selv driften? BN: Ja. DBC: Har I arbejde med integrationen mellem Revit og MainManager? BN: Nej, det er prompte. Revit det er ude på projektafdelingerne, og er en svær størrelse, for vi har jo også en IT organisation, og vi er jo lidt anderledes end, hvis det er et hospitals it. Men det skal vi 4

60 jo nok finde ud af, fordi jeg også havde tænkt, at jeg skulle have en revit licens, for ellers kan jeg ikke se, hvad det egentlig er de levere, og ikke kun IFC-modeller, som jeg først kan se når de kommer ind MainManager min min Snakker omkring IFC-filer og integrationen mellem driftssystemer. DBC: Hvad stiller det af krav til bygningsmodellen i forbindelse med MainManager? BN: Den kan laves til en IFC-fil, men det er jo et krav i selv sig selv. Jeg synes det er fint at det er et fælles format, man ligge ind, hvis bare man kan gå den anden vej. DBC: Hvordan vil i sørge for at holde jeres driftsinformationer opdateret? BN: Jeg har lige været ud og underholde om det der, og min sidste planche, det er sådan et årshjul,der siger her implementere vi, og så kører vi hele vejen rundt, og så laver vi ændringer, og så implementere vi igen. Den bliver ved, ved og ved. Og hvis man ikke afsætter ressourcer til det, så er driftssystemet ikke noget værd. Så hvis man ikke får opdateret sine modeller, og har et personale til det, så er det ingenting værd, altså det er jo ikke ajour. Og det er der faktisk tidligere gamle amter, det sagde f.eks. at CAD var forfærdeligt. Problemet var, at de ikke afsatte ressourcer til at sætte, og putte tingene ned i databasen, for at få den til at virke, og det tager halvanden til to år før man har alle data inde. Det virke altså bare ikke automatisk, der skal sættes tid af til at få disse data integreret. DBC: Hvilke bygningsdele drifter i på? BN: Det er meget forskellige, men der lavet en workshop med ene driftsfolk ude på DNU Aarhus Universitetshospital, og de har valgt ca. 500 bygningsdele og hvis de har valgt 500 bygningsdele, så skal det nok være rigtigt, at det er det vi drifter, så den har jeg haft i baglommen, og så har jeg gået ud til andre og sagt her, har vi 500 bygningsdele ser det fornuftigt ud, og som de så siger, jamen hvis de andre driftsfolk siger det, så må det være sådan, men undervejs kan vi jo se om der er noget vi mangler bygningsdele deromkring. Og hvis så, man vi have en information som er større, så er man nød til at og gå ud i modellen og hente dem, og ellers kan man selv koble dem på derinde. Det er et system som er drag and drop og så ligger klassifikationen i den ene side med alle de bygningsdele og så kan man oprette og hive ind og redigere undervejs DBC: Hvad stiller i af krav til klassificering af jeres objekter? BN: Det er en udfordring, fordi det ene store hospital de er hoppet med på CCS, og hvor de så har projekteret i CCS og lavet udbud, og man kan se at man nok har sparet noget i forhold til prisen af byggeriet. Og hvor vi nu har sagt a må vi også sige b, for cuneco siger jo, det er et super system, og så har vi det andet store hospital det kører i SfB, og så kunne jeg jo gå ind og sige ej vi er altså nød til at det er det ene eller det andet vi bruger så jeg kan vælge mellem pest eller kolera og det gør at jeg vælger begge dele, så vi kører et EU projekt hvor vi prøver at få databasen til at kunne kende begge systemer, så når et projekt kører ind i CCS, så læser den CCS, men den viser samtidig også SfB koden, fordi driften ind til videre kun kører i SfB de kender ikke CCS og omvendt hvis SfB så viser den også CCS koden. Så på den måde bliver MainManager en oplæring af driftsfolkene, at de kan hedde noget andet, og det har vi søgt om hos bips, og der er ved at blive skrevet en 5

61 projektbeskrivelse og søgt midler de hedder IceConsult, men nu hedder de MainManager at de kan bygge MainManager om. DBC: Har I gjort jer nogen erfaring vedrørende integration mellem Revit og MainManger, godt eller skidt? BN: Det har været en udfordring fordi vi er lidt atypiske. Vi har valgt at serverne står in-house og dvs. vi skal ud og ind via. VPN-linjer, og det er jo en tunnel, som kan give nogle forhindringer, men vi har fået et resultat ind, hvor man fint kan se bygningsdele og det hele, og vi har lavet tre testbygninger. En der hedder 2D, BIM CCS og BIM SfB, og de skal kunne kører inden vi begynder og ligge de rigtige bygninger ind. DBC: I har ikke prøvet at eksportere informationer den anden vej, altså fra MainManager og til Revit? BN: Nej, og hvordan man gør det, det ved jeg ikke, men det bliver en udfordring egentlig ligesom med klassifikationen, men det er jo også det der er det spændende i det. 6

62 Opstart Scanning af QR-kode i lejemålet Oplysninger vedr. lejemålets bygningsdele. Der vælges nu bygningsdel - 2 bad. Der ses nu hvilke bygningsdele der hører til 2 bad - Der vælges håndvask Eksisterende billede af håndvask Oplysninger vedr. garanti på håndvasken Oplysninger vedr. type af håndvask Oplysning vedr. montør. Der oprettes nu en sag ved at trykke på den grønne knap øverst til højre. Der er nu mulighed for at tage billede Sagen er nu oprettet og ligger på den ejendomsfunktionærers dashboard Eller indtale en besked vedr. sagen Sidste mulighed er at sætte en standart frase på sagen. Der skal herefter trykkes på den grønne knap (videre) øverste til højre for at komme til næste step i udarbejdelsen af rekvisitionen. Der kan nu specificeres hvem leverandøren mv. Når felterne er udfyldt trykkes på knappen øverst til højre (opret) Bilag 4 Gennemgang af DOtAB Dette var en gennemgang af hvordan DOtAB en fungere. Den skal være med til at give et bedre indblik ind hvordan de ejendomsfunktionærer skal anvende DOtAB en. Billederne er taget som screendumps fra min personlige Ipad. Der skal lyde en stor tak til AAB for at give love til at prøve DOtAB en.

63 Bilag 5 Ha ndtering af AAB s driftsinformationer

64 Bilag 6 Pentagon Undersøgelsens spørgsmål (problemformuleringen) Hvad spørges der om? Hvilke krav skal bygherre tage stilling til i forbindelse med de nye IKT-bekendtgørelser og kan disse integreres i den daglige drift og vedligehold ved hjælp af driftssystemer? Undersøgelsens faglige formål: Hvorfor er spørgsmålet vigtigt? Drift og vedligehold er en stor økonomisk post i en boligforening og har stor betydning for opretholdelsen af bygningernes kvalitet. Overholder boligforeningen AAB IKT bekendtgørelsen. Undersøgelsens genstand, fænomen: Hvad spørges der til? Drift og vedligehold i en boligforening (Arbejdernes Andels Boligforening). Integrationen ml. Revit og Mdoc FM, hvordan bruges de allerede kendt informationer omkring bygningsdelen i afdelingerne? Undersøgelsens redskaber: Teori, begreber, metoder: Hvordan skaffes vi den? Publikationer i forhold til drift og vedligehold Vejledning om drift af almene boliger m.v. AB92, ABR89 Love, Bekendtgørelser, vejledninger Interview med Arbejdernes Andels Boligforening (Leif Kruse) Interview med NTI CAD center (Michael Møller) Undersøgelsens fremgangsmåde: Hvordan gennemføres trin for trin? Drift og vedligehold i almene boligforeninger Lovgivningen indenfor almene boligforeninger Lave spørgsmål til interviews.

65 Bilag 7 Brugerflade i Mdoc FM