Czym jest BPMS? Wyjaśnienie zarządzania procesami biznesowymi

BPMS, czyli system zarządzania procesami biznesowymi, to oprogramowanie do modelowania i wykonywania zdefiniowanych procesów oraz monitorowania pracy, którą obsługuje. Jego mocną stroną jest wykonywanie procesów: system pilnuje kolejności, przydziela zadania i zapisuje przebieg pracy. Słabiej radzi sobie z szerszym obrazem, bo może wykonywać i raportować tylko tę część pracy, którą mu powierzono.

W tym przewodniku wyjaśniamy, do czego służy BPMS, jakie pięć elementów zwykle obejmuje zakup i gdzie kończą się jego możliwości. Porównujemy też oprogramowanie do wykonywania procesów z process intelligence. To drugie pozostawia wykonywanie procesów systemom, które już dobrze sobie z tym radzą, a ich dane łączy w jednym miejscu dostępnym dla pracowników i używanych przez nich narzędzi AI.

Co oznacza skrót BPMS?

BPMS to skrót od Business Process Management System, czyli systemu zarządzania procesami biznesowymi. Niektórzy dostawcy rozwijają go jako Business Process Management Suite, czyli pakiet do zarządzania procesami biznesowymi. W obu przypadkach chodzi o oprogramowanie do definiowania procesów, kierowania przez nie pracy i monitorowania ich przebiegu.

BPM, czyli zarządzanie procesami biznesowymi, to praktyka polegająca na analizowaniu, projektowaniu, mierzeniu i ulepszaniu sposobu wykonywania pracy. BPMS to jeden z rodzajów oprogramowania, które może wspierać te działania. BPM można stosować bez zakupu BPMS, a sam zakup BPMS nie gwarantuje dobrego zarządzania procesami.

Ta kategoria oprogramowania zmieniała się z czasem. Zaczęło się od silników workflow, później pojawiły się pakiety z dodatkowymi funkcjami modelowania, formularzami i monitorowaniem, a dziś obejmuje także platformy low-code, na których zespoły tworzą całe aplikacje procesowe. Dlatego dostawcy różnie opisują BPMS. Oceniając oprogramowanie do zarządzania procesami biznesowymi, warto pominąć etykietę i zadać cztery pytania: czy system modeluje proces, wykonuje go, łączy się z innymi zaangażowanymi systemami i pokazuje przebieg jego instancji?

Jakie pięć elementów obejmuje BPMS?

Produkty różnią się sposobem łączenia tych funkcji, ale system zarządzania procesami biznesowymi zazwyczaj obejmuje pięć elementów:

1. Modeler. Definiuje się w nim proces, często w BPMN 2.0. Model może opisywać przepływ pracy, a w systemie umożliwiającym wykonywanie procesów także stanowić podstawę jego uruchomienia. Więcej informacji o projektowaniu modeli procesów można znaleźć w opisie modelera BPMN.
2. Silnik wykonawczy. Tworzy instancje procesów, sprawdza warunki, przydziela zadania, uruchamia liczniki czasu i eskaluje opóźnioną pracę.
3. Formularze, reguły i role. Określają, jakie informacje podają pracownicy, jakie zadania widzą i jakie reguły wyznaczają kolejny krok.
4. Integracje. System wymienia dane z aplikacjami, takimi jak systemy ERP i CRM, hurtownie danych oraz bramy API. Prace integracyjne mogą stanowić znaczną część wdrożenia.
5. Monitorowanie i repozytorium. Dashboardy pokazują stan uruchomionych instancji. Repozytorium ułatwia zarządzanie wersjami procesów i kontrolowanie zmian.

Silnik workflow to jeden z elementów tego rozwiązania. BPMS łączy go z narzędziami i mechanizmami kontroli potrzebnymi do definiowania, obsługi i monitorowania szerszego procesu.

Czego BPMS nie zapewni zwykły dokument opisujący proces?

Dokument opisuje, jak praca powinna przebiegać. BPMS może kierować pracą i śledzić jej przebieg zgodnie ze skonfigurowanymi regułami. Na przykład może:

• Eskalować zadanie, które czeka dłużej niż określony czas.
• Kierować instancję do zatwierdzenia po spełnieniu skonfigurowanego warunku.
• Zapisywać ścieżkę przebytą przez każdą instancję.
• Umożliwiać zmianę przepływu przez konfigurację, bez modyfikowania kilku powiązanych aplikacji.

Te funkcje przydają się, gdy potrzebne są spójne zasady kierowania pracy, jasny podział odpowiedzialności i wgląd w instancje obsługiwane przez system. Nie oznaczają jednak, że każda część rzeczywistego procesu odbywa się w BPMS. Jeśli najważniejsze jest udokumentowanie procesu lub zrozumienie jego obecnego przebiegu, oprogramowanie do wykonywania procesów może nie być najlepszym pierwszym krokiem.

Czym różnią się BPMS, silniki workflow, RPA, process mining i process intelligence?

Te pięć technologii odpowiada na różne potrzeby związane z zarządzaniem procesami. Poniższa tabela pokazuje, do czego służy każda z nich i na jakie pytanie pomaga odpowiedzieć.

RPA i BPMS w różny sposób wpływają na proces. RPA automatyzuje zadania w istniejącym procesie. BPMS wykonuje zdefiniowany proces, co może zmienić sposób kierowania pracą. Przed automatyzacją zadania warto sprawdzić, czy można je wyeliminować przez przeprojektowanie procesu. Więcej informacji zawiera artykuł Jak znaleźć możliwości automatyzacji dzięki process mining.

Process mining i BPMS odpowiadają na różne pytania. Process mining analizuje dane o zdarzeniach, aby pokazać, jak praca faktycznie przebiega w systemach. BPMS wykonuje zaprojektowany przepływ i raportuje o obsługiwanych instancjach. To rozróżnienie ma znaczenie, gdy trzeba sprawdzić, czy model odpowiada rzeczywistemu przebiegowi pracy.

Process intelligence to ostatni wiersz tabeli, a zarazem rozwiązanie, które łączy pozostałe elementy. Pozostawia wykonywanie procesów systemom, które najlepiej sobie z tym radzą, odczytuje dane z każdego z nich i utrzymuje jeden model procesu, względem którego można je oceniać. BPMS raportuje o własnych instancjach, a process intelligence o całym procesie, także o pracy, której nie obsługuje żadna pojedyncza platforma.

Dlaczego jeden BPMS nie może obsługiwać wszystkich procesów?

BPMS może wydawać się odpowiedzią na potrzeby związane z zarządzaniem procesami, dopóki nie uwzględni się systemów, nad którymi nie ma kontroli. Rzeczywisty proces przebiega przez system ERP, CRM, narzędzie do obsługi zgłoszeń, portal dostawcy, arkusz kalkulacyjny i kilka skrzynek pocztowych. Platforma obsługuje tylko tę część, którą zamodelowano w jej obrębie. Pozostała praca odbywa się gdzie indziej.

Ta luka ma trzy konsekwencje, które warto poznać przed zakupem.

Zamiast korzystać ze standardów, tworzą Państwo własne workflow. BPMS to zestaw narzędzi, więc każdy proces staje się osobnym projektem: trzeba zamodelować własny wariant, nazwać etapy i utrzymywać własną wersję przepływu, z którego korzystają tysiące innych organizacji. Standardowe modele referencyjne dla procesów od zamówienia do płatności, od zakupu do zapłaty czy zarządzania incydentami są odtwarzane w każdej platformie zamiast ponownie wykorzystywane. W efekcie nawet dwa działy korzystające z tego samego systemu mogą mieć różne wersje tego samego procesu.

Platformy skupione na wykonywaniu procesów tracą z oczu szerszy obraz. BPMS ocenia się na podstawie procesów, które obsługuje, dlatego uwaga i budżet koncentrują się na przepływach działających w systemie. Procesy, których nie obsługuje, czyli te przebiegające między zespołami, systemami i krajami, często nie mają właściciela. Przyspieszenie pracy wykonywanej w systemie nie oznacza jeszcze, że wiadomo, jak działa cała organizacja.

BPMS ma ograniczony zakres, a z czasem przybywa w nim wyjątków. Każdy proces ma wyjątki: pilne zamówienie, ważnego klienta czy dostawcę, który przyjmuje zgłoszenia tylko e-mailem. W BPMS każdy wyjątek oznacza kolejną skonfigurowaną ścieżkę, formularz, integrację i workflow do utrzymania. Platforma, która miała standaryzować pracę, stopniowo zapełnia się szczególnymi przypadkami zrozumiałymi tylko dla jej zespołu.

Nie oznacza to, że BPMS jest złym narzędziem. Nie sprawdza się jednak jako jedyne źródło wiedzy o procesach.

Zarządzanie procesami IT a zarządzanie procesami po stronie biznesu

Największa luka występuje w obszarze zarządzania procesami IT, gdzie pojedyncze zadanie obejmuje kolejkę zgłoszeń, kalendarz zmian, kilka aplikacji i powiązane z nimi zatwierdzenia. Żadne pojedyncze oprogramowanie do zarządzania procesami biznesowymi nie obejmuje wszystkich tych elementów.

Po stronie biznesu luka wygląda inaczej, ale jest podobna. Procesy od zamówienia do płatności, od zakupu do zapłaty czy wdrożenia pracownika również przebiegają przez kilka systemów. Ich etapy należą jednak do operacji, a nie do zespołu wsparcia, więc oczekiwanie mierzy się w dniach, a nie w zgłoszeniach. Przebieg między systemami rzadko jest dokumentowany od początku do końca.

Ta różnica wpływa na wybór oprogramowania. Platformę do zarządzania usługami ocenia się na podstawie obsługiwanych przez nią zgłoszeń, więc raportowany czas kończy się na granicy systemu. Nie widać z niego etapów procesu odbywających się poza platformą, takich jak odpowiedź dostawcy, kontrola zdolności kredytowej czy zatwierdzenie e-mailem. Niezależnie od tego, kto odpowiada za proces, metoda jest taka sama: odtworzyć jego przebieg na podstawie danych o zdarzeniach z każdego systemu zapisującego poszczególne etapy, a następnie porównać go z udokumentowanym przepływem.

Czy warto utrzymywać rzadko używany BPMS?

Wiele organizacji kupiło BPMS ze względu na silnik wykonawczy, ale nigdy z niego nie skorzystało. Wdrożenie trwało dłużej, niż zakładano, pierwsze przepływy skonfigurował partner, a firma nadal pracowała w używanych wcześniej systemach. Pozostał płatny modeler, który kilka osób otwiera, by rysować diagramy, oraz opłaty za utrzymanie środowiska, którego nikt nie uruchamia.

Warto wtedy rozdzielić dwa zadania połączone w jednej platformie. Silnik workflow miał wykonywać pracę, a repozytorium modeli przechowywać wiedzę o procesach. Jeśli realizowane jest tylko drugie zadanie, płacą Państwo za platformę wykonawczą używaną jako narzędzie do dokumentowania. To kosztowny i technicznie rozbudowany sposób na tworzenie dokumentacji.

Jeśli większość tych stwierdzeń jest prawdziwa, platforma wykonawcza ma przechowywać wiedzę, choć nie została do tego zaprojektowana. Rozwiązaniem nie jest rozbudowa środowiska wykonawczego. Wiedzę warto przenieść do narzędzia, które pełni funkcję centralnego repozytorium: przechowuje wszystkie procesy, łączy je z danymi z różnych systemów i udostępnia pracownikom oraz potrzebnym im asystentom AI, bez konieczności utrzymywania środowiska wykonawczego.

BPMS warto zachować dla procesów, które rzeczywiście obsługuje. Wiedzę o procesach można przenieść w miejsce, które można rozwijać bez cyklu wydawniczego.

Czym process intelligence różni się od BPMS?

Różnica jest zamierzona, a nie wynika z braku funkcji. Process intelligence nie wykonuje procesów, bo zajmuje się tym wiele różnych systemów, a najlepszym z nich rzadko jest akurat platforma, którą Państwo mają. RPA, agenci AI, systemy zarządzania workflow, własne workflow systemu ERP i zespoły wykonujące pracę sprawdzają się w różnych obszarach. Narzędzie do wykonywania pracy należy wybierać właśnie pod tym kątem.

Wiedzy nie można jednak pozostawić pięciu różnym systemom. Jeśli każdy z nich przechowuje własny obraz procesu, nikt nie wie, czym ten proces jest, jaki wariant obsłużył danego klienta ani który etap warto zautomatyzować w następnej kolejności. Ważniejsze od wykonywania pracy jest scentralizowanie wiedzy o procesach, zarówno dla osób, które ją wykonują, jak i dla używanych do tego asystentów AI.

Przewaga wynika z dostępu do danych. BPMS raportuje o własnych instancjach, a platforma process intelligence łączy dane o zdarzeniach ze wszystkich systemów, dzięki czemu uwzględnia także pracę, której BPMS nie widział. Może też przechowywać jeden model, względem którego ocenia się BPMS, system ERP i narzędzia do automatyzacji.

Dlaczego process mining pomaga oprzeć model na rzeczywistym przebiegu pracy?

BPMS może raportować o instancjach obsługiwanych w systemie. Nie oznacza to jednak, że uwzględnia wszystkie ścieżki, którymi pracownicy realizują proces. Mogą wystąpić trzy częste luki:

• Praca odbywa się poza silnikiem. Ktoś obsługuje wyjątek e-mailem, a dane w systemie aktualizuje później. Instancja może wyglądać na zgodną z regułami, choć praca trwała dłużej, niż wynika z modelu.
• Ten sam rezultat osiąga się w innych systemach. Zespoły mogą korzystać z systemu ERP, arkusza kalkulacyjnego lub portalu dostawcy. Jeśli ta praca nie trafia do BPMS, dashboardy nie pokażą całego procesu.
• Model przestaje być aktualny. Proces może być poprawnie opisany w chwili publikacji, a później zmieniać się wraz z pojawianiem się lokalnych wariantów. Jeśli aktualizacja modelu trwa długo, takie różnice mogą się utrzymywać.

W efekcie dobrze zarządzany model przestaje odzwierciedlać sposób, w jaki pracują ludzie. Process mining pozwala ponownie oprzeć go na rzeczywistości: odczytuje dane o zdarzeniach zapisywane przez systemy i odtwarza faktyczne ścieżki, również te, których nikt nie zamodelował.

Weryfikacja zgodności porównuje model procesu z danymi o zdarzeniach i pokazuje rozbieżności między projektem a wykonaniem. Z kolei process mining ujawnia warianty, opóźnienia i poprawki zapisane w danych organizacji. Artykuł Dlaczego modelowanie procesów i process mining warto stosować razem wyjaśnia, dlaczego tych dwóch elementów, czyli planu i rzeczywistego przebiegu, nie należy rozdzielać.

Dlaczego nie stworzyliśmy funkcji wykonywania procesów?

To zasadne pytanie o platformę do zarządzania procesami: skoro można zamodelować proces i sprawdzić, jak przebiega, dlaczego go nie wykonywać? BPMS powstał właśnie dlatego, że odpowiedź wydaje się oczywista: należy to zrobić. Wybraliśmy inną drogę, świadomie, a nie przez przeoczenie.

W praktyce oznacza to, że ProcessMind nie przejmuje kontroli nad workflow. Używane już systemy nadal wykonują pracę, a wiedza o tym, co robią, trafia do jednego miejsca i pozostaje aktualna. Jeśli później zmienią Państwo system wykonawczy, na przykład zastąpią bota RPA agentem AI albo starszy workflow nowym, model, historia i pomiary pozostaną na swoim miejscu. Artykuł Dlaczego stworzyliśmy ProcessMind wyjaśnia pozostałe powody tej decyzji.

Jak ProcessMind współpracuje z BPMS?

ProcessMind nie jest systemem BPMS i nie wykonuje pracy. Za obsługę procesów nadal odpowiada BPMS, system ERP lub platforma automatyzacji. Taki jest cel: zachować najlepszy system wykonawczy dla każdego procesu, a wiedzę o wszystkich procesach przechowywać w jednym miejscu.

W praktyce process intelligence działa tak:

• Przed wdrożeniem: Przeanalizuj dane o zdarzeniach z zaangażowanych systemów, aby poznać rzeczywiste ścieżki, warianty i wyjątki. Zamodeluj docelowy proces w BPMN 2.0, a następnie użyj symulacji procesów, by sprawdzić skutki zmiany, zanim ktokolwiek skonfiguruje workflow.
• Po wdrożeniu: Kontynuuj analizę danych, aby sprawdzać, czy przebieg pracy nadal odpowiada projektowi i czy lokalne obejście nie stało się po cichu standardowym sposobem działania.

BPMS wykonuje pracę. Process intelligence pomaga ustalić, co warto wykonywać, i sprawdza, czy przebieg odpowiada procesowi, którego faktycznie przestrzegają pracownicy.

Kiedy wybrać BPMS, RPA, a kiedy process intelligence?

Najlepszy punkt wyjścia zależy od tego, co już wiadomo i jaki problem trzeba rozwiązać.

Zacznij od process intelligence, gdy:

• Pracownicy nie zgadzają się co do tego, jak obecnie przebiega proces.
• Proces obejmuje kilka systemów, a część pracy może odbywać się poza głównym workflow.
• Wiadomo, że proces przebiega zbyt wolno, ale nie wiadomo dlaczego.
• Organizacja ma BPMS, którego silnik workflow nie jest używany, i chce przechowywać wiedzę o procesach w bardziej przydatnym miejscu.

Rozważ BPMS, gdy:

• Proces jest zrozumiały i na tyle stabilny, że można go ustandaryzować.
• Praca obejmuje kilka zespołów, a przekazywanie zadań wymaga jasnych zasad kierowania lub podziału odpowiedzialności.
• Trzeba egzekwować reguły i zarządzać zmianami bez jednoczesnego modyfikowania kilku aplikacji.

Rozważ RPA, gdy:

• Proces jest stabilny i powtarzalny.
• Zadanie powtarza się na tyle często, że warto je zautomatyzować.
• Nie można zmienić aplikacji, a dany etap da się zautomatyzować przez ich interfejsy.

Dwie zasady pomagają zachować właściwą kolejność działań: przed zakupem oprogramowania do wykonywania procesów należy je zmierzyć, a przed automatyzacją zadania sprawdzić, czy można je wyeliminować przez przeprojektowanie procesu.

Jak ocenić BPMS przed zakupem?

Warto zacząć od jednego procesu, który ma jasną nazwę i właściciela: od zamówienia do płatności, od zakupu do zapłaty, wdrożenie pracownika czy obsługa incydentów. Nie należy oceniać ogólnego obszaru, takiego jak „operacje”, bez wskazania konkretnego procesu. Następnie warto przejść przez cztery kroki.

1. Znajdź dane o zdarzeniach

   Sprawdź, które systemy zapisują przebieg procesu i czy ich dane zawierają identyfikator case, nazwę działania oraz znacznik czasu. Narzędzia do zarządzania procesami biznesowymi opisują planowany przebieg, a dziennik zdarzeń potwierdza, co faktycznie się wydarzyło.

2. Porównaj projekt z rzeczywistym przebiegiem

   Znajdź ścieżki, opóźnienia i wyjątki, których nie pokazuje model. Sprawdzenie najlepszego kandydata na BPMS na własnych danych jest bardziej przydatne niż porównanie tabeli funkcji, bo pokazuje, którą część procesu system faktycznie by obsługiwał.

3. Ustal, na co wskazują dane

   Wyniki mogą wskazać BPMS, przeprojektowanie procesu, zmianę jednego etapu albo brak potrzeby zmian. Wybór narzędzia powinien wynikać z ustaleń, a nie odwrotnie.

4. Po wdrożeniu nadal mierz proces

   Platforma może raportować o obsługiwanych przez siebie zadaniach. Dane o zdarzeniach z różnych systemów pokażą, czy po uruchomieniu workflow proces nadal odpowiada rzeczywistej pracy.

Jeśli proces obejmuje systemy, z którymi BPMS się nie łączy, pierwsze pomiary to pokażą. Warto poznać ten obraz przed zakupem narzędzia do wykonywania procesów.