W analizie biznesowej przede wszystkim staramy się zrozumieć problem klienta – zarówno od strony oczekiwań, celów, sposobu działania (tego obecnego i tego pożądanego), jak i z punktu widzenia rozwiązania problemu, oprogramowania itd. Dzisiaj kilka słów o tym pierwszym aspekcie. Jak właściwie zrozumieć klienta w aspekcie jego działania? Jesteśmy po przeczytaniu opasłej dokumentacji organizacyjnej, rozmowie z wieloma mądrymi ludźmi i zapoznaniu się z dziesiątkami ich rysunków. Bo rysunki klient jakieś ma. Przecież rysunek mówi więcej, niż słowo pisane. Po licznych wywiadach mniej więcej znamy działanie organizacji. Mniej więcej, bo relacje różnych osób nie pokrywają się zupełnie, tak przynajmniej czujemy przez skórę. Słuchając opowieści managerów bądź specjalistów dziedzinowych czujemy, że przedstawiają nam opowiadanie o wspólnym świecie, każdy jednak ze swojej perspektywy. Nie możemy potwierdzić, że opis jest spójny, pozbawiony dziur, że wszystkie aspekty i działania wyczerpują temat. Rozmowa jest kluczowa, pozwala dzielić się myślami, poglądami, opisem działania. Jak uchwycić perspektywę organizacji? Jak zweryfikować, a przede wszystkim jak zbudować obraz działania firmy w danym obszarze, którym obejmować będziemy analizą? Niezbędny będzie model, najpierw procesowy a szerzej – model całego kontekstu biznesowego wokół procesów. Dzisiaj będzie o tym.

Model analityczny

Niedawno wspominałem, jest nim abstrakcyjny uproszczony obraz złożonego świata, który pozwala nam przede wszystkim zrozumieć dziedzinę, zweryfikować nasze rozumienie a następnie zaplanować dalsze działania. Model to często rysunek (choć spotkałem się też z modelem analitycznym pisanym słownie – ubranym w szablony, mniej przystępnym ale nadal nadającym się do pracy z nim). Model może być rysunkiem, ale nie zawsze rysunek jest modelem. Czym różni się rysunek od modelu? Rysunek w kontekście analizy to obraz myśli zapisany graficznie. Model pozwala na jednoznaczną komunikację naszych myśli i weryfikację ich słuszności. To użycie tych rysunków do zobrazowania wszystkich rysowanych aspektów. Model to jednolite zasady, prawidłowości a następnie odzwierciedlone powiązania i ograniczenia, umieszczone w odpowiednim narzędziu pozwalającym zachować spójność informacyjną między artefaktami i zarządzić ich zmianą. Artefakty te opisują różne obszary, powstają w różnym czasie, miejscu, tworzone są przez różnych autorów i przy okazji różnych inicjatyw (projektów). Jeśli dysponujemy jedynie zestawem rysunków procesów, zmiana jednego z nich nie pozwoli ocenić zmiany pozostałych. Nie mamy wówczas narzędzia do zbadania jak jeden rysunek wpłynie na inny. Zmiana diagramu w modelu, osadzony w kontekście, wymusza weryfikację spójności zmiany i wpływu na inne obszary. Pozwala wyśledzić wpływ, bo są powiązania. Podobnie tworząc nowy diagram, tworzymy go w kontekście opisanego już świata (architektury biznesowej): zarówno procesowego, pojęć jak i obiektów biznesowych. I w kontekście tego świata powstający proces opisujemy – odnosząc do obecnych charakterystyk, procesów, przebiegów i powiązań, danych czy obiektów biznesowych i ich struktur.

Model procesowy stanowi część architektury biznesowej organizacji, co analityka biznesowego będzie interesować o tyle, że procesy nie są bytem niezależnym. Procesy identyfikowane w ramach organizacji wiązane są z produktami i usługami których dotyczą, kanałami ich oferowania, celami itd. Identyfikując zmianę organizacyjną na poziomie produktu, jaki organizacja oferuje, otrzymamy informację jakiego obszaru procesowości zmiana będzie dotyczyła. Mamy więc powiązanie proces – produkt/ usługa – kanał, często jeszcze segment klienta. Podobnie przebudowa procesu wiązać się będzie w pływem choćby na produkt, jego kompletność (a może wiązać się będzie z jego pogorszeniem), cel itp.

Czasami już sama konstrukcja architektury procesów uwzględnia podział na ww. obszary. Otrzymywany jest wówczas zbiór grup procesów zidentyfikowanych jako iloczyn kartezjański: produktów, kanałów oferowania, kanałów obsługi, segmentów klienta… czegoś jeszcze?

Model opisywany jest przez obszar procesowy. Opisuje on z jednej strony zidentyfikowane procesy wraz z ich przebiegami, z drugiej strukturę, zależności i powiązania między procesami (bądź hierarchię – w zależności od metodyki, jaka została zastosowana do stworzenia architektura procesów, o czym napiszę mam nadzieję niedługo). Powiązania zaszyte są w przebieg procesów. Oznacza to, że dodając kolejny proces będę musiał zweryfikować czy jego inicjacja jest wynikiem działania innego procesu, czy zdarzenia zewnętrznego. Modyfikując proces powinienem zweryfikować jak modyfikacja wpłynie na inne procesy, w jaki sposób.

Obszar obiektów biznesowych i danych to kolejny obszar wpływający na procesy. Procesy przekazują obiekty danych, pewne dane potrzebne są na ich wejściu, pewne dostarczane są w trakcie trwania, inne są wynikiem działania procesów. Obiekty biznesowe przybierają swoją fizyczną reprezentację (dowód osobisty, umowa, wniosek papierowy) bądź niematerialną (wniosek elektroniczny). Utrzymując model dziedziny zintegrowany z procesami, przy modyfikacji procesu biznesowego zobaczę jak modyfikacja wpływa na obszar informacji jakie są niezbędne po pozyskania (być może w innym procesie), jakie z nich znajdą się w formie bardziej „materialnej”. Usuwając natomiast z ekosystemu organizacji konkretny wniosek, umowę czy dyspozycję bądź ingerując w jego zmiany zobaczę jak zmiana ta wpłynie na przebieg procesów i czy „naprawa” świata organizacji w jednym miejscu nie „zepsuje” nam innej.

Kolejną kwestią jest dobra definicja obiektów biznesowych, pozwalająca na zachowanie precyzji opisu wymaganej do dobrego rozumienia biznesu. Precyzji, która pozwoli uchwycić różnice w sposobie pojmowania tej samej kwestii w różnych miejscach organizacji (dyspozycja vs wniosek, kredyt vs rachunek kredytowy vs rachunek do obsługi kredytu). Często rozmawiamy o tym samym używając innych terminów. Czasem używając te same terminy i pojęcia mamy na myśli inne rzeczy. Ot, przyzwyczajenie z danego obszaru, przyjęte w naszym otoczeniu słownictwo, czy nowomowa korporacyjna. O modelu dziedziny/ modelu pojęć i wpływie na świat procesów można by napisać wiele, dlatego postaram się poświęcić inny wątek temu zagadnieniu.

Kolejnym jest obszar reguł biznesowych. Reguły bezpośrednio związane z procesami wyznaczają pewne ograniczenia względem elementów, narzucają określone zachowania, określają w jaki sposób pokierować zachowaniami biznesowymi wewnątrz aktywności w procesie. Zmiana reguły na poziomie organizacyjnym (np. ograniczeń co do wieku kredytobiorcy) może istotnie wpłynąć na przebieg procesu bądź zablokować jego realizację.

A wszystko to łączy się razem. Jeśli nie jestem świadomy powiązania i zależności między procesami, nie wiem jak zmiana w jednym wpłynie na inny. Brak takiej wiedzy odbije się na powodzeniu przedsięwzięcia, na „nieoczekiwanych” odkryciach, które wydłużają inicjatywę, bo pod jej koniec „nagle” oczekuje się, że nasz projekt wywraca jakąś część dobrze działającej organizacji. Przecież rysowaliśmy. Ale był to tylko wąski kontekst. A można by tego dowiedzieć się z modelu znacznie wcześniej. Jeśli nie jestem świadomy powiązań procesu (procesów) z obiektami biznesowymi, danymi biznesowymi utrzymywanymi na poziomie organizacji, wpływ zmiany w obrębie procesu może doprowadzić do utraty informacji w innym procesie, a zatem znów kiedyś może się okazać, że „wyskoczy” nam niespodzianka przed samym wdrożeniem (a nawet gorzej, po).

Praca na rysunkach to praca „na szybko”. Same rysunki nie dadzą nam wymaganej odpowiedzi. Same rysunki wizualizują i pozwalają zrozumieć jedynie pewien aspekt w bardzo niedoskonały sposób. Aspektów do uwzględnienia w analizie biznesu jest wiele, pracujemy bowiem na skomplikowanym systemie naczyń połączonych. Dlatego zrozumieć znaczy dobrze zdefiniować a następnie stworzyć dobry model, wewnętrznie spójny i zawierający dokładnie tyle informacji, ile jest potrzebnych aby efektywnie działać.

Na koniec jedno „Ale”

Aaaale model jest ciężki, bo to dużo pracy i dużo klikania. Owszem, z jednej strony wymaga pewnego nakładu pracy: w porównaniu do braku modelu – dużego (bo nie tworzyliśmy, a musimy zacząć to robić), w porównaniu do rysowania już nie tak znaczącego. Wymaga trzymania się pewnych stałych zasad (i ich ciągłej weryfikacji). Wymaga wersjonowania, bo się zmienia i jego części mogą odnosić się do opisów sprzed zmiany. Jednak z drugiej strony pozwala rozumieć i analizować. Pozwala działać na opisie rzeczywistości, a nie hipotezie względem niej, czy prawdopodobieństwie jej rozumienia. Jeśli czegoś nie umiem opisać i osadzić w kontekście, z dużym prawdopodobieństwem tego nie rozumiem. Tworząc model zadaję pytania, których nie zadam bez niego. Budując model zapewniam sobie platformę komunikacyjną z członkami zespołu ale też z innymi częściami organizacji. Badam wpływ, badam konsekwencje. Nie tylko rysuję, ale analizuję, porządkuję bowiem myślenie wokół aspektów, które są wymagane aby rozwiązanie zadziałało. A inne nasuwają mi się same.

I wreszcie naprawdę na sam koniec. Tworząc oprogramowanie decydujemy się na używanie mniej lub bardziej skomplikowanych języków programowania, platform, technologii. Nie robimy nic na skróty, bo szybko wyjdą problemy. Brak logowania błędów szybko zemści się przy utrzymaniu produkcyjnym rozwiązania. Podobnie nie stosujemy dowolnie składni języka, bo nie zadziała. Polecenie czy nazwa metody oznacza dokładnie to, co określił twórca i zadziała zgodnie ze swoim przeznaczeniem. Kodowanie wymaga precyzji. Dlaczego by uciekać od modelowania biznesu i pomijać jednoznaczność jego opisu? Konsekwencje programistyczne rozwiążemy naprawą kodu. Czasem kosztowną, acz nie tak, jak konsekwencje decyzji biznesowych podejmowanych w oparciu o hipotezy tego jak działamy i o prawdopodobieństwo rozumienia organizacji…