Dlaczego warto analizować procesy biznesowe przed planowaniem i wdrożeniem rozwiązań IT?

Business Process Model and Notation (BPMN) to graficzne przedstawienie procesów biznesowych. Zaprojektowanie przebiegu procesów umożliwia ich analizowanie i optymalizację. W tym artykule skupię się na BPMN w kontekście decyzji o wdrożeniu aplikacji usprawniających funkcjonowanie firmy. Dotyczy to zarówno indywidualnie tworzonych programów, jak również gotowych rozwiązań. Chociaż BPMN nie służy bezpośrednio do projektowania oprogramowania, ma istotne znaczenia w przypadku weryfikacji zapotrzebowania na rozwiązania IT. 

W większości firm procesy biznesowe przebiegają w sposób stosunkowo naturalny. Częściowo są one zdefiniowane w wewnętrznych dokumentach firmowych. W praktyce jednak wewnętrzne regulacje nie oddają w całości aktywności podejmowanych przez pracowników czy oddziały. Najczęściej taka sytuacja jest akceptowana przez osoby zarządzające. Do czasu, gdy niezbędne okazuje się ich zoptymalizowanie.

Optymalizacja procesów biznesowych wymaga podjęcia różnych decyzji i zaprojektowania wielu aspektów codziennego funkcjonowania firmy. Oznacza to, że proces ten obejmuje nie tylko oprogramowanie wspomagające pracę. W wyniku weryfikacji istniejących procesów można bowiem uznać, że zakup aplikacji nie będzie najlepszym rozwiązaniem dla określonej firmy. Oczywiście wiosek może być też taki, że przedsiębiorstwo potrzebuje wielu różnych programów lub odwrotnie – integracji istniejących rozwiązań IT. 

Business Process Model and Notation jako wstęp do diagnozowania potrzeb

W tym artykule chciałabym skupić się na tych sytuacjach, w których analiza i projektowanie optymalnych procesów biznesowych powiązane jest z tworzeniem programów. Wynika to z mojego doświadczenia w tym aspekcie. Mam świadomość, że wiele problemów w trakcie wdrażania rozwiązań informatycznych wynika z niedomówień powodujących, że programy nie spełniają oczekiwań biznesowych. Podczas projektowania lub dostosowywania programów do indywidualnych potrzeb firmy istotna jest poprawna komunikacja. Ta rozpoczyna się jednak od właściwego zdiagnozowania zapotrzebowania, które jest pochodną procesów biznesowych. Początkiem rozmów na temat planowania i projektowania jakichkolwiek rozwiązań z zakresu IT jest zatem przeanalizowanie procesów oraz ich odpowiednie zaprojektowanie. W tym celu można wykorzystać Business Process Model and Notation (BPMN).

BPMN – podstawowe informacje

Business Process Model and Notation (BPMN) to notacja w formie graficznej, która służy do przedstawiania procesów biznesowych. Zbiór odpowiednich symboli umożliwia zaprezentowanie zdarzeń oraz poszczególnych aktywności, przepływów pomiędzy nimi, a także bramek decyzyjnych, z uwzględnieniem uczestników. BPMN jest utrzymywane przez organizację Object Management Group (OMG). Chociaż nie jest to jedyny sposób graficznego prezentowania procesów, to jest on stosunkowo popularny i uniwersalny. W większości przypadków pozwala na opracowanie wizualizacji zrozumiałej dla specjalistów z różnych dziedzin. Jednocześnie należy podkreślić, że w przypadku BPMN nie można mieszać kontekstu biznesowego oraz powiązanego z projektowaniem systemów informatycznych. Do tego drugiego celu przeznaczony jest m.in. język modelowania Unified Modeling Language (UML). 

BPMN – pule i tory

Pule (pool) to kontenery graficzne, które prezentują poszczególnych uczestników zdarzeń (eventów). Mogą nimi być osoby na określonych stanowiskach czy role, działy, a nawet całe organizacje. Wewnątrz puli prezentuje się elementy przepływu procesu i aktywności (zadania czy prace).

Nie zawsze jednak możliwe jest zaprezentowanie wszystkich aktywności podejmowanych przez określonych uczestników procesu, co dotyczy szczególnie współpracy z podmiotami zewnętrznymi. W takich przypadkach możliwe jest zaprezentowanie puli bez zawartości, ponieważ procesy przykładowo w zewnętrznej firmie najczęściej nie są do końca znane analitykowi.

Tory (lane) to bardziej szczegółowa reprezentacja uczestników procesów biznesowych. Dzięki nim możliwe jest przedstawienie aktywności poszczególnych komórek organizacyjnych czy ról. Warto bowiem zwrócić uwagę na fakt, że podczas tworzenia kompleksowego diagramu możliwe jest, że w ramach jednego zdarzenia podejmowane będą działania przez osoby na różnych stanowiskach, a także przez kilka oddziałów. W takim wypadku należy wskazać przepływy na poziomie całej firmy i zadania, za które odpowiadają poszczególne role (osoby na odpowiednich stanowiskach) czy komórki organizacyjne.

BPMN – zdarzenia, aktywności 

Granice zdarzenia, a więc eventu, oznacza się za pomocą okręgów. Pojedyncza cienka linia wskazuje początek, a pojedyncza gruba koniec. Okręgi z podwójną linią oznaczają, że dane zdarzenie poprzedza inny event.

W ramach zdarzeń prezentowane są aktywności i przepływy umieszczone w pulach lub torach. Aktywności oznaczane są jako zaokrąglone prostokąty. W praktyce można także spotkać diagramy prezentujące komunikację pomiędzy poszczególnymi osobami, stanowiskami lub jednostkami, które nie są zorganizowane w pule i tory. Wynika to z faktu, że kompleksowe ujęcie wszystkich procesów bywa problematyczne, stąd obok ogólnych informacji umieszcza się również analizy szczegółowych wycinków procesów. 

BPMN – subprocesy, aktywności wieloinstancyjne i ich grupy 

Aktywności zaprezentowane na diagramie mogą posiadać dodatkowe oznaczenie „+”, które wskazuje, że posiadają one pewne subprocesy. Dla subprocesów można przygotować dodatkowe diagramy, aby poprawić czytelność. Często działania podejmowane w firmie są na tyle skomplikowane, że sensowny jest podział na procesy główne i subprocesy. 

Korzystając z BPMN, można uprościć prezentację określonych aktywności również poprzez korzystanie z grup oraz wieloinstancyjnych aktywności równoległych (parallel multi-instance activity) i sekwencyjnych (sequential multi-instance activity). Wieloinstancyjne aktywności to takie, które dotyczą wielu działań czy zadań o określonym typie. Mogą one odbywać się jedno po drugim (sekwencyjnie) lub niezależnie od siebie w określonym czasie czy w tym samym przedziale czasowym (równolegle). Przykładem może być wysyłka wiadomości w przypadku zmiany terminu spotkania do wszystkich jego uczestników. Jeżeli w spotkaniu bierze udział 10 osób, to każde wysłanie wiadomości mailowej stanowi typ aktywności o nazwie „wysyłka e-mail z informacją o zmianie spotkania do uczestników”. W tym typie mieści się wysyłka wiadomości do konkretnych osób czy ról, np. „wysyłka e-mail z informacją o zmianie spotkania do Jana Kowalskiego”, „wysyłka e-mail z informacją o zmianie spotkania do Anny Nowak” lub „wysyłka e-mail z informacją o zmianie spotkania do księgowego”, „wysyłka e-mail z informacją o zmianie spotkania do project managera” itd. Nie ma jednak sensu wyszczególnianie każdego pracownika czy stanowiska, skoro możliwe jest oznaczenie takiej aktywności jako „wysyłka e-mail z informacją o zmianie spotkania do uczestników”.

Grupowanie aktywności różni się od sekwencyjnych i równoległych aktywności wieloinstancyjnych tym, że stanowi zgrupowanie różnych aktywności, o różnych typach. To znaczy w przypadku zmiany terminu spotkania musimy wysłać e-mail z informacją o zmianie spotkania do uczestników, ale także wpisać nową datę spotkania do kalendarza udostępnianego wszystkim pracownikom i zarezerwować salkę. Możemy zatem zgrupować razem aktywności: „rezerwacja salki”, „wpisanie nowej daty do publicznego kalendarza” i aktywności równoległe o typie: „wysyłka e-mail z informacją o zmianie spotkania do uczestników”.

BPMN – bramki decyzyjne i łączniki

Łączniki to elementy łączące poszczególne aktywności. Możemy wyróżnić: przepływy sekwencji (sequence flows), przepływy komunikatów (message flows), powiazania pojęciowe (association) oraz powiązania danych (data association). Przepływy wskazują na następstwo i wyznaczają kierunek. Są istotnym elementem projektowania procesów, a dzięki bramkom decyzyjnym możliwe jest wskazywanie wielu ścieżek dostępnych w określonych sytuacjach.

Bramki decyzyjne to elementy związane z kontrolą przepływów. Poszczególne aktywności mogą bowiem przebiegać liniowo, jednak często rozwidlają się, ponieważ procesy wymagają podejmowania decyzji. Wyróżnia się:

• ekskluzywne bramki decyzyjne (exclusive gateway decision);
• inkluzywne bramki decyzyjne (inclusive gateway decision);
• równoległe bramki decyzyjne (parallel gateway decision);
• bramka zdarzeniowa, decyzje bazujące na zdarzeniu (event-based i parallel event-based);
• kompleksowe bramki decyzyjne (complex Gateway).

Ekskluzywne bramki decyzyjne – przykład

Przykładem bramki ekskluzywnej jest sytuacja, w której do firmy sprzedającej drukarki firmowe przychodzi klient zainteresowany zakupem produktu. Załóżmy, że firma daje rabat klientom, którzy już posiadają ich urządzenia i chcą je wymienić na nowe. W takich sytuacjach odbierane jest dotychczasowe urządzenie, a w zamian za to wystawiany jest rabat na nowe. Sprzedawca zatem ma do wyboru dwie możliwe ścieżki – może zaoferować wymianę starej drukarki na rabat lub nie może tego zrobić, jeżeli klient nie chce skorzystać z takiej opcji lub nie posiada urządzenia tej firmy. W tej sytuacji nie jest możliwe spełnienie obu warunków jednocześnie, ponieważ albo osoba zainteresowana zakupem chce i może wymienić stare urządzenie na nowe, albo nie chce lub nie może tego zrobić. Sprzedawca wybierze zatem tylko jedną ścieżkę i zgodnie z nią będzie kontynuować proces. 

Inkluzywne bramki decyzyjne – przykład

Przykładem inkluzywnej bramki decyzyjnej może być sytuacja, gdy pracownik banku zadaje pytanie osobie posiadającej działalność gospodarczą, czy jest klientem indywidualnym czy firmowym. W obu bowiem przypadkach może zaoferować klientowi całkiem inne produkty. Można zatem wskazać osobne ścieżki dla obsługi klienta indywidualnego i firmy. W tym wypadku ta sama osoba może posiadać konto indywidualne i firmowe. Jednocześnie nie można założyć, że każdy będzie posiadał oba rodzaje kont. Tym samym pracownik banku może – ale nie musi – przeprowadzić oba procesy w zależności od tego, czy klient spełnia oba warunki jednocześnie czy też nie.

Równoległe bramki decyzyjne – przykład

Równoległe bramki decyzyjne obrazują procesy, które następują bez spełnienia dodatkowych warunków. Innymi słowy są one obligatoryjne i każda z zaprezentowanych na diagramie ścieżek zostanie wykonana. Przykładem może być wcześniej wskazana sytuacja przekładania spotkania. W takim przypadku obligatoryjnie należy zmienić termin wydarzenia w kalendarzu oraz poinformować o tym fakcie osoby na nie zaproszone. Oba działania muszą zostać wykonane bez dodatkowych warunków.

Pozostając przy przykładzie zmiany terminy spotkania, można również w diagramie uwzględnić fakt, że tego typu modyfikacja jest powiązana z określonym zdarzeniem poprzedzającym. Przykładowo może to być sytuacja kryzysowa i zaangażowanie osób zaproszonych na spotkanie w działania sztabu kryzysowego. W takim przypadku bramka decyzyjna jest nie tylko równoległa, ale także bazująca na zdarzeniu.

BPMN – wejście, wyjście i dane

BPMN oferuje także dodatkowe oznaczenia dotyczące danych. To bardzo ważne w szczególności, gdy procesy powinny uwzględniać kwestie dotyczące przykładowo danych osobowych i przepisów RODO. Możliwe jest oznaczenie: obiektów typu dane (data object), ich wejścia i wyjścia (data input, output), a także persystencji danych/magazynów danych (data store).

Przykładem wykorzystania powyższych oznaczeń może być pozyskiwanie danych i wysyłka wiadomości e-mail do użytkowników, którzy zapisali się na newsletter. Proces rozpoczyna się od zapisu na newsletter, kiedy to możemy wskazać miejsce wejścia danych (np. formularz na stronie internetowej). Następnie można oznaczyć miejsce ich przechowywania (np. serwer firmowy, rozwiązania chmurowe), a także punkt wyjścia, gdy pracownik pobiera adresy e-mail, by wysłać wiadomości za pomocą korespondencji seryjnej. Łączymy tutaj aktywności pracownika z wykorzystaniem aplikacji. 

Oczywiście miejscem, w którym przechowywane są tego typu dane, może być dedykowane narzędzie do wysyłki newslettera. Proces pozyskania danych, a więc i punkt wejścia, jest podobny. Jednakże przetwarzanie danych osobowych nie będzie wymagało ich pobrania. Teoretycznie pracownik może skorzystać z wcześniej zdefiniowanych grup odbiorców bez jakiegokolwiek zapoznania się z zawartością bazy. Z punktu widzenia procesów biznesowych pracownik nie pobrał danych, chociaż zdajemy sobie sprawę z faktu, że dane te są pobierane z serwera w ramach aplikacji. Tutaj można zauważyć, że projektowanie procesów biznesowych i rozwiązań w postaci systemów informatycznych różni się w znaczący sposób.

BPMN – pętle

Pętle oznaczają procesy, które są powtarzalne w czasie. Oznacza to, że pewne zbiory aktywności lub pojedyncze aktywności wykonywane są powtórnie wiele razy. Odnosząc pętle do sytuacji z życia, warto wyobrazić sobie pracę urzędnika obsługującego ściśle określony typ spraw. Petenci pobierają bilety z odpowiednim numerem, w efekcie czego każdy zgłasza się do przykładowego urzędnika z tą samą sprawą. Urzędnik przechodzi przez proces rozwiązania sprawy jednego zainteresowanego, a następnie obsługuje kolejnego, który zgłosił się z dokładnie z tą samą sprawą. To oznacza, że ponownie przechodzi przez ten sam proces. Całość powtarza się do momentu, gdy kolejka zostanie „rozładowana”, a więc nie będzie kolejnych osób z określonym problemem. Z punktu widzenia pracy takiego przykładowego urzędnika wykonuje on pętlę.

BPMN – inne oznaczenia

W dokumentacji Business Process Model and Notation można znaleźć wiele dodatkowych oznaczeń, które są bardzo pomocne podczas projektowania procesów. Więcej można znaleźć na stronie Object Management Group zawierającej pełną dokumentację BPMN. W tym artykule skupiłam się na najczęściej wykorzystywanych oznaczeniach przez firmy. BPMN daje jednak o wiele większe możliwości dostosowania diagramów do procesów biznesowych danego przedsiębiorstwa.

Logika biznesowa a proces tworzenia oprogramowania

Logika biznesowa i proces projektowania oprogramowania nie są tożsame. To znaczy procesy biznesowe mogą być wspomagane wykorzystaniem różnego rodzaju aplikacji, ale nie muszą. Oczywiście trudno jest nam sobie dzisiaj wyobrazić, że firma mogłaby nie korzystać z żadnych aplikacji, zresztą z części musi ze względu na przykładowo prawo podatkowe.

Jednocześnie planowanie wdrożenia aplikacji wymaga świadomości rzeczywistego zapotrzebowania firmy. To natomiast można ocenić po dokładnej analizie. Jednakże sprowadzanie wszystkich działań związanych z funkcjonowaniem przedsiębiorstw tylko do programów informatycznych pomijałoby istotne procesy biznesowe. 

Świadomość procesów pozwala na wybór efektywnych rozwiązań IT

Podczas moich doświadczeń z planowaniem funkcjonalności i wdrażaniem aplikacji często musiałam dostosowywać swoją komunikację do specjalistów z różnych obszarów. Mając ten sam cel, osoby specjalizujące się w zarządzaniu, marketingu i IT posługiwały się zupełnie inną logiką opisywania w gruncie rzeczy tych samym procesów. Patrząc na zakup w sklepie online z punktu widzenia firmy, widzimy drogę, którą pokonuje użytkownik, a której celem jest nie tylko konwersja. Zaczyna się ona przed znalezieniem strony sklepu internetowego, a transakcja nie oznacza końca tzw. customer journey. Firma w ramach procesu sprzedażowego podejmuje liczne działania poza sklepem internetowym. Ktoś musi zapakować przesyłki, dbać o relacje z firmą kurierską, uzgadniać szczegóły z dostawcami, prowadzić promocję sklepu itd. Część z procesów związanych z e-commerce możemy jednak postrzegać z perspektywy interakcji użytkownika z aplikacją i opisać je za pomocą graficznej prezentacji user journey. Na etapie planowania sklepu internetowego sytuacja wygląda nieco inaczej. Procesy związane z modelowaniem systemu muszą uwzględniać nie tylko potencjalne przypadki użycia czy interakcje, ale także strukturę i działanie samej aplikacji.

Pomimo tych różnic graficzna prezentacja procesów biznesowych, w zgodzie z przykładowo Business Process Model and Notation, to dobry wstęp do optymalizacji codziennych działań. Dotyczy to również weryfikacji zapotrzebowania na rozwiązania IT. BPMN pozwala na dokładniejsze zrozumienie, jakie faktyczne oczekiwania powinna spełniać dana aplikacja i umożliwia określenie celu biznesowego oraz jej funkcjonalności.