IKT i projekteringen
VIA UNIVERSITY COLLEGE - AARHUS IKT i projekteringen Specialeopgave på 7.semester Bygningskonstruktøruddannelsen Jeppe Strand Lemvig - 141994 27-03-2015 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Titelblad RAPPORT TITEL: IKT i projekteringen VEJLEDER: Martin Nielsen FORFATTER: Jeppe Strand Lemvig DATO/UNDERSKRIFT: _______________________________ STUDIENUMMER: 141994 OPLAG: 1 SIDETAL (à 2400 anslag): 29,9 sider 71.872 anslag GENEREL INFORMATION: All rights reserved - ingen del af denne publikation må gengives uden forudgående tilladelse fra forfatteren. BEMÆRK: Dette speciale er udarbejdet som en del af uddannelsen til bygningskonstruktør – alt ansvar vedrørende rådgivning, instruktion eller konklusion fraskrives 1 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Forord Jeg har igennem hele min uddannelse til bygningskonstruktør, haft en særlig fokus og interesse for det digitale byggeri. Derfor var det særlig interessant for mig i praktikken at opleve hvordan sammenhængen mellem beskrivelser, tilbudslister og fagmodeller fungerer. Her kunne jeg hurtigt se, at de projekterende havde rigtig svært ved at efterkomme kravene til IKT anvendelsen, samt IKT bekendtgørelsens kravformuleringer. Jeg har igennem hele mit skoleforløb kun tænkt BIM projektering som en positiv ting. Derfor synes jeg det var ekstra interessant at lave mit 7.semester speciale på baggrund af mine oplevelser i det daglige arbejde med udarbejdelsen af udbudsmateriale. Læsevejledning og specialets opbygning er beskrevet i afsnit 1. Der rettes en særlig tak til Peter Hyttel og Karsten Hansen for at stille op til interviews i forbindelse med denne rapport. Ligeledes vil jeg gerne takke BIM Aarhus for interessante debatter og foredrag, som har givet et stort input af viden fra branchen. Jeg vil også gerne takke Mads Valentin, Lone Sand, Jacob Guldner og Marianne Friis som tidligere har hjulpet mig med inputs vedrørende BIM projektering. Til sidst en tak til min vejleder Martin Nielsen. 2 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Abstract In my 7th semester assignment, I have chosen to investigate the architectural designer’s risks in a digital building project. One of the main topics of this assignment is how to create the connection between BIM models, descriptions and offer lists. The report is divided in three parts, the first part is focusing on the theoretical aspect of a digital project, and the second part is a case study from my internship, where the issue towards BIM designing was difficult to handle. The third part of the report is a project planning section that links theory, case study and industry experience. While working with the report, I found that BIM design is difficult and not always the smartest solution. Industry's quest for the perfect solution has complicated the preparation of tender documents and made the architectural designer’s work very risky. However, there are still many benefits of BIM design. The trick is to balance the BIM software´s options so it creates value for the architect and comply with applicable legal texts. 3 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Indholdsfortegnelse 1. 2. 3. 4. Indledning............................................................................................................................ 6 1.1 Problemformulering .................................................................................................... 7 1.2 Afgrænsning ................................................................................................................. 7 1.3 Metode......................................................................................................................... 8 1.4 Målgruppe.................................................................................................................... 9 1.5 Læsevejledning ............................................................................................................ 9 1.6 Billedliste ...................................................................................................................... 9 IKT i projekteringen ........................................................................................................... 10 2.1 IKT-bekendtgørelserne .............................................................................................. 10 2.2 Ydelsesbeskrivelserne 2012 ....................................................................................... 14 2.3 BIPS IKT-ydelsesspecifikation ..................................................................................... 15 2.3.1 Klassifikation i BIPS paradigme ........................................................................... 15 2.3.2 Koordinering i BIPS paradigme ........................................................................... 16 2.3.3 Digitalt udbud ..................................................................................................... 16 2.4 Task force under DI kontra BIPS ................................................................................ 16 2.5 Delkonklusion............................................................................................................. 18 Case – Praksis eksempel .................................................................................................... 20 3.1 IKT tekniske specifikationer ....................................................................................... 20 3.2 Sammenhæng i udbudsmaterialet ............................................................................ 22 3.3 Opsummering ............................................................................................................ 25 Projektering ....................................................................................................................... 26 4.1 Klassifikationssystemer .............................................................................................. 26 4.1.1 Typekode ............................................................................................................ 26 4.1.2 Klassifikationssystemer ...................................................................................... 27 4.2 Mængdeudbud og tilbudsliste ................................................................................... 29 4.3 Koordinering af IKT-ydelserne ................................................................................... 31 4.4 Sammenhæng i udbudsmaterialet ............................................................................ 32 4.5 Bygningsdelsjournal ................................................................................................... 32 4.5.1 Keynote og Excel ................................................................................................. 32 4.5.2 Dalux bygningsdele ............................................................................................. 34 4 IKT i projekteringen Version 1 4.5.3 Jeppe Strand Lemvig 141994 27-03-2015 BIM eller bims, hvordan ser fremtiden ud? ....................................................... 36 5. Konklusion ......................................................................................................................... 37 6. Litteraturliste ..................................................................................................................... 39 7. Bilagsliste ........................................................................................................................... 40 Bilag 1 .................................................................................................................................... 41 Bilag 2 .................................................................................................................................... 42 Bilag 3 .................................................................................................................................... 46 Bilag 4 .................................................................................................................................... 47 Bilag 5 .................................................................................................................................... 49 Bilag 6 .................................................................................................................................... 50 5 IKT i projekteringen Version 1 1. Jeppe Strand Lemvig 141994 27-03-2015 Indledning Der er en generel tendens i vores samfund om at effektivisere og standardisere så mange arbejdsopgaver som overhovedet muligt. Dette er et led i at trimme omkostningerne i virksomhederne og skabe merværdi på samme tidsforbrug. Dette faktum gælder selvfølgelig også i byggebranchen, hvor entreprenørerne arbejder med at minimere udgifterne på deres projekter og effektivisere arbejdsgangene. Denne udvikling er også i gang hos de projekterende, dog ikke i samme tempo som hos entreprenørerne. Det kan der være mange årsager til, men det er et faktum at BIM projektering potentielt kan have en kæmpe indflydelse på de projekterendes ydelser og kvalitet. Denne form for projektering kan løse mange potentielle fejl på tegnebrættet og generelt ligger det op til en bedre koordinering mellem byggeriets parter. I den helt ideelle verden kan BIM tankegangen føres fra byggeriets projektering til nedbrydning og genanvendelse. Der er rigtig mange faktorer der spiller ind ift. om det bliver rentabelt at projektere på denne måde. Dels skal man have en projektgruppe der kan arbejde med BIM værktøjer, men man skal også have en forståelse for hvordan man håndtere den IKT aftale der kontraheres med bygherren. Mange i branchen mener at IKT ydelserne er svære at gennemskue og der er en tendens til at man ikke ved hvad man har lavet en aftale om. Det bliver endnu mere kompliceret når bygherren ofte heller ikke ved hvad IKT egentlig er. Så bliver det tit en gentagelse af et andet projekt. Dette er et stort problem da IKT-bekendtgørelsen giver bygherren mulighed for at skærpe kravene til rådgiverens ydelser om brug af BIM-modeller og dennes egenskaber. Derfor bliver kravene til modellens information og præcision fra projektering til drift også skærpet. Bygherren kan bestemme at der skal laves udbud med mængder, som de projekterende så skal genere ud fra deres BIM programmer, samtidig med at der skal laves en gængs klassifikationsstruktur, som skal binde fagmodeller, beskrivelser, tegninger og i sidste ende tilbudslister sammen. Der er mange delte meninger om mængdeudbud, men det er et faktum at man som rådgiver bliver nødt til at tage stilling til hvordan man vil gribe denne udfordring an. Da der ikke findes nogle branchestandarder for hvordan man kvalitetssikrer udbudsmaterialet så man er sikker på at mængder, bygningsdele og beskrivelser hænger sammen. Det er interessant at undersøge hvordan man kan skabe en sammenhæng mellem udbudsmaterialet og fagmodellerne. 6 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 1.1 Problemformulering Hvilke IKT ydelser skal den projekterende rådgiver være særlig opmærksom på under udarbejdelse af et udbudsmateriale og hvordan kvalitetssikrer de at der i udbudsmaterialet skabes en sammenhæng mellem objekterne i fagmodellerne, beskrivelserne og tilbudslisten? For at besvare min problemformulering har jeg opstillet en række delspørgsmål: - Hvad er beskrevet i gældende lovtekster, samt branchevejledninger om rådgiverens IKT-ydelser? Hvilke ydelser skal man som rådgiver være særligt opmærksom på i ydelsesbeskrivelsen og IKT-ydelsesspecifikationen? Hvilke IKT-værktøjer anvendes i praksis og hvordan bliver de anvendt i sammenspillet mellem rådgivere og bygherre? Hvordan er rådgivernes holdning til de nuværende IKT-ydelsesspecifikationer og hvordan ser fremtiden ud? Hvorfor anvender man klassifikationssystemer? Hvordan kvalitetssikrer man projektmaterialet med BIM værktøjer? Hvordan skaber man sammenhæng i udbudsmaterialet? Hvilken type bygningsdelsjournal giver det mest kvalitetssikre udbudsmateriale? 1.2 Afgrænsning Da rapportens problemstilling til dels er meget tegnestue- og projektspecifik, vil det ikke være muligt at skabe et billede af den gængse projekteringsmetodik i branchen, da jeg ikke snakker med samtlige rådgivere i Danmark. Jeg har afgrænset mit område til at fokusere på praksis erfaringer, samt udtalelser fra brancheorganisationerne Danske ARK og FRI. Rapporten tager udgangspunkt i de projekter som er omfattet af IKT-bekendtgørelserne, samt projekter hvor bygherren stiller krav om IKT-ydelser. Rapporten omhandler den projekterendes risikoforhold i forbindelse med en digital byggesag, samt hvilken indflydelse det har på projekteringen. Rapporten omhandler ikke hvilke fordele driftsherren eller entreprenøren har ved et digitalt udbud. 7 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Figur 1 Organisationsdiagram Rapporten fokuserer kun på den projekterendes ansvar og ydelser. Som det er vist på organisationsdiagrammet kunne der sagtens laves en undersøgelse af driftsherrens krav til facility management. Men nærværende rapport koncentrerer sig kun om de projekterende rådgivere og deres forpligtelser. 1.3 Metode For at belyse emnet har jeg valgt at dele undersøgelsen op i 3 dele. Jeg vil indsamle relevante teoretiske tekster fra pålidelige kilder i branchen, for at synliggøre de krav der stilles til rådgivernes IKT ydelser. Jeg vil ligeledes anskueliggøre hvilke IKT værktøjer der anvendes i branchen, samt indholdet i disse relateret til den projekterendes ydelser. I min anden del af undersøgelsen vil jeg beskrive en praksis case, hvor IKT problematikken har været særlig spændende ift. rapportens problemstilling, denne case har jeg selv været en del af, så arbejdet og løsningerne er taget ud fra mine praksiserfaringer. Den sidste del af rapporten tager udgangspunkt i de opstillede interviews af relevante fagpersoner, som til daglig sidder med IKT og BIM ekspertise på tegnestuerne. Deres input sammenholdt med den teoretiske baggrundsviden skal ved hjælp af løsningsforslag fra casen, danne grundlag for et projekteringsafsnit som tager sit udgangspunkt i de problemstillinger den projekterende møder i dagligdagen. 8 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 1.4 Målgruppe Målgruppen for denne opgave er medstuderende og fagpersoner, som til daglig sidder med BIM og IKT i projekteringen. Særligt fagpersoner som til daglig udarbejder udbudsmaterialet vil forhåbentligt kunne drage nytte af nogle af de ting jeg undersøger i nærværende rapport. Målgruppen kan også være den mindre eller mellemstore tegnestue, som ikke nødvendigvis har BIM eller IKT folk ansat. De kan med fordel læse undersøgelsen og på den måde danne sig et billede af hvad man skal være særlig opmærksom på i IKT-kontraheringen, samt den efterfølgende projektering, hvis man er omfattet af IKT-bekendtgørelserne. 1.5 Læsevejledning I rapporten vil ordet rådgiver blive omtalt en del gange. Da der findes flere forskellige slags rådgivere, som vist i organisationsdiagrammet, er det derfor i nærværende rapport ment som en projekterende rådgiver. Sproget i rapporten er meget fagspecifik og der angives ikke nogen ordforklaringer. Det er derfor påkrævet at læseren har en forståelse for det gængse projekteringssprog. Kilde- og bilagshenvisninger er beskrevet i en parentes efter brødteksten eller citatet. 1.6 Billedliste Figur 1 Organisationsdiagram……………………………………………………………………………………….….s.8 Figur 2 Udklip fra IKT-nøgle se bilag 2……………………………………………………………………………….s.20 Figur 3 Udklip fra IKT-nøgle se bilag 2……………………………………………………………………………….s.21 Figur 4 Oplæg til tilbudsliste i casen………………………………………………………………………………….s.22 Figur 5 Vedtaget tilbudsliste i casen………………………………………………………………………………….s.23 Figur 6 Brugerfladen i Dalux……………………………………………………………………………………………..s.23 Figur 7 Diagram over sammenhængen mellem Bauhausfil og Dalux database……………….…s.24 Figur 8 Udklip af BIM7AA typekodens opbygning……………………………………………………………..s.27 Figur 9 Udklip af CCS klassifikationens struktur……………………………………………….………………..s.28 Figur 10 Udklip af Cunecos oplæg til opmålingsregler samt tilbudslister………………….……….s.30 Figur 11 Udklip af bygningsdelsjournal i Excel med keynote……………………………………………..s.33 Figur 12 Udklip af bygningsdelskort genereret i Dalux..........................................................s.35 9 IKT i projekteringen Version 1 2. Jeppe Strand Lemvig 141994 27-03-2015 IKT i projekteringen IKT kommer ind i projektet når bygherre stiller krav til hvilke IKT ydelser han ønsker ved konkurrencens start. Denne aftale kaldes IKT-aftalen og er ofte et udfyldt paradigme fra BIPS, som danner aftalegrundlaget mellem bygherre og rådgiver. Problemstillingen er dog, at det er et kendt faktum at disse IKT-specifikationer er for eksperter og bygherren ved ofte ikke hvad hans valg har af konsekvenser for rådgivernes projektering. Dette afsnit gennemgår de væsentligste punkter i IKT-bekendtgørelsen vedrørende problemstillingen i rapporten. Der vil desuden blive kigget på sammenhængen mellem ydelsesbeskrivelserne og BIPS. Den sidste del af afsnittet omhandler branchens syn på IKT og hvad der bliver arbejdet på at forbedre eller ændre. 2.1 IKT-bekendtgørelserne I februar 2013 blev den gamle IKT-bekendtgørelse erstattet af to nye som omfatter brugen af IKT i alment og offentligt byggeri. Helt generelt er de to bekendtgørelser ens bortset fra paragraf 1, 2 og 12. Det er primært i anvendelsesområdet de er forskellige, da de har hjemmel i forskellige love, henholdsvis Almenboligloven og Lov om offentlig byggevirksomhed. (Bygningsstyrelsen, 2013) IKT-bekendtgørelserne har til formål at standardisere og sikre bygherren at der anvendes IKT i projekteringen, såvel som i driften. Bekendtgørelserne er udarbejdet af Klima-, Energi- og Bygningsministeriet. I dette afsnit fremhæves de væsentligste paragraffer i IKT-bekendtgørelsen for rådgivernes ydelser og ansvar, jf. problemstillingen i rapporten. Paragraf 3 i bekendtgørelsen er formuleret således: § 3. Bygherren skal sikre at der gennem hele byggesagen sker en koordinering af den samlede IKT-anvendelse mellem alle involverede parter. (118, BEK nr, 2013) Formålet med denne paragraf er at bygherren skal vælge en IKT-leder til projektet. Det er ofte en rådgiver, som skal varetage denne funktion og lederens rolle skal defineres i IKTydelsesspecifikationen. Det vil sige at den pågældende rådgiver har ansvaret for at koordinere byggesagens parter iht. IKT anvendelse. Han skal sikre at projektet som minimum overholder IKT-bekendtgørelsens krav. Da denne koordinatorrolle er beskrevet meget bredt i bekendtgørelsen, er der pålagt denne rolle et stort ansvar ift. at få koordineret på tværs af fagene. Denne koordinering kræver en del ekspertviden, samt en forståelse af hvilke ydelser de forskellige aktører skal varetage igennem projekteringen. Det kan derfor være svært at gennemskue omfanget ud fra ydelsesspecifikationen, hvis man ikke har den fornødne erfaring eller ekspertise. 10 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 I paragraf 4 stk.1 står der: § 4. Bygherren skal stille krav om, at digitale byggeobjekter gennem hele byggesagen struktureres, klassificeres, navngives, kodes og identificeres ensartet i en nærmere bestemt detaljeringsgrad. Bygherren skal i den forbindelse stille krav om, at byggeobjekterne forsynes med de informationer og egenskaber, der er relevante for den efterfølgende forvaltning, drift og vedligehold. (118, BEK nr, 2013) Det vil sige at bygherren skal sikre at der anvendes en kendt kodningsstruktur igennem hele byggesagen. Denne struktur tager ofte sit udgangspunkt i gængse standarder, som SfB, DBK, CCS eller den lidt mere sjældne OmniClass, samt den nye BIM7AA. Det som bekendtgørelsen ligger op til, er at bygherren i samråd med driftsherren skal vælge et klassifikationssystem, der kan videreføres til driften. Det er vigtigt at præcisere at der i en byggesag, sagtens kan optræde flere forskellige klassifikationssystemer på bygningsdelene, men hovedformålet er at man kan identificere bygningsobjekterne fra fagmodellerne på tværs af fag i tilbudslister og beskrivelser. Ideelt set kunne man undvære denne klassifikation af bygningsdelene, men det kræver at man udelukkende anvender BIM programmer til udarbejdelsen af det færdige udbudsmateriale på tværs af fag og aktører. Dette er på nuværende tidspunkt ikke muligt, da der ikke findes software der kan indeholde 3D modellering, beskrivelser, tilbudslister, driftsprogrammer o.l. Der er stadig en stor del af arbejdet som foregår på ikke database baserede programmer (fx Word og Excel), det er derfor nødvendigt at klassificere bygningsdelene, så de kan identificeres i hele byggesagen. Formuleringen om bygherrens krav på at byggeobjekterne bliver forsynet med informationer der kan bruges i driften, er til stor debat i branchen da det ikke har nogen økonomisk gevinst for rådgiveren. Rådgiveren skal selvfølgelig varetage bygherrens interesser, men som tingene er nu, så er det ikke synligt hvad bygherren vil have og slet ikke driftsherren. Det har ellers været et af de erklærede mål med BIM, at det skulle give gevinst i hele byggeriets levetid. COWI udarbejdede i 2009 en rapport, som skulle synliggøre fremtidens byggeri, fra vugge til grav, med BIM modellering som værktøj. På side 38 tabel 1 i rapporten, står der at branchen kan opnå en økonomisk gevinst på ca. 17 mia. kr./år. (COWI, 2009) Og da rapporten var udarbejdet på vegne af erhvervs- og byggestyrelsen, vakte den selvfølgelig en del opsigt. Det er bla på baggrund af Cowis rapport at BIM projekteringen blev et større krav fra bygherren, da de på baggrund af konklusionerne i rapporten kunne se at de ville få en meget mere præcis drift. Men det er på nuværende tidspunkt ikke implementeret i driften som man havde, turde håbe på. Cuneco har med deres CCS klassifikation kommet med et bud på hvordan man kan klassificere helt ned på en komponent i en bygningsdel. Jeg vil beskrive CCS under afsnittet Klassifikation senere i rapporten. 11 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Ifølge Peter Hyttel er bla BIPS, kernen i den forkerte drejning branchen har taget. Hos BIPS har man haft så meget fokus på nogle teoretiske tanker om den samlede værdikæde og BIMs værdi for hele byggekæden, så man har spredt sin produktportefølje over hvad man egentlig har skullet levere, CAD relaterede meget operationelle ting, som hvad lagstruktur bruger man til at omhandle dokumentstyring og CAD anvendelse, udbud, aflevering, alle discipliner har man ligesom prøvet at pakke ind i et stort monster af informationsteoretisk baserede ting om hvad der kunne være godt. (Interview Hyttel, 2015) Han mener at BIPS i sin egen ekspansion har hægtet rådgiveren af og blevet et kæmpe paradoks i branchen, da de komplicerer projekterne mere end de ensarter og standardisere dem. I paragraf 7 står der: § 7. Under projektering og udførelse skal bygherren stille krav om, at der anvendes objektbaseret bygningsmodellering. (118, BEK nr, 2013) På mange tegnestuer har man i dag en BIM koordinator tilknyttet hvert projekteringsteam. Denne funktion er blevet nødvendig bla på grund af paragraf 3 og 7 i IKT-bekendtgørelsen. Kravet om anvendelse af objektbaseret bygningsmodellering, har ændret rådgivernes produktionsapparat som Hyttel siger. De (BIPS) har sådan set forfejlet deres egne brancheorganisationers arbejde i og med at vores opgave består i at inddække vores egne ydelser, så vi ikke kommer ud i de situationer som vi ser der opstår nu på baggrund af BIPS IKT-specifikationer, som sådan set er blevet de dokumenter som bygherren råt for usødet smider med ethvert projekt og som giver voldsomme diskussioner i ethvert projekt for det går ind og konflikter med vores produktionsmetoder. (Interview Hyttel, 2015) Denne omstilling af produktionsapparatet som Hyttel omtaler er et kæmpe problem for rådgiverne da langt de fleste erfarne projekterende ikke magter denne omstilling. Derfor er man nødt til at have en BIM mand, koordinator eller manager på hver byggesag. Problemet er at projektlederen ofte ikke har indblik i hvor meget arbejde der ligger i bla at koordinere modellerne, lave mængdeudtræk og kollisionskontroller. Alle sammen opgaver som skal afklares i de IKT-tekniske specifikationer parterne imellem. Men formålet med denne paragraf er at sikre et bedre kvalitetssikret udbudsmateriale, da det tvinger parterne til at koordinere deres fagmodeller, om det så er ved faseskift, hver torsdag eller noget helt tredje må man så aftale specifikt i de tekniske specifikationer. 12 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 I paragraf 7 stk.3 står der: at fagmodeller koordineres via én eller flere fællesmodeller med henblik på simulering, kollisionskontrol, mængdeudtag, tegninger og beskrivelser, og (118, BEK nr, 2013) For at sikre modellens kvalitet skal den vedligeholdes og koordineres bla ved hjælp af kollisionskontroller. Disse kontroller skal sikre at modellerne bliver mere præcise, så man kan overholde de krav som er anført i paragraf 7 stk.3. Det er denne koordinering som gerne skulle gøre at man tidligt i en projekteringsfase på tværs af fag, kan fange eventuelle kollisioner mellem bygningsdele, objekter der ligger dobbelt i modellen og derfor giver en forkert mængde, samt eventuelle mangler i modellen. I § 9 stk. 1,2 og 4 står der: § 9. I det omfang der udbydes med mængder, skal bygherren sikre: 1) at mængder er indeholdt i udbudsmaterialets tilbudslister, 2) at udbudsmaterialet for den enkelte entreprise omfatter såvel tilbudslister som relevante, digitale, objektbaserede bygningsmodeller, hvoraf mængder kan udlæses, 4) at det af udbudsmaterialet fremgår, på hvilket grundlag mængderne er beregnet, herunder hvilke opmålingsregler og/eller opmålingsmetoder, der er anvendt. (118, BEK nr, 2013) Grunden til at man ønsker et udbud med beskrivende mængdebetegnelse, er at opnå et ens grundlag for de bydende. Det skal sikre bygherren det bedste resultat i licitationen. Disse mængder bliver genereret i BIM modellen og derefter ført over på en mængdeliste som sammensættes i en tilbudsliste. Dette er ændret ift. den gamle IKT-bekendtgørelse, da det nu kan vurderes af bygherren om det giver mening at lave mængdeudbud. Umiddelbart lyder det kun som en god ting, da alle entreprenører byder på det samme grundlag, men for de projekterende har det stor indflydelse på måden der bliver projekteret på. De skal være knivskarpe i modellen og have en helt struktureret måde at modellere på, så man sikrer at mængderne kommer rigtigt ud på tilbudslisten. Et eksempel er en gulvkonstruktion, som fx består af råbeton, afretningslag, flydemørtel og gulvbelægning. Her skal man have mængder ud på alle fire typer og hvordan gør man det korrekt. Der foreligger ikke nogle branchestandarder, så det er meget projektspecifikt hvordan man gør. Dette gælder også opmålingsreglerne, da der ikke findes nogle branchestandarder, selvom BIPS har en anvisning fra 2008, men denne er ikke målrettet mængdeudtag fra en BIM model. 13 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Mængdeudbud er kompliceret og branchen har også vidt forskellige holdninger til det. FRI mener bla: Den besparelse, som entreprenørerne vil få ved udbud med mængder, står ikke mål med rådgivernes ekstra arbejde. Dansk byggeri siger: Det vil skabe en produktivitetsgevinst hos de udførende på hele 2,5 mia. kr. (Søefeldt, 2013) Ift. ansvaret for mængderne står der således i AB92: § 2. Ved udbud forstås bygherrens opfordring til at fremkomme med tilbud. Stk. 2. Der bydes på grundlag af de oplysninger, som indeholdes i udbudsmaterialet. Dette materiale skal være entydigt og således udformet, at der er klarhed over ydelsernes omfang og indhold. (AB92, 1992) Det vil sige at det er bygherren som har ansvaret for at mængderne er anført korrekt, da entreprenøren kan kræve ekstra betaling hvis mængderne ikke stemmer overens. Bygherren vil selvfølgelig i den forbindelse føre ansvaret over på rådgiveren og det vil så være dem der står med ansvaret i den sidste ende. Det er i det hele taget den største juridiske problemstilling ved mængdeudbud. Hvem har ansvaret og hvem skal verificere mængderne? Det anbefales at bygherren i sit udbudsmateriale anfører at den valgte entreprenør verificere mængderne inden kontrahering, så forhandlingerne kan foregå på baggrund af de kontrollerede mængder. (Bygningsstyrelsen, 2013) 2.2 Ydelsesbeskrivelserne 2012 Danske ARK og FRI har igennem en årrække udarbejdet en ydelsesbeskrivelse for byggesagens parter. Den tager udgangspunkt i den traditionelle faseopdeling og er et værktøj til at sikre et gennemført projekt, som overholder gældende lovtekster. Der er til ydelsesbeskrivelsen tilknyttet et ydelsesskema, som er en tjekliste for hvem der har ansvaret for hvad i projektet. Dette skema er projektspecifikt og er egentlig et afkrydsningsskema hvor man kan få et overblik over aktørernes ydelser. Det som er essentielt ift. afsnittet om IKT, er at det ikke er udspecificeret hvad der præcist gemmer sig i de enkelte ydelser. Det er derfor svært at udarbejde en nøjagtig handlingsplan mellem byggeriets parter på baggrund af ydelsesskemaet. Under afsnit 8.1-8.7 i ydelsesbeskrivelserne er anført en kort beskrivelse af IKT ydelserne uden dog at være nærmere beskrevet, som tidligere præciseret. Der står dog i bunden af hvert afsnit, at ydelsen skal fastlægges i en IKT-specifikation. Det vil sige at man skal lave en særskilt IKT-specifikation for hvert punkt som er anført i ydelsesbeskrivelsen. Der er som sådan ingen regler for hvilken form for ydelsesspecifikation man anvender, den skal dog som minimum overholde IKT-bekendtgørelsen. Det er dog mere eller mindre blevet normen at anvende BIPS IKT-ydelsesspecifikation, med der tilhørende tekniske specifikationer. 14 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 2.3 BIPS IKT-ydelsesspecifikation BIPS opdeler IKT specifikationerne i to dele. Den første del er selve IKTydelsesspecifikationen, som er et dokument bygherren i samarbejde med driftsherren har udarbejdet inden konkurrencen. På det grundlag kan de bydende rådgivere så se i hvilket omfang de skal levere IKT ydelser. Specifikationen i sig selv er et ydelsesskema, hvor bygherren kan tilvælge og præcisere de IKT ydelser han ønsker på projektet. Den er nemlig opbygget af to dele, en basistekst og en projektspecifik. Sammenhængen mellem IKT-bekendtgørelsen, ydelsesbeskrivelserne og IKTydelsesspecifikationen kan ses i inddelingen af de enkelte afsnit. De afsnit i ydelsesbeskrivelserne som ikke var nærmere defineret, men anviste at man skulle anvende en IKT-specifikation, er de samme afsnit der bliver præciseret i BIPS værktøj. Ydelsesspecifikationen er opdelt i fire væsentlige afsnit. I rapporten bliver der fokuseret på de tre som har særlig fokus for den projekterende: 2) Digital kommunikation 3) CAD og bygningsmodeller 4) Digitalt udbud Til hvert afsnit er der tilknyttet en IKT-teknisk specifikation, som skal udarbejdes på baggrund af bygherrens ydelsesspecifikation. De tekniske specifikationer er bilag som udarbejdes imellem de projekterende, dog med bygherrens accept. Det er altså et styringsgrundlag og værktøj for de projekterende ift. at dokumentere hvem der gør hvad i forbindelse med projekteringen. Specifikationen ligger op til at man tager stilling til hvordan man vil efterleve de krav som er anført i ydelsesspecifikationen. De tekniske specifikationer er under løbende revision med IKT-lederen som den styrende. Det vil sige at man inden projektstart skal aftale hvordan man vil gribe projekteringen an, men det kan løbende tilpasses i byggesagen. 2.3.1 Klassifikation i BIPS paradigme I forhold til rapportens undersøgelse om særlige forhold og risici for den projekterende, er afsnit 2.4 i paradigmet til ydelsesspecifikationen væsentligt, da det omhandler hvilket klassifikationssystem der anvendes på sagen. Der står som udgangspunkt CCS som klassifikation og det har selvfølgelig en naturlig sammenhæng med at det er Cuneco, som hører under BIPS, der har udviklet dette system. De efterfølgende afsnit 2.4.1-2.4.7 er en faseopdelt inddeling af klassifikationens omfang. Her kan man præcisere i hvilket niveau der skal klassificeres og igen hænger det sammen med Cunecos bud på detaljegraden af informationsniveauerne. Det er i særlig grad i disse afsnit at man som projekterende skal være skarp på hvad der er anført under særlige forhold, da der er stor forskel på om man fx skal klassificere efter informationsniveau 3 eller 4. (Se bilag 1) 15 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 2.3.2 Koordinering i BIPS paradigme Under afsnit 3 om CAD og bygningsmodeller skal der udpeges en IKT-koordinator eller leder. Det vil typisk være en af de projekterende, da de ofte har størst erfaring i at arbejde med BIM modeller. Der er dog stor forskel på at modellere i en 3D model og styre IKT koordineringen mellem bygherre, projekterende, udførende og driftsherren. Og da man skal præcisere fagmodellernes detaljeringsgrad i de forskellige faser på tværs af fag, så ligger der et stort arbejde for koordinatoren i at samle og styre modellerne. Ligesom ved afsnittet om klassifikation er fagmodellernes detaljegrad ligeledes opdelt i afsnittene 3.3.1-3.3.7. Her bliver der ligeledes lagt op til at man skal definere informationsniveauerne på modellerne i de forskellige faser. Det er ligeledes IKT-koordinatoren der skal sikre at der udveksles filer og udføres konsistens- og kollisionskontrol både internt og samlet. 2.3.3 Digitalt udbud Ved udarbejdelsen af digitalt udbud foreligger der en teknisk specifikation, der ligger op til en styring omkring håndtering af bla beskrivelser. I afsnit 4.3 Udbudsmaterialets struktur, skal der foreligge en præcisering af hvilket paradigme der ønskes anvendt til projektet. I basisteksten er der på forhånd angivet BIPS B1.000 beskrivelsesstruktur, så hvis man ønsker en anden struktur, skal det aktivt tilvælges. Afsnit 4.4 s.13 under digitalt udbud er beskrevet: ”Udbudsmaterialet skal indeholde tilbudslister, hvor mængder er angivet, og der skal være sammenhæng mellem bygningsdelsbeskrivelser samt poster og mængder angivet i tilbudslisten.” (Ydelsesspecifikation, 2013) Dette er selvfølgelig et væsentligt punkt for de projekterende da der på nuværende tidspunkt ikke findes opmålingsregler af BIM modeller og der ligger en stor risiko for de projekterende ift. at få alle mængder med på tilbudslisten. Det er ligeledes en væsentlig faktor at der anvendes en struktureret metode til at sikre sammenhæng mellem fagmodel og tilbudsliste. Der findes heller ikke noget BIM værktøj, der på en simpel og præcis måde kan udtrække fx malede overflader og det er derfor nødvendigt for dem som udarbejder udbudsmaterialet at lave et manuelt udtræk på disse typer bygningsdele. Selvom Bygningsstyrelsen er kommet med en skabelon til hvordan man kan opsætte en tilbudsliste med mængder, er det stadig meget tegnestuespecifikt hvordan man vil opbygge tilbudslisten. 2.4 Task force under DI kontra BIPS Der er et opgør undervejs på brancheplan, som Hyttel formulerer det. Udviklingen ift. IKT ydelser er eksploderet de sidste 10 år og arkitekterne har ikke været gode nok til at følge med og sige fra. Nye standarder for projekteringens omfang er langsomt blevet implementeret i IKT-ydelseskontrakterne og bygherren ved groft sagt ikke hvad de køber. Denne udvikling har en gruppe fra Danske ARK og FRI, sat sig for under Dansk Industri (DI), at gøre noget ved. BIPS oprindelige formål var at varetage rådgivernes interesser og sikre dennes ydelser. BIPS har dog i en årrække udvidet deres værktøjskasse, til at indbefatte en 16 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 masse ekstra arbejder for rådgiverne. Denne udvikling skyldes til dels Cowis rapport om hvor meget byggebranchen kunne spare ved at anvende digitale bygningsmodeller. Der hvor paradokset fremtræder, er branchens omstrukturering fra CAD til BIM. Branchen havde nået et niveau, hvor man var specialister i at projektere med CAD værktøjer. Der var fastlagt en projekteringsmetodik og et produktionsapparat som kunne skabe det som det hele handler om, et godt hus. På den anden side kommer der et krav om digitalisering af byggebranchen og dermed også en omstrukturering af produktionsapparatet. Det vil sige at specialisterne i at projektere i CAD ikke kan bruges på samme måde, da der nu skal projekteres i BIM. Branchen mister derfor den gruppe af specialister, som ikke formår at omstille sig, det er derfor en helt ny gruppe af mere uerfarne projekteringsfolk der skal køre BIM projekterne. Der vil selvfølgelig altid være afvigelser fra dette, men overordnet set er hele produktionsapparatet hos rådgiverne ændret. Det er opgøret med alle ekstra arbejderne som task forcen vil bekæmpe. BIPS er ved at relancere deres IKT-specifikationer, så de er nemmere at overskue og forstå. De skal ikke kun være for eksperter og så skal de tilrettes de projekterendes ydelser. (Forprojekt, 2015) Denne omformulering af IKT-specifikationerne skal give rådgiverne et bedre overblik over hvad der er indbefattet i de forskellige IKT-ydelser. På spørgsmålet om hvordan branchen ser på BIPS forprojekt med henblik på at relancere IKT-ydelsesspecifikationerne siger Hyttel. den er så også meget til debat, da den rapport der er lavet bliver stemt ned i task forcen, det vil vi ikke, vi vil ikke arbejde med forskellige niveauer i de her ydelser. Det handler om at komme væk fra at det er BIPS der definerer branchens ydelser, til det er branchen selv. (Interview Hyttel, 2015) Hyttel siger direkte at de har tænkt sig at forkaste BIPS nye IKT-specifikationer, da de stadig er alt for omstændige og omfattende. Han siger at der arbejdes på en helt ny type IKT-aftale, som overholder bekendtgørelsens minimumskrav. På den måde vil alle bygherrens tilvalg, figurere som ekstra ydelser og det vil derfor være nemmere for rådgiverne at øge honoraret. Der bliver desuden i forlængelse af arbejdet med BIM7AA, som uddybes i et senere afsnit, arbejdet på en leverancespecifikation, som skal definere de rådgivende parters ydelser ift. hinanden. Denne specifikation orienterer sig udelukkende mod de projekterendes arbejde igennem faserne, hvordan modellerne koordineres og hvilke parametre der skal tilføjes de enkelte bygningsdele igennem projekteringen. Gentofte er en af de førende kommuner ift. IKT anvendelse på byggesager. De har ambitioner om at digitalisere samtlige af kommunens bygninger, samt udarbejde driftsplaner og 3D modeller. Kommunen har ansat folk til kun at varetage den digitale udvikling og en af dem er Stine Thulin, hun siger således om BIPS IKT specifikationer. 17 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 ”Brug IKT-specifikationerne – det er et rigtigt godt værktøj, og det er forholdsvis nemt at gå til. Det kræver selvfølgelig, at man lige sætter sig ind i det, og der er en del underdokumenter, man skal forholde sig til. Men når først det er gjort, og når man har taget stilling, så kan man genanvende sit eget IKT-paradigme på de fleste sager.” (Gentofte, 2011) Det hun siger, er at de har stor succes med at anvende BIPS paradigmer og at de kan standardisere brugen af dem. Det underbygger Hyttels udsagn om at bygherren vedlægger BIPS IKT-ydelsesspecifikationer til ethvert projekt uden skelen til byggesagen. Men det er selvfølgelig ”nemt” for bygherren at sikre IKT aftalen på denne måde. Stine Thulin siger videre om de projekterendes manglende evner til at projektere med 3D objekter. ”De nikker og siger ja, men vi kan ofte over byggewebben se, at de alligevel projekterer i 2D. Generelt er det vores erfaring, at kompetencerne i 3D-modellering på tegnestuerne er langt tilbage at ønske. Der sidder nogle pionerer på de fleste tegnestuer, som har tilegnet sig de nødvendige færdigheder. Men der er stadig mange, som ikke mener, at det er noget, de behøver beskæftige sig med” (Gentofte, 2011) Dette harmonere meget godt med Hyttels problemstilling omkring de erfarne projekteringsfolk, man kan derfor diskuterer hvem der har problemet, da det selvfølgelig ikke er hensigtsmæssigt at hægte alt den byggetekniske erfaring og viden af blot fordi bygherren ønsker en 3D model til at visualisere huset over for brugerne. For som de også selv har erfaret i Gentofte, så er der stadig langt til at man kan implementere 3D modellen i et driftssystem. ”Der er vi ikke endnu med vores nuværende FM-system, men vi er i gang med en proces med at klarlægge, hvordan vi kan få imødekommet disse behov. Vi vil have et system, som også kan bruges af institutionslederne og inspektørerne i kommunens ejendomme”. (Gentofte, 2011) Hyttel svarer til spørgsmålet om hvorvidt bygherren kan anvende BIM modellerne i driftsfasen. Nej, det gør de ikke og det er præcis problematikken, hele tankegangen er forfejlet, fordi projekteringssoftwaren kan ikke bruges til sådan noget. Det er ikke det der er meningen med softwaren. (Interview Hyttel, 2015) 2.5 Delkonklusion IKT-bekendtgørelserne er styrende for rådgivernes ydelser. Det kan være svært at gennemskue hvad der konkret menes med de enkelte paragraffer. Rådgiverens IKT- eller BIM ansvarlige skal kunne gennemskue omfanget af ydelserne ved projektopstart. For at efterleve IKT-bekendtgørelsen er der en helt klar skabelon formuleret af BIPS. Problemet er at den kan være svær at efterleve, da den nemt kan blive meget omfattende, da bygherren 18 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 ofte tilvælger samtlige ydelser paradigmet ligger op til. Det vil sige at et lille projekt potentielt kan blive meget omfattende ift. IKT-ydelser. Efter Danske ARK og FRIs indtræden i DI, er der så småt opstået et opgør med branchens drejning og i særlig grad BIPS paradigmer. Dette opgør udspringer i rådgiverens interesse om at få indsnævret ydelserne og fralægge mange af de uhåndterbare opgaver som er lusket ind fra siden. Der skal formuleres en standardaftale der som minimum overholder IKTbekendtgørelsen. 19 IKT i projekteringen Version 1 3. Jeppe Strand Lemvig 141994 27-03-2015 Case – Praksis eksempel I afslutningen af min praktik kom jeg med på udarbejdelsen af hovedprojektet til et byggeri på ca. 12000kvm. Ift. min problemstilling vil jeg fremhæve de problematikker vi har siddet med på sagen og hvorfor vi havnede i de situationer. Da det er en offentlig bygherre og vi er langt over entreprisesummens tærskelværdi, skulle vi derfor efterleve IKT-bekendtgørelsen nr.118 om offentligt byggeri. 3.1 IKT tekniske specifikationer Da projektet blev opstartet for år tilbage, har der været en del udskiftning på projektlederposten. Det vil sige at da den tredje projektleder lige var kommet på sagen, gav det selvfølgelig en masse præcisering ift. det aftalegrundlag der var indgået med ingeniøren, som er totalrådgiver og da hele projekteringsgruppen var kommet på til hovedprojektet, var der ingen der anede noget om hvad der tidligere var aftalt. Derfor var det også noget af en overraskelse da vi blev gjort opmærksomme på, at vi skulle klassificere vores bygningsdele med SFB systemet. Vi havde brugt en masse tid og ressourcer på at klassificere med den nye typekode BIM7AA, som godt nok minder om SFB, men der er alligevel en stor forskel. Det præciserer jeg under afsnittet om klassifikation. Efter at vi havde typekodet alle vores bygningsdele med BIM7AA, modtog vi en nummereringsnøgle fra ingeniøren. Denne nøgle præciserede en SFB syntax, som kan ses på udklippet nedenfor. Figur 2 Udklip fra IKT-nøgle se bilag 2 Det vil sige at vi i praksis skulle tilpasse alle vores i forvejen typekodede bygningsdele til SFB, med en parentes om hovedgruppen. Men det var ikke kun der problemerne opstod, vores BIM afdeling ville have at vi anvendte BIM7AA, med et løbenummer fra 001-999. I den fremsendte nummereringsnøgle var der ligeledes et skema ift. hvordan vi skulle anvende løbenummeret, som man også kan se i syntaxen. 20 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Figur 3 Udklip fra IKT-nøgle se bilag 2 Som det kan ses på udklippet om løbenummeret, så vil vores arkitektbygningsdele kollidere med konstruktionsbygningsdelene, da vi i teorien anvender de samme løbenumre. Da de tekniske specifikationer var aftalt lang tid før den nuværende projektgruppe kom på, havde vi ikke været opmærksomme på at vi skulle efterleve denne struktur. Det var ydermere ikke muligt at opspore den IKT-aftale som var indgået mellem bygherre og totalrådgiveren. Vores held var at totalrådgiveren tilsyneladende havde fundet IKT-aftalen ligeså uinteressant som os, da vi kunne se i flere af de tekniske specifikationer, at vi rent faktisk ikke tilnærmelsesvis overholdte det som var aftalt. Der stod bla i den tekniske afleveringsspecifikation at vi skulle anvende Drofus på rum, at der skulle klassificeres med SFB på driftsrelevante bygningsdele o.l. (se bilag 3) Det arbejde vi nu satte os for, var at lave en sammenhæng mellem BIM7AA og SFB, så vi kunne bøje nummereringsnøglen lidt til vores fordel samtidig med at ingeniøren ikke skulle lave noget om, da det jo groft sagt var os der skulle makke ret. Umiddelbart lyder det simpelt at tilpasse vores typekode til SFB, men det handlede om at bibeholde det produktionsapparat vi ville bruge på tegnestuen, samtidig med at det kunne sammenkædes med SFB. I IKT-bekendtgørelsen står der at klassifikationen skal hænge sammen med bygningsobjekter, bygningsdelsbeskrivelser og tilbudsliste. Det var derfor vigtigt at starte bagfra med tilbudslisten, hvordan skal den opsættes og grupperes. Vi startede derfor med at skabe denne sammenhæng. Det lykkedes på baggrund af den fremsendte tilbudsliste at overtale bygherren til at undlade SFB på arkitektens bygningsdele, det vil sige at vi kunne bibeholde BIM7AA typekoden. Dette lykkedes kun fordi vi kom med et konkret løsningsforslag som kunne skabe en sammenhæng mellem ingeniørens og arkitektens bygningsdele uden at nogen parter skulle lave om på deres kodning. I det næste afsnit beskriver jeg mit løsningsforslag. 21 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 3.2 Sammenhæng i udbudsmaterialet For at efterleve kravene om udbud med mængder og sikre en sammenhæng i projektet, er det essentielle at få afklaret klassifikationen. Udbuddet er opdelt i fire storentrepriser, hvor vi primært på arkitektdelen fokusere på komplettering og råhus. Det er derfor nødvendigt at lave en struktur for tilbudslisten der kan indeholde ARK og KON bygningsdele. Mit forslag var at anvende SFB som et prefix på vores bygningsdele, det vil i praksis sige at vi klassificere med SFB hovedgruppen og anvender BIM7AA som løbenummer, mens ingeniøren kan beholde udgangspunktet fra den fremsendte syntax. På den måde undgår vi at der er sammenfald af klassifikationsnumre og tilbudslisten kan grupperes efter SFB hovednummeret, se eksempel nedenfor. Figur 4 Oplæg til tilbudsliste i casen Men det mest optimale for os, ville selvfølgelig være at vi ikke skulle til at lave et SFB prefix. Derfor tog vi teten over for totalrådgiveren og listede nogle mulige scenarier op. - Vi ville meget gerne anvende BIM7AA. Kan dette ikke lade sig gøre, benytter vi et SFB prefix. Vedlagde et udkast til en mulig tilbudsliste med BIM7AA. Vi tog på den måde styringen og fik overtalt totalrådgiveren til at vi kunne fortsætte med BIM7AA, til trods for alt hvad der var angivet om SFB iht. klassifikation i udbud og drift. 22 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Figur 5 Vedtaget tilbudsliste i casen Da det kan være svært at have et præcist overblik over bygningsdelene i fagmodellen, anvender man ofte en bygningsdelsjournal eller bygningsdelskort. På Sterilcentralen blev det besluttet at teste et nyt webbaseret databaseprogram Dalux. Dalux skal hjælpe til med at kvalitetssikre fagmodellens objekter og på den måde sikre at de er beskrevet og anført på tilbudslisten. Figur 6 Brugerfladen i Dalux Det vil i praksis sige at bygningsdelsjournalen bliver genereret ud fra fagmodellen og på den måde kan det sikre at vi får alle bygningsobjekterne med på tilbudslisterne og beskrivelserne. Dette værktøj egner sig bedst til at komme på projektet ved dennes opstart og ikke som i vores tilfælde på hovedprojektet, da der er blevet brugt rigtig meget tid på at diskutere hvad slutproduktet af Dalux skulle være, samt selve processen med at få skabt forbindelsen mellem fagmodellen og Dalux databasen. 23 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 En anden væsentlig faktor ved denne implementering af Dalux, er oprettelsen af en katalog fil, som bliver kaldt Bauhaus modellen. Denne model er bygningsdelskatalogfil og det er i denne man skal oprette nye bygningsdele og linke dem til Dalux, før man kan trække dem ind i fagmodellen. Det har været en omfattende proces, da alle bygningsdele i modelfilen skulle oprettes i Dalux og så i Bauhaus, for så til sidst at blive linket sammen med fagmodellen igen. Men grunden til at indføre en Bauhaus model, er at hvis man fx har 5 ARK modeller, så bliver alle bygningsdele styret et sted fra og på den måde kan man bedre sikre at man får de rigtige mængder, samt en oversigt over hvilke bygningsdele man har i sine modeller. Det skal ligeledes også sikre at den samme bygningsdel ikke bliver oprettet på to forskellige måder. Figur 7 Diagram over sammenhængen mellem Bauhausfil og Dalux database Med de nye tiltag omkring bygningsdelsjournaler genereret fra Revit, samt en klassifikationsstruktur der skulle skabe sammenhængen fra fagmodel til tilbudsliste, skulle det gerne give et bedre og mere præcist udbudsmateriale. Men den største udfordring ved projektet, var manglen på standard projekteringmetodikker, da der ikke rigtig var noget reference projekt vi kunne tage udgangspunkt i eller tegnestuestandarder. Det vil i praksis sige at man arbejder ud fra princippet om at prøve sig frem og så vurdere udkastet iht. det ønskede slutresultat. Denne fremgangsmåde har været meget tidskrævende da vores fagmodel ikke var modelleret med henblik på de enkelte entreprisers mængdeudbudte tilbudslister. Det vil sige at rent Revit teknisk skulle modellen opdeles i bygningsobjekter, som passede til de enkelte entrepriser. Dette var en meget omstændig og kompliceret 24 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 proces, da der ikke findes en ”rigtig” måde at gøre det på. Og den tid der blev brugt på at tilpasse modellen gik groft sagt fra detaljeringen. 3.3 Opsummering Den væsentligste ting at opsummere ift. min problemstilling, er IKT aftalernes betydning for projektet. Dels at krav til IKT ydelser kan overraske så sent i processen, men måske mest hvordan man under projekteringen kan bøje og dreje aftalerne til egen eller fælles fordel. Det er tankevækkende at så læsbare krav som er angivet i IKT ydelserne, tilsyneladende uden bygherrens indvendinger kan omgås og undlades. Så er det man tænker hvorfor de er formuleret, når de ikke bliver efterlevet. Selve projekteringen har været styret af mængdeudbuddet. Alle beslutninger i processen er taget på baggrund af udbudsformen og det output der skulle genereres. Det har i praksis betydet at hovedvægten af projekteringsarbejdet er gået med at formulere og definere bygningsdele i Dalux og tilbudslisterne. Den tid kunne man have brugt på detaljeringen og samlingen af huset, da der her ofte dukker uventede ting op. 25 IKT i projekteringen Version 1 4. Jeppe Strand Lemvig 141994 27-03-2015 Projektering Projekteringsmetodikker er ofte meget tegnestuespecifikke og på den måde er det svært at skabe en egentlig afklaring omkring dette, så i rapporten bliver der taget udgangspunkt i de problemstillinger der er blevet fremhævet i IKT afsnittet, samt praksis løsningsforslag fra casen. I dette afsnit vil der indgå eksempler på klassifikationssystemer anvendt i branchen og en forklaring på disses egenskaber og betydning. Der vil endvidere også blive præciseret hvordan man kan lave mængdeudbud, kvalitetssikring og styring af BIM modellerne, samt anvendelse af bygningsdels- journaler og kort i projekteringen. Der vil i afsnittet om bygningsdelsjournaler indgå en sammenligning af forskellige software til udarbejdelse af udbudsmateriale samt en perspektivering ift. fremtidens BIM projektering. 4.1 Klassifikationssystemer Indledningsvis er det vigtigt at præcisere forskellen på en klassifikationskode og en typekode. Da der er nogle helt væsentlige forskelle, specielt når man tænker på hvilket output det skal give. Det er endvidere vigtigt at forstå forskellen på en bygningsdel og bygningskomponent. Det er meget mere kompliceret og tidskrævende at klassificere en bygningskomponent frem for en bygningsdel. En bygningsdel kan bestå af flere bygningskomponenter, fx en skalmur, som består af teglsten, murbindere, isolering, mørtel og pap. Man kan potentielt klassificere mørtelen og på den måde bruge det i driften. På den måde er der kæmpe forskel på hvor stort projekteringsarbejdet er med at klassificere bygnings- dele eller komponenter. 4.1.1 Typekode Typekoden er et arbejdsredskab til den projekterende ift. at identificere og skabe sammenhæng i projekteringen. Typekoden vil ofte være et internt værktøj, som ikke anvendes til andet end en generel kode for en given bygningsdel. Det er derfor væsentlig at klargøre, at en typekode ikke er tilstrækkelig for bygherren, hvis denne i sin IKTydelsesspecifikation eller lignede, har stillet krav til klassifikation af de enkelte bygningsdelskomponenter til brug i driften. Typekoden kan sagtens kombineres med en klassifikationskode, som tidligere forklaret i casen, hvor man kombinerede BIM7AA typekoden og SFB klassifikationen. Der er netop udviklet en ny typekodningsstruktur som udspringer af SFB og folkene bag det er syv store tegnestuer fra Aarhus. Derfor hedder typekoden BIM7AA. 26 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Figur 8 Udklip af BIM7AA typekodens opbygning (BIM7AA, u.d.) Typekoden er omtalt brugt i casen og den er stadig ved at blive implementeret af flere rådgivere, da man på brancheniveau er ved at lave et opgør med BIPS og deres klassifikationssystem CCS. 4.1.2 Klassifikationssystemer Som indledning til afsnittet vil jeg kort orientere om at der findes en masse forskellige klassifikationssystemer, SFB, DBK, OmniClass, CCS o.l. Jeg vil primært fokusere på CCS og SFB, da CCS er BIPS foretrukne system og det derfor er indskrevet i alle deres IKTparadigmer. Jeg vil også skrive lidt om SFB, da det stadig er et meget anvendt system, samt det faktum at BIM7AA udspringer af SFB strukturen. SFB er den mest anvendte klassifikationsstruktur i byggebranchen og den er derfor gennemprøvet igennem en årrække. SFB systemet er opdelt i 9 overordnede emner, der så er underopdelt i hoved- og undergrupper. Mange af grupperne er defineret som standard og de er så suppleret op med både hoved- og undergrupper som man kan lave projektspecifikke. Dette klassifikationssystem bliver kun anvendt på bygningsdele og det kan derfor sagtens efterleve kravene i IKT-bekendtgørelsens §4. Men i takt med udviklingen af det digitale byggeri og BIPS stadig større indflydelse på bygherrens ønsker ift. IKT, er der blevet pålagt ekstra ydelser hvor den væsentligste er BIM modellens output til driften. SFB systemet er derfor ikke tilstrækkeligt i sin rene form og Cuneco blev sat til at udvikle et 27 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 klassifikationssystem, som kunne bruges på bygningskomponenter og på den måde få endnu mere information ind og ud af BIM modellerne. Cuneco Classification System – CCS er blevet det klassifikationssystem som skal videreføre tankegangen om at en byggesag skal hænge sammen fra byggeriets projektering til nedbrydning og genanvendelse. CCS systemet kan anvendes på både bygningsdel og komponentniveau og er derfor et værktøj som potentielt set kan anvendes til driften. Da langt de fleste bygherre ønsker at man anvender BIPS IKT-paradigmer, vil der automatisk være udfyldt en masse tilvalgsfelter om at det anvendte klassifikationssystem skal være CCS og at de forskellige faser skal opfylde informationsniveauerne som ligeledes er defineret af Cuneco. Iht. IKT-bekendtgørelsen §4 om valg af klassifikationssystem er formålet således: Formålet med kravet er at sikre at informationer om byggeobjekter og deres egenskaber i videst muligt omfang er til rådighed for bygherren og hans rådgivere og udførende under projekteringen og udførelsen, samt at driftsrelevante objekter og deres egenskaber står til rådighed for driftsherrens anvendelse ved byggeriets overdragelse i et nærmere specificeret omfang. Det er vigtigt, at dataudvekslingen kan ske så uhindret som muligt. (Bygningsstyrelsen, 2013) CCS systemet giver rådgiverne mulighed for at klassificere og identificere bygningsdele og deres komponenter i en bred udstrækning, samtidig med at man kan sætte parametre på den enkelte komponent om placering i byggeriet samt hvilke bygningsdele den tilhører. Figur 9 Udklip af CCS klassifikationens struktur (Cuneco, u.d.) 28 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Cuneco mener at dette er nødvendigt for at kunne identificere og gruppere de enkelte komponenter. Eksempelvis kan et vindue, som klassificeres %QQA, have et prefix foran som angiver placering på en given etage. På den måde kan du lave en unik klassifikationskode af hvert enkelt objekt, selvom vinduerne i princippet er ens, men er placeret på forskellige etager. Hele den her tankegang om at man rent klassifikationsmæssigt, som man havde det i DBK og som man nu viderefører i CCS, hvor man laver referencestrukturer, hvor en dør er en del af et vægsystem, hele den tankegang er overført fra mekanikken, hvor en transistor er en del af et elektrisk kredsløb. I modelprojektering og i det arbejde rådgiveren sidder og laver, er den type af ting ikke nødvendig. (Interview Hyttel, 2015) Denne måde at klassificere på er langt udover hvad der står i IKT-bekendtgørelsen og det skaber ingen værdi for rådgiveren, derfor skal man være ekstra opmærksom på i hvilket omfang klassifikationen skal udføres med CCS. Denne tankegang omkring det at lave et identifikationsprefix på hver enkelt bygningskomponent udspringer fra et system som slet ikke har noget med byggebranchen at gøre. Det er derfor ikke en tankegang som ligger i branchen og umiddelbart er det primært entreprenørerne i deres tilbudskalkulation, samt driften der kan drage nytte af denne identifikation. 4.2 Mængdeudbud og tilbudsliste Udbud med mængder er et væsentligt punkt i IKT-bekendtgørelsen, da det potentielt giver bygherren nogle helt klare fordele i forbindelse med konkurrencen. Man skal dog være særlig opmærksom på hvilken form for udbud man har på sin byggesag, da projekteringsgraden er væsentlig mindre hvis man har et funktionsudbud eller en totalentreprise, har man disse former på sin byggesag er mængderne overflødige. Det jeg vil fokusere på for den projekterende er et udbud med mængdeangivelse på den enkelte bygningsdel. Det kunne fx være til en hoved-, fag- eller storentreprise, hvor man laver en samlet tilbudsliste indeholdende samtlige poster/bygningsdelstyper i projektet. Der vil til afsnittet blive belyst følgende projekteringsmæssige problemstillinger. - Hvordan trækker man de rigtige mængder ud af modellen? Hvilke måleregler kan man anvende? Hvordan strukturer man tilbudslisten? Hvem har ansvaret for mængderne? I casen strukturerede vi mængderne ved at angive hvilke bygningsdele som tilhører de forskellige entrepriser, det gjorde vi fordi det handler om hvilket output vi kan generere. Det er selvfølgelig en smule anderledes i casen, da det er en storentreprise, frem for en hovedentreprise, hvor det er en entreprenør der byder på hele sagen. I casen kunne vi i Dalux angive entreprisenummer, klassifikation og bygningsdelsbeskrivelsesnummer. Disse 29 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 oplysninger trak vi over i tilbudslisten, som så blev tilpasset efter den opsætning totalrådgiveren ønskede. I en hovedentreprise vil man fx udbyde en samlet tagkonstruktion, mens man i en fagentreprise ville dele den op i fx tømrer, murer og blikarbejde. Det er derfor vigtigt at strukturerer bygningsdelene efter den entrepriseform der anvendes på sagen. Der findes ikke nogen standarder på opmålingsregler til BIM modeller, men der findes software hvor man kan se hvordan mængden på den enkelte bygningsdel bliver opmålt. Det er vigtigt at man på tilbudslisten angiver hvilken målemetode der er blevet anvendt. Der kan nemlig være flere forskellige typer, da man fx ikke per automatik kan trække overfladebehandlinger ud af modellerne. Nogle gør det på rum, men maleren stopper jo ikke med at male ved underkant loft, så der vil være noget manuel tilpasning alligevel. Derfor er det vigtigt at man i tilbudslisten har en angivelse af de stipulerede ydelser. Selve mængdeudtrækket kan foregå på flere forskellige måder. Hvis man projektere i Revit, så kan man trække mængden ud via schedules og på den måde få en mængde af den givne bygningsdel. Fordelen ved Revitudtræk er at den forstår hvilken enhed de forskellige bygningsdele skal udtrækkes i. Ulempen er at Revit kan give unøjagtige mængder, så man skal være meget struktureret i sin modellering. Cuneco har netop offentliggjort deres oplæg til opmålingsregler i BIM projektering, samt hvilke data der skal indgå i tilbudsgivningen og en standard for en tilbudsliste. Dette værktøj er primært udlagt som en beskrivelse af metoden og ikke som et egentligt værktøj. Det tager selvfølgelig sit udgangspunkt i CCS klassifikationen og det nedenstående er et udklip fra nyhedsbrevet. Figur 10 Udklip af Cunecos oplæg til opmålingsregler samt tilbudslister, se bilag 6 30 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Cuneco skriver videre i nyhedsbrevet at værktøjerne til at udføre disse procedurer vil blive lanceret d.27 marts 2015. Essensen i CCS opmålingsregler er at skabe en sammenhæng mellem opmålingsreglerne og de enkelte bygningsdelstyper. Den væsentligste problemstilling ved mængdeudbud er, hvem har ansvaret for mængderne angivet i tilbudslisten? Som tidligere fortalt under IKT afsnittet, så har bygherren iht. AB92 ansvaret for at den korrekte mængde er angivet på tilbudslisten. På den måde er det også rådgiveren som alene står med ansvaret for mængderne. Hyttel svarer til spørgsmålet om, hvilke værdier rådgiveren får ved et mængdeudbud? Vi får kun risikoen. (Interview Hyttel, 2015) Det kan derfor være en god ting at indskrive i AB92, at entreprenøren skal verificere mængderne x antal dage efter modtagelse af udbudsmaterialet. En anden mulighed kunne være at sende modellen til mængdetjek hos eksterne rådgivere. På den måde kan man muligvis fange ting i modellen som er unøjagtige og som potentielt kan give en forkert mængde. 4.3 Koordinering af IKT-ydelserne Bygherren stiller ofte krav til at en af rådgiverne skal være IKT-leder på projektet. Det vil sige, hvis man sidder som totalrådgiver, så har man ansvaret for at sikre et ensartet og sammenhængende projekt med de andre rådgivere. Hvis man er underlagt at anvende BIPS tekniske specifikationer, så skal man ud fra disse afklare BIM projekteringens omfang. Koordineringsarbejdet er ofte meget tidskrævende og det er derfor vigtigt at man indregner disse ydelser i sagen fra projektopstart. Der er selvfølgelig en masse ting man afklarer i IKT aftalerne, men der vil ofte komme en del projektspecifikke tiltag til, som man skal tilpasse projektet efter. Hovedsagen er at de timer der bliver brugt på at afklare projekteringsmetodikkerne betaler sig i den sidste ende. Dette er dog stadig en proces hos rådgiverne, da der stadig er en del i branchen som ikke mener at BIM projektering betaler sig. Hyttel formulerer IKT-lederens rolle således. IKT ledelsen er en ting som er blevet flettet ned over rådgiveren, hvor de både får ansvaret for at operationalisere alle de her tanker og hvis man så igangsætter en udbudsproces med mængder, så gælder det, så har rådgiveren ansvaret for at det kan forstås og tolkes korrekt over forskellige projekteringsplatforme. (Interview Hyttel, 2015) I forbindelse med den nye typekode BIM7AA, er der et leveranceskema på vej som skal hjælpe koordinatoren til at synliggøre fordelingen af ydelserne. Dette skema er endnu et værktøj i en lang række til at definere de projekterendes ansvar overfor hinanden. Men der vil højst sandsynligt aldrig være en helt klar holdning til leverancerne, da man ofte arbejder i forskellige projekteringsprogrammer og med forskellige metodikker. Noget der kan være med til at skabe fejl, er hvis rådgiverne ikke taler samme sprog, hvis de arbejder på forskellige platforme. (Interview Hansen, 2015) Det Hansen mener, er at man kan nå rigtig 31 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 langt med koordineringen, hvis bare de projekterende kunne arbejde på samme platform. Det vil sige at man fx modellerer i Revit og laver bygningsdelsjournaler, beskrivelser og tilbudslister i Dalux. På den måde har man samlet hele projekteringsarbejdet på de samme platforme. Så sikrer man også et mere præcist udbudsmateriale, da der er en større sandsynlighed for at opdage evt. fejl og mangler. 4.4 Sammenhæng i udbudsmaterialet Iht. IKT-bekendtgørelsen så er det klassifikationskoden på den enkelte bygningsdel, som skal skabe sammenhængen i projektet. Det er her essentielt for rådgiveren at sikre en simpel og overskuelig klassifikationsstruktur, som giver mening ift. at sikre en god projektering. Det kunne fx være BIM7AA på bygningsdelsniveau. Det kan så suppleres med et bygningsdelskort på hver typekode som skal driftes, dette kort kan entreprenøren så udfylde med vedligehold på den enkelte komponent, totaløkonomi, certificeringer, miljøkrav o.l. På den måde kan man som rådgiver skabe de overordnede rammer for bygningsdelenes dritfsplaner, dog uden at påtage sig ansvaret for komponenternes egenskaber. En anden problemstilling ved BIM projekteringen er detaljegraden i de objekter man putter ind i modellen. Hvor går grænsen, skal man modellere og trække mængder ud på samtlige objekter i modellen, eller ligger der stadig et arbejde for entreprenøren i at danne sig et overblik over udbudsmaterialet og på den baggrund indregne evt. objekter, som ikke er modelleret men tegnet med 2D streger. 4.5 Bygningsdelsjournal Dette afsnit omhandler bygningsdels- journaler og kort. Forskellen på journalen og kortet, er kort sagt at journalen typisk er en oversigt over samtlige bygningsdele i projektet, hvor egenskaberne på hver bygningsdel er beskrevet. Det er på mange områder det samme som kortet består af, men her vil man typisk gå mere i detaljen med egenskaberne på hver komponent i bygningsdelen. Det er oplagt at bruge et bygningsdelskort til at indføje særlige driftsforhold for netop denne bygningsdel. Metoden til oprettelse af disse journaler og kort er meget tegnestuespecifik og den eneste sammenhæng man kan trække er at det er et rigtig godt redskab til at synliggøre hvilke bygningsdele man har i projektet, samt muligheden for at analysere om bygningsdelene og komponenterne kan opfylde diverse krav fx brand, lyd, tæthed mm. Afsnittet er opdelt i to forskellige typer bygningsdelsjournaler, samt en opsummering og perspektivering af journalernes anvendelsesmuligheder nu og i fremtiden. 4.5.1 Keynote og Excel Det er efterhånden en udbredt tilgang til bygningsdelsjournalen at oprette den i Excel. På den måde kan man samle rigtig mange egenskaber om hver enkelt bygningsdel på en simpel og overskuelig måde. 32 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Figur 11 Udklip af bygningsdelsjournal i Excel med keynote Der er mange måder at anvende Excel journaler på, men den mest interessante måde at anvende Excel på, er ved at oprette en txt fil af Excel arket og på den måde kan man anvende det i sin Revitmodel. Det sker ved hjælp af funktionen keynote. Keynoten kan læse txt filen fra Excel og på den måde kan man bruge nogle af de informationer man har oprettet i bygningsdelsjournalen på objekterne i Revit. Begrænsningen ligger dog i at man kun kan bruge tre kolonner fra Excel arket, det vil sige at inden man laver txt filen, så skal man fjerne alle de kolonner man ikke vil have med over i keynoten. Og da man kun kan have tre kolonner, så skal man være meget præcis i hvilke informationer man ønsker at tagge med i fagmodellen. Styrken ved keynote er at det er et meget simpelt værktøj, som man hurtigt kan opsætte og anvende i modellen. Excel har en meget hurtig og overskuelig brugerflade, det gør det nemt at tilpasse filens egenskaber efter det ønskede output. Man kunne fx strukturere filen så den bliver sorteret efter klassifikation eller bygningsdelsnummer. Herefter kan man så beskrive en konstruktionsopbygning, som man kan tagge med på snit. Ligeledes kan man fx tagge med klassifikationskoden på planerne og så vil Revit automatisk oprette en legend som forstår hvilke bygningsdele der er tagget og på den måde får du en meget præcis angivelse af bygningsdelene på de forskellige planer. Denne metode er rigtig god til at kvalitetssikre dit tegningsmateriale ift. om der er taget stilling til alle objekter i projektet. I Revit kan man tagge alle bygningsdele af en bestemt type, fx vægge, tage o.l, på en gang. Så sikrer man at alle objekterne figurerer på den automatisk genererede signaturforklaring på planen eller snittet. Det kunne også tænkes at man gerne vil generere tilbudslister fra Revit og så vil det være oplagt at have en entreprisekode med fra Excel arket. Så kan man tagge bygningsdelene og på den måde få mulighed for at gruppere objekterne i fagmodellen efter entreprise og klassifikation. Man vil så efterfølgende kunne lave skemaer med mængder for den enkelte entreprise. 33 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 4.5.2 Dalux bygningsdele I forbindelse med casen, blev Dalux omtalt som et styringsværktøj til bygningsobjekterne i BIM modellen. Det er dog tanken at Dalux skal kunne bruges til mange andre funktioner. Da Dalux har rettigheder til at have et add-in i Revit, forstår den de parametre som styrer bygningsdelene i Revit, denne forståelse og sammenhæng kaldes mapping. Tanken med Dalux er dog ikke at Revit skal genererer informationer til Dalux, men derimod omvendt. Dalux fungerer som en form for bygningsdelskatalog med en masse informationer på de enkelte objekter. Det er så sammenhængen med Revit, der skubber informationerne videre til Revit. Som programmet fungerede under casen, så kunne det ikke anvendes til andet end en form for bygningsdelsjournal, hvor man kunne udfylde bygningsdelskort til hvert objekt, som var anvendt i projektet. Da Dalux bygningsdele er et relativt nyt program, så har det nogle spændende funktioner som er under udarbejdelse, dem kommer jeg ind på senere i afsnittet. Der er en del ting man skal være opmærksom på når man benytter sig af Dalux i projekteringen. Den mapping som foregår fra Dalux til bygningsobjekterne i Revit, kan være svær at gennemskue, da man ikke har nogen filterfunktion til at sortere de objekter som er mappet fra dem som ikke er. Der kan derfor være en risiko for at man opretter en ny bygningsdel i Revit og glemmer at mappe den med Dalux, hvis dette sker, kommer objektet ikke med på fx tilbudslisten og du står som projekterende med et stort problem. Det vil sige at det program som skal kvalitetssikre sammenhængen mellem fagmodellen og udbudsmaterialet også skal granskes grundigt inden udbud, da der kan ligge en masse objekter i modellen, som ikke er mappet. Det vil sige at det kræver en masse disciplin og struktur at anvende Dalux. Egenskaber som kan være svære at styre i et kreativt miljø, samt i meget pressede situationer, som fx op til en udsendelse. Det er meningen at man skal kunne lave en tilbudsliste ud fra nogle parametre man opsætter i Dalux, så man fx kan lave tilbudslister sorteret efter entreprise eller bygningsdelstype. Denne funktion er under udarbejdelse og dens egentlige form er endnu ikke afklaret. Men det er klart kan Dalux automatisk genererer en tilbudsliste som man kan opsætte efter entrepriser, så er man nået et godt stykke ift. at efterleve IKTbekendtgørelsens § 9. Hansen siger således om Dalux og mulighederne ved programmet. Man kan sammenkoble bygningsdelsbeskrivelser, definerer entrepriser, arbejdsbeskrivelser og ansvar…pt kan den generere et Excel ark med alle bygningsdele der er i projektet, som hele tiden er opdateret med modellen, hvilket er et super godt kvalitetssikringsværktøj…det næste er så at man kan generere en tilbudsliste (Interview Hansen, 2015) 34 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Dalux er opbygget med en hovedmenu hvor samtlige bygningsdele oprettet i Dalux er grupperet i det klassifikationssystem som er valgt på projektet. Hver bygningsdel har et unikt bygningsdelskort, hvor man manuelt indtaster egenskaberne på bygningsdelen. Her har man også muligheden for at uploade et dokument på en bygningsdel. Det vil sige at man kan lave en bygningsdelsbeskrivelse af den enkelte type bygningsdel og kæde den sammen med objektet i Dalux. På den måde kan man sikre at alle bygningsdelsbeskrivelserne er lavet, samt at de er tilknyttet det rigtige objekt. På den måde siger Hansen at Dalux på sigt kan løse problemet med at skabe sammenhæng mellem fagmodel, beskrivelser og tilbudslister. Det der kan være stærkt ved Dalux er at man ikke behøver at skifte brugerflade for at få processen i hus. (Interview Hansen, 2015) Figur 12 Udklip af bygningsdelskort genereret i Dalux Man kan ikke generere en samlet arbejdsbeskrivelse for fx tømrerarbejdet, men det er meningen at man på sigt ”bare” skal trykke på knappen og så kan den lave beskrivelserne automatisk. Det skal selvfølgelig pointeres at mange af de informationer der er i en bygningsdelsbeskrivelse er projektspecifikke og kan derfor ikke genbruges fra projekt til projekt. Men hele tanken omkring parametrisk software er at det skal kunne forstå hinanden. Og denne måde at lave en sammenhæng mellem bygningsobjekterne i BIM modellen og beskrivelserne foregår stadig på to platforme i Dalux. Der er stadig en stor del manuelt granskningsarbejde i at oprette disse informationer og risikoen for fejl er stadig stor. Hvis Dalux skal fungere som en endelig løsning på sammenhængen mellem BIM 35 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 modeller, beskrivelser og udbudsmateriale, så mangler det at kunne forstå parametrene på den enkelte bygningsdelstype og kunne bruge den information til at skabe en bygningsdelsbeskrivelse. For man kan sagtens ”lave” Dalux i Revit ved hjælp af parametre. På den måde kan man undgå at bruge et eksternt add-in program, som selvfølgelig koster penge til licens, samt implementering på tegnestuen. Hansen siger dog til spørgsmålet om at oprette Dalux i Revit. Det kan man sagtens, så er det bare et spørgsmål om at man skal sikre det er de samme parametre som man har i alle projekter, samt en kontrol af at de ikke ændrer sig uden at blive synkroniseret på alle projekter. (Interview Hansen, 2015) 4.5.3 BIM eller bims, hvordan ser fremtiden ud? Et nyt program til at lave bygningsdelsbeskrivelser hedder Glasshouse og er udarbejdet af 3Dbyggeri. Den væsentligste forskel på Glasshouse og Dalux er at Glasshouse arbejder sammen med parametrene i Revit ift. at generere bygningsdelsbeskrivelser. Det vil sige at Glasshouse forstår at læse de informationer man giver objekterne i Revit fx ville vinduet %QQA.1001 som i modellen har et parameter der hedder KarmOverflade og et parameter value RAL 7021, linke sammen med den manuelt indtastede kategori overflade, som er indtastet i Glasshouse. På den måde kan programmet forstå at ændre beskrivelsen, hvis parameteret bliver ændret i Revit. Det vil sige at man skal have en meget præcis model, hvor man tager stilling til samtlige parametre på hver type objekt. Det kræver derfor at man inden projektering får oprettet en masse families, som kan give det rigtige udtræk til Glasshouse, samt en stor mængde shared parameters som forstår at udnytte de egenskaber der bliver tilføjet i modellen. Men det helt store spørgsmål er, skal man overhovedet lave bygningsdelsbeskrivelser på baggrund af BIM objekter. Her tænkes der primært på de folk som projekterer. Bygningskonstruktører, tekniske tegnere, arkitekter mm. Alle faggrupper har vidt forskellig baggrund og vejen til at alle projekterer på samme måde er lang. Og er det overhovet nødvendigt. For at kunne anvende programmer som Dalux og Glasshouse, kræver det en masse ressourcer at styre det. Ressourcer som er svære at fakturere. Der er mange gode egenskaber i BIM programmerne, som kan kvalitetssikre udbudsmaterialet. Men jo mere avanceret man gør det, des sværere bliver det at se fordelene. Præcisionen i modellen skal ikke kun være på mængderne, men også på hvilke informationer man putter på den enkelte bygningsdel. Og som tingene er nu, så kan man ikke tilføje objekterne tilstrækkelig med information til at kunne lave en korrekt bygningsdelsbeskrivelse. Det vil sige at man alligevel skal ind og manuelt indtaste en masse oplysninger og så er det måske alligevel kun de mest banale ting der kommer automatisk fra Revitobjekterne. Styrken ved disse programmer kan være at de på en overskuelig måde kan give et overblik over hvilke objekter man har i modellen, hvor de skal hen, hvad de skal kunne overholde, samt angive en mængde. Kan man så også bruge dem til at sikre at alle objekter på tilbudslisten er beskrevet, så er man måske kommet så langt man skal med BIM projekteringen. 36 IKT i projekteringen Version 1 5. Jeppe Strand Lemvig 141994 27-03-2015 Konklusion I IKT afsnittet blev det fremhævet hvilke ydelser den projekterende skal være særlig opmærksom på i IKT bekendtgørelserne og ydelsesbeskrivelserne. Særligt funktionen som IKT leder på et projekt kan være enormt tidskrævende, specielt når man er totalrådgiver. IKT lederen skal i praksis efterleve bekendtgørelsens paragraf 3. Dette gøres bla ved at lave kollisions- og konsistenskontroller af bygningsmodellerne, en leverancespecifikation med underrådgiverne, samt prøve at ensarte de projekterendes arbejdsplatforme, så man undgår fejl i udvekslingerne. Da dette arbejde ofte ikke er synligt i udarbejdelsen af et udbudsmateriale, så bliver IKT lederens arbejde ofte ikke afsat nok tid til i timeregnskabet. En væsentlig ting, som har været anvendt i mange år i byggebranchen, er klassifikationssystemer. I bekendtgørelsens paragraf 4, stilles der krav til at digitale byggeobjekter struktureres igennem hele byggeprojektet. Her er der sket rigtig meget, som har stor indflydelse på de projekterendes produktionsapparat. CCS klassifikationens indtog har betydet en markant ændring af niveauet for klassifikationen. Da stukturen er taget ud fra en helt anden industri end byggeriet, er der mange i branchen som ikke forstår behovet for et sådan referencesystem, da man groft sagt prøver at gå fra 2D tegninger til en 3D model og så burde referencesystemet være overflødigt. Et modsvar til CCS er den nye typekode BIM7AA, som er en overbygning på SFB og som er oprettet af branchen selv. Denne typekode på bygningsdelene overholder IKT bekendtgørelsen, hvilket er det egentlige formål. Som casen beretter, kan man selvfølgelig møde bygherre, som vil have et andet klassifikationssystem end BIM7AA og det kan sagtens efterleves med et prefix foran typekoden. Det vigtigste for den projekterende ift. klassifikationer, er at det er gennemskueligt og afklaret ved projektopstart, det vil sige at tegnestuen kører med sin egen typekode og så kan bygherren få sit ønskede klassifikationsnummer på som et prefix før udbud. I de nye IKT bekendtgørelser er det blevet op til bygherren at vurdere om der skal udbydes med mængder. Et mængdeudbud skal sikre bygherren at de bydende entreprenører giver tilbud på samme mængde, det skal så resultere i en skarpere pris. Selve projekteringen med et mængdeudbud er enormt kompliceret og der findes ikke nogen standard for hvordan man skal udtrække mængder fra BIM modellerne, samt sikre at mængderne er korrekte. Præciseringen i at angive de forskellige bygningsdele ift. entrepriser, er en vigtig forudsætning for at strukturere tilbudslisterne. Det er ligeledes vigtigt at man tidligt i projekteringen tager stilling til hvilken type udbud man skal have, samt hvilken entrepriseform der er på sagen. Rådgiveren skal være ekstremt opmærksom på at mængderne er korrekte da de har ansvaret. Det er derfor vigtigt at man får lavet kollisionskontroller af fagmodellen, så man kan fange eventuelle unøjagtigheder eller forglemmelser. 37 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 For at skabe en sammenhæng mellem fagmodeller, beskrivelser og tilbudslister, skal man på nuværende tidspunkt arbejde på mindst to forskellige platforme. Det kan ikke på nuværende tidspunkt lade sig gøre at lave hele udbudsmaterialet i fx Revit. Det er derfor nødvendigt at anvende et program som kan læse objekterne fra fagmodellen og som løbende opdateres. I casen blev Dalux anvendt til at skabe denne sammenhæng. Dalux kan på nuværende tidspunkt ikke lave tilbudslister eller beskrivelser, så den fungerer egentlig bare som en bygningsdelsjournal. Men det er meningen at man skal kunne lave tilbudslister ud fra den. Derfor kunne man på casen have brugt et Excel ark i stedet for. Men spørgsmålet er om ikke det er utopi at tænke man kan generere hele udbudsmaterialet på baggrund af en BIM model, hvor man groft sagt, bare trykker på knappen og så er det hele lavet. Der vil altid være projektspecifikke tiltag, som ikke kan standardiseres, fx bygningsdelsbeskrivelserne, de skal oprettes specifikt til hver sag med meget få afsnit som kan genbruges. Derfor er det relevant at tænke om ikke den projekterende efter at have gransket IKT aftalen, skal lave et afklarende opstartsmøde hvor man klarlægger hele forløbet for projekteringen. Man anvender den typekode eller klassifikation, som er standard på arbejdspladsen, samt en struktur for tilbudsliste med mængdeangivelse. Derefter kan man med fordel modellere modellen, med objekter tilknyttede de forskellige entrepriser og så anvende en bygningsdelsjournal der kan generere tilbudslister, samt skabe et overblik over hvilke objekter i modellen der har tilknyttet en bygningsdelsbeskrivelse. Man kan så ud fra kollisions- og konsistenskontroller kvalitetssikre at man har alle mængder med på tilbudslister, samt alle objekter med i beskrivelserne. Det kan virke tidskrævende, men struktur og minimering af arbejdsplatforme kan skabe det overblik som giver et bedre og mere sammenhængende udbudsmateriale. 38 IKT i projekteringen Version 1 6. Jeppe Strand Lemvig 141994 27-03-2015 Litteraturliste 118, BEK nr, 2013. BEK nr 118 af 06/02/2013. [Online] Available at: https://www.retsinformation.dk/Forms/R0710.aspx?id=145421 [Senest hentet eller vist den Oktober 2013]. AB92, 1992. Almindelige Betingelser for arbejder og leverancer i bygge- og anlægsvirksomhed. s.l.:Klima-, Energi- og Bygningsministerie. BIM7AA, u.d. bim7aa.dk. [Online] Available at: http://bim7aa.dk/BIM7AA_Typekodning.html [Senest hentet eller vist den 18 Marts 2015]. Bygningsstyrelsen, 2013. Vejledning til bekendtgørelse om anvendelse af informations- og kommunikationsteknologi i offentligt byggeri, Valby: Bygningsstyrelsen. COWI, 2009. Digital forvaltning af bygninger fra vugge til grav, Kongens Lyngby: Udarbejdet for Erhvervs- og Byggestyrelsen. Cuneco, u.d. [Online] Available at: http://cunecoclassification.dk/default.asp [Senest hentet eller vist den 18 Marts 2015]. Forprojekt, I., 2015. Forprojekt BIPS IKT aftale, s.l.: BIPS. Gentofte, K., 2011. Gentofte henter gevinster ved IKT. pp. 21-23. Hansen, K., 2015. IKT i projekteringen [Interview] (12 Februar 2015). Hyttel, P., 2015. IKT [Interview] (13 Februar 2015). informationsniveauer, C., u.d. Bips.dk. [Online] Available at: http://bips.dk/files/bips.dk/article_files/ccs_informationsniveauer_hoeringsudgave_201401 24_0.pdf [Senest hentet eller vist den 26 Februar 2015]. Søefeldt, M. B., 2013. Udbud med mængder og sammenhæng i projektmaterialet, s.l.: Alectia. Ydelsesspecifikation, I., 2013. s.l.:BIPS. 39 IKT i projekteringen Version 1 7. Jeppe Strand Lemvig 141994 27-03-2015 Bilagsliste Bilag 1: Udklip af Cunecos informationsniveauer Bilag 2: Udklip af nummereringsnøglen fra casen Bilag 3: Udklip af den IKT-tekniske afleveringsspecifikation i casen Bilag 4: Interview med Peter Hyttel Bilag 5: Interview med Karsten Hansen Bilag 6: Nyhedsbrev fra Cuneco omhandlende opmålingsregler 40 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Bilag 1 Udklip af Cunecos informationsniveauer (informationsniveauer, u.d.) 41 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Bilag 2 Udklip af nummereringsnøglen fra casen Hovedprojekt Nummereringsnøgle (klassifikation) til TBL, beskrivelser og 3D model 2015 Maj Indledning OBS! I bilag 13 IKT ydelsesbeskrivelse er angivet DBK. Dette er ændret til SfB jf. mailkorrespondance. Der stilles krav om: • Klassifikation af byggeobjekter i 3D modellen • Klassifikation af udbuds- og tilbudsmateriales informationer • Der sikres overensstemmelse mellem bygningsmodellen, bygningsdelsbeskrivelser samt posterne og mængderne angivet i tilbudslisten På de følgende sider redegøres der for praktisk anvendelse af SfB i projektmaterialet og nummereringsnøglen for SfB systemet fag for fag. 42 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 2. Praktisk anvendelse af SfB i projektmateriale Eksempel på SfB-klassifikation for konstruktioner Arbejdsbeskrivelse: Bygningsdelsbeskrivelse: Vigtigt at SfB klassifikationen også fremgår under omfang, og skaber sammenhængen til de specifikke bygningsdele! 43 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Tilbudsliste: 3D-model Når sammenhængen i projektmaterialet er som ovenstående eksempel på konstruktions opfylder vi bygherrens krav til sammenhæng i projektmaterialet via SfB. 44 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 3. SfB nummereringsnøgle SfB klassifikationen består af følgende: SfB syntax SfB Hovedgruppe (XX) SfB Løbenummer Undergruppe (Fortløbende ifølge tabel) X.X .XXX For SfB Hovedgruppe og forslag til undergruppe, se de efterfølgende sider. SfB undergruppe bestemmes fagspecifikt. Løbenummer bruges i de enkelte bygningsdelsbeskrivelser i afsnit 4.2 Omfang. For fagspecifikke løbenumre se nedenfor. Løbenummer Arkitekt Anlæg Konstruktioner VVS-installationer Ventilation El-installationer SfB Tabel (1.) (10) 001-399 401-499 501-999 001-999 001-999 001-999 Bygningsbasis Bygningsbasis, terræn (10)1 Forberedt grund. (10)2 Byggegrube incl. afstivning (10)3 Spunsvægge (10)4 Jordberegning (10)5 Ledninger i jord … … 45 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Bilag 3 Udklip af den IKT-tekniske afleveringsspecifikation i casen 46 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Bilag 4 I bilag 4 er interviewet med Hyttel oplistet med de uddrag fra lydfilen som er anvendt i specialet. Hvert citat har angivet den præcise placering i lydfilen som overskrift. Præsentation af den interviewede: Peter Hyttel IKT ansvarlig ved CF Møller, samt medlem af PAR og FRIs task force under Dansk Industri. Lydfil 2:15min Hos BIPS har man haft så meget fokus på nogle teoretiske tanker om den samlede værdikæde og BIMs værdi for hele byggekæden, så man har spredt sin produktportefølje over hvad man egentlig har skullet levere, CAD relaterede meget operationelle ting, som hvad lagstruktur bruger man til at omhandle dokumentstyring og CAD anvendelse, udbud, aflevering, alle discipliner har man ligesom prøvet at pakke ind i et stort monster af informationsteoretisk baserede ting om hvad der kunne være godt. Lydfil 4:05min De (BIPS) har sådan set forfejlet deres egne brancheorganisationers arbejde i og med at vores opgave består i at inddække vores egne ydelser, så vi ikke kommer ud i de situationer som vi ser der opstår nu på baggrund af BIPS IKT-specifikationer, som sådan set er blevet de dokumenter som bygherren råt for usødet smider med ethvert projekt og som giver voldsomme diskussioner i ethvert projekt for det går ind og konflikter med vores produktionsmetoder. Lydfil 10:00min den er så også meget til debat, da den rapport der er lavet bliver stemt ned i task forcen, det vil vi ikke, vi vil ikke arbejde med forskellige niveauer i de her ydelser. Det handler om at komme væk fra at det er BIPS der definerer branchens ydelser, til det er branchen selv. Lydfil 18:00min Hyttel svarer til spørgsmålet om hvorvidt bygherren kan anvende BIM modellerne i driftsfasen. Nej, det gør de ikke og det er præcis problematikken, hele tankegangen er forfejlet, fordi projekteringssoftwaren kan ikke bruges til sådan noget. Det er ikke det der er meningen med softwaren. Lydfil 21:30min Hele den her tankegang om at man rent klassifikationsmæssigt, som man havde det i DBK og som man nu viderefører i CCS, hvor man laver referencestrukturer, hvor en dør er en del af et 47 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 vægsystem, hele den tankegang er overført fra mekanikken, hvor en transistor er en del af et elektrisk kredsløb. I modelprojektering og i det arbejde rådgiveren sidder og laver, er den type af ting ikke nødvendig. Lydfil 46:10min Hyttel formulerer IKT-lederens rolle således. IKT ledelsen er en ting som er blevet flettet ned over rådgiveren, hvor de både får ansvaret for at operationalisere alle de her tanker og hvis man så igangsætter en udbudsproces med mængder, så gælder det, så har rådgiveren ansvaret for at det kan forstås og tolkes korrekt over forskellige projekteringsplatforme. Lydfil 48:28min Vi får kun risikoen. 48 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Bilag 5 I bilag 5 er interviewet med Hansen oplistet med de uddrag fra lydfilen som er anvendt i specialet. Hvert citat har angivet den præcise placering i lydfilen som overskrift. Præsentation af den interviewede: Karsten Hansen BIM manager hos CF Møller, samt medlem af BIM7AA styregruppen. Lydfil 13:10min Noget der kan være med til at skabe fejl, er hvis rådgiverne ikke taler samme sprog, hvis de arbejder på forskellige platforme. Lydfil 19:25min Man kan sammenkoble bygningsdelsbeskrivelser, definerer entrepriser, arbejdsbeskrivelser og ansvar…pt kan den generere et Excel ark med alle bygningsdele der er i projektet, som hele tiden er opdateret med modellen, hvilket er et super godt kvalitetssikringsværktøj…det næste er så at man kan generere en tilbudsliste. Lydfil 25:05min Det der kan være stærkt ved Dalux er at man ikke behøver at skifte brugerflade for at få processen i hus. Lydfil 25:10min Det kan man sagtens, så er det bare et spørgsmål om at man skal sikre det er de samme parametre som man har i alle projekter, samt en kontrol af at de ikke ændrer sig uden at blive synkroniseret på alle projekter. 49 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Bilag 6 Bilag 6 er nyhedsbrevet fra Cuneco omhandlende opmålingsregler Nyhed 2015-03-06 A SSP 6-14041 Udgivelse af CCS Opmålingsregler Efter lang tids forberedelse er CCS Opmålingsregler klar til at blive udsendt i løbet af marts måned 2015. CCS Opmålingsregler var et af indsatsområderne i cuneco og undervejs i projektet blev der arbejdet indenfor områderne måleregler, data til tilbudsgivning og standard for tilbudslister. Kort fortalt dækker ovenstående tre områder: • • • Måleregler: Regler for hvordan mål gøres op. Dette har en tæt relation til de udtræk af mængder, der kan laves fra bygningsmodelleringssystemer. Data til tilbudsgivning: Retningslinjer for hvilke informationer om fx bygningsdele, der skal videregives til de bydende i forbindelse med et udbud. Standard for tilbudslister: Udarbejdelse af et fælles standardiseret format for en tilbudsliste ledsaget af et digitalt format, der kan implementeres i fx kalkulationssystemer. Resultaterne af projekterne indenfor disse tre områder blev sendt i høring i februar 2014 og høringsforløbet blev afsluttet i sommeren 2014. Oprindelig var det tanken, at udsende CCS måleregler som en selvstændig publikation, men i forbindelse med høringen blev det klart, at branchen efterlyste et værktøj til at specificere omfanget af ydelser – og ikke kun mål – til anvendelse i udbudssituationen. 50 IKT i projekteringen Version 1 Jeppe Strand Lemvig 141994 27-03-2015 Dette har cuneco arbejdet videre med, hvilket har betydet, at man har taget de ellers færdige måleregler, der blev afleveret fra projektgruppen, og indarbejdet dette i et kompleks, der indeholder regler for opgørelse af både ydelser og mål og som samlet betegnes CCS Opmålingsregler. CCS Opmålingsregler kommer til at omfatte i alt 6 elementer, som illustreret i figuren. • • • CCS Prissætningsregler, Basis indeholder generelle principper for hvordan ydelser prissættes i henhold til CCS Opmålingsregler. Dette er grundlæggende lærebogsstof, der er en forudsætning for anvendelsen af systemet. CCS Prissætningsregler, Bygningsdelsoversigt er en liste, der identificerer de CCS Prissætningsregler, Bygningsdele, der er gældende på et givet tidspunkt. Denne liste vil løbende blive opdateret efterhånden som der kommer yderlige CCS Prissætningsregler, Bygningsdele til. CCS Prissætningsregler, Bygningsdele er skemaer, der indeholder detaljerede specifikationer for, hvordan de enkelte bygningsdele prissættes. Disse skemaer vil 51 IKT i projekteringen Version 1 • • • Jeppe Strand Lemvig 141994 27-03-2015 bl.a. angive hvilke CCS Måleregler, Bygningsdele, der skal anvendes ved opgørelse af bygningsdelens mængder. CCS Måleregler, Basis indeholder i lighed med basis for prissætningsregler en redegørelse for de grundlæggende principper for anvendelse af CCS måleregler. CCS Måleregler, Bygningsdelsoversigt er en liste, der identificerer de CCS Målesætningsregler, Bygningsdele, der er gældende på et givet tidspunkt. Denne liste vil løbende blive opdateret efterhånden som der kommer yderlige CCS Måleregler, Bygningsdele til. CCS Måleregler, Bygningsdele indeholder måleregler for de enkelte bygningsdele. Dette omfatter bl.a. en redegørelse for hvilke egenskaber for de enkelte bygningsdele, der anvendes ved opgørelse af bygningsdelens mængde. Disse egenskaber koordineres med de mængder, der kan udtrækkes fra gængse bygningsmodelleringssystemer. Det vil typisk være i bygningsdelsbeskrivelserne man angiver, hvilke CCS Prissætningsregler, der gøres gældende. I den forbindelse kan man både referer til de prissætningsregler, der udgives af bips og til projektspecifikke prissætningsregler, der indeholder projektafhængige justeringer. Den første udgave af CCS Opmålingsregler vil blive frigivet den 27. marts 2015. Denne udgave vil indeholde CCS Prissætningsregler, Basis og CCS Måleregler, Basis samt bygningsdelsoversigter for både prissætningsregler og måleregler. Derudover vil udgaven indeholde CCS Prissætningsregler og CCS Måleregler for en række bygningsdele. CCS Opmålingsregler vil løbende blive udbygget efterhånden som der bliver udarbejdet prissætningsregler og måleregler for yderligere bygningsdele. 52
© Copyright 2024