Mapowanie procesów w firmie: jak stworzyć mapę procesu krok po kroku

Proces, który w głowie ma trzy kroki, w rzeczywistości może mieć ich dwadzieścia

Właściciel firmy mówi:

„Proces jest prosty. Klient wysyła zapytanie, przygotowujemy ofertę i zaczynamy realizację”.

Brzmi logicznie.

Dopóki nie zaczniemy dokładnie sprawdzać, co naprawdę dzieje się pomiędzy tymi trzema punktami.

Klient wysyła formularz.

Wiadomość trafia na wspólną skrzynkę.

Ktoś sprawdza, czego dotyczy zapytanie.

Dane są kopiowane do CRM.

Handlowiec dostaje informację.

Kontaktuje się z klientem.

Po rozmowie zapisuje notatki.

Potrzebuje konsultacji technicznej.

Pisze do innej osoby.

Czeka na odpowiedź.

Przygotowuje brief.

Brief trafia do wyceny.

Brakuje informacji.

Wraca do handlowca.

Handlowiec kontaktuje się z klientem.

Powstaje oferta.

Manager ją zatwierdza.

Dokument trafia do klienta.

Klient akceptuje.

Informacje trzeba przekazać do realizacji.

Nagle proces, który w głowie miał trzy etapy, składa się z kilkunastu lub kilkudziesięciu działań, decyzji, przekazań i punktów oczekiwania.

I właśnie dlatego mapowanie procesów w firmie jest tak wartościowe.

Nie dlatego, że organizacja potrzebuje efektownego diagramu.

Dlatego, że trudno świadomie poprawić proces, którego nikt nigdy nie zobaczył w całości.

Dobra mapa pozwala przestać dyskutować o tym, jak firma powinna działać.

Zaczynamy analizować:

jak działa naprawdę.

Czym jest mapowanie procesów biznesowych?

Mapowanie procesów biznesowych to uporządkowane przedstawienie sposobu, w jaki praca, informacje, decyzje i odpowiedzialność przepływają od określonego zdarzenia początkowego do konkretnego rezultatu.

Najprostsza mapa może wyglądać:

zapytanie → kwalifikacja → rozmowa → wycena → oferta → decyzja klienta

Bardziej użyteczna mapa może dodatkowo pokazywać:

• kto wykonuje każdy etap,
• jakie informacje są potrzebne,
• skąd pochodzą dane,
• gdzie są zapisywane,
• jaki system jest wykorzystywany,
• gdzie występują decyzje,
• ile trwa aktywna praca,
• ile trwa oczekiwanie,
• gdzie odpowiedzialność zmienia osobę lub dział,
• co dzieje się w przypadku błędu,
• jak obsługiwane są wyjątki,
• co uruchamia następny etap,
• jaki rezultat powinien powstać.

American Society for Quality opisuje flowchart jako narzędzie służące do wizualnego przedstawiania kolejnych kroków procesu oraz punktów decyzyjnych.

Ale sam diagram nie jest celem.

Mapa ma pomóc zrozumieć proces i podejmować lepsze decyzje dotyczące jego zmiany.

Mapa procesu nie jest tym samym co procedura

Procedura może mówić:

„Po otrzymaniu zapytania pracownik rejestruje klienta w CRM i przekazuje sprawę do odpowiedniego handlowca”.

Mapa rzeczywistego procesu może pokazać:

formularz → e-mail → sprawdzenie wiadomości → sprawdzenie duplikatu → CRM → ręczne uzupełnienie pól → wiadomość na Teams → oczekiwanie → przypisanie handlowca.

To ogromna różnica.

Procedura opisuje często:

jak proces powinien przebiegać.

Mapa current state powinna pokazywać:

jak przebiega rzeczywiście.

Dlatego mapowania nie powinno się wykonywać wyłącznie na podstawie instrukcji i dokumentacji.

Trzeba zweryfikować ją z osobami, które naprawdę wykonują pracę.

Dobra mapa nie musi być skomplikowana

Proces można opisać na 50 stronach.

Można stworzyć diagram ze 150 symbolami.

Można wykorzystać zaawansowaną notację.

Nic z tego nie gwarantuje lepszego zrozumienia procesu.

Dobra mapa powinna umożliwiać odpowiedź na praktyczne pytania:

Co rozpoczyna proces?

Jaki ma osiągnąć rezultat?

Co dzieje się po kolei?

Kto wykonuje dane działanie?

Kto podejmuje decyzję?

Jakie informacje są potrzebne?

W których systemach odbywa się praca?

Gdzie odpowiedzialność przechodzi dalej?

Gdzie proces czeka?

Gdzie może popełnić błąd?

Jak obsługujemy wyjątki?

Po czym wiemy, że proces został zakończony?

Najlepsza mapa procesu nie jest najbardziej szczegółowa.

Jest wystarczająco szczegółowa do podjęcia właściwej decyzji.

Najpierw AS-IS, później TO-BE

To jedna z najważniejszych zasad mapowania procesów.

Podczas warsztatu ktoś mówi:

„Tutaj automatycznie twórzmy zadanie”.

Ktoś inny:

„Tu można dać AI”.

Kolejna osoba:

„Ten etap najlepiej całkowicie usunąć”.

Wszystkie pomysły mogą mieć sens.

Ale na początku należy je odłożyć.

Najpierw trzeba stworzyć:

AS-IS / current state

czyli obraz tego, jak proces działa obecnie.

Dopiero później:

TO-BE / future state

czyli sposób, w jaki proces powinien działać po zmianach.

Value Stream Mapping wykorzystuje dokładnie tę logikę: zespół najpierw odwzorowuje rzeczywisty obecny przepływ materiałów i informacji, a później projektuje przyszły stan.

To chroni przed częstym błędem:

projektowaniem rozwiązania przed zrozumieniem problemu.

Nie poprawiaj procesu podczas tworzenia mapy AS-IS

To pokusa.

Widzisz ręczne przepisywanie danych i od razu chcesz je usunąć.

Widzisz dodatkową akceptację i zaczynasz projektować regułę.

Widzisz e-mail i od razu myślisz o integracji.

Lepiej najpierw dokończyć obraz stanu obecnego.

Dlaczego?

Bo późniejsza część procesu może wyjaśnić, dlaczego dany etap istnieje.

Może się również okazać, że problem, który początkowo wydawał się najważniejszy, nie ma dużego wpływu na wynik całego procesu.

Najpierw:

zrozum.

Później:

oceniaj.

Na końcu:

projektuj.

Nie mapuj procesu z pamięci jednego managera

Manager mówi:

„Po podpisaniu umowy sprzedaż przekazuje wszystkie informacje do realizacji”.

Handlowiec:

„Po spotkaniu przygotowuję podsumowanie i wrzucam je do CRM”.

Project manager:

„Zwykle nie mam tam wszystkich danych, więc pytam handlowca”.

Realizacja:

„My i tak sprawdzamy jeszcze wiadomości, bo czasem ustalenia są inne”.

Która wersja jest prawdziwa?

W pewnym sensie wszystkie.

Każda osoba widzi inny fragment procesu.

Dlatego mapowanie end-to-end powinno angażować osoby rzeczywiście wykonujące kolejne etapy pracy.

Manager może znać model.

Pracownik zna praktykę.

IT zna system.

Sprzedaż zna klienta.

Back office zna wyjątki.

Dopiero połączenie tych perspektyw daje sensowny obraz.

Zweryfikuj proces na prawdziwych przypadkach

Sama rozmowa również nie wystarcza.

Zapytaj pracownika:

„Jak dodajesz nowego klienta?”

Odpowiedź:

„Normalnie. Wpisuję go do CRM”.

To jedno zdanie może oznaczać:

otwarcie wiadomości,

sprawdzenie danych,

wyszukanie firmy,

kontrolę duplikatu,

skopiowanie telefonu,

dodanie źródła,

przypisanie ownera,

wklejenie notatki,

utworzenie szansy,

ustawienie etapu,

utworzenie zadania,

wysłanie wiadomości handlowcowi.

Dlatego podczas mapowania warto przejść przez kilka prawdziwych spraw.

Nie pytaj tylko:

„Jak zazwyczaj to robicie?”

Poproś:

„Pokaż mi ostatni przypadek od początku do końca”.

Proces musi mieć jasno określony początek i koniec

„Mapujemy sprzedaż”.

To za szeroko.

Gdzie sprzedaż zaczyna się w tym konkretnym projekcie?

Od reklamy?

Wejścia na stronę?

Formularza?

Rozmowy?

SQL-a?

A kiedy się kończy?

Po wysłaniu oferty?

Podpisaniu umowy?

Wpłacie?

Przekazaniu do realizacji?

Lepszy zakres:

Początek: potencjalny klient wysyła formularz na stronie.

Koniec: zakwalifikowany lead ma właściciela i ustalony kolejny krok w CRM.

Albo:

Początek: klient akceptuje ofertę.

Koniec: realizacja posiada komplet informacji potrzebnych do rozpoczęcia projektu.

Dzięki temu wiadomo:

co mapujemy,

a czego świadomie nie mapujemy.

Każdy proces powinien prowadzić do konkretnego wyniku

Proces istnieje po coś.

Nie:

„bo zawsze tak robiliśmy”.

Obsługa nowego leada może kończyć się wynikiem:

zakwalifikowany lead został przypisany i ma zaplanowane następne działanie.

Onboarding klienta:

zespół posiada komplet informacji i może rozpocząć realizację.

Raportowanie:

osoba decyzyjna otrzymała aktualną informację potrzebną do podjęcia decyzji.

Proces reklamacyjny:

sprawa została rozwiązana, klient poinformowany, a przyczyna zapisana.

To ważne.

Jeżeli nie umiemy jasno określić rezultatu, bardzo trudno później odpowiedzieć:

czy proces działa dobrze?

Jak stworzyć mapę procesu krok po kroku?

Profesjonalne mapowanie można przeprowadzić bez skomplikowanego oprogramowania.

Najważniejsza jest kolejność analizy.

Krok 1. Zdefiniuj problem albo cel mapowania

Nie mapuj procesu dlatego, że „warto mieć procesy opisane”.

Ustal, dlaczego to robisz.

Na przykład:

• leady czekają zbyt długo,
• oferty powstają za wolno,
• onboarding nowych klientów jest chaotyczny,
• dane są przepisywane pomiędzy systemami,
• zespół wykonuje dużo ręcznej pracy,
• trudno wdrażać nowych pracowników,
• firma chce przygotować proces do automatyzacji,
• planowane jest wdrożenie AI,
• nie wiadomo, gdzie znajduje się wąskie gardło.

Cel determinuje poziom szczegółowości mapy.

Jeżeli interesuje Cię czas obsługi klienta, musisz mierzyć oczekiwanie.

Jeżeli przygotowujesz automatyzację, ważne będą dane, systemy i wyjątki.

Jeżeli problemem jest odpowiedzialność, kluczowe staną się role i handoffy.

Krok 2. Określ początek i koniec

Zapisz konkretne zdarzenie początkowe.

Na przykład:

„formularz został wysłany”.

I konkretne zakończenie:

„handlowiec ma kompletne dane i zaplanowane następne działanie”.

Unikaj granic typu:

„obsługa klienta”.

„sprzedaż”.

„realizacja”.

Im bardziej precyzyjne granice, tym łatwiej przeprowadzić analizę.

Krok 3. Zidentyfikuj uczestników

Kto uczestniczy w przepływie?

Nie tylko formalne działy.

Może to być:

• klient,
• marketing,
• SDR,
• handlowiec,
• manager,
• księgowość,
• back office,
• project manager,
• realizacja,
• system informatyczny,
• zewnętrzny dostawca.

To szczególnie ważne przy mapach typu swimlane.

Krok 4. Rozpisz rzeczywiste działania w kolejności

Na tym etapie nie oceniaj.

Zapisuj.

Co dzieje się po kolei?

Użytkownik wysyła formularz.

Powstaje e-mail.

Pracownik sprawdza wiadomość.

Weryfikuje firmę.

Tworzy rekord.

Przypisuje handlowca.

Handlowiec kontaktuje się z klientem.

Po rozmowie uzupełnia dane.

I tak dalej.

Jeżeli pracownicy mówią:

„to zależy”,

nie próbuj od razu wymusić jednej ścieżki.

To sygnał, że trzeba dodać decyzję albo wyjątek.

Krok 5. Dodaj decyzje

Proces rzadko jest prostą linią.

Pojawiają się pytania:

Czy dane są kompletne?

Czy lead pasuje?

Czy rabat mieści się w limicie?

Czy dokument wymaga dodatkowej akceptacji?

Czy klient już istnieje?

Czy sprawa jest standardowa?

Każda odpowiedź może prowadzić do innej ścieżki.

Decyzje są szczególnie ważne przed automatyzacją.

System musi wiedzieć:

według jakiej reguły wybrać dalsze działanie?

Krok 6. Dodaj dane

Przy każdym ważniejszym etapie zapytaj:

Jakie informacje są potrzebne?

Skąd pochodzą?

Gdzie są zapisane?

Czy są strukturalne?

Czy są kompletne?

Czy człowiek musi je przepisywać?

Przykładowo kwalifikacja leada może potrzebować:

• nazwy firmy,
• branży,
• wielkości przedsiębiorstwa,
• rodzaju problemu,
• budżetu,
• terminu,
• danych kontaktowych.

Jeżeli procesu nie da się wykonać bez tych informacji, mapa powinna to pokazać.

Krok 7. Dodaj systemy

Przy każdym etapie zapisz, gdzie wykonywana jest praca.

Może to być:

• CRM,
• ERP,
• poczta,
• formularz,
• Excel,
• Google Sheets,
• Slack,
• Teams,
• system projektowy,
• system księgowy,
• baza danych,
• aplikacja branżowa.

Dzięki temu zaczynają być widoczne miejsca, w których człowiek pełni rolę integracji.

Krok 8. Dodaj czas

Szczególnie przy procesach wymagających optymalizacji.

Rozdziel:

czas aktywnej pracy

od:

czasu oczekiwania.

Przykład:

uzupełnienie danych — 5 minut,

oczekiwanie na przypisanie — 3 godziny,

rozmowa — 30 minut,

przygotowanie oferty — 40 minut,

oczekiwanie na akceptację — 16 godzin.

Nagle widać, że problemem nie musi być wydajność osoby przygotowującej ofertę.

Krok 9. Dodaj wyjątki i ścieżki błędów

Co się dzieje, jeśli:

• brakuje numeru telefonu,
• klient jest już w CRM,
• dokument ma błędny format,
• system nie odpowiada,
• kwota przekracza limit,
• klient nie odpowiada,
• AI nie potrafi jednoznacznie sklasyfikować sprawy,
• integracja zwraca błąd?

Proces, który działa tylko przy idealnym przypadku, nie jest wystarczająco opisany do odpowiedzialnej automatyzacji.

Krok 10. Zweryfikuj mapę na realnych przypadkach

Weź kilka prawdziwych spraw.

Przejdź przez mapę krok po kroku.

Czy rzeczywiście tak przebiegły?

Czy czegoś brakuje?

Czy pojawiła się dodatkowa osoba?

Czy dane znajdowały się w innym miejscu?

Czy wystąpiła ścieżka, której nie uwzględniono?

Dopiero wtedy mapa zaczyna przedstawiać rzeczywistość.

Nie pytaj wyłącznie „co robisz?”

To pytanie jest za wąskie.

Lepszy zestaw pytań:

Co uruchamia Twoją pracę?

Skąd wiesz, że masz coś zrobić?

Jakie dane musisz otrzymać?

Skąd je bierzesz?

Co sprawdzasz?

Jak podejmujesz decyzję?

Gdzie zapisujesz rezultat?

Komu przekazujesz sprawę?

Co robisz, gdy danych brakuje?

Co robisz, gdy przypadek jest nietypowy?

Skąd kolejna osoba wie, że może rozpocząć pracę?

Co najczęściej powoduje powrót sprawy?

Na co najczęściej czekasz?

Te pytania odsłaniają proces znacznie lepiej niż:

„opowiedz mi, czym się zajmujesz”.

Mapuj również przepływ informacji

To jeden z najczęściej pomijanych elementów.

Proces to nie tylko działania.

To również informacja.

Wyobraźmy sobie:

sprzedaż → realizacja.

Strzałka wygląda bardzo prosto.

Ale co właściwie przechodzi tą strzałką?

• dane klienta,
• zakres,
• cena,
• deadline,
• kontakt,
• notatki,
• pliki,
• obietnice sprzedażowe,
• informacje o wyjątkach.

W jakiej formie?

CRM?

E-mail?

Slack?

PDF?

Notatka?

Rozmowa?

Jeżeli informacja jest niekompletna albo rozproszona, nawet dobrze zaprojektowane zadania mogą się zatrzymywać.

Człowiek często jest niewidzialną integracją pomiędzy systemami

Mapa może pokazać coś takiego:

formularz → pracownik → CRM → pracownik → Excel → pracownik → ERP

Technicznie systemy „współpracują”.

W praktyce współpracują dlatego, że pomiędzy nimi siedzi człowiek i przenosi dane.

To jeden z najważniejszych sygnałów przed automatyzacją.

Zaznacz na mapie każdy moment, w którym człowiek:

• kopiuje informacje,
• eksportuje plik,
• importuje plik,
• przepisuje numer,
• tworzy rekord na podstawie innego rekordu,
• wysyła dane pomiędzy systemami.

Nie oznacza to automatycznie, że każdy taki krok należy automatyzować.

Ale każdy powinien zostać przeanalizowany.

Handoff to jedno z najważniejszych miejsc na mapie

Handoff to moment, kiedy odpowiedzialność przechodzi z jednej osoby, zespołu albo systemu do innego.

Na przykład:

marketing → sprzedaż,

sprzedaż → realizacja,

realizacja → księgowość,

AI → człowiek.

Właśnie tutaj często powstają problemy:

• brak danych,
• brak właściciela,
• oczekiwanie,
• niejasny status,
• utrata kontekstu,
• duplikacja pracy.

Dlatego przy każdym przekazaniu warto zapytać:

Co dokładnie jest przekazywane?

Komu?

Kiedy?

W jakim systemie?

Po czym odbiorca wie, że może zacząć?

Co się stanie, jeśli czegoś brakuje?

Dodaj właściciela każdego etapu

Każde działanie powinno mieć jasno określonego wykonawcę albo odpowiedzialny system.

Nie:

„sprzedaż”.

Jeżeli to potrzebne:

„account executive”.

„SDR”.

„sales manager”.

Przy bardziej ogólnej mapie nazwa działu wystarczy.

Przy problemach odpowiedzialności warto zejść niżej.

Najważniejsze:

nie zostawiaj kroków, które po prostu „się dzieją”.

Odróżnij wykonawcę zadania od właściciela całego procesu

Marketing pozyskuje lead.

Sales kwalifikuje.

Back office przygotowuje ofertę.

Manager zatwierdza.

Handlowiec wysyła.

Każdy odpowiada za swój etap.

Ale kto odpowiada za wynik:

„klient otrzymuje prawidłową ofertę w odpowiednim czasie”?

To właściciel procesu.

Jeżeli odpowiedź brzmi:

„wszyscy”,

często w praktyce oznacza:

„nikt”.

Mapa procesu powinna pomóc zobaczyć nie tylko lokalne odpowiedzialności, ale również ownership całego przepływu.

Dodaj czas pracy i czas oczekiwania

Proces może zawierać 90 minut aktywnej pracy i trwać tydzień.

Bez pomiaru oczekiwania mapa może tego nie pokazać.

Dlatego przy ważniejszych etapach warto zapisać:

processing / working time

oraz:

waiting time.

To pozwala znaleźć miejsca, gdzie proces „stoi”, mimo że nikt aktywnie nad nim nie pracuje.

Jeżeli chcesz szerzej analizować właśnie takie miejsca, powiązanym materiałem jest:

Wąskie gardła w firmie: jak je znaleźć i usunąć, zanim zaczną blokować rozwój

`/poradnik/waskie-gardla-w-firmie/`

Zaznacz powroty do wcześniejszych etapów

Procesy bardzo rzadko są prostą linią.

Oferta wraca do poprawy.

Brief wraca do handlowca.

Dokument wraca do klienta.

Faktura wraca do księgowości.

Projekt wraca do wcześniejszego etapu.

Każdy powrót oznacza potencjalny rework.

Warto sprawdzić:

jak często występuje?

dlaczego?

ile kosztuje?

czy można usunąć jego przyczynę wcześniej?

Jeżeli 40% ofert wraca po brakujące dane, problemem może nie być etap ofertowania.

Problem może znajdować się w sposobie zbierania informacji podczas sprzedaży.

Zaznacz ręczne kontrole i akceptacje

„Manager zatwierdza”.

Dlaczego?

Czy:

• każdą sprawę,
• tylko powyżej określonej wartości,
• wyjątki,
• określone rabaty,
• klientów wysokiego ryzyka?

Mapa powinna pokazywać regułę.

Nie tylko sam fakt istnienia akceptacji.

To ważne, ponieważ później można zdecydować:

które przypadki powinny przechodzić standardową ścieżką,

a które rzeczywiście wymagają człowieka.

Wyjątki powinny być częścią mapy

Proces:

formularz → CRM → handlowiec.

Świetnie.

A jeśli formularz nie ma numeru telefonu?

A jeśli firma już istnieje?

A jeśli zgłoszenie jest spamem?

A jeśli klient wybierze dwie usługi?

A jeśli CRM nie odpowiada?

A jeśli nie uda się znaleźć odpowiedniego ownera?

Wyjątki nie są dodatkiem do procesu.

W wielu firmach stanowią dużą część codziennej pracy.

Jeżeli automatyzacja nie wie, co zrobić z wyjątkiem, człowiek musi dostać:

• informację,
• kontekst,
• jasny sposób przejęcia sprawy.

Jaki rodzaj mapy procesu wybrać?

Nie istnieje jeden najlepszy diagram dla wszystkich sytuacji.

Wybór zależy od pytania, na które próbujesz odpowiedzieć.

Prosty flowchart

Najlepszy, gdy chcesz szybko zobaczyć:

co dzieje się po kolei?

Pokazuje:

działania,

decyzje,

kolejność,

podstawowe ścieżki.

Dobry dla prostych i średnio złożonych procesów.

Swimlane

Przydatny, gdy głównym problemem jest:

kto za co odpowiada i gdzie praca przechodzi między osobami lub działami?

Każda osoba, rola albo system otrzymuje swój „tor”.

Dzięki temu bardzo szybko widać handoffy.

SIPOC

Przydatny na początku, gdy najpierw trzeba zobaczyć proces z wysokiego poziomu.

SIPOC oznacza:

Suppliers – Inputs – Process – Outputs – Customers

czyli:

dostawcy,

wejścia,

proces,

wyniki,

odbiorcy.

Nie zastępuje szczegółowej mapy procesu.

Pomaga ustalić zakres i główne elementy przed zejściem do szczegółów.

BPMN

Business Process Model and Notation jest formalną notacją rozwijaną przez Object Management Group.

BPMN zaczyna mieć szczególną wartość, kiedy proces:

• jest rozbudowany,
• posiada wiele ścieżek,
• zawiera komunikację pomiędzy uczestnikami,
• wymaga dokładnego określenia zdarzeń,
• jest przygotowywany do implementacji technicznej,
• musi być jednoznacznie zrozumiały dla analityków i developerów.

Nie oznacza to jednak, że każda firma powinna rozpoczynać mapowanie od BPMN.

Jeżeli celem jest dwugodzinny warsztat nad prostym onboardingiem, zwykły swimlane może być bardziej użyteczny.

Value Stream Mapping

VSM patrzy szerzej na przepływ wartości oraz informacji.

Jest szczególnie przydatny, kiedy interesuje Cię:

• cały strumień,
• czas przejścia,
• czas aktywnej pracy,
• kolejki,
• przepływ informacji,
• działania tworzące i nietworzące wartości,
• current state i future state.

Mapa procesu i VSM nie są dokładnie tym samym narzędziem.

Mogą się jednak bardzo dobrze uzupełniać.

BPMN nie jest celem samym w sobie

Formalny diagram, którego rozumie wyłącznie analityk, ale którego nie potrafią zweryfikować pracownicy wykonujący proces, ma ograniczoną wartość.

Najpierw zrozumienie.

Później formalizacja.

BPMN powinien zwiększać jednoznaczność.

Nie zwiększać dystans pomiędzy mapą a ludźmi, którzy mają według niej pracować.

Swimlane jest bardzo dobrym narzędziem do odkrywania problemów organizacyjnych

Załóżmy trzy tory:

Klient

Sprzedaż

Back office

Mapa pokazuje:

klient wysyła formularz,

sprzedaż analizuje,

back office uzupełnia dane,

sprzedaż sprawdza,

back office przygotowuje dokument,

sprzedaż poprawia,

manager akceptuje.

Widać, że sprawa wielokrotnie przechodzi pomiędzy osobami.

Sam proces może zawierać niewiele pracy.

Ale wiele przekazań.

To właśnie liczba handoffów może generować:

• oczekiwanie,
• utratę kontekstu,
• nieporozumienia,
• dodatkową komunikację.

SIPOC pomaga ustawić zakres przed szczegółowym mapowaniem

Załóżmy, że mapujesz onboarding klienta.

Suppliers

Kto dostarcza dane?

Klient.

Sprzedaż.

Księgowość.

Inputs

Czego potrzebujemy?

Podpisanej umowy.

Danych klienta.

Zakresu.

Plików.

Terminu.

Process

Na wysokim poziomie:

weryfikacja → zebranie danych → konfiguracja → przekazanie → start.

Outputs

Co ma powstać?

Kompletny projekt gotowy do realizacji.

Customers

Kto wykorzystuje wynik?

Klient.

Project manager.

Zespół realizacyjny.

Już ten prosty model potrafi ujawnić, że organizacja nie wie na przykład:

jakie dokładnie dane są wymagane przed rozpoczęciem pracy.

Mapa powinna uwzględniać wartość z perspektywy klienta

Łatwo stworzyć proces zoptymalizowany pod wewnętrzną strukturę.

Każdy dział ma swoje:

statusy,

akceptacje,

formularze,

raporty.

Klient widzi tylko:

„czekam”.

Dlatego dla poszczególnych etapów warto zadawać pytanie:

Czy ten krok tworzy wartość dla klienta lub jest konieczny do prawidłowego działania procesu?

Jeżeli nie:

dlaczego istnieje?

Nie oznacza to, że wszystkie działania wewnętrzne są zbędne.

Kontrola bezpieczeństwa nie musi tworzyć bezpośrednio wartości widocznej dla klienta, ale może być konieczna.

Chodzi o świadome rozróżnienie.

Przykład mapowania procesu obsługi nowego leada

Stan obecny

1. klient wysyła formularz,
2. wiadomość trafia na e-mail,
3. marketing odczytuje wiadomość,
4. pracownik sprawdza dane,
5. kopiuje kontakt do CRM,
6. sprawdza duplikat,
7. wybiera handlowca,
8. wysyła mu informację,
9. handlowiec otwiera CRM,
10. kontaktuje się z klientem,
11. zapisuje notatkę,
12. tworzy kolejne zadanie.

Po dodaniu czasu:

formularz → natychmiast,

oczekiwanie na marketing → średnio 90 minut,

ręczna obsługa → 4 minuty,

oczekiwanie na handlowca → 2 godziny,

kontakt → 15 minut.

Aktywnej pracy:

niecałe 20 minut.

Całkowity czas:

kilka godzin.

Co pokazuje mapa?

Dane są przepisywane ręcznie.

Przypisanie wymaga człowieka.

Nie istnieje jasna kontrola czasu reakcji.

Duża część procesu to oczekiwanie.

Future state

formularz → walidacja → CRM → kontrola duplikatu → automatyczne przypisanie → zadanie → powiadomienie → handlowiec.

Nietypowe przypadki:

osobna kolejka do ręcznej kwalifikacji.

Jeżeli opis potrzeby wymaga interpretacji, AI może wspierać klasyfikację.

Widzimy dokładnie, gdzie technologia ma rolę, a gdzie jej nie potrzebujemy.

Przykład mapowania onboardingu klienta

Stan obecny

Klient podpisuje umowę.

Handlowiec informuje PM-a.

PM prosi o dane.

Klient wysyła część informacji.

PM dopytuje.

Sprzedaż przesyła notatki.

Brakuje plików.

Klient dosyła materiały.

Realizacja pyta o zakres.

Handlowiec wyjaśnia.

Projekt zaczyna się po kilku dniach.

Mapa może ujawnić

brak jednego momentu kompletacji danych,

kilka źródeł prawdy,

brak standardu handoffu sprzedaż → realizacja,

niejasne wymagania dotyczące startu.

Future state

Po podpisaniu umowy uruchamiany jest jeden proces.

Klient otrzymuje formularz onboardingowy.

Wymagane dane są walidowane.

Sprzedaż uzupełnia część wewnętrzną.

System sprawdza kompletność.

Project manager otrzymuje projekt dopiero wtedy, kiedy spełnione są kryteria rozpoczęcia.

Nie przyspieszyliśmy ludzi.

Usunęliśmy niepotrzebne oczekiwanie i dopytywanie.

Przykład mapowania przygotowywania oferty

Current state

spotkanie → notatki → brief → przekazanie → weryfikacja → pytanie do handlowca → odpowiedź → wycena → dokument → akceptacja → wysłanie.

Problem?

Zespół mówi:

„oferty tworzymy zbyt wolno”.

Mapa z czasami pokazuje:

tworzenie dokumentu — 25 minut,

wycena — 30 minut,

oczekiwanie na brakujące dane — średnio 6 godzin,

akceptacja — średnio 10 godzin.

Problemem nie jest samo pisanie oferty.

Jeżeli firma od razu wdroży AI do generowania dokumentu i skróci 25 minut do 5, cały proces nadal może trwać prawie tyle samo.

Mapa chroni przed optymalizacją niewłaściwego miejsca.

Proces przed technologią

To jedna z najważniejszych zasad.

Firma mówi:

„Potrzebujemy n8n”.

„Musimy wdrożyć AI”.

„Kupmy nowy CRM”.

„Zróbmy bota”.

To rozwiązania.

Najpierw trzeba znać problem.

Poprawna kolejność wygląda bardziej tak:

cel → current state → problem → przyczyna → future state → wymaganie → technologia

Nie:

narzędzie → szukanie miejsca, gdzie można go użyć.

Jak mapa procesu przygotowuje firmę do automatyzacji?

Automatyzacja wymaga jednoznaczności.

System musi wiedzieć:

co uruchamia proces?

Jakie dane otrzymuje?

Co ma zrobić?

Według jakich reguł?

Co jest wynikiem?

Co oznacza błąd?

Co jest wyjątkiem?

Kiedy potrzebny jest człowiek?

Mapa procesu dostarcza odpowiedzi na większość tych pytań.

Dzięki temu dużo łatwiej przejść później do automatyzacji procesów w firmie.

Jak mapa procesu przygotowuje firmę do wdrożenia AI?

AI nie jest zamiennikiem mapowania procesu.

Wręcz przeciwnie.

Im bardziej autonomicznie ma działać system, tym ważniejsze jest określenie jego miejsca w procesie.

Mapa powinna odpowiedzieć:

Co AI otrzymuje?

Jakiego wyniku oczekujemy?

Na podstawie jakiej wiedzy pracuje?

Co dzieje się przy niskiej pewności?

Kiedy wynik musi zatwierdzić człowiek?

Jak rejestrowana jest decyzja?

Co dzieje się po błędzie?

Przykład:

AI klasyfikuje zgłoszenie supportowe.

To jeszcze nie jest proces.

Proces brzmi:

zgłoszenie → walidacja → AI określa kategorię → wysoka pewność → automatyczny routing → niska pewność → kolejka człowieka → przypisanie → obsługa.

Dopiero teraz wiadomo, jak AI funkcjonuje w systemie.

Ścieżka błędu jest równie ważna jak happy path

W prezentacji automatyzacji często widzimy:

formularz → AI → CRM → e-mail.

Świetnie.

A jeśli API CRM nie odpowie?

Jeżeli AI zwróci nieprawidłową odpowiedź?

Jeżeli klient nie poda danych?

Jeżeli rekord już istnieje?

Jeżeli integracja wykona operację dwa razy?

Profesjonalna mapa powinna pokazywać:

• walidację,
• retry,
• logowanie błędu,
• alert,
• ręczną kolejkę,
• eskalację.

Nie każdy element trzeba wizualizować na mapie biznesowej.

Ale przed implementacją techniczną powinien być świadomie zaprojektowany.

Nie zaczynaj od mapowania całej firmy

To częsty błąd.

„Zmapujemy wszystkie procesy”.

Sprzedaż.

Marketing.

HR.

Finanse.

Realizacja.

Support.

Zakupy.

Zarządzanie.

Po trzech miesiącach powstaje ogromna biblioteka diagramów.

A firma nadal pracuje tak samo.

Lepsze podejście:

wybierz jeden proces o realnym znaczeniu biznesowym.

Zmapuj.

Popraw.

Zmierz.

Dopiero potem przejdź dalej.

Mapowanie powinno prowadzić do decyzji.

Nie do kolekcjonowania diagramów.

Który proces warto zmapować jako pierwszy?

Dobrym kandydatem jest proces, który:

• występuje często,
• ma znaczenie dla klienta lub przychodu,
• angażuje kilka osób,
• przechodzi przez kilka systemów,
• regularnie się opóźnia,
• generuje błędy,
• wymaga wielu ręcznych działań,
• posiada dużą liczbę wyjątków,
• powoduje pytania o status,
• ma zostać zautomatyzowany.

Jeżeli proces występuje dwa razy w roku, działa poprawnie i kosztuje godzinę pracy, prawdopodobnie nie jest najlepszym pierwszym kandydatem.

Kiedy mapowania nie warto nadmiernie rozbudowywać?

Nie każdy przypadek wymaga kilkudniowego warsztatu.

Nie ma sensu tworzyć zaawansowanego modelu, kiedy:

proces jest bardzo prosty,

wykonuje go jedna osoba,

praktycznie nie występują wyjątki,

problem jest już jednoznacznie znany,

koszt błędu jest niski,

proces wkrótce zostanie całkowicie usunięty.

Mapa jest narzędziem.

Jej koszt powinien być proporcjonalny do wartości decyzji, którą ma umożliwić.

Jak priorytetyzować problemy znalezione na mapie?

Po zmapowaniu procesu możesz znaleźć 20 problemów.

Nie naprawiaj wszystkich jednocześnie.

Oceń każdy przynajmniej według:

Wpływu

Jak wpływa na:

sprzedaż,

klienta,

koszt,

ryzyko,

czas zespołu?

Częstotliwości

Jak często problem występuje?

Skali

Ile spraw obejmuje?

Wysiłku

Jak trudno wprowadzić zmianę?

Ryzyka

Co może pójść źle?

Zależności

Czy przed zmianą trzeba poprawić coś innego?

Następnie zacznij od zmian, które mają istotny wpływ i rozsądny koszt wdrożenia.

Mierz proces przed zmianą

Bez stanu bazowego bardzo łatwo powiedzieć:

„jest lepiej”.

Ale o ile?

Przed zmianą warto zmierzyć na przykład:

• lead time,
• czas aktywnej pracy,
• czas oczekiwania,
• liczbę ręcznych działań,
• liczbę przekazań,
• liczbę błędów,
• rework,
• czas reakcji,
• procent spraw wymagających wyjątku.

Po wdrożeniu przyszłego procesu wykonaj ten sam pomiar.

Dzięki temu optymalizacja staje się eksperymentem możliwym do oceny.

Future state powinien być prostszy, a nie tylko bardziej cyfrowy

Current state:

e-mail → Excel → CRM → wiadomość → ręczny raport.

Źle zaprojektowany future state:

e-mail → automatyzacja → Excel → integracja → CRM → bot → raport.

Technologii jest więcej.

Czy proces jest lepszy?

Niekoniecznie.

Lepszy future state może wyglądać:

formularz → CRM → reguła → właściciel

z raportem tworzonym bezpośrednio na podstawie CRM.

Celem nie jest cyfryzacja każdego istniejącego kroku.

Celem jest zaprojektowanie lepszego przepływu.

Dobra kolejność: usuń, uprość, ustandaryzuj, dopiero potem automatyzuj

Przed automatyzacją każdego etapu zadaj pytania:

Czy ten krok musi istnieć?

Jeżeli tak:

Czy może być prostszy?

Następnie:

Czy możemy ustalić standard?

Dopiero potem:

Czy warto go zautomatyzować?

A gdy zadanie wymaga interpretacji tekstu, dokumentów albo nieustrukturyzowanej informacji:

Czy AI daje tutaj przewagę nad klasyczną regułą?

Taka kolejność chroni przed automatyzowaniem organizacyjnego długu.

Mapowanie procesów a audyt procesów

Te pojęcia są powiązane, ale nie identyczne.

Mapowanie procesu odpowiada głównie:

„Jak proces działa?”

Audyt procesów idzie dalej:

„Co w nim nie działa, dlaczego i co powinniśmy zmienić?”

Mapa jest więc często jednym z najważniejszych elementów audytu.

Jeżeli potrzebujesz szerszego podejścia obejmującego diagnozę, problemy, przyczyny, priorytety i rekomendacje, zobacz:

Audyt procesów w firmie: jak znaleźć straty, błędy i procesy do automatyzacji

`/poradnik/audyt-procesow-w-firmie/`

oraz usługę:

Audyt procesów w firmie – ExperciAI

Podejście procesowe pozostaje fundamentem zarządzania jakością

Podejście procesowe nie jest wyłącznie metodą używaną przy automatyzacji.

Jest jednym z fundamentów systemowego zarządzania organizacją.

ISO 9001 opiera zarządzanie między innymi na identyfikowaniu procesów, ich zależności, oczekiwanych rezultatów, odpowiedzialności, mierników i ciągłym doskonaleniu.

To ważna perspektywa.

Proces nie jest tylko diagramem.

Jest sposobem osiągania wyniku organizacji.

Mapa pomaga ten sposób zobaczyć.

Proces, który działa dzisiaj, może przestać działać przy większej skali

Firma otrzymuje 20 leadów miesięcznie.

Founder czyta każdy formularz.

Przypisuje go handlowcowi.

Działa świetnie.

Firma rośnie.

200 leadów.

Founder nie nadąża.

Pojawia się asystent.

500 leadów.

Potrzebna jest kolejna osoba.

Proces, który wcześniej był racjonalny, stał się ograniczeniem.

To samo dotyczy:

• akceptacji,
• faktur,
• ofert,
• onboardingu,
• raportów,
• przekazywania projektów.

Dlatego mapę warto ponownie przeglądać po istotnych zmianach skali, struktury albo technologii.

Najczęstsze błędy podczas mapowania procesów

Mapowanie procesu idealnego zamiast prawdziwego

Mapa wygląda świetnie.

Tylko nikt tak nie pracuje.

Rozwiązanie:

weryfikuj na rzeczywistych przypadkach.

Zbyt duży zakres

„Mapujemy całą firmę”.

Po tygodniu zespół tonie w szczegółach.

Rozwiązanie:

jasno ustal początek i koniec.

Za dużo detali

Mapa zawiera każde kliknięcie i każde pole.

Traci czytelność.

Rozwiązanie:

poziom szczegółowości dobieraj do celu.

Za mało danych

Mapa mówi, że proces ma pięć etapów.

Nie wiadomo, ile trwają.

Rozwiązanie:

dodaj mierniki, gdy celem jest optymalizacja.

Pomijanie wyjątków

Diagram działa tylko dla idealnego klienta.

Rozwiązanie:

zidentyfikuj najczęstsze odstępstwa.

Brak pracowników wykonujących proces

Manager mapuje przepływ sam.

Rozwiązanie:

angażuj osoby wykonujące pracę.

Natychmiastowe projektowanie technologii

Każdy problem kończy się nowym narzędziem.

Rozwiązanie:

oddziel current state od future state.

Brak właściciela zmiany

Mapa powstaje.

Nikt niczego nie wdraża.

Rozwiązanie:

każda rekomendacja powinna mieć ownera.

Brak pomiaru po zmianie

Proces został „poprawiony”.

Nie wiadomo, czy wynik się zmienił.

Rozwiązanie:

ustal KPI przed wdrożeniem.

Jak powinien wyglądać rezultat profesjonalnego mapowania?

Po zakończeniu pracy firma powinna posiadać nie tylko diagram.

Mapę current state

Pokazującą rzeczywisty obecny proces.

Granice i rezultat

Jasno określony początek, koniec i oczekiwany wynik.

Role

Informację o tym, kto wykonuje poszczególne działania.

Dane i systemy

Informację, skąd pochodzą dane i gdzie wykonywana jest praca.

Najważniejsze mierniki

Czasy, kolejki albo inne wskaźniki potrzebne do oceny procesu.

Problemy

Miejsca oczekiwania, błędów, ręcznej pracy, duplikacji i niejasnej odpowiedzialności.

Przyczyny

Nie tylko objawy.

Mapę future state

Pokazującą docelowy sposób działania.

Rekomendacje

Co:

usunąć,

uprościć,

ustandaryzować,

zintegrować,

zautomatyzować,

wspomóc AI.

Priorytety

Co warto zrobić jako pierwsze?

Plan wdrożenia

Kto?

Co?

W jakiej kolejności?

KPI po zmianie

Po czym poznamy, że nowy proces działa lepiej?

Jak podchodzimy do mapowania procesów w ExperciAI?

W ExperciAI mapa nie jest celem końcowym.

Interesuje nas to, co można dzięki niej zobaczyć.

Analizujemy między innymi:

• rzeczywistą kolejność pracy,
• role i odpowiedzialności,
• systemy,
• dane,
• handoffy,
• czas aktywnej pracy,
• oczekiwanie,
• ręczne operacje,
• powroty,
• akceptacje,
• wyjątki,
• miejsca zależne od jednej osoby.

Następnie zadajemy pytania:

Które działania są naprawdę potrzebne?

Co można usunąć?

Co warto uprościć?

Co powinno zostać ustandaryzowane?

Które systemy warto połączyć?

Co można bezpiecznie automatyzować?

Gdzie AI rzeczywiście ma sens?

Nie każdy proces potrzebuje automatyzacji.

Nie każdy potrzebuje AI.

Nie każdy potrzebuje nowego systemu.

Czasami najlepszym rezultatem jest:

usunięcie etapu,

zmiana odpowiedzialności,

lepszy formularz,

ujednolicenie danych,

zmiana zasad akceptacji.

Dopiero gdy proces jest zrozumiały, można odpowiedzialnie zdecydować, gdzie technologia przyniesie realną wartość.

Jeżeli chcesz zobaczyć, jak naprawdę działają kluczowe procesy w Twojej firmie i znaleźć miejsca do usprawnienia, zobacz audyt procesów w firmie w ExperciAI.

Jeżeli proces został już uporządkowany i problemem pozostaje ręczna praca, zobacz również automatyzację procesów w firmie.

Checklista mapowania procesu

1. Czy proces ma jasno określony początek?
2. Czy ma konkretny koniec?
3. Czy wiadomo, jaki wynik powinien dostarczyć?
4. Czy mapa pokazuje rzeczywistość, a nie procedurę?
5. Czy została zweryfikowana na realnych przypadkach?
6. Czy uczestniczyły osoby wykonujące proces?
7. Czy mapa pokazuje główne role?
8. Czy pokazuje wykorzystywane systemy?
9. Czy wiadomo, skąd pochodzą dane?
10. Czy zaznaczono ręczne przenoszenie informacji?
11. Czy pokazano decyzje?
12. Czy uwzględniono wyjątki?
13. Czy uwzględniono ścieżki błędów?
14. Czy zaznaczono powroty do wcześniejszych etapów?
15. Czy zaznaczono handoffy?
16. Czy wiadomo, kto odpowiada za każdy krok?
17. Czy proces posiada właściciela end-to-end?
18. Czy dodano czas aktywnej pracy, jeśli jest istotny?
19. Czy dodano czas oczekiwania?
20. Czy wskazano miejsca powstawania kolejek?
21. Czy wiadomo, które działania nie tworzą wartości?
22. Czy oddzielono current state od future state?
23. Czy przed automatyzacją sprawdzono możliwość usunięcia kroku?
24. Czy dla AI określono przypadki przekazywane człowiekowi?
25. Czy powstał plan wdrożenia zmian?
26. Czy każda ważna zmiana posiada ownera?
27. Czy ustalono mierniki bazowe?
28. Czy wiadomo, kiedy proces zostanie zmierzony ponownie?

Jeżeli większość odpowiedzi jest jednoznaczna, firma posiada znacznie lepszą podstawę do optymalizacji i automatyzacji.

Podsumowanie

Mapowanie procesów nie polega na rysowaniu diagramów dla samej dokumentacji.

Polega na zobaczeniu firmy w sposób, którego nie daje analiza pojedynczych stanowisk i narzędzi.

Od:

„klient wysłał zapytanie”

do:

„handlowiec wykonał właściwe działanie”.

Od:

„klient podpisał umowę”

do:

„realizacja może rozpocząć projekt”.

Od:

„pojawiły się dane”

do:

„manager otrzymał informację potrzebną do podjęcia decyzji”.

Dopiero kiedy widzimy całą drogę, możemy zauważyć:

gdzie praca czeka,

gdzie informacja ginie,

gdzie proces wraca,

gdzie odpowiedzialność jest niejasna,

gdzie jedna osoba ogranicza przepływ,

gdzie dane są przepisywane,

gdzie wykonujemy zbędne działania,

gdzie potrzebna jest standaryzacja,

gdzie warto zastosować automatyzację,

a gdzie AI rzeczywiście może pomóc.

Dobra mapa nie powinna kończyć się odpowiedzią:

„tak działa ten proces”.

Powinna umożliwić zadanie znacznie ważniejszego pytania:

„Dlaczego działa właśnie w taki sposób i jak możemy zaprojektować go lepiej?”

Najpierw rzeczywisty proces.

Później jego diagnoza.

Następnie future state.

Dopiero na końcu technologia.

W przeciwnym razie firma może bardzo sprawnie zautomatyzować proces, którego od początku nie powinna wykonywać w obecnej formie.

FAQ: mapowanie procesów w firmie

Co to jest mapowanie procesów?

Mapowanie procesów to przedstawienie kolejnych działań, decyzji, odpowiedzialności, danych i systemów tworzących określony proces biznesowy. Celem jest zrozumienie rzeczywistego przepływu pracy i stworzenie podstawy do jego poprawy.

Jak zrobić mapę procesu?

Najpierw określ problem, początek, koniec i oczekiwany rezultat procesu. Następnie rozpisz rzeczywiste działania, role, decyzje, dane, systemy, czasy, przekazania i wyjątki. Na końcu zweryfikuj mapę na kilku prawdziwych przypadkach.

Po co mapować procesy w firmie?

Mapa pomaga znaleźć opóźnienia, ręczne przepisywanie informacji, niejasną odpowiedzialność, błędy, zbędne działania, wąskie gardła i miejsca nadające się do automatyzacji.

Czym różni się AS-IS od TO-BE?

AS-IS lub current state pokazuje rzeczywisty obecny proces. TO-BE lub future state przedstawia docelowy sposób działania po wprowadzeniu zmian.

Czym różni się mapa procesu od Value Stream Mapping?

Mapa procesu może koncentrować się szczegółowo na konkretnym workflow. Value Stream Mapping zazwyczaj patrzy szerzej na przepływ wartości i informacji oraz analizuje między innymi czas, kolejki i działania tworzące wartość.

Co to jest swimlane?

Swimlane to sposób przedstawiania procesu w osobnych „torach” dla konkretnych osób, ról, działów albo systemów. Szczególnie dobrze pokazuje odpowiedzialność oraz przekazywanie pracy między uczestnikami procesu.

Co to jest SIPOC?

SIPOC to wysokopoziomowy model procesu obejmujący Suppliers, Inputs, Process, Outputs i Customers. Pomaga ustalić zakres procesu przed przygotowaniem bardziej szczegółowej mapy.

Czy do mapowania procesów trzeba używać BPMN?

Nie. Proste procesy można skutecznie przedstawiać za pomocą zwykłych flowchartów lub swimlane. BPMN jest szczególnie przydatny przy bardziej złożonych procesach i tam, gdzie potrzebna jest ustandaryzowana, precyzyjna notacja.

Co to jest BPMN?

BPMN, czyli Business Process Model and Notation, to ustandaryzowana przez Object Management Group notacja służąca do modelowania procesów biznesowych.

Czy mapowanie powinno być wykonane przed automatyzacją?

Przy bardziej złożonych automatyzacjach zdecydowanie warto najpierw zrozumieć current state. Pozwala to uniknąć automatyzowania zbędnych kroków i dokładnie określić dane, reguły, wyjątki oraz miejsca wymagające człowieka.

Czy mapowanie procesów pomaga przy wdrażaniu AI?

Tak. Pokazuje miejsce AI w większym workflow, rodzaj danych wejściowych, oczekiwany rezultat oraz przypadki wymagające przekazania sprawy człowiekowi.

Jaki proces warto zmapować jako pierwszy?

Najlepiej taki, który często występuje, ma duże znaczenie dla klienta lub biznesu, angażuje kilka osób lub systemów i generuje opóźnienia, błędy albo dużo ręcznej pracy.

Czy mapa procesu powinna zawierać wszystkie wyjątki?

Nie zawsze wszystkie możliwe, ale powinna uwzględniać istotne i występujące w praktyce odstępstwa. Szczególnie te, które wpływają na czas, koszt, ryzyko lub możliwość automatyzacji.

Jak szczegółowa powinna być mapa procesu?

Na tyle, aby odpowiedzieć na pytanie biznesowe będące powodem mapowania. Zbyt ogólna nie pokaże problemu. Zbyt szczegółowa stanie się nieczytelna i kosztowna w utrzymaniu.

Jak często aktualizować mapę procesu?

Warto ją ponownie zweryfikować po istotnej zmianie systemów, odpowiedzialności, modelu działania lub skali firmy, a także wtedy, gdy mierniki procesu zaczynają się pogarszać.

Czy mapowanie procesów jest tym samym co audyt procesów?

Nie. Mapowanie koncentruje się przede wszystkim na zobrazowaniu sposobu działania procesu. Audyt wykorzystuje między innymi taką mapę do szerszej diagnozy problemów, przyczyn, ryzyk, priorytetów oraz możliwych usprawnień.

Źródła i materiały

1. Lean Enterprise Institute — Value Stream Mapping

Materiały dotyczące mapowania strumienia wartości, current state, future state, przepływu informacji, cycle time i lead time.

Zobacz materiały Lean Enterprise Institute o Value Stream Mapping

2. Lean Enterprise Institute — Understanding the Fundamentals of Value-Stream Mapping

Praktyczne omówienie tworzenia mapy stanu obecnego i przyszłego oraz wykorzystania mapowania do identyfikowania problemów i działań, które nie tworzą wartości.

Zobacz materiał Lean Enterprise Institute

3. Lean Enterprise Institute — Value-Stream Improvement

Materiały pokazujące przejście od zdefiniowania problemu przez mapowanie obecnego i przyszłego stanu do wdrażania usprawnień.

Zobacz materiały Lean Enterprise Institute dotyczące Value-Stream Improvement

4. Object Management Group — Business Process Model and Notation 2.0.2

Oficjalna strona aktualnej formalnej specyfikacji BPMN. Standard opisuje ustandaryzowaną notację służącą do precyzyjnego modelowania procesów biznesowych i workflow.

Zobacz oficjalną specyfikację BPMN

5. American Society for Quality — Flowchart

Materiały ASQ dotyczące diagramów przepływu i ich wykorzystania do przedstawiania kolejności działań oraz punktów decyzyjnych.

Zobacz materiały ASQ

6. International Organization for Standardization — The Process Approach in ISO 9001

Oficjalny materiał ISO dotyczący podejścia procesowego, zależności pomiędzy procesami oraz wykorzystania cyklu Plan-Do-Check-Act do ich zarządzania i doskonalenia.

Zobacz oficjalny materiał ISO dotyczący podejścia procesowego