Oczekiwane statystyki czasu realizacji

Pozostając w wątku zakupów internetowych, dziś ponownie nawiąże do wiadomości e-mail, którą otrzymałem. W tym samym tygodniu, co ankietę, otrzymałem maila od innego sklepu, w którym zwykle robię takie zakupy, ale ostatnio czas realizacji zamówienia nie był dla mnie akceptowalny. Nastąpiło wydłużenie czasu od złożenia zamówienia do nadania przesyłki przez sklep. Wcześniej były to 1-2 dni, a ostatnio nawet tydzień. Po otrzymaniu tej wiadomości, dałem im szansę, bo w ofercie mają kilka produktów, których nie ma ten drugi sklep (czyli szerokość oferty  bardziej mi odpowiada). A może nie miałem wyjścia?

Treść wiadomości zawierała sformułowania typu „Zdajemy sobie sprawę, że nasz serwis w tym okresie mógł zawieść Twoje oczekiwania […] mamy nadzieję, że te chwilowe problemy nie wpłyną na dotychczasowe zaufanie.[…] Przywróciliśmy standard realizacji zamówień – wysyłamy przesyłki w ciągu 1-2 dni roboczych od złożenia zamówienia. […]”. Na koniec było odesłanie do serwisu ze wskazanymi czasami realizacji.

czas_realizacji450px_v3

Na diagramie, który zamieściłem kiedyś we wpisie z przykładami czasu realizacji (powyżej), zaznaczyłem miejsce, które sklep pewnie monitorował i zauważył, że nastąpiło jego znaczne wydłużenie. Taka obserwacja jest prosta do monitorowania – wystarczy badać czas między zapisem/złożeniem zamówienia (czas zapisu/złożenia – Z) a czasem odnotowania nadania przesyłki (czas nadania – N). Obydwie informacje przychodzą w wiadomości e-mail w postaci statusów, więc muszą być także odnotowane w systemie.

Sklep może prowadzić dzienny monitoring czasu realizacji zamówienia (N-Z) w zakresie maksymalnej wartości, minimalnej, mediany, dominanty czy średniej (pojęcia wyjaśnione poniżej). W zależności od rozkładu tych wartości, może podejmować odpowiednie decyzje lub zaplanować właściwe kroki. Jeżeli wartości wykraczające poza 1-2 dni są sporadyczne pewnie nie wymagają pilnych akcji.

Gdyby zobrazować na wykresie częstość występowania poszczególnych czasów realizacji dobrze byłoby, gdyby wykres był prawostronnie skośny (co zostało zaprezentowane na diagramie). Oznacza to, że większość wartości jest na początku przedziału 1-2 dni, a mniej powyżej 2 dni.

Rozkład prawostronnie skośny to taki rozkład, w którym zachodzi nierówność dominanta < mediana < średnia, czyli

  • [średnia:] średni czas realizacji zamówienia jest wyższy niż
  • [mediana:] czas realizacji zamówienia, który dzieli wszystkie pomiary czasu na 2 równe części co do występowania, a ten jest większy od
  • [dominanta:] czasu, który występuje najczęściej w rozkładzie czasów realizacji.

 

Współdzielenie listy zakupów – „pull” czy „push”?

W ramach poprzedniego wpisu dotyczącego elektronicznej listy zakupów wskazałem, że jedną z funkcjonalności dostępnych w aplikacjach wspierających zakupy, jest możliwość współdzielenia listy zakupów. W aplikacji, z której korzystałem, to współdzielenie oparte było o podawanie adresu e-mail, przy założeniu, że zarówno tworzący listę, jak i ją otrzymujący jest zarejestrowanym użytkownikiem aplikacji i ma założone konto na serwerze aplikacji.

Użytkownicy aplikacji w ramach udostępnionej listy mogą:

  • dodawać/edytować produkty na liście,
  • śledzić postęp zakupów realizowanych przez drugą osobę,
  • kopiować listę na przyszłość.

Założeniem dla funkcjonowania współdzielenia listy zakupów, był dostęp do sieci Internet z poziomu urządzenia, na którym jest zainstalowana aplikacja. W sytuacji utraty dostępu do sieci Internet, zmiany na liście oczekiwały na podłączenie się drugiego użytkownika listy. W przypadku dostępu do sieci Internet przez obydwa urządzenia, zmiany były przekazywane w miarę na bieżąco.

Wspólny proces dla obydwu użytkowników jest przedstawiony na poniższym diagramie.

wspoldzielenie450px_1

Dla współdzielenia listy można byłoby zastosować dwa modele „współpracy”:

  • model „push” (aplikacja inicjująca zmianę przy pomocy pośrednika przekazuje zmiany do drugiej aplikacji)
  • model „pull” (jedna aplikacja przekazuje zmiany do wspólnego miejsca, a druga odpytuje o ewentualne zmiany w liście)

Wariant: model „push
Użytkownik – właściciel listy – rejestruje listę, udostępnia ją, a następnie wprowadza na niej zmiany. Wszystkie te elementy są przesyłane na serwer obsługujący aplikację. Każda zmiana jest rejestrowana i przekazywana do aplikacji odbiorcy listy (wskazanego poprzez e-mail). Serwer wysyła informację o zmianach do aplikacji użytkownika, rejestrując wysłane zmiany. Ewentualna zmiana przez drugą aplikację jest wysyłana analogiczną ścieżką. Na diagramie przedstawiona została ta komunikacja, gdzie każda zmiana jest „pchana” (ang. push) na serwer a następnie do drugiej aplikacji.

wspoldzielenie450px_2

W tym celu został wykorzystany wykres wyglądający jak diagram sekwencji (znany z UML) z pewnymi dodatkami. W projektowaniu rozwiązań można znaleźć wzorzec fire-and-forget, w którym informacje są przesyłane bez oczekiwania na reakcję odbiorcy. Trochę jak tutaj, bo w tym modelu aplikacja nie czeka na informację zwrotną.

Wariant: model „pull
Podobnie jak w poprzednim wariancie, użytkownik – właściciel listy – rejestruje listę, udostępnia ją, a następnie wprowadza na niej zmiany. Wszystkie te elementy są przesyłane na serwer obsługujący aplikację. Trafiają na listę zmian/działań (ang. queue) wykonanych na liście zakupów w postaci zdarzeń typu: udostępnienie listy, zmiana listy, zakup produktu (a dokładnie jego odklikanie) itd. W momencie ustawienia udostępnienia listy, zmiany na utworzonej liście są dostępne do pobrania/odczytania (ang. pull) przez drugą aplikację. W sytuacji, gdy takie udostępnienie nie nastąpi, zmiany są odnotowywane na serwerze i są dostępne tylko dla właściciela listy.

wspoldzielenie450px_3

Na diagramie jest przedstawiony ten model. W projektowaniu rozwiązań można znaleźć wzorzec publish-subscribe, który zakłada, że odbiorcy pobierają interesujące ich informacje z miejsca, gdzie zostały wystawione.

Pewnie można byłoby jeszcze zidentyfikować kilka innych wariantów, gdzie ta komunikacja jest bardziej dwustronna. Jednakże biorąc pod fakt, że aplikacja jest zainstalowana na urządzeniach mobilnych i nie w każdej sytuacji aplikacje będą miały dostęp do internetu, jakiś sposób przechowywania i kolejkowania zmian jest konieczny.  Dodatkowo użytkownicy wykonują często operacje zmiany i przeglądania zmian w różnym czasie lub tworzenie listy jest rozłożone w czasie. Patrząc od strony „odbiorcy” listy, także może zmodyfikować listę w czasie jej dostępności. Takie zmiany są „przesyłane zwrotnie” do właściciela listy.

Zakupy wg elektronicznej listy

Gdy chodzę między półkami sklepowymi obserwuję w jaki sposób klienci danego sklepu wspomagają się w tym, aby nie zapomnieć o jakimś produkcie. Jedni korzystają z list zapisanych na papierze (na kartce, w notatniku), inni patrzą w ekran (komórki lub innego sprzętu), a inni jeszcze wyglądają jakby wszystko pamiętali (a może kupują to, co im się rzuci w oczy). W ramach swoich zakupów korzystałem z każdej z tych opcji, więc robiłem zakupy wg jakiejś listy (o czym już kiedyś pisałem).

Dzisiaj chciałbym się skupić na liście elektronicznej. Przez jakiś czas korzystałem z jednej z dostępnych aplikacji na komórkę. Aplikacje te mają pewnie wiele elementów wspólnych. Bazując na tej, z której korzystałem, można powiedzieć, że:

  • wspierają tworzenie listy (dodawanie, usuwanie, edytowanie, nadawanie kategorii automatyczne lub ręczne),
  • wspierają odtwarzanie listy (np. kopiowanie poprzedniej do nowej – całej lub wybranych produktów),
  • umożliwiają kontrolę postępu zakupów (oznaczanie zakupionych),
  • umożliwiają współdzielenie listy zakupów z innymi osobami,
  • pozwalają na dodawanie produktów w promocji z listy podłączonych gazetek lub list produktów promocyjnych,
  • pozwalają na sortowanie produktów,

Na poniższym diagramie jest zaprezentowany proces tworzenia takiej listy zakupów.

zakupy450px

Co ciekawe w aplikacji, z której korzystałem, była możliwość wykorzystania wyszukiwarki produktów – wpisując fragment nazwy podpowiadał produkty lub wskazywał te, które kiedyś zostały dodane. Bardzo to przyspieszało tworzenie listy. Ten element jest zaznaczony na diagramie za pomocą „*” oraz rozpisany w dodatkowej ramce.

Co ciekawe chęć dodania dwóch takich samych produktów wymagała jedynue podwójnego „kliknięcia” w wyszukany produkt, a usunięcie wymagało jednego ruchu palca. Mając powtarzalną listę zakupów lub produkty na różnych listach, można było je kopiować do nowo tworzonej listy a potem edytować oraz usuwać. Wpisanie jednostek czy dokładniejszych informacji, z czego rzadko korzystałem, wymagało wejścia w opcję edycji konkretnej pozycji na liście. Było to bardzo wygodne.

Produkty oznaczone jako kupione, „spadały” na dół ekranu i były wyszarzane. Lista „braków” się skracała i była widoczna cały czas od góry ekranu. W przypadku pomyłki lub zmiany zdania można było produkt „odznaczyć” i wracał „na górę”.

Polecam taką formę budowania listy zakupów i jej wykorzystania. W sieci można znaleźć wiele artykułów od tym jakie funkcjonalności powinna mieć dobra aplikacja na komórkę do wspierania zakupów, listy najlepszych aplikacji oraz ich wymagania.

Poziom akceptacji

Proces kredytowy, wniosek o dotację, wniosek o dofinansowanie, proces rekrutacji… składa się na pewno z dwóch kroków – złożenia wniosku oraz podjęcia decyzji/oceny przez określoną jednostkę/grupę osób. Decyzja taka podejmowana jest na podstawie określonych kryteriów, działań ręcznych lub/i automatycznych lub w oparciu o wiedzę ekspercką/doświadczenie. W szczególności ten ostatni element jest ciekawy, ponieważ można go rozciągnąć na inne działania, takie jak na przykład udział w konkursie fotograficznym. Właśnie wyniki z jednego z konkursów zainspirowały mnie do tego wpisu. W wynikach pojawiło się pojęcie poziomu akceptacji. Mogę przypuszczać, że na akceptację złożyły się 2 elementy – spełnienie kryteriów podczas zgłoszenia do konkursu oraz pozyskana ocena zdjęć w ramach obrad jury.

Poziom akceptacji można określić jako liczbę wniosków/zgłoszeń, które przeszły punkt oznaczony na zielono na diagramie (punkt B) i przeszły do końca procesu, względem wszystkich zgłoszeń, które zostały zgłoszone do konkursu, co zostało oznaczone kolorem niebieskim na diagramie (punkt A). Wartość B/A wyrażona procentowo to prawdopodobnie poziom akceptacji, który pojawił się w opublikowanych wynikach.

poziom_akceptacji2_450px

Informację też można byłoby podzielić dodatkowo, wprowadzając punkt zaznaczony na czerwono na diagramie (punkt C), informujący o tym ile wniosków/zdjęć zostało zaakceptowanych formalnie, ale nie otrzymało wymaganej oceny eksperckiej aby przejść dalej, czyli nie kwalifikowało się do nagrody lub publikacji podczas wystawy. Mamy więc:

  • B/A – poziom akceptacji
  • C/A – poziom akceptacji formalnej (spełnienie kryteriów)

Podobnie można byłoby podejść do pozostałych wskazanych procesów oraz sytuacji biznesowych.

Obserwacja poziomu akceptacji dla procesów biznesowych może być przydatna, w szczególności, gdy zbadamy obydwa wskazane miejsca. Jeżeli na przykład większość wniosków odpada na punkcie C (kryteria formalne), to może to oznacza, że:

  • wniosek/kryteria są nieczytelne lub nieprecyzyjne (nie zakładam tu świadomego działania);
  • konieczne są dodatkowe działania edukacyjne, komunikacja, przykłady lub wsparcie podczas wypełniania wniosków;

Jeżeli natomiast zdecydowana większość odrzuceń odpada na punkcie B (decyzja/ocena), może to być spowodowane tym, że:

  • wzrósł poziom ryzyka/niepewności wśród wnioskujących;
  • spadł poziom akceptowalnego ryzyka w jednostce przyjmującej;
  • obniżony został dostępny budżet lub liczba nagród;
  • istnieje brak/nadmiar odpowiednich wniosków/kandydatów;
  • nastąpiły zmiany w otoczeniu rynkowym lub jego zachowaniu;

W pewnych sytuacjach obniżenie poziomu akceptacji może być oczekiwaną lub zamierzoną sytuacją, a w innych może to być przypadek lub coś co zaskoczyło daną jednostkę lub opiekuna procesu. Myślę jednak, że warto przyjrzeć się zmianom poziomu akceptacji w czasie, poszukać tego przyczyn lub sposobów na ustabilizowanie sytuacji.

Nadmiarowe statusy?

Po opublikowaniu poprzedniego wpisu, dotyczącego „jakości” danych w systemie, z którego korzystają użytkownicy, robiłem porządki w poczcie. Przeglądałem wiadomości, których już nie potrzebuję, a dotyczyły opisanych we wpisie przypadków. W ramach listy wiadomości dotyczących przypadku (3), gdy zamówiony produkt był dostępny wg strony sprzedawcy, ale nie było go u dostawcy , zwróciłem uwagę na jedną rzecz. Wiadomości dotyczące tego zakupu zawierały nietypową, porównując do innych wiadomości, listę statusów zamówienia, które otrzymałem.

O statusach pisałem już wiele razy i z tych wpisów, bazujących na otrzymanych wiadomościach, statusy można sprowadzić do listy: utworzone, złożone, w trakcie realizacji, wysłane, dostarczone. Czasami pojawiały się statusy pośrednie lub dotyczące firmy dostarczającej przesyłkę. Statusy te wydawały się uzasadnione i przy okazji w wiadomościach wskazywane były dodatkowe możliwości (np. zmiana godziny dostawy). Natomiast w przykładzie do którego zmierzam, te statusy były inne, co prezentuje poniższy diagram.

nadmiarowe_statusy450px

Jak widać, jako Klient zostałem poinformowany, że złożyli zamówienie u dystrybutora (2 osobne wiadomości dla każdego produktu), potem, że idzie ono do magazynu (znów 2 wiadomości), a potem, że tam dotarło (uff… jedna wiadomość)…  Wybrane statusy były osobno dla każdego produktu. Wydaje się, że te trzy statusy mogłyby być przekazane jako w trakcie realizacji lub w kompletacji (przypadek z pewnego sklepu). A potem dopiero status wysłane. Byłoby to myślę wystarczające. To, że złożyli zamówienie u dystrybutora nic mi nie mówi i jest to raczej status wewnętrzny sklepu. Co ciekawe nie ma potwierdzenia złożenia zamówienia przez Klienta.

I tutaj przypomina mi się Brzytwa Ockhama, która zakłada, że „nie należy mnożyć bytów ponad potrzebę”. Moim zdaniem tutaj można byłoby tę zasadę zastosować i ograniczyć liczbę statusów do 2 i w szczególności nie rozdzielać statusów osobno na każdy produkt z zamówienia, a traktować je jako całość. Zamówiłem tylko 2 produkty i dostałem 6 wiadomości, a mógłbym dostać 2. Pierwszy np. o treści dla zamówienie w trakcie realizacji: „Otrzymaliśmy Twoje zamówienie i informujemy, że jej kompletujemy. Poinformujemy Cię, gdy zostanie ono wysłane” i drugi dla zamówienie wysłane: „Wysłaliśmy Twoje zamówienie. Dziękujemy za skorzystanie z naszych usług”. Byłoby prościej i otrzymałbym mniej wiadomości, które i tak potem usuwam.

Nieudany proces

Miesiąc temu pisałem we wpisie o procesie zamówienia, w którym firma dostarczająca produkt informowała mnie o każdym zrealizowanym i planowanym kroku z bardzo dużą dokładnością. Proces zakończył się sukcesem, w szacowanym terminie – produkt został dostarczony. Mogę powiedzieć, że każdy z przekazanych statusów odzwierciedlał sytuację rzeczywistą. Do każdego z elementów SIPOC (o którym pisałem już wielekrotnie) można przyporządkować określone obiekty z podanego procesu.

Dzisiaj wrócę również do tematu procesu zamówienia. Jednakże niestety muszę przytoczyć przykład rzeczywistego procesu, w którym to fakt, byłem informowany o każdym etapie realizacji, ale niestety komunikaty nie odzwierciedlały rzeczywistości, patrząc z mojej perspektywy. Na początku wszystko wyglądało identycznie: złożyłem zamówienie, czyli wybrałem produkt, podałem parametry zamówienia, zapłaciłem, a produkt został wysłany, o czym poinformował mnie pierwszy komunikat. I tu się podobieństwa kończą. Następny komunikat stwierdzał: uzgodniono termin przesunięcia dostawy. Nie było ani kontaktu mailowego ani telefonicznego od firmy kurierskiej. Ok, machnąłem ręką, nowy termin był w ostateczności akceptowalny, jak nie dojdzie produkt będę się martwił.

nieudanyprocess450px

Kolejny komunikat poinformował: brak kontaktu z odbiorcą, produkt zwrócony. I w tym momencie już nie było ciekawie. Ani nie wiedzieliśmy, że kurier jednak nie przyjedzie, ani nie podał wcześniej szacowanej godziny dostawy, a na koniec pomimo aktywnego telefonu i przebywania w strefie objętej zasięgiem – kontaktu nie było. Skończyło się reklamacją skierowaną do firmy kurierskiej. Wielokrotnie zamawialiśmy produkty u tego dostawcy i z wykorzystaniem kuriera – nigdy nie było problemów.

Potem okazało się, że produkt wrócił do firmy, u której zamawiałem produkt, a po kilku dniach nastąpił zwrot środków na konto.  Choć niestety nie mam zamówionego produktu, czy element oczekiwanego “wyjścia” (ang. output) w ramach modelu SIPOC nie został zrealizowany zgodnie z oczekiwaniami. Zostałem z “wejściem” (ang. input) – swoją potrzebą oraz środkami na koncie. Dostawca produktu (ang. Supplier) oraz Odbiorca produktu/Klient (ang. Client) uczestniczyli w tym procesie, ale nie można powiedziec, że są zadowoleni – z jednego strony produkt nie został sprzedany, a z drugiej dostarczony. Sam proces  (ang. process)“podobno” – podkreślam to słowo – został zrealizowany, choć mam wątpliwości, czy z tak funkcjonującym kurierem wszystkie kroki rzeczywiście zostały zrealizowane.

Powyższy diagram obrazuje taką zmianę sytuacji, z oznaczeniem, że nastąpiła kolejna zmiana strony obsługującej oraz w procesie nie ma statusu „produkt dostarczony”.

Statusy cząstkowe czy o kluczowych etapach?

Ostatnio zamawiając wybrany produkt przez internet, proces zaówienia wyglądał jak zwykle, czyli wybór produktu, określenie parametrów dostawy oraz płatności, a na koniec płatność za pomocą wybranej usługi. Po chwili na skrzynce znalazłem informację z potwierdzeniem zamówienia. Wybrałem dostawę za pomocą firmy kurierskiej, więc wystarczyło czekać na dostawę w szacowanym terminie –  kilka dni.

Następnego dnia dostaję maila od firmy kurierskiej z informacją: “czekamy na przygotowanie przesyłki”. Po kilku godzinach – “odebraliśmy przesyłkę, powiadomimy o czasie dostawy kolejnym mailem”. Następnego dnia – “planowane dostarczenie w podanej lokalizacji i przedziale czasowym”. Otrzymałem także informację o tym, że mogę zmienić szczegóły dostawy – lokalizację i przedział czasowy. Na koniec, gdy kurier dostarczył mi przesyłkę i potwierdziłem podpisem odbiór, dostałem maila, że “przesyłka dostarczona”. Poszczególne statusy oraz powiązane kroki procesu zostały przedstawione na poniższym diagramie.

statusyczastkowe450px

Można powiedzieć, że zamiast „zwykłych” statusów o etapach (złożone, wysłane, w trakcie oraz dostarczone) z procesu przekazywane były Klientowi statusy cząstkowe. Te cząstkowe statusy były okazją dla firmy do udostępnienia dodatkowej możliwości elektronicznej zmiany szczegółów dostawy. Podobnie można było dokładnie zauważyć moment zmiany podmiotu odpowiedzialnego za realiazcję procesu – między przygotowaną przesyłką (strona zamawiającego na diagramie) a odebraną przesyłką (strona dostarczającego na diagramie). W takich procesach często na koniec występuje ankieta, pozwalająca na ocenę procesu.

Szczerze mówiąc zacząłem się zastanawiać, z jaką szczegółowością chciałbym być informowany o przebiegu realizacji procesu – mógłbym otrzymać numer przesyłki smsem, z możliwością jej śledzenia. Mając na uwadze, że czas realizacji był 1-2 dni, tak częste statusy wydawały się nadmiarowe, ponieważ gdybym sprawdził pocztę dopiero po kilku dniach zobaczyłbym 3-5 wiadomości dotyczącej przesyłki. Jeżeli okres realizacji byłby dłuższy, np. od momentu złożenia zamówienia do przygotowania przesyłki był okres kilku dni lub tygodni, to pewnie oceniłbym to inaczej. Korzyścią z rozwiązania było to, że dokładnie wiedziałem, gdzie jest przesyłka i mogłem się przygotować na jej odbiór od kuriera.

Proces określania korzystnych wyników

Wielu kibiców polskiej ligi zastanawia się kto zostanie mistrzem. Jedni ze 100% pewnością mówią, że to drużyna, której kibicują. Inny patrzą z niedowierzaniem na tabelę, na 2 kolejki przed końcem. Bo prawda jest taka, że 4 drużyny – oznaczmy je jako LP, LG, LW, JB – walczą o mistrzostwo oraz miejsce w pucharach. Jedna z drużyn pozostanie z niczym. Kolejna drużyna w kolejności ma taką stratę, że nie trzeba jej brać pod uwagę. Wskazane drużyny są obecnie ułożone w kolejności:  LW, JB, LB, LG z dorobkiem punktowym odpowiednio: 40, 38, 38, 38. Jest to punkt wyjściowy do próby określenia szans wybranej drużyny na zwycięstwo. Kroki są opisane na poniższym diagramie.

wyniki428px

Po określeniu punktu startowego, trzeba wygenerować wszystkie możliwe układy wyników w 2 kolejkach, z uwzględnieniem tego, że w pierwszej kolejce każda z drużyn walczy z drużyną spoza pierwszej czwórki, a w drugiej kolejce, walczą między sobą. Opieramy się tutaj tylko na wszystkich możliwych wynikach. Można to wygenerować następująco:

lp = 38
lw = 40
lg = 38
jb = 38
Określenie puntku startowego, poprzez określenie liczby punktów dla każdej z drużyn, przed kolejką.
for lp1 in [3,1,0]:
for lw1 in [3,1,0]:
for lg1 in [3,1,0]:
for jb1 in [3,1,0]: (…)
Generowanie wszystkich możliwych rozstrzygnięć dla pierwszej kolejki, wybierając odpowiedni wynik dla każdej z drużyn.
for lp2 in [3,1,0]:
for lw2 in [3,1,0]:
jb2 = wynikiodwr[lp2]
lg2 = wynikiodwr[lw2]
Generowanie dla każdego zestawu wyników z pierwszej kolejki, wszystkich możliwych rozstrzygnięć dla drugiej kolejki, wybierając odpowiedni wynik dla każdej z drużyn, z uwzględnieniem tego, że JB gra z LP oraz LG gra z LW.
(lp1,lw1,lg1,jb1,
lp2,lw2,lg2,jb2,
lpk = lp+lp1+lp2,
lwk =lw+lw1+lw2,
lgk =lg+lg1+lg2,
jbk = jb+jb1+jb2)
Zebranie możliwe zestawu wyników dla 1 I 2 kolejki wraz z osiągniętą liczbą punktów na koniec. Taki rekord jest dodawany do określonej struktury danych – określmy ją jako Wyniki.

Tym sposobem mamy 729 różnych rozstrzygnięć.

Teraz na bazie utworzonej struktury danych Wyniki możemy sprawdzić jakie rozstrzygnięcia powodują mistrzostwo określonej drużyny. Założmy, ze interesuje nas drużyna LP to wtedy możemy wyszukać wygenerowane pozycje, które spełniają na przykład warunek:

(Wyniki.lpk > Wyniki.lwk) & (Wyniki.lpk >= Wyniki.lgk) & (Wyniki.lpk > Wyniki.jbk)

Dla tego warunku mamy 91 rozstrzygnięć, co stanowi około 12,5% biorąc pod uwagę wszystkie wyniki bez uwzględnienia dotychczasowych rozstrzygnięć między drużynami grającymi w danej kolejce, statystyk, problemów drużyn, zmęczenia, kartek itp. Powyższy warunek nie uwzględnia tez innych relacji z ta samą liczbą punktów, które mogą powodować mistrzostwo określonej drużyny.

Powyższy przykład pokazuje, że pod określonymi krokami w procesie, kryją się określone działania w systemie lub wykonywane przez użytkownika. Wraz z diagramem mógłby być opis, który mniej lub bardziej technicznie pokazuje, na czym polega dany krok. Takie elementy jak powyżej można byłoby potraktować jako warstwę implementacyjną procesu.

Już w niedzielę okaże się, które z wygenerowanych wierszy można pominąć, skupiając się tylko na wynikach drugiej kolejki.

Gdy chcesz wysłać paczkę

Dzwoni domofon. Pytasz kto to? Pada krótka odpowiedź: kurier. Nie przypominasz sobie czy na coś czekasz, więc wpuszczasz i weryfikujesz co to za przesyłka. Sprawdzasz i przyjmujesz paczkę lub nie. Gdy znasz nadawcę jest łatwiej i dane odbiorcy w pełni się zgadzają – przyjmujesz paczkę. W innych sytuacjach – kwestia pozostaje do wyjaśnienia. Te wyjaśnienia ułatwia dołączony do paczki list przewozowy/nalepka adresowa. Oprócz nadawcy i odbiorcy przesyłki zawiera informacje o jej wymiarach, wadze, nazwie firmy oraz dodatkowe informacje. Są one efektem procesu zlecenia wysyłki paczki. Tzw. wyjścia poszczególnych kroków.

paczka350px

Diagram przedstawia standardowy proces w takim przypadku. Przeglądając różne strony internetowe firm kurierskich można zauważyć, że na samym początku następuje pytanie o wagę i wymiary paczki, następnie miejsce dostarczenia. Paramatry te pozwalają określić cenę paczki. Jeżeli nadawca akceptuje te koszty, może podać szczegółowe dane nadawcy i odbiorcy. Czasami najpierw następuje rejestracja nadawcy, a potem reszta procesu. Bez podawania jakichkolwiek danych można wycenić paczkę i określić czy jest standardowa, czy może wymaga innych działań. Na odpowiednim etapie konieczne jest także opłacenie wysyłki.

W sytuacji, gdy zależy nam na ubezpieczeniu lub gwarancji dostarczenia paczki do określonej godziny jesteśmy zobowiązani do poniesienia wyższej opłaty, wykonania dodatkowych kroków lub zlecenia wysyłki paczki w określonych godzinach i miejscu. Elementów tych nie uwzględniłem na diagramie.

Wartość dodana w takim procesie może być tworzona przez dodatkowe udogodnienia, w tym poprzez możliwość śledzenia położenia paczki – jej wysyłki, transportu, dostarczenia, dzięki poznaniu z góry określonym identyfikatorom dla paczki.

Kiedy dostaniesz powiadomienie?

Ostatnio otrzymałem wiadomość mailową o treści: “Przypomnienie o końcu ważności biletu okresowego”. Rzeczywiście za 2 dni kończył mi się okres ważności wykupionego biletu okresowego. Pamiętałem o tym, więc kilka dni wcześniej już go przedłużyłem. Dlatego byłem trochę zdziwiony, że tego maila otrzymałem.

Zacząłem się zastanawiać, że mogli wygenerować bazę z kończącymi się biletami wcześniej i dopiero tego dnia wygenerować powiadomienia. Inne rozwiązanie to takie, że mechanizm chodzi codziennie i sprawdza dla aktywnych biletów jaka jest data końca. W systemie każde przedłużenie może jest widoczne jako osobny rekord, a nie zmienia bieżącego i to powoduje problem. Wydaje się, że mechanizm nie sprawdza, czy jest już kolejny rekord lub nie pobiera najstarszej daty końca spośród rekordów. Może utrudnieniem dla mechanizmu jest to, że ze względu na długi weekend, przesunąłem datę początku obowiązywania nowego biletu o kilka (X) dni (na co pozwala system). Wydaje się, że algorytm wyboru biletu do wysłania powiadomienia mógłby wyglądać jak poniżej.

bilet_okresowy400px

Powyższy diagram jest kolejnym przykładem drzewa decyzyjnego, które przedstawiam na swoim blogu. Jest to istotny element procesu biznesowego. Wiele procesów opiera się na krokach, w których taki mechanizm ma zastosowanie i od niego zależy dalszy przebieg procesu. Wykonywane działanie opiera się na danych zebranych podczas procesu. Na powyższym diagramie taki przykładowy proces również został uwzględniony. Za pomocą drzewa decyzyjnego można szybko określić jakie działanie powinno zostać podjęte w ramach kroku

A może ta wysyłka powiadomienia, gdy jest odstęp między kolejnymi okresami ważności biletu, jest zabiegiem świadomym, aby użytkownik jednak pamiętał o tym, że pierwotny bilet kończy się danego dnia? Takie działanie dodałem do drzewka decyzyjnego linią przerywaną jako alternatywne rozwiązanie dla tego diagramu. To, w jaki sposób interpretujemy dane i układamy drzewko decyzjne jest kwestią decyzji biznesowej. Jeżeli zależy nam mimo wszystko, aby powiadomić użytkownika w każdej sytuacji, będziemy patrzeć tylko na parametry bieżącego biletu. Jeżeli natomiast, nie chcemy wysyłać powiadomień, które użytkownicy odbiorą jako błędne, trzeba zastosować bardziej dokładne reguły.