Posts Tagged ‘przykład w BPMN’

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.

Reklamy
h1

Asocjacje w BPMN

Maj 21, 2013

Komentarz do poprzedniego wpisu o obiektach danych w BPMN wskazał jedną kwestię o której nie napisałem przy okazji umieszczania obiektów na diagramie. Połączenie obiektu danych z krokiem procesu odbywa się za pomocą tzw. asocjacji (ang. Association).

processassoc450b

Zgodnie z uwagą wygląd asocjacji wskazuje na rodzaj powiązania:

  • asocjacja bez strzałek oznacza dostęp do danych – na powyższym diagramie między krokiem “Zarejestruj zlecenie” i elementem “Baza zleceń” (kolekcja obiektów, ang. Data Store).
  • asocjacja ze strzałkami oznacza dane wejściowe lub wyjściowe – na powyższym diagramie dla obiektów wejściowych strzałka na asocjacji jest w kierunku kroku procesu, dla wyjściowych w stronę obiektu danych.

Dodatkowo na diagramie  (w BPMN) występuje obiekt danych (obiekt Zlecenie), który najpierw jest wyjściem z kroku (zapisane zostały dane). Ma oznaczony status. Dalsza praca odbywa się na takim obiekcie, będącym wejściem do kolejnego kroku (krok pobiera dane). Korzystając z aplikacji do przygotowania diagramu procesu, trzeba uważnie stosować typy powiązań.

Asocjacje są także wykorzystywane do łączenia innych obiektów – np. tekstu (ang. Text annotation) – jak w przypadku powyższego diagramu element zawierający dodatkową informację o kroku.

h1

Obiekty danych w procesie BPMN

Maj 17, 2013

Kolejnym etapem realizacji zlecenia w serwisie samochodowym, była kwestia płatności I otrzymanie potwierdzenia. Otrzymałem wydruk zlecenia z kwotą, statusem oraz wykonanymi czynnościami. Przyglądając się zleceniu zauważyłem, że składa sie ono z informacji uzyskanych od Klienta, danych wprowadzonych przez operatora i danych z rejestru części dostępnych w serwisie. Elementy to obiekty danych, które razem tworzą zlecenie. Operacje na tych danych pokazuje poniższy diagram BPMN.

processobjects450

Obiekty danych są z jednym z elementów procesów w BPMN. Mogą informować o danych służących do realizacji zadań przez użytkownika w systemie, obiektach wykorzystywanych przez samą aplikację oraz efektach działania aplikacji. Na diagramie zaprezentowano przykłady. Obiekt (ang. Data Object), na którym działa proces, ma wskazane różne statusy – Zarejestrowany, Wydrukowany. W tym celu wykorzystuje się element BPMN oznaczony poprzez prostokąt z “zagiętym rogiem”. Obiekty wejściowe (ang. Data Input) są oznaczane pustą strzałką, a obiekty wyjściowe (ang. Data Output) – pełną strzałką.

W tym wypadku obiekt Zlecenie można potraktować jako złożenie danych kluczowych i danych zawartości. Proces jest sterowany przez operatora.

h1

Najpierw sprawdź, potem zrealizuj

Maj 12, 2013

Ostatnio odwiedziłem jedną z sieci serwisów samochodowych. Zadanie było proste: zamowienie nowych felg, ich zamontowanie razem z oponami letnimi i ich wyważenie. Składam zamówienie I słyszę, że potrwa to około 1,5 godziny, płatność przy odbiorze w takiej i takiej wysokości. Na koniec prośba o zostawienie telefonu kontaktowego – logiczne, zamierzali poinformować, że samochód jest gotowy do odbioru. Zostawiam samochód i idę na zakupy do okolicznego centrum handlowego. Po około 1,5 godziny, gdy wracam do serwisu, telefon z serwisu: “Jednak nie zrealizujemy zlecenia. Brakuje nam jednej rzeczy, jest w systemie, ale nie ma na stanie”.

W myślach pojawiło się tylko “Ups. Chyba coś jest nie tak z ich procesem obsługi.”. Takie stwierdzenie ani dobrze nie brzmi w oczach klienta – mamy, ale nie mamy. I potem to wahanie co mogą zaproponować. Umawiamy się na kolejną wizytę i tylko taki niepokój, że może jeszcze coś wyjdzie. Na pytanie “czy umówionego dnia załatwimy wszystko?”. Nastąpiła chwila ciszy i po dłuższym wahaniu: “Tak”.

Realizowany proces (w BPMN) można zaprezentować następująco:

serwisauto450

Na powyższym diagramie został oznaczony linią przerywaną krok, którego w powyższym przykładzie raczej zabrakło. Potrzebne było określenie, czy są dostępne wszystkie elementy potrzebne do realizacji zlecenia. Elementy zlecenia można potraktować jako wejście procesu. Gdy nie ma wszystkich wymanych elementów, proces nie będzie efektywny. Dla tego serwisu jest to jeden z kluczowych procesów i opisany przypadek może jedynie spowodować, że klient więcej z usług tego serwisu nie skorzysta. Mało tego będzie się zastanawiał, czy w związku z tym problemami nie powinien otrzymać jakiejś rekompensaty (było czuć podczas rozmowy telefonicznej, że nie czują sie komfortowo z tą sytuacją).

Co ciekawe w innym oddziale sieci, wykonali ten krok i na starcie powiedzieli czego im brakuje do realizacji potencjalnego zlecenia. Proces był sprawny. Z punktu widzenia odbiorcy był także efektywny – wskazali jak możemy zrealizować zlecenie i gdzie. Chcąc osiągnąć efektywny i sprawny proces, konieczny jest wskazany krok w każdym oddziale.

h1

Usługowy proces współpracy

Kwiecień 27, 2013

W artykule Fenomen chmury w Gazecie-MŚP autor zastanawia się jak dobrze wybrać dostawcę takich usług. Wskazuje wiele korzyści, tak ich jak ciągłość działania, dostępność z różnych miejsc, oszczędność kosztów itp. Równocześnie przypomina, że technologia nadal budzi wiele obaw. W artykule pojawiają się dwie możliwości wykorzystania chmury – korzystanie z aplikacji i korzystanie z przestrzeni dyskowej.

Obydwa te możliwości kryją się pod jednym angielskim określeniem SaaS. SaaS rozwinąć można jako:

  • Sofware as a Service – oznacza wykorzystanie aplikacji umieszczonej na zdalnym serwerze – „aplikacja jako usługa”. Nie ma potrzeby jej instalowania i konfigurowania lokalnie na komputerze odbiorcy. Użytkownik wskazuje aplikację do uruchomienia, wykorzystuje, a potem kończy pracę. Na poniższym diagramie BPMN przedstawiony jest schemat współpracy.

collaboration_1_450

  • Storage as a Service – oznacza korzystanie z zdalnej przestrzeni dyskowej – „przechowywanie jako usługa”. Użytkownik przesyła dane do zewnętrznej lokalizacji. Ma do nich dostęp z różnych lokalizacji. Nie musi dbać o dużą lokalną przestrzeń dyskową. Nie musi także pamiętać o archiwizowaniu danych oraz tworzeniu kopii zapasowych – dba o to dostawca usługi. Na poniższym diagramie BPMN przedstawiony jest schemat współpracy.

collaboration_2_450

Obydwa modele obsługi przypominają proces współpracy (ang. collaboration process). Użytkownik wysyła komunikat do dostawcy usługi. Wywołuje usługę o odpowiednich parametrach – wysyła żądanie uruchomienia aplikacji, przechowania danych. W odpowiedzi otrzymuje komunikat z wynikiem – udostępniona usługa, dane zapisane, brak dostępu do aplikacji (nie została skonfigurowana), brak przestrzeni dyskowej (zostało wyczerpane miejsce przewidziane w umowie). Dostawca dba o bezpieczeństwo, ciągłość dzialania, wybór źródła aplikacji, metod archiwizowania, momentu tworzenia backupu. Za taką możliwość płaci stałą lub w inny sposób skonstruowaną opłatę.

h1

Co to ten token?

Marzec 22, 2013

W poprzednim wpisie użyłem sformułowania, że po „otrzymaniu tzw. tokenów” ze wszystkich ścieżek wchodzących do bramki proces będzie kontynuowany. Tzw. token można sobie wyobrazić jako znacznik przebiegu procesu przekazywany od zdarzenia początkowego, od czynności do czynności, rozdzielanego i łączonego na ścieżkach równoczesnych, traconego w pewnych sytuacjach. W szczególności za pomocą tokenów łatwo wyjaśnić działanie bramek. Spróbuję przedstawić to wizualnie.

tokens_animation4

Załóżmy, że przygotowujemy obiad, rysujemy proces czynności wykonywanych po kolei, a potem dajemy komuś zadanie powtórzenia procesu. Można sobie wyobrazić, że ta osoba (lub robot po przepisaniu procesu na język maszynowy), wodzi palcem po procesie i wykonuje czynności zgodnie z ich opisem. Wstawia wodę na ziemniaki, soli ją, w trakcie gotowania wody, obiera ziemniaki, a potem je wrzuca do garnka, następnie wykonuje kolejne czynności. Może też to zrobić za pomocą parowaru. Wstawia wodę, obiera ziemniaki i umieszcza je w parowarze. Powyższy diagram w BPMN prezentuje taki przykładowy proces.

Przyglądając się dokładnie animacji można zauważyć, że:

  • za bramką AND są 2 tokeny i przejście do następnych czynności, jest możliwe, gdy obydwa one trafią do bramki łączącej. Zadania mogą zakończyć się w różnym czasie.
  • za bramką typu exclusive jest jeden token, ponieważ proces przebiega jedną ścieżką.
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.