DIGITALE SAMARBEJDSPROBLEMER - MELLEM TO ARKITEKTVIRKSOMHEDER

Transkript

1 - MELLEM TO ARKITEKTVIRKSOMHEDER KRISTENSEN SPECIALE 7. BK UCN AALBORG SOFIENDALSVEJ 60, 9200 AALBORG

2 Titelblad Titel Forfatter: Faglig vejleder Digitale samarbejdsproblemer mellem to arkitektvirksomheder Anders Norup Kristensen Galstersgade 13 st. tv. 9400, Nørresundby Tlf: Mail: Henriette Knak Afleveringsdato Institution Rapport type: University College Nordjylland UCN Sofiendalsvej Aalborg 7. Semester speciale på bygningskonstruktøruddannelsen Antal sider i hovedtekst: Antal sider i alt Dato: Underskrift:

3 Forord Inspirationen til dette speciale er samlet gennem uddannelsesforløbet på bygningskonstruktøruddannelsen på UCN Aalborg. Samt det netop overstået praktikforløb hos Friis & Moltke A/S. Derudover har forfatter af rapporten, igennem de første tre specialer, indsamlet sig en større interesse og erfaring inden for anvendelsen af digitale værktøjer i byggebranchen. Mens specialet på 3.semester blev brugt på at samle sig en grundviden og forståelse for begrebet BIM. Blev både specialet på 4. og 5. semester brugt på at få en mere specifik viden inden for et dybdegående emne med fokus på BIM. Det var henholdsvis, dokumenthåndtering med henblik på problemer med en standardiseret deling af filer, både internt og eksternt på tegnestuen (4. semester). Og udviklingen af BIM i Skandinavien, med særlig fokus på Finlands kontra Danmarks udvikling (5. Semester). Problemstillingen inden for digitale samarbejdsproblemer er hovedsageligt blevet samlet gennem et 20 ugers praktikforløb hos Friis & Moltke. I et af de deltagende projekter, Herlev Sygehus, blev der observeret et stigende problem med samarbejdet mellem en anden arkitektvirksomhed, Henning Larsen A/S. Projektet havde en størrelse, der gjorde at man indgik i et konsortium, hvori der befandt sig i alt to arkitektvirksomheder og tre ingeniørvirksomheder. Dog opstod størstedelen af problematikkerne blandt arkitektvirksomhederne. Da de to tegnestuer var geografisk adskilt, foregik størstedelen af kommunikationen mellem tegnestuerne over videokonference, telefonisk kontakt samt skriftlige beskeder. Det resulterede i hårudtrækkende frustrationer, men man fornemmede alligevel at problematikkerne, der lå til grunde her, lå dybere i samarbejdet. Og også omhandlede de aftalegrundlag der var blevet fastlagt i starten af projektet. Jeg vil gerne takke min faglige vejleder Henriette Knak for vejledning og gode råd under specialeforløbet. Derudover vil jeg gerne takke: Kenneth Højbjerg, BIM-Manager og afdelingsleder, Bjerg Arkitektur Henrik Hansen, BIM-Manager og projektleder, Friis & Moltke Ove Kath, Sagsarkitekt, Friis & Moltke

4 Indhold 1.0 Indledning Problemstilling Problemformulering Afgrænsning Metode Ideprocessen Prøve-fejl-metoden/falsifikationsmetoden Den Kvalitative metode Læsevejledning Målgruppe Hoveddel Digitale aftalegrundlag og standarder Hvad er IKT? IKT-Bekendtgørelserne og anvendelsen i den danske byggebranche Digitale IKT aftalegrundlag Relevante standarder og anvisninger Korrekte krav til anvendelsen af IKT Case Samarbejdet mellem Friis & Moltke og Henning Larsen Niveauforskelle i byggebranchen i anvendelsen af IKT Komplet standardisering af det digitale samarbejde Konklusion Perspektivering Kildeliste Litteratur Hjemmesider Interviews Bilag BEK 118 Anvendelse af informations- og kommunikationsteknologi i offentligt byggeri BEK 119 Anvendelse af informations- og kommunikationsteknologi i Alment byggeri Interview med Kenneth Højbjerg Interview med Henrik Hansen... 43

5

6 1.0 INDLEDNING 1.0 Indledning Dette speciale vedrører de problemstillinger der kan opstå i et digitalt samarbejde, mellem to arkitektvirksomheder, og hvordan de muligt løses ved at man fra start har indtænkt nogle ordentlig og klare aftalegrundlag når det vedrører anvendelsen af IKT. Det er bl.a. rådgiveraftalen, ydelsesbeskrivelsen med særlig fokus på pkt. 2.2 og IKT-specifikationerne. Derudover vil der i specialet blive taget stilling til hvordan brugen foregår i praksis og om man forstår at udnytte kravene som et værktøj til en bedre byggesag. Eller om man fejler og det i stedet er en hæmsko i byggeprocessen. Det vil ende ud i en diskussion, hvor der vil blive debatteret om vi generelt her herhjemme i Danmark overhovedet er på et niveau, hvor vi kan stille høje krav til os selv om anvendelsen af IKT. Eller om vi i givet fald, kan anvende det i et samarbejde med en eller op til flere aktører af samme fag. Og om det vil være muligt at standardisere en hel branche, som alle kan blive enige om at anvende. Det vil til sidst ende ud i et løsningforslag på problematikken og en endegyldig konklusion af specialet. 1.1 Problemstilling I et fungerende samarbejde er det ganske normalt, at de indblandede aktører, af samme fag, har hver sine kompetencefelter. Disse kompetencer stammer som regel fra medarbejdere, erfaringer der er samlet i tidligere projekter samt de forskellige interesseområder hver tegnestue besidder. Med forskellige kompetencer vil det være muligt at kunne få flere detaljeret elementer med i sit projekt, og på den måde opnå et mere tilfredsstillende produkt. Men det er svært at blive klog på, om disse facetter overhovedet blev indtænkt, da et samarbejde mellem Friis & Moltke og Henning Larsen blev opstartet i På flere af landets større tegnestuer ofres der store ressourcer på, at implementere og gøre brug af BIM. Men medfører det samtidigt at der opstår så store adspredelser mellem tegnestuerne, at hvad der skal ses som standardiserende arbejdsværktøjer, ikke kan anvendes i et samarbejde mellem to aktører i samme faggruppe. Fordi springet i det faglige niveau bliver for stort? Eller handler det om, at vi her i landet ikke besidder den rigtige viden til at anvende standarderne og færdiggøre et fyldestgørende aftalegrundlag sammen med andre, som de var tiltænkt? Udover at man kan føle sig presset fra sine konkurrenter og fagfolk til, at implementere BIM. Har man fra statens side, siden 2007 [(W1) retsinformation.dk], gjort krav om brugen på større statslige og statslige støttede byggerier. Disse krav er henover årene, ved hjælp af nye bekendtgørelser, blevet mere defineret og forsigtigt strammet. Men hvilke effekt har det medført? Sætter man sig ind i de nye tiltag, eller fører det til at folk i desperation skriger efter at implementere og gøre brug af BIMs muligheder, uden de overhovedet har en forståelse for, hvad de vil have og hvad de overhovedet har brug for? Der er flere problematikker der kan gøre sig gældende i et samarbejde. Men fælles for dem alle er, at de muligvis kunne afhjælpes ved, at man fra start har udarbejdet et fælles grundlag. Det skal være med til at fastsætte, nogle fælles rammer for det videre samarbejde. Men formår man at udnytte det potentiale, der ligger i de aftaleformularer og standarder der i dag gør sig gældende? Eller er det mere dokumenter der fra en juridisk side, skal være udfyldt for at man i situationer med uoverensstemmelser kan finde den ansvarlige, som i sidste ende får økonomiske konsekvenser? Med anvendelse af digital teknologi, er det muligt at løfte kvaliteten og effektiviserer de fleste områder i byggeprocessen. Det er lige fra projekteringen og designet, over udførelsen til den fremtidige 1 S i d e

7 drift af byggeriet. Hvilket er til gavn for hovedparten af de involverede i en byggesag og de efterfølgende personer, der har ansvaret for driften og vedligeholdelsen. Kort sagt er IKT i byggeprocessen i en kraftig udvikling, hvor man høster nye erfaringer og viden, både inden for IKT, men også det overordnet brug af BIM. Men for det kan udnyttes, er det nødvendigt at man fra start har udarbejdet IKT-specifikationer der definerer udgangspunktet for brugen af IKT. Men bliver det overhovedet ordentligt indtænkt? Disse IKT-specifikationer skal være med til at definere parternes roller og ydelser, men hvis man ikke formår at få udfyldt nogle fyldestgørende specifikationer, kan det resultere i man står med tvivlspørgsmål senere i byggeprocessen. Men hvilke konsekvenser kan det have og i så fald hvordan løser man problemet? 1.2 Problemformulering Overordnet: Hvordan forbygges problematikkerne i opstarten af et digitalt samarbejde mellem to danske arkitektvirksomheder? Underordnet: Hvilke digitale aftalegrundlag og standarder gør sig gældende i et samarbejde med en anden arkitektvirksomhed? Forstår man til dags dato at anvende og afsætte, fyldestgørende og korrekte krav til anvendelse af IKT, og hvad er konsekvenserne af det? Er det generelle niveau for forståelsen og anvendelsen af IKT i byggebranchen for lav til at man kan indgå i et samarbejde? Vil en fuldstændig standardisering hjælpe på et digitalt samarbejde, og vil den være mulig? 1.3 Afgrænsning På grund af emnets mulige størrelse og et ønske om et gennemarbejdet speciale. Ses det nødvendigt at lave en afgrænsning for, at kunne komme dybere ned i de enkelte områder, der ønskes at blive belyst iht. det valgte emne. Denne rapport er blevet afgrænset til at fokusere på den projekterende, med henblik på samarbejdet mellem to danske rådgivende arkitektvirksomheder. Det sker på baggrund af, at det er på dette område der er observeret udfordringer og problemstillinger mellem to aktører fra samme fag i brugen af IKT/BIM i opstarten af en byggesag. Som beskrevet, vil der blive taget udgangspunkt i hvilke elementer der er nødvendige at indtænke i opstartsfasen, med henblik på IKT. Det gælder bl.a. oprettelse af et fyldestgørende aftalegrundlag, hvilke standardiseringer der burde være medvirkende til at den digitale kommunikation kan forekomme tilfredsstillende, og være med til at forebygge samt skabe et tæt samarbejde mellem to tegnestuer. Derfor vil der ikke blive belyst hvilke krav aftalegrundlagene stiller til den udførende. Men udelukkende, hvad der har interesse for samarbejdet mellem to arkitekter. Der vil derudover blive set på hvordan situationen ser ud blandt de danske tegnestuer i dag, og om brugen af IKT i byggeprocessen er medskabende til et mere velfungerende arbejde. Eller i givet fald har den modsatte effekt. Derudover vil der blive lagt fokus på offentlige og almene byggesager frem for det private, da det er her der er stillet krav til anvendelse af IKT. Og af samme grund er det her den største problemkonflikt opstår. I forhold til IKT-specifikationerne og publikationer, vil der primært blive fokuseret på de tilgængelige fra bips regi. 2 S i d e

8 1.0 INDLEDNING 1.4 Metode I nedenstående metodeafsnit vil der bliver redegjort for, den generelle proces i at nå frem til problemformuleringen, og vejen fra problemformuleringen til problemløsningen. Samt en redegørelse for grundlaget og metoden til at indsamle den nødvendige data, herunder interviews og kriterier, som har afgørende betydning for specialets indhold til at nå et tilfredsstillende niveau. Specialets overordnede formål er at komme med et løsningsforslag til hovedspørgsmålet; Hvordan forbygges problematikkerne i opstarten af et digitalt samarbejde mellem to danske arkitektvirksomheder? Ideprocessen Formålet med specialet er at finde frem til en problemløsning, til det ovennævnte hovedspørgsmål. Dette er en længerevarende proces der indebærer flere forskellige led. Fra start har man observeret en større problemstilling der har skabt en undring. Denne problemstilling har været selve kilden til at finde frem til den efterfølgende problemformulering, igennem en såkaldt Ideproces [(L1) Back m.fl, 2010:14, 20]. Den skal i sidste ende resultere i en mulig løsning på problemformuleringen. Ideprocessen er delt op i tre trin: 1. Overordnet emne 2. Hovedspørgsmål 3. Underspørgsmål Observering af problemstilling Ideproces For at få belyst alle tre trin, vil der ud over den i forvejen indhentet viden og erfaring fra semestre og praktik. Foreligge en Informationssøgning vigtig informationssøgning og Problemløsning brainstorm der har til hensigt, at finde frem til den endelige problemformulering, der er ret- Fig Fra observering af problemstilling til problemløsningen [(L1) lbid.] ningsgivende for specialet. Dvs. at problemformuleringen skal fungere som rettesnor for i hvilken retning man arbejder imod. Hele denne proces skal være med til at skabe en mere gennemarbejdet problemformulering og afgrænsning, og ligeledes føre til at selve specialet er mere bearbejdet iht. til det valgte emne Se fig Til brainstormingen er der blevet anvendt mindmapping for at danne sig et godt og organiseret overblik over i hvilken retning man kunne drage specialet. Det har været med til at gennemtænke en god problemformulering. Mindmappingen er ligeledes blevet brugt til at sikre og holde styr på processen, så man på bedst måde har kunne organisere sit arbejde og hvilke elementer man skulle prioritere frem for andet. Mindmappingen er hovedsageligt blevet brugt i de indledende faser, til bedre at kunne Emne Hovedspørgsmål Underspørgsmål 3 S i d e

9 bearbejde og prioritere, først og fremmest sit emne og problemformulering, men ligeledes den samlede proces i specialet. På den måde er det blevet sikret man ikke har glemt elementer man har set relevante i de tidligere faser. For at nå frem til en mulig løsning på problemet, vil der i dette speciale indgå informationer fra interviews, artikler samt de kravspecifikationer til brugen af BIM der er nødvendige i opstarten, og standarder der dertil høre. Overordnet set skal det være med til at skabe en større forståelse og indvirkning til digitale samarbejdsproblemer de opstartsfasen. Udover ideprocessen vil der blive anvendt to metoder, Prøve-fejl-metoden/falsifikationsmetoden og den kvalitative metode. Metoderne skal bruges til at få belyst emnet fra flest mulige synsvinkler. Metoderne vil primært blive anvendt i analyse- og den diskuterende del Prøve-fejl-metoden/falsifikationsmetoden Som indledning til specialet, vil der blive taget brug af Falsifikationsmetoden [(L1) Back m.fl., 2010:36]. Falsifikationsmetoden eller Prøve-fejl-metoden består i at man opstiller en række hypoteser inden man begynder sine undersøgelser. Det kan ske gennem almindelige antagelser, men ligeledes komme fra af egne observationer. Normalt bliver hypoteser skabt gennem grundige undersøgelser eller længerevarende observationer. Det kan f.eks. ske ved hjælp af den induktive metode 1. Ved Falsifikationsmetoden er det modsat. Her har hypoteserne ingen sandhedsværdi i begyndelsen. Når man har fundet sine hypoteser prøver man efterfølgende at falsificere, dvs. prøve at påvise at hypotesen er usande. Det kan ske gennem en videre bearbejdning af en mængde materiale, undersøgelser eller nye observationer se fig I rapporten bliver der opstillet tre hypoteser: 1. Flere aktører i rådgiverbranchen har ikke den nødvendige viden inden for anvendelsen af IKT, og derfor stiller både for svære og for lette krav. 2. IKT-bekendtgørelserne er for nemme at slippe udenom. 3. Det er umuligt at få et funktionelt digitalt samarbejde med en anden arkitektvirksomhed. Egne antagelser Egne observationer Hypotese Hypotese Observationer Undersøgelser Hypoteserne er opstillet på baggrund af den viden der er blevet samlet gennem egen interesse, samt gennem praktikforløbet hos Friis & Moltke, hvor man har observeret problematikken. Metoden skal være med til at give forfatter en større forståelse for hvorfor problematikken er opstået hos Friis & Moltke, men også om de samme problematikker er at finde i resten af branchen og på samme måde skabe en sammenligning. Teori Falsificeringsfasen Fig Gennemgang af processen i Falsifikationsmetoden. Egen ill. Sandt Falsk 1 Ved den induktive metode, foretager man undersøgelser på baggrund af en række observationer. Hvis der opstår en form for systematik i sine observationer, bliver der opstillet en hypotese. 4 S i d e

10 1.0 INDLEDNING Igennem specialet vil hypoteserne hovedsageligt blive falsificeret gennem litteratur, interviews og artikler, hvor det er muligt at trække kritiske linjer tilbage til hypoteserne. I konklusionen vil hypoteserne bliver falsificeret Den Kvalitative metode I Specialet vil der også blive taget brug af den kvalitative metode [(L1) Back m.fl, 2010:42]. Metoden anvendes i hovedtræk til indsamling af empirisk data, også kaldt blød data. Det vil sige, data der i modsætning til den kvantitative metode 2, ikke er målbar ud fra en eksakt data, men i stedet er nødvendig at formulere gennem ord. Metoden bliver i højt grad anvendt når det bliver besværligt kun at iagttage og måle, og man ønsker en mere dybdegående og Kvalitativ metode Spørgsmålstyper Stikprøvestørrelse Mængde af information fra hver respondent Krav til markedsanalytiker ifm. gennemførelse Hjælpemidler ved gennemførelse Mulighed for at gentage analysen med samme resultat Analysedesign Uddybende, undersøgende detaljeret analyse end den kvantitative metode kan give. Det kan f.eks. ske i situationer hvor der er en stor adspredelse i målgruppen af deltagere. Det kan være alt fra alder til mere konkrete politiske holdninger. I dette tilfælde er det erhvervsfolk fra forskellige virksomheder og med stor forskel i erfaring inden for anvendelse af IKT. Metoden bliver også kaldt en eksplorativ analyse [(W2)- Berg-marketing.dk]. Hvilket vil sige en analyse, som anvendes til at udforske bredt, og give mulighed for at arbejde mere åbent og kan improvisere for at få indsnævret sine hypoteser. Som beskrevet vil metoden blive brugt i dette speciale til enkeltstående interviews med erhvervsfolk, med erfaringer inden for anvendelsen af IKT og digitale samarbejdsproblemer i opstartsfasen af byggesager og de videre konsekvenser. Grundlaget for interviewsene er, at få en større forståelse for hvordan situationen er hos de danske arkitektvirksomheder. Og hvordan de muligvis har foretaget den påkrævet implementering ift. offentlige og almene byggesager. Metoden skal være med til vha. uddybende spørgsmål, at fremhæve de subjektive holdninger blandt de deltagende erhvervsfolk. Som der kan opstå, og på den måde få en mulig variation i de givende svar. Interviewsene vil blive lydoptaget og muligvis bestå af både skriftlige, telefoniske og personlige fremmødte interviews. For at være sikker på, at de deltagende har de rette kompetencer og kan være med til at finde frem til selve problemet og en mulig problemløsning. Bliver der opstillet en række kriterier der bedst muligt skal overholdes. Det gøres både for at komme frem til problemstillingen, men også for at spare tid med unødvendige spørgsmål. Kriterier for interviews: - Skal have en stilling der regelmæssigt beskæftiger sig med BIM - Skal have erfaring indenfor og forståelse for anvendelsen af IKT - Skal have medvirket i en sag, hvor man har samarbejdet med anden arkitektvirksomhed. - Skal have været med i begyndelsen af en given byggesag, hvor der kan have været vanskeligheder med at implementere IKT i byggeprocessens opstart. Lille Stor Interviewer med specielle forudsætninger og forståelse i emnet. Videooptager, båndoptager, spørgeramme, billeder Lille Eksplorativ analyse Fig Uddybende beskrivelse af kvalitativ metode. Egen ill. 2 Metode der anvendes til at indsamle data der er målbar, f.eks. data der er indsamlet gennem spørgeskema med faste svagmuligheder, der kan give et overordnet indblik i et givent emne. 5 S i d e

11 I de pågældende interviews, vil der blive stillet hypotetiske spørgsmål. De bunder i egne observationer og erfaring der er indsamlet gennem skoleprojekter, foredrag o.l., samt gennem et 20 ugers praktikophold hos Friis & Moltke. Da det er nødvendigt at inddrage ansatte fra Friis & Moltke og deres samarbejdspartnere vil alle spørgsmål forblive absolut objektive, spørgsmålene vil dog stadig være positiv og negativ rettet mod IKT og et digitalt samarbejde. Derudover vil spørgsmålene samtidig blive formuleret ud fra problemformuleringen og de tre hypoteser der er stillet under Falsifikationsmetoden. For at sikre en størst mulig entydighed i interviewsene, vil der i hovedtræk blive stillet de samme spørgsmål. Det vil være med til at skabe de bedste muligheder for, en senere sammenligning af interviewsene. Spørgsmålene er dog defineret så der med størst chance kan opstå tvetydige svar. Erhvervsinterviews Interviews med fagfolk der har været involveret i en sag med et samarbejde mellem anden arkitektvirksomhed. Hovedspørgsmålene vil være således: Spg. 1. Hvordan forekom jeres samarbejde med anden arkitektvirksomhed? Spg. 2. Har i fået kurser og rådgivning i brugen af vigtige værktøjer? Spg. 3. Hvilke digitale værktøjer brugte i til at kommunikere med anden arkitektvirksomhed? Spg. 4. Kunne en mere specifik IKT-aftale forbedre et samarbejde? Spg. 5. Kunne en ny læring i kommunikation hjælpe? Spg. 6. Er folk i branchen for uvidende til, at det kan lade sig gøre at oprette et digitalt samarbejde. Eller kan det skyldes at niveauet generelt er for lavt i Danmark, ift. Eks. England (Tre trins udvikling) Der vil ud over spørgsmålene være plads til en løs samtale. Her vil der være mulighed for at stille mere uddybende spørgsmål, da overnævnte spørgsmål, skal ses som retningslinjer for at skabe en entydighed. Balancen mellem den løse samtale og de ovennævnte spørgsmål, vil variere meget efter om deltageren i interviewet selv er initiativtagende, eller om interviewer konsekvens skal gå målrettet efter spørgsmålene. Introduktion af deltagere: Henrik G. Hansen BIM-Ansvarlig hos Friis & Moltke og har været med på Herlev Hospitals projektet. Ved at interviewe Henrik, vil man få et overblik over Friis & Moltkes syn på sagen, men fokus på BIM og IKT. Ove Kath Sagsarkitekt på Herlev Hospital og var været med på Herlev Hospitals projektet. Ved at interviewe Ove, vil det give en bred forståelse for projektet, og hvor han kan se det negative og positive i samarbejdet, Birthe Bæk BIM-Ansvarlig hos HLA og har været med på Herlev Hospitals projektet. Birthe Bæk har været ansvarlig for at udspecificere IKT-specifikationerne og BIM-manualen. 6 S i d e

12 1.0 INDLEDNING Birthe var ikke til at træffe under speciale skrivningen, så det har desværre ikke været muligt at få hendes holdninger med i specialet. Kenneth Højbjerg BIM-Manager hos Bjerg Arkitektur. Har siden han blev færdig som bygningskonstruktør i 2012 udelukkende koncentreret sig om BIM og anvendelsen af IKT. Vil kunne give specialet en praj om hvordan anvendelsen af IKT foregår i praksis. 1.5 Læsevejledning I dette speciale vil henvisninger til litteratur blive anført vha. Harvardmetoden, dvs. at henvisninger vil forekomme efter den givne kilde i teksten. F.eks. [Hildebrandt m.fl., 2005: 4] dvs. Forfatter: Hildebrandt m.fl (m.fl. vil blive brugt, hvis der er mere end en forfatter), årstal for udgivelsen af bogen: 2005, og sidetal: 4 Derudover vil der indgå følgende forkortelser til litteraturhenvisninger: [lbid.] Samme bog/litteratur, samme side. [op.cit.:sidetal] Samme bog/litteratur, anden side. På samme måde vil henvisninger til hjemmesider blive anført vha. Harvardmetoden. F.eks. [ Direkte links til kilderne vil være at finde i kildelisten. Henvisninger til litteraturlisten vil ske vha. forkortende ord med et tal tilkoblet. F.eks. W1 for hjemmeside eller L1 for litteratur. Hvilket vil være at finde henvisningen. Dvs. [(W1) Henvisninger til interviews vil blive anført med interviews nummer I2 og eksakte minuttal 4:32-5:12, f.eks. [(I2) 4:32-5:12] Interviews vil være at finde på den medfølgende cd under dokumentation_interviews. Henvisninger til illustrationer i tekst eller bilag er angivet som; Se fig. x eller Se bilag x. Ordforklaringer o.l. der skal være med til at give læser en bedre forståelse for emnet, vil være at finde i fodnote med standard nummerering. Direkte citering fra kildemateriale vil forekomme i kursiv, samt have kildehenvisning. Derudover vil der blive henvist til interviews. De optagede interviews vil forelægge på medfølgende cd i lydformat. Mulige skriftlige interviews vil være vedlagt i bilag. 1.6 Målgruppe Der forventes at læser er indforstået med de basale grundprincipper i BIM og der vil derfor ikke befinde sig en nærmere definition på hvad BIM indebærer, men kun elementer der er nødvendige for forståelse af resten af specialet. Specialet er skrevet til personer der ønsker en større viden i anvendelsen af IKT med primær fokus på opstartsprocessen ved en ny byggesag. Der vil indledningsvis være et afsnit, som indgang, til forståelse for IKT og hvilke aftalegrundlag der gør sig gældende. Det er derfor ikke nødvendigt for læser at have en grundig viden i IKT inden læsningen påbegyndes. 7 S i d e

13 2.0 Hoveddel 2.1 Digitale aftalegrundlag og standarder - Hvilke digitale aftalegrundlag og standarder gør sig gældende i et samarbejde med en anden arkitektvirksomhed? I følgende afsnit vil der blive givet en beskrivelse på hvad IKT indeholder, og hvilke faktorer den omhandler. Der vil derefter fremgå en beskrivelse af IKT bekendtgørelserne, efterfølgende med hvilke elementer man skal være opmærksom på i et samarbejde, når det omhandler de digitale IKT aftalegrundlag, samt hvilke standarder der har interesse mht. et samarbejde Hvad er IKT? Hvis man bare har fulgt det mindste med i både den danske, men også internationale byggebranche, kan man ikke have undgået at have stødt på forkortelsen IKT (ICT på engelsk). Men selv om mange har hørt ordet, er der stadig en stor forvirring omkring hvad forkortelsen overhovedet indeholder, og om det er et begreb udelukkende fra byggebranchen. Det enkle svar er nej. Forkortelsen IKT står for Informations- og kommunikationsteknologi og som navnet hentyder, består det af to elementer, informationsteknologi og kommunikationsteknologi. IKT er det nyeste skud på stammen over ord vi bruger, når man refererer til den digitale verden. Tilbage i slut 50 erne opstod ordet EDB, Elektronisk Data Behandling, der i sin enkelhed gik ud på at automatiserede elektroniske metoder til at behandle kommerciel data. Det var typisk meget enkle aktiviteter til at behandle en stor mængde oplysninger. [(W3) sites.google.com] Siden da er der sket et gigantisk skridt i den digitale verden, og man har derfor haft brug for at nuancere betegnelsen, så den passede til brugen. Ved EDB var der tale om envejskommunikation. I dag ses en flervejskommunikation der i sig selv ikke kun behøver at være mellem to enheder, men kan bestå af adskillige enheder. IKT omfatter bl.a. overførelser, lagring og indsamling af information, som man kender fra IT, Informationsteknologi. Men ligeledes af det, der gør det muligt at man kan viderebringe informationen, Kommunikationsteknologi. Dvs. IKT er derfor i alt sin enkelhed alt den teknologi vi anvender for at kommunikere og dele digital information med IKT-Bekendtgørelserne og anvendelsen i den danske byggebranche Siden slutningen af 2003, har man for alvor forsøgt at øge brugen af IKT i den danske byggebranche. En af de væsentlige årsager til, at fokusset blev rettet mod IT-teknologien, skyldtes de tre rapporter; - PPU-konsortiets rapport - IT i byggeriets fremtid (Højgaard & Schultz, Rambøll og Arkitektgruppen Aarhus) [(W4) Hfb.dk] - Ressourceområdeanalysen - Bygge/Bolig (Erhvervsministeriet) [(W5) Statensnet.dk] - Taskforce-rapporten - Byggeriets fremtid [(W6) Statensnet.dk]. I rapporterne indså man, at man havde problemer med pris, kvalitet og produktiviteten. Det resulterede i, at man i 2001 afsatte en arbejdsgruppe, der havde til formål at undersøge om man kunne komme problemet til livs ved, at implementere IKT i byggeriet. Konklusion blev, at man ville forsøge med en implementering i byggebranchen. 8 S i d e

14 2.0 Hoveddel 2.1 Digitale aftalegrundlag og standarder Det førte til at man i 2003 prøvede med regeringsinitiativet, Det digitale byggeri, der vha. regeringens rapport Staten som bygherre vækst og effektivisering i byggeriet, skulle være med til at gøre de statslige bygherre opmærksom på, at de skulle være mere aktive i kravstillelsen over for byggeriets aktører, og det ville hjælpe på den forandringsproces der var nødvendig. Branchen skulle dog stadig være med til at forme udviklingen, og derfor dannede man 4 konsortier. De fire konsortier havde til opgave, at løse opgaven om en mulig implementering af IKT i branchen. Det førte til projektrådet, De 4 konsortier, der dannede de tidligere bygherrekrav 3 [W7) Erhvervsstyrelsen.dk]. Som vist ved fig Man mente dog stadig at branchen manglede nogle standarder og klassificeringer, der kunne være med til at løse det stigende problem. Det skete ved, at Bips og Erhvervs- og byggestyrelsen indgik i et samarbejde om, Det digitale fundament [(W8) Bips, 2003:10]. Det resulterede i man specificerede de statslige bygherrekrav. De bestod af 10 krav til statslige og statsligstøttet byggerier. De 10 Fig Organisationsdiagram over det digitale byggeri, der er delt op i Bedst i byggeriet, De 4 bygherrekrav og Det digitale fundament. krav blev defineret i Erhvervs- og byggestyrelsens bekendtgørelse nr. 1365, Krav til anvendelse af informations og kommunikationsteknologi i byggeriet og blev gældende fra 2007 [(W9) Retsinformation.dk]. Siden da er bekendtgørelsen blevet revideret, den største og seneste revision kom i 2010, Bekendtgørelse nr Krav til anvendelse af informations- og kommunikationsteknologi i byggeriet [(W10) Retsinformation.dk]. Revisionen skulle være med til at gøre kravene mere overskuelige. Det skete bl.a. ved at nedjustere kravene fra 10 til 5, de såkaldte De 5 bygherrekrav. Revisionen trådte i kraft fra d. 1 marts, 2011 [(W11) Erhvervsstyrelsen.dk]. Disse var gældende indtil de nyeste bekendtgørelser trådte i kraft d. 1. april Dog gælder bekendtgørelsen stadig for byggesager, der har været i gang før d. 1. april I juni 2011 vedtog folketinget, Lov om offentlig byggevirksomhed. Vedtagelsen medførte at kommuner og regioner også skulle omfattes af de produktivitetsfremmende og omkostningsbesparende værktøjer, som de statslige byggerier var omfattet under, altså BEK nr [(W14)bygst.dk]. D. 9 februar 2013 blev de nye, og til dags dato gældende, IKT-bekendtgørelser offentliggjort. Som noget nyt har man valgt at dele bekendtgørelsen op i to: - BEK nr. 118 af 06/02/2013 om anvendelse af informations- og kommunikationsteknologi (IKT) i offentligt byggeri [(W12) Retsinformation.dk] - BEK nr. 119 af 07/02/2013 om anvendelse af informations- og kommunikationsteknologi (IKT) i alment byggeri [(W13) Retsinformation.dk]. 3 De tidligere bygherrekrav: Krav til bygherre der indebar; Projektweb, 3D modeller, Digitalt udbud og Digital aflevering. Se de 4 bjælker i Fig , under bygherrekrav 9 S i d e

15 Bekendtgørelsen er delt op i to for, at man kan inddrage de almene byggerier. Det er sket på baggrund af et ønske fra ministeret for By, bolig og landdistrikter, der ville have at tilsvarende IKT-krav også omfattede almene boligbyggerier [(W14) bygst.dk]. Med de nye bekendtgørelser er der endnu engang ønske fra regeringens side om, at fremme brugen af IKT i byggeriet for de offentlige bygherre, med størst mulig ensartethed. Med ændringerne ønsker regeringen at gøre byggebranchens aktører opmærksom på, en økonomisk besparelse ved brugen af IKT/BIM. Det kan evt. ske ved at standardisere sig og give mulighed for at genbruge data. Med de nye bekendtgørelser har man også forsøgt at gøre den mere overskuelig for byggeriets parter. Ved at forenkle sproget og formulere sig mindre juridisk, håber man på at gøre bekendtgørelserne nemmere anvendelige og lettere at forstå de opstillede krav. En af de væsentligste ændringer i bekendtgørelserne er, at man er gået fra de forhenværende 5 krav til 9. Dvs. der teoretisk set er kommet flere krav som bygherren skal stille til byggesagens parter. Bekendtgørelserne består i alt af 12 paragraffer, der er opdelt i tre kategorier; 1-2 Bekendtgørelsens anvendelsesområder 3-11 Selve bekendtgørelsen 12 Bekendtgørelsens ikrafttrædelse De to bekendtgørelser er næsten identiske på nær 1 og 2, dvs. anvendelsesområderne. Nedenfor er vist hvilke områder der gør sig gældende for den enkelte bekendtgørelse: Bekendtgørelse nr. 118 Offentligt byggeri [(W12) Retsinformation.dk] 1. Bekendtgørelsen gælder for opførelse af byggeri, om- og tilbygning af byggeri, renovering og vedligehold af byggeri samt anlæg knyttet hertil ved: Byggeri med staten som bygherre med en anslået entreprisesum på 5 mio. kr. ekskl. moms eller derover. Byggeri med en anslået entreprisesum på 5 mio. kr. ekskl. moms eller derover, der helt eller delvist finansieres ved lån eller tilskud fra staten på mindst 50 pct. Byggeri med en anslået entreprisesum på 5 mio. kr. ekskl. moms eller derover til brug for institutioner, hvis drift betales af staten, når tilskuddet udgør mindst 50 pct. af driften. Byggeri med region og kommune som bygherre med en anslået entreprisesum på 20 mio. kr. ekskl. moms eller derover. Byggeri med en anslået entreprisesum på 20 mio. kr. ekskl. moms eller derover, der helt eller delvist finansieres ved lån eller tilskud fra region og kommuner, på mindst 50 pct. Byggeri med en anslået entreprisesum på 20 mio. kr. ekskl. moms eller derover til brug for institutioner, hvis drift betales af region og kommuner, når tilskuddet udgør mindst 50 pct. af driften. Stk. 2. Bekendtgørelsen gælder ikke for byggeri, som får tilsagn om offentlig støtte efter lov om almene boliger m.v., lov om friplejeboliger og efter lov om byfornyelse og udvikling af byer. 2. Bygherren kan i forbindelse med byggesager vedrørende renovering og vedligehold undlade at opfylde ét eller flere af bekendtgørelsens krav, hvis udgifterne forbundet med opfyldelse af det eller de pågældende krav ikke står mål med gevinsterne. Stk. 2. Bygherren kan dog ikke fravige reglerne i 8 om digitalt udbud og tilbud via et digitalt system. Bekendtgørelse nr. 119 Alment byggeri [(W13) Retsinformation.dk] 1. Bekendtgørelsen gælder, jf. dog 2, for: 10 S i d e

16 2.0 Hoveddel 2.1 Digitale aftalegrundlag og standarder Byggerier i henhold til 115 i lov om almene boliger m.v. Renoveringer i henhold til 91 og 92, stk. 1 og 3, i lov om almene boliger m.v. Projektkonkurrencer, som bygherren afholder i forbindelse med de byggerier, der er nævnt i nr Bekendtgørelsen finder kun anvendelse på byggerier, renoveringer eller projektkonkurrencer, hvor en almen boligorganisation, en kommune eller region er bygherre, og hvor byggeriets eller renoveringens samlede, anslåede entreprisesum er på 20 mio. kr. ekskl. moms eller derover. Som nævnt, er det de 2 første paragraffer ud af de 13 der er uafhængige fra de 2 bekendtgørelser. Som det ses i overnævnte tekst fra BEK nr. 118 og 119, skal man gøre brug af IKT-kravene når entreprisesummet opnår en vis størrelse i de forskellige instanser, eller udgør 50 pct. af prisen. Ved statslige og statslige støttet byggerier er det 5 mio. ekskl. moms, og ved region og kommune alment byggeri er det 20 mio. ekskl. moms der gør sig gældende. De næste 9 krav er identiske i de to bekendtgørelser og kan opstilles i tre typer af krav: 1. Krav, som øger kvaliteten og produktiviteten hos bygherren. 2. Krav, som øger driftsherrens produktivitet i driften. 3. Krav, som øger kvaliteten og produktiviteten i leverancesystemet, som i denne sammenhæng omfatter rådgivere, projekterende, udførende, byggevareproducenter, it-udbydere m.v. [(W14)bygst.dk] For at bygherren kan opnå fordele i sine egen arbejdsproces og hos sig selv, er det nødvendigt at sikre at kravene er stillet korrekt ift. de to første typer krav. Ift. specialets afgræsning vil kun de paragraffer der har direkte indflydelse for to arkitektvirksomheder blive givet en kort beskrivelse af. Det vil sige, de kravstillelser der gør sig gældende til projekteringen og stillelser der på anden måde, kan have en indflydelse på det samarbejde der kan foreligge mellem to arkitektvirksomheder. BEK 118 og BEK 119 er desuden vedlagt i Bilag 6.1 og Bilag IKT-Koordinering Formålet med kravet er, at der under hele projektforløbet er en specifik IKT-leder (IKT-koordinering), der er udpeget til at have det overordnet ansvar for at koordinere det digitale samarbejde med de involverede aktører, f.eks. to arkitektvirksomheder hvis det er tilfældet. Som regel findes IKT lederen hos en af projektets rådgivere, da man kender til projektet, og vil derfor indgå i projektets rådgiveraftale. IKT-lederens ydelser vil ofte blive formuleret i ydelsesbeskrivelsen under pkt. 2.2 IKT-ledelse [(W15) Frinet.dk]. Her vil IKT-lederen have ansvaret og har til opgave at formidle, koordinere, organisere og dokumentere anvendelsen af IKT i byggesagens forløb. For at få en bedre definition på IKT-Koordineringen, kan der udarbejdes specifikke IKT-specifikationer såsom IKT- Ydelsesspecifikation og IKT-Tekniskspecifikation (vil blive beskrevet senere i specialet). IKT-specifikationerne vil især relatere til; Digital kommunikation, Anvendelse af digitale bygningsmodeller, digitalt udbud og tilbud og digital aflevering. Ift. organisering af fællesmodellen i den objektbaserede bygningsmodellering, har IKT-lederen kun ansvar for det IKT-mæssige. Selve den tværfaglige koordinering og kontrol og indholdet i modellen har projekteringsledelsen og projektets fagansvarlige ansvaret for. [(W14) Bygst.dk] 11 S i d e

17 4. Håndtering af digitale byggeobjekter 4 stiller krav til, at sikre at information om byggeobjekter og deres egenskaber på bedst mulig måde er til rådighed for bygherre, rådgivere og udførende under hele byggesagen. Samt materiale der er relevant for driftsherre ved overdragelse. Alt dette skal ske på bedst tænkelig måde, så dataudvekslingen kan ske uhindret. Derudover er formålet at udnytte nogle af de kvaliteter der indebæres ved at arbejde med objektbaseret modellering. Ved at klassificere alle objekter entydigt, vil det være muligt at identificere dem senere i processen, f.eks. i tilbudslister og bygningsdelsbeskrivelser, på tværs af professioner og faser. Kravet er opstillet for at sikre at information om objekterne ikke går tabt i processen og kan udveksles mellem parterne og de forskellige IKT-systemer der anvendes. Til anvendelsen er der tre klassificeringssystemer, der anbefales: Sfb-systemet CCS (Cuneco Classfication System) der er under udvikling som erstatning for Dansk bygge Klassifikation (DBK) 5. Forvaltnings Klassifikation, version 2.0 som benyttes fra 2012 i forbindelse med forvaltning af almene boliger 6. [(W12) Retsinformation.dk] Kravet til brugen stilles af bygherren og gælder samtlige parter i byggesagen. Man anbefaler at kravet indgår i aftalegrundlaget, hvor der specifikt henvises til relevant dokumentation, kodning og klassifikation. Derudover er det en god ide at man fastsætter de specifikke løsninger til at opfylde kravet, da bekendtgørelsen kun stiller krav til anvendelsen og ikke fastsætter brugen. [(W14) Bygst.dk] 5. Digital kommunikation og projektweb mv. Pointen med kravet er at have et fælles sted, som benyttes af flere parter, hvorfra man kan hente det nødvendige materiale. På den måde sikres en effektiv måde at formidle den digitale data. Ligeledes sker der automatisk en systematisering og dokumentering af den digitale kommunikation mellem byggesagens parter. Det vil sige, at man får skabt et centralt arkivsystem, som alle sagens parter har adgang til. Ved at skabe det fælles arkivsystem har man ligeledes kendskab til hvem der har ansvaret for hvilke dataleverancer og hvornår de skal være klar for de øvrige parter. Typisk sker det vha. af projektweb, hvilket er internetbaseret. Eller ved brug af en modelserver, der indeholder alle digitale byggeobjekter. Ved brug af et fælles arkivsystem er det dog vigtigt at der er klare linjer for mappestrukturen og navngivningen er filer. Det er derfor nødvendigt at udarbejde et fælles grundlag, det kunne f.eks. være Bips A104 Dokumenthåndtering, der er en vejledning til mappestrukturen og navngivningen, der 4 SfB-systemet: Den mest anvendte klassifikationssystem. SfB-systemet er dog ved at være forældet, da systemet er bygget op omkring dokumentbaseret arbejdsmetode, dvs. den kun rummer tabeller for bygningsdele, konstruktioner ressourcer. Men mangler tabeller for øvrige objektklasser [(W14) Bygst.dk]. 5 CCS: Er et nyt informationshåndteringssystem til at støtte brugen af IKT i byggeriet. Hensigten er, at CCS skal indeholde bl.a. klassifikation, identifikation, og struktureret håndtering af egenskaber til understøttelse af vedligehold og udveksling af informationer om bygværker, rum, bygningsdele, ressourcer og processer igennem hele byggeriets værdikæde [(W14) Bygst.dk]. 6 Forvaltnings klassifikation: FK er en klassifikation, som tilgodeser kravet om systematisk håndtering af alle aktuelle objekttyper (bebyggelser, afdelinger, bygninger, rum, bygningsdele m.v.) i forvaltningsdomænet. Det er desuden en klassifikation, der sammen med nye kontoplaner for konto 115 og 116 (almindelig og planlagt vedligeholdelse) i den almene driftskontoplan danner en brugsmæssig helhed [(W14) Bygst.dk].. 12 S i d e

18 2.0 Hoveddel 2.1 Digitale aftalegrundlag og standarder er bygget op efter metadata en 7 du giver din fil (En mere dybdegående beskrivelse af Bips A104, vil forekomme senere i specialet under afsnit 2.2). Man skal dog være opmærksom på den stemmer overens med projektmanualer, f.eks BIM-manualen. Derudover er det vigtigt man arbejder med åbne filformater. Kravet omfatter alle byggesagens parter, og skal indgå i aftalegrundlaget. Desuden vil det være fornuftigt at der formidles en IKT-ydelsesbeskrivelse eller specifikation på den digitale kommunikation. [(W14) Bygst.dk] 6. Anvendelse af digitale bygningsmodeller i projektkonkurrencer Formålet med paragraffen er at sikre, at der bliver anvendt en objektbaseret bygningsmodel under projektkonkurrencen. Det gøres for at forslagene til de arkitektoniske, funktionelle og tekniske forhold er i orden. Ved at anvende en objektbaseret bygningsmodel, får bygherren en bedre mulighed for at danne sig et overblik over projektet, pga. der er langt større mulighed for visualisering. Det gælder både de arkitektoniske aspekter, men ligeledes det funktionelle og energi- og miljø forholdene mv., som er mulige at udføre gennem simuleringer med en 3D-model. Et vigtigt punkt i paragraffen er at man ligeledes skal aflevere i et åbent filformat, IFC. Det gøres for at sikre at modellen er læsbar, og er uafhængig af softwaren. På den måde sikres at man ikke hindres i at deltage, hvis man anvender en specifik software. Man skal dog være opmærksom på at IFC-filer ikke altid implementeres lige godt. Det kan derfor være en fordel at anvende samme software med samarbejdspartnere under projektkonkurrence, inden aflevering af konkurrenceprojekt. Dette krav er især vigtigt, da der på dette tidspunkt ikke foreligger aftaler mellem parterne. Derfor skal kravet opsættes som en betingelse for at konkurrenceforslagene betragtes som konditionsmæssige. [(W14) Bygst.dk] 7. Anvendelse af digitale bygningsmodeller i projektering og udførelse Der stilles krav til anvendelse af objektbaseret bygningsmodeller i projekterings- og udførelsesfasen. Det gøres for at man på bedst mulig måde anvender de muligheder der opstår ved et objektbaseret arbejde. Det har til formål at øge produktiviteten og kvaliteten under projekteringen, men der opstår også mulighed for at køre en dybdegående kollisionskontrol på projektet ved at anvende en 3D-model, og på den måde forbedre kvalitetssikringen af det samlede projektmateriale. Det giver også rig mulighed for en optimering af en effektiv planlægning. Under projekteringen vil der være langt større beslutninger der skal træffes ang. modellen, blandt andet fordi informationsniveauet stiger. Det er derfor vigtigt at indskrive i rådgiveraftalen, hvem der har ansvaret for den objektbaseret bygningsmodel, og aktørens ydelser og rolle. Men ligeledes anbefales det, at man i specifikationer definerer parternes ønsker og behov til detaljeringsgraden af modellen. Bl.a. fordi man ofte på dette tidspunkt arbejder i en fællesmodel. Til fællesmodellen anbefales det også, at udpege en ansvarlig for opbygning og vedligeholdelse af modellen, hvilket tydeligt skal fremgå i IKT-ydelsesspecifikationen. Kravet bliver stillet af bygherren til rådgiver og skal derfor indgå i rådgiveraftalen. [(W14) Bygst.dk] 7 Metadata er de informationer du vælger at tildele din fil, dokument eller tegning. F.eks. dit musikbibliotek der er opbygget efter kunster, sang, album, årstal. Jo flere informationer du giver dine filer, jo nemmere vil det være senere at finde frem til netop det dokument du søger. 13 S i d e

19 8. Digitalt udbud og tilbud 8 har som sådan ikke indflydelse på samarbejdet mellem to rådgivende arkitekter. Udover at bygherre skal indgå en aftale med de projekterende om hvordan projekteringsmaterialet skal struktureres. Det er dog iht. til 4,6,7 og 10. Denne strukturering er dog også yderst vigtig ift. detaljeringsgraden af eksempelvis udbudsmængderne, da metoden skal være identisk igennem hele udbudsmaterialet. Der skal således være entydighed mellem udbudsmaterialets objekter, beskrivelsen af objekternes egenskaber og tilbudslistens positioner og mængder, hvilket der i sig selv kræver klare aftaler og disciplin. [(W14) Bygst.dk] 9 Udbud med mængder Formålet med paragraf 9 er endnu engang at anvende de muligheder man får ved objektbaseret bygningsmodeller, og hvis de rigtige informationer er knyttet til objekterne, mulighed for at trække mængderne ud af modellen og direkte ind i tilbudslisterne. På den måde får man en entydig mængde, der sendes til udbud. På den måde minimeres mulige fejlmålinger fra entreprenørens side i opmålingen af mængderne. Det betyder dog også, at man skal have klare aftaler om hvordan mængderne er defineret fra rådgivers side, og klare aftaler om hvilke informationer objekterne skal indeholde ift. tidligere paragraffer. Det er dog muligt at kombinere et udbud der har defineret mængder og et uden. Ved at anvende udbud med mængder, påhviler der også rådgiveren et ansvar for korrekt mængde, og han står ligeledes til ansvar hvis der opstår fejlmålinger i mængdeudtaget senere i processen. Det kan dog frasiges ved at man ved kontraktforhandlinger stiller krav om at entreprenøren inden for en given tid, selv kontrollerer mængderne. [(W14) Bygst.dk] 10. Digital leverance ved byggeriets aflevering Formålet med kravet er at udnytte de informationer som der er givet til den objektbaseret model, når byggeriet afleveres. Derved vil det være muligt at benytte informationerne ved 1- og 5 års eftersynene (Byggeskadefondens eftersynsordning ved det almene boligbyggeri). Det vil sige, at den digitale aflevering er med til at udleve visionen om at modellen anvendes fra start til slut. Kravene til paragraffen er meget flyvske og man er meget åbensindet i hvordan kravene bliver opfyldt, grundet driftherrens softwareplatforme kan være så forskellige. Det er dog vigtigt at modellen afleveres i IFC format. Derudover er det fornuftigt at indtænke et system til håndtering af filerne, muligvis Bips A104 - Dokumenthåndtering. For rådgiverne er det vigtigt at man har indtænkt den digitale aflevering fra start og der er opnået enighed, muligvis gennem IKT-specifikationerne. Det vigtigste er, at der bliver udpeget en afleveringsansvarlig, der sikrer at afleveringen sker fyldestgørende. [(W14) Bygst.dk] 11. Digital mangelinformation Kravets formål er at sikre at der sker en systematik af manglerne. Ligesom med 10, handler det lige så meget om at anvende en BIM-model på bedst mulig måde, og sørge for at der sker et informationsflow i driftherrens IKT-system. En af fordelene ved at knytte en BIM-model til mangellisterne er, at det giver et bedre overblik til at lokalisere manglen. Det er derfor nødvendigt at man fra start har nogle klare retningslinjer mellem rådgiverne, om hvordan de informationerne implementeres i modellen og hvilke der er nødvendige. Det vil derfor også have en fordel at give en person ansvaret på det bliver opfyldt. Det kunne bl.a. være projekteringsledelsen. 14 S i d e

20 2.0 Hoveddel 2.1 Digitale aftalegrundlag og standarder Hvis der indgår to rådgivere, er det vigtigt at man har udarbejdet hvilken rådgiver og medarbejdere der har hvilke ansvarsområder for, at der ikke skal opstå tvivlsspørgsmål senere i processen. [(W14) Bygst.dk] Digitale IKT aftalegrundlag Fælles for bekendtgørelserne, bliver der stillet krav til, at bygherren opstiller betingelser. Men bekendtgørelserne omfatter ikke hvordan bygherren har tænkt sig at stille kravene over for byggeriets andre parter. En beskrivelse af kravstillelsen vil derfor ofte indgå i de aftalegrundlag der bliver lavet. Disse krav vil typisk være en del af ydelsesbeskrivelsen, der knytter sig til byggesagsbeskrivelsen og rådgiveraftalen. I følgende afsnit, vil indgå en beskrivelse af de vigtigste aftalegrundlag der skal være på plads i et samarbejde. Rådgiveraftalen Når en bygherre indgår i et samarbejde med rådgiverne, er det vigtigt at få aftalegrundlaget i orden. Derfor anvendes i de fleste tilfælde Almindelige betingelser for teknisk rådgivning og bistand, også kaldt ABR 89. ABR 89 er ikke en lov, og det er derfor nødvendigt at aftale at anvende ABR 89. ABR 89 bruges til at definere opgavens omfang og indhold, samt rådgiverens forpligtelser. Heri kan også indskrives hvordan rolledelingen er ift. til de forskellige involverede. Rådgiveraftalens hovedformål er at undgå senere konflikter. Det er derfor vigtigt at det tydeligt indgår, hvordan ansvarsfordelingen foreligger, også mellem rådgiverne i mellem [(W16) Mowe.dk]. Ydelsesbeskrivelser for Byggeri og Planlægning 2013 Ud over rådgiveraftalen, kan det være en god ide at anvende/henvise til ydelsesbeskrivelsen fra Ydelsesbeskrivelsen er med til at definere den rolle rådgiveren skal varetage over for bygherren ift. rådgiveraftalen. Men også hvilken rådgiver der varetager de forskellige roller. Ydelsesbeskrivelsen skal være med til at give en afgrænsning af den rådgivning der skal afleveres. I forhold til IKT, er det særligt punkt 2.2, der er vigtigt Pkt. 2.2 IKT Koordinering. Punktet har været en del af beskrivelsen siden Siden da har man gjort punktet mere specifikt, hvor den væsentlige ændring er, at man har tilføjet punktet Kvalitetssikring: IKT lederen koordinerer kollisions- og konsistenskontrol på grundlag af de digitale fagmodeller [(W15) Frinet.dk]. Hvilket har gjort sig gældende siden 2009 [(W17) Danskeark.dk] IKT-Specifikationer/IKT-aftale IKT-specifikationer for byggeriet bruges til at definere de digitale aftalegrundlag der skal foreligge mellem de parter der indgår i en byggesag. Dvs. de projekterendes ydelser på en byggesag, samt de tekniske og praktiske i det digitale samarbejde på den pågældende sag. Specifikationerne omfatter hovedsageligt det digitale grundlag, den digitale kommunikation, digitalt udbud og afleveringen, og CAD. De nuværende IKT specifikationer, F udgave fra dec. 2013, bygger på de tidligere publikationer: CAD-projekt-aftale 2005 C205, 3D CAD projektaftale 2006, Erhvervs- og Byggestyrelsens IKT-aftale 2006 og Bips F102 Byggeriets IKT-specifikationer, anvisning, 2. udgave juni 2011 [(W18) Bips.dk]. Specifikationerne kan opdeles i to: 1. Ydelsesspecifikationen. Specifikationen anvendes til at klarlægge de projekterendes digitale ydelser på den gældende byggesag. Det kan bl.a. være krav fra bygherre eller aftaler der er lavet mellem de projekterende parter. Det er derfor også muligt at indgå aftaler blandt parterne uden bygherre har gjort et krav gældende. 15 S i d e

21 2. De tekniske specifikationer. Specifikationerne gælder de tekniske og praktiske forhold der befinder sig i et digitalt samarbejde mellem parterne i en byggesag. Der kan i nogle tilfælde være krav fra bygherrens side til de tekniske forhold, men de vil typisk blive udarbejdet af de projekterende efter kontraktindgåelse. De tekniske specifikationer består af: a. IKT-Teknisk kommunikation b. IKT-Teknisk CAD c. IKT-Teknisk Udbud d. IKT-Teknisk Aflevering Ved at opdele specifikationerne i to dele, er det muligt allerede på et tidligt tidspunkt i processen at udarbejde en plan for hvad ydelserne skal indeholde. Hvorefter man igennem processen opdaterer de tekniske specifikationer, da de ofte kan være svære at definere ordenligt så tidligt. Ved at definere nogle faste og klare rammer, undgår man en senere konflikt eller forvirring om aftalen mellem sagens parter. Fig Ydelsesspecifikationen opbygning, Vejledning, Basistekst og den projektspecifikke [(W18) Bips.dk] Bips F202 Basis beskrivelse Ydelsesspecifikation CAD-Manual 2008 A104 Dokumenthåndtering Beskrivelsesværktøj B1.000 Digitale mangellister Projekt specifik beskrivelse IKT-teknisk kommunikation IKT-teknisk CAD IKT-teknisk udbud IKT-teknisk aflevering Fig IKT-specifikationer og basisbeskrivelser der gør sig gældende. Egen ill. Del 1. IKT-ydelsesspecifikationen Ydelsesspecifikationen består ligesom med Bips andre publikationer af tre dele, en basisbeskrivelse, en projektspecifik og en vejledning. Basis og den projektspecifikke er opsat i samme dokument i to separate kolonner, og udgør tilsammen ydelsesspecifikationen, mens vejledningen er i et dokument for sig selv. Det er altid basisteksten der gør sig gældende, hvis nogle af ydelsesområderne ikke er anført i den projektspecifikke. Basis og projektspecifikke udgør tilsammen ydelsesspecifikationen. For opbygning se fig Som skrevet tidligere er der et vigtigt punkt i ydelsesbeskrivelsen ang. IKT (pkt. 2.2). Det er derfor lige så vigtigt at IKT-ydelsesspecifikationen stemmer overens og uddyber ydelserne ift. IKT-ledelse. Man kan ligeledes anvende IKT-ydelsesspecifikationen til af definere IKT-lederens rolle og ydelser mere tydeligt, samt hvem ellers der har et overordnet ansvar. Det er ligeledes også muligt at man definerer flere af bygherrens IKT-krav i IKTydelsesspecifikationen. [(W18) Bips.dk] Derudover bruges IKT- ydelsesspecifikationen til at samle de relevante kontrakter mellem de parter, der er omfattet af de digitale ydelser som indgår i samarbejdet på byggesagen. I Basisteksten indgår bestemmelser som anvendes som almene gældende grundlag, der ligeledes er skabt for at danne størst mulig samhørighed. Den projektspecifikke anvendes til at definere de tilvalgsposter der burde komme, men også hvilke man fravælger sig, så den passer med de krav man har til den enkelte sag. 16 S i d e

22 2.0 Hoveddel 2.1 Digitale aftalegrundlag og standarder Det giver både mulighed for at tilvælge sig basistekstens bestemmelser, samt uddybe sine egne under særlige forhold. Del 2. Tekniske specifikationer De tekniske specifikationer, som er vist i Fig er opdelt i 4 dele, kommunikation, CAD, udbud og aflevering. De tekniske specifikationer anvendes til en dybere definition af det digitale samarbejde mellem byggesagens parter. De tekniske specifikationer må dog ikke indeholde ydelser, som skal være defineret i del 1. Ved de tekniske specifikationer er det alene en projektspecifik. Dog er der knyttet basisbeskrivelser/anvisninger der til, som fremstår for dem selv. Disse vil blive defineret senere i specialet. (Se fig felter der er markeret med gråt). Nedenfor er en kort beskrivelse af de fire specifikationers funktioner [(W18) Bips.dk]. 1. IKT-Teknisk Kommunikation specifikation Går i sin enkelhed ud på at bygherren udpensler, hvordan man har tænkt sig den digitale kommunikation skal foregå, både teknisk, men også i praksis. Det gælder bl.a. projektweb, som skal være udfyldt for at 5 er opfyldt. Der vil typisk foregå revisioner i dokumentet, under byggesagen, da der kan forekomme elementer man ikke havde taget højde for. 2. IKT-teknisk CAD specifikation CAD specifikationen henvender sig mest af alt til 6 og 7, der omhandler brugen af digitale bygningsmodeller i konkurrencefasen og under projekteringen. Specifikationen anvendes til at præcisere de tekniske og praktiske rammer ved anvendelsen af CAD. Bl.a. bestemmelse af informationsniveauer, dataudtræk og egenskabsdata. 3. IKT-teknisk Udbuds specifikation Specifikationen berører kravet om digitalt udbud og tilbud, 8. der tydeliggøres brugen og de tekniske forhold der er nødvendige i byggesagen. Her defineres flere af ydelserne fra ydelsesspecifikationen, det kan bl.a. være omkring opmåling, mængder og hvordan datastrukturen skal være. Samtidig henvises der til B1.000, F103, C202, F111 for basisbeskrivelser. 4. IKT-Teknisk afleverings specifikation Den tekniske afleveringsspecifikation er ligesom tilfældet med de andre, en yderligere præcisering af de tekniske og praktiske forhold der skal foreligge, hvis man vælger at udføre en digital aflevering. Det kan bl.a. være hvilke dokumenter der skal afleveres, samt hvilke oplysninger der er nødvendige per dokument Relevante standarder og anvisninger Som fortalt i ovennævnte afsnit, udgør de tekniske specifikationer kun en projektspecifik del, hvorimod basisbeskrivelsen findes i en andre publikationer. Der vil derfor komme en kort gennemgang af beskrivelserne samt andre relevante standarder og vejledninger der kan have betydning for samarbejdet mellem to arkitekter. Det er dog svært at beskrive alle de værktøjer der kan hjælpe og gøre et samarbejde nemmere. Derfor vil der komme en kort beskrivelse af nogle af de vigtigste, der samtidig har indflydelse på IKT-specifikationer mv. Samt en opremsning af andre betydelige standarder m.m., dog uden forklaring. Bips A104 Dokumenthåndtering A104 er en anvisning til hvordan man kan håndtere sine dokumenter. Håndteringen består af to elementer. En mappestruktur og en filnavngivning. Filnavngivningen gives ud fra filens placering i mappestrukturen. Ved at tilknytte den korrekte metadata, bliver det også nemmere at søge på filen. Det virker dog bedst på projektweb, da operative styresystemer som Windows ikke er egnede til det. Med A104 skaber man en fælles måde at navngive og placere filer, hvilket gør at der ikke opstår den 17 S i d e

23 samme misforståelse, og chancen for at filer forsvinder minimeres. Det er især vigtigt for eksterne dokumenter eller tegninger, hvor flere forskellige parter skal anvende filen. Bips C102/C202 CAD Manual 2008 CAD Manualen består af to elementer, en anvisning (C102) og en basisbeskrivelse (C202). Manualen bruges til at fastlægge nogle fælles retningslinjer for brugen af 2D/3D projektering og skal være med til at påvirke brugen af cad-samarbejdet og cad-produktionen i en positiv retning [(W19) Bips.dk]. Bips B1.000 Beskrivelsesanvisning Beskrivelsesanvisningen bruges til at give den korrekte information til Bips anvisninger og beskrivelser i hvordan de hænger sammen og hvordan de udfyldes korrekt. Det er nødvendigt med en forståelse for strukturen for, at du kan sammensætte dine beskrivelser og på den måde er det afgørende for hele grundarbejdet, ved anvendelse af Bips værktøjer. Den har ikke direkte indflydelse på et samarbejde, men mere en hjælp mod en sikker arbejdsmetode der fører frem til et korrekt samarbejde [(W20) Bips.dk]. Bips U104 Digitale mangellister ved udveksling At udfylde mangellister for et helt byggeri kan være en stor byrde, samtidig findes der et utal af forskellige måder at føre journal for manglerne. Når det skal være digitalt og i samarbejde med andre, er det nødvendigt at der er en entydighed i mangellisterne. U104 skal ses som en teknisk standard for de digitale mangellisters indhold og anvendelse [(W21) Bips.dk]. Bips C110 Kom godt i gang med 3D/ Bips C214 Guide om objekter C110 udkom i 2009, og blevet lavet for at give et indblik i og ide om hvad man som aktør gik ind til og hvad man skulle være opmærksom på, når man gik fra 2D projektering til 3D. Publikationen stiller en del af de problemstillinger man kan stå med som firma, og giver nogle løsninger til problemerne. Publikationen skal være med til at man får skabt en korrekt implementering i sin virksomhed. [(W22) bips.dk] C214 henvender sig til hvordan man anvender den tre dimensionelle verden og arbejdet med objekter. Hvis man ikke før har prøvet det, kan det give problemer fra første skridt. C214 skal ses som en guide til korrekt brug af objekter og hvad det indebærer at arbejde med BIM objekter, og hvordan du bruger objekter i et samarbejde med en anden instans [(W23) Bips.dk]. Disse to vejledninger kan være et rigtig godt fundament, hvis man selv eller andre i et samarbejde ikke har det samme kompetenceniveau, og på den måde kan man hæve hele niveauet og ligeledes skabe et bedre samarbejde, hvis alle er indforstået med arbejdsmetodens gøren. Ud over de ovennævnte standarder/anvisninger, er der flere publikationer der kan være fordel i at benytte i et samarbejde med en anden arkitekttegnestue. Det kan bl.a. være med til at give en fælles forståelse, men også nogle fælles retningslinjer for fremtidig brug i projekteringen. - Bips C101 CAD udveksling Bips C213, C203 Tegnestandarder - Bips C201 Lagstruktur - Bips F103 Objektstruktur - Bips F110 Opmålingsregler - Bips C205 IKT/CAD aftale S i d e

24 2.0 Hoveddel 2.2 De korrekte krav til anvendelsen af IKT 2.2 Korrekte krav til anvendelsen af IKT - Forstår man til dags dato at afsætte fyldestgørende og korrekte krav til anvendelse af IKT, og hvad er konsekvenserne af det? Det kommende afsnit vil fungere som en analytisk indgang til, om man forstår at afsætte kravene til anvendelse af IKT på en korrekt måde, så de er med til at hjælpe på processen, og hvad de mulige konsekvenser der kan opstå. Det vil gøres gennem en case fra et samarbejde mellem Friis & Moltke og Henning Larsen på projekteringen af til- og nybygningen på Herlev sygehus Case Samarbejdet mellem Friis & Moltke og Henning Larsen Den følgende case, omhandlende samarbejdet mellem Friis & Moltke og Henning Larsen på projekteringen af Herlev Hospital. Vil blive støttet op af egne observationer, der er foretaget gennem de 20 ugers praktikforløb hos Friis & Moltke, hvor man indgik i projekteringen i de sidste tre måneder af hovedprojektet. Derudover vil der blive taget brug af interviews, samt aftalegrundlag og IKT-specifikationer for at få en fornemmelse af det udgangspunkt samarbejdet havde. Casen vil udelukkende omhandle de to arkitekter, og der vil derfor ikke indgå andre af aktørerne fra konsortiet eller underrådgivere. I casen vil der blive brugt følgende forkortelser; for Friis & Moltke FM og Henning Larsen HLA. Det primære fokus i casen vil omhandle anvendelsen af IKT, BIM og de mulige konsekvenser. Der gøres opmærksom på at flere af de gældende bekendtgørelser, specifikationer mv. ikke gjorde sig gældende da sagen startede op. Derfor vil retningslinjerne have været anderledes ved Herlev sagen. Det gælder bl.a. IKT-bekendtgørelse 1381 og tidligere revisioner af IKT-specifikationer mv. I 2007 udarbejdede region hovedstaden en plan for hospitalsstrukturen i hele regionen. I den anledning blev Herlev hospital udvalgt som nyt områdehospital. Der var dog behov for forbedringer. I 2008 blev der bevilliget 2,25 mia. til udbygning. Det gældte f.eks. nyt kvinde-barncenter og en ny akutmodtagelse. I den anledning blev der udskrevet en begrænset udbudskonkurrence i to dele (delprojekt A og B). Her bød konsortiet NHH ind på delprojekt A. I spidsen af konsortiet stod Henning Larsen, derudover bestod konsortiet af; Friis & Moltke, Norconsult, NNE Pharmaplan og Orcicon. Delprojekt A er en udbygning på Herlev Hospital, der udgør et areal på m 2 og skal blandt andet rumme en ny akutmodtagelse og et kvinde-barn-center med børne- og fødeafdeling. Projektet udgør 5 etager der består af 2 etager med rektangulære baser, samt 3 etager med cirkulære bygninger med sengestuer. Konsortiet NHH vandt konkurrencen i 2011 (12. april 2011) [(W24) Herlevhospital.dk] se Ingeniør/ Norconsult Arkitekt/ Henning Larsen Bygherre/ Herlev Hospital Totalrådgivere Ingeniør/ Pharmaplan Underrådgivere Bygherrerådgiver: Niras Aarhus Arkitekterne Ingeniør/ Orbicon Arkitekt/ Friis & Moltke Erik Steffensen (Bygningsintegreret kunst) SLA A/S (Landskabsarkitekter) Brundsgaard & Laursen (Arkitekter) Via Trafik Rådgivning A/S (Ingeniør) Fig Organisationsdiagram over Herlev hospitals udbygning af del A Egen ill. 19 S i d e

25 fig for organisationsdiagram over konsortiet NHH. Med underskrivelsen af rådgiveraftalen d. 10 august 2011 [(L2) HLA m.fl] var stien lagt for et funktionelt arbejde, hvor der fra start var indtænkt de kontraktlige forudsætninger, der skulle være mellem bygherre og konsortiet, men også mellem parterne i konsortiet. Heri blev der også indskrevet de nøglepersoner, heriblandt projektleder fra bygherre, projektleder fra rådgiver (HLA), projekteringsleder (HLA) og sagsarkitekt (HLA). Derudover indebar aftalen også de tidsfrister der skulle overholdes og de økonomiske grundlag for opgaven. Hvis man skal have anvendelsen af IKT i mente, blev der også udspecificeret de før beskrevne IKTspecifikationer (afsnit 2.1.3). De blev lavet for, at man mellem de to arkitektvirksomheder havde et fælles grundlag. De indebar den digitale kommunikation, software og modellering af den objektbaseret model. Hvor man f.eks. aftalte man skulle anvende Revit Architecture. Det var dog en længerevarende procedure at blive enige, som fik konsekvenser senere i processen. Da konsortiet blev dannet, kom FM og HLA med helt forskellige kompetencer inden for brugen af BIM og Revit. FM var begyndt at anvende modelleringsværktøjerne i Revit siden 2008, hvor stort set alle medarbejderne havde været på et 3 dages kursus i de grundlæggende trin i Revit. Men pga. krisen havde det været nødvendigt at ligge programmet på hylden. De havde dog nået at anvende Revit på 6-7 mindre projekter. Her havde de lært programmet og skabt sig nogle erfaringer til at anvende programmet til modellering og den databehandling af informationer der lå bag det. Dog var Herlev Hospital deres første store sag hvor det skulle anvendes på [(I2) 04:54-5:17]. HLA s udgangspunkt var anderledes. For dem var Herlev Hospital første gang de skulle bruge Revit, og havde ingen kendskab til programmets arbejdstilgang. I forhold til honorarfordelingen var det HLA s opgave at udspecificere IKT-specifikationerne [(I2) 17:15-18:40]. Men da de ingen erfaring havde i anvendelsen af IKT sammen med Revit, var det først og fremmest nødvendigt at uddanne en medarbejder til BIM-koordinator. Men da der heller ikke var andre der havde erfaring med brugen af Revit, blev en stor del af de implicerede medarbejdere, ved projektet, sendt på kursus i brugen af Revit. Men som man tit ser, vil man kunne opleve en vis form for skepsis, når man bliver stillet over for nye arbejdsmetoder. Og dét så man også hos HLA, der før havde anvendt tegneprogrammet Microstation 8. Derfor startede samarbejdet så lavt som det overhovedet kunne, hvilket gav store bekymringer hos FM, da man så at HLA ikke havde den nødvendige viden til at fokusere på de rigtige områder [(I2) 1:01-1:44]. På et af de sidste kurser skulle der også besluttes hvordan anvendelsen af IKT skulle foregå, hvor repræsentanter fra FM deltog. Selvom HLA havde samlet sig en basal viden angående brugen af BIM og Revit sammen, havde de stadig vanskeligheder med at færdiggøre nogle af IKT-specifikationerne. De var dog ikke interesseret i at få hjælp udefra bl.a. fordi honorarfordelingen var blevet fastsat. Til tider lyttede de til FM, men i de fleste tilfælde ønskede de at finde deres egen metode til tingene, da det CITAT Det var til tider ligesom at snakke med nogle der ikke kunne sproget -Udtalelse angående at blive enige om en BIM-manual Henrik Hansen, Friis & Moltke. [(I2) 4:42-4:54] 8 Microstation er et CAD program fra Bentley Systems til at tegne i 2D og 3D. Mens man arbejder i samme fil og udvinder sine tegninger mv. i Revit. Er ens model delt op i flere modeller i Microstation, hver gang du generere en tegning i Microstation bliver den eksporteret til sin egen fil. 20 S i d e

26 2.0 Hoveddel 2.2 De korrekte krav til anvendelsen af IKT var en del af deres læringsproces. Derudover var der også et økonomisk aspekt i form af honoraret de ikke ønskede at miste. Selv om det skabte frustrationer hos FM, at de til tider ikke kunne blive enige. Så så de det som meget naturligt og kunne sagtens forstå det. For dem der havde opgaven prøvede selvfølgelig at løse den så perfekt som muligt [(I2 18:57-19:20)]. Det gav dog hurtigt diskussioner i samarbejdet, at HLA ønskede den læringsproces. FM følte de kom med en masse erfaring, og vidste hvor man skulle lægge sit fokus, og hvor nødvendigt det var at man på flere punkter var meget specifik, f.eks. på strukturen. Her ønskede HLA at være mere åben, så det var muligt at ændre det hen ad vejen, når de havde fået noget mere erfaring [(I2) 24:19 24:50]. Ud over det, fokuserede HLA mere på layoutet, hvilket FM og HLA brugte flere måneder på at blive enige om [(I2) 4:07-4:42]. Der blev dog til sidst udspecificeret de nødvendige IKT-specifikationer, hvor den ene, IKT-teknisk CAD specifikation (pkt ), senere blev revideret til en såkaldt BIM-manual. Den blev færdiggjort sådan at man hen ad vejen kunne tilføje vigtige elementer. Det blev dog mest ved idé i stedet for handling. Man aftalte på møder gennem projekteringen, hvordan man skulle gøre tingene, men de blev sjældent skrevet i manualen, hvilket medførte man glemte de ting der var blevet aftalt. CITAT Det er helt grundlæggende svært for to arkitekttegnestuer at arbejde sammen, man har forskellige måder at gør tingene på. Noget af det er selvfølgelig branchespecifikt. ( ) Det man gør i det ene firma, er lige så rigtigt som det man gør i det andet firma. Og hvis de to firmaer ikke er villige til at ændre arbejdsmetode, så får man ikke et særlig godt samarbejde, så det kræver man er omstillingsparat og er ovre det personlige. Henrik Hansen, Friis & Moltke. [(I2) 32:03-33:15] Manualen blev lavet for at give en mere specifik beskrivelse af hvordan man skulle udnytte bygningsmodellen, men ligeledes hvordan man overhovedet skulle anvende modellen. I det første lange stykke tid, var der meget forvirring i at gå fra Microstation til Revit. Det medførte også at hos HLA, valgte man at holde fast i Microstation til at udføre deres skitsering, som efterfølgende blev tegnet over i Revit af medarbejdere, der havde fået styr på brugen af Revit. På den måde, kunne de holde flere medarbejdere beskæftiget på sagen. Hos FM så man det som en nødvendighed, men også en naturlig proces. Ellers kunne det have medført at projektet måske var gået i stå. Løsningen betød, at der blev brugt dobbelt så lang tid [(I2) 20:10-20:50]. Når man læser manualen igennem, bemærker man også tydeligt at der har været behov for at definere brugen af Revit ret tydeligt, og man har haft med medarbejdere at gøre, der er begyndt på begynderniveau. Størstedelen af manualen er blevet brugt til at definere selve strukturen bag anvendelsen af Revit. Det gælder bl.a. navngivningen af modellerne, hvor filerne lægges på byggeweb og selve layoutet af tegninger. Selve disciplinen bag brugen er også defineret klart og tydeligt i manualen. Men hvis man dykker ned i rapporten, finder man flere punkter hvor det har været nødvendigt at komme med klare definitioner på fagudtryk fra Revit. Det kan indikere, at der har været medarbejdere på sagen der ikke har haft den nødvendige erfaring med Revit. Det gør sig bl.a. gældende ved punkt 3.6 [(L4) Henning Larsen m.fl., 2011:23] hvor man har set det nødvendigt at give en forklaring på parameters, hvor man sammenligner med egenskabsdata. Parameters er en vigtig del af brugen af Revit, 21 S i d e

27 hvis du skal anvende programmet til mere end et ganske simpelt tegneprogram på niveau med Sketchup 9. Det gør også, at hvis man bare har en forholdsvis lav erfaring med brugen, vil man også have kendskab til anvendelsen af parameters. Samt på side 25 [(L4) Henning Larsen m.fl, 2011: 25] hvor de gør opmærksom på hvordan man skal tegne vægge. Man skal dog ikke se det som et negativt aspekt, at man har defineret flere fagudtryk fra Revit, det giver bare en indsigt i, hvor niveauet har været fra start af projektet. Når man går i dybden med de andre tekniske specifikationer. Der er blevet lavet i forbindelse med Herlev. Bemærker man dog en tydelig forskel. Hvis man f.eks. kigger på den IKT-tekniske kommunikationsspecifikation, bevidner den om, at man hos HLA har haft styr på hvordan selve den digitale kommunikation skulle foreligge, og hvordan den skulle anvendes i praksis [(L5) Henning Larsen m.fl]. De småfejl man kan finde i IKT-teknisk CAD specifikationen/bim-manualen er man helt foruden i de andre tekniske specifikationer. Det giver også en forståelse for at HLA har gjort deres arbejde. Men at de havde en alt for lille erfaring med brugen af Revit, til at de kunne sætte retningslinjer og faste rammer for hvordan man i sådan et stort konsortium skulle anvende et kompliceret tegneprogram som Revit. Som der beskrives var der mange problemstillinger i starten af projektet, og mange af dem fik lov til at ligge igennem hele projekteringen, uden der blev gjort noget ved dem. Man lærte i stedet at leve med dem, selvom de gjorde samarbejdet vanskeligere, og som fik konsekvenser i slutningen af hovedprojektet [(I2) 2:29-3:20]. Opsummering af startfasen ved Herlev Hospital: - Stor forskel i brugerforståelsen af Revit og hvordan IKT skulle anvendes. Hvilket gav store udfordringer for begge parter. - Stor uenighed om hvordan anvendelsen af IKT skulle struktureres i projektet. - Brugte kræfter på områder som havde mindre betydning. - IKT-specifikationerne er blevet lavet så enkle som muligt, så man kunne udnytte den udvikling der ville opstå gennem projektet. - Flere af de tekniske specifikationerne har været mangelfulde fra start (man har ikke fået fuldt op på dem som det ellers var meningen). - Begge firmaer havde svært ved at gå på kompromis med sine egne intentioner om brugen. - Generelt var retningslinjerne for modellering i Revit for dårlige ift. hvor stort et projekt man havde med at gøre. (IKT-Teknisk CAD specifikation/bim-manual) Mange af de bekymringer man havde i opstartsfasen på modelleringen viste sig at være korrekte. Da man gik ind i de sidste måneder af for- og hovedprojektet. Blev intensitet af modelleringen forøget, hvilket forårsagede et stort pres på brugen af modellerne. I korte træk indebar det, at man sad alt for mange mennesker i alt for store modeller. Selvom man både hos FM og HLA sad på computere der med lethed levede op til systemkravene 10 til Revit. Oplevede man at modellerne nåede en størrelse på over 200 mb, hvilket gjorde at de blev ekstrem sløve, og man kunne spilde op til en times arbejde om dagen, på at komme rundt i den model 9 Sketch up er et forsimplet gratis tegneprogram der udmærker sig ved, at det er forholdsvis nemt at gå i gang med ift. til andre professionelle tegneprogrammer såsom Revit og Archicad. 10 Multicore Xeon or i-series processor or AMD equivalent with SSE2 technology, 16 GB RAM, DirectX 11, Nvidia Quadro Graphic Card [Autodesk.com] 22 S i d e

28 2.0 Hoveddel 2.2 De korrekte krav til anvendelsen af IKT man ønskede. Derudover låste man ofte for hinanden når der skulle synkroniseres til centralfilen 11. Ud over en lang ventetid, resulterede det også i at knuden af medarbejdere, kunne blive så lang at flere måtte lukke deres program ned uden af få synkroniseret og gemt sit arbejde. Man prøvede at komme problemerne til livs ved at afholde ugentlige Revit koordineringsmøder. Her drøftede man brugen, og prøvede at finde løsninger der kunne virke her og nu. Alle problemerne kulminerede dagen før deadline. Da man mødte ind om morgenen virkede centralfilen ikke, og man var kommet til at gemme oven i back-up filerne. Centralfilen/modellen var blevet korrupt, hvilket man tror skyldes den overbelastning af forskellige brugere der arbejdede på tværs i modellen. Dvs. man sad nu to tegnestuer og kunne stort set ikke komme videre med projektet. 12 timer senere havde man endelig fået løst problemet, men man havde mistet vigtig tid, hvilket også resulterede i at man overskred deadline tidspunktet med næsten en hel dag. En af grundprincipperne i BIM er at optimere byggeprocessen og fjerne spildtid i projekteringen, men i dette tilfælde virkede det fuldstændig modsat. Hvad der virker som almindelige fejl i processen, kunne have været undgået hvis man fra start i projektet havde sat retningslinjer, for hvordan modelleringen og brugen af tegneprogrammet skulle bruges. Hvilket også er noget af det, man har fuldstændig undgået i BIM-manualen. Som skrevet tidligere, er der tydeligt beskrevet hvordan navngivningen af modellerne skal foregå, og hvor de skal lægges mv. Men der mangler simpelthen nogle retningslinjer for modelleringen i de objektbaseret tegningsmodeller. Da man tilbage i opstartsfasen havde diskuteret hvordan modellerne skulle bygges op. Havde man ment det kun var nødvendigt at dele projektet op i to delinger, hvad der svarer til cirka m 2 pr model, hvad der senere viste sig at fylde mere end 200 mb pr. model. På flere af landets tegnestuer, har man en regel der siger en model ikke må overskride m2 pr. model [(I2) 43:35-45:16] [(I1) 21:21-22:17] Hvilket også klart viser en indikation om, at HLA ikke på dette punkt havde de kompetencer der var nødvendige, for at definere de rammer der skulle gælde når det kom til de digitale bygningsmodeller. Det er svært at sige hvem der bærer skylden for at visse ting i samarbejdet mislykkedes. Først og fremmest sad projekteringsledelsen og skulle koordinere anvendelsen af IKT og man må desværre sige at de på flere punkter mislykkedes, ikke på selve opfyldelse af IKT-kravene, hvis man diktere 6 og 7 (digitale bygningsmodeller i projektkonkurrence og projektering). Bekendtgørelsen foreskriver f.eks. at man skal kunne anvende de digitale bygningsmodeller til parternes ydelser, og man aftaler hvilke modeller, der skal udarbejdes se bilag 6.1, 7.2. Hvilket også bliver beskrevet både i ydelsesbeskrivelsen, men også mere defineret i de tekniske specifikationer. Men i stedet for kun at leve op til myndighedernes krav, skulle man fra start have færdiggjort eller gjort CAD specifikationen/bim-manualen mere fyldestgørende, når man ser på projektets størrelse. Det havde også gjort samarbejdet bedre, og man havde været foruden de frustrationer der blev skabt internt på tegnestuerne. Som nævnt før er nogle af principperne i BIM, at optimere byggeprocessen og at genanvende data. Ved Herlev sagen, har man skabt sig et stort bibliotek af objekter der ville kunne anvendes i andre sager. Man mener at kunne anvende op til 80% af de objekter der er blevet skabt i Herlev sagen [(I2) 15:29-16:49]. Man skal derfor ikke se samarbejdet som fuldstændig mislykket og IKT-specifikationerne har helt sikkert været med til at danne nogle rammer man har kunne arbejde indenfor. Men 11 Hvis der var flere der skulle synkronisere på en gang, kunne man komme til at låse for hinanden, og man kunne kun løse problemet ved, at finde den rigtige rækkefølge i medarbejdere der skulle synkronisere ift. hvornår de havde trykket på synkroniseringsknappen. 23 S i d e

29 desværre må man også erkende, at hvad der skulle have optimeret processen, havde den direkte modsat effekt. Både fordi man skulle skabe et samarbejde, hvor der til tider var langt mellem at være enig. Samtidig med man traf nogle beslutninger der fik store konsekvenser senere i processen. Man skal dog huske på at projekteringen startede op i 2011, hvor ved at de nye og mere overskuelige IKT-bekendtgørelser samt revideret specifikationer ikke var trådt i kraft. Det er derfor svært at vide om det havde hjulpet på samarbejdet, og om det overhovedet havde ændret noget. Da de problemer der opstod mest af alt har omhandlet ansvarsrollerne ift. at definere specifikationerne og forstå hvordan man anvender Revit på den bedst tænkelige måde, når man har med sådan en stor sag at gøre. Opsummering af Casen - Den store forskel i brugerforståelsen fik den indflydelse, at BIM-manualen til tider blev mere til digitalt talerør til brugen af Revit, end et værktøj til at fremme samarbejdet. - På sådan en stor sag som Herlev, er det nødvendigt at have stor kendskab til et kompliceret tegneprogram som Revit, for det er muligt at fastsætte retningslinjer. - Selvom man gennem rådgiveraftalen, ydelsesbeskrivelsen, IKT-ydelsesspecifikationen og de IKT-tekniske specifikationer overholder kravene om anvendelsen af IKT i byggeriet, kræver det mere for at man får et mere fyldestgørende resultat i den sidste ende. - For at et samarbejde kan fungere korrekt, er begge parter nødt til at gå på kompromis med sine egne idealer og arbejde mod et samlet produkt, og ikke et produkt skabt af to parter. Egne observationer - Selvom der blev holdt ugentlig Revit koordineringsmøder, var der store problemer med at overholde de regelsæt der var sat iht. brugen af Revit. Hvilket gav mange frustrationer når man opdagede fejl i modellen, man dagen forinden var blevet enig om på et møde. - Der var ikke fastsat de korrekte retningslinjer til hvordan der skulle arbejdes med fagmodellerne. Til tider sad over 8 mennesker i samme fil, hvilke gav problemer med vi låste for hinanden. Dvs. når man skulle synkronisere med centralfilen, blev man blokeret af en anden person. Det kunne enten skyldes personen havde fået ejerskab over nogle objekter man selv havde oprettet, eller andre personer var i gang med at synkronisere. - Modelfilerne blev for store, hvilket medførte at alle modellerne blev alt for tunge at arbejde i, og man skulle passe på hvordan ens arbejde skulle foreligge, da modellen kunne få computeren til at gå i sort i flere minutter. Eller for den sags skyld lukke Revit, hvilket medførte spildt arbejde. Det skyldtes ikke fejl i software eller hardware, da det var nyt. Men i stedet forkert opbygning af modellerne. - Modellerne skulle være blevet delt op i mindre dele, så de ikke overskred en mængde på 50 mb. (I flere tilfælde kom modellerne over 200 mb). 24 S i d e

30 2.0 Hoveddel 2.3 Niveauforskelle i byggebranchen i anvendelsen af IKT 2.3 Niveauforskelle i byggebranchen i anvendelsen af IKT - Er det generelle niveau for forståelsen og anvendelsen af IKT i byggebranchen for lav til at man kan indgå i et samarbejde. I nedenstående afsnit vil der blive opstillet en diskussion om, at vi i den danske byggebranche har et forståelsesniveau, ift. anvendelsen af IKT, der gør at vi kan anvende det i et samarbejde med en anden aktør fra samme fag. Eller om forskellene blandt de danske arkitekttegnestuer er så store, at det er umuligt at opbygge et fungerende samarbejde, der vil føre til et godt slutprodukt. Der vil blive gjort brug af interviews og artikler for at redegøre for diskussionen. Om der er en samlet forståelse af anvendelsen af IKT i den danske byggebranche. Er ikke et spørgsmål man bare kan svare ja eller nej til. Hvilket casen er et godt eksempel på. Hos HLA mente man, at man havde en generel god forståelse i anvendelsen af IKT, hvilket også afspejlede sig i de fleste af deres IKT-specifikationer. Men da det kom til at udspecificere, hvordan man skulle modellere den objektbaseret model (IKT-teknisk CAD specifikation) gik det galt. Derfor handler det om meget mere end bare at kende nogle kravstillelser. Alle kan læse to dokumenter og forstå hvad der står. Men det handler også om at forstå hvordan man anvender, hvad der står. Det er svært at sige hvor langt vi er herhjemme med anvendelsen af IKT i byggeriet og om vi stiller de korrekte krav. Mest af alt fordi der mangler en definition på, hvornår man anvender IKT. Er det når man bliver stillet over for kravene fra bygherres side, eller er det når man anvender Bips IKTaftalegrundlag (IKT-specifikationerne), eller måske en hel tredje. Henover sommeren, lavede Danske Ark en undersøgelse blandt deres medlemmer [(W26) Danskeark.dk]. Ud over at undersøgelsen viste at folk mangler viden omkring IKT-kravene, viste undersøgelse også at cirka en tredjedel af de deltagende medlemmer ofte bliver stillet overfor IKT-krav. Men fordi man bliver stillet over for kravene, er det ikke ensbetydende med, man forstår dem og kan bruge dem i et samarbejde med en anden tegnestue. Men før man begynder at kigge på et samarbejde, er man nødt til at kigge på det enkelte individ. Og her ser man tydeligt en væsentlig forskel. Mange middelstore tegnestuer er først blevet ramt af IKTkravene nu, fordi anvendelsesområdet til kravene er blevet skærpet i de nye bekendtgørelser (BEK 118 og 119). Selvfølgelig er det muligt at tage en uddannelse/kursus som IKT-leder på 3 dage og derved få en ide om specifikationerne [(W28) Byggeweb.dk]. Men det er først når man har haft det mellem hænderne du begynder at få en evne til, at forstå anvendelsen af IKT. Som Kenneth Højbjerg, Bjerg Arkitektur, udtaler under interviewet. Så handler det om at samle sig nogle bitre erfaringer og finde ud af hvad man gør og ikke skal gøre [(I1) 20:22-21:21]. Han oplevede selv at komme på kursus, men det er erfaringer der giver det bedste resultat. Derfor er det også ganske klart at store og små virksomheder ikke kan have den samme erfaring. Det er ganske få tegnestuer, der frivilligt har implementeret IKT-kravene uden det har været krav fra bygherre. Derfor vil man også se et støt stigende flow af nye brugere der implementerer IKT-kravene på deres tegnestue. På samme måde er det også svært at forstille sig, at man kan opnå et lige niveau i mellem alle de danske tegnestuer. Den generelle udvikling vil altid være der, og samtidig vil man også kunne opleve at de virksomheder, der først var med på BIM-bølgen også er dem der bliver ved med at udvikle sig mest ift. resten af branchen. Det ses bl.a. hos Bjerg arkitektur. De var blandt de første tre der startede op på Revit herhjemme og har holdt en konstant udvikling med særlig fokus på at optimere den digitale energivisualisering [(I1) 25 S i d e

31 37:00-40:42]. Det har i dag ført til at de endnu engang er forgangstaler og er med i en forsøgsgruppe til at implementere Cunecos CCS klassificeringssystem. Hvis man kigger mod andre lande, vil man kunne se at England er i gang med at hæve hele branchens BIM integrering igennem et 3 trinssystem, The Next Level, hvor alle offentlige byggerier skal have nået det tredje trin, og mest avanceret trin, inden 2016 [(W30) Bips.dk]. Det er ikke noget der ville kunne lade sig gøre herhjemme. Organisationen bag udviklingen af digitaliseringen i byggebranchen er vidt forskellig. Mens man ser det er staten der sætter standarderne i England er det brugerne herhjemme. Derudover findes der også et andet problem med implementeringen af IKT. Rigtig mange tegnestuer er simpelthen for uvidende om hvad der skal implementeres, og som Christian Lerche, adm direktør i Danske Ark udtaler [(W26) Licitationen.dk]. Så ses der mange uerfarne, der stiller nogle ufattelige krav. Man vil hellere stille et krav for meget end et for lidt. Hvilket også bliver støttet op af Kenneth Højbjerg, der også mener man er bange for at stille for få krav. Man frygter simpelthen man ikke opfylder lovgivningen, og derfor stiller man et par ekstra krav for at være på den sikre side. Når de ved Bjerg står for bygherrerådgivning, oplever de ofte at folk simpelthen ikke er sikre på hvad der skal med, da man er bange for at få efterregninger [(I1) 24:56-27: 31]. Man skal derfor gøre op med sig selv hvad man har behov for, og derefter holde sig til minimummet, i stedet for at gå all in. Man skal holde sig til det lavpraktiske og sørge for du overholde lovgivningen, og kigge mere på hvad der kan være værdiskabende for de medarbejdere der skal sidde på projektet. På samme måde, sikrer du også at det ikke ender med du spilder en masse ressourcer på at implementere materiale, som du i sidste ende overhovedet ikke skal bruge. Det afhænger dog af sagens størrelse, jo større projektet bliver, jo mere kompleks bliver specifikationerne selvfølgelig. Især med henblik på CAD-specifikationen, der er den vigtigste når det omhandler rå projektering [(I1) 42:33-43:54]. Hvilket man også så på Herlev sagen, da det var denne specifikation, der gav de største anvendelsesproblemer og konflikter. Men det går dog først helt galt, hvis den IKT-ansvarlige på en sag, ikke har den nødvendige kunnen, som måske kun er blevet støttet op af et IKT-leder kursus, og den vej igennem tror han forstår det hele. Det er på de tidspunkter man ofte ser IKT-aftalegrundlag hvor CITAT Hellere stille et krav for meget end et for lidt Derfor er vores frygt, at flere vil bruge anledningen til at stille unødvendige krav, så flere bliver smittede med børnesygdommene i stedet for at udrydde dem Christian Lerche, adm. Direktør i Danske Ark På mange af de store tegnestuer lever IKT-lederne på deres grå erfaringer, altså hvad de aldrig skal gøre igen. F.eks. at man aldrig kan samle en m2 bygning i én Revit model, og på den måde lærer man det til næste gang Kenneth Højbjerg Bjerg Arkitektur [20:22-21:21] alt er vinget af. Et IKT-leder kursus er en god måde at opsamle sig en viden til at forstå principperne i anvendelsen af IKT, og aftalegrundlagene. Men man skal dog være klar over, at efter et kursus på tre dage, kan man ikke løse alle de problemstillinger man kan blive stillet overfor mht. IKT. Hvis implementeringen ikke var en kompliceret proces, som man ser på flere danske tegnestuer, ville det ikke være et problem der skulle belyses [(W28) Byggeweb.dk]. 26 S i d e