Dla kogo ten krok?

„W drodze”, „Zdezynfekowana”, „Czekam w punkcie” oraz „Odebrana” – takie cztery wiadomości (uogólnione na potrzeby wpisu) otrzymałem ostatnio od podmiotu pośredniczącego w dostawie produktu zamówionego w sklepie internetowym. Pierwszy komunikat pojawił się, gdy podmiot odebrał paczkę, drugi pojawił się, gdy paczka trafiła do sortowni (można to było sprawdzić śledząc paczkę), kolejny, gdy dotarła do wybranego punktu odbioru a ostatni oznaczał, że została odebrana. Dotychczas korzystałem kilkakrotnie z tego pośrednika i dopiero w okresie pandemii, pojawił się ten dodatkowy krok, związany z dezynfekcją (dokładnie ozonowaniem) przesyłki. Jest to krok, który wprowadziło wiele podmiotów. Jeden z nich (znalazłem taką informację w sieci Internet) uzasadnia tę zmianę, tym, że daje ona „możliwość zagwarantowania nadawcom i odbiorcom”, tego podmiotu, „maksymalnego poziomu bezpieczeństwa obsługiwanych przesyłek”.

Gdy czytałem takie informacje dotyczące różnych podmiotów zacząłem się zastanawiać w jaki sposób można scharakteryzować taki krok (ozonowanie/dezynfekcja przesyłki) w procesie dystrybucji paczki. Podnosi, zgodnie z powyższym cytatem, przede wszystkim bezpieczeństwo obsługi paczki – czym zainteresowany jest:

• odbiorca (klient) przesyłki, ponieważ może ją odebrać bez ryzyka kontaktu z wirusami (związanych z pandemią),
• osoby uczestniczące w procesie (pracownicy/personel), mogą spokojnie zająć się przesyłką na różnych etapach procesu, przekazać ją dalej,
• właściciel i interesariusze firmy (akcjonariusze) – jeżeli pracownicy są bezpieczni, nie generuje to potencjalnego kosztu przestoju, szukania dodatkowych osób, generowania opóźnień w dystrybucji czy też akcji dodatkowej dezynfekcji większych powierzchni; jest to także pewnie wynik optymalizacji kosztowej – gdzie pewnie ryzyko związane z obsługą zainfekowanej przesyłki i szacowany koszt likwidacji skutków był porównany z kosztem wprowadzenia takiego kroku i jego stosowania w procesie.

Element ten to także budowa wizerunku i jasny komunikat dla społeczeństwa, że realizujemy dodatkowe kroki, aby nasi Klienci oraz pracownicy czuli się bezpieczni. To także reagowanie na zmieniające się otoczenie, wymogi sytuacji oraz możliwość zapewnienia ciągłości działania.

Można powiedzieć, że taki dodatkowy krok w procesie tworzy „wartość„. W szczególności, że nie wiąże się z dodatkowymi kosztami, a potencjalne (teoretyczne) opóźnienie z tego tytułu wydaje się akceptowalne z perspektywy odbiorcy. Dla mnie osobiście tak.

Na diagramie graficznie oznaczyłem dla kogo wynika wartość z tytułu poszczególnych etapów procesu oraz pojawienia się tego nowego elementu w procesie. Zgodnie z wyjaśnieniem powyżej – krok jest „współdzielony” przez różne zainteresowane strony. Dodatkowo został dodany stan dot. przeprowadzenia komunikacji na „rynku” dla potencjalnych/zainteresowanych osób o wprowadzonej zmianie. Diagram przedstawiony został w postaci diagramu stanów (ang. state diagram), opierając się na stanach zakomunikowanych odbiorcy bezpośrednio – pominięte zostały stany wskazane w mechanizmie śledzenia przesyłki. Są to stany kluczowe  dla przebiegu procesu, określające jego ramy zarówno z perspektywy dostawcy przesyłki, odbierającego ją od sklepu internetowego (sprzedający), jak i dla końcowego Klienta (kupujący), ponieważ szybko może się zorientować, na jakim etapie jest jego przesyłka i czy może udać się do punktu odbioru.

Dobrze jest zwrócić uwagę na takie inforamcje dotyczące podmiotów, z których korzystamy w okresie pandemii, ze szczególnym uwzględnieniem tego, czy podmiot wykonuje to bezpłatnie oraz na jakich warunkach i przy jakich ograniczeniach. Pozwoli nam to uniknąć na przykład sytuacji, gdy zostaniemy naciągnięci przez oszustów wykorzystujących taką sytuacją na rynku.

Reklama

Ocena zamówienia – moment i konstrukcja

Udało się! Dotarło bez części zamówionych produktów, ale wreszcie odebrałem zamówienie, o którym pisałem w poprzednim wpisie. Przyszło w całości, nieuszkodzone, bezpiecznie zapakowane. Choć spodziewałem go się trochę wcześniej. Patrząc na zrealizowany proces mogę dla niego wskazać następujące komentarze:

1. (+) sklep posiadał produkty, których szukałem,
2. (+) ceny produktów były akceptowalne,
3. (+) dostępne sposoby płatności i dostawy pozwoliły wybrać to, co mi pasuje,
4. (+) nie odwołali/nie wstrzymali zamówienia w przypadku problemów,
5. (+) produkty przyszły w całości,
6. (-) zamówienie przyszło z opóźnieniem,
7. (-) informacje o dostępności produktów nie są do końca prawdziwe, przez co nie dostałem kompletu zamówienia.

Podsumowując:  jestem zadowolony z realizacji tego zamówienia – biorąc pod uwagę liczbę (+) i (-). Co ciekawe sklep ma specyficzny sposób zachęcania do wypełnienia ankiety o zrealizowanym zamówieniu. Pierwszy raz dostałem prośbę, jeszcze przed wysyłką zamówienia – zachęcała do tego wiadomość: „Wystaw opinię o naszym sklepie w zamian za…..” – sprawdziłem, że przyszła po statusie „gotowy do wysłania”. Dzień po odebraniu przesyłki przyszła kolejna wiadomość: „Twoja opinia jest dla nas ważna”, która także odwoływała się w treści do możliwości nagrodzenia za wydanie opinii.

Na poniższym diagramie stanów w UML (ang. state diagram) umiejscowiłem tę prośbę o ocenę (stan „Brak oceny”) w całym procesie zamówienia, patrząc z perspektywy statusów, które otrzymałem w postaci wiadomości e-mail lub określiłem sobie samodzielnie (oznaczone na szaro).

Po otrzymaniu pierwszej wiadomości, zadałem pytanie: co tak szybko? Przecież zamówienie nawet do mnie nie zostało wysłane. Po drugiej wiadomości, zacząłem zastanawiać się czy chcę wypełniać tę ankietę i w jaki sposób ten fakt wpłynie na moją ocenę, uwzględniając również to, co opisałem w poprzednim wpisie. Ostatecznie uruchomiłem proces oceny, chcąc sprawdzić, czy będzie okazja do wypowiedzenia się w tej kwestii. Wyglądało to następująco:

• Pytania dotyczyły zakupionego produktu – czyli pytania dotyczące komentarzy (1) i (5) powyżej.
• Pytania dotyczyły procesu w samym sklepie – dla (2), (3) i (7) powyżej.
• Pytania dotyczyły czasu dostawy – dla (4), (6) i (7),
• Prośba o dodatkowe komentarze – tutaj mógłbym wskazać te elementy, o które nie było pytania bezpośrednio. Mógłbym pochwalić za pewną elastyczność związaną z brakiem produktów równocześnie wskazując, że można byłoby to poprawić. Mógłbym wskazać zastrzeżenia co do ankiety itd.

Zabrakło mi w czasie czy nawet przed wypełnieniem ankiety informacji, czy ankieta jest anonimowa, czy zostanie opublikowana na stronie czy tylko przesłana. Dopiero na ostatnim kroku, jest informacja o akceptacji regulaminu, który odpowiada na te pytania. Wydaje się, że taką informację w skrócie można byłoby zawrzeć na 1 ekranie lub w innej formie.  Można też powiedzieć, że wystarczyłaby wysyłka ankiety w tym drugim kroku, na przykład 2 dni po nadaniu przesyłki, zakładając standardowy czas realizacji dostawy dla wybranej formy dostawy.  Plusem jest to, że ankieta jest prostsza od tej, którą kiedyś opisywałem. Ma też element niestandardowy jakim jest możliwość zamieszczenia zdjęcia lub dodatkowe informacji związanej z zamówionym produktem (np. zachęcają do pokazania jak go odbiorca wykorzystuje).

Umiejscowienie prośby o ocenę dla zamówień , które ostatnio składałem, było różne. Konstrukcja ankiety również.   Przeważnie przychodziły w momencie powiadomienia o wysłaniu zamówienia. W jednym przypadku przyszła informacja z pewnym opóźnieniem. Ten czas opóźnienia dla ankiety jest dość istotny – z jednej strony wpływa na to ile pamiętamy z realizowanego procesu, a z drugiej może wpłynąć na samą chęć wypełnienia ankiety. Zależy to od tego jak sprawnie przeszło zamówienie, jakie spowodowało reakcje, a także od podejścia odbiorcy – jedni nie wystawiają ocen wcale a inni to robią zawsze i wszędzie. Reszta z odbiorców jest gdzieś pośrodku i pewnie na pytanie o to, czy wystawią ocenę, odpowiedzą krótko „to zależy”.  Podobnie jest z konstrukcją ankiety – długa i szczegółowa może zniechęcić do jej wystawienia. Prosta i krótka może zachęcić do jej częstego wypełnienia.

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.

Wzorcowa pizza

Wyobraźmy sobie, że jesteśmy w pizzerii i mamy ochotę zjeść pizzę. Nie wiemy jeszcze jaką, ale będzie to pizza. Można powiedzieć, że danie to jest pewien sposób abstrakcyjne, bliżej nieokreślone, do momentu, gdy zapoznamy się z menu i dowiemy się jakie są możliwości. Spośród rodzajów pizzy, np. Amerykańska, Wegetarianska, Hawajska, Rzeznicka itp., będziemy wybierać konkretną na podstawie jej składników, które w niej będą. Przeglądamy menu i decydujemy się na konkretne składniki – na przykład Ser, Szynka, Salami lub Ananans, Ser itd.

Wymienione składniki też są w pewien sposób abstrakcyjne, nie wiemy jak będą ułożone, ile ich będzie, jak będą duże, ale wiemy, że będzie to określony składnik.
Mamy więc od strony Klienta: wybraną pizzę składająca się z wymienionych składników.
Restauracja wie jaka pizza z jakich się składa elementów, ale dopiero w momencie przygotowania nastąpi ich wybór.

Powyższy przykład, opierając się na wyborze abstrakcyjnych składników z jednej strony, a dostarczenia konkretnych produktów z drugiej, można przedstawić za pomocą wzorca projektowego fabryka abstrakcyjna (ang. abstract factory).
Wzorzec ten składa się z elementów, zaprezentowanych na powyższym przykładowym diagramie UML:

• Fabryka abstrakcyjna (ang. abstract factory) – interfejs dla klienta do wyboru konkretnych rodzajów pizzy. Na diagramie oznaczony jako „AF”.
• Fabryka konkretna (ang. concrect factory) – określa elementy konieczne do stworzenia danej pizzy z elementów składowych. Na diagramie oznaczony jako „CF”.
• Produkt abstrakcyjny (ang. abstract product) – interfejst dla klienta do wyboru rodzaju składników pizzy. Na diagramie oznaczony jako „AP”.
• Produkt (ang. product) – konkretna realizacja oczekiwana przez klienta – dany składnik pizzy. Na diagramie oznaczony jako „P”.
• Klient (ang. client) – używa powyższych elementów (wybiera pizzę, składniki). Na diagramie oznaczony jako „C”.

Klient inicjuje wybór pizzy, wybierając jej składniki, fabryka tworzy, w zależności od wybranej pizzy, odpowiednie zestawienie składników. Te zależności obrazują strzałki użytkowania (ang. uses) elementów na diagramie.

Proces akceptacji – sposób sterowania

Zastanawiałem się po przeczytaniu komentarzy do poprzedniego wpisu nad rozwiązaniem dla procesu akceptacji dokumentu. Wydaje się, że są dwa możliwe rozwiązania:

1. System wspiera proces akceptacji i decyduje o tym do kogo trafia dokument po wykonaniu danej akcji. Określa również kiedy proces jest zakończony. Na poniższym diagramie górna część (Diagram A) prezentuje takie podejście. System po akcji użytkownika „Zatwierdź” lub „Odrzuć” wykonuje „Określenie osoby” i ewentualnie „Przesyła dokument”. Operacja „Prześlij dokument” może wystąpić bądź nie. Podobnie w wyniku „Określ osobę” może zostać zakończony proces.
2. Użytkownik decyduje o osobach uczestniczących w procesie. Po wykonaniu „Akceptuj” lub „Odrzuć” użytkownik decyduje, czy przesłać dokument dalej, skonsultować go, czy całkowicie odrzucić. Rolą systemu w takiej sytuacji jest śledzenie i odnotowywanie zmian. Taka sytuacja jest przedstawiona na dolnej części poniższego diagramu (diagram B).

Na powyższym diagramie (diagram przypadków użycia w UML) za pomocą powiązań <<include>> oraz <<extend>> przedstawiono specyfikę następujących przypadków użycia:

• „Określ osobę” – użyto powiązania<<include>>, które oznacza, że zawsze podczas „Zatwierdź dokument” oraz „Odrzuć dokument” występuje „Określ osobę”.
• „Prześlij dokument” – użyto powiązania <<extend>>, które oznacza, że jedynie w określonych sytuacjach (przy spełnieniu ustalony warunków), zostanie wywołane „Prześlij dokument”.

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.

Status – informacja dla klienta czy dostawcy?

Zanim odpowiem na pytanie postanowione w komentarzu do poprzedniego wpisu, chciałbym przedstawić jeszcze jeden przykład. Przykład będzie dotyczyć statusów zamówienia w systemie składania zamówień przez klienta. Informacja o statusie może być przydatna zarówno dla klienta, który chce być informowany na jakim etapie jest zamówienie, jak i dla dostawcy, który może na tej podstawie tworzyć raporty. Można także pójść dalej i przechowywać dwa rodzaje statusów – zewnętrzne (biznesowe) i wewnętrzne (systemowe). Obydwa statusy mogą wynikać z wymagań.

Zastanówmy się w takim razie w jakich statusach może być zamówienie w analizowanym systemie składania zamówień:

• zainicjowane/utworzone (z pierwszym dodanym produktem, klient może dodać kolejne produkty lub zaprzestać na jednym);
• złożone (klient wysłał zamówienie do realizacji);
• oczekujące na realizację (klient zrealizował płatność na złożone zamówienie lub potwierdził złożenie zamówienia);
• w trakcie realizacji/realizowane (gdy realizacja zamówienia została rozpoczęta i jest w trakcie, w systemie obsługi opartym o kolejkowanie, można powiedzieć, że zamówienie zostało podjęte);
• wykonane (przedmiot zamówienia został przekazany do klienta);
• anulowane (klient wycofał zamówienie z różnych powodów już po złożeniu zamówienia);
• wstrzymane (realizacja zamówienia została zatrzymana z różnych przyczyn);
• usunięte (klient usunął zamówienie przed jego złożeniem);

Poniższy diagram (stanów) w UML prezentuje przejścia między poszczególnymi statusami (stanami Zamówienia).

Obsługa wyjątków w wymaganiach

W trakcie funkcjonowania procesów biznesowych, systemów czy aplikacji komputerowych mogą wystąpić sytuacje zwane wyjątkami (ang. exceptions). Mogą one być związane bezpośrednio z czynnościami wykonywanymi przez użytkownika/uczestnika procesu, a także wynikać z problemów z funkcjonowaniem wykorzystywanych narzędzi. W szczególności możemy mówić o:

• nieautoryzowanych żądaniach,
• błędnie wprowadzonych danych,
• niedostępności narzędzi, usług, baz danych,
• czasie odpowiedzi przekraczającym ustalone parametry biznesowe,
• awariach wydajności,
• utracie połączenia
• itp.

Podczas projektowania aplikacji istotne jest to, aby w wymaganiach wskazać sposób obsługi sytuacji wyjątkowych. Strategie mogą być różne – począwszy od raportowania każdego błędu do użytkownika i przenoszeniem na niego odpowiedzialności poradzenia sobie z sytuacją, poprzez wspieranie użytkownika w rozwiązywaniu problemu, po implementację mechanizmów, które automatycznie próbują rozwiązać zaistniałą sytuację.

Na diagramach przedstawionych (wskazanych) w poprzednim wpisie pojawił się element komunikacji Zarządcy z InterfejsemERP czy pośrednio z BaząProduktów. Patrząc jedynie na ten element można mówić o różnych sytuacjach.

Na powyższym diagramie (diagram sekwencji w UML) zaprezentowano dwa wyjątki: timeout i failure. W przypadku tego pierwszego można by wskazać, że ma powtarzać wywołanie na przykład 3 razy i dopiero przy kolejnej nieudanej próbie informować użytkownika i zapisywać sytuację w bazie. Obsługa wyjątków jest istotna w systemach wykorzystujących usługi lub pracujących na dużych bazach danych. Na diagramie nie wskazano WczesniejZakupione, InniKupowali oraz Promocje, aby zachować pewien poziom ogólności. Jednakże warto przypomnieć, że wskazane elementy uczestniczą w interakcji między WyszukiwarkaProduktow a BazaProduktow. Nie została również pokazana sytuacja, gdy dane pochodzące od użytkownika były błędne.

Diagram klas – „reinżynieria” (etap 2)

Kolejnym etapem tworzenia diagramu klas, przedstawionego w poprzednim wpisie (Diagram klas – reinżynieria (etap 1)) jest uzupełnienie go o atrybuty oraz metody. Poniższy diagram zawiera takie przykładowe uzupełnienie:

Diagram klas – „reinżynieria” (etap 1)

Wcześniej zostały zaprezentowane dwa diagramy klas (pierwszy i drugi), które prezentowały w różny sposób, mniej lub bardziej poprawny, pewną dziedzinę. Na diagramach zostały wskazane metody, atrybuty oraz zostały opisane związki. Po dyskusjach na wcześniej wspomnianym forum, przemyślałem propozycje i postanowiłem, że stworzenie tego diagramu klas to będzie dobry przykład podejścia o charakterze reengineeringu lub benchmarkingu, zależy jak na to spojrzeć. Zacznę od początku, a to jest cecha bliska reengineeringu. Zastosuję wskazówki, wnioski z dyskusji, porównania się z doświadczeniami innych, co przypomina benchmarking (o różnicy między tymi dwoma podejściami, w zakresie procesów, postaram się napisać w kolejnym wpisie).

Kilka słów o tym, co chciałbym przedstawić:

• mamy klienta (klientów), który składa zamówienia on-line u dostawcy pewnych produktów,
• u dostawcy dostępne jest wiele produktów, o różnych cenach, parametrach, wadze itp.,
• zamówienie może się składać z od jednego do wielu produktów,
• za zamówienie klient może dokonać płatności na 3 różne sposoby: kartą kredytową, przelewem lub gotówką.

Mamy więc: Klienta, Zamówienie, Produkt oraz Płatność, co na diagramie można przedstawić następująco: