Dyrekcja

Artykuł ukazał się w Business Dialog Bulletin w kwietniu 2007 r.

Pojęcie procesu biznesowego na dobre zadomowiło się w biznesowej rzeczywistości i nikogo nie dziwią inicjatywy, często bardzo kosztowne, mające na celu opisanie czy usprawnianie procesów biznesowych. Niestety, wraz z popularyzacją podejścia procesowego do zarządzania organizacją, pojęcie procesu biznesowego uległo rozmyciu.

Artur Kasprzyk

Procesem biznesowym nazywa się całe obszary funkcjonowania organizacji, takie jak marketing czy sprzedaż, procesem biznesowym jest zarazem dużo mniejszy obszar działania, taki jak obsługa zamówienia; równie często procesem biznesowym nazywa się opis działań realizowanych przez narzędzia informatyczne klasy BPMS. Z drugiej strony opis procesów biznesowych jest najczęściej wykonywany na poziomie „ogólnej” koncepcji działania, bardzo często z łamaniem zasad języka wykorzystywanego do utworzenia opisu. Z przykrością należy stwierdzić, iż w dużym stopniu do takiego stanu rzeczy przyczyniają się projekty związane z pozyskaniem normy ISO, w ramach których firmy audytorskie akceptują niepoprawne opisy, sankcjonując tym samym brak precyzji i niejednoznaczność. Na skutek tego  rodzi się przekonanie, iż opis procesów służy głównie pozyskaniu normy ISO oraz jakiejś wąskiej grupie ludzi, która jest za nie odpowiedzialna. Podawana jest także w wątpliwość sama idea procesowości, poprzez podniesienie prostych, ale jakże trafnych argumentów w stylu „skoro tak prosto działamy, jak nam tutaj zaprezentowano, to skąd się bierze tylu sprinterów w garniturach na korytarzach firmy?”. Codzienne życie organizacji jest niewrażliwe na wyniki certyfikacji.

Splot tych czynników powoduje, iż z uruchamianych projektów wdrażania podejścia procesowego do zarządzania organizacją niewiele kończy się sukcesem biznesowym.

Niniejszy artykuł ma na celu zaprezentowanie obecnego stanu adaptacji podejścia procesowego i zagrożeń, jakie przy tym występują oraz wskazanie tych kierunków jego rozwoju, które stwarzają nadzieję na osiągnięcie większych korzyści z  inwestycji w projekty wdrażania procesowych metod zarządzania. Z uwagi na objętość materiału, w artykule nie zostanie zaprezentowane powiązanie pomiędzy mapami strategii a modelem procesowym organizacji.

Obecny etap adaptacji podejścia procesowego

Z punktu widzenia dostępnych technik opisu procesów wydaje się, iż w Polsce1 większość projektów jest realizowana z wykorzystaniem podejścia opartego na karcie przepływu procesu (flowchart), popularnego na rynku od kilkudziesięciu lat. Omawianą technikę opisu można z powodzeniem stosować w wielu obszarach funkcjonowania organizacji, w których „liniowość” jest naturalną cechą prowadzonych działań. Typowymi przykładami są liniowe procesy produkcyjne, procesy administracyjne czy też procesy w organizacjach podlegających ścisłym rygorom prawnym (np. w bankach). Zgodnie z tym podejściem w dalszych fazach wdrażania zmian w organizacji procesy są uzupełniane procedurami postępowania uwzględniającymi reguły biznesowe zidentyfikowane podczas opisu. Podstawowym ograniczeniem tego podejścia jest konieczność opisania wszystkich dozwolonych sekwencji działań oraz zbyt skromne możliwości reprezentacji działań uruchamianych współbieżnie (w tym także innych procesów) w zależności od stanu realizacji danego procesu. Słabości te czynią metodę mało użyteczną w sytuacjach, w których nie sposób przewidzieć wszystkich możliwych konfiguracji działań. Typowa sytuacja tego rodzaju to działania sprzedażowe, w trakcie których kolejne czynności są na bieżąco wybierane – spośród  określonego dozwolonego zbioru – na podstawie stanu realizacji negocjacji handlowych.

Przykładem języka modelowania omawianego typu jest mocno już okrzepła i popularna metoda Rummlera-Brache’a. Inny przykład to notacje konstruowane ad hoc na potrzeby poszczególnych projektów w oparciu o podstawowe symbole przepływu pracy dostępne w popularnym pakiecie Visio.

W praktyce opis oparty na flowchart okazuje się często zbyt uproszczony, nie odzwierciedla złożoności i różnorodności współczesnych procesów biznesowych. Trudno jest na podstawie takiego opisu sformułować specyfikację oczekiwanego wsparcia działań organizacji technologiami informatycznymi – zestawy wymagań są bądź zbyt ogólne, by mogły stanowić podstawę do świadomego ich zatwierdzenia, bądź zawierają zbyt wielką mnogość oczekiwań, znacznie ponad rzeczywiste zapotrzebowanie. W efekcie może to prowadzić do budowy lub zakupu systemów, z których spora część funkcjonalności będzie niewykorzystana, a brakować będzie kluczowych funkcjonalności, które nie zostały zidentyfikowane z powodu zbyt ogólnego opisu zasad działania organizacji.

Informatyka skupia swoje zainteresowanie na procesach biznesowych gdyż potrzebuje precyzyjnych i kompletnych specyfikacji wymagań biznesu wobec narzędzi, które biznesowi udostępnia – narzędzi wspomagających zarządzanie procesami poprzez integrowanie działania systemów informatycznych oraz działania pracowników w ramach jednego wspólnego środowiska pracy. O wpływie tychże narzędzi na model procesowy organizacji traktuje następny rozdział.

BPMS

Wraz z falą fascynacji architekturą zorientowaną na usługi (Service Oriented Architecture, SOA) rośnie zainteresowanie tzw. systemami zarządzania procesami biznesowymi, określanymi akronimem BPMS. Są to systemy informatyczne, których zadaniem jest definiowanie procesów biznesowych oraz umożliwienie ich późniejszego nadzoru. Lecz dla potrzeb systemu informatycznego procesy muszą być opisane w sposób jednoznaczny i dokładnie odpowiadać rzeczywistości. Zestawienie tego wymogu z dotychczasową praktyką zarządzania, dopuszczającą pewien margines dowolności (jak w przypadku opisanej wyżej metodologii wykorzystującej flowcharts) rodzi zasadniczą wątpliwość. Z jednej bowiem strony narzucenie ścisłych wymogów formalnych na opis procesu daje spore szanse na usprawnienie pracy, ale z drugiej strony spore zagrożenie jej paraliżu, a co najmniej odczuwalnych niedogodności. Moim zdaniem jedynym powodem tej kontrowersji jest stale jeszcze otwarte pytanie o możliwość oddania rzeczywistości przy pomocy dostępnego języka modelowania.

Zakładając umiejętność precyzyjnego modelowania, o tym, czy ostatecznie projekt zaowocuje sukcesem czy porażką w dużej mierze zadecyduje, czy przyjęty przez narzędzie paradygmat modelowania umożliwia odzwierciedlenie rzeczywistości. Jeżeli modelujemy przy pomocy np. coraz popularniejszego języka BPMN, wówczas jesteśmy w stanie perfekcyjnie oddać wszystkie wariancje w ramach procesów przemysłowych. Aczkolwiek, istnieje ryzyko pojawienia się problemów, jeśli naszym zadaniem będzie wsparcie narzędziami do zarządzania procesami działów sprzedaży czy marketingu. Przed jeszcze trudniejszym zadaniem staniemy w przypadku firm produkujących oprogramowanie, w których jedne procesy są definiowane ad hoc w ramach realizacji innych procesów.

Rozwiązania komplementarne

W sukurs obecnym już na rynku metodom modelowania i zarządzania procesami przychodzą nowe podejścia, uzupełniające dotychczas stosowane techniki i narzędzia. Część z nich już została uznana na rynkach bardziej dojrzałych i chętniej adaptujących nowe trendy, część z nich dopiero zaczyna „nabierać rumieńców”.

Jedną z technik modelowania struktur procesowych, pozwalającą uczynić z monolitycznych konstrukcji swobodnie powiązane fragmenty działań, jest Event-Driven Architecture (EDA). Według tej koncepcji, której stosowanie jest niesłusznie zawężane jedynie do rozwiązywania problemów informatycznych, opisywany organizm (bez względu na to, czy jest to proces biznesowy, czy też działanie wewnątrz infrastruktury IT, np. opartej na SOA) składa się z wielu autonomicznych składowych, komunikujących się wzajemnie w sposób asynchroniczny poprzez wysyłanie i odbieranie zdarzeń. Koncepcja taka zbliża zdecydowanie tworzony model procesów biznesowych do realiów funkcjonowania organizacji, w której jedne działania (np. obsługa zgłoszenia reklamacyjnego) komunikują się z innymi obszarami funkcjonowania organizacji (np. obsługa usterki) poprzez przesłanie komunikatów (np. e-mail). Organizacja jest wówczas postrzegana jako zestaw „uruchomionych” drobnoziarnistych działań, które w odpowiednich momentach wysyłają do organizacyjnego uniwersum sygnały o osiągnięciu określonego stanu, w efekcie czego może dojść do uruchomienia, zakończenia czy też wybudzenia innych działań. Oczywiście, można zarzucić pomysłowi, iż miast wielkich bloków działań („na których wszystko widać”), uzyskujemy dużo większą liczbę działań drobniejszych, powiązanych wzajemnie pajęczyną niejawnych zależności. Ale czy nie tak wyglądają nasze organizacje?

Innym kierunkiem rozwoju podejścia procesowego jest koncepcja zarządzania sprawami (case management, case handling), według której w ramach obsługi sprawy (instancji procesu), zespół przypisany do jego realizacji współdzieli informacje powstające w ramach obsługi tej sprawy, a działania (ciągi akcji) są podejmowane w momencie, gdy spełnione są wymagane do tego warunki (np. informacja opisująca osiągnęła określony stan). Osoba pracująca nad sprawą decyduje (a nie „wnioskuje” z przygotowanego wcześniej opisu) o kolejnym działaniu, jakie ma zostać wykonane. W przeciwieństwie do wcześniej wymienionych technik, podejście zakłada, iż w ramach obsługi sprawy mogą się pojawić dane (dokumenty itp.), których nie przewidziano w opisie procesu (w „tradycyjnym” podejściu procesowym projektant procesu określa jakie dane będą przetwarzane). Przykładem obszarów zastosowań tego typu podejść mogą być sprawy sądowe, czy zgłoszenia szkód w firmach ubezpieczeniowych.

Kolejne podejście, nazywane zarządzaniem ludzkimi interakcjami (human interaction management, HIM) uwzględnia jeszcze większą „nieprzewidywalność” działań w ramach opisu procesów. Zgodnie z teorią HIM, ludzie wykonujący pracę umysłową pracują według określonych wzorców postępowania. Przez większą część czasu wykonywana praca, mogąca trwać tygodnie, miesiące czy lata, może nie przynosić wymiernych efektów, jakich oczekuje się od procesu, co nie oznacza, iż proces nie jest realizowany. Podejście zakłada bowiem, iż kluczową rzeczą – z punktu widzenia procesów opierających się na pracy umysłowej – jest zdefiniowanie interakcji pomiędzy rolami (rozumianymi w znaczeniu zdefiniowanym w technice RAD2) biorącymi udział w realizacji procesów oraz wskazanie warunków wejściowych pozwalających na uruchomienie danego działania i wyjściowych pozwalających uznać je za zakończone. Przy takim podejściu, realizowany proces jest postrzegany jako zbiór wykonywanych „atomowych” działań, a każda z ról biorących udział w procesie postrzega go jako zestaw działań, które powinna w danym momencie wykonywać. Kolejną, cechą charakterystyczną dla omawianego podejścia jest założenie, iż w ramach ról biorących udział w realizacji konkretnego procesu istnieje wystarczająca kompetencja oraz organizacyjne umocowanie, by móc zredefiniować proces w trakcie jego wykonywania (można uznać, iż początkowo każda instancja procesu jest uruchamiana zgodnie z ustalonym wzorcem, ale w toku realizacji prac kształt instancji procesu może ulec zmianie). Przykładem tego typu procesów są działania związane z opracowywaniem kampanii marketingowej czy budową systemów informatycznych, w których ciężko a priori przewidzieć działania, które będą wykonywane w celu doprowadzenia  przedsięwzięcia do końca.

Podsumowanie

Obserwacja działań podejmowanych w naszym kraju w obszarze modelowania procesów biznesowych nie napawa optymizmem. Spośród sporej liczby projektów, które mieliśmy okazję audytować, czy po prostu przyglądać się im, duża część (50-60%) była realizowana bez jasnego i przemyślanego pomysłu, nie mówiąc już o systematycznej metodyce. To przeraża. Szczególnie niedobrze jest w projektach, w których modele procesów biznesowych tworzone są  przez zespoły pracujące nad wdrożeniem rozwiązania informatycznego. Pomijając ewentualny wpływ kwestii etycznych (konflikt interesów: albo poprawnie albo tak, aby model procesów pasował do systemu, który akurat mamy), w wielu przypadkach powodem takiego stanu rzeczy jest najzwyczajniej w świecie brak odpowiednich kompetencji w zespole realizującym projekt. Na to nakłada się bardzo często brak wystarczającej wiedzy o sposobach modelowania procesów oraz o korzyściach z tego płynących po stronie zamawiającej. W efekcie powstają modele procesów, których nikt nie czyta, do których nikt się nie stosuje i których nikt nie utrzymuje. Opisy procesów na potrzeby norm ISO, które pracownicy „wkuwają” na dzień przed wizytą audytora, by dzień później o nich zapomnieć. Opisy procesów rozpoczęte na początku uruchomienia projektu wdrożenia systemu informatycznego i porzucone gdzieś w trakcie ich realizacji, gdyż „nie było już czasu”. I co gorsza, ogólne przekonanie, iż modelowanie procesów niewiele jest warte, bo nie ma z tego żadnych biznesowych korzyści, a za to całe mnóstwo problemów.

No ale czemu się dziwić? Żyjemy w kraju, w którym występuje chyba ewenement w skali światowej – wykładowcy na konferencjach „branżowych” muszą zapłacić za możliwość wystąpienia! Skoro tak się sprawa ma, to inwestycja musi się zwrócić. Toteż uczestniczymy w imprezie bardziej propagandowej niż merytorycznej i otrzymujemy taką wiedzę, na otrzymanie jakiej zgodziliśmy się. Kolejna obserwacja – z jakiś nieznanych powodów, jesteśmy bardzo wrażliwi na brak wdrożeń referencyjnych w Polsce. Bardzo często oceniając dojrzałość rozwiązań nie ufamy temu, iż na świecie od lat pracuje się jakimiś metodami, czy wykorzystuje określone narzędzia. A przecież dość oczywistym jest fakt, iż w gospodarkach znajdujących się na wyższym poziomie rozwoju, w których dysponuje się większymi budżetami, ale też i konkurencja jest ostrzejsza, szybciej próbuje się adaptować nowe technologie. Czekamy na sukcesy krajowych wdrożeń owych sprawdzonych już na świecie podejść i narzędzi, a tymczasem świat ucieka nam do przodu. Na własne życzenie czekamy, aż ktoś nas wyprzedzi.

Sprawdzajmy więc to, co jest dostępne w ramach szeroko pojętego podejścia procesowego. Dostępne na świecie, a nie tylko w okolicznych województwach. Oceniajmy dostępne rozwiązania i nie bójmy się eksperymentować; wybierajmy konferencje, które nie noszą znamion wydarzenia marketingowego (często marka organizatora wskazuje na charakter konferencji); czytajmy uznaną literaturę branżową i na niej starajmy się wyrabiać swoją opinię. Przy takim podejściu do wdrażania nowych myśli i technologii mamy szansę na rzeczywiste usprawnienia i czerpanie garściami korzyści, jakie daje dobrze wdrożony pomysł. A mamy z czego wybierać, co starałem się pokazać powyżej.

—