Oficiální zadání práce

Oficiální zadání práce

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Implementace standardu pro řízení IT služeb v bankovnictví Ondřej Ettl

Vedoucí práce: Ing. Božena Mannová, Ph.D

Studijní program: Softwarové technologie a management, kombinovaná forma studia Obor: Softwarové inženýrství 8. května 2010

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu paragrafu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon)

V Praze dne 8.5.2010

……………………………………………………………………………

Obsah 1 2

Úvod ...........................................................................................................................................1 Základní procesy ITIL v bankovnictví ............................................................................................2 2.1 Obecná problematika ..........................................................................................................2 2.2 Service Strategy ...................................................................................................................4 2.3 Service Design .....................................................................................................................5 2.4 Service Transition ................................................................................................................6 2.4.1 Change Management ...................................................................................................6 2.4.2 Release And Deployment Management ..................................................................... 10 2.5 Service Operation .............................................................................................................. 12 2.5.1 Incident Management................................................................................................ 13 2.5.2 Event Management.................................................................................................... 16

2.5.3 Request Fulfilment ..................................................................................................... 16 2.5.4 Problem Management ............................................................................................... 16 2.5.5 Access Management .................................................................................................. 17 2.6 Continual Service Improvement ......................................................................................... 17 3 Implementace procesu Change Management............................................................................ 19 3.1 Modelová aplikace............................................................................................................. 19 3.2 Model migrace nové verze aplikace ................................................................................... 20 3.2.1 Business testy ............................................................................................................ 20 3.2.2 Performance testy ..................................................................................................... 20 3.2.3 Souběhové testy ........................................................................................................ 21 3.2.4 Integrační testy .......................................................................................................... 21 3.2.5 Analýza dopadů na pravidelné zpracování.................................................................. 21 3.2.6 Příprava migračních balíčků ....................................................................................... 21 3.2.7 Plán migrace .............................................................................................................. 22 3.2.8 Pilotní provoz............................................................................................................. 22 3.2.9 Informace BU a SLM................................................................................................... 22 3.2.10 3.2.11 3.2.12 3.2.13

RFC nástroj ................................................................................................................ 22 IT CAB Committee ...................................................................................................... 26 Koordinace migrace ................................................................................................... 26 Podpora po migraci .................................................................................................... 26

3.2.14 Monitoring................................................................................................................. 26 3.2.15 Vyhodnocení migrace ................................................................................................ 27 3.3 Analýza modelu ................................................................................................................. 27 4 Ověření a vyhodnocení implementace ...................................................................................... 29 4.1 Metriky ITIL ....................................................................................................................... 29 4.2 Počet oprav na změnu ....................................................................................................... 30 4.3 Počet incidentů na změnu ................................................................................................. 32 5 Závěr......................................................................................................................................... 33 6 Literatura .................................................................................................................................. 34

Seznam obrázků OBR. 1 SCHÉMA BUSINESS PROCESS .......................................................................................................................... 2 OBR. 2 ITIL LIBRARY .............................................................................................................................................. 4 OBR. 3 PEOPLE, PROCESSES, PRODUCTS, PARTNERS = 4P ............................................................................................... 5 OBR. 4 ŽIVOTNÍ CYKLUS RFC .................................................................................................................................... 8 OBR. 5 MODEL INCIDENTU .................................................................................................................................... 15 OBR. 6 PLAN-DO-CHECK-ACT CYKLUS ...................................................................................................................... 18 OBR. 7 CSI CYKLUS .............................................................................................................................................. 18 OBR. 8 RFC ZÁKLADNÍ PRŮBĚH ............................................................................................................................... 23

Seznam tabulek TAB. 1 KOMPONENTY ITIL CORE ............................................................................................................................... 4 TAB. 2 URČENÍ PRIORITY INCIDENTU ......................................................................................................................... 13 TAB. 3 PRIORITA INCIDENTU ................................................................................................................................... 14 TAB. 4 METRIKY INCIDENT MANAGEMENTU ............................................................................................................... 14 TAB. 5 POST IMPLEMENTATION REVIEW.................................................................................................................... 24 TAB. 6 VÝSLEDKY IMPLEMENTACE RFC ..................................................................................................................... 24 TAB. 7 TYPY AKTIVIT GENERUJÍCÍCH RFC ................................................................................................................... 25 TAB. 8 TYPY RFC PODLE VÝZNAMNOSTI .................................................................................................................... 25 TAB. 9 ANALÝZA MODELU CHANGE MANAGEMENT ...................................................................................................... 28 TAB. 10 POČTY OPRAV NA ZMĚNU ........................................................................................................................... 30 TAB. 11 POČTY INCIDENTŮ NA ZMĚNU ...................................................................................................................... 32

Seznam použitých zkratek BU CAB CAB/EC CAPEX CI COBIT CSI ELS EM ERFC HA CHA CHC ISO IT ITIL ITSM KEDB KPI MTBF MTBSI MTRS PIR QA RDM RFC SD SIT SLA SLM SPI SPOF TCO TCU UAT

Business Change Advisory Board Change Advisory Board/Emergency Committee Capital Expenditure Configuration Item Control Objectives for Information and Related Technology Continual Service Improvement Early Life Support Event Management Emergency Request for Change High Availability Change Authority Change Coordinator International Organization for Standardization Information Technology IT Infrastructure Library IT Service Management Known Error Database Key Performance Indicator Mean Time Between Failures Mean Time Between Service Incidents Mean Time to Restore Service Post-Implementation Review Quality Assurance Release and Deployment Management Request for Change Service Desk System Integration Test Service Level Agreement Service Level Management Service Provider Interface Single Point of Failure Total Cost of Ownership Total Cost of Utilization User Acceptance Test

Úvod

1 Úvod ITIL je standard pro řízení IT služeb, který se od roku 2007, kdy byl standardizován jako ITILv3, velmi dobře uplatňuje v IT praxi. Pomocí něj lze efektivně řídit IT služby ve velkých organizacích. Cílem mé práce je ukázat, že ITILv3 je dostatečně obecný a robustní standard, který je možno úspěšně implementovat také v bankovních institucích a pomocí nějž je možné stabilizovat rozsáhlé informační systémy. Vzhledem k tomu, že se podílím od roku 2008 na implementaci procesů definovaných standardem ITIL v konkrétním bankovním domě, budu ve své práci vycházet z praktických zkušeností a pracovat nad reálnými daty. Ve druhé kapitole popíši základní procesy definované standardem ITIL: Service Strategy, Service Design, Service Transition, Service Operation a Continual Service Improvement a jejich potenciální vazby na procesy v bankovnictví. Podrobněji se budu věnovat procesům Service Transition a Service Operation, pomocí kterých lze službu kvalitně zavést do provozu, stabilizovat a efektivně řešit případné incidenty. Na příkladu konkrétní banky a reálné transakční aplikace popíši ve třetí kapitole možnou implementaci jednoho z procesů ITILv3. Proces implementace stále probíhá, a proto budu ověřovat jen ty části procesu, které byly v průběhu dvou let implementovány a na jejichž implementaci jsem se podílel. Tyto dílčí procesy podrobněji rozeberu a budu analyzovat jejich konkrétní vliv na kvalitu a stabilitu služby. Ve čtvrté kapitole vyhodnotím implementaci vybraného procesu podle metrik, které budou sledovat vliv zavedení standardu na kvalitu a stabilitu služeb. Budu přitom pracovat s reálnými daty, která pokrývají období od roku 2008, kdy byla implementace zahájena, až do současnosti. Pro měření úspěšnosti implementace vyberu modelovou aplikaci, která poskytuje dostatečné portfolio služeb a je jednou z klíčových aplikací v bankovní instituci. V práci používám původní anglické termíny, protože jsou podle mého názoru srozumitelnější a jednoznačnější. Jedná se navíc o ustálenou terminologii, která se již běžně používá v praxi, a český překlad by v mnoha případech pouze komplikoval komunikaci.

1

2

Implementace standardu pro řízení IT služeb v bankovnictví

2 Základní procesy ITIL v bankovnictví IT Infrastructure Library (ITIL) je standard pro řízení IT služeb, který začal vznikat ve Velké Británii v 80. letech minulého století. Vznik knihovny byl motivován požadavky úřadu vlády Velké Británie na zavedení standardu pro řízení služeb. V 90. letech minulého století byla knihovna postupně rozšiřována, až došlo v roce 2004 k její standardizaci na ITILv2. Od roku 2007 je knihovna standardizovaná jako ITILv3, obsahuje šest základních publikací a je spravována Office of Government Commerce. ITIL není metodika, a to ani metodika IT Service Managementu (ITSM), ale standard pro návrh a dodržování ITSM procesů, který vychází z nejlepších praktických zkušeností a zároveň nechává volnost pro vlastní implementaci těchto procesů. Cílem řízení IT služeb je dosáhnout souladu IT služeb a reálných potřeb businessu a zároveň sladit poskytované IT služby s rychle se měnící poptávkou businessu (1). Standard ITIL vznikl jako souhrn nejlepších postupů z oblastí ITSM.

2.1 Obecná problematika Služby jsou prostředkem dodání hodnoty zákazníkům formou usnadňující tvorbu potřebných výstupů zákazníka bez specifických nákladů a rizik. Zákazník svoje služby naplňuje nezávisle na poskytovatelích služeb, hodnota ale nespočívá pouze v tom naplnit potřeby, ale také v tom, jak je naplnit a s jakými náklady a riziky. Služby zvyšují výkonnost odpovídajících úkolů a redukují efekty omezení, výsledkem je pak zvýšení pravděpodobnosti dosažení požadovaných výstupů (1). Správa služeb je sada specializovaných schopností organizace pro poskytování hodnoty zákazníkům formou služeb. Schopnosti mají formu funkcí a procesů pro řízení služeb v celém životním cyklu (1). Jádrem řízení služeb je transformace zdrojů organizace na služby přenášející hodnoty zákazníkům. Business Process (Obr. 1 (1)) je sada koordinovaných aktivit kombinující a implementující zdroje a schopnosti za účelem produkování výstupů, které přímo či nepřímo vytváří hodnotu pro externího zákazníka nebo zainteresovanou stranu.

Obr. 1 Schéma Business Process

Proces poskytuje transformace směrem k cíli, ale také zpětnou vazbu pro své posílení nebo nápravné akce. Definice procesu popisuje akce, závislosti a sekvence. Procesy jsou měřitelné, mají specifické výsledky, mají zákazníky a reagují na specifické události. Proces transformuje jeden či více vstupů na výstupy a zahrnuje role, odpovědnosti, nástroje, řízení.

Základní procesy ITIL v bankovnictví

Metriky procesu jsou důležité pro posuzování a řízení procesů. Podle ITIL totiž nelze řídit to, co není měřeno. Metriky procesu a metody jejich měření musí být zvoleny tak, aby bylo možné hodnotit schopnost procesů dostát svých cílů. ITIL definuje 4 typy metrik: Pokrok (Progress)

Milníky či produkty vypovídající o schopnostech procesu

Shoda (Compliance)

Soulad procesu s požadavky, regulačními omezeními

Účinnost (Effectivenes)

Přesnost a správnost procesu a jeho schopnost dodávat správné výsledky

Efektivita (Efficiency)

Produktivita procesu, jeho rychlost, propustnost a vytížení zdrojů

Funkce v ITIL jsou organizační jednotky specializované na provádění jistých typů prací a zodpovědné za specifické výstupy. Jsou vybavené schopnostmi a zdroji nezbytnými pro výkon těchto prací a zajištění výstupů. Mají vlastní znalostní základnu, kterou akumulují z vlastních zkušeností, a představují cestu strukturování organizace k implementaci specializovaných principů. Funkce definují role a jejich pravomoci a zodpovědnosti za specifické práce a výstupy (1). ITIL Library obsahuje dva typy publikací: 1. ITIL Core – zahrnuje nejlepší zkušenosti a rady aplikované na organizace všech typů poskytujících IT služby pro business. 2. ITIL Complementary Guidance – jsou doplňkové publikace pro specifické průmyslové sektory, typy organizací, provozní modely a technologické architektury. ITIL Core obsahuje 5 základních publikací:

Service Strategy Service Design Service Transition •Change Management •Service Asset and Configuration Management •Release and Deployment Management

Service Operation •Incident Management •Event Management •Request Fulfilment •Problem Management •Access Management

Continual Service Improvement

3

4


Obr. 2 ITIL Library

Základní struktura ITIL Library je na obr. 2 (1). Architektura ITIL Core vychází z životního cyklu služeb a její jednotlivé služby jsou specifikovány v tabulce 2. Komponenta ITIL Core Service Strategy Service Design Service Transition Service Operation Continual Service Improvement

Místo v životním cyklu Definuje pravidla a cíle

Fáze životního cyklu služeb Učení a zlepšování Tab. 1 Komponenty ITIL Core

2.2 Service Strategy Service Strategy poskytuje návod pro návrh, vývoj a implementaci řízení IT služeb. Popisuje nastavení interních/externích trhů, zavedení katalogu IT služeb a jejich přínosů a v neposlední řadě popisuje implementaci strategie napříč celým životním cyklem (2). Service Strategy má význam pro tyto aktivity: -

-

Pro provoz a úspěšný růst v dlouhodobém měřítku musí mít poskytovatelé služeb schopnost uvažovat a jednat strategickým způsobem a smyslem Service Strategy je pomoci organizacím vybudovat tuto schopnost. Service Strategy zodpovídá mimo jiné otázky: - Jaké služby a komu máme nabízet? - Jak se budeme diferencovat od konkurence? - Jak můžeme definovat kvalitu služeb? - Jak zvolit optimální cestu zvyšování kvality služeb? - Jak efektivně alokovat zdroje napříč portfoliem služeb?


2.3 Service Design Service Design poskytuje návod pro návrh a vývoj IT služeb a pro procesy řízení služeb. Zahrnuje principy návrhu a metody konverze strategických cílů na portfolio služeb. Neomezuje se pouze na návrh nových služeb, ale zahrnuje také změny a zlepšení služeb pro udržení jejich hodnoty pro zákazníka. Cílem je návrh nových/změněných služeb pro zavedení do produkčního prostředí při zvážení všech aspektů (3). Pro všechny aspekty návrhu služeb musí být uplatněn holistický systémový přístup pro zajištění konzistence a integrace v rámci všech aktivit a procesů napříč celou IT technologií, poskytující funkcionalitu a kvalitu, kterou řídí business. Etapa Service Design je zahájena sadou nových nebo změněných business požadavků a končí vyvinutím řešení služby splňující potřeby businessu. Přínosy Service Design pro business jsou (3): -

Redukce Total Cost of Ownership (TCO) Zvýšení kvality služeb Zvýšení konzistence služby Snadnější implementace nových/změněných služeb Zvýšení souladu služeb Efektivnější výkonnost služeb Zvýšené IT Governance Efektivnější řízení služeb a IT procesů Zlepšení informací a rozhodování

IT systémy a služby jsou navrhovány, plánovány, implementovány a řízeny pro business jako celek. Poskytované IT služby by měly být orientovány, zaměřeny a řízeny potřebami businessu, nákladově efektivní a bezpečné, flexibilní a adaptabilní, adekvátní účelu. Měly by být také schopny absorbovat rostoucí požadavky na množství a rychlost změn a zároveň zohledňovat zvyšující se požadavky businessu na kontinuální provoz. Jejich řízení a provozování by mělo probíhat s akceptovatelnou mírou rizik. Tlak na business a IT někdy vede k potlačení nebo dokonce vynechání aktivit Service Designu, ačkoliv jsou to nezbytné etapy. Organizace proto musí chápat etapy Service Design jako základní element řízení služeb. Je také třeba neustále zvyšovat schopnosti Service Design tak, aby se stala konzistentní a opakovatelnou praktikou, umožňující organizaci dodat kvalitní služby a redukovat rizika spojená s jejich nasazením a provozem. Implementace řízení služeb podle ITIL v praxi znamená použití 4P, kterými jsou lidé, procesy, produkty (technologie, nástroje), partneři (dodavatelé, prodejci). Jsou znázorněny na obr. 3.

People

Processes

Products/

Partners/

Technology

Suppliers

Obr. 3 People, Processes, Products, Partners = 4P

5

6


2.4 Service Transition Service Transition poskytuje návod pro vývoj a zlepšení schopností pro nasazení nových či změněných služeb do provozu. Zároveň nabízí doporučení pro řízení komplexity změn služeb s prevencí neočekávaných konsekvencí. Popisuje, jak jsou požadavky Service Strategy zahrnuté v Service Design efektivně realizovány v Service Operation při soustavné kontrole rizik výpadků služeb (4). Service Transition plánuje a řídí kapacity a zdroje potřebné pro sestavení, otestování, zavedení a uvolnění služby. Poskytuje konzistentní a rigorózní rámec pro vyhodnocení schopností služby a profilu rizik. Zavádí a udržuje integritu všech identifikovaných částí a konfigurací služby. Poskytuje informace pro podporu rozhodování a pro efektivní a opakovatelné mechanizmy sestavení a instalace. Zajišťuje řízení, provozování a podporu služby. Service Transition zároveň nastavuje očekávání zákazníka, jak bude nová/změněná služba použita s cílem umožnit změnu businessu. Cílem je redukovat odchylky v plánované a skutečné výkonnosti zaváděných služeb, redukovat známé chyby a minimalizovat rizika zavedení nových/změněných služeb do provozu. Musí také zajistit, že služba může být využívána v souladu s požadavky a omezeními v rámci požadavků na službu (4). Do oblasti Service Transition spadá řízení a koordinace procesů, systémů a funkcí pro kompletaci, sestavení, otestování a nasazení nových verzí do produkčního prostředí dané organizace. Naopak mimo rozsah Service Transition spadají tyto aktivity: -

Minoritní modifikace produkčních služeb a prostředí, např. výměna vadného PC nebo tiskárny apod. Kontinuální zlepšování služeb, které neovlivňuje významně službu.

Z pohledu BU umožňuje Service Transition sladit novou/změněnou službu s jejich požadavky a zajistit, že zákazníci a uživatelé mohou užívat nové/změněné služby způsobem, který maximalizuje přínosy pro chod businessu. Service Transition zároveň zlepšuje schopnost rychle se adaptovat na nové požadavky a na rozvoj trhu. Zvyšuje také podíl úspěšných změn a verzí nasazených do produkčního prostředí, minimalizuje dopady migrací na business. 2.4.1 Change Management Change Management je proces zodpovědný za řízení životního cyklu všech změn. Jeho cílem je umožnit realizaci požadovaných změn při minimálním narušení služeb IT. Musí také reagovat na měnící se business požadavky zákazníka při současné maximalizaci poskytované hodnoty a redukci incidentů, výpadků a nutnosti přepracování a oprav. Reaguje také na BU a IT změnové požadavky, které uvedou danou službu do souladu s business potřebami. Požadavek na změnu je přidání, modifikace nebo odstranění autorizované, plánované či podporované služby nebo její komponenty a její dokumentace. Change Management řídí následující typy změn: Malé – bez nutnosti zvláštního schvalování, jedná se např. o pravidelně se opakující zásahy, které jsou již dostatečně vyzkoušené a nehrozí tak dopad na kvalitu poskytované služby. Významné – změna služby či infrastruktury, pro niž existuje předem autorizovaný přístup. Změna je schvalována oprávněnou osobou, případně komisí. Pro rozhodující prvky standardních změn platí, že činnosti spojené s nasazením jsou dobře známy, zdokumentovány a zavedeny. Rizika jsou obvykle malá a jasná.


Kritické – občas nutná a nevyhnutelná změna. Je nutné zevrubné testování a obezřetný postup, neboť dopad změn může být větší, než jaký by měl původní incident, který kritickou změnu vyvolal. Počet těchto změn by měl být držen na absolutním minimu. Kritické změny služeb jsou proto vyhrazeny pro opravy chyb IT služeb, které významným způsobem negativně ovlivňují business. Schvalování těchto změn je zpravidla ve zkráceném řízení, kdy musí samotné schválení provést předem určená autorita, někdy Emergency Change Advisory Board (ECAB). V kritických situacích totiž není možné svolávat jednání celého Change Advisory Board (CAB). Change Management zajišťuje, aby pro efektivní a promptní řízení všech změn byly použity standardizované metody a procedury. Všechny změny v aktivech služeb a konfiguračních položkách jsou zaznamenány v Systému správy konfigurací (4). Cílem procesu je také optimalizovat celková business rizika. Úkolem pak je, aby jednotlivé změny služeb byly zaznamenány, vyhodnoceny, schváleny, prioritizovány, plánovány, testovány, implementovány, dokumentovány a přezkoumány řízeným způsobem. Pro úspěšnou implementaci procesu Řízení změn jsou nezbytné politiky a standardy, které zahrnují: -

Vytvoření kultury Change Management napříč celou organizací, kde tolerance neautorizovaných změn bude nulová. Sladění Change Management s potřebami businessu. Prioritizace změn, tzn. nastavení různých priorit pro změny typu inovace, prevence, oprava, kritická oprava. Zavedení zodpovědnosti za změny v průběhu celého jejich životního cyklu. Zavedení jednotného místa pro změny s cílem minimalizovat pravděpodobnost konfliktních změn. Zabránění přístupu neautorizovaných osob do produkčních prostředí. Zabránění přístupu neautorizovaných osob do testovacích prostředí. Integrace s dalšími procesy Řízení služeb. Vyhodnocení výkonnosti a rizik pro všechny změny s dopadem na způsobilost služeb.

Pro efektivní správu požadavků v rámci Řízení změn jsou využívány Request for Change (RFC) nástroje, které mohou mít celou řadu podob. Rozdílné typy změn mohou vyžadovat rozdílné typy požadavků na změnu, a proto je nutné zajistit adekvátní procedury a formuláře pro pokrytí všech typů požadavků na změnu. Nástroj by měl také podporovat distribuci pracovních příkazů souvisejících s požadavkem na zodpovědné osoby, které nasazení změny provedou podle popsaného zadání. Aktivity Change Management procesu zahrnují: -

Plánování a řízení změn a verzí. Komunikaci. Rozhodování o změnách a jejich autorizaci. Zajištění existence rollback scénářů pro případ neúspěšného nasazení změny. Měření a kontrolu. Reporting. Porozumění dopadu změn. Kontinuální zlepšování.

Základní aktivity při řízení individuálních změn pomocí RFC nástroje jsou následující a jsou znázorněné na obr. 4 (4) – záznam požadavku na změnu, přezkoumání formální a věcné stránky požadavku, vyhodnocení dopadu požadavku, autorizace změny, schválení požadavku, plánování případných oprav, koordinace nasazení změny do produkčního prostředí, plánování zvýšené podpory po nasazení změny, informace businessu o plánovaném termínu nasazení změny, přezkoumání a uzavření změny.

7

8


Obr. 4 Životní cyklus RFC

Vytvoření a záznam požadavku na změnu jsou iniciovány jednotlivcem nebo organizační jednotkou. Každý požadavek pak dostane přiřazené unikátní identifikační číslo. Termín nasazení změny musí být plánován, a proto záznam požadavku obsahuje datum a čas. Následně je požadavek přezkoumán a jsou vyřazeny změny, které jsou zcela nepraktické nebo opakují již dříve schválený/zamítnutý/realizovaný požadavek anebo mají neúplnou dokumentaci. Požadavek je následně vrácen jeho iniciátorovi společně s popisem důvodu zamítnutí. Finální schválení požadavku je v gesci Poradního výboru pro změny (CAB). Ten při rozhodování zohledňuje následující skutečnosti. -

Dopad změny na business aktivity zákazníka. Efekt na infrastrukturu a službu, posuzuje se zejména výkonnost, spolehlivost, odolnost a bezpečnost. Dopad na ostatní služby, které jsou provozovány na stejné infrastruktuře. Efekt neimplementování změny; zde může nastat problém např. z důvodu změny legislativy nebo v souvislosti s přechodem země na novou měnu (Slovenská republika, 1.1.2009). Zdroje potřebné pro provedení změny, včetně nákladů a předpokládané doby realizace. Plán provedení změny a Project Service Outage (PSO). Existence rollback plánu. Nové trvalé zdroje vyžadované po implementaci změny. Dopad na plán kontinuity, plán kapacit, plán bezpečnosti. Dopad na testovací a produkční prostředí. Dopad na pravidelné zpracování, např. noční reporting.


CAB je orgán, jehož smyslem je schvalování změn a posuzování a prioritizace požadavků. O změnách může rozhodnout sám nebo jen s doporučením předat příslušné autoritě. Musí být složen z osob, které jasně rozumí potřebám businessu a mají výborné znalosti a zkušenosti v oblasti provozu produkčních systémů. Předsedou CAB typicky bývá Change Manager, dalšími členy bývají: -

zákazník, manažeři uživatelů, zástupci uživatelů, vývojáři aplikací, specialisté, techničtí konzultanti, Service Desk, Service Level Management (SLM), Change Authority, Change Coordinator, zaměstnanci správy budov a majetku, zástupci zainteresovaných třetích stran.

Složení CAB se může lišit schůzku od schůzky na základě typu projednávaných změn, obvykle se ale účastní všichni členové CAB a v závislosti na projednávaných změnách i přizvaní hosté. Speciální skupinou CAB je Emergency CAB (ECAB), který slouží pro případ výskytu kritických změn. Jedná se zpravidla o menší organizační jednotku s příslušnou autoritou ke schválení změn tohoto typu. Kritické změny ECAB schvaluje mailem nebo telefonicky ve zrychleném módu, projevuje se individuální přístup. Change Manager přijímá, zaznamenává a nastavuje priority ve spolupráci se zadavatelem změny, případně zamítá nepraktické změny. Předkládá požadavky na změny v rámci schůzky CAB, zveřejňuje program schůzky a zajišťuje rozeslání podkladů v předstihu před jednáním. Rozhoduje o členech CAB a přizvaných hostech, kteří se budou daného jednání účastnit. Change Manager svolává a řídí schůzky CAB a ECAB, na kterých doporučuje akceptovatelné změny. Zveřejňuje plán změn a verzí prostřednictvím Service Desku. Řídí přezkoumání všech implementovaných změn a generuje pravidelné reporty pro management a business. Žádná změna není bez rizika. I malé změny, které jsou zdánlivě bez dopadů a rizik na stabilitu služby, mohou způsobit velké škody. Změny proto musí být posuzovány z pohledu rizik a je tedy nutné identifikovat faktory, které mohou přerušit business operace, bránit dodávce služeb nebo jinak ovlivnit cíle organizace. Relevantní rizika je třeba posoudit, široce komunikovat a příslušným způsobem schválit osobou zodpovědnou za konkrétní business službu. Nutnou podmínkou pro schválení změny je tedy souhlas ze strany business. Posouzení rizik z pohledu businessu je totiž pro nasazení do produkčního prostředí klíčové. Speciálním, v některých případech nevyhnutelným typem změn jsou změny kritické. Jejich negativní dopad po nasazení do produkce může být větší, než v případě původního incidentu, který odstraňují. Počet těchto změn musí být minimální, jsou totiž z pohledu stability služeb nejrizikovější. Zpravidla tyto změny opravují chyby, které významným negativním způsobem ovlivňují business a mají přímý dopad na klienta. Tyto změny musí mít jasně definovanou úroveň autorizace, tou je zpravidla ECAB. Na základě posouzení dopadů, rizik a potencionálních přínosů změny by měl každý člen CAB jasně indikovat, zda podporuje implementaci dané změny do produkčního prostředí či nikoliv, případně za jakých podmínek (schválení změny s podmínkou). Pro nastavení pořadí realizace změn je nutné určit jejich prioritu. Každý požadavek proto obsahuje klasifikaci dopadu a naléhavosti. Priorita jednotlivých změn, a tím i jejich pořadí, je pak odvozena od jejich dopadu a naléhavosti. Dopad změny je určen přidanou hodnotou, kterou poskytuje businessu po úspěšném nasazení změny do produkce, nebo stupněm poškození a extra náklady při nasazení neúspěšném (4). Naléhavost změny je odvozena od doby, s jakou může být její implementace zpožděna.

9

10


Plánování změn podle doporučení ITIL: -

-

Řada změn může být spojena do jedné společné verze. Mnoho nezávislých změn obsažených v jedné verzi vytváří zbytečné vazby, které lze jen obtížně řídit a definovat jejich rizika. Pokud naopak verze obsahuje jen malé množství změn, roste režie v podobě řídících aktivit a správě verzí. Metodika ITIL proto doporučuje, aby Change Manager plánoval změny podle jejich ovlivnění business potřeb, nikoli IT. Change Manager řídí vytvoření plánu změn, tzn. detaily změn schválených k implementaci, očekávaný termín implementace, plánované výpadky služeb.

Autorizací změny rozumíme získání formálního schválení změny od příslušné autority. Autoritou může být role, osoba nebo skupina lidí a její úroveň pro konkrétní změnu by měla být posouzena podle typu a velikosti rizik, plynoucích z požadované změny. Změny s dopadem na celou organizaci, např. s dopadem na centrální databázi, nad kterou poskytuje služby více aplikací, musí být schváleny nejvyšší autoritou - Poradním výborem pro změny. CAB může autorizaci změn dále delegovat. Autorizace změn a jejich prvotní prozkoumání se typicky odehrává na pravidelných schůzkách CAB. Ideálním modelem jsou pravidelné schůzky CAB a přizvaných hostů v kombinaci s elektronickou komunikací a RFC nástroji. Do agendy schůzek spadají zhavarované, nevrácené a neautorizované změny. Dále se posuzují požadavky v předem daném pořadí podle priorit, hosté jsou pak přizvání na základě harmonogramu probíraných změn. V rámci schůzek se také plánují významné změny a aktualizuje se plán těchto změn. Plán významných změn je pak transparentní pro business. Na závěr je předložen přehled změn, které budou projednávány na další schůzce CAB. V případě, že se CAB nedohodne na doporučení, je finální rozhodnutí o schválení změny a uvolnění příslušných prostředků v gesci vyššího managementu. Koordinace implementace změny je část procesu, která navazuje na autorizaci požadavku. Schválené změny se podle oblasti předávají konkrétním technickým skupinám k realizaci. Distribuci má v gesci skupina Change Coordinators. Změny a jejich pracovní příkazy jsou předávány formálním způsobem a jsou tak snadno sledovatelné. Change Manager je pak zodpovědný za implementaci změn podle plánu. Stejně tak zodpovídá i za případný rollback změny podle předem daného a schváleného scénáře. Procedury pro obnovení by měly být připraveny tak, aby v případě neúspěšného nasazení změny mohly být rychle aktivovány a eliminovaly tak dopad na kvalitu služby. Pro zadavatele z toho vyplývá velký důraz na pečlivou přípravu rollback scénáře. Prozkoumání a uzavření změny uzavírá proces Service Transition. Provádí se pro ověření dosažení plánovaného cíle. Change Manager musí také přezkoumat nové/změněné služby po určité době od zavedení změny. Na přezkoumání se podílí i členové CAB a účelem takového přezkoumání je zjistit, zda je klient/uživatel spokojen s výsledkem změny, zda změna nemá žádné neočekávané vedlejší efekty na ostatní služby, funkcionalitu, performance, záruku apod. Zkoumá se také, zda zdroje potřebné na zavedení a následnou podporu služby odpovídají plánu. Ověřuje se, zda plán verzí a nasazení zafungoval korektně, stejně tak i případný rollback scénář. 2.4.2 Release And Deployment Management Release And Deployment Management (RDM) definuje a schvaluje plány verzí se zákazníky a zainteresovanými osobami. Jeho účelem je zajistit, aby každý migrační balíček sestával ze sady vzájemně kompatibilních aktiv a komponent služby a aby zároveň byla udržena integrita balíčku v průběhu procesu Service Transition. Účelem je také garance, že všechny balíčky jsou sledovány, instalovány, testovány, verifikovány a v případě potřeby odinstalovány přes všechna klíčová prostředí. Proces zaznamenává a řídí odchylky, rizika, problémy a realizuje nezbytná nápravná opatření. Další funkcí procesu je také sdílení poznatků a jejich distribuce na zákazníky a uživatele, kteří pak mohou službu optimálně využívat. Znalosti je také nutné pravidelně předávat do provozu a k pracovníkům podpory, aby byla podpora služby vždy aktuální a schopná rychlého zásahu.


Cílem RDM je nasazovat nové verze služby do produkčního prostředí, nastavit efektivní používání služeb s cílem dodat zákazníkovi přidanou hodnotu. Proces pak uzavírá předání řízení služby do Service Operation. Mezi hlavní úkoly RDM patří zajištění jasných a vyčerpávajících plánů verzí, které umožní zákazníkovi plánovat business projekty. Do gesce RDM spadá kompletace, instalace, testování a efektivní implementace nových verzí do cílového prostředí podle daného a předem schváleného plánu. Proces minimalizuje neočekávané dopady na produkční služby, provozní a podpůrnou organizaci. Zákazníci, uživatelé a pracovníci správy služeb by měli být spokojeni s praktikami Service Transition (uživatelská dokumentace, školení, dostupnost služby v jednotlivých prostředích, minimální nedostupnost služby, minimální změny termínů). Jednotka nasazení je definovaná jako část služby, která je nasazována dohromady na základě politiky nasazování. Cílem je stanovit nejvhodnější úroveň jednotky podle snadnosti a množství změn nezbytných pro uvolnění a nasazení změny do konkrétního prostředí. Důležitými parametry jsou také množství zdrojů a čas potřebný k nasazení jednotky, komplexita rozhraní mezi jednotkou nasazení a zbytkem služby a též dostupný úložný prostor pro sestavení, testy, distribuci a provozní prostředí. Každá jednotka nasazení musí být jednoznačně identifikována, nejčastěji pomocí číselného kódu, který její verzi jasně definuje. Z pohledu distribuce nových verzí na více lokalit jsou definovány dva přístupy:  

Big Bang – metoda velkého třesku, kdy je nová verze nasazena najednou do všech lokalit. Phased – nová verze se nasazuje do lokalit postupně, fázově.

Instalační balíček může být jednoduchou jednotkou nasazení nebo strukturovanou sadou jednotek, implementace je řízena modelem nasazení. Služba může být totiž nasazena do produkčního prostředí různými způsoby. Úkolem Service Design je vybrat nejlépe vyhovující model nasazení pro danou službu. Model nasazení pak musí definovat strukturu instalačního balíčku, vstupní a výstupní kritéria a požadovanou dokumentaci pro každou etapu. Model nasazení také určuje role a jejich zodpovědnosti v procesu, definuje harmonogram nasazení, migrační plán. Model definuje podpůrné systémy, nástroje a procedury pro dokumentování a sledování všech aktivit souvisejících s nasazením změny do daného prostředí. Obvyklé role, které zajišťují fungování RDM procesu jsou Release and Deployment Manager, Release Packaging and Build Manager, Deployment a Early Life Support (ELS). Release And Deployment Manager je zodpovědný za plánování, návrh, sestavení, konfiguraci a testování software a hardware pro sestavení instalačního balíčku. Mezi jeho další povinnosti patří řízení všech aspektů RDM, koordinace týmů sestavení a nasazení, reportování o nasazení verzí na management a business. Release Packaging And Build Manager nastavuje finální konfiguraci instalačního balíčku pro dané prostředí, sestavuje finální dodávku verze, testuje finální dodávku před nezávislým testováním, nastavuje a reportuje přetrvávající známé chyby a jejich možné obejití a poskytuje vstupy do procesu finální implementace. Deployment se zabývá fyzickým nasazením implementace dané služby, koordinuje dokumentaci verze a komunikaci, plánuje nasazení spolu se správou změn. Poskytuje technické a aplikační konzultace a podporu v průběhu RDM, včetně známých chyb a obejití. Jeho úkolem je také poskytování zpětné vazby o efektivnosti verze. Zaznamenává metriky nasazení a porovnává je s hodnotami určenými SLA, např. dopad na dostupnost služby.

11

12


Early Life Support je podpora poskytovaná pro nové nebo změněné IT služby po určitou dobu po jejich nasazení. V průběhu počáteční podpory může poskytovatel služeb IT znovu posoudit klíčové ukazatele výkonnosti (KPI), úroveň služby a prahové hodnoty monitorování. Rovněž může poskytnout dodatečné zdroje pro správu incidentů a problémů. Počáteční podpora by měla být posouzena jako integrální část fáze nasazení změny. Pracovníci z odboru ELS jsou zodpovědní za poskytování podpory IT služeb businessu od začátku až po akceptaci Service Operation. Mají také zajistit dodávku adekvátní podpůrné dokumentace, provést akceptaci verze pro zahájení úvodní podpory a poskytovat úvodní podporu v reakci na incidenty a chyby detekované v nové/změněné službě. Prostředníkem mezi koncovými uživateli a ELS je Service Desk.

2.5 Service Operation Service Operation je místem, kde je z pohledu zákazníka přidaná hodnota skutečně vidět. Účelem je koordinace a provedení aktivit a procesů vyžadovaných pro dodání a řízení služeb business uživatelům a zákazníkům na smluvně dohodnuté úrovni. Řídí také technologie, které jsou použité pro dodávku a řízení služeb, kontroluje a řídí provozní procesy (5). Poskytuje návody pro dosažení výkonnosti a efektivity při dodávce a podpoře služeb. Radí také, jak udržet stabilitu služeb při umožnění změn návrhu, rozsahu a úrovně služeb. Poskytuje znalosti umožňující dělat lepší rozhodnutí v oblastech, jako je řízení dostupnosti, řízení kapacit a jejich utilizace, plánování provozu a opravy problémů. Jednou z klíčových aktivit Service Operation je balancování konfliktních aspektů v řízení služeb (5): IT služby vs. technologické komponenty  

Pohled na IT jakožto na sadu IT služeb (externí BU pohled). Pohled na IT jakožto sadu technologických komponent (interní IT pohled).

Pro praxi jsou nezbytné oba pohledy. Organizace, která se příliš soustředí na BU pohled, může po čase zjistit, že slibuje nesplnitelné. Organizace, která se naopak zaměřuje až příliš na interní systémy, nakonec zjistí, že nabízí drahé služby přinášející jen malou hodnotu. Stabilita vs. rychlost reakce na změny Service Operation zajišťuje stabilní IT infrastrukturu, zároveň ale musí brát v potaz, že business vyžaduje změny stávajících služeb, nebo zadává požadavky na služby nové. Mnoho změn je přitom evolučních, takové lze plánovat a udržet přitom požadovanou stabilitu. Řada změn ale vzniká rychle a pod tlakem. Mnoho organizací nedokáže oba póly vybalancovat a má tendenci se zaměřit více na stabilitu nebo na odezvu na změny. Kvalita vs. náklady na službu Service Operation má konzistentně dodávat domluvenou úroveň IT služeb a zároveň přitom udržovat náklady a vytížení zdrojů na optimální úrovni. Mezi kvalitou a náklady přitom existuje přímá úměra, klíčové je pak nalézt optimální úroveň. V bankovnictví je kladen zvýšený důraz na kvalitu IT služeb, cenou jsou pak vyšší náklady na udržení požadované kvality. Reaktivní vs. proaktivní přístup Reaktivní organizace je taková, která nedělá nic, dokud o to není požádána externím podnětem, např. požadavkem na změnu. Naopak proaktivní organizace se vždy ohlíží na okolí a hledá způsoby, jak zlepšit svůj aktuální stav. Proaktivní chování je obecně považováno za lepší, na druhou stranu ale může být příliš drahé. Service Operation má udržovat rovnováhu mezi reaktivním a proaktivním přístupem. To vyžaduje formálně nastavené procesy Problem Management a Incident Management a


integraci mezi Service operation a CSI. Zároveň je pro udržení rovnováhy nutná prioritizace chyb a business požadavků. Jednotlivé procesy probíhající v rámci Service Operation jsou rozepsány v následujících kapitolách. 2.5.1 Incident Management Cílem procesu Incident Management je obnovit co nejrychleji normální provoz služby a minimalizovat nepříznivý dopad na business operace. Nezabývá se přitom hledáním příčin incidentů ani jejich trvalým řešením. Zahrnuje jakékoliv události, které přeruší nebo mohou přerušit dodávku služby. Incident je neplánované přerušení služby, nebo redukce její kvality (částečná vs. celková nedostupnost služby). Pro všechny etapy řešení incidentu musí být definováno časové měřítko, přičemž záleží na prioritě incidentu a podmínkách zakotvených v příslušné SLA. Každá podpůrná skupina si musí být těchto časových měřítek plně vědoma. Řada incidentů není nových a týkají se většinou něčeho, co se již v minulosti stalo a co se opět jistě bude opakovat. Model incidentu (Obr. 5 (5)) obsahuje chronologicky seřazené kroky, které by měly být provedeny při řešení daného typu incidentu, včetně všech závislostí. Důležitá je přitom komunikace mezi řešitelem a koncovým uživatelem a nastavení pravidel komunikace pro oba směry. Komunikačním prostředníkem bývá zpravidla Service Desk. Model definuje posloupnost jednotlivých kroků, určuje, kdo má co dělat, a obsahuje časová měřítka a limity pro dokončení požadovaných akcí. Určuje také eskalační procedury, tedy kdo a kdy má být kontaktován. Model incidentu zároveň slouží jako vstup pro podpůrné nástroje, které mohou řadu kroků automatizovat. ITIL definuje v rámci Modelu incidentu následující kroky: Identifikace incidentu je nezbytná proto, aby mohly jednotlivé akce začít. Není přitom možné jen čekat, až uživatel kontaktuje Service Desk. Je nutné v co největší míře aplikovat proaktivní přístup, například v podobě monitoringu kritických částí IT infrastruktury. V ideálním případě je potom incident vyřešen dříve, než ho zaznamenají koncoví uživatelé! Každý incident musí být plně zaznamenán, včetně časového razítka, bez ohledu na způsob oznámení. Během řešení incidentu musí být uchovány a v aktuálním stavu udržovány všechny relevantní informace. Kategorizace incidentu spočívá v zařazení incidentu do příslušných kategorií a umožňuje budoucí sledování trendů. Zpravidla jsou incidenty kategorizovány do více úrovní, např. HW-Server-Memory board-Card Failure nebo SW-Application-Finance Suite-Transaction System. Prioritizace incidentu určuje prioritu řešení incidentu. Priorita je přitom určena na základě urgence (jak rychle potřebuje business řešení) a dopadu incidentu na kvalitu poskytované služby. Je třeba brát v potaz další hlediska, jako např. počet ovlivněných služeb a uživatelů, úroveň finančních ztrát, efekt na dobré jméno businessu nebo regulační a legislativní přestupky. Jednoduchý kódovací systém, podle kterého je možné určit prioritu incidentů, je v tabulkách 2 a 3.

Urgence

Vysoká Střední Nízká

Vysoký 1 2 3 Tab. 2 Určení priority incidentu

Dopad Střední 2 3 4

Nízký 3 4 5

13

14


Priorita 1 2 3 4 5

Popis Kritická Vysoká Střední Nízká Plánovaná

Čas řešení 1h 8h 24 h 48 h plánováno

Tab. 3 Priorita incidentu

Úvodní diagnóza je prvotním krokem při řešení incidentu. Pokud je incident směřován přes Service Desk, musí analytik SD provést úvodní diagnózu. V praxi je uživatel stále na telefonu, analytik se snaží zjistit všechny symptomy incidentu. Eskalace incidentu nastane, pokud SD nedokáže vyřešit incident sám, nebo překročí stanovený čas na řešení. Hierarchická eskalace incidentu nastává, má-li incident vážnou povahu, diagnóza trvá příliš dlouho, nebo není jasné, komu přidělit incident k řešení. Vyšetřování a diagnóza je fáze, která hledá příčinu incidentu. Všechny aktivity by měly být zaznamenány v záznamu incidentu. Mezi typické aktivity v rámci této fáze patří zjištění, co se přesně stalo, pochopení chronologie událostí, zjištění dopadu incidentu, identifikace jakýchkoliv událostí, které mohly incident vyvolat, a prohledávání znalostní báze. Vyřešení a zotavení nastupuje ve chvíli, kdy je identifikováno potenciální řešení incidentu. Toto řešení by pak mělo být otestováno a aplikováno. Mezi typické aktivity patří vyzvání uživatele, aby na své stanici provedl zadané akce, nebo požádání specializované podpůrné skupiny o provedení specifických akcí. Uzavření incidentu je posledním krokem řešení. SD musí ověřit, zda byl incident plně odstraněn, zda je uživatel plně spokojen s provedeným řešením a zda souhlasí s uzavřením incidentu. Je nutné také zajistit kategorizaci a dokumentaci incidentu. Pokud je pravděpodobné, že se daný typ incidentu bude opakovat, pak je tato skutečnost komunikována na Problem Management, který založí záznam o problému a přijme potřebná preventivní opatření. Pro posouzení efektivity procesu Incident Management je nutné sledovat a reportovat metriky uvedené v tabulce 4: 1

Celkový počet incidentů

2

Velikost aktuálního seznamu incidentů

3

Počet a procento závažných incidentů

4

Průměrný čas pro nalezení řešení nebo obejití incidentů

5

Procento incidentů vyřešených v souladu s nastavením SLA

6

Průměrné náklady na incident

7

Procento incidentů vyřešených Service Deskem Tab. 4 Metriky Incident Managementu

Úspěšný Incident Management musí být schopen detekovat incidenty co možná nejdříve. K tomu náleží vzdělávání uživatelů, kteří hlásí incidenty, a zapojení klíčových uživatelů do procesu. Musí přesvědčit pracovníky o nutnosti zaznamenávání všech incidentů a musí zajistit dostupnost informací o problémech a známých chybách (5).


Obr. 5 Model incidentu

15

16


Incident Manager je zodpovědný za řízení efektivity a výkonnosti procesu, poskytování manažerských informací a řízení pracovníků 1. a 2. úrovně podpory. Řídí závažné incidenty. První úrovní podpory je přitom myšlený Service Desk, druhá úroveň podpory disponuje hlubšími technickými znalostmi a dovednostmi a je schopna vyřešit méně komplikované incidenty. Do třetí úrovně podpory spadají technicky orientované skupiny, jakými jsou například Network Support, Server Support, Terminal Support, Database Support a Application Management. 2.5.2 Event Management Event Management je schopen detekovat události, dávat jim význam a stanovit patřičné řídící akce. Je odpovědný za správu událostí během jejich životního cyklu a poskytuje vstupní bod pro provádění mnoha procesů v rámci provozu služeb (5). Událost je jakákoliv detekovatelná a zjistitelná příhoda, která má význam pro správu IT infrastruktury nebo dodávku IT služeb. Události jsou obvykle notifikace vytvořené IT službou nebo monitorovacími nástroji. Efektivní provoz služeb je závislý na znalosti stavu infrastruktury a na detekci jakýchkoliv odchylek od normálního nebo očekávaného provozu. Události rozdělujeme do tří základních typů: -

-

-

Události informující o pravidelném zpracování. Do této skupiny patří notifikace o dokončení plánovaného zpracování, notifikace o přihlášení uživatele do systému nebo potvrzení o doručení e-mailu. Události signalizující výjimku, např. uživatel se pokouší přihlásit k aplikaci chybným heslem, neobvyklá situace v business procesu, nebo zatížení procesoru přesahuje akceptovatelnou úroveň. Události, které signalizují neobvyklý, ale ne výjimečný provoz, např. využití paměti serveru dosahuje nejvyšší akceptovatelné úrovně, nebo čas dokončení transakcí je o 10% delší než standardně.

Role Event Manager nebývá ustanovena, protože události se objevují v mnoha kontextech. Je však důležité, aby procedury EM byly koordinovány. Do správy událostí je typicky zapojen SD a technická a aplikační správa. 2.5.3 Request Fulfilment Request Fulfilment je proces odpovědný za řízení životního cyklu všech požadavků na službu. Poskytuje uživatelům kanál pro požadavky na standardizované služby, pro které existuje předdefinovaný proces schvalování a kvalifikace (5). Zároveň uživatelům poskytuje informace o dostupnosti služeb a proceduře na jejich získání. Proces dodává komponenty standardních služeb, jako např. licence software apod. Týká se většinou požadavků na malou změnu, tzn. změnu, se kterou je spojeno nízké riziko, nízké náklady a často se opakuje. Vzhledem k tomu, že mnoho požadavků na služby se často opakuje, může být sestaven předdefinovaný proces (model), který obsahuje nutné etapy a kroky k uspokojení těchto požadavků. Tento přístup je základním konceptem procesu Request Fulfilment. 2.5.4 Problem Management ITIL definuje Problem jako neznámou příčinu jednoho či více incidentů (5). Problem Management je procesem odpovědným za řízení životního cyklu všech problémů. Primárním úkolem je zabránit problémům a incidentům, eliminovat opakující se incidenty a minimalizovat dopad incidentů, kterým nebylo možné zabránit. Model problému obsahuje chronologicky seřazené kroky, které by měly být provedeny při řešení daného typu problému, včetně všech závislostí. Jedná se o podobný koncept jako v případě Modelu incidentu a zpravidla obsahuje následující kroky:


1. Detekce problému spočívá v detekci neznámé příčiny několika incidentů. Zahrnuje analýzu incidentů technickou skupinou, automatickou detekci infrastruktury nebo notifikaci dodavatele. 2. Zaznamenání problému, bez ohledu na způsob detekce musí být zaznamenány veškeré relevantní informace problému. 3. Kategorizace problému, podobně jako v případě incidentu. 4. Prioritizace problému, prioritizovány podobně jako incidenty. 5. Vyšetřování a analýza, klíčová je identifikace kořenové příčiny, kdy rychlost a povaha vyšetřování závistí na dopadu. Mezi používané techniky patří chronologická analýza událostí, analýza stupně závažnosti, brainstorming, Ishikavovy diagramy nebo Paretova analýza. 6. Workarounds spočívá v dočasném obejití incidentů způsobených problémem. Jakmile je k dispozici workaround, musí být evidován. 7. Zaznamenání známé chyby. Jakmile je hotova diagnóza a zejména, pokud je nalezen workaround, musí být vytvořen záznam známé chyby. 8. Vyřešení problému, oprava má zpravidla podobu RFC resp. ERFC. 9. Uzavření problému, formální uzavření záznamu problému, související incidenty zůstávají otevřené. 10. Přezkoumání závažného problému, hlavním cílem je zabránit opakování. Problem Manager je jmenovaná osoba/tým. V malých organizacích může být kombinovaná s další rolí, ale nikdy ne s technickými zdroji. Problem Manager koordinuje veškeré aktivity Problem Managementu a v jeho kompetenci je i řízení spolupráce mezi všemi skupinami řešícími problémy, dále i vlastnictví a ochrana Known Error Database (KEDB) a formální uzavírání problémů. 2.5.5 Access Management Access Management je proces přidělující autorizovaným uživatelům práva k používání služeb a naopak neautorizovaným uživatelům v přístupu brání. Umožňuje tím uživatelům používat služby IT, přístup k datům nebo jiná aktiva. Pomáhá zajišťovat důvěryhodnost, integritu a dostupnost aktiv tím, že tato aktiva pak mohou být modifikována pouze autorizovanými uživateli. Tento proces je posledním článkem v Service Operation.

2.6 Continual Service Improvement Continual Service Improvement (CSI) poskytuje návody k vytvoření a udržení hodnoty služeb pro zákazníky pomocí lepšího návrhu, zavedení a provozu služeb (6). CSI v sobě kombinuje praktiky, principy a metody z oblastí Quality Management, Change Management a Capability Improvement. Primárním účelem CSI je kontinuální zajištění souladu IT služeb s měnícími se potřebami businessu a s identifikací a implementací zlepšení do IT služeb, které podporují business. Základním principem CSI je měření. Platí totiž, že nemůžete řídit to, co nekontrolujete, nemůžete kontrolovat to, co neměříte, a zároveň nemůžete měřit to, co nedefinujete (6). Cílem CSI je přezkoumat, analyzovat a doporučit možnosti zlepšení v každé fázi životního cyklu, kontrolovat plnění požadavků SLA. Cílem je i identifikovat a implementovat individuální aktivity ke zlepšení kvality IT služeb a zvýšit efektivitu souvisejících ITSM procesů. Důležité je pozvednout nákladovou efektivitu dodávky IT služeb bez poklesu spokojenosti zákazníka. Demingův cyklus zlepšuje služby a procesy řízení služeb, zahrnuje tyto fáze: -

Plánování iniciativ zlepšení (Plan) spočívá v nastavení cílů a metrik úspěchu a v definici kroků pro zaplnění mezer.

17

18


-

Implementace iniciativ ke zlepšení (Do) zahrnuje realizaci projektů pro překlenutí identifikovaných mezer. Monitorování procesů řízení služeb (Check) srovnává implementovaná řešení s metrikami úspěchu s cílem určit, zda se podařilo mezeru vyplnit nebo alespoň zmenšit. Kontinuální zlepšování služeb (Act) rozhoduje, zda zachovat stávající stav, nebo přidat nezbytné zdroje.

CSI reprezentuje uzavření Demingova cyklu Plan-Do-Check-Act (Obr. 6 (6))

Obr. 6 Plan-Do-Check-Act cyklus

Konstantní cyklus pro zlepšování v šesti krocích (obr. 7 (6)):

Obr. 7 CSI cyklus

Prvním krokem cyklu je přijetí vize na základě pochopení představ a cílů businessu. Druhým krokem je posouzení aktuální situace z pohledu business, procesů, lidí, organizace a technologií. Třetí krok spočívá v pochopení a dohodnutí se na prioritách pro zlepšování podle měřitelných cílů. Dalším krokem je rozpracování CSI plánu, který má zajistit dosažení dohodnutých priorit. Předposlední krok ověřuje, zda bylo dosaženo plánu na základě metrik a měření. Na závěr přichází ověření, zda rychlost zlepšování kvality je udržována zakotvením principu neustálých změn v organizaci. Po tomto kroku se cyklus začne opakovat v konstantním pořadí. Opakováním cyklu je zajištěno průběžné zlepšování procesu řízení služeb.

Implementace procesu Change Management

3 Implementace procesu Change Management V této části práce popíší implementaci procesu Change Management v bankovní instituci. Jako model pro implementaci vybraného ITIL procesu jsem zvolil velkou českou finanční instituci1, která má okolo 8 tisíc zaměstnanců a poskytuje komplexní bankovní služby. Modelová instituce má v současnosti implementovaný COBIT framework pro řízení procesů na úrovni top managementu. Organizační struktura modelové instituce je složena z několika útvarů. IT útvar má okolo 300 zaměstnanců a 2 oddělení. Implementace procesů ITIL se primárně vztahuje na tento útvar, který poskytuje a podporuje IT služby businessu a zákazníkům. Až 90% obchodní činnosti modelové instituce je plně závislých na dostupnosti IT služeb. Velký důraz je proto kladen na rychlost řešení provozních incidentů, řešení problémů a řízení změn. Service Desk je klíčovým bodem celého útvaru, a proto je identifikován jako nejkritičtější.

3.1 Modelová aplikace Obecným způsobem zde rozepíši, jak probíhá údržba a podpora velké transakční aplikace, následně se pokusím ukázat, jak může metodika ITIL pomoci při jejím spravování v praxi. Jedná se o aplikaci, která spadá svým zaměřením a rozsahem do korporátních informačních systémů. Modelová aplikace poskytuje rozhraní mezi uživatelem a hlavním účetním systémem. Z pohledu architektury jde o třívrstvý systém: -

klient (uživatelské rozhraní), aplikační server (business logika), databáze (úložiště dat).

Mezi hlavní poskytované služby patří typování hotovostních, bezhotovostních a hromadných transakcí, šekové funkcionality, dohledávání transakcí v transakční historii, reporting, notifikace zákazníkům a audit. Tato business kritická aplikace v průměru zpracovává 100 000 transakcí denně a běží v High Availability (HA) módů 5x12, což znamená, že musí být podporována každý pracovní den od 07:00 do 19:00. Z pohledu zákazníků je kladen největší důraz na dostupnost služby od 09:00 do 15:00, kdy je statisticky zpracováváno nejvíc transakcí. Podporu poskytuje centrální SD, specializovaný útvar a podpora databáze a serverů. Každý rok jsou do produkčního prostředí nasazovány průměrně 3 nové verze, které obsahují opravy produkčních chyb, změny v rámci drobného vývoje, změny vyžádané legislativně, performance vylepšení, změny vyvolané změnou infrastruktury a změny vyvolané závislými systémy. Z pohledu ITIL se jedná o Service Transition nových nebo pozměněných služeb. Řádově se jedná o stovky změn do každé verze, většina z nich má přitom povahu oprav stávajících služeb. Plánované termíny nasazení jednotlivých verzí jsou vždy konsensem mezi IT podporou a businessem. Při plánování verzí je nutné brát v potaz období, která jsou pro banku kritická z pohledu zvýšených požadavků na dostupnost služeb. Konkrétně se jedná o konec kalendářního měsíce, střed kalendářního měsíce a přelom roku. V těchto termínech jsou přes bankovní systémy zpracovávány největší objemy transakcí a dat. Z důvodu zajištění podpory 5x12 jsou také všechny významné i malé změny nasazovány až po 19 hodině. V rámci vývoje každé nové verze aplikace probíhá komplexní implementační cyklus, který sestává z následujících kroků: 1

Seznam požadavků. Analýza a odhad pracnosti požadavků. Prioritizace požadavků ze strany business.

Kvůli citlivým údajům neuvádím v práci název bankovní instituce.

19

20


-

-

-

Vývoj a testování. Buildengine – kompilace a deployment jednotlivých modulů a kompletace verze do balíčku. System Integration Test (SIT), testování změn a jejich případných dopadů do dalších částí aplikace, součástí jsou také křížové testy, kdy jsou změny testovány duplicitně. Automatické testy - jsou pravidelně prováděny pomocí testovacího nástroje. Testuje se soubor funkčností, které jsou z pohledu poskytovaných služeb kritické. Business test – testování změn ze strany businessu, kontrola z pohledu metodiky, kontrola, zda změny skutečně odpovídají zadání. Jedná se o první kontakt zákazníka, kterého reprezentuje vybraná skupina specialistů, s novou verzí aplikace. Výsledkem testů jsou akceptované změny/opravy nebo další požadavky na úpravy stávajících změn. Všechny požadavky jsou evidovány v systému pro správu požadavků. Performance testy – cílem je kontrola, zda nová verze nemá horší performance než verze předchozí. Tím se eliminuje případný performance dopad v produkčním prostředí. Schválení RFC v procesu Change Management. Migrace pilot – nasazení nové verze do pilotního provozu. Tzn. její instalace pro předem určené útvary tak, aby byla podchycena co největší oblast funkcionalit na co největším počtu uživatelů a zároveň aby migrace měla minimální dopad na ostatní produkční uživatele. Zvýšená podpora po migraci, řešení případných incidentů. Schválení RFC v procesu Change Management. Migrace produkce – plošné nasazení nové verze do celé pobočkové sítě. Zvýšená podpora po migraci, řešení případných incidentů. Monitoring aplikace.

3.2 Model migrace nové verze aplikace Na modelu migrace nové verze aplikace do produkce se budu snažit ukázat, jak mohou pravidla Change Managementu prospět stabilitě a kvalitě zaváděné služby v oblasti bankovnictví. Výše uvedený cyklus probíhá v rámci každé nové verze aplikace. Některé jeho fáze se přitom mohou několikrát opakovat. Zevrubněji se v mé práci budu věnovat pouze procesům, které probíhají po BU akceptaci verze, tzn. po úspěšném otestování a schválení všech nových požadavků/oprav ze strany businessu. Tato část cyklu mi totiž připadá z pohledu ITSM pro sledování nejvhodnější. V definici ITIL se jedná o Service Transition, konkrétně o RDM a Change Management. Dále budu popisovat jednotlivé kroky z procesu nutného pro nasazení nové verze/služby do produkčního prostředí. 3.2.1 Business testy Nutnou podmínkou akceptovatelnosti nové nebo změněné služby je pro business nula kritických chyb. Poslední předávka balíčku pro BU testy musí proběhnout minimálně měsíc před plánovanou migrací do pilotního provozu. Business na základě testů poskytne předběžný souhlas s migrací, což je z pohledu ITSM dostatečný signál pro další kroky v procesu plánování migrace do produkce. Finální souhlas s migrací poskytuje BU až těsně před samotnou migrací v rámci pravidelných schůzek IT a BU. 3.2.2 Performance testy Dopad nové/změněné služby na výkon a stabilitu systému je nutné obhájit na CAB. Testují se kritické funkčnosti aplikace, porovnává se rychlost účtování běžných transakcí, měří se doba zpracování pravidelných nočních reportů. Pro performance testy bývá zpravidla dedikováno speciální prostředí, které neovlivňují okolní systémy, a výsledky testů jsou tak nezkreslené. V případě, že dojde ke zhoršení rychlosti poskytované služby, je nutné toto analyzovat, provést nápravu a zajistit performance test znovu. Na CAB se pak předkládá, že u služby, která je systémem poskytována, nebyla zhoršena performance. V opačném případě je daný RFC těžko schvalitelný pro nasazení do produkčního prostředí.


3.2.3 Souběhové testy Cílem těchto testů je prověřit, že nová/změněná služba nasazená do pilotního provozu nebude mít dopad na produkční uživatele. Potenciální rizika jsou identifikována v rámci pravidelných schůzek IT podpory aplikace. Tato rizika jsou poté testována podle speciálních pravidel. Musí být ověřeno, že nová funkčnost se v pilotním provozu bude chovat podle zadání a zároveň bude bez dopadu do produkce. Testy probíhají na prostředí, které se z pohledu infrastruktury, služeb a dat co nejvíce podobá tomu produkčnímu. Dostupnost a podporu tohoto prostředí zajišťuje Konfigurační manažer. Kladný výsledek všech souběhových testů je nutnou podmínkou pro další pokračování v procesu migrace. 3.2.4 Integrační testy Testy prověřují, zda nová/změněná služba nemá nečekaný dopad na externí aplikace. Vzhledem k tomu, že aplikace je v produkci integrována s dalšími cca 10 aplikacemi na různé úrovni provázanosti, je nutné každou aplikaci projít zvlášť. Některé dopady lze vyvrátit pouhou analýzou, u některých je nutný integrační test. Souhlas všech externích aplikací s nasazením nové služby je nutnou podmínkou pro migraci nové verze do produkce. 3.2.5 Analýza dopadů na pravidelné zpracování Během migrace nesmí dojít k neočekávanému omezení nebo výpadku pravidelného zpracování (reporting, hromadné zpracování dat, účtování transakcí, počítání databázových statistik). Proto klade Change Management v bankovní instituci velký důraz na zevrubnou analýzu možných dopadů migrace. Z pohledu analýzy možných dopadů je nutné znát časové intervaly, ve kterých pravidelné automatické procesy probíhají. Podle nich je pak možné sestavit harmonogram samotné migrace. 3.2.6 Příprava migračních balíčků Cílem je připravit a v určených termínech odevzdat instalační balíčky a potřebnou dokumentaci do procesu Change Management. Forma a struktura předávek, včetně požadovaných termínů odevzdání, je předem dána ze strany Change Management. Balíčky je možné rozdělit do 3 skupin: -

-

-

Front-End – klientská část aplikace, která je instalována na uživatelské stanice, terminálové servery, terminálové farmy, atd. Jedná se zpravidla o stanice se systémem Windows. Testování těchto balíčků zajišťuje speciální odbor – Testlab, který ověřuje, zda lze aplikaci nainstalovat podle připravené dokumentace v požadovaném čase na požadované lokality. Testuje také vlastní spuštění aplikace a jednoduchý test základních funkčností. Případné nejasnosti pak komunikuje na zadavatele. Po otestování a akceptování předá balíček dál do procesu řízení změn. Testovací prostředí Testlabu z hlediska infrastruktury plně odpovídá tomu produkčnímu. Server-Side – serverová část aplikace, která je instalována na aplikační servery. Pro její testování není stanoven žádný speciální odbor. Test instalace a spustitelnosti serverové části aplikace probíhá pouze v rámci souběhových testů. Součástí je dokumentace, která přesně popisuje, jak budou jednotlivé moduly instalovány na produkční aplikační servery a případné prerekvizity. Databáze – migrační SQL skripty, platforma Oracle. Balíček je souborem DDL a DML operací, které jsou připraveny podle předem daných požadavků – komentáře, struktura skriptů, struktura balíčku atd. Instalační balíček je předán na databázovou podporu, která zajistí jeho otestování na klonu produkční databáze, tzn. na databázi, která je obrazem databáze produkční jak z pohledu dat, tak z pohledu datového modelu. Výsledek testu je poslán zpět na zadavatele, statistiky z testu jsou předány na člena CAB zodpovědného za schválení změny z pohledu produkční databáze. Klon produkční databáze je nutné dostatečně dopředu alokovat, aby nedošlo ke kolizi dvou a více aplikací. Naopak, pokud je nutné, je klon ideálním prostředím pro centrálně řízené integrační testy více aplikací. Klon obsahuje degradovaná data

21

22


tak, aby citlivé údaje nebyly k dispozici neautorizovaným uživatelům. Souhlas s migrací DB člena CAB je nutnou podmínkou pro migraci nové služby do produkce. 3.2.7 Plán migrace Plán migrace musí být připraven v požadované kvalitě a detailu, ideálně podle předem připravené šablony. Zahrnuje účastníky migrace, role zainteresované na migraci, datum migrace, datum pro splnění přípravných kroků, definuje zodpovědnosti v procesu migrace. Dále obsahuje kontakty na účastníky migrace, eskalační skupinu a komunikační plán. Definuje řízení migrace za IT a BU, technické požadavky pro provedení migrace a architekturu systému. V plánu migrace musí být také rozepsány přípravné kroky migrace (přípravy instalačních balíčků, testy, komunikace na koncové uživatele, alokace zdrojů). Hlavní částí je detailní popis migrace v jednotlivých krocích. Každý krok přitom musí obsahovat začátek, konec, osobu odpovědnou za provedení, komunikaci před provedením kroku a komunikaci po provedení, předpoklad pro provedení daného kroku. Nejmenší časovou jednotkou činnosti je přitom 5 min. Součástí musí být také rollback scénář, který popisuje, jak se vrátit do výchozího stavu před migrací, a dopad migrace na externí systémy. 3.2.8 Pilotní provoz Pilotním provozem se snižuje negativní dopad nově implementované změny. Podstatou pilotního provozu je určení útvarů (skupin uživatelů), které budou mít novou/změněnou službu k dispozici s předstihem. Vybrané útvary pak pracují s novou verzí v reálném provozu a typují reálné transakce. Mají tak v případě kritického incidentu v pilotním provozu možnost ihned využít služeb poskytovaných produkční (původní) verzí aplikace. Nasazením nové verze do pilotního prostředí tedy zajistíme otestování nové/změněné služby v reálném provozu, aniž bychom významně ohrozili dostupnost a kvalitu služby v produkčním prostředí. To je hlavní výhoda pilotního provozu. Po dostatečném otestování v pilotním provozu je nová verze zpřístupněna všem útvarům. Dostatečným otestováním přitom rozumím minimálně měsíc provozu na třetině útvarů tak, aby byly pokryté všechny základní služby, které aplikace poskytuje. Pilotní provoz je velmi nákladnou částí procesu, vyžaduje zvýšené nároky na HW a zdroje podpory pilotu. Výsledný pozitivní dopad na kvalitu a dostupnost služeb v produkčním prostředí kompenzuje vysoké náklady na pilotní provoz a pro bankovní instituci tak tento přístup přináší velkou přidanou hodnotu. 3.2.9 Informace BU a SLM V předem daných termínech je nutné informovat o plánované migraci BU a SLM. SLM poté zajistí předání informace na jednotlivé pobočky a komunikuje případnou nedostupnost nebo pouhé riziko nedostupnosti poskytované služby. BU připraví pro cílené útvary zprávu, ve které je informuje o termínu nasazení a případných rizicích. Zpráva také obsahuje popis nejvýznamnějších změn služeb, případně nových služeb. Zpráva je odeslána na vedoucí útvarů den před plánovou migrací. Některé speciální služby je možné předem školit ve Školícím prostředí. Souhlas BU s migrací a souhlas SLM jsou nutné podmínky pro schválení migrace do produkce. 3.2.10 RFC nástroj Nástroj pro správu změn pomáhá řídit nasazení nových služeb a úpravu stávajících. Jedná se o komplexní nástroj, který umožňuje přehlednou správu všech produkčních změn. Požadavky do něj vyplňuje Zadavatel (Plánována), následně jsou schváleny Autoritou (Přiřazena IT ChA) a předány na Koordinátory změny (Přiřazena IT ChC). Ti naplánují projednání RFC na IT CAB Committee, kontrolu RFC po formální stránce a předání požadavku ke schválení členům CAB (Čekání na schválení). CAB prochází požadavek podle Checklistu, případné nejasnosti se poté řeší na pravidelném IT CAB Committee. Požadavek se kontroluje z pohledu termínu migrace, podpory systému během migrace, možného dopadu na business. Nutnou součástí každého RFC je plán migrace, který přesně popisuje její jednotlivé kroky. Součástí je rollback scénář a komunikační plán. Zvlášť je také kontrolován dopad


na centrální databázi. Po schválení RFC členy IT CAB je požadavek převeden do stavu (Schválena k nasazení) a je na zodpovědnosti koordinátorů propagovat jednotlivé pracovní příkazy a instalační balíčky na předem určené technické skupiny. Změnu přebírá IT Promotion Coordinator, který je zodpovědný za implementaci RFC a převedení do stavu (Nasazena), a po vyhodnocení PIR je RFC (Uzavřena). Přehled jednotlivých stavů RFC v rámci schvalovacího procesu je na obr. 8. Součástí požadavků jsou pracovní příkazy, které definují, kdo bude danou část požadavku nasazovat, kdy bude nasazena, na které lokality bude nasazena, kde je k dispozici příslušný migrační balíček. Dashboard produkčních změn zobrazuje přehled plánovaných změn na vybrané období. Má podobu Gantt diagramu, na kterém jsou Změny zobrazeny v podobě obdélníků, ty reprezentují dobu trvání dané Změny. Uvedená data jsou data plánovaného počátku a plánovaného termínu dokončení změny. Historie všech změn je evidována.

Plánována

Přířazena IT ChA

Řeší IT ChA

Přiřazena IT ChC

Čekání na schválení

Schválena k nasazení

Nasazena

Uzavřena

Obr. 8 RFC základní průběh

V procesu schvalování změny figurují tyto role: Zadavatel je jakýkoli pracovník IT, který smí zaregistrovat novou Změnu. Při prvotním zakládání požadavku je Stav nastaven na hodnotu Plánována. Pokud je již požadavek připraven a je možno implementovat změnu, je nutné doplnit ve formuláři konkrétního požadavku příslušnou IT Change Authority, která je za provedení RFC odpovědná. IT Change Authority je role odpovědná za záznam o Změně a za formální správnost požadavku na Změnu. Představuje omezenou množinu zaměstnanců. Většinou IT ChA reprezentuje IT Project Leader (v případě projektů) nebo liniový vedoucí. IT Change Coordinator plánuje nasazení Změny a sleduje kolize, posílá požadavky na Změnu ke schválení IT CAB (navrhuje projednání na schůzi IT CAB a přiděluje Změny k projednání), sleduje splnění připomínek v případě schválení Změny IT CAB s připomínkami. IT Change Coordinator má plný přístup ke všem záznamům Změn během celého jejich životního cyklu od plánování do uzavření. IT Change Coordinator vstupuje do aktivní správy požadavku na Změnu po převzetí záznamu od IT ChA. V této chvíli je notifikován e-mailovou zprávou o přiřazení požadavku na skupinu IT Change Coordinatoru a jeho úkolem je ověřit všechny náležitosti požadavku na Změnu a požadavek přijmout. V případě nedostatku informací může IT Change Coordinator Změnu vrátit IT ChA nastavením stavu požadavku na: Přiřazena ITChA. V tomto případě bude IT ChA notifikována e-mailem o přiřazení požadavku a bude vyzvána k nápravě nesrovnalostí. Změny kategorie Significant a Critical vyžadují schválení nasazení IT CAB, ostatní Změny schvaluje IT Change Coordinator samostatně. Ve stádiu projednávání Změny na IT CAB, je stav Změny veden jako Čekání na schválení. Zadáním Data IT CAB se identifikuje datum IT CAB Committee, na kterém bude daná Změna projednána. Avšak IT Change Coordinator může kdykoli zasáhnout do hlasovacího procesu a doplnit poznámky k vyjádření, případně i změnit verdikt jednotlivých schvalovatelů v průběhu jednání IT CAB.

23

24


IT CAB člen schvaluje požadavky kategorie Significant a Critical, účastní se jednání IT CAB, které se schází pravidelně dvakrát týdně. Členové IT CAB jsou předem informováni o agendě nadcházejícího jednání. Jejich úkolem je seznámit se s aktuálními Změnami a jejich časovým rozložením. Proces schvalování je časově omezen s ohledem na schůzku IT CAB. Proces hlasování by měl být ukončen ještě před skutečným setkáním IT CAB, proto je u každé Změny v procesu schvalování nastaven Nejzazší termín schválení, do něhož by se vyjádření všech schvalovatelů měla zaregistrovat. IT Promotion Coordinator je osoba zastřešující instalaci a samotné nasazení Změny. Provádí koordinaci jednotlivých Pracovních příkazů a následně převádí záznam o Změně do stavu Nasazena. Nositelem této role může být jak interní osoba, tak i externista. IT Promotion Coordinator vstupuje do správy záznamu požadavku na Změnu ve chvíli, kdy Změna je již Schválena k nasazení a všechny náležitosti Změny, včetně příslušných Pracovních příkazů, jsou řádně splněny. V okamžiku připravenosti RFC k nasazení je IT Promotion Coordinator včas notifikován e-mailovou zprávou, v níž dostane i odkaz na příslušný záznam, vyžadující jeho akci. Úkolem IT Promotion Coordinatora je sledovat plnění Pracovních příkazů přiřazených ke Změně a nutných k celkovému řešení Změny. Sleduje plnění termínů a evidenci záznamů jednotlivých kroků v nástroji. V okamžiku uzavření všech příslušných Pracovních příkazů ke Změně, je povinností IT Promotion Coordinatora doplnit do záznamu RFC následující informace: Skutečný začátek a Skutečný konec. Po dokončení Změny převede její stav na hodnotu Nasazena. IT PIR Evaluator vstupuje do správy RFC ve chvíli, kdy je Změna již Nasazena a připravena k závěrečnému hodnocení. Je to osoba označena na IT CAB jako IT PIR Evaluator. Ten je odpovědný za hodnocení průběhu nasazení příslušné Změny a zajištění podkladů od všech zúčastněných osob řešitelů pro výsledné hodnocení PIR. Při hodnocení může využít číselníky v tabulkách 5 a 6, podle kterých stanoví výsledný kód uzavření změny. PIR hodnocení je číselník hodnocení průběhu nasazení Změny s hodnotami 1 až 3 dle následující tabulky: 1 Příprava i implementace Změny proběhla hladce a zcela v souladu s procesem. V průběhu se nevyskytly žádné potíže. V rámci doby post-implementační podpory byly splněny dohodnuté podmínky. 2 V průběhu přípravy či implementace Změny došlo k drobným odchylkám od procesu či od plánu. Výsledná dodávka však nebyla významně ohrožena. Podmínky doby post-implementační podpory byly splněny pouze částečně. 3 Změna byla řízena chaoticky, chyběla komunikace, nebylo dosaženo požadovaných efektů implementace Změny. V rámci doby post-implementační podpory nebyly splněny dohodnuté podmínky. Změna byla projednána a řádně schválena k nasazení. Tab. 5 Post Implementation Review

Kód uzavření se vyplňuje při uzavření požadavku a vypovídá o způsobu ukončení požadavku. Nabývá hodnot: Storno Implementována Odmítnuta Rollback

Změna byla stornována před vyřešením. Změna byla implementována. Implementace změny byla odmítnuta. Byl spuštěn rollback změny. Tab. 6 Výsledky implementace RFC


V následující tabulce jsou uvedené aktivity, v rámci kterých může být Změna požadována. Maintenance - plánovaná Maintenance - neplánovaná Operation - plánovaná Operation - neplánovaná Projekt - plánovaná změna (nové funkčnosti) Projekt - plánovaná změna (oprava) Projekt - neplánovaná změna SE - plánovaná změna (nové funkčnosti) SE - plánovaná změna (oprava) SE - neplánovaná změna

Plánovaná Změna v rámci údržby služby. Neplánovaná Změna v rámci údržby služby. Řešení incidentů, problémů, (poruchy, nedostupnost …). Plánovaná Změna v rámci operation. Neplánovaná Změna v rámci operation. Řešení incidentů, problémů, (poruchy, nedostupnost …). Plánovaná Změna v rámcích projektu se zavedením nových funkčností. Plánovaná Změna v rámcích projektu vyvolaná nutností opravy stávajících systémů/aplikací. Neplánovaná Změna v rámcích projektu. Řešení incidentů, problémů, (poruchy, nedostupnost …). Plánovaná Změna v rámci drobného vývoje, související se zavedením nových funkčností. Plánovaná Změna v rámci drobného vývoje vyvolaná nutností opravy stávajících systémů/aplikací. Neplánovaná Změna v rámci drobného vývoje. Řešení incidentů, problémů, (poruchy, nedostupnost …). Tab. 7 Typy aktivit generujících RFC

RFC nástroj umožňuje procesování následujících typů Změn: Standard Minor Significant Critical

Změny, u kterých existuje definovaný a vyzkoušený postup řešení. Jedná se o rutinní Změnu (např. update antivirů, založení nové konfigurační položky). Změny nad jednou aplikací/systémem, která není business kritická. Tato aplikace nemá vazbu na žádné jiné aplikace a tyto Změny nejsou v katalogu standardních Změn. Změny nad business kritickými aplikacemi/systémy nebo nad aplikacemi, které mají vazbu na jiné aplikace, tyto Změny nejsou v katalogu standardních Změn. Změny, které reagují na výjimečný stav (řešení incidentů nebo problémů), schvaluje IT CAB/CC, mají vlastní, zrychlené workflow. Tab. 8 Typy RFC podle významnosti

Pro každou Změnu sleduje RFC nástroj tyto atributy: 1. 2. 3. 4. 5. 6. 7.

Dopad na dostupnost – sleduje se dostupnost poskytované služby během instalace změny. Závislosti/Vazby na jiné projekty, změny, události. Plánovaný začátek instalace změny, datum a čas hh:mm. Plánovaný termín dokončení instalace změny, datum a čas hh:mm. Nová funkčnost k dispozici, datum a čas hh:mm. Oblast instalace, produkce, pilot, testovací nebo školící prostředí. Podpora během instalace, kontakty.

Pro každou Změnu typu Significat/Critical vyžaduje RFC nástroj i vyplnění Checklistu, který je definovaný ze strany IT CAB. 1. 2. 3. 4. 5. 6.

Existuje Plán migrace? Byl business informován dle platných pravidel? Kdo konkrétně? Souhlasí aplikační gestor s nasazením? Byly podpůrné skupiny informovány a jsou připraveny k instalaci? Je zajištěn pomigrační dohled a podpora? Kdo konkrétně a kdy? Byly analyzovány a případně ošetřeny dopady do dalších systémů nebo aplikací?

25

26


7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

Má změna dopad na centrální databázi? Má změna vliv na dceřinné společnosti? Byly analyzovány a ošetřeny dopady do pravidelného zpracování? Existuje rollback scénář? Byla mitigovaná rizika spojená s nasazením změny? Byla vytvořena a předána provozní dokumentace? Byly odstraněny chyby v aplikaci nebo systému? Kde byla změna testována? Bylo otestováno nasazení instalačních procedur? Bylo řádně otestováno a výsledky testu byly akceptovány? Byly provedené performance testy aplikace nebo systému s ohledem na novou změnu?

3.2.11 IT CAB Committee Pravidelné jednání, na kterém IT CAB uděluje GO/NOGO pro RFC typu Significant a Critical. Nasazení změny musí být připraveno po formální stránce, nutný rollback scénář. Sleduje se riziko kolize migrace s ostatními aplikacemi. Výsledkem je GO/NOGO/GO s podmínkou. Odpovědnost je na roli Change Manager, jestliže nemůže danou změnu rozhodnout, je předána na vedení IT. Jednání se zpravidla účastní Change Manager, Change Coordinator, Change Authority, Zadavatel, SLM, Infrastruktura, Podpora databáze, Service Operation a Business. Po schválení změny jsou její pracovní příkazy distribuovány na odpovědné pracovníky. Z jednání Change Committee vznikne také zápis, který obsahuje všechny projednané změny a výsledky jejich schválení. Změna je poté ve stavu Schválena k nasazení až do dne migrace, pracovní příkazy jsou Přiřazené. 3.2.12 Koordinace migrace Klíčovou rolí v implementační části procesu je Koordinátor migrace, který odpovídá za provedení všech kroků podle schváleného plánu v požadovaném čase. Rozhoduje podle předjednaných prerekvizit o případném vrácení změny. Do koordinace migrace spadá také komunikační plán. Ten definuje, v které části migrace bude mezi účastníky komunikace probíhat. 3.2.13 Podpora po migraci Podporou po migraci rozumím zvýšenou podporu služby den po implementaci změny do produkce. Tento den je z pohledu dopadu změny na kvalitu a dostupnost služby kritický. Je proto nutné alokovat zdroje ze všech úrovní podpory tak, aby případné incidenty byly řešeny co nejrychleji a nejefektivněji. Musí být zajištěna plná informovanost všech účastníků pomigrační podpory a incidenty musí být co nejrychleji komunikovány na BU, uživatele a zákazníka. 3.2.14 Monitoring Snahou je dostatečně monitorovat všechny části systému. Monitoring umožňuje dostatečně rychle reagovat na incidenty, v ideálním případě incidentům předcházet. Musí být jasně definovány vstupy a výstupy monitorovacího nástroje, tedy jak má reagovat na konkrétní události v konkrétních částech systému. Z pohledu rozsáhlé bankovní aplikace je vhodné monitorovat následující události v subsystémech a procesech: -

Aplikační servery (zatížení) Databáze (zatížení) Služba (dostupnost) Účetní systém (dostupnost) Externí systémy (dostupnost) Reporting (kompletnost) Pravidelné zpracování (kompletnost)


-

Systémové chyby (výskyt) Aplikační chyby (výskyt)

V případě výskytu události je nutné notifikovat aplikační podporu, která událost vyhodnotí a následně komunikuje na technickou podporu nebo SD. Je nutné dopředu vyspecifikovat kritičnost jednotlivých událostí na kvalitu a dostupnost služby a podle jejich významnosti k nim pak přistupovat. 3.2.15 Vyhodnocení migrace V rámci vyhodnocení migrace se prochází jednotlivé incidenty, které nastaly po zavedení změny do produkčního prostředí. Je vhodné seřadit je podle jejich kritičnosti a poznamenat do je KEDB. V případě incidentů, které byly způsobené chybou v procesu, je nezbytné bezodkladně upravit proces tak, aby nedošlo k jejich opakování. Vyhodnocení migrace zpravidla probíhá formou schůzek, bývají plánovány týden po migraci a účastní se jich aplikační a technická podpora. Cílem schůzek je optimalizovat proces migrace a minimalizovat počet opakujících se incidentů.

3.3 Analýza modelu Protože proces implementace stále probíhá, budu analyzovat v procesu jen ty části, které byly v průběhu dvou let implementovány. Tyto dílčí procesy jsem podrobně rozepsal v kapitole 3.2 a nyní budu analyzovat jejich konkrétní vliv na kvalitu a stabilitu služby. V analýze jsem se snažil zachytit také rizika, která vyplývají z případného vynechání procesu. Soubor těchto procesů dohromady tvoří model implementace standardu Change Management v rámci bankovní instituce. Jedná se tedy o konkrétní implementaci standardu ITIL, kterou je možné dále rozvíjet a sledovat. V následující tabulce jsou uvedeny dílčí procesy Change Management a jejich pozitivní dopady na kvalitu a stabilitu IT služeb. Zároveň zde analyzuji rizika, se kterými je nutné počítat, dokud daný proces nebude implementován. Analýza jednotlivých procesů je založená na zkušenostech z reálného provozu bankovní aplikace. Proces Business testy

Performance testy

Souběhové testy

Integrační testy

Analýza dopadů pravidelné zpracování

Pozitivní dopad Business pohled, často hlubší znalost problematiky, zkušenosti z praxe na pobočkách. Odhalení rizika s dostatečným předstihem před nasazením do produkce. Implementace nové služby do pilotního provozu nemá dopad na stávající služby v produkčním provozu. Nová služba v pilotním provozu splňuje požadavky BU a zákazníka. Odhalení rizika s dostatečným předstihem před nasazením do produkce. Notifikace útvarů zajišťujících podporu o plánované migraci s možným dopadem. Zvýšená podpora po migraci.

Rizika Vysoký počet požadavků na změnu nebo opravu po nasazení do produkce. Celková nebo částečná nedostupnost služby. Dopad na externí aplikace. Dopad na kvalitu a dostupnost původních služeb.

na Hladký průběh samotné migrace. Snížení rizika přerušení pravidelného zpracování, např. generování nočních reportů, nahrávání dat.

Chybně nebo vůbec neprovedené pravidelné zpracování. Dopad na externí systémy a kvalitu poskytované služby.

Celková nebo částečná nedostupnost služby poskytované externí aplikací.

27

28


Příprava balíčků

migračních Standard formátu, ve kterém jsou předávány nové/změněné služby na technickou podporu, ta je instaluje podle jasně popsaného návodu. Plán migrace Migrace a rollback scénář popsány podle standardu. Nedochází k nejasnostem, jsou jasně dány jednotlivé kroky migrace. Pilotní provoz Testování nové/změněné služby omezeným počtem uživatelů v produkčním provozu. Včasné odhalení chyb. Pilotní uživatelé mají k dispozici také původní verzi služby, ke které se mohou snadno vrátit v případě nedostupnosti pilotní služby. Informace BU a SLM Připravenost a podpora před, v průběhu a po migraci. Kladný dopad na rychlost řešení incidentů. RFC nástroj Evidence požadavků na změny. Plánování změn podle standardu.

IT CAB Committee

Koordinace migrace

Podpora po migraci

Monitoring

Vyhodnocení migrace

Identifikace případných kolizí s dalšími RFC. Identifikace kolizí v požadavcích na zdroje. Prověření splnění všech požadovaných činností podle kontrolního seznamu. Reportování změny na management. Realizace migrace podle plánu v požadovaném čase, kontrola základních funkčností. Řešení případných incidentů během migrace, rozhodnutí o rollback scénáři. Rychlá reakce na případné incidenty. Komunikační plán: uživatelé, SD, aplikační podpora, technická podpora. Zkrácení případné nedostupnosti služby. Odhalení incidentu ještě před nahlášením ze strany uživatelů. Proaktivní řešení incidentů.

Chybná instalace nové/změněné služby. Chybné zpřístupnění služby.

Neprovedená nebo chybně provedená migrace. Dopad na kvalitu a dostupnost služby.

Dopad chyby způsobené novou/změněnou službou na všechny uživatele. Riziko celkové nedostupnosti služby.

Zákazníci nepočítají s migrací. Kolize termínu. Business nezajistí podporu. Nelze dohledat, která změna má dopad na kvalitu služby. Mohou nastat kolize termínů migrací. Kolize změny služby s jinou změnou služby. Dopad na dostupnost služby. Nemožnost implementace RFC z důvodu nealokovaných zdrojů.

Jednotlivé kroky migrace provedené ve špatném pořadí. Nedostupnost služby po migraci.

Celková doba incidentu, částečná/celková nedostupnost služby. Zhoršení vnímání kvality služby ze strany zákazníka. Reaktivní řešení incidentů. Zhoršení vnímání kvality služby ze strany zákazníka.

Evidence chyb v migračním Opakující se chyby v procesu. procesu. Ponaučení se. Tab. 9 Analýza modelu Change Management

Ověření a vyhodnocení implementace

4 Ověření a vyhodnocení implementace Definice metriky – budou sledovány počty kritických chyb, které jsou nahlášeny z produkčního prostředí bezprostředně po nasazení nové verze aplikace. Dalším ukazatelem může být počet oprav služby realizovaných po jejím nasazení do produkce, jinými slovy - kolik opravných balíčků je nutno nasadit v rámci stabilizace nové verze v produkci.

4.1 Metriky ITIL Nejprve popíši, jaké metriky doporučuje ITIL pro vyhodnocení úspěšnosti implementovaných procesů. ITIL doporučuje následující KPI pro Change Management: -

Množství změn služeb, které dosáhly zákazníkem požadovaných cílů vyjádřený jako podíl všech změn. Přínosy změn vyjádřené jako hodnota provedených zlepšení a odvrácený negativní dopad porovnaný s náklady procesu změn. Počet incidentů souvisejících s nasazení změny. Redukce počtu výpadků služby. Redukce počtu kritických a neplánovaných změn. Redukce počtu havarovaných změn, tj. změn, které musely být vráceny. Průměrný čas na implementaci změny. Redukce počtu neautorizovaných změn. Poměr úspěšně procesovaných změn. Redukce počtu oprav po nasazení změny.

Pro hodnocení úspěšnosti implementace Změny je možné použít následující měřítka: -

Počet přerušení, incidentů, problémů/chyb způsobených neúspěšným nasazením změn nebo verzí. Nepřesná specifikace změn z technického, zákaznického nebo business pohledu. Neúplné posouzení možných dopadů. Neoprávněná změna. O kolik procent byly sníženy náklady na změnu/verzi (čas, úsilí, cena). Snížení procenta neautorizovaných změn. Frekvence změn podle služeb, business oblastí atd. Celkový objem změn, podle služeb, business oblastí atd. Poměr plánovaných a neplánovaných (kritických) změn. Poměr schválených a zamítnutých RFC. Čas potřebný na procesování změny od počáteční myšlenky až po nasazení do produkčního prostředí.

29

30


4.2 Počet oprav na změnu První metrikou, kterou jsem vybral pro sledování úspěšnosti implementace standardu řízení IT služeb v bankovnictví, je počet oprav nutných ke stabilizaci služby po nasazení změny. Jedná se o metriku, která sleduje kvalitu poskytované IT služby. Metodika Change Management a související procesy začaly být implementovány v průběhu roku 2008. Proto jsem se rozhodnul sledovat kvalitu služby od začátku roku 2008 do současnosti. Během sledovaného období bylo do produkčního prostředí migrováno celkem 6 hlavních verzí a 14 stabilizačních opravných balíčků. Každá hlavní verze je po migraci do produkce stabilizována opravnými balíčky. Balíčky v sobě zahrnují opravy business kritických chyb a cílem je ukázat, že počet jednotlivých oprav klesá. Předpokladem metriky je, že hlavní verze jsou stejně velké, tj. obsahují v průměru 300 oprav a 40 změn služby. V následující tabulce je uveden seznam změn a jejich atributů, hlavní verze jsou přitom označeny modře. Typ určuje, jestli se jedná o hlavní verzi služby nebo o stabilizační balíček, Datum odpovídá migraci změny do produkčního prostředí, ID jednoznačně identifikuje verzi služby. Posledním atributem je počet oprav business kritických chyb, obsažených ve stabilizačním balíčku. V případě hlavní verze se jedná o součet oprav všech balíčků, které byly nutné pro stabilizaci. Tendence snižování počtu oprav v produkčním prostředí je zachycena na dvou grafech uvedených níže. Typ Verze Patch Patch Patch Patch Verze Patch Patch Verze Patch Patch Verze Patch Patch Verze Patch Patch Patch Verze Patch

Datum 27. 3. 2008 27. 3. 2008 1. 4. 2008 24. 4. 2008 5. 6. 2008 21. 8. 2008 25. 8. 2008 30. 9. 2008 4. 12. 2008 8. 12. 2008 22. 1. 2009 16. 4. 2009 27. 4. 2009 17. 6. 2009 20. 10. 2009 29. 10. 2009 25. 11. 2009 8. 12. 2009 8. 4. 2010 26. 4. 2010

ID 200801 200801_01 200801_02 200801_03 200801_04 200802 200802_01 200802_02 200803 200803_01 200803_02 200901 200901_01 200901_02 200902 200902_01 200902_02 200902_03 201001 201001_01

Počet oprav 38 19 4 10 5 35 21 14 23 15 8 8 4 4 7 1 1 5 3 3

Tab. 10 Počty oprav na změnu

Na grafu 1 je zachycena klesající tendence počtu oprav, které bylo nutné nasadit do produkčního prostředí pro stabilizaci služby po nasazení hlavní verze. Je zde vidět, jak zahájení implementace standardu Change Management v průběhu roku 2008 pozitivně ovlivňuje kvalitu poskytované služby. Od verze 200901 ke stabilizaci služby stačí maximálně 10 oprav, v případě verze 200801 to přitom bylo 38 oprav, a v případě 200802 35 oprav. Postupná implementace a dodržování standardu pro

Ověření a vyhodnocení implementace

řízení IT služeb nám tedy během dvou let zajistily snížení počtu oprav na 30% původních hodnot. Došlo tak k trojnásobnému zlepšení kvality poskytované služby a zároveň se zlepšilo vnímání služby ze strany BU, uživatelů a zákazníka. Na grafu 2 je vidět, kolik stabilizačních balíčků bylo nutno procesovat po migraci nové verze do produkce. Např. ke stabilizaci verze 200801 bylo nutné nasadit do produkce 4 stabilizační balíčky, které celkem opravovaly 38 business kritických chyb. V případě poslední migrované verze 201001 už stačil pouze 1 balíček, který zahrnoval opravu 3 BU kritických chyb.

Počet oprav nutných pro stabilizaci služby 40 35 30 25 20 15 10 5 0 200801

200802

200803

200901

200902

201001

Počet oprav Graf 1

Počet oprav na změnu 40

38 35

35 30

4

5

8

8

5

7 4

5

4 1

1

3

3 201001_01

10

10

201001

15

14

15

200902_02

19

20

23

21

200902_01

25

Graf 2

200902_03

200902

200901_02

200901_01

200901

200803_02

200803_01

200803

200802_02

200802_01

200802

200801_04

200801_03

200801_02

200801_01

200801

0

31

32


4.3 Počet incidentů na změnu Touto metrikou sleduji efekt postupné implementace standardu Change Management na stabilitu a dostupnost IT služeb. Chci tak ukázat, že v souvislosti s implementací dochází ke snižování objemu incidentů na klíčových IT službách. Data pro metriku jsou čerpána za stejné období jako v případě první metriky. V tabulce 11 je uveden přehled změn, datum jejich migrace do produkce a počty incidentů detekovaných bezprostředně po jejich nasazení. Každý incident přitom má dopad na dostupnost služby a podle počtu incidentů zákazník službu hodnotí. Typ Verze Verze Verze Verze Verze Verze

Datum 27. 3. 2008 21. 8. 2008 4. 12. 2008 16. 4. 2009 20. 10. 2009 8. 4. 2010

ID 200801 200802 200803 200901 200902 201001

Počet incidentů 10 13 3 4 3 1

Tab. 11 Počty incidentů na změnu

Na grafu 3 je vidět klesající tendence počtu incidentů po zavedení nové/změněné služby do produkčního prostředí. Je zřejmé, že stabilita služby se v čase zlepšuje.

Počet incidentů 14 12 10 8 6 4 2 0 200801

200802

200803

200901

Počet incidentů Graf 3

200902

201001

Závěr

5 Závěr Change Management je jedním z klíčových procesů Service Transition a zlepšuje stabilitu, dostupnost a kvalitu IT služeb v bankovnictví. Zároveň poskytuje pro IT dostatečný aparát k propagaci businessem požadovaných změn do produkčního prostředí tak, aby mohly být změny nasazovány v požadovaném čase a s minimálním rizikem. Pro zákazníka jsou pak služby kvalitnější a business se může lépe soustředit na jejich další zlepšování. Ve své práci jsem popsal procesy definované standardem ITIL: Service Strategy, Service Design, Service Transition, Service Operation a Continual Service Improvement. Nejzajímavější se mi z pohledu praxe jeví procesy Service Transition a Service Operation, pomocí kterých lze službu kvalitně zavést do provozu, stabilizovat a efektivně řešit případné incidenty. Proto jsem se právě těmto procesům věnoval podrobněji. Na příkladu reálné bankovní instituce jsem popsal implementaci procesu Change Management, který je částí Service Transition ITILv3. Implementace procesu Change Management byla zvolena z důvodu stabilizace, zlepšení kvality a dostupnosti IT služeb poskytovaných v rámci bankovní instituce. Cílem implementace bylo také zajistit zlepšení vnímání IT služeb ze strany zákazníka a uživatelů. Dalšími procesy průběžně zaváděnými do provozu jsou Incident Management a Event Management. Protože proces implementace stále probíhá, ověřil jsem jen ty části procesu, které byly v průběhu dvou let implementovány. Tyto dílčí procesy jsem podrobně rozepsal ve třetí kapitole, kde jsem poté analyzoval jejich konkrétní vliv na kvalitu a stabilitu služby. V analýze jsem se snažil zachytit také rizika, která vyplývají z případného vynechání procesu. Soubor těchto procesů dohromady tvoří model implementace standardu Change Management v rámci bankovní instituce. Jedná se tedy o konkrétní implementaci standardu ITIL, kterou je možné dále rozvíjet a sledovat. Pro vyhodnocení implementace Change Management jsem zvolil dvě metriky, které sledují vliv zavedení standardu na kvalitu a stabilitu služeb. Pracoval jsem přitom s reálnými daty, která pokrývají období od roku 2008, kdy byla implementace zahájena, až do současnosti. Pro měření jsem vybral modelovou aplikaci, která poskytuje dostatečné portfolio služeb a je jednou ze tří klíčových aplikací v bankovní instituci. Jejím prostřednictvím je realizováno 30% všech obchodů. Výsledky obou metrik ukazují, že implementace procesu Change Management přispívá v rámci bankovní instituce k průběžnému zlepšování kvality a dostupnosti IT služeb. ITIL je standard, který se od roku 2007, kdy byl standardizován jako ITILv3, velmi dobře uplatňuje v IT praxi. Pomocí něj lze efektivně řídit IT služby ve velkých organizacích. V práci jsem se snažil ukázat, že ITILv3 je dostatečně obecný a robustní standard, který je možno úspěšně implementovat v bankovních institucích a pomocí nějž je možné stabilizovat rozsáhlé informační systémy. Bankovním institucím pomůže zlepšit kvalitu poskytovaných IT služeb, jejichž stabilita a dostupnost jsou pro chod bankovního domu v současnosti klíčové. Na IT službách totiž závisí až 90% veškerých činností bankovních domů. Reálnou implementaci a její vyhodnocení se mi, dle mého názoru, podařilo v této práci ukázat.

33

34


6 Literatura 1. Office of Government Commerce. The Official Introduction to the ITIL Service Lifecycle. London : The Stationery Office, 2007. 2. —. Service Strategy. London : The Stationery Office, 2007. 3. —. Service Design. London : The Stationery Office, 2007. 4. —. Service Transition. London : The Stationery Office, 2007. 5. —. Service Operation. London : The Stationery Office, 2007. 6. —. Continual Service Improvement. London : The Stationery Office, 2007.

Příloha Přílohou je CD, které obsahuje dva dokumenty: -

Implementace standardu pro řízení IT služeb v bankovnictví.docx Implementace standardu pro řízení IT služeb v bankovnictví.pdf

Oficiální zadání práce

Recommend Documents