Proč bych měl ve firmě zavést proces správy změn (change management)?

V každé firmě se přirozeně vyvine něco, čemu říkám neformální change management. Většinou bývá hodně rigidní, konzervativní, postavený na zvycích a lidech. Proto se hrozně těžko aktualizuje a přizpůsobuje měnící se situaci. V reálu to znamená, že změny je složitější prosadit a provádět kontrolovaným způsobem. Je to jako devítihlavá saň, kdy řešíš jednu událost z pohledu jedné větve byznysu, ale jiné oblasti trpí, protože to neděláš systémově. V tomhle stavu hrozí několik nebezpečí. První pastí je absence procesu na straně byznysu. Jakákoliv personální změna způsobí problém. Nový člověk s neformální správou změn není seznámený, a buď postup začne složitě získávat (komu zavolat, na koho se obracet se žádostí) nebo ho začne znovu sám vytvářet. Je to hledání slepých uliček, které zdržuje a konzumuje kapacitu lidí.

Druhou pastí je absence procesu na straně IT. Přestože se mi ze strany iniciátorů změn povede získat strukturovaný postup, není jasné, kdo to realizuje na straně IT. Jednou to bude vývoj, podruhé provoz, potřetí někdo další. Případně se bude hrát ping pong, kdy se to jeden tým snaží přehodit na druhý. Provedení změny nebude standardní, kdy se jednou realizuje za 3 dny a podruhé za 14 dní, podle toho, jak to IT zrovna cítí.

Následně narazíš na spoustu dalších dílčích problémů jako chybějící prioritizace, špatná informovanost byznysu o průběhu změny, slabé kapacitní řízení, atp.

Na co si mám dát pozor, pokud change management zavádím?

Je důležité si uvědomit, že change management se nedá dělat napůl. Aby dával smysl, musí se poctivě dodržovat. Bez podpory managementu není možné jej prosadit. Zažil jsem například implementaci change managementu, která získala certifikaci ISO 20 000, a přesto šlo o neúspěšný projekt. Byl to projekt bez manažerské podpory, kde zadání v podstatě znělo následovně: „Stačí, když projdeme auditem a získáme certifikaci.“ Proces se udělal do šuplíku, aby se jednou za rok vytáhl a předložil auditorovi. V reálu ale všechno dál běželo mimo formální proces. Potom první kverulant, na kterého narazíš, dobře ví, že může věci dělat postaru bez jakékoliv sankce. Můžeš vyrobit Potěmkinovu vesnici, ale pokud nepřesvědčíš byznys, získáš neúspěšný proces, byť s certifikací ISO 20 000. Změny se budou dál prosazovat neformálními cestami.

Pokud podporu vedení získáš, stále hrozí, že se projekt nedotáhne do konce. Prvotní efekt totiž většinou bude zhoršení kvality, snížení kapacity, zvýšení nákladů. To je obecně nevýhoda všech IT Service Management projektů. Je potřeba být připravený, že k počátečnímu zhoršení může dojít a chápat, že tuto fázi musíme překonat, aby se mohly dostavit benefity a zlepšení.

To se dostáváme k řízení očekávání. V okamžiku, kdy dojde k dočasnému zhoršení, se tým dostává pod tlak. Jak postupuješ v takové situaci?

Očekávání by měla být jiná od zaběhnutého procesu než okamžitě po implementaci. I v post-implementační fázi dokážu dosáhnout některých rychlých vítězství. V change managementu jsou to typicky standardní, předem schválené změny. Tím si vždycky pomáhám. Vytipujeme relativně drobnou, často probíhající změnu, která má kvůli nesystematickému řešení velkou chybovost nebo je bržděná byrokratickými překážkami. Pokud standardní změnu dobře definujeme, popíšeme workflow a navedeme k ní změnové události, máme rychlé vítězství, které zákazník vnímá pozitivně, dá se na něm demonstrovat smysluplnost procesu a prokazatelně uvolní určitou kapacitu týmu.

Řešil jsem například proces pro automobilku, kdy auta při havárii automaticky volají tísňovou linku ze všech lokalit v Evropě. Pokud se změní tísňová linka v dané lokalitě, je potřeba aby informace protekla do všech systémů. Takovou změnu není potřeba schvalovat a zatěžovat byrokracií. Rozhodli jsme, že změna bude předem schválená, nastavili jsme automatizované workflow, které spustí žádosti na telefonního operátora, databáze. Tím odpadlo spoustu manuální práce. Je ale potřeba dobře připravit proces realizace změny.

Když proces zavedu, jak ověřím úspěch projektu?

Obecně platí, že když chystám projekt, připravím si rovnou i metriky, podle kterých budu projekt hodnotit. To platí i u zavádění change managementu. Metriky budou subjektivní a objektivní (soft + hard). Ty subjektivní jsou velmi důležité. Jedná se o spokojenost byznysu a IT s průběhem procesu. Pomocí dotazníků a rozhovorů získám jasnou představu, jak jsou lidé spokojení se stávajícím procesem. Po implementaci změny provedu stejné hodnocení klidně se známkováním každé změny a vyhodnotím, zda došlo k pozitivnímu vývoji. Soft ukazatel může být ale i frekvence, s jakou tě vedení volá na kobereček, kolik je eskalací a stížností. I zde se dá do určité míry spočítat, jak to bylo před a po implementaci.

Dál samozřejmě měříš i tvrdé ukazatele, které jsou jasněji prokazatelné a mají do určité míry větší argumentační sílu. Například měříš time to market, tedy čas, který uplyne od požadavku na změnu po realizaci. Většinou to měříš zvlášť podle kategorie a priority změn. Jak rychle dokážu realizovat urgentní změny? Jak rychle minor změny? Potom můžu sledovat chybovost ve změnách. Kolikrát jsem musel roll-backovat změnu? Kdy jsem ji implementoval na více pokusů? To jsou čísla, která ti ukážou, jestli změnový proces funguje a jaké je zlepšení od stavu před implementací.

Jak následně zajistím, že proces neodumře a firma nesklouzne zpět k neformálnímu řízení změn?

ITIL mluví o principech dlouhodobého směřování a správy (IT governance). Existuje mezičlánek mezi teorií (sepsáním pravidel) a prosazením pravidel. Jsou to postupy, které musíš vytvořit spolu se samotným procesem. Jejich úkol je zajistit kontrolu procesu, hodnocení a vytvoření tlaku na jeho vykonávání. Pokud uděláš proces bez governance, tak si ani nevšimneš, že nefunguje nebo že se obchází. Když používáš principy správy IT, pak například vzniká pravidelný report, který vizualizuje, kolik procent požadavků prošlo přes formální část CHM a kolik přes neformální. V podstatě už při implementaci procesu nastavuješ mechanismus, co se stane, pokud tato část bude vyšší než například 10 %. Důsledkem pak většinou je, že se konkrétní problémy řeší na manažerské úrovni. Tímto způsobem hlídáš, aby se z teoretické, administrativně zpracované části procesu stal živý proces.

Jan Škrabánek Autor rozhovoru je konzultantem společnosti ALVAO.