Zdarzenie opisują coś znaczącego, co wydarzyło się w pewnym momencie w domenie. Tak przedstawiona definicja eventu jest wystarczająca do przeprowadzania EventStormingu, jednak zwykle powoduje poruszenie całego szeregu pobocznych, mniej istotnych wątków podczas sesji. Nie ma w tym nic dziwnego, każdy uczestnik warsztatu ma przecież własną perspektywę na omawiany problem, a dodatkowo, termin domena nie należy do najprecyzyjnieszych określeń.

Najczęstszym celem sesji EventStormingu jest zrozumienie domeny i zbudowanie jej modelu na potrzeby późniejszej implementacji. Z oczywistych powodów wymaga to posiadania wiedzy o zachodzących procesach i istniejących w nich zdarzeniach. Jednak mie wszystkie odkrywane w trakcie wasztatu eventy mają taki sam wpływ na domenę, część z nich można by wręcz celowo pominąć w dyskusjach, ponieważ kierują rozmowy w niewłaściwe strony.

Przykład z warsztatu

Klient przychodzi do oddziału i naciska przycisk wydania numerka w automacie przy wejściu. Po zweryfikowaniu możliwości obsłużenia klienta przed zamknięciem placówki, numerek zostanie wydany i klient zaczyna oczkiwać w kolejce do konsultanta. Gdy klient zobaczy na wyświetlaczu swój numer, podchodzi do okienka, a konsultant rozpoczyna przyjmowanie wniosku. System wyświetla wielokrokowy formularz, który konsultant wraz z klientem uzupełniają strona po stronie. Gdy zostanie kliknięty przycisk “następna strona”, system zapisuje w bazie danych wprowadzone informacje, po czym wyświetla kolejną stronę formularza. Na koniec klient potwierdza podpisem zgodność podanych danych, status wniosku zostaje ustawiony na “złożony” i nadawany jest mu numer identyfikacyjny. Inne systemy są powiadamiane o tym fakcie przez Kafkę. Złożony wniosek jest następnie przetwarzany, a po pozytywnym zakończeniu całego procesu konsultant otrzymuje odpowiednią prowizję.

Powyższy fragment jest tylko drobnym przykładem wypowiedzi, jakie często pojawiają się w trakcie EventStormingu, zwłaszcza podczas Big Picture. Wypowiadające się osoby swobodnie przemieszczają się pomiędzy rożnymi domenami, procesami czy nawet systemami i ich warstwami, nie odczuwając przy tym różnic pomiędzy kolejnymi opisywanymi przez siebie zdarzeniami.

Każdy z przedstawionych powyżej eventów wnosi coś do ogólnego zrozumienia problemu, od ogólnego kontekstu po obecnie zastosowane rozwiązania. Uczestniczące w warsztacie osoby są zwtkle zaangażowane w wiele inicjatyw w organizacji, przez co skupienie się przez 2 czy 3 dni jedynie na analizie jest nieosiągalne. Biorąc pod uwagę tak istotne ograniczenie warto jasno sprecyzować, jakie zdarzenia powinny być przedmiotem eksploracji.

Klasyfikacja zdarzeń

Usunięcie części zdarzeń z dyskusji sprowadza się de facto do ich odpowiedniego sklasyfikowania, określenia występujących pomiędzy mi podobieństw i różnic. Eventy mogą być rozróżniane przykładowo pod kątem:

• przynależności do procesu biznesowego - co jest najbardziej oczywistym sposobem grupowania eventów
• przynależności do domeny biznesowej - co z kolei jest dopiero efektem końcowym stormingu i nie jest widoczne na początku warsztatu
• źródła pochodzenia - czy powstały w wyniku działania użytkownika w procesie, czy za ich powstawnie odpowiadał już bezpośrednio system
• widoczności dla zaangażowanego w proces użytkownika - czy możliwe jest bezpośrednie zaobserwowanie ich wystąpienia, analogicznie ze stosowaną w Service Blueprint koncepcją Line of Visibility

Tak przyjęte podziały nie wydają się jednak jasno określać, nad którymi zdarzeniami warto skupić się w pierwszej kolejności. Aby ułatwić proces eksploracji, rozszerzam stosowaną w EventStormingu definicję eventu i wprowadzam następujący ich podział:

Zdarzenia domenowe

Zdarzenia domenowe opisują kluczowe momenty, w których dzieje się coś znaczącego dla biznesowego kontekstu działania organizacji, zachodzą ważne zmiany w procesach lub podejmowane są w nich istotne decyzje biznesowe. Są najważniejszym punktem rozmowy dla ekspertów domenowych i pozwalają zrozumieć CO biznesowo się dzieje w omawianym procesie, a nie JAK technicznie jest to realizowane.

Dla każdego ze zdarzeń domenowych możliwe jest precyzyjne określenie czasu jego wystąpienia, w innym przypadku - z całą pewnością nie jest to zdarzenie przynależne do danej domeny.

Zdarzenia weryfikacyjne

Zdarzenia weryfikacyjne opisują momenty, w których następuje kontrola powiązanych z procesem zasad, ważnych dla operacyjnego działania organizacji. Tego rodzaju eventy są dość łatwe do rozpoznania z kilku powodów:

• nazwa zdarzenia jednoznacznie wskazuje na przeprowadzoną kontrolę, w postaci sformułowania …Verified czy …Checked, nie określając przy tym dokładnych reguł poddanych weryfikacji
• zdarzenie nie opisuje bezpośrednio żadnej zachodzącej w domenie zmiany, a jedynie sam moment sprawdzenia - ewentualne decyzje są dopiero jego konsekwencjami
• proces ulega w tym rozwidleniu na ścieżki pozytywne i negatywne, w zależności od wyniku sprawdzenia

Wprowadzanie takich zdarzeń podczas sesji Big Picture EventStorming może wydawać się kontrowersyjne, nie opisują one przecież zachodzących w domenie zmian! Zdobycie wiedzy o tak ważnym biznesowo punkcie procesu, z którym w trakcie sesji Process Level EventStorming wiązać się będą już konkretne reguły domenowe, pozwala pominąć ten aspekt.

Zdarzenia środowiskowe

Zdarzenia środowiskowe opisują momenty, w których w otoczeniu omawianej domeny dzieje się coś interesującego. Zdarzenia te nie mają bezpośredniego wpływu na sposób funkcjonowania organizacji, nie będą więc one częścią finalnego modelu. Jednak podczas sesji Big Picture EventStorming tego rodzaju eventy pozwalają zrozumieć szerszy kontekst omawianego zagadnienia czy potrzeby poszczególnych aktorów.

Zdarzenia środowiskowe różnią się od zdarzeń domenowych w istotny sposób - nie jest możliwe określenie dokładnego czasu ich wystąpienia czy nawet jednoznaczne stwierdzenie, że faktycznie one wystąpiły. Podobnie jak w przypadku zdarzeń weryfikacyjnych, to odstępstwo od popularnej definicji eventu jest pomijalne, o ile tego rodzaju zdarzenia są jedynie uzupełnieniem dla znacznie ważniejszych eventów.

Zdarzenia interfejsu użytkownika

Zdarzenia interfejsowe opisują momenty, w których zachodzi interakcja z interfejsem użytkownika systemu. Nie określają jednak sposobu, w jaki dana organizacja funkcjonuje. Na tego rodzaju zdarzenie wskazują poniższe czynniki:

• nazwa eventu bezpośrednio nawiązuje do interakcji z interfejsem, pojawiają tu sformułowania typu. …Clicked, …Displayed, …FormSubmitted
• w momencie wystąpienia nie zachodzą zmiany istotne z perspektywy operacyjnej organizacji

Tego rodzaju zdarzenia mogą być pomocne przy identyfikacji driverów architektonicznych dla poszczególnych części systemu, lub projektowaniu jego UI, jednak zazwyczaj opieranie na nich projektowania modelu domenowego jest błędem.

Zdarzenia infrastrukturalne

Zdarzenia infrastrukturalne opisują momenty, w których dzieje się coś znaczącego z perspektywy technicznej. W przeciwieństwie do eventów domenowych, nie opisują CO biznesowo się dzieje w domenie i jej procesach, ale JAK technicznie jest to realizowane.

Różnica ta widoczna jest przede wszystkim w nazwach zdarzeń, gdzie często wykorzystywany jest żargon techniczny, zrozumiały jedynie dla części uczestników warsztatu.

Pozostałe rodzaje eventów

Czy można wyszczególnić inne rodzaje eventów? Zapewne tak.

Zastosowanie praktyczne

Ścisłe klasyfikowanie kolejnych zdarzeń i przypisywanie ich do określonych grup nigdy nie powinno być celem samym w sobie. Czas spotkania jest cenny, nie ma powodu by niepotrzebnie tracić go na dyskusje, czy dane zdarzenia należy do jednej czy drugiej grupy. Nie warto także ich rozróżniać osobnymi kolorami post-itów, wprowadzanie kolejnych elementów notacji mogłoby niepotrzebnie wprowadzać zamieszanie i utrudniać czytanie modelu.

W jakim celu warto więc zauważać różnice pomiędzy poszczególnymi zdarzeniami? Niestety, ale nie każde zdarzenie, o którym łatwo jest komuś opowiadać w trakcie stormingu, jest warte uwagi i czasu pozostałych osób. To na barkach facilitatora leży odpowiedzialność za prowadzenie warsztatu i przybliżanie wszystkich do wyznaczonego celu, umiejętność rozróżniania poszczególnych zdarzeń i w razie konieczności korygowanie kierunku rozmów jest tu więc fundamentalna.

– Uruchamiam aplikację, wybieram z listy odpowiedni formularza i wprowadzam do niego dane
– I co dalej się dzieje?
– Zapisuję go
– A w jakim celu to wykonujesz?
– Nadaję w ten sposób bieg wnioskowi
– Jak wygląda dalsze jego przetwarzanie?
– Analityk musi w 14 dni ocenić ryzyko, o czym od razu informujemy klienta

Powyższa rozmowa pokazuje prosty sposób, w jaki facilitator może szybko przenieść uwagę z kwestii technicznych na biznesowe aspekty działania omawianego procesu. Punktem zwrotnym było tu pytanie o cel wykonywanych w systemie czynności.