Okiem analityka
3 pytania do eksperta. Mikołaj Polak
Automatyzacja procesów biznesowych w tak wielkich organizacjach jak banki i instytucje, to nie lada wyzwanie. O to, jakie są najważniejsze wyzwania w tym obszarze, zapytaliśmy Mikołaja Polaka – doświadczonego analityka biznesowo-systemowego, na co dzień pracującego w obszarze bankowości korporacyjnej. Mikołaj dzieli się swoją analityczną perspektywą i garścią wskazówek, które pozwolą spojrzeć inaczej na procesy i projekty IT. I tym samym być może – uniknąć kosztownych pułapek i błędów.
Który proces bankowy jest najtrudniejszy do automatyzacji?
Nie ma jednej odpowiedzi na to pytanie. Choć procesy bankowe są w dużej mierze podobne, każdy bank posiada swoją specyfikę operacyjną i organizacyjną. Większość procesów w teorii da się zautomatyzować. Tym, co na przykład może blokować automatyzację jest dostępność API czy sposób przechowywania danych. Brak dostępności API powoduje oczywiście problemy z integrowaniem budowanych systemów z istniejącymi w banku rozwiązaniami.
Przechowywanie i procesowanie danych w formie np. arkuszy kalkulacyjnych, powoduje za to inny rodzaj problemów. Wiele instytucji nadal przechowuje dane w arkuszach kalkulacyjnych, często w formacie Excel. Chyba w większości organizacji mówi się „Excel rządzi”, ponieważ jest popularny, znany i użytkownicy czują się komfortowo, pracując w nim. Natomiast jako źródło danych wejściowych dla systemu workflow, arkusze kalkulacyjne są nieefektywne z perspektywy integracji systemowych. Dlatego w takich przypadkach pierwszym działaniem nie jest automatyzacja, ale – przygotowanie danych.
Przykładem może być proces onboardingu klienta KYC
(Know Your Customer, czyli proces Poznaj Swojego Klienta).
Jednym z wymagań przy budowaniu automatyzacji procesu KYC jest weryfikacja podmiotu w bazach wewnętrznych i zewnętrznych pod kątem identyfikacji potencjalnych ryzyk i ich wyeliminowania. Na pierwszy rzut oka rozwiązanie wydaje się oczywiste. Problemem w tym przypadku jest przechowywanie danych w arkuszach kalkulacyjnych. Excel to nie baza danych!
To oznacza, że pojawia się więcej koniecznych kroków, niż się z początku wydawało w, z pozoru prostym, wymaganiu „integracja z bazami wewnętrznymi”. Nie tylko trzeba zbudować bazę danych, która inicjalnie zostanie zasilona danymi istniejącymi (podprojekt migracji danych) lecz także zapewnić użytkownikom możliwość dodawania, usuwania, zarządzani danymi, co wiąże się zwykle z koniecznością wdrożenia nowej aplikacji. Dopiero wtedy możemy wykonać krok w stronę zintegrowania procesu KYC z takim repozytorium.
W praktyce trudność automatyzacji rzadko leży w samych procesach. Częściej wynika z ograniczeń środowiska technologicznego i jakości danych. Trzeba wtedy zrobić krok wstecz – i zanim zacznie się automatyzować, należy zidentyfikować źródła danych. Często spotykam się u klientów z sytuacją, że różne działy przetwarzają te same dane, ale każdy ma swoje repozytorium, inne logiki. To prowadzi do rozbieżności, a musi być „jedno źródło prawdy”. Trzeba też przystosować środowisko technologiczne i wystandaryzować część procedur w organizacji. To bywa najtrudniejsza część zadania, jednak jest niezbędna dla prawidłowego działania.
Jakie są najpopularniejsze błędy, których klienci mogliby uniknąć, a jednak je popełniają?
Jednym z najczęściej popełnianych błędów jest brak myślenia procesowego.
Klient koncentruje się często na pojedynczym efekcie, który chce osiągnąć, zamiast zwerbalizować konkretną potrzebę czy problem. Tymczasem za konkretnym efektem lub problemem zawsze stoi mniejszy lub większy proces. Może on angażować wielu interesariuszy, wymagać współdziałania i synchronizacji systemów, integracji, a czasem nawet – efektów kilku kolejnych procesów i podprocesów. To powoduje często budowanie fragmentarycznych, oderwanych od kontekstu, trudno skalowalnych i nieefektywnych rozwiązań. Na szczęście, jeśli klient trafia na odpowiedzialnego wykonawcę – w trakcie warsztatów czy uzgadniania wymagań, łatwo pokazać, jak się rzeczy mają. Trudniej, gdy klient nie miał wcześniej okazji poznać szerszego kontekstu procesowego. Dlatego proponujemy inwentaryzację procesów „as-is” wykorzystując do tego np. Event Storming. Dzięki temu organizacja „otwiera oczy” i poznaje swoje procesy.
Drugim częstym błędem jest brak precyzyjnego zdefiniowania potrzeby biznesowej.
Tu również problemem jest częste „myślenie gotowym rozwiązaniem”. Na przykład – zamiast komunikatu „potrzebuję, żeby aplikacja agregowała dane klienta z różnych źródeł wewnętrznych i zewnętrznych oraz prezentowała je w czytelnej formie, tak aby użytkownik mógł szybko podjąć decyzję bez przeszukiwania wielu systemów”, otrzymujemy komunikat: „proszę odtworzyć w systemie tabelę, jaką mam obecnie w Excelu”. Jeśli potraktuje się tak zdefiniowaną potrzebę jako gotowe wymaganie – efektem bywają niepotrzebnie zmarnowane godziny pracy zespołu wytwórczego, a co najgorsze na końcu niezadowolony klient. Bo przecież nie chodziło mu tylko o przepisanie do systemu tabelki, a o rozwiązanie konkretnego problemu, którego nie potrafił sprecyzować.
Dlatego tak ważne są warsztaty i bieżąca komunikacja z interesariuszami, będącymi użytkownikami końcowymi. Z jednej strony – pozwalają rozwiać wątpliwości. Z drugiej – przyzwyczajają osoby do definiowania potrzeb biznesowych i projektowych w taki sposób, który naprawdę mówi, czego potrzebuje ich organizacja i czego oczekują od efektywnego procesu.
I tutaj najlepiej sprawdza się Scrum. Ponieważ w krótkim czasie (2‑tygodniowe sprinty) dostarcza konkretną wartość biznesową (incrementy produktu). A użytkownik końcowy testuje je w realnym środowisku, dostarczając feedback na bieżąco. Dzięki temu ma możliwość doprecyzowania potrzeb, co przekłada się na jeszcze bardziej ulepszoną funkcjonalność.
Kolejny błąd to rozpoczynanie projektów IT bez zapewnienia udziału odpowiednich ekspertów domenowych.
Zdarza się, że zespoły projektowe są budowane z: osób technicznych, właścicieli produktów, właścicieli procesów biznesowych. Natomiast nie ma w nich osób, które na co dzień pracują w danym procesie, tzw. end userów (użytkowników końcowych). A to dla nich tak naprawdę powstaje dane rozwiązanie informatyczne.
Wyobraźmy sobie projekt realizowany w dużej firmie logistycznej, która planuje wdrożenie systemu do zarządzania transportem i magazynem (TMS/WMS). Celem projektu jest automatyzacja harmonogramowania dostaw, przyjęć towaru oraz optymalizacja tras kierowców.
Zespół projektowy składa się z przedstawicieli działu IT, finansów oraz zespołu zakupowego, który odpowiada za kontakty z przewoźnikami. Brakuje jednak osób z codziennym doświadczeniem operacyjnym – dyspozytorów, magazynierów i kierowców – czyli tych, którzy faktycznie będą korzystać z nowego systemu.
W efekcie powstaje rozwiązanie, które teoretycznie spełnia założenia biznesowe, ale w praktyce okazuje się nieintuicyjne. Planowanie tras wymaga zbyt wielu kliknięć, a moduł przyjęcia towaru nie uwzględnia różnic między magazynami o różnej przepustowości ramp. System działa, lecz nie wspiera efektywnie pracy operacyjnej – prowadząc do frustracji użytkowników i konieczności wprowadzania kosztownych poprawek po wdrożeniu.
Dlatego tak ważne jest, by w zespołach projektowych – oprócz ekspertów technicznych i właścicieli procesów – znaleźli się również przedstawiciele operacji. To oni najlepiej rozumieją codzienne ograniczenia i realne potrzeby użytkowników. Ich udział od początku projektu pozwala uniknąć rozbieżności między koncepcją systemu a rzeczywistym sposobem jego wykorzystania. To klasyczny przykład braku wiedzy „as-is” w zespole projektowym. Eksperci domenowi mogliby już na etapie analizy wskazać, które dane są naprawdę potrzebne i jak je najlepiej prezentować. Ich włączenie od początku projektu pozwala uniknąć sytuacji, w której rozwiązanie poprawne technologicznie okazuje się niepraktyczne w codziennej pracy.
Czwarty błąd dotyczy wyboru metodyki prowadzenia projektu IT.
Klienci chcą prowadzić projekty w metodyce zwinnej, która jest bardziej elastyczna, szybciej reaguje na zmianę warunków, szybciej dostarcza „namacalną” wartość biznesową. Jednocześnie często działają organizacji, która narzuca sztywny harmonogram i budżet. Do tego, jeśli klient nieprecyzyjnie definiuje potrzeby biznesowe, nie angażuje ekspertów domenowych i nie patrzy na proces w sposób całościowy, w konsekwencji możemy zmagać się z narastającymi wymaganiami projektowymi. Zupełnie inaczej (i niewinnie) wyglądają one na etapie RFP. Potem okazują się kryć pod sobą mnóstwo nowych, pojawiających się co chwilę, wymagań.
Często spotykam się z sytuacją, gdzie sponsor projektu IT z góry narzuca termin wdrożenia, a wymagania są „pływające” i muszą się zmieścić w zaklepanym budżecie na dany rok. W ten sposób to, co w swobodnej agile’owej metodyce można by zaadresować, staje się problemem w świecie nieprzekraczalnego deadline’u, budżetu i nienegocjowalnego zakresu. Klient zaś jest, w oczywisty sposób, niezadowolony – projekt bowiem nie spełnia jego niewypowiedzianych oczekiwań.
Wybierając metodykę prowadzenia projektu IT, warto znać jej zalety, ale i wymagania oraz ograniczenia. A także ograniczenia i wymagania struktury swojej organizacji. Realne i szczegółowe przyjrzenie się potrzebom biznesowym, potrzebom zaangażowanych na co dzień w proces interesariuszy, warunkom brzegowym narzuconym przez organizację… To wszystko pomaga dobrać odpowiednią metodykę projektu do środowiska, w którym projekt będzie prowadzony.
O co najczęściej pytają klienci zainteresowani wdrożeniem systemu automatyzacji procesów biznesowych (np. naszego Flowee)?
Klienci bankowi najczęściej pytają o kwestie integracji – zwłaszcza z bazami takimi jak np. KRS, REGON czy BIK, z których dane są kluczowe dla codziennej pracy zespołów. Chcieliby też wiedzieć, czy Flowee posiada wbudowany silnik decyzyjny. A także – czy zaciąga dane finansowe np. z KRS i automatycznie na ich podstawie wylicza zdolność kredytową i generuje oferty.
Choć na wszystkie te pytania wstępna odpowiedź brzmi „nie, tego nie ma w pakiecie”, to jednocześnie wszystkie funkcjonalności Flowee osiąga poprzez integrację z istniejącymi już po stronie klienta rozwiązaniami. Przy wdrożeniu Flowee jest też możliwe jego dostosowanie do potrzeb klienta. Również poprzez zbudowanie nowych modułów przeznaczonych specjalnie dla niego, by jak najlepiej działały w zbudowanym bezpośrednio u klienta środowisku.
Klienci coraz częściej pytają również o dostępność wersji mobilnej. W kolejnych etapach rozwoju Flowee planujemy prace nad rozwiązaniami, które zapewnią wygodny i bezpieczny dostęp do systemu z urządzeń przenośnych. Odpowiedzialne projektowanie produktów to również świadomość, że nie wszystkie rozwiązania będą sprawnie działały i będą równie ergonomiczne i dobrze zabezpieczone w środowisku mobilnym.
