Tuoreimman Harvard Business Review’n artikkelissa Why IT Fumbles Analytics professorit Donald Marchand ja Joe Peppard haastavat CRM-, ERP- ja muiden johtamisjärjestelmäprojektien mantran, jonka mukaan valittu teknologia on jalkautettava aikataulussa, suunnitelman mukaisesti ja sovituilla kustannuksilla. Vaikka projektien lopputulos olisikin perinteisillä mittareilla (tehokkuus, kustannukset, tuottavuus ym.) tarkasteltuna onnistunut, ei yritysten johto yleensä ole tyytyväinen lopputulokseen. Syy tyytymättömyyteen: järjestelmissä käsitellään valtavia datamääriä, mutta tuota dataa ei osata valjastaa paremman johtamisen ja syvällisemmän ymmärryksen tueksi.

Marchand ja Peppard esittävät, että projekteissa tulisi perinteisen mantran toistelun sijaan keskittyä perehtymään tietojen luontiin ja niiden hyödyntämiseen käyttäjien – ihmisten – näkökulmasta. Lopputuloksena saataisiin järjestelmiä, jotka hyödyttäisivät liiketoiminnan johtamista.

Artikkelin kirjoittajat antavat viisi neuvoa liiketoiminnan IT-projekteille:

1. Sijoita ihmiset projektin ytimeen.
2. Painota tiedon hyödyntämistä IT-projektien keinona tuottaa lisäarvoa liiketoiminnalle.
3. Täydennä projektiryhmää vuorovaikutuksen ja käyttäytymisen asiantuntijoilla.
4. Keskity oppimiseen.
5. Panosta liiketoiminnan ongelmien ratkomiseen, älä teknologian jalkautukseen.

Hyvänä summauksena Marchand ja Peppard toteavat, että IT-projekteissa keskitytään selvästi vähemmän I:hen kuin T:hin. Ja mikäpä siinä, sillä useimmille meistä se teknologia on hauskempaa ja helpompaa.

Olen lukemattomia kertoja CRM-projekteissa ja asiaa käsittelevissä koulutuksissa korostanut lopputuloksen, aikataulun ja budjetin seurannan merkitystä ja helppoutta. En vielä tämän artikkelin perusteella ole valmis heittämään niitä roskakoriin, mutta rinnalle nostaisin mieluusti edellä mainitun liiketoiminnan ongelmien ratkomisen. Jos projekti saadaan paperilla siististi maaliin, mutta hyödyt ovat minimaaliset, ollaanko aidosti maalissa?

Marchand ja Peppard viittaavat yhdeksi ongelmien lähteeksi toimintatavan, jossa järjestelmien määritykset tehdään projektin suunnitteluvaiheessa. Niiden lopputulos realisoituu kuitenkin vasta projektin valmistuttua. Käsitettä mainitsematta professorit kuvaavat juuri vesiputousmallin yleisimmän haasteen: työkaluja suunnitellaan samalla, kun prosesseja mallinnetaan uusiksi. Lopputulosten oikeellisuus ja hyödynnettävyys selviää tulevaisuudessa, kun järjestelmä saadaan käyttöön.

Tässä lienee jälleen yksi peruste suosia ketteriä kehitysmenetelmiä. Ja painottaa tiedon ja johtamisen merkitystä liiketoiminnassa pelkän välinepuuhastelun sijaan.