Projekty IT, zwłaszcza złożone wdrożenia systemów ERP, CRM czy BI, należą do najbardziej wymagających przedsięwzięć, zarówno pod względem technicznym, jak i organizacyjnym. Niestety wiele z nich nie kończy się sukcesem – różnice w oczekiwaniach, przeciągające się harmonogramy, błędy w implementacji lub brak jednoznacznych ustaleń prowadzą do poważnych sporów między dostawcą a klientem. Gdy zawodzą negocjacje i mediacje, coraz częściej strony decydują się na skierowanie sprawy do Sądu Arbitrażowego przy Krajowej Izbie Gospodarczej.
Arbitraż to pozasądowa forma rozwiązywania sporów, prowadzona przez niezależnych arbitrów, zgodnie z uprzednio uzgodnionymi zasadami. W porównaniu z postępowaniem sądowym, arbitraż wyróżnia się szybkością, elastycznością i poufnością. Strony mają wpływ na wybór arbitrów, którzy mogą posiadać doświadczenie nie tylko prawnicze, ale również techniczne – co w przypadku sporów IT ma ogromne znaczenie. Proces arbitrażowy składa się z kilku kluczowych etapów: zgłoszenia roszczeń, odpowiedzi, powołania składu orzekającego, przeprowadzenia postępowania dowodowego oraz wydania wyroku. To właśnie etap dowodowy bywa najbardziej wymagający – szczególnie wtedy, gdy przedmiotem sporu jest realizacja projektu informatycznego.
W takich sprawach niemal zawsze kluczową rolę odgrywa ekspertyza techniczna przygotowana przez niezależnego biegłego. Jego zadaniem jest wnikliwa analiza dokumentacji projektowej, harmonogramów, komunikacji, umów, zakresów funkcjonalnych, testów oraz rezultatów wdrożenia. Spory IT często opierają się na bardzo wyraźnej asymetrii wiedzy – dostawca dysponuje kompetencjami technicznymi i projektowymi, podczas gdy klient polega głównie na zaufaniu, deklaracjach i prezentacjach. W takich warunkach może dojść do sytuacji, w której dostawca konstruuje harmonogramy, modele rozliczeń lub akceptacji etapów w sposób korzystny wyłącznie dla siebie, niezgodny z rzeczywistym stanem prac i rynkowymi praktykami.
Biegły nie jest rzecznikiem żadnej ze stron – jego rola polega na bezstronnej ocenie tego, co rzeczywiście zostało zrealizowane, czy było to zgodne z umową i czy odpowiadało standardom branżowym. Często okazuje się, że projekt nie zawiódł z jednego powodu, lecz z wielu skumulowanych błędów – po obu stronach. Opinia biegłego pomaga rozplątać te zależności i pokazać, które decyzje, zaniechania lub nieporozumienia miały kluczowy wpływ na wynik projektu.
W projektach IT bardzo często występuje tzw. efekt domina – niepodjęcie decyzji przez klienta skutkuje niekompletnymi wymaganiami, które prowadzą do błędnych założeń technicznych po stronie dostawcy. Te z kolei owocują niedostosowanymi rozwiązaniami, które generują problemy przy testach, wdrożeniu i integracji. W takim układzie winy przeplatają się: niedopilnowany nadzór projektowy po stronie klienta spotyka się z brakiem przejrzystości komunikacji ze strony dostawcy, zmiany w zakresie nie są dokumentowane, a końcowe rozliczenia stają się punktem zapalnym. Ekspertyza techniczna pozwala w takich przypadkach zidentyfikować, gdzie zaczęło się pęknięcie, jak się rozprzestrzeniło i które decyzje – lub ich brak – miały największy wpływ na ostateczną porażkę projektową.
Dobrze przygotowana ekspertyza to nie tylko dokument – to narzędzie pomagające arbitrom zrozumieć złożoność sporu i podjąć decyzję opartą na faktach. Jej wartość nie polega jedynie na technicznej precyzji, ale również na tym, że jest zrozumiała dla osób spoza świata IT – dla prawników, przedsiębiorców i arbitrów. W wielu przypadkach to właśnie ona skłania strony do zawarcia ugody przed zakończeniem postępowania. W pozostałych – stanowi fundament rozstrzygnięcia.
Częścią pracy biegłego jest również ocena logiki procesów biznesowych zaimplementowanych w systemie – nie tylko „czy działa”, ale „czy działa tak, jak powinno”. Coraz częściej analizowane są także kwestie takie jak jakość kodu źródłowego, dokumentacja techniczna, kompletność testów i zgodność implementacji z uzgodnionymi standardami. Arbitraż daje możliwość uwzględnienia tych aspektów dzięki temu, że procedura jest elastyczna – można powołać dodatkowych ekspertów, zorganizować wspólne sesje techniczne, a nawet uzyskać opinie porównawcze.
Dla arbitrów i stron sporu równie istotne jak analiza techniczna jest zrozumienie tła decyzji – kto, kiedy i dlaczego podjął określone działania lub zaniechał ich podjęcia. Sprawy IT nie są bowiem tylko sprawami „o kod” – to spory o sposób prowadzenia projektu, zarządzanie zmianą, komunikację i wzajemne oczekiwania. Biegły w takim postępowaniu jest kimś więcej niż ekspertem od systemów – jest tłumaczem rzeczywistości projektowej na język faktów i zrozumiałych wniosków.
Rzetelna ekspertyza pokazuje często, że spór nie sprowadza się do jednej winy – lecz wymaga zrównoważonego podejścia do rozdzielenia odpowiedzialności. Arbitraż, w przeciwieństwie do sądu powszechnego, pozwala na taką elastyczność. Umożliwia wnikliwe spojrzenie na przyczyny porażki projektu i uwzględnienie całego kontekstu – nie tylko zapisów w umowie, ale również sposobu ich realizacji.
Ostatecznie, arbitraż technologiczny – wsparty ekspertyzą biegłego – daje stronom nie tylko wyrok, ale i szansę na zrozumienie, co poszło nie tak. To z kolei bywa nieocenione przy planowaniu kolejnych projektów IT, tym razem z większą świadomością ryzyk, odpowiedzialności i znaczenia współpracy.