Hogyan ne hajtsuk végre informatikai rendszerünk migrációját?

2021.01.29.
Egyre több vállalat lép a digitális transzformáció útjára és dönt a meglévő rendszereinek modernizációja mellett annak érdekében, hogy fejlessze üzleti folyamatait és növelje az ügyfeleinek nyújtott szolgáltatások minőségét.

Egyre több vállalat lép a digitális transzformáció útjára és dönt a meglévő rendszereinek modernizációja mellett annak érdekében, hogy fejlessze üzleti folyamatait és növelje az ügyfeleinek nyújtott szolgáltatások minőségét.

Ilyenkor a már meglévő régi informatikai rendszereinek teljes adatállományát át kell „emelnie” az újba, azaz rendszermigráció végrehajtására kerül sor.

Nem mindegy azonban, milyen minőségű IT rendszermigráció megy végbe. Ugyanis egy nem teljes vagy akár hibás rendszer migráció vállalatcsoportszintű, költséges és hosszútávú károkat okozhat, ahogyan ez a brit TSB Bank esetében 2018-ban történt, amikor levált a Lloyds Banking Group (LBG) rendszeréről, hogy áttérjen a felvásárló spanyol Banco Sabadell által alkalmazott szoftverre.

Mi volt a hiba? Cikkünkben röviden bemutatjuk a banki szakemberek rémálmaiba illő hibákat, elemezzük a problémás döntéseket, és áttekintést adunk arról, hogyan lehetett volna helyesen migrálni a banki IT rendszereket, és elkerülni a CEO lemondását.

Baljós árnyak

A TSB Bank migrációs projektje már a kezdetektől fogva problémákkal küzdött, nem volt megfelelően előkészítve.

Egy komplex legacy rendszer átalakításáról volt szó, melyre mindössze csupán egy szűk, 18 hónapos időkeretet szántak, amely természetesen túlcsúszott a tervezett határidőn, – közel 70 millió fontos többletköltséget okozva, mivel a régi rendszer használatáért továbbra is fizetni kellett az LBG-nek.

A projekt másik alapvető hibája az volt, hogy nem voltak világosan megszabva a hatáskörök, és az új rendszer szakértői nem kaptak hozzáférést a régihez.

„Houston, we have a problem”

Az igazi bajok azonban a rendszer élesítésétől kezdődően jelentkeztek. Az indulás után szinte azonnal elszabadult a pokol: hiba lépett fel (1) a banki tranzakciók utalásánál, (2) az ügyfelek nem tudtak hozzáférni a számlájukhoz, (3) sokan más ügyfél számlájának adataihoz fértek hozzá, (4) irracionális összegek jelentek meg a számlákon és egyéb hasonló esetek történtek.

Természetesen özönlöttek a panaszok, az ügyfélszolgálat egy idő után már nem is bírta kezelni; a Twitter is az elégedetlen ügyfelektől volt hangos, és a sajtó is cikkezni kezdett az incidensről – ami az eset méretét és súlyosságát tekintve nem meglepő. Mindezek tetejébe a brit pénzügyi ombudsman és a londoni pénzügyi szektor magatartási normáinak betartatására hivatott hatóság, a Financial Conduct Authority (FCA) is eljárást indított a TSB Bank ellen.

Kapcsolódó:  Miért és hogyan építsük be a digitális transzformációt a vállalati kultúrába?

A CEO lemondásra kényszerült

Mikor egyértelművé vált, hogy a kialakult káoszos helyzet nem lesz megoldható házon belül, a vezetőség az IBM egyik szakértői csapatához fordult segítségért. Az általuk készített jelentésből kiderül, hogy a banki IT rendszer migrációs projekt mérete és komplexitása magas kockázatot jelentett, ennek megfelelően „világszínvonalúan szervezett tervezés és rendszerezett tesztelés” lett volna elvárt.

Az IBM azonban nem találta nyomát mindennek, sem az éles üzembe helyezés szigorú követelményrendszerének. Egyes elméletek szerint a rendszer összeomlásának oka az lehetett, hogy a próbaüzemek tesztelése nem volt teljeskörű, ennek ellenére a vezetőség mégis az éles üzembe helyezés mellett döntött: kockáztatott és vesztett.

Az eset következményeként a bank CEO-ja, Paul Pester lemondásra kényszerült.

Megelőzhető lett volna a baj?

A TBS Bank esete nagyon tanulságos példa arra, hogy mennyire fontos a megfelelő tesztelés és milyen katasztrofális következményekkel jár, ha elmarad. Ahogyan az IBM is megállapította: sokkal átfogóbb, a helyzetek széles spektrumán javítani képes tesztelési folyamatokat kellett volna alkalmazniuk.

Automatizáljuk a tesztelést

A tesztautomatizációval mindez elkerülhető lett volna, hiszen a szoftver által tesztelt szoftver sokkal megbízhatóbban képes kiszűrni az esetleges hibákat, és sokkal nagyobb valószínűséggel lehet probléma nélkül migrálni az IT rendszereket.

A manuális tesztelésnek is megvan a maga helye és funkciója, de a hiányossága is. Egy ekkora projektnél, mint amilyen a TBS Bank rendszerének migrációja volt, a manuális tesztelés túl nagy hibahatárral dolgozik.

Egyrészt a tesztek ismételt kézi végrehajtása hamar monotonná válik, ami megnöveli a hiba átcsúszásának esélyét az emberi tényezőnek köszönhetően. Emellett idő- és erőforrásigényes, tesztautomatizációval ugyanannyi idő alatt nagyobb számosságban hajthatók végre tesztfutások a manuális teszteléshez képest.

Összességében az automatizált tesztelés jobban tesztelt alkalmazást eredményez, ami alapvetően szükséges a TSB jellegű helyzetek megelőzéséhez. A bolgár DSK Bank a rendszereinek migrálásakor emiatt bízta meg az automata tesztelés megtervezésével és levezénylésével a ProofIT és a KPMG szakembereit.

Kapcsolódó:  Mi a kapcsolat a koronavírus-járvány és a tesztautomatizálás között?

Időfaktor: tesztfuttatások automatikus kiértékelése

Ha jobban tesztelt egy IT rendszer, nagyobb mélységben ismerhetők fel a lehetséges kockázatok. Talán, ha a TSB vezetői tisztában lettek volna azzal, milyen kockázatot vállalnak az élesbemenetellel, inkább vártak volna még vele, vagy a részleges bevezetést választják.

Egy szoftver mélyebb megismerésében segítségre lehetnek bizonyos tesztautomatizációs eszközök – mint amilyen a ProofIT Kft. terméke, a hazai fejlesztésű ACE (Automated Conformance Evaluation) is. Ezekkel az eszközökkel a tesztfutások azonnal, automatikusan kiértékelésre kerülnek, riportálhatók, így folyamatos visszajelzést kaphatunk a tesztelt alkalmazás állapotáról.

Ennek a visszacsatolásnak köszönhetően lehetőség van a megalapozottabb döntéshozatalra, melynek következményeképp az éles üzembe kikerülő hibák már ismertek lesznek és van kidolgozott stratégia a kezelésükre. Így elkerülhető, hogy olyan helyzet alakuljon ki, amikor már külső szakértő bevonására van szükség.

Azonban érdemes megjegyezni, hogy tesztautomatizációnál számolni lehet azzal, hogy hasonló, drasztikus hibából kevesebb lesz, mivel a lehetséges rendellenességek már a fejlesztés korai szakaszában detektálhatók, így könnyebben és kisebb költséggel javíthatók. Ezáltal kiszámíthatóbbá válik a működés, ami a jövőbeni kockázat felméréséhez is nagyban hozzájárul.

ACE: Az átállást segítő szoftver

Amennyiben a vállalata egy új rendszer bevezetése előtt áll, a TSB története tanulságos példa lehet számára. Sosem küszöbölhetők ki teljesen a váltással járó kockázatok, de megfelelően megtervezett és kivitelezett teszteléssel kontrollálhatók.

A ProofIT Kft. azért hozta létre az ACE tesztautomatizáló termék- és szolgáltatáscsomagot, hogy az ilyen komplex folyamatok során megbízhatóan és könnyedén segítse az átállást.

Forrás:

  1. Case Study 2: The Epic Meltdown of TSB Bank
  2. TSB failed to test IT system properly, suggests IBM

CÍMKÉK  
A cikk szerzője

ProofIT

Teljeskörű tesztautomatizálási szolgáltatás és infrastruktúra: tesztautomatizálás a tervezéstől a kivitelezésen át az eredmények kiértékeléséig. A ProofIT Kft. széleskörű szolgáltatásokkal és tesztelési infrastruktúra kiépítésével nyújt segítséget elsősorban nagyvállalatok, állami szervezetek számára több mint tíz éve.
LEGNÉPSZERŰBB cikkek

Sorry. No data so far.

© 2018 ProofIT Kft. Minden jog fenntartva. / All rights reserved.
linkedin
Share This