Mapowanie procesów biznesowych – od AS-IS do procesu gotowego do optymalizacji

Mapowanie procesów biznesowych pozwala zobaczyć, jak praca rzeczywiście przepływa przez organizację: od momentu powstania potrzeby do uzyskania konkretnego rezultatu. Pokazuje działania, decyzje, odpowiedzialności, systemy, przekazania między zespołami, czas oczekiwania oraz wyjątki, które często nie występują w oficjalnych procedurach.

Jest to szczególnie ważne przed automatyzacją. Jeśli firma zautomatyzuje proces bez wcześniejszego zrozumienia jego przebiegu, może jedynie przyspieszyć zbędne czynności, utrwalić niewłaściwe reguły albo przenieść istniejące wąskie gardło do nowego systemu.

Dlatego praktyczna kolejność powinna wyglądać następująco:

AS-IS → analiza problemów → uproszczenie → TO-BE → dobór zmian → automatyzacja → pomiar

Mapowanie nie jest więc tworzeniem diagramu dla dokumentacji. Mapa procesu powinna prowadzić do decyzji o tym, co usunąć, zmienić, ustandaryzować lub zautomatyzować.

Microsoft opisuje business process mapping jako sposób przedstawienia zarówno obecnego sposobu działania firmy, jak i przyszłego procesu po zmianie. Politechnika Lubelska wskazuje natomiast mapowanie jako podstawę m.in. optymalizacji, standaryzacji, wdrażania ERP, CRM i workflow oraz identyfikowania obszarów do automatyzacji.

Czym właściwie jest mapa procesu biznesowego?

Proces biznesowy to zestaw powiązanych działań prowadzących od określonego wejścia do oczekiwanego rezultatu.

Przykładowy proces może zaczynać się od:

klient przesyła formularz

i kończyć:

klient otrzymuje aktywowaną usługę.

Pomiędzy tymi punktami mogą występować:

• weryfikacja danych,
• decyzje,
• przekazania między działami,
• praca w kilku aplikacjach,
• oczekiwanie,
• wyjątki,
• poprawki,
• komunikacja z klientem.

Mapa procesu pokazuje te elementy w taki sposób, aby można było przeanalizować cały przepływ, a nie tylko działania pojedynczego pracownika.

To ważne, ponieważ lokalnie każdy dział może działać sprawnie, a cały proces nadal może być wolny.

Sprzedaż realizuje zadanie w godzinę.

Finanse potrzebują 20 minut.

Operacje – 40 minut.

Cały proces trwa jednak pięć dni.

Dlaczego?

Ponieważ pomiędzy tymi etapami praca czeka.

Mapa pomaga zobaczyć właśnie takie zależności.

AS-IS i TO-BE – dwa różne obrazy procesu

W projektach optymalizacyjnych często wykorzystuje się dwa modele:

AS-IS – jak proces działa obecnie,

TO-BE – jak powinien wyglądać po zmianie.

SAP zaleca wyraźne rozdzielanie procesów AS-IS i TO-BE podczas projektowania transformacji, a Microsoft stosuje ten sam podział przy definiowaniu procesów i wymagań dla rozwiązań biznesowych.

Różnica wydaje się prosta, ale właśnie tutaj powstaje wiele błędów.

AS-IS nie pokazuje procedury

Powinien przedstawiać rzeczywisty sposób wykonywania pracy.

Jeżeli oficjalna instrukcja mówi:

zgłoszenie → akceptacja → realizacja

ale pracownik faktycznie:

1. otrzymuje e-mail,
2. kopiuje dane do Excela,
3. pisze do managera na Teams,
4. czeka na potwierdzenie,
5. przenosi dane do drugiego arkusza,
6. loguje się do ERP,
7. tworzy zlecenie,
8. poprawia brakujące informacje,
9. przekazuje sprawę dalej,

mapa AS-IS powinna pokazywać właśnie ten drugi przebieg.

Obejścia, dodatkowe arkusze i nieformalne kanały komunikacji są często najbardziej wartościową częścią analizy.

TO-BE nie jest ładniejszą wersją AS-IS

Model docelowy powinien odpowiadać na problemy znalezione podczas analizy.

Nie chodzi o:

stary krok → ten sam krok, ale automatyczny

lecz o pytanie:

czy ten krok w ogóle powinien istnieć?

Dlatego między AS-IS a TO-BE powinien znajdować się etap analizy i projektowania zmiany.

Nie zaczynaj mapowania od rysowania prostokątów

Pierwszym krokiem powinno być ustalenie zakresu procesu.

Jeżeli nie wiadomo, gdzie proces się zaczyna i kończy, warsztat szybko rozrasta się do dyskusji o całej organizacji.

Przed mapowaniem ustal pięć rzeczy.

1. Co uruchamia proces?

Trigger powinien być konkretny.

Przykłady:

• klient składa zamówienie,
• wpływa faktura,
• pracownik akceptuje ofertę zatrudnienia,
• użytkownik zgłasza incydent,
• handlowiec oznacza lead jako zakwalifikowany.

Nie używaj niejasnych punktów startowych typu:

obsługa klienta się rozpoczyna.

2. Co oznacza zakończenie?

To również musi być rezultat, nie ostatnia czynność administracyjna.

Dla onboardingu pracownika zakończeniem nie musi być:

HR zamknął ticket.

Lepszym rezultatem może być:

pracownik posiada niezbędny sprzęt, konta i dostęp do systemów potrzebnych do rozpoczęcia pracy.

3. Kto jest odbiorcą procesu?

Może to być:

• klient,
• pracownik,
• inny dział,
• dostawca,
• urząd,
• system.

To pomaga później ocenić, które działania rzeczywiście tworzą wartość.

4. Kto jest właścicielem procesu?

Proces przecinający kilka działów nadal powinien mieć kogoś odpowiedzialnego za jego rezultat end-to-end.

Inaczej każdy optymalizuje własny fragment.

5. Jaki problem chcemy zbadać?

Mapowanie bez pytania biznesowego może skończyć się kilkugodzinnym warsztatem i dużym diagramem bez dalszego zastosowania.

Lepsze cele to:

• skrócić czas onboardingu,
• ograniczyć poprawki faktur,
• znaleźć przyczynę opóźnień ofert,
• przygotować proces do wdrożenia ERP,
• znaleźć kandydatów do automatyzacji.

SIPOC może pomóc ustalić granice

Przy większych procesach warto rozpocząć od bardzo wysokiego poziomu.

SIPOC opisuje:

• Suppliers – dostawców wejść,
• Inputs – dane lub zasoby wejściowe,
• Process – główne etapy,
• Outputs – rezultaty,
• Customers – odbiorców.

Nie jest szczegółową mapą procesu.

Ma pomóc uzgodnić:

co właściwie analizujemy?

SIPOC jest wykorzystywany właśnie jako wysokopoziomowa mapa pozwalająca określić główne elementy procesu przed wejściem w szczegóły.

Przykład:

SIPOC	Proces onboardingu
Supplier	HR, manager
Input	dane pracownika, stanowisko, data rozpoczęcia
Process	przygotowanie → konta → sprzęt → szkolenie → aktywacja
Output	pracownik gotowy do pracy
Customer	nowy pracownik, manager

Dopiero później można wejść głębiej.

Kto powinien uczestniczyć w mapowaniu?

Nie mapuj procesu wyłącznie z managerami.

Manager może dobrze znać:

• politykę,
• oczekiwany rezultat,
• zakres odpowiedzialności.

Pracownik operacyjny zna natomiast:

• rzeczywistą kolejność działań,
• wyjątki,
• skróty,
• problemy systemów,
• miejsca, gdzie trzeba czekać,
• informacje przekazywane nieformalnie.

Dlatego w warsztacie warto uwzględnić przedstawicieli najważniejszych etapów procesu.

Przy procesie order-to-cash mogą to być:

• sprzedaż,
• operacje,
• finanse,
• logistyka,
• osoby zarządzające systemami.

Politechnika Lubelska również wskazuje współpracę z przedstawicielami kluczowych działów jako element mapowania zarówno AS-IS, jak i TO-BE.

Jak stworzyć mapę AS-IS krok po kroku?

Krok 1. Zacznij od głównych etapów

Nie próbuj od razu dokumentować każdego kliknięcia.

Najpierw:

zgłoszenie → weryfikacja → decyzja → realizacja → zamknięcie

Dopiero później rozwiń etapy, które są istotne dla problemu.

Krok 2. Przypisz odpowiedzialności

Dla każdego kroku ustal:

kto go wykonuje?

To szybko ujawnia handoffy, czyli miejsca przekazywania pracy pomiędzy osobami lub zespołami.

Każde przekazanie może tworzyć:

• oczekiwanie,
• utratę informacji,
• zmianę priorytetu,
• kolejną kolejkę.

Krok 3. Dodaj systemy

Zaznacz, gdzie używane są:

• CRM,
• ERP,
• Excel,
• e-mail,
• formularz,
• Jira,
• SAP,
• dokument papierowy,
• system branżowy.

Szczególnie interesujące są momenty, w których informacja przechodzi:

System A → człowiek → System B

To częsty kandydat do integracji.

Krok 4. Dodaj decyzje

Proces rzadko jest prostą linią.

Pytaj:

• kiedy sprawa jest akceptowana,
• kiedy trafia do poprawy,
• kiedy wymagany jest dodatkowy approval,
• co powoduje zmianę ścieżki.

Krok 5. Dodaj wyjątki

Nie mapuj wyłącznie happy path.

Jeżeli 20% przypadków wymaga dodatkowej obsługi, ten wariant jest częścią rzeczywistego procesu.

Przykłady:

• brak danych,
• duplikat,
• niewłaściwy dokument,
• nieaktywny klient,
• kwota przekraczająca limit,
• odrzucenie,
• błąd integracji.

Krok 6. Dodaj czas

Dla istotnych etapów zbieraj przynajmniej:

• czas aktywnej pracy,
• czas oczekiwania.

To jedno z najważniejszych rozróżnień.

Proces może mieć godzinę pracy i cztery dni oczekiwania.

Value Stream Mapping również oddziela przepływ wartości od strat i czasu oczekiwania, a Lean Enterprise Institute rekomenduje zaczynanie od mapy rzeczywistego current state, a dopiero później projektowanie future state.

Jakich problemów szukać na mapie?

Sama mapa jest dopiero początkiem.

Po jej stworzeniu przejdź przez każdy fragment i szukaj konkretnych sygnałów.

Oczekiwanie

Pytaj:

Dlaczego sprawa tutaj stoi?

Najczęstsze przyczyny:

• brak osoby decyzyjnej,
• zbyt duża kolejka,
• brak danych,
• ręczny routing,
• zależność od innego działu.

Ręczne przepisywanie danych

Szczególnie interesujące jest:

Excel → CRM

CRM → ERP

e-mail → ticket

Jeżeli dane już istnieją cyfrowo w jednym systemie, warto zapytać, dlaczego człowiek musi przepisywać je do drugiego.

Duplikowanie pracy

Przykład:

sprzedaż sprawdza dane klienta.

Następnie finanse sprawdzają te same dane ponownie.

Być może oba kroki mają uzasadnienie.

Ale trzeba je potwierdzić.

Rework

Jeżeli praca wraca:

A → B → C → B → C

warto znaleźć przyczynę.

Nie ograniczaj się do pytania, jak szybciej wykonać B po raz drugi.

Znacznie ważniejsze:

Dlaczego C odsyła sprawę do B?

Zbyt wiele akceptacji

Approval jest częstym źródłem kolejek.

Pytaj:

• jaka decyzja jest podejmowana,
• jakie ryzyko kontrolujemy,
• czy wszystkie przypadki wymagają takiego samego poziomu zatwierdzenia,
• czy próg został kiedykolwiek zaktualizowany.

Brak właściciela

Niektóre zadania istnieją pomiędzy działami.

Wszyscy są częściowo odpowiedzialni, więc nikt nie jest odpowiedzialny za termin.

Przełączanie systemów

Samo przejście z aplikacji do aplikacji nie zawsze jest problemem.

Ale jeżeli pracownik przez większość zadania:

kopiuje → wkleja → wyszukuje → przepisuje → sprawdza

warto przeanalizować integrację albo RPA.

Jak odróżnić krok potrzebny od zbędnego?

Nie każdy krok manualny jest marnotrawstwem.

Człowiek może wnosić:

• ocenę ryzyka,
• wiedzę ekspercką,
• negocjacje,
• interpretację,
• decyzję.

Dlatego przy każdym etapie można zastosować prostą sekwencję pytań:

Czy krok jest potrzebny?

Jeżeli nie → usuń.

Jeżeli tak:

Czy można go uprościć?

Jeżeli tak → uprość.

Następnie:

Czy powinien być wykonywany zawsze w ten sam sposób?

Jeżeli tak → standaryzuj.

Na końcu:

Czy technologia może wykonać go bezpieczniej lub szybciej?

Dopiero wtedy → automatyzuj.

To ważniejsze niż zaczynanie od pytania:

Make, n8n czy Power Automate?

Projektowanie procesu TO-BE

TO-BE powinien być projektem lepszego procesu, a nie tylko bardziej cyfrowego.

Zacznij od rezultatu.

Przykład:

klient powinien otrzymać zaakceptowaną ofertę w ciągu jednego dnia roboczego.

Następnie zaprojektuj przepływ prowadzący do tego rezultatu.

Eliminuj

Usuń kroki bez uzasadnienia.

Na przykład drugi arkusz prowadzony wyłącznie dlatego, że kiedyś nie było CRM.

Upraszczaj

Zamiast dziesięciu kategorii zgłoszeń być może wystarczą cztery.

Łącz

Dwie kontrole mogą zostać wykonane przez jeden mechanizm.

Przesuwaj decyzje

Nie każda decyzja musi trafiać do najwyższego szczebla.

Można np. ustalić:

do określonego limitu → automatyczna ścieżka

powyżej limitu → manager

Standaryzuj dane

Automatyzacja jest trudna, gdy każde zgłoszenie wygląda inaczej.

Przed automatyzacją warto ujednolicić:

• pola,
• statusy,
• formaty,
• klasyfikacje,
• reguły walidacji.

Automatyzuj dopiero stabilny przepływ

Technologia może następnie przejąć:

• routing,
• aktualizację statusów,
• powiadomienia,
• przypomnienia,
• generowanie dokumentów,
• przenoszenie danych,
• walidację,
• część klasyfikacji.

Microsoft opisuje właśnie taki kierunek: po zrozumieniu AS-IS należy zaprojektować idealniejszy stan TO-BE, usuwając wąskie gardła, zbędne czynności i źródła błędów oraz określając metryki poprawy.

mapowanie procesu obsługi leada na przykładzie

AS-IS

Lead wpływa z formularza.

1. Marketing dostaje e-mail.
2. Pracownik kopiuje dane do arkusza.
3. Raz dziennie przesyła arkusz sprzedaży.
4. Manager sprzedaży przegląda leady.
5. Przypisuje handlowców.
6. Handlowiec ręcznie tworzy kontakt w CRM.
7. Wysyła pierwszą wiadomość.
8. Aktualizuje arkusz.
9. Po kontakcie aktualizuje CRM.

Problemy

Mapa pokazuje:

• dwa źródła statusu: CRM i Excel,
• batching – leady przekazywane raz dziennie,
• ręczne tworzenie rekordów,
• ręczny routing,
• ryzyko niespójnych danych.

Pierwsza zła automatyzacja

Można zbudować automat:

formularz → automatycznie dopisz wiersz do Excela.

Technicznie działa.

Proces praktycznie się nie zmienia.

Lepszy TO-BE

formularz → walidacja → CRM → automatyczne przypisanie według reguły → zadanie dla handlowca → status aktualizowany w CRM

Excel znika.

Batching znika.

Ręczne przepisywanie znika.

Manager interweniuje tylko w przypadkach wymagających decyzji.

To pokazuje różnicę między:

automatyzacją czynności

a:

przeprojektowaniem procesu przed automatyzacją.

AS-IS i TO-BE powinny mieć metryki

Mapa bez danych może prowadzić do ciekawych dyskusji, ale trudno później sprawdzić rezultat zmiany.

Dlatego jeszcze przed wdrożeniem zbierz stan bazowy.

Przydatne mogą być:

Obszar	Metryka
Czas	lead time
Aktywna praca	processing time
Kolejki	waiting time
Jakość	liczba błędów
Rework	odsetek spraw wracających
WIP	liczba otwartych spraw
Automatyzacja	liczba ręcznych kroków
Koszt	koszt obsługi przypadku
Klient	czas do uzyskania rezultatu

Cele docelowe ustalaj dopiero po poznaniu stanu obecnego.

Nie zakładaj z góry, że automatyzacja skróci proces o konkretny procent, jeśli nie masz danych.

Mapowanie procesów a BPMN – nie są tym samym

Mapowanie procesów biznesowych jest metodą poznawania i przedstawiania procesu.

BPMN jest notacją, której można użyć do jego opisania.

To ważne rozróżnienie dla Twojego klastra.

Ten artykuł odpowiada:

jak zbadać proces i przygotować AS-IS/TO-BE

Osobny artykuł BPMN powinien odpowiadać:

jak poprawnie przedstawić poznany proces za pomocą zdarzeń, zadań, bramek, pools i lanes

Nie każdy warsztat potrzebuje BPMN.

Przy prostym procesie wystarczy:

• tablica,
• karteczki,
• prosty flowchart,
• diagram swimlane.

BPMN staje się bardziej wartościowy wtedy, gdy proces ma wiele decyzji, uczestników, komunikatów i ma później stanowić podstawę rozwiązania informatycznego.

W praktycznych projektach AS-IS i TO-BE są również modelowane właśnie za pomocą BPMN, np. w analizach procesów publicznych czy projektach transformacyjnych.

Kiedy wykorzystać diagram swimlane?

Swimlane jest szczególnie użyteczny, gdy największym problemem procesu są odpowiedzialności i przekazania.

Każdy tor reprezentuje np.:

• dział,
• rolę,
• system.

Wtedy od razu widać:

Sprzedaż → Finanse → Operacje → Sprzedaż

Jeżeli pojedyncza sprawa wielokrotnie przechodzi między zespołami, może to być sygnał nadmiernej fragmentacji procesu.

Kiedy wykorzystać Value Stream Mapping?

VSM patrzy szerzej na przepływ wartości i szczególnie mocno eksponuje:

• czas,
• oczekiwanie,
• przepływ informacji,
• czynności tworzące i nietworzące wartości.

Lean Enterprise Institute rozróżnia VSM od bardziej szczegółowego process mappingu: mapa strumienia wartości pokazuje szerszy przepływ end-to-end, natomiast mapa procesu pozwala analizować konkretny proces lub operację bardziej szczegółowo.

VSM jest więc dobrym wyborem, gdy najważniejsze pytanie brzmi:

Gdzie w całym strumieniu klient najdłużej czeka?

Mapowanie procesów a Process Mining

Tutaj granica też powinna być wyraźna.

Mapowanie procesów

Opiera się przede wszystkim na:

• warsztatach,
• wywiadach,
• obserwacji,
• dokumentacji,
• wiedzy uczestników.

Pozwala zrozumieć kontekst.

Process Mining

Analizuje dane zdarzeniowe z systemów.

Pokazuje:

• rzeczywiste warianty procesu,
• czasy,
• powroty,
• częstotliwość,
• odchylenia.

SAP wskazuje, że w bardziej złożonych środowiskach process mining może służyć do weryfikowania map AS-IS na podstawie rzeczywistych danych systemowych.

Najlepszy model:

warsztat mówi, jak ludzie rozumieją proces

dane pokazują, jak proces wykonuje się w skali

Jeżeli obie perspektywy się różnią, właśnie wtedy zaczyna się ciekawa analiza.

Jak przygotować proces do automatyzacji?

Proces nie jest gotowy do automatyzacji tylko dlatego, że został narysowany.

Przed przekazaniem go do zespołu wdrożeniowego sprawdź kilka elementów.

Reguły są jednoznaczne

Źle:

ważne zgłoszenia przekazujemy szybciej.

Lepiej:

zgłoszenia klientów kategorii A z priorytetem P1 trafiają bezpośrednio do zespołu X.

Wyjątki są opisane

Co się dzieje:

• przy błędzie,
• braku danych,
• odrzuceniu,
• niedostępnym systemie?

Dane wejściowe są znane

Skąd automat otrzyma:

• identyfikator,
• klienta,
• kwotę,
• dokument,
• status?

Odpowiedzialność jest ustalona

Kto odpowiada za proces po wdrożeniu automatyzacji?

IT może utrzymywać integrację.

Właściciel biznesowy nadal odpowiada za logikę procesu.

Wiadomo, gdzie potrzebny jest człowiek

Nie każdy krok powinien zostać zautomatyzowany.

Człowiek może pozostać w punktach:

• decyzji o dużym ryzyku,
• negocjacji,
• oceny eksperckiej,
• wyjątków.

Efekt jest mierzalny

Bez baseline nie wiadomo później, czy automatyzacja rzeczywiście pomogła.

Jak wybrać kandydatów do automatyzacji na mapie?

Po zaprojektowaniu procesu można ocenić poszczególne kroki.

Dobry kandydat zwykle:

• występuje często,
• jest powtarzalny,
• działa według reguł,
• korzysta z danych cyfrowych,
• ma znany zakres wyjątków,
• nie wymaga każdorazowo decyzji eksperta,
• powoduje zauważalny koszt lub opóźnienie.

Przykłady:

Ręczne przekazywanie sprawy
→ workflow automation.

Przepisywanie danych między systemami
→ API albo RPA.

Klasyfikowanie ustrukturyzowanych danych
→ reguły.

Klasyfikowanie e-maili według treści
→ możliwe zastosowanie AI.

Zbędna akceptacja
→ usunąć, a nie automatyzować.

To ostatnie jest szczególnie ważne.

Nie każdy problem na mapie wymaga technologii.

Błędy, które psują mapowanie procesów

Mapowanie tego, jak powinno być

AS-IS ma czasami wyglądać źle.

Jeżeli diagram jest zaskakująco prosty, a ludzie mówią, że proces jest bardzo trudny, prawdopodobnie nie pokazano wszystkiego.

Pomijanie wyjątków

Happy path nie wystarcza do zaprojektowania automatyzacji produkcyjnej.

Zbyt duży poziom szczegółowości

Mapa 300 czynności często staje się nieczytelna.

Jeżeli jeden fragment wymaga dużego szczegółu, utwórz podproces.

Zbyt mały poziom szczegółowości

Obsłuż zamówienie

nie pokazuje nic, jeżeli właśnie obsługa zamówienia jest przedmiotem analizy.

Brak użytkowników procesu

Model stworzony wyłącznie na podstawie procedury pokazuje procedurę.

Przeskok z AS-IS prosto do automatyzacji

To najważniejszy błąd w kontekście Twojego serwisu.

Między nimi powinno być:

analiza → uproszczenie → TO-BE.

Automatyzowanie obejścia

Jeżeli pracownik używa Excela dlatego, że system nie wspiera procesu, nie zakładaj automatycznie, że trzeba zautomatyzować Excel.

Może trzeba usunąć przyczynę używania arkusza.

Brak danych bazowych

Po wdrożeniu nie wiadomo wtedy, czy proces się poprawił.

Kiedy mapa AS-IS nie musi być bardzo szczegółowa?

Nie każdy projekt potrzebuje wielotygodniowej dokumentacji.

Jeżeli proces:

• jest prosty,
• ma kilka kroków,
• wykonuje go jeden zespół,
• problem jest oczywisty,

wystarczy prosty warsztat i mapa.

Przykład:

pracownik codziennie:

1. pobiera plik CSV,
2. kopiuje dane,
3. loguje się do CRM,
4. importuje je ręcznie.

Nie trzeba przygotowywać 40-stronicowej dokumentacji, aby stwierdzić, że warto sprawdzić integrację.

Poziom analizy powinien odpowiadać skali problemu.

Kiedy potrzebna jest głębsza analiza?

Więcej pracy warto poświęcić, gdy:

• proces przechodzi przez wiele działów,
• dotyczy dużego wolumenu,
• ma wiele wyjątków,
• jest regulowany,
• będzie podstawą dużego wdrożenia ERP lub CRM,
• automatyzacja może wpłynąć na krytyczne operacje.

W takich przypadkach mapa procesu może stać się również podstawą wymagań dla rozwiązania IT. Microsoft ostrzega, że definiowanie wymagań funkcjonalnych bez odniesienia do zmapowanych procesów może prowadzić do brakujących kroków, błędnych interpretacji i późniejszego odkrywania problemów.

Praktyczny przebieg warsztatu mapowania procesu

Dla średnio złożonego procesu można zastosować taki rytm:

1. Ustal granice procesu.

Start, koniec, odbiorca, właściciel.

2. Zbuduj 5–8 głównych etapów.

Bez wchodzenia w szczegóły.

3. Rozwiń rzeczywiste działania.

Z osobami wykonującymi pracę.

4. Dodaj odpowiedzialności i systemy.

Kto i gdzie pracuje.

5. Dodaj decyzje oraz wyjątki.

Nie tylko podstawową ścieżkę.

6. Oznacz czas pracy i oczekiwania.

Nawet przybliżony na pierwszym warsztacie.

7. Oznacz problemy.

Duplikacja, kolejka, rework, przekazanie, ręczna praca.

8. Zweryfikuj mapę na rzeczywistych przypadkach.

Weź kilka ostatnich zamówień, zgłoszeń lub faktur i przejdź ich historię.

9. Zaprojektuj TO-BE.

Usuń i uprość przed automatyzacją.

10. Ustal metryki oraz działania wdrożeniowe.

Mapa musi prowadzić do konkretnego planu.

Jak przejść od TO-BE do działania?

Po warsztacie nie powinien pozostać tylko diagram.

Przygotuj listę zmian:

Problem	Zmiana	Typ	Właściciel	Miernik
Ręczne przepisywanie	Integracja CRM–ERP	Automatyzacja	IT	czas obsługi
Zbędny approval	Zmiana limitu	Proces	Finanse	waiting time
Brak danych	Walidacja formularza	Proces/IT	Sprzedaż	rework
Powolny routing	Reguły automatyczne	Workflow	Operations	lead time

Wtedy AS-IS i TO-BE są narzędziem zarządzania zmianą, a nie tylko dokumentacją.

Proces gotowy do optymalizacji nie oznacza procesu gotowego do pełnej automatyzacji

To ważne rozróżnienie.

Po mapowaniu może się okazać, że najlepszym usprawnieniem jest:

• usunięcie raportu,
• zmiana odpowiedzialności,
• ograniczenie WIP,
• wcześniejsze zbieranie danych,
• nowa polityka akceptacji.

Automatyzacja jest jedną z możliwych form optymalizacji.

SAP opisuje automatyzację procesów jako koordynowanie zadań, decyzji oraz interakcji systemów w zdefiniowanych przepływach pracy. Żeby taki przepływ zaprojektować dobrze, najpierw trzeba wiedzieć, jaką pracę system rzeczywiście ma koordynować.

Dlatego dobra mapa TO-BE powinna rozróżniać:

człowiek → reguła → system → integracja → AI → wyjątek

a nie zakładać, że każdy element musi zostać przekazany technologii.

Od jakiego procesu zacząć?

Jeżeli organizacja nie mapowała wcześniej procesów, nie zaczynaj od całego przedsiębiorstwa.

Wybierz jeden przepływ:

• o wyraźnym początku i końcu,
• istotny biznesowo,
• z widocznym problemem,
• obejmujący możliwą do opanowania liczbę zespołów.

Dobry przykład:

wpływ zapytania klienta → wysłanie oferty

albo:

wpływ faktury → zaksięgowanie

Następnie:

zmapuj AS-IS → zmierz oczekiwanie → znajdź rework i przekazania → usuń zbędne kroki → zaprojektuj TO-BE → dopiero później oceniaj automatyzację.

To podejście jest bardziej pracochłonne niż rozpoczęcie od wyboru narzędzia, ale znacznie zmniejsza ryzyko zbudowania szybkiej automatyzacji procesu, który od początku powinien wyglądać inaczej.