Järjestelmähankkeiden sietämätön keveys

Suuret IT-hankkeet ovat tunnetusti melkoisia rahareikiä, sillä riippumatta siitä mitä tutkimusta tarkastelee, niin reippaasti yli puolet niistä epäonnistuu. Suurimmat syyt epäonnistumiseen ovat sitoutumisen puute käyttäjien ja johdon osalta sekä epärealistiset odotukset projektin etenemisestä. Kuinka monta järjestelmähanketta tiedät, jotka olisivat onnistuneet alittaen alustavan projektiaikataulun?

Hei, ei täs mitään. Onhan moni muukin epäonnistunut.

Voehan rähmä!Miksi järjestelmähanke eroaa niin paljon muista ”rakennushankkeista”? Miettikääpä vaikka talonrakennusta; kuinka monta järjestelmäprojektia oikeasti seurataan yhtä tarkalla pieteetillä kuin talonrakentamista? Jos järjestelmäprojektille tehtäisiin yhtä tarkat suunnitelmat, arvioinnit ja edellytykset kuin ns. konkreettisille rakennusprojekteille, niin saataisiinko tuota läpimenoprosenttia kasvatettua?

Niksipirkka

Yksi vinkki järjestelmäprojektin kanssa painiville: Palkatkaa teknisesti pätevä kaveri projektin vetäjäksi. Sellainen, joka on joskus aikaisemmin tehnyt vastaavanlaisen, onnistuneen järjestelmäprojektin. Aivan kuten osaava rakennusmestari säästää aikaa ja omaa mielenterveyttä, kokeneesta projektipäälliköstä ei kannata isommissa järjestelmäprojekteissa tinkiä. Vaikeahan näitä on löytää, sillä hyvin harva joutuu painimaan samankaltaisten, suurten järjestelmäprojektien parissa useammin kuin kerran.

Lisäksi kannattaa tunnistaa järjestelmähankkeeseen sisältyvät aliprojektit ja hallita myös niiden resursointi. Eräs aliprojekti, joka saa usein liian vähän huomiota, on dataharmonisointi (datamigraatio, yhdenmukaistaminen, konvertointi… Miksi sitä nyt haluaakin kutsua). Erääsääkin tapauksessa dataharmonisoinnille oli varattu aikaa kuukausi, vaikka datamassaa oli reippaanlaisesti. Kuulostaako realistiselta? Halpa hinta harvoin korreloi laadun kanssa ja nopeus kasvattaa usein riskiä.

Data on kuitenkin se järjestelmän ydin. Ei se hieno järjestelmä palvele ketään, jos sisältö on silppua. Se mitä hyötyä järjestelmällä halutaan saavuttaa vaikuttaa suoraan siihen, mitä ja kuinka paljon datalle tehdään muutoksia. Järjestelmä itsessään kaikkine palvelinrautoineen on vain kehikko; ”olet mitä syöt”.  Itse asiassa koko asetelma pitäisi kääntää toisin päin, eli varsinainen datan järkeistämisprojekti olisi se ylätason projekti, jonka aliprojektina olisi ”uusi ERPpi”? Silloin taidetaan puhua siitä MDM:stä.

Datan kanssa päästään perimmäisten kysymysten äärelle, kuten kuka vastaa datan laadusta, kuka omistaa datan, millainen hallintomalli, miten olemassa oleva data valjastetaan tehokäyttöön yms. Tullaan sen verran isoon asiakokonaisuuteen, että sitä ei ihan tässä yhdessä blogiartikkelissa pystytä kuvaamaan. MDM asioista tarinoi Maijasen Janne jo viime vuoden puolella. Myös Mikko Jokela vei aihetta eteenpäin omassa blogissaan nostaen datan rinnalle prosessinäkökulman. Lisää datahallinnosta voi lukea esim www.dataversity.net sivuilta.

Mitäs muuta? Johtoportaan tulee sitoutua projektiin, pitäkää visio kirkkaana ja käyttäjät mukaan. Täähän on niin simppeliä, että ihmetyttää toi epäonnistumisten suuri määrä.

Jos aihe muuten kiinnostaa enemmänkin, niin kannattaa ilmoittautua tähän, samaan teemaan pureutuvaan webinaariin.

– Kalle –

Advertisements

2 thoughts on “Järjestelmähankkeiden sietämätön keveys

  1. Itse olen oppinut, että PDM-projekti ei ole IT-projekti. Kuten sanoit rauta on vain kehikko. Yksi syy epäonnistumisille on, että lähdetään siitä tietojärjestelmäprojektista eikä siitä tiedosta.

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s