Posts Tagged ‘BPMN’

h1

Przez telefon czy na stronie?

11 stycznia, 2020

Chyba każdy zna ten moment gdy jest przerwa w dostawie prądu – czy to chwilowa objawiająca się tylko mrugnięciem czy też dłuższa, wymagająca określonych działań (sięgnięcia po latarkę, świeczkę czy inny sprzęt). Gdy ostatnio w sobotę, nastąpiły 3 krótkie „mrugnięcia” a później przyszedł do mnie sąsiad z pytaniem czy coś wiem, przypomniałem sobie o innej sytuacji. Pod koniec roku 2019, dzień przed wigilią byłem w domu z rodziną, mijała właśnie godzina 19 i nagle ciemność – na całym osiedlu. Niezły moment na taki problem – ludzie przygotowują święta, wstawione ciasta, mięsa i inne potrawy a tu brak prądu. Złapałem za telefon i szukam informacji. Za pierwszym razem nic nie znalazłem, a za drugim pojawiła się informacja na mapie dostawcy prądu o  awaryjnej przerwie w dostawie prądu, która jest szacowana na 2 godziny. Minęło kilkanaście minut i prąd znów był dostarczany. A po 20 powtórka, znów ciemność – tym razem na krócej. Informacja na stronie się nie zmieniła.

Mogę sobie wyobrazić, że w momencie pierwszego wyłączenia część osób złapało za telefon i zamiast szukać informacji (sprawdzać samodzielnie) zadzwoniło na pogotowie energetyczne lub na infolinię dostawcy prądu. Mogło być też tak, że ktoś mógł pójść do sąsiada i spytać czy coś wie o na przykład planowanym wyłączeniu prądu. Wyobraźmy sobie jak mógłby wyglądać proces od strony dostawcy, który łączy te dwie możliwości – stronę z informacjami i telefony.

prad_zgloszenie400px

Dostawca na podstawie zgłoszeń telefonicznych i ich weryfikacji mógłby umieścić informację na stronie o awarii. Dzięki czemu zaspokoi potrzebę informacji tych sprawdzających i potencjalnie zmniejszy liczbę telefonów z regionu objętego awarią. Może także mieć system monitoringu, który wskaże mu, że taka awaria nastąpiła. Wejściem do procesu może być zgłoszenie telefoniczne od odbiorcy lub własny monitoring. Wyjściem może być informacja na stronie. Skutkiem pewnie będzie także wysłanie ekipy technicznej w rejon objęty awarią lub inne specyficzne działania.

Na powyższym diagramie próbowałem przedstawić omówiony proces. Na diagramie w notacji BPMN wykorzystałem zdarzenie inicjujące proces, powstałe na bazie zgłoszenia/komunikatu przekazanego przez „zewnętrznego” aktora. Jest to tzw. message start event – jeden z typów zdarzeń (ang. events) używanych w notacji BPMN służącej do modelowania procesów. To zdarzenie na diagramie jest zaznaczone na żółto. Opisany proces nie miałby miejsca, jeżeli takie zdarzenie nie nastąpi. Brak telefonów lub innych zgłoszeń oznacza prawdopodobnie, że nie ma awarii.

Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego blogahttps://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.

h1

Automatyczne reguły oparte o wzorce

11 lipca, 2018

Automatyczna odpowiedź: Potwierdzenie otrzymania wiadomości. Państwa wiadomość została przekazana do właściwego pracownika […] ”, a dalej podpis i informacja „Wiadomość została wygenerowana automatycznie, prosimy na nią nie odpowiadać.”. Takiego maila otrzymałem w odpowiedzi na wiadomość skierowaną do podmiotu gospodarczego, wskazując w tytule numer sprawy. Nie otrzymałem jeszcze odpowiedzi na to zgłoszenie. Jednak mogę sobie wyobrazić co się stało na poziomie skrzynki odbiorczej. Mechanizm obsługujący, pobrał tytuł wiadomości, sprawdził do kogo powinna trafić sprawa, a potem wysłał maila z powyższą odpowiedzią. Poniższy diagram w BPMN prezentuje przebieg takiego procesu automatycznego.

buss_rule_1_450px

Na diagramie znajduje się tym zadania „reguła biznesowa” (ang. business rule task), o której pisałem już kilkakrotnie, obrazując ją różnymi przykładami oraz zastosowaniami. W ramach tego kroku następuje próba odnalezienia osoby przyporządkowanej do określonych sformułowań lub numerów użytych w tytule. Mogą to być poszukiwania dokładnego odpowiednika lub zakresów wartości (wzorca). z uwzględnieniem ewentualnych określeń poprzedzających lub następujących po poszukiwanym fragmencie. Reguła może też przewidywać, że inne przypadki są przesyłane do ręcznego przyporządkowania. Reguły mogłyby także zakładać priorytety sprawdzania.

Fragment tytułu (wzorzec) – przykłady Przyporządkowanie
[NR SPRAWY] 2018/06/1* Osoba X
[NR SPRAWY] 2018/06/0* Osoba Y
[NR SPRAWY] 2017/* Skrzynka ogólna
….  
*PRODUKT A* Zespół A
*PRODUKT B* Zespół B
 
*PRODUKT N* Zespół N
RE/ODP:*   Pierwotny nadawca
(lub osoba zastępująca)
brak przyporządkowania Skrzynka ogólna
h1

Notacja uniwersalna dla procesu

28 lutego, 2017

Wiele symboli, grafik, mechanizmów, które nas otacza każdego dnia jest zrozumiała niezależnie od posiadanego wykształcenia, narodowości czy wcześniejszych doświadczeń. Gdy widzimy “+” w wyrażeniu, to wiemy, że coś dodajemy do czegoś. Gdy widzimy czerwone światło na ulicy, to oznacza brak możliwości ruchu. Gdy widzimy pięciolinię to myślimy o muzyce. Podobnie jest z wieloma innymi symbolami. Symbole są mniej lub bardziej upowszechnione. Korzystanie z nich ułatwia komunikację, wymianę pomysłów oraz idei między różnymi odbiorcami. Opisane przykłady wskazują na stosowanie tzw. notacji uniwersalnej, z ang. universal notation.

upn450px

W przypadku procesów biznesowych, także istnieje taka notacja, która pozwala na zaprezentowanie przebiegu procesu w sposób zrozumiały dla większości odbiorców. Jest to tzw. Universal Process Notation, po przetłumaczeniu Uniweralna Notacja dla Procesów. W tej notacji, jak widać na powyższym diagramie są stosowane obiekty (ramki), zawierające informację o nazwie czynności oraz jej wykonawcy oraz połączenia opisujące wejścia i wyjścia poszczególnych czynności. W odróżnieniu od notacji BPMN, którą się często posługuję w ramach diagramów na blogu, zapis jest zdecydowanie uproszczony.

Na powyższym diagramie zapisałem przykładowy proces dot. kolejkowania, gdzie występowały dwie różne role – użytkownik oraz system. Produkty poszczególnych kroków były różne i można je jednoznacznie określić: Otrzymane żadanie klienta, Wypełniony formularz, Zapisane zgłoszenie, Parametry listy ustalone, Sprawa dodana do kolejki. Strzałki informują o kolejności kroków oraz kierunku przekazywania wejść. Dodatkowo mamy ponumerowane kroki, aby łatwiej było się do nich odnosić. Pozwalają też zidentyfikować pierwszy krok (proste zastosowanie uniwersalnej notacji związanej z liczbami).

h1

Proces w „basenie”

2 stycznia, 2016

Podczas jednej z zeszłorocznych kontroli biletowych w pociągu, z rozpędu dałem do kontroli bilet powrotny. Konduktor próbuje uparcie  kilka razy odczytać kod, przeprowadzić jego weryfikację. Wreszcie spisuje kod na kartce i oddaje mi bilet. Odchodzi, sprawdza bilety pasażerów. Nagle wraca i sytuacja sie powtarza. Mówi, że trzeba będzie kupić bilet ponownie, bo ten jest nieprawidłowy i pewnie został anulowany. Biorę od niego bilet, patrzę i nagle okazuje się, że bilet jest na pociąg powrotny. Wpatrywał się w niego kilka minut i tego nie zauważył, nawet spisując jego numer. Odszukuję właściwy bilet, daję go i wszystko było już ok.

weryf_biletu_1_450px

Przytoczona sytuacja obrazuje prosty proces, opisany od strony pracownika kolei, składający się z 2 tzw. aktorów – Konduktora i Systemu kontroli. W takiej sytuacji, gdy proces jest ciągły w ramach jednej jednostki/podmiotu (pracowników kolei), stosujemy na diagramie (w BPMN) tzw. basen (ang. pool) i pola/pasy (ang. lane). Są to poziomo lub pionowo przedstawione obszary, przy czym w ramach basenu (ang. pool), określającego np. jednostkę biznesową, są umiejscowione pasy (ang. lanes), określające aktorów/role (lub inne obiekty) z tej jednostki biznesowej (lub procesu). Powyższy diagram prezentuje taki uproszczony diagram, z wykorzystaniem tych elementów.

Dzięki takiej prezentacji mamy jednoznaczne wskazania kto, jakie i w ramach jakiej jednostki wykonuje czynności, składające się na proces. Między rolami/aktorami w ramach basenu nie są przesyłane komunikaty, proces jest ciągły. Nie mamy zdarzeń początkowych procesu w ramach każdego pasa, a jedynie przed czynnością/zadaniem, które występuje biznesowo jako pierwsza w procesie. Jako nazwa basenu może występować również nazwa procesu, w którym uczestniczą wskazane na pasach role.

h1

Jak korzystać z bramek opartych o zdarzenia?

14 listopada, 2015

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.

nakasie450

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:

h1

Kiedy zaczyna się proces

21 lutego, 2013

Oczekiwanie na zdarzenie w poprzednim wpisie było związane ze zdarzeniami, które mają miejsce w trakcie trwania procesu i pozwalają na jego kontynuowanie. Z kolei dzielenie klasy na pary, było związane ze zdarzeniami przerywającymi proces lub wymagającymi wykonania określonych kolejnych kroków. Obydwie sytuacje były związane z tzw. intermediate events.

W przypadku BPMN można rozróżnić również zdarzenia inicjujące dane proces – tzw. start events. Proces może rozpoczynać się w wyniku wystąpienia danego zdarzenia (np. momentu czasu) lub jednego z wielu zdarzeń (np. czas lub wiadomość). Możliwa jest także sytuacja, gdy musi wystąpić równocześnie kilka zdarzeń. Dla każdej z tych sytuacji, język BPMN przewiduje różnego typu oznaczenia zdarzeń. Oznaczenia te pozwalają szybko zorientować się, podczas czytania diagramu, jaki rodzaj zdarzenia inicjuje proces.

Załóżmy, że mamy następującą sytuację. Pewna jednostka po zakończeniu każdego miesiąca kalendarzowego przygotowuje raport. Na przygotowanie raportu składa się określenie parametrów raportu, wykonanie raportu w systemie oraz przygotowanie komentarza do raportu. Taki proces jest inicjowany przez zdarzenie o typie określenia czasu (ang. timer), co widoczne jest na poniższym diagramie.proces_timer450

Załóżmy, że w pewnym momencie podjęto decyzję, że raport może być także przygotowywany na żądanie, zgodnie z wytycznymi podanymi we wniosku. Poniższy diagram w BPMN prezentuje dodanie takiego zdarzenia o typie wiadomości (ang. message). Jako element uzupełniający kroku „Określ parametry raportu” dodano informację o danych wejściowych (opcjonalnych).process_message450

Obok wskazanych typów zdarzeń inicjujących BPMN przewiduje jeszcze kilka ich rodzajów: niezdefiniowany (ang. none), warunkowy (ang. conditional), sygnał (używany przy łączeniu procesów, ang. signal), różne zdarzenia (ang. multiple), równoczesne zdarzenia (ang. parallel).

h1

Specjalistyczny pośrednik

20 lipca, 2012

Ponad roku, przy okazji omawiania wzorców „Fire and Forget” oraz „Request-Response posłużyłem się przykładem procesu ETL. Jednym z etapów realizacji tego procesu, jest wyciąganie (ang. Extract) danych. Wskazałem przykład zastosowania wzorca „Request-Response” (Pytanie – Odpowiedź) oparty na odpytywaniu bazy danych (dokładnie DBMS, tj. Systemu Zarządzania Bazą Danych) o dane/informacje/status i zwracanie przez nią stosownej informacji. Były to sprawdzenie dostępności bazy (DB), pytanie o wielkość danych (WD) i pobieranie kolejnych rekordów danych (DZ – dane zapytania). Takie działania mogą się odbywać poprzez bezpośrednie zapytania w języku SQL. Fragment oznaczony jako „bez wzorca” na diagramie poniżej przedstawia takie bezpośrednie odpytania.

Załóżmy jednak, że mamy odbytać kilka baz i powiązać dane ze sobą. Chcielibyśmy równocześnie uniknąć sytuacji namierzania się na każdą bazę osobno, identyfikowania jej strukury, a chcielibyśmy przekazać żądanie: sprawdź, pobierz, zapytaj. W takiej sytuacji między procesem Extract a poszczególnymi bazami danych można umieścić narzędzie pośredniczące, które wykona określone operacje i odpowiednio rozdzieli zadania po DBMS poszczególnych baz źródłowych.

W takim celu można zastosować wzorzec projektowy Fasada (ang. Facade), który zmniejszy liczbę połączeń i zależności między systemami. Wiąże się to utworzeniem „pośrednika” przyjmującego żądania i wysyłającego je do odpowiednich wykonawców. Sytuację taką prezentuje powyższy diagram w BMPN w części „wzorzec”.

Zaletą jest to, że mamy jeden interfejs, który można wykorzystać w różnych procesach, bez konieczności ingerowania w systemy źródłowe. Modyfikując połączenie między pośrednikiem a bazą (np. przeniesienie w inne miejsce, inna konfiguracja, sposób zapytania) modyfikujemy je tylko w jednym miejscu, bez konieczności zmiany procesów wywołujących. Takie rozwiązania są stosowane w implementacji systemów opartych o usługi (SOA).