Warning: include(/home/sw/ziembor/public_html/include/headtmpl.php) [function.include]: failed to open stream: No such file or directory in /Windows_NT/po_co_i_jak_pisac_procedury.php on line 1

Warning: include() [function.include]: Failed opening '/home/sw/ziembor/public_html/include/headtmpl.php' for inclusion (include_path='.:/:/usr/local/php/pear5') in /Windows_NT/po_co_i_jak_pisac_procedury.php on line 1
Po co i jak pisać procedury: krótki wstęp do problematyki

Po co i jak pisać procedury: krótki wstęp do problematyki

Ziemek Borowski
Uwaga: jest to moje wstępne podejście do tematu. W gruncie rzeczy więcej nie wiem na ten temat niż wiem: jest to raczej zapis moich dotychczasowych przemyśleń i doświadczeń w zwartym dokumencie -- będzie mi miło jeśli z tego skorzystasz, ale nie jestem w stanie obiecać poprawności poniższego.

Co to jest procedura?

Słownik języka polskiego

podaje, że procedura to: procedura ż IV, CMs. ~urze; lm D. ~ur 1. "unormowany przepisami, zwyczajami sposób prowadzenia, załatwiania jakiejś sprawy; tok, tryb, przebieg czegoś". I tak rolę pełni w życiu przedsiębiorstw: normowanie ich trybu życia, dokumentowanie sposobów pracy/wykonywania pewnych podstawowych dla firmy czynności. W wypadku przedsiębiorstw, gdy mówi się o procedurach chodzi zwykle o konkretne dokumenty wykorzystywane w konkretnych działaniach.

Po co tworzyć procedury?

Po to by ułatwić sobie życie.

Zdanie to brzmi nieco paradoksalnie w kontekście typowych przyczyn poddania procedurom działalności organizacji. Zwykle jest to jedno z dwu rodzajów nieszczęść: sytuacja tuż po awarii, gdy właściciele, kadra zarządzająca, audytorzy chcą wiedzieć czy mieliśmy jakieś plany wyjścia z awarii oraz druga: wprowadzanie modnych wśród kadry zarządzającej norm zarządzania jakością w organizacji: ISO serii 9000 lub inne TQM. Ale to nie do końca tak. Owszem są to dwie najczęstsze przyczyny. Obie, choć momentami niezbyt przyjemne, potrafią przynieść przedsiębiorstwu korzyści -- o ile oczywiście wcześniej nie nastąpi bankructwo ;-). W szczególności normy zarządzania przez jakość/tudzież zarządzania jakością cieszą się wyjątkowo złą opinią (po przykłady odsyłam np. do Dilberta). Lecz jeśli przedsiębiorstwo przeżyje, jeśli proces wprowadzania procedur został odpowiednio:

ma szansę spowodować, że życie w firmie stanie się lżejsze i milsze. Nie tylko każdy będzie znał swoje miejsce ale i większość zadań będzie dobrze opisana, a te które nie będą wkrótce, po pokonaniu pewnej bariery technicznej będzie. Oczywiście taka wizja robienia wszystkiego według pewnego stałego trybu może wydawać się wizją koszmarną, rodem z filmów Chaplina (była tam taka scena z taśmą produkcyjną). I co gorsza pewne ,,standardowe'' metody obijania się znikają ;-). Ale chyba lepiej/prościej mniej pracować z lepszymi efektami. Tyle, że ten zysk produktywności/wydajności pracy ma szansę nastąpić gdy proces wprowadzania norm przebiegał właściwie. Jednym z istotnych elementów, poza np. właściwym zdefiniowaniem tak zwanych procesów biznesowych (czyli ścieżek, metod obsługi klienta), poza wyznaczeniem strategii działania firmy są właściwe, dopasowane do potrzeb i ludzkiej cierpliwości procedury. Zresztą same procedury są wykorzystywane w wielu innych formach ludzkiej działalności: najprostszym przykładem jest tu prawo państwowe. Ustawy, a zwłaszcza rozporządzenia wykonawcze są najpowszechniejszym przykładem rutynizacji pewnych działań zgodnie z wolą zarządzającego. Problem z którym często się borykamy jako ich użytkownicy jest niska jakość tychże. ;-(. Inne przykłady to polityka/zasady bezpieczeństwa informatycznego (a zwłaszcza zasady III, najbardziej operacyjnego poziomu). Inne przykłady to wszelkiego typu plany zapasowe/ciągłości pracy: nawet jeśli firma nie posiada ambicji osiągnięcia certyfikacji ISO serii 9000 lub nie potrzebuje polityki bezpieczeństwa to na pewno potrzebuje zapewnienia choćby podstawowej ciągłości pracy w wypadku awarii: choćby prostego wykonywania kopii zapasowych i sposobów odzyskiwania danych z takiej kopii. Oczywiście można robić to spontanicznie tylko, że zwykle okazuje się że takie spontaniczne wykonywanie kopii nie obejmuje wszystkich danych lub że osoba odpowiedzialna za ich wykonywanie w pewnym momencie przestała je wykonywać bo.... zapomniała. Pewną receptą wydaje się napisanie skryptu który będzie wykonywał taką kopię w nocy, uruchamiany przez odpowiedni mechanizm systemowy. Tylko, że nadal nie jest tu jasna ścieżka odzyskiwania danych. A często jest tak, że takie odzyskiwanie odbywa się w sytuacji sporego napięcia: nerwy, krzyczący zwierzchnicy, rozpaczający użytkownicy, niskie ciśnienie atmosferyczne. I wówczas taki dokument gdzie krok po kroku jest opisana recepta na osiągnięcie sukcesu w danej sytuacji może być niezastąpiony. Kolejnym polem stosowania procedur w administracji systemami informatycznymi jest dokumentowanie takich systemów. O ile część dokumentacji może być w formie opisów funkcjonalności lub architektury to wskazane jest by pewne czynności przybrały formę procedury (odchudzonej często do formy listy następujących po sobie kroków, listy kontrolnej lub podobnej, ale procedury) -- zwłaszcza gdy osiągnięcie danego celu jest czynnością nie trywialną.

Większość metodologii zarządzania IT skupia się na poziomie zasad (policies, polityk). Jednak zazwyczaj administrator ma raczej do czynienia z dokumentami na niższym poziomie ogólności, to jest z procedurami.

Jak pracować z użyciem procedur postępowania?

Czynności poddane procedurom powinny być, i zwykle są, czynnościami rutynowymi. I jako takie nudnymi. A takie często są mimo woli skracane i pomijane. Dlatego warto doprowadzić do systematycznego notowania postępu wykonywania procedury: z jednej strony daje to większą pewność (przy systematycznym sprawdzaniu przez osobę nadzorującą wykonywanie procedury) jej wykonywania, a z drugiej niesie pewne zobowiązanie stawiane przed wykonującym procedurę. Notowanie to powinno mieć jak najprostszą postać, np. "ptaszków" lub podpisów/..parafek'' przy kolejnych krokach procedury, w kolumnie opisanej datą wykonania. Ze strony osób zajmujących się procedurami muszą być jednak spełnione pewne warunki: osoby je przeprowadzające powinny mieć dostęp tylko do ostatniej zatwierdzonej do wykonanie przez nie wersji. Poprzednie wersje powinny być zdawane za podpisem (tak by mieć pewność, że wykorzystywana jest ostania wersja).

Jak pisać procedury?

Samo pisanie procedur wydaje się prostym zajęciem. Jakość tych procedur może być jednak różna. Tu dużo zależy od procesu testowania tychże. Np. w jednym z poradników dotyczących disaster recovery spotkałem się z sugestią przeprowadzania testów odzyskiwania systemu robionych w ten sposób, że np. farmę bazodanową odzyskuje zespół który zazwyczaj zajmuje się siecią, i tą że sieć dokumentował. Siecią zajmuje się wówczas zespół zajmujący się systemami operacyjnymi, systemami operacyjnymi zajmuje się zespół bazodanowy. Daje to możliwość wykrycia pewnych ukrytych ,,oczywistych'' założeń jakie czynią piszący procedury.

Na co moim zdanie warto zwrócić uwagę przy pisaniu procedury:

Oczywiście daje się wymyślić jeszcze multum opisów, warunków brzegowych wykonywania procedury.

Niezbędne elementy

Uważam, że w konkretnym, gotowym do użycia dokumencie niezbędne są następujące elementy:

  1. numer/identyfikator procedury w repozytorium (stały, niezmienny z wersji na wersję)
  2. nazwa procedury
  3. wersja procedury
  4. data obowiązywania (np. Obowiązuje od 2002-04-03)
  5. status (zatwierdzona, testowana, opracowywana) i przez kogo zatwierdzona
  6. lista aktorów (w sensie UML-owym: czyli poza osobami również systemy/programy niezbędne w działaniu) procedury. Tu ew. można to rozbić na osoby i rekwizyty.
  7. Opis warunków/przyczyn wykonywania procedury
  8. Warunki i zalecenia do wykonywania procedury
  9. Kolejne etapy postępowania w procedurze

Czasem można spotkać się, z wymogami umieszczania w takim dokumencie większej ilości informacji np.

Ogólnie takie informacje są potrzebne. Tylko, że powinny znajdowac się w dokumencie ,,mocującym'' procedury, czyli w zasadach/policies.

Przykład: ISP, Zarządzanie DNS-em: Delegowanie domeny podrzędnej.

1. numer procedury ISP/DNS/DEL/006
2. nazwa procedury ISP, Zarządzanie DNS-em: Delegowanie domeny podrzędnej.
3. wersja procedury 0.1
4. data obowiązywania od 2002-06-01 do 2002-06-15
5. status testowa, do oceny, Ziemek Borowski
6. lista aktorów procedury
  1. Administrator ISP
  2. Administrator klienta
  3. Serwer DNS ISP: ns.ten-isp.pl 192.168.42.9
  4. Serwer DNS klienta
7. Opis warunków wykonywania procedury Jest przeprowadzana, gdy Administrator klienta zgłosi zapotrzebowanie.
8. Warunki i zalecenia do wykonywania procedury brak szczególnych
9. Kolejne etapy postępowania w procedurze
  1. Administrator klienta zgłasza podpisanym kluczem X.509 e-mailem lub telefonicznie zapotrzebowanie stworzenia nowej poddomeny
  2. Administrator ISP weryfikuje na liście upoważnionych Administratora klienta
  3. Gdy weryfikacja zostanie przeprowadzona poprawnie administrator deleguje domenę.

Powyższa procedura w częsci szczegółowej jest na pewno nie wystarczająca: powinna zostac opisana szczegółowo droga do wydelegowani poddomeny w kontekście konkretnej konfiguracji używanej przez tego ISP.

Patrz też

$Date: 2002/06/16 12:36:32 $ $Revision: 1.6 $

Warning: include(/home/sw/ziembor/public_html/include/bottomtmpl.php) [function.include]: failed to open stream: No such file or directory in /Windows_NT/po_co_i_jak_pisac_procedury.php on line 469

Warning: include() [function.include]: Failed opening '/home/sw/ziembor/public_html/include/bottomtmpl.php' for inclusion (include_path='.:/:/usr/local/php/pear5') in /Windows_NT/po_co_i_jak_pisac_procedury.php on line 469