Jak stosować zdarzenie error wewnątrz procesu?

W pracy korzystam z narzędzia napisanego w VBA (ang. Visual Basic for Applications) do generowania wynikowego pliku tekstowego z arkusza kalkulacyjnego. Jednym z kroków jest odczytanie liczby rekordów i przypisanie jej do zmiennej pomocniczej.

Podczas tworzenia narzędzia założyłem zmienną jako Liczba Całkowita (typ Integer). Podczas próby wykonania nowego raportu pojawił się błąd „overflow”. Oznacza on, że nie można przepisać wartości większej niż dopuszcza to typ pola (na diagramie zdarzenie błąd wartości). Po poprawieniu (zmiana na Long) mechanizm zadziałał poprawnie.

Podany przykład można byłoby zobrazować następująco na diagramie:

Na powyższym diagramie jest zaprezentowane zastosowanie zdarzenia tzw. intermediate o charakterze błędu (ang. error event), co powoduje przerwanie wykonania algorytmu. Obrazuje to zdarzenie końcowe z krzyżykiem.  Tego typu zdarzenie błędu umieszczamy na brzegu czynności mogącej spowodować błąd (na diagramie Odczytaj liczbę wierszy) i  łączymy z czynnością obsługującą (na diagramie Wyświetl komunikat) lub z zdarzeniem końcowym procesu.

Reklama

Jak korzystać z bramek opartych o zdarzenia?

Wielokrotnie byłem świadkiem w kolejce w sklepie, gdy pracownik sklepu w pewnym momencie przerywał kasowanie produktów, tzn. automatyczne odczytywanie kodów (czynność Odczytaj kod na diagramie) produktów i ich dodawanie do listy produktów. W tym momencie brał produkt i ręcznie przepisywał kolejne cyfry kodu kreskowego do odpowiedniego miejsca na ekranie kasy (czynność Przyjmij kod na diagramie). Pozwalało to na dodanie tak odszukanego kodu, a następnie produktu do listy produktów.

Produkt musi się znaleźć w określonym obszarze kasy (czynność Namierz produkt na diagramie), aby czujniki czytnika mogły zeskanować kod (czynność Odszukaj kod w zasięgu czytnika na diagramie). Czasami kod musi być dokładnie w pozycji równoległej do poziomu kasy, a czasami może być pod innym kątem.

Na powyższym diagramie (w BPMN) najpierw następuje rozgałęzienie za pomocą bramki (ang. gateway) a potem połączenie dwóch ścieżek w jedną przed akcją, która jest wspólna dla obydwu ścieżek. W tym miejscu także jest zastosowana bramka. Jest to jedna ze znanych dobrych praktyk w stosowaniu “bramek”, czyli rozgałęzienie i połączenie ścieżek jest zakończone bramką. Element zaznaczony na niebiesko.

Każde wyjście z bramki, opartej o zdarzenia (ang. event-based gateway), powinno być połączone ze zdarzeniem. Pozwala to jednoznaczenie wskazać w jakiej sytuacji następuje wyjście na daną ścieżkę, czyli jakie zdarzenie powoduje przejście tą ścieżką. Jest to druga ze znanych dobrych praktyk w stosowaniu bramek. Oznaczone na zielono na diagramie.

Istnieje więcej dobrych praktych w tym obszarze, jednakże już te dwa znacznie wpływają na poprawę czytelności diagramu. Dzięki nim wiemy, które ścieżki kiedy występują i w których momencie i na jakich warunkach następuje powrót z rozgałęzienia i przejście do dalszej części procesu.

O zdarzeniach pisałem już kilkakrotnie w różnym kontekście:

• Jak podejmowane są decyzje w procesie? – wykorzystanie różnych typów zdarzeń.
• Co to jest tokem? Czyli jak się on przemieszcza po po procesie.
• Rozróżnienia ścieżek alternatywnych i wyjątków

Proces „oczami” metody 5W2H

Na szkoleniach miękkich w różnych sytuacjach jest przytaczana metoda 5W2H, służąca do identyfikacji oraz analizy problemów. Metoda ta polega na zadaniu pytań: Kto? (ang. Who?), Co? (ang. What?), Gdzie? (ang. Where?), Kiedy? (ang. When?), Dlaczego? (ang. Why?) oraz Jak (ang. How?) i Ile? (ang. How much?). Metodę tę można także użyć do analizy procesu – poznania go, co jest pierwszym krokiem przed próbą jego poprawy.

Ponad rok temu opublikowałem na blogu wpis o marnotrawstwie w procesie. Proces z tego wpisu, dotyczący przygotowania raportu, jest idealnym przykładem do pokazania działania tej metody. Na diagramie przytoczono ten diagram z modyfikacjami –  uproszczenie oraz oznaczenie kroków, które pozwalają na odpowiedź na niektóre z tych pytań.

Odpowiedzi na te pytania są następujące:

• Kto? Z kroków procesu można wywnioskować, że osoba odpowiedzialna za przygotowywanie raportów.
• Co? Efektem procesu jest przygotowanie raportu w postaci pliku i wydruku. Krok z efektem został zaznaczony na diagramie na czerwono.
• Gdzie? Proces nie odpowiada na to pytanie. Proces mógłby się odbywać w dowolnym podmiocie.
• Kiedy? Proces realizowany jest pojawieniu się danych źródłowych. Można założyć, że dane źródłowe są generowane cyklicznie. Krok został zaznaczony na zielono na diagramie.
• Dlaczego? Raport jest przygotowywany w procesie dla jego odbiorcy. Jest przekazywany po przygotowaniu. Może być używany do podejmowania decyzji.
• Jak? Raport jest tworzony ręcznie przez pracownika. Później generuje i drukuje plik PDF. Kluczowy krok zaznaczony jest na niebiesko.
• Ile? Proces realizowany w ten sposób jest pracochłonny. Wykonywane są ręcznie kolejne czynności. W tym czasie pracownik mógłby wykonać inne zadania, więc ponoszony jest pewien koszt. Pewne czynności wydają się nieuzasadnione (analiza we wskazanym wcześniej wpisie).

Spoglądając na proces z takiej perspektywy, możemy także określić elementy, których tak naprawdę nie wiemy o procesie lub tylko przypuszczamy, że jest on realizowany w określony sposób. W powyższych odpowiedziach, w niektórych punktach używałem stwierdzenia, że “można założyć” lub “wywnioskować”. Dodając do procesu:

• informację o częstotliwości (zmieniając zdarzenie inicjujące z “pustego” na czasowe) lub
• użytkowniku (umieszczając proces w prostokącie z nazwą roli) lub
• odbiorcy raportu (poprzez umieszczenie akceptującego raport)

można usprawnić poszukiwanie odpowiedzi na powyższe pytania. Takie działania powodują, że diagram procesu jest lepiej udokumentowany i łatwiej nim zarządzać. Elementy zostały zasygnalizowane na diagramie linią przerywaną.