Przykłady standardowych procedur operacyjnych: 3 gotowe SOP
Poznaj trzy przykłady standardowych procedur operacyjnych wraz z krokami, systemami i wyjątkami. Dowiedz się, co powinna zawierać SOP i jak utrzymać ją w aktualności.
Przykład standardowej procedury operacyjnej jest najbardziej przydatny wtedy, gdy pokazuje rzeczywiste kroki, systemy i wyjątki, a nie tylko listę nagłówków. Poniżej przedstawiamy trzy gotowe przykłady, a następnie omawiamy budowę procedury, którą można utrzymywać, sposób dokumentowania jej w miejscu wykonywania pracy oraz praktyczną metodę sprawdzenia, czy nadal odpowiada rzeczywistości.
Czym jest standardowa procedura operacyjna?
SOP opisuje sposób wykonywania powtarzalnego zadania: kto je wykonuje, w jakiej kolejności, w którym systemie i co zrobić, gdy standardowa ścieżka nie ma zastosowania. Zapewnia zespołowi wspólny punkt odniesienia do wykonywania pracy i szkolenia nowych osób. Jej jakość zależy jednak od tego, kiedy ostatnio porównano ją z rzeczywistym przebiegiem pracy.
Czym SOP różni się od polityki, instrukcji roboczej i mapy procesu?
Te dokumenty pełnią różne funkcje:
- Polityka określa decyzje podjęte przez organizację. Na przykład: „Wszystkie faktury powyżej 10 000 wymagają podwójnego zatwierdzenia”.
- Instrukcja robocza wyjaśnia, jak wykonać konkretny krok, na przykład którego ekranu, pola lub przycisku użyć. SOP określa, co dzieje się dalej, a instrukcja robocza wyjaśnia, jak wykonać dany krok.
- Mapa procesu pokazuje przepływ pracy między rolami i systemami. SOP opisuje szczegółowo jedno zadanie. Zobacz przewodnik po mapowaniu procesów.
Pisz SOP z myślą o osobie wykonującej pracę. Uwzględnij sytuacje, w których musi podjąć decyzję lub obsłużyć wyjątek.
Trzy przykłady standardowych procedur operacyjnych
Każdy przykład zawiera tabelę kroków z przypisaną rolą, systemem, oczekiwanym wynikiem i ścieżką postępowania w razie wyjątku. Dzięki tym informacjom łatwiej stosować procedurę i porównywać ją z pracą zarejestrowaną w systemach.
Przykład 1: Obsługa wyjątków przy fakturach w centrach usług wspólnych
Procedura rozpoczyna się, gdy faktura nie przejdzie trójstronnego uzgodnienia. Kolumna dotycząca wyjątków wyjaśnia, co zrobić, gdy krok nie przebiega zgodnie z planem.
| Krok | Kto | System | Wynik | Co zrobić w razie problemu |
|---|---|---|---|---|
| 1 | Pracownik działu zobowiązań | ERP | Utworzona sprawa wyjątku z kodem przyczyny | Brak kodu przyczyny: przed rozpoczęciem analizy przekazać sprawę liderowi zespołu zobowiązań |
| 2 | Pracownik działu zobowiązań | ERP, portal dostawcy | Zidentyfikowana różnica: cena, ilość lub dostawa | Cena mieści się w tolerancji 2%: zaksięgować fakturę i odnotować odchylenie |
| 3 | Kupiec | ERP | Potwierdzenie, że towary otrzymano zgodnie z zamówieniem | Kupiec niedostępny przez 2 dni: eskalować sprawę do menedżera kategorii |
| 4 | Pracownik działu zobowiązań | ERP | Wniosek o notę kredytową lub zatwierdzenie faktury do płatności | Dostawca kwestionuje notę kredytową: przejść do procedury rozstrzygania sporów, nie pozostawiać sprawy otwartej |
| 5 | Lider zespołu zobowiązań | ERP | Zamknięta sprawa z odnotowaną przyczyną | Ten sam kod przyczyny pojawia się przez trzy miesiące z rzędu: zgłosić wniosek o zmianę procesu |
Ostatni wiersz pozwala zespołowi zgłosić powtarzający się problem do analizy. Nie zakłada, że każdy wyjątek wymaga takiego samego rozwiązania.
Przykład 2: Przyjęcie i rozmieszczenie towaru
| Krok | Kto | System | Wynik | Co zrobić w razie problemu |
|---|---|---|---|---|
| 1 | Pracownik przyjęcia towaru | WMS | Dostawa sprawdzona z awizem ASN | Brak ASN: ręcznie zarejestrować przyjęcie i oznaczyć dostawcę |
| 2 | Pracownik przyjęcia towaru | WMS | Zarejestrowana ilość i uszkodzenia | Wykryto uszkodzenie: zrobić zdjęcie, umieścić paletę w kwarantannie i powiadomić dział zakupów |
| 3 | Kontroler jakości | QMS | Decyzja o zwolnieniu partii | Partia wstrzymana: towar pozostaje w kwarantannie, nie rozpoczynać rozmieszczania |
| 4 | Pracownik magazynu | WMS | Towar rozmieszczony w sugerowanej lokalizacji | Lokalizacja zablokowana: użyć lokalizacji przepełnienia i odnotować zmianę |
| 5 | Pracownik magazynu | WMS | Zapas dostępny do kompletacji | Przyjęcie zaksięgowane po godzinie granicznej: sprawdzić, czy otwarte zamówienia wymagają ponownego zaplanowania |
Przykład 3: Wstępna kwalifikacja incydentów w dziale wsparcia IT
| Krok | Kto | System | Wynik | Co zrobić w razie problemu |
|---|---|---|---|---|
| 1 | Pracownik działu wsparcia | ITSM | Zarejestrowany incydent z informacją o usłudze, wpływie i pilności | Nie można skontaktować się z użytkownikiem: zarejestrować incydent w jego imieniu i podać źródło informacji |
| 2 | Pracownik działu wsparcia | ITSM, CMDB | Ustalony priorytet na podstawie macierzy wpływu i pilności | Zespół rozwiązujący kwestionuje priorytet: eskalować sprawę do właściciela usługi, nie zmieniać go po cichu |
| 3 | Zespół rozwiązujący | ITSM | Diagnoza i próba naprawy w czasie określonym w SLA | Naprawa wymaga zmiany: powiązać zgłoszenie z rekordem zmiany i pozostawić incydent otwarty |
| 4 | Pracownik działu wsparcia | ITSM | Potwierdzenie użytkownika i zamknięcie incydentu | Użytkownik nie potwierdzi rozwiązania w ciągu 3 dni: zamknąć incydent z podaniem przyczyny |
Co powinna zawierać standardowa procedura operacyjna?
Poniższy układ może posłużyć jako punkt wyjścia do opracowania kolejnej standardowej procedury operacyjnej:
- Cel i zakres: Określ, czego dotyczy procedura, a czego nie obejmuje. Jasne granice pomagają skupić jedną procedurę na jednym zadaniu.
- Zdarzenie uruchamiające: Wskaż zdarzenie rozpoczynające procedurę, aby odbiorca wiedział, kiedy ją stosować.
- Role: Przypisz obowiązki do ról, a nie konkretnych osób. Ludzie się zmieniają, role są stabilniejsze.
- Numerowane kroki i systemy: Opisz każdy krok, wskaż osobę odpowiedzialną za jego wykonanie i używany system.
- Postępowanie w razie wyjątku: Wyjaśnij, co zrobić, gdy standardowa ścieżka nie ma zastosowania. Uwzględnij częste odstępstwa, nie tylko przebieg idealny.
- Kontrole i dowody: Określ, co i gdzie należy rejestrować oraz jak długo przechowywać te informacje.
- Właściciel i historia zmian: Wskaż osobę odpowiedzialną oraz zapisuj datę i zakres każdej zmiany.
- Przesłanka do przeglądu: Określ, co powinno uruchomić przegląd, na przykład zmiana systemu, przepisów lub zespołu albo zauważalna zmiana wyników.
Historia zmian pokazuje, co i kiedy zmieniono. Przesłanka do przeglądu pozwala wrócić do procedury, zanim się zdezaktualizuje.
Jak sprawdzić, czy procedura jest gotowa do użycia?
Przed opublikowaniem lub aktualizacją procedury warto zadać sobie kilka pytań:
- Czy zakres jasno określa, czego procedura nie obejmuje?
- Czy zdarzenie uruchamiające jest jasno opisane na początku?
- Czy przy każdym kroku wskazano rolę, system i oczekiwany wynik?
- Czy kroki wykonywane w aplikacji pokazują ekran, który zobaczy odbiorca?
- Czy procedura wyjaśnia, co zrobić, gdy standardowa ścieżka nie ma zastosowania?
- Czy wskazano właściciela i prowadzona jest historia zmian?
- Czy konkretnie określone zdarzenie uruchamia przegląd?
- Czy można porównać procedurę z danymi o zdarzeniach i czy wszelkie różnice omówiono z właścicielem procesu?
Jeśli nie można odpowiedzieć na ostatnie pytanie, warto najpierw ustalić, które systemy rejestrują pracę. Dzięki temu można sprawdzić, czy procedura nadal odzwierciedla praktykę. W ten sposób jej utrzymanie staje się cyklicznym przeglądem, a nie tylko odkładaniem dokumentu do archiwum.
Jak zarządzać standardowymi procedurami operacyjnymi
Samo opracowanie procedury to łatwiejsza część. Trudniej zarządzać całym programem: ustalić, gdzie przechowywać procedury, która wersja jest aktualna i kto je przegląda. Niezależnie od tego, czy używane jest specjalne oprogramowanie do zarządzania procedurami, czy folder z dokumentami, kopia dla każdego zespołu szybko się dezaktualizuje. ProcessMind przechowuje procedurę razem z opisanym procesem, dzięki czemu zasady zarządzania dotyczą także samego tekstu:
- Dodaj procedurę do opisywanej czynności. Każdy proces ma drzewo dokumentacji z sekcjami skonfigurowanymi raz dla całego środowiska. Dzięki temu każda procedura zaczyna się od tych samych sekcji dotyczących opisu, zakresu, ról, celów i zasad zarządzania. W razie potrzeby organizacji można dodać własne sekcje. Instrukcja robocza pozostaje przy właściwym kroku, zamiast trafiać do folderu, który trzeba później odszukać.
- Przeglądaj procedurę razem z procesem. Proces przechodzi przez etapy: wersja robocza, w przeglądzie, zatwierdzony, opublikowany, wycofany i zarchiwizowany. Recenzenci mogą znaleźć swoje zadania za pomocą filtra „wymaga mojego przeglądu”. Zatwierdzenie może od razu utworzyć opublikowaną wersję, więc dokument nie jest zatwierdzany w jednym miejscu, a zmieniany w innym.
- Dodawaj komentarze przy opisywanej pracy. Opcja Dodaj komentarz przy kroku rozpoczyna dyskusję dotyczącą danej czynności. Pytanie o pole, kontrolę lub wyjątek pozostaje obok instrukcji, zamiast ginąć w skrzynce odbiorczej.
- Zachowuj kolejne wersje. Historia wersji zapisuje, co, kiedy i przez kogo zmieniono. Publikacja określa, którą wersję widzą odbiorcy.
- Przypisuj role na podstawie modelu. Macierz RACI w dokumencie jest wypełniana na podstawie ról przypisanych do czynności w modelu. Dzięki temu odpowiedzialność opisana w tekście odpowiada tej przedstawionej na diagramie.
- Dodawaj zrzuty ekranu tam, gdzie praca odbywa się na ekranie. W ProcessMind można zrobić zrzut ekranu lub nagrać ekran, przyciąć obraz do istotnych elementów, zasłonić dane osobowe, aby pozostały ukryte w zapisanym pliku, i dodać instrukcje w Markdown. Edytor może też wykrywać prawdopodobne pola wrażliwe. Zaznaczenia można edytować i poprawić przed zapisaniem. Zrzut jest przechowywany jako artefakt przypisany do czynności.
- Eksportuj dokument dla osób, które potrzebują pliku. Format Word sprawdza się przy przeglądach i w systemie jakości, Markdown przy kontroli wersji, a PDF i wydruk przy dystrybucji i archiwizacji. W ustawieniach eksportu można określić, czy plik ma zawierać także elementy modelu bez dokumentacji, diagramy procesu i macierz RACI dla każdej czynności. Lista nieudokumentowanych elementów często najszybciej pokazuje, gdzie procedura ma luki.
Dokument to tylko jedna część. Druga to weryfikacja, którą warto przeprowadzić w tym samym miejscu: porównać opisane kroki z czynnościami zarejestrowanymi w systemach, a następnie zdecydować, czy zmiany wymagają szkolenia, aktualizacji dokumentu czy modyfikacji procesu. Zatwierdzona zmiana trafia z powrotem do dokumentacji i otrzymuje własny status wersji.
Warto jasno określić dwa ograniczenia. ProcessMind porządkuje dokumentację i dostarcza materiału do przeglądu, ale nie poświadcza zgodności ani nie zastępuje zatwierdzenia wymaganego przez system zarządzania jakością czy biblioteki polityk prowadzonej przez dział prawny. Narzędzia do zrzutów ekranu działające poza tym workflow, na przykład Scribe, równie dobrze rejestrują sposób wykonania zadania. W przypadku kilku procedur utrzymywanych przez jeden zespół może wystarczyć wiki. Ani wiki, ani osobny magazyn dokumentów nie pokażą jednak, czy procedura nadal odpowiada rzeczywistemu przebiegowi pracy.
Dlaczego pisemne procedury przestają odpowiadać praktyce?
Procedury się dezaktualizują, bo po ich opisaniu zmienia się sposób pracy. Nie musi to oznaczać, że dokument został źle napisany. To znak, że proces ewoluował.
Procedura opiera się na pamięci. Warsztat pokazuje, jak uczestnicy rozumieją proces. Może to odzwierciedlać jego założony przebieg, a nie praktykę. Łatwo przeoczyć wyjątki, choć mogą stanowić znaczną część pracy.
Zespoły wypracowują obejścia. Ktoś znajduje szybszy sposób obsługi częstego przypadku i dzieli się nim ze współpracownikami. Jeśli aktualizacja procedury wymaga więcej wysiłku niż skorzystanie z obejścia, dokument może nie nadążać za praktyką.
Zmieniają się systemy. Zmienia się nazwa pola, kontrola zostaje zautomatyzowana albo próg zatwierdzenia ulega zmianie. Procedura może nadal opisywać poprzednią konfigurację.
Trudno zauważyć zmianę. Dokument nie pokazuje, kiedy praca zaczęła odbiegać od opisu. Bez danych o procesie trzeba prosić ludzi o odtworzenie przebiegu zdarzeń.
Jak utrzymać aktualność procedury
Sam dokument w folderze nie wystarczy. Pomaga powiązanie procedury na bieżąco z procesem i opisywaną czynnością. Dzięki temu zmiana kroku i zmiana dokumentacji są przeglądane razem przez role wskazane w modelu. Opublikowana wersja jest jednym źródłem informacji dla zespołu korzystającego z Process Portal, a każdy eksport powstaje na podstawie tej dokumentacji, nie lokalnej kopii edytowanej przez kogoś z zespołu.
Dwa elementy pomagają ocenić, czy opis odpowiada praktyce. Weryfikacja zgodności mierzy różnicę między udokumentowanym procesem a czynnościami zarejestrowanymi w systemach. Dzięki temu odchylenia można analizować, zamiast tylko ich się domyślać. Nadzór nad procesem pozwala jasno określić, kto odpowiada za tę ocenę, a zasady zarządzania i publikacji określają sposób przeglądu i przechowywania wersji.
Pisemna procedura dezaktualizuje się dopiero wtedy, gdy zmienia się sposób pracy, a wtedy trudno już ustalić, kiedy do tego doszło. Z mojego doświadczenia wynika, że najłatwiej wcześnie zauważyć zmianę, gdy procedura jest powiązana z procesem i opisywaną czynnością. Warto analizować dokumentację i dane razem. W przeciwnym razie jedno z nich zawsze będzie nieaktualne.
Jak opracować procedurę na podstawie danych o zdarzeniach?
Dane o zdarzeniach pokazują, jakie kroki są wykonywane w systemach rejestrujących pracę, takich jak ERP, ITSM czy WMS. Warto wykorzystać je razem z wiedzą o procesie przy opracowywaniu i przeglądzie procedury. Do tego służy między innymi process mining:
-
Wczytaj dziennik zdarzeń
W systemach rejestrujących proces zidentyfikuj identyfikator case, czynność i timestamp. Wybierz jeden sposób określania case i jeden zakres czasu, aby wyniki można było porównywać. -
Zestaw go z udokumentowanym procesem
Zestaw zarejestrowaną sekwencję z krokami opisanymi w procedurze. Niektóre kroki występują w każdym case, inne rzadko, a jeszcze inne wcale. Każda z tych sytuacji wymaga wyjaśnienia. -
Przeanalizuj odchylenia
Sprawdź, jak często przebiega każda ścieżka, gdzie praca czeka i które kroki są powtarzane. Odchylenie w danych to powód do analizy, a nie dowód, że praca przebiega nieprawidłowo. -
Uwzględnij w procedurze istotne odchylenia
Powtarzające się sytuacje opisz jako wyjątki, podając rolę, system i oczekiwany wynik, tak jak w trzech przykładach powyżej. Następnie poproś osoby wykonujące pracę o potwierdzenie informacji, których nie widać w danych.
Dane o procesie pomagają zweryfikować procedurę, ale nie wyjaśniają każdej decyzji ani nie określają, jak proces powinien przebiegać. Omów wyniki z osobami, które wykonują pracę i odpowiadają za proces. Przy okazji wskaż właściciela i przesłankę do przeglądu. Procedura bez właściciela prędzej czy później się zdezaktualizuje.
Where to Go From Here
Mają już Państwo procedurę i sposób jej weryfikacji. Porównajcie opisane kroki z czynnościami rejestrowanymi przez systemy i wykorzystajcie różnice, aby ustalić, co omówić z zespołem procesowym.
