Komitet Asekurujący

Wydawałoby się, że to przyszli użytkownicy wdrażanego systemu informatycznego powinni pilnować swoich szefów, aby projekt sprawnie posuwał się do przodu, tymczasem jest odwrotnie - bez zaangażowania dyrektorów żaden projekt nie ma szans powodzenia.

Wydawałoby się, że to przyszli użytkownicy wdrażanego systemu informatycznego powinni pilnować swoich szefów, aby projekt sprawnie posuwał się do przodu, tymczasem jest odwrotnie - bez zaangażowania dyrektorów żaden projekt nie ma szans powodzenia.

Byłby w głębokim błędzie każdy, kto szukałby przyczyny takiego stanu rzeczy w nieprzezwyciężalnej, wręcz biologicznej niechęci szeregowych pracowników do przeprowadzania zmian, do wprowadzania nowych narzędzi i nowych form pracy. Wszyscy deklarują - i rzeczywiście tak jest - że chcą pracować według lepszych wzorów, że potrzebują narzędzi uwalniających ich od działań monotonnych, pracochłonnych, w których z powodzeniem mogłaby ich zastąpić technika. Pracownicy sami potrafią wskazać te obszary, w których system informatyczny usprawniłby ich pracę, polepszył wyniki, a więc i ich osobiste osiągnięcia.

Myliłby się też ten, kto wskazywałby na lenistwo pracowników i odmowę pracy ponad ściśle wyznaczone ramy obowiązków służbowych. To jest problem łatwo rozwiązywalny poprzez odpowiedni system motywacyjny. Często wręcz staje się problemem to, że pracownicy wolą robić rzeczy dodatkowe - w domyśle zaniedbując codzienne obowiązki - bo mają za to dodatkowe pieniądze, niebagatelne w ich, na ogół skromnym, budżecie.

Również po powierzchni problemu prześlizgnie się ten, kto będzie próbował rzecz wyjaśniać w kategoriach antagonizmów między równymi grupami. Antagonizmy owszem są, ale przecież udział dyrekcji we wdrożeniu wcale ich nie likwiduje, tylko zsyła do podziemia, do strefy niejawnej, o której wszyscy wiedzą, ale nikt nie omawia.

Zatem jaki problem rozwiązuje tak zwany Komitet Sterujący, nieśmiertelny element wszystkich projektów informatycznych?

Jeden problem jest oczywisty. Komitet złożony z najwyższego kierownictwa jest potrzebny w procesie wdrożenia, żeby rozstrzygać o sprawach, które jego dotyczą, np. jakie raporty chce otrzymywać, w jakiej formie, jak często, z jakimi danymi i z jakimi analizami. Drugi też jest oczywisty. Komitet Sterujący musi reagować w sytuacjach awaryjnych, na przykład oszustwa ze strony dostawcy, choroby kluczowych osób w projekcie albo sabotażu ze strony lokalnego przywódcy pracowniczego.

A dwa kolejne zadania Komitetu Sterującego są mniej oczywiste. Wszyscy o nich wiedzą, ale sprawy są na tyle wstydliwe, że lepiej ich nie poruszać publicznie. Otóż wspomniałam wcześniej, że rzeczywiście na ogół pracownicy rozumieją konieczność zmian i z mniejszymi lub większymi oporami godzą się z niedogodnościami okresu przejściowego, z koniecznością dodatkowej pracy i nauki. Ale, ale... to, że akceptują nowe narzędzia wcale nie znaczy, że akceptują ich konkretny kształt. Problemy rodzą się właśnie w momencie podjęcia decyzji, czy coś ma tak wyglądać czy inaczej, czy tego oczekiwano czy raczej czegoś innego, czy to jest optymalne czy można jeszcze ulepszyć. Dyskusje mogą nie mieć końca, a wypracowanie zgody bywa prawie niemożliwe, bo gdzieś tam pod skórą tkwi jednak ta irracjonalna niezgoda na nowe. A jeszcze jak każdy zainteresowany albo znający się na rzeczy uzna zabranie głosu za sprawę honoru, to są wszystkie przesłanki do tego, aby projekt pogrążył się w personalnych niesnaskach i upadł. Komitet Sterujący jest po to więc, żeby arbitralnie, niedemokratycznie uciąć te dywagacje. Być może wybierze rozwiązanie nie najlepsze, być może kogoś urazi, ale projekt odzyska szansę realizacji, a i pracownicy będą czuli się lepiej, bo ktoś uwolni ich od wewnętrznego - również dla nich psychicznie uciążliwego - przymusu forsowania swojego zdania i zmobilizuje do zgody.

Drugie zadanie to rola pogotowia ratunkowego dla projektu. Ono najczęś-ciej wtedy jest potrzebne, gdy wychodzą na jaw niedoróbki kontraktu. Czegoś do końca nie ustalono, czegoś nie przewidziano, jakiś problem uznano, że rozwiąże się sam, coś zostawiono na nieokreślone później. Potem w trakcie realizacji projektu po kolei ujawniają się wszystkie te niedoróbki. Umowę zawiera zarząd, zarząd więc musi również zostać przywołany do sprecyzowania tego, czego w umowie nie ustalono, a powinno być ustalone. Tak naprawdę istnienie Komitetu Sterującego uświadamia, jak mało konkretne - chciałoby się powiedzieć, jak bardzo nieprofesjonalne - są umowy na zakup licencji i wdrożenie oprogramowania.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200