Snusfornuftig IKT-aftale

Der er ikke én IKT-aftale, der passer alle projekter og rådgiver-teams. Ofte ser man kravene er så høje, at rådgiverne undervejs i processen ser bort fra flere af kravene, på trods af, at de ofte selv har været med til at udforme IKT-aftalen.

Hvilket informationsniveau? Hvilket klassifikationssystem? Hvilket afleveringsformat? Hvem laver kollisionskontrol? Hvor ofte udveksles modeller? Hvordan navngives filer og lag? Hvilket projektweb? Hvilken version af Revit? Hvordan afleveres driftdata fra entreprenøren? Udbydes der med mængder?

Regel nummer ét må være, at man spørger bygherre om, hvordan driftsdata skal afleveres. Det vil formentlig sætte krav til klassifikation, både som system (f.eks. CCS, DBK, SfB, Omniclass eller andre), men også hvordan f.eks. en række installationer skal samles til ét objekt i BIM-modellen, der klassificeres under ét, for at lette driften.

Bygherre og driftsherre vil helt sikkert se en fordel i, at aflevering og udveksling af BIM sker med åbne fil-formater, der sikrer at man kan åbne projektet mange år frem i tiden uanset hvilken software-platform man ønsker at benytte. Men de åbne formater tager højde for, at man ikke kender alle rådgivere, entreprenører eller detail-projekterende systemleverandører. Vil bygherre eller bygherrerådgiver følge med i fremdriften undervejs, er det også lettest, hvis filerne lægges ud i et format der kan åbnes af simple “viewers”. Kort sagt IFC-filer bør være et krav fra bygherre – i hvert fald hvis man spørger Bygherreforeningen!

Cairns Complex

Nogle definerer præcist i CAD/BIM-aftalen, hvordan bygningsdelene skal opbygges i modellen, og – endnu værre – definerer hvilken software alle rådgiverne skal benytte. Men der er forskel på, hvilke behov man har som landskabsarkitekt, bygningsarkitekt, konstruktionsingeniør, VVS-ingeniør, entreprenør og driftsherre. Der er mange arkitekter, der ønsker fleksibiliteten af ARCHICAD, landskabsarkitekten benytter måske Bentleys Microstation, konstruktionsingeniørerne har ofte en forkærlighed for Tekla, installationsingeniørerne kan måske bedst lide MagiCAD, som enten bygger oven på AutoCAD eller Revit, entrepenøren benyttter måske SIGMA eller Vico, mens driftsherre måske vil benytte DaluxFM eller ArchiFM. – Men IFC-formatet kan importeres og eksporteres af dem alle.

Men der er ikke kun softwareplatformen, som adskiller fag-rådgiverne. Arkitekten vil ofte gerne arbejde med væggen som ét objekt fra yderst til inderst og med dæk som ét objekt, måske fra underkant nedhængt loft til overkant færdigt gulv. Men selv om man arbejder med ét objekt, kan det sagtens være sammensat af forskellige materialer, så man senere kan eksportere betondelen til konstruktionsingeniøren eller lade installationer løbe over nedhængt loft uden at kollidere med arkitektens omsluttende objekt. Konstruktionsingeniøren har måske behov for at modellere dæk som præfabrikerede elementer og ikke som ét stort dæk.

Artlantis Render 02

Det går helt galt, når man strenger IKT-aftalen så hårdt op, at hver rådgiver KUN må have de bygningsdele i sin model, som vedkommende er ansvarlig for. Det vil sige, at arkitekten måske modellerer teglfacade, isolering og gips, mens ingeniøren modellerer betondelen i midten. Men da arkitekten er ansvarlig for viduerne, som sidder fast i beton-delen, modellerer de så en væg af “luft”, som vinduerne sættes fast i. Det er noget som koster tid under projekteringen! – Men der er ingen grund til at de forskellige rådgivere strukturerer og opdeler deres modeller ens, men alene at man kvalitetssikrer, at ingeniørens dækelementer og beton-delen af arkitektens dæk er samme sted, ligesom man checker om arkitekt og ingeniør har vindueshullerne samme sted i modellen, samt at der ikke er kollisioner med installationerne. Det gør det meget mere fleksibelt, at hver rådgiver kan modellere som de selv synes bedst, og at man kontinuerligt alene kvalitetssikrer at modellerne passer sammen.

Dér hvor man skal holde tungen lige i munden, er i at alle benytter samme nulpunkt i modellen og samme etagestruktur. Det betyder, at modellerne “falder” ind samme sted, når man lægger modellerne sammen. Det kan løses med besværlige “Shared Coordinate”-filer, men meget lettere er det, bare at skrive et lokalt nul-punkt ind i IKT-aftalen, sammen med den “vertikale sektionering”, der beskriver etage-koterne. Sidstnævnte skal i mine øjne referere til overkant færdigt gulv (for at sikre tilgængelighed), men der mange argumenter for at sektionere i overkant beton-konstruktion.

For at samarbejdet glider bedst muligt, er det vigtigt at definere mindst muligt konkret om modellering i CAD/BIM-aftalen, men i stedet beskrive den process, som medfører en høj kvalitet af samarbejde. Samtidig skal man huske, at CAD/BIM-aftalen bør redigeres løbende i takt med, at behov og viden udvikles. Vi anbefaler altid, at man laver en workshop, når de første to rådgivere er fundet. I workshoppen sikrer man at rådgiverne let kan eksportere og importere IFC-filerne og at de benytter samme nul-punkt og sektionering, så modellerne automatisk passer sammen. Fra starten aftales det at man i et fast interval udveksler både IFC-filer og i original-format fra det BIM-program man benytter. Én af rådgiverne, bygherrerådgiver eller en trediepart sættes til at kvalitetssikre fag-modellerne – igen med et fast interval – og ved at opstarte denne process meget tidligt, får man fjernet de mange tusinde “dumme”-fejl, som projetkerne altid indeholder.

Skærmbillede 2015-02-08 kl. 08.57.22

Kvalitetssikringen bør altid foregå på baggrund af IFC-filerne, for at sikre at det er filerne i afleverings- og udvekslingsformatet, som er i orden. Man kan enten benytte NavisWorks eller Solibri Model Checker til kvalitetssikringen, men sidstnævnte kan checke for meget mere, herunder f.eks. klassifikation, tilgængelighed, rumnumre, tollerancer, flugtveje, trapper og rampers lovlighed, samt meget, meget mere. Bygherre bør sætte krav til, at fejlrapporterne bliver lagt ud på projektweb, men også at de deles i et webinterface, hvor man kan administrere fejlene og synkronisere dem til de forskellige BIM-programmer hos rådgiverne. BDF-filer er et eksempel på en sådan løsning, men BIMcollab er for tiden det bedste værktøj på markedet til administrering af fejl.

Der er nogle som mener, at det smart at modellere og beskrive bygningsdelene i detaljer i f.eks. Revit, ARCHICAD, Tekla og MagiCAD, men det er et stort arbejde og medfører tunge og langsomme modeller. Det er langt smartere, f.eks. at koble beskrivelser i en web-database som Glasshouse eller BIM Shark, at klassificere med CCS i Project Spine og at lave beslåning af døre i BIMeye. Så holder man BIM-modellerne rene og simple, men får alle informationer i et web-interface, som også kan benyttes af medarbejdere, der ellers ikke har BIM-kompetancer. Data kan ofte lægges tilbage i modellerne eller direkte til bygherres FM-system.

maxresdefault

IFC-filerne er rigtig gode til at videre give projektet til entreprenøren, til brug for kalkulation, planlægning, visualisering af byggeprocessen og meget mere. Entreprenøren kan berige modellerne med driftsdata, helst direkte i det valgte FM-system. Det er faktisk vores erfaring, at det er bedre at lægge driftsdata ind i et forkert FM-system (så længe at det er BIM-baseret), end at aflevere i Excell, JPEG eller PDF. Årsagen er, at de fleste FM-systemer relativt billigt kan koble deres databaser, så informationerne automatisk kan overføres.

For at opsummere, synes jeg, at man kommer længere med at definere nogle få snusfornuftige krav i IKT-aftalen og altid sørge for at tilrette den i forhold til bygherres behov, samt rådgiverteamet og projektets særlige udfordringer. Processen er vigtig og det giver højere kvalitet, hvis parterne fortæller hvad de skal bruge, til hvad og hvornår, samt hvordan og hvor ofte bygherre eller bygherre rådgiver checker rådgivernes materiale og fejlrapporter. Er bygherre ikke tilfreds, sættes mængden af stikprøver op. – Det giver meget bedre samarbejde, end en IKT-aftale med høje krav, som rådgiverne ikke alligevel ikke overholder.

  • BIM – Geometri eller data

    BIM betyder ”Bygnings Informations Modeller”, hvilket jeg forstår som 3D-modeller beriget med informationer. Nogle benytter i stedet oversættelsen ”Bygnings Informations Modellering”, hvilket understreger, at værdien ligger i processen og ikke i selve output. Måske bør ordet ”Bygning” endda erstattes med ”Bygge”, så man i større omfang også inddrager landskab, anlæg, infrastruktur og (by-)planlægning. Når man starter… Se indlæg

  • ARCHICAD 20 – Et frisk syn på BIM…

    Den nye version af ARCHICAD er landet, med masser af nye funktioner og muligheder. Der er som sædvanligt noget for enhver at glæde sig til, så lad os dykke direkte ned i det. Hele brugerfladen er blevet ryddet op, og væk er æstetikken fra Windows 95! Mere end 1.000 nye ikoner er designet som vektor-grafik,… Se indlæg

  • What is the point?!?

    Digitalisering og BIM-baseret opmålinger bliver for tiden udført i stor stil på kæmpe projekter. BIM Equity leverer forskellige digitaliserings-løsninger, både baseret på 2D-tegninger og registreringer på stedet. Når 2D-tegninger skal omdannes til BIM, benytter vi vores filippinske partner, tegnestuen Aidea, der har mange års erfaringer med BIM. De skiftede fra AutoCAD og Sketchup i 2005 og… Se indlæg

  • BIMeye styrer informationerne i BIM…

    En af de store tendenser for BIM er, at man i stadig højere grad fokuserer på informationer og data. 3D-modellen og tegninger er stadig en stor del af BIM, men værdien af data er større end de fleste indser, især jo længere ind i byggeprocessen man kommer. En anden tendens er små web-databaser overtager arbejdsgange,… Se indlæg

  • Young Architect

    Som nyuddannet arkitekt er man mester i rum og formgivning, men måske ikke i ligeså høj grad i Bygnings Informations Modellering (BIM), som er den metode, de større tegnestuer benytter til skabe deres projekter. Med BIM slår man 2D-tegninger og 3D-modellering sammen til ét workflow og én fil. Samtidig kan man udtrække mængder og tilføje… Se indlæg

Kommentér

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *