Uczmy się na błędach

Afery i katastrofy są skutkami komputeryzacji, czyli użycia techniki informacyjnej, do wykonywania starych procedur w ramach nie zmienionej organizacji.

W ciągu ostatnich lat mieliśmy kilka katastrof, których skutków, przyczyn oraz mechanizmów nikt nie przeanalizował. A jeśli nawet tak, nie wynikły z tego żadne korzyści. Nawet niepowodzenia nie muszą być wyłącznie stratami. Takie katastrofy, np. Poltax, Pewex i urząd celny, powinno się było poddać wnikliwej analizie i ocenie, na podstawie których sformułowano by wnioski i zalecenia dla twórców podobnych zastosowań. Powinny powstać opisy przypadków, na których studenci i uczestnicy kursów uczyliby się dobrych praktyk. Błędów popełnionych w toku szkolenia nie popełnialiby później w praktyce. Przez fałszywy wstyd nakazujący milczenie na temat niepowodzeń, środki wydane na nieudane projekty straciliśmy bezpowrotnie. Rząd powinien był zlecić wykonanie analiz, gdyż ponosi odpowiedzialność za wydatkowanie pieniędzy publicznych. Na ich podstawie można było spisać listę złych praktyk przy tworzeniu systemów.

Ostatnio głośna jest sprawa wprowadzania systemu ZORBA w PKO BP. Trudno jest wypowiadać się na temat jakości (w tym zgodności z potrzebami) oprogramowania. Można przyjąć, że jest ono poprawne, przynajmniej na tyle, na ile mogli to zrobić jego twórcy. Cały proces zmian jednak przeprowadzono niezgodnie z regułami sztuki. Jest to skutkiem błędów popełnionych zarówno przez użytkowników, jak i informatyków.

Pierwsi zawinili, nie szukając skutecznego rozwiązania realnych problemów. Błędnie i bezpodstawnie założyli, że problemy banku rozwiąże informatyka i informatycy. Na domiar złego zgodzili się (sami zasugerowali?) na testowanie systemu "na ludziach". Drudzy powinni wiedzieć, że nie można przechodzić do eksploatacji kompleksowego systemu (nawet samego oprogramowania) z marszu. Należy przeprowadzić operację testowania w warunkach rzeczywistych na jeden z czterech znanych sposobów.

Na podstawie niekompletnych, sprzecznych, błędnych... w sumie niepoprawnych specyfikacji może powstać tylko błędne oprogramowanie, które naraża użytkownika na straty. Poniesie je, gdy nastąpi awaria, a skutki będą tym dotkliwsze, im bardziej zaawansowana jest aplikacja.

(J.Martin: 1985; System Design from Provably Correct Constructs).

Wnioski

Nieudane projekty musi się poddawać merytorycznej analizie. Jej efektem nie mogą być kary dyscyplinarne ani tym bardziej nowe bezsensownie szczegółowe przepisy, które nie wymuszą wzrostu kompetencji, a będą krępować kreatywność i elastyczność. Lepiej zmieniać system kształcenia i promować potrzebne u nas publikacje na tematy systemów informacyjnych, ich analizy i projektowania, prace badawcze w tym obszarze i ludzi z doświadczeniami, umiejętnościami, wiedzą i pomysłami.

Dopóki nie zbywa nam dobrych doświadczeń, dopóty proponujemy pamiętać o wzorcu przedstawionym na rysunku 2 oraz uwzględniać ogólne zalecenia dla użytkowników zestawione w tabeli SUKCES (Strategicznie Uzasadnione, Kompleksowe, Celowe i Efektywne Systemy).

Źródło: opracowanie własne na podstawie: Peters, T.J., Waterman, R.H. (1984). In Search of Excellence. Lessons from America's Best Run Companies. New York: Warner Books. Inc.