Tworzenie dużego systemu informatycznego zawsze niesie ze sobą ryzyko porażki. Nigdy nie popłaca strusia metoda, gdy kierownictwo realizowanego projektu udaje wbrew faktom, że wszystko idzie dobrze. Klęska wielkiego systemu Confirm może być tutaj pouczającym przykładem.

Systemy rezerwacji zawsze były wdzięcznym obiektem do wprowadzania systemów informatycznych. Już od dawna systemy komputerowe usprawniają pracę agencji lotniczych czy sieci hoteli przy rezerwacji biletów i miejsc. W roku 1988 Hilton Hotels, Marriot Hotels i Budget Rent-A-Car zawiązały konsorcjum Intrico, którego celem było stworzenie wielkiego, scentralizowanego systemu rezerwacji, jakiego nie miała konkurencja. Na wykonawcę wybrano oddział American Airlines - AMR Information Services, czyli w skrócie AMRIS.

Przed systemem o wdzięcznej nazwie Confirm postawiono dość ambitne zadania. Poza scentralizowanym dokonywaniem rezerwacji, musiał on łączyć się z istniejącymi programami (poprzez odpowiednie interfejsy), a także łatwo dać się skomercjalizować, by można go było sprzedawać innym. AMRIS był sprawdzonym partnerem, znanym z bardzo udanego systemu rezerwacji biletów lotniczych Sabre. Niestety, jak się później okazało nawet sukces jakiegoś systemu informatycznego wcale nie gwarantuje powodzenia przy budowie podobnego, ale trochę większego.

Wartość projektu opiewała w tej fazie na 55 mln USD. W czasie 7 miesięcy miał powstać kompletny projekt, a gotowy system powinien był ujrzeć światło dzienne po 45 miesiącach (w 1992 r.). Wkrótce okazało się, że pierwszą fazę realizacji przygotowano niezbyt starannie. Projekt powstał na zbyt ogólnym poziomie abstrakcji. Już rok później klienci AMRIS-a wnieśli pierwsze poważne zastrzeżenia, ale kierownictwo firmy zapewniło, że wszystko rozwija się zgodnie z planem. Tuszując sprawę zwiększeniem dawki optymizmu AMRIS podniósł wysokość planowanych kosztów do 72 mln USD. Niestety optymizm był nieuzasadniony. Nieprecyzyjnie oszacowano bowiem nawet koszt funkcjonowania systemu (rozumiany jako średni wydatek na jedną rezerwację). Wówczas jednak nic o tym nie wiedziano w instytucjach zleceniodawców i w projekt inwestowane były dalsze fundusze.

W roku 1990 ujawniają się pierwsze poważne opóźnienia w realizacji przedsięwzięcia. Między innymi nie dotrzymano terminów wykonania prototypów interfejsu użytkownika, a odbiorcom odmówiono przestawienia rezultatów dotychczasowej pracy w momencie, gdy triumfalnie ogłoszono skończenie pierwszej fazy implementacji (co było niestety zwykłym kłamstwem). Jeszcze w październiku 1990 r. AMRIS mówił o rocznym opóźnieniu, ale zarazem zapewniał o skończeniu pracy zgodnie z ustalonym wcześniej terminem. Na początku 1991 r. przygotowano nowy harmonogram pracy (data ukończenia w 1993 r.), który powstał właściwie bez merytorycznego uzasadnienia. Pracownikom kazano tak przestawić terminarze projektów cząstkowych, by wszystko pasowało, choć terminy były całkiem nierealistyczne. Opornych usunięto z pracy. Cena projektu wzrosła tymczasem do 92 mln USD.

Wreszcie na przełomie lat 91/92 rezygnację ze swojego stanowiska ogłosił prezes AMRIS, a wraz z nim zwolniono większość zarządu. Okazało się wtedy, że kierownictwo tej firmy ukryło wyniki kontroli, przeprowadzonej wcześniej przez firmę konsultingową, w której jasno wykazano zły obrót spraw. Nowy kierownik wystosował nieco dramatyczny w tonie list: "(...) Rzeczy nie szły nam, tak jak to zaplanowaliśmy. Ci, którym powierzono kierowanie projektem Confirm, okazali się być niewłaściwymi ludźmi. W dodatku bagatelizowali oni wiele poważnych technicznych problemów, czasem wręcz je przemilczając (...)". Konsorcjum jeszcze raz zawierzyło zapewnieniom o realności wykonania projektu w ciągu maksimum dwu lat. Ostateczna klęska nastąpiła w momencie, gdy pojawiła się pierwsza wersja beta głównego programu. Niemożliwe okazało się połączenie centralnego systemu rezerwacji (odpowiedzialnego za dokonywanie transakcji) z modułem odpowiedzialnym za podejmowanie decyzji. To był już ostateczny koniec projektu.

AMRIS wystąpił na drogę sądową przeciwko konsorcjum, oskarżając je o zerwanie kontraktu. Intrico nie pozostało dłużne i skutkiem umowy pozasądowej AMRIS musiał zapłacić 160 mln USD odszkodowania (wobec 125 mln USD kosztów poniesionych w ciągu 4 lat przez konsorcjum na realizację).

Przyczyny klęski

Budowa każdego systemu informatycznego, podobnie jak i każdej złożonej konstrukcji, ma w sobie wpisane ryzyko poniesienia klęski. To co jest istotne, to umiejętność wyciągnięcia wniosków z tej sytuacji. Ameryka leży daleko, a mądry człowiek powinien uczyć się na błędach innych. Tak naprawdę to do końca nie można prześledzić wszystkich przyczyn niepowodzenia projektu Confirm. Wiadomo, że zgubiono tutaj dwa elementy konieczne do powodzenia całego przedsięwzięcia - zaufanie i odpowiedzialność. Bluffować można niestety tylko na krótką metę.

Pracownik firmy jest odpowiedzialny przed jej kierownictwem. Jego uczciwość sprowadza się do rzetelnego informowania kierownictwa o wszystkich zauważonych problemach. Z kolei zarząd w wypadku wystąpienia błędów i przeszkód mogących doprowadzić do przekroczenia budżetu lub niedotrzymania terminu umowy, powinien powiadomić o tym klienta, czekającego na system.

W opisywanej historii niektórzy pracownicy AMRIS-a starali się być lojalni i uczciwi. Zapłacili za to utratą pracy. Kierownictwo było nieuczciwe i nieodpowiedzialne. Bało się przyznać, że nie wszystko idzie po jego myśli. Nie potrafiło spojrzeć prawdzie w oczy. W efekcie najdotkliwsze konsekwencje poniósł sam AMRIS.

Wina nie leżała jednak tylko po stronie AMRIS-a. Odbiorcy systemu zaniedbali obowiązku ciągłego uczestnictwa w postępujących pracach. Mające miejsce jedynie comiesiąc spotkania projektowe zdemoralizowały wykonawcę, który nie czuł nad sobą żadnej kontroli. Przy realizacji systemu o tej skali nie można czekać z założonymi rękami "aż oni (wykonawcy) to nam zrobią", bo wiąże się z tym zbyt wielkie ryzyko.

Recepta na sukces

Takowej niestety nie ma. Istnieją tylko pewne zalecenia, o których warto pamiętać. Szacując termin ukończenia prac i wymagany budżet zawsze należy patrzeć realistycznie bez specjalnego optymizmu. Nigdy nie wkraczać w kolejną fazę realizacji przed zakończeniem poprzedniej (a przede wszystkim usunięciem zauważonych błędów, by ich dalej nie propagować). Kierownictwo zawsze powinno rozmawiać z klientami dobrze znając wcześniej faktyczny stan zaawansowania robót. Uniknie się wówczas udzielania uspokajających wyjaśnień nie popartych faktami. Pracownicy powinni zawsze mówić o zauważonych problemach. Klienci natomiast powinni systematycznie sprawdzać bieżący stan zaawansowania realizacji projektu, utrzymując ścisłe kontakty z wykonawcą. Warto pamiętać tutaj o sprawdzonej zasadzie ograniczonego zaufania. Zawsze trzeba dołożyć wszelkich starań, by precyzyjnie i odpowiednio wcześnie (przed przystąpieniem do realizacji) określić swoje wymagania względem systemu. Poza tym warto zwracać uwagę na różnego rodzaju sygnały alarmowe, jak np. poważne personalne przetasowania występujące u wykonawcy w czasie realizacji systemu informatycznego.

Duże systemy z reguły nigdy nie są realizowane w 100% zgodnie z planem (zgodnie ze starą zasadą, że tworząc program można precyzyjnie ocenić jedynie termin ukończenia albo budżet, ale nigdy te dwa czynniki naraz). Firmy zajmujące się realizacją dużych kontraktów informatycznych powinny realizować w swoim działaniu normy zachowań zawodowych i etycznych właściwych informatyce. Wszystkie większe światowe organizacje skupiające informatyków mają własne zbiory takich zasad i obligują swoich członków do ich przestrzegania.

Sytuacja powstała przy tworzeniu systemu Confirm w dużej mierze przypomina, to co się działo na naszym krajowym podwórku podczas realizacji projektu Poltax, zwłaszcza jeśli chodzi o postawę i zachowanie kierownictwa, szczególnie we wcześniejszym okresie. W czasie procesu sądowego AMRIS zarzucił konsorcjum zleceniodawcy, że "myśli tylko o sobie". Nie jestem pewien czy to dobrze, że nasze Ministerstwo Finansów nie jest tak egoistyczne...