Czas realizacji procesu – przykład

Ostatnio opisywałem różne przypadki, z którymi się spotkałem podczas realizacji procesu zamówienia złożonego w sklepie internetowym. Każde złożone zamówienie do mnie dotarło, więc jestem zadowolony, ponieważ prezenty dotarły. Czas ich realizacji od momentu złożenia zamówienia do otrzymiania przesyłki był różny. W zależności od dostawcy, w ramach procesu dostępne był mniej lub bardziej rozbudowane narzędzia do monitoringu przesyłki.

Wybrałem jeden z przypadków, aby pokazać różne czasy realiazcji procesu, bazując z jednej strony na powiadomieniach mailowych, a z drugiej na informacjach zawartych na stronie do śledzenia przesyłki. Kluczowe daty/godziny dla zrealizowanego procesu zostały zaprezentowane na diagramie.

czas_realizacji450px

Na łączny czas dostarczenia przesyłki, patrząc na proces od początku do końca, składały się:

  • z punktu widzenia nadawcy przesyłki, działania wykonane w czasie T1 (między od 2017-11-19, g. 21:15 do 2017-11-20, g. 19:10), od momentu złożenia zamówienia do jej nadania u operatora,
  • z punktu widzenia operatora dostaraczającego przesyłkę – T2 (między 2017-11-20, g. 19:10 a 2017-11-22, g. 16:00), tj. do momentu dostarczenia przesyłki do punktu odbioru. W tym czasie mogły być wykonywane działania takie jak: transport przesyłki między punktami pośrednimi, przyporządkowanie przesyłki do kanału/kierunku dostawcy, oznaczenie statusu przesyłki itp.
  • czas oczekiwania na odbiór przesyłki z punktu przez klienta – T3 (między 2017-11-22, g. 16:00 a 2017-11-22, g. 19:40). Maksymalny czas oczekiwania przesyłki w punkcie: 5 dni roboczych.

Łącznie proces zajął TC (od 2017-11-19, g. 21:15 do 2017-11-22, g. 19:40), będacy sumą powyższych czasów. Na bazie tych informacji można byłoby określić także czas rzeczywistego (TR) przebiegu procesu, bez uwzględniania czasu oczekiwania, ponieważ zależy od tego, kiedy będę mógł udać się po przesyłkę (najlepiej jak najszybciej, ale nie przekraczając czasu, gdy przesyłka będzie czekać na odbiór). Informację o tym, że przesyłka oczekuje na odbiór, można potraktować jako moment zakończenia procesu.

Na powyższym diagramie można byłoby określić jeszcze T0, w czasie którego wybierałem produkt, określałem sposób dostawy, płatności a następnie potwierdziłem i opłaciłem zamówienie. Niestety nie policzyłem ile czasu zajęło mi złożenie zamówienia. Z punktu widzenia sklepu internetowego, do momentu potwierdzenia zamówienia ten czas nie jest istotny, o ile składanie zamówienia odbywa się w sposób i w czasie akceptowalnym przez użytkownika. Jeżeli czas się wydłuża ze względu na błędy systemu lub problemy z aplikacją, taka informacja mogłaby być cenna dla sklepu internetowego.

Jeżeli użytkownik loguje się do systemu, to można byłoby policzyć czas od ostatniego logowania do złożenia zamówienia lub czas od umieszczenia zamówienia w poczekalni do jego rzeczywistego zamówienia, W powyższym przykładzie skupiłem się na czasie upływającym od momentu, gdy następuje wskazanie konkretnego zamówienia do realizacji.

Czas realizacji a “szybkość” procesu

Składając różne elementy procesu, o których pisałem na blogu, można utworzyć uogólniony proces, który:

  • zmienia wejścia procesu w wyjście procesu, na co zwracana jest uwaga w modelu SIPOC.
  • ma wejścia i wyjścia procesu, uzależnione od rodzaju procesu.
  • posiada kroki dodające wartość dla odbiorcy procesu (kroki oznaczone na diagramie jako VAP) lub tylko dla innych interesariuszy zainteresowanych (kroki na diagramie oznaczone jako VAI) procesem.
  • obsługuje wyjątki lub alternatywne ścieżki przebiegu procesu.

Każdy realizowany proces można opisać za pomocą jego czasu realizacji, czyli Delivery Cycle Time. Wartość ta informuje jak długo trwa proces od jego zainicjowania przez Klienta, na przykład poprzez złożenie zamówienia, dostarczenie dokumentu, złożenie zapytania, po zakończenie procesu, rozumiane jako dostarczenie produktu, na przykład przedmiotu zamówienia, akceptacji dokumentu, odpowiedzi na zapytanie.

szybkosc450px

Wartość ta interesuje nie tylko odbiorcę procesu, ale także księgowość, inwestorów oraz inne grupy interesariuszy. Biorąc pod uwagę powtarzalność procesu, najlepszą sytuacją, gdy w danym czasie, na przykład miesiąca, można zrealizować kilka, kilkanaście lub więcej przebiegów procesu.

Na bazie tych informacji można byłoby spróbować obliczyć “szybkość” procesu. Dostarczając 1 produkt w czasie T, możemy potencjalnie policzyć liczbę dostarczanych produktów, obsługiwanych zamówień w czasie jednostki czasu, np. miesiąca, czyli [Miesiąc/T] sztuk/per miesiąc.

Sformułowanie “szybkość” używam w cudzysłowach, aby zaznaczyć potoczne rozumienie tego słowa, przez porównanie na przykład do szybkości drukowania (10 kartek/minut). Obok tego pojęcia funkcjonuje także pojęcie “prędkości” (wartości z wektorem). W przypadku procesów pojęcia te też podlegają próbie rozróżnienia, wychodząc od pojęć z terminologii angielskiej.

Różne „rodzaje” czasu procesu

Analizując proces można spojrzeć na niego z punktu widzenia czasu jego przebiegu. W zależności od tego punktu zainteresowania można wyróżnić różne „rodzaje” czasu. Rozróżnienie czasów zostanie przedstawione na dwóch przykładach. Pierwszy jest związany z przygotowaniem raportu, a drugi z obsługą zakupów on-line.

Wg literatury można wyróżnić:

  • całkowity czas przebiegu procesu,
    w przykładzie z przygotowaniem raportu (proces A) – będzie to czas od pierwszego sprawdzenia dostępności danych do odbioru raportu;
    w przykładzie z obsługą zakupów online (proces B) – będzie to czas od przełączenia na szyfrowane połączenie do realizacji zamówienia;
  • czas „oczekiwania”, czyli czas od zakończenia realizacji jednego procesu do rozpoczęcia następnego:
    proces A – to czas od oddania raportu, do pierwszego sprawdzenia dostępności danych przed kolejnym raportem;
    proces B – to czas od realizacji danego zamówienia, do obsługi kolejnego zamówienia;
  • łączny czas zadań przynoszących wartość dodaną:
    proces A – są to kroki procesu zmierzające do dostarczenia raportu, a nie będące przejawem marnotrawstwa w procesie. Szczegóły we wpisie.
    proces B – są to kroki procesu, oznaczone we wpisie kolorem zielonym, jak np. zebranie danych o kliencie, wybór sposobu dostawy, rozliczenie.
  • łączny czas zadań, które nie przynoszą wartości dodanej:
    – zarówno w procesie A, jak i B są to wszystkie kroki nie wskazane powyżej. Co istotne patrzymy tutaj tylko z perspektywy wartości dla klienta. Kroki w procesie mogą przynosić wartość innym grupom interesariuszy zainteresowanych procesem, a także powodować ewentualny wzrost wartości w przyszłości.

Czas realizacji procesu a liczba osób

Załóżmy, że mamy do wykonania określoną ilość prostych produktów, będących efektem wykonania 3 zadań, z których kolejne jest uzależnione od wykonania poprzedniej czynności. Czynności te mogą być wykonywane w kolejności zadanie 1, zadanie 2, zadanie 3 dla produktu 1, zadanie 1, zadanie 2, zadanie 3 dla produktu 3 itd. Mogą też być wykonane w kolejności zadanie 1 dla produktu 1, zadanie 1 dla produktu 2 itd, zadanie 2 dla produktu 1, zadanie 2 dla produktu 2 itd. oraz zadanie 3 dla produktu 1, zadanie 3 dla produktu 2 itd. Jak przykład można podać wysyłkę listów, dla której możliwe są 2 scenariusze lub składanie rowerów, co przytacza artykuł „The Product-Process Matrix Using the Right Process for the Volume of Work You’re Doing” na stronie MindTools.com.

We wskazanym artykule pojawia się opcja podziału zadań procesu na osoby wraz z zaletami i wadami takiego rozwiązania. Zastanówmy się jednak jak na czas realizacji zadania wykonania wspomnianych produktów wpłynie liczba zaangażowanych osób. Dla ułatwienia załóżmy, że zadanie 1 trwa 2 JT (jednostki czasu, nie wnikając, czy są to godziny, minuty czy dłuższy okres czasu), zadanie 2 trwa 4 JT a zadanie 3 trwa 1 JT. Łączny czas przygotowania produktu to 7JT, czyli przy 100 produtkach konieczne jest 700 JT. Równocześnie jest to okres czasu potrzebny na wykonanie produktów przez jedną osobę, niezależnie od tego, czy wykonuje zadania pierwszym wariantem (zadanie 1->zadanie 2->zadanie 3) czy drugim (zadanie1, zadanie 1…, zadanie 2, zadanie 2…, zadanie 3, zadanie 3…).

Poniższy diagram prezentuje możliwe sytuacje (nie są to wszystkie możliwości):

Analizując wskazania czasu realizacji oraz czasu oczekiwania na zadania można zadecydować, który wariant należy wybrać. Biorąc pod uwagę czas potrzebny na realizację od momentu rozpoczęcia do momentu zakończenia to najlepszy jest wariant 3. Jednakże, osoba 3 najdłużej czeka na wykonanie swojego zadania dla poszczególnych produktów. Z kolei w wariancie 3, mamy najkrótszy czas oczekiwania na zadanie, tylko 2 TJ, ale niestety czas realizacji jest o 99 TJ dłuższy niż wariantu 3, ale nadal jest krótszy niż wariantu 1 czy 2.

Wskazany czas oczekiwania nie zmienia się, gdy realizacja zadania przez osobę 2 w wariancie 2 i osobę 3 w wariancie 4 zostanie tak przesunięte, że zacznie wykonywać pracę w możliwie najpóźniejszym terminie, ale tak, aby ostatnie zdanie wykonać zaraz po przekazaniu efektów dla ostatniego produktu od osoby poprzedniej.

Wybór wariantu nie jest prosty. Jeżeli jedynym kryterium będzie czas realizacji to kwestia jest prosta. Jeżeli pojawi się kwestia liczby osób i możliwości ich zaangażowania (np. ostatnie dni realizacji lub pierwsza połowa okresu realizacji) to ciekawsze mogą być warianty 2, 3 lub 4. Tak jest w przypadku liczby zaangażowanych osób mniejszej bądź równej liczbie jednostkowych zadań.

A co byłoby gdyby dodać kolejną osobę, która wykonywałaby któreś z zadań? O tym … w osobnym wpisie.

Oczekiwane statystyki czasu realizacji

Pozostając w wątku zakupów internetowych, dziś ponownie nawiąże do wiadomości e-mail, którą otrzymałem. W tym samym tygodniu, co ankietę, otrzymałem maila od innego sklepu, w którym zwykle robię takie zakupy, ale ostatnio czas realizacji zamówienia nie był dla mnie akceptowalny. Nastąpiło wydłużenie czasu od złożenia zamówienia do nadania przesyłki przez sklep. Wcześniej były to 1-2 dni, a ostatnio nawet tydzień. Po otrzymaniu tej wiadomości, dałem im szansę, bo w ofercie mają kilka produktów, których nie ma ten drugi sklep (czyli szerokość oferty  bardziej mi odpowiada). A może nie miałem wyjścia?

Treść wiadomości zawierała sformułowania typu „Zdajemy sobie sprawę, że nasz serwis w tym okresie mógł zawieść Twoje oczekiwania […] mamy nadzieję, że te chwilowe problemy nie wpłyną na dotychczasowe zaufanie.[…] Przywróciliśmy standard realizacji zamówień – wysyłamy przesyłki w ciągu 1-2 dni roboczych od złożenia zamówienia. […]”. Na koniec było odesłanie do serwisu ze wskazanymi czasami realizacji.

czas_realizacji450px_v3

Na diagramie, który zamieściłem kiedyś we wpisie z przykładami czasu realizacji (powyżej), zaznaczyłem miejsce, które sklep pewnie monitorował i zauważył, że nastąpiło jego znaczne wydłużenie. Taka obserwacja jest prosta do monitorowania – wystarczy badać czas między zapisem/złożeniem zamówienia (czas zapisu/złożenia – Z) a czasem odnotowania nadania przesyłki (czas nadania – N). Obydwie informacje przychodzą w wiadomości e-mail w postaci statusów, więc muszą być także odnotowane w systemie.

Sklep może prowadzić dzienny monitoring czasu realizacji zamówienia (N-Z) w zakresie maksymalnej wartości, minimalnej, mediany, dominanty czy średniej (pojęcia wyjaśnione poniżej). W zależności od rozkładu tych wartości, może podejmować odpowiednie decyzje lub zaplanować właściwe kroki. Jeżeli wartości wykraczające poza 1-2 dni są sporadyczne pewnie nie wymagają pilnych akcji.

Gdyby zobrazować na wykresie częstość występowania poszczególnych czasów realizacji dobrze byłoby, gdyby wykres był prawostronnie skośny (co zostało zaprezentowane na diagramie). Oznacza to, że większość wartości jest na początku przedziału 1-2 dni, a mniej powyżej 2 dni.

Rozkład prawostronnie skośny to taki rozkład, w którym zachodzi nierówność dominanta < mediana < średnia, czyli

  • [średnia:] średni czas realizacji zamówienia jest wyższy niż
  • [mediana:] czas realizacji zamówienia, który dzieli wszystkie pomiary czasu na 2 równe części co do występowania, a ten jest większy od
  • [dominanta:] czasu, który występuje najczęściej w rozkładzie czasów realizacji.

 

Zdrowe skutki procesu

Dzisiaj będzie nietypowo – o jedzeniu. Nie myślałem, że wyjazd na święta i spotkania przy świątecznym stole skończą się dyskusją o zdrowym żywieniu, składzie pokarmów, tych zdrowych i tych mniej zdrowych. Moment na dyskusję o tyle ciekawy, że świąteczne potrawy pewnie patrząc pod różnym kątem, mogą zostać przyporządkowane zarówno do tych zdrowych, jak i do tych mniej. Zależy to od okoliczności, ilości, ale i także czasu oraz środków przeznaczonych na przygotowanie potraw. Jednakże najciekawsza była puenta dyskusji.

Okazało się, że istnieją aplikacje na komórkę, które korzystając z dostępnego połączenia internetowego, na podstawie kodu kreskowego produktu (nie wszystkich) są w stanie wskazać jakie “środki” chemiczne (konserwanty, wzmacniacze smaku lub inne) znajdują się w danym produkcie (od sosów, przez przekąski po inne produkty kończąc). Z perspektywy użytkownika proces realizowany w aplikacji, wspierający – można tak to ująć – zdrowie żywienie, został zaprezentowany na poniższym diagramie.

zdrowy_proces_418px

Taka aplikacja (jedną z nich testowałem “w swojej kuchni”) wymaga dostępu do internetu (warunek wejściowy przy uruchomieniu), więc pewnie ma dostęp do jakiejś  bazy odpytywanej za pomocą łącza internetowego – aplikacja pozwala również na definiowanie produktów oraz przeglądanie poprzednich skanów. Każdy odnaleziony produkt jest prezentowany za pomocą listy składników (tzw. “E” oraz innych), z oznaczeniem ich charakteru – korzystny, obojętny, podejrzany, szkodliwy itd. Równocześnie podaje krótką informację o danym elemencie – sposób pozyskania oraz wpływ. Dla pewnych produktów pozwala na zapoznanie się z produktami alternatywnymi.

Korzystanie z aplikacji jest bardzo proste, można korzystać z niej w dowolnym miejscu, a integracja aplikacji z lampą/latarką komórki, pozwala także na odczytanie kodu w słabszych warunkach oświetleniowych. Wydaje się to bardzo pouczające – z jednej strony dowiadujesz się, czy jakiegoś produktu lepiej unikać, z drugiej można określić, czy przypadkiem jakieś dolegliwości nie wynikają akurat ze spożycia większej ilości produktu, zawierającego składnik potencjalnie je powodujący. Można także potwierdzić, że dany produkt zawiera jedynie „korzystne” składniki.  Efektem z realizacji procesu wspieranego przez aplikację jest “lepsze” zdrowie lub spożywanie bardziej zdrowego jedzenia.

Podany przykład aplikacji pokazuje jak technologia może wspierać codziennej życie. Komórkę mamy przeważnie na zakupach ze sobą, tym bardziej, że wielu użytkowników korzysta również z aplikacji komórkowych do budowania listy zakupów czy z mechanizmu przypomnień o określonych zakupach.

„Dziennik” procesu

W zwykle w dzienniku zapisujemy wydarzenia z życia codziennego, grupy, jednostki lub innego podmiotu. Pod każdą datą lub/i godziną mamy informację o tym, co się wydarzyło, jakie były komentarze, kto brał udział itd. Potem po jakimś czasie możemy przeglądać dziennik, dzielić się z nim, analizował co, kiedy się wydarzyło i ile trwało. Wszystko zależy od tego z jaką skrupulatnością jest on prowadzony. Jeżeli jest to osobisty dzienny, wszystkie zapisy dotyczą jego właściciela, ale nie muszą. Mogą wskazywać także innych uczestników.

Dziennik na podobnych zasadach może zostać utworzony dla realizowanego procesu biznesowego. Taki przykładowy , uproszczony proces przy użyciu czynności wykonywanych zarówno ręcznie, jak i przez użytkownika w systemie został zaprezentowany na diagramie. Użytkownik wykonuje kolejne zadania w ramach procesu. Aplikacja obsługująca proces zapamiętuje pewne fakty o wykonywanych czynnościach. Dane zadanie, na starcie może odnotować fakt jego rozpoczęcia, a na koniec, fakt zakończenia, co zostało również zaprezentowane na diagramie. Pozostałe czynności składające się na dane zadanie mogą odkładać także inne informacje.

logowanie_1_450px

W takim „dzienniku” procesu mogą zostać zapisane jedynie podstawowe informacje: data i czas rozpoczęcia czy zakończenia poszczególnych zadań i użytkownik wykonujący. Mogą być to także dodatkowe informacje dotyczące okoliczności lub przedmiotu realizowanego procesu. Zapis informacji odbywa się bez angażowania użytkownika. Może zostać przeanalizowany na przykład przez administratora lub właściciela procesu.

Jak stosować zdarzenie error wewnątrz procesu?

W pracy korzystam z narzędzia napisanego w VBA (ang. Visual Basic for Applications) do generowania wynikowego pliku tekstowego z arkusza kalkulacyjnego. Jednym z kroków jest odczytanie liczby rekordów i przypisanie jej do zmiennej pomocniczej.

Podczas tworzenia narzędzia założyłem zmienną jako Liczba Całkowita (typ Integer). Podczas próby wykonania nowego raportu pojawił się błąd „overflow”. Oznacza on, że nie można przepisać wartości większej niż dopuszcza to typ pola (na diagramie zdarzenie błąd wartości). Po poprawieniu (zmiana na Long) mechanizm zadziałał poprawnie.

Podany przykład można byłoby zobrazować następująco na diagramie:

error_ev_pl1_450px
Na powyższym diagramie jest zaprezentowane zastosowanie zdarzenia tzw. intermediate o charakterze błędu (ang. error event), co powoduje przerwanie wykonania algorytmu. Obrazuje to zdarzenie końcowe z krzyżykiem.  Tego typu zdarzenie błędu umieszczamy na brzegu czynności mogącej spowodować błąd (na diagramie Odczytaj liczbę wierszy) i  łączymy z czynnością obsługującą (na diagramie Wyświetl komunikat) lub z zdarzeniem końcowym procesu.

Pytania o kroki procesu ręcznego

Podczas wizyty w hotelu, musiałem wypożyczyć żelazko. Udałem się do recepcji. Pytam, czy jest taka możliwość? Padła odpowiedź, że tak, ale trzeba zapłacić depozyt. Powiedziałem ok. Jak się okazało, najpierw trzeba było zapłacić, podać numer pokoju, poczekać na odnotowanie w papierach wypożyczenia żelazka, założenie oznaczenia na żelazku Potem przy zwrocie  żelazka trzeba było złożyć podpis, że nastąpił zwrot depozytu i żelazka. Natomiast przy oddawaniu klucza  sprawdzają czy nastąpiło rozliczenie pokoju. Dlaczego wypożyczenia żelazka i jego zwrotu nie odnotują w systemie? Podczas wymeldowania, można byłoby sprawdzić czy nastąpił zwrot żelazka.

Opisana zmiana to przejście od procesu w pełni ręcznego (obecnie stosowanego, tzw. as-is, oznaczonego na diagramie) do procesu wspieranego systemowo lub zautomatyzowanego (docelowego, tzw. to-be, oznaczonego na diagramie). System mógłby informować przy zwrocie klucza, że nie zostało ono zwrócone.

zelazko2

Podczas wykonywania takiej zmiany, zaczynamy od analizy bieżącego procesu, jego kroków. Można np. :

Można także zadać pytania, które sugeruje autor artykułu “Avoid Pains Converting a Manual to an Automated Process”:

  • Dlaczego dany krok jest ważny dla procesu?
    Np. na powyższym diagramie jest to powiązanie pożyczonego żelazka i numeru pokoju. Jest to wykonywane poprzez wpis do rejestru. Pozwala to zidentyfikować, gdzie są żelazka, kto jeszcze ich nie zwrócił.

  • Co się stanie jeżeli nie wykonamy danego kroku?
    Np. w powyższym procesie możemy nie pobrać depozytu. Ułatwia to obsługę klienta, nie musi mieć przygotowanej gotówki.

  • Czy miałoby sens, gdyby inny uczestnik procesu go wykonał?
    np.  zamiast ręcznego sprawdzania czy zwrócono żelazko, kontrola wykonywana przez system. na diagramie tego elementu nie oznaczono.

  • Czy istnieją procedury lub regulacje, których wymaga dany krok do wypełnienia przez tego uczestnika?
    W powyższym przypadku, gdy spytałem, dlaczego tyle formalności (ponieważ wystąpiła sytuacja, że gość hotelu nie zwrócił żelazka), odpowiedź, którą usłuszałem mogłem sobie wyobrazić – każą to robimy (czyli jest jakaś procedura).

  • Jeżeli procedury decydują o pełnym wykonaniu kroku, czy mogą zostać zmodyfikowane?
    Przenesienie działań do systemu, będzie wymagać zmiany procedury. Będą wykonywane inne kroki.

  • Jeżeli krok zostanie zautomatyzowany, co jeszcze musi zostać wykonane, aby mieć pewność, że krok jest poprawnie zakończony? Jest to uzależnione od zastosowanego rozwiązania.

Odpowiedź na pierwsze pytanie, to tak naprawdę określenie czego oczekujemy od procesu i czy obecny proces spełnia nasze oczekiwania. Wykonywanie procesu w takiej formie, bez zastanowienia się, bo tak mówią procedury, można powodować zdziwienie uczestników (=klientów) procesu. Takie zdziwienie wyraziłem.

Właściciel procesu – kto to taki?

Wyobraźmy sobie sytuację, że jesteśmy uczestnikiem procesu biznesowego, odbieramy wkład z wcześniejszych kroków, przetwarzamy go, rejestrujemy, weryfikujemy, a następnie przekazujemy dalej. Wiemy jaka jest wizja procesu, jaką wartość i komu proces przynosi. Pewnego dnia zdajemy sobie sprawę, że pewne kroki można zmienić i usprawnić przebieg procesu. Zgłaszając się z tym pomysłem do przełożonego lub innej okazji, może się okazać, że trzeba skontaktować się z właścicielem procesu. Bez jego zgody i zaangażowania proces nie ulegnie zmianie.

Kto to jest ten właściciel procesu?
Według słownika biznesowego, właściciel procesu (ang. process owner) to “osoba, która jest odpowiedzialna za wydajność procesu (ang. performance) podczas realizacji jego celów (ang. objectives), mierzonych przez wskaźniki oceny procesu (tzw. KPI). Osoba ta jest uprawniona do wykonania niezbędnych zmian”. Można powiedzieć, że zarządza procesem. W szczególności (streszczając wskazania z „Process Roles ‚Who are the Process Owners?'”):

  • definiuje jak ma przebiegać proces,
  • określa jaki ma przynieść efekt,
  • monitoruje i raportuje efektywność procesu,
  • ustala zmiany w procesie w porozumieniu z właścicielami innych powiązanych procesów,
  • odpowiada za zgodność procesu z oczekiwaniami biznesowymi,
  • sposnoruje rozwój procesu, przy przechodzi między kolejnymi pozomami dojrzałości procesu,

W ramach jednego z artykułów na ModernAnalyst.com, autorzy zastanawiali się nad tym, jak ważne jest właścicielstwo procesu biznesowego („The Importance of Business Process Ownership”). Artykuł wskazuje jakie są obowiązki właściciela procesu, za co odpowiada I z czym wiąże się ta rola. Porusza także ciekawy temat, że nie każdy chce być właścicielem danego procesu.

wlascprocesu450

Procesy najbardziej atrakcyjne szybko znajdują właścicieli. Procesy trudne, ryzykowne wymagają poszukiwań właściciela procesu. Artykuł wskazuje, że jest to wynikiem różnych elementów – od charakteru procesu po umiejętności danego potencjalnego właściciela kończąc. Biorąc pod uwagę zakres obowiązków, nie jest to łatwe zadanie. Na podstawie artykułu i własnych przemyśleń spróbowałem spojrzeć na te “chęci” w sposób przedstawiony na powyższym diagramie.

Powyższą macierz można byłoby rozwinąć, wskazując na zmianę od słabego procesu do atrakcyjnego, czyli poprzez wzrost wartości dla właściciela. Podobnie przesunięcia w górę i w lewo macierzy można byłoby dodać, ale następuje to jakby przez odwrotność zaznaczonych działań/obserwacji. Zaprezentowane podejście wynika z tego, że atrakcyjny proces zyska potencjalnego właściciela, a spadek jego “cech” powoduje, że trudniej jest go znaleźć (patrząc od strony organizacji).