Asseco News
Asseco News to portal informacyjny Asseco Poland. Nasze treści kierujemy do wszystkich osób zainteresowanych tematyką IT, biznesowym aspektem nowych technologii, a także działalnością Asseco.

Automatyzacja procesów biznesowych. Podstawowe pojęcia i problemy

Typowy proces sprzedaży kredytu gotówkowego w banku zawiera od 15 do 20 czynności realizowanych przez osoby pełniące jedną z kilku ról biznesowych – doradcę, analityka, osobę decyzyjną. Inżynier procesu odpowiada za zdefiniowanie modelu takiego procesu, w celu jego późniejszej automatyzacji. Określa on aktywności, których realizacja wymagana jest do osiągnięcia celu, a następnie układa je w optymalny sposób.

 

Niniejszy artykuł rozpoczyna cykl kilku publikacji związanych z tematyką automatyzacji zarządzania procesami biznesowymi w przedsiębiorstwie na przykładzie wybranych procesów realizowanych w bankach. W pierwszej części zostaną przedstawione podstawowe pojęcia związane z tą dziedziną oraz główne problemy, jakie jej aktualnie towarzyszą. W kolejnych, tematyka będzie podążała w kierunku rozważań na temat nowych trendów, jakie pojawiły się w ostatnich latach oraz interesujących perspektyw rysujących się na przyszłość, związanych m.in. z wykorzystaniem bardziej zaawansowanych technik, takich jak process mining, czy analiza i wykorzystanie zjawiska emergencji.

 

Automatyzacja zarządzania procesami biznesowymi (Business Process Management, BPM) jest dziedziną formalnie obecną na rynku IT już od lat 90-tych ubiegłego stulecia, kiedy rozpoczęły się pierwsze prace standaryzacyjne w tym obszarze. Kluczową rolę we wczesnej fazie rozwoju dyscypliny odegrała organizacja Workflow Management Coalition (WfMC), która zdefiniowała podstawowe pojęcia i pierwsze reguły. Początkowo zagadnienie było rozpatrywane w wąskim znaczeniu, jako „zarządzanie przepływem zadań” lub „zarządzanie przepływem dokumentów”. Praktyka pokazała jednak, że problemy związane z BPM mają szerszy kontekst, który należy uwzględnić w budowanej teorii, aby lepiej dopasować ją do spotykanych w przedsiębiorstwach przypadków użycia. Obecnie, wiodące organizacje standaryzacyjne takie jak Object Management Group, czy nadal aktywna WfMC, zgadzają się, że należy uwzględniać aspekty związane z modelowaniem, automatyzacją, sterowaniem, monitorowaniem i optymalizacją procesów w powiązaniu z takimi czynnikami jak posiadany personel, klienci, otoczenie biznesowe, czy wykorzystywane systemy. Istnieje też zgoda co do tego, że głównym wyznacznikiem jakości i poprawności wykorzystywanych procesów powinien być stopień spełnienia celów, jakie wyznacza sobie organizacja. W ostatnich latach szczególnie widoczne jest przesunięcie ciężaru zmian w dwóch kierunkach:
•    zwiększenie roli klienta, wynikające ze spostrzeżenia, że jest on równorzędnym uczestnikiem procesów i jako taki powinien być uwzględniany w ich modelowaniu,
•    rozluźnienie reguł: pojęcie przepływu sterowania powinno być rozumiane w sposób bardziej swobodny. Porządek czynności może być zdefiniowany, ale należy uwzględnić także przypadek, kiedy definicja procesu na danym etapie jego stosowania może być nieokreślona lub określona częściowo.

 

Jedną z metod opisu procesów realizowanych w przedsiębiorstwie są notacje graficzne. Przyjmują one najczęściej postać diagramu aktywności, do którego wprowadzono specjalne rozszerzenia. Najpowszechniej stosowaną notacją jest Business Process Model and Notation (BPMN), która pozwala na określenie czynności realizowanych w procesie, definiowanie możliwych przepływów sterowania pomiędzy nimi, obsługę pojawiających się zdarzeń i sytuacji wyjątkowych oraz określenie spodziewanych artefaktów. Model stworzony za pomocą BPMN, oprócz pełnienia funkcji dokumentacyjnej i regulacyjnej w organizacji, służy często także jako gotowy program wykonywany za pomocą oprogramowania zwanego silnikiem przepływu pracy (workflow engine). Czynność definiowania modelu procesu w celu jego późniejszej automatyzacji nazywana jest „orkiestracją procesu”, a osobę która jest za nią odpowiedzialna określa się mianem „inżyniera procesu”. Jego zadaniem jest zdefiniowanie zbioru aktywności, których realizacja jest wymagana do osiągnięcia celu, a następnie ułożenie ich w sposób najbardziej optymalny.
Zwykle istnieje więcej niż jedno rozwiązanie takiego zadania. Przykładowo, typowy proces sprzedaży kredytu gotówkowego w banku zawiera od 15 do 20 czynności realizowanych przez osoby pełniące jedną z kilku ról biznesowych (doradca, analityk, osoba decyzyjna). Na poniższych rysunkach przedstawiono 3 warianty początkowej części takiego procesu. Wariant 1 został określony jako „defensywny”, ponieważ przedstawienie ofert klientowi jest poprzedzone szczegółowym sprawdzeniem jego obecnej sytuacji kredytowej. Wariant 2, „ofensywny”, charakteryzuje się tym, że oferty są przedstawiane maksymalnie szybko, bez szczegółowej kontroli. Wystąpi ona w dalszych etapach procesu. Wariant 3 określony jako „być może zrównoważony”, to próba odnalezienia rozwiązania optymalnego.

 

Wariant 1, „defensywny”:

 

 

Wariant 2, „ofensywny”:

Wariant 3, „być może zrównoważony”:


Przyjmując, że w całym procesie mamy 17 czynności oraz możliwość ułożenia ich w dowolnej kolejności, to zadanie inżyniera procesu ma 17! (czyli ok. 3,5 * 1014) rozwiązań! Jeśli ograniczymy liczbę czynności, które można organizować w sposób swobodny do siedmiu (co jest liczbą realną w rzeczywistych warunkach), to nadal otrzymujemy ponad 5 tysięcy rozwiązań. Możliwość sprawdzenia empirycznego takiej liczby wariantów leży poza zakresem jakiegokolwiek banku. Wybór właściwego rozwiązania opiera się zatem na wiedzy i doświadczeniu inżyniera procesu oraz późniejszej obserwacji i optymalizacji z wykorzystaniem informacji zwrotnej pochodzącej z praktycznego użycia modelu. Narzędziem pomocnym przy optymalizacji procesu są specjalne wskaźniki o znaczeniu biznesowym zwane Key Performance Indicators (KPI). Przykładami takich wskaźników mogą być: całkowity czas realizacji procesu, obciążenie personelu liczone jako poświęcony czas pracy, obciążenie klienta liczone na przykład jako czas trwania konsultacji, satysfakcja klienta wyrażona za pomocą ankiety, itd. Najważniejsze pytanie, na jakie musi odpowiedzieć inżynier procesu będzie brzmiało: jak zdefiniować funkcję, której argumentami są wskaźniki KPI, aby maksymalizacja wartości tej funkcji prowadziła do spełnienia celu procesu (zakładając oczywiście, że cel taki został wcześniej określony – w omawianym przykładzie będzie to zapewne maksymalizacja wartości i jakości kontraktów)? Drugi problem przed jakim stanie inżynier procesu to: jak modelować proces, aby badana funkcja rzeczywiście przyjmowała wartości maksymalne (rozwiązań mamy 5 tysięcy), oraz: jak wiarygodnie i bez opóźnień weryfikować rezultaty? Tradycyjne podejście do automatyzacji procesów biznesowych, nakazuje problemy takie rozwiązywać według schematu opartego na dwóch filarach:

 

1.    wiedzy eksperckiej inżyniera procesu,
2.    optymalizacji bazującej na danych empirycznych pochodzących z wielokrotnego wykonania procesu.

 

Przykład takiego schematu został zobrazowany na poniższym rysunku:

 

Oprócz naturalnej podatności powyższego schematu na problemy wynikające z niepełnej wiedzy eksperta, które eliminuje się poprzez monitorowanie i optymalizację, w rzeczywistym otoczeniu biznesowym występuje jeszcze jedno zagrożenie. Są nim stale zmieniające się warunki prowadzenia działalności. To, co dziś daje przewagę rynkową, jutro może stać się mało znaczącym składnikiem biznesu, lub nawet może utrudniać jego prowadzenie. To, co obecnie nie trafia w potrzeby sektora docelowego, jutro może okazać się elementem atrakcyjnym i pożądanym. Na mapie BPM pojawia się nowe wyzwanie – adaptacja. Ostatnie lata rozwoju dziedziny przyniosły duży rozwój w tym zakresie. Oprócz tradycyjnego BPM wspieranego notacją BPMN pojawiło się nowe podejście: Adaptive Case Management, wspierane nową notacją Case Management Model and Notation (CMMN).
Ten obiecujący kierunek rozwoju dziedziny stanie się tematem kolejnego artykułu.

 

Maciej Koryl, Architekt Systemowy, Asseco Poland

 

Autor jest opiekunem Koła Naukowego Systemów Klasy Enterprise na Politechnice Rzeszowskiej oraz prowadzi zajęcia na studiach podyplomowych na kierunku Inżyniera Oprogramowania w Wyższej Szkole Informatyki i Zarządzania.