Ha az IT-projektekkel kapcsolatos kutatásokat nézzük az elmúlt tíz évből, mintha évről évre ugyanazt a tanulmányt olvasnánk újra és újra függetlenül a készítőktől: az IT-projektek több mint kétharmada kudarcba fullad. Boston Consulting Group: a digitális átalakítási projektek 70 százaléka nem éri el a tervezett célját. 2020 Mainframe Modernisation Business Barometer Report: négy cégből háromnak nem sikerül befejeznie a korszerűsítési projektjeit. McKinsey: a nagy informatikai projektek 70 százaléka kudarcos...
Ebből egy dolgot biztosan levonhatunk: az IT-projektek kockázatosak, és bármennyire is előkészítjük, nincs garancia a sikerre. Azaz egy IT-projekt egy nagy vállalakozás. Lehetünk optimista vállalkozó, aki örül, ha tíz projektjéből három sikeres – és az a három nagyot is dob az üzleten. Vagy játszhatunk maximális biztonságra, de az elérhető maximális nyereség egy a hagyományos üzleti igényeket megbízhatóan kiszolgáló IT lesz. (Ez utóbbi sem kevés!)
Kudarc = nem hozza a maximumot
A legtöbb esetben egyébként közel sem ilyen sarkosan csapódik le egy projekt kimenetele, mint ahogy az az elemző cégek tanulmányaiban megjelenik. Egy projektet ugyanis sokszor már akkor is sikertelennek minősítenek, ha csak részeredményeket tud felmutatni, vagy nem egészen ott segít, ahol eredetileg várták, de amúgy az eredmény beépül a vállalati folyamatokba.
De mi az oka, ha teljesen félremegy a fejlesztés? Összeszedtük a leggyakoribb okokat.
1. Nem tudja a bal kéz, mit csinál a jobb. Addig eljut a CIO, hogy az üzleti és informatikai szempontot összehangolja, csak épp ez a felső vezetés szintjén marad. A szervezet egésze viszont nem érti, hogy mi miért történik. A technikai megvalósítás kiváló, csak épp az a részleg nem tudod arról, hogy ezzel a projekttel neki is dolga lenne, amely például adatokat kellene vigyen ebbe az új rendszerbe. Az eredmény az alsóbb szervezeti szintek együttműködésének hiányában: kudarc.
Éppen ezért kellene nagyobb figyelmet fordítani a változáskezelésre (ezt a szervezetek kétharmada építi bele a projektjeibe): a projekt közvetlen és közvetett érintettjeinek, végső soron pedig minden alkalmazottnak el kell fogadnia a kitűzött célokat. Mert ha nem, akkor majd megfúrják az elkészült rendszert a projektcsapat győzelmi jelentése után. Az eredmény: sok fölöslegesen kidobott pénz és kudarc.
2. Nem a működő szerver a siker mértéke. Mindig előre meg kell határozni, mi a cél, és az soha nem lehet IT-cél. Az nem digitális transzformáció, hogy telepítjük a legújabb frissítéseket, csupán alap a megbízható működéshez. A siker mérőszámait az üzleti szempontok alapján érdemes meghatározni, és nem csak a tűzijátékos teljes sikert, hanem a részsikereket is. Így kisebb a kudarc lehetősége is, és a részeredmények is jobban integrálhatók a folyamatokba.
Ehhez kapcsolódik a kockázatelemzés: minden projektnek és a projekt során hozott döntésnek is van kockázata (pénzügyi, szervezeti, működési vagy technikai). Ezeket mindig elemzeni kell, és fel kell készülni a kezelésükre is.
A rutinos projektmenedzserek egyébként 60 százalékos célt tűznek ki, és az agilis szemlélet jegyében teret engednek a folyamatos alkalmazkodásra és optimalizálásra. Így a menet közben pontosodó igények is beépülhetnek a projektbe. A rosszul meghatározott mérőszámok (a részcélokhoz is) eredménye: kudarc.
És még egy: ha korszerűsítés a cél, a legtöbbször el kell felejteni a régi technológiát. Lovaskocsiból nem lehet Ferrarit építeni, még akkor sem, ha lecseréljük a zabmotoros hajtást benzinmotorosra. Ha a vezetés ragaszkodik a régihez, az eredmény borítékolható: kudarc.
3. Az a fontos, amit a főnök reggel kitalált? Sok projekt bukik el azon, hogy nincsenek megfelelően priorizálva a feladatok. Így aztán az üzlet ad hoc igényei beelőzhetnek – sokszor keresztbe húzva egy hosszabb távú fejlesztési projektet is. Az eredmény egyértelmű: kudarc.
Ahogy az IT nem tudja meghatározni egyedül az üzleti célokat és mérőszámokat, úgy a legagilisabb környezet sem alkalmas arra, hogy az üzlet egyedül döntsön technológiai kérdésekben. Ha az IT-t szolgai végrehajtó szerepbe kényszerítik, olyan technológiákra pazarolja el a vállalat a fejlesztési forrásait, melyek legfeljebb az üzlet egy kisebb területét elégítik ki. Összességében az eredmény: kudarc.
Hajlamosak vagyunk túlbonyolítani
Végül, de nem utolsósorban: a bonyolult dolgok ritkán jók. Ha valahol, a projektek esetében hatványozottan igaz, hogy mindig legyen kéznél Occam borotvája. Ha egy viszonylag egyszerű feladat minden részleténél a legjobb példákat szeretnénk beépíteni, akkor általában kapunk egy túlárazott, a tervezettnél sokkal hosszabb idő alatt elkészülő, nehézkes vagy akár használhatatlan rendszert. Az eredmény tehát: kudarc.
Az IT-projektek erőforrás-tervezésénél egyre inkább figyelembe kell venni, hogy szakemberekből kevés van. A CIO-k világszerte kemény versenyt folytatnak a megfelelő emberekért a munkaerőpiacon. Mindezt tetézi, hogy sok ágazatban idén erősödő pénzügyi szigorra lehet számítani. Ebben a helyzetben pedig sokkal fontosabbá válik az erőforrások megfelelő kiosztása, illetve a projektek részeredményeinek a hasznosítása is.
Költségcsökkenésből finanszírozott modernizáció
A cloud-native alkalmazások megkövetelik az adatközpontok modernizációját, amihez a SUSE többek között a virtualizációs költségek csökkentésével szabadítana fel jelentős forrásokat.
CIO kutatás
Merre tart a vállalati IT és annak irányítója?
Hiánypótló nagykép a hazai nagyvállalati informatikáról és az IT-vezetőkről: skillek, felelősségek, feladatkörök a múltban, a jelenben és a jövőben.
Töltse ki Ön is, hogy tisztábban lássa, hogyan építse vállalata IT-ját és saját karrierjét!
Az eredményeket május 8-án ismertetjük a 17. CIO Hungary konferencián.
Projektek O-gyűrűje. Mit tanulhat egy projektvezető a Challenger tragédiájából?