Każdy użytkownik chciałby aby gdy pojawią się problemy z działaniem usługi, aplikacji, rozwiązania IT, mógł liczyć na kompetentną i szybką pomoc. Czy takiemu oczekiwaniu trudno sprostać? Okazuje się, że nie jest to trywialne zadanie i nie każdy zespół wsparcia, serwisu, utrzymania poradzi sobie z nim w satysfakcjonujący sposób. Na czym polega ta trudność? Co jest takiego szczególnego i będącego wyzwaniem w świadczeniu serwisu, czym nie każdy serwis będzie mógł się pochwalić?

Błędy, awarie, incydenty, problemy

Nie ma i w najbliższym czasie nie będzie systemu IT, który działa bezbłędnie. Każde, nawet najlepiej przetestowane rozwiązanie IT, po wdrożeniu na produkcję, będzie wymagało wsparcia dla użytkowników. Wręcz tendencja jest odwrotna. Użytkownikom udostępniane są usługi IT, które z definicji nie są dokończone aby to użytkownik „w boju” sprawdził rozwiązanie i zgłosił błędy i niepoprawne działanie. Co raz więcej mamy systemów w wersji beta, które są oddawane do użytkowników aby je testowali, tzw testowanie przez używanie. Z tego powodu, informacją zwrotną od użytkowników są zgłaszane incydenty i problemy. Użytkownik nawet rozumie, że coś może się zepsuć, nie działać lub funkcjonować niepoprawnie. Jednocześnie jednak oczekuje, że zgłoszone problemy zostaną rozwiązane, tak aby mógł korzystać z danego systemu, aplikacji, rozwiązanie i wykonywać swoje codzienne obowiązki. Aby to się działo w sposób uporządkowany, dobrze jest mieć ustalone SLA dla obsługi zgłoszeń, nie wspominając o ustalonych praktykach i narzędziach, które pomogą obu stronom: użytkownikowi i IT.

SLA

Dla uruchomionych na produkcji rozwiązań informatycznych, powinniśmy mieć zdefiniowane w katalogu usług, usługi oraz poziom ich świadczenia czyli SLA. W zakresie SLA powinno być ustalone, w jaki sposób użytkownik zgłasza pojawiające się niesprawności oraz jak szybko zespół wsparcia naprawi te niesprawności. Dwa parametry SLA są tutaj kluczowe: czas reakcji i czas naprawy. Dla obu powinniśmy mieć zdefiniowane wartości dopuszczalne, czyli po jakim czasie zgłoszenie zostanie potwierdzone oraz po jakim naprawione. Oczywiście użytkownik chciałby aby te czasy były jak najkrótsze a IT aby były jak najdłuższe. Musimy znaleźć kompromis pomiędzy tymi dwoma podejściami. Skracanie tych czasów aby uzyskać przewagę konkurencyjną a później ich nie dotrzymywanie, nie będzie z korzyścią dla nikogo. Czy jednak dobrze zdefiniowane wartości SLA dla obsługi serwisowej są wystarczającym warunkiem aby uzyskać satysfakcję użytkownika? Okazuje się, że nie koniecznie. Dostawca może spełniać wymagania SLA zawarte w umowie a użytkownik nie będzie zadowolony, ze świadczonych usług serwisu.

Przyczyny

Jakie mogą być przyczyny takiego stanu rzeczy? 

• Po pierwsze, sam fakt że błędów jest bardzo dużo może powodować irytację użytkownika i rozwiązywanie ich zgodnie z SLA nic tu nie zmieni.
• Po drugie, wartości dopuszczalne czasu reakcji i naprawy mogą być za duże, co oznacza, że użytkownik za długo czeka na rozwiązanie zgłoszonego problemu.
• Po trzecie, niska jakość świadczonych przez zespół wsparcia usług serwisowych. Nie mam tu na myśli SLA, tylko sprawy związane z komunikacją, uprzejmością, zrozumieniem, pomiędzy użytkownikiem i serwisem.

Zapewne przyczyn można podać więcej. Ja wskazuję te według mnie najważniejsze. Co więc zrobić aby użytkownik lepiej postrzegał IT i osoby, które wspierają go w rozwiązywaniu błędów?

Rozwiązania

Na pewno pomoże większa koncentracja przy tworzeniu rozwiązania IT. Należy już u źródła spowodować, że będzie popełniane mniej błędów, które później wpływają na pracę użytkownika. Można spróbować zweryfikować parametry SLA i dostosować je do oczekiwań użytkownika oraz możliwości IT. Jednak te działania mogą nie przynieść zamierzonego wyniku. Co więc jeszcze możemy poprawić? Obsługa serwisowa wymaga kontaktu pomiędzy użytkownikiem a pracownikiem zespołu wsparcia. Kontakt ten może być telefoniczny, przez komunikator, chat, mail, narzędzie klasy ITSM. Niezależnie jaka to będzie forma kontaktu, po obu stronach są ludzie i powinni umieć się „dogadać”. Nie musi to być wcale takie proste. Osoby w zespole wsparcia to techniczni guru, którzy znają się bardzo dobrze na rozwiązaniu IT ale już z komunikacją mogą mieć problemy.

Przyjacielski serwis

Potraktujmy użytkownika jak naszego przyjaciela. Na co można liczyć w przypadku przyjaciela?

• Na pewno na empatię. Osoby z zespołu serwisu muszą podejść ze zrozumieniem i szczególną uwagą do problemów zgłaszanych przez użytkownika, którego nie można traktować jako zło konieczne i naszego wroga. Wręcz przeciwnie to biznes, którego użytkownik jest przedstawicielem, płaci nam za świadczone usługi wsparcia. Wejście w buty użytkownika, na pewno zmniejszy dystans pomiędzy użytkownikiem a IT.
• Niezależnie co się dzieje, pracownik zespołu serwisowego musi być uprzejmy dla użytkownika. Wiadome jest, że użytkownik może być zdenerwowany występującym błędem, ponieważ uniemożliwia mu on wykonanie określonej czynności. Nie można pod żądnym pozorem być nie miłym dla użytkownika, nawet jeżeli on jest niemiły w stosunku do serwisu. Należy uspokajać sytuację a nie ją jeszcze nakręcać. Trzy proste słowa proszę, przepraszam, dziękuję mogą zdziałać cuda, a nie wymagają żadnego szkolenia i dużego nakładu sił.
• Słuchać, słuchać, słuchać. Umiejętność aktywnego słuchania, pomoże w zrozumieniu potrzeb użytkownika i przyczyni się do budowania relacji pomiędzy użytkownikiem a IT.
• Otwartość i elastyczność na wyrażane potrzeby. Nie zamykajmy się w sztywnych ramach SLA i obowiązujących umów, tylko wykażmy się inicjatywą i zaangażowaniem.

Czy serwis może być przyjacielski. Może. Czy łatwo jest to osiągnąć. Niestety trudno ale nie znaczy, że jest to niemożliwe. Wymaga to dużego zaangażowania kierownictwa w ustalenie strategii i konsekwentne jej realizowanie. Jeżeli nawet nie mamy ludzi z takimi umiejętnościami to można się ich nauczyć. Potrzebne są szkolenia, warsztaty a może nawet specjalny program, który na kilka miesięcy, a może nawet lat rozpisze działania, które są wymagane aby użytkownik zaczął postrzegać wsparcie serwisowe jako swojego przyjaciela a nie geeka i nerda z IT, z którym kontakt to najzwyklejsza męczarnia i katorgi. Takiego podejścia i przyjacielskiej relacji życzyłbym sobie w każdej organizacji, która świadczy wsparcie w obsłudze serwisowej.

Artykuł Jak świadczyć przyjacielski serwis IT? pochodzi z serwisu Mariusz Siek.

W poprzednim artykule opisywałem proces zarządzania katalogiem usług. Bardzo mocno z nim powiązany jest proces zarządzania poziomem usług. Tak naprawdę kiedyś zarządzanie katalogiem usług było w ramach procesu zarządzania poziomem usług, ale zostało wydzielone do oddzielnego procesu. Nie dziwi więc fakt, że oba procesy są spokrewnione i zarządzanie poziomem usług bez katalogu usług nie miałoby co robić, bo poziom świadczenia określa się dla usług zdefiniowanych w katalogu usług. Ponieważ katalog usług jest bardzo ważnym produktem i narzędziem w zarządzaniu usługami IT, według mnie dobrze się stało, że został do jego zarządzania powołany dedykowany proces. Co zatem zostało w procesie zarządzania poziomem usług?

Cele

Podstawowym celem procesu zarządzania poziomem usług jest zagwarantowanie, że wszystkie aktualne i planowane usługi, są dostarczane na uzgodnionym, wymaganym poziomie. Osiąga się ten cel poprzez ciągły cykl negocjacji, uzgadniania, monitorowania, raportowania i przeglądania wymaganych (dopuszczalnych) wartości parametrów SLA.

Proces koncentruje się na:

• Definiowaniu, dokumentowaniu, uzgadnianiu, monitorowaniu, mierzeniu, raportowaniu i przeglądaniu poziomu, dostarczanych usług IT. Jeżeli jest potrzeba wprowadzane są środki naprawcze
• Zapewnieniu i poprawie relacji i komunikacji z biznesem i klientami
• Zapewnieniu, że zostaną określone, konkretne i mierzalne cele (wartości dopuszczalne) dla wszystkich usług IT
• Monitorowaniu i poprawie satysfakcji klienta z jakości świadczonych usług
• Zapewnieniu, że IT i Klienci mają jasne i jednoznaczne oczekiwania co do poziomu świadczonych usług
• Zagwarantowaniu, że nawet jeżeli wszystkie wymagane wartości poziomu usług zostaną spełnione, będą podejmowane proaktywane działania, mające na celu ciągłą poprawę kosztową usług

Zakres

Rysunek z książki ITIL Service Design

W zakresie procesu zarządzania poziomu usług jest zapewnienie regularnych kontaktów i komunikacji z klientami i menedżerami biznesowymi, w zakresie związanym z poziomem świadczonych usług. W tym względzie proces SLM powinien reprezentować dostawcę usług IT przed biznesem i biznes przed dostawcą usług IT. Zakres procesu SLM obejmuje również:

• Współpracę z procesem zarządzania relacjami biznesowymi (proces na etapie strategii), w zakresie osiągnięcia celów procesu SLM
• Negocjacje i uzgodnienie przyszłych (planowanych) wymagań na poziom usług i wartości dopuszczalnych (Service Level Requirements – SLR) dla wszystkich usług
• Negocjacje i uzgodnienie aktualnych wymagań na poziom usług i wartości dopuszczalnych (Service Level Agreement – SLA)
• Rozwijanie i zarządzanie odpowiednich umów OLA, które zagwarantują dotrzymanie celów w umowach SLA
• Przeglądanie i zarządzanie umowami z dostawcami zewnętrznymi (Underpinning contracts),które zagwarantują dotrzymanie celów w umowach SLA
• Proaktywne zapobieganie awarią usług, minimalizowanie ryzyka i poprawa jakości usług
• Raportowanie i zarządzanie rzeczywistym poziomem usług i przeglądanie wszystkich przekroczeń poziomu usług zdefiniowanego w SLA
• Okresowe przeglądy SLA, OLA i zakresu usług
• Identyfikowanie możliwości usprawnień i wprowadzanie ich do rejestru usprawnień
• Inicjowanie i koordynowanie planu poprawy usług (Service Improvement Plan – SIP)

Proces zarządzania poziomem usług nie obejmuje:

• Negocjacji i uzgodnienia wymagań funkcjonalnych, oprócz tych funkcjonalności, które mogą wpływać na poziom świadczonych usług
• Pilnowania aktywności, które są konieczne do zapewnienia wymaganego poziomu usług, ale są realizowane przez inne procesy takie jak zarządzanie dostępnością i zarządzanie pojemnością.
• Negocjacji i podpisywania umów z dostawcami zewnętrznymi, za które odpowiada proces zarządzania dostawcami. SLM dostarcza tylko dane wejściowe i wymagane konsultacje.

Korzyści

Efektywnie funkcjonujący proces zarządzania poziomem usług zapewnia:

• Interfejs dla biznesu, dla wszystkich zagadnień związanych z poziomem usług
• Uzgodnione SLA z określonymi celami (wartościami dopuszczalnym) oraz informację zarządczą, że te cele są spełnione
• Wyjaśnienie przyczyn źródłowych przekroczenia SLA i podejmowanie działań, które zagwarantują nie powtarzanie się tych przekroczeń
• Wiarygodny kanał komunikacji i zaufane relacje z klientem i biznesem

Rodzaje SLA

SLA możemy definiować na kilka różnych sposobów.

• SLA zorientowane na usługę, definiujemy jedno SLA dla usługi, chociaż może z niej korzystać wielu klientów. Problemem może być zróżnicowanie poziomu SLA, jeżeli usługa korzysta z tych samych elementów konfiguracji
• SLA zorientowane na klienta, definiujemy SLA dla jednego klienta, uwzględniając wszystkie usługi jakie dla niego świadczymy
• Wielopoziomowe SLA, którego przykładem może być trzypoziomowe SLA: poziom korporacji, poziom klienta i poziom usługi

Podsumowanie

To zaczyna się robić nudne :-). Zarządzanie poziomem usług to kolejny bardzo ważny proces w zarządzaniu usługami IT. Jest odpowiedzialny za ustalenie z biznesem, na jakim poziomie będą świadczone usługi IT. Musi przy tym uwzględniać wymagania biznesu i klienta, możliwości organizacji IT, posiadane zasoby sprzętowe i softwareowe oraz obowiązujące umowy z dostawcami zewnętrznymi. Żąglowanie tymi wszystkimi elementami, wymaga nie lada umiejętności od Menedżera poziomu usług. Potrzebne jest również doświadczenie w negocjowaniu, komunikacji, budowaniu relacji i balansowaniu pomiędzy biznesem a IT.

Pytanie: Jaki rodzaj SLA stosujesz najczęściej i dlaczego?

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

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.

Zaczynam nową serię artykułów, które mam nadzieję, będą bardzo atrakcyjne i pomocne dla osób, które je przeczytają. Często spotykam się z pytaniem jakie narzędzie wybrać do wsparcia obsługi procesów ITIL. Obecnie rynek dostarcza bardzo dużo rozwiązań, które pomogą nam zapanować nad sprawnym wdrożeniem, uruchomienie i działaniem procesów zarządzania usługami IT. Są to zarówno proste narzędzia pomagające w obsłudze zgłoszeń od użytkowników, po kombajny, które pomogą zaimplementować dowolny, wymyślony przez nas proces. Które z nich wybrać? Czym się kierować? Jakie kryteria przyjąć aby dopasować narzędzie do potrzeb i nie zapłacić fortuny? Czy lepiej wybrać narzędzie świadczone w modelu SaaS (Software as a Service) czyli w chmurze, czy może jednak uruchomić je na własnych zasobach sprzętowych? Dzisiaj opiszę jakie kryteria będę stosował do weryfikacji narzędzi. W kolejnych artykułach, które będę chciał publikować raz w miesiącu, opiszę jak dane narzędzie spełniło określone przeze mnie kryteria. Mam nadzieję, że w miarę upływu kolejnych miesięcy powstanie subiektywny ranking narzędzi klasy ITSM. Świadomie piszę, że subiektywny, bo oprócz kwestii merytorycznych, będę chciał pokazać moje wrażenia i odczucia z krótkiego testowania narzędzia.

Wymagania ogólne

Na początek kilka wymagań ogólnych, które powinno spełniać narzędzie.

• Wdrożenie dowolnego work flow dla procesów zarządzania usługami IT, który został zaprojektowany w organizacji
• Monitorowanie i raportowanie zdefiniowanych KPI dla procesów ITSM
• Intuicyjny interfejs dla użytkowników i pracowników I, II i III linii wsparcia
• Możliwość tworzenia prostych formatek do wsparcia procesów ITSM
• Tworzenie i nadawanie uprawnień dla ról występujących w procesach ITSM
• Integracja narzędzia z usługą katalogową (np. Active Directory, LDAP) aby nie trzeba było zakładać użytkownikom dodatkowych kont do narzędzia

Service Desk

Chyba nikt nie wyobraża sobie narzędzia ITSM bez funkcji Service Desku. Jest to podstawowa funkcjonalność pozwalająca na:

• Wyszukanie rozwiązania w bazie wiedzy, zanim jeszcze użytkownik wyśle zgłoszenie
• Samodzielne zgłaszanie przez użytkowników incydentów i problemów oraz service requestów
  • Prosty formularz zgłoszeniowy, dostępny przez stronę WWW lub dedykowaną aplikację
  • Email, na podstawie którego zostanie zarejestrowane automatycznie zgłoszenie
  • Telefon ze skonfigurowanym IVR, który na podstawie prostych wyborów, pozwoli na zarejestrowanie zgłoszenia
• Otrzymanie potwierdzenia przyjęcia zgłoszenia oraz monitorowanie statusu jego obsługi (czas reakcji, czas rozwiązania)
• Potwierdzanie rozwiązania zgłoszenia oraz zamykanie zgłoszeń po ustalonym czasie (np. 7 dni)
• Ocena, ankieta w jaki sposób zostało obsłużone zgłoszenie (pozytywnie, neutralnie, negatywnie)

Zarządzanie incydentami

Pierwszym najczęściej wspieranym przez narzędzie ITSM i wdrażanym w organizacjach procesem jest zarządzanie incydentami. Co powinno zapewniać narzędzie aby proces ten funkcjonował efektywnie?

• Nadawanie kategorii i priorytetów dla incydentów
• Określanie priorytetu na podstawie wpływu i ważności incydentu (SLA)
• Wysyłanie komunikatów, alertów o stopniu wykorzystania czasu rozwiązania
• Rejestrowanie na podstawie incydentów i problemów rozwiązań dla znanych błędach (baza znanych błędów)
• Łatwość komunikacji pomiędzy liniami wsparcia (komentarze, chat)

Zarządzanie problemami

Uzupełnieniem do zarządzaniami incydentami jest zarządzanie problemami, które powinno zawierać:

• Rejestrowanie problemów na podstawie jednego lub więcej incydentów
• Powiązanie problemu z incydentem lub incydentami
• Nadawanie kategorii takich samych jak dla incydentów
• Określanie SLA dla obsługi problemów
• Monitorowanie wykorzystania czasu obsługi problemu

Zarządzanie zmianą

Drugim najważniejszym i najczęściej implementowanym w narzędziu procesem jest zarządzanie zmianą. Jak narzędzie może pomóc w funkcjonowaniu procesu?

• Obsługiwać zmianę standardową, normalną i pilną
• Wspierać proces akceptacji zmiany przez Menedżera zmian oraz Radę ds. Zmian
• Umożliwiać wskazanie z bazy konfiguracji usługi, elementu konfiguracji, którego dotyczy zmiana
• Gromadzić informację o historii zmiany, w całym jej cyklu życia
• Powiązanie zmiany z incydentami i problemami

Zarządzanie zasobami i konfiguracją

Bez procesu zarządzania zasobami i konfiguracją nie mogą skutecznie i efektywnie funkcjonować pozostałe procesy ITSM, dlatego ważne jest aby móc:

• Zarejestrować wszystkie typy elementów konfiguracji składające się na usługi
• Zdefiniować wymaganą ilość atrybutów dla EK
• Określić relacje pomiędzy elementami konfiguracji i usługami (jeden do jeden, jeden do wielu, wiele do jednego i wiele do wielu)
• Zdefiniować kategorie i podkategorie dla każdego EK
• Automatycznie aktualizować informacje o zmianach wprowadzanych do EK

Zarządzanie poziomem usług (katalogiem usług)

Zarządzanie poziomem usług jest bardzo ważnym procesem, chociaż nie zawsze tak jest postrzegane. Jak powinno być wspierane przez narzędzia ITSM?

• Zarejestrować i opisać usługi wraz z atrybutami
• Wprowadzić SLA dla usług i odpowiednio powiązać z usługami
• Tworzyć słowniki dla parametrów SLA takich jak dostępność, wydajność, obsługa zgłoszeń itp
• Udostępniać usługi i SLA dla innych procesów ITSM (zarządzanie incydentami, problemami, zmianą, zasobami i konfiguracją)
• Monitorować i raportować rzeczywisty poziom usług (SLA)

To są podstawowe kryteria, jakimi będę się kierował sprawdzając i weryfikując narzędzia ITSM. Test pierwszego narzędzia jeszcze w tym miesiącu. Jeżeli macie propozycje innych kryteriów, bardzo chętnie dodam je do swojej listy i będę stosował podczas weryfikacji. Jeżeli macie również swoje typy narzędzi ITSM, które mam wziąć pod lupę, to dajcie znać a ja podejmę rękawicę i prześwietlę swoimi metodami.

Pytanie: Które jedno kryterium z powyższych jest dla Was najważniejsze i dlaczego?

Artykuł Jakie narzędzie ITSM wybrać? pochodzi z serwisu Mariusz Siek.

Proces zarządzania incydentami (Incident Management) jest najczęściej wdrażanym i wykorzystywanym procesem ITIL. Ma na to wpływ wiele czynniki ale najważniejszym jest fakt, że w każdej organizacji występują jakieś zdarzenia w działaniu usług IT, które wymagają pomocy ze strony zespołów wsparcia. Nie oznacza to, że jest to najłatwiejszy proces. Wręcz przeciwnie według mnie to jeden z bardziej złożonych i jednocześnie ważnych procesów. Jego wdrożenie wymaga dobrego przygotowania i przemyślenia jak proces powinien funkcjonować w naszej organizacji. Zobaczmy, na jakie aspekty należy zwrócić uwagę.

Narzędzie ITSM

Zaczynam od narzędzia aby obalić mit, że do obsługi incydentów wystarczy wdrożyć narzędzie klasy ITSM i już wszystko będzie działać jak w szwajcarskim zegarku. Sam ITIL podpowiada, że „głupiec z narzędziem, jest nadal głupcem”. Zobacz mój artykuł „Czy narzędzia pomogą Ci w utrzymaniu usług IT?”. Nie oczekujmy, że jak wdrożmy narzędzie to, rozwiąże ono wszystkie nasze problemy. Tak się nie stanie. Narzędzie może pomóc w zarządzaniu incydentami ale wcześniej trzeba je odpowiednio skonfigurować i dopasować do naszych realiów. Narzędzie upraszcza pewne czynności ale nie gwarantuje, że incydenty będą rozwiązywane w SLA. Za to odpowiadają pracownicy, którzy są tylko ludźmi.

Wybór narzędzi ITSM, które wspierają procesy ITIL, w tym zarządzanie incydentami jest wiele. Wybór trzeba poprzedzić analizą, która pomoże nam porównać ich możliwości z naszymi wymaganiami.

SLA

Wymagania na poziom usług, bardzo często zawierają dwa parametry: czas reakcji i czas rozwiązania. Oba one związane są z obsługą incydentów. Po pierwsze musimy je dobrze mierzyć, ustalając z biznesem ich czas rozpoczęcia i zakończenia. Częstym błędem jest pomijanie tej kwestii i liczenie czasów reakcji i rozwiązania według uznania IT, bez weryfikacji z biznesem. Rodzi to dużo sytuacji stresowych na styku IT-biznes i nie pomaga w budowaniu dobrych relacji. Opisałem to zagadnie w artykule „Jak mierzyć parametry SLA cz1”.

Musimy również pamiętać aby monitorować stopień wykorzystania czasu reakcji i rozwiązania. Tutaj pomaga nam narzędzie, które liczy upływający czas i wysyła komunikaty, zgodnie ze zdefiniowanymi regułami do osób obsługujących incydent jak i menedżerów zarządzających. Monitorowanie, pozwala podejmować działania, które zapobiegną przekroczeniu dopuszczalnych wartości czasów reakcji i naprawy. Komunikaty powinny być wysyłane, już po upłynięciu połowy czasu na obsługę.

Kategoryzacja i priorytetyzacja

Kolejnym bardzo ważnym elementem w procesie zarządzania incydentami, jest poprawne przypisanie kategorii do zgłoszonego incydentu. To jest odpowiedzialność pierwszej linii wsparcia czyli Service Desk (Help Desk). Dlaczego jest to takie ważne? Na podstawie kategorii, zgłoszenie przydzielane jest do właściwej grupy wsparcia. Jeżeli zrobimy to niepoprawnie, tracimy cenny czas rozwiązania, ponieważ incydent trafi do niewłaściwej osoby, która zwróci go ponownie do Service Desk. Może to być od 30 minut do kilku godzin, w zależności jak szybko zgłoszenie zostanie „odbite” do SD.

Równie istotne jest nadanie incydentowi właściwego priorytetu, z którym wiąże się długość czasu rozwiązania. Z jego wyborem związana jest pilność, czyli jak szybko powinien być rozwiązany oraz wpływ, czyli skutki jakie wywołuje incydent np. na ilu użytkowników oddziaływuje. Jeżeli wybierzemy za niski priorytet, może się okazać, że przy jego zmianie, upłynął już cały czas rozwiązania i mamy przekroczenie wartości dopuszczalnej czasu rozwiązania.

Eskalacja funkcjonalna i hierarchiczna

Obie eskalacje są bardzo ważne. Nie wyobrażam sobie funkcjonowania procesu zarządzania incydentami bez tych mechanizmów. Ponieważ o tym zagadnieniu napisałem oddzielny artykuł zapraszam do zapoznania się z nim „Eskalacja funkcjonalna a hierarchiczna – czy ich używasz?”.

Incydent manager

Incydent manager, to kluczowa rola dla efektywnie i sprawnie funkcjonującego procesu zarządzania incydentami. Jeżeli ktoś tego nie rozumie, niech nie oczekuje, że proces będzie działał sam. Osoba ta lub w dużych organizacjach wiele osób, pilnuje przede wszystkim aby incydenty były rozwiązywane zgodnie z SLA. Jest to szczególnie ważne, gdy dostawca zewnętrzny, musi płacić kary umowne, za nie dotrzymanie czasów reakcji lub czasu rozwiązania. To jednak nie jedyna jego rola. Incydent manager koordynuje obsługę incydentów, rozstrzyga kwestie sporne, motywuje grupy wsparcia do działania, analizuje kategorie i ilość incydentów. To bardzo ważna rola, bez której proces zarządzania incydentami, nie może działać poprawnie.

Obsługa incydentów, to ciągła gonitwa i walka o dotrzymanie SLA. Warto jednak od czasu do czasu się zatrzymać i sprawdzić czy nasz proces działa poprawnie i jest optymalnie dopasowany do naszej organizacji. To będzie wymagało wysiłku i dodatkowej pracy ale opłaci się nam ona. To zadanie również dla incydent managera, pamiętaj aby mieć go zawsze na pokładzie.

Pytanie: Co możesz poprawić w swoim procesie zarządzania incydentami?

Artykuł Czy dobrze zarządzasz incydentami? pochodzi z serwisu Mariusz Siek.

Jeżeli zarządzasz usługami IT, codziennie spotykasz się z problemami, które musisz ogarnąć i zapanować nad nimi. Ciesz się z tego powodu. Każda taka sytuacja pozwala Ci nauczyć się czegoś nowego. Każdy problem to szansa na poprawę poziomu świadczonych usług IT. Nie zniechęcaj się i nie martw, tylko zacznij działać, aby znaleźć najlepsze rozwiązanie. Może nie od razu będzie to ten idealny sposób ale jeżeli włożysz swoje serce i pot, to na pewno dotrzesz do właściwego rozwiązania. Jakie problemy mogą Cię spotykać i jak im sprostać, przeczytasz w poniższym wpisie.

Co miesiąc nie dotrzymuję SLA

To chyba jeden z najczęściej występujących przypadków. Jeżeli mamy uzgodnione SLA z biznesem i rozliczamy się z niego co miesiąc, wykazujemy w raporcie, jakie wartości osiągnęły parametry SLA. Niektóre z nich, niestety nie spełniają postawionych wymagań. W takim przypadku rzetelnie pokazujemy biznesowi, że nie daliśmy rady i bijemy się w pierś. Na tym jednak nasze działanie się nie kończy. Na każde przekroczenie parametru SLA, w ustalonym okresie rozliczeniowym, zakładamy problem w rejestrze problemów, w celu znalezienia jego przyczyny źródłowej. Szukamy rozwiązania do skutku, a o postępach naszych działań, na bieżąco informujemy biznes.

W moich zespołach jest duża rotacja pracowników

Jest to co raz częściej występujące zjawisko na rynku pracy, że pracownicy szukają ciekawszych i lepiej płatnych zajęć. Nie jest to tylko specyfika IT ale tendencja, która według mnie, co raz bardziej będzie się nasilać. Musimy z nią żyć i radzić sobie.

• Po pierwsze musimy budować kompetencje zespołów, w taki sposób, aby nie były w jednych rękach i głowie. Nie możemy uzależniać się od wiedzy i kompetencji jednej osoby, która może zachorować lub zmienić pracodawcę. Przynajmniej dwie osoby w zespole powinny mieć zbliżone kompetencje. Jedna może mieć trochę większe ale ta druga powinna w 1-2 tygodnie być w stanie zastąpić osobę wiodącą.
• Po drugie musi powstawać dokumentacja techniczna, która zawiera wiedzę i informacje, które są niezbędne do zarządzania aplikacją, systemem, serwerem, bazą danych itp. po odejściu pracownika. Wiem, że jest to wyzwanie, bo nigdy nie ma na to czasu oraz administratorzy i technolodzy nie cierpią pisać dokumentacji ale innej drogi nie ma.

Mam za mały budżet aby spełnić oczekiwania biznesu

Wiadomo, że pieniędzy jest zawsze za mało i każdy chciałby mieć więcej. Jak jednak lepiej nimi zarządzać?

Jeżeli chcesz lepiej zrozumieć swoje finanse w IT, musisz policzyć koszty świadczenia poszczególnych usług IT. Tylko posiadając rzetelną wiedzę, jakie są elementy składowe kosztów, możesz zacząć rozmawiać z biznesem, co i za ile możesz dostarczyć. Ta wiedza jest niezbędna przy uzgadnianiu SLA, przy jego raportowaniu i rozliczaniu. Wyposażony w niezbędną wiedzę o kosztach i ich związku z poziomem świadczonych usług, możesz usiąść do rozmów z biznesem, aby rzeczowo pokazać, co w aktualnym budżecie, przy obowiązującym SLA, jest możliwe do uzyskania. Język faktów i rzeczowych danych powinien uświadomić biznesowi możliwości IT.

Biznes cały czas narzeka na działanie IT

Narzekanie to chyba cecha narodowa Polaków. Po pierwsze należy wysłuchać tych żali i uzyskać od biznesu jak najwięcej rzeczowych i wiarygodnych informacji, co im najbardziej doskwiera i przeszkadza. Jeżeli te narzekania są uzasadnione, trzeba zaplanować działania, które pomogą w rozwiązaniu zagadnień, podnoszonych przez użytkowników. Aby te żale były przekazywane w cywilizowany sposób należy spotykać się regularnie z biznesem i słuchać co mają do powiedzenia. W ten sposób budujemy partnerską relację i tworzymy swój dobry wizerunek.

Bardzo dużo zmian do systemów IT, wprowadzanych w krótkim czasie

Otoczenie biznesowe oczekuje, nowych funkcjonalności i aplikacji, aby spełnić wymagania rynku i pokonać konkurencję. To skutkuje wdrażaniem bardzo dużej ilości zmian do systemów produkcyjnych. Nie jesteśmy w stanie zatrzymać tej tendencji. Wręcz przeciwnie będzie się ona nasilała. Wprowadzane nowe zmiany wymagają nowych kompetencji i wiedzy aby je sprawnie utrzymywać. Jak się przygotować na taką sytuację?

• Uczestniczyć w planowaniu zmian, które są przygotowywane przez zespoły deweloperskie i mieć na to planowanie wpływ.
• Pozyskać od zespołów wytwórczych wymaganą do utrzymania wiedzę i kompetencje, przed wdrożeniem zmian na produkcję.
• Oczekiwać od fazy wytwórczej przygotowania bazy znanych błędów, które zostaną wdrożone na środowisko produkcyjne, która pozwoli szybciej je identyfikować i rozwiązywać.

Problemy były, są i będą, a te podane przeze mnie, są tylko przykładowe. Sposób radzenia sobie z nimi, jest oznaką tego jak dobrymi jesteśmy managerami. Te trudności i niedogodności spowodują, że będziemy działać bardziej kreatywnie i innowacyjnie – nie lubię tego słowa :-). Co nas nie zabije to nas wzmocni i wyjdziemy z większą siłą i przekonaniem, że jesteśmy w stanie sprostać każdemu problemowi. Musimy tylko opanować emocje i rzeczowo zjeść tego słonia po kawałeczku, aby nie stanął nam w gardle :-).

Pytanie: Z jakim problemem w zarządzaniu usługami IT ostatnio się zmierzałeś i z jakim efektem?

Artykuł Problemy w ITSM i jak je rozwiązać? pochodzi z serwisu Mariusz Siek.

Zarządzając usługami IT, naszym głównym celem powinno być zapewnienie jak najwyższej dostępności usług IT. Przerwa w działaniu usługi IT, wpływa bezpośrednio na funkcjonowanie biznesu i użytkowników, którzy z tych usług korzystają. Mimo jednak starań i wysiłków IT, zdarzają się awarie usług IT, których skutkiem jest, niedostępność ich do realizacji procesów biznesowych. Z każdej takiej awarii, nazwanej również major incident, należy wyciągnąć lekcję, ustalając przyczynę źródłową oraz planując działania, które zapobiegną, takiemu zdarzeniu w przyszłości. W ramach analizy awarii powinny być również wyznaczone jej koszty. Co powinno wchodzić w te koszty i jak je policzyć?

Koszty IT

Jednym z kosztów awarii, są koszty związane z przywróceniem usługi IT do prawidłowego działania. W skład tych kosztów wchodzi pracochłonność ludzi z IT, którzy usuwają awarię. Należy policzyć ile czasu spędziła, każda z osób zaangażowanych w naprawę awarii i pomnożyć przez stawkę za roboczogodzinę. Nie należy pomijać nikogo, kto uczestniczy w obsłudze awarii, w szczególności Service Desk, który jest SPOC dla awarii oraz osób koordynujących pracę specjalistów i technologów, takich jak major incident manager czy kierownicy zespołu utrzymania i/lub infrastruktury.

Jeżeli przyczyną awarii jest zepsuta infrastruktura sprzętowa (serwer, macierz, dysk, przełącznik LAN itp), to do kosztów jej usunięcia należy również doliczyć, wartość wymienionego sprzętu lub jego części.

Koszty IT jest policzyć najłatwiej, ponieważ są to koszty, które łatwo zidentyfikować i określić ich związek z awarią. Trzeba tylko pamiętać, aby koszty związane z pracochłonnością zarejestrować zaraz po awarii, tego samego dnia lub najpóźniej następnego, kiedy jeszcze każdy pamięta ile czasu poświęcił na jej usunięcie. Jeżeli nie zrobimy tego na bieżąco, to później będzie już trudno zebrać wiarygodne dane.

Koszty biznesu

Koszty IT, nie dość że się łatwo liczy, to jeszcze są najmniejszą składową kosztów awarii. Jak policzyć koszty awarii związane z wpływem niedostępności usługi IT, na działanie i funkcjonowanie biznesu? W tym przypadku musimy stworzyć model kosztowy dla każdej usługi biznesowej. W modelu musimy uwzględnić:

• Jaki wpływ ma niedostępność usługi IT na prowadzenie biznesu? Czy całkowicie go zatrzymuje czy tylko utrudnia i powoduje spadek efektywności działania użytkowników?
• W jakich okresach czasu wpływ jest mniejszy lub większy? Czy biznes jest linearny i wystąpienie awarii o dowolnej godzinie świadczenia usługi mam taki sam wpływ? Czy biznes charakteryzuje się pewną okresowością i np krytyczne dla niego są określone godziny w ciągu dnia lub dni w tygodniu lub miesiącu?
• Czy biznes ma jakieś obejście, na wypadek wystąpienia awarii, z którego może skorzystać? Chodzi o wykorzystanie innych narzędzi lub tak zwane działanie „na piechotę”. Biznes może funkcjonować, chociaż nie tak wydajnie jak ze wsparciem usług IT.

Pytań i kryteriów może być oczywiście więcej, jeżeli tego wymaga specyfika usług IT, świadczonych dla biznesu. Wynikiem prac nad modelem powinno być przygotowanie, dla każdej usługi IT, kalendarza, który będzie zawierał koszt w pln niedostępności usługi w danej godzinie np 9-10, 10-11, 11-12 itd, w okresie jej świadczenia zgodnie z SLA. Koszt awarii dla biznesu będzie liczony jako czas trwania awarii pomnożony przez koszt niedostępności usługi w danej godzinie.

Koszty inne

Niestety koszty IT i biznesu do nie wszystkie wymierne koszty awarii. Są jeszcze koszty, które trudno policzyć, a mogą być bardzo duże i ich wpływ może być bardzo istotny. Mam tu na myśli koszty związane z wizerunkiem firmy, jeżeli usługi, które świadczy IT są udostępniane w internecie, dla szerokiej grupy klientów. Duże wpadki (awarie) mogą skutkować rezygnacją klientów z korzystania z usług lub w najlepszym razie utratą lub nadszarpnięciem zaufania. Nie można tego łatwo zmierzyć ale na pewno jest to element, o którym musimy pamiętać, w codziennej pracy IT.

Często mówi się o tzw. utraconych korzyściach, które również, nie jest łatwo oszacować, jednak należy to zrobić aby mieć pełny obraz wpływu awarii usług IT, na działanie biznesu i organizacji.

Policzenie kosztów awarii usług IT, wymaga zaangażowania wielu osób i wykonania niełatwej pracy. Jest to jednak wysiłek, który na pewno się opłaci, nie tylko IT ale całej firmie. Wiedząc jakie są koszty awarii, będzie można podejmować decyzje, czy potrzebne jest dofinansowanie określonej usługi IT oraz jak ustawiać priorytety w utrzymaniu oraz przywracaniu do działania poszczególnych usług. Ta świadomość będzie pomagać IT, jeszcze lepiej dostarczać usługi dla biznesu, którego działanie w co raz większym stopniu, uzależnione jest od prawidłowego działania usług IT.

Pytanie: Jakie koszty awarii uwzględniasz w swojej firmie?

Artykuł Koszty awarii usług IT 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.