Az informatikai vezetőket rendre nehéz helyzetbe hozza, amikor gyorsan kell állást foglalniuk egy-egy technológia bevezetésével kapcsolatban. Bekötött szemmel ugrani az ismeretlenbe ugyanis több mint kockázatos. Az IT-projektek emiatt sokszor hosszadalmasak is: a körültekintő tervezés után még olyan, részben ismerős terepen zajló projektnél sem lehet kihagyni a pilot fázist, mint pl. az S/4HANA-átállás.

Másrészt egyre gyakoribb, hogy a cégvezetés szeretné, ha vállalata egyfajta technológiai early adopterként viselkedne, mert attól versenyelőnyt remélnek.

De hogyan lehet ennek a kockázatait minimalizálni? Például úgy, hogy a vállalat pilotokat futtat. A pilot azonban sok esetben egyfajta "zöldmezős" gyakorlóterepet jelent, emiatt nem feltétlenül tárja fel a valós körülmények rejtette buktatókat. Így hiába sikeres a pilot, a projekt végül mégis elbukik. Tehát, mondják a projektmenedzsment-szakértők, más utat kell választani a megvalósíthatóság vizsgálatára: készítsünk proof of conceptet (PoC), azaz bizonyítsuk komplexen az elképzelés helyességét.

Pilot ez is, csak a szemlélete és hatóköre más

Technikai értelemben persze a PoC és a pilot IT-projektek nem sokban különbözik egymástól: végső soron egy olyan tesztelési fázist jelent, amely megelőzi a változtatás (klasszikus IT-projekt, pl. egy új rendszer bevezetése, üzleti folyamatok átalakítása vagy szervezeti intézkedés) végrehajtását.

A PoC azonban sokkal átfogóbb információt nyújt a változás megvalósíthatóságáról, illetve lehetővé teszi a lehetséges hatások elemzését, beleértve a sikeres projekt legfontosabb három alapfeltételének, a költség, az időtartam és a hatókör tarthatóságának vizsgálatát. A legfontosabb azonban az, hogy a pilotoktól eltérően sokkal világosabban megmutatja, hogy a tervezett változások milyen előnyöket hoznak, és milyen kockázati vannak. Végül, de nem utolsósorban levezethető belőle egy döntési sablon a végrehajtáshoz, érvelnek PoC-szemlélet hívei.

De nemcsak a megvalósíthatóság útját jelöli ki: az agilis projektekben is használt ún. gyors kudarcok (fail fast) tesztelésére szintén alkalmas. Tesztelhetők vele a funkciók, és szimulálhatóvá teszi a módosított munka- és üzleti folyamatokat, miáltal megközelítőleg jó előrejelzést ad a várható eredményekre vonatkozóan. A PoC a konkrét végrehajtás megtervezéséhez szintén jó kiindulópont: sokkal pontosabbá teszi pl. az idő- és költségkeret meghatározását.

Csináljunk projektet a projektért?!

A PoC-t a gyakorlatban ugyanúgy kell kivitelezni, mint bármely projektet. A projekt terjedelmétől és kontextusától függően meg kell fogalmazni röviden egy koncepciót, amelyben rögzítjük a kiinduló helyzetet. Ugyanebben a dokumentumban meg kell válaszolni néhány alapvető kérdést: mi a projekt célja, milyen technikai és pénzügyi erőforrásokat kell mozgósítani a megvalósításához, milyen időkeretet szánunk a projektre, milyen módszertant (vízesés, agilis stb.) alkalmazunk...?

A PoC célja lehet például különböző eszközök használhatóságának összehasonlítása. Ilyenkor azonos felhasználási eset(ek)re kell megvizsgálni mindegyiket, és mérni a teljesítményüket, használhatóságukat, költségeiket stb.

Ha viszont egy már kiválasztott megoldást kell részletesebben elemezni (vannak helyzetek, amikor valójában nincs választás: lásd a fentebb emlegetett S/4HANA-migrációt), akkor a reprezentatív felhasználási eseteket kell szimulálni a platformon.

Ha a feladatot jól hajtotta végre a csapat, a kapott mérőszámok alapján a PoC-vizsgálat lezárultakor viszonylag könnyű megválaszolni a legfontosabb kérdéseket: teljesültek-e az elvárások?; voltak-e meglepetések az eredményekben?, összességében mik voltak a következményei a módosításoknak? A válaszokból összeállítható egy olyan dokumentum, amely alapján a board valóban felelősen tud dönteni a kezdeményezés megvalósításáról.

Megoldja-e a PoC az early adopterek problémáit?

Az új technológiák alkalmazása esetében kicsit más a mérlegelési szempont. A PoC segítségével azt kell eldönteni, hogy ellensúlyozzák-e az új funkciók a termék-szolgáltatás gyermekbetegségeit. Hoz-e annyi versenyelőnyt, hogy érdemes legyen bevállalni a kiforratlansággal járó kockázatokat?

Ha egy vállalat működését erősen meghatározza IT-jának a fejlettsége, érdemes ennek vizsgálatára önálló egységet felállítani: az ilyen egységeket újabban softlaboroknak (a vállalati informatika virtuális laboratóriuma) nevezik. A részlegek feladata az early adopterként alkalmazható új megoldások felkutatása és/vagy tesztelése a vállalat igényei szempontjából. Azaz lényegében a vállalat intézményesítheti a PoC-folyamatokat egy ilyen speciális kompetenciaközpont felállításával.