Systematisk ferdigstillelse sikrer at de tekniske systemene virker når bygget eller anlegget skal tas i bruk. Denne guiden forklarer metoden, testhierarkiet og FMI-nivåene, viser hvordan systematisk ferdigstillelse henger sammen med commissioning, og hvem som har ansvar for hva.
Innhold
- Hva er systematisk ferdigstillelse?
- Systematisk ferdigstillelse og commissioning
- Hvorfor prosjekter feiler i sluttfasen
- De tre elementene
- V-modellen
- Slik gjennomføres systematisk ferdigstillelse
- Testhierarkiet
- FMI: modenhet per system
- FMI og Level-skalaen
- Roller og ansvar
- Overlevering og FDV
- Eksempler fra prosjekter
- Vanlige feil
- Systematisk ferdigstillelse i TaskCtrl
- Vanlige spørsmål
Hva er systematisk ferdigstillelse?
Mange byggeprosjekter blir ferdige uten at de tekniske systemene fungerer som de skal. Ventilasjonen styres ikke riktig, adgangskontrollen snakker ikke med brannalarmen, og feilene oppdages først når brukerne flytter inn. Systematisk ferdigstillelse er metoden som skal hindre dette.
Veilederen fra BA2015 definerer systematisk ferdigstillelse som en sikkerhet for at prosjektet oppfyller alle funksjonskrav innenfor gitte krav til tid, kostnad og kvalitet, planlagt og verifisert gjennom en strukturert prosess som er ledelsesstyrt fra planlegging til overtakelse.
Det viktigste ordet er prosess. Systematisk ferdigstillelse handler ikke bare om testene i slutten av prosjektet, men om veien dit. Arbeidet starter ved prosjektoppstart, med en plan som beskriver hvordan bygget skal fungere, og følger prosjektet gjennom prosjektering, bygging, testing, overtakelse og drift.
Systematisk ferdigstillelse og commissioning
Begrepene brukes ofte om hverandre. Commissioning er det internasjonale begrepet, og er særlig utbredt i industri, olje og gass og datasentre. Systematisk ferdigstillelse er den norske metodikken, beskrevet i veilederen fra BA2015.
Målet er det samme: at systemene virker, hver for seg og sammen, når anlegget settes i drift. Begge starter ved prosjektoppstart, med suksesskriterier for hva anlegget skal oppfylle. Forskjellen ligger i rollen. ITB-gruppen og prosjektorganisasjonen jobber gjennom hele prosjektet for å sikre at kriteriene blir ivaretatt. Commissioning er ofte en uavhengig tredjepart som i alle faser verifiserer at de faktisk blir det. Rollene utfyller hverandre, de overlapper ikke.
I internasjonale prosjekter er commissioning ofte delt inn i nivåer fra Level 1 til Level 5, med integrert systemtest som siste nivå. Noen prosjekter bruker en utvidet skala fra Level 0 til Level 7, der Level 0 dekker krav og planlegging i tidligfasen, og Level 6 og 7 dekker driftsklarhet og prøvedrift.
Hvorfor prosjekter feiler i sluttfasen
Ifølge veilederen er hovedårsaken til de mange feilene og manglene som avdekkes under avsluttende testing, at systematisk ferdigstillelse ikke har fått nok oppmerksomhet i prosjekteringen, kombinert med for lite kontroll underveis i byggingen. Veilederen peker også på at:
- Feil kvitteres ut som kvalitetssikret. Egenkontroll alene avdekker ikke alt.
- Løsninger prosjekteres uten å virke. Det oppdages ofte først under fullskala funksjonstester.
- Kontraktene styrer oppmerksomheten. Entreprenørene ser på egne forpliktelser, mens integrasjonen mellom systemer faller mellom stolene.
- Bransjen bygger først og kontrollerer etterpå. Når samme løsning gjentas mange ganger, bør første montasje testes før den rulles ut.
Erfaringer fra prosjekter peker i tillegg på:
- Uklare grensesnitt. Når grensesnittene ikke er definert, mangler beskrevet funksjonalitet og komponenter når systemene skal testes sammen.
- For sen forberedelse. Aktiviteter som kommer senere i prosjektet, blir ikke planlagt i tide. Det er sløsing av samme type som lean beskriver.
- Antakelser fra tidligere prosjekter. «Vi gjorde det slik der» blir planen, uten at kravene i dette prosjektet er sjekket.
- Fremdrift foran kvalitet. Fremdriften presses fortere enn kvaliteten klarer å følge. Datasentre er særlig utsatt.
- Kontrakter som ikke sikrer kompetansen. Kontraktene sørger ikke for at riktig kompetanse kommer inn i prosjektet, for eksempel en systemintegrator.
- Informasjon i siloer. Data ligger i ulike systemer som ikke synkroniseres og ikke blir vedlikeholdt.
De tre elementene
Veilederen beskriver tre elementer som må være på plass for at systematisk ferdigstillelse skal virke:
- Ledelse. Byggherre og prosjektledelse må forankre metoden fra start, sette mål, fordele roller og ta beslutninger som driver prosessen videre.
- Innholdskompetanse. Prosjektet trenger folk som kan funksjoner, gode tekniske løsninger og tverrfaglige sammenhenger, med forankring i drift og vedlikehold.
- Systematikk. En tydelig struktur for planer, krav, dokumenter, tester og avvik, støttet av et verktøy som tas i bruk fra prosjektoppstart.
V-modellen
Grunnlaget for systematisk ferdigstillelse er V-modellen, som også brukes i IKT-prosjekter. På venstre side beskrives kravene, fra overordnet programmering ned til detaljerte funksjonsbeskrivelser. På høyre side verifiseres de samme kravene, nivå for nivå, etter hvert som byggingen skrider frem.
Poenget er at hver test skal ha et krav å verifisere mot. Uten funksjonsbeskrivelser har ikke systemfunksjonstesten noe å måle mot, og uten integrerte funksjonsbeskrivelser kan ikke de integrerte testene si om samspillet er riktig.
Slik gjennomføres systematisk ferdigstillelse
1. Lag en plan for systematisk ferdigstillelse
Planen utarbeides ved prosjektoppstart og revideres i faseovergangene. Den beskriver prosessen, rollene og leveransene, og bør inngå i prosjektets grunnlagsdokumenter. Planen kan også brukes som grunnlag for kravene til rådgivere og entreprenører. Valg av entreprisemodell er ikke avgjørende for om metoden kan brukes.
2. Etabler systemlisten
Systemlisten er oversikten over alle tekniske systemer i prosjektet. Hvert system får et unikt nummer, og listen viser hvor systemet er plassert og hvilket område det betjener. Det er dette som gjør det mulig å koble systemene til testplanen og til ferdigstillelsen av områdene.
3. Skriv funksjonsbeskrivelser
Integrerte funksjonsbeskrivelser viser hvordan systemer og arealer henger sammen. Funksjonsbeskrivelsene beskriver hvert enkelt system. Begge må være på plass før løsningene detaljeres for langt i modellen. FMI-veilederen anbefaler at funksjonsbeskrivelsen er ferdig, FMI200, før modellen når MMI200.
4. Lag testprosedyrer, testplan og akseptkriterier
Testene beskrives i testprosedyrer allerede under prosjekteringen, med tydelige akseptkriterier. Da kan milepælene formuleres som «gjennomført og akseptert test» i stedet for bare «gjennomført test», og det blir målbart om kravene er nådd.
5. Følg opp status underveis i byggingen
Entreprenørene rapporterer ferdigstillelse av eget arbeid på definerte oppgaver. Veilederen gir eksempler på slike statuser: fysisk montert, ferdig tilkoblet, innregulert, FDV lastet opp, klart for systemfunksjonstest, systemfunksjonstest akseptert, opplæring avholdt, klart for integrerte tester og integrerte tester akseptert. Byggeledelsen kontrollerer da bare arbeid entreprenøren selv har erklært ferdig.
6. Test første produksjon før utrulling
Når samme løsning skal bygges mange ganger, prøvebygges den først. Feil i første montasje rettes før løsningen rulles ut i hele bygget.
7. Send «Varsel klart for test»
Før hver test bekrefter entreprenøren at det som skal testes, er ferdig og egenkontrollert. Varselet gjør forberedelsene tydelige og plasserer ansvaret hvis testen ikke blir godkjent.
8. Gjennomfør testene og lukk avvikene
Testene gjennomføres etter testprosedyren og dokumenteres i testrapporter. Feil og mangler føres i en felles liste for alle fag og kontrakter, og man går ikke videre til neste nivå før akseptkriteriene er oppfylt.
Testhierarkiet
Systematisk ferdigstillelse bygger på trinnvis testing. Komponentene testes først, deretter systemene, og til slutt samspillet mellom systemene. Slik unngår prosjektet at alle feilene dukker opp samtidig i slutten.
- Systemfunksjonstest. Tester et system på byggeplassen med relevant utstyr tilkoblet, og dokumenterer at ytelsene er i henhold til kravspesifikasjonen.
- Integrerte tester. Tester samspillet mellom to eller flere systemer på tvers av system- og entreprisegrenser.
- Fullskalatest. Dokumenterer at bygget fungerer som forutsatt med alle relevante delsystemer koblet sammen.
- Virksomhetstest. Som fullskalatesten, men med virksomhetens eget utstyr i normal bruk.
- Stabilitets- og ytelsestest. Dokumenterer at systemene fungerer stabilt over tid med forutsatte ytelser.
FMI: modenhet per system
Det er vanskelig å forklare hvor langt et teknisk system har kommet, og enda vanskeligere for et helt prosjekt med hundrevis av systemer. FMI, Funksjons Modenhets Index, løser dette med faste nivåer som settes per system og kan aggregeres til områder eller hele prosjektet.
Hovednivåene er faste og skal brukes likt av alle, mens hvert prosjekt kan legge til mellomnivåer. Et enkelt system uten grensesnitt kan hoppe over nivåer som ikke er relevante, for eksempel tabletest. Les mer i artikkelen om FMI-veilederen.
FMI og Level-skalaen
I internasjonale prosjekter, særlig datasentre, deles commissioning ofte inn i fem nivåer: kontroll ved levering, installasjon og mekanisk ferdigstillelse, oppstart av utstyr, funksjonstest av systemer og integrert systemtest (IST). De to skalaene er laget for ulike formål og kan ikke oversettes en til en, men de overlapper:
- FMI100 til FMI300 dekker planlegging og prosjektering, før det finnes noe fysisk å teste. Level 1 til 5 starter først når utstyret kommer. Level 0 i den utvidede skalaen dekker tidligfasen.
- Level 1 til 3 dekker levering, installasjon og oppstart. I FMI følges dette gjerne opp med mellomnivåer mellom FMI300 og FMI400.
- FMI400, systemfunksjonstest akseptert, ligger nær Level 4.
- FMI500, integrerte tester og fullskalatester akseptert, ligger nær Level 5 og IST.
- FMI600 og FMI700, virksomhetstest og drift, går lenger enn Level 1 til 5. Den utvidede skalaen dekker driftsklarhet og prøvedrift i Level 6 og 7.
Roller og ansvar
- Byggherre og prosjektledelse. Eier prosessen. Forankrer metoden, utpeker en ansvarlig for testprosessen, godkjenner testresultater og beslutter om man kan gå videre.
- Rådgivere. Utarbeider funksjonsbeskrivelser og testprosedyrer, og godkjenner entreprenørenes revisjoner etter at produktene er valgt.
- Entreprenører. Har ansvar for egenkontroll, reviderer funksjonsbeskrivelser og testprosedyrer etter leverandørvalg, rapporterer status på eget arbeid og sender varsel klart for test.
- Driftsorganisasjonen. Deltar i testene og bruker dem til opplæring. Det gir eierskap til anlegget de skal overta.
Overlevering og FDV
Overtakelse mellom kontraktspartene er en juridisk prosess. Overleveringen til driftsorganisasjonen er noe annet, og veilederen peker på fire kjernepunkter for at den skal lykkes:
- Forventningsavklaring. Det byggeier forventer å få, må stemme med det prosjektet faktisk leverer.
- Transparente feil- og mangellister. Med frister som overholdes, på et nivå der både bas og byggherre kan følge status.
- Komplett FDV-dokumentasjon. FDV leveres fortløpende, og skal være klar før testene starter.
- Opplæring. Planlagt i god tid og gjennomført som en del av testene.
Prøvedrift er beskrevet i NS 6450, og akseptkriteriene for start og avslutning av prøvedrift bør være definert i kontraktene.
Eksempler fra prosjekter
E39 Lyngdal: anlegg med JVIS
Arbeidsfellesskapet Implenia Stangeland bruker TaskCtrl gjennom hele prosessen på E39 Lyngdal, fra planlegging av vei, tunneler og bruer til ferdigstillelse. Les caset om E39.
Kuben, Bergen: bolig med COWI og Stoltz
COWI og Stoltz brukte TaskCtrl til prosjektering og systematisk ferdigstillelse, med testprotokoller som ble oppdatert på byggeplassen mens testene pågikk. Les caset om Kuben.
Project Lightning, El Paso, Texas: datasenter
På et datasenter på 1 GW er sjekklister og systematisk ferdigstillelse knyttet til aktivitetene i taktplanen, slik at byggingen og testplanen henger sammen. Les caset om takt og tog i datasentre.
Vanlige feil
- Testplanleggingen starter i slutten av byggefasen. Da er det for sent å påvirke løsningene.
- Tester uten akseptkriterier. Uten tydelige kriterier er det uklart når en test er godkjent, og milepælene blir uklare.
- Modellen kommer foran funksjonen. Systemer prosjekteres ferdig i BIM før funksjonen er avklart, og må prosjekteres om.
- FDV samles inn til slutt. Dokumentasjonen bør leveres fortløpende og være klar før testene.
- Ingen felles avviksliste. Når hvert fag har sin egen liste, mister prosjektet oversikten over hva som må lukkes før overlevering.
Systematisk ferdigstillelse i TaskCtrl
Veilederen fra 2016 påpekte at det ikke fantes verktøy som kunne ivareta hele prosessen, fra prosjektoppstart til ferdig testet og overlevert. TaskCtrl er bygget på veilederen for å dekke nettopp det.
Modulen for systematisk ferdigstillelse samler systemlisten, testhierarkiet, testprosedyrene og testprotokollene. Testene gjennomføres og signeres på mobil, avvik registreres med bilde mot riktig system, og FDV-dokumentasjonen samles inn underveis. Modulen er koblet til byggemodulen, slik at status fra taktplanen følger med inn i testplanen.
Systemlisten er utgangspunktet. Hver rad er et system med unikt nummer, og kolonnene følger systemet gjennom hele løpet:
- System. Systemstatus, MMI, FMI og åpne avvik.
- Dokumenter. Funksjonsbeskrivelse, systemskjema, automasjonstegninger og kravspesifikasjon.
- Mekanisk ferdig. Startet, ferdig og spenningssatt, med status fra byggingen.
- Tester. Tabletest, systemfunksjonstest, I/O-test, integrert test, områdetest og scenariotest.
- Fag. Hvilke fag som er involvert i systemet, fra byggherre og prosjekteringsleder til ARK, RIB, RIV, RIE og de øvrige.

Eksemplet viser hvordan FMI følger arbeidet. Systemer med ferdig funksjonsbeskrivelse står på FMI200. Systemer der tabletesten er akseptert og systemfunksjonstesten er planlagt, står på FMI350. Når systemfunksjonstesten er akseptert, går systemet til FMI400. MMI viser modenheten i modellen ved siden av: 400 for arbeidsunderlag og 450 når systemet er utført.
Testhierarkiet settes opp etter prosjektets egen struktur. Et datasenter kan for eksempel ha bordtest, FAT, mekanisk ferdigstillelse, funksjonstester, IST og fullskalatest som egne kolonner.
Faglig bidrag: Ove Kjærgård, Brisq.
Guiden bygger på «Veileder: Systematisk ferdigstillelse» fra BA2015, utarbeidet av Per Roger Johansen og Tor I. Hoel (2016), og «FMI-veilederen» fra Prosjekt Norge ved NTNU.
Vanlige spørsmål
Hva er systematisk ferdigstillelse?
Systematisk ferdigstillelse er en metode for å sikre at et prosjekt oppfyller alle funksjonskrav innenfor gitte rammer for tid, kostnad og kvalitet. Prosessen er ledelsesstyrt, starter ved prosjektoppstart og går gjennom prosjektering, bygging, testing, overtakelse og drift.
Hva er forskjellen på systematisk ferdigstillelse og commissioning?
Commissioning er det internasjonale begrepet, særlig brukt i industri, olje og gass og datasentre. Systematisk ferdigstillelse er den norske metodikken. Begge har samme mål og starter ved prosjektoppstart. Forskjellen ligger i rollen: ITB-gruppen og prosjektorganisasjonen sikrer at kriteriene blir ivaretatt, mens commissioning ofte er en uavhengig tredjepart som verifiserer at de blir det.
Hva er et testhierarki?
Et testhierarki er rekkefølgen testene gjennomføres i, fra komponenter via systemfunksjonstest og integrerte tester til fullskalatest og virksomhetstest. Hvert nivå bygger på det forrige, slik at feil oppdages tidlig og ikke hoper seg opp i slutten av prosjektet.
Hva er FMI?
FMI, Funksjons Modenhets Index, viser hvor langt hvert teknisk system har kommet. Hovednivåene går fra FMI100, plan for systematisk ferdigstillelse etablert, til FMI700, drift.
Hva er integrert systemtest (IST)?
IST er testen der flere tekniske systemer testes sammen for å dokumentere at de fungerer i samspill. Begrepet brukes mye internasjonalt og i datasenterprosjekter, der det ofte kalles Level 5.
Hva er «Varsel klart for test»?
Det er en erklæring fra entreprenøren om at alt som skal testes er ferdig og egenkontrollert, slik at testen kan gjennomføres som planlagt. Varselet gjør ansvaret tydelig hvis testen ikke blir godkjent.
Når bør man starte med systematisk ferdigstillelse?
Ved prosjektoppstart. Plan for systematisk ferdigstillelse bør være en del av prosjektets grunnlagsdokumenter, og testplanleggingen bør starte tidlig i prosjekteringen, ikke i slutten av byggefasen.
Les også
Vil du se systematisk ferdigstillelse i praksis?
Vi viser gjerne hvordan systemliste, testhierarki og testprotokoller kan settes opp for deres prosjekt.