Onnistuneen tietojärjestelmähankkeen menestystekijät

Ohjelmistotuotannon menetelmät ja ohjelmistoprojekteissa sovellettavat käytännöt ovat kehittyneet ja muuttuneet merkittävästi viimeisten vuosikymmenien aikana. Vielä 1990-luvulla suomalaisissa alan oppikirjoissa suositeltu vesiputousmalli on lähestulkoon jäänyt historiaan ja sitä korvaamaan on syntynyt uusia toimintatapoja. Tähän on ollut yhtenä syynä hankkeiden ja projektien koon kasvaminen ja monimutkaistuminen, minkä aiheuttamiin haasteisiin vanhoilla toimintatavoilla ei ole kyetty vastaamaan. Tavoitteena on ollut yhä kattavampi kokonaisuuden ja kannattavuuden hallinta koko hankkeen elinkaaren ajan. Lisäksi suunnittelu pyritään tekemään mahdollisimman toiminta- ja käyttäjälähtöisesti ja toteutus ketterästi, muutoksiin varautuen.

Me Goforella näemme, että tietojärjestelmähankkeissa onnistumista parhaiten tukevat menestystekijät ovat:

  • käyttäjälähtöisyys
  • kokonaisarkkitehtuuriohjaus
  • ketterä kehittäminen
  • palvelukeskeinen arkkitehtuuri
  • hallittu monitoimittajaympäristö.

Tässä artikkelissa käyn läpi edellä listatut periaatteet ja pohdin, mistä taustasta ne ovat syntyneet. Pyrin myös vastaamaan kysymykseen siitä, mitä aikaisemmin käytetyissä menetelmissä ilmenneitä heikkouksia ne ovat kehitetty ratkaisemaan.

Käyttäjälähtöisyys osana hanketta sen alusta saakka

Käyttäjälähtöisyys on järjestelmän käyttäjien, nykyisten ja tulevien, osallistamista koko hankkeen ajan. Aiemmin käyttäjä otettiin usein mukaan tietojärjestelmäprojektiin vasta sen loppuvaiheessa, käyttöönoton aikana, jolloin nämä koulutettiin käyttämään uutta järjestelmää. Tyypillinen reaktio oli muutosvastarinta tilanteessa, jolloin loppukäyttäjät eivät olleet päässeet lainkaan vaikuttamaan heidän vakiintuneita työtapojaan merkittävästi muuttavan järjestelmän ominaisuuksiin ja toiminnallisuuksiin. Käyttäjien sitouttaminen mukaan muutokseen alettiin nähdä merkittävänä asiana. Lisäksi havaittiin, että käyttäjä on tärkein substanssiosaaja tunnistamaan niitä tarpeita, joita tehtävien suorittamiseen liittyy. Käyttäjien osallistaminen tukee merkittävästi myös lopputuotteen jalkautusta ja hyväksyntää sen käyttäjien keskuudessa.

Helppokäyttöisyys on kriittinen tekijä tehokkuuden saavuttamisessa, joka puuttuessaan syö merkittävän osan uusien teknologioiden tuomista eduista. Ottamalla käyttäjälähtöisyys osaksi hanketta alusta alkaen voidaan välttää turhien ominaisuuksien aiheuttamaa resurssihukkaa, tehottomuutta ja heikkoa käytettävyyttä.

Kokonaisarkkitehtuuriohjauksen kautta strategiasta toteutukseen

Kokonaisarkkitehtuurin välityksellä hankkeen strategiset tavoitteet tuodaan konkretiaan, projektien ylätason vaatimuksiksi. Tätä kautta ymmärretään hankkeen ja siihen liittyvän toiminnan, tiedon, tietojärjestelmien ja teknologian kokonaiskuva. Lisäksi kokonaisarkkitehtuurin avulla saadaan hankkeessa toteutettavien palveluiden käyttösuhteet ja riippuvuudet näkyviin, jotta niitä pystytään hallinnoimaan ja muutosten vaikutukset joka kohtaan havaitaan ajoissa.

Vielä muutama vuosikymmen sitten tietojärjestelmät olivat pienempiä ja niillä oli tyypillisesti vähän tai ei lainkaan riippuvuuksia toisiin järjestelmiin. Tietojärjestelmät kehitettiin tai hankittiin pääsääntöisesti yhden organisaation toiminnon tarpeisiin. Tästä syystä kokonaisuuden hallinnan merkitystä ei nähty tai sitä ei pidetty tarpeellisena. Muutenkin tietotekniikan rooli organisaatioissa oli yleisesti ottaen pienempi, ja suuri osa toiminnoista suoritettiin vielä manuaalisesti.

Kun toiminta yhä enemmän siirtyi tietojärjestelmien avulla tehtäväksi, sen rooli toiminnan kehittämisessä muuttui merkittävämmäksi. Jossain vaiheessa ymmärrettiin, että tietotekniikan ei voi antaa ohjata toimintaa, vaan päinvastoin tietojärjestelmien kehittämisen tulee olla toimintalähtöistä. Tästä syystä organisaatioiden toiminnan ja niiden tietojärjestelmien muodostaman kokonaisuuden sekä näitä läpileikkaavien prosessien ymmärtäminen on muodostunut kriittiseksi tietojärjestelmiä suunniteltaessa ja toteutettaessa.

Tulee siis ymmärtää, miten toteutettava järjestelmä tukee organisaation tavoitteita, miten toimintaa kehitetään hankittavan järjestelmän avulla ja miten se integroituu muuhun järjestelmäkokonaisuuteen. Näihin kysymyksiin pystytään parhaiten vastaamaan hanketta edeltävän ja koko järjestelmän toteutukseen tiiviisti liittyvän kokonaisarkkitehtuuriohjauksen kautta.

Ketterä kehittäminen vesiputousmallin korvaajana

Ketteryydellä tarkoitetaan nopeaa sopeutumista muutoksiin. Nykypäivänä on ymmärretty, että ohjelmistoprojekti tulee organisoida niin, että nopeat suunnanvaihdot ovat missä tahansa vaiheessa mahdollisia. Järjestelmän ominaisuuksia iteroidaan ja tarkennetaan koko ajan.

Aiemmin järjestelmän toteutusta edelsi raskas suunnittelu- ja määrittelyvaihe, jonka aikana pyrittiin kuvaamaan ja päättämään mahdollisimman tarkkaan järjestelmän tuleva sisältö. Projektien ja hankkeiden koon kasvaessa ja niiden riippuvuuksien muihin projekteihin lisääntyessä, tämän kaltaisen suunnitelman tekeminen on havaittu käytännössä mahdottomaksi. Kun projekti on riittävän laaja, jo pelkkä määrittelyvaihe muodostuu niin pitkäksi, että sen aikana ympäristö ja tavoitteet ehtivät muuttua moneen kertaan. Näin ollen ilman jonkinasteista epävarmuuden sietoa järjestelmän toteutusta ei periaatteessa saataisi koskaan edes käyntiin.

Ketterän kehittämisen avulla siis hallitaan riskiä, joka aiheutuu siitä, ettei projektin alussa useinkaan ole tarkkaa suunnitelmaa tai varmuutta tuotettavalta järjestelmältä vaadittavista ominaisuuksista. Se tarkoittaakin jatkuvaa muutosten hallintaa projektin alusta loppuun.

Palvelukeskeinen arkkitehtuuri haastaa järjestelmäkeskeisen ajattelun

Palvelukeskeinen arkkitehtuuri on arkkitehtuurityyli ja ajattelutapa, jossa tietojärjestelmät hahmotetaan ja suunnitellaan palveluiden kautta. Ohjelmistojen toiminnallisuus ja sovelluslogiikka toteutetaan jaettujen uudelleenkäytettävien palveluiden avulla.

Aikaisemmin järjestelmät tyypillisesti rakennettiin irrallisiksi ja itsenäisiksi kokonaisuuksiksi. Ne rakentuivat siiloiksi, joiden tietosisältöön ei päässyt käsiksi muista järjestelmistä ja joka palveli ainoastaan muutamia ennalta määriteltyjä liiketoimintafunktioita. Järjestelmät olivat myös hyvin hankalasti muutettavissa ja jatkokehitettävissä.

Tietojärjestelmiin kohdistuvat muutosvaatimukset ovat koko ajan lisääntyneet. Lisäksi järjestelmien käyttötavat muuttuvat koko ajan esimerkiksi mobiilikäytön ja sähköisen asioinnin kehityksen myötä. Muutospaineista huolimatta järjestelmillä halutaan olevan pitkä elinkaari. Palveluarkkitehtuurin hyötyjä onkin ketteryyden, uudelleenkäytettävyyden, tuottavuuden ja tieto-integraation parantaminen, kustannussäästöt ja avoimuuden ja kilpailutuksen tehostaminen.

Monitoimittajaympäristön avulla eroon toimittajariippuvuudesta

Hallitulla monitoimittajaympäristöllä tarkoitetaan toteutuksen suunnitelmallista jakamista useille eri toimittajille, jotka tuottavat kukin oman osuutensa yhteisestä kokonaisuudesta.

Aiemmin käytäntönä oli hankkia järjestelmä yhdeltä toimittajalta, joka sai näin ollen automaattisesti monopoliaseman järjestelmän ylläpitoon ja jatkokehittämiseen koko sen elinkaaren ajaksi. Tämä muodosti merkittävän riskin tilaajan kannalta ja johti pahimmillaan kustannusten hallitsemattomaan kasvuun ja laadun heikkenemiseen. Vähitellen alettiinkin miettiä tapoja, jotka mahdollistaisivat toimittajan vaihtamisen kesken jopa projektin tai viimeistään jatkokehitysvaiheessa. Heräsi myös ajatus, voitaisiinko toteutus purkaa pienempiin osiin, joilla olisi kaikilla eri toimittaja. Tällöin vältyttäisiin yhteen toimittajaan sitoutumiselta.

Jotta monen toimittajan yhteistyö tapahtuisi hallitusti, tärkeää ovat yhteiset toimintatavat ja pelisäännöt, yhteinen visio ja fokus, jonka eteen kaikki tekevät työtä sekä systemaattinen ja riittävä dokumentointi. Lisäksi kommunikaation rooli muodostuu sitä merkittävämmäksi mitä useampia toimijoita työhön osallistuu ja mitä enemmän riippuvuuksia näiden tekemällä työllä on toisten työhön. Myös ketterä toteutustapa asettaa paineita kommunikaation sujuvuudelle. Ei riitä, että kukin toimittaja kommunikoi tilaajan kanssa, vaan myös toimittajien keskinäisen kommunikaation toimivuudesta tulee huolehtia. Samalla tilaajan tulee pysyä jatkuvasti selvillä, mitä kenenkin toimesta on suunniteltu ja sovittu.

Toteutuksen purkaminen pienempiin osiin ja näiden kilpailuttaminen erillään hyödyttää tilaajaa vähentämällä riippuvuutta yhdestä toimittajasta. Se mahdollistaa toimittajien välisestä kilpailusta hyötymisen ja pienten toimijoiden pääsyn mukaan isoihinkin tietojärjestelmähankkeisiin. Tämä kuitenkin edellyttää tilaajalta palvelukeskeistä ajattelutapaa ja voimakasta kokonaisarkkitehtuuriohjausta, jotta toteutuksen osien väliset riippuvuudet kyetään hallitsemaan.

Tavoitteena onnistuminen

Edellä kuvattujen periaatteiden ja menetelmien käyttö siirtää vanhanaikaisempiin menetelmiin verrattuna yhä enemmän vastuuta hankkeen onnistumisesta toimittajalta tilaajalle. Tilaajalta vaaditaan osallistumista ja osaamista. Projektiin tulee sitouttaa mukaan sekä loppukäyttäjiä että toiminnan edustajia. Vaaditaan syvällistä ymmärrystä koko toimintaympäristöstä ja toteutettavaan järjestelmään liittyvistä muista järjestelmistä ja palveluista. Tilaajan osuus onkin ratkaiseva sen kannalta onnistuuko hanke vai ei.

Kun mietitään milloin hanke on onnistunut, olennaisiksi asioiksi kustannusten ja aikataulun ennustettavuuden lisäksi nousevat lopputuloksen laatuun liittyvät seikat. Järjestelmän tulee olla sekä toiminta- että käyttäjälähtöisesti suunniteltu, yhteentoimiva muiden järjestelmien kanssa ja ylläpidettävä. Lisäksi välttämällä yhteen toimittajaan sitoutumista pystytään hallitsemaan kustannuksia ja pienentämään järjestelmän elinkaareen liittyviä riskejä.

Me goforelaiset olemme olleet mukana asiakkaidemme onnistumisissa lukuisissa ohjelmistohankkeissa ja nähneet, miten onnistumisen aikaansaaminen on itse asiassa hyvin yksinkertaisten perusperiaatteiden noudattamisesta kiinni. Olemmekin sitä mieltä, että kun hankkeessa on voimakas kokonaisarkkitehtuuriohjaus, se toteutetaan monitoimittajaympäristöä halliten, ketterästi ja palvelukeskeisen arkkitehtuurin periaatteita noudattaen sekä käyttäjälähtöisesti, lopputuloksen onnistuminen on taattu.

Lue sivuiltamme lisää onnistuneen hankkeen valmistelusta ja sen johtamisesta.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

Liity joukkoon

Backend-kehittäjä

Helsinki, Jyväskylä, Tampere

Frontend-kehittäjä

Helsinki, Jyväskylä, Tampere