Avagy ötlettől a megvalósításig egy multinál.
Avagy ötlettől a megvalósításig egy multinál.
A Corporate IT sorozat 5. része (korábbi postok 1. rész, 2. rész, 3. rész és 4. rész) azt a varázslatos folyamatot veszi nagyító alá, amikor az ötletből valóság lesz.
Nem, nem ITIL-ről vagy módszertanról lesz szó, hanem az elmélet gyakorlati megvalósulásáról. Mert ugye az ember kitalál valami jó ötletet – valamit meg kell változtatni az egyik szoftveren -, elküldi az ötletet valahová, aztán nem történik semmi. Vagy ami még zavaróbb: mindenki elfelejtkezik róla, aztán 1 év múlva váratlanul valaki telefonál, hogy a változtatás elkészült.
Mi is történik ilyenkor a háttérben?
A történet valahogy úgy kezdődik, hogy valakinek ötlete/problémája/megvilágosulása támad, és kitalálja, hogy mi lenne ha nem így lennének a dolgok hanem úgy. Ezt rögtön le is írja, aztán elküldi valahová.
Itt kezdődnek a problémák – hova kell címezni az ötletet? Lehet küldeni mondjuk a Helpdesknek, el lehet küldeni a „központba”, a főnöknek, vagy az is lehet, hogy a cég külön web portálon gyűjtögeti a változás kérelmeket.
És itt jön az első meglepetés: a változáskérelmek kezelését elsősorban nem az IT végzi. Még mielőtt bármit is tenne az IT, előbb valakinek az üzleti oldalon végig kell gondolnia, hogy a kérelem jogos-e, mik a kihatásai, és persze mi a prioritása. Ugyanis nem egy kérelem jön, hanem egyszerre nagyon sok – sokkal több, mint amennyit meg lehet csinálni. Ezért az igényeket szűkíteni és priorizálni kell (ez a szomorú valóság).
Azt az embert, aki ezt a szűrést és priorizálást végzi, alkalmazás gazdának nevezhetjük (application owner, szemben a szintén alkalmazás gazdának fordított application admin-nal). Ő az, aki üzleti és folyamat oldalról kiválóan ismeri a szoftvert, képes elválasztani az ocsút a búzától, és a szűkszavú értelmetlen igényből értelmes kérelmet faragni.
A priorizálás eredményeképpen előáll egy feladat-lista a legfontosabb igényekkel, amiket az üzlet és az IT heti rendszerességgel átnéz. Ha egy feladat elkészül, akkor az üzlet megrendel egy új igényt, és felteszi a listára.
Az IT számára a munka akkor kezdődik, amikor ez a „rendelés” megtörténik. A munka kap egy felelőst (csúnya szóval erőforrást), és hajrá. Ez jelenti a „projekt” kezdetét: kielemezzük az igényeket, tervet készítünk, megírjuk a kódot, teszteljük, kirakjuk a teszt környezetbe a szakértők részére, majd ha az üzlet jónak találja, akkor telepítés.
Amennyiben az IT kiszervezte a fejlesztést, úgy a folyamat a következőképpen módosul: kielemezzük az igényeket, terveket készítünk, a tervet elküldjük a fejlesztőknek, a fejlesztők megírják a kódot, szólnak hogy kész, leteszteljük a megoldást, aztán kirakjuk a teszt környezetbe a szakértők részére.
Általában a folyamat legkritikusabb része az üzleti validálás. Főleg mert az üzleti felhasználók nem szoktak ráérni, ezért rohangálni kell utánuk. (Általában az igény csak addig fontos, amíg meg nem rendelik, aztán már nem érnek rá vele foglalkozni…)
Az IT annyi változáskérelmet tud megoldani, amennyi erőforrás (fejlesztő, rendszerszervező) áll rendelkezésre, és amennyire ezek a kollégák ráérnek. Gyorsabban dolgozni szimplán anyagi kérdés – fel kell venni plusz embereket. Ezért a tipikus IT-s csapat túlterhelt, és egy csomó igény várakozik érintetlenül. (Ha nem így lenne, akkor majd jön valaki és leoptimalizálja a költségeket)
Amikor valakinek 1 év múlva szólnak, hogy megvalósult a kérése, akkor nyilván az történt, hogy a kérés bekerült valamilyen prioritással egy listára, és ennyi ideig tartott felküzdeni magát a lista elejére.
Ha valaki gyorsan szeretne egy igényt megvalósítani, akkor nem feltétlenül az IT-val kell beszélnie, hanem azzal a menedzserrel, aki priorizál, és valamilyen módon meggyőzni az igény fontosságáról (ez lehet egy jó benefit statement vagy egy pofa sör).
A nagyon nagy ötletekből projekt lesz, és az egészen másképp alakul.
Utolsó kommentek