Firmy informatyczne, jeszcze niedawno dostarczając system, abstrahowały całkowicie od procesu biznesowego, który dany system wspiera. W szczególności robili tak "wielcy" rynku informatycznego, którzy po prostu tłumaczyli na polski standardowe umowy SLA z USA i nie negocjowali warunków z klientami. Powoli się to zmienia - dostawcy informatyki rozumieją, że warunki takiej umowy muszą uwzględniać specyfikę biznesu klienta. Jeżeli potrzebą odbiorcy jest stuprocentowe bezpieczeństwo - to system informatyczny ma je wspierać. Jeżeli szybkość reakcji jest priorytetem - to ponad wszystko odpowiedzialnością informatyków jest zadbać o szybkość reakcji. W podanym przykładzie ma być regulowana dostępność aplikacji w okresie sporządzania listy płac. W systemie zbierania danych z rozproszonych stacji meteorologicznych ważne jest przekazywanie pomiarów w określonym momencie tak, aby mogła być sporządzona prognoza. Natomiast w przypadku systemu skoringowego (szacowania ryzyka) dla firmy ubezpieczeniowej najważniejsza jest poprawność tego oszacowania. Każdorazowo umowę o odpowiedzialności trzeba przemyśleć i - co ważne - przetestować, najlepiej podczas okresu próbnego, ewentualnie na danych historycznych. Bez tego obie strony mogą być zaskoczone wynikami. Papier jest cierpliwy, pozwala zapisać wszystko, ale tam, gdzie w grę wchodzi odpowiedzialność wymierzana pieniędzmi, lepiej bazować na mierzalnych faktach. Warto przy tej okazji powtórzyć pewien truizm: dobrze skonstruowana umowa działa ku pożytkowi obu stron, "przyciśnięcie" jednej ze stron przez drugą w długim okresie owocuje negatywnymi konsekwencjami także dla "przyciskającego".

Monitoruj i egzekwuj

Zmorą polskiego życia publicznego są prawa i ustalenia, które nie są wypełniane treścią. Analogicznie w umowach o odpowiedzialności za jakość systemów informatycznych, oprócz zapisów, musi istnieć też część wykonawcza. Jeżeli dostawca systemu informatycznego zobowiązuje się do czegoś, to odbiorca powinien być pewien, że jest w stanie stwierdzić ponad wszelką wątpliwość, że warunki takiej umowy są dotrzymywane, a jeśli nie są - to gdzie i o ile nastąpiło ich naruszenie.

Przypuśćmy, że w umowie outsourcingowej systemu płacowego dostawca zobowiązał się, że dostępność systemu w godzinach 8.00-17.00 wyniesie 95%, zaś odbiorca przyrzekł, że nie będzie w jednym cyklu przetwarzać list płac obszerniejszych niż 300 osób. Obie strony muszą w tej sytuacji przewidzieć u siebie tzw. moc wykonawczą dla tej umowy. Najpierw więc dostawca zobowiąże użytkowników outsourcowanego systemu płacowego, by w każdej sytuacji, gdy nie mogą się do niego dostać, informowali o tym fakcie wskazaną osobę, np. za pomocą poczty elektronicznej. W konkretnym, ustalonym w umowie cyklu (np. raz na kwartał) osoba ta przeczyta pocztę od użytkowników systemu płacowego i obliczy na tej podstawie, jaka była rzeczywista dostępność, oraz poinformuje dostawcę (załączając materiał faktograficzny), jeżeli nie było to 95%.

Analogicznie, po stronie dostawcy, ktoś przeanalizuje logi serwerów i stwierdzi, czy rzeczywiście zadany klient przetwarzał listy płac liczące do 300 osób, czy może więcej. Jeżeli było ich więcej, niezwłocznie zaproponuje wyższą stawkę za obsługę firmy przez system płacowy.

Zarządzaj ryzykiem, zarządzaj odpowiedzialnością

Dostawca, który zobowiązuje się dostarczyć odbiorcy system informatyczny o konkretnych parametrach oraz ponieść odpowiedzialność, gdyby nie były one spełnione, bierze na siebie spore ryzyko. Ryzykiem tym musi świadomie zarządzać tak, by w każdej chwili mógł z czystym sumieniem powiedzieć, że nie uwikłał się w coś nieoczekiwanego, co może przynieść dramatyczne skutki dla jego firmy.

Pozostańmy przy przykładzie firmy outsourcingowej, która dostarcza klientom funkcjonalność polegającą na zdolności przetworzenia listy płac przez udostępniany system informatyczny. Zdolność świadczenia takiej usługi na odpowiednim poziomie dostępności jest uwarunkowana kilkoma czynnikami: stabilnością zasilania, dostępnością łączy szerokopasmowych, z których korzystają klienci, oraz liczbą błędów w aplikacji.

Jeżeli któryś z tych czynników zawiedzie (zasilanie zostanie wyłączone, sieć "padnie", a aplikacja będzie miała błędy), firma nie będzie w stanie świadczyć usługi na oczekiwanym poziomie i będzie musiała ponieść za to odpowiedzialność (np. zapłacić karę umowną). Każdym z tych typów ryzyka należy więc zarządzać, np. kupić bardzo wydajne systemy UPS, które przez wiele godzin będą w stanie utrzymywać zasilanie serwerów podczas awarii; wydzierżawić dodatkowe łącze, które pozwoli klientom na dostęp do aplikacji; wreszcie zapewnić gruntowne testy aplikacji tak, by nieoczekiwany błąd został wyłowiony, zanim trafi ona w ręce klientów. Każde z tych działań powinno być ujęte w tzw. planie zapobiegania ryzykom (risk mitigation plan) i rozważone na wysokim szczeblu.

Nie zapominajmy, że w gospodarce rynkowej ryzyko jest przedmiotem obrotu. Można je kupić i sprzedać. Tak powstały ubezpieczenia od odpowiedzialności cywilnej, znane nie tylko notariuszom i lekarzom, ale także każdemu posiadaczowi samochodu. W zamian za uzgodnione wynagrodzenie firma ubezpieczeniowa zobowiązuje się pokryć straty osoby ubezpieczonej (przy czym "osoba" oznacza również firmę) w przypadku, gdy ktoś zażąda od niej odszkodowania. Zamiast więc kupować generator podtrzymujący zasilanie serwerów podczas zaniku prądu, może bardziej opłaca się wykupić ubezpieczenie od awarii zasilania i w razie czego zapłacić karę za niedostępność aplikacji pieniędzmi firmy ubezpieczeniowej? Znalezienie właściwego sposobu zarządzania odpowiedzialnością wymaga łączenia wiedzy z informatyki, zarządzania i ubezpieczeń. Na razie wydaje się, że tego właśnie brakuje firmom outsourcingowym, gdzie władzę dzierżą inżynierowie "wyeksportowani" z macierzystego przedsiębiorstwa podczas reorganizacji.

Choć nie ma jeszcze "ubezpieczeń od odpowiedzialności informatycznej", to pojawienie się ich wydaje się przesądzone. Rozwój outsourcingu w ostatnich latach musi spowodować pojawienie się takiej oferty dla firm informatycznych.

Oręż odpowiedzialności

W najbliższych latach należy się spodziewać większego nasycenia procesów biznesowych przez informatykę, a - co za tym idzie - coraz większych wymagań jakościowych stawianych systemom i serwisom. Wymagania te pociągają gwarancję, zaś gwarancja to nic innego, jak gotowość do poniesienia odpowiedzialności w razie problemów. Odpowiedzialność więc jest tematem na czasie. Należy oczekiwać, że coraz więcej firm informatycznych będzie używać rozszerzonej odpowiedzialności jako oręża w walce konkurencyjnej.

I być może dożyjemy nawet sytuacji, w której dostawca systemu informatycznego będzie w sposób równie symboliczny jak konstruktor mostu demonstrował zaufanie do swojego dzieła.