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.

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.

Reklama

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.

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.

Czas akcji

Posiadana przeze mnie domena z kończącą się ważnością i powiadomienia od operatora domeny zainspirowały mnie do dzisiejszego wpisu. Nie było w tym nic dziwnego, ale  otrzymałem kilka różnych wiadomości dotyczących mojej domeny w temacie jej przedłużenia, które skłoniły mnie do przemyśleń. Zacząłem się im przyglądać kiedy przyszły i jakie akcje mogłem wykonać na danym etapie obowiązywania domeny. W całym okresie poprzedzającym zakończenie ważności domeny mogłem wykonać takie akcje jak: czekać, opłacić domenę z wyprzedzeniem, zrezygnować z domeny, poprawić dane, anulować zamówienie itd. Poniższy diagram prezentuje te możliwości w odpowiednich odcinkach czasu (trochę uogólniony).

Dodatkowo na diagramie dodałem informację o tym kiedy podjąłem zdecydowaną akcję – na niebiesko – zrezygnowałem z przedłużenia domeny. I z perspektywy oceniam, że komunikaty zaznaczone na czerwono są zbędne (o nadmiarowych statusach pisałem również w innym wpisie). Wskazałem w systemie, że nie chce przedłużać domeny (musiałem to potwierdzić). Cennym komunikatem – na zielono – był ten potwierdzający skuteczność rezygnacji z domeny (bo zaznaczenie braku chęci do jedno, a sam fakt wyłączenia domeny to drugie). Co ciekawe otrzymałem jeden komunikat, mówiący o upłynięciu terminu płatności za domenę po terminie jej ważności – moim zdaniem ten komunikat może spowodować pewien niepokój u Klienta, że jednak nie wszystko odbyło się zgodnie z oczekiwaniami i będą konieczne jakieś wyjaśnienia lub jednak opłacenie faktury.

Myślę, że taki proces w przybliżeniu, ma miejsce w przypadku różnych subskrypcji, usług z określoną ważnością, automatycznie lub „ręcznie” przedłużanych, płatnych jednorazowo z dany okres lub automatycznie opłacanych w odstępach czasu (te odstępy są istotne przy zgłoszeniu ewentualnej rezygnacji). Niektóre podmioty wysyłają wiadomość raz z listą możliwych akcji do wykonania, a potem z potwierdzeniem wybranej akcji. Inni komunikują każdy etap a inni z kolei pozostawiają pełną kontrolę klientowi usługi (zgodnie z zapisami regulaminów) i jedynie potwierdzają (lub nie) wykonanie określonej akcji (bo w sumie wszystko widać w systemie, który udostępnia operator, choć z tym bywa różnie – nie mam dostępu do podglądu pewnych ustawień w jednym z takich systemów, gdy nastąpiła jego migracja na inne/nowsze rozwiązanie).

Okresy między akcjami do wykonania, powiadomienia są specyficznym elementem danego systemu. Podmiot projektujący system, a dokładnie powiadomienia z procesu, ustawia co i w którym momencie wysyła. Patrząc na diagram BPMN może to być zdarzenie czasowe, np. przypadające na 1 dzień miesiąca lub określoną godzinę dnia (tak jest w przykładzie powyżej), dzień tygodnia, informujące wszystkich odbiorców, którym się kończy wykupiona usługa w następnym miesiącu lub za określony czas (np. X dni). Taki przykładowy proces został zaprezentowany na powyższym diagramie. W tym przypadku składa się z określenia listy usług, komunikatów do wysłania i ich wysyłki (komunikaty A-F).

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.

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.

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.

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:

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.

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

• zweryfikować kroki będące objawami marnotrawstwa – np. zbieranie podpisu od klienta,
• określić kroki tworzące wartość dodaną – np. możliwość pożyczenia żelazka,
• wykorzystać doświadczenia reinżynierii lub benchmarkingu proccesów – wystarczyłoby odwiedzić inny hotel i zobaczy jak rozwiązał proces.

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.