Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie
Diplomant: Bc. Michal Rajnyš Vedoucí diplomové práce: Ing. Jan Tolar Oponent diplomové práce: Prof. Ing. Jiří Voříšek, CSc.
METODIKY ŘÍZENÍ INFORMATICKÝCH PROCESŮ – IMPLEMENTACE ISO 20000
školní rok 2007/2008
-1-
Prohlášení
Prohlašuji, že jsem diplomovou práci zpracoval(a) samostatně a že jsem uvedl(a) všechny použité prameny a literaturu, ze kterých jsem čerpal(a).
V Praze dne 30.6. 2008 ………………………………. podpis
-2-
Abstrakt Rozšiřující se počet konzultačních firem nabízejících podporu při implementaci normy ISO/IEC 20000 a jejich ujišťování, že je vhodná pro jakýkoliv typ organizace, klade otázku, zda je tomu skutečně tak? Text se zabývá metodikami řízení informatických procesů v MSP a zdůrazňuje problémy, které mohou v tomto segmentu nastat. Práce obsahuje jak teoretická východiska, tak zkušenosti z plánování implementace ISO 2OOOO v malém podniku zabývajícím se Business Inteligence. V první části práce jsou metodiky zasazeny do obecného rámce řízení informatiky (IT governance) a je diskutován jejich účel a dopady standardizace řídících procesů, ke kterému jejich používání vede. Hlavní pozornost je věnována ITIL a ISO 20000 a jejich vzájemnému vztahu. U obou metodik je posouzena vhodnost pro segment MSP. V rámci praktické části jsou definovány podmínky, které je třeba splnit pro úspěšnou implementaci ISO 20000 v MSP. Hlavním výstupem této části je konkrétní metodika implementace ISO 20000 v malém podniku. Klíčová slova: řízení IT služeb, ITIL, ISO 20000,metodika, MSP, norma, procesy, standard
Abstract Increasing amount of consulting companies offering support for implementation of norm ISO/IEC 20000 and their assurance that this norm is suitable for any type of organization is bringing a question if it is in reality true. The text is considering methodologies of information processes management in MSP and is highlighting problems that can arise in this segment. The work consists of theoretical outputs as well as experience from planning the implementation of ISO 20000 in a small Business Intelligence company. In the first part of this work are methodologies put in general frame of informatics management (IT Governance) and is discussed their purpose and impacts of standardization of management processes to which their use is leading. The main attention is paid to ITIL and ISO 20000 and their mutual relationship. In both methodologies is apprised suitability for segment MSP. In scope of the practical part are defined conditions that need to be fulfilled in order to achieve successful implementation of ISO 20000 in MSP. The main output of this part is concrete methodology of implementation of ISO 20000 in a small company. Key words: ITSM, ITIL, ISO 20000, methodology, norm, processes, SME, standard
-3-
Poděkování Rád bych na tomto místě poděkoval vedoucímu práce Prof. Ing. Jiřímu Voříškovi, CSc. za konzultace a podporu při psaní této práce. Mé díky patří i kolegům a vedoucím pracovníkům ze společnosti Inekon Systems s.r.o. za přátelský a otevřený přístup při poskytování informací pro potřeby mé diplomové práce.
-4-
Metodiky řízení informatických procesů – implementace ISO 20000..............................................1 Abstrakt............................................................................................................................................3 Poděkování.......................................................................................................................................4 1 Úvod...............................................................................................................................................7 2 Význam a užití metodik..................................................................................................................9 2.1 Základní pojmy.......................................................................................................................9 2.1.1 Metodika..........................................................................................................................9 2.1.2 IT Governance.................................................................................................................9 2.2 Názvosloví............................................................................................................................11 2.3 Ekonomické efekty ICT v organizaci....................................................................................11 2.4 Standardizace........................................................................................................................12 2.5 Závěr.....................................................................................................................................13 3 Přehled Metodik..........................................................................................................................14 3.1 COBIT...................................................................................................................................14 3.2 ITIL- Information technology infrastructure library..............................................................15 3.2.1 ITIL V2..........................................................................................................................15 3.2.2 ITIL V3..........................................................................................................................22 3.2.3 Hodnocení ITIL.............................................................................................................36 3.3 ISO20000..............................................................................................................................38 3.3.1 PDCA.............................................................................................................................40 3.3.2 Procesy...........................................................................................................................41 3.3.3 ISO 20000 – 2 ...............................................................................................................43 3.3.4 Co norma obsahuje.........................................................................................................43 3.3.5 Kvalita...........................................................................................................................44 3.3.6 Audit..............................................................................................................................44 3.3.7 Hodnocení ISO 20000....................................................................................................46 3.4 Závěr.....................................................................................................................................48 4 Zkušenosti z projektu implementace............................................................................................49 4.1 Priority procesů.....................................................................................................................49 4.2 Metodika implementace ISO 20000......................................................................................50 4.2.1 Metodiky implementace zaměřené na ISO 20000..........................................................51 4.2.2 Metodika v Inekon Systems s.r.o...................................................................................55 Analýzy .....................................................................................................................................56 Cíle a přínosy projektu...........................................................................................................56 Organizační a odpovědnostní struktura..................................................................................56 Zájmové skupiny a jejich předpokládané role v projektu ......................................................57
-5-
Zralost managementu služeb..................................................................................................57 Komunikační strategie................................................................................................................63 Opatření komunikační strategie..................................................................................................63 Zveřejňování dokumentů.......................................................................................................63 Změny projektu a příslušných dokumentů............................................................................64 Veřejná diskuse......................................................................................................................64 Politika a plán Managementu služeb.........................................................................................64 Procesy ......................................................................................................................................64 Definování politiky................................................................................................................64 Etapy......................................................................................................................................65 Návrh procesu........................................................................................................................65 Nástroje......................................................................................................................................67 4.3 Závěr.....................................................................................................................................67 5 Řízení informatických procesů v MSP.........................................................................................69 5.1 Charakteristika malých podniků............................................................................................69 5.1.1 Organizační struktura.....................................................................................................70 5.1.2 Management...................................................................................................................71 5.1.3 Strategické řízení...........................................................................................................72 5.2 ITIL pro malé podniky..........................................................................................................72 5.3 ISO 20000 pro malé podniky................................................................................................73 5.4 Cíle implementace ISO 20000...............................................................................................74 5.5 Závěr.....................................................................................................................................75 6 Závěr............................................................................................................................................76 7 Přílohy..........................................................................................................................................78 7.1 Použitá literatura...................................................................................................................78 7.2 Terminologický slovník........................................................................................................81 7.3 Auditované dokumenty při certifikaci podle ISO 20000 .....................................................82 7.4 Požadavky na odbornou způsobilost pro konzultanta a auditora normy ISO 20000..............84 7.5 Hodnocení efektivnosti investic do ICT a jejich přínosu podnikatelským aktivitám dle COBIT........................................................................................................................................85
-6-
1
Úvod
Asi každý, kdo se někdy podílel na vývoji nějaké aplikace, informačního systému nebo řešil jiné problémy spojené s informačními technologiemi, si položil otázku, proč je to tak složité? I mnozí uživatelé jistě zažili okamžiky, kdy nedokázali „přesvědčit počítač, aby dělal“, to co chtějí. Proč je nejběžnější radou uživateli, aby vypnul a znovu zapnul počítač nebo program? Proč po několikaměsíční práci dokáže „shodit“ celou aplikaci středník místo čárky ve vstupních datech? Proč je možné, že výstupem z BI1 aplikace je prodej triček za období měřen v litrech a přitom to není chyba? V podobných otázkách by se dalo pokračovat, ale je možné na ně jednoduše a věcně odpovědět? Pravděpodobně ne, protože v takovém případě by již takové otázky nikdo nekladl, a tyto problémy by byly vyřešeny. Odpovědi, které existují jsou spíše filosofického charakteru a problémy je jimi možno popsat nikoli vyřešit. Několik takových odpovědí si zde dovolím nastínit. Nekladu si samozřejmě za cíl v této práci vyřešit všechny problémy informatiky, ani se plést do práce filosofům, jen bych chtěl uvést pár myšlenek, ke kterým jsem během svého studia informatiky dospěl a pro které na jiném místě této práce není místo. Tak tedy zaprvé: Informační technologie jsou o komunikaci, to jistě není překvapivé zjištění, ale někdy v zápalu řešení problémů, nám tato souvislost může uniknout. Jsou o komunikaci mezi lidmi. To jistě také není překvapující nicméně, myslím, že to je jedna z hlavních příčin výše zmíněných problémů. Mezilidská komunikace sama o sobě není jednoduchou záležitostí. Lidé si mohou nerozumět z mnoha důvodů. Z těch objektivních je to především jazyk a to hned v několika rovinách. Tou nejzjevnější jsou národní jazyky, kdy cizincům nerozumíme i když hovoří o nám jinak známých věcech, protože neovládáme jejich jazyk. Další rovinou je výklad významu slov. Mnohdy může dojít k omylu mezi stejným jazykem hovořícími osobami, protože jeden použil obecně známé slovo v jiném nebo posunutém významu. Poslední rovinou, kterou zmíním, i když by se jich samozřejmě dalo najít mnoho, jsou osobní vztahy mezi komunikujícími. Jak jsem napsal, informační technologie zprostředkovávají komunikaci mezi lidmi, to znamená, že ke všem
výše popsaným problémům musíme přiřadit ještě prostředníka a to ne jednoho a
komunikující nejsou dva, ale desítky, stovky. Asi nemusím dále pokračovat, protože představa stovek komunikujících lidí přes stejný počet prostředníků, z nichž mnozí jsou schopni zprostředkovat komunikaci pouze určitého druhu asi vyvolá pocit chaosu v každém. Za druhé: Problém technologický. Vyjádřeno ve zkratce, ICT jsou založeny na dvojkové soustavě, zatímco život lidí není černobílý. 1
Business intelligence
-7-
Tolik tedy moje úvahy. Nyní je namístě vysvětlit, jak to souvisí s tématem této práce, jež se zabývá metodikami řízením informatických služeb. Jsou to tedy tyto metodiky, jež hrají stěžejní roli při řízení komunikace v organizaci. Dodávání požadovaných výstupů za daných podmínek je úkolem řízení všech ekonomických aktivit. ICT a informatika jsou relativně mladé. Informatika se stupněm šíří poznání může jen těžko srovnávat s takovými disciplinami jako je medicína, matematika či fyzika. Podobně je na tom ICT průmysl ve srovnání např. se strojírenstvím nebo zemědělstvím. Naopak stupeň zasažení společnosti, kdy prakticky všechny obory lidské činnosti jsou ICT více či méně dotčeny, je s ostatními odvětvími plně srovnatelný či dokonce vyšší. Ostatní obory měli dostatek času vyvinout teoretické i praktické znalosti svého řízení, zatímco první teoretické poznatky o řízení ICT se datují do konce 70. let minulého století. Zatímco ve většině odvětví existuje mnoho teoretických2 poznatků o jejich řízení na všech úrovních, v ICT se nacházíme ve fázi, kdy s teprve začínají masově implementovat specifické oborové metodiky vyšších úrovních řízení. A právě tyto metodiky by měli přinést stabilitu pro dodávky informačních služeb, protože správným řízením úspěch začíná. Na tomto místě je ke zvážení, zda jsou specifické znalosti řízení ICT potřebné a zda by si řízení nevystačilo se standardním managementem. Zvláště pak v situaci, kdy existují názory, že ICT už ničím výjimečné3 nejsou a proto si zvláštní pozornost nezaslouží. Je to samozřejmě subjektivní názor, když uvedu, že ICT výjimečné jsou a to především proto, že se musí vypořádávat s problémy mezilidské komunikace. Hlavními normami, jimiž se práce zabývá jsou ITIL (V2, V3) a ISO/IEC 20000 především kvůli své propojenosti a protože mají největší dopad do praktické části. Věřím, že práce poskytne vodítko, jak se v těchto normách a jejich vzájemných vztazích orientovat a také ozřejmí hlavní problémy a oblasti, jimž je třeba věnovat pozornost při praktické aplikaci norem nejen v segmentu MSP. V zásadě je práce rozdělena na teoretickou a praktickou část, i když se tyto oblasti na několika místech protínají. Hlavním cílem práce je vyplnit mezeru mezi obecným zněním normy ISO 20000 a detailním plánem její implementace. Proto je v teoretické části práce nejdříve vymezen účel metodik řízení informatických procesů (kap.2). Následně je v kapitole 3
proveden rozbor
nejdůležitějších metodik a jejich vzájemných vztahů. Kapitola 4 popisuje zkušenosti z projektu implementace ISO 20000, jež ztělesňuje především vytvořená konkrétní metodika implementace ve firmě Inekon Systems s.r.o. V kapitole 5 jsou pak na základě poznatků z předchozích částí a popisu specifik MSP provedeny obecné závěry o vhodnosti ITIL a ISO 20000 pro tento segment podniků.
2
Např. u výroby od pásové přes Kanban, JIT po TOC Carr, N., G. IT Doesn't Matter. Harvard Business Review, May 1, 2003. Plný text na http://www.roughtype.com/archives/2007/01/it_doesnt_matte.php 3
-8-
2
Význam a užití metodik
Tato kapitola objasňuje význam metodik a jejich místo v řízení organizace. Postupuje od obecné definice pojmu metodika přes význam a shrnutí ekonomických efektů informatiky pro podnik po zařazení metodik řízení informatických procesů do obecného rámce řízení informatiky v podniku (IT Governance). Diskutovány jsou taktéž efekty standardizace řízení, ke kterému používání obecných metodik vede.
2.1
Základní pojmy
Na tomto místě jsou definovány základní pojmy a jejich vztahy, jež jsou v práci používány. Pozornost je také věnována názvosloví, které dosud v této oblasti není zcela ustálené.
2.1.1
Metodika
[VOR97]:“Metodika je explicitní způsob strukturování myšlení a konání. Metodika obsahuje model, který reflektuje zvolené pohledy na realitu a který vychází z množiny filosofických paradigmat. Metodika musí říkat, jaké kroky a jak vykonat, ale nejdůležitější je, aby řekla, proč mají být vykonány právě v daném pořadí.“ Metodiky zkoumané v této práci této definici v zásadě vyhovují. Jejich porovnání je ovšem poměrně problematické, neboť nelze použít (nebo spíše to nemá smysl) kvantitativní porovnání např. počet stran, počet procesů, jež norma definuje apod., neboť vypovídací schopnost takových hodnot by byla velice malá. Je třeba se zaměřit především na kvalitativní hodnocení jako je přizpůsobitelnost, srozumitelnost a především do jaké míry jsou schopny naplňovat cíle, pro které byly vytvořeny. Tyto cíle určuje IT Governance.
2.1.2
IT Governance
Úkolem IT Governance je řídit aktivity ICT v rámci organizace tak, aby byly zajištěny následující cíle: •
Propojení a sjednocení business a ICT strategie v rámci společnosti tak, aby byly oboustranně splněny předem definované požadavky a očekávání (tj. odvození IT strategie z jednotlivých cílů definovaných v business strategii)
•
Maximální a řízené využití příležitostí, které ICT businessu nabízí
•
Zodpovědné využívání ICT zdrojů
•
Řízení rizik spojených s vývojem / pořízením / provozováním ICT
Definice IT Governance4: 4
Zdroj: http://www.itil.cz/index.php?id=917 -9-
ISACA: IT Governance je definovaná struktura vztahů a procesů, pomocí kterých lze řídit a kontrolovat organizaci tak, aby ICT v maximální míře umožňovalo a podporovalo dosažení podnikatelských cílů. Přidanou hodnotou je redukce a řízení rizik nad procesy v IS. IT Governance ovlivňuje zvýšení efektivity organizace pomocí: •
Zajištění a zabezpečení integrity, bezpečnosti a spolehlivosti strategických a jiných citlivých informací.
•
Ochrany investic do ICT a komunikací
•
Nastavení odpovídajícího vedení a řízení informačních aktiv, na nichž přímo závisí úspěch nebo přežití organizace
•
Zvyšování hodnoty podnikatelských procesů pomocí ICT (vazba ICT na podnikatelské procesy)
ITIL: IT Governance se zabývá kooperací businessu a ICT managementu. Tato kooperace je stěžejní pro podnikové cíle a procesy, které jsou závislé na správném fungování ICT. Oblasti zájmu IT Governance •
Sjednocení strategií (podniková versus ICT strategie)
•
Řízení změn (change management)
•
Business Continuity
•
ICT Asset Management
•
Řízení zdrojů
•
Řízení znalost
Hlavním akcentem IT governance5 je sladění strategie informatiky se strategií podniku ( Business IT alingement). Je to oblast, která zahrnuje řízení informatických procesů a tedy na ní mají metodiky, o kterých je tato práce, značný vliv. Jednou z nejstarších metodik je ITIL (viz kap. 3.2), dále COBIT (viz kap.3.1), a v poslední době ISO 20000 (viz kap. 3.3),. Tyto metodiky, ačkoli se zabývají stejným předmětem, mají velmi rozdílnou náplň a každá z nich se hodí pro jiné případy. Dají se ovšem vhodně kombinovat a z teoretického hlediska by mohli být používány všechny tři najednou, ovšem z praktického hlediska by to již asi bylo příliš mnoho best practice a standardů nejednou. BEST PRACTICE Volně přeloženo nejlepší zkušenosti. Jedná se praktické prvky, které jsou obsaženy nejen ve zde probíraných metodikách, ale i v aplikačním softwaru apod. V metodikách řízení informatických 5
Je to jeden z pojmů s těžkým překladem, neboť vláda, vládnutí se moc nehodí do českého podnikového názvosloví a řízení má užší význam.
- 10 -
procesů jsou velmi zobecněny. To znamená, že v normách nenajdeme konkrétní podoby procesů či popisy činností, ale návody a doporučení jak s procesy zacházet, kde si dát pozor na jejich rozhraní a k jakým účelům je používat. Obsah procesů, tedy konkrétní činnosti a pracovní postupy si musí každá organizace určit sama. V metodikách je tedy obsaženo best practice, jak zacházet s best practice.
2.2
Názvosloví
V práci je používáno hlavně anglické názvosloví, důvod je především ten, že bylo čerpáno především z anglicky psané literatury. Obsah a význam většiny pojmů v této oblasti není ujasněn ani v Anglickém jazyce a proto jsem nechtěl tuto nejistotu ještě zvyšovat používáním českého názvosloví, které taktéž není ustálené a i norma ISO 20000 vyšla z těchto důvodů v dvojjazyčné verzi.
2.3
Ekonomické efekty ICT v organizaci
Protože implementace některé z metodik řízení informatických procesů přináší nemalé náklady, je třeba nejprve posoudit, jak velký ekonomický význam má informatika pro organizaci a zda jsme schopni jej měřit. Vliv ICT na náklady ICT ovlivňuje náklady (stejně jako mnoho dalších investic) dvěma způsoby, jednak je to zvyšování nákladů pořizováním infrastruktury a SW a za další mnoho těchto investic by mělo vést přes zefektivnění výroby a rozhodování k úspoře nákladů. Tyto úspory se většinou objevují v jiných oblastech, které jsou technologiemi podporovány, než ve vlastním ICT. Hodnocení úspor může probíhat relativně jednoduše. Pokud máme v projektu stanoveny cíle, které vedou k úsporám a popsány metody měření, lze úspěšnost projektu snadno vyhodnotit. Potřebná data by měla být získána z účetnictví nebo podobné dokumentace a základním porovnáním, zda se ušetřilo více prostředků než se na úsporu vynaložilo, můžeme rozhodnout o úspěšnosti projektu. Stejným způsobem lze hodnotit projekty věnované úsporám v rámci samotného ICT. Vliv ICT na tržby Tržby jsou nejdůležitějším faktorem při dosahování zisku. Pokusme se nyní podívat na to, jak mohou ICT podpořit zvyšování tržeb. Zde se ovšem dostaneme k problému, že pokud se nejedná o firmu, která poskytuje produkt spojený s ICT, je obtížné vyjádřit přímý vztah mezi ICT projektem a změnou tržeb. Základní úvaha je taková, že podnik dosahuje změny tržeb díky změnám parametrů svého produktu. Primárním činitelem je tedy změna vlastního produktu případně s ním spojených služeb vycházející z marketingových plánů. Zde je třeba se zaměřit na vliv ICT při pozitivní změně parametrů produktu. Tím se oproti nákladům poněkud komplikuje situace, protože úspěch produktu závisí nejen na vlastnostech, jež definuje podnik, ale zejména na reakci trhu. Je tedy třeba zabývat se zejména otázkou, jak ICT může nebo podporuje změny produktu, které by - 11 -
ovšem měly vycházet z podnikového marketingového plánu. Největší komplikací tohoto mezičlánku je dopad na způsob měření vlastního přínosu ICT ke změně produktu. Nejen, že se jedná spíše o kvalitativní ukazatel, ale navíc i jeho ocenění probíhá spíše na vnitropodnikové bázi a přepočítání z tržní ceny může zkreslit výsledky. Podrobně jsou problémy spojené s měřením ICT podle standardních ekonomických ukazatelů (ROI, EVA) diskutovány v literatuře [MOL00]. Role metodik v měření informatiky Jednou z možností, jak se ujistit, že podniková informatika je provozována efektivně, je používání metodik jako jsou ISO 20000, ITIL a COBIT. Metodiky obsahují best practice, proto lze předpokládat, že firma, která jich bude užívat, bude mít daleko větší šanci provozovat svoje IS/ICT efektivněji a spolehlivěji než by to bylo bez nich. Proto jedním ze způsobů měření efektů informatiky může být nepřímá metoda měření shody s těmito standardy. A sice, předpokládáme-li, že jsou to skutečně nejlepší způsoby zacházení s ICT, lze se domnívat, že pokud, se takto budeme chovat, bude nám ICT přinášet i největší možné užitky. Neměříme tedy přímo užitky informatiky, ale způsob, jakým ji provozujeme, z čehož se pak dá usuzovat, jaké nám přináší prospěchy, nebo přinejmenším zjistit, zda jsou naše postupy v pořádku. Výhodou tohoto přístupu, je zejména ten fakt, že pro tyto standardy jsou k dispozici komplexní metriky jejich sledování v podobě auditních postupů – Zejména COBIT a ISO ( ITIL sám o sobě tyto postupy neobsahuje, ale na ITIL je nyní založeno ISO 20000, které již metody pro implementaci a audit obsahuje. Příloha 7.5 obsahuje postup měření přínosů podnikové informatiky sestavený dle metodiky COBIT.
2.4
Standardizace
Zavádění jakýchkoli cizích standardů do podniku znamená příležitost zlepšit stav procesů o best practice z oboru, ale zároveň to znamená určité omezení a nebezpečí, že firma přijde o své specifické výhody, pokud používá vlastní know-how. Zde prezentované metodiky jsou rozšířené a jsou de – facto standardy. Proto znamenají potenciální nebezpečí, že organizace nahradí svoje specifické postupy činnostmi, které již používá konkurence a přijde tak o část své přidané hodnoty. Taktéž je zřejmé, že používání standardů klade určité omezení schopnosti ICT rychle měnit svoje služby, protože minimálně musí požadavek projít formálním schválením o shodě s definovanými procesy. Pokud by ve shodě nebyl, bude z toho dlouhé a nákladné řízení, takže je možné, že i dobrý a inovativní požadavek bude zamítnut. Na druhé straně ovšem zůstane zachována integrita systémů a služeb a zmírní se riziko neuváženého zásahu. Normy nepředepisují konkrétní znění vnitrofiremního předpisu, ale kladou požadavky na strategické cíle celého řízení podnikové informatiky i jednotlivých řídících procesů, čímž určité mantinely stanovují. Znamenají tyto mantinely, že všichni v daném prostředí dojdou ke stejným strategickým cílům svých procesů a činností? Pravděpodobně ne, ale velmi to záleží na způsobu implementace metodiky. Vlastní splnění normy znamená pouze existenci určitého rámce, do - 12 -
kterého se zasazují činnosti a zkušenosti organizace. Ovšem v situaci, kdy firma používá k implementaci konzultační firmu, která má připraveno oborové řešení, je zde nebezpečí přijetí cizích způsobů práce. Logicky vzato, pakliže by všichni používali stejnou konzultační firmu, budou mít asi dosti podobné procesy. To je v reálu samozřejmě nesmysl, nicméně k určitému omezení intervalu řešení patrně dochází.
2.5
Závěr
Z uvedeného vyplývá, že vznikají dva protichůdné tlaky, jednak přizpůsobivost organizace měnícím se podmínkám trhu a rychlé zavádění inovací a na druhé straně standardizace a zachování spolehlivosti ICT. Pokud to tedy shrneme existují dva silné faktory, které souvisí s vlivem podnikového ICT na konkurenceschopnost firmy. Je to postavení ICT v rámci inovací a konkurenceschopnosti podniku a je to také způsob přijímání standardů řízení. Pokud konkurenční výhoda podniku není na možnostech ICT postavena, nemá její „standardizace“ výrazný negativní dopad a spíše může znamenat větší spolehlivost dodávek služeb.
- 13 -
3
Přehled Metodik
V této kapitole je uveden metodik řízení informatických procesů, které mají nevětší dopad na celou práci. Jsou jimi ITIL a ISO 20000. V rámci popisu ITIL jsou uvedeny hlavní cíle a náplně řídících procesů, které jsou shodné pro obě metodiky. Text se věnuje i rozdílům obou norem a jejich vzájemnému vztahu. Doporučení pro implementaci jednotlivých metodik je obsaženo v kapitole 5.3 a 5.4. V následující kapitole je stručná charakteristika metodiky COBIT, jež je vhodná především pro kontrolu a audit podnikové informatiky.
3.1
COBIT
COBIT (Control Objectives for Inforamtion and related Technology) je metodika
vhodná
především pro kontrolu a audit podnikové informatiky. Poskytuje návod jak propojit ICT procesy, zdroje a informace se strategickými cíli organizace. Výstupy z auditů a kontrol provedených podle této metodiky jsou určeny především nevyšším manažerům a poskytují jim obraz o stavu informatiky v podniku. Představu komplexnosti COBIT si lze udělat na základě přílohy 7.5, kde je posán postup auditu efektivnosti podnikové informatiky. Metodika se skládá ze 34 procesů rozdělených do 4 domén podle zaměření: Plan and organize Acquire and implement Deliver and support Monitor Text COBIT je tvořen sadou dokumentů jež je možné používat současně nebo i odděleně podle potřeb uživatele ( manažer, auditor, specialista). Jsou jimi: Executive Summary – manažerský souhrn – stručný souhrn základních konceptů a klíčových prvků metodiky Cobit Framework – rámec metodiky – vysvětluje informační vazby mezi procesy ICT a podnikovými procesy. Vazby jsou řízeny a hodnoceny obecnými kontrolními cíly (high level objectives), informačními kritérii a využíváním ICT zdrojů Management Guidelines – směrnice pro řízení – obsahují model zralosti, klíčové faktory úspěšnosti (CSF), výsledkové (KGI) a výkonnostní metriky (KPI), jež jsou definovány pro každý kontrolní cíl.
- 14 -
Detailed Kontrol Objectives – detailní kontrolní cíle- obsahuje definice požadovaných výsledků, kterých je možno dosáhnout implementací 318 specifických a detailních kontrolních cílů. Audit Guidelines – směrnice pro audit- definuje postupy a činnosti auditu a zmiňuje rizika, která hrozí při nedosažení odpovídajícího kontrolního cíle. Implementation Tool Set – sada nástrojů pro implementaci – obsahuje nástroje a návody pro diagnostiku kritických oblastí řízení ICT a případové studie provedených implementací.
3.2
ITIL- Information technology infrastructure library
Minimálně v Evropě nejznámějším standardem ITSM je ITIL, který je vyvíjen OGC 6 od 80.let minulého století. Původním cílem bylo sjednotit požadavky státních zakázek na ICT a IS. Postupně se tento model vyvíjel a dostával se i do soukromých společností. Věcně se jedná o rámec pro best practice procesy, jejichž náplní mohou být i stávající činnosti v oblasti service managementu. První verze byly publikovány CCTA7 pod zkratkou GITMM8 a rozrostla se až na 31 knih. Od poloviny 90. let je ITIL světovým de- facto standardem v oblasti service managementu. Jeho rozšíření napomohlo především používání běžného jazyka pro definici požadavků i postupů v jednotlivých procesech, což umožnilo porozumět této problematice i lidem mimo ICT oblast. Zároveň to odpovídá posunu orientace řízení ICT oddělení od technologických cílů k obchodním. Poskytování služby 9zákazníkům ať již interním čí externím se stává hlavním posláním.
3.2.1
ITIL V2
Tato verze byla publikována mezi lety 2000 – 2004. Nahradila výše zmíněnou rozsáhlou knihovnu 7 propojenými a více konsolidovanými knihami, které tvoří celkový rámec pro best praktice. V následujících řádcích jsou tyto publikace stručně charakterizovány. Asi nejdůležitější z nich jsou Service Delivery a Service Support v nichž jsou obsaženy nejdůležitější procesy10, které se staly základem pro mezinárodní normu ISO 20000. Vzhledem k procesnímu modelu, je samozřejmé, že jednotlivé oblasti nejsou oddělené a procesy spolu komunikují a navazují na sebe. Protože jsou pokryty prakticky všechny procesy dodávání služeb, vzniká mezi nimi řada spojení a rozhraní, některá jsou zjevná z obrázku.
6
Office of Govement Commerce UK Government's Central Computer and Telecommunications Agency 8 Government Information Technology Infrastructure Management Methodology 9 Slovem zákazník je v této kapitole nahrazen anglický termín business. Zákazník představuje odběratele služeb a může to být entita mimo firmu nebo i uvnitř organizace. 10 Procesy jsou stručně charakterizovány v kapitole pojednávající o ITIL V3. 7
- 15 -
Obrázek 1: Propojení oblastí ITIL [RUD04] The business perspective Je určena pro pracovníky ICT oddělení, aby jim pomohla rozumět, jakým způsobem mohou přispět k plnění obchodních cílů organizace. Zároveň je vede k poznání, jak mají být jejich role a služby lépe napojeny na tyto cíle, aby maximalizovali svůj přínos. Obsahuje procesy: •
Business Relationship management
•
Parterships and outsourcing
•
Continuous improvement
•
Exploitation of information
•
Communication and technology for business advanatage
Planning to implement service management
- 16 -
Popisuje akce a úkoly důležité v v rámci plánování, implementace a zlepšování procesu řízení služeb. Zaměřuje se na řešení organizačních a kulturních změn v podniku, stanovení vize a strategie. V jednotlivých kapitolách jsou popsány metody popisu aktuálního i budoucího stavu a postupy, jak překlenout vzniklou mezeru. Obecně lze říci, že ke každé problematice je vytvořen postup hodnocení aktuálního stavu, který většinou využívá některé ze známých koncepcí, jako je zralost procesu apod. Již v prvních kapitolách této a zároveň i v ostatních knihách je doporučení pojímat implementaci procesů podle ITIL jako projekt a zvolit i vhodnou projektovou metodiku jako je PRINCE2. Nejen v tomto svazku je ovšem řada upozornění, že implementace není pouze projekt a má širší dopady. Application management Popisuje, jak řídit aplikace od zjištění zákaznické potřeby přes všechny stádia životního cyklu aplikace až po její zrušení. Klade důraz na to, aby ICT projekty byli úzce spjaty s těmi obchodními během celého životního cyklu aplikace, aby tak bylo zajištěni, že zákazník dostává nevjyšší přínos ze své investice. Service delivery Pokrývá procesy důležité pro plánování a poskytování kvalitních ICT služeb s ohledem na dlouhodobé zlepšování dodávaných služeb. Obsahuje procesy: •
Availability management
•
Capacity management
•
Service level management
•
IT service kontinuity management
•
Financial management for IT services
Service support Popisuje procesy spojené s každodenní podporou a údržbou aktivit spojených s poskytováním ICT služeb. Obsahuje procesy: •
Service Desk
•
Incident management
•
Problem management
•
Change management
•
Release management
- 17 -
•
Configuration management
ICT infrastructure management Pokrývá všechny aspekty řízení infrastruktury od identifikace zákaznických požadavků přes výběrové řízení, testování, instalaci až po nasazení, používání a optimalizaci ICT komponent a ICT služeb. Security management Detailně popisuje proces plánování a řízení zvolené úrovně bezpečnosti informací a ICT služeb včetně všech aspektů spojených s reakcí na bezpečnostní incidenty. Obsahuje také
postup
hodnocení a řízení rizik, zranitelností a implementaci nákladově orientovaných metrik.
3.2.1.1 Certifikace ITIL V2 Existují tři druhy certifikátů ITIL, všechny se vztahují na osobu držitele a samotné procesy v organizaci, jak je tomu např. u norem ISO, certifikovat nelze. Získáním certifikátu držitel potvrzuje znalost definované oblasti ITIL popřípadě zkušenosti s jeho využíváním. Foundation Certificate In IT Service Management Tento certifikát potvrzuje, že držitel rozumí základním principům ITIL – terminologii a funkci Service Desk, deseti klíčovým procesům a jejich vazbám a rozhraním na ostatní procesy. Pro získání je třeba dosáhnout 65 procent bodů u zkoušky. Practicioner Certificate In IT Service Management Pro získání certifikátu je třeba prokázat hluboké porozumění ITIL procesům. Je dostupný pro každý proces. Podmínkou pro získání certifikátu jsou 3 – 4 roky ve funkci vedoucího ICT oddělení a Foundation Certificate In IT Service Management. Manager’s Certificate In IT Service Management Dokazuje, že držitel má znalosti ze všech knih. Další podmínky jsou shodné s předchozím certifikátem.
3.2.1.2 Implementace ITIL V2 Po stručném shrnutí jedné z nejvýznamnějších ITSM metodik a popisu cílů hlavních ITSM procesů se nyní budu věnovat postupu implementace těchto procesů.
- 18 -
Přestože hlavním tématem této práce je implementace standardu ISO 20000 je na tomto místě popsána metodika firmy BT[5], která v zásadě odpovídá požadavkům obsaženým v PISM11, které budou detailně rozebrány v praktické části této práce. Procesní analýza Prvním krokem implementace je popis procesů. Protože ITIL neobsahuje detailní procesy (kromě Change Management), je možno postupovat dvěma způsoby. Popsat procesy v organizaci a následně je upravovat podle kritérií obsažených v normě a to bez pomoci externí poradenské firmy. Výhodou tohoto postupu je, že výsledné procesy budou přesně odpovídat požadavkům a možnostem organizace. Existuje ale velké nebezpečí zafixování chybných postupů, které by mohl externista rozpoznat, případně poradit, jak tuto problematiku řešit. Problémy jsou především v zatížení vlastních zdrojů a nutnost mít v organizaci odborníka na procesní analýzu a ITIL. Druhý způsob spočívá ve spolupráci s konzultační firmou, která má připraveny standardní návrhy procesů a v rámci implementace se bude jednat pouze o jejich úpravu pro danou organizaci. Výhodou je menší zatížení vnitřních zdrojů a především odpadá nutnost mít zaměstnance s požadovanými znalostmi, kteří jsou velmi drazí. Nevýhodou může být použití procesů, které nejsou organizaci vlastní a nehodí se pro ni. Při volbě konkrétního postupu, je třeba zvážit, nakolik jsou procesy v organizaci efektivní a dobré. V případě, že chceme implementací docílit i zásadních změn postupů, je vhodnější využít pomoci konzultační firmy, která může snadněji rozpoznat chyby, kterých si nejsme vědomi. Analýza rozdílů V tomto kroku se zjišťují rozdíly mezi procesy vzniklými v kroku předchozím a skutečným stavem. Tyto rozdíly se stanou podkladem pro projekt implementace. Informace pro tuto analýzu musí být dodány autory návrhů procesů, kteří již mají přehled o problematice. Rozdíly se mohou objevit v mnoha oblastech jako jsou vlastní procesy (návrh a shoda), lidé( znalosti, schopnosti, role, počet a organizace), technologie (nástroje, systémy a vybavení), ve službách třetích stran nebo v jejich kombinaci. V tomto kroku jde především o identifikaci a popsání rozdílů než o návrhy řešení. Příklady rozdílů zjištěných v Incident Management :
11
•
Incidenty nejsou centrálně evidované v jednom systému
•
Není jasně definovaná role a vazba Service Desk na incident Management
•
Incidenty se nehodnotí konzistentním způsobem
•
Není vhodný reporting incidentů
•
Nejsou vyjasněna rozhraní na ostatní procesy
Planning to implement Service Management
- 19 -
Plánování Před vytvořením vlastního plánu je třeba podniknout tyto kroky: •
Přiřadit priority rozdílům
•
Identifikovat činnosti, které povedou k řešení
•
Vytvořit posloupnost činností
•
Vytvořit plánu
Přiřazení priorit Smysl této činnosti je především ve vhodném seřazení nejdůležitějších rozdílů a následném čerpání zdrojů pro jejich řešení a dosažení rychlých přínosů, což podpoří projekt. Postupné probíhání změn by nemělo ohrozit úroveň právě dodávaných služeb. Identifikace činností, které povedou k řešení Podle přiřazených priorit se hledají činnosti a cesty vedoucí k požadovanému stavu. Některá řešení mohou vyžadovat úspěšné vyřešení ostatních rozdílů či se jedno řešení může vázat k více rozdílům. Ačkoli ITIL má vést ke zlepšení poskytování služeb jako celku, je třeba se zabývat jednotlivými částmi procesu. Úspěšný provoz procesu závisí zejména na •
Rolích a činnostech
•
Službách třetích stran
•
Nástrojích a systémech používaných k podpoře IT Service Management
Vytvoření posloupnosti činností Účelem je vytvořit přehled činností a způsobu, jakým bude implementace provedena. To je velmi důležité pro komunikaci s vedením a s ostatními, jichž se implementace bude dotýkat. Přehled by měl zahrnovat všechny činnosti, jejich klasifikaci a cíle, kterých mají dosáhnout. Podle rozsahu projektu by se měly vytvořit tři časové úseky do nichž by byly činnosti zahrnuty podle svých priorit nebo podle složitosti.
Vytvoření plánu Plán rozpracovává posloupnosti činností jednotlivých časových úseků definovaných v předchozím kroku. Detailně popisuje, co je třeba udělat a s jakými zdroji nebo dalšími omezeními je třeba počítat.
- 20 -
Realizace a měření Ještě před zahájením vlastní implementace je třeba stanovit a nastavit metriky představující Key Performance Indicators (KPI), které budou použity k měření efektů projektu Implementace ITIL. KPI mohou pomoci stanovit, zda proces probíhá podle požadavků a jestli produkuje předpokládané výstupy nebo výsledky. KPI by měly pomoci rozpoznat potřebu korekce procesu dříve než zkolabuje. Zavedení řízení služeb Posledním krokem projektu je zavedení struktury řízení IT Service Management procesů, jejímž cílem je zajistit, aby procesy byly řízeny v souladu s požadavky zákazníků a efektivně využívaly zdrojů. IT Governance se nevztahuje pouze na Service Management, ale také na vývoj aplikací a zavádění nových aktivit souvisejících s ICT. Zatímco ITIL procesy poskytují strukturovaný rámec pro kontrolu dodávání služeb, IT Governance poskytuje rámec pro řízení a neustálý vývoj, zavádění a zlepšování těchto procesů, tak aby bylo dosaženo cílů organizace. Vztah mezi IT Governance a IT Service Management je znázorněn na následujícím obrázku
Obrázek 2: Vztah IT Governance a ITSM [LIT08] Jak ITIL pomáhá dosahovat firemních cílů? Bez jasného a přesvědčujícího zodpovězení této otázky bude hodnocení projektu implementace ITIL velmi obtížné. Projekt by měl vést nejen ke zvýšení výkonnosti ICT oddělení. - 21 -
IT Service Management by měl směřovat k: •
Maximalizaci hodnoty dodávané IT službami za použití metrik schválených zákazníkem
•
Efektivnímu řízení ICT rizik
•
Maximalizaci shody mezi strategií dodávky služeb a obchodní strategií
Řídící rámec by proto měl definovat metriky podporující plnění těchto cílů a způsoby jejich měření.
3.2.2
ITIL V3
Tato verze nahrazuje předchozí verzi 5 knihami pokrývajících životní cyklus služeb od definice a analýzy zákaznických požadavků v rámci Service Strategy a Service Design, přes implementaci v rámci přeměny služby do běžného užívání a provozu až po neustálé zlepšování. Nová verze nepředstavuje revoluční změnu, ale jedná se o uspořádávání a posun procesů od zaměření na vlastní efektivitu k zaměření na plnění požadavků zákazníků. Většina procesů z verze 2 zůstává platných nebo se pozměnila. Hlavními přírůstky oproti V2 jsou tedy strategie (Service Strategy) a návrh dodávky služeb (Service Design). V2 se soustředila na součásti procesů dodávky a podpory služeb a zaostávala v otázkách podpory strategie návrhu a sledování kvality dodávky služeb. Následující obrázek znázorňuje změny v uspořádání.
Obrázek 3: Změny v uspořádání procesů V2 a V3 [BRO08]
- 22 -
Další obrázek shrnuje nově definované procesy a jejich uspořádání v jednotlivých knihách ITIL V3.
Obrázek 4: Nové procesy [BRO08] Podle [6] je třeba zmínit, že implementace V3 vyžaduje mnohem větší počáteční vyspělost procesů, protože důraz je kladen především na soulad dodávky služeb a zákaznických požadavků. V podstatě by se dalo říci, že vývoj tohoto pojetí se ubírá od V2 přes ISO20000 k V3. Tím pádem V3 není pro všechny firmy. Je vhodná zejména tam, kde samotné procesy jsou na dostatečné úrovni zralosti a je třeba služby dále rozvíjet směrem k větší podpoře obchodní strategie. Pokud tedy IT služby nejsou hlavním hybatelem obchodu, může podnik zůstat u V2 popřípadě u certifikace ISO 20000. V3 tedy není náhradou za V2, nýbrž ji rozvíjí směrem větší podpoře obchodu. Jelikož ITIL procesy jako takové nelze certifikovat, není potřeba plnit všechny požadavky normy a podnik si tak může vybrat určité oblasti, které chce zlepšit nebo používat V3 jako měřítko svých služeb, aniž by normu implementoval. Z hlediska teorie a seznamování se s problematikou ITSM životní cyklus více přibližuje procesy reálnému podnikání a objasňuje jejich místo v řízení společnosti. Pokud totiž firma nevyužívá - 23 -
procesní řízení před implementací norem, je velmi obtížné převést teorii a doporučení do praxe, protože se jedná o dvě zásadní změny najednou. Jednak uvědomění si, že proces a s ním i jeho řízení a odpovědnost za něj prochází celým podnikem a nekončí a nezačíná v jednom oddělení jako dosud. Za druhé vlastní činnosti procesu, které se dosud neprováděly, nebo se prováděly odlišným způsobem bez návaznosti na další činnosti a monitoring. Začleněním procesů do vyššího celku, který představuje životní cyklus služby neznamená, že by se měnila jejich podstata procházení celou firmou, ale přibližuje to jejich vnímání funkčně řízené organizaci, kdy si vedoucí a členové jednotlivých oddělení dokážou lépe představit své místo v procesu a návaznost na okolí. Zároveň to nepožaduje hned od začátku razantní změnu přístupu od funkčního myšlení v procesní. Ovšem, jak bylo zmíněno výše pro praktickou implementaci je vhodné využít všech tří relevantních metodik.
Obrázek 5: Životní cyklus služby [CAR04]
3.2.2.1 Service strategy Strategie služeb je zde vnímána přes uspokojování zákaznických potřeb nikoliv jako produkování výsledného výstupu. Orientace je zaměřena především na porozumění zákazníkovy v co nejširším kontextu trhu, aby bylo docíleno dodávání co nejvyšší hodnoty. Strategie služby musí brát v potaz všechny účastníky transakce a to jak vnitřní tak vnější a stavět na dlouhodobých vztazích mezi poskytovatelem a zákazníkem. Měla by také vymezovat specifické konkurenční výhody poskytovatele, které jej odlišují od ostatních a na nichž je postaven jeho byznys. Zákazník a dodavatel by si tedy měli uvědomit a dokonale rozumět: •
Jaké služby nabízet
- 24 -
•
Komu je nabízet
•
Jak by měli být vyvinuty interní i externí trhy
•
Jaká je konkurence na těchto trzích, a jaké skutečnosti odlišují hodnotu toho, co děláme nebo jak to děláme.
•
Jak zákazníci a účastníci měří dodanou hodnotu a jak tuto hodnotu vytváříme
•
Jak se zákazníci rozhodují pro dodavatele služeb s ohledem na využívání více typů poskytovatelů
•
Jak pomocí finančního řízení dosáhnout průhlednosti a kontroly vytváření hodnot
•
Jak silné případové studie budou vytvořeny, aby zabezpečily strategické investice do servisních aktiv a schopností řízení služeb
•
Jak bude alokování zdrojů přeměněno na optimální efekty napříč spektrem služeb
•
Jak budou služby měřeny
Klíčové procesy: Finacial management Zajišťuje finanční účtování služeb,
účetnictví ICT oddělení a vyčísluje finanční hodnotu
dodávaných služeb. Patří sem také oceňování aktiv používaných k poskytování dohodnutých služeb. Service portfolio management Jedná se o neustálý proaktivní proces (nový ve V3), který řídí investice ve všech fázích životního cyklu služby. Demand Management Tento nový V3 proces se snaží nalézt rovnováhu mezi požadavky zákazníků a kapacitním zajištěním služeb. Jedná se především o odhady zákaznického chování nebo ovlivňování zákazníků výhodnějšími nabídkami služeb v době nízkého provozu.
Service design Tato část životního cyklu služby představuje především návrh vhodných a inovativních služeb včetně architektur, procesů, politik a dokumentace, tak aby odpovídaly současným i budoucím zákaznickým požadavkům. Hlavní úkoly a cíle jsou: •
Návrh služeb odpovídající zákaznickým požadavkům
- 25 -
•
Návrh procesů podporujících životní cyklus služby
•
Identifikace a řízení rizik
•
Návrh bezpečné a pružné ICT infrastruktury, prostředí, aplikačních a datových zdrojů a kapacit
•
Návrh metrik a způsobu měření
•
Vytvořit a udržovat plány, procesy, politiky standardy, architektury, frameworky a dokumenty podporující návrh kvalitních ITC řešení
•
Vyvinout schopnosti a kapacity uvnitř ICT oddělení
•
Přispívat k celkovému zlepšení kvality ICT služeb
Klíčové procesy Service Catalogue Management Jedná se o nový proces V3 zajišťující přehled o poskytovaných službách. Měl by dodávat jednotný přehledný zdroj informací o všech dodávaných službách , jejich detailech a stavech. Hlavním bodem procesu je katalog služeb, do kterého se mohou dostávat informace z ostatních procesů jako je např. Business Relationchip Management nebo Service Level Management. Service Level Management V rámci tohoto procesu jsou vyjednávány a schvalovány cíle poskytovaných služeb a způsoby reportování jejich dodávky. Hlavními výstupy procesu jsou SLA, OLA a plán zlepšování služeb (SIP) Capacity management Toto je jeden z procesů, který jde napříč celým životním cyklem služby a zabývá se službami i zdroji a jejich přizpůsobení zákaznickým požadavkům. Availability management Tento proces se zaměřuje na všechny otázky spojené s dostupností služeb, komponent a zdrojů. Zajišťuje, aby byly splněny a měřeny cíle všech oblastí a aby byly dosaženy nebo překročeny všechny zákaznické požadavky a to efektivně. Management dostupnosti by se měl zabývat dvěma druhy činností: Reaktivní činnosti: monitorování, měření, analýzy a řízení událostí, incidentů a problémů týkajících se dostupnosti.
- 26 -
Proaktivní činnosti: proaktivní plánování, návrh a doporučení pro zlepšování dostupnosti IT service continuity management Tento proces probíhající napříč životním cyklem služby má zajistit udržení odpovídajících obnovovacích aktivit IT služeb v dohodnutém čase. Podstatné je především vypracování plánů obnovení a jejich udržování v souladu s požadavky zákazníků. Information security management Bezpečnost je taktéž jednou ze součástí, která se týká firmy jako celku. V rámci tohoto procesu jsou zajišťovány tyto činnosti: •
Dostupnost a použitelnost informací v době požadavku
•
Informace jsou dodávány pouze oprávněným osobám
•
Informace jsou kompletní, přesné a jsou chráněny proti neoprávněnému zásahu
•
Obchodní transakce a výměny informací jsou důvěryhodné
Supplier management Vztahy s dodavateli mají zajistit, aby byly plněny podmínky dodávek a došlo k naplnění očekávání zákazníků. Tento nový V3 proces má zajistit, že dodavatelé naplňují podmínky smluv, přičemž jako hlavního zdroje využívá databáze dodavatelů a kontraktů.
Klíčové aktivity ve Service Design: •
Sběr a analýza zákaznických požadavků a jejich jasná dokumentace
•
Návrh a vývoj odpovídajících servisních řešení, technologií, informací a metrik
•
Vytvoření a revize všech návrhů procesů a dokumentů v rámci navrhování služeb
•
Zajištění vztahu se všemi ostatními aktivitami a rolemi návrhu a plánování
•
Vytvoření a udržování politik a návrhových dokumentů
•
Řízení rizik všech služeb a navržených procesů
•
Zajištění shody se všemi firemními a ICT strategiemi a politikami
3.2.2.2 Service transition Tato část životního cyklu zaujímá místo mezi návrhem služby a jejím ostrým provozem. Cílem je zajistit všechny potřebné prvky pro provoz a podporu služby. Může dojít k doladění služeb podle
- 27 -
aktuálních potřeb zákazníka jež se odchýlily od těch definovaných návrhovém balíčku, který je výstupem z předchozí fáze životního cyklu. Service Transition se nezabývá pouze implementací aplikací, ale všemi aspekty služby a to i mimořádnými situacemi, které mohou v průběhu dodávky nastat. V rámci této fáze je třeba jasně stanovit: •
Uvažovanou hodnotu pro zákazníka a komu je dodávána resp. kým je hodnocena
•
Identifikace všech zúčastněných dodavatelů, zákazníků a ostatních zájmových skupin
•
Aplikace a přizpůsobení návrhu služby včetně úprav, jejichž potřeba v rámci přeměny vyplyne
Pod tuto fázi životního cyklu jsou zařazeny tyto procesy: Change Management Změna služby je přidání, modifikace nebo odebrání autorizované, plánované nebo podporované služby či její komponenty a její dokumentace. Proces, že změny jsou zaznamenány, ohodnoceny, autorizovány, jsou jim přiděleny priority, jsou řádně otestovány a implementovány, dokumentovány a revidovány kontrolovaným způsobem. Change Management samozřejmě, jako řada dalších procesů, probíhá napříč celým životním cyklem služby a celým service managementem od strategické po liniovou úroveň Účelem Change Management je zajištění používání standardizovaných metod pro efektivní a rychlé nakládání se změnami a zaznamenání změn v rámci Configuration Management procesu. V neposlední řadě je součástí tohoto procesu i řízení rizik, které je se zavaděním změn spojené. Service asset and configuration management Tento nový V3 proces poskytuje zákazníkům přesné informace a kontrolu o všech aktivech, které tvoří infrastrukturu organizace, a jejich vztazích.Proces prostupuje celým životním cyklem služby, identifikuje, kontroluje a účtuje aktiva spojená se službami, zajišťuje a chrání jejich integritu. Aktiva jsou členěna na konfigurační položky, což jsou jednotlivé záznamy v konfigurační databázi, přičemž konfigurační položkou může být jakékoli aktivum včetně lidí a nemusí jít pouze o aktiva spojená s ICT. Jsou tu zahrnuty interní i externí poskytovatelé a aktiva, která je nutno sdílet za účelem dodávky externích služeb. Knowledge management.
- 28 -
Řízení znalostí má zajistit, že správní lidé mají správné znalosti v potřebném okamžiku, aby tak mohli zajistit podporu a dodávku služeb požadovaných zákazníky. Jedná se o nový proces oproti V2. Hlavními přínosy by mělo být: •
Efektivnější služby se zlepšenou kvalitou
•
Jasné a rozšířené porozumění hodnotám, jež služby dodávají
•
Neustálá dostupnost relevantních informací
Středem řízení znalostí je postup přeměny data – informace – znalosti – moudrost, která vytváří z dat samostatně nepoužitelných hodnotná aktiva. Transition planning and support (nový V3 proces) Plánování má zajistit •
Plán a koordinaci zdrojů k zajištění požadavků servisní strategie a návrhu služeb efektivním realizováním provozu služeb
•
Identifikaci a řízení rizik v rámci činností prováděných v této fázi
Release and deployment management Cílem tohoto nového V312 procesu je zavést všechny prvky do produkčního systému a zajistit efektivní používání nových nebo změněných služeb. Pokud je proces efektivně zvládnutý, přináší hodnotu v podobě změn, které jsou optimální z hlediska rychlosti implementace, rizik, nákladů a poskytuje konzistentní auditovatelnou implementaci. Proces uvolnění a nasazení pokrývá celou implementaci nových nebo změněných služeb do provozu od plánování uvolnění až po počáteční provozní podporu. Service Validating and Testing Hlavním smyslem testování a schvalování do provozu je dát objektivní zprávu o tom, že nová či změněná služba odpovídá požadavkům obsaženým v příslušné SLA.Oproti předcházející verzi ITIL, je zde tento proces vyčleněn zvlášť. Úspěšné testování závisí na holistickém vnímání služby – jak bude používána a jak je konstruována. Všechny služby zajišťované vlastními silami nebo externě je třeba řádně otestovat a ověřit, že splňují všechny požadavky v rámci předpokládaných situací a přijaté míry rizika. Vyhodnocování 12
Jedná se o změnu a doplnění procesu oproti Release management V2
- 29 -
Zajištění, že služba bude pro byznys použitelná, je klíčovým faktorem úspěchu Service Transition. Zahrnuje ustavení metrik a způsobů měření pro zajištění použitelnosti služby. Vyhodnocování je zaměřeno na vstupy do Service Transition – vhodnost výstupů z návrhů služby, na vlastní proces transformace a vhodnost nové nebo změněné služby pro produkční prostředí. Činnosti Service Transition: •
Řízení komunikace a povinností v rámci celého ITSM
•
Řízení změn, které se týkají organizace a účastníků
•
Řízení účastníků13
•
Řízení Service Transition a klíčových rolí
Tato verze ITIL pojímá činnost vyhodnocování jako samostatný proces. Klíčové role a odpovědnosti Zaměstnanci podílející se na Service Transition musí být vedeni k efektivnosti a hospodárnosti. Nepředpokládá se, že by pro tuto fázi životního cyklu byly vytvořeny speciální pracovní místa, nýbrž že jsou role přiděleny zkušeným a znalým pracovníkům, kteří se na vývoji služby podíleli v jiných fázích.
3.2.2.3 Service Operation V této fázi životního cyklu služby dochází k dodávání hodnot s plnění funkcí, pro které je služba určena. Služba je zákazníkům dodávána na dohodnuté úrovni a je zajištěn provoz a údržba aplikací, technologií a infrastruktury potřebné pro chod služby. K tomu je nutné najít rovnováhu mezi těmito konfliktními zájmy: •
Interní IT pohled x externí pohled zákazníka
•
Stabilita x rychlost reakce
•
Kvalita x cena
•
Reaktivní x proaktivní činnosti
Všechny tyto konflikty mohou vést k nedostatkům při poskytování služeb. Klíčové procesy a činnosti Event Management Process
13
Stakeholder management
- 30 -
Událost je změna stavu, která má význam pro management konfigurační položky nebo IT služby. Řízení událostí (jedná se o nový proces V3) je závislé na monitorování, ale je odlišné. Monitorování je založené na zjišťování stavu komponent i když tyto nehlásí žádné události. Událostí mohou být zjištěny na základě zpráv zaslaných konfigurační položkou nebo nástrojem, který tyto zprávy předává. Výsledkem výskytu události může být incident, problém, změna nebo pouze její zaznamenání pokud se jedná např. o standardní událost jako je potřeba výměny záznamového média. Incident Management Process Incident je neplánované přerušení služby nebo snížení její kvality. Za incident se považuje i porucha konfigurační položky i když zatím neměla dopad na dodávku služby. Účelem řízení incidentů je co nejrychlejší obnova služby a omezení nepříznivých dopadů na byznys.Proces řízení incidentů může být nastartován událostmi vyplývajícími z řízení událostí nebo tím, že uživatel kontaktuje help desk. Po zaznamenání by měly být ohodnoceno riziko incidentu, naléhavost a určeno, kdo by jej mohl vyřešit. Pokud ten, kdo incident zaznamená ( zpravidla pracovník help desku) není schopen jej vyřešit, dojde k jeho eskalaci. Pokud se incident opakuje, je třeba jej řešit v rámci Problem Managementu s využitím dalších procesů ( Change, Release) Request Fullfilment Process Požadavek na službu je uživatelský požadavek na informaci, radu nebo běžnou změnu, či na přístup k IT službě. Účelem nového V3 procesu vyhovění požadavku je umožnit uživateli žádat a obdržet standardní službu, poskytnout informaci o službě nebo o postupu, jak službu obdržet a poskytnout obecné informace či přijímat připomínky a stížnosti. Všechny požadavky by měly být zaznamenány a kontrolovány, zda jsou oprávněné. Access Management Process Tento nový V3 proces slouží k zajištění přístupu ke službám oprávněným uživatelům a ochraně před neautorizovanými uživateli. Proces zahrnuje identifikaci, verifikaci, zjištění nároku a garanci přístupu ke službě. Zároveň probíhá monitorování přístupu ke službám s případnou
- 31 -
změnou nebo odebráním přístupových práv.Tento proces napomáhá udržet důvěrnost, dostupnost a integritu dat. Problem Management Process Problem Management řeší opakované incidenty u nichž většinou není známá příčina. V rámci tohoto procesu probíhá zjišťování příčiny, navrhování a schvalování řešení a ověření implementace řešení. Proces je úzce svázán s Incident Management, který dává podněty pro řešení problémů a Release and Deployment Management, do jehož odpovědnosti patří vlastní implementace navrženého řešení.
Specifické činnosti Service Operation •
Monitorování a kontrola – zjištění stavu služeb a konfiguračních položek s případnou nápravou
•
Console management/ operations bridge – centrální koordinační bod pro monitorování a řízení služeb
•
Řízení infrastruktury – databáze, sklady, middleware, adresářová služba atd.
•
Provozní aspekty procesů z jiných fází životního cyklu služby: change, configuration, release and deployment, availability, kapacity, knowledge atd.
Klíčové funkce: Service desk Service desk je místo, kde se setkávají všechny zákaznické požadavky. Může se jednat o hlášení incidentů, nových požadavků na služby nebo standardních požadavků spojených s provozem ( registrace nového uživatele, změna hesla atp.) Pracovníci Service desk jsou také odpovědní za prvotní reakci na incidenty, teprve pokud jej nedokáží sami vyřešit dochází k eskalaci požadavku nebo předání požadavku do procesu Problem management. Technical management Jedná se o řízení technické infrastruktury. Hlavním úkolem je zajistit potřebné zdroje včetně lidských pro zajištění provozu, změny nebo vylepšení poskytovaných služeb. Application management
- 32 -
Tato funkce je odpovědná za řízení softwarové infrastruktury a velice úzce spolupracuje s vývojem. IT operations management Jedná se o zajištění potřebné infrastruktury pro poskytování služeb podle schválených úrovní. Jedná se o tyto dvě funkce: •
IT Operations Control – jedná se běžnou provozní kontrolu a monitorování prováděnou např. v síťovém operačním středisku.
•
Facilities Management – zajišťuje řízení data center, serverových místností a zálohování.
3.2.2.4 Continual service improvement (CSI) Neustálé zlepšování služeb je spojeno s udržováním hodnoty pro zákazníka prostřednictvím neustálého vyhodnocování a zlepšování kvality služeb a celkové zralosti životního cyklu služeb a podřízených procesů. CSI kombinuje principy praktiky a metody managementu kvality, změny a kapacit směrem k vylepšování každého stupně v životním cyklu stejně jako služeb, procesů a spojených aktivit a technologií. Model funguje na základě porovnání aktuální úrovně služeb a jejich přínosu pro zákazníka s jejich dlouhodobými cíly a úkoly. Zjištěné rozdíly jsou podněty pro změny vedoucí ke zlepšení stavu. Toto vše se provádí neustále dokola, takže se jednotlivé části ovlivňují.
Obrázek 6: Cyklus zlepšování služeb [CAR04]
Klíčové procesy a činnosti Hlavním prvkem je zlepšovací proces, který má 7 kroků pokrývajících sběr a analýzu dat, identifikaci trendů, rozhodování managementu o prioritách a implementaci zlepšení.
- 33 -
Obrázek7 : Proces zlepšování [CAR04] Každý krok je řízen strategickými a taktickými cíly definovanými během fází životního cyklu Service Stratey a Service Design. Definice, co by se mělo měřit Na základě definovaných cílů by se měla stanovit sada metrik, která by měřila jejich dosahování a to bez ohledu na to, zda jsou aktuálně data k dispozici. Definice, co lze měřit Některé veličiny definované v předchozím kroku měřit nelze, nebo neexistují potřebná data, nicméně informace o těchto nedostatcích a rizicích z toho plynoucích může být velmi důležitá. Na základě této analýzy lze stanovit budoucí cíle z hlediska měření. Sběr dat Tento krok obsahuje monitorování a sběr dat za pomoci automatizovaných či ručních operací. Hlavní důraz je třeba klást na kvalitu dat, význam mohou mít nejenom provozní data služeb procesů, nástrojů atp. , která vypovídají většinou o nějakých událostech nebo chybách, ale data o dobrém plnění SLA. V případě správného plnění požadavků, je totiž třeba vyhodnotit, zda by požadavky nešlo plnit s nižšími náklady. Úprava dat Data z různých oblastí měření a různých formátů je třeba sjednotit, tak aby mohla podávat souhrnný obraz o zkoumaných jevech.
- 34 -
Analýza Analýza by měla odpovědět na tyto otázky: •
Daří se nám plnit cíle?
•
Existují jasné trendy?
•
Je potřeba něco změnit? S jakými náklady?
Prezentace informací Při prezentaci výsledků je třeba si uvědomit, komu jsou prezentovány. Především by měli odpovídat na otázky zákazníků
a nezabíhat zbytečně do technických podrobností. Kromě
problémů nebo nezdarů je dobré prezentovat i úspěchy a inovace jichž bylo ve službách dosaženo, neboť inovace jsou hlavním marketingovým nástrojem ICT oddělení. Implementace nápravných opatření V poslední fázi cyklu zlepšování by se měly přijmout schválená nápravná opatření a to taková, aby odpovídala prioritám organizace. Po tomto kroku se činnost zlepšování vrací zpět na začátek procesu a hledají se nová opatření, jež pomohou zlepšit kvalitu dodávaných služeb. Měření služeb Měření a monitorování dává podklady pro celý proces zlepšování a je proto stěžejní součástí zlepšování procesů a prokazování hodnot, které služby přinášejí zákazníkům. Proto je třeba soustředit se nejenom na technická a provozní data, ale i na spokojenost zákazníků. 4 hlavní důvody monitorování a měření jsou: •
Ověření předchozích rozhodnutí
•
Řídit činnosti, aby plnily stanovené cíle – to je převládající důvod
•
Prokázat, že je třeba pozměnit parametry
•
Zasáhnout a v případě potřeby přijmout včas nápravná opatření
Jsou tři druhy metrik, které je třeba sledovat a to nejen pro potřeby zlepšování, ale i pro ostatní procesy. •
Technologické metriky
•
Procesní metriky
- 35 -
•
Metriky služeb
Reporting služeb Ačkoli v každodenním provozu je vyprodukováno velké množství dat, pro zákazníky mají význam jen některá. Je vhodné prezentovat data v historických souvislostech a prezentovat události, jež se staly a jak na ně ICT oddělení zareagovalo a ne pouze konstatování o plnění SLA.
3.2.3
Hodnocení ITIL
Svým obsahem, rozsahem a stylem plně odpovídá účelu, pro který byl vytvořen. Pro každého, kdo se chce zabývat řízením ICT služeb ať již teoreticky nebo prakticky, je tato knihovna velikým zdrojem poznání. Zvláště pak V3 objasňuje pozici informatiky v organizaci od strategického pohledu na vlastní aktivity organizaci a ukazuje, jak se do nich ICT zapojuje až po relativně detailní popis a řešení nejzávažnějších obtíží. Jelikož je norma učená pro všechny druhy a velikosti organizací14, zůstává popis na poměrně vysokém stupni abstrakce, nicméně i tak jsou závěry poměrně zřejmé a zejména pro začátečníka v této oblasti snadněji pochopitelné než např. u ISO 20000. O rozsahu vypovídá i počet stran, který se u V3 pohybuje kolem 300-400 stran na jednu knihu. Vlastní text je celkem pochopitelný a v obou verzích obsahuje mnoho příkladů15 nebo praktických zkušeností. Nicméně i když text psán srozumitelně, neznamená to, že je určen naprostým laikům a je třeba, aby čtenář měl alespoň nějaké zkušenosti nebo znalosti z této oblasti. Jak bylo zmíněno výše, ITIL neobsahuje podrobný popis procesů16, neboť vzhledem k různorodostem organizací by to nebylo ani vhodné ani možné. Co obsahuje, je rámec (framework) pro tyto procesy. Tzn. popisuje vstupy, výstupy, role, rozhraní, vazby procesů. Naplnit tuto konstrukci specifickými činnostmi je úkolem implementace. Teoreticky se může jednat o činnosti, které již organizace provádí a největším přínosem bude jejich popis a systematizace. I tak by uspořádání a uvědomění si souvislostí bylo přínosem a v každém případě by mělo zjednodušit a zefektivnit řízení služeb. V praxi se ovšem často dostaneme, do situace, kdy požadované procesy ve firmě jsou velmi skryté a atomizované. V takovém případě je vhodné spolupracovat se zkušenou konzultační společností a brát implementaci jako příležitost pro zavedení nových lepších pracovních postupů. To se týká především funkčně řízených společností, kdy se jednotlivé činnosti vykonávají, ale nikdo se jimi nezabývá jako celkem. Proto se asi nesetkáme se situací, kdy by po nějakém zkoumání vyplynulo, že procesy v organizaci neexistují, spíše se jedná o to, že nejsou dokumentovány jako procesy. 14
Toto obecně přijímané tvrzení je diskutováno v kapitole 5. I v tomto ohledu došlo mezi verzemi k posunu a např. Service Design V3 obsahuje citáty ze Shakespeara. 16 Je otázkou do budoucna, zda se bude informatika ubírat cestou standardizace a bude možné navrhovat tak přesné procesy, jako je tomu např. v účetnictví. 15
- 36 -
Na příkladu Change Management si to lze předvést, neboť tento proces odpovídá i postupům, které používáme v běžném životě. Ve zkratce se jedná o to, rozpoznat, že něco není v pořádku, zjistit významnost a přijmout opatření k nápravě. Samozřejmě, aby tento proces byl ve shodě s ITIL musí obsahovat další činnosti, metriky a vyhodnocování. Nicméně chci tím naznačit, že definované procesy nejsou nijak nové a hlavní přínos je, uvědomění si jejich celistvosti a propojení s ostatními.. Z vlastní zkušenosti mohu říci, že pohled na jednotlivý proces není tak složitý. Pokud, ale začneme zkoumat byť jeden proces, ale se všemi návaznostmi a rozhraními, zjistíme, že to až tak jednoduché není. V tomto ohledu je ITIL nepostradatelným vodítkem i pro ISO 20000. I když se rozhodneme pouze pro tuto normu, je využití ITIL jako „výkladového slovníku“ velmi prospěšné. Vzájemné vazby obou norem lze využít i v opačném případě. Tedy požít ISO 20000 při implementaci ITIL, jako výtah toho nejdůležitějšího. Protože ITIL je velmi rozsáhlý a obsáhlý, může se projekt, zvláště pokud by se implementovaly všechny procesy, stát nepřehledným a těžko uchopitelným. Na tomto místě může pak ISO fungovat jako „maják“, který ukazuje cestu. Nicméně první příklad bude mít asi větší přidanou hodnotu a je rozebrán na dalších místech této práce. Pro kterou normu jako hlavní se tedy rozhodnout? Záleží především na cílech projektu a požadavcích vedení podniku. Je třeba zvážit, jakou úlohu má ICT hrát ve strategii podniku. Pokud by se jednalo o zefektivnění jen některých procesů a aspektů provozu ICT služeb, pak je vhodnější ITIL. Pokud by se ovšem měly zavádět všechny definované procesy, viděl bych jako vhodnější ISO 20000. Neméně důležitým aspektem, je prezentace ICT oddělení. Zde jasně vede ISO20000, protože je certifikována organizace a její procesy, zatímco soulad s ITIL nelze nijak prokázat. Nezanedbatelnou výhodou u ISO 20000, je přezkoumávání jeho procesů externím subjektem, aby si společnost mohla udržet certifikát. To samo o sobě nutí organizaci udržovat procesy aktualizované a vynucovat jejich dodržování. Zároveň je tlačena k vytvoření speciálních rolí pro řízení kvality, takže je zde předpoklad, že minimálně formálně bude tato problematika zajištěna. -
?
- 37 -
3.3
ISO20000
Nyní se dostáváme k popisu metodiky, která je pro tuto práci stěžejní. Je jí norma ISO/IEC DIS 20000:2005 (dále jen ISO 20000). Norma stanovuje všechny povinné náležitosti pro management služeb, které jsou potřebné pro každého poskytovatele služeb. Obsahuje dvě části ISO 20000-1, která udává, jaké je třeba splnit podmínky pro certifikaci procesů managementu služeb podle této normy a ISO 2000-2 Code of practice, kde je popsáno, jak tyto podmínky plnit (pokud není řečeno jinak, kapitola se věnuje ISO 20000-1). Norma je překladem britské BS 15000, změny jsou zejména v oblasti názvosloví. ISO 20000 prosazuje přijetí integrovaného procesního přístupu managementu služeb. Procesy, které norma obsahuje, pokrývají hlavně oblasti z knih ITIL – Service support a Service Delivery (V2), ke kterým přidává další procesy a obsahuje tak celkem 13 oblastí. V oblasti managementu bezpečnosti informací norma odkazuje na ISO17799(lze využít i novější ISO 27000), které je speciálním standardem pro management bezpečnosti informací. Zatímco ITIL má v průměru kolem 350 stran/ kniha, tak obě části ISO 20000 včetně komentáře mají dohromady 65 stran. To samozřejmě vychází ze zaměření normy. Chci tím ilustrovat pouze skutečnost, že pro porozumění ISO 20000 je třeba dostatečné vzdělání v procesním řízení, informatice a pro začátečníky i ITIL, jako výkladový slovník. Pokud bychom toto vztáhli k MSP, tak si nemyslím, že by pro tuto oblast byla norma sama o sobě použitelná, protože ve většině nelze předpokládat takové znalosti v dostatečném rozsahu. Rozdíly oproti BS 15000 BS 15000 bylo původně vyvinuto ITSM komisí (BDD/3) BSI17 za přispění týmu expertů z odvětví se znalostmi z široké palety organizací. Na vývoji této normy se podílely např. : •
IT service management fórum ve Velké Británii – spravovalo náležitosti certifikace
•
BCS (The British Computer Society) – podíl na vývoji normy
•
OGC – vlastník ITIL, podíl na vývoji normy
Změny textu ISO 20000 oproti BS 15000 jsou velmi malé a bez většího vlivu na celkový smysl normy.
17
•
Termín BS 15000 by zaměněn za ISO/IEC 20000
•
Termín servisní organizace byl zaměněn za poskytovatel služeb
•
Termín třetí strana byl zaměněn za dodavatel (supplier)
•
Definice dokumentu a záznamu byly přizpůsobeny normám ISO
Britský standardizační institut
- 38 -
Předpokládané přínosy řízení služeb •
Standardizaci procesů a zefektivnění činnosti při poskytování ICT služeb
•
Řízení ICT služeb od strategie k vlastní úrovni ICT služeb
•
Minimalizací výpadků s podstatným zvýšením kvality ICT podpory a dostupnosti ICT služeb
•
Standardní procesy umožňující rychlé přizpůsobení ICT změnám v podnikání nebo rozdílným požadavkům zákazníků
•
Získání konkurenční výhody před ostatními poskytovateli ICT služeb
•
Zefektivnění svého vlastního „core businessu“
•
Marketingový přínos z certifikace
Většinu výše zmíněných přínosu lze dosáhnout pouze za předpokladu stanovení odpovídajících cílů v rámci implementace normy. O této problematice se podrobněji zmiňuji v kapitole Metodika implementace ISO 20000 Tato norma může být použita: •
Firmami, které vstupují do výběrových řízení se svými službami
•
Firmami, které vyžadují důsledný přístup od všech poskytovatelů služeb v dodavatelském řetězci
•
Poskytovateli služeb pro benchmarking jejich managementu služeb ICT
•
Jako základ ohodnocení, které může vést k formální certifikaci
•
Organizací, která potřebuje prokázat schopnost poskytovat služby, které splňují požadavky zákazníků
•
Organizací, která usiluje o zlepšení služeb pomocí efektivní aplikace procesů pro monitorování a zlepšování kvality služeb.
Vhodnost normy pro danou organizaci je třeba samozřejmě posoudit podle konkrétního případu. V potaz by měla být brána kritéria jako je velikost firmy, její obor, přidaná hodnota, kterou může informatika dát výslednému produktu firmy. Podrobněji viz další odstavce.
- 39 -
3.3.1
PDCA
Metodika ISO20000 je postavena na cyklu PDCA v jehož první iteraci by měla proběhnout implementace definovaných procesů a v dalších pak jejich zlepšování. Cyklus funguje takto: (P - Plan) Plánuj Stanovení cílů a procesů nezbytných k dosažení výsledků v souladu s požadavky zákazníka a politikou organizace. (D - Do) Dělej Implementace procesů (C – Control) Kontroluj Monitorování a měření procesů a služeb ve vztahu k politikám, cílům a požadavkům a vykonávání procesů (A - Act) Jednej Provádění opatření pro neustálé zlepšování procesů. Jedná se o upravený Demingův cyklus, do kterého na jedné straně vstupují (jak je vidět na obrázku) požadavky zákazníků a relevantního okolí a vystupují z něj prvky, které jsou obsaženy v systému řízení. Podobný účel jako PDCA v ISO plní v ITIL Service life cycle ( viz kapitola 3.2.2 o ITIL V3)
Obrázek8 : Cyklus PDCA [SEB05]
- 40 -
3.3.2
Procesy
Norma rozděluje management služeb do 13 oblastní. Oblasti a jejich propojení naznačuje obrázek 9. Ve skutečnosti jsou rozhraní procesů velmi složitá, avšak text normy se jimi nezabývá. Obsahuje především požadavky, které je třeba plnit a často, což není u ISO norem zvykem, se objevuje slovo „musí“. Požadavky jsou ovšem velmi obecné, např. že „Plán managementu služeb musí přinejmenším stanovovat: c) procesy, které mají být prováděny. …“ [SEB05, str. 11] Formální nároky na dokumentaci definovány nejsou. Procesy, které norma obsahuje pokrývají hlavně oblasti z knih ITIL – Service Support a Service Delivery (V2) a přidává další procesy.
Obrázek 9 : Oblasti procesů definovaných v ISO20000 [SEB04] Rozdíly ISO 20000 oproti ITIL Přestože jsou si oblastmi, jimiž se obě normy zabývají velmi podobné určité drobné rozdíly existují. Dále jsou uvedeny rozdíly v obecných nárocích na procesy. ISO 20000 vyžaduje systém managementu služeb, který se musí vyznačovat těmito vlastnostmi: Jasný rozsah – Musí být známí zákazníci, produkty a poskytované služby. Jestliže je rozsah jasně stanoven, organizace může zaměřit svoje omezené zdroje na správně služby a zákazníky. Řízenými procesy lze efektivněji přizpůsobit změny a směrování zdrojů v případě změněných požadavků nebo zákazníků.
- 41 -
Definované procesy Klíčové politiky, procesy a procedury musí být dokumentovány známi všem zaměstnancům podílejícím se na dodávkách ICT služeb. Dokumentované procesy jsou viditelné a umožňují monitorování měření a zlepšování. Zveřejněné politiky poskytují jasný přehled o záměrech managementu. Kontrola infrastruktury Management přiměřená kontroluje vybrané aktivity poskytování služeb, aby se ujistil, že jsou prováděny správně. Měření výkonnosti Reportování a měření procesů a dodávaných služeb poskytuje potřebnou zpětnou vazbu pro řízení procesů Neustálé zlepšování Na základě zpětné vazby z měření jsou navrhovány akce vedoucí ke zlepšení procesů. Níže jsou uvedeny hlavní rozdíly v procesech ISO 20000 a ITIL (V2) . Management vztahů s byznysem Některé prvky obsahuje ITIL Service Level Management. Tento proces zajišťuje, aby poskytovatel služeb rozuměl požadavkům zákazníků a aktivně řídil vztahy, tak aby zajistil uspokojení potřeb zákazníků svými službami. Hlavními součástmi je: -
Popis všech klíčových účastníků
-
Používání procesu pro stížnosti
-
Měření spokojenosti zákazníků
Management bezpečnosti informací Širší okruh ITIL se tímto zabývá, ISO 20000 obsahuje minimální požadavky a odkazuje se na ISO 17799 Service Desk ISO 20000 tuto funkci neobsahuje, ale předpokládá se, že tyto otázky budou řešeny v rámci Incident managementu Service reporting – Hlášení o službě Některé prvky obsahuje ITIL Service Level Management, avšak Service reporting v ISO 20000 má širší záběr a obsahuje i prvky týkající se systému řízení Management dodavatelů Není obsaženo v ITIL
- 42 -
3.3.3
ISO 20000 – 2
Druhá část normy nazývaná „code of practice“ obsahuje rozšíření, jak plnit požadavky kladené první částí. Ke každému procesu jsou popsány náležitosti, jež by poskytovatel měl plnit, aby proces odpovídal požadavkům normy a poskytoval co nejlepší výsledky. Formálně je tato část nepovinná a je v podstatě jakýmsi rozšířením navazujícím i strukturou kapitol na část první. Obsahově není o mnoho konkrétnější. Smysl této části je především nabídnout širší možnosti jak normu uplatňovat a jak se orientovat v problematice. Ovšem i v tomto směru je rozsah ITIL neporovnatelně větší a tak zůstává ITIL důležitým zdrojem minimálně pro začátečníky. O propojení zmiňovaných norem si lze vytvořit představu na základě následujícího obrázku.
Obrázek 10 : Vztah ITIL, ISO a vnitropodnikových předpisů [LAC08]
3.3.4
Co norma obsahuje
Předešlé kapitoly se věnovali hlavně popisu textu a struktury ISO 20000, nyní se podívejme, na to, co skutečně norma obsahuje a jaký to má význam. Norma je výrazně procesně orientovaná, proto je na správné řízení procesů kladen největší důraz a to v obou částech. Rámcově se tak shoduje s publikacemi o obecném procesním řízení např. Procesní řízení ve veřejném sektoru[GRA08] a specifických ICT praktik obsahuje relativně málo18. Ty jsou vidět především v oblasti dostupnosti služeb a řízení incidentů kde, ačkoli to norma výslovně neuvádí, je cítit předpoklad on- line řešení. Tedy požadavek okamžité reakce, i když samozřejmě záleží na poskytovateli, jaké reakční časy si se zákazníky domluví. Další věc, která evokuje ICT služby a rovněž není explicitně vyjádřená, je vzdálené poskytování služeb, tedy že zákazník konzumuje služby na jiném místě, než je poskytovatel poskytuje. Třetím takovým prvkem je předpoklad dlouhodobosti smluvního vztahu, který má vliv hlavně v otázkách měření a vyhodnocování procesů resp. služeb, což může vést k 18
Nebo méně, než by si člověk představoval.
- 43 -
případné úpravě SLA. Kromě těchto prvků by se norma dala použít v podstatě na poskytování jakékoli služby. Ačkoli se tyto předpoklady mohou zdát velmi omezující, v kapitole 4 si na praktickém příkladě ukážeme, že normu lze dobře přizpůsobit i když podnik formálně výše zmíněné předpoklady nenaplňuje. Přizpůsobení metodiky je důležitým krokem, při použití jakékoli metodiky. Jak je patrno z obrázku 10, prostředí organizace ovlivňují hlavně vnitřní předpisy, které jsou na základě použité metodiky vytvořeny. Takto detailní
předpisy
žádná obecná19 norma neposkytuje a jejich vytvoření je
hlavním úkolem implementace metodik řízení informatických procesů.
3.3.5
Kvalita
Normy řady ISO jsou v obecném povědomí známy především jako normy pro řízení kvality. Tuto oblast zahrnuje samozřejmě i ISO 20000 a to v procesu nazvaném management kvality. Zde je definováno, jak zacházet s podněty na zlepšení a jaké náležitosti má splňovat systém kvality. Obecné principy tohoto procesu lze přirovnat k procesu Change management. Proces obsažený v této normě se soustředí především na vlastní procesy řízení normou definované. Pokud jde o kvalitu produktu je třeba využít specializovaných přístupů jako ISO 12207, Six sigma apod.
3.3.6
Audit
Dalším markantním rozdílem mezi ISO 20000 a ITIL je způsob certifikace resp. auditu. Zatímco ITIL certifikuje pouze osoby na základě znalostí, ISO 20000 certifikuje procesy na základě shody s normou, jež definuje jasná pravidla a je tedy dobrou oporou pro vedení auditu. Jasně říká, kde má být dokumentovaný postup, kde je povinný záznam a stanovuje jejich povinný obsah. Následující popis auditu byl vytvořen na základě dokumentů firem BT [LAC08] a EZU20 [SEB]. Začněme posouzením samotné implementace systému. Z hlediska povinně řízené dokumentace organizace musí mít především: •
Dokumentované politiky a plány managementu služeb
•
Dokumentované dohody o úrovni služeb
•
Dokumentované procesy a postupy požadované touto normou
•
Záznamy požadované touto normou
Musí být stanoveny postupy a odpovědnosti pro tvorbu, přezkoumání, schvalování,
19
Tím myslím, normy, které nejsou tvořeny na firemním základě, neboť konzultační firmy samozřejmě mají pro jednotlivé předpisy připraveny šablony, které přizpůsobují dané organizaci. 20 Elektrotechnický zkušební ústav, s.p.
- 44 -
udržování, rušení a řízení různých typů dokumentů a záznamů. Taktéž musí být stanoveny úlohy a odpovědnosti v rámci všech implementovaných procesů, včetně dokladů o proškolení a dostatečné kvalifikaci k jejich vykonávání.
Postup auditu Proces auditu je jednoduchý: •
Výběr akreditované autorské firmy
•
Stanovení rozsahu certifikace – podle organizačních složek, poskytovaných služeb nebo geograficky
•
Předání veškeré dokumentace procesů a jejich politik, informací o produktech/službách – zkoumání dokumentace bude trvat asi týden, auditoři analyzují silné a slabé stránky procesů
•
Auditoři provedou v organizaci rozhovory a případně budou zjišťovat podrobnosti a objasnění k předaným materiálům
•
Auditoři zpracují zprávu
•
Auditoři prezentují výsledky auditu – pokud byl audit úspěšný, prezentace končí předáním certifikátu
•
Tento proces se opakuje každé 3 roky
Před provedením auditu by mělo být provedeno cvičení, kdy bud´ interní nebo externí osoba, jež má s průběhem auditu zkušenosti pokládá otázky, jež bude pokládat i auditor. Pozornost by přitom měla být zaměřena především na slabá místa procesů V průběhu implementace a posléze v provozu by měla být prováděna externí hodnocení ITSM procesů, protože audit samotný nedává dostatečnou zpětnou vazbu a soustředí se především na nedostatky zásadního charakteru. Toto hodnocení by mělo dávat směr dalšího snažení v ITSM a být založeno jak na slabých, tak silných stránkách. Oblasti auditu a jejich vztahy ukazuje následující obrázek.
- 45 -
Obrázek 11 : Oblasti auditu ISO 20000 [LAC08] Overview -Přehled procesu – Hodnotí se zda záměry a cíle procesu jsou jasně definovány, zda jsou určeny odpovědnosti, role a vlastník procesu Scope - Rozsah procesu – Hodnotí se, zda byl rozsah procesu definován, odsouhlasen a dokumentován, zda jsou jasně stanoveny odpovědnosti za rozhraní procesů a neustálého zlepšování Activities -Činnosti procesu – Hodnotí se, jak efektivně a účelně jsou implementovány procesy a procedury. Hodnotí se činnosti a dokumentace jejich přiřazení k procesům Kontrol, report, audit - Kontroly, kontrolní mechanismy, auditování – Hodnotí se, jak dobře jsou implementovány procesy vzhledem k jejich účelům a cílům. Procesy jsou sledovány, jak naplňují plány. Míru požadavků na vybrané procesy ukazuje tabulka v příloze 7.5. Plnění požadavků uvedených v tabulce a samozřejmě i dalších lze v rámci auditu velmi snadno prověřovat.
3.3.7
Hodnocení ISO 20000
V následujících odstavcích hodnotím text normy spíše subjektivně. Jedná se o pohled začínajícího uživatele norem a proto se některé komentáře mohou zdát nepřesné. Nicméně myslím, že následující odstavce jsou schopny text normy přiblížit těm, kteří jej ještě nečetli.
3.3.7.1 Podrobnost Text normy je konkrétní21 a obecný zároveň. Konkrétní je v tom, že stanovuje požadavky na proces, tedy že něco opravdu musí být. Obecná je v tom, že nestanovuje, jako to má být uděláno, to 21
Ve srovnání např. s ISO 9000
- 46 -
samozřejmě není účelem normy, ale mnohé začátečníky v této oblasti to může, tak jako mě, velmi překvapit. V zásadě z toho vyplývá, že požadavky normy není až tak složité splnit, jak by se mohlo na první pohled zdát. Samozřejmě je třeba vytvořit řadu dokumentů, měření procesů a dalších náležitostí, které jsou ovšem řekl bych sekundárního charakteru. Tyto náležitosti slouží především ke kontrole a auditu a na vlastní procesy nemusejí mít nijak zásadní dopad. Tato vlastnost je společní všem normám řady ISO, proto asi také panuje obecné přesvědčení, že ISO znamená pouze papírování. To je v zásadě pravda, neboť norma požaduje dokumentaci a měření procesů, nicméně je to nepochopení základního principu. Norma je o tom, jak něco řídit, ne o tom, co se má řídit. Neobsahuje tedy žádné konkrétní popisy činností, které jednotlivé procesy obsahují dokonce ani neklade přesné požadavky na dokumentaci či měření. Záleží tedy na tom, kdo si nechává normu implementovat, co z ní bude mít. O tomto problému dále pojednávám v kapitole o implementaci.
3.3.7.2 Srozumitelnost Jestliže jsem v kapitole o ITIL konstatoval, že je velmi obecný a abstraktní a že pro jeho pochopení je potřeba znalostí ISTM minimálně na obecné úrovni (procesů a cílů jednotlivých ISTM procesů), pak v případě ISO 20000 musím tuto větu opakovat a několikrát podtrhnout. Navíc je potřeba znalost ITIL. Moje první reakce, když jsem četl první stránky byl asi trojího druhu. První, celkem pozitivní, že tam není nic až tak nového nebo něco, čemu bych nerozuměl vůbec. Druhá reakce byla, že tam vlastně není nic. Tedy nic, čeho by se člověk mohl chytit a najít tyto prvky i v reálném světě. A třetí bylo naprosté zděšení, jak tyto věci implementovat do skutečné organizace. Normu jsem přečetl celou, obě části, několikrát i anglicky. Po několika pokusech mi bylo jasné, že bez ITIL to nepůjde vrátil jsem tedy o krok zpět, ke studiu ITSM procesů podle ITIL. Uvedené není kritikou normy, neboť její text plně odpovídá svému účelu. Je to spíše varování pro ostatní, kteří by se chtěli normou podrobněji zabývat, aby tak nečinili bez předchozího studia ITIL. Co musím ocenit na českém vydání Normy, je že obsahuje i anglický text, neboť vzhledem k uvedeným souvislostem to značně usnadňuje porozumění textu.
- 47 -
3.4
Závěr
V této kapitole byly popsány metodiky řízení informatických procesů COBIT, ITIL a ISO 20000. Hlavní důraz byl kladen na poslední dvě zmiňované, protože mají důležitý význam pro další části této práce. Lze konstatovat, že ačkoli se metodiky zabývají stejným předmětem, navzájem si nekonkurují, nýbrž se vhodně doplňují. To platí zejména pro ITIL a ISO 20000, jež je možné úspěšně používat ve vzájemné kombinaci. Rozdíl mezi těmito metodikami je především v obsahu, přičemž rozsah pokrývaných procesů i jejich hlavní náplně a cíle jsou velmi podobné. Ovšem zatímco ITIL přistupuje k problematice řízení informatických procesů velmi komplexně a obsahuje i celou řadu metod, které lze využít při jeho implementaci, ISO 20000 stručně shrnuje požadavky, které musí poskytovatel splnit, chce-li mít řídící procesy v souladu s touto normou. Způsob certifikace osob resp. procesů je také největším rozdílem mezi těmito metodikami.
- 48 -
4
Zkušenosti z projektu implementace
V této kapitole jsou shrnuty hlavní zkušenosti z projektu implementace ve firmě Inekon Systems s.r.o. Jedná se o přizpůsobení normy konkrétním podmínkám podniku, kde předmětem řízených procesů jsou služby poskytované v rámci implementace BI řešení u zákazníka. Dále je uvedena metodika implementace ISO 20000, jež jsem pro firmu vypracoval. Vzhledem k tomu, že projekt ještě neskončil, nemohu úspěšnost těchto opatření komentovat. Další pozorování průběhu projektu by bylo zajímavé především z hlediska propojení výše zmíněné věcné metodiky s metodikou projektovou, která ovšem není předmětem této práce.
4.1
Priority procesů
Z teoretického hlediska firma dodává produkt vytvořený na základě projektu. Nejedná se tedy o čistou službu, tak, jak ji chápe norma. Samozřejmě, že další spolupráce se zákazníkem v podobě údržby aplikace a případných úprav se více podobá službě, nicméně stěžejní činností podniku je právě implementace. ÏSO 20000 je sice primárně zaměřeno na nepřetržitě poskytované „výpočetní“ služby, nicméně díky své obecnosti není vymezení služeb a projektů na překážku jeho implementace, ale je především otázkou priorit procesů. Pokud bychom si představili vymezení projektu a služby v krajních případech, tak můžeme říci, že poskytování služby je víceméně v čase konstantní nebo se cyklicky opakuje nějaký cyklus zatížení ve špičce a mimo špičku. Dá se však s velkou pravděpodobností předvídat její průběh. Na druhou stranu projekt se chová velice nárazově a nepředvídatelně.
Srovnání priorit pro jednotlivé oblasti procesů uvádí následující
tabulka.
- 49 -
Oblast procesů
Priorita
pro Priorita
službu Výkazy o službách Vysoká Management konfigurací Vysoká Management změn Střední Management úrovně služeb Vysoká Rozpočtování a účtování pro Vysoká
projekt Nízká Vysoká Vysoká Vysoká Střední
IT služby Management
Vysoká
vztahů Vysoká
s businessem Management
vztahů
s Vysoká
Střední
dodavateli Management
kontinuity
a Vysoká
Nízká
pro Část projektu
dostupnosti služeb
Popis produktu Plán projektu Dohoda o ceně
Verze produktu – prototyp, testovací provoz, ostrý provoz
Management
bezpečnosti Vysoká
informací Management problémů Proces uvolnění Management kapacit
Vysoká
Vysoká Střední Střední
Vysoká Vysoká
Nová verze SW,
Vysoká
service pack Plánování kapacit, zejména
Management incidentů
Vysoká
Vysoká
lidských zdrojů Změny zadání projektu
Tabulka 1 Priority procesů pro službu a projekt Nízká priorita samozřejmě neznamená, že proces není důležitý. Tabulka slouží k porovnání, které procesy jsou v daném případě implementace důležitější. V posledním sloupci je uvedeno převedení pojmu ze služby na část projektu, ke které se bude proces vztahovat. Do různých procesů by se pak měly promítnout odpovídající části používané metodiky řízení projektů.
4.2
Metodika implementace ISO 20000
Tato kapitola popisuje zvolenou metodiku implementace ve firmě Inekon Systems. Její účel, vznik a rozebírá jednotlivé aspekty přípravné fáze projektu. Předně je třeba zmínit, že v ani jedné normě není přesný popis nebo konkrétní návod, jak management služeb implementovat. Součástí ITIL je kniha Planning to implement service management [OGC02], která shrnuje problematiku a
- 50 -
podtrhuje nevětší problémy, jež se mohou vyskytnout. Zároveň nabízí metody, které v jednotlivých krocích použít. Vlastní projekt je pak kombinací těchto metod a obecné projektové metodiky, kterou ITIL neobsahuje a odkazuje se v této souvislosti především na PRINCE2 a PMBOK. ISO 20000 obsahuje v kapitole 4 – Plánovaní a implementace managementu služeb Demnigův cyklus22 v jehož jedné iteraci se implementace provádí. Ten stanovuje minimální rozsah činností, které musí být provedeny, ale jejich konkrétní metody neuvádí a to ani v ISO 20000-2. V knize věnované procesnímu řízení obecně je popsán postup implementace procesního řízení v organizaci, který je ve shodě se zde zmiňovanými přístupy. Konkrétní metodika, která je popsána v této kapitole tedy vznikla na základě doporučení z knihy Procesní řízení ve veřejném sektoru[GRA08] , činnosti v jednotlivých fázích byly převzaty ze zkušeností firmy BT[LAC08] a normy ISO 20000[SEB05], metody z ITIL PISM[OGC02].
4.2.1
Metodiky implementace zaměřené na ISO 20000
Na tomto místě je popsána metodika implementace ISO 20000 vypracovaná firmou BT a taktéž základní prvky, které obsahuje samotná norma. Zkušenosti BT ukazují, že úspěšné implementace jsou založeny na Demingově cyklu, jehož obsah je trochu upravený. Cyklus je založen na iteraci aktivit plánuj, dělej (realizace), kontroluj a jednej. Podrobnější popis viz. kapitola o ISO 20000. Celý projekt by měl být pojat jako zahájení postupné přeměny procesů ne jako revoluce. BT odhaduje, že bez ohledu na velikost investice použitých zdrojů,
typická organizační i kulturní transformace
směrem k ISO 20000 trvá u větších
společností přes dva roky. Seznam činností zde uvádím, protože značně rozšiřuje požadavky normy a byl vzat jako základ pro vypracování vlastní metodiky Inekon Systems.
22
Podrobný popis je uveden dále v této kapitole.
- 51 -
Činnosti Plánuj: •
Provést všechny běžné projektové plánovací aktivity23
•
Provést analýzu rozdílů mezi stávajícím stavem a stavem požadovaným normou
•
Určit schopnosti a potřebná školení o organizaci ICT
•
Ke každému procesu přiřadit vlastníka
•
Vytvořit program všech aktivit spojených s ISO 20000, aby byla zajištěna kontrola
•
Vytvořit projektové plány definující a dokumentující fungování provozních procesů
•
Vytvořit komunikační plán plány pro účastníky procesu, obchodní a ICT části organizace
•
Definovat vzory a požadavky na procesní dokumentaci
•
Definovat organizaci řízení implementace.
Činnosti Dělej •
Definovat a odsouhlasit politiky a obchodní cíle procesu
•
V rámci každé oblasti definovat procesy a činnosti založené na požadavcích z předchozího kroku
•
Vytvořit nebo pořídit a implementovat nástroje potřebné pro podporu procesů
•
Provést školení
•
Průběžně informovat vrcholové vedení a ostatní útvary podniku
•
Implementovat procesy a související nástroje a začít sledování metrik a KPI
Činnosti Kontroluj •
Podrobit všechny procesy srovnávacímu měření a hodnocení
•
Sbírat všechny návrhy na zlepšení a optimalizaci služeb
•
Analyzovat KPI a navrhovat zlepšování služeb
•
Zajistit, aby byly funkční všechny kontrolní mechanismy poskytující potřebné reporty
•
Provést interní audit shody s normou nebo externí hodnocení
•
Jestliže je organizace připravena, zahájit externí audit pro získání certifikace.
Činnosti Jednej
23
•
Provést dodatečné interní audity nebo externí hodnocení slabých míst organizace
•
Integrovat ISO 20000 do všech stávajících programů zlepšování kvality
•
Provést nápravu neshod zjištěných při auditech (stanovit priority a harmonogram)
•
Stanovit roční interní audity pro zajištění shody s normou
Včetně stanovení cílů a přínosů projektu a způsobu měření jejich dosažení.
- 52 -
Nyní si popišme některé důležité činnosti podrobněji: Stanovení rozsahu První a nejdůležitější je stanovení rozsahu certifikace. Ten může být ohraničen organizačně, geograficky projektem nebo poskytovanou službou. Z hlediska návratnosti investic, je menší rozsah výhodnější, nicméně je zde nebezpečí, že po certifikaci malé části organizace již pro další rozšiřování nebude dostatečná podpora. Rozsah certifikace by také měl být uváděn ve smlouvách nebo by se o něj měl zákazník zajímat, protože certifikována může být jiná služba než právě poptává. Určení vlastníků procesů Vlastník není odpovědný za přímé vykonávání procesu, ale určuje jeho strategii, politiku a směr ve vztahu k požadavkům obchodu. Měl by to být člen vrcholového vedení, protože např. u Change managemtnu, by se mohlo předpokládat, že vlastníkem procesu bude Change manager, nicméně ten je odpovědný za každodenní řízení jednotlivých změn, takže nemá dostatečný nadhled a navíc by si neměl sám určovat cíle a požadavky pro svojí práci. Vhodným kandidátem u tohoto konkrétního procesu je např. viceprezident Service support Stanovení metrik a KPI Norma metriky a KPI požaduje a měly by být stanoveny v prvních fázích implementace. Ještě před jejich stanovením je třeba si ujasnit některé faktory: •
Jak bude každá metrika/KPI používána?
•
Kdo a pro jaký účel bude požívat reporty
•
Jaké informace budou považovány za užitečné
•
Jakým způsobem budou zprávy o metrikách a KPI podávány
•
Odkud se budou brát data pro měření a budou tyto důvěryhodná
•
Může být sběr dat automatizován? Pokud ne, nepřevýší náklady na měření a vyhodnocování přínosy, které poskytnou pro zlepšování procesů?
U každé metriky a KPI je třeba zvážit, jak bude ovlivňovat běžný provoz a chování v organizaci. Je to další oblast, ve které je třeba zajistit shodu se strategií ICT i celé firmy, aby se nestalo, že sice požadavky stanovené metrikami budou plněny na 100%, ale výsledek celého procesu bude znamenat pro firmu výraznou ztrátu.
- 53 -
Co stanovuje ISO 20000 Jak bylo poznamenáno výše, norma se zabývá především obsahem plánu, který je definován ve fázi plánuj Demingova cyklu, ve fázi dělej, spíše uvádí, že se má plán realizovat bez přidání dalších požadavků a v následujících fázích jsou zmíněny především obecné nároky na metriky, získávání dat vhodných pro audit a stanovení programu auditu, což je podobné výše popsané metodice, proto zde uvádím pouze první dvě fáze. Plánování managementu služeb (Plánuj) •
Rozsah managementu služeb
•
Cíle a požadavky, kterých má být managementem služeb dosaženo
•
Procesy, které mají být prováděny
•
Rámec pro role a odpovědnosti managementu včetně vyšších odpovědných vlastníků, vlastníků procesů, a řízení dodavatelů
•
Rozhraní mezi procesy managementu služeb a způsoby, jakými jsou činnosti koordinovány
•
Přístup určený k identifikaci, hodnocení a řízení problematických záležitostí a rizik na cestě k dosahování stanovených cílů
•
Přístup k určování vazeb na projekty, které vytvářejí nebo pozměňují služby
•
Zdroje, prostředky a rozpočet nezbytný pro dosažení stanovených cílů
•
Nástroje vhodné k podpoře procesů a
•
Jak bude řízena, auditovaná a zlepšována kvalita služeb
V tomto kroku norma dále požaduje jasné rozdělení odpovědností za projekt implementace a stanovení způsobů pro komunikaci plánů, přezkoumání, autorizaci a udržování. Implementace managementu služeb a poskytování služeb – dělej •
Poskytovatel musí implementovat plán obsahující
•
Přidělení finančního krytí a rozpočtů
•
Přidělení rolí a odpovědností
•
Dokumentaci a údržbu politik, plánů. Pracovních postupů, a vysvětlení pojmů pro každý proces nebo sadu procesů
•
Identifikaci řízení rizik spojených se službami
•
Řízení týmů, např. nábor a rozvoj vhodných zaměstnanců a řízení stabilizace zaměstnanců
•
Řízení prostředků a rozpočtu
•
Řízení týmů včetně podpory zákazníka a provozu
•
Výkazy o skutečném plnění ve vztahu k plánům a
- 54 -
•
Koordinaci procesů managementu služeb
V dalších fázích jsou uvedeny obecné nároky na metriky, získávání dat vhodných pro audit a stanovení programu auditu.
4.2.2
Metodika v Inekon Systems s.r.o.
Na základě těchto zdrojů byla vypracována metodika pro konkrétní implementaci normy v prostředí malé ICT organizace čítající zhruba 25 zaměstnanců a poskytující služby Business Inteligence. V tomto konkrétním případě slouží metodika k vysvětlení jednotlivých částí projektů a obsahuje metody, které budou použity ke splnění jeho cílů. Naznačuje časovou posloupnost prováděných činností, ovšem pouze rámcově. Rozebírá postupy a náplň jednotlivých činností, jež budou v rámci projektu vykonávány. Neobsahuje konkrétní informace o časovém průběhu, výši alokovaných zdrojů, odpovědností atd. Je to jakýsi vysvětlovací dokument, který určuje rámec, na jehož základě bude vypracován plán projektu. To je řekněme vnější pohled pro účastníky projektu. Dalším neméně podstatným přínosem metodiky je její vznik, protože jak již bylo řečeno normy návod pro svou implementaci neobsahují. V průběhu jejího vzniku bylo možné si uvědomit podrobné vztahy mezi jednotlivými fázemi projektu, činnostmi a jejich významem a dopadem na organizaci. A konečně značná část dokumentu bude použita pro vypracování plánu odpovídajícího normě Z hlediska požadavků normy je tento dokument tedy navíc, nicméně valná část bude použita pro vytvoření plánu implementace, který již norma definuje. Na dalších stranách je výsledný dokument, který jsem z výše uvedených důvodů vytvořil. Protože některé jeho část si zaslouží větší pozornost, jsou opatřeny komentářem formátovaným kurzívou, který není součástí vlastního firemního dokumentu.
4.2.2.1 Dokument Metodika implementace ISO 20000 Tento dokument stanovuje principy a postupy projektu implementace standardu 20000-124
ISO/IEC
v Inekon Systms s.r.o. Popisuje, jak bude zjištěn aktuální i požadovaný stav Service
managementu a jakými způsoby se požadovaného stavu dosáhne. Určuje analýzy, které budou za tímto účelem provedeny i jejich metody. Vzhledem ke komplexnosti projektu, bude tento prováděn po etapách, v nichž se budou implementovat ucelené oblasti procesů. Procesy do jednotlivých etap budou zahrnuty podle rozsahu dopadu na chod firmy a stávající úrovně jejich zralosti, která bude popsána v příslušném
24
Dále jen norma.
- 55 -
dokumentu. První etapa navíc bude specifická, protože se v ní budou testovat
postupy návrhu
procesů a komunikační strategie. Změny v organizaci práce i podnikové kultuře mohou být po dokončení projektu zcela zásadní a proto je správné komunikaci a získání pracovníků pro projekt třeba věnovat mimořádnou pozornost, protože to je klíčový faktor úspěchu. Z tohoto důvodu bude vypracována komunikační strategie napojená na analýzu klíčových rolí v projektu.
Analýzy Pro projekt budou provedeny analýzy aktuálního stavu i požadovaného stavu budoucího. Aktuální stav bude analyzován jednak z celkového pohledu podniku a jednak pro jednotlivé procesy jako úvodní fáze jejich implementace. Požadovaný stav v zásadě definuje norma, která popisuje nutné náležitosti jednotlivých procesů i způsoby jejich hodnocení. Aby procesy byly měřitelné, budou tam, kde je to vhodné a účelné stanoveny příslušné metriky a jejich hodnocení v souladu s cíli a politikami procesu..Pro definování očekávaných dlouhodobých přínosů bude provedeno interwiev se sponzory projektu, což je v tomto případě vedení podniku a vedoucí jednotlivých úseků. Analýzy a jejich postup byly převzaty z metodiky ITIL. Ve většině případů se jedná o značné zjednodušení jejich rozsahu a hloubky a to především z důvodů velikosti firmy a s přihlédnutím k cílům projektu. Nicméně každá z nich poukazuje na důležité aspekty, jež je třeba brát v potaz a je tedy užitečná pro správné hodnocení.
Cíle a přínosy projektu Stanovení hlavních i dílčích cílů jednotlivých etap, potažmo celého projektu je zřejmé z jeho podstaty
a tou je získání certifikace managementu služeb společnosti podle normy ISO/IEC
20000-1. Tomu odpovídají i metriky, což jsou požadavky normy pro certifikaci. Stanovení přínosů bude provedeno na základě rozhovorů s vedením podniku a vedoucími jednotlivých oddělení. Lze předpokládat, že to budou přínosy spíše kvalitativní, jejichž měření nebude snadné. Pro jednotlivé procesy budou stanoveny metriky podle požadavků normy a politiky kvality, která bude vytyčovat strategické úkoly managementu služeb.
Organizační a odpovědnostní struktura Analýza organizační a odpovědnostní struktury je důležitá především z hlediska odpovědnosti za činnosti, jež se stanou součástí navrhovaných procesů. Je třeba identifikovat osoby, jež budou schvalovat a podílet se na návrzích. Jelikož některé procesy budou probíhat napříč firmou, mimo stávající organizační strukturu, bude důležité správně delegovat nové pravomoci a to nejen výkonné, ale i kontrolní. Na základě výstupů z této analýzy budou určení vlastníci jednotlivých procesů.
- 56 -
Zájmové skupiny25 a jejich předpokládané role v projektu Tato analýza by měla objasnit role a postoje zájmových skupin v projektu. Tyto skupiny budou mít pravděpodobně rozdílné zájmy i užitky a náklady z projektu. Hlavními skupinami budou sponzoři projektu, zaměstnanci a uživatelé. Vzhledem k velkosti firmy a její organizační struktuře, je možné, že někteří lidé budou členy více skupin. U takových osob je třeba určit jejich hlavní roli a zájem na projektu.Toto se může týkat především vedení podniku, které se ocitá jednak v roli sponzora projektu, ale jednotlivý vedoucí jsou zároveň zaměstnanci a měly by i projekt podporovat a prosazovat.Další důležitou skupinou jsou klíčový uživatelé 26, představující především zkušené pracovníky a experty. Jejich získání je důležité, neboť jejich případný odpor může velmi zkomplikovat postup projektu. Pro rozpoznání postojů jednotlivých členů zájmových skupin je třeba zjistit, jejich potřeby, které by mohl projekt naplňovat nebo ovlivnit a jejich aktuální uspokojení. Na základě zjištěných údajů mohou být lépe komunikovány cíle projektu a jejich přínosy pro jednotlivé skupiny.
Zralost managementu služeb Jedná se o hodnocení definovanosti procesů podle toho, jestli jsou jejich činnosti vykonávány jednotným způsobem v souladu s požadavky businessu, zda jsou dobře zdokumentovány a jsou pro ně vyčleněny zdroje. Hodnotí se také vyhodnocování efektivnosti procesu a její měření. Taktéž je možné podobnou metodou ohodnotit podnik jako celek, do jaké míry řídí svoje služby potřebami zákazníků. Ovšem je pravděpodobné, že obě analýzy dospějí ke stejnému stupni zralosti, protože nelze předpokládat zralý proces v prostředí, kde ostatní procesy jsou na nižší úrovni a taktéž zralý podnik bez zralých procesů Určení stupně, ve kterém se podnik nachází je z hlediska projektu spíše informativní, protože cíle projektu jsou pevně stanoveny normou a nelze se od nich odchýlit. Ovšem v mnohém může napovědět pro dosažení přínosů. Metodou této analýzy bude Process Maturity Framework [OGC02] Analýza sleduje 5 kritérií procesu: •
Vize a směrování
•
Proces
•
Lidé
•
Technologie
25
Stakeholders Ze se jedná o zaměstnance, kteří budou „užívat“ procesy ve své práci, a zákazníky, jež budou „užívat“ definovaných služeb. 26
- 57 -
•
Kultura
Existuje 5 úrovní vyspělosti procesu od základní (1) až po optimalizovaný proces. Stupeň 1 Výchozí Proces je rozpoznán, ale je řízen velmi málo nebo vůbec, není považován za důležitý a je mu věnována malá pozornost a zdroje v rámci organizace.Tento stupeň lze také popsat jako „ ad hoc“ , příležitostný až chaotický. Vize a směrování
Minimální
financování
a
zdroje
s nízkou
aktivitou Výsledky jsou dočasné a neudržitelné Proces
Ojedinělé reporty a revize Nejasně definované procesy, kdy činnosti jsou vykonávány pouze jako reakce na vzniklý problém Totálně reaktivní proces
Lidé Technologie
Aktivity jsou nepravidelné a neplánované Nejasně definované role a odpovědnosti Proces je prováděn ručně nebo za použití
Kultura
malého počtu specifických, oddělených nástrojů Orientovaná technologicky a nástrojově se silným zaměřením na činnosti
Tabulka 2 stupeň vyspělosti procesu 1
- 58 -
Stupeň 2 Opakovatelný Proces je rozpoznán a je mu v provozu dávána malá důležitost, zdroje nebo pozornost. Obecně jsou aktivity spojené s procesem nekoordinované, nepravidelné, nejednotné a jsou řízené směrem k efektivitě.
Vize a směrování
Nemá jasné úkoly a cíle Má dostupné zdroje Nepravidelné, neplánované aktivity, reporty a
Proces
přehledy Činnosti a procedury jsou definované Vysoce reaktivní proces
Lidé Technologie
Nepravidelné a neplánované aktivity Nezávislé (oddělené) role a odpovědnosti Mnoho oddělených nástrojů s nedostatečnou kontrolou
Kultura Tabulka 3 stupeň vyspělosti procesu 2
Data jsou uložena odděleně Orientovaná a řízená na produkt a službu
- 59 -
Stupeň 3 Definovaný Proces je rozpoznaný a dokumentovaný, ale není formální odsouhlasení, shoda a vyjasnění
jeho
role v provozu celé IT organizace. Vize a směrování
Dokumentované a odsouhlasené formální úkoly a cíle Formálně
zveřejněné,
monitorované
a
revidované plány Dobře financovaný s dostatečnými zdroji Proces
Pravidelně plánované reporty a přehledy Jasně definované a správně zveřejněné činnosti a procedury Pravidelně plánované aktivity Dobrá dokumentace
Lidé
Příležitostně proaktivní proces Jasně definované a schválené
role
a
odpovědnosti Formální úkoly a cíle Technologie
Formalizované plány školení procesu Data jsou sbírána průběžně včetně
hlášení
dosažení prahových mezí Kultura Tabulka 4 stupeň vyspělosti procesu 3
Formální pojetí orientace na zákazníka a službu
- 60 -
Stupeň 4 Řízený Proces je plně rozpoznán a akceptován napříč organizací. Je servisně zaměřen a má úkoly a cíle, které jsou založeny na obchodních požadavcích a záměrech. Proces je plně definován, řízen a stal se proaktivním s dokumentovanými a ustavenými rozhraními a závislostmi s ostatními procesy. Vize a směrování
Jasný směr vymezený obchodním zaměřením, úkoly a formálními cíly, měřený postup Jsou používány efektivní manažerské reporty Integrované procesní plány jsou propojeny s obchodními a IT plány
Proces
Pravidelné plánované a revidované zlepšování Dobře definovaný proces, činnosti a standardy včetně popisu všech pracovních míst Jasně definovaná rozhraní a závislosti procesu Integrovaný proces Service managementu a systémového vývoje
Lidé
Ve většině případů je proces proaktivní Inter a intra procesní týmová práce Odpovědnosti jsou jasně definovány ve všech
Technologie
popisech pracovních míst Průběžné monitorovací měření Reporting prahových
Kultura
a mezí
upozorňování
o
centralizované
dosažení skupině
integrovaných nástrojů, databází a procesů Zaměřená na business s porozuměním širším souvislostem
Tabulka 5 stupeň vyspělosti procesu 4
- 61 -
Stupeň 5 Optimalizovaný Proces je plně rozpoznaný a jeho strategické cíle a úkoly jsou v souladu s celkovou business strategií a cíly. Tyto jsou nyní institucionalizovány a jako součást každodenní aktivity všech účastníků procesu. Proces obsahuje prostředky pro kontinuální zlepšování, které vytváří prostor pro prevenci. Vize a směrování
Integrovaná
se
strategickými
plány,
neoddělitelně spojená s celkovými business plány, cíly a úkoly Průběžné mezních
monitorování, stavů
měření,
s revizemi
hlášení
napojenými
na
průběžný proces zlepšování Pravidelné audity efektivnosti, hospodárnosti a Proces
shody Dobře definované procesy a činnosti, které jsou součástí firemní kultury
Lidé
Proaktivní proces obsahující prevenci Úkoly vycházejí z požadavků businessu a formální cíle jsou aktivně monitorovány v rámci každodenní činnosti Role a odpovědnosti jsou součástí celkové
Technologie
firemní kultury Dobře dokumentovaná celková architektura s kompletní integrací všech oblastí – lidí,
Kultura
procesů a technologie Postavená na průběžném zlepšování společně se zaměřením na business strategii Porozumění jakou hodnotu má IT pro business a jejich role v hodnotovém řetězci
Tabulka 6 stupeň vyspělosti procesu 5 V rámci projektu implementace je cílem, aby procesy definované normou dosáhly 3. stupně zralosti. Po ukončení projektu a zavedení procesu neustálého zlepšování bude cílem v dohledné době posunout nejdůležitější procesy na stupeň zralosti 4. Nejvyšší tedy 5. stupeň je ideální stav a je otázkou, zda jej lze dosáhnout, popřípadě, zda je to ekonomicky přínosné.
- 62 -
Komunikační strategie Vzhledem ke komplexnosti projektu, nárokům na jeho organizaci a požadavkům na změnu pracovních postupů, jež se dotkne mnoha zaměstnanců, je třeba stanovit vhodnou komunikační strategii, jež ozřejmí cíle projektu, jeho přínosy a nebude zamlčovat náklady. Z hlediska obecného Change managementu27 je třeba vytipovat pracovníky, kteří jsou změnám nakloněni a jejich pomocí přesvědčit i ostatní. Většina ohlášených organizačních změn vyvolává apriori negativní emoce, na jejichž zvládnutí je pak potřeba vyvinout nemalé úsilí, které by bylo lépe věnovat pro projekt samotný. Dále také je podpora projektu jednou z nejdůležitějších okolností jeho úspěchu. Jelikož je projekt implementace ISO 20000 značně rozsáhlý a přinese změny na všech úrovních organizace, včetně změny odpovědností a vyhodnocování efektivity podniku, je třeba předejít negativnímu vymezení se pracovníků. Vzhledem k výše uvedenému, je důležité, aby byl projekt od začátku maximálně otevřený a to nejen pokud se jedná o cíle a plánované přínosy. Všichni zainteresovaní by měli mít možnost se včas vyjádřit k navrhovaným dokumentům a jejich připomínky by měly být v maximální míře zakomponovány do návrhů. Tím se značně sníží možnost vyvolání pocitu, že se rozhoduje „ o nás bez nás“. Ovšem je třeba nevzbudit nesplnitelná očekávání např., že projekt sám vyřeší veškeré problémy. Je třeba vytvořit otevřenou a přívětivou atmosféru a předejít možnosti prosazovat projekt silou, což je pro malý podnik obzvláště nebezpečné. Pokud by někdo změny nepřijal a dál pracoval podle starých metod, může to mít dalekosáhlé důsledky.
Opatření komunikační strategie Dále jsou popsány základní prvky komunikační strategie a jejich propojení s postupem projektu. Je možné, že v průběhu projektu dojde ke změnám nebo přibudou další opatření.
Zveřejňování dokumentů Dokumenty budou schvalovány vedením ke zveřejnění na základě jejich stadia vývoje a klasifikace28. Stadiem vývoje se myslí, zda je dokument již ve své platné podobě a podléhá změnám podle příslušného předpisu, či se jedná o dokument ve stadiu vzniku (např. pracovní návrh procesu, politiky). Dokumenty týkající se projektu a určené ke zveřejnění budou umístěny na přístupném místě, aby do nich mohli pracovníci nahlížet. Obecně bude snaha, aby co nejvíce dokumentů bylo veřejných a všichni měli dostatek informací o průběhu projektu.
27
Tím je myšleno obecné prosazování změny, ne proces Change managementu podle normy. Klasifikací se myslí přiřazení stupně důvěrnosti dokumentu od obecně veřejného po důvěrný. Viz příslušný předpis 28
- 63 -
Změny projektu a příslušných dokumentů Otevřenost projektu bude spočívat především v možnosti vyjadřovat se a navrhovat změny ke všem relevantním součástem. To se týká především fází návrhů jednotlivých procesů, kdy bude zapotřebí především navrhnout procesy tak, aby co nejvíce přispívali k efektivitě práce a byly v nich obsaženy nejlepší postupy a zkušenosti všech pracovníků. Ovšem politiky a metriky zůstanou plně v kompetenci vedení. O významných přírůstcích budou zaměstnanci informováni prostřednictvím Newsletteru, drobné změny a úpravy budou popsány v souboru, který bude uložen spolu s dokumenty v centrálním úložišti projektu.
Veřejná diskuse Kromě elektronické komunikace bude o postupu na projektu podávána pravidelná zpráva na poradách včetně prostoru pro otázky. V této souvislosti je třeba, aby hlavní argumenty pro projekt podával nejen implementační tým, ale i vedení a pokud možno se vyhnul odpovědím typu „ Protože to tak musí být podle ISO“. Členové implementačního týmu budou samozřejmě mít povinnost zabývat se otázkami připomínkami a stížnostmi a podávat odpovědi v přiměřeném rozsahu a čase. Pro sběr návrhů a požadavků i mimo aktuálně navrhované procesy bude zřízena emailová schránka.
Politika a plán Managementu služeb Jednou z hlavních odpovědností vrcholového vedení je stanovit politiku managementu služeb, které bude obsahovat cíle, které je třeba dosáhnout a plány k nim vedoucí. Podrobné požadavky na tyto dokumenty obsahuje norma, proto nebudou na tomto místě dále diskutovány.
Procesy Procesy splňující kriteria normy jsou stavebními prvky jednotlivých oblastí, kterým se norma věnuje. Pro každou oblast managementu služeb popsanou v normě je třeba stanovit politiku, která bude obsahovat manažerské shrnutí hlavních cílů, činností, návazností na ostatní oblasti a strategii společnosti. Na této politice se budou podílet zejména odpovědní řídící pracovníci jednotlivých úseků a to podle toho, který úsek bude mít hlavní odpovědnost za oblast. Vzhledem k tomu, že procesy prostupují organizací napříč úseky, budou se k politice vyjadřovat všichni členové vedení nebo bude požadován alespoň jejich formální souhlas s politikou.
Definování politiky Osnova politiky bude stanovena podle požadavků normy, pokud jsou tyto přesně stanoveny, jinak bude vycházet ze základních principů managementu služeb. K jednotlivým bodům osnovy bude
- 64 -
vedeno interwiev s odpovědným pracovníkem. Tím se zjistí aktuální stav oblasti a zároveň budou sděleny případné požadavky na změnu vzhledem k normě. Pracovní znění politiky vypracuje osoba pověřená implementací a to s důrazem na plnění požadavků normy. Tuto verzi pak ve spolupráci s odpovědným pracovníkem dopracuje do podoby politiky odsouhlasené oddělením, které má za oblast odpovědnost ( nebo její největší část) a bude postoupena ostatním vedoucím pracovníkům k připomínkám a odsouhlasení. Konečné odsouhlasené znění politiky se stane součástí zveřejněného dokumentu.
Etapy Projekt bude rozdělen na etapy podle skupin procesů a podle fáze jejich implementace. Protože procesy pokrývají celou organizaci a jsou vzájemně propojeny, nelze je navrhovat všechny najednou, stejně tak nelze některé procesy implementovat, zatímco ostatní nebudou ještě navrženy. Souběžně s etapami návrhů procesů bude navrhována konfigurační databáze, jejíž zprovoznění bude první etapou implementace. V průběhu jednotlivých etap může dojít k potřebě změn v již schválených procesech, proto bude Change management zařazen do první etapy. Procesy do jednotlivých etap budou zařazovány podle svého dopadu do organizace, stupně jejich aktuální zralosti a potřeb napojení na ostatní procesy. První etapa bude specifická, protože se v ní budou testovat postupy spolupráce a zkoušet nejvhodnější formy komunikace.
Návrh procesu Jednotlivé procesy, které vyplynou z požadavků normy, budou navrhovány v několika krocích, jejichž smyslem bude určit počáteční a cílový stav. Návrh cílového stavu procesu se pak stane základem pro jeho implementaci. Popis jeho počátečního stavu bude vycházet z analýzy zralosti procesu podle PMF (viz výše) . Z této analýzy vyplynou hlavní oblasti, kterým se bude další postup věnovat, tak aby vedl ke splnění požadavků cílového stupně zralosti, předepsaným požadavkům normy a zároveň co nejvíce vyhovoval potřebám firmy. Návrh
bude postupovat podle jednotlivých procesů definovaných v normě a zařazených do
konkrétní etapy. Po odsouhlasení politiky
a shodě na principech jednotlivých procesů bude
navržena pracovní verze, která se stane podkladem pro jednání s odpovědnými pracovníky, kteří buď aktuálně vykonávají činnosti, které budou zahrnuty do procesu nebo tyto činnosti budou vykonávat v budoucnu. Výsledná podoba procesu bude schválena vedoucími oddělení, jichž se proces dotýká. Pokud je zákazníkem procesu externí subjekt bude jeho zájmy zastupovat obchodní oddělení. Z takto schválených návrhů bude vytvořen celkový proces etapy a posléze i business procesy firmy. Postup zdola nahoru je zvolen z několika důvodů. Jednak to umožní postupné poznávání požadavků normy a konfrontaci s realitou v podniku, dále v prvních fázích návrhu vyplynou propojení mezi
- 65 -
jednotlivými procesy, jejichž zkoumání na vyšší úrovni by bylo značně obtížné a v neposlední řadě to umožní věcnou komunikaci nad specifickými problémy. Samotná analýza aktuálního stavu všech procesů by si vyžádala mnoho času a zdrojů, protože firma je funkčně řízena a procesy nejsou explicitně rozpoznané29 . Účelem tedy je z jednotlivých procesů, odpovídajících normě, sestavit business procesy, které budou přijatelné a efektivní
pro chod
organizace. Dokumentace procesu bude zahrnovat jak slovní, tak grafický popis, který bude ve formě diagramů používajících notaci BPMN 1.0. Struktura dokumentu procesu bude obsahovat: •
Jméno procesu, verze
•
Politika
•
Přehled procesu
•
30
Vstupy
o
Podprocesy
o
Činnosti
o
Výstupy
o
Události startující proces
o
Nástroje
Role a odpovědnosti o
Výkonné odpovědnosti
o
Vlastník procesu
o
Účastníci procesu
o
Ostatní role
•
Další dokumentace
•
Rozhraní
•
29
o
o
K ostatním procesům SM30
o
K ostatním procesům IT
o
K business procesům
Závislosti o
Na a k ostatním procesům SM
o
Na a k ostatním procesům IT
To ovšem neznamená, že neexistují. Service management
- 66 -
o •
Na a k ostatním business procesům
Formální cíle o
Měření
o
Metriky
o
Cíle a časové měřítko
•
Revize, hodnocení a audit
•
Reporty vytvářené procesem o
Frekvence
o
Obsah
o
Distribuce
•
Slovník pojmů, zkratky a odkazy
•
Komunikační plán
Komunikační plán vysvětluje politiku procesu všem účastníkům, obsahuje: •
Misi a ústřední zprávu procesu
•
Cílové skupiny
•
Komunikační strukturu, která vysvětluje, kdo s kým a o čem má komunikovat.
•
Časové měřítko
•
Metody komunikace
•
Identitu cílových skupin, úkoly, přínosy, faktory úspěchu a neúspěchu, možnost odporu
Nástroje Vzhledem ke komplexnosti projektu a předpokladu vzniku mnoha nových dokumentů a evidencí a potřebě jejich vyhodnocování bude potřeba zavést standardizovaný systém oběhu dokumentů. Dále jako součást vlastní implementace normy bude potřeba vytvořit konfigurační databázi. Oba tyto prvky by měly být automatizovány a proto bude potřeba vytvořit nejen pravidla vlastního fungování, ale pokud možno implementovat nástroje pro jejich podporu. Z tohoto důvodu proběhne výběrové řízení na vhodný produkt. Požadavky na produkt vyplynou z potřeb evidencí jednotlivých procesů.
4.3
Závěr
V této části práce byly popsány hlavní zkušenosti a výstupy z přípravné fáze projektu implementace ISO 20000 ve firmě Inekon Systems s.r.o. Jedná se řešení otázek, které jsou na pomezí mezi zněním normy a tvorbou řídících dokumentů pro jednotlivé procesy. Je to hlavně - 67 -
přizpůsobení normy prostřednictvím přidělení priorit jednotlivým procesům, jež se v samotném projektu projeví hlubší analýzou a přidělením delšího času pro řešení otázek spojených právě s těmito procesy. Dále byla popsána metodika vycházející jak z požadavků normy, tak ze zkušeností z implementací v dalších firmách. Tento dokument neobsahuje specifika projektové metodiky zvolené pro konkrétní implementace a taktéž stojí na pomezí obecného dokumentu a konkrétních vnitrofiremních předpisů. Proto také pokládám za vhodné jej zveřejnit v plném znění, protože může být inspirací pro další organizace segmentu MSP.
- 68 -
5
Řízení informatických procesů v MSP
V této kapitole je popsána role metodik řízení informatických procesů v MSP. Analýza vychází z hodnocení metodik v předchozích částí práce, specifik MSP, které jsou uvedeny v první části této kapitoly a z příkladu implementace metodiky ISO 20000 ve firmě Inekon Systems. Začátek této kapitoly se zabývá obecným vymezením velikosti podniků, které ovšem není dobře použitelné pro účely hodnocení problematiky, jíž se tato práce zaobírá. Proto jsou v této kapitole definovány kritéria, jež pomohou při hodnocení vhodnosti implementace některé z výše probíraných metodik. V poslední části této kapitoly je provedeno hodnocení možnosti uplatnění ITIL a ISO 20000 v MSP.
5.1
Charakteristika malých podniků
Rozdělení kategorií podniků podle velikostí není zcela zřejmé a jednoduché. Různé organizace vládní i soukromé používají svoje kritéria. Navíc i badatelé přistupují k malým a středním podnikům jako k jednomu segmentu, což jak bude zmíněno dále je pro tuto práci velmi zásadní nedostatek. V ekonomických publikacích se setkáváme s definicemi velikosti firem na základě kvantitativních údajů. Sleduje se zejména počet zaměstnanců a roční obrat. Např. podle Evropské komise [KOL99] : počet zaměstnanců obrat celková hodnota aktiv nezávislost Počet zaměstnanců představuje hlavní kritérium, ostatní mají doplňkový význam. Např. obrat nelze použít jako jediné kritérium, neboť podniky z oblasti obchodu a distribuce mají obecně vyšší obrat než např. výrobní podniky. Mikro podniky •
méně než 10 zaměstnanců
Malé podniky •
méně než 50 zaměstnanců a dále buď roční obrat nepřekračující 7 mil. EUR
- 69 -
nebo celkovou roční bilanční sumu nepřekračující 5 mil. EUR •
splňují kritérium nezávislosti
Střední podniky •
méně než 250 zaměstnanců a dále buď roční obrat nepřekračující 40 mil. EUR nebo celkovou roční bilanční sumu nepřekračující 27 mil. EUR
•
splňují kritérium nezávislosti, což znamená, že není více než 25% kapitálu a hlasovacích práv ve vlastnictví jiného subjektu.
Pro podmínky v ČR jsou podstatná především kriteria: počet zaměstnanců a nezávislost. Obrat a hodnotu bilančních aktiv lze očekávat podstatně nižší. Pro účely této práce je vhodnější definovat velikost poskytovatele. Z tohoto hlediska by pak mohlo zůstat hledisko počtu zaměstnanců a obrat by se zaměnil za hodnotu informačních aktiv podniku. I takové členění je velmi hrubé a je potřeba jej dále specifikovat a to právě službami, které jsou poskytovány. Jejich náročností a počtem zákazníků. Jelikož je těchto hledisek kvantitativních i kvalitativních mnoho, je bezpředmětné určovat nějaké hranice, kdy je pro poskytovatele vhodné implementovat některou ze zde popisovaných metodik řízení informatických procesů. Navíc i definice služby nemusí přesně odpovídat tomu, co poskytovatel produkuje a přesto je pro něj metodika vhodná. (O této problematice více v kapitole 4). V následujících kapitolách jsou popsána specifika malého poskytovatele, která jsou někdy v konfliktu s normami a třeba pečlivě vážit dopad implementace metodik do prostředí. Pokud se jedná o střední poskytovatele, tam je situace z hlediska složitosti řízení podobná spíše velkým poskytovatelům a problém se posouvá spíše do oblasti, kterou metodiku zvolit, než zda se jimi vůbec zabývat, jako je tomu u malých.
5.1.1
Organizační struktura
Organizační struktura malých poskytovatelů, bývá velice plochá a pružná. Jednotliví zaměstnanci mají přehled o dění v organizaci. Je běžné, že se osobně znají všichni zaměstnanci včetně vedení. Je také běžné, že jeden zaměstnanec vystupuje ve více rolích. Proto, je třeba zajistit, aby tyto role byly slučitelné. To je velký rozdíl oproti pracovníkovi velké firmy, který zastává jen jednu roli nebo pouze její část. Celkově to znamená, že proces by měl být spíše pružný než komplexní. Dalo by se dokonce říci, že jednoduchost procesu by měla mít větší váhu než popis detailních činností. Jednou z nesporných výhod, jež poskytuje výše zmíněná plochá organizační struktura, je schopnost rychlé reakce malého poskytovatele na změny a další podněty z okolí. Podněty od pracovníků se díky osobním vztahům dostávají velmi rychle k nejvyššímu vedení. To klade specifické požadavky na řídící procesy u malých poskytovatelů. Ty by neměly vytvářet zbytečně pevné struktury
- 70 -
s potřebou rozsáhlé byrokracie31. Na procesy vznikají dva protichůdné tlaky. Jeden je, aby proces byl komplexní, aby mohl postihnout všechny možné situace a odpovídal normě, opačným směrem působí požadavek na jednoduchost jeho používání a správu. Definování řídících procesů zahrnujících
best practice může být výhodné pro malého
poskytovatele, který se chystá na svůj růst. Dosavadní manažerské zkušenosti se mohou u vedoucích pracovníků obohatit o postupy obsažené ve zvolené metodice normě. Na druhou stranu pokud
organizace
využívá
nějaké
nestandardní
postupy,
mohou
se
tyto
necitlivým
přizpůsobováním procesu normě ztratit.
5.1.2
Management
Role vrcholového managementu je rozhodující v každém větším ICT projektu. Ať už podnět k řešení vzniklé situace dostane vedoucí pracovník od svých podřízených nebo obchodních partnerů, případně z vlastní iniciativy, vždy to bude on, kdo bude rozhodovat a nést odpovědnost. Mnoho projektů skončilo neúspěchem právě díky nezájmu vyššího managementu. V případě implementace metodik managementu služeb to platí dvojnásob.
5.1.2.1 Osobnosti Většina malých firem je vedena jejich majiteli a zakladateli. Tito lidé rozhodují o všech důležitých událostech a do určité velkosti firmy řídí i běžný provoz. Většinou se jedná o tvůrce podnikatelského záměru a odborníky v daném oboru. Jejich osobnostní charakteristiky ovlivňují jejich způsob vedení firmy i celý vývoj v podniku. Jsou to oni, kdo by měl jako první rozhodovat o ICT a způsobu jeho řízení . Pokud se nejedná o konzultační firmu oblasti ITSM, nelze předpokládat hluboké znalosti metodik řízení informatických procesů . Proto je pro ně komplikované je hodnotit a rozhodovat o jejich implementaci. Další překážka může být přímo v osobnostních charakteristikách vedoucích pracovníků. Většinou jsou to lidé, kteří si svou firmu sami vybudovali a jsou na ní pyšní. Konzultační firma se je pak snaží přesvědčit, že by se měli chovat jinak a používat jiné přístupy. Jedna z hlavních kompetencí člověka (ať již je to zaměstnanec organizace či vnějšího subjektu) odpovědného za implementaci nových řídících procesů by měla být schopnost jednat s lidmi a vtáhnout je do projektu, který pro ně může být nesnadný a rizikový.
5.1.2.2 Včasné rozhodnutí K již zmíněným komplikacím managementu musíme započítat další. I kdyby byl manažer schopen sám posoudit dopady implementace managementu ICT služeb podle některé z prezentovaných metodik, jedním ze základních kamenů úspěchu je i včasné rozhodnutí, kdy tento krok provést. 31
Je totiž mnohem snadnější, dojít za nadřízeným osobně, než podávat návrhy prostřednictvím vstupního formuláře do Change management procesu nebo do procesu neustálého zlepšování.
- 71 -
Uvádí se, že velkým společnostem trvá přijetí nových řídících procesů přibližně dva roky, i kdyby u malých firem tato doba byla poloviční, je naprosto stěžejní naplánovat tuto aktivitu v dostatečném předstihu před dalšími strategickými změnami, především růstem společnosti. Pokud by došlo k souběhu zavádění strategických změn a zvýšenou produkcí firmy, mohlo by dojít ke kolapsu.
5.1.3
Strategické řízení
Podle studie Fredericka A. Frosta [FRO] o používání nástrojů strategického rozhodování, jsou tyto v malých a středních firmách používány velmi okrajově. Ačkoli zkoumané firmy byly z Austrálie a jihovýchodní Asie, lze předpokládat, že stav v ČR bude podobný, ne-li horší. Ze zkoumaných 783 podniků mělo strategický plán pouze 193 (24,6%). Protože do průzkumu byly zahrnuty i střední podniky, lze předpokládat, že procento malých firem, které mají stanoven strategický plán bude ještě menší. Protože metodiky řízení informatických procesů patří ke strategickým nástrojům, lze odvodit, že jejich používání v segmentu MSP není nijak masově rozšířené. To nakonec dokreslují i ankety provedené na konferenci Systémová integrace [BRU06], [POU07].
5.2
ITIL pro malé podniky
V této kapitole bych se chtěl zabývat vhodností ITIL pro malé podniky ve srovnání s ISO 20000. Spíše než možnostmi a aspekty vlastní implementace bych chtěl prodiskutovat otázku schopnosti vůbec projekt uskutečnit. Podmínky v malých firmách jsou popsány v jiných částech této práce a tomto místě z nich budu vycházet. Asi největším problémem je samotná znalost metodiky a to na manažerské úrovni, aby někdo mohl říci, zda se projekt může uskutečnit a zda má šanci přinést požadované výsledky. Jak vyplývá z předchozích kapitol popisu a hodnocení, ITIL je velmi rozsáhlý avšak zůstává na vysoké úrovni abstrakce. Proto aniž bych chtěl management malých firem podceňovat, už pro zhodnocení možností projektu jsou potřeba vysoce odborné znalosti. Je tedy více než pravděpodobné, že je pro malé podniky prakticky nemožné zaměstnávat ITIL odborníky pro svou vnitřní potřebu. Pokud se firma rozhodne zavádět principy ITSM, je zřejmé, že tak bude činit ve spolupráci s konzultační firmou. V tomto ohledu bych velké rozdíly mezi oběma metodikami neviděl, snad jen, že pro ITIL je většina materiálů v anglickém jazyce, což znamená, že pokud by organizace chtěla české materiály, musela by se spolehnout na překlady konzultační firmy. Nutno dodat, že text ISO 20000, ačkoli je v jedné publikaci česky i anglicky, není také nijak lehké čtení. Výchozí situace je tedy pro obě normy podobná. Proč tedy doporučují spíše ISO 20000? Odpověď je poměrně jednoduchá, protože ISO říká, že musíte. Dává (v rámci možností) jasné podmínky, co je třeba splnit a jaké jsou podmínky pro soulad. Na první pohled se to může zdát příliš jednoduché, ale je třeba si uvědomit, že malá firma může pro projekt implementace vyčlenit pouze omezené zdroje. Nelze příliš počítat s tím, že by byl vyčleněn pracovník, který by se projektu mohl věnovat
- 72 -
naplno, takže v případě potřeby, která je samozřejmě neustálá, dá přednost aktuálním pracovním povinnostem na projektu, který je hlavním podnikáním firmy. Samozřejmě, že vlastní projekt implementace ISO 20000 je tímto problémem ohrožen také, nicméně získání certifikátu (viz. dále) je velmi silná motivace, zejména pro manažery. Jejich čas a získání pro projekt je totiž naprosto klíčové, neboť oni musí stanovit cíle, politiky a metriky jednotlivých procesů i celého projektu, co ž je velmi náročná práce u obou metodik. V zásadě lze říci, že možnosti a problémy obou přístupů jsou podobné, ale pro malou firmu 32 je v certifikaci velký marketingový potenciál. Protože si nemůže dovolit rozsáhlé reklamní kampaně a nemůže počítat s tím, že by její produkt byl všeobecně známý, může touto cestou dát najevo, že je spolehlivá a že zákazníci nemusí mít strach poptávat její služby. Zároveň je to prostředek, který přiměje organizaci certifikované postupy nejen zavést, ale i udržovat. Znamená to tedy, že malé firmy by se neměly o ITIL vůbec zajímat? To rozhodně ne, neboť v některých případech, kdy by se jednalo pouze o zavedení jednoho33 nebo několika málo procesů může být flexibilita této metodiky nespornou výhodou. Využití ITIL pro malé podniky tedy vidím především jako podklad a benchmark pro zaváděné procesy ISO 20000 a jako „výkladový“ slovník ITSM problematiky, kdy zejména nenověji publikovaná verze nabízí dostatek materiálů a podnětů k zamyšlení se nad úlohou ICT v rámci organizace a plnění jejích strategických cílů.
5.3
ISO 20000 pro malé podniky
Vhodnost pro MSP je třeba vnímat ve dvou rovinách. V první rovně jde o vhodnost procesního řízení informatiky a tedy o ITSM normy obecně. Zde je potřeba zvážit především obor organizace a přínosy, které může implementace mít. Ekonomicky může mít implementace dva druhy přínosů. Jednak je to zvýšení příjmů z vyšší efektivnosti informatických procesů a dodávání požadovaných služeb v požadované kvalitě, což je obecně těžko měřitelná veličina a této problematice se zde věnovat nebudu, pouze obecně. Záleží, jak moc je výsledný produkt firmy informaticky náročný. Na jedné straně jsou organizace poskytující služby ICT svým zákazníkům, na druhé straně jsou organizace, které s ICT nemají nic společného. Tam, kde je produkt informaticky náročný, lze očekávat větší přínos. Na druhé straně může být přínosem úspora nákladů efektivity a přehlednosti řízení informatických procesů uvnitř organizace. Vzhledem k velikosti firem, které zde jsou předmětem zkoumání je otázkou, zda náklady na implementaci a řízení procesů poskytování ICT služeb mohou být nižší než úspory. Oba druhy přínosů jsou samozřejmě závislé na výchozím stavu procesů v podniku a na stupni zralosti, kterého vlivem používání metodiky pro jejich řízení firma dosáhne. Druhou rovinou je hodnocení, kterou normu implementovat. Tady bych se přikláněl spíše k ISO neboť vzhledem k diskutabilnosti ekonomických přínosů je velkým přínosem prezentace 32 33
Zvlášte pak pro tu, jež se zabývá poskytováním ICT služeb. Ačkoli u jednoho to nikdy neskončí.
- 73 -
certifikátu. Navíc norma obsahuje konzistentní celek procesů a dá tak předpoklady k úspěšné organizaci informatiky i v případě růstu společnosti. Zatímco implementace jednotlivých ITIL procesů může z hlediska dalšího růstu organizace přinést značnou rozkolísanost uvnitř tohoto odvětví. A proto bych ITIL doporučoval jen ve výjimečných případech.
5.4
Cíle implementace ISO 20000
Stanovení cílů implementace je samozřejmě jedním z nejdůležitějších kroků, neboť projekt může proběhnout úspěšně, ale pokud byly stanoveny špatné cíle, jeho přínosy nebudou valné. A již v tomto kroku se metodiky rozcházejí. Zatímco ITIL směřuje spíše k postupnému implementování procesů na základě zhodnocení, co firmu nejvíce trápí, ISO 20000 požaduje implementaci procesů všech. Z tohoto hlediska je tedy poněkud jasnější situace, pokud je hlavním cílem získat certifikát. Tato otázka má ovšem další souvislosti. Protože pokud jde o ISO, nabízejí se dvě cesty. Jedna, která má za hlavní cíl získání certifikátu a druhá, jejímž cílem je implementovat procesní řízení a systém zlepšování kvality. Nejde zde o samotnou definici cílů, neboť ty jsou v obou případech minimálně formálně shodné, ale spíše o definici přínosů. V zásadě lze konstatovat, že jakýkoli ICT provoz požadované procesy provádí, i když je nemá formálně definované. Jak již bylo řečeno v kapitole o ITIL, ITSM procesy nejsou něco nového, ale v mnoha organizacích jde spíše o formální rozpoznání procesů, neboť činnosti, jež jsou jejich obsahem musí tak jako tak v nějaké formě provádět. Ať již je to vztah se zákazníky, dodavateli, Change management, Capacity management, i funkce help desku. Dotaženo do absurdity tyto činnosti vykonává každý uživatel PC. Tím zjevným rozdílem je tedy hlavně dokumentace procesů a systém jejich řízení. A právě v tomto bodě mohou nastat dvě situace. Pokud se organizaci jedná v podstatě pouze o certifikaci, bude projekt spíše o pořízení potřebné dokumentace a pravidel zacházení s dokumenty. Změny na chod firmy mohou být celkem minimální a spíše formálního charakteru. Druhá cesta spočívá v opravdové implementaci řízení procesů, kdy stejně důležitým nebo důležitějším cílem než získání certifikátu, je zvýšení efektivity a efektivnosti procesů spolu se systémem neustálého zlepšování. Oba přístupy se tedy napovrch jeví shodně, nicméně rozdíl je zcela zásadní. První přístup zakonzervuje stávající procesy ve firmě34 a navíc přidá nutnou administrativu pro splňování požadavků normy. V zásadě tedy nelze očekávat zlepšení a přibudou pouze náklady. Samozřejmě jsou tu i výhody a to malé riziko, spojené se změnami, které nenastanou a samozřejmě menší náklady projektu implementace. Tento postup lze zvolit, pakliže je organizace se svými procesy spokojená, jsou dostatečně zralé nebo se jedná o „doplňkovou“ certifikaci zavedených ITIL procesů. 34
Protože jejich změna bude složitější minimálně díky nutné administrativě.
- 74 -
Z uvedeného vyplývá, že druhý způsob je samozřejmě náročnější riskantnější a nákladnější, ale zato může přinést pozitivní efekty. Nebezpečí zde spočívá především v přijímání změn v řízení společnosti, změny ve firemní kultuře, jež mohou mít dočasně vliv i na vlastní core business. Vyšší budou i náklady spojené s analýzami, stanovováním strategií jednotlivých procesů, metrik, způsobů měření. Náklady nejsou jen peněžní např. za konzultační služby, ale i čas zaměstnanců a především managementu, který musí o těchto záležitostech rozhodovat a to pokud možno ne pouze formálně.
5.5
Závěr
V této kapitole byly diskutovány problémy MSP s použitím metodik pro řízení informatických služeb. Vyšel jsem z obecných podmínek managementu v tomto segmentu podniků a jejich vztahu ke strategickému řízení neboť z obou těchto principů vychází i vztah MSP k probíraným metodikám. Především je důležité zmínit, že místo velikosti organizace je třeba se zaměřit na to, jakou roli informatika ve fungování podniku hraje. Aby mělo pro podnik smysl zabývat se řízením informatiky na úrovni prezentovaných metodik, musí být informatika pro podnik zcela zásadním zdrojem přesahujícím provozování běžných kancelářských aplikací a účetního SW. Na základě porovnání ITIL a ISO 20000 bych pro MSP ve většině případů doporučil ISO 20000, neboť obsahuje ucelenou sadu procesů a umožňuje jejich certifikaci. To by mělo zaručit, že organizace implementuje všechny potřebné procesy a zároveň získá certifikát, který může využít pro svůj marketing. To ovšem neznamená, že by pro MSP nebyl ITIL důležitý. Je třeba ho vnímat především jako pomůcku pro objasnění smyslu procesů a jejich náplně. Ve specifických případech lze samozřejmě aplikovat vybrané procesy ITIL a to především tam, kde je potřeba udržovat několik stěžejních procesů a ostatní nemají pro organizaci význam. Ovšem nejdůležitějším závěrem této kapitoly je, že aby implementace ( a´t už jakékoli normy) byla pro organizaci přínosná, je třeba jasně stanovit cíle a přínosy, kterých má být touto aktivitou dosaženo. Jedná se především o to, aby procesy a související aktivity byly nejenom definovány a dokumentovány, ale především aktivně používány. To předpokládá nejen dostatek času a zdrojů pro projekt implementace, ale především aktivní zapojení všech zaměstnanců, kteří budou danými procesy dotčeni a to hlavně manažerů, kteří budou organizaci pomocí těchto procesů řídit.
- 75 -
6
Závěr
Na základě provedených analýz lze konstatovat, že vztah MSP k metodikám řízení informatických procesů je třeba posuzovat především podle kvalitativních vlastností jejich způsobu využívání informatiky. Jak vyplývá ze závěrů předchozích kapitol, masivního rozšíření se v segmentu MSP v nejbližší době asi nedočkáme. V práci byly probrány dvě hlavní metodiky řízení informatických procesů, které spolu navíc velmi souvisejí. U obou bylo provedeno hodnocení jejich vhodnosti pro MSP, ze kterého vyplývá, že ačkoli je u obou metodik deklarováno, že jsou vhodné pro všechny typy organizací, je třeba jejich aplikaci v MSP velmi uvážit, protože zejména pro malé podniky jsou přínosy implementace těchto norem přinejmenším diskutabilní a to jak z hlediska zvýšení přínosů z informatiky, kdy je možno toto očekávat pouze u ICT firem, tak z hlediska nákladů, kdy je potřeba velmi poměřovat náklady a rizika implementace s možnými úsporami. Je třeba si uvědomit, že při nákladech a rizicích takového projektu jsou pro MSP zajímavé úspory v řádech desítek procent, zatímco pro velké firmy mohou být zajímavé úspory již v řádech jednotek procent. Nicméně pokud bych měl osobně některou normu doporučit, tak to vzhledem k diskutovaným okolnostem bude ISO 20000, protože vyžaduje přijetí uceleného konceptu řízení informatiky a protože umožňuje certifikovat organizaci, což může mít pozitivní marketingové efekty. ITIL by se dal doporučit ve specifických případech, kdy je potřeba rychle dosáhnout pokroku v nějakém stěžejním procesu, který má významný dopad na chod podniku. Protože však ITIL nevyžaduje splnění pevně daného okruhu oblastí, může zavedení jen některých procesů firmu spíše rozkolísat a přinést další neočekávané náklady na rozhraních, kde procesy řízeny jsou a kde nejsou. Hlavní cíl práce, kterým bylo vyplnění mezery mezi obecným zněním normy ISO 20000 a detailním projektem implementace řídících procesů dle této normy se podařilo splnit. Splnění představuje vypracovaná metodika implementace ISO 20000 pro firmu Inekon Systems s.r.o., jež je obsažena v kapitole 4.2. Metodika vychází z analýz provedených v teoretické části práce, jež spočívaly zejména v zařazení metodik řízení informatických procesů do obecného rámce IT Governance, analýzy dopadu jejich použití na řídící procesy organizace a porovnání dvou hlavních norem ITIL a ISO 20000. Pro úspěšnost projektu je nejvíce zapotřebí uvědomit si jeho místo mezi ostatními činnostmi podniku. Z hlediska zařazení se jedná o strategický projekt, protože se týká řízení a ovlivňuje výsledky jednoho ze stěžejních útvarů podniku. Proto by měl získat dostatečné zdroje i čas vedoucích pracovníků, kteří rozhodují o cílech a přínosech celého projektu i jednotlivých částí. Vedoucí projektu ať již externí nebo interní by měl především prohovořit se sponzorem jeho očekávání a cíle, které by měl projekt přinést. A to samozřejmě na začátku projektu, ale i dále v jeho průběhu. Jak bylo popsáno výše, ISO 20000 je natolik obecné a připouští značnou míru - 76 -
volnosti, že můžeme dojít k různým výsledkům implementace při splnění všech závazných podmínek normy. Proto by měl po fázi plánování proběhnout další rozhovor o cílech implementace, který povede k redefinici hlavních přínosů tedy buď pouze certifikace nebo zavedení efektivního managementu ICT služeb a certifikace. Jedná se o dva odlišné postupy. Není třeba připomínat, že takový rozhovor může být značně problematický zejména pro externího vedoucího projektu, ale je to poslední příležitost, kdy je možno dále pokračovat v projektu tak, aby přinesl očekávané přínosy za stanovených nákladů a míry rizika. Pro další rozvoj tohoto tématu po teoretické stránce by bylo vhodné uskutečnit průzkum zaměřený na metodiky řízení informatických procesů v MSP. Po praktické stránce by velkým přínosem bylo vypracování uceleného postupu, který by vhodně kombinoval metodiku implementace s projektovou metodikou, které se normy vyhýbají.
- 77 -
7
Přílohy
7.1
Použitá literatura
Monografie [CAR04] Cartlidge, A., Hanna, A., Rudd, C., Macfarlane, I., Windebank, J., Rance, S. An Introductory Overview of ITIL. The IT Service V3 Management Forum Ltd Wokingham: 2004 ISBN 0-9551245-8 -1 [DAR97]Darnton, G., Darnton, M. Business Process Analysis. London: International Thomson Business Press, 1997 ISBN 1 86152 039 5 [GRA08]Grasseová, M., Dubec, R., Horák, R. Procesní řízení ve veřejném sektoru. Brno: Computer Press a.s., 2008 ISBN 978-80-251-1987-7 [KOL99]Kolektiv autorů. Podnikání v malé a střední firmě. Praha: Vysoká škola ekonomická v Praze Fakulta podnikohospodářská, 1999. ISBN 80-7070-707 [MOL00]MOLNÁR, Z. :Efektivnost informačních systémů , Grada, Praha, 2000 ISBN: 807169410 [OGC02]Office of Government Commerce. Planning to implement service management [CD-ROM] . London : The stationery office, 2002 ISBN 0 11 330877 9 [OGC07a]Office of Government Commerce. Service Design .
London : The stationery office,
2007 ISBN 0 11 3310471 [OGC07b]Office of Government Commerce. Service Transition .
London : The stationery office,
2007 ISBN 0 11 3310455 [OGC03]Office of Government Commerce. Service Delivery [CD-ROM].
London : The
stationery office, 2003 ISBN 0 11 330017 4 [OGC00]Office of Government Commerce. Service Support [CD-ROM]. office, 2000 ISBN 0 11 330015 8 - 78 -
London : The stationery
[RUD04]Rudd, C. An Introductory Overview of ITIL. The IT Service Management Forum Ltd Wokingham: 2004 ISBN 0-9543521-9 -X [SEB05]Šebestová, M.; Váňa, V.; Sedláček, M. Management služeb IT, Komentované vydání souboru ISO/IEC DIS 20000:2004. Praha : Český normalizační institut, 2005. ISBN 80-7283-186-0
[SVA07]Svatá, V., Audit Informačního systému, Praha: Vysoká škola ekonomická v Praze, 2007 ISBN 80-245-0978-X [VOR97]Voříšek, J., Strategické řízení informačního systému a systémová integrace Praha: Management Press 2002 ISBN 80-85943-40-9 Články [BRO08]Brown, D., ITIL V2 to V3 – Is it worth it? [online]. Axiom systems Best Praktice whitepaper, 2008
[cit. 2008-04-13]
Dostupný z WWW:
/ po zaregistrování [BRU06]Bruckner, T., Trojan, Z. Výsledky výzkumu k řízení informatiky provedeného na konferenci SI 2006 [online]. Systémová integrace 3, 2006 [cit. 2008-04-20]. Dostupný z WWW: <
http://www.cssi.cz/cssi/vysledky-pruzkumu-k-rizeni-informatiky-provedeneho-na-konferenci-
si-2006 > [FRO]Frost, F., A.
The use of strategic tools by small and medium-sized enterprises: an
Australasian study Strategic Change roč.12, č1 str. 49 [LAC08]LaCava, C. J. ISO/IEC 20000:Proven and practical implementations. [online].
INS
Whitepaper,2008[cit.2008-04-10].Dostupný z WWW: [LIT05]Litten, K. Five Steps to implementing ITIL. [online].
INS Whitepaper, 2005[cit.
2008-04-10]. Dostupný z WWW: [POU07]Pour, J., Voříšek, J. Výsledky průzkumu řízení informatických služeb V ČR [online]. Systémová integrace 2, 2007 [cit. 2008-04-20]. Dostupný z WWW: < http://www.cssi.cz/cssi/vysledky-pruzkumu-rizeni-informatickych-sluzeb-v-cr>
- 79 -
[SEB]Šebestová, M., Sedláček, M. Jak probíhá audit managementu poskytovaných IT služeb při certifikaci podle ISO/IEC 20 000? [online]. [cit. 2008-04-13]. Dostupný z WWW: [SME91]Smeltzer, L., R. An Analysis of Strategies for Announcing Organization-Wide Change [online]. Group & Organization Studies (1986-1998) 3, 1991, ABI/INFORM Global Dostupné z ProQuest [TRA06]Trahant, B., T. Communication: The Key to Sustainable Government Transformation [online]. Public Manager, podzim, 2006 pg. 13, ABI/INFORM Global Dostupné z ProQuest [WHI06]White, A., Baselining ITSM [online]. Proactive services, 3, 2006 Dostupný z WWW: < http://whitepapers.zdnet.com/abstract.aspx?&q=baselining&docid=166723 > po zaregistrování [ZID06]Žid, N. Procesní řízení kontra organizační struktury a funkce [online]. Systémová integrace 3, 2006 [cit. 2008-04-20]. Dostupný z WWW:< http://www.cssi.cz/cssi/procesni-rizeni-kontraorganizacni-struktury-funkce > Diplomové práce [KRI07]Křivka, F. Procesy a nástroje řízení projektových rizik. diplomová práce VŠE v Praze, obhajoba 14.6. 2007 [VLC07]Vlček, D. Management služeb IT (ISO 20000) v Iterity s.r.o. diplomová práce VŠE v Praze, obhajoba 12.9. 2007 [VLC06]Vlčková, D. Teoretické koncepce a podnikatelské vize ITSM. diplomová práce VŠE v Praze, obhajoba 13.6. 2006
- 80 -
7.2
Terminologický slovník
Termín Best practice Information Systems
Zkratka
Význam [zdroj]
ISACA
Nejlepší zkušenost [autor] Vlastní metodiky COBIT [www.isaca.org]
ITSM
Oblast zabývající se řízením podnikové informatiky [autor] Řízení služeb ICT [autor]
Audit and Control Association IT Governance Information Technology Service Management MSP Malý poskytovatel Politika
Malé a střední podniky [KOL99, str. 7] Poskytovatel služeb definovaný v kapitole 5.1 [autor] Strategické cíle a úkoly procesu, které definuje vlastník
Poskytovatel služeb
procesu. [autor] Organizace usilující o dosažení shody s ISO/IEC 20000, může se jednat o oddělení v rámci organizace, které poskytuje služby vlastní organizaci i cizím zákazníkům. Poskytovatelem může být i celá organizace. [autor] Skupina podpory pro první kontakt se zákazníkem, která
Service desk
provádí vysoký podíl celkových podpůrných prací. Service Level Agreement Zákazník
SLA
[SEB05, str.9] Písemná smlouva mezi poskytovatelem služeb a zákazníkem, která popisuje odsouhlasené úrovně služeb. [OGC02] Konzument služeb, které dodává poskytovatel. Může to být část organizace jejíž součástí je i poskytovatel nebo se může jednat o cizí organizaci/osobu [autor]
- 81 -
7.3
Auditované dokumenty při certifikaci podle ISO 20000
- 82 -
Tabulka 7 Auditované prvky při certifikaci ISO20000 Zdroj:[SEB]
- 83 -
7.4
Požadavky na odbornou způsobilost pro konzultanta a auditora normy ISO 20000
Požadavky na odbornou způsobilost auditora certifikačního orgánu v oblasti systému managementu podle normy ISO/IEC 20000
Vysokoškolské vzdělání, pracovní zkušenost v oblasti IT, absolvování kurzů se zaměřením na informační technologie
Splnění požadavků ISO 19011 na auditora včetně absolvování nejméně 40 denního školení auditování systémů managementu
Absolvování
školení
ISO/IEC
20000
pro
externí
auditory
vedené
školitelem
akreditovaným itSMF International, včetně úspěšně složené zkoušky
Podmínkou přijetí na výše uvedené školení ISO/IEC 20000 je minimálně 3letá zkušenost s auditováním v oblasti IT a zároveň certifikace auditora pro ISO9001, BS7799, ISO27001, TickIT nebo certifikace interního auditora
Absolvování minimálně 2 kompletních auditů systému managementu IT služeb v roli auditora v zácviku včetně plánování auditu, psaní zpráv,
přezkoumání dokumentace
celého
případu
Pozn: Tato informace je založena na požadavcích institucí, které na národní nebo mezinárodní úrovni stanovují kvalifikační a certifikační schémata pro ISO/IEC 20000 (Český institut pro akreditaci a itSMF International)
Základní doporučení pro osoby zvažující certifikaci na ISO/IEC 20000 Consultant Certificate 1.
Seznamte se podrobně s požadavky ČSN ISO/IEC 20000
-
část1: Specifikace –je
k dispozici v českém překladu (norma je dvojjazyčná pro snadnější srozumitelnost přeložených termínů) . Pokud jste to ještě neudělali, seznamte se s obsahem knihovny ITIL, doporučujeme získat alespoň Foundation Certificate. 2.
Zvažte, jaký typ certifikace je pro Vás potřebný – zda je to certifikace na auditora nebo konzultanta. Tyto dvě činnosti se totiž navzájem vylučují, nelze je vykonávat současně bez konfliktu zájmu a norma takovou činnost explicitně zakazuje. Auditor je členem organizací, které jsou označovány jako Registered Certification Bodies (RCB) a které provádějí vlastní audit na ISO/IEC 20000. Konzultant je buď zaměstnanec auditované organizace nebo organizace, poskytující poradenství či školení před vlastním auditem.
3. Pokud jste zvolili konzultantský certifikát, následujícím krokem je výběr organizace, která poskytuje akreditovaná školení (Accredited Course Providers, ACP), viz. seznam na http://www.isoiec20000certification.com/lookuplist.asp?Type=8 . 4.
Akreditovaný poskytovatel školení na ISO/IEC 20000 Consultant Certificate musí postupovat podle pravidel, stanovených itSMF, především se musí řídit závazným
- 84 -
kvalifikačním
schématem:
http://www.isoiec20000certification.com/qualification/index.asp . 5. Součástí akreditovaného školení je povinně i zkouška, která má dvě části: a.
Multiple Choice Questions – otázky s výběrem odpovědí ze seznamu
b. Written Assignment – volný text, odpovědi na otázky podle případové studie Druhá část se do značné míry podobá písemné zkoušce na ITSM Manager‘s Certificate pro ITIL V2. Zkušenosti z ITSM Manager‘s zkoušky jsou výhodou, ovšem nejsou podmínkou. Pro úspěšné vykonání zkoušky je potřeba získat více než 50% z každé části a současně dosáhnout více než 65% v součtu z obou částí. Výsledky je Vám povinen poskytovatel školení dodat do 6 týdnů ode dne konání zkoušky. V případě neúspěchu lze požádat o opakování celé zkoušky nebo jedné části zkoušky. Zdroj: ITSMF CZ
7.5
Hodnocení efektivnosti investic do ICT a jejich přínosu podnikatelským aktivitám dle COBIT.
Postup byl stanoven na základě dokumentů: ISACA Cobit Audit guidelines AI1, DS2, DS6, PO5 Dílčí cíle: • •
• • • •
Zmapovat veškeré investice do ICT. Zjištění počtu uživatelů a nákladů na uživatele. Zjištění měřitelných přínosů informačních systémů. Zmapování podnikových procesů, které jsou pomocí ICT automatizovány. Porovnání nákladů na ICT podle nákladů běžných u podobné (a úspěšné) firmy na trhu. Benchmarking efektivity. Zjištění historické vazby mezi ziskovostí společnosti a investicemi do ICT. Jsou ICT procesy a procedury nastaveny vhodně z hlediska detailního monitoringu nákladů? Je vytvořen roční plán priorit v ICT? Jak často je reportováno Identifikace příležitostí k snížení nákladů. Existuje metodologie pro přidělování zdrojů.
•
Zjištění zda existující politiky a postupy splňují že :
• • •
- 85 -
o o o o o o o o o o
o o o o o o o o o o o o o
Uživatelské požadavky, které jsou uspokojovány stávajícím nebo novým/změněným systémem, jsou jasně definovány před tím, než je schválen vývoj, implementace nebo změna systému Dokumentace s uživatelskými požadavky je posouzena a schválena poučeným vlastníkem/sponzorem před odsouhlasením vývoje, implementace nebo změny systému Funkcionalita a provozní nároky řešení jsou uspokojeny včetně výkonu, bezpečnosti, spolehlivosti, kompatibility a legislativy Alternativní řešení uživatelských požadavků jsou prozkoumány a analyzovány před výběrem SW řešení. Před konečným výběrem jsou brány v potaz všechny softwarové balíky, jež jsou schopny uspokojit uživatelské potřeby. Možnosti pořízení software jsou jasně definovány v těchto skupinách, krabicový SW, interní vývoj, přímý kontrakt, úprava existujícího SW, nebo kombinací těchto výše uvedených. Pro všechny možnosti uspokojení uživatelských potřeb ustanovených pro návrh modifikace systému nebo pro nový systém je připravena, analyzována a schválena poučeným vlastníkem/sponzorem technická studie proveditelnosti. V každém navrženém vývojovém, implementačním nebo změnovém projektu systému je provedena analýza nákladu a přínosů pro každou uvažovanou variantu uspokojení uživatelských potřeb. Je věnována pozornost podnikovému datovému modelu při posuzování proveditelnosti jednotlivých řešení. V každém navrženém vývojovém, implementačním nebo změnovém projektu systému je připravena a dokumentována analýza bezpečnostních hrozeb, potenciálních zranitelností a dopadů a vhodných bezpečnostních a vnitřních kontrolních mechanismů pro snížení nebo zamezení zjištěného rizika. Náklady a přínosy bezpečnostních opatření jsou pečlivě prozkoumány, aby byla jistota, že náklady nebudou vyšší než přínosy. Vedení organizace formálně potvrzuje studii nákladů/přínosů. Vhodné kontrolní mechanismy je třeba vkládat do všech nově navržených modifikací systému v průběhu fáze designu projektu. Vhodné kontrolní mechanismy poskytují možnost ochrany uživatele před odhalením a zneužitím jeho identity jiným uživatelem (např. nabídnutím anonymity, pseudinymity) bez ohrožení systémové bezpečnosti. Vedení IT oddělení zjistí všechny systémové programy, které budou uspokojovat jeho provozní požadavky. Produkty jsou kontrolovány a testovány před jejich použitím a dohodou o ceně. Pořizování softwarových produktů odpovídá nákupní politice organizace nastavujíc rámec vznikání požadavků pro návrh, výběr poskytovatele softwaru a vyjednávání kontraktu. Pro licencovaný software získaný od třetích stran mají dodavatelé odpovídající postupy k ověření, ochraně a udržování integrity práv spojených se softwarem. Analýza rizik je provedena podle celkového rámce odhadování rizik. Existují mechanismy přiřazování a udržování bezpečnostních vlastností k exportovaným a importovaným datům a jejich správné interpretaci. Vedení organizace vyvinulo a implementovalo obecný přístup k pořizování majetku popisující běžnou sadu postupů a standardů, jež mají být dodrženy při pořizování HW a SW služeb. V kontraktech je dojednáno, že software, dokumentace a ostatní dodávky jsou testovány a kontrolovány před schválením. Testování zahrnuté ve smluvních ujednáních osahuje testování systému, integrace, HW a komponent, postupů, uživatelského přijetí, zátěžové testy, testy ladění a
- 86 -
o o o o o o o o o o o o o o o o o o o
výkonnosti, návratové testy, a konečně pilotní test celého systému, aby se předešlo jakýmkoli nepředvídaným výpadkům. Existují politiky specificky adresující potřeby pro smluvní ujednání, definice obsahu smluv, vlastník nebo kontraktační manažer odpovědný za zajištění vzniku smluvního ujednání, jejich sledování a změn podmínek podle potřeb. Smlouvy obsahují alespoň následující: Schváleny vedením a právním oddělením Poskytované služby Kvantitativní a kvalitativní SLA Cenu služeb a periodicitu placení Postup řešení problému Pokuty Podmínky odstoupení od smlouvy Ustanovení o změnách Reportování sužeb – obsah, frekvence, a dodávky Role smluvních stran během životního cyklu smlouvy Záruka kontinuity služeb Proces komunikace mezi uživatelem a dodavatelem služby Délka kontraktu Úroveň přístupu poskytnutá dodavateli Bezpečnostní požadavky Záruka utajení (nezveřejnění) Právo na přístup a audit
2. Plán auditu •
• •
Vniknutí do problematiky – porozumění procesům, architektuře organizace, informačním technologiím studiem materiálů a dokumentace , rozhovorem s CIO a ředitelem podniku. Podrobnější studium implementace a využívání informačních systémů(ERP) pomocí rozhovorů s běžnými uživateli a provedení potřebného testování za účelem zjištění, zda používané postupy odpovídají vytčeným dílčím cílům. .Součástí této fáze by mělo být i pochopení systému vnitřních kontrol. Vytvoření seznamu informačních systémů a k nim i zajištěné firemní procesy. Zjistit míru zapojení informačního systému a jeho přínos. Procesy rozdělit na klíčové a podpůrné. Navrhnutí plánu úspor nákladů u málo výhodných informačních systémů s nevýhodným poměrem náklady/přínosy.
Vedení podniku a kompetentní osoby budou
průběžně informováni, aby mohli co nejdříve
přijmout nápravná opatření. Časová náročnost akce bude záviset zejména na dostupnosti dokumentace ( nejen v IT oddělení), její aktuálnosti a stavem jejího využívání.
- 87 -
