A legnagyobb üzleti kockázat egy nagyvállalati rendszer mögött ritkán egy technológia vagy egy szállító. Az a tudás, ami csendben kisétál a cégből, és amit a legtöbb szervezet csak akkor vesz észre, ha már baj van. A jó hír, hogy ez a tudás visszanyerhető, és nem csak emberek fejéből.
Van egy pillanat, amit a legtöbb nagyvállalati IT-vezető ismer. Egy értekezleten elhangzik egy kérdés a saját rendszerükkel kapcsolatban: „ha ehhez a folyamathoz hozzányúlunk, az érinti X-et?”, „ki tudjuk-e váltani ezt a modult anélkül, hogy a számlázás megakadna?” A válasz pedig csend, egy bizonytalan vállrándítás, vagy az ismerős mondat: „ezt igazából csak Sanyi tudja, de ő most már igazgató, nem ér rá.”
Ez nem hanyagság és nem rossz vezetés, hanem egy szervezeti mintázat, ami szinte minden 10-15 éve épülő nagyvállalati rendszer mögött kialakul. Ennek a mintázatnak neve is van: kulcsemberi függőség. Érdemes komolyan venni, mert minden hónappal többe kerül.
Hogyan vész el észrevétlenül egy nagy rendszer tudása
Egy nagyobb enterprise rendszer fejlesztése jellemzően egy összeszokott, viszonylag szűk csapattal indul. Tíz évvel később ennek a csapatnak már csak töredéke van a cégnél: a többiek elmentek, nyugdíjba mentek, vagy vezetőként már nem foglalkoznak a részletekkel. Helyettük új fejlesztői generációk dolgoznak a rendszeren, akik csak részeit ismerik. Aki öt éve van bent, sokszor csak a felét látja, vagy annál kevesebbet.
Közben létezik egy másik illúzió: a „van dokumentációnk”. A valóságban általában van valami: külső szállítóktól örökölt anyagok, Excel-táblák halmazai, különböző időszakokból származó Confluence-oldalak, gyakran egymásnak ellentmondó információkkal. Egy részükre rá lehet támaszkodni, más részük aktívan félrevezet, és ránézésre nem mindig lehet eldönteni, melyik melyik.
A rendszer mai, tényleges működése ezért két helyen él: a kódban, és néhány ember fejében. A kód a megbízhatóbb forrás, de senki nincs, aki teljes egészében átlátná, mert egyszerűen túl nagy. Az emberi tudás pedig törékeny: egy szabadság, egy kilépés, egy szervezeti átszervezés egy nap alatt ki tud venni az egyenletből egy olyan szereplőt, akiről senki nem gondolta előre, hogy ennyire kritikus.
A valódi kockázat nem technológiai, hanem emberi és üzleti
A következmények eleinte csak a fejlesztői csapatban érződnek, aztán megjelennek mindenhol, ahol a vezetőt mérik.
Minden új fejlesztés átfutási ideje megnyúlik, mert előbb meg kell érteni, mihez nyúlunk. Minden audit és szabályozói megfelelés tovább tart, mert tényeket kell kibányászni a kódból, nem dokumentumokból olvasni. Minden modernizációs vagy folyamat-átalakítási döntés bizonytalanságban születik, és a bizonytalanságnak külön ára van: vagy túlbiztosítjuk a projektet és sokat költünk, vagy alulbecsüljük, és menet közben derülnek ki a meglepetések.
Aztán ott van a szállítói viszonyok kérdése. Ha a rendszert mi vásároltuk, és a szállító ismeri jobban, mint mi magunk, abban a tárgyalásban nem egyenlő felek vagyunk. Az árajánlatok megkérdőjelezhetetlenek, a kilépés költsége kiszámíthatatlan, és a „mi lenne, ha házon belül megoldanánk” forgatókönyv ködbe vész, mert nem tudjuk pontosan, mit is kéne megoldani.
És a legkonkrétabb pont: ha abból a néhány emberből, aki még fejből tudja, hogyan működnek a kritikus folyamatok, egyetlenegy felmond holnap, abból a következő negyedéves projekttervek átírása lesz. Ezt jellemzően csak utólag mérjük fel.
A lényeg ennyi: ami „csak” hiányzó dokumentációnak tűnik, az valójában mérhető üzleti kockázat, amit fel lehet vinni a board elé, ha van rá nyelvünk és van rá megoldási irány.
A tudás visszanyerhető, és nem csak emberek fejéből
A jó hír, hogy ez a fajta tudás nem örökre veszett el. Ott van, ahol a rendszer valójában él: a kódban, a folyamat-definíciókban, az adatbázis-sémában, a konfigurációkban. A kérdés sokáig az volt, hogy mindezt emberi erővel ki tudja-e bányászni belőle valaki; nagy rendszereknél a válasz többnyire nem.
Az elmúlt egy-két évben ez a kérdés más helyzetbe került. Az AI ma már képes arra, amire egyetlen ember egyedül nem: átolvasni, kategorizálni, összekötni és összefüggéseiben értelmezni egy százezres nagyságrendű kódbázist. A folyamat-szintű leírások visszafejthetők, a folyamatok közti kapcsolatok feltérképezhetők, a használaton kívüli részek azonosíthatók.
Egy lényeges megkötéssel: ennek csak akkor van valódi értéke, ha az eredmény ellenőrizhető és visszavezethető a kódra. Egy generikus AI-eszköz egy átláthatatlan rendszerre ráengedve magabiztosan rossz válaszokat is fog adni. Találhat 30 indítható folyamatot ott, ahol valójában 140 van. Egy ilyen tévedés rosszabb, mint a „nem tudom”, mert hibás állításokra épülnek üzleti döntések. A jól megépített megközelítés ezért determinisztikus, tényekre épülő alapra teszi az AI-t: minden állítás a forráskód egy konkrét pontjához köthető, és egy szakértő napok alatt le tudja ellenőrizni a kimenetet.
Az eredmény nem egy újabb dokumentációs könyvtár, amit senki nem olvas, hanem egy élő, kereshető, ellenőrizhető tudásréteg a rendszerről. Ha holnap megkérdezik az értekezleten, hogy „ha hozzányúlunk X-hez, mi mást érint”, a válasz nem csend lesz, hanem egy konkrét lista, mögötte forráshivatkozásokkal a kódra.
És ezt nem évek alatt kell felépíteni. Egy jól körülhatárolt, fájdalmas területen (egy modul, egy folyamatcsoport, egy konkrét migrációs kérdés) hetek alatt eljuthat egy szervezet odáig, hogy a következő nagy döntését már megalapozottan, nem találgatva hozza meg.
Kulcsemberi függőség: a legdrágább kitettség
A nagyvállalati rendszerek mögött a legdrágább függőség ritkán szállítói. Sokkal inkább az a néhány ember, aki még fejből tudja, hogyan működik az egész, és akiknek a kilépése csak idő kérdése.
És kevés olyan kockázat van, ami akkor is nő, ha semmi nem történik: minden eltelt hónappal közelebb van egy nyugdíjazás, egy felmondás, egy átszervezés.
Van ennek egy kevésbé nyilvánvaló következménye is. A kódból visszafejtett tudást valakinek ellenőriznie kell, és erre azok a legalkalmasabbak, akik a rendszert még fejből ismerik. Amíg ők itt vannak, a visszanyert tudás hitelesíthető; utánuk már csak az marad, amit a kód önmagában elmond.
Hol érdemes elkezdeni
Ha ismerős a helyzet a saját rendszereiteknél, az első lépés nem egy projekt, hanem egy tárgyszerű kép arról, hol van ma a legnagyobb kitettség. Készítettünk ehhez egy rövid önértékelőt: 6 dimenzió mentén (a kulcsemberi függőségtől a változtatási kockázaton át a compliance-ig), kizárólag a saját válaszaidból rajzol board elé vihető kockázati profilt. Az eredményt adatmegadás nélkül látod, és ha jól álltok, azt is őszintén megírjuk.
Ha pedig már egy konkrét modul vagy folyamatcsoport körül forog a kérdés, szívesen átnézzük közösen egy rövid beszélgetésen.
