For every complex question, there is a simple answer, which is wrong.
H.L. Mencken, W.E. Deming, Out of Crises, 1982, s. 388
Rakentamisen teollistaminen edellyttää liiketoimintamallien muutosta, jotta digitalisaation avulla saadaan toteutettua suunnittelutiedon, materiaalien ja työn virtaus. Virtaus ei ole tällä hetkellä mahdollinen kuin yksittäisissä projekteissa, koska tuotantosysteemeitä on aivan liikaa samassa rakennusliikkeessä ja ne ovat logiikaltaan erilaisia. Alalla tehty vakiointi on riittämätöntä, koska tiedon vakiointia on tehty pääosin koskemaan kaikkea rakennustuotantoa riippumatta projektitoimitusmuodosta. Rakentamisen kehittämisessä ei ole huomioitu eri tuotteiden, siis eri rakennustyyppien, ja niiden tuottamiseen tarvittavia tuotanto¬systeemejä liiketoimiyksiköissä. Alan fragmentoitunut toimintaympäristö estää liiketoimintamallien ja tuotantosysteemien kehittämistä, jonka seurauksena urakkamuotoja on kehitetty irtaallaan suunnittelun digitalisaatiosta ja tuotanto-systeemeistä. Valmistavan teollisuuden tutkimus on osoittanut, että tuotteen volyymi sekä tuote¬vaihtelu ovat keskeinen valintaperuste tuotantosysteemille ja sen logiikalle. Eri tuotantosysteemien digitalisaatio ja automatisaatio tapahtuvat valmistavassa teollisuudessa eri tavoin, eri standardein, eri ohjelmistoilla ja eri yritysten kehittämänä. Tarkoituksenmukainen tuotantosysteemi suunnittelusta rakentamiseen on myös saatava mallinnettua rakennustuoteteollisuuteen ja sen erilaisiin tuotantomuotoihin, jotta suunnittelutieto saadaan virtaamaan ja materiaalivirta saadaan hallittua digitaalisesti työn ja materiaalin kohtauttamiseksi teollisesti työmaalla. Rakentaminen teollistaminen edellyttää valmistusprosessin haltuunottoa, joka ei voi onnistua ilman systeemistä muutosta. Tämä muutos on tehtävä suunnitteluun, hankintaan, toimitusketjujen kytkentään sekä tuotantoon. Valmistusprosessin hallinta toteutetaan eri tavoin rakentamisen eri tuotantosysteemeissä, koska eri tuotantosysteemit toimivat eri logiikalla. Siksi myös digitalisaatio etenee eri tavoin rakentamisen eri tuotantosysteemeissä. Esitämme malliksi tuotantosysteemin toteutustavan sekä sen digitalisoinnin HVLM-rakentamisesessa, jota voi soveltaa toistuvaan rakentamiseen.
Rakennusalan pahin paradoksi [1]: As designed ≠ As build?
Olemme rakennusalalla luoneet käsitteet sille, että suunnittelemme rakentavamme jotain (as designed) ja rakennamme projektissa jotain aivan muuta (as build). Olemme luoneet alalle käsitteistön, as designed – as build, kuvaamaan sitä tosiasiaa, että suunniteltu ei toteudu (eikä sen tämän määritelmän mukaan ole tarkoituskaan toteutua). Kutsumme myöskin toteutussuunnitelmiksi sellaisia suunnitelmia, jolla ei voi rakentaa, eli toteuttaa suunniteltua. ”Toteutussuunnitelmista” otetuilla määrillä ei voi tehdä tilauksia, vaan näiden periaatteellisten geometriatietoja sisältävien suunnitelmien perusteella voi tuotteet ja materiaalit tunteva ammattilainen tehdä varsinaisen toteutussuunnittelun käyttäen oikeita reaalimaailman osia ja materiaaleja. Sama pätee esivalmistukseen, eli esimerkiksi keittiön, ikkunoiden tai ovien tarkoitus tietomallissa on toimia vain havainnekuvana, jonka perusteella toimittaja tekee varsinaisen esivalmistettavan tuotteen valmistussuunnitelman. Emme myöskään edellytä, että 3D-”toteutus”suunnitelmien tietoja voisi hyödyntää hankinnassa, logistiikassa tai itse rakentamisessa, koska emme aseta vaatimuksia suunnitelmien metatiedoille [2].
Tilanne on looginen lopputulos rakentamisessa käytetystä osittamisen logiikasta ja ositetun projektin kilpailuttamisesta halvimpien tarjouksien saamiseksi [3]. Tämän perustoimintatavan seurauksena suunnitteluvaiheen lopputulos on käytännössä hankinnan mahdollistavat suunnitelmat, eivät siis toteutussuunnitelmat. Suunnitelmataso mahdollistaa sen, että kyseisen rakennusosan tai vastaavan osa-alueen suunnitelmat sisältävät juuri sen verran tietoa, että alaurakoitsijat voivat tarjota kyseisen urakan mustana laatikkona, työ ja materiaali yhdessä. Toimintamalli on ohjannut suunnitteluohjelmistojen ja tietomallivaatimusten kehitystä suuntaan, joka on heikentänyt suunnitelmien tietosisältöjä ja käytettävyyttä hankinnassa, toimitusketjujen hallinnassa, tuotannon suunnittelussa ja itse rakentamisessa. Toisin sanoen tieto ei virtaa suunnitelmista järjestelmiin eli BIM:stä huolimatta digitalisointi ei ole toteutunut. Tietomallit eivät palvele rakentamisen prosessia tai rakennustuoteteollisuutta kuin hyvin rajallisesti. Käytännössä pääurakoitsijat ovat ulkoistaneet useimmissa urakkamuodoissa käytettävien tuotteiden ja materiaalien valinnan sekä toteutussuunnitelmien tekemisen alaurakoitsijoille. Valtaosassa tapauksista alaurakoitsijoilla ei ole käytettävissä omia ohjelmistoja 3D-suunnitteluun eli tietomallintamiseen tai suunnitelmien tarkentamiseen, jonka seurauksena toteutussuunnitelma perustuu yksittäisten rakennustyömiesten ja -naisten ammattitaitoon tulkita viitteellisiä suunnitelmia ja toteuttaa niiden avulla vastuullaan oleva rakennusosa urakoitsijan hankkimista osista ja materiaaleista. Tästä toimintamallista seuraa myös se, että ala ei opi toleranssien hallintaa, koska emme pysty laskemaan toleranssien hallitsemattomuudesta aiheutuvia kuluja. Laajemmissa ja haastavammissa hankkeissa pääurakoitsijan tärkein tehtävä on pyrkiä yhteensovittamaan alaurakoitsijoiden tekemät toteutussuunnitelmat ja kunkin haluama valmistusprosessi. Last Planner System on erinomainen tuotantosysteemi juuri tähän tarkoitukseen erityisesti rakennustyypeissä, joita tehdään harvoin samanlaisia [4].
Valmistavan teollisuuden tai rakentamisen teollistamisen näkökulmasta tämä tilanne estää alaa kehittymästä. Verrattuna muihin teollisuudenaloihin epänormaali teollinen tilanne on normalisoitunut. Edelleen minkä tahansa tasoinen suunnitteluprosessi ja sen tuotokset täyttävät as designed – as build –määritelmän, koska meillä ei ole metodia, jolla mittaisimme eri suunnitteluprosessin vaiheissa a) tietosisällön ja tarkkuustason suhteessa prosessin kyseisen vaiheen vaatimaan tasoon tai b) emme pysty mittaamaan suunnitteluprosessin lopputuloksen ”toteutussuunnitelmien” toteutettavuutta. Esimerkki ”toteutus-suunnitelmista” ja niiden käytön seurauksista alla kuvassa 1. Eri järjestelmien mallintaminen eri ohjelmistoja käyttäen tuottaa hyvin eritasoisen detaljitiedon tietomalliin. Tärkeintä on jokaiselle suunnittelijalle oman työn optimointi eli onnistunut ja vähätöinen mitoittaminen sekä tilan varaaminen omille järjestelmille eli geometriasuunnittelu. Mitä tarkempi vaatimus tilalle (esim. kaadot) ja mitä rajoitetumpi geometria (mitä jäykempi tai vaikeammin työstettävä materiaali), sitä tarkempi on suunnittelutieto. Koska sähkö kulkee ylämäkeen ja kaapeli pienessä tilassa, voi suunnittelija jättää rakentajan ratkaistavaksi, miten sähkökaapelit asennetaan. Rakentamisen päästä päähän prosessin fragmentaation yksi epätoivottu tulos on siis myös se, että tuotanto on käsityötuotantoa ja vaatii toteutussuunnitteluosaamista (craft production, craftmanship). Tämän seurauksena rakennuksessa syntyy väistämättä toteutusvaiheessa virheitä, koska yksittäisten ammattilaisten tekemiä toteutussuunnitelmia ja ratkaisuja ei pystytä yhteensovittamaan ja varmistamaan, että ratkaisut eivät törmää muiden tekemien toteutussuunnitelmien ja ratkaisujen kanssa. Osa törmäyksistä pintautuu vasta hyvin myöhäisessä vaiheessa, jolloin korjaaminen on vaikeaa, ja siksi rakentamisprosessiin on sisällytetty perinteisesti pitkä ”viimeistelyvaihe”.
Kuva 1: Sähköasentajia miettimässä toteutussuunnitelmaa ja tarvittavia osia sekä materiaaleja asunnossa alaurakoitsijan työkuvien eli ”toteutussuunnitelman” perusteella.
Ongelmamme on myös se, että emme tosiasiassa saa talteen toteumatietoa rakennustyömaalta siitä mikä as build-toteuma itse asiassa oli. Meillä ei ole suunnitteluvaiheessa rakennuksen osaluetteloa eikä varsinkaan rakennustyön loputtua tietoa siitä mitä osia ja materiaaleja on käytetty missä sijainnissa tai miten ne on tarkkaan ottaen asennettu. Tästä yhtenä osoituksena on se tosiasia, että tehtäessä uudehkonkin rakennuksen kuluvien osien uudistuksia tai käyttötarkoituksen muutoksia täytyy tehdä koepurku tai varautua merkittäviin lisäkustannuksiin rakennuksen ylläpidosta vastaavan tehdessä rakennukseen muutoksia (vaikka toteuttajalla olisi ”toteutus”suunnitelmat käytössään uunituoreena projektipankista ladattuna). Samalla vaatimukset hiilijalanjäljen laskemisesta toteuman perusteella sekä erityisesti vaatimukset pienentävät rakennusalan hiilijalanjälkeä (hiilikädenjälki) kasvavat. Manuaalinen tiedonkäsittely ei tule olemaan ratkaisu edes hiilijalanjäljen laskentaan, vaan se on pakko toteuttaa automatisaation avulla. Tämän seurauksena suunnittelutieto on saatava virtaamaan eli suunnittelua on muutettava siten, että tietomalleista on saatava tieto alustoille ja tietokantoihin rakenteellisessa muodossa, jotta sitä voidaan konekäsitellä eli rikastaa tietoa. Tiedon virtautusta ei ole mahdollista toteuttaa hankintaa, työsuunnittelua, logistiikkaa ja rakentamista palvelevaksi ellemme tiedä näiden organisaatioiden tietovaatimuksia ja sisällytä tätä tietoa ARK-, RAK-, ja TATE-tietomalleihin tarkoituksenmukaisessa muodossa ja varmista, että tieto saadaan mallista tarkoituksen mukaisessa muodossa ulos käytettäväksi yhteensopivasti eri järjestelmissä. [5]
Ratkaiseeko tahtituotanto alan tuottavuusongelman?
Rakentamisen tutkimuksella on merkittäviä ongelmia hahmottaa ja ymmärtää valmistavan teollisuuden eri tuotantomalleja sekä erityisesti virtausta. Valmistavan teollisuuden tärkeimpien toimintojen, eli tuotekehityksen ja valmistusprosessin, merkitystä ei ymmärretä, joten yritykset siirtävät valmistavasta teollisuudesta Lean-menetelmiä ovat jääneet systeemisesti puolitiehen. Vuodesta 2002 alkaen tutkimus ja edelläkävijäyritykset ovat yrittäneet korjata tilannetta kehittämällä ja kokeilemalla eri toimintalogiikkaan perustuvia tuotantojärjestelmiä. LPDS, LPS, LBMS tai VDC eivät ole muuttaneet alaa tuottavammaksi, vaikka jokaisella on tutkimuksen mukaan todistettavasti saatu merkittävä parannus yksittäisissä tutkituissa hankkeissa. Tilanne herättää vakavan epäilyksen, että valmistavan tuotannon konteksti, josta metodit on pyritty siirtämään rakennusalalle, on ymmärretty väärin tai valmistavan teollisuuteen tehdystä tutkimuksesta saatuun tietoon ei ole perehdytty. Toinen vaihtoehto on se, että metodit on ymmärretty ja/tai toteutettu väärällä tavoin. Kolmas vaihtoehto on, että kohdekonsepti eli rakentamisen eri tuotantologiikat on ymmärretty väärin ja kokoelmaa Lean-metodeja yritetään käyttää väärässä tuotantoympäristössä. Tällä hetkellä tahtituotannosta on olemassa ainakin kolme erilaista versiota: Takt Planning (Tommelain et al), TPTC (Dloughy and Binniger et al.) ja valmistusprosessin haltuunottoon perustuva yksiosaista virtausta tavoitteleva tahtituotanto (suomalainen tahtituotanto). Riskinä on, että tahtituotannolle käy samalla tavoin kuin edeltäville tuotantosysteemeille: yksittäisissä projekteissa ja niistä tehdyissä tutkimuksissa siitä saadaan >30 % tuottavuusparannuksia, mutta rakennusliikkeet tai niiden liiketoimintayksiköt eivät saa muutettua toimintatapaansa ja otettua laajasti käyttöön tuotantosysteemiä. Tämän seurauksen into laantuu ja toteutukset liudentuvat valevirtaukseksi ja palataan perinteiseen urakointiin aivan kuten LPS:n käyttöönotossa on käynyt. [6]
Viikon tahti tahtituotantologiikkana on parantanut rakentamisprosessin läpimenoaikaa, joka ei niinkään ole selitettävissä varsinaisella tahtituotannolla ja yksittäisvirtauksen käyttöönotolla , vaan pikemminkin tuotannon suunnittelun tarkentamisella viikon sakottomin välitavoittein. Eräkoon pienentäminen (eli pienemmät mestat) mahdollistavat sen, että perinteiseen toteutustapaan verrattuna rakennuksessa on viikon tahdissa enemmän alaurakoitsijoita töissä samanaikaisesti, joten edellisessä kappaleessa kuvattujen alaurakoitsijoiden teke¬mien toteutussuunnitelmien ja ratkaisujen aiheuttamat törmäykset tulevat esille aiemmin eikä virhettä en¬nätetä monistaa toistuvissa tiloissa. Tämän lisäksi vuorovaikutus työmaalla paranee ja johtaminen helpottuu, koska eri alaurakoitsijat ovat läsnä samanaikaisesti samalla työmaalla. Suunnittelutavan muutosta, hankinnan tiedonkäsittelyn automatisointia, yksiosaiseen virtaukseen siirtymistä tai valmistusprosessisin haltuunottoa viikon tahtituotanto ei aikaansaa. Se ei myöskään pura vallitsevan osittamisen logiikan rakentamia tarpeettomia siiloja eli valmistusprosessin kannalta ongelmallisia urakkarajoja, jotka ylläpitävät törmäyksiä. Vasta siirtyminen päivä- tai tuntitahtiin on tehnyt näkyväksi sekä suunnittelun että toteutussuunnitelmien puutteet ja hankinnan ongelmallisen tilanteen siirryttäessä mustalaatikko-ostamisesta työn ja materiaalin erottamisen avulla valmistusprosessin haltuun ottamiseen. Käytännössä yksiosaisen virtauksen käyttäminen pakottaa muuttamaan suunnittelun detaljitasoa kohti toteutussuunnitelmia, vakioimaan suunnitelmien tietosisältöjä, jotta suunnitelmista saadaan tieto rakenteellisessa muodossa hankintaan ja yhdistämään rajapintojen avulla hankinnan järjestelmiä toimittajien järjestelmiin. Oleellinen kysymys rakentamisen teollistamisessa on se, mihin rakentamisen lajeihin yksiosainen virtaus sopii ja miten teollistetaan ne rakentamisen lajit, joihin se ei sovi.
Urakkamuotojen vaikutus rakentamisen teollistamiseen
Rakentamisessa urakkamuodot ovat lähinnä liiketoiminnassa yritysten käyttämiä liiketoimintamalleja. Urakkamuodot heijastavat tilaajan rakennuttamistarpeita ja kyvykkyyksiä sekä sovittavat julkisen ja yksityisen sektorin toimijat yhteen markkinassa. Kuvassa 2 on eritelty miten rakentamisen päästä päähän prosessi jakautuu vastuina tilaajan ja urakoitsijan välille.
Kuva 2 (Ronkainen, 2015) Urakkamuotojen jaottelu vastuunjaon mukaan
Yksi osa teollistamisen ongelmaa ovat urakkamuotojen mukanaan tuomat sopimukset, maksuperusteet ja niihin liittyvä riskinjako, joka estää tehokkaasti alaa pääsemästä eteenpäin valmistusprosessin haltuunotossa. Käytännössä maksuperusteet aikaansaavat ansaintaparadigman toteutumisen, jolloin kenenkään ei kannata investoida tuotantosysteemiin, koska vallitsevassa mallissa investoinnin hyödyt menevät pääosin muille.
Kun tarkastellaan toteutusmuotoja suunnittelun näkökulmasta, kuvassa 3 alla, voidaan todeta, että urakkamuodot eivät ota huomioon rakennustyyppejä (eli rakennusliikkeen kyseisen rakennustyypin volyymia tai tuotevaihtelua peräkkäisissä hankkeissa), eikä mahdollista suunnittelutason parantamista. Rakennusalalla on tutkittu ansiokkaasti mitä riskejä eri toteutusmuodot aiheuttavat eri tilaajille, mutta ei niinkään sitä millaisia tuotantosysteemejä eri toteutusmuodot aikaansaavat tai mitä rakennustyyppejä on tarkoituksenmukaista toteuttaa eri tuotantosysteemeillä ja miksi. Urakkamuodoilla on taipumus peittää sen tosiasian, että toteutussuunnittelu jää alaurakoitsijoille ja hämärtävät toteutussuunnittelun merkityksen verrattuna valmistavaan teollisuuteen.
Kuva 3, Urakkamuotojen jako suunnittelu ja hankintavastuun avulla (Ronkainen, 2015)
Tuote-prosessi-matriisi
Rakennusala on pyrkinyt tutkimaan ja käyttämään tuote-prosessi-matriisia valmistavan teollisuuden tuotantosysteemien ymmärtämiseksi. Valitettavasti matriisi on tutkimuksessa rakennusalalla irrotettu kontekstista ja pyritty sovittamaan rakentamista tuoteprosessi -malliin ikään kuin olisi olemassa yleinen rakentamisen prosessi. Tämä on johtanut väärille jäljille rakentamisen teollistamisessa samoin kuin Shingon tuotannon prosessi-operaatio-mallin käyttö. Tuote-prosessi-matriisin avulla on pyritty mallintamaan mihin rakentaminen kokonaisuutena luontevasti asettuisi virtauksen perusteella [8]. Virtausta on tutkittu laajemmin ja pyritty tunnistamaan erilaisia virtauksia, kuten työntekijöiden, alaurakoitsijoiden, materiaalin, tiedon, asennuksen, asennuspaikkojen, operaatioiden, arvon, prosessin ja työn virtaukset. Valitettavasti tämä tutkimus [9] on vienyt huomion pois olennaisimmasta asiasta, eli valmistusprosessista. Samalla tutkimuksen aiheuttama sumuverho estää käyttämästä tehdasfysiikkaa rakentamisessa. Leanin osalta tutkimus ei ole pystynyt rakennusalalla hahmottamaan TPS:n ja Toyotan tahtituotannon logiikkaa, vaan on liudentanut yksiosaisen virtauksen ja tahtituotannon kokonaisuudessaan kytkemällä LPS:n osaksi tahtituotantoa. Tämän seurauksena on alalle syntynyt esimerkiksi käsitys siitä, että viikon tahti olisi jollain tavalla tahtituotantoa, vaikka se itseasiassa on valevirtausta [10].
Tuote-prosessi-matriisissa ei ole niinkään kysymys siitä, että vertailtaisiin eri tehtaan lay-out:n tai prosessiin liittyviä paremmuuksia saati, että tuotantoa koetettaisiin viedä kohti jatkuvaa virtausta väen väkisin. Tuote-prosessimatriisi (kuva 4 alla) osoittaa, että valmistavassa teollisuudessa on erilaisia tuotantotapoja, tuotantosysteemejä, jotka sopivat erityyppiseen tuotantoon ja erityyppiseen markkinaan riippuen siitä millainen tuotevolyymi on ja millainen tuotevaihtelu (tuote-mix) on. Vähäinen vaihtelu tuotettavien tuotteiden välillä (Low-Mix, LM) ja korkea volyymi (High Volume, HM) mahdollistavat jatkuvan virtauksen käytön, linjaston käytön sekä yksiosaisen virtauksen hyödyntämisen. Tällöin tuotantojärjestelmä voidaan virittää äärimmäisen tehokkaaksi, mutta samalla menetetään tuotantojärjestelmän joustavuus. Tuotettaessa pieniä eriä (Low Volume, LV) tuotteita, joilla on suuri tuotevaihtelu (High Mix, HM), on tarkoituksen mukaista järjestää tuotantosysteemi operaatioittain kuten Job Shop:ssa tehdään. Tällöin yksittäisen tuotteen virtaus ei ole kovinkaan tehokasta, mutta tuotanto on kuitenkin tehokasta pienestä eräkoosta huolimatta, mikäli materiaalivirrat saadaan hallittua. Tuote-prosessimatriisin tärkein asia rakennusalan teollistamisessa on ymmärtää mitä tuotetta ollaan tekemässä ja millaisia sopimusmalleja siihen käytetään.
Kuva 4: Schmennerin esittämä tuote-prosessi-matriisi
Toyota ja erityisesti Toyotan tuotantosysteemi TPS on esimerkki erittäin pitkälle kehitetystä LMHV-tuotantojärjestelmästä. LPS:n ja Lean-menetelmien kopiointi HMLV-tuotantoon ei tuota hyviä tuloksia, koska tuotantosysteemin logiikka on väärä. Alla olevassa taulukossa (taulukko 1.) on esimerkinomaisesti lueteltu Toyotan LMHV-tuotantosysteemin osia ja arvioitu niiden soveltuvuutta Job Shop-tuotantosysteemiin.
Taulukko 1: Lean-työkalujen käytettävyys Job Shop-tuotantosysteemissä
Tuotteen volyymin ja tuotevaihtelun merkitys on oleellinen arvoitaessa rakentamisen teollistamista. Samat keinot eivät selvästikään päde koko rakennusliikkeen tuotantoon tai edes rakennusliikkeen yhden liiketoimintayksikön toiminnan teollistamiseen, mikäli yksikössä tuotetaan erilaisia tuotteita eri variaatioin. Samalla on syytä huomata, että valmistava teollisuus on edennyt tutkimuksessa jo huomattavasti pidemmälle eri tuotantosysteemien osalta (kuva 5 alla), joista rakennusala voi hyötyä ymmärtämällä tuotantosysteemit sekä niiden kontekstin oikein.
Kuva 5: Valmistavan teollisuuden tuotantosysteemien spektri
Rakentamisen teollistaminen tapahtuu käytettyjen projektitoimitusmallien ehdoilla, koska projektitoimitus-muoto määrittää sen kenellä on mahdollisuus ja valta muuttaa tuotantosysteemiä nykyisestä teolliseksi. Rakennuttaja pystyy aikaansaamaan teollistamista toistuvissa hankkeissa samalla tavoin kuin rakennusliikekin, mutta oleelliseksi kysymykseksi muodostuu se, kenelle aineeton pääoma on mahdollista kerryttää. Eri projektitoimitusmuodot yhdistettynä erityyppiseen volyymiin ja tuotevaihteluun aikaansaa erilaisen tuotantosysteemin ja erityyppisen aineettoman pääoman kerryttämisen mahdollisuuden eri osapuolille.
Rakentamisen kytkeytyminen rakennustuoteteollisuuteen
Rakennustuoteteollisuus on rakentamista huomattavasti pidemmällä tuotannon suunnittelussa (tehtaiden karkea/hienokuormitus), tiedon virtauttamisessa eli prosessiensa digitalisaatiossa ja itse valmistusprosessien käytössä. Rakennustuoteteollisuudessa on käytössä pääosin neljä eri liiketoimintamallia ja tuotantotapaa. Näistä rakennusalalla käytetään termejä vakiotuotteet ja projektituotteet.
Valmistavan teollisuuden näkökulmasta vakiotuotteiksi kutsumamme osat ja materiaalit ovat varasto-ohjautuvaa tuotantoa. Toisin sanoen ne ovat materiaaleja ja tuotteita, joita käytämme laajalti eri hankkeissa. Tuotteet ovat olemassa projektien yli ja niistä riippumatta. Varasto-ohjautuva tuotanto eli MTS (Make to Stock) on suunnittelun ja tuotetiedonhallinnan näkökulmasta yksinkertaisin digitalisoinnin kohde. MTS-tuotantoa ovat esimerkiksi laminaatit, talotekniikan osat ja materiaalit tai väliseinärangat ja kipsilevy. Projektituotteet jakaantuvat tilauspisteohjauksen perusteella tilauksesta suunnitteluun (ETO eli Engineer to Order), tilauksesta valmistukseen (MTO eli Make to Order) ja tilauksesta kokoonpanoon (ATO eli Assemble to Order). ETO tuotteita ovat esimerkiksi betonielementit. Vastaavasti keittiöt ovat yleensä MTO-tuotannolla toteutettuja ja sähkökeskukset ATO-tuotannolla toteutettuja.
Rakentamisen teollistamisen näkökulmasta nämä kaikki neljä ovat tärkeitä erottaa toisistaan, koska jokainen rakennustyömaa tarvitsee kaikkia näitä tuotantotapoja (pl. osa saneerauskohteista). Jokainen toimitusketjuista kuuluu johonkin näistä tuotantotavoista ja jokaisella neljällä on erilainen digitalisointitapa, koska välitettävä tieto ja transaktiot ovat kussakin erilaiset. Tämä tarkoittaa käytännössä sitä, että suunnitteluprosessia on muutettava siten, että rakennusliike yhdessä suunnittelutoimistojen kanssa vakioi tietomallien tietosisältöjä siten, että hankinta saa järjestelmiinsä materiaalin tilausta ja toimitusketjun ohjausta varten kullekin toimitusketjutyypille tarvittavat tiedot rakenteellisessa muodossa. Työ ja materiaali eivät siis voi virrata ennen kuin suunnittelutieto saadaan virtaamaan tietomalleista ja suunnitelmista tietokantoihin tai data-alustoihin pääurakoitsijalla. Tämä edellyttää myös suunnittelusiilojen eli hankekehityksen, kustannusmallinnuksen ja ARK-, RAK-, ja TATE-”toteutussuunnitelma”-järjestelmien tietosisältöjen vakiointia ja koneluentaa. Rakentamisen suunnittelu- ja toteutusprosessi täytyy kytkeä hankinnasta toimittajien järjestelmiin kuvassa 6 esitetyllä tavalla, ja toteuttaa rajapinta MTS-, ETO-, ATO- ja MTO-tuotantologiikalla toimiviin rakennustuoteteollisuuden järjestelmiin. Valtaosa rakennustuoteteollisuudesta käyttää jo kuljetuksissa koneohjausta tai on kykenevä ottamaan se käyttöön heti kun rakennusliikkeet pystyvät ottamaan sähköisen vastaanoton käyttöön työmailla.
Kuva 6: Rakentamisen suunnittelu ja tuotantoprosessi täytyy kytkeä digitaalisesti rakennustuoteteollisuuden toimitusketjuihin, joiden päätyypit ovat ETO-, ATO-, MTO- ja MTS-tuotantomuodot
Teolliseen rakentamiseen siirtyminen
Rakentamisen teollistamista ei voi toteuttaa samalla tavoin kaikissa rakennusliikkeen liiketoimintayksiköissä. Valmistavan teollisuuden kehittämät tuotantosysteemit ja niiden eri logiikat antavat selkeän mallin rakennusliikkeiden liiketoimintamallien kehittämiseen. Eri tuotteita tekevät liiketoimintayksiköt toimivat erilaisissa markkinoissa ja niiden tuotteet eroavat sekä tuotteiden volyymin että peräkkäisten valmistettavien tuotteiden, eli rakennusten, samankaltaisuuden osalta. Toisin sanoen osa rakennusliikkeiden liiketoimintayksiköistä tarvitsee erittäin ketterän tuotantosysteemin, jotta voi rakentaa peräkkäin aivan erilaisia rakennuksia vaihtelevalla joukolla alaurakoitsijoita. Osa liiketoimintayksiköistä tekee samanlaisia rakennuksia suurella volyymillä ja perättäisissä rakennuksissa on vähän eroja toisiinsa nähden. Osa liiketoimintayksiköistä tekee rakennuksia, joissa jo itsessään on paljon toistoa. Toistojen määrä rakennuksessa ja perättäisten toistettavien rakennusten määrä on kriittinen valintakriteeri tuotantosysteemille sekä suunnittelutavan muutokselle, koska nämä yhdessä mahdollistavat tuotekehityksen, investoinnin digitalisaatioon sekä valmistusprosessin haltuunoton. Käytännössä tämä tarkoittaa sitä, että suunnitelmien LoD-taso on tarkoituksenmukaista nostaa tasolle, joka mahdollistaa suunnittelutiedon virtautuksen suoraan hankintajärjestelmiin ja näiden kytkemisen toimittajien järjestelmiin. Rakentamisen teollistamisen yksi tärkeimmistä askelista on pääurakoitsijoiden ja suunnittelijoiden tuottaman tiedon rakenteellistaminen, jotta rakentaminen voidaan yhdistää digitaalisesti käyttämään rakennustuoteteollisuuden järjestelmiä.
Suunnittelu- ja tuotetiedon vakioinnista vastaavat tällä hetkellä Suomessa Rava3PRO-projekti, Rakennustietomalli Oy (RYTV-hankeohjelma) sekä Rakennusteollisuus RT (Toimitusketjujen tuotetiedon digitalisointihanke). Rava3PRO on vakioinut suunnittelunimikkeet talotekniikan MTS-tuotteiden osalta ja julkaissut nimikkeistön koodistot.suomi.fi -sivustoilla [11]. RT:n johdolla toimivan TATE-toimitusketjutyöryhmän tavoitteena on hyödyntää vakioituja suunnittelunimikkeistöjä, jotta työryhmä saa julkistettua kansallisen toteutusmallin TATE-toimitusketjun digitalisoinnille sekä referenssiarkkitehtuurin. Vastaava työ on käynnissä RT:n johdolla betonielementtitoimitusketjun digitalisoimiseksi hyödyntäen BEC-ryhmän vakioimia elementtityyppikohtaisia tietoja. Tiedon virtautuksen periaate on esitetty alla olevassa kuvassa 7. MTS-tuotteiden osalta vakioiduilla suunnittelunimikkeillä sekä tietomallista saatavilla attribuuttitiedoilla saadaan hankinnan ja toimitusketjujen koneohjaukseen tarvittavat lähtötiedot rakenteellisessa muodossa tietokantaan. Tämä mahdollistaa ohjelmistorobotiikan, algoritmien ja sääntöpohjaisen tiedonkäsittelyn eli automatisaation lähtötietojen rikastamiseksi tilaukseksi ja myöhemmin kotiinkutsuiksi mahdollistaen toimitusten sähköisen vastaanoton työmaalla, varastopaikoille varastoinnin sekä saldojen koneluennan.
Kuva 7: vakioitujen suunnittelunimikkeiden avulla mahdollistetaan suunnittelutiedon rikastaminen tilaustiedoiksi.
Suunnittelu- ja ostonimikkeiden kytkeminen toisiinsa konekäsittelyä hyödyntäen mahdollistaa osaluettelon muodostamisen sekä hiilijalanjäljen koneellisen laskennan. MTS-tuotteiden osalta kansallinen referenssiarkkitehtuuri on kuvattu alla olevassa kuvassa R. Valmistavan teollisuuden näkökulmasta MTS-osille ja materiaaleille toteutetaan automatisaatiota käyttäen vakioitujen suunnittelunimikkeiden rikastaminen osaluetteloksi eli muodostetaan E-BOM (Engineering Bill of Materials). Edelleen konekäsittelyn avulla hankintajärjestelmät pystyvät muuttamaan vakioidut suunnittelunimikkeet (sijainneittain työtehtäviin sidottavat määrät osista ja materiaaleista) ostonimikkeiksi eli M-BOM:ksi (Manufacturing BOM) ja automatisoimaan tilaus-toimitus tiedonkäsittelyn aikaan saaden tahtilogistiikan. Pääurakoitsijan hankita pystyy hakemaan järjestelmiinsä tuotetiedot kansallisista tuotetietorekistereistä, joiden tiedonsiirtorajapinta on jo standardoitu rakennusliikkeitä varten (TT-standardi [12]). Vastaavat rajapinnat on toteutettu myös sähköosien kansalliseen tuo¬tetietorekisteriin www.sähkönumerot.fi ja rakennustuotteista https://www.rakennustieto.fi/palvelut/tuotetieto.
Kansallinen työnjako on toiminut MTS-osien osalta siten, että Rava3PRO on tuottanut vakioidut suunnittelunimikkeet sekä koneluettavat tilatyypit. Tilatyypeistä täytyy muodostaa kansallinen malli tilojen yksilöimiseksi, josta RT:n Digiryhmä on tehnyt hankealoitteet RYTV-ohjelmaan Rakennustietomalli Oy:lle. Nämä yhdessä muodostavat konekäsittelyn vaatimukset täyttävät lähtötiedot, jota rikastetaan tuotetiedoilla aikaansaaden arkkitehtuurin, joka on esitetty kuvassa 8. Tiedonsiirto urakoitsijoiden järjestelmistä toimittajien järjestelmiin tullaan toteuttamaan käyttäen Peppol-standardia, jonka Valtionkonttori on ottamassa käyttöön viranomaisena myös rakennusalalle julkisiin hankintoihin. Logistiikka- ja aikatauluohjelmistoihin tarvitaan myös kansallinen rajapinta.
Kuva 8: Suunnittelutiedon vakiointi (vakioitujen suunnittelunimikkeiden käyttöönotto tietomallinnuksessa) mahdollistaa muutoksen hankintajärjestelmien ja toimittajajärjestelmien yhteentoimivuudessa: käytännössä se on konekäsittelyn edellytys rakennusliikkeiden ja toimittajien järjestelmien välisen tiedonsiirron automatisoimiseksi.
Betonielementtitoimitusketju on julkistamassa vakioituja tietosisältöjä koskevat metatietomääritelmät sekä rajapintakuvaukset H2/2024 aikana. Tämän ansiosta kaksi vaikeinta toimitusketjua saadaan vakioitua digitalisointia varten 2024 aikana. RT käynnistää MTO- ja ATO-toimitusketjuihin omat työryhmänsä, jotta suunnittelutieto saadaan virtaamaan kattavasti rakentamisen ja rakennustuoteteollisuuden yhdistämiseksi digitaalisesti toisiinsa.
Yksiosaisen virtauksen käyttö tuotantosysteeminä edellyttää LMHV-tuotantoa, jota liiketoimintayksiköt tekevät esimerkiksi linjasaneerauksissa ja asuntotuotannossa. Tällöinkin yksittäisten kohteiden tuotanto on syytä jakaa prosessiosaan ja projektiosaan. Koska sisätehtaat käyttävät pääosin MTS-tuotteita ja näille on olemassa jo tiedonvirtautuksen malli, voivat rakennusliikkeet ryhtyä digitalisoimaan suunnittelua ja työmaatoteutusta.
Miten toteuttaa rakentamisen teollistaminen?
Rakentamisen teollistamiseksi on tärkeää hahmottaa, että meillä ei ole yhtä ongelmaa tai yhtä tuotantosysteemiä, jota olemme korjaamassa. Teollinen rakentaminen ja rakentamisen teollistaminen ovat kaksi eri asiaa. Lähtökohtaisesti toteutamme hyvin erityyppisiä rakennuksia, joilla toistuvuus vaihtelee suuresti, jonka seurauksena tarvitsemme sekä hyvin ketteriä suunnittelu-, toimitusketju- ja rakentamisprosessin yhdistäviä tuotantosysteemejä, että tiettyyn rakennustyyppiin erikoistuvia tuotantosysteemejä. Ensimmäisten tehtävänä on kerätä osaaminen ja aineeton pääoma markkinoilta tehokkaasti haastavien, harvoin tehtävien ja jopa uniikkien kohteiden suunnittelemiseksi ja toteuttamiseksi kustannustehokkaasti. Jälkimmäisiä tarvitaan, jotta aineetonta pääomaa pystytään kumuloimaan bulkkituotannon, kuten asuntojen ja toimistorakennusten, toteuttamiseksi siten, että sekä tuote että valmistusprosessi kehittyisivät samalla kun loppuasiakasarvo kasvaisi.
Allianssi on osoittautunut erittäin toimivaksi malliksi erittäin yksilöllisten hankkeiden rakentamisessa, koska siinä kehitetään sekä tuote että sen valmistusprosessi kokoamalla markkinasta tarvittavat kyvyt. Osapuolten ja yhteiskunnan näkökulmasta malli on ongelmallinen, koska se ei juurikaan kerrytä aineetonta pääomaa, vaan osaaminen jää yksittäisten työntekijöiden hiljaiseksi tiedoksi eikä hyödytä juurikaan alaa (pl. allianssimallin kehittyminen). Allianssimalli on kuitenkin tärkeä uniikkien kohteiden takia, koska niitä tehdään markkinassa niin vähän, että matala volyymi käytännössä estää ketään toimijaa ylläpitämästä koko kyseisen rakennustyypin ja sen sovelluksen vaatimaa osaamista itsellään. Vastaavasti LPS on erinomainen malli yhteensovittaa alaurakoitsijoille ulkoistetut rakennusosat, tuotevalinnat ja valmisprosessi viimeisellä mahdollisella hetkellä eli rakentamisvaiheessa. LPS:llä on tästä syystä tärkeä rooli nykyisen rakentamisen valtavirta-arvonluontimallin, eli osittamisen ja halvimman osan kilpailuttamisen, käytössä. Myös sen ongelmana on tuotekehityksen puute ja valmistusprosessin jääminen hiljaiseksi tiedoksi. LPS:n toteuttaminen siten, että syntyvä hiljainen tieto rakennusvaiheesta saataisiin kodifioitua yrityksen aineettomaksi pääomaksi eli esimerkiksi rakenneratkaisukirjastoksi, suunnittelu- ja rakentamisprosessin koulutettavaksi kuvaukseksi tai yksinkertaisesti yrityksen hallitsemaksi valmistusprosessiksi, on vaikeaa. LPS on kuitenkin erinomainen tuotantosysteemi, mikäli suunnitteluvaihetta ei ole mahdollista muuttaa eikä hankintatapaan haluta vaikuttaa, mutta sen toteuttaminen käytännössä ei ole pääurakoitsijoilta onnistunut systeemisesti. Tahtituotanto sopii osaan rakentamista pyrittäessä yksiosaiseen virtaukseen ja valmistusprosessin haltuun ottamiseen. Tämä edellyttää käytännössä pääurakoitsijalta omaa tuotetta eli suunnittelun yhdistämistä toimittajakumppanuuksiin tuotteen vakioimiseksi. Tuotevakiointi mahdollistaa työn standardoinnin sekä työn ja materiaalin erottamisen toisistaan. Tuotantosysteemi on tällöin hyvin samankaltainen TPS:n kanssa, toisin sanoen sitä on mahdollista kehittää aineettoman pääoman rikastamiseksi, tiedostaen samalla sen, että se erikoistuu vain tietyn tyyppisen tuotteen valmistamiseen. Eri tuotantosysteemit on esitetty alla kuvassa 9 tuote-prosessi-matriisiin sovellettuna.
Kuva 9. Tuote-prosessi-matriisi sovellettuna rakennusalalle
Tuote-prosessi matriisi esitetyssä muodossa ohjaa jo rakennusliikkeitä tarkastelemaan omia liiketoimintayksiköitään niiden valmistamien tuotteiden volyymin ja tuotemix:n osalta. On helposti osoitettavissa, että ne liiketoimintayksiköt, jotka tekevät vain yhtä tuotetta, voivat hyötyä tahtituotannosta ja ottaa sekä tuotteen että sen valmistusprosessin haltuunsa. Vastaavasti sekarakentamista tekevät liiketoimintayksiköt joutuvat päättämään tuotantosysteeminsä toteutuslogiikan eri lähtökohdista ja tekemään strategisen valinnan missä markkinasegmentissä, millaisella tuotteella (jos ollenkaan) sekä millaisella tuotantosysteemillä he aikovat kilpailla. Kysymys on rakennusalalle uusi, sillä se avaa vaihtoehtoiset liiketoimintamallit ja markkinamuutoksen perinteisen osittamiseen perustuvan rakennustavan rinnalle.
[1] Paradoksi = näennäisesti loogiselta tuntuva ajatus tai väite, joka kuitenkin johtaa epäloogiseen, tai mahdottomaan lopputulokseen
[2] Käytännössä esimerkiksi YTV ulkoistaa tietosisältövaatimukset määritettäväksi kussakin projektissa erikseen, ks. esim. https://drive.buildingsmart.fi/s/S2p59nX27yZ2LzM , kohta 4.2 ”Mallinnuksen tarkoitus on esittää geometrian avulla pääreittien sijainti – tietosisällölle ei aseteta vaatimuksia.”
[3] ml. eri suunnitelmien kilpailuttamisen halvimmalla hinnalla käyttäen vaatimuksina YTV2012:ta.
[4] Samalla tavoin on loogista, että markkinaan on kehitetty Allianssimalli, joka paikkaa nykyisen fragmentoituneen liiketoimintaverkoston toimintaa. Allianssimallissa kehitetään tuote ja sen suunnittelemiseksi ja rakentamiseksi suunnittelu- ja tuotantosysteemi, jotka ovat pitkälle digitalisoituja. Allianssihankkeissa on mahdollista investoida sekä suunnittelujärjestelmiin että erityisesti tietosisältöjen vakiointiin ja metatietojen määrittelyyn siten, että hankinta, logistiikka ja rakentaminen saavat mallista eri käyttötapauksissa tarvitsemansa tiedon tarvitsemassaan muodossa käytettäväksi omissa järjestelmissään.
[5] Tarkasteltaessa pääurakoitsijan toteuttamaa suunnittelua kokonaisuutena, pystymme erottamaan kolme päätoimintoa (pääurakoitsijasta ja liiketoimintayksiköstä riippuen nimet vaihtelevat): 1) hankekehitys, 2) kustannusmallinnus ja 3) toteutussuunnittelu. Kaikissa käytetään eri ohjelmistoja ja tiedostomuotoja suunnitelmien edistämiseen, jonka seurauksena tieto ei virtaa edes suunnitteluvaiheessa saman organisaation sisällä tai suunnittelukumppaneiden ja pääurakoitsijan välillä, joten tietosisältövaatimusten määrittely auttaa heti myös suunnitteluvaihetta itseään ja aikaansaa tiedon virtauksen suunnittelujärjestelmien välillä korvaten tiedon välittämisen tiedostoilla ja manuaalisen tiedonsiirron järjestelmistä toiseen.
[6] Seuraava hype LPDS:n, LPS:n, LBMS:n, VDC:n ja tahtituotannon jälkeen on jo horisontissa: tekoälyohjattu rakentaminen.
[7] Viikon tahti ei ole tahtituotantoa siten, miten valmistava teollisuus määrittelee yksiosaisen virtauksen: ks. Toyota Kata, s. 71-82, Operation Management s. 620-621, The Toyota Way 2ed.
[8] esim. Rafael Sacks 2016: https://www.tandfonline.com/doi/full/10.1080/01446193.2016.1200733
[9] esim. https://www.iglc.net/Papers/Details/2015
[10] Fake flow: The Toyota Way, 2ed. sivut 73-75.