TUTKIMUSRAPORTTI VTT-R-04729-10 InfraTimantti esiselvitys Loppuraportti Kirjoittajat: Luottamuksellisuus: Juha Hyvärinen, Tarja Mäkeläinen, Mirkka Rekola, Jouko Törnqvist Luottamuksellinen
2 (63) Raportin nimi InfraTimantti esiselvitys, loppuraportti Asiakkaan nimi, yhteyshenkilö ja yhteystiedot Rakennustietosäätiö RTS Christer Finne, TkT, T&K-johtaja Runeberginkatu 5, P.O.B 1004, FIN-00101 Helsinki, Finland Projektin nimi InfraTimantti esiselvitys Rakennetun ympäristön elinkaarenaikaisten tietomallipohjaisten prosessien ja liiketoimintamallien kehittäminen Raportin laatija(t) Juha Hyvärinen, Tarja Mäkeläinen, Mirkka Rekola, Jouko Törnqvist Avainsanat Asiakkaan viite Tarjous VTT-V4105109 4.10.2009 Tilaus 09.12.2009 Tilausvahvistus 10.12.2009 Projektin numero/lyhytnimi 41051/Infra Timantti ESI Sivujen/liitesivujen lukumäärä 63/10 Raportin numero Infra-rakentaminen, tietomallinnus, toimintaprosessit VTT-R-04729-10 Tiivistelmä Valmisteltavana olevan InfraTimantti tutkimushankkeen aihepiirinä on rakennetun ympäristön elinkaaren aikaisten (omistaminen ja kehittäminen, käyttö ja ylläpito, sekä rakentaminen) tietomallipohjaisten prosessien ja infra-alan liiketoimintamallien kehittäminen. Tässä esiselvityksessä on priorisoitu tutkimushankkeen pääasialliset painopisteet erityisesti tilaajan kannalta (omistajuus sekä yhteiskunnan ja käyttäjän tarpeet). Luottamuksellisuus Luottamuksellinen Espoo 15.6.2010 Laatija Tarkastaja Hyväksyjä Juha Hyvärinen, Erikoistutkija VTT:n yhteystiedot VTT kirjaamo PL 1000 02044 VTT kirjaamo@vtt.fi Käyntiosoite: Vuorimiehentie 5, Espoo Puh. 020 722 4158 Faksi 020 722 7001 Jakelu (asiakkaat ja VTT) Tilaaja, VTT Markku Virtanen, Teknologiapäällikkö Pentti Vähä, Tutkimusprofessori, Tiimipäällikkö VTT:n nimen käyttäminen mainonnassa tai tämän raportin osittainen julkaiseminen on sallittu vain VTT:ltä saadun kirjallisen luvan perusteella.
3 (63) Alkusanat Tämä esiselvitys on tehty InfraTM-ryhmän (Liikennevirasto; Helsingin, Espoon, Tampereen, Vantaan, Turun, Oulun ja Lahden kaupungit; InfraRY) tilauksesta ja tiiviissä yhteistyössä sen kanssa. Työn tarkoituksena on ollut valmisteltavana olevan InfraTimantti-hankkeen suuntaaminen infran-tilaajien kannalta tärkeimpiin kysymyksiin tutkimuksen teema-alueella (rakennetun ympäristön elinkaaren aikaisten tietomallipohjaisten prosessien ja toimintamallien kehittäminen). Työ on tehty vuoden 2010 alkupuolella ja sen toteuttajina VTT:ssä ovat olleet Juha Hyvärinen, Tarja Mäkeläinen, Mirkka Rekola, Antti Ruuska ja Jouko Törnqvist sekä asiantuntijoina Pertti Lahdenperä (hankintamallit) ja Ville Valovirta (innovaatiojohtaminen); esiselvitykseen on myös osallistunut lukuisa joukko Suomalaisia infra-alan asiantuntijoita kyselyiden, haastattelujen ja työpajatyöskentelyjen kautta tekijät kiittävät kaikkia tämän esiselvityksen tekemiseen myötävaikuttaneita henkilöitä. Erityisesti haluamme kiittää yhteistyöstä InfraTM-ryhmän puolesta toimeksiantoa valvonutta ja ohjannutta ryhmää: Harri Mäkelä, Karl-Johan Serén ja Christer Finne. Espoo 15.6.2010 Tekijät
4 (63) Sisällysluettelo Alkusanat...3 1 Johdanto...6 2 Infran tilaajien hankinta- ja toimintamallit...7 2.1 Prosessi...7 2.1.1 Koetut ongelmat ja tietotarpeet...8 2.2 Käytettävät ja kehitettävät toteutusmuodot...10 3 Infra-alan tiedonhallinnan kartoitus...12 3.1 Tilaajien järjestelmät...12 3.2 Tilaajien tiedonhallinnan ongelmat ja tarpeet tietojärjestelmille...14 3.2.1 Osaaminen...14 3.2.2 Prosessit ja tiedonsiirto...14 3.2.3 Rekisterit...15 3.2.4 Visualisointi...15 3.2.5 Resurssien ja strategian puute...16 3.3 Tiedonhallinta tuottajien näkökulmasta...16 3.3.1 Suunnittelu...17 3.3.2 Rakentaminen...17 3.3.3 Projektin tiedonhallinta...17 3.4 Tiedonhallinnan kartoituksen johtopäätökset...18 3.4.1 Merkittävimmät kehitystä estävät tekijät...20 4 Best Practise esimerkkejä...22 4.1 Tilaajan hankintaprosessin ohjaus...22 4.2 Tuotannon prosessien hyvät esimerkit...23 4.3 Tietomallipohjaiset prosessit ja liiketoiminta talonrakennuksessa...25 4.3.1 Päätöksentekoprosessin analysointi...25 4.3.2 Information Delivery Manual...27 4.3.3 Tietomalliin perustuvat palvelut - case Finnmap Consulting...29 4.4 Älykäs tieto - älykäs tiedonhallinta...29 4.5 Kansainvälinen kehitys ja yhteistyö...31 4.5.1 Kansainvälinen standardointi...31 4.5.2 Talonrakennusalan tilaajayhteistyö...33 4.6 Elinkaarenhallinnan työkalut...33 5 Strategiat...36 5.1 Muutosvoimat...36 5.2 Perusteesit...37 5.3 Keskeisten toimijoiden strategiat ja toimenpiteet...38 5.3.1 Käyttöönotto ja juurruttaminen...40 5.4 Näkökulmia kehittämiseen...42 5.4.1 Strategisia /yleisiä koko toimialan toimenpiteitä...43
5 (63) 6 Johtopäätökset...48 7 Lähdeviitteet...51 8 Liite 1...54 9 Liite 2...55 10 Liite 3...56 11 Liite 4...57 12 Liite 5...58 13 Liite 6...59 14 Liite 7...60 15 Liite 8...61 16 Liite 9...62 17 Liite 10...63 18 Liite 11...64
6 (63) 1 Johdanto Siirtyminen tietomallintamiseen olisi nähtävä infra-alan systeemisenä innovaationa ([15]) pikemminkin kuin yksittäisen toimijan uutena työvälineenä, vaikka sillä jo siinäkin roolissa on arvoa ja sellaisena saattaa olla kehityspolun välttämätön alkuetappi. Uuden teknologian todellinen hyödyntäminen kuitenkin on tehokkainta toimijaverkostoissa joissa kaikki ovat omaksuneet paitsi uudet työkalut myös toimintatavat ja -prosessit niin omissa organisaatioissaan kuin myös niiden välisessä yhteistoiminnassa ( liiketoimintaekosysteemissä ). Pelkästään nykyprosessien automatisointi ei riitä; vanhat tulee hylätä, sillä ne prosessit ovat ratkaisseet eri ongelmia toisin sanoen: "Ongelmia ei voi ratkaista samalla ajattelulla, joka ne aiheutti". A.Einstein. Tässä InfraTimantti tutkimuksen esiselvityksessä on lähdetty edellä mainitusta väittämästä, jonka mukaan tietomallinnuksen kehittämistä ja käytäntöön viemistä ei pidä ottaa pelkästään teknisenä haasteena (vaikka se sellaisenakin on varsin merkittävä) vaan katsoa sitä laajemmin, myös toimintaprosessien (ja niissä toimivien ihmisten) uudistumisen sekä liiketoiminnan tarpeiden ja mahdollisuuksien kautta. Tästä syystä on ensin selvitetty infran tilaajien näkökulmasta hankintamallien nykyisiä käytäntöjä ja tulevaisuuden odotuksia, ja vasta sen jälkeen peilattu tietojärjestelmien nykytilaa ja niille tulevia haasteita. Samaan aikaan on kartoitettu esimerkkejä tietomallintamisen ja tiedonhallinnan parhaista käytännöistä sekä infra- että talonrakennusalalla. Näin kerätyn tiedon ja selvityksen loppuvaiheessa pidetyissä työpajoissa saadun näkemyksen pohjalta on tuotettu tämän selvityksen strategiset linjausehdotukset ja johtopäätökset. Tämän esiselvityksen aikana kuultiin eri yhteyksissä yhteensä 67 Suomalaisen infra-alan asiantuntijaa (Liite 11). Nämä edustivat tilaajia (kuntatilaajat 39, valtionhallinto 14) ja tuottajia (urakoitsijat 7, konsultit 3), sekä ohjelmistotoimittajia (6) ja muita asiantuntijoita (8). InfraTimantti esiselvityshankkeen loppuseminaariin osallistui 28 kutsuttua alan asiantuntijaa ja vaikuttajaa.
7 (63) 2 Infran tilaajien hankinta- ja toimintamallit Esiselvityksen ensimmäisessä vaiheessa tavoitteena oli tarkastella infran tilaajien toimintaprosesseja keskittyen lähinnä hankintoihin (eri suunnitteluvaiheet, rakentaminen, hoito ja ylläpito). Selvityksen alla olivat hankintaorganisaatiot, toteutusmuodot, tietojärjestelmien hyödyntämisen yleinen taso ja tiedonhallinta ja tiedon kulku hankkeissa. Pyrittiin paikantamaan ongelmat prosessin eri vaiheissa ja arvioimaan, onko kehittämis- ja painotustarpeita eri toimintojen tai vaiheiden kesken. Selvitys toteutettiin strukturoituina haastatteluina (kyselylomake esimerkki Liite 1) ja työpajoissa. Työpajoissa kantaa oli ottamassa myös tuottajapuolen edustajia. Yleisesti ottaen toimijoiden välisistä ongelmista saatiin haastatteluissa palautetta huonosti: oman toiminnan rutiineihin oltiin pääsääntöisesti tyytyväisiä, ja muiden toimijoiden tarpeista ei välttämättä oltu tietoisia (eikä myöskään osattu esittää muita kohtaan omaa työtä helpottavia parannuksia). 2.1 Prosessi Tarveselvitys/ Esisuunnittelu Yleissuunnittelu Väyläsuunnittelu (Tie-/Rata-/Katu/Yl.alue) Rakentaminen Hoito & ylläpito Purkaminen & kierrättäminen Tarveselvitys, muutoksen/ korjauksen suunnittelu, rakentaminen... Selvityspäätös Tarveselvitys Suunnittelupäätös -Lain määrittelemällä tasolla prosessit yhtenäisiä kuntien kesken sekä kuntien ja liikenneviraston välillä -Roolituksissa eroja - kuinka pieneksi työnjako on pilkottu ja monellako tasolla on päälliköitä Maakuntakaavoitus Valtakunn. alueidenkäyttösuunnitelmat Liikennejärjestelmäsuunnitelmat (Alustava yleissuunni -telma) Yleissuunnitelma YVA Yleiskaavoitus ja yleiskaavojen muutokset Nähtävillä olo Muistutukset Lausunnot Hyväksymispäätös Hyväksymispäätös Väyläsuunnitelma Asemakaavoitus ja asemakaavojen muutokset Mahdolliset valitukset Nähtävillä olo Muistutukset Lausunnot Mahdolliset valitukset Rakentamissuunnitelma Rakentaminen Kuva 1 Väylähankkeen prosessikaavio. Kuva muokattu tiehallinnon [14] ja ratahallinnon[8] kuvien perusteella. Lain määrittelemällä tasolla prosessit ovat yhtenäisiä kuntien kesken ja kuntien ja liikenneviraston kesken (Kuva 1). Roolituksissa on eroja, esim. siinä kuinka pieneksi työnjako on pilkottu ja monellako tasolla on päälliköitä. Tarveselvitystä eivät haastatellut kaupunkien ihmiset yleensä lukeneet prosessissa olevan ollenkaan, tai he katsoivat sen olevan jotain, mitä kaavoituksen yhteydessä selvitellään tai vaihtoehtoja mietitään.
8 (63) Vain isot uudishankkeet menevät tämän koko lakimääräisen prosessin läpi. Pieniä korjauksia ja muutoksia tehdään suoraan virkamiespäätöksillä. Näin voidaan menetellä, kun toimenpide ei aiheuta muutoksia katusuunnitelmaan. Pienet hankkeet kirjataan vuosittaiseen ohjelmaan, jota eri organisaatiot kutsuvat hieman eri nimillä (toiminta- ja taloussuunnitelma/rautatiet, suunnitteluohjelma/ tiehallinto, rakentamisohjelma/kunnat) (Kuva 2). Määräraha Uusi tarve Toiminta & tal.suunnitelma/ Suunnitteluohjelma/ Rakentamisohjelma Suunnitteluttaminen Suunnitteluttaminen Rakennuttaminen Rakennuttaminen Suunnitteluttaminen Rakennuttaminen Hoito ja ylläpito Kuva 2 Pieniä hankkeita tehdään vuosittaisen suunnitelman mukaan 2.1.1 Koetut ongelmat ja tietotarpeet Ongelmien nimeäminen osoittautui yllättävän hankalaksi tilaajien haastatteluissa. Joko niitä ei nähty omasta näkökulmasta juuri olevan, tai jos niitä oli, ne otettiin itsestäänselvyytenä: "Tuleehan siellä työmaalla aina kaikenlaista. Ne sitten vaan selvitetään." Valmius ja halukkuus uusiutumiseen vaikuttivat heikoilta. Tehtävien ulkoistamiskehitys on johtanut siihen, että tilaajat ovat jääneet melko "hallinnolliseen" rooliin rakennushankkeisiin nähden. Tilaajan edustajat hoitavat vain kilpailuttamista ja päätöksentekoa. Tilaajan etääntymisestä oltiin yhtä mieltä ja myös siitä, että se on huono asia. Myös laatu uhkaa laskea, kun oma tuntuma lopputuotteeseen katoaa: "Ollaan uskon varassa, kun urakoitsija sanoo, että näin se laatu syntyy." Myöskään tietotarpeista ei päästy juuri keskustelemaan. Hankkeet ja prosessit hahmotetaan tehtävien kautta ja tuotettavien suunnitelmien ym. tuotosten kautta ei tiedon tuottamisena ja "kuluttamisena". Ei ole olemassa listauksia siitä, mitä tietoja itse asiassa tilataan ja saadaan, kun tilataan esimerkiksi "yleissuunnitelma" tai "luovutuskansio".
9 (63) Haastatteluissa nousi esiin tarve siirtyä osa-optimoinnista kokonaisoptimointiin. Myös tarvetta suunnittelun parantamiseen mainittiin monesta näkökulmasta: vaihtoehtoja olisi selvitettävä enemmän, suunnittelu olisi tehtävä koko elinkaaren näkökulmasta, suunnittelun ohjausta tilaajan toimesta voisi parantaa, samoin suunnittelijan ja rakentajan vuorovaikutusta. Alalla on vielä varsin jyrkät osapuolten väliset rajat. Yhteistä näkemystä ja ymmärrystä on vähän. Pääurakka-maailmassa kärjistetysti kuvattuna suunnittelijalla ei ole käsitystä siitä, mitä/miten rakentaja tekee ja mitä tietoa/aineistoa tämä tarvitsee. Linkkinä suunnittelijan ja rakentajan välillä on tilaaja. Tilaajalla on vastuu tarpeiden selvittämisestä ja tiedon välittämisestä "rajan" yli - molempiin suuntiin. Tuottajaosapuolet kokivatkin tästä syystä ST-toteutusmuodon hyväksi. Siinä suunnittelija ja rakentajat ovat suorassa vuorovaikutuksessa, jonka molemmat kokivat omalta kannaltaan hyödylliseksi. Aiheeseen liittyvää kommentointia: - suunnittelu on ongelma jos suunnittelun sisällön määrittely ontuu - mitä on pyydetty suunnittelijalta tilausvaiheessa?..eli joskus tulee törmäyksiä työmaan kanssa asioista, joita ei ole tilattu - koneautomaatio tarvitsee täyden mitta-aineiston, tämä pitää tilata jo suunnittelutilauksen yhteydessä - tilaajan tule kertoa miten ylläpidon näkökulmat huomioidaan ja suunnittelijalla tulee olla osaamista - joskus rakennuttajakonsultti pitää huolen, että suunnittelija ei edes pääse työmaalle - as-built-tiedon huono palautuminen on tilaamisongelma. Ei vaadita parempaa. Myös tilaajien omassa organisaatioissa hankkeiden hoitaminen oli jaettu eri vaiheissa eri henkilöille. Tämä saattaa entisestään hankaloittaa vaiheiden välistä yhteyttä. Laeissa määritellyt eri suunnitteluvaiheet näyttäytyivät hyvin erillisinä. Tuottajaosapuolten haastatteluissa "suunnittelulla" tarkoitettiin lähinnä yksinomaan rakennussuunnitteluvaihetta. Myös tilaajien edustajat viittasivat yleissuunnittelu- ja väyläsuunnitteluvaiheisiin "hallinnollisina vaiheina". Edelleen kokonaisoptimoinnin ja uudenlaisten ratkaisujen kehittämisen näkökulmasta tämä vaikuttaa ongelmalliselta. Yhteiskunnallinen ulottuvuus (vuorovaikutus, hyväksyttävyys, ympäristöarvot, jne.) ja tekninen ulottuvuus (kestävyys, laatu, kustannukset, jne.) eivät kohtaa, jos niitä tarkastellaan erillisinä erillisissä vaiheissa. Myös eri hallinnonalojen sektorit mainittiin hankalina kuntien toiminnassa. Ymmärrys toisten prosesseista ja toiminnan tavoitteista ei aina kohdannut esimerkiksi maankäytön suunnittelun, maanmittauksen ja infranpitoa tekevän viraston/osaston välillä.
10 (63) Kommentteja: - hankkeet ovat pitkiä aina matkan varrella ei voi muistaa miksi on tehty tietty ratkaisu. tätä tietoa ei nykyprosessissa välttämättä dokumentoida - elinkaarinäkökulmaa lisää! Malli millä lasketaan, yhteiset numeroarvot (tietokanta 2011) - Kuuleminen ja muistutukset: Useimmiten ihmisten muistutukset/valitukset ei "kohdistu tuotteeseen". Ei varsinaisesti valiteta asiasta, johon suunnitelma edes vaikuttaa. Kaikki valitukset käsitellään oikeudessa ja odotettava on päätöstä, vaikka se suurella todennäköisesti on kielteinen. 2.2 Käytettävät ja kehitettävät toteutusmuodot Saatujen vastausten perusteella perinteiset toteutusmuodot (pääurakat) ovat ylivoimaisesti eniten käytettyjä (suunnittelun tilaamisessa myös erilaiset palvelusopimukset sekä hoidon ja ylläpidon osalta oma työ). Syyksi mainitaan vakiintuneet käytännöt ja myös hankintalaki (joko todellisena syynä tai oletettuna). Uusista toteutusmuodoista tilaajat eivät ole kokeneet toistaiseksi olevan suurta etua. Tosin kokeiltukin on hyvin vähän. Vain Liikennevirastossa on laajempaa kokemusta ST-urakoista. liitteessä (Liite 2) on esitetty taulukkona yhteenveto kuntien ja liikenneviraston käytössä olevista toteutusmuodoista. Tilaajat olivat myös sitä mieltä, että tähän asti "hankintainnovaatiot" (eli uudet hankintamuodot) ovat olleet urakoitsijalähtöisiä: isot urakoitsijat ajavat niitä, koska näkevät niissä mahdollisuuksia itselleen. Tavallaan myösniiden avulla syrjäytetään pieniä yrityksiä, joilla ei ole resursseja tai osaamista näihin toteutusmuotoihin..
11 (63) Kommentteja: - Isoissa hankkeissa voi lähteä kokeilemaan jotain uutta. Pienet hankkeet niin pieniä ja simppeleitä, että niissä vaikea nähdä hyötyä uusista muodoista - Elinkaarimalli: Tuleeko ongelmaksi saada tarjoajia? Kaupunkien hankkeet/tilaukset pieniä ja kokonaisuutenakin niissä markkinat ovat aika pienet. Kannattaako kenenkään niihin erikoistua? - Uutta sovelletaan vähän, koska rahat on niin tiukilla joka tapauksessa. Ei haluta ottaa mitään ekstra riskejä. - Alueurakointi: markkinat on vielä heikot. "Siellä on sitten aina vaan Destia ja NCC tarjoamassa". Viherpuolen osaamista puuttuu. Yritysten pitäisi panostaa tähän. - ST: Katusuunnitelman jälkeen S:lle jää joka tapauksessa niin pieni liikkumavara, että en oikein ymmärrä, mikä sen s:n merkitys siinä sitten on. (tilattaessa rakennussuunnitelma + rakentaminen) - ST: on jo otettu vähän takaisinkin päin, eli ensin innostuttiin kovinkin, nyt on havaittu, että joihinkin tapauksiin sopii, joihinkin ei. - Ei kummoisia innovaatioita ole uudet toteutusmallit synnyttäneet Toistaiseksi näyttää siis siltä, että "innovatiivinen hankinta" on toiminut niin, että sopimussuhteet ja roolit hiukan muuttuvat, mutta kaikki tehdään muuten samalla tavalla kuin ennenkin. Todellisia muutosodotuksia sisältyi elinkaarimalliin ja suunnittele-toteuta-ylläpidä-malliin, jossa olisi urakoitsijalla riittävän pitkä ylläpitovastuu (vähintään 15 vuotta). Haastetta näiden muotojen tilaamiseen tuo se, että on vaikea määritellä vaatimuksia ja tavoitteita 15-25 vuoden päähän. "Maailma voi muuttua." Arveltiin, että kuntien hankkeista luultavasti vain isoimmat kerralla rakennettavat uudet alueet olisivat sellaisia joiden elinkaarivastuusta joku voisi olla kiinnostunut. Oltiin yksimielisiä siitä, että osittain epäinnovatiivisuus johtuu tiukoista rajoittavista tekijöistä ja niistä johtuvista vapausasteiden puutteista (hankintalaki, jäykät lakimääräiset prosessit). Esiin näyttäisi nousevan uudistusten hakemisen tarve tilaajan puolella omasta näkökulmasta: hyötyjä pitäisi aktiivisesti hakea itse itselleen/yhteiskunnalle. Toisaalta haasteena on se, että ulkoistaminen on lähes totaalista ja kehittämismahdollisuus katkeaa. Hoidossa ja ylläpidossa pohdittiin vaihtoehtoja, joissa tietyllä alueella sama urakoitsija hoitaisi sekä teiden että ratojen ylläpitoa tai joissa sekä Liikenneviraston tiet että kunnan kadut/tiet hoidetaan yhdellä sopimuksella. Hoidossa ja ylläpidossa trendi näyttäisi siis olevan kohti suurempia kokonaisuuksia ja kokonaispalvelua. Laajemmassa viitekehyksessä Valtion taloudellisen tutkimuskeskuksen tutkijat kuvaavat virkamiehen kannustimia seuraavasti: Virkamiehellä ei ole välittömiä taloudellisia kannustimia investointien pitkän aikavälin kustannusten ja riskien minimointiin, koska he eivät ole suorassa taloudellisessa vastuussa investointien tuotosta. Tämä ongelma korostuu useissa julkisen sektorin toiminnoissa, missä palvelulle tai olemassa olevalle pääomalle ei ole määritelty taloudellista tai yhteiskunnallista arvoa tai palvelun laatuun reagoivaa kysyntäjärjestelmää. [7]
12 (63) 3 Infra-alan tiedonhallinnan kartoitus Tiedonhallinnan kartoittamiseksi tehtiin sähköpostitse tilaajille kyselylomakkeeseen perustuva kysely (Liite 3). Lisäksi aihetta laajennettiin (puhelin)keskusteluin muutaman henkilön kanssa (LV tieosasto ja rautatieosasto, kaksi kaupunkia). Tilaajatahojen tietojärjestelmiin liittyen pyrittiin selvittämään, mitä ohjelmia ja järjestelmiä kullakin on käytössä, kuinka hyvin ne tukevat toimintaa, ja mitä ongelmia tietojärjestelmiin liittyen koetaan olevan. Tietojärjestelmien käyttöön ja toimivuuteen liittyviä asioita kartoitettiin tilaajilta osittain myös ensimmäisen vaiheen toimintamallihaastattelujen yhteydessä. Ensimmäisen vaiheen haastatteluissa nousseita tietojärjestelmiin liittyviä asioita työstettiin myös 18.3.2010 työpajassa. Tuottajaosapuolen tilannetta selvitettiin muutamalla kohdennetulla syväluotaavalla haastattelulla. Kaksi suunnittelu- ja kaksi urakoitsijayritystä haastateltiin. Ohjelmistotoimittajille tehtiin lomakekysely (Liite 4), jolla pyrittiin saamaan vertailukelpoista tietoa ohjelmistojen käyttötarkoituksista, tietomallinnusta mahdollistavista ominaisuuksista ja tiedonsiirto-ominaisuuksista. Selvityksessä käsiteltiin sekä teknologisia että prosesseihin ja käytäntöihin liittyviä asioita. 3.1 Tilaajien järjestelmät Tilaajatahojen käytössä on lukuisa määrä erilaisia ohjelmia. Kukin kunta on hankkinut ohjelmia omassa tahdissaan sitä mukaan ja siitä näkökulmasta kuin on katsonut tarpeelliseksi. Liikennevirastossa (erityisesti rautatieosastolla) ollaan erillisten ohjelmien ja järjestelmien integroinnissa jonkin verran pitemmällä kuin kaupungeissa. Liikennevirastolla on käytössä itselle räätälöityjä järjestelmiä ja kaupungeissa kaupallisia ohjelmistotuotteita. Toisaalta kaupungeista saattaa löytyä myös itse omin käsin tuotettuja sovelluksia. ELY-keskukset toimivat valtakunnallisesti samoilla, pääosin liikenneviraston määrittelemillä ohjelmilla. Tilaajan ja infran omistajan kannalta (käytön ja) kehittämisen keskiössä ovat omaisuudenhallintaan liittyvät rekisterit sekä hallinnollisiin prosesseihin ja talouteen (projektinhallinta, toiminnanohjaus) liittyvät ohjelmistot. Alla (Kuva 3) on esitetty infranpidon jakautuminen kolmeen tunnistettuun pääalueeseen: omaisuudenhallinta, omaisuuden käytön hallinta ja hankkeiden hallinta. Kokonaisuuteen liittyvät lisäksi maankäytön suunnittelu ja liikennejärjestelmätason suunnittelu. Kyselyssä nimettiin jonkin verran aluesuunnitteluun ja maankäytön suunnitteluun liittyviä ohjelmia, liikennejärjestelmätason tiedonhallintaan ja suunnitteluun liittyviä ei juurikaan. Kuva 3 esittää lilalla tekstillä listattuna kyselyssä nimettyjä ohjelmistoja omaisuudenhallintaan, käytön hallintaan ja hankkeiden hallintaan liittyen. Sinisellä tekstillä on merkitty toimintoja, johon tietoa ja järjestelmiä tällä alueella käytetään.
13 (63) HOITO- JA YLLÄPITOURAKAT Puisto Monsu Saarni 2 YAOH kunnossapitosovellus... Ennakkotietojärjestelmä (LV) Kaivuuluparekisteri YAOH luparekisteri Xcity elupa Winkki Alueiden käyttö ASPA/KeyInfo Asiakaspalautejärjestelmä Maisematyölupatietokanta Stella Map... KÄYTTÄJÄT KÄYTTÄJÄT Hoidon ja ylläpidon suunnittelu ja kilpailuttaminen... Liikennöinti Lupa-asiat Asiakaspalvelu... OMAISUUDEN HALLINTA Perustiedot Kuntotieto KÄYTÖN HALLINTA KÄYTTÄJÄT KÄYTTÖ YLLÄPITO Omaisuuden arvo ja palvelukyky RAK. Kunnon seuranta SUUNN. Korjaussyklien ennustaminen... Toiminnanohjaus Projektinhallinta... HANKKEIDEN HALLINTA Tierekisteri (LV) Siltarekisteri (LV) Ratapurkki (LV) Novapoit Iris Tekla YAOH-rekisteri MapInfo FACTA-kuntarekisteri YLRE/KeyArea PuuAtlas Vire Silvakuviot CityCAD... Sampo (LV) ProConsept Planet MSO Project server FORE ProjectWise KeyWinkki... KORJAUSHANKKEET UUSINVESTOINNIT Xstreet Vectorworks Ec-Trak Syncro AutoCAD Map Ytcad Fiksu M-color Liisu... Kuva 3 Tunnistetut tilaajien toiminnan ja tietojärjestelmien osa-alueet. Kyselyssä nimetyt infranpidon järjestelmät jäsennettynä osa-alueille. Omassa toiminnassa tarvittava tieto ja tiedon hyödyntäminen nykyjärjestelmillä on tutkimuksessa mukanaolevilla haastatelluilla tilaajilla otettu haltuun. Viimeisilläkin toimijoilla ainakin järjestelmien käyttöönotto on menossa. Kautta linjan kuitenkin tunnustetaan, että hyödyntämispotentiaalia on vielä jäljellä ja opetteluvaiheessa ollaan edelleen. Omaisuudenhallinnan alueella tavoitteena tietojärjestelmien hyödyntämisessä on tietoisuuden nostaminen omaisuuden määrästä ja kunnosta. Tätä kautta tavoitteena on mahdollistaa objektiiviseen tietoon perustuvat päätökset mielipidepäätösten sijaan ja mahdollistaa optimaalinen ja perusteltu niukkojen budjettien allokointi. Hankkeiden hallinnan alueella esiin nousee lähinnä talous: raha, sopimukset ja ajan tasalla pysyminen. Hankkeiden sisällölliset asiat eivät nouse esiin. Tämä liittynee luvussa 2 esitettyyn tilaajan etääntymiseen hankkeen sisällöstä. Suunnittelu ja rakentaminen on ulkoistettu, ja hankkeen kulkuun ja sisältöön vaikutetaan papereista käsin. Omaisuudenhallinta lähinnä omien prosessien tehostamista. Hankkeiden hallinta mahdollistaa parhaassa tapauksessa projektiorganisaation toiminnan tehostamista. Käytön hallinnan alueella omaisuustieto mahdollistaa ulospäin suunnattuja palveluja, jotka tehostavat koko yhteiskunnan toimintaa sähköisinä palveluina ja sähköisenä vuorovaikutuksena. Esimerkkejä tällaisista palveluista ovat mm. sähköiset luvat (maankaatolupa, kaivuulupa, jne.) kaupungin venepaikkojen vuokraus (mm. Tampereella ja Espoossa mahdollista verkon välityksellä), toripaikkojen vuokraus tai liikuntapaikkojen varaukset. Kuntien ja Liikenneviraston yhteinen Digiroad-palvelu on esimerkki olemassa olevan
14 (63) omaisuusrekisteritiedon hyödyntämisestä kolmannen osapuolen käyttäjille tuottamiin palveluihin. Kommentteja tiedonhallintaan liittyen: - ulkoistamis-/tilaamiskehitys itsessään vaatii kautta linjan parempaa tiedonhallintaa kuin omana työnä rakentaminen ja ylläpito. Omassa organisaatiossa riittää, kun tieto on jollain ja jotkut tietää, miten sen saa. Ulkoisen tahon kanssa, kun kyse on sopimuksista, tiedot pitää olla sovitussa muodossa ja ajan tasalla. Toistaiseksi tietomalli "loistaa poissaolollaan" tilaajien toiminnassa. Omaisuudenhallinnassa tällä hetkellä käsiteltävä "tuotetieto" on varsin yksinkertaista, "dataa": mittaustietoa, luokittelumaista tietoa. Tätä pidettiin toistaiseksi riittävänä päätöksentekoon. Nykyiseen tiedon tasoon on totuttu ja se koetaan paremmaksi kuin ei mitään, mutta voidaan kysyä synnyttäisivätkö paremmat mahdollisuudet ja tiedon tarjonta kysyntää havainnollisemmalle tai monipuolisemmalle tiedolle? 3.2 Tilaajien tiedonhallinnan ongelmat ja tarpeet tietojärjestelmille 3.2.1 Osaaminen Tiedonhallinnan osaaminen ja käsitteistö on hallussa niillä, joiden tehtävänä on juuri tämän alueen kehittäminen on. Näillä henkilöillä on mahdollista olla ja saavuttaa myös näkemys siitä, miten järjestelmiä tulisi hyödyntää ja miksi. Osaaminen on kuitenkin keskittynyt liian harvoille. Laajemmissa haastatteluissa ei ollut harvinaista, että käytössä olevia tietojärjestelmiä kysyttäessä osattiin nimetä sähköposti ja RT:n sopimusnetti. Nämä ovat epäilemättä kovassa käytössä olevia työkaluja, eikä kaikissa tehtävissä välttämättä tarvita juuri sähköpostia kummempia välineitä, mutta jollain tavalla tämä kuitenkin kertoo yleisestä osaamisen ja tiedostamisen tasosta, sillä jokaisessa kyselyssä mukanaolevassa kunnassa on käytössä erilaisia järjestelmiä, joita mm listattiin edellä (Kuva 3). Osaamisongelma myös tiedostettiin. Ohjelmistojen ja tietojärjestelmien käytettävyyteen toivottiin kiinnitettävän erityistä huomiota, jotta oppimiskynnys olisi matala. Myös uusien järjestelmien käyttöönottovaiheeseen suunniteltiin panostaa tulevaisuudessa enemmän. 3.2.2 Prosessit ja tiedonsiirto Nykyiset prosessit eivät mahdollista tietoteknisten välineiden hyödyntämistä tehokkaasti. Myöskään teknologisesti tiedonsiirto-ominaisuudet eivät ole vielä ohjelmistoissa sujuvalla tasolla. Tieto ei siirry vaiheesta toiseen, vaan sitä joudutaan tuottamaan uudestaan eri muodoissa.
15 (63) Kommentteja tiedonhallintaan liittyen: - Jos ohjelmasta toiseen olisi helppoa siirtyä, tehtäisiin kullakin ohjelmalla vain se, jossa se on paras, helppokäyttöisin tai tehokkain. Nyt on tehtävä yhdellä ohjelmalla mahdollisimman valmista tulosta, jotta hankalalta ja ongelmia-aiheuttavalta tiedonsiirtovaiheelta vältytään. Vain osa syistä on teknisiä (ohjelmien yhteensopimattomuus tai tiedonsiirrossa syntyvät virheet). Paperilla toimitettavaa tietoa on huono hyödyntää uudelleen. Myös sähköisessä muodossa olevan piirustuksen jatkohyödyntäminen on rajallista. Tietoa ei pystytä suoraan siirtämään esim. suunnitelmista ja/tai toteumatiedosta rekistereihin. Sähköiset prosessit ovat paikoitellen sellaisia, että piirustus tulostetaan, allekirjoitetaan tai leimataan ja skannataan sähköiseen arkistoon. Yhteisen tietomallin tai siirtoformaatin puutteesta on aiheutunut käsitys, että mitään ei voisi tehdä ennen, kuin se on kehitetty. Myös nykyisillä ohjelmistoilla voi toimia integroidummin ja uusia toimintamalleja voidaan luoda ja alkaa harjoitella nykytekniikasta lähtien. 3.2.3 Rekisterit Rekistereihin liittyen ongelmana koettiin olevan tiedon määrä ja tiedon oikean detaljitason määrittäminen. Vaakakupeissa ovat lähinnä mahdollisimman täsmällisen tiedon tallentaminen/välittäminen ja toisaalta tiedon ylläpidon aiheuttama työkuorma. Ongelma on myös rekisterien yhtenäisyyden puute valtakunnan tasolla. Rekisteriin talletetuista tiedoista ei ole olemassa sopimuksia tai standardeja. Kunnilla on ollut keskinäisiä kehityshankkeita, mutta ei yhtenäistä kaikkia kuntia yhdistävää kehityslinjaa. Toinen rekistereihin ja tiedon ylläpitoon liittyvä oleellinen kysymys on tietojen hallinnointi. Kuka tallentaa mitäkin, ja kuinka eri rekistereissä olevaa tietoa yhdistellään ja linkitetään toisiinsa. Tiedon kopiointi järjestelmästä toiseen on turhaa työtä (ellei ole täysin automaattista), ja tiedon kahdentuminen lisää ristiriitaisen tiedon riskiä, koska molempia sijaintipaikkoja ei todennäköisesti päivitetä samalla kertaa. 3.2.4 Visualisointi Tilaajapuolta selkeästi hyödyttäneitä käyttökohteita ovat havainnolliset 3D-mallit sekä ohjelmat ja menetelmät sähköiseen suunnitelmien näytteille asettamiseen. Näitä on tarpeen edelleen kehittää ja ottaa käyttöön. Tällä hetkellä lähinnä suurissa hankkeissa tehtiin 3D-malleja, muuten esillä oli piirustuksia pdftiedostoina. Käyttäjän näkökulmasta tulisi pyrkiä aina havainnolliseen, realistiseen malliin, joka on istutettu ympäristöön. Tämä parantaa suunnitelmien ymmärrettävyyttä.
16 (63) Teknisesti mallin on oltava kevyt, nopeasti latautuva, netin välityksellä selainpohjaisesti käytettävä. Mielellään mallien katselu ei vaatisi mitään asennuksia käyttäjältä. Yleisölle on tarjottava matala kynnys olla mukana prosessissa, ymmärtää ja vaikuttaa. Aineistoon voisi liittyä keskusteluosio, jonne voi heti jättää kysymyksiä, joihin esim. kerran viikossa kunnan asiantuntija tai suunnittelija käy vastaamassa. Monta asiaa selvinnee ilman huomautusta tai valitusta. Myös eri ihmisten jättämät kommentit avaavat yleisölle eri näkökulmia asiaan. 3.2.5 Resurssien ja strategian puute Kaikilla tilaajaosapuolilla ei ollut (ainakaan vastaajan tiedossa) tietoista strategiaa tiedonhallinnan käyttöönotosta tai kehittämisestä. Organisaatioiden IT-strategiat, jos niitä on, eivät ota kantaa tietomallin käyttöönottoon vaan keskittyvät sisäiseen tiedonhallintaan ja asiakkaiden sähköiseen palvelemiseen. Tietomallin hyödyntäminen on kuitenkin tulevaisuudessa myös osa sisäistä tiedonhallintaa. Jos tietomallinnusta ollaan kehittämässä, olisi hyvä tiedostaa, mihin sitä tarvitaan ja varautua sen hyödyntämiseen omasta näkökulmasta. Vasta kun on olemassa strategia ja on määritelty toimenpiteet sen toteuttamiseksi, voidaan saada ja määritellä resursseja ja rahoitusta asian kehittämiseen ja käyttöönottoon. 3.3 Tiedonhallinta tuottajien näkökulmasta Tuottajaosapuolten haastatteluissa pyrittiin selvittämään: suunnitteluryhmän keskinäistä toimintaa ja tiedon/tiedostojen vaihtoa, suunnittelijan ja urakoitsijan vuorovaikutusta ja tiedon vaihtoa, suunnittelijan ja tilaajan välistä vuorovaikutusta, suunnittelijan ja urakoitsijan käyttämiä ohjelmistoja ja niiden toimivuutta ja yhteensopivuutta. Tuottajille tietomallinnus ja integroitu tiedonhallinta rakennushankkeissa vaikuttaisivat olevan suuremman mielenkiinnon kohde kuin tilaajille, mutta käytännössä toimintatavat ovat edelleen hyvin perinteisiä, piirustussuuntautuneita. Pilottiprojektien ja tutkimusten raportit antavat varsin erilaista kuvaa kuin haastattelut. Tuottajan näkökulmasta, jos tilaaja jatkaa piirustusten tilaamista, mitään ei ole järkevää eikä tarpeen muuttaa. Alan laajaan muutokseen tarvitaan uudenlaisia tilauksia. Keskustelut tuottajien kanssa vahvistivat havaintoa, että jokainen tekee työtään hyvin paljon omista lähtökohdistaan ja on kiinnostunut vain omasta näkökulmastaan oleelliselta näyttävistä asioista. Yhteistä ymmärrystä ja kokonaisnäkemystä kaivattaisiin enemmän. Otokset tuottajien haastatteluissa olivat pieniä ja vaihtelut vastauksissa suuria, mikä asettaa tiettyjä varauksia johtopäätöksille.
17 (63) 3.3.1 Suunnittelu Suunnitteluohjelmistot lukevat toistensa formaatteja käyttökelpoisesti. Vallitsevaksi "tiedostostandardiksi" on muodostunut dwg. Lähes kaikki ohjelmat tuottavat ja/tai lukevat sitä. Tiedonsiirto on mahdollista ja suhteellisen toimivaa. Esim. suunnittelijat keskenään eivät käytä/tarvitse Inframodel-formaattia tiedonsiirtoon. Tieto kuitenkin jossain määrin korruptoituu siirroissa ohjelmasta toiseen. Suunnittelija tekee tuottamatonta työtä järjestelmästä toiseen ladattaessa korruptoituvan suunnitelmatiedon parsimisessa sekä piirustusten esitysteknisten yksityiskohtien (ulkoasun) virittelyssä (eri tilaajille erilaiset). Tuottajan näkökulmasta olisi tärkeää, että kaikki tilaajat toimisivat yhtenäisen käytännön mukaan. Olisi tietty suunta, johon perustaa kehittäminen omalla puolella. Tällä hetkellä on vaihtelua tilaajien kesken mm. siinä, mitä lähtötietoa toimitetaan ja minkälaisella muotoilulla ja missä formaatissa piirustuksia tilataan. Panostuksia on oman työn kehittämisessä jouduttu tekemään variaatioiden hallintaan. 3.3.2 Rakentaminen Rakentajan kiinnostus tiedon yhteiskäyttöön kulminoituu tällä hetkellä tavoitteeseen työkoneohjauksesta. 3D-ominaisuudet ovat suunnitteluohjelmistoissa käyttökelpoisella tasolla. Sen takia mm. työkoneohjaus on ollut mahdollista kehittyä suhteellisen korkealle tasolle muuhun kokonaisuuteen verrattuna. Koneohjaus ei nykyisellään vaadi varsinaista tietomallia. Koneet eivät ole "kiinnostuneita" tiedon sisällöstä ja semantiikasta, ainoastaan paikkatiedosta. Koneohjaus vaatii jatkuvaa 3d-mallia kohteesta. Suurissa ja/tai monimutkaisissa työmaissa havainnollisesta kolmiulotteisesta materiaalista olisi lisäksi hyötyä työmaan johdolle työn suunnittelussa ja organisoinnissa. Rakentaja ei ole täysin tyytyväinen suunnittelijalta tulevaan materiaaliin. Suunnitelmista (tiedostoista) puuttuu 3d-tieto, koska ne on tehty piirustukseen tähdäten. Lisäksi suunnitelmissa on jonkin verran virheitä. Kolmiulotteinen suunnittelu poistaisi lipsahdus-/ ajatusvirheitä suunnitelmista. Nykyisellään koneohjausmallien tuottaminen vaatii paljon käsityötä ja tiedon (tiedostojen) uudelleen generointia. Väyläsuunnittelussa alalla on vallinnut traditio, jossa suunnittelija tekee periaatteelliset suunnitelmat, joista rakentaja soveltaa tien paikalleen maastossa. Virtuaalimallinnus vaatii tähän muutoksen. Tarvitaan riittävän tarkka, jatkuva malli, jonka ominaisuudet voidaan laskea, simuloida ja arvioida jo ennen rakentamista ja jonka avulla kohde voidaan mitata maastoon automaattisesti. 3.3.3 Projektin tiedonhallinta Suurimmissa hankkeissa käytetään (ja tilaajankin taholta vaaditaan) projektitiedon hallintaan projektipankkia. Kautta linjan haastatteluissa toivottiin projektin tiedon jakamiseen ja hallintaan kehitettävän ja otettavan käyttöön parempia työkaluja.
18 (63) Käytössä on perusprojektipankit (esim. Buildercom ja Sokopro), joiden käytettävyys ei tyydytä. Myös projektipankkikäytöntöihin tulisi laatia sopimuksia ja ohjeita. Erilaiset tiimityöskentelyominaisuudet ja projektin tiedonhallintaohjelmistot ovat olleet tiiviin kehittämisen kohteena aivan viime aikoina. Uudenlaisia alustoja tulisi testata. Suunnittelijat hahmottavat hankkeen suunnitelman kautta ja toivovat visuaalista malliin/suunnitelmaan pohjautuvaa käyttöliittymää myös muiden dokumenttien hallintaan (esim. Bentley Geospatial Server). 3.4 Tiedonhallinnan kartoituksen johtopäätökset Tavoitteeksi oli asetettu vastata kysymykseen, tukevatko ohjelmistot ja tietojärjestelmät prosesseja. Tutkimuksen jälkeen suurempana ongelmana näyttäisi olevan se, että toimintatavat eivät tue järjestelmien käyttöä. Jo nyt käytössä olevat järjestelmät mahdollistaisivat jonkin verran uusia toimintamalleja. Mahdollisuuksia on enemmän kuin on pystytty ottamaan käyttöön. Lisäksi tavoitteena oli selvittää tilaajan tarpeet järjestelmille ja tietomallille. Vastausten mukaan tarpeita ei juuri olisi tai niitä on hyvin vaikea nimetä. Vaikuttaa olevan epäselvää, mihin tai miten tietomallitietoa tarvittaisiin tai hyödynnettäisiin tilaajan prosesseissa? Sama vaivaa osittain tuottajapuolella. Selviä hyödyntämiskohteita kuitenkin suunnittelu- ja rakentamisprosessissa on (havainnollistaminen, kustannusten hallinta, suunnitelmien yhteensovittaminen, koneautomaatio). Infra-alalla tietomalli tulee ehkä olemaan monitahoisempi asia kuin talonrakennuksessa. Talo pitää itsessään sisällään toiminnan ja ominaisuudet, joista ollaan kiinnostuneita ja joita hyödynnetään. Taloa mallina tarkastelemalla voi simuloida ja arvioida näitä ominaisuuksia. Talo on "tuote". Infra puolestaan on luonteeltaan ennemminkin järjestelmä, joka mahdollistaa toimintaa. Infratuotteet; tie, katu, rata, puisto, vesijohtoverkosto ovat järjestelmän osia. Itse tuotetta esim. väylää mallintamalla voidaan tarkastella väylän (teknisiä?) ominaisuuksia. Väylää käytetään siirtymiseen paikasta toiseen tai kuljetukseen. Kiinnostava tarkasteltava/simuloitava asia on myös yhteiskunnan toiminta väylän kanssa tai ilman. Se ei selviä pelkästään väylän mallin avulla. Infralle ominaista on myös "alueellisuus". Infra toimii kokonaisuuksina, joilla on suhteita toisiinsa. Mallit muodostuvat "kerroksittain" rakenne/tuote - alue - yhdyskunta - yhteiskunta? Infratietojärjestelmissä oleellista on yhteys paikkatietoon. Alla (Kuva 4) on laajennettu tietojärjestelmien jaottelua. Kuvassa tilaajan/omistajan toiminta ja olemassa oleva infra on vihreän renkaan sisäpuolella. Kehän ulkopuolella on infraan liittyviä toimintoja. Maankäytön suunnittelulla, kaupuankisuunnittelulla ja liikennejärjestelmäsuunnittelulla vaikutetaan siihen, mitä infraa rakennetaan ja minne. Tällä alueella on omat ohjelmistonsa ja tietomallinsa (säiliöt ja hilat). Rakennushankkeissa osapuolilla tulee olemaan eri käyttötarkoituksiin eri ohjelmia ja tietomalleja, samoin hoidossa ja ylläpidossa. Käyttäjien kanssa kommunikoidaan tiettyjen järjestelmien
19 (63) välityksellä. Kuva 4 havainnollistaa sitä, että tietomalleja tuleekin olemaan ei yksi vaan monta. Tietomalli itsessään ei (yksin) ratkaise keskitetyn tiedonhallinnan ongelmaa. Sen sijaan tietomallin voisi nähdä työkaluna, joka mahdollistaa osapuolten uudenlaista yhteistoimintaa ja yhteisen tiedon hyödyntämistä. Tämän kuvan esitystavassa yhteisesti sovittava ja kehitettävä asia ovat säiliöiden väliset nuolet. Tämä sisältää sopimukset siitä, missä tilanteissa tietoa on osapuolten/järjestelmien välillä siirrettävä, mikä on tarvittava tietosisältö ja mikä on tiedon muotoilu, formaatti. Tärkeää olisi sopia sisällöistä: mitä tietoa mitäkin tarkoitusta varten a) tallennetaan b) vaihdetaan. Tärkeää on sen ymmärryksen saavuttaminen, kuka tarvitsee mitäkin tietoa ja mihin. Kun rajapinnat on määritelty, kukin voi tykönään toimia omilla ohjelmillaan ja omien systeemiensä mukaan omalla detaljitasollaan, kunhan pystyy bisnesteknisissä tilanteissa tuottamaan sovitun rajapinnan mukaiset asiat sovitulla tavalla. Kuntokartoitukset LIIKENNEJÄRJESTELMÄ- SUUNNITTELU HOITO- JA YLLÄPITO OMAISUUDEN HALLINTA Rekisterit, kuntotieto KAUPUNKISUUNNITTELU, MAANKÄYTÖN SUUNNITTELU Lähtötietojen hankkiminen KÄYTTÄJÄT Käyttöluvat, varaukset, vuokraukset,... KÄYTÖN HALLINTA HANKKEIDEN HALLINTA Projektinhallinta, kustannusten hallinta Suunnittelu, rakentaminen, projektinjohto UUSINVESTOINNIT KORJAUSHANKKEET Kuva 4 Infra-alan tiedonhallinnan kokonaisuus Seuraavassa (Kuva 5) on listattu tässä esiselvityksessä tilaajien, tuottajien tai ohjelmistotoimittajien nimeämät ohjelmat. Kuvan listaus (suuremmassa koossa ks. Liite 5) ei ole tyhjentävä listaus infra-alan ohjelmistoista. Ohjelmistojen kartoittamista tulee jatkaa kattavan kuvan saamiseksi siitä, mihin kaikkiin käyttötarkoituksiin ohjelmistoja on olemassa, millaisia ominaisuuksia niissä on ja miten ohjelmistot tällä hetkellä ovat yhteensopivia.
20 (63) HOITO- JA YLLÄPITO Puisto Monsu Saarni 2 YAOH kunnossapitosovellus Novapoint IRIS Novapoint IRIS RDA Novapoint Utitlity Network Optram Enterprise Suite XPipe XPower OMAISUUDEN HALLINTA Tierekisteri (LV) Ratapurkki (LV) Novapoint IRIS Novapoint Utility Network YAOH-rekisteri MapInfo FACTA-kuntarekisteri YLRE/KeyArea PuuAtlas Vire Silvakuviot CityGIS XPipe LiisiRekisteri LIIKENNEJÄRJESTELMÄ- SUUNNITTELU Novapoint Area Planning Novapoint Map Stella Map ProjectWise XCity CityCAD KAUPUNKISUUNNITTELU, MAANKÄYTÖN SUUNNITTELU Asiakaspalautejärjestelmä Sähköiset palvelut Novapoint Web Stella Web KÄYTTÄJÄT SpatialWeb ecity einfra DigiRoad KÄYTÖN HALLINTA Ennakkotietojärjestelmä (LV) Kaivuuluparekisteri YAOH luparekisteri Xcity elupa Winkki Alueiden käyttö ASPA/KeyInfo Asiakaspalautejärjestelmä Maisematyölupatietokanta Stella Map LIIRE HANKKEIDEN HALLINTA Sampo (LV) ProConsept Planet MSO Project server FORE ProjectWise KeyWinkki... Xstreet Microstation XPipe RM Bridge Tekla Structures PowerCivil for Finland Vectorworks Rail Track Ec-Trak Syncro Novapoint Base AutoCAD Map ProjectWise Ytcad Geospatial Server Fiksu LOUHI M-color Novapoint Civil Construction Liisu Novapoint Site Tools Novapoint Landscape Novapoint Road Novapoint Soundings Novapoint Railway Novapoint Geocalc UUSINVESTOINNIT Novapoint Road Marking Novapoint Road Signs KORJAUSHANKKEET Novapoint Tunnel Novapoint Virtual Map Kuva 5 Infra-alan ohjelmistoja listattuna edellisen kuvan jäsennyksen mukaan Kuviin liittyen havaitaan, että suunnittelupuolella on paljon tarjontaa; ylläpito- ja käyttöpuolella huomattavasti vähemmän Omistajien/tilaajien järjestelmät ja ohjelmistot sijoittuvat renkaan keskelle. Laajempaan yhteiskunnalliseen tason arvottamiseen/poliittiseen päätöksentekoon soveltuvat ohjelmat ovat vielä pääosin kehittämättä. Selvästi eniten esimerkkejä ja kokemusta mallinnuksesta on siltojen osalta sekä puistojen osalta. Molemmissa voidaan hyödyntää talopuolen mallinnusohjelmia. 3.4.1 Merkittävimmät kehitystä estävät tekijät Teknologian potentiaalin täysi hyödyntäminen vaatii tulevaisuudessa siinä mielessä varsin perusteellisia muutoksia, että useat "paperiprosessiin" liittyvät asiat ovat kirjattuna eri lakeihin. Jotta esimerkiksi allekirjoituksiin ja sähköiseen arkistointiin liittyvät esteet poistuvat, näihin asioihin on kehitettävä ratkaisut, ja lait on muutettava siltä osin. Nämä esimerkit liittyvät sähköisen asioinnin kehittämiseen yleisellä tasolla (myös muilla aloilla kuin infranpidossa), ja niiden tiimoilta on kehityshankkeita jo käynnissä (esim. KRYSP [18] ja SADe [19]). Teknologian kehittämisen kannalta keskeiset kysymykset ovat: tukevatko ohjelmistot tehokkaasti suunnittelijan/urakoitsijan/palveluntarjoajan omaa työtä, ja tuottavatko ohjelmistot sitä tietoa, jota prosessissa tarvitaan? Tarvitaanko näistä näkökulmista ikään kuin sisällöllisiä parannuksia ohjelmiin? Teknisiä parannuksia ja lisäominaisuuksia tarvitaan (ainakin) käytettävyyden ja tiedonsiirron parantamiseen.
On epäselvää, mikä infratietomalli on tietomalli esitetään huolettomasti yhteydessä kuin yhteydessä kaikki ovat mielestään sitoutuneet yhteisen tietomallin kehittämiseen ja samaan aikaan puhuvat kukin eri asiasta ymmärrys ja kehittäminen on siksi pysynyt yleisellä tasolla Tilaajan vaatimukset kohdistuvat piirustuksiin -> ei tuoteta parhaalla mahdollisella tavalla suunnittelu- ja rakentamisprosessissa hyödynnettävissä olevaa tietoa Kaikki suunnitteluohjelmistot eivät ole mallintavia ja parhaat ohjelmistot eivät ole vielä laajassa käytössä ei ole edes mahdollista tuottaa vielä tietomalleja Jyrkkä jako vaiheisiin rakennushankkeissa ja eri osapuolten siiloutuminen sekä tilaajan (sisäiset osaprosessit) että tuottajien puolella vähentää ymmärrystä muiden prosessin vaiheiden ja toisten osapuolten tarvitsemasta tiedosta toimintamallina estää kokonaisoptimointia 21 (63)
22 (63) 4 Best Practise esimerkkejä Tässä InfraTimantti esiselvityksen osassa esitetään valittuja esimerkkejä kehityksen kärjestä ja hyvistä käytännöistä tietomallinnukseen liittyen. Esimerkit ovat osittain tutkimuksia, osittain teknologian kehityksen kärkeä ja osittain soveltamisen parhaita käytäntöjä. Esimerkit ovat sekä infrarakentamisesta että talonrakentamisesta. 4.1 Tilaajan hankintaprosessin ohjaus Allianssi on hankintamalli, jossa projektin pääosapuolet solmivat keskinäisen sopimuksen ja muodostavat projektiorganisaation, joka huolehtii kaikkien projektin vaiheiden toteutuksesta. Kaikki osapuolet ovat mukana päätöksenteossa kaikissa vaiheissa. Esimerkkikaavio projektiorganisaation rakenteesta, Kuva 6. Sopimus perustuu hankkeen tavoitehintaan, jonka ylitykset tai alitukset jaetaan osapuolten kesken. Samalla projektin riskit ja voitot jaetaan. Tämä muodostaa kaikille osapuolille yhdensuuntaiset intressit, minkä katsotaan olevan allianssihankintamallin päähyöty ja mahdollisuus (Kuva 7). Kaikki joko voittavat tai häviävät, eikä kyse ole enää "nollasummapelistä". Toiminnan läpinäkyvyys lisääntyy, kun kaikesta on sovittava osapuolten kesken avoimesti ([5][6][10]). Kuva 6 Esimerkkikaavio allianssiprojektin järjestäytymisestä. (Kuva Pertti Lahdenperä [6]). Allianssimallia on tutkittu ja raportoitu runsaasti jo aiemmin, esimerkiksi [5][6]ja [10]. Myös mm. Liikennevirasto on ollut mukana allianssia tutkineissa tutkimushankkeissa. Tässä itse hankintamallia ei esitellä tarkemmin, vaan seuraavaksi keskitytään tämän tutkimuksen havaintoihin, joiden perusteella allianssimallia voitaisiin myös tietomallintamisen näkökulmasta pitää hyvänä hankintamuotona.
23 (63) Kuva 7 Allianssihankkeessa tilaajan ja tuottajien taloudelliset intressit ovat samansuuntaiset. Tämä mahdollistaa lopputuloksen paranemisen (performance level). (Kuva Pertti Lahdenperä [6]) Allianssimallissa tilaaja tulee osaksi toteutusorganisaatiota. Tämä ehkäisee todettua ja vastaajia huolestuttanutta tilaajan etääntymistä hankeprosessista ja sen mukana lopputuotteen ominaisuuksista. Allianssimallissa kaikista projektin osapuolista muodostetaan työryhmät, joissa kaikki osallistuvat päätöksentekoon. Tämä automaattisesti palvelee tiedon siirtymistä osa-alueelta ja osapuolelta toiselle ja lisää yhteisen ymmärryksen määrää. Tätä kautta kaikkien osapuolten toiminta- ja yhteistyökyky jatkossa muissakin hankkeissa paranee. Allianssin on todettu sopivan projekteihin, joissa kehitetään tai käyttöönotetaan uutta teknologiaa. Samoin on todettu, että mallia kannattaa käyttää, kun tilaaja tavoittelee koko alan kehittymistä. Allianssi sopii (suuriin) projekteihin, jotka sisältävät haasteita, joita on vaikea ennalta hallita. Koska neuvottelut allianssin perustamiseksi ovat suuri ponnistus, allianssimallia tyypillisesti käytetään vain suurissa hankkeissa. Pieniä hankkeita ja hoitoa ja ylläpitoa varten tulisi kehittää kevyempiä yhteistyömalleja tai soveltaa yhteistyösopimusta tietyn ryhmän kesken pitkällä aikavälillä useissa hankkeissa. Tarve yhteistoimintamuodoille hankinnoissa on todettu myös RAKLIn Hankintaklinikan raporteissa [11][12]. 4.2 Tuotannon prosessien hyvät esimerkit Saksalainen tutkimushanke ForBAU (www.forbau.de) [1] tutkii infrarakentamisen mallinnusta ja työmaan simulointia. Tutkimuksessa tutkijat ja infra-alan yritykset työskentelivät yhdessä neljässä alahankkeessa. Tavoitteena oli automatisoida laser-skannatun tai valokuvista tulkitun maastotiedon muuttamista 3D-malliksi, kehittää väylämallin ja siltamallin keskinäistä integraatiota ja parametrista päivittämistä,
24 (63) kehittää maanpinnan mallin, maaperämallin ja väylämallin yhdistämistä, kehittää massansiirtojen simulointia ja optimointia, parantaa työmaan suunnittelua ja työvaiheiden järjestystä prosessioptimoinnilla Siemens UGS NX 3D Building Model AutoDesk Civil 3D 3D Terrain Model AutoDesk Civil3D 3D Roadway Model Bridge 3D Subsoil Model SurPack 3D Excavation Pit Siemens UGS NX 3D Site Equipment EIS Kuva 8 ForBau-tutkimushankkeen visio virtuaalisesta työmaasta. (Kuva ForBauprojekti, Dr. Ing. Andre Borrmann, TU Munchen) Mallit tuotetaan olemassa olevilla kaupallisilla standardiohjelmistoilla (Civil 3D, NX, SurPack,..). Mallien yhdistämiseen kehitettiin hankkeessa integrointimoduuli (ForBAU Integrator, Kuva 9). Simulointeihin sovellettiin kaupallista tehdasprosessien simulointiin tarkoitettua ohjelmistoa. Tiedonsiirrossa hyödynnettiin LandXML, IFC-Bridge ja OKSTRA standardeja. Hankkeessa osallistuttiin IFC-Bridge ja IFC-Road -standardien kehittämiseen [1].
25 (63) TP2 Process simulation XML Volume and position of cut and fill areas 3D Terrain Model 3D Roadway Model 3D Subsoil Model LandXML OKSTRA Geotechnical Data ForBAU Integrator 3D Bridge Model PDM system Kuva 9 Kaavio ForBAU-projektissa muodostetusta kokonaisuudesta. (Kuva ForBau-projekti, Dr. Ing. Andre Borrmann, TU Munchen) 4.3 Tietomallipohjaiset prosessit ja liiketoiminta talonrakennuksessa Talonrakennusalalla tietomallintamisen kehittämisen painopisteenä on selvästi ollut rakennushanke ja sen prosessit. Mallien hyödyntäminen kiinteistöjen käytön, ylläpidon ja omistajan kiinteistöliiketoiminnan alueella on edelleen kehitysvaiheessa. Rakennussuunnitteluun on tarjolla hyviä mallinnusohjelmistoja sekä malliin kytkeytyviä muita ohjelmia, jotka tuottavat lisätietoa suunnitelmasta (esim. kustannukset, energiankulutus, sisäolosuhteiden toimivuus, palotekninen toimivuus, valaistus, ympäristövaikutukset). Myös eri alojen suunnitelmien/mallien yhdistämiseen ja tarkastamiseen on ohjelmia tarjolla. Uusimpana kehityksenä ovat ohjelmistojen tarjoamat ryhmätyö- ja yhteistyömahdollisuudet. Uusia yhteistoimintatapoja ja tietomalliin perustuvia prosesseja on harjoiteltu n. kymmenen vuoden ajan. 4.3.1 Päätöksentekoprosessin analysointi Talonrakennusalalla on tilaajan näkökulmaa ja intressiä tietomallien käyttöön jäsennetty analysoimalla tilaajan päätöksentekoprosessia rakennushankkeen aikana. VBE 2 -tutkimushankkeessa hahmoteltiin tilaajan yleinen päätöksentekoprosessi (numero 1, Kuva 10), jossa määriteltiin kussakin päätöksentekopisteessä: mistä asioista siinä päätetään ja mihin tietoihin päätös perustuu [4]. Nämä tiedot listattiin ja määriteltiin mistä tietomalleista (minkä suunnittelualan ja minkä valmiusasteen mallista) tai mallin analyysistä tieto on saatavissa. Kuva 11 on esimerkki taulukosta, johon on koottu
26 (63) investointipäätökseen liittyvät tiedot ja niiden lähteet. Tietomalleja edustavat kuvissa kyseisessä VBE 2-hankkeessa ideoidut rakennuksen tietomallien ja simulaatioiden/ analyysien symbolit. Myös Senaatin tietomallivaatimukset [9] perustuvat tähän ajatteluun ja sen jatkojalostamiseen (Kuva 10). Tärkeimmiksi hyödyntämiskohteiksi malleille määriteltiin määrälaskenta ja laajuuksien hallinta, energiasimulointi sekä havainnollistaminen. Mallit määriteltiin vaatimuksissa niin, että ne ovat käyttökelpoisia näihin käyttötarkoituksiin. 4 1 3 Julkaiseminen Laadunvarmistus 2 Mallien käyttötarkoitukset Kuva 10 Suunnittelutieto siirtyy nuolien suuntaan kohti tilaajan päätöksentekoa. Malleille asetettavat vaatimukset on johdettava käänteisessä järjestyksessä (1,2,3,4). (Kuva Senaatti-kiinteistöjen tietomallivaatimusten [3] julkaisuseminaarista) Tietomallivaatimuksissa määritellään myös mallien laadunvarmistusprosessi ([3] osa 6) ja mallien ja piirustusten julkaisuprosessi laadunvarmistusprosessi ([3] osa 1), jotka katsottiin tarpeellisiksi luotettavan tietomalliprosessin aikaansaamiseksi. Laadunvarmistuksella varmistetaan, että tuotetut mallit ovat vaatimuksen mukaisia. Mallit tarkastetaan määritellyllä tavalla paitsi suunnittelijan itsensä toimesta myös tilaajan toimesta. Julkaisuprosessi varmistaa, että tietomallit tuotetaan ennen piirustuksia ja piirustukset perustuvat laadunvarmistuksen läpäisseeseen julkaistuun malliin. Tietomallinnuksen käyttöönoton myötä Senaatti-kiinteistöt on tehnyt muutoksia myös omaan investointiprosessiinsa [9].