Jak wdrożyć system w 9 miesięcy i nie zwariować?

Gazeta Finansowa (Nr 43/2012)
Marcin Dziuba, Łukasz Kawulok
Jak wdrożyć system w 9 miesięcy i nie zwariować?
Doświadczeniami z wdrożenia systemu oceny ryzyka metodą zaawansowanych ratingów
(A-IRB) w rekordowo szybkim czasie dzielą się Marcin Dziuba (architekt systemu) oraz
Łukasz Kawulok (opiekun biznesowy projektu po stronie dostawcy).
Projekt
Zdążyliśmy. W dniu, w którym piszę ten artykuł, aplikacja jest wdrażana na środowisko pilotażowe. Kiedy w grudniu 2011 roku podpisywaliśmy umowę na wdrożenie aplikacji do oceny ryzyka kredytowego
klientów instytucjonalnych, nikt z nas nie był świadomy jak wielkie wyzwanie zostało nam postawione.
Głównymi celami projektu było zamodelowanie na platformie BPM
procesów związanych z oceną wniosków kredytowych, aneksowania
i monitorowania podpisanych umów z wykorzystaniem nowej metodyki oceny ratingu klienta. Procesy, które dzięki długiej współpracy
z bankiem były nam częściowo znane, wymagały odpowiedniego doprecyzowania i opisania, natomiast metodyka była całkowicie nowym
obszarem. Wdrażane zasady oceny ryzyka kredytowego spełniające
wymagania KNF odnośnie zaawansowanej metody wewnętrznych ratingów, wymagały przeprojektowania całego dotychczasowego modułu wyznaczania ratingu klienta.
finansowych. Dzięki takiej funkcjonalności ocena ilościowa zawsze jest
wyliczana w oparciu o jeden model wskaźnikowy.
Kompleksowy moduł gromadzący informacje o klientach banku, firmach
i osobach powiązanych, posiadanych zabezpieczeniach, zintegrowany
z systemem centralnym organizacji, umożliwia przetwarzanie wszystkich istotnych danych o kredytobiorcy z punktu widzenia oceny ryzyka
kredytowego.
Gromadzenie w nowym rozwiązaniu informacji w usystematyzowanej
postaci, pozwala na łatwe pozyskiwanie i identyfikowanie wielostronnych relacji oraz znaczne polepszenie jakościowe danych przekazywanych do systemu raportowego.
Testowanie
A1, C2… dla większości ludzi nic nieznaczące kombinacje liter i cyfr,
dla banku są kluczowymi wskaźnikami opisującym ryzyko udzielenia
kredytu wybranemu przedsiębiorcy. Wdrażana metodyka wymaga zgromadzenia średnio 10 tys. zmiennych w celu oceny sytuacji ekonomicz-
Analiza
Podczas trzymiesięcznego etapu analizy, opisaliśmy wszystkie modelowane procesy. Opracowany materiał spowodował, iż wiedzieliśmy
jakie wymagania funkcjonalne rozwiązanie musi spełniać. Ważnym elementem tego etapu był aktywny udział pracowników banku w tworzeniu założeń. W trakcie projektowania nowych funkcjonalności, całkowite zaangażowanie strony zamawiającej jest warunkiem koniecznym
aby dostarczane rozwiązanie realizowało stawiane mu oczekiwania.
Nie udało się jednak zupełnie wyeliminować zmian, pojawiających się
właściwie już w końcowej fazie analizy. Pojawiały się nowe wymagania,
wynikające z dynamicznie zmieniającej się rzeczywistości, które trzeba
było adresować w projekcie. Wymusiło to elastyczne podeście do procesu produkcji i konfiguracji rozwiązania.
Trafną decyzją okazało się zastosowanie podejścia iteracyjnego do
prowadzenia projektu. Dzięki kompleksowej platformie BPM, byliśmy
wstanie udostępniać kolejne skonfigurowane obszary w krótkich odstępach czasu. Zaletą takiego rozwiązania było to, że klient już we
wczesnej fazie projektu wiedział jak będą wyglądać kolejne moduły
i mógł szybko reagować na niedoprecyzowane funkcjonalności. Dlatego możemy mieć teraz pewność, iż finalna wersja aplikacji spełnia jego
oczekiwania.
Gromadzone przez bank na przestrzeni ostatnich kilku lat dane finansowe o sytuacji ekonomicznej poszczególnych kredytobiorców, pozwoliły na opracowanie i kalibrację wewnętrznych modeli ratingowych.
Mechanizm ten jednak nie był pozbawiony wad i w dużej mierze polegał na jakości pracy użytkownika.
W nowym rozwiązaniu zastosowaliśmy funkcjonalność rejestracji sprawozdań finansowych w postaci kompletu dokumentów. Skonfigurowane
w nim walidacje uniemożliwiają wprowadzenie niepoprawnych danych
i eliminują przypadkowe błędy analityka.
Zgodnie z nową koncepcją metodyki, wprowadzane informacje
niezależnie od formy prawnej i typu sprawozdawczości (ustawa o rachunkowości, MSR, podatkowa książka przychodów i rozchodów) są
przekształcane do standardowych dla metodyki wzorów sprawozdań
strona 1 vsoft business improvement
Jakość gromadzonych informacji
no-finansowej kredytobiorcy. Dane te, przetwarzane w aplikacji przez
ponad sto modeli obliczeniowych odpowiadają za wyznaczenie ratingu
bazowego klienta.
Przy takiej ilości informacji istotną rolę odegrał proces testowania modeli w silniku ratingowym. Skonfigurowanie dużej ilości formuł przetwarzających wszystkie dane wejściowe, wymagało ogromnej precyzji i staranności. Nie trudno było o popełnienie błędu literowego, przez co wyniki
obliczeń mogły zostać zafałszowane. Błędy takie zdarzały się również
w dostarczonej dokumentacji. Wzajemna kontrola klient-dostawca,
prowadzona już na wczesnym etapie projektu, pozwoliła na wyeliminowanie większości pomyłek. Istotne znaczenia ma tutaj zastosowanie
narzędzia umożliwiającego graficzne modelowanie algorytmów obliczeniowych oraz wspierającego proces testowania w sposób zrozumiały
dla obu stron kontraktu.
Ergonomia
W całym procesie weryfikacji wnioskodawcy bardzo ważna jest ocena
jakościowa przeprowadzana przez analityka, dlatego też wdrażany system musiał maksymalnie ułatwić identyfikacje różnych ryzyk związanych
z sytuacją ekonomiczną klienta. Ocena dużych grup kapitałowych mających wiele powiązań jest dla użytkownika prawdziwym wyzwaniem. Implementowana metodyka umożliwia przeprowadzenie oceny zarówno
na sprawozdaniach jednostkowych jak i skonsolidowanych, uwzględniając wpływ grupy kapitałowej. Stworzone w aplikacji funkcjonalności
pozwalają na równoległe prowadzenie analiz z różnego zakresu danych,
a także na łatwą ocenę powiązań kapitałowych i organizacyjnych występujących pomiędzy firmami lub osobami.
Przed rozpoczęciem prac programistycznych spędziliśmy wiele godzin nad prototypem systemu, dostosowując układ aplikacji i formularzy
w taki sposób, aby maksymalnie ułatwić prace użytkownikom. Zastosowanie technik kognitywistycznych, testowanie prototypu z docelowymi
odbiorcami rozwiązania oraz zadbanie o funkcjonalności ułatwiające
pracę grupową, pozwala mieć pewność, iż aplikacja jest przyjazna użytkownikom.
Jak nie zwariować?
9 miesięcy, czterdziestoosobowy zespół składający się z programistów,
projektantów procesów, osób tworzących modele obliczeniowe, testerów, grafików, dokumentalistów i wdrożeniowców, tysiące linii kodu,
zamodelowanych procesów algorytmów i setki stron dokumentacji.
Taki ogrom pracy jest potrzebny aby dostarczyć klientowi rozwiązanie
informatyczne, które w pełni spełnia oczekiwania i pozwala optymalnie
prowadzić mu swój biznes.
Jak wdrożyć system oceny ryzyka metodą zaawansowanych ratingów
(A-IRB) w 9 miesięcy i nie zwariować? W mojej ocenie, kluczowymi elementami do osiągnięcia celów projektu w tak krótkim czasie było wykorzystanie doświadczenia z zakresu oceny ryzyka kredytowego zespołu
realizującego projekt, odpowiednie zaangażowanie i wiedza pracowników klienta w zakresie wdrażania nowych rozwiązań informatycznych
oraz umiejętne zarządzanie projektem.
Równie istotne okazało się zastosowanie narzędzia do modelowania
algorytmów obliczeniowych i platformy BPM, pozwalających na łatwą
konfiguracje, testowanie i wprowadzanie wymaganych zmian.
matematycznymi i zwrotami prawnymi. Tak to prawda, w projekcie zdecydowaną większość stanowiły osoby nieprogramujące, a klient bardzo
często był obecny w trakcie prac na wyciągnięcie przysłowiowej ręki.
Proces obliczeń przestał być czarną skrzynką, którą klient owszem
podziwiał za możliwości, ale bał się niezrozumiałej zawartości.
Łatwość w zrozumieniu graficznych algorytmów, łatwość w weryfikacji ich poprawności, pełna powtarzalność uzyskana dzięki wbudowanym mechanizmom testów biznesowych oraz szybka i pewna weryfikacja działania obliczeń na bardzo szerokim zestawie danych testowych
to podstawowe elementy, w których narzędzie bardzo pomogło. Ułatwiło zrozumienie logiki obliczeń, ale i znacznie przyśpieszyło proces ich
weryfikacji i testowania, o szybkim wprowadzaniu poprawek i zmian,
czasem nawet przez samego klienta nie wspominając. Weźmy prosty
przykład, który miał w projekcie miejsce wielokrotnie. Analityk stworzył w narzędziu model zgodnie z wymaganiami i wyspecyfikowanym
algorytmem.
Do tego modelu klient dodał kilka przykładów, czyli dane wejściowe
i oczekiwany wynik algorytmu. Analityk wprowadził te przykłady, jako
testy biznesowe i następnie je uruchomił. Jeśli wyniki były niepoprawne,
taki test (pojedynczy przykład) od razu jest zaznaczony. Analityk mógł
poprawić błąd i ponownie uruchomić wszystkie testy, ewentualnie omówić sprawę z klientem, potwierdzić czy dane są poprawne, czy może
jest konieczna zmiana algorytmu. Trwa to kilka sekund, od razu wiadomo czy wykonana zmiana była skuteczna i czy nie popsuła innych
wyników. Dzięki temu rozmowa analityka i klienta koncentruje się tylko
na kwestiach merytorycznych.
Wyobraźmy sobie inny przykład. Istnieje gotowy model, który jest
testowany. Zazwyczaj testowanie polega na ręcznym (czasochłonnym)
przeliczeniu i porównaniu wyniku z wynikiem algorytmu. Bardzo szybko
poprawne wyniki można zapisać jako testy. W przyszłości te zapisane
kombinacje wyników będą sprawdzane automatycznie z wyraźnym zyskiem czasu. Po każdym teście ilość automatycznych scenariuszy rośnie
lawinowo.
Po zakończeniu prac nad prototypem programiści razem z projektantami budowali proces obsługi, który w odpowiednich momentach wywołuje obliczenia, usprawniali ergonomię, doskonalili zabezpieczenia
aplikacji, dodawali do systemu tak zwane „smaczki”. Co jednak istotne
ich dodatkowym zadaniem było usprawnianie narzędzia. To dzięki ich
pracy narzędzie, którego używają analitycy i którego będą używali przy
kolejnych projektach będzie jeszcze lepsze, pozwalając skupić się na
tym, co analitycy lubią najbardziej – na merytoryce: A1, C2 …
Łukasz Kawulok
Marcin Dziuba
Ekspert w obszarze analizy procesów
biznesowych sektora bankowego,
doświadczony trener i manager.
Obecnie Architekt rozwiązań
biznesowych w firmie VSoft SA.
Realizacja tak dużego systemu bez odpowiednich narzędzi to z pewnością nie jest recepta na sukces. Jaka więc
jest ta recepta?
Moim zdaniem właśnie dzięki odpowiednim narzędziom, których użyliśmy do budowy systemu sprostaliśmy temu wymagającemu zadaniu.
Jak wspominał Marcin potrzeba 10 tys. zmiennych i ponad stu modeli
obliczeniowych po to żeby w wyniku wyznaczyć kombinacje dwóch liter.
Dzięki narzędziu, które umożliwia graficzne modelowanie algorytmów
obliczeniowych osobom rozumiejącym biznes klienta nie było konieczności „tłumaczenia” działania systemu programistom. Konfigurację
wszystkich obliczeń wykonywały osoby mówiące tym samym, specyficznym językiem metodyki kredytowej, językiem naszpikowanym wzorami
Łukasz Kawulok
Ekspert w obszarze rozwiązań IT
skierowanych do obszaru bankowości
oraz manager z wieloletnim
doświadczeniem. Obecnie Dyrektor
w Biurze Kontraktów firmy VSoft SA.
strona 2 vsoft business improvement
Marcin Dziuba