Pytania o … SIPOC

W książce Lean Banking” (F. Majorana, A. Morelli) można znaleźć poniższy diagram, który wskazuje „przykład kolejnych czynności , jakie muszą zostać wykonane, aby sporządzić poprawnie SIPOC”. Diagram na potrzeby wpisu został przetłumaczony oraz lekko zmodyfikowany (co widać na diagramie).

Spróbujmy odpowiedzieć na postawione pytania na bazie procesu realizacji zamówienia przy użyciu sklepu internetowego, którego przykład wykorzystuję często na blogu. Jest to proces „łatwo” dostępny dla większości użytkowników sieci Internet. Taki użytkownik ma możliwość poznania całego przebiegu procesu od jego zainicjowania aż do samego końca (otrzymania zamówionego produktu). W sytuacjach problemowych (np. brak zamówionego produktu lub inny problem), to właśnie do niego jest kierowana odpowiednia informacja z prośbą o podjęcie decyzji co dalej z procesem. Użytkownik wybierając konkretny produkt orientuje się przeważnie kto jest jego dostawcą, jaka jest jego cena na rynku oraz parametry.

sipoc_pytania_full

Odpowiedzi na pytania mogą być następujące (punkty odpowiadają numerom pytań na diagramie a odpowiedzi są poglądowe):

  1. Jest to proces realizacji zamówienia ze sklepu internetowego z dostarczeniem produktu w sposób wskazany przez Klienta. Klient płaci z zamówiony produkt w wybrany sposób (wybierając z opcji dopuszczonych przez sklep, po spełnieniu określonych warunków).
  2. Pytania odnoszą się do granic procesu. Określenie tego, gdzie zaczyna i kończy dany proces jest istotne z różnych względów. W przypadku procesu zamówienia można przyjąć, że złożenie zamówienia jest początkiem procesu a dostarczenie produktu jest jego końcem. W zależności od tego, czy Klient jest nowy lub istniejący, w trakcie tego procesu następuje rejestracja lub nie nowego użytkownika sklepu internetowego. Jednakże to, że Klient się zarejestruje nie oznacza, że złoży zamówienie – może je np. zapisać na przyszłość. Zarejestrowani użytkownicy mogą przeważnie skorzystać z większej liczby opcji oraz udogodnień jakie daje dany sklep.
  3. Output’em procesu jest:
    a. produkt dostarczony do Klienta za pomocą ustalonego sposobu dostawy oraz
    b. zaksięgowana płatność za produkt na koncie sklepu
  4. Beneficjentem output’ów są:
    3a. Klient;
    3b. Działa finansowy sklepu internetowego oraz dostawcy produktów;
  5. Od output’u:
    3a. Klient oczekuje, że produkt jest zgodny w parametrach z zamówionym produktem, że nie jest uszkodzony; jest kompletny;
    3b. Firma oczekuje, że dokonana płatność przez Klienta dotarła we właściwej wysokości na konto sklepu;
  6. Aby proces miał szansę zaistnieć to:
    a. Produkt musi być w magazynie sklepu;
    b. Dostawca produktu dysponuje możliwościami uzupełnienia produktu na zamówienie;
    c. Sklep internetowy musi być dostępny dla użytkowników (strona musi działać a serwery były w stanie obsłużyć ruch);
    d. Sklep musi obsługiwać różne formy płatności;
    e. Sklep musi mieć ustalone mechanizmy dostawy produktów;
    f. Pośrednicy uczestniczący w procesie są gotowi na przewóz produktów;
    g. Powinien istnieć określony regulamin sklepu określający prawa i obowiązki poszczególnych stron transakcji (Klienta oraz sklepu jako całości);
    h. Ceny produktów są adekwatne do produktów;
    i. Klient musi wybrać produkt, określić parametry zamówienia oraz je potwierdzić.
    Warunki zaistnienia procesu są wynikową możliwości technicznych, posiadanych zasobów oraz planowanych do osiągnięcia efektów. Input’y w ramach procesu są łączone i pozwalają na osiągnięcie output’ów – na poszczególnych krokach procesu są jego wejściami przekształcanymi w wyjścia.
  7. Dostawcą input’ów są: dział zamówień sklepu (6a), producent produktów (6b), dział techniczny wraz z wsparciem firmy hostingowej (6c-6d), dział dystrybucji (6e-6f), sklep jako całość (6g-6h) oraz Klient (6i);
  8. Input’y wskazane powyżej powinny się charakteryzować tym, że:
    a. Są dostępne w momencie czasu, w którym Klient decyduje się na złożenie zamówienia;
    b. Produkty dostępne w sklepie w zakresie parametrów są zgodne z rzeczywistością;
    c. Formy płatności oferowane przez sklep funkcjonują poprawnie i bez zakłóceń;
    d. Firmy pośredniczące działają w ramach zgodnych z regulaminem sklepu;
    Sposób ich wykorzystania oraz efekty są zgodne z regulaminem sklepu;

Powyższe odpowiedzi składają się na uogólniony przykład. Przykładając je do konkretnego procesu uległyby większym lub mniejszym zmianom. Wskazując konkretne produkty (ich rodzaj, charakter) można byłoby dodać dodatkowe wymagania/charakterystyki lub wymagania przy których proces może zaistnieć.

Obowiązek dla właściciela procesu?

„…może być wykorzystana w celu stworzenia dokumentacji, której celem będzie wykazanie zgodności realizowanych procesów przetwarzania z wymaganiami RODO. Obowiązek wykazania przestrzegania stosowania przepisów RODO wynikający z art. 24 RODO nie określa bowiem w jaki sposób, poprzez jakie dokumenty, czy inne instrumenty zarządzania powinien być zrealizowany. Przepis art. 24 RODO stanowi jedynie, że administrator ma wykazać, że wdraża odpowiednie środki techniczne i organizacyjne, aby przetwarzanie odbywało się zgodnie z RODO.” oraz „...podejmowanie działań zapewniających, że osoby zaangażowane w proces przetwarzania informacji posiadają stosowne uprawnienia i uczestniczą w tym procesie w stopniu adekwatnym do realizowanych przez nie zadań oraz obowiązków mających na celu zapewnienie bezpieczeństwa informacji…” – są to dwa fragmenty artykułu ze strony Urzędu Ochrony Danych Osobowych mówiące o dokumentacji przetwarzania danych osobowych zgodnie z RODO.

Czytając ten artykuł zacząłem się zastanawiać czy przypadkiem z powodu obowiązywania rozporządzenia RODO nie pojawiają się dodatkowe obowiązki dla właściciela procesu. Samo sformułowanie właściciela procesu nie pojawia się w ustawie (o ile dobrze zweryfikowałem). Występują sformułowania odnoszące się do administratora danych, do jednostki przetwarzającej dane oraz rejestru czynności przetwarzania.

Temat wpływu RODO na procesy biznesowe już opisywałem w innym wpisie, niedługo po wejściu ustawy w życie, a był to okres kiedy podmioty funkcjonujące na rynku wysyłały do swoich klientów stosowne klauzule informacyjne. Wskazałem tam takie aspekty jak zebranie danych, zapisanie danych oraz wykorzystanie danych (co zasygnalizowałem również na poniższym diagramie). Są to elementy procesów, np. zamawiania w internecie lub innych, których kształt oraz rozwój określa właściciel procesu wraz z interesowanymi stronami. Przypomnę, że jednym z punktów było odpowiada za zgodność procesu z oczekiwaniami biznesowymi, co wydaje się oczywiste.

rodo2_450px

Działanie różnych procesów biznesowych, opartych o dane Klientów w nich uczestniczących, jest uzależnione także od innych aspektów – takich jak bezpieczeństwo procesu (w sklepie, z którego korzystam, regulamin to precyzuje), ryzyko procesu czy zgodność procesu z regulacjami obowiązującymi dany podmiot (regulamin sklepu, z którego skorzystam, ma takie zapisy, precyzujące z jakimi ustawami jest zgodny). W zależności od ustaleń i zasad stosowanych w danym podmiocie, można powiedzieć, że na jednostce rozwijającej, utrzymującej lub opiekującej się procesem, leży obowiązek spełnienia tych wymogów. Można uogólnić, że to właściciel procesu powinien odpowiadać za zgodność procesu z wymogami regulacyjnymi, w tym z RODO.  Wskazanie właściciela procesu wydaje się tutaj uzasadnione.

Dlaczego? To właściciel procesu ma (powinien mieć?) najlepszą wiedzę o tym jakie są kroki procesu oraz jakie elementy w procesie są pozyskiwane od Klienta (zasygnalizowane na diagramie). W momencie konieczności zebrania dodatkowych poświadczeń lub danych od Klienta, to właściciel procesu inicjuje samodzielnie lub wspólnie z zainteresowanymi jednostkami odpowiednią zmianę techniczną, zmierzającą do osiągnięcia postawionego celu.

Wracając do cytatu, to właściciel procesu  moim zdaniem wspiera administratora danych w określeniu odpowiednich zapisów w rejestrze czynności przetwarzania oraz wyjaśnia elementy składające się na taką pozycję jak na przykład (co próbowałem także zasygnalizować na diagramie):

  • „…
  • cele przetwarzania;
  • opis kategorii osób, których dane dotyczą, oraz kategorii danych osobowych;
  • kategorie odbiorców, którym dane osobowe zostały lub zostaną ujawnione…;
  • …”

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.

 

Ankieta oceny realizacji zamówienia

Dzisiejszy tytuł wpisu nie jest przypadkowy. Jest to dokładnie tytuł wiadomości e-mail jaką otrzymałem od sklepu internetowego następnego dnia po odebraniu zamówienia w wybranym punkcie. Czasami uruchamiam te ankiety a czasami usuwam takie wiadomości. Tym razem postanowiłem, że przyjrzę się bliżej takiej ankiecie.

Proces realizacji zamówienia rozpoczął się „tradycyjnie” w serwisie internetowym – po przejrzeniu oferty, wybrałem produkty, które chciałem zamówić. Następnie określiłem sposób dostawcy i wskazałem punkt odbioru. Po otrzymaniu wiadomości SMS udałem się po odbiór zamówienia. Proces ten jest przedstawiony na poniższym diagramie. Na diagramie znalazł się również krok: Oceń proces, ponieważ przeważnie występuje on w procesie realizacji zamówienia inicjowanego w sklepie internetowym.

ocena_procesu450px

Wykonując krok Oceń proces musiałem skorzystać z ankiety wskazanej poprzez link w otrzymanej wiadomości. Link kierował do dedykowanego serwisu. W ankiecie były pytania wskazane poniżej. Dla potrzeby wpisu trochę je uogólniłem, aby nie wskazywały wprost jaki sklep internetowy dokładnie wysyła taką ankietę. Jest to zestaw pytań, które potencjalnie pasują do różnych sklepów.

Pytania są następujące:

 

Oznaczenie Pytanie Oceniany krok
A1 Pytanie o szerokość oferty Przejrzyj ofertę, Wybierz produkty
A2 Pytanie o podział oferty na kategorie Przejrzyj ofertę
A3 Pytanie o wyszukiwarkę Przejrzyj ofertę
A4 Pytanie o ceny Przejrzyj ofertę, Wybierz produkty
B1 Pytanie o formy dostawy Złóż zamówienie
B2 Pytanie o formy płatności Złóż zamówienie
C Pytania o lokalizację punktu odbioru Odbierz zamówienie
D Pytania o obsługę w punkcie odbioru Odbierz zamówienie
E Pytanie o zadowolenie z obsługi w punkcie odbioru Odbierz zamówienie
F Pytanie o problemy w trakcie realizacji lub odbioru Odbierz zamówienie
G Pytanie o polecenie sklepu innym cały proces

Pytania na diagramie zostały przyporządkowane do poszczególnych części procesu, zgodnie z powyższą tabelką. Patrząc na pytania w ramach poszczególnych grup można spróbować zinterpretować wyniki:

  • jeżeli spadają oceny w zakresie pytań z grupy A, może to sugerować, że w ofercie brakuje części poszukiwanych produktów przez Klientów i zamawiają te, które znaleźli lub też ceny produktów Klienci są w stanie zaakceptować ale mogłyby być niższe. Jeżeli oceny rosną lub utrzymują się na wysokim poziomie, oznaczać to może, że oferta spełnia oczekiwania Klientów lub jeżeli ktoś już złożył zamówienie, to ocenia w taki sam sposób sklep, nie wnikając w szczegóły. Kwestię dostosowania produktów i ich cech do oczekiwań Klientów opisywałem we wpisie „Promocyjny proces
  • jeżeli spadają oceny w zakresie pytań z grupy B, to oznacza, że Klienci sobie radzą ale oczekują jednak określonych zmian w procesie zamówienia, np. nowej formy dostawy, formy płatności lub inne sklepy stosują rozwiązania, które bardziej odpowiadają Klientom. Jeżeli oceny rosną lub utrzymują się na tym samym wysokim poziomie, oznacza to, że serwis działa zgodnie z oczekiwaniami bądź też korzystają z niego te same grupy Klientów. Dostępność usług analizowałem kiedyś we wpisie „Punkty przełamania dla usługi”.
  • oceny z pytań z grupy C są uzależnione od tego jak gęsta jest sieć punktów odbioru oraz od odległości punktu odbioru od miejsca przebywania, pracy czy zamieszkania Klienta. Zakładając, że Klient wybiera dostawę do danego punktu odbioru świadomie, negatywne oceny mogą świadczyć, że tych punktów jest za mało. Inna sprawa, że niektóre sklepy dostarczają tylko do punktów odbioru i wtedy Klient nie ma wyjścia, jeżeli korzysta z danego sklepu i może to wtedy wpłynąć na oceny. Może też być jeden punkt odbioru w danym mieście.
  • oceny pytań z grup D-E są silnie uzależnione od interakcji międzyludzkich, od czasu i okoliczności, kolejek w punkcie odbioru, doświadczenia osób w nim pracujących, oczekiwań Klientów, rodzaju i jakości produktów, infrastruktury oraz problemów niezależnych od punktu odbioru (np. przerwy w działaniu kart czy brak prądu). O ryzykach, które powodują, że zakupy się nie udają pisałem w innym wpisie.
  • oceny z ostatnich grup F-G, to ocena całego procesu zamówienia i jego odbioru. Im lepsze oceny tym większa szansa, że obecny Klient może przyciągnąć kolejnych Klientów do danego sklepu. Przeważnie są to pytania o chęć polecenia sklepu innym lub powrotu do sklepu kolejny raz. W tej części są także pytania o problemy oraz sugestie Klienta odnośnie procesu. Dzięki odpowiedziom w tej sekcji możemy się dowiedzieć co konkretnie można poprawić. Ocena jakości procesu czy usługi wymaga zbudowania wskaźników.
  • co ciekawe żadne z pytań nie dotyka wprost kwestii związanej z czasem realizacji zamówienia, dlatego też element oczekiwania na możliwość odbioru zamówienia nie został przypisany do żadnej z grup, a został uwzględniony jako elementy oceny całości procesu. Na czas procesu można spojrzeć w różny sposób.

Odpowiednio skonstruowana ankieta i jej analiza pozwalają odpowiedzieć na pytania, które już kiedyś analizowałem we wpisie „Dlaczego taki proces?” oraz „A gdzie wartość dodana procesu?” oraz we wpisach powiązanych. Zakładając, że wypełnione ankiety zawierają „prawdziwe” dane i to, że Klienci chcą nam coś przekazać, abyśmy poprawili proces oraz podejmują taki wysiłek w większości przypadków, gdy mają uwagi, to wnioski takiej ankiety mogą być przydatne podczas poprawy procesu oraz dostosowania go do oczekiwań Klientów.

Myślę, że warto wypełniać jednak takie ankiety po zrealizowanym zamówieniu a także wtedy, gdy takie zamówienie nie dochodzi do skutku (jeżeli jest taka możliwość). Korzyścią jest to, że w przyszłości będziemy mogli potencjalnie skorzystać z lepszego procesu lub też ułatwimy innym korzystanie ze sklepu. Warto też wskazywać konkretne słabości lub braki.

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.

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.

Gdy koncert został odwołany

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.