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.
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 -
Avainsanat: data, Data Governance, erp, Master data management, MDM
4.2.2012 11:48 |
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.
6.2.2012 08:39 |
Juurikin näin. Itse se kehikkoprojekti, eli järjestelmäprojekti tulisi nähdä alisteisena projektina varsinaiselle tiedonhallintaprojektille. Koitin sitä ajatusta tuoda tuohon loppuun, joskin puhuin tiedon sijaan datasta.
Mutta samapa se millä kärjellä mennään, hintahan on aina ratkaiseva tekijä
: http://www.tietoviikko.fi/kaikki_uutiset/tiedon+ja+logican+tarjousten+valtava+hintaero+44+miljoonaa+euroa/a764381