Deliv­ery do pro­dukce nes­tačí: tech­no­log­ická a orga­ni­za­ční trans­for­ma­ce banky v praxi

Ban­ka dnes není finanční fir­ma s IT pod­porou, ale tech­no­log­ická fir­ma posky­tu­jící finanční služ­by. Každý pro­dukt, každý pro­ces a každá inter­akce s klien­tem jsou zprostřed­kovány soft­warovým sys­témem. Pokud tech­nolo­gie nefun­gu­jí, nefun­gu­je ban­ka. 
Tato per­spek­ti­va zásad­ně mění pohled na roli IT. Přestává být pod­půrnou funkcí, stává se primárním pro­dukčním prostřed­kem. Rozhod­nutí o architek­tuře, způ­sobu vývo­je nebo orga­ni­za­čním nas­tavení týmů tedy pří­mo ovlivňu­jí schop­nost banky konkurovat. 

Jed­ním z klíčových témat je trans­for­ma­ce servis­ního mod­elu. His­toricky se velké banky vyví­je­ly kanálově – poboč­ka měla své pro­cesy, call cen­trum, dig­itál­ní kanál další. Výsled­kem byla para­lel­ní imple­men­tace téže logiky v různých sys­témech. Z čehož plynu­la nejen rozdíl­ná zákaznická zkušenost, ale také vysoká míra provozní komplexity. 

Česká spořitel­na se rozhod­la ten­to mod­el opustit a sjed­notit obsluhu klien­ta přes jed­nu plat­for­mu – George. Zásad­ní myšlenk­ou je, že klien­tův George je zároveň bankéřův George. Bankéř tedy nepracu­je v interním para­lel­ním sys­té­mu, ale se ste­jným rozhraním, které vidí klient. Pouze má rozšířená oprávnění. 

Tech­nicky to zna­mená výrazné omezení dup­likací busi­ness logiky, kon­sol­i­daci inte­gračních vrstev a sjed­no­cení pro­ces­ního mod­elu. Orga­ni­za­čně to zna­mená, že ban­ka i klient pracu­jí s jed­ním zdro­jem infor­ma­cí, dat ap. Tím se zároveň reduku­je infor­mační asyme­trie, která byla his­toricky pro bankovní sek­tor typická. 

Další výrazné téma se týká struk­tu­ry vývo­jových týmů. V kla­sick­ém enter­prise prostředí vzniká přirozená ten­dence ke kra­jní spe­cial­izaci. Prob­lém je rozdělen mezi řadu rolí: prod­uct own­er, cus­tomer jour­ney expert, design­er, ana­lytik, devel­op­er, tester, ser­vice own­er. Každá role má svůj výřez odpověd­nos­ti a mezi nimi vzniká série han­doverů. 
Každý han­dover zna­mená ztrá­tu kon­tex­tu. Devel­op­er dostává speci­fikaci v nástro­ji typu JIRA, ale nemusí rozumět původ­ní­mu prob­lé­mu ani strate­gick­é­mu záměru. Tester validu­je imple­mentaci, aniž by byl součástí původ­ní diskuse o hod­notě. Daný řetězec opti­mal­izu­je lokál­ní části pro­ce­su, nikoli celek. 
Výsled­kem je para­dox: Orga­ni­zace disponu­je nedozírným intelek­tuál­ním kapitálem, ale ten je frag­men­tován, doslo­va převáděn na ​„drobásky“. Mozková kapaci­ta týmu se nevyužívá naplno, pro­tože lidé nej­sou pří­tom­ni klíčovým rozhodnutím. 

Reakcí na ten­to stav je zjednodušení struk­tu­ry týmů. Mís­to pale­ty rolí se mod­el reduku­je na tři zák­lad­ní: prod­uct man­ag­er, prod­uct design­er a engi­neer. Cílem není zjednodušení pro zjednodušení, ale odstranění zbytečných mezivrstvových předávek. 

Engi­neer přestává být ​„imple­men­tační jed­notk­ou“, stává se plno­hod­not­ným účast­níkem návrhu řešení. Je zapo­jen do diskuse o prob­lé­mu, o hod­notě i o způ­sobu doručení. Ten­to mod­el se při­b­ližu­je star­tupové­mu prostředí, kde si tým nemůže dovolit luxus hluboké spe­cial­izace a kde odpověd­nost za výsledek nese oprav­du každý. 

Nejde přit­om jen o rychlost dodání. Jde o kval­i­tu řešení. Pokud je tech­nický pohled pří­tomen už při návrhu, lze přede­jít řadě architek­ton­ick­ých slepých uliček a zbytečných kompromisů. 

Zají­mavým prvkem trans­for­ma­ce je také návrat klíčového know-how do orga­ni­zace. V určité fázi byla ban­ka sil­ně závis­lá na externistech, kteří byli čas­to jed­iní, kdo dispono­val kri­t­ick­ou znalostí sys­témů. Interní role se reduko­valy na objed­návkovou funkci. 
Ten­to mod­el je krátkodobě pohodl­ný, avšak dlouhodobě nebezpečný. Orga­ni­zace ztrácí schop­nost rozumět vlast­ním sys­témům, stává se závis­lou na doda­vatelích a ztrácí ino­vační kapac­i­tu. Insourc­ing více než stovky inženýrů není jen per­son­ál­ní změ­na, ale strate­gické rozhod­nutí o zachování kom­pe­tencí uvnitř firmy. Externí kapac­i­ty mají smysl jako doplněk, nikoli jako nosi­tel klíčového know-how. 

Nejzásad­nější myšlenk­ou celého rozhovoru je odmít­nutí metriky ​„nasazeno do pro­dukce“ jako ukaza­tele úspěchu. V mno­ha velkých orga­ni­za­cích se právě deliv­ery stává hlavním cílem. Pro­jekt je považován za úspěšný ve chvíli, kdy je funkcionali­ta nasazena. 

Reali­ta je však jiná. Hod­no­ta vzniká až v okamžiku, kdy klient řešení používá a kdy mu přináší měřitel­ný přínos. Mezi imple­men­tací a skuteč­nou adopcí může být dlouhé období iter­ací, komu­nikace a úprav. 

To vyžadu­je změnu role prod­uct man­agera. Nes­mí být pouze koordiná­torem dodávky, musí být vlast­níkem hod­no­ty. Musí pra­co­v­at s daty, defi­no­vat out­come metriky a dlouhodobě sle­dovat, zda pro­dukt skutečně plní svůj účel. 

Umělá inteligence je vnímá­na nikoli jako mód­ní vlna, ale jako struk­turál­ní změ­na. Nejde jen o autom­a­ti­zaci dílčích úloh. AI zásad­ně rozšiřu­je možnos­ti jed­notlivých rolí. Engi­neer může gen­erovat kód, vali­dovat návrhy nebo autom­a­ti­zo­vat testování. Man­ažer získává ana­lyt­ick­ého part­nera schop­ného rych­le struk­tur­ovat problémy. 

Což ovšem zároveň klade vyšší nároky na adapt­abil­i­tu zaměst­nanců. Tech­no­log­ická bar­iéra už čas­to není hlavním omezením. Omezením je ocho­ta lidí změnit způ­sob práce. Orga­ni­zace tak musí kom­bi­no­vat tech­no­log­ick­ou adop­ci s kul­turní změnou. 

Z rozhovoru je patrné i vědomí rizika nad­měrné kom­plex­i­ty. Velké orga­ni­zace mají ten­den­ci dělat mno­ho věcí para­lel­ně. Dostatek zdro­jů para­doxně vede k překom­bi­no­vaným řešením. Scarci­ty – omezení zdro­jů – může být zdravým korek­tivem, který nutí pri­or­i­ti­zo­vat. 

Trans­for­ma­ce tedy není jen o škálování, ale o schop­nos­ti říct né a soustřed­it se na něko­lik klíčových ini­cia­tiv, které mají skutečný dopad.