Faza Discovery ogranicza ryzyko wdrożeń systemów windykacyjnych
Przed rozpoczęciem budowy systemu windykacyjnego zespoły biznesowe i techniczne powinny zweryfikować procesy, wymagania i architekturę. Faza Discovery ma ograniczyć późniejsze zmiany zakresu, koszty i spory.
Systemy do windykacji obsługują liczne strategie zależne od liczby dni opóźnienia, salda i historii kontaktu z dłużnikiem. Muszą łączyć się z e-Sądem i komornikami, wspierać restrukturyzację, kontrolować przedawnienie, a czasem prowadzić sprawy transgraniczne podlegające różnym jurysdykcjom.
Paweł Wroniewicz, kierownik działu sprzedaży VSoft, wskazuje, że każda organizacja układa te elementy inaczej, zgodnie z własnymi procedurami, tolerancją ryzyka i historią wykorzystywanych narzędzi. Dlatego specyfikacja przygotowana przy wyborze dostawcy nie zawsze odpowiada realiom w chwili rozpoczęcia projektu.
W dużych przedsiębiorstwach wymagania mogą być częściowo nieaktualne już po kilku miesiącach. Dopiero szczegółowa analiza ujawnia faktyczne reguły działania, zależności między działami i rezultaty wcześniejszych prac koncepcyjnych. Bez tego wstępne szacunki prowadzą do sporów o zakres, kolejnych zmian i niezadowolenia obu stron.
Faza Discovery powinna poprzedzać kodowanie i obejmować trzy równoległe strumienie. Część zarządcza określa model współpracy, harmonogram i role. Część analityczna opisuje procesy, tworzy backlog i makiety doświadczeń użytkownika. Część techniczna projektuje architekturę oraz przygotowuje proof of concept najbardziej ryzykownych elementów.
Rezultatem jest zweryfikowana specyfikacja, zestaw klikalnych makiet, uporządkowany backlog, wycena oraz mapa dalszego rozwoju systemu. Dokumenty opierają się wtedy na danych pozyskanych wspólnie, a nie na założeniach zapisanych wiele miesięcy przed wdrożeniem.
Discovery można stosować również przy mniejszych projektach opartych na gotowym produkcie. Kilkudniowy warsztat pozwala uruchomić system w standardowej wersji, a następnie ustalić kolejność rozbudowy, strategii procesowych i integracji z istniejącą infrastrukturą informatyczną.
Celem jest wskazanie zmian, które najszybciej przyniosą efekty, bez rozpoczynania kosztownej personalizacji bez rozpoznania. Według doświadczeń VSoft wcześniejsza kontrola oznacza mniej niespodzianek, krótsze wdrożenie i mapę rozwoju ograniczającą potrzebę korygowania zakresu już w trakcie prac.
Strumienie nie powinny działać osobno. Decyzja biznesowa może zmienić architekturę, a ograniczenie techniczne może wymagać innej kolejności procesów w backlogu. Wspólne warsztaty pozwalają ujawnić te zależności przed rozpoczęciem kosztownego kodowania.
Proof of concept powinien dotyczyć elementów obarczonych największą niepewnością, na przykład integracji albo nietypowej reguły prawnej. Pozytywny test ogranicza ryzyko, że kluczowa funkcja okaże się niewykonalna dopiero po zbudowaniu pozostałych modułów.
Discovery umożliwia też świadomą ocenę partnera technologicznego. Klient sprawdza sposób współpracy i jakość analizy, a dostawca otrzymuje dane potrzebne do realistycznego harmonogramu oraz wyceny.
L.Sawicki--GL