1 Řízení IT služeb: rychle, jednoduše a jasně

1 Řízení IT služeb: rychle, jednoduše a jasně
Při následujícím putování různými oblastmi řízení IT služeb je možné mnohé objevit. Kapitolu je
přitom nutné chápat jako úvod do tématiky. Každý bude jistě schopen pochopit, že není možné
kompletní řízení IT organizace s rozmanitými charakteristikami jednotlivých podniků vyložit na
několika stranách v plném rozsahu. Následující text tak představuje vstupní bod a podává přehled
tématiky.
Vertikální úroveň
Úroveň I
Strategické
plánování
Dohled, Rozvoj a řízení změn
Zaměření IT
na strategii
podniku
IT strategie
Definice IT
služeb
Řízení inovace
na bázi IT
Kontrola
a Audit
Trvalý rozvoj
IT služeb
Provoz IT
služeb
Úroveň II
Řízení IT
projektů
Údržba a
podpora
Informační
systémy a
externí služby
Sladění
procesů
Řízení změn
Zajištění
IT služeb
Bezpečnost
a prostředí
Dohled
a Vyhodnocení
Řízení změn
a Rozvoj
IT Projekty
Obrázek 1 – Přehled tematických oblastí v rámci řízení IT služeb dle metody INNOTRAIN IT
Tato kapitola je rozdělena do tří oddílů, které je možné znovu najít jako úrovně v metodice IT
INNOTRAIN (viz obrázek 1):
Plánování strategie jako vrchní horizontální úroveň kombinuje jak strategické, tak také taktické
aspekty řízení IT služeb. Aktivity na této úrovni se vyznačují relativně dlouhým časovým
horizontem, na který berou zřetel, a stanoví rámec, v němž mohou probíhat operativní činnosti.
Více informací k této úrovni najdete přímo v kapitole 3.1.
Nižší horizontální úroveň popisuje provoz IT služeb a na základě toho každodenní činnost IT ve
firmě. Jak se vyhnout poruchám? Jak zajistit, aby byl správný server k dispozici ve správný čas?
Jak obstarát nový hardware? Všechno toto jsou otázky, na které odpovídá kapitola 3.2.
1
Závěr tvoří kapitola Sledování, zlepšení a změna. Zobrazena vertikálně na mapě modulů ITSM se
tato kapitola zabývá průřezovými tématy, která se týkají jak strategie a taktiky, tak také
operativního působení. Jmenovat by zde bylo možné například témata shoda (Compliance), řízení
změn nebo také projektové řízení, která jsou uvedena v kapitole 3.3.
1.1 Strategické plánování
Vertikální úroveň
Úroveň I
Strategické
plánování
Dohled, Rozvoj a řízení změn
Zaměření IT
na strategii
podniku
IT strategie
Definice IT
služeb
Řízení inovace
na bázi IT
Kontrola
a Audit
Trvalý rozvoj
IT služeb
Úroveň II
Provoz IT
služeb
Řízení IT
projektů
Údržba a
podpora
Informační
systémy a
externí služby
Sladění
procesů
Řízení změn
Zajištění
IT služeb
Bezpečnost
a prostředí
Dohled
a Vyhodnocení
Řízení změn
a Rozvoj
IT Projekty
Každý podnik by měl jasně definovat své strategické cíle, aby mohl i v budoucnu úspěšně působit
na trhu. Tyto cíle a požadavky by se měly shodovat s nadřazenou vizi a misi. Při definici
strategických cílů lze použít zásadu SMART. Cíle by podle této zásady měly být
Specific (specifické),
Measurable (měřitelné),
Achievable (dosažitelné),
Realistic (realistické) a
Time related (termínované).
Aby bylo možné zhodnotit obchodní cíle na základě těchto pěti kritérií, vezmou se v úvahu faktory
jako ukazatele trhu (např. podíl na trhu, značka, image firmy, obrat), finanční ukazatele (např.
2
příjmy, návratnost investic, cash flow, rentabilita) nebo podnikové ukazatele (např. kapacita, doba
provedení, stav zásob).
Plánování strategie se skládá ze dvou hlavních kroků:
tvorba strategie a
hodnocení strategie.
Tvorba strategie začíná analýzou stávající situace (interní a externí), pokračuje stanovením cílů a
vede nakonec k vytvoření strategického plánu. Hodnocením strategie se rozumí kontrola
strategických možností na základě tří hlavních kritérií úspěchu:
vhodnost (bude to fungovat?)
realizovatelnost (může se to skutečně realizovat?) a
akceptace (bude to akceptováno?).
Informační technologie (IT) poskytuje četné možnosti, aby se dosáhlo strategických cílů a zadání, o
které se usiluje. IT však musí být vzato v úvahu již ve velmi rané fázi plánování strategie.
1.1.1 Zaměření IT na strategii podniku
Při zaměření strategie IT pro malé a střední podniky (MSP) se hlavní zájem zaměřuje na praktický
užitek IT a s ním související koncepci. Avšak i u MSP musí být respektováno sladění obchodní
strategie, strategie IT, struktury IT a struktury obchodu. Tyto souvislosti objasňuje následující graf.
3
řídí
Firemní strategie
Strategie IT
Struktura firemních
činnosti
podporuje
řídí
řídí
podporuje
ovlivňuje
formuje
Struktura IT
omezuje
Obrázek 2 – Vzájemné propojení strategie a struktury IT ve firmě
Obchodní strategie (Business Strategy) popisuje, jaké střednědobé a dlouhodobé ekonomické cíle
podnik sleduje. Abychom zůstali u příkladu „Karlovy dílny“, bylo by Karlovým strategickým
ekonomickým cílem získat větší počet zákazníků, aby byla jeho dílna optimálně vytížená.
Strategie IT se vytváří a definuje na základě obchodní podnikové strategie. Karlovou strategií IT by
mohlo být, že posílí svoje vystupování online, aby získal více zákazníků, a tak lépe vytížil svou
dílnu. Strategie IT však může také naopak ovlivnit obchodní strategii. Nové technologie, které byly
oceněny během strategie IT, mohou umožnit použití nových produktů nebo služeb, a tak ovlivnit
budoucí obchodní strategii. V podniku, který jsme použili jako příklad, nabízí Karel během své další
obchodní činnosti prostřednictvím své webové stránky nejen rezervační systém, ale úspěšně si
také buduje místo na trhu náhradních dílů.
Konstrukce IT zase vychází ze strategie IT. Aby zlepšil svou přítomnost na internetu, musí Karel
poskytnout a řídit nový hardware a software. Tak jako při konstrukci budovy je nutné dbát na její
funkčnost, možnost její rekonstrukce a bezpečnou statiku (v případě IT by se ale mělo mluvit spíše
o bezpečnosti údajů a dosažitelnosti). Konstrukce IT tak popisuje dynamickou souhru všech
součástí IT za účelem podpory strategie IT. Konstrukce IT má samozřejmě vliv na strategii IT.
Zůstaňme u srovnání s konstrukcí budovy: budovu, která byla původně plánována jako obytný
dům, lze jen těžko přestavět na hotel/restauraci. Decentralizovaná konstrukce IT může být
4
změněna v centralizovanou pouze s vysokými náklady. Jinými slovy: konstrukce IT by měla být co
možná nejflexibilnější, aby co nejlépe podporovala strategii IT.
Konstrukce obchodní činnosti (Business Architecture) definuje obchodní procesy a jejich sladění,
aby podporovala i strategii podniku. Optimalizace těchto obchodních procesů může být dosažena
změnami konstrukce IT, ale může jí být také zabráněno technicky podmíněnými omezeními.
Při podpoře obchodní strategie prostřednictvím investic do IT je středem zájmu přínos hodnoty IT
pro podnik.
Aby bylo možné zcela pochopit přínos hodnoty IT, musí být téma posuzováno z různých hledisek.
Nejdříve se musí zjistit, zda se použitím IT se stanovenými náklady dosáhne optimálního výsledku.
Za druhé by se mělo zkoumat, zda je podnik schopen si s pomocí IT zajistit konkurenční výhody a
prostřednictvím investic do IT dosáhnout vyšších zisků. Za třetí musí být zohledněn vliv společnosti
na její zákazníky a je nutné si položit otázku, v jakém rozsahu se výhody předají zákazníkům nebo
v jakém rozsahu je zákazníci požadují.
Aby se IT orientovalo na podnikatelské cíle, resp. na stávající obchodní procesy, mělo by se
vedení podniku zaměřit na následující oblasti:
Strategická orientace – s hlavním cílem zajistit správné propojení obchodních plánů a plánů
IT. K tomu musí být hodnoty, které navíc IT vytvoří, definovány, trvale zajištěny a
kontrolovány. Kromě toho musí být postupy IT a postupy podniku vzájemně sladěny.
Value Delivery – zde stojí ve středu zájmu praktické využití navíc vytvořených
hodnot. Tím se garantuje, že IT skutečně poskytne slíbené strategické výhody,
přičemž je ve středu zájmu optimalizace nákladů.
Řízení zdrojů– s hlavním cílem optimalizovat investice do zdrojů vztahujících se
k IT, resp. jejich řízení. K nim patří aplikace, informace, infrastruktura a
zaměstnanci. Zde se dbá zejména na optimalizace vědomostí a infrastruktury.
Řízení rizika – zde je klíčovým bodem vytvořit vědomí existence rizika u členů
společnosti od nejvyššího managementu až po posledního zaměstnance. V této
souvislosti je potřebné pochopit požadavky sladění (Compliance) a přiřazení
odpovědností za řízení rizika v rámci podniku.
Měření výkonnosti – tématem tohoto bodu je následně monitorovat a kontrolovat
různé úkoly a projekty, co se týká implementace strategií, využívání zdrojů a
poskytování služeb. K tomuto účelu mohou být použity různé nástroje jako
Balanced Scorecards, aby se zajistilo, že požadavky vytyčené v rámci strategie
mohou být realizovány v cílech, které lze měřit.
Směr obchodní činnosti a IT se začíná krystalizovat na nejvyšší úrovni managementu během
vytváření strategie. Přitom je nutné vzít v úvahu větší množství požadavků:
5
Orientace musí prokázat zlepšení některého obchodního plánu – každý návrh
projektu by měl obsahovat finanční ukazatele vztahující se k nákladům a příjmům,
které jsou s ním spojeny (např. diskontovaný peněžní tok/cash flow, očekávaný
finanční zisk/výnos). Příznivci projektu by měli být odpovědní za jeho dokumentaci.
Kromě toho by měly být pravidelně kontrolovány výsledky.
Orientace musí být při dalším rozvoji obchodní činnosti udržována na aktuálním
stavu: všechny změny v okolí podniku a uvnitř podniku vlastní projekt ovlivňují. Se
změnou poměrů by se mělo počítat již v projektu a měla by být zohledněna při
plánování časového harmonogramu a při sestavování rozpočtu projektu. Výměna
informací mezi oddělením IT a zbývajícími odděleními podniku je potřebná,
protože v opačném případě „technokraté obchod již nebudou dostatečně
respektovat a orientace nebude dostatečná“.
Při orientaci je nutné překonávat překážky, které stojí v cestě realizaci cílů. Rozdíly mezi
koncepcí projektu a realitou se projeví teprve během realizace projektu. Počáteční plány
projektů by se měly řídit podle cílů, kterých je možné jejich během provedení dosáhnout.
Všechny vzniklé problémy by měly být dokumentovány a zkontrolovány ve vztahu k celému
projektu.
Orientace musí být plánována – aby byl původní plán projektu vždy aktuální, musí
být dokumentovány dohody veškerých změn. Během fáze realizace musí být
časový harmonogram, rozpočet, rozsah procesů atd. projektu stále aktualizovány.
Tento plán by měl být centrálním zdrojem poznatků, které se týkají postupu a
změn projektu.
U projektů IT musí být středem zájmu požadavky uživatele, přičemž je nutné
respektovat výhody pro uživatele a pro podnik. Samotné IT nemůže řešit žádné
problémy podniku. Viděno z finanční perspektivy, přináší IT především náklady,
oprávněnost výdajů za IT však mohou prokázat pozitivní vlivy na obchod. O
tématu „Jaká částka má být vydána za IT?“ by se mělo diskutovat jako o odpovědi
na následující otázku: Jaké výhody přináší IT?
Aby bylo možné měřit stupeň orientace IT na firemní činnosti, tedy objasnit otázku, jak dobře
spolupracují oblasti pro technické a obchodní procesy podniku, měli bychom vzít v úvahu
následující faktory a s nimi související otázky:
Vyspělost komunikace – jak dobře si rozumějí zaměstnanci v oblastech technika a
obchodní činnost? Probíhá komunikace bez problémů a často? Komunikuje Vaše
firma efektivně s poradci, dodavateli a partnery? Přikládá se interně váha i
předávání poznatků?
Vyspělost měření kompetence/hodnoty – jak dobře měří firma vlastní výkon a
hodnotu vlastních projektů? Hodnotí po ukončení projektů, co proběhlo dobře a co
špatně? Zlepšuje své interní procesy, aby mohl příští projekt proběhnout lépe?
6
Vyspělost Governance – jak dobře uvádí Vaše firma do souladu obchodní strategii
s prioritami týkajícími se IT, technického plánování a tvorby rozpočtu? Vycházejí
aktuální projekty ze znalosti obchodní strategie? Podporují tuto strategii?
Vyspělost partnerství – v jakém rozsahu vybudovalo obchodní oddělení a oddělní
IT skutečné partnerství na základě vzájemné důvěry a v jakém rozsahu jsou
připravena se dělit o rizika a odměny?
Rozsah a vyspělost konstrukce – v jakém rozsahu se dále rozvíjela technologie,
aby zvýšila svůj výkon jako čistá podpora obchodních procesů? Jak toto přispělo
k růstu, konkurenceschopnosti a zvýšení zisků podniku?
Vyspělost schopností – disponují zaměstnanci potřebnými schopnostmi pro
efektivní práci? Jak chápou techničtí zaměstnanci centrální faktory vlivu na
obchodní činnost a jsou seznámeni s procesy podniku? Jak dobře rozumějí
zaměstnanci obchodních oddělení relevantním technologickým koncepcím?
Investice týkající se IT vyžadují pečlivý finanční management, aby se dosáhlo plánovaných
výhod. Kromě toho musí být stanoveny přiměřené priority týkající se rozsahu projektů IT. V případě
speciálních aktivit pro spravování investic do IT se jedná o:
Rámcové koncepce finančního řízení – potřebné pro spravování a udržování
investic do IT a nákladů na zařízení a služby IT. Při tom by se mělo použít
portfolio, které obsahuje investice týkající se IT, obchodní scénáře a rozpočty IT.
Stanovení priorit v rámci rozpočtu IT – proces, který je potřebný pro rozhodování,
je stanovení priorit při přiřazování zdrojů IT. Přiřazení zdrojů je nutné pro procesy,
projekty a údržbu. Cílem tohoto procesu by mělo být dosáhnout z portfolia firmy co
možná nejvyšší rendity z investičních programů týkajících se IT a služeb IT.
Vypracování rozpočtu IT – rozpočet musí být vypracován na základě priorit, které
jsou určeny portfoliem investičních programů týkajících se IT. Proces vypracování
rozpočtu by měl zahrnovat náklady na provoz a údržbu aktuální infrastruktury.
Procesy sestavování rozpočtu by měly firmě umožnit vytvoření celkového rozpočtu
pro IT a rozpočtů určených pro jednotlivé programy. Přitom musí existovat
možnost průběžné kontroly, snížení a schválení všech druhů rozpočtů.
Řízení nákladů – každá firma by měla implementovat jeden proces pro řízení
nákladů, v němž se porovnávají skutečné náklady s přidělenými rozpočty. Měla by
existovat možnost náklady sledovat a vypracovávat příslušné zprávy. Jakékoli
odchylky by měly být identifikovány včas, přičemž by měl být přezkoumán i jejich
vliv na určité programy. Toto by podniku umožnilo přijmout vhodná protiopatření a
v případě potřeby aktualizovat obchodní scénář programu.
7
Řízení poskytování benefitů – měl by být implementován proces sledování výhod
prostřednictvím poskytnutí IT a udržování schopností IT. Podnik by měl zjistit a
dokumentovat přínos IT pro obchodní činnost. Toto se může vztahovat na přímý
vliv investičních programů na bázi IT nebo na nepřímý přínos jako součást
podpory běžných provozních procesů. Zprávy by měly být monitorovány a
kontrolovány, aby firma mohla zlepšit přínos IT vhodnými změnami buď
investicemi do IT nebo do souvisejících programů.
1.1.2 Strategie IT
Strategie IT je, jak již bylo popsáno výše, ve vzájemném vztahu se strategií podniku a strukturou IT
služeb. Následující kapitola podrobněji popisuje několik nejdůležitějších aspektů vývoje strategie IT
a s nimi související konstrukce IT. Jedná se o:
1. řízení portfolia IT,
2. řízení požadavků,
3. definici struktury informací,
4. stanovení orientace technologie a
5. kontrolu a hodnocení rizik IT.
1. Řízení portfolia IT (portfolio investic)
Řízení portfolia ve smyslu strategie IT popisuje krok mezi obchodní strategií a její technologickou
realizací. Jak bylo popsáno v předcházející kapitole, měly by být pro účely podpory obchodní
činnosti prostřednictvím IT (IT-Business-Alignment) investice IT hodnoceny podle finančních kritérií
a kritérií tvorby přidané hodnoty. Protože však v podniku jsou zpravidla k dispozici finanční a
personální zdroje pouze v omezené míře, tyto investice do IT si vzájemně konkurují. V důsledku
toho se nabízí otázka, která z investic IT má být s dostupnými prostředky realizována. Řízení
portfolia pomáhá podniku určit těmto investicím IT určité pořadí. Přitom je potřeba se pokusit
porovnat šance, rizika, dobu realizace a náklady plánovaných investic do IT. Následující graf
popisuje proces řízení portfolia investic a jeho rozhraní ke strategii IT.
8
Požadavky na IT projekty
Řízení IT portfolia
IT-Portfolio-Management
Životní cyklus
ŘízeníLife-Cycle
IT portfolia
Vývoj IT strategie
Analýza IT portfolia
Komunikace IT portfolia
Úprava IT portfolia
Obrázek 3 - Životní cyklus řízení portfolia IT
Druhý graf je příkladem dvourozměrné analýzy portfolia, která se vztahuje k návratnosti investice
(Return of Investment - ROI) a podpoře strategie podniku. Je však nutné si všimnout, že by pro
hlubokou analýzu portfolia projektů a s tím spojené stanovení priorit jednotlivých investic do IT
měly být zohledněna ještě další hlediska (např. riziko realizace, období realizace atd.).
9
vysoká
nízká
Návratnost investice
Úsporné IT projekty s
malým dopadem na
firemní strategii
Úsporné a všemi
směry přínosné
IT projekty
projekt 2
projekt 1
IT projekty s nízkou
úsporností a malým
dopadem na firemní
strategii
Přínosné, ale
nákladné IT projekty
projekt 4
projekt 3
nízká
vysoká
Schopnost přispět k podpoře firemní strategie
Obrázek 4 – Stanovení priorit jednotlivých projektů
2. Řízení požadavků
Řízení požadavků (také zvané Demand Management) je rozhodujícím procesem během fáze
životního cyklu strategie služeb IT. Řízení požadavků popisuje požadavky na obchod (Business
Requirements), které vyplynou z obchodní strategie a ze stávajících obchodních procesů a tím
definuje potřebnou kapacitu a flexibilitu struktury IT. Abychom zůstali u příkladu Karlovy dílny:
Karlovou obchodní strategií je dostat se k většímu počtu zákazníků, proto rozvíjí svou prezentaci
na internetu (tento cíl odpovídá definici strategie IT). Jedním z obchodních požadavků (Business
Requirement) úspěšného rozvoje přítomnosti na internetu je nepřetržitý provoz, a sice 24 hodin
denně po všech 365 dnů obchodního roku. Tento požadavek proto musí být podporován konstrukcí
IT. Server a software musí být dimenzovány na nepřetržitý provoz. Řízení požadavků je centrální
aktivitou v rámci řízení služeb, který musí usilovat o stálou rovnováhu mezi čerpáním a
poskytováním služeb.
Řízení požadavků je spojeno s různými procesy a aktivitami plánování strategie. Vztahuje se
zejména na strategický plán pro IT, řízení portfolia IT, zaměření na zákazníka a definici služby.
10
3. Konstrukce informací
Definice konstrukce informací je důležitým úkolem při vytváření strategie IT určitého podniku.Tento
proces se vztahuje na vytvoření a udržování obchodního informačního modelu a definici vhodných
systémů, aby se optimalizovalo využití informací. Tím jsou aplikace plynule začleněny do
obchodního procesu.
Definování konstrukce informací zvyšuje kvalitu rozhodování na úrovni managementu, protože je
zajištěna existence konsistentních a bezpečných informací. Kromě toho umožní tento proces
spravování zdrojů informačních systémů, aby odpovídaly obchodním strategiím. Kromě toho
přispívá definice konstrukce informací k tomu, že se posiluje odpovědnost za integritu a
bezpečnost údajů uvnitř firmy a zlepšuje se efektivita výměny dat překračující rámec jednotlivých
aplikací.
Správná definice konstrukce informací přispívá k tomu, aby se dosáhlo řady cílů ve spojení se
strategií IT a strategií podniku dané firmy. Pomáhá především při optimalizaci využití informací a
vyšší flexibilitě IT. Zajišťuje integraci aplikací do obchodních procesů.
Pokud by Karel například v budoucnu chtěl prostřednictvím internetu prodávat náhradní díly, musí
být jeho konstrukce informací tak flexibilní, aby údaje internetového obchodu mohly být integrovány
do jeho aplikačního softwaru.
4. Stanovení orientace technologie
Strategie IT podniku určuje technologický směr na podporu obchodní činnosti. Technologický směr
by se měl orientovat na obchodní požadavky podniku. Ten potřebuje stabilní, nenákladné,
integrované a standardizované aplikační systémy, zdroje a schopnosti, aby splnil aktuální i budoucí
obchodní požadavky. Pro tento proces je potřebná definice a implementace plánu infrastruktury
technologie, jakož i konstrukce a norem, pomocí kterých budou identifikovány a optimálně využity
technologické možnosti.
Účel plánu infrastruktury technologie je stanovit v tomto směru jasná a realistická očekávání a
uvést, co technologie může dokázat u produktů, služeb a zajišťovacích mechanismů. Plán by měl
být pravidelně aktualizován a měl by se vztahovat na témata, která jsou spojena se strukturou
systému, orientací technologie, plánem nákupu, normami, strategiemi migrace a případnými
mimořádnými situacemi. Tím je firma schopna včas reagovat na změny v konkurenční situaci a
zlepšovat spolupráci platforem a aplikací.
Správné stanovení orientace technologie by mělo podporovat firmu v tom, aby získala a udržovala
integrované a standardizované aplikační systémy. Měla by podporovat optimalizaci infrastruktury
IT, zdrojů IT a schopností IT. Pokud by například v Karlově podniku systém ERP vycházel
z technologie Java, má smysl vytvořit další aplikace, které rovněž vycházejí z této technologie. Tak
11
může být údržba provedena stejným tvůrcem. Kromě toho jsou již na trhu k dispozici široké znalosti
technologie java, a proto je možné rychle zaměstnat další pracovníky.
Další informace týkající se návrhu, plánování, implementace a údržby struktur IT a podniku, lze
najít v rámcovém díle TOGAF.
5. Kontrola a hodnocení rizik
Aby bylo možné realizovat dobrou strategii IT, musí firma kontrolovat a spravovat rizika IT. Účel
tohoto procesu spočívá v tom, aby se analyzovala rizika IT a jejich potenciální vlivy na obchodní
proces a cíle a aby se podávaly informace o příslušných výsledcích.
Kontrola rizik by měla být vyjádřena ve vztahu k nákladům, které jsou s nimi spojeny, aby byli aktéři
schopni najít akceptovatelnou úroveň tolerovaných rizik (viz analýza portfolia). To se prokazuje
také jako užitečné pro doporučení a komunikaci plánů opatření, kterými se na rizika reaguje. Tak
by nemělo pro Karlův podnik jistě žádný velký význam provozovat výpočetní středisko odolávající
zemětřesení. Ale je přiměřené pravidelně údaje ukládat a archivovat a vyhotovit plán jejich
rekonstrukce pro případ přírodní katastrofy.
Přiměřená kontrola rizik IT a jejich řízení podporuje firmu v tom, aby brala zřetel na všechna
zařízení IT a aby je chránila. To může přispět k tomu, aby bylo dosaženo zadání IT a aby se
vytvořila jistota ohledně obchodních vlivů rizik na zadání a zdroje IT.
1.1.3 Definice IT služeb
Následující oddíl bude pojednávat o bodech důležitých pro definici služeb IT a jejich řízení v rámci
podniku. Ty zahrnuje řízení katalogu služeb, jakož i definici a řízení úrovně služeb (Service Level).
Zásadní význam pro podnik má efektivní komunikace týkající
se potřebných či požadovaných služeb mezi vedením IT a
uživateli
těchto
objednavatele
požadavek,
služeb,
nebo
musí
často
zákazníky.
podnik
označovanými
Aby
byl
definovat,
splněn
jako
tento
dohodnout
a
dokumentovat služby IT a úrovně služeb (Service Levels).
V rámci řízení IT služeb je za spravování služeb v rámci
portfolia služeb a katalogu služeb odpovědný management
řízení katalogu služeb. Při vytvoření služby závisí portfolio
služeb na portfoliu investic (viz také kapitola 1.1.2), protože
investice definuje a stanoví jejich priority.
Obrázek 5 – Struktura portfolia služeb
12
V takovém portfoliu služeb by měly být centrálně organizovány a uloženy základní definice služeb
IT, což zahrnuje také charakter služeb a obchodní požadavky. Proces řízení katalogu služeb
odpovídá za vytvoření a vedení katalogu služeb. Tento proces by měl zajistit, aby portfolio služeb
obsahovalo přesné informace ohledně všech služeb, které se vztahují k obchodním procesům
nebo s ním úzce souvisejí.
Vhodná definice a správa služeb by měla firmu podporovat při tom, aby mohla lépe reagovat na
obchodní požadavky v souladu s obchodní strategií. Tím by mělo být také zajištěno, aby byli
koneční uživatelé s nabídkou a úrovní služeb spokojeni. Kromě toho to může vést k větší
transparentnosti z důvodu lepšího chápání nákladů IT, výhod IT a strategie IT.
V rámci řízení úrovně služeb (Service Level Management - SLM) se s obchodními odděleními
projednají, dohodnou a dokumentují vhodné cíle služeb IT. Pak se provádí monitoring
poskytnutých služeb a vyhotovení příslušných zpráv. SLM by měl zajistit stálou orientaci na
obchodní požadavky a priority. Prostřednictvím SLM by měla být zjednodušena dohoda mezi
zákazníkem a poskytovatelem služeb.
Řízení úrovně služeb (SLM) je neoddělitelně spojeno s koncepcí Service Level Agreements (SLA),
Operating Level Agreements (OLA) a s Underpinning Contracts (UC). Přitom se nesjednávají
pouze dohody o úrovni služeb (SLA), je zajištěno i jejich dodržování. Obecně je SLM odpovědné
za to, že budou mít všechny procesy řízení IT služeb a smlouvy, které jsou jejich základem (SLA,
OLA, UC), rozsah odpovídající stanoveným cílům.
SLA by měly být definovány a sjednány pro všechny kritické služby IT na základě požadavků
zákazníků a schopností IT. Existuje mnoho oblastí k dohodě, které by měly být zastřešeny
prostřednictvím SLA. Nejdůležitější body se vztahují na závazky vůči zákazníkům, požadavky na
podporu služeb (Service-Support), financování a obchodní dohody, jakož i role a kompetence
včetně monitoringu SLA.
1.1.4 Řízení inovace na bázi IT
Strukturovaný způsob práce, který vychází z Best Practices, je nejen účelný, ale také fakticky
usnadňuje pracovní život. Z výzkumů v rámci projektu INNOTRAIN IT v 6 zemích vyplynulo, že v
podnicích, které používají ITSM, může jeden pracovník IT spravovat mnohem více pracovních
míst. Vyjádřeno jinými slovy, zde se skrývá možné ulehčení ve dvojciferné procentní oblasti.
„Maximalizátor zisku“ může samozřejmě na tomto místě uspořit náklady a dále rozvíjet svůj zisk.
Výhledově by však bylo účelnější optimalizovat zisk dlouhodobě tím, že se budou uvolněné zdroje
investovat do inovací v rámci podniku.
Projekt INNOTRAIN se zaměřuje právě na tuto otázku: Jak mohou být – vycházeje z ITSM – volné
zdroje využity v organizaci pro inovace? Jistě nelze takový vývoj uskutečnit ze dne na den. Jako
13
první krok je nutná určitá motivace a také nějaká snaha. Jestliže se však člověk pro to rozhodne,
mohl by vývoj vypadat takto:
INOVACE
VÝROBKŮ a SLUŽEB
PROCES
INOVACE
DOSTUPNÉ ZDROJE
INOVACE
INOVACE
ŘÍZENÍ ZMĚN
INFRASTRUKTURY
V ORGANIZACI
PRO UVOLNĚNÍ
POTŘEBNÝCH ZDROJŮ
PRO
INOVACE
NA ÚROVNI
INFRASTRUKTURY
PROCESŮ,
VÝROBKŮ A SLUŽEB
ČINNOSTI IT
ČINNOSTI IT
ČINNOSTI IT
ROUSTOUCÍ EFEKTIVITA S POUŽITÍM METODY ŘÍZENÍ IT SLUŽEB
2
1
3
4
Obrázek 6 – Vývoj inovačních potenciálů na bázi ITSM
1. Fáze 1 představuje situaci před zavedením ITSM. V poměru se 100 % času používá na
přípravné činnosti.
2. Použitím osvědčených postupů roste efektivita IT. Vytížení přípravnými činnostmi IT se ve
střednědobém horizontu snižuje. Nepřetržitou optimalizací a rozšiřováním použití ITSM je
možné dosáhnout dalšího snížení zatížení a odkrýt na základě toho potenciál pro inovace.
Základní poznatky a postup k této otázce najdete v kapitolách 3 a 4.
3. V třetím kroku se uvolní potenciál pro inovace. Musí dojít k dalším změnám ve způsobu
myšlení a práce. Použití určitých technik stabilizuje využití potenciálů pro inovace. Více
k tomuto čtěte v kapitolách 5 a 6.
4. V prozatím konečném stavu se zatížení sníží a uvolněné zdroje se využijí pro vytvoření
inovací.
Ale co jsou to vlastně inovace? Inovace je možné definovat takto: vynálezy nebo změny, které
vedou k novým metodám reorganizace výrobního systému. Tak se u některé inovace může jednat
o nápady, produkty, postupy nebo služby, které podnik nebo obchodní oblast považuje za nové a
14
které se uplatňují v každodenním životě („interní zavedení na trh“). Bleší trh, na kterém může
každý nakupovat a prodávat, aniž by musel vyjít z domu? Bleší trh, kde můžete „šmejdit“ online –
před 15 lety zněl tento nápad Pierra Omidyara ještě velmi utopicky. Přesto realizoval svůj nápad
jako internetovou aukční síň a založil eBay.
Na základě následující inovační spirály je možné definovat tři úrovně inovací, které vycházejí ze
zásad řízení IT služeb.
Úroveň 3
Inovace výrobků a
poskytovaných služeb
Úroveň 2
Inovace podnikových
procesů
Úroveň 1
Řízení IT služeb a správa
IT infrastruktury
Počateční stav
Zavedení základních
principů řízení IT služeb
Obrázek 7 – Inovační spirála INNOTRAIN IT
Úroveň 1 – Řízení služeb infrastruktury IT: Inovace na této úrovni se týkají infrastruktury IT
podniku. Tak by na příkladu Karlovy dílny další růst podniku a konečně změna řízení tiskáren vedly
k tomu, že se musí údržba tiskárny nekonfliktně předat na výrobce nebo poskytovatele služby a
musí se platit pouze skutečné náklady na tisk („Pay per Click“) a že se riziko (porucha tiskárny atd.)
přesune.
Úroveň 2 – Inovace obchodních procesů: IT se dnes často považuje za průkopníka („Enabler“)
obchodních procesů. Proto poskytuje tato úroveň velký potenciál pro zlepšení. Karel může
například dalším použitím místa na trhu náhradních dílů etablovat další odbytový kanál a tím
zásadně změnit obchodní proces.
15
Úroveň 3 – Inovace produktů a služeb: Jistě nejnáročnější úroveň sleduje inovace na úrovni
produktů a služeb. Prominentním příkladem jsou dnes nespočetné Smartphone Apps, které se
poskytují jako doplnění produktů. Výrobci automobilů tyto spojí se svými vozidly, a tak produkt
změní.
Do oblasti úkolů modulu řízení inovací na bázi IT patří identifikovat potenciály, vést dialog
s obchodem, iniciovat a podporovat inovace. Protože inovační proces probíhá ve více krocích,
zvyšuje se komplexnost problematiky, která je s tím spojena. Proto je zavedení inovací na bázi IT
komplexním procesem, který může procesy podniku radikálně změnit. Na základě toho se
kapitola 6 exkluzivně zabývá tématem řízení inovací a na tomto místě se na to připravuje. Jako
doplněk popisuje kapitola 5 zacházení se změnami a podporuje proces změn v organizaci.
1.2 Provoz IT služeb
Vertikální úroveň
Úroveň I
Strategické
plánování
Dohled, Rozvoj a řízení změn
Zaměření IT
na strategii
podniku
IT strategie
Definice IT
služeb
Řízení inovace
na bázi IT
Kontrola
a Audit
Trvalý rozvoj
IT služeb
Úroveň II
Provoz IT
služeb
Řízení IT
projektů
Údržba a
podpora
Informační
systémy a
externí služby
Sladění
procesů
Řízení změn
Zajištění
IT služeb
Bezpečnost
a prostředí
Dohled
a Vyhodnocení
Řízení změn
a Rozvoj
IT Projekty
1.2.1 Údržba infrastruktury a podpora uživatelů
“Pomoc, moje obrazovka je černá!“ Tento výkřik uživatele zná každý. Denně dochází k velkému
počtu takzvaných poruch v provozu systému, tedy k odchylkám od plánů. Tato kapitola vysvětluje
strukturované zacházení s těmito poruchami.
16
Nyní nejprve malé zařazení relevantních termínů: uživatelská podpora (Service Desk) je
centrálním kontaktním partnerem pro všechny dotazy uživatelů podle principu „jeden ´kontakt pro
zákazníka“ („one face to the customer“ú. Na základě toho má zákazník pouze jeden kontaktní bod
pro všechny dotazy, které se týkají IT (např. hotline, systém prodeje lístků). Zřídka rozšiřují podniky
i svou uživatelskou podporu a zpracovávají jejím prostřednictvím jiné dotazy (např. u budovy řízení
nebo řízení mimořádných událostí). Na programu zde může být požadavek poskytnutí služby
(Service Request), hlášení poruchy (Incident) nebo také požadavek provedení změny (Request for
Change). Uživatelskou podporu lze považovat za sběrné místo, které eviduje všechna hlášení a
pak je nasměruje do správných procesů pro jejich zpracování. Nejprve se budeme tedy zabývat
požadavky různého druhu označované jako incident.
Uživatelská podpora
Uživatelská podpora je centrální funkcí ITSM. Tvoří spojovací článek mezi službami IT a
operativním obchodem. Všechny požadavky zaměstnanců o pomoc se provádějí přes tuto funkci.
Incident je neplánované přerušení (např. výpadek počítače na pracovním místě) nebo snížení
kvality některé služby (např. pomalé internetové spojení). Také výpadky konfiguračních prvků
(Configuration Items) mohou být bez přímého vlivu na službu zpracovány jako incident. Příkladem
by byl v tomto případě výpadek pevného disku, přičemž server může být dále v provozu. Na rozdíl
od toho neovlivňují požadavky na poskytnutí podpory (Service Requests) od uživatelů (týkající
se informací, poradenství, standardních změn, přístupu) služby IT. Představují cestu, jak uspokojit
potřeby zákazníků. Příkladem je požadavek na toner do tiskárny, protože tiskárna hlásí, že bude
brzy potřeba.
Porucha nebo incident?
Incident je definován jako porucha IT nebo jako žádost o s poskytnutí služby IT. Incidentem by
mohlo být např. „můj excel padá“ nebo také „Musím z excelu vytvořit PDF, jak to mohu udělat?“.
Všechny incidenty by měla zpracovat uživatelská podpora a evidovat jejich stav, aby bylo možné
později provést jejich vyhodnocení.
Proces správy a zpracováni incidentů se zpravidla označuje jako řízení incidentů (Incident
Management). Probíhá v různých fázích:
1. evidence a klasifikace incidentu
2. diagnóza incidentu
3. postoupení incidentu a
4. ukončení incidentu.
17
Infrastructure Library IT (ITIL) poskytuje v aktuální verzi 3 vzorový proces jako Best Practice. Ten
může sloužit jako základ pro vývoj vlastního procesu, neboť požadavky se podle jednotlivých
podniků masivně liší. U menších podniků stačí jistě pragmatický telefonát, aniž by byl potřebný
velký plán postupu zvládnutí incidentu, u středních a velkých podniků však tento incident vede
opakovaně k přerušení vlastních činností. Zde se vyplatí formálnější cesta.
V obou případech je však účelné incidenty dokumentovat a analyzovat je v rámci procesu
zkvalitnění provozu IT. V ideálním případě se incidenty evidují v lístkovém systému, pro začátek
však snad postačí i jednoduchý seznam.
ITIL navrhuje následující postup:
+
Lístkový systé m
Fáze I
Záznamenání
poruchy
Správa událostí
Identifikace a
záznam poruchy
Prímý kontakt E Mailem nebo
telefonem
Ostatní vstupy
Kategorizace
poruchy
Ano
Požadavek
provedení služby
Plnění požadavku
Ne
Stanovení priority
Fáze 2
Stanovení
priorit
Ano
Závažná porucha?
Proces rešní
Závažné poruchy
Ne
Úvodní
diagnostika
Fáze III
Diagnóza a
prípadné
predání
Ano
Nutne
hierarchické
predání?
Ye s
Rízení predání
Ano
Nutné funkcní
predání?
Funkcní eskalace
(2nd Level / 3rd
Level)
No
Zkoumání a
diagnóza poruchy
Vyrešní poruchy
Fáze IV
Odstranení
poruchy
Uzavrení poruchy
Konec
Obrázek 8 – Proces zpracování incidentu v návaznosti na ITIL V3
18
Fáze I – Identifikovat, evidovat a kategorizovat poruchy
Identifikace poruch je rozdělena na mnoho ramen uživatelů. Většinu odchylek je možné snadno
identifikovat a podle relevance pro uživatele se tito rádi smíří s náklady na jejich hlášení.
V mnoha případech je však za identifikaci poruchy nebo budoucí poruchy odpovědná proaktivní
konfigurace. Tak mohou být například identifikovány a hlášeny odchylky na úrovni hardwaru
(například výpadek pevného disku při útoku). Na systémové úrovni se prosadilo použití
monitorovacích řešení. Tak může být například funkce e-mailového serveru zkontrolována
odesláním e-mailové zprávy monitorovací aplikací a doba doručení oznámení o jejím doručení.
Jestliže je při tom překročena prahová hodnota, označí se to jako událost a vyvolá se alarm.
V závislosti na použitých systémech a používané kultuře provádí uživatel vlastní evidenci poruchy
(např. lístkový systém) nebo ji provádí pracovník uživatelské podpory (např. při telefonátech nebo
e-mailech). Ve velkých podnicích zajišťuje přesná kategorizace přesné postoupení lístku
odpovídajícímu specialistovi. Poskytuje však i v menších podnicích možnost – od kritického
množství poruch – identifikovat slabiny a optimalizační potenciály. Jestliže jsou například hlášeny
zvláště často problémy s nějakou kancelářskou aplikací, má za určitých okolností smysl uživatele
lépe proškolit nebo aplikaci vyměnit. I kategorizaci, jako evidenci poruchy, může provést uživatel
nebo pracovník IT. Na základě evidovaných údajů může být přijato rozhodnutí, zda se jedná o
poruchu nebo o požadavek provedení služby, při kterém se aktivuje zvláštní proces.
Fáze II – stanovení priorit
Stanovení priority incidentu pak udává, jak ho
zaměstnanci a nástroje uživatelské podpory
Nízký vliv
Priorita
3
Priorita
4
Priorita
5
zpracují. Stanovení priorit v sobě často skrývá
velký potenciál konfliktů mezi uživateli a
Střední vliv
Priorita
2
Priorita
3
Priorita
4
Priorita
1
Priorita
2
Priorita
3
Vysoká
naléhavost
Střední
naléhavost
Nízká
naléhavost
poskytovateli služeb, neboť z pohledu uživatele
má vlastní incident přirozeně vždy největší
prioritu.
Silný vliv
Zkušenosti
ukázaly,
že
v mnoha
případech, v nichž uživatel sám stanoví prioritu,
se priorita viditelně lišila od skutečnosti. Proto
je lepší nechat provést klasifikaci incidentu
pracovníkem
Obrázek 9 – Příklad stanovení priorit incidentů
1
uživatelské
podpory,
neboť
pouze on má potřebný přehled o aktuální situaci v podniku. Definice priority incidentu se měří podle
vlivu na podporované obchodní procesy a podle naléhavosti, kdy se tento vliv projeví. Vychází-li
se z pořadí incidentu, mohou být definovány reakční doby (doba, kdy se zahájí řešení problému) a
doby řešení (doba až do obnovení pravidelného provozu).
Fáze 3 – Diagnóza a případně předání
Při první diagnóze platí pravidlo shromáždit všechna relevantní fakta (data o prostředí, symptomy
atd.). Často se toto děje také přímou komunikací mezi zaměstnancem uživatelské podpory a
uživatelem. V případě jednoduchých nebo známých problémů se zaměstnanec pokusí najít přímé
řešení. Jestliže to není možné, protože není dostatek času nebo nemá potřebné podrobné
vědomosti, musí být incident předán k dalšímu zpracování. Zde se rozlišuje mezi dvěma způsoby:
Funkční předání je postoupení další instanci (osoba nebo tým) s většími zkušenostmi. Postoupení
může být jak interní (vlastním zaměstnancům IT), tak externí (např. na podporu dodavatele). Dnes
se zde často užívá termín „2nd Level Support“ (dvojúrovňová podpora).
Hierarchickým předáním se myslí informování a zapojení vyšších úrovní řízení, aby se podpořilo
předání. Nadřízený manager má v tomto procesu např. odstranit organizační překážky nebo
mobilizovat zdroje, aby se dosáhlo rychlého řešení problému.
Nyní musí být s příslušnými specialisty určena diagnóza nebo musí být incident předán dále, až
bude vytvořena konečná diagnóza. Uživatelská podpora je nezávisle na stupni předání za incident
odpovědná, koordinuje aktivity a pravidelně informuje uživatele o postupu řešení jeho incidentu.
Fáze 4 – Odstranění poruchy
Pokud je diagnóza uznána jako porucha, může být tato odstraněna a opět nastolen obvyklý stav.
V zásadě by měla být řešení také odpovídajícím způsobem otestována. Tak může například tisk
testovací stránky po odstranění vzpříčeného papíru poskytnout informaci o tom, zda existují další
problémy. U úprav na aplikace – takzvaná horká řešení (Hotfixes) nebo dočasná řešení problému
(Patches) – by se měly testovat i možné vzájemné účinky, dříve než se celoplošně zpřístupní.
Poté, co bylo řešení a obnovení úspěšné, může být incident ukončen. Přitom by měla uživatelská
podpora zajistit, aby byl uživatel s řešením spokojen. Často se toto děje systematicky, kdy
uživatelská podpora změní stav incidentu na vyřešeno, ale uživatel může incident ukončit.
1
V mnoha případech se následně nastartuje krátký dotaz, který v několika otázkách (3-5) hodnotí
kvalitu uživatelské podpory.
Řízení problémů
Odstranit poruchu – bylo to ono? Samozřejmě ne. V mnoha případech se sice podaří poruchy
prostřednictvím přednastaveného procesu rychle vyřešit, ale příčina není eliminována a je možné,
že dojde ke vzniku další poruchy. Jestliže se na jednom typu tiskárny dochází častěji ke vzpříčení
papíru, mohl by mít tento typ tiskárny výrobní vadu nebo by mohl být nekompatibilní s použitým
papírem. Těmito příčinami poruch se zabývá řízení problémů.
Problém
Problém existuje tehdy, jestliže je možné u většího počtu incidentů usuzovat na stejný vzor.
Prostřednictvím centrální správy incidentů může uživatelská podpora identifikovat opakující se
problémy (např. program excel u uživatele XY vždy spadne, pokud je současně otevřen program
word) a najít dlouhodobá řešení.
Problém, tedy příčina jednoho nebo většího počtu incidentů, se zpracovává procesem řízení
problémů ve více krocích. ITIL zde poskytuje také jeden adekvátní referenční proces:
1. Identifikace problému zaměstnancem uživatelské podpory, týmu technické podpory nebo
managementu mimořádných událostí.
2. Evidence problému s odkazy na odpovídající poruchy včetně kategorizace pro účely
pozdějšího reportingu a stanovení priorit problému, které je podobné s řízením incidentů.
3. Diagnóza problému s cílem identifikovat jeho příčinu. Je-li příčina identifikována, ale není
dosud k dispozici žádné řešení, měl by být definován osvědčený způsob (Workaround)
(např. nový start tiskárny). Ten se eviduje jako známá chyba („Known-Error“) a je
k dispozici oddělení uživatelské podpory, aby mohla rychleji příslušné poruchy odstranit.
4. Nalezení řešení s cílem co možná nejrychleji řešení realizovat. Jestliže je však pro
konečné řešení potřebná změna („Change“), měla by se provést prostřednictvím
definovaného postupu v řízení změn. Tímto strukturovaným postupem se zredukují a
kontrolují možné účinky (k tomu více v kapitole X).
1
Jak řízení incidentů, tak řízení problémů sázejí na identické koncepce týkající se personálu a
nástrojů. Ve větších organizacích se doporučuje etablovat vlastní tým, který bude mít funkci
uživatelské podpory. Zde lze také uvažovat o koncepcích jako je centrální nebo decentralizovaná
uživatelská podpora, virtuální uživatelská podpora (např. ve spolupráci s dodavatelem) nebo
dokonce o příslušných koncepcích časových zón u mezinárodních podniků (zásada Follow-theSun). V malých organizacích IT může být funkce svěřena i některému zaměstnanci, který je
odpovědný za uživatelskou podporu a kterého podporují jeho kolegové. V ideálním případě by
měla být realizována koncepce „One-Face-to-the-Customer“ nebo jinými slovy jedna kontaktní
osoba pro uživatele pro všechny záležitosti. Usnadňuje to komunikaci uživatele s oddělením IT,
zarazí to triviální dotazy a umožňuje ostatním zaměstnancům (např. vývojovým pracovníkům nebo
administrátorům) koncentraci na klíčová témata.
Co se týká nástrojů, jsou dnes k dispozici četná komerční řešení a řešení Open-Source. V ideálním
případě disponuje uživatelská podpora následujícími aplikacemi, které jsou integrovány do určitých
řešení nebo jsou spolu propojena přes smysluplná rozhraní:
1. Lístkový systém, který spravuje a dokumentuje poruchu nebo problém po celou dobu jeho
trvání. Jeho prostřednictvím by měla být možná i komunikace s uživatelem (např. přes
webové rozhraní nebo prostřednictvím e-mailu).
2. Databanka pro evidenci známých chyb a jejich řešení. Zde se nemusí jednat vždy o
nabubřelé řešení. Pro menší organizace stačí většinou také pouze jednoduchý seznam.
3. Databanka řízení konfigurace (CMDB) je pomůcka, která podporuje mnoho oblastí.
Databanka poskytuje údaje a informace z celého prostředí IT, a tak pomáhá pochopit
souvislosti a snadněji identifikovat problémy. Tak je možné si například přečíst, jaký
zaměstnanec používá který typ tiskárny na svém pracovišti. Více k tomuto tématu v
kapitole 4.
1.2.1 Informační systémy a externě poskytované služby
Ruku na kostru počítače: tluče srdce vaší IT ještě? Okolo srdce informační technologie – aplikací,
systémů, sítí a hardwaru – se točí všechno v této kapitole. Mnoho činností je potřebných, aby se
realizovala, udržovala a provozovala tato komplexní konstelace. Už jste všechno předali jinam?
Také v tomto případě poskytuje tato kapitola cenné informace.
Dříve než se dostaneme k řemeslu, zůstaňme nejdříve krátce u managementu. Mnoho „ajťáků“
považuje řízení dostupnosti a kapacity za strategický nebo taktický úkol. V menších organizacích
1
IT je to však ve většině případů tak, že specialista své systémy podrobně zná, o tyto se také
koncepčně stará a obě témata jsou přesunuta na operativní úroveň jednání.
Správa dostupnosti (Availability Management) je odpovědné za veškeré aspekty, které se týkají
dostupnosti služeb IT. Obecně řečeno: oddělení služeb IT poskytne v případě potřeby zákazníka
potřebnou a plánovanou funkci v rámci SLA [Service Level Agreement, německý termín Dohoda o
kvalitní službě (DGV)]. Konkrétně formulováno: pokud chce uživatel vyvolat své e-maily, musí
příslušný e-mailový sever fungovat. Tak řízení dostupnosti sleduje dodržování cílů definovaných
v SLA a stará se o potřebná a možná zlepšení, která se týkají dostupnosti. Řízení dostupnosti má
při tom k dispozici reaktivní a proaktivní prostředky:
Reaktivní
Proaktivní
Sledování, měření, analyzování,
předkládání zpráv a kontroly
dostupnosti
Přezkoumání nedostupnosti
Hodnocení a řízení rizika
Implementace přiměřeně nákladných
protiopatření
Plánování, design a test nových nebo
změněných služeb IT
Test mechanismů dostupnosti a
výpadku
Poskytovatelé služeb často lákají slibem “99% dostupnosti služeb IT”. Tato procentní dostupnost
se vypočte tak, že se skutečná dostupnost služeb vydělí sjednanou dobou poskytnutí služby:
(sjednaná doba služby – doba výpadku)
Dostupnosti (v %)
=
sjednaná doba služby
x 100
Na první pohled se jeví hodnota 99-procentní dostupnosti jako velmi vysoká. Chtějme ji však přece
jen přepočíst na minuty a dny a uvidíme, jaký výsledek nás čeká. Vztaženo na den odpovídá 99procentní dostupnost ani ne 15 minutám výpadku. Počítáno na rok, kumulují se všechny
čtvrthodiny na více než 3,5 dne. Na tomto základě je možné rozhodnout, zda rámec s 99 procenty
byl zvolen účelně a realisticky. Zpětně se vyplatí zkontrolovat, zda byl slib také dodržen.
Dalším rozhodujícím orientačním bodem je dostupnost služeb IT (bez ohledu na to, zda interních
nebo externích) od poskytnutí až do konzumace (end-to-end). Jestliže se například poskytnutí
obchodní aplikace měří na bázi provozní doby serveru (Server Uptime), mohou vždy ještě jiné
1
okolnosti (např. výpadek sítě) mezi serverem a uživatelem vést k výpadku, který zůstane
nezohledněn. Podle toho by se měření mělo uskutečnit co nejdříve u příjemce, aby se podařilo
zachytit všechny možnosti.
Jestliže přes všechna preventivní opatření dojde k výpadku, jsou v rámci řízení dostupnosti
relevantní tři měrné veličiny:
reakční doba – čas od hlášení poruchy až do začátku odstraňování poruchy a
doba obnovy – čas od hlášení poruchy až do obnovení služby.
Pokud se řízení služeb předá externě, mělo by se při výběru poskytovatele služeb IT dbát
především na dobu obnovy. jinak může nastat následující případ: Poskytovatel služby IT reaguje
po hlášení defektu hardwaru již po několika minutách a zařídí objednání náhradního dílu. Jestliže
však není náhradní díl k dispozici a až do jeho dodávky uplyne jeden týden, může být služba opět
nabídnuta teprve po několika dnech.
Dalším tématem řízení je správa kapacity (Capacity Management), která dnes existuje a bude
v budoucnu existovat. Manager kapacity funguje jako „věštec“ podniku IT. Nedívá se však do
skleněné koule, ale analyzuje aktuální potřebu, sleduje vývoj podniku a na základě strategie
podniku odvozuje budoucí potřebu služeb IT a infrastruktury, které do nich patří. Musí zajistit, aby
byla kdykoli k dispozici potřebná kapacita v plánované kvalitě.
Správa kapacity se skládá ze tří tématických oblastí:
Správa obchodní kapacity (Business Capacity) zahrnuje všechny aktivity, které
se zaměřují na to, aby identifikovaly budoucí obchodní požadavky a aby je
zohlednily v plánu kapacit.
U správy kapacity služeb IT (Service Capacity) se hovoří o aktivitách, které
poskytují poznatky o kapacitách služeb IT potřebných v budoucnu.
správa kapacit jednotlivých kopmponent (Component Capacity) obsahuje
všechny aktivity, které sledují kapacitu, performanci a vytížení jednotlivých
konfiguračních prvků (např. PC, tiskárna, telefon, server).
Zjednodušeně lze říci, že se sledují budoucí požadavky obchodu na služby IT a služeb IT na zdroje
a že musí být zohledněny v plánování kapacit. Na základě tohoto plánování lze jednat tak, aby i
v budoucnu byly dosaženy stanovené cíle SLA. Tak může být například dokumentován přírůstek
1
potřebné paměti, odvozena prognóza a včas přikoupena další paměť. Tím se zajistí, aby mohly být
zachovány přiměřeně nákladné kapacity IT.
Až do tohoto okamžiku jsme se věnovali pouze řízení IT a službám IT. Nesmíme však zapomenout
na specialisty, kteří aplikace a systémy instalují a provádějí jejich údržbu. Podle velikosti podniku
se tento technický provoz dělí na různé týmy s různými kompetencemi. Běžné je přitom rozlišování
oblastí úkolů systémy a aplikace.
Oddělení péče o systémy, administrátoři podniku, se starají o všechna témata blízká hardwaru.
V prostředí ITSM se tento úkol často nazývá řízení operativního IT a obsahuje řízení fyzické
infrastruktury IT (typickými příklady jsou výpočetní střediska nebo počítačové místnosti). Nejvyšším
cílem je zajištění, resp. optimalizace aktuálního, stabilního stavu infrastruktury.
K úkolům řízení operačního IT patří například:
správa systému a provedení provozních aktivit a mimořádných událostí
řízení konzol a serverů (Job Scheduling)
zálohování (Backup) a obnovení (Restore)
řízení tisku
měření výkonnosti a optimalizace
údržbové činnosti a
řízení vybavení IT (klimatizace, dodávka elektřiny atd.).
Správa aplikací (Application Management) je naproti tomu odpovědná za design, vývoj, testy a
inovace obchodních aplikací. Oblasti úkolů mohou mít od podniku k podniku mnoho variant.
Jestliže se rozvoj software zadá interně, zvětší se spektrum úkolů oddělení správy aplikací. Jinou
možností je externí zadání vývoje aplikací. Samozřejmě existují mezi těmito dvěma řešeními četné
mezistupně (např. standardní software s vlastními úpravami). Úkoly oddělení řízení aplikací se
definují takto:
péče o aplikace podniku
částečně design, vývoj, test a inovace aplikacípodpora operačního řízení IT služeb a
školení zaměstnanců.
1.2.2 Zajištění IT
Razantní rozvoj informačních technologií staví oddělení IT malých a středních podniků
permanentně před výzvy: existují technologie nového druhu, změněné služby a inovační produkty.
1
Mohly by být přínosem k efektivnějšímu plnění úkolů nebo jsou pouze samoúčelné? Pro
zodpovězení této otázky je mnoho možností výpočtu:
Celkové náklady vlastnictví (Total cost of ownership - TCO),
nebo
Celkové výnosy z vlastnictví (Total benefits of ownership - TBO)
Celková hodnota vlastnictví (Total value of ownership – TVO)
statický nebo dynamický účet investic
návratnost investic - Return on Invest (ROI).
Ve skutečnosti je to tak, že tyto přinášejí podniku v dílčích oblastech konkrétními výsledky. Ve
většině případů však neposkytují, pokud to bereme odděleně, žádné ověřené výsledky. Tak se
neprovádí žádné konkrétní porovnání všech nákladů a zisků nebo se používají pouze čistě finanční
veličiny. V poslední řadě musí být objasněna otázka, zda očekávaný celkový zisk (TBO/TVO)
ospravedlňuje očekávané celkové náklady (TCO) po dobu trvání nebo dokonce vytvoří ziskovou
situaci. Jinými slovy: sledování návratnosti investic (Return on Investment), které však nezahrnuje
pouze investiční náklady a finanční užitek, nýbrž celkové náklady a zisk.
Bylo-li přijato rozhodnutí o investici, musí být už „jen“ zajištěny nové komponenty IT. Přesto se až
příliš často tento záměr ukazuje jako příliš komplexní.
Nikoli bez důvodu, neboť postupy zajištění IT se dotýkají většího počtu oblastí organizace – i mimo
oblast IT – a zahrnují služby externích poskytovatelů služeb, jakož i dodavatelů. Na základě toho
by měla probíhat úzká kooperace a měla by být vedena otevřená komunikace.
Řízení výběru dodavatelů v rámci organizace IT má následující cíle:
pravidelný monitoring prodejního trhu a sledování trendů a novinek,
výběr dodavatelů s přihlédnutím k jejich strategickému významu pro obchodní
procesy podniku,
vyjednávání smluv s dodavateli a fixace služeb,
zajištění a plynulé zvyšování kvality nakoupené služby,
udržování vztahů s dodavateli (Supplier-Relationship-Management) a
dokumentace všech dodavatelů, smluv a vztahů.
Často se úkoly také dělí mezi čistým oddělením nákupu a organizací IT. IT přitom koordinuje
všechny technické aspekty v cyklu, zatímco nákup řeší smluvní a cenové otázky.
2
základě dvou variant:
přínos pro celkovou hodnotu a význam
riziko a vliv.
Nízký
obchodní vztahy Význam může být přitom definován na
Operativní
dodavatel
Operativní
dodavatel
Standardní
dodavatel
Střední
dlouhodoběji by měly být formulovány
Přínos pro hodnotu a důležitost
podnik, tím
Taktický
dodavatel
Taktický
dodavatel
Operativní
dodavatel
Vysoký
Čím vyšší je strategický význam určitého dodavatele pro
Strategický
dodavatel
Taktický
dodavatel
Operativní
dodavatel
Vysoké
Střední
Nízké
Ve většině případů se vyplatí dlouhodobá a těsná
spolupráce. Tak mohou být prostřednictvím rámcových
smluv při nákupu komponent (např. na očekávané
množství osobních počítačů v jednom roce) dosaženy
Riziko a vliv na obchodní procesy
Obrázek 10 – Klasifikace dodavatelů
jednak často výhodnější podmínky, ale zároveň také optimalizace a uvolnění v procesu nákupu. Ve
střednědobém horizontu je možné dosáhnout prostřednictvím důsledné standardizace dalších
stupňovitých efektů.
Není už pořízení IT žádným tématem pro podniky, které všechny služby zadaly externě? I
v případě kompletního externího provádění výkonů (Full-Outsourcing) je odpovědná kontaktní
osoba v podniku důležitá; i zde se musí udržovat vztah mezi zákazníkem a dodavatelem, sledovat
kvalita a pravidelně monitorovat trh.
1.2.3 Bezpečnost a prostředí
„Sony říká „Sorry“ – Výrobce playstation se omluvil za masivní krádeže údajů ve svých sítích a
slíbil zdarma hry jako narovnání, jakož i lepší bezpečnostní opatření. (i)“. To byla zpráva v mnoha
denících na jaře roku 2011. Kriminalita není v prostředí IT nic nového. Nyní by mohl některý malý
podnik samozřejmě tvrdit, kdo by tak mohl už profitovat z mých údajů? Přitom je téma bezpečnost
3
IT širší, než by si člověk myslel a skutečně relevantní také pro malé podniky:
Křestní jména, značky aut, data narození nebo oblíbený fotbalový klub – mnoho
uživatelů používá lehce zapamatovatelné výrazy, aby si zapamatovali heslo.
Existuje v podniku příslušná směrnice?
Je heslo administrátora pro případ jeho výpadku bezpečně uloženo u
nadřízeného?
Jsou instalovány virové scannery a provádí se jejich pravidelná aktualizace?
Jsou pevné disky před jejich likvidací bezpečně vymazány?
Jsou důležité servery bezpečně uloženy, aby se chránily před poškozením vodou
nebo horkem?
Co se děje s e-maily, když je zaměstnanec na dovolené?
Kdo smí v podniku používat svůj soukromý mobilní telefon?
Četné statistiky dokládají, že asi polovina případů relevantních pro bezpečnost není způsobena
externími původci, ale samotnými zaměstnanci podniku. Téměř ve všech případech se toto děje
neúmyslně, většinou to je nepozornost, nedostatečné proškolení nebo lehkomyslnost. Na základě
toho by měly i malé a střední podniky analyzovat možná nebezpečí a přijmout protiopatření.
Přitom by měla být zohledněna všechna možná rizika:
ochrana informací před neoprávněným přístupem a před škodlivým softwarem
(např. viry, útoky hackerů, špionáž),
předání informací oprávněným osobám (Access Management) a
zajištění infrastruktury proti vlivům z prostředí mimo IT (např. přepětí v elektrické
síti nebo výpadek elektřiny, povodeň, vedro nebo dokonce požár).
Přijatá opatření (např. zajištění protipožární stěny, používání klimatizačního zařízení) je nutné
považovat za preventivní. Opatření, která byla přijala, přitom mají být úměrná možné škodě.
Provozovat server v úklidové místnosti vedle chemikálií a vlhkých hadrů je jistě nedbalé.
Autonomní výpočetní středisko odolávající zemětřesení ale také není pro malý podnik vhodné.
Stoprocentní ochrana je možná pouze zřídka nebo je pouze spojená s vysokými náklady, které lze
ospravedlnit pouze v několika málo oblastech použití. Odpovídajícím způsobem by však měla být
pojmenována možná rizika a plánována opatření, pokud by rizika přece jen nastala. To se děje
v takzvaném plánu obnovy (IT-Recovery-Plan) s různými scénáři. Cílem je aby služby, u kterých
došlo k výpadku, byly co možná nejrychleji uvedeny zase do běžného provozu.
1
Pokud musí být například při dlouhodobém výpadku proudu servery vypnuty, měl by plán obnovy
popisovat systematický postup při jejich startu, aby se přihlédlo ke všem vzájemným závislostem
jednotlivých systémů a aby nedošlo k žádnému dalšímu zpoždění nebo dokonce ke vzniku škody.
1.3 Dohled, rozvoj a řízení změn
Vertikální úroveň
Úroveň I
Strategické
plánování
Dohled, Rozvoj a řízení změn
Zaměření IT
na strategii
podniku
IT strategie
Definice IT
služeb
Řízení inovace
na bázi IT
Kontrola
a Audit
Trvalý rozvoj
IT služeb
Úroveň II
Provoz IT
služeb
Řízení IT
projektů
Údržba a
podpora
Informační
systémy a
externí služby
Sladění
procesů
Řízení změn
Zajištění
IT služeb
Bezpečnost
a prostředí
Dohled
a Vyhodnocení
Řízení změn
a Rozvoj
IT Projekty
1.3.1 Dohled a vyhodnocení
Každá příručka ITSM musí mít oddíl, v němž jsou popsána pravidla a mechanismy, které jsou
odpovědné za monitoring a kontrolu všech úkolů a aktivit ve vztahu k IT. Audit a kontrola
informačních systémů jsou součástí interního auditu a kontrolních funkcí organizace.
Institut interního auditu (Institute of Internal Auditors - IIA) se k tomu vyjadřuje následujícím
i
způsobem : „Interní audit (monitoring) představuje nezávislou a objektivní aktivitu, aby se získala
jistota týkající se faktů a poradenských služeb. Středem zájmu je čerpání hodnoty a zkvalitnění
podnikových procesů. Podporuje podnik při dosažení jeho cílů tak, že se poskytuje systematické a
disciplinované nasazení pro hodnocení a zkvalitnění efektivity řízení rizika, kontrolních a řídících
procesů.“
Iniciativa amerického soukromého sektoru definovat jednotné pojetí obsahu pojmu „systém
vnitřního řízení a kontroly (Committee of Sponsoring Organizations of Tradeway Commission
ii
- COSO) se vyjadřuje následovně : “Interní kontrola se obecně definuje jako proces, který provádí
představenstvo organizace, řízení a další personál, aby se zajistila rozumná míra jistoty týkající se
dosažení cílů v následujících kategoriích: (1) účinnost a efektivita procesů; (2) spolehlivost při
sestavení finančních zpráv (3) sladění s aplikovanými zákony a předpisy.“
1
Audit a kontrola spolu úzce souvisejí a často se o nich hovoří společně a společně se také popisují.
Oběma postupy má být získána jistota, která se týká dosažení cílů podniku. Existuje ovšem jasný
rozdíl mezi pojmy:
Kontrola se provádí na základě vlastního hodnocení, to znamená, že ji provádějí
zaměstnanci, kteří jsou kompetentní pro určité úkoly. V oblasti IT se toto může
vztahovat například na administrátora systému, který systematicky kontroluje, zda
úkoly, které provedl, byly řádně splněny.
Na rozdíl od kontroly musí být audit proveden nezávislou jednotkou (to znamená
bez pomoci některého interního oddělení podniku, které je za určitý úkol
odpovědné) a zaměřuje se na efektivitu kontrolních mechanismů. Prostřednictvím
auditu by se mělo zkontrolovat, zda je kontrolní systém efektivní. Toto se zase
vyjadřuje v potenciální schopnosti identifikovat chyby a nepravidelnosti, které stojí
v cestě dosažení cílů podniku.
U malých a středních podniků hrají kontrolní aktivity nejdůležitější roli, což lze odůvodnit strukturou
účastníků jednotlivých procesů a strukturou podniku (viz níže). Z tohoto důvodu byl název tohoto
oddílu (3.3.1) změněn na „audit a kontrola“ namísto názvu „kontrola a audit“, který je v literatuře
používán nejčastěji.
Obecně se všechny aktivity auditu a kontrolní aktivity zabývají systematickým sledováním většího
počtu definovaných cílů kontroly. Přitom se zjišťuje, zda jsou cíle splněny, resp. zda je odhadnuto,
v jakém rozsahu budou splněny.
Co se týká auditu a kontroly informačních systémů, jsou k dispozici četné směrnice a normy.
Existuje však obecně uznávaná vzorová norma, v níž se popisuje, jak má být v podniku proveden
audit a kontrola týkající se IT. Jedná se o COBIT: Control Objectives for Information and Related
iii
iv
Technology . Existuje i zjednodušená verze této normy s názvem „COBIT Quickstart“ , která je
koncipovaná speciálně pro malé a střední podniky a přizpůsobena jejich specifickým vlastnostem.
Tyto normy mohou být použity jako referenční modely, jestliže byly v podniku implementovány
konkrétní procesy auditu a kontrolní procesy.
Velké podniky mají vlastní dobře organizovaná oddělení auditu s příslušnými postupy, zatímco
malé a střední podniky se touto problematikou nezabývají tak hluboce organizovaně a
systematicky. Příčinou toho je skutečnost, že struktura MSP je o mnoho menší než struktura
velkých podniků a obvykle také neformulují žádné dlouhodobé strategie.
Jaká úroveň auditů a kontrol je přiměřená průměrnému malému a střednímu podniku? Na tuto
otázku si musí podrobně odpovědět management daného podniku. Je však možné se omezit na
čtyři specifické procesy:
1
1. poskytnutí Governance IT,
2. sledování a hodnocení výkonu IT,
3. zajištění sladění s externími požadavky a
4. monitoring a hodnocení interní kontroly.
U procesů 1-3 se jedná o pouhé kontrolní procesy, protože je provádějí v plném rozsahu
zaměstnanci, kteří jsou pověřeni řízením denně vzniklých úkolů v oblasti obchodních procesů a IT
firmy. Proces 4 je naproti tomu proces auditu a měl by být proveden externím podnikem.
Obecně by měl být každý proces funkce auditu nebo kontrolní funkce proveden v následujících
krocích:
1. definice vhodných procesů řízení,
2. kontrola vyspělosti procesu,
3. definice kompetencí v podniku a
4. definice nejdůležitějších výkonových ukazatelů, které se používají pro monitoring procesů.
Co se týká definice procesů řízení, musí podnik stanovit a vypracovat určité vzory požadovaných
postupů, které splňují požadavky ITSM, jež byly identifikovány při formulování obchodních strategií
a strategií IT. Požadované postupy mohou například zahrnovat následující: (1) zřízení
pravidelného reportingu o aktivitách IT pro kontrolu ze strany řízení firmy, (2) postup pro projednání
omezeného počtu relevantních a měřitelných výsledků a ukazatelů týkajících se IT, které se budou
nepřetržitě sledovat, (3) kontrola metody, pomocí které jiné podniky v oboru zpracovávají témata IT
a důležitá rozhodnutí v oblasti IT nebo (4) identifikace požadavků, které vzniknou z důvodu sladění
s externími předpisy. Všechny postupy řízení závisejí na procesech. Na základě toho musí být
vytvořeny odděleně pro každý jednotlivý proces. Co se týká MSP, měl by být počet postupů řízení
omezen na rozumnou hodnotu, maximálně na 3 postupy na jeden proces.
Vyspělost určitého procesu lze kontrolovat tak, že se srovná aktuální a požadovaný stav
specifického procesu v rámci podniku s cílem podniku a průměrnou hodnotou v oboru. Toto může
být provedeno následujícími kroky:
1. Definování aktuální pozice procesu v rámci podniku.
2. Definování požadované pozice procesu v rámci podniku. Aby bylo možné provést tento
krok, může být jako referenční hodnota použita průměrná pozice v oboru.
3. Určení mezery mezi aktuální a požadovanou pozicí.
1
4. Definování procesu změny z aktuální na požadovanou pozici.
5. Definování integrovaného implementačního programu pro Governance.
Nástrojem k provedení tohoto úkolu je model vyspělosti. Tato koncepce byla převzata z metodiky
CMMI (Capability Maturity Model Integration), která je definována SEI (Software Engineering
Institute). Skládá se z 5 úrovní:
v
1. Začátečnická – proces vyplývá ze situace a je chaotický.
2. Spravovaná – proces je plánován a prováděn v souladu se směrnicemi podniku.
3. Definovaná – proces je dobře popsán a pochopen a charakterizován ve vztahu k normám,
postupům, nástrojům a metodám.
4. Spravovaná kvantitativně – výkon a kvalita procesu se měří kvantitativními požadavky.
5. Optimalizovaná – proces se průběžně zkvalitňuje prostřednictvím kvantitativních náhledů
do příslušných obchodních zadání a požadavků na výkon.
Konkrétní normy ITSM mohou obsahovat upravené verze modelů vyspělosti. Změna může
zahrnovat odlišný název a počet úrovní, základní myšlenka však zůstává zachována: probíhá od
nejnižší k nejvyšší úrovni, přičemž s každou úrovní vyspělost modelu vzrůstá.
Každý proces provádějí osoby. Proto musí podnik definovat kompetence jednotlivých rolí a každý
postup řízení kontrolovat vhodnou rolí podniku a druhem kompetence. U ITSM se toto označuje
jako diagram RACI nebo také diagram RASCI:
Responsible – odpovědný (odpovědnost za provedení), kompetentní za vlastní provedení.
Interpretuje se také jako odpovědnost v disciplinárním smyslu.
Accountable – odpovědný účtovat (odpovědnost za náklady), odpovědný ve smyslu „schválit“,
„povolit“ nebo „podepsat“. Osoba, která nese odpovědnost v právním a obchodním smyslu.
Supportive – podpůrný. Osoba může hrát podpůrnou roli nebo poskytovat provozní prostředky.
Consulted – konzultující (odborná odpovědnost). Osoba, kterou žádáme o radu. Interpretuje se
také jako odpovědnost z odborného pohledu.
Informed – informovaná (právo na informace). Osoba, která obdrží informace o průběhu, resp.
výsledku činnosti nebo která má oprávnění obdržet informace.
U MSP se mohou podnikové role vztahovat na majitele, obchodní vedení, vedoucí oddělení IT,
různé vedoucí oddělení, hlavního účetního atd. Tyto role musí být pečlivě přidělovány a
přizpůsobeny rámci a rozsahu aktivit podniku. Na příkladu autodílny by mohla mít matrice RASCI
tuto strukturu:
1
R
C
Prohlídka vozidla
R
Nákup náhradních dílů
A
pobočky
Vedoucí
Skladník
Učeň
Mistr
zákazníkům
služeb
Manažer
Příprava jednání se zákazníkem
A
S
I
A
R
Oprava
I
A
R
Vystavení faktury
R
S
C
A
Obrázek 11 – Příklad matrice RASCI
Každá metoda ITSM je tehdy efektivní, jestliže se měří její účinnost a efektivita. Obecně se
účinnost vztahuje na „provedení správných akcí“, zatímco efektivita se týká „správného provedení
akcí“. Existují dva druhy měrných veličin, pomocí kterých se mohou výše uvedené cíle měřit.
Z celého množství dostupných měrných veličin se vyberou nejdůležitější měrné veličiny a definují
se jako hlavní měrná veličina. Používají se ve výkazech a mají umožnit zajištění účinnosti,
efektivity a hospodárnost. Ty jsou definovány jako Klíčové cílové indikátory (Key Goal Indicators KGI) pro měření účinnosti a Klíčové výkonnostní indikátory Key Performance Indicators (KPI) pro
měření efektivity v rámci ITIL; COBIT používá Lag Indicator, resp. jako synonymum Lead Indicator.
Key Goal Indicator (KGI) nebo Lag Indicator
Měrné veličiny, které managementu ukazují, zda proces IT splnil požadavky podniku. Příkladem
KGI by mohl být počet incidentů.
Key Performance Indicator nebo Lead Indicator
Měrné veličiny, které určují, jak dobře si stojí výkonnost (Performance) procesů IT, co se týká
podpory dosažení cílů. Jsou včasnými indikátory toho, zda bude cíl pravděpodobně splněn nebo
ne. KPI jsou například reakční čas nebo kvóta počátečních řešení incidentů.
Jak již bylo dříve v této kapitole zmíněno, je COBIT Quickstart doporučení pro praxi, které může
být použito jako referenční model při zavádění postupů kontroly a auditu v rámci malých a
středních podniků. Toto doporučení může a mělo by být přizpůsobeno zvláštnostem a struktuře
2
podniku. Úprava může spočívat například ve snížení počtu jednotek podniku v diagramu RA(S)CI,
snížení nebo rozšíření úrovní vyspělosti procesů nebo v jiných změnách. Podrobný popis lze najít
v aktuálním COBIT Quickstartu IT Governance Institutu.
1.3.2 Sladění (Compliance)
V odborném jazyce se pojem Compliance (výjimečně přeloženo jako konformita s předpisy)
používá, aby se označilo dodržování národních, evropských a mezinárodních zákonů a směrnic
(např. Spolkový zákon o ochraně údajů, Basilejská úmluva II, Sarbanes-Oxley Act), ale také
dobrovolných kodexů v podniku. Pojem sladění zahrnuje také některá pravidla týkající se IT jako
bezpečnost (ochrana osobních údajů), zdraví, ergonomie, důvěrnost, právní a regulační
požadavky, duševní vlastnictví, dohody o internetových obchodech, pojistné smlouvy, jakož i
předpisy a postupy specifické pro daný obor, jako například závazek k uchovávání záznamů
z tachografů.
Cílem sladění IT je široké a trvalé dodržování požadavků souladu s předpisy. Vedle zajištění
právních důsledků vznikají výhody při hodnocení podniku a vyšší bezpečnost IT. Klíčovým úkolem
je dokumentace a odpovídající přizpůsobení zdrojů IT při změnách předpisů. Pravidelně by také
měly být hodnoceny možné problémy nebo možná nebezpečí (viz také kapitola 3.2.3).
Všechna témata v oblasti sladění musí být zkontrolována s velkou pečlivostí, protože počet těchto
předpisů stále vzrůstá. Při porušení předpisů mohou být v mnohých zemích jednatelé a členové
představenstva činěni osobně odpovědnými za dodržování ustanovení zákona. Pokud se předpisy
nerespektují, mohou hrozit občanskoprávní, ale také trestněprávní sankce. Tak stanoví spolkový
zákon na ochranu osobních údajů (BDSG) za porušení tohoto zákona trest odnětí svobody na
dobu až do 2 let nebo peněžní pokutu. Později, od té doby, co Basilejská úmluva II ukládá
finančním institucím široké kontroly, existuje potřeba jednat pro nastolení sladění IT u všech
podniků.
Další podrobné informace, jakož i vzorové procesy k tématu sladění (Compliance) jsou podrobně
obsaženy v aktuálních publikacích COBIT.
1.3.3 Řízení změn
Už jste si někdy instalovali update softwaru a následně to už dál nefungovalo? Pokud jsou přitom
účinky omezeny na vlastní pracovní místo, nemuselo by to být zase tak špatné. Ale pokud si člověk
představí při tom důsledky při update všech počítačů podniku? Ale administrátorovi se tato
nepředvídaná událost stane jen jednou a bude v budoucnu vše kontrolovat dvakrát. Často až
1
byrokraticky chápané řízení změn (Change Management) může být na tomto místě účelnou
pomůckou, aby se zamezilo vzniku poruch. Poskytuje rozhraní k jiným procesům, zejména ke
stálému procesu zkvalitnění nebo k řízení problémů. Tak jsou například v řízení problémů
identifikovány možné problémy, jsou analyzovány a je definováno jejich řešení. Jestliže řešení
problému vyžaduje změnu aktuální situace, postoupí se potřebné úpravy prostřednictvím
požadavku o změnu do procesu změn. Ten definuje strukturovaný průběh, kterým se má určitý
prvek (např. počítač pracovního místa, hardware, serveru ale také služby nebo procesy)
prostřednictvím modifikace, připojení nebo odstranění převést z aktuálního stavu do požadovaného
budoucího stavu. Cílem řízení změn (Change Management) je umožnit změnu, která se vyplatí, při
minimálním přerušení služeb IT.
Change (změna)
Každá změna existujícího prostředí IT se definuje slovem „Change“ (změna). Tak může např.
identifikace nějakého problému (např. tabulková kalkulace pořád padá, jestliže je současně
otevřena aplikace E-Mail Client) vést ke změně, jestliže bylo nalezeno řešení problému. Odpovědí
na zmíněný problém by mohlo být zvýšení paměti v počítačích. Tato změna se označuje jako
Change.
Kromě „tvrdých změn“ (hart Changes), tedy např. technologických změn, které byly popsány výše,
existují často organizační změny označené jako „měkké změny“. Masivní zapojení faktoru „člověk“
si zde vyžaduje zvláštní postup a na základě toho je tomuto komplexnímu tématu věnována vlastní
kapitola (kapitola Chyba! Nenalezen zdroj odkazů.).
Změny informační technologie jsou v dnešní době na základě silné dynamiky a počtu různých
prvků a jejich vzájemné závislosti komplexním úkolem. Změny mohou mít přitom víceúrovňové a
dalekosáhlé důsledky. Jestliže se třeba zavádí nový provozní systém a pokud se následně zjistí, že
použitá tiskárna a ekonomické aplikační systémy podniku nejsou kompatibilní, mohou být následky
již velmi dalekosáhlé. Proto je nejvyšším cílem řízení změn minimalizace rizika. Tím, že se změny
provádějí pod kontrolou, je možné sledovat i možná rizika, která s sebou změny přinášejí.
Indikátory potenciálu zkvalitnění vlastního řízení změn mohou být:
časté neplánované výpadky služeb,
nižší kvóta úspěšnosti při provedení změn a
vysoká míra nouzových změn nebo neautorizovaných změn.
1
Jestliže jsou tyto důvody správné, je účelné o tématu přemýšlet. Ale i kromě minimalizace rizika
může profesionální řízení změn přinést další přidané hodnoty pro IT a pro zákazníky:
kvalifikované zpracování změn a lepší plánování doby, kvality a nákladů,
střednědobé snížení nákladů prostřednictvím standardizovaných postupů,
zvýšení produktivní doby služeb IT prostřednictvím snížení doby výpadku služeb a
kombinované sledování obchodních aspektů a aspektů IT u nějaké změny, aby
bylo možné identifikovat potenciály zlepšení.
Aby se dosáhlo určité transparentnosti, rozumné databáze pro rozhodnutí a konečně také
dokumentace, evidují se požadované změny v požadavku o změnu (Request for Change). Přitom
může být takový požadavek o změnu evidován pragmaticky na lístku prostřednictvím uživatelské
podpory nebo jako vzor dokumentu, který musí být vyplněn. Důležité však je, aby bylo určeno, jaká
forma musí být pro jaký typ změny použita a že jsou v případě potřeby k dispozici příslušné
varianty. V praxi se vykrystalizovaly v tomto ohledu tři typy změn:
Standardní změny
Změny, které jsou stanoveny pro standardizovaný postup již předem a které mají zpravidla pouze
nepatrný vliv. Vzhledem k jejich generálnímu plánování nevyžadují žádnou schvalovací proceduru.
Takovou změnou je například zřízení nového e-mailového účtu, odvolání hesla nebo zřízení
obvyklého pracovního místa.
Běžné změny
Změny, které nejsou časově v podstatě kritické a které nemohou být zpracovány jako standardní
změna. Takovou změnou by mohlo být například nahrání doplňku IT do systému ERP.
1
Nouzové změny (Emergency)
V případě incidentu může být nutné provést rychlé změny. V takovém případě je běžná procedura
příliš dlouhá a příliš těžkopádná. Změny mohou být provedeny sice podle definovaných požadavků,
ale mnohem rychleji. Toto se aplikuje, jestliže například výpadek hardwaru ovlivňuje servery.
Na závěr zbývá ještě vysvětlit činnosti řízení změn (Change Management). Ty jsou, jak je v řízení
IT služeb obvyklé – definovány jako proces. Následující diagram tento proces zobrazuje. Nejdříve
se vysvětlí obě role managera změn (Change Manager) a autorita: role managera změn spravuje
změnu. Role může být obsazena více osobami. Často je odpovědný zaměstnanec uživatelské
podpory také za první kroky řízení změn. Obsazení role může být definováno podle potřeb
podniku. Role autorita se často obsazuje takzvaným „Change Advisory Board“. Skládá se ze
zástupců všech oblastí IT, obchodních oblastí a možných třetích stran (např. externí dodavatelé).
V menších podnicích však může být Change Advisory Board nahrazen také obvyklou poradou
týmu.
1
+
Start
Manaž er z měn
Vytvoření
požadavku na
změnu
Iniciátor
Manaž er z měn
Kontrola
požadavku na
změnu
Standardní změny
Zamítnutí
Výsledek?
Změny
Manaž er z měn
Hodnocení změny
Manaž er z měn
Dokumentace
důvodů zamítnutí
Auditor
Autorizace změny
Ne
Autorizace?
Ano
Manaž er z měn
Plán provedení
změny
Manaž er z měn
Implementace
změny
Kontrola a
ukončení změny
Konec
po
provedení
změny
Obrázek 12 – Proces řízení změn v návaznosti na ITIL
1
Konec
bez
provedení
změny
1. Vystavení požadavku na změnu
O změnu se zásadně žádá prostřednictvím požadavku iniciátora (např. zaměstnanec , organizační
jednotka nebo také zaměstnanec uživatelské podpory) formou požadavku na změnu (Request for
Change nebo také Change Request). Nákres a dokumentace požadavku na změnu se může
uskutečnit různými způsoby (například v papírové formě, e-mailem, webovým formulářem). Stupeň
podrobností přitom závisí na rozsahu a účincích změny. V ideálním případě se použije integrovaný
nástroj řízení IT služeb, který jednak dokumentuje všechny údaje a na druhé straně může zobrazit
závislosti (např. na konfigurační prvky). Na základě požadavku o změnu se otevře záznam o
změně (Change Record), který dokumentuje všechny činnosti.
2. Kontrola požadavku o změnu
Při počáteční kontrole požadavku o změnu prověřuje manager změn jeho smysluplnost a
kategorizaci. Tak jsou standardní změny postoupeny přímo ke zpracování. Naproti tomu se
přefiltrují žádosti, které jsou neproveditelné, neúplně vyplněné nebo již byly hodnoceny, a iniciátor
bude následně informován o zamítnutí žádosti spolu s odůvodněním. Žadateli by mělo být při tomto
postupu poskytnuto právo podat odpor.
3. Hodnocení změny
Aby bylo možné přijmout rozhodnutí o změně, musí se evidovat určité parametry. ITIL tyto
parametry označuje jako „sedm R řízení změn“.
1. Who RAISED the change? Kdo předložil požadavek na změnu?
2. What is the REASON for the change? Co je důvodem změny?
3. What is the required RETURN? Co je požadovaným výsledkem změny?
4. What are the RISKS? Jaká rizika existují?
5. What RESOURCES are required? Jaké zdroje jsou potřebné?
6. Who is RESPONSIBLE for required activities like implementation and test? Kdo je
odpovědný za potřebné aktivity jako implementace a testování?
7. What is the RELATIONSHIP between this change and other changes? Jaký je vztah mezi
touto změnou a ostatními změnami?
Zjištěné informace pak mohou být využity ke stanovení správné úrovně autorizace, aby mohly být
identifikovány zájmové oblasti („Kdo je tím dotčen?“) nebo také aby mohly být definovány obchodní
případy (Business Case), vlivy, náklady, zisk a riziko.
1
4. Autorizace změny
Autorizace zajistí, aby byli o změně informováni všichni zúčastnění a aby se s ní vyrovnali. Takto
vytvořenou transparentností se snižují rizika a vlivy lze kontrolovat. Podle typu, rozsahu a rizika
změny může být podle kultury podniku účelné stanovit různé stupně autorizace. Tak se jistě
výměna ? mechaniky s pouze nepatrnými účinky bude patrně projednávat pouze interně v oddělení
IT. Schválení změny (Release) systému ERP se pak ale jistě bude projednávat také až do úrovně
vedení podniku. Nezávisle na rozhodnutí grémia budou o výsledku informováni všichni zúčastnění,
zejména žadatel.
5. Plánování změny
Při změnách softwaru má často smysl kombinovat všechny změny v takzvané Releases a pak je
zpřístupnit v jediném kroku. Zde by však měly být prověřeny také výhody (např. zlepšené
pánování, lepší stupeň realizace) ve vztahu k nevýhodám (např. termínové zpoždění). Dále by
měla být plánována a odsouhlasena vlastní realizace. Zde je nutné přihlédnout k tomu, aby byly
aktivní služby ovlivněny co nejméně. Výsledkem by měly být jasně definované balíčky určených
činností.
6. Implementace změny
Autorizované změny se (formálně) předávají jako pracovní balíčky příslušným zaměstnancům nebo
týmům. Ty provedou vlastní implementaci. Řízení změn však nese odpovědnost za koordinaci
činností a včasné dokončení implementace.
7. Kontrola a ukončení změny
V posledním kroku se změna ještě jednou zkontroluje a ukončí. To se provádí následujícími
aktivitami:
rekapitulací dokumentace změny,
kontrolou změny a její dokumentace,
ukončením dokumentace změny (po ukončení všech činností),
oznámením ukončení všem zúčastněným a prezentací změny k převzetí a
pokud existují referenční poruchy nebo problémy, mohu být tyto rovněž
zkontrolovány a ukončeny.
V případě, že je některá změna velmi časově naléhavá (např. výpadek severu), hovoří se o
nouzové změně. V tomto případě by se mělo postupovat podobným způsobem, avšak jednotlivé
kroky mohou být zkráceny. Tak se jistě značně zkrátí fáze hodnocení a plánování a bude se
1
provádět bez široké dokumentace. Autorizace se v takovém případě uskuteční prostřednictvím
relevantních zúčastněných, kteří jsou v daném okamžiku dostupní (hovoří se také o Emergency
Change Advisory Board (ECAB)). Testy se zredukují nebo se v extrémním případě neprovádějí.
Dokumentace nouzových změn se zpravidla provádí následně. Tak má být zajištěno, aby změna
přes časový tlak probíhala rozumným postupem.
1.3.4 Neustálé zlepšování služeb IT
Neustálé zlepšování služeb IT (Continual Service Improvement (CSI)) je součástí ITSM. Při něm se
používají metody z řízení kvality, aby se člověk poučil z úspěchů a neúspěchů minulosti a tímto
způsobem vypracoval řešení, kterými se bude stále zlepšovat efektivita služeb IT a procesů. CSI
musí prokázat svou hodnotu pro podnik, aby odůvodnilo svou existenci. Musí existovat jasně
definovaný účel s jasnými výhodami, které ovlivní celý podnik. CSI se podle definice ITIL skládá ze
čtyř procesů:
Hodnocení služeb IT – Cílem tohoto procesu je pravidelně hodnotit kvalitu služeb
IT. K tomu patří identifikovat oblasti, v nichž se nedosahují požadované úrovně,
jakož i pravidelné odsouhlasení s jednotlivými obchodními oblastmi, aby bylo
zajištěno, že sjednané úrovně služeb IT i nadále odpovídají obchodním
požadavkům.
Hodnocení procesů − Cílem tohoto procesu je procesy pravidelně hodnotit. To
zahrnuje identifikaci oblastí, v nichž nejsou dosahovány požadované ukazatele
procesu, jakož i pravidelné vypracování kritérií (Benchmarks) a provádění auditů,
kontrol vyspělosti a hodnocení.
Definice iniciativ pro zkvalitnění − Cílem tohoto procesu je definovat speciální
iniciativy, aby se zvýšila kvalita služby IT a procesu na základě výsledků
hodnocení služeb a procesů poskytování služeb. Iniciativy, které jsou toho
výsledkem, jsou buď interní iniciativy, které provádí poskytovatel služby
samostatně, nebo iniciativy, u kterých je potřebná spolupráce se zákazníkem.
Kontrola CSI − Tímto procesem má být zkontrolováno, jak jsou iniciativy pro
zkvalitnění podle plánu realizovány. Kromě toho se v případě potřeby provedou
opravy.
Proces CSI vyžaduje tři aktéry. První aktér, manager CSI, je odpovědný za správu inovací procesů
ITSM a služeb IT. Manager CSI stále měří výkon poskytovatele služeb a koncipuje inovace
procesů, služeb IT a infrastruktury, aby se zvýšila efektivita a hospodárnost. Druhý aktér, manager
procesů (Process Manager), je odpovědný za plánování a koordinaci všech činností týkajících se
1
řízení procesů. Podporuje všechny aktéry, kteří se podílejí na správě a inovacích procesů, což
zahrnuje také osobu odpovědnou za procesy. Tato role koordinuje také všechny změny procesů a
tím zajišťuje, aby spolu všechny procesy hladce spolupracovaly. Třetí aktér, osoba odpovědná za
procesy, odpovídá za to, aby byl proces vhodný ke svému účelu. Ke kompetencím role patří
podpora, forma a trvalé zkvalitňování procesu a jeho ukazatelů.
Podniky, které by chtěly zlepšit služby IT, si musí udělat jasno o vlivu inovací v oblastech obchod a
trh na oblast IT. Aby se zdůvodnilo zavedení dané inovace, měl by podnik porovnat náklady a zisk
(nebo úspory). Obtížné je to tehdy, když sice náklady mohou být relativně jednoduše změřeny,
avšak růst zisku jako přímý výsledek plánu zkvalitnění služby IT (Service Improvement Plan, SIP)
může být v číslech vyjádřen obtížněji. SIP je formální plán implementace zkvalitnění procesů
služeb a IT. SIP se používá, aby se spravovaly a zaprotokolovaly iniciativy na zkvalitnění vyvolané
prostřednictvím CSI. Iniciativy na zkvalitnění jsou buď:
interní iniciativy, které provádí sám poskytovatel služby, například iniciativy na
zkvalitnění procesů nebo na lepší využití zdrojů;
iniciativy, u kterých je potřebná spolupráce se zákazníkem, například zkvalitnění
služeb.
Následující informace jsou typicky obsaženy v SIP pro každou definovanou iniciativu týkající se
zkvalitnění procesu nebo služby:
1. dotčený proces nebo služba,
2. osoba příslušná pro proces (osoba odpovědná za proces) nebo za službu (osoba
odpovědná za službu),
3. osoba odpovědná za iniciativy (osoba příslušná pro iniciativu, často role v řízení IT služeb
jako manager úrovně služby (Service Level Manager), manager kapacity, manager
dostupnosti, osoba odpovědná za proces, osoba odpovědná za službu),
4. schválení nadřízeným managementem,
5. popis iniciativy,
6. zdroj opatření (např. Service Review, audit procesu),
7. obchodní scénář (očekávaný výsledek iniciativy, odhad nákladů, specificky požadovaný
výsledek iniciativy, např. určité snížení nákladů při poskytování služby) a
8. harmonogram a stav implementace (konečné datum, aktuální stav).
CSI je součástí každé úspěšné implementace řízení služeb. CSI zajišťuje, aby se služby IT
rozvíjely spolu s obchodní činností a přizpůsobily se jí a umožňuje stálé zlepšování stability,
1
výkonu a funkčnosti služeb. Projekty CSI mohou být realizovány v mnoha různých formách:
požadavek zákazníka na zjednodušení služby, méně potřebných dokumentů a nízké čekací doby
požadavků na poskytnutí služby, vytvoření špičkového katalogu služeb IT na základě lepšího
pochopení atd.
Účelem CSI je zaměřit služby IT na stále se měnící obchodní požadavky. K tomuto účelu se
identifikují a implementují inovace služeb IT, která podporují obchodní procesy. Cíle CSI jsou:
kontrola, analýza a vypracování návrhů možností zkvalitnění strategie služeb,
koncepce, přechod a postupy,
kontrola a analýza výsledků při dosažení úrovně služeb IT (Service Level),
identifikace a implementace jednotlivých činností za účelem zlepšení kvality služeb
IT,
zlepšení hospodárnosti při poskytování služeb IT bez negativních vlivů na
spokojenost zákazníků a
zajištění, aby byly použity vhodné metody řízení kvality na podporu stálých činností
nutných pro zkvalitnění služeb IT.
Co je naše vize?
Kde jsme teď?
Jak udržíme proces
v běhu?
Obchodní vize,
úkoly a cíle
Zjištění skutečné
situace
Kam chceme
jít?
Měřitelné cíle
Jak se tam
dostaneme?
Služby, procesy a
projekty
Došli jsme tam?
Měření a ukazatele
Obrázek 13 – Model CSI v návaznosti na ITIL
Podle modelu CSI (obrázek 14) je proces zkvalitnění služeb IT konstantním cyklem, který se
skládá z následujících kroků:
1
pochopení obchodní mise, cílů a zadání, aby se na tomto základě rozvinula vize
jejich zkvalitnění (Jak zní vize?),
kontrola aktuální situace týkající se obchodu, podniku, zaměstnanců, procesů a
technologie, abychom získali přesný okamžitý obraz aktuálního stravu podniku
(Kde jsme teď?),
pochopení priorit zkvalitnění a přijetí příslušných dohod na základě rozvoje zásad z
vize (Čeho bychom chtěli dosáhnout?),
vypracování podrobného plánu CSI k dosažení vyšší kvality poskytovaných služeb
prostřednictvím implementace procesů ITSM (Jak se tam dostaneme?),
kontrola měření a ukazatelů, jestli zajistí, abychom dosáhli milníků, aby bylo
sladění procesů vysoké a obchodní cíle a priority byly dosaženy prostřednictvím
úrovní služeb (Dosáhli jsme toho?).
1.3.5 Řízení projektu IT
Projekt je časově iniciativa podniknutá proto, aby se rozvíjel konkrétní produkt nebo určitá služba,
například budova nebo nový počítačový systém. Projekt se uskutečňuje od začátku až do konce a
může trvat dny, týdny, měsíce nebo dokonce roky. Zavedení internetového obchodu (Webshop) by
bylo projektem pro Karlův podnik, provozování internetového obchodu však patří ke každodenní
operativní obchodní činnosti.
Projekt
Projekt je časově a finančně omezený plán, který se podniká pro to, aby se vytvořil jedinečný
produkt, jedinečná služba nebo aby se dosáhlo jedinečného výsledku. Má jasné cíle, požadavky a
podmínky týkající se kvality. Projekt však může mít charakter organizace času.
Řízení projektu se popisuje jako řada zásad, praktických postupů a technik, kterými se provádí
kontrola harmonogramu projektu, jakož i nákladů a výkonů. Skládá se z řady úkolů, kterými se
projekt od začátku do konce provádí, aby byly dosaženy cíle, které byly předem stanoveny.
Vztaženo na tuto definici, lze řízení projektu IT chápat jako dílčí oblast, v níž jsou projekty
informační technologie plánovány, sledovány a kontrolovány. Přitom by se nemělo nechat bez
povšimnutí spektrum úkolů rozdělené do jednotlivých přihrádek. Nové oblasti vědomostí PMBOK
(obrázek 15) poskytují pohled do různých tematických oblastí, které by měly být v rámci řízení
projektu
sledovány.
1
Řízení integrace
Řízení rozsahu projektu
Řízení termínů
Řízení nákladů
Řízení kvality
Řízení personálu
Řízení komunikace
Řízení rizika
Řízení nákupu
Obrázek 14 – Oblasti vědomostí řízení projektu podle PMBOK
Nezávisle na jejich druhu se všechny projekty
provádějí a realizují v rámci určitých omezení. Tři
Doba
omezení čas, náklady a rozsah se často označují
jako magický trojúhelník řízení projektu (Project
Management
Triangle).
Časové
omezení
se
vztahuje na dobu, která je k dispozici do dokončení
Kvalita
projektu. Nákladové omezení popisuje rozpočet,
který je pro projekt k dispozici. A poslední omezení,
rozsah, stanoví, jaké činnosti musí být provedeny
Náklady
Rozsah
Obrázek 15 – Trojúhelník řízení projektu
pro dosažení cíle. Aby byl projekt úspěšný, musí být
tato tři omezení v rovnováze.
U řízení projektu je možné přihlížet k různému nasazení. Dva důležité způsoby sledování jsou:
tradiční nasazení: identifikace postupu kroků, které musí být provedeny
agilní nasazení: projekt jako řada relativně malých úkolů (žádný komplexní
proces).
Pro tradiční řízení projektu jsou potřebné velmi disciplinované metody plánování a kontroly.
V tomto nasazení je možné rozlišovat pět fází vývoje projektu. Každá fáze obsahuje procesy, jimiž
projekt postupuje od nápadu až k implementaci. Jednotlivé fáze jsou:
1. fáze iniciování projektu
2. fáze plánování a návrhu projektu
3. fáze provedení a realizace projektu
4. systémy monitoringu projektu a kontrolní systémy a
5. ukončení projektu.
1
Při tradičním nasazení se vychází z toho, že lze předvídat, jaké určité události projekt ovlivní.
Z tohoto důvodu musí být všechny úkoly provedeny postupně ve správném pořadí.
V porovnání s tradičním nasazením vychází agilní řízení projektu ze zásady, že centrem řízení má
být interakce mezi jednotlivci. Projekt se považuje za řadu relativně malých úkolů, které se
přizpůsobují dané situaci a které se nekoncipují a nerealizují v rámci předem kompletně
plánovaného procesu.
Používá se řada metod řízení projektu, aby se formálně stanovilo, jak bude řízení projektu
probíhat. Project Management Body of Knowledge (PMBOK), Projects in Controlled Environments
(PRINCE) nebo SCRUM jako agilní metodika pro vývoj softwaru a produktů se vysvětlí na
příkladech v následujících odstavcích. Cílem těchto tří technik vždy je standardizovat postupy
vývojového týmu, aby je bylo možné snadněji předvídat a spravovat.
Project Management Body of Knowledge (PMBOK)
PMBOK je vedoucí myšlenkou řízení projektu, sestava ze standardní terminologie (IEEE, ANSI),
která poskytuje základy řízení projektu, jakož i jejich uplatnění na větší množství projektů. Vedoucí
myšlenka PMBOK byla poprvé zveřejněna ústavem Project Management Institute v roce 1987.
Zabývá se použitím poznatků, schopností, nástrojů a technik, aby se splnily požadavky projektu.
Projekt se realizuje prostřednictvím integrace procesů řízení projektu. Tým projektu je aktivní
v devíti vědomostních oblastech: integrace, rozsah, čas, náklady, kvalita, personalistika,
komunikace, rizika, nákup. V těch je definována řada základních procesů a dobře popsán jejich
vstup, nástroje a techniky, jakož i výstup. Manager projektu je odpovědný za splnění cíle projektu,
aby poskytl definovaný konečný produkt. Přitom musí být dodržena omezení týkající se rozsahu
projektu, doby, nákladů a potřebné kvality.
Project in Controlled Environments (PRINCE2)
PRINCE2 je nasazení na bázi produktu pro řízení projektu, které bylo vyvinuto vládou Velké
Británie a mezinárodně se používá, zejména v prostředí IT. Jako skalní metodu ke spravování
projektů IT a jiných obchodních projektů definuje PRINCE2 čtyřicet různých aktivit a strukturuje je
do sedmi procesů: (1) start projektu, (2) iniciace projektu, (3) řízení projektu, (4) řízení jedné fáze,
(5) řízení přechodů jednotlivých fází, (6) řízení dodávek produktů a (7) ukončení projektu. V této
metodě se každá proces specifikuje s centrálními vstupy a výstupy (Inputs a Outputs) a s určitými
časy a aktivitami, které musí být provedeny. To umožňuje automatickou kontrolu jakýchkoli
1
odchylek od plánu. Metoda je rozdělena na zvládnutelné fáze a umožňuje efektivní kontrolu zdrojů. Na
základě přímé kontroly může být projekt proveden kontrolovaným a organizovaným způsobem.
PRINCE2 je flexibilní metoda a může být aplikována na jakékoliv druhy projektů.
SCRUM
V dnešní globální ekonomice jsou tvůrci softwaru vystavení tlaku rychleji vyexpedovat správné
produkty. Jako rámcová koncepce pro provedení projektů na základě zásad a hodnot agilního řízení
projektu může být použit SCRUM k organizování a řízení komplexních inovací softwaru a produktů
dílčími postupy, které se opakují. Musí být přihlédnuto k tomu, že tato metodika byla sice původně
koncipována pro projekty v oblasti vývoje softwaru, ale že může být použita jak pro jednoduché, tak
pro komplexní inovační projekty.
Jak je tomu i u jiných metod, které byly od agilní metody odvozeny, nepokouší se SCRUM o to, aby
vše definoval na začátku projektu. SCRUM sází naopak na empirické nasazení, při kterém se celý
projekt dělí na „sprinty“, tedy na časové úseky, které tým stanoví, v trvání obvykle dva až čtyři týdny.
Na konci každého sprintu kontrolují členové týmu na poradách postup projektu a plánují další kroky.
i
http://www.theiia.org/theiia/about-the-profession/internal-audit-faqs/?i=1077 (Vyvoláno dne
15.03.2011).
ii
http://coso.org/IC-IntegratedFramework-summary.htm (Vyvoláno dne: 15.03.2011).
iii
IT Governance Institute (2007a) Control Objectives for Information and related Technology (COBIT)
4.1, IT Governance Institute, Rolling Meadows, IL, http://www.isaca.org/KnowledgeCenter/Research/ResearchDeliverables/Pages/COBIT-4-1.aspx (Vyvoláno dne 15.03.2011).
iv
IT Governance Institute (2007b) COBIT Quickstart, 2
nd
Edition, IT Governance Institute, Rolling
Meadows, IL http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/COBITQuickstart-2nd-Edition.aspx (Vyvoláno dne: 15.03.2011).
v
Software Engineering Institute (2010) CMMI for Development, Version 1.3, Carnegie Mellon
University Software Engineering Institute, TECHNICAL REPORT CMU/SEI-2010-TR-033, ESC-TR2010-033, listopad, http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm (Vyvoláno dne:
9.05.2011).
2