Odkąd zacząłem się zajmować zarządzaniem usługami IT, uważałem że wprowadzanie najlepszych praktyk ITIL należy zaczynać od katalogu usług. Nadal tak uważam, bo jak można zarządzać usługami nie wiedząc jakie mamy usługi i jaki poziom ich świadczenia (SLA) jest określony. Potwierdza to biblioteka ITIL, która w wersji 3 w 2007 roku, oprócz procesu „Zarządzanie poziomem usług„, wprowadziła dedykowany proces „Zarządzanie katalogiem usług”. Jeżeli mamy specjalnie dla katalogu usług proces do jego zarządzania, to chyba należy uznać, że katalog usług, jest bardzo ważnym narzędziem w zarządzaniu usługami IT. Zobaczmy co zawiera proces „Zarządzania katalogiem usług”

Cele

Celem procesu Zarządzania katalogiem usług jest dostarczenie i utrzymanie jednego, spójnego źródła informacji o wszystkich produkcyjnych i projektowanych usługach i zapewnienie, aby te informacje były dostępne dla jak najszerszego grona, uprawnionych odbiorców.

Proces koncentruje się na:

• Zarządzaniu informacjami zawartymi w katalogu usług
• Zapewnieniu, że katalog usług jest dokładny i odzwierciedla aktualny stan usług, które działają produkcyjnie lub są przygotowywane do wdrożenia na produkcji
• Zapewnieniu, że katalog usług jest dostępny dla wszystkich uprawnionych interesariuszy, w sposób który zapewnia efektywne wykorzystanie zgromadzonych w nim informacji
• Zapewnieniu, że katalog usług wspiera zmieniające się potrzeby pozostałych procesów zarządzania usługami, w zakresie informacji zawartych w katalogu usług

Zakres

Proces Zarządzania katalogiem usług, obejmuje swoim zakresem:

• Przygotowanie wsadu do definicji usług i pakietów usług
• Rozwój i utrzymanie opisów usług i pakietów usług, według ustalonych standardów
• Wytworzenie i utrzymanie prawidłowego katalogu usług
• Interfejsy, zależności i spójność pomiędzy katalogiem usług a portfolio usług
• Interfejsy i zależności pomiędzy usługami i usługami wspierającymi w katalogu usług i CMS
• Interfejsy i zależności pomiędzy usługami a komponentami wspierającymi i elementami konfiguracji, w katalogu usług i CMS

Proces Zarządzania katalogiem usług nie obejmuje:

• Gromadzenia, utrzymania i wykorzystania zasobów usługi i danych konfiguracji. Tym zajmuje się proces zarządzania zasobami i konfiguracją.
• Gromadzenia, utrzymania i spełnienia żądań o usługę. Tą aktywnością zajmuje się proces spełniania żądań (request fulfillment)

Korzyści dla biznesu

Efektywne zarządzanie katalogiem usług, pozwala na osiągnięcie następujących korzyści:

• Dostarcza biznesowi centralne źródło informacji o usługach IT, ich szczegółach, statusie, poziomie świadczenia, jakie procesy biznesowe wspierają, sposobie wykorzystania.
• Zapewnienie wspólnego rozumienia usług IT przez biznes i IT, skutkujące lepszymi relacjami pomiędzy klientem a dostawcą, poprzez wykorzystanie katalogu usług jako narzędzia marketingu i komunikacji
• Lepsza koncentracja dostawcy usług na wynikach klienta, dzięki powiązaniu wewnętrznych aktywności dostawcy usługi i zasobów usługi z procesami i wynikami biznesowymi
• Poprawa wydajności i efektywności pozostałych procesów zarządzania usługami IT, poprzez wykorzystanie informacji zawartych w katalogu usług
• Lepsza wiedza, dopasowanie i koncentracja na wartości dla biznesu, dla każdej usługi, po stronie dostawcy usług IT

Rodzaje usług

Katalog usług to nie zwykła lista usług ale pewna hierarchia i struktura, która pokazuje zależności pomiędzy procesami biznesowymi, usługami i SLA. Same usługi możemy podzielić na dwie główne grupy:

• Usługi udostępniane użytkownikowi, są to usługi które wspierają procesy biznesowe klienta, bezpośrednio dostarczające oczekiwanych wyników
• Usługi wspierające, są to usługi, które wspierają funkcjonowanie usług udostępnianych użytkownikowi i nie są przez niego widziane

Ja nazywam pierwsze usługami biznesowymi a drugie usługami systemu. Oczywiście nazw usług wspierających może być więcej: infrastrukturalne, sieciowe, aplikacyjne, techniczne itp. Niezależnie jak będą się nazywać, należy zadbać aby były jednoznacznie zdefiniowane, aby każdy zainteresowany rozumiał je w ten sam sposób.

Na poniższym rysunku (z książki ITIL Service Design) pokazano rodzaje usług, przykładowe usługi, ich relacje pomiędzy nimi, procesami biznesowymi i SLA. Daje on pewne wyobrażenie, co powinien zawierać katalog usług i jak ważnym jest narzędziem.

Podsumowanie

Proces Zarządzania katalogiem usług, jest jednym z najważniejszych na etapie projektowania usług oraz w całym cyklu życia usługi. Zapewnia, że:

• wszystkie usługi funkcjonujące produkcyjnie, będą w katalogu usług opisane
• będą określone relacje pomiędzy procesami biznesowymi a usługami udostępnianymi użytkownikowi (biznesowymi)
• będą określone relacje pomiędzy usługami biznesowymi a wspierającymi (systemu)
• informacje będą aktualne, prawidłowe i odzwierciedlające rzeczywistość produkcyjną.

Jeżeli zastanawiałeś się dlaczego potrzebny jest dedykowany proces dla zarządzania katalogiem usług, to teraz już chyba nie masz wątpliwości. Wykorzystaj go aby poprawić jakość świadczonych usług IT do biznesu.

Pytanie: Ile usług masz w katalogu usług i jakie są ich rodzaje?

Artykuł Zarządzanie katalogiem usług pochodzi z serwisu Mariusz Siek.

Usługi utrzymania, według najlepszych praktyk ITIL, powinny być świadczone przez każdą organizację utrzymania. Ich zakres i rodzaj powinien być dopasowany do potrzeb danej organizacji. Czy jednak każdy dyrektor IT (CIO), jest w pełni świadomy i przekonany, że warto zainwestować w zmianę i rozwój organizacji IT? Jak rozwiać wątpliwości i obawy CIO? Podejmę się tego trudnego zadania, aby wskazać najczęściej pojawiające się obawy i ustalić ich przyczynę oraz podać argumenty, które rozwieją wszelkie wątpliwości.

W jaki sposób utworzenie katalogu usług pomoże w mojej organizacji?

Żeby dotrzeć do sedna problemu musimy zadawać pytania pogłębiające.

• Czy IT wie jakie usługi świadczy dla biznesu?
• Czy dla świadczonych usług IT jest zdefiniowane i uzgodnione SLA?
• Czy biznes jest zadowolony ze świadczonych usług IT?

Pytań może być oczywiście więcej. Wszystko zależy jak szybko ustalimy przyczynę źródłową obawy.

Następnym krokiem jest podanie korzyści dla IT z wprowadzenia katalog usług.

• Kompletna informacja o usługach IT świadczonych dla biznesu
• Świadczenie usług IT na wyższym poziomie niż dotychczas
• Uzgodnione SLA wygrany-wygrany dla usług IT
• Zadowolenie Klientów biznesowych
• Łatwe i szybkie definiowanie nowych usług oraz SLA dla nich
• Partnerskie relacje pomiędzy biznesem a IT

Im więcej korzyści podamy, tym łatwiej będzie CIO, przezwyciężyć swoje obawy. Analogiczny schemat postępowania zastosuję dla kolejnych obaw i obiekcji biznesu.

Jaką wartość, uruchomienie lub optymalizacja procesów utrzymania, wniesie do świadczonych usług IT?

Pytania pogłębiające:

• Czy zgłoszenia, incydenty, problemy, service requesty, od użytkowników z biznesu rozwiązywane są w zadowalającym czasie?
• Czy działania IT postrzegane są jako dobrze zorganizowane i uporządkowane?
• Czy znane i zrozumiałe są odpowiedzialności ról po stronie biznesu i IT?
• Czy zawsze tak samo podchodzimy do powtarzalnych aktywności?

Korzyści:

• Ustalona ścieżka postępowania przy zgłaszaniu incydentów, problemów, service requestów, wpływająca na skrócenie czasu ich rozwiązania
• Określone zasady działania, w przypadku powtarzających się aktywności, ułatwiają ich sprawne wykonywanie
• Jasno określone odpowiedzialności poszczególnych ról, w procesach utrzymania, zapobiegające nieporozumieniom i zapewniające efektywne ich działanie
• Uporządkowanie komunikacji pomiędzy biznesem i IT, zwiększające poziom zaufania po obu stronach

Jak SLA poprawi postrzeganie usług IT przez biznes i użytkowników?

Pytania pogłębiające:

• Czy biznes i użytkownicy wiedzą jakie jest SLA na usługi IT, z których korzystają?
• Czy aktualny poziom świadczonych usług jest wystarczający dla biznesu?
• Czy Klienci biznesu dobrze postrzegają jego funkcjonowanie i są zadowoleni?
• Czy biznes nie chciałby mieć gwarancji świadczenia usług IT na uzgodnionym poziomie?

Korzyści:

• Zwiększenie świadomości biznesu i użytkowników, jakiego poziomu usług (SLA) mogą oczekiwać
• Uzgodnienie wyższego poziomu usług dla kluczowych dla biznesu usług IT
• Gwarancja od IT, że usługi będą świadczone na wymaganym i ustalonym przez strony poziomie
• Poprawa poziomu świadczonych usług, tam gdzie były negatywnie postrzegane przez biznes
• SLA jest narzędziem obrony przed biznesem, gdy oczekuje świadczenia usług na za wysokim poziomie

ITIL to ściema. Ktoś to wymyślił aby zarabiać na tym pieniądze

Pytania pogłębiające:

• Czy CIO zna przypadki, w tej lub innej organizacji, że wprowadzenie dobrych praktyk ITIL, pogorszyło poziom świadczonych usług IT?
• Czy CIO uczestniczył w szkoleniu ITIL Foundation, wprowadzającym i dającym podstawową wiedzę o ITIL?
• Czy wie, że ITIL powstał w oparciu o doświadczenia, najlepsze praktyki, z organizacji, z różnych branż, na całym świecie?
• Co konkretnie w ITIL mu się nie podoba?

Korzyści:

• ITIL w usystematyzowany sposób podchodzi do świadczenia usług utrzymania, wprowadzając ład i porządek
• ITIL można dostosować i dopasować do własnych potrzeb w organizacji IT
• Nie ma sensu wymyślać koła na nowo. Lepiej skorzystać z doświadczeń innym i zaadaptować je do własnych potrzeb
• Lepsze postrzeganie organizacji IT, która wykorzystuje najlepsze praktyki ITIL

Za co mi płaca w ramach świadczonych usług IT?

Pytania pogłębiające:

• Czy CIO wie, jaki jest koszt wytworzenia i utrzymania usług IT?
• Czy CIO wie, że poziom świadczonych usług SLA, wpływa na koszty dostarczenia i utrzymania usług IT?
• Czy znany jest model kosztowy usług IT?

Korzyści:

• Zdefiniowany i znany biznesowi i IT model kosztowy dostarczenia i utrzymania usług IT
• Zwiększona świadomość po stronie biznesu, które usługi ile kosztują i z czego to wynika
• Łatwiejsza i bardziej zrozumiała wycena kosztów dla nowych usług
• Efektywniejsze wykorzystanie środków finansowych w organizacji

Macie już procedury, narzędzia, ludzi i cały czas nie możecie dotrzymać SLA

Pytania pogłębiające:

• Dla których parametrów SLA, ich niedotrzymanie SLA, jest szczególnie odczuwalne przez biznes?
• Jak dużo zmian, nowych usług biznes wymaga aby były wdrażane?
• Co jest ważniejsze dla biznesu, wprowadzanie nowych funkcjonalności czy stabilizacja działania obecnych usług IT?

Korzyści

• Funkcjonujący proces ciągłej poprawy utrzymywanych usług IT w obszarach procedur, narzędzi, ludzi
• Zachowana równowaga pomiędzy potrzebami biznesu wprowadzania nowych zmian a stabilnością działania usług IT na produkcji
• Nieustanna poprawa jakości świadczonych usług utrzymania w celu dotrzymania wymaganego SLA

Dostarczcie mi oprogramowanie dobrej jakości to będę je utrzymywał i dotrzymam SLA

Pytania pogłębiające:

• Kto odpowiada za wytwarzanie i dostarczanie nowego oprogramowania?
• Jakie są stosowane metody weryfikacji, testowania oprogramowania w trakcie jego wytwarzania?
• Z iloma znanymi błędami z etapu wytwarzania, oprogramowanie jest wdrażane na produkcję?
• Czy osoba odpowiedzialna za utrzymanie ma wpływ na to, jakiej jakości oprogramowanie jest dostarczane?

Korzyści:

• Zwiększenie świadomości w zespołach wytwórczych (programiści, testerzy) jakie jakości oprogramowanie dostarczają
• Wprowadzenie akceptacji „utrzymania” przed wdrożeniem oprogramowania ze znanymi błędami
• Przygotowanie zespołów utrzymania do obsługi zgłoszeń, dotyczących nowych aplikacji

Nie mam pieniędzy na dedykowane role incydent managera, problem managera, change managera itp. To są darmozjady. Ja nie widzę efektów ich pracy

Pytania pogłębiające:

• Czy stać IT, na świadczenie usług, dla których nie jest dotrzymywane SLA?
• Na co warto wydać pieniądze? Na poprawę działania organizacji utrzymania czy kary umowne z nie dotrzymania SLA?
• Czy zna obowiązki ról utrzymaniowych, i które konkretnie ich odpowiedzialności są zbędne?

Korzyści:

• Dzięki incydent managerowi, rozwiązujemy więcej zgłoszeń w czasach SLA
• Problem manager, przyczynia się do rozwiązywania problemów, które generują powtarzające się incydenty. W ten sposób mamy mniej zgłoszeń.
• Change manager jest policjantem, który pilnuje aby na system produkcyjny, nie zostały wdrożone zmiany, które wcześniej nie zostały zweryfikowane i potwierdzone, że nie destabilizują działania aktualnie wykorzystywanego oprogramowania

To wybrane obawy, jakie mogą powstrzymywać CIO, przed stosowaniem najlepszych praktyk w utrzymaniu usług IT. Mam nadzieję, że pokazałem w jaki sposób można przekonywać osoby odpowiedzialne za utrzymanie, do metodycznego podejścia do świadczenia usług utrzymania. Oczywiście najlepszym argumentem dla CIO byłby oszczędności pieniędzy. Nie zawsze jednak można takie argumenty podać, bo nie wszystkie korzyści można zmierzyć miarą finansową. Im więcej korzyści podamy, tym łatwiej będzie nam wpłynąć na zmiany w organizacji IT.

Pytanie: Które korzyści przekonują Cię najbardziej?

Artykuł Obiekcje CIO w stosowaniu usług utrzymania pochodzi z serwisu Mariusz Siek.

Dzisiejszy świat jest oparty na pieniądzu i można się z tym zgadzać lub nie ale bez pieniędzy nie można żyć. IT nie jest tu wyjątkiem i również musi kierować się zasadami finansowymi. Czy jednak biznes wie i ma świadomość ile płaci za usługi IT i co ramach tych usług otrzymuje? Analogicznie czy IT rozumie, jak działanie usług IT wpływa na biznes i jakie rodzi konsekwencje finansowe?

Wycena usług IT świadczonych dla biznesu

Każde szanujące się IT powinno umieć pokazać biznesowi ile kosztują usługi, które dla niego świadczy. I nie mam tu na myśli podania jednej kwoty, która jest budżetem IT w danej organizacji, którą pewnie ważne dla organizacji osoby znają. Jest potrzeba, a właściwie przymus, aby umieć pokazać koszty pojedynczej usługi, dodatkowo wskazując, co na ten koszt się składa. W ten sposób świadomość po stronie IT jak i biznesu wzrośnie i pozwoli skoncentrować siły, na najważniejszych elementach, w celu optymalizacji kosztów usług. W pierwszej kolejności należy zapewnić aby usługa była świadczona zgodnie z SLA, a drugiej aby koszt jej świadczenia był jak mniejszy.

Każdą usługę należy wyceniać indywidualnie i podanie prostego wzoru, jest raczej nie możliwe. Zakładając jednak, że większość usług IT to jakaś aplikacja lub jej funkcjonalność udostępniana użytkownikowi, należy skoncentrować się na następujących aspektach:

• Wytworzenie usługi IT (aplikacji, systemu, rozwiązania)
  • Dostawca zewnętrzny czy wewnętrzny
  • SLA dla usługi
• Utrzymanie usługi IT
  • Zespoły wsparcia (I, II i III linia wsparcia, menedżerowie)
  • Infrastruktura sprzętowo-programowa (hardware i software)

Wytworzenie usługi IT – jaki dostawca?

Na początku usługę IT należy wytworzyć, więc powołujemy projekt, który w ustalonym czasie, a częściej po jego przekroczeniu :-), dostarczy działającą aplikację, system, rozwiązanie. Jeżeli mamy do czynienia z dostawcą zewnętrznym, to w umowie z nim mamy określone za ile zostanie usługa dostarczona. Czy tak będzie to już inna bajka ale musimy tylko pilnować realizacji umowy, aby za ustalone pieniądze dostawca wytworzył usługę o określonych parametrach SLA. O samych parametrach SLA za chwilę.

Jeżeli mamy dostawcę wewnętrznego to, w większości organizacji powoływany jest projekt, którego celem jest dostarczenie, zdefiniowanych w nim produktów. Tu jest prosto, bo każdy kierownik projektu, powinien znać bardzo dobrze koszty jego prowadzenia i podać je w nocy o północy. Co jednak jest składową tych kosztów:

• Zarządzanie projektem – kierownik projektu i wszystko to, co jest do prowadzenia projektu potrzebne, np. PMO.
• Praca programistów – czas spędzony na wytworzenie oprogramowania i poprawy wykrytych błędów pomnożony przez stawkę. Im więcej błędów tym koszt wytworzenia rośnie, bo programiści zamiast pisać nowe linie kodu, poprawiają te już napisane.
• Praca testerów – czas spędzony na weryfikacji oprogramowania w testach regresji, funkcjonalnych, niefunkcjonalnych (np. bezpieczeństwa, wydajnościowych) pomnożony przez stawkę. Najlepiej jakby tak wytestować aplikację, aby po wdrożeniu było jak najmniej błędów. To oczywiście pobożne życzenia. Pamiętajmy jednak, że jeżeli, za mało „wydamy” na testowanie na etapie rozwoju (developmentu), to odbije się to nam podczas etapu utrzymania. Tak czy siak poniesiemy ten koszt, tylko może z innej puli. Kto by się przejmował, że użytkownik będzie miał trudności w korzystaniu z aplikacji z błędami.
• Praca pozostałych osób z zespołu wytwórczego – analitycy, architekci, scrum masterzy, delievery managerowie itp. Skrupulatnie liczmy i dodajemy do pozostałych kosztów.
• Infrastruktura sprzętowo-programowa – na etapie wytwarzania należy zadbać o odpowiednią infrastrukturę sprzętowo-programową, na której będzie działać oprogramowanie. Dobór infrastruktury powinien zostać wykonany przez architekta z osobą z zespołu infrastruktury, który za nią będzie później odpowiadał. Oddzielnie liczymy koszty hardware’u i software’u czyli licencji. Uwzględniamy okres maintenance’u dla sprzętu i oprogramowania. To jest infrastruktura dedykowana dla konkretnej aplikacji. Jeszcze będzie infrastruktura wspólna ale o tym przy okazji kosztów utrzymania.

Wytworzenie usługi IT – jakie SLA?

Na koszt dostarczenia usługi, bardzo duży wpływ ma SLA. Jeżeli biznes wymaga wysokiego SLA, to przekłada się to na rozwiązanie architektoniczne, a tym samym, potrzebne technologie i infrastrukturę, które decydują o koszcie usługi IT. Nie należy o tym zapominać i IT powinno uświadamiać biznes jakie są konsekwencje np dostępności na poziomie 99,99%, czasu rozwiązania wynoszącego 4 godziny i czasu przywrócenia usługi po awarii w 2 godziny. Koszty związane z SLA powinny zostać uwzględnione w architekturze rozwiązania oraz organizacji utrzymania (zespoły wsparcia).

Utrzymanie usług IT – zespoły wsparcia

I tutaj zaczynają się schody, bo jak policzyć pracę zespołów wsparcia dla pojedynczej usługi (aplikacji)?

• Dla I linii wsparcia (Service Desk) – robimy to na podstawie zgłoszeń zarejestrowanych w narzędziu ITSM, sprawdzając ile czasu poświęcono na zgłoszenia dla danej aplikacji. Nie zawsze jednak czas obsługi zarejestrowany na pierwszej linii wsparcia jest czasem poświęconym dla konkretnej usługi. Musimy przyjąć założenia, na podstawie których będziemy liczyć.
• Dla drugiej linii wsparcia (zespół utrzymania, infrastruktury) – możemy podobnie jak dla Service Desk oprzeć się na narzędziu ITSM. Jednak praca osób odpowiedzialnych za aplikację i infrastrukturę to nie tylko zgłoszenia. Nikt nie rejestruje czasu poświęconego na daną aplikację, gdy do obsługi ma takich aplikacji kilka i dla wszystkich wykonuje różne czynności operacyjne. Szacujemy więc i ustalmy ile osób zajmuje się konkretną aplikacją/infrastrukturą i ile procentowo czasu na nią poświęca. W ten sposób wyznaczymy interesująca nas wartość.
• Dla III linii wsparcia (zespół wytwórczy, dostawca zewnętrzny) – liczmy tak jak Service Desk na podstawie zgłoszeń z ITSM. Tu nie ma problemu, bo III linia wsparcia obsługuje tylko błędu.

Utrzymanie usług IT – infrastruktura sprzętowo-programowa

Infrastrukturę sprzętową, czy korzystamy z chmury czy dedykowanego centrum przetwarzania danych, liczymy uwzględniając sprzęt i oprogramowanie. Nie jest to trudne, gdy dana aplikacja działa na dedykowanym sprzęcie i oprogramowaniu. Stopień skomplikowania zaczyna się, gdy usługa korzysta ze wspólnej bazy danych, rozwiązania bezpieczeństwa (np. firewall) lub sieci WAN i LAN. W takim przypadku możemy podejść albo prosto, dzieląc po równo dany zasób pomiędzy dwie, trzy lub więcej usług. Możemy również wykonać trochę pracy i zmierzyć w jakim stopniu usługi wykorzystują dany zasób i podzielić go pomiędzy usługi proporcjonalnie. Im na większej dokładności nam zależy tym musimy zastosować taki model, który najwierniej będzie odzwierciedlał rzeczywistość.

Policzenie kosztów usług, to trudny i pracochłonny proces, który jednak warto podjąć i wykonać. Sami się zdziwicie jak wiele ciekawych informacji można uzyskać wykonując takie ćwiczenie. Nie jest to na pewno czas stracony. Podjęty wysiłek opłaci się w dłuższym okresie czasu. IT będzie wiedziało jak wyceniać nowe usługi a biznes będzie świadomie podejmował decyzje w sprawie wymagań, które bezpośrednio lub pośrednio wpływają na koszt końcowy usługi.

Pytanie: Jak i jakie koszty usług IT liczysz w swojej organizacji?

Artykuł Ile kosztują usługi IT? pochodzi z serwisu Mariusz Siek.

Ostatnio dużo piszę o SLA i wydaje mi się, że nadal nie wyczerpałem tematu :-). W publikacji „SLA wygrany-wygrany” wskazywałem na potrzebę równowagi w SLA, pomiędzy wymaganiami biznesu a możliwościami IT. Natomiast w artykule „Jak funkcjonować z niekorzystnym SLA dla zamawiającego lub dostawcy”, zwracałem uwagę jak radzić sobie, gdy jednak SLA dla jednej ze stron jest dużo bardziej korzystne. Czy może być jeszcze gorzej. Według mnie może, gdy nie mamy żadnego SLA, a mimo to IT musi świadczyć usługi dla biznesu. Dla kogo jest to bardziej niekorzystna sytuacja? Wydaje się, że traci na tym biznes ale czy tylko? Zastanówmy się, jakie są konsekwencje takiej sytuacji w rzeczywistości i co można zrobić aby ją zmienić.

Nie mamy SLA i co nam zrobisz?

Dobrze przygotowane i uzgodnione SLA zabezpiecza interesy zamawiającego czyli biznesu i dostawcy czyli IT. Co jednak oznacza brak SLA dla wzajemnych relacji i działania operacyjnego?

Nie mamy ustalone, na jakim poziomie mają być świadczone usługi, co oznacza że nie wiemy czy są dostarczane we właściwy sposób. Co to oznacza w praktyce?

• Nie jest określone jaka powinna być dostępność usług. Czy wystarczające jest 95% a może 98 lub 99%? W jakim kalendarzu powinny być świadczone usługi?
• Nie mamy zdefiniowanej wydajności i wolumetrii usług. Czy czasy odpowiedzi są odpowiednie krótkie: 5, 3 a może 1 sekunda? Czy ilość wywołań usług jest na poziomie, dla jakiego zostały zaprojektowane usługi? A może nikt nie zastanawiał się tworząc te usługi?
• Nie ustalono jaki powinien być czas reakcji i rozwiązania, w przypadku pojawienia się zgłoszeń od użytkowników. Jak szybko zareagują zespoły wsparcia i w jakiem czasie usuną incydent lub problem? Czy 30 minut na czas reakcji jest wystarczające? Ile powinien wynosić czas rozwiązania w zależności od priorytetu zgłoszenia? 4, 8 godzin a może 1, 2 5 dni?
• Nie przewidziano w jakim czasie należy przywrócić usługi do działania, w przypadku wystąpienia katastrofy. Czy biznes może funkcjonować bez usług IT 1, 2 czy 4 dni?

Podałem przykładowe parametry SLA i możliwe wartości dopuszczalne dla nich, aby pokazać, jakie są konsekwencje braku SLA. Co można zrobić w takiej sytuacji? Rozwiązania na pewno się znajdą ale wymagają dobrej woli obu stron: biznesu i IT.

Zacznij od mierzenia SLA

Jak mam mierzyć coś czego nie ma? SLA to w dużym uproszczeniu lista parametrów, dla których zostały określone wartości dopuszczalne. Dlatego jeżeli nie mamy żadnego SLA, to na początek ustalmy, biznes i IT wspólnie, jakie parametry SLA chcielibyśmy mieć. Jak już będziemy mieli ustalone parametry SLA, musimy zacząć je mierzyć, czyli wyznaczać ich wartości rzeczywiste. Jak mierzyć parametry SLA możesz przeczytać w moich dwóch publikacjach „Jak mierzyć parametry SLA część 1” i „Jak mierzyć parametry SLA część 2„. Mierzenie parametrów SLA jest pierwszym krokiem do uzgodnienia SLA. Kolejnym jest liczenie wartości rzeczywistych parametrów SLA.

Licz wartości rzeczywiste parametrów SLA

Jak już mierzymy i zbieramy wartości parametrów SLA, możemy zacząć wyznaczać wartości rzeczywiste tych parametrów za ustalony okres czasu: dzień, tydzień, miesiąc, kwartał, rok. Policzone wartości pokazują nam na jakim poziomie świadczone są usługi dla poszczególnych parametrów SLA. Możemy porównywać te wartości dzień do dnia, tydzień do tygodnia, miesiąc do miesiąca itd. Uzyskana w ten sposób wiedza, pozwala nam na analizę wartości rzeczywistych i poznanie trendów oraz możliwości organizacji IT. Jest to nie ocenione źródło informacji, jak działają usługi i organizacja utrzymania, która wspiera prawidłowe funkcjonowanie usług IT.

Ustal wartości dopuszczalne parametrów SLA

Wyznaczane regularnie wartości rzeczywiste parametrów SLA, są podstawą do ustalenia, jakie powinny być wartości dopuszczalne dla tych parametrów. Według mnie można do najwcześniej zrobić posiadając dane z przynajmniej 3 miesięcy. Jednak aby nasza prognoza była lepsza, lepiej dysponować danymi z 6 a najlepiej z 12 miesięcy. Pierwsza propozycja wartości dopuszczalnych parametrów SLA powinna być średnią wartości rzeczywistych z liczby miesięcy, za które posiadamy dane. Im więcej miesięcy tym wartość dopuszczalna lepiej będzie odzwierciedlać możliwości IT. Co jednak, gdy wyznaczone wartości dopuszczalne, nie spełniają oczekiwań biznesu?

Rozpocznij negocjacje i uzgodnij SLA

Jeżeli wartości dopuszczalne parametrów SLA nie spełniają wymagań biznesu, obie strony myszą siąść do rozmów i rozpocząć negocjacje, których celem będzie ustalenie takich wartości SLA, które będą korzystne dla obu, biznesu i IT. Strategii negocjacyjnych jest bardzo dużo, nie chodzi jednak aby jedna strona przechytrzyła drugą ale aby porozumiały się, co do wspólnych parametrów. Zrozumiałe jest, że biznes będzie chciał jak najlepsze wartości dla siebie a IT dla siebie. Mimo tego musi dojść do kompromisu. Pamiętajmy, że biznes, nie ma żadnego SLA, dlatego powinien dążyć do ustalenia SLA, które będzie z korzyścią dla obu stron. Przecież, jeżeli nie ma SLA, to IT nie zgodzi się na SLA, którego nie będzie mogło spełnić.

Najważniejsze jest mierzenie wartości rzeczywistych parametrów SLA i otwartość biznesu i IT, do rozmów na temat jakie SLA będzie korzystne dla obu stron. Bez woli współpracy i wypracowania wspólnego rozwiązania, nie będzie możliwe doprowadzenie do uzgodnienia SLA i nadal nie będzie żadnego SLA. Taki scenariusz jest najgorszy z możliwych i niekorzystny dla zamawiającego i dostawcy.

Pytanie: Jak rozwiązałeś sytuacje braku SLA w swojej organizacji?

Artykuł Co zrobić jeżeli brak jest SLA? pochodzi z serwisu Mariusz Siek.

Zdefiniowanie i uzgodnienie SLA, które będzie korzystne zarówno dla biznesu jak i IT, wymaga wiedzy i doświadczenia. Nie jest łatwo pogodzić wysokie wymagania biznesu z często ograniczonymi możliwościami IT. Ktoś może powiedzieć, że co to za filozofia napisać SLA i uzgodnić, przecież IT jest dla biznesu a nie odwrotnie. Opracowanie i uzgodnienie SLA, powinno prowadzić do sytuacji wygrany-wygrany, w przeciwnym razie zapewnienie najwyższej jakości usług przez IT dla biznesu, będzie niemożliwe.

Jakich błędów nie popełnić i jak ich uniknąć?

1Brak partnera po stronie biznesu

Przygotowanie i uzgodnienie SLA wymaga dwóch stron: biznesu i IT. Często zdarza się, że strony biznesowej nikt nie reprezentuje. Bez wiarygodnego i decyzyjnego partnera po stronie biznesu, nie jest możliwe uzgodnienie dobrego SLA. W większości przypadków inicjatorem SLA jest IT i to ono przygotowuje propozycję SLA, która jest przedstawiana biznesowi. Jeżeli biznes, nie znajdzie w swoich szeregach osób, które krytycznie ale konstruktywnie spojrzą na propozycję SLA przygotowaną przez IT, to:

• Po pierwsze będzie to SLA jednostronne
• Po drugie nie można będzie go uzgodnić
• Po trzecie faktycznie nie będziemy mieli żadnego SLA, bo SLA nie uzgodnione jest bezwartościowe

Aby zaradzić tej sytuacji, należy jeszcze przed rozpoczęciem przygotowywania SLA przez IT, wystąpić do biznesu z prośbą, o wskazanie biznesowego właściciela usługi/usług, który będzie odpowiadał za uzgodnienie SLA z IT.

2Brak uprawnień

Aby SLA mogło zostać uzgodnione i obowiązywało obie strony, biznesowy właściciel usługi musi mieć wymagane uprawnienia do reprezentowania biznesu. Bez takich uprawnień nie będzie możliwe podpisanie SLA. Należy zadbać aby osoba pełniąca rolę biznesowego właściciela usługi, zajmowała „wysoką” pozycję w organizacji.

3Brak wymagań biznesowych

Jeżeli już mamy partnera po stronie biznesu, to może się okazać, że nie ma wymagań niefunkcjonalnych związanych z działaniem usługi/usług. Brak wymagań biznesowych może wynikać z:

• Braku kompetencji po stronie biznesu. Najzwyczajniej w świecie, biznes nie wie co to jest SLA i trudno mu odnieść się do propozycji przedstawionej przez IT
• Brak doświadczenia. Nigdy nie uzgadniali SLA i nie mają skali porównawczej, do której mogą się odnieść.

W tym przypadku, rolą IT jest wyedukować biznes z wymagań niefunkcjonalnych i parametrów SLA.

4Zbyt duże wymagania biznesu

Również niekorzystna sytuacją jest, gdy biznes ma zbyt duże wymagania, co do SLA. Wtedy bardzo trudno jest uzgodnić SLA, ponieważ, żadna ze stron nie chce ustąpić, broniąc swoich racji. IT znając swoje możliwości, nie chce zgodzić się na wygórowane wymagania biznesu. Biznes chcąc zapewnić jak najwyższą jakość usług, nie chce złagodzić swoich wymagań. Sytuacja jest patowa.

Jako jej rozwiązanie, proponuję aby IT przedstawiło jakie są koszty związane ze świadczeniem usługi/usług na wysokim poziomie oczekiwanym przez biznes. Język finansów, powinien pomóc w złagodzeniu wymagań biznesowych lub spowodować dodanie pieniędzy do budżetu IT.

5Niewłaściwe zdefiniowanie parametrów SLA

Definiując każdy parametr SLA, trzeba pamiętać aby był dostosowany do usługi i odzwierciedlał wymagania biznesu. Jeżeli opracujemy parametr, który nie będzie odpowiadał na wymagania biznesowe, to nie oczekujmy, że biznes będzie z tego zadowolony i wysoko będzie oceniał jakość naszych usług. Pokazujmy biznesowi jakie są możliwości i konsekwencje przygotowanej definicji parametru, aby był świadomy jaki ma wybór.

IT odpowiada za poprawne zdefiniowanie parametrów SLA i powinno o tym zawsze pamiętać.

6Brak narzędzi do mierzenia SLA

Każde SLA, nawet to najlepsze dla obu stron, jest nic nie warte, jeżeli nie potrafimy go mierzyć. Bez odpowiednich narzędzi, IT nie będzie w stanie wykazać, czy spełnia czy nie obowiązujące SLA. Jeżeli IT nie zadba o ten aspekt, będzie narażona ze strony biznesu na oskarżenia, że świadczy usługi na nie wystarczających poziomie. Niestety, nikt nie będzie mógł tego udowodnić ale niezadowolenie biznesu, będzie skutkowało co raz gorszymi relacjami z IT.

Po stronie IT leży odpowiedzialność, przygotowania odpowiednich narzędzi, które będą mierzyły i wyznaczały, poszczególne parametry SLA.

Mam nadzieję, że przybliżenie, jakie błędy można popełnić przygotowując i uzgadniając SLA, pozwoli chociaż w części ich uniknąć.

Pytanie: Z którym błędem masz najczęściej do czynienia i jak sobie z nim radzisz?

Artykuł 6 najczęściej popełnianych błędów w SLA pochodzi z serwisu Mariusz Siek.

Zagadnienie jak mierzyć parametry SLA jest bardzo rozległe i jego rzetelne przedstawienie, wymagało podzielenia materiału na dwie części. W pierwszej części opisałem parametry SLA związane z dostępnością i czasem rozwiązania. W części drugiej rozwinę temat czasu rozwiązania i czasu reakcji oraz wydajności.

Czas rozwiązania

Czas rozwiązania może dotyczyć zarówno incydentów, problemów jak i service requestów. Zasady związane z mierzeniem czasu rozwiązania są dla wszystkich analogicznie. Kluczowe jest ustalenie:

• czasu rozpoczęcia
• czasu zakończenia
• zatrzymania czasu rozwiązania

Przykładowe zdarzenia rozpoczynające i kończące czas rozwiązania, podałem w części pierwszej. Oczywiście, które powinny być użyte do mierzenia czasu rozwiązania zależy, kto ten parametr definiuje. Dostawca, czy to w postaci wewnętrznego działu IT czy firmy zewnętrznej, będzie dążył do „skracania” początku i końca związanego z czasem rozwiązania. Oznacza to, że będzie wybierał te zdarzenia, które są korzystne dla niego. Jako rozpoczęcie będzie wskazywał, potwierdzenie przez Service Desk przyjęcia zgłoszenia, a jako zakończenie, rozwiązanie zgłoszenia przez zespoły wsparcia. 

Klient, nazywany również biznesem, będzie chciał aby czas rozwiązania obejmował jak najszerszy przedział czasu. Jest to jak najbardziej naturalne postępowanie obu stron :-).

Do wyjaśnienia pozostaje jeszcze kwestia zatrzymywania czasu rozwiązania. Jest to sposób na wydłużanie czasu rozwiązania, w sytuacji gdy zespoły wsparcia nie mogą rozwiązywać zgłoszenia, ponieważ:

• Nie mogą odtworzyć błędu i potrzebują kontaktu ze zgłaszającym
• Brakuje im wymaganych w zgłoszeniu danych
• Do rozwiązania potrzebują interakcji ze zgłaszającym

Oczywiście mówimy tu o zatrzymywaniu czasu rozwiązania, tylko w uzasadnionych przypadkach. Nie można dopuścić do sytuacji, w której zatrzymywany jest czas rozwiązania, aby „sztucznie” wydłużyć jego trwanie. Z drugiej strony, nie może być wliczane do czasu rozwiązania oczekiwanie na kontakt, ze zgłaszającym, który jest zajęty lub nieobecny w pracy.

Czas reakcji

Z czasem reakcji jest trochę łatwiej, niż z czasem rozwiązania, jednak musimy uważać na jego rozpoczęcie. Zakończenie czasu reakcji jest mniej problematyczne i przeważnie jest nim potwierdzenie przez Service Desk przyjęcia zgłoszenia. Bardzo często to potwierdzenie jest automatyczne, po zarejestrowaniu zgłoszenia w systemie ITSM lub wysłaniu emaila na określony adres.

Zwrócić należy uwagę na rozpoczęcie czasu reakcji, który może być mierzony od:

• Odebrania zgłoszenia telefonicznego przez operatora Service Desk
• Wysłania emaila na wskazany adres
• Zarejestrowania zgłoszenia w systemie klasy ITSM

W zależności, które zdarzenie wybierzemy, będziemy mieli inną wartość czasu reakcji.

Bardzo ważne jest, aby ustalić z biznesem, początek i koniec czasu reakcji i rozwiązania, aby nie było później nieporozumień, co do ich mierzenia i rozliczania.

Wydajność

Jak mierzyć parametry SLA dla wydajności, wolumetrii i czasu odpowiedzi, jest bardzo złożonym zagadnieniem obszaru SLA.

• Po pierwsze, należy zwrócić uwagę, czy pomiar jest wykonywany z perspektywy systemy czy użytkownika końcowego. Bardzo często mierzymy czas odpowiedzi na serwerze aplikacyjnym, nie uwzględniając opóźnień sieciowych i innych występujących pomiędzy użytkownikiem końcowym a systemem/aplikacją IT.
• Po drugie, jakie operacje, czynności podlegają pomiarowi. Aby optymalizować kosztowo testy wydajnościowe, uwzględnia się tylko najważniejsze i najczęściej wykorzystywane ścieżki działania użytkownika. Może to prowadzić do nie mierzenia w ogóle, pewnych aktywności w systemie.
• Po trzecie, testy wydajnościowe przeprowadzane są najczęściej na środowisku testowym, które nie odzwierciedla w 100% środowiska produkcyjnego, co może skutkować niedokładnością pomiaru. Dodatkowo, testy wydajnościowe przeprowadzane są przeważnie raz, podczas tworzenia systemu/aplikacji. Aby weryfikacja podczas testów wydajnościowych była wiarygodna, powinno się je powtarzać okresowe co 3 lub 6 miesięcy.
• Po czwarte, testy wydajnościowe nie mierzą rzeczywistej wolumetrii i czasów odpowiedzi, tylko wyznaczają wartości w środowisku laboratoryjnym. Aby mierzyć wartości rzeczywiste, w środowisku produkcyjnym, należy wybrać jedną z możliwości:
  • Uruchomić i skonfigurować narzędzie monitorowania wydajności, np. appDynamics aby móc na bieżąco, mierzyć parametry wydajnościowe
  • Zaprojektować i wdrożyć mechanizm, wyznaczania czasów pojedynczych wywołań, dla poszczególnych usług. Czasy te powinny być zapisywane w dedykowanej tabeli, na podstawie której można będzie wyliczyć, wymagane parametry wydajnościowe

Zagadnienia pomiaru wydajności są bardzo ciekawe i wielowątkowe, dlatego pomyślę aby opisać je bardziej szczegółowo w oddzielnym artykule.

Tak naprawdę, to przedstawiłem tylko najważniejsze kwestie związane z mierzeniem wybranych, najczęściej stosowanych parametrów SLA. Mam nadzieję, że zainteresowałem Ciebie tą wiedzą. Jeżeli masz pytania, napisz je w komentarzu. Chętnie na wszystkie odpowiem. Na koniec pytanie ode mnie.

Pytanie: Jak mierzysz rzeczywiste wartości parametrów wydajnościowych?

Artykuł Jak mierzyć parametry SLA – część 2 pochodzi z serwisu Mariusz Siek.

Tworząc katalog usług często pamiętamy, aby dobrze zdefiniować usługi i później rzetelnie określić dla nich SLA. Czy jednak zastanawiamy się, jak będziemy mierzyć wartości rzeczywiste poszczególnych parametrów? Na ile wykonane pomiary, będą odzwierciedlać rzeczywisty poziom usług odczuwany przez użytkownika? Posiadanie SLA bez jasno i precyzyjnie wskazanych metod pomiarowych, w jaki sposób będziemy wyznaczać wartości rzeczywiste, jest niewystarczające, aby dobrze rozliczać SLA.

Czym jest metoda pomiarowa?

Ustalając z biznesem poszczególne parametry poziomu usług, powszechnie nazywane SLA, musimy oprócz podania ich wartości dopuszczalnych, pokazać jak będą wyznaczane wartości rzeczywiste tych parametrów. Sposób wyznaczania wartości rzeczywistych nazywam metodą pomiarową. Aby precyzyjnie ją opisać należy zdefiniować wzór, według którego będzie wyznaczana wartość rzeczywista parametru oraz opisać wszystkie symbole we wzorze. Nie będę tutaj podawał szczegółowych wzorów ale chciałbym zwrócić uwagę, na najważniejsze sposoby liczenia, dla poszczególnych parametrów SLA.

Dostępność

Dostępność usługi biznesowej można liczyć na dwa sposoby

• Pierwszy, polega na mierzeniu w narzędziu monitorowania dostępności poszczególnych usług systemowych/technicznych, wchodzących w skład usługi biznesowej.
• Drugi, polega na mierzeniu czasu rozwiązania incydentów, powodujących niedostępność usługi biznesowej dla użytkowników.

W obu przypadkach należy pamiętać, o okresie za jaki liczona jest dostępność usługi biznesowej. Najczęściej liczymy ja za okres jednego miesiąca. Wynika to z okresu, za jaki rozliczamy się z biznesem, ze świadczenia danej usługi biznesowej

Narzędzie monitorowania dostępności

Opierając się na narzędziu monitorowania dostępności (np. Nagios), dostępność usługi biznesowej wyznacza się na podstawie dostępności poszczególnych usług systemowych/technicznych. Może to być prosta zależność, że niedostępność jednej usługi systemowej/technicznej oznacza niedostępność całej usługi biznesowej. Możemy skomplikować ten model i dodać wagi, określające wpływ usługi systemowej/technicznej na dostępność usługi biznesowej. Zastosowanie konkretnego rozwiązania zależy od złożoności usługi biznesowej i naszych potrzeb.

Ważnym zagadnieniem jest również czy mierzymy dostępność usług systemowych od wewnątrz, czyli z perspektywy IT. Czy od zewnątrz z perspektywy użytkownika końcowego. Oba sposoby mogą dawać znacząco różne wyniki dostępności usługi biznesowej.

Narzędzie klasy ITSM

Korzystając z narzędzia klasy ITSM, wyznaczamy czasy rozwiązania, dla poszczególnych incydentów, które powodowały niedostępność usługi biznesowej dla użytkownika. Suma czasów rozwiązania incydentów, wyznacza dostępność w % oraz niedostępność usługi biznesowej. Oczywiście oddzielnym zagadnieniem jest, jak liczony jest czas rozwiązania incydentu, ale o tym później.

Który sposób liczenia dostępności jest lepszy? Bardziej dokładna jest pierwsza metoda pomiaru, ponieważ mierzymy faktyczną niedostępność usługi biznesowej, niezależnie czy była czy nie była, wykorzystywana przez użytkownika. W drugiej metodzie mierzymy tylko tą niedostępność usługi biznesowej, widzianą z perspektywy użytkownika końcowego.

Pozostawiam czytelnikom do wyboru, która metoda jest dla nich bardziej odpowiednia.

Czas rozwiązania incydentu

Dla czasu rozwiązania incydentu należy określić jego początek i koniec. Liczenie czasu rozwiązania może zaczynać się od:

• otrzymania zgłoszenia przez I linię wsparcia
• przyjęcia zgłoszenia przez I linię wsparcia 
• potwierdzenia przez Service Desk przyjęcia zgłoszenia

Zakończenie liczenia czasu rozwiązania może być spowodowane przez:

• rozwiązanie incydentu przez zespoły wsparcia
• dostarczenie skutecznego rozwiązania do użytkownika
• wdrożenie rozwiązania na produkcję

Do Waszej rozwagi pozostawiam, który początek i koniec czasu rozwiązania powinno się wybrać .

Omówienie kolejnych parametrów SLA, opiszę w następnej publikacji.

Pytanie: Jak w Twojej organizacji wyznaczasz dostępność?

Artykuł Jak mierzyć parametry SLA – część 1 pochodzi z serwisu Mariusz Siek.

W celu lepszego zrozumienia i pokazania jak należy tworzyć katalog usług wcieliłem się w postać Marka Zuckerberga, twórcy najbardziej znanego i najpopularniejszego portalu społecznościowego Facebook. Przygotuję katalog usług dla Facebooka dla wybranej usługi biznesowej i usługi systemu. Oczywiście będą to przeze mnie wymyślone usługi z parametrami jakie według mnie powinny posiadać ale jak najbardziej zbliżone do realnych. Może Mark z nich skorzysta ?

Definiowanie usługi biznesowej

• Nazwa usługi – Konto dla użytkownika indywidualnego

• Opis usługi – usługa umożliwia dostęp do konta na portalu Facebook dla użytkowników indywidualnych z urządzeń stacjonarnych i mobilnych. Użytkownik po zalogowaniu może korzystać ze wszystkich funkcjonalności w ramach swojego profilu

• Ważność dla biznesu– krytycza, ze względu na fakt, że jest to jedna z głównych funkcjonalności portalu. Oprócz niej są jeszcze inne takie jak np. FunPage, promowanie postów

• Termin wdrożenia na produkcję – 4.02.2004 (według https://pl.wikipedia.org/wiki/Facebook#Utworzenie)

Parametry usługi biznesowej

• Role – trochę przekornie podałem prawie wszędzie Marka Zuckerberga jako pełniącego wszystkie role (oprócz użytkownika) ale tak naprawdę w 2003/2004 roku tak było

  • Właściciel usługi biznesowej – Mark Zuckerberg,

  • Użytkownik/Użytkownicy – wszystkie osoby mające dostęp do internetu

  • Kierownik Projektu – Mark Zuckerberg

  • Service Level Manager – Mark Zuckerberg

  • Service Manager/Owner – Mark Zuckerberg

  • Analityk – Mark Zuckerberg

  • Architekt, Architekt infrastruktury, Architekt bezpieczeństwa – Mark Zuckerberg

• Ciągłość działania (BCP) – usługa jest krytyczna dla Facebook. Na niej opiera się najważniejszy biznes FB wię jest krytyczna i musi być uwzględniona w BCP. Nie robię analizy ryzyka ale od razu wiem, że wartości dla wartości dla dwóch parametrów powinny być następujące:

  • Recovery Time Objective (RTO) = 0 godzin 0 minut – FB nie może pozwolić sobie na niedostępność swojej krytycznej i najważniejszej usługi dlatego zostosowano rozwiązania High Availability, zapewniające ciągłość działania nawet w przypadku wystąpienia awarii

  • Recovery Point Obejctve (RPO) = 0 godzin 0 minut – FB nie może sobie pozwolić na utratę jakichkolwiek danych

• Bezpieczeństwo

  • metoda uwierzytelniania/dostępu – login i hasło, można ustawić two-factor authentication, który zwiększa poziom bezpieczeństwa poprzez potwierdzenia określonych czynności specjalnym kodem wysyłanym sms ma telefon komórkowy

  • polityka haseł – dostępna funkcjonalność, która pokazuje podczas zmiany hasła czy spełnia określone wymagania: długość, złożoność itp

  • odzyskiwanie hasła – działa funkcja przypominania hasła w przypadku jego zapomnienia

Definiowanie usługi systemu

• Nazwę usługi – Publikacja posta na profilu prywatnym

• Opis usługi – usługa umożliwia opublikowanie posta w formie tekstu, zdjęcia, wideo, aktywności na profilu prywatnym przez jego właściciela z urządzenia stacjonarnego lub mobilnego

• Ważność dla biznesu – krytycza, ze względu na fakt, że jest to jedna z głównych funkcjonalności profilu prywatnego. Oprócz niej są jeszcze inne takie jak np. wideo na żywo, like’owanie, komentowanie i dzielenie się postami innych użytkowników

Parametry usługi systemu (SLA)

Dostępność

• Kalendarz świadczenia – 24/7/365 – usługa musi być dostępna non-stop

• Dostępność w % = 99,999% w miesiącu – bardzo wysoka dostępność związana z krytycznością usługi

• Niedostępność = 26 sek w miesiącu – przeliczona z procentów na czas niedostępność usługi

Wydajność

• Wolumetria (pojemność) – rzeczywiste dane o wolumetrii Facebook dostępne są na stronach https://www.brandwatch.com/blog/47-facebook-statistics-2016/ https://expandedramblings.com/index.php/by-the-numbers-17-amazing-facebook-stats/. Zachęcam do zapoznania, niektóre liczby powalają.

• Czas odpowiedzi = 1 sekunda – takiego czasu odpowiedzi oczekują po kliknięciu na opublikuj posta

Obsługa serwisowa

• Przyjmowanie zgłoszeń – 24/7/365 – skoro usługa jest krytyczna i świadczona non-stop to przyjmowanie zgłoszeń również powinno być non-stop.

• Obsługa zgłoszeń – 24/7/365 – analogicznie jak przyjmowanie zgłoszeń przez https://www.facebook.com/help/

• Czas reakcji = 30 minut – wartość pożądana, której nie udało się potwierdzić na stronach FB

• Czas rozwiązania = 4 godziny– wartość pożądana, której nie udało się potwierdzić na stronach FB

• Okno serwisowe – od 00:00 do 06:00 GMT bez niedostępności. Architektura FB jest tak zaprojektowana i wdrożona, że wdrażanie poprawek lub nowych wersji nie wpływa na dostępność usługi dla użytkowników

Przedstawiłem przykładową usługę biznesową i systemy dla Facebook. Wierzę głęboko, że pozwoliło to przybliżyć tematykę tworzenia katalogu usług, dla osób które mają z nią pierwszy kontakt.

Zachęcam do dyskusji czy zdefiniowane przeze mnie usługa biznesowa i systemy oraz parametry je opisujące wiarygodnie opisują funkcjonalności Facebook, i które parametry mogą mieć wartości takie jak w rzeczywistości a które nie. Jeżeli masz jakieś pytania lub uwagi napisz je w komentarzy pod publikacją.

Artykuł Katalog usług dla Facebook pochodzi z serwisu Mariusz Siek.

W pierwszej części przedstawiłem jak zdefiniować usługę biznesową i jakie przypisać jej parametry w tym związane z SLA. W części drugiej zaprezentuję jak zdefiniować usługę systemu i jak określić dla niej parametry na poziom usług (SLA). Dana usługa systemu jest ściśle powiązana z konkretną usługą biznesową i dziedziczy po niej parametry usługi biznesowej.

Co jest potrzebne do zdefiniowania usługi systemu?

Definiując usługę systemu postępujemy analogicznie jak dla usługi biznesowej. Korzystamy z dokumentacji analitycznej przygotowanej przez zespół analizy oraz dokumentacji architektonicznej. Ponieważ co raz częściej zespoły wytwórcze pracują według metodyk zwinnych (Agile, Scrum) nie ma dokumentacji analitycznej a jedynym źródłem są historyjki. Dobrym sposobem jest spotkanie się z analitykiem i/lub architektem i pozyskanie niezbędnych informacji.

Definiowanie usługi systemu

Na podstawie uzyskanych informacji tworzymy usługę systemu. Pomagamy sobie definicją usługi systemu – jednoznacznie wyodrębniona w granicach systemu, funkcjonalność, która spełnia warunki: inicjuje ją użytkownik, daje określony rezultat i w ramach której wykonywane są operacje.

W oparciu o definicję tworzymy:

• Nazwę usługi, która pozwoli ją jednoznacznie zidentyfikować i będzie pozwalała na zrozumienie czego ona dotyczy

• Opis usługi, zawierający bardziej szczegółowe informacje o jej działaniu

• Ważność dla biznesu, określający jak ważna dla biznesu jest usługa systemu. Możemy wyróżnić trzy poziomy ważności: krytyczna, bardzo ważna i ważna. Ważność dla biznesu będzie miała wpływ na wyznaczenie poziomu usługi (SLA).

Katalog usług – Parametry usługi systemu (SLA)

Dla zdefiniowanej usługi systemu w katalogu usług, określamy jej poziom świadczenia następującymi parametrami SLA.

Dostępność

• Kalendarz świadczenia, określający w jakich dniach tygodnia i godzinach usługa jest świadczona dla użytkowników np. dni robocze 8:00-16:00

• Dostępność w %, określa jaki procent czasu usługa jest dostępna w ustalonym kalendarzu świadczenia za dany okres (najczęściej miesiąc) np. 99%

• Niedostępność, w inny sposób wyrażona dostępność w % pokazująca ile czasu (minut, godzin) usługa może być niedostępna w kalendarzu świadczenia za dany okres (najczęściej miesiąc) np. 101 minut w miesiącu (1 godz 41 minut), dla kalendarza świadczenia dni robocze 8:00-16:00 i dostępności w procentach 99%

Wydajność

• Wolumetria (pojemność), wyznacza maksymalną liczbę wywołań usługi systemu w jednostce czasu (minuta, godzina, dzień, miesiąc, rok), określając maksymalną pojemność dla usługi. Przykładowe parametry wolumetryczne:

  • Maksymalna liczba wywołań usługi w czasie

  • Średnia liczba wywołań usługi w czasie

• Czas odpowiedzi, określa czas oczekiwania użytkownika od momentu wywołania usługi do zwrócenia przez usługę odpowiedzi/wyniku np. 1 sekunda. Aby wyznaczyć czas odpowiedzi należy zdefiniować początek i koniec usługi systemu.

Obsługa serwisowa

• Przyjmowanie zgłoszeń, wskazuje przedział czasu, w którym przyjmowane są zgłoszenia (incydenty, service requesty, problemy) od użytkowników. Przyjmowanie zgłoszeń może być procesem automatycznym i różnić się od czasu obsługi zgłoszeń np. dni robocze od 6:00 do 18:00

• Obsługa zgłoszeń, wyznacza przedział czasu, w którym zespoły wsparcia obsługują zgłoszenia np. dnia robocze 8:00-16:00. Na zespoły wsparcia składają się I linia wsparcia (Service Desk), II linia wsparcia (zespoły utrzymania) i III linia wsparcia (zespoły wytwórcze lub dostawcy zewnętrzni).

• Czas reakcji, określa czas od przekazania zgłoszenia przez użytkownika (telefon, maila, narzędzie ITSM) do Service Desk do potwierdzenie przyjęcia zgłoszenia przez Service Desk np. 30 minut.

• Czas rozwiązania, wskazuje ile czasu zespoły wsparcia mają na rozwiązanie zgłoszenia (incydent, service request, problem) liczone od jego potwierdzenia przez Service Desk do dostarczenia skutecznego rozwiązania do użytkownika np. 4 godziny. Czas reakcji i rozwiązania można różnicować w zależności od ważności usługi dla biznesu (krytyczna, bardzo ważna i ważna)

• Okno serwisowe, podaje przedział czasu, w którym zespoły wsparcia mogą wdrażać rozwiązania zgłoszeń (incydenty, service requesty, problemy) oraz zmiany na produkcję np. codziennie 18:00-20:00. Okno serwisowe wiąże się przeważnie z niedostępnością usługi i powinno być poza kalendarzem jej świadczenia. Wyjątkiem są usługi świadczone w trybie 24/7/365.

Przedstawiłem najważniejsze parametry dla usługi systemu i na tym zakończę część drugą i ostatnią dotyczącą tworzenia katalogu usług. Oczywiście jeżeli są inne wymagania, można dla nich również zdefiniować parametry SLA. Mam nadzieję, że przedstawiona wiedza pomoże lepiej zrozumieć katalog usług i poziom świadczenia usług (SLA).

Zapisz

Zapisz

Zapisz

Zapisz

Zapisz

Zapisz

Artykuł Katalog Usług – co powinien zawierać? Część 2 pochodzi z serwisu Mariusz Siek.

W poprzedniej publikacji zachęcałem do utworzenia katalogu usług i wskazywałem, że jest to pierwszy i najważniejszy krok, we wdrażaniu najlepszych praktyk ITIL w organizacji. Teraz chciałbym pokazać, jakie informacje powinien zawierać katalog usług oraz na co zwrócić szczególną uwagę.

Od czego zacząć tworzenie katalogu usług?

Dokument opisujący katalog usług powinien zaczynać się od definicji. Konieczne jest zdefiniowanie najważniejszych pojęć, tak aby były rozumiane w ten sam sposób przez wszystkich zainteresowanych. Opracowanie definicji, pomoże lepiej zrozumieć podstawowe zagadnienia oraz w przyszłości zapobiegnie nieporozumieniom i różnym interpretacją kluczowych pojęć.

Definicje są bardzo ważnym elementem katalogu usług i pominięcie tego elementu będzie rodziło poważne skutki w przyszłości, dla rozumienia i rozliczania poziomu usług.

Przykładowe pojęcia, które powinny zostać zdefiniowane: usługa, poziom usług, SLA, dostępność, wydajność, pojemność, incydent, problem, awaria, błąd, czas reakcji, czas naprawy, zmiana, wniosek o zmianę.

Co jest potrzebne do zdefiniowania usługi biznesowej?

W celu zdefiniowania usługi biznesowej musimy poznać funkcjonowanie danego biznesu i jego procesów biznesowych. Najlepiej skorzystać z dokumentacji analitycznej przygotowanej przez zespół analizy, który zidentyfikował wymagania użytkownika i Klienta oraz usystematyzował tą wiedzę np. poprzez wykorzystanie notacji UML lub BPMN. Ponieważ co raz częściej zespoły wytwórcze pracują według metodyki Agile (Scrum) nie ma dokumentacji analitycznej a jedynym źródłem wiedzy o wymaganiach są historyjki spisane w narzędziu. Można również sięgnąć do dokumentacji architektonicznej, która powinna zawierać potrzebne informacje. Bardzo dobrym sposobem jest również spotkanie się z analitykiem i/lub architektem i pozyskanie niezbędnych informacji.

Katalog usług – Definiowanie usługi biznesowej

Na podstawie uzyskanych informacji tworzymy usługę biznesową. Jak to zrobić najlepiej? Pomagamy sobie definicją usługi biznesowej – jednoznacznie wyodrębniona funkcjonalność wspierająca proces biznesowy i dająca określone korzyści dla biznesu, użytkownika klienta.

Na tej podstawie grupujemy funkcjonalności i tworzymy:

• Nazwę usługi, która pozwoli ją jednoznacznie zidentyfikować i będzie pozwalała na zrozumienie czego dotyczy usługa

• Opis usługi, zawierający informacje bardziej szczegółowe jakie funkcjonalności wchodzą w skład usługi biznesowej

• Ważność dla biznesu, określający jak ważna dla biznesu jest usługa. Możemy wyróżnić trzy poziomy ważności: krytyczna, bardzo ważna i ważna

• Termin wdrożenia na produkcję, to data wskazująca kiedy usługa zostanie wdrożona na środowisko produkcyjne. Bardzo często data ta jest terminem wdrożenia danego wydania, które zawiera nową usługę

• Termin uruchomienia produkcyjnego, to data rozpoczęcia korzystania z usługi przez użytkowników. Może to być ta sama data co termin wdrożenia na produkcje jednak czasami zdarza się, że usługa uruchamiana jest po kilku dniach, tygodniach od wdrożenia na produkcję.

Parametry usługi biznesowej

Dla zdefiniowanej usługi biznesowej możemy określić następujące parametry:

• Role, wskazują podział odpowiedzialności w ramach usługi biznesowej. Najważniejsze role to: Właściciel usługi biznesowej, Użytkownik/Użytkownicy, Kierownik Projektu, Service Level Manager, Service Manager/Owner, Analityk, Architekt, Architekt infrastruktury, Architekt bezpieczeństwa

• Ciągłość działania, pokazuje czy usługa biznesowa jest krytyczna dla biznesu i powinna zostać włączona do Planu ciągłości działania (BCP). Wymagane jest wykonanie analizy ryzyka (Business Impact Analysis-BIA) dla usługi, która jest krytyczna dla biznesu. Wyznacza się dwa parametry, które są wymaganiami na poziom usług (SLA) :

  • Recovery Time Objective (RTO) – czas w jakim należy przywrócić działanie usługi biznesowej po wystąpieniu awarii np. 4 godziny

  • Recovery Point Obejctve (RPO) – akceptowalny poziom utraty danych dla usługi biznesowej wyrażony w czasie np. odzyskujemy dane sprzed 1 godziny, co oznacza utratę danych z ostatniej godziny przed awarią

• Bezpieczeństwo, podstawowe wymagania związane z bezpieczeństwem takie jak: metoda uwierzytelniania/dostępu, polityka haseł, odzyskiwanie hasła itp

Przedstawiłem najważniejsze parametry dla usługi biznesowej i na tym zakończę część pierwszą związaną z usługą biznesową. W części drugiej przekaże informacje jak zdefiniować usługę systemu i jakie parametry dla niej określić.

Zapisz

Zapisz

Zapisz

Zapisz

Zapisz

Zapisz

Artykuł Katalog Usług – co powinien zawierać? Część 1 pochodzi z serwisu Mariusz Siek.