Proces sterowany lokalizacją

Ostatnio napotkałem na artykuł dot. wprowadzenia inteligentnych wózków na zakupy w jednej z sieci supermarketów (bodajże francuskich). Przy pierwszych słowach przypomniała mi się moja praca magisterska. Opisałem w niej jak wózek sklepowy może podpowiadać kolejne zakupy klientowi, na podstawie analizy jego dotychczasowych zachowań. W przypadku artykułu, o ile dobrze pamiętam, mowa była o mechanizmie informującym o produktach w zasięgu ręki Klienta. Poniższy diagram prezentuje potencjalne działanie tego procesu w ramach wózka.

W ramach drugiego kroku procesu Określ produkty w zasięgu, mechanizm przygotowany przez sklep, znając lokalizację wózka oraz produktów w sklepie, określałby dostępne produkty. Po ich określeniu mógłby je zaprezentować klientowi (krok: Wyświetl listę produktów) w odpowiedniej kolejności. Zjednej strony będą to produkty w promocji, z drugiej produkty sugerowane przez sklep jako pierwsze, którymi powinien zainteresować się klient (np. produkty pod marką supermarketu najpierw, a potem innych producentów). W zależności od parametrów, lista może być różna.

Nie pamiętam, czy opisany mechanizm posiadał opcje: wskazania przez Klienta jakimi informacjami jest zainteresowany, podania swojego numeru klienta, określenia innych preferencji lub otrzymania wskazówek o umiejscowieniu poszukiwanego produktu . Narzędzie byłoby bardzo pomocne, gdyby jednak je posiadało.

Reklama

Proces akceptacji – sposób sterowania

Zastanawiałem się po przeczytaniu komentarzy do poprzedniego wpisu nad rozwiązaniem dla procesu akceptacji dokumentu. Wydaje się, że są dwa możliwe rozwiązania:

1. System wspiera proces akceptacji i decyduje o tym do kogo trafia dokument po wykonaniu danej akcji. Określa również kiedy proces jest zakończony. Na poniższym diagramie górna część (Diagram A) prezentuje takie podejście. System po akcji użytkownika „Zatwierdź” lub „Odrzuć” wykonuje „Określenie osoby” i ewentualnie „Przesyła dokument”. Operacja „Prześlij dokument” może wystąpić bądź nie. Podobnie w wyniku „Określ osobę” może zostać zakończony proces.
2. Użytkownik decyduje o osobach uczestniczących w procesie. Po wykonaniu „Akceptuj” lub „Odrzuć” użytkownik decyduje, czy przesłać dokument dalej, skonsultować go, czy całkowicie odrzucić. Rolą systemu w takiej sytuacji jest śledzenie i odnotowywanie zmian. Taka sytuacja jest przedstawiona na dolnej części poniższego diagramu (diagram B).

Na powyższym diagramie (diagram przypadków użycia w UML) za pomocą powiązań <<include>> oraz <<extend>> przedstawiono specyfikę następujących przypadków użycia:

• „Określ osobę” – użyto powiązania<<include>>, które oznacza, że zawsze podczas „Zatwierdź dokument” oraz „Odrzuć dokument” występuje „Określ osobę”.
• „Prześlij dokument” – użyto powiązania <<extend>>, które oznacza, że jedynie w określonych sytuacjach (przy spełnieniu ustalony warunków), zostanie wywołane „Prześlij dokument”.

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.

Ślad po procesie

Myślę, że można powiedzieć, że wraz z końcem września kończy się okres intensywnych wyjazdów wakacyjnych i powrotów. Jedni korzystali z samochodu, inni roweru, autobusu, statku, pociągu czy samolotu. Niektórzy skorzystali ze wszystkich, inni z jednego środka transportu a inni z kilku. Pierwszym krokiem był zakup lub rezerwacja biletu, samodzielnie lub przez biuro podróży, elektronicznie lub bezpośrednio w punkcie sprzedaży. W zależności od potrzeb, możliwości, każdy wybierał to, co mu pasuje. Pasażer decydował się na: wybór przewoźnika/linii (1), wybór kierunku (2), daty (3), miejsca startu (4) lub też innych parametrów podróży. Następne kroki zależały od wybranego środka transportu.

Pewnie niektórym pasażerom/turystom to dziś została przy torbie pamiątka z podróży samolotem. Jest to można powiedzieć ślad z realizacji pewnego procesu (wskazanego poniżej). Przyglądając się temu fragmentowi papieru można znaleźć takie informacje jak: (a) nazwisko pasażera, (b) liczba i waga bagażu, (c) data wydruku, (d) oznaczenie miejsca wylotu, (e) oznaczenie samego lotu, (f) oznaczenie miejsca docelowego, (g) data i godzina wylotu oraz (h) dodatkowe oznaczenia. Dodatkowo jest na nim kod kreskowy.

Ten ślad zawiera informacje pochodzące z procesu rezerwacji przelotu wykonywanego samodzielnie lub przez biuro podróży, rozszerzone o informacje pochodzące z odprawy, takie jak data wydruku oraz te, dotyczące bagażu. Przykładowy proces generujący przytoczone atrybuty został zaprezentowany na powyższym diagramie.

Informacje zawarte na tym pasku (bo często jest to długi wąski pasek) pozwalają szybko zweryfikować gdzie powinien trafić bagaż i czy został skierowany prawidłowo. Dodatkowo za pomocą naklejek z powtórzeniem kodu kreskowego, systemy na lotnisku mogą właściwe pokierować bagaż przez systemy sortowania bagażu. Także na samej płycie lotniska te paski lub kody są używane przez obsługę do weryfikacji, a także pewnie identyfikacji załadowanych sztuk bagażu (bo stojąc przy oknie i obserwując załadunek, można zauważyć, że na taśmie bagażowej przy samolocie jest czytnik, o ile dobrze zauważyłem, który skanuje każdą sztukę bagażu).

Można powiedzieć, że z punktu widzenia pasażera jest to ślad po odbytej podróży samolotem, natomiast z punktu widzenia lotniska jest to element zarówno kontrolny, jak i sterujący. Dodatkowo w momencie “zagubienia” bagażu można przypisać bagaż do odpowiedniej linii i przybliżyć się do powiązania bagażu do właściciela.

Filmowy proces a rzeczywistość

Ostatnio oglądałem film Eagle Eye. W filmie tym ukazana jest wizja pełnej inwigilacji społeczeństwa, w którym wybrane jednostki (osoby, zespoły, firmy), przy wykorzystaniu odpowiednich technologii, są “sterowane” do wykonania określonych czynności. Począwszy na opuszczeniu mieszkania, wybraniu środka lokomocji, poprzez sposób poruszania się po wykonywanie zadań w celu znanym tylko przez komputer.

Właśnie ten komputer, wykorzystując różne dane i narzędzia przeprowadza poniższy proces.

Poszczególne kroki wykonywane są w fimie na różne sposoby:

• Nawiąż kontakt poprzez telefon, ekrany na ulicach, samochód;
• Określ lokalizację poprzez położenie telefonu, samochodu czy obserwacje z kamer;
• Wydaj instrukcję poprzez ekrany lub słownie;

Po każdej instrukcji, wykonywana jest weryfikacja postępów w ich realizacji i w zależności od tego czy postęp jest oczekiwany, odbiorca otrzymuje kolejne instrukcje, komunikat lub proces kończy się. Każdy z tych kroków można byłoby rozbić na szczegółówe algorytmy, drzewa decyzyjne lub podprocesy. Wybierając jeden element, można byłoby znaleźć różne jego zastosowania.

Wizja wydaje się dość przerażająca, ale… weźmy na przykład telefon komórkowy – gdy się przemieszczamy, przełączamy się między stacjami bazowymi, gdy zamieszczamy zdjęcie w portalu społecznościowym, to często umieszczamy pod nim naszą lokalizację. Mając teoretycznie dostęp do tych dwóch informacji, jesteśmy w stanie określić w jakim miejscach najczęściej przebywamy i odpowiednio dostosować przekaz. Połączmy to z danymi z innych telefonów komórkowych i mamy powiązania. W internecie (wystarczy wpisać w wyszukiwarce internetowej: „co wie o nas telefon”) można znaleźć wiele publikacji na ten temat. Dobrze jest instalując daną aplikację poświęcić chwilę na jej konfigurację i dostosowanie ustawień do własnych potrzeb i sposobu wykorzystania.

… jako pomoc dla Klienta

Dziś postanowiłem kontynuować temat zapoczątkowany w poprzednich wpisach – dla mechanizmu wsparcia klienta przy wózku zakupowowym, dla którego podstawą jest lokalizacja i identyfikacja produktów. Wyobraźmy sobie, że obok listy produktów, dostępnych w sklepie (czyli Produkty_w_ofercie), wraz z ich lokalizacjami, sklep dysponuje także historią zakupów podzielonych na koszyki (czyli Historia_koszyków). Każda wizyta klienta, niezależnie czy miał 1 produkt w koszyku czy więcej, została zachowana jako pakiet danych z przypisanym identyfikatorem koszyka.

Takie dane można byłoby wykorzystać, aby dynamicznie, w zależności od tego, co Klient umieszcza i wyciąga z koszyka (czyli Produkty_w_koszyku), proponować mu kolejny produkt lub produkty, z podaniem nawet ich lokalizacji w sklepie. Dodany produkt do koszyka wywołałby przeszukiwanie historii koszyków pod kątem wzorca, zawierającego wybrany lub wybrane produkty. Im większa liczba produktów tym więcej produktów do zaproponowania. Ideę takiego działania prezentuje diagram.

Na diagramie został zaprezentowany przypadek dla danego produktu P1 umieszczonego przez Klienta w koszyku. Traktując wskazanie produktu P1 jak pakiet produktów, diagram jest nadal prawdziwy, ponieważ w zestawieniu z Historią koszyków, P1 może oznaczać pakiet produktów.

Proces przebiega w trzech krokach: odszukanie produktu/pakietu z koszyka w historii zakupów, sprawdzenie produktów w odnalezionych koszykach a następnie wybór produktów do zaoferowania Klientowi. Klient otrzymuje propozycję produktów, w przykładzie jest to produkt P3, a zakupy są dla niego łatwiejsze – może “nie zapomni” o jakimś produkcie, który zwykle kupował przy podobnym zestawie produktów.

… i falami radiowymi

W poprzednim wpisie, dotyczącym określania położenia wózka i wyświetlania produktów w pobliżu, pominąłem kwestie tego, co robi Klient. Klient może wziąć do ręki dany produkt (wyświetlony lub nie na ekranie), obejrzeć i odłożyć, zajrzeć na półkę, a także może włożyć produkt do wózka. I ta ostatnia sytuacja mnie dzisiaj interesuje.

Gdyby sklep chciał zbierać informację o tym, które produkty wyświetlane w danym momencie, rzeczywiście trafiły do wózka, musiałby mieć technologię, za pomocą której szybko rozpozna jakie produkty trafiły do koszyka, a które na przykład zostały z niego wyciągnięte i odłożone na półkę. Do takich działań, bez angażowania Klienta lub pracownika można wykorzystać technologię RFID.

RFID (ang. Radio-Frequency IDentification) to określenie, które opisuje technologię, umożliwiającą automatyczną rozpoznanie obiektu przy użyciu fal radiowych. W powyższym przypadku mechanizm zamontowany na wózku namierza tzw. chip RFID (krok Namierz fale z chipa na diagramie), automatycznie odczytuje informację przypisaną do produktu na chipie RFID (krok Odczytaj dane z chipa na diagramie) za pomocą fal radiowych. Następnie rozpoznaje produkt w bazie produktów (krok Odszukaj produkt w bazie lub na liście na diagramie) na podstawie zebranych informacji (identyfikatora oraz innych danych). W danym momencie może rozpoznać kilka (lub więcej) produktów. Na tej podstawie odnotowuje produkt na liście zakupów (krok Dodaj produkt do listy), którą może także być wyświetlana klientowi. Może także usuwać produktu z listy (krok Usuń produkt z listy), gdy Klient wyciągnie je z wózka.

Taka technologia może bardzo przyspieszyć proces zakupów, np. przy kasie w sklepie lub go ułatwić, gdy gabaryty produktów utrudniają łatwy dostęp do identyfikatora produku, umieszczonego w inny sposób na nim. W wielu artykułach można spotkać stwierdzenie, że nie przy wszystkich produktach zastosowanie takiej technologii byłoby możliwe lub przede wszystkim opłacalne. Jednakże, gdy zastosować ją w sklepach do sprzedaży hurtowej, byłoby to już bardziej uzasadnione.

Proces oparty o stany

Wyobraźmy sobie, że parking opisany ostatnio we wpisie, wykonuje oprócz wskazanych 3 podstawowych działań (przyjęcie samochodu, przyjęcie opłaty i wypuszczenie samochodu), jeszcze jedną bardzo ważną rzecz. Mianowicie, wskazuje w momencie wjazdu na parking, gdzie jest najbliższe wolne miejsce. Niby rzecz trywialna, ale wymaga odpowiedniego przygotowania – zarówno od strony infrastruktury (kontrola zajętych miejsc, identyfikacja gdzie są samochody wcześniej wpuszczone, które jeszcze nie zaparkowały), jak i informatycznej (odpowiedni system zarządzania miejscami parkingowymi, kontrolą stanów miejsc i ich zmianą, a także prezentacją graficzną parkingu).

Z jednej strony mamy zmianę stanu miejsca parkingowego, a z drugiej weryfikację położenia, gdzie jest wolne miejsce. Takie procesy zostały zaprezentowane na powyższym diagramie. W momencie realizacji procesu (na diagramie Określ mapę dojazdu) z prezentacją najbliższego wolnego miejsca (na diagramie Wyświetl mapę dojazdu) system musi wziąć pod uwagę stany miejsc parkingowych wynikajacych z:

• zajęcia miejsca parkingowego (zmiana stanu na zajęty),
• opuszczenia miejsca parkingowego (zmiana statusu na wolny),
• przemieszczania się samochodów wpuszczonych na parking (w dowolnym momencie dane miejsce może zmienić stan),
• lokalizacji samochodów wpuszczonych na parking (np. są na 2 poziomie, a miejsce akurat jest na 1 poziomie).

Chcąc uniknąć ryzyka, że wskazane najbliższem miejsce okaże się zajęte, można także wskazywać miejsce alternatywne. Dodatkowo już po wjeździe na parking w widocznych miejscach mogłyby być umieszczone ekrany wskazujące na najbliższe wolne miejsce parkingowe (cykliczne wykonywanie pierwszego procesu). Ułatwieniem w zarządzaniu takim parkingiem mogłoby być to, że nie da się cofnąć do innego miejsca parkingowego, nie przejeżdżając przez punkt startowy, który dodatkowo jest kontrolowany przez system.

W podanym przykładzie podane procesy opierają się na świadomym wykorzystaniu stanów poszczególnych miejsc parkingowych (oznaczone za pomocą funkcji w klasach UML na diagramie). Stany miejsc występują naprzemiennie i trudno jest określić jakie są ramy czasowe dla rozpoczęcia procesu i jego zakończenia. Dla danego miejsca stan może się nie zmienić godzinami lub zmienić się raz i pozostać taki przez wiele godzin. Takie cechy są charakterystyczne dla procesów sterowanych stanami – ang. state-driven process. Skierowanie samochodu na dane miejsce jest możliwe tylko, gdy jest ono wolne. Zmiana stanu odbywa się poprzez odnotowanie wjazdu samochodu na dane miejsce.

Obiekty danych w procesie BPMN

Kolejnym etapem realizacji zlecenia w serwisie samochodowym, była kwestia płatności I otrzymanie potwierdzenia. Otrzymałem wydruk zlecenia z kwotą, statusem oraz wykonanymi czynnościami. Przyglądając się zleceniu zauważyłem, że składa sie ono z informacji uzyskanych od Klienta, danych wprowadzonych przez operatora i danych z rejestru części dostępnych w serwisie. Elementy to obiekty danych, które razem tworzą zlecenie. Operacje na tych danych pokazuje poniższy diagram BPMN.

Obiekty danych są z jednym z elementów procesów w BPMN. Mogą informować o danych służących do realizacji zadań przez użytkownika w systemie, obiektach wykorzystywanych przez samą aplikację oraz efektach działania aplikacji. Na diagramie zaprezentowano przykłady. Obiekt (ang. Data Object), na którym działa proces, ma wskazane różne statusy – Zarejestrowany, Wydrukowany. W tym celu wykorzystuje się element BPMN oznaczony poprzez prostokąt z “zagiętym rogiem”. Obiekty wejściowe (ang. Data Input) są oznaczane pustą strzałką, a obiekty wyjściowe (ang. Data Output) – pełną strzałką.

W tym wypadku obiekt Zlecenie można potraktować jako złożenie danych kluczowych i danych zawartości. Proces jest sterowany przez operatora.

Benchmarking procesów

Benchmarking procesów jest jednym z 3 rodzajów benchmarkingu, biorąc pod uwagę przedmiot porównania (obok benchmarkingu strategicznego i benchmarkingu produktów). Polega na analizie procesów liderów rynkowych pod względem efektywności kosztowej oraz sposobie kreowania wartości dla klienta, a następnie porównanie z procesami danego przedsiębiorstwa i wyciągnięciu wniosków. Wnioski z porównania mogą przyczynić się do przeprowadzenia odpowiednich zmian. Na przykład w ramach łańcucha dostaw ten rodzaj benchmarkingu skupia się przede wszystkim na następujących możliwościach odnośnie procesów:

• łańcuch kierowany przez dialog z klientem,
• skuteczna dystrybucja,
• planowanie sprzedaży na podstawie popytu,
• wytwarzanie odchudzone (ang. lean manufacturing),
• partnerskie stosunki z dostawcami,
• zintegrowane zarządzanie łańcuchem.

Na powyższym diagramie (w BPMN) zaprezentowano w sposób uproszczony przebieg łańcucha dostaw sterowanego popytem klienta. W trakcie określania przedmiotu realizacji następują ustalenia między Klientem a przedstawicielem dostawcy/producenta. Diagram zawiera moment oczekiwania na decyzję klienta – proces planowania nie rozpocznie się, jeżeli zamówienie nie zostanie potwierdzone. Nie są przygotowane produkty na magazynie. Pominięta została w przykładzie kwestia dostawy surowca czy zlecania pracy podwykonawcom. Uwzględniając te elementy można byłoby wskazać także w jaki sposób przebiegają kontakty z kolejnymi uczestnikami procesu. Modnym podejściem w kontekście organizacji procesów produkcyjnych, dostawczych jest stosowanie tzw. wytwarzania odchudzonego.