Gdy Klient nie decyduje…

„Informujemy, że podczas składania zamówienia niektóre produkty były na wyczerpaniu i nie są już dostępne. Zgodnie z regulaminem sklepu, zamówienie zostanie pomniejszone o dany produkt. Jeżeli zamówienie było opłacone z góry, środki zostaną zwrócone na konto w ciągu 7 dni roboczych.”. Taką wiadomość otrzymałem z jednego ze sklepów internetowych, prawie tydzień od złożenia zamówienia. O tym, że realizacja zamówienia będzie wydłużona wiedziałem od momentu składania zamówienia. Także później przyszła informacja o tym, że potrwa dłużej. Jednak gdy otrzymałem taką wiadomość byłem trochę zaskoczony, bo składając zamówienie nie było informacji o potencjalnych brakach produktów.

Przy wcześniejszych zamówieniach, które składałem, takie sytuacje się zdarzały, ale sposób działania sklepu był inny. Jedne sklepy oczekiwały potwierdzenia w zakresie proponowanych akcji lub anulowania zamówienia. Były też propozycje telefoniczne zastąpienia produktu innym w podobnej cenie. Pierwszy raz mi się zdarzyło, że to sklep zadziałał w określony sposób, tylko mnie informując. W sumie cieszę się, że nie czekali z realizacją zamówienia na moją decyzję, a zwrócą środki za brakujące produkty, a resztę zamówienia zrealizują.

Na poniższym diagramie w BMPN spróbowałem przedstawić opisywaną sytuację (mam nadzieję, że w poprawny sposób).

W celu zobrazowania sposobu obsługi sytuacji, gdy na magazynie jednak nie ma produktu, użyty został obiekt BPMN wskazujący na błąd wewnątrz procesu (ang. intermediate error event), a dokładnie w ramach wykonania kroku procesu. Po wystąpieniu tego zdarzenia, następuje poinformowanie Klienta (pierwszy krok po zdarzeniu) oraz zwrot środków (drugi krok po zdarzeniu). Obiekt błędu jest umieszczony na obramowaniu kroku Skompletuj zamówienie. Jest to wskazanie, że błąd nastąpił w trakcie realizacji tego kroku i został przejęty (ang. catch) i obsłużony (ang. handle) ramach wskazanych kroków.

Mogę sobie wyobrazić, że podczas tego kroku, pracownik sklepu przechodzi przez magazyn z elektroniczną listą produktów, znajduje je po kolei i umieszcza w środku transportu. Po przejściu kilkunastu pozycji zamówienia, nie odnajduje kolejnego produktu w odpowiedniej ilości. Oznacza to, kompletuje resztę. Na tej podstawie proces idzie dla zebranych produktów dalej, a dla brakujących jest obsługa sytuacji nietypowej/wyjątkowej.

Innym rozwiązaniem jest, gdy taki obiekt błędu jest umieszczany jako niezależny element w ramach przebiegu procesu (ang. sequence flow). Przykład takiego zastosowania tego obiektu można zobaczyć w innym wpisie dotyczącym wyjątków.

Reklama

Co pokazać na diagramie procesu?

Ostatnio na forum analizy biznesowej śledziłem wątek dotyczący kaskadowego procesu akceptacji (ang. waterfall acceptance business process) zainicjowanego przez inicjatora w następujący sposób (po przetłumaczeniu): „… sposób zaprezentowania procesu, który zawiera wiele kroków akceptacji wykonywanych przez różnych aktorów biznesowych. Każda z ról (4 lub 5) z występujących w procesie może zaakceptować lub odrzucić (odesłać do poprzedniej roli) dokument. Przebieg procesu nie może zostać zmodyfikowany […] Diagram ma być czytelny…”. Cały wątek znajduje się na forum Modern Analyst.

W powyższym opisie można wskazać następujące elementy:

• inicjator poszukiwał sposobu na prezentację procesu;
• w procesie uczestniczy kilka osobnych osób;
• dokument niezaakceptowany jest odsyłany do poprzedniej roli;

Na poniższym diagramie zaprezentowano (przetłumaczone) dwie propozycje rozwiązania powyższego problemu. Ta po lewej przygotowana została przez inicjatora wątku. Z kolei ta po prawej, została przedstawiona przez jednego z uczestników wątku. Obydwa diagramy przytoczone bez zmian w przebiegu – zaprezentowane w jednorodnej notacji (diagram aktywności UML).

Pierwszy z nich wskazuje wprost do kogo wraca dokument po jego odrzuceniu przez danego uczestnika procesu. Natomiast drugi nie pokazuje tego wprost – wymagane jest zapoznanie się z opisem procesu. Myślę, że nie jest to korzystne, ponieważ proces akceptacji to przede wszystkim przebieg dokumentu między recenzentami/akceptantami i samym inicjatorem. Jednakże zaletą takiego przedstawienia jest uproszczenie diagramu oraz wskazanie, że kolejni uczestnicy (poza inicjatorem) wykonują podobne czynności. Wdrażając rozwiązanie w systemie będą to prawdopodobnie „wywołania” tego samego przypadku użycia. Taki przypadek użycia będzie musiał przede wszystkim „wiedzieć”, gdzie odesłać i gdzie przesłać dalej dokument, a także kiedy zakończyć proces.

Warto sobie zadać pytania:

• dla kogo ma zostać przygotowana prezentacja procesu?
• do czego zostanie wykorzystana prezentacja procesu?

Odpowiedzi na te pytania determinują poziom szczegółowości procesu i sposób prezentacji. Każda z odpowiedzi: „ma pokazywać kto”, „ma pokazywać co” lub „ma pokazywać jak” może wymusić inny sposób prezentacji. Jedyne co wiemy o oczekiwaniach, to wymóg czytelności diagramu. Wydaje się, że diagram po lewej stronie jest bardziej czytelny, dzięki zastosowaniu podziału na „partycje”, wskazanie stanów dokumentów oraz wykonywanych akcji.