Posts Tagged ‘Start events’

h1

Proces to-be ze zdarzeniem warunkowym

Kwiecień 25, 2016

Pod jednym z moich wpisów, dotyczącym kroków procesu ręcznego, skupiłem się na tym jak wygląda (proces as-is) proces wynajęcia żelazka w hotelu. Wskazałem również jak taki proces mógłby wyglądać (proces to-be) po zmianach. Pod wpisem pojawił się komentarz: “wiem, że sam przykład jest poboczny i służy wywołaniu tematu, ale… naprawdę tak załatwiono sprawę żelazka? normalnie inspekcja i lustracja. oczywiście są też skrajne sytuacje w drugą stronę – jak tu http://www.eporady24.pl/odpowiedzialnosc_hotelarza_za_kradziez_w_pokoju_goscia,pytania,4,60,2900.html może spróbowałby Pan opisać proces związany z bezpieczeństwem w hotelu? jak to uregulować i usprawnić?”. Zgadzam sie, że zaobserwowany proces jest słaby, jednakże po przeczytaniu wskazanego w komentarzu artykułu, może się wydawać uzasadniony, jeżeli ktoś próbował takie żelazko ukraść.

We wskazanym artykule wskazane są potencjalne konsekwencje dla gościa oraz hotelu w sytuacji kradzieży w pokoju hotelowym pod nieobecność gościa. Artykuł porusza kwestię możliwych rozwiązań dla sporu między gościem a hotelem. W tym wypadku wydaje się, że szkoda nastąpiła z winy gościa. Dlatego właśnie spróbuję z tą częścią zmierzyć się w tym wpisie. Na potrzeby przypadku załóżmy, że obecny proces (as-is) zakłada, że uniknięcie kradzieży jest uzależnione jedynie od działań gościa – ukrycia kosztownych rzeczy, żeby nie leżały na widoku, przekazania ich do depozytu, upewnienia się, że drzwi pokoju są zamknięte itp. Zastanówmy się nad hipotetycznym procesem  docelowym (to-be).

condit_process_1_450px

Pierwszym pomysłem na wariant procesu, który pozwoliłby na uniknięcie kradzieży (rozwiązanie trochę zainspirowane metodami stosowanymi w samochodach) jest wykorzystanie rozbudowanego klucza do pokoju. Zakładając, że gość hotelu nie zapomni wziąć klucza z pokoju, można byłoby wprowadzić rozwiązanie, że klucz zaczyna piszczeć/wibrować, gdy znajdzie się np. w odległości X metrów od pokoju, który nie jest zamknięty. A oddalanie się od pokoju powoduje wzrost natężenia.

Diagram procesu ilustruje tzw. zdarzenie początkowe warunkowe (ang. rule/conditional start event). Takie zdarzenie oznacza, że proces rozpoczyna się w momencie wystąpienia określonych warunków, bardziej lub mniej rozbudowanych. Gdy warunek jest spełniony, tj. odległość od drzwi > X m, to rozpoczyna się proces. W sytuacji, gdy odległość jest mniejsza niż X m, to proces nie rozpoczyna się.

Podobne zastosowanie zdarzenia warunkowego mogłoby się znaleźć w innych procesach. Na przykład obsługa sytuacji, gdy  poziom wskażnika wykracza poza dopuszczalne wartości. Inny przypadek to spadek zapasów poniżej pewnej wartości itd.

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

 

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