Tietopalvelun vaihtuminen voi näyttää organisaation ulkopuolelta tekniseltä päivitykseltä. Vanha palvelu suljetaan, uusi avataan ja käyttäjille toimitetaan uusi osoite. Käytännössä muutos voi ulottua järjestelmien lisäksi projektien aikatauluihin, toimittajasopimuksiin, ihmisten tehtäviin ja siihen, miten tietoa siirretään organisaatiosta toiseen.
Digiroadin uudistus on tästä ajankohtainen esimerkki. Kun tuttu tietopalvelu korvautuu uudella ja samalla muuttuvat tietomallit sekä rajapinnat, organisaation pitää selvittää, mitä muutos tarkoittaa sen omassa toiminnassa. Pelkkä uuden palvelun valmistumisen odottaminen ei vielä valmista käyttöönottoon.
Johtamisen näkökulmasta tärkein kysymys onkin tämä: kuka kokoaa muutoksen vaikutukset yhteen ja huolehtii siitä, että siirtymä tapahtuu hallitusti? Palveluntarjoaja vastaa omasta uudistuksestaan. Tietoa hyödyntävien organisaatioiden pitää puolestaan johtaa muutos omiin järjestelmiinsä, projekteihinsa ja toimintatapoihinsa.
Mitä Digiroadissa muuttuu?
Digiroad siirtyi Väylävirastolta Fintrafficin vastuulle vuoden 2026 alussa. Fintrafficin tiedotteen mukaan tietojen päivittäminen nykyiseen palveluun päättyi 31.8.2026 ja palvelu sulkeutuu syyskuun lopussa. Tämän jälkeen alkaa vähintään loppuvuoden kestävä käyttökatko, jonka aikana uusia aineistojulkaisuja ei tehdä.
Korvaava Digitraffic Road Network otetaan vaiheittain käyttöön vuonna 2027. Uudistukseen kuuluvat tietomallit, sovellukset sekä tietojen toimittamisen ja julkaisemisen rajapinnat. Ensimmäisen uuden tietomallin mukaisen aineiston julkaiseminen on tavoitteena keväällä 2027. Ajantasainen tilanne löytyy Fintrafficin muutostiedotteesta.
Organisaation kannalta kyseessä on siis siirtymä, jossa vanhan palvelun päättyminen ja uuden käyttöönotto eivät tapahdu samalla hetkellä. Tämä pitää ottaa huomioon sekä käynnissä olevissa hankkeissa että tulevien töiden valmistelussa. Uuden palvelun tavoiteaikataulu on suunnittelun lähtötieto, jonka rinnalle tarvitaan oma toimintasuunnitelma välivaihetta varten.
Ensimmäinen selvitys: missä olemme riippuvaisia nykyisestä palvelusta?
Muutoksen laajuutta on vaikea arvioida, jos nykyistä käyttöä ei tunneta. Digiroad voi näkyä yhdessä tiimissä ladattavana aineistona, toisessa ohjelmiston taustalla ja kolmannessa ulkopuolisen palveluntuottajan työn osana. Kaikki riippuvuudet eivät löydy järjestelmäluettelosta tai yhden henkilön muistista.
Aloittaisin siksi nykytilan kartoituksesta. Missä projekteissa ja palveluissa tietoa käytetään, miten se saadaan käyttöön ja kuka vastaa käytännön työstä? Samalla pitää selvittää, tapahtuuko tiedonsiirto käsin, organisaation omalla integraatiolla vai ohjelmistotoimittajan toteuttamana.
Tässä vaiheessa johdon tehtävä on saada oikeat ihmiset saman pöydän ääreen. Tiedon käyttäjä tuntee arjen tarpeen, tekninen asiantuntija järjestelmäriippuvuudet ja projektipäällikkö hankkeen aikataulun. Hankinta tai sopimusvastaava puolestaan selvittää, mitä muutostöistä on sovittu toimittajan kanssa. Näistä muodostuu yhteinen kuva siitä, kuinka suuresta muutoksesta omassa organisaatiossa on kyse.
Vanhan ja uuden vastaavuudet pitää kartoittaa
Yksi siirtymän keskeisistä tehtävistä on vanhan ja uuden palvelun välinen mappaus eli vastaavuuksien kartoitus. Sillä tarkoitan tässä sekä tietojen että toimintatapojen vertailua. Mitä nykyisin käytämme, mistä vastaava tieto jatkossa saadaan ja mikä muuttuu sen käsittelyssä?
Kartoituksen pitää ulottua pidemmälle kuin kenttien nimien vertaamiseen. Selvitettäviä asioita voivat olla esimerkiksi tietojen merkitykset, tunnisteet, luokitukset, jakelutavat, käyttöoikeudet ja päivityskäytännöt. Näiden vastaavuutta ei pidä olettaa etukäteen, vaan teknisten ja toimialan asiantuntijoiden pitää selvittää se uuden palvelun dokumentaation perusteella.
Projektin johtajan ei tarvitse itse ratkaista tietomallien yksityiskohtia. Hänen pitää kuitenkin huolehtia siitä, että selvityksellä on tekijät, aikataulu ja selkeä lopputulos. Tarvitaan näkyvä ero sen välillä, mikä voidaan säilyttää, mikä vaatii muutoksen ja mistä ei vielä ole riittävästi tietoa.
Kaikkea ei välttämättä pystytä ratkaisemaan heti. Avoimet kysymykset kannattaa koota yhteiseen listaan ja nimetä niille vastuuhenkilöt. Muuten sama epävarmuus kiertää palavereissa viikosta toiseen ilman, että kukaan vastaa sen selvittämisestä.
Käynnissä oleva projekti ei siirry uuteen palveluun yhdellä päätöksellä
Palvelun vaihtuminen ja projektin siirtyminen uuden palvelun käyttöön ovat kaksi eri asiaa. Hankkeessa voi olla jo tehtyjä analyysejä, sovittuja toimituksia, käytössä olevia aineistoja ja järjestelmiä, joiden toiminta perustuu nykyiseen ratkaisuun. Niiden muuttaminen kesken työn voi vaikuttaa aikatauluun, kustannuksiin ja eri osapuolten tehtäviin.
Siksi käynnissä olevat hankkeet kannattaa tarkastella erikseen. Lähellä valmistumista olevan projektin tilanne voi olla erilainen kuin monivuotisen hankkeen tai vasta käynnistyvän työn. Siirtymistapaa ei kannata päättää kaikille samalla oletuksella ennen kuin vaikutukset on selvitetty.
Johdettavia kysymyksiä ovat esimerkiksi siirtymisen ajankohta, tarvittavat muutostyöt ja päätösvalta. Kuka arvioi vaihtoehdot, kuka hyväksyy etenemistavan ja miten siitä sovitaan tilaajan sekä muiden osapuolten kanssa? Jos päätös vaikuttaa sovittuun toimitukseen, asia pitää käsitellä myös projektin muutoksenhallinnassa.
Välivaihe tarvitsee oman toimintamallin
Käyttökatko tekee näkyväksi vaiheen, joka jää järjestelmäuudistuksissa helposti liian vähälle huomiolle. Organisaation arki jatkuu, vaikka korvaava palvelu ei olisi vielä kokonaan käytettävissä. Töitä pitää suunnitella, sopimuksia valmistella ja asiakkaille kertoa, millä edellytyksillä tehtäviä voidaan toteuttaa.
Välivaiheen suunnitelmassa pitäisi kuvata käytettävissä olevat palvelut ja aineistot sekä ne tarpeet, joihin ei vielä ole vahvistettua ratkaisua. Asiantuntijat arvioivat vaihtoehtojen soveltuvuuden. Projektin johto kokoaa niiden vaikutukset aikatauluun, resursointiin ja toimituksiin.
Myös väliaikaisille toimintatavoille tarvitaan omistaja ja päättymisehto. Muuten kiireessä sovittu menettely voi jäädä pysyväksi käytännöksi uuden palvelun rinnalle. Uudistus on vasta osittain valmis, jos uusi ratkaisu on käytössä mutta vanhat kiertotavat jatkavat elämäänsä.
Vastuut, toimittajat ja kustannukset pitää saada näkyviin
Siirtymässä on yleensä useita osapuolia, joista kukin vastaa vain osasta kokonaisuutta. Kansallinen palveluntarjoaja kehittää palvelua, ohjelmistotoimittaja muuttaa omaa tuotettaan ja tiedon käyttäjä valmistautuu uuteen toimintatapaan. Hankkeen tilaaja ja palveluntuottaja joutuvat vielä sopimaan, miten nämä muutokset huomioidaan yhteisessä työssä.
Ongelma syntyy helposti osapuolten väliin. Yksi odottaa rajapintakuvausta, toinen tilausta muutostyölle ja kolmas tietoa siitä, milloin käyttäjiä pitäisi kouluttaa. Kaikki voivat hoitaa omaa tehtäväänsä, vaikka kokonaisuuden eteneminen pysähtyy.
Siksi vastuiden lisäksi pitää selvittää riippuvuudet. Mitä tietoa tai päätöstä kukin tarvitsee ennen kuin voi edetä? Samalla kannattaa tarkistaa, mitkä muutokset sisältyvät nykyisiin sopimuksiin ja mistä syntyy lisätyötä.
Budjettiin pitää varata myös oman henkilöstön aikaa. Nykytilan selvittäminen, vastaavuuksien kartoitus, testaus, ohjeiden päivittäminen ja käyttäjien tukeminen eivät tapahdu ilman työpanosta. Jos nämä tehtävät jätetään muun työn ohessa hoidettaviksi, siirtymän aikataulu perustuu helposti kapasiteettiin, jota ei todellisuudessa ole.
Käyttöönoton valmius pitää osoittaa käytännössä
Tekninen yhteys uuteen palveluun on yksi käyttöönoton edellytys. Sen lisäksi pitää varmistaa, että organisaation tarvitsema työnkulku toimii ja ihmiset tietävät, miten toimia muutoksen jälkeen. Käyttöoikeudet, tukikanavat, vastuut ja päivitetyt ohjeet kuuluvat samaan kokonaisuuteen.
Rajattu pilotti voi auttaa selvittämään, mitä käyttöönotto todellisuudessa vaatii. Siihen kannattaa valita tunnistettava työtehtävä ja sopia etukäteen, mitä kokeilulla halutaan selvittää. Teknisten ja toimialan asiantuntijoiden vastuulla on määritellä oman alueensa hyväksymiskriteerit.
Projektin johto puolestaan varmistaa, että testauksen havainnot johtavat päätöksiin. Mitkä puutteet estävät käyttöönoton, mitkä voidaan korjata myöhemmin ja kuka hyväksyy jäljelle jäävät rajoitukset? Kokeilu auttaa vasta silloin, kun sen tulosten perusteella muutetaan suunnitelmaa tai vahvistetaan eteneminen.
Tässä tarvitaan muutoksen omistajaa
Tällainen siirtymä on luonteva esimerkki tehtävästä, jossa väliaikaisesta käyttöönotto- tai muutosjohtajasta voi olla hyötyä. Organisaatiossa voi olla kaikki tarvittava asiantuntemus, mutta kenelläkään ei ole aikaa johtaa kokonaisuutta oman työnsä rinnalla. Silloin ongelma on vastuun ja työajan järjestämisessä.
Interim-johtajan tehtävä olisi koota tilannekuva, vaiheistaa työ ja huolehtia päätösten etenemisestä. Hän yhdistäisi asiantuntijoiden selvitykset projektien tarpeisiin, toimittajien aikatauluihin ja johdon päätöksentekoon. Tekninen ja suunnittelullinen arviointi säilyisivät niitä tekevien asiantuntijoiden vastuulla.
Digiroadin uudistuksessa kiinnostavin johtamiskysymys on lopulta hyvin käytännöllinen: tietääkö organisaatio, miten se siirtyy nykyisestä toimintatavasta uuteen? Jos vastaus on vielä epäselvä, ensimmäinen tehtävä on nimetä muutokselle omistaja ja käynnistää tarvittavat selvitykset. Niitä voi tehdä jo ennen kuin uuden palvelun kaikki yksityiskohdat ovat valmiina.
Seuraavassa kirjoituksessa tarkastelen yhteistä terminologiaa. Kun tietoja ja toimintatapoja verrataan, pitää ensin ymmärtää, tarkoittavatko eri osapuolet samoilla sanoilla samaa asiaa. Se on myös onnistuneen vastaavuuskartoituksen ja käyttöönoton perusta.
Filed under
