Suomessa ympäristöministeriössä vireillä olevat RYHTI-hanke ja KRL-uudistus sovittavat maamme rakentamisen tiedonhallintaa ja sen toimintoja kansainvälisiin standardeihin sekä ilmastotavoitteiden vaatimuksiin. Tavoitteena on yhtenäisen suunnitelmatiedon hyödyntäminen koko rakennuksen eli omaisuuskohteen elinkaaren ajan. Yhtenäinen IFC4-muodossa toimitettava tietomalli tulee olemaan pakollinen rakentamisen luvanhaussa.
Perinteinen käsitys ja vakiintunut toimintatapa tiedonsiirrossa on yksinkertaistetusti yksisuuntainen ja lineaarinen. Tällöin koko projektin suunnittelun ja rakentamisen tehtävät on pilkottu peräkkäisiksi vaiheiksi. Esimerkiksi arkkitehti toimittaa ”lupakuvat” sopimuksensa mukaisesti.
Jos perinteinen prosessi pilkotaan palasiksi rakennusosan suunnittelutehtävien tarkkuudella, se voi mennä esimerkiksi näin:
Perinteisessä prosessissa kukin osapuoli toimitti omat piirustuksensa, jotka siirtyivät lähtötiedoiksi ketjussa seuraaville. Yhdistelmäpiirustus syntyi panemalla alakohtaiset piirustukset valopöydälle päällekkäin. Tämä oli helppoa, koska mukana oli vain grafiikkaa – selostukset ja varusteluettelot toimitettiin erikseen. Käytännössä tässä tapauksessa työmaalla paikalle asennettiin vastaava vesikaluste, jonka dokumentit päätyivät huoltokirjaan. Prosessi oli ja on viritetty pääosin alasvirtaavaan tiedonsiirtoon: tilaaja -> arkkitehti -> muut suunnittelijat -> työmaa.
Vastaavassa optimaalisesti tehdyssä tietomallipohjaisessa prosessissa arkkitehti sijoittaa suunnitteluohjelmassa (3D) vesikalusteen, johon eri osapuolet tukeutuvat ja lisäävät tietoa omissa työvaiheissaan. Mikäli osapuolet mallintavat sisältönsä, esimerkissä vesikalusteen, päällekkäisesti (ARK-/LVI-malleissa), sirpaloituu tieto eri ohjelmistoissa. Sama tilanne syntyy myös, jos osapuolet mallintavat muita rakennusosia, esimerkiksi pilareita, päällekkäisesti erillisissä arkkitehti- ja rakennemalleissa.
Tehtäväluettelon näkökulmasta arkkitehdin tilavarausobjekti (vesikaluste, pilari tai mikä tahansa muu) korvautuu erikoissuunnittelijan tarkemmin määrittämällä rakennusosalla. Samalla osa arkkitehdin asettamista tiedoista – esimerkiksi väri, muoto tai tuotteen tiedot – tuhoutuu tai muodostuu päällekkäiseksi, ristiriitaiseksi. Mikäli rakennesuunnittelija määrittää hiilijalanjälkeen vaikuttavat tekniset ominaisuudet erilliseen rakennesuunnittelumalliin, eikä niitä päivitetä arkkitehtimalliin, syntyy vastaava ristiriita.
Tiedonhallinnan näkökulmasta yllä kuvattu prosessi on erittäin puutteellinen. Parempi prosessinhallinta ja tuotetiedon teollinen vakiointi on välttämätöntä tiedonhallinnan ISO-19650-standardin toteuttamiseksi – sekä palvelemaan muita sirpaloituneita prosesseja, joita ei kaikkia välttämättä voi hallita. Prosessi on rikki, jos eri osapuolet täyttävät päällekkäisten mallien ja rakennustuotteiden erilaisia ristiriitaisia tietokenttiä.
Vaikka edellä mainitut tietokentät vakioituisivat kaikkiin eri osapuolten käyttämiin ohjelmiin, pitää niitä hallita jossakin keskitetysti. Lisäksi jos pelkästään suunnittelijoilla on suora mahdollisuus tiedon rikastamiseen, ei yhtenäistä As-Built-tietosisältöä voi syntyä. Keskitetylle tiedonhallinnalle on siis tilaus.
Building Lifecycle Intelligence -ratkaisun tarkoitus on korvata tilaajan sekä eri suunnittelu- ja rakentamisen toimijoiden siiloutunut tieto yhtenäisellä dRofus-tietokannalla. Yhtenäinen tietokanta mahdollistaa tiedon jatkuvan käsittelyn koko hankkeen ajan. Tämä tietokanta on jaettu kaikkien osapuolten kesken, ja siihen voi olla yhteydessä selaimella miltä tahansa laitteelta. dRofus-tietokantaan voi myös linkittää minkä tahansa muun tietokannan. Yhtenäinen tietokanta on keskeinen projektin näkökulmasta – eikä vain koska se korvaa erilliset, vaan myös koska se on yhteistyöalusta kaikille.
Yhtenäisen tiedonhallinnan hyödyt ovat valtavat, pelkästään jo siksi, että kaikki osapuolet saavat mahdollisuuden tiedon reaaliaikaiseen käyttöön.