Wprowadzenie

Większość modeli (systemów map) procesów biznesowych posługuje się trzyelementowym wzorcem (pragmatyką) bazującym na definicji procesu brzmiącej mniej więcej tak: proces to czynność lub ich sekwencja przekształcająca stan wejścia w stan wyjścia. Czasami dodaje się, że źródłem wejścia jest “dostawca” a wyjścia “klient” (także tak zwany klient wewnętrzny). Wada tej definicji polega na tym, że jest zbyt ?mechaniczna?. Co to znaczy? Że traktuje wejście i wyjście procesu jak ?pojedyncze stany czegoś? łącznie (wytłumaczenie kilka linijek dalej).

Klasycznym przykładem tego podejścia jest Six Sigma i model SIPOC:

Model SIPOC zakłada istnienie osobnej dokumentacji dla samego procesu, nie precyzując jak ma zostać ona wykonana (nie narzuca metody dokumentowania procesu).

Przepływy

Nieco szersza definicja procesu, mieszcząca się pojęciowo w powyższej, mogła by brzmieć: proces przekształca stan wejścia w stan wyjścia, przekształcenie to jest ograniczone określonymi zasobami i regułami (zakazami). Tu mamy do czynienia z pięcioma elementami to jest: wejście, wyjście, proces, zasoby, reguły. Przykładem tego podejścia jest starszy od  Six Sigma model oparty na wzorcu [[ICOM]] (powstał w latach 60tych!):

Tu już widać, że proces na tym poziomie jest pewną abstrakcją, definiowane są (ICOM) cztery “satelitarne” elementy definiujące “co, z czego i dlaczego się dzieje”.

Można się także dość często spotkać z definicją sześcioelementową Erikssona-Penkera ([[Eriksson-Penker Business Modeling Profile]]) . Tu mamy:

Powyższy model bazuje na uznaniu, że proces biznesowy:

1. ma cel,
2. ma specyficzne dane na wejściu,
3. ma specyficzne dane na wyjściu,
4. wymaga zasobów,
5. stanowi “wiele czynności do wykonania”,
6. angażuje różne “departamenty” w firmie (poziomy przepływ),
7. tworzy jakąś wartość dla klienta (wewnętrznego lub zewnętrznego)

Problem jaki ja mam z tym wzorcem to: wymaga niestandardowych pojęć w UML.  Profilowanie polega na rozbudowie taksonomii znaczeń (stereotypy pokazują jakie podtypy tworzymy dla danego typu), niestety obiekt jako instancja klasy nie wytrzymuje w moich oczach definicji czegoś tak abstrakcyjnego jak cel biznesowy(<<goal>>). Symbol procesu (tak zwany pagon) także nie jest pojęciem z UML. Pojęcie Information jest tak pojemne, że w moich oczach jest workiem, który pomieści wszystko, a cechą dobrej notacji (formalnego języka, także otwartego) jest jednak wzajemne wykluczanie się definicji pojęć danej przestrzeni nazw (czyli jeżeli coś jest np. Wejściem to już nie może być Informacją), na tej zasadzie nie rozumiem też różnicy pomiędzy celem procesu a jego wyjściem albo Aktorem z Zasobem (w końcu ludzie to zasoby ludzkie).

Od niedawna UML formalnie wprowadził nowy diagram Profile (jako wersji Beta używam go od roku co najmniej) i zachowując semantykę tego diagramu trudno było by taki profil zbudować (mi nie wyszło).  Jednak ocenę przydatności tego systemu pozostawiam Państwu.

Definicja trzyelementowa traktuje wszystkie dostępne dane (informacje) jako Wejście. Problem w tym, że przekształcana jest tylko część z nich.

Jeżeli np. do realizacji procesu fakturowania, na jego wejściu potrzebne są dane do faktury oraz jej wzór i znajomość reguł naliczenia podatku VAT (stosowna Ustawa) to zwróćmy uwagę, że tak naprawdę przekształcane są (przetwarzane) tylko dane do faktury, pozostałe dane to niemodyfikowane ograniczenia, wiedza, którą musi posiadać Wykonawca. Tak wiec np. ustawa o podatku VAT to nie przetwarzane wejście tego procesu.

Aby proces zaistniał musi pojawić się Osoba tworząca fakturę czyli zasoby, ów Wykonawca z jego wiedzą i narzędziami jakimi dysponuje. W efekcie model nieco się poszerza: wejście, wyjście (dane do faktury), proces (jak powstaje faktura np. etapy zatwierdzania), zasoby (osoba fakturująca i narzędzia których używa do tego), reguły (wewnętrzne procedury oraz prawo).

Reguły rozbijamy na dwie części: reguły biznesowe (wewnętrzne procedury i zarządzenia) oraz prawo czyli ograniczenia zewnętrzne. Jaki cel przyświeca takiemu podziałowi? Wydzielenie specyfiki badanej organizacji. Jej specyfika tkwi w wewnętrznych procedurach i zarządzeniach a nie w mapie procesów, ta jest raczej wewnętrznym łańcuchem wartości (który nie powinien być zbyt skomplikowany).

Jeżeli chcemy ?odkryć? źródła przewagi rynkowej musimy zdefiniować to, co odróżnia nas od konkurencji. Co to jest? Posiadane zasoby i reguły biznesowe.

Tak opisany model można zobrazować w notacji BPMN:

Każdy proces jest inicjowany jakimś zdarzeniem, w szczególności pojawieniem się dokumentu do obsłużenia np. Zamówieniem. Wyjście to produkt tej pracy np. Faktura. I tylko to podlega przetwarzaniu. Reszta “danych wymaganych” to nie wejście procesu a jego ograniczenia w postaci: aktów prawnych, procedur, zarządzeń wewnętrznych (reguł biznesowych). Proces kończy się zdarzeniem: “Dane wyjściowe wytworzono”, jest to “manifestacja”. W czym rzecz? otóż jeżeli proces się skończył: faktura VAT została wytworzona ale do czasu gdy nikt się o tym nie dowie (produkt procesu nie zostanie dostarczony klientowi lub nie zostanie od o tym poinformowany), proces formalnie trwa. To dlatego mówi się o BPMN (i o naturze procesów) że są sterowane zdarzeniami. Aktów prawnych definiować nie trzeba, procedura to określony, narzucony sposób wykonania konkretnej czynności, reguła biznesowa to ograniczenie dotyczące całej organizacji (więcej o regułach w poprzednich wpisach).

Jaki z tego wniosek? Skuteczne zarządzanie, z pełnym zrozumieniem skutków, wymaga modelu, który pokaże nam czym dysponujemy, w czym jesteśmy (chcemy być) lepsi i na co nie mamy wpływu, czyli z czym walczymy i my i konkurencja jednakowo.

Na tym etapie Analityk Biznesowy może dać menedżerom dobry model biznesowy symulujący modelowaną organizację, podstawę do podejmowania decyzji organizacyjnych.

Zasoby

Zasoby to coś, bez czego żadna organizacja nie jest w stanie funkcjonować. Wśród nich są ludzie i narzędzia pracy, których używają. Model ICOM traktuje zasoby ogólnie, w BPMN zostały one “ukryte” w postaci abstrakcji jaką jest rola (lub wykonawca).  Wykonawca “grupuje” w sobie niezbędną wiedzę, umiejętności, narzędzia i materiały potrzebne do wykonania Czynności (dlatego obecnie jako poważny błąd postrzegam modelowanie oprogramowania (Systemu) jako toru w procesie, System to nie rola a narzędzie pracy no chyba, że mowa o robotach ;)).

Wśród tych narzędzi mogą być komputery, a konkretnie oprogramowanie, które wspiera Wykonawcę w realizacji wybranych Czynności. Skoro tak, to oprogramowanie po prostu świadczy usługi swoim użytkownikom ([[model usługowy systemu informatycznego]]).

Tak rozumiane ?usługi? to nic innego jak wymagania na oprogramowanie. Z uwagi na to, że wymagania te dzielimy na usługi (realizacja wsparcia jakiejś logiki biznesowej) oraz jakość jej realizacji, wymagania dzielimy na funkcjonalne oraz jakościowe (poza-funkcjonalne).

Systemy i oprogramowanie

Dotykamy tu więc oprogramowania np. systemów ERP, CRM, EOD (elektroniczny obieg dokumentów) lub dedykowanego (w zasadzie zawsze mamy do czynienia z systemami dedykowanymi jeżeli tylko planowana jest jakakolwiek ich kastomizacja).

Na tym etapie powinien powstać projekt architektury systemu. Wystarczy się rozejrzeć wokół siebie by przekonać się, że mamy wokół wiele różnego oprogramowania. Między bajki można włożyć tezę, o jednym wielkim pakiecie zintegrowanym ? nikt takiego nie ma (tylko jednego). To co nazywamy Systemem Informatycznym to tak na prawdę pakiet oprogramowania od różnych, mniej lub bardziej wyspecjalizowanych dostawców. Integracja poszczególnych elementów tego pakietu (lub brak tej integracji) zależy od pierwotnego planu (architektury).

Teraz dopiero rysuje się obraz Systemu: wiele różnego rodzaju oprogramowania, które wspiera różnych pracowników na różnych etapach ich pracy. Czy da się to opisać nie mając opisanego wyżej modelu biznesowego?

Czym jest piąty element?

To abstrakcja jaką jest proces biznesowy. Mało która firma ma modele procesów a każda jakoś istnieje! Można żyć bez map procesów, straszne! Co więc oferują firmy doradcze “sprzedające” mapowanie procesów biznesowych? Nie wiem.

Sedno sposobu pracy organizacji to reguły biznesowe. One rządzą tym, co jest wykonywane i jak. Proces (to jak jest wykonywana praca) to abstrakcja, efekt istnienia ograniczeń (w tym właśnie reguł biznesowych). Tak wiec można zarządzać firmą nie mając modeli procesów podobnie jak można mieszkać w mieście nie mając jego planu.

W czym problem? Bez “mapy” nie rozumiemy wielu zjawisk mimo, że występują. Jednak przydatny model biznesowy to model procesów powiązany z pozostałymi czterema składnikami opisu organizacji (ludzie, prawo, wewnętrzne zarządzenia i procedury).

Model biznesowy to nie są dziesiątki i setki nieczytanych diagramów, pokazujących szczegółowo to co robią pracownicy, bo mogą to robić na nieskończenie wiele sposobów (tą metodą projekt mapowanie procesów nie ma końca!). Istotne jest to co powstaje, po co i dlaczego akurat tak. Całą organizację można pokazać tak:

Na zakończenie: np. model pracy operacyjnej każdego urzędu można kompletnie opisać jednym diagramem. Jeżeli chcesz na prawdę poznać swoją firmę, opracuj jej model. Ale nie w postaci setek diagramów  będących suchym zapisem wywiadu.

Rozłóż firmę na czynniki pierwsze i zrozum ją. Bez tego nie zarządzasz a próbujesz zarządzać!

Wykonaj sformalizowany notacjami i słownikiem pojęć, audyt firmy, sposobu funkcjonowania i zrozum jak na prawdę działa. O wspólnym słowniku pojęć biznesowych, podstawą budowy reguł biznesowych, innym razem.