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).

zamowienie_error_500px

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.

Niespełnione oczekiwania jako początek zmian

Ostatnio poszedłem do biura podróży, z którego jakiś czas temu korzystałem, aby dowiedzieć się jakie oferty wycieczek wpasowałyby się w moje oczekiwania oraz warunki graniczne, które określę podczas wyboru. Po przedstawieniu oczekiwań, zapoznaniu się z przedstawionymi ofertami, wyszedłem z biura. I nie czułem się zadowolony. Sposób obsługi, pytania oraz sposób przedstawienia oferty nie był taki jak oczekiwałem. Przedstawicielka biura nie zachęciła mnie do skorzystania z ich oferty, a wręcz zniechęciła. Poszedłem więc do kolejnego biura z myślą, że będzie inaczej. I było. Zdecydowanie. Wyszedłem z biura z bardzo pozytywnymi odczuciami oraz nawet z typami ofert, z których byłbym chętny skorzystać. Dwie rozmowy i dwa jak różne efekty i odczucia. Proces obsługi (z perspektywy biura podróży), którego doświadczyłem, wraz z próbą identyfikacji różnic, przedstawiłem na poniższym diagramie używającym elementów notacji BPMN z dodatkowymi artefaktami i oznaczeniami (które wyjaśnię w dalszej części wpisu).

niespelnione_oczekiwania540px

Proces oznaczony niebieskimi strzałkami to ten, który spełnił oczekiwania, a ten z czerwonymi strzałkami całkowicie odstawał od moich oczekiwań. Jak się okazuje do biura poszedłem z pewnymi oczekiwaniami – oznaczmy je jak M(oje)O(czekiwania) na potrzeby wpisu i powyższego diagramu. Sposób realizacji obsługi dla procesu czerwonego oznaczmy jako R(ealizacja)U(usługi)D(la)C(zerwonego) [odpowiedni obiekt na diagramie]. I odpowiednio dla niebieskiegoR(ealizacja)U(sługi)D(la)N(iebieskiego) [odpowiedni obiekt na diagramie]. Różnica między wartościami odpowiednio RUDC lub RUDN a wartością MO to jest tzw. luka 5 w modelu jakości usług (GAP 5 w ramach Service Quality Model). Jest to luka między otrzymaną a oczekiwaną usługą. W przypadku procesu niebieskiego ta luka, bazując na moich indywidualnych odczuciach, prawie nie występowała a w przypadku czerwonego była bardzo duża.

Wyobraźmy sobie, że właściciele sieci przeprowadzają/zlecają badanie jakości obsługi w swoich punktach sprzedaży lub takie badanie wykonuje niezależna instytucja. I, idąc dalej, to czerwone biuro podróży ma bardzo słabe wyniki w porównaniu do sieci niebieskiej. W takiej sytuacji, aby nie tracić klientów oraz udziału w rynku, właściciel decyduje się, tak załóżmy, na przeprowadzenie benchmarkingu procesów (pisałem o tym 9 lat temu na moim blogu), wzorując się na liderze rynku lub choćby na sieci niebieskiej, po względem budowy wartości dla klienta oraz realizacji procesu obsługi. Tym sposobem został zrealizowany pierwszy krok procesu benchmarkingu identyfikacja obszaru/procesu.

W drugim kroku, jakim jest analiza, sieć czerwona może zebrać informacje o różnicach w sposobie funkcjonowania i realizacji działań na styku klienta i pracownika sieci, gdzie zauważona została luka oczekiwań i efektów realizacji. Mogę sobie wyobrazić, że wyznaczony pracownik sieci czerwonej lub zatrudniona do tego osoba udaje się do sieci niebieskiej, aby na własnej skórze poczuć jak wygląda proces, oraz znając instrukcje oraz wyniki badania, określić gdzie tkwią różnice w sposobie obsługi (na diagramie miejsca z różnicami są zaznaczone obszarami w kolorze szarym). W podanym przykładzie w dwóch miejscach różnica polega na wykonaniu określonego kroku lub nie, a w trzecim miejscu są wykonywane różne kroki. Taka osoba obserwująca proces, może właśnie zauważyć, co robi pracownik, aby przyciągnąć, zachęcić i utworzyć dłużej trwającą relację z klientem. Może też wskazać, że dany krok powoduje znaczną różnicę w budowaniu relacji lub wpływa silnie, bazując na swoim doświadczeniu, na poziom satysfakcji.

Po zebraniu obserwacji, można przejść do dalszych kroków procesu benchmarkingu. Dostosowując proces do obserwacji i doświadczeń można poprawić jakość obsługi klienta. Nie mówię tu o kopiowaniu rozwiązań, a bardziej o wyciąganiu wniosków z doświadczeń i próby spojrzenia na proces w inny sposób. To jak wygląda proces jest uzależnione od wewnętrznej polityki, dostępnych szkoleń i przyjętych założeń obsługi, doświadczeń z przeszłości. Może też być wynikiem istnienia lub próby zaadresowania pozostałych luk w jakości obsługi (czyli luk 1-4)). Wdrażanie na siłę rozwiązań niespójnych z resztą procesów i działań podejmowanych przez organizację, może bardziej zaszkodzić niż pomóc. Taka zmiana może następować stopniowo obserwując na przykład innych graczy na rynku, a nie tylko lidera rynkowego. Ta ciągła zmiana poprzedzona obserwacją konkurentów lub liderów rynkowych, analizie różnic i wdrażania odpowiednich zmian jest sednem procesu benchmarkingu.

W kontekście zmian widocznych dla klienta i zapewniania spójności z wewnętrznymi procesami organizacji, dobrze się zastanowić nad takimi elementami jak:

Gdy aplikacja pamięta Twój telefon

Wczoraj otrzymałem maila o tytule „Próba logowania przy użyciu nieznanego urządzenia”. W pierwszym momencie zacząłem się zastanawiać… Czy ktoś loguje się moimi danymi, a może ktoś się pomylił… Przeglądając jednak treść wiadomości zauważyłem oznaczenie aplikacji, która wygenerowała taką wiadomość. Zainstalowałem na nowym telefonie aplikację (jednego ze sklepów stacjonarnych wraz ze sklepem internetowym), którą miałem także na starym telefonie. Podczas próby zalogowania się pomyliłem się i pewnie aplikacja zidentyfikowała, że logowanie nastąpiło po przerwie, ale z innego urządzenia. Sprawdziłem w regulaminie aplikacji, że oprócz podawanych świadomie danych przez użytkownika, zapisuje ona również numer używanego urządzenia mobilnego. Element ten widocznie pozwala na rozróżnienie, że użytkownik, który próbuje się zalogować użył innego urządzenia. Regulamin wskazuje po co zbiera tę informację i jawnie o tym informuje.

Na poniższym diagramie w BPMN, będącym moim wyobrażeniem procesu występującego w takiej aplikacji na bazie obserwacji aplikacji/narzędzi, z których korzystam, są wskazane kroki (na zielono), które w tle identyfikują urządzenie użytkownika i następnie w przypadku poprawnego logowania zapisują te dane. W przypadku nieudanego logowania, używa tych danych do weryfikacji zgodności urządzenia z poprzednio stosowanym. Taki mechanizm, stosowany także przez inne narzędzia, pozwala podnieść bezpieczeństwo logowania, chronić dane osobowe. Wykonuje to przez każdorazowe informowanie użytkownika na podany podczas rejestracji adres e-mail co najmniej o tym, że nastąpiła jakaś nieudana próba logowania (ścieżka (1) na diagramie).

Niektóre narzędzia/aplikacje wysyłają powiadomienie o poprawnym logowaniu, które nastąpiło z innego urządzenia niż dotychczas (ścieżka (3) na diagramie). W podanym przykładzie nastąpiło wejście do aplikacji, ale nie musi to nastąpić – zależy to od sposobu zbudowania aplikacji i przyjętych założeń. Może być tak, że najpierw użytkownik musiałby potwierdzić, że to on się logował. Na diagramie zostały zaznaczone obydwie takie opcje obok ścieżki gdy dane poprawne logowanie odbywa się z tego samego urządzenia co dotychczas (ścieżka (2)).

dane_logowania_430px

Powyższy przebieg procesu został zasygnalizowany przy użyciu odpowiednich elementów BPMN, przy czym:

  • (oznaczona przez (A)) do przeprowadzenia równoczesnej identyfikacji urządzenia oraz identyfikacji użytkownika pod kątem późniejszej autentykacji  użyto bramek rozdzielających i łączących dla ścieżek równoległych (ang. paralel gateway).
  • (oznaczona przez (B)) do podjęcia decyzji są użyte bramki oparte o dane, w których tylko jedna ze ścieżek jest możliwa (ang. exclusive).

Użytkownik otrzymując taką wiadomość (kroki oznaczone na żółto na diagramie) może zadecydować czy jest to sytuacja, o której wie, czy może jest to sytuacja, na którą powinien zareagować. Na przykład nie używał aplikacji danego dnia lub w ostatnim czasie, a nagle otrzymuje informację o próbie zalogowania nieudanego lub udanego.

Jeżeli dane narzędzie/aplikacja ma taką obsługę logowań, to widzę 2 możliwości:

  • Twórca/Właściciel narzędzia równocześnie zapewnia narzędzia wspierające obsługę reakcji użytkownika (np. tymczasowa blokada użytkownika, kontakt z twórcą/właścicielem lub inne) lub
  • Mechanizm ma tylko charakter informacyjny i użytkownik na własną rękę musi poszukać metod reakcji (np. zmienić hasło).

Myślę, że to dobrze, że istnieją takie mechanizmy. Dzięki takim rozwiązaniom mamy większą pewność, że nasze dane, przechowywane w aplikacji, nie zostaną podejrzane przez nieuprawnioną osobę lub też dowiemy się szybko o tym, że ktoś taką próbę wykonał. Patrząc na serwisy, aplikacje dostępne z różnych urządzeń, jest to duże ułatwienie oraz wsparcie w zakresie realizacji wskazówek dotyczących bezpiecznego korzystania z aplikacji mobilnych (opublikowanych na stronach urzędowych).

Użytkownik otrzymując taką wiadomość w sytuacji, gdy określa ją jako wymagającą zareagowania, powinien zastanowić się jakie dane podał w danej aplikacji – ograniczoną liczbę informacji (np. tylko e-mail) czy dane generujące dla ich właściciela duże ryzyko (np. dane pesel, adres zamieszkania, numer dowodu wraz z wizerunkiem czy danymi finansowymi). Mam nadzieję, że nikt z czytelników mojego bloga nie doświadczył tego bardziej ryzykownego wariantu.


Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.

Gdy brak zdarzenia…

Ostatnio idąc do pracy, zauważyłem jak zmienia się cykl na skrzyżowaniu, które muszę pokonać. Samochody zaczęły zwalniać i w momencie jak dotarłem na skrzyżowanie zapaliło się im czerwone a ja nacisnąłem przycisk dla pieszych, aby wywołać zielone. Niestety zgodnie z cyklem zapaliło się światło zielone najpierw na jednej podporządkowanej, potem na drugiej. W tym momencie powinno zapalić się światło zielone dla pieszych, ale to nie nastąpiło. Przypuszczam, że za późno nacisnąłem przycisk, aby algorytm zmiany świateł to wyłapał. Może przycisk nie działał, choć to raczej nie możliwe, bo często z tego przejścia korzystam. Mogę przypuszczać, że cykl jest ustawiony jak na poniższym diagramie.

cykl_swiatel_450px

Na powyższym diagramie w BPMN wykorzystane zostały elementy:

  • Zdarzenie oparte o czas (nadejście określonego momentu czy minięcie określonego czasu), co jest oznaczone przez obiekt timer event. Na diagramie są 2 takie zdarzenia: początkowe dla procesu (start timer event), oznaczone jako (A) na diagramie oraz pośrednie, występujące wewnątrz procesu (intermediate timer event), oznaczone kolejnymi literami (B, C, D, E).
  • Zdarzenie informujące o otrzymaniu sygnału/komunikatu od zewnętrznego aktora (message event), tym razem zastosowane wewnątrz procesu (intermediate message event). Takim komunikatem/sygnałem jest żądanie od pieszego, który oczekuje zmiany światła z czerwonego na zielone dla przejścia dla pieszych. Ostatnio wskazywałem, że to zdarzenie może rozpocząć proces. W tym wypadku to zdarzenie wpływa na przebieg procesu, który wykonałby się i tak bez tego zdarzenia – nastąpiłaby zmiana świateł, tak, aby samochody z dróg podporządkowanych mogły przejechać przez skrzyżowanie. Różnica między obiektami jest widoczna na diagramach – jedno z nich ma pojedynczą linię (początkowe), a drugie podwójną (wewnątrz procesu).
  • Bramka oparta o zdarzenia (event-based gateway) do rozdzielenia ścieżki. Bramka ta (typu exclusive) działa w ten sposób, że pierwsze napotkane zdarzenie inicjuje uruchomienie ścieżki/przebiegu procesu, występującego po tym zdarzeniu. Na końcu rozdzielenia też jest bramka i w zależności od jej rodzaju – wszystkie ścieżki muszą dojść do tego miejsca lub wystarczy jedna, aby proces przeszedł dalej. W powyższym przykładzie zastosowano również bramkę, która oznacza, że wystarczy tylko jedno z „wejść”, aby przejść dalej w procesie (tzw. exclusive gateway). Taka bramka znajduje się także poniżej, w celu wyboru jednej ze ścieżek, w zależności od tego, czy światło dla pieszych jest zielone czy nie. Decyzja oparta jest o zebrane dane/statusy (exclusive data-based event) a nie zdarzenia. Wcześniejsze zdarzenie (żądanie pieszego) spowodowało zmianę światła lub nie – jest to w sumie zero-jedynkowe. Takie oznaczenie można zaliczyć do danych sterujących procesem. Gdy brak takiego zdarzenia, zadania dotyczące światła dla pieszych w przebiegu procesu zostaną pominięte.
  • Zadania (ang. tasks) wykonywane w procesie – zmiany świateł na czerwone, a potem na zielone dla odpowiednich sygnalizatorów oznaczonych numerami (1)-(4).
  • tzw. artefakty, czyli dodatkowe elementy rozszerzające interpretację diagramu. Dodałem komentarze dotyczące przebiegu procesu, aby lepiej oznaczyć miejsca, które opisuje w punkcie dotyczącym bramek. Są to informacje dodatkowe, które nie sterują przebiegiem procesu, a pozwalają lepiej zrozumieć przedstawiony diagram.

Za pomocą wskazanych obiektów można sterować przebiegiem procesu oraz sekwencją wykonywanych zadań. W zależności od obsłużonych zdarzeń lub ich kolejności wystąpienia, proces pójdzie ścieżką „domyślną”, obsłuży wyjątek lub zastosuje zadania wynikają z alternatywnego przebiegu procesu. Powyższy proces mógłby przebiegać tak, że zawsze następuje przełączenie światła dla pieszego – z czerwonego na zielone, niezależnie od jego żądania.

Może być też tak, że w zależności od liczby żądań, czy jedno czy z dwóch stron jezdni, zmiana świateł dla samochodów następuje szybciej lub czas oznaczający, że konieczne jest przestawienie świateł się wydłuża. Pewnie istnieje też system, który dostosowuje długość cykli do ruchu lub natężenia ruchu pieszych. W niektórych miastach były testowane (a nawet chyba są wdrożone) takie mechanizmy, które badają natężenie ruchu lub mają zmienny system sygnalizacji w zależności od pory dnia.

Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Dzięki niej będę mógł tworzyć treści bardziej dostosowane do Waszych oczekiwań. Jeżeli pojawią się jakieś uwagi do samej ankiety lub problemy z jej wypełnieniem prośba o sygnał w komentarzu lub na adres e-mail podany po prawej stronie.

Przez telefon czy na stronie?

Chyba każdy zna ten moment gdy jest przerwa w dostawie prądu – czy to chwilowa objawiająca się tylko mrugnięciem czy też dłuższa, wymagająca określonych działań (sięgnięcia po latarkę, świeczkę czy inny sprzęt). Gdy ostatnio w sobotę, nastąpiły 3 krótkie „mrugnięcia” a później przyszedł do mnie sąsiad z pytaniem czy coś wiem, przypomniałem sobie o innej sytuacji. Pod koniec roku 2019, dzień przed wigilią byłem w domu z rodziną, mijała właśnie godzina 19 i nagle ciemność – na całym osiedlu. Niezły moment na taki problem – ludzie przygotowują święta, wstawione ciasta, mięsa i inne potrawy a tu brak prądu. Złapałem za telefon i szukam informacji. Za pierwszym razem nic nie znalazłem, a za drugim pojawiła się informacja na mapie dostawcy prądu o  awaryjnej przerwie w dostawie prądu, która jest szacowana na 2 godziny. Minęło kilkanaście minut i prąd znów był dostarczany. A po 20 powtórka, znów ciemność – tym razem na krócej. Informacja na stronie się nie zmieniła.

Mogę sobie wyobrazić, że w momencie pierwszego wyłączenia część osób złapało za telefon i zamiast szukać informacji (sprawdzać samodzielnie) zadzwoniło na pogotowie energetyczne lub na infolinię dostawcy prądu. Mogło być też tak, że ktoś mógł pójść do sąsiada i spytać czy coś wie o na przykład planowanym wyłączeniu prądu. Wyobraźmy sobie jak mógłby wyglądać proces od strony dostawcy, który łączy te dwie możliwości – stronę z informacjami i telefony.

prad_zgloszenie400px

Dostawca na podstawie zgłoszeń telefonicznych i ich weryfikacji mógłby umieścić informację na stronie o awarii. Dzięki czemu zaspokoi potrzebę informacji tych sprawdzających i potencjalnie zmniejszy liczbę telefonów z regionu objętego awarią. Może także mieć system monitoringu, który wskaże mu, że taka awaria nastąpiła. Wejściem do procesu może być zgłoszenie telefoniczne od odbiorcy lub własny monitoring. Wyjściem może być informacja na stronie. Skutkiem pewnie będzie także wysłanie ekipy technicznej w rejon objęty awarią lub inne specyficzne działania.

Na powyższym diagramie próbowałem przedstawić omówiony proces. Na diagramie w notacji BPMN wykorzystałem zdarzenie inicjujące proces, powstałe na bazie zgłoszenia/komunikatu przekazanego przez „zewnętrznego” aktora. Jest to tzw. message start event – jeden z typów zdarzeń (ang. events) używanych w notacji BPMN służącej do modelowania procesów. To zdarzenie na diagramie jest zaznaczone na żółto. Opisany proces nie miałby miejsca, jeżeli takie zdarzenie nie nastąpi. Brak telefonów lub innych zgłoszeń oznacza prawdopodobnie, że nie ma awarii.

Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego blogahttps://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.

Proces nieskończony

Jadąc ostatnio autobusem komunikacji miejskiej, chciałem przy wejściu „odbić” kartę. Karta ta musi zostać przyłożona do czytnika w momencie, gdy nie ma się wykupionego biletu długookresowego a korzysta się z mechanizmu tzw. portmonetki. Zamiast poprawnie naliczonej opłaty zobaczyłem pomarańczowy ekran z błędem. Na szczęście drugi czytnik działał poprawnie.

Po zajęciu miejsca, akurat z dobrym widokiem na czytnik, zauważyłem, że na ekranie jest odliczany czas. Potem następował restart aplikacji, wyświetlenie „poprawnego” ekranu czytnika, informację o błędzie komunikacji i ponownie pomarańczowy ekran. A potem po minucie, znów restart i wszystko zaczynało się od początku. I tak w nieskończoność (tak mi się zdawało). Prezentuje to poniższy diagram w BPMN.

petla_1_kadr

Na powyższym diagramie zaprezentowano typ obiektu BPMN określanego jako podproces (ang. subprocess, co jest oznaczone znakiem „+”) z oznaczeniem wykonywania go w pętli (ang. loop subprocess). Jego charakter wykonywania w pętli jest oznaczony symbolem strzałki (w kształcie okręgu) a same szczegóły działania są opisane na diagramie. W dolnej części diagramu wskazano części składowe tego podprocesu.

Wydaje się, że po określonej liczbie restartów czytnik mógłby się zatrzymać i wyświetlić ekran z błędem i prośbą o skorzystanie z innego czytnika lub mógłby się wyłączyć do momentu ręcznej ingerencji przez operatora (np. na pętli autobusowej). W takiej sytuacji potrzebne byłoby wskazanie liczby powtórzeń oraz obsługi sytuacji, gdy po określonej liczbie powtórzeń efekt procesu nie jest zgodny z oczekiwaniami.

Specjalnie na diagramie zostawiłem oznaczenie błędu (czerwony symbol z „x”) przy obiekcie podprocesu pochodzące z aplikacji, w której go rysowałem. Aplikacja wskazała mi, że nie określiłem poprawnego warunku zakończenia pętli, co zrobiłem świadomie, aby zobrazować, że opisywany proces w rzeczywistości się nie kończył – nie miał np. warunku na liczbę wykonywanych powtórzeń w sytuacji, gdy zdarzenie początkowe pojawia się za każdym razem (np. błąd komunikacji).

Automatyczne reguły oparte o wzorce

Automatyczna odpowiedź: Potwierdzenie otrzymania wiadomości. Państwa wiadomość została przekazana do właściwego pracownika […] ”, a dalej podpis i informacja „Wiadomość została wygenerowana automatycznie, prosimy na nią nie odpowiadać.”. Takiego maila otrzymałem w odpowiedzi na wiadomość skierowaną do podmiotu gospodarczego, wskazując w tytule numer sprawy. Nie otrzymałem jeszcze odpowiedzi na to zgłoszenie. Jednak mogę sobie wyobrazić co się stało na poziomie skrzynki odbiorczej. Mechanizm obsługujący, pobrał tytuł wiadomości, sprawdził do kogo powinna trafić sprawa, a potem wysłał maila z powyższą odpowiedzią. Poniższy diagram w BPMN prezentuje przebieg takiego procesu automatycznego.

buss_rule_1_450px

Na diagramie znajduje się tym zadania „reguła biznesowa” (ang. business rule task), o której pisałem już kilkakrotnie, obrazując ją różnymi przykładami oraz zastosowaniami. W ramach tego kroku następuje próba odnalezienia osoby przyporządkowanej do określonych sformułowań lub numerów użytych w tytule. Mogą to być poszukiwania dokładnego odpowiednika lub zakresów wartości (wzorca). z uwzględnieniem ewentualnych określeń poprzedzających lub następujących po poszukiwanym fragmencie. Reguła może też przewidywać, że inne przypadki są przesyłane do ręcznego przyporządkowania. Reguły mogłyby także zakładać priorytety sprawdzania.

Fragment tytułu (wzorzec) – przykłady Przyporządkowanie
[NR SPRAWY] 2018/06/1* Osoba X
[NR SPRAWY] 2018/06/0* Osoba Y
[NR SPRAWY] 2017/* Skrzynka ogólna
….  
*PRODUKT A* Zespół A
*PRODUKT B* Zespół B
 
*PRODUKT N* Zespół N
RE/ODP:*   Pierwotny nadawca
(lub osoba zastępująca)
brak przyporządkowania Skrzynka ogólna

Gdy odbiorca decyduje

Sprzedaż lub kupno mebla? Sprzedaż książki? Wymiana? Skorzystanie z usług? Przeszukiwanie ofert w okolicy a także dalej. Publikacja oferty. Zakończenie oferty. Promocja oferty. Oddam za darmo. Odbiór własny. Te i inne sformułowania są charakterystyczne dla serwisów, w ramach których zwykły użytkownik Internetu może sprzedać, kupić lub wymienić produkt/usługę. Takich serwisów jest wiele i nabierają popularności. Obsługa ich jest bardzo prosta, w większości przypadków nie wiąże się z opłatami.

Załóżmy, że mamy produkt do sprzedania (książkę, mebel lub inny produkt), który jest w dobrym stanie i którego nie chcielibyśmy wyrzucić a wolimy go oddać w dobre ręce, najlepiej otrzymując za to mniej lub bardziej symboliczną opłatę. Publikujemy ofertę, pojawia się chętny i co dalej?

decyzja_odbiorcy_2_450px

W pierwszej kolejności, ustalamy docelową cenę za produkt, w szczególności, gdy wskazaliśmy, że cena jest do negocjacji. Ustalając cenę należy także wziąć pod uwagę koszt dostawy produktu do odbiorcy – kto płaci? W jakiej formie i kiedy? Mamy więc dwa parametry cena i koszt przesyłki. W sytuacji, gdy odbiór będzie osobisty, koszt przesyłki nie wchodzi w grę. W takiej sytuacji, łatwiej też jest ustalić formę płatności. Przy drobnych produktach, płatność odbywa się przeważnie w momencie przekazania produktu. Innym rozwiązaniem jest nadanie przesyłki z płatnością realizowaną w momencie odbioru przesyłki (tzw. usługa „za pobraniem”) – odbiorca może płacić za produkt lub/i za koszt przesyłki. Jeżeli chodzi o samą płatność, może też odbyć się wcześniej, przed wysłanie produktu – przelew na konto lub inna forma płatności elektronicznej

Na powyższym diagramie (w BPMN) zastosowanodecyzję” opartą o zdarzenia (ang. exclusive event-based gateway), ponieważ to osoba zainteresowana i jej decyzje wpływają na dalszy przebieg procesu. Taka sytuacja występuje w dwóch miejscach – na początku procesu, gdy ustalany jest sposób dostawy, a potem gdy ustalany jest sposób płatności za produkt.

Po co to zdarzenie początkowe?

W przypadku BPMN stosowanie zdarzeń początkowych nie jest obligatoryjne, jednakże dobrą praktyką jest ich stosowanie. Jest to istotne, aby oznaczyć gdzie zaczyna się proces. Łatwiej odbiorcy diagramu określić, która czynność jest pierwsza. Łatwiej mu także zapoznać się z logiką procesu, który jest na diagramie. Wyobraźmy sobie, że na poniższym przykładowym (w BPMN) diagramie nie ma oznaczonego zdarzenia początkowego, które zostało zaznaczone. Skąd będziemy wiedzieć, gdzie się zaczyna proces i co powoduje jego przeprowadzenie? Czy zaczynamy od przekazania raportu do akceptacji czy od korekty?

zdarzenie_poczatkowe_1_450px

Umieszczenie zdarzenia początkowego (ang. start event) ma także tę zaletę, że można okreslić typ tego zdarzenia. Można np, wskazać, że proces ma miejsce co miesiąc, albo w określonym momencie czasu. Także może sygnalizować jakie fizycznie zdarzenia go inicjuje i jakie warunki. Zależy to również od tego jak szeroki proces chcemy pokazać. Jeżeli autor diagramu zakłada, że np. przyjęcie zamówienia jest pierwszym krokiem, to przed nim dobrze jest umieścić zdarzenie początkowe.

Wiele narzędzi stosowanych do modelowania procesów w notacji BPMN kontroluje, czy dana czynność (ang. task) ma połączenie (ang. connection) przychodzące i wychodzące. Zdarzenie początkowe nie wymaga połączenia przychodzącego.

 

Wysłany-odebrany

W wielku polskich miastach na przystankach komunikacji miejskiej można zauważyć tablice, które wskazują godziny przyjazdu lub czas oczekiwania na dany środek komunikacji. Obserwując dane na takim wyświetlaczu można zauważyć, że wskazana liczba minut do przyjazdu np. autobusu spada a czasami rośnie i znów spada. Wskazuje na orientacyjny czas przyjazdu autobusu.

Można przypuścić, że z jednej strony w systemie zakodowany jest czas przejazdu danego autobusu między poszczególnymi przystankami. Jeżeli dany autobus jest spóźniony na poprzedni przystanek, to pewnie orientacyjny czas przyjazdu rośnie (biorąc pod uwagę opóźnienie i czas planowany na przejazd między przystankami). Można sobie wyobrazić, że autobus przyjeżdzając na przystanej wysyła sygnał do systemu, który go odbiera i analizuje, a następnie koryguje czasy wyświetlane na tablicach. W takim komunikacie mogłyby być dane: linia, kurs, czas itp. Taką komunikację opartą wysyłkę I odbiór komunikatu prezentuje poniższy diagram.

wyslany_odebrany_1_450px

Wskazane typy zadania (z BPMN) – wysyłające (ang. send task) i odbierające (ang. receive task) zostały przeze mnie wykorzystane m.in. w poprzednim wpisie w ramach procesu współpracy. Zadania te mają za cel umożliwienie komunikacji między basenami w procesach współpracy. Patrząc na rozwiązania systemowe, mogą to być komunikaty wysyłane w określonym formacie i wyrażone w okreslonym języku (np. XML). Np. w momencie przyjazdu autobusu na przystanek komunikat mógłby być taki:

<?xml version="1.0"?>
<header>
   <sendtime>2016-01-23 12:30:01</sendtime>
   <msgtype>PrzyjazdAutobusu</msgtype>
</header>
<body>
   <busnumber>45</busnumber>
   <kurs>3</kurs>
   <stopnumber>4</stopnumber>
</body>

I w momencie odjazdu z przystanku komunikat mógłby być taki:

<?xml version="1.0"?>
<header>
   <sendtime>2016-01-23 12:33:01</sendtime>
   <msgtype>OdjazdAutobusu</msgtype>
</header>
<body>
   <busnumber>45</busnumber>
   <kurs>3</kurs>
   <stopnumber>4</stopnumber>
</body>