Piękny zwyczaj nakazuje, aby podczas prób obciążeniowych mostu jego projektant stanął pod nim. W ten symboliczny sposób pokazuje, że jest pewny swego dzieła w takim stopniu, iż może gwarantować głową jego wytrzymałość. Trudno powiedzieć, ile prawdy w tej legendzie, ale ilustruje ona bardzo ważną rzecz: ogromną odpowiedzialność, jaką ponoszą konstruktorzy inżynierii lądowej. Czy od informatyków będzie można kiedykolwiek wymagać takiej odpowiedzialności?

Wirus nieodpowiedzialności

Gdy epidemia wirusa "MyDoom", która jak tsunami na przełomie lutego i stycznia br. przetoczyła się przez Internet, wszyscy zadawali sobie pytanie: jak to się mogło stać? Miliony zarażonych komputerów, setki milionów wiadomości e-mailowych z wirusem w środku, setki tysięcy godzin roboczych poświęcone na usuwanie skutków, koszty idące w miliony dolarów... Warto zadać jeszcze inne pytania: kto za to odpowiada, w jakim stopniu i dlaczego właśnie ta, a nie inna osoba?

Do tego należy dodać historie, które wstrząsały światem informatyki w ostatnich czasach. Problem roku 2000, wywołany przez nieodpowiedzialność programistyczną, spowodował koszty idące w miliardy dolarów w skali całego globu. System wyborczy zawiódł w kluczowy wieczór, a mimo to wykonawca otrzymał pieniądze. W wyniku błędu w oprogramowaniu rakieta Ariane w 290 sekundzie lotu wybuchła, niszcząc dwa satelity - łączne straty wyniosły kilkaset milionów dolarów.

Niewątpliwie informatyka potrzebuje więcej odpowiedzialności.

Wiara i wina

Kodeks cywilny w kwestii odpowiedzialności za szkodę wyrządzoną drugiej osobie jest bardzo zwięzły i, wydawałoby się, jednoznaczny: "Kto z winy swej wyrządził drugiemu szkodę, zobowiązany jest do jej naprawienia" (art. 415 kc). Zauważmy, że wyrządzający szkodę poniósł za to odpowiedzialność, konieczne jest dowiedzenie jego winy. Można wyrządzić szkodę bez winy? Ależ można - jeżeli system informatyczny nie zadziała w kluczowym momencie z powodu awarii zasilania, nie ma w tym winy dostawcy systemu informatycznego. Czy odpowiedzialność ponosi zakład energetyczny? Tak, o ile z jego winy nastąpiła przerwa w zasilaniu. Jeżeli zaś przyczyną przerwy była np. wichura albo awaria w elektrowni, zakład energetyczny będzie argumentował, że to nie on powinien naprawiać szkody.

Kwestia winy jest więc kluczowa dla odpowiedzialności, a dowiedzenie winy jest bardzo trudne. Należy więc zalecić zarówno informatykom, jak i odbiorcom informatyki precyzowanie zakresu odpowiedzialności w umowie wiążącej strony. Pamiętajmy, że w polskim prawie cywilnym istnieje swoboda zawierania umów. Zdecydowana większość umów wiążących firmę informatyczną z klientem to umowy licencyjne na produkty masowe. Wszyscy wiemy, jak wyglądają takie umowy - z reguły odpowiedzialność za szkody klienta jest tam wyłączona, a w najlepszym razie ograniczona do wysokości kwoty zapłaconej przez odbiorcę za licencję.

Takie rozwiązanie jest dobre dla użytkowników domowych i drobnych przedsiębiorców, ale nie satysfakcjonuje odbiorcy korporacyjnego. Ten wymaga, aby jego kluczowe systemy, określane mianem mission critical, miały zagwarantowaną jakość, a odpowiedzialność wykonawcy za ich błędne działanie nie była wyłączona. W dyskusji o odpowiedzialności twórców informatyki zapiszmy spostrzeżenie pierwsze: kluczowe systemy dla użytkownika biznesowego wymagają ponoszenia odpowiedzialności przez ich wykonawcę i powinna to regulować umowa.

Opisz i mierz

"Nie władamy tym, czego nie potrafimy opisać i zrozumieć" - powiedział Kartezjusz. Parafraza tego stwierdzenia w przypadku informatyki mogłaby brzmieć: "Nie odpowiadamy za to, czego nie potrafimy opisać i zmierzyć". Opisanie i pomiar wielkości to pierwszy krok do ustalenia odpowiedzialności za ewentualne szkody spowodowane błędnym działaniem systemu informatycznego.

Pierwszy i - dodajmy - jednocześnie najtrudniejszy. Jeżeli zakładamy, że w umowie outsourcingowej dostawca ma zapewnić klientowi dostępność systemu na poziomie 99,9%, to jak zmierzyć owe 99,9%? Wbrew pozorom sprawa ta nie jest oczywista. Przypuśćmy, że chodzi o dostępność aplikacji odpowiedzialnej za listę płac. Naliczenie pensji następuje pod koniec miesiąca, a ewentualnych narzutów na pensję (np. ZUS) - na początku następnego. Poza tym okresem aplikacja może być dostępna sporadycznie albo wcale. 99,9% nie powinno się więc odnosić do całej doby, a jedynie tego czasu, w którym aplikacja musi być wykorzystywana (czyli np. w godzinach pracy, w ostatnim tygodniu miesiąca).

Aby dodatkowo skomplikować ten przypadek, przyjmijmy, że aplikacja potrafi naliczać listy płac dla już zarejestrowanych pracowników, ale nie pozwala rejestrować nowych. Czy można to uznać za błąd? Czy taki błąd liczy się do 99,9% dostępności, czy nie? Życie jest znacznie bogatsze od najwymyślniejszych nawet modeli - i takie pytania firmy informatyczne i ich klienci stawiają sobie co dzień.

Najgorsza rzecz, jaką można zrobić, to zawrzeć tak precyzyjny parametr liczbowy jak 99,9% i nie zdefiniować dokładnie, co on znaczy. Wtedy zamiast mieć odpowiedzialność wykonawcy, mamy niekończące się dyskusje na temat poszczególnych przypadków.

Podobnie należy definiować liczbę błędów w dostarczonym rozwiązaniu. Jeżeli firmie informatycznej chce ktoś zlecić system, a jednocześnie obwarować płatność liczbą błędów w tym systemie, powinien wyraźnie określić, co jest defektem aplikacji. Łatwo przy tym popaść w skrajność i powiedzieć, że każdy błąd ma jednakowe znaczenie; w praktyce błędy w systemach informatycznych dzieli się na przynajmniej kilka klas pod względem uciążliwości (severity) i kara (lub brak nagród) grozi wykonawcy tylko za te najcięższe błędy.

Wniosek nasuwa się sam: tam, gdzie klient chce, by wykonawca lub usługodawca aplikacji ponosił odpowiedzialność za jej parametry jakościowe, musi bardzo szczegółowo opisać, w jaki sposób te parametry będą mierzone.

Bez tego każda umowa regulująca odpowiedzialność dostawcy systemu informatycznego będzie zaproszeniem do negocjacji, a nie regulacją odpowiedzialności.

Przywiąż do procesu

W publikacjach na temat umów SLA (Service Level Agreement) dla outsourcingu informatyki pełno jest "gotowców", w których można znaleźć definicję parametrów istotnych dla klientów. Z reguły są tam: dostępność systemu, poprawność jego działania, czas na usunięcie błędu, dostępność pomocy (help desk), czas wykonania zmiany. Wszystkie te parametry należy traktować jako menu, dostępne a` la carte, nie zaś obowiązkową część każdej umowy SLA.

Parametry, których dana firma potrzebuje, zależą ściśle od rodzaju jej działalności. Firma, która funkcjonuje od 8.00 do 16.00, nie ma potrzeby dostępności aplikacji 24/7. Przedsiębiorstwo handlujące zbożem musi dokładnie zabezpieczyć się przed błędami w aplikacji w okresie żniw, ale w zimie może dać odetchnąć swojemu dostawcy (oraz swojej kieszeni, gdyż gotowość 24/7 ma swoją cenę i to niemałą). Z kolei instytucja finansowa, która handluje kontraktami terminowymi na rynku instrumentów pochodnych, będzie prawdopodobnie chciała zapewnić sobie wysokie bezpieczeństwo i szybkość działania aplikacji, podczas gdy sprawność działania działu help desk będzie miała dla niej trzecio-planowe znaczenie.