Posts Tagged ‘BPMN’

h1

Proces w „basenie”

Styczeń 2, 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?

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:

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

Specjalistyczny pośrednik

Lipiec 20, 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).

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

Od sprawności do efektywności procesu

Listopad 19, 2011

Ostatnio płaciłem za usługę za pomocą mechanizmu płatności elektronicznych, inicjowanych z poziomu panelu administracyjnego, jednego z dostawców usług (nazwijmy internetowych). Wybrałem usługę do opłacenia, wskazałem rodzaj pakietu, wybrałem sposób płatności, kilka razy potwierdziłem, a na koniec otrzymałem komunikat „Niestety nie udało się. Spróbuj jeszcze raz”. Pomyślałem, będą musiał powtórzyć ostatni krok. Niestety okazało się, że całość. Czy było to efektywne? Czy można powiedzieć, że proces jest sprawny? Proces w uproszczeniu został zaprezentowany na poniższym diagramie (w BPMN).

Fakt, za drugim razem, proces zakończył się oczekiwanym efektem – usługa została opłacona i jej czas obowiązywania został przedłużony na następny okres. Jednakże sama realizacja nie odbyła się jak dla mnie w najlepszy możliwy sposób – zarówno ze względu na poświęcony czas, kilkakrotne potwierdzanie czy też wątpliwość czy przypadkiem jakaś płatność nie została jednak wykonana, a jedynie potwierdzenie nie zadziałało, czy też powrót do panelu.

Sformułowanie „oczekiwany efekt” wskazuje na tzw. efektywność procesu, natomiast „najlepszy możliwy sposób” wskazuje na tzw. sprawność procesu. W internecie można znaleźć różróżnienie, dla ułatwienia posłużę się angielskimi definicjami:

  • Effective: Adequate to accomplish a purpose; producing the intended or expected result ( =oczekiwany efekt).
  • Efficient: Performing or functioning in the best possible manner (=najlepszy możliwy sposób) with the least waste of time and effort.

Definicje idealnie pokazują, że proces efektywny to taki, który generuje właściwe efekty, a proces sprawny, który doprowadza do tych efektów w najlepszy możliwy sposób, biorąc pod uwagę czas, koszt realizacji. W przypadku powyższego procesu należałoby poprawić sposób działania i obsługi wyjątków, aby był realizowany szybciej. Można by, jak w przypadku niektórych sklepów internetowych, zapisywać etapy zrealizowane i umożliwić podjęcie procesu od pewnego kroku, ostatniego zaakceptowanego. Jeżeli chodzi o efektywność procesu to efekt jest prawidłowy. Myślę, że warto najpierw zadbać, aby z punktu widzenia użytkownika, proces przynosił oczekiwany efekt, a następnie poprawiać sprawność procesu, tak, aby efekt końcowy przewyższał oczekiwania użytkownika.

h1

SIPOC na bazie diagramu BPMN

Czerwiec 4, 2011

W wielu przedsiębiorstwach, które udostępniają swoim pracownikom – np. pracownikom obsługującym klientów – system informatyczny, funkcjonuje proces obsługi zgłoszeń błędów/problemów. Proces ten funkcjonuje obok zwykłych/głównych procesów (ang. core processes), wspieranych przez system informatyczny i w których biorą udział pracownicy. W kontekście systemu informatycznego pracownik staje się użytkownikiem (albo inaczej patrząc aktorem).

Ideę takiego procesu obrazuje poniższy diagram w BPMN.

Proces obsługi zgłoszeńW jednym z ostatnich wpisów wspomniałem o diagramie SIPOC. Jest on używany do zobrazowania przepływu pracy. Po rozwinięciu poszczególnych liter nazwy – umieszczonych także w odpowiednich miejscach na diagramie – mamy następujące elementy:

  • Supplier (S), czyli Dostawca – oznacza podmiot, który dostarcza informacje, zasoby do realizowanego procesu. Na powyższym diagramie jest to użytkownik systemu, który zgłasza problem – oznaczony przez (S).
  • Input (I), czyli zasoby wejściowe – oznacza informacje, zasoby dostarczane przez Dostawcę. Powyżej jest to zgłoszenie problemu/błędu z jego opisem, czasem wystąpienia, identyfikatorem transakcji/błędu, danymi identyfikacyjnymi użytkownika. Obiekty oznaczone przez (I).
  • Process (P), czyli proces – działania w określonej kolejności, które wykorzystuję zasoby wejściowe w celu zwiększenia ich wartości lub wytworzenia efektu końcowego (wyjściowego). W tym wypadku jest proces ze wskazanymi czynności zmierzającymi do znalezienia rozwiązania. Uczestnicy procesu analizują dostarczone informacje przez użytkownika. Wykorzystują przekazane dane kontaktowe w celu uzyskania dodatkowych wyjaśnień. Proces (P) składa się z kroków „Analiza zgłoszenia”, „Poszukiwanie rozwiązania” oraz „Wybór/Wskazanie rozwiązania”.
  • Output (O), czyli efekt wyjściowy – oznacza informacje, zasoby dostarczane przez proces. Na diagramie jest to rozwiązanie (jego opis), oznaczony przez (O).
  • Customer (C), czyli klient – oznacza podmiot, który otrzymuje efekt wyjściowy. W tym wypadku jest to inicjatora zgłoszenia, oznaczony przez (C).

Więcej o diagramie SIPOC można przeczytać u źródła (Six Sigma).

Obserwuj

Otrzymuj każdy nowy wpis na swoją skrzynkę e-mail.

Dołącz do 90 obserwujących.