Ograniczenia w konfiguracji procesu

Ostatnio będąc w jednym z nowo wybudowanych biurowców w Warszawie, spotkałem się z nowym rozwiązaniem dot. funkcjonowania windy. Zwykle jesteśmy przyzwyczajeni, że przyciski do wskazywania piętra docelowego są wewnątrz windy, co oznacza, że gdy zostanie zawołana winda, jej przejazd na „nasze” piętro jest uzależniony od innych pięter wybranych przez innych użytkowników.

Można powiedzieć, że czas przejazdu trwa tyle ile przejazd przez piętra bez zatrzymania oraz suma czasów potrzebnych na otwarcie, przemieszczenie się pasażerów i wyjście. Jeżeli w biurowcu z 10 piętrami, w windzie będą osoby jadące na 1, 3, 5, 9 piętro, gdy my jedziemy na 10 to czas przejazdu się wydłuży. W odwiedzonym biurowcu, żądanie piętra wskazywane jest przed wejściem i system zarządzania piętrami, wskazuje, z której windy można skorzystać. Jedna jedzie np. na piętra 1-4, a inna na piętra 8-10. Rzeczywisty czas przejazdu zdecydowanie się skraca.

winda_pub

Powyższe obliczenia wskazywałem w jednym w poprzednich wpisów, dotyczącym konfiguracji kroków procesu. W zmodyfikowanej wersji, dana winda ma ograniczenie swojej konfiguracji – porusza się tylko do określonego piętra albo między określonymi piętrami. To ograniczenie może się zmieniać w czasie w zależności od zapotrzebowania i ilości żądań dotyczących różnych pięter. Jeżeli np. przed windą znajduje się grupa osób, np. 30, i każda z nich wskazuje, że chce pojechać na piętra 4-8, to, aby skrócić czas oczekiwania, liczba wind obsługująca te piętra może się zmienić. Może to też być rozłożone w czasie po analizach wcześniejszego wykorzystania.

Na powyższym diagramie pierwotny proces został odpowiednio zmodyfikowany do takiej sytuacji. Ograniczenie dotyczyć może nie tylko pięter ale także zabieranych osób, a także miejsce oczekiwania windy w trakcie braku wykorzystania. Ten sam mechanizm działa także w momencie przejazdów między piętrami oraz powrotu z najwyższego piętra. Dodany krok „sprawdź zgodność żądania” i przestawiona kolejność wynika z narzucony ograniczeń dla procesu obsługi windy.

Można powiedzieć, że system zarządzania windami, dla każdej windy uruchomił ten sam program obsługi, funkcjonujący w oparciu o powyższy proces, ale z innymi ograniczeniami, wejściem do procesu. Jest to czysto teoretyczne przedstawienie, ale pokazuje jak narzucone ograniczenia dla procesu wpływają na jego działanie. Konfiguracja jego kroków, określa w jaki sposób reaguje na określone wejścia do procesu.

Każdy krok procesu jest istotny

Od jakiegoś czasu w Poznaniu funkcjonuje karta aglomeracyjna. Jedną z jej funkcji jest możliwość opłacenia (w różnej formie) przejazdów komunikacji miejskiej. Jeżeli korzysta się sporadycznie przydatna okazuje się funkcja wirtualnego konta, które się zasila, a potem bezpośrednio w tramwaju bądź autobusie można zapłacić za przejazd. Opłata jest naliczana za każdy przystanek, jednostkowa opłata maleje wraz z liczbą przejechanych przystanków.

karta400

Konstrukcja pobierania opłat jest o tyle ciekawa, że w przypadku wykonania wszystkich kroków procesu zaprezentowanego na powyższym diagramie, opłata jest obliczona dokładnie za liczbę przejechanych przystanków. Jeżeli proces zostanie przerwany (nie zostanie wykonany krok zaznaczony na czerwono) opłata zostanie pobrana tak jakby podróż trwała do końca linii (nawet gdy przejechało się kilka przystanków).

Wykonując wszystkie kroki otrzymujemy oczekiwany produkt procesu (wyjście procesu). Gdy któregoś nie wykonamy, nie otrzymamy produktu, co można powiedzieć o każdym procesie. Proces jest powtarzany wielokrotnie, każda poprawna realizacja procesu, przy zapewnionych środkach na karcie (wejście procesu) i wykonaniu wszystkich kroków, mamy opłacony przejazd w kwocie zgodnej z oczekiwaną (wyjście procesu).

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

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.

Najpierw sprawdź, potem zrealizuj

Ostatnio odwiedziłem jedną z sieci serwisów samochodowych. Zadanie było proste: zamowienie nowych felg, ich zamontowanie razem z oponami letnimi i ich wyważenie. Składam zamówienie I słyszę, że potrwa to około 1,5 godziny, płatność przy odbiorze w takiej i takiej wysokości. Na koniec prośba o zostawienie telefonu kontaktowego – logiczne, zamierzali poinformować, że samochód jest gotowy do odbioru. Zostawiam samochód i idę na zakupy do okolicznego centrum handlowego. Po około 1,5 godziny, gdy wracam do serwisu, telefon z serwisu: “Jednak nie zrealizujemy zlecenia. Brakuje nam jednej rzeczy, jest w systemie, ale nie ma na stanie”.

W myślach pojawiło się tylko “Ups. Chyba coś jest nie tak z ich procesem obsługi.”. Takie stwierdzenie ani dobrze nie brzmi w oczach klienta – mamy, ale nie mamy. I potem to wahanie co mogą zaproponować. Umawiamy się na kolejną wizytę i tylko taki niepokój, że może jeszcze coś wyjdzie. Na pytanie “czy umówionego dnia załatwimy wszystko?”. Nastąpiła chwila ciszy i po dłuższym wahaniu: “Tak”.

Realizowany proces (w BPMN) można zaprezentować następująco:

serwisauto450

Na powyższym diagramie został oznaczony linią przerywaną krok, którego w powyższym przykładzie raczej zabrakło. Potrzebne było określenie, czy są dostępne wszystkie elementy potrzebne do realizacji zlecenia. Elementy zlecenia można potraktować jako wejście procesu. Gdy nie ma wszystkich wymanych elementów, proces nie będzie efektywny. Dla tego serwisu jest to jeden z kluczowych procesów i opisany przypadek może jedynie spowodować, że klient więcej z usług tego serwisu nie skorzysta. Mało tego będzie się zastanawiał, czy w związku z tym problemami nie powinien otrzymać jakiejś rekompensaty (było czuć podczas rozmowy telefonicznej, że nie czują sie komfortowo z tą sytuacją).

Co ciekawe w innym oddziale sieci, wykonali ten krok i na starcie powiedzieli czego im brakuje do realizacji potencjalnego zlecenia. Proces był sprawny. Z punktu widzenia odbiorcy był także efektywny – wskazali jak możemy zrealizować zlecenie i gdzie. Chcąc osiągnąć efektywny i sprawny proces, konieczny jest wskazany krok w każdym oddziale.

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.

Proces raportowania a entropia informacyjna

Po obejrzeniu filmu Lot 93, zacząłem się zastanawiać nad tym, że w przypadku zdarzeń wyjątkowych/obserwacji istotne znaczenie ma właściwa komunikacja i proces przekazywania informacji o tym. Każda kolejna osoba, która otrzymuje tę informacje, dopytuje, potwierdza, chce dowiedzieć się więcej. Czy to oznacza, że entropia informacyjna danej organizacji (np. Centrum Obsługi Lotów bądź innej jednostki) rośnie? Moim zdaniem tak. Zgodnie z interpretacjami dotyczącymi entropii, to mówimy przede wszystkim o komunikacji bieżącej, poszukiwaniu informacji (odpowiedzi) a nie samym korzystaniu z zapisanych źródeł informacji. Na fakt występowania entropii informacyjnej w organizacji zwrócił mi uwagę jeden z czytelników bloga pod wpisem „Komunikacja jako efekt procesu”. Taka informacja, przekazywana i analizowana, jest wejściem do procesu i z punktu widzenia poszczególnych jej „uczestników posiada pewien status„. Zastanówmy się jak mógłby wyglądać proces raportowania takiej informacji.

Załóżmy, że mamy ścieżkę raportowania Pracownik Lokalny->Manager Lokalny->Władze Lokalne->Łącznik -> Władze Globalne. Każdy z nich oznaczony jest innym kolorem na diagramie. Statusy informacji, zgodnie z ich „autorem” są również oznaczone kolorami. Statusy „Do uzupełnienia” oraz „Uzupełnione” są opcjonalne – wystąpią, gdy pojawi się pytanie przy przekazywaniu dalej, które należy wyjaśnić z inicjatorem procesu. Podobnie może wystąpić to na wyższym poziomie raportowania. Ramką na diagramie została zaznaczona komunikacja / przejścia informacji, zachodząca między Managarem Lokalnym a Władzami Lokalnymi, między Władzami Lokalnymi a Łącznikiem i między Łącznikiem a Władzami Globalnymi. Na wyższych poziomach mogą też nie wystąpić niektóre statusy. Każdy z uczestników może zadać nowe pytania i skierować uwagę na kwestie, które wcześniej nie zostały poruszone. Można powiedzieć, że po wykonaniu każdego z przejść entropia informacyjna rośnie? Chyba tak.

Materializacja ryzyka jako „inicjator” procesu

Załóżmy, że został wdrożony system informatyczny wspierający główne procesy biznesowe. W trakcie realizacji projektu, w ramach Rejestru Ryzyk, który jest jednym z elementów zarządzania ryzykiem, umieszczono ryzyko „błędne wykorzystanie aplikacji”. Ryzyko to zostało wskazano jak możliwe do wystąpienia po wdrożeniu systemu. Odpowiedzialność za to ryzyko ponosi właściciel systemu/danego procesu biznesowego.

W trakcie realizacji procesu biznesowego, użytkownik napotkał na problem i zgłosił go – nastąpiło wejście (w rozumieniu diagramu SIPOC) do procesu obsługi błędów. Problemem zajął się użytkownik i okazało się, że problem nie wynika z błędu systemu a z błędnego wykorzystania systemu przez użytkownika. Błędne wykorzystanie systemu – materializacja ryzyka – mogła nastąpić z niewiedzy, niekompletnych lub niezrozumiałych materiałów, braku wykorzystania dostępnych procedur itp.

Można powiedzieć, że materializacja ryzyka zainicjowała nowy proces – zaprezentowany na poniższym przykładowym diagramie BPMN.

Wejściem do procesu jest zgłoszenie błędnego wykorzystanie systemu, które powinno zostać wyjaśnione przez właściciela biznesowego procesu głównego, na przykład poprzez rozszerzenie materiałów pomocniczych, procedur lub dedykowaną komunikację.

We wskazanej sytuacji przygotowanie odpowiednich materiałów jest działaniem zmniejszającym wpływ tego ryzyka. Jednakże rzeczywistość biznesowa jest zawsze bardziej zróżnicowana niż przypadku opisane w materiałach czy procedurach. Często konieczna jest ich modyfikacja po jakimś czasie w wyniku zgłoszeń użytkowników końcowych czy obserwacji pierwszych linii wsparcia. Czasami następuje to również w wyniku materializacji ryzyka.

PROCA, czyli proces zarządzania ryzykiem

Dzisiejszy wpis będzie trochę odbiegał od poprzednich. Jednakże pozwoli na wprowadzenie dodatkowego elementu w przedstawianiu przykładów oraz spojrzeń na procesy biznesowe oraz ich modele. Chciałbym dodać element ryzyka. Nie chciałbym tłumaczyć co oznacza ryzyko, niepewność (można o tym przeczytać w wielu publikacjach w internecie)

W publikacjach na temat zarządzania ryzykiem, pojawia się następujący proces (cykl) zarządzania ryzykiem:

  1. Identyfikacja ryzyka
  2. Ocena ryzyka
  3. Wybór i planowanie reakcji na ryzyka
  4. Monitorowanie i kontrola

Poniższy diagram (przy użyciu notacji BPMN, oddając bardziej ideę niż przepływ procesu) prezentuje moje podejście do procesu zarządzania ryzykiem – PROCA.

Podejście to, składające się poniższych kroków pochodzących z rozwinięcia liter nazwy – PROCA – można wyjaśnić następująco:

  • Przygotowanie – w ramach którego nastąpi identyfikacja ryzyk, ich ocena oraz wybór właściwej metody postępowania w celu zapobieganiu zdarzeniom bądź umiejętności radzenia sobie w sytuacji, gdy określone zdarzenie wystąp
  • Realizacja – krok procesu, którego celem jest postępowanie zgodnie z przygotowanym i co ważne zakomunikowanym planem działania. Na powyższym diagramie wejściem do procesu „Realizacji” są dwa elementy – zakończenie prac przygotowawczych lub/i wystąpienie zdarzenia ujętego podczas identyfikacji ryzyk.
  • Obserwacja – bardzo ważny krok procesu, w którym uczestnicy działań projektowych lub prowadzonej działalności operacyjnej, obserwują otoczenie pod kątem zakomunikowanego planu, a także możliwych do pojawienia się nowych szans lub zagrożeń. Świadomość zmieniającego się otoczenia i tego, że decyzje są podejmowane w warunkach niepewności, pozwala na zmniejszenie ryzyka braku realizacji zaplanowanych celów. Przy wejściu do tego kroku, na diagramie pojawia się zdarzenie związane z czasem. Obserwacja może odbywać się także w sposób uporządkowany, na cyklicznych spotkaniach, podczas kŧórych następuje przegląd dotychczasowych działań oraz ewentualnie burza mózgów o obserwacjach, sugerowanych zmianach.
  • (Ciągła) Aktualizacja – wyniki obserwacji, zebrane informacje zwrotne od uczestników procesu, powinny być przeglądane i analizowane pod kątem wpływu na wcześniej zakomunikowany plan działania. Jeżeli okaże się, że konieczne jest dostosowanie, powinno zostać wykonane i przekazane do realizacji. I w tym momencie pojawia się pętla, której zakończenie jest związane z końcem projektu (o ile pewne ryzyka nie zostały przeniesione na proces wykorzystujący produkty projektu) lub zmianą przebiegu, warunków realizacji procesu. Stąd właśnie przy określeniu tego kroku oraz w samej nazwie podejścia słowo „Ciągła”.

Tak określony sposób postępowania kładzie nacisk na 3 aspekty:

  • zmienność otoczenia i konieczność jego obserwacji
  • to, że plan postępowania nie jest stworzony na zawsze i powinien podlegać weryfikacji.
  • to, że nieodłącznym procesem tego procesu jest komunikacja

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