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.

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.

Zacznij od Katalogu Usług

Co to jest katalog usług? Jest to dokument opisujący jakie usługi świadczone są Biznesowi przez IT.

Nie dla każdego Menedżera Usług jest jasne, że katalog usług IT jest najważniejszym elementem ITIL, od którego powinno się zacząć przygodę z zarządzaniem usługami IT w każdej organizacji, która odpowiada za dowolny system informatyczny.

ITIL to wiele procesów, produktów, ról i cały ogrom wiedzy oraz informacji, które opisują najlepsze praktyki w zarządzaniu usługami IT. Powstaje jednak zasadnicze pytania: Od czego zacząć? Ilu fachowców w tej dziedzinie tyle zdań i sposobów na rozpoczęcie przygody z ITIL. Według mnie należy zacząć od opracowania katalogu usług, ponieważ:

• Musimy wiedzieć z czym mamy do czynienia i jakie „usługi” IT świadczy dla Biznesu.

• Znając usługi będziemy mogli dla nich zdefiniować parametry SLA

• Do zdefiniowanych usług będzie można zgłaszać incydenty i problemy

• Usługi będzie można powiązać z elementami konfiguracji zawartymi w bazie konfiguracji (CMDB)

• Do istniejących usług można będzie wprowadzać zmiany, wynikające z naprawianych błędów lub rozwoju usług

• Możemy zarządzać poziomem usług i rozliczać ich poziom świadczenia

• Monitorujemy wykorzystanie zasobów sprzętowych przez poszczególne usług i na tej podstawie planujemy ich rozbudowę

Dlaczego dwa katalogi?

Katalog usług powinien składać się z dwóch części: biznesowej i technicznej. Obie części mogą być opisane w jednym dokumencie lub każdy w niezależnym dokumencie, ponieważ ich odbiorcy będą inni.

Ze względów praktycznych lepiej każdy z katalogów: biznesowy i techniczny opracować w oddzielnym dokumencie. Jeżeli ktoś będzie zainteresowany obydwoma dokumentami to nic nie stoi na przeszkodzie aby się z każdym zapoznał.

Zaczynamy pisanie katalogu usług od katalogu usług biznesowych. Dlaczego? Musimy wiedzieć jakie procesy biznesowe wspierają usługi IT. W ramach tworzenia biznesowego katalogu usług poznamy i zrozumiemy jak działa biznes, który korzysta z usług IT i bardziej świadomie będziemy mogli podejść do dekompozycji usług biznesowych na usługi techniczne. Będziemy mieli też udokumentowany cały zakres usług jakie mają być wspierane przez zespół IT i na tej podstawie będziemy mogli planować i budować kompetencje zespołu IT.

Dekompozycja usług

Katalog usług to nie tylko prosta lista usług biznesowych i technicznych ale powiązania i relacje pomiędzy tymi usługami oraz elementami konfiguracji (infrastruktury sprzętowo-programowej).

W celu identyfikacji i zdefiniowania powiązań pomiędzy usługami biznesowymi a usługami technicznymi wymagane jest wykonanie dekompozycji usług biznesowych na usługi techniczne a następnie na elementy infrastruktury sprzętowo-programowej.

Dekompozycja usług dostarczy niezbędnych informacji od czego zależy działanie poszczególnych usług i w jaki sposób można zabezpieczyć się przed niedostępnością usługi biznesowej dla użytkowników końcowych.

Katalog usług a SLA

SLA może być częścią katalogu usług ale lepiej utworzyć oddzielny dokument, ponieważ będą tworzone jeszcze dokumentu OLA i UC.

Tworząc katalog usług warto zastanowić się, czy w nim będą zawarte wymagania SLA czy utworzymy oddzielny dokument, który będzie opisywał wymagania SLA dla naszego systemu, usługi, aplikacji.

Zgodnie z najlepszymi praktykami umowa SLA powinna być oddzielnym dokumentem. Często jednak ze względów praktycznych warto umieścić parametry SLA w katalogu usług aby w jednym dokumencie była zarówno informacje o usługach biznesowych i technicznych jak i jakie wymagania poziomu usług są stawiane tym usługom.

Ile kosztują usługi IT?

Czy biznes wie i ma świadomość ile płaci za poszczególne usługi IT i co w ramach tych usług otrzymuje? Czy IT wie, jak nie działanie usług IT wpływa na biznes i jakie rodzi konsekwencje finansowe? Odpowiedzi na te pytania może dać tylko opracowanie:

• wyceny usług IT świadczonych dla biznesu

• modelu kosztów awarii usług IT

Obie wyceny muszą być zrobiona rzetelnie jednak ze względu na złożoność systemów informatycznych i fakt, że różne usługi biznesowe korzystają z tych samych usług technicznych (np. sieć LAN, zasoby dyskowe, systemy backupu) wycena jest pewnym modelem kosztów a nie ich rzeczywistym odzwierciedleniem.

Artykuł Katalog usług – Dlaczego jeszcze go nie masz? pochodzi z serwisu Mariusz Siek.