Gdy w projekcie są trzy strony. Jak ułożyć odpowiedzialność w umowach wdrożeniowych opartych o rozwiązania SaaS?
Jeszcze kilka lat temu większość projektów wdrożeniowych miała stosunkowo prostą strukturę. Klient zawierał umowę z wykonawcą, który dostarczał i wdrażał system, a odpowiedzialność za powodzenie projektu była skupiona zasadniczo po jednej stronie.
Rozwój rozwiązań chmurowych oraz SaaS diametralnie zmienił ten model, aktualizując reguły negocjacyjnej „gry”. Coraz częściej bowiem wdrożenie opiera się na platformie dostarczanej przez globalnego producenta, podczas gdy sam projekt realizuje lokalny integrator. W efekcie w jednym przedsięwzięciu funkcjonują trzy niezależne podmioty: klient, integrator oraz producent platformy. Każdy z nich odpowiada za inny element projektu, a jednocześnie powodzenie wdrożenia zależy od ich ścisłej współpracy.
To właśnie w tym miejscu pojawiają się najciekawsze problemy kontraktowe. W klasycznych projektach wdrożeniowych najważniejsze było ustalenie, kto odpowiada za rezultat prac. W projektach opartych o rozwiązania SaaS coraz częściej ważniejsze staje się inne pytanie – jak zorganizować współpracę pomiędzy klientem, integratorem i producentem platformy.
To nie jest już klasyczne wdrożenie
Wiele umów wdrożeniowych nadal opiera się na założeniu, że wykonawca dostarcza system, wdraża go i odpowiada za jego działanie. Taki model coraz rzadziej odpowiada jednak rzeczywistości.
W projektach opartych o rozwiązania SaaS integrator najczęściej nie jest producentem oprogramowania. Platforma funkcjonuje już wcześniej, jest rozwijana przez globalnego dostawcę i udostępniana klientowi na podstawie odrębnej umowy subskrypcyjnej. Rolą integratora nie jest więc stworzenie systemu od podstaw, lecz jego właściwa konfiguracja, dostosowanie do procesów biznesowych klienta, integracja z pozostałymi systemami oraz bezpieczne przeprowadzenie całego procesu wdrożeniowego.
To zasadniczo zmienia sposób postrzegania odpowiedzialności.
Integrator nie powinien odpowiadać za rozwój platformy, jej dostępność czy wady standardowych funkcjonalności. Odpowiada natomiast za sposób wykorzystania tej platformy w konkretnym projekcie – za przyjęte rozwiązania konfiguracyjne, poprawność integracji, migrację danych, realizację uzgodnionego zakresu oraz koordynację procesu wdrożenia czy też customizację rozwiązania (w zakresie, w jakim ma możliwość jej wykonania).
W praktyce oznacza to, że umowa wdrożeniowa powinna odzwierciedlać rzeczywisty podział ról pomiędzy producentem platformy, integratorem i klientem. Próba przeniesienia na integratora odpowiedzialności za elementy pozostające poza jego kontrolą prowadzi nie tylko do trudnych negocjacji, ale przede wszystkim do niejasności w trakcie realizacji projektu.
Umowa wdrożeniowa nie może funkcjonować w oderwaniu od umowy subskrypcyjnej
W modelu SaaS integrator bardzo często nie jest stroną umowy dotyczącej korzystania z platformy. Klient zawiera odrębny kontrakt z producentem, regulujący m.in. licencje, poziom dostępności usług (SLA), wsparcie producenta czy warunki rozwoju platformy.
Jeżeli umowa wdrożeniowa pomija ten fakt, bardzo szybko pojawiają się pytania, na które trudno znaleźć jednoznaczną odpowiedź. Kto odpowiada za dobór odpowiedniej liczby licencji lub metryk? Kto ponosi ryzyko błędnego sizingu? Czy integrator odpowiada za globalną awarię platformy? Kto powinien zgłaszać błędy producentowi i prowadzić komunikację w toku ich usuwania?
To kwestie, które warto rozstrzygnąć już na etapie negocjacji. W praktyce oznacza to konieczność równoległego analizowania obu kontraktów. Postanowienia umowy wdrożeniowej nie mogą abstrahować od zakresu praw i obowiązków wynikających z umowy subskrypcyjnej, ponieważ dopiero oba dokumenty określają pełny model odpowiedzialności stron.
Granica między konfiguracją a produktem
W praktyce największe znaczenie ma właściwe określenie granicy pomiędzy odpowiedzialnością za konfigurację a odpowiedzialnością za sam produkt.
Jeżeli przyczyną problemu jest nieprawidłowo wykonana konfiguracja, błędna integracja lub niewłaściwie przygotowana migracja danych, odpowiedzialność integratora jest naturalna.
Inaczej wygląda sytuacja, gdy źródłem problemu okazuje się wada standardowej funkcjonalności platformy albo zmiana wprowadzona przez jej producenta. W takim przypadku integrator może wspierać klienta w analizie problemu, przygotowaniu zgłoszenia czy wdrożeniu rekomendowanego rozwiązania, jednak nie powinien ponosić odpowiedzialności za samą wadę produktu.
To rozróżnienie wydaje się oczywiste, ale w praktyce bardzo często nie znajduje odzwierciedlenia w treści umowy.
RACI to za mało
Macierze RACI doskonale porządkują odpowiedzialność operacyjną, ale nie rozwiązują problemów kontraktowych. Nawet najbardziej szczegółowy podział ról nie zastąpi postanowień regulujących sposób współpracy pomiędzy klientem, integratorem i producentem platformy.
W projektach opartych o rozwiązania SaaS samo przypisanie ról i odpowiedzialności nie wystarcza. Nawet najbardziej szczegółowa macierz RACI nie zagwarantuje powodzenia projektu, jeżeli umowa nie określa zasad współdziałania pomiędzy klientem, integratorem i producentem platformy.
To właśnie współdziałanie staje się jednym z kluczowych obowiązków stron. Klient powinien zapewnić terminowe podejmowanie decyzji biznesowych, dostęp do środowisk i odpowiednich osób, integrator – koordynację prac, komunikację techniczną oraz zarządzanie ryzykiem projektu, natomiast producent platformy – wsparcie w zakresie standardowych funkcjonalności i rozwoju produktu. W praktyce granice tych kompetencji często się przenikają, dlatego umowa powinna przewidywać nie tylko podział odpowiedzialności, ale również mechanizmy współpracy i eskalacji.
Dobrze przygotowany kontrakt odpowiada zatem nie tylko na pytanie „kto odpowiada?”, ale również „kto, z kim i w jaki sposób ma współpracować, aby problem został rozwiązany?”. W projektach SaaS to właśnie ta druga kwestia najczęściej decyduje o powodzeniu przedsięwzięcia.
Co istotne, obowiązek współdziałania nie kończy się z chwilą odbioru projektu. Wręcz przeciwnie – w modelu SaaS jego znaczenie często wzrasta po uruchomieniu systemu, gdy pojawiają się bieżące zgłoszenia, aktualizacje platformy i konieczność koordynacji działań pomiędzy wszystkimi uczestnikami projektu.
Wdrożenie i utrzymanie to dwa różne światy
Etap utrzymania różni się od wdrożenia nie tylko zakresem świadczonych usług, ale również modelem odpowiedzialności. Po zakończeniu projektu integrator przestaje być wyłącznie wykonawcą wdrożenia, a staje się partnerem wspierającym klienta w bieżącym funkcjonowaniu rozwiązania.
Nie oznacza to jednak, że powinien samodzielnie usuwać wszystkie problemy pojawiające się w trakcie eksploatacji systemu. W modelu SaaS część zagadnień pozostaje bowiem w wyłącznej kompetencji producenta platformy – dotyczy to w szczególności standardowych funkcjonalności, rozwoju produktu czy usuwania błędów samej platformy.
W praktyce rolą integratora jest często pełnienie funkcji Single Point of Contact (SPOC) dla klienta. To on dokonuje wstępnej analizy zgłoszeń, identyfikuje ich przyczynę, rozstrzyga, czy problem wynika z konfiguracji, integracji czy działania platformy, prowadzi komunikację z producentem oraz koordynuje proces usunięcia problemu. Nie zawsze jest więc podmiotem, który sam dokonuje naprawy, ale pozostaje odpowiedzialny za skuteczne przeprowadzenie klienta przez cały proces.
Taki model wymaga odpowiedniego odzwierciedlenia w umowie. Oprócz klasycznych postanowień dotyczących SLA czy czasów reakcji warto precyzyjnie określić zasady współpracy pomiędzy klientem, integratorem i producentem platformy, w tym sposób eskalacji zgłoszeń, zakres wsparcia świadczonego przez integratora oraz granice jego odpowiedzialności.
W praktyce to właśnie partnerska współpraca tych trzech podmiotów – a nie próba przeniesienia pełnej odpowiedzialności na jednego z nich – najczęściej decyduje o sprawnym funkcjonowaniu rozwiązania po zakończeniu wdrożenia.
Zamiast podsumowania – o czym warto pamiętać negocjując umowę wdrożeniową w modelu SaaS?
W projektach opartych o rozwiązania SaaS dobrze skonstruowana umowa powinna odpowiadać nie tylko na pytanie, kto za co odpowiada, ale również jak strony mają ze sobą współpracować. W praktyce warto zwrócić szczególną uwagę na następujące kwestie:
- precyzyjne wyznaczenie granicy odpowiedzialności pomiędzy integratorem a producentem platformy;
- spójność postanowień umowy wdrożeniowej z umową subskrypcyjną, tak aby oba kontrakty tworzyły jeden, konsekwentny model współpracy;
- określenie zasad obsługi i eskalacji zgłoszeń, w szczególności tych wymagających zaangażowania producenta platformy;
- ustalenie roli integratora po zakończeniu wdrożenia, w tym odpowiedź na pytanie, czy będzie pełnił funkcję Single Point of Contact (SPOC) dla klienta;
- wyraźne rozdzielenie zasad dotyczących wdrożenia i utrzymania, obejmujące odrębne obowiązki, procedury oraz zakres odpowiedzialności na każdym z tych etapów.
To właśnie te elementy coraz częściej decydują o tym, czy umowa będzie skutecznie wspierała realizację projektu, czy stanie się źródłem sporów już po jego uruchomieniu.
