Umowa IT bez kosztownych pułapek – na co zwrócić uwagę przed rozpoczęciem projektu technologicznego?

Wdrożenie systemu ERP, stworzenie aplikacji, zakup rozwiązania SaaS czy zamówienie dedykowanego oprogramowania wiążą się z ryzykiem, którego nie da się ograniczyć wyłącznie dobrym wyborem dostawcy. Równie ważne są warunki umowy określające zakres prac, harmonogram, procedurę odbioru, odpowiedzialność oraz zasady korzystania z gotowego rozwiązania.

Problemy często ujawniają się dopiero w trakcie projektu. Opóźnienie kolejnego etapu, brak oczekiwanej funkcjonalności albo spór dotyczący dodatkowych kosztów może prowadzić do poważnych konsekwencji biznesowych. Dlatego kontrakt IT powinien opisywać nie tylko scenariusz prawidłowej realizacji projektu, ale również zasady postępowania w sytuacjach problemowych.

Jednym z podstawowych źródeł sporów jest odmienne rozumienie zakresu zamówienia. Ogólne stwierdzenie, że wykonawca dostarczy system odpowiadający potrzebom klienta, może okazać się niewystarczające, gdy strony zaczną dyskutować o konkretnych funkcjonalnościach.

Umowa powinna pozostawać spójna z dokumentacją techniczną, specyfikacją i harmonogramem. Warto określić również sposób zgłaszania zmian oraz ich wpływ na cenę i termin realizacji. Ma to szczególne znaczenie w projektach rozwijanych etapami, w których wymagania biznesowe mogą ewoluować podczas wdrożenia.

Sam termin wykonania prac nie rozwiązuje problemu, jeśli strony nie ustalą, kiedy dany etap można uznać za prawidłowo ukończony. Procedura odbiorowa powinna określać kryteria weryfikacji rezultatów, terminy na zgłaszanie uwag oraz sposób postępowania z wykrytymi błędami.

W zależności od charakteru projektu można przewidzieć testy akceptacyjne i podział usterek według ich znaczenia. Inne konsekwencje powinien powodować błąd uniemożliwiający korzystanie z podstawowych funkcji systemu, a inne niewielka wada, która nie blokuje pracy użytkowników.

Zapłata za stworzenie programu komputerowego nie oznacza automatycznie, że zamawiający może korzystać z niego w dowolny sposób. Zasady dotyczące praw własności intelektualnej wymagają odpowiedniego uregulowania w kontrakcie. Znaczenie ma między innymi to, czy klient otrzyma licencję, czy dojdzie do przeniesienia określonych praw oraz jaki będzie zakres dozwolonego korzystania z rozwiązania.

Szczególnej uwagi wymagają projekty wykorzystujące komponenty dostawców zewnętrznych i oprogramowanie open source. Należy wiedzieć, na jakich warunkach poszczególne elementy mogą być wykorzystywane oraz kto odpowiada za zgodność zastosowanych komponentów z ich licencjami.

Przy większych wdrożeniach analiza kontraktu przez prawnik it kraków może pomóc zidentyfikować ryzyka dotyczące między innymi odpowiedzialności, licencji, SLA, danych osobowych czy uzależnienia przedsiębiorstwa od jednego dostawcy. Istotne jest przy tym spojrzenie na umowę nie tylko od strony przepisów, ale również rzeczywistego przebiegu projektu technologicznego.

Vendor lock-in staje się problemem wtedy, gdy zmiana wykonawcy okazuje się technicznie lub prawnie bardzo trudna. Firma może dysponować działającym systemem, a jednocześnie nie mieć odpowiednich praw, dokumentacji albo dostępu do kodu potrzebnego do jego dalszego rozwoju.

Ryzyko to warto przeanalizować jeszcze przed podpisaniem kontraktu. Znaczenie mogą mieć zasady dostępu do dokumentacji, możliwość modyfikacji systemu, prawa licencyjne, procedura zakończenia współpracy oraz warunki migracji danych. W określonych projektach rozważa się także rozwiązania związane z zabezpieczeniem dostępu do kodu źródłowego.

Łochowski.Legal to kancelaria adwokata Piotra Łochowskiego z siedzibą w Krakowie, koncentrująca praktykę na zagadnieniach związanych z nowymi technologiami. Zakres usług obejmuje między innymi umowy IT, audyty kontraktów, ochronę danych osobowych, cyberbezpieczeństwo, AI, compliance oraz obsługę przedsiębiorstw technologicznych. Kancelaria wspiera projekty IT od etapu wyboru dostawcy po negocjowanie i przygotowanie umów.

Łochowski.Legal obsługuje między innymi software house’y, startupy, dostawców usług chmurowych oraz zespoły produktowe. W ramach wsparcia dla branży IT przygotowuje i opiniuje umowy wdrożeniowe, licencyjne, utrzymaniowe, SLA i NDA, a także pomaga w kwestiach RODO, regulaminów usług cyfrowych, negocjacji oraz sporów związanych z realizacją kontraktów technologicznych.

W przypadku usług wymagających ciągłej dostępności samo zobowiązanie do utrzymywania systemu może być zbyt ogólne. Parametry SLA pozwalają precyzyjniej określić oczekiwany poziom świadczenia usług, sposób reagowania na awarie oraz czas potrzebny na ich usunięcie.

Odpowiedzialność dostawcy powinna być analizowana w powiązaniu z rzeczywistym znaczeniem systemu dla działalności klienta. Awaria narzędzia pomocniczego ma inne konsekwencje niż niedostępność platformy sprzedażowej, systemu produkcyjnego czy rozwiązania obsługującego kluczowe procesy przedsiębiorstwa.

Jeżeli dostawca otrzymuje dostęp do danych osobowych przetwarzanych przez klienta, projekt wymaga uwzględnienia wymogów związanych z ochroną danych. Może być konieczne odpowiednie uregulowanie powierzenia przetwarzania, zasad bezpieczeństwa, korzystania z podwykonawców oraz postępowania w przypadku incydentu.

Kwestii RODO nie należy rozpatrywać dopiero po uruchomieniu systemu. Architektura rozwiązania, sposób przechowywania informacji i zakres dostępu poszczególnych podmiotów mogą mieć bezpośrednie znaczenie dla zgodności całego projektu.

Czy każda umowa na stworzenie oprogramowania powinna regulować prawa autorskie?

Takie kwestie powinny zostać jasno określone. Strony muszą wiedzieć, na jakiej podstawie klient będzie korzystał z programu oraz jaki jest zakres przysługujących mu uprawnień.

Czym jest SLA w umowie IT?

SLA, czyli Service Level Agreement, określa uzgodniony poziom świadczenia usług. Może regulować między innymi dostępność systemu, czas reakcji na zgłoszenie oraz zasady usuwania awarii.

Co oznacza vendor lock-in?

Jest to sytuacja, w której przedsiębiorstwo staje się silnie zależne od konkretnego dostawcy technologii. Zmiana wykonawcy może być wtedy utrudniona z powodów technicznych, organizacyjnych lub prawnych.

Czy w umowie IT warto określić procedurę odbioru?

Tak. Jasna procedura pozwala ustalić, według jakich kryteriów rezultat zostanie zaakceptowany, kiedy można zgłosić błędy oraz jakie działania powinien podjąć wykonawca.

Kiedy najlepiej przeanalizować umowę IT?

Najbezpieczniej zrobić to przed podpisaniem kontraktu i rozpoczęciem właściwych prac. Pozwala to negocjować warunki wtedy, gdy strony mają jeszcze możliwość swobodnego ustalenia zasad współpracy.

Dobrze przygotowana umowa technologiczna powinna odzwierciedlać rzeczywisty sposób realizacji projektu. Precyzyjne zasady dotyczące odbiorów, odpowiedzialności, licencji, utrzymania systemu i zakończenia współpracy ograniczają przestrzeń do sporów oraz ułatwiają podejmowanie decyzji, gdy projekt nie przebiega zgodnie z pierwotnym planem.

(tekst sponsorowany)