Wiedza o skuteczności i efektywności realizacji projektów informatycznych znalazła się w niebezpiecznym stadium. Ten szczególny etap poznania natury zjawiska można opisać jako zrozumienie kolejności i 'mechaniki' zdarzeń, podczas gdy właściwe przyczyny sukcesu i porażki projektów informatycznych mają dużo poważniejszą i głębszą naturę.

Przyjmuje się obecnie, że projekt, który posiada zdefiniowane zasoby ludzkie, finansowe, określony harmonogram itp. czynniki, musi przynieść sukces, jeżeli tylko będzie pieczołowicie realizowało się ustalone reguły organizacyjne stosownie do obranego i usankcjonowanego schematu, czyli metodyki. Praktycy tę upraszczającą konkluzję - poprzez ogrom swoich doświadczeń - odrzucą, ale przecież nadal jesteśmy bliżej stanu, w którym 'wiedziemy', nie przybliżając się do 'rozumienia'.

Co właściwie należy zrozumieć? Odpowiedź jest zgoła nieoczekiwana. Trzeba zrozumieć, że projekt informatyczny to tylko część pewnego przedsięwzięcia, które zawsze ma jednoznaczną konotację społeczną, a produkt ostateczny nie istnieje, nie ma jakiegokolwiek sensu, jeżeli nie ma kontekstu społecznego. Tak więc "na nowo przemyśleć i zrozumieć jakość" to nic innego, jak pójść za myślą Armanda Feigenbauna, że jakość produktu to "zbiorcza charakterystyka wyrobu lub usługi z uwzględnieniem marketingu, projektowania, wykonania, która powoduje, że dany produkt lub usługa spełniają oczekiwania użytkownika".

Od klasyków jakości do standardu ISO

W. Edwards Deming (jednak pamiętajmy, że wszystko zaczęło się od Waltera A. Shewharta) w swoich 14 zasadach trafnie ujął istotę tego, co można nazwać podejściem jakościowym w organizacji. Wśród wskazówek tego prekursora na pierwszy plan wysuwa się potrzeba innego podejścia do procesu wytwarzania - zostało to wręcz określone jako nowa filozofia i nowe myślenie. Dochodzi do tego słuszne podkreślenie znaczenia organizacji pracy, roli menedżera i umiejętności wykonawców. Takie podejście do procesu wytwarzania i z takimi akcentami mieści się jednak w zwyczajnych zasadach nauki organizacji i zarządzania. Jeżeli więc Demings zrobił coś istotnego, to zauważył potrzebę akcentowania problemu jakości wyrobu. On sam nie wymyślił więc "kamienia filozoficznego jakości", chociaż pierwszy krok ku temu uczynił (np. kwestia niestosowania wyłącznie kryterium cenowego dla oceny wyrobu i jego jakości - wydaje się, że to zalecenie sformułowane w połowie ubiegłego wieku, niestety dzisiaj jest mocno kwestionowane poprzez praktykę stosowaną w zamówieniach publicznych. Mylił się więc nasz klasyk, czy my sami wróciliśmy do klasycznego błędu?).

Jeżeli Deminga uznać za pierwszego filozofa jakości, który przy tym dobrze rozumiał reguły sprawnej organizacji, a przede wszystkim dostrzegł problem jakości, to Joseph Juran kwalifikuje się jako znakomity przedstawiciel marketingu, który z potrzeby utylitarności produktu uczynił paradygmat produkcji i wytwarzania. Juran dość przewrotnie wyraził pewną myśl, którą świetnie można przenieść w realia technologii IT i ciągłych z nią problemów - "Nasi przodkowie nigdy nie mieli problemów z komputerami i systemami informatycznymi. Oni nie mieli systemów informatycznych i komputerów".

Jeżeli dokładnie przeanalizować zasady planowania jakości określone przez Jurana, to wybija się jedna myśl - określ dokładnie, kto jest twoim klientem i czego potrzebuje, a następnie zrób wszystko, aby wytworzyć pożądane dobro konsumpcyjne. Ta zasada, jakkolwiek słuszna, nie uwzględnia jednej okoliczności: produkt doskonały (jeżeli w ogóle istnieje) zawsze ma pewną dynamikę. Wymagania określone w br., ze względu na zjawiska obiektywne (rozwój technologii) i subiektywne (np. moda), wpływają istotnie na to, co jest oczekiwane, a więc powinno być wytworzone.

Philip B. Crosby, określając 14 kroków doskonalenia jakości, zasłużył bardziej na wdzięczność współczesnych entuzjastów ISO aniżeli Deming. Od jego 14 etapów doskonalenia jakości do naszych norm ISO pozostaje przysłowiowy "żabi skok".

Przeglądając dorobek klasyków systemów jakości, nie sposób nie zauważyć, że poczynili oni bardzo ważne obserwacje dotyczące procesów wytwórczych i umiejętnie je wykorzystali. Ich sława wynika nie tyle z ich pracy teoretycznej, co właśnie z praktycznych osiągnięć. Zachowując wszakże należny szacunek dla przeszłości, warto poczynić kilka nowych spostrzeżeń

które mają swoje uzasadnienie w dyskusji nad jakością. Wspomniane spostrzeżenia zostały ujęte w 7 uwagach, z których każda wskazuje na inny aspekt oceny produktu czy usługi.

Nowe spojrzenie na jakość wyrobu (systemu informacyjnego w szczególności).

1. Pojęcie jakości produktu (usługi) jest zawsze (i powinno być) związane z konkretnym produktem (usługą). Tak jak nie ma produktu w ogóle (abstraktu), tak nie ma pojęcia jakości w ogóle. Przykładem szczególnym produktu i przyjętym w dalszych rozważaniach jest system informacyjny.

2. System informacyjny stanowi cel ostateczny i naczelną zasadę przedsięwzięć wykorzystujących technologie informatyczne. Zakup komputera, programu informatycznego albo ich wytworzenie ma sens i znaczenie jedynie wtedy gdy służy usprawnieniu procesu wymiany informacji pomiędzy użytkownikami.

Niewłaściwe zrozumienie (wspomnianego już nieco wcześniej) kontekstu społecznego produktów wykorzystujących technologie informatyczne stanowi jedną z poważniejszych barier poprawy ich jakości. W praktyce budowy systemów niestety przyjęło się przekonanie, że celem każdego projektu jest wytworzenie systemu informatycznego. Innymi słowy - chodzi w takim razie o produkt inżynierski, który poprzez sprawne zastosowanie narzędzi i infrastruktury informatycznej zapewnia płynność wykonania założonych procedur obsługi. Ważne jest zrozumienie, że nie chodzi o obsługę procedury, a o odebranie informacji od użytkownika A w celu jej przetworzenia i przekazania do użytkownika B. Dla zrozumienia, dlaczego ten postulat zmiany w ocenie celu stosowania inżynierii informatycznej ma zasadnicze znaczenie, wystarczy obserwować pracę użytkowników w rozległych systemach informacyjnych.

Zauważmy, jak "miękko" w języku potocznym przyjęło się stwierdzenie, że "komputer nie znalazł miejsca", "komputer drukuje taką decyzję", a nawet, że "komputer się pomylił". Naturalny proces komunikacji społecznej został więc zepchnięty na plan dalszy; to nie kasjerka umie (nie umie) wyszukać połączenie komunikacyjne, to nie urzędnik wydał dobrą (złą) decyzję administracyjną. Skutek takiego odwrócenia stanu rzeczy, że komputer wszystko umie zrobić, jest tylko jeden: użytkownik (s)traci(ł) zainteresowanie efektem (skutkiem) komunikacji, czyli tym, co i komu oferuje z wykorzystaniem komputera, jakiej jakości produkt informatyczny użytkuje. Inżynier, testując sprawność i niezawodność systemu, pozostaje w przekonaniu, że jakość jego wyrobu ogranicza się do stabilności, przepustowości, zgodności z regułami prawa itd.

3. Naturą procesów (procedur) komunikacyjnych jest ich "poprzeczny" przebieg. Procesy komunikacyjne zapoczątkowane w jednym miejscu, kończą się w miejscu docelowym, przecinając wielokrotnie struktury administracyjne, ramy instytucji czy jakiekolwiek inne sztuczne ograniczenia. W nauce organizacji proces (w pewnym uproszczeniu) ujmuje się właśnie jako taki "poprzeczny" przebieg, w którym chodzi o to, aby punkt "A" skutecznie i efektywnie połączyć z punktem "B", by je skomunikować.

System informatyczny (zdaniem autora) wytwarzany jest w opozycji do natury procesu komunikowania się, jako układ zamkniętych i zakończonych czynności, najlepiej ujętych w układzie funkcjonalnym. Naturalną właściwością systemu informatycznego jest oprogramowanie kolejnych czynności, z których każda ma swój początek i koniec (zarówno na początku, jak i na końcu znajdują się odpowiednie informacje wytworzone/przetworzone). Mamy więc poważną (być może rozwiązywalną) sprzeczność prawdziwej natury procesu komunikacji i jego inżynierskiej implementacji.