WORKFLOW I BYGGERIET

Transkript

1 WORKFLOW I BYGGERIET IKT OG DATAUDVEKSLING GRUPPE: BI-13:72 SEMESTER: 2. Semester DATO: STED: Aalborg Universitet Rapport om workflow i byggeriet mellem projekterende, samt brug af IKT- og dataudvekslingsværktøjer. Udarbejdet på 2. semester, Bygningsinformatik Aalborg Universitet

2 Workflow i Byggeriet IKT og Dataudveksling 2012, Aalborg Universitet, School of Engineering and Science 2. semester, Cand.scient.techn. i Bygningsinformatik Udarbejdet af: Allan Svabo Jónsson Nikolaj Stephansen Bjarke Kristensen (Aaron Widdicombe) Daniel Nielsen Søren Christensen Søren H. Sternkopf Vejledere: Kjeld Svidt, Aalborg Universitet Rapportomfang: Sidetal: 114 Bilag: 2 stk. 19 sider i alt. Afleveringsdato: Forsideillustrationer: Bill Rounds ESQ. Golkin Oleg.

3 Forord Bygningsinformatiklinjen på Aalborg Universitet, er en overbygning på kandidatniveau tilegnet professionsbachelorer inden for byggeri og anlæg. Kandidatuddannelsen beskæftiger sig hovedsageligt med digitale værktøjer, samt digitalt informationsflow i bygge- og anlægssektoren. Denne rapport er et projekt, udarbejdet på 2. semester af informatiklinjen, skrevet af et projektteam på 7 personer. Rapporten er udarbejdet i efteråret, fra september 2012 til december Rapporten er skrevet med det formål, at belyse og løse, bestemte problemstillinger ifm. en konkret byggecase, hvor digitale værktøjer til dels har været anvendt. Hensigten er, at interesserede kan sætte sig ind i problemstillinger fundet og afhandlet i rapporten. Dette omhandler brugen af informations- og kommunikationsteknologi, samarbejdsformer og arbejdsmetodikker, samt levering og håndtering af digitale data. Denne rapport er tilsigtet arkitekter, ingeniører, konstruktører, byggebranchen som helhed, firmaet E. Pihl & Søn A/S, som har stillet den konkrete case til rådighed, samt aktørerne på byggeriet NavitasPark. Rapporten tager udgangspunkt i byggeriet NavitasPark, hvilket i skrivende stund, er under opførelse på de bynære havnearealer i Århus. E. Pihl & Søn A/S står for totalentreprisen på byggeriet. I forbindelse med udarbejdelsen af denne rapport, har diverse samarbejdsparter været inddraget. Der siges tak til: E. Pihl & Søn A/S, for levering af casen samt samarbejdet herom, indbefattende levering af informationer omkring organisationen, div. arbejdslister, udlevering af bygningsmodel og opstilling til interviews. Alectia A/S, for opstilling til interviews. Kjaer & Richter A/S, for opstilling til interviews. Ole Daniels og Jesper Nørgaard fra AAU, for opstilling til interview. Bygherre Niels Chr. Sidenius Adm. Dir. Incuba Science Park, for opstilling til interview. Københavns Ejendomme for at tilgængeliggøre IKT-aftalegrundlag. Fra Aalborg Universitets Institut for Byggeri og anlæg, skal siges tak til: Lektor Kjeld Svidt, for rådgivning og vejledning i forbindelse med det samlede projektarbejde. Ud over ovennævnte har flere fagfolk inden for området ydet videnskabelig assistance under rapportens udarbejdelse. Hermed bringes en oprigtig tak til samtlige bidragsydere. På vegne af gruppe BI-13:72 Aalborg Universitet: Allan Svabo Jónsson, Bjarke Kristensen, Daniel Nielsen, Nikolaj Stephansen, Søren Christensen, Søren H. Sternkopf, (Aaron Widdicombe) December AALBORG UNIVERSITET 2012 Indledning 1

4 Abstract This semester project is conducted on the 2 nd semester of Aalborg University s master degree in Building Informatics. The purpose of this thesis is to identify the issues that occur through model and information exchange inbetween the actors in a building organization. Special focus is placed on the designing phases, and the demands of the actors. These demands are thoroughly examined, and held-together with traditional, as well as newer work methods and tools. The work is based on publications and regulations through national and international organizations such as BuildingSMART and BIPS. These standards and tools are used throughout the thesis, and are compared to the Danish building industry in the conditions that they apply. Furthermore, to build this reference, a case has been drawn in through NavitasPark in Aarhus. This thesis is addressed to people with a general knowledge of the building industry, with particular focus on the information exchange within the building process. This includes Architects, Engineers, Developers and Owners/Clients etc. In general, people who on a daily basis are affected, by the increasing information flow that occur in building projects. The general structure in Workflow i Byggeriet IKT og Dataudveksling, starts with an introduction of the case, this leads to an analysis of the issues concerning information exchange in the building process. From here the methods occurring throughout the thesis to solve the tasks are listed. The critical areas that occur in the method section, forms three main areas, each with their own proposal for the unified process of optimization. Finally a case experiment has been conducted, where several of the earlier components have been implicated. To conclude the thesis, a main conclusion and discussion has been formulated, where the problem statement is answered, as to create an understanding, and solution for possible steps to create better information exchange in the building industry. AALBORG UNIVERSITET 2012 Indledning 2

5 Resumé Dette semesterprojekt er udarbejdet i forbindelse med 2. semester på Aalborg Universitets overbygnings uddannelse i byggeri og anlæg, Cand.scient.techn. med speciale i Bygningsinformatik. Formålet med rapporten er, at identificere de problemstillinger der opstår igennem model- og informationsudvekslingen aktørerne imellem, og dermed at tilskynde til en kvalificeret diskussion for således, at danne grobund for mulige og effektive løsningsforslag. Der lægges særlig fokus på de projekterende parter i byggeriet, deres krav og behov behandles grundigt, og sammenholdes med traditionelle, såvel som mere tidssvarende arbejdsmetoder- og værktøjer. Grundlaget for rapportarbejdet er baseret på gældende publikationer og anvisninger gennem nationale og internationale instanser som BuildingSMART og BIPS. Deres standarder og værktøjer er praktisk anvendt igennem rapporten, og sat i forhold til den danske byggebranche og de forhold den er underlagt. For yderligere at skabe denne reference, er der bl.a. inddraget en case gennem NavitasPark i Aarhus, som er under udførsel i skrivende stund. Rapporten henvender sig til personer med grundlæggende viden om byggebranchen og særlig fokus på informationsudvekslingen i byggeprocessen. Det være sig arkitekter, ingeniører, bygherrer mm. som til daglig berøres af det voksende informationsflow, der optræder i byggeprojekter. Strukturen i Workflow i Byggeriet IKT og Dataudveksling indledes med en introduktion af casen, der leder videre til analysering af konkrete udfordringer ved udveksling i byggeprocessen. Herfra opstilles metodevalget for løsning af opgaven, der kontinuerligt optræder igennem rapporten. De kritiske områder der forefindes ved metodeafsnittet danner tre hovedafsnit, med hvert sit udspil til den samlede optimeringsproces. Til sidst er der udviklet et case forsøg, hvor flere af de tidligere komponenter inddrages. Afslutningsvis formuleres en hovedkonklusion og perspektivering, hvor problemformuleringen besvares således, at skabe forståelse for mulige tiltag der kan afhjælpe en bedre informationsudveksling. AALBORG UNIVERSITET 2012 Indledning 3

6 Læsevejledning Denne rapport er opbygget således, at der inden første kapitel, og selve hoveddelen af rapporten, er opsat et forord, et resumé, denne læsevejledning, samt en indledning. Ydermere findes der i slutningen af denne læsevejledning, en liste med forkortelser af diverse begreber som anvendes i rapporten. Hvert enkelt kapitel i rapporten omhandler et delemne, som indgår i en større sammenhæng ift. projektcasen og ifølge en fortolkning af Leavitt s model(for information omkring Leavitt s model, se rapportens metodeafsnit). Resultaterne fra disse delemner konkluderes til slut i rapporten til en samlet række løsningsforslag til den konkrete case. Som ovennævnt, er der til strukturering af de sammenhængende forhold i rapporten, benyttet Leavitt s systemmodel. Modellen bruges sædvanligt til at danne en systematisk organisationsudviklingsproces, samt sammenspillet mellem de forskellige delelementer. I denne rapports øjemed er modellen brugt til, at organisere delelementerne, samt bindeleddene her imellem, som beskrevet herunder. Opgavesystemet: Opgaven/formålet med rapporten er, at udarbejde et forslag til optimering af byggeprocessen vha. digitale værktøjer, hvilket eksempelvis vil kræve en bedre dataudveksling og tidligere samarbejde mellem byggeriets aktører. Opgave Struktur: For at opgaven skal kunne lade sig gøre, skal digitale værktøjer, som BIM platforme, kalkulations- og simuleringsprogrammer og andre kompatible programmer, indføres i strukturen i danske byggevirksomheder. Struktursystemet: For at implementere denne optimerede arbejdsproces, skal nye strukturformer afprøves i virksomhederne, da disse ønskers at vinde indpas i fremtidige byggerier. Derfor vil der blive uddybet yderligere omkring udbudsformer som: OPP, IPD samt Lean Construction. Struktur Teknologi: For at samarbejdsformerne kan bindes sammen med IKT systemerne, og der derved fås den bedst mulige udveksling mellem parterne, skal der udformes nye IKT aftaler, klassifikationssystemer, samt nye standarder, der kan få hele systemet til at køre sammen i en højere enhed. Teknologisystemet: For at BIM processen, og data udvekslingen skal kunne fungere optimalt, er det nødvendigt at indføre nye IKT løsninger og udvekslingsmetoder, som IFC, IDM og IFD. Teknologi - Aktører: Der skal her skabes nye forståelser for hver af aktørerne, for at de kan komme med i den nye tankegang. For at opnå dette kan der sættes nye standarder. Aktørsystemet: For at alle aktører skal kunne være med, er det nødvendigt at de har BIM kompatible værktøjer, og at medarbejderne har kendskab til anvendelsen af disse. Aktører Opgave: For at binde alle aktørerne sammen og skabe overblik over, hvilke aktører der skal have hvilke filer og modeller på hvilket tidspunkt, samt i hvilket niveau, skal der vurderes på udvekslingsmetoder. AALBORG UNIVERSITET 2012 Indledning 4

7 Struktur Aktører: For at danne et godt samarbejde mellem byggeorganisationen og aktørerne, kan der indføres nye ledelsesformer for, at få aktørerne til at tage ejerskab. De står dermed samlet med et større ansvar i projektet, hvilket vil kunne øge motivationen og dermed give større gennemsigtighed i byggeorganisationen. Teknologi Opgave: For at slutte teknologiske processer sammen med opgaven/ målet, skal der dannes nye standarder/ regler for import/ eksport til div. BIM programmer, for at give disse en bedre interoperabilitet. Der kan desuden udvikles nye værktøjer, for at få flere muligheder på banen. Ydermere kan der oprettes nye templates til, hvordan enkelte ting skal sættes op, både standardmæssigt, strukturmæssigt og programmæssigt. Nedenfor på figur 1 ses strukturen i rapporten, opsat som Leavitt s systemmodel. OPP, IPD BIM- Programmer Struktur IKT-aftaler, Klassifikationer, standarder - Dataudveksling - Optimering af processerne (BP) Opgave - Standarder/ regler for export/ import. - Nye værktøjer - Værdibaseret ledelse - Tage ejerskab -Gennemsigtighed Teknologi IFD, IFC, MVD, ERM, IKT, IDM - Måske ny template - Sprogpakke BPMN Roadmap/Process map Cuneco Informationsniveau -metode Aktører IKT-aftaler, Klassifikationer, standarder Kurser, programindkøb Figur 1. Leavitt s systemmodel, udarbejdet ifm. rapporten AALBORG UNIVERSITET 2012 Indledning 5

8 Kapitlerne, samt afsnittene i rapporten, er sat op så de følger den generelle retningslinje sat ovenfor ved Leavitt s modellen. I den generelle rækkefølge: Opgave-Struktur-Teknologi-Aktører. Arbejdet med problemområderne til casen starter i kapitel 1, hvor der gives en kort introduktion til firmaet E. Pihl & Søn A/S, samt den konkrete case NavitasPark, der er arbejdet med i rapporten. Kapitel 2 omhandler rapportens problembeskrivelse, som ved brug af LFA metodens interessentanalyse, problem/måltræ, og matrix giver en problemstilling og formulering, der arbejdes med i resterende kapitler. Valg og afgrænsning af arbejdsmetodik til rapporten findes i kapitel 3. Metoder beskrevet i dette kapitel er som følgende: LFA metoden, Leavitt s model, interviews, brugen af Quality Function Deployment (QFD) i rapporten, samt BPMN proces maps. Arbejdsmetoden (HOQ) kvalitetshuset behandles i kapitel 4. Der er i kapitlet opbygget et kvalitetshus omkring interessentbehov og ønsker på NavitasPark. I kapitlet arbejdes der med hvilke interesser der vægtes højst i forbindelse med interessenternes behov og ønsker. Der konkluderes i kapitlet, på hvilke der bedst indfrier disse behov og ønsker. Rapportens kapitel 5, omhandler nyere kommunikations- og samarbejdsformer i byggeriet. Her er blandt andet redegjort for Integrated Project Delivery (IPD), Lean Construction, Target Value Design (TVD), Offentligt Privat Partnerskab (OPP) og Partnering. Det er beskrevet hvordan disse kan bruges i forbindelse med et byggeri som NavitasPark. Dette gøres for at give gennemsigtighed i organisationen, og skabe værdi. I kapitel 6 beskrives historien bag IKT bekendtgørelserne i byggebranchen og Cuneco s klassifikationssystem CCS. Ydermere beskriver kapitlet den gældende IKT-bekendtgørelse kontra de to nye IKT bekendtgørelser i høring. Kapitlet slutter med et afsnit omkring IKT aftaler i byggeprojektet, hvor der ses på København Ejendommes (KEjd) IKT-aftalegrundlag, samt udarbejdes en IKT-ydelsesspecifikation teoretisk til brug i NavitasPark projektet. Til kapitel 6 hører den projektspecifikke IKT-ydelsesspecifikation, vedhæftet rapporten som Bilag 01: IKTydelsesspecifikation, projektspecifik beskrivelse. Kapitel 7 beskriver metoder til strukturering af data i byggeprocessen. Det beskrives hvordan en Information Delivery Manual (IDM), kan udarbejdes. Der lægges vægt på den visuelle del, Business Process Modeling Notation (BPMN), og et eksempel til denne gives i en case. Til slut i kapitlet beskrives en ny tilgang til metode og struktur for informationsniveauer, der pt. er under udarbejdelse af udviklingsprojektet Cuneco. Der gives, i kapitel 8 forslag til hvordan samarbejdet i en byggesag kan foregå via en viewer på en tablet. Det beskrives hvordan en database linkes til en webserver, hvor alle ansvarlige i byggesagen kan hente informationer. Kapitlet munder ud i et løsningsforslag til projektet NavitasPark. Til slut findes rapportens hovedkonklusion, samt en perspektivering med refleksion over rapportskrivningen. AALBORG UNIVERSITET 2012 Indledning 6

9 Praktiske oplysninger Figurer, tabeller og bilag indeholdt i rapporten, er henvist til i litteratur- og tabellister. Disse lister er at forefinde til slut i rapporten. Forkortelser: BIM: Bygnings Informations Modellering, referer til en arbejdsproces der involverer genereringen og håndteringen af digitale repræsentationer af fysisk og funktionelle karakteristika af eksempelvis en bygning. BSdd: Building Smart Data Dictionary (tidligere IFD). DBK: Dansk byggeklassifikation, klassifikationssystem udarbejdet for at sikre at alle byggeobjekter struktureres ensartet. CCS: Cuneco Classification Systems, klassifikationssystem som DBK, CCS, udarbejdes for at tilse de mangler der har været i DBK klassifikationssystemet. IDM: Information Delivery Manual, tillægskontrakt til IKT-aftalen, der udførligt beskriver hvordan dataudvekslingen i et givent projekt skal foregå. IKT: Informations og kommunikationsteknologi, IKT, er de specifikke processer i et arbejde, der indebærer kommunikation på IT-basis. IPD: Integrated Project Delivery, en platform for et tidligt og effektivt samarbejde i projekteringen på tværs af alle byggeprojektets aktører. LFA: Arbejdsmetode til at sikre at alle interessenters interesser er varetaget i produktet som udarbejdes. OPP: Offentlig privat partnerskab, rådgiver, finansielle parter og udførende etablerer et samarbejde på et givent projekt, for at optimere værdi og kvalitet. QFD: Quality Function Deployment er en metodologi, der benyttes til at definere kunde, eller interessentkrav. Metoden benyttes specifikt til, at oversætte kundekravene så disse kan danne grundlag for udviklingen af et produkt ved hjælp af et House Of Quality (HOQ). AALBORG UNIVERSITET 2012 Indledning 7

10 Indhold INDLEDNING CASEN NAVITASPARK, ET DOMICIL PÅ DE BYNÆRE HAVNEOMRÅDER I AARHUS E. PIHL & SØN PROBLEMBESKRIVELSE & -FORMULERING PROBLEMBESKRIVELSE: LFA-ANALYSE PROBLEMFORMULERING METODEVALG & AFGRÆNSNING LFA LEAVITT S MODEL INTERVIEWS QFD BPMN KVALITETSHUSET (HOQ) OG NAVITASPARK KVALITETSHUSETS RESULTAT OG KONKLUSION KOMMUNIKATIONS- OG SAMARBEJDSFORMER STYRING- OG LEDELSESFORMER INTEGRATED PROJECT DELIVERY (IPD) LEAN OG LEAN CONSTRUCTION TARGET VALUE DESIGN (TVD) SYNERGIEN MELLEM LEAN OG BIM DIGITALT UDBUD OG TILBUD: OFFENTLIGT PRIVAT PARTNERSKAB (OPP) PARTNERING DELKONKLUSION IKT-AFTALEGRUNDLAG IKT-AFTALENS HISTORIE KLASSIFIKATION IKT-BEKENDTGØRELSEN BEK IKT-YDELSESSPECIFIKATION IKT DELKONKLUSION DATAUDVEKSLING OG PROCES IDM MODEL VIEW DEFINITION - MVD BUSINESS PROCESS MODEL AND NOTATION BPMN CASE: ENERGI OG INDEKLIMAINGENIØRER, AAU AALBORG UNIVERSITET 2012 Indledning 8

11 7.5 METODE OG STUKTUR FOR INFORMATIONSNIVEAUER DELKONKLUSION SAMARBEJDE OG LEDELSE PÅ NAVITASPARK CASE: OPFØRELSEN AF NAVITASPARK DELKONKLUSION KONKLUSION PERSPEKTIVERING FIGURLISTE TABELLISTE LITTERATURLISTE BILAG AALBORG UNIVERSITET 2012 Indledning 9

12 Indledning Den danske byggesektor, søger at optimere byggeprocesser via nye digitale værktøjer og aftalegrundlag. (Regeringen, 2003) Efter et paradigmeskifte fra 2D til 3D og modelprojektering, opstår der nu nye muligheder for udveksling af informationer imellem aktører. De nye behov for vidensdeling, og hermed også mængden af informationer udvekslet, kan have tendens til at skabe frygt for tab af konkurrenceevne, samt manglende tiltro mellem byggeriets parter. Selvom den nye teknologi er tilgængelig, stilles der ikke krav til at benytte den (Økonomi- og Erhvervsministeriet, 2010), dette kan medføre mangelfulde aftalegrundlag i byggesager(herunder IKT aftaler). Manglende erfaring og viden om de nye arbejdsmetoder bevirker endvidere til at udviklingen bremses. I perioden udarbejdede Rambøll en rapport for Erhvervs- og Byggestyrelsen, hvor der måltes svigt, fejl og mangler i dansk byggeri. Målingerne blev taget i to perioder, den første i perioden og den næste i perioden Rapporten viste svigt, fejl og mangler for knap 8 mia. kr. i og godt 13 mia. kr. i I førstnævnte tilfælde var beløbet fordelt ligeligt på nybyggeri og renovering, mens hovedparten (9 mia. kr.) i vedrørte nybyggeri. I begge perioder fandtes det største omfang af svigt, fejl og mangler i ikke-støttet boligbyggeri. Årsagen til de identificerede svigt var ligeligt fordelt på problemer af organisatorisk karakter og teknisk karakter. (Erhvervs- og byggestyrelsen, 2010) Der er udarbejdet flere undersøgelser og rapporter, som behandler dette problem i byggebranchen. Af eksempler kan nævnes: Erhvervs- og byggestyrelsens rapport af 2010 der omhandler omfanget af svigt, fejl og mangler i dansk byggeri (Erhvervs- og byggestyrelsen, 2010) og som ovennævnte Rambølls rapport af Der er udviklet adskillige teorier og værktøjer, som giver løsningsforslag til dette problem. Nogle af teorierne går ud på at bruge andre styrings- og ledelsesformer end de traditionelle. Som eksempler kan nævnes den værdibaserede ledelsesform, IPD, OPP, Trimmet Byggeri (Lean) og Partnering. Med hensyn til problemer af teknisk karakter udvikles der IT værktøjer og arbejdsmetoder, der behandler disse problemer. Som eksempel på dette kan nævnes Bygnings Informations Modellering (BIM). I forbindelse med BIM lægges der op til, at der tidligt opnås en større grad af informationsdeling, som igen er afhængig af de aftalegrundlag der vælges at basere projekterings- og planlægningsarbejdet på. Her kommer en IKT aftale ind i billedet, som angiver retningslinjer for projektarbejdet. I tilknytning til IKT aftalen, kan der udarbejdes en Information Delivery Manual (IDM), som beskriver hvilke data der skal udveksles, samt hvornår de skal udveksles. Sammen med nye arbejdsmetoder og programmer, følger en usikkerhed for tidsforbrug, omkostninger, og om det er muligt, at forbedre arbejdsgange og indtjeningsmuligheder. Dette medfører, at der ofte benyttes kendte og afprøvede arbejdsmetoder, som i nogle tilfælde kan være forældede ift. nyudviklede og optimerede arbejdsmetoder. De nye informationsudvekslingsmetoder kan være med til, at sikre færre gentagne arbejdsgange i byggeprojekter, samt give større økonomisk og tidsmæssig sikkerhed på sigt. Denne rapport beskriver kommunikations- og dataudvekslingsforholdene i byggesagen NavitasPark på havnefronten i Århus. Der arbejdes med at finde løsningsforslag på problemer afdækket i denne sag, så AALBORG UNIVERSITET 2012 Indledning 10

13 eventuelle fejl, svigt og mangler kan undgås i fremtiden. Løsningsforslag tager udgangspunkt i interviews afholdt med byggesagens parter, gældende standarder i branchen mm. I rapporten gives løsningsforslag på forskellige områder, eksempelvis IKT-aftalegrundlag, udbudsformer, samarbejdsformer og dataudvekslingsspecifikationer. AALBORG UNIVERSITET 2012 Indledning 11

14 1. Casen I forbindelse med udarbejdelse af denne rapport, er der indsamlet information om samarbejdet imellem aktører, og deres aftalegrundlag indenfor IKT, samt hvordan deling af filer og modeller er håndteret. Dette for at skabe et overblik over, hvilke forbedringer der eventuelt kan arbejdes med. Den konkrete case er NavitasPark, beliggende på de bynære havnearealer i Aarhus. I det følgende introduceres byggeprojektet, samt totalentreprenør. 1.1 NavitasPark, et domicil på de bynære havneområder i Aarhus Historien om NavitasPark startede i 2008, hvor Region Midtjylland sammen med Aarhus Kommune, Ingeniørhøjskolen i Aarhus, Aarhus Maskinmesterskole og INCUBA Science Park fremlagde deres planer for et nyt videns- og innovationsmiljø, som skulle hedde NavitasPark. (Navitas Park, 2010) Med baggrund i de fælles visioner for byggeriet blev der i vinterhalvåret gennemført et planlægningsarbejde med brugerinvolvering, både individuelt hos parterne samt i den fælles byggeprogramgruppe. Resultatet af planlægningsarbejdet udmøntede sig i et byggeprogram, der blev udarbejdet af bygherrerådgiver Kuben Management. Byggeprogrammet blev beskrevet som funktionsbaserede krav, der ville give en totalentreprenør fleksibilitet til at være innovativ, og der hvor det vurderedes optimalt, blev der stillet krav til konkrete rumstørrelser. Yderligere blev der udarbejdet et byggeprogram for det offentlige parkeringsanlæg, som Aarhus kommune skulle drive. (NavitasPark, 2009) Figur 3. Skema over behov Kuben Management Figur 2. Strategisk platform for Navitas Park Kuben Management AALBORG UNIVERSITET Casen 12

15 Konsortiet valgte at fokusere på købet af en byggegrund af Aarhus kommune på den nordlige bastion, ved de bynære havnearealer. Her kunne NavitasPark opføres som et samlet bygningskompleks på ca m 2. Projektet skulle opføres i en totalentreprise efter et totalentrepriseudbud, hvor der skulle være fokus på pris, arkitektur og funktionalitet. Aarhus kommune ville i tilknytning til byggeriet opføre en p-kælder, der skulle udgøre et selvstændigt lejemål og indeholde 450 parkeringspladser. I december 2008 vedtager Aarhus byråd at sælge den nordlige bastion, på de bynære havnearealer til konsortiet. I juni 2009 bliver totalentreprisen sendt i EU-udbud med prækvalifikation af fem konsortier. 11 konsortier sender ansøgning til prækvalifikation og i oktober 2009 blev følgende fem ud af de 11 prækvalificeret til totalentreprisekonkurrencen. 1. E. Phil & Søn A/S, Arkitektfirmaet Kjaer & Richter A/S, Christensen & Co Arkitekter A/S, Marianne Levinsen Landskab A/S, Alectia 2. Hoffmann A/S, Arkitema K/S, Niras A/S 3. NCC Construction Danmark A/S, Arkitektfirmaet C.F. Møller A/S, Metopos ApS, COWI A/S 4. Enggaard A/S, Per Aarsleff A/S, Schmidt Hammer Lassen Architechts, Lund+Slaato Arkitekter A/S, Arkitekt Kristine Jensens Tegnestue, Rambøll Danmark A/S. 5. MT Højgaard A/S, Henning Larsen Architechts A/S, Schønherr Landskab K/S, Landskabsarkitekter MAA MDL, Grontmij Carl Bro A/S, Esbensen Rådgivende Ingeniører A/S. Efter at de fem hold havde indsendt deres tilbud på projektet, blev det herefter bedømt af et udvalg bestående af følgende personer. 1. Niels Christian Sidenius, adm. direktør, INCUBA Science Park 2. Ove Poulsen, rektor, Ingeniørhøjskolen i Aarhus 3. Anders H. Sørensen, rektor, Aarhus Maskinmesterskole 4. Carl Nielsen, direktør, Aarhus Kommune, Teknik og Miljø 5. Kent Martinussen, fagdommer 6. Lars Juel Thiis, fagdommer 7. Bo Andersen, fagdommer Tildelingskriterium blev angivet som: Det økonomisk mest fordelagtige tilbud med følgende underkriterier: Kvaliteten af det tilbudte løsningsforslag der vægtes med 70 % Pris der vægtes med 30 % Underkriteriet kvalitet indebar en vurdering om løsningsforslaget kunne opfylde udbudsmaterialets visioner og krav til: arkitektur, funktionalitet, udnyttelsesgrad, integreret energidesign og totalentreprenørens organisationsplan/beskrivelse (vægtes mindre end de 4 førstnævnte) Underkriteriet pris, blev bedømt ud fra en pointtildeling som Bascon og Kuben havde udarbejdet. AALBORG UNIVERSITET Casen 13

16 Bedømmelsesudvalget indstillede forslag nr. 1 som det økonomisk mest fordelagtige tilbud, da det på en omfattende måde havde forstået og bearbejdet bygherrernes ønsker til NavitasPark. Forslaget blev beskrevet som en skulpturel krystal, der i sin udformning lignede en stjerne. (Navitas Park, 2010) Navitas byggeriet Navitas skal være et centrum for energi, innovation og uddannelse. Navitas er designet som et byggeri i energiklasse 1, efter 2015-normen. Der arbejdes på en certificering for bæredygtighed efter retningslinjerne i BREEAM (Building Research Establishment Enviromental Assessment Method)(Når byggeriet er færdigt afsluttes denne certificering). Derefter skal byggeriet bruges som et laboratorie for energi. Det første spadestik til Navitas-byggeriet på havnearealet i Aarhus, blev taget den 9. juni Byggeriet skal bruges af mere end studerende, undervisere, forskere og iværksættere. Tidsplan og organisation Navitas skal stå færdigt i Byggefasen er august 2011 til marts Som bygherrer af Navitas, står ingeniørhøjskolen i Aarhus, INCUBA Science Park, Aarhus maskinmesterskole og Aarhus kommune. Byggeriet vil derfor rumme de to uddannelsesinstitutioner, samt en ny forskerpark. Aarhus kommune etablerer et offentligt parkeringsanlæg i kælderen. E. Phil & Søn A/S har sammen med arkitektfirmaet Kjaer & Richter A/S, Christensen & CO A/S, Marianne Levinsen Landskab ApS og rådgivende ingeniørfirma Alectia A/S, forestået totalentreprisen på NavitasPark. Ingeniører Rambøll A/S er bygherrerådgiver. Som ovennævnt står E. Phil & Søn A/S for totalentreprisen og har egenproduktion på betonarbejde samt betonelementmontage, hvor de øvrige entrepriser er udbudt til forskellige underentreprenører og leverandører. Der er i alt 34 underentreprenører og leverandører på projektet. (Navitas Park) AALBORG UNIVERSITET Casen 14

17 Figur 4. Organisationsplan for udførelsesfasen E-Pihl og Søn A/S 1.2 E. Pihl & søn E. Pihl & Søn er blandt Danmarks ældste entreprenørvirksomheder. E. Pihl blev stiftet af murermester Lauritz Emil Pihl i 1887, og virksomheden voksede sig hurtigt til en af hovedstadens førende murermesterforretninger. I 1916 indtrådte sønnen Carl i firmaet, som herefter blev kendt under navnet E. Pihl & Søn. I 1947 købte civilingeniør Kay Langvad halvdelen af virksomheden, som herefter bevægede sig over til at være en rådgivende ingeniørvirksomhed såvel som entreprenørvirksomhed. Virksomheden er vokset til, at være blandt de 225 største internationalt opererende entreprenørvirksomheder og beskæftiger ca medarbejdere. Arbejdsopgaverne spænder bredt fra store infrastrukturprojekter til vandbygning, kraftværker, domicilbyggeri og renovering. Virksomheden har egen projekteringsafdeling, hvor egenproduktionen består af beton-, murer-, tømrer- og malerarbejde. E. Pihl & Søn har hovedkontor i Kgs. Lyngby. Organisatorisk er virksomheden bygget op med en bestyrelse på seks personer, en direktion med en adm. direktør, en underdirektør samt en direktionssekretær. Dernæst er der en kvalitetsstyrings- og miljøafdeling og en arbejdsmiljø- og sikkerhedsafdeling. Produktionen indeholder tre afdelinger: Danmark, som tager sig af de hjemlige projekter og Udland I og II, der tager sig af de mange udenlandske projekter. Herudover har de en række datterselskaber i forskellige lande, bl.a. USA, Storbritannien, Island mfl., og er med i OPP projekter samt flere konsortier. Hertil har AALBORG UNIVERSITET Casen 15

18 virksomheden er række støttefunktioner, disse er bl.a. en teknisk afdeling, økonomiafdeling, juridisk afdeling og flere. Der henvises i øvrigt til organisationsdiagrammet på figur 5 (E. Pihl & Søn A/S) Figur 5. Organisationsdiagram for virksomheden E. Pihl & Søn E. Pihl & Søn (E. Pihl & Søn, 2012) AALBORG UNIVERSITET Casen 16

19 2. Problembeskrivelse & - I dette afsnit findes en oversigt over de problemområder, der behandles i denne rapport. Analysemetoden LFA (Logical Framework Approach) er benyttet til at analysere problemområderne samt aktiviteter, der kan benyttes til løsning af disse problemer. Afsnittet indeholder en problembeskrivelse, en LFA analyse, den analyserede problemstilling, og endeligt problemformuleringen, som opgaven tager udgangspunkt i. formulering 2.1 Problembeskrivelse: Gennem interviews med E-Pihl og Søn, totalrådgivere på byggeprojekt NavitasPark i Aarhus, samt gennem indsamling af oplysninger i empirien, er det afdækket, at NavitasPark varetages af adskillige entreprenører, underentreprenører, rådgivere, leverandører m.m. Hvoraf alle har brug for særlige informationer og modeller ifm. deres arbejdsområde samt, at disse informationer leveres rettidigt parterne imellem. Nedenstående problemstillinger er blevet identificeret ude på pladsen efter interview med entreprenørvirksomheden E. Pihl & Søn, som forestår totalentreprisen. Der arbejdes med byggeprocessen som helhed og med særlig fokus på brug af digitale værktøjer og samarbejdsformer. 1. De forskellige aktører er tilbageholdende med at dele og anvende diverse digitale arbejdsfiler med hinanden. 2. De forskellige aktører er usikre på, hvor meget de bør skrive under på ift. IKT aftalen. Derfor bliver kontrakten for generel, og anvendes ikke i ønsket grad. 3. Jf. bygherrekravene i bekendtgørelse 1381 pålægges de statslige bygherrer at stille krav om IKT i deres byggerier. NavitasPark hører inde under denne kategori, og det er nødvendigt for de forskellige aktører at efterleve kravene. Dette er dog ikke sket problemfrit, og det bemærkes, at der er behov for en anden tilgang til denne type projekter. 4. Aktørerne har tendens til skepsis overfor hinandens måde at arbejde på med modelarbejde og vidensdeling-/ håndtering. F.eks. forsøges det at låse modeller således, at modtageren ikke kan lave fejlagtige ændringer. Dette resulterer i, at modtageren får svært ved, at arbejde videre med modellen f.eks. trække mængder ud etc. 5. De faggrupper, som skal bruge data til videre bearbejdning er usikre på, hvor megen information de skal have, før de sidder med selve arbejdet foran sig. Dvs. at der er behov for klare retningslinjer i form af BPMN Process-maps og ERM (Exchange Requirement Models). AALBORG UNIVERSITET Problembeskrivelse & -formulering 17

20 6. Der arbejdes overvejende med en traditionel tilgang til nye projekter, og der tages udgangspunkt i Par & Fris ydelsesbeskrivelsen. Denne er dog ikke optimeret til brug af IKT-aftalegrundlaget, da den kun giver meget generelle fællesguidelines. 7. Mange af aktørerne er på forskellige IT tekniske niveauer, og arbejder sjældent i de samme programmer (f.eks. Revit og AutoCAD). Herved stiller dette store krav til formaterne filerne deles i, så alle kan tilgå dem og arbejde videre med indholdet. Ifm. Rapporten ønskes der igennem en analyse af problemerne, at skabe løsningsforslag der kan afhjælpe disse problemer i NavitasPark s organisation. Første del af analysegrundlaget i forbindelse med NavitasPark byggeriet, udføres som Logical Framework Approach (LFA). Hvilket beskrives i afsnit 2.2. AALBORG UNIVERSITET Problembeskrivelse & -formulering 18

21 2.2 LFA-Analyse 2. SEMESTER PROJEKT LFA analysen benyttes som grundlag til at afdække de følgevirkninger, som de afdækkede problemer kan medføre samt, at angive de mål der skal nås for løsning af problemområderne. LFA analysen indledes med en analyse af byggesagens interessenter, hvorefter et problemtræ er udarbejdet, som belyser problemerne og deres følgevirkninger. Problemtræet vendes til et måltræ, der viser hvilket produkt problemerne skal vendes til, før disse kan regnes som løst. Analysen slutter ud i en matrix, der beskriver et formål med målene, samt oplister aktiviteter til løsning af problemområderne. Rapportens problemformulering er udarbejdet på baggrund af denne LFA analyse, og beskriver hvilke af de afdækkede problemer, der behandles i denne rapport. For mere omkring LFA, henvises til rapportens metodeafsnit. Interessentanalysen Interessenter Bygherre Projekterende og udførende Bruger Indvirkning på interessenten (Dyrere) og længere byggeri Flere skjulte byggefejl kan forekomme Flere fejl under byggeriet Større risiko for dagbøder som følge af forsinkelser Behov for yderligere investering i personel og deres efteruddannelse Længere byggeperiode, derved senere ibrugtagen Deltagelse i løsningen af problemet Relationer til andre interessenter Kan ikke direkte deltage i løsningen af problemerne på den konkrete sag Vil lægge pres på byggeaktører, for at imødekomme tidsplan således at brugerne kan flytte ind rettidigt Tabel 1. Interessentanalyse, udarbejdet ifm. rapporten Er højt motiveret i direkte at deltage i løsningen Vil lægge pres på hinanden for, at få de nødvendige informationer og data når de skal bruge dem Kan ikke direkte deltage i løsningen af problemerne Vil lægge pres på bygherren for, at de kan benytte faciliteterne til det lovede tidspunkt AALBORG UNIVERSITET Problembeskrivelse & -formulering 19

22 Problemtræ Figur 6. Problemtræ, udarbejdet ifm. rapporten AALBORG UNIVERSITET Problembeskrivelse & -formulering 20

23 Måltræ Figur 7. Måltræ, udarbejdet ifm. rapporten AALBORG UNIVERSITET Problembeskrivelse & -formulering 21

24 LFA-Matrix Tabel 2. LFA-Matrix udarbejdet ifm. rapporten AALBORG UNIVERSITET Problembeskrivelse & -formulering 22

25 2.3 Problemformulering I forbindelse med problemområderne afdækket i LFA-analysen kan en generel problemformulering udarbejdes: Hvordan kan dataudveksling imellem byggeaktørerne strømlines, så et bedre informationsflow i projekteringen af byggesager skabes? Ud fra casen NavitasPark og den opsatte LFA analyse er der oplistet følgende underspørgsmål til problemformuleringen: 1. Hvordan kan byggesagens organisation og samarbejdet heri forbedres? 2. Hvordan kan et mere komplet og præciseret IKT aftalegrundlag defineres? 3. Hvordan kan informationsudvekslingen mellem byggeriets projekterende aktører optimeres? 4. Hvilke nye tiltag er under udarbejdelse for at sikre, at nye IKT værktøjer tages i brug? Problemformuleringen beskriver de forskellige emner, der er fundet i forbindelse med analysen til casen. Disse emner undersøges ud fra det induktive og deduktive princip. I det induktive princip arbejdes der med at undersøge i empirien i den konkrete situation. I det deduktive princip arbejdes der med en teori og antagelse om virkeligheden. Derefter forsøges antagelsen afprøvet på konkrete observationer. AALBORG UNIVERSITET Problembeskrivelse & -formulering 23

26 3. Metodevalg & afgrænsning Under dette afsnit indgår de analyse- og arbejdsmetoder, der er brugt i forbindelse med udfærdigelsen af denne rapport. Hver analyse- og arbejdsmetode er repræsenteret i opgaven under de enkelte afsnit. De enkelte afsnit henviser til metodeafsnittet, hvor dette skønnes nødvendigt. 3.1 LFA Til analysering af problemstillinger i den konkrete case, er der i denne rapport brugt dele af Logical Framework Approach, LFA, hvilket er en metode til systematisk at planlægge og monitere projekter. I LFA metoden arbejdes med en grundig problem- og målanalyse, mens løsningerne udledes heraf i stedet for, at starte et givent projektarbejde med løsningsudvikling. LFA Metoden kan inddeles i en række faser. Faserne kan opfattes, som udgørende et proces forløb med mulighed for at springe tilbage i forløbet. LFA proceduren fremgår af figur 8 (Anlægsteknikforeningen i Danmark, 2011) Analyse Beslutning om projektmål og stradegi Projektbeskrivelse Forudsætninger og risici Erfaringsopsamling Planlægning af tid, organisation og økonomi Gennemførsel og opfølgning Beslutning om gennemførsel Konsekvensvurdering Figur 8. LFA proceduren i hovedtræk Anlægsteknikforeningen Den første del er analysefasen, som består af: problematiserende beskrivelse, interessentanalyse, problemanalyse og målanalyse. I den næste fase besluttes, om de opsatte mål er acceptable, ellers må processen gå om. Når projektmålet er besluttet, foretages en videreudvikling og beskrivelse af projektet, indeholdende projektets formål, projektets mål og projektets produkt. Denne fase suppleres med en gennemgang af de væsentlige forudsætninger og risici. Når projektet er beskrevet, kan aktiviteterne danne basis for en overordnet implementeringsplan, hvori der skal tages stilling til organisation og projektbudget. Herefter udarbejdes en konsekvensvurdering i rapportform, med indstilling, til hvorvidt projektet bør gennemføres. Til slut kan ledelsen tage den endelige beslutning om projektets fremtid. AALBORG UNIVERSITET Metodevalg & afgrænsning 24

27 Hovedområderne brugt af LFA proceduren ifm. udarbejdelsen af denne rapport ligger i de første områder omkring analyse, projektmål, strategi og projektbeskrivelse. For mere information omkring LFA henvises til Anlægsteknik 2. (Anlægsteknikforeningen i Danmark, 2011) 3.2 Leavitt s model Leavitt s model bruges som organisationsudviklingssystem, til at holde de 4 delemner (Opgave, Struktur, Teknologi og Aktører) i et projekt op mod hinanden. Dette for at se om det er muligt at optimere delemner i en organisation, uden at demotivere andre. De forskellige systemer er beskrevet herunder: Opgavesystemet: omfatter virksomhedens hovedopgave. Dette kan også være en af virksomhedens underfunktioner, som salg, produktion osv. Figur 9. Leavitt s systemmodel Anlægsteknikforeningen Struktursystemet: omhandler hvordan arbejdsfordelingen i organisationen hænger sammen, samt hvordan kommunikationen heri fungere. Teknologisystemet: Teknologi er de hjælpemidler der bliver brugt til at løse organisationens opgaver, herunder kan refereres til produktionsteknologi, fremstillingsteknologi, styringsteknologi og informationsteknologi. Aktørsystemet: er de mennesker der er ansat i firmaet. Hensigten med modellen, er at undersøge samspillet mellem de forskellige delemner i en virksomhed. Derfor er denne blevet brugt som en sammenholdende struktur i rapporten, for at vise hvordan de forskellige kapitler hænger sammen. (Anlægsteknikforeningen i Danmark, 2011) AALBORG UNIVERSITET Metodevalg & afgrænsning 25

28 3.3 Interviews 2. SEMESTER PROJEKT En del af informationsindsamlingen og -håndteringen i forbindelse med udarbejdede rapport, sker ved brug af det deduktive princip 1, herunder den kvalitative metode.(se nedenstående afsnit: det kvalitative forskningsinterview) Interviews udføres efter Kvale s tilgang til de syv faser af en interviewundersøgelse. (Kvale & Brinkmann, 2009) De syv faser er opstillet således, at disse giver intervieweren et grundlag for udførelsen af et struktureret og velovervejet interview. De syv faser er opdelt som følgende. 1. Tematisering 2. Design 3. Interview 4. Transskription 5. Analyse 6. Verifikation 7. Rapportering (Kvale & Brinkmann, 2009) Nedenstående oplistes tilgangen til disse syv faser ud fra viden beregnet til denne rapport. Tematisering: Tematiseringen af interviewet sker, som det første ifm. de konkrete interviews i rapporten. Ifm. tematisering af rapporten, henvises til LFA-modellen tidligere omtalt i dette kapitel. Design: Inden interviewet afholdes, planlægges spørgsmålene, så de vil kunne give den tilsigtede viden, og hvordan denne skal analyseres, så den er brugbar. Interview: Det konkrete interview gennemføres ud fra en reflekteret tilgang til den søgte viden citat (Kvale & Brinkmann, 2009). Her tages i betragtning, hvilke personer der interviewes samt, hvilken viden de kan forventes at besidde. Fortrinsvis vil interviewene i rapporten, stilles til elitepersoner eller personer med høj faglig viden og erfaring. Transskription: Interviewet klargøres til analyse, og omdannes fra talesprog til skreven tekst. Analyse: På basis af undersøgelsens formål afgøres hvilken analysemetode, der bedst egner sig til interviewene. Verifikation: Her fastlægges hvilke informationer tilegnet igennem interviewene, der kan bruges til undersøgelsen. Rapportering: Resultaterne fra undersøgelsen, samt anvendte metoder skrives til et læseværdigt produkt citat. (Kvale & Brinkmann, 2009) 1 Deduktion: Logiske konsekvenser af en generel lovmæssighed AALBORG UNIVERSITET Metodevalg & afgrænsning 26

29 Det kvalitative forskningsinterview. Hoveddelen af de interviews der udføres i forbindelse med denne rapport, udføres som kvalitative forskningsinterviews. Dette grundet et ønske om ekspertviden inden for de emner rapporten ønsker at afdække, samt de interviewedes respektive arbejdsfunktioner. Det kvalitative interview bygger på en filosofi om, hvordan viden opnås, og hvad viden består i. Dette kaldet Epistemologi 2. (Kvale & Brinkmann, 2009) Forskningsinterviewet laves med henblik på at konstruere ny viden. Da interviewenes formål er faktuel information arbejdes der med en spørgeteknik, der ikke kan opfattes tvetydigt. Dette baserer sig på interviewerens spørgsmål og interviewedes svar herpå. De syv hovedtræk ved interviewbaseret viden formuleres som. Viden er relationel, samtalebaseret, kontekstuel, sproglig, narrativ og pragmatisk eller handlingsorienteret For detaljeret gennemgang af de syv hovedtræk, henvises til Kvale s arbejder med interviewforskning. (Kvale & Brinkmann, 2009) 3.4 QFD QFD (Quality Function Deployment) er en metodologi der benyttes til, at definere kunde eller interessentkrav. Metoden benyttes specifikt til at oversætte kundekravene, så disse kan danne grundlag for udviklingen af et produkt. (Nicholas & Steyn, Project management for Engineering, Business and Design, Fourth edition, 2012), QFD benyttes bl.a. af virksomheder der ønsker at blive Six Sigma certificeret, eller som bruger denne metodologi til at forbedre kvaliteten i virksomheden. (QFD Online, 2010) (Evans & Lindsay, 2011) Hvor LFA i denne rapport anvendes til, at analysere hvordan opgaven kan løses på projektplan benyttes QFD til at afklare hvilke krav, samt hvilke ønsker de projekterende interessenter på NavitasPark har, eller ønsker til projektmaterialet. Dette gøres med henblik på at definere arbejdsmetoder, eller aftalegrundlag, der sikrer de projekterende færre gentagne arbejdsgange i projektet. Så der herved er mulighed for at spare både tid og penge på projekteringen. House of Quality Figur 10, viser den principielle opbygning af kvalitetshuset, som bruges til, at definere vigtigheden af diverse funktioner eller krav i forhold til kunden. Kvalitetshuset er opbygget af en række matrixer, kort beskrevet i følgende tekst. Kundens behov, også betegnet som HVAD i huset, beskriver kundens specifikke behov, hvor relevansen af hvert analyseres. Kundens HVAD bliver holdt op mod forskellige designfunktioner, tekniske krav, eller funktioner i produktet, også kaldet HVORDAN. Disse indbyrdes forhold sammenlægges for, at finde den totale relevans eller vigtighed af produktets emneområder. De forskellige funktioner holdes op mod hinanden i en korrelationsmatrix for, at se de enkelte tiltags påvirkning på hinanden, enten positivt eller negativt. Til sidst sammenlignes forholdene, så en kundeopfattelse kan analyseres, og de forskellige tiltag, eller aftags indflydelse på kundeopfattelsen af produktet kan aflæses. 2 Epistemologi: En gren i filosofien, som arbejder med egenskaberne, ophavet og grænserne for menneskelig viden og erkendelse. AALBORG UNIVERSITET Metodevalg & afgrænsning 27

30 Relevans/ vigtighed 2. SEMESTER PROJEKT Korrelations matrix Design eller tekniske krav HVORDAN Kundebehov HVAD Forhold mellem kundebehov og tekniske krav Kundeopfattels er Relevans/vigtighed i alt Værdier HVOR MEGET Evaluering Figur 10. Strukturen i "kvalitetshuset" House of Quality, udarbejdet ifm. rapport I forbindelse med udarbejdelsen af denne rapport, bruges en omskrevet version af kvalitetshuset. Dvs. at kundeopfattelser, samt evaluering i denne forbindelse er fjernet fra kvalitetshuset. Dette da disse to områder typisk bruges til at sammenligne virksomhedens produkter med andre virksomheder. For mere omkring QFD, og Six Sigma, henvises til QFDonline (QFD Online, 2010), Project management for Engineering Business and Technology (Nicholas & Steyn, Project management for Engineering, Business and Design, Fourth edition, 2012) og The Management and Control of Quality (Evans & Lindsay, 2011). 3.5 BPMN BPMN(Business Process Modeling Notation), er det værktøj der benyttes til udarbejdelsen af det proceskort, der skal danne grundlag for et projekts IDM. Kortet bruges til at forstå de aktiviteter der udføres i en arbejdsproces, den rækkefølge aktiviteterne bliver udført i, de aktører der er involveret i processen, samt den information der bliver udvekslet mellem aktører når aktiviteter er færdige. Ydermere kan proces-kortet identificere start og slut på opgaver i processen, opgaver hvor en udveksling af information sker samt beslutninger i processen. (BuildingSMART, 2012) (Wix, 2007) En BPMN består af fire dele, hvoraf den første er aktørerne der udfører processerne, selve processerne, forbindelser mellem processerne (disse beskriver den logiske sekvens hvori processerne opstår, eller viser overgangen mellem processer) samt artefakter, der bruges til at give mere information omkring processerne. Aktørerne bliver afbilledet som swimlanes hvori processerne og artefakterne er repræsenteret over en sekvens. BPMN bruges konkret i denne rapport til dannelse af en procesmap i forbindelse med IDM. For mere information omkring udformningen af BPMN proces-kort, henvises til BuildingSMART, samt denne rapports kapitel 7.3. (Wix, 2007) AALBORG UNIVERSITET Metodevalg & afgrænsning 28

31 4. Kvalitetshuset (HOQ) og NavitasPark Gennem interessentanalysen, problemtræet og LFA-matrixen udarbejdet ifm. rapporten, er der afdækket en række områder, hvori der kan opstilles alternativer til, hvordan informationsudvekslingen i NavitasPark projektet kunne køres, samt hvilke arbejdsmetoder der blev brugt. Der tilstræbes at udarbejde en samlet løsning bestående af tre særskilte dele, disse tre områder er som følgende: 1. Aftale omkring brug af Informations og kommunikationsteknologi i projektet (IKT-aftale) 2. IDM, Information Delivery Manual, som en del af aftalegrundlaget 3. Samarbejdsformer og kommunikationsformer, IPD, OPP, LEAN mm. I forbindelse med interviews med hhv. Ingeniør, Bygherre, Arkitekt og Totalrådgiver, er der fundet frem til en række problemstillinger, som hver part har stået med. Ét eksempel var delte holdninger til IKTaftalegrundlaget hvor den ene part mente, at aftalen ikke var udspecificeret nok, Mens den anden part mente, at aftalen var udspecificeret for meget. Et andet eksempel var, at koordinatoren fra totalrådgiveren og arkitekten måtte modellere visse ting selv, for at have en samlet model til basis for tid og prisanalyser. Der har endvidere ikke været enighed om, hvad fagmodellerne skulle indeholde af konkret information, udover at der i disse ikke måtte modelleres solids. De løsningsforslag som denne rapport munder ud i, er baseret på informationen indhentet ved disse interviews og gennem tilgængelig litteratur. Til at specificere interessenternes ønsker til optimerede processer, bruges et let omskrevet House of Quality (HOQ), kvalitetshus (som nævnt i rapportens metodeafsnit). I det traditionelle kvalitetshus arbejdes med udviklingen af nye produkter kontra eksisterende produkter i en given virksomhed, og sammenligner herefter sit produkt med konkurrentens. I sammenhæng med denne rapport, bruges kvalitetshuset til at opliste interessenternes behov og interesser, samt hvilke af disse der kan være konfliktende. Disse holdes op mod rapportens formål, samt de arbejdsområder der er fundet, ud fra LFA-analysen. For mere information omkring det traditionelle kvalitetshus henvises til rapportens metodeafsnit, hjemmesiden qfdonline.com, eller bogen Project management for Engineering, Business and Technologi (Nicholas & Steyn, Project management for engineering, business and technology, 2012) I figur 11, ses kvalitetshuset udarbejdet ifm. interviewene. Dette behandler emneområdernes sammenhæng til hinanden, deres indbyrdes forhold, samt hvor højt hvert arbejdsområde er vægtet på samlet plan. Vægten og den relative vægt af interessenternes behov/ønsker er alle sat éns, så hver interessents mening behandles som lige vigtigt. Delaktiviteterne for rapportens samlede produkt (God informationsudveksling, samt minimering af fejl, mangler og spild) kan hver især påvirke hinanden, enten negativt eller positivt. Blå plusser angiver positive korrelationer, hvor blå minusser eller pil nedad angiver negative korrelationer. Et eksempel på en positiv korrelation, er sammenhængen mellem et veldefineret IKT-aftalegrundlag, og en udspecificeret IDM. Disse to især da en IDM kan fungere som en del af et veldefineret aftalegrundlag. Et eksempel på en negativ korrelation, kan være forholdet imellem at bruge traditionelle samarbejdsformer og at arbejde med IPD, den ene udelukker som minimum en del af den AALBORG UNIVERSITET Kvalitetshuset (HOQ) og NavitasPark 29

32 Figur 11. HOQ (House Of Quality) Kvalitetshus, over interessenters behov og ønsker, tabel leveret af QFDonline AALBORG UNIVERSITET Kvalitetshuset (HOQ) og NavitasPark 30

33 anden, og det må så vælges, hvad der er mest i interessentens interesse at arbejde med. Hvert kundekrav eller interessentbehov tildeles en vægt i forhold til de respektive arbejdsområder der vedrører dem. Ved en svag relation gives en pil opad, ved moderat relation gives en cirkel og til sidst gives der ved en stærk relation en cirkel med en streg i. Disse relationer omregnes til point med hhv. 1 point for svage relationer, 3 for moderate, og 9 point for stærke relationer. Et eksempel i kvalitetshuset på en stærk relation der udgør 9 point, kan være forholdet fra totalrådgiverens og arkitektens mening om, at tidligt udbud og dataudveksling på forprojekt stadie er en fordel. Denne mening udgør en stærk relation til både IKTaftalegrundlaget, specificering af IDM samt samarbejdsformen IPD. Sidst angives sværhedsgraden af implementering af arbejdsopgaverne, der vægtes en sværhedsgrad mellem 1 og 10, hvor en arbejdsopgave vægtet et 10-tal er uhyre svær at løse, eller opnå. Eksempler på svære opgaver i forbindelse med det udarbejdede kvalitetshus på figur 10, er udvikling af bedre standarder for dataudveksling og samarbejdsformen OPP. Sværhedsgraden for nye og bedre dataudvekslingsstandarder, ligger i implementeringen af disse. Standarder kan udvikles, men brugen af disse skal spredes til og implementeres i hele byggebranchen. Nye IKT-bekendtgørelser(beskrevet i rapportens afsnit 6.3), samt Cuneco s klassifikationssystem CCS(beskrevet i rapportens afsnit 6.2) forsøger, at tage hånd om dette. OPP er en langvarig proces, og kan i flere henseender være svær at implementere på tværs af aktørerne. Det sidste kvalitetshuset viser, er den vægt og relative vægt, hver enkelt arbejdsproces har i forhold til løsning af det samlede problem. Figur 12 viser grafisk den relative vægt af hvert delområde i procent. OPP 12% Traditionelle samarbejdsformer 2% IKT-aftalegrundlag skærpes 23% IPD 19% IKT-aftalegrundlag nedtones 6% LEAN 11% Bedre standarder for dataudveksling 7% Specificeret IDM 20% Figur 12. Procentmæssig fordeling af delprodukter, ud fra data indsamlet i kvalitetshuset, udarbejdet ifm. rapport AALBORG UNIVERSITET Kvalitetshuset (HOQ) og NavitasPark 31

34 4.1 Kvalitetshusets resultat og konklusion Generelt stemmer interessenternes meninger og ønsker overens med en digitalisering af arbejdsprocessen, samt med brug af værdibaserede ledelsesformer i projektet. Blot 8 % af de samlede ønsker kan ikke løses ved brug af disse værktøjer. Her er tale om ønsker, der kan opfyldes ved brug af traditionelle samarbejdsformer, og/eller ved en nedtoning af IKT-aftalegrundlaget. Der er ud fra den udarbejdede LFA-analyse, afdækket tre hovedarbejdsområder der også tidligere er beskrevet i dette afsnit. Med udfærdigelsen af kvalitetshuset underbygges valget af disse områder. Den procentmæssige fordeling af interessenternes ønsker fordeles nedenfor på de tre punkter, og et fjerde punkt tillægges med de sidste 8 %, som denne rapport ikke behandler videre. 1. Aftale omkring brug af Informations og kommunikationsteknologi i projektet (IKT-aftale) 23 % 2. IDM, Information Delivery Manual, som en del af aftalegrundlaget 20 % 3. Samarbejdsformer og kommunikationsformer, IPD, OPP, LEAN mm. 42 % 4. Traditionelle samarbejdsformer og nedtoning af IKT-aftalegrundlag 8 % Ovennævnt fire arbejdsområder dækker over 92 % af de samlede interesser og ønsker, som interessenterne på byggeriet NavitasPark har. De to arbejdsområder der råder over de sidste 8 %, er ikke mulige at løse samtidigt med, at de øvrige 92 % løses. Det er ikke muligt at udføre et projektarbejde traditionelt, hvis der vælges at bruge IPD, OPP eller Lean, og det er til dels ikke muligt at nedtone et aftalegrundlag, hvis dette på samme tid ønskes skærpet. Undtagelsen er, hvis dele af aftalegrundlaget skærpes, og andre nedtones. Ud fra ovenstående kan interessenternes behov og interesser antages opfyldt, hvis de fire valgte arbejdsområder, implementeres i projektorganisationen. Gennem resten af denne rapport, vil der blive redegjort for områderne, og der vil blive givet løsningsforslag på, hvordan disse eventuelt kunne være indarbejdet i NavitasPark projektorganisationen. AALBORG UNIVERSITET Kvalitetshuset (HOQ) og NavitasPark 32

35 Dette kapitel arbejder med struktur- og aktørdelen af Leavitt s model, som er beskrevet i metodeafsnittet. Strukturen er en betegnelse for arbejdsdelingen og samarbejdet i projektorganisationen, samt hvordan kommunikationen foregår imellem de forskellige projekterende på NavitasPark. Der vil blive beskrevet en cyklus for nye samarbejdsmetoder, der benytter forskellige styrings- og ledelsesformer, som kan forbedre samarbejdet og kommunikationen i byggeprojekter. 5. Kommunikations- og Samarbejdsformer På NavitasPark foregik der et samarbejde i projekteringsfasen indtil hovedprojektet blev afleveret februar Arkitekter og entreprenører var samlet på samme lokation under projekteringen, der medførte hurtigere kommunikation mellem disse. I de afholdte interviews under udarbejdelsen af rapporten, bliver denne kommunikation på tværs af byggeorganisationen nævnt flere gange. Der var dog nogle problemer i samarbejdet med ingeniørerne, idet de sad i Virum og arbejdede på deres model. Dette gjorde kommunikationen med dem besværlig og tidskrævende. Under interviewene med arkitekten og totalentreprenøren blev det fremhævet, at samarbejdet med ingeniørerne gjorde at projekteringen foregik mere traditionelt. Hvorvidt dette samarbejde har skabt værdi for bygherrerne, er derfor svært at udlede af disse interviews. Pris-Tid-Kvalitet Herunder er der udarbejdet en cyklus, for hvordan OPP-IPD-Lean og BIM fungerer sammen i forhold til Pris- Tid-Kvalitet (Trekant) Etablere et samarbejde omkring: Krav, ønsker og ydelser for at skabe værdi. TID PRIS Kvalitet BIM IPD Lean OPP Figur 13. OPP-IPD-Lean i forhold til Pris-Tid-Kvalitet, udarbejdet ifm. rapport AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 33

36 Ovenstående model beskriver en sammenhæng mellem værditrekanten: Pris, tid og kvalitet som er essensen i alt byggeri. Det er denne trekant alle aktører i byggebranchen burde bruge mere tid på for, at der kan skabes værdi. Trekanten hænger nøje sammen med måden, hvorpå det vælges at samarbejde i et byggeprojekt (OPP, IPD, Lean), og hvilke værktøjer der understøtter dette samarbejde på en optimal måde. Efterfølgende beskrives forskellige styrings- og ledelsesformer, som kan optimere samarbejdet i byggeprojekter. 5.1 Styring- og ledelsesformer I byggeriet er der forskellige barrierer for innovation, kontraktstyring eller Partnering/ Værdibaseret ledelse eller en kombination af dem. Ud fra de generelle organisatoriske kendetegn, som præger den bureaukratiske og regelstyrede ledelse (kontraktstyring) kontra den værdibaserede ledelse (samarbejde/partnering), kan det sammendrages, at den værdibaserede ledelse har et positivt menneskesyn med en tillid og tro på den enkelte person, og dennes kvaliteter. Hvorimod den bureaukratiske og regelstyrede ledelse, ikke har dette positive menneskesyn. Værdibaseret ledelse tager afsæt i stor tillid til den enkelte medarbejder, der får ansvar og mulighed for at træffe beslutninger, og udvise initiativ. De handlinger som medarbejderen foretager sig, forventes til gengæld, at være præget af sund fornuft ud fra et fælles værdigrundlag vedtaget i organisationen. Denne ledelsesform foregå som en intern organisationsform, der konsekvent bruger de krav omgivelserne stiller til både de interne og eksterne interessenter. Det kan være krav til kundenærhed, kvalitet i rådgivning, omstillingsevne og lokal beslutningskompetence. (Petersen) Den bureaukratiske og regelstyrede ledelse har sine begrænsninger i at medarbejderen ikke kan/må tage beslutninger selv, men skal arbejde ud fra manualer, arbejdsgangsbeskrivelser og en lang række regler for, hvordan tingene skal gøres og ikke skal gøres. Udført arbejde skal kontrolleres for at sikre kvaliteten, og medfører ofte, at der stilles krav til kontrollørens indsigt og viden i den specifikke situation, dette kan hæmme kvalitetstjekket. Når kontrolløren skal tage en beslutning, kræver det, at han har beføjelserne til, at kunne træffe denne beslutning, som er besværlig i decentraliserede organisationer. (Petersen) Verner C. Petersen har i en skematisk form sammendraget forskellen mellem de to ledelsesmetoder. Moderne bureaukratisk ledelse kontra værdibaseret ledelse Organisationer kendetegnet ved: Lederens rolle Moderne bureaukratisk ledelse (papirledelse) Planlægger, modpart, kontrollant, beslutningstager Medarbejderstilling Hjul i maskineriet Medarbejder Form for påvirkning Planer, regler, aftaler Mål, værdier Medarbejdermål Tryghed Mening Værdibaseret ledelse (ledelse med holdning) Værdisætter, inspirator, træner og i sidste instans beslutningstager AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 34

37 Indsigt/mening Ringe Meningsfuld og med indsigt Organisering og struktur Struktureret og afgrænset, forudsigelig, entydig Flydende og overlappende, åben, flertydig Udviklingsperspektiv Statisk, fragmenteret Dynamisk sammenhængende Stillingtagen Regelbaseret Værdibaseret Problemløsning og beslutningstagning Rationel, eksplicit og regel- og metodebaseret Håndtering af etiske problemer Ud fra regler og retningslinjer Ud fra værdier Ansvarlighed Regelbaseret Personlig Baseret på såvel explicit viden, tyst viden og værdier Kvalitetsopfattelse Normer standarder, ISO 9000 etc. Omfatter også de usynlige aspekter, kvalitet som holdning Tabel 3. Organisationsteori ledelse (Verner C. Petersen), udarbejdet ifm. rapport Ud fra ovenstående kan det sammendrages, at den bureaukratiske og regelstyrede ledelse kan virke umotiverende og besværlig, da styring sker gennem regler og anvisninger, og motivation skabes gennem straf og belønning. Det bærende element i den værdibaserede ledelse er derimod motivation, som styres gennem eksempelsættende adfærd og kulturpåvirkning, og motivationen foregår gennem delegering og selvansvarlighed. Bhote beskriver flere forskellige styrings- og ledelsesformer til at optimere pris-tid-kvalitet i industrien. Herunder ses en model af de fire niveauer for samarbejde. Tabel 4. Anlægsteknik 2. side 45. Karakteristika for de fire niveauer til nirvana iht. (Bhote, 1989). Disse niveauer for samarbejde kan relateres og bruges i byggebranchen, da arkitekt, ingeniør og entreprenør agerer leverandør til bygherre. AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 35

38 Niveau 1. Rådgiver/entreprenør nærer mistillid til bygherre og fokuserer udelukkende på pris. Niveau 4. Rådgiver/entreprenør har fuld tillid til bygherre og har fokus på totale omkostninger, kvalitet, pris og tid/levering. Tabel 5. Anlægsteknik 2 side 45. Karakteristika for de fire niveauer til nirvana iht. (Bhote, 1989). Disse niveauer for styrings- og ledelsesformer kan også relateres til byggebranchen. Derfor er der udarbejdet en model med de fire niveauer, som kan bruges i byggeriet. Stadie Niveau 1: Bygherre som modpart. Niveau 2: Bygherre som Bygherre. Niveau 3: Bygherre som samarbejdspartner. Samarbejde Mistillid Mistro Delvis tillid Fuld tillid Stigning i antal og brug af rådgivere og entreprenører Ingen informationsudveksling Rådgivere og entreprenører spilles ud mod hinanden Mange rådgivere og entreprenører Begrænset informationsudveksling Forhandlinger føres med skjulte kort Mål for aftaler Pris Omkostninger og mangelsituationer Tabel 6. De 4 niveauer for samarbejde i byggerier, udarbejdet ifm. rapport Begyndende reduktion i rådgiver- og entreprenørbasen Begyndende informationsudveksling Langsigtet samarbejde Kvalitet og øget omsætning Niveau 4: Bygherre som fuldt integreret samarbejdspartner. Brug af en bestemt rådgiver og entreprenør Hyppige besøg, know-how og teknisk hjælp Fælles målrettet omkostningsreduktion Totaleomkostninger Kvalitet, pris, tid. AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 36

39 Herunder en model for styring/ledelse i byggebranchen. Styring/ledelse. Eksempler på fælles udviklingsopgaver Traditionel styring/ledelse Logistik ikke fastlagt. Mange gentagne arbejdsgange 100 % kvalitetskontrol Ingen eksempler Fagentrepriser/ Hovedentrepriser. Totalentrepriser. Lean/OPP/IPD* Skubbe Skubbe/trække. Trække. Gennemskuelighed Reducering af gentagne arbejdsgange. Stikprøvekontrol. Begrænset samarbejde om kvalitet Tabel 7. Styring og ledelsesniveauer i byggebranchen, udarbejdet ifm. rapporten Standardisering af arbejdsgange Reduktion i stikprøver. Begyndende samarbejde om kvalitet Ingen eller næsten ingen gentagne arbejdsgange Ydelser/leverancer leveres til tiden Proces- og erfaringsopsamling. Best in practice. Der findes flere rapporter, som underbygger manglende styring og ledelse af byggerier. Bl.a. Rambølls rapport, omhandlende svigt, fejl og mangler i dansk byggeri for 13 mia. (Erhvervs- og byggestyrelsen, 2010) Ud fra denne rapport kan det påvises, at der er plads til nye måder at organisere og lede byggerier i byggebranchen. Som beskrevet i kapitel 4, House of Quality (kvalitetshuset) er det ud fra denne analyse påvist, at der er plads til optimering af samarbejdsformer og kommunikationen på NavitasPark. Dette kan gøres ved hjælp af IPD, OPP og Lean (Trimmet Byggeri). Disse samarbejdsmetoder vil derfor blive beskrevet i det efterfølgende. 5.2 Integrated Project Delivery (IPD) En platform for effektivitet i byggeprojekter. IPD, er en anden måde at indføre effektivt byggeri. Denne metode bygger på gensidig respekt og tillid. Der lægges op til, at alle aktører arbejder aktivt i et samarbejdsmiljø og kommunikerer med hinanden for at løse problemer i stedet for at pålægge skyld. Der arbejdes på at alle får gensidig gavn og belønning ud af byggeprojektet. Typisk vil arkitekt, ingeniør og entreprenør inddrages tidligt af bygherre for aktivt, at arbejde på det bedste for projektet. Der arbejdes sammen for at alle i projektgruppen kan træffe beslutninger i enighed, og parterne arbejder på tværs af faggrupper og grænser for, at fremme innovation. Med andre ord silotankegang er ikke befordrende for projektet. Projektets mål defineres tidligt og planlægges intensivt, for at have et grundlag allerede i designfasen AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 37

40 Dette lægger op til, at projektteams anvender BIM teknologier for at fremme samarbejdet i teamet, øge effektiviteten og maksimere den måde de forskellige programmer arbejder sammen på, og dermed øge gennemsigtigheden. IPD, kan ved første indtryk ligne en ny metode til at udarbejde aftaler mellem rådgiver, entreprenør og ejer/bygherre. Det er også bygherren, som vil få mest udbytte af denne samarbejdsmåde. (Eastman, Teicholz, Sachs, & Liston, 2011) Der findes yderligere måder at lave en retslig ramme for samarbejde. Bl.a. design-bid-build og design-build som ejeren, rådgiver og bygherren kan bruge til et samarbejde om et design- og byggeprojekt. (BuildingGreen, 2008) Flere organisationer har udviklet specifikke IPD udbudsbetingelser. Bl.a. har The American Institute of Architects (AIA), udgivet flere versioner af IPD i maj Kontrakt skabelonerne findes på organisationens hjemmeside. (American institute of Architects) Samarbejdet på NavitasPark i projekteringsfasen indtil hovedprojektet minder en del om IPD, men da ingeniørerne ikke projekterede sammen med arkitekterne og entreprenørerne i Aarhus, blev samarbejdet besværliggjort. Hvorvidt dette skyldes måden ingeniøren arbejder på, eller noget helt andet, har ikke været muligt at finde frem til. (information indhentet ved interviews) Der bliver i følgende afsnit gennemgået principperne bag Lean, og dens funktion i en projektorganisation, samtidig med, hvordan det kan fungere i samarbejde med BIM. De to initiativer viser sig at have meget til fælles, og supplerer hinanden. På trods af manglende praktisk erfaring ved brug af de 2 initiativer, findes teorien om dem begge hver for sig, og sammenlignes til slut i afsnittet. Kapitlet gennemgår desuden, hvordan de to principper ledelsesmæssigt og designmæssigt kan styrke byggeprocessen, forbedre kvalitet, reducere omkostninger og forbedre samarbejdet og kommunikation i en projektorganisation. 5.3 Lean og Lean Construction Lean er en japansk produktionsfilosofi, som stammer fra Lean production (Lean manufacturing). Bilproducenten Toyota er kendt for at have udviklet filosofien, og har været et centralt punkt for udviklingen indenfor Lean, i de sidste mange årtier. Lean er at bevare en høj værdi i et produkt, ved at reducere mængden af arbejde, med fokus på minimering af spild, tid og ressourcer. Det vil sige, at de ressourcer der ikke skaber direkte værdi for produktet, bliver fjernet fra processen. Ved at anvende denne filosofi, har Toyota kunnet levere et billigere produkt, og samtidig sikre en bedre drift end andre bilproducenter på markedet. (Linker, 2004) Lean Construction og Lean design Lean Construction, også kendt som Trimmet Byggeri i Danmark, er et begreb der opstod i starten af 90 erne efter en rapport udarbejdet af Lauri Koskela, på Stanford University i Californien. Lean Construction ses som en kombination af tidligere forskning og praktisk udvikling i design og konstruktion, hvor flere af principperne fra Lean manufacturing kan anvendes. Dog er byggeri i forhold til produktion sværere at AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 38

41 forudse, da der er flere variable faktorer, som spiller ind i et byggeprojekt f.eks. vejrforhold, der kan vanskeliggøre planlægningen. Lean Construction skal ses som et term, der kan benyttes af alle i byggebranchen og ikke kun til udførelsesfasen af projektet. Det finder derved anvendelse for både brugere, arkitekter, ingeniører, entreprenører og leverandører. Ligesom ved Lean manufacturing blev det observeret, at byggebranchen kunne udnytte Lean i alle aspekter i byggeprocessen: design, udførelse, ibrugtagning, drift og vedligehold, renovering og nedrivning. For at udspecificere denne proces, blev Lean Project Delivery system (LPDS) udviklet af LCI (Lean Construction Industry). LPDS modellen er en proces, hvor de forskellige faser i et byggeprojekt integreres med hinanden. Modellen åbner op for yderligere samarbejde mellem de forskellige aktører i en projektorganisation, og fremmer positivt samarbejde mellem parterne, hvor viden og erfaring deles fra starten af designfasen og gennem hele processen. Figur 14. LPDS model, LCI Ovenstående figur illustrerer Lean Project delivery system. Processen er sorteret i 16 moduler, hvori 11 af dem er organiseret i 5 faser, der dækker designfasen frem til brug. Produktions kontrol og arbejdsstrukturering dækker alle faser, og repræsenterer ledelsen gennem hele projektforløbet. Figuren viser også, hvordan de forskellige faser i Lean construction integreres med hinanden i forhold til projektets faser, og i sidste ende linket mellem et afsluttet projekt til begyndelsen af det næste. Dette link ses som et af kerneelementerne i Lean tankegangen, da tidligere erfaringer- og viden genbruges, og anvendes til at udvikle fremtidige projekter og processer. En af de faktorer som gør LPDS succesfuldt, er at aktører såsom entreprenører, bliver involveret i projektets designfase, der gør det muligt for dem at have indflydelse på beslutningerne i de tidlige faser. De erfaringer der indtil videre findes ved brug af Lean principper i byggeprojekter, viser at kvaliteten i designfasen optimeres markant i forhold til traditionelle design processer. Mere om dette findes senere i kapitlet. AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 39

42 5.4 Target Value Design (TVD) Det overordnede koncept i Lean design, som kan indgå i LPDS, er Target Value Design (TVD). Konceptet fokuserer hovedsagligt på værdierne ønsket af kunden ud fra det fastlagte budget, og projektets designfase gennemføres ud fra disse. TVD konceptet anvendes som en ledelsesmetode til IPD, der beskriver samarbejdet mellem aktører i projektets tidlige faser. Target Value Design kan opdeles i 5 undergrupper som vist på figur 15. Alle undergrupperne anvendes til at konfigurere værdien i projektet samtidig med, at holde fokus på at skabe maksimal værdi indenfor det givne budget. (Nguyen, 2010) Følgende del af kapitlet, gennemgår de 5 undergrupper af Target Value Design og forklarer, hvordan Lean og BIM kan hænge sammen i et projekt. Figur 15. Target Value Design Nguyen Production System Design Production System Design er et design relateret aspekt, som strukturerer designfasen for at undgå spild. Denne undergruppe viser, hvor vigtigt det er, at have entreprenørerne med tidligt i designfasen i stedet for, at de først involveres i projektet efter designfasen er afsluttet. En rapport udarbejdet af Lauri Koskela, påviser, at mellem 23 % og 78 % af fejlene der resulterer i ekstra ydelser skyldes utilstrækkeligt arbejde i designfasen. (LCI) Dette er som følge af manglende ekspertise blandt de projekterende i designfasen. En måde at forhindre dette spild er forslået gennem Lean, ved at involvere de aktører med tilstrækkelig ekspertise indenfor konstruktion, materialer, priser mm. tidligt. Forskning har vist at 80 % af byggeudgifterne bliver fastsat indenfor de første 20 % af design i designfasen (LCI). Det er derfor vigtigt at få entreprenører med i projektorganisationen i denne fase, sådan at de får indflydelse på beslutningerne. AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 40

43 Dette vil kunne give besparelser og minimere fremtidige fejl og forbedre den konstruktionsmæssige kvalitet. Der kan endvidere tages bedre beslutninger da aktørerne med ekspertise får indflydelse. Figur 16. The MacLeamy curve. AIA Grafen i figur 16 illustrer, hvordan en projekterings proces kan se ud med tidlig inddragelse entreprenører. Punkt 1 viser, hvad ændringer medfører på forskellige tidspunkter i processen. Punkt 2 illustrerer den økonomiske virkning af ændringerne. Punkt 3 viser en traditionel design proces, hvor ekspertise fra entreprenørne ikke får indflydelse på projektet før efter designfasen. Punkt 4 illustrerer, hvordan ekspertisen kan få indflydelse på projektet i et Lean baseret projekt. Grafen synliggør fordelene der kan være, ved at have entreprenørerne med i designfasen. Ved at deres ekspertise udnyttes tidligt, minimeres ændrings procenten senere i projektet, hvor det også bliver dyrere at foretage ændringer. Ideen med et tidligt samarbejde går hånd i hånd med principperne bag BIM. Samtidig kan det betyde, at entreprenørerne får mere motivation og tiltro til projektet, da de har haft indflydelse på de valgte løsninger. BIM projekter er dyrere i designfasen, da der skal indhentes flere informationer, som skal lægges ind i modellen, og dette er tidskrævende. Dog forventes det, at disse ekstra omkostninger bliver dækket af de besparelser, der hentes i udførelsen af byggeriet. Collocation (Samhusning) Collocation handler om at samhuse et projektteam bestående af designere, ingeniører, rådgivere, entreprenører samt underentreprenører tidligt i et projekt for, at samle viden fra alle aktører og levere et integreret projekt. Denne tankegang er princippet bag Integrated Project Delivery (IPD), som senere er blevet adopteret af Lean Construction Industry (LCI). LCI beskriver den ønskede struktur i en projektorganisation. American Institute of Architecture har endvidere beskrevet strukturen i projektteams for at udnytte potentialet i BIM. På AIA s webside har de anvendt The MacLeamy curve, hvor figuren har fået ændret navn til BIM approach, og på LCI s webside er samme graf ændret til Lean approach. Kurven blev udviklet af MacLeamy for at beskrive fordelen ved IPD teams. Sammenhængen mellem de tre koncepter er derfor tydelig. AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 41

44 LCI beskriver IPD som følgende: Integrated Project Delivery is a delivery system that seeks to align interests, objectives and practices, even in a single business, through a team-based approach. The team s primary Team Members would include the Architect, key technical consultants as well as a general contractor and key subcontractors. It creates an organization able to apply the principles and practices of the Lean Project Delivery System. - LCI I et dokument udarbejdet af AIA, ved navn The working document Integrated Project Delivery, er IPD forklaret som følgende: Integrated Project Delivery (IPD) is a project delivery approach that integrates people, systems, business structures, and practices into a process that collaboratively harnesses the talents and insights of all participants to reduce waste and optimize efficiency through all phases of design, fabrication and construction. Integrated Project Delivery principles can be applied to a variety of contractural arrangements Integrated Project Delivery encourages contribution of knowledge and experience and requires proactive involvement of Key participants. It is possible to achieve Integrated Project Delivery without Building Information Modeling, it is the opinion and recommendation of this study that Building Information Modeling is essential to efficiently achieve the collaboration required for Integrated Project Delivery. - AIA (Tjell, 2010) Samarbejde Når entreprenører og andre aktører skal samarbejde i designfasen, skal dette være veldefineret inden start. Det kan være en udfordring at strukturere koordinationen, kommunikationen og informationsdelingen i forhold til hvem der skal bruge hvad og hvornår. I Lean filosofien er samarbejdet et bærende element for, at deltagerne kender processen og deres rolle, og kan have indflydelse på processen. En måde at strukturere samarbejdet i et projektteam, er ved at anvende konceptet BIG room. Et koncept, hvor alle aktører sidder samlet ét sted. (Emmit, Sander, & Christoffersen, 2004) Arkitekt Underentrepr enør Entreprenør Brugere Bygherre Rådgivere Ingeniør Figur 17. Illustration af BIG room konceptet i en byggesag Janni Tjell Ovenstående figur illustrerer, hvordan BIG room konceptet kunne se ud ved anvendelse i en byggesag. Projektets faglige aktører skal sammen med brugerne af byggeriet foretage evt. beslutninger i fællesskab AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 42

45 tidligt i designfasen. Dette kan som førnævnt forbedre det endelige produkt, da vidensniveauet bliver større ved denne type dialog. Ifølge Toyotas erfaringer med BIG room konceptet skal der udføres systematisering af den information, som skabes ved møderne. Informationen skal struktureres, så den kan findes frem, når det er nødvendigt. Denne information skal visualiseres, for at give et bedre overblik når informationsmængden bliver stor. Her kan BIM processen levere en visualisering og et overblik af produktet. De forskellige fagmodeller kan eksempelvis linkes sammen i en kollisionskontrol, for at hindre evt. sammenstød mellem de forskellige bygningsdele. Bygningen udarbejdes derfor som en virtuel model i et samarbejde mellem rådgiverne og de udførende. Set Based Design Konceptet Set based design ses, som en af de vigtige grundlæggende processer i Lean design. Ifølge Toyota er en af de vigtigste læreprocesser for den yngre generation af ingeniører, at vente med at tage beslutninger indtil de har overvejet en bred række af muligheder. (Tjell, 2010) Set based design omhandler, at beslutninger der foretages tidligt i design processen, kan medføre at det bedste resultat ikke opnås. Design tilgangen anvendes ofte af Toyota på en sådan måde, at når et produkt skal designes f.eks. et nyt bremsesystem, får 2-3 forskellige hold ingeniører opgaven at udvikle designet. Derefter sammenlignes resultater, hvor der gennem udveksling af ideer og meninger skabes det bedste produkt. Denne metode kan også anvendes i byggeriets designfase, men tilgangen er anderledes i forhold til fremstillingsindustrien. (Parrish, Wong, Tommelin, & Stojadinovic, 2007) Den mere traditionelle metode til design kan sammenlignes med Point based design. Point based design er en metode, hvor designet bestemmes tidligt, og alle involverede jagter derefter de løsninger, der kan anvendes i de efterfølgende faser. På denne måde er det ikke altid muligt at udføre større ændringer i designet, og kan resultere i løsninger, der ikke nødvendigvis er de bedste. (Emmit, Sander, & Christoffersen, 2004) Figur 18 viser en illustration over processen ved Point based design, hvor designet udføres i et serieforløb. De involverede i projektet, må derfor arbejde efter de retningslinjer der er bestemt i forvejen. Figur 19. Illustration over Point based design Ward Figur 18. Illustration af set based design Ward AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 43

46 I modsætning til Point based design, gælder Set based design om at vente indtil det sidste forsvarlige tidspunkt med at tage den endelige beslutning, også kendt indenfor Lean konceptet som the last responsible moment. Dette giver mulighed for, at flere designs udarbejdes samtidigt. De forskellige design konkurrerer med hinanden, og kan supplere hinanden. Den endelige beslutning om designet sker til slut i processen, hvor den mest værdifulde løsning vælges. At vente på denne måde indtil alle alternativer er kendt, kan sammenlignes med Lean planlægning i udførelsesfasen, hvor opgaver først planlægges efter, at de forrige er udført. Figur 19 illustrerer Set based design processen. Her ses det at forskellige designkoncepter bliver udarbejdet parallelt med hinanden, samtidig med andre aspekter af processen. De skrottede alternativer, kan anvendes til andre projekter og arkiveres, da der gennem disse alternativer dannes erfaring til fremtidig anvendelse. BIM supplerer Set based design, fordi værktøjet muliggør analyser, visualiseringer og giver dermed et tidligt overblik af designet. Herved minimeres fejl og gentagne arbejdsgange Hvis BIM platformen kombineres med Lean, vil de involverede kunne opnå et design i højere kvalitet. Set based design er i bilindustrien bevist som værende en hurtig design proces, dog er dette endnu ikke tilfældet i byggebranchen. (LCI) Target Costing Target Costing er et element i Lean design, som kan skabe værdi for kunden, da uventede omkostninger undgås. Ved traditionel projektering, kan entreprenørerne først byde på projektet efter designfasen. Dette kan medføre risiko for, at entreprenøren selv skal forestå ekstra omkostninger, hvis projektet bliver dyrere. Det kræver stor erfaring, at kunne vurdere prisen, når de ikke har haft indflydelse på designet. Ved brug af Target Costing får entreprenørerne tidligt i designfasen oplyst en budgetramme, og skal efterfølgende skabe et projekt af størst mulig værdi. Glenn Ballard fra LCI (Lean Construction Institute), forklarer denne proces kort som, Designing to target cost is a development practice that converts cost into a design criterion rather than a design outcome. Det vil sige, at et budget for et projekt bliver til et design, i stedet for at designet bliver til et budget. Anvendes Target Costing sammen med digitale modelleringsværktøjer, kan bygningsmodellen tilføjes en ekstra dimension i form af pris (5D). Dette giver mulighed for at vurdere priser gennem processen. Kombineres Set based design med denne pris dimension, kan forslagene sammenlignes økonomisk ved afholdelse af BIG room møder. 5.5 Synergien mellem Lean og BIM I en rapport udarbejdet af Rafael Sacks, Lauri Koskela, Bhargav A. Dave og Robert Owen (The Interaction of Lean and Building Information Modelling in Construction) (Sacks, Koskela, A., & Owen, 2009), er der forsket indenfor de 2 initiativer, og hvordan de går hånd i hånd i et byggeprojekt. I rapporten er der opstillet en matrix med 24 Lean principper, 18 BIM funktioner og 56 relationer mellem dem, hvor 52 af dem er positive. I BIM Handbook, er der ud fra rapporten forklaret 4 områder af synergien mellem de 2 initiativer. BIM reducerer variation i arbejdet AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 44

47 Det er muligt at visualisere bygningens udformning ud fra en 3D model, evaluere dens funktioner, udføre en hurtig generering af design alternativer, konsistens kontrol, og automatisk generering af rapporter. Disse er alle sammen med til at reducere spild i form af ventetid og gentagne arbejdsgange. Dette har indflydelse på hele projektorganisationen, og specielt for dem der opfører byggeriet. (Sacks, Koskela, A., & Owen, 2009) BIM reducerer udførelsestiden som helhed I alle typer af produktion er målet at reducere produktionstiden mest muligt for at spare tid, som resulterer i en økonomisk besparelse. BIM kan være med til at give store besparelser i et byggeprojekt. I BIM Handbook, præsenteres et eksempel på et medicinsk center, hvor BIM har været anvendt i projektet. Under prissætningen reducerede de tiden fra at vare flere måneder, til 2-3 uger ved hjælp af 5D værktøjer. Det samme gælder for analysen af udførelsesprocessen, hvor de ved hjælp af 4D værktøjer var i stand til at analysere udførelsen af byggeriet, og undgå proces konflikter som kunne være opstået. Udover disse er der mange andre funktioner som gør BIM tidsbesparende f.eks. automatisering af ændringer mm. Alle disse faktorer er med til at reducere projektets varighed, og gør derved BIM projekter tidsbesparende. (Sacks, Koskela, A., & Owen, 2009) Visualisering af materialer og processer I de mere komplekse bygningsdele der f.eks. indeholder armering er det muligt for et projektteam at udarbejde tekniske tegninger i 3D objekter, som senere kan bruges i projektet. BIM Handbook nævner et eksempel på udførelsen af en bro i USA, hvor samme metode er anvendt i Skandinavien af E. Pihl og Søn A/S på udførelse af jernbanebroer i Sverige. Her udarbejdedes en 3D model af betonkonstruktionerne, hvor alt armering var detaljeret i 3D. Designteamet har haft forbindelse med leverandøren af betonarmeringen, hvor der blev etableret en forbindelse fra 3D modellen direkte til leverandørens produktionsmaskiner. På denne måde blev der produceret præcise mængder af armering, i nøjagtige mål efter 3D modellen samtidig med, at denne hurtigere kunne leveres. Her erfarede projektteamet, at fejlene i forhold til 2D projekteringen blev reduceret med fejl pr. 100 stk. armeringsjern, i forhold til 0-2 fejl pr. 100 stk. ved brug af 3D modellen. Samtidig var projektteamet i stand til at bestille armeringen efter 4D simulering af udførelsen, som samtidig støtter principper for Lean (Sacks, Koskela, A., & Owen, 2009) BIM støtter Lean principper i designfaserne Klienter forstår design koncepter bedre, når de fremvises i 3D i stedet for 2D. Dette giver mulighed for, at designteamet kan fremlægge deres ideer på en bedre og mere forståelig måde. F.eks. gennem visuelle simuleringer af energi og indeklima. Kontrol af forskellige krav, samt flow af information bliver forbedret, da designteamet hele tiden kan følge opdateringer, der sker i modellen. BIM modellerne giver mulighed for at udsætte beslutninger, da de ikke skal bruge lige så meget tid på, at skabe tegningsmateriale som automatiseres med BIM. Et af Lean principperne er at reducere fejl og skære spild fra processen. Sammenholdt med ovennævnte værktøjer og processer sker dette automatisk i designfaserne. (Sacks, Koskela, A., & Owen, 2009) AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 45

48 5.6 Digitalt udbud og tilbud: Cuneco s nye forslag/-udspil, går ud på at stille krav til digitalt udbud og tilbud for at mindske redundante arbejdsprocesser. Derfor er der blevet set efter krav, både indenlands og udenlands (England og Tyskland). Ud fra søgningen og analyser, er der fundet ud af, at hvis udbuds- og tilbudsprocessen digitaliseres og standardiseres, er der mulighed for at spare op til 40 % af omkostningerne i et byggeprojekt. Dette kan potentielt reducere byggeriets samlede omkostninger med mere end 2 milliarder kr. årligt. Derfor er antallet af digitale udbud af byggeprojekter støt stigende, grundet de store fordele, ved at afholde licitationen via en digital udbudsportal. Dog er der stadig processer der forekommer uintelligente. Det viser sig, at der ved godt 30 % af digitale udbud, udelukkende udveksles udbudsmateriale i pdf format. Dette resulterer i, at entreprenørerne står med et dødt dokument, som de selv skal printe ud, udfylde, scanne og sende retur. Desuden er der stadig flere problematikker omkring selve udbudsportalen, da standarder for udbuds og tilbudsmaterialer ikke ses tilstrækkelige. Dette gør det svært at eksportere udbudsmaterialet fra udbudsportalen. Derudover er der behov for yderligere kontrolfunktioner, og muligheder for at dele entrepriserne op i underentreprenører, når disse hentes ned, og skaber meget manuelt arbejde. Brugen af 3D modeller til udbudsmateriale, udføres hovedsageligt, med den nødvendige information, der skal anvendes til videre projektering. Dog ikke til entreprenørens tilbudsgivning, der får en samlet hovedmodel. Herefter skal de selv trække nødvendigt data ud fremfor, at modellen var opdelt i fagmodeller, til de respektive fagentreprenører. Dette burde gøres for at lette arbejdet, da mange entreprenørfirmaer ikke har kompetencerne, til at gøre dette. Desuden er der stadig problemer mht. udvekslingsformatet IFC, da de forskellige programmer læser dets data forskelligt. Til tider har software værktøjer problemer med at læse disse, da mange af filerne er enormt store, hvorved processen igen bliver meget træg/ langsom, og oversætter med unøjagtigheder. Dette kunne gøres bedre gennem standardisering, hvor de bydende aktører fik en specifik version af modellen, som herved kunne bruges til opmåling af div. mængder til kalkulation. En anden måde dette kan omgås, er ved at sætte mængderne på udbudsmaterialet, hvorved de slipper for at gøre det selv. Hvilket er årsagen til Cuneco har igangsat 3 projekter, i perioden 1. maj til 30. november 2012, med formålet at komme disse problemstillinger til livs. (Cuneco, 2012) (Dansk Byggeri; Bygningsstyrelsen; Cuneco; Balslec & Jacobsen Aps; Byggeweb; Chalmers, 2012) Specifikation af måleregler: Det er erfaret at BIPS opmålingsregler fra 2008, ikke er tilstrækkelige i forhold til praktisk anvendelse, hverken præcisions- eller omfangsmæssigt. Derfor er formålet med denne beskrivelse, at det klart skal defineres, hvor der skal laves ekstraarbejder og supplerende opmålinger, for at prissætte ydelserne. Disse mængdeudtræksregler, skal føres sammen med de regler, der er i IFC modeller. På denne måde spares der tid, da det bliver muligt at stole på de mængder, der trækkes ud af programmet. Der bliver taget udgangspunkt i følgende materiale: AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 46

49 Bips Opmålingsregler 2008 Priskuranter for murerarbejde, tømrerarbejde, malerarbejde, VVS-installationer og El-installationer BuildingSMART: Information Requirements for Model-based Quantities Definition of Base Quantities, 2010 BuildingSMART: Requirement Definition for Model based quantities, 2007 Opmåling for bygningsmalere, 2009 (Cuneco, 2012) Specifikation af data til tilbudsgivning: Efter afdækning af erfaringer i branchen vedrørende BIPS opmålingsregler er det erfaret, at der stadig er væsentlige processer, der ikke fungerer korrekt. Dette udledes af behovet for en del manuelt arbejde i forbindelse med udtrækningen af data. I denne beskrivelse er det dog ikke den geometriske data der tages stilling til, men nærmere, hvordan tilbudslisterne struktureres/-grupperes, samt tilkoblingen af egenskabsdata til objekterne, som kan have indflydelse på prisen (hovedsageligt råhuset og teknikken i bygningen). Disse skal efterfølgende overdrages til de tilbudsgivende i nødvendigt omfang, og i struktureret form. Der tages udgangspunkt i: Bips Opmålingsregler 2008 Priskuranter for murerarbejde, tømrerarbejde, malerarbejde, VVS-installationer og EL-installationer V&S Prisbøger BuildingSMART projekter og publikationer vedr. Quantity take-off fra modeller (Cuneco, 2012) Digitale tilbudslister: Det er i flere år blevet foreslået, at det var en god ide at få et standardiseret digitalt format til udbuds og tilbudsfasen, der som regel udleveres i PDF format, der ikke er hensigtsmæssigt for de bydende. Derfor er formålet med projektet, at udvikle et format, der kan indlæses i branchens mest anvendte kalkulationssystemer, som f.eks. Excel. Samt at det vil kunne bruges uanset udbuds- og samarbejdsform. Derfor er det også vigtigt, at projektet ikke kun formuleres til bygherren, de projekterende og de udførende men også udbyderne af kalkulationssystemerne. Eftersom projektet aldrig vil kunne lade sig gøre, uden at formatet implementeres i deres software. Ydermere skal projektet tage udgangspunkt i de tidligere lovgivninger for opmåling. (Cuneco, 2012) På baggrund heraf, vil der i de nye regler, blive lavet en sammenkobling af de gamle reglementer, for at danne et nyt. Dette nye reglement skal være bedre til at tage stilling til, hvad der skal ske med f.eks. udsparinger, fradrag osv. Derfor nedsættes en gruppe af div. aktører med beregning og udbudserfaring, for at få tilstrækkeligt indblik i alle grene af byggeriet. AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 47

50 Stadig i høring Da disse fremlagte publikationer stadig er i høring, er der mulighed for, at der vil blive lavet yderligere ændringer heri, før de træder i kraft som værende en del af lovgivningen. Det er dog stadig meningen, at de færdige forslag skal bruges, som grundlag for forbedringer i det eksisterende materiale. Fordelen ved Cuneco s udmeldte forslag er, at de er forholdsvis nemme at gå til, og skal kunne implementeres i aktørernes programmer. Foruden dette er Cuneco kommet med forskellige udspil til hvordan udvekslingen mellem aktørerne, kan fordelagtiggøres for at optimere byggeprocessen. Hermed opstår der en optimal dataudveksling mellem aktørerne, som beskrevet i Leavitt s systemmodel, i starten af rapporten. 5.7 Offentligt Privat Partnerskab (OPP) Når et OPP samarbejde indgås, skal hele byggeriets livscyklus anskues, da OPP som hovedregel er en udbuds/styrings form, der varetager bygherrens(bestillerens) ønsker fra idé, til en års drift- og vedligeholdelsesperiode. Der skal derfor tages højde for såvel udformning, materialer, beliggenhed samt udførelsesmetoder. Incitamentet for et OPP er, at alle skal løfte det kvalitetsmæssige aspekt sammen. I starten bliver ansvaret for korrekt udførelse af de enkelte opgaver, placeret hos den person/personer, som besidder den største ekspertise på netop dette område. Der placeres veldefinerede krav til samarbejde idet, at alle har til interesse i, at bygningen eller opgaven udføres med mindst mulig fejlprocent. Ved at entreprenøren evt. selv har et økonomisk forhold til selskabet, er det også i entreprenørens favør, at processen forløber med så få ophold som muligt i udførelsesfasen. Ved at inddrage og placere ansvaret for opgaver ved de personer der har viden indenfor området, vil dette gøre, at entreprenøren kommer tidligt i samspil med arkitekten og/eller ingeniøren. Da projektering og udførelse er forskellige, og hvor at ingeniørens største interesse ligger i at det rent statisk kan lade sig gøre, har en entreprenør interesse i, at det også er til at opføre, samt til den billigste pris. I et OPP selskab er der mange ting, der skal tages stilling til. En vigtig faktor er at sikre sig kvalitet, både hvad angår materialer og udførelse. Når samarbejdet mellem de projekterende og de udførende starter tidligt, kan de bedre bistå hinanden på hver deres ekspertise område. OPP Organisering Et OPP selskab har til formål at skabe kvalitet, derfor skal alt være velovervejet inden udførelsen. Det skal overvejes, hvilke konsekvenser de forskellige materialer og udførelsesmetoder kan have. I et OPP selskab er det bedre at øge ressourcerne i opførelsen af projektet, hvis det efterfølgende kan minimere udgifterne i drift perioden. Ved valget af materialer og udførelsesmetoder kan brugen af digitale værktøjer formidle entydig informationsudveksling. Der skal udføres drift og vedligeholdelses manualer for at sikre sig, at konstruktionerne og materialer får den tilstrækkelige vedligehold. Bestilleren som ofte er en statslig bygherre, kan forlange at få drift og vedligeholdelses manualer udleveret digitalt. Hvis de allerede har et drift og vedligeholds system, skal de nye bygningsdata, kunne overføres til dette program. Da udviklingen indenfor IT og brugen af denne i byggebranchen er et meget omtalt emne, er det oplagt, at der tænkes over, at de systemer som er indbygget i bygningen, skal kunne opdateres inden overdragelse til bestilleren. AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 48

51 Figur 20. OPP Organisationsdiagram (c) HM Treasury Figur 21 viser en organisation som den typisk vil se ud for et OPP selskab. Et vigtigt element for kvaliteten under hele processen er, at entreprenørerne og i visse tilfælde leverandørerne, er medejere i OPP selskabet. Ved valget af denne organisationsmodel giver det entreprenørerne, såvel som leverandørerne, et økonomisk samt kvalitetsmæssigt incitament til, at levere og indbygge de aftalte materialer i en den ønskede kvalitet. De har som medejere af selskabet en interesse i at holde udgifterne nede i drift perioden, som kan vare op til 30 år. Figur 21. OPP Samarbejde (c) EBST Figur 22 giver et overblik af et OPP samarbejde fra projektering, og frem til at samarbejdet ophører. På byggestyrelsens hjemmeside står der, at de statslige bygherrer skal jf. bekendtgørelse 1394 om anvendelse af offentligt privat partnerskab (OPP) overveje, om byggeriet skal gennemføres i en samarbejdsform med en privat partner der udover byggeriet, leverer finansiering og drift mm. AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 49

52 5.8 Partnering Partnering er ikke en traditionel kontraheringsmodel, men derimod en samarbejdsmetode, der lægger vægt på gensidig respekt og tillid hos de involverede parter. Parternes interesse er, at gennemføre et projekt på den mest økonomiske og tidseffektive måde, samt mindske mulighederne for konflikter. I forhold til andre entrepriseformer, som f.eks. totalentreprise, hvor der eksisterer et klart bestiller/leverandørforhold, og en klart defineret aftalestruktur. Partnering handler mere om en uformel aftalestruktur. Partnering er særligt egnet til projekter, hvor bestilleren på forhånd ikke har lagt sig fast på en konkret udførelse. Derved kan der ved partnering, drages kompetencer fra forskellige leverandører og udførende for, at opnå det bedst mulige resultat. Det kan være en fordel at indbygge incitamenter i samarbejdsaftalen, for på den måde, at få de forskellige parter til at støtte op om samarbejdsformen. Eksempler på positive incitamenter kunne være: At der sættes den fornødne tid til at udvikle samarbejdet. At der fokuseres på løsninger i stedet for problemer og ansvarsfraskrivelse. At rådgiveren og entreprenøren generelt skærper opmærksomheden på opgavens løsning, gennem øget risk management i procesplanlægningen. At entreprenøren er mere omhyggelig ved indgåelse af underentrepriseaftaler og indkøb. Incitamentet skal være en fælles fordel for alle de involverede parter. Således, at hvis det opfyldes, kommer det flere til gode. Det kunne eksempelvis være præmier til entreprenøren, hvis han at slutter tidligere, men på baggrund af godt samarbejde og ikke igennem dårlige arbejdsvilkår og stress. (Anlægsteknikforeningen i Danmark, 2011) Et godt eksempel på veldefinerede incitamenter og målsætninger er fra et fjernvarmeprojekt i København, som omhandler en 4 km lang tunnel. Punkterne i denne samarbejdsaftale for fælles målsætning var (DFTU): At der opretholdes en høj grad af teamspirit baseret på åbenhed, ærlighed, tillid og gensidig respekt. At sikre at teamånden er forankret i egen organisation. At processen gennemføres i et positivt og konstruktivt samarbejde. At eventuelle uenigheder løses i positiv dialog i stedet for modspil og tvister. At projektstyring uanset Partnering gennemføres effektivt og målrettet. Der var også i samarbejdsaftalen, beskrevet direkte positive incitamenter som en gulerod for at deltage i projektet. Incitamenterne og bonusserne er beskrevet i nedenstående punkter. Incitament for overholdelse af den økonomiske ramme. Rådighedsbeløb og ekstraarbejde/-tilkøbes og defineres. Overskud fordeles 50 % (bygherre), 5 % (rådgiver), 45 % (entreprenør) Tidsbonus Entrepriser klar i henhold til tidsplan. AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 50

53 Bonusforløb fordeles 10 % (bygherre), 90 % (Entreprenør) Global tidsbonus Entrepriser afleveres rettidigt og mangelfrit. Bonusbeløb til hver entreprenør. Sikkerhedsbonus Der uddeles kr. hver 3 måned i præmie til de medarbejdergrupper, der gør mest for at fremme sikkerheden på arbejdspladserne. (DFTU) Det kan i forhold til samarbejdet, være en god ide, at beskrive konflikthåndtering i samarbejdsaftalen. Grunden til dette er, at mange entreprenører har argumenter for ikke at deltage i samarbejdet idet, at de måske ikke er bekendt med Partnering. Det kan derfor være anbefalelsesværdigt at beskrive, hvordan evt. konflikter løses. På tunnelprojektet beskrev de deres håndtering af konflikter således: Uoverensstemmelser mellem parterne skal afklares via dialog, hurtigt og på lavest mulig niveau i organisationen. Der afsættes tid for, hvor længe de enkelte niveauer må bruge på at løse problemet. Løses konflikten ikke inden for den afsatte tid, skal den løses på næste niveau i organisationen. Kan styregruppen ikke komme til enighed, skal en fælles valgt uafhængig opsynsmand søge at bringe parterne til enighed. Lykkes dette ikke, kan konflikten indbringes for voldsgiftsretten. (DFTU) En veldefineret samarbejdsaftale, hvor alle punkter entydigt er beskrevet, kan være en fordel, når parterne skal indgå kontrakter med hinanden. Hvis der skulle være benyttet Partnering på NavitasPark, skulle bygherrerne have stillet lige store krav til udførelse og samarbejde, ellers kunne der opstå konflikter. De kan opstå, hvis en af bygherrerne ikke giver samme gulerod for det udførte arbejde. 5.9 Delkonklusion Samarbejdet og kommunikationen på NavitasPark foregik som en IPD fra opstart af projekteringen, indtil hovedprojektet blev afleveret. Dette lettede kommunikationen og samarbejdet mellem de forskellige projekterende. De nye samarbejdsformer benytter BIM platforme til, at dele informationen og gøre projektet mere gennemsigtigt. Der opnås tidligere et overblik af pris og tid på projektet. Dette samarbejde kræver, at det meget tidligt defineres hvilken, kvalitet bygherren ønsker til projektet. Som beskrevet, hører tid, pris og kvalitet sammen, dette skal derfor være beskrevet entydigt i projektet. AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 51

54 På NavitasPark-projektet er der fire bygherrer, både offentlige og private. Da finansieringsmulighederne er forskellige for disse, kunne der ikke benyttes en OPP eller Partnering på projektet. To af bygherrerne havde ikke erfaring med rollen som bygherre, det var kun Incuba Science Park samt kommunen, der havde denne erfaring. Bygherrernes forskellige tilgangsvinkler og beslutninger om hvilken kvalitet der er gældende, har stor betydning for det færdige resultat. IPD og Lean understøtter samarbejdet, så der kan kommunikeres og besluttes, hvilken kvalitet der skal være gældende. Modelleringen på BIM platforme giver et overblik af designet, og kan også danne grundlag for simuleringer og analyser. Samarbejdet mellem rådgivere og entreprenører tilfører entreprenørerne erfaring og viden, der er værdifuld under projekteringen. Dette kan tilføre den værdi som bygherren ønsker. AALBORG UNIVERSITET Kommunikations- og Samarbejdsformer 52

55 6. IKT-aftalegrundlag Dette kapitel omhandler bindeledet mellem teknologidelen og de andre systemer i Leavitt s model, som det er vist på figuren, til venstre. IKT-grundlagene fungerer som bindeled mellem teknologien, aktørerne, strukturen og opgaven. Disse danner basis for et velfungerende projektarbejde. Informations og kommunikationsteknologi (IKT) baserer sig på arbejdet med kommunikation på IT-basis, kommunikation mellem servere, pc er mm. En IKT aftale er et aftalegrundlag, der indgås mellem bygherren og de respektive parter i et byggeri. Aftalen indgås for, at klarlægge de digitale ydelser parterne imellem, samt at forpligte aktørerne til at bruge IKT værktøjer i byggeprojektet. I aftalegrundlaget specificeres det i hvilken grad der skal gøres brug af IKT samt hvilke værktøjer og formater, der er tale om. (Det Digitale Byggeri) 6.1 IKT-aftalens historie IKT-aftalen blev introduceret i regeringens udspil Staten som bygherre vækst og effektivisering i byggeriet for at igangsætte forbedringer i det danske byggeri, da produktiviteten ikke havde udviklet sig som ønsket siden 1980 erne, samt for at have et fælles grundlag på tværs af virksomheder. Følgelig blev man enig om, at opsætte målsætninger for den danske byggeindustri, således at skabe en udvikling heri. Disse er vist nedenfor: Mere byggeri for pengene Højere produktivitet Bedre kvalitet Disse mål skulle gennemføres vha. følgende indsatsområder: Øget brug af nye udbuds- og samarbejdsformer. De statslige bygherrer og arkitektur Fælles krav til IT-anvendelse i byggeriet. Fælles krav om nøgletal og benchmarks. Disse nye udbuds- og samarbejdsformer omhandlede eksempelvis OPP (Offentlig Privat Partnerskab), som introducerede tidligere udbud i byggeriet for at opnå bedre kvalitet vha. tidligt samarbejde. Denne og andre nye samarbejdsformer, omtales senere i rapportens kapitel 5. AALBORG UNIVERSITET IKT-aftalegrundlag 53

56 Der blev i indsatsområderne lagt stor vægt på, at der skulle ske en større udvikling af IT indenfor byggesektoren. Dette udmundede i, at der skulle indføres nye IT redskaber, således at undgå, at størstedelen af dokumenterne blev udvekslet i papirformat. Herfor opsattes følgende krav: Fælles retningslinjer for statslige bygherrers IT-krav indenfor: o Digitalt udbud og tilbud med beskrivende mængdefortegnelser o Digital 3D projektering af byggeriet o Fælles projektweb i byggeprojekter o Digital aflevering af drift- og vedligeholdelsesdata til brug i ejendomsforvaltninger. o Digital byggesagsbehandling Foruden disse krav skulle der føres nøgletal, samt udføres benchmarks gennem byggeriet for at have erfaringstal til efterfølgende projekter. Pilotprojektet til indførelse af IKT kravene har været Det Digitale Byggeri (DDB), som forløb gennem perioden (Regeringen, 2003) Efter DDB har de statslige bygherrer skullet stille en række krav til anvendelsen af IKT, som de projekterende virksomheder har skullet opfylde på statslige, og statsligt støttede byggerier, også kaldet de 5 bygherrekrav. I 2006 blev resultaterne af DDB samlet til et aftalegrundlag, også kaldet Erhvervs- og Byggestyrelsens samarbejdsaftale om IKT, som består af en anvisning, et paradigme og en vejledning (siden er der kommet to nye aftaler kaldet IKT-specifikationen, heri en basisbeskrivelse og en anvisning) ligesom BIPS byggesagsbeskrivelse. Den sidste nye IKT-specifikation er en tillægsaftale, der supplerer CAD manualen og de traditionelle ydelses- og leveranceaftaler i en byggesag. Specifikationen tager udgangspunkt i følgende publikationer: CAD-projekt-aftale 2005 C205, 3D CAD projektaftale 2006 og Erhvervs- og Byggestyrelsens IKT-aftale. I denne tillægsaftale defineres et sæt IKT-tekniske specifikationer på hvert af områderne: kommunikation, CAD/ bygningsmodel, udbud og aflevering. Disse bliver hermed gældende i den konkrete byggesag. (Det Digitale Byggeri) IT/CAD Projektaftale 2005 C205 & 3D CAD- projektaftale 2006: CAD- og 3D CAD projektaftalerne er begge baggrundmateriale for, hvad der ligger bag tegningsspecifikationerne i IKT-specifikationerne, henholdsvis for 2D tegninger og 3D modeller. Disse er tillægsaftaler til CAD-manualen, og beskriver yderligere, hvilke aktører der har ansvaret for hvilke tegninger samt, hvilke firmaer der bruger hvilke programmer, med alt relevant specificeret, hvorved kontroverser i projektet undgås. Ydermere er der i disse aftaler specificeret, om der er afvigelser fra mappestukturen, tegningsnumre og filkodningsprincipper. Foruden dette, er et af de væsentligste punkter, hvilket filformat der udveksles i, hvor hyppigt det sker, hvilket niveau filerne er i, hvem der står for udvekslingen af filerne, og hvem der uploader dem på projektwebben. I 3D CAD- projektaftalen skal der dog også specificeres, hvem der står for at lave konsistenskontrol og kollisionskontrol af modellerne, og hvornår dette skal finde sted. Det defineres også, hvem der skal samle fagmodeller til en hovedmodel, og dermed har ansvaret herfor, og om objekternes egenskabsdata skal placeres i modellen eller i en separat database. AALBORG UNIVERSITET IKT-aftalegrundlag 54

57 6.2 Klassifikation. 2. SEMESTER PROJEKT Udviklingsprojektet Cuneco er ved at udvikle det nye CCS klassifikationssystem, som skal overtage klassifikationssystemet DBK. Publikationen er stadig under udvikling, men herunder vil det foreløbigt præsenterede materiale fremlægges. Systemet er et referencesystem, der indgår som grundlæggende struktur i Cuneco s andre publikationer. CCS er i overensstemmelse med internationale standarder, i måden det er opbygget. Dette vil sige, at klassifikationssystemet kan mappes sådan, at det kan konverteres til andre landes standarder. Ifm. opførelsen af det nye supersygehus, DNV Gødstrup, bliver der endvidere undervist i denne nye klassifikationsmetode. CCS skal fremstå som værende et fælles sprog, samt en ny metode til at lave entydige udvekslinger af informationer i byggebranchen. Her deles der op i strukturelle aspekter, som bruges til at identificere bygningsdele og brugsrum. For at dette skal kunne lade sig gøre, er CCS under udvikling, så det kan læses af alle byggeriets parter samt af den software, som bruges til projekteringen. (Cuneco, 2012) Klassificeringen bliver delt op i fem forskellige aspekter, som alle kan aflæses vha. et start præfiks, som vist herunder: Typeaspekt % et enkelt % er til gruppering af bygningsdele med sammenfaldende egenskaber, eksempelvis kan et sidehængt vindue beskrives som %QQA1 og et tophængt hedde %QQA2. Hvis det derimod er et rum, der defineres, gøres dette med %%. Hermed kan et enkeltrum hedde %%MA01 og et storrum hedde %%MA02. (Cuneco, 2012) Produktaspekt # et enkelt # anvendes til nummerering af et objekt uden kendskab til dens behov eller strukturering. Eksempelvis kaldes vindue 1 #QQA1 og nr. 115 #QQA115. Ved rum er det samme princip som ved typeaspektet. Nr. 1 kaldes for ##1 og nr. 115 ##115, dog skal der her ikke forveksles med Rumnummer, da denne kan være anderledes. (Cuneco, 2012) Sammensat produktaspekt - et enkelt - anvendes til at definere sammensætningen af en bygningsdel (sammensætning af flere bygningsdele), fx vægsystem 1. Vinduesparti 1. Vindue 1 ville beskrives som -B1.UA1.QQA1 og vægsystem 12. vindue 316 ville hedde -B12.QQA316. Rum deles op i bygning 1. Etage 2. Brugsrum 1, som ville beskrives B4.E2.R1 og Bygning 12. Afsnit 3. Etage 2. Brugsrum 22 ville hedde - -B12.S3.E2.R22. Dette illustreres på figur 23. (Cuneco, 2012) Figur 22. Cuneco, sammensat produktaspekt Cuneco AALBORG UNIVERSITET IKT-aftalegrundlag 55

58 Placeringsaspekt + Er meget som forrige, her defineres placeringen af et vindue i en bygningsdel med et + så derfor ville vægsystem 1. vægkonstruktion 4. Vindue 27 beskrives +B1.UG4.QAA27. på samme måde defineres placeringen af et rum med ++ så derfor ville bygning 4. Etage 2. Brugsrum 1 beskrives ++B4.E2.R1. (Cuneco, 2012) Funktionsaspekt = Bruges til at definere konstruktive systemer, derfor vil f.eks. ventilationssystem 1. blandeanlæg 2. kontraventil 3 beskrives =j1.ha2.rma3 og == bruges til at definere sammensætningen af brugsrum, ved deres tilhørsforhold til andre grupper, f.eks. beskrives klynge 1. afdeling 2. kontor 3 som ==K1.A2.MA3. (Cuneco, 2012) Supplerende strukturelle aspekter I klassifikationen er der lavet plads, så tre af hvert symbol kan bruges i tilfælde af, at man har brug for noget projekt specifikt. Eksempelvis kan badekabinet 4. vægkonstruktion 1 kan hedde ---AA4.UG1 og skole 1. Administration 1. kontor 3 kan hedde ===S1.A1.MA3. (Cuneco, 2012) I det nye høringsforslag Metode og struktur for informationsniveauer, udgivet pr. 16. november. Er der uddybet endnu et udkast omkring en ny opdeling af klassifikationsmetoden. Dette sker med bogstaver, og successiv underopdeling af emner, som skal gøre det lettere at finde de korrekte informationer. Forslaget er vist herunder på figur 24, dog skal det siges at dette stadig kun er et forslag under høring. Figur 23. Successiv underopdeling af emner Cuneco Forslaget viser klart, at systemet er et referencesystem, der binder Cuneco s andre systemer sammen. Systemet er endvidere bygget op så eksempelvis rum kan grupperes, så de projekterende har overblik herover. Efter koderne er påført, kan eksempelvis arkitekten føre koderne over i modelleringsprogrammet, hvorefter der kan påsættes ejerskabsforhold. En af Cuneco s succeskriterier er, at de standarder og data, der udvikles, kan implementeres og anvendes i de programmer, aktørerne bruger til hverdag. AALBORG UNIVERSITET IKT-aftalegrundlag 56

59 6.3 IKT-bekendtgørelsen BEK 1381 Efter initiativet Det digitale byggeri (DDB) har staten stillet en række krav ifm. anvendelsen af Informations- og kommunikationsteknologi (IKT). Disse krav kommer til udtryk i Bekendtgørelse om krav til anvendelse af informations- og Kommunikationsteknologi i byggeri. Seneste revidering er BEK 1381 af 13/10/2010 som stadig er gældende. (Økonomi- og Erhvervsministeriet, 2010) Det skal dog nævnes, at to nye bekendtgørelser i skrivende stund(oktober 2012) er til høring, og træder i kraft inden for kort tid. Senere i dette afsnit redegøres der for disse bekendtgørelser samt, hvad de ændrer i forhold til den gældende bekendtgørelse. IKT bekendtgørelsen er en del af regeringens ambition om at effektivisere den danske byggesektor gennem statslige kravstillelser. Det forventes, at et skub fra statens side vil sætte gang i den private sektor. (Regeringen, 2003) Den gældende IKT bekendtgørelse tager afsæt i statsbyggeloven, og vedrører herfor også kun de bygherrer, der er omfattet af denne. Dette inkluderer, ministerier og institutioner der figurerer på finansloven, samt har en minister som ansvarshavende. Bekendtgørelsen gælder for byggeri der helt eller delvist, er finansieret gennem lån eller tilskud fra staten. Dette er, når lånet eller tilskuddet udgør mindst 50 procent af byggeomkostningerne. Bekendtgørelsen vedrører deslige byggeri til institutioner, hvis drift er helt eller delvist betalt af staten, og når det samlede tilskud udgør mindst 50 procent. Det skal dog nævnes, at bekendtgørelsen kun finder anvendelse, på byggeopgaver med en anslået projektsum over 5 mio. kr. ekskl. moms. (Økonomi- og Erhvervsministeriet, 2010) Bekendtgørelsen stiller krav inden for fem områder. Disse fem områder omhandler hhv.: 1. Brugen af Dansk Bygge Klassifikation (DBK), hvilket er et klassifikationssystem udarbejdet under DDB. 2. Projektweb skal bruges til digital lagring af materiale 3. Digitale bygningsmodeller i 3D, der skal anvendes bygningsmodeller af det åbne format IFC. 4. Digitalt udbud med mængder, udbud og tilbud skal gennemføres i en internetbaseret udbudsportal. 5. Digital aflevering. Formålet med kravene er, at staten som bygherre blandt andet forpligter deres leverandører til at anvende en række fælles standarder. Der er lagt megen vægt på brugen af DBK-systemet i alle fem kravområder. De ovenstående krav beskrives nærmere i næste afsnit, og sammenlignes med paragrafferne i udkastene til de nye IKT-bekendtgørelser. For uddybende information omkring de 5 krav i den gældende bekendtgørelse, henvises der til selve bekendtgørelsen. (Økonomi- og Erhvervsministeriet, 2010) IKT-bekendtgørelsen og klassifikationssystemer Den nuværende IKT-bekendtgørelse læner sig stærkt op ad DBK klassifikationssystemet, hvilket som tidligere nævnt blev udarbejdet under DDB. (DBK klassifikationssystemet blev udviklet som erstatning for det tidligere SFB klassifikationssystem, da SFB mentes ikke at være specifik nok til større byggesager) Der har været omtale omkring DBK og om klassifikationssystemet er effektivt. Samarbejdet Digital AALBORG UNIVERSITET IKT-aftalegrundlag 57

60 Konvergens, er en samling af seks større virksomheder i byggeindustrien, der i 2008 udførte en test på klassifikationssystemet. De kom frem til konklusionen, at hvis DBK skulle blive en anvendt klassifikationsstandard, ville det være nødvendigt med ændringer svarende til de fem nedenstående punkter: 1. Ejerforholdet skal afklares: DBK skal forankres i en solid, ressourcestærk og kompetent ejer- og driftsorganisation 2. Videreudviklingen skal sikres: Der skal træffes aftale om den nødvendige videreudvikling og vedligeholdelse herunder om hvordan opgaverne finansieres 3. Formidling og vejledninger: Der skal udarbejdes praktiske vejledninger og læringsmateriale, rettet mod brugerne 4. DBK skal integreres i software-systemerne: Kodestrukturen skal tilpasses og software-leverandørene motiveres til at integrere DBK 5. DBK skal internationaliseres: DBK skal oversættes til engelsk og løbende tilpasses den internationale udvikling og andre nationale klassifikationssystemer (Digital Konvergens, 2008) DBK vandt aldrig indpas i den danske byggesektor. Grundet dette har Bygningsstyrelsen iværksat et udviklingsprojekt varetaget af Bips, kaldet Cuneco. Et af Cuneco gruppens indsatsområder er at erstatte DBK med det nye Cuneco Classification System (CCS). Det er ambitionen, at CCS skal kunne afklare strukturen og koden for bygningsdele. Eksempelvis i forhold til brug af klassifikation og referenceteknik forventer man, at udvikle en kode, der er stabil hele vejen igennem et byggeris livscyklus. Det forventes at CCS tages i brug i slutningen af (Cuneco, 2012) Sammenligning af SFB, DBK og CCS: Herunder vil de tre klassifikationssystemer blive sammenlignet: SFB DBK CCS - Fordele - Nemt at klassificere - Let at aflæse - Nem at have i tegningshovedet - Ulemper - Stor mulighed for (99) numre (fællesnumre) - Kun et tegningsnummer - Ikke særlig specifik - Uoverskuelig ved store byggesager, da der kan forekomme mange (99) numre - Ikke et referencesystem - Lever ikke op til nutidens krav - Fordele - Definerer præcist hvad der referes til - Kodningen kan nedbrydes i det omfang, det er nødvendigt - Ikke nogen div. klasse - Plads til udvidelse - Ulemper - Meget uoverskueligt system at klassificere med - Mulighed for at hægte egen kodestuktur ind i det eksisterende. - Fordele - Er lige så specifik som DBK - Kan deles op i rum eller bygningsdele - Bruges som referencesystem til resten af deres publikationer - Plads til udvidelse AALBORG UNIVERSITET IKT-aftalegrundlag 58

61 - Er overskueligt (pt. i høringsudgave) - Er mulig at bruge på både analoge og digitale projekt - Ulemper - Stadig under udvikling Tabel 8. Sammenligning af tre klassifikationssystemer, udarbejdet ifm. rapport Cuneco forsøger med CCS, at aflive de fejl og mangler, der har været pointeret i bl.a. SFB og DBK klassifikationssystemerne. Hvis CCS ender ud som tilsigtet, vil dette ende i et mere komplet og brugervenligt klassifikationssystem end tidligere. De kommende IKT-bekendtgørelser Byggebranchen er en evigt foranderlig branche, og i forbindelse med IT kommer der konstant nye muligheder og programmer til. I takt med disse fornyelser bliver IKT-bekendtgørelsen også hyppigt opdateret og omskrevet. Først ved tilblivelsen af bekendtgørelsen i 2008, dernæst med omskrivningen i 2010 og nu igen med to helt nye IKT-bekendtgørelser, den ene for offentligt byggeri, og den anden for alment byggeri. Det skal dog tages i betragtning, at de nye bekendtgørelser stadig er i høring (oktober 2012). (Økonomi og Erhvervsministeriet, 2012) (Økonomi- og Erhvervsministeriet, 2012) I bekendtgørelserne er der gået fra de fem bygherrekrav, til nu otte fokusområder, som principielt dækker over de samme områder. Punkterne er som følgende: IKT-ledelse Klassifikation Digital kommunikation Anvendelse af digitale bygningsmodeller og visualiseringer i idé- og projektkonkurrencer Anvendelse af digital bygningsmodel under projektering og udførelse Digitalt udbud og tilbud Digital aflevering ved byggeriets aflevering Digital mangelinformation Kravene til IKT-ledelse er en ny tilføjelse til bekendtgørelsen, hvor kravene til klassifikation, digital kommunikation, anvendelse af digitale bygningsmodeller og ned til digital aflevering dækker de samme områder som den nuværende klassifikation. Kravet til digital mangelinformation er endnu en ny tilføjelse til bekendtgørelsen. Hvad der konkret indgår i hvert af de otte punkter, er vist i tabel 9. (Økonomi- og Erhvervsministeriet, 2012) (Økonomi og Erhvervsministeriet, 2012) AALBORG UNIVERSITET IKT-aftalegrundlag 59

62 IKT-ledelse Klassifikation Digital kommunikation Anvendelse af digitale bygningsmodeller og visualiseringer i idé- og projektkonkurrencer Anvendelse af digital bygningsmodel under projektering og udførelse Digitalt udbud og tilbud Digital aflevering ved byggeriets aflevering Digital mangelinformation Tabel 9. Otte kravpunkter under de kommende IKT-bekendtgørelser, udarbejdet ifm. rapport. Bygherre skal udpege en IKT-ledelse i byggesagen, og stille krav om, at IKT-ledelsen gennem hele byggesagens forløb forestår den samlede IKTkoordinering på tværs af parterne. Bygherre skal stille krav om, at der anvendes et klassifikationssystem gennem hele byggesagen, således at alle byggeobjekter struktureres, klassificeres, navngives og kodes ensartet. I den forbindelse skal bygherren stille krav om, at byggeobjekterne indeholder de informationer, der er relevante for efterfølgende forvaltning drift og vedligeholdelse. Bygherren skal stille krav til relevante parter om, at der anvendes et internetbaseret system til digital kommunikation og arkivering af relevant information om byggesagen. Bygherren skal stille krav om, at der under projektering og udførelse anvendes objektbaseret bygningsmodellering. Bygningsmodellen afleveres som minimum i IFC- og originalformat. Bygherren skal stille krav om, at der under projektering og udførelse anvendes objektbaseret bygningsmodellering. Bygningsmodellen gøres som minimum tilgængelig i IFC- og originalformat for relevante parter. Bygherren skal stille krav om, at der ved udbud af byggearbejdet anvendes digitalt udbud, samt at tilbud afgives digitalt. Bygherren skal i samråd med eventuel driftsherre stille krav om digital aflevering af det byggesagsmateriale der vurderes relevant for dokumentation af byggesagen, det afleverede byggeri, samt den fremadrettede ejendomsforvaltning, herunder drift og vedligehold. Bygherren skal sikre, at der anvendes digitale mangellister. De kommende bekendtgørelser nævner hermed ikke krav til anvendelsen af et specifikt klassifikationssystem, og er deri mere åbne end den gældende bekendtgørelse, der nævner DBK i majoriteten af paragrafferne. Det er erfaret, at DBK ikke bliver/blev brugt i byggebranchen i dens tilsigtede omfang. Cuneco s klassifikationssystem CCS søger, at rette de fejl og mangler der blev påpeget i DBK. Dog er CCS ikke gjort til et krav i de nye IKT-bekendtgørelser. I bilagsform er der til de nye bekendtgørelser vedhæftet en vejledning til paragrafferne. AALBORG UNIVERSITET IKT-aftalegrundlag 60

63 Til alle former for IKT-koordinering anbefales det at udarbejde IKT-specifikationer, og det falder naturligt at IKT-lederen står for disse. I vejledningen til de nye bekendtgørelser henvises der til at bruge en IKT-aftale, der er udviklet inden for organisationen eller til at bruge bips IKT-specifikationer. Det skal så her nævnes, at visse specifikationer skal omskrives til den konkrete byggesag, hvilket de også ville skulle ved en udarbejdet standard fra eget firmas side. (Statens byggeforskningsinstitut, 2012) Anvendelsesområder af IKT-bekendtgørelserne Den nuværende IKT-bekendtgørelse BEK nr af 13/12/10, finder udelukkende anvendelse ved statsligt støttet byggeri. Dette inkluderer nybyggeri, om- og tilbygning, renovering og vedligeholdelse af byggeri samt anlæg knyttet til omfattet byggeri, jf. at byggeopgavens samlede anslåede projektsum overstiger 5 mio. kr. ekskl. moms. Ydermere finder bekendtgørelsen anvendelse for helt eller delvist statsfinansieret byggeri, når et lån eller tilskud udgør mindst 50 procent af byggeomkostningerne. Det samme gælder for byggeri til institutioner, hvis drift er helt eller delvist betalt af staten, når tilskuddet udgør mindst 50 procent. Her er bekendtgørelsen også kun gældende forudsat, at den samlede projektsum overstiger 5 mio. kr. ekskl. moms. (Økonomi- og Erhvervsministeriet, 2010) De to nye IKT-bekendtgørelser i høring finder hhv. anvendelse ved offentligt byggeri, og alment byggeri. Indholdet i de to bekendtgørelser er det samme, forskellen på dem ligger i anvendelsesområdet. Bekendtgørelsen om offentligt byggeri finder praksis i samme områder som gældende BEK nr. 1381, dog tillagt byggeri finansieret eller driftet af regioner og kommuner. Bekendtgørelsen finder anvendelse i region og kommunalt byggeri med en sum på over 20 mio. kr. ekskl. moms. I bekendtgørelsens 2 gives der mulighed for dispensation, for sager med entreprisebeløb mellem 5 og 20 mio. kr. ekskl. moms. Såfremt bygherren vurderer, at opfyldelse af et eller flere krav udgør en økonomisk byrde. Reglerne om digitalt udbud og tilbud kan dog ikke fraviges. IKT-bekendtgørelsen for alment byggeri er et nyt skud på stammen. Formålet med denne er, at inkludere en større markedsandel af bygge- og anlægssektoren i Danmark under lovgivningen. Bekendtgørelsen står for sig selv, og omfatter byggerier, der etableres med én eller flere af nedenstående tre punkter: 1) Byggerier der etableres i henhold til 115 i lov om almene boliger m.v. 2) Renoveringer i henhold til 91og 92, stk.1 og 3 i lov om almene boliger m.v. 3) Idé- og projektkonkurrencer som bygherren afholder i forbindelse med de byggerier, der er nævnt i nr. 1. De ovenstående 3 punkter, finder kun anvendelse på byggerier, renoveringer og idé- og projektkonkurrencer hvor byggeriets eller renoveringens samlede anslåede entreprisesum er på 20 mio. kr. ekskl. moms eller derover. Dette gælder hvor en almen boligorganisation, en kommune eller region er bygherre. (Økonomi og Erhvervsministeriet, 2012) Disse to kommende bekendtgørelser favner hermed langt bredere end den eksisterende BEK nr Almene byggerier og byggerier støttet regionalt og kommunalt er inkluderet i bekendtgørelserne, dette gør, at en langt større procentdel af alle bygge- og anlægsopgaver i Danmark, er omfattet krav om eksempelvis digitalt udbud og tilbud, IKT-ledelse, anvendelse af digitale bygningsmodeller mm. Dette gøres fra ministeriernes side for, at påvirke byggeindustrien til en Harmoniseret og værdiskabende anvendelse af informations- og kommunikationsteknologi (IKT) i bygge- og renoveringsopgaver i den almene og den AALBORG UNIVERSITET IKT-aftalegrundlag 61

64 offentlige sektor (Økonomi- og Erhvervsministeriet, 2012) (Økonomi og Erhvervsministeriet, 2012) Det er tilsigtet, at denne kravstillelse ved det offentlige og almene byggeri, skal afhjælpe en integration i byggesektoren som helhed i Danmark. Økonomisk fordeling af bygge- og anlægsopgaver i Danmark Det offentlige og almene byggeri i Danmark, udgør en stor post i byggesektoren som helhed. Nedenfor ses bygge- og anlægsopgaver fordelt på hhv. offentlige, støttede og private byggerier anno Offentligt byggeri 8% Alment støttet boligbyggeri 10% Erhverv 36% Ikke støttet boligbyggeri 46% Figur 24. Procentmæssig fordeling af byggeområder, nybyggeri og renovering, udarbejdet ifm. rapport. Kilde: Danmarks statistik 2010 Iht. Danmarks statistik dækker det offentlige byggeri sammen med alment støttet byggeri i Danmark 18 %, af den samlede anlægs- og renoveringssum for byggeopgaver. Med de kommende bekendtgørelser, bliver en stor del af disse 18 % omfattet af kravene til anvendelse af IKT i byggeriet, hvor den nuværende IKT aftale blot omfatter en lille del af de 8 %, som udgør det offentlige byggeri. Opsummering Regeringen kom i 2003 med udspillet staten som bygherre, som blev startskuddet for IKT aftalens fremkomst i byggeriet. Dette initiativ fremkom for at få effektiviseret byggeriet i Danmark, vha. Informationsteknologiske tiltag. Dette ledte efterfølgende til Det Digitale Byggeri, som var pilotprojektet herfor. Økonomi- og erhvervsministeriet har med udarbejdelsen af IKT-bekendtgørelsen tilstræbt at udarbejde en standard for, hvordan IKT-styringen i en byggesag skal foregå. Bekendtgørelsen dækker over statsligt byggeri over en grænse på 5 mio. kr. ekskl. moms. Udarbejdelsen af to nye bekendtgørelser der i øjeblikket er i høring, skal udvide området for, hvor det kræves at bruge kravene specificeret i bekendtgørelserne, bl.a. på kommunal- og regionsplan. Kravene dækker over en række områder omhandlende IKT-ledelse, AALBORG UNIVERSITET IKT-aftalegrundlag 62

65 anvendelse af digital kommunikation, digitale bygningsmodeller mm. De to kommende bekendtgørelser dækker over en stor del af de 18 % af byggesektorens produktionsværdi, hvor den hidtil gældende, blot dækker over den del af de 8 % af offentligt byggeri, der er støttet af staten. Ydermere er der i de kommende bekendtgørelser fjernet fokus fra DBK klassifikationssystemet, så det er mere åbent for aktører at anvende andre systemer som eksempelvis det kommende CCS. 6.4 IKT-Ydelsesspecifikation Som konkluderet i afsnit 4.1, samt i forbindelse med kvalitetshuset udarbejdet i sammenhæng med denne rapport, (figur 11) vil et specificeret IKT-aftalegrundlag både varetage de fleste interessenters interesser på samme tid med, at dette kan være med til at lette arbejdsgangen i byggeprojektet. Dette afsnit behandler den konkrete IKT-aftale, samt giver forslag til konkrete tiltag til denne. Under udarbejdelsen af denne rapport har det ikke været muligt, at rekvirere IKT-aftaler til NavitasPark byggeriet, og der tages herfor grundlag i IKT-aftaler og specifikationer udarbejdet af Københavns Ejendomme. Københavns Ejendomme og IKT Københavns Ejendomme har med grundlag i BIPS beskrivelser udarbejdet en række dokumenter, der tilsammen udgør et komplet IKT-aftalegrundlag, her er tale om hhv.: IKT-Ydelsesspecifikation IKT-Teknisk afleveringsspecifikation IKT-Teknisk CAD-specifikation IKT-Teknisk kommunikationsspecifikation IKT-Teknisk udbudsspecifikation IKT-Bilag Selvom der tages udgangspunkt i BIPS beskrivelsesværktøjerne, har Københavns Ejendomme (KEjd) en lang række tilføjelser til disse beskrivelser, hvilke kan læses under de enkelte specifikationer. Ydelsesspecifikationen tager afsæt i den projektspecifikke beskrivelse fra BIPS. De omfattende ændringer og tilføjelser KEjd har til beskrivelsen, er markeret med en fed streg i venstre margin af dokumentet. De specifikke afsnit i beskrivelsen der gør sig gældende i pågældende projekt, skal markeres med en afkrydsning i højre side af dokumentet som tilvalgt. Nedenfor gives et eksempel på strukturen i dette: AALBORG UNIVERSITET IKT-aftalegrundlag 63

66 På denne måde er KEjd s rettelser og tilføjelser til BIPS beskrivelsen let overskuelige, og der er ingen tvivl, om hvad der gælder, og hvad der er aktuelt i den specifikke beskrivelse. Den række tilføjelser KEjd har til BIPS beskrivelsen, bidrager som en samlet helhed til en specifik og gennemarbejdet aftale. Der lægges vægt på, hvem der skal udføre hvilke dokumenter, og hvor ansvarsområderne placeres mv. Som eksempler på tiltag KEjd har til beskrivelsen er følgende. (I de tilfælde der er specifikke ansvarshavende, markeres denne med fed) Rådgiver udarbejder IKT-teknisk Kommunikationsspecifikation og evt. bilag. Dette gøres efter kontraktindgåelsen. Københavns Ejendommes paradigmer skal anvendes. (Rådgiver) Fil og mappestruktur skal følge strukturen angivet i den projektspecifikke IKT-tekniske CADspecifikation, som KEjd har udarbejdet. (Alle) (Rådgiver) Filformater iht. IKT-teknisk kommunikationsspecifikation (Alle) IKT-teknisk CAD-specifikation skal udarbejdes af rådgiver efter kontraktindgåelse. Københavns Ejendommes paradigmer skal anvendes (Rådgiver) En lang række krav til tegningsproduktion, projekttegninger, arbejdstegninger i læsbart A3-format, specificering af simulering, faser, filformater, informationsniveauer i fællesmodeller osv. Ved alle disse tilføjelser er hæftet en ansvarshavende. (Alle) Udbud iht. IKT-teknisk udbudsspecifikation, udarbejdet af KEjd. Udbuds-og tilbudsportal tilvejebringes af Bygherren, samt den ansvarlige for digitalt udbud ifm. IKT bilag 1, Projektorganisation. (Bygherren) (Ansvarshavende specificeret i andet dokument) D&V-dokumentation til bygherren skal afleveres digitalt via Projektweb Procesdokumenter, formater og metoder iht. IKT bilag 2, Fil og mappestruktur, IKT-teknisk kommunikationsspecifikation og IKT-teknisk afleveringsspecifikation Objektegenskaber til brug for D&V iht. IKT bilag 3, Objektegenskaber Drift- og vedligeholdelsesinformation, bygningsmodel og dokumenter iht. IKT-teknisk afleveringsspecifikation; IKT bilag 2, Fil og mappestruktur og IKT bilag 3, objektegenskaber. Mfl. (Københavns Ejendomme, 2012) KEjd har udviklet dette IKT-aftalegrundlag af en lang række grunde med mange forhåbninger, og ønsker for tiltaget. Det forventes, at der skabes et bedre overblik over KEjd s bygningsportefølje, at udbudsweb og projektweb sparer KEjd for ressourcer, og at BIM optimerer nuværende processer. Disse samt andre giver en forventning om billigere og bedre byggeprojekter, optimering af drifter af bygningsporteføljen og hurtigere samt nemmere tilgang til informationer om KEjd s bygninger. (Københavns Ejendomme, 2012) BIM og de tilhørende arbejdsprocesser, aftalegrundlag (IKT) mv. ses af organisationen som et godt bud på en effektivisering af byggeprojekter inden for egen organisation, samt på landsbasis. I ethvert projekt, produkt og virksomhed er det kloge valg, at effektivisere arbejdet mest muligt teknologisk og arbejdsprocesmæssigt. Tankegangen at undlade at lave ikke værdiskabende arbejdsopgaver, ikke spilde tid og arbejdskraft, dette ligger sig endvidere stærkt op ad LEAN tankegangen, Se kapitel 5.3 for LEAN. AALBORG UNIVERSITET IKT-aftalegrundlag 64

67 NavitasPark og IKT I henhold til kvalitetshuset (figur 11), udarbejdet ifm. denne rapport, er det i aktørernes interesse, at have et stærkt og specificeret IKT-aftalegrundlag. Selve aftalegrundlaget brugt på NavitasPark, er udfærdiget i 2010, og er hermed af åbenlyse årsager ikke opdateret til i dags standarder, da især IT-værktøjer brugt i byggesager udvikles hurtigt. I forbindelse med dette afsnit, og med hensynstagen til interessenternes afdækkede ønsker og interesser i det udarbejdede kvalitetshus i rapportens kapitel 4. Gives et forslag til en IKT-ydelsesbeskrivelse med afsæt i de nyeste værktøjer, bekendtgørelser og standarder der er tilgængelige i dag. (december 2012). Denne ydelsesbeskrivelse findes i bilag 01. Da det ikke har været muligt at rekvirere IKT-aftalegrundlaget brugt til NavitasPark, tages der til ydelsesspecifikationen grundlag i KEjd s ydelsesspecifikation af , samt BIPS ydelsesbeskrivelse af Dette flettes sammen med rapportens andre relevante områder. Herunder CCS, IKT-bekendtgørelser i høring mfl. Bilag 01, skal ses som et praktisk forslag til en del af det projektspecifikke aftalegrundlag. Som det kan ses i bilaget, er størstedelen af punkterne, fra afsnit 2 digital kommunikation til afsnit 5 digital aflevering afkrydset som tilvalgt. Dette er gjort, da de nye IKT-bekendtgørelser i høring stiller en række krav/anbefalinger til, hvad der skal specificeres (se rapportens afsnit 6.3 omkring kommende IKTbekendtgørelser). Ydermere er det konkluderet ud fra kvalitetshuset figur 11, at det er i aktørernes interesse at få et specificeret IKT-aftalegrundlag. Nedenfor er oplistet en række krav fra IKTydelsesbeskrivelsen. Der henvises igen til Bilag 01 for den samlede ydelsesbeskrivelse udarbejdet ifm. denne rapport. Der anvendes CCS til klassifikation af projektinformation Fast internetforbindelse på pladsen på mindst 15 Mbit download, samt A3 farveprinter Bips A104, dokumenthåndtering anvendes til s Simuleringer over varmetab, ventilation, akustik og dagslys er specificeret Konsistens og kollisionskontrol er specificeret Specifikke regler for hvornår hovedfil skal synkroniseres Ansvarlige for digital aflevering, digitalt udbud/tilbud mv. Mfl. Denne ydelsesbeskrivelse vurderes, at kunne fungere som en del af den samlede løsning, der kan være med til at mindske fejl og mangler i byggesagen, heriblandt spildtid, uenigheder mm. Forudsætningen for at kunne bruge et specificeret aftalegrundlag, er dog at byggesagens aktører accepterer dette. 6.5 IKT Delkonklusion I henhold til kvalitetshuset figur 11, er en skærpelse af IKT-aftalegrundlaget på NavitasPark byggeprojektet vægtet med 340 point, hvorimod en nedtoning af aftalegrundlaget blot er vægtet 90 point. Disse to muligheder afskriver automatisk hinanden. Hvorfor det er valgt mest i interessenternes interesse, at arbejde med et meget specificeret IKT-aftalegrundlag. IKT anses som en nødvendighed med statens øjne for at optimere byggebranchen. To nye IKT-bekendtgørelser er pt. i høring, hvilket bringer en række nye krav ind for dette område, der udvider IKT-aftalens indvirkning i byggebranchen som helhed. Udviklingsprojektet Cuneco vil med klassifikationsstandarden CCS endvidere bidrage til udviklingen af IKT, med et nyt og forhåbentligt bedre reference- og klassifikationssystem end tidligere, såsom SFB og DBK. AALBORG UNIVERSITET IKT-aftalegrundlag 65

68 Med baggrund i interviews, indsamlet information, CCS og kvalitetshuset (figur 11) er der givet forslag til en sags-specifik IKT-ydelsesbeskrivelse (Bilag 01). Den menes at kunne løse de dele af interessenternes behov afdækket i forbindelse med IKT. AALBORG UNIVERSITET IKT-aftalegrundlag 66

69 7. Dataudveksling og proces Dette kapitel omhandler teknologidelen i Leavitt s model. Der redegøres for, hvordan udvekslingen af IFC modeller kan systematiseres ved hjælp af IDM, og de værktøjer der er knyttet til denne. Derudover redegøres der grundlæggende for IFC, der ligger som baggrund for at bruge og udvikle IDM, samt grundlæggende om BSDD, en oversætter til at sikre entydighed på tværs af lande- og sproglige grænser. De sidste mange år er det blevet mere og mere almindeligt, at arbejde med Bygnings Informations Modellering(BIM), og bygningsmodeller indenfor byggebranchen. Meningen med BIM er, at disse modeller kan indeholde flere informationer om byggeprojektet end de traditionelle CAD tegninger. Disse informationer skal kunne deles på tværs af aktører(arkitekt, ingeniør, entreprenør osv.) for, at minimere redundans gennem gentagende arbejdsgange som f.eks. at finde de samme data flere gange. En udfordring som følge af dette er, at de forskellige aktører har behov for forskellige værktøjer, og at disse ikke er så gode til at snakke sammen. BuildingSMART (tidligere IAI) har siden midten af 90 erne arbejdet med udfordringen, at kunne dele BIM modeller mellem forskellige værktøjer uden at information går tabt i overførslen. Resultatet af dette arbejde er Industry Foundation Classes (IFC). IFC er en vidtspændende informations model, der er udviklet til at være en åben standard til deling af BIM modeller. Eftersom at IFC er udviklet til at kunne håndtere alle almindelige informationer om et byggeprojekt, gør det formatet meget komplekst. Implementering af alt det IFC formatet indeholder, er derfor nærmest utænkelig. Trods stor indsats fra både softwareudviklere og BuildingSMART, har det været svært at udveksle pålidelige og forudsigelige BIM data. (BuildingSMART, 2012) Computere kan ikke fortolke geometri på samme måde, som mennesker kan. Derfor er det vigtigt, at Downstream 3 værktøjer modtager nøjagtig information fra Upstream 4 værktøjer. Dette er en fundamental grund til at udvikle og bruge Information Delivery Manual (IDM). IDM foreslår en metode, der opfanger og integrerer byggeprocessen, og samtidig giver detaljerede brugerdefinerede specifikationer af de oplysninger, der skal udveksles på bestemte punkter/rækkefølger i et projekt. (BuildingSMART, 2012) Open BIM For at sikre et åbent Workflow der er medvirkende til et bedre samarbejde mellem byggeriets aktører, har BuildingSMART i samarbejde med flere førende BIM software udviklere taget initiativ til Open BIM. Open BIM er en universel tilgang til samarbejdsbaseret design, realisering og drift af bygninger baseret på den 3 Den modtagende part. (Pull funktion) 4 Den afsendende part. (Push funktion) AALBORG UNIVERSITET Dataudveksling og proces 67

70 åbne IFC standard. Dette er med til at skabe en bedre konkurrence, idet alle kan deltage uanset værktøjs løsning. (BuildingSMART, 2012) IFC Industry Foundation Classes (IFC) er et format i skemastruktur, udviklet til elektronisk at repræsentere alle aspekter af et byggeri over hele dets livscyklus. Det er designet til, at kunne udvides i takt med, at brugerbehov defineres, og at IT-værktøjer bliver mere avancerede(bips2012). Formatet er baseret på ISO STEP EXPRESS sprog og koncept. IFC muliggør, sammen med BSdd (før IFD) og IDM, brug af Open BIM, og er et alternativ til proprietære formater. Open BIM giver aktører mulighed for at benytte og udveksle informationsrige bygningsmodeller på tværs af software værktøjer uanset udgiver. (BuildingSMART, 2012) Den første udgave af IFC(IFC 1.0) blev lanceret i januar (VTT Building Technology; IAI International Council, 1999), og er løbende blevet opdateret, hvor den seneste version er IFC4 fra september IFC4 er blevet forbedret med en række nye features, som er fuldt integreret med MVD teknologi, automatisk genererede ændrings log mm. Den seneste opdatering er sendt til den internationale standardiserings organisation (ISO) til godkendelse som en fuld international standard ISO (BuildingSMART, 2012) En problematik, som kan opstå ved brug af IFC formatet til udveksling, er manglende import/eksportmoduler i software værktøjerne. Dette bevirker, at information kan gå tabt i udvekslingsprocessen. BuildingSMART har arbejdet med at udvikle en metode, der definerer nogle specifikationer, som efterfølgende kan implementeres i software værktøjerne. Denne IDM metode vil blive beskrevet i afsnit 7.1. BSdd(IFD) BuildingSMART Data Dictionary (BSdd), før kaldt International Framework for Dictionarys (IFD) danner grundlag for en fælles terminologi i anvendelsen af åben BIM, så alle modeller tolkes entydigt af alle aktører. Information kan herved automatisk oversættes fra sprog til sprog, uden fejl og tab af data (Norge) (BuildingSMART, 2012)BSdd er en standard, der arbejder sammen med IFC og IDM, og er baseret på ISO (Framework for object-oriented information)standarden. BSdd fungerer på den måde, at navn og sprog separeres fra selve konceptet, således ikke at udføre direkte oversættelser. I stedet anvendes konceptet separat, og der findes relationer, som tilkobles. Herved sikres en automatisk og entydig overførsel af alle objekters egenskabsdata. For en grafisk illustration af dette kan henvises til IFD Library hjemmeside på: Alle entiteter 5, som indgår i en BSdd får en Global Unique Identifier (GUID) Dette er en 22 karakterstreng, der fungerer som hver entitets CPR nummer. Dette er med til at sikre situationer, som f.eks. med det engelske ord Beam", der kan have flere betydninger (bjælke, lysstråle, en sejlbåds sejlbom osv.), beholder sin oprindelige betydning. En anden situation, som BSDD ved hjælp af GUID skal sikre, er illustreret på Figur Ontologisk samlebegreb for noget der eksisterer i sig selv, genstande, egenskaber, processor osv. AALBORG UNIVERSITET Dataudveksling og proces 68

71 Figur 25. BSdd medtager det som almindelige ordbøger ikke gør Figuren viser, at en dør på norsk oversat til engelsk ved hjælp af en almindelig ordbog kommer til at hedde door. Men den norske dør definerer en dør med tilhørende karm, hvorimod den engelske door kun definerer dørbladet. Skal døren beholde sin betydning, skal den oversættes til door-set. Dette gøres, som beskrevet ovenfor, ved at BSdd separerer navn og definition fra selve konceptet, og definerer det på sproget, som det skal oversættes til. (Bjørkhaug & Bell) En integreret proces Rapporten, An Integrated Process For Delivering IFC Based Data Exchange udarbejdet af Building SMART, beskriver: En integreret proces for design, implementering, certificering og brug af standard information for den globale byggebranche, der består af fire faser. Disse er som vist på Figur 26. De fire processer. I det følgende beskrives der kort, hvad de fire faser indeholder samt en uddybning af de to første, hvor fokus er lagt. (IDM og MVD) Figur 26. De fire processer. BuildingSMART Den første fase, IDM, definerer en proces, der involverer mindst to typer software værktøjer, og den information der skal udveksles mellem disse. Den er inddelt i fire hovedområder, der omfatter følgende: 1. Udarbejdelse af et proces-kort (BPMN), der definerer en arbejdsproces samt, hvornår information bliver håndteret og videregivet. Hvornår arbejdsopgaver starter, slutter eller er i gang. 2. Formulering af udvekslingskrav (Exchange Requirements), hvilket definerer den information, der skal udveksles ved de respektive processer, som kommer til syne i den udarbejdede BPMN. AALBORG UNIVERSITET Dataudveksling og proces 69

72 3. Exchange Requirement Models (ERM) som organiserer udvekslingskravene til udvekslingskoncepter, der vil linkes til Model View Definitions (MVD), og gør det muligt at verificere, at alle krav er opfyldt. 4. Formulering af en BIM guide der har til opgave at dokumentere vejledning til brugeren omkring, hvilke objekter og hvilken data der skal være inkluderet i den BIM, der skal udveksles. Næste fase, MVD, definerer en delmængde af IFC model specifikationerne, som er nødvendige for den udveksling af oplysninger defineret i en eller flere relaterede IDM er. MVD er inddelt i tre hovedområder, der omfatter følgende: 1. Udarbejdning af MVD oversigt/beskrivelse, der definerer omfanget af MVD en, især IDM erne den er rettet mod. 2. Udarbejdning af MVD diagram som definerer MVD koncepterne, der anvendes i udvekslingen såvel som opbygningen og relationerne mellem koncepterne. 3. Implementeringsvejledning af koncepterne som definerer IFC enheder, der anvendes til udveksling af hvert koncept, og de iværksætteraftaler som reducerer gennemførelsesrækkevidden, der ellers ville blive krævet af IFC skemaet. Tredje fase, software implementering og certificering: Når IDM og MVD er defineret, skal disse indarbejdes i softwareværktøjerne. Her er det nødvendigt med teknisk support til udviklerne for en god implementering. For at sikre en pålidelig dataudveksling skal værktøjerne også testes, og certificeres af en tredje part for, at bekræfte om implementeringen er i overensstemmelse med specifikationerne defineret i IDM og MVD. Fjerde fase, BIM Validering: Dette er en test, der burde gøres for hver enkelt udveksling i et projekt selvom der er brugt certificeret værktøj. Den kontrollerer om eksport applikationen har overholdt kravene fra værktøjet, om brugeren har anvendt værktøjet korrekt, og om slutbrugerens krav er overholdt. (BuildingSMART, 2012) 7.1 IDM Der udvikles IDM er på mange niveauer, være det internationalt, nationalt, fagligt eller virksomhedsmæssigt. En IDM består af to dele, en procesdel og en datadel. Datadelen skaber sammenhæng til IFC modellen gennem en MVD, denne beskrives senere i dette kapitel. Hvorimod procesdelen bruges til at kortlægge, hvilke informationer der skal udveksles og hvornår. Denne del kan også anvendes alene uden datadelen, f.eks. indeholder de dansk udviklede IDM er om arealer og kollisionskontrol kun proces delen. En IDM kan opnå en formel godkendelse af BuildingSMART som kræver, at den opfylder en række krav.(bips) Disse krav kan der læses mere om på BuildingSMART s hjemmeside. IDM metoden er godkendt som en ISO-standard Methodology and format. De nye rapporter fra Cuneco der i skrivende stund(november 2012) er ved at lægge sidste hånd på et nyt klassifikations system, hælder meget imod principperne i procesdelen af IDM. De lægger op til, at der allerede i analysefasen indgås en aftale om, i hvilket informationsniveau de enkelte bygningsdele skal ligge på gennem hele projektfasen. I afsnit 7.5 er der beskrevet yderligere om Cuneco og det nye klassifikationssystem. AALBORG UNIVERSITET Dataudveksling og proces 70

73 Inden arbejdet på en IDM påbegyndes, skal projektets omfang formuleres (IDM Scope). Dette skal fastlægge om der allerede findes værktøjer, der understøtter samme proces osv. Denne formulering skal skabe sammenhæng til Business Use Case. Den første opgave af selve IDM aktiviteterne er at udvikle en Business Use Case, som identificerer processens deltagere, hvilken information og format der skal udveksles og til hvilket formål. Business Use Case er en fortællende beskrivelse af processen, og den skal fastsætte anvendelsesområdet, sammenhænget, detaljeringsgraden og det forventede resultat. IDM Activity TechGroup Figur 27. IDM aktiviteterne BuildingSMART Det næste er at udarbejde proces-kort, som er en visuel repræsentation af den beskrevne proces i Use Casen. Formålet er, at kortlægge informationsflowet i en arbejdsproces. Tredje aktivitet i IDM processen er at beskrive udvekslingskraverne (Exchange Requirements), som repræsenterer forbindelsen mellem proces og data. AALBORG UNIVERSITET Dataudveksling og proces 71

74 Indholdet af en IDM Figur 28. IDM Basic Framework BuildingSMART Ved udviklingen af en IDM er der som tidligere nævnt flere faktorer samt processer, der skal overholdes for, at kunne opnå fuldt udbytte af arbejdet. Derudover skal en IDM, kunne understøttes af software fra både eksporterende såvel som modtagende parter for at blive anvendt effektivt. Selve indholdet af IDM en er udformet af mange forskellige typer regler og informationer, samt viser aktørerne, hvem der skal forestå hvilke opgaver. Ovenstående figur 28 viser de nødvendige inputs for, at udvikle en komplet IDM og, hvad de hver især indeholder. Figuren er inddelt således, at den øverste del indeholder beskrivelserne, som rådgiverne har behov for, mens bunden hører til software udviklerne med de tekniske aspekter. Proces map - PM En proces map beskriver de aktører, der er involveret i en IDM proces, men i særdeleshed informations flowet der relaterer sig til deres indbyrdes aktiviteter. Den repræsenterer en visuel grænse for, hvor meget information der kommer til at indgå i den specifikke proces. Derudover bestemmer den, hvilke informationer der skal udveksles samt, hvornår i byggeprocessen de skal forbruges, og produceres. en PM kan sammenlignes med en udspecificeret projekteringstidsplan, hvor alle arbejdsprocedurer og databehov er vist i sammenhænge mellem aktiviteterne (sekvensbaserede). Den har klare fordele i den digitale projektering, idet den præcist klarlægger, hvad de forskellige parter kan forvente af hinanden. Det vælges, at vise kortet via en BPMN(Business Process Modelling Notation) der illustrerer arbejdsprocesserne, som beskrives længere henne i dette afsnit. Reference processes - RP Gennem arbejdet med IDM er og MVD er produceres der genanvendeligt materiale, som direkte kan overføres til flere forskellige typer PM er. En RP kan defineres som en basal bestanddel af proces maps, AALBORG UNIVERSITET Dataudveksling og proces 72

75 f.eks. en aktivitet der er entydig såvel i dets betydning som i dets attributter. Formålet med RP er på sigt at danne reference biblioteker, hvor nødvendige units til ens PM kan hentes, for derved at skabe en større standardisering. Herved skabes både fordele på tidsaspektet i en IDM proces, samt entydighed i det senere udsendte materiale ved, at udviklerne anvender samme komponenter. Exchange Requirements ER ER beskriver et sæt af informationer, der skal udveksles mellem forskellige parter i en byggeproces på et specifikt tidspunkt i projektet. Herved kan det præcist synliggøres, hvilket indhold der er nødvendigt for at imødekomme en given opgaves udførelse senere i projektet. Måden informationen deles på foregår som en ikke teknisk beskrivelse, idet brugerne der definerer kravene i ER primært består af: arkitekter, ingeniører, konstruktører mm. Dokumentet/dataobjektet kan senere anvendes af softwareudbydere til at definere informationssættet i f.eks. Industry Foundation Classes (IFC) eller Geographic Markup Language (GML) etc. En ER inddeles i 4 kasser, hvor den nødvendige datamængde opstilles ud fra en template. Sektionstype Overskrifts sektion Oversigts sektion Informations sektion Resultats sektion Beskrivelse af sektion Administrativ information: Titel på ER, unique identifier kode, datomærkning samt log over ændringer, personmærkning, tildeling af hvilke projektniveauer ER er gældende til Kort beskrivelse for administrator/udvikler: Klar og præcis tekst uden tekniske referencer såsom formater der kan forklare alle bruger, hvad ER typens mål og brug omhandler. Detaljeret ikke teknisk beskrivelse: Sammensætning af information units 6 til at udgøre den specifikke ER til senere udveksling Udfald af den specifikke ER: Hvilken form skal den udveksles i, beskrivelse af indeholdt information, skalering af relevans for bruger, brugerens rolle beskrives Tabel 10. Exchange Requirements struktur, udarbejdet ifm. rapport Functional parts FP En FP også kaldet unit of information er den tekniske del, der er nødvendigt for en software specialist således, at kunne danne ER, der kan udveksles mellem aktørerne. Den vises i skemaform som en informationsmodel, der kan stå alene men samtidigt indgå som en delmængde i den informationsmodel som er baseret på f.eks. IFC datamodellen. I størrelsesorden kan en FP sammenlignes med et objekt, en attribut eller et property set i en bygningsdel, som en modtagende part behøver. Der er visse regler der gør sig gældende, når sammenhængen mellem hhv. FP og ER, skal forklares: 6 Principielt det samme som Functional parts der beskrives i næste afsnit. AALBORG UNIVERSITET Dataudveksling og proces 73

76 En ER kan genereres via sammensætning af flere FP er (ER = FP) En FP kan genereres ud fra en sammensætning af flere FP er (FP1 = fp1+a+b), dog skal det tilsikres, at der ikke opstår flere versioner med samme entitet i det samlede skema. I så fald skal skemaet tilrettes. En ER kan indeholde andre ER samt FP (ER2 = ER1+FP1+FP2) En FP kan aldrig indeholde ER, men kan indeholde andre FP, der definerer ER. For visuel beskrivelse af ovenstående regler se slideshow på følgende webadresse: Ligesom ER er FP også inddelt i særlige sektioner således at skabe entydighed. Sektionstype Overskrifts sektion Beskrivelse af sektion Administrativ information: Titel på FP, unique identifier kode, skema navn og datomærkning, logbog samt beskrivelse af evt. ændringer Oversigts sektion Kort beskrivelse for administrator/udvikler: Klar og præcis tekst med moderat beskrivelse af det tekniske indhold der også kan forstås af en bruger med, hvad FP typens mål og brug omhandler. Resultat sektion Kort, præcis beskrivelse: Hvad skal FP kunne levere, og hvordan er den sammensat Teknisk koncept sektion Teknisk opbygning: Beskrivelse af nødvendig information samt specificering, navngivelse af entiteten/attributten/property set jf. IFC terminologien, afkrydsning af vigtigheden af FP Liste sektion Liste bestående af anvendte: Entiteter, datatyper, funktioner, property sets, andre FP er, Concepts anvendt i selve FP Skema sektion Præsentation: Visning af FP i hhv.: EXPRESS G(grafisk illustration), EXPRESS(tekstbaseret) eller ifcxml(tekstbaseret) Eksempel sektion Tabel 11. Functional parts struktur, udarbejdet ifm rapport Guide: Praktiske eksempler der kan anvendes som rettesnor især i de tidlige udviklingsstadier Concepts En FP er opbygget af flere units benævnt Concepts eller Units of Functionality, som definerer de forskellige begreber og de grundlæggende funktioner indeholdt i hver FP. Det kan f.eks. bestå af navngivning, identifikation af fil, div. aktiviteter, men ligeså vigtigt er relationerne mellem de forskellige entiteter. AALBORG UNIVERSITET Dataudveksling og proces 74

77 Exchange Requirement Model - ERM En ERM er den tekniske løsning på en ER, som dannes ud fra et sæt FP er, og er derved afhængig af en struktur i form af et skema(ifc). En praktisk ting er, at flere af de eksisterende concepts kan genanvendes og derved spare tid, samt at alle anvender de samme komponenter. Den har en særlig vigtig funktion, da den er bygget op omkring Business Rules, som forklares nærmere senere, og kan understøttes af software applikationer til formidling af information. Samtidigt udgør den en del i Model View Definitionen(MVD), som softwareproducenterne skal bruge ifm. deres arbejde, og komponenterne indeholdt i ERM kan danne grundlag for validerings tests. Business Rules - BR BR har til formål at beskrive operationer, definitioner og begrænsninger der kan tilsluttes et datasæt i en bestemt proces eller aktivitet. De gør det muligt at udføre kontrol på hhv.: anvendelse af særlige entiteter attributter og egenskaber der skal anvendes i den specifikke model værdier, værdiskalaerne eller grænseværdier, som skal observeres afhængigheder mellem entiteter, attributter eller attributværdier (See, Karlshøj, & Davis, 2011) Reglerne kan beskrives vha. et regelskema som en del af en database, eller via IFC begrænsningerne. Formålet med BR er, at kunne variere indholdet i informationsmodellen, således at passe til en specifik forretningsprocedure uden, at skulle lave indgreb i selve skemaet. Herved skabes et mere fleksibelt skema, der kan håndtere flere typer BR sæts ad gangen foruden, at behandlingen af dem ikke får betydning for det underliggende informationsskema. BR eksisterer også i flere plan f.eks. projekt niveau, nationalt niveau etc. Verification and Validation tests Ved udviklingen af en IDM er det vigtigt, at udøve en kontrol ift. produceret materiale der påviser, hvorvidt den lever op til kravene. Grundige kontroller på softwareapplikationerne udføres, som skal kunne importere og eksportere data. Disse gennemgås på forskellige niveauer bl.a. verificering og validering, som hver især kan beskrives ud fra ISO 9000 Kvalitetsstyring: Verificering: Bekræftelse ved undersøgelse og tilvejebringelse af objektivt bevis af, at de specificerede krav er blevet opfyldt. Formålet er at tilsikre, at resultat opfylder de stillede og ønskede krav i grundlaget, og en registrering af resultatet udføres. Dette udføres via certification testing, hvor behovene via IFC2x3 Coordination View Version fra 2010 sammenholdes i den pågældende IDM/MVD, med hvert objekt i filen. Validering: Bekræftelse ved undersøgelse og tilvejebringelse af objektivt bevis af at kravene til en specifik tiltænkt anvendelse er blevet opfyldt. 7 et subset af IFC AALBORG UNIVERSITET Dataudveksling og proces 75

78 Formålet er en mere praktisk tilgang til kontrollen af udvekslingen, hvor fokus ligger på brugeren og dennes måde at tildanne udvekslingsdata på. Testen skal kontrollere at værktøjerne anvendt i udvekslingssoftwaren, såsom eksport applikationerne, business rules samt generel brugerhåndtering for den sendende såvel som den modtagende part, anvendes korrekt. 7.2 Model View Definition - MVD Model View Definition er den tekniske del i IDM en som, skal anvendes ifm. import og eksport af data, mellem forskellige parter i byggeprocessen. Den indgår som Phase 2 i udviklingen af en IDM(se figur 26), og støtter måden informationerne udveksles på via softwareapplikationer. En MVD udgør en delmængde af IFC specifikationen også kaldet et view, der udveksler Exchange Requirements ud fra IDM skemaet. Denne delmængde består af flere IFC koncepter såsom: classes, attributes, relationships, property sets, quantity definitions etc. (BuildingSMART, 2012)Nedenstående figur 29 viser groft, hvordan en MVD hører inde i IFC informationsmodellen, og kan defineres som værende den del af IFC formatet, som specifikt anvendes til at udveksle den givne Exchange Requirement. Her ses, hvordan der gennem samling af forskellige functional parts kan dannes grundlag for en MVD, som f.eks. en energi- og indeklima ingeniør kunne gøre brug af. Tekla Flow/tryktab MagiCad Archicad Statiske egenskaber Overflader MVD IFC Figur 29. MVD indeholdt i IFC formatet, udarbejdet ifm rapport 7.3 Business Process Model and Notation BPMN BPMN er en notationsform til at præsentere specifikke forretningsprocesser på i form af en BPD(Business Process Diagram). Den baserer sig på flowdiagrammer, der afbildes som grafiske elementer, der repræsenterer forskellige arbejdsopgaver og deres sammenhæng. Formålet og i den grad fordelen med denne kommunikationsform er, at yde support til alle involverede i et projekt ligegyldigt om de er forretningsfolk eller IT-specialister. Herved opnås, at begge parter får et fælles sprog, samt får en fælles opfattelse af løsningen. De grafiske procesmodeller anvendes både som dokumentation for AALBORG UNIVERSITET Dataudveksling og proces 76

79 kravspecifikationen til de IT-systemer, der skal understøtte de modellerede forretningsprocessor. Men også til dokumentation af virksomhedens forskellige arbejdsgange og forretningsprocesser. Der er desuden en klar sammenhæng mellem den grafiske del og den underlæggende formelle opbygning med BPEL(Business Process Execution Language), som er et standardiseret eksekveringsformat til specificeringen af forretningsprocesser. Det kommer af, at BPMN er udviklet til SOA 8 og webservices således, at der kan bygges videre på tidligere standarder. Der findes flere formater, dog fokuseres der på BPEL og XPDL i afsnittet eftersom den generelle opfattelse i markedet er, at det er de vindende standarder. (Devoteam Fischer & Lorenz, 2005) For at opnå den optimale dataudvekslingsproces skal der være særlig fokus på planlægning således hvad, hvornår og i hvilken form er defineret, før et projekt påbegyndes. I denne forbindelse eksisterer også andre typer konceptuelle modeller til organisering af processer såsom: Unified Modelling Language, Entity- Relationship models og IDEF0. De griber arbejdet forskelligt an, og vurderes ikke at have den samme optimale effekt på IDM som BPMN har, og beskrives derfor ikke yderligere i afsnittet. BPEL WS-BPEL BPEL4WS BPEL udspringer fra det tidligere metasprog 9 BPML(Business Process Modeling Language), og er en forkortelse af WS-BPEL samt BPEL4WS(Web services business process execution language). Det er et XML baseret sprog til definition af workflow samt forretningsprotokoller til interaktion. Den er opbygget i 2 forskellige dele hhv.: Procesbeskrivelsessprog Specificerer gængse byggeblokke til processer såsom aktiviteter, flows, forbindelser, data containere og opgave operationer. De defineres iht. XML strukturen uden en grafisk repræsentationsmodel. Infrastrukturgrundlag Bygger på WSDL 10 (Web services description language) og anvendes til at beskrive relationerne mellem virksomheder og processer og en web service-baseret infrastruktur. (Jensen, 2006) XPDL XML Process definition language anvendes ligeledes til udvekslingen af procesbeskrivelser udviklet i et grafisk værktøj, og proces flow der automatisk kan afvikles af en proces engine. Strukturmæssigt er BPMN og XPDL meget ens og medtager alle aspekterne af BPMN diagrammet. Den grundlæggende forskel på BPEL og XPDL ligger i, at BPEL ikke definerer den visuelle del, hvorimod XPDL gør. Den bliver defineret som et procesdesignformat, idet den indeholder vektor koordinator samt forbindelser mellem proces flows. Det kan sammenlignes med et målestoksforhold af en-til-en, idet den gengiver et nøjagtigt billede af den oprindelige model ifm. en eksport/import arbejdsgang. Af denne grund vælger mange at benævne XPDL som værende seriekoden bag BPMN. (Kemsley, 2007) 8 Serviceorienteret arkitektur 9 Et sprog til at definere andre sprog med f.eks. XML 10 Beskriver navnet på en service, forventelige parametre og anvendt data struktur AALBORG UNIVERSITET Dataudveksling og proces 77

80 Komponenterne i en BPMN BPMN består af en stor mængde symboler, der alle har hver deres betydning samt regel for måden, de kan anvendes på. Der er 4 elementtyper som altid indgår i BPMN: Aktører, processor, forbindelser samt artefakter, der tilsammen viser det flow, en given proces skal igennem. Derudover har systemet en række tillægsobjekter, som kan hægtes på diagrammet for at få indflydelse på den givne proces. Det er vigtigt at tilføje, at modellen ikke er tidsbestemt som f.eks. et Gantt diagram men rettere sekvens bestemt. De basale modelleringsobjekter beskrives i nedenstående del af afsnittet. Aktører Pools & Lanes Det første der foretages under udførelsen af en BPMN er at definere, hvilke aktører der skal med i procesdiagrammet. De illustreres som rektangulære bokse beskrevet som pools, hvori hver af de større aktører indgår såsom Energi ingeniør, Bygherrerådgiver osv. I hver af disse pools kan der afhængig af aktørens struktur inddeles i swimlanes f.eks. kan en Energi og indeklima ingeniørs pool indeholde følgende underinddelinger: Varme, Energi, Lys og Akustik. I figur 30 ses Facilities Management som værende pool delen, hvor den er inddelt i swimlanes i form af Maintenance Operator og Facilities Manager. (BuildingSMART, 2007) Figur 30. BPMN: Pools and lanes BuildingSMART Begivenheder - Events Alle begivenheder markeres med en cirkel, og har til formål at vise, at der sker noget under forretningsprocessen. Der anvendes 3 typer af begivenheder, som har indflydelse på hhv. start(alm. ring), intermediate(dobbelt ring) og slutning af en proces(fed ring). Hver af disse cirkler kan indeholde et ikon(event triggers) der yderligere beskriver funktionen af den pågældende begivenhed. F.eks. repræsenterer billedet af et brev en besked, og et ur relaterer sig til et tidspunkt. Events reagerer på input og klassificeres desuden også ud fra begreberne: Catching en indkommen besked kan igangsætte en given proces Throwing udsende en bekræftelses besked når en proces afsluttes Figur 31. BPMN: Begivenheder BuildingSMART Aktiviteter Processes Ethvert arbejde der skal udføres under en forretningsproces kaldes for en aktivitet, og illustreres som en rektangulær kasse med afrundede hjørner. Navngivningen for den enkelte aktivitet beskrives relativt groft med en handling samt et objektnavn f.eks. Rediger Model. Derudover kan samtlige aktiviteter være tilknyttet hver deres specifikke identifikationskode. For at holde et BPMN-diagram overskueligt vælges det at opdele aktiviteterne i hhv. tasks (atomic proces) og collapsed sub-processes. Tasks udgør enkelte arbejdsgange der ikke kan nedbrydes til yderligere arbejdsgange. Forskellen på de to ligger i muligheden for at nedbryde aktiviteten i yderligere underpunkter. F.eks. kan tasken rediger model via en collapsed subprocess inddeles i åbn Revit model, ændre komponenter, gemme en ny kopi til Figur 32. BPMN: Aktiviteter BuildingSMART AALBORG UNIVERSITET Dataudveksling og proces 78

81 projektweb, underret øvrige aktører om ændringer via mail mm. De forskellige processer kan også indeholde markers, der definerer attributter ifm. den pågældende aktivitet. Plustegnet for yderligere nedbrydelse i sub-processen er bl.a. en marker og vises som et symbol i bunden af aktiviteten. For yderligere marker typer se Quick Guide (BPMN), udarbejdet af BuildingSMART (BuildingSMART, 2007) Forbindelser Connections Der eksisterer 3 hovedtyper af forbindelser i BPMN, som anvendes til at forbinde aktiviteter og flowobjekter i diagrammet: En Sequence flow udformes som en udbrudt linje samt fyldt pilhoved der forbinder forskellige aktiviteter i poolen, og den rækkefølge de kommer i. Den kan også gå på tværs af swimlanes, såfremt de er indeholdt i samme poolområde. En Message flow udformet som en stiplet linje med en åben cirkel i starten, og et åbent pilhoved ved enden, der forbinder sendt information imellem Figur 33. BPMN: Forbindelser BuildingSMART aktiviteterne i forskellige pools eller swimlanes. Den kan aldrig anvendes til at forbinde aktiviteter indenfor samme pool. En Associations forbindelse udformes, som en stiplet linje og repræsenterer enten et artefakt eller noget tekst til et flowobjekt. Afhængig af signalet der ønskes at sende ift. Artefaktet, kan der tilkobles et åbent pilhoved, der får forskellig betydning afhængig af, hvilken retning det peger. Såfremt pilhovedet peger på objektet repræsenterer det et input, hvorimod hvis det peger på artefaktet er det et resultat. (BuildingSMART, 2007) Beslutninger Gateways En gateway kan beskrives som et samlepunkt, hvor flere stier indenfor delingen og samlingen af sekvensflows mødes. Den udtrykkes grafisk som en diamant form, og kan sammenlignes med, at der tages en beslutning i forretningsprocessen. Ydermere kan der tilkobles internal markers, som beskriver et sæt af funktioner, det er nødvendigt at forholde sig til i den endelige beslutning. F.eks. betyder et plustegn i gatewayen, at alle stier skal Figur 34. BPMN: Beslutninger (c) BuildingSMART sammensættes for at opnå det endelige resultat. I figur 34 ses den indflydelse de forskellige markers får, når det kommer til sekvensflowet hhv. divergerende og konvergerende gateways. AALBORG UNIVERSITET Dataudveksling og proces 79

82 Artefakter Artefakter kan beskrives som supplerende information til den pågældende proces ogeller sammenhængen mellem processerne. Umiddelbart eksisterer der 3 typer prædefinerede artefakter: Dataobjekt Viser læseren hvilke data er nødvendige eller produceres i en given aktivitet, og udføres som et ark papir med bøjet kant. Annotations Anvendes for at give læseren af moddelen en bedre forståelse gennem tekstinformation på de forskellige strenge. Grupper Er repræsenteret som en rektangulær kasse med afrundede hjørner og udført af stiplede linjer. Formålet er til dokumentation eller analyse, men berører ikke sekvensflowet. (SEWO, 2011) Figur 35. BPMN: Artefakter SEWO 7.4 Case: Energi og indeklimaingeniører, AAU Som anført er IDM med tilhørende værktøjer en metode til, at systematisere udvekslinger af BIM modeller ved, at der inden projektstart kan angives hvilke informationer, og hvornår i processen de skal udveksles. Det tilsigtede med IDM er en optimering af informationsflowet og, at det står klart for de involverede, hvad der er med i datamodellen til hver udveksling. Dette skulle være med til, at give en bedre kvalitet i projektet, og modvirke uventede opgaver, som evt. skyndes igennem. På samme måde kan der spares tid i projekteringsfasen, og dermed også spares penge. Indtil videre eksisterer der to danske IDM er hhv. arealer og kollisionskontrol. Dog indeholder de kun selve procesdelen og ikke datadelen, hvor sammenhængen til IFC skabes via en MVD. Disse udvikles af nationale instanser som BIPS eller samarbejdsgrupper som Digital Konvergens 11, hvor flere af de største aktører i den danske byggebranche er med hhv.: COWI, Grontmij, MT Højgaard, NCC, Pihl og Rambøll. Der er ligeledes en mulighed for, at tilgå IDM er via BuildingSMART og dele dem på internationalt plan således at få et fælles sprog. I denne forbindelse er en dansk IDM-Metodeguide under udvikling gennem BIPS, som skal agere drejebog for de personer/organisationer der medvirker i udarbejdelsen. Den forventes færdig primo 2013, og vil komme til at afhjælpe flere kvalitetsudvekslinger i en byggeproces. Dette vil forenkle udviklingen, og derved gøre det nemmere at få dem inkorporeret, hvor de kan fungere som en effektiv standardisering. For at påvise hvor og hvordan en IDM kan være effektiv, er der afholdt interview med bl.a.. nogle energi og indeklima ingeniører fra AAU. Her er deres behov og arbejdsområder skitseret op, samt den arbejdsmetodik de har gjort brug af indtil videre. I afsnittet præsenteres et løsningsforslag i form af en IDM proces map, der ville kunne gå ind og optimere deres udvekslingsarbejde AALBORG UNIVERSITET Dataudveksling og proces 80

83 En energiingeniørs approach Dette afsnit tager udgangspunkt i et interview med energiingeniørerne: Ole Daniels og Jesper Nørgaard. For at høre om deres indgangsvinkel til projektering af indeklimaet i en bygning. Begge er uddannede Civilingeniører med speciale i indeklima og energi, og arbejder som undervisningsassistenter på AAU. De arbejder primært i det teoretiske felt, som i dette afsnit vil sige, at der arbejdes med lukkede forsøg og modeller, der kan styres i kontrollerede miljøer. De tager udgangspunkt i teorier og retningslinjer, som kommer fra forskellige statslige instanser, som f.eks. SBI. De udfører analysearbejde og beregninger på alt fra flow af ventilationsstrømme til energiberegninger af bygningen. Dog kræver deres arbejde en betydelig mængde information fra andre byggeaktører, foruden måden og kvaliteten den udleveres i. Dette får senere betydning for hastigheden, de kan udføre deres arbejde med, og resultaterne de når frem til i deres research. Ligeledes er der særlige problemstillinger ift. måden, de afleverer information videre på i byggeprocessen. Disse faktorer beskrives længere nede i afsnittet. Datakrav og arbejdsprocedure I indeklimaingeniørens arbejde er der behov for data, der kan beskrive hhv.: bygningens rumudformning, anvendte materialer, rummenes brug og belastning, føringsmuligheder mm. Disse informationer indsættes i simuleringsprogrammer, der kan forudsige virkemåden, et givent system vil have på byggeriet. Derved er det med til at optimere det færdige projekt, idet flere problemstillinger afklares tidligere i byggeforløbet. Arbejdsprocessen for energiingeniøren starter som udgangspunkt med, at de får tilsendt alle tegninger og skemaer fra øvrige projekterende, hvorfra mængderne manuelt udtrækkes, og overføres til egne programmer som f.eks. Bsim. Ud fra materialet vælges de kritiske nøgleområder, som forenkles til simple modeller f.eks. kasser, og selve simuleringen udføres over disse(se nedenstående eksempel). Figur 36. Forenkling af komponenter til kasse form (Svidt) Her ses hvordan der tages udgangspunkt i en rigtig stald med flere komponenter, og omdannet dem til simple figurer der kan simuleres på. Denne arbejdsmetodik er nødvendig både iht. tid, men især også computerkraft, da en eksakt replika ville stille meget store krav for at udføre en CFD simulering(computational fluid dynamics). CFD er en metode til påvisning af strømningsforhold på forskellige objekter, der via en computer gør brug af numeriske metoder og algoritmer. Hovedregelen er, at AALBORG UNIVERSITET Dataudveksling og proces 81

84 jo mere detaljerige modeller der vælges at simulere over, desto længere tid skal computeren arbejde for at skabe kvalitativt data. Figur 37. Computersimulering af strømningsforhold (Svidt) Når resultaterne udkommer, er det i form af et tekstdokument og grafer, hvorfra de manuelt videreføres til tegneprogrammet for at tilsikre sig, at der er den fornødne plads og placering i byggeriet. Der er dog plads til optimering, da visse aspekter af programmet er forældet, og det ikke har nogle funktionelle import/ eksport muligheder. Derfor indtaster de mange af deres data selv, og laver egne modeller fremfor at have et reelt samarbejde mellem programmerne. Se nedenstående figur 38 for forklaring. Figur 38. Datakrav for indeklimaingeniøren Analyseberegningerne fra teoretikerne er udført på baggrund af lukkede forsøg i kontrollerede omgivelser, og kan derfor være svære at sammenligne med den praktiske del af byggeriet. Men det interessante ved deres rolle er, at finde nogle værktøjer eller processer der gør, at de kan spare nogle arbejdsgange mellem modtaget data og behandlingen af data. AALBORG UNIVERSITET Dataudveksling og proces 82

85 Bsim Energiingeniørerne Ole Daniels og Jesper Nørgaard er igennem deres tid på Aalborg Universitet blevet introduceret til en række forskellige IT værktøjer i relation til deres uddannelse. De anvender primært en programserie kaldet Bsim, som er en pakke af IT analyseværktøjer, der anvendes af energiingeniører til projektering af bygninger og installationer udviklet af Statens Byggeforskningsinstitut (SBI). Ifølge Jesper og Ole anvendes programpakken dog mindre i praksis, idet 9 ud af 10 virksomheder foretrækker at bruge andre programmer. Bsim består af 7 faste moduler, som dækker de fleste områder af ingeniørens projektering og kan opdeles i følgende 2 kategorier: Visuelle værktøjer: - Simview til visuel fremstilling af bygningsmodellen geometri - SimDXF import af CAD-tegninger - SimDB database med konstruktioner og materialer Analyseværktøjer: - Tsbi5 dynamisk simulering af indeklima og energiforhold - XSun analyse og simulering af sollys og skygge - Simlight beregning af dagslys - Be10 beregning af bygningers energibehov De visuelle værktøjer anvendes til at fremstille en grafisk 3D model, hvor bygningsmodellens geometri, konstruktioner, materialer og installationer kan defineres vha. SimDXF og SimDB. Selve analyseværktøjerne anvendes derefter til, at udføre deciderede beregninger og simuleringer på de modeller der er opbygget med visuelle værktøjer. Imellem de interne programmer i Bsim pakken kan data udveksles, og enkelte genanvendes. Det grundlæggende for at indeklima og energiforholdene kan analyseres på en bygning, er opbygning af en 3D model i Bsim. Denne udarbejdes fra bunden, eftersom Bsim s værtøjer langt fra er fuldt kompatible med andre BIM værktøjer. Dog kan DXF filer importeres til programmet, hvorefter der kan simuleres på dem. Men der tabes visse data ved filoverførslen, og en stor mængde kvalitetssikring er nødvendig for, at tilsikre sig de korrekte informationer til senere simulering. Afhængig af arbejdets omfang i projektet, er det ikke altid nødvendigt for ingeniørerne, at opbygge en model der omfatter hele bygningen, men derimod de kritiske områder som opbygges enkelvist i Bsim som rum. Når arbejdet er udført er det muligt via Bsim, at eksportere data videre til diverse andre programmer i form af skemaer. Dette er programmer, som kan anvendes til videre bearbejdning af simuleringer mv. Det store spørgsmål ved arbejdet omkring 3D modeller med tilkoblet data, er hvilken-og hvor meget information den skal indeholde, når den overføres mellem aktørerne i et byggeprojekt. Under interviewet med de to energiingeniører på AAU fortalte de, at udlevering af en geometrisk model ikke vil være så stor en hjælp, da de kun mener, at 10 % af arbejdet ligger i at opbygge en geometrisk model, hvor de AALBORG UNIVERSITET Dataudveksling og proces 83

86 resterende 90 % omhandler resten. Dette er ofte tilfældet, da det langtfra altid er nødvendigt for ingeniørerne at analysere alle rum i en bygning, men derimod de kritiske rum, som f.eks. er udsat for tung personbelastning såsom køkkener. Derfra kan de analysere øvrige rum uden, at skulle modellere dem i Bsim. Men de nødvendige informationer skal stadig defineres på et datagrundlag, og her kommer IDM ind. Nedenstående figur 39 er et eksempel på, hvordan udvekslings- og arbejdsprocessen mellem en indeklimaingeniør, og rådgiver/arkitekt i et byggeprojekt kan synliggøres vha. IDM. Der arbejdes kun med procesbeskrivelsen og ikke datadelen. Figur 39. Process map for Energi & indeklimaingeniør, udarbejdet ifm. rapporten Specifikation af processer Type Dokumentation [1,1] Informer arkitekt/rådgiver Subproces Energi og indeklima ingeniøren fremsender krav til rådgiveren om behov for modelinformation til videre bearbejdning. [1,2] Model Subproces Rådgiver modellerer de aftalte informationer og data i en model baseret på kravene fra energi ingeniøren [1,3] Analyse Subproces Energi og indeklima ingeniøren modtager det relevante data fra rådgiver, og kontrollerer at det er i overensstemmelse med de opstillede krav. [1,4] Lys, Akustik, Ventilation, Varme Subproces De forskellige krav placeres ud til de 4 forskellige delområder i energi og indeklima ingeniørens fagområde, og analyser udvikles på hver. AALBORG UNIVERSITET Dataudveksling og proces 84

87 [1,5] Arbejde fortsætter Subproces Det fælles resultat fra de 4 analyser videresendes tilbage til rådgiveren, der vurderer om resultatet er tilstrækkeligt ift. projektet. Såfremt det er godkendt, arbejdes der videre ud fra modellen, og hvis ikke udarbejdes der rettelser, som sendes tilbage til revurdering hos energi og indeklima ingeniøren. Tabel 12. Beskrivelse til process map Ved at anvende Quickguide til BPMN fra BuildingSMART er måden, som informationen mellem de 2 parter skal håndteres nu fastsat. Den indeholder både den korrekte rækkefølge samt den tilstrækkelige mængde af information defineret på artefakterne i form af Exchange Requirements. Næste skridt på vejen er, hvordan industrien fås til at adoptere denne nye metode. Udover opkvalificering af arbejdskraften og implementering gennem de offentlige krav, er det nødvendigt at ændre gældende kutymer indenfor byggebranchen. En metode er gennem ydelsesbeskrivelsen Byggeri og Planlægning 2012 som i pkt. 2.2 og særskilt pkt. 8 nu har lagt fokus på IKT egenskaberne. Her bliver de forskellige roller i byggeprojektets IT afdeling skitseret op, og tildeles en betydelig større rolle end tidligere, hvor der refereres til specifikke ydelser bl.a. i form af IDM er. Nedenstående figur 40 viser, hvordan en IDM kan blive anvendt i en byggesag i et kontraktforhold. Figur 40. IDM i en byggesag, kontraktforhold Schmidt/hammer/Lassen architects (Schmidt/Hammer/Lassen Architects, 2012) 7.5 Metode og stuktur for informationsniveauer En anden måde dataudvekslingen kan gribes an på, er Cuneco s nyudgivne publikation Metode og struktur for Informationsniveauer, som referer til deres referencesystem CCS. Denne metode minder om BuildingSMART s mht. IDM, hvor målet er at skabe et bedre overblik over overgangene mellem de forskellige aktører i byggeriet. Metode og struktur for informationsniveauer er med til at specificere hvilke egenskabsdata, der skal foreligge for eksempelvist et vindue, der skal indgå f.eks. i den rådgivende ingeniørs klima- og energiberegninger, på forskellige stadier i processen. Alt efter hvor nøjagtig beregningerne skal være. AALBORG UNIVERSITET Dataudveksling og proces 85

88 Desuden kan metoden bruges til at håndtere leverancespecifikationerne imellem aktørerne, gennem de respektive niveauer i byggeprojektet. Gennem et byggeprojekt bliver der løbende lagt flere informationer på en bygningsmodel, til energiberegninger, priskalkulationer, tidsplanlægning osv. Denne datatilvækst bevirker, at modellen til sidst kan blive meget uoverskuelig, og danne grundlag for redundant information. Dette hænger sammen med, at meget af dataene, udelukkende bruges til opbygningen af modellen. Men ikke er ment som værende valide til senere brug i efterfølgende projektering. Dette kan få modellen til at virke mere færdig end den reelt set er. (illustreres i grafen på figur 41) Figur 41. Informationer kontra valide informationer i en bygningsmodel Cuneco Meningen med informationsmetoden er derfor at skabe et værktøj, som muliggør undgåelse af disse redundante informationer i modellen. Dette sker, ved at specificere hvilke informationer der skal udveksles hvornår. Herved opnås et bedre samarbejde mellem parterne, og dermed fremmes både deres og ikke mindst branchens produktivitet. Dette kan afhjælpe uoverensstemmelser mellem aktørerne, da alle hermed ved hvad der skal afleveres til hvem og hvornår. Det er disse udfordringer Cuneco har søgt bearbejdet med deres nye værktøj, som beskrives i deres rapport. Hovedformålet med rapporten, er at skabe: Et system der er med til at sikre en bedre kommunikation mellem byggeriets parter. Grundlag for at det er klart, hvad der ved en overgang mellem to aktører henholdsvis skal afleveres af informationer, og hvad der modtages af informationer. Klarere spilleregler mellem aktører, samtidig med at det bliver lettere at vurdere omfanget af en opgave. (Cuneco, 2012) AALBORG UNIVERSITET Dataudveksling og proces 86

89 Senderen ved hermed præcist hvad han skal sende af sted, og modtageren ved hvad han skal forvente at modtage. Derfor henvender metoden sig også til alle parter i byggeriet, da hver part kan få den information, de har brug for. Herunder, på figur 42 er vist et simpelt eksempel for et lille hus, som er delt op i bygningsdele og rum, for at kunne definere hvilke dele der er på hvilket informationsniveau, og i hvilken fase. Figur 42. Informationsniveauer for et hus Cuneco Som det kan ses i eksemplet stiger informationsniveauet efterhånden som faserne skrider frem, da der bliver brug for flere og flere informationer, som byggeriet når længere frem. Dog er informationsniveauet lavere ved aflevering til D & V, da der ikke er behov for lige så mange informationer hertil, som til nogle af de tidligere faser. (Cuneco, 2012) AALBORG UNIVERSITET Dataudveksling og proces 87

90 Ved indgåelse af projekteringsaftaler, defineres der i analysefasen, hvilke informationer og egenskaber hvert informationsniveau skal indeholde. Herefter defineres det hvilke informationsniveau de respektive funktionskrav osv. skal ligge på igennem projektet. Figur 43. Informationsniveauer Cuneco Efter informationsniveauerne er definerede for hvert rum, bygningsdel eller proces vil de altid være den samme, f.eks. er et vindue på niveau 3 altid konstrueret med det samme indhold uanset projekttype, fase og aktører osv. Men leverancespecifikationen er anderledes, da det er forskelligt, hvilken fase den skal afleveres i, samt hvem der afleverer den (bliver også forklaret senere). Derfor er der ikke altid den samme sammenhæng mellem informationsniveauerne og de forskellige faser i byggeriet. Det kunne være, at der allerede er behov for vinduer i niveau 3 eller 4 i designfasen således at sikre sig, at prisen er tæt på at blive overholdt fra start. I et andet projekt kan dette niveau først opnås i hovedprojektet af byggeriet. Derfor aftales de forskellige niveauer i kontrakten, mellem de forskelige rådgivere. AALBORG UNIVERSITET Dataudveksling og proces 88

91 Figur 44 viser de forskellige niveauers definition i hhv. omfang, detaljering og konkretisering af de respektive bygningsdele. Dog er man i det nye forslag gået fra de tidligere 7 niveauer (0-6) og til disse 6 niveauer (1-6). Hvor niveau 6 tidligere var as-built dokumentation til driftsherren, er det i dette forslag, at egenskabsdataene kommer til gavn, da dette er de data, der kan bruges til automatisk produktion, f.eks. i bukkemaskiner til armering. Forslaget er til høring indtil den 29. november 2012, hvor der bliver afholdt høringsseminar. Hvorefter indholdet for de enkelte informationsniveauer defineres i forhold til de omtalte emner: Funktionskrav, resultater og proces som CCS også er delt op efter. Egenskabsdata: Egenskabsdata er en vigtig del af denne metode, og benævnes karaktertræk ved objekter i rapporten. Dette kan være alt fra generelle egenskaber til meget specifikke egenskaber, som kun hører til et objekt. Men grundet mængden af forskellige egenskaber, er der dannet tre overordnede grupperinger for disse: Funktionskrav, resultat og produktion. Funktionskrav omhandler informationer, som stiller krav til specifikke løsninger i resultatområdet (informationsniveau 2-4), hvor produktionsområdet er mere produktionsrelaterede informationer f.eks. til produktion og D & V (Niveau 5 6). Dog kan de tre grupperinger deles yderligere op i underkategorier, som f.eks. produkt-, placering-, form- eller grænsefladeegenskabsdata. Dette er illustreret i figur 44: Dette betyder også, at der med informationsniveaumetoden kan defineres hvilke informationer, der skal bruges i hvilken fase i projektet. F.eks. kan en bygningsdels egenskaber være krævet tidligt i faserne, hvorimod dens placering først behøver at være kendt senere i projektet. Et eksempel kunne være betonelementer, eller murstensvægge som er kendt fra start, men deres præcise placering behøver først at være 100 % fastlagt senere i projektet. Dog placeres de bærende vægge tidligt i projektet. Figur 44. Gruppering af egenskabsdata Cuneco AALBORG UNIVERSITET Dataudveksling og proces 89

92 Disse definitioner kan efterfølgende bruges til at beskrive, hvilke ting der skal udføres i hvilke informationsniveauer, på hvilket som helst tidspunkt i projektet. F.eks. kan der skrives A3 hvilket betyder, at alle funktionskrav skal afleveres i niveau 3 på det stadie, som er defineret (kan være i tabel). Der kan også stå BA3 B2 hvor produktegenskaberne skal afleveres i niveau 3, men de resterende elementer i B skal afleveres i niveau 2. Dette kan også vises på et skema, som vist på tabel 13 for at holde styr på, hvornår der menes, at hver bygningsdel er på hvilket niveau. Dette kan sammenlignes med det tidligere beskrevne BPMN, som også danner et overblik over dataudvekslingen mellem parterne. Tabel 13. Oversigt over informationsniveauer i faserne for D&V Cuneco Views Efter disse egenskabsdata er defineret, kan de anvendes i byggeriet til f.eks. energiberegninger, ved at have de nødvendige informationer på de pågældende bygningsdele. Derfor har Cuneco udarbejdet et forslag kaldet Views, som minder om det tidligere beskrevne IDM. Disse views er en definition/-template, over hvilke ting der skal bruges til analyser og beregninger i faserne. Herunder på figur 45, er vist et eksempel over et view på et vindue til en energiberegning: Det kommende CCS vil indeholde en række af disse views til forskellige formål, som derefter kan redigeres efter behov, eller oprette særskilte views til bestemte formål. Figur 45. View for energiberegning til vindue Cuneco AALBORG UNIVERSITET Dataudveksling og proces 90

93 Disse views kan også oprettes således, at de varierer alt efter hvilket informationsniveau der arbejdes med. Her kunne et godt eksempel være en priskalkulation, hvor der løbende inddrages egenskabsdata i beregningen efterhånden, som processen skrider frem for at gøre økonomien mere præcis. Som eksempel kan ses figur 46: Figur 46. Priskalkulation på forskellige informationsniveauer Cuneco Metodens anvendelse: Metoden er IKKE en ny 3D- arbejdsmetode, men kan i stedet bruges til at understøtte aftaler om informationsleverancer og informations flow samt et redskab til at styre et projektforløb. Metoden kan bruges både i de traditionelle forløb/-udbudsformer, men også i de nyere agile 12 samarbejdsformer, som f.eks. OPP. Den kan desuden bruges, hvad enten det er i digital form eller analog projektering. I rapporten er der givet et eksempel på, hvordan informationsniveaumetoden kan understøtte de øvrige aftaleforhold i projektet. Ved at følge nedenstående 6 trin: 1. Udfør før indgåelse af en aftale baseret på informationsniveauer en projektanalyse, der definerer og beskriver projektets kontekst, kompleksitet, organisation, aktører og succeskriterier 2. Fastlæg en hensigtsmæssig procesmodel for byggeprojektet (f.eks. fasemodel for projektering og udførelse) 3. Identificer relevante aktører for relevante roller 4. Analyser informationsbehovet i projektets forskellige faser eller anvend en af Cuneco s skabeloner for f.eks. en traditionel faseopdeling, totalentrepriser eller funktionsudbud 5. Udfyld leverancespecifikationen 6. Følg løbende op på om projektets fremdrift er i overensstemmelse med det aftalte (Cuneco, 2012) 12 Agil, fleksible og omstillingsparate samarbejder. AALBORG UNIVERSITET Dataudveksling og proces 91

94 Leverancespecifikation: Et vigtigt redskab i informationsniveaumetoden er at der anvendes en leverancespecifikation for at holde styr på, hvornår hvem får hvad, samt hvem der har ansvaret. Derfra kan de forskellige bygningsdele sættes op i en tabel, som eksemplet vist i figur 47: I figuren er de forskellige hoved- og delsystemer angivet og opdelt efter CCS kodningen, hvorefter informationsniveauet for den pågældende fase er angivet, og afsluttet med den ansvarlige for det pågældende emne. Tabellen bliver igennem projektet løbende udvidet, (kan også være lavet fuldt ud fra start) hvorved det kan ses hvilket informationsniveau projektet skal være i ved de næste faser. Metoden gør det muligt, at bestemme hvornår en specifik information skal være Figur 47. Eksempel på leverancespecifikationer med aktører Cuneco tilgængelig, samt på hvilket niveau det skal være. Desuden kan tabellen også bruges i tilfælde af faseopdelt projektering, da tabellen så deles op i faser, og viser de aktører der er ansvarlige i hver fase. Dette kan også være i tilfælde af, at ansvaret overdrages til en anden part. Hovedemnerne kan opdeles i underemner, hvorefter de strukturelle aspekter kan bruges, i form af præfiks, som beskrevet under CCS kodningen. Terrænsystemet kan f.eks. deles op i %UF1 stribefundamenter osv. Dette ville betyde at det er typeaspekt UF1, som er stribefundament i dette tilfælde. Her kan yderligere bestemmes, om et af underemnerne behøver at være i et højere informationsniveau end de resterende. Dog kan der forekomme bygningsdele, der får en mere håndgribelig kode som vist herunder: I figur 48 vises et eksempel på at der i fase 4, er brug for kendskab til produkt samt form i højt niveau, hvorimod det ikke er så vigtigt, hvor den er placeret, og dermed heller ikke hvad den grænser op imod. Disse informationskrav, kan også stilles op for funktionskravene (A) og produktionskravene (C). Figur 48. Leverancespecifikation, indvendige skillevægge med specificeret informationsniveau Cuneco AALBORG UNIVERSITET Dataudveksling og proces 92

95 På figur 49 er vist en oversigt over, hvordan disse tabeller ville kunne se ud i en samlet hele, hvor der er sat 4 faser på, der tilpasses den enkelte sag. Herefter udfyldes entrepriserne nedad for, at definere hvornår hvilket objekt skal udleveres, samt i hvilket niveau og af hvem. I tilfælde af at en entreprise skal igangsættes i de første faser lades disse felter være tommer, hvorefter de behov der er brug for udfyldes. Metoden har også fordelen, at det er enkelt sat op, så det let kan implementeres i en hjemmeside, eller laves som et Excel ark. Ydermere kan der, når systemet er 100 % fastlagt, hentes skabeloner til de forskellige organisationsformer og fasemodeller, så det er nemt for den projekterende. Der vil også komme forslag til forskellige views, som kan bruges til div. i projektet. Her ses også, at der fra Cuneco s side er taget udgangspunkt i BuildingSMART s procesmap. (Et eksempel procesmap kan ses i afsnit 7.4) Kvaliteten, successen og værdien af informationsniveaumetoden skal nu skabes gennem praktisk afprøvning, implementering i virkelige projekter og videre tilpasning og udvikling baseret på erfaringerne fra dens praktiske brug. (Cuneco, 2012) Figur 49. Eksempel på leverancespecifikation for hele byggeprocessen Cuneco AALBORG UNIVERSITET Dataudveksling og proces 93