Reguła biznesowa w pętli

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ść.

 

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.

Reklama

Asocjacje w BPMN

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).

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.

Obiekty danych w procesie BPMN

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.

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.

Najpierw sprawdź, potem zrealizuj

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:

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.

Usługowy proces współpracy

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.

• 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.

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ę.

Co to ten token?

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.

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ą.

Decyzje pod kontrolą lub poza

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.

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.

Oczekując na zdarzenie

Telefon z recepcji hotelowej przypomniał mi o moim zamówieniu. Informacja była prosta, że w tej chwili nie mogą zrealizować zamówienia. Powiedziałem, że mogę poczekać nawet godzinę. No właśnie, złożyłem zamówienie i czekałem na wynik, w sumie nieistotne było dla mnie jakie czynności przed czy po telefonie wykonują żeby zrealizować moje zamówienie. Czy sprawdzają listę zamówień? Czy pytają tych co się opóźniają ze zwrotami? Jak się komunikują między recepcją a osobami realizującymi? Dla mnie ważny jest efekt, że po zgłoszeniu zamówienia, po jakimś czasie mogę się spodziewać pukania do drzwi. Oczekuję jakby na określone zdarzenie, a dokładniej zareaguję na zdarzenie, które nastąpi.

W ten sposób działa proces w przypadku tzw. czarnej skrzynki. W centrum zainteresowania są operacje, komunikaty wykonywane/wysyłane przez jedną ze stron i ich efekt. Na powyższym diagramie recepcję/obsługę można traktować jako czarną skrzynkę.

Czas między zgłoszeniem a zdarzeniem „pukania do drzwi” może wpłynąć na:

• ocenę realizacji procesu, jego efektywności,
• postępowanie w przyszłości, że wcześniej zacznę proces (wcześniejsze zgłoszenie),
• ewentualne skrócenie czasu, który będę oczekiwać na realizację,
• rezygnację z usług i realizację ich w inny sposób,
• ewentualne zasygnalizowanie czasu akceptowalnego oczekiwania w momencie zgłoszenia.

Z punktu widzenia recepcji/obsługi, mogą wpisać w informacji dla gościa, że czas oczekiwania na zamówienie może trwać tyle i tyle, a także w którym momencie gość zostanie powiadomiony o przedłużeniu czasu realizacji – podobnie jak w przypadku rozpatrywania reklamacji.

W zależności od punktu widzenia, wnioski są różne. W przypadku recepcji/obsługi przyjęcie zamówienia jest podobnym punktem, ale zgłoszenie możliwości odbioru jest jeszcze ważniejszym, ponieważ oznacza, że można zrealizować kolejne zamówienie innego gościa, który także ocenia proces realizacji, o innych lub podobnych akceptowalnych parametrach.

Równoczesne ścieżki procesu

Uruchamiam w pewien weekend swój komputer i po kilku sekundach widzę komunikat o braku możliwości odczytu dysku. Dobra restartuję go i zastanawiam się co się mogło stać. Próbuję ustalić przyczynę problemu i znaleźć możliwe rozwiązania, zgodnie z metodologią 8D, o której pisałem ponad rok temu. Próbuję komend na poziomie linii poleceń, sprawdzania dysku, uruchomienia trybu awaryjnego, załadowania poprzedniej wersji. Wszystkie działania wykonywałem sekwencyjnie. Ostatecznie skończyło się na instalacji systemu od początku. Mówi się trudno.

Wrzuciłem płytkę, zmieniłem tymczasowo kolejność źródeł uruchomienia systemu. Wreszcie pojawił się ekran – uruchom system z dysku lub zainstaluj system. Wybrałem to drugie i po kilku ekranach zaczyna się kopiowanie plików. A tu nagle zaskoczenie, mogłem równocześnie konfigurować przyszły system. Ooo…, coś nowego. Zwykle działo się to sekwencyjnie – najpierw kopiowanie potem parametry lub na odwrót. A tu taka oszczędność czasu.

Powyższy przykład można zobrazować diagramem w BPMN przy wykorzystaniu elementów pozwalających na rozdzielenie procesu na dwie równoczesne ścieżki (tzw. parallel gateway). Element początkowy rozdziela ścieżkę a element końcowy łączy. Przejście do dalszej części procesu możliwe jest dopiero po zakończeniu obydwu ścieżek. Gdyby czynności były sekwencyjnie ułożone nie byłoby tego elementu. Przed rozdzieleniem były pewne zadania istotne dla obydwu ścieżek, a potem były zadania będące efektem wszystkich wcześniej zakończonych kroków – uruchomienie systemu po raz pierwszy w wybranej wersji językowej i dla danego użytkownika.

Ale to nie tak działa…

Setny wpis, a sama liczba 100 na przełomie stycznia i lutego kojarzy się z studniówką, do której przygotowują się licealiści. Wybór miejsca, jedzenia, muzyki, stroju, partnera itd. Można powiedzieć, że weryfikowana jest pewna lista kontrolna. A kolejne czynności układają się w proces. Tak to można określić. Kwestia przypomina mi pewną historię. Pamiętam jak kiedyś w czasie okresu przygotowań do studniówki, wychowawczyni klasy zadecydowała, że na wychowawczej będziemy wybierać pary do poloneza, znaczy się ona będzie wybierać.

Więc zaczęła wybierać, najpierw partnerka (nieistotne czy alfabetycznie, czy tak jak siedziały w klasie), a potem dobierała partnera. I tak szło, partnerka-partner, partnerka-partner, i było coraz ciekawiej. Można powiedzieć że był to powtarzalny proces z dwoma czynnościami, który zgodnie z jej założeniami procesu, kończył się, gdy wszyscy będą posiadać parę lub skończą się partnerki lub partnerzy. W sumie nieistotne, które zdarzenie zakończyło proces. Kroki na poniższym diagramie w BPMN, poza zielonym zdarzeniem, oznaczają proces założony przez wychowawczynię.

Jednak sytuacja, nie była taka idealna, gdy próbowała wybrać jednego z partnerów, powiedział, że nie jest to możliwe, ponieważ już się umówił na parę do poloneza – jednym słowem jest zajęty. Wiedział widocznie z kim chcę iść i poczynił odpowiednie kroki wcześniej. Pojawiło się nowe zdarzenie w procesie (oznaczone na zielono na diagramie), które wprowadziło zamieszanie. Efektem jest alternatywna (a może wyjątkowa?) ścieżka postępowania – tłumaczenie, zmiana jego decyzji, poszukanie rozwiązania. Wychowawczyni nie do końca wiedziała jak zareagować – było to, co czego się nie spodziewała.

Czasami jest też tak w rzeczywistości, ktoś zakłada określony przebieg procesu, zbiera informację i w pewnym momencie trafia na jednego uczestnika, który miał potwierdzić proces, który stwierdza: „Ale to działa tu inaczej, ja robię to i to, a wtedy i wtedy, to…”. Dlatego tak istotne jest zaangażowanie uczestników procesu w przygotowanie procesu. W innym przypadku narażamy się na ryzyko, że jakieś zdarzenie zniweluje efekty naszej dotychczasowej pracy, a czas potrzebny na opracowanie procesu wydłuży się. Warto się wcześniej przygotować, zebrać eksperów dziedzinowych, przedstawić cel opisu procesu, jakie są granice procesu i zachęcić do zaangażowania. Warto także uzyskać potwierdzenie od osób zaangażoanych czy zgadzają się na założenia procesu lub wcześniej zarysowane jego granice.