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. Ten wpis ma na celu ukazanie podstawowych problemów w tym obszarze.
Na początek wybierzmy przykładową sytuację, do której będę dalej się odnosić. 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…
Gdzie zaczyna i kończy się proces?
Wskazany proces jest dość szeroki, wymaga interakcji użytkownika na różnym etapie. Chcąc opisać ten proces, potrzebne jest określenie jego granic. Wszystko zależy od celu prezentacji. Czy chcemy przedstawić sam proces złożenia zamówienia, który realizowany jest z jednej perspektywy, np. sklepu? Czy może chcemy pokazać cały proces od rejestracji do dostarczenia zamówienia? W podanym przykładzie mamy tak naprawdę kilka procesów:
- Proces rejestracji użytkownika
- Proces logowania
- Proces wyboru produktu
- Proces złożenia zamówienia
- Proces realizacji zamówienia
Każdy z tych procesów może wystąpić w innym momencie. Dlatego łatwiej jest je zaprezentować osobno jak odrębne elementy działań użytkownika. Dają one użytkownikowi inną wartość dodaną. Rejestracja użytkownika może nigdy nie skończyć się zamówieniem, może być tylko potrzebna do otrzymywania aktualnych informacji. Wybór produktu do koszyka może nie skończyć się zamówieniem, a jedynie dodaniem go do poczekalni albo zarezerwowania produktu. Określając granice procesu istotne jest także zwrócenie uwagi na to, co chcemy wyrazić w danych procesie – czy chcemy jedynie pokazać jego przebieg, wzbudzić dyskusję, czy może pokazać jego wejścia i wyjścia (więcej poniżej) czy może zająć się już każdym szczegółem (więcej poniżej).
Na poniższym diagramie mamy jeden z wybranych procesów – Proces realizacji zamówienia.
Jakie są kroki?
Na powyższym diagramie dla procesu “Realizacja zamówienia” wskazałem jakie mogłyby być potencjalne kroki tego procesu. Podczas próby prezentacji diagramu musisz zidentyfikować
kolejne kroki procesu i nazwać je tak, aby jednoznacznie wskazywały jaka czynność jest wykonywana. Kroki procesu powinny określać co robimy – czynności. Dobrą praktyką jest również wskazywanie co jest przedmiotem tego działania (np. produkt, raport, itd.). Najlepsze praktyki w tym obszarze mówią o wielu elementach. Podstawowe zasady, które zastosowałem na powyższym diagramie, opisałem na swoim blogu we wpisie “Nazwy kroków procesu” (https://modelowanie.wordpress.com/2013/01/17/nazwy-krokow-procesu/). Jak widać na powyższym diagramie zostały zidentyfikowane dość “grube”, ogólne kroki. Liczba kroków oraz ich rozbicie na poszczególne czynności wynika z oczekiwanej szczegółowości diagramu procesu (więcej poniżej).
Jakie są wejścia i wyjścia procesu?
Identyfikując kolejne kroki procesu, a w szczególności pierwszy i ostatni krok, możemy się zastanowić co jest wejściem do procesu, a co jest jego wyjściem. Trzymając się podejścia SIPOC (https://modelowanie.wordpress.com/2011/06/04/sipoc-na-bazie-diagramu-bpmn/) określamy co daje nam (ang. Input) dostawca (ang. Suplier) procesu, a co otrzymuje(ang. Output) odbiorca (ang. Client) procesu (ang. Process). Takie podejście pozwala określić jaki jest rzeczywisty efekt działania procesu. Wracając do procesu globalnego – wyjścia z danego jego etapu jest wejściem do kolejnego etapu procesu. Istotne jest, że wyjście w postaci “Koszyk produktów” może być wejściem dla dwóch różnych procesów – realizacji zamówienia oraz umieszczenia produktów w poczekalni. Na poniższym diagramie zostało to zasygnalizowane.
Jaki poziom szczegółowości?
Jak widać dodając kolejne elementy, analizując kroki procesu, jego diagram staje się coraz bardziej szczegółowy. Przygotowując diagram procesu należy się zastanowić jaki poziom szczegółowości procesu jest potrzebny lub oczekiwany. Czy mają być pokazane tylko główne kroki procesu, jak powyżej, czy chcesz przedstawić większe szczegóły? Wyzwaniem jest zachowanie
poziomu szczegółowości na podobnym poziomie przez cały proces w ramach diagramu. Można pokazać detale pierwszych kroków, a potem tylko wybrane fakty. Takie podejście jednak może spowodować zamieszanie u odbiorców diagramu. Jeśli znasz więcej szczegółów, możesz udokumentować je w komentarzu do diagramu lub na samym diagramie wykorzystując dedykowane obiekty. Umieszczenie na diagramie większych szczegółów może wiązać się między innymi z:
- wskazaniem rodzaju wykonywanej czynności (ręczna, użytkownika)
- rozbiciem kroków na bardziej szczegółowe
- dodaniem obiektów, które używane w procesie (np. wejścia i wyjścia z kroków)
- umieszczeniem kroków automatycznych, odwołań do bazy danych lub innego źródła danych
Poniższy diagram prezentuje taki szczegółowy proces.
Jakie narzędzia?
Powyższe diagramy zostały przygotowane w środowisku Eclipse (https://www.eclipse.org/bpmn2-modeler/) z wtyczkami do modelowania procesów na bazie notacji BPMN (https://modelowanie.wordpress.com/2007/07/22/troche-o-notacji-bpmn/). Dostępnych jest wiele narzędzi, komercyjnych oraz darmowych. Często używanymi narzędziami do modelowania (m.in. BPMN) są Visual Paradigm czy Enterprise Architect. Wystarczy poszukać narzędzia w jednej z wyszukiwarek (np. narzędzie do modelowania procesów, narzędzie do modelowania w BPMN, ang. process modeling tool) i sprawdzić czy odpowiada naszym potrzebom. Część narzędzi pozwala na wykorzystanie pełnego zakresu notacji do modelowania procesów biznesowych. Inne z kolei, pozwalają na stworzenie uproszczonych diagramów procesów, które także mogą zrealizować postawiony przed nimi cel.
Podsumowanie
Modelowanie procesów biznesowych wymaga zmiany podejścia do obserwowanych sytuacji biznesowych lub wykorzystywanych narzędzi. Myślenie w kategoriach procesu, który chciabyś przedstawić na diagramie, wymaga przede wszystkim określenia celu diagramu. Od niego zależy jaki poziom szczegółowości jest potrzebny, na jakich elementach się skupić a także jakie narzędzia wykorzystać. Najlepiej jest tworzyć różne diagramy i zapoznawać się z najlepszymi praktykami/wzorcami w zakresie modelowania procesów (ang. process modelling best practiceses, https://www.google.pl/?gws_rd=ssl#q=process+modelling+best+practices). W Internecie można także znaleźć wiele przykładowych diagramów procesów, które obrazują różne podejście, wykorzystywane narzędzia i różny stopień szczegółowości.
Autor wpisu
Łukasz Mozalewski – pracuje jako analityk biznesowy, skupiając się na zbieraniu i opisywaniu wymagań, również tych dotyczących zmiany procesów biznesowych. Jest autorem bloga o modelowaniu procesów biznesowych (http://modelowanie.net).
0 komentarze “Początki w modelowaniu procesów”
Warto śledzić zachowania poszczególnych użytkowników na naszej stronie – w jakim momencie opuszczają naszą witrynę, przez jakie zakładki „się przeklikowują” kolejno, ile czasu spędzają na danej podstronie, jaki jest schemat pojedynczej wizyty – na tej podstawie można modyfikować strukturę naszego serwisu, co niewątpliwe przełoży się na lepszą konwersję i więcej leadów.
Chyba Enterprise Architect jest jednym z popularniejszych narzędzi. Czy są tu jednak osoby korzystające z Visual Paradigm? Poszukuję opinii od użytkowników na temat tego narzędzia. Wiem że EA jest lepszy dla UML. A jak jest z poprawnością modelowania dla BPMN w Paradigm?
Jak robię ankiety wśród analityków, to wychodzi, że EA w Polsce używa(ło) ok. 2/3 analityków, a VP ok. 1/4. EA jest o wiele tańszy, stąd na pewno większe zainteresowanie. Oba są ogromnymi kombajnami – mają ogromne możliwości i pewnie na początku używa się z 5% funkcji. Na tym poziomie pewnie nie widać wielkiej różnicy. Różnią się nieco interfejsem, dostępnymi typami diagramów i dodatkowymi funkcjami. Co do UML, to skąd opinia, że EA jest lepszy dla UML? Widzę, że EA daje większe możliwości mieszania elementów UML na jednym diagramie i dodaje swoje Customs diagrams. Ja akurat wolę tu podejście VP bardziej zgodne ze specyfikacją UML. Tak naprawdę, jeśli robi się podstawowe diagramy UML i BPMN to nie widać większej różnicy. Ja używam obu. EA w pracy, a jak coś w domu robię to raczej VP. Jak ktoś ma iOS, to EA wymaga programu, który będzie symulował działanie na Windowsie (crossover). Da się w tym pracować, ale bardzo nie przepadam za tym i jak tylko mogę to idę na VP.
Podsumowując – co Ci jest potrzebne? Jeśli robienie podstawowych diagramów UML i BPMN na jedno stanowisko, pracujesz na Windowsie, to weź EA, jest tańszy. Nie zobaczysz dużych różnic. Jeśli masz bardziej wyrafinowane potrzeby, to warto zajrzeć na strony obu narzędzi i porównać opcje w poszczególnych pakietach.