Tämä artikkeli aloittaa kolmiosaisen IT-järjestelmien kehittämissarjan, jossa käsitellään IT-järjestelmien uusimista. Tässä ensimmäisessä osassa käsittelemme, kannattaako olemassa oleva järjestelmää parannella vai tulisiko rakentaa kokonaan uusi järjestelmä?
Jatkuvat ja usein dynaamiset muutokset sekä teknologiassa että liiketoiminnassa asettavat omia vaatimuksiaan ja pakottavat järjestelemään IT-kokonaisuudet, bisnessovellukset ja -systeemit uudelleen. Silloin usein organisaation tai yrityksen johto, IT-johto mukaan lukien, joutuu tekemään päätöksen siitä, uusitaanko olemassa oleva järjestelmä vai rakennetaanko kokonaan uusi? Tähän liittyykin useita kysymyksiä, kuten:
- Millainen muutos on kyseessä?
- Riittääkö vanhan järjestelmän pikkuviilaus vai pitääkö lähteä uudistamaan järjestelmä perin pohjin?
- Kannattaako aina rakentaa uutta vai voisiko joskus korjata vanhan paremmaksi?
- Voiko moottori säilyä samana ja käyttöliittymän uusia tai toisinpäin?
- Eiköhän siinä vanhassakin ole paljon toimivaa?
Vastauksia on yhtä paljon kuin tilanteita.
Nollaratkaisu ja paremman ajan odotus
Kokeneet päätöksentekovaikuttajat (mm. konsultit) pitävät aina yhtenä vaihtoehtona ns. nollaratkaisua. Se tarkoittaa sitä, ettei tehdä mitään muutoksia ainakaan vielä. Syyt voivat olla erilaisia, esim. lähiaikoina tulevat ja asiaan vaikuttavat muut projektit ja uudistukset, budjettitilanne, odotettavissa olevat liiketoiminnan strategiset korrektiliikkeet yms.
Pitäisi kuitenkin muistaa, että joskus päätöksen ja sen mukaisen toteutuksen pitkittäminen ja siirto "parempiin aikoihin" voi pahentaa tilannetta mm. kasvattamalla tulevia kustannuksia. On myös tilanteita, jolloin ei enää voi lykätä järjestelmän uusimista tai uudelleenrakentamista. Näitä ovat esimerkiksi olennaiset lakien, säädösten, organisaation tai prosessien muutokset, uudet roolit, käyttäjä- ja asiakasryhmät yms.
IT-järjestelmän uusimiseen Kokonaisarkkitehtuurin näkökulmasta
Oli kyse mistä tahansa IT-järjestelmästä tai -sovelluksesta, muutosta pitäisi lähestyä kokonaisarkkitehtuurin (yritysarkkitehtuuri) näkökulmasta. Asia helpottuu huomattavasti, jos organisaatiossa on ollut ennestään organisoitu ja ylläpidetty kokonaisarkkitehtuurityö ja siihen liittyvät prosessit. Jos kuitenkaan ko. lähestymistapaa ei ole systemaattisesti käytetty, kannattaa viimeistään tässä vaiheessa miettiä sen hyödyntämistä.
Käytännössä tämä tarkoittaa sitä, että kyseessä olevan järjestelmän uusimista käsitellään koko organisaation isomman kuvan osana, mm. strategiset tavoitteet ja niiden toteutustavat, tuotantoketju, sidosryhmät, liiketoiminta-, tieto-, järjestelmä- ja teknologia-arkkitehtuurit. Hyvän pohjan antaa esimerkiksi kansainvälinen viitekehys TOGAF ja kotimainen JHS-suositus 179, kumpikin ilmaisia.
Kokonaisarkkitehtuuri antaa mahdollisuuden huomioida monet tärkeät näkökulmat ja välttyä pahimmilta virheiltä, kuitenkaan pakottamatta käyttämään ko. kehyksiä koko laajuuksissaan.
Pitkäaikainen sitoutuminen järjestelmään
On huomioitava myös, että kriittisen tai tärkeän järjestelmän hankinta tarkoittaa pitkäaikaista sitoutumista yhteen teknologiaan tai toimittajaan. Niinpä on tärkeää ajatella järjestelmämuutosta myös pidemmällä aikajanalla, sekä suhteessa kokonaiskustannuksiin ja liiketoimintaympäristöön.
Onko tarkoitus muuttaa vain ko. sovellus, vai lähdetäänkö uudistamaan myös lähestymistavat? Onko kyseessä vain IT-osa, sen korvaaminen tai korjaaminen, vai onko kyseessä isompi muutos, jossa käydään läpi kokonaisvaltaisesti bisnestarpeet?
Vaatimukset järjestelmältä ovat muuttuneet
Vanhan sovelluksen luontivaiheessa oli eri ajattelutapa, eikä silloin ollut tiedossa nykyisiä teknologisia mahdollisuuksia. Elämä on muuttunut sen jälkeen paljonkin. Nyt asiakkaiden ja käyttäjien käsitykset, vaatimukset ja tottumukset ovat erilaisia kuin vaikkapa seitsemän vuotta sitten. Siten esimerkiksi Lean-metodologian soveltaminen on tässä hyvin suositeltavaa. Ketterä ohjelmistokehitys on tapa varmistaa, että prosessi on tehokas ja jouheva.
Kysy ja voita!
- Miksi olemme toimineet kuten tähän saakka ja juuri näillä työkaluilla?
- Mitä oikeasti halutaan saada aikaan, mitä lisäarvoa tahdomme saavuttaa?
- Toimimmeko oikein?
- Mitä turhaa on prosesseissamme ja miten pitäisi toimia, mitä pitää muuttaa?
Vastaamalla näihin kysymyksiin voidaan saada yllättäviä vastauksia, aivan uudenlaisia otteita, arkkitehtuuri- ja teknologiaratkaisutarpeita, joilla on vaikutusta siihen, lähdetäänkö rakentamaan uutta vai pärjätäänkö vanhan päivittämisellä.
Veturina bisnes vai teknologia?
Mielenkiintoinen huomio on sekin, onko järjestelmämuutoksen omistajana tai käynnistäjänä IT vai liiketoiminta. Toki oletusarvoisesti tarkoituksena on se, että organisaation kehitys tapahtuisi bisnesvetoisesti, jolloin IT:n pitää toimii tärkeässä kumppanuusroolissa, ei kuitenkaan pelkkänä "toimittajana". Käytännössä reaalielämässä usein nimenomaisesti tietohallinto herättää liiketoiminnan johtoa jo pakollisiin muutoksiin. Uudistusten omistajan/käynnistäjän roolilla ja asenteella on vaikutusta lopullisiin päätöksiin.
Tässä oli IT-järjestelmien hankkimista käsittelevän blogisarjan ensimmäinen osa.
Seuraavassa osassa käydään läpi osallistavan ja eri sidosryhmien huomioivan päätöksenteon hyödyt, järjestelmän päivittämisen eri vaihtoehtoja sekä muutamia yleisiä syitä päivityksille. Kolmannessa osassa käsitellään IT-järjestelmäuudistuksen haasteita sekä kerrotaan vinkkejä miten toimia, kun budjetti asettaa rajat järjestelmän uusimiselle.
