Z zamiarem napisania tego tekstu noszę się już od kilku lat i za każdym razem mówiłem sobie: “ok, jeszcze tylko skończę ten jeden projekt i zobaczymy czy faktycznie ma to sens”. I tak od kilku lat. W końcu jednak udało się.

Wprowadzenie

Popularność podejścia do modeli procesów biznesowych, polegającego na “pokazaniu różnicy”, trwa od czasów popularyzacji re-inżynierii procesów biznesowych (lata 90-te) [zotpressInText item=”{5085975:WH68CD7T}”]. Umowy na usługi, zawierające w zakresie opracowanie modelu ‘as-is’ i ‘to-be’ nadal są podpisywane. Zakładam, że decyzje o zakresie projektu to indywidualne potrzeby zamawiających. Ja opiszę swoje doświadczenia i wnioski.

Głównym deklarowanym celem tworzenia obu tych modeli jest zawsze porównanie stanu obecnego i planowanego, a następnie zdecydowanie o tym ‘co dalej’. Zakłada się, że te modele powinny pokazać wartość dodaną projektowanych zmian. Pierwszy problem to konieczność stworzenia dwukrotnie większej ilości dokumentacji, to zaś przekłada sie na czas i koszt. W konsekwencji wdrożenie planowanej zmiany bardzo odsuwa się w czasie. Wynik każdej pierwotnie wykonanej analizy dezaktualizuje się wraz z upływem czasu, tym szybciej im więcej szczegółów ona zawiera. Wpadamy tu w ‘kwadraturę koła’. W artykule Cykl życia… zapytałem: Czego oczekuje biznes: efektu czy produktu? Wyniki analiz i rekomendacje to produkty pracy analityka, wdrożone zmiany organizacyjne czy oprogramowanie to także produkty. Te zawsze można kupić i mieć. A czym jest efekt? Np. zwiększeniem efektywności… A to oznacza, że etap analizy i potem wdrażania rozwiązania, także powinien cechować się efektywnością!

W czasach zmian rynkowych zachodzących w okresie poniżej roku, każda strata czasu jest szkodą, dwukrotne wydłużenie procesu analizy i opracowania rekomendacji szczególnie.

Więc jak, skoro nie dwa modele: ‘as-is’ i ‘to-be’?

Metody

Tu posłużę się prostymi metodami czyli schematy blokowe i rzadko stosowana a bardzo skuteczna: idealizacja [zotpressInText item=”{5085975:9L4LJPUY},{5085975:K9E2WBBD},{5085975:YPEIW5YK}”]. Nawiążę także do mało popularnej a ciekawej i bardzo skutecznej metodyki usprawniania organizacji, także opartej na idealizacji, opisanej przez Ackof’a [zotpressInText item=”{5085975:EMPAJKU9}”].

Rezultaty

Kluczem skutecznego planowania rozwoju organizacji jest studium wykonalności planowanych zmian, a do tego bardzo przydatna jest idealizacja jako metoda.

Wytyczenie kierunku działań

Każda organizacja kiedyś powstała i od tego momentu zaczyna żyć (co – uwaga – nie jest tożsame z jej rozwojem). Jeżeli podejmujemy decyzję o wprowadzaniu zmiany (a na początku raczej tylko deklarujemy taki zamiar) pierwszymi rzeczami jakie należy określić są: cel i kierunek zmian. Jak już to wiemy, kolejnym krokiem jest określenie tego co i w jakim czasie chcemy osiągnąć. Pamiętajmy, że ideał może nie być osiągalny, jest jednak zawsze doskonałym wyznacznikiem kierunku (podobnie jak rekordy olimpijskie dla sportowców, którzy wiedzą, że nigdy ich nie przekroczą, ale mimo to wiedzą co i po co trenować). Dlaczego? Bo kluczową wiedzą jest zawsze to, ile mnie dzieli od ideału i czy jest sens go osiągać, bo rozwiązania powinny być wystarczającą dobre, a nie zawsze najlepsze (co najwyżej możliwie najlepsze).

Projektowanie ideału jest takim sposobem myślenia o zmianie, który można przedstawić w prosty sposób: w rozwiązywaniu problemów, praktycznie dowolnego rodzaju, można uzyskać najlepsze wyniki dzięki wyobrażeniu sobie idealnego rozwiązania, a następnie cofnięciu się aż do miejsca, w którym znajdujesz się w chwili obecnej. Dzięki temu unikniesz urojonych przez siebie przeszkód, zanim jeszcze w ogóle pojmiesz, jak osiągnąć ideał.

[zotpressInText item=”{5085975:EMPAJKU9}”]

Poniższy diagram pokazuje kluczowe punkty planu:

I teraz: Czy dokładny opis stanu aktualnego jest potrzebny, skoro kluczowe pytanie zawsze brzmi: co zmienić? Sprawdźmy.

Wyobraźmy sobie, że robimy porządki w starej piwnicy a celem jest pozbycie się rzeczy niepotrzebnych. Identyczną sytuację mamy z plecakiem, gdy dość regularnie wyjeżdżamy np. w góry, nie chcemy jednak nosić zbędnych rzeczy. Są dwa możliwe podejścia do tego zadania:

1. przeglądamy wszystko i zastanawiamy się czego się pozbyć,
2. odkładamy wszystko na bok, i wybieramy tylko to o czym wiemy, że na pewno nadal będzie potrzebne i wiemy do czego, reszta zostaje (z piwnicy: wyrzucona).

Można próbować bronić każdej z tych metod, problem w tym, że pierwsza powoduje (praktyka to pokazuje), że zawsze zostaje prawie wszystko, a przybywa nowego.

Modelowanie organizacji

Natura człowieka to emocjonalne przywiązanie do tego co się już posiada, a z naturą (emocje) trudno walczyć. Dlatego warto czasami ją wspomagać (z tego samego powodu nie należy samemu negocjować tego co jest dla nas bardzo ważne, a jak musimy to robić sami, to należy zrezygnować z negocjacji i z góry ustalić korzystne warunki lub zrezygnować [zotpressInText item=”{5085975:6KBU6QYR}”]).

Popatrzmy na znany, nie tylko moim czytelnikom, od lat diagram:

Pokazuje on trzy podstawowe poziomy opisu (dokumentowania) organizacji. Najwyższy poziom to model biznesowy, czyli opis strategii (z reguły mieści się na jednej stronie maszynopisu). Najniższy to szczegółowe opisy wymaganych kompetencji, zakresy obowiązków, instrukcje stanowiskowe, procedury i zarządzenia, instrukcje itp. Te dwa rodzaje opisów ma praktycznie każda organizacja bo nawet, jeżeli nie wymaga tego prawo, to wymagają tego podstawy zarządzania.

Środkowa warstwa to coś, czego większość organizacji nadal nie ma, bo uważają że nie jest to potrzebne do bieżącego, operacyjnego zarządzania. Czym jest ten środkowy model? To jest tak zwany wewnętrzny łańcuch wartości organizacji, czyli opis tego jak powstają jej produkty i usługi, i jaką poszczególne prace wnoszą wartość dodaną do całości [zotpressInText item=”{5085975:9MPPQESP}”]. Dokumentujemy go jako Model (mapa) Procesów Biznesowych, jest to abstrakcyjny model, pozbawiony szczegółów, pokazuje to ‘co’ robimy i po co a nie ‘jak’. Warto tu zwrócić uwagę na ważną rzecz:

Nie ma żadnego sensu odwzorowywanie na schematach blokowych szczegółów trzeciej najniższej warstwy, bo powstają monstrualne liczby diagramów, które niczego nie wnoszą do projektu, bo ich przydatność jest co najmniej wątpliwa.

To ‘jak’ to robimy zawiera posiadana już dokumentacja w warstwie trzeciej, najniższej; nie ma więc sensu powtórne jej dokumentowanie na diagramach, powołujemy się na nią modelując procesy (więcej w artykule Analiza, wymagania i usprawnianie organizacji).

Czy warto mieć taki model procesów? Owszem, bo podejmowanie decyzji o zmianach bez takiego modelu to loteria. Jednak jeżeli model jest zbyt szczegółowy (patrz powyższa uwaga), to nie tylko opracowanie go jest kosztowne i trwa długo, ale zapoznanie się z nim zajmuje zbyt dużo czasu, więc nikt tego nie robi. W efekcie decyzje są podejmowane tak, jak by tego modelu nie było. Kiedyś decyzje o zmianach podejmowano rzadko i każdorazowe, poprzedzające te decyzje długie analizy, miały sens. Obecnie decyzje takie podejmujmy nie raz ‘znienacka”, i nawet jeżeli nie są częste, to nie ma czasu na poprzedzanie ich analizami, a bez analizy skutków decyzje operacyjne są loterią. W efekcie utrzymywanie aktualnego, ale bez zbędnych detali, modelu organizacji jest możliwe, opłacalne i ma ogromne znaczenie (patrz Audyt organizacji, model Architektury Korporacyjnej).

Poprawnie opracowane modele (mapy) procesów biznesowych pozwalają zrozumieć organizację i przewidywać efekty planowanych zmian.

(patrz: Audyt organizacji, podnoszenie efektywności)

Wdrażanie zmian

Popatrzmy na poniższy diagram:

Rozwój organizacji, poza bardzo rzadkimi przypadkami, nie jest (nie powinien być) rewolucją. Pisali o tym nie raz krytycy przywoływanej na początku Radykalnej Reorganizacji Procesów Biznesowych (mało która organizacja ją przetrwała) [zotpressInText item=”{5085975:64HNXMZ3}”]. Więc co zmieniać i jak? Powyższy diagram mówi, że generalnie zmiany dotyczą najniższej warstwy, ale żeby wiedzieć gdzie jest jej granica, trzeba mieć udokumentowaną także tę środkową. Zmiany procesów biznesowych są rzadkie, dotyczą pojedynczych procesów, i nie są to rewolucje.

Przejście od lewej do prawej strony to nasz plecak w góry: albo przeglądamy wszystko i próbujemy odrzucać nadmiar, albo wybieramy tylko to, o czym wiemy że będzie potrzebne. Skąd mamy wiedzieć, co będzie potrzebne? Jeżeli wykonamy model procesów biznesowych jako model wewnętrznego łańcucha wartości, to znaczy, że doskonale wiemy co i po co robimy, pozostaje jedynie określenie tego jak. I tu właśnie pojawia się moment, w którym określamy jak coś zrobić najlepiej, a potem patrzymy czy to jak to teraz robimy jest takie jak być powinno. Jeżeli tak, kontynuujemy (zabieramy to ze sobą w kolejną podróż), jeżeli nie – zarzucamy i staje sie to wymaganiem, wobec nowego rozwiązania (bez rozpamiętywania historii, sentymenty niestety zniszczyły już niejedną firmę).

W projekcie analizy i usprawnienia powstają więc:

1. Dokumentacja rynkowego modelu biznesowego, czyli opis strategii (w tym także misja i wizja organizacji).
2. Model motywacji biznesowej planowanych zmian (wytyczamy kierunek).
3. Model procesów biznesowych jako model wewnętrznego łańcucha wartości (to jest kilkanaście diagramów a nie kilkaset!).
4. Analiza przetwarzanych informacji i jej standaryzacja (analiza dokumentów, biznesowy słownik pojęć, reguły biznesowe, standaryzacja treści dokumentów, są to produkty aktywności na modelach procesów).
5. Wymagania biznesowe (czym ma się charakteryzować nowe rozwiązanie).
6. Opis (model) rozwiązania, stanowiący sobą tak na prawdę wymaganie dla jego dostawcy (wykonawcy).

Jeżeli pozbędziemy sie nadmiarowych, o wątpliwej wartości dodanej dla tego projektu, prac, to całość trwa od dwóch do sześciu miesięcy, zależnie od wielkości organizacji. W dużych organizacjach łatwo jest podzielić modele na dziedzinowe obszary, w których wdraża się lokalne samodzielne rozwiązania, wystarczy zaplanować ich integrację. Mając model informacyjny (dokumenty i ich wzajemne zależności) nie jest to trudne. Wbrew temu co mówią, dostawcy kompleksowych monolitycznych systemów, nie jest żadnym ryzykiem to że kilka działów przetwarza te same dane, ważne jest zagwarantowanie standaryzacji tych danych oraz ich nośników czyli dokumentów [zotpressInText item=”{5085975:4NX3LTE9}”]. Jeżeli bez problemu mogą współpracować ze sobą dwie odrębne firmy, to podobnie mogą to robić wydziały tej samej firmy, tym bardziej że w dowolnym momencie taki wydział może zostać wydzielony jako osobny podmiot, i po tej przemianie to wszystko nadal dalej działać. Włączenie do wnętrza organizacji innej firmy podobnie, nigdy nie powinna to być rewolucja informatyczna i wymiana wszystkiego.

Podsumowanie

Praktyka pokazuje, że powyższe sprawdza sie doskonale. Rezygnacja z detalicznych modeli as-is na najniższym poziomie ww. piramidy, nie przynosi straty jakości projektu, nie podnosi też jego ryzyka, a znakomicie skraca czas i tym samym obniża koszt tego etapu pracy (modelowanie procesów).

Owszem, nie raz na początku słyszałem od sponsora projektu: “chcemy zobaczyć te zmiany, chcemy widzieć różnice”. Jednak oferta wykonania takiej usługi w dwóch wariantach: zawierająca model ‘as-is’ i bez tego modelu (oferta fixed-price bo innych niż umowa o dzieło na tym etapie od lat nie składam: klienci chcą znać koszty przed a nie po projekcie), od kilku lat w 100% przypadków kończy się rezygnacją z dokumentowania detali i modeli procesów “as-is”. Więcej w artykule Audyt organizacji, podnoszenie efektywności.

Uważam, że w czasach gdy “czas to pieniądz”, a czas ten liczymy obecnie w tygodniach a nie w latach, projekty analityczne trwające ponad kwartał (czy pół roku w bardzo dużej organizacji) są stratą czasu i środków.

Kluczowe pytanie na koniec:

Kiedy powstają szczegóły nowego rozwiązania? W toku projektowania i wdrożenia…

…i jest to bardzo bezpieczne i zarazem efektywne, bo mając architekturę rozwiązania (wewnętrzny model łańcucha wartości i model architektury rozwiązania) wiemy ‘co’ ma powstać, pozostaje już tylko na bieżąco podejmować decyzje ‘jak’ ma to wyglądać.

Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle ?problemami złośliwymi?. ?Problem złośliwy? to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania.

[zotpressInText item=”{5085975:ERP7FIQG},{5085975:3E8MCCST},{5085975:B9NB3E9J}”]

Sprawując ze swojej strony nadzór nad dostawcą rozwiązania, jego nabywca panuje nad wszystkim. Mogę tylko podsumować to tak: to co napisał Ackoff 15 lat temu [zotpressInText item=”{5085975:EMPAJKU9}”] i ponad 20 lat temu [zotpressInText item=”{5085975:4NX3LTE9}”]: podejście takie sprawdza sie doskonale.

A co gdy rekomendacje zmian dotyczą środkowej warstwy (wewnętrzny łańcuch procesów)? Wtedy owszem, powstaje model t-bo, jest to rekomendacja, a jej udokumentowanie to jeden diagram…

(tak realizowane były moje projekty dla wielu małych firm, kilku instytucji publicznych, w tym Kancelarii Senatu i Żandarmerii Wojskowej, a także dla KGHM SA)

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

W poprzednim artykule (Ile jest tych wymagań na system ERP) pisałem, że nadmierne skupianie się na szczegółach nie tylko nie wnosi niczego do projektu ale nie raz wręcz go niszczy. Dotyczy to zresztą ogólnie projektów analitycznych, nie tylko w dziedzinie IT.

Na stronach jednego z bardziej poczytnych serwisów o analizie IT – http://www.modernanalyst.com – pojawił się jakiś czas temu ciekawy artykuł o analizie SWOT. Autor opisuje jak tę analizę przeprowadzić, ja opiszę jak jej użyć w analizie systemowej organizacji i specyfikowaniu wymagań. We wstępie artykułu czytamy:

Much of the business of business analysis is in the details, and most business analysts are by nature detailed, systematic thinkers. Occasionally most organizations, though, have times when they can?t see the forest for the trees. That is when the high-level, broad-range view that SWOT Analysis affords is just as useful in avoiding costly errors as unambiguous requirements. (What is SWOT Analysis?).

W dużym uproszczeniu: wielu analityków skupia się od razu na szczegółach, bo to naturalne elementy naszego bezpośredniego otoczenia, nie potrafią spojrzeć na organizację z daleka,  “nie potrafią dostrzec lasu patrząc na pojedyncze drzewa”. Analiza SWOT pozwala spojrzeć na problem z innej, wyższej perspektywy, szerzej, dzięki czemu jest bardzo użyteczna w unikaniu kosztownych błędów jakimi są niejednoznaczne wymagania. 

Jednym z “zabójców projektów” (a konkretnie ich budżetów i harmonogramów) są tak zwane wymagania osierocone i wymagania nieodkryte na etapie analizy. Są to odpowiednio wymagania zgłoszone do specyfikacji i zrealizowane, z których następnie nikt nie korzysta, oraz te odkrywane dopiero na etapie wdrożenia. Nie da się “zaprojektować” lasu myśląc o drzewach bo celem jest las, a nie konkretne drzewa. 

Jeden projekt może mieć jeden cel, jeżeli jednak “celem” ma być każdy kolejny krok, podróż nigdy się nie kończy.

 

Wymagania o jakich pisałem w poprzednim artykule to wymagania wobec rozwiązania, którym było “jakieś oprogramowanie”.  Jednak to drugi etap analizy. Generalnie najpierw analizuje się i definiuje wymagania biznesowe, a potem dopiero wymagania wobec rozwiązania, wiedząc już jakie warunki musi ono spełniać. Przykładowym wymaganiem biznesowym może być podniesienie jakości obsługi klienta (co by to tu teraz nie miało znaczyć), a dopiero rekomendowanym rozwiązaniem może być, np. oprogramowane CRM albo reorganizacja działu sprzedaży (co z resztą wiele firm robi znacznie częściej niż kupuje nowy CRM ;)).

 

Wiele firm rzuca się na projekty od razu z założeniem, że “musimy mieć nowe oprogramowanie”. Co nie raz bywa dużym błędem i masą zmarnowanych środków. Jak się przed tym ustrzec?

Warto popatrzeć na organizację i konkretny problem z pewnej perspektywy, z wyższego poziomu abstrakcji, niż tylko stojąc między biurkami widząc konkretne sprawy i ludzi się nimi zajmującymi. Narzędziem pozwalającym “wznieść” się na wyższy poziom abstrakcji jest właśnie analiza SWOT. Analiza ta polega na zidentyfikowaniu czterech kluczowych elementów wpływających  na organizację : czynniki zewnętrzne  jakimi są okazje i zagrożenia oraz czynniki wewnętrzne czyli silne i słabe strony organizacji. Tu ważna informacja, analiza SWOT to analiza “czegoś konkretnego” w “określonym środowisku”. Czynniki wewnętrzne opisują “to coś”, zaś czynniki zewnętrzne opisują “środowisko tego czegoś”. Można tak analizować organizację (np. firma i jej otoczenie rynkowe) czy też produkty projektów (np. konkretne oprogramowanie w firmie) ale nie sam projekt wdrożeniowy czy proces (one nie są “czymś”).

Analiza SWOT może być elementem analizy systemowej organizacji. Analiza SWOT to np. wstęp do opracowania rekomendacji w odpowiedzi na problem biznesowy. SWOT to identyfikacja i wpływ określonych elementów, pozostaje ocena tego jaki, i na co.  Dlatego analiza SWOT stała się częścią tak zwanego Modelu Motywacji Biznesowej (BMM). Model ten pozwala lepiej zrozumieć otoczenie “problemu” oraz “śladować” elementy zidentyfikowane w analizie SWOT na konkretne procesy biznesowe i strukturę organizacyjną.

(diagram BMM: analiza SWOT i przejście na procesy biznesowe opr. własne autora).

Z poprzednich moich artykułów wiemy, że wymagania wobec rozwiązania (w tym wobec oprogramowania) mają swoje źródło w procesach biznesowych i ich wykonawcach. Jednak spisanie ich w postaci deklaratywnej listy podczas warsztatów i wywiadów, prowadzi do powstania długiej i praktycznie nieweryfikowalnej listy o jakiej pisałem w  Ile jest tych wymagań na system ERP.

Lekarstwem na problem jest weryfikacja (tworzenie) listy wymagań wobec rozwiązania. Weryfikacja (diagram powyżej) polega na tak zwanym śladowaniu. Śladowanie to wywodzenie każdego wymagania z pierwotnej potrzeby, jaką jest taktyka, którą przyjęto by osiągnąć cel. Taktyka ma swoje źródło w strategii (taktyka implementuje strategię). Strategia (jej skonstruowanie) jest odpowiedzią na okazję rynkową, która jest przyczyną, dla której podejmujemy działania rynkowe. Okazja rynkowa daje szansę na “zysk” (produkt dający dochody) w postaci dostarczenia swojemu otoczeniu wartości dodanej. Warto tu zwrócić uwagę na to, że elementy analizy SWOT także powinny mieć swoje uzasadnienie w postaci identyfikacji zewnętrznych i wewnętrznych czynników wpływu. Słabe strony oraz zagrożenia powinny identyfikować ryzyka projektu. Analizę uznajemy za zakończoną po zidentyfikowaniu wszystkich znanych kluczowych czynników wpływu i ryzyk. Analiza taka jest elementem analizy systemowej organizacji.

Wielu właścicieli firm, ich zarządy, pomija ten etap w projektach z uwagi na swoje przekonanie, że ich dotychczasowe działania i chęć ich kontynuacji, nie wymagają żadnej korekty, oczekują podania na tacy opisu narzędzia, którego – jak sądzą  – potrzebują. Zachowują się jak pacjenci, którzy mimo, że ostatnie badania robili wiele lat temu, nie dopuszczają myśli, że lekarz może im przepisać na gorączkę coś innego niż kolejną aspiryną. Bywa, że zbyt późno odkrywają, że tym razem to nie było kolejne przeziębienie.

 

Praktyka pokazuje, coś bardzo ciekawego: zamiast prowadzić żmudne i kosztowne wywiady, sesje warsztatowe, burze mózgów, których produktem jest długa lista dość przypadkowych “pomysłów na wymagania”, warto dochodzić do listy wymagań metodą od ogółu do szczegółu, właśnie od poziomu analizy SWOT (opartej na wizji i misji organizacji). Takie podejście od razu, najkrótszą drogą, prowadzi – przez model procesów biznesowych – do bardzo spójnej i kompletnej, bez nadmiarowych (osieroconych) wymagań, specyfikacji wymagań wobec rozwiązania. Każde wymaganie ma swoje uzasadnienie (śladowanie) w strategii, nie ma ryzyka, że coś pominiemy, bo tu weryfikatorem jest model procesu (kompletna i sprawdzona lista czynności). Koszty uzyskania specyfikacji wymagań tą metodą, są znacznie niższe niż tradycyjnymi (wywiady) metodami bo: nie angażujemy czasu całych zespołów pracowników na wywiady i warsztaty, ryzyko bardzo kosztownych pominięć i nadmiarów jest minimalne, liczba iteracji w takim projekcie zbliża się do JEDNEJ! i nie trzeba odkrywać wymagań metodą kosztownych prototypów na etapie przedwczesnej implementacji. Jedyny “problem” to  jej przeprowadzenie, mimo “pokusy”, rozpoczęcia projektu od razu bo “nie ma czasu na analizę, i szkoda na to pieniędzy”.

Wstęp

Kwestia “liczby poziomów modelowania procesów” pojawia się na każdym moim szkoleniu w postaci pytań uczestników. Często także spotykam się  z tym “zagadnieniem” w projektach i w literaturze. Można np. spotkać modele z procesami ponumerowanymi poziomami modelowania: procesy główne 0.1; 0.2 itp., procesy pierwszego poziomu: 1.1; 1.2; 1.3, dalej 2.2.4 itd. W czym problem?

Definicje

Po pierwsze: proces np. archiwizacji dokumentu może się pojawić na każdym z tych poziomów, jaki numer mu nadać? Po drugie pewne obszary działania są mało złożone i możliwe, że wystarczy jeden “poziom”, inne złożone i potrzebne będą może cztery poziomy?

Elementarny proces, podobnie jak klocek LEGO, może się pojawić wszędzie, niezależnie od poziomu, np. realizacja zobowiązania finansowego, czyli zapłata za coś, może się pojawić jako zapłata za fakturę wystawioną przez kancelarię prawną w procesie negocjowania umowy handlowej (czyli bardzo “wysoko”) jak i w procesie regulowania zobowiązań za dziurkacze (raczej nisko w takiej hierarchii).

Najpierw dwie kluczowe definicje za normą terminologiczną ISO 9000 (jakość zarządzania):

Proces to: każde działanie, które przekształca wejście (dane wejściowe) na wyjście (dane wyjściowe). Proces może w swoim “wnętrzu” zawierać zbiór różnych operacji (działań) wzajemnie ze sobą powiązanych i na siebie oddziałujących.

Procedura to: określony sposób realizacji działań lub procesów.

Powyższa definicja jest łatwa do  przyjęcia i często stosowana, jednak jest zbyt uboga (pojęcie proces jest tu dość pojemne) by stanowiła podstawę do formalnego modelowania organizacji, dlatego  dodatkowo przytoczę tę, nieco pełniejszą:

(cytat, str. 41) Proces biznesowy jest chronologicznym i logicznym ciągiem funkcji (zadań) wykonywanych w toku pracy nad określonym obiektem w ramach racjonalnego działania. [zotpressInText item=”{5085975:UQN54LMV}”]

(cytat, str. 431) Proces biznesowy stanowi zbiór powiązanych ze sobą czynności ukierunkowanych na realizację określonego celu biznesowego w oparciu o wykorzystywane zasoby. Proces biznesowy jest sterowany poprzez strategię organizacji definiującą cele oraz produkty tworzone przez procesy. [zotpressInText item=”{5085975:UQN54LMV}”]

Przeglądając literaturę przedmiotu (w tym powyższe) można dojść do następującej definicji procesu biznesowego:

Proces biznesowy: czynność, lub logicznie powiązany chronologiczny łańcuch czynności, przekształcający stan wejścia procesu w stan jego wyjścia, mający wartość dla odbiorcy. Proces do wykonania, wymaga określonych zasobów, sposób jego realizacji może być ograniczony. (opr. własne)

Do modelowania procesów obecnie używa się najczęściej notacji BPMN (obecnie tak zwany standard de’facto), specyfikacja tej notacji tak definiuje proces:

A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work. In BPMN a Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flows that define finite execution semantics. Processes can be defined at any level from enterprise-wide Processes to Processes performed by a single person. Low-level Processes can be grouped together to achieve a common business goal. [zotpressInText item=”{5085975:JSERUS7B},{5085975:QJUPRFNR}”]

Warto zwrócić uwagę na fakt, że z perspektywy notacji, ta jest jedynie językiem wyrazu, proces to “sekwencja aktywności w organizacji, której celem jest dostarczenie określonego efektu”.  Dalej: proces jest obrazowany z pomocą grafu złożonego z elementów o określonej semantyce (mających sztywno określone znaczenia). Proces może być definiowany na dowolnym poziomie. Procesy na najniższym poziomie mogą być grupowane  np. wspólnym celem. Tyle notacja. Definicja procesu w BPMN jest zgodna z ISO.

Tak więc procesem jest tu każdy przepływ pracy, zaś procesem biznesowym są te przepływy, których granice (początek i koniec) wyznaczają produkty biznesowe (określone obiekty, cele biznesowe).  

Co to oznacza?   Oznacza to, że skoro celem biznesowym jest np. wystawienie faktury za dokonaną sprzedaż, zaś przygotowanie samej treści faktury jest jedynie jednym z etapów jej tworzenia (krok), procesem biznesowym jest wystawienie faktury,  ale nie jest nim samo jej zredagowanie (krok, kolejne zadanie) bo poza redagowaniem mamy także czynności sprawdzenia, księgowania i wydruku. Tak więc na najniższym poziomie hierarchii mamy proces Fakturowanie, dalsze szczegóły wystawienia faktury to procedura jej tworzenia składająca się z kolejnych, ustalonych kroków (zadań do wykonania).

Proces biznesowy Fakturowanie może być (i z reguły jest) częścią nadrzędnego procesu Realizacja zamówienia. Pierwszym produktem tego procesu jest Zamówienie gotowe do wykonania, proces ten to np. sekwencja Rejestracja Zamówienia i Weryfikacja Zamówienia. Cały proces Realizacji zamówienia ma więc dwa podprocesy:   Rejestracja zamówienia oraz następujący po nim proces biznesowy Fakturowanie. Produktem pierwszego jest Zatwierdzone zamówienie a produktem drugiego Faktura sprzedaży.

Poszczególne wewnętrzne kroki obu procesów, same z siebie, nie tworzą produktu (np. zarejestrowane ale niesprawdzone Zamówienie nie ma wartości biznesowej, to krok który należy wykonać ale nie jest to samodzielny proces biznesowy).

Popatrzmy na poniższy diagram:

Pokazuje trzy kluczowe poziomy procesowego opisu organizacji: na samym dole mamy zasoby, ich umiejętności wspierane procedurami. To warstwa realizacji, ta która jest udokumentowana w każdej niemalże organizacji jako zakresy obowiązków, procedury i zarządzenia. Najwyższa warstwa to kluczowe elementy strategii, architektura kluczowych procesów. Na tym poziomie można mówić o tak zwanych procesach end-2-end czyli o tym jak organizacja reaguje na bodźce zewnętrzne (np. na każde zapytanie ofertowe odsyłana jest oferta). Ten poziom także jest prawie zawsze udokumentowany jako strategia i plan marketingowy. Warstwa środkowa, procesy biznesowe, to abstrakcja opisująca (modelująca) logikę działania organizacji – jej wewnętrzny łańcuch wartości.

Popatrzmy teraz na jeden ze sposobów ustalenia liczby poziomów modelowania, bardzo często spotykany:

1. Level 1 ? End-to-end processes: Span across functions, e.g. market-to-cash.
2. Level 2 ? Main process areas: Typically function-specific, e.g. accounts receivables.
3. Level 3 ? Sub-processes: Sequence of related activities, e.g. goods invoicing.
4. Level 4 ? Activities: Key steps within sub-process, e.g. printing invoices.
5. Level 5 ? Tasks: Specific user actions or system transactions, e.g. send invoice to print. A step contains a description of how to perform the task.

(źr. Process Improvement at Carlsberg powered by ARIS from Software AG).

Poziom oznaczony Level-1 jak najbardziej mamy “zawsze”. Różnica pomiędzy poziomami 4 i 5 jest dla mnie niezrozumiała. Angielskie słowa acitivity i task to odpowiednio czynność i zadanie. Trudno mi sobie wyobrazić drukowanie faktury bez wysłania faktury do druku.  Czy to dwa poziomy szczegółowości? To co tu widzę, i nie tylko tu, to mieszanie  obszaru działania organizacji (ludzi) z obszarem realizowanym przez “zasoby”. To troszkę (podane przykłady) jak by ktoś uznał, że czynność (poziom 4) to zmiana biegu w samochodzie a zadanie (poziom 5) to zazębienie się właściwych kół zębatych w skrzyni biegów.  Ma to sens?

Poziomy 2 i 3 to modele procesów, liczba tych poziomów może być różna o czym dalej.

Przykład

Poniżej procesy end-2-end (celowo nie nadałem im rzeczywistych nazw by nie sugerować się konkretną firmą czy branżą):

Pokazuje jak organizacja reaguje na zdarzenia  generowane przez jej otoczenie biznesowe. Kolejny etap (poziom ?) to model (diagram) dla każdego tego procesu:

– proces A

– proces B

Proces A zawiera (tworzy) pośredni produkt (Dane 5) oraz produkt Dane4. Zgodnie z definicją procesu, oznacza to, że A składa się dwóch podprocesów, pierwszy tworzy produkt Dane5 a drugi Dane4. Proces tworzący Dane5 jest wykonywany np. na bazie wiedzy wykonawcy (rola), który posiada wymaganą umiejętność, ta jest opisana w dziale HR więc powielanie zapisów z karty obowiązków jest zbędne, wystarczy się na nią powołać w dokumentacji procesu. Czynność tworząca Dane4 jest na tyle  “złożona”, że wiedza wykonawcy to za mało (albo jest ryzyko, że się pomyli) dlatego dokumentujemy (formalizujemy) sposób tworzenia produktu Dane4 jako proces C składający się z określonych czynności:

Proszę zwrócić uwagę, że proces B i C to procedury (wewnątrz nie powstają produkty biznesowe), to tylko opis kroków jakie należy wykonać by powstał produkt procesu.  Procedury z powodzeniem można, zamiast tworzyć takie diagramy,  opisać znanym z projektów ISO strukturalnym tekstem, diagram raczej nie wnosi tu wartości dodanej.  Tworzenie diagramów dla procedur miało by sens, gdyby zrezygnować z procedur w formie tekstowej, w przeciwnym wypadku tworzymy redundantne opisy wymagające synchronizacji. W praktyce robi się tak, dokumentuje procedury diagramami, w przypadkach  gdy procedura jest złożona i jej opis tekstowy może być nieczytelny lub trudny w zrozumieniu. Analogicznie ma się sytuacja w przypadkach gdy sposób tworzenia produktu (proces biznesowy) w 100% jest efektem wiedzy posiadanej przez wykonawce (rola): tu powołujemy się wyłącznie na stosowne zapisy w dziale HR, nie tworzymy ich kopii w postaci diagramu.

Zobrazowanie powyższych diagramów, ich powiązań:

Tu mamy diagram obrazujący “podległość”, czyli to jak się one wzajemnie zagnieżdżają i to jak najbardziej obrazuje strukturę całego modelu.  Jednak próba ponumerowania konkretnych procesów i zbudowania ich hierarchii zachowującej drzewiastą logikę jest nierealna z powodu własnie tego, że procesy są inicjowane zdarzeniami, te zaś nie są “poziomowe” (np. proces opisany na początku archiwizacji dokumentu może się pojawić na każdym poziomie/diagramie). Numerować hierarchicznie jednak można diagramy, które jak widać, mają strukturę podobną do systemu folderów.

Ile więc mamy poziomów modelowania organizacji? Trzy (patrz pokazany wcześniej diagram BPTrends): najwyższy czyli strategia i procesy end-2-end,  najniższy czyli procedury i instrukcje stanowiskowe (implementacja) oraz środkowy czyli abstrakcję – model procesowy – opisującą jak to się wszystko do siebie ma (środkowy poziom ma strukturę zagnieżdżania się diagramów/modeli procesów jak wyżej ale procesy mają jedynie swoje nazwy jako identyfikatory).

Proszę zwrócić uwagę, że:

1. w zasadzie każda organizacja ma udokumentowany poziom najwyższy (strategia) i najniższy (procedury, zarządzenia, instrukcje)
2. warstwa środkowa jest tworzona wtedy, gdy chcemy zrozumieć wewnętrzne zależności, których może być dużo, i mogą być złożone  (zawiłe); to ile “poziomów” powstanie w warstwie środkowej, zależy wyłącznie od stopnia złożoności danej organizacji i zawsze jest to indywidualna jej cecha, tylko w części zależna od wielkości organizacji.

Często można się spotkać z nieformalnymi (o niezdefiniowanych granicach procesów) diagramami w postaci:

Poziom  najwyższy:

i poziomy niższe:

Czy taki diagram nam coś nam daje? Jest w zasadzie graficzną formą tekstowego (niejednoznacznego) opisu. 

Modelowanie procesów biznesowych to nie rysowanie diagramów, to tworzenie modeli, które poddają się walidacji i testowaniu zgodności z rzeczywistością. Poprawne modele pozwalają przewidywać reakcję organizacji na planowane zmiany. 

Na zakończenie

Modne ostatnio projekty modelowania procesów biznesowych z reguły, jako produkt, dostarczają niezliczone ilości “map procesów”, które kończą swój żywot na zakurzonych z czasem półkach, powstawały zbyt dużym kosztem by je wyrzucić do kosza. Ich stałe utrzymanie (aktualizacja) nie raz bywa kosztowniejsze od wytworzenia.

Po więc robimy te modele? Przytoczę znowu cytat inicjujący pewną dyskusję na forum: 

I think the only reason to conduct any project is to improve one or more processes. This means that if you don’t know which process(es) you are trying to improve, you should not start the project. Comments? (Process before project | LinkedIn).

W wolnym tłumaczeniu ;):

jeżeli uznamy, że jedynym powodem prowadzenia projektów jest usprawnianie określonych procesów biznesowych, to znaczy, że uruchamianie tych projektów bez wiedzy, które to dokładnie procesy i bez pełnego zrozumienia ich wpływu na organizację, projektów tych nie należy rozpoczynać.

Procesy modelujemy więc po to, by zrozumieć jak działa organizacja oraz po to, by przewidzieć jak się ona zachowa, jeżeli jakiś proces zmienimy, bo może się nie raz okazać, że nie warto się pewnych projektów podejmować z uwagi na skutki.

Modelowanie, jak widać, nie jest procesem obrazkowego zapisu tego co wiemy od pracowników tej czy innej firmy, to jest stenotypia. Modelowanie to trudny proces odkrywania prawdziwej logiki działania organizacji (i wypada mi teraz zaprosić na moje szkolenia :)).

Polecam także wcześniejszy artykuł o modelowaniu organizacji z perspektywy systemów zarządzania jakością ISO, bo projekty IT to nie jedyny przypadek gdy modelowanie organizacji bardzo pomaga.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Kolejne szkolenia za mną, projekty także. Od czasu do czasu audyt (lub ciche opinie) cudzych projektów. Stale widzę dwa poważne problemy w wielu tych dokumentach:

1. utrata panowania nad złożonością,
2. algorytmizacja.

W 2005 roku napisałem na zakończenie artykułu dot. modelowania:

Artykuł ten napisałem głównie po to by mogli Państwo także sami ocenić pracę firm, którym płacicie za tego typu usługi. Na pewno modelowanie wymaga długich studiów i doświadczenia ale efekty muszą być zrozumiałe. Nie jest ono możliwe bez udziału wyższej kadry firmy. Bieganie z ankietami po firmie to dokumentowanie stanu obecnego a nie modelowanie. Dokumentowanie procedur jest przydatne jako kolejny etap przygotowań do napisania dedykowanego oprogramowania ale jest nie potrzebne przed wdrożeniem gotowego systemu, który tylko podlega parametryzacji. Po drugie przed wdrożeniem czy napisaniem systemu konieczne jest zbudowanie modelu firmy choćby po to by upewnić się, że jest on optymalny. W przeciwnym wypadku możemy doprowadzić do utrwalenia w systemie złych i nieefektywnych procesów a w skrajnym przypadku panującego w niej bałaganu. ( Modelowanie biznesowe czyli pilnowanie hochsztaplerów).

od tamtej pory niestety w zasadzie nic sie nie zmieniło na rynku.

Pierwszy problem objawia się lawinowo rosnącą liczbą detali na diagramach i liczbą diagramów. Są nawet tacy, którzy uważają, że  poprawny model procesów biznesowych całej firmy, to setki diagramów. Bzdura. Dlaczego?

Czym jest model?

Model [łac. modulus ?miara?, ?wzór?], metodol. pojęcie oznaczające zarówno teoretyczny, jak i fizyczny obiekt, którego analiza lub obserwacja umożliwia poznawanie cech innego badanego (modelowanego) zjawiska, procesu lub obiektu. (źr. słownik j.p. PWN).

Tak więc cechą dobrego modelu jest możliwość jego testowania. Dobry model to uproszczenie rzeczywistości odwzorowujące jej ograniczenia w wybranym aspekcie. Jeżeli więc testujemy np. współczynnik oporu powietrza projektowanego samochodu, wymagany (i wystarczający) model, to reprezentacja kształtu karoserii a nie kompletna miniatura z silnikiem i siedzeniami.

Analizując organizację, tworzymy model w celu… i tu powinna paść nazwa konkretnego aspektu, perspektywy, którą chcemy badać. Analiza organizacji to element np.:

1. planu budowy nowego systemu zarządzania kosztami (np. [[metoda ABC t.j. zarządzania kosztami działań]]),
2. planu wdrożenia systemu Business Inteligence ([[model biznesowy jako narzędzie projektowania wielowymiarowego modelu hurtowni danych]]),
3. [[opracowania wymagań na oprogramowanie wspomagające zarządzanie]] (ma dwa główne aspekty: [[wybór gotowego oprogramowanie]] oraz [[specyfikacja wymagań na oprogramowanie dedykowane]]).

Podstawową decyzją jaką należy podjąć jest to, czego nie ujmować na tych modelach, a każdy powyżej ma inny kontekst. Każdy projekt, zawierający etap modelowania (modelowanie nie jest celem samym w sobie!) warto rozpoczynać od audytu.  Jego celem jest sprawdzenie jaką wiedzę o sobie samej posiada organizacja czyli ile z tego, co się dzieje w organizacji, jest udokumentowane. Nie musi to być wszystko. Dobrze zarządzana organizacja panuje nad swoją “ciągłością działania”, to jest rozumie jak działa i nie posiada punktu, który jako jeden decyduje o być albo nie być firmy. Typowym przykładem takiego punku jest jeden człowiek, skupiający na sobie kluczowe dla funkcjonowania firmy, kompetencje (np. szef produkcji). Z natury rzeczy ma to miejsce w każdej małej firmie, jednak im większa firma tym ryzyko jej funkcjonowania powinno być mniejsze. Podstawowym elementem zrozumienia mechanizmu funkcjonowania organizacji są reguły biznesowe i zdolności (wiedza) posiadanych zasobów. Opisałem to także w artykule Jak wyłuskać istotę rzeczy.

Złożoność i algorytmizacja. Typowy anty-przykład: proces zawarcia umowy, w którym udział bierze między innymi prawnik oraz Zarząd. Celem jest (między innymi) opinia prawna o treści umowy, uzgodnienie jej treści, na końcu pozyskanie właściwych podpisów (np. wymagane dwa a mamy pięciu członków zarządu). W tym miejscu pojawiają się zawiłe diagramy opisujące jakimi to ścieżkami przemieszcza się dokument (nie ma uwag – OK, są uwagi, odeślij do prawnika, uzupełnij, prześlij znowu do Zarządu, …, następnie pozyskaj podpis Prezesa, jeżeli prezes jest niedostępny, to…). Nawet nie mam ambicji narysowania tego potwora, jakim byłby taki diagram. Jak to mogło by wyglądać? Po pierwsze potrzebna jest specyfikacja stanowisk (ról w procesach) i kompetencji tych ludzi. Po drugie lista reguł (prawo, zarządzania wewnętrzne, procedury itp.). W efekcie powyższy proces to prosty przepływ: konsultacja treści umowy (prawnik ma wiedzę prawniczą, w ramach swoich uprawnień ma prawo do spotkań z Zarządem np. w celu skonsultowania treści umowy. Po uzgodnieniu treści umowy, np. Asystent Zarządu, który(a)  zna procedury i prawo (kolejna rola i kompetencje) zdobywa właściwe podpisy na umowie. Koniec! Gdzie szczegóły? Są! Proces jest, zakresy kompetencji są, prawo i zarządzenia są. Tą metodą, wtedy jest to audyt, można sprawdzić spójność zakresów obowiązków i zarządzeń wewnętrznych  z prawem oraz strategią firmy.

W wielu firmach system zarządzania jest tak niespójny, że jedynym sposobem funkcjonowania tych firm, jest łamanie zasad przez jej pracowników. Niestety pierwsza wpadka często powoduje załamanie się całego systemu (a nie raz i firmy). Wiele Zarządów firm nie zdaje sobie nawet sprawy z tego, jak duże jest ryzyko ciągłości funkcjonowania ich firm. 

Tak więc model procesu to nie algorytm działania firmy, wykazano nie raz, że algorytmizacja pracy ludzi jest niecelowa (wtedy stosujemy roboty).

Znaczna część tego co robią ludzie to efekt ich kompetencji, wiedzy i doświadczenia, a nie dyktowania im jak mają wykonywać swoja pracę.

Jeżeli wybierzemy drogę modelowania tego wszystkiego diagramami, to ilość tych diagramów szybko przekroczy granicę sensy całego projektu: nie będą czytane. Ich wartość będzie żadna.

W procesie dobrze przygotowanej analizy (jakiejkolwiek) modele tworzy się by je badać, a nie tylko po to by powstały za pieniądze sponsora projektu.

Na koniec ciekawy artykuł, opisujący jak stosować reguły biznesowe w modelowaniu procesów.

In creating a viable business solution, you need both a business process model and business rules ? not just one or the other. The trick is not to get them entangled, to remain clear about which is which. The good news is that by separating them you can simplify your business process models dramatically ? often by an order of magnitude or more. This discussion explains how. (za  Business Processes: Better with Business Rules).

P.S.

Widzę pewną korelację: najczęściej obecni lub dawni programiści robią najgorsze modele organizacji: mają tendencje to technokratycznej algorytmizacji opisu pracy ludzi, ignorują czynnik ludzki w modelach, patrzą na procesy w firmach przez pryzmat ograniczeń rozwiązań i technologii, które oferują ich pracodawcy. Podobne tendencje mają także ci, którzy podchodzą do tworzenia modeli procesów jak do “spisania metodami obrazkowymi tego co mówią pracownicy podczas wywiadów”. To także bardzo złe modele, zaryzykuję tezę, że gorsze od tych z rąk programistów.

Należy też nabrać pokory: większość organizacji sprawnie funkcjonuje nie mając żadnych modeli procesów, więc teza, że ich brak szkodzi jest nie do obrony. Po co więc te modele? Żeby zrozumieć dlaczego tak jest i co się stanie, gdy zechcemy wprowadzać zmiany.

Analiza biznesowa to dość duże wyzwanie. Nie polega tylko na zapisaniu z pomocą wywiadów tego, co firma robi. Chodzi o zrozumienie tego co dana firma robi i po co to robi. Powoli coraz więcej się mówi o modelach i notacjach. Stały się wręcz modne (bo, że pomagają to już wiadomo). Jednak celem analizy nie jest opracowanie modeli procesów, te są tylko narzędziem osiągania celu. Celem analizy jest odkrycie i wskazanie tego, co i na co ma wpływ w modelowanej organizacji.

Niejako standardem w projektach związanych z oprogramowaniem, są ostatnio notacje: BPMN na etapie tworzenia modeli biznesowych i notacja UML  na etapie projektowania oprogramowania (całego systemu). Od dłuższego czasu spotykam się z pewnymi ograniczeniami obu tych notacji.

W jednym z poprzednich  artykułów napiałem:

Na poziomie procesów biznesowych, stosuję zamiennie BPMN albo ArchiMate.  Z każdym kolejnym projektem skłaniam się jednak do używania na tym poziomie ArchiMate. Powodem jest to, że BPMN oferuje wyłącznie czyste pojęcia z definicji wykonawczej procesu (czynność, dane, zdarzenie, rola, pula, bramki). Na tym poziomie jednak, nie raz należy wyrazić rozdzielnie takie pojęcia jak rola i aktor (np. klient i kontrahent mogą pełnić rolę zamawiającego w procesie) albo pojęcia takie jak funkcje biznesowe (aktor wraz z zasobami jakich używa, pełni funkcję administracji wewnętrznej) albo usługi powiązanej z procesami (proces sprzedaży powiązany z usługą obsługi klienta). Przykłady można mnożyć. (Co jest wadą większości analiz biznesowych?).

Od czasu do czasu jestem pytany jak reprezentować System (oprogramowanie analizowane lub projektowane) na modelach BPMN. Niestety notacja ta nie ma takiego odrębnego pojęcia w swojej przestrzeni pojęciowej. Najczęściej spotykanym sposobem zobrazowania systemu na modelu procesu jest użycie dedykowanego toru (lane) dla zobrazowania oprogramowania i umieszczanie w nim czynności wykonywanych przez (z użyciem) oprogramowanie (od tej metody odszedłem kilka lat temu). Inna metoda to oznaczanie czynności związanych z użycie systemu stereotypem przypadek użycia (tę nadal stosuję). Pierwsza metoda moim  zdaniem łamie definicje roli w procesie. Jeżeli jakaś czynność jest realizowana przez osobę (aktora) używającą do pracy oprogramowania, pojawia się problem: co jest tu modelowane i gdzie się podział aktor skoro tor to system. Drugi sposób to użycie możliwości programu CASE użytego do analizy i niestandardowego wzbogacenia notacji o pojęcie stereotypu, którego formalnie BPMN nie ma. Jedno i drugie kłóci się także z modelowaniem etapu CIM ([[Computation Independent Model]]).

Jak już nie raz podkreślałem, siła formalnych notacji leży w ich bardzo dobrze opracowanym słowniku pojęć i relacji między tymi pojęciami. Łamanie tych zasad powoduje, że tak wykonana analiza staje się ryzykowna, gdyż pozwala na wprowadzanie niejednoznaczności w modelach.

Jednak problem istnieje… powstała notacja

ArchiMate

Notacja powstała w Telematica Institute, zyskała sobie własną tożsamość jako ArchiMate, została “wchłonięta” pod skrzydła The Open Group. Specyfikacja 1.0 powstała w 2004 roku więć notacja została już dość dobrze “przećwiczona”. Z niszowej stała się standardem. Obecnie stanowi oficjalne narzędzie modelowania w projektach na bazie metodyki TOGAF:

(źr. www.archimate.nl, obecnie TOGAF 9 i Archimate v.2.0; poprzednia ArchiMate v.1.0 zawierała tylko pojęcia z zakresu warstw biznesowej, aplikacji i technologii, pola zakreślone ukośną linią to rozszerzenie wprowadzone w wersji 2.0).

Ważne jest to, że notacja ta swoimi pojęciami biznesowymi, opisuje (modeluje) organizacje przekrojowo. W ramach systemu pojęciowego ArchiMate mamy trzy grupy pojęć dla trzech warstw modeli:

Jak widać słownik pojęć w warstwie biznesowej jest znacznie bogatszy niż w notacji BPMN. Każde pojęcie ma ściśle zdefiniowane znaczenie a znaczenia te (zasięg ich definicji) oczywiście nie zachodzą na siebie. Co nam to daje? Możliwe jest przeprowadzenie bardzo wnikliwej analizy logiki procesów biznesowych, skojarzenie jej z usługami systemu, jego funkcjonalnością i metodami implementacji. Czy ArchiMate zastępuje BPMN czy UML? Nie, ale pozwala uniknąć ich nadużywania i nadrabia ich braki w sferze biznesowych modeli abstrakcyjnych.

Jak już pisałem BPMN i UML to notacje, które powstały w celach “inżynierskich” tu, w inżynierii oprogramowania, są raczej bezkonkurencyjne.  Jednak są, moim zdaniem, zbyt ubogie i mało zrozumiałe do modelowania złożoności biznesowej. Pokażę to na przykładzie modelu procesu sprzedaży. Załóżmy, że w toku analizy udokumentowaliśmy proces fakturowania wraz z tym kto fakturuje, fakturą jako dokumentem i danymi. Chcemy następnie opracować specyfikację  usług, jakie planowany system miałby realizować, przyporządkować logicznie poszczególne usługi do grup (funkcjonalność systemu). Na koniec zaprojektować architekturę systemu.

Jak wspomniałem poprzednio, problem rozwiązuje stosowanie języka (notacji) adekwatnego do problemu. Tu pokażę przykład jak notacja ArchiMate radzi sobie z problemem łączenia biznesu, oprogramowania i technologii:

A gdzie BPMN i UML? Ano każdy proces (przyjęcie zamówienia, kompletacja, fakturowanie) w kontekście szczegółów przepływu pracy, modelowany byłby w notacji BPMN (konkretne role, dokumenty, czynności). Pozostałe warstwy operują pojęciami, których szczegóły  można (należy jeżeli taki jest zakres projektu) modelować już w notacji UML. Usługi mapują się na przypadki użycia, pozostałe to architektura: komponenty oprogramowania, dane, architektura techniczna.

Jak widać, ArchiMate pozwala na tym poziomie abstrakcji na więcej niż same BPMN czy UML, ale też nie zastępuje ich. Wzbogaca także system pojęciowy na potrzeby analizy biznesowej co pozwala wiernie odtworzyć rzeczywistość biznesową w sposób zrozumiały dla “biznesu”.  Jako podsumowanie przytoczę jeszcze raz znany już tu diagram:

(jak tworzyć modele ArchiMate  z pomocą narzędzia Agilian).

O architekturze korporacyjnej w kontekście analizy i projektowani innym razem. Teraz tylko kilka korzyści z posiadania takiego modelu:

1. możliwość wywodzenia wymagań na oprogramowanie w modelu biznesowego,
2. możliwość analizy wpływu i zależności usług biznesowych od infrastruktury IT (projekty związane z analizą ciągłości działania organizacji),
3. możliwość prowadzenia przekrojowych analiz ryzyka.

Więcej na temat samej Architekturze Korporacyjnej na stronie ArchitekturaKorporacyjna.pl, którą gorąco polecam.

Zainteresowanym notacją ArchiMate i jej używaniem polecam stronę ArchiMate Good practices.

___

P.S. Z uwagi na wady semantyczne notacji ArchiMate i rozpoczęcie przez The Open Group jej licencjonowania zarzuciłem stosowanie tej notacji (2012). Nadal udzielam konsultacji w zakresie recenzowania modeli wykonanych w tej notacji.