Referat af fokusgruppemøde om programmeringsfasen 13.10. 2011 cuneco en del af bips Dato 24. 10. 2011 Projektnr. Sign. MET 1. Baggrund cuneco vil i en behovsanalyse afdække byggebranchens behov som udgangspunkt for arbejdet med at udvikle standarder for digital udveksling af information. Behovsanalysen består af følgende elementer: Workshops for de enkelte aktører: Byg- og driftsherrer, arkitekter, rådgivende ingeniører, udførende og byggematerialeproducenter. To fokusgrupper på tværs af aktører inden for faserne: programmering, projektering, udførsel og drift & vedligehold. Dette dokument beskriver det første fokusgruppemøde om programmeringsfasen, som blev afholdt den 13.10. 2011 hos cuneco. Mødet havde følgende deltagere: Marianne Kaae Nielsen, Universitets- og Bygningsstyrelsen Peter Birk Hansen, Universitets- og Bygningsstyrelsen Stine Tarhan, Gentofte Ejendomme Ann-Marie Jensen, Gentofte Ejendomme Mette Stokholm, Region Hovedstaden Gert Munksgaard Thorsøe, Emcon David Fink, Schmidt hammer lassen architects Leif Kaare Jensen, Rambøll Christine Kalhauge, COWI Torben Klitgaard, cuneco (facilitator) Gunnar Friborg, bips (facilitator) Lars Hvam, DTU Management (oplægsholder) Mette Øbro, cuneco (referent) Anette Prindahl (procesmodel-referent) Mødet havde følgende dagsorden: 1. Diskussion af case v. Lars Hvam 2. Behovsidentifikation: Hvad er fasens største udfordringer vedr. udveksling og genbrug af data? v. Torben Klitgaard 3. Gennemgang af de enkelte udfordringer v. Gunnar Friborg 4. Opsamling og prioritering v. Torben Klitgaard cuneco står for fællesskab. Vi udvikler det fælles grundlag for digitaliseret samarbejde i byggeri, anlæg og drift. Målet er øget effektivitet og produktivitet gennem bedre udveksling af informationer. www.cuneco.dk Side 1 af 11
Nedenfor refereres mødets diskussioner. Bemærk, at referatet ikke angiver en samlet konklusion om de enkelte punkter, men deltagernes individuelle kommentarer, som kan være modstridende grundet deltagernes forskellige synspunkter og interesser. 2. Diskussion af case Lars Hvam fremlagde en case, som ud fra en aktuel byggesag illustrerer, hvor der kan opstå problemer i forhold til udveksling og genbrug af data i programmeringsfasen, og hvordan en standard kan gøre en forskel. Casen omhandlede et sygehusbyggeri og havde fokus på rumprogrammer (casen er nøjere beskrevet på http://cuneco.dk/behovsanalyse). I casen opstår der problemer bl.a. omkring brugen af begreber, som varierer hos forskellige aktørgrupper, hvilket skaber uklarhed og basis for misforståelser. Der anvendes forskellige klassifikationer af klynger og rum; der beregnes kvadratmeter efter forskellige principper, og egenskaber for rum beskrives på individuelle måder. Effekten af dette er uklarhed og mange tilbageløb i processerne, ligesom det kan være svært for bygherrerne at sammenligne de indkomne projektforslag. Iflg. Lars Hvam vil problemerne kunne afhjælpes via en standard for benævnelser af klynger, rum og kvadratmeter, en rumklassifikation og en standard for rumegenskaber og for beregning af kvadratmeter. Herudover foreslog Lars Hvam en standard tjekliste for, hvad der skal specificeres i programudbuddet i f.t. udbudsformen, så udbudsmaterialet er komplet. Deltagerne kunne overordnet genkende problematikken, men havde følgende kommentarer til casen: De store offentlige bygherrer har behov for nøgletal/bygningsindikatorer vedr. bl.a. arealforbrug og brutto-netto-faktor, så man på et reelt grundlag kan sammenligne de enkelte bygninger. Der efterspørges i denne forbindelse en standard og et måleinstrument, som kan anvendes på tværs af bygningstyper: Alle taler om kvadratmeter og brutto-netto-faktor, og alle definerer det forskelligt o Fx har Universitets- og Bygningsstyrelsen selv udviklet en arealtjekker, som kan tjekke antal rum og kvadratmeter i et afleveret projektforslag. Bygherrer med heterogene bygningsporteføljer har ikke behov for at kategorisere ned på bygningstyper og fx lave rumdefinitioner Det vil være at skyde gråspurve med kanoner. Men der er brug for et redskab til at strukturere de informationer, som bygherren skal give til sin rådgiver. Der mangler i eksemplet fokus på slutbrugerne og deres behov til bygningen. Side 2 af 11
Lavenergi er et andet fokusområde, hvor bygherrerne har behov for at afklare, om kravene er opfyldt i et givet projektforslag: Hvis vi skal kunne sammenligne projekter, kræver det en standardiseret opfattelse af, hvad er et rum, hvordan laver vi energiberegninger, og hvor specifikke skal de være? Selvom man gerne vil angive et helt overordnet tal, man sidder i konkurrencesituation og er i tvivl om projekterne, så er man ofte nødt til at gå længere ned i de enkelte projekter, end man havde regnet med Der er behov for mere ensartede opfattelser af, hvad et rumprogram skal indeholde i en given fase man skal blive enige om, hvilket filter man skal se egenskaberne igennem. Det bliver en stor udfordring at kunne sammenligne nye bygninger med den eksisterende bygningsmasse, da denne har en anden arealopgørelse. Standarder kan opleves som en spændetrøje de må ikke hindre rådgiverne i at tænke innovativt og fx tegne rum med multiple funktioner: Vi vil også gerne udfordre standarderne og tænke i processer mere end i bokse. At definere et fællesprog (dvs. standarder) er dog nødvendigt, det handler om hvilket niveau, de skal ligge på. Det vil blive dyrt at vedligeholde standarder for fx rumdefinitioner, da behovene ændrer sig over tid, bl.a. pba den teknologiske udvikling: Jeg er bange for en rigid standardisering, som koster en masse at vedligeholde, men reelt ikke tilfører værdi Klynge er ikke et standardbegreb for alle danske hospitaler (og benævner desuden en klinisk grundstruktur frem for en bygningsstruktur). Det er muligt at sammenligne danske hospitalsbyggerier på et tilstrækkelig godt grundlag med de eksisterende standarder og værktøjer. Der er et indlysende behov for at lave standarder omkring areal: Jeg oplever hele tiden forskellige opfattelser af, hvad en kvadratmeter er. Det er tankevækkende, at man stadig kan tale om, at vi er usikre på, hvad en kvadratmeter indeholder brutto og netto. En standard her ville give mening den er universel og kan også bruges i morgen Det er i programmeringsfasen for store byggeprojekter svært for bygherrer at overskue, hvilke konsekvenser deres valg og ændringer får. De har derfor behov for et konsekvensværktøj, der kan vise konsekvenserne af en given beslutning, fx i forhold til totaløkonomi, energi og arealforbrug. En standard kan give et fælles sprog mellem de projekterende og bygherren, så de projekterende bedre forstår, hvad bygherren mener med sine programmerings-informationer: Alle projekter kommer med forskellige informationer, hvor vi som projekterende skal grave ned og Side 3 af 11
finde ud af, præcis hvad de betyder. Fx indebærer hvert projekt udviklingen af et rumprogram med information på forskellige måder og i forskellige formater. Et fælles sprog i form af en standard vil give os et meget bedre grundlag, så vi kan bruge mere tid på at udvikle projektet end på at oversætte projektet 3. Behovsidentifikation Cuneco har i de forudgående workshops afdækket følgende primære behov i programmeringsfasen: 1. Informationsniveauer til udførelse af beregninger i de tidlige faser - fx arealer, energi og totaløkonomi 2. Indarbejdelse af bygningsdriftens behov i programmeringsfasen 3. Grundlag for struktureret arbejde med rumprogrammer Deltagerne var overordnet enige i disse behov med følgende supplerende bemærkninger: Der er klart behov for en standard eller et værktøj til, hvordan man i en tidlig fase kan få indarbejdet bygningsdriftens behov. Bygningsdriftens behov handler ikke kun om materialer og levetid, men også om hvordan arbejdsmiljøet fungerer for de primære brugere og for dem, der skal drifte bygningen. Arbejdsmiljø skal således også indarbejdes i programmeringsfasen. Anlægsøkonomi hører også med under punkt 1. Man skal arbejde med funktioner, før man arbejder med rumprogrammer. Funktioner er på det mere overordnede niveau, man bevæger sig på i programmeringsfasen, hvor det handler om at klarlægge de ønskede funktioner og herfra bevæge sig ned på rum og kvadratmeter. Programmeringsfasen bør være knyttet sammen med analyse af de erfaringer, bygherren har fra sine øvrige bygninger fx om kvadratmeterforbruget og driftsudgifter i bestemte enheder. Analyser kræver imidlertid en fælles, entydig sprogbrug. Der er behov for et fælles sprog/en standard for visualiseringer, så bygherren og de projekterende får samme opfattelse af, hvad der ligger i en visualisering, og hvilken grad af information, den indeholder. Efterfølgende blev de tre områder diskuteret enkeltvis ud fra punkterne: beskrivelse af problemet, årsager til problemet og hvilke typer standarder, der kan afhjælpe problemet. Diskussionen er gengivet i næste afsnit. Side 4 af 11
4. Gennemgang af de enkelte udfordringer 4.1. Informationsniveauer til udførelse af beregninger i de tidlige faser - fx arealer, energi og totaløkonomi Beskrivelse af problemet: Bygherren og hans rådgivere arbejder med at få styr på arealer, energi og økonomi i de tidlige faser af byggeriet vha. analyser og beregninger. Det er et problem at få et ensartet materiale at regne ud fra. Typisk løses det vha. individuelle løsninger. Areal er en vigtig faktor i programmeringsfasen, bl.a. fordi hele energirammen er baseret på arealer. For bygherren er det vigtigt at kunne formidle kvadratmeterpriser på sine bygninger. Bygherren ønsker bl.a. ved arkitektkonkurrencer at få overblik over sammenhængen mellem økonomien og areal pba. et meget heterogent materiale: Jeg kan blive usikker på kroner og på kvadratmeter, og hvis vi har forskellige opfattelser af disse ting, kan meget gå galt og det gør det også At der ikke er en standardiseret opfattelse af arealer, giver problemer fx i projektkonkurrencer, hvor deltagerne på basis af bygherrens udmeldte nøgletal om priser og kvadratmeter under- eller overperformer, hvilket gør det svært for bygherren at ligebehandle deltagerne: Vi vil som offentlig bygherre gerne sikre os, at vi taler om det samme; at vi får det, vi beder om; og at vi kan gennemskue det, vi får. Der efterspørges derfor en ramme, som projekterne kan tjekkes i forhold til og sammenlignes ud fra (som fx den tidligere nævnte arealtjekker). Andre bygherrer ønsker derimod ikke at stille skarpe, detaljerede krav i en konkurrencesituation, men derimod at få et kreativt bud på, hvordan deres ønsker til funktioner kan løses. Her kan det være svært at arbejde inden for standarder om fx bestemte typer af rum. Fra arkitektsiden oplever man at blive stillet over for meget forskelligartede rumprogrammer. Samlet set opleves der behov for større ensartethed, uden der dog er stemning for en større standardisering af udbudsmaterialet. Der er behov for at brugbare nøgletal, beregnet ud fra samme grundlag, så man reelt kan anvende erfaringer fra andre byggerier: Hvis man fx skal bygge noget, man aldrig har prøvet at bygge før, er man nødt til at basere sig på erfaringer fra andre projekter, men det er farligt at basere sig på nøgletal, som man ikke ved, hvad er fastsat ud fra (hvor man fx har glemt, Side 5 af 11
at prisen var ekskl. grundkøb). Der er m.a.o. behov for et ensartet grundlag. o Bygherrerne kunne selv blive bedre til at indsamle og analysere driftsdata fra eksisterende bygninger, gerne i 3Dmodeller, så det kan indgå i programmeringen af nye bygninger og renoveringer. Bygherren beder ofte om beregninger og simuleringer på et overordnet niveau allerede i programmeringsfasen, enten til rådgiverne eller til bygherrerådgiverne, afhængigt af udbudsformen og af, hvor meget man selv ved i forvejen. Fx stilles der krav til energi og indeklimaparametre. Totaløkonomi er en faktor, som er meget oppe i tiden, men som kan være svær at fastlægge på et tidligt tidspunkt i processen, hvor der er stor usikkerhed. Der findes et Lead-certificeringssystem og en tysk bæredygtighedsstandard, der definerer forskellige niveauer, som bygherren kan vælge, at bygningen skal leve op til. Herved sættes en overligger, som flere forskellige løsninger kan tilgodese. Årsager til problemet: Der er uklarhed om arealkategorier og om sammenhængen til større enheder, og hvordan man kan håndtere hybride rum. Der mangler enighed om målemetoderne og standarder for, hvordan man måler: Alle snakker om brutto-netto-faktor, men ingen ved rigtigt, hvad de lægger i den Byggeriets parter skal lære at arbejde med usikkerhed, hvilket er uomgængeligt på programmeringsniveau, hvor der er en arkitektonisk intention, som ikke er præciseret: Man kan ikke få eksakt videnskab på programmeringsniveauet Hvilken type standarder kan afhjælpe problemet? En standard for, hvordan man som bygherre beskriver tingene på bestemte niveauer i bestemte faser, vil gøre det nemmere for bygherren at afklare sin egen beslutningsproces og det materiale, bygherren leverer videre til de andre aktører, vil ligne noget, de har set før. Standarden skal dog ikke være detaljeret, fx i forhold til hvordan klynger defineres. Det vil give en stor entydighed i konkurrencer, hvis projektforslagene efterprøves efter en standard, som alle kender. Bygherren kan være mere sikker på at få det, han er blevet lovet, og vil generelt kunne opnå en bedre økonomi. Side 6 af 11
Der skal være en standard for grænsefladen, hvor der udveksles 3Dmodeller, så det fx bliver muligt for bygherre/bygherrerådgiver at lave en beregning på modellerne. Det er godt at definere en overligger uden at definere løsningerne. Man kan fx definere overliggere i forhold til energiklasse, som kan løses med fx mindre glas eller mere isolering (à la Lead-certificering). Der skal være en standard og måleregler for alt det almindelige i en bygning og så må man leve med en restmængde, som ikke er standardiseret. 4.2. Indarbejdelse af bygningsdriftens behov i programmeringsfasen Beskrivelse af problemet: Der er for lav kobling mellem drift og byggeri. Driftens erfaringer og behov indarbejdes ikke i tilstrækkelig grad i byggeriet, hvorved bygningen kan blive uhensigtsmæssigt indrettet og dyrere i drift end nødvendigt. Årsager til problemet: Organisering ofte ligger byggeafdelingen og driftsafdelingen forskellige steder i organisationen og har ikke nok kontakt med hinanden. Driften bliver ikke inddraget på det rette tidspunkt. o Driftens behov og erfaringer skal tænkes ind på et meget tidligt tidspunkt, før beslutningerne danner sig et andet i organisationen, dvs. byggeafdelingen bør have en løbende dialog med driften. Driftsfolkene ved ikke, hvilke oplysninger der er brug for i de forskellige faser. Bygge- og driftsafdelingerne har forskellig kultur og faglighed. Der mangler tradition for at inddrage driftsprincipper i programmeringen. Det handler ikke om tidligt at inddrage driften på det operationelle niveau, men på det strategiske niveau i forhold til, hvordan man vil drifte bygningen fx om man vil udbyde nogle af servicefunktionerne, hvilket måske skal indtænkes i bygningens udformning og informationsflow. At indsamle driftsinformation er imidlertid i sig selv en udfordring: Hvis bygningerne lejes ud med drifts- og vedligeholdelsesansvar for lejerne, har bygherren ikke adgang til alle relevante data fra driften. Side 7 af 11
Det er en kæmpe opgave for en kommune at indsamle driftsdata over en længere årrække, idet driftsomkostninger er delt op på mange forskellige underposter, der er relateret til forskellige fagforvaltninger, som over tid er blevet fusioneret eller adskilt. Hvilken type standarder kan afhjælpe problemet? Tjeklister til bygherren om, hvornår i processen og på hvilke niveauer man skal inddrage driften. Man skulle se på bygningstyper og lave en typificering på 10-15 forskellige bygningstyper, der baseret på prisen for byggeriet og opmåling af driftsudgifterne genererer erfaringsnøgletal og kan fungere som referencebyggerier, som alle store bygherrer kan benytte sig af. Det skal være referencedata på et meget overordnet niveau En standard skal medtænke, at den almene sektor skal indberette mange tal til staten, som skal struktureres på en helt anden måde end normalt, hvilket er en belastning: Man skal passe på, at man ikke får foreslået noget, som bliver en byrde for folk, og som man ikke kan trække data ud af En standard for digital aflevering i forhold til, hvilke data driftsherrerne har brug for. o I de tilfælde, hvor byg- og driftsherren ikke er den samme, skal det være en standard, som sikrer, at der kommer driftsdata ind, som den efterfølgende driftsherre kan bruge. Mange bygherrer drifter ikke selv, men udlejer, administrerer og forvalter bygninger. Dette skal kommende standarder tage højde for, hvis gevinsten skal være stor. 4.3. Grundlag for struktureret arbejde med rumprogrammer Beskrivelse af problemet: Det er besværligt at arbejde med rumprogrammer. Der er ikke entydighed omkring begreberne, og egenskaber beskrives individuelt. Rumprogrammet kan betragtes som udmøntningen af den strategiske overvejelse: Hvad skal vi lave i denne bygning og hvordan. Rum kan have en overordnet funktion, men også bruges multifunktionelt. Mange rum kan beskrives entydigt i arealkategorier og anvendelseskategorier, mens andre rum falder uden for. Rumprogrammer er et kommunikationsværktøj, som gerne skal være essensen af bygherrens ønsker, og som kan anvendes over for både byggefolk og slutbrugerne. I forbindelse med brugerinddragelse er det vigtigt, at der er en rød tråd tilbage til visionen, så det af rumprogrammet Side 8 af 11
fremgår, hvorfor man er havnet på netop dette areal med disse egenskaber. (Rumprogrammet kan dog typisk ikke stå alene, men skal suppleres med andre skitser og forklaringer). Fx fungerer rumprogrammet for et nyt hospital som en portal, som slutbrugerne gives adgang til. Rumprogrammer er for snævert et begreb, idet bygherren som udgangspunkt beskriver funktioner, der skal have nærhed til hinanden, uden at forholde sig til, hvad rummet hedder. Termen nærhedsgrad anvendes i forbindelse med rumprogrammer, men ikke klynger. Rumprogrammer skal kunne bruges efterfølgende i projekteringen; bare mere detaljeret, hvis de skal være en gevinst. De kan fx bruges som et levende dokument, hvor der tilføjes information i de forskellige faser, indtil der til sidst er en klar historie om hele projektet. o Nogle rådgivere arbejder i denne forbindelse med to parallelle spor, hvor der løbende trækkes informationer ud af BIM-modellen til rumdatabasen og omvendt. Årsager til problemet: Udfordringen vedr. rumprogrammer er mere selve arbejdsprocessen end manglende standarder: Bygherrer ved ofte ikke præcis, hvad de vil have og kan derfor heller ikke definere det præcist til arkitekterne. Samtidig ønsker bygherren netop at blive inspireret af arkitektkonkurrencen og få ideer til, hvordan man kan gøre tingene anderledes, hvilket kan påvirke den ønskede funktionalitet, der ender med at blive til et rumprogram. Dvs. der er en indbygget dynamik i arbejdsprocessen, som ikke har med standarder at gøre. Det er en udfordring for rådgiverne at vedligeholde, at rumskemaet hænger sammen med projektet, efterhånden som projektet udfolder sig og får flere og flere data føjet til: Man har et rumprogram, som kommer ned i rumskemaer for hvert enkelt rum, og som definerer udfaldskrav, der bringes over i projekteringsfasen. Alle disse data, hvordan man får dem videre? På et eller andet tidspunkt dør rumskemaerne i sig selv Det er en kæmpe opgave at vedligeholde rumskemaer og giver det nogen værdi, kan man ofte diskutere? Den måde at håndtere data på kunne være lidt mere smidig: fra rumprogram til rumskema til selve projekteringen, og at trække data ud på tværs Hvilken type standarder kan afhjælpe problemet? For de bygherrer, som er relativt afklarede med deres ønsker, vil det være en fordel, hvis der kobles flere informationer til rumprogrammet, så det er muligt at lave en tidlig prissætning. Der ønskes i denne forbindelse en Side 9 af 11
fælles standard for hvilke informationskrav, der skal stilles til rumprogrammet i de enkelte faser. Nogle af deltagerne har positive erfaringer med eksisterende kommunikationsværktøjer, som giver et godt overblik over projektet i de tidlige faser og gør det muligt fx at vise alle rum med luftskifte over 20 gange i timen. Det er dog op til brugerne selv at definere fx rumegenskaber. Der er i denne forbindelse en pointe i at lave en standard at definere datasæt for de typiske elementer af et byggeri. o Der kan tænkes ud fra en model, hvor nogle elementer er fælles og kan standardiseres, mens andre er individuelle for de enkelte byggerier. Det kan dog være svært at afgøre præcis, hvad der er fælles, og hvor detaljeret et niveau der skal standardiseres på. Man kan evt. lave standarder for forskellige bygningstyper og forskellige bygherrer. Desuden skal det indtænkes, at der gerne skal kunne bygges videre på materialet i projekteringsfasen. De statslige og regionale bygherrer har mange standarddefinitioner på rum allerede, som skal tænkes ind i forhold til evt. yderligere standarder, så nye standarder ikke blot bliver til besvær. Side 10 af 11
5. Prioritering af behov Afslutningsvist prioriterede deltagerne de diskuterede behov i forhold til, hvor vigtige de er for branchen at få løst. Deltagerne fik hver især 10 points, som de kunne fordele på emnerne. Tabellen viser den samlede pointfordeling. Område Kommentarer Points Informationsniveauer Informationsniveauer er der, hvor man tit er ude at 34 til udførelse af svømme (+) beregninger i de tidlige faser Arealer er meget relevante. Der skal være en standard for arealer (+) Der skal være en standard for totaløkonomiske beregninger, udarbejdet af forskere og byggevareproducenter (+) Det handler om at sætte overliggeren og definere de overordnede udfaldskrav. Man skal kunne se konsekvenserne af de ændringer, man foretager sig undervejs i processen. Grundlag for Det er fint at have en fælles måde at gøre det på, som 19 struktureret arbejde med rumprogrammer er nem at for aktørerne at sætte sig ind i, fordi de har set den før. Men der skal ikke være en masse forskellige kategorier (+/-) Bygherrerne løser selv rumprograms-problematikken ved hjælp fra rådgivere og softwareleverandører (-) Der findes allerede de standarder og den softwarehjælp, man har behov for (-) Der findes ikke tilstrækkelige standarder for rumprogrammer i forhold til den fortsatte projektering (+) Det skal gøres nemmere at bevæge sig mellem rumprogram og BIM-model (+) Indarbejdelse af At få indarbejdet driften er utrolig vigtigt, men skal 13 bygningsdriftens gøres vha. organisering og ikke standardisering (-) behov i programmeringsfasen Det handler om processer en standard på området vil ikke give værdi (-) Fin kobling til OPP-problematikken (+) Dansk Facility Management har lavet nogle retningslinjer, cuneco kan lade sig inspirere af. *Udveksling af Der ligger en besparelse i forhold til fx efterberegning 3 modeller og simulering, hvis man er enige om modellen og de data, der kommes ind (+) *Visualisering Det er i øjeblikket meget op til de bydendes egen fortolkning, hvad der ligger i at visualisere. Det vil være en fordel at få en ensartning på området, så der stilles de samme krav til de bydende, og parterne forstår det samme ved det (+) 1 *: Dette emne supplerede en enkelt deltager prioriteringsøvelsen med. Side 11 af 11