Zmiana zasad SLA: co trafi do kolejnego raportu?

Nowy kalendarz od uzgodnionej daty

Załóżmy, że klient i firma serwisowa uzgodnili rozszerzenie godzin obsługi od następnego okresu. Zmienia to kalendarz używany do pomiaru SLA, czyli uzgodnionego poziomu obsługi. Osoba przygotowująca raport edytuje wspólny kalendarz w swoim zestawieniu. Gdy później wraca do poprzedniego miesiąca, musi odszukać stare ustawienia, żeby odtworzyć wcześniejszy wynik.

W proponowanej aplikacji opiekun usługi przygotowuje nową wersję zasad przy uzgodnieniach z tym klientem. Zapisuje zmieniony kalendarz oraz datę, od której ma być stosowany. Dotychczasowa wersja pozostaje dostępna. Osoba sprawdzająca widzi, czego dotyczy propozycja i które ustalenia klienta ma odwzorować.

Przed zatwierdzeniem może porównać ten sam zestaw przykładowych zgłoszeń według obecnych i proponowanych zasad. Przy różnicy otwiera wyjaśnienie, że nowy kalendarz wlicza czas obsługi, który wcześniej wypadał poza godzinami pracy. Taki podgląd pozwala wychwycić zmianę wprowadzoną dla niewłaściwego klienta albo od niewłaściwego okresu, zanim trafi ona do raportowania.

Osoba odpowiedzialna za zasady zatwierdza wersję do stosowania od uzgodnionej daty. Przy wcześniejszym raporcie pozostaje wskazanie definicji, według których powstał. Kierownik może więc wyjaśnić starszy wynik, nawet gdy zespół korzysta już z nowego kalendarza.

Oddzielne reguły dla klientów

Wspólny szablon ułatwia przygotowanie kolejnej konfiguracji. Opiekun usługi nadal potrzebuje wiedzieć, których klientów obejmuje zmiana i kto ją sprawdził. Rozszerzenie godzin dla jednego klienta nie powinno przypadkiem zmienić reguł stosowanych przy pozostałych.

Aplikacja może zebrać przygotowywane zmiany wraz z datami i osobami odpowiedzialnymi za ich przegląd. Kierownik widzi wtedy, która wersja jest robocza, która została zatwierdzona i która obowiązuje w danym okresie. Osoba przejmująca klienta może wrócić do uzasadnienia zmiany, zamiast odgadywać je z aktualnych ustawień.

Wasz zespół przekłada uzgodnienia z klientem na jednoznaczne zasady pomiaru. Jeśli data albo zakres zmiany wymagają wyjaśnienia, sprawa wraca do osoby odpowiedzialnej za te ustalenia. Wykonawca aplikacji potrzebuje potwierdzonych reguł, aby odwzorować je w obliczeniach i podglądzie porównania.

Co sprawdzić w obecnym helpdesku

Jira Service Management pozwala edytować cele SLA, w tym czas docelowy, priorytet, kalendarz i warunki określające objęte nimi zgłoszenia. Warto zacząć od tych możliwości w używanym produkcie oraz sposobu ich wykorzystania przez administratora.

Na przykładzie ostatniej zmiany ustalcie, jak obecne narzędzie przechowuje wcześniejsze definicje, pokazuje proponowaną różnicę i wiąże reguły z okresem oraz klientem. Jeśli dostępne funkcje obsługują potrzebny przegląd i zatwierdzenie, konfiguracja może wystarczyć.

Integracja jest warta rozważenia, gdy helpdesk dobrze wykonuje pomiar, lecz przygotowanie i akceptacja zmian odbywają się w mailach lub arkuszach. Można połączyć zatwierdzoną wersję zasad z miejscem, w którym jest stosowana. Trzeba przy tym ustalić, jakie informacje obecny produkt udostępnia i jak potwierdzić zastosowanie właściwej wersji.

Własna aplikacja może objąć przygotowanie zmian dla wielu klientów, porównanie starej i nowej wersji oraz zatwierdzanie ich do użycia. Helpdesk nadal prowadzi zgłoszenia. Taki zakup ma sens, gdy zespół regularnie odtwarza decyzje o konfiguracji, a istniejące funkcje lub rozszerzenia nie obsługują wygodnie tego obiegu.

Jeżeli zasady są już uporządkowane, a trudność polega na comiesięcznym zbieraniu historii zgłoszeń, przeczytaj artykuł o automatyzacji raportowania SLA dla klientów.

Historia zasad też wymaga przeniesienia

Przy uruchomieniu aplikacji potrzebne będą aktualne reguły, przygotowywane zmiany i odwołania do definicji użytych w starszych raportach. Zespół powinien wskazać, które wersje potrafi potwierdzić na podstawie dostępnych zapisów. Brakującej historii nie da się odtworzyć z samego dzisiejszego kalendarza. Starsze raporty mogą pozostać w dotychczasowym archiwum, jeśli zachowają potrzebne powiązania.

Po uruchomieniu opiekunowie usług nadal przygotowują i zatwierdzają zmiany biznesowe. Z wykonawcą trzeba uzgodnić utrzymanie połączeń oraz obsługę sytuacji, w której zatwierdzona wersja nie została zastosowana w systemie raportującym.

W porównaniu z gotowym produktem uwzględnij też własność kodu i danych oraz dostęp potrzebny do przejęcia utrzymania przez inną firmę. Eksport powinien obejmować wersje zasad z datami, decyzjami i wskazaniem raportów, które z nich korzystały.

Jak Syntalith może uporządkować zmiany SLA

W ramach oprogramowania na zamówienie i integracji Syntalith może przygotować obieg zmiany zasad: od roboczej wersji i porównania wyników po zatwierdzenie oraz przekazanie do używanego systemu. Opiekunowie usług otrzymują miejsce do przygotowania zmiany, a kierownik może sprawdzić jej zakres przed uruchomieniem. Wasz zespół wnosi potwierdzone definicje pomiaru i wskazuje osoby odpowiedzialne za ich akceptację.

Opowiedz o ostatniej ręcznej poprawce raportu po zmianie ustaleń z klientem. Co trzeba było odnaleźć: poprzedni kalendarz, datę zmiany czy zgodę na jej zastosowanie? Na tej podstawie możemy określić, czy potrzebne jest lepsze wykorzystanie helpdesku, integracja czy osobna aplikacja do prowadzenia zmian. Informacje o rozliczeniu prac znajdziesz w cenniku Syntalith.