Archive for the ‘Ogólne’ Category

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.

Reklamy
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

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

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

RODO a procesy

Czerwiec 21, 2018

Przez ostatni miesiąc pewnie wielu użytkowników poczty elektronicznej otrzymało po kilka, kilkanaście, a może kilkadziesiąt wiadomości, które zaczynały się od słów lub były zatytułowany w stylu: „zmiana regulaminu”, „to kolejna wiadomość”, „ważna zmiana”, „Od 25 maja…”, „Ochrona danych osobowych” i wiele innych. Częścią wspólną tych wiadomości, pochodzących z różnych sklepów internetowych, serwisów, stron internetowych, było odniesienie do RODO. Takie cztery litery pojawiały się w tytule lub samej treści.

RODO to unijne rozporządzenie dotyczące ochrony danych osobowych, w zakresie ich przetwarzania oraz przepływu. Rozporządzenie weszło w życie 25 maja 2018 i jak najbardziej dotyczy procesów, zarówno biznesowych, jak i tych technicznych związanych z przetwarzaniem danych.

Wyobraźmy sobie, że mamy proces biznesowy, który zbiera dane osobowe a który można uogólnić do trzech poniższych kroków: Zebranie danych, Zapisanie danych, Wykorzystanie danych.

process_rodo_1_450px

W każdym z tych kroków w jakiś sposób RODO dotyka takiego procesu:

  • zebranie danych – osoba, której dane dotyczą musi otrzymać informację o tym dlaczego zbierane są dane i jakie z tego tytułu posiada ona uprawnienia – takie zapisy  już funkcjonują w wielu formularzach czy regulaminach obecnie, choć w wyniku wejścia Rozporządzenia  mogły już zostać uszczegółowione/zmienione, co wynikało z ich aktualnego brzmienia oraz z powiązań z innymi dokumentami (np. Regulaminem);
  • zapisanie danych – w tym wypadku z perspektywy RODO jest istotna świadomość tego jakie dane zbieramy, gdzie je składujemy, kto jest administratorem oraz kto może z nich skorzystać. RODO wprowadza lub wskazuje jeszcze wiele zasad (które wyjaśnia ustawa, rozporządzenie, publikacje czy też regulaminy stosowane przed podmioty);
  • wykorzystanie danych – RODO zwraca uwagę na to, aby ich wykorzystanie było uzasadnione (nie będę wchodzić w szczegóły co to znaczy) oraz zgodne z tym, co zakomunikowaliśmy osobie, które dane dotyczą (zainteresowanych co to znaczy odsyłam do właściwych publikacji dotyczących RODO).