IT-järjestelmiä käsittelevän artikkelisarjan kolmas osa käsittelee tietojärjestelmäuudistuksen haasteita. Lisäksi kerromme arvokkaita vinkkejä mm. tilanteeseen, jossa budjetti aseittaa rajoitteet uudistukselle. Lisäksi annamme vinkkejä miten toimia, jos vastaavaa ratkaisua ei löydykään markkinoilta.
Kun valmista ratkaisua ei ole saatavilla
Oli kyseessä liiketoimintasovelluksen osittainen uudistaminen tai kokonaan uudelleenrakentaminen, valintaan vaikuttaa myös sovelluksen erikoistumis- ja räätälöintiaste. Jos kyseessä on yleisempi sovelluskokonaisuus (esim. ERP, CRM, HelpDesk), markkinoilta löytyy helpommin joko valmiita ratkaisuja tai mahdollisuuksia soveltaa omaa sovellusta osana ko. laajempaa kokonaisuutta. Jos halutaan päivittää ns. kapealle toimialalle aikoinaan toteutettu sovellus, tuskin löytyy valmiita ratkaisuja, jolloin uudistamislaajuus on kapeampi ja lähtökynnys korkeampi.
Erikoistumisen saralla yhtenä vinkkinä on pyrkimys yhteistyöhön samantyyppisen kumppaniorganisaation kanssa, joka käyttää samantyyppistä sovellusta - ja kustannusten jako kumppanin kanssa. Joskus joutuu lähtemään etsiskelemään samantyyppistä kumppania jopa ulkomaille, jolloin avautuu mahdollisuuksia toimia kansainvälisessä ympäristöä. Silloin tilanteesta ja omasta asenteesta riippuen voi päästää jopa johtamaan kansainvälistä yhteistyötä.
Mikä on riittävä budjetti järjestelmäuudistukselle?
Yleensä hyvin rajoittavaksi ja tärkeäksi tekijäksi nousee käytettävissä olevat varat eli myönnetty budjetti. Joskus on tarvetta käyttää uusia tekniikoita tai tiettyjä vaativiakin teknisiä ratkaisuja, mutta raha ei tahdo riittää.
Yhtenä pelastajana voi silloin toimia open source -toteutukset. Niillä on omat riskinsä ja kustannuksensa, mutta kustannustaso on eri luokkaa kuin kaupallisilla sovelluksilla. Toki tällaisiin open source -toteutuksiin sitoutuminen vaatii omaa tasapainottelua päätöksenteossa, mutta tällaiset toteutukset ovat nykyään yritysten ja organisaatioiden yhä yleisemmin valitsema vaihtoehto.
Tietojärjestelmäuudistuksen piilokustannukset
Varsinaisen toteutuksen tai hankinnan osalta kannattaa selvittää ja huomioida valitun ratkaisun, sen toimittajan ja ylläpidon kokonais- ja piilokustannukset ja niihin vaikuttavat tekijät. Niitä ovat mm. siirtymävaiheen rinnakkaiskäyttö tai kerralla-vaihdon haasteet ja riskit, koulutus, lisenssit, konsultointi- ja ylläpitokustannukset, asiakkaan (käyttäjän ja myös loppuasiakkaan) muutosvastarinta, helppokäyttöisyys, tyytyväisyys, ja myös ns. piilohyödyt. Järjestelmän tai sovelluksen kokonaisuudistuksella ja räätälöinnillä on eri hintalappuja, joilla ei ole suoranaista riippuvuutta siihen, kumpi ratkaisu on valittu.
Investointien tarkka arviointi kannattaa
Mahdollisuuksien mukaan on pyrittävä laskemaan ja huomioimaan aineelliset ja aineettomat hyödyt sekä haasteet. Hyvä isäntä pyrkii aina arvioimaan mahdollisimman tarkkaan investoinnin kustannukset ja tekemään investointilaskelman, mukaan lukien vuotuiset kustannukset ja investoinnin eliniän.
Sovellusmuutosten kulut ja teknologinen ajallinen riittävyys tulee myös suhteuttaa. Ei ole järkevää, eikä aina edes mahdollista tehdä tuntuvia investointeja asioihin, jotka muuttuvat nopeasti, usein ja väistämättä. Tuleekin arvioida, milloin joudutaan tekemään seuraava uusiminen ja mikä on sen todennäköisin aiheuttaja.
Entä miten laaja käyttäjämäärä tai korkea käyttöaste ko. sovelluksella/järjestelmällä tässä vaiheessa on ja tuleeko se muuttumaan paljon?
Vanhan järjestelmän lähdekoodi suurena haasteena
Jos ei haluta rakentaa uutta sovellusta, vaan mieluummin päivittää vanhaa, pitää selvittää vanhan ohjelmakoodin laatu ja saatavuus ylipäätänsä. Useimmiten on aiheellista ottaa yhteys sovelluksen toimittajaan tai tekijään. Pahimmissa tapauksissa ko. yritystä ei ole enää olemassakaan, tekijä ei ole harrastanut koodausta enää vuosiin.
Jos koko lähdekoodia ei ole saatavana, on spekulointia kokeilla generoida koodi nykyisestä sovelluksesta. Siinäkin tapauksessa, että ohjelmakoodi on tallessa, sen läpikäynti ja vanhan version toiminnallisuuksien muuttaminen on useimmiten vaikeampaa kuin uuden koodin kirjoittaminen.
Mutta kuka tämän omistaa?
Viimeistään tässä vaiheessa pitää huomioida ja tarvittaessa selvittää nykysovelluksen omistajuuskuviot. Eli onko sovelluksen toimittajan/tekijän kanssa aikoinaan solmittu sopimus, onko se tallessa, mitä oikeuksia omalla organisaatiolla on ko. sovellukseen tai sen muuttamiseen yms.
Vertaile, analysoi, arvioi ja kilpailuta
Tietojärjestelmän tai sovelluksen päivittämisen tai uudelleenrakentamisen vaiheessa tärkeimmäksi nousee kysymys siitä, miten tilannetta lähdetään analysoimaan ja arvioimaan, miten tehdään päätöksiä ja suoritetaan päivityksiä. Vahvat ja suoranaiset vaikutukset ovat mm lähestymistavalla, resurssien saatavuudella, projektin toteutustavalla ja metodologialla, kiireellisyydellä ja aikataululla. Eri vaihtoehtoja kannattaa vertailla, jotta valinta on paras ja kustannustehokas. Siksi jopa kevyt kilpailuttaminen kannattaa (ja julkishallinnossa projektikoosta riippuen on välttämätön).
Ihan aluksi:
- Mitä vaihtoehtoisia toteutuksia on olemassa kummallekin ratkaisulle (päivitys vs. uuden rakentaminen)?
- Mitä omat arkkitehdit ja kehittäjät esittävät ehdotuksiksi ja niiden työmääräarvioiksi?
- Entä ulkoiset toimittajat, ovatko ne omiin verrattuna edullisempia, omaperäisempiä, helpompia, nopeampia, universaaliratkaisun tai kuningasidean tarjoajia?
- Voiko joistakin niistä tulla vakituinen työkumppani, joka parhaimmillaan voisi auttaa asettamaan liiketoiminta tai sen osia uudenalaiselle alustalle?
Bisnesmaailma on täynnä esimerkkejä mittareista ja toimittajatyytyväisyyden näytöistä:
- Pidempiaikaiset kumppanuussuhteet ko. toimittajaorganisaation kanssa
- Referenssit
- Lukuisat onnistuneet projektit
- Ketteryys
- Avoimuus yhteistoiminnassa
- Toimittajan todistettu osaaminen
- Perinteisten ja uusien teknologioiden, integraatio- ja migraatiototeutusten vahva kokemus
- Kustannustehokkuus
- Asiakkaalle turvalliset ja varmat lähestymistavat
- Toimittajan tarjoama takuu
Päivittää vanhaa vai rakentaa uutta?
Vastaus ei välttämättä ole aina heti saatavilla. Sekä vastaus että tulos riippuu ratkaisevasti siitä, kuka on mahdollistaja. Käytännössä osaava mahdollistaja voi jo ennen varsinaista teknistä toteutusta auttaa myös löytämään oikean vastauksen ketterästi ja laadukkaasti - tai kokonaan ottaa vastuun arvioinnin suorittamisesta, minkä avulla oikea päätöksenteko onnistuu.
Kuten näemme, jos tulokselle halutaan tasapainoa ja kestävyyttä, pitää päätöksentekoa varten ottaa huomioon ja analysoida varsin monta kriteeriä ja näkökulmaa. Näin ko. asian käsittelystä voi tulla aika laaja ja haastavakin. Homma hoituu, kun edetään ketterästi ja peliin saadaan mukaan osaavia tekijöitä!
Lue myös artikkelisarjan ensimmäinen osa, jossa käsittelemme, kannattaako hankkia kokonaan uusi järjestelmä vai parannella nykyistä. Toisessa osassa käsittelemme osallistavan päätöksenteon hyötyjä järjestelmämuutoksissa sekä järjestelmän päivittämisen eri mahdollisuuksia.
