Gwarancja w umowie wdrożeniowej IT. 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.

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.

Zamów wzór umowy wdrożeniowej IT!

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 standardowym rozwiązaniem w branży IT.

Wyłączenie rękojmi stanowi kluczową strategię ograniczania ryzyka dla software house’ów, ponieważ skutecznie przenosi cały system odpowiedzialności za wady do bardziej przewidywalnej i kontrolowanej sfery gwarancji umownej. Bez tego wyłączenia klienci mogliby dochodzić roszczeń z tytułu rękojmi, oferującej inne, potencjalnie mniej korzystne dla wykonawcy środki zaradcze lub ramy czasowe.

Miejsce rękojmi zazwyczaj niejako przejmuje gwarancja, stanowiąca rozwiązanie umowne i nieobligatoryjne. Gwarancja jest dobrowolnym oświadczeniem dotyczącym jakości produktu, którego treść, zakres i czas trwania określane są w oświadczeniu gwarancyjnym stanowiącym zazwyczaj część umowy wdrożeniowej.

W przeciwieństwie do rękojmi, gwarancja oferuje elastyczność i możliwość dostosowania do specyficznych potrzeb i charakterystyki oprogramowania. 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ę.

Skuteczność i wykonalność gwarancji na oprogramowanie są bezpośrednio związane z jakością i precyzją specyfikacji funkcjonalnych oraz dokumentacji. Dokumenty te służą jako kluczowe odniesienia prawne, a nie tylko przewodniki techniczne. Niedokładne lub niekompletne specyfikacje prowadzą do niejasnych zobowiązań gwarancyjnych – jeśli stan „jak jest” oprogramowania nie może być obiektywnie zmierzony w stosunku do stanu „jak powinno być”, określenie „wady” staje się subiektywne i podatne na spory.

Sprawdź również: Jak opisać przedmiot umowy wdrożeniowej IT? 

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.

Kluczowe jest rozróżnienie między „wadą” a „brakującą funkcjonalnością”. Wada powinna być zazwyczaj ograniczona do defektów funkcjonalnych w istniejącym oprogramowaniu i jego zamierzonej funkcjonalności. Brak funkcji, która mogłaby być postrzegana jako niezbędna, ale nie została pierwotnie uzgodniona w specyfikacji, nie stanowi wady objętej gwarancją, lecz może wymagać dodatkowego rozwoju niestandardowego.

Taka niejednoznaczność prowadzi bezpośrednio do rozszerzania zakresu prac i sporów.

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.

Dodatkowo należy wyłączyć z zakresu wad: wprowadzenie przez zamawiającego nieautoryzowanych zmian do systemu, świadczenie usług utrzymania systemu przez podmiot trzeci bez uprzedniej zgody wykonawcy, nieprzestrzeganie zasad bezpieczeństwa przez klienta oraz użycie sprzętu lub oprogramowania niezatwierdzonego przez wykonawcę. Jasne określenie tych wyłączeń jest kluczowe dla zarządzania oczekiwaniami klienta i ograniczenia odpowiedzialności wykonawcy.

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.

Typowe kategorie wad obejmują: wady krytyczne prowadzące do całkowitej awarii systemu i uniemożliwiające korzystanie z kluczowych funkcji, wady istotne powodujące awarię kluczowej części aplikacji z możliwymi obejściami, oraz wady nieistotne dotyczące mało istotnej funkcjonalności lub kwestii kosmetycznych. Kategoryzacja ta pełni podwójną strategiczną rolę – stanowi nie tylko wytyczne operacyjne do usuwania błędów, ale także kluczowe narzędzie zarządzania ryzykiem i zapobiegania sporom.

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).

Przykładowe czasy reakcji i naprawy w ramach gwarancji mogą wyglądać następująco: dla wad krytycznych – natychmiastowa reakcja lub w ciągu 1-2 godzin z ciągłą pracą do rozwiązania, dla wad istotnych – reakcja w ciągu 4-8 godzin z rozwiązaniem w ciągu 1-7 dni, dla wad nieistotnych – reakcja w ciągu 24-48 godzin z rozwiązaniem do następnego większego wydania. Kluczowe jest jasne zdefiniowanie i udokumentowanie tych poziomów krytyczności w umowie.

Co ważne gwarancja i SLA mogą działać równolegle. Zazwyczaj wtedy czasy reakcji i naprawy z SLA są dużo bardziej korzystne dla zamawiającego gdyż zamawiający za SLA płaci dodatkowe wynagrodzenie, podczas gdy gwarancja jest udzielana w ramach samej umowy wdrożeniowej.

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).

Sprawdź również: Czym jest Service Level Agreement (SLA)?

Czas trwania gwarancji na oprogramowanie

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).

W praktyce umów na niestandardowe oprogramowanie okres gwarancji zazwyczaj wynosi od 90 dni do 1 roku po wdrożeniu. Ten okres jest przeznaczony na testowanie i uruchomienie przez użytkowników, aby upewnić się, że przedmiot umowy jest zgodny z ustaleniami i działa poprawnie.

Czas trwania gwarancji jest elementem negocjacyjnym i powinien być uwzględniony w kalkulacji wynagrodzenia – dłuższe okresy gwarancyjne mogą wiązać się z wyższymi kosztami dla software house’u ze względu na zwiększoną ekspozycję na ryzyko i konieczność alokacji zasobów na potencjalne naprawy.

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.

Takie postanowienia chronią wykonawcę przed odpowiedzialnością za wady, które nie wynikają z jego działania lub zaniechania, a są efektem niewłaściwego postępowania zamawiającego lub czynników zewnętrznych. Modyfikacje kodu, konfiguracji lub struktury bazy danych bez zgody wykonawcy mogą prowadzić do nieprzewidzianych błędów. Podobnie interwencje podmiotów trzecich mogą wprowadzać nowe wady lub uniemożliwiać identyfikację pierwotnej przyczyny problemu. Klauzule wyłączające odpowiedzialność z tytułu gwarancji muszą być jasne i jednoznaczne, aby były egzekwowalne.

Sprawdź również: Gwarancja a rękojmia w umowach IT

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.

Zakres gwarancji bezpośrednio wpływa na poziom ryzyka, jaki ponosi software house, a co za tym idzie, na jego model cenowy. Im szerszy zakres gwarancji i dłuższy jej okres, tym większe potencjalne koszty związane z usuwaniem wad, utrzymaniem zespołu wsparcia i zarządzaniem ryzykiem. Software house’y powinny dokładnie analizować i modelować różne scenariusze ryzyka, aby zapewnić, że oferowana cena adekwatnie pokrywa koszty związane z gwarancją i zapewnia zdrową marżę zysku. Prognozowanie kosztów gwarancyjnych jest kluczowe dla prawidłowego oszacowania rezerw księgowych na poczet gwarancji.

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).

Software house, jako wykonawca wdrożenia, zazwyczaj nie jest stroną gwarancji sprzętowej i nie ponosi za nią odpowiedzialności. W umowie wdrożeniowej należy jasno określić, że odpowiedzialność za wady sprzętu spoczywa na jego producencie lub dystrybutorze, a wszelkie roszczenia z tego tytułu powinny być kierowane bezpośrednio do nich.

Ponadto gwarancja dotyczy oprogramowania własnego wykonawcy – gwarancja na oprogramowanie osób trzecich również zazwyczaj udzielana jest przez jego producenta lub dystrybutora.

W przypadku oprogramowania osób trzecich, takiego jak systemy operacyjne, bazy danych, biblioteki czy gotowe komponenty komercyjne, software house powinien zapewnić, że są one dostarczane zgodnie z warunkami licencji i gwarancji udzielanych przez ich producentów.

Umowa wdrożeniowa powinna precyzować, że wykonawca nie ponosi odpowiedzialności gwarancyjnej za wady oprogramowania osób trzecich, chyba że wady te wynikają z jego nieprawidłowej integracji lub konfiguracji.

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.

Usługi utrzymania stanowią odrębną umowę, często zawieraną po zakończeniu okresu gwarancyjnego lub równolegle z nim. Mogą obejmować wprowadzanie nowych funkcjonalności, modyfikacji i ulepszeń nieobjętych pierwotną specyfikacją wdrożenia, monitorowanie systemu pod kątem wydajności i dostępności, dostarczanie aktualizacji bezpieczeństwa i poprawek niezwiązanych z wadami objętymi gwarancją, oraz zarządzanie infrastrukturą zapewniające spełnienie wymagań środowiskowych.

Gwarancja natomiast zazwyczaj ograniczona jest do usuwania wad, które tkwią w wykonanym oprogramowaniu. Te usługi są zazwyczaj wliczone w początkowe wynagrodzenie za wdrożenie i obejmują naprawę błędów, które uniemożliwiają oprogramowaniu działanie zgodnie z uzgodnionymi specyfikacjami.

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ń.

Może to prowadzić do oczekiwania bezpłatnych usług rozwojowych w ramach gwarancji lub niejasności co do zakresu odpowiedzialności i płatności. Jasne rozgraniczenie tych pojęć w umowie jest fundamentalne dla przejrzystości finansowej i operacyjnej. Dla software house’ów precyzyjne rozróżnienie między gwarancją a usługami utrzymania jest kluczowe dla ochrony przed nieuzasadnionymi roszczeniami o bezpłatne świadczenie usług wykraczających poza pierwotny zakres umowy.