Jak opisać zakres wdrożenia?
Ogólne zobowiązanie do wdrożenia systemu zgodnie z potrzebami klienta nie pozwala rozliczyć projektu. Umowa powinna wskazywać specyfikację, procesy, integracje, architekturę, format migracji danych i rezultaty poszczególnych etapów.
Równie ważne są założenia i wyłączenia, na których opiera się wycena. Pozwalają odróżnić wadę uzgodnionej funkcji od późniejszego rozszerzenia projektu.
Jak powiązać harmonogram z obowiązkami klienta?
Etapy analizy, konfiguracji, rozwoju, migracji, testów, szkoleń i uruchomienia powinny kończyć się wskazanym rezultatem. Harmonogram musi uwzględniać dane, decyzje, środowiska i dostępy dostarczane przez zamawiającego.
Opóźnienie klienta nie powinno automatycznie uzasadniać dowolnego przesunięcia. Dostawca powinien zgłosić przeszkodę, jej wpływ i możliwe działania naprawcze.
Jak uregulować odbiór i błędy?
Procedura powinna określać przedmiot testów, kryteria, termin zgłaszania zastrzeżeń i sposób ponownego sprawdzenia. Przydatne jest rozróżnienie błędów blokujących, istotnych i drobnych.
Nie każda usterka powinna blokować cały etap, lecz wykonawca nie powinien otrzymywać pełnej płatności za rozwiązanie, którego kluczowe funkcje nie działają. Uwagi klienta powinny wskazywać konkretną niezgodność ze specyfikacją.
Dlaczego potrzebna jest procedura change request?
Zmiana podczas wdrożenia jest normalna. Ryzyko powstaje, gdy zespół zaczyna ją wykonywać bez uzgodnienia ceny, terminu i wpływu na architekturę.
Procedura powinna obejmować zgłoszenie, analizę, wycenę, decyzję uprawnionej osoby i zasady kontynuowania dotychczasowych prac. Warto też określić pulę drobnych modyfikacji objętych ceną.
Jak dobrać model wynagrodzenia?
Ryczałt wymaga dojrzałego zakresu, a time and materials – raportowania czasu, limitów budżetu i kontroli prac dodatkowych. Model mieszany może łączyć ryczałt dla zdefiniowanych etapów z rozliczeniem godzinowym zmian.
Płatności powinny odpowiadać mierzalnym rezultatom. Wysoka zaliczka zwiększa ryzyko klienta, a płatność całości dopiero po uruchomieniu może nieproporcjonalnie obciążyć dostawcę.
Jak uregulować prawa do systemu i komponentów?
System zwykle łączy elementy dedykowane, wcześniejsze narzędzia wykonawcy, produkty zewnętrzne, open source i konfigurację chmury. Umowa powinna rozdzielać te kategorie oraz wskazywać, co jest przenoszone, a co licencjonowane.
Przeniesienie autorskich praw majątkowych wymaga formy pisemnej i wskazania pól eksploatacji. Samo opłacenie faktury nie daje automatycznie praw do kodu, a wykonawca powinien posiadać łańcuch praw od swojego zespołu i podwykonawców.
Jak ułożyć dane, bezpieczeństwo i utrzymanie?
Przed użyciem danych produkcyjnych trzeba ustalić role stron, zakres dostępów, podwykonawców, środowiska testowe, incydenty, kopie zapasowe i usuwanie danych. Jeżeli dostawca przetwarza dane w imieniu klienta, potrzebne są wymagania z art. 28 RODO.
Gwarancja na błędy, utrzymanie i SLA pełnią różne funkcje. Dokumentacja powinna rozróżniać naprawę niezgodności, rozwój systemu oraz wsparcie eksploatacyjne.
Jak zaplanować wyjście od dostawcy?
Umowa powinna określać wydanie danych, konfiguracji, kodu objętego właściwymi prawami, dokumentacji i dostępów administracyjnych. Znaczenie mają format eksportu, termin, koszt migracji i współpraca z następcą.
Przy systemach krytycznych można rozważyć repozytorium kontrolowane przez klienta, regularne przekazywanie dokumentacji lub depozyt kodu źródłowego.
Jak ten problem wygląda w praktyce
Hipotetyczny przykład: trzy nowe integracje bez change request
Specyfikacja przewiduje integrację z jednym programem księgowym. W trakcie projektu klient dodaje magazyn, kuriera i system spółki zagranicznej, a zespół zaczyna prace na podstawie ustaleń ze spotkań. Przy odbiorze wykonawca żąda dopłaty i przesunięcia terminu, a klient uznaje funkcje za część pierwotnej ceny. Formalna analiza zmiany przed rozpoczęciem prac pozwoliłaby uzgodnić zakres, architekturę, budżet i termin.
Kwestie do ustalenia lub sprawdzenia przed działaniem
- Specyfikacja, założenia, wyłączenia i odpowiedzialność za integracje
- Etapy, zależności i obowiązki współdziałania zamawiającego
- Kryteria odbioru, klasy błędów i ponowne testy
- Procedura change request i osoby uprawnione do zatwierdzania
- Model ceny, raportowanie czasu i limity budżetu
- Prawa do kodu, komponentów zewnętrznych, open source i dokumentacji
- Dane osobowe, bezpieczeństwo, SLA oraz obsługa incydentów
- Eksport danych, dokumentacja i wsparcie przy zmianie dostawcy
Najważniejsze zagadnienia w skrócie
| Zagadnienie | Kluczowa informacja |
|---|---|
| Zakres | Mierzalne rezultaty, integracje, założenia i wyłączenia |
| Odbiór | Kryteria testów, klasy błędów, terminy i ponowna weryfikacja |
| Zmiany | Analiza ceny i terminu przed rozpoczęciem dodatkowych prac |
| Prawa | Oddzielenie elementów dedykowanych od narzędzi i licencji zewnętrznych |
| Wyjście | Dane, dokumentacja, dostępy i praktyczne wsparcie migracji |
Podstawy prawne
- Ustawa z dnia 23 kwietnia 1964 r. – Kodeks cywilny, w szczególności przepisy o wykonaniu zobowiązań i odpowiedzialności kontraktowej
- Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych, w szczególności art. 41, 53 i 74
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679, w szczególności art. 28 i 32
Materiał ma charakter ogólny i nie stanowi porady prawnej w konkretnej sprawie. Właściwe rozwiązanie zależy od stanu faktycznego, dokumentów i celu biznesowego.
Podsumowanie
Umowa wdrożeniowa powinna pozwalać stronom odróżnić błąd od nowego zakresu, obiektywnie przeprowadzić odbiór i korzystać z systemu również po zakończeniu współpracy z dostawcą. Najważniejsze mechanizmy muszą być spójne ze specyfikacją i realnym sposobem prowadzenia projektu.