Proces to-be ze zdarzeniem warunkowym

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

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.

Reklama

Kolejkowanie wspiera proces

We wpisie dotyczącym obsługi serwisowej w punkcie sprzedaży, skupiłem się na braku komunikacji dla Klienta – o tym, co dzieje się ze zgłoszeniem. Wskazywałem także możliwe usprawnienia dla opisanego procesu. Przedstawiony proces wskazywał także na liczbę mnogą sprawę, które są przekazywane serwisantowi (zbiorczo a nie sztuka po sztuce). Ta lista spraw zbieranych przez punkt sprzedaży to tzw. kolejka spraw. Taka kolejka mogłaby powstawać również w systemie do obsługi zgłoszeń.

Zaprezentowany w tamtym wpisie proces mógłby wyglądać jak na poniższym diagramie. Nowe kroki procesu są oznaczone na zielono, zmodyfikowane – na niebiesko, usunięte – na czerwono. Serwisant otrzymuje listę spraw w systemie, odbiera jedynie przedmioty spraw, oznaczone za pomocą numerów spraw. Sprawę, która jest w systemie, może przeglądać zainteresowany po otrzymanym numerze sprawy. Może sprawdzić status, a także odpowiedzieć na pytanie, które potencjalnie otrzymał. Po rozwiązaniu sprawy, punkt sprzedaży może odznaczyć w systemie numery spraw, dla których przedmioty są gotowe do odbioru.

Sprawy trafiają na kolejkę spraw do załatwienia. Potem przy zmianie statusu mogą zostać przesunięte na inna kolejkę spraw. Innym podejściem jest jedna kolejka, z różnymi statusami, która może być przeglądana po danym statusie.

Rozwiązanie oparte o kolejki jest często stosowane w systemach informatycznych do obsługi komunikacji asynchronicznej, kiedy odbiorca komunikatu nie jest w stanie zapewnić odpowiedzi bezpośrednio po zapytaniu lub nie wystawia takiego mechanizmu, ze względu na przygotowane rozwiązania.

„Dziennik” procesu

W zwykle w dzienniku zapisujemy wydarzenia z życia codziennego, grupy, jednostki lub innego podmiotu. Pod każdą datą lub/i godziną mamy informację o tym, co się wydarzyło, jakie były komentarze, kto brał udział itd. Potem po jakimś czasie możemy przeglądać dziennik, dzielić się z nim, analizował co, kiedy się wydarzyło i ile trwało. Wszystko zależy od tego z jaką skrupulatnością jest on prowadzony. Jeżeli jest to osobisty dzienny, wszystkie zapisy dotyczą jego właściciela, ale nie muszą. Mogą wskazywać także innych uczestników.

Dziennik na podobnych zasadach może zostać utworzony dla realizowanego procesu biznesowego. Taki przykładowy , uproszczony proces przy użyciu czynności wykonywanych zarówno ręcznie, jak i przez użytkownika w systemie został zaprezentowany na diagramie. Użytkownik wykonuje kolejne zadania w ramach procesu. Aplikacja obsługująca proces zapamiętuje pewne fakty o wykonywanych czynnościach. Dane zadanie, na starcie może odnotować fakt jego rozpoczęcia, a na koniec, fakt zakończenia, co zostało również zaprezentowane na diagramie. Pozostałe czynności składające się na dane zadanie mogą odkładać także inne informacje.

W takim „dzienniku” procesu mogą zostać zapisane jedynie podstawowe informacje: data i czas rozpoczęcia czy zakończenia poszczególnych zadań i użytkownik wykonujący. Mogą być to także dodatkowe informacje dotyczące okoliczności lub przedmiotu realizowanego procesu. Zapis informacji odbywa się bez angażowania użytkownika. Może zostać przeanalizowany na przykład przez administratora lub właściciela procesu.