Umowa z dostawcą systemu IT — na co zwrócić uwagę, zanim ją podpiszesz?
Jak pewnie wszyscy wiemy, wdrożenie systemu IT to dla wielu firm bardzo angażujące przedsięwzięcie pod kątem czasu, ale i finansów. Od jakości umowy z dostawcą zależy nie tylko powodzenie projektu, ale również bezpieczeństwo biznesowe organizacji na lata. Źle skonstruowana umowa może prowadzić do przekroczenia budżetu, opóźnień, sporów prawnych lub systemu, który nie spełnia realnych potrzeb firmy, a w ostateczności fiaska całego projektu.
Poniżej przedstawiam kilka punktów, na które warto zwrócić uwagę, zanim przejdziemy do podpisania umowy i rozpoczęcia prac w projekcie.
SLA - Service Level Agreement
SLA to jeden z najważniejszych elementów umowy, szczególnie gdy system ma kluczowe znaczenie dla ciągłości działania firmy. Powinien on precyzyjnie określać:
dostępność systemu (np. procent czasu działania w skali miesiąca),
maksymalny czas reakcji na zgłoszenie (response time),
maksymalny czas usunięcia awarii (resolution time),
klasyfikację incydentów według ich krytyczności,
kary umowne lub mechanizmy kompensacyjne za niedotrzymanie SLA.
Brak jednoznacznych wskaźników SLA lub ich ogólnikowe sformułowanie znacząco osłabia pozycję zamawiającego w przypadku problemów operacyjnych. Mówiąc kolokwialnie, dostawca może powiedzieć “nie mamy pańskiego płaszcza i co nam Pan zrobi”.
2. Zakres wdrożenia
Zakres wdrożenia powinien być opisany w sposób maksymalnie szczegółowy. W praktyce to właśnie niejasności w tym obszarze są najczęstszą przyczyną sporów i dyskusji na temat tego, co dostawca powinien naszym zdaniem dostarczyć. A zdaniem dostawcy oczywiście nie.
Umowa powinna jasno wskazywać:
jakie moduły i funkcjonalności są objęte wdrożeniem,
jakie integracje z innymi systemami są przewidziane (i potencjalnie - kto za to zapłaci),
jakie obowiązki spoczywają na dostawcy, a jakie na zamawiającym,
harmonogram prac i kamienie milowe,
jakie dane będą podlegać migracji i w jakim zakresie, kto przygotowuje dane do migracji,
kryteria odbioru (testy, dokumentacja, szkolenia), czyli czego dokładnie oczekujemy od dostawcy, aby uniknąć późniejszych domysłów, co autor miał na myśli.
Warto zadbać o to, aby załączniki (specyfikacja funkcjonalna, harmonogram, opis architektury) miały taką samą moc prawną jak treść umowy głównej.
3. Odpowiedzialność dostawcy
Odpowiedzialność dostawcy systemu IT nie powinna być jedynie formalnym zapisem. Kluczowe jest określenie:
odpowiedzialności za wady systemu i błędy wdrożeniowe,
odpowiedzialności za naruszenie bezpieczeństwa danych,
limitów odpowiedzialności (np. wielokrotność wynagrodzenia),
wyłączeń odpowiedzialności — i ich zasadności.
Zbyt niskie limity odpowiedzialności lub szerokie wyłączenia mogą sprawić, że w razie poważnego problemu firma pozostanie bez realnej ochrony.
4. Zmiany w projekcie
W projektach IT zmiany są nieuniknione. Umowa powinna zawierać jasno opisany mechanizm zarządzania zmianą (change request), obejmujący:
sposób zgłaszania zmian,
procedurę ich wyceny i akceptacji,
wpływ zmian na harmonogram i budżet,
sytuacje, w których zmiana jest traktowana jako element pierwotnego zakresu.
Brak takiej procedury często prowadzi do niekontrolowanego wzrostu kosztów lub sporów o to, co „było w umowie”.
5. Licencje i prawa autorskie
Kwestie licencyjne mają fundamentalne znaczenie dla dalszego rozwoju i utrzymania systemu. Umowa powinna precyzować:
rodzaj licencji (czasowa, bezterminowa, sublicencjonowalna),
zakres dozwolonego użytkowania (liczba użytkowników, środowiska),
prawa do modyfikacji i rozwoju systemu,
dostęp do kodu źródłowego (jeśli dotyczy),
skutki rozwiązania umowy.
Niedoprecyzowanie tych kwestii może skutkować uzależnieniem firmy od jednego dostawcy (vendor lock-in) bądź realnym brakiem dostępu do systemu, jeśli całe administrowanie systemem spoczywa wyłącznie na dostawcy. Dopóki system jest użytkowany, to jest to w porządku, ale co się może wydarzyć, kiedy za kilka czy kilkanaście lat uznamy, że chcemy zmienić system? Czy informując dostawcę o rezygnacji, nie odetniemy się z dnia na dzień od źródła danych i dostępu do systemu? Warto pomyśleć o tym długoterminowo.
Podsumowanie:
To tylko kilka przykładów, które pokazują, co jest istotne z perspektywy zamawiającego, aby podpisać umowę na wdrożenie systemu i jednocześnie nie skazać się na porażkę wdrożeniową zanim jeszcze rozpoczną sie prace. Jako osoba, która widziała różne potknięcia projektowe, bardzo chętnie będę kontynuować ten wątek w drugiej części artykułu. Ciąg dalszy nastąpi.
