Archive for the ‘modelowanie’ Category

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.

 

Reklamy
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:

h1

Proces „oczami” metody 5W2H

Listopad 5, 2015

Na szkoleniach miękkich w różnych sytuacjach jest przytaczana metoda 5W2H, służąca do identyfikacji oraz analizy problemów. Metoda ta polega na zadaniu pytań: Kto? (ang. Who?), Co? (ang. What?), Gdzie? (ang. Where?), Kiedy? (ang. When?), Dlaczego? (ang. Why?) oraz Jak (ang. How?) i Ile? (ang. How much?). Metodę tę można także użyć do analizy procesu – poznania go, co jest pierwszym krokiem przed próbą jego poprawy.

Ponad rok temu opublikowałem na blogu wpis o marnotrawstwie w procesie. Proces z tego wpisu, dotyczący przygotowania raportu, jest idealnym przykładem do pokazania działania tej metody. Na diagramie przytoczono ten diagram z modyfikacjami –  uproszczenie oraz oznaczenie kroków, które pozwalają na odpowiedź na niektóre z tych pytań.

5w2h_450

Odpowiedzi na te pytania są następujące:

  • Kto? Z kroków procesu można wywnioskować, że osoba odpowiedzialna za przygotowywanie raportów.
  • Co? Efektem procesu jest przygotowanie raportu w postaci pliku i wydruku. Krok z efektem został zaznaczony na diagramie na czerwono.
  • Gdzie? Proces nie odpowiada na to pytanie. Proces mógłby się odbywać w dowolnym podmiocie.
  • Kiedy? Proces realizowany jest pojawieniu się danych źródłowych. Można założyć, że dane źródłowe są generowane cyklicznie. Krok został zaznaczony na zielono na diagramie.
  • Dlaczego? Raport jest przygotowywany w procesie dla jego odbiorcy. Jest przekazywany po przygotowaniu. Może być używany do podejmowania decyzji.
  • Jak? Raport jest tworzony ręcznie przez pracownika. Później generuje i drukuje plik PDF. Kluczowy krok zaznaczony jest na niebiesko.
  • Ile? Proces realizowany w ten sposób jest pracochłonny. Wykonywane są ręcznie kolejne czynności. W tym czasie pracownik mógłby wykonać inne zadania, więc ponoszony jest pewien koszt. Pewne czynności wydają się nieuzasadnione (analiza we wskazanym wcześniej wpisie).

Spoglądając na proces z takiej perspektywy, możemy także określić elementy, których tak naprawdę nie wiemy o procesie lub tylko przypuszczamy, że jest on realizowany w określony sposób. W powyższych odpowiedziach, w niektórych punktach używałem stwierdzenia, że “można założyć” lub “wywnioskować”. Dodając do procesu:

  • informację o częstotliwości (zmieniając zdarzenie inicjujące z “pustego” na czasowe) lub
  • użytkowniku (umieszczając proces w prostokącie z nazwą roli) lub
  • odbiorcy raportu (poprzez umieszczenie akceptującego raport)

można usprawnić poszukiwanie odpowiedzi na powyższe pytania. Takie działania powodują, że diagram procesu jest lepiej udokumentowany i łatwiej nim zarządzać. Elementy zostały zasygnalizowane na diagramie linią przerywaną.