Rakennusala on kehittynyt manuaalisista piirtopöytien ajoista sähköisiin 3D-tietomalleihin ja lukemattomiin tietojärjestelmiin – silti tuotetun datan lisäarvo jää usein hyödyntämättä. Syynä ovat muun muassa siiloutuneet prosessit ja rakenteettoman tiedon olematon virtaus. Olemme syyllistyneet valedigitalisaatioon: pdf-tiedosto on digitoitua, ei rakenteisesti jäsenneltyä digitalisoitua dataa. Miten hyppäämme mukaan trendiin ja siirrymme tekoälytuettuun datatalouteen, jossa tieto liikkuu rakenteisessa muodossa, rikastuu ja luo kilpailuetua?
Vain muutamassa vuosikymmenessä paperipiirustukset ovat vaihtuneet tietomalleihin, ja lähes jokaisessa organisaatiossa pyörii kymmeniä, ellei satoja digitaalisia järjestelmiä. Olemme iloinneet modernin öljyn – datan – määrän kasvusta, koska se paljastaa prosessiemme vaihtelun ja hukat. Samalla olemme jähmettyneet siiloihin: toimimme omissa järjestelmissämme toistamalla samoja virheitä tietämättä, että myös muut kamppailevat saman ongelman kanssa. Dataa syntyy, mutta se ei virtaa järjestelmästä toiseen – ja virtaamatta se ei muutu arvoksi.
Rakennusalan digitalisaatio on hionut monia perusprosesseja paremmiksi, mutta tiedon rakenteisuus ja yhteentoimivuus ovat jääneet sivuun. Suunnittelussa tuotettu, rikastettavissa oleva digitaalinen 3D-informaatio latistuu arvoketjun alavirrassa metatiedottomaksi paperiseksi 2D-tasokuvaksi asentajan käteen. On vaikea rakentaa yhdessä samaa hanketta, kun jokaisella taholla on erilaiset ohjeet.
Monelle pk-yritykselle datavetoinen muutos on hankalaa: resurssit, osaaminen ja ajankäyttö ovat kiven alla. Datapohjaisia palveluja tai teollisen internetin mahdollisuuksia ei nähdä kasvun ajureina, kun perinteinen tuotekehitys ja tuotannon tehostaminen ajavat edelleen kärjessä. Lisäksi data jää usein järjestelmiinsä lukituksi: se on käytettävissä vain siellä, missä se syntyy – ei analysoitavissa, yhdistettävissä tai raportoitavissa yli toiminto- tai organisaatiorajojen. Pahimmillaan käyttäjät tulkitsevat ja käsittelevät käyttämiensä järjestelmien dataa omien termiensä kautta, mikä heikentää tiedon laatua entisestään.
Hyvälaatuinen, luotettava ja saatavilla oleva data on kaiken kehittämisen lähtökohta. Pk-yrityksille datan hyödyntäminen voi olla jopa suhteellisesti arvokkaampaa kuin suurille – ketteryys taipuu nopeammin paremmaksi päätöksenteoksi ja palveluiksi. Todellinen arvo syntyy, kun data-aineistoja yhdistetään ja niistä jalostetaan tietoa tai palveluja.
Varastossa lepäävä puolivalmiste ei tuota arvoa – ei myöskään järjestelmiin ripoteltu ja niihin lukkiutunut data. Pdf-muotoisen suunnitelman siirtäminen servereille ei vielä avaa patoa. Informaatio tulee tehdä rakenteelliseksi, saavutettavaksi ja linkitettäväksi.
Rakennusala on verkostolaji. Arvo syntyy, kun tieto kulkee saumatta suunnittelusta hankintaan, toimitusketjusta työmaalle ja lopulta rakennuksen ylläpitoon – ja takaisin oppimissilmukaksi. Liiketoimintamalleja on uudistettava tuottamaan rakenteista tietoa, joka virtaa reaaliajassa toimijoiden, tietokantojen ja prosessien välillä. Suomella on kaikki edellytykset rakentaa skaalautuvia rakennusalan datatalousmalleja: tiiviit verkostot, laadukkaat tutkimusinstituutiot sekä yliopistot ja adaptiiviset pk-toimijat. Potentiaali innovatiivisten liiketoimintamallien viemiselle kansainvälisille markkinoille on suuri.
Olemme ajautuneet ojaan: dataa on, mutta todellinen arvo syntyy vasta sen virtaamisesta ja yhdistämisestä. Kun murramme siilot, rakennamme yhteisen kielen ja johdamme dataa kuin tuotetta, avautuu tie tekoälytuettuun tuottavuusloikkaan. Onko roolisi disruptoida vai olla disruptoitavana?
Tätä artikkelia on kommentoitu 6 kertaa
6 vastausta artikkeliin “Rakennusalan datatalous: siiloista ekosysteemeihin”
Tuotantovaiheeseen saavuttaessa piirrellään yhä editorilla mittaviivoja peedeäffiin eli se digi, mitä hankkeen alussa on ollut, on kyllä melko tarkkaan karissut matkalle.
Muutakin kuin hiuksia sormen ympärille pyörittäneenä voin suorastaan pahoin, kun alan mittaamaan määriä 2D-piirustuksista, kun tiedän minkälaista kalustoa on käytetty silloin, kun niitä suunnitelmia on tehty. Jotenkin sieltä toimistosta pitäisi nyt päästä murtautumaan ulos raksalle sen datan ja tiedon kanssa, joka ihan todellisesti on jo olemassa, mutta joka ei vaan sääsuojan alle pääse.
Sen verran voin paljastaa lisää, että tämä tuska ei koske mitään pientä rakennusfirmaa vaan ihan merkittävän suurta puljua.
Jos jäämme odottamaan ekosysteemien syntymistä on se ikään kuin tekosyy olla tekemättä mitään.
Tottakai tiedon virtaaminen on hyvä asia ja asiat kehittyvätkin siihen suuntaan mutta paras aika aloittaa muutos on nyt.
Suurin ongelma digissä on se ettei sitä hyödynnetä organisaatioissa, ongelma ei ole silloin digi vaan organisaatio.
Ei ole villojen vika jos ne kastuu tai kuran vika jos valut jäätyvät.
Mitä hyvää digi on mm. tuonut ?
Suunnittelu -> BIM, pilvipohjainen yhteistyö -> Vähemmän virheitä, parempi laatu
Kustannukset -> 5D-BIM, data-analytiikka -> Tarkempi kustannusohjaus
Läpimenoajat -> 4D-aikataulutus, modulaarisuus -> Nopeampi rakentaminen
Työmaajohtaminen -> IoT, mobiiliraportointi, dronet -> Tehokkaampi ja turvallisempi työmaa paremman tilannekuvan kautta
Tuotannon kehittäminen -> Lean + data(mm.RTLS), digitaalinen kaksonen -> Jatkuva parantaminen ja tuottavuus
Jotta ne villat ei kastu ja kurat jäädy niin jos vaan ihan ensin opeteltaisiin suunnittelemaan ja rakentamaan..taas. Siihen ei tuota digiä tarvita.
Tottakai perusasiat täytyy osata aina, oli digiä tai ei. Laatu ei synny ohjelmistoista, vaan osaamisesta, prosesseista ja kulttuurista.
Olennaista on huomata, että:
✅ Digi ei korvaa suunnittelua tai rakennustaitoa
➡️ Digi parantaa mahdollisuuksia tehdä ne oikein ensimmäisellä kerralla
Kun tiedämme varmemmin mitä, missä ja milloin tehdään:
Villat eivät kastu, koska suunnitelmat ja työvaiheiden ajoitus ovat synkassa → aikataulutus ja tilannekuva
Kurat eivät jäädy, koska sää-, logistiikka- ja tuotantodata ohjaavat tekemistä
Virheet vähenevät, koska poikkeamat nähdään ajoissa paremman tilannekuvan ansiosta → esim. sijaintidata, fotodokumentointi, digitaalinen tarkastuslista
Ei ole digin, materiaalien tai laitteiden vika, jos niitä ei käytetä järkevästi.
Rakentamisen ongelmat syntyvät usein puutteellisesta tiedonkulusta ja siitä, ettei tieto ole työmaalla siellä missä sen pitäisi olla
Digi on siis läpinäkyvyyden ja oppimisen työkalu tarjoten myös ohjaustietoa päivä sekä viikkojohtamiseen:
Ilman dataa -> virheet huomataan lopussa | datalla -> virheet huomataan heti
Ilman dataa -> jokainen projekti “ensimmäinen laatuaan” | datalla -> toistettavat, kehittyvät prosessit
ilman dataa -> syyllistetään ihmisiä | datalla -> korjataan prosesseja
Lopulta kyse ei ole “digistä vastaan ammattitaito”, vaan:
Ammattitaidosta, jota digi vahvistaa.
Paras aika rakentaa parempaa toimintamallia oli eilen.
Seuraavaksi paras aika on tänään. 😊
Tietomallinnusta tehdään lähes tulkoon kaikissa firmoissa, mutta touhua vaan vaivaa aika yksinkertainen ongelma, jonka vuoksi tieto ei siirry, eikä data ole hyödynnettävissä. Vika, jota paperikuvien / PDF-tiedostojen kanssa ei ole, nimittäin yhteinen, helppokäyttöinen, tietosisällöltään vakioitu ja sovitulla tavalla asiat esittävä käyttöliittymä.
Tänä olen joutunut louhimaan tietoa useampaan isohkon hankkeen tietomalleista ja valitettavasti, edes samasta suunnittelutoimistosta (sama firma, sama paikkakunta) tulevista malleista ei tietosisältö tule ulos samalla tavalla, vaikka ohjeistus on lähteissä ollut sama. Se vaan jonkun päivityksen myötä tai ohjelmistoversion vaihtumisen jälkeen on vaan juuri ratkaisevan verran erilaista, eikä IFC-export toimikaan juuri totutulla tavalla, vaan kaikki on määritettävä uudelleen ja tieto jää puuttumaan.
Ihan himpun verran turhauttavaa puuhaa, kun suunnittelun aloituksesta vielä 3 kk kuluttuakaan eivät kaikki mallit ole samassa koordinaatistossa, osa tiedosto on vain tyhmiä blokkeja, objektit törmäilevät miten sattuu jne. Rinnalle rakennesuunnittelija tuottaa yksinkertaisesta terästungosta ansiokkaita massalistoja hankintaa varten… Ne tulevat suoraan Teklasta, mutta itsehän en pääse niitä hakemaan tai todentamaan, kun eihän niitä kaikkia komponentteja olekaan IFC:hen laitettu mukaan tai edes mallissa, kun ne pitää samaan iakaan tietomalliselosteesta muistaa kaivaa, että nosto-ovien pieliteräkset on vain pohjoissivun ovien ympärillä ja räystästukihanan koko rakennukseen on vain yksi mallinnettu (juu piti tietää, että ne ovat tasan 2,7 m välein ympäri räystäspiirin) jne.
Ohjelmistot ovat aika hyvin yhteensopivia ja tietoa voidaan siirtää, törmäystarkastelut, reikäkierrot jne. onnistuvat, saadaan huomioitua muidenkin tarpeita ja reittejä, mutta kun ei ole juuri ihan pilkulleen tietosisältö etukäteen kaikille joka kerta erikseen määriteltynä, niin ryhtymiseen menee pirusti vaivaa ja silti tietomallikoordinaattorin raporteista joutuu lukemaan, kuin sitä ja tätä puuttuu, attribuutit ovat väärin tai puutteellisia, eikä tiedot vaan ole oikein tai hyödynnettävässä muodossa.
Kauhulla vaan voidaan odotella mitä 1.1.2026 tuo tullessaan, kun rakentamislupaa pitäisi hakea tietomallipohjaisesti, hyvin hyvin väljästi määritellysti toki ja jostain pitäisi kyetä loihtimaan ilmastoselvityksen lähtötiedot ja materiaaliselosteen tiedot..
Muu
Nykytilan konkreettiset haasteet: miksi data ei virtaa?
Kirjoitus havainnoi oikein, että 3D-informaatio ”latistuu” 2D-kuvaksi asentajan käteen. Ongelma on kuitenkin usein syvempi: jopa silloin, kun siirrämme 3D-tietomalleja (kuten IFC-malleja), niiden sisältämä data on usein semanttisesti ”latistunutta” – meillä on 3D-muotoja, mutta ei koneluettavaa tietoa.
Tämä johtuu muutamasta perusasiasta.
Datamallien laatuongelmat: BEP, standardit ja mappaukset
Käytännön työssäni näen jatkuvasti, että suunnittelijoiden tuottamat IFC-tietomallit eivät noudata edes projektin omia tietomalliohjeita (BEP) tai yleisiä standardeja. Tämä on yleinen turhautumisen aihe työmaalla ja jatkojalostuksessa.
Syynä on harvoin pahantahtoisuus. Kuten totesit, suunnittelijoilla on kiire ja resurssipula. Usein syy on tekninen: tietomalliohjelmistojen ”mappaukset” (mappings) eli säännöt, joilla ohjelmiston oma tieto ”käännetään” avoimeen IFC-muotoon, ovat puutteellisia tai väärin asetettuja. Oletusarvoinen ”Vie IFC” -nappi tuottaa harvoin kelvollista dataa.
Toinen syy on se, että monet tietomalliohjeet (BEP) ovat kuten kirjoituksessa mainitaan ”toivelistoja” eivätkä ”sopimusvalmiita pelikirjoja”. Niistä puuttuvat koneellisesti todennettavat hyväksymiskriteerit, jolloin ”valmis” on mielipidekysymys.
Semantiikan ytimessä: IfcType ja luokittelun tarkkuus
Yksi perustavanlaatuisimmista mutta vähiten ymmärretyistä ongelmista on IfcType-olion (tyyppitiedon) virheellinen tai olematon käyttö.
Yksinkertaisesti selitettynä: sen sijaan, että mallissa olisi 100 yksilöllistä IfcObject-ovea, joilla kullakin on samat tiedot, mallissa pitäisi olla 100 viittausta yhteen IfcTypeObject-ovityyppiin (esim. ”OVI-TYYPPI-A”). Tähän tyyppitietoon liitetään kaikki yhteinen tieto (valmistaja, paloluokka, ääniluokka).
Tämän perusasian laiminlyönti tekee tiedostokoosta valtavan , tekee muutosten hallinnasta painajaisen ja, kuten myöhemmin käy ilmi, tuhoaa tietomallin arvon täysin ylläpidon (FM) näkökulmasta.
Tämä semanttinen epätarkkuus näkyy myös karkeissa luokitteluvirheissä. On yleistä, että esimerkiksi ontelolaatta (joka on rakenteellisesti palkki) on mallinnettu IfcSlab-luokkaan (laatta). Vaikka IfcSlab-luokalla voi kuvata ontelolaatan , epätarkka luokittelu hämärtää rakenteen todellisen funktion. Jos emme pysty luotettavasti tunnistamaan edes päärakenteita, miten voimme rakentaa ”tekoälytuettua datataloutta” sen päälle?
Herätys on tapahtumassa: tilaajan rooli ja uudet vaatimukset
Kirjoituksesi ja nämä tekniset haasteet johtavat samaan johtopäätökseen: olemme ajautuneet ojaan. Onneksi herätys on tapahtumassa, ja se tulee kahdesta suunnasta: lainsäädännöstä ja edistyneistä tilaajista.
Pakotettu muotos: laki, datavelka ja hiilijalanjälki
Mitä suurempi ja monimutkaisempi projekti, sitä suuremmaksi kasvaa tämä kuvaamani ”datavelka”. Se on kaiken sen manuaalisen työn, korjaamisen ja arvailun summa, joka syntyy epätarkan ja rakenteettoman datan takia.
Tälle on tultava loppu, ja se loppu on todennäköisesti uusi rakentamislaki (2025).
Laki tulee muuttamaan kaiken. Se edellyttää tietomalleja lupaprosessissa ja, mikä tärkeintä, se määrää pakollisen elinkaariarvioinnin (LCA) eli hiilijalanjälkilaskennan. Nämä tiedot on toimitettava ”koneluettavassa muodossa”.
Tämä uusi laki törmää suoraan nykytodellisuuteen. Kuten huomautettu, hiilijalanjälkilaskenta kärsii, jos materiaalitiedot ovat väärin. Tällä hetkellä toimivaa, automaattista työnkulkua suunnitteluohjelmistoista LCA-laskentaan ei käytännössä ole olemassa. Laskenta vaatii koneluettavaa materiaalitietoa , mutta meidän malleissamme on usein vain tekstikenttiä, kuten ”Betoni” tai ”Villa”.
Uusi laki on ”disruptio”, josta kirjoituksessa kysytään. Se lopettaa ”valedigitalisaation” pakottamalla meidät tuottamaan dataa, jonka laatu voidaan mitata ja todentaa automaattisesti. Hiilijalanjälkilaskelma ei ole mielipidekysymys – se joko toimii tai epäonnistuu datan laadun perusteella.
Todiste olemassa: RAVA3pro ja tilaajan vastuu
RAVA3pro-hankkeessa tilaajat (kunnat) ovat tehneet juuri sen, mitä blogikirjoitus peräänkuuluttaa. Vaikka hanke keskittyi lupaprosessissa vahvasti arkkitehtimalliin , se laajeni määrittelemään tarkat, koneluettavat tietosisältövaatimukset myös talotekniikalle (esim. LVI, SÄHKÖ, RAU). He ovat siirtyneet ”toivelistoista” (BEP) automaattisesti tarkistettaviin sääntöihin.
Nyt on korkea aika myös muiden tilaajien herätä ja ymmärtää tämä. Tilaajan on vaadittava ja mitattava datan laadua.
Kadotettu elinkaari: ylläpidon arvo ja datavelka
Yleinen nyrkkisääntö on, että rakennuksen alkuperäiset rakentamiskustannukset (suunnittelu ja rakentaminen) muodostavat vain noin 10–20 % rakennuksen koko elinkaaren kokonaismenoista. Loput 80–90 % ovat käytön, ylläpidon ja korjausten kustannuksia. Tämä asettaa datan arvon oikeaan mittakaavaan: jos 200 miljoonan euron rakennushanke edustaa vain tätä 20 prosentin osuutta, laadukkaalla datalla pyritään vaikuttamaan myöhempiin, jopa 800 miljoonan euron ylläpito- ja käyttökustannuksiin.
Tämä johtaa meidät suurimpaan yksittäiseen epäonnistumiseen, joka mainittiin myös huomioissani: ylläpidon (FM) datan täydellinen puuttuminen. On käsittämätöntä, ettei ylläpidolle lasketa arvoa. En ole 20-vuotisen urani aikana nähnyt yhtäkään suunnittelumallia, jonka olisi voinut sellaisenaan ottaa käyttöön ylläpidossa.
Esimerkki pumppujen ylläpitotiedoista paljastaa ydinongelman selvästi. Kuvitellaanpa:
Ylläpito tarvitsee 50 identtisestä pumpusta kahdenlaista tietoa :
– Tyyppitiedot (yhteiset kaikille): valmistaja, mallinimi, huolto-ohje.
– Esiintymätiedot (yksilölliset): sarjanumero, asennuspäivä.
Suunnittelija ei ole käyttänyt IfcType-oliota (ks. Osa 2.2), vaan on kopioinut 50 yksittäistä IfcObject-pumppua. Mallissa ei ole olemassa semanttista ”Pumppu-Tyyppi-A” -tyyppikohdetta, johon urakoitsija voisi liittää yhteiset tiedot.
Seuraus: Urakoitsijan pitäisi syöttää yksilöllinen sarjanumero 50 kertaa (tämä on normaalia ja pakollista). Mutta koska IfcType-rakenne puuttuu, hänen pitää syöttää myös yhteiset tyyppitiedot (valmistaja, huolto-ohje) manuaalisesti 50 kertaa, yhden jokaiseen esiintymään.
Tätä jälkimmäistä (tyyppitiedon manuaalista kopiointia) ei tietenkään tapahdu. Dataa ei syötetä, ja malli on ylläpidolle hyödytön.
Tämä on se ”datavelka” kalleimmassa muodossaan. Yksinkertainen, suunnitteluvaiheen tekninen laiminlyönti (IfcType:n puute) aiheuttaa miljoonien eurojen menetyksen rakennuksen elinkaaren aikana (hyödyttömät FM-järjestelmät).
Avaimet ekosysteemiin
Blogikirjoituksesi ydin on oikea: olemme verkostolaji. Arvo syntyy, kun data liikkuu. Kuten huomioissani totesin: mitä useampi pystyy hyödyntämään tietomalleja, sitä tehokkaampaa se on. Meidän on ajateltava laajemmin – koko elinkaari.
Mutta jotta data voi liikkua ja jotta kaikki voivat sitä hyödyntää, meidän on ratkaistava nämä perustavanlaatuiset dataongelmat. Avaimet tähän ekosysteemiin ovat olemassa, ja ne liittyvät avoimuuteen. Omassa työssäni openBIM-asiantuntijana näen ratkaisun kolmiosaisena:
Avoin Validointi: Meidän on pystyttävä automaattisesti tarkistamaan datan laatu. Emme voi luottaa manuaaliseen silmäilyyn. Meidän on käytettävä koneluettavia vaatimuksia (kuten RAVA3pro:n säännöt tai kansainvälinen IDS-standardi ) ja avoimia validointityökaluja (kuten ifcopenshell ), jotka varmistavat, että data on sitä, mitä sen pitääkin olla, ennen kuin se siirtyy eteenpäin.
Datan Suora Muokkaus (Native Authoring): Kun virheitä löytyy, meidän on pystyttävä korjaamaan ne. Usein tämä tarkoittaa tuskallista ”pyykkipoika-liikennettä” takaisin suunnitteluohjelmistoon. Uudet, avoimet työkalut (kuten bonsaibim ) antavat meille mahdollisuuden muokata ja rikastaa IFC-dataa suoraan, ilman datan ”latistumista” ohjelmistosiirroissa.
Datan Saavutettavuus: Jotta data tavoittaisi kaikki (kuten totesimme), se ei voi olla kalliiden ohjelmistolisenssien takana. Tämä on suurin este datan hyödyntämiselle ylläpidossa ja työmaalla. Avoimet teknologiat (kuten ifc.js ), jotka tuovat täysimittaisen tietomallin selaimeen , ovat se tekninen vallankumous, joka vastaa blogisi ”ekosysteemi”-visioon. Ne mahdollistavat datan käytön kenelle tahansa, missä tahansa.
Vastatakseni siis loppukysymykseesi: ”Onko roolisi disruptoida vai olla disruptoitavana?”
Roolimme on olla realisteja. Meidän on tunnistettava ne raa’at, tekniset totuudet, jotka estävät meitä saavuttamasta visiotamme. Ja sen jälkeen roolimme on mahdollistaa disruptio rakentamalla ja käyttämällä avoimia työkaluja, jotka murtavat siilot, korjaavat ”datavelan” ja tekevät datasta vihdoin sen ”modernin öljyn”, josta kaikki puhuvat.
Kiitos vielä kerran keskustelun herättämisestä. ///arpi