Pytanie o dokumentację procesu

Wyobraźmy sobie, że korzystamy w internecie z narzędzia do przeliczania kursów walut. W narzędziu, nazwijmy go Kalkulator walut, ma miejsce proces składający się z kroków: wybór walut przeliczenia, wpisanie kwoty, wskazanie kierunku przeliczenia oraz samego przeliczenia. Proces jest bardzo prosty, co obrazuje poniższy diagram. W procesie uczestniczy Użytkownik oraz Kalkulator walut. Proces przebiega przy określonych Kursach walut mówiących o sposobie wyrażenia jednej waluty drugą. Podana Wartość przez użytkownika jest zmienna.

Biorąc pod uwagę elementy procesu, obecne przy modelowaniu wielowymiarowym procesów biznesowych (o którym pisałem w jednym z poprzednich wpisów), dokumentacja procesu mogłaby wyglądać następująco:

• artefakty/obiekty – proces wykorzystuje obiekty: Waluta, Kursy Walut, przy czym Kursy Walut są obiektem wejściowym dla procesu, który nie podlega modyfikacjom w ramach procesu. Natomiast Waluta jest uzależniona od wyboru użytkownika. Kwota wejściowa nie jest modyfikowana, natomiast proces wylicza Kwotę wyjściową. Działanie na tych obiektach jest wskazane na diagramie.
• Aktywności/czynności: Wskaż waluty dla przeliczenia, Wpisz kwotę, Wskaż kierunek przeliczenia, Przelicz.
• Uczestnicy: Użytkownik, Kalkulator walut.
• Role/Uprawnienia: Użytkownik ma możliwość określenia parametrów obiektów wejściowych. Kalkulator określa wartość parametrów wyjściowych.
• Zasoby: Formularz udostępniony przez Kalkulator walut.

Zawartość powyższej przykładowej dokumentacji jest dość ograniczona, ale wystarcza do zrozumienia jak działa proces, jakie są jego elementy. Użytkownik nie widząc nawet formularza, może sobie wyobrazić co się dzieje. Gdyby proces był bardziej skomplikowany, poziom szczegółów, elementów wskazanych w dokumentacji też by się powiększył. W zależności od podmiotu gospodarczego czy czasu przeznaczonego na dokumentację, będzie ona wyglądała różnie. Czasami wystarczy zaangażowanie jednej osoby do jej stworzenia, a innym razem wymagane będzie powołanie zespołu.

Pytanie jednak się nasuwa. Czy taka dokumentacja jest potrzebna, czy może jej tworzenie jest stratą czasu? Czekam na komentarze pod wpisem lub maile na skrzynkę podaną w kolumnie po prawej.

Reklama

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.

Cechy notacji

W publikacjach określających podstawowe elementy procesu, o których pisałem w poprzednim wpisie, wymienia się cechy jakie powinna mieć notacja do modelowania procesów. Wskazywane cechy wpływają na możliwości przedstawiania modeli procesów biznesowych z różnych perspektyw.
Są to poniższe cechy. Opisy tych cech są moją interpretacją dostępnych informacji w publikacjach umieszczonych w Internecie.

• naturalna reprezentacja (ang. natural representation) – notacja o takiej cesze, pozwala na nie tylko na wyrażenie wszystkich aspektów opisywanego procesu, ale pozwala na zrobienie tego w naturalny, zrozumiały i łatwy do zidentyfikowania sposób;
• wsparcie oceny/pomiarów (ang. support of measurement) – notacja dająca takie możliwości, to taka, która oferuje atrybuty oraz artefakty pozwalające na pomiar przebiegu procesu, co jest podstawą decyzji o ewentualnych przyszłych modyfikacjach procesu;
• skalowalność/możliwość dostosowania (ang. tailorability of models) – ma to na celu utrzymywanie jak najmniejszej liczby modeli procesów. Notacja powinna pozwalać na dostosowywanie przygotowanego modelu do różnych potrzeb, bez konieczności budowy go w całości od początku;
• formalizm (ang. formality) – oczekiwane jest sformalizowanie tworzonych modeli, co przyczynia się do lepszego jego zrozumienia przez różnych uczestników i odbiorców modelu. Można powiedzieć, że założenia stosowania elementów notacji są sztywne, a nie dowolne;
• zrozumiałość (ang. understandability) – reprezentacja modelu powinna ułatwiać wyciągnięcie potrzebnej informacji przez różnych uczestników lub odbiorców procesu;
• wykonalność (ang. executability) – notacja ma wspierać odczyt stworzonego modelu przez maszyny i jego wykonanie;
• elastyczność (ang. flexibility) – notacja powinna umożliwiać wyrażenie aspektów związanych z maszynami, jak i tymi wynikającymi z decyzji, zachowań ludzi;
• umożliwienie śledzenia/identyfikowalność (ang. traceability) – notacja powinna wspierać analizę informacji, pod kątem ich wykorzystania, przetwarzania oraz kontekstu. Cecha ta także wskazuje na możliwość identyfikacji powiązań między elementami procesu.

Biorąc po uwagę jedynie możliwość ich porównywania istotne są takie cechy jak formalizm i zrozumiałość, aby dany element procesu był interpretowany tak samo przez różnych odbiorców i nie wymagał dodatkowego wyjaśnienia podczas interpretacji. Z kolei metody służące do zmiany procesów (np. benchmarking, six sigma) wymagają, aby proces mógł być opisany przez elementy wspierające jego ocenę.

W zależności od zastosowanej notacji, powyższe cechy będą możliwe do zidentyfikowania bez żadnych problemów lub po prostu będzie trzeba stwierdzić, że dana notacja nie posiada danej cechy,
Jak dla mnie bardzo ważnymi cechami są skalowalność/możliwość dostosowania oraz elastyczność, które świadczą o tym, że daną notację można wykorzystać w różnych sytuacjach, dziedzinach oraz do przedstawienia różnorodnych ścieżek alternatywnych oraz zachowań uczestników procesu.

Elementy procesu

W wielu publikacjach dotyczących modelowania procesów biznesowych, ich reprezentacji, analizy i przygotowania do ich zmiany, pojawia się sformułowanie języka do modelowania wielowymiarowego dla procesów biznesowych (ang. multi-view process modeling language). Założeniem tego podejścia jest przedstawienie procesu z różnych perspektyw w taki sposób, aby łatwo było je porównywać, tworzyć powiązania. Proces jest traktowany jako bardziej klasa procesu niż jego reprezentacja w maszynowej postaci (np. za pomocą BPML).

Elementami takiej reprezentacji procesu, a bardziej modelu procesu są:

• tzw. artefakty (ang. artifacts), czyli obiekty, które proces tworzy, modyfikuje lub wykorzystuje podczas swojego przebiegu. Mogą to być obiekty/dane wejściowe, wyjściowe, a także obiekty stosowane tymczasowo wewnątrz przebiegu procesu. Są używane przy wykonywaniu kroków/czynności procesu.
• tzw. aktywności/czynności (ang. activities), czyli rzeczywiście wykonywane działania w ramach realizowanego procesu. Pewne zadania mogą przyczyniać się do wzrostu wartości produktu procesu, a inne są niezbędne dla interesariuszy procesu . O tym elemencie procesów pisałem wielokrotnie na swoim blogu, z różnych perspektyw.
• tzw. agenci/uczestnicy procesu (ang. agents), czyli wykonawcy kroków procesu lub osoby zainteresowane jego przebiegiem.
• tzw. role (ang. roles), czyli obowiązki lub uprawnienia przypisane do uczestników procesu podczas jego wykonywania.
• tzw. zasoby (ang. resources), czyli narzędzia, aplikacje, systemy lub inne środki, które wspierają, umożliwiają realizację procesu. Mogą to też być środki pozwalające na automatyzację lub przyspieszenie wykonywanych czynności.