Archive for the ‘Procesy’ Category

h1

Zakupy wg elektronicznej listy

Październik 12, 2019

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.

Reklamy
h1

Poziom akceptacji

Wrzesień 30, 2019

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.

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.

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