Pytania o realizację procesu

Ostatnio wysyłając przesyłke, postanowiłem sprawdzić, za pomocą dostępnych narzędzi, jaki jest status przesyłki – czy dotarła, czy została odebrana. Udało mi się sprawdzić I przy okazji pomyślałem, że tak naprawdę jest to pewien proces rozciągnięty w czasie, gdzie inicjatorem jest nadawca przesyłki, a na końcu procesu jest odbiorca przesyłki. Istotnym elementem procesu są komunikaty przekazywane od obsługującego proces do odbiorcy – takim komunikatem jest przekazanie informacji do odbiorcy o oczekującej przesyłce w miejscu odbioru.

Proces od strony podmiotu obsługującego można zobrazować następująco:

Diagram1

W przypadku tego procesu, patrząc z perspektywy metody SIPOC można powiedzieć, że mamy: Dostawcę (nadawca przesyłki), Wejście (rodzaj przesyłki, dane odbiorcy, waga, inne parametry), Proces (realizacja przesyłki), Wyjście (przesyłka dostępna w miejscu docelowym, komunikat do odbiorcy), Klient (odbiorca przesyłki).

Jako nadawca – Klient – chciałem wiedzieć jak jest realizowany proces przesyłki.
Pytania, które mógłbym zadać, przykładowo:

  • Jaki poziom szczegółowości postępu procesu (statusy) jest potrzebny? Np. Nadany, przesłany, odebrany. Więcej o statusach.
  • Jakie informacje o przesyłce (wejście, wyjście) powinny być dostępne? np. Numer przesyłki, miejsce nadania itp.
  • Jakie informacje z realizacji procesu są mi potrzebne? np. Daty realizacji.
  • Do kiedy mogę sprawdzić, czy przesyłka dotarła? np. 2 tygodnie od zakończenia procesu, gdybym nie mógł sprawdzić przesyłki na bieżąco.

 

Informacja dodatkowa z procesu, to ile czasu może trwać dostarczenie określonej przesyłki do danego miejsca, gdyby korzystał częściej z tego mechanizmu. Jest to cenne, aby wiedzieć z jakim wyprzedzeniem lub po jakim czasie może druga strona zareagować na przesłaną informację.

Wyjście z pętli w BPMN

Ostatnio kilkakrotnie dzwonił do mnie „tajemniczy” numer prywatny. Domyślałem się, że to może być Bank lub inna instytucja. Kilkakrotnie próbowałem odebrać – albo mi się nie udało albo nie słyszałem. Zawsze pozostaje opcja „oddzwonię”, ale nie tym razem – na „Numer prywatny” nie da się oddzwonić. Jeden raz , udało się odebrać i usłyszałem tylko „Proszę czekać na zgłoszenie się operatora”. Pomyślałem – o mają automatyczne wybieranie numeru. Dobra, myślę, poczekam pół minuty, bo więcej nie byłem w stanie. Po pół minucie muzyczki, rozłączyłem się. I niestety brakowało mi jednego, informacji kto i dlaczego dzwoni. Po kilku dniach wreszcie się im udało, po odebraniu usłyszałem natychmiast miły głos operatora, który przedstawił się, wygłosił formułkę i przeszedł do rzeczy. Wysłuchałem go do końca. Następny raz już nie zadzwonili.
callcenter450
Powyższą sytuację można sobie wyobrazić jak pętlę per odbiorca kampanii. Zgodnie z definicja pętli (ang. loop) z matematyki umożliwia cykliczne wykonywanie ciągu czynności („pobranie rekordu, sprawdzenie statusu, wybranie numeru”) określoną liczbę razy, do momentu zajścia pewnych warunków („odbyto rozmowę” – status sprawdzany na bramce), dla każdego elementu kolekcji (działanie wykonywane dla każdego rekordu kampanii) lub w nieskończoność.

Kolejne czynności: sprawdź czy rozmowa się odbyła, wybierz numer, połącz z operatorem (gdy nie jest wolny, poinformuj o oczekiwaniu), a po rozmowie pomiń danego odbiorcę z kolejnego telefonu. Wyjściem z pętli jest zdarzenie „Odbyto rozmowę”. A zdarzenia: „Brak połączenia”, „Połączenie zerwane”, „Odbiorca niedostępny” powodują powtórzenie czynności dla danego odbiorcy.  Odczułem to na własnej skórze – a dzwoniący odczuł wszystkie powyższe zdarzenia z mojej strony. Powyższy diagram w BPMN obrazuje taką sytuację. Zobrazowana pętla, w sytuacji braku odebrania telefonu przez odbiorcę, jest nieskończona – należałoby dodać warunek o ilości prób lub maksymalny czas od rozpoczęcia kampanii do ostatniego telefonu.

Asocjacje w BPMN

Komentarz do poprzedniego wpisu o obiektach danych w BPMN wskazał jedną kwestię o której nie napisałem przy okazji umieszczania obiektów na diagramie. Połączenie obiektu danych z krokiem procesu odbywa się za pomocą tzw. asocjacji (ang. Association).

processassoc450b

Zgodnie z uwagą wygląd asocjacji wskazuje na rodzaj powiązania:

  • asocjacja bez strzałek oznacza dostęp do danych – na powyższym diagramie między krokiem “Zarejestruj zlecenie” i elementem “Baza zleceń” (kolekcja obiektów, ang. Data Store).
  • asocjacja ze strzałkami oznacza dane wejściowe lub wyjściowe – na powyższym diagramie dla obiektów wejściowych strzałka na asocjacji jest w kierunku kroku procesu, dla wyjściowych w stronę obiektu danych.

Dodatkowo na diagramie  (w BPMN) występuje obiekt danych (obiekt Zlecenie), który najpierw jest wyjściem z kroku (zapisane zostały dane). Ma oznaczony status. Dalsza praca odbywa się na takim obiekcie, będącym wejściem do kolejnego kroku (krok pobiera dane). Korzystając z aplikacji do przygotowania diagramu procesu, trzeba uważnie stosować typy powiązań.

Asocjacje są także wykorzystywane do łączenia innych obiektów – np. tekstu (ang. Text annotation) – jak w przypadku powyższego diagramu element zawierający dodatkową informację o kroku.

Decyzje pod kontrolą lub poza

Dzisiaj ponownie przybliżę temat tzw. bramek wyłączających (ang. exclusive gates), czyli takich, z których możliwe jest tylko jedno wyjście do dalszego procesu. Około rok temu, wskazywałem we wpisie o podejmowaniu decyzji w procesie, że mamy dwa rodzaje tych bramek: oparte o dane (ang. data-based) oraz oparte o zdarzenia (ang. event-based). Podany wtedy przykład nie podawał wyraźnie rozróżnienia między tymi bramkami. Dzisiaj postaram się podać lepszy przykład.

process_decisions_d

Załóżmy, że nadal mówimy o procesie przygotowania raportu. Otrzymaliśmy wniosek i analizujemy, czy mamy komplet danych i są one spójne. Posługujemy się danymi dostępnymi tu i teraz, lokalnie, bez angażowania innych osób, chcemy zrealizować zlecone zadanie. I to jest jest właśnie specyfika bramek opartych o dane (ang. exclusive data-based). Na powyższym diagramie w BPMN jest to pierwsza z bramek, występująca po czynności Określ parametry wniosku. Wszystkie elementy są pod kontrolą wykonującego czynność. Wiemy dokładnie jakie czynności zostaną wykonane dalej.

W sytuacji jednak, gdy dane okażą się niespójne lub zabraknie danej do parametryzacji oczekiwanego raportu, pojawia się konieczność kontaktu z odbiorcą raportu. W tym momencie, dalszy przebieg procesu jest poza naszą kontrolą. To, co się dalej wydarzy jest uzależnione od odbiorcy raportu. To jest charakterystyczne dla bramek opartych o zdarzenia (ang. exclusive event-based). Na powyższym diagramie w BPMN jest to druga bramka. W sumie wiemy co dalej możemy wykonać w przypadku różnych działań odbiorcy, ale sama jego decyzja jest niezależna od samego procesu.

Myślę, że powyższy przykład lepiej oddaje charakter tych dwóch bramek. Innym przykładem może być ten z wysyłką listu/wykonywaniem telefonu, a odbiorem przesyłki/odebraniem telefonu.

Granice procesu

Czasami mówimy „Muszę zrobić przelew” i wtedy mamy pewnie na myśli proces od momentu określenia danych odbiorcy, poprzez zalogowanie do serwisu on-line, wypełnienie danych, autoryzację i wylogowanie. Z punktu widzenia Klienta proces zaczyna się wcześniej niż proces postrzegany przez operatora systemu. Operator określa, że wykonanie przelewu jest możliwe dla zalogowanego użytkownika, z odpowiednimi uprawnieniami (dostępnymi opcjami), limitami oraz możliwościami autoryzacji przelewu.

Można powiedzieć, że granice procesu są różne – jedne szersze, a drugie węższe.

granice_procesu450

Na powyższym diagramie:

  • kolorem czerwonym oznaczone są kroki poza granicami procesu w systemie, o którego przebiegu decyduje operator systemu on-line;
  • kolorem niebieskim oznaczone są kroki automatyczne, wykonywane w tle, istotne dla przeprowadzenia procesu;
  • kolorem szarym oznaczone są kroki pozwalające na dostęp do systemu, danej funkcji systemu i wyjście z systemu; obok możliwości wykonania przelewu ich efektem – w szczególności weryfikacji uprawnień – może być udostępnienie innych funkcji;
  • kolorem żółtym oznaczone są elementy właściwego procesu pozwalającego na wykonanie przelewu.

Patrząc od żółtych kroków, mamy najwęższe granice procesu. Uwzględniąc wszystkie kolory mamy najszersze granice.

Optymalizacja zakupowa a reguły biznesowe

Przygotowywanie listy zakupów to czynność jak najbardziej codzienna. Żadna filozofia, tworzysz listę, zastanawiasz się gdzie możesz kupić poszczególne rzeczy, jak daleko, ile czasu potrzeba, co jest najbardziej potrzebne, co mogę kupić innym razem. Łatwiej jest gdy robimy listę zakupów do określonego sklepu – spożywczego czy marketu. Trudniej, gdy okazuje się, że lista zakupów jest na tyle różnorodna, że wymaga odwiedzenia różnego rodzaju sklepów i niekoniecznie mamy czas, aby udać się do marketu.

Załóżmy więc, że mamy do kupienia: kwiaty (ZAK3), chleb(ZAK2), gazety(ZAK1) i płytę CD (ZAK4). Rzeczy potrzebne i jak dostępne w różnych sklepach. Dodatkowo mapa obok wskazuje miejsca potencjalnego zakupu tych produktów oraz miejsce rozpoczęcie zakupów (START).

Poniższy diagram (w BPMN) prezentuje przebieg procesu realizowanego w powyższej sytuacji – od określenia zakupów do realizacji zakupów. Najważniejszą częścią procesu jest określenie priorytetów oraz kolejności wykonywanych zakupów. Jest to istotne, gdy na przykład mamy mniej czasu lub liczymy się z tym, że pewnych produktów możemy nie dostać lub może być kolejka. Może będzie trzeba zmienić sklep. Następnie, co prawda dynamicznie, określana jest droga po zakupy. Można ją zaplanować przed wyjściem z domu a można w trakcie. W podanym przykładzie nie zostały wskazane priorytety. Po połączeniu informacji o miejscach (gdy będą inne) oraz priorytetach droga może zostać określona w zupełnie inny sposób.

Taką optymalizację zakupową wykonujemy automatycznie w trakcie określania listy zakupów, nie zastanawiając się nad poszczególnymi krokami, ani kolejnością. Gdybyśmy chcieli przygotować aplikację, która dla podanej listy zakupów określa lokalizację, potencjalną kolejność zakupów w zależności od priorytetów, akceptowalną odległość od miejsca startu, miejsca, których chcemy uniknąć, należałoby zdefiniować odpowiednie reguły biznesowe, zaimplementować mechanizm rozwiązujący problem komiwojażera, włączyć mapę wraz z naniesioną listą sklepów.

Rózwój procesu jako likwidacja jego luk

W literaturze można się spotkać z przyczynowym podejściem do rozwoju przedsiębiorstwa, które skupia się na identyfikacji i rozwoju luk. Mogą to być takie luki jak na przykład:

  • luka między stanem pożądanym a rzeczywistym, patrząc całościowo na organizację;
  • luka między stanem możliwości a stanem potrzeb przykładowo w zakresie zasobów o określonym doświadczeniu, zaangażowaniu, umiejętnościach;
  • luka między posiadanymi lub pozyskanymi w przeszłości możliwościami a rzeczywistymi/realizowanymi osiągnięciami, efektami działalności, która najlepiej pokazuje, czy przedsiębiorstwo idzie w oczekiwanym kierunku, czy jego osiągnięcia sprzedażowe, inwestycyjne, w zakresie polityki społecznej itp. odpowiadają posiadanym zasobom oraz zrealizowanym przedsięwzięciom.

Spojrzenie to jest właściwe dla poziomu całej organizacji, jednakże czy nie można tego przełożyć na niższy poziom? Pojedynczego procesu? Odpowiedź jest prosta – tak, w szczególności stosując zasady benchmarkingu lub reinżynierii procesów biznesowych.

Załóżmy, że mamy fragment procesu, gdzie po zakończeniu zadania przez jednego z uczestników procesu, efekt jest „konsumowany” przez innego uczestnika w kolejnym kroku. Diagram (w BPMN) prezentuje „oficjalny” i rzeczywisty przebieg procesu z zaznaczeniem luki.

W procesie konieczna byłaby modyfikacja luki między wyjściem „X” a wejściem „Y”. Różnica wynika z założenia, że każdy z uczestników chce wykonać jak najlepiej swoją pracę, jednakże oczekiwania uczestnika o Roli Y co wejścia do swojego zadania, są różne od rzeczywistego wejścia, produkowanego na wyjściu przez uczestnika o Roli X. W procesie konieczne jest wtedy przeznaczenie czasu na wyjaśnienia lub poprawki. W ramach benchmarkingu możliwe byłoby poprawienie tego procesu – na przykład poprzez zderzenie oczekiwań obydwu stron – Roli X i Roli Y. Może efekt pracy Roli X jest spowodowany przez jakość materiału, który otrzymuje z wcześniejszych etapów procesu. Całościowa analiza pozwoli na zidentyfikowanie większości luk i określenie ich przyczyn.

Wejścia i wyjścia w procesie

Diagramy zaprezentowane w poprzednim wpisie – diagram procesu w BPMN oraz wizualizację myślenia systemowego – można spróbować połączyć na jednym diagramie, powstałym na bazie diagramu aktywności dla procesu biznesowego. Na poniższym diagramie zostały dodane wejścia do kroków i wyjścia z kroków (kierunek strzałek obrazuje to, czy dany obiekt jest wejściem czy wyjściem z danego kroku procesu).

Można zauważyć, że:

  • niektóre wejścia/wyjścia pasują do kwestii zobrazowanych na diagramie myślenia systemowego – np. „Akceptowalna stawka”;
  • niektóre kwestie z diagramu można potraktować jako cechę wejść/wyjść – np. „Liczba zgłoszeń” jest cechą „Listy zgłoszeń”;
  • niektóre kwestie z diagramu nie są związane z wejściami/wyjściami a bardziej są cechą charakterystyczną dla całego procesu – np. „Czas realizacji rekrutacji”;

Istotne jest to, że cechy wejść do poszczególnych kroków wpływają zarówno na realizację danego kroku, jak i całego procesu. Takimi cechami mogą być liczba zgłoszeń, jakość zgłoszeń, czas potrzebny na zapoznanie się z danym zgłoszeniem, stopień dopasowania poszczególnych zgłoszeń do opisu stanowiska pracy itd.

Świadomość takich powiązań ułatwia realizację procesu. W szczególności, gdy dany uczestnik procesu ma świadomość, że efekt (i jakość) realizacji jego zadania zostanie wykorzystany dalej w procesie, wpłynie na działania dalszych uczestników procesu. Właśnie do pokazania takich zależności w ramach procesu w kontekście produktów dla klientów wewnętrznych procesu można wykorzystać myślenie systemowe. Na analizie wejść/wyjść procesu jest oparte narzędzie SIPOC pochodzące z metodologii Six Sigma (ale o tym innym razem).

Benchmarking – trochę teorii

Benchmarking jest „procesem ciągłego uczenia się i twórczego doskonalenia organizacji wykorzystującym rozwiązania i osiągnięcia, które wypracowali najlepsi w danej dziedzinie”. Rozszerzając tę definicję można wskazać, że „benchmarking jest ciągłym i systematycznym procesem identyfikowania, analizy, projektowania i w konsekwencji wdrażania lepszych rozwiązań w zakresie procesów, produktów oraz sposobów rozwiązywania problemów i realizacji celów z wykorzystaniem uznanych i sprawdzonych wzorców wewnętrznych i/lub zewnętrznych organizacji, którego rezultatem powinien być wzrost jej efektywności”. Definicja pochodzi z książki A. Węgrzyna „Benchmarking. Nowoczesna metoda doskonalenia przedsiębiorstwa„. Ta definicja zarysowuje cztery podstawowe elementy benchmarkingu.  Poniższy diagram (w BPMN) prezentuje, zgodnie z powyższą definicją 4 główne etapy, charakter wdrażanych zmian, wejście oraz wyjście procesu.

Warstwa implementacyjna – podproces

W ramach warstwy implementacyjnej, niektóre zadania/kroki procesu są bardziej rozbudowane a niektóre mniej. Jednym z zadań/kroków, które ma charakter podprocesu (ang. sub proces) jest „Realizacja zamówienia” (diagram obok).

Warunki wejścia dla tego podprocesu są następujące:

  • zebrano dane o kliencie (zostały określone DaneKlienta)
  • złożono zamówienie (został określony komplet danych składających się na DaneZamówienia),
  • określono szczegóły i warunki dostawy (zostały określone DaneDostawy),
  • zrealizowano płatność (potwierdzenie realizacji płatności – PotwierdzPlatnosci)
  • produkt jest nadal w ofercie i produkt jest dostępny (ProduktDostepny)
  • klient nie zrezygnował z zamówienia (BrakRezygnacji)

Wyjście z procesu może być następujące:

  • zamówienie zostało zrealizowane (produkt został dostarczony do Klienta – ProduktDostarczony) lub
  • pojawił się problem w trakcie realizacji (produkt nie został dostarczony do Klienta – ProduktNiedostarczony)