Posts Tagged ‘as-is’

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

Pytania o kroki procesu ręcznego

Październik 23, 2015

Podczas wizyty w hotelu, musiałem wypożyczyć żelazko. Udałem się do recepcji. Pytam, czy jest taka możliwość? Padła odpowiedź, że tak, ale trzeba zapłacić depozyt. Powiedziałem ok. Jak się okazało, najpierw trzeba było zapłacić, podać numer pokoju, poczekać na odnotowanie w papierach wypożyczenia żelazka, założenie oznaczenia na żelazku Potem przy zwrocie  żelazka trzeba było złożyć podpis, że nastąpił zwrot depozytu i żelazka. Natomiast przy oddawaniu klucza  sprawdzają czy nastąpiło rozliczenie pokoju. Dlaczego wypożyczenia żelazka i jego zwrotu nie odnotują w systemie? Podczas wymeldowania, można byłoby sprawdzić czy nastąpił zwrot żelazka.

Opisana zmiana to przejście od procesu w pełni ręcznego (obecnie stosowanego, tzw. as-is, oznaczonego na diagramie) do procesu wspieranego systemowo lub zautomatyzowanego (docelowego, tzw. to-be, oznaczonego na diagramie). System mógłby informować przy zwrocie klucza, że nie zostało ono zwrócone.

zelazko2

Podczas wykonywania takiej zmiany, zaczynamy od analizy bieżącego procesu, jego kroków. Można np. :

Można także zadać pytania, które sugeruje autor artykułu “Avoid Pains Converting a Manual to an Automated Process”:

  • Dlaczego dany krok jest ważny dla procesu?
    Np. na powyższym diagramie jest to powiązanie pożyczonego żelazka i numeru pokoju. Jest to wykonywane poprzez wpis do rejestru. Pozwala to zidentyfikować, gdzie są żelazka, kto jeszcze ich nie zwrócił.

  • Co się stanie jeżeli nie wykonamy danego kroku?
    Np. w powyższym procesie możemy nie pobrać depozytu. Ułatwia to obsługę klienta, nie musi mieć przygotowanej gotówki.

  • Czy miałoby sens, gdyby inny uczestnik procesu go wykonał?
    np.  zamiast ręcznego sprawdzania czy zwrócono żelazko, kontrola wykonywana przez system. na diagramie tego elementu nie oznaczono.

  • Czy istnieją procedury lub regulacje, których wymaga dany krok do wypełnienia przez tego uczestnika?
    W powyższym przypadku, gdy spytałem, dlaczego tyle formalności (ponieważ wystąpiła sytuacja, że gość hotelu nie zwrócił żelazka), odpowiedź, którą usłuszałem mogłem sobie wyobrazić – każą to robimy (czyli jest jakaś procedura).

  • Jeżeli procedury decydują o pełnym wykonaniu kroku, czy mogą zostać zmodyfikowane?
    Przenesienie działań do systemu, będzie wymagać zmiany procedury. Będą wykonywane inne kroki.

  • Jeżeli krok zostanie zautomatyzowany, co jeszcze musi zostać wykonane, aby mieć pewność, że krok jest poprawnie zakończony? Jest to uzależnione od zastosowanego rozwiązania.

Odpowiedź na pierwsze pytanie, to tak naprawdę określenie czego oczekujemy od procesu i czy obecny proces spełnia nasze oczekiwania. Wykonywanie procesu w takiej formie, bez zastanowienia się, bo tak mówią procedury, można powodować zdziwienie uczestników (=klientów) procesu. Takie zdziwienie wyraziłem.