Jak wdrożyć system w 9 miesięcy i nie zwariować?
Transkrypt
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