Wprowadzenie

Artykuł prezentuje doświadczenia w zakresie integracji adaptacyjnych metod zarządzania projektami oraz płaszczyzny zarządzania procesami biznesowymi w organizacji gospodarczej w oparciu o studium przypadku firmy SESCOM S.A. z Gdańska. Celem opracowania jest formalizacja autorskiego modelu ABPM (Agile Business Process Management), który ma służyć ukierunkowaniu statycznych organizacji procesowych na budowanie adaptacyjnych, minimalistycznych modeli procesowych z uwzględnieniem zwinnych metod rozwoju oprogramowania workflow oraz długookresowych cykli życia infrastruktury procesowo-informatycznej. W artykule zaproponowano obszary implementacji elementów metodologii zwinnych w klasycznym cyklu Deminga oraz podsumowano doświadczenia dotyczące roli kapitału ludzkiego w realizacji strategii biznesowej zgodnie z modelem ABPM.

Agile - istota i zastosowanie

Podejście Agile zakorzeniło się na stałe w wielu organizacjach gospodarczych i należy do najbardziej docenianych przez nowoczesnych menadżerów koncepcji zarządzania projektami. Określane często w języku polskim jako zwinne lub adaptacyjne, podejścia z zakresu agile stanowią zestaw technik rozwoju produktu zorientowanych na osiągnięcie wysokiego poziomu jakości, satysfakcję klienta oraz dostarczanie produktu z zachowaniem ograniczeń czasowych oraz budżetowych¹. Filozofia metodyk zwinnych zakłada odejście od tradycyjnego planowania i precyzyjnego ustalania celów w projektach wytwórczych na rzecz stworzenia wizji produktu, która wyostrza się w trakcie kolejnych iteracji. Na potrzeby niniejszego artykułu zbiór podejść i metodyk adaptacyjnego zarządzania projektami zostanie uogólniony pod akronimem AZP. Najbardziej popularne metodyki adaptacyjnego zarządzania projektami to:

• Adaptive Software Development (ASD) ²,
• Agile Modeling³,
• Dynamic Systems Development Method (DSDM)⁴ oraz bazująca na niej metodyka Agile Project Management (AgilePM)⁵,
• Extreme Programming (XP) ⁶,
• Feature-Driven Development (FDD) ⁷,
• Kanban⁸,
• Lean Software Development⁹,
• rodzina metodyk Crystal¹⁰,
• SCRUM¹¹.

Manifest Agile¹², stanowiący teoretyczną referencję poszczególnych metodyk, zakłada adaptacyjny styl pracy, zorientowany na dostarczenie wartości biznesowych przy ścisłej współpracy zespołu projektowego z klientem. W AZP podkreśla się wagę spotkań zespołu z interesariuszami służących ciągłej weryfikacji i adaptacji wytwarzanych funkcjonalności, aczkolwiek odstępy czasowe pomiędzy tymi spotkaniami nie są przez metodyki narzucane. Generalnie przyjmuje się, że czas iteracji jest pochodną zasad współpracy zespołu projektowego z klientem, przy czym nie powinien on przekraczać 30 dni¹³. W praktyce czas trwania iteracji może być wyrażony w dniach lub pojedynczych tygodniach, ale musi być ona zorientowana na dostarczenie założonej funkcjonalności wytwarzanego produktu.

O adaptacyjnym lub zwinnym zarządzaniu mówi się przy okazji projektów wytwórczych, które zostały uruchomione w celu stworzenia produktu o charakterze innowacyjnym. Najwięcej artykułów, studiów przypadku i publikacji łączy to podejście z wytwarzaniem oprogramowania, a także z projektowaniem i wytwarzaniem sprzętu komputerowego, nowoczesnych środków transportu czy innych przedmiotów powszechnego użytku. Jego zaletą jest bez wątpienia możliwość dostosowania procesu rozwoju projektu do uwarunkowań i kultury danej organizacji gospodarczej, w której zdecydowano się na zwinne zarządzanie projektami.

O ile zrozumiała jest intensyfikacja wysiłku badawczego w kontekście projektów, których sukces opiera się na zwinnym podejściu do zarządzania, o tyle istotne wydaje się rozstrzygnięcie kwestii, czy AZP można wykorzystać wyłącznie do zarządzania projektami wytwórczymi - czy też przeniesienie zwinnych praktyk do innych obszarów biznesu i za ich pomocą zarządzanie czymś więcej niż tylko projektami rokuje sukces? A gdyby zacząć adaptacyjnie zarządzać procesami biznesowymi w organizacji gospodarczej?

Niniejszy artykuł stanowi próbę harmonijnej integracji doświadczeń procesowych i sukcesów metodyk adaptacyjnych. O ile nie można odmówić przewagi klasycznych metod - bazujących na kaskadowym cyklu życia - nad zwinnymi metodami zarządzania w projektach o charakterze statycznym¹⁴, o tyle praktyka wykorzystania AZP wskazuje, że konsekwentnie przejmuje ono rynek metod klasycznych, a jego wdrożenie w ocenie niemal 87 proc. organizacji gospodarczych przyczynia się do wzrostu zysków¹⁵. Wykorzystanie zalet metodyk zwinnych wydaje się zasadne o tyle, że przyczyn licznych porażek inicjatyw udoskonalania procesów należy doszukiwać się w technicznym realizowaniu działań optymalizacyjnych w ramach BPM (Business Process Management) zgodnie z dorobkiem metodyk klasycznych. Tym samym w literaturze podejmuje się pierwsze próby uzyskania synergii AZP i BPM¹⁶ .

Zarządzanie procesami biznesowymi w XXI wieku

Tematyka zarządzania procesami biznesowymi doczekała się kompleksowej eksploracji zarówno w literaturze, jak i w praktyce. Pierwsze rozważania w tym zakresie pojawiły się już kilkadziesiąt lat temu - gdy wykonywaną pracę zaczęto postrzegać jako działania wieloetapowe, realizowane przez różne zasoby, za pomocą różnych narzędzi i w różnych miejscach. W obszarach ciągłego podnoszenia jakości wyrobów i usług powstało wiele metod, których zastosowanie jest czasami uwarunkowane specyfiką obszaru biznesowego (np. produkcja), częściej jednak ma charakter uniwersalny. W procesach wytwórczych do analizy przyczyn i skutków powstających wad można zastosować metodę FMEA (Failure Mode and Effect Analysis), której celem jest dostarczanie rozwiązań prewencyjnych lub korygujących z uwzględnieniem krytyczności niedomagań. Szersze zastosowanie biznesowe ma metoda Kaizen, która dotyczy nie tylko poprawy jakości usług, produktów czy pracy -skupia się także na wdrożeniu stylu życia, w którym pracownicy dążą do doskonałości poprzez uruchamianie procesów myślowych, ciągłe korygowanie błędów, odrzucanie ograniczających pracę wątpliwości na rzecz twórczego wykorzystania intelektu i prostoty działania. Wszystkie metody poprawy jakości wyrobów, usług i pracy wpisują się w koncepcję szczupłego zarządzania przedsiębiorstwem (Lean Management), której korzeni należy doszukiwać się w praktykach Toyota Motor Corporation. Opracowany i wdrożony w Toyocie „odchudzony” system wytwórczy dał możliwość dostarczania klientom produktów o wymaganej przez nich jakości, przy równoczesnej redukcji ludzkiego wysiłku i skróceniu czasu trwania etapów produkcji.

Procesom wytwórczym towarzyszą przepływy pracy (np. pomiędzy działami), a także obieg dokumentów i informacji, które - z uwagi na złożoność - wymagają kontroli, zarządzania i ciągłej poprawy. Autorem jednej z częściej wybieranych metod zarządzania procesami w organizacji gospodarczej był amerykański statystyk Edwards Deming, który opisał cykliczność życia procesów biznesowych. Cykl Deminga (nazywany też cyklem PDCA albo kołem Deminga) zilustrowano na rys. 1 w postaci diagramu maszyny stanowej UML¹⁷.

Mimo że cykl ten jest koncepcją biznesową sprzed wielu lat, współczesna interpretacja nawiązuje do przemyśleń twórcy; natomiast praktyczna jej realizacja opiera się na osiągnięciach informatyki, które wykraczają poza oryginalne rozważania E. Deminga¹⁸.

Zgodnie z modelem ujętym na rys. 1 zarządzanie procesami biznesowymi w organizacji gospodarczej rozpoczyna się od fazy planowania (plan), tj. wskazania obszarów występowania procesów biznesowych w organizacji gospodarczej, a następnie zdefiniowania tych procesów. Współcześnie modelowanie procesów biznesowych wykonuje się w dedykowanych środowiskach informatycznych za pomocą wyspecjalizowanych notacji, spośród których najpoważniejszym kandydatem do przyjęcia roli zunifikowanego standardu¹⁹ jest notacja BPMN (Business Proces Model and Notation)²⁰. Na tym etapie zarządzania procesami projektuje się również wskaźniki KPI (Key Performance Indicators), które mają charakter liczbowy bądź czasowy i służą do bieżącego monitorowania procesów.

Kolejna faza w cyklu Deminga - faza realizacji (do) - obejmuje wykonywanie poszczególnych czynności procesowych składających się na proces biznesowy. Współcześnie realizacja procesów biznesowych jest wspierana przez systemy informatyczne workflow, które są często zintegrowane z innymi aplikacjami - np. ERP, CRM. Coraz częściej komercyjne uruchomienie procesu biznesowego jest poprzedzone wykonaniem symulacji komputerowej jego modelu, co umożliwia np. identyfikację błędów logicznych w definicji procesu. Przy odpowiedniej parametryzacji tego modelu można podjąć próbę oszacowania zapotrzebowania na personel czy też czasu trwania i kosztów realizacji procesu²¹.

Faza trzecia dotyczy weryfikacji (check) wykonywanych procesów biznesowych. Do najbardziej popularnych technik monitorujących należą pomiary wartości wskaźników procesowych KPI i odnoszenie ich do wartości teoretycznych, które oszacowano na etapie projektowania procesu. Nowoczesne organizacje wprowadzają dodatkowe mechanizmy kontrolne i analityczne, które są implementowane w systemie workflow albo stanowią oddzielne aplikacje, zasilane danymi z wykonywanych procesów (z bazy danych systemu workflow). Do takich mechanizmów można zaliczyć data mining i process mining, które umożliwiają odkrycie cennych informacji o procesach - a także uchwycenie tendencji i korelacji w działaniach firmy, których oszacowanie za pomocą tradycyjnych wskaźników KPI nie jest możliwe.

Ostatni etap w cyklu Deminga - tj. udoskonalanie (act) - odnosi się do poprawy definicji procesów biznesowych opartej na analizie danych - pozyskanych zarówno z systemów informatycznych nadzorujących pracę, jak i z innych źródeł, takich jak uwagi uczestników procesów czy sugestie właścicieli biznesowych i interesariuszy. Jednakże głównym celem wprowadzania poprawek, nowych pomysłów i rozwiązań oraz modyfikacji w procesach powinno być zwiększenie poziomu zadowolenia klienta pośrednio lub bezpośrednio pozyskującego z tych procesów wartości (towary, usługi), za które jest gotowy zapłacić.

Wiele współczesnych przedsiębiorstw próbuje działać według cyklu PDCA. Słowa uznania należą się tym organizacjom gospodarczym, które potrafią domknąć i iteracyjnie uruchamiać koło Deminga, co oznacza chęć rozwoju, analizowanie własnych działań oraz poszukiwanie rozwiązań usprawniających procesy i biznes jako całość. Znaczące możliwości w tym zakresie oferują systemy informatyczne, których producenci dostarczają już kompleksowe, rozbudowane środowiska zapewniające wsparcie na wszystkich etapach zarządzania procesami. Ale cykliczne podejście do procesów - choć w niektórych organizacjach stanowiące nadal odległy cel - nie jest już obecnie czymś innowacyjnym. Co więcej, we współczesnych organizacjach gospodarczych statyczne zarządzanie procesowe charakteryzuje się zbyt wysokim poziomem bezwładności, aby wyjść naprzeciw bieżącym wymaganiom biznesowym i optymalizować procesy biznesowe pod kątem indywidualnych potrzeb klienta²². Tak jak kilkanaście lat temu informatyzacja spowodowała istotny rozwój PDCA, tak dzisiaj należałoby postawić kolejny krok w zarządzaniu procesami i wprowadzić innowacje w tej dziedzinie, zapewniając tym samym organizacji gospodarczej przewagę konkurencyjną na kilka kolejnych lat.

Model adaptacyjnego zarządzania projektami

Adaptacyjne zarządzanie projektami jest zbiorem zasad, wartości i praktyk, które pozwalają zespołom projektowym zmierzyć się z ambitnymi wyzwaniami²³. AZP sprawdza się tam, gdzie trzeba tworzyć elastyczne, innowacyjne produkty - a zespoły wytwórcze są zdolne do adaptacji i zmian. Skupia się na wykonaniu - nie na planowaniu i kontroli. Błędne byłoby jednak wnioskowanie, że AZP to całkowite oddanie projektu w ręce zespołu i stuprocentowa pewność, że innowacyjny produkt zostanie stworzony. AZP, podobnie jak BPM, funkcjonuje bowiem w pewnych ramach organizacyjnych, co zostało ujęte na rys. 2 w modelu adaptacyjnego zarządzania projektami.

Struktura modelu AZP powstała w oparciu o adaptacyjne wytwarzanie oprogramowania, co prawdopodobnie powoduje automatyczne kojarzenie pojęcia Agile z projektami informatycznymi. W schemacie koncepcyjnym cykl życia projektu składa się z pięciu faz. Pierwszą z nich jest tworzenie wizji produktu i koncepcji biznesowej, która obejmuje wysokopoziomową identyfikację tego, co i w jaki sposób ma wytworzyć zespół projektowy. Co charakterystyczne, pierwsza faza AZP obejmuje także kompletowanie składu zespołu projektowego, studia przypadków „zwinnych” projektów ujawniają bowiem, iż nie każdy człowiek posiada predyspozycje do pracy w adaptacyjnych warunkach.

Kolejna faza w modelu AZP dotyczy adaptacyjnego planowania, na które składają się takie elementy, jak zebranie wstępnych wymagań produktu, utworzenie listy dostarczanych funkcjonalności, a także analiza ryzyka i oszacowanie kosztów. Na tym etapie zespół produkcyjny nakreśla harmonogram działań, który nie jest zorientowany wyłącznie na terminowe oddanie gotowego produktu, ale opiera się na dopasowaniu liczby i częstotliwości iteracji do dostarczanych funkcjonalności. Z kolei trzecia faza - eksploracji - to iteracyjne dostarczanie docelowej funkcjonalności produktu. Jego ewolucja pokrywa się z ewolucją zespołu projektowego, który staje się współpracującą, samoorganizującą się społecznością projektową. Istotnym elementem tej fazy jest zarządzanie relacjami pomiędzy klientami, kierownikami produktu oraz innymi interesariuszami.

W fazie adaptacji następuje przegląd dostarczonych funkcjonalności. Klient, po intensywnej fazie eksploracji, korzysta już z wielu wypracowanych funkcjonalności, a więc jego wiedza o zamówionym produkcie rośnie. Równocześnie wyniki eksploracji są analizowane i oceniane pod kątem technicznym, a także weryfikowane od strony biznesowego uzasadnienia projektu. Działania adaptacyjne i pozyskana w nich wiedza zostają wbudowane w kolejną iterację prac, a nowe informacje powodują okresowe powracanie do etapu tworzenia wizji w celu jej wyostrzenia i doprecyzowania.

Każdy adaptacyjny projekt powinien zostać w sposób świadomy zakończony, co oznacza dotarcie do ostatniej fazy cyklu AZP. Jest to często najtrudniejszy etap działań projektowych, ponieważ może być znacznie oddalony w czasie od inicjacji projektu - a także, z punktu widzenia klienta, może być po prostu niezrozumiały. Warto sobie uświadomić, że projekt ma określony czas życia, natomiast gotowy produkt (np. oprogramowanie) może wymagać dalszego rozwijania i udoskonalania. Niemniej AZP określa zakończenie projektu jako etap finalizacji dokumentacji, archiwizacji kodu oraz innych działań o charakterze porządkowym. Zamykanie projektów jest dobrą praktyką, która nie kończy dalszych prac nad produktem, z założenia adaptacyjnym, ponieważ wypracowane na daną chwilę funkcjonalności mogą w nawet niedalekiej przyszłości wymagać zasadniczego rozbudowania bądź modyfikacji, bo zmieni się otoczenie biznesowe - a tym samym zmianie ulegnie początkowa wizja.

Adaptacyjne praktyki zarządzania projektami a płaszczyzna procesów biznesowych

Przedstawione powyżej charakterystyki cyklu Deminga oraz modelu AZP stanowią selektywny wycinek rozległej wiedzy z tych obszarów. Niemniej przywołanie charakterystyki obu modeli jest niezbędne do zdefiniowania wzajemnych relacji pomiędzy nimi. W tym miejscu warto odnieść się do przykładu Grupy Allegro, która stosując zwinną metodykę zarządzania projektem, dokonała migracji infrastruktury IT z serwerowni w Niemczech do Polski²⁴. Projekt był realizowany na bazie zwinnych metodyk, czyli w formie krótkich iteracji, w które wbudowano cykle PDCA. W projekcie migracji infrastruktury IT taka relacja pomiędzy AZP i PDCA zdała egzamin, o czym świadczy rekordowo krótki czas przeniesienia sprzętu. Trzeba jednak zauważyć, że sam charakter przywołanego projektu Grupy Allegro, realizowanego w iteracjach z zachowaniem cyklu plan-do-check-act, umożliwiał zachowanie krótkich interwałów pomiędzy poszczególnymi fazami koła Deminga. W praktyce w terminie kwartalnym - taki okres Grupa Allegro przewidziała na migrację serwerowni - cykl PDCA zrealizowano wielokrotnie (w szczególnych przypadkach realizacja takiego cyklu może przypadać nawet kilka razy w ciągu pojedynczego dnia). Zakres i dynamika projektu były tak duże, że poszczególne fazy przebiegały niezwykle szybko z uwagi na fakt, iż organizacja nie dysponowała komfortowymi rezerwami czasowymi na szczegółowe (a tym samym długotrwałe) analizy zasadności wdrożenia w praktyce i walorów poszczególnych pomysłów. Zmiany musiały zachodzić błyskawicznie i zwinnie, bo ramy czasowe projektu były nadzwyczaj niekorzystne.

Sukces przywoływanego projektu Grupy Allegro stanowi argument za skutecznością wbudowania cykli PDCA w zwinne iteracje z AZP. Wyzwaniem o innej skali jest włączenie w obszar zainteresowania organizacji gospodarczej - równolegle do projektów - zarządzania procesami biznesowymi, w tym procesami stanowiącymi podstawowy obszar działalności (core business) tej organizacji. Przykładem tego typu organizacji procesowej jest firma SESCOM S.A. z Gdańska, świadcząca usługi dla klientów w różnych krajach i branżach. Każdego dnia obsługiwanych jest przez nią kilkaset instancji procesów biznesowych, związanych z usuwaniem awarii sprzętu klienta, wykonywaniem audytów, przeglądów i zleceń inwestycyjnych oraz obsługą logistyki.

W celu efektywnej realizacji przepływów pracy SESCOM konsekwentnie rozwija własny system informatyczny klasy workflow o nazwie Platforma SES Support. W miarę ciągłego doskonalenia tego narzędzia wykształciła się jego nadrzędna funkcjonalność, służąca wsparciu interakcji klienta z organizacją gospodarczą. W szczególności dotyczy to zlecania wykonania działań, śledzenia postępów prac i pozyskiwania informacji raportowych, np. o liczbie zgłoszeń czy kosztach oraz czasach realizacji zgłoszeń. Tym samym SES Support stał się ważnym mechanizmem kreowania dobrych relacji z klientem, który - charakteryzując się określoną specyfiką zachowania w zakresie elektronicznych form kontaktu (a tym samym generując nowe wymagania systemowe i stymulując kierunki rozwoju) - stał się jednoczenie współtwórcą tego systemu. Co więcej, sugestie i wymagania poszczególnych klientów zaczęły wpływać na sposób zarządzania procesami biznesowymi w SESCOM, stając się najważniejszym bodźcem zarówno w tworzeniu relacji firma-klient, jak i w organizacji pracy w jej ramach.

Intensywny wzrost potrzeb klientów firmy SESCOM odnotowany w latach 2011-2013, a także rozwój branż znajdujących się w obszarze zainteresowania organizacji i wydłużenie listy świadczonych usług spowodowały konieczność przeprowadzenia gruntownej zmiany w zarządzaniu procesami biznesowymi. Zmiana ta musiała być wsparta zasadniczą przebudową systemu informatycznego - po to, aby zarówno sam system, jak i obsługiwane przez niego procesy biznesowe były przygotowane na zmiany zachodzące w organizacji biznesowej i jej otoczeniu. Nawiązując do przywołanych wcześniej modeli, warto zauważyć, że w SESCOM nową edycję informatycznego systemu wsparcia można zrealizować bezpośrednio, z wykorzystaniem wybranej metodyki z rodziny AZP, jednakże tego typu projekt ma istotny wpływ na zarządzanie procesami biznesowymi w firmie. Inaczej niż to zakłada metoda Grupy Allegro, w przypadku firm działających w oparciu o przepływy pracy, dokumentów i informacji zarządzanie procesami (BPM) stanowi wyższą warstwę niż zarządzanie projektami - firma taka koncentruje się przede wszystkim na procesowym aspekcie funkcjonowania. Wynika to z kształtu podstawowego obszaru działalności oraz roli projektów w tego typu organizacjach jako spójnych zbiorów działań, prowadzących do usprawniania procesów biznesowych. Z kolei w organizacjach, w których projekty stanowią istotną (albo główną) gałąź biznesu firmy i nie są prowadzone wyłącznie w celu poprawy przepływów pracy, zwinne zarządzanie projektami (AZP) może być nadrzędne względem procesów, które są sprowadzane w takiej konfiguracji do roli narzędzia służącego realizacji i śledzeniu etapów projektów.

Pojawia się w tym momencie pytanie, jak wygląda relacja pomiędzy cyklem Deminga a modelem AZP w przypadku organizacji gospodarczych, które muszą działać zwinnie, a jednocześnie procesowo, i dla których właśnie procesy stanowią podstawowy obszar działalności. Krokiem w kierunku rozstrzygnięcia tej kwestii jest autorski model zarządzania współczesną firmą, zastosowany w firmie SESCOM. Integrację AZP z BPM w tej organizacji gospodarczej oparto na trzech podstawowych filarach:

1. zaprojektowanie i wdrożenie systemu informatycznego, który będzie wspierał procesy biznesowe w organizacji gospodarczej;
2. zaprojektowanie i wdrożenie procesów biznesowych, które będą realizowane przez ten system;
3. zaprojektowanie mechanizmów adaptacji procesów oraz systemu do zmian zachodzących w biznesie i jego otoczeniu, z zachowaniem reguły świadczenia usług na jak najwyższym poziomie niezależnie od dynamiki rozwoju organizacji gospodarczej.

Włączenie AZP do opracowania nowej edycji systemu SES Support wydaje się rzeczą naturalną. Niemniej, zgodnie z założeniem AZP (rys. 2), projekt tworzenia systemu musi zostać zamknięty (faza nr 5). Sam produkt, jak i procesy biznesowe będą natomiast dalej rozwijane - po to, aby reagować na dynamikę otoczenia biznesowego i adaptować się do rozwoju firmy oraz - co najważniejsze - spełniać rosnące wymagania klientów. Można więc stwierdzić, że po zamknięciu projektu informatycznego dostarczenia SES Support model AZP nie będzie już obowiązywał w swojej pięciofazowej formie. Pozostaną natomiast w użyciu techniki zwinne, których wykorzystanie w dalszych fazach cyklu zarządzania procesami zapewni elastyczność i adaptacyjność modelu BPM. Rysunek 3 ilustruje propozycję połączenia AZP z BPM w autorski model ABPM (Agile Business Process Management).

Na rys. 3 założono, że zagnieżdżony model AZP jest przeprowadzany systematycznie w swoich pięciu fazach i jednocześnie przebywa drogę w ramach BPM od planowania (plan) do realizacji (do). Ten etap zarządzania procesami w firmie odnosi się do tworzenia innowacyjnego produktu biznesowego, jakim są procesy, koncepcje, założenia oraz system wspierający pracę wraz z peryferyjnymi aplikacjami. W trakcie realizacji tych działań nie przewiduje się długookresowego obserwowania procesów biznesowych i formułowania wniosków, które wpłynęłyby na ich poprawę i ulepszenie wspierającego je produktu IT. Z kolei w ramach poszczególnych faz obowiązują iteracje, w których dostarczone funkcjonalności są testowane i konsultowane, a następne poddawane niezbędnym adaptacjom. W momencie gdy model AZP osiągnie fazę zamknięcia (praktyki biznesowe organizacji przewidują formalne zakończenie każdego projektu), model BPM przejdzie do fazy realizacji. Należy przy tym zaznaczyć, iż w przypadku podmiotów realizujących projekty IT w oparciu o przyrosty (z niezależną budową i zamknięciem każdego indywidualnego przyrostu) należałoby rozważyć domknięcie cyklu AZP.

W fazie realizacji cyklu ABPM komercyjne uruchomienie procesów nie sprzyja przeprowadzaniu ich zasadniczych redefinicji - tak samo jak niekorzystne z punktu widzenia operacyjnego działania organizacji jest daleko idące przebudowywanie funkcjonalności oprogramowania workflow. Naturalnie bieżące wprowadzanie niezbędnych poprawek w procesach i w infrastrukturze IT jest jak najbardziej wskazane, ale wpływ modyfikacji i samego procesu ich wdrażania na organizację (w szczególnych przypadkach wiążącego się z przerwami w działaniu firmy) implikuje ograniczenie liczby ingerencji w definicje procesów i aplikacje do niezbędnego minimum.

Kolejna faza w modelu ABPM dotyczy weryfikacji (check) tego, w jaki sposób procesy i systemy obsługują przepływy pracy w firmie. Wypracowane wnioski (act) bezpośrednio prowadzą do stworzenia rozwiązań, które w fazie planowania kolejnego cyklu są wprowadzane w życie i tym samym udoskonalają funkcjonowanie organizacji gospodarczej.

Zaprezentowany syntetyczny opis kompletnego cyklu w oparciu o model ABPM może wzbudzić kontrowersje, istotą technik adaptacyjnych jest bowiem ciągłe dostosowywanie procesów i systemu workflow do bieżących potrzeb biznesowych przy osiąganiu kolejnych faz - realizacji, weryfikacji i udoskonalania. Po co więc ponownie osiągać fazę planowania, skoro wartość dodana jest osiągana w sposób ciągły we wcześniejszych fazach ABPM, opartych na wyostrzaniu biznesowej wizji i na zwinnych technikach Agile? Odpowiedzi na to pytanie dostarczyło studium przypadku firmy SESCOM. Realizacja ostatniego, pełnego cyklu, powiązana z adaptacją procesów i systemu SES Support do rosnących wymagań biznesowych rozciągała się na przestrzeni 5 lat. Dynamika rozwoju organizacji zaczęła obejmować usługi w nowych krajach, w konsekwencji tworzenie kolejnych spółek za granicą, rozbudowanie katalogu usług i branż, a także powstanie nowych ról procesowych w organizacji gospodarczej. Procesy i systemy adaptowano na bieżąco do tych zmian. Osiągane efekty zaspokajały bieżące potrzeby biznesowe, jednakże w długim okresie architektura systemu SES Support zaczęła ulegać degradacji. Podlegająca ciągłej rozbudowie baza danych zaczęła z czasem sprawiać programistom SESCOM dodatkowe problemy, a kod systemu w wyniku dodawania kolejnych funkcji, procedur, parametrów i reguł biznesowych zaczął tracić swoje walory w zakresie utrzymania. W konsekwencji od pewnego momentu wykonywanie kolejnych adaptacji stało się uciążliwe, pracochłonne i ryzykowne. Zarząd spółki podjął więc decyzję, aby dotychczas stosowaną wersję SES Support zastąpić całkowicie nowym produktem, który uwzględni dotychczasowe rozwiązania, wiedzę i efekty licznych iteracji udoskonaleń, lecz dodatkowo uwzględni też najnowocześniejsze technologie i w przyszłości umożliwi bardziej efektywną adaptację do powstających potrzeb. Tym samym decyzja zarządu o gruntownym odświeżeniu definicji procesów oraz systemu SES Support oznacza domknięcie koła Deminga i ponowne zainicjowanie fazy planowania.

Nakreślając relacje pomiędzy AZP a BPM, należy zaznaczyć, że - w zależności od charakteru projektu oraz od modelu biznesowego danej organizacji - mogą one przybierać różne formy. Gdy projekt jest dynamiczny (co miało miejsce w przypadku migracji infrastruktury IT w ramach Grupy Allegro), wnioskowanie i poprawa działań muszą następować w bardzo krótkich cyklach. Natomiast gdy rdzeniem biznesu są procesy wspierane systemem workflow, wówczas gruntowne poprawy, udoskonalenia i adaptacje tych procesów (i w konsekwencji - systemu) nie mogą zachodzić zbyt często i w krótkich iteracjach, bo mogłoby to odbić się niekorzystnie na jakości świadczonych usług. W takim przypadku dorobek z zakresu AZP musi zostać efektywnie wykorzystany na etapie przejścia pomiędzy projektowaniem i realizacją procesów, gdyż przyszłe gruntowne modyfikacje będą mogły zostać wdrożone dopiero po jakimś czasie.

Przeprowadzona powyżej analiza oraz zaproponowany model ABPM pozwalają zdefiniować relacje zachodzące pomiędzy zwinnym zarządzaniem projektami a zarządzaniem procesami biznesowymi z wykorzystaniem technik Agile. W dalszej części artykułu ujęto rekomendacje w zakresie wykorzystania zwinnych technik AZP we wszystkich fazach cyklu ABPM.

Faza planowania - zwinne projektowanie procesów biznesowych

W tradycyjnym podejściu do zarządzania procesami biznesowymi faza planowania skupia się na zaprojektowaniu procesów biznesowych dla przedsiębiorstwa. Jeśli organizacja gospodarcza nie jest właśnie zakładana i działa już komercyjnie na rynku, wówczas faza ta skupia się na identyfikacji procesów i ich wizualizacji - zazwyczaj za pomocą graficznych paradygmatów modelowych, wzbogaconych dodatkowym opisem słownym. Ponieważ procesy biznesowe są współcześnie realizowane za pomocą systemów workflow, w fazie planowania system tej klasy jest dla danych procesów tworzony od podstaw lub powstaje na bazie produktu uniwersalnego, wymagającego adaptacji do potrzeb danej organizacji gospodarczej. W dużych korporacjach etap planowania pochłania znaczne zasoby finansowe i czas pracy wielu osób (analityków, programistów, kierowników i przyszłych użytkowników systemu), stąd zakłada się, że efekt końcowy będzie charakteryzował się wysoką szczegółowością i jakością w momencie zamknięcia fazy planowania. Efekt taki da się osiągnąć, jest on jednak adekwatny tylko na dany moment funkcjonowania organizacji - a z uwagi na zmienność otoczenia to, co dziś napędza biznes, jutro może stać się dla niego hamulcem.

W adaptacyjnej fazie planowania zwinne powinno być projektowanie procesów, projektowanie i wytwarzanie systemu workflow, a na dodatek oba te produkty powinny być także adaptacyjne. Oczywiście bezcelowe jest uchylanie się przed opracowaniem harmonogramów i budżetu dla procesowego projektu, warto natomiast ograniczyć dyskusje na ten temat, bo późno osiągnięty kompromis może stać się ograniczeniem i - konsekwentnie - przyjętym celem, zabijając tym samym ducha zwinności i innowacji w zespole projektowym. Jeśli chodzi o wytwarzanie oprogramowania workflow, rozwijanie wykorzystania technik AZP w tym kontekście wydaje się nadmiarowe, gdyż setki przykładów działania zgodnego z filozofią Agile dotyczą właśnie budowania aplikacji. Ale co z procesami biznesowymi? Jak mówić o zwinnym tworzeniu procesów, skoro mogą one dotyczyć powtarzającej się produkcji albo wykonywania innych, powtarzalnych zadań? W tym momencie warto przytoczyć założenia AZP: celem nadrzędnym w biznesie powinno być dostarczenie wartości klientowi zarówno dzisiaj, jak i jutro. Stąd procesy biznesowe muszą być przygotowane na zmiany, na jakie może natrafić nawet preskryptywny biznes.

Procesy powtarzalne opierają się na specyfikacji i podlegają ścisłej kontroli, jednakże ulegają degradacji w warunkach niepewności. Można napotkać stwierdzenia, że strukturalne, sztywno zaprojektowane i mocno kontrolowane procesy stanowią antidotum na brak ponadstandardowych umiejętności pracowników. Jednakże w obrazie całościowym umyka aspekt innowacji, oportunistycznych propozycji i ulepszeń - charakterystycznych dla organizacji na najwyższych poziomach dojrzałości procesowej. Jak w takim razie powinna wyglądać adaptacyjna faza planowania procesów biznesowych? Można wyjść od stwierdzenia, że zwinność to wyważenie proporcji pomiędzy stabilnością a elastycznością - czyli umiejętność oszacowania, co należy utrzymać w stabilności, a co może się zmieniać. Projektując zwinne procesy biznesowe, trzeba mieć wizję tego, w jakim celu są one uruchamiane. Następnie identyfikuje się uczestników procesów i inne zasoby wykonujące czynności, a także określa przetwarzane dokumenty, wywoływane aplikacje, potencjalne ryzyka. Ramy takiego procesu muszą być jasno nakreślone, ale łatwe do adaptacji. Projektując przepływ pracy, należy wyeliminować rozbudowaną dokumentację formalną, a w jej miejsce wprowadzić dokumenty i notatki tymczasowe, które zmieniają się w miarę kolejnych iteracji projektu. Istotne jest wykorzystanie narzędzi i formatów pozwalających na łatwą pielęgnowalność tej minimalistycznej dokumentacji. Myśląc o procesie, trzeba poszukiwać takiej jego formy, która będzie realizowała w przyszłości nawet najbardziej powtarzalne sekwencje zdarzeń, jednakże przy uwzględnieniu możliwości podjęcia niestandardowych działań. Porażką twórców modelu procesu jest późniejsze usilne omijanie jego formuły - co zazwyczaj nie jest wynikiem złej woli pracowników, ale koniecznością, dzięki której praca może być skuteczniej wykonywana. Gdy model procesu staje się przestarzały, pracownicy uruchamiają dodatkowe kanały komunikacji - takie jak poczta elektroniczna, telefony, coraz częstsze spotkania, dodatkowe specyfikacje, nieformalne schematy pracy. Można to traktować jako poszukiwanie rozwiązań, ale wartość tych działań nie buduje nowego produktu - są one ukierunkowane wyłącznie na zniwelowanie błędów bądź nieelastyczności w definicji procesu. Z punktu widzenia organizacji najistotniejszą kwestią problematyczną wynikającą z takich działań jest utracona wiedza o wykonywanej pracy, która - zamiast być automatycznie odzwierciedlana w bazie danych systemu workflow - jest przechowywana lokalnie na urządzeniach przenośnych pracowników, w ich głowach, a najczęściej po prostu się ulatnia. Zwinny proces biznesowy i adaptacyjna aplikacja workflow umożliwiają użytkownikom niestandardowe działania. Mogą to być funkcjonalności elektronicznych notatek do zdarzeń, alertów, powiadomień, funkcje czatu czy nawet możliwość uruchomienia własnego podprocesu ad hoc. Dobrym rozwiązaniem jest też zrównoleglenie niektórych działań procesowych, do których użytkownicy mają zawsze dostęp i które mogą modyfikować bez zbędnej zwłoki. Frustrujące jest bowiem oczekiwanie w sekwencji zadań na możliwość wykonania czynności procesowej, którą można by - z uwagi na dostępność danych wejściowych i sprzyjający układ zdarzeń - zrealizować na bieżąco. Jednocześnie pojawia się zagrożenie, że niektóre dane zostaną przeoczone podczas odroczonego wykonywania czynności. Tym samym zasadne jest takie zaprojektowanie procesu, aby jego definicja była zgodna z celem biznesowym i umożliwiała monitorowanie tego aspektu, ale - dzięki ograniczeniu liczby ścisłych sekwencji czynności - kolejność i kształt najbardziej podatnych na zmiany wycinków procesu została wykreowana przez użytkowników i ich bieżące potrzeby biznesowe.

W projektach o charakterze adaptacyjnym, takich jak definiowanie procesów i wytwarzanie wspierającego je systemu workflow, istotna jest rola „zwinnych” umiejętności menedżerskich osoby odpowiedzialnej za wytworzenie wizji produktu i prowadzenie zespołu do realizacji tej wizji. Pierwszym wyzwaniem jest wskrzeszenie w zespole ducha samoorganizacji i samodyscypliny pracowników. Następnie, mając świadomość budżetu i harmonogramu, należy być orędownikiem doskonałości technicznej, zachęcać do eksploracji, uczenia się, wprowadzania zmian - a przede wszystkim do dostarczania funkcjonalności. Pod koniec każdej iteracji należy odpowiedzieć sobie na pytanie, czy wygenerowane informacje i funkcjonalności są warte czasu i pieniędzy poświęconych na tę ostatnią iterację, co de facto prowadzi bezpośrednio do weryfikacji tego, czy projekt jest realizowany zgodnie z planem.

Faza realizacji - zwinne wykonywanie procesów biznesowych

W tradycyjnym zarządzaniu procesami biznesowymi zdefiniowane w fazie planowania przepływy pracy, dokumentów i informacji są implementowane w systemie workflow, a następnie organizacja zaczyna pracować zgodnie z ustalonymi zasadami. Projektanci sztywnych procesów żyją w przekonaniu, że pracę w firmie mogą wykonywać nawet mniej uzdolnione osoby, bo proces jest tak zaprojektowany, że cel procesowy i tak zostanie efektywnie osiągnięty. W odniesieniu do części modeli procesowych podejście takie sprawdza się, ale postrzeganie procesowości w kategoriach alternatywy dla umiejętności jest postrzeganiem naiwnym. Proces biznesowy jak najbardziej pomaga zorganizować pracę, ale nie powinien ograniczać zdolności i zdrowego rozsądku. Utalentowani pracownicy muszą mieć poczucie swobody w działaniach procesowych, ponieważ dzięki temu następuje ich rozwój. Nawet najlepszy proces nie zrekompensuje nieodpowiednego doboru zasobów ludzkich, bo adaptacyjność w prowadzeniu biznesu często wymaga odkrywania, eksploracji i eksperymentowania, a nie bezrefleksyjnego wykonywania planu. Zwinne podejście do realizacji pracy powinno całkowicie wyeliminować myślenie w kategoriach „to nietypowa kwestia, wiem, jak ją rozwiązać, ale system mi na to nie pozwoli”. Adaptacyjny proces i zwinny system workflow otwierają w tym momencie możliwości działania odbiegającego od reguły i ostatecznie pomyślnego wykonania zadania, przy równoczesnym wyciągnięciu cennych wniosków na przyszłość.

Zwolennicy sztywnych procesów twierdzą, że zwinne metody pozbawione są rygoru, że są niezdyscyplinowane - a przez to gorsze. Ale wystarczy przyjrzeć się najbliższemu otoczeniu biznesowemu i przeanalizować, jaka część procedur i procesów jest w codziennej pracy ignorowana oraz jakie są tego przyczyny. Doświadczenia związane z wykorzystaniem AZP wskazują, że w praktyce opracowanie mniej wyrafinowanych modeli procesowych - co umożliwia konsekwencję w ich realizowaniu - jest bardziej efektywnym sposobem postępowania. Skoro adaptacyjne zespoły projektowe mogą się samoorganizować, to zespoły procesowe również mogą mieć pewną decyzyjność w działaniu. Warto dodatkowo zauważyć, że w procesach biznesowych o nieprzejrzystej logice napotkane zawiłości potrafią sparaliżować nawet osoby ponadprzeciętnie uzdolnione, które w momencie zwątpienia mają tendencję do unikania podejmowania decyzji i mają opory, aby wskazać jakikolwiek kierunek działań. Lider projektu kierujący się zwinnym sposobem myślenia wspiera podjęcie decyzji w warunkach niepewności i jest za nią w pełni odpowiedzialny. Wysłany do współpracowników sygnał działania niesie w sobie informację, że pomimo wielu niejasności idziemy we wskazanym kierunku.

Faza weryfikacji - zwinna analiza procesów biznesowych

W działaniach o charakterze innowacyjnym - do których zaliczyć należy tworzenie oprogramowania - bieżące raportowanie projektu pozwala ustalić, czy projekt podąża w odpowiednim kierunku, oraz zapewnia klientowi podstawy oceny, czy za swoje pieniądze otrzymuje oczekiwaną wartość. W organizacji, której trzonem działania są powtarzalne procesy uzupełniane przez realizację innowacyjnych projektów, po fazach planowania i realizacji następuje weryfikacja sposobu działania organizacji (check). Weryfikacja nie jest naturalnie przeprowadzana poprzez nagłe wstrzymanie procesów biznesowych i zainicjowanie działań analitycznych. Pomiar pracy i monitorowanie wskaźników realizowane są na bieżąco, natomiast wolumen zebranych danych i informacji po pewnym okresie działania wystarczy do tego, aby wykonać gruntowną analizę i zakończyć ją wnioskami oraz zestawem rekomendacji.

Impulsem do uruchomienia fazy weryfikacji powinny być niepokojące sygnały, że bieżąca adaptacja procesów i systemu wymagają coraz większego wysiłku i niekoniecznie nadążają za kreowanymi przez biznes wymaganiami. Dodatkowo - pomimo wysiłku analityków, informatyków i innych uczestników procesów - spada jakość świadczonych usług, co można wywnioskować zarówno na podstawie obserwacji wewnętrznych w organizacji gospodarczej, jak i opinii klientów oraz kooperantów.

Wiele organizacji weryfikuje procesy biznesowe poprzez obserwację trendu w wartościach wskaźników KPI. Dodatkowo analizowane są statystyki ilościowe dotyczące wykonywanych zadań, a także zestawienia czasowe. Kombinacje raportów mogą być różnorodne i odnosić się do pojedynczych pracowników, zespołów procesowych, pojedynczych zadań czy też całych procesów biznesowych. Taka analiza jest niezwykle ważna, ponieważ dostarcza odpowiedzi na pytanie „co się dzieje w firmie?” Nadal jednak w cieniu pozostaje wiedza o charakterystyce kwestii problematycznych. Współczesną propozycją poszukiwania odpowiedzi w tym obszarze jest odkrywanie wiedzy o procesach biznesowych (process mining). Ta metoda analityczna w ostatnich latach wyszła poza ośrodki akademickie i zaczyna być powszechniej stosowana w komercyjnych narzędziach informatycznych. Odkrywanie wiedzy o procesach biznesowych polega na transformacji surowych danych do postaci użytecznych informacji, wykorzystywanych następnie do poprawy systemów i procesów, które te dane generują. Najcenniejszą wiedzę stanowią bowiem ukryte w strukturach danych wzorce, reguły, tendencje i korelacje, które w dłuższym okresie tworzą się samoczynnie podczas archiwizacji danych przez systemy informatyczne. Odkrycie tych nietrywialnych zależności pomiędzy atrybutami dostarcza unikalnej wiedzy o funkcjonowaniu przedsiębiorstwa, której uzyskanie jest nieosiągalne za pomocą tradycyjnych metod oceny procesów biznesowych.

W użytecznej analizie procesów istotne są ich adaptacyjne modele, które znacznie wykraczają ponad graficzny i słowny opis sekwencji wykonywanych czynności. Model musi uwzględniać adaptacyjne zachowanie organizacji, czynności niestandardowe, wspierać decyzyjność i umożliwiać kontaktowanie się w ramach procesu. Natomiast - niezależnie od sposobu wykonania pracy - punkty pomiarowe procesu pozwolą zarchiwizować informacje o podjętych przez pracowników działaniach. Nie ma oczywiście mowy o całkowitym kontrolowaniu poczty elektronicznej i rozmów telefonicznych, bo nie jest to w pełni możliwe ani też zasadne. Pozostaje także w sprzeczności z ideologią Agile. Informacje zapisywane przez system z właściwie zaprojektowanymi punktami pomiarowymi mogą być na tyle użyteczne, że nadmierne skupianie się na czynnościach pracowników nie ma najzwyczajniej sensu. Znajomość biznesu, jego użyteczna analiza i trafne wnioski to bezcenny materiał należący do organizacji, który zasila kolejną fazę w cyklu zarządzania procesami - udoskonalanie pracy.

Równocześnie z wykonywaniem analiz w fazie weryfikacji nie może zabraknąć informacji zwrotnych pochodzących od uczestników procesów, którzy najlepiej identyfikują przyczyny powstających problemów i czasami mają już opracowane propozycje rozwiązań. I właśnie te propozycje, których realizacja prawdopodobnie wykracza poza bieżącą adaptację, stanowią najcenniejszy materiał do gruntownej przebudowy procesów i systemu. Wyzwaniem dla kadry menadżerskiej jest pozyskanie rzetelnych informacji na temat przyczyn problemów, a także istniejących ograniczeń w ich rozwiązaniu oraz pomysłów na wyeliminowanie utrudnień. Wskazane są rozmowy z pracownikami, wywiady, ankiety, spotkania warsztatowe. Adaptacyjni i działający w oparciu o samodyscyplinę pracownicy chętnie dzielą się swoją wiedzą na temat źródeł problemów i sposobów ich eliminacji, o ile są w stanie dostrzec namacalne efekty ich spostrzeżeń w kolejnych iteracjach modeli procesowych bądź edycjach systemów IT. Natomiast zespoły, które działają, opierając się na konsekwentnym podnoszeniu wartości referencyjnych (niejednokrotnie do poziomów nieosiągalnych), mikrozarządzaniu, niejasnych celach, w nieprzyjaznych warunkach pracy, nie dość, że nie wniosą żadnej wiedzy służącej poprawie pracy, to dodatkowo mogą dostarczyć błędnych informacji - które jeszcze bardziej pogrążą system pracy i mogą doprowadzić do jego całkowitego upadku.

Faza udoskonalania - zwinna poprawa procesów biznesowych

Analizując przykłady działania wielu przedsiębiorstw, można stwierdzić, że niesprzyjająca sytuacja w organizacji gospodarczej skutkuje doraźnym zwoływaniem spotkań przez kadrę menedżerską, a następnie analizowaniem procesów, przeglądaniem raportów i stawianiem diagnozy dotyczącej przyczyn zaistniałych problemów. Towarzyszące temu emocje, a czasami także brak wiedzy o zarządzaniu procesami biznesowymi, prowadzą niejednokrotnie do wyolbrzymionych reakcji i gwałtownych działań, co paraliżuje pracę uczestników procesów i uniemożliwia efektywny pomiar wpływu wprowadzonych zmian. Oparty na cyklu Deminga model ABPM zakłada, że faza udoskonalania procesów biznesowych rozpoczyna się po fazie ich komercyjnej realizacji i weryfikacji. Nie należy jednak wnioskować, że wymienione fazy zarządzania procesami są całkowicie rozłączne czasowo. Nie da się bowiem w praktyce zatrzymać wykonywania procesów po to, aby dokonać ich poprawy i adaptacji do bieżących potrzeb. Skuteczność poprawy w procesach będzie tym większa, im więcej o tych procesach wiadomo, zarówno na podstawie wykonywania procesów, jak i ich użytecznej analizy w fazie weryfikacji.

W cyklu Deminga kwintesencją fazy udoskonalania są: poprawa sprawności procesów i redukcji kosztów oraz inne działania o charakterze optymalizacyjnym. Nawiązując do studium przypadku firmy SESCOM oraz do wypracowanego modelu ABPM, można stwierdzić, że faza udoskonalania nabrała w nim nieco odmiennego kształtu niż w źródłowym cyklu PDCA. Z uwagi na uwarunkowania biznesowe, które wykreowały się wraz z dynamicznym rozwojem organizacji gospodarczej, gruntowna poprawa procesów biznesowych bez przebudowy systemu informatycznego i bez wprowadzenia nowej wizji w zarządzaniu procesami została uznana za nieefektywną. Gdyby taka możliwość istniała, model ABPM uwzględniałby wprowadzenie zasadniczych działań usprawniających na jak najwcześniejszym etapie. Można nawet zaryzykować stwierdzenie, że to, co się dało adaptacyjnie usprawnić, zostało już usprawnione. Ostatecznie brak możliwości dalszej zwinnej adaptacji procesów i systemu postawił zarząd spółki przed koniecznością opracowania nowej strategii procesowej dla organizacji gospodarczej. Tak więc w fazie udoskonalania skupiono się na inkorporacji procesowych doświadczeń i rezultatów fazy weryfikacji do wizji nowego systemu SES Support, a także sprecyzowaniu uwarunkowań, w jakich miały powstawać i być wykonywane gruntownie przeprojektowane procesy biznesowe.

W modelu ABPM faza udoskonalania inicjuje przeglądowe prace nad procesami biznesowymi w organizacji. Planując istotne zmiany, warto pamiętać o kilku kwestiach, istotnych w kontekście kompleksowego udoskonalania procesów. Dużym błędem jest skupienie się na adaptacji konkretnego procesu (np. obsługa reklamacji), a całkowite pominięcie innych procesów i uwarunkowań biznesowych, które znajdują się w otoczeniu poddanego gruntownej przebudowie procesu. Jaki jest sens rozprawiać o wydłużonym czasie reakcji w obsłudze reklamacji, nie biorąc pod uwagę tego, co i jak się dzieje w powiązanych obszarach biznesowych? Czy przyczyną wydłużenia czasu obsługi reklamacji jest to, że osoba przyjmująca zgłoszenie długo wypełnia formularze, czy może to, że ktoś wcześniej nie dopełnił obowiązków i nienależycie przygotował jej warsztat pracy? A może trzeba przeanalizować proces przygotowania formularzy i bazy danych na potrzeby obsługi reklamacji? Może struktura bazy danych jest już nieadekwatna w kontekście rozwoju biznesu?

Pracując nad biznesowym i informatycznym aspektem procesów, trzeba pamiętać o tym, że wyostrzająca się wizja zmian istotnych dla wykonywanej pracy powinna bezwzględnie wiązać się z wymaganiami klienta. Każda adaptacja działań organizacji gospodarczej musi być wykonywana w świetle dostarczania klientowi produktów i usług szybciej, przy niższych kosztach, jednakże z zachowaniem doskonałości technicznej i przy spełnieniu zakontraktowanych mierników jakościowych. Adaptując procesy, warto dążyć do redukowania formalności oraz zmniejszać wolumen produkowanej i przetwarzanej dokumentacji. Podobnie jak w inicjującej model fazie planowania, w fazie udoskonalania sprawdzają się prototypowanie i wizualizacja, a także podpowiadanie klientowi rozwiązań, uświadamianie, a czasami sugerowanie pewnych decyzji.

Rozpatrując model ABPM w kontekście działalności firmy SESCOM, można zauważyć, że po pięciu latach realizacji cyklu BPM latem 2013 roku nastąpiło uruchomienie fazy udoskonalania, która na początku jesieni zamknęła koło cyklu i płynnie przeszła do fazy planowania w kolejnej iteracji BPM. Tym samym został zainicjowany projekt nowego systemu SES Support, zaczęły powstawać nowe wizje procesów, zaczęto testować nowe narzędzia i techniki analityczne, dokonano zmian w strukturze organizacji. Co istotniejsze, dzięki świadomej realizacji wcześniejszych faz cyklu, niezależnie od wprowadzania nowej strategii, organizacja płynnie wykonuje kontrakty serwisowe i inwestycyjne, zdobywa nowych klientów i rozszerza obszary działań. Działania rozpoczynające nowy cykl i prace nad gruntownie przebudowaną infrastrukturą procesowo-informatyczną są naturalnym elementem działań wszystkich pracowników spółki. Jednocześnie są oni świadomi, iż nowa strategia zarządzania w firmie nie jest etapem docelowym, lecz będzie przedmiotem kolejnego cyklu ABPM, będzie adaptowana do przyszłych wymagań klientów i - w długookresowej perspektywie - znów ulegnie planowanej i kontrolowanej przebudowie.

Podsumowanie i wnioski

Opis wysiłków w zakresie adaptacji zwinnych technik zarządzania projektami do świata procesów biznesowych nie jest wyłącznie rozważaniem teoretycznym. Konieczność wprowadzenia zmian w projektowaniu, realizacji i analizie procesów to rzeczywista potrzeba biznesowa, przed jaką stanął zarząd spółki SESCOM S.A. z Gdańska. Po 5 latach dynamicznego rozwoju organizacji oraz w perspektywie pozyskania kolejnych klientów w już obsługiwanych i nowych branżach zarząd przyjął za cel opracowanie strategii zarządzania procesami biznesowymi w taki sposób, aby niezależnie od dynamiki rozwoju spółki zapewnić najwyższą jakość świadczonych klientom usług. Mimo że podobne strategie formułuje wiele współczesnych firm, uwzględnienie w założeniach zwiększenia elastyczności i podatności na zmiany przy zachowaniu kontroli i przyjętych względem klienta zobowiązań przyczyniło się do zasadniczej zmiany kultury organizacji. W wielu przypadkach zrezygnowano z budowania procesów w tradycyjny, sekwencyjny sposób. Pracownikom zapewniono większą decyzyjność i możliwość reakcji na nietypowe, niezdefiniowane zdarzenia. W praktyce do pewnego stopnia to pracownicy i partnerzy spółki kreują przebieg procesów, natomiast odpowiednio zaprojektowane narzędzia informatyczne śledzą ten przebieg, a następnie przeprowadzają wizualizację pracy i dostarczają rzeczywistych danych do analizy.

Realizacja tej strategii implikowała zasadnicze zmiany w obszarze informatyzacji spółki. Sięgnięto także po najnowsze techniki analityczne, które w Polsce nie miały dotychczas praktycznych zastosowań. Mimo że nowatorska strategia jest wdrażana dopiero od kilku miesięcy, organizacja dysponuje na tym etapie informacjami zwrotnymi, które pozwalają wyostrzać prokliencką wizję funkcjonowania organizacji. Pozyskana dzięki realizacji cyklu ABPM wiedza traktowana jest jako know-how organizacji. Dorobek z zakresu AZP, zasadniczo reorientujący dotychczas stosowane, statyczne metody tworzenia i udoskonalania procesów biznesowych, pozwala odważniej wchodzić na rynki zagraniczne, wprowadzać nowe branże serwisowe, a niekończąca się dynamika w procesach staje się naturalnym silnikiem dalszych usprawnień, które napędzają prowadzony przez organizację biznes.

Potencjał do budowania adaptacyjnych procesów biznesowych może zostać w pełni wykorzystany pod warunkiem, że kapitał ludzki będzie kształtowany w taki sposób, aby miał świadomość, iż pewne podstawy w procesach i projektach są niezmienne (koszty, terminy, zobowiązania, SLA), natomiast zmieniają się strategie i praktyki działania. Adaptacyjność to nastawienie umysłu. Procesy liniowe i powtarzalne nie znikną, ale elastyczność i zaprojektowanie mechanizmów pozwalających na podejmowanie inicjatywy prowadzą do minimalizacji bezmyślnych decyzji lub ich całkowitego unikania z uwagi na brak opisu wszystkich ograniczeń. Wiele poważnych organizacji głosi, że procesy nie mogą być ważniejsze od ludzi, a następnie krępuje pracowników procedurami i formalizmami, niszcząc tym samym talenty i umiejętności. Warto jednocześnie dodać, że zwinne zarządzanie procesami i projektami musi być strategią wszystkich, a nie tylko wybranych jednostek organizacyjnych w firmie. Nawet najlepszy zespół z najlepszym menedżerem na czele nie zrewiduje wysokopoziomowej polityki organizacji i nie zrekompensuje niezdolności do adaptacji organizacji jako całości. Zwinne działania są przeciwieństwem polityki nakazowej i mikrozarządzania, które ostatecznie skłania do biernego schowania się w procesach i projektach przy jednoczesnym mówieniu kadrze menedżerskiej tego, co chce usłyszeć.

Bibliografia

• Actuation Consulting, The Study of Product Team Performance, 2013, http://www.actuationconsulting.com/whitepaper_request_2013.php.
• Agile Blog, The Importance of Timeboxing and Iterations for Agile Planning, 2013, http://blogs.telerik.com/agile-blog/posts/13-09-11/the-importance-of-timeboxing-and-iterations-for-agile-planning.
• Ambler S.W., Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process, John Wiley & Sons, New York 2002.
• Anderson B.D., Reinertsen D.G., Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, Sequim 2010.
• Beck K., Andres C., Extreme Programming Explained: Embrace Change, 2nd Edition, Addison-Wesley, Boston 2004.
• Beck K., et al., Manifesto for Agile Software Development, 2001, http://agilemanifesto.org.
• Cobb C.G., Zrozumieć Agile Project Management. Równowaga kontroli i elastyczności, APN Promise, Warszawa 2012.
• Cockburn A., Agile Software Development: The Cooperative Game (2nd Edition), Addison-Wesley, Boston 2006.
• DSDM Consortium, Agile Project Management Handbook v 1.2, 2010.
• Gawin B., Marcinkowski B., Symulacja procesów biznesowych. Standardy BPMS i BPMN w praktyce, Helion, Gliwice 2013.
• Highsmith J.A., Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Dorset House Publishing, New York 1999.
• Lotz M., Waterfall vs. Agile: Which is the Right Development Methodology for Your Project?, 2013, http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology.
• Marcinkowski B., Gawin B., BPMN a wymiar danych - ograniczenia i notacje komplementarne, „e-mentor” 2014, nr 2 (54), s. 57-67, http://dx.doi.org/10.15219/em54.1096.
• Mikoluk K., Agile Vs. Waterfall: Evaluating The Pros And Cons, 2013, https://www.udemy.com/blog/agile-vs-waterfall.
• Moen R., Norman C., Evolution of the PDCA Cycle, 2009, http://pkpinc.com/files/NA01MoenNormanFullpaper.pdf.
• Object Management Group, Business Process Model and Notation (BPMN). Version 2.0.2, 2013, http://www.omg.org/spec/BPMN/2.0.2.
• Palmer S.R., Felsing J.M., A Practical Guide to Feature-Driven Development, Prentice Hall, New Jersey 2002.
• Poppendieck M., T. Poppendieck, Lean Software Development: An Agile Toolkit, Addison-Wesley, Boston 2003.
• Schwaber K., Agile Project Management with Scrum (Developer Best Practices), Microsoft Press, Redmond 2004.
• Simmons S., Steele M., BPM Voices: Synchronicity: An Agile Approach to Business Process Management, 2012, http://www.ibm.com/developerworks/websphere/bpmjournal/1202_col_simmons/1202_simmons.html.
• Stapleton J., DSDM: The Dynamic Systems Development Method, Addison-Wesley, Boston 1997.
• Szelągowski M., Konsekwencje dynamic BPM, „e-mentor” 2014, nr 4 (56), s. 61-68, http://dx.doi.org/10.15219/em56.1126.
• Thiemich C., Puhlmann F., An Agile BPM Project Methodology, „Lecture Notes in Computer Science” 2013, Vol. 8094, s. 291-306, http://dx.doi.org/ 10.1007/978-3-642-40176-3_25.
• Wieczorek D., Od zwinności do doskonałości, „Zarządzanie projektami” 2014, nr 5, s. 7-13.
• Wrycza S., Marcinkowski B., Maślankowski J., UML 2.x. Ćwiczenia zaawansowane, Helion, Gliwice 2012.