Posts Tagged ‘Start events’

h1

Przez telefon czy na stronie?

11 stycznia, 2020

Chyba każdy zna ten moment gdy jest przerwa w dostawie prądu – czy to chwilowa objawiająca się tylko mrugnięciem czy też dłuższa, wymagająca określonych działań (sięgnięcia po latarkę, świeczkę czy inny sprzęt). Gdy ostatnio w sobotę, nastąpiły 3 krótkie „mrugnięcia” a później przyszedł do mnie sąsiad z pytaniem czy coś wiem, przypomniałem sobie o innej sytuacji. Pod koniec roku 2019, dzień przed wigilią byłem w domu z rodziną, mijała właśnie godzina 19 i nagle ciemność – na całym osiedlu. Niezły moment na taki problem – ludzie przygotowują święta, wstawione ciasta, mięsa i inne potrawy a tu brak prądu. Złapałem za telefon i szukam informacji. Za pierwszym razem nic nie znalazłem, a za drugim pojawiła się informacja na mapie dostawcy prądu o  awaryjnej przerwie w dostawie prądu, która jest szacowana na 2 godziny. Minęło kilkanaście minut i prąd znów był dostarczany. A po 20 powtórka, znów ciemność – tym razem na krócej. Informacja na stronie się nie zmieniła.

Mogę sobie wyobrazić, że w momencie pierwszego wyłączenia część osób złapało za telefon i zamiast szukać informacji (sprawdzać samodzielnie) zadzwoniło na pogotowie energetyczne lub na infolinię dostawcy prądu. Mogło być też tak, że ktoś mógł pójść do sąsiada i spytać czy coś wie o na przykład planowanym wyłączeniu prądu. Wyobraźmy sobie jak mógłby wyglądać proces od strony dostawcy, który łączy te dwie możliwości – stronę z informacjami i telefony.

prad_zgloszenie400px

Dostawca na podstawie zgłoszeń telefonicznych i ich weryfikacji mógłby umieścić informację na stronie o awarii. Dzięki czemu zaspokoi potrzebę informacji tych sprawdzających i potencjalnie zmniejszy liczbę telefonów z regionu objętego awarią. Może także mieć system monitoringu, który wskaże mu, że taka awaria nastąpiła. Wejściem do procesu może być zgłoszenie telefoniczne od odbiorcy lub własny monitoring. Wyjściem może być informacja na stronie. Skutkiem pewnie będzie także wysłanie ekipy technicznej w rejon objęty awarią lub inne specyficzne działania.

Na powyższym diagramie próbowałem przedstawić omówiony proces. Na diagramie w notacji BPMN wykorzystałem zdarzenie inicjujące proces, powstałe na bazie zgłoszenia/komunikatu przekazanego przez „zewnętrznego” aktora. Jest to tzw. message start event – jeden z typów zdarzeń (ang. events) używanych w notacji BPMN służącej do modelowania procesów. To zdarzenie na diagramie jest zaznaczone na żółto. Opisany proces nie miałby miejsca, jeżeli takie zdarzenie nie nastąpi. Brak telefonów lub innych zgłoszeń oznacza prawdopodobnie, że nie ma awarii.

Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego blogahttps://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.

h1

Proces to-be ze zdarzeniem warunkowym

25 kwietnia, 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.

h1

Po co to zdarzenie początkowe?

13 lutego, 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

21 lutego, 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).