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ä.