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.
Järjestelmämuutoksiin mahdollisimman moni mukaan
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ää.
Tarkastele järjestelmämuutoksia myös ulkoisesti
Järjestelmämuutoksia kannattaa myös tarkastella ulkoisesti ja huomioida esimerkiksi seuraavia asioita:
- Millä tavalla tulevat muutokset voivat vaikuttaa oman organisaation imagoon, kilpailijatilanteeseen, asiakaskokemuksiin, kumppanuusyhteistyöhön?
- Minkäänlaista imagoa voimme luoda tai muokata muutosprojektissa oman ratkaisun kautta sidosryhmien silmissä?
- Vaikutetaanko edelläkävijältä, pakkomuutokseen myöhäisreagoijalta, inter- vai pro-aktiiviselta? Seurataanko kilpailijoita vai haastellaan?
- Onko valitsemamme ajoitus sopiva tai mieluummin jopa ennakoiva? Onko ratkaisu ainutlaatuinen, onko se mahdollisuuksien mukaan käyttäjille vaivaton?
Ei välttämättä kokonaan uutta järjestelmää
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.
Esimerkkeinä mainittakoon:
- Käyttöliittymät ja niiden visualisuus ja helppokäyttöisyys: jos halutaan pysyä nykytrendissä ja tuoda GUI:n käyttöön selaimen kautta eli pilvipalveluna, tarjolla voivat olla modernit tekniikat kuten Backbone, RequireJS, jQuary, Underscore, Bootstrap, moodulienhallinta (AMD)
- App- ja logiikkakerros: prosessimoottori, .NET ja JAVA EE -ratkaisut uudemmasta päästä
- Tiedonvälitys, rajapinnat: JSON, XML, REST, AJAX
- Sisältö- ja dokumenttihallinta: Alfresco, Liferay, Sharepoint
- Integraatio ja sen automatisointi: Enterprise Application Integration (EAI), palveluväylä/ESB (vaatii laajempaa arkkitehtuurin huomioonottoa)
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.
Osaajia vanhaan ohjelmointikieleen
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.
Datan migraatio haasteena järjestelmäuudistuksille
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ämuutosten lakiasetukset
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.
