Sąd nad systemem

Czy procesy sądowe są właściwą drogą do rozwiązania spornych kwestii po nieudanym projekcie informatycznym? Nie. Dochodzi jednak do sytuacji, w których nie ma już innego rozwiązania - tracą bowiem i skarżący, i oskarżony.

Czy procesy sądowe są właściwą drogą do rozwiązania spornych kwestii po nieudanym projekcie informatycznym? Nie. Dochodzi jednak do sytuacji, w których nie ma już innego rozwiązania - tracą bowiem i skarżący, i oskarżony.

Pod koniec sierpnia br. BRE Leasing złożył w Sądzie Arbitrażowym przy Krajowej Izbie Gospodarczej pozew przeciwko firmie SA o odszkodowanie z tytułu zakończonego niepowodzeniem wdrożenia systemu informatycznego Egeria Leasing. W połowie września br. spółka zależna BRE rozpoczęła kampanię informacyjną, wymierzoną w reputację i rynkowy wizerunek krakowskiego integratora, publikując w prasie płatne artykuły, opisujące historię nieudanego projektu z punktu widzenia BRE Leasing. W umowie strony zapisały, że treść wszystkich publicznych komunikatów musi być wcześniej uzgodniona, nie mówiąc o tym, że treść umowy jest tajemnicą handlową. Prezes BRE Leasing uznał jednak, że umowa już nie obowiązuje ze względu na przekroczenie przez ComArch wszystkich uzgodnionych terminów, i rozpowszechnił treść wielostronicowego pozwu sądowego. ComArch przez kilka tygodni nie odbijał piłeczki, uchylając się od komentarza ze względu na "dobry obyczaj kupiecki oraz postanowienia zarówno umowy, jak i ustawy o zwalczaniu nieuczciwej konkurencji, zabraniającej dyskutowania na łamach prasy szczegółów realizacji zawartych umów". Pod koniec miesiąca stracił jednak cierpliwość i postanowił na drodze sądo- wej dochodzić odszkodowania od BRE Leasing za naruszanie dobrego imienia firmy. "Jesteśmy w bardzo trudnej sytuacji, nie możemy agresywnie odpierać ataków klienta, ponieważ jesteśmy firmą usługową i w ten sposób pojmujemy profesjonalizm. Wydaje się, że po stronie klienta emocje wzięły górę" - mówi Janusz Filipiak, prezes ComArchu.

Kwestie formalne

W otwartej wojnie znalezienie rozwią- zania satysfakcjonującego obie strony może okazać się niezwykle trudne. Polskie sądy nie są przygotowane do rozstrzygania sporów o zakres odpowiedzialności stron za nieudane wdrożenie. Większości prawników trudno jest poruszać się w obszarze zagadnień ekonomicznych, nie mówiąc o sferze informatyki. Oczywiście, arbitrzy lub sędziowie mogą powołać biegłych, lecz - jak stwierdzają bardziej lub mniej niezależni konsultanci, którym rola ta mogłaby przypaść - to praca niewdzięczna i nisko płatna. Trudno więc o rzetelną ekspertyzę.

Sąd skazany jest więc na umowę i dowody, czyli powstającą w trakcie projektu dokumentację dwustronnych uzgodnień, zapisy spotkań, protokoły zdawczo-odbiorcze, schematy organizacyjne. Umowy najczęściej są konstruowane przez prawników dostawcy systemu, którzy głęboko zastanowili się, w jaki sposób zabezpieczyć jego interesy. Przede wszystkim nie są to umowy o dzieło, a więc rezultatu, lecz umowy o "profesjonalne świadczenie usług". Jeśli większa część tekstu umowy traktuje o kwestiach związanych ze sprzedażą licencji, a w pozostałej pojawiają się określenia typu "asysta wdrożeniowa" i dokładnie są wyliczone zakupione przez klienta godziny pracy konsultantów, to z pewnością nie jest to umowa gwarantująca wdrożenie systemu "pod klucz". Niejasne określenie w umowie samego przedmiotu umowy utrudnia sędziemu jej rozpoznanie. Opis funkcjonalny systemu ma zazwyczaj charakter na tyle ogólny, że trudno o interpretację, czy rzeczywiście dana część systemu została wykonana i czy stan faktyczny jest zgodny z wcześniejszymi ustaleniami.

W umowach wdrożeniowych rzadko są definiowane kluczowe pojęcia, takie jak "system informatyczny", "wdrożenie", "aplikacja", "użytkowanie". Sąd dysponuje więc umową, która w zasadzie jest dla niego niezrozumiała, zbyt obszerna i jednocześnie niedostatecznie szczegółowa. Zazwyczaj w pewnym akapicie stwierdza się - za zgodą klienta, który pod umową złożył podpis - że "dostawca ponosi odpowiedzialność za błędy oprogramowania, chyba że wynikają one z natury oprogramowania", a w zasadzie - na wzór umów licencyjnych Microsoftu - nie ponosi odpowiedzialności za nic i niczego nie gwarantuje. Ewentualnie ponosi odpowiedzialność tylko za szkody poczynione umyślnie, a umyślne działanie na szkodę klienta jest niezwykle trudne do udowodnienia. Dobrze gdy strony usta-lą, że spory rozstrzygane są na gruncie prawa polskiego, a nie na przykład austriackiego. Większość zachodnich producentów systemów ERP umieszcza też w umowach klauzulę, na mocy której niemożliwy jest zwrot licencji niezależnie od okoliczności, uzasadniając to zasadami sprawozdawczości, obowiązującymi spółki giełdowe.

Większość firm wdrożeniowych zastrzega w umowie ograniczenie odpowiedzialności do pewnej kwoty, nie przekraczającej zazwyczaj 100% wartości kontraktu. Argument o nieodpowiedniej funkcjonalności systemu i amatorstwie firmy informatycznej można zbić, powołując się na 100 innych udanych wdrożeń oraz wskazując na złą organizację i "niską kulturę informatyczną klienta". Jak więc na tym tle wyglądają szanse BRE Leasing na uznanie przez sąd odszkodowania w wysokości 1,47 mln zł, na którą to sumę składają się zwrot należności wpłaconych już na konto ComArchu (645 tys. zł), kara (415 tys. zł) oraz odszkodowanie (409 tys. zł jako ekwiwalent 9877 roboczogodzin poświęconych przez pracowników BRE na przygotowanie materiałów dla wykonawcy, spotkania z wykonawcą i wprowadzanie danych do nowego systemu), odsetki i koszty procesu? Zdarzały się przypadki zwrotu przez firmę informatyczną części pobranego wynagrodzenia, ale był to raczej efekt dobrej woli i marketingowego podejścia dostawcy w perspektywie następnych projektów niż wygrana klienta na podstawie umowy.

Przejdźmy do meritum

BRE Leasing oskarża ComArch o drastyczne przekroczenie uzgodnionego harmonogramu projektu (zakończenie planowano w połowie 1998 r., pozew złożono w 2001 r. w czasie gdy system był wykonany w 60%), brak profesjonalizmu młodej, niedoświadczonej i często zmieniającej się kadry, rekomendację niewydajnej w stosunku do wymagań systemu konfiguracji sprzętowej, wykonanie poszczególnych modułów niezgodnie ze specyfikacją zawartą w analizie potrzeb zamawiającego, będącej efektem pierwszego etapu projektu.

W projekcie uczestniczyło 46 pracowników firmy ComArch, kierowało nim czterech menedżerów. ComArch twierdzi, że jest to dowód determinacji, z jaką starał się wykonać system bez względu na poniesione koszty, rotacja menedżerów projektu była przeprowadzana na życzenie prezesa BRE Leasing, a przekroczenie terminów to wynik nieustannych zmian wymagań dotyczących funkcjonalności. Do pewnego momentu ComArch był skłonny te zmiany uwzględniać, później prawdopodobnie w grę zaczęło wchodzić dodatkowe wynagrodzenie dla konsultantów, którego kosztów klient nie chciał ponieść. Niełatwo jest dokonać choćby próby analizy, która ze stron może mieć rację, o tym powinien rozstrzygnąć sąd. Zgodnie jednak z naszą wiedzą, w Polsce nie została jeszcze rozstrzyg-nięta żadna sprawa tego rodzaju, a większość pozwów była wycofywana z sądu, strony bowiem zawierały ugodę. Sprawa BRE kontra ComArch jest pierwszym tak "publicznym" konfliktem klienta z firmą informatyczną.

"Sądy są po to, by rozstrzygać spory, ale oddanie sprawy wdrożenia do sądu powinno być ostatecznością. Obie firmy wyjdą z tego sporu pokiereszowane. Klientowi trudno będzie znaleźć firmę, która na korzystnych warunkach zechce podjąć kolejną próbę wdrożenia, reputacja dostawcy może zostać poważnie nadszarpnięta niezależnie od ostatecznego werdyktu, który nie zostanie wydany wcześniej niż za dwa lata, jeśli w ogóle. Naprawdę trudno o jednoznaczną ocenę, kto jest winny nieuda-nego wdrożenia. Można poddać się przy bardzo dobrym systemie i wdrożyć sys- tem całkiem słaby, wszystko zależy od tego, jak układa się współpraca obu stron" - ocenia Czesław Stachowiak, kierownik działu analiz strategicznych Instytutu Energetyki w Gdańsku, właściciel firmy CS_Consulting.

Warto sobie uświadomić, że nie każde niepowodzenie projektu jest zawinione przez dostawcę. Oczywiście, w pierwszych latach rozwoju polskiego rynku systemów ERP zdarzały się przypadki sprzedaży systemu; który wcześniej został wycofany przez zachodniego producenta; sprzedaży przedsiębiorstwu wielozakładowemu, prowadzącemu produkcję procesową, systemu, który obsługi tego rodzaju działalności nie umożliwiał. Zdarzały się systemy, które po zakupie przeleżały kilka lat na półce, bo konsultanci partnera wdrożeniowego nie mieli umiejętności, a pracownikom klienta brakowało koncepcji. Jest wiele wdrożeń, które trwają latami, prowadzonych ze strony klienta przez zakładowego informatyka, który nie ma ani wystarczających kompetencji, ani zdolności, ani czasu, ani chęci, ani uprawnień w przedsiębiorstwie, by takie wdrożenie doprowadzić do szczęśliwego końca. Mnóstwo jest wdrożeń, których koszty zdecydowanie przekroczyły początkowe wyobrażenia klienta i ten w związku z tym płaci więcej niż planował lub zawiesza wdrożenie na czas nieokreślony po uruchomieniu modułu finansowego, gdyż na resztę zwyczajnie go nie stać.

"10% wszystkich projektów kończy się sukcesem i jest dobrze prowadzonych. 30% to projekty, które się zakończyły, ale na pewno nie tak, jak strony tego oczekiwały w momencie zawierania umowy. Reszta to mniej lub bardziej spektakularne porażki, projekty, które nie przyniosły żadnych efektów lub zakończyły się na etapie modułu finansowo-księgowego" - mówi Ludwik Maciejec, właściciel firmy Usługi Informatyczne i Konsultingowe. A jednak mimo tych porażek, niewiele wdrożeń znajduje swój finał w sądzie. Zaskakująco niewiele.

No i czym się chwalić

Prawda jest taka, że - nawet w przypadku projektu ewidentnie nieudanego - nikomu nie zależy na tym, by sprawę złożyć do sądu, upublicznić. Niezwykle trudno jest udowodnić, że wina spoczywa całkowicie na jednej ze stron, zbyt często dostawca bez trudu mógłby dowieść, że klient nie podjął na czas odpowiednich decyzji, nie udostępnił odpowiednich zasobów, nie zorganizował odpowiednio przepływu informacji. "Najczęściej trafiają do nas sprawy o niewypełnienie zobowiązań, sprawy proste, w których łatwo jest stwierdzić, że jedna ze stron zachowała się niezgodnie z zapisami umowy. A i tak większość nawet tych prostych spraw kończy się poza sądem, strony idą na ustępstwa i decydują się podpisać ugodę, zamiast płacić adwokatom, ponosić koszty i wikłać się w proces" - stwierdza Jolanta Dumas, radca prawny, sekretarz Sądu Arbitrażowego przy Krajowej Izbie Gospodarczej.

Dostawcy nie zależy na procesie z oczywistych względów. Klient z kolei przyznaje się w ten sposób, że nie odrobił pracy domowej: nie sprawdził referencji dostawcy, nie przyjrzał się oferowanemu przez niego rozwiązaniu pod kątem potrzeb swojego przedsiębiorstwa, nie przeanalizował umowy. Szef działu informatyki i dyrektor finansowy musieliby przyznać, że podjęli złą decyzję przy wyborze dostawcy, stracili - być może bezpowrotnie - znaczną kwotę, nie byli w stanie kontrolować przebiegu projektu.

Trudności obiektywne

Warto uzmysłowić sobie, że wiele problemów z wdrożeniem nie powstaje w wyniku czyjejkolwiek złej woli. Projekty rozpisane są na rok, dwa lata. W tym czasie zmieniają się zarządy, cele biznesowe, kondycja finansowa obu stron, w naturalny sposób odchodzą i przyjmowani są nowi pracownicy. Pod koniec realizacji większości projektów tworzy się również specyficzna sytuacja, w której klient jest już znacznie mądrzejszy niż na początku i uzmysławia sobie wyraźnie, że wymagana przez niego początkowo funkcjonalność systemu nie zaspokoi potrzeb firmy i nie przyniesie jej znaczących korzyści. Zresztą pod koniec projektu może się okazać, że to już zupełnie inna firma, ale tego przecież nie było w umowie. Pojawia się również strach przed ostateczną weryfikacją podjętych kilkanaście miesięcy temu kosztownych decyzji, który czasem powo- duje, że nawet wdrożony system nigdy nie wejdzie do użytku. Klient oczywiś-cie chciałby odzyskać pieniądze za licencję i wycofać się z całego przedsięwzięcia, lecz nie pozwalają mu na to treść zawartej umowy i podpisane protokoły zdawczo-odbiorcze. Sprawa nie trafia więc do sądu.

Sądy nie rozstrzygną wszystkich sporów na tle informatycznym, ponieważ nie mają odpowiednich doświadczeń i kompetencji. Można narzekać, że dostawcy systemów i ich prawnicy są aroganccy, ich postępowanie - nie zawsze etyczne, obietnice - nierealne, oferty - nierzetelne, ceny - zbyt wygórowane, a rezultaty - niepewne. Narzekanie nic jednak nie zmieni, może najwyżej zepsuć nastrój narzekającemu. Na razie jedyną metodą dochodzenia sprawiedliwości w sporach z dostawcami jest pokorne odrabianie pracy domowej jeszcze przed uruchomieniem projektu: uzupełnianie wiedzy o systemach informatycznych (które z pewnością z czasem nie staną się prostsze), angażowanie w projekty trzeciej strony, czyli doświadczonego konsultanta, który wskaże klientowi również jego błędy, wybór systemu, który w razie konfliktu może zostać wdrożony przez inną firmę, studiowanie umów i załączników przed ich podpisaniem. No i jeszcze trochę zdrowego rozsądku, elastyczności i zdolności przyznania się do popełnionych błędów.


TOP 200