W praktyce najczęstszy błąd wygląda tak: firma wybiera integratora na podstawie prezentacji i referencji, akceptuje jego „standardowy kontrakt” bez negocjacji, a rok później spiera się o to, czy opóźnienie o 3 miesiące jest winą integratora czy klienta — bez żadnych postanowień umownych, które pozwalałyby to rozstrzygnąć. Naprawa kontraktu w trakcie projektu jest możliwa, ale najtrudniejsza i najdroższa.
| # | Standardowy kontrakt integratora | Wynegocjowany kontrakt klienta |
|---|---|---|
|
Zakres wdrożenia |
Ogólny opis systemu lub lista modułów bez specyfikacji procesów |
Załącznik funkcjonalny z listą modułów, procesów, integracji i kryteriów akceptacji |
|
Odbiory |
Brak protokołów lub ogólny zapis o „gotowości systemu” |
Protokoły odbioru częściowego i końcowego z definicją błędów blokujących odbiór |
|
Change requesty |
Integrator decyduje, co jest CR; wycena post factum |
Procedura CR z obowiązkiem wyceny przed realizacją; rozróżnienie CR od naprawy wad |
|
Kary umowne |
Szerokie wyłączenia „po stronie klienta”; kary praktycznie nienegocjowalne |
Precyzyjne wyłączenia; kary egzekwowalne |
|
Cap odpowiedzialności |
1 miesiąc wynagrodzenia lub ostatni etap |
Limit odpowiedzialności odpowiedni do wartości i ryzyk projektu, z odrębnymi zasadami dla naruszeń szczególnie istotnych (np. poufności, RODO czy praw własności intelektualnej). |
|
Rękojmia za wady |
Wyłączona całkowicie lub skrócona do 30 dni |
Odpowiednio uregulowana rękojmia albo gwarancja (w zależności od przyjętego modelu odpowiedzialności). |
|
Escrow kodu |
Brak |
Umowa escrow lub obowiązki eksportu danych (przy SaaS) |
|
Exit plan |
Brak — zmiana integratora wymaga odrębnych negocjacji |
Przenośność danych, format eksportu, Transfer of Knowledge, czas trwania licencji po zakończeniu |
|
RODO |
Brak umowy powierzenia lub klauzula ogólna |
Umowa powierzenia przetwarzania danych (art. 28 RODO) z pełnym zakresem |
|
Zmiana integratora |
Trudna i kosztowna |
Uregulowana umownie; koszty przewidywalne |
Zanim podpiszesz umowę wdrożeniową, możesz samodzielnie sprawdzić, czy chroni Cię w kluczowych obszarach — od zakresu i odbiorów, przez SLA i kary umowne, po limit odpowiedzialności, powierzenie danych i dostęp do systemu po zakończeniu współpracy.
Przygotowaliśmy interaktywną checklistę, która przeprowadzi Cię przez najważniejsze punkty i pokaże, gdzie kontrakt wymaga uwagi. Jeśli któryś z obszarów budzi wątpliwości, przeanalizujemy Twoją umowę i wskażemy, co doprecyzować — skontaktujemy się i ustalimy zakres wsparcia.
Przedsiębiorstwa wdrażające systemy ERP, MES i WMS zarządzające produkcją, logistyką i magazynem. Dla nich awaria systemu po go-live oznacza przestój linii produkcyjnej — dlatego SLA i kary umowne mają realne znaczenie finansowe, a nie tylko negocjacyjne.
Podmioty wdrażające ERP, WMS i systemy CRM/PIM/omnichannel. Dla nich kluczowe są integracje z kanałami sprzedaży i skrócony czas uruchomienia — każdy dzień opóźnienia go-live to konkretna strata przychodu.
Firmy wdrażające systemy IT dla własnych klientów lub wdrażające narzędzia do wewnętrznego użytku. Rozumiemy specyfikę projektów agile i waterfall — i doradzamy, jak chronić interesy klienta w obu modelach.
Wewnętrzne zespoły prawne i zakupowe, które potrzebują wsparcia merytorycznego przy negocjacjach z dużymi integratorami SAP, Oracle, Microsoft lub przy analizie kontraktów wielomilionowych. Dostarczamy analizę i argumenty — decyzje zostają po Twojej stronie.
Podmioty chcące wyjść z istniejącego kontraktu lub zmienić integratora. Oceniamy, co mówi obecna umowa o exit planie, przenośności danych i ewentualnych kosztach zmiany — zanim zaczniesz negocjować.
Zakres wdrożenia to fundament całego kontraktu. Wszystko, co nie jest w nim wyraźnie opisane, może być przez integratora potraktowane jako zmiana zakresu — i wycenione jako osobny change request.
Zasada, którą widać w każdym projekcie IT: integrator odpowiada za to, co zostało w umowie wyraźnie zdefiniowane. Ogólny zapis "wdrożenie modułu finansowo-księgowego" nie przesądza o tym, które procesy, które integracje z systemami zewnętrznymi i które raporty są objęte kontraktem. Każda z tych pozycji może stać się change requestem.
W praktyce oznacza to, że umowa bez precyzyjnego załącznika funkcjonalnego nie chroni przed:
Weryfikujemy zakres wdrożenia pod kątem tego, co firma rzeczywiście potrzebuje — procesów, integracji, raportów i migracji danych — a nie tego, co wynika z szablonu integratora.
art. 643 KC i orzecznictwo w sprawach umów o dzieło wskazują, że sposób dokonania odbioru oraz reakcja zamawiającego po zgłoszeniu gotowości do odbioru mogą mieć istotne znaczenie przy późniejszej ocenie wykonania zobowiązania.. Dlatego protokoły odbioru i procedura kwestionowania powinny być opisane w umowie, nie pozostawione do ustalenia „w toku projektu”.
SLA (Service Level Agreement) to parametry dostępności systemu i czasy reakcji integratora na incydenty. W umowach wdrożeniowych SLA zazwyczaj dotyczy środowiska produkcyjnego po go-live — i zazwyczaj jest to jeden z elementów najczęściej podlegających negocjacjom..
Trzy rzeczy, które decydują o tym, czy SLA jest egzekwowalne:
Cap odpowiedzialności to limit odszkodowania, którego klient może dochodzić od integratora. W wielu standardowych projektach umów integratorów cap jest ustalony na poziomie wynagrodzenia za jeden miesiąc lub za ostatni etap. Przy wdrożeniu wartym kilka milionów złotych oznacza to, że realne odszkodowanie za katastrofalny projekt może wynieść kilkadziesiąt tysięcy złotych.
Dwie kwestie, o których rzadko mówią doradcy integratora: (1) art. 484 §2 KC daje sądom prawo do obniżenia rażąco wygórowanej kary umownej — integrator może z tego skorzystać w sporze, nawet jeśli kara była negocjowana. (2) Rękojmia za wady dzieła (art. 638 KC) to oddzielne narzędzie od kary umownej — standardowe umowy często ją wyłączają. Warto wiedzieć o tym, zanim podpisze się protokół odbioru.
Zuzanna Świątek, radca prawny, specjalizuje się w prawie umów i obsłudze korporacyjnej, w tym w umowach w obszarze IT. Sprawdzi Twój kontrakt z integratorem pod kątem odbiorów, SLA, kar umownych, limitu odpowiedzialności i zasad wyjścia z umowy — i wskaże, co doprecyzować, zanim projekt ruszy. Zostaw kontakt, a skontaktujemy się i ustalimy zakres wsparcia.
Trzy elementy, o których myśli się za późno — gdy wdrożenie jest skończone, a współpraca z integratorem się kończy.
Escrow kodu źródłowego to umowa trójstronna (klient, integrator, niezależny agent escrow), na mocy której kod lub konfiguracja są deponowane u agenta i udostępniane klientowi przy zdefiniowanych zdarzeniach: upadłości integratora, zaprzestania wsparcia, zerwania współpracy. Kiedy ma sens:
Exit plan powinien być częścią umowy wdrożeniowej od dnia podpisania — nie warunkiem wynegocjowanym dopiero przy zmianie systemu. Kluczowe elementy:
RODO: w większości projektów wdrożeniowych integrator ma dostęp do danych osobowych przetwarzanych przez klienta. Jeżeli przetwarza je w imieniu i na rzecz klienta, konieczna jest umowa powierzenia przetwarzania danych (art. 28 RODO). Konkretna rola integratora (procesor, współadministrator lub podmiot bez dostępu do treści danych) zależy od okoliczności projektu — warto ocenić ją indywidualnie, nie zakładać z góry.
w XX Rankingu firm i doradców podatkowych Dziennik Gazeta Prawna.
w Rankingu firm doradztwa podatkowego Rzeczypospolitej.
Za wkład w rozwój gospodarczy, zaangażowanie w ideę społecznej odpowiedzialności biznesu oraz stworzenie silnej i rozpoznawalnej marki.
Wyróżnienie dla firm kierujących się wysokimi standardami w działalności biznesowej, gwarantujących najwyższą jakość obsługi.
Zostaw kontakt, a przeanalizujemy Twój kontrakt z integratorem — zakres i odbiory, SLA, kary umowne, limit odpowiedzialności, powierzenie danych i zasady wyjścia z umowy. Wskażemy, gdzie zapisy zostawiają Cię bez realnych narzędzi i co doprecyzować, dopóki masz jeszcze pole do negocjacji. Skontaktujemy się i ustalimy zakres wsparcia.
Projekt umowy przygotowany przez integratora z natury rzeczy reprezentuje jego interesy. W wielu standardowych projektach umów integratorów znajdziesz ograniczoną odpowiedzialność wykonawcy, szerokie klauzule wyłączeń i uproszczone procedury odbioru. Analiza tych postanowień przed podpisaniem pozwala zdecydować, co negocjować — a pozycja negocjacyjna jest największa przed startem projektu.
Elementy, które warto wynegocjować: (1) załącznik funkcjonalny z listą modułów, procesów i integracji, (2) harmonogram z terminami odbiorów częściowych i końcowych, (3) kryteria akceptacji z definicją błędów blokujących odbiór, (4) kary za opóźnienie z precyzyjnymi wyłączeniami, (5) SLA dla środowiska produkcyjnego, (6) rękojmia lub gwarancja o określonym zakresie i czasie trwania, (7) zasady change requestów z obowiązkiem wyceny przed realizacją, (8) escrow kodu lub obowiązki eksportu danych, (9) klauzula exit i przenośność danych, (10) cap odpowiedzialności proporcjonalny do wartości kontraktu, (11) umowa powierzenia danych (art. 28 RODO) — jeśli integrator będzie przetwarzał dane osobowe.
Każda platforma niesie inny profil ryzyk: SAP — relacja trójstronna (SAP, partner implementacyjny, klient); kluczowe jest uregulowanie odpowiedzialności partnera za dostosowania i wdrożenie. Dynamics 365 — model subskrypcyjny; model subskrypcyjny powoduje, że kwestie eksportu danych po zakończeniu korzystania z usługi powinny zostać szczegółowo uregulowane w umowie. Comarch ERP XL / enova365 — polskie systemy z licznym ekosystemem partnerów o zróżnicowanym profilu; warto zweryfikować zakres odpowiedzialności i ubezpieczenie OC partnera. Oracle — w projektach międzynarodowych mogą występować umowy poddane prawu obcemu lub przewidujące arbitraż; model on-premise i chmura niosą różne ryzyka licencyjne.
Analizę projektu umowy przygotowujemy w ciągu [DO PODMIANY] dni roboczych. Negocjacje obejmują zazwyczaj 1–3 rundy z integratorem. Kluczowe: proces prawny powinien startować zanim zostanie ustalony ostateczny harmonogram wdrożenia — zmiana harmonogramu po podpisaniu jest znacznie trudniejsza.
Escrow kodu to umowa trójstronna (klient, integrator/dostawca, niezależny agent), na mocy której kod lub konfiguracja są deponowane u agenta i wydawane klientowi przy zdefiniowanych zdarzeniach: upadłości dostawcy, zaprzestania wsparcia, zerwania współpracy. Zastosowanie zależy od modelu: oprogramowanie dedykowane — escrow kodu; ERP z rozbudowaną customizacją — escrow konfiguracji i modyfikacji; SaaS — umowne obowiązki eksportu danych jako funkcjonalny odpowiednik.
