Piše: Domagoj Markovina
Ako pogledamo aplikativnu arhitekturu gotovo bilo koje banke srednje veličine, u pravilu ćemo naći dvije stvari koje dobro funkcioniraju i jednu koju je teže odrediti.
Aplikativni sloj prema klijentima uglavnom dobro funkcionira. Mobilna aplikacija i internetsko bankarstvo dobro su osmišljeni i responzivni, a kontakt centar ima moderno radno sučelje. Desetljeće ulaganja u digitalizaciju osiguralo je da ovaj sloj bude pouzdan i u većini banaka to i jest.
Core sustavi su pouzdani; platforme često nemaju baš najbolje korisničko iskustvo – ali u pravilu dobro rade ono za što su namijenjene.
Između ta dva sloja odvija se stvarni bankarski posao – i u većini banaka to je sloj koji zapravo nikad nije sasvim dovršen.
Postoji i PDF verzija ovog teksta, s dijagramima arhitekture, ako vam je lakše za čitanje ili dijeljenje: Preuzmite PDF.
Sloj u kojem nastaju ishodi za klijente
Middle office je operativni sloj smješten između kanala koje klijenti dodiruju (front office) i core sustava gdje se odvijaju novčane transakcije (back office). To je mjesto gdje ispunjeni zahtjev postaje račun, pritužba postaje rješenje, a korporativni upit postaje ugovor.
U većini banaka to nije jedan koherentan sloj. To je skup rješenja sastavljenih tijekom vremena: kontakt centar, BPM za automatizaciju otvaranja računa, ponešto robotske automatizacije, jedan ili više alata za upravljanje predmetima, zajedničke email grupe za internu email komunikaciju ispod svega toga. Mnogo je toga doista dobro napravljeno – sami za sebe sustavi rade i isporučuju specifičnu funkcionalnost. Rađeni su u različito vrijeme, na različitim platformama iz različitih razloga i stoga nisu povezani se u jedan, vlastiti sloj nego ostaju nepovezana “točkasta” rješenja.
To je ono na što ljudi često misle kad govore o naslijeđenim (legacy) sustavima u operativi. Naslijeđe obično nisu pojedinačni sustavi – većina ih je u redu. Naslijeđe je zapravo izostanak promišljene arhitekture iznad njih.
To je važno jer je upravo ovaj sloj mjesto gdje korisničko iskustvo zapravo nastaje. Tekući račun nije redak u sustavu depozita. To je korisničko iskustvo njegovog otvaranja, korištenja, problema s njim i rješavanja tog problema. Ako je korisnička aplikacija prozor, core sustav knjiga, onda je middle office je ono što klijent doživljava kao banku.
Zašto je ovaj sloj tako često fragmentiran?
Da odmah razjasnimo – jer je sve ovo lako shvatiti kao kritiku ljudi koji su gradili te sustave – ovo nije kritika. Tamo gdje je operativni sloj fragmentiran, to nije rezultat ničije namjere, nego obično predvidljiv rezultat ograničenja koja su izvan kontrole IT odjela.
Budžeti se obično odobravaju za ono što je lako vidljivo, opipljivo i shvatljivo. Projekti za kanale komunikacije vidljivi su upravi i lakše dobivaju sredstva. Operativni sloj iza njih teže je pokazati, opravdati i time teže financirati pa se poboljšava u koracima, a ne kao samostalna cjelina.
Core sustav često se nije smio dirati. Kratki prozori za promjene i stvarni rizik na core sustavima gurali su operativnu logiku prema van, u alate koje je bilo manje riskantno mijenjati. Fragmentacija je tada često bila odgovoran, ako ne i jedini izbor.
Poslovne jedinice obično su kupovale pojedinačne alate za rješavanje konkretnih problema. Svaki je rješavao stvaran lokalni problem, no bez jedinstvenog arhitekturnog mandata – izolirano to su razumne odluke, koje u konačnici proizvedu šarenilo platformi, sustava i procedura.
Spajanja tvrtki su bankarski sustav slagala jedan na drugi. Integracije ostavljaju banke s nekoliko preklapajućih sustava. Konsolidacija je višegodišnji program, rijetko dovršen do kraja prije nego što stigne zahtjev za novom promjenom.
Ništa od ovoga nije kritika – to je jednostavno kontekst u kojem se posao odvijao. Pitanje nije “zašto ovo nije odmah napravljeno kako treba”, nego “s obzirom na to kako je moralo biti građeno, što ćemo napraviti sada da postane koherentno?”
Gdje se manjak “middle officea” vidi?
Budući da u pravilu nitko ne budžetira za „middle office“ kao zasebnu stavku, trošak nepovezanosti dijelova obično se pojavljuje u drugim brojkama.
Pokazuje se u otvaranju računa. Znatan dio digitalnih zahtjeva zapne negdje između podnošenja zahtjeva i aktiviranog računa – dokument koji nije stigao do pravog tima, provjera koja je zapela, ručni korak koji se nije odradio. Svaki zastoj ima svoje logično, opravdano objašnjenje. Zajedno opisuju sloj koji u praksi ne postoj niti funkcuionira kao jedan sloj nego niz kao nepovezanih događaja.
Pokazuje se u broju poziva u kontaktni centar koji ne pada unatoč ulaganjima u digitalnu transformaciju. Klijenti zovu jer se nešto u operativnom sloju nije dovršilo ili je dovršeno na krivi način. Poziv je simptom, a uzrok je uzvodno.
Pokazuje se u pritužbama, gdje stope ponavljanja ne padaju čak i nakon novog sustava za pritužbe, jer rješavanje i dalje ovisi o procesima u drugim, odvojenim sustavima. Pritužba se zabilježi i proslijedi, ali se problem često rješava na razini simptoma, a ne uzroka.
Pokazuje se u regulatornom opterećenju. Regulatorna pravila pretpostavljaju da se izvršavanje operativnih procesa može dosljedno dokazati i revidirati. Sloj raspršen po brojnim alatima može zadovoljiti taj kriterij, ali obično uz mnogo više ručnog rada nego što bi trebalo.
Najskuplji manjak se vidi u transformacijskim programima koji ne pomiču metriku na temelju koje su odobreni. Uglađena nova aplikacija na fragmentiranom operativnom sloju može postati samo brži put do istih kašnjenja i grešaka. Uprava vidi poboljšanje kanala, a klijent nepromijenjeno vrijeme čekanja na rješavanje problema. Zatvaranje tog jaza gotovo je uvijek problem middle officea, a ne kanala komunikacije.
Ista pritužba, u dva operativna modela
Pokušajmo to konkretizirati. Razmotrimo što se događa s jednom pritužbom u dvije različite banke – a većina banaka nalazi se negdje između to dvoje.
U prvoj se pritužba evidentira u jednom sustavu, e-poštom šalje timu na rješavanje, a njezino rješenje ovisi o podacima u drugim sustavima koje osoba mora tražiti. Često se rješava na razini simptoma, a regulatorno izvješćivanje rekonstruira se naknadno. Na kraju njime upravlja marljivost uključenih ljudi, a ne sustav.
U drugoj pritužba prolazi kroz definiran proces prihvata i kategorizira se prema aktualnoj taksonomiji. Usmjerava se pravom timu s vidljivim regulatornim rokom. Zadužena osoba (ili AI Agent) vidi cjelovitu povijest klijenta. Potrebna komunikacija generira se prema rokovima. Ako zapne, automatski se eskalira. Podaci o uzroku bilježe se na strukturiran način, a regulatorni izvještaj ažurira se u stvarnom vremenu.
Isti događaj unutar dva različita operativna modela. Cilj nije skočiti iz prvog u drugi preko noći, nego napraviti iskorak u pravom smjeru.
Što koherentan sloj zapravo radi?
Umjesto popisa stvari u kojima banka podbacuje, ovo je korisnije kao tiha dijagnostika. Koliko od ovoga vaš trenutni ustroj radi, i koliko dosljedno kroz različite procese? Većina banaka neke od ovih stvari radi dobro na nekim mjestima. Obrazac toga gdje drže, a gdje pucaju obično je karta onoga što treba prvo popraviti.
Koherentan operativni sloj radi pet stvari:
1. Orkestrira posao – zna što se mora dogoditi, kojim redom, tko to radi, prema kojim rokovima i s kojim sustavima povezanim u tijek procesa. Pitanje koje treba postaviti jest rade li vaši procesi od početka do kraja ili zastaju na rubovima svakog od alata.
2. Drži zapis o procesu uz zapis o klijentu – zapis o samom radu: u kojoj je fazi, što ga blokira, što je odlučeno, tko je odlučio i prema kojem pravilu. Test je možete li rekonstruirati predmet bez da pitate ljude koji su ga vodili.
3. Donosi pravi kontekst pravoj osobi – agent, službenik za usklađenost i voditelj operacija svaki vide isti temeljni zapis kroz prikaz prilagođen njima, umjesto da rade s odvojenih, nepovezanih ekrana.
4. Eksplicitno upravlja iznimkama. Većina procesa puca ne na uobičajenom putu, nego u neuobičajenih 5–15% slučajeva. Sloj koji vodi samo idealan tijek gura svaku iznimku u improvizirani ljudski rad, a tu leži najviše troška i najviše neuspjeha.
5. Koherentan sloj se mijenja brzinom poslovanja, a ne brzinom core sustava. Promjene pravila, propisa i proizvoda prvo padaju u operativni sloj. Mora biti dovoljno konfigurabilan da ih brzo upije. Pitanje je koliko vam dugo treba da danas dodate korak u aktivni tijek rada – i koliko brzo to može biti u produkciji.
Kako sloj učiniti promišljenim?
Promišljen middle office je strateška prednost. Slučajan je tihi, ponavljajući porez na svaki digitalni program i svaki regulatorni ciklus.
Dobra je vijest da je postizanje cilja obično manje dramatično nego što zvuči. Za mnoge banke to nije potpuna zamjena. To je konsolidacija – dovođenje operativnog rada u jedan konfigurabilan sloj koji orkestrira između komunikacijskih kanala i core sustava, pri čemu zapis o klijentu nastaje kao nusproizvod dobrog vođenja posla, a ne kao stvar na koju je sve ostalo pričvršćeno.
Platforme koje to rade se ponekad nazivaju inteligentnom automatizacijom procesa, a ponekad low-code poslovnim platformama. Mi bismo je opisali jednostavnije – kao middle office operativni sloj. Vodeće platforme imaju unificiranu arhitekturu, umjesto sastavljanja ukupnog rješenja akvizicijom: tretiraju proces i zapis o klijentu kao jednako važne, i ostaju dovoljno konfigurabilne da ljudi koji vode procese mogu te procese mijenjati. Poanta je zauzeti stav prema sloju kao ključnom gradivnom dijelu poslovne IT arhitekture – što ponekad znači novu platforma, a često znači koherentnije korištenje onoga što već imate.
Gdje počinje razgovor?
Nema jednog ispravnog odgovora, jer ovisi o banci. Neke trebaju konsolidirati pojedinačne alate u jednu platformu. Neke trebaju koristiti više onoga što već imaju. Nekima je najbolje krenuti s jednim procesom visoke vrijednosti – pritužbe, otvaranje računa, šteta – i graditi sloj odatle prema van.
Ono od čega svaka banka ima koristi jest postaviti pitanje prije nego što se opiše rješenje.
1. Gdje naš operativni sloj zapravo danas stoji i koji dijelovi već dobro rade?
2. Jesu li ti dijelovi povezani u jedan sloj ili rade jedan pokraj drugog?
3. Što bi trebalo da cijela stvar postane koherentna i koliko je od toga konsolidacija, a ne zamjena?
4. Što bi se promijenilo za klijenta da to učinimo?
Ako su pitanja poviše korisna, tu počinju razgovori koje treba voditi. Pitanje platforme dolazi kasnije – a ponekad je pošten odgovor da više koristite platforme koje već imate.
Ako želite porazgovarati o tome gdje je vaš operativni sloj danas i što bi trebalo napraviti da postane koherentan – radimo s klijentima upravo na ovakvoj vrsti problema.
Možete zadržati ili podijeliti i dizajniranu verziju ovog teksta, s dijagramima: Preuzmite PDF
Razgovarajte s našim timom
