Projektiinfo tootmismeetodid ja -protsessid (EN ISO 19650)

Introduction

Töö tegemise dokumenteerimiseks kasutatakse tootmismeetodeid ja -protsesse. See võib projekti elluviimise meeskonna erinevatele liikmetele tähendada erinevaid asju. Kliendi jaoks võib see tähendada, kuidas informatsiooni esitatakse ülevaatamiseks ja vastuvõtmiseks, arhitekti jaoks võib see olla spetsifikatsioonide koostamise protsess; kuid ukse tarnija jaoks võib see olla protsess, mille käigus otsitakse enne tootmisse lubamist kõik vajalikud ülevaatused ja kinnitused.

Mõned määravad osalised võivad kaaluda täiendavate tootmismeetodite ja -protsesside lisamist, mis võivad hõlmata nõudeid ruumilise koordineerimise, vastuolude tuvastamise protsesside ja koosolekute aruandluse, tehniliste päringute esitamise protsesside ja paljude muude standardsete protsesside kohta. Lisanäidetena võib tuua:

• lepingute haldamine;
• päevakavade ja koosolekute dokumenteerimise metoodikad;
• ruumiline planeerimine;
• mudeli loomine;
• koondstrateegia;
• koordineerimine ja vastuolude vältimine;
• programm / ajakava (4D);
• mahud ja maksumus (5D);
• kontrolli- ja katseplaanid;
• info kontrollimine ja kinnitamine;
• üleandmise informatsioon;
• informatsiooni arhiveerimine.

Ülaltoodud loend on lihtsalt näide ning igal organisatsioonil ja projektil võivad olla oma enda nõuded. Kui need ei sisaldu hankedokumentides ega dokumenteerita täielikult, on määraval osalisel raske eeldada, et need protsessid on tegelikult integreeritud ka projekti.

Kui tulevane määratud juhtiv osaline teeb projekti jaoks pakkumust, peab ta üle vaatama hankedokumentatsiooni osana sisalduvad tootmismeetodid ja -protsessid ning võtma arvesse ka elluviimise meeskonna poolt kasutatavaid tootmismeetodeid ja -protsesse. Määramiseelse BIM rakenduskava ja ettevalmistuskava koostamisel tuleb arvesse võtta võimalikke lünki või kattumisi. Näiteks võib määrav osaline nõuda aruannet koos ettenähtud informatsiooniga, mis esitab järjepidevaid tõendeid konstruktsiooni vastuolude lahendamiseks tehtud edusammude kohta. Tulevane määratud juhtiv osaline peaks tegema koostööd elluviimise meeskonnaga, et teha kindlaks, kuidas seda informatsiooni saab esitada.

When are Project Information Production Methods and Procedures Established?

Projektiinfo tootmismeetodid ja protsessid tuleks ette valmistada enne hanget ning need võib lisada hankedokumentidesse või asjakohased osad võib ka lisada infovahetuse nõuetesse (EIR).

Responsibility

Määrav osaline vastutab projektiinfo tootmismeetodite ja -protsesside kehtestamise eest, mis lisatakse iga projekti hankedokumentatsiooni. Nende täitmise eest vastutab määratud juhtiv osaline, elluviimise meeskond ning iga töörühm.

Määratud juhtiv osaline ja määratud osalised peaksid kaasama tootmismeetodid ja -protsessid BIM rakenduskavas, milles sätestatakse, kuidas nad informatsiooni toodavad. Need on suunatud iga üksiku organisatsiooni vajadustele.

Alljärgnevas loendis on sätestatud iga osalise vastutus lähtuvalt EN ISO 19650-2 alamprotsessist.

Guidance

Järgnevalt on toodud mõned üldised näited informatsioonist, mis võib sisalduda projektiinfo standardis. Mõnel projektil võivad olla väga spetsiifilised nõuded, mida ei saa siin dokumenteerida. Näiteks suurema projekti korral saame rääkida väga paljudest informatsiooni kontrollimise protsessidest, mis ei oleks ühekordse, väiksema projekti puhul ökonoomne. Kogu informatsiooni lõppkasutust tuleks hoolikalt kaaluda.

Capture of existing asset information

Üks olulisemaid ülesandeid, mida esmalt teha, on määrata, milline olemasolev informatsioon on saadaval ja kas see sobib projekti staadiumite koostamiseks ja nende edasi arendusteks. Oluline on kogutud informatsiooni lõikes läbi viia esmane kontroll, mis võib säästa märkimisväärse ümbertegemise vajaduse hilisemas staadiumis. Näiteks tuleks võimalikult varakult paika panna täpne alusplaan (korruste jaotus), mis baseerub mõõdistusinfol, et hilisemas etapis vältida koordineerimisega seotud vigasid. Kui tehakse oletusi, tuleks need selgelt edastada.

Aluskaartide kasutamine on end õigustav kui nende täpsus oleks vähemalt ±1 m. Topograafilised uuringud on väga kasulikud, kuid ainult siis, kui need kujutavad endast ehitiste ja/või maa-ala hiljutisi uuringuid, mida ei ole oluliselt muudetud. Laserskaneeringud ja punktipilved võivad anda väga täpse ruumilise esituse nähtavast, kuid ei pruugi määrata nende varade seisukorda ega anda teavet ehitise peidetud osade kohta, nt vahelagede tagune või maa-alune osa. Seetõttu on võib osutuda vajalikuks spetsialistide poolt läbiviidavad lisauuringud, et saada informatsiooni osade kohta, mis pole kergesti ligipääsetavad, nt maa-alused osad või kandvate elementide siseosa (sh armatuur).

Võimaluse korral peaks määrav osaline jagama hankedokumentatsioonis (CDE kaudu) varade kohta käivat olemasolevat informatsiooni tulevase määratud juhtiva osalisega. See võib hõlmata alljärgnevat:

• Ajaloolised ülestähendused
• Tehnosüsteemide kohta käiv info
• Aluskaardid
• Mõõdistusinfo
• Lisamõõdistused (tingimuslikud uuringud)
• Asbesti kasutusega seotud uuringud
• Teostusinfo
• Varade register
• Lisauuringud, nt georadariga tehtud uuringud

Kogu asjassepuutuva informatsiooni sobivust tuleks eelnevalt kontrollida ja vastavalt sellele edastada see info ka elluviimise meeskonnale.

Alustades tööd olemasoleva varaga, algatatakse iga projekti puhul muudatuste kontrollimise protsess, et hoida olemasolevate varade kohta ajakohastatud arvestust, mis tuvastab:

• Olemasolevad üleliigsed varad, mis jäävad paika
• Olemasolevad varad, mis projekti käigus eemaldatakse/lammutatakse
• Olemasolevad varad, mida muudetakse
• Uued varad

Generation, review, or approval of new information

Informatsiooni kontrollimise, ülevaatamise ja jagamise protsess on määratletud standardi EN ISO 19650-2:2018 tegevustes 5.6.3–5.6.5. Allolev joonis esitab kinnitusprotsessi maatriksi.

Joonis. Kinnitusprotsessi maatriks.

Täiendavate juhiste saamiseks vaata ka õppemoodulit ühtne andmekeskkond. Elluviimise meeskonna jaoks on kahte tüüpi ülevaatusi:

1. Ülevaatus töörühmade vahel, nagu on näidatud jaotises 5.6.5 Infomudeli ülevaatus.
2. Kogu elluviimise meeskonna läbivaatus, mille määratud juhtiv osaline on seejärel volitanud esitama määravale osalisele – vaadake punkti 5.7.2. Infomudeli ülevaatus ja kinnitamine.

Ehitiste projekteerimist teostatakse järk-järgult (iteratiivselt), mille käigus kavandatakse projektlahendusi, kontrollitakse seda kõigi teadaolevate piirangute suhtes, jagatakse seda teistega, kes omakorda vaatavad läbi jagatud informatsiooni ja piirangud, mille raames nad peavad töötama, ning lisavad või soovitavad projekti muudatusi. Iga iteratsiooniga optimeeritakse projektlahendit, et see sobiks kõige paremini eesmärgi, projekti eelarve, asukoha ja suutlikkuse nõuetega.

Võttes arvesse vastutusmaatriksit ja ülesandepõhist info edastamise kava, vastutab iga töörühm järgmiste EN ISO 19650-2 tegevuste eest:

• 5.6.1 Võrdlusinfo ja jagatud ressursside kättesaadavuse kontrollimine
• 5.6.2 Info genereerimine
• Kvaliteedi tagamise kontrolli läbiviimine
• Info ülevaatus ja ühiskasutuse kinnitamine

Elluviimise meeskond vastutab kollektiivselt:

• 5.6.5 Infomudeli ülevaatus

Koordineerimine peaks jätkuma seni, kuni töörühmad on valmis esitama koordineeritud projektinfo määratud juhtivalt osaliselt loa saamiseks.

Informatsiooni loomine koostöös lähtub igast töörühmast, kes tagab ajakohase võrdlusinfo kontrollimise ja kaasamise. Näiteks võib arhitekt näidata, et hoone teljed ja tasapinnad sobivad ehitusinseneri poolt vajatavaga, samas kui teatud mahus vajab mingi ala täpsustust ning lisamõõdistuste ootel. Konstruktsiooniinseneril on põhjendatud ootus, et jagatud hoone teljed ja tasemed vaadatakse üle muu kättesaadava info põhjal ja seejärel kiidetakse heaks enne, kui ta hakkab neid oma projekti kaasama. Samamoodi, kui ehitusinsener töötab välja konstruktsioonianalüüsi mudeli, mis sisaldab arvukalt arvutusi optimaalse ehitise karkassi määramiseks, on teistel seda teavet kasutavatel inimestel mõistlik ootus, et seda on kontrollitud kokkulepitud projekteerimispiirangutega, nt talade maksimaalne kõrgus, et tagada tehnosüsteemide sobitamine ning et see info oleks kinnitatud enne kui seda jagatakse teiste projekteerijatega. Koordineerimiskoosolekul võib tekkida vajadus kaaluda võimalusi tala ristlõike vähendamiseks, mis võib tähendada tala kõrguse või laiuse vähendamist. Kõik töörühmad peavad mõistma muudatusega kaasnevaid eeldusi ja riske. Näiteks võidakse katusele paigalda generaator, mis paikneb pika ava keskel. Sellistel juhtudel võib ainsaks ökonoomseks lahenduseks osutuda, kus ava laiust tuleb vähendada.

Projekti alguses tunduvad otsused väga muutlikud, kuna valikuvõimalusi võib olla palju, kuid projekti edenedes põhinevad otsused kõikidel varasematel otsustel ning varasema otsuse taganemise ja kohandamise kulud suurenevad oluliselt, kuna informatsiooniga on seotud üha rohkem otsuseid. Otsuste langetamist võimaldav teave edastatakse sageli projekteerimise kooskõlastuskoosolekutel vahepealsete lahenduste kaudu, mis võivad sisaldada erinevaid projektlahendeid. Neid infopakette loetakse töös olevateks ja neid tuleks selgelt edastada, kasutades infokonteineri sobivusolekut ning ühtset andmekeskkonda. Pärast otsust liikuda edasi kõige optimaalseima projektlahendiga, väljastatakse elluviimise meeskonnale kinnitatud disaininfo kui “Jagatud”, mis võimaldab neil jagatud informatsiooni põhjal oma disainilahendusi edasi arendada.

Enne muudetud projektiga jätkamist tuleks kontrollida kogu võrdlusinfot. See võib hõlmata uuringuid, teiste projekteerijate ajakohastatud teavet, standardeid jne. Kui mõni uus võrdlusinfo mõjutab kokkulepitud projekti, nt truup asub eeldatust erinevas kohas, võib enne informatsiooni jagamist vaja minna veel üht kooskõlastuskoosolekut. Kaaluda tuleks ametlikku projekti muudatuste kontrollimise protsessi, mis tuvastab kokkulepitud projekti muudatused ja nende põhjused. See aitab kommunikeerida ja jälgida muudatusi elluviimise meeskonna liikmete vahel ning annab määratud juhtivale osalisele mehhanismi laiendada muudatusi lepingu haldamise protsessidega, millel on ulatuse, eelarve või programmi mõju.

Enne ajakohastatud informatsiooni teiste elluviimise meeskonna liikmetega jagamist, peavad töö autorid läbi viima kvaliteedikontrolli. See võib hõlmata alljärgnevat:

• Edastatavat informatsiooni kontrollitakse ülesandepõhise info edastamise kava (TIDP) alusel. TIDP-d tuleks iga uue või muutunud informatsiooni jaoks ajakohastada.
• Informatsiooni tuleks kontrollida projektiinfo standardiga. Näiteks, kas kirjanurk on õige, kas infokonteiner vastab failinimede standardile, kas hoone teljed, tasemed ja ruumid on nummerdatud õigesti, kas kasutatakse õigeid vara atribuute?
• Informatsiooni muudatuste kontrolli ning sobivust tuleks kontrollida.

Lõpuks peaks kogenud projekteerija info üle vaatama ja selle jagamiseks heaks kiitma. Ülevaatus peaks sisaldama:

• Määratud juhtiva osalise infonõudeid
• Infovajaduse taset
• Informatsiooni, mida vajavad teised töörühmad

Projekti kooskõlastuskoosolekute tõhusaks toimimiseks tuleks enne kooskõlastuskoosolekut värskendada järgmist informatsiooni:

• Projektinfot tuleb jagada enne koosolekut, et anda projekteerijatele aega üle vaadata uus jagatud informatsioon nende hetke lahendusega, eeldustega ning projekti riskiregistriga. Informatsiooni olek peaks olema selgelt määratletud, nt “pooleli olev töö“ või “jagatud“.
• Disainiga seotud probleemidest tuleb teavitada enne koosolekut. Need tuleks lisada jälgitavasse registrisse.
• Projekteerimisriskid tuleb lisada riskiregistrisse ja neid tuleb hoida ajakohastena.
• Programmiriskid tuleb lisada või ajakohastada riskiregistris. Näiteks võib uue informatsiooni saamiseks olla vaja veel ühte disaini iteratsiooni, mis mõjutab edastamise tähtaega.
• Disaini muutmise kontrolli otsused tuleks üle vaadata ja lisada.
• Ajakohastatud ülesandepõhist info edastamise kava (TIDP) tuleks jagada.

Riskiregistrid on äärmiselt olulised, kuna need tagavad riskide formaalse tuvastamise ja jälgimise. Määratud juhtiv osaline võib samuti eskaleerida riske, mis nõuavad määrava osalise panust, kui need on vastuolus projekti eelarve, ulatuse ja projektiprogrammiga. Sellest tuleks teavitada kokkulepitud lepinguhaldusprotsessi kaudu.

Kasutades pilvepõhiseid lahendusi mudelite ja muu informatsiooni jagamiseks saab potentsiaalselt kogu projektiinfot jagada elluviimise meeskonna vahel ilma, et oleks vaja luua väljatrükke või pdf-dokumente. See ei kaota nõuet kehtestada vahe-eesmärke, mis loovad põhimõttelise joone projektimuudatuste valikuks. Näiteks, põhiprojekti käigus on põhjendatud ootus, et esmalt peab projekteerima laed ja seejärel saame lisada valgustuse ja muud laeelemendid. Kuna lagedega seonduvalt kasutavad seda infot teised projekteerijad, siis tuleb see info välja jagada (kui “jagatud“) ning lisada juurde, mis mahus võib informatsioon olla puudulik või ootel.

Tabel. Paranduste staatuse ülevaate näide.

Ülaltoodud näites ei sobiks versioonid P01.1 ja P01.2 teistele projekteerijatele projekteerimise alustamiseks. Ruumide lõplik paigutus ei pruugi olla valmis ja mis tahes projekteerimine võib vajada ümbertegemist. See ei takista projekteerijal informatsiooni kasutamast, kuid seda võib käsitleda riskiteguriks. Informatsioonile toetuvatel projekteerijatel on mõistlik ootus saada õigeaegselt lagede paigutuse “jagatud” versioon, mis võimaldab neil kavandamist jätkata vastavalt info esitamise peakavale (MIDP).

Tööd saab alustada redaktsiooni P01 alusel. Redaktsioon P02 sisaldab muudatusi, mis tuleks redaktsioonikontrolli abil selgelt dokumenteerida. Kõik olulised projekti muudatused, mis mõjutavad ulatust, eelarvet või programmi, tuleks lisada projekti muudatuste kontrolli registrisse. Redaktsioon P03 sobib määratud juhtivale osalisele kinnitamiseks. Redaktsioon P04 sobib esitamiseks määravale osalisele läbivaatamiseks ja heakskiitmiseks. Muudatus P05 võib sisaldada määrava osalise poolt lisatud märkuseid.

Määratud juhtival osalisel võib olla märkimisväärne huvi, et see eelnimetatud protsess toimiks veatult, kuna ta vastutab selle eest, et iga töörühm esitab määravale osalisele informatsiooni vastavalt info esitamise peakavale (MIDP), mis peab olema vastavuses projekti vahe-tähtaegadega. Kriitilised teekonnad tuleks põhjalikult läbi uurida, mis nõuab ka terviklikku mõistmist iga ülesande kestuse kohta, et oleks võimalik usaldusväärselt hinnata lõplikku alguskuupäeva. Töörühmade vahelised ülesanded, mis on omavahel seotud (eelnevad, sõltuvad ülesanded), tuleks identifitseerida, kuna see annab teada, millal informatsioon genereeritakse. Vastutus võimalike konfliktide tähenduses tuleks kindlaks määrata, seega ei tohiks midagi eeldada.

Sobivuse olekuid tuleks hoolikalt kaaluda. Olukorras, kus need pole selgelt defineeritud, peaks määrav osaline või ka määratud juhtiv osaline looma standardiseeritud süsteemi, milles iga töörühm teab, millist sobivuse olekut peab ta infokonteinerite juures CDE-s kasutama.

Tõhus planeerimine on õigeaegseks projekteerimiseks ja ehitustöödeks ülimalt oluline. Esitatud pakkumusena lisatud elluviimise meeskonna ettevalmistuskava peaks sisaldama dokumenteeritud tõendeid elluviimise meeskonna lähenemisviisi kohta informatsiooni koostamisel, ülevaatamisel ja kinnitamisel. Protsessi tuleks projekti alguses testida ettevalmistuse perioodi jooksul. Riskiregistrite, projektimuudatuste kontrolli, TIDP-de jms malle tuleks jagada elluviimise meeskonnaga ühtse andmekeskkonna kaudu.

Security or distribution of information

Informatsiooni genereeritakse süsteemide kohta, mida juhib iga töörühm. Kui töörühmade vahel teavet vahetatakse, tuleks seda teha ühtses andmekeskkonnas (CDE). CDE strateegia tuleks läbi vaadata määrava osalise projektiinfo tootmismeetodites ja -protsessides. On kaks põhimõttelist valikut:

1. “Töös olev“ ning “jagatud info“ võib olla loodud süsteemis, mida kontrollib elluviimise meeskond. Alles pärast seda, kui määratud juhtiv osaline on informatsiooni kinnitanud, esitatakse see läbivaatamiseks ja heakskiitmiseks ühtsesse andmekeskkonda, mida kontrollib määrav osaline.
2. Alternatiivina võib määrav osaline nõuda, et kogu projektinfo salvestatakse ja jagatakse ühes konkreetses ühtses andmekeskkonnas, mida kontrollib määrav osaline.

Enamik CDE-sid hoiab iga toimingu kohta kontrolljälge, samas kui e-kirjadena levitatavat informatsiooni saab levitada ilma kontrolljäljeta. Seda tasub silmas pidada nii turvalisuse kui ka juhtimise seisukohast.

Määratud juhtiv osaline vastutab informatsiooni edastamise eest vastavalt info esitamise peakavas (MIDP) määratletud tähtaegadele. Iga töörühm peaks jagama informatsiooni määratud juhtiva osalisega enne info esitamist määravale osalisele. Kui määratud juhtiv osaline on informatsiooni heaks kiitnud, tuleb see esitada kliendi CDE-le läbivaatamiseks ja kinnitamiseks.

Delivery of information to the appointing party

Määrav osaline peaks kehtestama protsessi iga töörühma esitatud info läbivaatamiseks ja vastuvõtmiseks pärast seda, kui määratud juhtiv osaline on info heaks kiitnud. Selle tegemise protsess tuleks dokumenteerida määrava osalise projektiinfo tootmismeetodite ja -protsesside all.

Igal projekti tähtajal esitatakse informatsioon määravale osalisel läbivaatamiseks ja kinnitamiseks. Määrav osaline peab tagama, et asjakohased isikud vaatavad info läbi, peavad märkuste üle arvestust ja määravad igale infokonteinerile ülevaatuse või aktsepteerimise staatuse (vt allolev tabel).

Tabel. Ülevaatuse staatuse näide.

Väiksemate projektide puhul saab protsessi hallata e-kirja ja arvutustabelite abil. Soovitatav on informatsiooni esitamise protsess kehtestada CDE-s. See peaks pakkuma kontrollitavat süsteemi vastuvõetud dokumentide muudatuste jälgimiseks ning võimaldama jälgida üksikisikute lisatud kommentaare ja ülevaatuse oleku muutusi (vt allolevat näidet).

Tabel. Kontrollitava süsteemi näide haldamaks dokumentide ülevaatamise protsessi.

CDE peaks sisaldama logi või tegevusandmeid:

1. Iga infokonteineri redaktsiooni üleslaadimise kuupäev ja kellaaeg
2. Iga infokonteineri versiooni üles laadinud kasutaja
3. Iga infokonteineri nimi ja kirjeldus
4. Iga infokonteineri versioon
5. Iga infokonteineri sobivuse olek
6. Tähtaeg, mille jaoks iga infokonteiner välja antakse
7. Määrava osalise poolt lisatud läbivaatamise staatus

Tuleks luua läbivaatamise töövood, mis peaksid hõlmama alljärgnevat:

1. Läbivaatamise periood nt 10 tööpäeva või 14 kalendripäeva. Lepingud sisaldavad tavaliselt kindlaksmääratud tähtaegu ülevaatuste tegemiseks koos trahvidega, kui ülevaatusi ei tehta õigel ajal.
2. Töövoo nimi, nt arhitektuur, konstruktsioonid, tehnosüsteemid, tervishoid ja ohutus, planeerimine, keskkond, kvaliteedijuhtimine.
3. Töörühmad, kes saavad töövoo kaudu teavet esitada. Näiteks võib arhitekt olla võimeline esitama töövoo arhitektuuri, tervishoiu ja ohutuse ning planeerimise kohta, kuid mitte konstruktsioonide töövoogu.
4. Isikud või rollid, kes võivad esitada esitatud teabe tehnilise ülevaatuse. Need peaksid vastama esitatavale informatsioonile. Näiteks võib määrav osaline kaasata üksikisiku või organisatsiooni arhitektuurse informatsiooni läbivaatamiseks.
5. Isikud või rollid, kes annavad iga infokonteineri jaoks ülevaatuse või aktsepteerimise oleku. See võib olla kliendi esindaja, projektijuht või muu isik, kellel on õigus määrata igale infokonteinerile ülevaatuse või aktsepteerimise olek.
6. Ülevaatuse või aktsepteerimise olek, nt A - Aktsepteeritud, B – Kinnitatud märkustega, C - Tagasi lükatud.

Iga töövoo põhjal koostatud ülevaated peaksid sisaldama järgmist:

1. Alguskuupäev
2. Ülevaatuse nimetus
3. Ülevaatamiseks ja vastuvõtmiseks kaasatud infokonteinerid
4. Mis tahes täiendav teave, sealhulgas sisulehed, edastusregistrid jne.

Arvesse tuleks võtta, kuidas iga infokonteineri või üldise ülevaate kommentaare jälgitakse. Informatsioon on oluline ülevaatuse oleku määravatele isikutele ja töörühmale, kes peab kommentaaridega tegelema. Kõik CDE funktsioonid, mis võivad automatiseerida kommentaaride seostamist infokonteineritega, vähendavad võimalike probleemide väljajätmise ohtu ja muudavad süsteemi tõhusamaks (vt allolevat näidet).

Tabel. Iga infokonteineri kommentaari järgimise protsessi näide.

Veelgi keerukam ja parem lähenemine oleks seostada iga kommentaar infonõuetega seotud aktsepteerimiskriteeriumidega (vt allolevat näidet).

Tabel. Kommentaari järgimine iga infokonteineri osas, vastavalt infonõudele.

Contract management

Ehituslepingud hõlmavad ette nähtud suhtlust projektijuhi ja töövõtja vahel, mis tagab kontrollitud mehhanismi kasutamise projekteerimise ja ehitamise aspektide edastamiseks, mis võivad põhjustada muudatusi lepinguhinnas või ehitusprogrammis.
Allpool on toodud mõningaid näited:

• Üldine kommunikatsioon (GC)
• Varajased märgukirjad (EW)
• Tehnilised päringud (TQ) / Infopäring (RFI)
• Projektijuhtimise juhend (PM)
  • Üldinfo
  • Kompensatsiooni tingimus
  • Muudetud programm
  • Disaini esitamine
• Töövõtjate ettepanekud (CP)
• Kompensatsiooni tingimus (CE)
• Hinnapakkumused / projektijuhi hindamine (QA)
• Programmi esitamine (PS)
• Lõpetamise prognoos (FC)
• Defektid (DF)
• Makse (PY)

Kuigi põhialused on enamasti samad, on kasutatav terminoloogia lepinguti erinev.

Space planning

Mõelge läbi, kuidas saab ruume võrrelda algsete kavanditega. Mudelid võivad sisaldada automaatseid pindala- ja mahuarvutusi mõõtmisreeglite alusel. Samas tasub kaaluda ka muid ruumide mõõdikuid, mida saab kontrollida, sealhulgas ruumi minimaalset laiust, pikkust ja kõrgust, aspekti, põranda tasapinda, turvalisust, õhuvahetust, põranda viimistluse libisemiskindlust jne. Lisaks, kas eksisteerib nõue spetsifitseerida ja kinnitada muid elemente, nagu uksed, põrandaviimistlus või mööbel, inventar ja seadmed ruumide kaupa? Kas need mõõdikud valideeritakse mudeli nõuete alusel või eksporditakse see informatsioon kontrollimiseks mõnda teise sobivamasse ja juurdepääsetavamasse süsteemi ja kui jah, siis milline on selle metoodika? Kontrollimise ja kinnitamise metoodikad tuleks lisada projektiinfo tootmismeetoditesse ja -protsessidesse.

Olulisem on olla süstemaatiline ja järjekindel kui omada info haldamiseks keerukaid tarkvarasüsteeme. Väiksemate projektide puhul võivad tabelid väga hästi toimida eeldusel, et informatsiooni säilitamise metoodika ja vastutus on hästi edastatud.

Kuna ruumiline planeerimine on sageli projekti üks esimesi tulemusi, on oluline arvestada koordinaatide süsteemi. Kui on tehtud mõõdistus, tuleks mudelid kooskõlastada koordinaatsüsteemiga, sest vastasel juhul võib vaja minna märkimisväärset ümbertegemist.

Model authoring

Näited
Määrav osaline dokumenteerib mudeli loomise protsessi projektiinfo standardis. Määratud juhtiv osaline kirjeldab projektiinfo standardis sisalduvaid ettekirjutavaid nõudeid BIM rakenduskavas. Kõik informatsiooni koostajad kasutavad eelnimetatud dokumente järjepidevalt.

Change Control

Muudatuste kontrollimise tase on vajalik tagada kõikides projekti staadiumites, et säilitada muudatuste tõhus teavitamine. Arvesse peaks võtma muudatuste kontrolli taset ja see peaks olema iga projekti etapi jaoks sobiv, kuna muudatuste võimalikkus/vajadus ja muudatuste maksumus suureneb oluliselt, kui projekti arendatakse projekteerimisest ehitamiseni. Traditsiooniliselt edastatakse muudatused ajakohastatud jooniste või dokumentide väljastamisega koos lühikese kommentaariga, mis sisaldab muudatusi praeguse ja eelmise väljaantud versiooni vahel. Keskmiste ja suuremate projektide puhul tuleks kaaluda aga alljärgnevat:

1. Protsess, mis tuvastab projekti nõuded ja loob süsteemi nende nõuete täitmise kontrollimiseks ja kui neid ei ole võimalik täita, siis selle põhjused. See võib olla projekti lühikirjeldusest koostatud tabel, mis on seotud planeerimise, regulatiivsete ja muude nõuetega. Suuremate projektide jaoks võivad sobivamad olla tarkvarasüsteemid, mis võimaldavad kasutajapõhist haldust/ligipääsu ning kontrolle.
2. Tarkvara või ühtse andmekeskkonna (CDE) süsteemid, mis suudavad jälgida jooniste, dokumentide ja mudelite probleeme või kommentaare. Neid saab kasutada alternatiivina traditsioonilistele töökoosolekutele, kus dokumente vaadatakse üle ning märgistatakse vastavalt. Sellistesse süsteemidesse tuleks lisada mehhanism probleemide või kommentaaride jälgimiseks, neile vastamiseks ja nende sulgemiseks.
3. Tarkvara või ühtse andmekeskkonna (CDE) süsteemid, mis suudavad tuvastada lisatud, kustutatud või muudetud komponente. See võib osutuda väga kasulikuks, kui mahtusid võetakse üksikasjalikult arvesse, näiteks tööprojekti etapis. Selle toimimiseks tuleb hoolitseda selle eest, et mudelite loomine oleks olemuselt progressiivne, ja modelleerimisel tuleb olla ettevaatlik, et mudeli komponente ei kustutataks ega ehitataks ümber iga kord, kui paigutust muudetakse.
4. Ehitusel tuleks muudatusi juhtida ettenähtud muudatuste kontrollimise protsessi kaudu. Neid juhitakse sageli lepingu alusel. Näiteks võib dokumentide, mudelite ja jooniste muudatused kokku võtta kui “Muudatused vastavalt PMI #12-le” ja muudatuse üksikasjad tuleks üksikasjalikult kirjeldada projektijuhtide juhistes.

Federation strategy

Koondstrateegiat kasutatakse sageli mudelite puhul, mis on koondatud vastuolude tuvastamiseks. Koondstrateegia koosneb mudelitest, joonistest, dokumentidest ja muudest allikatest, mis on lingitud, kuid mis ei kaota linkides oma identiteeti ega terviklikkust. Näiteks võib ehitise ideekavandi ühendada mõõdistuse või aluskaardiga, kui see ehitis on seotud jagatud geodeetilise alusvõrguga. Komponenti nagu radiaatorit võib tuvastada sellega seotud ruumi järgi, millega markeeritakse komponentide/elementide nimekiri ruumi kaupa, mida kasutatakse korrashoiu teostamiseks.

Näited
Töö planeerimist, andmete eraldamist ja informatsiooni koondamist koordineerib määratud juhtiv osaline. Koondstrateegia peaks hoidma mudelite arvu minimaalsena, pidades silmas eeldatavaid tulevasi nõudeid ja mudeli mahule seatud ootusi. Kasutada tuleks järgmist strateegiat:

1. Määratud juhtiv osaline loob põhimudeli või joonise, mis sisaldab kontrollitud koordinaate ja jagatud funktsioone, nagu korruste tasemed ja ehitise teljed, mida jagatakse projekti alguses teiste töörühma liikmetega. Seda mudelit tuleks kasutada kõigis teistes mudelites ja jagatud koordinaadid tuleks hankida sellest mudelist.
2. Mudelite koostajad esitavad informatsiooni mudelites, mida nad kontrollivad, hankides samal ajal informatsiooni teistest mudelitest, kui see on nõutav võrdlusinfona, koondamisena või otsese infovahetusena. Seetõttu põhineb esimene mudelite jaotus alati töörühmade põhistena.
3. Mudeleid võib omakorda jagada alamüksusteks lähtuvalt määratud süsteemide põhiselt, kandev konstruktsioon, vahelaed, turvasüsteemid jne. Süsteemide loend peaks sisalduma spetsifikatsioonis ja see peaks kaasama kõiki vastutusmaatriksis määratletud elemente/komponente.
4. Kui mudeleid tuleb veelgi väiksemateks osadeks jaotada, tuleks määratleda tsoonid. Tsoonid võivad olenevalt mudeli suurusest ja keerukusest olla horisontaalselt või vertikaalselt ühe või mitme tasemega määratud piirkond. Koondstrateegiasse tuleks lisada põhiplaan tsoonide määratluse kohta. Töörühm võib valida, kas kasutada tsoone või mitte, kuid ei tohi luua erinevaid tsoone, mis kattuvad määratud tsoonidega, ega kombineerida elemente rohkem kui ühes tsoonis. Näiteks võib ehitusinsener soovida lisada kogu hoone teraskarkassi ühte tsooni, samas kui arhitekt võib soovida eraldada laed väikesteks üksusteks, mida piiravad tsoonid.
5. Töörühmad kasutavad arhitektide mudeli ruume. Kõikidest muudatustest teavitatakse kõiki projektimeeskonna liikmeid.

Coordination and clash avoidance

Koordineerimine ja vastuolude vältimine, eriti tööprojekti ja ehitamise staadiumis, on ülimalt olulised tänastes projektides, mille keerukus on suurenenud ning tehaselist tootmist ning kohapealset kokkupanekut kasutatakse üha enam. Selle peamine eelis on, et võimalikud vastuolud oleksid lahendatud enne kui tooted jõuavad ehitusplatsile. See paneb kõikidele meeskondadele olulise kohustuse pakkuda ajakohast ja täpset informatsiooni ühes vastuvõetavate ehitustolerantsidega. Seeläbi saab lühendada kriitilise raja kestust, kuna enne järgnevate projektsete elementidega alustamist väheneb vajadus teostuse mõõdistustele. Samas ei ole see riskivaba, sest üks toode, mis seda protsessi eirab või lihtsalt ei järgi, võib paljusid teisi oluliselt mõjutada. Kuna koondmudeleid kontrollitakse tavalistel koordineerimise koosolekutel, võib tekkida võimalus asju paremini teha, kuna projekteerimine ise on väga visuaalne.

Näited
Elluviimise meeskond peab välja töötama koordineerimisprotsessi, et tuvastada ja parandada võimalikke ohutusega seotud probleeme, vastuolusid, ebatõhusust või tegevusest tingitud mõjusid. Projekti alguses tuleks kehtestada metoodika vastuoludega seotud probleemidest teatamiseks ja nende lõpetamiseks.

Koordineerimis- ja vastuolude vältimise protsessid peaksid hõlmama järgmist tüüpi vastuolusid:

• Kattuvad vastuolud – vastuolud, kus kaks komponenti või süsteemi hõivavad sama füüsilist ruumi, nt pinnaveetoru ja kanalisatsiooni toru. Neid vastuolusid tuleks projekteerimise läbi vältida.
• Ruumivajadusega vastuolud – ruumiosa, mis peaks olema ette nähtud komponentide opereerimiseks ja korrashoiuks. See võib olla ka ajutine nõue ehituse ajal. Sellised ruumivajadused tuleks mudelites identifitseerida "Teenindusala" abil, mis tuleks kaasata vastuolude tuvastamise protsessi.
• Ajapõhised või 4D vastuolud – kus komponendid hõivavad samal ajal sama ruumiosa. Seda tüüpi vastuolusid välditakse ehitusprogrammil põhinevate tööde järjestamisega.

Komponendid peaksid sisaldama informatsiooni alljärgneva kohta:

• Olemasolev
• Lammutatud
• Ehitatav

Kui tööd on etapiviisilised, peaksid komponendid sisaldama informatsiooni selle kohta, millise etapiga need on seotud. Etapi jäädvustamiseks kasutatav atribuut peaks olema projekti jaoks standardiseeritud, et tagada kõigi projekteerijate etapipõhise info järjepidev edastamine. Kui see on asjakohane, tuleks projektinfoga seotud probleemide ja lahenduste edastamisel kasutada ajapõhiseid animatsioone.

Programme / scheduling (4D)

Programmi integreerimine 3D-mudeliga on väga muljetavaldav ja võib olla väga kasulik otsuste tegemisel, mis on seotud:

• Programm – kuna projekti programmid muutuvad keerukamaks, on neid raske kontseptualiseerida. Programmi täiustamiseks võivad eksisteerida teatud võimalused kui muuta teatud tegevuste algust.
• Ehitatavus – ehitustegevuse alustamise ja lõpetamise järjekord ei pruugi olla kõige optimaalsem. Visuaalne hindamine võib avada võimalused selle parandamiseks.
• Tervishoid ja ohutus – koordinaatorid saavad kasu projekti visualiseerimisest selle edenemise ajal ja nad võivad näha võimalusi vältida tervise- ja ohutusprobleeme, mis võib tähendada näiteks optimaalsemalt paigutatud viitade, varikatuste, tõkete jne kasutamist.
• Turvalisus – ehitusplatsid võivad sisaldada alasid, mis vajavad turvamist ja need piirid võivad aja jooksul muutuda. Strateegia ja ehitusprotsessi visualiseerimine võib tagada, et ehitusplatsi optimaalse turvalisuse võimalusi ei jäeta kasutamata.
• Muud tegurid – mida muud tüüpi dokumentide põhjal võib olla keerukas kindlaks teha.

Quantities and Cost (5D)

Kuni ehitusprojekti valmimiseni pole tegelik maksumus teada. Projekteerimise ja ehitamise ajal annavad kuluprognoosid juhiseid selle kohta, milliseid otsuseid saab vastuvõetava riskitasemega jätkamiseks teha.

Lepingunõudena võib kehtestada näiteks mahulise eelarve nõude ning selle kasulikkus sõltub ennekõike selle paikapidavusest. Samas peavad olema paigas teatud mehhanismid, et tulla toime võimalike ebatäpsuste ja mittetäieliku projekteerimisega seotud riskidega, mis võivad oluliselt kahjustada pakkumuse tegelikku maksumust.

On mitmeid tegureid, mis muudavad täpsete koguste genereerimise keeruliseks:

1. Hinnangud – tavaliselt keskenduvad varajased kuluplaanid 50%-le, mis ei ole otseselt seotud ehituselementidega. Inflatsiooni arvesse võttes põhinevad ehitushinnangud pindaladel ja kuludel ruutmeetri kohta, mis põhinevad sarnast tüüpi projektide eelarvetel. Kuigi kuluplaanides on usaldustegur, võib esimesest hinnangust saada soovitud või eeldatav valmis ehitusmaksumus. Eeldusel, et esimene hinnang oli mõnevõrra realistlik, võib kuni tööprojekti täieliku valmimiseni kõrvalekalle ehitatud elementide tegelikust maksumusest olla märkimisväärne. Näiteks põrandapindaladel põhineva kuluhinnangu koostamiseks kasutatud näidisprojektile ei pruukinud kehtida värskemad kütusesäästlikkust käsitlevad eeskirjad, mis võivad nõuda kulude märkimisväärset suurendamist.
2. Projekteerimine on iteratiivne – otsusel muuta üht projektielementi on mõju paljudele teistele projekteerimise valdkondadele. See võib raskendada üksikasjalike kuluplaanide järgimist juba projekteerimise alguses.
3. Projekteerimisnõuded – on traditsiooniliselt esitatud 2D-joonistena koos märkuste, spetsifikatsioonide, ajakavade ja muu toetava dokumentatsiooniga. Koguseid hindavad isikud peavad viitama mitmele infoallikale, et olla kindlad iga süsteemi või elemendi maksumuses. Konfliktseid võimalusi on palju isegi parimate jõupingutuste korral, kuna käimasolevaid iteratiivseid projektmuudatusi tuleb käsitleda mitmes dokumendiallikas.
4. Puudulik tööprojekt – olenevalt hankeprotsessist võib tööprojekt tekkida projekteerimisel või ehitamisel. Isegi tavapäraste lepingute puhul, kus suurem osa tööprojektist tuleks lõpule viia, võivad ajalised piirangud jätta paljud elemendid kirjeldamata, mitte täielikult kavandatuks ja paljud vastuolud võivad jääda lahendamata. Pakkumuse korral peavad eelarve konsultant ja töövõtja mõistma mittetäieliku tööprojekti maksumuse riski, sest vastasel juhul põhjustab see lõpuks ootamatuid pretensioone.
5. Automatiseerimise puudumine – suurem osa kogustest hinnatakse endiselt jooniste, väljavõtete ja spetsifikatsioonide hindamise teel. Isegi kui see teave on mahtude hindamise alustamise ajal täiuslikult kooskõlastatud ja täielik, on koguste genereerimine piiratud aja jooksul vaevarikas, kui seda tehakse käsitsi. Hilisem otsus hinnata projekti mõnda aspekti tulemuse põhjal ei pruugi enne pakkumuse tegemist olla enam võimalik ümber hinnata.

Võimalikud soovitused kuluprognooside parandamiseks on järgmised:

1. Projekti tähtajad – projekti oluliste tähtaegade juures tuleb koostada kuluprognoosid, mis annavad alust järgmisse etappi minna/mitte minna. Iga projektietapp ei tohiks alata ilma eelmise projektietapi kulusid kajastamata.
2. Projekti elluviimine – sarnaselt sellele, kuidas elluviimise plaani kasutatakse projektiinfo elluviimise haldamiseks, on kasvav suundumus kasutada projekti elluviimise plaane projekteerimisotsuste ja -eelduste dokumenteerimiseks, pöörates suuremat tähelepanu riskihinnangutele. Hästi teostatud projekt peaks vältima märkimisväärset ümbertööd, mis on väga töö- ja ajamahukas mitte ainult koguseid tootvate osaliste, vaid kõigi elluviimise meeskonna liikmete jaoks.
3. Ühtne andmekeskkond (CDE) – informatsioon on igas projektietapis tehtavatele otsustele võtmetähtsusega ning ühtset andmekeskkonda ja muid juurdepääsetavaid süsteeme tuleks kasutada tagamaks, et kõigil projektimeeskonna liikmetel on juurdepääs ajakohasele ja kontrollitud informatsioonile.
4. Looge mahtude väljavõte mudelite baasil – tagamaks koguste täpne mõõtmine mudelite põhjal:

• Projekteerijatel peaks olema hea arusaam sellest, mida igas projekti etapis modelleeritakse. Üksikasjalik vastutuse maatriks peaks selle jaoks väga hea viite andma. Kui on ebaselgust, tuleks otsida selgitust. Kas näiteks ukse varustuse saab välja võtta ukse spetsist?
• Mudelite elemendid peaksid sisaldama klassifikaatoreid, mis põhinevad kokkulepitud klassifikatsioonisüsteemil, nt CCI, RDS, Uniclass, ARM, NRM, ICMS. Kuluarvestustarkvara peaks suutma klassifitseerimist toetada ja suutma genereerida väljundeid, näiteks aruandeid, mis pakuvad otstarbekohast teavet. Näiteks võib projekti varases staadiumis olla vastuvõetav teadmine, kas post on ümmargune või ruudukujuline, kuid ehitushanke maksumuse mõistmiseks on vaja viimistlusklassi. Samamoodi võib olla õige varakult teada, kas vahelagi on olemas või mitte, kuid hiljem on oluline teada, millist tüüpi lagi on kavandatud. Paljud klassifikatsioonisüsteemid on olemuselt hierarhilised, mis võimaldab informatsiooni täpsustada kui elemendi kohta käiv info täpsustub. Ümbertegemise vähendamiseks peaksid projekteerijad ideaaljuhul tagama, et nende projektelementidele lisatakse asjakohased klassifikaatorid ning eelarvestaja või kulukonsultant uuriks informatsiooni ja kontrolliks selle sobivust.
• Projekteerijatel peaks olema hea arusaam ehitatavusest ja konstruktsioonielementide kokku monteerimisest, tagades, et modelleeritavad elemendid sobivad klassifitseerimiseks ja kvantifitseerimiseks.

Analysis

Analüüsitarkvara kasutatakse mudelite hindamiseks ja analüüsi tulemuste põhjal optimeeritud projektlahendite soovitamiseks. See võib asendada käsitsi tehtavaid hindamismeetodeid või võimaldada meetodeid, mis ilma sobiva tarkvarata poleks mõeldavad.

Analüüsitarkvarad võivad olla alljärgnevad:

1. Integreeritud BIM tarkvarasse (süsteemi)
2. BIM-tarkvara (süsteemi) pistikprogramm
3. Eraldi tarkvara, mis impordib BIM-mudelite versioone
4. Eraldi tarkvara, mis kasutab BIM-mudelitest eksporditud andmeid
5. Eraldi tarkvara, mis sisaldab kahesuunalist infovahetust geomeetrilise ja analüütilise mudeli vahel

Mõned analüütilise tarkvara süsteemide näited on alljärgnevad:

• Tehnosüsteemide toimivuse analüüs
• Energiaanalüüs
• Valgustuse/päevavalguse analüüs
• Konstruktsioonide analüüs
• Külmasilla arvutus
• Drenaaži arvutus
• Inimeste liikumise ja jälgimise analüüs
• Evakuatsioonimarsruudi modelleerimine
• Sõidukite liikumisanalüüs ja jälgimine

Näited

• Geograafiline asukoht – vara asub geograafiliselt reaalses asukohas. Varajased projektvalikud võivad sisaldada mitmeid variatsioone, mida saab hinnata, et valida kõige optimaalsem variant
• Ruumiline koordineerimine – mudelite elemendid paiknevad ruumiliselt üksteise suhtes viisil, mida tarkvara saab arvesse võtta
• Materjalid – mudelid võivad sisaldada andmeid tegelike materjalide kohta, mida saab kasutada soojuserijuhtivuse, massi, peegelduvuse ja paljude muude hinnatavate omaduste määratlemiseks

Olulised kaalutlused analüütiliste mudelite puhul:

• Väga vähesed projektid sisaldavad ühte mudelit. Tavaliselt on vähemalt üks konstruktsiooni, arhitektuuri ja tehnosüsteeme esitav mudel ning suuremate projektide puhul võib neid olla palju rohkem. Arvesse tuleks võtta, kuidas analüüsitarkvara paljude mudelitega töötab.
• Analüütilised mudelid teevad väga keerukaid arvutusi ega vaja sageli väga üksikasjalikke geomeetrilisi mudeleid. Mõnel juhul mõjutab liiga palju üksikasju arvutuste toimivust.

Animations and visualisations

Kuigi varajased ideekavandid või mahumudelid võivad vajada eraldiseisvaid mudeleid, tuleks võimaluse korral vältida eraldi mudeleid, mille ainus eesmärk on luua animatsioone või visualiseerimisi. Dubleerimise ja ümbertöötamise vältimiseks peaksid animatsioonid ja 3D-kujutised kasutama projektmudeleid. Mudelite ruumiline paigutus peab olema hästi määratletud. Vältima peab olukorda, kus ehitis paigutatakse olemasolevale maa-alale eelduste põhjal või et uus ehitis kattub olemasoleva ehitisega. Koordinaatide süsteem ja tolerantsid tuleks määratleda projektiinfo standardis. Materjalid tuleks lisada mudelitesse sobivas projekti etapis. Võimaluse korral tuleks materjalide palett (valik) hoida lihtsana, eriti projekteerimise varasemates etappides. Kui kombineeritakse mitu projektmudelit, on see eriti oluline. Arvesse tuleks võtta võimalikke väljundeid. 

Visualiseeringuid võib liigitada järgmiselt:

• Visuaalne uuring – ehitise või vara lihtne kujutamine
• Vaade – ehitise või vara kujutis, mis annab edasi kontseptsiooni või uuringu kujunduslahenduse osas
• Kontrollitud vaade – ettepaneku asukoha, kuju ja suuruse täpne kujutamine kõrge eraldusvõimega fotol koos välise välimuse täpse kujutisega
• Animatsioonid – võivad olla väga sarnased visualiseeringutele, kuid nähtava geomeetria ja eraldusvõime osas tuleb järeleandmisi teha, et minimeerida täisanimatsiooni renderdamiseks kuluvat aega. Animatsiooni failisuurust tuleb arvesse võtta, kuna paljud animatsioonid on nüüd saadaval võrgust vaadatavatena.
• BIM visualiseerimismudelid – need on üksikasjaliku BIM-mudeli alammudelid mis tahes konkreetses etapis, mida saab sidusrühmadega veebis või mobiilistel seadmetel jagada projekteerimise allkirjastamiseks, kooskõlastamiseks, kohapealseks kontrollimiseks või muuks. Need mudelid võimaldavad mittetehnilistel huvirühmadel mudelit ette kujutada ja BIM-andmebaasist sõltumatult päringuid teha.
• Virtuaalreaalsus (VR) ja liitreaalsus (AR) – tutvustab mängumaailma tehnoloogiaid, mis võivad hästi rakendatult olla väga keerukad ja muljetavaldavad. Sarnaselt animatsioonidega töödeldakse mudelite geomeetriat ja materjale spetsiaalses visualiseerimis- või mängutarkvaras, kuid animatsioonifaili asemel kujutavad need virtuaalset renderdatud stseeni, mis sobib vaatamiseks peakomplektide või prillidega. Geomeetria ja materjalide taset tuleb sageli rohkem optimeerida kui animatsioonide oma või virtuaalset stseeni võib olla vaja piirata, nii et kui eri etappidel on vaja mitut väljundit, on vaja väga hoolikat planeerimist, et vältida olulist ümbertegemist.

Elementide klassifitseerimine mudelis võib protsessi palju lihtsamaks muuta. Näiteks võib tehnosüsteeme avatud lagede korral liigitada erinevalt varjatud lagede kasutamise korrast.

Inspection and test plans

Kontroll- ja katseplaan on dokument, mis kirjeldab ehitustööde konkreetse elemendi kvaliteedikontrolli ja -tagamise haldamise kava, mis annab informatsiooni nõuete kohta, ülevaate kasutatava(te)st meetodi(te)st, asjaomaste osaliste kohustustest ja vastavuse kontrollimiseks esitatavad dokumentaalsed tõendid. Kontrollid ja katsed peaksid moodustama ühe osa kontroll- ja katseplaanist, mis sisaldub kvaliteedi tagamise kavas, mille töövõtja esitab määravale osalisele heakskiitmiseks.

Kontrollplaan võib sisaldada:

Läbiviidav ülevaatus – nt tuletõkke paigaldamine põrandaplaadi ja välisvoodripaneelide liitekohas ning uste paigaldusavades.

• Kinnitamiseks vajalikud nõuded võivad hõlmata alljärgnevat:
  • Joonised (sh märkused jooniste kohta)
  • Projektlahendi spetsifikatsioonid
  • Regionaalsed / Euroopa / rahvusvahelised standardid
  • Tootjate nõuded
  • Lepingulised nõuded
  • Planeerimistingimused
  • Ehituslikud erinõuded
  • Seadusandlikud nõuded
  • Saadud õppetundide töötoad
  • Näidis ja võrdlusalused
• Valideerimisnõuded – kontrollib, kas toode või teenus teeb seda, milleks see on mõeldud; et see vastab üksikasjalikele projekteerimisnõuetele. Valideerimine võib olla pädeva isiku kiire kontroll, kuid see võib olla teatud aja jooksul läbi viidud testide kompleks, mille tulemuseks on pädeva isiku poolt allkirjastatud aruanne.
• Sagedus – kui sageli kontrolli tehakse, nt siis kui iga üksus tarnitakse, kui ruumiala on valmis jne.
• Vastutus – kes kontrolli teostab?
• Ootekohad – kujutab protsessi kestel olevaid vahehetki. Näiteks paigalduse kontrollimine enne küttesüsteemi torude paigaldamist.
• Kinnitus – kes allkirjastab kontrollimise lõpetamise? Kas on vaja mitut allkirja?

Iga kontroll peaks sisaldama kontrollitavate elementide üksikasjalikku vormi. Näidisküsimused võivad hõlmata alljärgnevat:

1. Kas vastav isolatsioon on paigaldatud vastavalt spetsifikatsioonile ja aktsepteeritud võrdlusalusele?
2. Kas esineb vastuolusid, mis takistavad isolatsiooni paigaldamist vastavalt aktsepteeritud kriteeriumidele?
3. Kas isolatsiooni paigalduses on lubatud hälvetest suuremaid tühimikke?

Eelnevate küsimuste kinnitamiseks võiksid fotod täita väga olulist rolli/eesmärki. Kontroll- ja katseplaanide näidistabel on toodud allpool.

Tabel. Kontroll- ja katseplaanide näidistabel.

Ülevaatuse nõuetele mittevastavuste olemasolu korral tuleks need esitada defektidena. Defektid tuleks klassifitseerida sõltuvalt defekti raskusastmest.

• Vaatlus – ebakvaliteetne töö, kuid mitte defektne. Hilisemad samalaadsed tähelepanekud loetakse puudulikuks.
• Mittevastavus – defektne ja tuleks kõrvaldada piiratud aja jooksul. Vaidluse all olevad mittevastavused võivad muutuda defektideks.
• Defekt – lepinguline defekt, mille puhul väljamakse peetakse kinni seni, kuni töövõtja või teine osaline on defekti kõrvaldanud.

Joonis. Ülevaatamise ning testimise protsess.

Määrav osaline peaks kaaluma, kuidas katseid ja ülevaatusi hallatakse. Nad võivad soovida jätta töövõtjale üksikasjaliku protsessi esitamise, kuid nad võivad soovida ka kaaluda kasutatava tarkvarasüsteemi määratlemist ja selle süsteemi jõustamist, et andmed ja aruandlus oleksid määrava osalise kontrolli all. Igal juhul peaks määrav osaline hindama täielikult kõiki töövõtja ettepanekuid ning tagama, et kontrolli- ja katseplaanid on asjakohased ning täielikult läbi viidud ja õigeaegselt lõpule viidud. Kontrollplaani edukas läbimine võib olla oluline projekti või organisatsiooni KPI (ingl key performance indicator), mida saab hõlpsasti mõõta, kui seda teha metoodiliselt, kasutades kindlat tarkvara.

Kontrollide planeerimise periood on sageli väga lühike ja seda tuleb teha ettevalmistava perioodi jooksul, määramise ning ehituse alustamise vahel, mis isegi väga suurte ja keerukate projektide puhul ei ole pikem kui paar nädalat. Standardne ülevaatuste ja testide ajakava peab olema paigas mistahes projekti juures ning ka ebamäärasustele kuluv aeg juhul kui standardseid ülevaatuseid ja teste pole määratletud. Klientidel võib olla mõistlik taotleda pakkumusprotsessi osana näidisülevaatus- ja katseplaani või väga suurte projektide puhul etalonkontroll- ja katseplaani. Näiteks tuleohutusega on hetkel mitmeid tööstusstandardeid, mis võivad seda protsessi aidata.

Tehnilisi lahendusi tuleks põhjalikult kaaluda kontrollide ja katsete läbiviimisel. Isegi kõige elementaarsemad tahvelarvutis kasutatavad lahendused on tõhusamad kui paberkandjal olevad, mis nõuavad palju käsitsi töötlemist. Suuremate projektide puhul võib optimaalseim lahendus olla varade tuvastamine enne ehitamist. See võib anda märkimisväärseid võimalusi paremaks planeerimiseks, kuna ülevaatusi ja katsetusi on lihtsam läbi viia, kuna varade nimekiri on juba kindlaks tehtud ja seda ei pea enam kokku koguma erinevatest allikatest nõutud ajahetkeks.

Handover of informatio

Üleandmise dokumentatsioon koosneb:

1. Ohutustoimik, mis tagab vastavuse ehitusega seotud seadusandlikele eeskirjadele
2. Kasutus- ja hooldusjuhendid, mis tagavad, et üleantavat ehitist saab ohutult ja tõhusalt kasutada.

Üleandmisdokumentatsiooni koostamist tuleb alustada võimalikult varakult ehitusetapis, kuna see nõuab märkimisväärset planeerimist, et tagada informatsiooni saamine kõigilt projekteerijatelt ja töövõtjatelt. Suuremate ehitiste puhul on see paljude inimeste jaoks märkimisväärne ja aeganõudev ülesanne.

Määrav osaline võib kaaluda spetsiaalsete tarkvarasüsteemide kasutamist, mis on kohandatud üleandmise dokumenteerimiseks, mida turul on üksjagu. Need süsteemid on üldiselt andmebaasipõhised ja pakuvad paremaid võimalusi üleandmisinfo sidumiseks varadega ja ka ülevaatustega.

Näited
Ohutustoimik võib sisaldada infot lõpetatud konstruktsiooni kohta, mida vajatakse hilisemas korrashoius või renoveerimises. Kohe pärast määramist kehtestab kliendi esindaja ohutustoimikute ning kasutusjuhendite vastuvõtukriteeriumid, mis tuleb esitada määravale osalisele kinnitamiseks. See peaks sisaldama alljärgnevat:

1. Strateegiat üleandmisdokumentide edastamiseks staadiumites/asukohtades, kui see on projekti jaoks asjakohane.
2. Ehitiste toimimiseks kriitilise tähtsusega toimikute tuvastamise strateegia kui need on vajalikud käitamise esimesel päeval, samas kui mõned failid esitatakse määrava osalisega kokkulepitud ajavahemiku jooksul pärast üleandmist.
3. Kliendi esindaja strateegia üleantava informatsiooni jagamiseks, kontrolliks ning kinnitamiseks kõikidelt projektis osalejatelt, kes panustavad üleantavasse informatsiooni. See peab sisaldama alljärgnevat:

• Üleandmise vastavuse kontroll-loend ja allkirjadokument, mis väljastatakse määravale osalisele, milles võetakse kokku üleandmise dokumentatsiooni struktuuri iga jaotise ja alajaotuse täielikkus.
• Registrid, mis tuvastavad iga faili ja CDE-s olevale vastavale versioonile vastava versiooni.

Määrava osalisega lepitakse kokku strateegia jooniste ja dokumentatsiooni tuvastamiseks, mille puhul tuleb vastuvõetavate tolerantside piires kontrollida, kas see on vastavuses ehitatule.

Ettekirjutavam lähenemine võib täpsustada üleandmise dokumentatsiooni üksikasjalikku struktuuri või määrata kasutatavad tarkvarasüsteemid ja heakskiitmisprotsessi. See oleks algselt kasulik kontrollnimekirjana, kuna elemendid, mis ei ole projekti osa, võib välja jätta ja informatsiooni seada prioriteetseks. Suurem osa informatsioonist on üleandmise kuupäeva jaoks kriitilise tähtsusega, kuid osa infost võib järgneda hiljem. Suuremate projektide puhul võib olla kasulik määratleda näidisüleandmine enne tegelikku üleandmist. Allolevas tabelis on esitatud näide.

Tabel. Üleandmise kontrollnimekirja ning lõpetamise näide.

Tulemuste register peaks võimaldama jälgida iga infokonteineri sobivust. Võimaluse korral tuleks iga infokonteineri versiooni ja sobivuse oleku jälgimiseks kasutada ühtset andmekeskkonda (CDE).

Tabel. Üleandmise registri näide.