Procedury - zdefiniowane, sprawdzone, zatwierdzone i wdrożone - regulują postępowanie pracowników przy wykonywaniu zadań. Często ulegają modyfikacjom, dostosowywane są do zmieniającego się systemu informatycznego i nowych warunków pracy. Powstaje więc problem ze zdefiniowaniem, która wersja procedury jest wersją aktualną, oraz kto ma określić, która procedura jest aktualna?

W pewnej firmie jednym z zadań informatyków był nadzór nad systemem kontroli dostępu do firmy. Oznaczało to nadawanie uprawnień do określonych pomieszczeń (stref) w firmie i przebywania w pracy w określonym dniu, czasie itp. Wiązało się to także z wydawaniem kart dostępu, będących fizycznym nośnikiem tych uprawnień. Wstępnie ustalono, że po przeszkoleniu uprawnienia i karty będą wydawać wszyscy pracownicy działu informatycznego. Rozwiązanie to zapewniało szybkie realizowanie potrzeb użytkowników.

Okazało się jednak, że poza informatykiem odpowiedzialnym za całość systemu, inni nie do końca traktują poważnie procedurę nadawania uprawnień i w efekcie powstał bałagan. Na zebraniu działu informatycznego ustalono więc, że uprawnienia i karty będzie wydawał wyłącznie informatyk odpowiedzialny za system. Taki układ nie powinien powodować kłopotów z realizacją potrzeb użytkowników, w pierwszych dniach pracy nowy pracownik wspomagany jest bowiem przez kolegów starszych stażem. Przemieszczanie się po firmie będzie odbywało się - chwilowo - przy ich pomocy.

Kilka dni później, podczas rozmowy kierownik działu i szef grupy serwisu ustalili, że wszyscy informatycy będą nadawać uprawnienia. Procedura uległa zmianie, ale wiedziały o tym tylko dwie osoby. Niedługo potem jeden z informatyków odmówił nadania uprawnień i poprosił nowego pracownika o odczekanie kilku godzin, kiedy miał przyjść na dyżur informatyk odpowiedzialny za system kontroli. Pracownik poskarżył się szefowi serwisu, a ten miał pretensję do informatyka o odmowę wykonania zadania. Szef zapomniał, że nie poinformował o zmianie procedury.

Przypadkowa wersja

Każdy system informatyczny może ulec awarii. Jeśli można go później bezproblemowo uruchomić - to dobrze. Sytuacja się komplikuje, jeśli naprawa wymaga skomplikowanego konfigurowania.

W pewnej firmie działał system, którego zadaniem było stałe zbieranie informacji z Internetu. Odpowiedzialny za niego informatyk przygotował specjalną procedurę odtwarzania parametrów systemu po awarii, gdyż zwykłe uruchomienie powodowało, że nie uruchamiało się wiele potrzebnych użytkownikom usług. Aby uzyskać wszystkie funkcje, należało podczas uruchamiania systemu zmieniać parametry zgodnie ze skomplikowanym algorytmem. Czynności te opisane były w procedurze. Jednak po zmianach, które pewnego dnia wystąpiły w Internecie, część algorytmu przestała działać prawidłowo. Informatyk wziął się do pracy, podejmując działania zmierzające do i opracowania nowej wersji procedury. Nie od razu wszystko zadziałało, kolejne wersje procedury można więc było znaleźć na biurku informatyka.

Kryzys pojawił się wtedy, gdy twórca procedury zostawił jedną z roboczych wersji dokumentu przy serwerze. Wkrótce nastąpiła awaria, którą próbował usunąć jeden z pracowników działu, kierując się zaleceniami ze znalezionego przy serwerze dokumentu. Niestety, spowodowało to tylko pogorszenie sytuacji. Dopiero wezwany telefonicznie twórca procedury wszystko naprawił. Przyczyną kłopotów było z jednej strony pozostawienie przypadkowego dokumentu, z drugiej - przyjęcie z góry przez informatyka próbującego usunąć awarię, że ten właśnie dokument, leżący obok serwera, jest aktualną wersją procedury.

Rysunek dowodzenia

Tadeusz Sołtyk, znany polski konstruktor lotniczy, w książce "Dwa żywioły, dwie pasje" opowiada o metodzie nadzoru działań ludzi, rozproszonych w kilku miejscach, podczas prac wykonywanych w długim czasie, przy często następujących zmianach zakresu prac. Metodę tę Tadeusz Sołtyk stosował podczas realizacji projektów nowych samolotów, chociaż używają jej zapewne wszyscy konstruktorzy. Metoda - nazywana rysunkiem dowodzenia - nadaje się doskonale do stworzenia reguł określających zasady pracy informatyków.

Rysunkiem jest zbiór dokumentów (procedur, instrukcji, rysunków itp.), opisujących całość zadania. Praca w całości przeprowadzana jest wyłącznie według rysunku. Jeśli z jakichkolwiek powodów trzeba zmienić jej reguły, zmiany muszą znaleźć się na rysunku. Wszelkie zmiany, wynikające z rozwoju, opóźnienia czy innych przyczyn, są nieoficjalne do czasu, kiedy zostaną odzwierciedlone na rysunku. Oznacza to, że pracownicy nie muszą przyjmować zmian do wiadomości, dopóki nie zostaną one umieszczone na... tak, na rysunku. W ten sposób zaznacza się podział na to, co aktualne - a więc ważne, teraz realizowane, od tego, co przyszłe - więc potencjalnie ważne. Wszelkie procedury, instalacje, implementacje są wyłącznie potencjalnymi regułami pracy. Dopiero po sprawdzeniu, przedyskutowaniu, zatwierdzeniu i wprowadzeniu zmian w rysunku stają się regułami obowiązującymi.

Dla informatyków oznacza to konieczność - oprócz przeprowadzania aktualizacji dokumentacji - wykonania następnego kroku, zatwierdzenia zmian. Krok ten nie jest niczym nowym. Każda procedura zawiera miejsce na podpis osoby zatwierdzającej ją. Jednak warto zwrócić uwagę, że zbyt często aktualizacje dokonywane są werbalnie, czyli nie następuje zmiana na rysunku. Osoba, która w rozmowie nie uczestniczy, wykona procedurę według jej rysunkowego brzmienia, a więc zgodnie z zapisem, a niezgodnie z intencją ostatniej aktualizacji - czego oczywiście nikt sobie nie życzy. Dlatego przyjęcie rysunkowego sposobu myślenia może ułatwić wiele zadań i uchronić przed problemami.