Z Piotrem Milewskim, niezależnym konsultantem w obszarze kontraktowania rozwiązań IT, rozmawia Dorota Konowrocka.

Jaki rodzaj współpracy między dostawcą usług informatycznych a klientem może zostać objęty umową typu Service Level Agreement?

Umowa tego typu może dotyczyć każdego rodzaju współpracy między dostawcą a klientem, która obejmuje systematyczne świadczenie usług. Umowami SLA mogłyby być już objęte - choć zazwyczaj nie są, co jest w interesie dostawcy - zwykłe kontrakty posprzedażnego utrzymania i wsparcia. Także wszystkie umowy obejmujące outsourcing doskonale pasują do tego modelu. Dotychczas jednak umowy SLA ograniczały się do regulowania poziomu usług polegających na hostingu aplikacji czy udostępnianiu łączy teleinformatycznych.

Czy kontrakt SLA różni się znacząco od umowy zawieranej na wdrożenie systemu lub sprzedaż licencji?

Umowa typu Service Level Agreement jest standardowym kontraktem informatycznym i jako taka powinna zawierać typowe elementy: procedury eskalacyjne, zabezpieczenie należytego wykonania usług (np. gwarancjami bankowymi) czy ochronę przed jednostronnymi decyzjami dostawcy. Jednak SLA jest kontraktem o tyle nietypowym, że wymaga dopracowania ogromnej liczby szczegółów i sporej wiedzy technicznej. To umowa, do której strony będą się odwoływały co miesiąc. Musi być więc na tyle precyzyjna, aby klient nie darł co miesiąc kotów z dostawcą. Zawarcie umowy zakupu licencji nie wymaga w zasadzie kreatywnego myślenia, Service Level Agreement - tak.

Jakie są najważniejsze elementy umowy SLA?

Kluczowym jej elementem są mierniki wskazujące poziom wykonania usługi przez dostawcę. Typowe mierniki to np. czas dostępności serwerów, minimalna gwarantowana przepustowość łącza, czas reakcji na awarię, czas usunięcia awarii. Zawsze zalecam podstawienie do takiego wzoru czy definicji miernika rzeczywistej sytuacji biznesowej. Wynik takiej symulacji pokaże, czy definicja jest akceptowalna dla klienta. Czasami lepsze jest dobrze zdefiniowane 85% niż mityczne 99,9999% sprytnie skalkulowane przez dostawcę. Zgodnie ze zdrowym rozsądkiem dostępność to procent czasu, np. 98,5% w okresie miesiąca, w którym każdy serwer czy łącze działają bezawaryjnie. Jeśli nie działa choć jedno, trudno mówić o dostępności. Dostawca może jednak przemycić w umowie definicję, która obejmuje np. wszystkie 50 serwerów będących pod jego opieką. I okaże się, że z punktu widzenia umowy dopuszczalna jest sytuacja, w której 49 serwerów działa poprawnie przez 99% czasu, a jeden tylko przez 80%. Tymczasem dla klienta może być to serwer o krytycznym znaczeniu.

Umowy SLA wymagają sporej wiedzy technicznej, ponieważ klient musi wiedzieć, dlaczego dany miernik jest dla niego istotny i dlaczego powinien zostać zagwarantowany na określonym poziomie. Im wyższy poziom, tym większe koszty dla klienta. Pytanie, czy konieczne. Podobnie jest z określaniem czasu reakcji na zgłoszenie usterki i czasu jej usunięcia. Nie wpisujmy tu nierealnych, choć pozornie uspokajających, terminów, tylko takie, których dostawca może dotrzymać, a za których niedotrzymanie będzie odpowiadał finansowo.

Podczas negocjacji dostawca okazuje się zazwyczaj stroną silniejszą ze względu na większe doświadczenie związane z podpisywaniem umów. Na jakie niekorzystne propozycje klienci powinni być wrażliwi?

Jak mawia pewien znajomy CIO, jedynym obowiązkiem klienta jest płacenie za usługę. Dostawca nie powinien zobowiązywać klienta do przestrzegania wymyślnych procedur administracyjnych, których dopełnienie jest warunkiem przyjęcia zgłoszenia o awarii. Czasem prawidłowe zgłoszenie wymaga np. dodzwonienia się do odpowiedniego przedstawiciela dostawcy lub załączenia opisu okoliczności, w jakich awaria wystąpiła. Jeśli klient nie dopełni tych wymogów, dla dostawcy nie biegnie czas reakcji i czas usunięcia awarii. W krańcowych przypadkach, jeśli klient nie dopełni procedur, zmuszony jest zapłacić karę umowną. To nieporozumienie. Umowa powinna określać sposób zgłoszenia awarii, ale powinien być on jak najprostszy.