Archive for the ‘modelowanie’ Category

h1

Ślad po procesie

Wrzesień 29, 2017

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.

przelot450px

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.

Reklamy
h1

Po co to zdarzenie początkowe?

Luty 13, 2016

W przypadku BPMN stosowanie zdarzeń początkowych nie jest obligatoryjne, jednakże dobrą praktyką jest ich stosowanie. Jest to istotne, aby oznaczyć gdzie zaczyna się proces. Łatwiej odbiorcy diagramu określić, która czynność jest pierwsza. Łatwiej mu także zapoznać się z logiką procesu, który jest na diagramie. Wyobraźmy sobie, że na poniższym przykładowym (w BPMN) diagramie nie ma oznaczonego zdarzenia początkowego, które zostało zaznaczone. Skąd będziemy wiedzieć, gdzie się zaczyna proces i co powoduje jego przeprowadzenie? Czy zaczynamy od przekazania raportu do akceptacji czy od korekty?

zdarzenie_poczatkowe_1_450px

Umieszczenie zdarzenia początkowego (ang. start event) ma także tę zaletę, że można okreslić typ tego zdarzenia. Można np, wskazać, że proces ma miejsce co miesiąc, albo w określonym momencie czasu. Także może sygnalizować jakie fizycznie zdarzenia go inicjuje i jakie warunki. Zależy to również od tego jak szeroki proces chcemy pokazać. Jeżeli autor diagramu zakłada, że np. przyjęcie zamówienia jest pierwszym krokiem, to przed nim dobrze jest umieścić zdarzenie początkowe.

Wiele narzędzi stosowanych do modelowania procesów w notacji BPMN kontroluje, czy dana czynność (ang. task) ma połączenie (ang. connection) przychodzące i wychodzące. Zdarzenie początkowe nie wymaga połączenia przychodzącego.

 

h1

Niemy proces

Styczeń 31, 2016

W sumie dzisiejszy wpis mógłbym zacząć podobnie jak wpis, który niecały rok temu zamieściłem na swoim blogu. We wpisie w marcu 2015r. skupiłem sie na tym, że zdzwoni do mnie często ten sam numer, a gdy go odbieram, to przedstawiciel sieci komórkowej lub innego dostawcy próbuje przekonać mnie do skorzystania z nowej oferty lub zmiany parametrów istniejącej. Po kilku kolejnych telefonach, dalej już nie dzwonili.

Teraz mam podobną sytuację, ale niestety odbierając połączenie, nie słyszę operatora, a muzyczkę lub jest cisza w słuchawce. Domyślam się, że nastąpił rozwój narzędzi i numer telefonu jest wydzwaniany i umieszczany w kolejce do danego konstulanta, gdy jeszcze on nie zakończył poprzedniej rozmowy. Za każdym razem, przerywam połączenie, bo nie ma zamiaru czekać nieokreślony czas na nawiązanie połączenia. A Ci dzwonią po raz kolejny. Można powiedzieć, że proces jest niemy, bo tak naprawdę nie wskazuje dlaczego, skąd i w jakim celu nastąpiło połączenie.

kampania_1_450px

Moim zdaniem można byłoby ten proces bardzo łatwo usprawnić, co jak rozumiem nie jest w interesie wydzwaniającego. Pierwsza myśl, to automatyczne przywitanie (wysłany „Komunikat powitalny” na diagramie) z informacją, że proszę poczekać kilka minut. Gdybym dowiedział się kto dzwoni to pewnie i tak przerwałbym połączenie. Skutek więc ten sam. Jednak co zrobić, aby nie dzwonili po raz kolejny? Patrząc racjonalnie, ani nie jest to efektywne, ani przyjazne. Gdyby nawet udałoby się porozmawiać, to nie miałbym z nimi ochoty rozmawiać. Problem byłby taki, że nawet rozmowa i brak zainteresowania nie oznacza, że przestaną zdzwonić. Obecne rozwiązanie jest bardzo słabe.

Powyżej zasygnalizowany proces (przed zmianą) jest przykładem nieefektywanego procesu Można w nim zaobserwować różne objawy marnotrawstwa.

h1

Poza basenem, czyli proces współpracy

Styczeń 11, 2016

W poprzednim wpisie, skupiłem się na procesie odbywającym się w ramach danej jednostki, gdy to pracownik odbiera bilet od pasażera i samodzielnie przeprowadza proces przy użyciu narzędzia. Cofnijmy się jednak o krok a dokładnie 2 kroki wcześniej, zanim konduktor rozpoczął weryfikację biletu. Z racji, że miałem bilet internetowy, najpierw zostałem poproszony o bilet a następnie o dokument osoby wskazanej na bilecie do potwierdzenia tożsamości. Te 2 kroki są zaprezentowane na poniższym diagramie.

prosba_o_bilet_1_450px

Na powyższym diagramie, można zauważyć, że także są wykorzystane tzw. baseny jednakże nie jeden, a dwa. Każdy z nich obrazuje innego uczestnika procesu a komunikacja odbywa się za pomocą komunikatów i reakcji na nie. Jest to tzw. proces współpracy (ang. collaboration process). W tym procesie pojawiają się już zdarzenia początkowe (ang. start event) i zdarzenia końcowe (ang. end event) w każdym z basenów oraz można powiedzieć, że nie jest on “ciągły” w ramach jednego basenu. Proces wychodzi jakby poza dany basen i oczekuje reakcji z drugiego basenu na wysłany komunikat.

Przykłady dla procesu współpracy w innych sytuacjach znajdują się w moich poprzednich wpisach:

h1

Początki w modelowaniu procesów

Grudzień 13, 2015

Obserwujesz sytuację biznesową i chcesz zrozumieć jak działają jednostki organizacyjne firmy? A może sam jesteś częścią procesu i zastanawiasz się jak wygląda on w całości? Jeśli dotyczy on Ciebie, często intuicyjnie wiesz, jakie czynności i kiedy są potrzebne. Z drugiej strony jednak dobrze uświadomić sobie jak akcje innych wpływają na dostarczanie wartości. Tworząc diagram procesu napotykasz kilka trudności – zaczynając od określenia jego granic, przez zidentyfikowanie poszczególnych kroków, a na odpowiednim poziomie szczegółowości kończąc.

Myślę, że każdy użytkownik Internetu korzystał z mniej lub bardziej rozbudowanych funkcjonalności tzw. sklepu internetowego lub innego serwisu pozwalającego na zakup usługi lub produktu przez Internet. W takim mechanizmie mamy elementy takie jak: logowanie/rejestracja, wyszukanie produktu, dodanie do koszyka, złożenie i opłacenie zamówienia, wylogowanie, realizacja zamówienia. Pierwsza myśl to określenie, że wszystkie te czynności stanowią jeden proces. Podejście słuszne, ale…

Chcesz przeczytać więcej? Zapraszam do przeczytania mojego gościnnego wpisu w serwisie Analiza IT o początkach w modelowaniu procesów, skupiającym się na następujących aspektach:

  • Gdzie zaczyna i kończy się proces?
  • Jakie są kroki?
  • Jakie są wejścia i wyjścia procesu?
  • Jaki poziom szczegółowości?
  • Jakie narzędzia?
h1

Jak stosować zdarzenie error wewnątrz procesu?

Listopad 20, 2015

W pracy korzystam z narzędzia napisanego w VBA (ang. Visual Basic for Applications) do generowania wynikowego pliku tekstowego z arkusza kalkulacyjnego. Jednym z kroków jest odczytanie liczby rekordów i przypisanie jej do zmiennej pomocniczej.

Podczas tworzenia narzędzia założyłem zmienną jako Liczba Całkowita (typ Integer). Podczas próby wykonania nowego raportu pojawił się błąd „overflow”. Oznacza on, że nie można przepisać wartości większej niż dopuszcza to typ pola (na diagramie zdarzenie błąd wartości). Po poprawieniu (zmiana na Long) mechanizm zadziałał poprawnie.

Podany przykład można byłoby zobrazować następująco na diagramie:

error_ev_pl1_450px
Na powyższym diagramie jest zaprezentowane zastosowanie zdarzenia tzw. intermediate o charakterze błędu (ang. error event), co powoduje przerwanie wykonania algorytmu. Obrazuje to zdarzenie końcowe z krzyżykiem.  Tego typu zdarzenie błędu umieszczamy na brzegu czynności mogącej spowodować błąd (na diagramie Odczytaj liczbę wierszy) i  łączymy z czynnością obsługującą (na diagramie Wyświetl komunikat) lub z zdarzeniem końcowym procesu.

h1

Jak korzystać z bramek opartych o zdarzenia?

Listopad 14, 2015

Wielokrotnie byłem świadkiem w kolejce w sklepie, gdy pracownik sklepu w pewnym momencie przerywał kasowanie produktów, tzn. automatyczne odczytywanie kodów (czynność Odczytaj kod na diagramie) produktów i ich dodawanie do listy produktów. W tym momencie brał produkt i ręcznie przepisywał kolejne cyfry kodu kreskowego do odpowiedniego miejsca na ekranie kasy (czynność Przyjmij kod na diagramie). Pozwalało to na dodanie tak odszukanego kodu, a następnie produktu do listy produktów.

Produkt musi się znaleźć w określonym obszarze kasy (czynność Namierz produkt na diagramie), aby czujniki czytnika mogły zeskanować kod (czynność Odszukaj kod w zasięgu czytnika na diagramie). Czasami kod musi być dokładnie w pozycji równoległej do poziomu kasy, a czasami może być pod innym kątem.

nakasie450

Na powyższym diagramie (w BPMN) najpierw następuje rozgałęzienie za pomocą bramki (ang. gateway) a potem połączenie dwóch ścieżek w jedną przed akcją, która jest wspólna dla obydwu ścieżek. W tym miejscu także jest zastosowana bramka. Jest to jedna ze znanych dobrych praktyk w stosowaniu “bramek”, czyli rozgałęzienie i połączenie ścieżek jest zakończone bramką. Element zaznaczony na niebiesko.

Każde wyjście z bramki, opartej o zdarzenia (ang. event-based gateway), powinno być połączone ze zdarzeniem. Pozwala to jednoznaczenie wskazać w jakiej sytuacji następuje wyjście na daną ścieżkę, czyli jakie zdarzenie powoduje przejście tą ścieżką. Jest to druga ze znanych dobrych praktyk w stosowaniu bramek. Oznaczone na zielono na diagramie.

Istnieje więcej dobrych praktych w tym obszarze, jednakże już te dwa znacznie wpływają na poprawę czytelności diagramu. Dzięki nim wiemy, które ścieżki kiedy występują i w których momencie i na jakich warunkach następuje powrót z rozgałęzienia i przejście do dalszej części procesu.

O zdarzeniach pisałem już kilkakrotnie w różnym kontekście: