Yhteistyöalustassa otetaan vastaan suunnitteluaineisto ja lähdetään pyörittämään rakentamisen aikaista toimintaa.

Jukka Kivelä ja Erno Tiensuu

Kolmiosaisen blogisarjan toisessa osassa siirrymme suunnittelusta rakentamisvaiheeseen. Rakentamisen yhteistyöalusta mahdollistaa tietomallipohjaisen kommunikoinnin.

Tällä hetkellä infrahankkeen rakentamisvaiheessa saattaa olla käytössä useita erillisiä järjestelmiä, kuten työmaan dokumentointi, työkoneiden ohjaus ja seuranta sekä projektipankki. Ideaalitilanteessa toimitaan kuitenkin yhdellä yhteistyöalustalla, jossa on mukana suunnittelija, valvoja, tilaaja, urakoitsija ja mahdollisesti muitakin sidosryhmiä. Alustalla kommunikoidaan tietomallin kautta: kaikki näkevät mallin ja muun tarvittavan dokumentaation sekä pystyvät keskustelemaan yksityiskohdista.

Yhteistyöalustassa otetaan vastaan suunnitteluaineisto ja lähdetään pyörittämään rakentamisen aikaista toimintaa. Hanketyypistä riippuen esimerkiksi urakoitsija ja suunnittelija voivat kommunikoida alustan kautta, ja kommunikaatio dokumentoidaan automaattisesti. Kun hanke alkaa olla päätösvaiheessa ja poikkeamat on saatu kiinni, urakoitsija täydentää suunnitelmamallia poikkeamatiedoilla, ja lopputulos viedään omaisuudenhallintaan ja kunnossapitoon.

Tilaajan projektipankki tarjoaa paikan hankkeen projektidokumenteille, jotta kaikki löytyy samasta paikasta. Parhaassa tapauksessa rakentamisen yhteistyöalusta ja tilaajan projektipankki ovat käytännössä sama alusta. Kun hanke on kokonaisuudessaan yhden ja saman palvelun alla, ei tule ongelmia esimerkiksi erillisten lisensointien kanssa.

Perinteinen sääntö on, että kun osapuolten määrä hankkeessa kasvaa, tulee myös enemmän haasteita toimintamallin kanssa. Suunnittelu on vielä aika selkeää, mutta rakentamisen aikana ketju on kaikkein laajimmillaan ja toimijoita on paljon. Toimintojen pitää olla yksinkertaisia, jotta ne voidaan ottaa käyttöön ja kouluttaa nopeasti.

Hyvä yhteistyöalusta sisältää raportointityökaluja, tietomallin tarkastelun, mahdollisesti kilpailutuksenkin, työmaan hallinnan ja toteumien hyväksynnät sekä rakentamisen seurannan, eli missä mennään aikataulun ja kustannusten suhteen.

Uudempana asiana voidaan seurata myös polttoaineiden kulutusta ja koneiden käyttöä, ja sitä kautta tehostaa työmaata. Kannattaako olla kahdeksan konetta, jotka tekevät 50 prosenttia päivästä tehokasta työtä, vai riittäisikö seitsemän tehokkaammin työskentelevää?

Rakentamisen suunnittelussa voidaan laajemminkin optimoida erilaisia rakennevaihtoehtoja sekä pienentää kuljetuksen kustannuksia ja hiilijalanjälkeä. Aiemmin hiilidioksidipäästöjä on laskettu Exceleillä, mutta nyt meillä on jo ohjelmistoja, joilla sitä voi tehdä. Erityisesti suurissa hankkeissa se kannattaa.

Täydennetään poikkeamat suoraan suunnitelmamalliin

Ehdottomasti tärkein asia rakentamisvaiheessa on poikkeamatiedolla täydennetty suunnitelmamalli, joka saadaan lopputuloksena rakennuttamisen yhteistyöalustasta. Eli ei lähdetä mallintamaan uudestaan koko työmaata, vaan hyödynnetään elinkaaren alussa tuotettua suunnitteluaineistoa.

Poikkeamille on lukuisia syitä, mutta projektissa pitää tuoda esille, minkä takia on poikettu suunnitellusta rakenteesta. Koneohjauksen kautta saadut poikkeamat päivitetään suunnitelmamalliin. Poikkeamatiedolla täydennetty suunnitelmamalli kertoo, miten työt ovat menneet työmaalla sekä sisältää mittaukset ja koko toteaman. Sen pitää mielestämme olla lähtökohta mallien suhteen. Tilaajakin varmasti edellyttää, että toteumavertailu on tehty suunnitelmamalliin, jonka perusteella työ on tilattu.

Olemme kuulleet, että joillain työmailla lähdetään mittaamaan kaikkea uudestaan. Se on päällekkäistä työtä ja tuo lisäkustannuksia, mutta jokin syy siinä varmasti on taustalla. Voi olla, että suunnitteluaineisto ei siirry riittävän luotettavasti urakoitsijalle. Meidän pitää alana varmistaa, että suunnittelussa syntyvä data on täysimääräisesti käytettävissä urakoitsijan puolella ja siihen voidaan luottaa.

Tällä hetkellä poikkeamatietoa tarkastellaan hyvin pistemäisesti: otetaan tarke yhdestä pisteestä, ja se joko on toleranssissa tai ei ole. Saattaa näyttää, että piste on 5 cm toleranssin ulkopuolella, mutta mikään ei kerro miksi näin on, ellei sitä verrata laajempaan kokonaisuuteen. Voi olla, että tarke on vain otettu 5 cm väärästä kohdasta. Poikkeama ei välttämättä tarkoita sitä, että rakenne ei olisi toleranssissa tai ei toimisi.

Yksittäisten pisteiden tarkastelun sijaan pitäisikin vertailla laajempia kokonaisuuksia, pintoja ja useita pisteitä kerrallaan. Kaivinkone pystyy edelleen vain pistemäiseen mittaukseen, joten käytännössä laajempi tarkastelu vaatii, että kaivinkoneen tekemä pistemäisten mittausten verkko mallinnetaan pinnaksi. Toinen vaihtoehto on tietysti käyttää skanneria, mutta se vaatii työvoimaa kartoittamiseen.

Kuka määrittelee kunnossapidon saaman tietosisällön?

Yleistasolla suunnittelu toimii hyvin tietomallipohjaisesti, ja putkesta saadaan määrämuotoista dataa hyödynnettäväksi. Haasteita tulee siinä, miten rakentamisesta mennään eteenpäin kunnossapitoon. Siihen haetaan parhaillaan toimintaperiaatteita hankkeittain, ja toimintamalli muodostunee lähivuosien aikana. Meiltäkin on pian tulossa tuote, jolla voidaan hallita työmaata tietomallipohjaisesti yhdellä alustalla.

Kunnossapitoa voidaan ajatella esimerkiksi data drop -konseptin kautta. Kunnossapito on viimeinen vaihe, joka vastaanottaa tiedon ja saa tietorikkaimman sisällön. Sen takia kunnossapidon pitäisi myös määritellä mitä tarvitaan, jotta he voivat hyödyntää suunnittelun ja rakentamisen aikaisia tietoja. Eli lopputuloksen määrittely tulee aina hankkeen seuraavalta vaiheelta.

Me peräänkuulutamme tilaajan vastuuta. Kun lähdetään rakennuttamaan, pitää katsoa kunnossapitäjänkin tarpeita ja ottaa ne huomioon. Rakentamisessa tyypillinen esimerkki on tiivistäminen. Kun rakennekerroksia tiivistetään, kunnossapitoa voisi kiinnostaa lukea dokumenteista, onko tehty kantavuuskokeita tai minkälaisia kerrosvahvuuksia on käytetty. Tähän liittyy myös rakentamisen takuu ja sen valvonta. Jos rakenne painuu vaikka viiden vuoden aikana, päästäänkö kiinni aineistoihin, joita siitä on tuotettu?

Lue myös blogisarjan ensimmäinen osa tietomallipohjaisesta suunnittelusta!

Tietomallipohjaisen suunnittelun dataa tulisi hyödyntää mahdollisimman paljon läpi hankkeen elinkaaren.