behovsanalyse bilag - Bips

ehovsanalyse
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

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