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

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 . Nawiążę także do mało popularnej a ciekawej i bardzo skutecznej metodyki usprawniania organizacji, także opartej na idealizacji, opisanej przez Ackof’a .

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

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

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

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

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 i ponad 20 lat temu : 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