Obsługa prawna wdrożeń IT
Wdrożenie systemu ERP, MES lub WMS to kontrakt na kilka milionów złotych i projekt liczony w miesiącach. Projekt umowy przygotowany przez integratora reprezentuje jego interesy — nie Twoje. Negocjujemy umowy wdrożeniowe po stronie klienta, zanim podpiszesz kontrakt z dostawcą SAP, Microsoft Dynamics 365, IFS, Comarch ERP XL, enova365 lub Oracle.
Jak możemy pomóc?
Analiza i negocjacje umowy przed podpisaniem
Analiza i negocjacje umowy przed podpisaniem
- Analizujemy projekt umowy integratora i identyfikujemy ryzyka kontraktowe: niejasny zakres wdrożenia, brak kryteriów odbioru, szerokie wyłączenia odpowiedzialności, wyłączoną rękojmię.
- Proponujemy zapisy alternatywne z uzasadnieniem negocjacyjnym: co należy zmienić, co warto negocjować, co można zaakceptować.
- Reprezentujemy klienta w rozmowach z integratorem — dostarczamy argumenty prawne, nie tylko „czerwone flagi”.
Odbiory, change requesty i wsparcie w trakcie projektu
Odbiory, change requesty i wsparcie w trakcie projektu
- Pomagamy definiować protokoły odbioru częściowego i końcowego, kryteria akceptacji i procedurę odmowy odbioru.
- Analizujemy change requesty pod kątem zakresu umownego: jeżeli dana funkcjonalność mieści się w uzgodnionym zakresie wdrożenia, jej brak lub wadliwe wykonanie co do zasady nie powinno być kwalifikowane jako change request.
- Doradzamy przy sporach w trakcie projektu: dokumentacja, korespondencja, wezwania.
Escrow, exit plan i RODO
Escrow, exit plan i RODO
- Przygotowujemy umowy escrow kodu i konfiguracji z niezależnym agentem — lub obowiązki eksportu danych jako alternatywę przy SaaS.
- Projektujemy klauzulę exit: przenośność danych, Transfer of Knowledge, czas trwania dostępu po zakończeniu umowy.
- Weryfikujemy potrzebę zawarcia umowy powierzenia przetwarzania danych (art. 28 RODO) i przygotowujemy jej treść.
Spory i dochodzenie roszczeń
Spory i dochodzenie roszczeń
- Doradzamy, gdy wdrożenie jest opóźnione lub system nie spełnia wymagań: ocena podstaw prawnych, dokumentacja, strategia działania.
- Prowadzimy negocjacje i postępowania sporne z integratorem — w tym przed arbitrażem lub sądem.
Czym jest obsługa prawna wdrożenia IT?
Umowy wdrożeniowe mają najczęściej charakter umów mieszanych, łączących elementy umowy o dzieło oraz umowy o świadczenie usług. Ich kwalifikacja prawna zależy jednak od treści konkretnego kontraktu oraz charakteru poszczególnych świadczeń.
Obsługa prawna wdrożenia oznacza udział prawnika po stronie klienta na każdym etapie, w którym kontrakt decyduje o pieniądzach i ryzyku: od negocjacji zakresu i harmonogramu, przez definiowanie kryteriów odbioru, aż po klauzulę exit i plan migracji danych po zakończeniu projektu.
Podstawowa zasada: negocjować przed zawarciem umowy. Po rozpoczęciu projektu możliwości zmiany zasad współpracy są zwykle znacznie bardziej ograniczone i często wiążą się z dodatkowymi kosztami negocjacji.
Kontrakt integratora czy wynegocjowany kontrakt klienta - co naprawdę podpisujesz?
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 |
Czy Twoja umowa licencyjna zawiera wszystko, co powinna? [CHECKLISTA]
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.
Dla kogo pracujemy?
Producenci i firmy przemysłowe
Producenci i firmy przemysłowe
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.
Firmy handlowe, dystrybutorzy, e-commerce
Firmy handlowe, dystrybutorzy, e-commerce
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.
Spółki technologiczne i software housy
Spółki technologiczne i software housy
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.
Działy prawne i zakupowe przy kontraktach enterprise
Działy prawne i zakupowe przy kontraktach enterprise
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.
Firmy planujące zmianę systemu lub integratora
Firmy planujące zmianę systemu lub integratora
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 — dlaczego ogólna lista modułów nie wystarczy
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:
- fakturowaniem przez integratora za prace, które klient uważał za oczywiste — bo „przecież to był standard”,
- opóźnieniami „z winy klienta”, gdy klient nie zatwierdził czegoś, czego umowa od niego nie wymagała,
- sporami o to, co blokuje odbiór systemu — bo umowa nie definiuje, które błędy uniemożliwiają go-live.
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.
Odbiory i kryteria akceptacji — co podpisujesz przy go-live
Dwa rodzaje odbiorów, które każda umowa powinna rozróżniać:
Dwa rodzaje odbiorów, które każda umowa powinna rozróżniać:
- Odbiory częściowe (etapy / kamienie milowe) — akceptacja poszczególnych etapów projektu; bez nich integrator może twierdzić, że „projekt jest w toku”, nawet gdy miesiącami nie dostarcza nic.
- Odbiór końcowy (go-live / uruchomienie produkcyjne) — formalne przyjęcie systemu; od tego momentu biegną terminy gwarancji i zaczyna obowiązywać SLA produkcyjny.
Trzy elementy, bez których protokół odbioru jest dokumentem fikcyjnym:
Trzy elementy, bez których protokół odbioru jest dokumentem fikcyjnym:
- Definicja błędów blokujących odbiór (błędy krytyczne) — bez niej integrator twierdzi, że system „działa”, a klient, że „nie spełnia wymagań”; spór rozstrzyga się w sądzie.
- Lista testów akceptacyjnych — konkretne scenariusze do sprawdzenia przed podpisaniem; zaakceptowany wynik testu = dowód w ewentualnym sporze.
- Procedura odmowy odbioru — klient musi mieć prawo do odrzucenia odbioru z podaniem przyczyn; brak tej procedury może prowadzić do domniemanego przyjęcia systemu.
Uwaga praktyczna
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, kary umowne i cap odpowiedzialności — liczby, które mają znaczenie
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:
- Definicja „dostępności” — jak mierzy się uptime, co wlicza się do okna serwisowego, co jest „awarią” a co „pracami konserwacyjnymi”.
- Mechanizm naliczania kar — od kiedy zaczyna biec czas na reakcję, kto zgłasza incydent, jak dokumentuje się naruszenie SLA.
- Wyłączenia odpowiedzialności — szerokie klauzule „przyczyn leżących po stronie klienta” lub „sił wyższych” mogą wykluczyć kary w praktycznie każdej sytuacji.
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.
Twoją umowę wdrożeniową przeanalizuje Zuzanna Świątek
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.
Escrow kodu, exit plan i dane — co po zakończeniu projektu
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:
- przy oprogramowaniu dedykowanym — escrow kodu źródłowego,
- przy ERP z rozbudowanymi modyfikacjami i customizacją — escrow konfiguracji i kodu modyfikacji,
- przy SaaS i chmurze — funkcjonalnym odpowiednikiem escrow są umowne obowiązki eksportu danych po zakończeniu kontraktu.
Exit plan powinien być częścią umowy wdrożeniowej od dnia podpisania — nie warunkiem wynegocjowanym dopiero przy zmianie systemu. Kluczowe elementy:
- przenośność danych: zobowiązanie integratora do wydania danych w standardowym, udokumentowanym formacie (CSV, XML, API) w określonym terminie,
- czas trwania dostępu po zakończeniu umowy — read-only dla celów archiwalnych,
- Transfer of Knowledge — sesje przekazania wiedzy dla nowego integratora lub wewnętrznego IT,
- zakaz blokowania dostępu do danych jako nacisku w sporze.
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.
Dlaczego Staniek&Partners?
- Pracujemy po stronie klienta, nie integratora — nie obslugujemy jednocześnie vendorów i ich klientów w tym samym projekcie. Rozumiemy, jak integrator konstruuje umowy — i gdzie są standardowe „rafy”.
- Znamy systemy z nazwy — SAP, Dynamics 365, IFS, Comarch, Oracle, enova365 to nie abstrakcyjne kategorie. Wiemy, jak różnią się modele licencyjne i gdzie są typowe pułapki kontraktowe każdej z tych platform.
- IT + IP + podatki w jednym miejscu — umowa wdrożeniowa praw do konfiguracji, modyfikacji i innych rezultatów prac wdrożeniowych oraz ciągłości (chain of title) nabycia tych praw, danych (RODO) i potencjalnie IP Box, jeśli system wspiera działalność B+R. Nie potrzebujesz trzech osobnych doradców. [LINK: /ip-box/ + /prawo/umowy-licencyjne/]
- Doświadczenie transakcyjne — pracujemy przy due diligence i transakcjach M&A, gdzie portfolio umów IT jest weryfikowane przez prawnika kupującego. Wiemy, na czym potknie się umowa wdrożeniowa, zanim zapyta o to audytor.
Te firmy nam zaufały
Zabezpiecz umowę wdrożeniową, zanim ruszy projekt
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.
- kancelaria@staniekandpartners.com
- +48 534 535 508
- NIP: 8992913267
- REGON: 520686986
Wiedza z bloga
![Czy Twoja umowa licencyjna zawiera wszystko, co powinna? [CHECKLISTA]](https://staniekandpartners.pl/wp-content/uploads/2026/07/jakub-zerdzicki-O3ChbcT94NM-unsplash-768x503.jpg)
FAQ, czyli najczęściej zadawane pytania
Czy umowa przygotowana przez integratora jest bezpieczna?
Czy umowa przygotowana przez integratora jest bezpieczna?
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.
Co powinna zawierać umowa wdrożeniowa ERP?
Co powinna zawierać umowa wdrożeniowa ERP?
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.
Czym różnią się umowy wdrożeniowe SAP, Dynamics 365, Comarch ERP i Oracle?
Czym różnią się umowy wdrożeniowe SAP, Dynamics 365, Comarch ERP i Oracle?
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.
Ile trwa analiza i negocjacja umowy wdrożeniowej?
Ile trwa analiza i negocjacja umowy wdrożeniowej?
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.
Czym jest escrow kodu źródłowego i kiedy jest potrzebny?
Czym jest escrow kodu źródłowego i kiedy jest potrzebny?
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.