Tworzenie procedur operacyjnych powinno odbywać się tam, gdzie będą one stosowane - wśród pracowników.

Tworzenie procedur operacyjnych opiera się na trzech podstawowych działaniach, nie różniąc się zasadniczo od metod wykorzystywanych podczas programowania. Pierwszym etapem jest określenie sytuacji poprzedzającej wykonanie procedury, drugim - opisanie procesów zachodzących podczas jej realizacji, trzecim - wyznaczenie efektów jej działania.

Konstruowanie procedur operacyjnych jest wzbogacone o konieczność uwzględnienia dodatkowego elementu, jakim jest subiektywny czynnik ludzki, wprowadzający w zachodzące procesy własną inwencję, wiedzę lub jej brak, lenistwo, niedbałość czy wręcz złą wolę. Ponadto tworząc aplikację, programista może przewidzieć wszystkie sytuacje, mogące wydarzyć się podczas realizacji procesu, ponieważ zdarzenia w programie zachodzą w świecie sztucznym. Realizacja procedury operacyjnej odbywa się w rzeczywistości - skomplikowanej i chaotycznej, w której mogą zajść przypadki szczególne trudne lub wręcz niemożliwe do przewidzenia.

Dla wszystkich, zamierzających zarządzać systemami w sposób sformalizowany i oparty na procedurach, pouczające są doświadczenia firm starających się o normy jakości ISO 9000. Proces ich opracowania i wdrażania trwa około 2 lat. Dlaczego tak długo? Ponieważ większość czasu zajmuje wychowanie ludzi, pracowników i kadry kierowniczej wszystkich szczebli - do najwyższego włącznie. W pewnej firmie strukturę procesu produkcji, przepływy dokumentów i zagadnienia finansowo-księgowe opisano w 3 miesiące, natomiast prawie rok zajęło przygotowanie procedur i drugie tyle nauczenie ludzi pracy z nimi.

Wszyscy pracownicy muszą zrozumieć potrzebę podporządkowania się wymogom procedur. Nie może być tak, że np. dyrektor firmy jest z systemu wyłączony. Jeśli skończy mu się ważność karty magnetycznej, uprawniającej do wejścia na teren firmy, to może się zdarzyć, że raz wejdzie bez niej. Nie powinno jednak stać się regułą, że dyrektor wchodzi do firmy bez wczytywania karty, ponieważ zadbanie o przedłużenie jej ważności jest poniżej jego godności lub wciąż zapomina o zleceniu sekretarce wykonania tego zadania. Takie wyjątki byłyby szkodliwe, co stałoby się np. gdyby nie chciało mu się także regularnie zmieniać hasła do tajnych danych? Za pozytywny przykład może posłużyć dyrektor znanej firmy informatycznej (mającej za sobą wdrożenie jednej z norm ISO), który podpisał specjalny dokument akceptujący rozwiązania wynikające z wdrożenia systemu jakości, chociaż pozbawiało go to pewnych przywilejów, np. uprawnień administratora wszystkich serwerów firmy.

Tworzenie procedur

Procedury nie mogą być narzucane. Muszą je tworzyć pracownicy wykonujący konkretne czynności, oni bowiem wiedzą najlepiej, co, jak, kiedy i po co robią, od kogo otrzymują zlecenia i dla kogo je wykonują. Metoda uzyskania opisu jest prosta. Wystarczy dać pracownikowi kartkę papieru. Można zostawić ją pustą, zgadzając się na pełną dowolność uzyskanych treści, można też przygotować pytania naprowadzające proces opisu w żądanym kierunku. Przykładowe pytania mogą wyglądać tak:

Co robisz, gdy:

* ktoś dzwoni i zgłasza problem z komputerem

* ktoś przychodzi i zgłasza problem z komputerem

* naprawa wydaje się łatwa i krótkotrwała

* naprawa może być pracochłonna i długotrwała

* do naprawy potrzebujesz narzędzi, części, oprogramowania

* komputer, mimo twoich działań, nie chce się uruchomić.

Oczywiście, nie wyczerpują one zagadnień związanych z serwisem komputerowym. Pozwalają jedynie zwrócić uwagę na najczęściej występujące zdarzenia, będące powodem podjęcia działań przez pracownika.

Opis czynności, przygotowany przez wykonującą je osobę, zawsze będzie niedoskonały. Wynika to z rutyny, której po pewnym czasie nabiera każdy. Powoduje ona zniekształcenie pola widzenia, czasem nawet częściowe ukrycie niektórych funkcji czy zależności. W ramce "dialogi" przedstawiony jest proces tworzenia opisu czynności wykonywanych przez informatyka. Zwraca uwagę stopniowe zwiększanie liczby szczegółów występujących w opisie pracy.

W pierwszym dialogu informatyk przedstawia wyłącznie podstawowe, spełniane przez siebie funkcje: wywiad, naprawa, informacja. Interesujące jest założenie informatyka, że komputer się uruchomi i poprzestanie na opisie takiej sytuacji. Zapewne najczęściej spotyka się on z problemami typu: nie mogę wydrukować, nie mogę zapisać danych na dysku, które nie wymagają ingerencji sprzętowych. Jednak echo innych zadań odnajdujemy w zdaniu „... staram się go uruchomić. Jeśli to się udaje...”. Więc nie zawsze się udaje.

W drugim dialogu okazuje się, że naprawy sprzętu są dokonywane, jednak informatyk spokojnie pomija tak istotne sprawy, jak dostęp do narzędzi i części. Dopiero dodatkowe pytania pokazują, że są używane narzędzia i części, a także w jaki sposób są dostępne.

W trzecim dialogu następuje - kluczowe z punktu widzenia tworzenia procedur - przyłapanie informatyka na pomijaniu takich czynności, jak porządek w narzędziach czy konieczność opisu uszkodzonych części. Oczywiście, narzędzia powinny być odkładane na miejsce, ale czy są? A części, czy rzeczywiście informatyk je opisuje, czy też odkłada na półkę w charakterze pułapki?

Być może rzeczywiście czynności te są wykonywane, ale nie są zauważane jako rutynowe, błahe, nie odgrywające żadnej roli w procesie serwisowania. Jednak rutynowo wykonuje je tylko badany przez nas informatyk. Jego kolega może nie mieć takiego nawyku, co spowoduje szybko postępujący bałagan na opisywanej półce. Celem tworzenia procedury jest przecież uniwersalność, każdy pracownik po zapoznaniu się z nią, musi poradzić sobie na wyznaczonym stanowisku. Dlatego nie można pomijać żadnych prac związanych z tworzoną procedurą. Nie trzeba też dodawać, że na tych trzech dialogach praca się nie kończy.

W zespołach - do uzyskania tych samych efektów - można przeprowadzić burzę mózgów. Początek jest podobny, wszyscy opisują wykonywaną czynność - tę samą. Każdy na swój sposób. Następnie wyznaczona osoba odczytuje opisy, na tablicy zapisując ich cechy wspólne i najważniejsze różnice. Takie porównanie wykazuje, jak bardzo różni się widzenie tych samych procesów przez różnych ludzi. W końcu następuje prawdziwa burza mózgów, podczas której każdy może zgłaszać wszelkie propozycje. Są one natychmiast weryfikowane przez innych pracowników, porównuje się metody i koszty, analizuje skutki ewentualnego wdrożenia. Ostatnim etapem jest zlecenie wybranym pracownikom opracowania szczegółowego opisu procesów na podstawie ustaleń uzyskanych w dyskusji.

Tworzenie opisów czy burze mózgów nie są zdarzeniami jednorazowymi. Muszą być powtarzane, aż do osiągnięcia dwóch celów: uzyskania prawidłowej procedury opisującej proces oraz pełnego zrozumienia przez pracowników powodów, dla których tworzy się procedury i próbuje osiągnąć normy jakości.