4. Zasadnicza rozbieżność między naturą procesów komunikacyjnych a ich inżynierskim ujęciem w systemach informatycznych wpływa na skuteczność zarządzania procesem wytwarzania, w szczególności systemu informacyjnego. To trochę tak, jakbyśmy znaleźli się w zaczarowanym kręgu. Odczytanie naturalnego procesu komunikacji i jego zamknięcie w sformalizowanych procedurach wprowadza łatwy i przewidywalny mechaniczny układ następstw. Pamiętajmy, że w tym ujęciu, obok twierdzenia "łatwy i przewidywalny", występuje też "mechaniczny". Jeżeli dalej podtrzymać związek między prostotą "mechaniki zdarzeń" a ulubionym kreowaniem przez informatykę struktury zarządzania opartej na układzie funkcjonalnym, trzeba koniecznie odnotować negatywne skutki tego działania, tj.:

• (wzmocnione) konflikty interesów przedstawicieli różnych ogniw naturalnego procesu komunikacyjnego. Te konflikty mogą się wyrażać np. w najbardziej prozaiczny sposób: w zwiększaniu wymagań i szczególnych, oczekiwanych preferencjach (np. w zakresie sprzętu i infrastruktury);

• wytłumienie "poprzecznej" natury procesów poprzez wymuszanie sztucznego przerywania ciągów komunikacyjnych na granicy organizacji czy jej komórki. Pomimo tego, że proces komunikacji pomiędzy punktem "A" (klient zgłasza interwencję serwisową) a punktem "B" (klient odbiera naprawiony sprzęt) jest jednym ciągiem, chętnie go przerwiemy na granicy naszej komórki (np. komunikatem - "to nie stabilizator napięcia");

• niepoprawne umiejscowienie jednostki kierującej projektem (projekty informatyczne przypisuje się do komórki informatycznej z automatu);

• niejednoznaczne identyfikowanie przyczyn niepowodzeń, jeżeli tkwią one w systemie organizacji instytucji czy projektu.

5. Ze względu na różnicę między czasem definiowania produktu a jego wytworzeniem powstaje niezamierzona rozbieżność - między wartością wytworzoną a oczekiwaną. Zagadnienia dynamiki wymagań dla realizowanego produktu mieszczą się w kwestii jakości - tutaj ujmowanej w kategoriach spełniania wymagań użytkownika.

Ta uwaga ma w szczególności zastosowanie w przypadku systemów informacyjnych.

Wytworzenie systemu informacyjnego jest ujęte w dość skomplikowany, długotrwały i kosztowny proces. Przy takich uwarunkowaniach, a szczególnie wspomnianej czasochłonności i wysokim koszcie, wyjątkowo trudnym postulatem wydaje się zarówno wielokrotne redefiniowanie wymagań, jak i trafna antycypacja wymagań użytkownika oraz możliwości technologicznych. Jeżeli więc wrócić do cennego postulatu jakościowego Jurana dotyczącego poprawnej definicji produktu jako warunku koniecznego wysokiej jakości, to wydaje się, że trafiamy na sprzeczność bez rozwiązania.

Od razu powiedzmy sobie - jest to sprzeczność nierozwiązywalna w naszej rzeczywistości budowy projektów informacyjnych.

System informacyjny, niezależnie od jego stopnia komplikacji w warunkach polskich, najchętniej definiowany jest jako produkt monolityczny, wielofunkcyjny, realizowany w (abstrakcyjnie) krótkim czasie przy nieograniczoności zasobów. Ten model - najchętniej preferowany przez dostawców - odpowiada każdego typu instytucji, niezależnie od jej wielkości i natury. Kardynalnym błędem jest przyjmowanie takiego modelu dla projektów realizowanych w administracji publicznej, która nie jest monolitem organizacyjnym. W efekcie duże projekty systemów informacyjnych załamują się z różnych przyczyn: zakłócenia finansowania, niestabilności prawa czy zmiany ośrodków decyzyjnych.

Należy uznać, że doraźną przyczyną niepowodzenia projektów może być problem leżący po stronie zasobów, zarządzania czy technologii. Nie jest to jednak prawdziwa przyczyna stanu rzeczy - jest nią duża dynamika zmienności produktu w trakcie realizacji systemu informacyjnego. Ponieważ tej przyczyny (jest to przecież kwestia o proweniencji jakościowej) nie uwzględnia się w ocenie projektów, nie stosuje się tym samym właściwej metody umniejszania ryzyka.

Dynamika zmienności produktu może być uwzględniona jeżeli:

• system informacyjny zostanie zdefiniowany na poziomie jego celów działania. Szczególnie ważne jest, aby wykonawcy pozostawić jak najwięcej obszarów do indywidualnych rozstrzygnięć, pozostając przy właściwościach komunikacyjnych interfejsów;

• architektura systemu opierać się będzie na autonomicznych, "samowystarczalnych" komponentach przygotowanych do współpracy z innymi, podobnie autonomicznymi komponentami;

• założy się wieloletni proces wytwarzania i ewolucji komponentów systemu.

Spełnienie ostatniego postulatu narzuca specyficzne procedury sposobu zamawiania, wytwarzania poszczególnych komponentów i ich eksploatacji.

6. Dla zdefiniowania wymagań systemu informacyjnego i jego wytworzenia udział użytkownika należy sprowadzić do określenia krótkich i zwartych elementów procesu. Użytkownik nie powinien wyrażać poglądów o architekturze systemu i sposobie realizacji celów. Warto przemyśleć "mit użytkownika".

Uwaga ta znajduje się w jawnej opozycji do zaleceń Jurana - a przynajmniej tak by się mogło wydawać. Jest jednak inaczej i chodzi bardziej o konstruktywne usankcjonowanie praktyki, aniżeli odrzucenie zalecenia. Praktyka jest natomiast taka, że w definiowaniu każdego nowego systemu uczestniczą przedstawiciele użytkownika wyłonieni z grupy "najbardziej świadomych" uczestników procesów. Przedstawiciele użytkowników służą jedynie do reinterpretacji projektu informatycznego. W żadnym z przypadków nie występuje sytuacja, aby to użytkownik tworzył wymagania systemu w stopniu równie znaczącym jak analityk lub programista.

Wyjściem naprzeciw postulatom o dostosowaniu produktu do wymagań użytkownika jest zaprojektowana i zaimplementowana elastyczność systemu pozwalająca na jego modyfikowanie już w trakcie eksploatacji.

7. Niezależnie od sposobu i stopnia szczegółowości specyfikacji wymagań systemu informacyjnego odpowiedzialność za produkt końcowy rozkłada się w równym stopniu na użytkownika i wykonawcę. Ma to bodaj najważniejszy wpływ na jakość produktu końcowego.Ta uwaga może być zakwalifikowana do słabo zarysowanej w naszej praktyce rynku informatycznego warstwy etycznej. Jej istota sprowadza się do tego, aby zamawiający produkt w swoich oczekiwaniach uwzględniał interes biznesowy wykonawcy. Wykonawca powinien dokładać starań, by jego najlepsza wiedza i dostępność najnowszych technologii, decydowała o kształcieproduktu korzystnym dla zamawiającego.

Wnioski

Jakość produktu (tutaj systemu informacyjnego) wynika z wielu uwarunkowań, a żadne z nich nie zasługuje na miano warunku ostatecznego. Jeżeli jednak decydować o najważniejszym, to wydaje się, że uwaga dotycząca etyki relacji zamawiającego i wykonawcy ma skutki najdalej idące i zarazem najtrudniej podlega regulacjom.

Czy w tym procesie doskonalenia systemów informacyjnych pomoże nam norma ISO? Bez wątpienia tak, jeżeli nadamy sens stwierdzeniu, że "w procesie audytu audytor wewnętrzny identyfikuje kryteria audytu w obszarze audytowanym". Może więc trzeba przemyśleć i zrozumieć jakość... I to było do udowodnienia!

Zbigniew Olejniczak jest dyrektorem Departamentu Informatyki w Ministerstwie Gospodarki, Pracy i Polityki Społecznej.