Co obejmuje wsparcie Dynamics 365: zakres, SLA i czas reakcji

Wsparcie Dynamics 365 Finance and Operations obejmuje cztery warstwy: obsługę zgłoszeń użytkowników według uzgodnionych czasów reakcji, proaktywne monitorowanie systemu, zarządzanie aktualizacjami Microsoft oraz bieżący rozwój rozwiązania. Dobra umowa wsparcia określa nie tylko to, jak szybko partner odpowie na zgłoszenie, ale też kiedy przywróci działanie procesu, kto testuje aktualizacje i co dzieje się z wiedzą o systemie, gdy zmienia się zespół. Czas reakcji na zgłoszenie krytyczne liczy się zwykle w minutach lub godzinach, a na drobną zmianę w dniach.

W praktyce najwięcej sporów między firmą a partnerem nie dotyczy szybkości odpowiedzi, tylko granic zakresu. Ten tekst porządkuje, co powinno znaleźć się w zakresie wsparcia Dynamics 365, jak czytać SLA i jakie czasy reakcji są rozsądne dla firmy, której finanse i łańcuch dostaw działają na Finance and Operations.

Najważniejsze fakty w skrócie:

• Cztery warstwy zakresu. Obsługa zgłoszeń, monitoring, aktualizacje Microsoft i rozwój systemu to osobne usługi, które warto opisać osobno w umowie.
• Reakcja to nie rozwiązanie. SLA powinno rozróżniać czas pierwszej reakcji, czas przywrócenia działania i czas trwałego rozwiązania problemu.
• Priorytet według wpływu na biznes. Zatrzymana wysyłka albo nieudany przelew to inny priorytet niż zmiana układu wydruku, niezależnie od kolejności zgłoszeń.
• Aktualizacje są stałym obowiązkiem. Microsoft wydaje cztery aktualizacje usługi rocznie, a przesunąć można tylko jedną z rzędu, więc testy regresji muszą być wpisane w zakres.
• Kalendarz finansów decyduje o godzinach. Zamknięcie miesiąca, JPK i KSeF wymagają wzmocnionej dostępności w konkretnych dniach, a nie całodobowego dyżuru przez cały rok.
• Dokumentacja należy do klienta. Konfiguracja, rozszerzenia i integracje powinny być opisane w repozytorium, które pozostaje po stronie firmy.

‍

Co obejmuje wsparcie Dynamics 365 Finance and Operations?

Najczęstszy błąd przy zamawianiu wsparcia polega na utożsamianiu go z helpdeskiem. Helpdesk to tylko pierwsza z czterech warstw. Pierwsza warstwa, reaktywna, to przyjmowanie i rozwiązywanie zgłoszeń: błąd księgowania, zablokowana partia zadań, integracja z bankiem, która nie zaczytała wyciągu, użytkownik bez uprawnień do nowej firmy w grupie. Druga warstwa, proaktywna, to monitorowanie zadań wsadowych, integracji, wydajności i rozmiaru bazy danych, tak aby problem został wykryty, zanim zauważy go księgowość w dniu zamknięcia.

Trzecia warstwa to zarządzanie wydaniami. Dynamics 365 Finance and Operations działa w modelu ciągłych aktualizacji, a według zasad One Version opisanych przez Microsoft klient otrzymuje cztery aktualizacje usługi w roku i może wstrzymać tylko jedną z rzędu. Każda aktualizacja wymaga przetestowania rozszerzeń, integracji i rozwiązań niezależnych dostawców przed wdrożeniem na produkcję.

Czwarta warstwa to rozwój: nowe pola, raporty, kroki zatwierdzania, przepływy w Power Automate, a czasem większa zmiana procesu po przejęciu spółki. W polskich firmach dochodzi do tego warstwa zgodności z przepisami: JPK, KSeF, biała lista podatników VAT i formaty przelewów. Dlatego sensowny zakres umowy opisuje wszystkie cztery warstwy osobno, z osobnymi zasadami rozliczeń i priorytetów. Szerzej o tym, jak dobrać model rozliczenia do tych warstw, piszemy w artykule o modelach wsparcia Dynamics 365.

‍

Jak czytać SLA we wsparciu Dynamics 365?

SLA, czyli umowa o poziomie usług, jest najczęściej czytana tylko w jednej kolumnie: czas reakcji. To najmniej ważna liczba w całym dokumencie. Czas reakcji mówi, kiedy konsultant potwierdzi przyjęcie zgłoszenia i zacznie pracę, ale nie mówi nic o tym, kiedy faktura sprzedażowa znowu trafi do KSeF albo kiedy magazyn wznowi kompletację. Dlatego dojrzałe SLA rozróżnia trzy miary: czas pierwszej reakcji, czas przywrócenia działania przez obejście problemu i czas trwałego rozwiązania przyczyny.

Ten sam podział stosuje Microsoft. W opisie poziomów ważności zgłoszeń dla Dynamics 365 i Power Platform zgłoszenie o krytycznym wpływie na biznes ma pierwszą reakcję w czasie poniżej godziny, a zgłoszenie o umiarkowanym wpływie od dwóch do czterech godzin, w zależności od planu. To są jednak czasy reakcji producenta platformy, a nie partnera, który zna Twoje rozszerzenia i integracje. Partner musi przejąć problem wcześniej i często sam zdecydować, czy jest to błąd platformy, czy konfiguracji.

Druga sprawa to godziny obsługi. SLA liczone w godzinach roboczych od poniedziałku do piątku wygląda dobrze na papierze, dopóki awaria nie zdarzy się w piątek o 17:30 w dniu wysyłki przelewów. Zamiast kupować całodobowy dyżur na cały rok, warto opisać okna wzmocnionej dostępności: ostatni i pierwszy dzień roboczy miesiąca, termin wysyłki JPK_VAT, dni wypłat i okresy szczytu sprzedaży. Trzecia sprawa to wyłączenia: zgłoszenia, które nie spełniają definicji krytycznych, czas oczekiwania na odpowiedź klienta i incydenty po stronie Microsoft powinny być opisane wprost, inaczej każdy raport SLA będzie przedmiotem sporu.

Ostatni element dobrego SLA to sposób raportowania. Miesięczny raport powinien pokazywać nie tylko odsetek zgłoszeń obsłużonych w terminie, ale też liczbę zgłoszeń powtarzających się z tej samej przyczyny, czas oczekiwania na odpowiedź po stronie firmy i listę problemów przekazanych do Microsoft. Taki raport pozwala zarządowi ocenić, czy system staje się stabilniejszy, czy tylko szybciej gaszone są te same pożary.

‍

Jakie czasy reakcji są rozsądne dla firmy na Finance and Operations?

Nie istnieje jeden prawidłowy zestaw czasów reakcji. Istnieje natomiast prosta zasada: priorytet zgłoszenia powinien wynikać z wpływu na proces biznesowy, a nie z tego, jak głośno zgłaszający opisuje problem. Zatrzymana produkcja, brak możliwości wystawiania faktur czy nieudany przebieg płatności to sytuacje, w których każda godzina ma wymierny koszt. Według badań Uptime Institute 54 procent organizacji oceniło, że ich ostatnia poważna awaria kosztowała ponad 100 tysięcy dolarów, a co piąta wskazała koszt przekraczający milion. Dla systemu ERP, przez który przechodzi cała sprzedaż, rachunek wygląda podobnie.

Z drugiej strony przesadnie krótkie czasy dla wszystkich zgłoszeń podnoszą cenę usługi, a nie poprawiają jakości. Partner, który musi odpowiedzieć w ciągu godziny na prośbę o zmianę nazwy kolumny w raporcie, przenosi koszt dyżuru na klienta. Rozsądny układ to cztery priorytety, z których tylko pierwszy obejmuje dyżur poza godzinami pracy, a ostatni jest w praktyce kolejką zmian planowanych w cyklu dwutygodniowym lub miesięcznym.

Poniższa tabela pokazuje typowe wartości dla średniej i dużej firmy w Polsce, która prowadzi finanse i logistykę w Dynamics 365. To punkt wyjścia do negocjacji, a nie norma. Firma działająca w trybie zmianowym, z magazynem pracującym w nocy, będzie potrzebowała krótszych czasów dla priorytetu pierwszego i szerszych okien obsługi. Firma usługowa z pracą biurową może bezpiecznie przyjąć dłuższe czasy dla priorytetów trzeciego i czwartego, oszczędzając na abonamencie.

‍

Gdzie najczęściej pojawiają się nieporozumienia?

Pierwsze nieporozumienie dotyczy granicy między błędem a zmianą. Firma zgłasza problem, który z jej perspektywy jest błędem, bo proces nie działa tak, jak powinien. Partner kwalifikuje go jako zmianę, bo system działa zgodnie z konfiguracją, tylko konfiguracja nie odpowiada już procesowi. Taki spór nie ma dobrego rozwiązania, jeśli umowa nie definiuje obu pojęć i nie mówi, kto rozstrzyga w sytuacji spornej. Najlepiej sprawdza się prosta zasada: błąd to rozbieżność z udokumentowanym zachowaniem systemu, a wszystko inne jest zmianą, wycenianą osobno, ale z możliwością szybkiej ścieżki dla drobnych poprawek.

Drugie nieporozumienie dotyczy aktualizacji. Wiele umów milczy na temat tego, kto testuje aktualizacje Microsoft i ile to kosztuje. Skutek jest przewidywalny: aktualizacje są przesuwane, wersja systemu się starzeje, a po wyczerpaniu możliwości wstrzymania aktualizacja trafia na produkcję bez pełnych testów. Trzecie nieporozumienie dotyczy wiedzy. Gdy każde zgłoszenie obsługuje inny konsultant, firma płaci za ponowne poznawanie systemu przy każdym incydencie, a w raportach SLA wszystko wygląda poprawnie.

Czwarte nieporozumienie dotyczy rozwiązań innych dostawców. Moduły do obsługi magazynu, bankowości czy płac, dostarczane przez niezależnych producentów, mają własne cykle wydań i własne wsparcie. Umowa powinna wskazywać, kto prowadzi zgłoszenie, gdy problem leży na styku tych rozwiązań z Dynamics 365. Bez tego firma staje się pośrednikiem między dwoma dostawcami, z których każdy wskazuje na drugiego. Zapisy, które ograniczają te ryzyka:

• Definicja błędu i zmiany. Jedno zdanie w umowie, które rozstrzyga większość sporów o kwalifikację zgłoszeń.
• Testy regresji w zakresie stałym. Każda aktualizacja usługi ma przypisany zakres testów i termin, a nie osobną wycenę za każdym razem.
• Stały zespół z zastępstwami. Imiennie wskazani konsultanci i co najmniej jedna osoba zastępująca dla każdego obszaru.
• Właściciel zgłoszeń na styku. Partner prowadzi zgłoszenia dotyczące rozwiązań innych dostawców do momentu ich rozwiązania.
• Przegląd miesięczny i kwartalny. Raport zgłoszeń i SLA co miesiąc, przegląd ryzyk, długu technicznego i planu rozwoju co kwartał.
• Zapisy na wyjście. Obowiązek przekazania kodu, dokumentacji i dostępów w uporządkowany sposób, jeśli firma zmieni partnera.

‍

Czym różni się wsparcie bieżące od opieki serwisowej i wsparcia projektowego?

W polskiej praktyce trzy pojęcia bywają używane zamiennie, choć opisują różne usługi. Wsparcie bieżące to obsługa zgłoszeń i utrzymanie systemu w ruchu. Opieka serwisowa to szersza usługa, w której partner odpowiada za stan systemu jako całości: monitoruje go, planuje aktualizacje, prowadzi dokumentację i proponuje usprawnienia. W tym modelu, opisanym na stronie opieki serwisowej Dynamics 365, rozliczenie zależy od wyniku, czyli stabilnego systemu, a nie od liczby przepracowanych godzin.

Wsparcie projektowe to z kolei udostępnienie ekspertów do konkretnego przedsięwzięcia: przejęcia spółki, wdrożenia nowego modułu, rolloutu na kolejny kraj albo naprawy projektu, który zatrzymał się w połowie. Ma ono początek i koniec, własny budżet i własny harmonogram, dlatego nie powinno konsumować puli godzin przeznaczonej na utrzymanie. Szczegóły tego modelu opisujemy na stronie wsparcia projektowego.

Dla zarządu ta różnica ma znaczenie budżetowe. Koszt utrzymania systemu przez dziesięć lat jego życia zwykle przewyższa koszt samego wdrożenia, a największa część tego kosztu powstaje tam, gdzie wsparcie jest kupowane godzinowo i bez planu. Partner, który odpowiada za stan systemu, ma interes w tym, aby usuwać przyczyny incydentów, wycofywać zbędne rozszerzenia i planować aktualizacje spokojnie. Partner rozliczany wyłącznie za godziny nie ma takiej motywacji, nawet jeśli pracuje rzetelnie. Najczęściej spotykany model w dużych firmach łączy oba podejścia: stały abonament na utrzymanie i aktualizacje oraz osobno wyceniane projekty rozwojowe.

‍

Jak przygotować się do wyboru lub zmiany partnera wsparcia?

Zanim firma zacznie porównywać oferty, warto przygotować trzy materiały. Pierwszy to historia zgłoszeń z ostatnich sześciu do dwunastu miesięcy, z podziałem na obszary i priorytety. Pokazuje ona rzeczywiste zapotrzebowanie i pozwala porównać oferty na podstawie kosztu miesięcznego, a nie stawki godzinowej. Drugi to mapa systemu: lista środowisk, rozszerzeń, integracji, rozwiązań innych dostawców i aktualna wersja aplikacji. Trzeci to kalendarz biznesowy: dni zamknięcia, terminy podatkowe, okresy szczytu i okresy urlopowe.

Z tymi materiałami rozmowa z partnerem staje się konkretna. Zamiast pytać, ile kosztuje godzina konsultanta, firma pyta, jaki zespół obsłuży jej system, ile osób w tym zespole przejmowało już środowisko Finance and Operations po innym partnerze i jak będzie wyglądał pierwszy miesiąc współpracy. Odpowiedzi na te pytania mówią o jakości wsparcia więcej niż jakakolwiek tabela z czasami reakcji.

Jeżeli zmiana partnera jest już przesądzona, najbezpieczniejsza kolejność zaczyna się od przeglądu technicznego środowiska. Pozwala on wycenić usługę na podstawie faktów i wykryć ryzyka, które w przeciwnym razie ujawniłyby się jako pierwszy poważny incydent. Dopiero potem następuje przekazanie wiedzy i dostępów, z krótkim okresem, w którym dotychczasowy partner nadal prowadzi zgłoszenia, a nowy zespół je obserwuje. Kroki, które najczęściej decydują o tym, czy użytkownicy w ogóle zauważą zmianę:

• Dostępy przed końcem wypowiedzenia. Uprawnienia administratora, repozytorium kodu i dane integracji przekazane, zanim wygaśnie umowa.
• Kod w repozytorium klienta. Rozszerzenia przekazane w repozytorium, którym zarządza firma, a nie jako archiwum na koniec współpracy.
• Przegląd otwartych zgłoszeń. Każde zgłoszenie zamknięte albo przekazane z pełną historią.
• Licencje rozwiązań innych dostawców. Sprawdzenie, czy wsparcie producentów nie wygasa razem z umową poprzedniego partnera.
• Najbliższa aktualizacja Microsoft. Plan i zakres testów uzgodniony z nowym zespołem przed przełączeniem.

‍

Od czego zależy koszt wsparcia Dynamics 365?

Cena wsparcia rzadko wynika z liczby użytkowników. Znacznie silniej zależy od czterech czynników: liczby i jakości rozszerzeń, liczby integracji z systemami zewnętrznymi, liczby spółek i krajów w jednym środowisku oraz od tego, jak bardzo firma chce przenieść odpowiedzialność za system na partnera. Środowisko z kilkuset zmodyfikowanymi obiektami, kilkunastoma integracjami i trzema lokalizacjami krajowymi wymaga innego zespołu niż system bliski standardowi, obsługujący jedną polską spółkę. Dlatego dwie firmy o podobnej liczbie użytkowników mogą płacić za wsparcie kwoty różniące się kilkukrotnie.

Drugim czynnikiem jest dług techniczny. Rozszerzenia budowane w pośpiechu, bez dokumentacji i testów automatycznych, podnoszą koszt każdej aktualizacji Microsoft i każdego incydentu. Partner, który przejmuje takie środowisko, musi najpierw je poznać, a często także uporządkować. Ten koszt pojawia się raz, ale zwraca się w kolejnych latach, ponieważ każda następna aktualizacja przechodzi szybciej, a liczba zgłoszeń wynikających z tej samej przyczyny spada.

Trzecim czynnikiem są godziny dostępności. Dyżur całodobowy przez cały rok jest najdroższym elementem każdej umowy i w większości firm finansowo nieuzasadnionym. Okna wzmocnionej dostępności, opisane wcześniej, pozwalają zapewnić bezpieczeństwo kluczowych procesów przy znacznie niższym abonamencie. Czwartym czynnikiem jest model rozliczenia. Pula godzin jest tania na starcie, ale nie obejmuje pracy proaktywnej, więc koszt incydentów rośnie z czasem. Abonament za utrzymanie jest wyższy miesięcznie, lecz w perspektywie trzech lat zwykle wychodzi korzystniej dla systemu, od którego zależy sprzedaż i rozliczenia.

Przy porównywaniu ofert warto więc poprosić każdego partnera o szacunek miesięcznego nakładu na podstawie historii zgłoszeń z ostatniego roku i porównywać koszt całkowity, a nie stawkę za godzinę. Oferta z najniższą stawką bywa najdroższa, jeśli konsultanci zmieniają się przy każdym zgłoszeniu i za każdym razem uczą się systemu od nowa.

‍

Jak ANEGIS prowadzi wsparcie Dynamics 365

ANEGIS jest partnerem Microsoft specjalizującym się w Dynamics 365 Finance and Supply Chain Management, z zespołem 98 specjalistów Dynamics 365 i ponad 170 ekspertów w biurach w Polsce i w Wielkiej Brytanii. Wsparcie prowadzimy w czterech filarach: obsługa zgłoszeń w ramach SLA, proaktywne utrzymanie, zarządzanie aktualizacjami Microsoft i ciągły rozwój systemu. Zakres może obejmować także Power Platform i Microsoft Fabric, jeśli raportowanie i automatyzacje są zbudowane wokół Finance and Operations. W środowiskach, które utrzymujemy, pracuje łącznie ponad 10 tysięcy użytkowników.

Każde przejęcie wsparcia zaczynamy od przeglądu technicznego w stałej cenie, trwającego od dwóch do czterech tygodni. Kończy się on rekomendacją zakresu, poziomu SLA i planem przejęcia. Przejmowanie systemów po innych partnerach, również słabo udokumentowanych, jest dla naszego zespołu standardem, a nie wyjątkiem. Dla BUUK Infrastructure, którego partnerem byliśmy przez ponad dziesięć lat, przeprowadziliśmy migrację z Dynamics AX do Dynamics 365 w chmurze, a po dwumiesięcznym okresie stabilizacji zespół wsparcia ANEGIS przejął system w utrzymanie. Ten sam zespół, który zna rozwiązanie z wdrożenia, odpowiada za nie w codziennej pracy.

Aktualizacje Microsoft planujemy z wyprzedzeniem, z testami regresji przypisanymi do konkretnych procesów, a zmiany przepisów, takie jak nowe wersje JPK czy KSeF, traktujemy jako stały element zakresu, a nie osobny projekt wyceniany w ostatniej chwili. Szczegóły tego podejścia opisujemy na stronie aktualizacji Dynamics 365.

‍

Sprawdź, czy Twoje wsparcie obejmuje to, czego potrzebujesz

Jeśli odnawiasz umowę wsparcia albo masz wrażenie, że obecny zakres nie odpowiada temu, jak firma korzysta z systemu, krótki przegląd zgłoszeń, ryzyk i kalendarza biznesowego zwykle szybko pokazuje, czego brakuje. Skontaktuj się z ANEGIS, aby umówić bezpłatną konsultację albo przegląd techniczny środowiska Dynamics 365 w stałej cenie.

‍