Yrityksen tehtävä ei ole kumartaa järjestelmää

Tämä tuntuu yksinkertaiselta ajatukselta, mutta silti edelleen käytössä on liian monia IT-järjestelmiä, jotka eivät taivu mihinkään.

Monoliittijärjestelmän yksi keskeisimpiä ongelmia on se, että järjestelmä määrää, miten työtä täytyy tehdä.

Vikaan mennään jo siinä vaiheessa, jos yritykseen tai organisaatioon tuodaan uusi järjestelmä, joka rusentaa vanhat, toimivat ja ketterät prosessit. Näitäkin on nähty.

Silti nykyään yleisempi ongelma on se, että organisaatio haluaisi kehittää prosessejaan, mutta järjestelmä ei anna. Asiakkaat, työntekijät tai johto haluaisi kokeilla jotain uutta, muuttaa jotain toimintamallia, testata uutta palvelukonseptia tai esimerkiksi ottaa käyttöön uuden palvelukanavan. Mutta ei pysty, koska järjestelmä ei siihen taivu.

Aikaa kahden vuoden hinkkaamiseen ei ole

Usein monoliittijärjestelmä on niin iso, kankea ja monimutkainen kokonaisuus, että jos jotain sen osaa halutaan kehittää, se kestää kauan. Ja jos koko järjestelmä kaikkinensa halutaan uudistaa, niin siinä vasta kauan meneekin. Aikamme ei salli odottaa, että uutta järjestelmää tai sen osaa hinkataan puoli vuotta, saati kaksi vuotta ennen kuin se on valmis.

Kahden vuoden päästä liiketoiminta voi olla jotain ihan muuta – maailma muuttuu, tarve menee ohi tai kilpailija teki sen jo. Pahinta on se, että järjestelmän kehitys laahaa koko ajan käyttäjien tarpeiden perässä. Pitäisi olla mahdollista sopeuttaa järjestelmää muuttuviin prosesseihin nopeasti. Testata nopeammin, korjata nopeammin, kehittää nopeammin.

Ketterä kehitys reagoi muutoksiin

Tällä hetkellä puhutaan kaikkialla koko ajan ketterästä kehittämisestä ja myös ketterästä liiketoiminnasta. Jokapäiväisessä puheessa vilisee MVPtä, agilea, fail fastia, scrumia, POCia, leania, sprinttiä, safea ja muita ketterän ajan toimintamalleja. Mitä se ketteryys kuitenkin ihan oikeasti on?

Se on sitä, että kun tulee jokin uusi idea tai tarve, se saadaan käytännön testiin päivissä, viikoissa tai korkeintaan kuukausissa. Ensimmäinen versio, jolla asiaa testataan, on rujo ja suorastaan buginen. Ensimmäisen version tehtävä on kerätä mahdollisimman nopeasti tietoa, onko tässä ideassa mitään perää ja mihin suuntaan tätä täytyy kehittää. ”Jos julkaisun hetkellä ei yhtään hävetä, on myöhässä.” Tuon ajatuksen kuulin muutama vuosi sitten Tampere Goes Agile -tapahtumassa, eikä se aivan väärin liene.

Ei tämä tietenkään sitä tarkoita, että asioita pitäisi tehdä hutiloiden ja jättää järjestelmiin reikiä ja repsottavia reunoja. Vaan se tarkoittaa sitä, että asioita pitää rakentaa, korjata ja muuttaa pala kerrallaan. Tästä syystä monoliitit puretaan ja siirrytään polyliitteihin.