Artykuł nr 36, Kategoria: Compliance i raportowanie

Audyt procedur i polityk firmowych – czy pracownik naprawdę wie, co ma zrobić?

Firma ma politykę.

Dokument został:

przygotowany;
zatwierdzony;
opublikowany w intranecie;
rozesłany pracownikom.

W arkuszu compliance można więc zaznaczyć:

POLICY EXISTS – PASS.

Ale czy pracownik, który jutro stanie przed nietypową sytuacją, będzie wiedział:

że taka procedura istnieje;
gdzie ją znaleźć;
która wersja jest aktualna;
kiedy ją zastosować;
co dokładnie zrobić;
czego nie wolno zrobić;
kogo zapytać;
kiedy eskalować problem?

To zupełnie inny test.

Dlatego istnienie procedury nie powinno być mylone z:

działaniem procedury w praktyce.

Dokument może być formalnie kompletny i jednocześnie operacyjnie słaby.

Może zawierać:

18 stron poprawnego tekstu,

a nie odpowiadać jasno na najważniejsze pytanie pracownika:

„Co mam zrobić teraz?”

Właśnie dlatego audyt polityk i procedur powinien obejmować nie tylko dokumentację, lecz także jej wykonalność operacyjną.

Polityka istniejąca na papierze nie jest jeszcze działającą kontrolą

To rozróżnienie jest fundamentalne.

Dokument istnieje

oznacza:

mamy zapis.

Dokument jest dostępny

oznacza:

pracownik potrafi go znaleźć.

Dokument jest zrozumiały

oznacza:

wie, czego od niego wymaga.

Dokument jest wykonywalny

oznacza:

może wykonać opisane działania w realnych warunkach.

Dokument działa

oznacza:

zachowanie organizacji rzeczywiście odpowiada założonemu procesowi.

Między pierwszym a ostatnim poziomem może istnieć ogromna różnica.

ISO 9001:2026 przesuwa uwagę z dokumentu na funkcjonujący system

16 września 2026 r. opublikowano ISO 9001:2026, szóste i aktualne wydanie międzynarodowego standardu systemów zarządzania jakością. Nowa edycja zastąpiła ISO 9001:2015 i nadal obejmuje m.in. kwestie kompetencji, świadomości, komunikacji, udokumentowanej informacji, sterowania operacyjnego, oceny wyników i doskonalenia. ISO podkreśla również jakość przywództwa, kulturę jakości oraz wyraźniejsze podejście do ryzyk i szans.

To istotne, ponieważ dobrze zaprojektowany system zarządzania nie kończy się na:

„procedura została zatwierdzona”.

Musi jeszcze umożliwiać:

właściwe wykonanie procesu;
monitorowanie jego skuteczności;
wykrywanie odchyleń;
uczenie się i poprawę.

Podobne pytanie zadaje współczesny compliance: czy program naprawdę działa?

Aktualne Evaluation of Corporate Compliance Programs amerykańskiego Departamentu Sprawiedliwości, w wersji z września 2024 r., pyta m.in.:

czy polityki są dostępne;
czy pracownicy wiedzą, jak je znaleźć;
czy są przedstawione w sposób odpowiadający odbiorcom;
czy zostały rzeczywiście zintegrowane z działalnością;
czy pracownicy i kluczowi gatekeeperzy rozumieją swoje obowiązki i zasady eskalacji.

DOJ rozróżnia też program istniejący wyłącznie formalnie od programu, który rzeczywiście działa w praktyce.

To nie jest oczywiście polski standard prawny ani obowiązkowa norma dla każdej firmy.

Jest jednak bardzo użytecznym punktem odniesienia:

nie pytaj tylko, czy firma ma politykę. Sprawdź, czy polityka została wdrożona tak, aby wpływać na rzeczywiste zachowanie.

Work-as-Imagined i Work-as-Done

Human factors używa bardzo przydatnego rozróżnienia:

Work-as-Imagined

czyli:

jak proces ma działać według dokumentacji,

oraz:

Work-as-Done

czyli:

jak praca naprawdę jest wykonywana.

Badanie jakościowe opublikowane w 2024 r. dotyczące procedur w środowisku petrochemicznym wykazało różnice pomiędzy postrzeganiem procedur przez osoby administrujące nimi i użytkowników wykonujących pracę. Bezpośredni użytkownicy opisywali więcej odchyleń od procedur, a powody obejmowały czynniki środowiskowe, organizacyjne, zadaniowe i indywidualne. Autorzy podkreślali, że wysokiej jakości SOP powinny być skuteczne, szczegółowe, efektywne, uporządkowane i dopasowane do rzeczywistej pracy.

To bardzo ważne.

Jeżeli pracownik nie wykonuje procedury, odpowiedź:

„trzeba go bardziej zdyscyplinować”

może być przedwczesna.

Najpierw warto sprawdzić:

czy procedura rzeczywiście daje się wykonać.

Procedura może być zgodna formalnie i wadliwa ergonomicznie

Przykład:

„Przed zatwierdzeniem dostawcy należy zweryfikować go zgodnie z procedurą due diligence.”

Brzmi poprawnie.

Ale pracownik pyta:

jaki formularz?
gdzie?
kto zatwierdza?
jak długo trwa kontrola?
co jeśli dostawca nie poda wszystkich danych?
jaki wynik blokuje współpracę?
kiedy potrzebna jest eskalacja?

Jeżeli procedura nie odpowiada:

pracownik musi stworzyć własny proces.

A wtedy organizacja nie ma już:

jednej kontroli.

Ma:

tyle kontroli, ilu pracowników.

Procedure Execution Test Expert Design

Do audytu procedur można zastosować autorski model:

PURPOSE → TRIGGER → ACTOR → ACTION → DECISION → EVIDENCE → ESCALATION → FEEDBACK

To Procedure Execution Test Expert Design.

Nie jest oficjalną metodą ISO ani DOJ.

Jego celem jest odpowiedź na jedno bardzo praktyczne pytanie:

Czy osoba, która nie tworzyła procedury, może dzięki niej prawidłowo wykonać proces?

1. PURPOSE – po co istnieje procedura?

Procedura powinna odpowiadać na realne ryzyko albo potrzebę.

Przykłady:

ochrona danych;
zatwierdzanie wydatków;
obsługa reklamacji;
weryfikacja dostawców;
reagowanie na incydent;
kontrola wersji;
przyjmowanie płatności;
bezpieczeństwo.

Problem pojawia się, gdy dokument istnieje:

„bo audyt tego wymagał”

albo:

„bo zawsze go mieliśmy”.

Purpose Test

Pytamy:

Jakie ryzyko lub cel kontroluje ta procedura?

Jeżeli odpowiedzi nie da się podać w jednym lub dwóch zdaniach:

procedura może nie mieć jasno zdefiniowanej funkcji.

Przykład

Polityka:

„Zasady korzystania z zewnętrznych nośników danych”.

Cel:

ograniczenie ryzyka nieautoryzowanego wyniesienia danych oraz wprowadzenia złośliwego oprogramowania.

Teraz możemy ocenić:

czy poszczególne wymagania rzeczywiście realizują ten cel.

2. TRIGGER – kiedy pracownik ma uruchomić procedurę?

To jedna z najczęstszych luk.

Dokument opisuje:

co zrobić.

Nie opisuje:

kiedy zacząć.

Trigger powinien być rozpoznawalny przez użytkownika

Słabo:

„w odpowiednich przypadkach należy przeprowadzić dodatkową weryfikację”.

Co to znaczy:

odpowiedni przypadek?

Lepiej:

dodatkową weryfikację uruchamia się, gdy wartość umowy przekracza X, dostawca znajduje się w określonej jurysdykcji albo występuje jeden z wymienionych sygnałów ryzyka.

Teraz istnieje:

operacyjny trigger.

Trigger Gap

Procedura bez triggera może być świetnie napisana.

Ale pracownik może jej nigdy nie otworzyć.

Nie dlatego, że ją ignoruje.

Dlatego, że:

nie wie, kiedy obowiązuje.

3. ACTOR – kto dokładnie ma wykonać czynność?

Sformułowania wysokiego ryzyka:

„należy sprawdzić…”

„powinno zostać zatwierdzone…”

„firma zapewnia…”

Kto?

Passive Voice Risk

Zdanie:

„Dokument należy zweryfikować przed wysłaniem.”

Nie wskazuje:

kto weryfikuje;
kto odpowiada;
kto zatwierdza wyjątek.

Lepiej:

Project Owner przekazuje dokument do niezależnej weryfikacji, a Final Approver zatwierdza wersję publikacyjną.

Teraz można przypisać:

odpowiedzialność.

RACI może pomóc, ale nie zawsze wystarczy

Przy procesach wieloosobowych można zastosować:

Responsible;
Accountable;
Consulted;
Informed.

Ale przy procedurze operacyjnej najważniejsze pytanie brzmi:

Czy pracownik wie, którą rolę pełni w tym konkretnym momencie?

4. ACTION – co dokładnie ma zrobić?

To centralna część procedury.

Nie:

„należy zachować należytą staranność”.

Tylko:

jakie działania tworzą należytą staranność w tym procesie?

Action powinien być wykonywalny

Dobry krok proceduralny określa:

czynność;
obiekt;
narzędzie;
oczekiwany wynik.

Przykład:

„Sprawdź NIP kontrahenta w bazie X i zapisz wynik kontroli w polu Y formularza dostawcy.”

To da się:

wykonać.

Zdanie:

„Zweryfikuj wiarygodność kontrahenta.”

wymaga dopiero stworzenia własnej metody.

Procedura nie powinna pozostawiać pracownikowi wszystkich decyzji

Jeżeli dokument mówi:

„w razie istotnego ryzyka należy odpowiednio zareagować”,

to pracownik musi sam określić:

co jest istotne;
jaka reakcja jest odpowiednia.

Być może właśnie te dwie rzeczy powinny zostać:

wcześniej zaprojektowane.

5. DECISION – gdzie pracownik musi podjąć decyzję?

Każda procedura ma punkty:

IF → THEN

Na przykład:

jeżeli dokument kompletny → kontynuuj.

jeżeli brak dokumentu → HOLD.

jeżeli ryzyko HIGH → eskaluj.

To właśnie Decision Points.

Decision Point powinien mieć kryterium

Słabo:

„jeżeli ryzyko jest wysokie…”

Lepiej:

„ryzyko HIGH występuje, gdy zachodzi co najmniej jeden z warunków A–D”.

Pracownik nie musi wtedy:

interpretować polityki od zera.

Decision Tree może być lepszy niż pięć stron tekstu

Nie każdy fragment procedury powinien być narracyjny.

Przy wielu wariantach czasem lepszy jest:

decision tree.

Na przykład:

dokument kompletny?

TAK → kontrola.

NIE → zwrot.

wynik pozytywny?

TAK → approval.

NIE → escalation.

Czytelność procedury to:

część kontroli.

6. EVIDENCE – skąd wiadomo, że procedura została wykonana?

Jeżeli proces jest istotny, samo stwierdzenie:

„pracownik zrobił”

może być niewystarczające.

Potrzebny może być:

formularz;
log;
zatwierdzenie;
timestamp;
zapis w systemie;
checklista;
decyzja.

Execution Evidence

Czynność	Dowód
weryfikacja kontrahenta	zapis wyniku
akceptacja kosztu	approval w systemie
wykonanie szkolenia	wynik / potwierdzenie
kontrola dokumentu	finding register
eskalacja	ticket / decyzja

To pozwala później sprawdzić:

nie tylko czy procedura istnieje,

ale:

czy była rzeczywiście stosowana.

Brak dowodu nie oznacza automatycznie braku wykonania

To ważne.

Możliwe, że:

proces wykonano,

ale:

system nie przechowuje śladu.

Wtedy finding może dotyczyć:

auditability procesu

a nie samego wykonania.

7. ESCALATION – co zrobić, gdy standardowa ścieżka nie działa?

Procedury najłatwiej pisać dla:

normalnego przypadku.

Ale ich jakość często ujawnia się dopiero przy wyjątku.

Na przykład:

brakuje dokumentu;
klient żąda wyjątku;
system nie działa;
deadline jest za godzinę;
przełożony poleca ominąć krok;
dwa wymagania są sprzeczne.

Co wtedy?

Escalation Gap

Jeżeli procedura nie opisuje:

jak wyjść z sytuacji niestandardowej,

pracownik może:

improwizować;
ominąć proces;
czekać;
eskalować do przypadkowej osoby.

Każda z tych reakcji może prowadzić do innego wyniku.

Dobra procedura nie musi przewidywać wszystkich wyjątków

To byłoby niemożliwe.

Powinna jednak wskazywać:

kto rozstrzyga przypadki, których nie przewidziano.

Przykład:

jeżeli sytuacja nie mieści się w decision tree, pracownik zatrzymuje proces i eskaluje do Compliance Owner.

To może wystarczyć.

8. FEEDBACK – czy procedura uczy się z rzeczywistego użycia?

Procedura nie powinna być dokumentem:

zamrożonym na pięć lat.

Praca się zmienia.

Zmieniają się:

systemy;
role;
przepisy;
ryzyka;
narzędzia.

Badanie jakościowe z 2024 r. dotyczące procesu zmian SOP w przedsiębiorstwie petrochemicznym wykazało różnicę pomiędzy tym, jak administratorzy i użytkownicy postrzegali możliwość aktualizowania procedur. Administratorzy oceniali proces jako bardziej przejrzysty i dostępny niż sami użytkownicy. Autorzy wskazywali na znaczenie przejrzystości procesu zmian, udziału pracowników i skutecznej komunikacji.

To bardzo cenna wskazówka:

procedura powinna mieć mechanizm feedbacku od ludzi, którzy rzeczywiście jej używają.

Procedure Execution Test – pełna mapa

Warstwa	Pytanie
Purpose	Po co procedura istnieje?
Trigger	Kiedy należy ją uruchomić?
Actor	Kto odpowiada za działanie?
Action	Co dokładnie trzeba zrobić?
Decision	Według jakiego kryterium wybrać ścieżkę?
Evidence	Jak potwierdzić wykonanie?
Escalation	Co zrobić z wyjątkiem?
Feedback	Jak procedura jest aktualizowana?

Jeżeli któryś element jest pusty:

może istnieć Procedure Execution Gap.

Najważniejszy test: daj procedurę osobie, która jej nie pisała

To prosty, ale bardzo mocny eksperyment.

Osoba otrzymuje:

scenariusz;
procedurę;
dostępne narzędzia.

Nie otrzymuje:

autora procedury stojącego obok.

Pytanie:

czy wykona zadanie prawidłowo?

To jest Procedure Execution Test.

Nie pytaj „czy rozumiesz?”

To bardzo słaby test.

Pracownik może odpowiedzieć:

tak.

Lepsze:

„Pokaż, co zrobisz w tej sytuacji.”

To zmienia:

deklarację wiedzy

obserwowalne wykonanie.

Scenario-Based Procedure Test

Przykład:

Dostawca nie przekazał jednego z dokumentów compliance, ale projekt musi rozpocząć się jutro. Kierownik prosi o „warunkowe puszczenie” dostawcy. Co robisz?

Teraz można obserwować:

czy pracownik znajduje politykę;
czy rozpoznaje trigger;
czy wie, kto zatwierdza wyjątek;
czy tworzy ślad dowodowy.

To znacznie lepsze niż:

„Czy znasz procedurę dostawców?”

Test procedury powinien obejmować przypadek normalny i nietypowy

Happy Path

Wszystko jest kompletne.

Negative Path

Czegoś brakuje.

Exception Path

Występuje sytuacja niestandardowa.

Escalation Path

Potrzebna jest decyzja wyższego poziomu.

Jeżeli procedura działa wyłącznie dla:

happy path,

może być niewystarczająca.

Policy-to-Practice Matrix

Przy audycie większej liczby polityk można zastosować:

Policy requirement	Operational step	Owner	Evidence	Test
dostawca musi być zweryfikowany	due diligence	Procurement	system	PASS
konflikt interesów zgłaszany	formularz	Employee	register	PASS
wyjątek wymaga approval	brak jasnej ścieżki	–	–	GAP
szkolenie coroczne	LMS	HR	record	PASS

Ta tabela pokazuje:

gdzie polityka przechodzi w rzeczywistą kontrolę.

Policy Requirement bez Operational Step może być martwym zapisem

Przykład:

„Pracownicy powinni unikać konfliktów interesów.”

To jest zasada.

Ale jak?

Potrzebne mogą być:

definicja;
trigger;
disclosure;
formularz;
owner;
decyzja.

Bez tego pracownik może:

rozumieć wartość,

ale nie znać:

procesu.

Polityka i procedura nie powinny pełnić tej samej funkcji

Warto rozróżnić.

Polityka

mówi:

co organizacja wymaga i dlaczego.

Procedura

mówi:

jak wymaganie realizujemy.

Instrukcja

może schodzić jeszcze niżej:

jak wykonać konkretną czynność.

Jeżeli jeden 40-stronicowy dokument próbuje być:

polityką + procedurą + instrukcją + poradnikiem,

może być trudny w użyciu.

Hierarchia dokumentów powinna być jasna

Przykład:

Policy → Procedure → Work Instruction → Form / Record

Jeżeli dokumenty są sprzeczne:

pracownik musi zgadywać, który ma pierwszeństwo.

Dlatego audyt powinien sprawdzać:

hierarchy.

Przykład: polityka wydatków

Polityka:

zakupy powyżej 50 tys. wymagają dwóch akceptacji.

Procedura:

jedna akceptacja powyżej 50 tys.

System:

pozwala zatwierdzić jedną osobą.

Co obowiązuje?

Mamy trzy warstwy:

POLICY ≠ PROCEDURE ≠ SYSTEM.

To poważniejszy problem niż:

literówka w dokumencie.

System powinien wzmacniać procedurę, a nie umożliwiać jej łatwe omijanie

DOJ w ECCP pyta m.in., w jaki sposób polityki i procedury są wzmacniane przez system kontroli wewnętrznej oraz czy organizacja rzeczywiście zintegrowała je z codziennym funkcjonowaniem.

Praktycznie:

jeżeli procedura mówi:

wymagane dwa approvale,

system powinien – jeśli to możliwe – wymuszać:

dwa approvale.

Jeżeli pozostawia przycisk:

„skip”,

trzeba przynajmniej kontrolować:

kto i kiedy może go użyć.

Procedura wpisana w system jest silniejsza niż procedura oparta wyłącznie na pamięci

Można rozróżnić:

Memory Control

pracownik ma pamiętać.

Prompted Control

system przypomina.

Enforced Control

system blokuje przejście bez spełnienia warunku.

Nie każda kontrola powinna być:

enforced.

Ale audyt powinien świadomie ustalić:

dlaczego wybrano dany poziom.

Dostępność procedury jest częścią jej jakości

Procedura może być świetna.

Ale jeśli pracownik potrzebuje:

12 minut,

aby ją znaleźć:

jej użyteczność operacyjna maleje.

DOJ ECCP wprost pyta m.in., czy polityki są publikowane w formacie umożliwiającym łatwe wyszukiwanie, czy pracownicy wiedzą, gdzie je znaleźć i czy organizacja analizuje ich wykorzystanie.

To bardzo konkretne kryterium audytowe.

Procedure Findability Test

Poproś pracownika:

„Znajdź obowiązującą procedurę zgłaszania konfliktu interesów.”

Mierz:

czy znalazł;
ile to trwało;
czy znalazł aktualną wersję;
czy wybrał właściwy dokument.

To daje:

rzeczywisty dowód dostępności.

„Wysłaliśmy e-mail” nie oznacza, że polityka jest dostępna

E-mail sprzed trzech lat:

nie jest systemem zarządzania procedurą.

Dostęp powinien być:

przewidywalny;
aktualny;
kontrolowany;
łatwy do wyszukania.

Version Control – czy pracownik może znaleźć starą procedurę?

To bardzo ważny test.

Jeżeli intranet zawiera:

polityka_v2.pdf

oraz:

polityka_final.pdf

polityka_2026.pdf,

pracownik może wybrać:

niewłaściwą.

Dlatego warto jasno oznaczać:

version;
effective date;
owner;
status;
superseded version.

Stara procedura dostępna jak aktualna jest aktywnym ryzykiem

Nie jest tylko:

problemem archiwizacyjnym.

Pracownik może ją rzeczywiście zastosować.

Dlatego przy zmianie dokumentu:

poprzednia wersja powinna otrzymać jednoznaczny status.

Procedure Change Audit

Przy zmianie polityki sprawdzamy:

co zależy od zmienionej reguły?

Na przykład zmienia się:

próg akceptacji 50 tys. → 75 tys.

Co trzeba zaktualizować?

policy;
procedure;
ERP workflow;
training;
formularze;
approval matrix.

Jeżeli tylko dokument główny zmieni wartość:

powstaje Procedure Propagation Gap.

Work-as-Done Audit – zobacz, jak proces działa naprawdę

Najbardziej wartościowym źródłem może nie być:

dokument.

Może nim być:

obserwacja procesu.

Pytania:

jak pracownik zaczyna zadanie?
gdzie szuka danych?
z kim się kontaktuje?
czego procedura nie przewiduje?
jakie ma obejścia?
które kroki uważa za zbędne?

To nie znaczy:

automatycznie zaakceptować obejścia.

Ale trzeba zrozumieć:

dlaczego istnieją.

Badania pokazują, że odchylenia mogą wynikać z całego systemu pracy

W badaniu dotyczącym procedur w środowisku przemysłowym użytkownicy wskazywali przyczyny odchyleń związane nie tylko z indywidualnym zachowaniem, ale również z warunkami organizacyjnymi, środowiskowymi i zadaniowymi.

Empiryczne badanie z 2023 r. dotyczące przestrzegania SOP przy zbieraniu danych w branży pocztowej wykazało natomiast zależności compliance m.in. od workloadu, zmęczenia, doświadczenia operatora oraz działań organizacji wzmacniających przestrzeganie procedur. Wynik dotyczy konkretnego procesu i branży, ale pokazuje, że wykonanie SOP zależy od szerszego środowiska pracy, a nie wyłącznie od treści dokumentu.

Procedura może wymagać zbyt dużej pracy poznawczej

Wyobraźmy sobie operatora.

Aby wykonać jedno zadanie, musi:

przeczytać 24-stronicową procedurę;
przejść do załącznika;
znaleźć właściwą tabelę;
wrócić do głównego dokumentu;
sprawdzić wyjątek;
otworzyć osobną politykę.

Formalnie:

wszystkie informacje istnieją.

Operacyjnie:

kontrola może być bardzo trudna.

Procedure Cognitive Load Test

Pytamy:

ile dokumentów trzeba otworzyć?
ile wyjątków zapamiętać?
ile decyzji podjąć?
ile razy przełączyć system?
czy critical information jest widoczna w momencie wykonania?

Badania nad work instructions w produkcji wskazują, że sposób przekazania instrukcji i obciążenie poznawcze użytkownika są istotnymi elementami projektowania wsparcia pracy.

Nie oznacza to, że:

każda procedura powinna być aplikacją AR.

Oznacza:

forma instrukcji powinna odpowiadać zadaniu użytkownika.

Procedure Usability – pięć pytań

Użytkownik powinien móc:

FIND

znaleźć procedurę.

UNDERSTAND

zrozumieć.

DECIDE

rozpoznać właściwą ścieżkę.

EXECUTE

wykonać.

PROVE

zostawić ślad działania.

Jeżeli któryś etap nie działa:

procedura może nie działać jako kontrola.

Badania procesowe wskazują na znaczenie usability procedur

Artykuł z Process Safety Progress z 2024 r., opisujący wieloletnie doświadczenia przedsiębiorstwa z obszaru process safety, wskazywał usability procedur i human factors jako istotne źródła odchyleń działania operatorów i opisywał podejście do lifecycle procedur oraz redukcji błędów. Jest to case study specyficznego środowiska przemysłowego, a nie uniwersalne badanie wszystkich organizacji, ale dobrze ilustruje znaczenie projektowania procedur z perspektywy użytkownika.

Test „nowego pracownika”

Bardzo dobry audyt można wykonać poprzez pytanie:

Czy kompetentna osoba, która rozpoczęła pracę miesiąc temu, potrafi wykonać proces wyłącznie na podstawie dostępnych instrukcji i szkolenia?

Jeżeli odpowiedź brzmi:

tylko jeśli zadzwoni do Kasi, bo Kasia wie,

to firma posiada:

tribal knowledge.

Nie w pełni kontrolowany proces.

Tribal Knowledge Risk

Wiedza działa tak długo, jak długo:

właściwa osoba jest dostępna.

Ryzyko pojawia się przy:

urlopie;
odejściu;
zmianie zespołu;
skalowaniu organizacji.

Dobra procedura nie eliminuje doświadczenia.

Powinna jednak przechowywać:

krytyczne elementy wiedzy organizacyjnej.

Szkolenie nie naprawi złej procedury

To kolejna częsta reakcja:

pracownicy nie stosują procedury → szkolenie.

Być może.

Ale jeśli procedura jest:

sprzeczna;
nieaktualna;
niewykonalna;
niedostępna;

szkolenie może tylko:

utrwalać problem.

Najpierw:

PROCEDURE QUALITY

dopiero potem:

TRAINING.

Training Effectiveness Test

Nie pytaj wyłącznie:

czy pracownik uczestniczył w szkoleniu?

Pytaj:

czy po szkoleniu potrafi wykonać wymagane działanie?

Attendance:

to evidence szkolenia.

Nie:

evidence competence.

ISO 9001:2026 nadal obejmuje kompetencje, awareness i komunikację jako elementy systemu zarządzania jakością.

Case-Based Training może być silniejszy niż prezentacja polityki

Zamiast:

60 slajdów,

można dać trzy scenariusze:

Klient oferuje prezent.

Dostawca nie przesyła dokumentu.

Menedżer prosi o pominięcie approvalu.

Pytanie:

co robisz?

To testuje:

zastosowanie polityki.

Nie zapamiętanie treści.

DOJ ECCP również wskazuje na znaczenie dostosowania trainingu i komunikacji do odbiorcy, a także praktycznych porad czy case studies odnoszących się do realnych sytuacji.

Exception Management – procedura bez wyjątków może generować nieformalny „drugi system”

Każda organizacja napotyka przypadki nietypowe.

Jeżeli oficjalny proces nie ma ścieżki wyjątkowej, powstaje:

„zróbmy to tym razem inaczej”.

Po pewnym czasie:

wyjątek staje się normą.

Exception Register

Przy procesach wysokiego ryzyka warto rejestrować:

Data	Wyjątek	Powód	Approval	Termin
01.09	brak dokumentu X	pilna dostawa	Compliance	7 dni
12.09	przekroczenie limitu	projekt krytyczny	CFO	jednorazowo

To pozwala zobaczyć:

czy wyjątki są rzeczywiście wyjątkami.

Jeżeli wyjątek występuje 40% czasu, być może problemem jest procedura

Możliwe przyczyny:

próg jest nierealny;
proces nie odpowiada działalności;
system został źle zaprojektowany.

Audit powinien wtedy badać:

root cause.

Nie tylko:

częściej przypominać o przestrzeganiu procedury.

Procedure Performance Metrics

Można mierzyć:

compliance rate;
liczbę wyjątków;
czas wykonania;
liczbę błędów;
liczbę eskalacji;
czas approvalu;
liczbę pytań do supportu.

Ale same KPI nie wystarczą.

Przykład:

100% formularzy wypełnione.

Czy proces działa?

Nie wiemy.

Być może formularz jest:

automatycznie zatwierdzany bez realnej kontroli.

Evidence of Activity ≠ Evidence of Control Effectiveness

To fundamentalna różnica.

Activity

formularz istnieje.

Effectiveness

formularz pozwala wykrywać problem, dla którego został zaprojektowany.

Audyt powinien sprawdzać oba poziomy.

Control Design vs Control Operating Effectiveness

Można zastosować rozróżnienie:

Design Effectiveness

Czy kontrola jest sensownie zaprojektowana?

Operating Effectiveness

Czy jest wykonywana?

Outcome Effectiveness

Czy rzeczywiście ogranicza ryzyko?

Przykład:

approval wydatków.

Design:

dwa poziomy.

Operating:

oba zatwierdzenia są rejestrowane.

Outcome:

czy approval rzeczywiście wykrywa niedozwolone wydatki, czy jest mechanicznym kliknięciem?

To trzy różne pytania.

Procedure Execution Audit – jak przeprowadzić go praktycznie?

Można zastosować osiem przebiegów.

PASS 1 – Document Architecture

Polityki, procedury, instrukcje, hierarchia.

PASS 2 – Ownership & Version

Owner, data, aktualność.

PASS 3 – Execution Logic

Trigger, actor, action, decision.

PASS 4 – Evidence

Czy wykonanie pozostawia ślad?

PASS 5 – Scenario Test

Happy / negative / exception.

PASS 6 – Work-as-Done

Jak proces naprawdę działa?

PASS 7 – System Integration

Czy narzędzia wspierają procedurę?

PASS 8 – Feedback & Change

Czy system uczy się i aktualizuje?

To znacznie szerszy audyt niż:

kontrola redakcyjna dokumentu.

Procedure Audit Coverage Matrix

Obszar	Full	Sampling	Nie badano
wersje	✓
role	✓
decision points	✓
wykonanie		✓
szkolenia		✓
system IT		✓
zgodność prawna			✓

To pozwala jasno powiedzieć:

co rzeczywiście objęto audytem.

Przykład 1. Procedura zakupowa

Polityka:

trzy oferty powyżej 100 tys.

Work-as-Done:

pracownicy zamawiają najpierw, a oferty zbierają później.

Problem nie znajduje się wyłącznie w:

nieprzestrzeganiu procedury.

Trzeba sprawdzić:

kiedy pojawia się potrzeba zakupowa;
czy czas na trzy oferty jest realistyczny;
czy system blokuje zakup;
czy istnieje procedura pilna.

Dopiero wtedy można zaprojektować remediation.

Przykład 2. Polityka bezpieczeństwa informacji

Polityka:

dane poufne przesyłać bezpiecznym kanałem.

Pracownik:

nie wie, który kanał jest bezpieczny.

Finding:

niejasne kryterium wykonania.

Remediation:

wskazanie zatwierdzonych kanałów i ścieżki dla wyjątków.

To podobna logika do bezpiecznego przekazywania dokumentów do audytu.

Przykład 3. Procedura incydentowa

Dokument:

„Incydenty należy zgłaszać niezwłocznie.”

Pracownik znajduje:

e-mail security;
numer IT;
portal;
przełożonego.

Którą ścieżkę wybrać?

Jeżeli procedura nie mówi:

powstaje ambiguity.

Przykład 4. Polityka konfliktu interesów

Zasada:

konflikt trzeba ujawnić.

Ale:

brak definicji;
brak formularza;
brak ownera;
brak terminu;
brak procesu decyzji.

Polityka deklaruje:

wartość.

Nie tworzy jeszcze:

operacyjnej kontroli.

Procedura może być zbyt szczegółowa

Problem działa również w drugą stronę.

Dokument ma:

94 strony.

Opisuje:

każdą możliwą sytuację.

Pracownik nie potrafi znaleźć:

właściwego kroku.

To Procedure Bloat.

Procedure Bloat zwiększa ryzyko lokalnych instrukcji

Jeżeli oficjalny dokument jest zbyt trudny:

zespoły tworzą własne skróty.

Na przykład:

instrukcja_krótka_Janek.docx

Teraz funkcjonują:

oficjalna procedura;
skrót;
wiedza ustna.

To może być sygnał:

że dokument formalny nie spełnia potrzeb użytkownika.

Jednostronicowy Job Aid może być częścią dobrze zaprojektowanego systemu

Nie każdy pracownik potrzebuje:

pełnej polityki podczas każdej czynności.

Można mieć:

policy;
procedure;
quick guide;
checklist;
decision tree.

Warunek:

wszystkie elementy muszą być spójne i kontrolowane wersją.

Nie upraszczaj kosztem krytycznych warunków

Quick guide:

ma być prosty.

Ale nie może usuwać:

wyjątku;
stop condition;
obowiązku eskalacji.

Dlatego również skrócone materiały powinny przechodzić:

cross-document check.

Procedure Owner – ktoś musi być odpowiedzialny za życie dokumentu

Owner odpowiada za:

aktualność;
review;
zmiany;
feedback;
komunikację.

Nie powinien być tylko:

nazwiskiem w stopce.

Review Date ≠ Review Completed

Dokument może mieć:

„review annually”.

Ale czy ktoś rzeczywiście sprawdził:

zmiany prawa;
proces;
system;
feedback użytkowników;
wyjątki?

Samo przesunięcie daty:

2025 → 2026

nie jest merytorycznym review.

Procedure Review Gate

Przy cyklicznym przeglądzie pytamy:

Czy zmieniło się prawo lub wymaganie?
Czy zmienił się proces?
Czy zmienił się system?
Czy zmieniły się role?
Czy były incydenty?
Czy występują powtarzalne wyjątki?
Czy użytkownicy zgłaszali problemy?
Czy istnieją nowsze wersje dokumentów zależnych?

Dopiero wtedy:

renewed.

Jak raportować findingi proceduralne?

Słabo:

„procedura niejasna”.

Lepiej:

W procedurze nie określono kryterium uruchamiającego enhanced due diligence. Pracownicy muszą samodzielnie zdecydować, które przypadki kwalifikują się jako podwyższone ryzyko, co może prowadzić do niejednolitego stosowania kontroli.

Teraz finding ma:

gap;
impact;
remediation direction.

Procedural Finding Register

ID	Finding	Materiality	Owner	Status
P-01	brak triggera EDD	HIGH	Compliance	OPEN
P-02	2 aktywne wersje	HIGH	QMS	OPEN
P-03	brak ścieżki wyjątku	MODERATE	Procurement	OPEN
P-04	instrukcja trudno dostępna	MODERATE	HR	ACTION

Obsługę całego cyklu można prowadzić zgodnie z Finding Register 360.

Po poprawieniu procedury trzeba wykonać retest

Zmiana dokumentu nie oznacza:

że proces już działa.

Po remediation trzeba:

powtórzyć scenariusz;
sprawdzić dostępność;
sprawdzić zrozumienie;
sprawdzić system;
sprawdzić evidence.

Czyli:

DOCUMENT RETEST + EXECUTION RETEST.

Mechanizm zamykania findingów opisuję szerzej w artykule „Poprawione” nie znaczy „zamknięte”.

Procedure Execution Gate – 12 pytań

Przed uznaniem procedury za operacyjnie gotową zapytaj:

Czy wiadomo, po co procedura istnieje?
Czy użytkownik wie, kiedy ją uruchomić?
Czy role są jednoznaczne?
Czy działania są wykonywalne?
Czy decision points mają kryteria?
Czy wiadomo, gdzie znaleźć aktualną wersję?
Czy wykonanie pozostawia wymagany dowód?
Czy istnieje ścieżka wyjątków?
Czy istnieje eskalacja?
Czy systemy IT wspierają procedurę?
Czy użytkownik potrafi wykonać scenario test?
Czy istnieje mechanizm feedbacku i aktualizacji?

Nie licz:

11/12 = 92%.

Jeden brak może dotyczyć:

krytycznej kontroli.

Pięć możliwych wyników audytu

DOCUMENT PASS

Dokument jest formalnie spójny.

EXECUTION PASS

Scenariusze dają się wykonać.

PASS WITH LIMITATIONS

Istnieją jawne ograniczenia.

REMEDIATION REQUIRED

Występują luki wymagające naprawy.

HOLD

Procedura nie powinna jeszcze pełnić funkcji wymaganej kontroli.

Taki wynik mówi znacznie więcej niż:

„procedura jest poprawna”.

Najczęstsze pytania

Czy każda polityka powinna zawierać szczegółową instrukcję?

Nie. Polityka może definiować zasady, a wykonanie może być opisane w osobnej procedurze lub work instruction. Ważna jest spójność i jasna hierarchia dokumentów.

Czy krótka procedura jest lepsza?

Nie automatycznie. Powinna być tak długa, jak wymaga zadanie, ale nie bardziej skomplikowana niż to konieczne.

Czy procedura podpisana przez zarząd może nadal być słaba?

Tak. Approval potwierdza zatwierdzenie, nie usability ani operating effectiveness.

Czy szkolenie wystarczy, jeśli procedura jest trudna?

Nie zawsze. Szkolenie może pomóc, ale nie powinno kompensować fundamentalnie niejasnej lub niewykonalnej procedury.

Czy nieprzestrzeganie SOP zawsze oznacza błąd pracownika?

Nie. Badania human factors wskazują, że odchylenia mogą mieć źródła indywidualne, organizacyjne, środowiskowe i zadaniowe.

Czy DOJ ECCP obowiązuje polskie przedsiębiorstwa?

Nie jako ogólny polski standard prawny. Jest wytyczną amerykańskiego Departamentu Sprawiedliwości dotyczącą oceny corporate compliance programs. W artykule wykorzystuję ją jako praktyczny punkt odniesienia dla pytań o dostępność, wdrożenie i skuteczność polityk.

Czy ISO 9001:2026 wymaga Procedure Execution Test?

Nie. Procedure Execution Test jest autorskim modelem Expert Design. ISO 9001:2026 stanowi natomiast współczesny punkt odniesienia dla zarządzania procesami, kompetencji, komunikacji, documented information, performance evaluation i improvement.

Dobra procedura nie jest dokumentem, który można przeczytać. Jest dokumentem, dzięki któremu można poprawnie działać

To najważniejszy wniosek.

Procedura może mieć:

poprawną podstawę prawną,

piękną strukturę,

właściwe logo,

podpis prezesa.

I nadal nie odpowiadać:

„Co dokładnie mam zrobić?”

Dlatego profesjonalny audyt powinien przejść przez:

PURPOSE → TRIGGER → ACTOR → ACTION → DECISION → EVIDENCE → ESCALATION → FEEDBACK

To właśnie Procedure Execution Test Expert Design.

Jeżeli łańcuch działa:

polityka ma szansę przekształcić się w rzeczywistą kontrolę.

Jeżeli się urywa:

organizacja może mieć paper compliance – formalne dokumenty, które nie sterują realnym zachowaniem.

Najbardziej wartościowy test nie brzmi więc:

„Czy procedura istnieje?”

ani nawet:

„Czy pracownik ją przeczytał?”

Tylko:

„Czy w realnym scenariuszu potrafi dzięki niej podjąć właściwą decyzję i zostawić dowód, że proces został wykonany?”

Jeżeli firma posiada wiele procedur, nie trzeba od razu audytować wszystkich z taką samą intensywnością.

Można rozpocząć od:

Procedure Risk Triage

i wybrać procesy, w których błąd może powodować:

istotną stratę;
naruszenie;
incydent;
błędną decyzję;
brak kontroli.

Następnie dla najważniejszych procedur wykonujemy:

Document Review → Scenario Test → Work-as-Done Review → Remediation → Retest.

To pozwala zmienić bibliotekę polityk z:

zbioru dokumentów

system rzeczywiście wspierający pracowników i kontrolujący ryzyko.

Opisz procedurę lub politykę wymagającą kontroli operacyjnej

Źródła i podstawa merytoryczna

ISO 9001:2026, Quality management systems — Requirements – aktualne, szóste wydanie ISO 9001 zostało opublikowane 16 września 2026 r. i zastąpiło ISO 9001:2015. Standard obejmuje m.in. leadership, planning, competence, awareness, communication, documented information, operation, performance evaluation i improvement. W artykule służy jako punkt odniesienia dla systemowego podejścia do jakości i skuteczności procesów; Procedure Execution Test nie jest wymaganym przez ISO formularzem.

U.S. Department of Justice, Criminal Division, Evaluation of Corporate Compliance Programs, Updated September 2024 – guidance oceniające m.in. projektowanie polityk i procedur, ich dostępność, komunikowanie pracownikom, operacyjne wdrożenie, training oraz faktyczną skuteczność compliance program. Dokument dotyczy amerykańskiego corporate enforcement i nie stanowi uniwersalnego obowiązującego standardu dla wszystkich przedsiębiorstw.

The realities of procedure deviance: A qualitative examination of divergent work-as-done and work-as-imagined perspectives, International Journal of Industrial Ergonomics, 2024 – badanie jakościowe użytkowników i administratorów procedur w środowisku przemysłowym pokazujące różnice między work-as-imagined i work-as-done oraz złożone przyczyny odchyleń od SOP. Wyników nie należy automatycznie uogólniać na każdą organizację.

One Procedure Change Process, Two Interpretations: A Qualitative Exploration of Differences in User and Administrative Perceptions, IISE Transactions on Occupational Ergonomics and Human Factors, 2024 – badanie procesu aktualizacji SOP w dużym przedsiębiorstwie petrochemicznym wskazujące na różnice pomiędzy postrzeganiem procesu zmian przez administratorów i użytkowników oraz znaczenie przejrzystości, employee buy-in i komunikacji.

Eskandarzadeh S., Fahimnia B., Hoberg K., Adherence to standard operating procedures for improving data quality: An empirical analysis in the postal service industry, Transportation Research Part E, 2023 – badanie dużego zbioru danych z branży pocztowej wskazujące na związki pomiędzy przestrzeganiem SOP a workloadem, zmęczeniem, doświadczeniem i działaniami organizacji wzmacniającymi compliance. Wyniki dotyczą konkretnego procesu i branży.

Wolf-Stokes E., Fisher R., Procedure excellence: Changing paradigms to enable human reliability, Process Safety Progress, 2024 – opis wieloletnich doświadczeń związanych z procedure usability i human factors w środowisku process safety oraz podejścia do lifecycle procedur. Jest to case study specyficznego środowiska przemysłowego, a nie uniwersalny dowód dla wszystkich organizacji.

Dane SEO

1. Meta title: Audyt procedur firmowych – czy naprawdę działają?

2. Meta opis: Jak sprawdzić, czy polityka działa w praktyce? Poznaj Procedure Execution Test: role, decyzje, wyjątki, dowody i retest.

3. Tagi: audyt procedur firmowych, audyt polityk firmowych, procedury firmowe, polityki compliance, SOP, kontrola wewnętrzna, work as done, Procedure Execution Test, compliance, instrukcje pracy

4. Fraza kluczowa: audyt procedur firmowych

5. Uproszczona nazwa: audyt-procedur-firmowych