BPMN w praktyce – jak modelować procesy biznesowe?

BPMN to standard graficznego modelowania procesów biznesowych, który pozwala jednoznacznie pokazać działania, decyzje, uczestników, komunikację i alternatywne ścieżki procesu. Jego wartość zaczyna się tam, gdzie zwykły schemat blokowy przestaje wystarczać.

Dobrze przygotowany diagram BPMN powinien pozwolić osobie biznesowej zrozumieć przebieg procesu, analitykowi znaleźć niejasności, a zespołowi technicznemu określić, gdzie potrzebny jest workflow, integracja, automatyzacja lub decyzja człowieka.

Nie trzeba jednak poznawać całej specyfikacji, aby tworzyć użyteczne modele. Oficjalnym standardem OMG pozostaje obecnie BPMN 2.0.2, a sama specyfikacja obejmuje znacznie więcej elementów, niż potrzeba do opisania większości procesów biznesowych.

W praktyce warto zacząć od kilkunastu konstrukcji używanych regularnie i rozszerzać model dopiero wtedy, gdy proces rzeczywiście tego wymaga.

Do czego służy BPMN?

BPMN, czyli Business Process Model and Notation, służy do przedstawiania logiki procesów za pomocą ustandaryzowanych symboli.

Zamiast opisywać procedurę:

pracownik składa wniosek, manager go weryfikuje, a następnie – zależnie od wartości – przekazuje do finansów albo bezpośrednio zatwierdza,

możemy pokazać:

Start → Złóż wniosek → Zweryfikuj wniosek → decyzja dotycząca wartości → odpowiednia ścieżka akceptacji → Koniec

Diagram pokazuje nie tylko kolejność, ale również logikę sterującą procesem.

OMG stworzyło BPMN między innymi po to, aby zapewnić standard zrozumiały dla osób biznesowych, a jednocześnie wystarczająco precyzyjny dla użytkowników technicznych zajmujących się implementacją procesów.

Dlatego BPMN jest stosowany w:

• analizie biznesowej,
• dokumentowaniu procesów,
• projektowaniu procesów AS-IS i TO-BE,
• wdrożeniach ERP i CRM,
• projektowaniu workflow,
• automatyzacji procesów,
• analizie wymagań,
• projektowaniu procesów wykonywanych przez silniki workflow.

Nie oznacza to, że każdy diagram BPMN musi później zostać uruchomiony w silniku procesowym. BPMN może służyć wyłącznie jako model analityczny.

BPMN a mapowanie procesów – gdzie przebiega granica?

To istotne przy architekturze naszego klastra.

Mapowanie procesów biznesowych odpowiada przede wszystkim na pytanie:

Jak działa obecny proces i co powinniśmy w nim zmienić?

BPMN odpowiada:

Jak tę wiedzę zapisać w jednoznacznym modelu?

Dlatego nie zaczynaj projektu optymalizacyjnego od wybierania symboli BPMN.

Najpierw trzeba ustalić:

• początek i koniec procesu,
• uczestników,
• rzeczywiste działania,
• problemy,
• decyzje,
• wyjątki.

Dopiero później warto przekładać tę wiedzę na formalniejszy model.

Aktualne polskie programy szkoleniowe również wyraźnie rozdzielają identyfikację procesów, cel modelowania i pracę z interesariuszami od późniejszego wykorzystania konkretnych elementów BPMN.

Podstawowe elementy BPMN, które trzeba znać

Na początku wystarczy opanować kilka grup elementów:

Element	Do czego służy?
Zdarzenie	Pokazuje, że coś uruchamia, zmienia lub kończy proces
Zadanie	Reprezentuje wykonywaną pracę
Podproces	Grupuje bardziej złożony fragment procesu
Bramka	Steruje rozgałęzianiem i łączeniem ścieżek
Sequence Flow	Pokazuje kolejność działań
Pool	Reprezentuje uczestnika procesu
Lane	Pokazuje role lub odpowiedzialności wewnątrz uczestnika
Message Flow	Pokazuje komunikację między uczestnikami
Data Object	Pokazuje dane wykorzystywane lub tworzone w procesie
Adnotacja	Dodaje wyjaśnienie bez zmiany logiki procesu

Microsoft grupuje podstawowe elementy BPMN podobnie: czynności, zdarzenia i bramki tworzą logikę procesu, a dodatkowe typy połączeń i obiekty pozwalają opisywać komunikację oraz kontekst.

Nie trzeba umieszczać wszystkiego na każdym diagramie.

Dobry model używa najmniejszego zestawu symboli potrzebnego do jednoznacznego opisania procesu.

Zdarzenia – co uruchamia i kończy proces?

Zdarzenie w BPMN przedstawia się jako okrąg.

Najważniejsze są trzy rodzaje:

• Start Event – początek,
• Intermediate Event – coś dzieje się podczas procesu,
• End Event – zakończenie.

Start Event

Najprostszy proces może zaczynać się od zwykłego zdarzenia:

Start → Przygotuj raport → Wyślij raport → Koniec

Jednak czasami ważne jest określenie, co dokładnie uruchamia proces.

Może to być:

• otrzymanie wiadomości,
• określony czas,
• wystąpienie warunku,
• sygnał.

Przykład:

Otrzymano zamówienie → Zweryfikuj zamówienie

jest bardziej informacyjny niż abstrakcyjne:

Start → Zweryfikuj zamówienie

jeżeli źródło procesu ma znaczenie.

Intermediate Event – kiedy proces na coś czeka

Zdarzenia pośrednie przydają się, gdy w trakcie realizacji procesu wydarzy się coś istotnego.

Przykład:

Wyślij prośbę o dokumenty → oczekuj na dokumenty → Zweryfikuj dokumenty

Możemy pokazać zdarzenie wiadomości reprezentujące otrzymanie danych.

Inny przykład:

Wyślij przypomnienie → czekaj 3 dni → ponów kontakt

Tutaj przydatny jest timer.

Zdarzenia są szczególnie ważne przy modelowaniu workflow i automatyzacji, ponieważ pozwalają odróżnić:

wykonaj działanie

od:

zaczekaj, aż wydarzy się określona sytuacja.

Specyfikacja BPMN definiuje m.in. zdarzenia związane z wiadomością, czasem, błędem, warunkiem, sygnałem czy eskalacją.

Nie trzeba jednak poznawać wszystkich wariantów na pierwszym diagramie.

Zadania – nazywaj działania, a nie obszary

Zadanie reprezentuje konkretną pracę.

Dobra nazwa:

Zweryfikuj dane klienta

Słaba:

Dane klienta

Dobra:

Zatwierdź płatność

Słaba:

Akceptacja

Model procesu opisuje działanie, dlatego najczytelniejszy format to zazwyczaj:

czasownik + przedmiot działania

na przykład:

• Utwórz zamówienie,
• Sprawdź dostępność,
• Wyślij ofertę,
• Zarejestruj reklamację,
• Zatwierdź fakturę.

Takie nazewnictwo bardzo ułatwia późniejszą rozmowę o automatyzacji.

Od razu możemy zapytać:

kto wykonuje tę czynność i czy nadal powinien ją wykonywać człowiek?

Nie zamieniaj każdego kliknięcia w zadanie BPMN

To częsty problem.

Proces:

1. Otwórz CRM.
2. Kliknij Klienci.
3. Wpisz numer.
4. Kliknij Szukaj.
5. Otwórz klienta.
6. Kliknij Edytuj.
7. Zmień status.
8. Kliknij Zapisz.

nie musi być opisany jako osiem zadań BPMN.

Na poziomie procesu biznesowego prawdopodobnie wystarczy:

Zaktualizuj status klienta

Szczegóły obsługi interfejsu można opisać:

• instrukcją,
• task miningiem,
• dokumentacją systemową,
• oddzielnym modelem niższego poziomu.

Poziom szczegółowości powinien wynikać z celu diagramu.

Podproces – kiedy diagram zaczyna być za duży

Jeżeli jedna czynność składa się z kilku istotnych kroków, nie trzeba umieszczać wszystkiego na głównym diagramie.

Można użyć podprocesu.

Na poziomie głównym:

Przeprowadź weryfikację klienta

Na niższym:

1. Pobierz dane.
2. Zweryfikuj dokumenty.
3. Sprawdź listę sankcyjną.
4. Oceń wynik.

To pozwala zachować czytelność.

Aktualne programy szkoleń BPMN traktują dekompozycję na podprocesy jako ważną część pracy z bardziej rozbudowanymi modelami.

Praktyczna zasada:

jeżeli odbiorca głównego diagramu nie potrzebuje widzieć wszystkich kroków, ukryj je w podprocesie.

Bramki BPMN – tutaj powstaje najwięcej błędów

Bramka nie oznacza po prostu decyzji.

Steruje sposobem, w jaki przepływ:

• rozdziela się,
• łączy,
• czeka na określone zdarzenie.

Najczęściej potrzebujesz czterech rodzajów.

Bramka XOR – wybieramy jedną ścieżkę

Exclusive Gateway, czyli XOR, oznacza wybór jednej z alternatyw.

Przykład:

Czy wniosek jest kompletny?

Tak → Przekaż do akceptacji.

Nie → Poproś o uzupełnienie.

Warunki powinny być opisane przy wychodzących przepływach:

kompletny

niekompletny

Dzięki temu odbiorca nie musi domyślać się znaczenia poszczególnych strzałek.

XOR jest prawdopodobnie najczęściej potrzebną bramką w zwykłych procesach biznesowych.

Bramka AND – uruchamiamy kilka ścieżek

Parallel Gateway, czyli AND, wykorzystujemy, gdy kilka działań ma zostać uruchomionych niezależnie.

Onboarding pracownika:

Podpisano umowę

następnie równolegle:

• Przygotuj laptop,
• Utwórz konto,
• Zamów kartę dostępu.

Nie muszą zostać wykonane dokładnie w tym samym momencie.

Istotne jest, że wszystkie ścieżki mają zostać zrealizowane, a nie wybrana jedna.

Przy ponownym połączeniu bramka równoległa może synchronizować te ścieżki przed przejściem dalej.

Bramka OR – jedna lub kilka ścieżek

Inclusive Gateway jest potrzebna, jeśli na podstawie warunków może zostać uruchomiona:

• jedna ścieżka,
• kilka ścieżek,
• potencjalnie wszystkie.

Przykład zamówienia:

jeżeli klient wybrał:

• konfigurację dodatkową → uruchom konfigurację,
• szkolenie → przygotuj szkolenie,
• migrację danych → uruchom migrację.

Klient może wybrać jedną, dwie albo wszystkie usługi.

To różni OR od:

XOR → dokładnie jedna

oraz:

AND → wszystkie

Rozróżnienie XOR, AND i OR jest standardowym elementem praktycznej nauki BPMN i pojawia się również w aktualnych polskich materiałach szkoleniowych.

Bramka event-based – nie wiemy, co wydarzy się pierwsze

To bardzo użyteczna, choć nieco bardziej zaawansowana konstrukcja.

Załóżmy, że firma wysyła klientowi propozycję.

Następnie może nastąpić:

klient odpowiada

albo:

mija termin 7 dni

Nie wybieramy ścieżki na podstawie wartości zapisanej w systemie.

Czekamy, które zdarzenie wystąpi pierwsze.

Wtedy pasuje event-based gateway.

IBM opisuje ją właśnie jako punkt, w którym dalsza ścieżka jest wybierana zależnie od tego, które oczekiwane zdarzenie nastąpi.

Pool i Lane – kto wykonuje proces?

BPMN pozwala rozdzielić:

uczestników procesu

od:

ról wewnątrz uczestnika.

Pool

Pool reprezentuje uczestnika współpracy.

Przykładowo:

Klient

i osobny:

Firma

Mogą to być dwie niezależne organizacje lub strony procesu.

Specyfikacja BPMN określa Pool jako reprezentację Participant w Collaboration.

Lane

Lane dzieli proces wewnątrz puli według odpowiedzialności.

W puli Firma możemy mieć:

• Sprzedaż,
• Finanse,
• Magazyn.

Dzięki temu widzimy, kto odpowiada za poszczególne działania.

Nie używaj pool i lane zamiennie

To jeden z klasycznych błędów.

Załóżmy:

Klient jest niezależnym uczestnikiem.

Firma jest drugim uczestnikiem.

Wewnątrz firmy działają:

• Sprzedaż,
• Finanse.

Logiczny układ:

Pool: Klient

Pool: Firma

• Lane: Sprzedaż
• Lane: Finanse

Nie należy automatycznie tworzyć oddzielnego poola dla każdego działu tylko dlatego, że organizacja posiada kilka jednostek.

Sequence Flow i Message Flow – bardzo ważne rozróżnienie

Na diagramie występują różne typy połączeń.

Sequence Flow

Pokazuje kolejność wykonywania czynności w procesie.

Na przykład:

Zweryfikuj klienta → Przygotuj ofertę

Sequence Flow może przechodzić między torami znajdującymi się w tej samej puli.

Message Flow

Pokazuje komunikację między niezależnymi uczestnikami.

Na przykład:

Klient → przesyła zamówienie → Firma

Message Flow może łączyć różne pule.

Nie wolno używać go do połączenia zadań znajdujących się wewnątrz tej samej puli. Specyfikacja BPMN mówi wprost, że Message Flow łączy odrębnych uczestników i nie może łączyć dwóch obiektów w jednym Pool.

Microsoft również rozróżnia w narzędziach BPMN przepływ sekwencji, przepływ komunikatów oraz skojarzenia jako osobne typy łączników.

To jedna z zasad, którą warto zapamiętać od początku.

Jak narysować pierwszy proces BPMN krok po kroku?

Zamiast zaczynać od nauki kilkudziesięciu symboli, przejdźmy przez prosty proces.

Przykład:

obsługa wniosku zakupowego.

Krok 1. Ustal początek i koniec

Początek:

Pracownik zgłasza potrzebę zakupu

Koniec:

Zamówienie zostało przekazane do realizacji

albo:

Wniosek został odrzucony

Już tutaj mogą wystąpić dwa możliwe zakończenia.

Krok 2. Wskaż uczestników

W procesie biorą udział:

• Pracownik,
• Manager,
• Dział zakupów.

Jeżeli wszyscy znajdują się w jednej organizacji i modelujemy jej wewnętrzny proces, możemy wykorzystać jedną pulę z trzema torami.

Krok 3. Dodaj główne działania

W pierwszej wersji:

Złóż wniosek → Sprawdź wniosek → Podejmij decyzję → Utwórz zamówienie

Nie dodawaj jeszcze każdego możliwego wyjątku.

Najpierw ustal podstawowy flow.

Krok 4. Dodaj decyzję

Po sprawdzeniu wniosku:

Czy zakup został zaakceptowany?

XOR.

Tak:

Utwórz zamówienie

Nie:

Poinformuj o odrzuceniu

Krok 5. Dodaj dodatkową regułę biznesową

Załóżmy, że wydatki powyżej określonego limitu wymagają dodatkowej akceptacji finansowej.

Po akceptacji managera:

Czy kwota przekracza limit?

Tak → Uzyskaj akceptację finansową

Nie → Utwórz zamówienie

Ponownie pasuje XOR.

Krok 6. Dodaj odpowiedzialności

Przenosimy zadania do odpowiednich torów:

Pracownik
Złóż wniosek.

Manager
Zweryfikuj i zatwierdź.

Finanse
Zatwierdź wydatek wymagający kontroli.

Zakupy
Utwórz zamówienie.

Już teraz diagram staje się narzędziem analizy.

Możemy zobaczyć liczbę przekazań między rolami.

Krok 7. Dodaj wyjątek

Co jeżeli dane są niekompletne?

Po weryfikacji:

Czy wniosek jest kompletny?

Nie → Poproś o uzupełnienie → Uzupełnij wniosek → ponowna weryfikacja

Powstaje pętla.

To dużo bardziej realistyczny proces niż model opisujący wyłącznie idealną ścieżkę.

Krok 8. Sprawdź, czy diagram nadal jest czytelny

Po dodaniu wyjątku może się okazać, że model zaczyna rosnąć.

Nie oznacza to, że trzeba dodać wszystkie możliwe przypadki.

Trzeba ustalić:

które warianty są istotne dla celu diagramu?

Jeżeli pojedynczy wyjątek zdarza się raz na kilka lat i ma oddzielną procedurę, być może nie musi znajdować się na głównym modelu.

Jak modelować AS-IS w BPMN?

Model AS-IS powinien pokazywać obecny sposób działania, również jeśli jest nieefektywny.

Załóżmy:

1. klient wysyła formularz,
2. sprzedaż kopiuje dane do Excela,
3. manager wybiera handlowca,
4. pracownik tworzy rekord w CRM,
5. CRM generuje zadanie.

Nie poprawiaj procesu podczas rysowania.

Model:

Odbierz formularz → Wpisz dane do arkusza → Przypisz handlowca → Utwórz kontakt w CRM

może wyglądać źle.

I właśnie dlatego jest użyteczny.

BPMN jest wykorzystywany w praktyce zarówno do modelowania AS-IS, jak i TO-BE, także w aktualnych programach kształcenia analityków biznesowych.

Jak modelować TO-BE?

Dopiero po analizie AS-IS projektujemy nowy proces.

Załóżmy, że:

• Excel jest zbędny,
• routing można wykonywać według jasnych reguł,
• CRM ma API.

TO-BE:

Otrzymano formularz → Zweryfikuj dane → Automatycznie utwórz lead w CRM → Automatycznie przypisz właściciela → Powiadom handlowca

Model pokazuje wtedy również zmianę odpowiedzialności.

Czynności wykonywane wcześniej przez człowieka mogą stać się działaniami systemu.

BPMN przed automatyzacją

Tutaj wartość notacji jest szczególnie duża.

Dobry model TO-BE może pomóc oddzielić:

User Task – działanie człowieka,

Service Task – działanie wykonywane przez usługę lub system,

Business Rule Task – zastosowanie reguły,

Send/Receive Task – komunikację,

Timer Event – oczekiwanie czasowe,

Message Event – oczekiwanie na informację.

Nie trzeba stosować wszystkich tych typów podczas pierwszej analizy biznesowej.

Stają się ważniejsze wtedy, gdy model ma zostać wykorzystany do projektowania rzeczywistego workflow.

Camunda zwraca uwagę właśnie na możliwość wykorzystania BPMN nie tylko do komunikacji biznesowej, ale również jako podstawy workflow automation i połączenia perspektywy biznesu, developmentu oraz operacji.

Diagram analityczny a proces wykonywalny przez silnik

To rozróżnienie warto wyjaśnić.

Model analityczny ma przede wszystkim przekazać ludziom wiedzę.

Model wykonywalny musi być wystarczająco precyzyjny, aby silnik procesowy wiedział:

• jakie zadanie uruchomić,
• na jakie zdarzenie czekać,
• którą integrację wywołać,
• jak obsłużyć błąd,
• jakie dane przekazać,
• kiedy zakończyć proces.

Nie każdy poprawny diagram biznesowy jest od razu gotowym procesem wykonywalnym.

Jeśli celem jest tylko analiza i dokumentacja, nie warto sztucznie zwiększać technicznej szczegółowości.

Dane w BPMN – kiedy je pokazywać?

BPMN umożliwia przedstawianie obiektów danych.

Może to być przydatne, jeśli ważne jest pokazanie:

jakie informacje są potrzebne do wykonania działania

albo:

co powstaje w jego wyniku.

Przykład:

Zweryfikuj wniosek

korzysta z:

Wniosek zakupowy

i tworzy:

Decyzję

Nie należy jednak przedstawiać każdego pola formularza.

Diagram procesu nie jest modelem bazy danych.

Jeżeli szczegóły danych wymagają osobnej analizy, warto użyć dodatkowej dokumentacji.

Jakich symboli nie trzeba używać od początku?

BPMN posiada wiele bardziej zaawansowanych konstrukcji.

Między innymi:

• zdarzenia błędów,
• kompensacje,
• sygnały,
• eskalacje,
• transakcje,
• zdarzenia graniczne,
• wielokrotne instancje,
• call activity,
• event subprocess,
• choreografie.

Ich znajomość jest wartościowa dla zaawansowanych modeli.

Ale uczenie się wszystkiego naraz prowadzi często do sytuacji, w której początkujący analityk bardziej zastanawia się nad symbolem niż nad procesem.

Na pierwszy etap wystarczą:

Start → Task → XOR/AND → Pool/Lane → End

plus message flow, jeśli mamy kilku uczestników.

To wystarcza do stworzenia wielu naprawdę użytecznych modeli.

Najczęstsze błędy podczas modelowania BPMN

Brak jasnego celu diagramu

Ten sam proces można modelować dla:

• managera,
• audytora,
• analityka,
• developera.

Każdy potrzebuje innego poziomu szczegółu.

Najpierw określ odbiorcę.

Próba pokazania wszystkiego

Duży diagram nie jest automatycznie bardziej precyzyjny.

Może być po prostu nieczytelny.

Niepoprawne użycie Message Flow

Komunikaty służą do komunikacji pomiędzy uczestnikami reprezentowanymi przez różne pule.

Nie do połączenia sprzedaży z finansami w obrębie jednego procesu.

Brak warunków przy XOR

Bramka rozdziela proces, ale strzałki nie wyjaśniają dlaczego.

Odbiorca musi zgadywać.

Nadużywanie bramek

Nie każda zmiana toru wymaga bramki.

Jeżeli po prostu:

Sprzedaż przygotowuje ofertę → Manager ją zatwierdza

wystarczy Sequence Flow przechodzący między lanes.

Bramki bez logiki

Romb nie jest dekoracją oznaczającą, że coś jest skomplikowane.

Powinien mieć konkretne znaczenie sterujące przepływem.

Modelowanie tylko happy path

Proces wygląda pięknie do momentu pierwszego:

• braku danych,
• odrzucenia,
• timeoutu,
• błędu.

Najważniejsze wyjątki powinny być widoczne.

Zbyt szczegółowe odwzorowywanie systemu

BPMN opisujący każde kliknięcie szybko staje się instrukcją obsługi zamiast modelem procesu.

Brak odpowiedzialności

Diagram samych zadań bez pools i lanes może nie pokazywać jednego z największych problemów procesu: ciągłego przekazywania pracy.

Dobra praktyka: modeluj od lewej do prawej

BPMN technicznie nie wymusza orientacji procesu.

Praktycznie najbardziej czytelny jest zazwyczaj przepływ:

lewa → prawa

Unikaj:

• prowadzenia strzałek w każdą stronę,
• długich powrotów przecinających cały diagram,
• nadmiernego krzyżowania przepływów.

Jeżeli model wygląda jak schemat instalacji elektrycznej, warto zastanowić się nad:

• podprocesami,
• zmianą układu,
• rozdzieleniem poziomów.

Czytelność jest częścią jakości diagramu.

Dobra praktyka: jeden diagram – jeden poziom abstrakcji

Nie łącz na jednym poziomie:

Obsłuż zamówienie

z:

Kliknij przycisk Zapisz.

Pierwsze jest dużym etapem procesu.

Drugie szczegółem interfejsu.

Jeżeli potrzebujesz obu informacji, zastosuj dekompozycję.

Na poziomie 1:

Obsłuż zamówienie

Na poziomie 2:

szczegółowy proces obsługi.

To pozwala stworzyć hierarchię modeli zamiast jednego gigantycznego diagramu.

Dobra praktyka: pokaż proces osobie, która go wykonuje

Model może być formalnie poprawny i jednocześnie niezgodny z rzeczywistością.

Po przygotowaniu AS-IS poproś osoby operacyjne:

Przejdźmy przez ostatni rzeczywisty przypadek. Czy faktycznie przeszedł przez te kroki?

Jeżeli nie, popraw model.

Można później dodatkowo wykorzystać process mining do ilościowej weryfikacji przebiegów na podstawie logów systemowych.

Kiedy BPMN może być zbyt rozbudowanym rozwiązaniem?

Nie każdy proces wymaga tej notacji.

Jeżeli chcesz jedynie pokazać:

Nowy → W trakcie → Zakończony

tablica Kanban wystarczy.

Jeżeli proces składa się z trzech kroków wykonywanych przez jedną osobę, prosty flowchart może być bardziej praktyczny.

BPMN zaczyna szczególnie pomagać, gdy pojawiają się:

• decyzje,
• równoległe działania,
• wiele ról,
• komunikacja z zewnętrznymi uczestnikami,
• wyjątki,
• zdarzenia,
• potrzeba późniejszej automatyzacji.

Nie używaj BPMN dlatego, że potrafisz. Używaj go wtedy, gdy jego jednoznaczność usuwa problem, którego prostszy model nie rozwiązuje.

Jakich narzędzi używać do BPMN?

Narzędzie jest sprawą drugorzędną.

Do modelowania BPMN wykorzystywane są m.in.:

• Microsoft Visio,
• Bizagi Modeler,
• Camunda Modeler,
• ADONIS,
• Enterprise Architect,
• Signavio,
• narzędzia BPM/workflow posiadające własne edytory.

Microsoft Visio posiada wzorniki odpowiadające BPMN 2.0, w tym podstawowe kształty oraz różne typy połączeń.

Aktualne szkolenia BPMN wykorzystują również m.in. Bizagi Modeler, Enterprise Architect czy ADONIS.

Nie wybierałbym jednak rozwiązania tylko według liczby dostępnych symboli.

Sprawdź:

• czy diagram można wygodnie współdzielić,
• czy narzędzie waliduje BPMN,
• czy potrzebujesz współpracy online,
• czy diagram ma później przejść do automatyzacji,
• czy potrzebujesz eksportu BPMN XML,
• kto będzie utrzymywał modele.

Do prostego modelowania analitycznego wymagania są inne niż do projektowania procesów wykonywanych przez silnik.

Jak zweryfikować gotowy diagram BPMN?

Zamiast od razu sprawdzać każdą stronę specyfikacji, wykonaj praktyczny test.

Czy wiadomo, co uruchamia proces?

Jeżeli nie – doprecyzuj Start Event.

Czy wiadomo, jaki rezultat go kończy?

Jeżeli nie – popraw zakończenie.

Czy każde zadanie opisuje działanie?

Powinno być jasne, co się dzieje.

Czy wiadomo, kto wykonuje pracę?

Sprawdź pools i lanes.

Czy każda bramka ma konkretne znaczenie?

XOR, AND i OR nie powinny być stosowane zamiennie.

Czy warunki ścieżek są zrozumiałe?

Nie pozostawiaj odbiorcy z zagadką.

Czy pokazano najważniejsze wyjątki?

Nie tylko idealny przebieg.

Czy komunikacja między uczestnikami jest odróżniona od sequence flow?

To jedna z podstawowych zasad BPMN.

Czy poziom szczegółowości jest spójny?

Jeżeli nie, zastosuj podproces.

Czy odbiorca rozumie diagram bez godzinnego tłumaczenia?

To najlepszy test praktyczny.

Od BPMN do optymalizacji procesu

Sam diagram niczego jeszcze nie poprawia.

Po stworzeniu AS-IS zacznij analizować model.

Szukaj:

• wielu przekazań między lanes,
• pętli,
• zbędnych akceptacji,
• ręcznych czynności pomiędzy systemami,
• wielu wariantów,
• oczekiwania,
• duplikacji,
• niejasnej odpowiedzialności.

Następnie projektuj TO-BE.

Przykład:

AS-IS:

Pracownik → formularz → Manager → Excel → Finanse → ERP → Zakupy

Analiza ujawnia:

• ręczne kopiowanie do Excela,
• ręczne przepisywanie do ERP,
• każda sprawa wymaga finansów.

TO-BE:

Formularz → automatyczna walidacja → bramka dotycząca wartości

niska wartość:

→ ERP

wysoka wartość:

→ Finanse → ERP

Zmiana nie polega więc wyłącznie na zamianie manualnego zadania na Service Task.

Zmienia się również logika procesu.

Od BPMN do automatyzacji procesu

Gdy TO-BE jest uporządkowany, można zacząć klasyfikować elementy.

Element procesu	Możliwe wykonanie
Powtarzalna decyzja oparta na regule	reguła biznesowa
Przekazanie zadania	workflow
Operacja między systemami	API
Działanie w systemie bez API	RPA
Interpretacja dokumentu	AI / document processing
Decyzja ekspercka	człowiek
Oczekiwanie na termin	timer
Oczekiwanie na informację	message event

Dzięki temu BPMN może stać się pomostem między:

analizą biznesową

a:

projektem automatyzacji.

Łukasiewicz – Poznański Instytut Technologiczny wskazuje BPMN 2.0 jako standard wykorzystywany do analizy AS-IS, projektowania TO-BE i optymalizacji przed wdrożeniem zmian procesowych.

Najważniejsza zasada pozostaje jednak taka sama jak przy automatyzacji procesów:

nie przekształcaj każdego manualnego prostokąta w automat.

Najpierw sprawdź, czy dany krok w ogóle powinien istnieć.

Najlepszy sposób na naukę BPMN: modeluj jeden prawdziwy proces

Nie zaczynaj od zapamiętywania całego katalogu symboli.

Wybierz proces, który dobrze znasz.

Może to być:

• wniosek urlopowy,
• zakup sprzętu,
• obsługa leada,
• reklamacja,
• onboarding pracownika.

Następnie:

1. ustal Start i End,
2. dodaj główne zadania,
3. przypisz odpowiedzialności,
4. dodaj najważniejsze decyzje,
5. pokaż główne wyjątki,
6. sprawdź poprawność przepływów,
7. zweryfikuj model z osobą wykonującą proces.

Dopiero później dodawaj:

• timery,
• komunikaty,
• podprocesy,
• bardziej zaawansowane zdarzenia.

W ten sposób BPMN pozostaje tym, czym powinien być: językiem pomagającym precyzyjnie rozmawiać o procesie, a nie zestawem symboli, które trzeba umieścić na diagramie.