change management tutorial what is change management
Tento komplexní průvodce správou změn podrobně vysvětluje proces správy změn, modely, výhody a 7R:
Change Management (CM) je sada nástrojů, procesů a technik, které se používají k pomoci jednotlivcům při přechodu ze stávajícího stavu v organizaci do nového stavu.
CM lze chápat jako:
- Správa konfigurace pro správu kódu a požadavků.
- Provádění organizačních změn.
- Sledování veškerých změn, které nastanou v IT infrastruktuře - IT Service Management (ITSM).
Co se naučíte:
Přehled správy změn
Cílem CM je aplikovat strategie pro provádění změn cílů, procesů nebo technologií organizace, dohled nad požadavky na změnu a pomoc zaměstnancům přizpůsobit se navrhované změně.
To znamená, že je povinné mít:
- Velmi dobře organizovaný postup řešení změny.
- Dobře připravený soubor postupů pro přípravu odpovědi na žádosti.
- Mechanismus pro sledování provádění žádosti.
K zahájení procesu řízení změn musí organizace vzít v úvahu dopad, který budou mít všechny změněné procesy, systémy v organizaci.
Měly by být zavedeny následující procesy:
- Naplánujte změnu
- Otestujte změnu
- Sdělte změnu
- Naplánujte změnu
- Implementujte změnu
- Zdokumentujte změnu
- Vyhodnoťte výsledky
Dokumentace je důležitým aspektem CM, protože musíme udržovat proces a také odvolání v případě, že je taková akce nezbytná.
Definice správy změn
Na základě různých hledisek lze CM definovat takto:
- Z pohledu odborníka na infrastrukturu jedná se o systematický přístup ke schvalování, testování a zavádění nového zařízení nebo nového vydání.
- Z hlediska projektu je to proces používaný k získání souhlasu se změnami rozsahu, časové osy nebo rozpočtu projektu.
- Z metodik - PMP, Prince2, ITIL, ISO20000, jedná se o proces získání schválení a implementace změn do projektu nebo provozního prostředí.
- Z pohledu PROSCI, Asociace profesionálů v oblasti řízení změn (ACMP), Inovace a institut řízení změn v organizaci (IOCMI), jedná se o proces, který pomáhá organizacím využívat CM na každé úrovni.
- Z hlediska vývoje softwaru je to proces zahrnující sledování a správu požadavků na změny a kódu.
Procesy správy změn jsou rovněž odpovědné za sledování veškerých změn, ke kterým v infrastruktuře IT dojde. ISO 20000 je standard, který definuje cíl řízení změn. Ke správnému sledování a správnému použití se používá každá změna provedená v souboru standardizovaných metod a postupů.
Pokud jde o změny dokumentace, název použitý pro takovou změnu je správa konfigurace a pro správné zacházení s verzí je povinné používat nástroj pro správu změn.
Nástroj CM provede následující akce:
- Sledujte všechny provedené změny.
- Proveďte změny provedené v případě potřeby.
- Zajistěte, aby bylo k dispozici více cest umožňujících vývoj různých verzí stejného produktu současně.
- Ujistěte se, že opravy kódu nebo vylepšení kódu souvisejí s defekty, sestaveními a verzemi.
Vezmeme-li v úvahu úvod, musí být jasné, že k definování pojmu řízení změn budeme muset porozumět kontextu, ve kterém bychom jej chtěli definovat.
Druhy organizačních změn
Je součástí správy, která slouží ke správě mnoha typů organizačních změn. Mezi nejdůležitější typy organizačních změn patří:
- Vývojová změna: To znamená jakékoli změny na úrovni organizace zabývající se zlepšením dříve zavedených procesů a postupů.
- Přechodná změna: Jedná se o změnu zabývající se přesunem organizace ze stávajícího stavu do jiného zcela nového stavu za předpokladu, že organizace má problém, který lze vyřešit změnou současného stavu.
- Transformační změna: Jedná se o změnu, která zásadním způsobem mění kulturu a fungování organizace.
7R's Of Change Management
ITIL „Business Perspectives Volume II“ obsahuje kontrolní seznam se sedmi jednoduchými otázkami v kapitole o kontinuitě podnikání, který nastiňuje kroky při určování změny rizika změny a průzkumu účinnosti procesu řízení změn.
Sedm otázek je diskutováno níže:
# 1) 'Kdo zvedl změnu?'
Existuje mnoho vstupních bodů a zúčastněných stran označených za zdroj změn. To vede k myšlence, že je povinný mít systém pro shromažďování všech změn. Takový systém by měl zahrnovat přijatelné kontroly, které se budou zabývat předáváním pozměňovacích návrhů v účelných oblastech.
# 2) „Jaký je DŮVOD pro změnu?“
Nejprve musíme pochopit, zda změna může přinést riziko bez jakýchkoli obchodních výhod. Každá zásadní změna by měla být analyzována podle dohodnutých kritérií analýzy portfolia.
nový soukromý server World of Warcraft
# 3) „Jaký NÁVRAT se od změny vyžaduje?“
Je nutné si uvědomit, zda změna generuje finanční návratnost.
# 4) „Jaká RIZIKA se podílejí na změně?“
Rizika jsou klasifikována jako rizika, která mohou být přijata, nebo rizika, která by měla být zmírněna. Zásadním krokem při definování souvisejícího nebezpečí je analýza dopadu změn na současnou infrastrukturu. ITIL používá koncept „závažnosti“ pro potenciální rizika a skutečné problémy.
# 5) „Jaké zdroje jsou nutné k provedení změny?“
Když diskutujeme o zdrojích, myslíme na lidi a IT prostředky potřebné pro implementaci změny. Z pohledu lidí musíme pochopit, jaké jsou dovednosti potřebné k provedení změny. Poté, co pochopíme potřebné dovednosti, musíme si být jisti, že tyto dovednosti jsou k dispozici.
# 6) „Kdo je ODPOVĚDNÝ za část změny, která je sestavena, testována a implementována?“
Odpovědnosti za sestavení, testování a implementaci změn aplikace by měly být rozděleny podle požadavků na shodu a audit. Oddělení odpovědností by mělo být sledovatelné, vymahatelné a žalovatelné v celém procesu řízení změn a vydání.
# 7) „Jaký je VZTAH mezi touto změnou a dalšími změnami?“
Analýzu změnových vztahů je třeba provést zevnitř i přes funkční hranice. Plánování plánovaných změn by mělo být sdíleno a tímto způsobem může být analýza dopadu změn a vztah, mapování součástí integrované databáze pro správu konfigurace (CMDB).
Zodpovězení těchto sedmi otázek přináší některé důležité výhody:
- Služby jsou spolehlivější a jsou k dispozici zákazníkům, protože organizace musí používat sadu metrik, která poskytuje objektivnější prostředek k měření rizika změny.
- Můžeme pochopit, jak dobře náš proces řízení změn vyhovuje stávajícímu, a identifikovat je v nových technikách.
- Auditovatelný proces řízení změn je zásadní, protože existuje závislost mezi obchodem na službách IT a novými požadavky.
Modely pro správu změn
Účelem modelů řízení změn je poskytnout hlavní zásady, které manažerům pomohou sladit rozsah navrhovaných změn se stávajícími nástroji.
# 1) ADKAR (Prosci)
Model ADKAR je sekvenční model řízení změn zaměřený na cíl. Vytvořil jej Jeff Hiatt, zakladatel Prosci.
[obraz zdroj ]
dvě hlavní položky testované v integračním testu jsou rozhraní a očekávané výsledky.
Povědomí a požadovaným účelem je změnit současný stav, ve kterém si uvědomujeme, že změna je nutná, ale proces změny ještě nezačal.
Během přechodové fáze se objevují znalosti a schopnosti. A v budoucnu se objeví posílení.
CÍL 1: Povědomí
Někdy je změna v organizaci nevyhnutelná a vyvede lidi z jejich komfortních zón. Vysvětlíme-li důvod změny s dostatečným předstihem, budou mít zaměstnanci dostatek času na to, aby změnu přijali a připravili se na ni.
CÍL 2: Touha
Pokud zaměstnanci pochopí potřebu změny a výhody s ní spojené, uvidíme nadšený přístup a touhu podílet se na implementaci změn.
Pokud nerozumíme pocitům zaměstnance ohledně změny a nebudeme správně řešit jejich obavy a ukážeme jim, jak jim tato změna osobně prospívá, pak změnu plně nepodpoří a nebude mít touhu podílet se na implementaci změny.
CÍL 3: Znalosti
Abychom mohli implementovat nové postupy, budeme muset tým vyškolit a poskytnout jim osvědčené postupy, aby mohli pochopit, jak tuto změnu implementovat.
CÍL 4: Schopnost
Převádění znalostí na schopnosti vyžaduje praxi. Je lepší mít nějakou simulaci pro analýzu výsledků a provedení úprav. Musíme sledovat zaměstnance, když zahájili implementaci změn, a na základě konstruktivní zpětné vazby můžeme tento proces vylepšit.
CÍL 5: Posílení
Myšlenkou tohoto cíle je, že musíme povzbudit zaměstnance, aby průběžně sledovali změnu.
# 2) Mosty přechodový model
Bridges Transition Model vyvinul William Bridges. Jedná se o model zaměřený na lidi. Hlavním účelem je řídit přechod zkušeností lidí na změnu. Silnou stránkou tohoto modelu je, že je zaměřen na přechod, nikoli na změnu.
Myšlenka Bridges je, že lidé budou sledovat fáze svým vlastním tempem. Model identifikuje 3 fáze přechodu:
- Fáze 1: Konec, ztráta a propuštění
Když zaměstnanci poprvé představí změnu, vstoupí do této počáteční fáze přechodu. Budou odolní, protože jsou nějakým způsobem nuceni dělat něco, s čím nejsou v souladu. Zaměstnanci musí pochopit a přijmout, že něco končí, než přijmou nový nápad.
- Fáze 2: Nejistota nebo neutrální zóna
Tato fáze je jako most mezi starým a novým státem. Zaměstnanci jsou stále připojeni ke starému, ale snaží se přizpůsobit novému stavu. Je to ideální okamžik, kdy je třeba povzbudit zaměstnance, aby vyzkoušeli nový způsob práce. Zpětná vazba je v této fázi opravdu důležitá.
- Fáze 3: Přijetí nebo nový začátek
To je doba, kdy zaměstnanci začínají přijímat iniciativu změny. Zaměstnanci budují dovednosti potřebné pro nové postupy.
# 3) IT infrastrukturní knihovna (ITIL)
Toto je rámec obsahující podrobné pokyny pro správu změn v infrastrukturách IT a provozu IT.
ITIL 4 byl vydán v roce 2019 a má hlavní klíčové body zaměřené na automatizaci procesů, zlepšení správy služeb a integraci IT oddělení do podnikání.
ITIL 4 obsahuje devět hlavních zásad a jsou uvedeny na následujícím obrázku:
[obraz zdroj ]
Před implementací ITIL v organizaci je povinné odpovědět na některé otázky související s lajky, jaké problémy v organizaci se snaží vyřešit a jaká je cesta k neustálému zlepšování služeb.
# 4) Kotterův 8stupňový model změny
John Kotter představil 8 krokový model změny, který vyvinul na základě výzkumu 100 organizací, které procházely procesem změn.
Kotter navrhuje, že musíme tvrdě pracovat na prvním kroku, než přejdeme k dalším krokům.
Následující obrázek vysvětluje Kotterův 8stupňový model:
Nastínil model změny v 8 krocích, aby prokázal, že změna není jednoduchý a rychlý proces. Abychom provedli obchodní změnu, měli bychom být opatrní, protože se jedná o obrovskou investici a za velkou cenu.
Proces řízení změn
Každá obchodní oblast má pro CM nějaké specifické nástroje a aplikace. Uvedeme zde několik příkladů, které nám pomohou zjistit, jak CM pracuje pro IT infrastrukturu, vývoj softwaru a koordinaci projektů.
Pro řízení projektů
Řízení změn hraje důležitou roli v činnostech prováděných pro správu projektů. Osoba řídící projekt by měla pečlivě analyzovat žádosti o změnu a určit účinek generovaný změnou pro projekt.
Oblasti projektu, které mohou být změnou ovlivněny, jsou:
- Rozsah projektu: Jak žádost o změnu ovlivní rozsah projektu?
- Časový plán projektu: Jak žádosti o změnu pozmění plán?
- Náklady na projekt: Jak žádost o změnu změní náklady na projekt?
- Kvalitní : Jak žádost o změnu ovlivní kvalitu finálního projektu?
- Lidské zdroje : Zjistěte, zda jsou zapotřebí další nebo specializované lidské zdroje.
- Komunikace: Po schválení žádostí o změnu by to mělo být včas oznámeno příslušným zúčastněným stranám.
- Riziko : Určete rizika generovaná žádostmi o změnu: logistická, finanční nebo bezpečnostní rizika.
- Pořizování : Požadavek na změnu může ovlivnit úsilí o nákup materiálů a smluvní práci.
- Zúčastněné strany : Žádosti o změnu mohou způsobit ztrátu zúčastněné strany a mohou ovlivnit podporu projektu zúčastněnými stranami.
Manažer projektu by měl dokumentovat schválené žádosti o změnu a také odmítnuté žádosti o změnu.
Pro vývoj softwaru
Změna je požadavek na něco jiného, než co bylo dohodnuto na začátku projektu, sprint, fáze (záleží na smlouvě s klientem).
Zavedeme zde nový termín: Změnit objednávku. Objednávka změny je dílo, které by mělo být přidáno nebo mělo být odstraněno z původního rozsahu smlouvy.
Ptáme se, co to znamená změnou ve vývoji softwaru:
- Změna specifikací, obchodních požadavků
- Změna požadavku
- Změna designu aplikace
- Změna kódu
- Změna testování
- Změna může být způsobena:
- Zákazníci
- Uživatelé
- Projektový tým
- Testovací tým
Agilní metodika inspiruje změny v požadavcích, změny během procesu vývoje softwaru a také změny v uživatelském rozhraní (UI). Příběhy se používají pro sledování požadavků na změny.
Poté, co se klient, projektový manažer nebo jiné zúčastněné strany rozhodnou, že pořadí změn je cenné, je třeba provést následující hrubé kroky:
- Proveďte analýzu dopadů
- Vytvořte jasný seznam toho, jaký dopad bude mít změna na:
-
- Časová osa projektu (může být prodloužena)
- Ceny (mělo by být sděleno zúčastněným stranám)
- Rozsah (je možné mít funkce, které lze odstranit, aby zahrnovaly nový)
V závislosti na typu projektu a odvětví je možné po schválení objednávky změn provést i další kroky.
Jedním z klíčových bodů v procesu změny je schvalovací proces. Je třeba schválit požadavek na změnu. Pro tento schvalovací proces je nutné vytvořit vstup požadavku na změnu s podrobnou dokumentací.
Podrobná dokumentace by měla obsahovat informace o ceně žádosti o změnu, rozsahu žádosti o změnu, době potřebné k vyřešení žádosti o změnu a podrobné analýze dopadu žádosti o změnu v systému.
Změny pocházejí z různých zdrojů, včetně zákazníků, koncových uživatelů, projektového týmu nebo testovacího týmu.
Změny od zákazníků a koncových uživatelů jsou obvykle změny v požadavcích. Změny přicházející od projektových týmů obvykle navrhují změny. Změny přicházející od testovacího týmu mohou vyžadovat změny kódu. Změny je nutné sdělit Správci softwarových projektů (SPM). Je třeba použít formulář žádosti o změnu (CR).
Žádost o změnu (CR) by měla obsahovat alespoň následující položky:
- Sériové číslo použité pro jedinečnou identifikaci požadavku na změnu.
- Jasný popis žádosti o změnu.
- Datum, kdy byla vznesena žádost o změnu.
- Obvykle by měl být požadavek na změnu někomu přidělen k analýze. Je povinné mít seznam s některými vstupy týkajícími se podrobností o alokaci. Tento seznam obsahuje:
- Datum přidělení
- Datum dokončení
- Osoby, kterým je žádost o změnu přidělena k analýze
- Žádost o změnu by měla být přidělena někomu ke schválení. Budeme tedy muset sledovat vstupy schválení:
- Datum přidělení ke schválení
- Datum dokončení
- Osoba odpovědná za schválení
- Žádost o změnu by měla být přidělena také pro řešení. Pro rozlišení tedy budeme muset sledovat následující vstupy:
- Datum přidělení k řešení
- Datum dokončení
- Osoba odpovědná za řešení
- Žádost o změnu by měla být přidělena také pro vzájemné hodnocení. S o pro vzájemné hodnocení budeme muset sledovat následující vstupy:
- Datum přidělení pro vzájemné hodnocení.
- Datum dokončení vzájemného hodnocení.
- Osoba, která je odpovědná za vzájemné hodnocení.
- Žádost o změnu by měla být přidělena také pro regresní testování. Budeme tedy muset sledovat následující vstupy pro regresní testování:
- Datum přidělení pro regresní testování.
- Datum dokončení regresního testování.
- Osoba, která je zodpovědná za regresní testování.
- Žádost o změnu by měla mít jasný stav. Stav může mít jednu hodnotu z následující sady (otevřená, uzavřená nebo v rámci analýzy, schválení, řešení, peer review, regresní testování)
- Když zavřeme požadavek na změnu, budeme muset uvést datum uzavření.
Pro lepší organizaci by to po obdržení ČR mělo být zaregistrováno v nástroji.
Poté by měla být provedena analýza, aby se pochopilo, zda je implementace proveditelná nebo ne, harmonogram a úsilí potřebné k implementaci a dopad ČR na harmonogram a náklady projektu.
Stav implementace, průběh řešení ČR je reportován prostřednictvím Týdenních zpráv o stavu příslušným manažerům.
Pro IT infrastrukturu
Nástroje pro správu změn se používají ke sledování změn provedených v hardwarové infrastruktuře IT oddělení. Každá změna provedená v infrastruktuře by měla být systematicky posouzena, schválena, zdokumentována, implementována a přezkoumána. Změny provedené v nastavení hardwaru se označují jako správa konfigurace (CM).
klady a zápory linuxu vs Windows
Problémy při řízení změn
Ve správě změn je mnoho potíží, protože mnoho zaměstnanců změny nepřijímá. Je těžké to změnit, pokud jsme nepochopili, že musíme změnit své myšlení. Se strategickým přístupem ke změně může být přijetí nových procesů snadné. K přijetí změn je nezbytná jasná komunikace.
Níže je uveden seznam výzev a obtíží:
- Konflikty: Změna může ukázat emoce jako zmatek a znepokojení. Konflikt je typická nezamýšlená reakce zmatku a znepokojení. Vedoucí by měl týmu pomoci překonat potíže. Konflikty naruší náš plán. Z tohoto důvodu musíme přijmout opatření ke zmírnění problémů.
- Plánování: Změna nebude mít žádnou změnu implementace bez správného plánu. Je třeba jasně vysvětlit výhody systematického postupu.
- Nedostatek komunikace: Pokud komunikace není dobrá, pak spekulace a fámy budou součástí organizace a nedostatek důvěry znesnadní zaměstnancům přijetí změny.
- Odpor: Odpor je třeba řešit, jinak vytvoří mnoho problémů, které je třeba změnit.
Výhody procesu řízení změn
Jedním z klíčových faktorů CM je, že poskytuje koncepční lešení pro lidi, proces a organizaci provádějící změnu.
Výhody pro organizaci:
- Změna je plánovaný a řízený proces. Výhody změny jsou známy před implementací a slouží jako motivace pro celý proces.
- Organizace může rychle reagovat na požadavky zákazníků.
- Zdroje lze sladit s cíli organizace.
- Výkon zaměstnanců se zvyšuje, když se cítí podporováni a rozumějí procesu změny.
- Změnu lze provést bez negativního dopadu na každodenní práci.
- Umožňuje organizaci hodnotit celkový dopad změny.
- Zlepšuje se organizační účinnost.
- Udržuje se efektivita organizace.
- Zkrácení času potřebného k provedení změny.
- Možnost neúspěšné změny je snížena.
- Zvyšuje se zákaznický servis a služba klientům pochází od sebevědomých a dobře informovaných zaměstnanců.
- Zvýšená návratnost investic (ROI)
- Pomáhá plánovat užitečné komunikační strategie
Výhody pro zaměstnance:
- V případě, že je změna dobře zvládnuta, může minimalizovat odpor vůči změnám.
- Efektivní správa změn podporuje rychlý přechod ze starého do nového a může udržet produktivitu.
- Poskytuje zaměstnancům podporu ohledně obav týkajících se změn.
- Efektivní proces CM vytváří správné pochopení změny pro zaměstnance i veřejnost.
- Pomáhá plánovat efektivní komunikační strategie.
- Zlepšuje kvalitu práce.
- Vylepšuje spolupráci a komunikaci.
Často kladené otázky
Otázka č. 1) Co je řízení změn?
Odpovědět: CM je sada nástrojů, procesů a technik používaných pro pomoc jednotlivcům při přechodu ze stávajícího stavu v organizaci do nového stavu.
Existuje několik důležitých aspektů:
- Správa konfigurace: Správa kódu a požadavků.
- Provádění organizačních změn.
- Sledování veškerých změn, které nastanou v IT infrastruktuře - IT Service Management (ITSM).
Otázka 2) Jaký je proces řízení změn softwaru?
Odpovědět: Správa změn softwaru je proces klasifikace změn podle kritérií projektu, jako je plán a cena.
Otázka č. 3) Jaký je rozdíl mezi kontrolou změn a správou změn?
Odpovědět: CM je forma porozumění, přizpůsobení a přizpůsobení se novému normálnímu stavu po transformaci organizace. Řízení změn je proces, jakým jsou změny požadavků ukládány, analyzovány, spravovány a zahrnuty do plánu a harmonogramu implementace.
Otázka č. 4) Jaké jsou 3 druhy změn?
Odpovědět: Mezi následující druhy změn patří vývojové změny, přechodné změny a transformační změny.
Závěr
Řízení změn může zvýšit úspěšnost organizací a projektů uplatněním strukturovaných nástrojů, implementací několika metod a navržením jasných procesů. Vrcholové vedení by mělo plánovat implementaci změny takovým způsobem, aby zaměstnanci měli pocit, že změna pro ně přinese nějaké pozitivní výsledky.
Pro správu změn existují různé modely. Při plánování je třeba vzít v úvahu tyto modely.
Jedním z klíčových bodů v CM je zapojení lidí do procesu změn. Změny v organizaci nelze dosáhnout bez podpory zaměstnanců a vedení. Správný plán pro CM pomáhá zajistit, aby proces změny byl spuštěn a řízen správnými lidmi ve správný čas.
Doporučené čtení
- Top 10 softwarových řešení pro správu změn v roce 2021
- 11 NEJLEPŠÍCH nástrojů pro správu konfigurace softwaru (nástroje SCM v roce 2021)
- Výukový program Bugzilla: Výukový program pro správu defektů
- Výukový program pro správu testů: Ultimate Guide to Test Management
- Výukový program pro praktickou kontrolu nástroje pro správu testů PractiTest
- Správa konfigurace v DevOps Practices
- Výukový program pro testování konfigurace s příklady
- 25 nejlepších nástrojů pro správu projektů v roce 2021 (nejnovější hodnocení)