Trochę inna analiza procesu

W trakcie nakładania metryk na proces (np. pod kątem BPMS), przedstawiony podczas wcześniejszej analizy, używana jest analiza wejść i wyjść procesów, a także próbuje się określić krytyczne punkty procesu. W trakcie analizy przebiegu procesu określa się punkty, w których można zebrać dane do oceny procesu, jego efektywności, czasu realizacji, powtarzalności, ilości wykorzystanych obiektów. Na poniższym diagramie zaprezentowano w sposób poglądowy (uproszczony) czas przebiegu procesu – miejsce startu i końca weryfikowanego fragmentu procesu. Podobnie można określić:

• liczbę zamówień;
• liczbę przesyłek;
• wagi przesyłek (średnia, łączna, mediana)
• liczbę oczekujących zamówień (wpływających w czasie realizacji poprzedniego);
• liczbę zrealizowanych zamówień;

Na podstawie pomiaru czasu (najdłuższy, najkrótszy, średni) można policzyć ilość czasu przypadającego na zamówienie, na przygotowanie przesyłki. Można to użyć do weryfikacji, czy dostępny czas pracy, biorąc pod uwagę zatrudnionych pracowników, jest wystarczający na realizację wszystkich zamówień złożonych w danym okresie czasu.

Reklama

BPMN – dalsza analiza procesu

Wśród pojęć w metamodelu zostały wymienione między innymi następujące:

• [punkt 1.] Zadanie Wejścia/Wyjścia (ang. Task I/O)
• [punkt 3.] Cechy jakości (ang. Quality Attributes)
• [punkt 5.] Strumień kontroli (ang. Control Flow)
• [punkt 6.] Kierowanie danymi (ang. Data Handling)
• [punkt 8.] Role (ang. Roles)
• [punkt 9.] Zdarzenia (ang. Events)
• [punkt 13.] Dane statystyczne (ang. Statistical Data)

Niektóre z nich – 1, 5, 6, 8, 9 – zostały wykorzystane na zamieszczonych diagramach podczas prezentacji warstwy implementacyjnej – cały proces oraz podproces.

Przykładowo:

• „Zadanie wejścia/wyjścia” to „ProduktDostarczony”
• „Strumień kontroli” to połączenie między krokami „Potwierdzenie zamówienia” a „Analiza danych zamówienia”
• „Kierowanie danymi” to połączenie między „Złożenie zamówienia” a „Przygotowanie zamówienia”
• „Role” to obiekt „Wykonanie: Pracownik”
• „Zdarzenia” to „Produkt dostępny”

Biorąc pod uwagę drugi z diagramów – tzn. podproces – można dodać do niego kolejne informacje: „Cechy jakości” oraz „Dane statystyczne”. Są to informacje, które można zebrać analizując wykonanie całego procesu. Istotne jest jednak to, aby w odpowiednich miejscach została zachowana informacja, która pozwoli na późniejszą analizę. Mogą to być następujące informacje:

• „data/czas rozpoczęcia” i „data/czas zakończenia” poszczególnych kroków;
• „oczekiwany czas wykonania określonych kroków” – aplikacja wspierająca wykonanie procesu może przypominać o zbliżających się terminach, bądź opóźnieniu;
• „wyjątki”/”niezaplanowane zdarzenia” – np. brak papieru w drukarce, wygaśnięcie umowy z pośrednikiem. Mogą to być bardziej lub mniej trywialne zdarzenia.

Są to informacje, które mogą się znaleźć w szczegółowym opisie danego procesu, aby nie przepełniać podstawowego diagramu. W momencie zapisu daty/czasu może nastąpić porównanie z założonymi czasami realizacji procesu. Takie elementy zostały zaprezentowane na poniższym diagramie.

Sieć wyzwań dla procesu

Brak właściciela, przeładowany krokami nie wnoszącymi wartości dodanej, bez metryk, niespełniający oczekiwań odbiorcy … to tylko cztery wyzwania, które stoją przed procesami biznesowymi, spośród 11 wymienionych w artykule, na który ostatnio trafiłem – chodzi o artykuł „The 11 most common business process challenges and how to defeat them”, który polecam (skłania do refleksji). Wymieniłem te 4 wybrane, ponieważ o tych między innymi wielokrotnie pisałem na swoim blogu w różnym ujęciu:

• o właścicielu procesu i jego roli,
• o krokach istotnych dla procesu, jak i tych, które nie wnoszą wartości dla procesu (dla poszczególnych kroków można określić dla kogo są te kroki), czy można je pominąć czy może wartość, którą w noszą jest zauważalna,
• o metrykach, efektywności czy sprawności procesu,
• o niespełnionych oczekiwaniach.

Wszystkie wymienione (wyzwania, stąd (CXX) od ang. Challenge, oznaczenia wykorzystane na diagramie) we wskazanym artykule to (pozwalam sobie je przytoczyć w formie listy bo nie ja je wymyśliłem i zebrałem, zachowując oryginalne nazwy – w sprawie szczegółów odsyłam do wskazanego powyżej artykułu, gdzie każdy podpunkt jest dokładnie opisany; tłumaczenia dodane pomocniczo w nawiasach): „

• (C1) Business process not defined (proces nie jest zdefiniowany),
• (C2) Business process not owned (proces biznesowy bez właściciela),
• (C3) Purpose not understood (cel procesu nie jest zrozumiany),
• (C4) Business process not followed (nikt nie podąża za procesem),
• (C5) Customer not understood (Odbiorca/Klient nie jest poznany/nie zostały poznane jego potrzeby),
• (C6) Supplier not understood (Dostawca nie jest poznany/uczestnicy nie rozumieją jego potrzeb/nie znają go),
• (C7) Cumbersome to execute (Proces jest uciążliwy do wykonywania),
• (C8) Loaded with non-value added work (Przeładowany pracą, która nie wnosi wartości dodanej),
• (C9) Performance not measured (Proces nie jest pomierzony pod kątem wydajności),
• (C10)  Not linked to strategy (Nie połączony ze strategią),
• (C11) Don’t understand what business they are really in (Brak zrozumienia dla biznesu, w którym funkcjonuje)”.

Po zapoznaniu się z artykułem, zacząłem się zastanawiać czy nie można stworzyć między nimi diagramu powiązań, wykorzystując do tego myślenie systemowe. Moim zdaniem pewne elementy pociągają za sobą inne:

• Ciężko na przykład mówić o zmierzeniu procesu (C9), jeżeli nie wiemy gdzie są granice procesu, jakie kroki się na niego składają (C1).
• Z racji, że to właściciel powinien pilnować tego jak funkcjonuje proces, czy jest zrozumiały i jakie są zależności między dostawcą, procesem a jego odbiorcą – czyli podejście SIPOC. Gdy jego zabraknie (C2) to proces dzieje się w „swojej” formie (C7) lub nie jest wykorzystywany wcale (C4). Elementy te zostały zaznaczone na czerwono (gdy nikt nie dba o proces, nie mierzy go, nie weryfikuje, nie dostosowuje do branży, to pojawiają się kolejne problemy).

Na diagramie wskazałem więcej takich powiązań. Skutkiem „kumulacji” różnych braków (wyzwań) jest to, że proces może być uciążliwy (C7) dla uczestników lub szukają oni obejść, nie chcą stosować się do przyjętych reguł lub przestają podążać wg procesu (C4) – zaznaczone na szaro na diagramie.

Zaprezentowane zależności to przykład mający na celu zobrazowanie idei, o której myślałem i bardzo subiektywne spojrzenie z mojej strony. Zachęcam moich czytelników do komentarzy i sugestii.  

Myślenie systemowe, o którym wspominam powyżej, pozwala na zaprezentowanie wpływu pewnych elementów na siebie, oznaczając zarówno kierunek, jak i rodzaj wpływu (pozytywny/negatywny). W powyższym przykładzie mamy oznaczenie konsekwencji jednego wyzwania (choć w momencie gdy wystąpi można je nazwać zaniedbaniem/luką) na inne. Połączone potęgują wrażenie chaosu oraz powodują narastanie kosztów czy długu technologicznego.

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.

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.

Dodanie produktu do procesu a jego sprawność

Ostatnie doświadczenia i lektura wpisu na jednym z blogów skłoniły mnie do przemyśleń dotyczących takich pojęć jak efektywność oraz sprawność procesu.

Załóżmy, że mamy proces składający się z zaplanowanych kroków: analiza sytuacji, przygotowanie opisu sytuacji, weryfikacja i akceptacja, przejście do kolejnego etapu – uszczegółowienia opisu i określenie rekomendowanych działań. Proces jest wykonywany w analogiczny sposób przez kilka zespołów, patrząc z tej samej perspektywy (ustalonej odgórnie), w zakresie właściwym danemu zespołowi, ale jest realizowany w różnym czasie. W momencie akceptacji można powiedzieć, że proces jest efektywny: dostarczył oczekiwany efekt – opis sytuacji. Załóżmy, że w momencie, gdy miało nastąpić przejście do kolejnego etapu, pojawia się nowe zadanie: określić powiązania między opisami przy równoczesnym opracowywaniu rekomendacji. Proces może i będzie nadal efektywny (otrzymamy oczekiwany efekt), ale jego sprawność – moim zdaniem – ucierpi.

Dany pracownik zamiast skupić się na dotychczasowym sposobie wykonania zadania w zaplanowanych terminach, będzie musiał wykonywać dodatkowe interakcje z innymi zespołami – co zostało zaznaczone na powyższym diagramie. Może to spowodować, że: nie wykona swojego zadania w terminie, zacznie zmieniać wykonaną pracę, nie będzie już działał tak sprawnie jak wcześniej. Każdy kolejny krok będzie wymagał od niego zastanowienia się, czy nie wymaga to dodatkowej analizy, zmiany miejsca realizacji.

Pojawiają się konflikty: ten zespół tę część chce zrobić wtedy, a ten w inny momencie. Inną część zaplanowali do wykonania w tym okresie, a potem dopiero przejdą do kolejnych zadań. Zamiast wykonywać swoją pracę pojawiają się dyskusje, które nie zawsze kończą się porozumieniem. Pomocne może sie okazać ustalenie priorytetów lub wydzielenie nowego zadania do dedykowanego zespołu. Interakcje mogą też spowodować nawrót do wcześniejszych analiz, ponieważ może wystąpić sytuacja, że jakieś założenie było błędne. Pierwotnie ustalone terminy realizacji mogą być nierealne, jakość produktów końcowych może nie spełnić oczekiwań lub wymagać dodatkowego etapu weryfikacji i akceptacji.

Kluczowe dane procesu

Kilkakrotnie w ramach swoich wpisów posługiwałem się pojęciem słownika danych będącego podstawą do reprezentacji danych dla procesu biznesowego, do jego realizacji, jak i oceny. Taki słownik definiuje poszczególne typy danychwystępujące w procesie, opisuje ich zastosowanie oraz reprezentację.

Poniższy przykład na diagramie (w BPMN) prezentuje zastosowanie różnych typów danych.

Rozróżniane są:

• dane kluczowe (ang. key data) – np. ID klienta czy produktu, dla którego realizowany jest proces. Na powyższym diagramie jest to IDProduktu oraz można również powiedzieć, że IDKlienta, ponieważ bez tych dwóch identyfikatorów nie da się przeprowadzić procesu.
• dane zawartości (ang. content data) – są dane przesyłane między usługami, przekazywane między kolejnymi krokami procesu, będace uzupełnienie dla danych kluczowych. Dane te mają również znaczenie, gdy wystąpi błąd w procesie, aby poznać kontekst błędu. Są to dane kontekstowe. Na powyższym diagramie jest to np. Ilość produktu, a także dodatkowe dane pobierane z bazy.
• dane sterujące (ang. steering data) – dane, na podstawie których określany jest przebieg procesu, w szczególności na bramkach decyzyjnych. Dane sterujące są także używane przez reguły biznesowe. Na powyższym diagramie jest to FProgramu, która decuduje o wykonaniu operacji aktualizacji danych klienta w zakresie wykorzystania/udziału w programie lojalnościowym.
• dane do oceny efektywności procesu (ang. KPI data) – dane pozwalające ocenić zachowanie procesu, obciążenie pracą w poszczególnych krokach, czas wykonania, ilość itp. Nie są zaprezentowane bezpośrednio na powyższym diagramie. W omawianym przykładzie mogłyby być to dane dotyczące np. ilości przypadków realizacji programu lojalnościowego, najczęściej wybierane produkty, czas odpowiedzi usług, problemy.

Świadomość danych „używanych” w procesie, pozwala lepiej go zrozumieć i ocenić. Analiza zachowania procesu, wskaźników efektywności, czasu przebiegu, pozwala na określenie niezbędnych zmian w procesie.

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.

Komunikacja jako efekt procesu

Ostatnio na blogu „Analiza systemowa”  przeczytałem artykuł „Nie ulec pokusie zadowolenia wszystkich”  i zacząłem się zastanawiać co poza wymienionymi krokami oraz wskazanymi w komentarzu można zrobić.

Pierwsza myśl to kwestia zarządzania ryzykiem, do czego można podejść zgodnie z PROCĄ, o której pisałem wcześniej. W szczególności ma to istotne znaczenie, gdy wchodzimy z nowym produktem, do nowej grupy odbiorców na danym rynku lub chcemy zaistnieć na nowym rynku. To, co może się wydarzyć na rynku lub „wrócić” w postaci informacji zwrotnej od użytkowników powinno być przedmiotem zarządzania ryzykiem. Np. Jednym z zagrożeń może być niewłaściwe wykorzystanie produktu lub nieprzyjęcie się produktu na rynku. Wskazane w komentarzu do artykułu pojawienie się substytutów także jest pewnym ryzykiem. Dla każdego zidentyfikowanego w ten sposób ryzyka można przygotować odpowiednią strategię postępowania i z dużym prawdopodobieństwem można powiedzieć, że nie będzie to akceptacja. Bardziej skłaniałbym się ku zapobieganiu. A co może tym pomóc? Właśnie druga kwestia, o której warto pamiętać…

Komunikacja. Wdrożenie produktu, począwszy od jego opracowania, przez przygotowanie po działania promocyjne jest swego rodzaju procesem. Na każdym jego etapie konieczne jest patrzenie przez pryzmat tego, co chcemy zakomunikować i komu. Powyższy diagram prezentuje odbiorców komunikacji i przykładowe mechanizmy wspierające. Spirala na środku diagramu wskazuje, że komunikacja inicjowana jest wewnętrz firmy, najpierw w kierunku pracowników, którzy powinni rozumieć po co i co zamierza firma stworzyć i dla kogo, wprowadzane są badania rynku itd. Jest to „proces” ciągły, który jest inicjowany, a jego efekty są wykorzystywane w procesie wdrożenia nowego produktu i usługi. Komunikacja na poszczególnych ramieniach trójkąta musi być spójna. Nie ma nic gorszego jak sytuacja, gdy klient, który zachęcony reklamą dowiaduje się od pracownika firmy, że jest inaczej. Wspomniana trójca czas, koszt oraz jakość określa również ramy działań związanych z komunikacją, ponieważ komunikacja też kosztuje i jest kosztem wdrożenia lub utrzymania rozwiązania produktu, może już nie samego projektu, ale jest zestawiana z osiąganymi korzyściami z produktu.

Czy stała opłata w outsourcingu jest decydująca?

We wpisie „Trochę inna analiza procesu”  próbowałem pokazać różne mierniki pozwalające na ocenę procesu, zarówno pod względem czasu realizacji, jak i ilości obsłużonych spraw. Podczas analizy procesu nie należy zapominać o koszcie procesu. Wyniki takiej analizy można wykorzystać w trakcie projektowania zmian w procesie zmierzających do poprawy jego efektywności.

Po przeczytaniu artykułu „Business Process Utility – The emerging plug-and-play model in Finance and Accounting Outsourcing”, zacząłem się zastanawiać, czy podobnego spojrzenia na proces nie można wykorzystać przy wprowadzaniu outsourcingu procesu. Dokładniej przy identyfikacji procesu do outsourcingu. Podczas wykorzystania outsourcingu w procesie kluczową rolę odgrywa tzw. Business Process Unit (BPU), jednostka, której zadaniem jest standaryzacja procesu i jego efektywna realizacja. Włączenie takiej jednostki wymaga odpowiedniego przygotowania umowy z jednostką obsługującą proces, w ramach której zostaną zdefiniowane odpowiedzialności, parametry jakości oraz koszt.

Poniższy diagram prezentuje przykładowe przejście na wykorzystanie takiej jednostki:

Korzyści z takiego przejścia w realizacji procesu można określić następująco:

• zastąpienie kosztów własnych, stałym kosztem za realizację procesu;
• jednorodna obsługa spraw przez dedykowaną jednostkę;
• w wielu sytuacjach większa automatyzacja procesu;
• spadek kosztów na utrzymanie infrastruktury potrzebnej do realizacji procesów;
• brak potrzeby inwestowania w rozwój technologii wcześniej wykorzystywanej w procesie;
• łatwiejsza komunikacja o przebiegu procesu;

Wadami wydają się:

• brak pełnej kontroli nad przebiegiem procesu;
• uzależnienie od jednostki zewnętrznej;
• wzrost ryzyka związanego z realizacją procesu;
• utrata stopnia indywidualizacji obsługi klientów/spraw na rzecz standaryzacji;
• możliwość wystąpienia negatywnego odbioru ze strony pracowników, dotychczas uczestniczących w procesie;

Reengineering – etapy w skrócie

Etapami składającymi się na proces reengineeringu są:

1. Identyfikacja procesów biznesowych, które zachodzą w firmie. Etap ten skupia się na identyfikacji procesów biorąc pod uwagę czas, koszt, znaczenie (priorytetu), problemy pojawiające się przy realizacji danego procesu. Należy także zdefiniować początek i koniec procesu. Więcej o tym etapie
2. Wybór procesu do reengineeringu. Firma nie jest w stanie podjąć się przeprojektowania wszystkich, czy też wielu procesów za jednym razem. Dlatego też musi wybrać określony proces. Więcej o tym etapie
3. Utworzenie zespołu reengineeringu. Wynikiem tego etapu jest określenie składu grupy roboczej, której zadaniem będzie przeprowadzenie reengineeringu.
4. Analiza procesu. Etap ten ma na celu określenie szczegółowego przebiegu procesu oraz określenie potrzeb klientów danego procesu.
5. Rekonstrukcja procesu. Odbywa się w całkowitym oderwaniu od procesu istniejącego.
6. Wdrożenie rekonstrukcji. Wdrożenie będzie przeprowadzane całościowo lub za pomocą projektów pilotażowych.