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