Pod koniec listopada w Poznaniu miał się odbyć koncert jednej ze znanych grup muzycznych. Koncert miał się odbyć w dość starej sali widowiskowo-sportowej, ale niestety, dla zainteresowanych, nie odbył się. Nie miałem biletów na ten koncert, ale akurat trafiałem w lokalnym serwisie na kolejne informacje na ten temat. Na kilka godzin przed koncertem zmieniono jego lokalizację (na inną część miasta), a bliżej godziny koncertu, zupełnie go odwołano. Zastanawiałem się jak na to zareagowali uczestnicy koncertu:
- Ci, co dotarli pod pierwsze miejsce koncertu;
- Ci, co dotarli pod drugie miejsce koncertu, bo się o zmianie dowiedzieli lub zostali odesłani z pierwotnego miejsca koncertu (ciekawe, czy ktoś tam osobiście informował osoby);
- Ci co nie dotarli wcale, bo mieszkają w okolicy i nawet nie wyszli z domu;
Jak można byłoby usprawnić proces komunikacji dot. zmiany lokalizacji lub odwołania koncertu?
Myślę, że cały proces mógłby zostać usprawniony (nie wiem czy taka możliwość istniała), gdyby każdy z kupujących bilet musiał to zrobić w tym samym miejscu lub też miałby możliwość podania numeru telefonu, który mógłby zostać wykorzystany tylko w opisanej wyżej sytuacji. Uczestnik miałby możliwość zapisania się (ang. subscribe) na konkretną informację na przykład z zastrzeżeniem, że potem jego numer telefonu jest usuwany. Równocześnie organizator zadeklarowałby, że będzie udostępniał tylko określoną informację (ang. publish), która przez dostępny system (na diagramie środkowa ramka System) zostanie przekazana na numery telefonów. Organizator nie znałby numerów telefonów, a tylko tematy, które przekazuje do pośrednika.
Opisany model interakcji, stosowany w architekturze oprogramowania, określany jest jako wzorzec publish-subscribe, czyli model składający się z części odpowiedzialnej za udostępnianie informacji przez jego dostawcę (część publish jest opisana na górnej części diagramu, opisanej jako Dostawca informacji) oraz części umożliwiającej wskazanie zainteresowania odpowiednimi tematami przez odbiorców informacji (dolna część diagramu opisana przez Odbiorca informacji). Odbiorcy otrzymują tylko informacje, których oczekują, natomiast nadawca informacji może wystawiać różne komunikaty, bez wiedzy do kogo i czy one trafią.
Wyobraźmy sobie, jak na powyższym diagramie, że uczestnicy koncertu (czyli odbiorcy), kupując bilet zaznaczają: chcę otrzymać informację o zmianie terminu koncertu i jego odwołaniu (wybór tematu na diagramie), a nie chce otrzymywać informacji o usprawnieniach dot. dojazdu czy atrakcji powiązanych. Organizator koncertu równocześnie planuje wystawiać informacje o potencjalnej zmianie terminu, odwołaniu, dojazdach, atrakcjach towarzyszących, innych koncertach itd. Uczestnik otrzyma to, co potrzebuje a Dostawca daje to, co chce (czyli przygotowanie komunikatu w określonym temacie).
Nie wiem na ile takie rozwiązania w komunikacji z uczestnikami miały w opisanej sytuacji miejsce, ale pewnie ułatwiłyby „życie” uczestnikom koncertu w momencie jego odwołania, a nie tylko przeniesienia w inne miejsce.
Modelowanie procesów biznesowych 