Ön is volt már végeláthatatlanul hosszúra nyúló döntési szituációban? Volt már, hogy nem tudott szakmailag megalapozott elképzelésekhez pénzt szerezni? Futott már hosszú köröket az engedélyezési procedúrák miatt? Volt már, hogy ez miatt nagy baj történt? Ha nem, lehet, hogy eddig csak szerencséje volt...
Előző számunkban a humán kockázatokról írtunk. Mostani írásunk egy szintén kevéssé tárgyalt területet, az életciklus nem megfelelő kezeléséből eredő kockázatokat veszi górcső alá a Comair történetén keresztül.
A Comair esete egy klasszikus működési kockázatmenedzsment hiba, ami a légitársaság számára több mint 20 millió dolláros veszteséget okozott nem beszélve a hírnevén esett csorbán.
Hogy kezdődött?
Amikor Eric Bardes 1997-ben csatlakozott a Comair IT csapatához, az egyik legelső megbeszélésen, amin részt vett a téma egy régi rendszer leváltása volt, amivel a cég a járatok személyzetét menedzselte.
Az alkalmazás, amit az SBS International szállított az egyik legrégebbi volt a vállalatnál (akkor 11 éve üzemelt). Az alkalmazás Fortran nyelven írodott (amelyik nyelvhez a cégnél akkoriban igazán már nem értett senki) és ez volt az egyetlen rendszer, ami a cég régi IBM AIX platformján futott (a többi alkalmazás már HP Unix-on).
Az SBS felajánlotta, hogy cseréljék le a rendszert az új Maestro elnevezésű személyzet menedzselő termékére. Az egyik járatszemélyzet felügyelő már használta ezt az első generációs alkalmazást. Az ő véleménye az volt, hogy még a legrosszabb ellenségének sem ajánlaná a programot.
A meglévő menedzsment rendszer tényleg nem volt elegáns, de a felhasználók már megszokták a kezelését és a Comair meglévő üzleti folyamatainak nagy része erre épült rá.
A megbeszélésen az a konszenzus alakult ki, hogy ha a Comair lecseréli a meglévő rendszerét és felvállalja ennek költségeit és kockázatait, akkor egy sokkal kielégítőbb megoldás jöhet csak szóba.
És vártak...
A lehetőség, hogy lecseréljék a régi rendszert a szokásos módon áttolódott a következő évre. De ekkor sem történt semmi.
A következő néhány év során a Comair vezetését a felmerülő események eltérítették a probléma megoldásától: kezelni kellett a Y2K problémáját, a független társaságot felvásárolta a Delta Airlines, 2001-ben a pilóták sztrájkja nehezítette meg a cég helyzetét, és végezetül szeptember 11-e, melynek következtében szinte összedőlt az egész légiközlekedési szektor.
Amikorra végre jóváhagyták a régi rendszer lecserélését a Sabre Airline Solutions megoldásával, az áttérést nem sikerült idejében végrehajtani. A szabadságolási időszak alatt a rendszer meghibásodott, leállítva az egész társaságot 3900 járatot késleltetve és megszüntetve, illetve közel 200 000 utast a földre kényszerítve.
A hálózat összeomlása a Comair-nek és anyacégének a Delta Airlines-nak 20 millió dolláros kárt okozott és nagymértékben rombolta mind a két cég megítélését a piacon. Arról nem is beszélve, hogy az esemény miatt a Légiközlekedési Hatóság azonnali vizsgálatot indított a társaság ellen...
Történhetett volna máshogy?
Az egész katasztrófa elhárítható lett volna, ha a vállalat felméri, hogy ez az egy kritikus rendszer és az erre épülő folyamatok ilyen mértékű kockázatnak teszik ki a cég napi működését és megpróbálják kezelni ezt a kockázatot.
Ha egy kicsit is betekintünk az eset mögött lévő döntési folyamatokba, akkor ismerős történésekre derül fény:
- az operatív vezetők nem fontolták meg eléggé, hogy a régi rendszer cseréje kiemelt prioritású az üzletmenet folytonosság miatt
- az IT nem tett sokat azért, hogy felvilágosítsa a vezetőket nézetük veszélyes mivoltáról
Habár úgy nézett ki, hogy mindenki tisztában volt azzal, hogy foglalkozni kell a már elavuló alkalmazással és architektúrával, mely az üzleti növekedés alapját biztosította, a gyorsaság hiánya volt megfigyelhető.
A Delta által történt kivásárlás után a Comair IT vezetése nem készített egy az egész rendszerre kiterjedő átvilágítást, ami meggyőzhette volna az anyacéget arról, hogy sürgősen be kell ruházni egy új rendszerbe mielőtt még túl késő lesz. Ehelyett a Delta nyomás alatt tartotta a Comair költségvetését, ahogy ez ilyen esetben lenni szokott.
Az ekkorra már majdnem 20 éves rendszer hibája a Deltát nem csak az ügyfélszolgálat megbénulásával és a pénzügyi kiadások és jótállások miatti fejfájással sújtotta, hanem egy figyelmeztető történetet biztosított bármely olyan cég számára, mely azt hiszi, hogy üzletileg kritikus rendszereit bármikor üzemeltetni képes ... csak még egy nappal tovább...
A rendszer jól működött
Az elkövetkezendő években a Comair különféle alkalmazásokra tett szert a repülő személyzet irányító rendszeren keresztül az utas foglalási alkalmazásmotorig, hogy növelje versenyképességét.
Sajnos az alkalmazásokon nem látszik meg az idő, mint például a különböző fizikai munkaeszközökön. Ezeket a rendszereket márpedig úgy kell kezelni, mint a fizikai vagyontárgyakat.
Az alkalmazások évről évre törékenyebbé válnak, így kiemelt figyelmet kell fordítani karbantartásukra, megújításukra. Életciklus kockázatuk nagy veszélyt hordozhat magában!
Pedig a Comair IT vezetői külső tanácsadói segítséget vontak be a rendszerekkel kapcsolatos IT stratégia megvalósításához.
A tanácsadók megvizsgálták az IT infrastruktúrát és egy öt éves stratégiai tervet készítettek, mely kitért azokra a rendszerekre, melyek leváltásra, bővítésre vagy fejlesztésre szorulnak ezek megoldási javaslatainak projektterveivel egyetemben. A légiszemélyzet beosztását kezelő rendszer a leváltásra javasolt kategóriába esett.
Nem csak kockázatkezelési, de pénzügyi érvek is felsorakoztathatóak voltak a döntés mögé. Egy új, szofisztikáltabb rendszer pótlólagos megtérüléseket eredményez a légiszemélyzettel kapcsolatos költségek csökkentésében.
Apró léptekkel a szakadék felé
Ezek az események 1998-ban történtek és az IT figyelmét ekkor már a 2000. évi probléma megoldásával kapcsolatos tevékenységek kötötték le.
Mindeközben a Delta Airlines megvásárolta a Comair-t. Papíron minden nagyon szép volt, még az IT területen is. Terv szerinti elindított projektjeik voltak megfelelő költségvetési fedezetekkel alátámasztva. Minden úgy nézett ki, ahogy azt az ember látni szeretné.
A Comair az összeolvadás ellenére teljesen függetlenül fejlődött az anyacégtől, kivéve, hogy a beruházási terveket jóvá kellett hagyatni anyavállalati szinten.
Ekkor jött szeptember 11. és ennek hatásai. A Delta, bár nem ment csődbe, mint sok más kisebb nagyobb társaság, de bevételei 8,5 milliárd dollárral csökkentek 4 év alatt arra kényszerítve, hogy extrém mértékben csökkentse költségeit. Ebben az időszakban a Delta visszautasította a rendszer lecserélésére vonatkozó beruházási javaslatot. Több belelátást és kimutatást akartak a projekttel kapcsolatban.
Végül tárgyalások sorozata után a Delta megadta az engedélyt a beruházásra és 2004 júniusában aláírták a szerződést a Sabre-el. Az új AirCrews Operations Manager rendszer bevezetése 2005-re tevődött.
2004 december 16-án a Comair 25,7 millió dollár profitot jelentett a harmadik negyedévre vonatkozóan.
Egy héttel később szokatlanul hideg téli időjárás köszöntött be sűrű havazásokkal. December 22-24-ig a járatok 91%-át kellett lemondani az időjárás miatt. A lemondások miatt a rendszer túlterhelődött és összeomlott. Ennek következtében karácsony napján a Comair-nek le kellett mondania mind az 1100 járatát az ünnepekre hazautazó utasok tízezreit kényszerítve megállásra. December 26-ig pedig a járatok 90%-a maradt a repülőtereken további utasok szabadságát gátolva.
Back up rendszer nem volt. A szállítónak több, mint egy napba került újraindítani a szoftvert, de az ütemezés még 29-én sem állt helyre.
Mik a tanulságok?
A Comair katasztrófája egy klasszikus esettanulmánya a működési kockázatok kezeletlenségének. Mind a Comair, mind a Delta részéről több hibát is elkövettek:
- A Comair IT szakértőinek kockázatelemzést kellett volna végezniük a rendszerrel kapcsolatosan és figyelmeztetni a Delta döntéshozóit a lecserélés elhalasztásának kockázatairól az üzletmenetre vonatkozóan.
- Ezen túlmenően ezt a felmérést többször is fel kellett volna terjeszteni, hogy érzékeltessék a javaslat fontosságát.
- Párhuzamosan a Deltának meg kellett volna vizsgálna a Comair belső működését és külön, függetlenül kockázatelemzést kellett volna készíttetnie a kitettségekről.
És ugyanez az eset a Deltával is előfordulhatott volna...
A nagyobb probléma az, hogy a működési kockázatok kérdéseit nem vonják be a vállalatok a napi döntéshozási folyamataiba.
Egy másik probléma, amit döntéshozói körben jól ismernek hazánkban is az, hogy a Comair IT vezetésének nem lett volna elég ismertetni több körben is a kockázatokat, hanem el is kellett volna azt adni mind a Comair vezetése, mind a Delta vezetése felé. Ez egy furcsa szituációhoz vezet: az IT és biztonsági részlegeknek meg kell tanulniuk nem csak felvetni a problémát, hanem el is adni a döntéshozói körnek. De erről majd később...
Az okok:
Ez az esettanulmány egy hosszú ideig húzódó döntési folyamat által kiváltott eseményt szemléltet. De nézzük meg milyen okok játszottak a háttérben szerepet:
- Egy olyan rendszer, amit egy 25 gépes légitársaság részére vezettek be, nem biztos, hogy ki tud szolgálni egy 1100 gépes társaságot is.
- Ráadásul több automatizált workflow épült a rendszerre, melyek egyre több terhelést jelentettek az architektúra számára.
- Abban egyetérthetünk, hogy a rendszer összeomlását nem a szoftver kora okozta. Viszont valószínűsíthető, hogy a rendszer nem volt kitesztelve ilyen mértékű terhelésre, ill. mivel a rendszer az üzleti tevékenység központjában volt, ezért sokszor bővítették, toldozták, foldozták, ami ismételten a kockázati faktorok számát növelte.
- Nem volt back up rendszer!!! Talán ezt a hiányosságot magyarázni sem kell.
- Nem elég, hogy nem létezett tartalék rendszer, de folytonossági terv sem készült rá, ezért az IT-t felkészületlenül érte a nem tervezett rendszerleállás. A szállítóval egyetemben kétségbeesetten próbálták újraindítani a rendszert, ahelyett hogy rögtön az alternatív eljárások alapján kezdtek volna dolgozni és így nem tényleges leállást, hanem csak késést szenvedtek volna el.
- A kompetencia hiánya. Ez viszont ténylegesen a szoftverkorából adódik. Minden IT szakember tudja milyen nehéz egy 20 éve fejlesztett rendszerhez értő szakembert találni, illetve mennyire nehéz kiképezni erre egy szakembert, aki ezt a tudását jószerivel sehol máshol nem tudja használni.
- Változással szembeni ellenállás elfogadása. Ellenérv lehet-e egy rendszer cseréje esetén, hogy az új rendszert mennyire fogadják el a felhasználók? A felhasználók egy idő után bármely rendszer használatát megszokják és megtanulják.
- Kérdés az is, hogy a felső vezetés mennyire volt elkötelezett az IT fejlesztése mellett?
Az IT-nek szüksége van üzleti ismeretekre. Nem csak technikai, hanem erős üzleti érveket is fel kell sorakoztatni a döntés előkészítésekor, pl. ROI megtérülések, üzleti hatáselemzés stb.
A kockázatok felmérése mindig üzleti döntés!
És hogyan előzhettük volna meg ezeknek az eseményeknek a bekövetkezését?
5 stratégiai lépés a kockázatok kezelésére
A vállalati kockázatmenedzsment (Corporate / Enterprise Risk Management - ERM) azt mondja, hogy közelítsünk a teljes szervezet oldaláról! Ezt a megközelítést nevezhetnénk JPÉ-nek is! (Józan Paraszti Ész)
Az ERM minden esetben a vállalati érdekekre és az üzletmenet folytonosságra fókuszál oly módon, hogy egyszerre láttatja a vállalatra ható kockázatokat (mind a belső, mind a külső kockázatokat) és ezeknek a kezelését stratégiai szintre emeli.
Minden informatikai vezetőnek egyre gyakrabban kell foglalkozni ezekkel a kérdésekkel, hiszen a vállalatok IT kitettsége ugrásszerűen nő, ezért az IT-nek mindennél nagyobb hatása van az üzletmenet folytonosságra.
De nem könnyű az érdekérvényesítés!
Sokan a szervezeten belül a kockázatok felszínre hozását egész egyszerűen kritikaként élik meg. Ezért a kockázatkezelés egyre inkább a vezetői kihívások része. Nézzük meg mely lépésekből kell állnia az informatikai vezetők ez irányú stratégiájának:
1. lépés
Találd meg az ösztönzés módját! Legyenek tisztában az informatikai szakértők az üzleti célokkal! Tudják meg, hogy munkájuk milyen hatással van a teljes szervezet üzleti eredményeire!
2. lépés
Fogalmazd meg tisztán miért fontos az ERM! Meg kell találni a módját az elvégzett feladat és az ehhez kapcsolódó üzleti kockázatok összekapcsolásának. A kockázat nem intrika, sem pesszimizmus!
3. lépés
Rugalmasság. Nem mindenki érti meg az adott kockázat fogalmát. A kockázatokat mindenki más aspektusból közelíti meg.
Nem megvitatni kell a kockázatokat, hanem oly módon kommunikálni, ami segíti a megértést.A vállalati intranet egy jól használható eszköz a tudatosság kialakításában. Ez sokban segítheti az IT-t a döntéshozók meggyőzésében.
4. lépés
Hagyd el az irodád! Fontos a többi területtel való kommunikáció, az információ begyűjtése, a célok más aspektusból való megközelítése. Ismerd meg a többi terület eredményeit! Ily módon sokkal jobban tudod fókuszálni üzeneteid, érveid a saját céljaid elérése érdekében.
5. lépés
Legyél te a minta! Cselekedeteid legyenek összhangban az üzeneteiddel. Ösztönözni kell a munkatársakat arra, hogy fedjék fel a gyenge pontokat.
"Azon a napon, melyen munkatársaid nem osztják meg a problémákat veled, elvesztetted a képességet, hogy vezesd őket" - Colin Powell, Védelmi Miniszter - USA
A kritikus szemlélet soha sem hátráltat. A kritika az ami a szervezetet mindig a jobb elérésére sarkallja!