Bankovní institut vysoká škola Praha
Rozvoj podniku pomocí strategického řízení změn Diplomová práce
Zdenek Procházka
Duben, 2010
Bankovní institut vysoká škola Praha K108 – Katedra informačních technologií a elektronického obchodování
Rozvoj podniku pomocí strategického řízení změn Diplomová práce
Autor:
Zdenek Procházka Informační technologie a management
Vedoucí práce:
Ing. Václav Šebek, CSc.
Odborný konzultant: (není stanoven)
Praha
Duben, 2010
Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a s pouţitím uvedené literatury. podpis autora V Praze dne
Poděkování: Děkuji vedoucímu práce inţenýru Václavu Šebkovi, CSc. za trpělivost a cenné rady v průběhu vypracování předloţené diplomové práce. Dále děkuji všem svým kolegům, kteří mi věnovali potřebný čas při konzultacích a jednáních.
Anotace práce: Předložená diplomová práce je zaměřena na přiblížení procesů strategického a změnového řízení, a to jak po teoretické a metodické stránce, tak i po stránce praktické z pohledu implementace a využití v podniku autorova zaměstnavatele. Výsledkem je uplatnění obou procesů v průběhu transformačního projektu a výsledky spojené se zaváděním popsaných změn v průběhu transformace. Autor podrobně popisuje příčiny a průběh transformačního projektu od iniciace přes analýzu, monitoring a plánování až po implementaci. V neposlední řadě se zamýšlí nad chybami a bariérami projektu a hodnotí dosažené cíle. Present Diploma Thesis is focused on strategic and change management processes, both from the theoretical and methodical point of view and also from the practical point of implementation and usage in author’s company. The result is use of both processes during the transformation project and results related to implementation of described changes in course of transformation. The author describes in detail the causes and course of transformation project beginning from the initiation through analysis monitoring and planning till implementation. Last but not least he thinks about the mistakes and barriers in project and evaluates the achieved goals.
Obsah: OBSAH:....................................................................................................................................................... 4 ÚVOD .......................................................................................................................................................... 6 ROZVOJ PODNIKU A STRATEGICKÉ ŘÍZENÍ ................................................................................ 8 ROZVOJ PODNIKU A STRATEGICKÉ ŘÍZENÍ ................................................................................ 8 1.1
CÍLE A ŢIVOT PODNIKU ............................................................................................................... 8
1.1.1
Fáze založení podniku ........................................................................................................ 10
1.1.2
Fáze růstu podniku ............................................................................................................. 12
1.1.3
Fáze stabilizace podniku .................................................................................................... 12
1.1.4
Fáze krize podniku .............................................................................................................. 13
1.2
2
STRATEGICKÉ ŘÍZENÍ ............................................................................................................... 14
1.2.1
Definice strategie................................................................................................................ 14
1.2.2
Definice strategického myšlení ........................................................................................... 15
1.2.3
Proces strategického řízení................................................................................................. 16
1.2.4
Formulování podnikové vize, mise a podnikových cílů....................................................... 19
1.2.5
Analýza okolí organizace.................................................................................................... 22
1.2.6
Formulace strategie............................................................................................................ 24
1.2.7
Implementace strategie ....................................................................................................... 25
1.2.8
Hodnocení a kontrola strategie .......................................................................................... 27
1.3
INFORMAČNÍ STRATEGIE PODNIKU ........................................................................................... 27
1.4
STAV STRATEGICKÉHO ŘÍZENÍ V PODNIKU ZAMĚSTNAVATELE ................................................. 28
ŘÍZENÍ ZMĚN ............................................................................................................................... 32 2.1
STRATEGIE ŘÍZENÍ ZMĚN V PODNIKU ........................................................................................ 32
2.2
PROCES ŘÍZENÍ ZÁSADNÍCH ZMĚN V PODNIKU .......................................................................... 35
2.3
PROCES ŘÍZENÍ ZMĚN V OBLASTI IT/ICT .................................................................................. 38
2.4
PROCES ŘÍZENÍ ZMĚN V PODNIKU ZAMĚSTNAVATELE .............................................................. 41
2.4.1
3
Proces řízení změn .............................................................................................................. 43
2.4.1.1
Změna softwaru....................................................................................................................... 44
2.4.1.2
Změna infrastruktury ............................................................................................................... 46
2.4.1.3
Standardní a Urgentní změna .................................................................................................. 50
2.4.1.4
Klasifikace dopadů změny ...................................................................................................... 51
2.4.1.5
Role v procesu řízení změn ..................................................................................................... 52
2.4.1.6
Metriky procesu řízení změn ................................................................................................... 56
2.4.2
Proces řízení uvolňování verzí (release) ............................................................................ 59
2.4.3
Kritická místa procesu a možnosti zlepšení ........................................................................ 62
PROJEKTOVÉ ŘÍZENÍ ................................................................................................................ 66
4
4
3.1
PROJEKTOVÉ ŘÍZENÍ – ZÁKLADNÍ TERMINOLOGIE .................................................................... 66
3.2
PROJEKTOVÉ ŘÍZENÍ V PODNIKU ZAMĚSTNAVATELE ................................................................ 68
3.2.1
Proces řízení projektů ......................................................................................................... 69
3.2.2
Proces softwarového inženýrství ........................................................................................ 71
3.2.3
Role v procesu projektového řízení ..................................................................................... 72
PŘÍPADOVÁ STUDIE V PODNIKU ZAMĚSTNAVATELE ................................................... 75 4.1
ANALÝZA PŘEDCHOZÍHO STAVU ORGANIZACE ......................................................................... 75
4.2
ZMĚNA STRATEGIE ŘÍZENÍ ÚTVARU INFORMATIKY ................................................................... 83
4.2.1
Formulace strategie a cílů .................................................................................................. 83
4.2.2
Cílová organizační struktura a kompetence útvaru ............................................................ 90
4.3
PROJEKT IMPLEMENTACE STRATEGIE ....................................................................................... 93
4.3.1
Metodika implementace změny ........................................................................................... 94
4.3.2
Aktivity a dokumentace projektu ......................................................................................... 97
4.3.3
Plánování a rozpočet projektu ............................................................................................ 98
4.4
BARIÉRY A CHYBY NA PROJEKTU ........................................................................................... 101
VÝSLEDKY ............................................................................................................................................ 106 ZÁVĚR .................................................................................................................................................... 108 SEZNAM POUŢITÉ LITERATURY: ............................................................................................................ 113 SEZNAM POUŢITÝCH OBRÁZKŮ A TABULEK: ......................................................................................... 114 PŘÍLOHA Č. 1. ....................................................................................................................................... 116 PŘÍLOHA Č. 2. ....................................................................................................................................... 117 PŘÍLOHA Č. 3. ....................................................................................................................................... 118 PŘÍLOHA Č. 5. ....................................................................................................................................... 120 PŘÍLOHA Č. 6. ....................................................................................................................................... 121 PŘÍLOHA Č. 7. ....................................................................................................................................... 122
5
Úvod Při výběru tématu pro diplomovou práci jsem se snaţil nalézt zadání, které bude dostatečně inspirativní a umoţní mi rozvoj vnímaní podnětů pro práci, kterou vykonávám v zaměstnání. Hledané téma jsem nalezl v zadání „Rozvoj podniku pomocí strategického řízení změn“. Téma mě zaujalo především moţností psát částečně o náplni práce, kterou vykonávám v zaměstnání, ale především mě vybídlo ke studiu materiálů, o kterých jsem byl a stále jsem přesvědčen, ţe mi budou i v budoucnu uţitečné. Proto povaţuji zpracování tématu jako velice přínosné i pro mě samotného. V době výběru tématu jsem byl krátce pověřen vedením transformačního projektu v podniku zaměstnavatele. Cíle tohoto projektu byly natolik zásadní, ţe jsem je povaţoval za strategické. Hlavním posláním celé změny bylo a je přeměna organizace IT sluţeb v oblasti infrastruktury. Celkovým trendem je centralizace řízení sluţeb, správa standardů a rozdělení odpovědností a rolí podle úrovní podpory mezi lokálními a centrálními sloţkami korporace. Napadlo mě, ţe psát o projektu v souvislosti s předmětným tématem mi umoţní vnést do výsledné práce dostatečný vlastní přínos. Dále mě zaujala samotná skladba názvu celého zadání. Rýsuje se v něm několik velmi zajímavých a podnětných pojmů. Prvním z nich je „strategie“ a návazné „strategické řízení“. Druhým pojmem je „změna“ a návazné „řízení změn“. Při propojení obou pojmů mi vytanul na mysli pojem „projekt“ a „projektové řízení“ jako nástroj pro strategické řízení změn. Zmíněné pojmy byly velmi inspirující a pokusit se ukázat jejich vzájemnou souvislost, bylo hlavním podnětem, proč jsem si vybral dané téma. Cíle práce jsem zvolil jak teoretické a metodické, související se zpracováním příslušné literatury, tak cíle praktické, související s průběhem a výsledky probíhajícího transformačního projektu u zaměstnavatele. Prvním metodickým cílem je uvést do souvislostí řízený rozvoj podniku a proces strategického řízení, který je jeho nástrojem. Vnímal jsem tuto oblast jako nedostatečně obsahově zpracovanou ve studijních přednáškách souvisejících předmětů. Proto chci dále navázat na strategii podniku funkční informační strategií pro oblast podniku, ve které působím. Druhým cílem práce je podrobný popis a analýza procesu řízení změn u firmy, jeho model, role, kritická místa a metriky. V předmětné souvislosti jsem se rozhodl metodicky zpracovat i téma nutných měkkých způsobů řízení strategických a zásadních
6
změn, které ze svého principu proces řízení jako takový neobsahuje. V návaznosti na transformační projekt jsem nucen se alespoň krátce zabývat procesem projektového řízení, aby celé téma bylo dostatečně ucelené. Třetím cílem je popis analýzy a průběhu strategického transformačního projektu sloţek útvaru informatiky v podniku zaměstnavatele. Předmětná část obsahuje detailní analýzu historického vývoje a příčin vedoucích ke změně strategie. Pokračuje proces stanovení cílů a formulace strategie a následná implementace transformačního projektu. Vzhledem k charakteru a rozsahu projektu je nutné na závěr zmínit i omezení a chyby na uvedeném projektu. V práci byla pouţita data, která patří do know-how zaměstnavatele, a proto nejsou prezentována jako celek. Při zpracování jsou pouţity jen nezbytně nutné části dat bez souvislostí, které by narušily know-how zaměstnavatele. Pro získání výsledků ze shromáţděných dat jsou v práci pouţity jak metody běţné (analýza, syntéza, komparace, dedukce, indukce aj.), tak metody specifické jako je typová analýza, metodika případových studií apod. Příslušný popis i odkazy jsou v textu.
7
Rozvoj podniku a Strategické řízení V úvodní kapitole si uvedeme do souvislostí základní cíle podnikání a potřebu strategického řízení za účelem dosaţení stanovených cílů. Poznáme fáze ţivotního cyklu podniku, kterými prochází, úskalí a rizika rozvoje, expanze a financování na cestě k maximalizaci zisku. Popíšeme si podrobně proces strategického řízení, z čeho vychází a na jakých základech je postaven. Uvedeme jednotlivé fáze procesu strategického řízení a tvorby strategie včetně výčtu několika specialistům známých metodik. V závěru kapitoly se budeme zabývat tvorbou informační strategie a její návaznosti na ostatní části procesu strategického řízení. V neposlední řadě se v souvislosti s cíli práce pokusíme nalézt odpovědi na otázky: Jak je formulována stávající platná strategie v podniku mého zaměstnavatele? Jak je formulována navazující informační strategie?
1.1 Cíle a život podniku Podniky dle Synka [1] existují proto, aby vyráběly a distribuovaly své výrobky a poskytovaly své sluţby zákazníkům a dále, a to především, aby ‚slouţily‘ všem ostatním, kteří jsou s vývojem podniku spjati. To je jejich hlavním posláním. Podniky ve svém chování sledují určitý cíl, tj. stav nebo výsledek, kterého má podnik dosáhnout. Cíl závisí hlavně na účelu, pro který byl podnik zaloţen a který je důvodem jeho existence. Cílem obecně rozumíme budoucí stav, kterého chceme dosáhnout. Primárním cílem nebo lépe řečeno cílovou funkcí je maximalizace hodnoty podniku. Formy maximalizace hodnoty mohou být různé, stejně jako metody měření pomocí různých ukazatelů, to však není obsahem a cílem práce. Nyní soustředíme svoji pozornost především na otázku ţivota podniku. Podnik, podobně jako člověk, prochází za dobu své existence různými vývojovými fázemi; během ţivotního cyklu postupně prodělává různé nemoci, které jsou-li neléčeny mohou váţně ovlivnit jeho stav i existenci. Aby k tomu nedošlo, musí se včas analyzovat vznikající problémy a včas na ně reagovat. V současné době se mimo podmínky, které přinesla globalizace, podniky potýkají s dopadem světové finanční a následné hospodářské krize. Globalizace přinesla zejména zesílení konkurence a turbulenci prostředí. Hospodářská krize znamenala závaţnou celosvětovou změnu trhů, na kterou 8
byly podniky nuceny reagovat. Dalším výrazným trendem je pronikání informačních technologií do společnosti a hospodářské praxe. Z toho všeho pro podniky plyne, ţe pokud nebudou dostatečně flexibilní a nedokáţí reagovat na změny a úspěšně se s nimi vyrovnat, dostanou se do váţných potíţí, které je mohou dovést aţ k zániku. Rozvoj podniku souvisí s podnikáním. Kromě právního pojetí lze na podnikání nahlíţet jako na proces, který se skládá především ze získávání kapitálu a jeho investování do takové struktury majetku, která vytváří předpoklad pro realizaci myšlenky spojené s výrobou cílového produktu nebo poskytováním sluţeb pro určitý okruh zákazníků na určitém trhu. Graficky znázorněnou podstatu počátku a další existence podniku zobrazuje obrázek 1; vychází z předpokladu, ţe podnik získává dodatečné zdroje pro své financování na kapitálovém trhu.
Obrázek 1. Podstata podnikání vyjádřená prostřednictvím základních účetních výkazů dle [1]. Uvedený fakt znamená, ţe podnik musí na jedné straně získat potřebný kapitál k zaloţení a k dalšímu rozvoji podniku a na straně druhé získaný kapitál vhodně investovat do potřebného majetku. Získaný kapitál se tak přeměňuje v konkrétní majetek (pozemky, budovy, stroje, zásoby atd.), jehoţ struktura a kombinace jednotlivých částí vyplývá z potřeby vytvořit dostatečnou provozní kapacitu a zajistit plynulost reprodukčního procesu; čímţ rozumíme zhodnocení investovaného kapitálu ve formě zisku, ale i k přiměřené likviditě. Podnikání bude mít smysl tehdy, jestliţe investice do podnikání zajistí, ţe hodnota majetku podniku časem převýší původní investici. Samotný ţivotní cyklus podniku a jeho jednotlivé fáze lze vyjádřit např. s vyuţitím modelu D. Millera a P. Friesena viz. obrázek 2.
9
Obrázek 2. Ţivotní cyklus podniku dle [1]. Z modelu jsou patrné základní fáze podniku, kterými jsou: zaloţení, růst, stabilizace, krize a zánik. Cílem manaţerů podniku je, aby při řízení podniku dosáhli stavu, kdy podnik na trhu funguje dlouhodobě. Jejich cílem tedy je udrţovat podnik v cyklickém střídání fází růstu a stabilizace. Schválně jsou zmíněny cíle manaţerů, protoţe cíle vlastníků mohou být odlišné, viz. snaha maximalizovat trţní hodnotu a následně prodat. Krize a zánik potká ty podniky, které včas nereagují na změny. Proces zániku firmy je však nezbytně nutné vnímat ryze z ekonomického hlediska, a to z hlediska zhodnocení investovaného kapitálu. Jestliţe podnik není schopen přinášet investorům přiměřené zhodnocení jejich kapitálu, hledají pro něj takové umístění, které při stejné míře rizika lépe zhodnotí jejich investici.
1.1.1 Fáze založení podniku Před samotným zaloţením podniku a vznikem jeho existence vţdy musí stát úvaha podnikatele a jeho marketingová strategie. Podnikatel po prozkoumání jednotlivých marketingových faktorů, kterými jsou dle metodiky 4(5)P: produkt (product), cena (price), distribuce (place), podpora prodeje (promotion), lidé a prodejní tým (people) musí nalézt odpověď na otázku CO, jaké výrobky bude vyrábět nebo jaké sluţby bude poskytovat. K tomu, aby mohl být výrobní proces úspěšně zahájen a realizován, je však nezbytné vytvořit určité předpoklady, které dle Synka [1] spočívají zejména: 1. Ve věcných předpokladech podnikatelské činnosti, tj. v:
10
zajištění potřebného mnoţství pracovních sil s odpovídající kvalifikací, vytvoření majetkové báze, která zajistí nezbytnou výrobní kapacitu, pořízení materiálu pro zajištění plynulosti výroby. 2. V řídících předpokladech, tj. ve: vytvoření skupiny vrcholového řízení podniku (managementu), zajištění výkonu základních funkcí managementu, tj. stanovení cílů, plánování, rozhodování, realizace, analýza a kontrola, vytvoření nástrojů řízení, vymezení dělby pravomoci a odpovědnosti, vytvoření adekvátní organizační struktury, zajištění kontroly. Formalizovaným dokumentem odráţejícím zaloţení podniku je zakladatelský projekt. Zakladatelský projekt, v závislosti na zvolené marketingové strategii a z ní vycházejícího marketingového mixu, řeší komplexně nejen co a jak vyrábět, ale současně nutně řeší i otázku reálnosti a dostupnosti všech potřebných zdrojů. Výsledkem musí být informace pro podnikatele, zda daný projekt je reálný, proveditelný a jaký efekt mu zajistí z investovaného kapitálu. Přípravě je nezbytné věnovat velkou pozornost zejména proto, ţe investoři přinášející dodatečný kapitál podstupují značné riziko, které musí být patřičně osvětleno. Východiskem je charakteristika podnikatelského projektu pomocí podnikatelského záměru formou zvolené strategie. Strategie musí z tohoto pohledu obsahovat: dobu ţivotnosti projektu, míru zapojení cizího kapitálu, pruţnost a diverzifikace projektu, citlivost na změnu vnějšího prostředí, řízení očekávaných rizik a v neposlední řadě plán postupné realizace projektu. Strategie podniku musí být páteří zakladatelského projektu zabývající se řešením otázky JAK dosáhnout stanovených cílů. Dobrá strategie volí postupy k dosaţení cílů organizace, při kterých se nejlépe uplatní její přednosti (silné stránky). Podnikatel předkládající zakladatelský projekt při jednáních o dodatečném financování, by si měl být vědom předností jím zvolené konkurenční strategie. K tomu je zapotřebí dobrá znalost vnitřního prostředí podniku, jeho silných (převaha) a slabých (zranitelnost) stránek.
11
1.1.2 Fáze růstu podniku Po úspěšném zaloţení podniku obvykle následuje fáze růstu. Konkrétně to znamená, ţe podnik ve zvoleném segmentu trhu zvyšuje objem výroby, prodeje a poskytování sluţeb. Dochází k expanzi podniku a zvyšování jeho konkurenceschopnosti. Jestliţe podnik roste, pak to znamená zájem o jeho výrobky nebo sluţby, management je úspěšný ve své práci a podnik je ziskový. Růst se odráţí v růstu trţeb nebo obratu, obvykle pak vzniká nejen potřeba dodatečných investic do budov, strojů a zařízení k zajištění dodatečné kapacity, ale i potřeba pokrytí přírůstku pracovního kapitálu. Růst podniku však není vţdy stejný. Management podniku je nucen analyzovat podstatu a míru růstu ve vztahu k vnějšímu okolí a vnitřnímu stavu podniku. Podnik v tomto kontextu můţe růst: příliš málo nebo naopak příliš rychle. Růst podniku musí být profinancován. V této souvislosti je zmiňován růst trvale udrţitelný, tj. míra růstu trţeb, při které nevznikají dodatečné nároky na externí financování firmy. Způsob financování růstu podniku musí souviset se strategií podniku a zásadním rozhodnutí o jeho formě; interní zdroje nebo externí zdroje. Z toho potom vycházejí související majetkové a strukturální změny a jejich následný dopad na vnitřní stav firmy.
1.1.3 Fáze stabilizace podniku V průběhu růstu podniku je nezbytně nutné neustále analyzovat a vyhodnocovat vnější a vnitřní vlivy prostředí, ve kterém se podnik nachází. Manaţeři podniku musí s ohledem na tempo růstu, velikost podniku a příleţitosti na trhu volit vhodnou strategii. Odpovědí na zásadní změny vnějších nebo vnitřních vlivů musí být změna zvolené strategie. V této fázi je vhodné podnik alespoň krátkodobě stabilizovat. Fáze stabilizace se vyznačuje shodnou úrovní odpisů a investic, v období růstu investice vţdy rostou rychleji neţ odpisy. Podnik si vybírá oddechový čas, probíhá jeho adaptace na stávající stav a postupně se připravuje na další růst. Fáze stabilizace by měla vţdy nastat, pokud dojde k výrazné změně některého z důleţitých faktorů prostředí, ale i v případě, kdy se nenadále podaří dosáhnout vytyčených cílů a je třeba stanovit cíle nové. Jak jiţ bylo řečeno, pokud podnik flexibilně nereaguje na změny, můţe dojít k jeho zániku. Přechod do fáze stabilizace je tedy rozhodnutím vrcholového managementu. Jako takový je funkcí a odpovědností sloţky řídící práce (managementu).
12
Vhodným příkladem aplikace hypotézy je chování podniků v době celosvětové finanční a hospodářské krize. Podniky, které nejdříve úspěšně stabilizovaly financování svého provozu v závislosti na celosvětový pokles trţeb, mohly nebo mohou pomýšlet na obnovení růstu. Naopak firmy, které nebyly schopné dostatečně stabilizovat svůj provoz a reagovat tak na klesající trţby, se dostaly do problémů a řada z nich zanikla nebo změnila majitele. Vrcholový management je pověřen funkcí řídící práce podniku, řešící základní problémy jeho fungování. Specifickou sloţkou jeho práce je strategické řízení. Jeho prostřednictvím vrcholový management integruje podnik v jeden celek, soustřeďuje jeho síly, vytváří, zjišťuje a upevňuje systémové vazby mezi jednotlivými činnostmi za účelem dosaţení strategických cílů a především zajišťuje dlouhodobý udrţitelný rozvoj.
1.1.4 Fáze krize podniku Aby podnik existoval dlouhodobě, nestačí, aby byl úspěšný pouze po finanční stránce. Je třeba, aby byl trvale orientován na zákazníka a byl schopen mu přinášet trvalou hodnotu. Měnící se potřeby zákazníků se musí odráţet v modifikaci cílů, změně koncepce a načasování nových procesů. V předmětném kontextu se často setkáváme s pojmem reengineering. Jedná se o systém řízení formou projektů, jejichţ hlavním cílem je změna – management řízení změn. Pod pojmem krize podniku lze označit stadium, kdy po delší časové období dochází k nepříznivému vývoji výkonnostního potenciálu. Klesá objem trţeb, likvidita a čisté obchodní jmění. Existence podniku je ohroţena, pokud nedojde k zásadním změnám. Východiskem z krize je sanace podniku. Sanací se rozumí soubor opatření, přijímaných ze strany vedení podniku za účelem ozdravení a obnovení prosperity organizace. Sanace podniku v podstatě znamená nalezení nových východisek pro existenci podniku. Reakcí na krizi je intenzivní uplatnění strategického řízení orientovaného na základní aktiva při stanovení nové strategie podniku, která podnik vyvede z krize, stabilizuje, obnoví a nastartuje další rozvoj nebo povede k úspěšné likvidaci. Pomocí úspěšného byznys plánu lze podnikání přenést na jiné místo, kde o výrobky či sluţby bude zájem. Likvidace a zánik podniku můţe nastat, pokud podnik splnil své poslání, naplnil podnikatelský záměr, za jehoţ účelem byl zaloţen. Podnik zaniká i v případě nezvládnutí krize. V tomto případě před zánikem podnik přechází do fáze úpadku a následného konkurzu. Zánik je z tohoto pohledu především právní akt. 13
1.2 Strategické řízení V předchozí kapitole jsme uvedli, ţe strategické řízení je specifickou sloţkou řídící práce. Jak ale tuto sloţku definovat? Dle Synka [1] je strategické řízení proces, ve kterém vrcholoví manaţeři formulují a zavádějí strategie směřující k dosaţení stanovených cílů, k souladu mezi vnitřními zdroji podniku a vnějším prostředím a k zajištění celkové prosperity a úspěšnosti podniku. Dle T. Mallyi [2] je strategické řízení tvorba a implementace strategie vycházející z analýzy trţní situace vyţadující strategické cítění a myšlení. V souvislosti s uvedenými definicemi se vyskytují pojmy: strategie a strategické myšlení, které je třeba náleţitě osvětlit.
1.2.1 Definice strategie Pojetí strategie je prezentováno v různých zdrojích odlišně. Dle Synka [1] strategie stanoví cesty jak dosáhnout naplnění poslání, vize a cílů. Představuje koncept celkového chování podniku, určuje nezbytné činnosti a alokaci zdrojů potřebných pro dosaţení zamýšlených záměrů. Strategie svou povahou představuje záměry, kterými je ovlivňován věcný rozvoj podniku, např. marketingový mix, záměry týkající se toho, co vyrábět, v jakém mnoţství a kvalitě, kdy a pro koho. Strategie mohou být zaměřeny i na tvorbu metod, nástrojů a opatření, jejichţ pomocí a prostřednictvím jsou prosazovány věcné strategie. Mezi věcnými strategiemi a strategiemi řízení je vzájemná vazba. Dle T. Mallyi [2] je strategie definována jako trajektorie nebo dráha směřující k předem stanoveným cílům, která je tvořena podnikatelskými, konkurenčními a funkcionálními oblastmi přístupu, jeţ se management snaţí uplatnit při vymezování pozice podniku a při řízení celkové skladby jeho činnosti. Strategie je také chápána jako věda o plánování a vymezení směru vojenských akcí a operací. Nicméně strategie můţe mít různé významy pro různé lidi dle jejich postavení v podniku. Často slýcháme, ţe: je to vyjádření o tom , jaký je strategický záměr organizace, určuje a ukazuje důvod dlouhodobých cílů organizace, akční programy a priority alokace podnikových zdrojů,
14
vybírá, do kterého podnikatelského sektoru organizace můţe nebo si přeje vstoupit, je zaměřena na tvorbu a udrţení klíčové kompetence firmy, definuje povahu nebo vlastnost ekonomických a neekonomických přínosů, kterých chce organizace dosáhnout nebo vytvořit pro stakeholdery, snaţí se dosáhnout dlouhodobě udrţitelné výhody v kaţdé obchodní aktivitě tím, ţe reaguje správně na příleţitosti a hrozby v daném prostředí, stejně jako na své silné a slabé stránky, jasně identifikuje manaţerské úkoly na korporátních, obchodních a funkčních úrovních.
1.2.2 Definice strategického myšlení Strategické myšlení není přirozené a musí být většinou naučené. Pro podnik je nutné, je nezanedbatelnou součástí plánování a koncepce podniku, avšak je to stále pouze pomocný prostředek nenahrazující tvůrčí schopnosti člověka. Hranice strategického myšlení neleţí jenom v nejistém plánování budoucnosti, ale i v nevypočitatelnosti lidských emocí. I dobře naplánovaná strategie ztroskotá na faktorech jako je marnivost, nejistota, hlad po moci. Liedtke dle T. Mallyi [2] vytvořil model, který definuje strategické
myšlení
jako
určitý
způsob
myšlení
se
specifickými
a
jasně
identifikovatelnými charakteristikami viz obrázek 3. Vysvětlení pojmů z obrázků je následující: Systémový pohled (perspektiva) – stratég má mentální model celkového systému tvorby hodnot od samého počátku aţ do konce a rozumí souvislostem daného řetězce. Chápe svou roli v rámci celkového systému a dopad svého chování na další části systému a na celkový výsledek. Zaměření na cíle – strategický úmysl poskytuje jedinci ve firmě zvládnout svoji energii k tomu, aby mohl zaměřit pozornost, odolávat rozptýlení a soustředit se tak dlouho, dokud nedosáhne stanovených cílů. Inteligentní oportunismus – je otevřenost vůči novým zkušenostem, které umoţňují jedinci vyuţívat výhody alternativních strategií, jeţ mohou být lepší a relevantní pro rychle se měnící prostředí. To znamená vzít v úvahu názory a podněty z niţších úrovní nebo od inovativních zaměstnanců, kteří mohou být klíčoví při identifikování alternativní přijatelné strategie. 15
Systémový pohled
Zaměření na cíle
Strategické myšlení Inteligentní oportunismus
Myšlení v čase
Hypoteticky založené myšlení
Obrázek 3. Elementy strategického myšlení dle [2]. Myšlení v čase – spojení minulosti, současnosti a budoucnosti vyuţitím paměti organizace a jejího historického kontextu jako kritických vstupů pro tvorbu své budoucnosti. Hypoteticky založené myšlení – schopnost tvorby a testování optimálních hypotéz v rychle se měnícím prostředí s velkým mnoţstvím informací, kdy není čas všechny dostupné informace vyhodnotit a přemýšlet o nich. Schopnost pracovat s hypotézami je klíčovým jádrem kompetence vedení organizace.
1.2.3 Proces strategického řízení Samotný proces strategického řízení vznikl během 60. let a prodělal několik etap v souvislosti s kulturními a ekonomickými změnami, které měly vliv na hlavní aktéry a principy ovlivňující koncepci celého procesu. Celou historií a vývojem jednotlivých škol se nebudeme zabývat. Avšak pro pochopení základu nynější koncepce procesu strategického řízení uvedeme krátké shrnutí etap vývoje v tabulce 1., tak jak jej uvádí T. Mallya [2] a dále se budeme zabývat pouze novodobým výkladem strategického managementu. Ten se vyznačuje sjednocením pojmů strategické řízení a strategie jako dvou sobě rovných sloţek. Současná teorie a výklad je nejvýrazněji ovlivněna publikacemi E. E. Chaffee – Three models of strategy a M. Portera – Competitive Strategy: Techniques for Analyzing Industries and Competitors.
16
Tabulka 1. Shrnutí etap vývoje strategického řízení dle [2]. Chaffee uvádí tvrzení, ţe strategie je vícerozměrná a závislá na konkrétním stavu. Naráţí na sporné otázky tří rozhodných v některých ohledech konfliktních modelů strategie. Těmito modely jsou: lineární model, adaptivní model (model přizpůsobení) a interpretační model. Lineární model – se zaměřuje na plánování, obsahuje rozhodnutí nebo plány, které mají být udělány k dosaţení stanovených cílů organizace. Tyto cíle a způsoby, jak cílů dosáhnout, jsou výsledkem strategického rozhodnutí. Adaptivní model – obsahuje neustálé prozkoumávání vnitřního a vnějšího okolí organizace. Cílem je vytvořit realizovatelnou shodu mezi příleţitostmi na jedné straně a riziky na straně druhé v daném vnějším prostředí organizace, a mezi schopnostmi a zdroji z těchto příleţitostí těţit. Interpretační model – souvisí se sociálními a kulturními aspekty podniku. Strategie sděluje význam pomocí metafor nebo referencí k tomu, aby motivovala všechny zainteresované skupiny v souladu se stanovenými cíli. Hlavní elementy procesu strategického řízení podle Chaffee jsou shrnuty takto, proces strategické řízení: zahrnuje přizpůsobování organizace obchodnímu prostředí, je měnící se a komplexní, změna vytváří nové kombinace situací vyţadující nové reakce a odezvy od vedení firmy, udává směr, kterým organizace půjde, a tím ovlivňuje celé její fungování, zahrnuje formulování a implementaci strategie, je částečně plánovaný, částečně neplánovaný proces, 17
probíhá na několika úrovních řízení od nejvýše k nejníţe poloţeným, zahrnuje konceptuální a analytický proces myšlení. Pan Porter na druhou stranu mluví o konceptu konkurenční strategie do jejíhoţ centra umístil dynamické vztahy mezi strategií podniku a strukturou odvětví. Uvádí moţnost výběru strategie zaloţené na dobře definované pozici obchodní situace v ekonomice. Zaměřil se především na analýzu a její kontext: obsah i proces. Tvrdí, ţe struktura řízení vyskytující se v daném odvětví ovlivňuje řízení firem, coţ má zpětně dopad na jejich výkon.Strategické řízení je dynamický proces pro sladění strategií, výkonnosti a obchodních výsledků organizace. Tvorba strategie tedy podléhá neustálým vlivům a nikdy není konečná. Její součástí je kaţdodenní rozhodování o tom, jak reagovat na vznikající změny v daném prostředí podnikatelského segmentu. Bylo by tedy mylné si myslet, ţe jde o časově omezenou posloupnost jednotlivých kroků zahrnujících tvorbu strategie. Přesto lze pro lepší pochopení dělit proces do pěti fází: identifikace mise, vize a poslání organizace, analýza okolí organizace, formulování strategie, implementace strategie a poslední fází je posouzení a kontrola dané strategie viz. obrázek 4.
18
Obrázek 4. Proces strategického řízení dle [2].
1.2.4 Formulování podnikové vize, mise a podnikových cílů První a zároveň nejdůleţitější fáze strategického řízení zahrnuje identifikaci současných podnikových misí a cílů. Má za úkol zjistit skutečný stav strategického řízení v daném podniku a definovat, čeho chce firma dosáhnout, a určit hlavní důvod její existence. V dostupných zdrojích je formulace pojmu poslání a jeho vztah na ostatní části velmi vágní, přesto se však pokusím odvodit obojí. Poslání – vychází ze zakladatelského projektu a identifikuje základní funkce podniku, smysl jeho existence, vztah k vlastníkům a ostatním zainteresovaným skupinám. Vyjadřuje hodnoty, které podnik zastává. Jedná se o text, ze kterého potom formulujeme vizi a opačně promítáme změny ve strategické vizi do poslání. Oba dokumenty by však měly být v souladu, coţ naznačuje, jaká je úroveň strategického
19
řízení v dané firmě. Jako příklad poslání uvádím podnikatelské principy podniku zaměstnavatele – viz příloha 1. Vize – dle Mallyi [2] definována jako mentální model budoucího stavu procesu, útvaru nebo organizace jako celku. Dobrá vize vytváří pozitivní obraz budoucnosti, která je motivující a dostatečně srozumitelná, aby udala dlouhodobý směr pro plánování, stanovení cílů a pro dobré a silné jméno firmy. Dobrá vize je jasná, srozumitelná, pochopitelná kaţdým, kdo je poţádán, aby se účastnil jejího prosazení, provokující a vyvolává pocit identifikace s firmou. Dobrá vize je krátká a výstiţná – heslo, jedna věta. Příklady vizí: 1. Bezpečná budoucnost pro společnost – podnik volí především stabilitu a reakci na moţná vnější ohroţení. 2. Být hlavním dodavatelem softwarových programů bankovního sektoru – podnik volí především růst na vybraném trhu. 3. Udrţet zvládnutelný počet zákazníků – podnik volí především udrţitelný růst. Mise – nazývána také jako ‚zhmotnělá‘ vize. Jak uţ tento název naznačuje jedná se o dokument, který vychází ze strategické vize a popisuje kodex chování organizace tak, aby vedl k naplnění stanovené vize. Mise udává jasně definovaný směr, kterým se má organizace ubírat a měla by dle Mallyi [2] splňovat následující charakteristiky: 1. definovat současný stav společnosti, 2. být stanovena na klíčové kompetence společnosti, 3. soustředit se na hlavní aktivity společnosti, 4. obsahovat sociálně politické potřeby, kterých chceme dosáhnout, 5. určit naše klíčové stakeholdery (zúčastněné subjekty), 6. vyplývat z naší filozofie, hodnot, etiky a kultury, 7. obsahovat naše přednosti, 8. obsahovat plány, jak dosáhnout strategické výhody. Mise ve své podstatě určuje směr podnikání a vymezuje oblasti, ve kterých si společnost bude následně klást cíle, kterých chce dosáhnout. Obsah mise se dá jednoduše shrnout do otázky, kdo jsme a co děláme? Z tohoto důvodu by měla mise odpovědět na: 1. Zákazníci – kdo jsou zákazníci naší firmy? 2. Produkty – jaký je hlavní produkt firmy? 3. Trhy – ve kterém geografickém prostředí chce firma konkurovat? 4. Technologie – má firma nejnovější technologii? 5. Přeţití, růst a zisk – je firma zaloţena na zdravém růstu a finanční stabilitě? 20
6. Filozofie – jaké jsou základní hodnoty, očekávání a etické priority firmy? 7. Osobní koncept – jaké jsou výjimečné kompetence nebo hlavní konkurenční výhody firmy? 8. Image na veřejnosti – angaţuje se firma v sociálních, společenských a environmentálních problémech v daném prostředí svého působiště? 9. Zaměstnanci – jsou zaměstnanci cennými aktivy firmy? Mise ač patří do první fáze procesu strategického řízení obsahuje reakci na informace získané analýzou, protoţe proces strategického řízení nelze brát jako posloupnost jednotlivých kroků, ale je nutné neustále prověřovat, zda nové poznatky o vnějších a vnitřních faktorech nevyţadují změnu přístupu. Příklady misí: 1. Restaurace: „Chceme být nejlepší a nejrychlejší restaurace ve městě. Budeme poskytovat návštěvníkům lahodné, zdravé a cenově dostupné jídlo při kaţdé jejich návštěvě.“ 2. Firma poskytující veřejné sluţby: „Naší misí je poskytnout veřejnosti spolehlivé sluţby, které nejlépe uspokojí jejich potřeby.“ Cíle – specifické stavy, kterých chce podnik dosáhnout – konkurenční pozice podniku na trhu. Cíl podniku je vytvářet zisk – růst jeho trţní hodnoty. Jak tento cíl realizovat stanovuje právě strategie. Z mise vycházíme při formulování obecných cílů. Obecné cíle se rozvíjejí v cíle konkrétní a oproti nim obsahují následující elementy – SMART: 1. Specifický – kaţdý musí rozumět, čeho přesně a kde chceme dosáhnout. 2. Měřitelný – kolik toho chceme dosáhnout, kvantifikovat pro moţnost kontroly. 3. Akceptovatelný – těmi, kdo ho budou plnit nebo implementovat. 4. Realistický – relevantní a dostatečně ambiciózní, jednoduchý cíl nemotivuje. 5. Termínovaný – časově vymezený, do kdy chceme cíle dosáhnout. Opakem cílů typu SMART (chytrý) jsou cíle DUMB (hloupý) dle Hroníka [3]: 1. Defective –defektní, nedokonalý, nespecifický a nejasný. 2. Unrealistic – málo ambiciózní, příliš náročný a tudíţ neakceptovatelný. 3. Misdirected – nesprávně zaměřený, v rozporu se strategií. 4. Bureaucratic – byrokratický, zatěţující ale nepotřebný. Hroník [3] dále uvádí zajímavá pravidla pro stanovení cílů, se kterými se na základě svých znalostí a praktických zkušeností plně ztotoţňuji: 1. Cíl by měl být pozitivně formulován ve smyslu toho, čeho dosáhnu, nikoli co nechci, co neudělám. 21
2. U cíle je zřejmý přínos (protoţe, abychom) a za kaţdým co (cíl) je čitelné proč (smysl, význam). 3. Cíl musí být rozpracovatelný do dílčích cílů nebo úkolů. Výstupem uvaţované fáze jsou tedy dokumenty poslání, vize a mise a stanovené konkrétní cíle jako podnět pro směr strategické analýzy. Příklady obecných cílů: 1. Chceme se stát vedoucí firmou na trhu. 2. Budeme vedoucí v oblasti technologie v oboru. 3. Staneme se vzorem servisních sluţeb v našem oboru. Příklady konkrétních cílů: 1. Zvýšit celkový zisk ze 2% na 5% během 3 let. 2. Chceme se stát jedničkou na trhu do konce roku.
1.2.5 Analýza okolí organizace Na počátku bych se rád vyjádřil k výše uvedené definici fází procesu strategického řízení. Z průběhu a jednotlivých kroků první fáze procesu je zcela zřejmé, ţe nelze formulovat relevantní vizi, misi, poslání nebo cíle bez alespoň částečné analýzy. Obě fáze se tudíţ vzájemně prolínají a ovlivňují. Vstupem do analýzy jsou jiţ ověřené předpoklady o stavu prostředí v návaznosti na platnou strategii. Celý proces tudíţ předpokládá, ţe podnik jiţ nějakou strategii formulovanou má a analýza slouţí k ověření, zda stávající strategie můţe být nadále platná, nebo zda se vyskytly natolik významné změny, ţe musí být upravena. Analýzu je moţné provádět pomocí velkého mnoţství různých metodik. Jednotlivé názvy metodik nebo jejich krátký popis uvádím do souladu s oblastí, kterou dané metodiky pomáhají analyzovat. Odkaz na jednotlivé metodiky slouţí pouze jako příklad pro případného zájemce o hlubší studium této oblasti. Zkvalitnění procesu tvorby strategie předpokládá včas identifikovat pozitivní i negativní důsledky dosavadního vývoje. V souvislosti s analýzou mluvíme o monitoringu okolí firmy, čímţ rozumíme neustálé vyhodnocování klíčových faktorů ovlivňujících firmu a v případě potřeby aplikaci nápravných opatření. Synek [1] hovoří o moţnosti vymezit dva okruhy strategické analýzy: analýza vnějšího okolí podniku, analýza vnitřních zdrojů a schopností podniku. 22
Mallya [2] hovoří o oblastech třech: analýza vnějšího (obecného, širokého) okolí – mezinárodní události, národní okolí zahrnující rozbor společenských, legislativních a hospodářských trendů a dále zkoumající politické, technologické a ekologické faktory. Metodiky SLEPTE nebo TEMPLES, analýza konkurenčního (oborového) oboru organizace – vliv odběratele, vliv dodavatele, stav soupeřivosti v oboru, hrozba náhraţek, stav moţného vstupu nových firem do oboru – viz Porter – pětifaktorový model konkurenčního prostředí, analýza interního okolí podniku – současné postavení firmy: faktory technického rozvoje, marketingové a distribuční faktory, výrobní faktory a řízení výroby, faktory podnikových a pracovních zdrojů, faktory finanční a rozpočtové – metodika 12M. Uvedené analýzy zkoumají jednotlivé faktory odděleně. Sjednocující pohled na stav organizace můţe dát analýza hodnotových řetězců (Value Chains Analysis). Je cestou k vymezení strategických výhod a nevýhod všech činností, jeţ vytváří výsledný produkt. Měří se přidaná hodnota jednotlivých činností a marţe. Činnosti lze ve výsledném přehledu rozdělit do dvou oblastí na: 1. Primární aktivity – týkají se hmotného vytváření produktu, distribuce, prodeje a následném servisu. 2. Podpůrné aktivity – infrastruktura, řízení lidských zdrojů, technologický vývoj a nákup vstupů. Základním podpůrným nástrojem však stále zůstává SWOT analýza zkoumající vnější oblast potencionálních příleţitostí (Opportunities) a hrozeb (Threats) a oblast potencionální vnitřní síly (Strengths) a slabin y (Weaknesses). Jiné analytické modely se zabývají především hodnocením strategické pozice jednotlivých produktů firmy na trhu. Patří sem: model BCG (Bostonská matice), matice atraktivity trhu a konkurenční pozice, model PIMS (The Profit Impact of Market Strategie model), matice politiky směru, matice zralosti odvětví a konkurenční pozice, matice Barksdale a Harris – portfolio analýza / ţivotní cyklus produktu.
23
Výsledky provedené analýzy představují podklady pro určení sjednocujících zdrojů konkurenční výhody a vymezení konkurenční pozice podniku jako východiska pro následnou formulaci strategie.
1.2.6 Formulace strategie Formulace strategie na základě výsledků strategické analýzy spočívá ve zpracování variant a následném postupném výběru vhodné strategie. První a nejzákladnější výběr je mezi růstem, stabilizací nebo omezením některé aktivity podniku. Po tomto výběru je na základě slabých a silných stránek společnosti moţné přistoupit k formulaci strategie. Strategie je nejdříve formulována pro úroveň celého podniku (tzv. Globální strategie) a následně rozpracována pro jednotlivé strategické podnikatelské, popřípadě funkční jednotky do dílčích strategií. Výsledkem je integrovaná hierarchická strategie o několika úrovních. Tato fáze dále zahrnuje soubor rozhodnutí o alokaci zdrojů a způsobu jejich vyuţití. Stratégové usilují o to, aby: sjednotili strategii s posláním, vizí a misí organizace, popřípadě předmětné dokumenty vytvořili nebo upravili, ustanovili dlouhodobé cíle k dosaţení mise a vybrali takovou strategii, která umoţní jejich dosaţení, identifikovali externí příleţitosti a hrozby a určili interní silné a slabé stránky, rozhodli o způsobu alokace zdrojů, určili, zda bude organizace expandovat, diverzifikovat či rušit některé aktivity, jakou formou to provede, tj. formulace cesty k cíli. Výsledná strategie musí být samozřejmě formálně přijata, prezentována, a pokud se jedná o zásadní změnu, musí dojít k proškolení pracovníků, kteří budou vybranou strategii uplatňovat. Uveďme si a částečně vysvětleme základní modely podnikové strategie. Model podnikové strategie podle Milese a Snowa – čtyři typy společností: 1. Prospectors – (hledači) značně diverzifikované společnosti, vyšší sklon k riziku, ochota zkusit cokoliv, co bude vynášet – př. Gogole. 2. Analysers – (analyzátoři) snaha racionálně vyvaţovat riziko, důkladná analýza, imitují hledače při vstupu na nové trhy – př. Microsoft. 3. Defenders – (obránci) averze k riziku, omezená oblast činností, odvětví nebo produktů – př. Coca-Cola. 24
4. Reactors – (reaktoři) imitace chování ostatních hráčů v odvětví, neefektivní, chybí pravděpodobně strategie nebo je zastaralá. Model základní (generické) strategie dle Portera se dělí na: 1. Cost leadership – (strategie vedoucího nákladů) pro trh s jednoduchými výrobky, které lze lehce vyrobit a konkurovat jim. Snaha o co nejniţší cenu cestou dosaţení nákladové výhody. 2. Differentiation – (odlišení) pro trh s vysoce hodnotnými a velmi rozdílnými výrobky. Snaha o vytvoření něčeho výjimečného a tím vytvořit pocit monopolního postavení. 3. Focus – (zaměření) segmentace trhu a výběr zvoleného segmentu. Snaha o cílené vytvoření něčeho na míru pro daný úzký segment. Strategie stability: 1. Strategie udržení – udrţet současný podíl na trhu pokud trh roste. 2. Strategie sklízení – maximalizace krátkodobého finančního toku, výnosy větší neţ náklady, vhodné při rozhodnutí o odchodu z trhu. Ansoffova matice: 1. Penetrace trhu – současný trh a produkt, snaha o zvýšení trţeb, reklama a sníţení ceny. 2. Rozvoj trhu – existující výrobek na nový trh. 3. Rozvoj produktu – nový výrobek na stávající trh, inovace nebo nahrazení stávajícího modelu výrobku, sledován ţivotní cyklus výrobku. 4. Diverzifikace – zcela nové produkty na nové trhy, vhodné pro novátory. Výstupem sledované fáze je formulovaná strategie na potřebných úrovních a podklady pro vypracování strategického plánu, aby bylo moţné strategii úspěšně implementovat. Strategický plán můţe být zpracován např. formou ‚akčních hypotéz‘ podle metodologie akčního výzkumu.
1.2.7 Implementace strategie Formulování strategie je podnikatelská záleţitost a je převáţně věcí top managementu a jeho kreativity. Oproti tomu její implementace a prosazení se jeví jako administrativní úkol vyţadující disciplínu, schopnost plánovat, motivovat, kontrolovat a odstraňovat vhodně problémy, které se vyskytly na cestě k cíli. Proto pro implementaci strategie je na základě znalostí i zkušeností vzhledem k rozsahu, náročnosti a dopadu na podnik 25
nejvhodnější projektový management. Přesto tomu tak u většiny podniků ve střední Evropě dosud není. Hlavní důvod shledávám v rozporu mezi základními poţadavky projektového managementu na jasně specifikované a měřitelné cíle a na druhou stranu mnohdy velmi fádně formulovanou strategii, která dané charakteristiky postrádá. Další příčinou můţe být neochota delegovat pravomoci spojené s implementací zásadního projektu na projektového manaţera, management by se musel podřídit. Zkušenosti z USA ukazují, ţe problémem je i osoba manaţera – nyní je v USA manaţerem osoba s odbornou znalostí a letitými zkušenosti, která má schopnost jednat s lidmi a postupem doby si doplní manaţerské praktiky. Tento trend se ještě ve střední Evropě neuplatnil, a proto je většinou vyuţívána pro implementaci strategie liniová struktura společnosti. Jedním ze základních nástrojů implementace je potom pouţívání strategického vůdcovství. Vůdce (manaţer) musí mít integritu a konzistenci. Je oporou a vzorem pro chování jemu podřízených zaměstnanců. Vůdce buduje a vytváří vztah důvěry v podřízené (delegování), posiluje sounáleţitost (tým) a překonává bariéry (stavba mostů) uvnitř organizace. Strategie má zásadní vliv na organizační strukturu podniku, která by měla odpovídat jednotlivým odpovědnostem vyplývajícím z dílčích strategií a vzájemně si neodporovat. Organizační struktura musí podporovat plnění podnikových cílů a přenášet potřebné pravomoci na jednotlivé útvary tak, aby ve výsledku byla odpovědnost a z ní vyplývající role konzistentní s pravomocemi ovlivnit plnění úkolů. Proces implementace strategie je dále ovlivňován nebo můţe mít za cíl ovlivnit firemní kulturu, manaţerskou etiku a motivační systém. Vyţaduje jasnou alokaci zdrojů, a to hmotných i nehmotných, jako jsou technologie, lidské zdroje a reputace. To vše má vliv na tvorbu strategického plánu. Samotná implementace vyţaduje podporu od informačního systému a vytváří nové poţadavky, které musí informační systém splňovat, aby integroval vize managementu, okolí, interní procesy, pouţívané technologie a metodiky. Strategický plán tedy interpretuje schválené strategie ve smyslu vedení organizace a spouští v jednotlivých podnikatelských nebo funkčních jednotkách specifická opatření.
26
1.2.8 Hodnocení a kontrola strategie Hodnocení je procesem, kterým se snaţíme zjistit, zda uskutečňované aktivity jsou v souladu s očekáváním. Kontrola se snaţí zajistit odstranění odchylek od cílů v chování zaměstnanců, odměňuje a posiluje aktivity, které vedení vyţaduje. Důleţitým nástrojem je vhodný kontrolní systém, který umoţňuje měřit výkonnost organizace ve vztahu k definovaným cílům a srovnávat očekávané výsledky se skutečnými. Bohuţel v mnoha společnostech existuje kontrolní systém, který však nemá stanovené kvantitativní a kvalitativní parametry. Takový systém má velmi nízkou vypovídací hodnotu a nevyvolává opatření vedoucí k nápravě, protoţe není vhodně definován poţadovaný stav. Kvantitativní a kvalitativní kritéria jsou nezbytnou součástí efektivního kontrolního systému, podporujícího účinnou evaluaci strategie. V neposlední řadě je vhodné se zabývat otázkou monitoringu evaluace strategie pomocí vhodně nastaveného informačního systému. Odpovídající informační systém na základě definovaných poţadavků a měřitelných kritérií můţe sám sledovat a včas upozorňovat na uţitečné informace o stavu organizace.
1.3 Informační strategie podniku V souvislosti s cíli diplomové práce se na závěr kapitoly zaměřím na informační strategii podniku a její význam pro řízení, rozvoj a provoz informatiky v podniku. Hlavními činnostmi útvaru informatiky podle Gáli, Poura, Tomana [4] jsou: 1. Řízení IS/ICT – strategické řízení IS/ICT; plánování a koordinace projektů, řešení vztahů s dodavateli a zákazníky/uţivateli; plánování finančních, personálních, datových a technologických zdrojů; řízení provozu. 2. Rozvoj aplikací a technologií – řešení projektů; analýza a návrh obsahu projektů, specifikace programových modulů a technologií, programování+ testování+ dokumentace řešení. 3. Provoz aplikací a technologií – zajištění provozu na serverech a koncových stanicích uţivatelů; provoz počítačových sítí, technických a softwarových prostředků a databází; údrţba a dokumentace provozu. Z uvedeného vyplývá, ţe řízení informatiky souvisí se strategickým řízením podniku. Cílem strategického řízení informatiky je dosaţení jejího racionálního dlouhodobého rozvoje ve vazbě na strategické a podnikatelské záměry společnosti, ve snaze integrovat
27
IS/ICT podniku s okolím a interními procesy v poţadované kvalitě. Kvalita informačního systému je vyjádřena úrovní a dostupností poskytovaných sluţeb širokému spektru uţivatelů. Hlavní náplní strategického řízení IS/ICT je proces formulace, uplatňování a periodické aktualizace celkové koncepce tj. informační strategie. Informační strategie je tedy jednou z funkčních strategií podniku, hierarchicky navazující na globální strategii organizace. Vstupem pro tvorbu nebo aktualizaci stávající informační strategie jsou: globální strategie podniku a z nich odvozené cíle a priority pro informatiku, analýza současného stavu IS/ICT v podniku, stav IS/ICT u konkurence, stav IS/ICT u hlavních partnerů, trendy na trhu IS/ICT, dostupné ASW na trhu, výsledky BPR nebo SWOT analýzy oblasti informatiky, poţadavky uţivatelů. Výstupem je nová nebo aktualizovaná informační strategie podniku ve formě globální architektury IS/ICT. Na ni pak navazují případně další dokumenty zabývající se dílčími architekturami a aspekty: aspekty – personální a sociálně etické, organizační a legislativní, architektury – hw, sw, technologická, datová, funkční a procesní.
1.4 Stav strategického řízení v podniku zaměstnavatele Podnik zaměstnavatele je významným hráčem v oblasti maloobchodu potravin a spotřebního zboţí v evropském měřítku. Z toho vyplývá, ţe se jedná o společnost s nadnárodním charakterem a silnou vazbou na mateřskou organizaci. Zmíněná silná vazba se projevuje různou úrovní centralizace jednotlivých procesů a rozhodovacích pravomocí. Autor pracuje na pozici, která mu zajišťuje pouze zprostředkovanou znalost strategických materiálů. Pracuji ve společnosti přes 8 let v oblasti IS/ICT. Vzhledem ke svým minulým zkušenostem s nesnadnou identifikací cílů jednotlivých útvarů a snahy z nich odvodit poţadovanou úroveň dostupnosti a kvality sluţeb se domnívám, ţe stav strategického řízení v podniku nebyl v prvních letech působení dostatečný. Byla zřejmá 28
absence prezentace jasných cílů strategie na niţší úrovně řízení, pokud v té době nějaká strategie vůbec existovala. K určitým změnám došlo v posledních 3 – 4 letech po personální obměně představenstva. Z probíhajících změn lze odvodit následující prosazované strategie: 1. Centralizace strategického řízení - Je cíleně budována oddělená mezinárodní organizační struktura podniku, která se snaţí být nezávislá na původní mateřské společnosti. Nová struktura postupně zahrnuje role pro řízení a koordinaci nadnárodních aktivit ve všech významných funkčních jednotkách společnosti. 2. Stabilní růst – Podnik expanduje na stávajících trzích a standardním tempem investic se snaţí udrţet, popřípadě zvýšit podíl na trhu počtem prodejen, nabízeným sortimentem a cenou. Podnik má dostatečné finanční zdroje, přesto však za stávající situace nevstupuje na nové trhy. Vyčkává, jak se bude situace na trzích vyvíjet v souvislosti s všeobecným poklesem trţeb v maloobchodu a bude se snaţit vyuţít případných problémů ostatních společností především na domácím trhu (Německo 2009-2010: převzetí cca 20 prodejen Karstadt po zkrachovalém Arcandoru a cca 40 prodejen společnosti Lupus). 3. Vytvoření a prosazování týmové kultury – Podnik vypracoval motivující obraz budoucí firemní kultury zahrnující hodnoty, vzory správného jednání a zásady manaţerského vedení. Důleţité bylo, ţe s ‚týmovou kulturou‘ byl seznámen kaţdý zaměstnanec formou půldenního workshopu, Kaţdý zaměstnanec obdrţel 20-ti stránkovou broţuru, ve které je na závěr uvedeno i 7 výstiţných hesel tzv. zásad jednání. Projekt měl neuvěřitelnou podporu z představenstva, v prvních měsících byly za neplnění termínů v tomto projektu a za jednání v nesouladu s poţadovaným vzorem vyměněni 3 ředitelé národních organizací (ze 6-ti). Projekt trval cca rok a na jeho závěr byla provedena anonymní anketa nezávislým institutem. Anketa a hodnocení výsledků se po 2 letech opakovaly. Výsledky mi nejsou známé, ale průběh a podpora mě osobně velmi potěšily. Nastartované změny se z mého pohledu daří naplňovat. Jedním z dalších projektů byla snaha o zajištění lepších sluţeb pro zákazníka – heslo: ‚budeme nejpříjemnějším místem pro nákup‘ se nedaří plnit ve všech zemích stejně. Tato změna měla obsahovat pro české prostředí velmi zajímavé rysy, které by určitě přinesly pozitivní ohlas zákazníků. 29
Pro posouzení uvádím, jakým způsobem toto funguje u mateřské společnosti v Německu, ale setkal jsem se s tímto jednáním i v Rumunsku: 1. Bezproblémová reklamace, ţádné otázky a komentování, peníze zpět! 2. Na pokladně mimo pozdravu (ten je snad běţný) se po namarkování všeho zboţí pokladní zeptá zda bylo vše v pořádku, potom teprve vyjede účtenku, pokud platíte kartou pokladní se podívá na jméno a potom Vám jménem popřeje pěkný den, víkend, atd.…, no nebylo by to příjemné i u nás? Pro doplnění, u konkurence v Česku (Tesco) jsem při nákupu zaplatil za produkt o 200,CZK více neţ bylo avizováno na regálu. Při reklamaci mi nejdříve řekli, ţe to není moţné a následně jsem musel jít jako poskok tento nesoulad ukázat a dokázat. Potom zaměstnanec obvolal několik dalších zaměstnanců, vynadal jim, a se slovy ‚to je zase "bordel" jako vţdycky‘ mi vrátil peníze. Podprahové sdělení, ţe je v Tescu nepořádek mi samozřejmě v paměti uvízlo do dnes. Vedle toho jsou proklamovány tzv. podnikatelské principy – viz. příloha 1. Tyto principy bych vzhledem k jejich obsahu chápal jako poslání podniku. Jde o dlouhodobé a trvalé hodnoty, které neobsahují vizi o nových cílech společnosti. Ve vztahu na poslání podniku byly vypracovány tzv. IT principy – viz. příloha 2. Informační strategie v současnosti odpovídá těmto principům. K jednotlivým bodům uvádím krátký komentář: 1. Centralizace – vytvoření samostatného německého IT/ITC. 2. Bezpečnost – společnost provádí cílený externí audit s komplexními dopady od standardů datových center přes úrovně oprávnění v ERP systému aţ po identity management. 3. Standardizace – snaha o maximální prosazení jednotné hw, sw, datové a technologické architektury. 4. Standardizace – snaha o maximální sjednocení funkčních procesů, rozumíme pouze IT/ICT procesy. Uplatňována metodika ITIL – jednotný incident, change a release management. Projekt ‚týmové kultury‘ se samozřejmě týkal i oblasti IT/ICT. Stabilizace a optimalizace procesů a zdrojů je (bude) realizována pomocí transformačního projektu. Rozbor předmětného projektu je cílem předloţené práce a více o něm naleznete v kapitole 4.
30
Shrnu-li své poznatky o strategickém řízení, které jsem získal studiem magisterského programu ‚Informační technologie a Management‘ za poslední dva roky a metodickou přípravou pro psaní diplomové práce, mohu konstatovat, ţe uvedené znalosti mi zásadně usnadnily vnímání a pochopení určitých změn v podniku zaměstnavatele. V prováděných změnách je zřetelně vidět provázanost jednotlivých strategií. Úroveň strategického řízení proto shledávám jako dobrou, vzhledem k tomu, ţe však nemám srovnání se stavem v jiné společnosti a nemám informace o dosaţených výsledcích jednotlivých projektů, nemohu a ani nechci vynášet soud o kvalitě strategického řízení a kvalitě strategie.
31
2 Řízení změn V předchozí kapitole jsme se zabývali pojmy strategie a strategické řízení. Chápeme jiţ význam strategického řízení pro budoucnost podniku a všechny jeho aktivity. Strategické řízení je kontinuální proces s vstupy, jednotlivými fázemi a výstupy. V předmětné kapitole si přiblíţíme problematiku zavedení změn v podniku. Pokusíme se o podrobný popis a analýzu stávajícího procesu řízení změn u firmy zaměstnavatele. Sestavíme jeho model, role, kritická místa a metriky. Uvedeme si změny v procesu způsobené adaptací na prostředí vzniklé působením transformačního projektu. Dále se budeme zabývat nejčastějšími chybami při zavádění změn a popíšeme doporučované pořadí kroků pro úspěšné nasazení nových strategií v organizaci.
2.1 Strategie řízení změn v podniku V první kapitole jsme si podrobně popsali proces strategického řízení. Pokusíme-li se shrnout význam celého procesu pro podnik do jedné věty, mohla by znít například takto: strategické řízení je kormidlem podniku řídící loď (podnik) ke stanovenému cíli a po stanovené cestě. Co by však bylo kormidlo bez lodního šroubu a sloţitého soustrojí, které zajišťuje pohyb vpřed po vybrané trase? Bylo by jen pouhou hračkou odtrţenou od reality. Význam uvedené slovní hříčky spočívá především ve snaze poukázat na fakt, ţe samotné strategické řízení k tomu, aby bylo úspěšné, potřebuje další nezbytné nástroje, kterými jsou především: řízení změn (change management), projektové řízení (project management). Projektovým řízením se budeme zabývat ve třetí kapitole, tudíţ nyní přejdeme k řízení změn. Z pohledu dnešní doby, kdy počet významných a velmi často traumatizujících změn rapidně roste v důsledku turbulence globálních ekonomických faktorů, se situace pro podniky jeví následovně. Mnoho podniků je nuceno přehodnotit své zaběhnuté postupy a vydat se do neznámých vod. Všeobecná snaha o sníţení nákladů a zvýšení kvality produktů a sluţeb vyvolává silnou potřebu změny. Ani dobrá strategie nezaručuje automaticky úspěch, pokud není správně a důsledně prosazována. Kotter [6] pojmenovává osm nejčastějších chyb při zavádění změn: 32
připuštění přílišné samolibosti, selhání při vytvoření dostatečně silné vedoucí koalice, podcenění síly vize, nedostatečně komunikovaná vize, nebourání bariér, které brzdí novou vizi, selhání při vytváření quick-wins, deklarování vítězství a dosaţených cílů příliš brzo, zanedbání pevného ukotvení dosaţené změny ve firemní kultuře. Jednotlivé chyby si nyní blíţe vysvětlíme. Přílišná samolibost managementu nebo organizace samotné vede k následující situaci. Problém je známý a všichni o něm víme, avšak chybí dostatečné pochopení významnosti nebo lépe řečeno urgence nutnosti změny. To vede pracovníky podniku k defenzivnímu chování a vyvolání úzkosti, která má za následek rezistenci vůči změně. Slabá vedoucí koalice změny nemá v podstatě šanci na provedení změny, i kdyţ je změna
v podniku
všeobecně
chtěná.
Nedostatečná
kompetence
týmu
nebo
nezainteresovanost top-managementu odsuzuje celý projekt změny k záhubě. Slabá vize značně ztěţuje prosazení projektu změny, neboť znesnadňuje chápání obsahu a smyslu stanovených cílů. Zaměstnanci se nemají čeho chytit a nemohou se názorově ukotvit ve snaze vytušit, co se po nich očekává. Komunikace vize je klíčovým faktorem úspěchu. I dobrá vize, pokud není správně a dostatečně komunikována a vysvětlena, selţe. Komunikace musí probíhat slovy i činy a působit konzistentně. Bariéry změny nelze připustit nebo obejít. Pokud připustíme existenci bariér, které měla změna zbourat, způsobujeme tím nekonzistenci proklamovaných cílů a skutečnosti. To vede k podkopání důvěry v danou změnu a v oslabení zaměstnanců, kteří obrazně narazí. Quick-wins je nutné systematicky plánovat. Prováděná změna musí v krátkém časovém horizontu vyprodukovat malá vítězství, která ji zajistí podporu a případné prostředky aţ do konce. Tato malá vítězství umoţňují projekt změny chápat jako úspěšný a pomáhají podniku vytrvat v jeho provádění. Naopak změna bez malých vítězství můţe být velmi brzo vnímána pouze jako přebytečná aktivita, která stojí podnik čas a peníze.
33
Proklamace vítězství je v celém projektu ošidná záleţitost. Jakkoliv se můţe zdát vhodné oslavit první důleţité dokončené změny, má tato událost za následek vyvolání pocitu, ţe práce je v podstatě hotová. To je však pro mnoho změn osudná chyba. Poslední, ne však nejméně významnou chybou, je zanedbání při ukotvení přijatých změn do firemní kultury. Ač přijatá, stává se neukotvená změna obětí jisté koroze. Pomine tlak spojený s jejím prosazením a její význam postupně degraduje aţ nakonec úplně vymizí z podnikové sociální sféry. Kaţdá z uvedených chyb při zavádění změn můţe ve svém důsledku způsobit následující: nové strategie nejsou správně zavedeny, nové akvizice nesplní očekávání z budoucí vzájemné podpory, reengineering trvá moc dlouho a je příliš nákladný, programy pro zavedení kvality nebo úspory nákladů nesplní své cíle. Kotter [6] identifikuje čtyři základní síly z ekonomické a společenské oblasti, které způsobily globalizaci trhů a konkurence: technologická revoluce v komunikaci a dopravě; informační sítě (internet), mezinárodní ekonomická integrace – přehlednější tarify, cla, plovoucí měny, globální kapitálové toky, vyzrálost trhů ve vyvinutých zemích – pomalejší růst domácího produktu, agresivnější export, niţší míra regulace, pád komunismu – privatizace a více zemí s kapitalistickým systémem. Globalizace má za následek zásadní změnu vnějšího okolí podniku v oblasti hrozeb (větší konkurence, rychlost proměny trhů) a příleţitostí (větší trhy, méně bariér). To vyvolává silnou potřebu významné a zásadní změny v organizaci. Typická transformační změna obsahuje: reengineering, restrukturalizaci, program kvality, slučování uvnitř podniku nebo akvizice, změnu strategie, změnu firemní kultury. Náročný úkol vyvolává potřebu pouţití nástrojů, které jsou schopné zajistit úspěch celého snaţení. Vhodným nástrojem je vědomě řízený proces řízení změn v podniku. 34
V následujících podkapitolách se budeme zabývat procesem řízení zásadních (strategických) změn v podniku a následně ve specifické funkční jednotce podniku jakým je útvar IS/ICT.
2.2 Proces řízení zásadních změn v podniku Zásadní změny nebo chceme-li strategické změny mají společné rysy, co do významu, dopadu, délky trvání a nákladnosti. Mají zásadní význam pro podnik a mnohdy významně ovlivňují jeho samotnou existenci. Mimo nutnosti dosahovat jednotlivých vytyčených cílů, nesmíme zapomínat na samotný způsob, jakým změnu zavést. V minulé podkapitole jsme si uvedli nejčastější chyby při zavádění změn, kterých je nutné se vyvarovat. Obrazem pro správné a úspěšné zavedení změny bude tedy jednání opačné. Kotter [6] ve své knize propaguje ‚osmi stupňový‘ proces vytvářející úspěšnou strategickou změnu. Jednotlivými stupni se rozumí následující postupné kroky: vytvoření pocitu naléhavosti změny, vytvoření vůdčí koalice, vývoj vize a strategie, komunikování vize změny, posílení zaměstnanců pro podporu rozsáhlých akcí, vytváření quick-wins, upevňování výsledků a vytváření prostoru pro další změny, zakotvení dosaţených výsledků ve firemní kultuře. V tomto procesu je zásadní řídit se sekvenčním provedením jednotlivých kroků. Podnik je povaţován za ţivý organismus a je třeba dostatečného času, aby si i poslední jeho části prošly jednotlivými fázemi. Dalším důleţitým faktorem pro změnu je uplatnění vůdcovství namísto řízení. Kotter [6] definuje rozdíl mezi řízením (management) a vůdcovstvím (leadership) následujícím vztahem – viz obrázek 5. Z obrázku 5 vyplývá, ţe uplatnění vůdcovství je nezbytně nutné pro prosazení zásadních změn s uplatněním v dlouhodobém horizontu. Projděme si jednotlivé fáze procesu a jmenujme si jejich klíčové činnosti, abychom jednotlivým krokům lépe porozuměli.
35
Obrázek 5. Management versus Leadership dle [6]. Naléhavost změny je počáteční fází celého procesu. V ní je zásadní navodit pocit naléhavosti a potřeby změny. Kotter [6] dokonce mluví o jistém vykolejení organizace z běţného provozu a navození pocitu krize. Pocit moţné krize má za následek nabourání samolibosti podniku z jeho stávajících výsledků. Mluví o celkovém duchu v podniku, který můţe být charakterizován větou: ‚máme svoje problémy, ale není to tak hrozné‘. Krize vyvolá potřebu změny a odbourá bariéry ve formě rezistence v samotných zaměstnancích z něčeho nového a neodzkoušeného. Ve chvíli, kdy organizace krizi vnímá, je zralá na provedení změny a můţeme přejít do další fáze. Vůdčí koalice potřebná pro vedení podniku ke změně musí obsahovat správné lidi, kteří si vzájemně důvěřují a věří v danou změnu a mají společný cíl. Krátce a jednoduše řečeno. Ustavit takovou koalici však není jednoduchý úkol. Správnými lidmi se rozumí lidé s dostatečně silnou pozicí v organizační hierarchii, vysokým kreditem, znalostmi, rozhledem a expertními dovednostmi. Lidé s vůdčími a řídícími dovednostmi, kteří si budou vzájemně věřit a budou věřit v provedení toho, co mají provést. Budou pracovat jako tým. Vůdčí tým v další fázi vytvoří vizi a strategii změny. Charakteristiku a důleţitost dobré vize jsme zmiňovali v kapitole 1.2.4., proto se jí nebudeme zabývat. Vize změny je její neodmyslitelnou součástí a bude jejím průvodcem při jejím naplňování. Komunikování vize je dalším nezbytným krokem před tím, neţ započneme samotnou změnu naplňovat. Klíčové elementy při efektivní komunikaci vize jsou dle Kottera [6]: jednoduchost; pouţívání metafor, analogie a příkladů; různé komunikační kanály; opakování; vedení příkladem; objasnění zdánlivých nekonzistencí a zpětná vazba. Pokud jsou všichni pracovníci seznámeni s vizí a nutnou změnou je třeba začít jednat.
36
Je důleţité jednat a nezastavit se před ničím, co stojí v cestě naplnění vize. Odstranit bariéry neboť jejich připuštění by podkopalo důvěru v naplnění vize změny. Bariéry je nutné odstranit v organizační struktuře, jde o přerozdělení pravomocí dle potřeby a nově definované odpovědnosti. Podporovat zaměstnance, kteří se snaží naplňovat změnu a konfrontovat jejich nadřízené s nutností změny v nich samotných. Quick-wins v průběhu procesu naplňování změny musí být plánované a opakované. Charakteristické pro dobrou quick-wins je následující: je viditelná a velký počet lidí vidí její reálné výsledky, je jednoznačná, je viditelně spojená s procesem změny. Dosaţení prvního quick-wins a jejich periodicita se řídí velikostí podniku od 6 do 18 měsíců. Role je zřejmá, quick-wins podporují a upevňují pocit, ţe podnik provádí potřebnou změnu správným směrem a navíc je veden správnými lidmi. Další fáze je celkově nejdelší v celém procesu a je třeba uplatňovat její techniky v celém průběhu. Celkovou změnu chápeme jako multi-změnu, která vyţaduje celou řadu malých či větších změn. Vyuţívanou technikou je využití dosažených výsledků pro další větší změny. V podstatě se jedná o navázání na quick-wins a vytvoření dostatečného potenciálu pro generování dalších a rozsáhlejších změn. Zapojíme do procesu změny více lidí, kteří se stanou nositeli změny. Uplatníme vůdcovství a projektové řízení při plnění jednotlivých specifických cílů. V neposlední řadě redukujeme nebo přímo eliminujeme vzájemné závislosti jednotlivých částí změny. Jedině tak dosáhneme úspěšné transformace podniku. Závěrečnou samostatnou etapou je zakotvení dosažených změn ve firemní kultuře. Rozumíme tím nejenom vytvoření potřebných dokumentů, jako jsou různé směrnice a organizační pokyny, ale pokud se na změnu podíváme z pohledu strategického řízení, musí být průkazné, ţe výsledný stav je v kontextu s posláním, vizí a misí podniku. Pouze takový výsledek je z dlouhodobého hlediska udrţitelný a po dlouhou dobu přenositelný i na nové zaměstnance. Proces řízení zásadních změn doplňuje fáze procesu strategického řízení, které definují ‚CO‘ dělat o způsob, tedy ‚JAK‘ to dělat. Jedná se tudíţ o odpověď na otázku, jak úspěšně provádět strategické řízení v podniku.
37
2.3 Proces řízení změn v oblasti IT/ICT V minulé podkapitole jsme se zabývali činnostmi spojenými s řízením změn v podniku. Uţ z jejich popisu je zřejmé, ţe se jedná o činnosti velmi neformální a vyţadující vysokou kreativitu vůdčích osobností změny. Oproti tomu, řízení změn ve specifickém funkčním útvaru, jakým je IS/ICT vyţaduje vysokou míru formalizace celého procesu. V kapitole 1.3. jsme definovali obsah řízení IS/ICT jako: strategické řízení IS/ICT; plánování a koordinace projektů, řešení vztahů s dodavateli a zákazníky/uţivateli; plánování finančních, personálních, datových a technologických zdrojů a řízení provozu. Zmíněný obsah se podle Gáli, Poura, Tomana [4] rozděluje na tři základní podnikové úrovně řízení do následujících oblastí: 1. Strategické úroveň řízení – strategické řízení / informační strategie 2. Taktická úroveň řízení: plánování a koordinace projektů, řízení informačních sluţeb, řízení kvality informačních sluţeb, řízení ekonomiky v informatice, řízení personálních zdrojů v informatice, řízení datových zdrojů, řízení technologických zdrojů. 3. Operativní úroveň řízení: řízení jednotlivých projektů, řízení provozu. Řízení změn se z tohoto pohledu prolíná všemi úrovněmi podnikového řízení a lze jej do určité míry chápat jako nezávislý proces. Tlak na racionalizaci řízení podnikové informatiky přinesl vznik různých metodik a modelů fungování úspěšného útvaru IS/ICT. V praxi zřejmě nejznámější a v našem prostředí nejpouţívanější jsou: 1. ITIL – IT Infrastructure Library. 2. COBIT – Control Objectives for Information and Related Technology. ITIL verze 2., definuje model základních modulů řízení a podpory IT sluţeb ve vztahu na jejich vstupy, základní funkce a výstupy následovně – obrázek 6. Obrázek znázorňuje rozsah kaţdého z klíčových modulů ITIL společně s hlavními výstupy z kaţdého
individuálního
procesu.
Spojnice 38
mezi
procesními
bloky
ukazují
nejvýznamnější vnější vazby procesů. Proces řízení změn je částí modulu podpory sluţeb (service support). V roce 2007 byl vydán nový soubor publikací pod označením ITIL ver. 3. Jedná se o zásadní přepracování celého konceptu s důrazem na ţivotní cyklus sluţeb. Bohuţel vzhledem k diametrálním rozdílům nelze jednoduše zmapovat procesy z verze předchozí na verzi stávající. I z tohoto důvodu je verze 2 stále populární a hojně uţívaná. V podniku zaměstnavatele, kde působím, se stále vyuţívá verze 2 a proto ji i popisuji.
Byznys - Strategie a plány byznysu - Požadavky byznysu - Plány kontinuity byznysu - Bezpečnostní politika byznysu
Perspektiva byznysu - ICT plány byznysu, komunikace - Politiky obstarávání - Požadavky byznysu - Politiky dodavatelské a smluvní
Správa aplikací - Aplikační strategie - Vývojový program - Aplikační architektura - Aplikační politiky
Plánování implementace SM - Vize & strategiw - Plány programů a projektů - Kultura, personál, školení - Cíle, CSF a KPI
Dodávka služeb - SIP - Plán kvality služeb - Finanční plán - Plán kontinuity služeb - Kapacitní plán - Plán dostupnosti
Správa bezpečnosti - Bezpečnostní politiky - Bezpečnostní strategie a plány
Podpora služeb - Konfigurace - Změny - Releasy - ostatní plány
Správa infrastruktury ICT - Design a architektura ICT - Vyhodnocování, požadavky, nabídková řízení - Strategie a plány ICT - Obchodní případy, studie proveditelnosti
Obrázek 6. Výstupy a rozhraní ITIL dle [7]. Pro účinné a efektivní zpracování změn v provozu kaţdé organizace IT je podstatný jediný centralizovaný proces řízení změn (Change Management). Změny musí být pečlivě řízeny v průběhu celého ţivotního cyklu od iniciace a záznamu, přes filtraci,
39
posouzení, kategorizaci, autorizaci, naplánování, výstavbu, testování, implementaci a případně jejich vyhodnocení a uzavření. Jedním z klíčových výstupů procesu je výhledový plán změn (Forward Schedule of Changes - FSC). Jedná se o ústřední program změn dojednaný se všemi ostatními útvary, zaloţený na ohodnoceném dopadu změny na procesy daného útvaru a naléhavosti změny. Change Management je tedy proces. Jeho cílem je zajištění stavu, ve kterém jsou všechny změny ohodnoceny, schváleny, implementovány, a přezkoumány řízeným způsobem. Zavádění změn, které nepůsobí následné incidenty a u kterých IT pracovníci nemusejí provádět back-out (návrat ke stavu před změnou), přináší zvýšení kapacity IT týmu a plánovanou práci namísto neplánované. Pro pochopení procesu je nutné si vysvětlit následující pojmy dle ITIL: Change: změna je pohyb z jednoho definovaného stavu do jiného. Změny musí mít jasně definovaný a dokumentovaný rozsah. Všechny poţadavky na změny musí být zaznamenány a klasifikovány. RfC: (Request for Change) formát pro dokumentaci a řízení ţivotního cyklu změny. RfC můţe být například výstupem z procesu Problem Management a navazuje na rozpoznání „známé chyby“. Priorita RfC: jedná se o atribut zaznamenávající naléhavost zavedení změny do praxe. Vychází z klasifikace pouţívané i pro incidenty a problémy jejíţ součástí je posouzení dopadu a naléhavosti. Kategorie RfC: atribut, který určuje úroveň potřebné autority ke schválení změny: 1. Minor – změnu schvaluje Change Manager. 2. Significant – změnu schvaluje CAB. 3. Major – změnu schvaluje člen top managementu nebo celé představenstvo. Change Advisory Board (CAB): tým, který schvaluje a pomáhá priorizovat důleţité změny. Forward Schedule Changes (FSC): časový plán implementace schválených změn. Předmětný plán je jedním ze zásadních výstupů celého procesu. Zodpovědnost za tvorbu plánu nese Change Manager. Plán musí obsahovat nejenom implementaci, ale i postupy pro případ selhání postupu implementace a způsob, kterým bude vše uvedeno do původního stavu (back-out plan). Standard change: relativně běţná změna v infrastruktuře, která se provádí zavedeným způsobem. Je pro byznys obvyklá a klíčovými znaky jsou: schválení je učiněno
40
dopředu, úkoly jsou dobře známy a schváleny, kaţdá skupina uţivatelů je autorizována zaţádat o standardní změnu z jejich oblasti, rozpočet je zajištěn předem. Urgent change: změna, kde rychlost implementace je klíčovým faktorem. Je povoleno provést některé činnosti aţ po provedení změny. Počet těchto změn by měl být minimální. Vstupy procesu: RfC z databáze známých problémů, databáze CI (Configuration Items). Aktivity procesu: zaznamenání, klasifikace (riziko, dopady, přínosy), dopady změny na konfigurace, Back-out plan – plán obnovy výchozího stavu před změnou, pokud není změna úspěšná a je třeba provést rollback, posouzení, testování a schválení změny. Výstupy procesu: harmonogram realizace a uvolnění změn, otestovaná, implementovaná, a nasazená změna. Z kategorizace a poţadované úrovně schválení je zřejmá návaznost procesu na strategické řízení. U zásadních (major) změn je v podstatě poţadováno schválení změny s dopadem na informační, popřípadě jinou funkční strategii. Takovou změnou můţe být například rozhodnutí o vybudování záloţního datového centra.
2.4 Proces řízení změn v podniku zaměstnavatele V podniku zaměstnavatele je proces řízení změn plně formalizován. Celý proces je namodelován pomocí BPM (Business Process Model) diagramů a zasazen do celkové hierarchie procesů v informatice podniku. Na uvedené modely navazují vypracované organizační pokyny publikované na firemním portálu s popisy jednotlivých subprocesů, rolí, činností a kritických faktorů úspěchu. Na uvedené organizační pokyny pak navazují školící materiály ve formě prezentací, znázorňujících jednotlivé zodpovědnosti aktérů procesu dle rolí a manuály k vyuţití softwarového nástroje „ITSM“.
41
Vzhledem k tomu, ţe celý proces a jeho návaznosti jsou velmi rozsáhlé, je i model procesu velmi obsáhlý. Pro potřeby předloţené práce se tedy pokusím o zjednodušení. Vzhledem k ustanovením o firemním tajemství nejsem oprávněn uvést kompletní model procesu se všemi diagramy. Proces řízení změn je součástí procesu „Support“ (podpora), který se dle typu podpory sluţby dělí na čtyři subprocesy, kterými jsou: 1. Incident Management. 2. Problem Management. 3. Change Management. 4. Release Management. Řízením změn se zabývají dva naposledy uvedené procesy, které se dělí na další subprocesy. Change Management se rozpadá na subprocesy: 1. Software Changes. 2. Infrastructure Changes. Součástí procesu Change Management jsou i výjimky ze standardního průběhu procesu. Zmíněné výjimky se odlišují procesem schvalování a procesem dokumentace, a jsou to: 1. Implement standard change. 2. Implement urgent change. Proces Release Management se prolíná s procesem Change Management a oba procesy mají společná rozhraní. Z principu je však proces Release Management vyčleněn, a to vzhledem k jeho parametrům a rozsahu. Release Management se v podstatě zabývá řízením velmi rozsáhlých a masových změn ve strategických softwarových produktech. Řízení zmíněných změn má svoje specifika, jimiţ je především rozsah dopadu a délka trvání jednotlivých fází. Proces má dvě specifické části: 1. Xxxx (podnikový) release. 2. Projektový release. Zjednodušený model návaznosti jednotlivých procesů je uveden na obrázku 7. Nesoulad modelu s popisem návazností subprocesů pro implementaci „Standard“ a „Urgent“ změny souvisí se zavedenou praxí. Předmětné výjimky bývají uplatňovány pouze v případě „Infrastructure“ změn. Nepřipadá v úvahu provádět softwarové změny těmito dvěma nestandardními postupy.
42
Obrázek 7. Model procesu Support s důrazem na proces řízení změn [vlastní].
2.4.1 Proces řízení změn Principy procesu jsou shrnuté v podnikovém organizačním pokynu následovně. „Změna“ je dokumentace změny prováděné v produktivním informačním systému (aplikační nebo infrastrukturní produkt). „Change Management – řízení změn“ je interní proces, který registruje, autorizuje a kontroluje všechny změny. Je nezbytně nutné rozlišovat mezi procesem řízení změn a procesem správy poţadavků. Cílem je zavádět všechny změny do produktivního informačního systému kontrolovaným a účelným způsobem za současné minimalizace rizika. To je prováděno standardizací, kontrolováním a autorizací změn prováděných na hardwaru a softwaru. Všechny změny musí být zaregistrovány, autorizovány, nasazeny a ukončeny jako objekt „Změna“ v podpůrném portálu ITSM. První fází procesu je registrace změnového poţadavku. Impulsem pro registraci změnového poţadavku mohou být tři vstupy: 1. Oprava známé chyby vyţaduje změnu, je reakcí na problém v produktu (rozhraní s procesem Problem Management). 2. Implementace schváleného poţadavku (rozhraní s procesem správa poţadavků). 3. Změny v rámci projektu. Vstupní rozhraní procesu je znázorněno na obrázku 8.
43
Obrázek 8. Vstupy procesu Change Management [firemní organizační pokyn]. Výstupem procesu jsou: 1. Zamítnuté změny. 2. Neúspěšně zavedené změny. 3. Úspěšně zavedené změny. Jak jsme si jiţ uvedli, proces se rozpadá na dva subprocesy podle charakteru typu poţadované změny na: 1. Softwarovou změnu. 2. Infrastrukturní změnu.
2.4.1.1 Změna softwaru Změna softwaru je definována jako změna produktu, který je identifikován v seznamu produktů a řešení jako aplikace – viz kategorie produktu APP v produktové databázi podpůrného portálu ITSM. Proces probíhá v těchto pěti po sobě jdoucích fázích: 1. Záznam RfC (Request for Change). 2. Autorizace RfC. 3. Implementace a testování. 4. Zavedení. 5. Poimplementační revize. Detailní popis činností jednotlivých fází a návaznost na odpovědnosti rolí ve sledovaném procesu je uveden v tabulce 2.
44
Tabulka 2. Činnosti a odpovědnosti v procesu Software Change Management [vlastní]. Ze specifikace procesu je zřejmé, ţe kaţdý jednotlivý poţadavek můţe procházet po záznamu do systému nespočetněkrát dalšími fázemi, dokud není s plnou platností zamítnut nebo nasazen. Výjimkou v tomto smyslu je fáze revizní, která striktně vyţaduje ukončení celého procesu pro jednotlivý poţadavek. Z tohoto důvodu má proces dva moţné finální výstupy, mimo jiţ zmiňovaného zamítnutí poţadavku. Prvním moţným výstupem je úspěšné zavedení, druhým neúspěšné zavedení změny. Pod neúspěšným zavedením změny si představme takovou změnu, kterou bylo nutné vrátit zpět (viz back-out plan v části o ITILu) nebo která nenaplnila očekávání a bylo nutné ji v krátkém sledu upravit. S procesem souvisí také dvě speciální funkce určené pro zvláštní případy, kterými jsou: 1. Činnosti při změně pro projekt. 2. Činnosti při změně pro jednotlivou zemi. První funkce souvisí s vyjasněním rolí v procesu řízení změn při zadání a realizaci nového projektu, potaţmo produktu. Nový produkt dodaný jako výsledek projektu je povaţován za změnu, a tudíţ musí být schválen, otestován a zaveden. Produkt od počátku nemá svého produktového manaţera, do doby neţ je tato role převedena na
45
určitou osobu, zastupuje jeho roli v procesu manaţer změny. Produkt, který je v produktivním provozu musí mít definovaného produktového manaţera. Další funkcí specifickou pro projekty je role projektového manaţera, související s vývojem stávajícího produktu potaţmo dopady projektu na funkce stávajících produktů. V takovém případě je projektový manaţer povinen informovat produktové manaţery stávajících produktů o moţných dopadech a změnách. Druhá funkce vychází ze specifik korporace. Společnost se snaţí o harmonizaci a jednotné procesy, coţ má za následek snahu o vývoj pro všechny ‚země‘ (rozuměj národní dceřiné společnosti). Kaţdá změna tudíţ generuje tzv. rodinu změn pro jednotlivé země, které jsou pak dále postupně zaváděny v plánovaných termínech. Potud není sledovaná funkce zajímavá. Důleţitost přináší aţ moţnost vynětí změny z nasazení pro jednu ze zemí. Důvodů můţe být několik: jiná legislativa, nenadálé události nebo i zaostalost při testování. V uvedeném případě je vygenerovaná změna pro danou zemi zamítnuta nebo odloţena s uvedením důvodů, které k tomu vedly.
2.4.1.2 Změna infrastruktury Změna infrastruktury je definována jako změna produktu, který je identifikován v seznamu produktů a řešení jako infrastruktura – viz kategorie produktu INF v produktové databázi podpůrného portálu ITSM. Specifikem procesu je absence produktového manaţera. Změnu do systému zaznamenává ten, kdo ji sám provádí v roli vykonavatele změny. Validaci dopadu změny provádí koordinátor změny. V praxi je daná role zastupována týmovým vedoucím jednotlivých oddělení organizační jednotky, která je za infrastrukturu odpovědná. V systému existují obě role, ale pro efektivnější průběh má mnohdy vykonavatel změny i práva koordinátora změny a můţe poţadavek na změnu přímo zaslat ke schválení. V procesu je plně vypuštěna fáze implementace a testování a fáze zavedení. Fáze zavedení je nahrazena uvedením poţadovaného termínu pro nasazení jiţ ve fázi záznamu změny před jejím odesláním ke schválení. Po schválení je změna automaticky ve stavu PIR. Vykonavatel změny je oprávněn změnu provést a následně revidovat a dokončit. Proces tedy prochází čtyřmi fázemi: 1. Záznam RfC (Request for Change). 2. Autorizace RfC. 46
3. Provedení. 4. Poimplementační revize. V celém procesu je vidět snaha o zkrácené řízení. Snahou je maximální efektivita, aby bylo moţné dosáhnout i vysoké propustnosti procesu. Je zřejmé, ţe změny v infrastruktuře jsou mnohdy lokálního charakteru a nevyţadují takovou úroveň plánování a kontroly, jako změny v softwaru. Proces se všemi kroky by byl příliš náročný a vedl by k neefektivnímu řízení změn. Následkem by byly změny zaváděné pozdě, nemotivovaní zaměstnanci a nízké procento změn, které by vůbec procesem prošly. Za snahou o zjednodušení procesu lze vidět i snahu motivovat zaměstnance, aby i změny, kde poměr dokumentace a zavedení se můţe blíţit aţ 1:2 v jednotkách času, byly zaznamenávány a procesem procházely. Schvalování probíhá kaţdý den na krátkém CAB jednání v 8:30. Sluţbu konající změnový manaţer má při schvalování k dispozici všechny změnové koordinátory, kteří mohou případně doplnit informace. Celý proces umoţňuje, aby změna od svého zaznamenání přes schválení po provedení a revizi prošla v průběhu dvou pracovních dnů. V průběhu transformačního projektu jsem identifikoval zřejmou kritickou slabinu tohoto procesu. Proces ve své zkrácené a maximálně efektivní verzi nebyl schopen zahrnout všechny případy uţití. Především nepřiřazoval ţádnou roli vedoucímu informatiky lokální země. Ten byl z tohoto důvodu zcela nesprávně opomíjen a nedostávalo se mu všech nutných informací k řízení provozu. Docházelo k paradoxním situacím jak ze strany centrálního útvaru informatiky, tak ze strany lokálního útvaru. Pracovníci centrálního útvaru naplánovali a provedli změnu, která ovlivnila systémy v lokální zemi, aniţ by dotčení pracovníci byli informováni. Nejparadoxnějším však byla moţnost provádění změn se zásadním dopadem lokálním útvarem, schválené centrálním manaţerem změn bez toho, aniţ by o tom vedoucí manaţer dané země věděl. Výsledkem byl mnohdy chaos a následné incidenty, které musely být řešeny. V důsledku toho vznikala neochota lokálního managementu proces podporovat a motivovat zaměstnance k jeho pouţívání. Identifikovaná příčina zjevného neúspěchu procesu byla mnou několikrát zmiňována, její důleţitost se však plně projevila aţ při prvních dopadech transformačního projektu. Vzhledem k tomu, ţe celý projekt je zaměřen na centralizaci správy sluţeb, vyţaduje maximální kvalitu komunikace a interakce mezi centrálním a národním útvarem informatiky. V plné nahotě se pak ukázala slabina v tzv. informační mezeře (information gap / lack of information) mezi centrálním a lokálním útvarem. V jejím 47
důsledku manaţer změny neschvaloval poţadavky na změnu od lokálního vykonavatele změny, protoţe o nich nikdo nic na CAB jednání nevěděl. V důsledku toho byl proces na můj návrh upraven. Byla přidána dodatečná tzv. nultá fáze – koordinace s manaţerem informatiky ovlivněných lokálních útvarů. Za tímto účelem byly vypracovány tři scénáře uţití procesu „Infrastructure change‘ podle dopadu na lokální země. Modely scénářů jsou uvedeny na jednotlivých obrázcích 9. – 11. První scénář odpovídá původnímu nezměněnému procesu, lokální útvar není zahrnut, tentokrát jiţ správně na základě ohodnoceného dopadu. Druhý scénář odpovídá případu zavedení změny centrálním útvarem na jím spravovaných systémech, ať jiţ lokalizací v dané zemi nebo v datovém centru, s dopadem na lokální útvar. V praxi je předpokládána koordinace případných souvisejících aktivit s pracovníky lokálního útvaru.
Obrázek 9. Scénář provedení změny v centrálním útvaru bez dopadu na lokální [vlastní].
48
Obrázek 10. Scénář provedení změny v centrálním útvaru s dopady na lokální [vlastní].
Obrázek 11. Scénář provedení změny v lokálním útvaru s dopady na lokální [vlastní]. Formálně je pak první krok uskutečněn zasláním strukturovaného e-mailu na speciální poštovní skupinu pro danou zemi. Stejná jmenná konvence zajišťuje snadné zapamatování po několikerém uţití. Členy skupiny si nominuje a zadává lokální útvar nezávisle. Zmínění členové jsou pak zodpovědní za koordinaci v lokálním útvaru. Prakticky uvedená změna procesu neumoţňuje reagovat na plánovanou změnu v průběhu její přípravy a zavedení do systému. Uvedené řešení bylo zvoleno za účelem zachování dostatečné efektivnosti celého procesu. Byla obava (oprávněná), ţe pokud bude vyţadováno formální povolení změnu provést od lokálního útvaru, ztratíme akceschopnost centrálního útvaru při plánování jeho aktivit. Moţnost zásahu do procesu 49
byla vyhrazena manaţerovi lokálního útvaru, který je oprávněn zaslat tzv. ‚veto‘ na skupinu změnových manaţerů. Ti pak do vyjasnění změnu neschválí. Třetí scénář odpovídá případu zavedení změny lokálním útvarem a s lokálním dopadem. Lokální vykonavatel změny je povinen informovat o plánovaných aktivitách manaţera lokálního útvaru. Ostatní pak probíhá stejně, jako při druhém scénáři. Čtvrtý moţný scénář odpovídající případu zavedení změny lokálním útvarem s centrálním dopadem byl vyhodnocen jako řídce se stávající a byl vypuštěn.
2.4.1.3 Standardní a Urgentní změna Mimo výše uvedené dva procesy existují dvě významné výjimky. Obě se týkají procesu Infrastructure change. Hlavním rysem obou výjimek je zkrácená doba od záznamu do provedení změny a celkové urychlení provedení změny. Výjimkami jsou: 1. Standardní změny. 2. Urgentní změny. Standardní změna je popsána jako standardní nebo periodická změna, která je detailně popsaná jako procedura. Dalším poţadavkem je, aby daná změna neměla negativní dopady na integritu dat nebo procesů. Změna s tímto charakterem můţe být podrobně zdokumentována pouze jednou a předloţena ke schválení speciálnímu CAB pro standardní změny. Pokud je změna schválena jako standardní, je nadále nutné ji dokumentovat v systému ITSM s identifikátorem schválené standardní změny, avšak vykonavatel změny po její registraci nemusí čekat na schválení a můţe změnu okamţitě provést. Změna je povaţována za schválenou apriori. K provádění a schvalování standardních změn existuje samostatný organizační pokyn. Mým přínosem do praxe bylo zdokumentování a zajištění schválení standardních změn, ke kterým jsou oprávněny všechny lokální útvary. Příkladem je restart serveru, výměna vadného zařízení nebo instalace standardního softwarového balíku přes centrální nástroj pro deployment. Urgentní změna je výstupem procesu Incident Management. Incident s vysokou prioritou a značným dopadem je ohodnocen jako „Prio 1“. Uvaţovaný incident zásadně ovlivňuje výkonnost podnikových procesů. Jeho řízením je pověřen sluţbu konající eskalační manaţer. Ten můţe pro vyřešení incidentu poţadovat urgentní změnu v systému, která odstraní zásadní omezení funkcí majících vliv na podnikové procesy nebo je alespoň sníţí. Předpokladem je tedy alespoň jeden incident s prioritou 1 a 50
k němu přiřazený problém ve stavu „Request for Change“. Změna je zaregistrována s nejvyšší prioritou, eskalační manaţer ji schválí (nejčastěji pouze telefonicky) a změna je provedena. Dokumentace a schválení v systému je potom provedena v nejbliţším moţném termínu eskalačním manaţerem. Eskalační manaţer má v daném případě roli změnového manaţera a koordinátora změny v jedné osobě a navíc při dokumentaci v systému zastává i roli vykonavatele změny, aniţ ji sám provádí.
2.4.1.4 Klasifikace dopadů změny Jako vodítko pro správnou klasifikaci dopadů změny při její registraci do systému je vypracován postup ohodnocení potenciálního rizika. Jak uţ jsem v dřívějším textu uvedl, kategorie změny je zásadním vstupem pro průběh fáze schvalování změny. Jsou popsány a vyuţívány následující čtyři kategorie změn, jejich klasifikace je provedena dle dopadu na produktivní prostředí: 1. Standardní změna. 2. Minor (malá) změna. 3. Major (velká) změna. 4. Significant (podstatná/významná) změna. Charakteristiky jednotlivých kategorií jsou uvedeny v tabulce 3.
Tabulka 3. Pouţité kategorie změn – klasifikace dle dopadu [vlastní].
51
2.4.1.5 Role v procesu řízení změn Nejdříve si objasníme samotný pojem role. Role je definována svou kvalifikací, svými úkoly, kompetencí a v neposlední řadě zodpovědností. Role můţe být vykonávána jednou nebo více osobami a naopak jedna osoba můţe vykonávat více rolí. Ve vztahu k procesu Change Management jsou definovány následující role: 1. Vlastník systému (System owner). 2. Vlastník procesu (Process owner / Mandate bearer). 3. Manaţer procesu (Process manager). 4. Změnový manaţer (Change manager). 5. Změnový koordinátor (Change coordinator). 6. Change Advisory Board (CAB). 7. Vykonavatel změny (Change performer) – pouze pro INF produkty. 8. Produktový manaţer (Product manager). 9. Projektový manaţer (Project manager). Definice jednotlivých rolí je uvedena v následujícím strukturovaném textu způsobem, aby bylo dostatečně přehledné přiřazení jednotlivých charakteristik k jednotlivým rolím.
Vlastník systému Kvalifikace: cílevědomost, strategické myšlení Kompetence: jednat jako klient, schvalování investic, jmenování vlastníka procesu Odpovědnost: silná a dynamická podpora projektu, akceptace projektu, vytváření povědomí o projektu v managementu společnosti Úkoly: nařízení zavedení procesu podle ITIL, poskytnout prostředky pro zavedení a roll-out, nastavit rámcové podmínky procesu
Vlastník procesu Kvalifikace: komplexní schopnost konat a myslet napříč procesy, cílevědomost, strategické myšlení Kompetence: návrh a další rozvoj procesu, nepřetrţité zlepšování procesu, definice pro metriky výkonnostních indikátorů (KPI’s), jmenování manaţera procesu Odpovědnost: schvalování změn v procesu, akceptace a vytváření povědomí o procesu
52
Úkoly: definice cílů procesu (krátkodobé, střednědobé, dlouhodobé), nastavit rámcové podmínky procesu
Manažer procesu Kvalifikace: schopnost konat v konfliktních situacích, cílevědomost Kompetence: vyţadovat měření procesu v případě nesouladu s cíli a postupy, shromaţďovat výkonnostní indikátory (KPI’s) Odpovědnost: za nastavení, pouţívání a kontrolu kvality procesu a procesních postupů, provádění cílů definovaných vlastníkem procesu, přispívat k nepřetrţitému zlepšování procesu, reporty výkonnostních indikátorů Úkoly: přispívat ke zpracování doporučení v procesu nepřetrţitého zlepšování, reporting, podpora vlastníka procesu
Změnový manažer Kvalifikace: schopnost konat v konfliktních situacích a při krizích, znalost procesu a produktů, ohodnocení obsahu a dopadu změny, systém pro řízení obsahu změny Kompetence: schvalování změn, rozhodování o produktivním nasazení změn a release, právo změnit klasifikaci dopadu změny Odpovědnost: zajištění (ochrana) produktivního prostředí, shromaţďování doporučení od odpovědných nebo ovlivněných osob k dané změně Úkoly: předsedající CAB, svolávat a účastnit se CAB, ohodnocení dopadu změny, ohodnocení klasifikace změny, konzultovat s CAB změny kategorie „major“, zajištění schválení změny kategorie „significant“ s top managementem a CAB, schvaluje změny všech kategorií v systému
Změnový koordinátor Kvalifikace: řídit konflikty a krize Kompetence: potvrzuje kategorizaci dopadu, právo zvýšit kategorii dopadu, schválení změn kategorie „minor“ Odpovědnost: podpora změnového manaţera, schvalování změny kategorie „minor“ Úkoly: ohodnocení efektu změny pro IT prostředí, potvrzení kategorie nabídnuté produktovým manaţerem, zvednout kategorii „minor“ na vyšší, schválení změny kategorie „minor“, účast na CAB 53
!!! Osoba nesmí být shodná s produktovým manaţerem (4-eye principle)
Change Advisory Board (CAB) Kvalifikace: mít poţadované kompetence, technické a ekonomické know-how, umět rozhodnout, komunikativnost, konstruktivní myšlení Kompetence: dávat doporučení změnovému manaţerovi ohledně změny kategorie „major“ a „significant“, změna kategorie (i směrem dolů) Odpovědnost: konzultovat změny kategorie „major“ a „significant“ se změnovým manaţerem, ohodnocení efektu změny pro IT prostředí Úkoly: ohodnocení efektu a dopadu změn „major“ a „significant“, změna kategorie v případě potřeby Členové: stálý člen: manaţer změn, dobrovolný člen: koordinátoři změn z jednotlivých oblastí, enterprise architekt, vývojáři, administrátoři, členové projektového týmu Zasedá periodicky nejméně jednou za 2 pracovní dny.
Vykonavatel změny (INF) Kvalifikace: znalost konfiguračního objektu (CI – configuration item) na který má změna dopad Kompetence: navrhuje kategorii dopadu, vykonává fázi provedení změny Odpovědnost: odpovídá za změnu, transparentnost prováděných změn, záznam a uzavření změny, kontaktní osobou pro ovlivněné týmy Úkoly: záznam změny, zamítnutí nebo odloţení změny, dokumentace všech potřebných údajů o změně, postoupit změnu ke schválení, postimplementační revize, ukončení
Produktový manažer Kvalifikace: technická znalost produktu, znalost rozhraní produktu s okolními produkty Kompetence: navrhuje kategorii dopadu, provádí a převádí jednotlivé stavy změny Odpovědnost: odpovídá za změnu, transparentnost prováděných změn na produktu, záznam a uzavření změny, kontaktní osobou pro zákazníka Úkoly: záznam změny, kontaktní osoba pro projektového manaţera pro změny na jeho produktu, zamítnutí nebo odloţení změny, dokumentace všech potřebných údajů o změně, postoupit změnu ke schválení, potvrzení implementační a testovací fáze, postimplementační revize, ukončení 54
Projektový manažer Má svoji roli specificky definovanou ve vztahu k procesu řízení změn. Nejedná se o plný popis role projektového manaţera ve firmě, ale pouze o její část ve vztahu k procesu. Detailní a ucelený popis role projektového manaţera se nachází v kapitole 3.2.3. Role je popsána rozdílně pro dva moţné případy, kterými jsou změny na stávajícím produktu a nasazení nového produktu.
Stávající produkt Odpovědnost: poskytnout všechny potřebné informace o změně produktovému manaţerovi dotčených produktů
Nový produkt Odpovědnost: vykonávat roli produktového manaţera se všemi poţadavky na tuto roli do doby neţ je definován produktový manaţer Podle charakteristik jednotlivých rolí lze logicky odvodit rozdíl v jejich vztahu k procesu na třech úrovních, kterými jsou: 1. Proces. 2. Změna. 3. Produkt. Vztahy jednotlivých rolí k jednotlivým úrovním (objektům) procesu se dají vyjádřit modelem, viz obrázek 12. Role systémového vlastníka jako zákazníka procesu musí být z principu vykonávána osobou mimo oddělení informatiky. Tak tomu i skutečně je a danou roli zastává člen představenstva společnosti, který v případě mé organizace svoji roli v praxi vykonává vcelku odpovědně a zajišťuje tím oddělení informatiky dostatečnou podporu při snaze o obcházení procesu jinými útvary. Vlastníkem procesu je člen top managementu centrálního útvaru informatiky. Manaţerem procesu pak zodpovědný pracovník procesního oddělení. Všechny zmíněné role jsou vykonávány pouze jednou osobou. Role změnového manaţera je z důvodu zastupitelnosti vykonávána jmenovaným týmem osob sestávajících se z členů top managementu útvaru. Ostatní role jsou pak zastávány dle jmenování a odpovědnosti za oblasti a produkty.
55
Obrázek 12. Vztahy jednotlivých rolí k objektům procesu řízení změn [vlastní].
2.4.1.6 Metriky procesu řízení změn V současnosti je proces měřen pomocí metrik ve formě výkonnostních indikátorů. Z toho vyplývá, ţe jsou sledovány počty a popřípadě poměry typů změn za určité časové období. Neexistují tvrdé metriky, které by stanovily hraniční hodnoty úspěšnosti nebo neúspěšnosti procesu. Vyhodnocení výkonnostních indikátorů předpokládá znalost prostředí a změn tak, aby čtenář reportu byl schopen zasadit změny v trendech růstu popřípadě poklesu jednotlivých parametrů do souvislostí. Reporting procesu řízení změn obsahuje následující výkonnostní indikátory: 1. Měsíční počet ukončených změn podle priority a kategorie. 2. Měsíční počet změn podle kategorie a statusu: úspěšně ukončený, neúspěšně ukončený, zamítnutý. 3. Počet ukončených změn ze vstupu procesu Problem Management. Změny jsou děleny pouze na nejvyšší úrovni podle subprocesů na změny aplikační (softwarové) a infrastrukturní. Ostatní dělení reporting neobsahuje. Vzhledem k tomu, ţe se tedy jedná o kumulované hodnoty za velmi obsáhlé oblasti, je výsledný report vhodný pouze pro top management útvaru informatiky. Do budoucna bude nezbytně 56
nutné pro vyšší vypovídající hodnotu zavést další indikátory. Z mé strany bych doporučoval především dělení podle produktů a podle zemí. Ukázky reportingu výkonnostních indikátorů naleznete na obrázcích 13. – 17. Jejich vyhodnocení a závěry pro praxi následují.
Obrázek 13. Měsíční počet ukončených změn podle priority a kategorie dle [firemní reporty]. Report (obrázek 13) vykazuje nepoměrně vyšší procento změn prováděných v oblasti infrastruktury. To vypovídá o tom, ţe zjednodušený proces přináší efektivitu nejenom v provádění změn, ale i v tom, ţe jsou změny skutečně dokumentovány a procesem řízeny. Dalším jevem, který graf ukazuje, je nárůst počtu infrastrukturních změn v 1. a 2. měsíci 2010. Přál bych si za tímto nárůstem vidět úspěšný remodeling procesu a jeho vyuţívání i v lokálních útvarech informatiky. Produktivní start procesu pro lokální útvary byl 1.1.2010. Bohuţel aţ příští výkazy ukáţí, jestli se tento trend potvrdí.
Obrázek 14. Počet ukončených změn ze vstupu procesu Problem Management dle [firemní reporty].
57
Na reportu (obrázek 14) je čitelná určitá stagnace. Zjištěný jev není způsoben jen funkčností procesu řízení změn, ale především neúspěšností procesu Problem Management. Proces pro řízení problémů je málo vyuţíván, a tím je průchod od incidentu ke změně mnohdy nečitelný. Následkem zmíněné skutečnosti není moţné v systému, ač ten to umoţňuje, trasovat původ změn v incidentech. Tím se ztrácí schopnost měřit úspěšnost odstraňování původců chyb v produktivním prostředí. Zjištěná skutečnost nezůstala bez povšimnutí. V současnosti jsou vyvíjeny aktivity ohledně reengineeringu sledovaného procesu. Předně musí být vyjasněna otázka nositele a řešitele problémů. Je zřejmá snaha nezapojovat do procesu lokální útvary a provádět problem management pouze na centrální úrovni.
Obrázek 15. Měsíční počet změn podle kategorie a statusu: úspěšně ukončený a neúspěšně ukončený dle [firemní reporty]. Obrázek 15 ukazuje, ţe procento úspěšně provedených změn je velmi vysoké. To vypovídá o tom, ţe je velké mnoţství změn uskutečněno a navíc v termínu, aniţ by bylo nutné obnovit systém do původního stavu. Sledovaný indikátor však nic nevypovídá o kvalitě provádění změn, protoţe i změna, která způsobila delší odstávku neţ bylo plánováno nebo zanesla do systému jiné chyby, které následně generovaly incidenty, je hodnocena jako úspěšná. Úspěšná změna se v tomto případě rovná provedená změna. V dané souvislosti chybí z mého pohledu zpětná vazba z procesu change management do procesu incident management. Zde vidím další oblast příleţitostí pro zlepšení procesu.
58
Obrázek 16. Celkový počet změn dle statusu zdokumentovaných v systému od 06/2007 dle [firemní reporty].
Obrázek 17. Koláčový graf poměrů změn dle statusu zdokumentovaných v systému od 06/2007 dle [firemní reporty]. Poslední report (obrázek 16) a graf (obrázek 17) opět potvrzuje domněnku o správnosti rozdělení procesu na subprocesy pro aplikace a infrastrukturu. Svědčí o tom procento změnových poţadavků ve stavu „zpracování“ (in bearbeitung). Zjištěná skutečnost vypovídá o rozdílech v délce zpracování změny v těchto dvou procesech.
2.4.2 Proces řízení uvolňování verzí (release) Proces Release Management se velmi prolíná s procesem řízení změn v podniku. Jeho hlavní úloha spočívá v dlouhodobém plánování termínů pro změnu podnikových aplikací. Proces se snaţí kontinuálně zpracovávat a měnit stav u většího počtu změnových poţadavků najednou. Výsledkem je zavádění release, kterému můţeme rozumět jako balíček změn komponent produktu. V souvislostí se zavedením release se
59
hovoří i o povýšení verze produktu. Proces odpovídá za sestavení a testování release, podporu při zavádění do produktivního prostředí a za distribuci a implementaci schváleného balíku změn. Release se dělí na dva typy: 1. Release produktu: povýšení verze jednotlivého produktu. 2. Xxxx (podnikový) release: změna všech podnikových produktů. Vztah obou typů release a jednotlivých změn je vyjádřen na obrázku 18.
Obrázek 18. Úrovně sestavování release v podniku dle [firemní materiály]. Z obrázku 18 je zřejmé sestavení produktového release z většího počtu změn a následný upgrade podnikového prostředí při zavedení všech souvisejících produktových release. Vyvstává otázka, jak je to s provázaností termínů mezi produktovým a podnikovým release. Samozřejmě není technicky moţné najednou změnit všechny aplikace. Proto hraje v tomto procesu hlavní roli plánování a sestavování release pro jednotlivé produkty s důrazem na vzájemnou podporu tak, aby ve výsledku bylo moţné vyuţívat nejen funkcionality pro jeden určitý produkt, ale i funkcionality, které vyuţívají určitého rozhraní na další systémy, popřípadě potřebují data z jiného systému. V praxi to vypadá tak, ţe se všechny potřebné funkcionality v prvním sledu vyvíjejí, implementují a testují pro všechny systémy dohromady, ale následně se v prvním sledu uvolní release pro nasazení v centrálním systému ERP. Tím jsou připravena potřebná rozhraní a případná data pro následující produktový release navazujících systémů. Ve
60
výsledku tedy nemusí být shodný termín release a spuštění pouţívání nové funkcionality v produktivním prostředí informačního systému. Proces probíhá ve třech hlavních fázích: 1. Plánování release. 2. Záznam release. 3. Kontrola a revize release. Plánovací fáze probíhá v ročním předstihu. V praxi jsou schválené termíny release pro příští rok nejpozději v 11. měsíci. Produktový manaţer je zodpovědný za rozhodnutí o počtu release pro daný rok, sestavení obsahu a trasování změnových poţadavků k releasu. Manaţer releasů ověří obsah produktového release ve vztahu na podnikový release zejména z pohledu konzistence plánu zavádění změn. Vstupem procesu jsou: 1. Změnové poţadavky z procesu řízení změn. Aktivitami procesu jsou: 1. Plánování a sestavování release. 2. Akceptace testů release. 3. Nasazení release. Výstupem procesu na rozhraní do change managementu jsou: 1. Schválený release k implementaci a testování. 2. Otestovaný release k nasazení. 3. Nasazený release k postimplementační revizi. Rolemi v procesu jsou: 1. Produktový manaţer. 2. Release manaţer. Pozice release manaţera, jak jsme si jiţ uvedli, je především kontrolní a koordinační. Jeho hlavní funkcí je kontrola obsahu v návaznosti na produktové a podnikové releasy a kontrola stavu testovaných změn. Jeho právem je vyřadit poţadavek z release, pokud bude mít jakékoliv pochybnosti o jeho kvalitě, obsahu nebo testování. Vzhledem k tomu, ţe proces sám o sobě není samostatný, nejsou k němu definovány ani zvláštní metriky. Pro zjednodušení návaznosti změn a jednotlivých release je ustavena jmenná konvence pro jednotlivé produkty tak, aby bylo moţné vytvářet jednoduchý číselník. Dále jsou s předstihem naplánovány a v systému zavedeny release na několik let dopředu. To usnadňuje plánování v dlouhodobém horizontu. Při upřesňování plánů pak dochází 61
podle potřeb projektů a moţných vyuţitelných zdrojů k případnému zrušení některého z release nebo doplánování dalšího.
2.4.3 Kritická místa procesu a možnosti zlepšení Oba procesy jsou vhodně podporovány softwarem ITSM. Tento software je interně vyvíjen za účelem podpory procesů v informatice podle metodiky ITIL. Softwarový produkt umoţňuje procesní, funkční a datovou provázanost řízení změn na incident a problem management a dále na modul řízení poţadavků. Provázanost jednotlivých modulů a aktivit v interním podpůrném softwarovém nástroji ve vztahu k řízení změn je znázorněna na obrázku 19.
Obrázek 19. Workflow overview in ITSM tool dle [8]. Logická komparace faktů uvedených na obrázku 19 ukazuje, ţe chybí provázanost na obsáhlou a aktuální konfigurační databázi. Z toho vyplývá slabina procesu, která na základě důkladného rozboru tkví v nedostatečné dokumentaci jednotlivé změny v návaznosti na změny konfigurace. Konfigurační databáze je do určité míry nahrazena databází produktů a jejich komponent. Z vlastní praxe však mohu konstatovat, ţe kvalita databáze produktů je velmi proměnlivá v závislosti na kvalitě informací zadaných do systému produktovým manaţerem. Jak jsem jiţ uvedl, proces je podporován softwarovým nástrojem. Jedinou výjimkou je proces
schvalování
standardních
změn. 62
Schvalování
standardních
změn
je
formalizováno interním organizačním pokynem a návrhy se projednávají jednou měsíčně na speciálním zasedání CAB. Seznam takto schválených změn je uveden včetně dokumentace na interním wiki portálu. K označení a katalogizaci se pouţívá číselník, jenţ definuje jednoznačné číslo standardní změny, které je pak vstupem při zaloţení poţadavku na změnu. Při změně tohoto typu je vyţadováno zdokumentovat její provedení, ţadatel však nemusí čekat na schválení. Bohuţel však systém nepodporuje zadání poţadavku kategorie standard a zadavatel je nucen pokaţdé, ač ne do detailů, vyplnit všechna povinná pole. Tím se dostáváme k jádru problému. Dokumentace předmětného poţadavku je neefektivní, informace o dopadech jsou umístěné mimo systém a délka zpracování poţadavku v systému mnohdy převyšuje čas potřebný k provedení takové změny. Je sloţité a v podstatě nemoţné motivovat zaměstnance k pouţívání tohoto procesu i pro tento případ. V uplynulých měsících se povedlo zavést dvě zásadní změny, které přispěly ke kvalitě, transparentnosti a vyuţívání celého procesu. O první změně jsem jiţ psal v kapitole2.4.1.2 Infrastructure change. Jednalo se o nastavení komunikačního workflow mezi centrálním a lokálními útvary informatiky. Druhou podstatnou změnou bylo vytvoření smysluplné jmenné konvence pro řešitelské týmy v produktu ITSM podle organizačního a funkčního zařazení. Došlo tím k zpřehlednění zařazení týmů do oblastí. Mým přínosem byl jednotný návrh struktury týmů pro lokální útvary informatiky, který je nyní zaveden v praxi a umoţňuje delegování do lokálních útvarů bez nutnosti znalosti zodpovědného řešitele. Týmy jsou rozděleny dle oblastí podpory na: 1. Infrastrukturu. 2. Verwaltung (Správa – rozuměj centrální útvary). 3. Ware (Zboţí – rozuměj podpora provozu a logistiky). V praxi to znamená, ţe zatímco v minulosti jsem byl nucen znát alespoň jednoho člena řešitelského týmu a pak jsme si vyhledal v jakém týmu je, dnes jsem schopen se adaptovat a pomocí jmenné konvence zvolit s nejvyšší pravděpodobností správný tým. Mimo jiné došlo k reorganizaci týmů a odstranění některých duplicit a překrývání. Z původního počtu přes 500 řešitelských týmů zůstalo cca 350. Na základě prověrky logiky řízení informací však i nadále procesu chybí detailnější reporting, který by zajišťoval přenos informací na niţší řídící úrovně. Střední management nemá k dispozici nástroj na hodnocení výkonnosti svého oddělení. To samé platí ve vztahu k reportům pro změny prováděné v lokálních útvarech. 63
V neposlední řadě postrádám reporty vztaţené k produktům pro produktové manaţery. Tímto směrem zacílené nové výkonnostní indikátory by přiblíţily význam a přínosy procesu na taktickou úroveň řízení a zajistily by tak nový impuls pro rozvoj a zlepšování procesu. Další oblastí příleţitostí pro zlepšení je reengineering procesu řízení problémů. Jeho vyšším vyuţitím by došlo k zvýšení počtu změnových poţadavků vázaných na odstranění chyby v systému. Tím by se všeobecně dala lépe měřit výkonnost útvaru informatiky nejenom ve střední hodnotě délky řešení incidentů, ale i ve schopnosti účinně řešit příčiny chyb, které následně paralyzují produktivní provoz. S provázaností na incidenty a chyby souvisí i zpětná vazba při vyhodnocení kvality provedení změny. Jak jsem se jiţ výše zmiňoval, tak chybí moţnost provázat vzniklý incident na uskutečněnou změnu. Z pohledu informačního systému, který je vyuţíván by však praktická aplikace dané vazby byla sloţitá. Bylo by nutné vytvořit rozhraní mezi oběma moduly a oba procesy modifikovat, coţ se jeví velmi náročné. Celkově bych oblasti příleţitostí seřadil podle přínosů a náročnosti zavedení následovně: 1. Detailnější reporting. 2. Vyšší kvalita databáze produktů. 3. Zpětná vazba do Incident Managementu. 4. Podpora zpracování standardních změn. 5. Reengineering Problem managementu. V kapitole jsme se detailně zabývali procesem řízení změny v návaznosti na rozhodnutí o zásadní změně strategie podniku. Na praktické implementaci z prostředí podniku zaměstnavatele jsme si ukázali rozhraní mezi procesem řízení změn a procesem strategického řízení. Tím je změnový poţadavek kategorie „significant“, který musí být schválen managementem společnosti. Předmětný změnový poţadavek musí být hodnocen v souladu se strategií podniku nebo můţe přinášet podnět pro její změnu. Popsali jsme si jednotlivé aktivity a role procesu. Zabývali jsme se technikami umoţňujícími plně rozvinout potenciál organizace nutný pro provedení poţadované změny a kroky následující po dosaţení plánovaného stavu. Zabývali jsme se změnou samotnou. V závěru kapitoly jsem logickou analýzou procesu odhalil kritická místa procesu a identifikoval moţné oblasti pro zlepšení. Ponechali jsme stranou další
64
důleţitý nástroj, který je potřebný k celkové koordinaci všech aktivit při provádění změn většího rozsahu, a tím je projektové řízení.
65
3 Projektové řízení V minulých kapitolách jsme se zabývali tvorbou strategie podniku ve vztahu k procesu strategického řízení. Uvedli jsme si nástroje, které jsou nutné pro úspěšnou implementaci strategie do prostředí organizace, kterými jsou proces řízení změn a projektové řízení. Proces řízení změn včetně jeho návaznosti na řízení IS/ICT a jeho praktickou implementaci jsme analyzovali a popsali v kapitole předchozí. V předmětné kapitole se budeme zabývat návazností projektového řízení na řízení změn za účelem zásadní změny stávajícího produktu nebo dodávky nového produktu.
3.1 Projektové řízení – základní terminologie Projektové řízení jako nástroj řízené změny je ve své podstatě proces a jako k procesu k němu budeme přistupovat. Stručně vysvětlíme obsah a cíle projektového řízení a poté uvedeme fáze a ţivotní cyklus projektu. Projektový management (projektové řízení): převzato ze Svozilové [9] Definice dle H. Kerznera: Projektový management je soubor aktivit spočívající v plánování, organizování, řízení a kontrole zdrojů společnosti s relativně krátkodobým cílem, který byl stanoven pro realizaci specifických cílů a záměrů. Definice dle PMI: Projektový management je aplikace znalostí, schopností, nástrojů a technologií na aktivity projektu tak, aby tyto splnily poţadavky projektu. V podstatě jde o aplikaci znalostí a metod na vyuţití zdrojů pro dosaţení cílů. Projekt: převzato ze Svozilové [9] Definice dle H. Kerznera: Projekt je jakýkoliv jedinečný sled aktivit a úkolů, který má dán specifický cíl, definováno datum začátku a konce, stanovený rámec pro čerpání zdrojů potřebných pro realizaci. Definice dle PMI: Projekt je dočasné úsilí vynaloţené na vytvoření unikátního produktu, sluţby nebo určitého výsledku. Podle první definice lze projekt definovat třemi charakteristikami, které jsou známé jako tři základny projektového managementu – viz obrázek 20. Životní cyklus a fáze projektu: projekt se v průběhu své dočasné existence nachází v různých fázích, které nazýváme ţivotním cyklem projektu.
66
Obrázek 20. Základny projektového managementu dle [9]. Fáze ţivotního cyklu projektu jsou dle Svozilové [9] sekvence neboli stavy projektu a časové úseky jim odpovídající. Přechod z jedné fáze do druhé je uskutečněn při dosaţení určitého dříve specifikovaného stavu projektu, případně souboru plánovaných dílčích výsledků. Fáze ţivotního cyklu projektu a definované mezisekvenční stavy se dají znázornit například takto – viz obrázek 21.
Obrázek 21. Ţivotní cyklus projektu dle [10]. Projekt jako takový musí mít mimo fází definovány i hlavní procesy, činnosti, role a odpovědnosti. Jejich propojení tvoří logický model projektu, který ukazuje přehledné zařazení činností do jednotlivých fází projektu. Fáze ve vztahu k rolím a definované
67
návaznosti ke vstupům předchozích činností tvoří subprocesy projektového řízení. Příslušný model je znázorněn na obrázku 22.
Obrázek 22. Logický model vztahů v rámci skupin procesů řízení projektu dle [9]. Vztahy i pozice podle sledovaného modelu slouţí pro obecný a zjednodušený pohled – skutečná situace v projektu a interakce mezi jednotlivými procesy a účastníky závisí na rozsahu projektu. Při velkém projektu pak bývá schéma mnohem sloţitější. Především však většina projektů přináší celou řadu cyklů, vzájemných vazeb a souběhů jednotlivých procesů.
3.2 Projektové řízení v podniku zaměstnavatele Projektové řízení v podniku zaměstnavatele je formalizováno obdobným způsobem jako změnové řízení pomocí interních směrnic a organizačních pokynů. Pro projektové řízení je popsán proces „Project Guide Line“ jako opakovaný sled činností k dosaţení specifikovaného výstupu. K dispozici je detailní procesní model, organizační pokyn a popis rolí. Popis rolí obsahuje i základní organizační strukturu projektu. Podpora předmětného procesu není zpracována formou softwarového nástroje. Z tohoto důvodu 68
jsou vytvořeny vzory základních dokumentů od návrhu přes schválení aţ k ukončení projektu. Pro dokumentaci projektů je vytvořena formalizovaná a standardní adresářová struktura. Pojetí a návrh procesu jsou přizpůsobeny globálnímu vyuţití, tj. nejenom za účelem řízení projektů v oblasti informatiky. Pro specifické činnosti spojené s vývojem hw/sw řešení je navrţen podpůrný proces SWEP (Software Engineering Process). Obdobný specifický proces je v podniku vytvořen pro podporu řízení projektů spojených s realizací staveb. To v podstatě vypovídá o jistých specifikách uvedených dvou oblastí, které vyţadují rozdílný přístup neţ jiné projekty. Pro účely předloţené práce v následujících kapitolách nebudeme detailně rozebírat celý proces. Krátce projdeme jednotlivé fáze procesu a pak se budeme zabývat pouze provázaností procesu s procesem změnového řízení a strategického řízení a to z pohledu rolí nebo odkazů v dokumentaci. Cílem kapitoly není popsat detailně proces řízení projektů, ale především ukázat vazby na procesy, které jsou předmětem práce.
3.2.1 Proces řízení projektů Proces řízení projektů - „Project Guide Line“ je navrţen s ohledem na širší vyuţití i pro řízení projektů mimo informatiku. Jednotlivé fáze procesu jsou (v závorce uvedena pro srovnání odpovídající fáze z logického modelu dle [9] Svozilové): 1. Předprojektová fáze (Zahájení). 2. Plánování (Plánování). 3. Koncepce (Plánování). 4. Realizace (Koordinace a Kontrola). 5. Implementace (Koordinace a Kontrola). 6. Kontrola úspěšnosti (Uzavření).
Obrázek 23. Fáze procesu „Project Guide Line“ dle [firemní organizační pokyn]. 69
Fáze procesu odpovídají standardním modelům. Mezi podpůrnými procesy jsou zmiňovány: komunikace a reporting, plánování a kontrola (zdroje, termíny, náklady) a projektová dokumentace. Mezi procesem řízení projektů a procesem řízení změn není ţádná funkční vazba. V dokumentaci k řízení projektů jsou samostatně definovány metriky a schvalovací postupy ve vztahu k změnovému řízení na projektu. Změnové řízení na projektu se vztahuje k změnám termínů, k potřebným lidským a finančním zdrojům, parametrům technických zařízení nebo specifikaci funkcionalit. Pro zajímavost uvádím kritické hodnoty indikátorů, při kterých musí být změnové řízení zahájeno bezpodmínečně a projednáno kontrolní komisí, coţ předpokládá účast člena představenstva podniku: 1. Nárůst nákladů o 5% nebo o více neţ 250 tis. Euro. 2. Přínosy < náklady. 3. Moţnost vyuţít efektu na jiné projekty – nutno navrhnout plán synergie. 4. Zpoţdění o 3 měsíce. 5. Podstatné změny obsahu a cílů projektu. Vazba projektového řízení na strategické řízení je v dokumentaci dobře čitelná. Vypovídá o tom definice vah pro tzv. priorizaci projektu. Priorizací se rozumí přiřazení priority, na základě které má potom projekt případnou přednost před jiným při čerpání zdrojů tak, aby bylo zajištěno jeho dokončení. Hlavními oblastmi slouţícími pro oceňování váhy projektu jsou: 1. Korporátní strategie – přímá návaznost na strategii podniku. 2. Ziskovost. 3. Nutnost změny (nové právní předpisy). 4. Dostupné finanční prostředky. 5. Závislosti projektů (projekt 1 musí být dokončen, aby se mohl spustit projekt 2). Z uvedených skutečností vychází definice čtyř kategorií projektů, přičemţ platí pravidlo, ţe projekt s vyšší prioritou má přednost při čerpání zdrojů – viz tabulka 4. Projekty vycházející z korporátní strategie mají definovánu nejvyšší prioritu hned po legislativních poţadavcích.
70
Tabulka 4. Klasifikace projektů dle priorit dle [firemní organizační pokyn].
3.2.2 Proces softwarového inženýrství Software Engineering Process (zkráceně SWEP) je podpůrný proces procesu řízení projektů pro projekty v oblasti informatiky. Jeho návrh a jednotlivé fáze tedy odpovídají definovaným fázím hlavního procesu. Doplňují je specifické činnosti související s vývojem software a dodávkou hardware. Vztah obou procesů – viz obrázek 24.
Obrázek 24. Vazby procesu „Project Guide Line“ a SWEP dle [firemní organizační pokyn]. 71
Proces softwarového inţenýrství je proces iniciovaný procesem řízení změn. Vstupem do procesu jsou zaregistrované poţadavky, které jsou následně schváleny procesem řízení změn. Rozdílem oproti procesu řízení změn je rozsah navrhované změny, která ze změnového poţadavku dělá softwarový projekt. Zajímavá jsou z tohoto pohledu pravidla pro chápání změny jako projektu. Změna typu: 1. Změna řešení nebo procesu podporovaných informačními technologiemi. 2. Zlepšení, která doplní a rozšíří části hardware nebo software funkcionality, která splňuje jedno z následujících kriterií: -
vynaloţené úsilí (úsekem informatiky nebo externí společností) více neţ 75 MD,
-
délka do roll-outu > 6 měsíců,
-
dodávka kompletně nového produktu
-
vynaloţené investice (interní a externí) > 1 mil. Euro
by měla být projektem řízeným pomocí SWEP procesu.
3.2.3 Role v procesu projektového řízení Oba výše popsané procesy vyţadují mnoho specifických rolí. Z pohledu této práce jsou zajímavá zpřesnění rolí projektového a produktového manaţera.
Produktový manažer v procesu SWEP Kompetence: rozhodnutí o zlepšování a rozšíření produktu, realizace akceptačních testů Odpovědnost: za celý produkt v celém jeho ţivotním cyklu, má ekonomickou, technickou a mezinárodní odpovědnost za produkt, monitoring produktu, poţadavky na produkt jsou realizovány v přípustném čase, kvalitě a nákladech, zabezpečuje integraci produktu do podnikového prostředí, adekvátní a aktuální technická dokumentace, dokumentace provozních operací Úkoly: spolupráce při realizace softwarových změn, plánování termínů a nákladů, plánování produktových release, koordinace změn produktu s dopadem na ostatní produkty s odpovědnými produktovými manaţery, sbírání a posuzování poţadavků, sledování trendů a nových funkcionalit produktu
72
Projektový manažer v procesu „Project Guide Line“ Kompetence / Odpovědnost: lidské zdroje na projektu, výsledky projektu (termíny, kvalita, náklady, obsah), uzavírat smlouvy, rozhodování na projektu, oprávněn k zadávání úkolů projektovému týmu, vynakládání zdrojů projektu, pravomoc uspořádat finanční prostředky projektu, moc vyţadovat veškeré informace o projektu, právo eskalovat na kontrolní výbor projektu, uplatňovat proces „Project Guide Line“, zajištění komunikace na projektu, doplnění podnikových materiálů o vyuţité best-practices (příklady dobré praxe) Úkoly: konzultovat se zákazníkem, kontrolovat plány, nasazení a řešení projektu, provádět operativní projektové řízení, zajistit kvalitu, udrţovat kontakt se všemi zúčastněnými na projektu, podporovat všechna interní i externí rozhodnutí, plánování lidských zdrojů, připravit a prezentovat všechny s projektem spojené smlouvy a status reporty Definice rolí je samozřejmě rozdílná, avšak určuje odpovědnosti a úkoly, které potvrzují dříve uvedené popisy rolí pro proces řízení změn. Produktový manaţer je i zde uváděn jako osoba odpovědná za produkt a všechny k němu vztaţené poţadavky a změny, které jsou následně implementovány a testovány pod jeho dohledem. Projektový manaţer nemá k změnovému řízení definován ţádný vztah, coţ odpovídá i neexistující vazbě mezi procesem řízení projektů a procesem řízení změn. Jeho vztah k změnovému řízení je tedy vytvořen pouze v popisu změnového řízení, kde je povinen informovat produktového manaţera nebo dokonce zastávat jeho roli po dobu projektu, pokud se jedná o dodávku nového produktu. Na základě získaných poznatků a zkušeností z praxe celkově hodnotím ukotvení obou procesů ve firemní dokumentaci pozitivně, avšak vnímám jako nedostačující celkovou podporu projektového řízení. Metodické materiály k oběma procesům čítají jenom několik málo stránek. Všeobecně chybí ukotvení firemní metodiky k některé z obecně známých metodik. Většina projektů je koordinována bez hlubšího provázání aktivit s ohledem na cíle. Nechci hodnotit kvalitu jednotlivých projektových manaţerů, ale moje zkušenosti s velkými podnikovými projekty dokládají především velmi špatnou komunikaci, pozdní rozhodnutí a nedostatek informací. Ve srovnání s procesem změnového řízení vychází projektové řízení jako proces výrazně slabší, který by si
73
zaslouţil rozsáhlejší reengineering. Na základě praktických zkušeností minimálně 30 – 40% projektů, pro které je schválený rozpočet se nezačnou realizovat v plánovaných termínech a povětšinou jsou odloţeny. Projekt, jehoţ realizace se odloţí vícekrát, je v podstatě nutné znovu iniciovat a analyzovat, neboť mezitím dojde ke změně vnitřního prostředí, co se týká produktů, ale je nutné i přehodnotit nebo znovu ověřit, zda zvolený způsob řešení nového produktu stále odpovídá potřebám společnosti. V neposlední řadě kaţdé řešení v oblasti retailu je během několika let zastaralé a potřebuje zásadní inovaci. Na závěr uvádím vytvořený model popsaných procesů v jejich návaznosti na úroveň řízení a zásadní vstupy, které vedou k inicializaci procesu – viz obrázek 25.
Obrázek 25. Procesní mapa – model popsaných procesů dle [vlastní]. 74
4 Případová studie v podniku zaměstnavatele V předchozích kapitolách jsme se zabývali především popisem procesů a jejich praktickým zavedením do prostředí podniku. V předmětné kapitole se budeme zabývat případovou studií projektu transformace útvaru informatiky v korporátním prostředí podniku zaměstnavatele. Zhodnotíme dlouholetý vývoj společnosti a příčiny vzniku stavu, který byl impulsem ke strategické změně řízení a kompetencí jednotlivých částí útvaru. Budeme se zabývat jednotlivými kroky projektu, jeho cíli a očekáváním spojeným se změnou strategie. V neposlední řadě uvedeme bariéry způsobující omezení projektu, které mají vliv na rychlost a kvalitu prováděných prací.
4.1 Analýza předchozího stavu organizace Podnik zaměstnavatele je významným hráčem v oblasti maloobchodu potravin a spotřebního zboţí v evropském měřítku. Jedná se o společnost s nadnárodním charakterem a korporátní strukturou. Podnik dnes působí na trzích v 7 evropských zemích. Má přes 140.000 zaměstnanců a zahrnuje obchodní síť v počtu necelých 1.000 prodejen (otevření prodejny číslo 1.000 je plánováno na říjen tohoto roku), logistickou a distribuční síť o rozloze přes 1,5 miliónu čtverečních metrů a v neposlední řadě se zabývá výrobou vlastních masných produktů. Mateřskou a zakladatelskou firmou je firma německá, coţ mělo a má vliv na způsob řízení společnosti, ale především na trhy, které si společnost vybrala za cíl své expanze, tj. trhy výhradně východoevropské. Stav, který povaţuji za výchozí a ke kterému budu směřovat v průběhu analýzy příčin předchozího stavu organizace je datován do období hospodářské konjunkce 2007 – 2008
ve
východoevropském
regionu.
Mateřská
společnost
byla
zaloţena
v meziválečném období na území spolkového státu Bádensko-Würtembersko. Do 80. let minulého století se jednalo o úspěšnou značku, ale měřeno německým měřítkem, s lokálním charakterem, zahrnující několik desítek obchodů. Na počátku 90. let společnost zahájila výraznou expanzi po celém území Německa a její obchodní síť měla cca 100 prodejen. Pro porovnání s aktuálním stavem došlo za posledních 20 let k téměř 10-ti násobnému růstu obchodní sítě. Jedním z podpůrných nástrojů růstu podniku byl i rozvoj informačních technologií. Vzniká samostatná organizační a účetní jednotka 75
útvaru informatiky. Manaţeři společnosti cestují po Evropě a Spojených státech a sbírají podněty k rozvoji růstu společnosti. Je budováno centrální datové centrum a organizace implementuje ERP systém SAP. Na konci 90. let podnik proniká do top-10 největších retailerů na mateřském trhu. Ve stejném období společnost zahajuje expanzi nejdříve do Česka, na přelomu tisíciletí na Slovensko a pak v rychlém sledu následuje Polsko a Chorvatsko. V roce 2005 společnost zahajuje další expanzi do Rumunska a Bulharska. Jednu z hlavních příčin předchozího stavu řízení informatiky lze spatřovat jiţ ve způsobu provedení expanze. Mateřská společnost byla v období expanze do Česka plně zaměřena na plnění cílů na výchozím trhu. Cílem bylo stát se číslem 1 a k tomu byly upnuté všechny síly a procesy. Expanze do Česka se týkala malého počtu vybraných manaţerů z mateřské organizace se zkušenostmi s řízením hlavních procesů firmy, kterými byly a stále jsou Nákup a Prodej zboţí. Uvedená závislost je zřejmá ze zastoupení českého a německého managementu v top-managementu podniku. Nositelem poslání a vizí podniku byl německý management na pozicích ředitele společnosti, ředitele oblasti Nákupu, ředitele oblasti Prodeje a ředitele oblasti Technické realizace staveb. Český management doplňoval vedení v oblasti Marketingu, Personalistiky a Správy. Pod Správu spadal i útvar informatiky, přičemţ jeho zařazení o 2 manaţerské linie níţe neţ top-management odpovídal i přisuzovanému významu. Jednalo se ve své podstatě o misi podpořenou hrstkou manaţerů a finančními prostředky. Cílem bylo perforovat trh, který jiţ v té době čítal několik významných evropských hráčů. Informační technologie byly budovány na zelené louce a nezávisle na mateřské společnosti. Jediným styčným produktem zůstal SAP, ale zbytek byl budován v závislosti na lokálních poţadavcích. Pro realizaci byly vybíráni partneři s mnohdy lokálním charakterem a nedostatečnou servisní sítí. To se později ukázalo jako klíčové při další expanzi. Výsledkem byly „české“ procesy podporované „českými“ produkty. Situace byla udrţitelná při další expanzi na Slovensko. Vzhledem k stále přetrvávajícím vazbám mezi oběma bývalými členy Československa bylo moţné budovat společnost na Slovensku jako pobočku s vazbou na české partnery a ne jako nezávislou národní organizaci. Vazba přetrvala aţ dodnes a teprve v tomto roce se slovenský útvar informatiky plně osamostatní. Další expanze do Polska a Chorvatska byla také řízena z Prahy. Vzhledem k tomu, ţe byly procesy společnosti podporovány „českými“ produkty, nebylo moţné realizovat implementaci podpory procesů v plné šíři vzhledem k nedostatečné kapacitě podpory některých partnerů. Tím došlo k implementaci druhé a 76
třetí architektury. Výsledkem byly opět rozdílné produkty, rozdílný vývoj a v neposlední řadě rozdílné procesy. Podařilo se udrţet jednotnou linii v budování centrální architektury podporovanou produktem SAP coţ bylo důsledkem skutečnosti, ţe česká organizace si vybudovala oddělení s konzultantskými a programátorskými schopnostmi. Kapacita oddělení umoţňovala i vývoj pro ostatní země. Návazné decentrální systémy však byly rozdílné. Plusy daného vývoje lze jednoznačně spatřovat v rychlosti, s jakou byla společnost schopná expandovat. Řešení bylo vybíráno podle stavu na lokálním trhu v návaznosti na lokální silné partnery. To umoţnilo relativně rychlou perforaci trhu a soustředěnost podniku na hlavní cíle. Mínusy se samozřejmě neprojevily ihned, ale aţ ve fázi dalšího růstu jednotlivých organizací. Organizace rostly nejen co do velikosti obchodní sítě a počtu zaměstnanců, ale i co do počtu jednotlivých útvarů a procesů. Procesy a řízení se zkomplikovaly a jejich podpora byla stále náročnější. Jednotlivé lokální útvary informatiky byly odpovědné za zajištění výběru, vývoje a podpory produktů bez jasné definice poţadavků a dostatečných kompetencí. Impulsem k první změně se stala potřeba vybudovat vlastní distribuční síť a tím dosáhnout úspor z rozsahu nejen při odběru velkého mnoţství zboţí, ale i při dopravě samotné. Mateřská organizace se v té době potýkala s neúspěšným zavedením centrálně řízeného skladu. Řešení potřebného rozsahu na východoevropském trhu neexistovalo. Investice se odhadovala v řádu miliard korun. Bylo potřeba postupovat společně. V tomto období okolo roku 2003 vzniká strategie, která by se dala nazvat „Strategie KMO“ (Xxx Mittel und Öst Europe). Cílem předmětné strategie pro oblast informatiky bylo vybudovat a řídit společné procesní a produktové portfolio pro podniky ve východoevropském prostoru. Jednalo se tedy především o procesní a softwarovou integraci v návaznosti na integraci vizí a idejí. V dalších krocích bylo potřeba rozšířit cíle o integraci hardwarovou a technologickou v souvislosti s plánovanou expanzí do Rumunska a Bulharska. Předmětem byly především produkty podporující hlavní procesy: 1. ERP systém SAP – řízení toku zboţí (modul Material Management). 2. Pokladní systém prodejen. 3. Systém pro řízení stavu zásob na prodejně. 4. Warehouse Management Systém.
77
5. Infrastruktura – sítě, pošta, tiskové a souborové sluţby, adresářové sluţby (identity management). Počáteční stav v jednotlivých lokálních organizacích, mimo jiţ zmíněných rozdílů v softwarových produktech by se dal z pohledu infrastruktury popsat následovně: 1. Oddělené a navzájem nedostupné sítě. 2. Oddělené autentizační a autorizační domény. 3. Pošta zasílaná prostřednictvím internetu. 4. Rozličný hardware a kancelářský software (zaslaný soubor ve vyšší verzi produktu z jedné organizace nelze otevřít v organizaci druhé). Pro naplnění cílů byla vystavěna nezávislá organizační jednotka KMO. Z historických důvodů bylo její sídlo umístěno do Prahy. Jednalo se o štíhlou organizaci sloţenou ze zástupců hlavních procesů byznysu a zástupců informatiky. Ti byli vybráni z jednotlivých zemí rovnoměrně (princip evropské integrace). Organizační struktura ve vztahu k jednotlivým úrovním řízení a procesům podporovaných informatikou vypadala následovně – viz obrázek 26.
Obrázek 26. Logický model organizační struktury KMO dle [vlastní]. Základním cílem změny bylo vymezit odpovědnosti za procesy a standardy pro nadnárodní úroveň a zamezit tak strategickým rozhodnutím na lokální úrovni. Kaţdá 78
byznys oblast měla svého SuperUsera (dále pouze SU), který byl odpovědný za standardizaci procesů v dané oblasti v návaznosti na informatiku. KMO informatika byla odpovědná za definici a prosazování jednotlivých standardů ve třech klíčových oblastech: 1. Centrální systémy (SAP). 2. Decentrální systémy (POS, WMS). 3. Infrastruktura. Sběr poţadavků probíhal na lokální úrovni. Poţadavky byly posuzovány na nadnárodní úrovni příslušným SU, popřípadě nositelem mandátu a jednotně předávány k realizaci na oddělení IS. To vedlo ke vzniku produktových manaţerů odpovědných za rozvoj informačních systémů v přidělených oblastech. Cílem bylo integrované produktové prostředí podporované mezinárodními kontrakty o implementaci a následné servisní podpoře. Hlavní cíle integrace se podařilo v období 2003 – 2006 naplnit především v oblasti hlavních softwarových produktů a jednotné správě poţadavků. Hardwarová a technologická integrace postupovala velmi pomalu především z důvodu nedostatku kapacit, nemluvě o integraci nebo vůbec zavádění systémů řízení do oblasti informatiky. Dosud jsem nezmiňoval působení a roli německého útvaru informatiky, který zastával roli poskytovatele datového centra, technologie a hardwaru pro aplikační hosting systému SAP. Lokální organizace za dané sluţby platily dle dohodnutých pravidel, smluvní zajištění neexistovalo, o řízení úrovně sluţeb ani nemluvě. Organizace se tedy v období 2006 – 2007 nacházela v následujícím stavu: 1. Integrovaná podpora a vývoj v hlavních procesních oblastech na úrovni KMO. 2. Shodná organizační struktura jednotlivých funkčních útvarů na úrovni KMO. 3. Stanovené ale z důvodu nákladnosti investic pouze částečně zavedené infrastrukturní architektury. 4. Nejednotné systémy řízení informatiky – zaměření na odstraňování následků incidentů a „hašení“ problémů. 5. Lokální útvary informatiky zaměřené především na technologii. 6. Lokální útvary informatiky nemají znalost byznysu, nositelem této znalosti je SuperUser, který spadá pod oblast byznysu. Jiţ v prvních letech východoevropské integrace bylo zřejmé, ţe integrace nebude dostatečná. Dalším krokem byla integrace s mateřskou společností. Postupné sbliţování 79
započalo jiţ v průběhu budování KMO. Byly však zřejmé nepřekonatelné rozdíly v procesních a funkčních oblastech, které vycházely ze samotného konceptu expanze na východoevropské trhy, který se vyznačoval řešením v závislosti na nákladovosti. Důvody byly zřejmé. Ještě v roce 2006 byly všechny organizace s výjimkou Česka v černých číslech, rozuměj v záporném hospodářském výsledku. Ani Česko se však nebylo schopné zabývat výraznějším rozvojem, protoţe z jeho výnosů byla částečně financována expanze v ostatních zemích. V důsledku toho byly investice do rozvoje infrastruktury nedostatečné a mnohde byla provozována stará technika bez obměny. Oproti tomu zavedená koncepce v mateřské firmě odpovídala potřebám zabezpečení provozu proti výpadku a chybám. Předmětná bariéra byla zřejmá a znemoţňovala hlubší vzájemné pochopení a propojení vizí útvarů informatiky z mateřské společnosti s KMO. Zásadní rozdíly lze po důkladné analýze faktů a syntéze zjištění shrnout především do určitých oblastí – viz tabulka 5.
Tabulka 5. Oblasti rozdílů v útvarech informatiky [vlastní]. Slabé stránky KMO byly patrné především v slabé podpoře podnikových procesů, a v přílišném zaměření na rozvoj infrastruktury a technologie v důsledku jejího podceněného financování, v slabých systémech řízení a v nedostatečném sledování trendů v oblasti bezpečnosti. Autor hodnotí sledované období z pozice zaměstnance, který působil postupně v těchto pozicích: 2001 – 2003 (CZ/SK): Operating – rutinní kontrolní činnosti, linka pro hlášení incidentů, popis tzv. if-then operací, koordinace řešení se servisními partnery,
80
2003 – 2004 (CZ/SK): externí Helpdesk – předání know-how, operativní řízení dodavatelů na projektu logistického centra pro Slovensko, 2004 – 2006 (KMO): standardizace v oblasti infrastruktury – síťová adresace, jmenná konvence, hw/sw standardy, konfigurační standardy, podpora expanze do Rumunska a Bulharska, 2006 – 2008 (CZ/SK): vedoucí týmu odpovědného za správu a řízení infrastruktury, koordinace projektů v oblasti infrastruktury, budování a optimalizace znalostního Helpdesku. Jako zaměstnanec KMO pro oblast infrastruktury jsem vnímal své postavení ve vztahu k lokálním útvarům informatiky především z pozice metodického konzultanta. Jelikoţ jsem byl partnerem a ne nadřízeným lokálním útvarům, byly mé pravomoci od počátku v podstatě nulové. Hlavní náplní byla podpora expanze do nových zemí. Bohuţel na poli standardů se mi vzhledem k mé pozici dařilo působit pouze částečně. Vzhledem k historickému působení jsme měli dobrou vyjednávací pozici k CZ/SK. Díky podpoře expanze částečně i v BG a RO. Ostatní země CRO a PL respektovaly má rozhodnutí, ale v podstatě je velmi často nevykonávaly. Úspěšný jsem byl nakonec pouze a částečně v zavedení jmenných konvencí a standardizaci síťových adresných rozsahů pro LAN. Jako vedoucí týmu odpovědného za správu a řízení infrastruktury jsem se střetl s následky exponenciálního nárůstu operativy z minulých let. Předmětný nárůst byl způsoben rychlým růstem obchodní sítě a absencí jednoznačných pravidel pro provádění poţadavků. Pro zvládnutí značného mnoţství různorodých poţadavků byla značná část činností outsourcována bohuţel aţ na úroveň specifikace řešení. To mělo za následek nízkou úroveň znalostí o nastavení a architektuře infrastruktury v interním týmu. V týmu o pěti lidech nemohlo přicházet v úvahu samostatné rozhodování o rozvoji, tudíţ jsem zvolil cestu získání znalostí v centrálním útvaru informatiky. Jednoduše řečeno, jsem jezdil do Německa, obcházel jsem lidi a zjišťoval potřeby pro vybudování nutné znalosti v lokálním útvaru. Na základě získaných informací jsem byl schopen plánovat potřebné investice v předstihu na další fiskální období a následně je i čerpat. Podařilo se vybudovat a postupně převzít management konfigurací v oblasti sítí, serverů a active directory. V závěru jsme byli schopni plánovat a realizovat většinu projektů vlastními silami za částečného přispění dodavatelů pro zajištění rutinních činností. Kritické činnosti vyţadující specifickou znalost se mi dařilo zajišťovat za 81
pomoci centrálního útvaru informatiky. Další mojí snahou bylo budování a optimalizace znalostního Service Desku na bázi ITIL. O výsledcích jsem psal ve své bakalářské práci viz. [7]. Nyní se však vraťme k analýze výchozího stavu a příčinám jeho vzniku. Zhodnotili jsme si historii a proces, který vedl ke vzniku stavu 2007 – 2008. Přes uvedené slabé stránky organizace KMO byla strategie ve své podstatě úspěšná. Pro nastartování další integrace chyběla vůle na obou stranách. Východoevropské země se na úrovni topmanagementu bránily nárůstu investic s potřebnou harmonizací a samotný centrální útvar informatiky si nebyl jist podporou jednotlivých kroků převzetí řízení. Panovala nejasná situace ohledně pravomocí centrálního útvaru informatiky k lokální útvarům. Výsledkem byla spolupráce formou konzultace a dodávky řešení ze strany centrálního útvaru a následné přenechání fáze implementace a podpory na lokálních útvarech. Z toho vyplývaly odlišnosti při implementaci řešení do produktivního prostředí. Chyběla především kontrola kvality a správnosti zavedení změn do podnikového prostředí v souladu s předepsanými standardy. V roce 2007 došlo ke změně obsazení představenstva celé korporace. Jednou ze změn byla i nová tvář odpovědná za oblast Správy (viz. slovníček pojmů). Pod Správu spadá i funkční útvar informatiky. Jedním ze zásadních nových cílů bylo celkové zavedení řízení bezpečnosti – viz příloha 2. IT principy. V souvislosti s tím se informační systémy podrobily důkladnému auditu a z něj vzešly první poţadavky na zajištění bezpečnosti na úrovni lokálních útvarů. Mimochodem od tohoto období audity probíhají v různých oblastech permanentně a za účelem řízení bezpečnosti bylo vybudováno samostatné oddělení. Vraťme se však k předchozí situaci. Lokální útvary byly podle zavedeného vzoru pověřeny zavedením bezpečnostních standardů. Realizace a výklad pravidel byla plně ponechána na jejich rozhodnutí, a to nemluvě o následné kontrole. Na počátku roku 2008 došlo k úniku informací o plánované expanzi na území Bulharska ohledně pozemků, které se společnost chystala přes prostředníka zakoupit. V důsledku toho byly pozemky skoupeny skupinou spekulantů. Předmětný bezpečnostní incident ukazoval na nedostatečné zabezpečení kritických informací společnosti a přímo ohroţoval další expanzi. V důsledku toho byl mimo jiné proveden audit bezpečnostní politiky v lokálním útvaru informatiky a byla zjištěna základní pochybení při uplatňování bezpečnosti v celé organizaci. V řádu několika dnů bylo provedeno 82
zajištění formou změny na klíčových postech v řízení expanze, technického nákupu, zajištění realizace staveb a informatiky. Byl jsem ze dne na den pověřen vedením oddělení infrastruktury v Bulharsku spolu s německým spolupracovníkem, který byl pověřen řízením celého útvaru. Všem členům útvaru byla odebrána kritická oprávnění a mým úkolem bylo po dobu několika měsíců zajišťovat podporu provozu a postupně delegovat pouze nezbytně nutná oprávnění na členy lokálního bulharského týmu.
4.2 Změna strategie řízení útvaru informatiky Incident v podobě ztráty citlivých informací ukázal zcela jasně nutnost zabývat se integrací centrálního a lokálního útvaru informatiky a to nejen v oblasti podoby standardů. Bylo zřejmé, ţe je nezbytné změnit přístup centrálního útvaru a zajistit podporou při realizaci a následnou kontrolou důsledné dodrţování přijatých politik, a to nejenom v oblasti bezpečnosti. Z mého pohledu se z odstupem času jedná o opravu strategie. Podnik si velmi dobře uvědomil, ţe jiţ dávno překročil fázi počátečního růstu a ve snaze zajistit si investice ve východoevropském prostoru nemohl postupovat jinak. Zajištění investic předpokládalo stabilizaci, a to i v útvaru informatiky, a přijetí dostatečných bezpečnostních opatření. Existovala zde i jiná cesta, cesta růstu kompetencí lokálních útvarů informatiky, které však bránil fakt neochoty rozšiřovat tým ze strany lokálního top-managementu. Pro srovnání měl útvar informatiky v mateřské společnosti přes 450 zaměstnanců, zatímco útvar zajišťující podporu v CZ/SK čítal 16 osob. V uvedeném počtu nebylo a není moţné dosáhnout tzv. super-specializací, které by byly schopné udrţet krok s poţadavky centrálního útvaru. Bylo tedy pouze otázkou času, kdy ke změně strategie nastane vhodný okamţik a uvedený incident pouze pomohl rozehrát příslušnou hru, avšak nebyl její hlavní a jedinou příčinou.
4.2.1 Formulace strategie a cílů Zásah v Bulharsku se na první pohled jevil jako dočasná záleţitost. Tak byl i po dlouhou dobu prezentován. Byl jsem přizván jako expertní poradce znalý 83
východoevropského prostředí do týmu zabývajícího se formulací nové strategie. Byl jsem zavázán mlčením aţ do doby, kdy bude strategie schválena, projednána a zveřejněna. Bylo to paradoxní, jako zaměstnanec českého útvaru jsem pracoval z pověření německého útvaru v Bulharsku. Formulace strategie probíhala v několika fázích a zahrnovala přijetí vize integrace útvarů informatiky, stanovení cílů a přijetí postupu. Následovalo několikaměsíční schvalování a následná prezentace ředitelům lokálních podniků. Aţ po tomto celkovém projednání byla strategie zveřejněna a projednána s lokálními útvary. V mezidobí jsem se stal zaměstnancem centrálního útvaru s odpovědností za jednu z hlavních fází změny strategie. Ale teď jiţ zpátky na počátek. Nejdříve bylo nutné si ujasnit vizi a cíle strategie. Ke stanovení vize budoucího uspořádání organizace, kompetencí a postupů poslouţila jako vzor analýza a doporučení z materiálů společnosti Gartner (autor neuvádí materiály v bibliografii, neboť neměl moţnost se s nimi seznámit přímo). Byl analyzován model skórující korporátní integraci a nutnost lokální odpovědnosti pro podnikového řízení informatiky mapující lokální odpovědnost a korporátní integraci – viz tabulka 6.
Tabulka 6. Model podnikového řízení informatiky [vlastní – inspirace Gartner].
84
Model popisuje čtyři rozdílné přístupy v organizaci korporace v rovině korporátní integrace a přenechané lokální odpovědnosti. Jednotlivé přístupy je moţné v klíčových oblastech řízení popsat následovně:
Centralizovaný přístup Ohnisko výkonu činností vzhledem k spotřebovanému času: >85% v centrálním útvaru (strategie, politiky, kontrola, metriky) Strategie a role IT: součinnost, náklady a integrace pod centrální kontrolou, role IT útvaru je zajištění korporátní uniformity a identity Výchozí zdroje: centrálně řízené rozhodování, globální externí poskytovatelé sluţeb ve všech moţných oblastech Infrastruktura: standardizace, minimální lokální zdroje Řízení nákladů: centrální příprava a kontrola investic a provozních výdajů Změna podnikání: centrálně definovaná lidmi na korporátní centrále, směr shora dolů Kontrola: jednotné směrnice, silná architektura a řízení podle standardů
Multi-lokální přístup Ohnisko výkonu činností vzhledem k spotřebovanému času: >85% v individuálních podnikových útvarech, minimalizace centrální kontroly za současné maximalizace lokální autonomie Strategie a role IT: nezávislá IT strategie pro kaţdou lokalitu, centrální směrnice jsou pouze vzorem Výchozí zdroje: lokálně řízené rozhodování, lokální výběr poskytovatelů sluţeb Infrastruktura: převládá dodávka lokálních sluţeb Řízení nákladů: lokální kontrola, centrála nevidí náklady lokálního útvaru Změna podnikání: řízena lokálními zájmy Kontrola: rozptýlená a pravděpodobně nestandardizovaná
Federativní přístup Ohnisko výkonu činností vzhledem k spotřebovanému času: 40% na 60% poměr mezi centrálním útvarem a lokálními jednotkami, vytvářet synergii ze společného postupu vyváţeně s lokálními moţnostmi
85
Strategie a role IT: součinnost v klíčových oblastech produktů a procesů, strategické a nákladové přínosy Výchozí zdroje: část centrálně řízené, mnoho lokálně řízených podle globálního smluvního rámce, lokální smlouvy, mix lokálních, globálních a regionálních poskytovatelů sluţeb Infrastruktura: standardizace, minimální lokální úprava, část dodávek centrálně řízená na základě centrálně řízených společných sluţeb Řízení nákladů: centrální příprava a kontrola pro centrální sluţby a korporátní inovace, lokální kontrola pro lokální projekty a sluţby Změna podnikání: centrálně definovaná, odsouhlasená s lokálními jednotkami Kontrola: jednotné směrnice, řízení podle standardů, slabá centrální kontrola
Rodičovský přístup Ohnisko výkonu činností vzhledem k spotřebovanému času: 40% na 60% poměr mezi centrálním útvarem a lokálními jednotkami, vytvářet synergii ze společného postupu pouze v klíčových oblastech Strategie a role IT: součinnost v nutných a jasných případech, strategické a nákladové přínosy Výchozí zdroje: část centrálně řízené pro klíčové oblasti, mnoho lokálně řízených poskytovatelů sluţeb Infrastruktura: lokální úprava dle zavedených doporučení Řízení nákladů: lokální kontrola, centrála vidí náklady na centrálně řízené sluţby Změna podnikání: základy podnikání se řídí obecnými principy, uplatněny lokální zájmy podle poţadavků Kontrola: centrální doporučení, lokální směrnice a kontrola Gartner dále definuje makro-proces řízení útvaru informatiky ve třech zásadních rovinách z pohledu role podnikového útvaru – viz obrázek 27.
86
Obrázek 27. Makro-proces řízení informatiky dle [vlastní – inspirace Gartner]. Zmíněný makro-proces je z pohledu modelu podnikového řízení informatiky vyjádřen modelem odpovědnosti za jednotlivé části makro-procesu – viz obrázek 28. Odpovědnost můţe být plně centralizovaná, sdílená (společná) nebo lokální (autonomní) na jednotlivých úrovních makro-procesu.
Obrázek 28. Makro-proces řízení informatiky ve vztahu k podnikovému modelu řízení informatiky dle [vlastní – inspirace Gartner].
87
Z analýzy vývoje řízení informatiky je zřejmé, ţe řízení informatiky prodělalo ve vztahu ke korporátnímu řízení změnu. Ve fázi prvotní expanze do východoevropského prostoru byl přijat multi-lokální model, který se velmi brzo vyčerpal a byl nahrazen modelem rodičovským, avšak jednalo se o jakýsi hybrid rodičovského modelu, kdy vznikla „Strategie KMO“. Rodičovskou úlohu v aplikaci modelu v podniku nehrál mateřský útvar, ale nově vzniklý útvar z vybraných expertů z původních lokálních struktur. V pozdějším vývoji přebíral roli rodiče mateřský útvar informatiky. Z pohledu odpovědnosti lokálního útvaru informatiky ve vztahu k lokálním byznys útvarům je moţné vyjádřit zaměření lokálního útvaru na tři oblasti: 1. Podnikové procesy. 2. Podnikové aplikace. 3. Technologie a infrastruktura. Náplň a zaměření odpovídající počtu zaměstnanců v jednotlivých odděleních lokálních útvarů odpovídala rodičovskému modelu, kde hlavní odpovědností lokálního útvaru je podpora infrastruktury. Model zaměření lokálního útvaru ve vztahu k lokálním byznys jednotkám lze vyjádřit pyramidovým modelem – viz obrázek 29.
Obrázek 29. Model zaměření lokálního útvaru informatiky dle [vlastní]. Útvar plně zajišťoval a řídil infrastrukturu a technologické vybavení lokální organizace. Ve vztahu k SuperUserům jednotlivých byznys oblastí vystupoval zmíněný útvar jako dodavatel sluţeb pro zajištění provozu aplikací s různou úrovní znalostí pouţívaných produktů. Plně postrádal znalosti podnikových procesů, které jsou nutné pro zajištění 88
efektivní podpory. Znalost procesů a aplikací se jevila jako klíčová slabá stránka útvarů informatiky. Útvar nebyl schopen plně ovlivnit kvalitu dodávaných sluţeb a v případě zásadních nebo urgentních problémů postrádal plné kompetence k rozhodování o řešení. Z nutnosti většího důrazu na korporátní integraci bylo moţné vybrat modely centralizovaného nebo federativního přístupu. Vzhledem k tomu, ţe i nadále jsou provozovány v jednotlivých zemích různé lokální aplikace a systémy pro podporu neklíčových procesů, které nebylo v dané fázi výhodné centralizovat, bylo rozhodnuto o strategickém federativním přístupu. Ten se vyznačuje vysokou mírou integrace na jedné straně a vysokou lokální odpovědností na straně druhé. Je vyţadována maximální součinnost obou partnerů. Dalším důleţitým strategickým rozhodnutím bylo obrazné převrácení pyramidového modelu zaměření lokálního útvaru informatiky. Obecné cíle pro budoucí model útvaru informatiky byly stanoveny následovně: 1. Jasně definované kompetence pro IT sluţby mezi národním a mezinárodním útvarem informatiky. 2. Stejné, jasné a stabilní IT procesy pro všechny země. 3. Srovnatelná a měřitelná struktura a procesy podpory ve všech zemích. 4. Způsobilá technologie a podnikové know-how v lokálních útvarech. 5. Zaměření na podnikové procesy a lokálně provozované systémy. 6. Jasné rozdělení na IT a Non-IT komponenty. Kroky vedoucí k dosaţení uvedených cílů byly rozděleny na dvě fáze. Důvodem pro rozdělení byla obava ze zatíţení lokálního útvaru dvěma protichůdnými trendy. První trend směřující k převzetí části kompetencí v oblasti infrastruktury zvyšuje riziko fluktuace na straně odpovědného lokálního týmu. Druhý trend v oblasti získání znalostí o podnikových procesech zvyšuje nároky a mění zaměření zaměstnanců ostatních lokálních týmů. Výsledkem by mohlo být pnutí v lokálním útvaru a následné sníţení akceschopnosti.
Fáze 1. – Jednotné infrastrukturní služby Úkoly: 1. Harmonizace organizační struktury IT. 2. Harmonizace a centralizace úkolů a aktivit infrastruktury.
89
3. Koordinace a vyhotovení jasného rozdělení kompetencí mezi národním a mezinárodním útvarem pro všechny produkty a sluţby. 4. Nasazení a prosazení všech relevantních IT procesů v zemích. Očekávání: 1. Uvolnění kapacit zdrojů v oblasti infrastruktury v lokálních útvarech. 2. Rekvalifikace uvolněných zdrojů a orientace na pochopení procesů.
Fáze 2. – Zaměření na podnikové procesy Úkoly: 1. Převzetí IT úkolů a aktivit, které jsou prováděny v byznys útvarech. 2. Moţný přesun zaměstnanců se znalostmi IT úkolů a aktivit z byznys útvarů do útvaru informatiky. 3. Zaměstnání nových zaměstnanců v případě chybějících zdrojů. To znamená, ţe byla zvolena následující strategie. Nejdříve převzít část kompetencí z oblasti infrastruktury z lokálního do centrálního útvaru. Očekává se uvolnění části zdrojů a sníţení závislosti lokálního útvaru na expertních znalostech z oblasti infrastruktury. Uvolněné zdroje bude moţné v případě zájmu rekvalifikovat a zaměřit se na získání znalostí o podnikových procesech. Cílem je udrţet počet zaměstnanců lokálního útvaru na přibliţně stejné úrovni, maximálně povolit nepatrné navýšení.
4.2.2 Cílová organizační struktura a kompetence útvaru Původní organizační struktura útvaru informatiky a rozdělení kompetencí mezi jednotlivými týmy nebylo v jednotlivých zemích stejné. Z toho pramenily nejasnosti při mapování poţadavků mezi centrálním a lokálním útvarem na úrovni jednotlivých týmů. Bylo nutné připravit čitelnou a především stejnou strukturu pro všechny útvary. Cílová organizační struktura převzala rozčlenění po vzoru mateřského útvaru. Došlo k rozšíření z dvou pilířů na tři a vymezení hlavních kompetencí řízení útvaru do pilíře čtvrtého – viz obrázek 30.
90
Obrázek 30. Model změny organizační struktury lokálního útvaru informatiky dle [vlastní]. Původní organizační struktura členila úsek na centrální a necentrální správu systémů. Nová struktura je vystavena z pohledu firemních procesů. Infrastruktura jako základní kámen dodává sluţby poskytovatele komunikace, autentizace a souborové sluţby. Ware (zboţí) se zabývá podporou procesů spojených s řízením toku zboţí – nákup, prodej, logistika a marketing. Verwaltung (správa) se zabývá podporou procesů spojených se správou – finance, controlling, personalistika, revize, technický nákup ale i IT procesy. Nová organizační struktura odráţí rozdělení podpory pro hlavní podnikové procesy spojené s celým distribučním řetězcem a pro podpůrné procesy pro ostatní oblasti, bez kterých by nemohl podnik fungovat. Kompetence lokálního útvaru informatiky byly obecně definovány následovně: 1. Podpora podnikových aplikací a infrastruktury. 2. Realizace IT procesů a standardů. 3. První kontaktní partner v případě výpadků a chyb v aplikaci nebo infrastruktuře. 4. V případě chyb odpovědný za zajištění komunikace mezi lokálním byznys útvarem a mezinárodním útvarem informatiky. 5. Provádí a koordinuje lokální roll-out aplikací a infrastruktury. 6. Překlady pro aplikace. 7. Prosazování IT bezpečnostních politik. 8. Řízení licencí. 91
9. Dodrţování standardů v souladu s lokální legislativou v oblasti IT. 10. Lokální kontrakty s poskytovateli servisu nebo sluţeb v souladu se stanovenou politikou mezinárodního rámce. 11. Odsouhlasení technické způsobilosti aplikace k lokální implementaci. 12. Kontrola provizí lokálních poskytovatelů sluţeb. 13. Odpovědný za plánování kapacit lokálních IT komponent. 14. Monitorování a kontrola datových toků. 15. Podpora integračních testů na lokální úrovni. V předmětné souvislosti byly vymezeny i kompetence mezinárodního útvaru. Seznam rozhodně není úplný, jeho hlavní význam spočívá v definici kompetencí, které před provedenou změnou nebyly transparentní. Vyhrazené kompetence mezinárodního útvaru: 1. Autorita pro řízení rozhodování o vývoji aplikací (řízení produktů). 2. Výběr technologií a systémových architektur. 3. Vedení implementací v souladu s IT principy – viz příloha 2. 4. Systémová a aplikační dostupnost v souladu s rámcovými SLA. 5. Řízení dodavatelů pro centrálně podporované sluţby a produkty. 6. IT bezpečnost – stanovení politik a vedení. 7. Centrální řízení uţivatelských rolí ke klíčovým systémům (informacím). 8. IT eskalační management. 9. Vlastník procesu pro IT procesy. 10. Technická koordinace integračních testů. Z autorova popisu je lehce patrná určitá schizofrenie při pojmenování centrálního útvaru informatiky. V popisu vývoje se vyskytuje pojem „útvar mateřské firmy“ nebo „centrální útvar“. Při popisu fáze formulace strategie a cílů se navíc vyskytne pojem „mezinárodní útvar“. Nejedná se o chybu. Paralelně s popisovaným transformačním projektem, který je předmětem diplomové práce, probíhá i projekt další – oddělení a vytvoření samostatného německého lokálního útvaru informatiky. Původní funkční jednotka byla vybudována pro podporu informatiky v německé společnosti. Přizpůsobování útvaru novým výzvám a potřebám postupně oddělovalo činnosti jednotlivých oddělení na činnosti spojené čistě s podporou německé organizace a činnosti spojené s podporou mezinárodní. Jak jsem uváděl v kapitole 1.4, je cíleně budována oddělená mezinárodní jednotka s mezinárodními kompetencemi. V závislosti na tom a pro zajištění obdobné transparentnosti procesů a úrovně sluţeb je připravováno 92
vyčlenění zaměstnanců z centrálního útvaru do lokálního německého útvaru. Očištěný centrální útvar bude jiţ opravdu mezinárodní. Vliv paralelního projektu na předmětný transformační projekt je minimální, naopak mnohá rozdělení odpovědností a operační postupy vypracované v průběhu transformace jsou nyní přebírány i do německého lokálního útvaru.
4.3 Projekt implementace strategie První fází projektu implementace strategie jsem byl pověřen spolu s kolegou, který řídil po převzetí bulharský útvar informatiky, na počátku roku 2009. Jeho hlavní kompetencí je definice a rozdělení kompetencí organizační struktury lokálních útvarů. Oba se podílíme na prosazování centrálních IT procesů. Mým úkolem je harmonizace a centralizace úkolů a aktivit týmů infrastruktury a vyhotovení jasného rozdělení kompetencí mezi národním a mezinárodním útvarem pro všechny produkty a sluţby z oblasti infrastruktury. Cílem implementace bylo obdobné členění kompetencí jaké vykrystalizovalo z převzetí řízení informatiky v Bulharsku. Bylo však nutné zvolit jinou cestu ve shodě s firemní kulturou a především včlenit převzaté sluţby do jednotlivých mezinárodních týmů. Poučení z Bulharska bylo jasné, zvolené řešení (aţ násilné převzetí), zapříčinilo demotivaci pracovníků bulharského útvaru. Z původních 9 zaměstnanců zůstal dnes ve firmě pouze jeden. Řešení „quick & dirty“ (rychle a špinavě) nepřipadalo v úvahu. Dalším problémem převzetí řízení bulharského týmu byla nepřipravenost jednotlivých členů týmu mezinárodního. Z tohoto důvodu i více neţ rok po převzetí byly stále nutné zásahy a podpora z mé strany při řízení a implementaci projektů a nutných konfigurací. Na začátku bylo nutné stanovit cíle srozumitelné pro vedení lokálního útvaru a inspirující k přijetí cílů za vlastní. Cíle byly stanoveny takto: 1. Jasné rozdělení odpovědností. 2. Stabilní a jasné IT procesy, nástroje pro podporu a stejná struktura = transparentnost. 3. Mezinárodní standardy, mezinárodní vlastnictví, lokální aktivity. 4. Jasný koncept pro případnou novou expanzi. 5. Celkově niţší úroveň ohroţení. 6. Definované nutné schopnosti pro zaměstnance, snadné zaškolení, nezávislost na jednom zaměstnanci. 93
7. Stejný reporting. Autorem práce navrţená a přijatá vize vyjadřující nutnost maximalizovat spolupráci národního a mezinárodního útvaru: Think global, act local (mysli/uvaţuj globálně, konej lokálně).
4.3.1 Metodika implementace změny V organizaci neexistovala expertní znalost, jak provést potřebnou transformaci, jakými postupy se řídit, které kroky učinit. Pro úspěch transformace bylo nutné vytvořit její společný základní obsah ve formě zjednodušené metodiky. Bylo nutné definovat jednotlivé kroky, které budou shodné pro transformaci sluţeb k jednotlivým produktům a jejich výstupy, které budou odráţet cílový stav – viz obrázek 31. Dále bylo nutné jednoznačně vymezit obsah z mnoţiny všech produktů, logicky rozčlenit jednotlivé produkty a sluţby na úrovně a k nim vymezit budoucí kompetence viz obrázky 32 - 34.
Obrázek 31. Jednotlivé kroky transformace sluţeb a jejich výstupy dle [vlastní]. Při definici kroků jsem vyšel ze standardního ţivotního cyklu návrhu produktu a definoval jsem čtyři fáze pro vytvoření kaţdé nové sluţby. Tyto fáze jsou: analýza, návrh, nasazení a údrţba sluţby. Kaţdé jednotlivé fázi odpovídá určitý výstup ve formě dokumentu – viz obrázek 31. 1. Analýza – popis současného stavu a poţadavky na změnu sluţby. 2. Architektura – popis architektury řešení sluţby.
94
3. Nasazení – dokumentace změnového poţadavku, dokumentace výsledné konfigurace, dokumentace rozdělení odpovědností, dokumentace rolí. 4. Údrţba – operační postupy a návody pro údrţbu sluţby, popis známých chyb. Obsah kaţdé sluţby se skládá z několika úrovní – viz obrázek 32. Pro kaţdou úroveň je nutné vymezit odpovědnosti mezi oběma sloţkami. Jednotlivé úrovně byly definovány pyramidovým modelem. Pouţité znázornění vystihuje podstatu sluţeb jen v určitém přiblíţení. Úrovně administrace a operativa jsou spíše dimenzí kaţdé jednotlivé úrovně hardware, operační systém a aplikace neţ jejich nadřízenou úrovní.
Obrázek 32. Logická architektura sluţeb produktu infrastruktury dle [vlastní]. O poznání lépe zachycují podstatu sluţeb a rozdělení kompetencí modely pro serverové a síťové produkty – viz obrázky 33 - 34. Pro jejich návrh jsem se inspiroval modelem OSI pro standardy síťových sluţeb.
95
Obrázek 33. Logická architektura sluţeb serverového produktu dle [vlastní]. Na základě těchto metodických podkladů bylo moţné vytvořit zadávací listinu projektu a projednat její schválení s managementem – viz příloha 3.
Obrázek 34. Logická architektura sluţeb síťového produktu dle [vlastní]. Zadávací listina se odkazuje na vypracovanou metodiku vedení projektu a obsahuje vymezený rámec sluţeb a produktů, které jsou předmětem změny v transformačním projektu. Těmito sluţbami jsou: 1. Active Directory a s ním spjaté sluţby (domény, politiky, schéma, souborové, tiskové, autentizační a autorizační sluţby). 2. Lotus Notes (mail, aplikace v systému).
96
3. Zálohování. 4. Sítě a zabezpečení sítí.
4.3.2 Aktivity a dokumentace projektu Prvním krokem po schválení zadání projektu byla analýza stávajícího stavu a navazující vytvoření cílové architektury uvedených sluţeb. Cílem byl sběr informací o aktivech a konfiguracích systémů spravovaných do té doby lokálním útvarem v jednotlivých zemích. Pro tuto analýzu jsem si vyţádal dočasné administrátorské přístupy do příslušných systémů, abych mohl provést šetření. Vypracoval jsem si seznam otázek, ke kterým jsem si následně zjišťoval odpovědi nebo si nechal vyhotovit příslušnou dokumentaci stavu. Analýzu jsem prováděl na místě a po jejím zhotovení jsem procházel její výsledky s vedoucím oddělení infrastruktury. Tím jsem měl zajištěnu zpětnou vazbu a verifikaci informací v analýze obsaţené. Navíc bylo moţné jiţ v této fázi upozornit na nesrovnalosti a pobídnout lokální útvary k jejich odstranění. Paralelně s analýzou bylo moţné řešit návrh cílové architektury. Nestavěli jsme na zelené louce a poţadavky na architekturu nám byly v podstatě známé. Úkolem bylo cílovou architekturu z pohledu zasaţených sluţeb optimalizovat a harmonizovat. Cílová architektura byla vypracována společně se zainteresovanými týmy z mezinárodního útvaru, coţ byl nutný předpoklad, aby architektura mohla být schválená a danými týmy později implementována a udrţována. Vyšli jsme tedy ze stávajících standardů a moţných řešení. V oblastech s nevhodnou architekturou pro lokální organizace jsme nechali její cílový model neuzavřený s úkolem jej postupně dobudovat na základě podnětů z lokálních útvarů. Výsledný návrh architektury jsem převedl do specifického katalogu sluţeb a k nim přiřadil aktuální stav v jednotlivých zemích – viz příloha 4, coţ umoţnilo a stále umoţňuje měření aktuálního stavu jednotlivých lokálních architektur a jejich souladu s cílovým stavem. Další nezbytně nutnou podmínkou před implementací byla detailní matice kompetencí k jednotlivým produktům potaţmo poskytovaným sluţbám. Bylo nutné transparentně vymezit, které aktivity budou zajišťovány ze strany mezinárodního úseku. Zvláštní důraz jsem kladl především na popis kompetencí, které se výrazně měnily, a to zvláště na ty, které budou svým charakterem vyţadovat nutnost spolupráce obou jednotek. 97
Bylo nutné zváţit, ţe pro vyjasnění hranic kompetencí je nutné analyzovat i daný produkt. Stanovené kompetence musí odpovídat moţnostem produktu a variabilitě nastavení rolí a oprávnění. Nejasně nebo nesprávně vymezené kompetence, neodpovídající moţnostem produktu by totiţ vyţadovaly častou a interaktivní součinnost obou řešitelských týmů, pro kterou v běţném provozu, pokud není plánovaná, neexistují dostatečné kapacity a dostatečně kvalitní komunikační kanál. Proto bylo nutné vymezit odpovědnosti tak, aby nedocházelo ke zbytečným interakcím. Časté interakce by přinesly sníţení výkonu, prodlouţení celkového dodání jednotky produktu sluţby (např. řešení incidentu nebo změny) a zvýšené nároky na reţijní komunikaci. Výsledná matice kompetencí – viz příloha 5. Vzhledem k některým kritickým oprávněním a poţadavkům na bezpečnost, které si vyhrazují vlastnictví rolí pouze na straně mezinárodního útvaru, nebylo moţné předmětný postup rozdělení dodrţet vţdy. V uvedených případech je nutné vypracovat detailní operační postup, ve své podstatě mini-proces s definovanými vstupy (nezbytně nutné informace k provedení úkonu), aktivitami a rolemi obou týmů při popisovaných činnostech a výstupy. Některé sluţby si samozřejmě vyţadovaly detailnější rozpracování architektury nebo kompetencí. Jejich dokumentace byla a je vytvářena v případě potřeby pro zpřesnění v rámci plánování implementace jednotlivých částí výsledného produktu. Vypracovaná dokumentace je zveřejněna na firemním wiki (známý redakční systém, nejedná se o intranet, kvalita a obsah je plně na redaktorovi dané sekce – není vyţadováno schválení) portálu a přístupná autorizovaným uţivatelům z mezinárodního i lokálního útvaru.
4.3.3 Plánování a rozpočet projektu Po
provedení
analýzy
aktuálního
stavu
lokálních
architektur
a
porovnání
s poţadovaným cílovým stavem bylo moţné se začít zabývat přípravou plánu. Aktivity jsem hned v první fázi po dohodě s kontrolním výborem projektu rozdělil do tří fází ve vztahu k aktuálnímu stavu specifikací jednotlivých cílových architektur a ve vztahu k rozpočtu. V prvním roce projektu, tj. do konce fiskálního roku 2009, byly naplánovány a provedeny aktivity nevyţadující dodatečné financování z lokálního nebo centrálního rozpočtu. Jednalo se především o převzetí administrace nekomplikovaných produktů a 98
standardizace konfigurací. Dalšími aktivitami byla snaha o reorganizaci instancí systémů tak, aby bylo moţné docílit vzájemné nezávislosti sluţeb dle definovaného standardu. Tyto aktivity byly naplánovány prioritně s vyuţitím zdrojů do konce fiskálního roku. Fiskální rok je definován jako období od března do února roku příštího. V současnosti lze hodnotit danou fázi jako ukončenou bez nutnosti investic a s minimálním zpoţděním. Druhá fáze zahrnuje fiskální rok 2010. Pro tuto fázi byly naplánovány aktivity a investice k produktům a sluţbám s jasně definovanou cílovou architekturou. Pokud tedy bylo zřejmé CO, KDE a JAK je potřeba udělat, byl proveden odhad nákladů a investic spojených s danou aktivitou. Na základě odhadu byla v průběhu října aţ listopadu roku 2009 připravena dokumentace pro zařazení do plánování pro fiskální rok 2010. Po obhájení plánu akcí byly podklady pro jednotlivé země schváleny a zapracovány do plánu investic a nákladů (budget). Jednotlivým aktivitám je ve výsledku přiřazeno controllingem projektové číslo. Čerpání těchto nákladů podléhá mé kontrole. Závěrečná prezentace plánu a rozpočtu proběhla na setkání managementu mezinárodního a lokálních útvarů – viz obrázek 35 - 36.
Obrázek 35. Rozpočtové poloţky dle katalogu sluţeb dle [vlastní].
99
Obrázek 36. Rozpočtové náklady investice dle katalogu sluţeb dle [vlastní]. Závěrečná fáze proběhne ve fiskálním roce 2011. V průběhu roku 2010 dochází k postupnému zpřesňování poţadavků na ostatní sluţby. Na základě poţadavků bude dokončen vzor cílové architektury. Po vytvoření návrhu dojde stejným procesem jako pro druhou fázi ke schválení aktivit a rozpočtu pro plán investic na rok 2011. K jednotlivým aktivitám jsou vypracovány detailní plány ve vztahu k finančním zdrojům
a
investicím
dle
náročnosti
implementace.
Plány
jsou
průběţně
vyhodnocovány, upravovány a aktualizovány především podle dostupných lidských zdrojů. Jednotlivé změny konfigurací byly pro jednotlivé země nebo lokality plánovány jako jednotlivé zásahy. Zásahy pak byly zdokumentovány jako změnové poţadavky v podpůrném nástroji ITSM a prošly procesem řízení změn v souladu s pravidly procesu – viz kapitola 2. Jako ukázku přikládám seznam vlastních vytvořených změn – viz export v příloze 6. Jedná se pouze o krátký výčet změn, které byly zaloţeny přímo autorem práce. Spousta ostatních změn byla zaloţena a prováděna kolegy z ostatních lokálních nebo mezinárodních týmů dle vzájemné dohody o odpovědnosti za změnu.
100
4.4 Bariéry a chyby na projektu Od začátku bylo zřejmé, ţe nejkritičtějším místem projektu bude komunikace. Standardní projektová komunikace s důrazem na jednoznačnost a transparentnost byla pouze podmínkou nutnou, ale ne postačující. Rozdíly plynou především z komunikace v anglickém jazyce, který není ani jednomu z dotčených týmů mateřským, a navíc mezi sedmi rozdílnými národnostmi. Z tohoto zastoupení plynou jisté kulturní rozdíly, které se odráţí v nutnosti řešit komunikaci s kaţdým týmem jiným způsobem. Mojí předností na projektu je funkční způsob vyjednávání se všemi zmíněnými národnostmi. Proto jsem velmi často pověřován i dalšími úkoly mimo rámec projektu, které vyţadují umění jednání s dotyčným týmem. Nebudu provádět hodnocení jednotlivých národů a lokálních týmů, přesto uvedu alespoň dva diametrálně odlišné způsoby komunikace. S bulharskými kolegy se mi osvědčilo, jemně řečeno, nevyjednávat. Ponecháním určité svobody v rozhodování se bulharští kolegové dostanou do problémů, nejsou schopni se rozhodnout a odvolávají se k autoritám v lokálním managementu ohledně toho, jak má být co provedeno. Tento problém v pocitu nekompetentnosti je v bulharské pobočce všudypřítomný. Na druhou stranu mnoho věcí je tam rozhodováno z autority vysoce postaveného top-managera bez úvah, zda je daný poţadavek chytrý a dobrý. Proto neváhám při prosazování termínů a zásahů uplatňovat mě svěřenou autoritu a v případě nutnosti si zajišťuji i podporu svých nadřízených. Nediskutujeme tedy o tom CO a JAK, ale pouze o KDY. Pravým opakem jsou kolegové polští. Vzhledem ke své velikosti, ale myslím i vzhledem k národní hrdosti, neradi přijímají rozhodnutí od někoho jiného. Dokonce se nezdráhám vyjádřit pocit, ţe přijímají lépe rozhodnutí od kolegů německých neţ ode mne, jako Čecha. To vede k určitým komplikacím při komunikaci. I s tím jsem se naučil ţít a v podstatě s nimi provádím určitou před-konzultaci před kaţdým zásadním rozhodnutím. Tím, ţe si jiţ v zárodku vyříkáme případné zdroje nepochopení nebo případné názorové neshody, je následná mezinárodní diskuze snazší a konstruktivní. Dalším zásadním překáţkou byla taktika při vyjednávání ohledně cílů projektu. Od začátku jsem zastával názor o nutnosti otevřeně informovat o dopadech na členy lokálního týmu. Bylo zřejmé, ţe někteří velmi kvalitní členové lokálních týmů s certifikací v oblasti pouţívaných produktů těţce ponesou ztrátu oprávnění pro administraci. Nakonec byly povinností informovat členy týmu pověřeni vedoucí 101
lokálních útvarů. Přijetí dané skutečnosti odpovídalo velikosti a dosaţené zkušenosti týmů. Například malý chorvatský tým změnu přijal s povděkem a je do dneška jedním z prvních, kde se změny aplikují. Oproti tomu větší, strukturované a lépe znalostně vybavené týmy polské, české nebo rumunské změnu přijaly jako nutné zlo. Pokud bych měl hodnotit za sebe, toto bylo z mého pohledu největší riziko projektu. Pokud by se nepodařilo zajistit spolupráci s lokálními členy týmu se znalostí o lokálních konfiguracích a specifikách, znamenalo by to v podstatě nepřekonatelnou bariéru při dalším postupu. Výsledkem mohla být také destabilizace týmů z důvodu odchodu klíčových zaměstnanců. Pro tento případ byl schválen krizový budget pro případné navýšení platu na klíčových pozicích tak, aby byla zachována kontinuita zkušeností minimálně do ukončení transformace. Zde je třeba zmínit fakt, ţe paradoxně v tomto případě pomohla ke stabilitě týmů především současná globální ekonomická krize v celém regionu. Rychlost provádění prací ze strany lokálních i centrálních týmů je různá, stejně jako kvalita. Poměrně rychle jsem přišel na nutnost zajištění kontroly kvality prováděných prací. Kontrola je nutná, ať uţ z důvodu prohlášení o dokončení úkolu, kdy se při následné kontrole zjistí, ţe úkol ani zdaleka není splněn, nebo i v případech, kdy je poţadovaný úkol splněn špatně. Důvodem je posloupnost komunikace: mezinárodní tým – já – vedoucí lokálního týmu – člen týmu delegovaný na úkol. Různé jazykové znalosti, znalosti prostředí a produktové znalosti vedou k chybným nastavením. Východiskem je postupné přebírání odpovědnosti do mezinárodního týmu a provádění úkolu pouze jednou pověřenou osobou za daný úkol ve všech zemích shodně. To je v podstatě i jeden z cílových stavů po dokončení transformace. V průběhu projektu se narazilo na některá omezení a bariéry projektu. Mezi zásadní, které povaţuji za významné, patří následující: 1. Rezistence a neochota spolupráce lokálního týmu. 2. Nárůst délky řešení incidentů vyţadujících interakci s centrálním útvarem. 3. Nedostatečná vyzrálost centrálního útvaru. 4. Omezení vyplývající z vymezené oblasti dopadu změny. U některých lokálních týmů lze vypozorovat určitou
rezistenci a neochotu při
spolupráci v případě poţadavků na podporu zásahů, které jsou přímo spjaty s pozdějším převzetím pravomocí nad produktem. Toto omezení bylo v podstatě přijato a akceptováno. Některá rozhodnutí nebo odezvy jsou z uvedeného důvodu opoţděné V případě nutnosti pak dochází k ‚přátelské‘ eskalaci. V tomto směru je smířlivý postup 102
v pořádku – viz riziko destabilizace lokálního týmu v případě změn na klíčových postech. Jak jsem jiţ uvedl východiskem je postupné plnění cílů transformace a přebírání odpovědnosti za konfigurace do centrálního týmu. Dalším problémem, který je velmi často zmiňován při argumentaci vedoucí k obhájení původní úrovně oprávnění, je nárůst délky řešení incidentů. Nejedná se o všechny incidenty, pouze o incidenty vyţadující interakci mezi lokálním a centrálním útvarem. Odebráním některých oprávnění nemůţou být některé poţadavky uţivatelů zpracovány ihned, ale je nutná jejich delegace. Zde je zřejmá celková absence řízení úrovně sluţeb. Uţivatel byl v minulosti zvyklý na řešení ‚ihned‘. Vzhledem k tomu, ţe není obecně definována úroveň sluţeb v rámci sluţeb poskytovaných interně útvarem informatiky koncovému uţivateli, naráţí lokální útvar na dopady změny, jejímţ výsledkem je sníţená akceschopnost a moţnost zaručit se za dodání řešení do určeného termínu. Pro uspokojivé řešení nevidím jiné východisko neţ nasazení procesu řízení úrovně sluţeb, na kterém se snad jiţ pracuje. Jak jsem jiţ uvedl, mým předpokladem na začátku projektu byla především omezení vyplývající z rizik neposkytnuté spolupráce ze strany lokálních týmů při zajištění činností nebo ze strany lokálního managementu při zajištění potřebných investic. Mým největším překvapením bylo a stále je značná flexibilita s jakou se lokální týmy se změnou vyrovnávají. Oproti tomu jako zásadním omezením se ukázala nedostatečná vyzrálost centrálních týmů. Centrální týmy, které přebírají definované činnosti a zajišťují centrálně poskytované sluţby, neměly dostatek zkušeností pro řízení takto rozsáhle poskytovaných sluţeb. Mou mylnou představou na počátku byl předpoklad, ţe bude stačit analyzovat, co a kde je potřeba a kolegové z centrálního týmu to jiţ provedou. Setkal jsem se v průběhu se zásadními nedostatky v komunikaci, a to nejen mezi centrálními a lokálními týmy, ale a to především i v komunikačních bariérách mezi samotnými týmy centrálního útvaru. Neschopnost dohodnout se na poţadavcích a jednotlivých krocích zásahu v rámci několika týmů mě postavila a stále staví do role koordinátora a mediátora. Na druhou stranu mi to dává moţnost přímého vhledu do problematiky a moţnosti rozhodnout v případě nejasností o způsobu řešení. Toto omezení jsem tedy překonal přijmutím role koordinátora a v některých případech i přijmutím odpovědnosti za rozhodnutí. Omezení, které představovalo nepřekonatelnou bariéru, však bylo nutné řešit jiným způsobem. Předmětným omezením byla nedostatečná znalost produktu ‚active directory‘ pro centrální řízení uţivatelských, počítačových i serverových účtů v centrálním útvaru. Vzhledem k chybějící znalosti 103
bylo v podstatě nemoţné navrhnout přijatelné řešení pro centrální i lokální útvar. Způsob nasazení podle zkušeností z centrálního útvaru by byl neefektivní a byrokratický. S touto překáţkou jsem se potýkal několik měsíců. Ve hře byla dokonce obměna na pozici vedení odpovědného oddělení v centrálním útvaru a nahrazení mou osobou. Dané řešení jsem s díky odmítl, protoţe by ve finále znamenalo přesunutí plné odpovědnosti za řešení na mě, aniţ bych měl moţnost docílit akceptace řešení v rámci týmu. Řešením nakonec bylo zaměstnání vytypovaného nejprogresivnějšího experta na daný produkt z rumunského lokálního týmu. Tím byla bariéra překonána, tým získal potřebnou znalost a navíc zkušenosti, a transformační projekt mohl dál pokračovat. Poslední z bariér na projektu je zásadní omezení dané samotným vymezením dopadu projektu. Od počátku byly navrţeny dvě fáze. První zahrnovala reorganizaci sluţeb vztaţených k infrastruktuře mezi lokálním a centrálním týmem. Druhá fáze má obsahovat změny ve vztazích mezi lokálním týmem a byznysem. Bohuţel se stále více ukazuje absence rozhodnutí o struktuře sluţeb v samotném lokálním útvaru. Lokální útvar, jak jsem uvedl v kapitole 4.2.2, se rozdělil na tři týmy. Dva týmy zaměřené na podporu byznysu a procesní znalosti a jeden tým za infrastrukturu. Bohuţel se stále více ukazuje, ţe takovéto rozdělení organizační není a nemůţe být správným schématem podpory samotné. V praxi se ukazuje nárůst zátěţe oddělení infrastruktury především v oblasti rutinních činností, jako je změna hesla nebo odblokování uţivatele. Výsledkem je trend rostoucí zátěţe týmu infrastruktury, tudíţ trend opačný neţ bylo očekáváno. Řešením by byl zásah do organizace lokálních týmů. Tohoto zásahu se bohuţel top-management centrálního útvaru obává. Doposavad se měnila náplň práce pro zaměstnance týmu a lokálnímu manaţerovi byly ponechány vcelku volné ruce, jak bude úkoly rozdělovat a jak bude zajišťovat podporu. Zásah do struktury fungování lokálních týmů by byl v podstatě i zásah do pravomocí lokálního manaţera a v tom je právě kámen úrazu. Obecně jsem jiţ eskaloval nutnost rozhodnout o struktuře podpory ne z pohledu organizační struktury, ale z pohledu servisně orientované podpory podle jednotlivých úrovní podpory. Řešení jsou ve své podstatě pouze dvě: 1. Vyčlenění rutinních úkonů a delegování na první úroveň – externí Servicedesk. 2. Vyčlenění rutinních úkonů a poskytnutí oprávnění pro týmy Ware & Verwaltung – filtrace incidentů. Schéma servisní podpory pro podporu prodejen s externím Service-deskem je na obrázku 37. 104
Obrázek 37. Servisně orientovaná podpora – prodejny - externí Service-desk dle [vlastní]. V uvedeném případě by rutinní činnosti byly prováděny na tzv. první úrovni podpory dle dostupných pravidel a postupů s přiděleným oprávněním. V druhém případě – viz obrázek 38 by z pohledu uţivatele prodejny přebíral odpovědnost za rutinu pracovník kontaktního procesního oddělení.
Obrázek 38. Servisně orientovaná podpora – prodejny – bez Service-desku dle [vlastní]. Osobně se kloním k první variantě v případě zemí s větším mnoţstvím obchodů a pro druhou variantu pro země menší. Celkovým problémem je i fakt, ţe sluţby nejsou měřené, tudíţ nelze vyhodnotit skutečnost, zda zatíţení opravdu narůstá. Předmětnou oblastí bude nutné se začít zabývat pro zajištění obdobné kvality sluţeb ve všech zemích.
105
Výsledky Ve vztahu k procesu řízení změn byly zavedeny vlastní navrţené změny procesu s těmito výsledky: 1. Modely scénářů v závislosti na iniciátora a oblast dopadu pomohly zlepšit komunikaci při zavádění změn mezi lokálními a centrálními útvary. 2. Zavedením povinnosti informovat o připravovaných změnách lokální nebo centrální útvar podle umístění vykonavatele přiřadila v procesu kontrolní roli manaţerovi lokálního útvaru informatiky. Navrţené změny procesu vedly k odstranění bariér při vyuţití procesu mimo centrální útvar. Výsledkem je vyšší propustnost procesu a více zdokumentovaných změn, coţ se potvrdilo i podle reportů – viz obrázek 13. Dalším přínosem v oblasti procesu změnového řízení byla: 1. Dokumentace a zajištění schválení standardních změn pro všechny lokální útvary centrálně. 2. Jednotný návrh struktury a jmenné konvence řešitelských týmů pro lokální útvary v rámci podpůrného nástroje ITSM. Standardní změny nejsou příliš vyuţívány. Můj přínos se projeví při realizaci integrace procesu řízení standardních změn do nástroje ITSM. Navrţené a zdokumentované změny poté budou lépe vyuţitelné. Návrh struktury týmů se realizoval a v současné době se bez připomínek pouţívá. Umoţnil jasnější delegaci a komunikaci v rámci nástroje ITSM při procesech Incident a Change Management. V souvislosti s transformačním projektem v organizaci jsem se podílel na analýze a formulaci cílů a strategie transformačního projektu. Prosadil jsem „federativní“ přístup k řízení lokálního útvaru. Připravil jsem budoucí model lokálního útvaru informatiky a jeho hlavní cíle pro oblast řízení a podpory infrastruktury. Navrhl jsem vizi transformačního projektu, která je nyní s oblibou citována – „Think global, act local“. Pro transformační projekt jsem navrhl a popsal jednoduchou metodiku. V rámci metodiky jsem navrhl dokumentaci a její vzory. Vypracoval jsem přehledné modely sluţeb pro snazší chápání obsahu změny a cílového stavu. Zpracoval jsem zadávací listinu projektu a zajistil její úspěšné schválení.
106
V průběhu projektu jsem postupně provedl analýzu stávajícího stavu, komunikoval a navrhl cílovou architekturu sluţeb a k jednotlivým produktům/sluţbám vyjednal matici kompetencí. Úspěšně jsem obhájil investice nutné pro druhou fázi projektu v řádu 1.5 miliónu eur. Úspěšně jsem prosazoval pouţití procesu změnového řízení v rámci transformačního projektu a sám jsem jej důsledně vyuţíval. Úspěšně jsem prováděl projektovou aktivní komunikaci, a proto se mi podařilo v rámci moţností přemostit bariéry mezi centrálními a lokálními útvary, a také i v rámci samotného centrálního útvaru mezi jednotlivými týmy. Výsledkem je získaná autorita v rámci centrálního útvaru, která je nepoměrně vyšší neţ mé pracovní zařazení v organizační hierarchii. Úspěšně jsem se zasadil o odstranění bariér a omezení transformačního projektu, coţ dovolilo uvaţovat o úspěšném splnění náročného procesu popsané změny. Na bariéry člověk v průběhu projektu naráţí, takţe jiţ nyní vím o dalších, které bude nutné překonat, a další se jistě v budoucnosti ještě objeví.
107
Závěr Za cíle předloţené práce jsem si vybral jak cíle teoretické a metodické související se zpracováním příslušné literatury, tak cíle praktické související s průběhem a výsledky probíhajícího transformačního projektu. Prvním cílem bylo uvést do souvislostí řízený rozvoj podniku a proces strategického řízení, který je jeho základním nástrojem pro cílený a bezpečný rozvoj, kdyţ se dokáţeme pro-aktivně a systematicky vypořádávat s riziky, omezovat slabé stránky, vyuţívat silné stránky a příleţitosti. Tuto oblast jsem podrobně zpracoval v první kapitole za přispění uvedené a citované literatury. Jako příklady jsem dále uvedl trendy v organizaci zaměstnavatele, které dávají tušit cíle strategického řízení podniku a navazující informační strategii pro útvar informatiky, ve kterém působím. Druhým cílem práce byl podrobný popis a analýza procesu řízení změn u firmy, jeho model, role, kritická místa a metriky. Východiskem pro analýzu procesu mi byly poznatky o poţadavcích na proces podle ITILu verze 2, které jsem zpracoval ve své bakalářské práci. Popsal jsem a důkladně analyzoval proces zavedený v organizaci zaměstnavatele s přispěním firemních organizačních pokynů a manuálů a kriticky zhodnotil jeho nedostatky v druhé kapitole práce. Uvedl jsem vlastní výsledky v souvislosti s navrţenými změnami a optimalizací procesu a zabýval se doporučeními ohledně taktiky provádění změn s velkým dopadem na ţivý organismus podniku. V předmětné souvislosti je nutné kriticky zhodnotit současný stav procesu řízení změn v podniku zaměstnavatele a vyjádřit přesvědčení o nutnosti optimalizace procesu v blízké budoucnosti, která zajistí především transparentnost prováděných změn. Procesu chybí detailnější reporting, který by zajišťoval přenos informací na niţší řídící úrovně. Střední management nemá k dispozici nástroj na hodnocení výkonnosti svého oddělení, coţ také platí ve vztahu k reportům pro změny prováděné v lokálních útvarech. V neposlední řadě postrádám reporty vztaţené k produktům pro produktové
108
manaţery. Dané nové výkonnostní indikátory by přiblíţily význam a přínosy procesu na taktickou úroveň řízení a zajistily by nový impuls pro rozvoj a zlepšování procesu. Další kritickou oblastí procesu řízení změn je řízení řešení problémů. Jeho vyšším vyuţitím by došlo k zvýšení počtu změnových poţadavků vázaných na odstranění chyby v systému. Tím by se všeobecně dala lépe měřit výkonnost útvaru informatiky, a to nejenom ve střední hodnotě délky řešení incidentů, ale i ve schopnosti účinně řešit příčiny chyb, které následně paralyzují produktivní provoz. S provázaností na incidenty a chyby souvisí i zpětná vazba při vyhodnocení kvality provedení změny. Chybí moţnost provázat vzniklý incident na uskutečněnou změnu. Dalšími nutnými kroky je nutnost optimalizace kvality dat v databázi produktů a podpora zpracování standardních změn v podpůrném softwarovém nástroji. Uvedené slabiny procesu jsem diskutoval s manaţerem a vlastníkem procesu s následujícími výsledky. Standardní změny budou do systému zavedeny od 06/2010. Probíhá reengineering procesu řízení problémů. Kvalitní reporting zatím není moţný i z důvodu nekvalitní databáze produktů. Z tohoto pohledu se v nejbliţším období zaměřím na diskuze ohledně moţností zkvalitnění produktové databáze s výhledem na její vyuţití při následujícím reportingu. Třetím cílem byl popis analýzy a průběhu strategického transformačního projektu sloţek útvaru informatiky v podniku zaměstnavatele. Příslušnou část jsem detailně zpracoval ve čtvrté kapitole. Zabýval jsem se analýzou historického vývoje a příčin stavu vedoucího ke změně strategie. Zpracoval jsem a popsal proces stanovení cílů a formulace strategie a následnou implementaci transformačního projektu. Na závěr jsem identifikoval, analyzoval a snaţil se odstranit omezení a chyby na uvedeném projektu. Cíle první fáze projektu: 1. Jasné rozdělení odpovědností. 2. Stabilní a jasné IT procesy, nástroje pro podporu a stejná struktura = transparentnost. 3. Mezinárodní standardy, mezinárodní vlastnictví, lokální aktivity. 4. Jasný koncept pro případnou novou expanzi. 5. Celkově niţší úroveň ohroţení. 6. Definované nutné schopnosti pro zaměstnance, snadné zaškolení, nezávislost na jednom zaměstnanci. 109
7. Stejný reporting. Úkoly probíhající první fáze projektu jsou: 1. Harmonizace organizační struktury IT. 2. Harmonizace a centralizace úkolů a aktivit infrastruktury. 3. Koordinace a vyhotovení jasného rozdělení kompetencí mezi národním a mezinárodním útvarem pro všechny produkty a sluţby. 4. Nasazení a prosazení všech relevantních IT procesů v zemích. Očekávání první fáze projektu: 1. Uvolnění kapacit zdrojů v oblasti infrastruktury v lokálních útvarech. 2. Rekvalifikace uvolněných zdrojů a orientace na pochopení procesů. Úkoly první fáze transformačního projektu se postupně plní a pomáhají dosaţení stanovených cílů. Projekt prozatím nenaplnil očekávání ohledně uvolnění zdrojů v oblasti infrastruktury v lokálních útvarech. Speciálním šetřením a vyhodnocením jsem zjistil, ţe důvodem je mnoţství rutinních poţadavků zpracovávaných na úrovni lokálního útvaru a nové činnosti spojené se zajištěním bezpečnosti, která byla v minulosti opomíjena. Další podstatnou příčinou je chybějící strategie pro rovnoměrné rozdělení rutinních činností v rámci lokálního útvaru mezi všechna oddělení. K tomuto rozhodnutí chybí v současnosti politická vůle ve vedení. Bude nutné do budoucna zváţit strategii interního nebo externího Service-Desku pro zajištění první úrovně podpory a kontaktu s interním zákazníkem (uţivatelem). Kompetence a pravomoci mne svěřené však tuto oblast nezahrnují. Jsem tudíţ velmi skeptický ohledně brzkého rozhodnutí v dané oblasti. Podnik si v současnosti není schopen nutnou strategii v předmětné oblasti vypracovat. Hlavní příčinnou této nerozhodnosti je z mého pohledu chybějící vyhodnocení a měření sluţeb poskytovaných lokálním útvarem. Nelze vyhodnotit faktické zatíţení lokálního útvaru a jeho trendy. Na základě toho chybí srovnání jednotlivých lokálních útvarů ve vztahu k výkonnostním indikátorům. Takto neměřená sluţba nemůţe být ani při nejlepší vůli optimalizována. Závěrem uvádím přehledově vlastní přínos k popisované problematice: 1. Přehledně a strukturovaně jsem zpracoval popis a návaznosti procesu strategického řízení na proces změnového řízení.
110
2. Vypracoval jsem modely scénářů procesu řízení změn pro komunikaci mezi lokálními a centrálními útvary. 3. Zavedl jsem povinnost informovat o připravovaných změnách lokální nebo centrální útvar podle umístění vykonavatele. 4. Zdokumentoval jsem a zajistil schválení standardních změn centrálně pro všechny lokální útvary. 5. Podílel jsem se na jednotném návrhu struktury a jmenné konvenci řešitelských týmů pro lokální útvary v rámci podpůrného nástroje ITSM. 6. Kriticky jsem zhodnotil slabá místa procesu řízení změn a nalezl moţný potenciál pro zlepšené předmětného procesu. 7. Podílel jsem se na analýze a formulaci cílů a strategie transformačního projektu. 8. Prosadil jsem „federativní“ přístup k řízení lokálního útvaru. 9. Připravil jsem budoucí model lokálního útvaru informatiky a jeho hlavní cíle pro oblast řízení a podpory infrastruktury. 10. Navrhl jsem vizi transformačního projektu – „Think global, act local“. 11. Pro transformační projekt jsem navrhl a popsal jednoduchou metodiku a v rámci metodiky jsem navrhl dokumentaci a její vzory. 12. Vypracoval jsem přehledné modely sluţeb pro snazší chápání obsahu změny a cílového stavu. 13. Zpracoval jsem zadávací listinu projektu a zajistil její úspěšné schválení. 14. V průběhu projektu jsem postupně provedl analýzu stávajícího stavu, komunikoval a navrhl cílovou architekturu sluţeb a k jednotlivým produktům/sluţbám vyjednal matici kompetencí. 15. Úspěšně jsem obhájil investice nutné pro druhou fázi projektu v řádu 1.5 miliónu eur. 16. Úspěšně jsem prosazoval pouţití procesu změnového řízení v rámci transformačního projektu a sám jsem jej důsledně vyuţíval.
111
17. Úspěšně jsem prováděl projektovou aktivní komunikaci, a proto se mi podařilo v rámci moţností přemostit bariéry mezi centrálními a lokálními útvary, a také i v rámci samotného centrálního útvaru mezi jednotlivými týmy. 18. Úspěšně jsem se zasadil o odstranění bariér a omezení transformačního projektu. 19. Kriticky jsem zhodnotil dosavadní průběh transformačního projektu a uvedl moţné oblasti zlepšení. V souvislosti s cíli práce jsem přesvědčen, ţe se mi podařilo všechny předmětné cíle splnit a k tomu přidat významnou část vlastního přínosu k dané problematice.
112
Seznam použité literatury: 1. SYNEK, Miloslav a kol. Podniková ekonomika. 4. vyd. Praha : C. H. Beck, 2006. 473 s. Beckovy ekonomické učebnice. ISBN 80-7179-892-4. 2. MALLYA, Thaddeus. Základy strategického řízení a rozhodování. 1. vyd. Praha : Grada, 2007. 252 s. ISBN 978-80-247-1911-5. 3. HRONÍK, František. Hodnocení pracovníků. 1. vyd. Praha : Grada, 2006. 128 s. ISBN 80-247-1458-2. 4. GÁLA, Libor; POUR, Jan; TOMAN, Prokop. Podniková informatika. 1. vyd. Praha : Grada, 2006. 484 s. Management v informační společnosti. ISBN 80247-1278-4 5. BUDIŠ, Petr. Strategické řízení informačních systémů. Praha, 2009. 80 s. přednášky z výuky ve formě powerpointové prezentace. 6. KOTTER, John P. Leading Change. 1. vyd. Boston, Massachusetts : Harvard Business school Press, 1996. 186 s. ISBN 0-87584-747-1 7. PROCHÁZKA, Zdenek. Modelování činnosti Helpdesku z pohledu ITIL. Praha : 2008. 56 s. bakalářská práce. 8. MÖNCHER, Enrico; RÖCKEL, Steffen. Manual ITSM Portal. ver. 2.14. Neckarsulm : 2008. 100 s. manuál produktu ve formě elektronického dokumentu. 9. SVOZILOVÁ, Alena. Projektový management. 1. vyd. Praha : Grada, 2006. 356 s. ISBN 80-247-1501-5. 10. ŠEBEK, Václav. Plánování a řízení projektů IS – Základní pojmy a principy. Praha, 2008. 49 s. přednášky z výuky ve formě pdf prezentace.
113
Seznam použitých obrázků a tabulek: Obrázek 1. Podstata podnikání vyjádřená prostřednictvím základních účetních výkazů dle [1]. Obrázek 2. Ţivotní cyklus podniku dle [1]. Obrázek 3. Elementy strategického myšlení dle [2]. Obrázek 4. Proces strategického řízení dle [2]. Obrázek 5. Management versus Leadership dle [6]. Obrázek 6. Výstupy a rozhraní ITIL dle [7]. Obrázek 7. Model procesu Support s důrazem na proces řízení změn [vlastní]. Obrázek 8. Vstupy procesu Change Management [firemní organizační pokyn]. Obrázek 9. Scénář provedení změny v centrálním útvaru bez dopadu na lokální [vlastní]. Obrázek 10. Scénář provedení změny v centrálním útvaru s dopady na lokální [vlastní]. Obrázek 11. Scénář provedení změny v lokálním útvaru s dopady na lokální [vlastní]. Obrázek 12. Vztahy jednotlivých rolí k objektům procesu řízení změn [vlastní]. Obrázek 13. Měsíční počet ukončených změn podle priority a kategorie dle [firemní reporty]. Obrázek 14. Počet ukončených změn ze vstupu procesu Problem Management dle [firemní reporty]. Obrázek 15. Měsíční počet změn podle kategorie a statusu: úspěšně ukončený a neúspěšně ukončený dle [firemní reporty]. Obrázek 16. Celkový počet změn dle statusu zdokumentovaných v systému od 06/2007 dle [firemní reporty]. Obrázek 17. Koláčový graf poměrů změn dle statusu zdokumentovaných v systému od 06/2007 dle [firemní reporty]. Obrázek 18. Úrovně sestavování release v podniku dle [firemní materiály]. Obrázek 19. Workflow overview in ITSM tool dle [8]. Obrázek 20. Základny projektového managementu dle [9]. Obrázek 21. Ţivotní cyklus projektu dle [10]. Obrázek 22. Logický model vztahů v rámci skupin procesů řízení projektu dle [9]. Obrázek 23. Fáze procesu „Project Guide Line“ dle [firemní organizační pokyn]. Obrázek 24. Vazby procesu „Project Guide Line“ a SWEP dle [firemní organizační pokyn]. 114
Obrázek 25. Procesní mapa – model popsaných procesů dle [vlastní]. Obrázek 26. Logický model organizační struktury KMO dle [vlastní]. Obrázek 27. Makro-proces řízení informatiky dle [vlastní – inspirace Gartner]. Obrázek 28. Makro-proces řízení informatiky ve vztahu k podnikovému modelu řízení informatiky dle [vlastní – inspirace Gartner]. Obrázek 29. Model zaměření lokálního útvaru informatiky dle [vlastní]. Obrázek 30. Model změny organizační struktury lokálního útvaru informatiky dle [vlastní]. Obrázek 31. Jednotlivé kroky transformace sluţeb a jejich výstupy dle [vlastní]. Obrázek 32. Logická architektura sluţeb produktu infrastruktury dle [vlastní]. Obrázek 33. Logická architektura sluţeb serverového produktu dle [vlastní]. Obrázek 34. Logická architektura sluţeb síťového produktu dle [vlastní]. Obrázek 35. Rozpočtové poloţky dle katalogu sluţeb dle [vlastní]. Obrázek 36. Rozpočtové náklady investice dle katalogu sluţeb dle [vlastní]. Obrázek 37. Servisně orientovaná podpora – prodejny - externí Service-desk dle [vlastní]. Obrázek 38. Servisně orientovaná podpora – prodejny – bez Service-desku dle [vlastní]. Tabulka 1. Shrnutí etap vývoje strategického řízení dle [2]. Tabulka 2. Činnosti a odpovědnosti v procesu Software Change Management [vlastní]. Tabulka 3. Pouţité kategorie změn – klasifikace dle dopadu [vlastní]. Tabulka 4. Klasifikace projektů dle priorit dle [firemní organizační pokyn]. Tabulka 5. Oblasti rozdílů v útvarech informatiky [vlastní]. Tabulka 6. Model podnikového řízení informatiky [vlastní – inspirace Gartner].
115
Příloha č. 1.
Podnikatelské principy Spokojenost zákazníka utváří naše chování Silná cenová politika určuje naší pozici na trhu Rychlá rozhodování a jednoduché pracovní procesy nám zajišťují úspěch Naše zásada je férovost vůči každému Respektujeme se a podporujeme navzájem Firemní dohody jsou dodržovány Jak centrála tak provoz pracuje systémově V rámci dobré firemní atmosféry musí být pochvala, uznání i schopnost konstruktivní kritiky na denním pořádku Obklopujeme se schopnými pracovníky, zastupitelnost ve všech oblastech je zajištěna
116
Příloha č. 2.
IT principy (poslání a pravidla útvaru informatiky) Následující IT Principy slouţí k společnému pochopení dalšího vývoje IT v xxxxx (podniku zaměstnavatele). Proto jsou závazné pro všechny zaměstnance skupiny společností. Principy jsou uvedeny dle priorit. Nemohou být diskutovány jednotlivě, ale musí být chápány z pohledu obsahu a priorit všech principů. Máme v úmyslu dosáhnout v maximální moţné míře mezinárodní standardizace a podle moţností co nejméně výjimek. Specifikace principů budou definovány v organizačních směrnicích. 1. Zabezpečení provozu a bezpečnost IT systémů je nejvyšší prioritou. 2. Uskutečňujeme nejhospodárnější řešení v rámci celé společnosti – Náklady a prokazatelný přínos bude základem pro rozhodování 3. Celková optimalizace pracovních procesů bude vţdy stát v popředí 4. Pouţíváme jednotné mezinárodní pracovní procesy a systémy 5. Standardní řešení jsou upřednostňována. Uzpůsobujeme naše pracovní procesy standardním řešením. 6. Změny v pracovních procesech se musí ověřit mezi vlastníkem systému a IT a mohou být provedeny aţ po odsouhlasení vlastníka systému 7. Systémové vlastnictví IT zahrnuje: provoz systémů, systémové architektury, uţívané programy a příslušné IT procesy 117
Příloha č. 3.
Zadávací listina projektu
118
Příloha č. 4.
Katalog prvků služeb
119
Příloha č. 5.
Matice produktů/služeb a odpovědností
120
Příloha č. 6.
Seznam změn z procesu řízení změn – ukázka z ITSM
121
Příloha č. 7.
Významový slovník pro použité pojmy Dobrá strategie – chápeme ji jako strategii vypracovanou ve vztahu k podnikatelským cílům podniku na základě analýzy, předpokladem je vyuţití strategického řízení, jedná se tedy o strategii jako výstup procesu strategického řízení s maximálním vyuţitím silných stránek podniku a příleţitostí na trhu. Výkonnostní potenciál podniku – chápeme jako schopnost podniku generovat zisk a drţet v rovnováze obrat, likviditu a čisté obchodní jmění. Hodnota podniku – je schopnost podniku generovat zisk, má vliv na jeho hodnotu pro vlastníka, například cena akcie vyjadřuje poměrnou část hodnoty podniku. Zásadní změna = Transformační změna = Strategická změna – změna s velkým dopadem a rozsahem, obvykle mění a ovlivňuje více procesů a více oddělení. Lokální útvar – funkční organizační jednotka ze struktury dceřiné (národní) společnosti. Mezinárodní útvar = Centrální útvar – funkční organizační jednotka ze struktury nadnárodní řídící společnosti. Změna softwaru – je
definována jako změna produktu, který je identifikován
v seznamu produktů a řešení jako aplikace – viz. kategorie produktu APP v produktové databázi podpůrného portálu ITSM. Změna infrastruktury - definována jako změna produktu, který je identifikován v seznamu produktů a řešení jako infrastruktura – viz. kategorie produktu INF v produktové databázi podpůrného portálu ITSM. Ware (zboţí) se zabývá podporou procesů spojených s řízením toku zboţí, patří sem z pohledu organizační struktury podniku funkční útvary: nákup, prodej, logistika a marketing. Verwaltung (správa) se zabývá podporou procesů spojených se správou, patří sem z pohledu organizační struktury podniku funkční útvary zajišťující podporu hlavním procesům: finance, controlling, personalistika, revize, technický nákup ale i IT procesy. 122
Verwaltung (správa) je i název jednoho z funkčních útvarů v organizační struktuře podniku, který má zastoupení na úrovni představenstva podniku. Tato oblast podniku zahrnuje finance, controlling a informatiku.
123
