behovsanalyse bilag 29. februar 2012

behovsanalyse bilag 29. februar 2012

Oversigt over bilag: Bilag 1: Behovsområder og input til løsninger s. 1 Bilag 2: Procesmodeller s. 17 Bilag 3: Brugerscenarier s. 19

BILAG 1: BEHOVSOMRÅDER OG INPUT TIL LØSNINGER Dato 29. 2. 2012 cuneco en del af bips Projektnr.10011 Sign. GF/MET Indholdsfortegnelse Indholdsfortegnelse... 1 1. Læsevejledning... 1 2. Klassifikation... 2 3. Egenskabsdata... 4 4. Eks: Funktionsarealer og rum... 6 5. Informationsniveauer... 7 6. Eks: Opsamling af driftsdata til brug for drift og programmering... 10 7. Opmålingsregler... 12 8. Standard for digitale tilbudslister... 14 9. Input til bips... 16 1. Læsevejledning Deltagerne i behovsanalysen har formuleret en lang række behov i relation til cunecos indsatsområder, dvs. behov som ideelt set ønskes indfriet vha. de standarder og værktøjer, som cuneco skal udvikle. Nogle af ønskerne ligger klart inden for cunecos indsatsområder, mens andre ligger i udkanten, men alle de behov, som kan siges at have en relation til cunecos indsatsområder, er medtaget i dokumentet. De problemer, behov og ønsker, som deltagerne har udtrykt, er af cunecos analyseteam blevet omformuleret til formål og indhold i en fremtidig løsning, fx i form af en standard. De formulerede behov og input til løsninger er nedenfor beskrevet under cunecos fire indsatsområder: Klassifikation, egenskabsdata, informationsniveauer og opmålingsregler. 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 16

Behov/input til løsninger er beskrevet under følgende overskrifter: Formål: hvad ønskes opnået? Indhold: Hvilke elementer skal der arbejdes med for at nå dette mål? Relaterede emner uden for cunecos område Interessenter og målgrupper: Hvem er det relevant for? Situationsbeskrivelse: i hvilke situationer opstår behovet? Det skal bemærkes, at beskrivelsen nedenfor ikke er en gennemgang af de standarder, der skal udvikles i cuneco, men en opsamling af de problemer og inputs til løsninger, der er fremkommet i behovsanalysen. Hvordan cuneco forholder sig til disse inputs og indarbejder dem i sin projektportefølje er en anden sag, som beskrives i et selvstændigt dokument. 2. Klassifikation Der er overordnet behov for et klassifikationssystem og en vejledning for anvendelsen af dette. Formål: 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. Indhold hvilke elementer skal der arbejdes med? Det skal 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 behov for overblik over hvilke komponenter, der anvendes i et byggeri enten via eget klassifikationssystem eller et fælles. Side 2 af 16

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. Klassifikationen 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. Klassifikation og niveauer de forskellige aktører har forskellige detaljeringsbehov. 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 fx hvor tingene beskrives på et overordnet niveau for dem, der alligevel selv går Side 3 af 16

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. Interessenter og målgrupper: Alle byggeriets parter Situationsbeskrivelse: 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. Egenskabsdata Der savnes en standard for egenskabsdata og en vejledning for anvendelsen af denne. Formål: Egenskabsdata skal kunne anvendes i alle situationer, af alle værktøjer og af alle aktører. Det er vigtigt at strukturere egenskabsdata og få alle de forskellige aspekter med fx at få fat i hvilke egenskaber driften, energiberegningen og indeklimasimuleringen har brug for. 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. 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. Indhold hvilke elementer skal der arbejdes 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 en del alene med standard-objekter uden tilføjelser og Side 4 af 16

o 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øjet). Egenskabsdata og deres definitioner og anvendelse er grundlaget for Produktionskort-tankegangen (grænseflade over mod informationsniveauer). En standard skal skabe entydighed for, hvad et produkt består af, fx om bundkant er med i overfladen o.lign. 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 som minimum være en EU-standard, ellers vil producenterne ikke anvende den. 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, og som de kan anvende direkte i bygningsmodellen. Producenter og leverandører oplever et stigende pres fra omgivelserne for at levere dokumentation på materialerne, såsom sikkerhedsdatablade, installationsmanualer og driftsmanualer. 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. 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 Side 5 af 16

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. 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. Interessenter og målgrupper: Alle byggeriets parter Situationsbeskrivelse: 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. Som eksempel på et emne, der blev diskuteret i behovsanalysen, og som både omhandler klassifikation og egenskaber, kan nævnes funktionsarealer og rum. Dette eksempel gennemgås selvstændigt nedenfor. 4. Eks: Funktionsarealer og rum Udviklingen af en klassifikation og en standard for egenskabsdata kan skabe værdi inden for arbejdet med funktionsarealer og rum ved at skabe mere struktur og større entydighed. Formål: 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 Indhold hvilke elementer skal der arbejdes med? Definition og klassifikation af funktions- og forvaltningsarealer (arealkategorier) i bebyggelser, bygninger og rum Klassifikation og fastlæggelse af vigtige egenskaber for rum og arealer Entydig definition af sammenhæng mellem brutto- og nettoarealer Dansk Standard opererer med netto-arealer, men det er delmængden netto-brugsarealer, som bygherrer interesserer sig for. Fastlæggelse af sammenhæng mellem rum og funktionsarealer Side 6 af 16

Om nødvendigt udarbejdes to eller flere modeller, hvis der er stor forskellighed i behov og anvendelse Afklaring af, hvordan arealer og rum hænger sammen med bygningen og hele bebyggelsen/ejendomskomplekset. 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 Situationsbeskrivelse: Indgår i programmering, konkurrencer, tidlig projektering, evt. myndighedsbehandling samt i bygningsdrift og forvaltning 5. Informationsniveauer Der savnes veldefinerede informationsniveauer, som gør det enklere for byggeriets parter på tværs af værdikæden at afstemme forventninger til hvilke data, der skal udveksles hvornår og i hvilken detaljeringsgrad. Formål: 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 klare grænseflader mellem fastlæggelse af informationsniveauer, faser og generelt beskrevne rådgiverydelser og entrepriseleverancer. At undgå mistillid og uklare aftaler mellem parterne. At få skabt grundlag for veldefinerede IDM er. Indhold hvilke elementer skal der arbejdes med? 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 fase- Side 7 af 16

modellen, 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. Der mangler en metode for beskrivelse af projektspecifikke digitale leverancer (informationsniveauer) og en beskrivelse af typisk praksis for en række typiske byggerier, så bygherrerne kan se eksempler på leverancer. 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. Der mangler afklaring om, hvilke dataniveauer der er tilstrækkelige for at kunne lave beregninger på modellen. 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 skal 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. De udførende efterspørger standarder for grænseflader: o Grænsefladen mellem projekt og produktion: En standard (IDM) for grænsefladen mellem de projekterendes projekt og de udførendes produktionsplanlægnings- og styringssystemer. Der skal opstilles regler for formater, egenskabsdata og objektstruktur, ligesom der skal formuleres krav til tegningsfordelingslister, produktionstegninger mm. Rådgivernes projekt skal m.a.o. rumme de nødvendige data og være kompatibelt med de udførendes systemer, og det skal foregå ensartet fra gang til gang. Side 8 af 16

o o Grænsefladen mellem hoved-/totalentreprenør og underentreprenør: En standard (IDM) for hoved-/totalentreprenørens samarbejde med underentreprenører. Hvem skal modtage hvilke data hvornår? Fastlagte retningslinjer for kommunikationen mellem hoved-/totalentreprenør og underentreprenører. Grænsefladen mellem totalentreprenør og rådgiver: Guidelines der specificerer, hvad rådgiveren skal levere. Relaterede emner uden for cunecos områ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. Materialevirksomhedernes holdning er, at de vil levere ét objekt, uanset målgruppen. Man ønsker således ikke at segmentere sine produkter til målgruppen, men at levere det samme objekt til alle (som dog kan være skalerbart i det enkelte byggeprojekt). Interessenter og målgrupper: Alle byggeriets parter Situationsbeskrivelse: 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. Som et konkret eksempel på de efterspurgte informationsniveauer kan nævnes informationsniveauer vedr. opsamling af driftsdata til brug for bygningsdrift og programmering, hvilket der var stor efterspørgsel på blandt deltagerne i behovsanalysen. Eksemplet beskrives derfor selvstændigt nedenfor. Side 9 af 16

6. Eks: Opsamling af driftsdata til brug for drift og programmering Formål: 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. En standard og basisstruktur for aflevering af data til bygningsdrift med opsamling fra projektering, udførelse og leverance vil kunne bevirke: 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. Større genbrug af (digitale) data fra tidligere processer og struktur for tilføjelse af driftsdata. Driftsherrerne skal kunne lave et mere præcist udbud af opgaver, hvilket kræver, at de kender de eksakte mængder (fx mængden af påkrævet maling til det enkelte vindue). Sikring af overførsel af vigtige bygningsdriftserfaringer til programmering. Indhold hvilke elementer skal der arbejdes med? 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, rum og bygningsdele til brug for bygningsdrift og forvaltning. 3D-objektmodeller skal tænkes ind i problematikken hvordan sættes bygningsmodellen op i forhold til driftsmodellen? Side 10 af 16

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. Afleveringsdata skal gøres brugbare i driften helst i form af en aktivitetsliste. Tilgængelighed af data er et vigtigt punkt, og levetid og vedligehold er uomgængelig parametre. Indarbejdelse af bygningsdriftens databehov i programmeringsfasen handler meget om totaløkonomi. 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). Der bør i cunecos udviklingsprojekter ses på resultaterne fra Bygherreforeningens nedenstående fire udviklingsprojekter mhp. koordinering, videreudvikling og understøttelse: Modelstrategi for BIM objekter og egenskaber i FM Veldefineret digital aflevering gennem IDM Fra papir til BIM fra dokumenter til modelbaseret digitalisering BIM-understøttet standard for tilstandsvurdering. Relaterede emner uden for cunecos område: Bygherrerne skal allerede i udbuddet stille kravene til afleveringsmaterialet det gør de ikke i dag. Side 11 af 16

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. Interessenter og målgrupper: Bygningsejere og bygherrer, rådgivere, udførende og leverandører Situationsbeskrivelse: Indgår i programmering, aflevering af byggeriets informationer samt i bygningsdrift og forvaltning 7. Opmålingsregler Der er behov for entydige opmålingsregler og en struktur for mængde- og dataudtræk ved udbud og tilbud. Formål: At sikre mere gnidningsfri dataudveksling i udbud/tilbudssituationen. At fjerne usikkerhed om mængder, der gør tilbudssammenligning svær. 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. Side 12 af 16

Indhold hvilke elementer skal der arbejdes med? 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 informationsniveau-arbejdet: Informationsniveau for udbud skal præcisere, hvad man kan forvente at finde af mængder i bygningsmodel og i tilbudslister. Det undersøges, om der er forskellige informationsbehov i forhold til tilbudsgivningen baseret på, i hvor høj grad den enkelte entreprenør sjusser eller laver eksakte beregninger og hvilke konsekvenser, dette 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 på bygningsdele, men også findes de ydelser, der i øvrigt leveres og afregnes (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. Relaterede emner uden for cunecos områ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. Side 13 af 16

Interessenter og målgrupper: Bygherrer, rådgivere og udførende Situationsbeskrivelse: 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. I relation til udbud-/tilbudsfasen efterspørges ligeledes en standard for digitale tilbudslister. Dette emne ligger i udkanten af cunecos indsatsområde inden for opmålingsregler, men behandles alligevel her som et selvstændigt punkt: 8. Standard for digitale tilbudslister Formål: Der bør udvikles en standardiseret tilbudsliste med mængder (IDM), som kan danne grundlag for gennemførelse af digitalt udbud. Tilbudslisten skal have specificeret sin form, format og indhold, så den kan bruges som grundlag for tilpasning af eksisterende kalkulations- og udbudssystemer. Standardiserede tilbudslister vil være en stor fordel, så fx de samme krav til tekniske anlæg ikke står forskellige steder i tilbuddene. o En standard vil skulle gøres specifik i forhold til specifikke udbudsformer eller man skal gøre det klart, præcist hvilket udbud standarden handler om (jf. kommentar ovenfor om at der findes forskellige niveauer af udbud). o Der findes en engelsk tilbudsliste, man kunne hente inspiration fra. Alle data omkring tilbudslister skal kunne genanvendes både i forhold til højdigitale og lavdigitale værktøjer. 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. Indhold hvilke elementer skal der arbejdes med? Hvordan sikres også juridisk, hvis det er et problem at digitale tilbudslister kan være i genanvendeligt format: excel eller lignende åbent format Side 14 af 16

frem for pdf-filer. Det ville være mere hensigtsmæssigt, hvis de udførende modtog et standardiseret tilbudsmateriale, som var baseret på redigerbare data og indeholdt mængder, og som skulle afleveres igen ud fra en digital standard. Hvordan kan data fra cad/bygningsmodel og tilbudslister genbruges i produktionen, og stiller det krav til angivelse af produkternes lokalisering og cad-modellens strukturering? 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. Det skal afklares, om der kan laves en (XML)standard via cuneco. Relaterede emner uden for cunecos område: 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. Side 15 af 16

9. Input til bips Behovsanalysen har ikke blot givet input til cunecos indsatsområder, men også til bips indsatsområder herunder bl.a. udvikling af beskrivelsesværktøjet i forhold til struktur og funktionsudbud og en opdatering af arbejdsmetode for bygningsmodellering. Inputtet til bips er beskrevet i procesmaterialet anvendt til behovsanalysens bølge 3 i dokumentet: Udpegede standarder præsenteret i bølge 3. Side 16 af 16

BILAG 2: PROCESMODELLER I dette bilag vises eksempler på procesmodeller, der illustrerer, hvordan standarder kan understøtte byggeriets dataudveksling inden for forskellige faser. Eksemplerne blev anvendt i behovsanalysens bølge 3. 17

18

BILAG 3: BRUGERSCENARIER cuneco har på baggrund af de i behovsanalysen udpegede behov udarbejdet otte brugerscenarier, som viser eksempler på, hvordan brugerne i en konkret situation kan tænkes at arbejde med cunecos kommende standarder og produkter. Der kan laves mange forskellige brugerscenarier, og formålet med de otte scenarier er på ingen måde at give et fuldt og endegyldigt billede af, hvordan cunecos produkter vil kunne bruges men blot udvalgte eksempler, som kan konkretisere de meget abstrakte produkter og gøre det nærværende for kommende brugere, hvordan cunecos produkter vil kunne bruges og skabe værdi i hverdagssituationer. For at gøre scenarierne så konkrete som muligt er der anvendt traditionelle aktørbetegnelser (såsom entreprenør og bygherrerådgiver ), men de beskrevne processer skal forstås generisk og kan udføres af mange forskellige aktører, afhængigt af det enkelte projekts organisering. Det er udarbejdet følgende brugerscenarier: 1. Bygherrerådgiver udarbejder rum- og arealprogram for konkurrenceprojekt 2. Bygherrerådgiver verificerer krav vedr. arealer og økonomi i konkurrenceprojekt 3. Rådgiver laver mængdesat tilbudsliste til digitalt udbud 4. Rådgiver laver udtræk til bygherren til verifikation af opfyldelse af krav 5. Entreprenør modtager digitalt udbudsmateriale som grundlag for tilbud 6. Entreprenør opretter produktionsgrundlag ud fra kalkulation 7. Driftsherre modtager digitalt materiale som grundlag for drift 8. Driftsherre registrerer driftsinformation som grundlag for programmering De otte scenarier er gengivet nedenfor. 19

20

21

22

23