Tämä blogi on jatkoa blogisarjalle Pandian reseptistä, jonka tarkoituksena on maksimoida onnistumisen todennäköisyydet toiminnanohjaushankkeessa. Suosittelen lukemaan ensin blogini reseptin ensimmäisestä periaatteesta ”Yksi Kenno, joka taipuu moneen”. Seuraavassa pohdin tarkemmin toiminnanohjausjärjestelmän käyttöönottoprojektissa onnistumisen edellytyksiä ja esittelen Pandian reseptin toisen periaatteen: Kennoa ei oteta käyttöön, vaan siihen liitytään.

Toiminnanohjausjärjestelmän käyttöönottaminen mielletään usein valtavaksi projektiksi, jonka suuruus itsessään nähdään jo kynnyksenä järjestelmävaihdoksille. Kennoon liittymisen periaatteen tavoitteena on tehdä käytön aloittamisesta ja siirtymästä niin helppoa kuin se suinkin on mahdollista, mutta kuitenkaan käyttämättä oikopolkuja, jotka kostautuvat myöhemmin.

Kennoon liittymisen tavoitteena on tehdä käyttöönottoprojektista mahdollisimman sujuva ja järjestelmän vaihtamisen kynnykset mataliksi.

Kennoon liittyminen terminä juontaa juurensa siitä, että Kenno on ns. ”multitenantti” järjestelmä. On olemassa vain yksi Kenno ja se otetaan käyttöön vain yhden kerran. Tämän jälkeen muut asiakkaat liittyvät saman Kennon käyttäjiksi. Suurin osa moderneista ohjelmistoista toimii nykyään tällä periaatteella, sillä se tarjoaa monia lyömättömiä etuja. Kennon tapauksessa esimerkiksi:

• Kiinteistöjen ja osapuolien perustiedot ovat kaikille samat ja ne syötetään Kennoon vain kerran. Myöhemmin esimerkiksi kiinteistön vaihtaessa omistajaa, siirtyy kiinteistö sujuvasti Kennon sisällä käyttäjäorganisaatiolta toiselle.
• Kun samaa palveluntuottajaa hyödyntää uusi Kennon käyttäjä, on data jo valmiina Kennossa. Palveluntuottajan näkökulmasta työnteko on myös helpompaa, kun kirjautua pitää vain yhteen paikkaan. Asiakkaita todennäköisesti helpottaa lisäksi se, että Pandia vastaa palveluntuottajille tarjottavasta tuesta keskitetysti vs jokainen asiakas erikseen.
• Asiakaskohtaiset tiedot ovat asia erikseen ja tietoturvasta sekä -suojasta huolehditaan luonnollisesti asianmukaisesti.
• Integraatioiden toteuttaminen helpottuu, kun rajapinnat ovat kaikille samat. Keskeiset integraatiot tarvitsee toteuttaa vain kerran (esim. Vastuu Group, Kela jne).

Multitenanttius helpottaa järjestelmän ylläpitoa ja datan laatua, kun jopa satojen asiakkaiden ei tarvitse kunkin erikseen ylläpitää samaa perustietoutta. Lisäksi koko tekninen infrastruktuuri palvelimineen, yhteyksineen ja rajapintoineen ovat kaikille samat. Ne siis otetaan käyttöön vain kerran, jonka jälkeen uudet asiakkaat todella ”liittyvät” olemassa olevan Kennon käyttäjiksi. Yksinkertaisimmillaan liittyminen tarkoittaa käyttäjätunnuksen avaamista, jonka jälkeen Kennoa voidaan käyttää. Kenno on myös suunniteltu kevyeksi ja yksinkertaiseksi, jolloin käytön aloittaminen ei välttämättä vaadi massiivista kouluttautumista.

Kenno otetaan käyttöön vain kerran ja uudet asiakkaat liittyvät saman Kennon käyttäjiksi.

Pelkästään näillä eväillä ainakaan suuremmat asiakkaat tuskin pystyvät kuitenkaan aloittamaan vielä tuotantokäyttöä. Perinteisesti käyttöönottoprojekteissa ainakin datan siirto ja ohjelmiston mukauttaminen asiakkaan vaatimuksia vastaavaksi ovat suuressa roolissa, joten pureudun näihin seuraavaksi hieman tarkemmin. Näiden ohella käyttöönottoprojekteissa toteutetaan tyypillisesti integraatioita ja tietysti kouluttaudutaan, mutta näihin aiheisiin en paneudu tässä blogissa ylempänä jo mainittua tarkemmin.

Kennoon liittyminen ja sujuvat datasiirrot

Datan siirtoon liittyvää työtä on vaikea paeta ja se on väistämättä edessä myös Kennoon liittyjillä. Perinteisesti tässä työssä on kuitenkin kyse paljolti ihan muusta kuin datan ”siirrosta”. Jos datalla on liiketoiminnassa vain vähän käyttöä, alkaa se helposti monessa järjestelmässä ”mätänemään” ja on siksi usein puutteellista, sisältää virheitä ja sijaitsee hajanaisissa paikoissa. Järjestelmävaihdostilanteet taas tyypillisesti viimeistään pakottavat tekemään datan hallinnan ryhtiliikkeen ja siksi tämä nähtäneenkin herkästi olennaisena osana käyttöönottoprojektia.

On kuitenkin mielenkiintoista, että samaan aikaan kun datan hallinnointi ja kuntoon laittaminen nähdään herkästi osana järjestelmävaihdosprojektia, ollaan kiinteistöalalla vuosikymmenet kipuiltu datan laadun kanssa monissa aivan muissa asiayhteyksissä, esimerkiksi johdon raportoinnissa. Meillä Pandialla on tästä jonkin verran kokemusta, joten rohkenen tältä pohjalta hieman haastaa vallitsevaa ajattelua toivon mukaan liialliseen idealismiin sortumatta.

Siis, mitäpä jos:

1. Unohdetaan hetkeksi mahdolliset järjestelmävaihdokset, ja hoidetaankin data kuntoon nyt heti sitoutuen samalla pitämään ainakin kriittiset perustiedot jatkuvasti kunnossa?
2. Aletaan ajattelemaan dataa samanlaisena arvokkaana omaisuutena kuin kiinteistöt ja suunnittelemaan datalle vastaavasti huolto- ja PTS-toimia? Datakin tarvitsee silloin tällöin nuohousta, siivousta ja toisinaan peruskorjauksia.
3. Varaudutaan samalla mahdollisiin järjestelmävaihdoksiin varmistamalla säännöllisesti, että olennainen data on siirettävissä kohtuullisella vaivalla haluttuihin formaatteihin (esim. Kennon tietomalli, mutta yhtä lailla mikä tahansa muu hyödyllinen formaatti)?

Mitä jos datasiirto järjestelmävaihdoksen yhteydessä ei olisikaan ”mörkö”?

Tarvittavan datatyön määrän sanelee aina lähtötilanne. Valtaosa työstä voidaan ja kannattaa tehdä etukäteen ja siitä todennäköisesti hyödytään muillakin tavoin kuin järjestelmävaihdosten yhteydessä. Kun data laitetaan kuntoon erillisprojektina yksinkertaistuu samalla mahdollisiin myöhempiin järjestelmähankintoihin liittyvä hankintaprosessi.

Kennoon liittyminen ja asiakaskohtaisiin vaatimuksiin mukautuminen

Toinen suuritöinen osa-alue käyttöönottoprojekteissa on niin kutsuttujen ”valmisohjelmistojen” mukauttaminen asiakaskohtaisiin vaatimuksiin. Erityisesti julkisiin kilpailutusmateriaaleihin tutustuttaessa tulee törmättyä usein tältä osin ristiriitaiseen ajatteluun.

Yhtäältä etsitään ”valmisohjelmistoa”, jota ei tarvitse räätälöidä ja toisaalta vaaditaan ”täydellistä konfiguroitavuutta ja mukautuvuutta” lukuisiin erityistarpeisiin. Väitän, että tällainen yhdistelmä ei ole reaalimaailmassa mahdollinen, joskin toimialamme on jotenkin oppinut elämään tämän ristiriidan kanssa (mielestäni systeemisesti epäterveellä tavalla). Tässä kohtaa kannattaa viimeistään lukea ensimmäinen blogini Pandian reseptin periaatteesta ”Yksi Kenno joka taipuu moneen”, jossa pohjustan asiaa laajemmin.

Lähtökohdaksi on valittava joko valmisohjelmistot ja alan parhaat käytännöt tai ohjelmistoräätälöinti ja omat erityistarpeet

Mielestäni sekä toimittajien että ostajien olisi aika oppia suosimaan selkeästi jompaakumpaa ajattelua, eli joko a) vakiointia ja parhaita käytäntöjä tai b) räätälöintiä ja omia erityistarpeita. Rusinoita on vaikea poimia pullasta ja helposti tätä yrittäessä päätyykin haalimaan nimenomaan kummankin vaihtoehdon haittapuolet. Tämän vuoksi myös käyttöönottoprojektit paisuvat ja monimutkaistuvat ja alkavat lopulta muistuttaa enemmänkin ohjelmistokehitysprojekteja kuin valmisohjelmiston käyttöönottoa.

Kennoon liittyminen tarkoittaa tältä osin, että Kenno otetaan lähtökohtaisesti käyttöön ”sellaisena kuin se on”, jolloin parhaimmassa tapauksessa valtaosa tyypillisen käyttöönottoprojektin työmäärästä poistuu. Olemme nähneet paljon vaivaa sen eteen, että Kenno taipuisi mahdollisimman moneen erilaiseen toimintatapaan, mutta minimaalisella asiakaskohtaisella räätälöinnillä tai konfiguroinnilla. Olemme myös harkitusti päättäneet, että jokaisen nippelin ja nappelin paikkaa, väriä, toiminnallisuutta jne ei ole mahdollista asiakaskohtaisesti konfiguroida. Tällaisen ”teknisen mukauttamisen” sijaan pyrimme luomaan ja levittämään alan parhaita käytäntöjä sekä löytämään yhdessä suunnittelemisen ja kouluttautumisen keinoin kullekin asiakkaalle ja käyttäjälle sopivimmat tavat käyttää Kennoa (sellaisena kuin se on).

Yhden Kennon ja siihen liittymisen periaatteet eivät sulje pois jatkokehittämismahdollisuuksia asiakkaiden kanssa.

Korjatkaamme vielä mahdollinen väärinymmärrys. Tarkoituksenamme ei suinkaan ole sulkea pois Kennon jatkokehittämismahdollisuuksia asiakkaiden kanssa. Päinvastoin, tällä logiikallahan Kennoa jatkuvasti kehitetään. Tarkoituksenamme on pikemminkin erottaa kaksi hyvin erilaista asiaa toisistaan: 1. Kennoon liittyminen ja 2. Mahdollinen kehitysyhteistyö. Jälkimmäisen osalta on tärkeää, että kaikki osapuolet sitoutuvat toimialan parhaiden käytäntöjen kehittämisen periaatteeseen. Erityisesti hankintavaiheessa kannattaa pohtia tätä erottelua tarkasti. Konkreettisesti: Kennon perusperiaatteiden ja asiakkaan prosessien ja käyttötapausten yhteensopivuus olisi hyvä tavalla tai toisella varmistaa ennen esimerkiksi julkista avoimen menettelyn kilpailutusta. Muussa tapauksessa on jotakuinkin varmaa, että kilpailutukseen päätyy (todennäköisesti turhia) vaatimuksia, jotka saattavat estää tarjouksen antamisen.

Lue myös blogisarjan seuraava osa, jossa käsitellään Pandian reseptin kolmatta periaatetta ”Yhdessä suunnittelu on avain onnistumiseen”. Tulen tässä jatkamaan edeltävääkin käyttöönottopohdintaa erityisesti julkisten hankintojen näkökulmasta.