To pytanie tylko z pozoru wydaje się banalne.

Przecież właściciel, prezes, dyrektor, kierownik czy lider zespołu znają swoją organizację. Wiedzą, czym firma się zajmuje, kto za co odpowiada, jakie są główne działy, jakie usługi świadczy firma, jakie ma produkty, klientów, cele i problemy.

Ale spróbujmy zadać to pytanie trochę inaczej:

Czy naprawdę znasz procesy, według których działa Twoja firma?

• Nie te opisane w procedurach.
• Nie te narysowane kiedyś na potrzeby audytu.
• Nie te, które „powinny” działać zgodnie z regulaminem.

Tylko te prawdziwe. Codzienne. Z wyjątkami, skrótami, telefonami, mailami, Excelami, dodatkowymi akceptacjami, nieformalnymi decyzjami i sytuacjami, o których „wszyscy wiedzą”, ale których nikt nigdy nie opisał.

W wielu firmach odpowiedź na to pytanie wcale nie jest oczywista.

Jeden proces, wiele wersji prawdy

Jednym z najciekawszych momentów podczas analizy procesowej jest rozmowa z różnymi uczestnikami tego samego procesu.

Pytamy o ten sam obszar działania firmy, ale otrzymujemy kilka różnych historii.

• Pracownik liniowy opisuje codzienną praktykę. Wie, co trzeba kliknąć, do kogo zadzwonić, kogo poprosić o zgodę i co zrobić, kiedy system nie pozwala przejść dalej.
• Kierownik niższego szczebla widzi zadania, opóźnienia, zastępstwa i problemy organizacyjne. Wie, gdzie proces się zacina i które sprawy wymagają ręcznego pilnowania.
• Kierownik średniego szczebla często patrzy przez pryzmat odpowiedzialności, obciążenia zespołów i raportowania.
• Dyrektor pionu koncentruje się na kosztach, ryzykach, wskaźnikach i zgodności z przyjętym modelem działania.
• Prezes albo zarząd widzą proces jeszcze inaczej — przez cele strategiczne, wynik finansowy, skalowalność i wpływ na całą organizację.

Każda z tych osób może mówić prawdę. Problem polega na tym, że każda widzi tylko fragment rzeczywistości.

I właśnie dlatego ten sam proces może mieć w firmie kilka różnych obrazów.

• Dla jednej osoby proces kończy się wtedy, gdy zadanie zostanie wykonane.
• Dla drugiej — kiedy kierownik potwierdzi wykonanie.
• Dla trzeciej — dopiero wtedy, gdy powstanie raport albo dokument końcowy.
• Dla czwartej — gdy dane trafią do rozliczenia, faktury albo systemu finansowego.

Formalnie mówimy o jednym procesie. W praktyce każdy może mieć na myśli coś trochę innego.

Co zwykle znika z opisu procesu?

Kiedy pytamy: „jak wygląda ten proces?”, bardzo często otrzymujemy opis standardowej ścieżki.

• Ktoś zgłasza sprawę.
• Ktoś ją akceptuje.
• Ktoś wykonuje zadanie.
• Ktoś potwierdza zakończenie.
• Proces się zamyka.

Na pierwszy rzut oka wszystko wygląda prosto.

Dopiero po kilku dodatkowych pytaniach okazuje się, że istnieją wyjątki.

• Co się dzieje, jeśli brakuje danych?
• Kto podejmuje decyzję, gdy wartość sprawy przekracza określony próg?
• Czy proces wygląda tak samo dla wszystkich klientów, lokalizacji albo typów zleceń?
• Kto może cofnąć sprawę do poprawy?
• Czy akceptacja zawsze jest wymagana?
• Co się dzieje, jeśli osoba odpowiedzialna jest nieobecna?
• Kto widzi sprawę, ale formalnie jej nie akceptuje?
• Kto tworzy raport?
• Na podstawie jakich danych liczony jest wskaźnik?
• Czy te dane są wpisywane zawsze tak samo?

To właśnie w tych pytaniach ukryty jest prawdziwy obraz procesu.

Bo proces to nie tylko główna ścieżka. To także warunki, wyjątki, decyzje, powroty, obejścia, zależności, role, terminy, powiadomienia, raporty i dane potrzebne do zarządzania.

Jeśli tego nie opiszemy, to nie mamy pełnego procesu. Mamy tylko uproszczoną opowieść o tym, jak proces powinien wyglądać.

Czy na takim obrazie można zarządzać firmą?

W tym miejscu warto zadać kolejne pytanie:

Czy niepełny i niespójny obraz procesu może być podstawą do spójnego zarządzania firmą?

Bo problem nie kończy się na tym, że różne osoby inaczej opisują ten sam proces. Prawdziwy problem zaczyna się wtedy, gdy na podstawie tych opisów próbujemy podejmować decyzje, porównywać wyniki, planować zmiany albo budować system informatyczny.

Jeżeli każdy dział rozumie proces trochę inaczej, trudno mówić o jego powtarzalnej realizacji.

Ta sama sprawa w jednym zespole może przechodzić przez trzy kroki, w drugim przez pięć, a w trzecim przez dodatkową nieformalną akceptację, o której nikt nie wspomina w procedurze.

• Raz termin liczony jest od daty zgłoszenia.
• Innym razem od daty uzupełnienia kompletu danych.
• W jednym oddziale sprawę zamyka pracownik.
• W drugim dopiero kierownik.
• W trzecim dodatkowo ktoś przygotowuje zestawienie w Excelu, bo „tak zawsze było potrzebne do raportu”.

W efekcie firma nie ma jednego procesu. Ma kilka lokalnych sposobów działania.

Podobny problem pojawia się przy porównywaniu wyników.

Jeżeli jeden zespół uznaje zadanie za zakończone po wykonaniu pracy, drugi po akceptacji kierownika, a trzeci dopiero po przygotowaniu dokumentu końcowego, to czy naprawdę możemy porównywać czas realizacji tych zadań?

W raporcie wszystko może wyglądać spójnie. Mamy kolumnę „czas realizacji”, status „zakończone” i wykres pokazujący wyniki poszczególnych zespołów.

Ale pod spodem mogą kryć się zupełnie różne definicje tego samego wskaźnika.

A skoro trudno porównywać wyniki, trudno też planować przyszłość.

• Nie wiemy, gdzie proces naprawdę się blokuje.
• Nie wiemy, które wyjątki są incydentalne, a które stały się codzienną praktyką.
• Nie wiemy, które osoby są faktycznie niezbędne w procesie, a które pojawiają się w nim tylko dlatego, że „tak się przyjęło”.
• Nie wiemy, które dane są naprawdę potrzebne do podejmowania decyzji.
• Nie wiemy, co warto automatyzować, a czego najpierw trzeba się pozbyć.

W takiej sytuacji firma nie zarządza jednym wspólnym procesem. Zarządza kilkoma lokalnymi wersjami procesu, często opartymi na doświadczeniu konkretnych osób, nieformalnych zasadach i rozwiązaniach wypracowanych przez lata.

To może działać przez długi czas. Szczególnie wtedy, gdy organizacja jest stabilna, a kluczowe osoby dobrze znają swoje obowiązki.

Problem pojawia się wtedy, gdy firma chce rosnąć, wdrażać nowe narzędzia, porównywać oddziały, skalować działania, automatyzować pracę albo przekazać wiedzę nowym pracownikom. Wtedy okazuje się, że doświadczenie ludzi jest bezcenne, ale nie wystarcza jako jedyna podstawa zarządzania. Analiza procesowa pokazuje firmie jej własne odbicie.

To, jak różnie ten sam proces wygląda w oczach jego uczestników, najlepiej widać podczas analizy procesowej. Dopóki rozmawiamy osobno z pracownikiem, kierownikiem, dyrektorem czy osobą odpowiedzialną za raportowanie, każdy opis wydaje się logiczny.

• Każdy mówi o swojej części pracy.
• Każdy wskazuje czynności, które z jego perspektywy są najważniejsze.
• Każdy ma swoje uzasadnienie.
• Każdy zna swoje problemy.

Problem polega na tym, że te opisy nie zawsze składają się w jeden spójny obraz.

Dopiero kiedy na podstawie rozmów, warsztatów, analizy dokumentów i obserwacji budujemy wspólny opis procesu, a następnie pokazujemy go poszczególnym uczestnikom, zaczyna dziać się coś bardzo ciekawego. Ludzie często ze zdziwieniem zauważają, jak wiele elementów było dla nich niewidocznych.

• Pracownik dowiaduje się, dlaczego określone dane są wymagane już na początku procesu.
• Kierownik widzi, że opóźnienia nie wynikają wyłącznie z pracy jego zespołu, ale z decyzji podejmowanych wcześniej.
• Dyrektor odkrywa, że raportowany wskaźnik jest liczony na podstawie danych, które w praktyce są uzupełniane w różny sposób.
• Osoba z zarządu może zobaczyć, że proces formalnie wygląda prosto, ale w rzeczywistości zawiera wiele wyjątków, nieformalnych uzgodnień i ręcznych obejść.

I to jest jeden z największych efektów dobrej analizy procesowej.

• Nie chodzi tylko o stworzenie dokumentacji.
• Nie chodzi tylko o narysowanie schematu.
• Nie chodzi tylko o przygotowanie materiału dla dostawcy systemu IT.

Chodzi o to, że organizacja może zobaczyć samą siebie z boku.

Analiza procesu jako wstęp do digitalizacji. Digitalizacja procesu biznesowego często kojarzy się z wyborem narzędzia.

• Jaką aplikację wdrożyć?
• Czy potrzebujemy systemu workflow?
• Czy zrobić aplikację mobilną?
• Czy wykorzystać platformę low-code?
• Czy zintegrować się z ERP, CRM albo systemem finansowym?
• To są ważne pytania, ale nie powinny być pierwsze.

Pierwsze pytanie powinno brzmieć:

Czy naprawdę rozumiemy proces, który chcemy zdigitalizować?

Jeżeli próbujemy cyfryzować proces, którego dobrze nie znamy, ryzykujemy, że system tylko przeniesie do świata cyfrowego istniejący chaos.

• Zamiast uprościć pracę, utrwalimy niepotrzebne kroki.
• Zamiast uporządkować odpowiedzialności, zapiszemy w systemie nieformalne zależności.
• Zamiast poprawić raportowanie, będziemy szybciej generować błędne albo niespójne dane.
• Zamiast automatyzować proces, zautomatyzujemy jego problemy.

Dlatego analiza procesu jest świetnym wstępem do digitalizacji.

• Pozwala ustalić, co naprawdę dzieje się w organizacji.
• Pozwala uzgodnić wspólny język.
• Pozwala wskazać role i odpowiedzialności.
• Pozwala zidentyfikować wyjątki.
• Pozwala zrozumieć, które dane są potrzebne i po co są zbierane.
• Pozwala określić, które czynności powinien wspierać system, a które warto wcześniej uprościć albo wyeliminować.

Dopiero na takiej podstawie warto projektować aplikację.

Wtedy system nie jest tylko elektronicznym formularzem. Staje się narzędziem wspierającym rzeczywisty sposób działania firmy — albo jeszcze lepiej: pomaga ten sposób działania uporządkować.

System nie powinien być cyfrową kopią chaosu

Wiele problemów we wdrożeniach systemów bierze się z tego, że zbyt szybko przechodzimy do projektowania ekranów, formularzy i funkcji.

Zadajemy pytania:

• Jakie pola mają być na formularzu?
• Jakie statusy mają być dostępne?
• Jakie raporty mamy przygotować?
• Kto ma mieć uprawnienia?

To są potrzebne pytania. Ale jeśli zadamy je zbyt wcześnie, możemy zaprojektować system na podstawie niepełnego obrazu procesu.

Aplikacja biznesowa powinna wynikać z procesu, a nie odwrotnie.

Najpierw trzeba zrozumieć, kto inicjuje sprawę, kto podejmuje decyzje, jakie są warunki przejścia między etapami, jakie wyjątki występują najczęściej, jakie dane są potrzebne do działania, a jakie tylko „od zawsze były w formularzu”.

Dopiero później można odpowiedzialnie projektować formularze, statusy, powiadomienia, automatyzacje, raporty i integracje.

Bo digitalizacja sama w sobie nie rozwiązuje problemów organizacyjnych.

• Jeżeli proces jest niejasny, system tego nie naprawi.
• Jeżeli odpowiedzialności są nieprecyzyjne, system tylko pokaże ten problem szybciej.
• Jeżeli dane są niespójne, raporty będą niespójne.
• Jeżeli każdy zespół pracuje inaczej, aplikacja albo wymusi wspólny standard, albo stanie się zbiorem wyjątków.

Dlatego dobrze przeprowadzona analiza procesu nie jest kosztem przed wdrożeniem. Jest zabezpieczeniem przed wdrożeniem złego rozwiązania.

Na końcu wróćmy do pytania z początku.

Czy znasz swoją firmę?

Być może znasz ją bardzo dobrze z perspektywy strategii, wyników, klientów albo struktury organizacyjnej.

• Ale czy znasz ją z perspektywy codziennych procesów?
• Czy wiesz, jak naprawdę przepływa praca między ludźmi, działami i systemami?
• Czy wiesz, które decyzje są formalne, a które nieformalne?
• Czy wiesz, gdzie powstają opóźnienia?
• Czy wiesz, które dane są potrzebne do zarządzania, a które są zbierane tylko dlatego, że kiedyś ktoś ich wymagał?
• Czy wiesz, czy różne zespoły realizują ten sam proces w taki sam sposób?
• Czy wiesz, czy wskaźniki, które porównujesz, naprawdę oznaczają to samo w całej organizacji?

To nie są pytania wyłącznie dla działu IT.

To są pytania o sposób zarządzania firmą.

Firma, która nie ma wspólnego obrazu swoich procesów, może działać dzięki doświadczeniu ludzi. Często działa tak przez lata. Ale trudno jej świadomie skalować działalność, porównywać wyniki, wdrażać nowe osoby, automatyzować pracę i budować powtarzalny model zarządzania.

Dlatego analiza procesu nie jest tylko etapem przygotowania do wdrożenia aplikacji.

Jest sposobem na sprawdzenie, czy organizacja rzeczywiście wie, jak działa.

A dopiero wtedy można odpowiedzialnie odpowiedzieć na kolejne pytanie: jaką część tego działania warto zdigitalizować?