|
Úloha
: Řízení provozních změn
|
|
|
|
|
Kód úlohy
Standardní kód úlohy v MBI.
:
|
Autor návrhu úlohy
Jméno a příjmení autora úlohy
:
|
Datum poslední úpravy
Datum poslední úpravy úlohy ve tvaru rrrr.mm.dd.
:
|
Předpokládaná pravděpodobnost užití v praxi
Předpokládaná pravděpodobnost užití úlohy v praxi, hodnoty 0 - 1. Např. 0,7 - úlohu lze využít v 7 z 10 podniků. Hodnoty jsou průběžně testovány a upřesňovány na základě anket a průzkumů.
:
|
|
|
Charakteristiky úlohy
 1. “Řízení provozních změn“ – cíl, účel
-
Cílem
úlohy je standardizovaným přístupem zajistit
řízení celého životního cyklu změny,
a to:
- minimalizovat negativní dopady a rizika změny,
- minimalizovat čas a náklady potřebné na změnu,
- úspěšně provést změnu napoprvé.
 2. Obsah úlohy
- Úloha pokrývá
komplex činností
spojených s přípravou a realizací změn v IT.
Úloha:
- určuje, na které prvky systému, resp. konfigurační položky se bude řízení změn vztahovat,
- analyzuje vliv dopadu změn na zajištění IT služeb,
- definuje postupy evidence, vyhodnocení a schvalování žádostí o změnu.
- V případě změn týkajících se vytvoření, výrazné komplexní změny služeb, deaktivace služeb, nebo přenesení jejich zajištění na jiného poskytovatele
řeší se tyto požadavky na změny v rámci úloh řízení služeb.
-
Specifický režim mají i urgentní změny
, které musí být definovány dle dohody mezi poskytovatelem a zákazníkem. V rámci úlohy se definuje i harmonogram zavádění schválených změn.
-
Schválené změny se po jejich realizaci testují,
a to podle definovaných postupů, které mimo jiné zajistí, že neúspěšně připravené a nasazené změny lze operativně odstranit nebo opravit (viz ISO/IEC 20000-1, 9.2).
 3. Vstupy úlohy:
- Katalog požadavků na IT (D042A
),
- Katalog IT služeb (D111A
),
- Evidence incidentů a problémů a jejich řešení (D721A
),
- Dokumentace provozu service-desku (D723A
),
- RFC, požadavek na změnu (D725A
),
- Návrh na změnu kontraktu a SLA (D726A
),
- Provozní dokumentace (D711A
),
- Technická dokumentace sítě (D712A),
- Analýza IT dodavatelů (D121A
),
- Aplikační architektura (D053A
),
- Technologická architektura (D054A
),
- Analýza stavu technologické infrastruktury (D233A
),
- Plán rozvoje technologické infrastruktury (D235A
).
 5. Podmínky úspěšnosti úlohy
- Existence service-desk nebo úlohy řízení uživatelských požadavků,
- Faktor dopadu změny je nezbytné analyzovat co nejpřesněji,
- Součástí každé změny by měl být plán její nápravy v případě neúspěchu, podrobnost tohoto plánu závisí na povaze změny,
- Je nezbytné veškeré změny dokumentovat. Není žádoucí, aby znalosti o změnách byly vázány na konkrétní osoby.
 6. Doporučené praktiky
-
Změnový tým by se měl skládat ze zástupců všech stran
, kterých se změna dotkne (např. zákazník, zástupci uživatelů, klíčový uživatel, vývojář, konzultanti, zaměstnanci kanceláře, zástupci třetích stran v případě outsourcingu, servisní a operativní personál aj.).
-
Úroveň řízení změn se liší především v závislosti na velikosti podniku a jeho okolí
– je-li okolí málo turbulentní, lze očekávat, že požadavky na změny budou přicházet v menším rozsahu a nebude se jednat o komplexní změny, proto není třeba provádět například dokumentaci příliš podrobně, jelikož odpovědnost za změnu i dohledatelnost změny není tak složitá, podobně tomu je při malém podniku, kdy lze dopad změny poměrně přesně určit stejně jako odpovědnosti, naopak při rostoucí velikosti podniku je nutné provádět činnosti podrobněji, především pak dokumentaci a odhady, aby bylo zamezeno neočekávanému ovlivnění systému, současně roste i význam plánu nápravy změny.
- V případě turbulentního prostředí podniku, kdy je velký počet požadavků na změnu, je vhodné
pro rutinní změny zavést standardní postupy, které může autorizovat co nejnižší úroveň řízení podniku
, tím je proces realizace změn podstatně rychlejší, také je vhodné standardizovat proces dokumentace změn a její formát, aby byly změny přehledně řazené a co nejsnadněji dohledatelné.
-
Při odhadu a vyhodnocení změny musí být organizace schopná odpovědět na následující otázk
y:
- Kdo vyvolal změnu?
- Jaký je důvod změny?
- Co má změna přinést?
- Jaká jsou rizika spojená se změnou?
- Jaké zdroje budou třeba?
- Kdo je zodpovědný za build, testování a implementaci změny?
- Jaký je vztah mezi změnou a ostatními změnami?
-
Normální menší změny se mohou svým typem překrývat se standardními změnami
. Hlavním rozdílem je to, že standardní změna je v organizaci často prováděná a má tedy smysl pro ni vytvořit samostatný proces.
-
Plánované odstávky služeb je dokument,
který obsahuje informace o rozvrhu všech plánovaných nedostupnostech služeb, které zapříčiní změny nebo projekty.
 7. “Řízení provozních změn“ - klíčové aktivity
- Záznam požadavku na změnu - požadavek může být vznesen prostřednictvím (zjednodušeného) RFC (Request for Change, Požadavek na změnu), ale i slovně. Je svolán poradní výbor pro naléhavé změny a je zaznamenán RFC.
- Odhad a vyhodnocení změny - poradní výbor musí odhadnout dopad (mimo jiné je třeba brát v úvahu bezpečnost a SLA, na ostatní služby nebo projekty, které běží na stejné infrastruktuře), rizika změny a potřebné zdroje. Dále musí ověřit, je-li změna urgentní. Musí proběhnout schůzka členů, kteří diskutují a podávají připomínky ke změně. Všechny tyto připomínky je třeba dokumentovat.
- Autorizace změny - poradní výbor musí zkontrolovat, je-li změna v souladu se současnými plánovanými projekty a změnami, pokud si odporují je nezbytné vrátit se k diskuzi o změně. V případě nutnosti kapacit je nezbytné srozumět ta oddělení, jejichž činnost bude změnou ovlivněna (jejichž kapacity budou využity). Musí být stanoven plán nápravy změny a plán samotné změny (v RFC).
- Aktualizace plánů změn, resp. projektů - aktualizace změnového plánu popř. plánu projektů, aby mohla být změna provedena.
- Koordinace implementace - je nezbytné vytvořit build změny. Je doporučeno všechen čas, který zbývá, vložit do testování (je-li pouze velmi omezený čas pro testování je vhodné otestovat alespoň prvky, které budou užity okamžitě nebo prvky, které mohou způsobit největší krátkodobé problémy. V této fázi jsou testy zaměřené především na funkcionalitu a jednotkové testy).
- Kontrola a uzavření záznamu o změně - kontrolu provádí po stanovené době pokud možno všichni členové poradního výboru. Tato kontrola má potvrdit, že změna dosáhla svého cíle a že se nevyskytly žádné neočekávané vedlejší efekty. Pokud se vyskytly problémy související s danou změnou musí být také prezentovány a řízení změn musí rozhodnout, jestli pro jejich nápravu vyvolají novou změnu nebo upraví stávající.
- Dokumentace realizované změny - je důležité dokumentovat všechny údaje o změně, aby bylo možné zpětně ji dohledat a identifikovat jestli s ní nastalé problémy nesouvisí. Dokumentace může být buď ve formě formulářů (RFC, plány apod.) nebo jako aktualizace změny v CMS (Configuration Management System), je-li implementován.
|
|
|
|
