Archive for the ‘bpmn’ Category

h1

Po co to zdarzenie początkowe?

Luty 13, 2016

W przypadku BPMN stosowanie zdarzeń początkowych nie jest obligatoryjne, jednakże dobrą praktyką jest ich stosowanie. Jest to istotne, aby oznaczyć gdzie zaczyna się proces. Łatwiej odbiorcy diagramu określić, która czynność jest pierwsza. Łatwiej mu także zapoznać się z logiką procesu, który jest na diagramie. Wyobraźmy sobie, że na poniższym przykładowym (w BPMN) diagramie nie ma oznaczonego zdarzenia początkowego, które zostało zaznaczone. Skąd będziemy wiedzieć, gdzie się zaczyna proces i co powoduje jego przeprowadzenie? Czy zaczynamy od przekazania raportu do akceptacji czy od korekty?

zdarzenie_poczatkowe_1_450px

Umieszczenie zdarzenia początkowego (ang. start event) ma także tę zaletę, że można okreslić typ tego zdarzenia. Można np, wskazać, że proces ma miejsce co miesiąc, albo w określonym momencie czasu. Także może sygnalizować jakie fizycznie zdarzenia go inicjuje i jakie warunki. Zależy to również od tego jak szeroki proces chcemy pokazać. Jeżeli autor diagramu zakłada, że np. przyjęcie zamówienia jest pierwszym krokiem, to przed nim dobrze jest umieścić zdarzenie początkowe.

Wiele narzędzi stosowanych do modelowania procesów w notacji BPMN kontroluje, czy dana czynność (ang. task) ma połączenie (ang. connection) przychodzące i wychodzące. Zdarzenie początkowe nie wymaga połączenia przychodzącego.

 

Reklamy
h1

Wysłany-odebrany

Styczeń 23, 2016

W wielku polskich miastach na przystankach komunikacji miejskiej można zauważyć tablice, które wskazują godziny przyjazdu lub czas oczekiwania na dany środek komunikacji. Obserwując dane na takim wyświetlaczu można zauważyć, że wskazana liczba minut do przyjazdu np. autobusu spada a czasami rośnie i znów spada. Wskazuje na orientacyjny czas przyjazdu autobusu.

Można przypuścić, że z jednej strony w systemie zakodowany jest czas przejazdu danego autobusu między poszczególnymi przystankami. Jeżeli dany autobus jest spóźniony na poprzedni przystanek, to pewnie orientacyjny czas przyjazdu rośnie (biorąc pod uwagę opóźnienie i czas planowany na przejazd między przystankami). Można sobie wyobrazić, że autobus przyjeżdzając na przystanej wysyła sygnał do systemu, który go odbiera i analizuje, a następnie koryguje czasy wyświetlane na tablicach. W takim komunikacie mogłyby być dane: linia, kurs, czas itp. Taką komunikację opartą wysyłkę I odbiór komunikatu prezentuje poniższy diagram.

wyslany_odebrany_1_450px

Wskazane typy zadania (z BPMN) – wysyłające (ang. send task) i odbierające (ang. receive task) zostały przeze mnie wykorzystane m.in. w poprzednim wpisie w ramach procesu współpracy. Zadania te mają za cel umożliwienie komunikacji między basenami w procesach współpracy. Patrząc na rozwiązania systemowe, mogą to być komunikaty wysyłane w określonym formacie i wyrażone w okreslonym języku (np. XML). Np. w momencie przyjazdu autobusu na przystanek komunikat mógłby być taki:

<?xml version="1.0"?>
<header>
   <sendtime>2016-01-23 12:30:01</sendtime>
   <msgtype>PrzyjazdAutobusu</msgtype>
</header>
<body>
   <busnumber>45</busnumber>
   <kurs>3</kurs>
   <stopnumber>4</stopnumber>
</body>

I w momencie odjazdu z przystanku komunikat mógłby być taki:

<?xml version="1.0"?>
<header>
   <sendtime>2016-01-23 12:33:01</sendtime>
   <msgtype>OdjazdAutobusu</msgtype>
</header>
<body>
   <busnumber>45</busnumber>
   <kurs>3</kurs>
   <stopnumber>4</stopnumber>
</body>
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

„Zbliżeniowy” proces

Czerwiec 28, 2014

„Można zbliżeniowo?”. Pytanie znajome, coraz częściej słyszane w różnych sklepach i punktach usługowych i równocześnie w odpowiedzi pada odpowiedź twierdząca. Wygodne, proste, w szczególności dla małych kwot, przeważnie do 50 zł. Nie ma problemu z wydawaniem pieniędzy i różnymi rodzajami kart i czytników. Zamiast wprowadzenia karty do czytnika jest przytknięcie karty. Zamiast wprowadzenia PIN jest autoryzacja automatyczna. Klient nie musi przekazywać karty sprzedawcy, jedynie musi zbliżyć kartę do czytnika w wyznaczonym miejscu i poczekać na sygnał przyjęcia transakcji (sygnał dźwiękowy lub wizualny).

kartazbliz450

Na powyższym diagramie zostały zaznaczone zmiany standardowego procesu płatności kartą na proces płatności zbliżeniowych. Jak widać do procesu dochodzi jeden nowy element: kontrola limitu płatności zbliżeniowych, czyli wspomniane 50 zł. Powyżej tej kwoty płatność zostanie zrealizowana w tradycyjny sposób.

Korzyścią jest przyspieszenie procesu. Co łatwo widać, np. przy płaceniu zbliżeniowo za obiad na stołówce. Brak potrzeby szukania drobnych czy wydawania reszty. Inni powiedzieliby, że też bardziej higieniczne dzięki braku styczności z monetami/banknotami przed posiłkiem.

h1

Cookies wspierające proces

Lipiec 27, 2013

Od jakiegoś czasu w serwisach internetowych pojawia się ramka informacyjna na temat tzw. cookies, sposobu i celu ich wykorzystania. Są to pliki zapisywane na komputerze użytkownika serwisu www, gdy go przegląda. W plikach zapisywane mogą być takie informacje jak: najczęściej wykorzystywane elementy strony, ustawienia pomocnicze, personalizacja strony, elementy wpływające na wyświetlane reklamy itp. Zgodnie z nowelizacją ustawy Prawo telekomunikacyjne każdy serwis wykorzystujący te mechanizmy musi poinformować użytkownika o takim mechanizmie. Powinien także zostać poinformowany o tym jak może wyłączyć zapisywanie cookies na swoim komputerze. Wyłączenie cookies jest jakby rezygnacją z części funkcjonalności dostępnych w serwisie www.

collaborationpr450

Załóżmy, że w danym serwisie, bez zalogowania, można wskazać, która zakładka ma się zawsze pojawiać jako pierwsza – np. na stronie operatora komórkowego, chcemy najpierw widzieć informacje przeznaczone dla abonentów, bez konieczności logowania się za każdym razem. Zaznaczenie przy pierwszej wizycie, przy równoczesnym włączeniu cookies, pozwoli na zapamiętanie takiej informacji dla danego użytkownika (z danego komputera).

W takiej sytuacji, można powiedzieć, że ma miejsce proces, przedstawiony na powyższym diagramie, w którym zaangażowany jest użytkownik, jego przeglądarka oraz serwis www. Użytkownik komunikuje się z serwisem poprzez odpowiednie wybory. Bez włączonych cookies jego działania zmierzające do personalizacji serwisu, nie powiodłyby się. Jego wybory byłyby jednorazowe I ważne tylko do zamknięcia przeglądarki. Za każdym razem musiałby wykonać wybór zakładki albo filtrowanie informacji, które go interesują.

h1

Reguła biznesowa w pętli

Czerwiec 9, 2013

W poprzednim wpisie dotyczącym prezentacji pętli w BPMN, wskazałem, że w taki sposób przedstawiona pętla jest nieskończona. Brak połączenia lub zerwane połączenie powoduje powtórzenie czynności. Zabezpieczeniem przed nieskończonym wykonywaniem czynności jest wprowadzenie kroku, który ma sprawdzić:

  • jaki jest status ostatniego działania,
  • ile razy wystąpiła taka sytuacja,
  • ile biznesowo razy dopuszczalne jest powtórzenie czynności,
  • jaka powinna być kolejna czynność.

 

callcenter450c

Powyższe elementy przekładają się na regułę biznesową, która na podstawie zainstniałych warunków (status operacji, liczba wystąpień, ograniczenie biznesowe) określa kolejne działanie – Powtórzenie działań lub zakończenie procesu. Taką sytuację przedstawia powyższy diagram w BPMN. Między wskazaniem zdarzeń a kolejnym krokiem, został dodany krok reguła biznesowa (ang. business rule task) o nazwie Określ działanie.

W kroku Powtórz działania powinien być odnotowywany historyczny status a zerowany bieżący, ponieważ bez tego proces nie wejdzie nigdy w ścieżkę dzwonienia do odbiorcy. Równocześnie może podbijać licznik wystąpienia statusu w danej kampanii. Decyzją biznesową można zmienić zapisy reguły biznesowej (wartości graniczne) bez konieczności zmiany procesu. Można też wskazać, że nigdy nie jest powtarzane wybieranie numeru.

h1

Wyjście z pętli w BPMN

Maj 29, 2013

Ostatnio kilkakrotnie dzwonił do mnie „tajemniczy” numer prywatny. Domyślałem się, że to może być Bank lub inna instytucja. Kilkakrotnie próbowałem odebrać – albo mi się nie udało albo nie słyszałem. Zawsze pozostaje opcja „oddzwonię”, ale nie tym razem – na „Numer prywatny” nie da się oddzwonić. Jeden raz , udało się odebrać i usłyszałem tylko „Proszę czekać na zgłoszenie się operatora”. Pomyślałem – o mają automatyczne wybieranie numeru. Dobra, myślę, poczekam pół minuty, bo więcej nie byłem w stanie. Po pół minucie muzyczki, rozłączyłem się. I niestety brakowało mi jednego, informacji kto i dlaczego dzwoni. Po kilku dniach wreszcie się im udało, po odebraniu usłyszałem natychmiast miły głos operatora, który przedstawił się, wygłosił formułkę i przeszedł do rzeczy. Wysłuchałem go do końca. Następny raz już nie zadzwonili.
callcenter450
Powyższą sytuację można sobie wyobrazić jak pętlę per odbiorca kampanii. Zgodnie z definicja pętli (ang. loop) z matematyki umożliwia cykliczne wykonywanie ciągu czynności („pobranie rekordu, sprawdzenie statusu, wybranie numeru”) określoną liczbę razy, do momentu zajścia pewnych warunków („odbyto rozmowę” – status sprawdzany na bramce), dla każdego elementu kolekcji (działanie wykonywane dla każdego rekordu kampanii) lub w nieskończoność.

Kolejne czynności: sprawdź czy rozmowa się odbyła, wybierz numer, połącz z operatorem (gdy nie jest wolny, poinformuj o oczekiwaniu), a po rozmowie pomiń danego odbiorcę z kolejnego telefonu. Wyjściem z pętli jest zdarzenie „Odbyto rozmowę”. A zdarzenia: „Brak połączenia”, „Połączenie zerwane”, „Odbiorca niedostępny” powodują powtórzenie czynności dla danego odbiorcy.  Odczułem to na własnej skórze – a dzwoniący odczuł wszystkie powyższe zdarzenia z mojej strony. Powyższy diagram w BPMN obrazuje taką sytuację. Zobrazowana pętla, w sytuacji braku odebrania telefonu przez odbiorcę, jest nieskończona – należałoby dodać warunek o ilości prób lub maksymalny czas od rozpoczęcia kampanii do ostatniego telefonu.