Spotkanie handlowe w dużej spółce giełdowej. Naprzeciwko nas członkowie zarządu oraz zespół powołany do realizacji projektu wdrożenia systemu klasy ERP. Od blisko godziny rozmawiamy o metodyce modelowania procesów. Wreszcie udaje nam się przekonać przedstawicieli drugiej strony o konieczności wyboru do szczegółowego modelowania wyłącz-nie procesów kluczowych, czyli procesów głównych w których powstaje wartość dodana dla klientów spółki oraz procesów pomocniczfych i zarządczych, mających największe przełożenie na procesy główne.

Na salę wkracza prezes, przechodzimy przez standardowy rytuał przywitań. Kontynuujemy rozmowę od miejsca, w którym skończyliśmy. Prezes z uwagą, w lekkim napięciu przysłuchuje się rozmowie, po czym stwierdza:
- Panowie, chcę mieć opisane WSZYSTKIE procesy, bardzo szczegółowo.
- Panie Prezesie, modelowanie wszystkich procesów nie ma sensu – odpowiadam i wracamy do punktu wyjścia.

Zarządy spółek zdają sobie sprawę, iż analiza procesów może być skuteczną metodą poprawy funkcjonowania przedsiębiorstwa. Tym niemiej istnieje wiele błędnych przekonań co do sposobu realizacji takiego przedsięwzięcia. Funkcjonujące w naszych głowach schematy myślowe wielokrotnie uniemożliwiają prawidłowe zaprojektowanie projektu związanego z analizą procesów oraz osiągnięcie korzyści, dla których takie projekty się realizuje. Poniżej postarałem się przeanalizować najczęstsze mity i przekonania, z którymi należy bezwzględnie walczyć.

Mit 1. Analiza procesów jest PANACEUM na każdy problem organizacji.
Wielokrotnie po uświadomieniu klientowi potencjału korzyści analizy procesów, druga strona, biorąc pod uwagę maksymalizację oczekiwanych efektów, przy równoczesnej minimalizacji kosztów, eskaluje zakres analizy, zapominając o kluczowych problemach organizacji, które w wyniku analizy powinny zostać rozwiązane. Z punktu widzenia klienta najlepiej byłoby aby procesy zoptymalizowano pod kątem wdrożenia systemu ERP, uwzględniono obiegi dokumentów - no bo w końcu, kto nie ma z nimi problemów, dodatkowo dopisano zasoby oraz przeprowadzono stosowne symulacje.
W tym miejscu trzeba odpowiedzieć jednoznacznie, iż nie jest możliwe zrealizowanie wszystkich tych potrzeb w trakcie jednego projektu. Oczekiwania tego typu pojawiają się zazwyczaj w podmiotach, które nie miały wcześniej do czynienia z profesjonalnym modelowaniem procesów biznesowych. Ich przedstawiciele nie zdają sobie sprawy, iż każde takie rozszerzenie powinno być traktowane jako odrębny projekt. Nie wiedzą, iż każdy postawiony w taki sposób cel radykalnie wpływa na wydłużenie czasu trwania analizy, jak również obciążenie zespołu po stronie klienta.
Wybór procesów do analizy, sposób ich odzwierciedlenia m.in. oznaczenia interakcji, czynności procesowych oraz głębokość dekompozycji procesów powinny być ściśle związane z celem modelowania. W przypadku modelowania procesów pod kątem wdrożenia systemu ERP, nie jest uzasadnione kładzenie akcentu na odwzorowanie obiegu dokumentów, w dużej mierze standardowo wspieranych tejże klasy systemami. Przy założeniu takiego celu analizy należy skoncentrować się na uchwyceniu tych procesów, które świadczą o przewadze konkurencyjnej organizacji, tak aby dobrać z rynku rozwiązanie, które w najlepszym stopniu te procesy wspiera, albo w najłatwiejszy w sposób da się do tych procesów dostosować.

Mit 2. Zakres analizy powinien objąć WSZYSTKIE procesy organizacji.
Dwa razy zastanowiłbym się nad zatrudnieniem firmy doradczej, której przedstawiciele bez dłuższego zastanowienia twierdzą, iż dokonają analizy WSZYSTKICH procesów mojej organizacji. Gdybym usłyszał jeszcze deklarację, iż dokonają tego w okresie dwóch miesięcy, zacząłbym się zastanawiać czy operujemy tą samą definicją pojęcia WSZYSTKO.
Specyfika modelowania procesów wymusza równie duże zaangażowanie w realizację projektu zespołu Zamawiającego jak zespołu Wykonawcy. Z tego powodu WSZYSTKO sprowadza się zazwyczaj do kompromisu skorelowanego z czasem, który obie strony są w stanie projektowi poświęcić. Z chwilą gdy mija termin realizacji projektu strony umowy stają się więźniami WSZYSTKIEGO. W pewnym momencie dochodzi do sytuacji gdy obie strony są tak samo umotywowane do zakończenia prac. Zazwyczaj w pierwszej kolejności jest to Wykonawca monitorujący koszty związane z wykorzystywanymi na projekcie zasobami. W miarę zaś upływu czasu również i Zamawiający nie wytrzymujący tempa prac, dodatkowo mogący być pod presją kolejnych terminów np. związanych z wyborem oprogramowania, jest zainteresowany zamknięciem projektu. I w sumie takie rozwiązanie wydaje się być najmniejszym wymiarem kary dla obu stron.
Praktyka pokazuje, iż liczbę procesów biznesowych, które warto w organizacji modelować można zazwyczaj ograniczyć do kilkunastu. Procesy te, które klasyfikuje się jako kluczowe (1) w największym stopniu tworzą wartość dodaną organizacji, (2) w największym stopniu do powstawania wartości dodanej się przyczyniają (3) lub są poważną przeszkodą w jej powstawaniu.
Z tego względu na etapie wstępnym projektu konieczne jest:
(1) przeprowadzenie szczegółowej analizy kontekstu organizacyjnego i identyfikacji procesów,
(2) klasyfikacja procesów na procesy główne, pomocnicze i zarządcze
(3) i dopiero na tej podstawie wybór procesów kluczowych podlegających modelowaniu.
W każdym wypadku na wybór procesów kluczowych powinien mieć wpływ określony przez organizację CEL modelowania procesów.

Mit 3. Procesy referencyjne OPROGRAMOWANIA najlepszym sposobem na poprawienie działania organizacji.
Wybierając system informatyczny często powstaje pytanie, czy nie pominąć działań związanych z modelowaniem procesów. Tak czy inaczej pierwszym etapem projektu wdrożeniowego jest bowiem Analiza Przedwdrożeniowa. Podejście takie jest rozważane w obliczu zapewnień firm wdrożeniowych o istnieniu „zaszytych” w ramach oprogramowania procesów referencyjnych będących odzwierciedleniem zbiorowego doświadczenia z set wdrożeń systemu rozważanego producenta.
Procesy referencyjne brzmią świetnie jako argument handlowy, tym niemniej odarte z towarzyszącego im nimbu tajemniczości sprowadzają się zazwyczaj do możliwości konfiguracyjnych oprogramowania. Zakres zaś wykorzystania tychże możliwości zależy w przeważającym stopniu od kompetencji zespołu wdrożeniowego. Wielokrotnie audytując projekty wdrożeniowe jesteśmy świadkami sytuacji, w których jeden Wykonawca deklaruje brak możliwości realizacji określonego wymagania klienta, podczas gdy drugi wykorzystując możliwości konfiguracyjne oprogramowania te wymagania potrafi zaspokoić. Co gorsza w takich okolicznościach, wymagających rozstrzygnięcia co w systemie jest możliwe, a co nie, producent zazwyczaj nabiera wody w usta, nie chce bowiem podważać kompetencji swojego partnera.
Reasumując analiza procesów wykonywana przed wyborem docelowego rozwiązania informatycznego pełni zupełnie inną rolę niż Analiza Przedwdrożeniowa wykonywana przez jego dostawcę. Celem takiej analizy powinna być optymalizacja procesów, tak aby uniknąć oprogramowania interakcji i organizacji działań o charakterze nieefektywnym. Analiza pozwala zidentyfikować procesy w największym stopniu dla organizacji krytyczne, a następnie określić zakres modyfikacji systemu w tych miejscach, gdzie organizacja danego procesu stanowi rzeczywisty wkład w kreowanie przewagi konkurencyjnej firmy i gdzie nie ma swojego uzasadnienia bazowanie na rozwiązaniach standardowych. Pozostawiając analizę procesów w gestii dostawcy oprogramowania Zamawiający jest narażony na jednostronne dostosowywanie procesów biznesowych organizacji do charakterystyki oprogramowania.
Na tym tle czasami spotykamy się również z przekonaniem, że dla właściwego wykonania modelowania procesów pod kątem wyboru systemu informatycznego konieczna jest szczegółowa znajomość funkcjonujących na rynku rozwiązań. Oczywiście taka wiedza jest przydatna, tym niemniej kluczowa jest umiejętność spojrzenia na procesy z punktu widzenia wymagań biznesu. Dopiero później powinno nastąpić nałożenie na procesy docelowych rozwiązań informatycznych. To właśnie w wyniku skutecznej procedury doboru oprogramowania możliwe jest wyłonienie takiego rozwiązania, które w największym stopniu odpowie na zdefiniowane wymagania standardowymi mechanizmami.

Mit 4. System informatyczny ma się w pełni DOSTOSOWAĆ do naszych procesów.
Co prawda przekonanie takie jest rzadsze, aczkolwiek w przypadku gdy się pojawia, wyjątkowo trudno z nim walczyć. Zgodnie z tym co zostało napisane powyżej zakres modyfikacji systemu informatycznego powinien współgrać z faktycznymi możliwościami budowania przewagi konkurencyjnej oraz korzyściami płynącymi z informatyzacji procesu o przebiegu odbiegającym od standardu. Należy być świadomym, iż każda modyfikacja rozwiązania, będzie skutkować potencjalnymi problemami oraz wzrostem kosztów na etapie aktualizacji systemu i w trakcie realizacji upgrade. Stworzenie wymagań bez odniesienia do standardowych mechanizmów funkcjonujących na rynku systemów informatycznych, brak otwartości na kompromis w zakresie dostosowania do standardów, i obligatoryjność wszystkich zdefiniowanych przez klienta wymagań będą prowadziły do preferowania dostawców piszących pod klucz i w konsekwencji takiego wyboru prawdopodobnego uzależnienia się od wybranego Wykonawcy.

Mit 5. Najważniejsze jest doświadczenie BRANŻOWE.
Na etapie negocjacyjnym jedno z kluczowych pytań dotyczy doświadczenia z modelowania procesów w tej samej branży. Jest to pytanie jak najbardziej uzasadnione, tym niemniej jest ono często zadawane w kontekście możliwości wzorowania się w trakcie projektu na procesach konkurencji. Oczywiście wiedza taka może być bardzo cenna, trzeba jednakże pamiętać o obowiązujących konsultantów zasadach poufności w zakresie wypracowywanych na projektach rozwiązań, ale również o niebezpieczeństwie kryjącym się w bazowaniu na doświadczeniach konkurencyjnych spółek.
Analogiczne pytanie powstaje na etapie wyboru firmy wdrożeniowej. W trakcie jednego z wielu spotkań handlowych w podmiocie branży zdominowanej przez jednego dostawcę systemu klasy ERP klient zadał mi pytanie czy wdrażać system, który uruchomiono z sukcesem w kliku takich samych konkurencyjnych zakładach, czy też wybrać rozwiązanie alternatywne. Z rozwiązaniem alternatywnym wiąże się większe ryzyko, ale również potencjalne korzyści płynące ze zróżnicowania swojego działania względem rywali.
Z tych właśnie względów jeden z naszych klientów, lider branży samochodowej, wybierając system nie zdecydował się na rozwiązanie, wydawałoby się idealnie dopasowane, ale funkcjonujące w firmie będącej bezpośrednim konkurentem, a na system Wykonawcy o mniejszym doświadczeniu w tej konkretnej branży, ale o dużych możliwościach dostosowania rozwiązania do specyfiki klienta.

Mit 6. Należy bazować na najlepszych PRAKTYKACH z innych branż.
Sam fakt odwzorowywania procesów funkcjonujących w innych firmach bez odniesienia do kontekstu biznesowego i uwarunkowań, w których funkcjonuje analizowany podmiot może stać się przyczyną stworzenia procesów docelowych w oparciu o błędne założenia, a nawet rozmycia określonego celu optymalizacji. Zdarzyło nam się współpracować z firmą, która była pod ogromnym wrażeniem zamodelowanego dla nich procesu nazywanego przez klienta procesem CRM. Nie wchodząc w dyskusję co do prawidłowości takiego nazewnictwa, po zbadaniu procesu, wszystko od strony formalnej było jak najbardziej prawidłowe, za wyłączeniem adekwatności zastosowania wspomnianego procesu w warunkach klienta. Specyficzna na rynku działalność podstawowa klienta powodowała, iż grono potencjalnych odbiorców ograniczało się do kilkudziesięciu podmiotów w skali świata, tym samym trudno było wyobrazić sobie tutaj aby kluczowym procesem był kampanie marketingowe, czy też złożone analizy profilu odbiorców.

Mit 7. Modelowanie procesów FINANSOWO-KSIĘGOWYCH.
Od czasu do czasu spotykamy się z oczekiwaniami klienta by mapować procesy finansowoksięgowe. Oczekiwanie takie kłóci się z samą filozofią podejścia procesowego do zarządzania organizacją. Proces z zasady powinien przechodzić na wskroś organizacji, przez wiele działów. W przypadku odwzorowania czynności realizowanych w ustalonej kolejności w ramach jednego działu należy mówić o procedurach. Dodatkowo należy stwierdzić, iż działalność  obszaru finansowoksięgowego jest w pełni regulowana ustawą o Rachunkowości, tym samym możliwości różnicowania ewidencji procesów gospodarczych organizacji są tutaj bardzo ograniczone. Również aplikacje ERP operują tutaj ścisłymi, zunifikowanymi procedurami w pełni zgodnymi z ustawą.
Ponieważ zadaniem finansów i księgowości jest odwzorowywanie i rejestracja zdarzeń gospodarczych zachodzących w przedsiębiorstwie to na pewnym etapie analizy procesów kluczowych będą pojawiały się czynności związane m.in. z rozliczaniem kontraktów, uruchamianiem procedur windykacyjnych, weryfikacją salda klienta pod kątem analizy klienta, tym niemniej mowy o procesach finansowoksięgowych być nie może. Spotkaliśmy się z próbami rozpisywania w formie procesów zasad dekretacji, ale wówczas nie można nazwać tego procesem tylko próbą schematycznego zobrazowania obowiązujących w firmie zasad księgowości.

Mit 8. Procesy powinny być zamodelowane do poziomu czynności NIEPODZIELNEJ.
Tu powstaje analogia do wcześniejszych rozważań na temat definicji WSZYSTKIEGO, rodzą się wątpliwości gdzie kończy się niepodzielność, jak obiektywnie ją stwierdzić i w którym momencie przy założeniu nieograniczonej wręcz możliwości rozbijania działań na coraz mniejsze skończy się cierpliwość klienta.
I również w tym przypadku poziom dekompozycji powinien jednoznacznie wynikać z założonego celu modelowania. Wystarczy przez chwilę o nim zapomnieć i konsekwencją tego może być sytuacja, w której w projekcie związanym z przeprowadzeniem symulacji procesów, klient prosi o dekompozycję procesów do poziomu czynności elementarnych. Tylko, że przy takim poziomie dekompozycji niemożliwe jest sensowne przypisanie parametrów symulacji i jej skuteczna realizacja. W tej konkretnej sytuacji procesy powinny być odzwierciedlone ze szczegółowością skorelowaną z możliwościami pomiaru długości trwania czynności oraz możliwościami przypisania do nich zasobów.Nie ulega wątpliwości, iż modelowanie procesów może przynieść organizacji naprawdę duże korzyści. Planując projekt optymalizacyjny każdorazowo konieczne jest jednak określenie stawianych projektowi celów oraz dopasowanie metodyki realizacji projektu tak aby cele te można było zrealizować. Działanie na zbyt wielu polach z dużym prawdopodobieństwem nie przyniesie oczekiwanych efektów. Równie ważnym aspektem jest umiejętność odnalezienia złotego środka w podejściu do zmian procesów - tak aby zmieniać tam gdzie jest to uzasadnione, pozostawiać niezmiennym zaś to co jest źródłem rzeczywistej przewagi konkurencyjnej. Warto zatem jak wielu innych dziedzinach naszego funkcjonowania  zachować umiar i rozsądek.