Ako vytvoriť program riadenia zmien IT?
Program riadenia zmien (CMP), bežnejšie známy ako proces riadenia zmien alebo proces riadenia riadenia zmien, je formálny proces, ktorý sa používa na zaistenie zavedenia zmien do produktu alebo systému kontrolovaným a koordinovaným spôsobom (podľa normy ISO 20000). CMP by sa nemalo zamieňať s organizačným manažmentom zmien (OCM), ktorý riadi dopady nových podnikových procesov vrátane tých, ktoré vyplývajú zo zavedenia systému a iniciatív IT, zmien v organizačnej štruktúre alebo kultúrnych zmien v rámci podniku. Stručne povedané, OCM riadi ľudskú stránku zmeny.
Cieľom CMP je zaistiť, aby bol negatívny vplyv zmien na systém informačných technológií spoločnosti minimalizovaný pomocou štandardizovaného postupu riadenia. Niektoré zmeny nie sú voliteľné. Ak sa napríklad zmení štandard čiarového kódu, musíte sa prispôsobiť; ak sa zmení štruktúra zrážok dane, musíte to zmeniť. Napriek tomu všetky zmeny tohto druhu stále podliehajú správe a riadeniu.
Nikdy nesmie nastať prípad, že by boli ad hoc zmeny vykonávané v systéme alebo v postupoch bez určitého dohľadu. Táto myšlienka musí pochádzať od vyššieho manažmentu a musí byť bez výnimky odovzdaná každému v spoločnosti. Bez podpory na najvyššej úrovni je CMP zbytočnou stratou času a peňazí. Pri správnom zabezpečení tento program ušetrí vašej spoločnosti pred veľmi nákladnými chybami.
- 1Vypracovať požiadavku na zmenu (RFC): Toto môže pochádzať z manažmentu problémov, kde je identifikovaný problém alebo séria súvisiacich problémov a je potrebná zmierňujúca zmena, aby sa zabránilo (alebo minimalizovalo) budúcim účinkom. RFC môže tiež pochádzať z obchodného rozhodnutia, ktoré bude vyžadovať určité úpravy (pridanie, odstránenie, zmena) podpornej technológie. RFC môže byť tiež nevyhnutné z dôvodu vonkajších vplyvov (tj vládnych nariadení alebo zmien vykonaných obchodnými partnermi).
- 2Získať súhlas so zmenou podniku: Rozhodnutie vykonať zmenu je spravidla obchodné rozhodnutie, kde sa vážia náklady vs. Aj v situáciách, keď je zmena striktne zameraná na infraštruktúru (zlyhanie komponentu alebo systému), rozhodnutie minúť peniaze spočíva v obchode, nie v IT oddelení. Existujú prípady, keď sú vopred vyvinuté postupy na predbežnú autorizáciu zmien, ako je núdzová údržba systému, ale bez ohľadu na načasovanie autorizácie zostáva rozhodnutie stále na obchodnom manažmente.
- 3Začať vývojový projekt: Vývoj zmeny (vrátane testovania) je funkcia riadená IT. V prípade núdzovej zmeny (server je vypnutý) sú tieto funkcie spravidla vopred určené. Keď sa má vyvinúť nový systém, dochádza k spolupráci medzi firemnými používateľmi a tímom IT. Systémy sú navrhnuté spoločnosťou IT, dizajn je schválený obchodnými partnermi (používateľmi), vyvinutý spoločnosťou IT, testovaný kombináciou IT a používateľov a konečný produkt je schválený oboma. Starostlivá pozornosť sa musí venovať pomocným účinkom, ktoré môže mať nová zmena na existujúce systémy.
- 4Prejdite bránou riadenia zmien: Poradný výbor pre zmeny (CAB) kontroluje všetky zmeny pred ich uvedením do výroby. CAB bude obvykle pozostávať zo skupiny ľudí s rôznymi perspektívami, pozadím a odbornosťou. Ich funkciou je preskúmať zmenu z hľadiska procesu a riadenia, aby sa zabezpečilo, že všetky predvídateľné riziká boli identifikované a zmiernené a že pre všetky prvky expozície (veci, ktoré by sa mohli pokaziť) existujú kompenzačné techniky. Vývojový tím a sponzor zmeny predložia zmenu CAB. V centre pozornosti bude hodnotenie rizika. Implementačné stratégie, komunikácia s dotknutými zainteresovanými stranami, záložné plány a monitorovanie po implementácii sú prvky, na ktoré sa musí CAB zamerať. CAB nie jezodpovedný za určenie, či je zmena primeraná - toto rozhodnutie už bolo prijaté. CAB tiež nezodpovedá za určenie, či je zmena nákladovo efektívna. Opäť je to výlučne obchodné rozhodnutie.
- 5Vykonajte zmenu: Ak CAB zmenu neschváli, uvedú sa dôvody (je to vždy preto, že určité riziká neboli zmiernené alebo nebola naplánovaná komunikácia) a vývojový tím dostane čas na vyriešenie týchto problémov a zmenu termínu schôdze pred CAB. Ak je zmena schválená, je naplánovaná implementácia. Bežne to nie je tak, že je CAB zastúpený pri implementácii, aj keď je možné, že niektorí členovia CAB majú odborné znalosti potrebné počas implementácie, ale nebudú prítomní ako oficiálni zástupcovia CAB, ale skôr ako odborníci na predmetnú problematiku (SME). Spôsob implementácie zmeny, kontrolný zoznam a kroky sú preddefinované a boli predložené a schválené CAB. Celý proces musí byť dôkladne zdokumentovaný a presne dodržaný schválený postup.
- 6Nahlásiť výsledky: Buď bola zmena úspešne implementovaná bez problémov, zmena bola implementovaná s problémami, ktoré boli počas implementácie opravené, zmena bola implementovaná s problémami, ktoré sa považovali za prijateľné, objavili sa problémy, ktoré boli neprijateľné a zmena bola vrátená späť, alebo v najhoršom prípade bola zmena implementovaná s neprijateľnými problémami a nebolo ju možné vrátiť späť. Bez ohľadu na výsledok je dokumentovaný a vrátený do CAB. CAB je potom zodpovedný za distribúciu týchto informácií zainteresovaným stranám a za uchovávanie a udržiavanie týchto výsledkov v systéme riadenia zmien (môže to byť buď automatizovaná databáza, alebo systém papierovej evidencie, ale dokumenty sa musia uchovávať na účely auditu).
- 7Prepojiť manažment problémov so zmenami: Problémy, ktoré vzniknú, by mali byť porovnané s dokumentáciou zmien CAB, aby bolo možné izolovať všetky neočakávané nepriaznivé účinky zmeny. Často sa stáva, že nežiaduce účinky zmeny nie sú zaznamenané okamžite, ale sú identifikované vznikom problémov v pomocných systémoch. Napríklad pridanie niekoľkých polí do databázy nemusí mať priamy negatívny vplyv na používateľov, ale môže ovplyvniť výkon siete, ktorý by bol zrejmý pre ostatných používateľov, ktorí nie sú priamo zapojení do upraveného systému.
- 8Pravidelný audit CMP: Minimálne raz za rok by sa mal vykonať audit CMP, aby sa zabezpečilo, že všetka dokumentácia o zmenách je udržiavaná a dostupná. Každý dokument o schválení zmeny by mal byť skontrolovaný, aby sa zaistilo, že sú k dispozícii správne podpisy a že výsledky implementácie sú riadne zdokumentované.
- Mala by byť schválená štandardná pravidelná údržba. Ak je normálnym procesom reštartovanie servera v nedeľu ráno o 2:00, nie je potrebné odosielať RFC vždy, ale tento proces musí byť schválený vopred.
- Údržba ad hoc musí dodržiavať CMP. Zahrňte napríklad testovanie protipožiarnych systémov, čistenie podláh v dátovom centre, inšpekciu a testovanie HVAC a dokonca aj údržbu proti škodcom. Niektoré spoločnosti idú tak ďaleko, že vyžadujú RFC, ak sa v dátovom centre zmení žiarovka (rebrík spadol a poškodil sieť).
- Postupy by mali podliehať manažmentu zmien. Ak dôjde k zmene v plánovaní zálohovania systému, musí prejsť správou zmien. Analyzujte každú zmenu akéhokoľvek druhu (systému alebo postupu), aby ste zistili, či existuje nejaké možné riziko.
- V vyspelých systémoch, kde sú zmeny rutinnejšie, sa kontrola CAB môže vykonávať elektronicky tak, že členovia CAB „schvália“ alebo neschvália implementáciu. To môže znížiť potrebu nákladných schôdzí, pretože s nadchádzajúcou implementáciou nie sú žiadne výnimočné zmeny.
- Členov CAB často striedajte. Vždy rovnakí členovia môžu viesť k uprednostňovaniu a môže to viesť k vyhoreniu. Chcete, aby bol váš CAB svieži, dávajte pozor a nepodliehajte vonkajším politickým vplyvom.
- CAB môže politike často prekážať. „Táto zmena je potrebná“ môže byť pravda, ale môže to byť aj osobná agenda jedného z vedúcich pracovníkov. CAB musí mať maximálnu právomoc rozhodovať o implementácii.
Otázky a odpovede
- Ako dlho trvá vytvorenie programov riadenia zmien IT?
- Musím vytvoriť program na rozvoj programu riadenia zmien IT? Je už nejaký k dispozícii? A ak mám napísať kód, aký jazyk mám použiť?
Komentáre (1)
- Pomohlo mi to predbežne porozumieť CMP. Dobré miesto na začiatok.