Minden ember hajlamos az önámításra, aktuális helyzetének, körülményeinek sajátos értelmezésére annak érdekében, hogy jobban érezze magát a bőrében, és ne kelljen szembesülnie a felmerülő, megoldandó nehézségekkel. Nincsenek ezzel másképpen a rengeteg kihívással szembesülő informatikai vezetők sem, akiknek rendkívül gyorsan változó technológiai és üzleti világban kell folyamatosan helytállniuk.
Bob Lewis, a CIO.com magazin munkatársa az iróniát sem nélkülözve olyan lehetséges önámítási esetekről számol be , amelyek során az informatikai vezetők hajlamosak a valóságosnál jobb színben feltüntetni a dolgok állását nemcsak közvetlen munkatársaik és a vállalat többi részlegénél dolgozó kollégáik, hanem saját maguk számára is.
Igazodunk az üzleti tevékenységhez. Sajnálatos módon mérettől függetlenül nagyon kevés olyan vállalkozás létezik, amelyik igazodik saját magához, inkább a részlegek közötti széthúzás jellemző rájuk. Az informatikai részleg igazodása többnyire a felsővezetők megnyugtatásából és költségtérítési rendszer bevezetéséből áll. Az utóbbi azt jelenti, hogy az IT mindent megcsinál, amire megkérik, feltéve, hogy az igénylők finanszírozzák a projektet. A költségtérítés révén az informatikai részleg nem az üzleti tevékenységhez igazodik, hanem a vállalat költségvetéséhez. Jó, ha ez összhangban van az üzleti célokkal, ha viszont nincs, az majd másvalakinek lesz a problémája.
Csak akkor érdemes upgrade-elni a szoftvereket, ha az új verzió fontos üzleti értéket képvisel. Ez az állítás nemcsak meggyőzően hangzik, hanem "főnökiesen" is. Joggal feltételezheti bárki: az így gondolkodó CIO pontosan tisztában van azzal, milyen befektetések szolgálják hatékonyan a vállalat üzleti érdekeit, és nem szórja a pénzt feleslegesen. Ráadásul ennek a szemléletnek köszönhetően csökkenthető az IT-költségvetés, mivel nem kell pénzt fordítani a dolgok naprakész állapotban tartására.
Az ilyen véleményt magukénak valló CIO-k sohasem éltek át mindent felforgató, több technológiai generáción átívelő továbbfejlesztést, így fogalmuk sincs arról, mivel jár majd annak a levezénylése. Márpedig a szoftverfrissítések preventív karbantartásnak tekinthetők. Ha most elspóroljuk a fejlesztést, később megfizetjük majd az árát, és az sokkal drágább lesz.
Késésben van egy kritikus projekt? Majd a következő fázisban behozzuk a lemaradást. Az üzleti szituáció ilyenkor általában az szokott lenni, hogy bárki ötlete is volt a projekt, úgy tervezték meg, mintha a táblázatkezelőket még fel sem találták volna. Addig trükköztek az adatokkal, amíg elfogadható megtérülés nem jött ki, továbbá meggyőzték magukat arról, hogy a módosított feltételek teljesíthetőek, ha egy kis szerencséjük és jó hátszelük lesz.
Minél nagyobb a projekt, annál több váratlan nehézség léphet fel, tovább bonyolítva a megvalósítást. A szükségletek és specifikációk meghatározásának fázisa mindig sokáig szokott tartani, de sebaj, mondják, mindenki tudja, hogy minél alaposabb a tervezés, annál kevesebb idő kell majd a kódoláshoz és a teszteléshez.
Aztán, ahogy az már lenni szokott, az IT alkalmazkodik a vállalathoz, a tervezés jobbról balra halad, vagyis meghatározzák a projekt befejezésének határidejét, és időben visszafelé készítik el az ütemtervet. Ilyenkor a projektmenedzser kellemetlen feladata, hogy addig alakítgassa az ütemezést, amíg az mindenki számára végrehajthatónak tűnő állapotba nem kerül.
Ha a "gondos" tervezés ellenére mégis csúszna a projekt, a leleményes projektmenedzserek két dolgot szoktak tenni. Először is lerövidítik a tesztelési időszakot, minek eredményeképpen ismét megvalósíthatóvá válik a határidős befejezés, és minden résztvevő arca fényre derül. Másodszor, intenzív álláskeresésbe kezdenek, még mielőtt a reputációjukat teljesen kikezdené a projekt nem megfelelő irányítása.
Elérkeztünk a tesztelés első fázisához, amelyre rossz esetben az a jellemző, hogy újradefiniálják, mit értenek elég jó minőség alatt. A követelmények lazításának és a befolyásolásnak köszönhetően a legrosszabb kód is átmegy az ellenőrzésen. Ezután következik a második, átfogó tesztelési időszak, amelynél rendkívül fontos tényező, hogy az alapos vizsgálat a szoftver gyártásba kerülése előtt vagy az után történik-e meg.
Ha a dolgok végképp rosszra fordulnak, új CIO veszi át az informatikai részleg irányítását, hogy elkerüljék a katasztrófát. Elődje a projektmenedzsert teszi felelőssé a kudarcért, aki az anonim alkoholisták összejöveteleit látogató alkoholfüggőkhöz hasonlóan projektmenedzsment-kurzusokon képezi tovább magát.
Agilis fejlesztést végzünk. Egyes informatikai részlegek áttértek a vízesés fejlesztési modellről egy vagy több agilis technikára, vagy pedig éppen zajlik náluk ez az átalakulás. Az agilis szoftverfejlesztési módszertant magukévá tevő csapatok túlnyomó része azonban az úgynevezett agilefall modell valamelyik formáját követi, vagyis amellett, hogy agilis próbál lenni, megtartja a vízesés modell egyes elemeit. Ráadásul szakértők szerint az agilefall csapdát elkerülő IT-részlegek fele szintén másik irányba ment, és nem tartja magát az agilis módszertanhoz. Esetleges, rendszertelen (haphazard) fejlesztést végez többnyire egy, a vízesés modell mellett elkötelezett vezető utasítására, aki már az áttérés megkezdése előtt meg volt győződve arról, hogy az agilis módszertan eleve kudarcra van ítélve, és mindent megtett azért, hogy ez a jóslata beteljesüljön.
Devops fejlesztést végzünk. Dehogyis, még csak agilis fejlesztést sem végeztek! Az igazság az, hogy a devopsszal kapcsolatos összes híresztelés ellenére nem a módszer hívei fedezték fel az együttműködést. Az agilis modell - az igazi, nem az agilefall - már jóval a devops megjelenése előtt támogatta az együttműködést, de az igazsághoz tartozik, hogy általában nem az IT-üzemeltetéssel működtek együtt a fejlesztők.
Hogy mit tesz hozzá a devops az agilis módszertanhoz? Először is a fejlesztői csapatok pusztán önző megfontolásból IT-üzemeltetőkkel bővültek, mivel nem akarták megvárni, amíg az illetékesek létrehozzák a környezetüket, és elvégzik a szükséges szoftverváltoztatásokat. Másodszor, mindenhol automatizálnak, ami számottevően növeli a munka hatékonyságát. Harmadszor pedig a devops esetében - a legtöbb agilis módszertől és a vízesés modelltől eltérően - a szoftver mindig telepíthető állapotban van. Ez azt jelenti, hogy a Scrum és a devops nem teljesen kompatibilisak egymással, a Kanban jobban működik.
IT-kormányzási folyamataink biztosítják, hogy csak a nagy üzleti értékű projekteket valósítsuk meg. Az IT-kormányzás hivatott arra, hogy csak a legnagyobb értéket teremtő projekteket finanszírozzák. Ám függetlenül attól, hogy milyen jól dolgozták ki a folyamatot, kedvezőtlen esetben olyan emberek fogják megvalósítani, akik nem igazodnak tökéletesen egymáshoz.
Ráadásul az egyes projektek üzleti értékének becslésekor különféle háttéralkuk és egyes technológiákkal, módszerekkel szembeni ellenérzések befolyásolhatják a döntéshozatalt. Vegyük hozzá még ehhez azt a bosszantó tényezőt is, hogy a költségcsökkentést eredményező projektek elsőbbséget élveznek a bevételnövelő projektekkel szemben. Ennek oka az, hogy a költségcsökkentési folyamat a vállalat irányítása alatt áll: ha mindent a tervek szerint hajtanak végre, csökkennek a kiadások. A bevételek növekedéséhez viszont az szükséges, hogy a vásárlók azt tegyék, amit mi akarunk, márpedig ez nem feltétlenül következik be. Nem vagyunk a főnökük, meg kell győznünk őket.
Információbiztonságunk szilárd. Még 2013-ban a Target áruházlánc 40 millió vásárlójának adatait lopták el annak ellenére, hogy a vállalat eleget tett a fizetőkártyás iparág PCI biztonsági szabványában előírt követelményeknek. Mindez azt bizonyítja, hogy a folytonosan változó kiberbiztonsági állapotok közepette senki sem ülhet a babérjain, folyamatosan fejleszteni és aktualizálni kell a kibertámadásokkal szembeni védelmet.
Amennyiben a CIO úgy gondolja, hogy vállalata információbiztonsága szilárd, valószínűleg téved. Inkább annak az informatikai vezetőnek a védelmi rendszere van megfelelő állapotban, aki amiatt aggódik, hogy lehet néhány biztonsági rés az infrastruktúrában.
