Mapowanie procesów biznesowych - jak to zrobić właściwie?



Autor artykułu: Robert Kuliński, Data publikacji: 12-09-2009 10:07

Modelowanie procesów jest dziś uznanym elementem analizy biznesowej. Często realizowane są projekty, których celem jest mapowanie i optymalizacja procesów, czy opracowanie KPI (Key Performance Indicators). Wiele firm wdraża BPM (Business Process Management). Pojawia się także na rynku wiele szkoleń z tego zakresu. Czy to oznacza, że wiedza z obszaru zarządzania procesami biznesowymi jest powszechna? A może to po prostu ciekawe zagadnienie, którym chętnie się zajmujemy, ale w sposób niezbyt poprawny, bez odpowiedniego poziomu wiedzy? Niestety wydaje się, że to drugie stwierdzenie jest bliższe prawdy. W niniejszym artykule przedstawię typowe analityczne błędy i trudności spotykane podczas realizacji projektów mapowania procesów biznesowych oraz wskazówki jak się ich ustrzec. Przykład przebiegu procesu w notacji BPMN   Cel projektu mapowania procesów Precyzyjnie i jednoznacznie określony cel projektu, to podstawa jego sukcesu. Dotyczy to każdego projektu - także takiego, który w nazwie ma „mapowanie procesów”. W praktyce, cel okazuje się często "rozmyty", różnie interpretowany i potrafi się częściowo zmieniać w trakcie realizacji projektu. Przyczyną takiej sytuacji, oprócz typowych dla wielu organizacji pozamerytorycznych problemów, jest sama natura zagadnienia. W zależności od poziomu zarządczego realizowanego projektu, jego cel jest postrzegany inaczej. Dla menedżera liniowego mapa aktualnego procesu, będzie szansą zapanowania nad organizacją pracy swojego zespołu. Dla kontrolera finansowego szczegółowa mapa procesu daje możliwość identyfikacji nieefektywności. Dla członków zarządu może być podstawą do definiowania zakresów odpowiedzialności w firmie. Cele mapowania procesów mogą być zatem bardzo różne. Idealnym podejściem do zdefiniowania celów projektu jest analiza strategii przedsiębiorstwa i wynikających z niej hierarchicznie udokumentowanych celów biznesowych firmy. Ocena realizacji celów biznesowych, szczególnie w przypadku oceny negatywnej, przekłada się na potencjalną konieczność modyfikacji określonych procesów zawartych w architekturze / mapie procesów firmy. W ten sposób uzyskujemy rzetelne uzasadnienie biznesowe uruchamianych projektów, w tym projektów mających na celu tworzenie precyzyjnych map (przebiegów) procesów biznesowych. Zakres projektu Częstym błędem popełnianym podczas definiowania zakresu projektu mapowania procesów, jest próba tworzenia detalicznych map dla bardzo wielu procesów ujętych w jednym dokumencie bez jasno sprecyzowanego celu biznesowego. Zwykle prowadzi to do powstania dokumentu zawierającego wiele setek lub nawet parę tysięcy stron, który najczęściej trafia na półkę i nie jest przez nikogo wykorzystywany. Jest to zazwyczaj konsekwencja nieprecyzyjnie określonego celu projektu, braku "świadomości procesowej" sponsora projektu i jego otoczenia, itp. Liczba procesów podlegających mapowaniu i poziom ich szczegółowości powinny wynikać bezpośrednio z celów projektu. Jeśli są one jasno sprecyzowane, dopasowanie zakresu projektu do jego celów biznesowych jest stosunkowo proste dla osoby posiadającej odpowiedni poziom wiedzy z dziedziny zarządzania procesami biznesowymi oraz analizy biznesowej. Osoby o wysokiej "świadomości procesowej" nie zdecydują się pochopnie na tworzenie olbrzymiej liczby szczegółowych map przebiegów bez precyzyjnego uzasadnienia biznesowego. Zdarza się, że konieczność taka istnieje, tym niemniej taki zakres wymaga najczęściej hierarchicznego podejścia i odpowiedniego wsparcia narzędziowego. Decydując o zakresie (czyli m.in. o liczbie i głębokości mapowania procesów) należy również pamiętać o tym, że opracowane w trakcie projektu procesy należy po jego zakończeniu utrzymywać w stanie aktualnym - odpowiadającym faktycznemu ich przebiegowi. Duża liczba szczegółowych map - bez odpowiednio zaimplementowanej hierarchii procesów i narzędzi wspierających, czy dedykowanych zasobów organizacyjnych, może doprowadzić do dezaktualizacji map. Problem ten może nie dotyczyć, bądź dotyczyć w mniejszym stopniu firm zorientowanych procesowo (czyli m.in. posiadających wskazanych właścicieli procesów biznesowych odpowiedzialnych za realizację procesów i utrzymanie map). Poza kwestią liczby procesów biznesowych, istnieje szereg innych aspektów mających wpływ na zakres prac projektu mapowania procesów biznesowych. Jednym z nich jest zakres informacyjny map. Brak określenia takiego zakresu na początku projektu powoduje niespójności pomiędzy procesami mapowanymi przez różne osoby czy zespoły. Zakres informacyjny powinien definiować elementy umieszczane na mapie przebiegu procesu, np. wspierające systemy i aplikacje informatyczne, sposób wykonywania czynności (manualnie, automatycznie, częściowo automatycznie), odpowiedzialne jednostki organizacyjne przedsiębiorstwa, role, powiązane produkty, usługi lub ich klasy, segmenty klienta, wskazania na szczegółowe procedury stanowiskowe itp. Każdy taki dodatkowy element informacyjny na mapie może znacząco zwiększyć zakres prac wymaganych do realizacji projektu. Jak więc określić właściwy zakres informacyjny? Podobnie jak poprzednio, punktem wyjścia są tu poprawnie zdefiniowane cele projektu. Podstawą do określenia właściwego zakresu informacyjnego jest m.in. określenie jak i do czego mapy będą wykorzystywane po zakończeniu projektu. Kolejnym elementem istotnie wpływającym na zakres i pracochłonność projektu mapowania procesów biznesowych jest oczekiwany poziom szczegółowości map. Podobnie jak w przypadku poprzednich elementów, powinien on wynikać z celów projektu. Tym niemniej określenie czy dany element procesu jest jeszcze zbyt ogólny czy może już zbyt szczegółowy często nie jest łatwe i w dużej mierze zależy od poziomu znajomości przebiegu procesu. Czynności w ramach przebiegu procesu, które dla osób z wyższej kadry kierowniczej wydają się bardzo szczegółowe, mogą być jednocześnie dużym uproszczeniem dla osób z działów operacyjnych, które na co dzień je realizują. Widać więc, że istotne znaczenie ma tu odbiorca i przyszły użytkownik map. Poziom szczegółowości map powinien być także dopasowany do oczekiwanego zakresu informacyjnego map. Przykładowo - jeśli oczekiwanym rezultatem projektu jest przedstawienie uczestnictwa i współpracy określonych jednostek organizacyjnych w procesach, ale nie jest istotne jak proces jest realizowany wewnątrz tych jednostek - można przyjąć taki poziom szczegółowości, który „zbiera” w jeden krok procesu wszystkie czynności realizowane przez jedną jednostkę organizacyjną, a każda kolejna czynność na mapie będzie realizowana przez inną jednostkę niż poprzednia. Jest to jeden ze sposobów określenia interesującego nas poziomu szczegółowości map. Struktura map procesów Tworząc mapy przebiegów procesów biznesowych nie sposób również pominąć kwestii ich struktury. Jeśli oczekiwany poziom szczegółowości map jest znaczący, próba tworzenia tylko jednego diagramu na proces może doprowadzić do powstania diagramów gigantów, które chcąc analizować na papierze należałoby drukować nie w formacie A4 czy nawet A3, a w formacie plakatowym... Jak łatwo się domyśleć, czytelność takiego dzieła byłaby znikoma. Dodatkowo, takie podejście spowodowałoby również wielokrotne mapowanie tych samych grup czynności realizowanych w ramach różnych procesów, w dodatku najprawdopodobniej za każdym razem nieco inaczej. Aby się tego ustrzec, należy konstruować mapy procesów w sposób kaskadowy. Określona czynność przedstawiona na diagramie nie musi być najmniejszą możliwą do wykonania czynnością. Może to być grupa czynności, których przebieg może być przedstawiony na odrębnym, zagnieżdżonym wewnątrz diagramie. Taka czynność złożona nazywa się „podprocesem” i może być powtarzana w ramach przebiegu wielu procesów. Zaletą takiego podejścia jest to, że kolejne poziomy zagnieżdżenia map przedstawiają kolejne poziomy abstrakcji procesów, od ogółu do szczegółu. Jest to przydatne, jeśli mapami będą posługiwały się osoby zarówno z wyższej kadry kierowniczej (wtedy patrzą tylko do pewnego poziomu głębokości), jak i osoby z części operacyjnej, zainteresowane w najdrobniejszych szczegółach przedstawionych na mapach. Decyzja o przedstawieniu pewnej grupy czynności, jako podproces, nie jest zadaniem trywialnym. Często obserwowanym błędem jest określanie tych kryteriów w sposób ilościowy, decydując np. aby na diagramie znajdowało się nie więcej niż 10 czynności. Rygorystyczne stosowanie takiej reguły powoduje, że czynności sztucznie przesuwa się do podprocesów, mimo braku merytorycznego uzasadnienia takiego ruchu. Sztucznie grupuje się kilka czynności w jedną, mimo że są merytorycznie odrębne i zgodnie z oczekiwanym poziomem szczegółowości powinny być przedstawione oddzielnie, itp. Innym obserwowanym błędem z tej samej kategorii jest próba określenia liczby poziomów zagłębienia, jakie są dopuszczalne - prowadzi to do tych samych problemów. Przykładowym, dość naturalnym kryterium grupowania czynności może być sposób realizacji pewnych czynności - jeżeli wykonywane są w sposób podobny, przy pomocy tych samych narzędzi - są to naturalni kandydaci do wydzielenia do podprocesu. Podobnie, jeśli czynności realizowane są w jednej jednostce organizacyjnej, podczas gdy czynności wcześniejsze i późniejsze są wykonywane w innej jednostce. Oczywiście nie należy zapominać o wymaganiu czytelności diagramu, jednak to powinno już zostać w gestii analityka tworzącego mapę, bez obligatoryjnych kryteriów ilościowych. Często pojawiającym się pytaniem jest sposób traktowania wariantowości przebiegów procesów. Jak wiadomo, ten sam proces może przebiegać na różne sposoby, w zależności od różnych warunków logicznych. Liczba zdefiniowanych wariantów zależy przede wszystkim od oczekiwanego poziomu szczegółowości map oraz ich zakresu informacyjnego. Zbyt duża wariantowość może prowadzić do znacznego skomplikowania przebiegu procesu i utraty jego czytelności. Należy więc rozważyć, czy nie warto rozbić procesu na parę wariantów i przedstawić je osobno, np. jeden proces dla klienta z rynku masowego, a drugi dla klienta z rynku biznesowego. Tym niemniej, są również sytuacje, w których sam charakter działania organizacji wymaga przygotowania procesów w bardzo wielu wariantach - ze względu na liczbę oferowanych produktów, liczbę kategorii klientów, czy wiele różnych kanałów kontaktu z klientami. W takich sytuacjach można posłużyć się dodatkowymi narzędziami wspierającymi same mapy procesów, tak by móc przeanalizować ich przebieg w jednym miejscu, przełączając się jedynie pomiędzy poszczególnymi wariantami - co przypomina nieco wielowymiarową analizę danych w formie graficznej. Notacja oraz narzędzia mapowania procesów Mając na względzie wszystkie wcześniej opisane przeze mnie czynniki wpływające na sposób mapowania procesów, dla zapewnienia sukcesu realizowanego projektu istotne jest także określenie właściwej notacji oraz narzędzia do mapowania procesów. Adekwatna do celów i zakresu projektu notacja, to taka, która umożliwia osiągnięcie oczekiwanego poziomu szczegółowości map, oraz taka, która będzie jednoznacznie rozumiana przez odbiorców map. Jeśli procesy mają być szczegółowe, ustandaryzowana notacja BPMN (Business Process Modeling Notation) ma duże szanse okazać się właściwą. Czasem jednak możemy być zobligowani do korzystania z narzędzia do mapowania procesów, wskazanego przez odbiorcę produktów projektu. Może to oznaczać, że notacja zostanie nam narzucona. Tym niemniej, jeśli będziemy mieli możliwość wyboru, należy pamiętać, że zarówno sama notacja jak i narzędzie wspierające mapowanie musi nam umożliwić realizację celów i zakresu projektu - uwzględniając wszystkie opisane uprzednio aspekty. Jeśli zatem w dłuższej perspektywie firma ma na celu optymalizację zmapowanych procesów, to mimo, że aktualny projekt może mieć na celu tylko utworzenie samych map, należy wybrać do tego taką notację i narzędzie, które umożliwią w przyszłości przekształcenie map w symulowalne modele. Słownik pojęć Realizując projekt mapowania, czy modelowania procesów często obserwowanym problemem jest brak precyzyjnego słownika pojęć. Te same pojęcia z analizy biznesowej są często inaczej interpretowane przez różnych ludzi. Wystarczy zapytać kilka osób jak rozumieją proces "end-to-end", aby się o tym przekonać. Oprócz problemów projektowych, często skutkuje to istotnym zmniejszeniem praktycznych możliwości wykorzystania utworzonych map. Spójne rozumienie określonych pojęć z zakresu analizy biznesowej najlepiej osiąga się odwołując się do definicji określonych w szeroko rozpoznawanych i uznanych standardach, kompendiach wiedzy itp. (np. BABOK® - Guide to the Business Analysis Body of Knowledge). W przypadku braku takiej możliwości, należy na potrzeby projektu, czy organizacji, stworzyć własny słownik pojęć analitycznych. Słowem podsumowania: projekt mapowania procesów biznesowych nie jest zadaniem łatwym. Istnieje wiele kwestii analitycznych, których pominięcie może łatwo doprowadzić do opóźnień w realizacji projektu, znacząco utrudnić korzystanie z utworzonych map bądź po prostu spowodować rozminięcie się z oczekiwaniami ich odbiorców. Planowanie projektu powinno być przeprowadzone dokładnie i uwzględniać aspekty opisane w niniejszym artykule. Tzw. „świadomość procesowa”, czyli wiedza z zakresu zarządzania procesami jest w tym działaniu obowiązkowa.

---