Sok tanácsadó kimutatta már, hogy 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, vagy kevesebbet foglalkoztak vele, hogy miért bukik el. Szerintem a válasz nem az, hogy "rossz technológiát választottak" - és nem is "nem volt elég a budget." A valódi okok sokkal inkább szervezetiek, folyamatiak, és őszintén szólva - előre láthatóak. Legalábbis ha az ember eleget látott belőlük. (Mire gondolok? Hogy a projekt definiyció, a feladatkijelölés a probléma. Egyszerűen nem olyan célt foglamaz meg a projekt ami reális, illetve illeszkedik a tényleges célokhoz., de alább egy kicsit részletesebben)
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. Mindenki találkozott már ilyen szituációval: Ez IT projket, legyen az IT a gazdája, végezze ő stb.
Egy nagyvállalati biztosítónál a digitalizációs projektet az IT osztály vezette. A projekt célja: egy 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 párhuzamos ellenőrzési lépések é silőszerű működés mind megmaradtak. (Az akorábbi papíralapú lépések kerültek leképezésre...kb csak" elektronikus papírt" hozott létre a projekt...)
A digitalizáció nem a folyamat tükrözése digitális eszközökbe. A digitalizáció, a folyamat újragondolása kell hogy legyen, új modell kialakítása, amelyen az üzlet és az IT együtt kell hogy dolgozzon, az elejétől.
Pénzügyi szektbeli tapasztalatból: a legtöbb digitalizációs projekt ott bukik el, ahol az IT "megkapja" a feladatot az üzlettőll, és megcsinálja, amit kérnek. Anélkül hogy valaki feltette volna a kérdést: de tényleg ezt hogyan szeretnénk a jövőben csinálni? (Persze mondhatjuk, ma már ilyen nincs, ezt mindenki tudja/érti....de sajnos nem. Még mindig élő probléma.)
2. ok: Nincs gazdája az üzleti igénynek, vagy nem fordít rá elég erőforrást
Ez szorosan kapcsolódik az első okhoz, de kicsitmás a mechanizmus.
A project sponsor (általában) 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. (Itt most nem konkrét üzleti elemzőre gonoolok, hanem arra az üzleti tema-re, aki "összerakja", hogy mi is a projekt scope-ja, belső tartalma stb.)
A pénzügyi szektorbeli projektek egyik leggyakoribb bukási mintája: a specifikációt egy belső projektmenedzser vagy egy külső tanácsadó írja meg , -aki ismeri a módszertant, de nem ismeri mélyen a biztosítási folyamatot, vagy a banki alkalmazásarchitektúrát., folyamatot. 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. (Nem elég mély és alapos, vagy egyszerűen tűrgyi tévedéseket tartalmaz.)
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és hiánya, é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. (Ezt persze nem úgy kell elképzelni, hogy egyeltalán nem vesz részt az üzleti folyamatot valóban értő szakértő, hanem esetleg nem elég keeretben, nem elég mélyen...vagy egyszerűen csak a kész specifikáció nem megy át utólag a kezén, még a fejlesztés előtt.) Az okok lehetnek azok, hogy egyszerűen sürgős, és úgymond nem ér rá, vagy csak egyszerűen a specifikáció mindig késésben van., és a fejlesztés elindul még az üzleti validálás előtt..
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 amival lehet együtt élni, de az üzleti végcélt (Real time adatk) nem éri el. Ez persze csak egy példa volt, valószínüleg lehet jobbat is találni,de a lényeg, hogy van egy olyan elem a folyamatban, aminek a változtatása nélkül nem lehet ténylegesen megváltoztatni a státus quo-t
A tanulság: a legacy rendszer állapotát és korlátait (Vagy bármely rendszer korlátait) a digitalizációs projekt legelején kell feltérképezni , ezt pontosan bemutatni, és nenek tudatában folytatni a projektet... és nem a fejlesztés közepén, amikor már nincs visszaút...és megint cska lesz egy lezárt projekt, de az üzlet nem lesz maradéktalanul elégedett.a kezdeti cél nem valósul meg...
4. ok: A változásmenedzsment utólag jön , ha egyáltalán jön
A digitális transzformáció nem csak IT projekt, hanem 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, felhasználói oktatásra. Az éles bevezetés előtt egy "tréning" és egy "kommunikáció" checkbox kerül a projekttervbe , és ezzel le van tudva. A felhasználók meg hirtelen szembesülnke, egy új felülettel, folyamattal stb.
Pénzügyi szektorbeli 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 projekt siker definíciója technológiai, nem pedig üzleti
"A rendszer élesbe ment." "A projekt határidőre lezárult." "A budget 95%-on teljesített."
Ezek IT, vagy legalábbis technikai, sikermutatók. Nem üzleti sikermutatók.
Az üzleti sikermutató: "A hitelelbírálás á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., ezzel a 7%-al kevesebb adminisztrációs erőforrásra van szükség"
Ha a projekt elején nincs definiálva hogy mi a mérési pont, illetve mi a siker kirtériuma, 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. (Ez kapcsolódik az első pontban elírtakhoz: MÁr a projekt elején meg kell határozni, hogy mit szeretnénk elérni, hogy mi a cél...).
Ami mégis működik
Az objektivitás kedvéért: A felmérések szerint 30% a sikeres projektek aránya, és 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 meghatározó szereplő erőforrása a projektre van allokálva, az igényeknek megfelelően.) A rendszerarchitektúra feltérképezve az architektúra döntés előtt. A siker KPI-k üzleti mutatókban definiálva vannak a projekt elején. A változásmenedzsment a technológiai fejlesztéssel párhuzamosan zajlik ,és 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.
Szigorúan ragszkodunk ahhoz, hogy az üzleti kulcsszereplőkkel egyeztetni tudjunk, és meghatározzuk , hogy mennyi erőforrásra van szükségünk az egyes szerepkörökből.
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 szektorbeli 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 szektorbeli 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
