Oficiální zadání práce

Transkript

1 Oficiální zadání práce

2

3 Č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

4

5 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

6

7 Obsah 1 Úvod Základní procesy ITIL v bankovnictví Obecná problematika Service Strategy Service Design Service Transition Change Management Release And Deployment Management Service Operation Incident Management Event Management Request Fulfilment Problem Management Access Management Continual Service Improvement Implementace procesu Change Management Modelová aplikace Model migrace nové verze aplikace Business testy Performance testy Souběhové testy Integrační testy Analýza dopadů na pravidelné zpracování Příprava migračních balíčků Plán migrace Pilotní provoz Informace BU a SLM RFC nástroj IT CAB Committee Koordinace migrace Podpora po migraci Monitoring Vyhodnocení migrace Analýza modelu Ověření a vyhodnocení implementace Metriky ITIL Počet oprav na změnu Počet incidentů na změnu Závěr Literatura... 34

8

9 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 OBR. 6 PLAN-DO-CHECK-ACT CYKLUS OBR. 7 CSI CYKLUS OBR. 8 RFC ZÁKLADNÍ PRŮBĚH... 23

10

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

12

13 Seznam použitých zkratek BU Business CAB Change Advisory Board CAB/EC Change Advisory Board/Emergency Committee CAPEX Capital Expenditure CI Configuration Item COBIT Control Objectives for Information and Related Technology CSI Continual Service Improvement ELS Early Life Support EM Event Management ERFC Emergency Request for Change HA High Availability CHA Change Authority CHC Change Coordinator ISO International Organization for Standardization IT Information Technology ITIL IT Infrastructure Library ITSM IT Service Management KEDB Known Error Database KPI Key Performance Indicator MTBF Mean Time Between Failures MTBSI Mean Time Between Service Incidents MTRS Mean Time to Restore Service PIR Post-Implementation Review QA Quality Assurance RDM Release and Deployment Management RFC Request for Change SD Service Desk SIT System Integration Test SLA Service Level Agreement SLM Service Level Management SPI Service Provider Interface SPOF Single Point of Failure TCO Total Cost of Ownership TCU Total Cost of Utilization UAT User Acceptance Test

14

15 Úvod 1 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.

16 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í.

17 Základní procesy ITIL v bankovnictví 3 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) Shoda (Compliance) Účinnost (Effectivenes) Efektivita (Efficiency) Milníky či produkty vypovídající o schopnostech procesu Soulad procesu s požadavky, regulačními omezeními Přesnost a správnost procesu a jeho schopnost dodávat správné výsledky 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

18 4 Implementace standardu pro řízení IT služeb v bankovnictví 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?

19 Základní procesy ITIL v bankovnictví 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/ Technology Partners/ Suppliers Obr. 3 People, Processes, Products, Partners = 4P

20 6 Implementace standardu pro řízení IT služeb v bankovnictví 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 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á.

21 Základní procesy ITIL v bankovnictví 7 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.

22 8 Implementace standardu pro řízení IT služeb v bankovnictví 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, ). - 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.

23 Základní procesy ITIL v bankovnictví 9 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.

24 10 Implementace standardu pro řízení IT služeb v bankovnictví 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ář 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.

25 Základní procesy ITIL v bankovnictví 11 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.