System, proces i procedura to nie to samo

System, proces i procedura funkcjonują na różnych poziomach firmy, dlatego rozwiązują odmienne problemy. Procedura porządkuje sposób realizacji działania. Proces organizuje przepływ pracy między poszczególnymi etapami. System łączy role, dane, zasady i narzędzia.

Gdy firma poprawia instrukcję, mimo że źródło błędu leży w przepływie pracy lub podziale odpowiedzialności, ponosi koszt zmiany, która nie usuwa przyczyny.

System, proces i procedura odpowiadają na inne pytania

System odpowiada na pytanie: „Co sprawia, że całość w ogóle działa?”. Obejmuje role, zasady, dane, narzędzia, odpowiedzialności i powiązania między procesami.

Proces odpowiada na pytanie: „Jak praca przechodzi od wejścia do wyniku?”. Pokazuje kolejne działania, punkty przekazania, dane wejściowe, wynik i osoby odpowiedzialne za poszczególne etapy.

Procedura odpowiada na pytanie: „Jak wykonać dane działanie?”. Opisuje konkretną czynność tak, aby wynik nie zależał od pamięci, humoru ani własnej twórczości osoby, która akurat siedzi przy komputerze.

To praktyczny model diagnostyczny. W jednej firmie procedura opisuje pojedynczy krok, w innej większy fragment procesu. Sens rozróżnienia pozostaje ten sam: ustalasz, czy problem dotyczy wykonania działania, przepływu pracy czy układu, w którym ta praca się odbywa.

W podejściu procesowym zgodnym z ISO 9001 proces to zbiór wzajemnie powiązanych lub oddziałujących działań, które wykorzystują wejścia do osiągnięcia zamierzonego rezultatu.

Błędna diagnoza produkuje kosztowną pracę

Firma widzi objaw i chce go szybko usunąć. Opóźniony projekt? Powstaje instrukcja. Chaos w plikach? Kupowany jest nowy dysk. Klient nie dostaje odpowiedzi? Ktoś zakłada kolejny kanał na czacie.

Każda z tych reakcji może mieć sens. Problem pojawia się wtedy, gdy decyzja zapada przed ustaleniem przyczyny. Instrukcja nie naprawi braku właściciela danych. Nowe narzędzie nie naprawi źle ustawionego przekazania pracy. Kolejny kanał komunikacji nie naprawi braku decyzji.

Efekt jest prosty: firma ma więcej dokumentów, dostępów i miejsc, do których można zajrzeć. Nadal nie wiadomo jednak, kto robi co, na jakiej podstawie i co uruchamia kolejny etap.

Jedno opóźnienie, trzy różne źródła

Załóżmy, że wdrożenie nowego klienta trwa dwa tygodnie dłużej, niż zakładano. Właściciel firmy mówi: „Proces onboardingu nie działa”. To może być prawda albo wygodna etykieta, która niczego nie wyjaśnia.

Pierwszy wariant jest proceduralny. Handlowiec ma przekazać dane klienta do realizacji, lecz nikt nie opisał, jakie dane są potrzebne i gdzie mają się znaleźć. Raz trafiają do CRM-u, raz do e-maila, raz na czat.

Drugi wariant jest procesowy. Dane są kompletne, ale zespół rozpoczyna pracę przed zatwierdzeniem zakresu. Potem czeka na decyzję klienta, wraca do poprzedniego etapu i wykonuje część pracy drugi raz.

Trzeci wariant jest systemowy. Dane są rozrzucone między kilka miejsc, nie ma właściciela wdrożenia, a CRM nie przekazuje informacji do realizacji w sposób zgodny z pracą zespołu.

Ten sam objaw, opóźniony onboarding, może więc wymagać trzech różnych decyzji.

Jak wygląda diagnoza od środka

Wyobraź sobie firmę, która realizuje projekty dla klientów. Handlowiec zamyka sprzedaż, zespół realizacyjny rozpoczyna pracę, a właściciel po raz kolejny słyszy, że „brakuje briefu”.

Na pierwszy rzut oka problem wydaje się prosty. Handlowiec nie przekazał informacji. Powstaje więc dokument „brief dla realizacji”. Po miesiącu nadal brakuje danych.

Dopiero rozmowa z zespołem pokazuje, co dzieje się naprawdę. Handlowiec ma część informacji w CRM-ie, klient dopowiada szczegóły w e-mailach, a osoba prowadząca projekt zapisuje ustalenia na czacie. Brief istnieje, ale nikt nie odpowiada za jego kompletność. Co gorsza, realizacja może zacząć pracę, zanim klient zatwierdzi zakres.

Problem obejmuje trzy usterki:

• Procedura nie określa, kto sprawdza kompletność briefu.
• Proces pozwala uruchomić realizację przed zatwierdzeniem zakresu.
• System nie wskazuje jednego źródła aktualnych danych klienta.

Naprawa zaczyna się od ustalenia właściciela briefu i jednego miejsca, w którym znajdują się dane potrzebne do rozpoczęcia projektu.

W tym scenariuszu dokument jest skutkiem dobrze wykonanej diagnozy, nie rozwiązaniem.

Czasem wystarczy jedna dobra instrukcja

Nie każdy błąd oznacza problem z całym procesem albo systemem. Bywa, że praca płynie poprawnie, odpowiedzialność jest jasna, a tylko jeden powtarzalny krok wykonuje się za każdym razem inaczej.

Przykład: firma wysyła klientom raport po zakończeniu usługi. Dane są w jednym miejscu, osoba odpowiedzialna jest znana, termin jest realny, a raport trafia do odbiorcy bez opóźnień. Problem pojawia się wyłącznie przy nazwie pliku i oznaczeniu wersji dokumentu. Raz raport jest opisany poprawnie, raz nie, przez co klient dostaje niewłaściwy załącznik.

Tu procedura ma sens. Krótka instrukcja nazewnictwa i kontroli pliku usuwa źródło błędu. Przebudowa procesu albo zmiana narzędzia byłaby kosztowną reakcją na problem, który mieści się w jednym działaniu.

Łatwo zapomnieć o tej granicy. Nie każda drobna usterka oznacza, że firma wymaga reorganizacji. Czasem jedna dobrze opisana czynność wystarcza, aby zatrzymać problem.

Gdy błąd przechodzi przez kilka warstw

Zły układ odpowiedzialności może tworzyć błędy w procesie, a te wymuszają tworzenie kolejnych procedur ratunkowych.

Punktem startu jest najwyższa warstwa, która faktycznie wytwarza obserwowany problem. Jeśli brak właściciela danych powoduje opóźnienia w wielu etapach pracy, samo poprawienie instrukcji przekazania danych nie zamknie sprawy. Jeśli jednak odpowiedzialność i przepływ są zdrowe, a błąd dotyczy jednego kroku, systemowa reforma byłaby pokazem siły bez pożytku.

Dobra diagnoza zaczyna się od pytania:

Co dokładnie generuje ten błąd?

Faktura nie jest opóźniona bez powodu

Ten sam sposób myślenia działa poza onboardingiem. Weźmy fakturowanie.

Jeśli księgowość dostaje dane od realizacji za późno, problem może leżeć w procesie: przekazanie informacji następuje w pewnym czasie po wykonaniu usługi, zamiast w chwili jej realizacji. Zmiana kolejności działań ma wtedy większy sens.

Jeśli dane do faktury są rozrzucone między ofertę, e-mail, CRM i prywatny arkusz jednej osoby, problem jest systemowy. Firma nie ma jednego aktualnego źródła informacji ani właściciela ich kompletności.

Jeśli natomiast wszystkie dane są dostępne, ale jedna osoba nie wie, gdzie wpisać numer zamówienia przy korekcie, problem jest proceduralny. Wystarczy jasno opisać ten krok.

Faktura jest skutkiem. Diagnoza zaczyna się wcześniej: od sprawdzenia, skąd pochodzą dane, kto je zatwierdza i kiedy przechodzą do kolejnej osoby.

CRM nie jest systemem

Wdrożenie narzędzia bez ustalenia procesu może nie zmienić źródła problemu. Firma płaci abonament, zespół dostaje nowe loginy, a klient nadal czeka na odpowiedź, bo nikt nie ustalił, kto wykonuje następny ruch.

Narzędzie działa dobrze wtedy, gdy realizuje decyzję, która już została podjęta. Automatyzacja potrafi przenieść dane, utworzyć zadanie, przypomnieć o terminie albo sprawdzić kompletność formularza. Nie odpowie jednak za firmę na pytanie, kto jest właścicielem sprawy i kiedy praca ma ruszyć.

AI nie naprawia braku odpowiedzialności

AI może pomóc w streszczaniu rozmów z klientem, przygotowaniu pierwszej wersji briefu, sprawdzeniu kompletności danych czy tworzeniu roboczych instrukcji. To użyteczne zastosowania, o ile w procesie wiadomo już, co ma przyjąć na wejściu i co ma wydać na końcu.

Jeśli handlowiec nie wie, które informacje są potrzebne realizacji, AI wygeneruje ładniejszy chaos. Jeśli zespół nie ma jednego źródła danych, model otrzyma sprzeczne informacje i zwróci sprzeczną odpowiedź.

Jak zobaczyć proces, który działa naprawdę

Firma zwykle ma dwa procesy. Pierwszy istnieje na schemacie, w prezentacji albo w głowie właściciela. Drugi wykonują ludzie, gdy klient dzwoni, brakuje danych, ktoś jest na urlopie albo termin zaczyna się palić.

Analiza zaczyna się od tego drugiego. Zamiast pytać: „Jak powinien wyglądać proces?”, pytasz ludzi: „Co robisz, gdy dostajesz tę sprawę?”. Odpowiedzi pokazują realne przekazania, nieformalne obejścia, prywatne arkusze i miejsca, w których praca czeka.

Do opisania jednego procesu wystarczy ustalić:

• Co uruchamia pracę.
• Jaki wynik ma powstać.
• Kto wykonuje każde działanie.
• Jakie dane są potrzebne.
• Gdzie dane mają być aktualne.
• Kiedy sprawa przechodzi do kolejnej osoby.
• Co dzieje się przy wyjątku.
• Po czym firma poznaje, że wynik jest poprawny.

Czasem wystarcza jedna rozmowa, w której trzy osoby opisują ten sam etap na trzy różne sposoby. To sygnał, że system nie został jeszcze ustalony.

Sześć pytań przed zmianą

Diagnoza nie wymaga od razu wielkiego projektu. Wystarczy rozłożyć problem na sześć elementów:

• Objaw: co dokładnie nie działa, opóźnienie, błąd, poprawki, brak danych?
• Właściciel: kto odpowiada za dane działanie lub wynik?
• Wejście i wynik: co uruchamia pracę i jaki efekt ma powstać?
• Przekazanie: w którym miejscu praca przechodzi do innej osoby albo zespołu?
• Dane: skąd pochodzą informacje i które miejsce jest ich aktualnym źródłem?
• Wyjątki: co dzieje się, gdy sprawa odbiega od zwykłego scenariusza?

Od objawu do pierwszego kroku

Sześć pytań porządkuje obserwację. Poniższa macierz, pokazująca, od której warstwy zacząć sprawdzanie, pomaga zamienić obserwację w decyzję.

Macierz nie zastępuje rozmowy z ludźmi wykonującymi pracę. Ogranicza jednak odruch wybierania pierwszej widocznej naprawy tylko dlatego, że da się ją wdrożyć przed końcem tygodnia.

Trzy poprawki, które zwykle niczego nie naprawiają

• Nazwanie każdego problemu „procesem”. Wtedy konflikt odpowiedzialności, nieopisany krok, brak danych i źle ustawione narzędzie trafiają do jednego worka. Diagnoza staje się szeroka, ale bezużyteczna.
• Dopisywanie procedur do źle ułożonego przepływu pracy. Dokumentów przybywa, ludzie dostają kolejne pliki, a źródło problemu zostaje na miejscu.
• Kupowanie narzędzia przed ustaleniem, co ma ono obsłużyć. Narzędzie może przyspieszyć dobrze opisany proces. Nie zastąpi jednak decyzji o odpowiedzialności, kolejności działań i sposobie obsługi wyjątków.

FAQ

Czym różni się proces od procedury?

Proces pokazuje przepływ pracy od wejścia do wyniku. Procedura opisuje sposób wykonania działania lub fragmentu tego przepływu.

Czy proces może istnieć bez spisanej procedury?

Tak. Praca może przechodzić przez kolejne etapy, choć nikt nie opisał ich w dokumencie. Taki proces zależy od pamięci ludzi i łatwo pęka przy zmianie pracownika, wzroście liczby klientów albo nietypowej sprawie.

Czy procedura może opisywać cały proces?

Może, jeśli firma używa tego słowa szerzej. Problem pojawia się wtedy, gdy jeden dokument miesza przebieg pracy, zasady odpowiedzialności i szczegółowe czynności.

Po czym poznać problem systemowy?

Po tym, że błąd wraca w różnych miejscach, dotyczy kilku osób albo wynika z rozjazdu między rolami, danymi, zasadami i narzędziami.

Czy nowe narzędzie może naprawić zły proces?

Czasem tak, jeśli źródłem problemu jest brak funkcji lub automatycznego przekazania danych. Sam zakup narzędzia nie zastąpi jednak decyzji o odpowiedzialności, kolejności działań i sposobie obsługi wyjątków.

Kiedy automatyzacja ma sens?

Wtedy, gdy firma zna już wynik działania, dane potrzebne na wejściu, właściciela kroku i regułę obsługi wyjątków.