Karta usługi - część 2

Jak IT ma wspierać usługę?

Ten oraz kolejny rozdział to już część karty przeznaczona tylko dla organizacji IT, która świadczy daną usługę. Przede wszystkim IT powinno wiedzieć, kto jest uprawniony do usługi oraz jakie są minimalne wymagania, aby być jej odbiorcą i użytkownikiem. Mogą to być wymagania organizacyjne, ale głównie będą to wymagania techniczne (wersja OS, przeglądarka, biblioteki systemowe, dodatkowy sprzęt itp.). W szczególności będą to wymagania na identyfikację i autoryzację użytkownika. Informacja ta powinna być zgodna z analogicznymi zapisami udostępnionymi w opisie usługi w katalogu publicznym.

Kolejny element istotny dla IT to relacje danej usługi z innymi usługami. Jest on ważny w trakcie analizy wpływu zmian na usługę i środowisko, a także podczas analizy występujących problemów. Informacja ta powinna się znajdować w karcie, choć ze względu na konieczność aktualizacji, lepiej jest zamieścić odnośnik do systemu modelowania usług, który umożliwia automatyczną aktualizację danych (najczęściej systemy inwentarzowe). Oprócz systemu inwentarzowego, dane te powinny być też dostępne w systemie obsługi zgłoszeń – jeśli taki występuje w IT. Tam również powinna się znaleźć informacja o odbiorcach/klientach usługi. W razie wystąpienia awarii łatwiej jest oszacować jej wpływ.

Usługa powinna mieć też opracowany proces eskalacji w przypadku wystąpienia krytycznych incydentów. Minimalnie powinna to być lista kontaktowa osób odpowiedzialnych za rozwiązanie problemów w poszczególnych obszarach oraz dane menedżerów zespołów. Powinien być również opisany proces dokonywania eskalacji - zarówno funkcjonalnej, jak i hierarchicznej - oraz zakres informacyjny, jaki powinien być opisany w zgłoszeniu, aby można je było sprawnie obsłużyć (wymaganie to jest istotne dla funkcjonowania I linii wsparcia, kontaktującej się z użytkownikami bezpośrednio). Ponadto w karcie usługi można zawrzeć opis działań w zakresie troubleshooting oraz informacje o dostępnych monitorach testujących jakość i dostępność usługi.

W karcie usługi jako odnośniki można umieścić wszelką dokumentację techniczną i treningową, włączając w to również dokumentacje poddostawców i producentów. Może się tam znaleźć dokumentacja użytkownika i opisy procesów realizowanych przez usługę. Poza tym warto zamieścić informację o kontakcie do ekspertów danej usługi, listy FAQ, linki do przydatnych portali i zewnętrznych baz wiedzy.

Istotnym elementem są plany komunikacji. W karcie należy zawrzeć sposób komunikowania zmian w usłudze oraz dedykowanych odbiorców informacji (role w organizacji zamiast konkretnych osób). Powinna być uwzględniona komunikacja zarówno do klientów/użytkowników usługi, jak i wewnątrz organizacji IT.

Jak IT dostarcza usługę?

Informacja o sposobie dostarczania usługi to kolejny dział karty usługi będący wewnętrzną informacją działu IT. Zawiera on komplet informacji technicznych o architekturze i konstrukcji usługi. Pierwszym i podstawowym elementem jest specyfikacja techniczna. Powinny się w niej znaleźć dokumentacje z opisem architektury, elementów składowych oraz łączących je relacji. Poziom szczegółowości powinien być tak dobrany, aby dokumentacja umożliwiała efektywny troubleshooting oraz wprowadzenie poprawek. Specyfikacja może być opisana w różny sposób, za pomocą diagramów, opisów tekstowych, grafów procesów. Może zawierać też informacje konfiguracyjne oraz dokumentację od poddostawców komponentów.

Kolejnym istotnym elementem jest dokumentacja procesów i procedur, które są wykonywane w celu świadczenia usługi. Przykładowo: mogą to być dokumentacje wykonywania backupu i odtwarzania, okresowe procedury przeglądowe, plany utrzymaniowe, weryfikacje logów i sposoby tworzenia raportów. Dotyczy to również procedur aktualizacji portali informacyjnych z wiedzą na temat świadczonej usługi. Nie należy zapomnieć o procesie zarządzania zmianą albo w postaci odniesienia do standardowego procesu obowiązującego dla wszystkich usług, albo dedykowanej procedury. W szczególności trzeba określić skład rady do spraw zmian dla danej usługi, tzn. listy osób, z którymi należy konsultować modyfikacje i uzyskać ich akceptację (w skład rady wchodzą członkowie organizacji świadczącej usługę). Ponadto można ustalić zespół odpowiedzialny za zmiany usługi oraz dedykowane formularze rejestracyjne dla zgłaszanych zmian. Należy też określić procedury zarządzania pojemnością, tj. okresowe analizy dostępnej pojemności, planowanie pojemności, przygotowanie rekomendacji do rozbudowy infrastruktury.

Finalnie w opisie sposobu dostarczania usługi powinny się znaleźć informacje o zespole odpowiedzialnym za świadczenie usługi. Są to zespoły osób (lub zdefiniowane role) odpowiedzialne za dostarczanie usługi, wsparcie w przypadku wystąpienia problemów (helpdesk/servicedesk), zarządzanie i planowanie (właściciel usługi). Lista osób powinna zawierać dane kontaktowe oraz ew. zastępstwa w razie niedostępności osób odpowiedzialnych.

Umowy o poziomach świadczenia

Umowy SLA, jako wyjątek z sekcji dostarczania, powinny być dostępne publicznie lub przynajmniej dany użytkownik powinien mieć udostępnione parametry świadczenia swojej usługi. IT winno mieć dostęp do wszystkich umów SLA, aby mieć kompletny pogląd na warunki świadczenia. W umowie SLA powinny być zdefiniowane parametry dostępności, pojemności, ciągłości oraz wsparcia, np.: usługa świadczona w reżimie 24x7, dla maksimum 100 użytkowników, z planowanymi 3-godzinnymi przerwami utrzymaniowymi w pierwszą niedzielę miesiąca, ze wsparciem helpdesk w godzinach 7.00-18.00.

Analogicznie do umów SLA w definicji usługi powinny się znaleźć umowy OLA i UC. W umowach OLA definiujemy warunki pomiędzy poszczególnymi zespołami wewnątrz firmy, np. dział aplikacji świadczący usługę aplikacyjną umawia się z działem serwerów na konkretną dostępność infrastruktury. I podobnie w przypadku umów UC, które podpisujemy z dostawcami zewnętrznymi. OLA i UC również powinny zawierać parametry pojemności, ciągłości, dostępności i wsparcia. W odróżnieniu od SLA, parametrów świadczenia OLA i UC nie udostępnia się użytkownikom i klientom. Zwykle parametry OLA i UC powinny być bardziej restrykcyjne niż umowy SLA na daną usługę – chyba że organ świadczący decyduje się wziąć na siebie ryzyko związane z niższym niż oferowany poziomem dostępności.

Przykład prostej karty usługi poniżej:

Wersja3.1
Nazwa usługiBankowość elektroniczna
OpisUsługa obejmuje całokształt działań mających na celu zapewnienie użytkownikom biznesowym stałego dostępu do oferowanej funkcjonalności systemów bankowych
Okres obowiązywania do01.04.2020
DostawcaZespół Bankowości Elektronicznej
Właściciel usługi ITDyrektor Zespołu Bankowości Elektronicznej
KlienciKlienci banku
Wymagania- Dostępność usługi „Księga główna”,
- Dostępność usługi „Sieć komputerowa”,
- Zasilanie energetyczne
Czas świadczenia usługi24 godziny 7 dni w tygodniu
Czas świadczenia wsparcia dla usługi5 dni w tygodniu (poniedziałek – piątek) w godzinach 9.00-17.00
Dostępność usługi99 %
Warunki dostępnościMaksymalnie XXXX klientów
Czas reakcjigodzina
Czas rozwiązaniaPriorytet (Pilność + Wpływ/Zasięg) – czas realizacji zgłoszenia
Krytyczny – 69 godzin
Rozwiązanie zastępcze – 49 godzin
Wysoki – 129 godzin
Normalny – 137 godzin
Niski – 273 godziny
Okna serwisowe3 godziny w miesiącu w godzinach od 24.00 do 03.00
Lista zleceń standardowychNazwaCzas realizacjiMax w miesiącu
 Aktywacja dostępu do usługi2 godziny100
 Dezaktywacja dostępu do usługi24 godziny100
 Zmiana parametrów dostępu do usługi24 godziny100

Czytaj także: https://hybrydoweit.pl/blog/karta-uslugi-czesc-1