Tässä IT-järjestelmien -artikkelisarjan toisessa osassa kädään läpi osallistavan ja eri sidosryhmien huomioivan päätöksenteon hyödyt sekä mm. järjestelmän päivittämisen eri vaihtoehtoja. Ensimmäisessä IT-järjestelmiä käsittelevässä artikkelissa käsittelimme, kannattaako rakentaa kokonaan uusi järjestelmä vai kehittää nykyistä ratkaisua.
Alusta asti kannattaa ottaa keskusteluun mukaan kaikki asiasta kiinnostuneet tahot ja osapuolet. Kärjistetysti ilmaistuna ei riitä, että asiasta päättävät CEO, CIO ja sovelluksen pääkäyttäjä. Kaikki hyödyllinen tieto on harvoin tiedossa, saati dokumentoitu, ja ns. hiljainen tieto tulee usein yllätyksineen esille.
Sisäisten tiimien ja tahojen huomioiminen on tärkeää järjestelmämuutoksen päätöksenteossa. Sovelluksen käyttäjät ja hyödyntäjät sekä liittyvien sovellusten, prosessien ja palveluiden toteuttajat pystyvät tuomaan arvokkaita näkökulmia ja vinkkejä muutosten ideointiin. Siten heidän osallistumista järjestelmien uudistusprojektiin kannattaa hyödyntää.
Järjestelmämuutoksia kannattaa myös tarkastella ulkoisesti ja huomioida esimerkiksi seuraavia asioita:
Joskus ihan pakottavaa tarvetta muutokseen ei ole. Ajattelumallissa, lähestymistavassa ja teknologiamahdollisuuksissa on kuitenkin tapahtunut niin vahva vaihdos ja tarjonta viime vuosina, että niitä on suorastaan pakko hyödyntää, ettei nykyinen ratkaisu jäisi ns. mentaalisesti vanhentuneeksi.
Usein silloin on kyse joistakin kokonaisratkaisun osista, jolloin ei ole tarvetta rakentaa uutta järjestelmää, vaan on mahdollista ja tarkoituksenmukaistakin uusia vain järjestelmän kerrokset tai niiden rajapinnat.
Päivitettäviä osioita voivat olla muutkin kuin kerrokset tai niiden rajapinnat. Jos mahdollista, koko IT-ratkaisua ja sen päivittämistä kannattaa tarkkailla modulaarisuuden näkökulmasta. Moduuleina voivat olla sovelluksen/ratkaisun loogiset osat, koodin blokit yms.
Tekniikan vanheneminen voi myös johtaa siihen, että esim. vanhan sovelluksen koodaamiseen käyttämä ohjelmointikieli on tullut sen verran harvinaiseksi ja nykyään vähän käytetyksi, että sen osaajia on vaikeaa löytää. Kukaan ei välttämättä ole enää edes kiinnostunut panostamaan vanhan tekniikan oppimiseen.
Integroitavuudesta ja migraatiotarpeista kannattaa mainita erikseen systeemin vain osittaisten uusimisten yhteydessä. Ne ovat tärkeitä tekijöitä, jotka saattavat pidätellä isoimmista arkkitehtuurimuutoksista eli kokonaan uuden järjestelmän rakentamisesta/hankkimisesta. Integraation osalta pyritään silloin hyödyntämään valmiita rajapintoja (ellei ole tarvetta muuttaa niitä tai luoda uusia).
Uuden sovelluksen tapauksessa on myös suunnitteltava ja luotava uusia sisältörakenteita eli tietokantoja yms. Silloin isoksi ja usein hintavaksi haasteeksi muodostuu datan migraatio, koska datan rakenne muuttuu siinä tapauksessa yleensä radikaalisti.
Järjestelmämuutosprojekteissa on huomioitava myös ns. pakottavat lakiasetukset ja säädökset. Julkishallinnon organisaatioissa on sen lisäksi myös omat vaatimuksensa. Voi esimerkiksi olla, että uudistuksen myötä on tarkoitus linkittää sovellukseen käyttäjätietoja sisältävät tietovarannot, mikä vaatii erikoiskäsittelyä ja lupaa.
Oman organisaation tai ulkoisen toimittajan lakiosaston apu on tällaisissa tilanteissa välttämätön. IT-kehityksen myötä tietoturvakin muuttuu koko ajan vaativammaksi. Se, mikä viiden vuoden vanhassa sovelluksessa oli ok tai ei ollut edes tiedossa, vaatii viimeistään nyt ehdottomasti salattuja yhteyksiä, keskitettyä käyttövaltuushallintaa, logien seurantaa ja käsittelyä.
Tämä oli järjestelmämuutoksia käsittelevän artikkelisarjan toinen osa. Seuraavassa eli kolmannessa osassa kerrataan IT-järjestelmäuudistuksen haasteet ja annetaan arvokkaita vinkkejä mm. tilanteeseen, jossa vastaavaa ratkaisua ei löydy markkinoilta tai kun budjetti asettaa rajoitteita.