Realizacja procesu biznesowego w organizacjach biurowych (w przeciwieństwie np. do fabryk) nieuchronnie wiąże się z przepływem dokumentów. Czy pojawienie się dokumentów wpływa na sposób, w jaki modelujemy procesy? Czy tworząc model procesu powinniśmy się w ogóle przejmować dokumentami? W projekcie prowadzonym dla jednej z instytucji rynku ubezpieczeniowego, w ramach którego kierowałem zespołem analityków tworzących model procesów biznesowych, znaleźliśmy bardzo ciekawą technikę modelowania procesów, w których pojawiają się dokumenty.
Prosty proces biurokratyczny
Technikę modelowania procesów z uwzględnieniem przepływu dokumentów omówimy na hipotetycznym procesie wnioskowania o wypłatę becikowego. Na pierwszym spotkaniu analitycznym dowiadujemy się, że proces ten przebiega mniej więcej następująco:
- otrzymanie od petenta wniosku o becikowe;
- sprawdzenie poprawności i kompletności wniosku przez pracownika;
- jeżeli wniosek niepoprawny lub niekompletny, odesłanie z prośbą o poprawienie lub uzupełnienie;
- jeżeli wniosek jest poprawny, lub otrzymano poprawienie lub uzupełnienie, następuje sprawdzenie, czy dziecko zostało zarejestrowane;
- jeżeli dziecko nie zostało zarejestrowane, odesłanie wniosku z prośbą o dostarczenie dowodu posiadania dziecka;
- jeżeli dziecko zostało zarejestrowane, lub po otrzymaniu i zweryfikowaniu dowodu posiadania dziecka, następuje wydanie decyzji o przyznaniu lub nieprzyznaniu becikowego, a nastepnie jej przesłanie do petenta;
- jeśli becikowe przysługuje, następuje wypłata;
- petent ma możliwość odwołania się od decyzji; odwołanie takie musi być obsłużone.
Opisany proces moglibyśmy zamodelować w sposób pokazany na rysunku 1.
Rysunek 1. Proces obsługi wniosku o wypłatę beckowego - model ogólny
Korespondencja
Dla utrudnienia załóżmy, że wymiana dokumentów odbywa się korespondencyjnie. Nie ma więc możliwości np. natychmiastowego poprawienia wniosku przez petenta w obecności pracownika. Pomiędzy każdym wysłaniem dokumentu do petenta a otrzymaniem od niego odpowiedzi mija pewien czas. Wykonanie procesu jest wtedy jakby zawieszone. I tu zaczynają się schody. Widzimy, że powyższy model jest wysokopoziomowy i wymaga uszczegółowienia. Powinniśmy więc uzyskać od klienta odpowiedzi na sporo pytań.
Pytanie: Co zrobić, gdy po odesłaniu wniosku z prośbą o poprawienie lub uzupełnienie, petent nie prześle go ponownie?
Odpowiedź: Przy braku odpowiedzi na pismo skierowane do petenta, po trzech miesiącach sprawa jest zamykana.
Z podejmowaniem decyzji w ramach procesu potrafimy sobie świetnie radzić. Uwzględnimy więc tą odpowiedź tak jak na rysunku 2, wykorzystując bramkę XOR sterowaną drarzeniami (ang. event-based XOR gateway).
Rysunek 2. Proces obsługi wniosku o wypłatę becikowego - uszczegółowienie
Pojawiają się jednak kolejne pytania:
Pytanie: Co zrobić, gdy po otrzymaniu od petenta poprawionego wniosku, ponownie otrzymamy wniosek z kolejnymi poprawkami?
Odpowiedź: Jeżeli decyzja nie została jeszcze podjęta, należy uwzględnić nadesłane poprawki, w przeciwnym razie, należy wysłać do petenta informację o nieuwzględnieniu poprawek.
Pytanie: Co zrobić jeśli w odpowiedni na nasze pismo otrzymamy od petenta odpowiedź nie odnoszącą się do naszego pisma, lub nie mającą sensu w naszym procesie (np. list z pogróżkami lub kopię pozwu sądowego)?
Odpowiedź: Mamy obowiązek przeanalizować każde, nawet najbardziej bezsensowne pismo petenta, a następnie odpowiedzieć na nie zgodnie z prawem, wykorzystując swoją wiedzę i intuicję.
Dociekliwy analityk powinien oczywiście zadać więcej tego rodzaju pytań. Możemy oczywiście próbować modelować każdą tego typu sytuację, wstawiając do diagramu procesu kolejne rozgałęzienia. Jednak im więcej w procesie takich miejsc, gdzie dalsza obsługa zależy od dokumentów otrzymanych od petenta, tym bardziej nasz diagram stanie się skomplikowany i nieczytelny. A może można inaczej?
Kto steruje przebiegiem procesu?
Warto, żebyśmy sobie w tym momencie uświadomili, że tak na prawdę to nie pracownicy instytucji wypłacającej becikowe sterują przebiegiem tego procesu, lecz uczestniczący w nim petent. Jego działania są całkowicie poza kontrolą naszej organizacji, nie możemy więc zakładać, że zachowa się zgodnie z naszymi oczekiwaniami. Wręcz przeciwnie, powinniśmy być przygotowani, że w najbardziej nieoczekiwanym momencie odwoła swój wniosek, prześle kopię pozwu sądowego lub pismo nie mające związku ze sprawą, na które jednak mamy obowiązek odpowiedzieć.
Mówiąc językiem informatyki, przebieg procesu jest sterowany zewnętrznymi zdarzeniami, które nie zależą od właściciela procesu. Skoro tak, to czy warto rozbudowywać schemat procesu, umieszczając w każdym punkcie, w którym oczekujemy odpowiedzi od petenta, całe spektrum zdarzeń - począwszy od tych oczekiwanych, a kończąc na tych najbardziej nieprawdopodobnych?
Modelując procesy we wspomnianym na wstępie projekcie dla instytucji ubezpieczeniowej, próbowaliśmy początkowo podążać wg opisanego powyżej schematu myślowego. W końcu doszliśmy jednak do wniosku, że istotą procesu sterowanego zdarzeniami będącymi poza naszą kontrolą, jest oczekiwanie na jedno ze zdarzeń, a nastepnie jego obsługa. Nasz proces - po wykonaniu kilku zadań związanych ze wstępną obsługą wniosku - trafiał do centralnego punktu - zadania, które nazwaliśmy "Analiza sprawy". W tym miejscu proces oczekiwał na dowolne ze zdarzeń. Po obsłudze każdego zdarzenia proces trafiał ponownie do zadania "Analiza sprawy".
Schemat procesu wyglądał więc tak jak na rysunku 3. Ze względu na wygląd diagramu wokół zadania "Analiza sprawy", nazwaliśmy nasz wzorzec "lampkami choinkowymi". Zauważmy, że np. po wysłaniu prośby o poprawienie lub uzupełnienie wniosku, jesteśmy gotowi przyjąć i obsłużyć nie tylko uzupełniony wniosek, ale także dowolne inne zdarzenie.
Rysunek 3. Proces obsługi wniosku o wypłatę becikowego - model "lampek choinkowych"
Który sposób jest lepszy?
Czy zatem przedstawiony na rysunku 1. model jest niepoprawny? Nie, jest to po prostu model bardziej ogólny, wysokopoziomowy. Zanim przeanalizujemy szczegóły i zadamy wszystkie kłopotliwe pytania, powinniśmy poznać ramowy przebieg procesu wg podstawowego scenariusza (tzn. bez nieoczekiwanych zdarzeń) i stworzyć jego model, taki jak na rysunku 1. Model z rysunku 3. jest po prostu uszczegółowieniem modelu przedstawionegu na rysunku 1. Uszczegółowieniem, które w sprytny sposób uwzględnia charakter tego procesu.
W wielu przypadkach do dalszej pracy wystarczy nam ogólny model z rysunku 1. Będzie tak np. wtedy, gdy projektujemy system informatyczny wspierający wykonanie procesu, lecz nie oparty na mechanizmach przepływu prac (ang. workflow). Wtedy model procesu pełni funkcję czysto informacyjną i nie przekłada się bezpośrednio na funkcjonalność systemu. Jednak czasami - np. podczas wdrażania systemu przepływu prac - niezbędne staje się szczegółowe zamodelowanie procesu ze wszystkimi, nawet najmniej prawdopodobnymi scenariuszami wyjątkowymi. Wtedy musimy zadać długą serię kłopotliwych pytań, na które często nawet klient nie zna jednoznacznej odpowiedzi, po to, aby zrozumieć i zamodelować specyfikę procesu.
Szymon Zioło
Komentarze