Specjalizacja procesu

W każdym chyba markecie jest kasa tzw. szybka, np. do 10 produktów. Generalnie stojąc w kolejce widać, że ludzie stosują się do tego ograniczenia. Wykładają produkty, czekają na ich skasowanie a potem decydują o sposobie zapłaty. Mają 4 możliwości: 1) płatność gotówką; 2) płatność bonami; 3) płatność kartą z użyciem PIN; 4) płatność zbliżeniowo. Proces z tymi 4 możliwościami jest zaprezentowany poniżej. W związku z tym zróżnicowaniem czas obsługi danego klienta jest różny i wymaga mniej lub więcej interakcji kasjer – klient.

Załóżmy jednak, że mamy kasę szybką, z zastrzeżeniem, że można płacić jedynie zbliżeniowo, czyli wprowadzamy obok ograniczenia do 10 sztuk, także ograniczenie do 50 zł. Proces się upraszcza i czas obsługi poszczególnych klientów jest zbliżony (nie wnikam w wyjątkowe sytuacje, jak nierozpoznawalny lub nieczytelny kod kreskowy lub problemy z terminalem). Na powyższym diagramie elementy, które nie wystąpią zostały zaznaczone.

Efektem jest proces, który zamiast alternatywnych ścieżek czy możliwości na starcie narzuca obsługę Klienta określonego typu i wskazuje jakie są wejścia (ograniczony ich zakres). To trochę przypomina wzorzec Publish/Subscribe, w którym proces „ogłasza” kto i co może w nim wykonać, a odbiorca (Klient) podłączy się do procesu, gdy chce z niego skorzystać (skorzysta z procesu w ramach możliwości jakie daje lub nie).

Reklama

Komunikaty w procesie a odbiorca

We wpisie dot. zasilenia karty aglomeracyjnej i sposobu korzystania („Każdy krok procesu jest istotny”), nie wskazałem jakie komunikaty pojawiają się w trakcie realizacji procesu. W momencie wskazania początku trasy pojawia się komunikat: „Pobrano X”, a po wskazaniu końca trasy: „Pobrano X, Zwrócono Y”. W ostatnich dniach spróbowałem skorzystać z innej funkcjonalności – zakupu biletu dla współpasażera.

Po wskazaniu początku trasy, wybrałem opcję na ekranie i ponownie przyłożyłem kartę do czytnika. Najpierw pojawił się komunikat, że mam czekać, ale nie wiedziałem na co. Dobrze, odczekałem i próbuję jeszcze raz. Teraz pojawił się komunikat identyczny jak za pierwszym razem: „Pobrano X”. I nie wiedziałem, czy ponownie pobrał po raz pierwszy, czy to już za dodatkową osobę. Żadnego komunikatu, że wybrałem podróż dla 2 osób. Jedynym potwierdzeniem, że tak się stało jest była kwota widoczna na drugim komunikacie: „Pobrano 2X, Zwrócono Y”. Całą drogę się zastanawiałem, czy jedziemy opłaconym przejazdem, czy jedno z nas jedzie na gapę.

Proces mógłby wyglądać następująco:
a) po zmianie prostej – inny komunikat: „Pobrano X za dodatkową osobę” – zaprezentowane na powyższym diagramie.
b) po zmianie bardziej skomplikowanej – wybór najpierw opcji, potem wskazanie liczby osób i wtedy byłaby jasność.

Dzięki takim zmianom komunikacja z czytnikiem byłaby prostsza i nie byłoby niejasności przy ewentualnej kontroli biletowej.

Uproszczenie na korzyść klienta procesu

Dziś ponownie będzie o karcie aglomeracyjnej w Poznaniu. Ostatnio na serwisie lokalnym pojawiło się pytanie czytelnika, czy naprawdę zasilenie biletu na konkretną trasę wymaga wizyty w Punkcie Obsługi Klienta. Otrzymana odpowiedź jest prosta: „Bilet trasowany jest bardzo skomplikowany i jego sprzedaż wymaga dostępu do specjalistycznego kreatora umożliwiającego ustalenie oraz zapisanie trasy. Z tego powodu każdy pierwszy bilet trasowany w systemie biletu aglomeracyjnego można tylko i wyłącznie kupić w jednym z Punktów Obsługi Klienta. Klient wybiera trasę i okres ważności biletu”.

Wyobraźmy sobie jednak sytuację, że chcemy bilet np. na 6 przystanków bez przesiadek z punktu A do punktu B. Takie rozwiązanie mogłoby być oparte o prosty proces. Użytkownik wybiera przystanek z listy a system podpowiada linie, które przez ten przystanek przejeżdżają. Użytkownik wybiera linię, a system pyta o kierunek. Potem użytkownik wskazuje kierunek i zapisuje trasę. Potem wskazuje rodzaj biletu. Przed pierwszą podróżą korzysta z czytnika lub biletomatu, aby zapisać trasę z odpowiednim biletem na kartę. Jeżeli chce coś bardziej skomplikowanego lub z przesiadkami trafia do Punktu Obsługi Klienta. Proces zaprezentowany na powyższym diagramie.
Myślę, że takie rozwiązanie zadowoliłoby wielu użytkowników. Już o kosztach obsługi, czasu oczekiwania w kolejkach nie wspomnę. Taki mechanizm mógłby być użyty do zbudowania również przesiadek.

Każdy krok procesu jest istotny

Od jakiegoś czasu w Poznaniu funkcjonuje karta aglomeracyjna. Jedną z jej funkcji jest możliwość opłacenia (w różnej formie) przejazdów komunikacji miejskiej. Jeżeli korzysta się sporadycznie przydatna okazuje się funkcja wirtualnego konta, które się zasila, a potem bezpośrednio w tramwaju bądź autobusie można zapłacić za przejazd. Opłata jest naliczana za każdy przystanek, jednostkowa opłata maleje wraz z liczbą przejechanych przystanków.

Konstrukcja pobierania opłat jest o tyle ciekawa, że w przypadku wykonania wszystkich kroków procesu zaprezentowanego na powyższym diagramie, opłata jest obliczona dokładnie za liczbę przejechanych przystanków. Jeżeli proces zostanie przerwany (nie zostanie wykonany krok zaznaczony na czerwono) opłata zostanie pobrana tak jakby podróż trwała do końca linii (nawet gdy przejechało się kilka przystanków).

Wykonując wszystkie kroki otrzymujemy oczekiwany produkt procesu (wyjście procesu). Gdy któregoś nie wykonamy, nie otrzymamy produktu, co można powiedzieć o każdym procesie. Proces jest powtarzany wielokrotnie, każda poprawna realizacja procesu, przy zapewnionych środkach na karcie (wejście procesu) i wykonaniu wszystkich kroków, mamy opłacony przejazd w kwocie zgodnej z oczekiwaną (wyjście procesu).