Przez telefon czy na stronie?

Chyba każdy zna ten moment gdy jest przerwa w dostawie prądu – czy to chwilowa objawiająca się tylko mrugnięciem czy też dłuższa, wymagająca określonych działań (sięgnięcia po latarkę, świeczkę czy inny sprzęt). Gdy ostatnio w sobotę, nastąpiły 3 krótkie „mrugnięcia” a później przyszedł do mnie sąsiad z pytaniem czy coś wiem, przypomniałem sobie o innej sytuacji. Pod koniec roku 2019, dzień przed wigilią byłem w domu z rodziną, mijała właśnie godzina 19 i nagle ciemność – na całym osiedlu. Niezły moment na taki problem – ludzie przygotowują święta, wstawione ciasta, mięsa i inne potrawy a tu brak prądu. Złapałem za telefon i szukam informacji. Za pierwszym razem nic nie znalazłem, a za drugim pojawiła się informacja na mapie dostawcy prądu o  awaryjnej przerwie w dostawie prądu, która jest szacowana na 2 godziny. Minęło kilkanaście minut i prąd znów był dostarczany. A po 20 powtórka, znów ciemność – tym razem na krócej. Informacja na stronie się nie zmieniła.

Mogę sobie wyobrazić, że w momencie pierwszego wyłączenia część osób złapało za telefon i zamiast szukać informacji (sprawdzać samodzielnie) zadzwoniło na pogotowie energetyczne lub na infolinię dostawcy prądu. Mogło być też tak, że ktoś mógł pójść do sąsiada i spytać czy coś wie o na przykład planowanym wyłączeniu prądu. Wyobraźmy sobie jak mógłby wyglądać proces od strony dostawcy, który łączy te dwie możliwości – stronę z informacjami i telefony.

Dostawca na podstawie zgłoszeń telefonicznych i ich weryfikacji mógłby umieścić informację na stronie o awarii. Dzięki czemu zaspokoi potrzebę informacji tych sprawdzających i potencjalnie zmniejszy liczbę telefonów z regionu objętego awarią. Może także mieć system monitoringu, który wskaże mu, że taka awaria nastąpiła. Wejściem do procesu może być zgłoszenie telefoniczne od odbiorcy lub własny monitoring. Wyjściem może być informacja na stronie. Skutkiem pewnie będzie także wysłanie ekipy technicznej w rejon objęty awarią lub inne specyficzne działania.

Na powyższym diagramie próbowałem przedstawić omówiony proces. Na diagramie w notacji BPMN wykorzystałem zdarzenie inicjujące proces, powstałe na bazie zgłoszenia/komunikatu przekazanego przez „zewnętrznego” aktora. Jest to tzw. message start event – jeden z typów zdarzeń (ang. events) używanych w notacji BPMN służącej do modelowania procesów. To zdarzenie na diagramie jest zaznaczone na żółto. Opisany proces nie miałby miejsca, jeżeli takie zdarzenie nie nastąpi. Brak telefonów lub innych zgłoszeń oznacza prawdopodobnie, że nie ma awarii.
—
Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.

Reklama

Drzewko decyzyjne w prezencie

Ostatnie tygodnie to okres szału zakupowego oraz przygotowań do świąt. Wielu z nas szuka prezentów dla najbliższych, znajomych, w ramach akcji społecznych czy czasami też dla siebie. Jedni poszukiwania prezentów zaczynają bardzo wcześnie (nie będę wskazywać kiedy, bo pewnie się znajdą tacy, u których podany termin wywoła emocje) a niektórzy zostawiają to na ostatnią chwilę (tydzień, dzień czy nawet godziny przed momentem wręczenia). Jednych prezenty są symboliczne a innych dość pokaźne. Jedni wydadzą fortunę a inni postawią na ręcznie przygotowywane prezenty. Wszystko zależy od dostępnego czasu, funduszy, pomysłu, poznanych lub nie potrzeb odbiorcy, podejścia danej osoby lub przyjętych zasad w danej grupie, rodzinie. Przypomina mi się przygotowywanie prezentów w szkole podstawowej podczas jednej z akcji – założeniem było, że prezent ma być wykonany ręcznie. Ile to powodowało kombinacji… I pewnie tak jest też w przypadku przygotowywania prezentów w dorosłym życiu.

Moim zdaniem podczas przygotowywania prezentów odpowiadamy sobie na następujące pytania (może trochę nieświadomie, ponieważ nasz sposób postępowania wynika z pewnego podejścia i możemy zawsze postępować w określony sposób lub się nad tym nie zastanawiać):

1. Zamówić gotowy produkt czy przygotować prezent samodzielnie?
2. Zamówić w okolice domu czy na miejsce, gdzie będziemy dawać prezent (o ile jest taka możliwość)?
3. Zamówić do punktu odbioru czy bezpośrednio do domu?
4. Opłacić przy zamówieniu czy dopiero przy odbiorze (o ile jest taka możliwość)
5. Zamówić kurierem , pocztą czy zdecydować się na odbiór osobisty?
6. Rozpocząć poszukiwania z wyprzedzeniem czy zostawić to na ostatnią chwilę
7. Zamówić prezent samodzielnie czy wspólnie z innymi (tzw. „zrzuta”)?
8. Jaką kwotę przeznaczyć na prezent?

Odpowiedzi na niektóre pytania z powyższych, wykluczają pojawienie się innych pytań. Z kolei pewne pytania wspólnie tworzą pewien zestaw wariantów. Np. Odpowiadając na pytanie (1), że wykonujemy prezent samodzielnie, możemy dodatkowo zastanowić się nad budżetem (8), aby określić ile chcemy przeznaczyć na elementy składowe. Możemy także zastanawiać się nad tym jak dostarczyć prezent do miejsca, gdzie zostanie wręczony. Pytanie o budżet czy moment zakupu w sumie występuje na każdym etapie „zastanawiania się”. Czasami kupujemy bo akurat jest promocja z tytułu black week/friday. A czasami czekamy na przypływ gotówki, ale mimo wszystko planujemy zakup prezentów uwzględniając dostępny czas, przyszły budżet oraz pomysły na prezenty.

Układając pytania w odpowiedniej kolejności możemy zbudować „prezentowe” drzewko decyzyjne (ang. decision tree). Czyli zidentyfikowaliśmy pytania, następnie je układamy w kolejności oraz budujemy zależności między nimi. Przykładowe drzewko bazujące na mojej propozycji ułożenia pytań jest przedstawione na powyższym diagramie. Można te pytania ułożyć także w innej kolejności. Można niektóre pominąć lub umieścić „wyżej” lub „niżej” w drzewku. Na szaro są zaznaczone liście (elementy końcowe, ang. leaf node) czyli określone akcje związane z przygotowaniem prezentu. Natomiast na biało miejsca rozgałęzienia (ang. splitting nodes), czyli punkty decyzji/pytania/testu wraz ze wskazaniem numeru pytania, do którego się odnoszą.

Drzewka decyzyjne pokazywałem także w kontekście wyborów, wyboru dostawcy czy scenariuszy dla grup na mistrzostwach.  Powyższe „podejmowanie decyzji” trochę mi przypomina planowanie działań uwzględniając co chcemy kupić (zaczniemy pewnie wcześniej) lub/i do kiedy musimy kupić (zrobimy to tak, aby się wyrobić, nawet rezygnując lub zmieniając wcześniejszy pomysł). Równocześnie mamy ograniczenie w postaci budżetu – co nas sprowadza to trójkąta projektowego (budżet, czas, zakres) lub rodzajów planowania stosowanych w technikach zwinnych.

Tymczasem pozostaje mi życzyć udanych i tafionych zakupów (niech Wasze drzewka będą pomocne), Wesołych Świąt i udanych wypieków o ile się ich podejmujecie.

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.

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

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.

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.

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.

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.

Automatyczne reguły oparte o wzorce

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

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

Ślad po procesie

Myślę, że można powiedzieć, że wraz z końcem września kończy się okres intensywnych wyjazdów wakacyjnych i powrotów. Jedni korzystali z samochodu, inni roweru, autobusu, statku, pociągu czy samolotu. Niektórzy skorzystali ze wszystkich, inni z jednego środka transportu a inni z kilku. Pierwszym krokiem był zakup lub rezerwacja biletu, samodzielnie lub przez biuro podróży, elektronicznie lub bezpośrednio w punkcie sprzedaży. W zależności od potrzeb, możliwości, każdy wybierał to, co mu pasuje. Pasażer decydował się na: wybór przewoźnika/linii (1), wybór kierunku (2), daty (3), miejsca startu (4) lub też innych parametrów podróży. Następne kroki zależały od wybranego środka transportu.

Pewnie niektórym pasażerom/turystom to dziś została przy torbie pamiątka z podróży samolotem. Jest to można powiedzieć ślad z realizacji pewnego procesu (wskazanego poniżej). Przyglądając się temu fragmentowi papieru można znaleźć takie informacje jak: (a) nazwisko pasażera, (b) liczba i waga bagażu, (c) data wydruku, (d) oznaczenie miejsca wylotu, (e) oznaczenie samego lotu, (f) oznaczenie miejsca docelowego, (g) data i godzina wylotu oraz (h) dodatkowe oznaczenia. Dodatkowo jest na nim kod kreskowy.

Ten ślad zawiera informacje pochodzące z procesu rezerwacji przelotu wykonywanego samodzielnie lub przez biuro podróży, rozszerzone o informacje pochodzące z odprawy, takie jak data wydruku oraz te, dotyczące bagażu. Przykładowy proces generujący przytoczone atrybuty został zaprezentowany na powyższym diagramie.

Informacje zawarte na tym pasku (bo często jest to długi wąski pasek) pozwalają szybko zweryfikować gdzie powinien trafić bagaż i czy został skierowany prawidłowo. Dodatkowo za pomocą naklejek z powtórzeniem kodu kreskowego, systemy na lotnisku mogą właściwe pokierować bagaż przez systemy sortowania bagażu. Także na samej płycie lotniska te paski lub kody są używane przez obsługę do weryfikacji, a także pewnie identyfikacji załadowanych sztuk bagażu (bo stojąc przy oknie i obserwując załadunek, można zauważyć, że na taśmie bagażowej przy samolocie jest czytnik, o ile dobrze zauważyłem, który skanuje każdą sztukę bagażu).

Można powiedzieć, że z punktu widzenia pasażera jest to ślad po odbytej podróży samolotem, natomiast z punktu widzenia lotniska jest to element zarówno kontrolny, jak i sterujący. Dodatkowo w momencie “zagubienia” bagażu można przypisać bagaż do odpowiedniej linii i przybliżyć się do powiązania bagażu do właściciela.

Po co to zdarzenie początkowe?

W przypadku BPMN stosowanie zdarzeń początkowych nie jest obligatoryjne, jednakże dobrą praktyką jest ich stosowanie. Jest to istotne, aby oznaczyć gdzie zaczyna się proces. Łatwiej odbiorcy diagramu określić, która czynność jest pierwsza. Łatwiej mu także zapoznać się z logiką procesu, który jest na diagramie. Wyobraźmy sobie, że na poniższym przykładowym (w BPMN) diagramie nie ma oznaczonego zdarzenia początkowego, które zostało zaznaczone. Skąd będziemy wiedzieć, gdzie się zaczyna proces i co powoduje jego przeprowadzenie? Czy zaczynamy od przekazania raportu do akceptacji czy od korekty?

Umieszczenie zdarzenia początkowego (ang. start event) ma także tę zaletę, że można okreslić typ tego zdarzenia. Można np, wskazać, że proces ma miejsce co miesiąc, albo w określonym momencie czasu. Także może sygnalizować jakie fizycznie zdarzenia go inicjuje i jakie warunki. Zależy to również od tego jak szeroki proces chcemy pokazać. Jeżeli autor diagramu zakłada, że np. przyjęcie zamówienia jest pierwszym krokiem, to przed nim dobrze jest umieścić zdarzenie początkowe.

Wiele narzędzi stosowanych do modelowania procesów w notacji BPMN kontroluje, czy dana czynność (ang. task) ma połączenie (ang. connection) przychodzące i wychodzące. Zdarzenie początkowe nie wymaga połączenia przychodzącego.

 

Niemy proces

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.

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.

Poza basenem, czyli proces współpracy

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.

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:

• proces w wykorzystaniem usług
• proces obsługi reklamacji

Początki w modelowaniu procesów

Obserwujesz sytuację biznesową i chcesz zrozumieć jak działają jednostki organizacyjne firmy? A może sam jesteś częścią procesu i zastanawiasz się jak wygląda on w całości? Jeśli dotyczy on Ciebie, często intuicyjnie wiesz, jakie czynności i kiedy są potrzebne. Z drugiej strony jednak dobrze uświadomić sobie jak akcje innych wpływają na dostarczanie wartości. Tworząc diagram procesu napotykasz kilka trudności – zaczynając od określenia jego granic, przez zidentyfikowanie poszczególnych kroków, a na odpowiednim poziomie szczegółowości kończąc.

Myślę, że każdy użytkownik Internetu korzystał z mniej lub bardziej rozbudowanych funkcjonalności tzw. sklepu internetowego lub innego serwisu pozwalającego na zakup usługi lub produktu przez Internet. W takim mechanizmie mamy elementy takie jak: logowanie/rejestracja, wyszukanie produktu, dodanie do koszyka, złożenie i opłacenie zamówienia, wylogowanie, realizacja zamówienia. Pierwsza myśl to określenie, że wszystkie te czynności stanowią jeden proces. Podejście słuszne, ale…

Chcesz przeczytać więcej? Zapraszam do przeczytania mojego gościnnego wpisu w serwisie Analiza IT o początkach w modelowaniu procesów, skupiającym się na następujących aspektach:

• Gdzie zaczyna i kończy się proces?
• Jakie są kroki?
• Jakie są wejścia i wyjścia procesu?
• Jaki poziom szczegółowości?
• Jakie narzędzia?