Iskustva iz projekta unapređenja procesa u finansijskoj instituciji 

Stojite iza žute linije i čekate da se na nekoj od tabli pojavi vaš broj ili da neko sa druge strane šaltera izgovori: „Sledeći!“ 

Prilazite, govorite da ste došli da otvorite račun i da ste prvi put u datoj banci, osiguravajućoj kompaniji – koji god primer rezonuje sa vama. Službenik traži lični dokument – a onda, u zavisnosti od vremenske prognoze, planetarnih uticaja i od toga u koju ste banku ušetali, prolazi najmanje 8 minuta do prvog pitanja koje vam službenik postavlja u vezi sa otvaranjem računa – a to je razlog vašeg dolaska, zar ne? 

Ipak, za vas, vreme kao da je stalo – najverovatnije niste ni primetili da je tih 8+ minuta prošlo, jer vam je u međuvremenu službenik postavio neka, možda čudna pitanja i predao da potpišete nekoliko papira, više ni sami ne znate koje.  

Vreme je stalo i za službenika – užurbano kuckanje na tastaturi se na momente prekida, uz upućivanje namrštenog pogleda u pravcu monitora, odlazi najmanje jednom do štampača i nekoliko puta ga neko prekida sa pitanjima, sa jedne ili druge strane šaltera.  

Šta je to što na šalteru traje najmanje 8, a često i preko 15 minuta? Jedni će reći „unos novog komitenta“, drugi „unos matičnih podataka klijenta“, treći „proces identifikacije“… ali da ne psujem dalje – ovoliko traje prikupljanje i unos vaših podataka u sistem, u cilju stvaranja osnove za sve dalje poslove koji će se odvijati između vas i banke u budućnosti.  

Možda 8 do 15+ minuta vašeg života ne zvuči toliko alarmantno, ali trajanje ove aktivnosti u kombinaciji sa aktivnostima koje slede nakon nje (npr. otvaranje računa, apliciranje za kredit, ugovaranje osiguranja i sl) mogu da vas kao klijenta na šalteru zadrže najmanje 30, 40 ili 60 minuta, a vas, kao službenika banke još više od toga. Drugo, aktivnost unosa, provere ili ažuriranja podataka o klijentu je početak svih ostalih procesa u datoj instituciji. Treće, nije problem samo u vremenu, već i u tačnosti, ažurnosti, korisnosti i upotrebl jivosti podataka. 

Mnogobrojni su uzroci ovakvog stanja 

– nije definisan vlasnik procesa i/ili nisu utvrđeni kriterijumi šta jeste, a šta nije matični podatak 

– podaci se prilikom izmena (zakona ili politike institucije) samo dodaju, ali retko kad se vrši kompletna revizijaili – podaci su deo nasledstva iz prethodnih sistema) 

– aplikacija za unos podataka je neprilagođena procesu, usled raskoraka između načina definisanja potreba od strane učesnika u procesu i shvatanja i tumačenja istih potreba od strane IT-a 

U nastavku teksta moći ćete da pročitate o iskustvima tokom analize ovog procesa i na koji način je vreme koje je potrebno za unos ovog seta podataka svedeno na 3 minuta. 

 

Dilema 1: Čiji sam ja podatak? Odakle dolazim? Kuda idem? 

 

Kako biste reagovali da vas službenik pita za devojačko prezime vaše majke? Zvuči savršeno logično, zar ne? Šalu na stranu, iako iza ovog polja postoji svrha, u današnje vreme postoje alternativni načini da se ona ostvari. Ipak, postojanje ovakvog polja se pokazalo izuzetno zabavnim i korisnim. Fenomen koji smo nazvali „Lakmus polje“ se pokazao kao odličan za započinjanje diskusija i podizanje dobre atmosfere prilikom usaglašavanja predloga za izbacivanje nepotrebnih polja sa drugim odeljenjima u kompaniji. Postavljanje simpatičnog pitanja: „Da li koristite i da li vam je potrebno polje devojačko prezime majke?“ govori samo za sebe.  

Zatečeno stanje u aplikaciji za unos matičnih podataka je sledeće: preko 200 polja, od kojih se neka popunjavaju, neka i preskaču, sa namerom ili bez nje. Tim uočava probleme počev od nejasne svrhe i nepoznatog korisnika polja, pa sve do problema u vezi sa dozvoljenim vrednostima, vrstom polja i mandatornostiParalelno sa definisanjem As-Is stanja i trenutnih problema, definisan je i To-Be izgled forme za unos podataka. Polje po polje, od rasprave zašto je za određeno polje bolji „radio button“, a ne „checkbox“, pa do ograničenja, kontrole i diskusije da li je samo mandatorno ili uslovno mandatorno Igre bez granica.  

Bilo je potrebno nekoliko dana kako bi se prošla sva polja koja sadrži forma za unos podataka i kako bi se ustanovilo As-Is i To-Be stanje i to samo za jednu varijaciju – „nov klijent koji je punoletni građanin sa prebivalištem i boravištem u državi X koji dolazi zbog posla Y 

Zašto samo jedna varijacija? Prvo, sam naziv koji smo varijaciji dodelili govori o razlogu. Drugo, zato što je za prvo mapiranje najvažniji fokus tima koji mapira. Pareto je zakon, tako da dobra osnova dobijena kvalitetnom analizom jedne varijacije garantuje dobru razradu ostalih varijacijaTreće, zato što se ispostavilo da postoji pet osnovnih varijacija (vrsta klijenata), a ne dve kako je prvobitno izgledalo.  

Nakon jasnog definisanja jedne glavne varijacije, uz pomoć matrice podatak vs vrsta klijenta“ definisane su potrebe ostalih varijacija i podvarijacija u smislu strukture polja (prikazivanja i mandatornosti).  

Utisak učesnika, dan 1: „Brzo ćemo ovo srediti“ 

Utisak učesnika, dan 2: „Nikada ovo nećemo završiti“ 

Zaključak faze: Odabir i razrada jedne varijacije je pravilo za započinjanje svih vrsta mapiranja. Pokazalo se da je prilikom „mikro mapiranja“ pogodnije paralelno raditi na As-Is i To-Be prikazu. 

 

Dilema 2: Zašto sam beše ovde? 

 

Koji su razlozi vaših dolazaka? U kojim ulogama se klijenti javljaju? Na koji način različite uloge u kombinaciji sa uticajem zakona i ostalih regulativa, direktiva i sl. utiču na set podataka koji se uzima od klijenta? 

Utisak učesnika, prva diskusija: „Postoji oko 10 razloga dolaska klijenta…“ 

Utisak učesnika, poslednja diskusija: „Postoji preko 30 razloga (uloga), ali još uvek brojimo…“ 

Na ovom mestu se nailazi na veliki problem. Većina aplikacija za unos matičnih podataka sa kojima sam se susrela do sad su izolovane od ostatka sistema. Šta je posledica? Polje „broj izdržavanih članova domaćinstva“ će u zavisnosti od toga da li je obavezno ili u zavisnosti od raspoloženja zaposlenog biti popunjeno ili nepopunjeno. Problem je kada ostane nepopunjeno, a klijent je došao po npr. keš kredit ili karticu. Takođe, problem je i kada vam neko postavi to pitanje, a vi došli samo da otvorite običan tekući račun.  

Naravno da je ovo trenutak kada se stavlja prst na čelo i postavlja pitanje šta bi bilo lepo da imamo od podataka o klijentu (nice to), a šta nam je uistinu potrebno u određenoj situaciji (need to). Ako sam došla da otvorim račun, nemojte me pitati koliko dece imam, postoje drugi načini da u nekom trenutku dobijem ponudu koja počinje sa: „CongratulationsYou are qualified to get…“ 

Zaključak faze: Otrežnjujuće je bilo popunjavati matricu „razlog vs podatak. Mislim da smo se svi mi, koji smo učestvovali u projektu, najlakše stavljali u poziciju klijenta u ovoj fazi. Definisanje razloga dolaska (pojavljivanja) klijenta je bio i uvod za „Dilemu 3“, koja sledi.  

Ovde je važno postaviti i pitanje sa kime klijent komunicira. Neprihvatljivo je da jednak pristup i jednake dozvole prilikom unosa ili ažuriranja matičnih podataka ima osoba koja radi u kontakt centru i neko koji je u direktnom kontaktu sa klijentom. Matrica „razlog vs lokacija“ je pokazala granice pristupa i mesta na kojima je potrebna dodatna validacija podataka.  

 

Dilema 3: Šta je starije: „Ko sam?“ ili „Zašto sam došao?“ 

… a šta je više „procesno“? 

 

Zapravo, šta klijent prvo izgovori? „Dobar dan, moje ime je….“ i daje svoj lični dokument ili „Dobar dan, došao sam zbog…“ i onda službenik banke traži lični dokument? 

Ukoliko ovome pridodamo i težnju da klijentu ne postavljamo pitanja neadekvatna njegovom razlogu dolaska, kao i želju za intuitivnom front-end aplikacijom, jasno je zašto smo ovoliko pažnje posvetili da formu za unos matičnih podataka postavimo na pravo mesto i pravilno je povežemo sa ostatkom procesa 

Primenjujući pravilo „proces je uvek isti“ prilikom dolaska bilo novog, bilo postojećeg klijenta, a u zavisnosti od lokacije, razloga dolaska, vrste klijenta i kriterijuma promenljivosti podataka, kroz određene „petlje“ se prolazi ili ne prolazi. Službenik više ne razmišlja o tome šta je sledeće što je potrebno da uradi na računaru, već može da bude fokusiran na klijenta koji je ispred njega. On sad brzo dolazi do momenta kada se za klijenta stvara vrednost, a pri tom je verovatnoća za nastanak greške bliže nuli nego ikada do sada.  

Takođe, na ovaj način postavljen sistem pruža mogućnost jasnog i jednostavnog prilagođavanja budućim izmenama zakonskih regulativa povodom identifikacije klijenta i upotrebe podataka.  

 

Dilema 4: Na koji način proveriti To-Be predlog? 

 

Simulacijom. Zašto simulacija? Prvo, zbog konačne provere u smislu logičnosti i adekvatnog redosleda polja, koraka i sl. Ukoliko imate priliku i da tokom simulacije imate klijenta ispred – to je najbolja prilika da proverite To-Be predlog koji je tim kreirao.  

Drugo, smatram da je kreiranje predloga novih formi za unos u npr. excel-u uz malo VBA bolji način da se dođe do dovoljno realne procene vremena trajanja To-Be rešenja, nego da se uđe u neku analizu-paralizu prilikom računanja istog putem npr. MTM-a 

Pozabavimo se vremenima.  

Vreme trajanja identifikacije novog klijenta u as-is situaciji (zatečeno stanje) je bilo najmanje (u idealnoj situaciji) 8 min 30 sek, pa sve do skoro 10 minuta kada se jave tipična rasipanja u vezi sa štampanjem, čekanjem, prekidanjem itd.  

Vreme trajanja identifikacije novog klijenta u to-be situaciji je određeno kroz tri varijante simulacije:  

  1. a) rad sa novom formom za unos matičnih podataka– 5 min 20sek 
  2. b) rad sa novom formom + OCR ličnog dokumenta– 3 min 45sek 
  3. c) rad sa novom formom + OCR ličnog dokumenta + potpisna ploča– 3 min 5sek 

Kada uporedimo vremena trajanja pojedinačnih varijanti sa idealnim vremenom na stari način dobijamo rezultat od preko 30% skraćenja za a), preko 50% skraćenja za b) i preko 60% skraćenja za c) varijantu. Uz napomenu da je c) varijanta ujedno i paperless varijanta.  

Još jednom sve pohvale za tim koji je učestvovao u projektu.  

 

Dilema 5: Kako osigurati da se ne vratimo na staro? 

(Sistem zvan „You shall not pass) 

 

Svaka čast na dobrom rešenju, ali koliko je to održivo? Nađi rešenje za to.  

Ovo rešenje se gradilo tokom čitavog projekta, a na momente je izgledalo kao da trenutno nije moguće osmisliti mehanizam koji će sprečiti da se, tokom određenog protoka vremena, ponovo nagomilaju podaci u formi za unos matičnih podataka. Otuda sam i dobila inspiraciju za naziv mehanizma „Adel“ (od ADL – Anti Data Laundry – bankari znaju zašto).  

Kada u As-Is stanju imate situaciju gde se prikazuje preko 200 polja u aplikaciji matičnih podataka, nezavisno od vrste klijenta i razloga dolaska, i kada u To-Be stanju dođete do cca 60 polja u prikazu za konkretnu varijaciju, kreiranje mehanizma koji sprečava da se vratimo na staro je prioritet 

Šta za vas predstavlja matični podatak? Upravo je preduslov za kreiranje mehanizma bilo definisanje kriterijuma šta jeste, a šta nije matični podatak. Iako zvuči krajnje banalno, prošli su sati diskusije pre nego što se došlo do prvog konkretnijeg predloga. Završno rešenje je konačno omogućilo taj „mehanizam“ koji će bilo koju potrebu za novih podatkom, a na osnovu nekoliko kriterijuma, svrstati u grupu:  

  1. a) matičnih podataka (podataka o klijentu)
  2. b) podataka o proizvodu
  3. c) podataka u „upitnicima“ (podaci koji ispunjavaju neke od kriterijuma prethodne dve grupe)

Šta je za mene ovde čarobnoTo što sada sa sigurnošću mogu da kažem da će podatak „Broj cipela“ završiti na matičnim podacima samo ukoliko ispuni dva ključna kriterijuma. U suprotnom, podatak će se nalaziti na „proizvodu“ ili u „upitniku“. 

 

Zaključak 

Divno je bilo otkrivati ogroman potencijal za unapređenje ovog segmenta procesa, čije se protočno vreme meri u minutama. „Sve može bolje“ je u redu ponavljati kao mantru. Lep osećaj je i prepoloviti vreme nanošenja dekora na šerpu u nekoj proizvodnji. Ipak, poseban osećaj je učestvovati u kreiranju nove aplikacije koja će od tog trenutka obeležavati početak svakog posla i čiji će efekat osetiti svaki klijent koji iz bilo kog razloga uđe u poslovnicu, pristupi online aplikaciji… ili na bilo koji način dođe u kontakt sa finansijskom institucijom 

Sve je to lepo, ali uvek ima ono: „Čemu sve ovo?“  

Moje viđenje: Diferencijacija. Finansijske institucije ne predstavljaju izuzetak na tržištu gde je konkurencija sve surovija. Kada iscrpimo mogućnosti diferencijacije putem smanjenja cene prema klijentu, preostaje nam samo da se takmičimo u brzini i kvalitetu usluge. Čini mi se da da je taj trenutak došao i na ove prostore. Kontinuirano unapređenje procesa sa ciljem dizajniranja efektivnih i efikasnih procesa koji generišu manje troškova i obezbeđuju realizaciju adekvatne usluge prema klijentu predstavljaće jedno od rešenja.  

Tako će se i kompanije u ovom segmentu u budućnosti sve više diferencirati od svoje konkurencije upravo putem optimizacije svojih procesa uz praćenje globalnih trendova na polju operativne izvrsnosti. Biće divno učestvovati i posmatrati promene koje slede.