A szám ismert. A cégek 70%-a megbukik a digitális transzformáció során - ez nem pesszimizmus, hanem iparági konszenzus. McKinsey, BCG, Gartner mind ugyanarra a következtetésre jutottak.
Ami kevésbé ismert: miért bukik el. Mert a válasz nem "rossz technológiát választottak" - és nem is "nem volt elég a budget." A valódi okok mélyen szervezetiek, folyamatiak, és őszintén szólva - előre láthatók. Legalábbis ha az ember eleget látott belőlük.
25 évet töltöttem pénzügyi szektorbeli vállalatok IT és üzleti oldalán - CIO-ként biztosítónál, fejlesztési és adattárház-vezetőként biztosítócsoportnál, igazgatósági tagként lízingcégnél. Ebből az időből 5 mintát hoztam magammal, amelyek újra és újra felbukkannak - és amelyek mindegyike megelőzhető lett volna.
1. ok: A transzformáció technológiai projektként indul - nem üzleti változásként
Ez a leggyakoribb és egyben a legköltségesebb tévedés.
Egy nagyvállalati biztosítónál a digitalizációs projektet az IT osztály vezette. A projekt célja: a kárrendezési folyamat digitalizálása. A technológiai megoldás kiváló volt: modern workflow rendszer, integrált dokumentumkezelés, mobilbarát felület. A projekt időben és budgeten belül lezárult.
Hat hónappal később a kárrendezési folyamat lényegében ugyanolyan lassú volt mint azelőtt. Miért? Mert a folyamat üzleti logikáját nem változtatták meg — csak digitalizálták a meglévő, rossz folyamatot. A papíralapú kárbejelentőt felváltotta egy digitális kárbejelentő de a mögöttes jóváhagyási szintek, a redundáns ellenőrzési lépések és a silók mind megmaradtak.
A digitalizáció nem a folyamat tükrözése digitális eszközökbe. A digitalizáció a folyamat újragondolása — amelyhez az üzlet és az IT együtt kell hogy üljön, az elejétől.
Pénzügyi szektoros tapasztalatból: a legtöbb digitalizációs projekt ott bukik el, ahol az IT "megkapja" a feladatot az üzlettől — és megcsinálja, amit kérnek. Anélkül hogy valaki feltette volna a kérdést: de tényleg ezt kell csinálni?
2. ok: Nincs gazdája az üzleti igénynek
Ez szorosan kapcsolódik az első okhoz — de más a mechanizmus.
A project sponsor a felsővezetésben van. A fejlesztők az IT osztályon. Valahol a kettő között — üresen — ott a hely ahol az üzleti elemzőnek kellene ülnie. Aki megérti amit az üzlet akar, és le tudja fordítani amit az IT meg tud csinálni.
A pénzügyi szektoros projektek egyik leggyakoribb bukási mintája: a specifikációt egy belső projektmenedzser vagy egy tanácsadó írja meg — aki ismeri a módszertant, de nem ismeri mélyen sem a biztosítási folyamatot, sem a banki rendszerarchitektúrát. Az eredmény: egy dokumentum amelyre mindenki sign-offot ad, de amelynek értelmezése 8 különböző fejlesztőnél 8 különböző kódot eredményez.
A BCG kutatásai szerint a digitális transzformációs projektek kudarcának egyik legdominánsabb oka az IT és az üzleti területek közötti együttműködési hiány — és ez különösen igaz a pénzügyi szektorra, ahol a termékek és folyamatok eleve összetettek. A bankok 55%-a szerint a meglévő rendszerek korlátai a legnagyobb akadály — de a rendszerek mögött ott vannak az üzleti folyamatok, amelyeket senki nem ért elég mélyen ahhoz hogy digitalizálja.
3. ok: A legacy rendszer "elefánt a szobában" -, és senki nem beszél róla
Minden pénzügyi nagyvállalatnál van egy vagy több rendszer amely évtizedek óta fut, amelyet senki nem mer megérinteni, és amely köré az összes többi rendszer felépült. Biztosítónál ez általában a core biztosítási rendszer. Banknál a core banking. Lízingcégnél a szerződéskezelő rendszer.
A digitalizációs projekt általában "köré" épít integrációs rétegeket, API-kat, új felületet. Ez nem feltétlenül rossz , de ha a legacy rendszer logikája diktálja az üzleti folyamatokat, akkor a digitalizáció valójában a legacy korlátait digitalizálja, nem az üzleti igényt.
Láttam ezt közelről. Egy biztosítónál az új digitális ügyfélszolgálati alkalmazás fejlesztése közben kiderült, hogy a core biztosítási rendszer nem tudja real-time visszaadni a kötvény státuszát , mert batch feldolgozással dolgozik. A fejlesztők megoldást találtak: cache réteget építettek. Az ügyfél "real-time" adatot lát , ami valójában 4 óránként frissül. Ez nem digitális transzformáció. Ez egy kompromisszum amit senki nem kommunikált az üzletnek.
A tanulság: a legacy rendszer állapotát és korlátait a digitalizációs projekt legelején kell feltérképezni , nem a fejlesztés közepén, amikor már nincs visszaút.
4. ok: A változásmenedzsment utólag jön , ha egyáltalán jön
A digitális transzformáció nem IT projekt. Szervezeti változás - amelynek az IT az eszköze.
Ezt elméletben mindenki tudja. A gyakorlatban a project timeline 90%-a a technológiára megy, és 10% sem marad a szervezeti felkészítésre. Az éles bevezetés előtt egy "tréning" és egy "kommunikáció" checkbox kerül a projektplánba - és ezzel le van tudva.
Pénzügyi szektoros vállalatoknál ez különösen kritikus, mert az érintett folyamatok általában compliance-érzékenyek. Az ügyintézők nem "lustáságból" állnak ellen az új rendszernek, hanem mert az új folyamat sérti a megszokott kontrollpontokat, és ők felelnek ha valami elromlik. Ha ezt a feszültséget senki nem kezeli előre, az ellenállás az éles bevezetés után manifesztálódik, és addigra a projekt "lezártnak" van könyvelve.
5. ok: A siker definíciója technológiai, nem üzleti
"A rendszer élesbe ment." "A projekt határidőre lezárult." "A budget 95%-on teljesített."
Ezek IT sikermutatók. Nem üzleti sikermutatók.
Az üzleti sikermutató: "A kárrendezési átfutási idő X napról Y napra csökkent." "Az ügyfélelégedettségi index N ponttal nőtt." "A manuális adminisztrációs lépések száma Z%-kal csökkent."
Ha a projekt elején nincs definiálva hogy mi a mérési pont — a projekt végén mindenki sikerként könyvelheti el azt amit valójában nem sikerült elérni. Ez nem szándékos megtévesztés — hanem a célok tisztázatlanságának természetes következménye.
25 év alatt megtanultam: az egyetlen kérdés amit a projekt legelején fel kell tenni az az, hogy "hogyan fogjuk tudni hogy sikerült?" — és a válasznak üzleti mutatóban kell megjelennie, nem technológiaiban.
Ami mégis működik
Az objektivitás kedvéért: a 30% amely sikerrel jár, rendszerint ezeket csinálja másképp.
Az üzleti igény gazdája azonosítva van — általában egy tapasztalt BA vagy belső product owner, aki mélyen érti a folyamatot és az IT korlátokat egyszerre. A legacy rendszer állapota feltérképezve az architektúra döntés előtt. A siker mérőpontjai üzleti mutatókban definiálva a projekt elején. A változásmenedzsment a technológiai fejlesztéssel párhuzamosan zajlik — nem utána.
Ezek nem rocket science megállapítások. Mégis az esetek 70%-ában valamelyik — vagy több — hiányzik.
Mit jelent ez a FrontX-nél
A FrontX digitalizációs projektjein az üzleti elemző nem "opcionális" -. hanem kötelező. Nem azért mert ez a "best practice" — hanem mert tapasztalatból tudjuk, hogy enélkül a projekt jó eséllyel a 70%-ba kerül.
Minden digitalizációs projekt előtt elvégezzük a legacy rendszer feltérképezést, az üzleti igény pontosítást, és a sikerkritériumok definiálást — mielőtt egyetlen sor kód születne. Ez nem lassítja a projektet — ez az ami lehetővé teszi hogy valóban lezáruljon.
Ha digitalizációs projektet tervezel pénzügyi szektoros környezetben — szívesen konzultálunk az első lépésekről: frontx.hu/kapcsolat
Gyakran ismételt kérdések
Miért bukik el a digitális transzformáció pénzügyi szektoros vállalatoknál?Az iparági adatok szerint a cégek 70%-a megbukik a digitális transzformáció során. A leggyakoribb okok: a transzformációt technológiai projektként kezelik üzleti változás helyett, nincs gazdája az üzleti igénynek, a legacy rendszer korlátait nem térképezik fel előre, a változásmenedzsment elmarad, és a siker mutatói technológiaiak maradnak üzleti helyett.
Miért különösen nehéz a digitális transzformáció biztosítóknál és bankoknál?Pénzügyi szektoros vállalatoknál a digitális transzformációt három tényező nehezíti különösen: az összetett, évtizedes legacy rendszerek amelyek köré az egész infrastruktúra épül, a szigorú szabályozói és compliance elvárások amelyek korlátozzák a mozgásteret, és a folyamatok domain-specifikus összetettsége — egy biztosítási termék vagy banki folyamat digitalizálásához mélyen kell ismerni a szektort. A bankok 55%-a a meglévő core rendszereik korlátait tartja a legnagyobb akadálynak.
Mi a különbség a digitalizáció és a digitális transzformáció között?A digitalizáció egy folyamat vagy dokumentum digitális formátumba konvertálása — pl. papíralapú kárbejelentő helyett digitális form. A digitális transzformáció ennél mélyebb: az üzleti folyamat újragondolása és átalakítása digitális eszközök segítségével. A leggyakoribb hiba: a meglévő, rossz folyamatot digitalizálják — ami digitalizáció, nem transzformáció.
Mikor érdemes üzleti elemzőt bevonni egy digitalizációs projektbe?A projekt legelején — nem a fejlesztés megkezdésekor. Az üzleti elemző feladata a valódi igény feltárása, a legacy rendszer korlátainak azonosítása, és a sikerkritériumok üzleti mutatókban való definiálása. Ha a BA csak a specifikáció írásánál kapcsolódik be, a projekt stratégiai döntései már meghozattak — és a BA csak a következményeket kezeli.
Hogyan mérhető a digitális transzformáció sikere?Nem technológiai, hanem üzleti mutatókkal: a folyamat átfutási ideje csökkent-e, az ügyfélelégedettség nőtt-e, a manuális lépések száma csökkent-e, a hibaarány javult-e. Ha a projekt sikerét az "élesbe ment" vagy "határidőre lezárult" határozza meg — az IT projekt volt, nem transzformáció.
Behán László a FrontX Kft. ügyvezetője és társalapítója. Korábban a Signal Biztosító CIO-ja, a Groupama Biztosító fejlesztési és datawarehouse vezetője, valamint a LeasePlan Hungaria igazgatóságának tagja volt operációs igazgatóként. 25 év IT és üzleti vezetői tapasztalattal rendelkezik a pénzügyi szektorban. Linkedin bio
