Különösen az early adopter vállalatoknak lehet hasznos. De különbözik ez bármiben az amúgy is megkerülhetetlen tervezéstől és pilottól?

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.

Piaci hírek

Magyar fejlesztésű szoftverrel bővült a projektmenedzserek eszköztára

A projektkontrolling területén jelenthet segítséget a céleszköz, amellyel lecserélhetők az elszórtan tárolt Excel-fájlok.
 
A software defined network már évek óta velünk él. Csak idő kérdése volt a koncepciót kiterjesztése a WAN-okra.

a melléklet támogatója a Yettel

Amióta a VMware a Broadcom tulajdonába került, sebesen követik egymást a szoftvercégnél a stratégiai jelentőségű változások. Mi vár az ügyfelekre? Vincze-Berecz Tibor szoftverlicenc-szakértő (IPR-Insights) írása.

Nyílt forráskód: valóban ingyenes, de használatának szigorú szabályai vannak

Különösen az early adopter vállalatoknak lehet hasznos. De különbözik ez bármiben az amúgy is megkerülhetetlen tervezéstől és pilottól?

Sok hazai cégnek kell szorosra zárni a kiberkaput

Ön sem informatikus, de munkája során az információtechnológia is gyakran befolyásolja döntéseit? Ön is informatikus, de pénzügyi és gazdasági szempontból kell igazolnia a projektek hasznosságát? Mi közérthető módon, üzleti szemmel dolgozzuk fel az infokommunikációs híreket, trendeket, megoldásokat. A Bitport tizennegyedik éve közvetít sikeresen az informatikai piac és a technológiát hasznosító döntéshozók között.
© 2010-2024 Bitport.hu Média Kft. Minden jog fenntartva.