NGinn BPM

Wdrożenie NGinn – case study

NGinn nie tak dawno temu przeszedł swój chrzest bojowy – mianowicie doczekał się wdrożenia produkcyjnego i to na całkiem sporą skalę. Ponieważ od wdrożenia minęło już trochę czasu a system jest ustabilizowany i można spokojnie powiedzieć że działa, to dziś opowiem nieco o tym jak owo wdrożenie wyglądało i jaka jest w nim rola NGinn.

Krótko o procesie

NGinn został użyty do zautomatyzowania procesu indeksowania dokumentów w firmie telekomunikacyjnej która jest jednym z operatorów komórkowych w Polsce. Indeksowanie dokumentów jest to jeden z etapów procesu obsługi wchodzących do firmy dokumentów papierowych (listów, umów i innych dokumentów dotyczących klientów firmy), który przedstawia się mniej więcej tak:

1. Przyjęcie dokumentów w kancelarii
2. Sortowanie (wstępna klasyfikacja)
3. Przygotowanie do skanowania (rozpakowanie, rozszycie etc)
4. Skanowanie
5. Indeksacja (klasyfikacja, opisanie dokumentu odpowiednimi danymi)
6. Umieszczenie dokumentu w archiwum elektronicznym
7. Dalsza obsługa dokumentu już w wersji elektronicznej (dalsze etapy są realizowane w innych systemach, proces obsługi jest różny dla różnych dokumentów)

W skrócie proces ten prowadzi do przekształcenia dokumentu na jego obraz cyfrowy (skan) z odpowiednimi metadanymi, dzięki czemu dalsza obsługa dokumentu może być prowadzona za pomocą systemów informatycznych. Firma dąży do maksymalnego zautomatyzowania tego procesu gdyż obsługuje dziesiątki tysięcy dokumentów dziennie i każda czynność ręczna generuje duże koszty (w obsługę wchodzących dokumentów zaangażowane jest kilkadziesiąt osób).

Celem naszego wdrożenia było zautomatyzowanie etapu indeksacji – czyli etapu w którym osoba skanująca dokument opisuje go odpowiednimi metadanymi. Te metadane zależą od rodzaju dokumentu, ale najczęściej są to podstawowe informacje jak rodzaj dokumentu, data wpłynięcia do firmy, data skanowania, identyfikator klienta, nr telefonu tego klienta, nr dokumentu, kod kreskowy, segment klienta i kilka innych atrybutów. Do tej pory musiały być odczytywane z dokumentu (lub wyszukiwane w innych systemach) i wpisywane ręcznie przez pracownika skanującego dokument, co miało swoje wady: wydłużało czas obsługi dokumentu i stwarzało ryzyko wystąpienia błędów w danych. W celu poprawienia efektywności tego etapu firma opracowała jego wersję zautomatyzowaną  w której praca ręczna została albo całkowicie wyeliminowana, albo ograniczona do minimum. Automatyzacja polegała na zmianie aplikacji skanującej tak aby sama wypełniała pola które może (datę skanowania, login osoby skanującej, kod kreskowy i kilka innych), zaś reszta danych pozyskiwana jest automatycznie z systemów zewnętrznych. Na przykład: jeśli na dokumencie występuje kod kreskowy z systemu sprzedaży to  dane klienta są pobierane z tego systemu. Jeśli kodu kreskowego brak to konsultant ma za zadanie wpisać ręcznie tylko identyfikator klienta – pozostałe dane klienta zostaną pobrane z systemu billingowego. Konsultant musi interweniować w sytuacjach wyjątkowych, np jeśli np kod kreskowy jest nieczytelny dla aplikacji skanującej (wtedy albo wpisuje go ręcznie albo nakleja nowy kod i podaje numer dokumentu). Procedura zautomatyzowana obejmuje również walidację danych (wykrywanie brakujących lub błędnych numerów klienta/numerów dokumentu/kodów kreskowych). W przypadku wykrycia nieprawidłowości odpowiedni pracownicy otrzymują zadanie poprawy indeksów w dokumencie.

Oszczędność na pojedynczym dokumencie jest rzędu minuty-dwóch. Ale po pomnożeniu tego przez ok 10-15 tysięcy dokumentów dziennie wychodzi nam oszczędność na poziomie trzydziestu osobo-dni (każdego dnia). Oznacza to trzydzieści etatów których nie trzeba tworzyć – czyli niewielkie w sumie usprawnienie w tak masowym procesie daje całkiem niezły efekt finansowy.

Realizacja

Do zrealizowania tej zautomatyzowanej procedury indeksacji użyliśmy NGinn. Działa to tak że po zeskanowaniu dokumentu jest on umieszczany w systemie EDMS (elektroniczne archiwum dokumentów), który to system powiadamia NGinn o pojawieniu się nowego dokumentu. W tym momencie NGinn uruchamia proces automatycznej indeksacji który odpowiada za uzupełnienie dokumentu o odpowiednie metadane. Oto schemat tego procesu:

1. Pobranie dokumentu z systemu EDMS.
   Po zeskanowaniu dokumentu i umieszczeniu go w systemie EDMS system ten powiadamia NGinn o pojawieniu się nowego dokumentu przekazując wewnętrzny identyfikator tego dokumentu. Na podstawie tego identyfikatora NGinn pobiera dane dokumentu z systemu EDMS. Pobierane są m. in. typ dokumentu, nr dokumentu, kod kreskowy i identyfikator klienta.
2. Pobranie danych klienta z systemu bilingowego. Jeśli dokument zawiera identyfikator klienta a nie zawiera kodu kreskowego, odpytujemy system bilingowy o dane klienta na podstawie podanego numeru klienta. Odpytanie odbywa się poprzez wywołanie odpowiedniego web service. Jeśli dane klienta zostaną odnalezione idziemy do kroku 4, w przeciwnym razie do kroku 5.
3. Pobranie danych dokumentu z systemu sprzedaży – dokumenty z systemu sprzedaży zaopatrzone są w odpowiedni kod kreskowy, identyfikowane są też numerem dokumentu. NGinn odpytuje system sprzedażowy o dane tego dokumentu na podstawie kodu kreskowego lub nr dokumentu, wśród danych zwracanych przez system sprzedażowy są również informacje o kliencie. Jeśli dokument zostanie odnaleziony przechodzimy do kroku 4, w przeciwnym razie do kroku 5.
4. Aktualizacja dokumentu w EDMS. Jeśli dane klienta/dokumentu zostały odnalezione w odpowiednim systemie, NGinn aktualizuje dane dokumentu w EDMS dzięki czemu jest on opisany pełnymi metadanymi.
5. Zadanie ‘popraw indeksy’. Jest to zadanie ręczne zakładane w systemie obsługi zgłoszeń. Zadanie to pojawia się na liście spraw odpowiedniej grupy konsultantów (system obsługi zgłoszeń jest uniwersalnym systemem w którym rejestrowane są zgłoszenia klientów oraz inne rodzaje spraw, m.in. zadania). Zadanie zawiera odnośnik do dokumentu w EDMS oraz informacje o tym które indeksy należy poprawić. Po poprawieniu indeksów konsultant zgłasza zakończenie realizacji zadania i proces powtarza się od kroku 1. Istnieje możliwość zakończenia zadania z opcją ‘pomiń walidację’, która powoduje przejście do kroku 6 bez dalszej walidacji danych dokumentu – jest to potrzebne w wyjątkowych przypadkach, np gdy dane klienta w na dokumencie są nieaktualne.
6. Poprawny przebieg procesu indeksacji kończy się przekazaniem dokumentu do systemu obsługi zgłoszeń. NGinn przekazuje dane dokumentu do systemu obsługi zgłoszeń, który na podstawie tych danych zakłada odpowiedniej treści zgłoszenie i przypisuje je do Back Office, do grupy konsultantów odpowiedzialnych za obsługę danego rodzaju zgłoszeń. NGinn na kroku 6 kończy swoją rolę i nie bierze udziału w obsłudze zgłoszenia.

W celu zaimplementowania tego procesu do standardowego zestawu zadań NGinn musiały zostać dołączone dwa typy zadań służące do integracji z systemem EDMS: zadanie “Pobierz dokument z EDMS” (krok 1) oraz “Zaktualizuj dokument EDMS”, czyli krok 4. Zadania te wykorzystują API integracyjne systemu EDMS. Pozostałe etapy procesu zostały zrealizowane za pomocą zadań standardowo udostępnianych przez NGinn. Dodatkowo, w systemie obsługi zgłoszeń został dodany interfejs integracyjny dla NGinn pozwalający NGinn zakładać zadania w tym systemie oraz raportować do NGinn zakończenie realizacji zadań przez konsultantów.

Jak łatwo policzyć, proces indeksacji wykorzystuje funkcje czterech różnych systemów: EDMS, billingu, systemu sprzedażowego oraz systemu obsługi zgłoszeń. Można powiedzieć zatem ze oprócz funkcji narzędzia ‘BPM’ NGinn pełni też rolę narzędzia integracyjnego zarządzającego przepływem danych między poszczególnymi aplikacjami.

Przebieg wdrożenia

Projekt był realizowany metodą szybkiego prototypowania. Klient bardzo szybko (w ciągu 2 tygodni) od rozpoczęcia prac otrzymał pierwszą wersję oprogramowania do testów. Podczas testów oprócz pewnej liczby błędów wykryto też rozmaite przypadki nietypowe które nie były przewidziane w wymaganiach. Każdy taki wyjątek wymagał modyfikacji procesu – praktycznie na bieżąco dostarczaliśmy klientowi zmodyfikowaną wersję procesu i testy mogły być kontynuowane. W sumie testowane było 7 albo 8 wersji procesu, każda kolejna zawierała obsługę przypadków nie przewidzianych przez poprzednią iterację. Testy trwały około 3 tygodni, później nastąpiło przeniesienie funkcjonalności na środowisko produkcyjne. W środowisku produkcyjnym wykryto jeszcze jeden albo dwa ‘nietypowe’ przypadki wymagające pilnego obsłużenia, co zaowocowało dwiema kolejnymi wersjami procesu.

Podczas testowania niektóre z cech NGinn okazały się bardzo przydatne:

• możliwość używania kilku wersji procesu jednocześnie. W przypadku testów ‘na produkcji’ używana była stabilna wersja procesu zaś eksperymentalne były uruchamiane tylko na potrzeby testów. Po przetestowaniu nastąpiło przełączenie domyślnej wersji procesu na nową według której były obsługiwane kolejne dokumenty. Nie było potrzeby migracji procesów w toku – dokończyły one swój bieg według starej wersji.
• zmiany definicji procesu ‘w locie’, bez zatrzymywania systemu pozwalały na bieżąco uwzględniać uwagi testerów a na produkcji przełączać się między wersjami procesu w sposób niezauważalny dla użytkowników

Po wdrożeniu

Obserwacja systemu po wdrożeniu pokazała kilka faktów:

• Mimo niezbyt rozbudowanej konfiguracji serwera nie ma żadnych problemów wydajnościowych, NGinn obciąża procesor i pamięć w niewielkim stopniu. Baza danych bez problemu radzi sobie z obsługą danych generowanych przez NGinn.
• Po ustabilizowaniu definicji procesu system działa praktycznie bezproblemowo 24 godziny na dobę,  7 dni w tygodniu. Przez ponad miesiąc nie było żadnego problemu technicznego, wszystkie dokumenty zostały zaindeksowane zgodnie z definicją procesu. Mam doświadczenie w pracy z różnymi systemami i naprawdę rzadko zdarza się żeby system działał tak stabilnie zaraz po uruchomieniu produkcyjnym.
• NGinn jest bardzo odporny na awarie systemów zewnętrznych. W naszym procesie indeksacji biorą udział cztery systemy i dość często zdarza się że któryś z nich na jakiś czas ‘wypada’, np nie można się z nim połączyć lub zgłasza błędy. W takiej sytuacji NGinn jest w stanie przeczekać okres niedostępności systemu i wznowić procesy kiedy system zewnętrzny zacznie odpowiadać. Dzieje się tak dzięki mechanizmowi ponawiania w NGinn który przez okres max. 3 dni próbuje ponownie wykonać nieudane operacje. Oznacza to też że po ustąpieniu awarii administrator systemu nie musi nic robić żeby obsługa procesów w NGinn była kontynuowana.
• Standardowo NGinn przechowuje stan wszystkich zadań w bazie danych. Informacje te nie są usuwane po zakończeniu zadania, dlatego ilość gromadzonych danych jest bardzo duża. Proces indeksacji składa się z 6-ciu zadań, co prawda nie wszystkie występują w każdym przebiegu, ale oznacza to że dla każdego indeksowanego dokumentu zapisywane jest 3-6 rekordów w bazie NGinn, co dziennie daje 50-100 tysięcy rekordów. Konieczny jest jakiś mechanizm czyszczący który będzie usuwał stan zakończonych zadań.
• Przy dużej ilości przetwarzanych dokumentów potrzebne jest narzędzie monitorujące pozwalające śledzić pracę NGinn i wykrywać ewentualne problemy. Dobrze by też było mieć jakieś narzędzie pozwalające na raportowanie przebiegu procesów. Na potrzeby tego konkretnie wdrożenia zostało uruchomione niezbyt rozbudowane narzędzie pozwalające śledzić podstawowe informacje – np aktywność w NGinn w ciągu ostatnich 24 godzin – poniżej obrazek z tego narzędzia:

Podsumowując, myślę że udało się pokazać że za pomocą NGinn można realizować rzeczywiste wdrożenia i narzędzie to potrafi wspierać procesy biznesowe nie tylko na papierze. Mam nadzieję na uruchomienie kolejnych procesów dla tego samego klienta i myślę że to pozwoli rozbudować NGinn o kolejne przydatne funkcje.

Filed under: Bez kategorii | automatyzacja procesu, DMS, EDMS, integracja, obsługa dokumentów, produkcyjnie, Wdrożenia Projekty Realizacja|2 Comments