Konklusioner fra bølge 2 fokusgrupper cuneco en del af bips Dato 17. 11. 2011 Projektnr. Sign. GF/MET 1. Baggrund cuneco vil i en behovsanalyse afdække byggebranchens behov for standarder for digital udveksling af information. Behovsanalysen består af tre elementer: Bølge 1, BEHOV: Workshops for de enkelte aktører (byg- og driftsherrer, arkitekter, rådgivende ingeniører, udførende og byggematerialeproducenter). Bølge 2, BEHOV: Fokusgrupper på tværs af aktører inden for faserne programmering, projektering, udførsel og drift & vedligehold. Bølge 3, LØSNINGER: Fokusgrupper på tværs af aktører inden for faserne programmering, projektering, udførsel og drift & vedligehold. Dette dokument beskriver konklusionen af bølge 2 fokusgrupperne, som blev afholdt hos cuneco den 13. - 31. oktober 2011. Fokusgruppemøderne havde følgende deltagere: Programmeringsfasen Projekteringsfasen Udførselsfasen Driftsfasen Marianne Kaae Nielsen, Universitets- og Bygningsstyrelsen. Peter Birk Hansen, UBST. Stine Tarhan, Gentofte Ejendomme. Ann-Marie Jensen, Gentofte Ejendomme. Mette Stokholm, Region Hovedstaden. Gert Munksgaard Thorsøe, Emcon. David Fink, smith hammer lassen architects. Leif Kaare Jensen, Rambøll. Christine Kalhauge, COWI. 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, Rambøll. Gert Jespersen, NCC. Allan Løvgreen, Kemp & Lauritzen. Kenneth Asbjerg, Jakon. Stefan Brandt Johansen, E. Pihl & Søn. Claus Erik Nielsen, NCC. Jakob Brysting, Rockwool. Thomas Gregersen, Linkcon. Claus Johannesen, PLH Arkitekter. Jens Kristian Lund Birkmose, COWI. Lars Holmsgaard, Landsbyggefonden. Torben Trampe, KAB. John Corell Nilsson, Slotsog Ejendomsstyrelsen. Bryan Karlqvist, Københavns Ejendomme. Michael Ørsted, Københavns Lufthavne. Henrik Carlsen, B. Nygaard Sørensen. Bjarne Christensen, YIT. Stefan Brorsen, Gottlieb Paludan. Christian Lundstrøm, Grontmij. Ellena Lee, Jakon. Jørgen Abildgaard, Jakon. 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. www.cuneco.dk Side 1 af 17
Fra cunecos side deltog: Torben Klitgaard, cuneco (facilitator) Gunnar Friborg, bips (facilitator) Lars Hvam, DTU (oplægsholder) Mette Øbro, cuneco (referent) Anette Prindahl, Qualiware (procesmodel-referent) Mødernes dagsorden var følgende: 1. Diskussion af case 2. Behovsidentifikation: Hvad er fasens største udfordringer vedr. udveksling og genbrug af data? 3. Gennemgang af de enkelte udfordringer 4. Opsamling og prioritering 2. Prioritering På baggrund af konklusionen af bølge 1 workshops diskuteredes fasernes største udfordringer vedr. udveksling og genbrug af data. De diskuterede emner blev afslutningsvist prioriteret ud fra, hvor stor værdi det vil skabe, at cuneco udvikler standarder på området. Resultatet fremgår af tabellerne nedenfor. Område Programmeringsfasen Points Informationsniveauer til udførelse af beregninger i de tidlige faser 34 Grundlag for struktureret arbejde med rumprogrammer 19 Indarbejdelse af bygningsdriftens behov i programmeringsfasen 13 *Udveksling af modeller 3 *Visualisering 1 Projekteringsfasen Informationsniveauer for udveksling af data mellem aktørerne i 18 værdikæden Standard for mængde- og dataudtræk ved udbud 13 Det skal være enklere at arbejde med klassifikation af bygningsdele 13 Paradigme for sammenhæng mellem klassifikation og 13 bygningsdelsbeskrivelser Standard for funktionsudbud 12 *Dette emne supplerede en enkelt deltager prioriteringsøvelsen med. Side 2 af 17
Udførselsfasen Standarder for udveksling og genbrug af data 25 Bedre opmålingsregler 19 Digitale tilbudslister 13 Standarder for materialespecifikation 13 Driftsfasen Egenskabsdatasæt for driftsobjekter 48 Standard for digital aflevering - automatisk indlæsning af as-built 45 information i driftssystemer Indarbejdelse af bygningsdriftens behov i programmeringsfasen 17 3. Udpegede standarder Analysen af fokusgruppediskussionerne indikerer samlet set, at cuneco og bips skal udvikle følgende standarder: Standarder inden for cunecos indsatsområder Standard for funktionsarealer og rum og deres egenskaber og sammenhænge Standard for opsamling af driftsdata til brug for bygningsdrift og programmering Standard for informationsniveauer, udveksling og datagenbrug Standard for opmålingsregler og mængde- og dataudtræk ved udbud og tilbud Standard for anvendelse af klassifikation Standard for anvendelse af egenskabsdata Standarder inden for bips indsatsområder Bygningsmodellen opdatering af arbejdsmetoder og regler Beskrivelsesstruktur og -værktøj opdatering vedr. struktur og indhold Beskrivelsesstruktur og -værktøj opdatering vedr. funktionsudbud Standard for digitale tilbudslister Andre emner Disse standarder er mere indgående beskrevet nedenfor, idet de ønsker og behov, som deltagerne har udtrykt på fokusgrupperne, er omformuleret til formål og indhold i standarderne. Side 3 af 17
3.1. Standarder inden for cunecos indsatsområder 3.1.1. Standard for funktionsarealer og rum og deres egenskaber og sammenhænge Større præcision i programkrav for udbud af opgaver i konkurrencer Grundlag for rumskemaer, bygningsmodellering, rum- og driftsdatabaser Større sikkerhed for opfyldelse af konkurrencekrav Bedre muligheder for sammenligning og validering af projekter Bedre grundlag for total- og energiberegning samt areal- og brugssimuleringer Bedre grundlag for forvaltning af arealer og rum Bedre benchmarking i form af bygningsindikatorer, opsamling af driftstal og skabelse af nøgletal for bygningsdrift og programmering Definition og klassifikation af funktions- og forvaltningsarealer (arealkategorier) i byggeri Klassifikation og fastlæggelse af vigtige egenskaber for rum og arealer Entydig definition af sammenhæng mellem brutto- og nettoarealer Fastlæggelse af sammenhæng mellem rum og funktionsarealer Om nødvendigt udarbejdes to eller flere modeller, hvis der er stor forskellighed i behov og anvendelse Proces Relaterede emner uden for cunecos primære projektområde: Proces omkring bygherrens interne behovsafklaring vedrørende arealer og rum Brugerinddragelse i det enkelte projekt Arbejdsprocessens dynamik i omsætning af program til projekt Interessenter og målgrupper: Bygherrer, bygningsejere, rådgivere og myndigheder Indgår i programmering, konkurrencer, tidlig projektering, evt. myndighedsbehandling samt i bygningsdrift og forvaltning 3.1.2. Standard for opsamling af driftsdata til brug for bygningsdrift og programmering En standard og basisstruktur for aflevering af data til bygningsdrift med opsamling fra projektering, udførelse og leverance vil kunne bevirke: Side 4 af 17
at der ikke nydefineres, og at der kun afleveres D&V-data, der er brug for at det undgås, at parterne bliver mødt af vidt forskellige krav at det undgås, at krav til driftsdata først fremkommer til afleveringen Det skal være nemt for bygningsejer at validere indkomne D&Vinformation. Der skal skabes grundlag for kravspecifikation for udvikling af kompatible it-værktøjer til brug for drift og programmering. Det skal undgås, at rådgivere, entreprenører og leverandører manuelt skal indtaste i mange forskellige bygningsejersystemer. At få større genbrug af (digitale) data fra tidligere processer og struktur for tilføjelse af driftsdata. Sikring af overførsel af vigtige bygningsdriftserfaringer til programmering. Der skal tænkes i aflevering af tre typer driftsdata: As built data til dokumentation for ansvar og for ombygning Data til brug for areal- og bygningsforvaltning Data til brug for den daglige bygningsdrift Fastlæggelse af egenskaber for arealer og rum til brug for bygningsdrift og forvaltning. Fastlæggelse af egenskaber på bygningsdele for bygningsdrift. 3D-objektmodeller skal tænkes ind i problematikken hvordan sættes bygningsmodellen op i forhold til driftsmodellen? Der skal ikke kun tænkes i 3D-modeller. Driftsherrerne arbejder med forskellige FM-systemer og gør tingene forskelligt. Driftdata kommer fra mange forskellige kilder. Ikke alle data findes i 3Dmodellen på forhånd, og ikke alle byggerier er fra store, 3D-baserede projekter. Materialet skal helst afleveres i databaseform som rådata eller i et åbent udvekslingsformat. Lige nu er det oplagt med en XML-struktur. Rigtig strukturering og klassifikation af data er en forudsætning for, at dataene bliver anvendelige. Der skal stilles krav til producenter om, hvordan produktdata skal leveres fx filtreret til forskellige aktører. Indarbejdelse af bygningsdriftens databehov i programmeringsfasen handler meget om totaløkonomi. Tilgængelighed af data er et vigtigt punkt, og levetid og vedligehold er uomgængelig parametre. Afleveringsdata skal gøres brugbare i driften helst i form af en aktivitetsliste. Der mangler en standard og en basisstruktur, som kan gøre det klart for alle aktører fra starten af processen, hvem der skal levere hvad og hvornår. IKT-aftalen dækker ikke dette behov. Side 5 af 17
Driftsherrerne skal blive enige om at udpege et begrænset antal bygningsdele (80/20) i opstart. Der er behov for et princip for objektets dataindhold, samt en relation til relaterede objekter (fx vindue + stillads dvs. bygningsdel + materiel). Relaterede emner uden for cunecos primære projektområde: Optimering af intern organisering og videndeling i bygherre/bygningsejerorganisationer med henblik på at anvende tidligere driftsinformationer i forbindelse med programmering af byggeri. Det er vigtigt, at driftspersonerne har indflydelse på programmeringsfasen og inddrages organisatorisk i beslutningerne. Der mangler en effektiv måde at inddrage driftsfolkene i processen på, da byggeafdelingen og driftsafdelingen typisk er adskilt organisatorisk. Man skal både finde de rigtige mennesker at inddrage, og den rigtige mødeform. Bygherrerne skal allerede i udbuddet stille kravene til afleveringsmaterialet det gør de ikke i dag. Interessenter og målgrupper: Bygningsejere og bygherrer, rådgivere, udførende og leverandører Indgår i programmering, aflevering af byggeriets informationer samt i bygningsdrift og forvaltning 3.1.3. Standard for informationsniveauer, udveksling og datagenbrug At få en fælles standard i byggesektoren for informationsniveauer og deres anvendelse og i forhold til, hvad der kan lade sig gøre på et givet tidspunkt i byggeprocessen. At få klart definerede informationsniveauer ikke uklare, upræcise og flydende som de, der er fastlagt fra 2006-2008. At få skabt grundlag for veldefinerede IDM er. At undgå mistillid og uklare aftaler mellem parterne. At få skabt klare grænseflader mellem fastlæggelse af informationsniveauer, faser og generelt beskrevne rådgiverydelser og entrepriseleverancer. Informationsniveauer fastlægges i forhold til aktørernes behov for informationer, de ønsker at modtage og genbruge, og så det kan fastlægges i en IKT-aftale mellem parterne. Informationsniveauer skal defineres og fastlægges i forhold til aktør, proces og informationsbehov og selvstændigt/uafhængigt i forhold til Side 6 af 17
fasemodellen, idet niveauer kan være uensartede i forhold til afklaring på specifikke bygningsdele, rækkefølgen af projekteringsaktiviteter og beslutningsbehovene for projektet. Informationsniveauer for funktionsudbud skal også fastlægges det skal ikke kun være for detailudbud. Informationsniveauer skal måske alene knyttes til bygningsdele (og rum). Det må vurderes, hvordan informationsniveauer eventuelt kan knyttes sammen med faser efter 80/20-reglen og A113-modeltankegangen, og hvordan afvigelser så evt. beskrives. Der skal arbejdes med, hvad der kan hægtes op på en bygningsmodel. Det skal vurderes, om der skal opereres med fastlæggelse af informationsniveauer i en successiv proces gennem en byggesag, fx 60%, 80%, 100%. Det skal afklares, om forskydningen mellem fx arkitektens og ingeniørens arbejde indvirker på, om der projekteres på forskellige informationsniveauer inden for samme (del)faser. Det undersøges, om det er muligt at arbejde med A113 lignende løsningsmodeller for fastlæggelse af grupperede informationsniveauer. Informationsniveauer kan også omfatte samlinger eller grupperinger af dokumenter eller procesdokumenter i form af logbøger, databaser etc. I grænseflade til opmålingsregler defineres informationsniveau for de mængder, som kalkulationsfolk ønsker på bygningsdele og rum. Relaterede emner uden for cunecos primære projektområde: Ønske om opdatering af rådgivernes ydelsesbeskrivelser med definitioner af, hvad faserne indeholder på digitalt niveau. Det vurderes, at det i høj grad er udbudsreglernes blokering for produktspecifikation og manglende detailspecificering, der giver mange forståelses- og udvekslingsmæssige problemstillinger i selve processen. Manglende gensidig tillid og værktøjsinkompatibilitet er også årsager til, at data ikke genbruges, men at parterne starter forfra. Interessenter og målgrupper: Alle byggeriets parter Indgår i alle byggeriets faser og alle informationsudvekslingsaktiviteter, fx: mellem bygherren og rådgiverne ved opstart af projekteringsprocessen mellem rådgiverne i projekteringsfasen mellem rådgivere og myndigheder i forbindelse med myndighedsbehandlingen mellem rådgiverne og entreprenørerne ved udbud og tilbud mellem byggevareleverandører og udførende ved bestilling og leverancer mellem rådgivere/entreprenører og bygningsejere/bygningsdriftsorganisationer mellem bygningsdrifts-og bygherreorganisationer etc. Side 7 af 17
3.1.4. Standard for opmålingsregler og mængde- og dataudtræk ved udbud og tilbud Sikre mere gnidningsfri dataudveksling i udbud/tilbudssituationen. Fremskaffelse af mængder i udbud, der forbedrer mulighederne for de udførende for direkte at kunne kalkulere pris og bestille materialer ud fra udbudsmaterialet. Endelig afklaring af mængder på (det højere) udbudsniveau i forhold til mængder anvendt på (det mere detaljerede) tilbudsniveau, og forholdet mellem udbudsmængder og udførelses/ tilbudsmængder. Afklaring af, hvordan forskellige værktøjer trækker mængder forskelligt ud (validitet) og afklaring af, om der internationalt skal lægges op til en fælles fremtidig standard for dette. Finde ud af grundlaget for hvor meget af processen og valideringen, der kan automatiseres. Fjerne usikkerhed om mængder, der gør tilbudssammenligning svær. Regler for dataudtræk fra en bygningsmodel skal specificere, hvordan man modellerer (objekt- og datadisciplin), hvad man selv skal tilføje, og hvad man gør, når værktøjerne gør det forskelligt. Opmålingsregler forudsætter, at der laves modelleringsregler og en struktur for, hvordan mængderne kobles på beskrivelsessystemet. I stedet for beskrivende mængdefortegnelse kan underpunkter i bygningsdelsbeskrivelserne vedrørende områder af bygningsdele, hvor fx dimensionering og udførelse er lidt anderledes, følge med over i tilbudslisterne. Til brug for informationsniveaustandard: Informationsniveau for udbud skal præcisere, hvad man kan forvente at finde af mængder i bygningsmodel og i tilbudslister. Det skal afklares, om der kan laves en (XML)standard via cuneco. Det undersøges om fx små og store entreprenører har forskelligt informationsbehov i forhold til tilbudsgivningen og hvilke konsekvenser, det har for projekt og tilbudsgivning. Afgrænsning af, hvad der kan defineres som hhv. en udbudsmængde og en tilbudsmængde, skal diskuteres og defineres. Mængder vedr. funktionsudbud skal også afklares. Det skal afklares, om der skal kunne afgives delmængder i tilbuddet, og hvad de evt. skal kunne bruges til. Nuværende opmålingsregler suppleres, så der ikke kun er mængder, men også de ydelser, der sælges (klassifikationstabel). Nuværende opmålingsregler suppleres med de regler, der gælder på enkelte bygningsdelstyper og arbejder om, hvordan man beregner mængden i det udførende led. Side 8 af 17
Relaterede emner uden for cunecos primære projektområde: Det juridiske aspekt med ansvar for mængderne, rådgivernes forbehold for mængdeansvar, og princippet med at de udførende skal overtage ansvaret for mængderne i forbindelse med indgåelse af entreprisekontrakt, bør endeligt afklares det diskuteres fortsat i hele byggesektoren. Delvist udenfor: Publikation(er) for de eksisterende opmålingsregler bør være kortere, mere entydige (der er mulighed for flere måleregler) og mere visuelt grebet an fx ved visning af brutto/netto-mål på en søjle eller lignende på andre bygningsdele. Interessenter og målgrupper: Bygherrer, rådgivere og udførende Indgår primært i udbuds- og tilbudsfasen men rækker ind i: den tidlige projektering og rådgiverkalkulation for fx det prissatte projektforslag den detaljerede kalkulation i det udførende led, herunder processer omkring priskuranter, akkorder mv. prissætning af drift- og vedligeholdelsesaktiviteter i forbindelse med bygningsdrift 3.1.5. Standard for anvendelse af klassifikation Klassifikation skal understøtte kategorisering og proces med at fremfinde de rette informationer i forbindelse med fastlæggelse, deling og anvendelse af information mellem parterne. Klassifikationskode skal primært håndteres af it-værktøjerne, sekundært anvendes som analog kode af brugerne. Der bør én gang for alle tages stilling til, om klassifikationskoder er noget, der skal kunne huskes analogt og hvis ja, i hvilket omfang. Klassifikation og referencekode skal kunne anvendes hver for sig, fordi der er forskellige parter, der har forskellige behov. Det skal fastlægges, hvornår parterne kan anvende deres egne koder, og hvornår det er nødvendigt at anvende fælles klassifikationskodning. Anvendelsesbehovet for klassifikation skal afklares gennem konkrete eksempler for forskellige fagområder. Det vurderes, om det er nemmere at arbejde med det bygningsdelene hedder og er (som giver mening) end at få vist en kode bestående af tegn (tal og bogstaver), som ingen kan huske. Klassifikation skal skilles fra referencesystemet. Arkitekterne har alene Side 9 af 17
behov for overblik over hvilke komponenter, der anvendes i et byggeri enten via eget klassifikationssystem eller et fælles. Producenterne opererer med deres egne klassifikationer (koder og produktnavne), som arkitekten først sent/aldrig sætter ind i modellen. Kodningsspørgsmålet skal afklares: Koden må ikke være en fortolkningskode. Den skal overholde matematiske regler for kodning, så den i sig selv er maskinaflæselig. Koden må ikke være for lang. Tit vil man hellere bare give objektet et nummer. Det kan være nemmere at anvende værktøjets egen nedbrydningslogik det kan være svært, hvis man har en prædefineret tilgang. DBK skal lægge sig op af det internationale ISO-arbejde mht. at finde/udvikle tabeller. Klassifikation skal kunne understøtte anvendelse også af beskrivelsesværktøjet. Det skal afklares med alle byggeriets parter, om ambitionsniveauet i det eksisterende DBK er for stort om man har villet ramme for langt nede, eller hvor overliggeren skal være. Byggeriets parter skal specifikt inddrages i dette spørgsmål. Det skal afklares, hvad der er det rigtige typiseringsniveau i forhold til at kunne skabe objektbiblioteker og families for at kunne navngive objekttyper eller have et system til at sortere typerne i. Hvor er de vigtigste adskillende egenskaber på fx døre, og hvilke egenskaber er mindre vigtige fx i forhold til prissætning? Det skal afklares, om det er hensigtsmæssigt at starte med et objekt med få egenskaber og successivt putte flere på, eller om det er bedre at skifte objektet ud undervejs med et med flere egenskaber. Og hvad betyder dette for klassifikation og anvendelse. Det skal afklares, hvordan sammenhængen er mellem bygningsdele i bygningsmodeller, bygningsdelsbeskrivelser og kalkulationer i forhold til entydighed og klassifikation. Der er ikke enighed eller standard på dette område. For rum skal afklares: Bruges der én type koder for at kunne lave og dokumentere projektet, og laver man bare den endelige (en anden) rumnummerering bagefter og udelukker/supplerer de hinanden? Bygningsdriftsklassifikation: En fremtidig klassifikation skal både være relevant for de store, professionelle bygherrer og for de mindre bygherrer, som kører på et lavere teknisk niveau. Evt. via forskellige niveauer et overordnet niveau, hvor tingene beskrives på et overordnet niveau for dem, der alligevel selv går ud og måler med tommelstok og et mere detaljeret niveau for dem, der magter at gå dybere ned. Det må ikke blive for voldsomt, så almindelige mennesker ikke kan se, hvor de er henne. Side 10 af 17
Interessenter og målgrupper: Alle byggeriets parter Indgår i alle byggeriets faser og alle informationsudvekslingsaktiviteter, hvor der skal være konsensus om, hvad noget hedder, hvordan det skal ses, kunne findes, sorteres etc., for at sikre entydighed, overblik og håndterbarhed. 3.1.6. Standard for anvendelse af egenskabsdata Der skal skabes struktur for, hvordan egenskabsdata skal ses i en sammenhæng, hvilke objekter de skal kunne knyttes til, hvordan de skal kunne klassificeres, og hvilke informationer der skal kunne knyttes til egenskabsdata, for at disse formål kan opfyldes. Egenskabsdata skal kunne anvendes i alle situationer, af alle værktøjer og af alle aktører. Fastlæggelse af egenskabsdata med tilknyttede informationer kan danne grundlag for informationsniveauer og IDM er og mapping via IFD. Afklaring af, hvilke dele af egenskabsdataproblematikken, der kræver international konsensus, og hvilke der bare kan arbejdes videre med. Det skal undersøges, om der kan tages udgangspunkt i de produkter og egenskabsdata, producenterne i forvejen anvender. Det skal undersøges, om mange informationer i et udbudsmateriale kan erstattes af referencer til standarder. Der skal evt. opdeles i standard- og unika-objekter, så udbudsmaterialet kan indeholde: o o en del alene med standard-objekter uden tilføjelser og en del med unika-objekter, hvor entreprenøren er nødt til at læse de enkelte beskrivelser (grænseflade til bygningsdelsbeskrivelser i Beskrivelsesværktøj struktur og indhold). Egenskabsdata og deres definitioner og anvendelse er grundlaget for Produktionskort-tankegangen (grænseflade over mod Standard for informationsniveauer). Standarden skal skabe entydighed for, hvad et produkt består af, fx om bundkant er med i overfladen, om beslåning er med i vægten, etc. standarder skal være entydige. o Det vil være en stor fordel med en fælles produktklassifikation. Med bare 80% dækning vil det være meget brugbart. Og det skal være minimum en EU-standard ellers vil producenterne ikke anvende det. Der skal være en standard til producenterne for egenskabsdata for byggevarer og komponenter. Producenter skal stille skalerbare data til rådighed hvor brugere selv kan vælge det informationsniveau, de ønsker, Side 11 af 17
og som kan anvende direkte i bygningsmodellen. I forhold til driften er det relativt få informationer, der er behov for, såsom levetid, og hvordan funktionen sikres. Driftsherrerne vil gerne modtage data fra producenterne med mulighed for selv løbende at modificere data ud fra egne erfaringer. Ud fra bygningsdelskort og principper for vedligehold kan peges på hvilke typer af information, som er interessante at trække ud, hvis de findes i produktinformationen eller i udførelsen. Driftsherrerne skal justere data fra starten, så de sikrer sig, at data passer til deres specifikke situation fx er der forskel på, hvor tit vinduer skal males, alt efter om de sidder på nord- eller sydsiden. Driften hægter egenskaber på både bygning, lejligheder, rum og bygningsdele. Det var godt, hvis der kunne knyttes egenskabsdatasæt til forskellige objekter, og driftsherrer kunne hente hinandens egenskabsdatasæt og knytte disse til egne objekter. Man kan hurtigt finde et minimumsniveau for vedligehold: Driftsfasen skal grundlæggende bare bruge, hvad der skal gøres og med hvilken frekvens. Man kunne knytte flere aktiviteter til bygningsdelen, fx hvor tit tjekke noget, minimumsvedligehold osv. 2-5 aktiviteter pr. bygningsdel er et relevant antal. Et automatisk genereret DV-system kan dog ikke stå alene, men skal suppleres fx i forhold til akut vedligehold. Driftsherren vil gerne have basisinformation fra afleveringen, som kan bruges til fx efterfølgende malerbehandling af vinduer, så det ikke er nødvendigt at tilkalde en rådgiver, når vinduerne skal males efter 5 år informationen kan sendes direkte ud til entreprenøren. I princippet skal alle de informationer, nogen synes er værd at få lagt ind i en pdf og sætte i ringbind, lægges ind i egenskabsdatasættet. Det handler blot om at strukturere data, så man kan finde dem, og man selv kan vælge hvilken pakke, man vil have. 2-5 aktiviteter er ikke tilstrækkeligt. IInteressenter og målgrupper: Alle byggeriets parter Indgår i alle byggeriets faser og alle informationsudvekslingsaktiviteter, hvor der skal være konsensus om, hvad informationerne er, hvordan de skal ses, kunne findes, sorteres etc. for at sikre entydighed, overblik og håndterbarhed. 3.2. Standarder inden for bips indsatsområder 3.2.1. Bygningsmodellen opdatering af arbejdsmetoder og regler En mere entydig definition af modelarbejdet, så det bliver tydeligt, hvor der er unødigt dobbeltarbejde for flere parter, og hvor der er nødvendigt Side 12 af 17
dobbeltarbejde af hensyn til de enkelte parters afklaring på egne faglige områder. At rådgivernes bygningsmodeller kan få værdi for entreprenørers og leverandørers videre udnyttelse af struktur og informationer. Hvad skal der til, for at rådgiverne kan lave grundlaget for en bedre udførelsesmodel? Bygningsmodellen, der overtages af entreprenøren, skal være lavet, så det er nemt for de udførende at bruge den som kommunikationsværktøj over for underentreprenører og leverandører, og så den kan danne udgangspunkt for planlægning af udførelsen (4D og 5D). Der skal laves modelleringsregler for at sikre, at de rigtige udbudsmængder kan udtrækkes, og for at der skabes bygningsmodeller hos rådgiverne, der kan anvendes fremadrettet af de udførende og af bygningsdriften. Interessenter og målgrupper: Rådgivere, udførende og eventuelt leverandører. I forbindelse med fremtidig overlevering fra rådgiverne af en åben bygningsog informationsmodel til de udførende. 3.2.2. Beskrivelsesstruktur og -værktøj opdatering vedr. struktur og indhold Bedre sammenhæng mellem bygningsmodel, beskrivelses- og kalkulationsinformationer samt mængdeudtagning og tilbudsliste. Bedre kvalitetssikring af, om det hele er med. Mulighed for at åbne for mere bygningsdelsinformation gennem flere værktøjsadgange. Standardisering af bygningsdelsbeskrivelser, så egenskabsdata står i fast struktur og klar tekst står i fast definerede felter. Mulighed for standardiseret opbygning af objektbiblioteker. Bygningsdelsbeskrivelserne skal gøres mere funktionelle og operative i forhold til bygningsmodellen de skal ikke flagre som et selvstændigt dokument. Fx peg på en bygningsdel i bygningsmodellen, og bygningsbeskrivelsen kommer frem. Nogle starter med bygningsdelsbeskrivelser, andre starter med bygningsmodellen der skal kunne linkes begge veje. Ved sammenkobling af objekter i bygningsmodel og bygningsdelsbeskrivelserne kan man tjekke, om der er de forekomster, der skal være (kvalitetssikring), og skabe bedre kobling til tilbudslisten, mængdeudtagning mv. Hver bygningsdel skal have sin plads i tilbudslisten med mulighed for Side 13 af 17
opdeling i underpunkter ved forskellige variationer (delegenskaber) + forskellig prissætning under samme beskrivelse. Egenskaber i en 3D-model er godt, men leverandører påpeger nødvendighed af beskrivelser i forhold til kendte standarder eller afvigelser herfra både mht. leverance og udførelse. Kan der laves: o o standard-objekter uden åbne tekstfelter og uden tilføjelser og unika-objekter, hvor entreprenøren skal læse de enkelte bygningsdelsbeskrivelser. Der skal være mulighed for beskrivelsesmæssig opbygning af objekt/bygningsdelsbiblioteker med variationsmuligheder (80/20) og med kobling til cad-objekter i objektbibliotek til brug for bygningsmodellen. Interessenter og målgrupper: Rådgivere, udførende og eventuelt leverandører I forbindelse med fremtidig overlevering af informationer fra rådgiverne til entreprenører og de udførendes tilgang til disse. Samt større standardiseret genbrug af bygningsobjekter i IKT-værktøjer. 3.2.3. Beskrivelsesstruktur og -værktøj opdatering vedr. funktionsudbud Formål Der skal skabes enighed i byggeriet om, hvad funktionsudbud er, når det bliver mere og mere anvendt. Samtidig skal skabes klarhed over, hvordan manglende produktangivelse ved EU-udbud skal håndteres, idet det i dag både kan ses som funktionsudbud og som utilstrækkeligt specificeret detailudbud. Det skal undgås ved funktionsudbud, at der skabes mange digitale ændringer specielt sent i processen. Der skal skabes klarhed vedrørende bygningsdele og rum om hvilke funktionskrav, der skal/kan gøres gældende og hvordan. Konteksten og forudsætningerne skal defineres. Der skal udarbejdes repræsentative eksempler, som viser, hvordan funktionsudbud skal håndteres og kan se ud. Det skal afklares, hvad der forstås ved mængder i et funktionsudbud (grænseflade til Standard for mængde- og dataudtræk ved udbud og tilbud), og hvordan et som-produkt kan specificeres, herunder hvilke egenskaber/parametre, der er de vigtige, så de tilbudsgivende ikke selv skal gætte. Side 14 af 17
Relaterede emner uden for beskrivelsesværktøjets primære projektområde: Organisations- og procesmæssige forhold, fx tidlig inddragelse af andre parter i projekteringen, ekstra fase for projektering efter tilbudsgivning og lign., ligger uden for beskrivelsesværktøjets område og må diskuteres af byggeriets parter såvel med hensyn til ydelser og leverancer som konsekvenser for pris og samarbejde. Diskussion af fordele og ulemper vedr. o udbud på detailniveau og med detailmængder og næsten ingen frihedsgrader alene med fokus på prisen, og o udbud på funktionskrav og få specificerede mængder, der giver de tilbudsgivende stor handlefrihed, men også indflydelse på bygherrens valg eller mulighed for valg af kvalitet, samtidig med at bygherren kan få flere muligheder i spil. Interessenter og målgrupper: Rådgivere, udførende og eventuelt leverandører I forbindelse med udbud og tilbud ved offentligt og EU-støttede byggeprojekter og i forbindelse med valg af funktionsudbud på grund af: bygherres ønske om at få flere løsningsforslag i spil rådgiveres manglende viden for at kunne lave et detailudbud manglende tilstrækkeligt honorar til at kunne lave et detailudbud 3.2.4. Standard for digitale tilbudslister Alle data omkring tilbudslister skal kunne genanvendes både digitalt og analogt. Der skal være velkendt og veldefineret struktur og detaljeringsniveau på tilbudslister, eller der skal laves principmodeller a la A113 for struktur og detaljeringsniveau. Det skal være klart, hvad sammenhængen er mellem tilbudslister, bygningsmodeller, beskrivelser og kalkulationsværktøjer. Hvordan sikres også juridisk, hvis det er et emne, at digitale tilbudslister kan være i genanvendeligt format excel frem for pdf-filer eller lignende åbent format. Hvordan kan data fra cad/bygningsmodel og tilbudslister genbruges i produktionen, og stiller det krav til angivelse af produkternes lokalisering og cad-modellens strukturering? Side 15 af 17
Hvor placeres udgifter til byggeplads, logistik, styring mv.? Det gør det svært at sammenligne tilbud, at disse kan lægges forskellige steder og er forskellige fra projekt til projekt. Det skal afklares, hvad de enkelte parters behov er omkring tilbudslisten og dens detaljering og opdeling for bygherren, rådgiveren og entreprenøren. Der skal findes det rette detaljeringsniveau eller detaljeringsmodelniveauer for projekter fx i forhold til prisvurdering og -regulering, fravalg og tilvalg, behov for detailmængder, opdeling på entrepriser, fag, lokaliteter mv. for at få en entydig definering af posterne. Det skal behandles, hvordan enhedspriser kan anvendes/ikke anvendes i forhold til hvilken sammenhæng de indgår i, idet en tilvalgt ekstraydelse kan være både meget dyrere og meget billigere at realisere end angivet i det oprindelige tilbud. Kalkulationens underposter skal de være et bilag til tilbudslisten? Fordele og ulemper skal belyses. Relaterede emner uden for de digitale tilbudslister: Bygherren bør som minimum stille de programmer til rådighed, som skal anvendes for at se udbudsmaterialet. Der afleveres fx mange modeller i cad-format uden viewere. Opfordring til at byggebranchen står sammen om krav til anvendelse af IFC, så software kan snakke sammen. Interessenter og målgrupper: Bygherrer, rådgivere og udførende Indgår primært i udbuds- og tilbudsfasen men rækker ind i: den tidlige projektering og rådgiverkalkulation for fx det prissatte projektforslag den detaljerede kalkulation i det udførende led, herunder processer omkring priskuranter, akkorder mv. prissætning af drift- og vedligeholdelsesaktiviteter i forbindelse med bygningsdrift 3.2.5. Andre emner Der mangler standarder for projektweb for, hvornår og hvordan man udveksler informationer. Cuneco bør tænke i, hvordan de udførendes processer kan optimeres digitalt. Hvordan kan håndværkerne komme til at arbejde mere effektivt? Der bør ses på installationsbranchen, som er nået længere end den øvrige byggebranche og i høj grad benytter sig af fælles objekter fra en teknikbank, hvor rådgiverne også henter objekterne til deres BIM-model. Side 16 af 17
Relaterede emner uden for cunecos indsatsområder: For kort tid til tilbudsafgivelse og for mange ændringer i projektet kort før afleveringen. Informationer, der er lagt ind i modellen, for at rådgiveren kan lave sine beregninger, bliver fjernet inden udbud, så de udførende ikke kan gøre brug af dem. Det er nødvendigt at bygherrer og rådgivere bliver enige om ansvarsproblematikken (økonomi- og risikofordeling) ved, at detaljerede rådgiverinformationer i 3D-modellen kan blive anvendt i forbindelse med udførelsen evt. til formål de ikke oprindeligt var blevet skabt til og i en fase, hvor de store risici ligger. Side 17 af 17