Helsingin palkanmaksujärjestelmän hankinta lienee Suomen lähihistorian pahin katastrofi palkanmaksussa. Kymmeniä tuhansia palkkoja on maksettu väärin ja edelleen palkkavirheitä korjataan vajaat 2000 joka viikko – kun uusia syntyy lähes saman verran. Tämän mittaluokan virheitä ei saisi tapahtua.
On tärkeä tunnustaa virheet, kuten on tehty. Mutta vähintään yhtä tärkeä on tunnistaa virheet – ja oppia niistä.
Alkuperäinen virhe on 40 vuotta vanha järjestelmä. Näistä vuosista vähintään 20 on virhe – järjestelmä olisi pitänyt uusia aikaa sitten.
Toinen selvä virhe on käyttöönoton virhe. 36 000 työntekijän palkanmaksu siirrettiin kerralla. Ja kun se ei onnistunut, virheiden määrä oli liian suuri että sitä olisi voitu hallita.
Olen itse ollut yli 10 000 palkansaajan organisaatiossa suunnittelemassa palkanmaksuun vaikuttavan järjestelmien muutoksia. Silloin oli lähtökohta, että edes 1000 palkansaajan siirtoa uuteen järjestelmään tai prosessiin ei tehty kerralla, vaan simulaatioiden jälkeen ensin siirrettiin noin 100 työntekijän osuus. Jos sadan palkan kanssa tulee ongelmia, ne voidaan tarvittaessa ratkaista vaikka käsin – toisin kuin 36 000 palkkaa. Tämä on normaalia kriittisten järjestelmien muutoksen contingency planningia – suomeksi varautumissuunnittelua.
Kysyin valtuustossa, mitä tästä katastrofista on opittu, miten vältetään samat virheet jatkossa? Kaupungilla on kymmeniä viime vuostuhannella käyttöön otettuja järjestelmiä, joten tätä oppia todella tarvitaan!
Kansliapäällikkö viittasi vastauksessaan budjetteihin, jotka eivät riitä korjauksiin, rahat eivät riitä. Siksi otetaan ”teknistä velkaa” eli ei korjata ongelmia heti.
Tämä on huono perustelu. Olen työskennellyt startupeissa ja niiden kanssa. Siinä maailmassa on normaalia julkaista keskeneräinen järjestelmä ja toivoa että ehditään korjaamaan ongelmat ennen kun ”tekninen velka” räjähtää käsiin. Tässä on järkeä startupeissa, joissa rahaa ei kerta kaikkiaan ole ja on välttämätöntä saada nopeasti käyttäjiä, jotta olisi mahdollisuus saada kerättyä rahaa. Jos rahaa on kassassa vain 6 kuukaudeksi, ei sen kauemmas tulevaisuuteen kannata paljon murehtia.
Mutta kaupungin tilanne ei ole tämä. Kaupunki on hyvin pitkällä tähtäimellä toimiva organisaatio jonka prioriteetti on palveluiden vakaus. Ja pitkällä tähtäimellä tekninen velka tulee keskimäärin kalliimmaksi kuin sen korjaaminen – kuten tässä tapauksessa päästiin näkemään!
Siksi kaupungin kannattaa suunnitella tietojärjestelmiään vuosia tulevaisuuteen katsoen. Jokaiselle järjestelmälle täytyy olla arvioitu elinkaari ja korvata järjestelmiä systeemaattisesti ja riittävästi resursoidusti. Jokaisen järjestelmän korvaussuunnitelmaa pitää miettiä jo hankinnan yhteydessä – ja ihan viimeistään kaikille 20 vuotta vanhoille järjestelmille.
Palkanmaksujärjestelmäprojektin ongelmista tullaan teettämään ulkopuolinen selvitys. Toivon todella, että selvityksessä päästään tekemään kattava juurisyyanalyysi, jotta kaikki mahdollinen oppi saadaan tästä katastrofista.
Vähän irvileukana postaan toimittajan postauksen hienosta BizDevOps-mallistaan:
https://www.sarastia365.fi/sarastia365n-devops-hyrra-tallainen-on-bizdevops-toimintamallimme/
mutta ihan tosissaankin olisi kiinnostavaa nähdä vastuunjakomallia tilaajan ja toimittajan roolien kesken siinä tilanteessa, kun voidaan ennakoida ongelmia. Meneekö hallinto-organisaation hierarkia projektiorganisaation päätöksentekomallin yli, vai annetaanko tilaajan puolelta projektille aidot toimintaedellytykset myös alaissuhteista riippumatta.
Olet varmasti Otso nähnyt monenlaisia tilanteita suuntaan ja toiseen!