Nie trzeba być ekspertem domenowym i posiadać głębokiej wiedzy na temat omawianych procesów, aby skutecznie przeprowadzić sesję EventStormingu. Oczywiście, znajomość szczegółów danej domeny jest ku temu mocno przydatna, jednak jej brak nie jest tu szczególnie istotną przeszkodą. Potrzebne do analizy zdarzenia mogą zostać skutecznie i szybko odkryte z użyciem przedstawionych poniżej strategii.
Podstawowym elementem EventStormingu są zachodzące w analizowanej domenie zdarzenia. Poprzez wspólną eksplorację procesów biznesowych, spośród wszystkich odkrytych eventów można wskazać zdarzenia kluczowe dla poszczególnych subdomen, zidentyfikować i zrozumieć ich wzajemne powiązania, a następnie, zdobytą w ten sposób wiedzę, wykorzystać do opracowania modelu domenowego. Będzie to jednak mocno problematyczne, gdy odkrywanie kolejnych zdarzeń przychodzi z trudem.
Przedstawione poniżej techniki są uniwersalne i mogą zostać użyte do analizy w zasadzie dowolnej domeny. Sprawdzą się one przede wszystkim podczas eksploracji na sesji Big Picture EventStorming, pozwalając na zidentyfikowanie bardzo szerokiej gamy różnych zdarzeń, także tych zachodzących dookoła projektowanego systemu. Żadna z poniższych strategii nie pozwoli jednak samodzielnie na na odkrycie wszystkich występujących w systemie eventów.
Najprostszym sposobem odkrycia zdarzeń w analizowanym procesie jest po prostu zapoznanie się z jego budową. Zapoznanie to może przyjąć formę np. rozmowy z ekspertem domenowym i przysłuchiwaniu się jego wypowiedziom, zapoznaniu się z przygotowanymi wcześniej materiałami, obserwacji pracujących osób czy też samodzielnego wykonania analizowanego procesu.
Uwagę powinny tu zwracać momenty, w których zachodzą ważne i możliwe do bezpośredniego zaobserwowania zmiany, wykonywane są konkretne czynności i kroki procesu, lub podejmowane są istotne decyzje, mające wpływ na jego przebieg.
Jakość odkrywanych zdarzeń zależy w dużej mierze od sposobu obserwacji procesu. Bezpośrednia rozmowa z ekspertem domenowym doprowadzi najczęściej do zidentyfikowania faktycznych zdarzeń domenowych, podczas gdy obserwacja wykonania procesu przez aktora może dostarczać jedynie pierwszych, najbardziej widocznych z zewnątrz działań.
Fragment regulaminu popularnej aplikacji taksówkowej:
Po zakończeniu lub anulowaniu podróży, zostaniesz obciążony rzeczywistą kwotą i automatyczna prośba zostanie wysłana do banku o zwolnienie tego tymczasowego wstrzymania. Jeśli wstrzymana kwota nie została zwolniona po 7 dniach, będziesz musiał skontaktować się ze swoim dostawcą płatności/bankiem, aby uzyskać więcej informacji.
Zastosowanie tej strategii doprowadzi tu w pierwszej kolejności do odkrycia następujących zdarzeń:
Rys. Bezpośrednie mapowanie opisu procesu na zdarzenia
Niemal w każdym długotrwałym procesie można wskazać zdarzenia, których wystąpienie jest wręcz krytyczne w całym przebiegu procesu. Często są to zdarzenia kończące ważne fragmenty procesu lub różne warianty ich wykonania. Brak ich wystąpienia zwykle oznacza niemożliwość osiągnięcia celu, dla którego dany proces jest realizowany.
Gdy ekspert domenowy zostanie zapytany o kilka najważniejszych zdarzeń, bez których omawiany system jest bezużyteczny, z dużym prawdopodobieństwem wskaże właśnie na kamienie milowe. Warto celowo ograniczyć w pytaniu liczbę takich zdarzeń, aby zmniejszyć ryzyko pojawiania się mniej istotnych dla procesu eventów.
Strategia ta bardzo dobrze sprawdza się na samym początku warsztatu, ponieważ odkrywane w ten sposób eventy zwykle rozkładają się równomiernie na osi czasu. W przypadku, gdy w sesji stormingowej uczestniczy kilku różnych ekspertów domenowych, dodatkowo pozwala to na możliwość zrównoglenia dalszej eksploracji.
Kroki milowe procesu bardzo często okazują się być także zdarzeniami typu Pivotal Events.
W jednej z popularnych aplikacji taksówkowych, proces zamawiania i realizacji przejazdu posiada wiele wariantów, jednak zawsze występują w nim zdarzenia Ride Requested, Ride Started oraz Ride Finished.
Rys. Kluczowe kroki procesu organizacji i realizacji przejazdu
Eventy te stanowią kroki milowe procesu, a pomiędzy nimi mogą występować różne inne sekwencje zdarzeń:
Ostatecznie jednak kończą się one właśnie tymi 3 eventami.
Często pierwsze odkrywane w trakcie EventStormingu zdarzenia opisują łatwe do zaobserwowania działania zaangażowanych w proces aktorów, systemów zewnętrznych, czy też upływ czasu. Jest to dobry punkt startowy do głębszej analizy, ponieważ wystąpienie określonych zdarzeń może powodować kaskadowe i automatyczne zaistnienie kolejnych, mniej oczywistych eventów. Zaskakująco często dla interesariuszy i ekspertów biznesowych znacznie ważniejsze są właśnie te zdarzenia pochodne, stanowiące konsekwencje pierwotnego eventu.
W identyfikacji konsekwencji zdzrzeń przydatne są pytania typu co się dzieje, gdy zajdzie X?, czy też w jaki sposób rozpoznamy, że stało się X? Pomagają one odkryć kolejne, zachodzące w systemie zmiany, nawet jeśli występują one w innych jego częściach. W rezultacie tej strategii powstają struktury, w której pierwsze zdarzenia zostały zainicjowane bezpośrednio, a wszystkie kolejne są powiązane relacją przyczynowo-skutkową, często z dodatkową logiką procesową.
Ten sposób eksploracji domeny jest niezwykle efektywny i ujawnia szereg kluczowych evenów domenowych. Do działania potrzebuje jednak zdarzeń początkowych, dlatego świetnie uzupełnia inne podejścia.
Opisane eventem Ride Finished dostarcie na miejsce docelowe i zakończenie przejazdu pociąga za sobą szereg istotnych konsekwencji.
Rys. Odkryte konsekwencje zdarzenia zainicjowanego przez aktora
Działania te są istotne z perspektywy operacyjnej firmy:
Z punktu interesariuszy biznesowych, ich wystąpienie jest znacznie ważniejsze niż odnotowanie samego faktu zakończenia przejazdu.
Powszechnym zjawiskiem podczas sesji Big Picture EventStormingu jest proponowanie zdarzeń o różnej granulacji. Zdarzenia opisujące jednoznacznie bardzo konkretne momenty procesu przeplatają się ze zdarzeniami, pod którymi skrywa się wiele osobnych, zachodzących w procesie zmian. Jeśli celem sesji jest zbudowanie dokładnego modelu analizowanej domeny, takie gruboziarniste zdarzenia będą to utrudniać, zostawiając pole do różnych interpretacji i luki w wiedzy o danym obszarze.
Dobrą praktyką jest opisywanie każdego istotnego punktu procesu osobnym zdarzeniem, a w razie potrzeby rozbicie “grubego” zdarzenia na kilka dokładniejszych, opisujących atomowe zmiany eventów. Odkryte w ten sposób zdarzenia często ujawniają istnienie osobnego procesu biznesowego lub subdomeny.
Zadanie ekspertowi pytanie typu co dokładnie się zmienia/dzieje w chwili, gdy nastąpi X? pozwala skutecznie odkryć istnienie takich eventów.
Za skorzystanie z usługi przejazdu zamawiający otrzymuje za każdym razem określoną liczbę punktów lojalnościowych. Punkty te mogą zostać przekazane w dowolnej chwili innemu użytkownikowi systemu, co opisuje zdarzenie Loyalty Points Trasferred To Another Account.
Rys. Rozbicie gruboziarnistego zdarzenia, na kilka niezależnych zdarzeń
W trakcie tego transferu zmianom w różnym stopniu ulegają 2 konta, macierzyste oraz docelowe, dochodzi także do poinformowania obdarowanej osoby o tym fakcie. Pokazuje to istnienie dwóch osobnych obszarów systemu, związanych z kolejno z obsługą kont i notyfikacjami.
Gdy podczas sesji EventStormingu analizowanych jest szereg różnych procesów lub ich wariantów, różne, nawiązujące do specyfiki poszczególnych scenariuszy zdarzenia w rzeczywistości oznaczają dokładnie to samo. Ekspert domenowy z pewnością zauważy ten problem i zaproponuje pojedyncze zdarzenie, jednak wielu mniej doświadczonych osób będzie traktować je całkowicie oddzielnie. W rezultacie, dyskusje obejmować będą bardzo szeroki zestaw eventów, a wyciąganie wartościowych wniosków mocno się utrudni.
W takiej sytuacji dobrą strategią będzie zastąpienie różnych, specyficznych zdarzeń ich uogólnieniem, które obejmie wszystkie zidentyfikowane przypadki. Ostatecznie, to nie liczba odkrytych zdarzeń mówi o jakości wytworzonego modelu…
Sygnałem możliwości takiego uogólnienia jest np. pojawianie się w zdarzeniach nazw funkcjonalności systemu, nazw własnych czy szeregu bardzo konkretnych przypadków użycia. Z kolei podczas sesji Process Level EventStorming, strategia ta może obejmować analizę reguł warunkujących pojawianie się zdarzeń. Jeśli kilka różnie brzmiących eventów jest poprzedzone kontrolą identycznych reguł domenowych, prawdopodobnie jest to dokładnie to samo zdarzenie.
Fragment regulaminu popularnej aplikacji taksówkowej:
Rzeczywista cena za przejazd zależy od następujących czynników: wybranej trasy, korków na drogach, przejazdów w nocy lub w dni świąteczne, wyjazdów z obszarów miejskich, dopłaty za usługi specjalne. Stosowane są także dopłaty, zgodnie z tabelą.
Rys. Wprowdzenie pojedycznego zdarzenia dokładnie opisującego różne przypadki
Na cenę przejazdu taksówką wpływa więc szereg różnych czynników i zdarzeń. Niezależnie jednak od tego, czy:
zawsze opisują to samo zachowanie: zmianę sposobu wyliczania ceny. Dokładnie opisuje to ugólnione zdarzenie Tariff Activated, dodatkowo wykorzystując przyjęte w tej domenie słownictwo.
Warunkiem wspólnego zrozumeinai problemu w zespole jest jednoznaczna i identyczna interpretacja odkrytych podczas EventStormingu eventów. Jeśli zdarzenia mają opisywać zachodzące w domenie zmiany, dość naturalnym wydaje się być używanie sformułowań typu zmieniono X czy zmodyfikowano X. Tak nazwane eventy są jednak nieprecyzyjne i zostawiają pole do odmiennej interpretacji przez różne osoby. Co więcej, odkrycie wielu zdarzeń tego rodzaju może bardzo silnie sugerować istnienie tzw. CRUD-a, podczas gdy domena jest w rzeczywistości znacznie bardziej złożona.
Pojawianie w nazwach zdarzeń słów zmieniono, zaktualizowano, zmodyfikowano zawsze powinno zwracać uwagę i chęć ich doprecyzowania. Tak ogólne sformułowania zawierają w sobie różne możliwe warianty zmiany, np. powiększenie/zmniejszenie, dodanie/usunięcie, poszerzenie/pomniejszenie. Jeśli konsekwencje poszczególnych wariantów zmiany są różne, dobrym rozwiązaniem będzie zastąpienie ogólnego eventu kilkoma, znacznie bardziej precyzyjnymi zdarzeniami.
Jeśli jednak niezależnie od rodzaju zmiany, konsekwencje są takie same lub też całkowicie ich nie ma, pozostawienie na osi czasu zdarzenia zmieniono X wydaje się być całkowicie uzasadnione. Pozwoli to ograniczyć wielkość modelu, przy jednoczesnym zachowaniu odpowiedniej jego szczegółowości.
Trasa przejazdu taksówką może ulec zmianie z wielu powodów, zarówno w wyniku działań osoby zamawiającej, kierowcy jak i przypadków losowych.
Rys. Zastąpienie generycznego zdarzenia osobnymi eventami o odmiennych konsekwencjach
Zastąpienie generycznego zdarzenia Ride Route Changed, oprócz rozróżniania oczywistych konsekwencji osobnych eventów pozwala dostrzec dodatkowe aspekty:
Jednocześnie zdarzenie Car Plate Number Changed pozostaje tu niezmienione. Podanie nowego numer tablic rejestracyjnych jest jedynie odnotowane i nie pociąga za sobą żadnych innych skutków.
Interfejs użytkownika powinien być projektowany przede wszystkim z uwzględnieniem zagadnień użyteczności i ergonomii, a jako taki, nie powinien wpływać w żadnym stopniu na budowę modelu domenowego. Zdarzenia związane z GUI rodzaju Button X clicked czy Form X submitted, o ile mogą precyzyjnie opisywać interakcje użytkownika z interfejsem systemu, nie pozwalają jednak zrozumieć zachodzących w nim procesów biznesowych. Pojawianie się takich zdarzeń ma miejsce zazwyczaj na sesjach analizy as-is istniejących systemów i pochodzą przede wszystkim od użytkowników tych systemów, nie ekspertów domenowych.
Poprzez wskazanie celu aktora, eventy interfejsowe mogą jednak zostać w prosty sposób zastąpione zdarzeniami domenowymi. Pytania typu co chciał osiągnąć aktor klikając ten przycisk? czy co dzieje się w konsekwencji kliknięcia tego przycisku? zazwyczaj dość skutecznie ujawniają ten cel i możliwe zdarzenie to opisujące. Kliknięcie, czy wysłanie formularza jest tu tylko technicznym sposobem dążenia do tego celu.
Opieranie głębokiej analizy domeny na eventach interfejsowych może nie być skuteczne. Nie oznacza to jednak, że zdarzania interfejsu użytkownika są całkowicie bezużyteczne. Mogą być one bardzo przydatne gdy celem sesji jest np. optymalizacja warstwy prezentacji systemu, lub interfejs ten jest skomplikowany i niezrozumiały dla zespołu.
Interfejs aplikacji taksówkowej zawiera przycisk służący do udostępnienia aktualnej lokalizacji zaufanym osobom.
Rys. Wprowadzenie zdarzenia opisującego zmianę wywołaną interakcją z GUI systemu
Z perspektywy analizy domeny, istotniejsze są konsekwencje naciśnięcia tego przycisku, czyli rozpoczęcie udostępniania lokalizacji. Event Sharing Current Location With Family Started opisuje także cel, który chciał osiągnąć tym kliknięciem pasażer.
Naturalnym początkiej EventStormingu jest rozpoczynanie eksploracji od ścieżek pozytywnych procesów (ang. happy-paths), pdkryte zdarzenia układają się jedne po drugich w logiczne sekwencje. Powstałe w ten sposob osie czasów są więc dość mocno liniowe, co w wielu przypadkach jest złudne, ponieważ trudno w ten sposób zauważyć istnienie wielu różńych podprocesów.
Zgodnie z definicją, zdarzenie opisuje już zaistniałą sytuację i jako takie, nie może zostać zmienione. Odwrócone mogą zostać jednak skutki, jakie poszczególne zdarzenia wywarły na system, co sprawnie zostać wskazane poprzez istnienie zdarzeń przeciwstawnych, np. otworzono - zamknięto, podniesiono - opuszczono, włączono - wyłączono. Odkryte w ten sposób zdarzenia przeciwstawne mogą powodować powstanie kolejnych eventów, zgodnie z opisaną w poprzednim punkcie strategią analizy konsekwencji. Warto pamiętać, że występowanie zdarzeń przciwstawnych czasem jest możliwe jedynie w ściśle określonym przedziale czasu, lub jest obarczone dodatkowymi warunkami.
Strategię tę można w zasadzie zastosować dla każdego ze zidentyfikowanych wcześniej zdarzeń. Nie byłoby to jednak efektywne wykorzystanie dostępnego czasu ekspertów domenowych, dlatego czasem warto ograniczyć się tu dla najistotniejszych punktów procesów, związanych np. z krokami milowymi czy Pivotal Events.
Zamówienie przejazdu taksówką nie jest nieodwołalnym zobowiązaniem dla klientów. Do momentu rozpoczęcia przejazdu z miejsca odbioru, może on zostać anulowany w dowolnej chwili.
Rys. Wprowadzenie zdarzenia przeciwstawnego, otwierającego nowy proces biznesowy
Event Ride Cancelled w oczywisty sposób odwraca tu skutki zdarzenia Ride Ordered i wiązać się będzie z wystąpieniem szeregu konsekwencji. Może on zaistnieć jedynie w przedziale wyznaczonym zdarzeniami Ride Ordered i Ride Started.
Przedstawianie procesu poprzez wskazywanie kolejno zachodzącym w nim zdarzeń jest obarczone kilkoma problemami. Ekspert domenowy przedstawiając swój obszar zainteresowań, dla przyspieszenia rozmowy zazwyczaj posługuje się skrótami myślowymi. Jest to działanie nieświadome, ponieważ wiele z omawianych zagadnień jest dla niego oczywistych. W efekcie, niektóre istotne zdarzenia nie będą widoczne dla wszystkich uczestników sesji. Dodatkowo, gdy proces posiada liczne rozgałęzienia i warianty, łatwo ulec przeciążeniu poznawczemu i pominąć jakiś fragment w eksploracji.
W celu odkrycia pominiętych zdarzeń można zastosować tzw. narrację wsteczną. Jest to technika sprawdzania spójności modelu poprzez czytanie osi czasu wstecz. Punktem startowym jest zwykle istotne zdarzenie w procesie, a poprzez pytania typu co musiało się wydarzyć wcześniej, aby zdarzenie X mogło zaistnieć?, sprawdzana jest poprzedzająca je ścieżka. Naturalnymi kandydatami do rozpoczęcia narracji wstecznej są zdarzenia będące kamieniami milowymi procesu, kończące cały proces lub Pivotal Events. Poszczególne zdarzenia muszą się ze sobą logicznie łączyć, wynikać jedno z drugiego bez nienaturalnych przeskoków, a ewentualne odkryte braki powinny zostać natychmiast uzupełnione.
Strategia ta sprawdza się dobrze w sytuacji, gdy już po sesji Big Picture oczekiwany jest dość dokładny obraz analizowanej domeny. Jej dokładne przeprowadzenie wymaga jednak dużego zaangażowania uczestników i czasu.
Rozpoczęcie przejazdu taksówką musi być poprzedzone nie tylko samym złożeniem zamówienia (Ride Ordered), ale także przybyciem taksówki w określone miejsce odbioru. Co z kolei jest poprzedzone rozpoczęciem dojazdu w to miejsce.
Rys. Odkrycie pominiętych wcześniej zdarzeń z użyciem narracji wstecznej
Otwiera to nowe obszary do eksploracji:
Nowe scenariusze są istotne z perspektywy biznesowej, a dodatkowo wymagają stałego posiadania informacji o aktualnej lokalizacji pojazdu z GPS. Odkryte zdarzenia stają się tu pretekstem do znacznie ważniejszych fragmentów analizy.
Niektóre oczekiwane w procesie zdarzenia mogą nigdy nie zaistnieć. Jest to szczególnie widoczne w sytuacji, gdy inicjatywa w procesie znajduje się po stronie aktora lub systemu zewnętrznego i to od nich zależy wykonanie kolejnego działania. Jeśli oczekiwane zdarzenie było istotne, np. uruchamiało ważną sekwencję zdarzeń, prawdopodobnie brak jego wystąpienia także ma konsekwencje, tym razem negatywne. Warto więc wskazać opisujące to zdarzenie.
Określenie nie wystąpiło X nie jest jednak zgodne z definicją eventu, ponieważ tego faktu nie można przypisać do konkretnego momentu czasu. Gdy zachodzi potrzeba dokładnego wskazania takiego zdarzenia, można np. sparafrazować to określenie w konwencji upłynął czas na wystąpienie X. Tak nazwane zdarzenie jest już zgodne ze stosowaną w stormingu definicją i może ono zostać dokładnie zlokalizowane na modelowanej osi czasu.
Gdy nie ma pewności, czy i jak bardzo dane zdarzenie jest krytyczne dla interesariuszy i eksperów biznesowych, pomocne może być pytanie typu co się stanie, jeśli X nie wystąpi? Jeśli w odpowiedzi szybko wskazane zostaną istotne eventy mające wpływ na stan systemu, całą odkrytą ścieżkę warto umieścić w modelu. Łącznie ze zdarzeniem opisującym upływ czasu i inicjującym cały podproces.
Fragment regulaminu popularnej aplikacji taksówkowej:
Opłata za oczekiwanie jest naliczana, aby pasażer nie był opóźniony i aby usługa została wykonana w odpowiednim czasie. Pasażer ma dwie minuty bezpłatnego czasu oczekiwania, a po upływie 2 minut zostanie obciążony opłatą zgodnie z wybranym typem floty.
Rys. Wprowadzenie zdarzenia opisującego brak innego eventu
Nie pojawienie się pasażera w odpowiednich momentach jest tu zobrazowane zdarzeniami pokazującymi upływ czasu, liczonego od momentu przybycia taksówki we wskaznego miejsce. Wystąpienie tych zdarzeń może powodować w rezultacie kolejne zdarzenia Tariff Activated czy Ride Cancelled.
Gdy w procesie oczekujemy zaistnienia konkretnego scenariusza zdarzeń, a sterowanie tym procesem znajduje się po stronie aktora lub systemu zewnętrznego, możliwych jest szereg odmiennych sytuacji:
Wskazanie zdarzeń opisujących poszczególne warianty jest wartościowe, ponieważ znów, na każdej z istniejących ścieżek generowane są często odmienne konsekwencje. Zidentyfikowanie tych zdarzeń otwiera także nowe, niewidoczne wcześniej przy analizie happy-paths obszary do dalszej eksploracji.
Naturalnymi kandydatami na zastosowanie tej strategii są miejsca, jak w przypadku poprzednich sposobów, w których inicjatywa i decyzyjność w procesie należy do aktora lub systemu zewnętrznego. Dotyczy to także sekwencji zdarzeń, których wykonanie zależy od powiązanych z nimi wartości (ang. payload), a na które istotny wpływ ma właśnie dany aktor czy system.
Fragment regulaminu popularnej aplikacji taksówkowej:
W przypadku usługi TAXI preautoryzacja dokonywana jest na podstawie estymowanej ceny za przejazd. Cena szacowana jest na podstawie odległości, jednak nie uwzględnia opłat dodatkowych i wylicza koszt przejazdu wyłącznie na podstawie stawek w pierwszej taryfie. Z tego względu, kwota preautoryzacji może być znacznie niższa niż faktyczna opłata za przejazd.
Rys. Możliwe rozgałęzienia w procesie płatności
Zgodnie z regulaminem, może zaistnieć tu kilka osobnych scenariuszy, tak więc proces ulega rozgałęzieniu:
Strategia weryfikacji i narracji wstecznej pozwala odkryć zdarzenia, które są konieczne dla zaistnienia innych eventów. Analogicznie, niektóre zdarzenia blokują możliwość zaistnienia innych. Może mieć to związek z istniejącymi w domenie biznesowej ograniczami, liczebnością zasobów i limitami ich wykorzystania, niedopełnionymi wcześniej obowiązkami, regulacjami prawnymi…
Openerem tej strategii jest pytania typu dlaczego X nie może zaistnieć?, jakie wcześniejsze zdarzenie lub jego brak spowodował tę blokadę? Jeśli zdarzenie blokujące zostanie zidentyfikowane, za pomocą strategii zdarzeń przeciwstawnych można zapewne także wskazać moment jej usunięcia.
Z kolei poprzez pytanie typu czy X nie może zaistnieć dla wszystich użytkowników, czy dotyczy to jedynie wybranej ich grupy? można weryfikować, czy zdarzenia nie niosą ze sobą jakichś specyficznych informacji. Informacje te są równie cenne dla dalszego modelowania domeny jak odkryte nazwy zdarzeń.
Fragment regulaminu popularnej aplikacji taksówkowej:
Jednym z powodów, dla którego w danej możesz nie być w stanie zamówić kursu jest brak dostępnych kierowców. Jest to mało prawdopodobne, ale jeśli tak się stanie, aplikacja poinformuje Cię, że nie ma dostępnych kierowców. W takiej sytuacji zalecamy odczekanie kilku minut przed ponowną próbą złożenia zamówienia.
Rys. Blokowanie wystąpienia ważnego zdarzenia przez inny event
Wysokie zapotrzebowanie na przejazdy może wyczerpać pulę dostępnych w danej okolicy kierowców. Gdy tak się stanie, składanie kolejnych zamówień zostaje wstrzymane.
Podczas analizy procesu uwaga wszystkich uczestników jest zazwyczaj skupiona na pojedynczym jego wykonaniu, zdarzenie po zdarzeniu.
Zamodelowany w ten sposob proces warto poddać weryfikacji współbieżności, np. poprzez symulację nałożenia się na siebie 2 (lub większej liczby) jego wykonań. Z dużym prawdopodobieństwem pozwoli to na zidentyfikowanie kolejnych zdarzeń, wynikającymi ze wzajemnego wpływu poszczególnych wykonań. Częstym scenariuszem jest odkrywanie w ten sposób istniejących w domenie ograniczeń, np. ilości dostępnych zasobów lub współbieżnego dostępu do nich.
Podczas wykonywania symulacji należy kierować się prostą zasadą: stan symulacji jest tylko i wyłącznie pochodną odkrytych zdarzeń. Jeśli poprawne wykonanie procesu wymaga dodatkowych zmian w stanie symulacji, oznacza to z dużą pewnością brak odpowiednich zdarzeń na osi czasu.
Dobrym miejscem do wprowadznia w symulacji kolejnej instancji procesu są wszelkiego rodzaju pętle lub dłuższe sekwencje następujących bezpośrednio po sobie eventów. Warto przy tym wskazać konkretne miejsce pomiędzy dwoma istniejącymi zdarzeniami, zbadać aktualny stan symulacji, po czym uruchomić nową instancję procesu. Takie działania zwiększają szansę odkrycia zdarzeń pominiętych we wcześniejszej eksploracji.
Zdarzenia Ride Requested, Ride Accepted, Ride Started zostały odkryte podczas wstępnego mapowania procesu. Przeprowadzona symulacja zakładała scenariusz, w którym dostępny był tylko 1 kierowca, jednak zamówienia zostały złożone przez 2 różnych klientów.
Rys. Odkrycie w symulacji pominiętego wcześniej zdarzenia
W ten sposób stało się oczywiste, że zdarzenie Ride Accepted mogło wystąpić tylko i wyłącznie raz, a na czas realizacji kursi powinno także następować wyłączenie odpowiedniego kierowcy z puli.
Nieoczywistym sposobem wyciągania wartościowych wniosków podczas sesji modelowania jest wprowadzanie zdarzeń poszerzających analizowany zakres. Przykładowo, w postaci całkowicie nowych i niewymaganych przez interesariuszy biznesowych wariantów odkrytych procesów, dodatkowych funkcjonalności wykorzystujących ich zdarzenia czy zmieniając całkowicie cel, dla którego dany proces jest w ogóle wykonywany.
Początkowo wiele osób zwykle odbiera to jako istotną i całkowicie niepotrzebną komplikację, negując sens dyskutowania o nowych eventach. Celem tej strategii nie jest doprowadzenie do implementacji takich propozycji! Wprowadzone w ten sposób zdarzenia pozwalają zauważać wcześniej niewidoczne powiązania lub możliwe uogólnienia, gdy kilka zdarzeń opisuje de facto tę samą zmianę.
De facto może to więc oznaczać zastosowanie przedstawionej wcześniej strategii uogólnień, przy czym poddane temu procesowi zdarzenia pochodzą po części z opisywanego procesu, a po części zostały po prostu wymyślone. Powstałe w rezultacie modele domenowe są dzięki temu znacznie dokładniejsze, prostsze, a także pozbawione silnego powiązania tylko z jednym konkretnym przypadkiem ich użycia. Mogą być przez to łatwiejsze w dalszym rozwoju i utrzymaniu. To tak zwane upraszczanie przez pozorne skomplikowanie.
Zdarzenie Free Ride Ordered For Another Passenger nie jest związane z żadnym istniejącym procesem. Jednak wprowadzenie tego scenariusza do rozmowy spowodowało zastąpienie nowego eventu dwoma innymi.
Rys. Odkrycie rozdzielenia ról poprzez wprowadzenie nieoczekiwanego zdarzenia
W rezultacie zostało dostrzeżone istnienie dwóch osobnych ról, tj. zamawiający przejazd jest jednocześnie płatnikiem, natomiast pasażerem może być osoba nie posiadająca nawet konta w systemie.
Rzadko kiedy celem aktora jest wykonanie procesu. Jest to tylko sposób, w jaki system umożliwia osiągnięcie ważnego dla niego celu. Co więcej, realny cel aktora czasem nie jest częścią modelowanego systemu i ostatecznie może on nawet nie wiedzieć o tym, że został on osiągniety. Alberto Brandolini, twórca EventStormingu, przedstawia to następująco: moments when user and system are happy, are two different things.
Czy warto więc wskazywać takie eventy podczas EventStormingu? Wskazanie zdarzeń ważnych z punktu widzenia aktora nadaje całemu procesowi i dyskusji kontekstu. Może to także doprowadzić do zmian w modelowanym procesie, np. w przypadku odkrycia innego lub krótszego sposobu jego realizacji. Znajomość celu aktora jest także bardzo przydatna przy formułowaniu User Stories na dalszych etapach prac nad projektem.
Do tego rodzaju eventów nie warto jednak się silnie przywiązywać. Zdarzenia zachodzące poza systemem będą przydatne jedynie podczas sesji Big Picture, na etapie sesji Process Level nie zachodzi już potrzeba ich prezentacji i mogą zostać usunięte z przygotowywanego modelu.
Celem pasażera było dotarcie na wskazne przez niego miejsce, co zostało opisane zdarzeniem Passenger Reached Destination. Zapewne w tym momencie podziękuje kierowcy za wspólną jazdę i wysiądzie z taksówki.
Rys. Zwielokrotnienie
W tym momencie, wszelkie konsekwencje zakończenia przejazdu, w postaci rozliczenia zablokowanych uprzednio środków czy przywrócenia kierowcy do puli są dla niego nieistotne.
Nie od dziś wiadomo, że skutecznym sposobem na szybkie uzyskanie odpowiedzi poprawnej jest pokazanie odpowiedzi błędnej. Gdy w przestrzeni rozmowy pojawia się fałszywe stwierdzenie, wiele osób odczuwa natychmiastową potrzebę skorygowania tego błędu i podzielenia się swoją opinią. Sprawny facyliator może wykorzystać ten mechanizm do przekazywania inicjatywy w rozmowie ekspertom domenowym, przełamywania impasu podczas warsztatu, czy podrzucania nowych kierunków do analizy.
Wprowadzenie do modelu błędnego zdarzenia kończy się dość często reakcją typu nie, to nie działa w ten sposób, to działa tak… W rezultacie przeprowadzonej dyskusji, niepoprawny event jest zastępowany poprawnym rozwiązaniem.
Nie jest to jednak strategia do częstego wykorzystania. Zbyt częste wprowadzanie do rozmowy błędnych zdarzeń może zostać odebrane negatywnie, a ich autor uznany przez grupę jako problem-maker. Wprowadzanie tego rodzaju eventów jako pierwszych, bezpośrednio na początku warsztatu także może odnieść przeciwny od zamierzonego skutek. Wiele osób na tym etapie przyjmuje zdarzenia prowadzącego jako wzór do naśladowania, co skierowałoby rozmowy na niewłaściwe tory.
Zdarzenie Taxi Suddenly Transformed Into Truck z oczywistych powodów nigdy nie wystąpi. Jednak może spowodować pojawienie się pytań Dlaczego?, Co spowodowało takie zdarzenie?, co z kolei ujawni nowy proces związany z zamówieniem przejazdu bagażowego.
Rys. Pojawienie się nowego eventu na wskutek celowego “błędu” facylitatora
Otwiera to prawdopodobnie nowy obszar do eksploracji, związany z dostępną przestrzenią bagażową części floty.
Lista przedstawionych strategii jest obszerna, a i tak nie wyczerpuje w pełni wszystkich sposobów odkrywania zdarzeń. Choć każda z nich z osobna doskonale pozwala odkrywać eventy pewnego rodzaju, w praktyce doskonale się także uzupełniają.
Sprawny facylitator podczas eksploracji będzie swobodnie przełączał się między poszczególnymi technikami. Gdy zostanie odkryty nowy event, stanie się on dla niego punktem wyjścia do zadania kolejnych pytań o zdarzenia poprzedzające, przeciwstawne, blokujące, alternatywne…
Rys. Odkrywanie zdarzenia poprzez łączenie różnych strategii
Podczas sesji EventStormingu warto pamiętać, że odbywa się ona w bardzo konkretnym celu, np. zrozumienia struktury procesu biznesowego, zmapowania stanu as-is obecnego systemu, odkrycia brakującej wiedzy, etc. Poszukując kolejnych zdarzeń należy brać to pod uwagę, czasem celowo zostawiając pewne obszary bez głębszej eksploracji i analizy.
Gdy AI pisze coraz więcej kodu, tym bardziej istotna staje się funkcja architekta oprogramowania.
