Problem roku 2000 dotyczy podstawowych kwestii zarządzania firmą i nie jest, jak się często mylnie uważa, problemem informatycznym. Tym samym przedsięwzięcie zapewnienia odporności firmy na ten problem musi być podjęte przez kierownictwo firmy, na którego zlecenie powstawały i były wdrażane systemy informatyczne. Pojawia się więc bolesny problem odpowiedzialności.

Stan wiedzy społeczeństwa o "problemie roku 2000" jest coraz większy. Poświęcono jemu artykuły, które ukazały się na pierwszych stronach wszystkich polskich gazet. Również pierwsza wersja tego artykułu (który ukazał się w Computerworld w sierpniu ub.r.) została zapewne odebrana jako apel o podjęcie działań we wszystkich obszarach życia społecznego i gospodarczego.

Naturalne pytania

Problem roku 2000 oznacza, w ostatecznym rachunku, duże problemy dla zarządu firmy, którą dotknie. Prowadzenie niechcianego projektu, duże wydatki na testowanie, ewentualne zakupy nowych wersji systemu lub sprzętu są poważnymi obciążeniami dla każdej instytucji. Ponadto, mimo zrealizowania wszystkich zalecanych czynności, może dojść do załamania systemu na przełomie stuleci, gdyż jak powszechnie wiadomo, nie ma metody dającej stuprocentową gwarancję sukcesu. Wówczas mogą pojawić się nowe wydatki na odszkodowania czy pokrywanie strat. Niektóre z nich mogą nawet doprowadzić do bankructwa dotkniętej tym problemem firmy. Kto jest temu winien, kto ponosi odpowiedzialność za taką sytuację, kogo można nią obarczyć? Kto też rozwiąże problemy zwykłego użytkownika, któremu drogi sprzęt elektroniczny odmówi posłuszeństwa 1 stycznia 2000 roku? Czy dostawca wymieni go na produkt wolny od wad?

Do kogo ma się zwrócić elektrownia, stosująca elektroniczne urządzenia zabezpieczające, od których poprawnego działania zależy życie ludzkie? Kto ma zbadać takie urządzenia, gdy nie można ich nawet na chwilę odłączyć, a producent często już nie istnieje?

Zrzucić na końcowego użytkownika

Punkt widzenia użytkownika łatwo określić - pragnie on każdego dnia mieć wolny od wad towar (urządzenie, program, miernik, właściwie realizowane usługi). Nie widzi powodu, aby rozumieć problemy dostawcy, nie widzi jakiegokolwiek powodu, dla którego miałby za cokolwiek płacić.

Jednak problem roku 2000 to możliwość zadziałania bomby logicznej, która może spowodować destrukcję kierowanej przez niego firmy lub instytucji, może doprowadzić do utraty prywatnej własności. Mówiąc językiem handlowym, problem ten dotyczy świadomości istnienia wady ukrytej w towarze. Należy wyraźnie stwierdzić, że brak odporności na problem roku 2000 jest wadą ukrytą.

Niezależnie jak potężna jest organizacja tworząca produkt, nie jest możliwe, aby przedstawiła ona 100% gwarancję, że jest on wolny od wad. Nawet najbardziej złożone testowanie prowadzi tylko do wyszukania kolejnych błędów. Ta smutna prawda nie wszystkim jest znana. Wady mają wszystkie istniejące systemy i urządzenia na świecie. Aby jednak dopuścić produkt do eksploatacji, trzeba podjąć decyzję, bazując na oszacowanym ryzyku.

Jednak użytkownik bierze na siebie część odpowiedzialności. Mając świadomość możliwości wystąpienia ukrytych wad, sam musi przewidywać możliwość pojawienia się awarii. Jeśli to ryzyko jest wysokie, użytkownik musi podjąć decyzję o stosowaniu zapasowych rozwiązań, tam gdzie to jest możliwe, i takich, które polegają na użyciu kilku produktów pochodzących od różnych wytwórców.

W przypadku oprogramowania zachodzi szczególna sytuacja. Mamy do czynienia z dwoma rodzajami wad: pierwsza - to pomyłki i przeoczenia w oprogramowaniu, a także błędnie skonstruowany algorytm, druga - to efekty świadomie podjętych, błędnych decyzji polegających na zastosowaniu uproszczeń lub ominięciu wewnętrznych procedur kontrolnych. Do tej drugiej kategorii niewątpliwie zalicza się problem roku 2000.

Nie zawsze jednak ten problem jest wadą ukrytą. Jeśli użytkownik od początku zaakceptował fakt, że produkt posługuje się w widocznych miejscach dwucyfrową liczbą roku, wówczas nie jest to wada ukryta, lecz efekt krótkowzroczności użytkownika. Dlaczego przed 10 laty kierownictwo firmy godziło się na kodowanie liczby roku w postaci dwóch cyfr?

Czasem jednak problem roku 2000 jest ukryty wewnątrz urządzenia. Firma kupując urządzenie lub sterownik może nie wiedzieć, że zakupiony produkt zawiera algorytm nieodporny na problem roku 2000. Możliwa jest sytuacja, w której producent umieścił w urządzeniu nie udokumentowane oprogramowanie. Może ono być nieodporne na problem roku 2000 i w konsekwencji całe urządzenie staje się nieodporne.

Dochodzenie praw

Czy użytkownik może dochodzić swoich praw u dostawcy produktu obarczonego wadą Y2K? Zasadniczo nie. Ta najważniejsza teza wymaga uzasadnienia. W tym celu należy cofnąć się do początkowych lat powstawania systemów informatycznych. W Polsce, w czasach nie tak przecież odległych, w których powstawały systemy informatyczne na komputery typu ODRA lub RIAD (dla przypomnienia - ODRA 1300 była polską wersją komputera mainframe firmy ICL o symbolu 1900, natomiast RIAD był klonem serii mainframe IBM - komputerów serii 360 i 370), systemy były pisane i następnie przetwarzane w ośrodkach obliczeniowych, zlokalizowanych w specjalnie do tego celu powołanych przedsiębiorstwach. Większe zakłady budowały własne ośrodki obliczeniowe i zatrudniały kadrę specjalistów. Programy komputerowe były projektowane, programowane i odbierane przez informatyków. Proces ten był postrzegany przez zarządy przedsiębiorstw jako prawidłowy.

Można przyjąć, że następował proces odbioru systemu, nawet jeśli nie był on tak sformalizowany, jak obecnie. Później pojawił się rynek produktów gotowych, elektronika trafiła do urządzeń powszechnego użytku, nawet tak prozaicznych, jak kuchenki czy pralki automatyczne. Ponadto stała się oczywistym elementem składowym systemów nawigacji, bezpieczeństwa oraz klimatyzacyjnych. Bez niej nie jest możliwe działanie współczesnej telefonii. Tam, gdzie jest elektronika, jest również program komputerowy. Program ten był zaprojektowany i zaprogramowany, a następnie przekazany do eksploatacji. Można przyjąć, że w każdej z opisanych sytuacji, pozornie niewiele mających ze sobą wspólnego, użytkownik znajduje się w takim samym położeniu prawnym. W każdym przypadku mamy do czynienia z używanym od dłuższego czasu produktem, do którego nie były zgłaszane zastrzeżenia lub reklamacje. Prawa użytkownika zabezpiecza umowa gwarancyjna i prawa związane z rękojmią, pod warunkiem że nie przekroczono określonego terminu. Jeśli produkt został przekazany do eksploatacji np. przed 10 laty, nie ma podstaw do jakichkolwiek roszczeń.

Jeszcze gorzej jest w przypadku produktu typowego, kupowanego "z półki". Dotyczy to powielarnego oprogramowania, takiego jak systemy operacyjne, systemy biurowe, narzędzia do tworzenia grafiki.

Użytkownik, otwierając opakowanie, automatycznie wyraża zgodę na treść umowy licencyjnej, w której praktycznie zawsze zawarta jest klauzula, że oprogramowanie jest takie jakie jest. Z tą klauzulą nie można się nie zgodzić, co nie zmienia faktu, że producent jednoznacznie wskazuje na użytkownika, jako na tego, który ponosi odpowiedzialność.

Obraz bardzo czarny?

Użytkownik słusznie może czuć się oszukany, mimo że z formalnego punktu widzenia można przyjąć, iż sam jest sobie winien. Przecież zapłacił za produkt, a zatrudnieni przez lata informatycy byli jednymi z najlepiej opłacanych pracowników w przedsiębiorstwie. Obowiązuje także zasada rzetelnego kupca, dotycząca każdego szanującego się wytwórcy. Warto tu przyjrzeć się, jak reagują na ten problem wielcy producenci oprogramowania. Autorzy artykułu, pracując nad problemem Y2K w swoich instytucjach, zwrócili się pisemnie do wielu producentów i dostawców produktów informatycznych z pytaniem o odporność na problem roku 2000. Z analizy odpowiedzi wynika, że wszyscy prowadzą prace nad badaniem swoich produktów i już teraz oferują poprawki lub nowe wersje oprogramowania, pozbawione tej wady. Pomijając fakt, że nowe produkty mogą zawierać nowe, nieznane wady, trzeba przyjąć, iż tego rodzaju działalność jest wyjściem naprzeciw oczekiwaniom użytkowników. Pojawiło się też nowe pytanie: dlaczego użytkownik ma płacić za nową wersję?

Zarówno kierownictwo firmy, jak i zwykli użytkownicy muszą liczyć się z potencjalnymi stratami finansowymi, choć może dojść do jeszcze gorszych następstw, jeśli zawiedzie newralgiczny dla nich system informatyczny. W skrajnej sytuacji mogą zginąć ludzie. Mimo bardzo już krótkiego czasu, jaki pozostał do pojawienia się feralnych dat, w każdym przedsiębiorstwie powinien być powołany zespół, wyposażony w odpowiednie możliwości finansowe i decyzyjne, prowadzący projekt roku 2000.

Badanie zasobów nie jest jedyną czynnością zabezpieczającą przed katastrofą. Odpowiedzialność kierownictwa firmy implikuje przygotowanie również scenariusza zachowań na wypadek sytuacji awaryjnej. Do tego celu konieczne jest już dziś przygotowanie odpowiednich formuł prawnych, utworzenie zespołu kryzysowego i zapasowego rozwiązania lub nawet ubezpieczenie się od odpowiedzialności. Najgorszym rodzajem działania jest strategia typu "jakoś to będzie".

Zwykły użytkownik ma właściwie tylko dwie możliwości. Pierwsza, to uważne śledzenie kolportowanych głównie przez Internet informacji producenta, druga - samodzielne testowanie produktu. Przy założeniu dobrej woli renomowanych producentów można optymistycznie założyć, że użytkownik nie zostanie z wadliwym produktem i nie przerazi go już banalna perspektywa, iż po 31 grudnia jest 1 stycznia.

Zabezpieczenie informatyka

Niejednokrotnie zdarza się, że kierownictwo danej firmy postanawia "rozwiązać" problem, zlecając informatykowi dokonanie analizy i poprawienie tego, co jest złe. Dla uściślenia, mamy tu na myśli typowego informatyka zajmującego się pisaniem lub wdrażaniem systemów, a nie organizatora, członka kierownictwa. Tak postępuje albo postępować będzie w miarę zbliżania się feralnych dat coraz więcej zarządów firm. Pojawia się wówczas nowy problem - zagrożenie egzystencji informatyka. Z pozycji swojego stanowiska informatyk nie poradzi sobie z tym problemem...

Cóż więc może zrobić w takiej sytuacji informatyk? Odpowiedź jest dwojaka. Z punktu widzenia ponoszonej odpowiedzialności za interesy firmy informatyk nie może czuć się odpowiedzialny za problem roku 2000, gdyż nie został do tego celu zatrudniony. Powinien jedynie zakomunikować, że dołoży wszelkich starań, by rzetelnie wywiązać się z powierzonych zadań, a następnie przedstawić swój plan działań. Plan ten musi zatwierdzić kierownictwo firmy. Informatyk powinien od początku, co powinno znaleźć się w planie, wskazać czynności, które osobiście będzie wykonywał, oraz te, które będą realizowane przez inne osoby. Przykładowo, analiza problemu roku 2000, dotycząca systemu finansowo-księgowego, powinna zawierać, oprócz typowych czynności informatycznych, również konieczność otrzymania certyfikatów od dostawców oprogramowania lub opracowania procedur na wypadek zaistnienia awarii.

Informatyk musi założyć teczkę zawierającą kompletną dokumentację wykonanych działań, tak aby w przypadku zarzutów mógł dowieść, że dołożył należytej staranności. Na tym polega sens prowadzenia działalności związanej z problematyką roku 2000, bo nikt nie jest przecież w stanie udowodnić, że system jest wolny od wad.

Drugi punkt widzenia, bardziej uczciwy, to stanowcza odmowa wykonania takiego polecenia udzielona przez informatyka, którego głównym argumentem jest brak kompetencji. Oczywiście wywoła to burzę i nieprzyjemne rozmowy, ale ryzyko odmowy jest zdecydowanie mniejsze niż konsekwencje wynikające z wzięcia na siebie nadmiaru odpowiedzialności.

Podstawowym rozwiązaniem zawsze powinno być powołanie zespołu sterującego, w którym miejsce znajdzie także informatyk. W ten sposób będzie mógł wykonać swoje zadania, bez obawy przekroczenia własnych kompetencji.

Bogusław Fries jest specjalistą ds. bezpieczeństwa i audytu systemów informatycznych Giełdy Papierów Wartościowych

Janusz Zawiła-Niedźwiecki jest dyrektorem departamentu informatyki w GPW