PARHAAT KÄYTÄNNÖT
Matti Kinnunen, 11.11.2011, 13:17Miten testata toteutusta POC:lla?
Menestyvät tietohallinnon johtajat tietävät, että on parempi katsoa kuin katua. Onnistuneet projektit ovat hyväksi urakehitykselle yrityksessä, epäonnistuneet projektit taas eivät. Epäonnistumisten välttämiseksi monet johtajat vaativat järjestelmätoimittajilta POC-vaihetta (Proof of Concept, ratkaisun/konseptin todennus) ennen sopimuksen allekirjoitusta, jotta voidaan todentaa kyseessä olevan ratkaisun toimivuus. Ict-alallakin uskotaan vasta kun nähdään omin silmin.
Hankittavan ratkaisun testaaminen POC:lla on hyvä tapa saada käsiinsä paljon arvokasta tietoa. Tärkeintä on määritellä etukäteen, mitkä ovat ratkaisun valintaan vaikuttavat tärkeimmät toiminnot, ja varmistaa POC:lla, että ne toimivat odotusten mukaisesti. Vääriin toimintoihin keskittyminen ei varmasti auta välttämään kalliita virheitä. Mihin POC:ssa siis kannattaa kiinnittää huomiota?
Suurimmat mahdolliset virheet voidaan jakaa kahteen eri luokkaan:
-projekteihin, joiden budjetti ja aikataulu venyvät
-järjestelmiin, jotka eivät tuota tarpeeksi tai ollenkaan liiketoimintahyötyjä
Jotta projektien aikataulu tai budjetti ei pääse venymään, pitää varmistaa että toimittaja tietää, miten testattavan ratkaisun saa toimitettua onnistuneesti. Tosin pelkästään toimittajan todistettu tietotaito ei riitä, sillä jokainen onnistunut käyttöönottoprojekti vaatii myös ostajan, tietohallinnon, loppukäyttäjien ja liiketoiminnan panosta.
Näin ollen POC:n tehtävänä on todistaa että kaikki kolme osapuolta (tietohallinto, toimittaja ja liiketoiminta) pystyvät työskentelemään yhdessä.
POC-vaiheen aikana rakennetaan kommunikointikanavia, sovitaan projektikäytäntöjä ja varmistetaan osapuolten sitoumus projektiin. Etenkin globaaleissa projekteissa on hyvä varmistaa että yhteistyö ja kommunikointi toimivat myös kulttuurirajojen yli; jos kommunikointi ei toimi POC-vaiheessa, se ei tule toimimaan myöhemminkään.
Jotta vältetään liiketoiminnan kannalta tarpeettomat järjestelmät, POC:n tulee testata ratkaisua, jonka vaikutukset liiketoimintaprosesseihin ovat mitattavissa.
POC-vaiheen lopputuotteena pitää olla järjestelmä tai ratkaisu, jota loppukäyttäjät voivat käyttää. Käyttäjien pitää pystyä mittaamaan uuden järjestelmän tuomat liiketoimintahyödyt, ja määrittämään niille rahallinen arvo. Kaikki POC:t, joiden tuloksena ei saavuteta todellisia liiketoimintahyötyjä, ovat ajan ja rahan hukkausta – ja samalla merkitsevät tietä projektin epäonnistumiseen.
Joten, POC-vaiheen jälkeen pitäisi osata vastata kahteen kysymykseen:
-Pystymmekö todistamaan ratkaisusta tehdyn business casen?
-Pystymmekö työskentelemään yhdessä?
Kysymyksissä esiintyvä ”me” on tietysti tietohallinto, toimittaja ja liiketoiminta. Jos et pysty vastaamaan molempiin kysymyksiin myöntävästi, ehdotan että etsit toisen toimittajan.
Matti, olet tasan oikeassa: "Kaikki POC:t, joiden tuloksena ei saavuteta todellisia liiketoimintahyötyjä, ovat ajan ja rahan hukkausta – ja samalla merkitsevät tietä projektin epäonnistumiseen". Viittaat ilmeisesti ERP-projekteihin? Mutta entäpä ne POC'it, joilla on mitattava hyöty? Tuotannon tietojärjestelmillä, kuten kehittyneet tuotannonsuunnittelujärjestelmät (APS), on lähes poikkeuksetta onnistunut POC. Kerrankin voidaan asettaa sellaiset mittarit, joiden seuraaminen on selkeää, nimittäin läpimenoajat ja KET.
PARHAAT KÄYTÄNNÖT
Sonja Laakkonen, 16.11.2011 15:38Voiko tietohallintolain ohittaa yksityissektorilla?
Ilmoituksesi käsitellään seuraavan työpäivän kuluessa.