Referat af fokusgruppemøde om projekteringsfasen

Transkript

1 Referat af fokusgruppemøde om projekteringsfasen cuneco en del af bips Dato Projektnr. Sign. MET 1. Baggrund cuneco vil i en behovsanalyse afdække byggebranchens behov som udgangspunkt for arbejdet med at udvikle standarder for digital udveksling af information. Behovsanalysen består af følgende elementer: Workshops for de enkelte aktører: Byg- og driftsherrer, arkitekter, rådgivende ingeniører, udførende og byggematerialeproducenter. To fokusgrupper på tværs af aktører inden for faserne: programmering, projektering, udførsel og drift & vedligehold. Dette dokument beskriver det første fokusgruppemøde om projekteringsfasen, som blev afholdt den hos cuneco. Mødet havde følgende deltagere: Mette Carstad, Universitets- og Bygningsstyrelsen Lars Reimar, CRH Concrete Birte Bæk, Henning Larsen Peter Hyttel Sørensen, C.F. Møller Per Jyllnor, JYRO architects Claus Dyrlund, Ramøll Gert Jespersen, NCC Torben Klitgaard, cuneco (facilitator) Gunnar Friborg, bips (facilitator) Lars Hvam, DTU Management (oplægsholder) Mette Øbro, cuneco (referent) Anette Prindahl (procesmodel-referent) Mødet havde følgende dagsorden: 1. Diskussion af case v. Lars Hvam 2. Behovsidentifikation: Hvad er fasens største udfordringer vedr. udveksling og genbrug af data? v. Torben Klitgaard 3. Gennemgang af de enkelte udfordringer v. Gunnar Friborg 4. Opsamling og prioritering v. Torben Klitgaard cuneco står for fællesskab. Vi udvikler det fælles grundlag for digitaliseret samarbejde i byggeri, anlæg og drift. Målet er øget effektivitet og produktivitet gennem bedre udveksling af informationer. Side 1 af 13

2 Nedenfor refereres mødets diskussioner. Bemærk, at referatet ikke angiver en samlet konklusion om de enkelte punkter, men deltagernes individuelle kommentarer, som kan være modstridende grundet deltagernes forskellige synspunkter og interesser. 2. Diskussion af case Lars Hvam fremlagde en case, som ud fra en aktuel byggesag illustrerer, hvor der kan opstå problemer i forhold til udveksling og genbrug af data i projekteringsfasen, og hvordan en standard kan gøre en forskel. Casen omhandlede tidligt udbud af glasvægge (casen er nøjere beskrevet på I eksemplet benævner og opmåler arkitekten glasvæggene på sin egen måde, og hvert led i kæden fra totalentreprenør over fagentreprenør til leverandør udfører deres egne opmålinger. Der er således meget dobbeltarbejde i processen, og der opstår usikkerhed om materialerne, da benævnelsen ikke er entydig, dvs. de forskellige leverandører fortolker måske arkitektens beskrivelse anderledes end ønsket og laver et forslag, som ikke kan godkendes, hvorved der er behov for tilbageløb i processen. Typisk indeholder en sådan proces mange tilbageløb. Iflg. Lars Hvam vil problemerne kunne afhjælpes via en standard for opmålingsregler og en standard for kodning i CAD-systemet, så arkitektens opmåling kunne udføres automatisk af CAD-systemet, hvilket ville lette arkitektens arbejde og gøre opmålingen mere præcis til brug for samarbejdspartnerne. Desuden ville en standard for byggevareklassifikation give en entydig benævnelse af produkterne, så der undgås misforståelser. Endelig kunne en standard for ydelser og ansvarsfordeling (à la A113 for betonelementer) fastlægge procesforløbet og gøre det klart, at det er fx arkitekten, som har ansvaret for opmålingen, hvorved dobbeltarbejdet minimeres. Samlet set ville standarderne skabe større entydighed, mindre spildtid og færre loops i processen. Deltagerne kunne overordnet genkende problematikken, men havde følgende kommentarer til casen: Det er ikke rimeligt, at arkitekten har ansvaret for opmåling i den digitale model, mens den udførende og underleverandøren friholdes. o Opmålingsansvar giver arkitekten et kæmpe ekstraarbejde. I praksis findes der ikke én opmålingsregel, men flere forskellige inden for de forskellige delområder af byggeriet: Man står i et kæmpe virvar af opmålingsregler og skal beslutte, hvad man vil gøre på det enkelte projekt. o Der skal defineres klare opmålingsregler, men ansvaret for opmålingen skal fortsat ligge hos de udførende. Side 2 af 13

3 I teorien kan man via standard for ydelses- og ansvarsfordeling aftale, hvor opmålingsansvaret skal ligge i praksis vil det ligge hos dem, der i de indledende arbejder satte modelklodserne ind i modellen. Producenten er også i eksemplets fremtidsscenarie nødt til at lave sin egen opmåling, idet han ikke ved, hvordan bygningsdelen er modelleret og opmålt. De forskellige parter kan projektere på forskellige niveauer. A113 er god til at definere, hvem der har ansvar for hvilken del. Spørgsmålet er, hvor langt man i en tilbudsfase reelt skal kunne detaljere tingene, og hvor meget tid folk skal bruge på at beregne det? o Problemet er ikke så meget opmålingsregler, som funktionsagtige udbud, der ikke løftes rigtigt. Der mangler en standard for kravene i et funktionsudbud. I forhold til udbud med mængder er det svært for rådgiverne at bedømme de korrekte mængder, da de ikke har erfaring med dette. Fx er det svært at vurdere, hvor meget der hører med til en stikkontakt, og hvis rådgiveren i et stort byggeri udbyder med 20% for lidt kabel, har det stor betydning: Vi bruger som rådgivere utrolig meget tid på at tage ansvar for mængderne Usikkerheden vedr. mængder gælder imidlertid også for entreprenørerne, som alle pålægger et risikotillæg i deres tilbud. Det vil derfor set fra de udførendes synsvinkel give en mere fair konkurrence, hvis bygherren specificerer, hvad der skal gives pris på, så alle giver pris ud fra de samme mængder. Hvis mængderne i praksis viser sig at være større, er det rimeligt, at bygherren skal betale mere: Det skal ikke introduceres som en konkurrenceparameter, hvor usikre vi som entreprenører er på vores opmåling Det meste af Europa arbejder med en beskrivende mængdefortegnelse, det burde også være muligt i Danmark. I Sverige får man det samme grundlag at regne på, og man detailtegner kun de ting, som afviger fra normen, der er angivet ved en kode. Dette giver en større kvalitetssikring og sparer tid, både i forhold til beskrivelser og tegningsarbejde. En standard kan ikke dække alt der vil i byggeriet stadig være mange områder, som skal specificeres særskilt. Side 3 af 13

4 3. Behovsidentifikation Cuneco har i de forudgående workshops afdækket følgende primære behov i projekteringsfasen: 1. Informationsniveauer for udveksling af data mellem arkitekter og ingeniører. 2. Standard for mængde- og dataudtræk ved udbud. 3. Det skal være enklere at arbejde med klassifikation af bygningsdele. 4. Paradigme for sammenhæng mellem klassifikation og bygningsdelsbeskrivelser. Deltagerne kunne relatere sig til de præsenterede behov med følgende supplerende bemærkninger: Informationsniveauer for udveksling skal også omhandle materialeleverandørerne, som oplever problemer med udveksling, specielt fordi de har forskellige krav til informationsniveauet i de tegninger, der skal anvendes videre i processen. Der er tænkt ud fra en gammeldags proces, hvor arkitekt og ingeniør projekterer sammen, og så sender projektet i udbuddet. Sådan foregår processen ikke længere, og det bør den heller ikke: Det vi skal have ud af BIM og bips er, at nu skal alle spille sammen Der mangler standarder for de data, bygherren skal modtage fra de projekterende i forhold til den løbende beslutningstagen, fx en standard for projekteringsniveauet relateret til udbuds- og entrepriseformen (dette er relateret til PAR/FRIs ydelsesbeskrivelser). o o Der er behov for, at bygherren i givne stadier kan validere projektmaterialet, fx tjekke arealerne. Det kan være en udfordring i en totalentreprise at få bygherren inddraget i processen og på den ene side afkræve bygherren beslutninger rettidigt, på den anden side afklare hvilket beslutningsgrundlag, der skal til for at kunne træffe en beslutning. Det Digitale Byggeris krav om digitalt udbud hænger ikke sammen med funktionsudbud. Der mangler en standard for funktionsudbud der findes ikke standarder til at håndtere graden af funktionsudbud, derfor opstår der tit diskussioner om, hvem der har ansvar for hvad hvornår. Økonomien er en barriere for virksomhedernes it-udvikling det er dyrt at opgradere medarbejderne til at anvende ny software, og skal softwaren være avanceret og fx håndtere meget detaljerede klassifikationer, er den i Side 4 af 13

5 sig selv meget dyr: Der er kun et rationale i at gøre det på meget store opgaver Nedenfor beskrives diskussionen af de enkelte emner, idet emne 1: Informationsniveauer for udveksling af data udvidedes til at omfatte arkitekter, ingeniører, entreprenører, leverandører og bygherrer. Desuden suppleredes med et nyt emne 5: Funktionsudbud hvordan digitalt? De fem emner blev diskuteret i gruppen ud fra punkterne: beskrivelse af problemet, årsager til problemet og hvilke typer standarder, der kan afhjælpe problemet. 4. Gennemgang af de enkelte udfordringer 4.1. Informationsniveauer for udveksling af data mellem aktørerne Det er et problem i forhold til bygningsmodellen, at der er forskellige opfattelser af informationsniveau fx kan bygherren have en anden opfattelse af, hvor meget informationsniveau 2 indeholder i et dispositions- og projektforslag, end rådgiverne gør. Det er vigtigt at få klarlagt præcist, hvad der er med og ikke med. De nuværende informationsniveauer er meget flydende og uklart beskrevne og bør laves om. o Uklarheden bevirker tvivl og mistillid: Det skaber et mistillidsforhold mellem rådgiver og kunde, hvor kunden mener, at han bestiller det, der står i IKT-aftalen, mens rådgiveren har svært ved at efterleve det Alle rådgiverne på mødet er enige om problemet med de uklare informationsniveauer. Der kunne i ydelsesbeskrivelserne beskrives grundigt, hvad bygherren kan forvente at få fra sine rådgivere i hvilke niveauer: Det er rart for alle parter at få en afstemning af, hvad man forventer. o En IDM, der beskriver, hvad bygherren skal have på hvert enkelt niveau, vil være en stor hjælp for alle. Man burde ikke skulle tale om udveksling mellem arkitekter og ingeniører de burde arbejde på en fælles model, der kører efter et aftalt fælles niveau. o Dette er i praksis ikke muligt i dag parterne arbejder på forskellige niveauer på forskellige tidspunkter, fx afventer ingeniøren arkitektens design, før de projekterer installationerne. Skal en fælles model fungere, skal alle lege med meget tidligere Side 5 af 13

6 o Det er mere rationelt for ingeniøren at afvente de færdige tegninger, men hvis BIM-processen skal køre, skal de levere indspark tidligt i processen. Mange vil gerne springe ud med BIM og tegne det færdige hus men det er mere hensigtsmæssigt at holde fast i fasemodellens definerede faser. Facilitator opsamler, at de nuværende ydelsesbeskrivelser (som har dannet basis for bips standarder) er ikke lavet ud fra de digitale muligheder, der findes i dag, og specificerer derfor ikke præcist nok den ønskede information og detaljeringsgrad. Dette bekræftes af deltagerne: Ordet tegning anvendes uden beskrivelse af, hvad begrebet dækker over, og hvordan det skal forstås i forhold til en BIM-model. Det er vigtigt at opdatere faseopdelingen på ydelsesbeskrivelserne med definitioner af, hvad faserne indeholder på digitalt niveau. A113, der håndterer ydelser og ansvar, fremhæves som et godt værktøj: Det har gjort en verden til forskel i vores kommunikation med kunderne Det er et problem i forhold til informationsniveauernes sammenknytning med faser, at et stort projekt i praksis ikke er på samme niveau i en bestemt fase der bygges måske i det ene hjørne, samtidig med at der skitseres i det andet. o Det kunne derfor være en god idé i stedet at knytte informationsniveauer til bygningsdele. I de fleste projekter kan man dog godt anvende informationsniveauer bygget op på faser. Der skal standardiseres ud fra 80/20-reglen dvs. standarder som kan dække 80% af tilfældene, mens særtilfældene må beskrives specifikt (også ved særtilfældene har man dog glæde af standardmodellen, idet særtilfældene kan beskrives ved deres afvigelser fra standarden, fx ved at byggeriet er kortere eller længere fremme på et givent område). o Det kunne også være en mulighed at beskrive informationsniveauerne dynamisk, så man ved udbuddet af rådgivningsopgaven kan give fx et 60% bud og senere i den løbende dialog gennem processen kan fastlægge fx 85%. o Der bør dog stadig laves en motorvej, som beskriver standarden for det forventede informationsniveau i de forskellige faser, og som afvigelserne kan beskrives i forhold til. Der er behov for digital udveksling af andre typer information end det, der kan hægtes op på en bygningsmodel. Der er dog bygningsmodellen, der har deltagernes primære fokus. Side 6 af 13

7 I forhold til dokumenthåndtering er der behov for at gruppere dokumenter, idet forskellige dokumenter typisk skal bringes med til forskellige samarbejdspartnere. Det kunne evt. være en mulighed at registrere beslutninger truffet løbende i byggeprocessen i en databasebaseret logbog frem for som nu, hvor de ligger i en stak dokumenter. Økonomi, energi og arealer bør være hægtet op på BIM-modellen, hvilket vil skabe entydighed det er ikke i orden fx at aflevere økonomien i et excelark ved siden af BIM-modellen. o I forbindelse med skabelonen for informationsniveauer til faserne kunne man fx som bygherre eller totalentreprenør krydse af hvilke af sådanne elementer, man forventer at få belyst. Det ville være nyttigt inden for ingeniørernes beregningsfelt at have en standard for hvilke informationer, som leverandører og underleverandører har behov for til deres processer m.a.o. hvilke informationer, der skal gives videre som beregningsgrundlag Standard for mængde- og dataudtræk ved udbud Facilitator opsamler den tidligere diskussion: Der skal skelnes mellem udbudsmængder og tilbudsmængder. Det er generelt uklart, hvad der hører med i udbudsmængder, og der er en særlig problematik i forhold til funktionsudbud. Opmålingsreglerne er uklare; mange aktører måler op hver især, og hvem skal have gevinsten ved en opmåling? Anvendeligheden af de eksisterende opmålingsregler er ikke god i forhold til udbudsmængder dokumentet er for langt og tvetydigt, fx er man i en udbudssituation nødt til at henvise til et afsnit, hvor der kan stå flere opmålingsregler for, hvordan man måler et givet system op. Der er brug for et kortere og mere entydigt dokument, suppleret med eksempler gerne billedmæssige eksempler, fx brutto-netto angivet på en søjle. Opmålingsreglerne skal beskrive, hvordan man trækker data ud af bygningsmodellen. Reglerne skal være præcise på, hvordan man modellerer, og hvilke ting man fx selv skal tilføje, når man modellerer på en given måde (idet værktøjerne gør det forskelligt). Spørgsmålet er, om udbudsmængderne nogen sinde give den ønskede værdi, når rådgiverne er nødt til tage en mængde forbehold, som prissættes forskelligt? o Entreprenørerne svarer ja, for så har de bydende et fælles grundlag at give pris på, og de slipper for alle at skulle opmåle et projekt, som kun én af dem vinder. Dette kan suppleres med en klausul om, at man inden for fire uger skal være enige om mængderne. Side 7 af 13

8 De udførende kan have stor værdi i at bruge en BIM-model til produktionsfasen (til 4D og 5D): Som entreprenør er der en fantastisk værdi i at bruge BIM som et kommunikationsværktøj over for dem, der skal udføre byggeriet. Det er derfor vigtigt, at modellen laves, så den er egnet til udførelse, og at hovedentreprenøren kan give den videre til underentreprenørerne, osv. Et krav til arkitekterne om at arbejde struktureret med BIM i forhold til udførselsfasen kan dog stride imod arkitekternes traditionelt mere kunstneriske tilgang: Hvor meget er arkitekter hyldemennesker, og hvor meget er de renæssancemennesker? Facilitator opsamler, at informationsniveauet i forhold til udbud skal forklare, hvad man kan forvente at finde af mængder, både i modellen og i tilbudslisten. Deltagerne bekræfter, at de ønsker en sådan præcisering: Hermed løses problemet vedr. tilbudsmængder ikke, men det er dog et stort skridt på vejen, at der i udbuddet angives en hovedmængde, som de udførende kan arbejde videre med. I funktionsudbud er det rimeligt, at der specificeres en ren mængde. Herved lægges en del af ansvaret over på dem, der giver buddet, og der skal i så fald frigøres nogle forudsætninger. Den udførende vil ikke automatisk give bygherren delmængder tilbage, men kan gøre det, hvis det efterspørges. Et eksempel på en aktuel, individuel løsning er at byde ud via en specificeret kalkulation bestående af poster, som skal prissættes. Kalkulationen er udarbejdet i Sigma, og den bydes ud digitalt via en XMLstruktur, hvor de bydende kan arbejde videre og nedbryde posterne og sende information tilbage på udbudsportalen om, hvor de evt. har ændret i niveauerne. o Det vil være en stor fordel at have en lignende brancheløsning baseret på fælles standarder og klassifikationer. Det skal kunne gøres både i Excel og Sigma, og cuneco skal levere en XMLkonvertering, der oversætter. o Eksemplet er også attraktivt for de udførende. Dog vil tilbudslister, som er meget detaljerede, men uden mængdeangivelser tvinge de udførende til at finde alle mulige delmængder, som er ligegyldige for dem selv i kalkulationssammenhæng. Facilitator spørger, om udbud med mængder vil kræve større datadisciplin og bevirke, at processen fra starten af struktureres i forhold til at skulle kunne generere mængder. Der er delvist enighed i dette. Side 8 af 13

9 Rådgiverne er uvante med at trække mængder ud og derfor usikre på, om det er den rigtige mængde, der kommer ud, hvorfor de også tæller manuelt op for at tjekke resultatet. Dette skal man ud over, hvis der skal skabes en fordel. o Usikkerheden går både på den uvante proces og de CADværktøjer, der anvendes. Det er ikke muligt at lave et værktøj, der kan kontrollere alle de ting, man kunne ønske sig at få kontrolleret fx at der er de aftalte ting i modellen eller en sammenligning af rum. Det er desuden kun få medarbejdere, som vil have den fornødne erfaring til at gøre det, så det er et ressourcemæssigt problem. Forskellige leverandører har behov for forskellige undermængder, hvilket er en udfordring i forhold til udbud med mængder: rådgiverne kan ikke forudse, hvilke undermængder den enkelte leverandør har behov for. Skal de øvrige aktører arbejde videre med mængder fra BIM-modellen, skal de kunne se, om fx en væg er tegnet helt op til loftet. M.a.o. forudsætter opmålingsreglerne, at der er modelleringsregler. Et andet eksempel på rådgivernes udfordring i forhold til mængdeudbud er, at rådgiverne ikke ved, præcis hvad de udførende plejer at konkurrere på og risikerer derfor fx ved kun at angive brutto-kvadratmeter i et malerudbud at få for høje bud, fordi de bydende ikke selv trækker det relevante fra (som kunne være, at der ikke males helt op til loftet) Det skal være enklere at arbejde med klassifikation af bygningsdele Det er som rådgiver svært at se, hvad man vinder ved at klassificere med en kode frem for at bruge noget, man kender i forvejen (fx 200 mm vægge samles i en kategori, der kan sættes underdele på). Det har forskrækket mange ved DBK, at tingene får et tal og et tegn, der i sig selv ikke giver nogen mening, med mindre man er inde i koderne: Hvorfor ikke benytte os af de navne, som vi giver dem alligevel? Det skal ikke være en fortolkningskode det skal bruges til mærkning og overholde matematiske regler for kodning, så det er maskinaflæseligt. Klassifikationen skal adskilles fra referencesystemet. DBK skal lægge sig op af det internationale arbejde i ISO med at finde de nødvendige tabeller. Det svenske klassifikationssystem, hvor der er en kobling til beskrivelsesværktøjet, fungerer godt. Side 9 af 13

10 Ambitionsniveauet i DBK er for stort man vil ramme alt for langt nede: Man ender med at blive glad for Sfb. Man skal standardisere alle hyldevarerne og opnå en entydighed omkring klassifikation og egenskaber for produkter som døre o.lign. Men ikke bruge energi på at klassificere de projektspecifikke ydelser. En arkitektvirksomhed har gode erfaringer med at arbejde med en fast klassifikation på bygningsdele i en database et minimum generelt niveau, der ligger i systemet som en standard, som medarbejderne kan arbejde videre på, omdefinere og lave yderligere typologier på. Facilitator spørger om bygningsdelstypeteksten kan have en overordnet karakteristisk tekst (à la væg og dør ) og herefter andre beskrivelser, fx på den ene side relateret til materiale og form, på den anden side relateret til andre egenskaber. Dette bekræftes af deltagerne. Rådgiverne starter gerne let og sætter senere flere egenskaber på objektet eller skifter objektet ud, alt efter hvilke muligheder deres værktøj giver dem. Facilitator spørger, om klassifikation er nøglen til at skabe sammenhæng mellem bygningsdele og bygningsdelsbeskrivelser. Dette bekræftes ikke: Man bruger andre nøgler såsom navn komma type. Sammenhængen opstår ved at henføre til en type, som har sit eget afsnit og får et nummer, som den har i tilbudslisten. Dette kræver, at navn og typeangivelse skal være stringente. Æ, Ø, Å skal ikke med i klassifikationen (af hensyn til internationalt arbejde). Set fra de udførendes side er det positivt at få en kobling mellem objekter i en bygningsmodel og beskrivelser Paradigme for sammenhæng mellem klassifikation og bygningsdelsbeskrivelser For de udførende vil det være hensigtsmæssigt at lave et system, der favner begge dele. Bygningsdelsbeskrivelserne skal gøres mere funktionelle og operative i forhold til bygningsmodellen: De skal ikke ligge og flagre som et selvstændigt dokument o Også arkitekterne ser en fordel i dette: Det ville være super, hvis man er ude på pladsen og har en ipad med, at man kan pege på en bygningsdel og så kommer beskrivelsen frem. Det vil vi rigtig gerne Side 10 af 13

11 Der mangler et paradigme og et funktionelt system, så at når man opretter en bygningsdel af en given type i et værktøj, kan man gå ud og hente beskrivelsen. Man skal kunne linke automatisk frem for at bruge copy and paste. Det er meget forskelligt, om man først laver bygningsdelsbeskrivelser og reviderer bygningsmodellen efter dem, eller omvendt. I praksis er det typisk forskellige folk i virksomheden, som tager sig af hhv. beskrivelser og af bygningsmodellen, og som har et vidensgab mellem sig. Det ville være fint, hvis bygningsdelsbeskrivelser og bygningsmodel var koblet sammen. Så ville man ud fra bygningsdelsbeskrivelsen kunne se, hvilke forekomster der var under bygningsdelen i bygningsmodellen, tjekke om de stemmer overens og senere lave en kobling til tilbudslisten. o Hver bygningsdel skal have sit eget selvstændige punkt i tilbudslisten, så man kan se, hvad man giver pris for (som igen kan deles op i underpunkter, der har forskellige priser). o I princippet kunne det i en BIM-model være en egenskab tilknyttet. Men leverandøren har stadig behov for at få den samlede beskrivelse, der er en god indgangsvinkel til at vurdere projektet om noget er anderledes, end det plejer at være. Branchen er i et vadested mellem en gammel tradition om at starte med et blankt stykke papir, når man tegner en bygning, og en ny arbejdsform, hvor man starter med at sætte de 80%, som er genbrug og standard, ind som objekter og bygger videre på disse. o Dette kræver et standardopbygget bygningsdelsbibliotek med mulighed for variationer, gerne hvor beskrivelser er koblet på objekter. o Det kræver også en ændret rolleopfattelse hos arkitekterne. Bips beskrivelsesværktøjer har løftet beskrivelserne meget, men informationen kommer tit ikke ud: Det ender i skrivebordsskuffen o Beskrivelserne skal gøres mere operationelle, også ude i produktionen. Sammenkoblingen mellem beskrivelser og bygningsmodel skal ske via klassifikationssystemet og kræver en nedbrydning af dette. Det vil måske iflg. facilitator kræve, at objekterne i modellen får 4-6 klassifikationskoder, idet flere fag typisk arbejder på samme bygningsdel. Deltagerne er enige i denne forudsætning, men stiller spørgsmålstegn ved, om det kan gennemføres i praksis. Side 11 af 13

12 4.5. Funktionsudbud hvordan digitalt? Der er ikke enighed i branchen om, hvordan man laver funktionsudbud, funktionsbeskrivelser og mængder med funktionskrav: Funktionsudbud er en udbudsform, som af forskellige årsager vinder større og større indpas i branchen. Det er imidlertid uklart, hvad der ligger i et funktionsudbud: Skal man fx tegne en ledning eller bare skrive, at der skal være lys i rummet? Hvad ligger der i et funktionsudbud, og hvilke ydelser skal hvem levere? Uklarheden vedr. funktionskrav skaber misforståelser og konflikt mellem parterne. Mange har oplevet praktiske problemer ved funktionsudbud, fx at ventilationsanlæggene ikke passede ind, når de blev leveret. Rådgiverne oplever ofte ved funktionsudbud, at der kommer digitale ændringer mange gange og sent i processen. o Som minimum bør føringsvejene i bygningsmodellen afklares tidligt for at undgå problemer. Samarbejdsformerne bør generelt ændres, så leverandørerne inddrages tidligere i projekteringsfasen, hvis de skal dimensionere noget. Dette ligger dog uden for cunecos regi. Det skulle være muligt at lave funktionsudbud på et meget tidligt tidspunkt, allerede mens der skitseres. Nogle funktioner har afgørende indflydelse på arkitekturen fx ventilations- og facadesystem så her vil bygherrerne gerne vide, hvad de køber. o Det er dog nødvendigt for leverandørerne at kende konteksten for det, der funktionsudbydes: Man kender ikke den kasse, som funktionen skal ind i, den har man brug for en definition på Der mangler en standard for kravspecifikationer i funktionsudbud: Det er et oplagt emne til beskrivelsesudvalget. Også at lave eksempler på kravspecifikationer hvilke grænseflader, hvad man skal tage hensyn til, hvad det skal kunne. Så får vi et ensartet grundlag. Det er måske forskelligt fra ventilation til beton, men det er principielt det, vi mangler, for vi opfinder det hver gang Facilitator opsamler, at de nævnte ønsker handler om kravspecifikation, samarbejdsform og proces, men ikke om noget digitalt. Side 12 af 13

13 5. Prioritering af behov Afslutningsvist prioriterede deltagerne de diskuterede behov i forhold til, hvor vigtige de er for branchen at få løst. Deltagerne fik hver især 10 points, som de kunne fordele på emnerne. Tabellen viser den samlede pointfordeling. Område Points Informationsniveauer for udveksling af data mellem 18 aktørerne i værdikæden Standard for mængde- og dataudtræk ved udbud 13 Det skal være enklere at arbejde med klassifikation af 13 bygningsdele Paradigme for sammenhæng mellem klassifikation og 13 bygningsdelsbeskrivelser Standard for funktionsudbud 12 Side 13 af 13