Utrzymanie i rozwój oprogramowania po wdrożeniu: o czym pamiętać w umowie

Dzień uruchomienia nowego systemu otwiera najdłuższą fazę projektu. Przez kolejne lata oprogramowanie trzeba poprawiać, aktualizować i dostosowywać do zmian w firmie oraz w systemach, z którymi się łączy. Utrzymanie i rozwój oprogramowania po wdrożeniu to temat, o którym przy podpisywaniu umowy na budowę myśli się najmniej, a który najczęściej kończy się sporem. Poniżej znajdziesz listę zapisów, które powinny trafić do umowy, zanim pojawi się pierwsza awaria.

Czym różni się gwarancja od utrzymania

Gwarancja obejmuje usuwanie wad tego, co zostało odebrane. Jeśli funkcja działa niezgodnie z uzgodnioną specyfikacją, wykonawca przez określony czas poprawia ją bez dodatkowej opłaty. Utrzymanie ma szerszy zakres: reagowanie na zgłoszenia, monitoring, aktualizacje bibliotek i środowiska, drobne zmiany, pomoc użytkownikom. Rozwój to nowe funkcje.

W umowie te trzy obszary muszą być wyraźnie rozdzielone. Inaczej każda rozmowa o tym, czy coś jest błędem (bezpłatnie), czy zmianą (płatnie), zaczyna się od nowa.

Checklista zapisów: utrzymanie oprogramowania w umowie

Zakres usługi

• Jakie elementy obejmuje utrzymanie: aplikacja, baza danych, serwer, integracje, aplikacja mobilna.
• Czy w cenie są aktualizacje bezpieczeństwa bibliotek i środowiska uruchomieniowego.
• Czy wykonawca monitoruje działanie systemu, czy tylko reaguje na zgłoszenia.
• Kto odpowiada za kopie zapasowe i test ich odtwarzania.

Klasyfikacja zgłoszeń i czasy reakcji

• Definicje kategorii: awaria krytyczna (system nie działa), błąd poważny (ważna funkcja nie działa, ale jest obejście), błąd drobny, pytanie.
• Czas reakcji i czas rozwiązania lub obejścia dla każdej kategorii.
• Godziny świadczenia usługi: dni robocze w godzinach pracy czy całą dobę dla awarii krytycznych.
• Kanał zgłoszeń i sposób potwierdzania ich przyjęcia.

Te zapisy działają tak samo jak w umowie na obsługę infrastruktury. Szczegóły rozpisaliśmy w artykule o umowie SLA na obsługę IT.

Konsekwencje niedotrzymania

• Kary umowne lub obniżenie opłaty za okres, w którym SLA nie było dotrzymane.
• Prawo do wypowiedzenia umowy przy powtarzających się naruszeniach.
• Raportowanie: co miesiąc lub co kwartał lista zgłoszeń z czasami obsługi.

Kod źródłowy i prawa autorskie

• Przeniesienie autorskich praw majątkowych albo licencja z określonymi polami eksploatacji, w tym z prawem do modyfikacji przez inny podmiot.
• Dostęp do repozytorium kodu na bieżąco, a nie dopiero przy rozwiązaniu umowy.
• Wykaz komponentów zewnętrznych i ich licencji.

Dokumentacja

• Dokumentacja techniczna: architektura, opis integracji, instrukcja instalacji i odtworzenia środowiska.
• Obowiązek aktualizowania dokumentacji przy każdej zmianie.
• Instrukcje dla użytkowników i administratorów.

Rozwój i zmiany

• Procedura zgłaszania zmian: opis, wycena, akceptacja przed rozpoczęciem prac.
• Stawka godzinowa lub pula godzin w abonamencie, z zasadą rozliczania godzin niewykorzystanych.
• Zasady testowania i odbioru zmian, w tym środowisko testowe.

Zakończenie współpracy

• Okres wypowiedzenia wystarczający na znalezienie nowego wykonawcy.
• Obowiązek przekazania następcy kodu, dokumentacji, dostępów i wiedzy.
• Pomoc w okresie przejściowym na ustalonych warunkach.

Abonament czy rozliczenie za zgłoszenie

Abonament gwarantuje dostępność zespołu i daje przewidywalny koszt. Sprawdza się, gdy system jest krytyczny dla firmy albo regularnie rozwijany. Rozliczenie za faktycznie przepracowane godziny wychodzi taniej przy stabilnym systemie, z którym rzadko są kłopoty. Nie daje jednak pewności, że ktoś szybko zareaguje na awarię. Częsty kompromis to niewielki abonament gwarantujący czasy reakcji plus stawka za prace ponad pulę.

Integracja, która przestała działać po roku

Weźmy firmę logistyczną, która zamawia aplikację do planowania tras zintegrowaną z ERP. Umowa obejmuje budowę i trzymiesięczną gwarancję. Po roku dostawca ERP zmienia sposób uwierzytelniania w API i integracja przestaje działać. Wykonawca aplikacji uznaje to za zmianę, a nie błąd, i wycenia prace jako nowe zlecenie. Umowy utrzymaniowej nie ma, więc firma czeka na wolny termin zespołu, a planowanie na kilka dni wraca do arkuszy.

Gdyby umowa przewidywała utrzymanie z obowiązkiem dostosowania integracji do zmian w systemach zewnętrznych i krótkim czasem reakcji, problem zostałby rozwiązany w ramach abonamentu i bez przestoju.

O czym się zapomina

• ERP, systemy kurierskie, banki i platformy sprzedażowe regularnie zmieniają swoje interfejsy. Kto i na jakich warunkach dostosowuje do nich integracje?
• Wersje systemu operacyjnego, bazy danych i frameworków mają ograniczony czas wsparcia. Aktualizacja środowiska to praca, którą trzeba zaplanować.
• Jeśli system zna tylko jeden programista wykonawcy, jego odejście staje się Twoim ryzykiem. Pytaj o zespół i zastępstwa.
• Po stronie firmy potrzebny jest opiekun, który zbiera zgłoszenia od użytkowników, ustala priorytety i odbiera zmiany.

Pytania do wykonawcy przed podpisaniem umowy

• Ile osób w zespole zna system i kto przejmie zgłoszenia, gdy główny programista jest na urlopie?
• Jak wygląda wydawanie nowych wersji? Czy jest środowisko testowe i kto akceptuje wdrożenie na produkcję?
• W jaki sposób będziesz informowany o planowanych pracach i przerwach w działaniu?
• Jak wykonawca dba o bezpieczeństwo: aktualizacje, kontrolę dostępu do serwerów, przechowywanie haseł i kluczy?
• Czy wykonawca przyjmie utrzymanie również wtedy, gdy hosting zapewnia inna firma albo Twój dział IT?

Konkretne, spokojne odpowiedzi na te pytania mówią o przyszłej współpracy więcej niż prezentacja handlowa.

A co z gotowymi systemami, takimi jak ERP

Przy gotowym oprogramowaniu zasady są podobne, tylko inaczej rozłożone. Aktualizacje i zgodność z przepisami zapewnia producent. Instalację aktualizacji, testy dodatków i konfiguracji, wsparcie użytkowników i rozwój raportów prowadzi zwykle partner wdrożeniowy. Umowa z nim powinna zawierać te same elementy: zakres, czasy reakcji, rozliczanie zmian i warunki zakończenia współpracy. Dodatki do ERP pisane na zamówienie wymagają tego samego podejścia co aplikacje dedykowane, łącznie z dostępem do kodu i dokumentacji.

Kiedy o tym rozmawiać

Najlepiej przed podpisaniem umowy na budowę. Masz wtedy jeszcze pozycję negocjacyjną i możesz porównywać oferty także pod kątem kosztów utrzymania. Warunki utrzymania da się ująć już w specyfikacji. Jak to zrobić, podpowiadamy w tekście o przygotowaniu specyfikacji aplikacji. Jeśli dopiero wybierasz między budową a zakupem, porównaj koszty utrzymania obu wariantów, jak opisujemy w artykule system dedykowany czy gotowe oprogramowanie.

FX2 tworzy oprogramowanie na zamówienie i utrzymuje je po uruchomieniu. Przejmujemy też opiekę nad systemami napisanymi przez innych wykonawców, jeśli dostępny jest kod i dokumentacja. Masz system bez umowy utrzymaniowej albo przygotowujesz nowy projekt? Porozmawiajmy o tym, jak zabezpieczyć jego przyszłość.