BIM: Behov for kontraktsreguleringer og generell standardisering

Vedlegg 1: Rasjonell prosjekteringsprosess (eksempel fra konkret prosjekt - detaljprosjektering og arbeidsunderlag for bygging i utførelsesentreprise)

Vedlegg 2: Vilkårene på ArchiCAD som leveres av Graphisoft Vedlegg 3: Skybasert lagring av bygningsinformasjonsmodeller

Forkortelser og begreper brukt i rapporten

Forkortelse/begrep	Definisjon/beskrivelse
AIM	Asset Information Model Informasjonsmodell for byggverk informasjonsmodell forbindelse med driftsfasen.
API	Application Programming Interface Et programvaregrensesnitt som lar to programvarer snakke med hverandre.
ArchiCAD	Spesifikk modelleringsprogramvare primært for arkitektfaget
BCF	BIM Collaboration Format (BCF) Et strukturert filformat som er egnet til å utstede sporing med en bygningsinformasjonsmodell. BCF er primært designet for å definere visninger av en bygningsmodell og tilhørende informasjon om kollisjoner og feil knyttet til bestemte objekter i visningen.
BEP	BIM Execution Plan Dokument som angir nærmere de viktige stegene i prosjektering, utførelse og vedlikehold i et prosjekt, og som identifiserer hovedoppgaver og ressurser.
BIM	Building Information Modelling Bygningsinformasjonsmodellering Bruk av en delt digital framstilling av et byggverk for å legge til rette for prosjektering, bygging og driftsprosesser slik at det kan dannes et pålitelig grunnlag for beslutninger.
BIM Collab Cloud	Spesifikk programvare for samhandling med BIM direkte mellom modellerings- og kvalitetssikringsprogramvarene. Bruker på de åpne IFC- og BCF-standardene.
BIM-modell	En delt digital framstilling av et byggverk. Det skilles mellom om modellene brukes i prosjektfasen (PIM) eller i driftsfasen (AIM).
BIM-objekt	Modellobjekt som inngår i modell. BIM-objekter er digitale representasjoner av prosjektets fysiske objekter (f.eks. tunnel, fundament, vegg, vindu, ventil osv.)
CDE	Common Data Environment Avtalt kilde til informasjon for et gitt prosjekt eller byggverk, for å samle inn, forvalte og fordele hver informasjonskonteiner gjennom en styrt prosess. En CDE- arbeidsflyt beskriver prosessene som skal brukes, og en CDE-løsning kan tilby teknologien for å støtte disse prosessene.
DWG	Proprietært filformat. I rapporten brukt generelt for tegninger
GDPR	General Data Protection Regulation EUs forordning (regelverk) for personvern og en del av personopplysningsloven.
ICE	Integrated Concurrent Engineering. Samtidig prosjektering er en arbeidsmetodikk som har som mål å bidra til at prosjekter gjennomføres effektivt og smidigere enn tradisjonelt. Arbeidsmetodikken fremmer tverrfaglig samarbeid og gode beslutninger i et prosjekt.
IFC	Industry Foundation Classes, NS-EN ISO 16739

	IFC-standarden spesifiserer et konseptuelt dataskjema og et utvekslingsfilformat for BIM-modeller. IFC kan utveksles på blant annet STEP format og ifcXML.
IFC Rail	Versjon av IFC-standarden med en påbygning som støtter klassifikasjon og utveksling av elementer for jernbane.
IFC Road	Versjon av IFC-standarden med en påbygning som støtter klassifikasjon og utveksling av elementer for veg.
Informasjonskonteiner	Navngitt varig sett av informasjon som kan gjenfinnes fra en fil, et system eller hierarki av lagrete data.
LoX	Level of Informasjon Beskrivelse av konkret, krevd modenhetssnivå på modellinformasjon. X’et viser til at det finnes flere ulike definisjoner. En av de mest brukte er Level of Development (LOD).
MMI	Modell Modenhets Indeks (eng. Model Maturity Index) Prosesstatsukode som angir hvor modent et BIM-objekt er i beslutnings- og kvalitetssikringsprosessene.
PIM	Project Information Model Prosjektinformasjonsmodell Informasjonsmodell i forbindelse med prosjektfasen.
Post	Med post i dette dokumentet menes prisbærende poster i en teknisk beskrivelse i en utførelseskontrakt. I Norge brukes primært to beskrivelsessystemer, NS 3420 (primært bygg) og SVV Prosesskoden (primært anlegg). Med post i dette dokumentet menes post eller prosess, avhengig av hvilket beskrivelsessystem som brukes i det aktuelle prosjektet.
Proarc	Spesifikk dokumenthåndteringsprogramvare
Punktsky	Samling av koordinatpunkter fra et fysisk objekt
Revit	Spesifikke modelleringsprogramvarer for arkitektfaget, bygningsingeniørfaget og tekniske ingeniørfag.
Tekla	Spesifikk modelleringsprogramvare for bygningsingeniørfaget.
TIDP	Task Information Delivery Plan Tidsplan for informasjonskonteinere med leveringsdatoer for en bestemt arbeidsgruppe.
VDI	Virtual Desktop Infrastructure En virtualiseringsteknologi for datamaskiner der et stasjonært operativsystem (OS) kjører og administreres i et lokalt eller skybasert datasenter. Det virtuelle skrivebordsbildet på datamaskinen leveres over et nettverk til en sluttpunktsenhet, som lar brukeren samhandle med operativsystemet og dets apper som om det kjører lokalt.

1 Innledning

1.1 Formål, innhold og struktur

1.1.1 Formål

Formålet med denne rapporten er å gi en oversikt over forhold ved bygningsinformasjonsmodellering – og særlig BIM – som tilsier regulering i kontraktsvilkår eller vedlegg, eller standardiseringsarbeid uten direkte tilknytning til kontraktsstandarder. Rapporten er ment å gi en faktisk bakgrunn for de vurderinger og valg som må gjøres i slike sammenhenger, men den gir ingen anbefalinger om disse valgene.

Regulering av BIM-relaterte forhold i kontraktsstandarder er først aktuelt i komite SN/K 378 Totalentreprisekontrakter ved store prosjekter og deretter i senere nye eller reviderte kontraktsstandarder.

1.1.2 Innhold og struktur

Rapporten redegjør innledningsvis for komiteens mandat (1.2), komiteens sammensetning (1.3) og komiteens arbeid (1.4). I 1.5 gis det en introduksjon til bygningsinformasjonsmodellering, med hovedvekt på BIM, mens 1.6 peker på konsekvenser ved bruk av BIM i konkurransefasen.

Punkt 2-5 behandler temaer som skaper behov for regulering eller standardisering tilknyttet BIM, i eller uten tilknytning til Standard Norges kontraktsstandarder.

Komiteen har ikke gjort noen forutsetninger mht. hvilken kontraktsstandard den BIM-relaterte reguleringen skal inkorporeres i. Drøftelsene av reguleringsbehovene har bare hatt BIM for øye. De enkelte kontraktskomiteene må vurdere hvilken betydning særpregene ved «deres» standard har for i hvilken grad, og evt. hvordan, BIM-relatert regulering bør gjennomføres.

Punk 6 inneholder en sammenfatning av de punkter komiteen mener bør vurderes regulert i standardiserte kontraktsvilkår (i motsetning til i kontraktsvedleggene).

Komiteen har underveis identifisert en del forhold komiteen mener kan være egnede temaer for annet standardiseringsarbeid, uten konkret tilknytning til kontraktsstandardene. Dette påpekes underveis i rapporten. En samlet oversikt over slike temaer er gitt i punkt 7.

Rapporten har tre vedlegg. Vedlegg 1 beskriver en rasjonell prosjekteringsprosess basert på BIM. Vedlegg 2 inneholder eksempler på lisensvilkår for programmer. Vedlegg 3 er et notat utarbeidet av RIFs BIM-ekspertgruppe om skybasert lagring av bygningsinformasjonsmodeller.

Rapporten skiller ikke gjennomgående mellom bygg og anlegg, men behovene og utfordringene knyttet til BIM kan være forskjellige i de to sektorene. Dette påpekes i rapporten, og det gis synspunkter på mulige nyanseringer i reguleringsbehov og -alternativer. For øvrig bør «kontraktskomiteene» som bruker rapporten selv vurdere i hvilken grad det bør nyanseres.

Komiteens forslag kan føre til tre typer tiltak:

(1) Endring av vilkårene i etablerte eller nye standardkontrakter

(2) Regulering i kontraktsvedlegg (typisk ytelsesbeskrivelser og prosesser), vanligvis uten at dette innebærer noen standardisering fordi hver individuelle kontrakt har sine særlige behov

(3) Standardisering av ytelser og prosesser tilknyttet BIM

For å gi en enkel oversikt er disse tre alternativene anmerket på aktuelle punkter i rapporten ved bruk av en eller flere av disse rutene:

Hvorvidt det etter komiteens mening haster å gjennomføre tiltakene, er tilsvarende angitt ved et rødt, gult og grønt felt i hver av rutene, der rødt betyr høyest prioritet. De tiltak som ikke er aktuelle er grået ut. Eks:

Det er ikke angitt noen prioritet på alternativet «Vedlegg», siden vedleggene uansett må fastlegges av partene ved den individuelle kontraktsinngåelsen. Rapporten identifiserer likevel temaer som bør behandles i vedlegg. Dette er en påminnelse til partene om hva deres kontrakt bør ta hensyn til, og det gir samtidig et nyttig perspektiv ved utformingen av standardiserte kontraktsvilkår og generelle standarder for ytelser og prosesser.

1.1.3 Betydningen av kontraktsorganiseringen

BIM er et verktøy for å gjennomføre kontrakter om bygge- og anleggsprosjekter. Organiseringen av kontraktene i prosjektet styrer derfor hvilken rolle BIM får og hvilke krav det er aktuelt å stille til prosess og ytelse knyttet til BIM.

Det er særlig to typer variasjoner i kontraktsorganisering som her er viktige.

For det første er det i denne forbindelse en klar forskjell mellom utførelsesentreprise og totalentreprise, særlig fordi valget styrer rådgiverens posisjon i prosjektet. Dette setter preg på den nærmere utforming av BIM-relaterte krav og prosesser, bl.a. ved at BIM-relatert samvirke med og mellom øvrige aktører i prosjektet må ivaretas i separate kontraktsforhold.

For det andre må det skilles mellom de «klassiske» kontraktsformene mellom en bestiller og en leverandør (rådgiver, entreprenør) og de formene for samvirkekontrakter som bringer inn bestiller, rådgivere og undertiden flere entreprenører i et slags felles kontraktsforhold (enkeltheten kan variere mye). I samvirkekontrakter vil forholdet mellom (en rekke) utøvere kunne reguleres under ett, mens de klassiske toparts-kontraktene gjør det nødvendig å ivareta BIM-hensyn og -krav i selvstendige kontrakter. I begge tilfeller vil det være krevende å koordinere selvstendige aktører.

Komiteen går ikke nærmere inn på disse spørsmålene, men understreker at man må ha disse variablene for øye når man skal omsette komiteens anbefalinger til standardkontrakter eller annen standardisering. Perspektivet er selvfølgelig også viktig ved utforming av individuelt tilpassede vedlegg i individuelle kontrakter.

1.2 Mandat

Sektorstyret i Standard Norge nedsatte 18. september 2019 en komité med følgende mandat:

«Komiteen skal utarbeide en rapport som identifiserer og beskriver alle sider ved bruk av BIM og tilsvarende verktøy (heretter BIM) som etter komiteens mening skaper behov for regulering i en eller flere berørte standardkontrakter. Rapporten skal søke å identifisere ulike problemstillinger deltakerne i komiteen har møtt ved bruken av BIM, med særlig fokus på ansvars- og rettighetsspørsmål knyttet til bruken av denne typen prosjektstyringsverktøy.

Rapporten skal også beskrive sannsynlige hovedtrekk i fremtidig utvikling av BIM.

Formålet med rapporten er å gi et tilstrekkelig faktisk grunnlag for utforming av regler om de særlige ansvars- og rettighetsforhold som oppstår ved bruk av BIM. Det er derfor ikke

avgjørende at rapporten på alle punkter er enstemmig. Men identifikasjon og beskrivelser må være tilstrekkelig tydelige og strukturerte til at de komiteer som arbeider med revisjon av berørte standardkontrakter har et faktisk grunnlag for å utforme de nødvendige reguleringer.

Komiteen inviteres til å fremme forslag til hvilke reguleringsbehov som bør dekkes i kontraktsvilkår og hvilke som bør ivaretas i kontraktens ytelses- og prosessbeskrivelser. Dersom komiteen finner at det er grunnlag for det, kan den, innenfor fastlagt fremdrift, fremlegge forslag til elementer for ytelses- og prosessbeskrivelse i kontraktvedlegg.

Komiteen skal beskrive hvilke forhold knyttet til BIM som på nåværende tidspunkt anses modne for regulering. Komiteen kan her skille mellom reguleringsbehov som er påtrengende og de som kan vente. Komiteen skal ikke selv utforme forslag til regulering av forhold knyttet til BIM.

Komiteens arbeid skal koordineres med arbeidet til SN/K 378 Totalentreprisekontrakter ved store prosjekter som utarbeider en Norsk Standard for totalentreprisekontrakter ved store prosjekter.

For at resultatet fra komitearbeidet til SN/K 379 Digitale Samhandlingsformer skal kunne benyttes i arbeidet til SN/K 378 Totalentreprisekontrakter ved store prosjekter, bør arbeidet ferdigstilles innen 8 måneder, slik at arbeidet til SN/K 378 ikke blir forsinket. Det skal fastsettes en framdriftsplan i samsvar med mandatet og en møteplan for hele perioden (…)»

1.3 Komiteens sammensetning

Arbeidsgruppen består ved avgivelse av rapporten av følgende medlemmer/ deltakere:

Entreprenørforeningen – Bygg og Anlegg	Xxxx Xxxx Xxx Xxxxxxx Xxxxx Xxx Xxxxxxxx
Arkitektbedriftene i Norge	Xxxxxx Xxxx Xxxxxx Xxxxxxxxx Xxxxx
Rådgivende Ingeniørers Forening - RIF	Xxxxxx Xxxx Xxxxxx Xxxx Xxxxxxxx Xxxxxxx Xxxxxxxxx
OneCo AS	Xxxx Xxxxxxxx
NTI AS	Xxxxxx Xxxxxx
Focus Software AS	Xxxxxx Xxxx
Statsbygg	Xxxxx Xxxxxxx
Nye Veier AS	Xxx Xxxxxxx
Bane NOR	Xxxxxxx Xxxxxx
Boligprodusentenes Forening	Xxx Xxxxx

Komiteen har vært ledet av Xxxx Xxxxxx, Nordisk institutt for sjørett, UiO, med Xxxxx Xxxxx Xxxxxxxxxxx og Xxxxx Xxxxx Xxxxxxxx som prosjektledere.

Det er en samlet komité som står bak beskrivelsene og anbefalingene i rapporten.

1.4 Komiteens arbeid

Det er avholdt totalt 10 møter i komiteen.

Komiteens arbeid har siden mars 2020 vært utført under de restriksjoner som er innført i forbindelse med covid-19-pandemien. Møtene i denne perioden har vært holdt som Teams- møter. Komiteens erfaring er at dette har fungert brukbart, men ikke like effektivt som fysiske møter.

Selv om komiteen hadde flere fysiske møter før nedstengningen, og medlemmene derfor i noen grad kjente hverandre, ble diskusjonene i nettmøtene mindre effektive som følge av

fravær av «metainformasjon» (kroppsspråk, øyekontakt). Det er også vanskelig å få en effektiv diskusjon når lydsystemet ikke er duplex, men simplex, altså at flere personer ikke kan snakke samtidig eller i tett dialog. Dette kompliserer drøftelsene, selv om det selvsagt også kan ha en oppdragende funksjon. Og det er vanskeligere å styre diskusjonen effektivt med de midler man har i nettmøte til å registrere hvem som ønsker å bidra. For å gi effektive diskusjoner må Teams-møter gå litt langsommere og unnvære en del av den dynamikken fysiske møter kan gi.

1.5 Informasjonsmodellering; BIM

1.5.1 Bredden av informasjonsmodellering

Det finnes mange typer informasjonsmodellering for bygge- og anleggsbransjen. De har ulik utbredelse, egenskaper og fordeler og ulemper. Det er viktig å merke seg at særlig for anleggsprosjekter, men også for større byggeprosjekter, finnes modeller i ulike formater som eksempelvis fra kartsystemer (SOSI), ortofoto fra droner og fly, punktskyer og terrengdata. Dette er modeller som har egne bruksområder og egenskaper. I anleggssektoren er man ikke komme like langt med standardisering av formater som i byggsektoren, men det må forventes at det i fremtiden vil foreligge et omforent sett av åpne formater.

Det åpne formatet IFC, som tradisjonelt er brukt for byggverkstypen BYGNING, får nå etter hvert støtte for en rekke infrastrukturområder (IfcRoad, IfcRail, IfcTunnel, IfcBridge, IfcLandscape, IfcHarbour osv.), og det skjer også integrasjon modellmessig mellom bygnings-siden (BIM) og infrastruktursiden (GIS, med standarder som GML, applikasjoner av GML som CityGML, LandXML, LandInfra osv.).

Komiteen har funnet det hensiktsmessig å konsentrere seg om å formidle problemstillingene knyttet til bruken av modell på åpent format som er det mest utbredte, IFC (NS-EN ISO 16739) og proprietære formater som ligger til grunn for dette.

1.5.2 Introduksjon til BIM

BIM er et av de sentrale tiltakene i digitaliseringen av byggenæringen og vil være et nav i informasjonsutveksling i en digital framtid.

Tradisjonelt har byggeindustrien i stor grad benyttet tegninger for å formidle informasjon i byggeprosjekter. Tegningen er en tolkning av informasjon som ofte avledes fra modell men kan også vise mer informasjon enn det som ligger i modellen, f.eks. er en detaljtegning mer detaljert enn modellen ofte vil være. Sett fra et informasjonsperspektiv kan modeller være enklere å forstå og samhandle om. Dette fordi modellen viser byggverkets geometri tre-dimensjonalt og fordi man kan zoome og snu seg rundt i modellen. Det finnes også flere digitale verktøy for samhandling med modell både internt i fagene og mellom disse. Sammen med nye måter for samhandling mellom prosjektets aktører utveksles informasjon med BIM gjerne oftere og utviklingen skjer i parallell. Sett fra et avtalemessig perspektiv kan samhandling på tvers av fagene og utvikling i parallell med BIM gjøre det vanskeligere å vite hvilket grunnlag det skal jobbes på. Bruk av BIM krever derfor god struktur på samhandling og samhandlingsplattformer.

BIM-objekter representerer reelle fysiske byggevarer i et bygg. BIM-objektene beskriver geometri, egenskaper, relasjoner til andre objekter og lokasjon. Det er viktig at informasjonen er riktig, relevant og strukturert. Det er kvaliteten på informasjonen og struktur i BIM-modellen som avgjør hvor egnet den er for bruk i tidsbesparende digitale prosesser og automatisering av oppgaver.

En BIM-modell er satt sammen av digitale BIM-objekter som representerer reelle fysiske objekter eller rom i et byggverk. Å samle leveranser fra alle fag i en BIM-

modell gjør det for eksempel enklere å kommunisere mellom fag, mellom bestiller og brukere, å se hvordan løsninger påvirker andre fag og helheten og å finne avvik.

Prosjekteringen er den fasen hvor byggenæringen har mest erfaring og løsninger innen bruk av BIM. Bruk av BIM bidrar blant annet til at beslutningstakere forstår de foreslåtte løsningene bedre og kan velge det som passer best for kunden og som er byggbare innen tid, kost og kvalitet. Kvaliteten på BIM-modeller som lages i prosjekteringsfasen legger grunnlaget for hvilken nytte de har videre i drift og vedlikehold.

BIM brukes i økende grad av utførende og har stort potensial for å effektivisere og forbedre eksisterende prosesser i byggefasen. Eksempler på dagens bruksområder for BIM-modeller i byggefase er blant andre optimalisering av løsninger og sikring av byggbarhet, mengdeuttak for kalkyle og bestilling, styring av varelogistikk, planlegging og koordinering av bygging, SHA-simuleringer og kontroll av ferdig bygg mot prosjektering.

Bruk av BIM i forvaltning og drift er fortsatt i pilotstadiet, men er i stadig utvikling.

En mulighet for å bruke BIM i drift og forvaltning er at all dokumentasjon om bygget er koblet til BIM-modellen. Da kan man blant annet peke på et objekt i modellen og få frem informasjonen man trenger fra PC, nettbrett og mobil. Det forventes at man kan spare mye tid i drift ved å få enkel tilgang til all dokumentasjon.

Med oppdatert, digital informasjon om bygget åpner det seg flere andre muligheter, herunder å melde avvik direkte i modell fra telefon/nettbrett, bedre planlegging av vedlikeholdsarbeider, bedre oversikt og statistikk over utleide arealer, kobling av sensorer som måler situasjonen «live» i bygget og prediktivt vedlikehold.

Med tegningsbasert samhandling foregår informasjonsutvekslingen sekvensielt med avtalte utvekslinger av tegninger. Grensesnittet mellom aktørene er tydelig. Med BIM- basert samhandling foregår informasjonsutvekslingen mer i parallell og med hyppigere utvekslinger. Grensesnittet er mer integrert. BIM-basert samhandling bidrar til økt effektivitet og kvalitet i prosesser og resultater, men stiller som nevnt også krav til god strukturering av samhandlingen mellom aktørene.

1.5.3 Definisjon

BIM er i ISO 19650-1 definert slik:

«Bygningsinformasjonsmodellering - BIM (building information modelling) bruk av en delt digital framstilling av et byggverk for å legge til rette for prosjektering, bygging og driftsprosesser slik at det kan dannes et pålitelig grunnlag for beslutninger»

BIM er således en overordnet betegnelse på bruken av en digital representasjon av et byggverk, der frembringelsen og bruken av representasjonen er delt mellom flere aktører som på denne måten samvirker om nødvendig prosjektering, innkjøp og bygging for å fremstille byggverket, og deretter for de aktører som er involvert i driften.

Definisjonen innebærer at BIM både betegner prosessen å utvikle representasjonen og selve representasjonen.

Poenget med prosessen er den verdiskapning den medfører, herunder etableringen av selve representasjonen – modellen.

Selve modellen kan relatere seg til prosjektgjennomføringsfasen eller driftsfasen. Disse modellene betegnes gjerne som henholdsvis PIM (Project Information Model, oversatt av Standard Norge til prosjektinformasjonsmodell) og AIM (Asset Information

Model, oversatt av Standard Norge til Informasjonsmodell for byggverk, forkortelsen AIM brukes også på norsk). Mens PIM gjelder prosjektfasen frem til ferdig «asset = byggverk» (bygning eller anlegg), gjelder AIM situasjonen etter at bygget eller anlegget er overtatt for bruk, og er derfor en del av eller grunnlag for FDV(U)- dokumentasjon. Se evt. NS/EN ISO 19650-1 pkt. 4.1, 5.6, 5.7 og 6.2 for beskrivelse av begrepene PIM og AIM.

Også den rådende oppfatning i bransjen er at BIM omfatter både prosess og modell. Denne dobbeltheten kan innebære utfordringer når man skal kontraktsregulere BIM- relaterte forhold. Men komiteen mener utfordringene kan håndteres bare man er tilstrekkelig bevisst om reguleringen tar sikte på det ene eller det annet aspekt – eller begge. Rapporten forsøker å gjenspeile dette. Det leverandøren skal prestere under en entreprise- eller rådgivningskontrakt betegnes gjerne som «ytelsen». I lys av definisjonen av BIM vil leverandørens ytelse på dette punkt kunne omfatte både plikter til å (delta i å) utvikle representasjonen – altså plikter knyttet til prosess – og plikt til å overlevere eller stille til disposisjon representasjonen eller stadier eller elementer av denne – altså plikter som ligner mer på fysiske leveranser. Dette er i tråd med NS 3418:2020 Konkurransegrunnlag med ytelses-beskrivelser for prosjekterings- og rådgivningsoppdrag — Struktur og innhold og NS 3450: 2014 Konkurransegrunnlag for bygg og anlegg - Redigering og innhold, som også skiller mellom leveranse og aktivitet. Dobbeltheten i BIM-definisjonen vil i kontraktsammenheng oftest gi seg utslag i om det er prosess og/eller leveranse som er den ytelse man tar sikte på å regulere.

1.5.4 Begreper, utvikling

Man bør ikke bruke BIM-relaterte begreper som strider mot begreper i ISO 19650. Men presisjon er neppe nødvendig på kontraktsvilkårs-nivå, bare i kravsspesifikasjoner i vedlegg.

I tråd med dette brukes i det følgende «bestiller» i stedet for «byggherre». Men på ett punkt avviker komiteen fra ISO-begrepsbruken: Vi bruker «leverandør» som betegnelse på bestillerens kontraktspart (entreprenør eller rådgiver), ikke «ledende leverandør» som man gjør i ISO-sammenheng. Og leddet nedenfor i kontraktshierarkiet betegnes som «underleverandør». Noe annet ville bryte for sterkt med langvarig innarbeidet begrepsbruk i bygge- og anleggsbransjen.

Objektdefinisjoner med tilhørende egenskapssett er felles arbeidsredskap for alle aktører og må derfor være standardisert – i hvert fall innen fag og mellom visse disipliner. Slike felles egenskapssett utvikles mest effektivt i generell standardiseringssammenheng. Kontraktsvilkår/-vedlegg må nøye seg med å henvise til standarder som måtte finnes. Det tilsvarende gjelder for datablader m.v. tilknyttet objektene.

Alle BIM-relaterte krav/standarder må utformes i lys av at dette er «bevegelige mål». BIM-relaterte krav/forutsetninger må ikke hindre utviklingen internasjonalt/nasjonalt, men støtte opp under den.

1.6 Anskaffelse

1.6.1 Generelt i BIM-sammenheng

Rapporten gir i første rekke grunnlag for utforming av kontraktsregler tilknyttet BIM. Men bruk av BIM i prosjektet har også konsekvenser i konkurransefasen. Her er de sentrale standardene NS 3450 og NS 3418. Når rapporten foreslår at emner bør reguleres i kontraktsvedlegg, har dette ofte en side til den strukturen og til dels det innholdet disse standardene legger opp til.

1.6.2 Konkurransegrunnlag

Skal prosjektet baseres på BIM, antar komiteen at ambisjonene for BIM bør synliggjøres i konkurransegrunnlaget.

Konkurransegrunnlaget må også fastsette kravene til leverandørens BIM-ytelser i prosjektet, og prisbærende poster knyttet til dette. Her kan man ha hjelp av ISO 19650-1 og mer detaljert i EN 17412-1. Tilbyderens generelle forutsetninger for å bruke BIM (kompetanse, prosess, samvirke) kan tenkes å være en del av kvalifikasjonskravene eller tildelingskriteriene som fastsettes i konkurransegrunnlaget. Komiteen har likevel ikke gått nærmere inn på de praktiske utfordringene man møter når dette skal konkretiseres.

2 Krav til ytelse/prosess

I dette pkt. 2 behandles spørsmål knyttet til leveransen av BIM-modell: Hvilket formål har leveransen (2.1), hvilken kommunikasjon og samhandling mellom partene krever den (2.3) og hvilke krav stilles det nærmere bestemt til leveransen (2.2)? Videre drøftes i 2.4 det prinsipielt viktige spørsmålet om hvilken rang modellen skal ha sammenlignet med andre kilder for krav til leverandørens ytelse (tegninger, spesifikasjoner osv.). Siden BIM innebærer en løpende prosess, er det sentralt å holde orden på hvilket stadium man har nådd, se 2.5 om prosesstatuskode. Endelig tas opp to praktisk viktige anvendelser av BIM: som FDV(U)- dokumentasjon og som grunnlag for mengdekontroll (se hhv. 2.6 og 2.7).

2.1 Til hvilket formål BIM kan benyttes

2.1.1 Formålet

Formålet med bruk av BIM i prosjektet har betydning for flere sentrale forhold i kontraktsreguleringen. Bl.a. vil formålsangivelsen

• sette rammer for detaljkrav om prosess/ytelse (2.2 nedenfor)

• kunne avgjøre hvilke rettigheter den enkelte aktør har til informasjon i BIM (3.1 nedenfor)

• kunne avgjøre hvilket ansvar en aktør har for feil i informasjon eller bearbeidelse i BIM (4.1 nedenfor)

• ha betydning for hva som utgjør tilleggsinformasjon (4.3.1 nedenfor)

• definere hva som innebærer bruk utenfor angitt formål (av ferdig modell eller forutgående informasjonsstadier) (4.3.2 nedenfor)

Formålet bør derfor angis så presist som mulig. En overordnet fanebestemmelse om formål kan tas inn i kontraktsvilkårene, mens de mer prosjektspesifikke bestemmelser bør inntas i vedlegg.

Aktuelle parametere i formålsangivelsen kan være:

• Bruk av modellen (for prosjektering eller deler av den, bygging, FDV og/eller videreutvikling etter avsluttet kontraktsforhold, egen bruk/overdragelse osv.). Se eksempler på formål for bruk av modell i 2.1.2

• Krav til fremgangsmåte eller leveranse. Formål med bruk av BIM kan både skyldes krav til en konkret informasjonsleveranse eller en fremgangsmåte i en ytelse. Det er ikke alltid klart grensesnitt mellom disse to opphav til formål. En informasjonsleveranse kan også brukes til å støtte prosessen som fører frem til leveransen. F.eks. vil krav til Tverrfaglig merkesystem bidra til bedre modellstruktur og samhandling. Omvendt vil en fremgangsmåte påvirke informasjonsleveranse. For eksempel vil analyse av byggbar geometri sikre et koordinert produksjonsgrunnlag. I 2.1.2 a) og

b) er det antydet en oppdeling mellom om formålet kan være et krav til fremgangsmåte eller resultat. Det er ikke entydig om det gitte eksemplet bare hører til den kategorien. Dette vil bla. avhenge av hvordan kravet er definert.

• Faseavhengige formål (PIM = modell i prosjektfasen og AIM = modell i driftsfasen). Formål kan overordnet deles inn i om BIM brukes i prosjektfasen eller i driftsfasen. Flere av de underliggende tekniske formål, se pkt. 2.1.2 a) og b) nedenfor, er aktuelle for både PIM og AIM. Denne inndelingen sier derfor i seg selv ikke så mye om hva som skal gjøres, men den kan være relevant for å vite hvilke krav gjelder for informasjonsleveransen/fremgangsmåten og for rent avtalemessig å kommunisere eierskap og krav til informasjon.

2.1.2 Eksempler på spesifikke formål BIM kan benyttes til

BIM kan brukes som verktøy for en rekke spesifikt angitte formål. Formålene utvikler seg og endres stadig. Det er derfor ikke mulig eller ønskelig å utarbeide noen komplett liste over formål i denne rapporten.

Formålet bør angis i kontrakten, fordi dette kan ha kontraktsmessig betydning i en del sammenhenger, f.eks. i forbindelse med regulering av ansvarsforhold og bestillerens bruksrett. Det vil være vanskelig å fastslå rekkevidden av slik regulering hvis formålet ikke i en eller annen form er angitt.

I det følgende gis noen eksempler på bruk av BIM (listen er ikke uttømmende):

a) Eksempler på formål som kan være et krav til leveransen (informasjonsleveranser):

• Tverrfaglig merkesystem

Alle systemer og objekter tildeles en kode iht. Standard Norges NS 3457 del 7, 8 og 9 for å identifisere system og produkttyper samt forekomster hvor dette måtte være aktuelt.

• Produksjonsgrunnlag

Det kan være enklere å kommunisere det prosjekterte materialet til de utførende direkte med BIM enn å skulle produsere tegninger, f.eks armeringstegninger (og tilsvarende i andre fagområder): I stedet for å rapportere modellen i tegninger og bøyelister, kan modellen brukes direkte for automatisk generering av bøyelister av armeringsleverandør og visualisering av armering for armeringsentreprenør.

• Energiberegning

Energibehov og -balanse kan beregnes med digitale verktøy som kan lese geometri av byggets klimaskall fra modell.

• Mengdeuttak

Oversikt over mengder for alle bygningskomponenter kan hentes ut fra modell. Se 2.7 nedenfor.

b) Eksempler på formål som kan være et krav til fremgangsmåte:

• Kontroll med status og fremdrift i prosjektet.

Statussetting kan brukes for å kommunisere modenhet på objekter. se 2.5.

• Visualisering av prosjektet og dets elementer på forskjellige stadier og for forskjellige formål.

• Byggbar geometri - kollisjonskontroll og byggbarhet

Fagmodeller settes sammen og analyseres med digitale verktøy for å finne avvik som kan kreve omprosjektering eller annet omarbeid i senere faser.

• Kostnadskalkyle

Det er mulig å bruke modeller til å liste opp mengder på objekttyper og prisdrivende egenskaper for disse i kalkyleverktøy.

• Mengdekontroll (se nærmere 2.7 nedenfor)

• Samhandlingsverktøy ICE

Integrated Concurrent Engineering er en beslutningsprosess for å fatte vedtak i tverrfaglige, komplekse saker. ICE-møter er velforberedte møter hvor alle nødvendige beslutningstakere er tilstede og med konkrete mål for beslutninger som skal tas. Møtene bruker modeller til å kommunisere problemstillinger og finne løsninger som ivaretar behov fra alle deltakerne.

• Rømningsanalyser

• Kontroll og oppfølgning av kvalitet.

• Planlegging av midlertidige forhold, eksempelvis krav til og muligheter for inntransport på forskjellige stadier av prosjektet.

• HMS-planlegging og -kontroll.

2.1.3 Endring av formål

Bestilleren kan i løpet av prosjektet se behov for bruk av BIM for formål ut over de som ble angitt ved kontraktsinngåelsen. Årsaken kan eksempelvis være teknologisk utvikling, regelverksendringer eller at behov ble oversett.

Slike endringer gir to typer utfordringer:

• bestilleren må i kontrakten sikre seg myndighet til å foreta endringen. Dette kan ofte håndteres gjennom den vanlige endringsmekanisme, men kan kreve særlige overveielser.

• virkningen av endringene reiser de vanlige spørsmål om ansvar, tilleggsvederlag og evt. fristutsettelse. Siden endringen kan ha grunnleggende betydning for kontraktsforholdet, bør disse forholdene gjennomtenkes.

2.2 Leverandørens ytelser

En samlet illustrasjon av kravene til prosess/ytelse i en rasjonell prosjekteringsprosess er inntatt som Vedlegg 1.

Noen av temaene i dette punkt kan trolig fastsettes som overordnet regulering i kontraktsvilkår, mens detaljer fastsettes i vedlegg. Detaljkrav kan være egnet for standardisering.

Det vil være nærliggende at kravene justeres i løpet av kontraktsperioden, på grunn av eksempelvis ny teknologi, nye prioriteringer og fremdriftsutfordringer. Prosedyrene for og konsekvensene av slike justeringer håndteres av den vanlige endringsmekanismen, mens kontraktens opprinnelige krav (som kanskje er justert) må beskrives i ytelse/prosess.

2.2.1 Hva skal leveres av leverandøren

a) Grunnleggende ytelser

Sentralt i kontraktsregulering av BIM-relaterte forhold er å stille krav til leverandørens

«ytelse». Ytelsen kan omfatte et bredt spekter av kontraktsplikter, og den vil naturlig variere mellom de forskjellige aktører i prosjektet. Den kan bestå i en ferdig modell, eventuelt ført frem til et definert stadium av modenhet. Ytelsen kan også være å

forestå eller bidra til prosessen frem til modellen på en nærmere spesifisert måte. Også plikten til spesifisert eller generelt samvirke med andre aktører om BIM kan være en del av ytelsen. For reguleringsformål kan man ofte skille mellom ytelseskrav i form av (i) krav til hva som skal leveres og (ii) krav til prosessen for frembringelsen av dette.

Kravene til ytelsen vil naturlig nok avhenge av om kravet gjelder resultat eller prosess.

Kravene til resultat kan eksempelvis gjelde kvalitet, format, dokumentasjon, overleveringsprosess, dokumentasjon av prosesstatus (eksempelvis MMI), osv. Dette kan gjøres som spesifikke krav og/eller som funksjonskrav. Eksempler på funksjonskrav kan være at modellen skal være «tilstrekkelig til energiklassifisering i henhold til »). Eller at modellen skal kunne være grunnlag for nærmere angitt form

for maskinstyring.

Kraven til prosess kan ta utgangspunkt i en forutsatt eller spesifisert BIM-prosess der viktige elementer er eksempelvis faser, samspill mellom aktører, rekkefølgebestemmelser, avhengigheter, dokumentasjon, kommunikasjonsformer, modenhetsverifisering, formater og lagring.

Regulering av ytelser og prosess knyttet til BIM må gjøres i vedlegg til kontrakten, mens leverandørens overordnede BIM-relaterte plikter bør vurderes inntatt i kontraktsvilkårene.

Etter komiteens syn er det flere sider av vedleggs- og ytelsesdelen knyttet til BIM som kan være egnet til standardisering i regi av Standard Norge eller andre. Særlig gjelder dette kriterier og prosesser for forskjellige faser av MMI (modenhetsstatus). Her foregår det allerede arbeid i regi av Standard Norge, jfr. den pågående revisjonen av NS 8360.

b) Forhold til andre aktører

BIM benyttes naturlig til samhandling og utveksling mellom de ulike involverte aktører underveis i prosjektet. Hvordan dette skal foregå må defineres i prosessbeskrivelse. Her bør man tenke på innhold, tidspunkt og form. Dette har også sider mot bl.a. det definerte formålet med BIM (2.1 over), rettigheter til informasjon i BIM (3.1 nedenfor), ansvar for feil i BIM (4 nedenfor).

Leverandørens plikt kan også omfatte å motta leveranse av BIM-innspill og krav fra andre leverandører som grunnlag for eget arbeid. Slikt grunnlag kan være av foreløpig karakter der modeller utveksles daglig eller ukentlig, altså at man utveksler innspill oftere enn ved milepæler. God og strukturert kommunikasjon i prosjektet mellom fagene er en forutsetning for at dette skal fungere greit. Modeller kan inneholde informasjon, som ikke er klar til å benyttes ennå. Det er derfor viktig at formålet med bruken av slike utvekslinger er avklart/avtalt.

Det kan også være aktuelt å pålegge leverandøren som selvstendig ytelse å samordne BIM-arbeidet tverrfaglig, eventuelt innen angitte områder eller faser. En slik rolle vil typisk tillegges én av mange aktører som deltar i arbeidet. Kontrakten (vedleggene) må i så fall identifisere denne aktøren. Videre må innholdet i samordningsplikten identifiseres, siden det her ennå ikke kan sies å foreligge noen etablert oppfatning. Slik identifisering og spesifikasjon er selvsagt nødvendig hvis den aktuelle leverandøren skal ha koordineringsrollen. Men også i kontrakt med andre aktører kan det være nødvendig å identifisere hvem som står for koordineringen og hva den skal bestå i, fordi dette virker direkte inn på disse aktørenes plikter.

c) Særlig om felles team osv.

I enkelte prosjekter legges det opp til omfattende og «sømløst» samvirke mellom forskjellige aktører for å optimalisere utviklingen av BIM. Selv om slike ordninger kan ha viktige operasjonelle fordeler, vil felles team som samvirker uten klare systemer for hvem som beslutter, betaler og har risiko for valg kunne innebære særlige utfordringer i prosjektstyringen.

Slikt samvirke må også ta høyde for at enkeltaktører kan ha ansvar for ulike oppgaver eller fag overfor det offentlige etter f.eks. plan- og bygningslovens system om ansvarsrett. Eventuelt samvirke og samspill må legges opp slik at slike aktører får ivaretatt sine offentligrettslige plikter.

2.2.2 Digitalisert produksjonsstyring, fremdriftsmåling og sluttkontroll

Skal den digitale samhandlingen også gjelde planlegging, framdriftsmåling og sluttkontroll, må de definerte objektene ha en utvetydig knytning til verdibærende poster, lokasjon, planområder og planaktiviteter. Eksempelvis må en lampe i standard utførelse være eget objekt og ha en egen prisbærende post i forhold til en spesiallakkert utførelse, som vil ha en annen objekt-definisjon og en annen prisbærende post.

Dette må ivaretas i vedleggsbestemmelser om styring, fremdrift og sluttkontroll, med tilknytning til vederlagsbestemmelser. Her ligger det trolig også en mulighet for standardiseringsarbeid.

2.2.3 Leveringstid

Leveringstid er sentralt i fastleggelsen av leverandørens ytelser. Den kan eksempelvis knyttes til definerte elementer («del-leveranser», f.eks. nødvendig prosjekteringsgrunnlag for enkelte disipliner på visse stadier). Eller den kan være nødvendig for å gjennomføre kontroll av prosesstatus (eksempelvis MMI).

Utfordringen ligger her ofte i å definere meningsfulle ytelser på tilstrekkelig presis måte – særlig når man griper inn i en kontinuerlig utvikling av datagrunnlaget, se

2.2.1 ovenfor.

Denne problemstillingen er især viktig ved bruk av BIM da informasjon ofte utvikles i parallell mellom aktørene. Så selv om modellene er under utvikling i samspill mellom prosjektets aktører må noe informasjon kunne låses og brukes som grunnlag uten at det senere kan endres og utløse behov for omarbeid fra andre aktører.

Eksempler på manglende rettidig leveranse kan være at rådgivende ingeniør bygg endrer gridavstand på bærende søyler lenge etter at dette skulle ha vært «låst». Eller at arkitekten endrer den låste himlingsplanen sin etter av rådgivende ingeniør VVS har satt ut sprinklerhodene sine eller rådgivende ingeniør elektro har satt ut ABA- detektorene og innfelte lysarmaturer.

2.2.4 Krav til kvalitetssikring

Leverandøren er gjennom offentligrettslige regler pålagt å kvalitetssikre sin leveranse gjennom å identifisere, verifisere og dokumentere oppfyllelse av myndighetskrav.

Leverandøren kvalitetssikrer også BIM-modellen opp mot det formål som bestiller har ønsket den benyttet til og de krav som er satt i prosjektet til objekter, egenskaper og detaljeringsgrad. Kvalitetssikring av myndighetskrav i BIM-modell og av at BIM- modellen/innhold kan brukes til forutsatt formål vil være en selvstendig del av kravene til prosess/leveranse. Selv om ytelsene som skal kvalitetssikres er som avtalt, forlegger det svikt hvis kvalitetssikringen ikke er gjennomført som den skal. Det må også skilles mellom prosess for kvalitetssikring og faktisk gjennomføring av den – også dette utgjør normalt selvstendige plikter.

I likhet med eksempelvis sikkerhetskrav, bør trolig overordnede kvalitetssikringskrav nedfelles i kontraktsvilkårene i form av «fanebestemmelse», f.eks. om at kvaliteten skal sikres opp mot BIMs formål, mens detaljene hører hjemme i vedlegg.

Krav til kvalitetssikring er trolig egnet for generelt standardiseringsarbeid dersom ikke eksisterende (internasjonale) standarder anses tilstrekkelige.

2.2.5 Premissgivere

BIM innebærer at de forskjellige aktører i prosjektet kontinuerlig forholder seg til hverandres data og utvikling av prosjektet. I dette «hopehavet» er gjerne noen fag premissgivere for andre, ofte fordi de er grunnleggende, fremdriftsmessig først eller fordi de i større grad er styrt av uomgjengelige ytre krav (om f.eks. energisertifisering eller avstandskrav). Praktisk viktige premisser kan ligge i arealplaner og grunnlagsdata fra kommunen.

Den som leverer premisser, er ansvarlig for at de er iht. avtalte krav. Og den som forbruker data fra denne leverandøren, må sikre at de holder seg til de gitte premissene.

2.3 Krav til kommunikasjon/samhandling

2.3.1 Generelt om kontraktskommunikasjon

Den stadige utviklingen av nye kommunikasjonsplattformer, tilsier en tydelig regulering av hvilken form kontraktsmessig kommunikasjon skal ha. Men her må det legges opp til en fleksibel regulering i standarden, slik at dette kan håndteres i den enkelte kontrakt. Enkelthetene må plasseres i vedlegg, mens en fanebestemmelse bør tas inn i kontraktsvilkårene.

Hva som utgjør kontraktsrelevante varsler, krav, osv. må defineres i de bestemmelser (i kontraktsvilkårene) som gir slike utsagn kontraktsrelevans (eksempelvis i endringsmekanismen). Skal eksempelvis kommunikasjon i form av «chat» på ulike plattformer være kontraktsrelevant? Disse spørsmålene tilsier årvåkenhet, men neppe særskilt regulering

Der den enkelte deltaker har praktisk mulighet for å sikre kopi av kommunikasjonen må som utgangspunkt denne selv ha ansvar for å sikre at den kan dokumenteres

(f.eks. i senere tvist). Der det er tekniske løsninger/saksbehandlingssystemer som gjør det praktisk vanskelig for deltakerne å sikre kopi, må det etableres tilgang/backup til relevant informasjon.

- Et eksempel kan være kommunikasjon per chat i et saksbehandlingssystem som styres av andre og som ikke åpner for lagring av lokal kopi eller som forutsetter lisens på systemet.

- Et annet eksempel kan være situasjoner der en aktør utestenges fra systemer som inneholder prosjektering med tilhørende kommunikasjon, uten at han har adgang til å hente ut kopier av det han selv har lagt inn. Her kan det være behov for regulering som sikrer tilgang til relevant informasjon.

- Et tredje eksempel er bruken av løsninger for utveksling og lagring av prosjektinformasjon, f.eks. Virtual Desktop Infrastructure (VDI) levert av den ene parten, er at denne parten da sitter på all informasjon som etableres og utveksles på løsningen. De andre partene har dermed behov for å hente ut all informasjon de selv har lagt inn og basert deres arbeid på samt eventuell annen relevant informasjon/kommunikasjon. Hvordan slik informasjon utveksles bør reguleres.

I den utstrekning en VDI-løsning omfatter modelleringsprogramvare kan serverkapasitet, optimalisering for programvaren, oppsett av arbeidsflate for den individuelle leverandøren, tildeling av lisens, behandling av nedetid og system for backup få betydning for leverandørens forutsetninger for å jobbe effektivt og levere iht. avtale. Ytelse for en slik løsning bør reguleres.

2.3.2 Spesielt om BIM-relatert kommunikasjon

Ethvert komplekst prosjekt stiller store krav til partenes evne og vilje til effektiv kommunikasjon på en fastlagt og strukturert måte innen avtalte tidsplaner. Dette er forutsetningen for leverandørens oppfyllelse av den ytelsesplikt han påtar seg (2.2 ovenfor). Kravene til effektiv og ryddig kommunikasjon blir enda viktigere i prosjekter som bruker BIM.

Den overordnede plikt til slik samhandling bør fremgå av kontraktsvilkårene, mens detaljer om prosessen må tas inn i vedlegg. Det er her åpenbart et standardiseringsbehov, som i noen grad ivaretas av ISO 19650-serien, men som kanskje bør videreutvikles i generell standardiseringssammenheng eller tilpasses det konkrete prosjektet gjennom utformingen av vedleggene til den individuelle kontrakten.

Økende bruk av smarte objekter og skripts kan være viktige konkurransefortrinn mellom leverandørene. Bedrifter som i et prosjekt deltar i samme leverandørgruppe kan være konkurrenter i et annet prosjekt. Prosjektet bør regulere krav til utveksling av slik informasjon. Det må unngås at viktig informasjon ikke deles i leverandørgruppen samtidig som det støttes opp under at enkeltleverandører driver innovasjon og gjør bruk av ny teknologi for økt effektivitet.

I tillegg til den generelle prosedyre for hvordan samvirket mellom partene skal foregå, er det behov for regulering av hvilken innsikt partene (og andre aktører) skal ha underveis i prosessen – altså før en definert «ytelse» skal foreligge. Dette må sees i sammenheng med bl.a. spørsmålet om rett til bruk av informasjonen (3.13.1 nedenfor) og ansvar hvis informasjonen inneholder feil (4 nedenfor).

NS/EN ISO 19650-2 punkt 5.4.4 beskriver hvordan man kan avtale leveranser mellom aktører i en delplan for informasjonsleveranse (TIDP – Task information delivery plan). Denne beskriver hvem som skal gjøre informasjon tilgjengelig for de andre partene i prosjektet. NS/EN ISO-standarden, punkt 5.4.2 og Annex A beskriver også hvordan man i en detaljert ansvarsmatrise kan angi ulike typer av ansvar for leveranser.

2.3.3 BIM gjennomføringsplan

Til grunn for bruk av BIM – i alle faser og former – må det ligge en samlet plan for hvem som skal bidra med hva, når og i hvilke former. Enkelthetene hører under mange forskjellige overskrifter (bl.a. om ytelser i pkt. 2.2, ansvar i pkt. 4 og rettigheter i pkt. 3.1), men operativt viktige aspekter bør sys sammen i en samlet plan. Plikt til å følge den kan naturlig tas inn i kontraktsvilkårene, men enkelthetene må henvises til vedlegg. ISO 19650-serien kan gi verdifulle innspill.

Ofte utarbeides det nærmere detaljer i en BIM-gjennomføringsplan – kalt BIM Execution Plan (BEP), jfr bl.a ISO 19650-2 2010 pkt. 3.13.1. Eksemplet i vedlegg 1

«Rasjonell prosjekteringsprosess» som er lagt til slutt i rapporten omhandler deler av en BEP, nemlig hvilke objekter som må nå hvilken modenhetsgrad til hvilke tidspunkter. Eksemplet viser også en detaljering av hva hver enkelt modenhetsgrad betyr i praksis, for eksempel nødvendig informasjon fra tilstøtende aktør/fag. Det er avgjørende at beskrivelsene av dette er detaljert nok til at det er mulig å verifisere om modenhetsgraden (evt avtalt kontraktuell forpliktelse) er oppfylt eller ikke.

En mal for BIM-gjennomføringsplan er godt egnet for generell standardisering.

En særlig utfordring ved gjennomføringen av tegningsløse prosjekter, er å definere grensene for når prosjekteringsansvaret opphører for prosjekterende og entreprenøren overtar dette ansvaret. Eksempelvis kan en BIM-modell mangle flere av målsettingene som tradisjonelt har vært å finne på en DWG/PDF-tegning. Når entreprenøren så benytter modellen til å ta ut produksjonsgrunnlaget og eksempelvis målsetter en betongkonstruksjon, så vil entreprenøren i praksis ha påtatt seg et prosjekteringsansvar. Dette bør reguleres, f.eks. i ytelsesbeskrivelsen, slik at dette ansvaret er klart.

2.3.4 Utvikling og revisjon av BIM-modellen i kontraktsperioden

a) Konsekvenser av revisjoner

En praktisk svært viktig del av kommunikasjonen gjelder den del av prosjektstyringen som består i kontroll med de revisjoner BIM-modellen gjennomløper i prosjektfasen.

Ofte jobber fagene på underlag fra andre fag. F.eks. vil VVS- og elektroingeniørene basere seg på underlag fra arkitekt og bygningsingeniør. Hvis underlaget fra sistnevnte endrer seg vesentlig etter at VVS- og elektroingeniørene har kommet langt i deres arbeid kan det medføre kostnadsdrivende omarbeid. Tilsvarende hvis utførende baserer innkjøp og bygging etter underlag som senere endrer seg.

Bruk av BIM kan medføre mer integrert samhandling mellom fagene og hyppigere utveksling av informasjon enn i prosjekter uten bruk av BIM. Dermed kan det være

vanskelig å holde styr på bl.a. revisjonshåndtering. Selv om mer integrert samhandling mellom fagene har mange fordeler, herunder bedre tverrfaglig forståelse for hverandres problemstillinger og flere iterasjoner i arbeidet frem mot kundens og prosjektets mål, så byr det også på utfordringer som forutsetter god styring av fagenes aktiviteter.

En måte å håndtere enkelte revisjoner på, kan være å angi prosesstatuskode (MMI) ned på det enkelte objektet så man kan se hvilke objekter som er låst, fordi de brukes som underlag av andre, og hvilke som fortsatt kan endres. Da kan alle se hva som kan brukes som underlag og ikke skal endres uten avtale.

NS-EN-ISO 19650-1 beskriver at informasjon i felles datamiljø kan ha status som ikke-delt, delt og publisert. Ikke-delt vil si at informasjonen bare er tilgjengelig for den enkelte aktør eller det enkelte fag. Konsekvensen av endring i ikke-delt informasjon anses som liten og trenger bare koordinering internt i faget. Delt informasjon kan f.eks. bety at informasjonen er delt innen prosjektgruppen. Det kan f.eks. være ukentlige utvekslinger av modeller mellom de prosjekterende. Konsekvensen av en revisjon av delt informasjon kan være kostnadsdrivende og krever koordinering innen gruppen hvor denne er delt.

Publisert informasjon er en mer formell måte å distribuere informasjon på. Det kan f.eks. være en utgivelse av produksjonsunderlag fra prosjekterende til utførende. Den krever høyere grad av kvalitetssikring og vil typisk ikke revideres med samme frekvens som delt informasjon. Konsekvensen av endring av publisert informasjon kan være svært kostnadsdrivende f.eks. i form av ombygging.

Prosjektet bør planlegge håndtering av revisjon av informasjon så potensialet med bedre integrasjon mellom fagene utnyttes samtidig som risiko for kostnadsdrivende endringer elimineres. Dette bør beskrives i vedlegg.

b) «Revisjoner» og «endringer»

En revisjon består normalt av en eller flere endringer (herunder supplering av informasjon) i modellen. Det er helt sentralt at deltakerne i prosjektet får nødvendig informasjon om endringer som er foretatt i modellen. På tegninger identifiseres dette vanligvis med en endrings-sky. I modeller gjøres gjerne bruk av verktøy som kan sjekke, rapportere og visualisere både geometriske og informasjonsmessige endringer. Hvordan slik informasjon skal gis må reguleres i vedlegg, som en del av ytelse/prosess.

Spørsmålet er egnet for generell standardisering, jfr. også neste punkt.

For å avdekke om det foreligger en endring, er det behov for å sammenligne informasjonene leverandøren hadde adgang til å basere seg på med informasjonene han nå må forholde seg til. Dette krever at man kan identifisere det opprinnelige informasjonsgrunnlaget. Det er enkelt dersom dette grunnlaget er definert som en

«ytelse» fra en annen aktør – normalt finnes det da systemer for å identifisere informasjonspakken. Men er dette ikke gjort, er det utfordrende å identifisere og dokumentere hvilke informasjoner f.eks. elektroentreprenøren berettiget baserte seg på.

Se for øvrig en samlet illustrasjon av en rasjonell prosjekteringsprosess inntatt som Vedlegg 1. Det som der er beskrevet om leveransepakker til entreprenør, kan også gjelde for avtalte informasjonspakker mellom ulike arkitekt- og/eller prosjekteringsaktører. Egenskapene må legge til rette for å kunne angi samme modenhetsstatus på samme objekt flere ganger, men da med ulike revisjonsnummer knyttet til forskjellige datoer.

Hvorvidt en revisjon i BIM-modellen også utgjør en «endring» under kontrakten, med tids- og/eller kostnadskonsekvens, vil bero på en konkret vurdering. Det må da bl.a. ses på hva som er definert som leverandørens ytelsesplikt (2.2 ovenfor) og hvem som har hvilke rettigheter til hvilken informasjon på hvilket stadium (3.1 nedenfor).

Dessuten er statussetting (Modell Modenhets Indeks - MMI) på objekter sentralt for å kunne spore om disse er modnet og publisert for bruk av andre (2.5 nedenfor).

c) Hvordan regulere?

BIM muliggjør nøye kontroll med og dokumentasjon av revisjoner underveis. Dette er sentralt for ryddig prosjektgjennomføring og for mulig risiko- og ansvarsplassering.

Revisjonshåndtering synes å ligge an til standardisering. Reguleringsbehovet og - hensynene synes å være generelle – det er neppe spesifikke behov i det enkelte prosjekt (skulle det være det, får man ta det inn i ytelse/prosess).

Komiteen antar at den kontraktsmessige håndteringen av revisjoner i BIM-modellen enklest gjøres ved å introdusere mest mulig dekkende systemer for uttak av

«informasjonspakker» fra BIM, der pakkens innhold og tidspunktet for uthenting gjøres til ytelseskrav for den aktuelle BIM-aktør. Krav av denne typen må eventuelt legges i kontraktens vedlegg. NS/EN ISO 19650-1 pkt. 12 beskriver krav til felles datamiljø (CDE – Common data environment) hvor det skilles mellom informasjon som er delt (innen leverandørgruppen) og publisert (til f.eks. entreprenør). Felles datamiljø skal bla. gi tilgang til informasjon på riktig nivå for de ulike aktører og versjonshåndtering.

Det er her trolig grunnlag for standardisering i regi av Standard Norge eller andre.

Slik vedleggs-regulering må støttes på vilkårsnivå: Kontraktsvilkårene må reflektere at BIM-modellen gjennomløper revisjoner ved å identifisere (evt. pr. henvisning til vedlegg) hva som for forskjellige formål utgjør relevante revisjoner, hvilke (overordnede) kontraktsvirkninger de skal ha og hvordan de skal håndteres under kontraktens alminnelige endringsmekanisme.

2.4 Rang / grensesnitt

2.4.1 Rangordning tegning – modell – beskrivelse

a) Behov og muligheter

Rangordningen mellom tegninger, beskrivelser og modeller (BIM) er viktig dersom informasjonsinnholdet er ulikt (motstridende eller mer detaljert). Fra et kontraktsperspektiv er det meget uheldig hvis det da er uklart hvilken informasjonsbærer som har prioritet.

Normalt vil beskrivelser inntatt i kontrakten gå foran både tegninger og modeller. Men for øvrig vil det kunne variere med bl.a. prosjektene, entrepriseform og BIM-prosess hvilken rangordning partene ønsker. Viktig informasjon er dels i modell, dels på tegning og delvis i beskrivelse. Konsekvensen er lett utførelsesfeil siden det er meget vanskelig å holde orden på forholdet mellom informasjonskildene. Følgen kan være at BIM-modellene benyttes i mindre grad. Dette er en stor utfordring i dagens prosjekter.

Det er vanskelig å peke på noen etablert praksis mht. rangorden. Det kan være forskjeller mellom kontrakter bestiller inngår med rådgivere sammenlignet med de han inngår med entreprenører, og det kan vær behov for andre regler der tegninger bare er ment å gjengi informasjon som ligger i modellen enn der de skal gjengi

ytterligere detaljer. Det kan derfor være behov for å skille ned på ulike leveransetyper innen samme prosjekt. Det kan også være forskjellige behov i prosjektets forskjellige faser.

Komiteen antar at det i dag ikke er tilstrekkelig grunnlag for å innføre en generell regel om rangordning mellom informasjonsbærerne, uavhengig av særegenheter ved kontraktsforholdet og hvilken bruk av BIM det legges opp til. Forskjellene kan her være store og behovene tilsvarende ulike. Se nærmere b) nedenfor.

I påvente av en mulig senere standardløsning av prioritetsspørsmålet er det viktig at partene ved kontraktsinngåelsen tar standpunkt til prioriteten. De bør spesielt være oppmerksomme på de ufullstendige prioritetsreglene som finnes i de eksisterende standardene, og ved behov endre dem (se f.eks. NS 8405 pkt. 3.2 annet ledd). Se også punkt c) nedenfor. I hovedsak er det da forholdet mellom tegning og modell man bør se på.

Et praktisk behov gjelder tilgjengeligheten av informasjon som eksempelvis har konstruktiv betydning. Et eksempel er strukturer som har fall eller dobbelkrumning, et annet er overhøyde på broer. Slik informasjon vises i dag ikke på de åpne formatene man benytter (da det ikke er mulig). Tradisjonelt har informasjonen ligget i tekst på arbeidstegninger i 2D. Det er viktig at prosjektet stiller krav til hvilken informasjon som skal ligge hvor. Slik informasjon bør ligge samlet på et sted (tegning, modell eller beskrivelse), eller forholdet mellom beskrivelse, tegning og modell må tydelig fremgå i denne sammenheng, ellers vil feil og misforståelser lett kunne oppstå.

b) Generelt standardiseringsarbeid

Her ligger det trolig muligheter for generelt standardiseringsarbeid. Dette bør baseres på at når først BIM brukes, må modellene anses for å være de sentrale informasjonsbærerne. Tegninger bør være representasjoner av informasjon som i størst mulig omfang er hentet fra modellen. Det bør derfor i minst mulig grad være informasjon på tegning som ikke er avledet fra modellen. Avvik fra dette kan være tegningstyper som har mer informasjon enn det som pr. i dag med fordel kan legges i modellen, f.eks. detaljtegninger. Forrang av medium må derfor bestemmes ut ifra bruken av BIM i det enkelte prosjektet og evt. ned på ulike leveransetyper.

Enkelthetene må trolig bero på prosjektet. I tegningsløse prosjekter eller i prosjekter der det skal leveres en avansert BIM-leveranse og i liten grad tegninger vil det være nærliggende å la modell få forrang for tegninger. For prosjekter med enklere BIM-krav og som i stor grad etterspør tegningsleveranse er det ikke praktisk at modell gjelder foran tegning. Det ville føre til mye dobbeltarbeid.

På denne bakgrunn vil det være krevende å standardisere rangordningen mellom informasjonsbærerne. Et viktig element vil være å identifisere og definere ulike grupper av kontraktstyper og BIM-bruk som egner seg for ulike standardløsninger. Komiteen går ikke videre inn på dette, men understreker at praksis og standardisering her vil påvirke hverandre gjensidig.

c) Individuell kontraktsregulering

Uavhengig av standardisering er det imidlertid viktig at partene så langt mulig regulerer hvilken rangordning som skal gjelde i deres individuelle kontraktsforhold. Uansett hvilken løsning man her velger, må det være slik at når en aktør mottar flere underlag av den samme prosjekteringen, og det viser seg at disse underlagene ikke er like, må det fremgå hva som skal gå foran. Uten kontraktsregulering av rangordningen mellom ulike uttrykk for leverandørens ytelsesplikter kan kontraktskravet til ytelse bli uklart. Eksempelvis inneholder ikke NS 8405 noen bestemmelse om BIM-modellens rang.

Det trenger ikke være direkte motstrid mellom tegninger og modell. Den ene kan inneholde tilleggsinformasjon som ikke er strid med informasjon i den andre. Også betydningen av dette bør reguleres.

Rangordning og tilhørende regulering bør tas inn i kontraktsvilkårene, eventuelt med åpning for individuell tilpasning etter kriterier som antydet.

2.4.2 Rang mellom ulike modeller; Stiknings-, fag- og BIM-modeller

I et prosjekt kan det produseres modeller av ulik type i de forskjellige fasene. Det må avklares forholdet mellom disse og tiltenkt bruk. Dette vil typisk være en avklaring av arbeidsprosess som bør skje i vedlegg/BEP.

Kravene må nedfelles i vedlegg.

Her kan det ligge mulige temaer for standardisering.

2.5 Prosesstatuskode

I Vedlegg 1 er det tatt inn en omfattende eksemplifisering av en rasjonell prosjekteringsprosess, der bl.a. behovet for og systematisering av prosesstatuskode inngår.

Siden BIM skal utvikles fra intet til komplett modell, og siden forskjellige aktører har behov for data fra modellen på forskjellige stadier av utviklingen, er det behov for verktøy som gir oversikt over status og sikrer at angitt status faktisk foreligger.

Dette krever kontraktsregler (i praksis i vedlegg) om hvilke data som skal ha hvilken kvalitetssikring på hvilket tidspunkt. Et eksempel på slike verktøy er MMI (Modell Modenhets Indeks).

Reguleringen må sees i sammenheng med hva dataene skal brukes til den må altså innebære en ansvarsplassering ved interaksjon mellom aktører. Det må også være prosesser for hvordan dette skal gjennomføres, og hvordan utvikling i status fastlegges og kommuniseres.

BIM-modellen kan f.eks. gi et inntrykk av ferdig detaljering i geometri. Vinduer kan se ferdige ut, selv i en modell fra forprosjektet. Det kan være umulig å forenkle geometri eller detaljering på objekter. Så lenge det er vinduer i modellen, kan det genereres vindusliste eller skjema fra modellen (dog uten info om brannklasse etc). Det er derfor viktig å statussette objekter, f.eks. med MMI eller lignende.

Modenhetsgrad kan tenkes definert ved absolutte kriterier eller ved henvisning til formål. I noen tilfeller kan informasjon på objekter løse dette, ref. standardiseringsarbeid på objekt / filnivå som f.eks. IFC Rail.

Overordnede prinsipper bør reguleres på vilkårsnivå, detaljer i vedlegg.

Dette temaet er godt egnet for standardisering. MMI-tenkning er sentral i pågående arbeid, jf. f.eks. dansk veileder på veibygging, og Nordic BIM Collaboration (veg- og bane bestillere) som undersøker muligheten for en Nordisk standard for samferdsel for LoX og MMI.

2.6 FDV/FDVU

Den ferdige BIM-modellen kan benyttes til forskjellige avtalte formål. Underveis har den tjent som grunnlag for prosjektering, innkjøp og bygging, og deretter kan den være grunnlag for forvaltning, drift og vedlikehold av anlegget/bygget (FDV). Det må da være bestilt som en del av ytelsen og være avtalt hvilket nivå FDV skal være på. I FDV-sammenheng vil modellen i praksis være en dokumentasjon av «som bygget» («as built»). Men bestilleren kan også ønske å utvikle anlegget/bygget. Eksempelvis kan det være aktuelt senere å bygge på en etasje, hvilket verken vil være «vedlikehold» eller «drift», i motsetning til om bestilleren senere ønsker å skifte til dører med bedre brannsikkerhet.

Kontrakten (i praksis vedleggene) må fastlegge hvilken ytelse leverandøren skal prestere, se

2.2.1 ovenfor (hva skal leveres). I denne forbindelse er det behov for å regulere bl.a. kravene til modellens detaljnivå, rettigheter til modellen (overdragelse, bruk, evt. til hvilket formål, rett til bearbeidelse), ansvar og risiko for feil i modellen (evt. avhengig av hvilken rett bestiller har til modellen), oppbevaring og tilgjengelighet av modellen, og ansvar ved feil i tilleggsinformasjon.

Kontrakten (vedlegg) bør avklare hvem som skal sørge for at modelleveranse til FDVU er riktig (jfr. samspill om utvikling), og til hvilket detaljnivå den skal være riktig.

Hovedalternativer for hvilke ytelser som skal ligge inne i BIM for FDVU-formål kan være emne for standardiseringsarbeid: Det bør være en standardisert måte å angi kravene til produktet på – uavhengig av hvilken aktør som definerer kravene. Rammer/inspirasjon kan ligge i ISO 19650 (f.eks. AIM – Asset Information Model – Informasjonsmodell for byggverk)

2.7 Mengdeuttak og mengdekontroll

Uttak av mengder kan uten BIM gjøres av entreprenøren ved å vurdere beskrivelse og tegninger, opp mot annet materiale. Mengdekontroll uten BIM er ofte etter entreprenørstandardene en kontroll av mengdene i beskrivelsen mot de tilsvarende mengdene som fremgår av tilbudsgrunnlagets tegninger.

BIM bør ha funksjoner som åpner for uttak av mengder eller mengdekontroll. Det er flere utfordringer knyttet til dette i dag, i forhold til anvendeligheten av funksjonene og om de er tilpasset norske forhold eller entreprenørenes behov. NS 3420 er ikke utviklet for BIM-formål, og kan derfor ikke uten videre tas som uttrykk for de krav som bør stilles til BIMs anvendelighet som målegrunnlag. For eksempel vil reglene om måling av lengder på ventilasjonskanaler i den mest vanlige beskrivelsesmetoden NS 3420 ta høyde for innstikk og kapp. I BIM-modellen vil det derimot normalt være den faktiske lengden på ferdig bygget kanal som måles. Uten spesifikk tilleggsinformasjon om objektet vil kanalen i modellen ikke bli målt med den delen av kanallengden som stikker inn i en kanal eller den kanaldelen den kobles til. Bend, T-stykker og påstikk opplyses som antall av hver dimensjon. Lengden hvert bend, T-stykke og påstikk representerer vil være avhengig av dimensjonen. Dersom BIM skal brukes for måling og mengdekontroll, må det derfor være enighet om måten å måle på og denne skal være kommunisert med alle relevante aktører i prosjektet, ikke minst utførende.

Figur 1

Figur 2

3 Prosjektrettigheter og oppbevaringsplikt

I dette pkt. 3 behandles først og fremst rettighetene til de data som ligger i BIM: Eiendomsrett, bruksrettigheter, overdragelsesrett og forholdet til tredjemenn (3.1). Men også praktiske sider ved BIM-data omtales: Oppbevaring, skjermingsbehov og skytjenester (hhv. 3.2, 3.4 og 3.5). Endelig tar komiteen opp spørsmål om gjennomføring og dokumentasjon av den kommunikasjonen mellom partene som inngår i utviklingen av BIM-modellen (3.3).

3.1 Rettigheter

3.1.1 Reguleringsbehovet

Gjennom BIM sammenstilles store datamengder, som både underveis og i sin endelige modellform (PIM og AIM) er nødvendige for prosjektet. Men dataene kan ha verdi også i andre sammenhenger – i forlengelsen av prosjektet (eksempelvis ved drift, ombygginger, utvidelser eller rivning) eller helt utenfor (som grunnlag for tilsvarende bygg eller anlegg i regi av andre aktører). I alle disse situasjonene kan det oppstå interessekonflikter mellom aktører som har gitt innspill til BIM. Det er derfor behov for å regulere rettighetene til dataene.

3.1.2 Reguleres hvor?

Rettighetsspørsmålene hører hjemme i kontraktsvilkårene. I vedleggene bør tekniske sider av formater, faser, modenhetsnivåer etc. defineres. Noe kan kanskje også egne seg for en viss standardisering.

3.1.3 Nødvendige inndelinger

I reguleringen synes det nødvendig å skille mellom

• rettighetsobjekt

- komponenter av underlagsinformasjon (f.eks. objekt-bibliotek, saklig avgrensede deler av prosjektering eller sammenstilling, osv.)

- sammenstillingen i et endelig produkt («ferdig BIM»)

- mellomstadier (definert f.eks. som modenhetsnivåer eller som input til andre aktørers arbeid)

- midlertidige objekter (eksempelvis forskaling og veier for inntransport): Bestiller må vurdere om slike forhold også skal fremgå av sluttleveransen, eksempelvis fordi han antar at det midlertidige kan bli permanent (bakkerigg).

- type informasjon («uttegnet» prosjektering vs. kommentarer, underliggende beregninger, osv.)

- «tilleggsinformasjon», dvs. informasjon ut over det som er nødvendig for å levere i henhold til kontrakt: Se 1 nedenfor.

• rettighetsinnhold

- rett til å få utlevert (i viss form)

- rett til å bruke informasjonen/sammenstillingen på nærmere angitt måte evt. innen angitt tidsramme (fri bruk for hvilket som helst formål innenfor prosjektet, bruk begrenset til FDVU tilknyttet kontraktsobjektet, bruk utenfor prosjektet osv.)

- rett til å overdra til andre (evt. for begrensede formål)

- avgivers fortsatte rett (ubegrenset, bortfalt eller mellomløsning)

- rettighetens varighet

- vederlag for rettigheten

Reguleringen av disse forholdene må baseres på bl.a.

a) klassisk interesseavveining mellom bestiller og leverandør.

Det må sees på både bestillers behov for bruk og leverandørenes videre bruk. Der objektene er utviklet av prosjekterende selv på forhånd eller underveis, vil konsekvensen av at bestiller får eiendomsrett (uten at leverandør får bruksrett) i sin ytterste konsekvens være at leverandøren må betale bestiller for bruk av de samme objektene i senere prosjekter. Dette vil fordyre prosjekter generelt, og vanskeliggjøre bruk av kunnskap og besparelser.

Bestiller nyter gjerne selv godt av slike besparelser ved at leverandørene benytter objekter man tidligere har utviklet. Det vil være en fordel for bestiller og bransjen at leverandøren kan benytte erfaringer, metoder, objekter fra et prosjekt, i alle nye prosjekt de engasjeres i. Dette driver bransjen fremover. Dersom leverandøren forhindres fra å bruke en god løsning som er utarbeidet i et prosjekt for bestiller A i et senere prosjekt for f.eks. bestiller B, vil dette virke kostnadsdrivende. Bestiller kan på sin side ha et behov for å kunne gjenbruke informasjon, erfaringer, metoder og objekter fra et tidligere prosjekt i et annet prosjekt med andre leverandører.

De nevnte forhold har generell relevans, men får ofte økt aktualitet i BIM- sammenheng.

Et mer spesifikt BIM-eksempel er at leverandørene vil ha behov for å unngå spredning av materiale av konkurransemessige hensyn eller som leverandøren har brukt betydelige ressurser på å utvikle. Når man lager BIM- modeller bygger man disse opp av objekter (byggeklosser). De fleste av disse objektene er forholdsvis enkle og lite konkurransesensitive (søyler, bjelker, stikkontakter etc). Noen objekter kan derimot være svært sofistikerte. Det vil si at man kan ha avanserte objekter i modelleringsverktøyet (Revit,Tekla etc) som ved å angi noen få parametere (verdier), gjerne kalt parametrisk design, får opp større konstruksjoner/bygg. Dette er noe som kan være et konkurransefortrinn for det enkelte firma og firmaet kan ha benyttet store ressurser til å utvikle disse. Dersom man konverterer til åpen BIM (IFC) kommer geometrien over, men smartheten i avanserte objekter blir ikke med. Dersom man derimot sender fra seg det proprietære formatet (Revit, Tekla etc) gir man fra seg eventuelle smarte objekter, hvilket kan være konkurransemessig skadelig for leverandøren.

Her er det minst to forhold som bør betraktes. Det første gjelder retten til bruk av objekter i den delte eller publiserte modellen i motsetning til objekter i leverandørens, utstyrsleverandørens, programvareleverandørens, bestillers eller entreprenørens objektbibliotek. Her kan bestiller ha retten til bruk av alle objekter i modellen, men kan ikke kreve objekter fra proprietære objektbiblioteker. Det andre gjelder retten til bruk av objekter innen prosjektet i motsetning til retten til bruk av objekter i andre prosjekter. Bestiller vil sjelden ha interesse i å gjenbruke proprietære objekter i andre prosjekter da det er deres rådgivere, som alle har egne biblioteker, som utvikler modellen i andre prosjekter. Det bør avklares om retten til bruk av objekter gjelder som underlag av utvikling av modell i en senere fase. Det kan f.eks. gjelde senere prosjektering av en ombygging eller et tilbygg hvor det er andre rådgivere som utfører den nye jobben enn de som prosjekterte underlaget.

Hvis leverandører har konkurransesensitiv metodikk innebygget i objekter som de ikke vil dele eller publisere, må det finnes løsninger på hvordan de kan levere en proprietær modell med grunnleggende parametri bevart uten at deres konkurransefortrinn avsløres. Men her er det en balansegang mellom

ulike interesser. Både kunde og leverandør har interesse av å tilrettelegge for innovasjon og konkurranse blant leverandørene.

b) tredjemanns rettigheter

til eksempelvis programvare, substansinnhold, herunder objekt-bibliotek og bearbeidelse gjennom prosjektering, vil være en praktisk begrensning som må vurderes og hensyntas ved fastleggelsen av reguleringen av prosjektrettighetene knyttet til BIM i standardkontraktene.

Rådgivere og arkitekter benytter i dag flere ulike programmer ved sin prosjektering. Felles for disse er at prosjekterende selv normalt kun har lisens til å bruke programmet. Eiendomsrett og øvrige rettigheter ligger hos programvareleverandøren. Prosjekterende har i disse tilfeller ingen praktisk mulighet til å gi sine kunder større rett enn de selv har, typisk eiendomsrett.

En rekke av programleverandørene er store internasjonale leverandører med sine standard vilkår, uten rom for forhandling av tilpasning av vilkår til den enkelte norske bestiller.

Et eksempel som illustrerer dette, er bruken av objektbibliotek. Rådgiverne benytter som regel objektbibliotek hvor rådgiver dels har utviklet objekter selv, og dels henter objekter fra programvareleverandøren eller utstyrsleverandørene. Bibliotek fra programvareleverandør og utstyrsleverandør har rådgiverne ikke eierskap til. Rådgiverne har dermed ingen mulighet til å overføre bedre rettigheter til slike biblioteker enn det som fremgår av lisensavtalen. Bestiller er på sin side i utgangspunktet ikke interessert i biblioteker, men i objekter som omfattes av de modeller som er utviklet i prosjektet. Hvis et objekt i en modell er hentet fra en programvares bibliotek, selv uten endringer, så er denne ikke lengre en del av biblioteket, men av modellen som bestilleren har betalt for. En måte å sikre dette på er at bestiller selv bruker proprietære modeller i samme programvare som leverandøren og som bestiller selv har betalt lisens for. Bestiller har dermed tilgang til samme standard objektbiblioteker (tredjemanns) som leverandøren. Men spørsmålet er aktuelt der bestiller ikke har samme lisenser som leverandøren eller ønsker en annen bruksrett (eller eiendomsrett) i eller utover prosjektet. En illustrasjon på denne problemstillingen er vilkårene fra to programvareleverandører som er inntatt i Vedlegg 2.

c) rettighetskonsekvenser av at forskjellige aktører har opphavsrett til forskjellige elementer som samspiller i modellen (sammensatte verk eller fellesverk).

d) muligheten for at det i kontraktsperioden foretas utskiftninger av aktører som bidrar i utviklingen av BIM.

e) reguleringen av rettigheter må ta i betraktning ansvars-spørsmålene:

Kan den som har plikt til å avgi noe holdes ansvarlig for alle/noen feil i det som avgis, evt. også for følgefeil (omfanget beror på omfanget av bestillers rettigheter)? Disse spørsmålene behandles i pkt. 4 nedenfor.

3.2 Oppbevaring

3.2.1 Grunnleggende

Det er behov for å oppbevare sluttresultatet av BIM-arbeidet, men også stadier underveis frem dit. Skal oppbevaringen ha noen hensikt, må den følges av en rett og praktisk mulighet til å nyttiggjøre seg informasjonen. Her kan det ligge utfordringer, siden programmer vanligvis ikke garanteres tilgjengelig i mer enn 3 år, og brukslisenser uansett må fornyes. Det er derfor nødvendig å oppgradere prosjektinformasjonen til nye programvareversjoner etter hvert for å bevare praktisk tilgang, og tilsvarende fornye lisensene. Kontrakten bør (i vedlegg) regulere hvem som skal sikre at informasjonen er tilgjengelig på oppdatert versjon av programvaren i hele perioden kravet til oppbevaring gjelder.

Oppbevaringen kan svikte pga. feil ved arrangementet (skyløsning, programvare). Ansvar og risiko for slike forhold må fastlegges.

3.2.2 HVA skal oppbevares?

Den avtalte leveranse – eller deler av den – skal gjerne oppbevares i en viss tid på en viss måte. Også stadier i utviklingen av modellen kan tenkes å skulle oppbevares.

Dette må kontrakten gi bestemmelser om, se 3.2.3 – 3.2.5 nedenfor. Oppbevaring av annet materiale skjer i partens egen interesse, uten kontraktsregulering. (Men kontrakten kan tenkes å legge bånd på bruken av slik materiale.)

Det må særskilt tas standpunkt til (hvilke deler av) BIM-relatert kommunikasjon (valg, samtykker, pålegg osv.) underveis i utviklingen av modellen som skal oppbevares, i hvilken form og med hvilken tilgjengelighet der den ene parten ikke uten videre har tilgang til informasjonen.

3.2.3 HVEM skal oppbevare det?

Kontrakten må ta standpunkt til hvem som har plikten til å sørge for oppbevaring, og om vedkommende må rådføre seg, evt. søke samtykke fra, den annen part mht. de valg som må gjøres og som ikke enkelt kan legges inn i kontrakten.

Oppbevaring som betinger lisenser mv, har en kostnads- og rettighetsside som kan innebære andre utfordringer enn tradisjonell lagring av papirkopier/pdf-filer.

Hvis tredjemann (skyleverandør) står for den faktiske oppbevaring, må det fastlegges hvem som kan kreve utlevering av dataene, herunder hva som skal skje ved opphør, konkurs, overdragelse til annen virksomhet osv.

3.2.4 HVORDAN skal det oppbevares?

Sluttproduktet, dvs. den avtalte leveranse (modellen), kan tenkes oppbevart utelukkende digitalt eller (også/delvis) på papir. Det kan følge ytre rammer av eksempelvis arkivloven (offentlige bestillere) og GDPR. Innen disse rammer må det fastlegges oppbevaringsformater (herunder ansvar for opprettholdelse av nødvendige lisenser) og oppbevaringssted, herunder hvorvidt oppbevaringen skal skje på servere innen angitte geografiske områder.

3.2.5 HVOR LENGE skal det oppbevares?

Praktiske rammer kan her følge av programvareoppdateringsfrekvens og lisenser, se

3.2.1 ovenfor. Men partene bør også selv sette en tidsramme, gjerne kombinert med bestemmelser om rett til utlevering og til å kreve sletting.

På alle punkter 3.2.3 – 3.2.5 må det knyttes ansvar til manglende etterlevelse av pliktene. Dette må ivaretas ved en fanebestemmelse i kontraktsvilkårene, mens det er en oppgave for generell standardisering å utvikle maler for oppbevaringsplikter.

3.3 Særlig om lagring av saksbehandlingsinformasjon

3.3.1 Dataeier vs. tjenesteleverandør

For å beskrive problematikken rundt lagring av prosjektinformasjon generelt kan man f.eks. se for seg at en bestiller stiller med eget system for saksbehandling, noe som ikke er uvanlig. I slike systemer vil man finne muligheter for å lagre alt fra rene dokumenter til informasjonsobjekter og metadata. Systemene lagrer også systematikken rundt saksbehandlingsprosessen (arbeidsflyt). Tradisjonelt sett er ikke dette noe nytt. Vi finner systemer som Proarc eller tilsvarende som utgjør nødvendige funksjoner for å dokumentere hvem som gjør hva i et prosjekt, og som slik sett har en viktig juridisk funksjon. Ved introduksjon av nye arbeidsmetoder og kommunikasjonsformer, gjerne i form av skytjenester og programvarer som snakker sammen gjennom API-er, oppstår det enda flere usikkerheter. De fleste BIM- programmer gir brukere mulighet til å kommunisere seg imellom, enten direkte i programvaren eller i tilliggende samhandlingsløsninger. Noen former for kommunikasjon foregår på proprietære plattformer og formater, mens andre skjer på åpne dokumenterte formater, API-er og plattformer for eksempel BIM Collab, en serverbasert samhandlingsplattform basert på BCF (BIM Collaboration Format). Slike samhandlingsverktøy kan ikke defineres som fullverdige saksbehandlingssystemer slik disse opptrer i dag.

Figur 3 – Eksempel på et saksbehandlingssystem (StreamBIM – Xxxxxx City)

Det finnes prosjekter der involverte med behov for tilgang til relevant informasjon, ikke får tilgang til slikt med henvisning til sikkerhet og andre plausible grunner.

Eksempler på utfordringer

- Ansvar for lagring og «konservering» av prosjektdokumentasjon, leverandør versus prosjekteier

- Oppdatering av programvareversjon for slike systemer vs riktigheten, i og med at feil også kan inntreffe ved oppgraderinger av slike systemer

- Langtidsgaranti for bindinger mot objekter i modell

- Varighet på slik informasjon på lang sikt, ved f.eks. garantiforhold

- Hvem eier dokumentasjonen

- Hvem styrer tilgang til slik informasjon

3.3.2 Lagring av kommunikasjon, kort og lang tid

Ofte ser vi at slike systemer for kommunikasjon bare opptrer i en gjennomføringsfase av et prosjekt. Når denne fasen er over, blir systemene mer eller mindre lagt døde.

Over tid vil manglende fokus på systemene medføre at datakvaliteten forringes, for til slutt å bli ubrukelig i f.eks. en garantisammenheng. Eksempelvis kan morgendagens chat-funksjon være organisert på måter som gjør at data fra dagens chat ikke lar seg meningsfullt lese.

Utfordringene kommer gjerne som en konsekvens av overgang til slike kommunikasjonssystemer fra formelle prosesser, gjerne med notater / utredninger med eventuelle dokumenterte revisjoner, som grunnlag for beslutninger.

Eksempler på utfordringer

- Ingen tar ansvar for å følge opp tilganger til dataene

- Tilstand på innhold blir ikke vedlikeholdt – og forfaller over tid

- Lisenser avsluttes

- Databasene avsluttet og slettet i tråd med en eller annen klausul i kontrakten med leverandøren

Det bør vurderes å ta inn regulering som forhindrer at datatilgangen forvitrer.

3.4 Særlige skjermingsbehov

Kontrakten må identifisere og regulere de særlige skjermingsbehov bestiller måtte ha, eksempelvis tilknyttet en bygnings sikkerhetsnivå. Slike krav hører naturlig hjemme i vedlegg. Bestiller må vurdere og redegjøre for hvordan leverandørene skal få oppfylt krav i. f.eks plan- og bygningsloven til oppbevaring av dokumentasjon.

Dette er et mulig emne for standardiseringsarbeid.

3.5 Særlig om skytjenester

Bruken av skybaserte tjenester (cloud) har steget i både privatmarkedet, næringslivet og det offentlige. Mens data tidligere gjerne var lagret på lokale servere på kontoret, kan man nå sette lagring ut som en tjeneste til andre aktører. Skybaserte tjenester innebærer at informasjonen lagres på desentraliserte servere og som regel på flere forskjellige servere, i forskjellige land, og hvor det lagres data for flere kunder.

Innenfor bygg- og anlegg har overgang fra filbasert til modellbasert prosjektgjennomføring ført til en endring av arbeidsmetodikk og samhandlingsmønstre. Modellene er vesentlige større enn de tidligere modellfilene, og beregninger utføres direkte i modellene. Dette har igjen medført nye krav til lagringskapasitet, tilgang til eksterne databaser, fildeling og regnekapasitet. Kravene til teknologi knyttet til infrastruktur, maskinvare og programvare øker eksponentielt og programvareleverandørene har endret sin strategi for å etterkomme de nye kravene.

Skybaserte tjenester brukes innen BIM i dag til:

- Distribuering av programvare

- Kjøring av programvare

- Håndtering av lisenser

- Lagring av prosjektdata

- Lagring av ulike databaser

- Samhandling mellom prosjektaktører

Det særegne for bruk av de skybaserte tjenestene er at det benyttes en tredjepartsleverandør utenfor prosjektet. Dette reiser særskilte spørsmål om bl.a.:

- Risiko for manglende eller forsinket tilgang til skytjenestene

- Risiko for feil eller tap av data i skyen

- Eierskap eller rettigheter til informasjonen i skyen

- Tilgang til informasjonen under og etter prosjektets sluttførelse

- Vedlikehold av informasjonen i skyen

- Jurisdiksjon knyttet til informasjonen i skyen

Skybaserte tjenester med lagring domineres i dag av tre store internasjonale leverandører hhv: Microsoft, Google og Amazon. Felles for disse og andre leverandører er at de har standardvilkår for bruk av sine tjenester som det ikke er praktisk mulig å få forhandlet endringer i. Dette skyldes dels skyleverandørenes størrelse og stilling. Dels skyldes det at

«billig» skylagring er basert på «hyllevare» hvor brukerne har like avtaler/rettigheter.

En rekke utfordringer ved bruk av skytjenester er omtalt i notat fra 2019 utarbeidet av RIFs BIM-gruppe som er vedlagt denne rapport som vedlegg 3.

4 Ansvar

Ansvarsspørsmålene er et viktig og krevende punkt som må reguleres i kontraktsvilkårene. I

4.1 drøftes enkelte generelle spørsmål tilknyttet ansvar ved «feil» i BIM, mens 4.2 gir enkelte praktiske eksempler på situasjoner der slike ansvarsspørsmål kan oppstå. Hvis modellen brukes til andre formål enn opprinnelig tenkt, kan det oppstå særlige ansvarsspørsmål uten at det kontraktsmessig foreligger noen «feil» i modellen. Disse situasjonene behandles i 4.3.

4.1 Ansvar for feil/avvik i BIM

Kontrakten angir hvilke krav som stilles til leverandørens ytelser. Dette gjøres først og fremst gjennom beskrivelsen av prosess/ytelse i vedleggene, se pkt. 2 over. Men disse kravene kan i praksis aldri være uttømmende og helt detaljerte. De suppleres derfor av «alminnelige krav til god ytelse», altså hva parter i bransjen jevnt over anser som krav til god ytelse når annet ikke fremgår av kontrakten. Slike supplementer kan være nedfelt i standarder som kontrakten direkte eller implisitt henviser til. Men det kan også hende at kontrakten ikke viser til slike supplerende kilder, eller at holdepunkter for «alminnelig god vare» ikke er nedfelt i standarder.

Hvis leverandørens ytelse ikke oppfyller disse kravene, foreligger det et «avvik» eller en

«feil». Konsekvensene av dette kan være at leverandøren for egen regning må utbedre ytelsen. Men det er vanligvis mer alvorlig hvis han kan i tillegg holdes ansvarlig for de økonomiske konsekvensene av avviket. Disse konsekvensene kan være omfattende når avviket gjelder BIM-relaterte ytelser. Det er derfor viktig å regulere vilkårene for og omfanget av slikt ansvar.

4.1.1 Feil i modellen

Feil kan forekomme uansett om prosjektet er tegnings- eller BIM-basert.

I alle prosjekter er det viktig å avtale detaljerte ytelser og prosess, samt avstemme forventningene til leveransene. Ved bruk av BIM, f.eks. som produksjonsunderlag, er dette av særskilt betydning. Dette fordi oppfatningene og forventningene til en «BIM- modell» er forskjellige og i bevegelse. Komiteen har i pkt. 2 over belyst hvilke krav som bør stilles og hvordan det kan gjøres. Det er viktig at kravene er mest mulig klart definert. Xxxxx fra disse kravene kan gi grunnlag for ansvar, som er det som her behandles.

Man kan tenke seg mange typer «feil» i BIM, eksempelvis:

- Feil ved innlegging av basisinformasjon (eksempelvis feil i overføring av leverandørinformasjon om komponenter). Her kan konsekvensene bli store, og det kan være vanskelig å fastslå hvordan feilen oppsto.

- Feil ved overføring av et generisk objekt til et faktisk, bestillbart produkt.

- Manglende informasjon iht. krav. Enten manglende geometri eller manglende informasjon knyttet til geometri.

- Kollisjoner. Ikke alle kollisjoner er nødvendigvis feil. Det kommer an på hvilken detaljering man har avtalt. Eksempelvis trenger ikke mindre elektro

trekkerør å være kollisjonsfritt. Her er man tilbake til om håndverkeren skal bruke sin fagkunnskap eller om man kun har en ufaglært montør.

- Manglende byggbarhet.

- Bygget/anlegget tilfredsstiller ikke kontraktens krav (dvs. at det blir

«mangelfullt» med tilhørende kontraktsvirkninger).

- Driftsproblemer: Prosjekteringen og modellen ivaretar ikke driftshensyn slik kontrakten forutsetter.

- Uoverensstemmelser mellom modell, beskrivelse og tegninger.

BIM innebærer ofte at prosjektering utføres av flere aktører parallelt. Forventningen er at dette er tidsbesparende og kostnadseffektivt. Slike fordeler kan utvilsomt oppnås, men forventningene kan også vise seg urealistiske. En vesentlig fare ligger nettopp i at virkningene av feil kan bli store når prosjekteringen gjøres parallelt og følgelig uten de «tersklene» som ligger i en «rasjonell prosjekteringsprosess», se Vedlegg 1. Her ligger det utfordringer som må tas i betraktning ved ansvarsreguleringen, men enkelthetene hører trolig hjemme i vedlegg, ikke i kontraktsvilkårene.

4.1.2 Ansvaret for feil

Kontraktsvilkårene må regulere ansvaret for feil i BIM. Bl.a. må man fastsette rekkevidden av ansvar for konsekvenser av feilen (direkte og indirekte følger), og fordeling av tidskonsekvens. Dette forutsetter gjennomtenkning av hva som skal anses for å utgjøre en «feil» i BIM (se også ingressen til 4.1 over). Spørsmålet må besvares på grunnlag av ytelsesbeskrivelsene, som kan ha elementer av både funksjonskrav og metodekrav. Men spørsmålet har også prinsipielle sider som må vurderes ved standardisering av reguleringen i kontraktsvilkårene.

Et trekk ved BIM er at interaksjonen mellom aktørene under utviklingen av prosjektet ofte er mer kompleks og sammenvevet enn i tradisjonell prosjektering mv. Særlig vil parallell prosjektering kunne ha slike virkninger, se 4.1.1. På den annen side kan bidragene fra de enkelte aktørene være mer sporbare pga. dataloggene, riktignok avhengig av programvare og lisensvilkår. Samlet er derfor både faktum og (derfor) ansvarsforholdene oftest mer oversiktlige under BIM. Men GDPR kan her tenkes å sette grenser for sporbarheten, selv om loggene oftest registrerer på firmanivå, ikke på individnivå.

Utfordringen synes derfor å være å sikre presis

- regulering av dette ansvaret (alminnelig behov, ikke særskilt for BIM, men bør være forankret i festnet oppfatning om hensiktsmessige løsninger i lys av BIM-praksis)

- dokumentasjon gjennom utnyttelse av datalogger for hvilke bidrag som baserer seg på hvilke innspill og hvilke konsekvenser feilen har ført til (særskilt for BIM, krever forståelse av prosessen).

Slik regulering må hvile på klarest mulig angivelse av de enkelte aktørers funksjoner og samspillet mellom dem i utviklingen av BIM, se komiteens anbefalinger i pkt. 2 over.

Feil i den programvare partene bruker, reiser særlige risiko- og ansvarsspørsmål. Det bør vurderes å regulere ansvar for bruk av programvare. I følge NS/EN ISO 19650-2 punkt 5.3.2 og 5.4.2 skal det medfølge en foreslått liste over programvare som del av tilbyders tilsvar til anbudsforespørselen og som bekreftes av bestiller som del av kontrakten.

4.1.3 Noen typefeil

Det finnes enkelte typisk feil man bør vurdere å regulere særskilt:

- feil ved eksport/import

- feil i programvare (hos én aktør)

- feil og nedetid i skytjenester

- feil i nettilgang generelt (brannmurer, spam-filter, båndbredde – jfr. identifisert kapasitetsbehov for effektivt nettbasert arbeid)

4.2 Eksempler på at originalmodell endrer tilstand

Med endret tilstand menes at modellen i sin foreliggende form ikke uten tiltak kan benyttes videre i prosjekteringen. Forårsaket av flere scenarioer, eksempelvis at originalmodellfiler;

- ikke kan åpnes med tilhørende programvare, grunnet «sammenbrudd» - korrupte filer

- kan åpnes, men bare etter utført «automatisk» feilretting

- kan åpnes, men inneholder undertrykkede feil

- kan åpnes, men ikke oppgraderes grunnet avhengigheter til 3. parts plugins

- kan åpnes, men ikke benyttes grunnet avhengigheter til egenutviklet programvare I det påfølgende beskrives eksempler og konsekvenser.

4.2.1 Korrupte filer

Hva som forårsaker feil i databasen for BIM-modellen kan være relatert til mange forhold, alt fra regelrette brukerfeil, feil i dataflyt / synkronisering i nettverket eller over internett, feil i programkode, feil i tilliggende materiale/databaser (f.eks. importert/linket underlag), virus osv. Det er også registrert feil der deler av modeller har forsvunnet uten at det har blitt fanget opp og man har jobbet videre i en periode.

Ofte vil man kunne konkludere med at kilden til, og dermed ansvar for feilen, ligger hos leverandøren av programkoden og i mindre grad brukerfeil.

Eksempler på feilmeldinger (dette er IKKE unikt for denne programvaren/programvareleverandøren);

Figur 4

Eksempler på utfordringer:

- Tap av utført arbeide

- Tidstap for øvrige parter i prosjektering / prosjekt / bygging

- Vanskelig å plassere ansvar for feil på riktig sted

- Latente / ikke utløste feil i modeller kan føre til at man jobber aktivt på et underlag som kan vise seg å ikke være riktig

- Modeller lar seg ikke nedgradere, dvs. lagres som tidligere versjon

- «Worst case» scenario er at modeller må etableres helt på nytt (remodelleres), med de konsekvenser dette måtte innebære.

4.2.2 Feilretting

Felles for disse situasjonene er at modellen må gjennomgå en prosess (gjerne automatisk, og derfor lite oversiktlig og forutseelig) knyttet til feilretting, for i det hele tatt å kunne benyttes videre i prosjekteringen. Enkelte slike opprettinger kan utføres av operatøren/brukeren selv, noen av support/kompetanse hos selgende leverandør, mens noen modeller må oversendes programvareleverandøren for oppretting.

For enkelte modeller vil konklusjonen være at disse ikke kan rettes opp og man må

«rygge» tilbake og hente frem sikkerhetskopier av tidligere fungerende versjoner. I en automatisk «audit» / «repair» av modeller er det behov for å kjenne til

- hva som forårsaket feilen

- hva som gjøres av rettinger i modellfilene i en automatisert prosess

- hvordan modellen opptrer som korrigert modell

- hvilken påvirkning slike endringer inne i modellen fører til utenfor modellen

Brukeren er i all hovedsak avskåret fra å vite eksakt hva som skjer i slike reparasjonsprosesser. Man får gjerne tilgang til dialoger og loggfiler som viser resultatet av prosessen, men tolkningen av dette er ikke mulig for operatøren/brukeren.

Eksempler på utfordringer:

- Tap av utført arbeide dersom man må «rygge tilbake» til tidligere sikkerhetskopi

- Usikkerhet knyttet til innhold i modeller – både geometri og informasjon

- Usikkerhet knyttet til videre bruk av modeller – er feilen reelt sett borte

- Stopp i modellering og tidstap for fagteam, mens feilretting utføres

- Stopp vil kunne påvirke egen og andre fag sin prosjektering

- «Cross over»-feil påvirker prosjektering hos ett eller flere andre fag

- Stopp i prosjektering vil kunne føre til forskyvning i leveranser ut mot andre parter, f.eks. til bestiller, prosjektledelse, byggeplass etc.

4.2.3 Undertrykkede feil

Under kontroll av modellen vil programmet rapportere en mengde feil. I større modeller er det ikke uvanlig at det finnes mange tusen slike feil. Retting av slike kan fremstå som en nærmest «uendelig» pågående prosess for å holde dette på et så lavt nivå som mulig. I programvarer for BIM er det mulig å undertrykke feil i databasen, gjerne feil klassifisert som «ubetydelig» men likefult klassifisert som feil.

Utfordringen er imidlertid også at det ligger en opsjon i programvaren på at feil er mulig å akseptere og også kan undertrykkes og skjules for operatøren/brukeren.

Eksempler på utfordringer:

- Usikkerhet knyttet til hva feilen innebærer for videre / fremtidig bruk av modellen

- Usikkerhet knyttet til hva slike feil potensielt kan forårsake av andre problemer

- Usikkerhet knyttet til ansvar for feilen nå den først er synliggjort, gjort aksepterbar av programvareleverandøren og til sist akseptert beholdt av operatøren

4.2.4 Avhengigheter til 3. parts plugins (apper)

De fleste av de store og dominerende BIM-program som benyttes i dag åpner for, og er til dels avhengig av, 3. parts programvarer for å utøve detaljert og spesialfaglig prosjektering. Et eksempel kan være prosjektering av tekniske fag basert på nasjonale regelverk / standarder, der slike spesifikke regelverk kun er mulig gjennom tilliggende spesialprogrammer.

Dette skaper en kompleks avhengighet mellom hovedprogrammet og en «skog» av tilliggende programvarer /apper, for å kunne sammenstille prosjekteringen til en samlet BIM-modell. En avhengighet som naturlig nok også innebærer en rekkefølge i utvikling av programvaren, som igjen gir en rekkefølge i oppgradering av prosjektmodeller.

I noen tilfeller vil feil i 3. parts programvarer også kunne føre til feil i hovedprogramvaren som appen er tilknyttet.

Eksempler på utfordringer:

- Usikkerhet knyttet til muligheter for oppgradering av modeller

- Usikkerhet knyttet til hvorvidt lisenser er kompatible bakover i tid på lisenser (noen lisenssystemer dekker bare 3 år bakover i tid).

- Usikkerhet knyttet til ansvar for feil i hvilken programvare (man kan også se for seg at feilen er utløst av feil i begge programmer)

- Stopp i muligheter for oppgradering

- Oppgradering utføres, feil kommer til syne etter oppgradering, må rygge tilbake

- Stopp i leveranser

4.2.5 Avhengigheter til egenutviklet programvare

I svært mange tilfeller, gjerne større prosjekter, utvikler prosjekterende og andre aktører tilknyttet prosjektene direkte både programvare og automatiserte prosesser (skript), som i sin tur bidrar til effektivisering av prosjektering. Et eksempel kan være bøyelisteprogram for armering. Disse kan både stå helt alene som frittstående program / skript eller ha avhengigheter til både hovedprogram og 3. parts programvarer på samme tid.

Også slike løsninger er gjenstand for programvarefeil, internt i eget program og som utløsende årsak til feil i andre program. I tillegg skaper slike løsninger også avhengigheter av en egenutvikling av programkode som også følger tilliggende programvarers utvikling / progresjon.

Typisk er dette relatert til eksempelvis generative designprosess (en kombinasjon av parametrisk design, simulering og optimalisering, se figur nedenfor), automatisering av prosesser slik som eksport av filer, overføring av data og filer mellom forskjellige systemer osv. I noen tilfeller er slike prosesser avhengig av funksjonalitet helt ned på operativsystemnivå (MS Windows), skytjenester og «4. parts» utvikling av slike.

Figur 5 – Illustrasjon på generativ designprosess der man gjør bruk av parametere som kan endres slik at man kan simulere et utall forskjellige løsninger for å optimalisere løsning.

Eksempler på utfordringer;

- Utvikling av egen programvare / skript, for effektivisering, skaper en forventning om at slik effektivisering alltid skal skje.

- Stopp i slike programmer / skript, som igjen gir stopp i effektivisering

- Ansvar for feil i slik kode tilligger utvikleren av koden, og ved at utvikleren er direkte tilknyttet prosjektet kanskje ikke vanskelig å plassere

- Innføring av AI (kunstig intelligens) og ML (maskinlæring) innebærer ytterligere utfordringer med tanke på hvor ansvar for feil og mangler skal plasseres, når design kanskje er fremkommet som resultat fra en tjeneste fra skyen.

4.3 Ansvar for tilleggsinformasjon og bruk utover avtalt formål

Det er i bestillers og leverandørs felles interesse at leveransen tilfredsstiller bestillerens krav og spesifikasjoner, og at innholdet er kvalitetssikret og dermed kan benyttes som forutsatt. Dette krever noe av begge parter.

Bestiller bør gjøre bestillingen så presis som mulig når det kommer til hvilke formater de ønsker, til hvilke tidspunkt det skal leveres og til hvilket formål informasjonen skal benyttes. I tillegg må de spesifisere hvilke krav som skal gjelde for BIM-modellen, men på en slik måte at ikke det ikke forhindrer innovasjon i hvordan modeller brukes til å oppnå avtalte ytelser og leveranser.

Leverandøren må på sin side tilpasse informasjonen og kvalitetssikre den opp mot det formål som bestiller har ønsket den benyttet til og de krav som er satt i prosjektet.

I noen prosjekter inneholde informasjonsleveransen mer informasjon enn det som er krevet frabestiller. Dette kan avstedkomme en rekke utfordringer knyttet bl.a. til ansvar, rettigheter (3.1), kvalitetssikring (2.2.4) m.m.

4.3.1 Rensing av modell og ansvar for tilleggsinformasjon

BIM-modeller som brukes til samhandling og oppdatering av status er dynamiske og utvikler seg gjennom prosjektets forskjellige faser. Stadig mer informasjon blir lagt inn i modellene og på objektene. Ikke all informasjon er like relevant til enhver tid eller er kommet like langt i modenhet og detaljering, se 2.3.4 a).

I den grad det er avtalt kan modeller leveres ryddet, slik at de er renset for tilleggsinformasjon.

Med tilleggsinformasjon menes informasjon som ikke er spesifisert eller bestilt av bestiller. Tilleggsinformasjon kan grovt deles inn i to kategorier.

Den første kategorien er informasjon som følger med BIM-objekter hentet fra ulik programvare (Revit, Tekla, ArchiCAD etc.) og som baserer seg på leverandørdata fra biblioteker levert av ulike leverandører.

Den andre kategorien er informasjon som etableres i tillegg til prosjektets BIM-krav, fordi det støtter behov i prosjektfasen uten å være del av de krevde leveransene. Det kan omfatte tekniske data, både fysiske kapasiteter og geometrisk informasjon, som størrelser, farger, materialer, brannkrav, lydkrav, isolasjonstykkelser etc. og som skyldes behov fra prosjekteringen og andre beslutningsprosesser for å sikre prosjektets omforente dataflyt, eksempelvis fordi dette skal jobbes videre med i et annet verktøy, se eksempel under. Dersom det skapes informasjon som alle har nytte av eller som skal jobbes videre med, bør det diskuteres om det skal inn i prosjektets BIM-krav.

Figur 6 – Eksempel på egenskaper knyttet til dørobjekt

Den første kategorien tilleggsinformasjon er programvarespesifikk og kan inneholde verdier som ikke er aktuelle for det enkelte prosjektet. Denne informasjonen kan man derfor ønske å fjerne i en eksport. Den andre kategorien tilleggsinformasjon er som regel ønskelig, mens prosessene som trenger informasjonen pågår, og skal delvis eksporteres i ulik mengde, i ulike faser, tilpasset prosjektets modenhet. Det er en utfordring å ha kontroll på hva som skal eksporteres kombinert med krav til høyere detaljering og mer omfattende dataleveranser. Dette gjør rensing av modell ressurskrevende.

I et stort og komplekst prosjekt kan det være flere BIM-modeller som til sammen kan inneholde noen millioner av objekter og som hver har en mengde mulige datafelt knyttet til seg. Eksempelvis vil en dør alene ha mulighet for opptil 100 datafelt. For komplette modellsamlinger i større prosjekt kan det være snakk om titalls millioner av data.

Korrekt informasjon er sentralt for prosjektene uavhengig av om informasjon ligger i modell eller andre steder. Feilinformasjon vil kunne skape usikkerhet om bruk av informasjon i modellen. Om og hvor mye det bør renses og kvalitetssikres vil variere med prosjektet, fasene og hva modellen skal brukes til. Ulike bestillere vil også ha ulikt behov og betalingsvillighet for rensing av tilleggsinformasjon.

Ved regulering av tilleggsinformasjon bør det skilles på om informasjon deles i gjennomføringsfasen eller ved sluttleveranse/prosjektets avslutning.

a) I gjennomføringsfasen

Underveis i prosjektet publiseres eller utveksles fag-/fellesmodeller som underlag for diskusjon, som underlag for andre fags prosjektering eller som underlag for bestillinger. Disse utvekslingsmodellene vil inneholde informasjon som er utviklet til ulikt nivå og informasjon som ikke vil være relevant på tidspunktet eller for formålet. For utvekslingsformål er det gjerne ikke hensiktsmessig å bruke ressurser på å fjerne slik informasjon. Prosjektet bør avtale, f.eks. i en BEP (2.3.3) eller et BIM-følgeskriv, hva modellen kan/ikke kan benyttes til eller hva som er til diskusjon/kan bygges videre på, samt statussetting av informasjon (2.5) for å vise modenhetsnivået på informasjonen.

b) Ved sluttleveranse/prosjektets avslutning eller avtalte milepæler,

For at leveransene ved prosjektets avslutning skal oppfylle bestillerens krav og kun inneholde kvalitetssikret og korrekt informasjon, må det foretas en rensing av modellen. Å gjøre en god rensejobb er ressurskrevende og krever også kompetanse.

Rensing av modell kan også være aktuelt ved milepælsleveranser i gjennomføringsfasen, i den grad bestiller ønsker å investere ressurser i slik rensing og det derfor er satt innholdsmessige krav ved milepæler.

Ved regulering av tilleggsinformasjon bør man være oppmerksom på de tekniske utfordringer som er knyttet til leveranser på åpent format (IFC) og proprietære formater. I noen prosjekter hvor det kreves leveranse på åpent format kreves det i tillegg leveranse på det formatet som modellen er utviklet i. Det kan være ulike formater for hver disiplin innen samme prosjekt.

Det finnes løsninger for rensing av modeller på åpent format, men det er eksempler på at det er vanskelig å kvalitetssikre den informasjonen som ligger der. Eksempelvis er det ikke alle mengder som kommer ut korrekt, eller der man forventer det.

Utfordringen med informasjon man ikke får styrt og ønsker å fjerne er derimot langt mer komplisert og gjør seg derfor i større grad gjeldende der proprietære filer inngår i krav til leveranse. Som illustrasjon kan nevnes noen eksempler fra faget rådgivende

ingeniør VVS. Der benyttes det mange komponenter som inneholder geometri og egenskaper som er parameterstyrt.

Disse komponentene inneholder dermed parametere som er av systemmessig karakter, produsert av BIM-programmet selv for "intern bruk" i programmet, som verken lar seg fjerne eller redigere og dermed også kan være vanskelig å kvalitetssikre i proprietære filer.

Figur 7 – Eksempel kanalbend

Figur 8 – Eksempel tilluftsventil

Disse eksemplene inneholder de parametere som vises i vanlig visningsmodus, men dersom man åpner selve komponenten i redigeringsmodus (Edit family i Revit), så vil det i enkelte tilfeller dukke opp enda mer, og som ikke er mulig å ta vekk:

Figur 9 – Eksempel på objektinformasjon i Revit

Figur 10 – Eksempel på objektinformasjon i Revit

c) Ansvar for tilleggsinformasjon

Kontrakten bør regulere kriteriene for plasseringen av ansvaret for feil i tilleggsinformasjon. Man kan eksempelvis tillate forbehold fra leverandør, knytte virkningene til hvorvidt det påvises uaktsomhet hos leverandør (eller bruker), statuere at «tilleggsinformasjon» ikke skal ha kontraktsmessige virkninger, osv.

Nivå på rensing og/eller kvalitetssikring for ulike typer utveksling (deling eller publisering) bør avtales i vedlegg og kan muligens også egne seg for en viss standardisering. Disse problemstillingene må også ses i sammenheng med bl.a. reguleringen av formålet med BIM-prosessen (2.1 ovenfor), rangordningen mellom informasjonsbærerne (2.4 ovenfor) og modenhetskriteriene og -kravene (2.5 ovenfor).

Kontrakten/vedlegg bør angi om bestillers krav er på formålsnivå, leveransenivå eller en kombinasjon av disse. På formålsnivå angis hva modellene skal brukes til (2.1), men ikke spesifikt hva som skal leveres. På leveransenivå spesifiseres hva som skal leveres av hvert fag ned på objektklasser, attributter, egenskaper og klassifikasjon for hver milepelsleveranse. Hvis bestiller både angir formål og leveranse skal en forrang mellom disse angis.

4.3.2 Ansvar for bruk til annet formål

Leverandøren kvalitetssikrer leveransen slik at den kan benyttes til de formål og krav som er nedfelt i kontrakten (2.1.1 og 2.2.4).

Både ytelsene under kontrakten og tilleggsinformasjon (4.3.1) kan tenkes benyttet til annet enn det angitte eller forutsatte formål, enten underveis i prosjektet (2.1.3.) eller etter endt prosjekt. F.eks. kan det tenkes at informasjon i en modell som er tiltenkt formålet bygging også kan benyttes til energiberegning, men uten at informasjonen er kvalitetssikret med tanke på dette formålet. Det kan også være at modellen enda ikke er på det modenhetsnivået som kreves for det tiltenkte formålet.

På samme måte som leverandøren kan ha vanskeligheter med å styre og kvalitetssikre informasjon fra visse av deres egne programvare, er det også vanskelig for bestiller i etterkant å vite hvilken informasjon som kan betraktes som tillegg til krav (dette gjelder især for proprietære leveranser og hvis bestiller har stilt krav på formålsnivå).

Digitaliseringen holder høyt tempo og ting som er utenkelige i dag kan være morgendagens muligheter. Modellene og informasjon som ligger i dem kan få andre anvendelsesområder.

Her oppstår det en potensiell interessekonflikt mellom bestillere og leverandører hvor bestillerne på sin side kan ha interesse i at deres bruk av modellene og informasjonen som ligger i de ikke begrenses, mens leverandørene på sin side må kunne kvalitetssikre informasjonen de gir fra seg for å ivareta sitt ansvar, både offentligrettslig og privatrettslig.

Dette skaper behov for regulering av rettigheter (3.1 ovenfor) og av ansvar dersom informasjon benyttes til annet formål enn det den var tiltenkt (2.1.1) og dermed heller ikke er kvalitetssikret for (2.2.4). Ansvaret bør reguleres i kontraktsvilkårene, og bør trolig nyanseres etter situasjonene.

Det vil i tillegg være naturlig å skille mellom utvidet bruk i det gjeldende prosjekt (se 2.1.3) eller ut over prosjektet.

5 Annet

I dette pkt. 5 tas opp temaer som ikke naturlig hører hjemme under de foregående hovedpunktene, men som utgjør en del av bakgrunnen for reguleringsbehov tilknyttet BIM.

5.1 Stansing, tilbakeholdelse

5.1.1 Stansing

Leverandørens rett til å stanse arbeidet ved manglende betaling: Beror på alminnelige kontraktsvilkår hvis det ikke lages særregel.

5.1.2 Tilbakeholdelse av ytelse

Leverandørens rett til å holde tilbake ytelse ved manglende betaling: Dersom prosjektering skjer på plattform som bestiller disponerer eller kontrollerer tilgang til og leveringen skjer suksessivt, vil leverandøren bare kunne tilbakeholde fremtidige ytelser for å fremtvinge betaling.

5.2 Kostnadsfordeling ved omfordeling av oppgaver

Med bruk av BIM kan det hende at det er aktører pålegges/påtar seg deloppgaver som tradisjonelt har vært håndtert av andre. Det kan også være at den som gir input til modellene ikke er samme aktør som høster «fruktene» av det. En jobb for én aktør kan bety gevinst for en annen. Dette reiser behovet for regulering av kostnadsfordeling på en annen måte enn hittil.

Eks. bøyelister utarbeides av rådgivende ingeniør bygg, mens kontrakten forutsetter at entreprenøren leverer dem. Det kan tenkes at bruk av BIM vil føre til at det blir flere omfordelinger av oppgaver, og at dette bør vurderes i en kontraktssammenheng. Dette må i tilfelle løses på basis av kontraktens krav til de respektive leverandørers ytelse sammenholdt med kontraktens endringsmekanisme.

Rapporten identifiserer følgende temaer som egnet for (delvis) regulering i kontraktsvilkår:

- 2.1.1: Formålet

- 2.1.3: Endring av formål

- 2.2.1: Hva skal leveres av leverandøren

- 2.2.4: Krav til kvalitetssikring

- 2.3.1: Generelt om kontraktskommunikasjon

- 2.3.2: Spesielt om BIM-relatert kommunikasjon

- 2.3.3: BIM gjennomføringsplan

- 2.3.4: Utvikling og revisjon av BIM-modellen i kontraktsperioden

- 2.4.1: Rangordning tegning – modell – beskrivelse

- 2.5: Prosesstatuskode

- 3.1: Rettigheter

- 3.2: Oppbevaring

- 3.3: Særlig om lagring av saksbehandlingsinformasjon

- 3.5: Særlig om skytjenester

- 4.1: Ansvar for feil/avvik i BIM

- 4.3: Ansvar for tilleggsinformasjon og bruk utover avtalt formål

- 5.1: Stansing, tilbakeholdelse

Komiteen har særlig sett på sider av BIM som er relevante for kontraktsregulering (i vilkår eller vedlegg). Men komiteen har samtidig kommet over temaer som antagelig kan være egnet for standardisering utenom kontraktsstandardene.

7.1 Generelt

På alle de punkter der komiteen anbefaler at man vurderer å foreta standardisering på annen måte enn i kontraktsvilkår, må det vurderes om det er hensiktsmessig å ta utgangspunkt i eksisterende standarder. Disse er først og fremst:

- ISO 19650-serien

- NS 8360-serien

- NS 3418

- NS 3420

- Prosesskoden

7.2 Spesifikke forslag (se pkt. 2-5 ovenfor)

Følgende emner kan trolig egne seg for standardisering utenom kontraktsstandardene:

- 2.2 Leverandørens ytelser

o 2.2.1 Hva skal leveres av leverandøren.

o 2.2.2 Digitalisert produksjonsstyring, fremdriftsmåling og sluttkontroll

o 2.2.4 Krav til kvalitetssikring.

- 2.3 Krav til kommunikasjon/samhandling

o 2.3.2 Spesielt om BIM-relatert kommunikasjon

o 2.3.3 BIM gjennomføringsplan

o 2.3.4 Utvikling og revisjon av BIM-modellen i kontraktsperioden

- 2.4 Rang/grensesnitt

o 2.4.1: Rangordning tegning – modell - beskrivelse

- 2.5 Prosesstatuskode

- 2.6 FDVU

- 2.7 Mengdeuttak og mengdekontroll

- 3.1 Rettigheter

- 3.2 Oppbevaring

- 4.3 Ansvar for tilleggsinformasjon utover avtalt formål

Document Metadata

Table of Contents

BIM: Behov for kontraktsreguleringer og generell standardisering

Document Metadata