Umowa na ERP jako element wyboru systemu, a nie formalność na koniec
Rola umowy w całym procesie wyboru ERP: od RFP do podpisu
Umowa na system ERP powinna być projektowana równolegle z wyborem rozwiązania, a nie dopinana na szybko po wyborze dostawcy. Jeśli wymagania biznesowe są opisane wyłącznie w RFP lub w prezentacjach handlowych, a nie trafiają do załączników umowy, w praktyce stają się katalogiem życzeń, a nie zobowiązaniem prawnym.
W procesie wyboru ERP kluczowe jest, aby już na etapie RFP (Request for Proposal) i późniejszych warsztatów zbierać konkretne zobowiązania dostawcy i od razu przekładać je na zapisy kontraktowe. Dotyczy to w szczególności: wymaganego poziomu dostępności systemu, czasu reakcji serwisu, zakresu aktualizacji, zasad rozwoju systemu i limitów odpowiedzialności. Im później temat umowy pojawi się w rozmowach, tym mniej będzie przestrzeni na negocjacje i tym większe ryzyko, że dostawca zasłoni się „standardowym wzorcem umowy”.
Dobrym podejściem jest tworzenie roboczego szkicu umowy lub przynajmniej kluczowych załączników (SLA, zakres wsparcia, polityka aktualizacji) już po pierwszych spotkaniach z 2–3 preferowanymi dostawcami. Dzięki temu można porównać nie tylko funkcje systemu ERP, ale również realne warunki serwisu i utrzymania, które będą obowiązywać przez lata po wdrożeniu.
Jak umowa przekłada się na realne koszty, ryzyka i elastyczność rozwiązania
Ta sama oferta wdrożenia ERP może w praktyce oznaczać zupełnie inne koszty całkowite (TCO) w zależności od treści umowy. Zapis „aktualizacje w cenie utrzymania” może oznaczać jedynie poprawki błędów, a nie duże upgrade’y. „Wsparcie serwisowe” może obejmować tylko rejestrowanie zgłoszeń, a nie faktyczne rozwiązywanie problemów w określonym czasie. Brak jasnych zasad indeksacji opłat może doprowadzić do istotnego wzrostu kosztów po 2–3 latach.
Umowa na ERP decyduje także o elastyczności rozwiązania. Jeśli warunki skalowania licencji (nowi użytkownicy, nowe moduły, oddziały) są nieprecyzyjne, każda większa zmiana w firmie może wiązać się z kosztownymi negocjacjami. Z kolei mało korzystne zapisy dotyczące wypowiedzenia, migracji danych i dostępu do kopii baz danych mogą w praktyce „uwięzić” firmę u jednego dostawcy na długie lata, nawet gdy system przestanie spełniać wymagania.
Dobrze skonstruowana umowa ERP jest więc narzędziem zarządzania ryzykiem: ogranicza skutki przestojów, porządkuje odpowiedzialność za dane, określa koszty aktualizacji, a także ustawia zasady rozwoju systemu wraz z rozwojem biznesu. Słaba umowa działa odwrotnie – zwiększa niepewność i sprawia, że każde odchylenie od „standardu” rodzi spór lub dodatkową fakturę.
Zależności między modelem wdrożenia (on-premise, chmura, hybryda) a kształtem umowy
Model wdrożenia ERP wprost wpływa na treść umowy. W środowisku on-premise firma zwykle odpowiada za infrastrukturę (serwery, sieć, kopie bezpieczeństwa), a dostawca – za oprogramowanie i wsparcie aplikacyjne. W modelu chmurowym (SaaS) większość warstw – od serwera po aplikację – jest po stronie dostawcy lub jego podwykonawcy, dlatego umowa musi rozróżniać SLA dla aplikacji ERP i SLA dla infrastruktury chmurowej.
W przypadku rozwiązań hybrydowych (np. ERP w chmurze, integracje i część baz lokalnie u klienta) rozdzielenie odpowiedzialności jest jeszcze bardziej złożone. Trzeba dokładnie opisać, kto odpowiada za:
dostępność aplikacji ERP,
dostępność łączy sieciowych pomiędzy lokalizacjami,
integracje (middleware, API, interfejsy wsadowe),
kopie bezpieczeństwa i odtworzenie środowiska,
zgodność konfiguracji z wymaganiami dostawcy ERP.
Jeśli umowa przerzuca zbyt wiele odpowiedzialności na klienta, realna gwarancja dostępności systemu znacząco spada. Z drugiej strony, nadmierne obciążenie dostawcy odpowiedzialnością za infrastrukturę klienta powoduje, że będzie on ograniczał się do minimalnych zobowiązań lub znacząco podniesie cenę usług utrzymaniowych.
Dlaczego to, czego nie ma w umowie, zazwyczaj nie istnieje w praktyce
W rozmowach handlowych często pojawiają się deklaracje w stylu „mamy wsparcie 24/7”, „reagujemy w ciągu godziny”, „aktualizacje są zawsze w cenie”. Jeśli te obietnice nie zostaną zapisane w umowie lub w załączniku SLA, nie ma realnej podstawy do ich egzekwowania. W sytuacji kryzysowej liczą się paragrafy i precyzyjne definicje, a nie nagrania z prezentacji sprzedażowej.
W praktyce warto traktować wszystko, co nie znalazło się w umowie, jako niezobowiązującą obietnicę. Dotyczy to także kwestii nieoczywistych: np. zakresu szkoleń powdrożeniowych, zasad udostępniania środowisk testowych, sposobu raportowania SLA, formy wsparcia w trakcie kontroli podatkowych czy audytów. Jeśli dany obszar jest dla firmy krytyczny, powinien mieć własny paragraf lub załącznik.
Brak zapisów często wychodzi na jaw dopiero po pierwszej poważniejszej awarii albo po pierwszej dużej zmianie organizacyjnej w firmie (nowy zakład, nowa spółka, reorganizacja procesów). Wtedy okazuje się, że dostawca „może pomóc, ale to usługa dodatkowa” albo „nie może zagwarantować czasu rozwiązania, bo to nie zostało zdefiniowane”.
Przykład „okazyjnej” umowy bez doprecyzowanego wsparcia
Realistyczny scenariusz: średnia firma handlowa podpisuje „okazyjną” umowę na ERP, koncentrując się na cenie wdrożenia i licencji. W umowie znajduje się ogólny zapis o „wsparciu serwisowym w standardowych godzinach pracy dostawcy” i „aktualizacjach zgodnych z polityką producenta”. Nie ma szczegółowego SLA, nie ma podziału zgłoszeń na priorytety, nie ma jasno zdefiniowanej dostępności systemu.
Po kilku miesiącach dochodzi do awarii, która blokuje przyjmowanie zamówień. Firma łapie się za głowę – każdy przestój oznacza realne straty. Dostawca rejestruje zgłoszenie, ale traktuje je jako „wysoki priorytet bez gwarantowanego czasu naprawy”, informując, że jego zespół jest aktualnie obciążony innymi projektami. Tymczasem przesyła propozycję „pakietu premium SLA” za dodatkową opłatą miesięczną, który wprowadza realne czasy reakcji i naprawy.
Finalnie firma płaci nie tylko za usunięcie awarii w trybie priorytetowym, ale także za rozszerzony pakiet SLA, bez którego trudno mówić o stabilnej pracy systemu. Oszczędność przy podpisywaniu umowy szybko zamienia się w dodatkowe koszty i utratę zaufania do dostawcy.
Kluczowe pojęcia w umowie ERP: SLA, serwis, gwarancja, utrzymanie
Definicja SLA w kontekście ERP: co obejmuje, czego zwykle nie obejmuje
SLA (Service Level Agreement) w kontekście ERP to opis minimalnych parametrów usług utrzymaniowych, jakie dostawca zobowiązuje się zapewnić. Typowe elementy SLA to:
deklarowana dostępność systemu (np. 99,5% w skali miesiąca),
czas reakcji na zgłoszenia według priorytetów (P1–P4),
czas usunięcia awarii lub przywrócenia działania,
godziny świadczenia wsparcia (np. 8/5, 12/5, 24/7),
SLA zazwyczaj obejmuje usługi serwisowe i utrzymaniowe, ale nie musi obejmować wszystkich działań związanych z systemem ERP. Często wyłączone są z niego:
prace rozwojowe (nowe funkcje, raporty, integracje),
szkolenia użytkowników,
projekty migracyjne i duże upgrade’y,
wsparcie dla niestandardowych rozszerzeń realizowanych przez stronę trzecią.
Jeśli firma oczekuje, że określone działania (np. zmiany konfiguracyjne czy konsultacje procesowe) będą wykonywane w określonym czasie i na określonych zasadach, należy to dopisać do SLA lub ująć w osobnym załączniku opisującym usługi rozwojowe i konsultingowe.
Różnica między gwarancją, utrzymaniem, rozwojem systemu i konsultingiem
W umowach ERP często myli się cztery pojęcia: gwarancja, utrzymanie (maintenance), rozwój (development) i konsulting. Każde z nich dotyczy innego rodzaju usług i innego okresu współpracy.
Gwarancja to zwykle okres po wdrożeniu (np. 3–12 miesięcy), w którym dostawca usuwa bezpłatnie błędy wdrożenia lub oprogramowania, o ile nie wynikają one z nieuprawnionych modyfikacji klienta. Gwarancja nie obejmuje zwykle zmian funkcjonalnych ani nowych wymagań.
Utrzymanie (maintenance) to płatna usługa ciągła, w ramach której dostawca zapewnia dostęp do aktualizacji, bezpieczeństwo poprawek, oraz wsparcie serwisowe zgodnie z SLA. Maintenance bywa powiązany z opłatą licencyjną (np. procent wartości licencji rocznie) albo wchodzi w skład abonamentu SaaS.
Rozwój systemu to prace polegające na rozszerzaniu lub modyfikowaniu funkcjonalności ERP pod specyficzne potrzeby firmy: nowe raporty, przepływy pracy, integracje z kolejnymi systemami. To zwykle projekty wyceniane osobno (time & material lub ryczałt), które nie są objęte standardowym SLA utrzymaniowym.
Konsulting obejmuje usługi doradcze: analizę procesów, projektowanie nowych rozwiązań, wsparcie w reorganizacji czy audyty konfiguracji. Również te usługi nie wchodzą zazwyczaj w zakres SLA i wymagają osobnej wyceny oraz harmonogramu.
Role po stronie dostawcy: helpdesk, serwis aplikacyjny, serwis techniczny, opiekun klienta
W dobrze opisanej umowie ERP warto wskazać nie tylko zakres usług, ale też role po stronie dostawcy i ich odpowiedzialności. Typowe role to:
Helpdesk / Service Desk – pierwszy punkt kontaktu, rejestruje zgłoszenia, wykonuje podstawową diagnozę, kieruje sprawy do odpowiednich specjalistów; często odpowiada za dotrzymanie czasu reakcji SLA.
Serwis aplikacyjny – specjaliści od warstwy aplikacji ERP, konfiguracji, procesów biznesowych; rozwiązują błędy funkcjonalne, modyfikują konfigurację, analizują logikę działania modułów.
Serwis techniczny – eksperci od infrastruktury (serwery, bazy danych, system operacyjny, sieć), kopii bezpieczeństwa i wydajności; kluczowi w modelach on-premise i hybrydowych.
Opiekun klienta / Account Manager – osoba odpowiedzialna za relację biznesową, eskalację spraw strategicznych, planowanie rozwoju systemu, negocjacje aneksów i nowych projektów.
Umowa powinna jasno wskazywać, jakie obowiązki spoczywają na każdej z tych ról i w jakich obszarach klient może oczekiwać wsparcia. W praktyce często pojawia się problem przerzucania odpowiedzialności między warstwą aplikacyjną a techniczną („to wina serwera, nie aplikacji” i odwrotnie). Dobre zapisy umowne minimalizują takie sytuacje.
Wsparcie reaktywne i proaktywne – dwie różne usługi
Support reaktywny to reagowanie na zgłoszenia klienta: awarie, błędy, niejasności w działaniu systemu. Proaktywne wsparcie to z kolei działania wyprzedzające problemy: monitoring środowiska, okresowe przeglądy konfiguracji, audyty wydajności, rekomendacje aktualizacji i zmian.
W wielu umowach ERP opisany jest wyłącznie support reaktywny, co oznacza, że dostawca włącza się dopiero wtedy, gdy coś już przestało działać lub powoduje zakłócenia. Tymczasem proaktywne podejście może znacząco zmniejszyć liczbę krytycznych incydentów i skrócić przestoje.
Jeśli firma oczekuje proaktywnego wsparcia, należy to wprost zapisać w umowie, np. poprzez:
cykliczne przeglądy techniczne i aplikacyjne (np. kwartalne),
cykliczne przeglądy konfiguracji kluczowych modułów (np. finanse, logistyka),
raporty z rekomendacjami zmian i harmonogram ich wdrożenia.
Brak rozróżnienia między wsparciem reaktywnym a proaktywnym prowadzi do rozczarowania: klient zakłada „opiekuńczy” model współpracy, a dostawca realizuje jedynie minimalne wymagania SLA, reagując tylko na zgłoszenia.
Jak unikać ogólników typu „wsparcie zgodne z najlepszymi praktykami”
Zapisy mówiące o „najlepszych praktykach branżowych” czy „standardach ITIL” brzmią profesjonalnie, ale są w praktyce bardzo trudne do wyegzekwowania. Dostawcy lubią się nimi posługiwać, bo nie wiążą się z konkretnymi liczbami i nie nakładają twardych zobowiązań.
Aby uniknąć nieporozumień, każdą ogólną obietnicę warto przełożyć na:
konkretny parametr (np. czas reakcji, czas naprawy, częstotliwość przeglądów),
konkretny artefakt (np. raport miesięczny, plan działania, dokumentacja powdrożeniowa),
konkretną procedurę (np. metoda eskalacji, sposób zgłaszania incydentów bezpieczeństwa).
SLA w ERP: dostępność, czas reakcji i czas naprawy
Jak liczyć dostępność systemu i jakie wyłączenia są „standardem”
Deklarowana dostępność typu „99,7%” brzmi dobrze, dopóki nie przełoży się jej na minuty przestoju i nie spojrzy na definicję tego, co jest liczone jako „niedostępność”. Bez kilku doprecyzowań taki parametr jest praktycznie bezwartościowy.
Przy definiowaniu dostępności należy jednoznacznie ustalić:
Okres referencyjny – czy dostępność jest liczona miesięcznie, kwartalnie, czy rocznie? Im dłuższy okres, tym łatwiej „rozmyć” pojedynczą, bolesną awarię.
Zakres godzin – czy dostępność dotyczy 24/7, czy tylko godzin pracy użytkowników (np. 7:00–18:00 w dni robocze)? Firmy handlowe i produkcyjne często pracują zmianowo, co wymusza szersze okno.
Co jest uznawane za niedostępność – czy chodzi tylko o całkowitą awarię, czy także poważne spadki wydajności (np. czas odpowiedzi powyżej określonego progu)?
Wyłączenia – planowane prace serwisowe, awarie po stronie klienta (np. sieć, VPN), działania osób trzecich. Jeśli wyłączenia są opisane zbyt szeroko, realna gwarancja dostępności znika.
Bez wskazania, jak będą mierzone okresy niedostępności (logi systemowe, monitoring dostawcy, narzędzia klienta), dyskusja o „niespełnionej dostępności” kończy się zwykle sporem o dane. Rozsądną praktyką jest uzgodnienie narzędzia referencyjnego i sposobu udostępniania raportów (np. miesięczne raporty z uptime).
Czas reakcji a czas przywrócenia działania – dwa różne zobowiązania
W zapisach SLA pojawiają się zwykle dwa kluczowe parametry: czas reakcji (response time) i czas przywrócenia działania (resolution/restore time). Czas reakcji to moment od zgłoszenia do pierwszego potwierdzenia i podjęcia działań, natomiast czas przywrócenia to moment, kiedy system znów działa w uzgodnionym zakresie.
Umowy często eksponują bardzo atrakcyjne czasy reakcji (np. 15 minut dla P1), ale nie definiują jasno czasu naprawy. To klasyczna pułapka – klient ma poczucie, że problem jest „zaopiekowany”, ale realny przestój trwa godziny lub dni.
Przy określaniu tych parametrów przydaje się rozdzielenie ich na poziomy priorytetów:
P1 – krytyczne (brak możliwości pracy kluczowych procesów, np. sprzedaż, księgowość, produkcja) – zwykle wymagają bardzo krótkiego czasu reakcji (kilkanaście minut) i twardego zobowiązania czasu przywrócenia (np. do kilku godzin) lub przynajmniej zastosowania procedury awaryjnej.
P2 – wysoki (istotne utrudnienia, ale istnieje obejście) – czasy mogą być dłuższe, ale nadal mierzalne (np. reakcja w 1–2 godziny, naprawa w 1–2 dni robocze).
P3/P4 – średnio-niski (błędy kosmetyczne, pytania, drobne usterki) – często bez twardego czasu naprawy, ale z deklaracją maksymalnego czasu podjęcia analizy.
Dobrą praktyką jest opisanie nie tylko czasu „pełnego” rozwiązania, ale także czasu na tymczasowe obejście (workaround), które pozwala kontynuować kluczowe działania biznesowe, zanim zostanie wdrożona docelowa poprawka.
Priorytety zgłoszeń i kto je nadaje
Konflikt interesów pojawia się natychmiast po pierwszej poważniejszej awarii: klient ocenia zgłoszenie jako krytyczne, dostawca – jako średnie. Jeśli w umowie brak jasnych kryteriów przydzielania priorytetów, górę bierze „uznaniowość”.
Aby tego uniknąć, użyteczne jest zdefiniowanie:
opisów priorytetów powiązanych z wpływem na procesy (np. P1 = brak możliwości wystawiania dokumentów sprzedaży dla całej organizacji),
przykładów sytuacji przypisanych do każdego priorytetu,
procedury zmiany priorytetu (np. po stronie opiekuna klienta przy eskalacji).
W części firm sprawdza się także matryca wpływu i pilności (impact/urgency), na podstawie której system helpdesku automatycznie wylicza priorytet. Takie podejście ogranicza przestrzeń do sporu „to krytyk czy nie”.
Okna serwisowe i prace planowe
Dostawca musi mieć czas na wykonywanie aktualizacji, kopii bezpieczeństwa, zmian konfiguracyjnych po swojej stronie. Jeśli okna serwisowe są definiowane zbyt szeroko („w każdą sobotę 0:00–12:00 system może być niedostępny”), to użytkownicy weekendowi (np. magazyny, logistyka) realnie tracą fragment tygodnia pracy.
W umowie dobrze jest określić:
standardowe okno serwisowe (dzień tygodnia, godziny) oraz czy liczy się ono do SLA,
zasady planowania prac poza oknem (np. minimalny termin powiadomienia, zgoda klienta),
różnicę między pracami krytycznymi (np. łatki bezpieczeństwa) a pracami optymalizacyjnymi (np. zmiany wydajnościowe),
formę komunikacji (mail, portal, komunikat w systemie) i odpowiedzialność za poinformowanie użytkowników końcowych.
Bez takich ustaleń można spotkać się z sytuacją, w której technologicznie uzasadnione prace są wykonywane o godzinach dogodnych dla dostawcy, ale najmniej wygodnych dla organizacji klienta.
Kary umowne, rabaty SLA i realne egzekwowanie zapisów
Modele rekompensat za niedotrzymanie SLA
Same wskaźniki SLA bez mechanizmu rekompensaty są raczej deklaracją dobrej woli niż narzędziem zarządzania jakością usługi. W praktyce stosuje się kilka rozwiązań:
Rabaty na opłatę utrzymaniową/abonament – procentowe obniżenie opłaty (np. za dany miesiąc), zależne od poziomu niewykonania SLA.
Ryzyko po stronie dostawcy (service credits) – przyznawanie „kredytów serwisowych”, które można wykorzystać na dodatkowe godziny prac rozwojowych lub konsultingowych.
Kary umowne kwotowe – określona kwota za każde naruszenie lub za przekroczenie progu (np. trzy poważne incydenty miesięcznie).
Przy ustalaniu mechanizmu rekompensat sensowne jest powiązanie go z realną szkodą biznesową. W usługach krytycznych (system obsługujący sprzedaż) zbyt niskie kary są po prostu ignorowane – dostawca akceptuje ich ryzyko, bo bardziej opłaca się zapłacić niż inwestować w stabilność.
Minimalne progi i limity odpowiedzialności
W umowach spotyka się progi, od których zaczyna się naliczać karę, oraz limity odpowiedzialności dostawcy. Np. kary przysługują dopiero wtedy, gdy dostępność spadnie poniżej określonego poziomu przez co najmniej dwa kolejne miesiące, a łączna kwota kar nie przekroczy wielokrotności miesięcznego abonamentu.
Takie zapisy same w sobie nie są niczym złym, ale jeśli zostaną przeskalowane, stają się w praktyce „bezpiecznikiem” dla dostawcy, wygaszającym odpowiedzialność. Powinny być oceniane z perspektywy:
skali biznesu klienta (czy limit obejmuje choćby koszty jednego dnia przestoju),
roli systemu ERP w krytycznych procesach,
potencjalnych roszczeń ubezpieczeniowych i ich relacji do umownych limitów.
Niektóre organizacje decydują się na rozdzielenie odpowiedzialności: odszkodowania za szkody pośrednie i utracone korzyści są wyłączone, ale kary umowne i rabaty SLA są skonstruowane w sposób realnie motywujący do utrzymania jakości usług.
Procedura ustalania naruszenia SLA
Sam zapis o karach nie wystarcza – potrzebny jest także opis procedury, według której strony ustalą, czy SLA zostało naruszone. Typowe elementy to:
źródło danych (system monitoringu, logi aplikacyjne, rejestr zgłoszeń),
termin przekazania raportu przez dostawcę (np. do 10. dnia kolejnego miesiąca),
czas na zgłoszenie zastrzeżeń przez klienta,
sposób rozstrzygania sporów (np. analityk po stronie klienta vs. inżynier po stronie dostawcy, ewentualnie ekspert zewnętrzny).
W firmach, które poważnie podchodzą do zarządzania usługą ERP, cykliczne przeglądy SLA są elementem stałego rytmu współpracy z dostawcą (np. comiesięczne lub kwartalne spotkania operacyjne), a nie jedynie zapisami na papierze.
Kary finansowe a poprawa jakości usług
Nawet dobrze skonstruowane kary nie zastąpią mechanizmu ciągłego doskonalenia usług. W praktyce, aby SLA działało jako narzędzie poprawy jakości, potrzebne są:
analiza pierwotnych przyczyn awarii (root cause analysis) i wnioski na przyszłość,
plan działań naprawczych (technicznych i organizacyjnych),
śledzenie wskaźników trendu (liczba incydentów P1, średni czas naprawy, powtarzalność problemów).
Bez tego kary stają się podatkiem za niską jakość, a nie bodźcem do jej podniesienia. Dobrze opisane raportowanie powdrożeniowe i mechanizm RCA można wpisać do załączników umowy jako obowiązkowy element obsługi incydentów krytycznych.
Źródło: Pexels | Autor: RDNE Stock project
Serwis i wsparcie powdrożeniowe: zakres, godziny, kanały kontaktu
Zakres usług serwisowych – co jest „w cenie”, a co poza nią
Po zakończeniu projektu wdrożeniowego ERP wchodzi w fazę „życia codziennego”. To wtedy najbardziej widać, jak zdefiniowany został serwis. Bez szczegółowego zakresu część oczekiwań klienta okazuje się „dodatkowymi pracami” wycenianymi osobno.
Przy określaniu zakresu wsparcia powdrożeniowego warto rozróżnić:
utrzymanie bieżącej konfiguracji (np. korekta błędnego parametru, dodanie użytkownika, zmiana słownika),
naprawę błędów (bugfixing) – zarówno w standardzie systemu, jak i w elementach dostosowanych przez dostawcę,
drobne zmiany (np. dodanie pola na istniejącym raporcie) – często do określonego limitu godzin miesięcznie,
prace projektowe – większe modyfikacje, które zawsze wymagają osobnej wyceny i harmonogramu.
Bez takiego podziału użytkownicy traktują każde zgłoszenie jako „serwis”, podczas gdy dostawca na część zadań patrzy jak na mini-projekt. To rodzi frustrację i opóźnienia, bo pojawia się warstwa uzgodnień handlowych przed rozpoczęciem realnych prac.
Godziny świadczenia wsparcia i obsługa sytuacji wyjątkowych
Standardowe godziny wsparcia (np. 8:00–16:00 w dni robocze) są wystarczające w organizacjach, które funkcjonują w podobnych widełkach czasowych. W firmach produkcyjnych, centrach logistycznych czy sieciach detalicznych taki model bywa jednak niewystarczający.
W umowie można przewidzieć różne warianty:
wsparcie podstawowe w godzinach pracy firmy,
dyżury rozszerzone (np. 6:00–22:00) dla awarii krytycznych,
dyżury weekendowe lub świąteczne, uruchamiane na wniosek klienta w określonych okresach (np. inwentaryzacje, zamknięcia miesiąca, szczyty sprzedażowe).
Przydatna jest również procedura zgłoszeń poza standardowymi godzinami: dedykowany numer telefonu, kolejka „emergency” na portalu serwisowym, czy obowiązek oddzwonienia w określonym czasie. Bez tego użytkownicy po prostu nie wiedzą, czy mają czekać do rana, czy próbować szukać obejść na własną rękę.
Kanały kontaktu i wymagane informacje w zgłoszeniu
Im bardziej usystematyzowany sposób zgłaszania problemów, tym szybciej można przejść do ich rozwiązywania. Minimalny zestaw uzgodnień obejmuje:
dozwolone kanały zgłoszeń (portal, e-mail, telefon) i ich przeznaczenie,
wymagane dane przy zgłoszeniu (opis, moduł, użytkownik, krok reprodukcji, zrzuty ekranu, logi),
zasady przyjmowania zgłoszeń zbiorczych (np. ten sam problem zgłaszany przez wielu użytkowników).
W praktyce niedokładne zgłoszenia („nie działa sprzedaż”) spowalniają proces już na starcie, bo serwis wraca z pytaniami. W niektórych organizacjach opłaca się formalnie wyznaczyć koordynatorów kluczowych obszarów (Key Users), którzy filtrują i porządkują zgłoszenia przed przekazaniem ich do dostawcy. Taka rola również może zostać opisana w umowie lub w załączniku organizacyjnym.
Eskalacja problemów i rola opiekuna klienta
Nawet najlepiej opisane SLA nie zastąpi zdrowego mechanizmu eskalacji, kiedy problem zaczyna mieć wymiar biznesowo-krytyczny. W zapisach umowy można przewidzieć:
poziomy eskalacji (service desk → kierownik serwisu → kierownictwo dostawcy),
Raportowanie jakości serwisu i przeglądy operacyjne
Sam system zgłoszeń to za mało, jeśli nie ma nad nim „parasola” w postaci cyklicznego raportowania i przeglądów współpracy. W umowie można wprost opisać:
częstotliwość raportów (miesięczna, kwartalna),
zakres raportu (liczba incydentów wg priorytetów, średni czas reakcji i naprawy, najczęstsze obszary problemów),
skład i forma spotkań przeglądowych (komitet sterujący, spotkanie operacyjne, warsztat techniczny),
sposób dokumentowania ustaleń (protokół, rejestr działań korygujących).
Dobrze dopisany jest także obowiązek utrzymywania przez dostawcę katalogu znanych problemów i obejść (known issues, workarounds), do którego dostęp ma zespół klienta. Dzięki temu serwis nie odpowiada w kółko na te same pytania, a użytkownicy szybciej radzą sobie z drobnymi utrudnieniami.
Praktycznym elementem jest też rozróżnienie raportowania operacyjnego (wskaźniki dzień po dniu) od raportowania trendów (kwartał do kwartału). Pierwsze służy bieżącej kontroli SLA, drugie – decyzjom o inwestycjach w stabilizację lub rozwój systemu.
Aktualizacje, upgrade’y i rozwój ERP – co musi być zapisane w umowie
Rodzaje zmian w systemie i ich konsekwencje dla umowy
„Aktualizacja” w ERP może oznaczać łatkę usuwającą błąd, nową wersję modułu finansowego albo pełny skok wersji całej platformy. Dobrze jest wprowadzić do umowy rozróżnienie:
poprawki utrzymaniowe (hotfix, patch) – drobne wydania usuwające konkretne błędy,
aktualizacje funkcjonalne mniejsze (minor release) – pakiety zmian nieingerujące radykalnie w architekturę,
upgrade’y główne (major release) – przejście na nową wersję systemu, często z koniecznością migracji danych i testów regresyjnych,
rozwój indywidualny – zmiany szyte na miarę, projektowane wyłącznie dla danego klienta.
Od tego podziału zależy, co jest w cenie utrzymania, a co traktowane jest jak osobny projekt. Brak takich definicji kończy się sporem: dostawca uznaje przejście na nową wersję za przedsięwzięcie projektowe, a klient spodziewa się „automatycznej” aktualizacji w ramach abonamentu.
Częstotliwość i tryb udostępniania aktualizacji
Systemy ERP są dziś rozwijane w różnych rytmach: od kwartalnych pakietów zmian po niemal ciągły strumień drobnych usprawnień. W umowie opłaca się doprecyzować:
jak często dostawca publikuje standardowe aktualizacje,
czy klient ma obowiązek przechodzić na każdą wersję, czy może pomijać wybrane wydania,
jak długo wspierane są starsze wersje (okres „support window”),
czy istnieją „wersje LTS” (long term support) z dłuższym okresem wsparcia kosztem mniejszej liczby nowych funkcji.
W organizacjach regulowanych (finanse, farmacja, energetyka) zbyt częste zmiany są ryzykowne ze względu na konieczność ponownej walidacji procesów. Jeśli dostawca wymusza częste aktualizacje, musi to iść w parze z jasno opisanym procesem testów i migracji.
Środowiska testowe i obowiązek testów po stronie klienta
Żadna poważna aktualizacja ERP nie powinna trafiać wprost na produkcję. Umowa powinna rozstrzygać kilka kwestii:
kto utrzymuje środowiska testowe i pre‑produkcyjne (dostawca czy klient),
czy ich koszt jest wliczony w abonament, czy wymaga dodatkowej opłaty,
jak wyglądają zasady odświeżania danych testowych (anonimizacja, częstotliwość kopiowania z produkcji),
jakie są obowiązki testowe stron (zakres testów technicznych dostawcy vs. testów biznesowych użytkowników).
Nierzadko w regulacjach wewnętrznych pojawia się zapis „dostawca gwarantuje, że aktualizacja nie wpłynie negatywnie na system”. W praktyce bez zaangażowania key userów po stronie klienta taki zapis jest martwy – dostawca może przetestować standard, ale nie zna wszystkich lokalnych konfiguracji i obejść. Rozsądniejszym rozwiązaniem jest formalne określenie okien testowych i osób odpowiedzialnych za akceptację wersji.
Kompatybilność z modyfikacjami i rozszerzeniami
Im bardziej system jest zmodyfikowany, tym większe ryzyko, że standardowa aktualizacja „rozjedzie” część funkcji. W umowie przydaje się kilka prostych reguł:
podział na modyfikacje utrzymywane przez producenta (np. oficjalne dodatki, rozszerzenia marketplace) i modyfikacje niestandardowe wykonane tylko dla danego klienta,
zasada, że w przypadku kolizji aktualizacji ze standardowym dodatkiem odpowiedzialność za dostosowanie leży po stronie dostawcy w ramach utrzymania,
zasady postępowania przy kolizjach z modyfikacjami szytymi na miarę – np. osobna wycena prac adaptacyjnych albo z góry zdefiniowany pakiet godzin na „re‑fit” po upgrade’ach.
Dobrym kompromisem jest katalog modyfikacji „certyfikowanych pod upgrade”, dla których dostawca deklaruje kompatybilność z kolejnymi wersjami, oraz modyfikacji „na własne ryzyko”, wymagających każdorazowej analizy.
Prawo do nowych funkcji i modułów
Nie każdy model licencyjny gwarantuje dostęp do wszystkich nowinek. W umowie należy rozdzielić:
aktualizacje tej samej edycji (np. nowe raporty w zakupionym module finansowym),
nowe moduły i produkty (np. WMS, CRM, APS),
funkcje dostępne tylko w wyższej półce produktowej (edition),
opcje dodatkowo płatne (np. zaawansowana analityka, AI, integracje zewnętrzne).
Dobrą praktyką jest zapis, że w ramach opłaty utrzymaniowej klient otrzymuje wszystkie funkcje rozwijane w ramach posiadanych modułów, a przejście na wyższą edycję lub dołożenie nowego modułu wymaga odrębnej oferty. Minimalizuje to rozczarowanie w stylu: „funkcja została pokazana na webinarze, ale jest tylko w wersji premium, której nie mamy”.
„Aktualizacje regulacyjne” i ich priorytet
W wielu krajach producent ERP cyklicznie publikuje zmiany wynikające z nowych przepisów (VAT, JPK, e‑fakturowanie, sprawozdawczość). Dla klienta to często kwestia ciągłości prawnej, więc w umowie powinny się znaleźć:
definicja, co traktowane jest jako aktualizacja regulacyjna,
termin jej udostępnienia po publikacji oficjalnych wymogów (np. X dni roboczych przed wejściem przepisów w życie),
zasady testów i odpowiedzialności za prawidłową konfigurację,
priorytet obsługi incydentów wynikających z aktualizacji regulacyjnej (zwykle najwyższy).
Jeśli system obsługuje wiele krajów, dochodzi jeszcze kwestia kolejności wdrożeń dla poszczególnych jurysdykcji. Dla grup kapitałowych działających międzynarodowo to nie jest detal, ale element zarządzania ryzykiem prawnym.
Modele licencjonowania i utrzymania ERP a treść umowy
On‑premise, hosting, SaaS – różne rozkłady odpowiedzialności
Model techniczny wdrożenia bezpośrednio wpływa na to, co faktycznie można zapisać w umowie utrzymaniowej. W uproszczeniu:
On‑premise – klient odpowiada za infrastrukturę (serwery, sieć, kopie zapasowe), a dostawca za aplikację i konfigurację; SLA obejmuje zwykle wyłącznie warstwę systemu ERP.
Hosting / IaaS – część odpowiedzialności przejmuje operator centrum danych lub chmury, dochodzi drugie SLA (na infrastrukturę), które trzeba zgrać z SLA aplikacyjnym.
SaaS – dostawca bierze na siebie całą „piramidę” (infrastruktura + aplikacja), a klient zarządza użytkownikami, danymi i procesami.
Jeśli ERP jest on‑premise, a serwery stoją w serwerowni klienta, dostawca nie powinien podpisywać się pod 99,9% dostępności, o ile nie ma wpływu na zasilanie, sieć czy kopie zapasowe. W modelu SaaS/hostingowym brak takiego zapisu może być z kolei czerwoną flagą, bo cała odpowiedzialność leży de facto po stronie dostawcy.
Licencje wieczyste a subskrypcje
Model licencji wieczystej z roczną opłatą utrzymaniową różni się od subskrypcji (abonament, SaaS) nie tylko finansowo, ale i prawnie. Umowa powinna wskazywać m.in.:
czy opłata utrzymaniowa jest obowiązkowa, aby otrzymywać aktualizacje i wsparcie,
co się dzieje po jej zaprzestaniu (prawo do korzystania z ostatniej wersji, brak wsparcia, brak aktualizacji regulacyjnych),
w subskrypcji – co dzieje się z dostępem po wypowiedzeniu (czas na migrację, tryb dostępu „read‑only”).
W licencji wieczystej dostawca czasem rezerwuje sobie prawo do zakończenia wsparcia dla danej wersji po kilku latach. Jeśli system jest krytyczny, dobrze rozważyć w kontrakcie scenariusz „końca życia produktu”: preferencyjne warunki migracji, dłuższy okres wsparcia odpłatnego, dostęp do dokumentacji umożliwiającej samodzielne utrzymanie.
„Vendor lock‑in” i prawa do konfiguracji oraz rozszerzeń
Przy modelu chmurowym i zamkniętych platformach problemem staje się uzależnienie od jednego dostawcy. W treści umowy opłaca się przeanalizować:
kto ma prawa autorskie majątkowe do rozszerzeń i modyfikacji (dostawca, klient, współwłasność),
czy klient ma prawo przenieść te modyfikacje na inną instancję lub do innego partnera wdrożeniowego,
jakie formaty eksportu konfiguracji i danych są wspierane (otwarte vs. zamknięte),
czy jest formalny zakaz świadczenia usług przez konkurencyjnych integratorów na tym samym systemie.
Jeśli dostawca zastrzega, że jedynie on może rozwijać i serwisować system, to w praktyce definiuje maksymalną siłę przetargową klienta przy renegocjacji stawek utrzymania. Nie zawsze da się tego uniknąć, ale warto mieć świadomość konsekwencji.
Elastyczność skalowania licencji
W szczególności w subskrypcjach liczba użytkowników, modułów czy mocy obliczeniowej zmienia się wraz z rozwojem firmy. Umowa powinna zawierać konkrety:
minimalne i maksymalne progi licencyjne,
terminy zgłaszania zmian (np. do 15. dnia miesiąca na kolejny okres rozliczeniowy),
zasady rozliczania sezonowych wzrostów (np. użytkownicy tymczasowi, licencje „floating”),
ewentualne rabaty za wzrost wolumenów oraz konsekwencje spadku (czy można zejść z licencji bez kary).
Dla firm sezonowych (handel, logistyka) sztywne podejście typu „tylko wzrost, brak możliwości spadku” prowadzi do przepłacania w spokojniejszych okresach. Lepiej wynegocjować mechanizm stopniowego skalowania w dół, nawet jeśli wymaga to dłuższych okresów wypowiedzenia dla części licencji.
Czas trwania umowy i warunki jej wypowiedzenia
Model licencjonowania łączy się bezpośrednio z długością zobowiązania. Trzeba jasno określić:
okres początkowy (np. 3 lata) i zasady automatycznego przedłużania,
prawo do wypowiedzenia z ważnych powodów (istotne naruszenie SLA, brak wsparcia regulacyjnego, zaprzestanie rozwoju produktu),
procedurę zakończenia współpracy (patrz niżej: dane, konfiguracje, dostęp „read‑only”).
Przy długich kontraktach subskrypcyjnych zabezpieczeniem po stronie klienta bywa gwarancja maksymalnej podwyżki (cap na wzrost cen rok do roku) oraz prawo do renegocjacji warunków przy istotnej zmianie modelu produktu (np. przejście na inną platformę technologicznie).
Bezpieczeństwo
Zakres odpowiedzialności za bezpieczeństwo danych i systemu
W kontekście ERP bezpieczeństwo obejmuje zarówno warstwę techniczną, jak i organizacyjną. W umowie należy odróżnić:
Na co zwrócić uwagę w umowie SLA przy wyborze systemu ERP?
W SLA kluczowe są konkretne, mierzalne parametry: poziom dostępności systemu (np. 99,5% miesięcznie), czasy reakcji i czasy usunięcia awarii dla różnych priorytetów zgłoszeń, godziny pracy serwisu (8/5, 12/5, 24/7) oraz opis kanałów kontaktu. Te elementy powinny być zapisane liczbowo, a nie w formie ogólników typu „niezwłocznie” czy „jak najszybciej”.
Istotne jest też rozróżnienie, czego SLA nie obejmuje: zwykle nie obejmuje prac rozwojowych, szkoleń czy dużych upgrade’ów. Jeśli firma oczekuje np. gwarantowanego czasu realizacji zmian konfiguracyjnych, trzeba to dopisać wprost do umowy lub osobnego załącznika.
Jaka jest różnica między gwarancją, serwisem a utrzymaniem systemu ERP?
Gwarancja dotyczy zazwyczaj okresu po wdrożeniu i obejmuje usuwanie błędów wynikających z niezgodności systemu z umową lub dokumentacją. Zwykle jest ograniczona czasowo (np. 3–12 miesięcy) i nie obejmuje zmian wynikających z nowych potrzeb biznesowych.
Utrzymanie (maintenance) to bieżąca opieka nad systemem w długim okresie: aktualizacje, poprawki, wsparcie serwisowe według SLA. Serwis to faktyczne reagowanie na zgłoszenia, diagnoza problemów i przywracanie działania systemu. Rozwój i konsulting to osobny obszar – nowe funkcje, raporty, integracje czy doradztwo procesowe są zwykle rozliczane jako dodatkowe usługi poza standardowym utrzymaniem.
Jak model wdrożenia (on-premise vs chmura) wpływa na treść umowy ERP?
W modelu on-premise klient odpowiada za infrastrukturę (serwery, sieć, backupy), a dostawca za oprogramowanie i wsparcie aplikacyjne. Umowa powinna jasno wskazywać, że SLA dotyczy tylko warstwy aplikacyjnej, a przestoje wynikające np. z awarii sprzętu po stronie klienta nie są objęte odpowiedzialnością dostawcy ERP.
W modelu chmurowym (SaaS) większość warstw jest po stronie dostawcy lub jego podwykonawców. Umowa musi więc rozdzielać SLA dla aplikacji ERP i SLA dla infrastruktury chmurowej (np. data center, łącza). W rozwiązaniach hybrydowych dochodzi jeszcze kwestia integracji i łącz sieciowych między lokalizacjami – tu potrzebny jest bardzo precyzyjny podział odpowiedzialności, aby uniknąć sytuacji „nikt nie jest winny” przy awarii.
Jak umowa ERP wpływa na całkowity koszt posiadania (TCO) systemu?
Na TCO wpływają m.in. zapisy dotyczące aktualizacji, indeksacji opłat, warunków skalowania i dodatkowych usług. Przykład: zapis „aktualizacje w cenie utrzymania” może oznaczać wyłącznie poprawki błędów, a większe upgrade’y będą wyceniane osobno. Brak ograniczeń indeksacji opłat za utrzymanie może podnieść koszty po 2–3 latach o kilkadziesiąt procent.
Warto też zwrócić uwagę na warunki rozszerzania licencji (nowi użytkownicy, moduły, spółki) oraz cennik prac serwisowych poza SLA. Jeśli umowa jest ogólnikowa, każdy niestandardowy ruch – nowy oddział, integracja, zmiana procesów – może oznaczać kosztowną, jednostkową wycenę i trudne negocjacje.
Co koniecznie musi być zapisane w umowie na ERP, żeby dało się to wyegzekwować?
Wszystko, co jest dla firmy krytyczne, powinno znaleźć odzwierciedlenie w paragrafach lub załącznikach. Dotyczy to w szczególności: parametrów SLA (dostępność, czasy reakcji i naprawy), zakresu wsparcia serwisowego, polityki aktualizacji, zasad backupu i odtwarzania, sposobu raportowania SLA, a także zasad rozwoju systemu (stawki, tryb zlecania prac, terminy).
Dość często pomijane są kwestie takie jak: dostęp do środowisk testowych, zakres szkoleń powdrożeniowych, wsparcie przy kontrolach podatkowych i audytach, warunki migracji danych i dostępu do kopii baz danych przy zakończeniu współpracy. Jeśli tego nie ma w umowie, w praktyce jest to „usługa dodatkowa” na warunkach dyktowanych przez dostawcę.
Jak uniknąć pułapek „okazyjnej” umowy na ERP bez doprecyzowanego wsparcia?
Jeśli oferta wydaje się bardzo atrakcyjna cenowo, a w umowie pojawiają się jedynie ogólne sformułowania typu „wsparcie w standardowych godzinach pracy” i „aktualizacje zgodne z polityką producenta”, to sygnał ostrzegawczy. Trzeba domagać się szczegółowego załącznika SLA z priorytetami zgłoszeń, gwarantowanymi czasami reakcji i naprawy oraz jasnym określeniem, co jest w cenie, a co płatne dodatkowo.
Dobrym podejściem jest symulacja kilku realistycznych scenariuszy: poważna awaria blokująca sprzedaż, nagła potrzeba integracji z nowym systemem, otwarcie nowej spółki. Na tej podstawie można sprawdzić, jak zadziałałyby obecne zapisy umowy i jakie dodatkowe koszty firma mogłaby ponieść. Jeśli odpowiedź dostawcy brzmi „to ustalimy później”, warto doprecyzować to już teraz w umowie.
Kluczowe Wnioski
Umowa na ERP musi być przygotowywana równolegle z wyborem systemu i dostawcy – kluczowe wymagania (SLA, wsparcie, aktualizacje, rozwój) powinny trafić do załączników kontraktu, inaczej pozostają tylko obietnicą handlową.
Zapisy umowy bezpośrednio kształtują całkowity koszt posiadania (TCO): nieprecyzyjne pojęcia typu „aktualizacje w cenie utrzymania” czy „wsparcie serwisowe” często oznaczają minimum działań, rosnące opłaty i dodatkowe faktury przy każdej niestandardowej sytuacji.
Kontrakt decyduje o elastyczności ERP w długim okresie – brak jasnych zasad skalowania licencji, rozszerzania modułów czy migracji danych może doprowadzić do „uwięzienia” u jednego dostawcy, gdy firma się rozrośnie lub zmieni model działania.
Model wdrożenia (on‑premise, chmura, hybryda) wymusza inny podział odpowiedzialności; jeśli nie zdefiniuje się granularnie, kto odpowiada za infrastrukturę, aplikację, integracje, łącza i backupy, realne SLA staje się fikcją.
W hybrydach szczególnie ważne jest rozpisanie „szwów” pomiędzy środowiskami – w przeciwnym razie przy awarii każdy podmiot przerzuca winę dalej, a firma zostaje z niedziałającym systemem i bez jasnej ścieżki eskalacji.
Czegokolwiek nie ma w umowie (np. czas reakcji, podział priorytetów zgłoszeń, zakres szkoleń, dostęp do środowisk testowych, wsparcie przy kontrolach), tego w praktyce nie da się skutecznie egzekwować – zostaje jedynie „dobra wola” dostawcy.
Opracowano na podstawie
ISO/IEC 20000-1:2018 Information technology — Service management — Part 1: Service management system requirements. International Organization for Standardization (2018) – Norma zarządzania usługami IT, podstawy SLA i odpowiedzialności
ITIL Foundation ITIL 4 Edition. AXELOS (2019) – Najważniejsze pojęcia ITSM, SLA, wsparcie, dostępność usług IT
Umowy w projektach IT. Przewodnik dla zamawiających i wykonawców. Wolters Kluwer Polska (2021) – Polskie opracowanie o kontraktach IT, SLA, odpowiedzialności i ryzyku
ERP: Making It Happen – The Implementers’ Guide to Success with Enterprise Resource Planning. John Wiley & Sons (2000) – Praktyczne aspekty wdrożeń ERP, ryzyka kontraktowe i organizacyjne
