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.

Kennon käyttöönotot kehityskumppaneillemme ovat käynnistymässä. Tai tarkemmin sanoen ”Kennoon liittymiset”, kuten tapanamme on puhua. On siis ajankohtaista pohtia näissä projekteissa onnistumisen edellytyksiä. Teen sitä tällä erää kolmen blogin sarjassa, josta tämä on ensimmäinen.

Me pandialaiset olemme onneksemme saaneet jo toista vuosikymmentä seurata sivusta toiminnanohjausjärjestelmien hankinta- ja käyttöönottoprojekteja ja oppia niistä. Kennon kehittämisen aikana olemme lisäksi nähneet useita kilpailutuksia, joihin Pandiaakin on kovasti toivottu osallistumaan. Emme ole kuitenkaan katsoneet aiheelliseksi niihin osallistua, sillä olemme nähneet niissä enemmän uhkia kuin mahdollisuuksia.

Pandian reseptillä maksimoidaan toiminnanohjaushankkeessa onnistumisen todennäköisyys.

Olemme Pandialla miettineet pitkään, miten Kennoon liittymisestä voitaisiin tehdä paitsi kehityskumppaneillemme myös uusille asiakkaillemme mahdollisimman sujuvaa. Tämä pohdinta on sittemmin tiivistynyt kolmeen periaatteeseen, joita avaan alla tarkemmin. Kutsumme näitä periaatteita ”Pandian reseptiksi”, jonka tarkoituksena on maksimoida onnistumisen todennäköisyys.

Pandian reseptin periaate 1: Yksi Kenno, joka taipuu moneen

Kiinteistöalalla ohjelmistojen ostaminen, myyminen, kehittäminen ja jopa ns. ”valmisohjelmistojen” käyttöönottaminen on pitkään perustunut asiakaskohtaisen räätälöinnin periaatteeseen.

En lähde tässä tarkemmin avaamaan miksi näin on ja mitä kaikkea tällä laajalla termillä tarkoitan. Taustalla on monia loogisia syitä ja jos näin ei olisi ollut, olisi moni hyvä ohjelmisto jäänyt alalle kokonaan kehittämättä, mukaan lukien Pandiankin tuotteet. Tällä pienellä toimialalla läheinen asiakasyhteistyö on aivan olennainen lähde uusille innovaatioille. Pitkässä juoksussa tähän tuudittautuminen voi kuitenkin kääntyä myös itseään vastaan.

Aloittaessani itse tällä alalla ihmettelin pitkään miten asiakaspalaverit voivatkin aina alkaa samalla teemalla, eli toiminnanohjaukseen liittyvien ongelmien päivittelyllä. Hyviäkin kokemuksia on toki tullut vastaan, mutta nyt 15 vuotta alalla toimineena uskallan sanoa, että huonoja kokemuksia mahtuu sekaan huomattavasti enemmän.

Uudet innovaatiot alun perin mahdollistaneesta asiakaskohtaiseen räätälöintiin pohjautuvasta ajattelutavasta on syntynyt pullonkaula yritysten liiketoiminnan kehittämiseen.

Oma näkemykseni on, että asiakaskohtaisesta räätälöinnistä lähtevä ajattelutapa on lopulta juurisyy järjestelmien kehittämisen, käyttöönottamisen ja ylläpitämisen haasteille, jotka ovat alalla ilmeisiä ja systeemisiä. Esimerkiksi Kenno kumppaneidemme osalta haasteet ovat niin syvällisiä, että ohjelmistot on lopulta todettu liiketoiminnan kehittämisen pullonkauloiksi. Räätälöinnin käsitteeseen luen tässä perinteisen ohjelmistoräätälöinnin ohella laajan konfiguroitavuuden, parametroitavuuden ja muut vastaavat ”teknistä mukautettavuutta” tarkoittavat käsitteet.

Kun ajatellaan ohjelmiston koodia, niin mitä yksinkertaisempaa se on ja etenkin, mitä vähemmän siinä on asiakaskohtaista variaatiota, sitä helpompi ohjelmistoa on ylläpitää ja jatkokehittää. Sitä todennäköisemmin ohjelmisto siis oikeasti toimii arjessa, sen dataan voidaan luottaa, käyttäjät saavat asiantuntevaa ja ajantasaista tukea ja niin edelleen.

Yksi Kenno joka taipuu moneen -periaatteella tarkoitan, että Kennoa kehittäessämme luomme koko toimialaa palvelevia ”parhaita käytäntöjä” sen sijaan, että kehittäisimme ratkaisuja yhden asiakkaan erityistarpeisiin. Toimintatapa on osoittautunut erittäin toimivaksi kun useat Kenno kumppanit ovat päässeet oppimaan toisiltaan, vertailemaan ja parantamaan toimintatapojaan ja vasta tämän jälkeen ollaan toteutettu ohjelmisto näitä toimintatapoja tukemaan.

Yksinkertaisuuteen ja alan parhaisiin käytäntöihiin perustuvat ohjelmistot toimivat pitkässä juoksussa parhaiten – työkalut toimivat tällöin arjessa luotettavasti, tukipalvelut pelaa, ja teknologia pysyy jatkokehitettävänä

Kantava ajatus kehityksessä on lisäksi periaatteen loppuosa ”taipuu moneen”. Tarkoitamme tällä, että asiakaskohtaistenkaan toimintatapojen tukeminen ei välttämättä edellytä ohjelmistoräätälöintiä, vaan ohjelmistosta voidaan alun alkaen tehdä joustava – moneen toimintatapaan taipuva. Helppoa tämä ei ole, mutta juuri siksi Kennon kehittämisessä noin 50% kaikesta työajasta kuuluukin huolelliseen tekniseen kokonaissuunnitteluun.

Näkyvimpiä käytännön esimerkkejä ”yhden Kennon” periaatteesta lienee kiinteistöhierarkia ja kiinteistöjen sekä osapuolien perustiedot, jotka on kaikille samat helpottaen mm. datan laadun varmistamista ja raportointia sekä rajapinnat ja viranomaisyhteydet, jotka ovat kaikille samat. Etenkin ensin mainittu saattaa edellyttää monelta ajattelutavan muutosta, mutta on pitkässä juoksussa taatusti vaivan arvoista. Toisena mainittu puolestaan helpottaa olennaisesti käyttöönottotyötä.

Pandian resepti muuttaa fundamentaalisti paitsi ohjelmistokehitysmenetelmät myös tavat, joilla järjestelmiä hankitaan.

Kennosta kiinnostuneiden yritysten ja päättäjien kannattaa huomata, että Yksi Kenno joka taipuu moneen -periaate muuttaa fundamentaalisti paitsi tavat, joilla ohjelmistoja kehitetään myös tavat, joilla ohjelmistoja kilpailutetaan ja hankitaan. Tyypillisesti kilpailutusdokumentaatioissa ja vaatimuslistoissa korostuu päällimmäisenä nimenomaan erityistarpeisiin räätälöityvyys ja muokattavuus, ikään kuin tämä olisi jokin perusarvo ja onnistumisen tae. Ja yhtä tyypillisesti toimittajat keksivät mitä villeimpiäkin ratkaisuja pystyäkseen näihin erityistarpeisiin ohjelmistonsa pitkän juoksun ylläpidettävyyden kustannuksella venyttämään. Toimialan on opittava pois tästä ajattelusta, sillä se on monesti juurisyy projektien työläydelle ja myöhemmin esiin tuleville käytännön haasteille.

Lue myös blogisarjan seuraava osa, jossa käsitellään Pandian reseptin toista periaatetta ”Kennoa ei oteta käyttöön vaan siihen liitytään”. Tulen tässä jatkamaan myös edeltävän teeman ajatuksia kertoen mm. miten ”Yhden Kennon periaatteen” ei suinkaan ole tarkoitus sulkea pois asiakkaiden kanssa yhteistyössä tehtävää järjestelmän jatkokehitystä.