h1

Gdy koncert został odwołany

Grudzień 9, 2018

Pod koniec listopada w Poznaniu miał się odbyć koncert jednej ze znanych grup muzycznych. Koncert miał się odbyć w dość starej sali widowiskowo-sportowej, ale niestety, dla zainteresowanych, nie odbył się. Nie miałem biletów na ten koncert, ale akurat trafiałem w lokalnym serwisie na kolejne informacje na ten temat. Na kilka godzin przed koncertem zmieniono jego lokalizację (na inną część miasta), a bliżej godziny koncertu, zupełnie go odwołano. Zastanawiałem się jak na to zareagowali uczestnicy koncertu:

  • Ci, co dotarli pod pierwsze miejsce koncertu;
  • Ci, co dotarli pod drugie miejsce koncertu, bo się o zmianie dowiedzieli lub zostali odesłani z pierwotnego miejsca koncertu (ciekawe, czy ktoś tam osobiście informował osoby);
  • Ci co nie dotarli wcale, bo mieszkają w okolicy i nawet nie wyszli z domu;
    Jak można byłoby usprawnić proces komunikacji dot. zmiany lokalizacji lub odwołania koncertu?

Myślę, że cały proces mógłby zostać usprawniony (nie wiem czy taka możliwość istniała), gdyby każdy z kupujących bilet musiał to zrobić w tym samym miejscu lub też miałby możliwość podania numeru telefonu, który mógłby zostać wykorzystany tylko w opisanej wyżej sytuacji. Uczestnik miałby możliwość zapisania się (ang. subscribe) na konkretną informację na przykład z zastrzeżeniem, że potem jego numer telefonu jest usuwany. Równocześnie organizator zadeklarowałby, że będzie udostępniał tylko określoną informację (ang. publish), która przez dostępny system (na diagramie środkowa ramka System) zostanie przekazana na numery telefonów. Organizator nie znałby numerów telefonów, a tylko tematy, które przekazuje do pośrednika.

publish_subscribe_1_450px

Opisany model interakcji, stosowany w architekturze oprogramowania, określany jest jako wzorzec publish-subscribe, czyli model składający się z części odpowiedzialnej za udostępnianie informacji przez jego dostawcę (część publish jest opisana na górnej części diagramu, opisanej jako Dostawca informacji) oraz części umożliwiającej wskazanie zainteresowania odpowiednimi tematami przez odbiorców informacji (dolna część diagramu opisana przez Odbiorca informacji). Odbiorcy otrzymują tylko informacje, których oczekują, natomiast nadawca informacji może wystawiać różne komunikaty, bez wiedzy do kogo i czy one trafią.

Wyobraźmy sobie, jak na powyższym diagramie, że uczestnicy koncertu (czyli odbiorcy), kupując bilet zaznaczają: chcę otrzymać informację o zmianie terminu koncertu i jego odwołaniu (wybór tematu na diagramie), a nie chce otrzymywać informacji o usprawnieniach dot. dojazdu czy atrakcji powiązanych. Organizator koncertu równocześnie planuje wystawiać informacje o potencjalnej zmianie terminu, odwołaniu, dojazdach, atrakcjach towarzyszących, innych koncertach itd. Uczestnik otrzyma to, co potrzebuje a Dostawca daje to, co chce (czyli przygotowanie komunikatu w określonym temacie).

Nie wiem na ile takie rozwiązania w komunikacji z uczestnikami miały w opisanej sytuacji miejsce, ale pewnie ułatwiłyby „życie” uczestnikom koncertu w momencie jego odwołania, a nie tylko przeniesienia w inne miejsce.

Reklamy
h1

Nadmiarowe statusy?

Listopad 22, 2018

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.

h1

Gdy dane w systemie są nieaktualne

Listopad 12, 2018

W ostatnich 3 miesiącach, kiedy inne zobowiązania nie pozwoliły mi na publikację wpisów na blogu, korzystałem ze sklepów internetowych. Było to podyktowane brakiem czasu na poszukiwania tych produktów w sklepach stacjonarnych lub po krótkiej weryfikacji okazywało się, że cena on-line jest zdecydowanie niższa. Co ciekawe w trzech przypadkach, które zdarzyły się w krótkich odstępach czasu, przytrafiły mi się nietypowe zdarzenia. Miałem taką sytuację po raz pierwszy.

W tych trzech przypadkach zamówiłem przez internet trzy różne produkty, z różnych sklepów. W pierwszym wypadku były to cebulki kwiatów (oznaczmy ją jako 1), w drugim mata gimnastyczna (oznaczmy ją jako 2) a w trzecim książka na prezent (oznaczmy ją jako 3). W dwóch przypadkach zakup nie zakończył się otrzymaniem produktu – przypadki (1) i (3), a w jednym przypadku ostatecznie produkt dotarł – przypadek (2). Co się wydarzyło?

  • Przypadek (1) – na drugi dzień po złożeniu zamówienia, otrzymałem informację, że produkt nie jest jednak dostępny fizycznie, jest w systemie, ale nie ma go w sklepie/magazynie. Wręcz usłyszałem, że ktoś go ukradł i dopiero przy remanencie na koniec roku zidentyfikują co się stało. Poprosiłem o zwrot kasy.
  • Przypadek (2) – po około tygodniu od zamówienia, otrzymałem informację mailową, że produkt jednak nie dotarł do nich z magazynu, mimo, że wskazują kilka dni roboczych na realizację zamówienia. Po wskazaniu, że jednak nie chcę rezygnować z zakupu i odpowiednich słowach „mobilizujących” okazało się, że produkt się jednak znalazł i został wysłany.
  • Przypadek (3) – po kilku dniach okazało się, że otrzymali z magazynu zupełnie inny produkt i próbowali mnie przekonać do zmiany zamówienia (proponując cenę wyższą niż cena rynkowa), a ten pierwotny nie jest w cale dostępny, pomimo, że na stronie informują o dostępności (wg informacji z magazynu). Zrezygnowałem z produktu i otrzymałem bon rabatowy na kolejne zakupy.

system_zaufanie_1_450px

Cechą wspólną tych przypadków jest silne uzależnienie od danych, które ktoś wprowadził do systemu (warstwa bazodanowa na diagramie). Może ich nie zaktualizował, nie zweryfikował lub jest to – miejmy nadzieję, że nie – działanie świadome, aby ściągnąć potencjalnego Klienta. Może Klient jak już złożył zamówienie, to weźmie coś innego, otrzyma zamiennie bon do wykorzystania w danym sklepie lub poczeka dłużej na zamówienie. Gdy Klient będzie nerwowy lub zdeterminowany, może zamieścić stosowne wpisy w mediach społecznościowych lub serwisach zbierających opinie klientów. Użytkownik kompletujący zamówienie, także sprawdza w systemie (warstwa użytkownika na diagramie), czy dany produkt jest dostępny (dane z warstwy bazodanowej), w którym miejscu magazynu i ile tak naprawdę sztuk pozostało.

Swoją drogą, chyba będąc dostawcą, nie pisałbym do potencjalnego Klienta, że coś nie dotarło z magazynu, a po chwili, że udaje się to odnaleźć. Podobnie mówienie o tym, że ktoś ukradł produkt też jest marketingowo słabe. Myślę, że można było zaproponować inną odpowiedź.

Użytkownicy systemu (warstwa użytkownika na diagramie) muszą mieć jakieś zaufanie do danych w systemie. Równocześnie zarówno oni, jak i Klienci (na diagramie Klient też jest użytkownikiem, ale np. strony www obsługującej sklep), na czymś muszą oprzeć swoje decyzje o sprzedaży czy zakupie – dostępności produktu, miejscu dostępności, liczbie sztuk, czasie dostawy itp. Użytkownicy mogą korzystać z informacji o produktach znajdujących się u pośrednika/sklepie (baza wewnętrzna na diagramie) lub u docelowego/źródłowego dostawcy (baza zewnętrzna, połączeniem tych elementów jest warstwa obsługująca na diagramie).

h1

Proces nieskończony

Sierpień 11, 2018

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

h1

Zrób to sam – wydruk faktury

Sierpień 4, 2018

Ostatnio robiłem zakupy w markecie budowlanym, wybrałem rzeczy a potem za nie zapłaciłem. Wychodząc ze sklepu moją uwagę zwróciła nowa rzecz w przejściu (wcześniej jej nie zauważyłem) – było to urządzenie wielkości biletomatu lub innego urządzenia tego typu. Zerknąłem na nazwę i zobaczyłem tylko słowo „fakturomat”. Poszedłem dalej, ale się zacząłem zastanawiać jak to działa. Już wcześniej zauważyłem, że na paragonie jest kod kreskowy, jednakże nie zdziwiło mnie to, ponieważ był już wcześniej i był wykorzystywany przy jakiejś loterii.

Klient w celu wygenerowania faktury mógłby zeskanować kod, wpisać dane oraz wydrukować ją. Zakładam, że z kodem kreskowym są związane szczegóły zakupionych produktów – nazwa, kod, % VAT, producent, cena, ilość i inne informacje niezbędne do umieszczenia na fakturze.

fakturomat_450px

Kluczem do realizacji procesu byłby paragon, który łączy w sobie w sumie dwa procesy: proces zakupowy oraz proces przygotowania faktury. W wielu sklepach, chcąc otrzymać fakturę wstrzymujemy kolejkę lub musimy pójść do punktu informacji i tam pozyskać fakturę. Bez zastosowania fakturomatu, angażowany jest pracownik i ewentualny literówki na fakturze muszą zostać poprawione po przekazaniu uwag przez Klienta. W fakturomacie, to klient kontroluje poprawność danych podczas ich wprowadzania i potwierdza ich poprawność (tak zakładam). Myślę, że jest to przydatne narzędzie, choć w sieci można znaleźć ostrzeżenia i wskazówki odnośnie wykorzystania tego narzędzia (warto się z nimi zapoznać).

Powyższy komentarz jest jedynie moim przypuszczeniem, ponieważ nie korzystałem z tego narzędzia. Trudno mi powiedzieć, czy proces jest całkowicie samodzielny, czy może jednak na koniec potrzebna jest jakaś interakcja z obsługą. Nie wiem także, czy paragon jest wykorzystywany i w jaki sposób są uzupełniane dane. Może być też tak, że trzeba zgłosić tę potrzebę w momencie płacenia za produkty.

h1

Automatyczne reguły oparte o wzorce

Lipiec 11, 2018

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
h1

Akcja i podanie

Lipiec 3, 2018

Jesteśmy w trakcie tego okresu czasu, gdy jedni płaczą, drudzy się cieszą, jedni grają ofensywnie, a inni defensywnie. Tamci preferują grę z kontry, a inni grę atakiem pozycyjnym. Strzały, celne, niecelne, bramki, spalone, kartki, podania, przebiegnięte kilometry, przejęcia, posiadanie piłki itd. Te i inne określenia oraz sytuacje charakteryzuję odbywające się mistrzostwa świata w piłce nożnej. Najciekawsze jest to, że nawet Ci, którzy nie kibicują, siadają przed telewizorem, telebimem lub przy radiu i w wielkim skupieniu śledzą to, co się dzieje na boiskach piłkarskich. A co się dzieje? Wyprowadzenie piłki, rozegranie akcji i strzał. Jest to pewne uproszczenie, ponieważ rozegranie akcji może następować ze środka pola, po przejęciu piłki, od rzutu wolnego lub rzutu z autu.

rozegranie_v2_450px

Kluczem wyprowadzania piłki i rozegrania akcji są podania. Wyobraźmy sobie, że mamy informację o liczbie podań wychodzących z danej formacji i przychodzących do niej, a także w ramach formacji. Przez formację rozumiem tutaj bramkarza, obrońców, pomocników oraz napastników.
formacje_450px

Na tej podstawie można byłoby powiedzieć: „w którym kierunku grała drużyna” lub „w jakim miejscu była najbardziej intensywna gra drużyny”. Nie wiem czy takie analizy są wykonywane, ale słuchają komentatorów i oglądając statystyki można odnieść wrażenie, że takie analizy można byłoby wykonywać. Jeżeli mamy zliczoną liczbę podań i wskazanie liczby celnych, to wiemy, czy dane podanie dotarło i w sumie do jakiej formacji.

Na diagramie dodałem informację także o niecelnych podaniach oraz strzałach. Można byłoby dodać także informację o przejęciach piłki, skuteczności podań oraz czasie, którego dotyczy diagram. Te przykładowe liczby można byłoby zinterpretować, że drużyna grała najwięcej w środku pola (od obrony do pomocników), a mniej angażowała  napastników oraz oddała tylko pojedyncze strzały na bramkę przeciwników.