Wstęp
Nagle na kilku grupach dyskusyjnych pojawiły sie ostatnio pytania jak sprzedać modelowanie procesów. Popularyzuje się chyba notacja BPMN (Business Process Modeling Notation, zestaw symboli i zasad ich użycia do modelowania procesów w organizacjach, ) i biblioteki symboli do MS Visio a także notacja UML (Unified Modeling Language, zestaw symboli do dokumentowania analizy obiektowej i obiektowych modeli systemów informacyjnych, ). Nie jedna rozmowa pozwoliła mi szybko się przekonać się, że chodzi o rysowanie a nie o modelowanie. Bo model procesu opisuje zjawisko i jest zrozumiały zaś rysunek procesu to obrazek pokazujący tylko to powiedział pan Jan w trakcie wywiadu a rysownik to skrzętnie narysował, najczęściej jakimś fajnym programem do rysowania diagramów, nie raz jest to MS Visio.
Jak już na jednej z tych grup napisałem, rysunki zawsze można tworzyć i sprzedawać i są tacy co je kupują, modelowanie zaś to wstęp do analizy modelowanego zjawiska, a jest nim także proces biznesowy.
Uważam także, że do modelowania potrzebna jest znajomość ogólnej teorii systemów, teorii modeli i analizy obiektowej w przypadku UML, do modelowania firm i organizacji dodatkowo wiedza z teorii zarządzania. Bez tego można np. wieżę Eiffla nie zamodelować (stworzyć jej model) a co najwyżej ją narysować, nawet bardzo ładnie ale bez zrozumienia tego jak powstała i dlaczego się jeszcze nie zawaliła.
Czym sie różni rysunek wieży Eiffla od modelu tejże wieży? No tym, że rysunek poza tym, że nie raz ładnie wygląda na ścianie nie przyda się do analizy odporności wieży na podmuchy wiatru, nie przyda się do oceny jej sztywności, nie przyda sie nawet do dokładnego wyliczenia ile czasu będzie spadał z niej samobójca (teraz jest siatka więc już nie spadają). Dziś powiem troszkę o modelach jakimi są także mapy procesów, nie będziemy modelowali statków.
Prawdziwy model
Modelowanie polega na abstrahowaniu od szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm .
Model to przede wszystkim narzędzie analityczne i komunikacyjne. Analityczne bo model powinien, bez potrzeby kontaktu z pierwowzorem, zachowywać sie tak jak on (w wybranym kontekście oczywiście). Komunikacyjny bo powinien być zrozumiały dla osoby nie biorącej udziału w jego tworzeniu. Po trzecie model powinien odwzorowywać istotę badanego zjawiska a nie kopiować jego poboczne cechy lub opisywać nie wnoszące nic do badania informacje oczywiste lub wręcz zaciemniające istotę problemu. Model wieży Eiffla do celów zbadania oporów powietrza nie musi zawierać informacji o kolorze i o tym ile schodów należy pokonać by na nią wejść. Na tej samej zasadzie rysowanie na diagramie faktu, że np. dokument jest komukolwiek przekazywany z ręki do ręki jest rysownictwem a nie modelowaniem.
Nie będę tu rozwijał tego wątku gdyż temat dokładnie zdefiniowałem w treści mojego kursu (patrz koniec tego tekstu) ale tu kilka przykładów. Oferta w pewnej firmie jest tworzona przez handlowca, zatwierdza ją dodatkowo jego przełożony jeżeli wartość oferty przekracza 10.000zł. Handlowiec pracujący krócej niż kwartał zanosi do zatwierdzenia wszystkie swoje oferty. Na diagramie, który swego czasu audytowałem było sześć czynności (sześć prostokącików) nazwanych „Przekazanie dokumentu…”. Konia z rzędem temu kto pokaże tu wartość dodaną (patrz słownikowa definicja procesu biznesowego). Skoro jedna osoba dokument przygotowała a druga go czyta to oczywistym jest, że dokument musi zostać tej osobie przekazany. Nie musimy (i nie powinniśmy) pisać tego w jaki sposób się to stało bo może to ulec zmianie bez utraty istoty procesu (następstwa czynności) ot choćby po wprowadzeniu elektronicznego obiegu dokumentów (tu ewentualnie jest miejsce na modelowanie wymagań funkcjonalnych na system IT ale to inny model!).
Pierwsza rada dla Państwa: jeżeli osoba modelująca Wam procesy umieści na diagramach czynności oczywiste to znaczy, że jest to rysownik a nie modelarz. Bo jeżeli nawet np. czynność przekazania dokumentu jest istotna z powodów czasowych a planujemy symulacje czasu trwania procesu na podstawie tego modelu to należy ją połączyć z procesem (czynnością) opracowania dokumentu bo celem procesu opracowania dokumentu jest to by znalazł sie on w rękach osoby, dla której został przygotowany i musi do niej dotrzeć co jest oczywiste. Pomijam, że osobiście nie widzę nic wartościowego w takich symulacjach ale to moje subiektywne zdanie.
Drugi przykład (także z życia). W pewnej instytucji (nie mogę zdradzić jakiej niestety, jest to ważna instytucja) uaktualniałem modele procesów i dodawałem nowe. Jakież było moje zaskoczenie gdy znalazłem na jednym z diagramów niemalże algorytm obsługi sprzętu służącego do przekazywania depesz. Proces wysłania lub odebrania depeszy tym sprzętem jest dokładnie opisany w instrukcji obsługi. Sam proces odebrania lub wysłania zawsze ma ten sam cel, sprzęt może zostać wymieniony na nowszy, jednak proces nie ulegnie zmianie a tu proszę: obrazkowy model instrukcji obsługi! Po drugie sprzęt jest typowy dla tego typu instytucji i umiejętność jego obsługi jest zapisana w oczekiwanych kwalifikacjach pracowników zatrudnianych w tej organizacji (oczekiwane kompetencje na tym stanowisku opisane w dziale kadr). Tak więc jeżeli ktoś Państwu „modeluje” podręczniki lub kompetencje pracownika to jest to rysownik a nie modelarz. Tu niestety tym rysownikiem był konsultant rodem z międzynarodowej korporacji. Nie chodzi mi o krytykę tejże korporacji bo ma ona nie małe osiągnięcia na polu modelowania właśnie procesów, jednak dlaczego wysłali rysownika? Nie wiem.
Tak więc model procesów biznesowych, którego celem jest opisanie tego jak powstaje wartość dodana w firmie i jak jest firma zorganizowana nie powinien zawierać algorytmów pracy, opisów czynności oczywistych czy też opisów oczekiwanych kompetencji. Wtedy modele procesów są na prawdę wartościowymi dokumentami, nie są to setki stron papieru, można je przeczytać bez potrzeby wlewania w siebie litrów RedBull’a, opisują sedno rzeczy, doskonale nadają się np. do sprecyzowania wymagań na system IT czy też wdrożenia Zrównoważonej Karty Wyników.
Nie zapominajmy jednak, że rysownicy rozliczają się z ilości papieru a modelarze z liczby modeli zaś dobry model procesów jest jak wiersz: sztuką jest jego stworzenie ale do przeczytania powinna wystarczyć znajomość alfabetu i jeden wieczór. Niestety w wielu firmach spotykam się tylko z rysunkami i nie dziwię się, że prezesi tych firm nie widzą w tym sensu.
Krótko o narzędziach
Na zakończenie kilka słów o narzędziach pracy modelarza. Modele można robić ołówkiem na papierze i jest to także dobry sposób. Można sobie troszkę ułatwić rysowanie jakimś programem wspierającym analizy i tworzenia schematów blokowych. Jednak nie raz mamy do czynienia z modelami dużych organizacji, modelami zawierającymi wiele elementów i skomplikowanych zależności. Próba wykonania ich prostym narzędziem nie jest niemożliwa ale jest bardzo pracochłonna i obarczona ryzykiem powstania wielu błędów niespójności. W takich przypadkach faktycznie potrzebny jest kilku poziomowy system kontroli jakości by tego typu błędy wychwytywać, jest to jednak wyjątkowo kosztowny i czasochłonny proces (nawet kilku konsultantów zaangażowanych w wytworzenie jednego diagramu!).
Na szczęście na rynku dostępne są systemy dedykowane do tego typu pracy. Powszechnie nazywane są systemami typu BPM (Business Process Management) lub bardziej rozwinięte systemy CASE (Computer Aided System Engineering). Czy warto w nie inwestować? Warto. Bo wyobraźcie sobie Państwo, że Waszą pracę magisterską nafaszerowaną rysunkami z wielopoziomowym systemem rozdziałów i podrozdziałów, indeksów pojęć i przypisów zleciliście do przepisania osobie mającej do dyspozycji tylko Notatnik z systemu Windows a osoba ta rozlicza się z Wami za czas pracy. Tak właśnie wygląda praca z diagramami nie tylko w Visio bo znam takich co robią to za pomocą programu do tworzenia prezentacji. Nie twierdzę, że modele te są złe, one po prostu są koszmarnie pracochłonne i kosztowne.
Tak więc na początku projektu należy sobie zawsze odpowiedzieć na pytanie: modelarz czy rysownik. Po drugie nie kupujcie modelowania tylko płaćcie ekspertom za wsparcie w rozwiązywaniu Waszych problemów i dokumentowaniu Waszych decyzji bo model to także doskonały sposób na udokumentowanie decyzji ot choćby właśnie organizacyjnych (np. dla potrzeb norm jakości ISO).
Tych, którzy chcą podjąć próbę samodzielnego modelowania procesów zapraszam zaś na kurs w 100% oparty na standardach OMG i nauce: Modelowanie procesów biznesowych w analizie systemowej.
a na koniec kilka cytatów:
?Model jest uproszczeniem rzeczywistości?, ?Modele opracowujemy po to by lepiej zrozumieć organizację, którą tworzymy lub opisujemy?, ?W dobrym modelu są uwzględnione wszystkie istotne elementy, natomiast są pominięte szczegóły, które nie odpowiadają przyjętemu poziomowi abstrakcji?, ?Modele złożonych organizacji opracowujemy dlatego, że nie jesteśmy w stanie ogarnąć tych organizacji w całości? (Grady Booch, James Rumbaugh, Ivar Jacobson, autorzy obiektowej notacji UML do modelowania systemów i organizacji)
„Modelowanie przedsiębiorstwa stwarza dobrą możliwość analizy oraz kształtowania procesów działania. Dzięki temu można uniknąć problemów przy wprowadzaniu zmian.” (Hubert H. Zimmermann),
„Analiza firmy i wykonanie jej modelu to sztuka a nie nauka ścisła.” (David Faulkner)
Generalnie zgoda, ale pytanie czy może być inaczej? Jaki % osób w branży (analityków, programistów) jest w stanie tworzyć modele? My staramy się pogodzić kilka światów i kilka technik. Event Storming (big picture, process level i design level) jako narzędzia do zbieranie informacji. Informacji a nie „wymagań”. Zbierania a nie analizy. Dale to dużą „inkluzywność”, ponieważ kolorowe karteczki i nieformalny zapis są kognitywnie łatwo dostępne dla każdego. ES można poprowadzić na abstraktach albo na przykładach. Dalej… Sam nie jestem fanem user story, ale to pomaga ludziom, którzy przetwarzają informacji przez przykłady a nie abstrakty. Po takim „zbieractwie” przychodzi czas na analizę, nie mieszamy nigdy tych 2 faz. Dlatego też rozmawiamy z ludźmi jako rysownicy, a formalne narzędzia wchodzą później w fazie analizy. I teraz jest bardzo ważne, to co napisałeś: będę potrzebował inny model dla oporu powietrza budynku a inny do projektowania estetyki budynku. Więc kluczem są Bounded Contexty, czyli osobne modele aby odpowiedzieć sobie na inne pytania. Stąd pierwszą fazą takiej analizy jest u nas odkrywanie poukrywanych i splątanych pod-domen aby odkryć na jakie pytania szukamy odp. Może się okazać, że kilka pod-domen da się „ograć” jednym modelem (jedną przestrzenią modelu). Całość nie trwa tak długo jak się może wydawąć, 2-3 dni i. mamy w średniej wielkości systemie strategiczną mapę zależności kontekstów, która wystarcza na kilka miesięcy pracy w szczegółach. Do tego można nałożyć drivery architektoniczne i mapa kontekstów destyluje się w kierunku modułów/mocroservisów, które mają granica wspierające prawdziwą autonomię zamiast spaghetti. Czyli w skrócie: użyłbym różnych narzędzi, do osiągnięcia różnych celów i do współpracy z różnymi ludźmi o różnych profilach kognitywnych.
„Jaki % osób w branży (analityków, programistów) jest w stanie tworzyć modele?” To pytanie w każdej branży: czy ma to robić każdy kto chce czy tylko Ci co potrafią?
„Sam nie jestem fanem user story, ale to pomaga ludziom, którzy przetwarzają informacji przez przykłady a nie abstrakty.” Pytanie, czy to jest skuteczne czy tylko fajne?
Problemem jaki ja widzę to to po czym poprawiam. Poprawiam po metodach opartych na obserwacji, innymi słowy każdy statystyk dobrze wie, ale nie rozumie. Model to wyjaśnienie tego co obserwują ludzie a nie to co co zaobserwowali. Dlatego niestety np. event storming czy user story kojarzy mi się z samochodem, który ma moduł skrętu w lewo, moduł skrętu w prawo i moduł do jazdy prosto. A ja szukam metod dotarcia do prawdy: moduł zmiany kierunku jazdy.
Model powinien być tym, co zostanie zaimplementowane. Tworzenie (analiza i projektowanie) „od razu w kodzie” wychodzi bardzo kosztownie… „Bounded context” to klucz do zarządzania danymi i przetwarzaniem ich (informacją). Dlatego metody analizy oparte na artefaktach i faktach, wydają się być znacznie skuteczniejsze w „odkrywaniu prawdy o dziedzinie” niż słuchanie ludzi: subiektywnych i nie raz lobbystycznych historyjek… 😉
„moduł do zmiany kierunku” zamiast „skręcania” – podoba mi się ta analogia i sam używam podobnej. Ale jak wchodzę w temat: badania białek syntetycznych, franczyzy na dostawę prądu do ładowarek, itd… wymieniać można by długo, i jedyne co mam, to ludzie, którzy myślą „kejsami” o biznesie, w którym pracują już jakiś czas albo dopiero go kreujemy to co mogę wtedy zrobić? Z psychologii wiemy, jak uczą się ludzie dorośli: https://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition https://en.wikipedia.org/wiki/Kolb%27s_experiential_learning
Mam mix ludzi z tak zwanego biznesu, mam mix ludzi z procesu produkcji softu, którzy będą kontynuować projekt i czasem najlepsze co mogę zrobić to wyjąć karteczki a czasem od razu zagaić o archetyp modelu biz. Czasem od razu destylacja kontekstów.
„To pytanie w każdej branży: czy ma to robić każdy kto chce czy tylko Ci co potrafią?” Ile rąk musisz użyć aby zliczyć w swojej branży tych co potrafią? 😛 Ale i tak jak po audycie architektury wychodzi, że analiza była niedostatecznie wielowymiarowa i model w zderzeniu z fizyką (sprzęt, prędkość światła;) nie daje rady i zamiast microservisów wychodzi jak zwykle. Zostawiając świat idealny i schodząc do realnego projekt realizują ci, których mamy, czasem, ci którzy nie uciekli na trawnik po drugiej stronie. Z tego powodu postuluję, że warto mieć w narzędziowniku narzędzia na różne okazje.
Pięknie wymieniłeś chyba wszystkie źródła problemów :)..
„?To pytanie w każdej branży: czy ma to robić każdy kto chce czy tylko Ci co potrafią?? Ile rąk musisz użyć aby zliczyć w swojej branży tych co potrafią?”
😉
„jedyne co mam, to ludzie, którzy myślą ?kejsami? o biznesie, w którym pracują już jakiś czas albo dopiero go kreujemy to co mogę wtedy zrobić? ”
Bo ludzie tak myślą: młotka używam to wbijania gwoździ, to straszenia złoczyńców, do wybijania szyb, do pukania w sprawdzane płytki chodnikowe, …. a tak na prawdę tego młotka nam od tych „kejsów” wcale nie przybywa, to stale ten sam młotek i ktoś musi na to wpaść… albo wyda majątek i nigdy nie skończy…
Co możesz zrobić? Nic nie możesz zrobić, możesz szukać lepszej metody, i tu robi się „szumnie” czyli nauka:
Machamer, P., Darden, L., & Craver, C. F. (2000). Thinking about mechanisms. Philosophy of Science, 67(1), 1?25.
i kwintesencja problemu analizy i modelowania:
Craver, C., & Tabery, J. (2019). Mechanisms in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://plato.stanford.edu/entries/science-mechanisms/
Polecam 🙂
A w kwestii uczenia i uczenia się, po ponad kilkunastu latach pracy jako wykładowca na uczelniach i trener na szkoleniach, wiem, że ludzie mają różne predyspozycje i już z tym nie walczę, uczciwie mówię ludziom, że na moich szkolenia dowiedzą się czy się nadają, a nie że się nauczą.. 😉 .. Zasada kołczów „chcieć to móc” to raczej brednie 😉
To jak z grą na instrumencie, jedni grają a innym nawet konserwatorium nie pomoże 😉 i musimy z tym żyć…
aha,może nieco z innej beczki ale polecam gorąco to:
Oliveira Rocha, H. F. (2022). Practical Event-Driven Microservices Architecture: Building Sustainable and Highly Scalable Event-Driven Microservices. Apress. https://doi.org/10.1007/978-1-4842-7468-2
Chyba nie mogę komentować pod komentarzem, mogę jedynie tworzyć komentarze na głównym poziomie. Co do event driven, to jest z tym kilka problemów: 1) to jeden z kilkunastu patternów, z których można budować kilkadziesiąt scenariuszy. Klasyczna pozycja https://www.enterpriseintegrationpatterns.com/
Znam :), stoi u mnie na półce 😉
i to:
https://martinfowler.com/eaaCatalog/
… chciałem złamać linię się formularz wysłał. Nie będę już łamał:) Problemy z eventami: często to jedyny pattern jaki znają zespoły dev. Eventy odwracają kontrolę, więc prowadzą do jej utraty. I to jest ok, np w IoT albo w gamedev, ale często w typowych systemach biznesowych jest potrzeba kontroli kolejności i zależności pomiędzy eventami. Wstawiamy wtedy Sagę/PorocessManagera i dodajemy nową złożoność różnego rodzaju, nie będę rozwijał. A czasem wystarczyłoby inaczej to zaprojektować. I największy problem z eventami: nieumiejętnie stosowane (brak destylacji kontekstów, brak opracowania published language) powodują „przeciekanie domen” – modele z jednej domeny są przenoszone do innych domen właśnie przez niemądrze zaprojektowane eventy. Powoduje to masakryczną https://en.wikipedia.org/wiki/Connascence i w efekcie rozproszony monolit, gdzie kończymy z brakiem jakiegokolwiek źródła prawdy a większość modułów to single point of failure. Ot taka codzienność:)
saga to stary dobry wzorzec 😉
Garcia-Molina, H., & Salem, K. (1987). Sagas. ACM Sigmod Record, 16(3), 249?259.
wraca do łask przy mikro-serwisach i bazach dokumentowych, regularnie go stosuje.
Separację kontekstów się doskonale robi właśnie na dokumentach projektowanych jako agregaty: jeden agregat (lub jego sekcja), jeden kontekst. Pole (znacznik) 'data’ w na dokumencie (agregat) „Karta Zgonu” to data zgonu, a to samo pole 'data’ na Akcie Urodzenia (agregat) to data urodzenia. Znika problem sztucznych nazw kolumn w modelu relacyjnym, który nie przenosi kontekstu.