Archive for the ‘BPMN/BPML’ Category

h1

Jak korzystać z bramek opartych o zdarzenia?

Listopad 14, 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:

Reklamy
h1

Obydwa czy pierwszy lepszy?

Marzec 14, 2013

Wyobraźmy sobie, że, czysto hipotetycznie, chcemy przesunąć po gąbce stalową kulkę. Nie trudno sobie wyobrazić taką sytuację, nawet mając świadomość, że jest absurdalny problem. Można to zrobić na dwa sposoby: popychając kulkę lub uciskając gąbkę, a kulka będzie się przesuwać tocząc po nierówności. Chciałbym skupić na tym drugim przypadku. Mamy dwie czynności: Utwórz wgłębienie i Przesuń kulkę (działanie automatyczne) wykonywane w tym samym momencie i Zwolnij nacisk wykonywane potem.

Załóżmy, że powyższe zadanie zostało przedstawione za pomocą diagramu procesu, używając BPMN, a w szczególności przez pomyłkę umieszczono jako element łączący tzw. bramkę OR (ang. inclusive OR merge). Sytuację tę przedstawia wariant A na poniższym diagramie. Specyfika tego elementu oznacza, że proces jest kontynuowany, jeżeli do bramki dotrze tzw. token z dowolnej ze ścieżek przychodzących. Gdyby automat wykonywał zadanie Utwórz wgłębienie, to kulka w pewnym momencie mogłaby zostać w innym miejscu gąbki niż początek wgłębienia, ponieważ operacja Zwolnij nacisk wykonana byłaby za szybko.process_forks450

Diagram można łatwo poprawić, poprzez umieszczenie elementu tzw. bramkę AND (ang. paraller (AND) joining). Element ten wskazuje, że przejście dalej w procesie jest możliwe dopiero po zakończeniu – otrzymaniu tzw. tokenów – wszystkich ścieżek przychodzących do bramki. Po wykonaniu wgłębienia należałoby poczekać na przesunięcie kulki, a następnie Zwolnić nacisk i utworzyć nowe wgłębienie. Poprawka zaprezentowana jest w ramach wariantu B.

Powyższy przykład pokazuje różnicę między dwoma elementami BPMN. Przepisując taki diagram na język maszynowy proces działałby niezgodnie z oczekiwaniem, jeżeli założeniem jest zakończenie dwóch równoczesnych czynności przed wykonaniem kolejnej.

h1

Decyzje pod kontrolą lub poza

Marzec 4, 2013

Dzisiaj ponownie przybliżę temat tzw. bramek wyłączających (ang. exclusive gates), czyli takich, z których możliwe jest tylko jedno wyjście do dalszego procesu. Około rok temu, wskazywałem we wpisie o podejmowaniu decyzji w procesie, że mamy dwa rodzaje tych bramek: oparte o dane (ang. data-based) oraz oparte o zdarzenia (ang. event-based). Podany wtedy przykład nie podawał wyraźnie rozróżnienia między tymi bramkami. Dzisiaj postaram się podać lepszy przykład.

process_decisions_d

Załóżmy, że nadal mówimy o procesie przygotowania raportu. Otrzymaliśmy wniosek i analizujemy, czy mamy komplet danych i są one spójne. Posługujemy się danymi dostępnymi tu i teraz, lokalnie, bez angażowania innych osób, chcemy zrealizować zlecone zadanie. I to jest jest właśnie specyfika bramek opartych o dane (ang. exclusive data-based). Na powyższym diagramie w BPMN jest to pierwsza z bramek, występująca po czynności Określ parametry wniosku. Wszystkie elementy są pod kontrolą wykonującego czynność. Wiemy dokładnie jakie czynności zostaną wykonane dalej.

W sytuacji jednak, gdy dane okażą się niespójne lub zabraknie danej do parametryzacji oczekiwanego raportu, pojawia się konieczność kontaktu z odbiorcą raportu. W tym momencie, dalszy przebieg procesu jest poza naszą kontrolą. To, co się dalej wydarzy jest uzależnione od odbiorcy raportu. To jest charakterystyczne dla bramek opartych o zdarzenia (ang. exclusive event-based). Na powyższym diagramie w BPMN jest to druga bramka. W sumie wiemy co dalej możemy wykonać w przypadku różnych działań odbiorcy, ale sama jego decyzja jest niezależna od samego procesu.

Myślę, że powyższy przykład lepiej oddaje charakter tych dwóch bramek. Innym przykładem może być ten z wysyłką listu/wykonywaniem telefonu, a odbiorem przesyłki/odebraniem telefonu.

h1

Kiedy zaczyna się proces

Luty 21, 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

Zadanie: Reguła biznesowa

Lipiec 16, 2012

W artykule „A New Information Systems Paradigm: What does a Business Analyst Needs to Know?” na ModernAnalyst.com autorzy przybliżają czytelnikom serwisu ewolucję systemów informacyjnych i sposobu ich tworzenia. Przechodzą od prostych rozwiązań, wymagających więdzy po stronie szeroko pojętego biznesu nt. choćby tworzenia zapytań SQL, aż do rozwiązań nowoczesnych, rozbudowanych z implementacją systemów klasy workflow, wspartych silnikami baz danych i nie tylko.

Jednym z elementów, które poruszają, jest zarządzanie regułami biznesowymi i tworzenie systemów wspierających ich definiowanie, przechowywanie oraz wykonywanie. Tzw. BRMS (Business Rules Management System, czyli System Zarządzania Regułami Biznesowymi) są nieodłącznym elementem tworzonych systemów. Powstają one trochę przez analogię do wspomnianych jakiś czas temu przeze mnie BPMS (Business Process Management System, czyli System Zarządzania Procesami Biznesowymi) czy DBMS (Data Base Management System, czyli System Zarządzania Bazą Danych).
Załóżmy, że mamy następującą regułę biznesową, wykorzystywaną w korespondencji wysyłanej z systemu:

  • Płeć: mężczyzna → powitanie: Pan;
  • Płeć: kobieta oraz Stan: mężatka → powitanie: Pani;
  • Płeć: kobieta oraz Stan: wolny → powitanie: Panna;

Reguła jest bardzo prosta i to co się rzuca w oczy, w przypadku pierwszej reguły, stan cywilny nie ma znczenia. Powyższą regułę można byłoby w łatwy sposób zapis w bazie danych – jako 3 wiersze, z 3 atrybutami.

Powyższy artykuł przypomina, że w celi opisu takich reguł powstawała Decision Model Notation (DMN) – notarcja modeli decyzyjnych. Artykuł nie rozwija tego tematu, ale w Internecie można znaleźć informacje. W szczególności na stronach brcommunity.com wskazują, że definiowanie reguł jest związane z ich wielokrotnym użytkowaniem. Jest to silne wsparcie dla osób projektujących proces, za pomocą notacji BPMN 2.0, gdzie została przygotowana opcja „BusinessRuleTask”. Służy ona do wołania o wynik poszczególnych reguł. Od notacji BPMN można przejść do postaci wykonawczej poprzez zastosowanie BPML. Przykład zastosowanie tego typu zadania – BusinessRuleTask- został wskazany na powyższym diagramie BPMN. Zadania tego typu oznaczane są przez symbol pogrubionej „tabelki”.

W biznesie można spotkać się z dwoma typami reguł biznesowych – reguły ogólne, mające zastosowanie do wielu procesów, mających miejsce w różnych miejscach orgranizacji oraz reguły szczególne, wykorzystywane w danym procesie biznesowym. Opis reguł biznesowych jest ważnym elementem, który pozwala na zrozumienie działania procesu oraz okoliczności jego wykonania. Często są to tabele lub diagramy drzewiaste ze względu na różnorodnosć powiązań. Samo wykonanie reguł biznesowych może zostać zaimplementowane w różnych sposób – może to być np. tabela bazy danych, na której wykonywane są zapytania SQL a wynikiem jest wynik reguły. Na konferencjach często można usłyszeć w jaki sposób implementować reguły i w jakich sytuacjach. Równocześnie zwracana jest uwaga, aby sposób ich definiowania i przechowywania pozwalał na ich późniejsze aktualizowanie bez konieczności zmiany systemu odwołującego się.

h1

Perspektywa Klienta

Marzec 14, 2011

W poprzednich wpisać (w szczególności w ramach Etapów benchmarkingu) wskazane zostały następujące kroki procesu wykonywane po stronie klienta:

  • zgłoszenie zapotrzebowania / wyszukanie produktu(-ów),
  • akceptacja oferty dostawcy / złożenie zamówienia,
  • realizacja zamówienia (płatność, odbiór produktu, podanie szczegółów realizacji).

Między powyższymi krokami procesu wykonywane są kroki dostawcy, wpływające na zachowanie klienta i jego decyzje. Wskazane kroki nie są jedynymi wykonywanymi przez klienta. Patrząc z perspektywy klienta można również wyróżnić elementy tzw. procesu decyzyjnego przed zakupem. W literaturze można znaleźć wiele podejść do tego procesu, różnego nazewnictwa uczestników oraz występujących etapów. Do mnie najbardziej przemawia rozwiązanie zaproponowane przez M.J. Baker.

W skrócie można je przedstawić jak na powyższym diagramie (przedstawionym w BPMN), dostosowując do przedstawionej sytuacji w poprzednich wpisach. Między punktami A i B, C i D mają miejsce kroki realizowane przez dostawcę lub wspólnie z dostawcą. Krok „Realizacja decyzji” mógłby zostać potraktowany jako cały wcześniej przedstawiony proces do momentu złożenia zamówienia/potwierdzenia.

h1

BPMN – wyjątki w procesie

Wrzesień 27, 2010

Wśród pojęć w metamodelu występuje także element wyjątku: [punkt 10.] Wyjątki (ang. Exceptions).

Poniższy diagram prezentuje moment wystąpienia – w ramach realizacji kroku „Przygotowanie przesyłki” (element wcześniej prezentowanego procesu) – takich wyjątków jak:

  • brak papieru w drukarce
  • brak atramentu
  • brak opakowania

Wszystkie zostały zaprezentowane jako zdarzenie „error” (błąd).
Obok znajduje się także zdarzenie „Materiały dostępne”, które pozwala na kontynuowanie procesu w odróżnieniu od powyższych, dla których inicjowany jest proces rozwiązania.