Pytania o kroki procesu ręcznego

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.

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

• zweryfikować kroki będące objawami marnotrawstwa – np. zbieranie podpisu od klienta,
• określić kroki tworzące wartość dodaną – np. możliwość pożyczenia żelazka,
• wykorzystać doświadczenia reinżynierii lub benchmarkingu proccesów – wystarczyłoby odwiedzić inny hotel i zobaczy jak rozwiązał proces.

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.

Reklama

Proces oparty o stany

Wyobraźmy sobie, że parking opisany ostatnio we wpisie, wykonuje oprócz wskazanych 3 podstawowych działań (przyjęcie samochodu, przyjęcie opłaty i wypuszczenie samochodu), jeszcze jedną bardzo ważną rzecz. Mianowicie, wskazuje w momencie wjazdu na parking, gdzie jest najbliższe wolne miejsce. Niby rzecz trywialna, ale wymaga odpowiedniego przygotowania – zarówno od strony infrastruktury (kontrola zajętych miejsc, identyfikacja gdzie są samochody wcześniej wpuszczone, które jeszcze nie zaparkowały), jak i informatycznej (odpowiedni system zarządzania miejscami parkingowymi, kontrolą stanów miejsc i ich zmianą, a także prezentacją graficzną parkingu).

Z jednej strony mamy zmianę stanu miejsca parkingowego, a z drugiej weryfikację położenia, gdzie jest wolne miejsce. Takie procesy zostały zaprezentowane na powyższym diagramie. W momencie realizacji procesu (na diagramie Określ mapę dojazdu) z prezentacją najbliższego wolnego miejsca (na diagramie Wyświetl mapę dojazdu) system musi wziąć pod uwagę stany miejsc parkingowych wynikajacych z:

• zajęcia miejsca parkingowego (zmiana stanu na zajęty),
• opuszczenia miejsca parkingowego (zmiana statusu na wolny),
• przemieszczania się samochodów wpuszczonych na parking (w dowolnym momencie dane miejsce może zmienić stan),
• lokalizacji samochodów wpuszczonych na parking (np. są na 2 poziomie, a miejsce akurat jest na 1 poziomie).

Chcąc uniknąć ryzyka, że wskazane najbliższem miejsce okaże się zajęte, można także wskazywać miejsce alternatywne. Dodatkowo już po wjeździe na parking w widocznych miejscach mogłyby być umieszczone ekrany wskazujące na najbliższe wolne miejsce parkingowe (cykliczne wykonywanie pierwszego procesu). Ułatwieniem w zarządzaniu takim parkingiem mogłoby być to, że nie da się cofnąć do innego miejsca parkingowego, nie przejeżdżając przez punkt startowy, który dodatkowo jest kontrolowany przez system.

W podanym przykładzie podane procesy opierają się na świadomym wykorzystaniu stanów poszczególnych miejsc parkingowych (oznaczone za pomocą funkcji w klasach UML na diagramie). Stany miejsc występują naprzemiennie i trudno jest określić jakie są ramy czasowe dla rozpoczęcia procesu i jego zakończenia. Dla danego miejsca stan może się nie zmienić godzinami lub zmienić się raz i pozostać taki przez wiele godzin. Takie cechy są charakterystyczne dla procesów sterowanych stanami – ang. state-driven process. Skierowanie samochodu na dane miejsce jest możliwe tylko, gdy jest ono wolne. Zmiana stanu odbywa się poprzez odnotowanie wjazdu samochodu na dane miejsce.

Elementy wspólne dla podprocesów

Po dłuższej przerwie miałem okazję korzystać z jednego z płatnych parkingów, będącego pod centrów handlowych. Wjeżdżam, pobieram bilet, otwiera się szlaban i wjeżdzam. Parkuję a bilet umieszczam w portfelu, sprawdzając tylko odnotowaną godzinę wjazdu. Chowam do portfela i idę do centrum handlowego. Po jakimś czasie wracam na parking, udaję się do kasy i wtedy dopiero zdaję sobie sprawę, że coś się zmieniło. Bilet nie został wciągnięty do środka a sama kasa inaczej wygląda. Płacę.

Próbuję więc wyjechać i jestem mile zaskoczony, bo szlaban się sam otwiera. Zdziwiony, próbuję włożyć bilet do czytnika, a tutaj komunikat: “Dziękujemy za wizytę”, potem numer tablicy rejestracyjnej i komunikat: “Proszę wyjechać”. Wtedy obejrzałem bilet i zobaczyłem, że jest na nim więcej danych. O taka zmiana, zwiększenie automatyzacji. Nieświadomy tego, system sam zapamiętał samochód i sam go rozpoznał. Ja musiałem tylko nie zgubić biletu i go opłacić.

Przykład ten pokazuje w jaki sposób można przyspieszyć i uprościć proces, wykorzystując nowoczesne technologie. Krótszy czas oczekiwania przy wyjeździe.  Wydaje się, że bilet jest już niepotrzebny. Każdy samochód, który podjeżdża jest analizowany pod kątem godziny wjazdu, opłacenia biletu i możliwości wypuszczenia samochodu. Gdyby ktoś spróbował wyjechać samochodem nieopłaconym zostałby zatrzymany. Gdyby nie udało się odczytać tablicy rejestracyjnej, poproszony zostałby kierowca o przytknięcie biletu.

Powyższy diagram prezentuje 3 oddzielone w czasie czynności – podprocesy – wykonywane przez system, w różnych okresach czasu, składające się na jeden większy proces obsługi korzystającego z parkingu. Oparte są one na tym samym identyfikatorze i jego statusie. Pozwala to na zmianę ich składowych, jeżeli zachowane zostanie powiązanie identyfikatora (numer rejestracyjny/numer biletu) oraz statusu (wjazd, opłacony, wyjazd). Na diagramie na zielono są zaznaczone kroki oparte na tych danych – zapis, odczyt i analiza (czas wjazdu, czas postoju, numer biletu, numer tablicy). Teoretycznie można byłoby zrezygnować z wydawania biletu po jego opłaceniu, ale wtedy w sytuacji awaryjnej (brak odczytu tablicy) proces przebiegnie w oparciu o bilet, przyłożony do czytnika.

W powyższym przykładzie proces obsługi korzystającego z parkingu składa się z 3 kroków: przyjmij samochód, przyjmij opłatę, wypuść samochód. Na takim poziomie, takie 3 kroki są wystarczające do pokazania jak przebiega proces główny. Jeżeli chcemy poznać szczegóły, zapoznajemy się z poszczególnymi podprocesami. Między tymi krokami z punktu widzenia obsługujących parking, mają miejsce czynności nieistotne dla nich – szukanie miejsca przez kierowcę, opuszczanie pieszo i powrót na parking przez kierowcę, poruszanie się samochodem po parkingu. Czas przebiegu procesu głównego jest zmienny i niezależny od sposobu jego obsługi.