Umowa wdrożeniowa SLA na system ERP. Co musisz sprawdzić przed podpisaniem? 

Wybrałeś już system ERP? Świetnie, ale to dopiero połowa sukcesu. Prawdziwe bezpieczeństwo gwarantuje dobrze skonstruowana umowa SLA. Nie powinna ona chronić wyłącznie przyszłego dostawcę, lecz przede wszystkim Twoją firmę. Wyjaśniamy z naszej perspektywy, na jakie kwestie szczególnie warto być uczulonym na etapie podpisywania kontraktu.  

Umowa SLA (Service Level Agreement) często bywa określana mianem umowy serwisowej systemu. Definiuje ona przedmiot umowy (np. system ERP), a także katalog określonych usług realizowanych w celu utrzymania i systematycznego poprawiania tegoż przedmiotu. Dlatego SLA często obejmuje usługi w zakresie naprawy błędów, aktualizacji czy konsultingu. 

Każda umowa powinna zawierać konkretne, mierzalne parametry. Nie powinny być zapisane ogólnikowo, lecz liczbowo. W kontekście systemu ERP do takich kwestii należą m.in. czasy reakcji, godziny pracy serwisu, poziom dostępności systemu czy opis kanałów kontaktu. W SLA powinny również być zapisane zasady dotyczące backupu danych oraz rozwoju systemu – z jasnym określeniem, co jest “w pakiecie”, a co za dodatkową opłatą. 

Ważnym czynnikiem, który wpływa na warunki umowy, jest model wdrożenia systemu ERP. W modelu on-premise, w którym to klient odpowiada za infrastrukturę, odpowiedzialność dostawcy ogranicza się wyłącznie do wsparcia aplikacyjnego. Dlatego w umowie SLA nie znajdą się informacje o wsparciu w momencie, gdy sprzęt klienta ulegnie awarii.  

Inaczej sytuacja wygląda w przypadku modelu chmurowego (SaaS), gdzie dostawca przejmuje większą odpowiedzialność za oprogramowanie ERP. Wówczas umowa musi rozdzielać SLA dla aplikacji oraz infrastruktury chmurowej (np. data center). Szczegóły dotyczące wsparcia ze strony partnera wdrożeniowego powinny być obowiązkowym elementem dokumentu. 

Analiza przedwdrożeniowa nie jest jedynie formalnością do odhaczenia w trakcie projektu. To błąd, który na późniejszych etapach odbija się na harmonogramie i budżecie. Dlatego rzetelna analiza potrzeb i dotychczasowych procesów biznesowych powinna zostać przeprowadzona jeszcze przed złożeniem podpisu na umowie. 

Podobnie sprawa wygląda ze szkoleniami wstępnymi dla pracowników. Rekomendujemy, aby zorganizować je przed startem wdrożenia. Dlaczego to takie istotne? Nie tylko ze względu na komfort pracowników i budowę świadomości zmiany. Warsztaty przedwdrożeniowe pozwalają zweryfikować, czy system rzeczywiście odpowiada na codzienne potrzeby zespołu. Na ich podstawie można także wychwycić rozbieżności między oczekiwaniami klienta a możliwościami dostawcy, zanim staną się one przedmiotem sporu.  

Jak wspomnieliśmy wyżej, diabeł tkwi w szczegółach. Umowa powinna jasno wskazywać, co wchodzi w skład wdrożenia, a co nie. Równie istotna jest procedura akceptacji poszczególnych etapów wdrożenia. SLA ma określać: 

• Kto i w jakim terminie odbiera dany etap (sprint, moduł, funkcjonalność), 
• Jakie kryteria muszą zostać spełnione, aby etap uznać za zakończony,  
• Co się dzieje, gdy klient zgłasza zastrzeżenia - jak przebiegają poprawki i ponowna akceptacja.  

Osobnym zagadnieniem jest zmiana zakresu wdrożenia. Bardzo często w trakcie realizacji projektu pojawiają się nowe potrzeby lub pomysły na modyfikację systemu. Umowa powinna z góry określać zasady rozliczania takich zmian – najlepiej w formie jasno opisanej procedury, wraz ze stawkami za dodatkowe prace.  

SLA ma również odpowiadać na kwestię harmonogramu – czy i w jaki sposób modyfikacje wpływają na pierwotny termin oddania systemu. Brak takiego zapisu prowadzi zwykle do sytuacji, w której klient oczekuje dotrzymania daty wejścia w go-live mimo rozszerzenia zakresu prac. Tymczasem dostawca może uznawać termin za automatycznie przesunięty.

Umowa SLA powinna precyzyjnie wskazywać osoby odpowiedzialne za projekt po obu stronach – najlepiej imiennie. Jeśli to niemożliwe, należy określić te osoby przynajmniej poprzez zdefiniowanie ról i kompetencji (np. project manager, konsultant wdrożeniowy, architekt systemu). 

Warto również zadbać o zapisy dotyczące rotacji kluczowych osób w zespole. Nagła zmiana project managera w połowie wdrożenia potrafi wywrócić harmonogram do góry nogami. Nowa osoba musi wdrożyć się w kontekst, co kosztuje cenny czas. Kary umowne za taką rotację (poza sytuacjami losowymi) skutecznie dyscyplinują dostawcę i zabezpieczają ciągłość projektu.  

Niemniej istotna jest transparentność stawek. Jeśli umowa przewiduje możliwość rozliczania dodatkowych prac godzinowo, klient powinien z góry znać stawki dla poszczególnych ról (tj. programista, konsultant, analityk), a nie dowiadywać się o nich dopiero z wystawionej faktury.  

Kluczowym elementem przy odbiorze systemu jest odpowiednie przekazanie wiedzy. Chodzi tu o szkolenia dla Key Userów, czyli pracowników, którzy później będą wspierać resztę zespołu w codziennej pracy z systemem. Umowa powinna określać liczbę godzin szkoleniowych oraz ich formę (stacjonarnie czy zdalnie).  

Drugą ważną kwestią są instrukcje stanowiskowe. Warto ustalić, czy dostawca przygotuje dedykowaną dokumentację dla konkretnych stanowisk pracy (np. dla pracownika magazynu), czy tylko ogólną dokumentację techniczną ERP. Ogólniki są zazwyczaj mało wystarczające dla pracowników operacyjnych, dlatego warto dopytać o lepszą personalizację materiałów.  

Często pomijana, a niezmiernie kluczowa sprawa, wiąże się z prawami autorskimi. Firma zamawiająca wdrożenie powinna precyzyjnie wiedzieć, czy i w jakim zakresie otrzymuje autorskie prawa majątkowe do stworzonego na jej potrzeby kodu, integracji czy modyfikacji. Ma to szczególne znaczenie w przypadku systemów dedykowanych. Bez odpowiednich zapisów firma może okazać się w praktyce zależna od jednego dostawcy również w zakresie dalszego rozwoju oprogramowania, nawet jeśli formalnie “zapłaciła” za jego stworzenie.  

Wdrożenie systemu to nie koniec współpracy z dostawcą, a jej początek w nowej odsłonie. Warto rozróżnić dwa pojęcia, które często są mylone: zwykłą umowę serwisową i pełne SLA. Umowa serwisowa zazwyczaj określa jedynie ogólne zasady wsparcia technicznego, tj. dostępność konsultanta czy zasady zgłaszania błędów. SLA natomiast to znacznie bardziej szczegółowy dokument, który precyzuje mierzalne parametry: 

• Czas reakcji na zgłoszenie (zależnie od jego priorytetu), 
• Czas usunięcia awarii, 
• Gwarantowana dostępność systemu (np. 99,5%), 
• Kary umowne za niedotrzymanie tych parametrów.  

Ważne: warunki umowy powdrożeniowej i SLA powinny zostać wynegocjowane już na etapie podpisywania umowy wdrożeniowej - a nie wtedy, gdy system jest już uruchomiony, a firma zdążyła się od niego uzależnić. To moment, w którym pozycja negocjacyjna klienta jest najsilniejsza. Po wdrożeniu, gdy codzienna praca firmy opiera się już na nowym systemie, negocjowanie korzystnych warunków wsparcia staje się dużo trudniejsze – dostawca wie, że klient nie ma realnej alternatywy w krótkim terminie.