Najważniejszym chyba powodem, dla którego "tradycyjne" systemy jakości zawodzą w przypadku procesów informatycznych, jest poszukiwanie przyczyn źródłowych defektu (root cause analysis). O ile dość łatwo stwierdzić, co mogło wpłynąć na fakt, że opona, która powinna być okrągła, ma odchylenie od idealnego koła, o tyle trudno analogiczną analizę przeprowadzić w przypadku informatyki. Na przykład okresowy spadek wydajności aplikacji poniżej oczekiwanych poziomów wydajności jest defektem zawinionym przez dostawcę aplikacji czy też np. jest spowodowany okresową defragmentacją dysku twardego lub chwilowym przeciążeniem procesora podczas kompresji danych? Znalezienie przyczyny źródłowej wymaga analiz statystycznych wykonanych na różnych danych źródłowych, aby np. dostrzec korelację między konkretnym parametrem (np. stosowanym językiem programowania) a jakością rozwiązania (mierzoną liczbą defektów). Aby analiza była wiarygodna, niezbędna jest dość duża ilość tych danych. Niestety, zarówno definicje tych danych, jak i systemy ich zbierania firma informatyczna musi zbudować od podstaw. Nie ma też na rynku opracowań porównawczych, np. mówiących, że dla programów w C++ liczba błędów programistycznych wynosi 120 na tysiąc linii kodu, zaś w przypadku SQL - jedynie 72 (te wielkości są oczywiście czysto hipotetyczne).

Nie mniej istotny jest brak standardowych norm cząstkowych, które informatyk projektujący system miałby do dyspozycji i na których mógłby polegać. Kiedy inżynier budowlany przystępuje do projektowania drogi, ma do wyboru kilkadziesiąt gotowych i sprawdzonych standardowych rozwiązań. Lecz gdyby nie zdecydował się na żadne z nich, może wziąć podłoże o znanej wytrzymałości (opisanej przez Polską Normę o określonym numerze), uzupełnić je warstwą wzmacniającą o dobrze znanych parametrach, a następnie wylać asfalt przyrządzony wg bardzo precyzyjnej receptury i mający znaną odporność na ścieranie. Efekt końcowy jest w dużym stopniu wypadkową tych wszystkich opisanych, uznanych i sprawdzonych norm, dzięki czemu droga zaprojektowana przez inżyniera budowlanego będzie miała pożądane cechy dla użytkownika końcowego (np. wytrzyma trzy lata jeżdżenia ciężarówkami o nacisku dwóch ton na oś). Taki inżynier może dać gwarancję odbiorcy końcowemu (np. gminie), bo cały czas porusza się w znanym i opisanym standardami środowisku.

Cóż może zaproponować inżynier informatyk? Musi dostarczyć produkt, nie wiedząc często, w jakim konkretnym środowisku sprzętowym będzie pracował. Może przetestować go na systemie operacyjnym, na którym produkt ten będzie działał, ale - szczególnie w przypadku produktów na rynku konsumenckim - nie jest w stanie sprawdzić go z wszystkimi wersjami systemów (a już na pewno nie na systemach, które dopiero się pojawią). Nie otrzymuje gwarancji na komponenty programistyczne, których używa (np. standardowe obiekty graficzne). Informatyk, który w tej sytuacji udzielałby odbiorcy końcowemu gwarancji obejmujących całe rozwiązanie, byłby nie tylko niekompetentny, ale po prostu nieuczciwy.

Za jakość trzeba płacić

Warto w tym momencie powiedzieć o jeszcze jednej kwestii: świadomości klientów. Przez wiele lat byli oni przyzwyczajani, że kiepska jakość jest poniekąd wpisana w naturę produktów informatycznych, zawieszanie się komputera to nic wielkiego, a błędy aplikacji zostaną szybko poprawione przez pakiety serwisowe. O ile jednak wydaje się, że odbiorcy systemów informatycznych A.D. 2003 zaczęli wymagać już ich podwyższonej jakości i niezawodności, a firmy informatyczne starają się zmierzać w kierunku zapewnienia tej jakości, o tyle brakuje na razie jednego istotnego elementu tej układanki. Brakuje świadomości klientów, że za podwyższone wymagania jakościowe trzeba płacić.

Za jakością produktów informatycznych stoją przecież konkretne koszty, które firma informatyczna musi ponieść. Opracowanie i wdrożenie pewnych standardów, stosowanie automatycznych narzędzi testujących, utrzymanie wewnętrznego działu jakości, znalezienie na rynku najlepszych ludzi oraz przeszkolenie ich... wszystko to oznacza konkretne wydatki. Czy odbiorcy są skłonni za to zapłacić? Czy rzeczywiście korzyści to uzasadniają?

Aby odpowiedzieć na takie pytania, klient firmy informatycznej musi sam najpierw znaleźć odpowiedzi na inne pytanie: z jakimi kosztami w jego biznesie wiąże się zawodność systemów informatycznych? Jeżeli hipermarket ma godzinę przestoju spowodowaną awarią oprogramowania w kasach, bezpośrednie koszty może policzyć stosunkowo łatwo, jako średni utarg w danej godzinie przemnożony przez średnią marżę.

Do tego trzeba dodać pensje płacone kasjerom "na postojowym" i bezpośrednie koszty usuwania awarii. Nieco trudniej wymierzyć utraconych klientów, skazę na wizerunku oraz utratę wiarygodności wobec dostawców. W bardziej złożonych gałęziach gospodarki (np. w logistyce albo usługach) szacowanie strat to jeszcze bardziej złożone zadanie.