Gwarancja w umowie wdrożeniowej. Poradnik dla software house’ów #10

W kontraktach IT jedną z kluczowych kwestii dla zamawiającego jest odpowiednie zabezpieczenie się na wypadek nieprawidłowego wykonania przez wykonawcę umowy.  Z tego artykułu dowiesz się, na czym polega udzielenie gwarancji na oprogramowanie oraz jak dokonać tego w taki sposób, aby zminimalizować ryzyka po stronie wykonawcy.

Prawo dla programistów – dołącz do naszej grupy na Facebooku! >>

Artykuł jest częścią serii dotyczącej umowy wdrożeniowej, poniżej znajdziesz odnośniki do pozostałych wpisów. Jeśli, któryś z artykułów nie jest jeszcze podlinkowany, oznacza to, że wpis dotyczący tego zagadnienia pojawi się na blogu w najbliższej przyszłości.

Gwarancja na oprogramowanie w umowach IT

Istnieje wiele mechanizmów – ustawowych oraz umownych – które pozwalają zamawiającemu podejmować działania w przypadku zawinionego, wadliwego (tj. niezgodnego z umową) wykonania oprogramowania. Przede wszystkim wykonawca ponosi odpowiedzialność odszkodowawczą na podstawie art. 471 KC, który przewiduje obowiązek naprawienia szkody wynikłej z zawinionego niewykonania lub nienależytego wykonania zobowiązania. Dochodzenie roszczeń na podstawie tego przepisu wymaga jednak podjęcia działań na drodze sądowej, co najczęściej wiąże się z długim i kosztownym postępowaniem. Z tego względu do umowy zazwyczaj wprowadzane są dodatkowe uprawnienia dla zamawiającego w tym przedmiocie.

Odpowiedzialność za wady oprogramowania

W umowie wdrożeniowej najczęściej mamy do czynienia z udzieleniem przez wykonawcę gwarancji na wykonane oprogramowanie. W tym miejscu należy zaznaczyć, że gwarancja stanowi zupełnie inne rozwiązanie prawne niż rękojmia (pojęcia te są często mylone). Rękojmia to ustawowa odpowiedzialność sprzedawcy za wady fizyczne i prawne sprzedanej rzeczy. W stosunkach pomiędzy przedsiębiorcami dozwolone jest wyłączenie zastosowania rękojmi, co jest standardem rozwiązaniem w branży IT. Miejsce rękojmi zazwyczaj niejako przejmuje gwarancja, stanowiąca rozwiązanie umowne i nieobligatoryjne. Przedmiot gwarancji wyznaczany poprzez zakres i zasady określone w umowie.

O czym należy pamiętać określając zakres świadczenia gwarancyjnego?

Precyzyjne opisanie przedmiotu umowy

Po pierwsze, o czym pisaliśmy już na blogu, przedmiot umowy powinien zostać określony bardzo precyzyjnie. Dokładne określenie, co i powinno zostać wykonane, pozwala zdeterminować, czy dane działanie programu rzeczywiście stanowi nieprawidłowe wykonanie umowy i tym samym podlega usługom gwarancyjnym opisanym w umowie. Opis oprogramowania zazwyczaj znajduje się w odrębnym załączniku stanowiącym specyfikację.

Zakres gwarancji w umowie wdrożeniowej

Dla zapewnienia bezpieczeństwa prawnego wykonawcy konieczne jest szczegółowe określenie zakresu gwarancji oraz zasad wykonywania usług gwarancyjnych. Przede wszystkim warto zamieścić w umowie precyzyjną definicję wady, która usuwana lub naprawiana będzie w ramach gwarancji. Z perspektywy wykonawcy rekomendowane jest, aby jako wadę wskazać tylko te nieprawidłowości, które wynikają z zawinionego wykonania umowy w sposób niezgodny z jej postanowieniami. Warto wprost wskazać, że za wadę nie uważa się nieprawidłowości wynikających np. z nieprawidłowej eksploatacji systemu przez zamawiającego, z niezapewnienia określonych w umowie wymogów w zakresie infrastruktury IT; czy też nieprawidłowości wynikających z działania innych systemów funkcjonujących w przedsiębiorstwie zamawiającego. Rzadko spotykanym, lecz najbardziej korzystnym dla wykonawcy rozwiązaniem jest z kolei określenie wady jako niedziałanie lub nieprawidłowe działanie określonego, zamkniętego katalogu funkcji systemu (w tym przypadku mamy do czynienia z istotnym ograniczeniem zakresu gwarancji).

Kategoryzacja wad i czasy naprawy. Odpowiedzialność za wady oprogramowania

Za dobrą praktykę uważa się dokonanie typizacji wad (np.: błąd krytyczny, błąd istotny, błąd nieistotny). Po raz kolejny wymagana jest tutaj precyzja – odpowiednie opisanie kategorii wad pozwoli m.in. ograniczyć sytuacje, w których zamawiający będzie zgłaszać wadę niższej kategorii jako błąd krytyczny, aby zapewnić szybszy czas naprawy.

Taka kategoryzacja wad pozwala wyważyć interesy stron – dla każdej kategorii ustala się inny czas naprawy, dzięki czemu najpoważniejsze awarie usuwane są szybko (aby umożliwić zamawiającemu faktyczne korzystanie z systemu), a niewielkie usterki mogą być naprawiane w dłuższej perspektywie czasowej (nie wpływa to bowiem na funkcjonowanie przedsiębiorstwa zamawiającego, a pozwala wykonawcy na zaplanowanie czasu naprawy z uwzględnieniem innych wykonywanych projektów).

Warto w umowie zaadresować także sposób postępowania w sytuacji, w której zamawiający zgłasza wadę wyższej kategorii, niż stanowi ona w rzeczywistości. Dla wykonawcy rekomendowanym rozwiązaniem jest zapewnienie sobie możliwości obniżenia kategorii wady w takim przypadku.

Z powyższym łączy się również kwestia ewentualnych kar umownych za zwłokę w czasie naprawy. Wysokość kar umownych jest aspektem biznesowym, jednak należy przede wszystkim należy zwrócić uwagę na dwie kwestie: (i) dla jakiej jednostki czasowej naliczana jest kara (np. za każdą rozpoczętą dobę zwłoki, za każdą rozpoczętą godzinę zwłoki itp.), (ii) aby kara umowna miała wysokość uzasadnioną rynkowo – kara ma być elementem motywującym wykonawcę do prawidłowego wykonania umowy oraz rekompensującym zwłokę zamawiającemu, jednak nie powinna być rażąco wysoka (kara umowna nie jest sposobem na zarobek, nie powinna też stanowić nadmiernego obciążenia dla przedsiębiorstwa wykonawcy).

Czas trwania gwarancji na projekt IT

Podstawową kwestią jest oczywiście określenie czasu obowiązywania gwarancji. Czas trwania gwarancji standardowo określany jest w miesiącach lub latach, jednak kluczowe jest tutaj odpowiednie określenie momentu, w którym gwarancja rozpoczyna swój bieg. Może to być np. moment odbioru końcowego oprogramowania (gwarancja rozpoczyna bieg dla całego systemu) lub moment odbioru określonych etapów oprogramowania (w tej sytuacji gwarancja wobec każdego z nich rozpoczyna – a więc i kończy – swój bieg w innym czasie).

Utrata gwarancji przez zamawiającego

Z perspektywy wykonawcy rekomendowane jest określenie w umowie przypadków, w których zamawiający traci prawo do gwarancji. Takimi sytuacjami może być np. wprowadzenie przez zamawiającego nieautoryzowanych zmian do systemu, świadczenie usług utrzymania systemu przez podmiot trzeci bez uprzedniej zgody wykonawcy, niezapewnienie wymogów dotyczących wymaganej infrastruktury itp.

Gwarancja a ofertowane wynagrodzenie

W kontraktach IT gwarancja niemal zawsze udzielana jest w ramach wynagrodzenia za wykonanie przedmiotu umowy – jest to bowiem dodatkowe zapewnienie wykonawcy, że oprogramowanie zostało wykonane prawidłowo, a zamawiający będzie mógł z niego korzystać w określony w umowie sposób. Określając jednak zakres świadczenia gwarancyjnego należy uwzględnić to w wysokości ofertowanego wynagrodzenia.

Gwarancja jakości oprogramowania a inne komponenty systemu

Wymaga zaznaczenia, że gwarancja jakości oprogramowania to zupełnie inne świadczenie niż gwarancja na dostarczany sprzęt (w tym przypadku gwarancja najczęściej udzielana jest przez producenta lub dystrybutora, który jednocześnie jest gwarantem). Ponadto gwarancja dotyczy oprogramowania własnego wykonawcy – gwarancja na oprogramowanie osób trzecich również zazwyczaj udzielana jest przez jego producenta lub dystrybutora.

Gwarancja a usługi utrzymania i usługi serwisowe

Na końcu warto podkreślić, że konieczne jest odróżnienie usług gwarancyjnych od usług utrzymania (serwis, SLA). Usługi utrzymania co do zasady są dodatkowo płatne. Ponadto zazwyczaj mają także dużo szerszy zakres – mogą np. obejmować usługi help desk, naprawę oprogramowania osób trzecich, nierzadko także usługi rozwoju. Gwarancja natomiast zazwyczaj ograniczona jest do usuwania wad, które tkwią w wykonanym oprogramowaniu.
W praktyce często zdarzają się umowy, w których kwestia ta nie jest precyzyjnie rozgraniczona, a pojęcia stosowane są zamiennie lub nieprawidłowo. Takich sytuacji należy unikać, ponieważ może to w efekcie końcowym doprowadzić do przyznania zamawiającemu nadmiernych uprawnień.