Archive for Styczeń 2016

h1

Niemy proces

Styczeń 31, 2016

W sumie dzisiejszy wpis mógłbym zacząć podobnie jak wpis, który niecały rok temu zamieściłem na swoim blogu. We wpisie w marcu 2015r. skupiłem sie na tym, że zdzwoni do mnie często ten sam numer, a gdy go odbieram, to przedstawiciel sieci komórkowej lub innego dostawcy próbuje przekonać mnie do skorzystania z nowej oferty lub zmiany parametrów istniejącej. Po kilku kolejnych telefonach, dalej już nie dzwonili.

Teraz mam podobną sytuację, ale niestety odbierając połączenie, nie słyszę operatora, a muzyczkę lub jest cisza w słuchawce. Domyślam się, że nastąpił rozwój narzędzi i numer telefonu jest wydzwaniany i umieszczany w kolejce do danego konstulanta, gdy jeszcze on nie zakończył poprzedniej rozmowy. Za każdym razem, przerywam połączenie, bo nie ma zamiaru czekać nieokreślony czas na nawiązanie połączenia. A Ci dzwonią po raz kolejny. Można powiedzieć, że proces jest niemy, bo tak naprawdę nie wskazuje dlaczego, skąd i w jakim celu nastąpiło połączenie.

kampania_1_450px

Moim zdaniem można byłoby ten proces bardzo łatwo usprawnić, co jak rozumiem nie jest w interesie wydzwaniającego. Pierwsza myśl, to automatyczne przywitanie (wysłany „Komunikat powitalny” na diagramie) z informacją, że proszę poczekać kilka minut. Gdybym dowiedział się kto dzwoni to pewnie i tak przerwałbym połączenie. Skutek więc ten sam. Jednak co zrobić, aby nie dzwonili po raz kolejny? Patrząc racjonalnie, ani nie jest to efektywne, ani przyjazne. Gdyby nawet udałoby się porozmawiać, to nie miałbym z nimi ochoty rozmawiać. Problem byłby taki, że nawet rozmowa i brak zainteresowania nie oznacza, że przestaną zdzwonić. Obecne rozwiązanie jest bardzo słabe.

Powyżej zasygnalizowany proces (przed zmianą) jest przykładem nieefektywanego procesu Można w nim zaobserwować różne objawy marnotrawstwa.

Reklamy
h1

Wysłany-odebrany

Styczeń 23, 2016

W wielku polskich miastach na przystankach komunikacji miejskiej można zauważyć tablice, które wskazują godziny przyjazdu lub czas oczekiwania na dany środek komunikacji. Obserwując dane na takim wyświetlaczu można zauważyć, że wskazana liczba minut do przyjazdu np. autobusu spada a czasami rośnie i znów spada. Wskazuje na orientacyjny czas przyjazdu autobusu.

Można przypuścić, że z jednej strony w systemie zakodowany jest czas przejazdu danego autobusu między poszczególnymi przystankami. Jeżeli dany autobus jest spóźniony na poprzedni przystanek, to pewnie orientacyjny czas przyjazdu rośnie (biorąc pod uwagę opóźnienie i czas planowany na przejazd między przystankami). Można sobie wyobrazić, że autobus przyjeżdzając na przystanej wysyła sygnał do systemu, który go odbiera i analizuje, a następnie koryguje czasy wyświetlane na tablicach. W takim komunikacie mogłyby być dane: linia, kurs, czas itp. Taką komunikację opartą wysyłkę I odbiór komunikatu prezentuje poniższy diagram.

wyslany_odebrany_1_450px

Wskazane typy zadania (z BPMN) – wysyłające (ang. send task) i odbierające (ang. receive task) zostały przeze mnie wykorzystane m.in. w poprzednim wpisie w ramach procesu współpracy. Zadania te mają za cel umożliwienie komunikacji między basenami w procesach współpracy. Patrząc na rozwiązania systemowe, mogą to być komunikaty wysyłane w określonym formacie i wyrażone w okreslonym języku (np. XML). Np. w momencie przyjazdu autobusu na przystanek komunikat mógłby być taki:

<?xml version="1.0"?>
<header>
   <sendtime>2016-01-23 12:30:01</sendtime>
   <msgtype>PrzyjazdAutobusu</msgtype>
</header>
<body>
   <busnumber>45</busnumber>
   <kurs>3</kurs>
   <stopnumber>4</stopnumber>
</body>

I w momencie odjazdu z przystanku komunikat mógłby być taki:

<?xml version="1.0"?>
<header>
   <sendtime>2016-01-23 12:33:01</sendtime>
   <msgtype>OdjazdAutobusu</msgtype>
</header>
<body>
   <busnumber>45</busnumber>
   <kurs>3</kurs>
   <stopnumber>4</stopnumber>
</body>
h1

Poza basenem, czyli proces współpracy

Styczeń 11, 2016

W poprzednim wpisie, skupiłem się na procesie odbywającym się w ramach danej jednostki, gdy to pracownik odbiera bilet od pasażera i samodzielnie przeprowadza proces przy użyciu narzędzia. Cofnijmy się jednak o krok a dokładnie 2 kroki wcześniej, zanim konduktor rozpoczął weryfikację biletu. Z racji, że miałem bilet internetowy, najpierw zostałem poproszony o bilet a następnie o dokument osoby wskazanej na bilecie do potwierdzenia tożsamości. Te 2 kroki są zaprezentowane na poniższym diagramie.

prosba_o_bilet_1_450px

Na powyższym diagramie, można zauważyć, że także są wykorzystane tzw. baseny jednakże nie jeden, a dwa. Każdy z nich obrazuje innego uczestnika procesu a komunikacja odbywa się za pomocą komunikatów i reakcji na nie. Jest to tzw. proces współpracy (ang. collaboration process). W tym procesie pojawiają się już zdarzenia początkowe (ang. start event) i zdarzenia końcowe (ang. end event) w każdym z basenów oraz można powiedzieć, że nie jest on “ciągły” w ramach jednego basenu. Proces wychodzi jakby poza dany basen i oczekuje reakcji z drugiego basenu na wysłany komunikat.

Przykłady dla procesu współpracy w innych sytuacjach znajdują się w moich poprzednich wpisach:

h1

Proces w „basenie”

Styczeń 2, 2016

Podczas jednej z zeszłorocznych kontroli biletowych w pociągu, z rozpędu dałem do kontroli bilet powrotny. Konduktor próbuje uparcie  kilka razy odczytać kod, przeprowadzić jego weryfikację. Wreszcie spisuje kod na kartce i oddaje mi bilet. Odchodzi, sprawdza bilety pasażerów. Nagle wraca i sytuacja sie powtarza. Mówi, że trzeba będzie kupić bilet ponownie, bo ten jest nieprawidłowy i pewnie został anulowany. Biorę od niego bilet, patrzę i nagle okazuje się, że bilet jest na pociąg powrotny. Wpatrywał się w niego kilka minut i tego nie zauważył, nawet spisując jego numer. Odszukuję właściwy bilet, daję go i wszystko było już ok.

weryf_biletu_1_450px

Przytoczona sytuacja obrazuje prosty proces, opisany od strony pracownika kolei, składający się z 2 tzw. aktorów – Konduktora i Systemu kontroli. W takiej sytuacji, gdy proces jest ciągły w ramach jednej jednostki/podmiotu (pracowników kolei), stosujemy na diagramie (w BPMN) tzw. basen (ang. pool) i pola/pasy (ang. lane). Są to poziomo lub pionowo przedstawione obszary, przy czym w ramach basenu (ang. pool), określającego np. jednostkę biznesową, są umiejscowione pasy (ang. lanes), określające aktorów/role (lub inne obiekty) z tej jednostki biznesowej (lub procesu). Powyższy diagram prezentuje taki uproszczony diagram, z wykorzystaniem tych elementów.

Dzięki takiej prezentacji mamy jednoznaczne wskazania kto, jakie i w ramach jakiej jednostki wykonuje czynności, składające się na proces. Między rolami/aktorami w ramach basenu nie są przesyłane komunikaty, proces jest ciągły. Nie mamy zdarzeń początkowych procesu w ramach każdego pasa, a jedynie przed czynnością/zadaniem, które występuje biznesowo jako pierwsza w procesie. Jako nazwa basenu może występować również nazwa procesu, w którym uczestniczą wskazane na pasach role.