W kończącym się roku trzy razy miałem do czynienia z nie małymi (czytaj kosztownymi) dokumentami zawierającymi „modele procesów biznesowych” i „specyfikację wymagań”. Wszystkie trzy miały pewne wspólne cechy:

1. były problemy z przydatnością tych dokumentów, co było powodem poproszenia mnie o ocenę i rekomendacje w kwestii ich naprawy,
2. wszystkie były produktem zbiorowych „warsztatów procesowych” i „warsztatów wymagań” z pracownikami modelowanej firmy,
3. żaden nie nadawał się do użycia jako materiał do stworzenia oprogramowania, mimo, że wszystkie one były produktem pierwszego etapu projektu o nazwie „analiza przed-wdrożeniowa”,
4. wszystkie cierpiały na problem nadmiaru szczegółów, niejednoznaczności i braku spójności.

Jedenaście lat temu (tak jedenaście!) napisałem:

Często firmy oferują usługę i produkt Model (mapę) Procesów Biznesowych. Co dają? Dają nieudolnie zrobiony opis procedur, niesłusznie nazwanych procesami. Setki schematów obrazujących kto, co i jak robi. A po co to robi? Tego tam z reguły nie opisano! Dziesiątki i setki stron diagramów, które lądują na półce i nie są używane podczas wdrożenia. Powstaje opracowanie, które jest niezrozumiałe przez zarząd firmy zlecającej tę pracę. Zarząd nie przyzna się, że nie rozumie bo podobno to znana firma doradcza lub wdrożeniowa opracowała. A moim zdaniem, jeżeli Zarząd nie potrafi zrozumieć udokumentowanego obrazu własnej firmy to dokument jest do kitu a nie Zarząd. (Modelowanie biznesowe czyli pilnowanie hochsztaplerów).

Dlaczego tak jest?  Dlaczego tak bardzo popularne są tego typu warsztaty a nie rzetelne, dające wysokiej jakości produkty, analizy?

Obserwacja gry vs. reguły gry

To co się dzieje na stole bilardowym (metafora z książki M.Fowlera ) można opisać z pomocą praw fizyki i reguł gry w bilarda. To co obserwujemy na szachownicy (metafora z bloga Paula Harmona ) to wynik reguł gry, doświadczenia i klasycznych zagrywek. W obu przypadkach dochodzą też do głosu wiedza i umiejętności graczy. Piłka nożna to reguły gry, prawa fizyki (tor piłki po kopnięciu piłki)  i umiejętności zawodników. Można tu podać wiele innych przykładów efektów łącznego istnienia określonych reguł oraz umiejętności ludzi.

Każda organizacja (firma, urząd, inne) to ludzie z ich wiedzą i umiejętnościami  oraz reguły „gry” czyli obowiązujące Prawo i wewnętrzne regulacje. I teraz pojawia się pytanie:

Czym jest model organizacji?

Przede wszystkim model to uproszczenie rzeczywistości, jednak stopień tego uproszczenia nie jest przypadkowy. To co upraszczamy (pomijane szczegóły) zależy od kontekstu w jakim ten model będzie użyty, bo tworzenie modelu na jeden cel: użycie go w konkretnym celu. Tu „niestety” wkracza nauka, mam na myśli podejście (metoda naukowa w analizie).

Modelowanie polega na abstrahowaniu od określonych szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm, jednak obserwowalna zmiana stanów ?maszyny? nie jest modelem (opisem) mechanizmu jej działania

Spójrzmy na to od końca. Aby powstało jakiekolwiek narzędzie wspomagające pracę np. ludzi wykonujących swoje obowiązki w organizacji, narzędziem takim jest także oprogramowanie (czyli aplikacje), musi powstać opis tego narzędzia. Aplikacje to także narzędzia. Tworzymy je głównie z dwóch powodów: tworzymy elektroniczne wersje kartotek (rejestrów) oraz tworzymy elektroniczne wersje określonych umiejętności (np. wyliczanie pierwiastków w kalkulatorze). Tak więc aby zamówić u developera Kartotekę musimy ją opisać i to jest relatywnie proste: tworzymy wzór Kartoteki, np. kartoteki pracownika, książki w bibliotece itp. Nieco trudniej jest opisać (udokumentować) umiejętność, zresztą najpierw trzeba ja jakoś zdefiniować. Umiejętności, tu wymagane, mogą być różne: od umiejętności weryfikacji danych wprowadzanych do kartotek aż do umiejętności wytwarzania nowych informacji na bazie tych dostępnych w kartotekach. Np. utworzenie faktury sprzedaży wymaga skorzystania z kartoteki klientów, z kartoteki oferowanych towarów i usług, kartoteki towarów dostępnych w magazynie, trzeba także posiadać umiejętność poprawnego wyliczenia wartości podatków na formularzu faktury, mogą do tego  dojść upusty zależne od wielu czynników: wartości zakupu, aktualnych promocji, status kupującego i wiele innych. Inny przykład: zarejestrowanie nowego dokumentu w archiwum wymaga skorzystania z kartoteki dokumentów oraz umiejętności nadania dokumentowi specjalnego znaku, sygnatury.

I tu wpadamy w efekt „kręcenia filmu”. Najczęściej tak zwana analiza  wygląda tak, że pracownicy analizowanej firmy, w toku warsztatów lub wywiadów, opowiadają z jakimi to sytuacjami mają do czynienia, co robią, kiedy i jak, opisując konkretne przypadki z jakimi mieli do czynienia  i to, jak sobie z nimi poradzili. Do tego dochodzą przypadki, w których sobie słabo poradzili, przypadki tego jak sobie radzą z tym, że czegoś nie rozumieją, a to wszystko jest okraszone  sposobami pracy wynikającymi nie raz z niewiedzy, nieznajomości prawa czy wewnętrznych regulacji. Na domiar złego, nie raz można się spotkać z przypadkami, w których opowiadający o swojej pracy wplata elementy pozwalające mu na działania niepożądane takie jak upraszczanie  procedur lub wręcz łamanie prawa (np. swego czasu pewien urzędnik na moich oczach w trakcie warsztatów zgłosił jako wymaganie wobec systemu obiegu dokumentów, możliwość podpisania orzeczenia sędziego przeterminowanym podpisem elektronicznym!).

Dokumenty, które dostaję do recenzji, to często właśnie zapisy, wręcz stenogramy z takich spotkań, i nie ma znaczenia czy to zapisy „prozą” czy zapisy w postaci obrazkowej z użyciem notacji BPMN czy UML (gdzie notacja jest wykorzystywana raczej jako biblioteka symboli a nie narzędzie z jego syntaktyką i semantyką). To dokumenty, które stanowią rodzaj stenogramu z rozmów, są jak filmy nakręcone podczas rozgrywania partii szachów lub bilarda: miłe w oglądaniu, długie, kosztowne i kompletnie nieprzydatne do napisania komputerowej gry.

Do opisania  każdej  z ww. gier (bilard, szachy), a także do opisania tego jak funkcjonuje organizacja, wystarczy dokument opisujący zasady gry (reguły biznesowe) oraz minimalną wiedzę i umiejętności graczy oraz to jakie i w jakiej kolejności rzeczy maja powstać czyli model procesów biznesowych. Model procesów jednak to nie jest „film” opisujący czyjąś pracę a logiczny łańcuch aktywności tworzących, każda, przydatny biznesowi produkt.

Jaki opis powstanie po przeprowadzeniu kilku dni warsztatów z graczami, którzy grają od lat, zasady gry znają na pamięć,  bywa ze podejmują próby łamania zasad dla osiągnięcia doraźnych efektów? To będą długie, nie raz niespójne wywody. Każdą z wymienionych gier opisują jednak jednoznacznie dwa bardzo krótkie dokumenty: reguły gry oraz minimalne umiejętności i wiedza każdego z graczy. Z takim dokumentem każdy projektant oprogramowania sobie poradzi bez problemu.

Niestety wiele produktów etapu projektu o nazwie analiza przed-wdrożeniowa to tak zwane malowanie trawy: kawał kosztownej i nikomu nie przydatnej pracy.

Jakiś temu pisałem z innej okazji:

Niestety, podczas tak zwanych typowych analiz, opartych na wywiadach  i spotkaniach warsztatowych, im więcej interakcji tym większe pole do manipulacji i perswazji (świadomej lub nie, ale jednak). Po drugie, nie ma żadnej gwarancji, że niczego nie pominięto (w takich rozmowach w zasadzie omawiane są rzeczy ciekawe i rzadkie a prawie nigdy oczywiste). […]

Drugim problemem i poważnym błędem jest uznanie, że ?skoro te analizy to spotkania i zapisywanie ich wyników, to może to robić niemalże każdy byle był komunikatywny?. Bzdura. Po pierwsze takie działanie to nie są analizy a stenogramy ze spotkań, po drugie są one zapisem subiektywnego oglądu sytuacji, jaki mają odpytywani pracownicy danej firmy (do tego z ich tylko perspektywy). (Nowoczesne technologie w służbie zdrowia, czyli telemedycyna w projektach IT).

Dlatego rolą analityka biznesowego nie jest spisanie przebiegu dziesiątek wywiadów i setek indywidualnych wymagań. Nie mają większego sensu dokumenty na setki i tysiące stron (nikt ich nie czyta!). Rolą analityka biznesowego jest przeanalizowanie dostępnych dokumentów, informacji, i stworzenie opisu mechanizmu działania organizacji oraz opisu rozwiązania, narzędzia mogącego usprawnić działanie organizacji. Opisu zawierającego reguły biznesowe, przetwarzane informacje (wzory dokumentów) oraz listą usług jakie ma świadczyć planowana do wdrożenia aplikacja wraz z opisem tego, jak te usługi mają być realizowane (umiejętności, które można zautomatyzować).  Sens mają więc zwięzłe opisy i modele mechanizmów działania organizacji oraz opisy tego jakie informacje i jak mają być przetwarzane z uwzględnieniem tego, że część tych prac nadal będą wykonywali ludzie. Takie jak reguły gry w szachy: ważne są dwie strony opisu reguł gry a nie setki stron opisów przykładowych partii.

Bardzo często słyszę od developerów, że większość dokumentów jakie dostają jest nieprzydatna. Nie raz zastanawiam się, dlaczego mimo to większość usługodawców tworzy tak nieprzydatne dokumenty? Najprawdopodobniej dlatego, że słuchanie i stenografowanie jest łatwe…  Z drugiej strony, nie raz niestety sami zamawiający chcą takich właśnie dokumentów, Ci jednak są usprawiedliwieni, bo to nie oni są analitykami. Ci ostatni sami decydują jakimi analitykami są…

Drugim powodem jest dość powszechny brak umiejętności abstrakcyjnego myślenia. Problem ten widać często na etapie modelowania procesów biznesowych: zamulanie zbędnymi szczegółami.  Bardzo wielu analityków ma skłonności do wgłębiania się w nieistotne szczegóły, to właśnie objaw braku umiejętności tworzenia abstrakcji. Do tego stopnia, że powstał pomysł na sformalizowanie zajmowanie się tymi szczegółami (Case Management).  Ciekawa dyskusja na ten temat pojawiła się na LinkedIn. Ja ze swej strony polecam artykuł (Case Managemet) oraz wypowiedzi Paula Harmona w dyskusji:

At the process level, we want the ability to describe and organize a generic set of activities. We might be concerned, for example, with how we organize Hotel Guest Services. To be clear what we mean by organizing Hotel Guest Services, we might talk about a specific instance in which a hotel organized guest services. One of the things we might decide, for example, was that the hotel wanted everyone to use the guest’s name. Thus, we might think of all of the activities in which employees might interact, and ponder how we would provide each set of employees with each guest’s name. It obviously wouldn’t be a matter of simply notifying one group — like those who take restaurant reservations of who is in what room — since, as Roger suggests, a hotel guest could proceed in any order, going to the pool, or to a conference session, or proceeding to make a restaurant reservation. In this case we are probably talking about putting information into a database from which various employees could easily retrieve it. Processes are dynamic and complex, in part, because the generic process description isn’t as prescriptive as it would be in a production line, where the stations are set and the behaviors expected at each station are well defined. They are „cases” because each instance of the process uses a different set of activities in a different order — as in the Rescue Hostage example. When we plan for a Rescue Hostage case or project if you prefer, we develop a series of scenarios, and practice a large set of activities. When the time comes to execute the process, we begin by planning for the specific instance case. The idea that we start the process with a generic: Plan for the Specific Rescue Effort, activity may be generic, but any detailed example of it will be an instance, since in the very nature of the planning we are tailoring to the specific instance. (Case Management Approaches | LinkedIn).

Od pewnego czasu (2013 rok) modny stał sie „event storming”:

Metoda warsztatowa, która pozwala szybko dowiedzieć się, co dzieje się w dziedzinie badanego problemu. W porównaniu z innymi metodami jest to metoda niezwykle lekka i celowo nie wymaga wsparcia ze strony komputera. Wynik jest wyrażony w postaci karteczek samoprzylepnych na szerokiej ścianie. Proces biznesowy jest ?odkrywany” jako seria zdarzeń w analizowanej dziedzinie, które są oznaczone jako przyklejone na ścianie pomarańczowe karteczki. Event storming został wymyślony przez Alberto Brandoliniego w kontekście projektowania opartego na dziedzinie problemu (Domain Driven Design). Event storming może być wykorzystana jako środek do modelowania procesów biznesowych i do inżynierii wymagań. Podstawową ideą jest zgromadzenie programistów i ekspertów dziedzinowych by uczyli się od siebie. Aby ułatwić ten proces wzajemnego uczenia się, event storming ma być zabawą. Nazwa została wybrana, aby pokazać, że należy skoncentrować się na zdarzeniach w analizowanej dziedzinie, a metoda działa podobnie do burzy mózgów w modelowaniu zwinnym.

(https://en.wikipedia.org/wiki/Event_storming)

Czy widzicie już problem? Tak! To próba stworzenia komputerowej gry w bilarda lub szachy na podstawie rozmowy z graczami o ich rozgrywkach. Podobnie wyglądała by próba napisania gdy Wyścigi samochodowe na podstawie wielogodzinnych warsztatów z kierowcami… zamiast po prostu pozyskać model samochodu i opis praw fizyki ruchu ciała stałego, a kierowcom dać spokój… Skąd sie biorą takie pomysły na prowadzenie analiz? Jeżeli z rozmowy o wyścigach samochodowych wyrzucicie nauczyciela fizyki to będziecie musieli radzić sobie opisując każdy możliwy zakręt po kolei: to będą „eventy” i będą ich ogromne ilości… A kwota na fakturze za to będzie duża…

Źródła