Rezygnacja z wykonania kroku procesu

Dzisiaj, po dłuższej przerwie wpis będzie ponownie o windach. Kilkakrotnie poruszałem ten temat. Najpierw w kontekście tego, gdzie powinna się ustawiać winda, aby przyjazd na żądanie był najkrótszy. Następnie o rozwiązaniu polegającym na tym, że numer piętra, na który chcemy jechać, wskazujemy przed wejściem do windy. W ostatnim wpisie, skupiłem się na nazewnictwie kroków, bazując na wcześniejszym przykładzie. Wpisy pokazywały różne aspekty odzworowywania rzeczywistości na diagramie procesu. Przejdźmy jednak do sedna…

Na wakacjach, w 9 piętrowym hotelu, były dość 2 szybkie windy, jednakże miały jedno ograniczenie – mimo, że w windzie mieściły się 4 osoby, rzadko był możliwy taki przejazd, ponieważ windy miały bardzo wrażliwy czujnik obciążenia. Powodowało to, że na każdym piętrze, w określonych porach dnia (np. kolacja) czekało dużo osób na windę. Winda co chwilę się zatrzymywała – a na danym piętrze nikt nie mógł wejść już do windy lub przed windą nikt nie czekał. Przeważnie rezygnował. W tym wpisie, chciałbym się skupić na tej rezygnacji. W skrajnej sytuacji, zjazd z 9 piętra mógł oznaczać zatrzymanie się na każdym piętrze. Wyobraźmy sobie, że obok przycisku wołającego windę, jest przycisk rezygnacji, który jest informacją dla windy, że jednak ma ominąć dane piętro.

winda2_450px

Na powyższym diagramie zostala zasygnalizowana taka sytuacja i jej potencjalna obsługa. W trakcie obsługi kolejnych pięter winda mogłaby omijać piętro, na którym wybrano rezygnację z oczekiwania na windę. Takie sprawdzenie mogłoby się odbywać w momencie przyjazdu na piętro, w trakcie przejazdu między piętrami lub startu z ostaniego piętra, gdzie nastąpiło zatrzymanie. Na diagramie zaprezentowano sprawdzenie dla pierwszego z wariantów, przy odpowiednich założeniach wskazanych na diagramie. Diagram pokazuje pewną powtarzalną logikę działań i ich umiejscowienie w przebiegu takiego „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.

Co dostarczają kroki procesu?

Ostatnio spotkałem się z pojęciem diagramu procesu, który na bazie kroków procesu równocześnie wskazuje, co one dostarczają. Jest to tzw. Process-Deliverable Diagram (w skrócie PDD). Jest to diagram, który łączy w sobie elementy z dwóch obszarów:

  • kroków/czynności składających się na proces, zaprezentowanych za pomocą diagramu czynności (ang. activity diagram) z notacji UML,
  • obiektów dostarczanych przez proces, zaprezentowanych za pomocą diagramu klas (ang. class diagram) z notacji UML;

pdd2

Pierwszym procesem, który przyszedł mi na myśl, gdy przeczytałem o tym diagramie, był proces realizacji projektu, zaprezentowany na powyższym przykładowym diagramie. Począwszy od inicjalizacji projektu, przez realizację jego kolejnych działań po wdrożenie, na każdym etapie dostarczany (ang. deliver) jest określony “produkt”. Produkty w całości lub częściowo są wykorzystywane na kolejnych etapach procesu. Te produkty można potraktować jako produkty końcowe procesu. Mogą być np. podstawą kolejnych zmian, przeprowadzania szkoleń, wyjaśniania reklamacji, analizy luk procesu.

Podobne rozwiązanie zostało zastosowane przy prezentacji wejść i wyjść w ramach realizacji procesu rekrutacji.

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

Konfiguracja kroków procesu

Chyba każdy korzystał kiedyś z windy – czy to w pracy, wieżowcu, urzędzie czy innym miejscu. Nietrudno więc wyobrazić sobie co się dzieje. Podchodzimy do windy i wołamy windę. Oczekujemy jej, wybieramy piętro, jedziemy, wysiadamy. Dojechaliśmy, proces jest efektywny. Proste, ale co się dzieje z windą, która zawiozła nas na dane piętro. Ten prosty proces przedstawia poniższy diagram.

Załóżmy, że winda zawsze zostaje na tym piętrze, na które zajechała, czyli jeżeli „czeka” na innym piętrze (X), a jesteśmy na piętrze (Y), a chcemy jechać na piętro (Z), to czas procesu wynosi: czas oczekiwania: |X-Y|+ czas jazdy: |Z-Y|. Przy 10 piętrowym budynku, gdy X=0, Y=10, Z=0, to mamy czas procesu 10+10 = 20 pj. (czyli „piętrojednostek”).

Diagram1x

Załóżmy, że widna zawsze, gdy jest pusta, a nie została zawołana, zmienia automatycznie piętro na piętro środkowe budynku. Przy 10 piętrowym budynku będzie to 5 piętro. Mamy więc, X=5, Y=10, Z=0, to wtedy czas oczekiwania: [|10-5|=5]+ czas jazdy: [|0-10|=10] = 15 pj. (czyli „piętrojednostek). Oczywiście, jeżeli zawołamy windę w czasie jej zjazdu/podjazdu, czas ten może być krótszy lub dłuższy. Gdyby były 2 windy, to wtedy mogłyby „wracać” na różne piętra i czas mógłby być jeszcze krótszy.

Do powyższych działań można byłoby dodać krok automatycznej zmiany piętra. I wtedy sposób realizacji tych dwóch kroków: oczekiwania na windę oraz automatycznej zmiany piętra jest słabym ogniwem procesu. W zależności od wysokości budynku, ilości wind, częstotliwości ich użycia na poszczególnych piętrach, można byłoby ustawić odpowiednio sposób „przesuwania wind” i ich „ściągania” do miejsca wołania. Za pomocą odpowiednich ustawień można poprawić sprawność procesu.

Dwa kroki procesu – różnorodność rozwiązań

Wyobraź sobie, że chcesz kupić książkę. Jakie wersje książki potencjalnie mogą Cię zainteresować? Wydanie w miękkiej okładce, w sztywnej, wersja pocket, wersja na czytnik elektroniczny, audiobook, druk na żądanie. Możliwości jest jak widać kilka. Możesz otrzymać książkę w ciągu kilku sekund lub kilku dni. Gdy lubisz trzymać książkę w ręku, słyszeć szelest, postawić książkę na półce – pomimo długiego oczekiwania, zamówisz książkę np. w sztywnej oprawie. Gdy chcesz jedynie mieć lekturę w podróży, jedną z wielu na czytniku, wybierzesz wersję elektroniczną.

W poprzednim wpisie o modelu długiego ogona wyróżniłem dwie powiązane czynności procesu „Wybór rodzaju procesu” (lewa strona poniższego diagramu) oraz „Realizacja zamówienia” (prawa strona poniższego diagramu). Na diagramie umieściłem pogrupowane w zależności od realizacji powyższe wersje książki.

Diagram2

Wskazane czynności są sposobem dostarczenia zamówienia dla klienta. W zależności od dokonanego wyboru, biorąc pod uwagę dwa „skrajne” rozwiązania:

  • wersja na czytnik elektroniczny – proces jest krótki, może zostać zakończony w przeciągu kilku-kilkunastu minut, w całości zrealizowany w ramach platformy sprzedażowej, bez angażowania dodatkowych jednostek,
  • wydruk na żądanie – proces jest dłuższy, trwa kilka – kilkanaście dni, realizowany jest w dużym stopniu poza platformą, angażuje zarówno jednostki powiązane (drukarnia), jak i zewnętrzne (poczta, firma kurierska, pracownik punktu odbioru zamówienia),

Oceniając realizację takiego procesu, konieczne jest właściwe zdefiniowanie mierników uwzględniających różne realizacje procesu i jego cechy charakterystyczne (SIPOC).

Nazwy kroków procesu

Po zamieszczeniu ostatnich wpisów, wszedłem na już cytowane przeze mnie forum analityków biznesowych – ModernAnalyst.com. Pojawił się na głównej stronie bardzo ciekawy artykuł dotyczący języka BPMN. Artykuł dotyczył przejścia w diagramach BPMN od antywzorów do najlepszych praktyk – „Efficient BPMN: from Anti-Patterns to Best Practices„. Dzisiaj chciałbym się skupić na 1 antywzorcu.

Po przeczytaniu artykułu, otworzyłem aplikację, w której tworzę diagramy, zacząłem od prawie najnowszego diagramu z prezentacją granic procesu i musiałem przyznać, że diagram nie jest zgodny z najlepszymi praktykami w zakresie nazewnictwa. W całym diagramie zastosowałem różne formy nazw czynności – rzeczowniki czy różne formy czasownikowe.

granice_procesu_popr450

Zgodnie z antywzorcem nr 1 (Anti-Pattern #1: Inconsistent Naming) podanym przez autora artykułu:

  • nazwy czynności powinny składać się z silnych czasowników i nazw właściwych dla domeny – w tym obszarze wybrane diagramy wymagają poprawek, ponieważ czasami stosuję dość nieprecyzyjne nazwy kroków,
  • bramki nie powinny mieć nazw – nie używam nazw,
  • nazwy czynności nie powinny zwierać „lub” i „i” – nie używam łączników w nazwach czynności, rozbijam je w przypadku i, a dla lub dodaję bramki,
  • nazwy powinny być krótkie, a szczegóły w dokumentacji – z racji, że staram się diagramem uzupełnić wpis, czasami nazwy są dłuższe a czasami krótsze,

Powyższy diagram prezentuje sposób zastosowania pierwszego wymogu – nowe nazwy otoczone przerywaną linią. Rzeczywiście proces wygląda lepiej i wskazuje jednoznacznie na zadania do wykonania.

Obowiązek dla właściciela procesu?

„…może być wykorzystana w celu stworzenia dokumentacji, której celem będzie wykazanie zgodności realizowanych procesów przetwarzania z wymaganiami RODO. Obowiązek wykazania przestrzegania stosowania przepisów RODO wynikający z art. 24 RODO nie określa bowiem w jaki sposób, poprzez jakie dokumenty, czy inne instrumenty zarządzania powinien być zrealizowany. Przepis art. 24 RODO stanowi jedynie, że administrator ma wykazać, że wdraża odpowiednie środki techniczne i organizacyjne, aby przetwarzanie odbywało się zgodnie z RODO.” oraz „...podejmowanie działań zapewniających, że osoby zaangażowane w proces przetwarzania informacji posiadają stosowne uprawnienia i uczestniczą w tym procesie w stopniu adekwatnym do realizowanych przez nie zadań oraz obowiązków mających na celu zapewnienie bezpieczeństwa informacji…” – są to dwa fragmenty artykułu ze strony Urzędu Ochrony Danych Osobowych mówiące o dokumentacji przetwarzania danych osobowych zgodnie z RODO.

Czytając ten artykuł zacząłem się zastanawiać czy przypadkiem z powodu obowiązywania rozporządzenia RODO nie pojawiają się dodatkowe obowiązki dla właściciela procesu. Samo sformułowanie właściciela procesu nie pojawia się w ustawie (o ile dobrze zweryfikowałem). Występują sformułowania odnoszące się do administratora danych, do jednostki przetwarzającej dane oraz rejestru czynności przetwarzania.

Temat wpływu RODO na procesy biznesowe już opisywałem w innym wpisie, niedługo po wejściu ustawy w życie, a był to okres kiedy podmioty funkcjonujące na rynku wysyłały do swoich klientów stosowne klauzule informacyjne. Wskazałem tam takie aspekty jak zebranie danych, zapisanie danych oraz wykorzystanie danych (co zasygnalizowałem również na poniższym diagramie). Są to elementy procesów, np. zamawiania w internecie lub innych, których kształt oraz rozwój określa właściciel procesu wraz z interesowanymi stronami. Przypomnę, że jednym z punktów było odpowiada za zgodność procesu z oczekiwaniami biznesowymi, co wydaje się oczywiste.

rodo2_450px

Działanie różnych procesów biznesowych, opartych o dane Klientów w nich uczestniczących, jest uzależnione także od innych aspektów – takich jak bezpieczeństwo procesu (w sklepie, z którego korzystam, regulamin to precyzuje), ryzyko procesu czy zgodność procesu z regulacjami obowiązującymi dany podmiot (regulamin sklepu, z którego skorzystam, ma takie zapisy, precyzujące z jakimi ustawami jest zgodny). W zależności od ustaleń i zasad stosowanych w danym podmiocie, można powiedzieć, że na jednostce rozwijającej, utrzymującej lub opiekującej się procesem, leży obowiązek spełnienia tych wymogów. Można uogólnić, że to właściciel procesu powinien odpowiadać za zgodność procesu z wymogami regulacyjnymi, w tym z RODO.  Wskazanie właściciela procesu wydaje się tutaj uzasadnione.

Dlaczego? To właściciel procesu ma (powinien mieć?) najlepszą wiedzę o tym jakie są kroki procesu oraz jakie elementy w procesie są pozyskiwane od Klienta (zasygnalizowane na diagramie). W momencie konieczności zebrania dodatkowych poświadczeń lub danych od Klienta, to właściciel procesu inicjuje samodzielnie lub wspólnie z zainteresowanymi jednostkami odpowiednią zmianę techniczną, zmierzającą do osiągnięcia postawionego celu.

Wracając do cytatu, to właściciel procesu  moim zdaniem wspiera administratora danych w określeniu odpowiednich zapisów w rejestrze czynności przetwarzania oraz wyjaśnia elementy składające się na taką pozycję jak na przykład (co próbowałem także zasygnalizować na diagramie):

  • „…
  • cele przetwarzania;
  • opis kategorii osób, których dane dotyczą, oraz kategorii danych osobowych;
  • kategorie odbiorców, którym dane osobowe zostały lub zostaną ujawnione…;
  • …”

Notacja uniwersalna dla procesu

Wiele symboli, grafik, mechanizmów, które nas otacza każdego dnia jest zrozumiała niezależnie od posiadanego wykształcenia, narodowości czy wcześniejszych doświadczeń. Gdy widzimy “+” w wyrażeniu, to wiemy, że coś dodajemy do czegoś. Gdy widzimy czerwone światło na ulicy, to oznacza brak możliwości ruchu. Gdy widzimy pięciolinię to myślimy o muzyce. Podobnie jest z wieloma innymi symbolami. Symbole są mniej lub bardziej upowszechnione. Korzystanie z nich ułatwia komunikację, wymianę pomysłów oraz idei między różnymi odbiorcami. Opisane przykłady wskazują na stosowanie tzw. notacji uniwersalnej, z ang. universal notation.

upn450px

W przypadku procesów biznesowych, także istnieje taka notacja, która pozwala na zaprezentowanie przebiegu procesu w sposób zrozumiały dla większości odbiorców. Jest to tzw. Universal Process Notation, po przetłumaczeniu Uniweralna Notacja dla Procesów. W tej notacji, jak widać na powyższym diagramie są stosowane obiekty (ramki), zawierające informację o nazwie czynności oraz jej wykonawcy oraz połączenia opisujące wejścia i wyjścia poszczególnych czynności. W odróżnieniu od notacji BPMN, którą się często posługuję w ramach diagramów na blogu, zapis jest zdecydowanie uproszczony.

Na powyższym diagramie zapisałem przykładowy proces dot. kolejkowania, gdzie występowały dwie różne role – użytkownik oraz system. Produkty poszczególnych kroków były różne i można je jednoznacznie określić: Otrzymane żadanie klienta, Wypełniony formularz, Zapisane zgłoszenie, Parametry listy ustalone, Sprawa dodana do kolejki. Strzałki informują o kolejności kroków oraz kierunku przekazywania wejść. Dodatkowo mamy ponumerowane kroki, aby łatwiej było się do nich odnosić. Pozwalają też zidentyfikować pierwszy krok (proste zastosowanie uniwersalnej notacji związanej z liczbami).

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.