Proces wyborczy

Tydzień temu odbyły się w Polsce wybory Prezydenta RP. Głosy zdobyte przez kandydatów rozłożyły się i żaden kandydat nie zdobył ich liczby wymaganej do wygrania w pierwszej turze (czyli powyżej 50% głosów). Za tydzień będzie więc druga tura… Od kilku tygodni, temat nie schodził z pierwszych stron serwisów, z czołówek wiadomości. Jedni informowali o tym gdzie tym razem się pojawił dany kandydat, co powiedział, co się wydarzyło w trakcie spotkania, a inni przypominali o wcześniejszym zachowaniu, decyzjach. Jedni przekonują na spotkaniach bezpośrednich, a inny wykorzystując sieć Internet. Jedni tworzą nowe hasła wyborcze, a drudzy opierają się na dotychczasowych zdaniach. Jedni zastanawiali się na kogo zagłosować, inni wiedzieli od samego początku. Teraz z kolei pojawiają się sondaże, które raz dają wygraną jednemu kandydatowi, a innym razem temu drugiemu. Kandydaci musieli jednak zacząć od zgłoszenia swojej kandydatury oraz przedstawienia odpowiedniej liczby głosów popierających. A jeszcze wcześniej musiał zostać ogłoszony termin wyborów, aby cały proces mógł ruszyć.

Proces wyborczy o zgłoszenia komitetu/kandydata, poprzez prowadzenie kampanii aż po przeprowadzenie samych wyborów, definiuje tzw. Kodeks wyborczy. Szczegółowe wytyczne są opisane w dokumencie „Kodeks wyborczy”, dokładnie ustawie, opublikowanej na stronach rządowych dotyczących wyborów. Jest to dokument, który określa zasady dla poszczególnych wyborów. Na potrzeby tego wpisu skupiałem się na dziale V, a efekt tego spróbowałem zobrazować na poniższym diagramie.

Kilka komentarzy do tego procesu:

• W sam proces wyboru Prezydenta (wg rozdziału 1 w dziale V) są zaangażowane minimum 3 podmioty – Marszałek Sejmu, Kandydat na Prezydenta oraz Państwowa Komisja Wyborcza – co oznaczyłem elementami znanymi z UML, łącząc te obiekty z odpowiednimi krokami procesu, przez połączenia typu asocjacja.
• Działania w tym procesie wykonywane są w określonym rygorze czasowym w zakresie momentu ogłoszenia oraz przeprowadzenia poszczególnych etapów – co zaznaczyłem przez zdarzenia wskazujące na momenty czasu (ang. timer event) wykorzystywane w diagramach BPMN.
• W procesie jest krok „Zgłoś kandydaturę” oznaczony jako podproces, ze względu na to, że jest to rozbudowane działanie (opisane w rozdziale 2 działu V), realizowane także w ustalonym rygorze czasowym. Kroki tego procesu zostały zasygnalizowane w ramce „Zgłoś kandydaturę”, wraz z połączeniem ich do wskazanych wcześniej uczestników procesu.
• W procesie kluczowym elementem jest krok „Zlicz głosy” , występujący 2 razy, przy czym pierwszy z nich występuje zawsze, a drugi opcjonalnie, w zależności od wyników 1 tury głosowania, co zostało oznaczone za pomocą bramki opartej o dane (ang. Exclusive data-based gataway)

Reklama

„Ciche” zdarzenie w procesie

Miałem pomysł na wpis zainspirowany tym, co się dzieje obecnie w Polsce i na świecie. Zrezygnowałem jednak z niego, choć tematyka tego wpisu będzie jakoś związana z tematyką zdrowia i medycyny. Jakiś czas temu, wysłałem w usługach medycznych zlecenie.. Po wybraniu właściwej opcji, potwierdzeniu oświadczeń zlecenie zostało wysłane. Mijają kolejne dni, a powiadomienia o realizacji/podjęciu zlecenia nie przychodzi. Po sprawdzeniu w systemie okazało się, że zlecenie wisi. Postanowiłem ustalić co się dzieje poprzez wykorzystanie infolinii zamiast udawać się do punktu, czekać w kolejce i odejść „z niczym” – co się ostatecznie okazało. Okazało się, że lekarz właściwy do podjęcia zlecenia jest nieobecny przez określony czas. Trudno, trzeba poczekać.

Wracając jednak do infolinii, z której nie korzystałem od dawna, spotkałem się z nową dla mnie sytuacją. Generalnie bardzo rzadko mam okazję korzystać z infolinii. Ostatnie moje doświadczenia były inne, bardziej standardowe, opierające się na wybieraniu określonych numerów z klawiatury, a potem kończyło się rozmową z konsultantem. Tym razem było inaczej…

Po przywitaniu, przedstawieniu formuły o ochronie danych osobowych, identyfikacji poprzez podanie numeru klienta, padło sformułowanie: „Proszę powiedzieć czego potrzebujesz…”. I w tym momencie nastała cisza – ja nic nie mówiłem i w słuchawce była cisza. Czekałem na standardową formułkę: „Wybierz 1, aby…., wybierz 2, aby…”. Po kilkunastu sekundach usłyszałem: „Powiedz, co potrzebujesz, na przykład [i pojawia się fraza] chcę się umówić na wizytę”. I w tym momencie stało się jasne, że zmienił się model obsługi na infolinii. Podałem potrzebę i „obsługa” poszła dalej już w mniej zaskakujący sposób. Było to ciekawe doświadczenie, które próbowałem zobrazować na poniższym diagramie w BPMN, z pewnym zastrzeżeniem. Zastosowałem na nim uproszczenie dla zadania „Kontynuuj proces” (zaznaczonego linią przerywaną). Nie wskazałem konkretnych kroków, które dalej mogłyby wystąpić – można to potraktować jako podproces lub pominięcie kroków procesu podczas jego wizualizacji.

Po rozłączeniu zacząłem się zastanawiać:

• (1) na ile sekund ciszy był ustawiony system (oznaczenie zdarzenia czasowego (ang. intermediate timer event) na diagramie),
• (2) co w sytuacji, gdybym użył jakiegoś sformułowania, np. komentując do osoby obok: „chyba nie działa”,
• (3) co w sytuacji, gdybym użył słowa, na które system nie jest przygotowany,
• (4) co w sytuacji, gdybym powiedział coś za cicho/niewyraźnie lub w sposób niekompletny (np. ze względu na posiadane objawy)

System w różnych sytuacjach może mieć przygotowaną odpowiednią reakcję – prosić o powtórzenie, powiedzenie głośniej, użycie innych słów, „dopyta” lub skieruje bezpośrednio do konsultanta z odpowiednim oznaczeniem sprawy. Sytuacje (2)–(4) są wynikiem działań oznaczonych na diagramie poprzez grupę, w której znajduje się „Przeanalizuj przekaz”. Jest to pewne uproszczenie, na które sobie pozwoliłem i wykorzystałem do tego element bramki opartej o dane (ang. data based gateway). Danymi tutaj jest „treść” przekazu przełożona na odpowiednie części składowe oraz odpowiednio przeanalizowana (zainteresowanych odsyłam do publikacji na ten temat).

Przypuszczam, że takie rozwiązania nie są rzadkością. Wynikać to może z różnorodności potrzeb użytkowników. Zdarzyło mi się kilka razy, że zastanawiałem się, którą opcję wybrać spośród wskazanych i przeważnie wtedy wolałem nawiązać połączenie z konsultantem. Myślę, że pewne kwestie mogą zostać obsłużone bez udziału konsultanta – na przykład mógłbym sobie wyobrazić, że przesunięcie wizyty na pierwszy możliwy termin. W powyższym przypadku to system za użytkownika wybiera odpowiednią ścieżkę obsługi a może nawet skierować do odpowiedniego konsultanta, bazując na ustalonych regułach czy słowach kluczowych.

Gdy aplikacja pamięta Twój telefon

Wczoraj otrzymałem maila o tytule „Próba logowania przy użyciu nieznanego urządzenia”. W pierwszym momencie zacząłem się zastanawiać… Czy ktoś loguje się moimi danymi, a może ktoś się pomylił… Przeglądając jednak treść wiadomości zauważyłem oznaczenie aplikacji, która wygenerowała taką wiadomość. Zainstalowałem na nowym telefonie aplikację (jednego ze sklepów stacjonarnych wraz ze sklepem internetowym), którą miałem także na starym telefonie. Podczas próby zalogowania się pomyliłem się i pewnie aplikacja zidentyfikowała, że logowanie nastąpiło po przerwie, ale z innego urządzenia. Sprawdziłem w regulaminie aplikacji, że oprócz podawanych świadomie danych przez użytkownika, zapisuje ona również numer używanego urządzenia mobilnego. Element ten widocznie pozwala na rozróżnienie, że użytkownik, który próbuje się zalogować użył innego urządzenia. Regulamin wskazuje po co zbiera tę informację i jawnie o tym informuje.

Na poniższym diagramie w BPMN, będącym moim wyobrażeniem procesu występującego w takiej aplikacji na bazie obserwacji aplikacji/narzędzi, z których korzystam, są wskazane kroki (na zielono), które w tle identyfikują urządzenie użytkownika i następnie w przypadku poprawnego logowania zapisują te dane. W przypadku nieudanego logowania, używa tych danych do weryfikacji zgodności urządzenia z poprzednio stosowanym. Taki mechanizm, stosowany także przez inne narzędzia, pozwala podnieść bezpieczeństwo logowania, chronić dane osobowe. Wykonuje to przez każdorazowe informowanie użytkownika na podany podczas rejestracji adres e-mail co najmniej o tym, że nastąpiła jakaś nieudana próba logowania (ścieżka (1) na diagramie).

Niektóre narzędzia/aplikacje wysyłają powiadomienie o poprawnym logowaniu, które nastąpiło z innego urządzenia niż dotychczas (ścieżka (3) na diagramie). W podanym przykładzie nastąpiło wejście do aplikacji, ale nie musi to nastąpić – zależy to od sposobu zbudowania aplikacji i przyjętych założeń. Może być tak, że najpierw użytkownik musiałby potwierdzić, że to on się logował. Na diagramie zostały zaznaczone obydwie takie opcje obok ścieżki gdy dane poprawne logowanie odbywa się z tego samego urządzenia co dotychczas (ścieżka (2)).

Powyższy przebieg procesu został zasygnalizowany przy użyciu odpowiednich elementów BPMN, przy czym:

• (oznaczona przez (A)) do przeprowadzenia równoczesnej identyfikacji urządzenia oraz identyfikacji użytkownika pod kątem późniejszej autentykacji  użyto bramek rozdzielających i łączących dla ścieżek równoległych (ang. paralel gateway).
• (oznaczona przez (B)) do podjęcia decyzji są użyte bramki oparte o dane, w których tylko jedna ze ścieżek jest możliwa (ang. exclusive).

Użytkownik otrzymując taką wiadomość (kroki oznaczone na żółto na diagramie) może zadecydować czy jest to sytuacja, o której wie, czy może jest to sytuacja, na którą powinien zareagować. Na przykład nie używał aplikacji danego dnia lub w ostatnim czasie, a nagle otrzymuje informację o próbie zalogowania nieudanego lub udanego.

Jeżeli dane narzędzie/aplikacja ma taką obsługę logowań, to widzę 2 możliwości:

• Twórca/Właściciel narzędzia równocześnie zapewnia narzędzia wspierające obsługę reakcji użytkownika (np. tymczasowa blokada użytkownika, kontakt z twórcą/właścicielem lub inne) lub
• Mechanizm ma tylko charakter informacyjny i użytkownik na własną rękę musi poszukać metod reakcji (np. zmienić hasło).

Myślę, że to dobrze, że istnieją takie mechanizmy. Dzięki takim rozwiązaniom mamy większą pewność, że nasze dane, przechowywane w aplikacji, nie zostaną podejrzane przez nieuprawnioną osobę lub też dowiemy się szybko o tym, że ktoś taką próbę wykonał. Patrząc na serwisy, aplikacje dostępne z różnych urządzeń, jest to duże ułatwienie oraz wsparcie w zakresie realizacji wskazówek dotyczących bezpiecznego korzystania z aplikacji mobilnych (opublikowanych na stronach urzędowych).

Użytkownik otrzymując taką wiadomość w sytuacji, gdy określa ją jako wymagającą zareagowania, powinien zastanowić się jakie dane podał w danej aplikacji – ograniczoną liczbę informacji (np. tylko e-mail) czy dane generujące dla ich właściciela duże ryzyko (np. dane pesel, adres zamieszkania, numer dowodu wraz z wizerunkiem czy danymi finansowymi). Mam nadzieję, że nikt z czytelników mojego bloga nie doświadczył tego bardziej ryzykownego wariantu.

—
Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.

Gdy brak zdarzenia…

Ostatnio idąc do pracy, zauważyłem jak zmienia się cykl na skrzyżowaniu, które muszę pokonać. Samochody zaczęły zwalniać i w momencie jak dotarłem na skrzyżowanie zapaliło się im czerwone a ja nacisnąłem przycisk dla pieszych, aby wywołać zielone. Niestety zgodnie z cyklem zapaliło się światło zielone najpierw na jednej podporządkowanej, potem na drugiej. W tym momencie powinno zapalić się światło zielone dla pieszych, ale to nie nastąpiło. Przypuszczam, że za późno nacisnąłem przycisk, aby algorytm zmiany świateł to wyłapał. Może przycisk nie działał, choć to raczej nie możliwe, bo często z tego przejścia korzystam. Mogę przypuszczać, że cykl jest ustawiony jak na poniższym diagramie.

Na powyższym diagramie w BPMN wykorzystane zostały elementy:

• Zdarzenie oparte o czas (nadejście określonego momentu czy minięcie określonego czasu), co jest oznaczone przez obiekt timer event. Na diagramie są 2 takie zdarzenia: początkowe dla procesu (start timer event), oznaczone jako (A) na diagramie oraz pośrednie, występujące wewnątrz procesu (intermediate timer event), oznaczone kolejnymi literami (B, C, D, E).
• Zdarzenie informujące o otrzymaniu sygnału/komunikatu od zewnętrznego aktora (message event), tym razem zastosowane wewnątrz procesu (intermediate message event). Takim komunikatem/sygnałem jest żądanie od pieszego, który oczekuje zmiany światła z czerwonego na zielone dla przejścia dla pieszych. Ostatnio wskazywałem, że to zdarzenie może rozpocząć proces. W tym wypadku to zdarzenie wpływa na przebieg procesu, który wykonałby się i tak bez tego zdarzenia – nastąpiłaby zmiana świateł, tak, aby samochody z dróg podporządkowanych mogły przejechać przez skrzyżowanie. Różnica między obiektami jest widoczna na diagramach – jedno z nich ma pojedynczą linię (początkowe), a drugie podwójną (wewnątrz procesu).
• Bramka oparta o zdarzenia (event-based gateway) do rozdzielenia ścieżki. Bramka ta (typu exclusive) działa w ten sposób, że pierwsze napotkane zdarzenie inicjuje uruchomienie ścieżki/przebiegu procesu, występującego po tym zdarzeniu. Na końcu rozdzielenia też jest bramka i w zależności od jej rodzaju – wszystkie ścieżki muszą dojść do tego miejsca lub wystarczy jedna, aby proces przeszedł dalej. W powyższym przykładzie zastosowano również bramkę, która oznacza, że wystarczy tylko jedno z „wejść”, aby przejść dalej w procesie (tzw. exclusive gateway). Taka bramka znajduje się także poniżej, w celu wyboru jednej ze ścieżek, w zależności od tego, czy światło dla pieszych jest zielone czy nie. Decyzja oparta jest o zebrane dane/statusy (exclusive data-based event) a nie zdarzenia. Wcześniejsze zdarzenie (żądanie pieszego) spowodowało zmianę światła lub nie – jest to w sumie zero-jedynkowe. Takie oznaczenie można zaliczyć do danych sterujących procesem. Gdy brak takiego zdarzenia, zadania dotyczące światła dla pieszych w przebiegu procesu zostaną pominięte.
• Zadania (ang. tasks) wykonywane w procesie – zmiany świateł na czerwone, a potem na zielone dla odpowiednich sygnalizatorów oznaczonych numerami (1)-(4).
• tzw. artefakty, czyli dodatkowe elementy rozszerzające interpretację diagramu. Dodałem komentarze dotyczące przebiegu procesu, aby lepiej oznaczyć miejsca, które opisuje w punkcie dotyczącym bramek. Są to informacje dodatkowe, które nie sterują przebiegiem procesu, a pozwalają lepiej zrozumieć przedstawiony diagram.

Za pomocą wskazanych obiektów można sterować przebiegiem procesu oraz sekwencją wykonywanych zadań. W zależności od obsłużonych zdarzeń lub ich kolejności wystąpienia, proces pójdzie ścieżką „domyślną”, obsłuży wyjątek lub zastosuje zadania wynikają z alternatywnego przebiegu procesu. Powyższy proces mógłby przebiegać tak, że zawsze następuje przełączenie światła dla pieszego – z czerwonego na zielone, niezależnie od jego żądania.

Może być też tak, że w zależności od liczby żądań, czy jedno czy z dwóch stron jezdni, zmiana świateł dla samochodów następuje szybciej lub czas oznaczający, że konieczne jest przestawienie świateł się wydłuża. Pewnie istnieje też system, który dostosowuje długość cykli do ruchu lub natężenia ruchu pieszych. W niektórych miastach były testowane (a nawet chyba są wdrożone) takie mechanizmy, które badają natężenie ruchu lub mają zmienny system sygnalizacji w zależności od pory dnia.
—
Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Dzięki niej będę mógł tworzyć treści bardziej dostosowane do Waszych oczekiwań. Jeżeli pojawią się jakieś uwagi do samej ankiety lub problemy z jej wypełnieniem prośba o sygnał w komentarzu lub na adres e-mail podany po prawej stronie.

Decyzje pod kontrolą lub poza

Dzisiaj ponownie przybliżę temat tzw. bramek wyłączających (ang. exclusive gates), czyli takich, z których możliwe jest tylko jedno wyjście do dalszego procesu. Około rok temu, wskazywałem we wpisie o podejmowaniu decyzji w procesie, że mamy dwa rodzaje tych bramek: oparte o dane (ang. data-based) oraz oparte o zdarzenia (ang. event-based). Podany wtedy przykład nie podawał wyraźnie rozróżnienia między tymi bramkami. Dzisiaj postaram się podać lepszy przykład.

Załóżmy, że nadal mówimy o procesie przygotowania raportu. Otrzymaliśmy wniosek i analizujemy, czy mamy komplet danych i są one spójne. Posługujemy się danymi dostępnymi tu i teraz, lokalnie, bez angażowania innych osób, chcemy zrealizować zlecone zadanie. I to jest jest właśnie specyfika bramek opartych o dane (ang. exclusive data-based). Na powyższym diagramie w BPMN jest to pierwsza z bramek, występująca po czynności Określ parametry wniosku. Wszystkie elementy są pod kontrolą wykonującego czynność. Wiemy dokładnie jakie czynności zostaną wykonane dalej.

W sytuacji jednak, gdy dane okażą się niespójne lub zabraknie danej do parametryzacji oczekiwanego raportu, pojawia się konieczność kontaktu z odbiorcą raportu. W tym momencie, dalszy przebieg procesu jest poza naszą kontrolą. To, co się dalej wydarzy jest uzależnione od odbiorcy raportu. To jest charakterystyczne dla bramek opartych o zdarzenia (ang. exclusive event-based). Na powyższym diagramie w BPMN jest to druga bramka. W sumie wiemy co dalej możemy wykonać w przypadku różnych działań odbiorcy, ale sama jego decyzja jest niezależna od samego procesu.

Myślę, że powyższy przykład lepiej oddaje charakter tych dwóch bramek. Innym przykładem może być ten z wysyłką listu/wykonywaniem telefonu, a odbiorem przesyłki/odebraniem telefonu.

Jak „podejmowane” są decyzje w procesie w BPMN?

Niektóre sklepy komputerowe stosują praktykę, że podczas rozliczania transakcji weryfikują cenę produktu z wewnętrzną bazą/stroną internetową. Klient wybierając produkt na półce prosi o jego udostępnienie, a następnie decyduje się bądź nie na jego zakup. W takim sklepie mówiąc, że jest zainteresowany, może usłyszeć, że cena jest wyższa, niższa lub taka sama. Poniższy przykładowy diagram w BPMN prezentuje właśnie taki proces – jest to proces, którego rzeczywiście doświadczyłem. Pozostawiłem pewne elementy bez ostatecznego rozwiązania, ponieważ każdy mógłby zachować się inaczej, sklep mógłby postąpić inaczej. Nie będę wskazywał jak postąpiłem, nie jest to istotne z punktu widzenia tematu, który chcę poruszyć.

W trakcie takiego procesu mamy różne momenty decyzyjne, oznaczone przez znaki w kształcie rombów na diagramie. W tym wypadku zostały zastosowane elementy charakterystyczne na diagramów w BPMN. Takie sytuacje zakupowe są idealnym przykładem do prezentacji elementów decyzyjnych na procesie. W powyższym przykładzie obydwa zastosowane elementy – „z pięciokątem w środku” oraz „z krzyżykiem” – oznaczają przypadki, gdy tylko z jedna z dalszych ścieżek diagramu może zostać zastosowana. Są one wyłacząjące się (ang. exclusive).

Pierwszy z nich – „z krzyżykiem” – opiera się na weryfikacji warunku, sprawdzeniu wartości dla określonych danych (ang. exclusive data-based). W przykładzie następuje sprawdzenie warunku dotyczącego ceny (na diagramie specjalnie go nie umieściłem aby to omówić w treści). Klient sprawdza, czy zawiera się w kwocie, którą przeznaczył na zakup. Sprzedawca porównuje dwie ceny – cenę z spółki i cenę z systemu. W zależności od wyniku następują różne komunikaty.

Drugi z nich – „z pięciokątem w środku” dotyczy oczekiwania na zdarzenie innej osoby, klienta, jako wynik jego zachowania, zrealizowanych działań (ang. exclusive event-based). W niniejszym przykładzie jest to wynik analizy produktu przez Klienta. Tak naprawdę sprzedawca może jedynie czekać, ponieważ nie wie co sprawdza Klient i jaka będzie jego ostateczna decyzja. Oczekuje określone zdarzenia – chcę kupić lub rozmyśliłem się. Można by jeszcze dodać opcję – chciałbym zobaczyć podobne produkty albo wróci do początku procesu.