IT Infrastructure Library Verze 3. Služby Prostředek k dodání hodnoty zákazníkovi, tím, že umožňují výstupy, které zákazník chce dosáhnout, bez potřeby,

Prezentace na téma: "IT Infrastructure Library Verze 3. Služby Prostředek k dodání hodnoty zákazníkovi, tím, že umožňují výstupy, které zákazník chce dosáhnout, bez potřeby,"— Transkript prezentace:

1 IT Infrastructure Library Verze 3

2 Služby Prostředek k dodání hodnoty zákazníkovi, tím, že umožňují výstupy, které zákazník chce dosáhnout, bez potřeby, aby vlastnil specifické náklady a rizika Vlastnosti ◦ Služby vytvářejí hodnotu ◦ Služby odebírají od zákazníka riziko vlastnictví ◦ Služby umožňují výstupy, které chce zákazník dosáhnout ◦ Služby snižují dopady omezení

3 Service management Služby se významně liší od zboží – nelze je mít na skladě Sada organizačních schopnostík poskytování hodnoty zákazníkům ve formě služeb

4 ITIL Seznam Good practices ◦ = vyzkoušené a revidované best practices „zdokumentovaný selský rozum“ –Brady Orand Vlastněno Office of Government Commerce ◦ Spadá pod ministerstvo financí UK ITIL v. 3 – iniciativa ITSMF

5 Historie ITIL Klasický ITIL (počátek 80. let) ◦ zaměřeno na vládní a veřejný sektor ◦ hlavní cíl – dosáhnout vyšší kvality IT služeb ◦ Rozrostlo se až na 31 knih Revidovaný ITIL (verze 2, 2000 -2002) ◦ OGC – Office of Government Commerce ◦ zaměřeno na všechny typy organizací, které poskytují služby IT ◦ celosvětový de-facto standard 2007 ITIL verze 3 ◦ Struktura ITIL přeskupena ◦ Základní knihy reflektují životní cyklus služby

6 Procesy „strukturovaná množina aktivit navržená za účelem dosažení specifické množiny cílů“ ◦ MaSsaCRe  Measurable  Specific output  Customer  Respond to a trigger

7 Funkce Organizační jednotky specializované na vykonávaní jistých typů páce a zodpovědné za určité výstupy

8 Role Skupina zodpovědností, které je třeba vykonat Nepopisuje jedince Specifické role ◦ Process owner  Zodpovídá za to, že proces dělá to co má ◦ Process manager  Zodpovídá za operativní řízení procesu ◦ Service owner  Zodpovídá zákazníkovi za iniciaci, transition a průběžnou údržbu a podporu služby ◦ Customer  Definuje a souhlasí se Service Level Targets  Platí za službu ◦ Uživatel – službu používá

9 RACI model Ukazuje kdo je Responsible, Accountable, Consulted a Informed za specifické aktivity v procesu ◦ Responsible označuje zdroj, který vykonává určitou činnost ◦ Accountable – osoba ve finále zodpovědná za úspěch nebo neúspěch činnosti (jen 1 osoba) ◦ Consulted - Dvousměrná komunikace ◦ Informed - Jednosměrná komunikace Zajišťuje, že je definovaná odpovědnost za každou činnost v procesu

10 Service management

11 SERVICE STRATEGY

12 Service strategy Primárně určeno pro IT ředitele Každý by měl mít povědomí, jak se tato rozhodnutí dělají Tato kniha poskytuje celkový přehled o službách

13 Smysl Service Strategy Popisuje strategická rozhodnutí, která je třeba udělat ohledně služeb a IT managementu IT organizace založeny jako technologické ◦ Pokud se mají stát poskytovateli služeb, musí rozumět byznysu IT se chce stát preferovaným prodejcem IT služeb pro byznys Hlavním výstupem je Service Level Package ◦ Byznys požadavky na služby, omezení, požadavky na procesy a ostatní požadavky na služby

14 Vytváření hodnot pomocí služeb Hodnota je vytvářena efektivním využitím Service Assets Service Asset = libovolná schopnost (capability) nebo zdroj (resource) service providera ◦ Schopnost  Věci, které víme a jak věci děláme, abychom dosáhli cíle (měkké)  Management  Organization  Procesess  Knowledge  People ◦ Zdroje  Investice a komponenty pomocí nichž věci děláme (tvrdé)  Financial Capital  Infrastructure  Application  Information  People

15 SERVICE DESIGN

16 Smysl Smyslem Service Designu je navrhnout nové či změněné služby ◦ Chceme zajistit konzitenci a integraci Zahrnuje ◦ Manažerské systémy a nástroje ◦ Architektonické standardy ◦ Technologie ◦ Metriky Service Managementu ◦ Procesy

17 Klíčové koncepty Vstupy jsou hlavně ze Service Strategy ◦ Service Portfolio Hlavním výstupem Service Design Package ◦ Zahrnuje nejen technologie, ale všechny ostatní aspekty ◦ Služba vyžaduje 4P  People, Products, Processes a Partners

18 Varianty Sourcingu In-Sourcing OutSourcing Co-sourcing Partnerství Business Process Outsourcing Application Service Provisioning Knowledge process outsourcing (KPO) ◦ Outsourcing expertízy v dané doméně

19 5 aspektů Service Designu Vlastní řešení (Service Solution) Nástroje Service Managementu Technologie a architektury, které řídí technologie Procesy k přechodu (transition) provozu a zlepšovní služeb Metriky Zdokumentováno v Service Design Package

20 Service Knowledge Management System SKMS Zahrnuje všechny informace o službě Vzniká v designu, ale poracuje se s ním ve všech fázích Zahrnuje ◦ Service Scripts ◦ Service Designs ◦ Problems ◦ Další informace

21 Service Portfolio Portfolio služeb Je součástí SKMS Obsahuje všechny služby, ve všech fázích jejich životního cyklu ◦ Service Pipeline  Zahrnuje služby, o kterých se uvažuje nebo jsou ve vývoji ◦ Service Catalog  Aktivní služby, které uživatelé mohou využívat ◦ Retired Services  Služby vyřazené z katalogu služrb

22 SERVICE TRANSITION

23 Smysl Na základě Service Design Package vytvoří a připraví službu pro provoz v živém prostředí Zodpovídá za změny a releasy služby a také za kontrolu změn Hlavní procesy ◦ Change Management ◦ Release and Deployment Management ◦ Sevice Asset and Configuration Management Hlavním výstupem je Service Transition Package ◦ Služba ◦ Metriky ◦ Service Levels ◦ Procedury ◦ Procesy ◦ Znalosti o službě Formalizuje přechod od navržené služby do provozu, včetně podpory v počátcích provozu (Early Life Support)

24 Service V-Model

25 Definitive Media Library Obsahuje schválené instalovatelné verze médií (např. softwaru) Vkládané verze musejí projít schvalovacím procesem Kontrolováno Change and Release Manegementem ◦ Evidováno v Configuration Management Systém

26 Definitive Spares Bezpečný sklad definitivních hardwarových náhradních dílů Veškerý hardware je nakonfigurován podle firemních standardů Udržuje se na stejné úrovni jako provozovaný hardware

27 SERVICE OPERATION

28 Smysl Zde jsou dodány hodnoty byznysu Koordinuje a vykonává aktivity a procesy, které jsou potřebné pro dodávku a řízení služeb v potřebné kvalitě Na vstupu je Service Transition Package Výstupem je hodnota pro byznys Reportuje Continual Service Improvement

29 Klíčové koncepty Velkou překážkou dodávky služeb je, že rozpočet zahrnuje pouze vývoj V Service Designu a Service Transition je třeba zajistit, že provoz služby bude zajištěn a financován

30 Je třeba vybalancoval Interní pohled x Externí pohle ◦ Zaměření na IT x Zaměření na pohled zákazníka Stabilita x Reaktivnost ◦ Malé zaměření na nové požadavky x utrácení příliš za změny Cena x Kvalita Reaktivní x Proaktivní

31 CONTINUAL SERVICE IMPROVEMENT

32 Smysl Zajišťuje, že služby jsou průběžně slaďovány s potřebami byznysu

33 Hodnota pro byznys Vyšší kvalita, ROI, VOI Improvements = výstupy, které v porovnání s předchozím stavem přináší zlepšení metrik Benefits = vyjádřeny ve finančních výstupech, vznikají realizací Improvements Return of Investment = rozdíl mezi dosaženými benefity a náklady vyjádřený v procentech ◦ Zlepšíme identifikací nižších nákladů Value of Investment = extra hodnota vytvořenáziskem benefitů, která zahrnujé nefinanční a dlouhodobé výstupy ◦ Zlepšíme identifikací další hodnoty při stejných nákladech

34 Založeno na Demingově cyklu

35 CSI Model

36 Měření Základní otázky ◦ Proč monitorujeme a měříme? ◦ Kdy toho necháme? ◦ Používá data někdo? ◦ Potřebujeme to ještě? Důvody měření ◦ To validate ◦ To direct ◦ To justify ◦ To intervene

37 Typy metrik Baseline = metrika změřená v určitém okamžiku za účelem srovnání s budoucími hodnotami Technologické Procesní ◦ Critical success factors ◦ Key performance indicators Služeb

38 PROCESY SERVICE STRATEGY

39 Sdílené aktivity Define the Market ◦ Zjišťuje, kdo jsou zákazníci služeb a jaká jsou jejich zákaznická aktiva  Zákaznická aktiva = to, co zákazníkovi umožňuje dosahovat jeho byznys výstupy Develop the Offerings ◦ Zdokumentování služeb v Service Portfolio tak, aby byly ve shodě se zákaznickými aktivy ◦ Identifikují se rovně potřebné capabilities a resources Develop Strategic Assets ◦ Vytvoření strategických resources a capabilities, které umožní vytvářet služby Prepare for Execution ◦ Zdokumentování strategie v SLP

40 Procesy Service Portfolio Management Demand Management Financial Management

41 Service Portfolio Management Smyslem je maximalizovat návratnost při současném řízení rizik Hlavním nástrojem je Service Portfolio ◦ Zodpovídá na otázky  Proč by to měl zákazník chtít  Proč by to měl chtít od nás  Jaké budou cenové modely  Jaké budeme potřebovat zdroje a schopnosti ◦ Service Pipeline ◦ Service Catalog

42 Aktivity Define – Bez omezení zdrojů – Business Case – potřeby byznysu Analyze – Zjistíme, co můžeme nabídnout při rozumném využití zdrojů Approve – musí být buď schváleno nebo zamítnuto – nic mezi tím Charter – nutná komunikace služby s dalšími složkami, zahrnutí do finančních plánů atd.

43 Demand management Službu nelze skladovat ◦ Musíme přesně odhadnout poptávku ◦ Poptávka je dána poptávkou po výsledných produktech firmy Tactical Demand Management ◦ Ovlivňování poptávky  Různé ceny Strategic Demand Management ◦ Patterns of Business Activity (PBA) ◦ User Profiles (UP)

44 Financial Management Zajišťuje řádné financování dodávek služeb Pomáhá vyjadřovat a komunikovat hodnotu IT převedením na finanční pojmy Klasifikace nákladů ◦ Přímé x Nepřímé ◦ Fixní x Variabilní ◦ Kapitálové x Operační

45 PROCESY SERVICE DESIGN

46 Procesy Service Designu Smyslem je holistický návrh procesu založený na požadavcích, standardech a omezeních ze Service Level Packege Procesy ◦ Service Level Management ◦ Service Catalog Management ◦ Availability Management ◦ Capacity Management ◦ Information Security Management ◦ Supplier Management ◦ IT Service Continuity Management

47 Service Level Management Přechod od byznysu k IT ◦ Snaží se porozumět potřebám byznysu, aby služby byly navrženy potřebným způsobem ◦ Snahou je dohodnou a zdokumentovat vhodné cíle Cílem je zařídit, aby dohodnuté cíle byly skutečně dodány

48 Klíčové koncepty SLM Service Level Agreement ◦ Neměly by nikoho držet jako rukojmí ◦ Dělení  Corporate Level  Customer Level  Multi-Level Service Level Requirements ◦ Zákaznický požadavek na IT službu ◦ Používá se k vyjednání služby Operational Level Agreements ◦ Dohoda mezi interními složkami na zajištění kvality služeb Hlavní rolí je Service Level Manager

49 Service Catalog Management Smyslem je poskytnout jediný konzistentní zdroj informací o všech dohodnutých službách Service Catalog ◦ Business Service Catalog ◦ Technical Service Catalog  IT pohled na služby pro byznys  Podpůrné služby (IT to IT) Zodpovědnou rolí je Service Catalog Manager

50 Availability Management Stará se o zajištění dostupnosti a její měření Koncepty ◦ Availability = dostupnost (v %) ◦ Reliability = spolehlivost  Jak dlouho služba funguje bez přerušení  Mean Time Between Service Interuptions  Čas dostupnosti / počet poruch  Mean Time Between Failures  Odečteme ještě ◦ Maintainability  Jak rychle se komponenta vrátí do provozu  Meant Time to Restore Services ◦ Serviceability  Schopnost dodavatele (3. strany) naplnit svůj kontrakt Životní cyklus incidentu: Detect -> Diagnose -> Repair - >Recover -> Restore

51 Avaliability Management Aktivity ◦ Design  Proaktivní - porozumění rizikům, vhodný návrh služby ◦ Transition  Revize služeb z pohledu dostupnosti ◦ Operation  Měření, analýza reportování Podporování Avaliability Management Information System (AMIS) ◦ Reporty, plány dostupnosti, designová kritéria, rozvrhy testování, …. Role ◦ Avaliability Manager  Úzce spolupracuje se SLM

52 Availability Management Vital Business Functions ◦ Ty které jsou kritické pro chod byznysu  Charakteristiky  High Avaliability  Minimaluzujeme nebo maskujeme  Fault Tolerance  Continuous Operation  Eliminujeme plánované výpadky  Continuous Avaliability  Maskujeme plánované a neplánované výpadky  Nástrojem pro jejich zjištění je SLM

53 Capacity Management Vyžaduje efektivní využití zdrojů Vybalancování nabídky a opptávky Smyslem je zajištění, že nákladově- zdůvodněná IT kapacita existuje pro všechny oblasti IT a je v souladu se současnými a budoucími dohodnutými potřebami byznysu

54 Klíčové koncepty Business Capacity Management ◦ Zaměřuje se na požadavky byznysu na kapacitu ◦ Jak ovlivní změny v poptávce, produkci požadavky na kapacitu služeb? Service Capacity Management ◦ Zajišťuje, že služba dokáže zajistit současnou požadovanou kapacitu a že bude schopná reagovat na změny v požadavané kapacitě Component Capacity Management ◦ Monitoruje kapacitu jednotlivých komponent Hlavní rolí je Capacity Manager Podporováno Capacity Management Information Systém ◦ Předpovědi, kapacitní plán, kapacitní reporty

55 Capacity Management

56 Information security management Zajišťuje ◦ Avaliability ◦ Confidentiality ◦ Integrity ◦ Authenticity

57 Klíčové koncept Information Security Framework ◦ Vytvoření  Politik  Kontrolních mechanismů  Bezpečnostní strategie  Bezpečnostní organizační struktura Politiky ◦ Typické: Užití a zneužití IT zdrojů, kontrola hesel, kontrola přístupů, antivirová p., klasifikace dokumentů, … Information Security Management System ◦ Standardy, manažerské informace, procedury, návody Role: Security Manager

58

59 Supplier Management Cílem je řídit dodavatele a služby, které dodávají tak, aby poskytovali kvalitu IT služeb byznysu a dodávali hodnotu za peníze

60 Klíčové koncepty Underpinning Contracts ◦ Smlouvy mezi IT a IT dodavateli ◦ Budou revidovány SLM Supplier and Contracts Database (SCD) ◦ Evidence všech dodavatelů a jejich smluv ◦ SM zajišťuje, že všechny údaje jsou správné

61 Aktivity

62 Supplier Categorization

63 IT Service Continuity Management Smyslem je na základě Business Continuity Plan vytvořit plán pro kontinuitu IT služeb Zajišťuje, že i v případě neštěstí budou nadále služby poskytovány v dohodnuté potřebné výši Stejně jako Avaliability Management se soustředí na Vital Business Functions

64 Aktivity

65 PROCESY SERVICE TRANSITION

66 Change Management Change Request můe vzniknout, kdekoliv v organizaci z různých důvodů Spuštěn Requestem for Change (RFC) Zajišťuje, že všechny změny jsou posouzeny standardizovaným, definovaným a zdokumentovaným procesem rychle a efektivně a zaznamenány v Configuration Management System (SMS)

67 7R Change Managementu Who RAISED the change What is the REASON for the change What is the RETURN required What are the RISKS involved What RESOURCES are required Who is RESPONSIBLE for the build, test and implementation What is the RELATIONSHIP with other ch.

68 Change Advisory Board (CAB) Posuzuje a schvaluje změny Liší se podle změny Schůze by měly být úzce zaměřené a neztrácet čas

69 Emergency Changes Změna, jejíž implementace je citlivá na čas Autorizace: Často nebývá čas na svolání CAB – svolá se ECAB (Emergency CAB) Testování: Mnohdy není čas předem, nutno otestovat posléze Dokumentace: po změně nezbytné Review: Všechny změny musí být revidovány

70 Change management Typy změn ◦ Standard Change  Předem schválené změny, které jsou běžné a mají popsané procedury a nízké riziko ◦ Normal Change  Projdou normálně celým procesem ◦ Emergency change Change models ◦ Pro běžně se vyskytující změny lze definovat konkrétnější postupy Remedition Planning ◦ Plán, pokud se změna nepovede Dokumentace ◦ Všechny změny musí být zdokumentovány, rozsah záleží na typu změny – ne všechna dokumentace bude při odeslání RFC

71 Aktivity

72 Service Asset and Configuration Management Poskytuje logický model IT infrastruktury, který popisuje všechny komponenty, ze kterých se skládá služba Vytváří Configuration Management System

73 Klíčové koncepty Configuration Model ◦ Používá se k popisu vazeb mezi jednotlivými složkami, ze kterých se skládá služba (součást CMS)  Umožní posoudit příčiny a důsledky incidentů a problémů  Umožní posoudit dopady změn

74 Klíčové koncepty Configuration Management System ◦ Obsahuje záznami o djednotlivých CI  Vztahy, přidružené incidenty, problémy, známé chyby, změnové záznamy Configuration Item (CI) ◦ Cokoliv co je pod kontrolou CM ◦ Individuální komponenty, ze kterých se skládá služba ◦ Každá má své charakteristiky  Název, verze, vztahy (s dalšími CI, incidenty, …) ◦ Každá má svůj status životního cyklu

75 Release and Deployment Management Hlavním cílem je zajistit holistický přístup k uvolnění releasu Další cíle ◦ Definování plánů releasu a deploymentu ◦ Zajištění integrity releasů v CMS ◦ Zajistit, že releasy lze sledovat, instalovat, testovat či odinstalovat

76 Klíčové koncepty Release Package ◦ Sada Release Units, které se distribuují společně Varianty ◦ Big Bang x Phased ◦ Push x Pul ◦ Automation x Manual

77 Aktivity

78 Role Release and Deplyment Manager ◦ Zajišťuje, že politiky vytvořené pro releasy se dodržují ◦ Zajišťuje update SKMS a CMS Release Packaging and Build Manager ◦ Zajišťuje, že specifický release je vytvořen a zabalen korektně a připravuje finální konfiguraci releasu pro nasazení v produkčním prostředí Deplyoment manager ◦ Zajišťuje, že release je nasezen v produkčním prostředí správně ◦ Zajišťuje i Early Life Support

79 Knowledge Management Zajišťuje, že organizačníí znalosti jsou skladovány a uchovávány pro použití v Service Operation Data, informace a znalosti jsou skladována v SKMS

80 D-I-K-W Model

81 Aktivity Knowledge Management Strategy ◦ Určení, jaké znalosti je třeba zachytit a kdy a kde Knowledge Transfer ◦ Předávání znalostí mezi částmi organizace ◦ U procesů, které vyžadují předávání zodpovědnosti je třeba definovat i místa, kde se předají znalosti Data and Information Management ◦ Zahrnuje vývoj a údržbu SKMS Using SKMS

82 PROCESY SERVICE OPERATION

83 Procesy Service Operation Zde je hodnota dodána zákazníkům Je třeba zajistit službám podporu, zajistit, že skutečně dodávají to co byznys potřebuje Procesy ◦ Incident Management ◦ Event Management ◦ Request Fulfillment ◦ Problem Management ◦ Access Management

84 Incident Management Cílem je obnovit dodávku služby co nejrychleji a minimalizovat Není cílem vyřešit problém, který výpadek způsobil

85 Klíčové koncepty Incident = neplánované přerušení služby nebo pokles ve kvalit+ sluby ◦ Může přijít z libobolného zdroje Incident Models ◦ 80 % incidentů není nových ◦ Lze definovat model rekace včetně zodpovědnosti, časového rozvrhu, pravidel eskalace Major Incidents ◦ Velké narušení byznysu ◦ Nesmí vzniknout ◦ Musíme je předvídat – plán Eskalace ◦ Servise desk, nebo vlastně kdokoliv, kdo řeší incident nemusí být schopný ho vyřešit  Funkční Eskalace – zapojíme někoho, kdo má specializované znalosti  Hierarchická eskalace – zapojmíme další manažery – více pozornosti incidentu

86 Aktivity Identifikace ◦ Monitorovací nástroje Logování ◦ Každý incident se musí zaznamenat ◦ Trendy ve službě ◦ SKMS – jak řešit příště Kategorizace ◦ Eskalace ◦ Service Request Prioritizace ◦ Naléhavost – časový rámec, do kdy musíme vyřešit ◦ Dopad – objektivní – dán službou, která je narušena Uzavření ◦ Kontrola, zda uživatelje spokojený s řešením

87 Role Incident Manager ◦ Má celkovou zodpovědnost za proces, zajišťuje, že se incidenty řeší správ+ 1st Level Support ◦ Zaměstnanci Sevice desku – zodpovědní za aktivity, které je potřeba udělat právě zde 2nd Level Support ◦ Mají větší technické dovednosti než service desk – řeší incidenty, které jim jsou přiděleny 3rd Level support ◦ Specialisté buď interní nebo u dodavatelů, kteeří řeší incidenty které vyžadují specializované znalosti

88 Problémy Incident M. Schopnost detekovat události co nejdříve Přesvědčit zaměstnance, že všechny incidenty musí být logovány Podpora použití prostředků self-help (na bázi webu) Dostupnost informací o známých chybách Integrace s CMS Integrace se SLM ◦ Dopady na prioritu

89 Event Management Event = Událost = jakýkoliv zjistitelný nebo rozpoznatelný výskyt, který má nějaký význam pro řízení IT infrastruktury, nebo dodávku IT služeb ◦ Má význam pro službu, ne vždy pro nás EM umožňuje detekovat události, vyhodnotit je a zajistit, aby byla provedena příslušná akce

90 Klíčové koncepty Typy událostí ◦ Regular ◦ Exceptional  Např. uživatel zadá špatné heslo ◦ Unusual but not Exceptional  Např. perace trvá déle než obvykle

91 Aktivity Event Detaction ◦ Je rozdíl mezi existující událostí a zjištěnou – technologie Event Filtering ◦ Ne všechny události vyžadují akci Significance ◦ Informational – není třeba reakce ◦ Warning – blížíme se k hraně, nebo třeba spadlo redundantní zařízení ◦ Exception – něco selhalo – často zahájí incident Event Correlation ◦ Pomocí korelačních pravidel zjistíme, zda jsou události spojené ◦ Pokud je událost významná roztřídíme ji na Incident, Problém, nebo Změnu Review Close Event

92 Aktivity Response Selection ◦ Event Logging  Všechny události by měly být nějakým způsobem zaznamenány ◦ Automatic Response  Některé události mají v Event Management System přiřazené automatické akce ◦ Alerts and Human Intervention  Výzva k vykonání nějaké činnosti ◦ Incident  Veškeré existující diagnostické záznamy jsou přiloženy ◦ Problem  Více incidentů může otevřít Problem Record ◦ Change

93 Role Service Desk ◦ Reagují na události Technical and Appliacations Management ◦ Řeší Incidenty a Problémy spojené s událostmi ◦ Trénují Service Desk v reakci na určité události IT Operations Management ◦ Má na starosti hlavně monitorování událostí tak, aby byla zajištěna funkčnost služeb

94 Request Fulfillment Ne všechny kontakty Service Desku jsou incidenty Service Request = změna ve službě požadovaná uživatelem, která má nízké riziko, nízký dopad, je běžná a často opakovaná ◦ Např. přidání software na počítač ◦ Většinou jsou založené na katalogu služeb  U elektronického katalogu může být dost podobné nákupu v e-shopu

95 Smysl Řídit řešení požadavků uživatelů tak, aby byly vyřešeny včas a v souladu s firemními politikami ◦ Poskytuje kanál pro uživatele, aby mohli požadovat standardní služby ◦ Poskytovat informace o dostupnosti služeb ◦ Zařízení dodání komponent běžných služeb Role ◦ Řeší se podobně jako incidenty – Service Desk v první linii

96 Problem Management Má na starosti odstraňování chyb z prostředí a snížování počtu incidentů, které uživatelé zažívají Vytváří návody pro rychlé odstranění incidentů (workaroundy, známé chyby, diagnostické skripty, …) – část SKMS Smyslem je, aby nedocházelo k Problémům a s nimi souvisejícím incidentům

97 Klíčové koncepty Problem = neznámá příčina jednoho či více incidentů Known Error = Problem po zjištění příčiny a zdokumentování ◦ Chyba v infrastruktuře, pro kterou je známé permanentní řešení nebo workaround Problem Models ◦ Umožňují automatizaci workflowu u známých typů problémů Known Error Database ◦ Obsahuje informaci o řešeních a workaroundech

98 Aktivity Problem Detection ◦ Většinou analýza trendů incidentů (ale někdy stačí 1) Problem Logging ◦ Všechny problémy a s nimi související informace se logují Problem Categorization ◦ Kvůli rozhodnutí, kdo je bude řešit (podle služby, technologie, aplikace, …) Problem Prioritization ◦ Podobně jako v Incident a Change Managementu – Urgency a Ipact Problem Investigation and Diagnosis ◦ Jakmile je příčina zjištěná vytvoří se Known Error Deploying Workarounds ◦ Zaznamenané workaroundy využívá Service Desk a Incident Management

99 Aktivity Raising a Known Error Record Problem Resoulution ◦ Otestuje se s uživatelem, aby se zjistilo, že chyba skutečně je odstraněna Problem Closure Major Problem Reviews ◦ Ke zlepšení procesu (jak úspěchy tak neúspěchy) Recording Errors from Development Monitoring and Tracking of Problems ◦ Problém se monitoruje v celém svém životním cyklu

100 Role Problem Manager ◦ Zajišťuje, že všechny aktivity v Problem Managementu se správně vykonávají ◦ Závisí na mnoha lidech, ay problémy řešitli ◦ Zodpovědnost  Komunikuje s řešiteli  Vlastní a chrání Known Error Database  Formálně uzavírá všechny Problem Records  Řídi vztahy s dodavateli ohledně řešení problémů  Organizuje Major Problem Reviews

101 Access Management Má zodpovědnost za bezpečnost v tom smyslu, že zajišťuje, aby přístup měl pouze ten, kdo k tomu má důvod Nerozhoduje o přístupu, jen vykonává politiky vytvořené v Service Designu

102 Klíčové koncepty Access (přístup) = úroveň nebo rozsah funkčnosti služby nebo dat, na která má uživatel nárok Service Groups = vytvoření skupin služeb na které má uživatel (nebo skupina u.) nárok a tím usnadňuje AM Identity = informace, na základě které se pozná jedinec a ověří se jeho status ve spolčnosti Directory Services =nástroj, který je užívaný k řízení přístupových práv Rights = nastavení, kterým uživateli přidělujeme přístup ke službě nebo skupině služeb

103 Aktivity Access Requests ◦ Požadavek může přijít z různých zdrojů (HR, Change, Process Fulfillment, … Verification ◦ Ověření identity uživatele a rozhodnutí zda uživatel má skutečně legimní nárok Providing Rights Monitoring Identity Status ◦ Status se z různých důvodů mění Logging and Tracking Access ◦ Přístupy se logují, kvůli auditním důvodům Removing or Restricting rights

104 Roles Service Desk ◦ Požadavky jdou stejně jako každý jiný Service Request  Splní nebo eskaluje Technical and Application Management ◦ Může plnit požadavky eskalované service deskem ◦ Vytváří zjednodušující mechanismy ◦ Testuje služby IT Operations Management ◦ Někdy se na ně delegují operativní aktivity AM (ověřování uživatelů, přidělování práv)

105 PROCESY CONTINUAL SERVICE IMPROVEMENT

106 Continual Service Improvement Nic se nepovede správně hned napoprvé Vytváří ze zlepšování permanentní činnost ne nárazovou akci Je součástí všech fází životního cyklu 7-step improvement process Role ◦ Service Manager ◦ CSI Manager

107 Aktivity