Bankovní institut vysoká škola Praha. Katedra informatiky a kvantitativních metod. Řízení rizik IT. Diplomová práce. Bc.

Transkript

1 Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod Řízení rizik IT Diplomová práce Autor: Bc. Regina Sadrieva Informační technologie a management Vedoucí práce: doc. Ing. Vlasta Svatá, CSc. Praha duben 2015

2 Prohlášení: Prohlašuji, že jsem diplomovou práci zpracovala samostatně a v seznamu uvedla veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámená se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Praze Bc. Regina Sadrieva 1

3 Poděkování Ráda bych poděkovala doc. Ing. Vlastě Svaté, CSc. za cenné rady, věcné připomínky a vstřícnost při konzultacích a vypracování diplomové práce. Také bych chtěla poděkovat doc. Ing. Bohumilu Minibergrovi, CSc a Ing. Václavu Šebkovi, CSc za nadstandardně kvalitní výuku předmětu Strategické řízení IS a Plánování a řízení projektů. 2

4 Anotace V diplomové práci je popsáno řízení rizik. Nejužívanější metody analýzy rizik konkrétně Delphi a kvantitativní metody pro počítačové zpracování. Klasifikace rizik finanční/nefinanční, statické/dynamické, čisté/spekulativní. Praktická část je zaměřena na přístupy k řízení rizika ve společnosti X. Klíčová slova: Riziko, klasifikace rizik, metody analýzy rizik, řízení rizik, ISMS, CRAMM, GRC, COSO ERM. Annotation The diploma thesis describes risk management. The most widely used methods of risk analysis in particular Delphi and quantitative methods for computer processing. Classification of risks (non)financial, static/dynamic, clean/speculative. The practical part is focused on approaches to risk management in the company X. Key words: Risk, risk classification, risk analysis methods, risk management, ISMS, CRAMM, GRC, COSO ERM. 3

5 Obsah Úvod Proces a pojmy řízení rizik Základy správy rizik Risk apetit a tolerance Odpovědnost za risk management Povědomí a komunikace Kultura rizik Základy vyhodnocování rizik Dopad na byznys Rizikové scénáře Základy reakce na rizika Indikátory rizik Definice reakcí na rizika a prioritizace Analýza rizik Metoda Delphi Kvantitativní metody pro počítačové zpracováni Softwarové nástroje CRAMM Enterprise Risk Manager GRC Projektová rizika Nejčastější chyby v IT projektech Microsoft Dynamics AX Charakteristika společnosti X před zavedením MS Dynamics AX

6 8.2. Cíle projektu a smluvní zajištění Vybrané moduly Ms Dynamics AX Organizace projektu Rizika projektu Ms Dynamics AX (Axapta) Realizace projektu Předávání systému Školení uživatelů Provoz Výhody a nevýhody implementace MS Dynamics AX Závěrem o projektu zavádění MS Dynamics AX ve společnosti Trendy ERP pro rok Trendy v architektuře IT trendy v ERP Trendy ERP v oblasti implementace Závěr Seznam použité literatury Seznam použitých obrázku Seznam použitých tabulek

7 Úvod V dnešní moderní době výpočetní technika ovládá praktický všechny aspekty života lidí a společností. I profese, které byly dřív vnímány jako ryze rukodělné, v dnešní moderní době vyžadují základní znalost PC. Jestliže dříve lidé považovali za zázrak statické webové stránky, dnes máme možnost sledovat záběry NASA z vesmíru. Jestliže dříve jsme se spokojili s monochromatickými obrázky, dnes máme možnost sledovat animace, které jsou tak kvalitní, že ani expert není schopen je rozlišit od videa. Rychlost internetového spojení je dostačující pro to, abychom pracovali s daty, která jsou fyzický uložena na druhém konci světa. Máme možnost využívat systémy typu ERP v cloudu, nemusíme čekat na implementaci měsíce nebo dokonce i roky, ale stačí i pár týdnů. Efektivita a mobilita, kterou nám přinášejí technologie, jde rukou v ruce s velkým množstvím rizik, které neustále stoupá. Moderní společnost, využívající moderní technologie je doslova obklopena riziky: rizika IT, projektová rizika apod.. Skutečnost je ale taková, že drtivá většina zaměstnanců neví, co to je bezpečnostní politika, neví o možných IT hrozbách a co by se mělo dělat, pokud dojde k bezpečnostnímu incidentu. Drtivá většina podniků se riziky nezabývá, pokud nedojde k incidentu, který způsobí milionové ztráty. Opatření jsou považována za nákladní a neefektivní. V případě projektů skoro vždy se převyšuje rozpočet a časový harmonogram, a výsledný produkt není v požadované kvalitě. Dle statistického výzkumu úspěšností implementace IS: 1 1,5 % projektů bylo použité tak, jak byly dodány 3 % projektů bylo použito po modifikaci 19 % projektů bylo použito a opuštěno 47,5 % dodaných projektů nebylo nikdy použito 29 % projektů nebylo vůbec dodáno Užitečná ale je existence velkého množství rámců, metodik, doporučení a odborné literatury o efektivní identifikaci a managementu rizik. Leč každá mince má dvě strany: na jedné straně 1 Doc. Ing. Bohumil Miniberger, CSc. přednáška z předmětů Strategické řízení IS 6

8 jsou nástroje pro efektivní řízení rizik a velké množství kvalitní odborné literatury, na druhé straně je lenivost a indiference lidí. Na řídicí pozice se dostávají nekvalifikovaní lidé, a pokud o nějakém rámci mají povědomí, tak používají pouze tento rámec, protože studium ostatních rámců a metodik vyžaduje čas, a velmi často i dobrou znalost angličtiny. K efektivnímu a kvalitnímu řízení rizik by se mělo používat více rámců a metodik, které se navzájem doplňují. Druhým extrémem je implementace velkého množství rámců, směrnic a metodik bez ohledu na to, zda je to opravdu zapotřebí. Namísto analýzy současného stavu, identifikaci slabých míst a stanovení cílů, se bezhlavě implementuje všechno, kvůli nařízení mateřské společností, nebo protože to mají konkurenti. Mým cílem bylo zjistit, jaké rámce, metody, SW a postupy řízení rizik existují. Informace jsem čerpala převážně z anglické literatury: rámce Risk IT, publikace od ISACA, PROTIVITI, Microsoft. Také jsem použila několik akademických práci a odborných článků. Abych nepřesáhla rámec diplomové práce, soustředila jsem se jenom na vybrané metody a rámce. V praktické části se diskutuje proces implementace systému ERP, konkrétně Ms Dynamics AX 2012 (Axapta), do středně velké společnosti, poskytující finanční služby. Společnost X jsem si zvolila, protože jsem v ní pracovala. Zaměřila jsem se na specifika a problémy implementace Ms Dynamics AX V dnešní době převládá názor, že výběr vhodného ERP systému, je nejdůležitějším krokem, ale i ten nejlepší systém nevytvoří přidanou hodnotu, v případě že klíčové uživatele nebudou náležitě proškoleny a že proces implementace ERP systému nekončí uvedením do provozu. 7

9 1. Proces a pojmy řízení rizik Proces řízení rizik je založen na několika prvcích, podobně interpretovaných různými rámci a metodikami. Tyto prvky jsou mezi sebou provázány. (2) Aktiva něco, co má měřitelnou/neměřitelnou hodnotu, která musí být chráněna. Hrozba událost, která má za následek poškození systému. Agent hrozby metoda/věc, která využije slabinu aktiva. Událost hrozby je fáze působení hrozby na slabinu systému. Slabina nějaká vlastnost, kterou hrozba může využit, např. neměnné heslo, chybějící kontrola. Prostředky ochrany kontroly/měřítka, zvyšující spolehlivost a odolnost IT služeb. Riziko potenciál využití slabiny aktiva hrozbou, který vede ke zničení aktiva. Residuální riziko riziko, které je spojeno s událostí, v případě kdy kontrola snižuje pravděpodobnost události a bere se to na vědomí. Obrázek 1 Prvky analýzy rizik a jejich vazby. Zdroj: (2) Rizika spojená s IT jsou nedílnou součástí všech rizik podniku. Podniková rizika lze členit na: 8

10 Strategické riziko Riziko životního prostředí Tržní riziko Úvěrové riziko Operační riziko Riziko souladu Velmi často jsou IT rizika považována za součást operačního rizika, jak je tomu v rámci Basel II. Ale i strategické riziko může obsahovat rizika IT, obzvlášť v případech kdy IT hraje klíčovou rolí pro dosažení byznys cílů. Totéž platí i pro úvěrové riziko, kdy špatně zajištěna bezpečnost IT může zapříčinit pokles úvěrových raitingů. IT rizika jsou součástí všech podnikových rizik, což znázorňuje následující obrázek. (8) Obrázek 1 IT riziko v hierarchii rizik. Zdroj: (8) IT riziko je byznys rizikem, obzvlášť v případech kdy je byznys riziko spojeno s využitím IT napříč celým podnikem. Rizika IT mohou být kategorizována různými způsoby, rámec Risk IT nabízí členění IT rizik na: IT Benefit/Value Enablmement Risk je spojeno se ztracenou příležitosti využití technologií ke zvýšení účelnosti a účinnosti byznys procesu. IT Programme and Project Delivery Risk je spojeno s přispíváním IT k novým byznys řešením nebo zlepšení stávajících, obvykle ve formě projektů nebo programů, což se váže k řízení investičního portfolia, kterým se zabývá rámec Val IT. IT Operations and Service Delivery Risk je spojeno se všemi aspekty výkonu IT systémů a služeb, které mohou způsobit destrukci/pokles hodnoty pro celý podnik. Dalším hlediskem je hledisko úrovně řízení rizik: (2) 9

11 Business riziko (celopodnikové) je definováno jako riziko toho, že kvalita kontrolního systému bude negativně ovlivněna, konkrétně: účelnost a hospodárnost provozních aktivit (Operations), soulad s regulacemi (Compliance) a spolehlivost finančního výkaznictví (Fiancial reporting). Riziko IS/IT je definováno jako riziko porušeni kvality IS, konkrétně: porušeni účelnosti (effectiveness), účinnosti (efficiency), spolehlivosti (reliability) a souladu s regulacemi (compliance). Riziko bezpečností informací je riziko porušení důvěrnosti (confidentiality), integrity (integrity), a dostupnosti (avaliability) aktiv. Některá IT rizika mohou být způsobena problémy, které nesouvisejí s IT, ale mají na IT velký vliv, například: problémy dodavatele projektu. Proto kvalitní řízení rizik IT vyžaduje dobré chápaní vazeb mezi příčinou a důsledkem. IT rizika existují vždycky, ať je podnik vnímá nebo ne. Proto je důležité identifikovat potenciálně důležitá rizika IT ve vztahu ke každému jinému riziku. Jak ukazuje praxe, IT rizika nejsou dost dobře chápána výkonným managementem a představenstvem. I když to jsou právě ty lidí, kteří závisejí na plnění strategických a operačních cílů podniku, a měli by být odpovědny za risk management. IT riziko není čistě technickou záležitostí. Byznys manažeři by měli určit, co potřebují od IT pro podporu byznysu, stanovit cíle pro IT a zodpovídat za řízení souvisejících rizik. Pro řízení rizik IT v podniku existují klíčové a podpůrné role (chief financial officer (CFO), chief information officer (CIO), human resources (HR) atd.). Každá role má svoje výhody/důvody pro řízení rizik IT, což znázorňuje tabulka dole. Tabulka 1 Role a důvody pro zavádění rámce Risk IT. Zdroj: (8) 10

12 Pro efektivní řízení rizik IT existují principy, založené na koncepci ERM. Obrázek 2 Principy pro řízení rizik IT. Zdroj: ( 8) Spojeni s byznys cíli (Connect to Business Objectives) - s IT riziky se zachází podobně jako s byznys riziky. Pozornost se věnuje byznys výstupům. IT podporuje dosažení byznys cílů a rizika IT jsou vyjadřována, jako vliv na strategií a dosažení cílů. Analýza rizik IT se zakládá na souvislosti byznys procesů a zdrojů, spojených s IT, jako jsou lidé, aplikace a infrastruktura. Byznys rizika spojená s IT jsou posuzována jednak jako ochrana proti ztrátě hodnoty a jako příležitost k vytváření hodnoty. Sladěni IT Risk managementu s ERM (Align IT Risk Management with ERM) byznys cíle a výše tolerovatelných rizik jsou definovány. Proces rozhodováni zohledňuje plný rozsah nových příležitostí a potenciálních ztrát, plynoucích z IT rizik. Záležitosti, týkající se rizik, jsou integrovány v každé organizační jednotce a napříč celým podnikem. Vyváženost Nákladů/Přínosů IT Risk (Balance Cost/Benefit of IT Risk) riziko je prioritizováno s ohledem na jeho apetit a toleranci. Implementované kontroly vycházejí z cost-benefit analýzy. Jinými slovy, kontroly se neimplementují jenom kvůli jejich nedostatku. Existující kontroly jsou pravidelně přezkoumávány pro zvýšení jejich efektivnosti. Podpora férové a otevřené komunikace (Promote Fair and Open Communication) otevřená, včasná, přesná a transparentní informace týkající se rizik IT je vyměňována a slouží základem pro všechna rozhodnutí spojená s riziky. Záležitosti týkající se rizik, principy a 11

13 metody risk managementu jsou integrovány napříč celým podnikem. Relevantní technická zjištění jsou prezentována způsobem, pochopitelným pro byznys manažery. Stanoveni odpovědností (Establish Tone at the Top and Accountability) povědomi o riziku a kultura rizika by měla začínat ze shora (řídicí výbor, výkonný management), aby při rozhodování byl brán zřetel na relevantní rizika. Obzvlášť velká pozornost by měla být věnována rozhodnutím týkajícím se IT, zakládání projektů, klíčovým změnám v prostředí IT, řízení rizik, monitorování a testování kontrol. Funkce jako součást každodenních aktivit (Function as Part of Daily Activities) řízení rizik je interaktivní a nikdy nekončící proces. Každá změna přináší riziko a/nebo příležitost. Pozornost by měla být věnována metodám posuzováni rizik, rolím a jejích zodpovědnostem, nástrojům, technikám a kritériím napříč podnikem, zejména: Identifikaci klíčových procesů a příslušných rizik Porozuměni dopadům dosahovaných cílů Identifikaci indikátorů, pro pochopení toho, kdy je požadován update rámce nebo komponent 12

14 2.Základy správy rizik Nezbytnými komponenty pro správu rizik jsou: (8) Risk apetit a tolerance Odpovědnost za risk management Povědomí a komunikace Kultura rizik 2.1. Risk apetit a tolerance Pojmy risk apetite a tolerance se používají docela často, někdo mezi nimi vidí zásadní rozdíl, někdo je považuje za synonyma. Definice těchto pojmů, uvedená v rámci Risk IT, je shodná s definici pojmů, uvedených v COSO ERM a v normě ISO 31000: (8) Risk apetit stanovená výše rizika, kterou společnost nebo entita ochotná přijmout pro plnění její mise (nebo vize). Risk tolerance přijatelná variace vzhledem k dosažení cíle. Oba pojmy jsou popsány v procesním modelu rámce Risk IT. Risk apetit je výše rizika, kterou entita připravená akceptovat pro dosažení svých cílů. Při zvažování výše risk apetitu pro podnik, velkou roli hrají dva zásadní faktory: 1. Podnikové kapacity pro absorbováni ztráty, např. finanční nebo reputace. 2. Kultura managementu, tj. náchylnost k riskováni opatrnost nebo agresivita. Jaká je výše kritické ztráty pro podnik? V praxi je risk apetit definován kombinaci frekvenci (frequency) a rozsahu (magnitude). Risk apetit se může lišit, a také se liší napříč celým podnikem, proto neexistuje absolutní norma nebo standard přijatelného nebo nepřijatelného rizika. Risk apetit může být definován pomoci mapy rizik, viz následující obrázek. 13

15 Obrázek 3 Mapa rizik. Zdroj: (8) Znázorněna mapa rizik je pouze příklad, každý podnik by měl definovat svou mapu rizik a regulérně jí obnovovat. Mapa rizik by měla být definována s ohledem na celopodnikovou kulturu rizik, neexistuje univerzální dobré nebo špatné řešení, musí to být definováno a pochopeno. Risk apetit a tolerance by se měly používat nejenom při posuzování rizik, ale i při rozhodování, týkající se rizik IT. Risk tolerance je tolerovatelná odchylka od úrovně stanovené definici risk apetitu, např. standard požaduje, aby projekt byl dokončen v stanovený čas a dodržel stanovený rozpočet, ale připouští 10% přečerpání rozpočtu a 20% převýšení časového harmonogramu. Risk apetit a tolerance s časem se mění, nové technologie, nové organizační struktury, nové podmínky na trhu, nové byznys strategie a velké množství jiných faktorů vyžadují obnovování portfolia rizik a přezkoumání risk apetitu v pravidelných intervalech, s použitím obnovených bezpečnostních politik Odpovědnost za risk management V následující tabulce jsou uvedený role včetně jejích odpovědností za jednu nebo víc aktivit v průběhu procesů risk managementu. Odpovědný (Responsibility) patří těm, kdo zodpovídá za úspěšné dokončení aktivit. 14

16 Věcně odpovědný (Accountability) patří těm, kdo vlastní požadované zdroje, má autoritu na schvalování, přijetí či nepřijetí výstupu z procesu. Role, popsané v následující tabulce, v každém podniku se implementují jinak, a ne vždy to koresponduje s organizačními jednotkami a funkcemi. Proto každá role byla stručně popsána v tabulce. Tabulka 2 Role a jejích odpovědností. Zdroj: (8) 15

17 2.3. Povědomí a komunikace Mít povědomí o riziku znamená přijímat ho jako nedílnou součást byznysu. Což ale neznamená, že všechna rizika by měla být eliminována, nebo že se jím má vyhýbat, ale porozumět jím, identifikovat a spravovat je. Komunikace je klíčovým prvkem procesu, odkazuje na skutečnost, že lidé neradí o rizicích komunikuji. Lidé mají tendenci vypouštět riziko a radši probírají problémy, incidenty a krizové situace. (8) Výhody otevřené komunikace o rizicích jsou: Přispívaní k pochopeni výkonným managementem aktuální expozici rizik IT, což umožní definovat vhodné a informované reakce na rizika. Povědomí všech zúčastněných stran o rizicích a důležitost jeho integrace do každodenních aktivit. Povědomí externích zúčastněných stran o aktuální úrovní rizik a používaných procesech risk managementu. Následky špatné komunikace jsou: Falešný pocit jistoty a bezpečí v top managementu a nedostatek jasného směru řízení rizik od top managementu dolů. Nevyvážená komunikace s externím prostředím, obzvlášť v případech kdy se jedná o vysoké ale řízené riziko, může vést k nesprávnému vnímaní aktuálního rizika třetí stranou, např. klientem nebo investory. Dojem, že se podnik snaží skrýt rizika před vlastníky. Komunikační komponenty znázorňuje následující obrázek. 16

18 Obrázek 4 Komponenty komunikace. Zdroj: (8) Aby výměna informaci byla efektivní, informace musí být: (8) Čistá známa a pochopitelná pro všichni. Stručná informace by neměla zaplavovat příjemce. Všechna základní pravidla kvalitní komunikace platí i při komunikaci o rizicích. Což znamená: nepoužívat žargon a technické termíny, týkající se rizik, protože příjemci většinou nemají odborné technické znalostí. Užitečná jakákoliv komunikace o rizicích musí být relevantní. Technická informace, která je příliš podrobná a/nebo posílána nesprávným osobám, bude spíš komplikovat, než poskytovat aktuální pohled na rizika. Včasná pro každé riziko existují kritické momenty, od vzniku do následků na byznys. Například riziko může vzniknout při nesprávné organizaci IT, následky budou v podobě neefektivních operaci IT a dodávky služeb. Komunikace je včasná, pokud umožní identifikovat a řídit rizika ve vhodný okamžik. Nemá smysl komunikovat o zpoždění projektu týden před deadline. Adresována správné cílové skupině komunikace musí pobíhat na správné úrovní agregace, musí být upravená pro cílovou skupinu tak, aby umožnila činit informována rozhodnutí. Agregace ale nesmí schovávat hlavní příčiny rizik. Například šéf oddělení bezpečností potřebuje podrobná technická IT data a informaci o virech, aby mohl vyvinout řešení. Řídicí výbor IT ale nepotřebuje takové detaily, ale potřebuje agregovanou informaci, aby mohl rozhodovat o změně politiky nebo dodatečném rozpočtu pro řízení toho samého rizika. 17

19 Přístupná na bázi need-to-know veškerá informace, týkající se rizik IT, by měla být přístupná v případě potřeby. Registr rizik se všemi relevantními dokumenty nesmí být veřejně přístupný a musí být chráněn před osoby, kteří takovou informaci vzhledem k své roli nepotřebuji. Komunikace nemusí mít vždy formální písemnou podobu. Může také probíhat formou pravidelných schůzek. Následující tabulka obsahuje přehled nejdůležitějších komunikačních kanálů pro účelné a účinné řízení rizik. 18

20 Tabulka 3 Komunikační tok. Zdroj: (8) 2.4. Kultura rizik Kultura rizik začíná v podniku od řídicího výboru a výkonného managementu. Kultura rizik přepokládá, že všechny úrovně napříč podnikem mají povědomí o tom jak a proč reagovat na 19

21 rizikové událostí. Kultura rizik je koncept, který není jednoduché popsat, je založen na sérií chování, což znázorňuje následující obrázek. (8) Obrázek 5 Elementy kultury rizik. Zdroj: (8) Symptomy neadekvátní nebo problematické kultury rizik zahrnují: Vychýlení mezi skutečným risk apetitem tím, co je v politice. Skutečný přístup managementu ve vztahu k riskování může být agresivní, když to vytvořena politika reflektuje mnohem přísnější přístup. Existence kultury vzájemného obviňování. Takovému typu kultury by se mělo vyhýbat, jelikož to je nejefektivnější inhibitor relevantní a účelné komunikace. V kultuře vzájemného obviňování, byznys jednotky mají tendenci obviňovat útvar IT, když se projekty nedodávají včas anebo nesplňují očekávaní. Čímž upouštějí možnost pochopit, jaký podíl na úspěchu projektu mají ony (byznys jednotky). V extrémních případech byznys jednotky obviňují v nesplnění očekávaní IT, když to problém je v neefektivní komunikaci. Taková kultura jenom odvádí pozornost od efektivní komunikaci mezi útvary. 20

22 3. Základy vyhodnocování rizik V dané kapitole bude popsáno několik základních komponent vyhodnocování rizik. Více informací a praktické návody jsou v publikaci Risk IT Practitioner Guide. V kapitole budou popsány: Dopad na byznys Rizikové scénáře 3.1. Dopad na byznys Hodnocení IT rizik a rozhodování o nich vyžaduje, aby IT rizika byla popsána v relevantní byznys terminologií. Efektivní risk management vyžaduje vzájemné pochopení mezi IT a byznysem, ohledně toho, jaké riziko by mělo být řízeno a proč. Všichni zúčastněné by měli být schopné chápat a vyjadřovat, jak nepříznivé událostí mohou ovlivnit byznys cíle. To znamená, že: (8) Lidé z IT by měli rozumět tomu, jak selhání nebo událostí spojené s IT dokážou ovlivnit podnikové cíle a způsobit přímou nebo nepřímou ztrátu. Lidé z byznysu by měli rozumět tomu, jak selhání nebo událostí spojené s IT dokážou ovlivnit klíčové služby a procesy. Měla by být vytvořena souvislost mezi rizikovými scénáři IT a dopadem na byznys, aby bylo možné porozumět vlivu nepříznivých událostí. Existuje velké množství technik, které mohou pomoci podniku popsat IT rizika v byznys terminologií. Některé dostupné metody znázorňuje obrázek níže. Obrázek 6 Možnosti popisu IT rizik pomocí terminologie srozumitelné pro byznys. Zdroj: (8) 21

23 CobiT Information Criteria umožňuje vyjadřovat byznys aspekty, spojené s používáním IT. Vyjadřuji stav informací (v nejširším pojetí) poskytovaný IT, následně přizpůsobeny pro prospěch podniku. Jakékoliv nepříznivé událostí, způsobené IT, mají dopad na podnik v podobě nesplnění informačních kritérií. Popisování dopadu takovým způsobem představuje střední techniku, která plně nepopisuje dopad na byznys, ale např. dopad na zákazníky nebo na finance. CobiT Business Goals and Balanced Scorecard další technika, založená na konceptu byznys cílů. Byznys riziko se skrývá v jakékoliv kombinaci byznys cílů, v případě že nebudou dosaženy. Byznys cíle jsou v CobiTu strukturovány do čtyř BSC perspektiv: finance, zákazník, interní, růst/prosperita. Extended BSC Criteria na rozdíl od předchozích metod, spojuje dimenze BSC se sadou víc hmatatelných kritérií. Kritéria, znázorněná na obrázku č.6, mohou být použitá selektivně, i když stále mají vztah příčina-následek (např. (ne)spokojenost zákazníka může mít vliv na podíl na trhu). Obvykle podmnožina kritérií se používá pro popis rizik v byznys terminologií. Westerman 4 A s An Alternative Approach to Express Business Impact - metoda, založena na rámci 4A, který definuje IT rizika jako potenciál pro řízení jakéhokoliv ze 4 vzájemně provázaných cílů: agilita, přesnost, přístupnost, dostupnost. COSO ERM rámec COSO Enterprise Risk Management, uvádí následující kritéria: strategie, operace, reporting, shoda (compliance). Strategie cíle high-level, podporující poslání podniku. Strategické cíle, reflektují rozhodnutí managementu, ohledně vytváření hodnoty pro zúčastněné strany. Operace týká se účinností a účelností podnikových operací, včetně cílů, týkajících se výkonnosti a ziskovosti. Reporting týká se spolehlivosti reportingu, zahrnuje interní a externí reporting, také mohou být zapojený finanční a nefinanční informace. Shoda týká se dodržování relevantních zákonů a regulací. FAIR bezpečnostně orientována metoda, ale kritéria dopadu platí pro všechna IT rizika. 22

24 3.2. Rizikové scénáře Jednou z výzev, pro řízení rizik IT, je identifikovat důležitá a relevantní rizika, mezi všemi možnými, které mohou nastat s IT nebo ve spojení s IT, vzhledem ke všudypřítomnosti IT a závislosti byznysu na IT. Jednou z technik, jak překonat tento problém, je vývoj a používáni rizikových scénářů. Jedná se o základní přístup, který přináší realismus, přehled, organizační angažovanost, lepší analýzu a strukturu složitých záležitosti rizik IT. (8) Vyvinuté scénáře se používají při analýze rizik, odhadují dopady na byznys s ohledem na frekvenci. Následující obrázek ukazuje, že scénáře rizika lze odvodit pomocí dvou různých mechanismů: 1. Přístup Top-down začíná od celopodnikových cílů, provádí se analýza nejvíc relevantních a pravděpodobných scénářů rizik IT, které mohou mít dopad na podnikové cíle. Pokud kritéria dopadu jsou dobře sladěna s řidiči skutečnou hodnotu podniku, příslušné rizikové scénáře budou vyvinuty. 2. Přístup Buttom-up seznám obecných scénářů se používá k definováni sady konkrétních a customizovaných scénářů, pro řešeni konkrétních podnikových situaci. Obrázek 7 Vývoj scénářů rizik. Zdroj: (8) 23

25 Tyto přístupy se vzájemně doplňují a měly by být používány současně. Scénáře rizik by měly být relevantní a spojené s reálnými byznys riziky. Na druhou stranu, používání sady scénářů pomáhá při ujištění, že žádné riziko nebylo přehlíženo, a poskytuje komplexnější a kompletnější pohled na IT rizika. Jakmile sada scénářů rizik je definována, může být použitá pro analýzu rizik, kde se posuzuje frekvence a dopad scénáře. Důležitou komponentou takového posuzováni jsou rizikové faktory, znázorněné na obrázku. Rizikové faktory jsou takové faktory, které mají vliv na frekvenci a/nebo dopad ze strany byznysu na scénáře, mohou mít různé povahy a zařazují se do dvou hlavních kategorií: 1. Environmentální faktory mohou být interní a extérní. Interní jsou do značné míry pod kontrolou podniku. Externí podnik ovlivňovat nemůže. 2. Schopnosti (Capabilities) jak dobrý je podnik v činnostech, spojených s IT. Mohou být rozlišovány ve třech základních rámcích ISACA: IT risk management capabilities, IT capabilities, IT-related business capabilities. Scénář rizik IT je popis spojených s IT události, které mohou vést k dopadu na byznys, kdy a jestli nastanou. K tomu, aby scénáře rizik byly kompletní a použitelné pro účely analýzy rizik, měly by obsahovat následující komponenty, znázorněné na obrázku níže. Obrázek 8 Komponenty scénáře rizik. Zdroj: (8) Aktér (Actor) ten, kdo generuje hrozbu. Může být interní/externí, lidský/nelidský. Ne každý typ hrozby vyžaduje aktéra. 24

26 Typ hrozby (Threat type) povaha události. Byl to zlý úmysl? Pokud ne, tak se jedná o náhodu nebo selhání dobře definovaného procesu? Nebo je to přírodní událost (froce majeure)? Událost (Event) scénář vždy musí obsahovat událost. Je to prozrazeni (konfidenciální informace), přerušeni (projektu), modifikace, krádež, zničeni atd.? Událost také zahrnuje neefektivní design (systému, procesu, atd.), neefektivní provedeni procesů (procedury change managementu, akvizice, prioritizace procesů), regulace (dopadů) a nevhodné použití. Aktivum/zdroj (Asset/resource) na který reaguje scénář aktivum má hodnotu pro byznys, která může být ovlivněna událostí a mít dopad na byznys. Zdroj je cokoliv, co pomáhá v dosahování cílů IT. Aktiva a zdroje mohou být identické, např. IT HW je důležitým zdrojem, protože všechny IT aplikace používají HW, a současně je zdrojem, protože má určitou hodnotu pro podnik. Aktiva/zdroje zahrnují: lidé a organizace, IT procesy a byznys procesy, fyzickou infrastrukturu, IT infrastrukturu, informace a aplikace. Čas (Time) dimenze času, může být popsána jako: trvání události, načasování (nastala událost v kritický okamžik?), časová prodleva mezi události a následkem. Struktura scénářů rizik se liší mezí ztrátovými událostmi (událostí, které způsobují negativní dopad), zranitelnosti (přispívá k závažnosti a četnosti ztrátových události), ohroženi (akce nebo události, které mohou vyvolat ztrátovou událost). Je důležité rozlišovat tahle rizika a nezahrnovat je do jednoho velkého seznamu rizik. 25

27 4. Základy reakce na rizika Rámec Risk IT vymezuje tři domény: 1. Řízeni rizik 2. Hodnoceni rizik 3. Reakce na vyhodnocená rizika V kapitole budou popsány základní komponenty domény Reakce na rizika. Více informaci a praktické návody jsou v publikaci The Risk IT Practitioner Guide. Zde budou popsány: Indikátory rizik Definice reakci na rizika a prioritizace 4.1. Indikátory rizik Indikátory rizik jsou metriky, které prokazují, že podnik podléhá, nebo má vysokou pravděpodobnost toho že podlehne riziku, které překračuje definovaný risk apetit. Pro každý podnik jsou specifické, a jejích volba závisí na řadě parametru interního a externího prostředi, jako jsou velikost a komplexnost podnikáni, regulovanost trhu, podniková strategie. Identifikace indikátoru rizik, mimo jiné, by měla brát v úvahu následující kroky: (8) 1. Indikátory rizik by se neměly zaměřovat výhradně na operační nebo strategickou stránku rizik. Měly by být identifikované pro všechny zúčastněné strany. Zapojeni správných zúčastněných stran do výběru indikátoru rizik, je důležité. 2. Výběr indikátoru rizik by měl být vyváženy, a měl by pokrývat: indikátory výkonnosti (indikace rizika po tom, co událost nastala), tzv. lead indikátory (indikují jaké jsou možnosti pro prevenci události), a trendové (indikátory pro analýzu vývoje v čase a korelaci). 3. Ujistit se, že indikátory budou identifikovat příčinu problému a ne jenom symptomy. Podnik může vyvinout rozsáhlou řádu metrik, které mohou sloužit jako indikátory, nicméně není možné udržovat tu celou řadu metrik jako KRI (Key Risk Indicators). KRI se odlišují vysokou relevancí a pravděpodobnosti předpovídani/indikováni významných rizik. Kritéria pro výběr KRI zahrnují: 26

28 Dopad indikátory pro rizika s významným dopadem na byznys. Možnost implementovat, měřit a reportovat z různých indikátoru se stejnou citlivosti, se preferuje indikátor s lepší měřitelnosti. Spolehlivost indikátor musí mít vysokou korelaci s rizikem a sloužit dobrým měřítkem. Citlivost indikátor musí být reprezentativním pro riziko a schopen přesně indikovat různé odchylky v riziku. Pro ilustraci rozdílu mezi spolehlivostí a citlivostí, může sloužit detektor kouře. Spolehlivost znamená, že detektor spustí alarm pokaždé, když bude kouř. Citlivost znamená, že detektor zazvoní, pokud je dosažen určitý práh hustoty kouře. Komplexní řada KRI by měla mít vyvážené indikátory rizik a jejích příčin, stejně tak jako dopadu na byznys. Správně zvolená řada KRI bude mít pro podnik následující výhody: Včasné varováni (pohled do budoucna) signál o blížícím se riziku, aby management zareagoval včas proaktivně, dřív než se z rizika stane ztráta. Pohled do minulosti, na rizikové události, které už nastaly, pro možnost zlepšeni reakci na rizika. Možnost dokumentovat a analyzovat trendy. Indikace celopodnikového apetitu rizik a toleranci, pomoci nastavení metrik. Zvýšeni pravděpodobnosti dosaženi strategických cílů podniku. Pomoc pro kontinuální optimalizaci řízení rizik a správy prostředi. Existují ale i společné problémy při úspěšné implementaci KRI, mezi ně patři: KRI nejsou provázány s konkrétními riziky. KRI jsou často neúplné nebo nepřesné v specifikaci, tj. moc obecné. Nedostatek sladěnosti mezi riziky, jejích popisy a metriky KRI. Příliš velké množství KRI. KRI jsou náročné na měřeni. Je obtížné shrnout, porovnat a interpretovat KRI systematickým způsobem na úrovni podniku. 27

29 Jelikož podnikové interní a externí prostředí se s časem mění, prostředí rizik je také vysoce dynamické a řada KRI by se měla měnit s časem. Každý KRI souvisí s apetitem rizik a toleranci, takže může být definována taková úroveň, při které zúčastněné strany budou moci včas zareagovat Definice reakcí na rizika a prioritizace Účelem definici reakce na rizika je sladit rizika s definovaným apetitem rizik pro podnik, po analýze rizik. Jinými slovy, reakce má být definována s ohledem na to, že budoucí reziduální riziko (stávající riziko a reakce na něj jsou definovány a implementovány) je pravděpodobné (obvykle v závislostí na rozpočtu) v mezích tolerance rizika. (8) Risk Avoidance vyhnuti se riziku, znamená ukončit činností, vedoucí k riziku. Používá se pouze v případě, kdy žádná jiná reakce nemůže být použita. Např. když riziko je velice nepřijatelné pro management, kdy nelze použit transfer rizika, když žádná jiná reakce na rizika nedokázala snížit frekvenci a rozsah. Například přemístit data centr co nejdál od regionu s vysokou pravděpodobností povodni/zemětřeseni atd., nebo nezúčastnit se projektu u kterého riziko neúspěchu je hodně vysoké. Risk Reduction/Mitigation redukce znamená, že po detekci rizika následují kroky pro sníženi výskytu a/nebo dopadu rizika. Například posílit řízení rizik IT, pomocí implementaci dostatečně zralých procesu řízení rizik IT, definovaných rámcem Risk IT. Nebo zavést řadu kontrolních opatřeni, určených pro sníženi buď frekvence a/nebo dopadu na byznys. Risk Sharing/Transfer transfer znamená sníženi frekvenci rizika nebo dopadu, pomoci transferu nebo sdíleni části rizika. Nejpoužívanějšími variantami jsou pojištění nebo outsourcing. Risk Acceptance pokud konkrétní riziko, je považováno za velice vzácné, ale je velmi důležité/katastrofické a opatřeni jsou nepřiměřené, management může rozhodnout riziko přijmout. 28

30 Obrázek 9 Možností reakci na rizika a prioritizace. Zdroj: (8) Výše byly popsány možnosti reakci na riziko, dále bude popsáno jak zvolit vhodnou reakci na riziko. Při procesu rozhodováni by měly být brány v úvahu následující parametry: Cena reakci (Cost of the Response) v případě transferu to je cena pojistného. V případě mitigaci to je cena za implementaci kontrolních opatřeni. Důležitost rizika (Importance of Risk) důležitost rizika ve vztahu k reakci na něj, tj. jeho pozice na mapě rizik. Schopnost implementovat reakce (Capability to implement response) čím zralejší proces řízení rizik v podniku je, tím složitější reakce mohou být implementovány. V opačném případě, rozumnější řešením bude implementace základních reakci na rizika. Účelnost reakci (Effectiveness of the response) rozsah, ve kterém reakce na riziko bude snižovat frekvenci a dopad. 29

31 Účinnost reakci (Efficiency of the response) relativní výhody, které může přinést reakce na rizika. V případě, že implementace souboru kontrol přesahuje rozpočet, je vhodná prioritizace. Reakce na riziko, mohou být umístěny do kvadrantu, který nabízí 3 možnosti: 1. Quick wins velmi účinná a účelná reakce na vysoká rizika. 2. Business case dražší nebo složitější reakce na vysoká rizika nebo účinná a účelná reakce na nízká rizika, obě varianty vyžadují pečlivou analýzu a rozhodnuti managementu ohledně investici. Přístup, který je popsán v publikaci Val IT, v dané situaci může být užitečný. 3. Deferral nákladné reakce na nízká rizika. 30

32 5. Analýza rizik Než se začne výroba systému nebo prototypu musí být prokázána požadována úroveň bezpečnosti a spolehlivosti, protože změny v předvýrobní etapě se realizují snadněji a s menšími náklady. Prediktivní analýzy spolehlivosti a bezpečnosti se používají ke zkoumáni a předpovědi takových ukazatelů jako: bezpečnost, pohotovost, udržovatelnost a bezporuchovost systému. Takové analýzy se provádějí v etapě volby koncepce a stanoveni požadavků, v etapě návrhu a vývoje, pro posouzeni splněni specifikovaných požadavků. Existují 4 hlavní etapy při prováděni prediktivní analýzy spolehlivosti a bezpečnosti: (1) 1. Funkční a technická analýza. Kolekce dat o systému, jejich funkční a technická charakteristika. Předběžná analýza funkčních a technických charakteristik systému. 2. Kvalitativní analýza. Stanovení cílů analýzy spolehlivosti, potřebné specifikace, definice, limity. Stanoveni úrovně analýzy a hloubky členěni systému. Praktické členěni systému do zvolené úrovně. Kvalitativní analýza spolehlivosti a bezpečnosti. Vytvořeni modelu spolehlivosti, definice modelu funkčnosti. Definice a popis poruch systému, kvalitativní klasifikace poruch. Souhrnný přehled všech poruch, jejich setříděni a posouzeni závažnosti. 3. Kvantitativní analýza. Výpočet ukazatelů spolehlivosti, podle daných kritérií, porovnání s požadavky. Analýza citlivosti systému na spolehlivost jeho prvků. Souhrnný přehled poruch, jejich setříděni podle závažnosti důsledků. 4. Syntéza výsledku analýzy. Syntéza výsledků, posouzeni dosažené úrovně spolehlivosti, závěry, doporučeni. Pro realizací analýzy rizik je vyžadována ideální znalost technologie uvnitř objektu a v jeho okolí. Analýza musí zohlednit všechny reálné možné havarijní stavy včetně jejich následků. Mělo by se vycházet z provozních a havarijních řádů, využívat informace z dřívějších havárií. Nejfrekventovanější metody pro analýzu rizik v technické praxi jsou: (1) 31

33 Metoda Preliminary Hazard Analysis (PHA) předběžné posouzeni nebezpečí, byla vyvinuta pro armádu USA. Aplikuje se ve fází návrhu nebo vývoje pro registraci charakteru a pravděpodobnosti potenciálních nebezpečí. Metoda What if? zkoumá pomocí brainstormingu možné neočekávané události, nebezpečná místa v systému a identifikuje prvky pro metody FMEA a FTA. Metoda Failure Modes and Effects Analysis (FMEA) analýza způsobů poškozeni účinku, zkoumá všechny možné příčiny selhání jednotlivých prvků zařízení. Metoda Fault Tree Analysis (FTA) analýza stromu poruch, vychází z finální poruchy a hledá primární příčiny. Tahle metoda je široce používána v průmyslu pro analýzu neopravovaných systémů. Metoda Event Tree Analysis (ETA) analýza stromu událostí, metoda kvalitativní a kvantitativní analýzy, začíná s nalezeným případem a hledá sekvence událostí. Metoda Hazard and Operability Analysis (HAZOP) riziková a operační analýza, je rozpracovanou verzí metody FMEA a zahrnuje nejen příčiny, ale i následky nebezpečných stavů. Metoda Chemical Process Quantitative Risk Analysis (CPQRA) kvantitativní posouzení rizika chemického procesu, je jedna z nejpropracovanějších metod, představuje komplexní bezpečnostní studií. Původně byla vyvinuta pro chemické provozy. Rentability Block Diagram (RBD) analýza blokového diagramu bezporuchovosti, široce používána v průmyslu. State Space Methods (SSM) analýza prostorů a stavů, používá se pro analýzu opravovaných systémů nebo tam, kde není možné použit RBD a FTA. Truth Table Method (TTM) pravdivostní tabulka, často se používá společně s blokovými diagramy. Princip spočívá v sestavení a řešení všech kombinací stavů prvků systému. 32

34 Úroveň závažnosti důsledku Katastrofické Kritické Závažné Nevýznamné Důsledky na osoby i systém Vícenásobná úmrtí a/nebo mnohonásobná těžká zraněni a/nebo závažné poškozeni a/nebo ztráty systémů/zařízeni. Jednotlivá úmrtí a/nebo několik vážných zraněni a/nebo několik případů nemoci z povoláni a/nebo vážné poškozeni životního prostředí a/nebo velké poškozeni systému. Lehká zraněni a/nebo malý počet případů nemoci z povoláni a/nebo závažné ohroženi pro životní prostředi a/nebo malé poškozeni systému. Možné lehké zraněni a/nebo možnost nemoci z povoláni a/nebo poškozeni systému. Tabulka 4 Klasifikace závažnosti důsledků události/poruch. Zdroj: (1) Frekvence výskytu zaznamenané poruchy/události/nehody znázorňuje tabulka dole. Kategorie A Časté B Pravděpodobné C Občasné D Ojedinělé E Nepravděpodobné F Nemožné Popis Existuje možnost častého výskytu. Nebezpečí působí trvalé. Výskyt nebezpečí lze očekávat často. Výskyt nebezpečí lze očekávat několikrát. Je možné, že se vyskytne několikrát během životního cyklu objektu. Není jisté, že se vyskytne, možné to je. Dá se předpokládat, že nebezpečí se může výjimečně vyskytnout. Extrémně nemožné, že se vyskytne. Dá se předpokládat, že nebezpeči se nevyskytne. Tabulka 5 Klasifikace a frekvence poruch/události. Zdroj: (1) 5.1. Metoda Delphi Metoda Delphi je postup pro stanoveni odborného odhadu budoucího stavu nebo vývoje, s využitím skupiny expertů. Využívají se subjektivní názory členů expertní skupiny s cílem dospět ke konsenzusu. Delphi je druh brainstormingu s jasně definovanými pravidly. Metoda Delphi je velice oblíbena při kvalitativní analýze rizik a řízeni projektů. (3) Metoda Delphi spočívá v účelových interview experty hodnoticí skupiny a představiteli hodnoceného subjektu. Pro analýzu Delphi používá soubor otázek, o kterých se mluvilo na účelových interview. Tyhle otázky se skládají ze dvou částí pevné a variabilní. Variabilní část se mění podle průběhu interview a respondentů. 33

35 Výhodou metody Delphi je menší náročnost na spotřebu času a zdrojů, je vhodná pro analýzu rizik, protože dokáže určit, co se může stát a za jakých podmínek. Pohovory probíhají iteračně a výsledky jsou pak statistický zpracovávány. Počet iteraci by měl být max. 3, jinak roste statistická chyba metody. Postup a hlavní charakteristiky metody Delphi: (3) Skupina nezávislých expertů, 8 až 12. Zachovává se anonymita expertů, odstraňuje se tím psychologická bariéra vzájemného ovlivňováni. Otázky jsou formulovány tak, aby se dálo odpovědět kvalitativně. Experti můžou své odpovědi měnit. Každá odpověď by měla být zdůvodněna. Odborný odhad se zpřesňuje po více kolech dotazováni, vždy se zpětnou vazbou na kolo předchozí. Výsledky jsou statistický zpracovány Kvantitativní metody pro počítačové zpracováni Kvantitativní metody se používají v oblasti bezpečnosti organizaci a IS Obecné metodiky pro kvantitativní analýzu se využívá pro analýzu rizik Monte Carlo. Celá problematika se zpracovává ve formě tabulek, nejisté hodnoty se zaměňuji funkcemi o rozsahu možných hodnot. Návrh modelu, který definuje aktuální situaci v systému pomoci tabulek, je rozhodujícím faktorem metody. Metoda určuje pravděpodobnostní rozdělení hrozeb a rizik. RiskPAC se používá pro automatizaci dotazníkových přístupů formou automatizovaného hodnoceni. Metoda zahrnuje techniky pro zpracovávaní odpovědí a podklady pro tvoru závěrů. Není to expertní systém, který pracuje na bází umělé inteligence, je to automatizované stanoveni rizik. Risk Watch je programový produkt, poskytující soubor metod pro zjištěni, simulaci a změnu parametrů rizik systému. Metoda je založena na simulační metodě Monte Carlo nebo na vytvořeni modelu, který se tvoří ze získaných dat. Jde o automatizované 34

36 zpracováni výsledků, které byly získaný ze souborů otázek, které jsou strukturovány podle bezpečnostních oblasti. 35

37 6. Softwarové nástroje V dnešní době, kdy jednu finanční krizi střídá druhá, o proces řízení rizik se začínají zajímat jak vlastníky, tak i manažery všech typů organizaci. Proces řízení rizik nikdy nekončí, je velice nákladný a vyžaduje kvalitní znalosti a zkušenosti. Specialisté pro tuto oblast jsou velmi drazí a ne každá organizace si je může dovolit. Možným řešením jsou poradenské organizace anebo specializovaný SW, zaměřený na podporu řízení rizik. Nástroje se děli do 4 skupin: (2) 1. Nástroje pro řízení rizik bezpečností informaci specializuji se na zavedení ISMS 2 na základě analýzy rizik, která vychází z DB hrozeb, opatřeni a typických aktivit IS/IT. Jedná se o nástroje, podporující analýzu rizik jednorázově, ale s dlouhodobě platnými výsledky. Představitelem této kategorie nástrojů je CRAMM Nástroje pro průběžné každodenní řízení rizik základním prvkem takových nástrojů je registr rizik. Do registru rizik se ukládají informace o všech bezpečnostních rizicích. Díky tomu je možné líp zvládat, hodnotit a analyzovat. Představitelem této kategorie nástrojů je Enterprise Risk Register. 3. Nástroje pro řízení celopodnikových rizik tzv. Enterprise Risk Management (ERM). Pomoci takových nástrojů podnik snižuje rizika, ohrožující jeho byznys procesy. Takové nástroje podporuji redukci rizika a průběžné zlepšováni v téhle oblasti. Základní komponenty těchto nástrojů: řízení dat, řízení rizik, nezávislé/transparentní oceňování aktiv, reporting a workflow. Představitelem této kategorie nástrojů je SAS. 4. Komplexní softwarové platformy tzv. Governance, Risk and Compliance SW (GRC), má širší funkcionalitu (zahrnuje i ERM). 2 ISMS systém řízení informační bezpečnosti. 3 CRAMM CCTA Risk Analysis and Management Method. 36

38 6.1. CRAMM CRAMM je metodika pro zaváděni ISMS. Používá se při analýze rizik IS a sítí, při návrhu bezpečnostních opatřeni a řešení havarijních situaci, při vymezení havarijních požadavků na IS. Při používaní metodiky CRAMM je možné provádět analýzu rizik IS během jednoho dne (pomocí CRAMM Express), detailně určovat hodnotu dat v IS, objevit nejrizikovější části IS, navrhovat protiopatření pro sníženi zjištěných rizik, udržovat bezpečnostní dokumentaci aktuální, analyzovat IS ve všech fázích jeho životního cyklu. CRAMM plně podporuje proces zavádění ISMS v souladu s normou ISO/IEC 27001:2005 a připravuje systém na certifikaci podle ISO/IEC (2) Uživatel si může vybrat typ analýzy s ohledem na styl práce, délku analýzy a objem vstupů/výstupů. Základním modulem CRAMM je analýza CRAMM Expert, která umožňuje provádět detailní analýzy rizik IS a navrhovat protiopatření. Tahle analýza obsahuje 3 fáze: 1. Identifikace a tvorba modelů aktiv, vyplývající z rozhovoru s respondenty. Cílem je určit možné dopady na provoz podniku, v případě ohroženi. 2. Identifikace a určení úrovně zranitelnosti systému. Cílem je výpočet míry rizika. 3. Návrh protiopatření, identifikace stavu zjištěných rizik. Cílem je zpracování podkladů pro implementaci protiopatření, která byla doporučena k realizaci. Analýzu se dá provést za pár hodin, proto se spíš hodí pro úvodní zmapováni oblastí, než pro získání certifikace Enterprise Risk Manager Nástroj Enterprise Risk Manager vychází z celé řady norem jako: ISO 31000, AS/NZS 4360, ISO 27001, COSO a dalších. Podnikům usnadňuje soulad se zmíněnými normami. Díky tomu, že nástrojem je podporována kvalitativní analýza rizik, data o rizicích se ukládají podle kategorie: aktiv, útvarů, lokalizaci, aktérů rizika, odpovědných stran, zasažených aktivit, odděleni. Mimo jiné také umožňuje nastavit průběžné snímkováni události a monitorováni opatřeni, která byla přijata jako reakce na událost. 37

39 Nástroj je dostupný v různých verzích s ohledem na počet uživatelů (jeden uživatel RiskEasy, skupinové užiti Risk Register for Workgrounds) a na typ rizik (řízení rizik projektů Risk Register for Projects, řízení celopodnikových rizik Enterprise Risk Register) GRC GRC umožňuje automatizovaně podporovat řízení, hodnotit, udržovat a hlásit kontroly a rizika v souladu se standardy a regulacemi. GRC podporuje zavádění IT Governance a soulad se zákonem SOX. (2) Hlavní funkcionality: Řízení auditu podpora interního auditu v oblastech: plánováni, vytvářeni pracovních dokumentů a reportingů. Řízení politik to je zvláštní forma řízení dokumentů, tzv. dokument management, který umožňuje sledovat životní cyklus politik (od vyhlášeni až po archivováni). Řízení souladu podporuje reporting, workflow, prezentaci kontrolních cílů vč. příslušných rizik. Na minimální úrovni se podporuje soulad se SOX. Dobrým zvykem je podpora souladu s ISO 9000, SLA a typickými regulacemi pro jednotlivé průmyslové sektory. Řízení rizika podpora všech etap procesu, s důrazem na provozní rizika s ohledem na Basel II. GRC se dělí na několik typů SW: (13) ITRM Magic Quadrant for IT risk management ORM Magic Quadrant for Operational risk management VRM - Magic Quadrant for Vendor risk management BCMP - Magic Quadrant for Business Continuity Management and Planning AM - Market Guide for Audit management CCO - Market Guide for Corporate Compliance & Oversight 38

40 7. Projektová rizika Riziko, které může být zaviněno špatným řízením projektu, se může vyskytnout jak při budování programových systémů, tak i při projektu podnikové inovace. Nejlepším způsobem, jak rozpoznat riziko je kontrolovat seznám úkolů a časového plánu, a diskutovat s odborníky. Cílem procesu rozpoznání rizik je vytvořit soubor rizikových faktorů. Měla by se zjistit a strukturovaně zaevidovat významná potenciální rizika a provést jejích klasifikaci do skupin. Měl by se vytvořit katalog rizik což je seznám identifikovaných potenciálních rizik, který tvoří základ pro vznik mapy rizik, kde jsou zohledněny dopady a pravděpodobnosti naplnění rizik. Základní soubor potenciálních rizik (check list) obsahuje seznám nejdůležitějších rizikových faktorů organizace a tím snižuje nebezpeči, že některé riziko bude opomenuto. (1) Hodnoceni důležitosti identifikovaných rizik se provádí formou řízené brainstormingové diskuse expertů, odborníků a pracovníků firmy za účelem sdílení zkušenosti, výstupem takové diskuse je mapa rizik. Obecně hlavními problémy projektu jsou: Nedodrženi dohodnutých termínů, příp. zpožděni Nedodrženi deklarované kvality Překročeni plánovaných nákladů Nejčastějšími riziky implementace ERP jsou: (12) Splnění ERP systémem očekávaní uživatele. Lze zjistit z analýzy přínosů, která se provádí po určité době rutinního provozu. Výběr kvalitního ERP systému a dodavatele. Schopnost zákazníka formulovat požadavky. Konzistence cílů v podnikové a informační strategií (lze použít metodu Balanced ScoreCard) Schopnost společností plně se zapojit do procesů zavádění systému ERP. Měla by být vytvořena přesná pravidla a směrnice, stanoveny odpovědnosti a pravomoci. Důležité je překonat odpor zaměstnanců ke změnám a motivovat je ke spolupráci. Nesmí chybět podpora vedeni společnosti. 39

41 Dostatečné pravomoci jednotlivých členu projektového týmu. Neohrožuje dokončeni projektu, ale jeho průběh. Spolupráce klíčových uživatelů a konzultantů. Nejlepším řešením jsou pravidelné schůzky, na kterých obě strany si vyměnění názory a budou řešit konkrétní problémy. Vnější vlivy např. změny v legislativě, neplánována dlouhodobá nepřítomnost klíčových pracovníku, dodací lhůty dodavatelů apod. Jedinou možnou obranou je vydefinovat postup zmírnění dopadu takových události. Potenciální rizika dle etap životního cyklu projektu: (12) Rizika etapy projektové přípravy věnování malé pozornosti podmínkám údržby systému; smlouvy jsou uzavírány nejvyšším managementem podniku a právním oddělením, tj. věcnou správnost obsahu smlouvy nikdo nekontroluje; většinou se podepisuji standardní smlouvy, bez ohledu na specifika dané implementace. Rizika etapy návrhu koncepce řešení velmi obecná koncepce, jenom popis možnosti produktu; disproporce mezi časem zpracováni a posouzením koncepce; neadekvátní výběr modulů; nástroje pro modelování procesů jsou často vynechány. Rizika etapy detailního návrhu prototypu vedení podniku se toho neúčastní; podpůrné činnosti, jako jsou: podpora systému, zálohováni, obnova systému, dokumentace, bezpečnost se přehlížejí; často chybí definice interface aplikace; chybí koncepce logické bezpečnosti. Rizika produkčního provozu s časem aktivita řešitelů oslabuje; auditory jsou velmi často tlačeny k odsouhlaseni produktivního provozu; není garance, že finanční moduly budou nastaveny dle účetních předpisů. Rizika etapy optimalizace systému podpora jenom základních procesů; optimalizace systému se neprovádí; změny v průběhu projektu se nepromítají ve formě dodatků k základní rámcové smlouvě; procesy nejsou popsané Nejčastější chyby v IT projektech Chyba - odchylka od normy, požadovaného stavu nebo porušení daných pravidel. Ve statistice chyba není synonymem omylu, ale představuje rozdíl mezi vypočítanou, očekávanou, změněnou hodnotou a skutečnou hodnotou. Kdyžto riziko je definováno pravděpodobností a dopadem. 40

42 29 % IT projektů bývá dokončeno úspěšně, podle průzkumů Standish Group. Společnosti vyvíjející SW a projektoví experti se shodují na tom, že vedeni IT znovu a znovu dělá stejné chyby. Přitom problémem není jenom ignorováni obecně platných pravidel, ale i obsazovani nekompetentních osob na klíčové pozice. Nedostatečná schopnost zvážit rizika, která ohrožují jednotlivé projekty, a stanovit postupy pro eliminaci takových rizik.(9) Dále budou popsány 13 nejčastějších chyb, kterých se dopouští IT odděleni při řízení projektu. Chyba číslo 1: Projekt nedisponuje lidským kapitálem s požadovanými znalostmi a dovednostmi. Když chybí tým, který je schopen rychlé a kvalitně reagovat, projekt skončí neúspěchem velmi rychlé. Aby k tomu nedošlo projektoví a IT manažeři musejí mít absolutní přehled o pracovním zatížení a dovednostech svěřených zdrojů, včetně konzultantů a dodavatelů. Zrovna oni, dle názoru expertů, velmi často zůstávají pozadu (co se týče zkušenosti), nehledě na to, že na projektech odvedou obrovský kus práce. Právě proto by měla být implementována aplikace, která poskytne projektovému managementu přehled pracovního vytíženi, dovednosti, zkušenosti a znalosti jednotlivých účastníků projektu. Až se bude vědět, kdo a co umí, musí se rozalokovat zdroje napříč projektem, v detailu po dnech. Tady je možnost využití velkého množství organizačních modelů, například formováni tiger team, v rámci kterého jsou zaměstnanci na rok nebo více vyjmutí z pracovního procesu, aby mohli pracovat na specifickém projektu. Omezená kapacita zaměstnanců, zapojených do projektu, je problém, který lze vyřešit pozastavením nebo zrušením volnějších aktivit, které nejsou úzce spojeny s podnikovou strategií. Je vhodné prozkoumat veškeré podnikové projekty a identifikovat ty, které nejsou pro podnik moc důležité. Pozastavení nedůležitých projektů a relokace získaných z nich zdrojů, umožní podniku být pružnější a úspěšnější. Chyba číslo 2: Projekt nedisponuje zkušenými projektovými manažery. Bez zkušeného inteligentního manažera řízení projektu se může velmi rychlé vymknout kontrole. Proto by se měl vyhledávat certifikovány projektový manažer s odbornou kvalifikací k řízení lidských zdrojů. Dobrý projektový manažer musí mít velice silné osobní zkušenosti. Takoví lidé dobře vědí, jak vést jednáni, jak zvládat krizové situace, jak komunikovat 41

43 s různými zainteresovanými skupinami lidi: obchodníky, které se zaměřují na funkční stránku projektu, lidmi z IT, které se zaměřují na bezpečnost, a také s finančními orgány, které se zaměřují na rozpočet. Jisté problémy se dá eliminovat pravidelnou komunikaci s investory, plánováním rozpočtu na bázi week-to-week a uvědomováním klienta i o menších změnách na projektu. Dobrý projektový manažer musí mít i odborné technologické znalosti z relevantního oboru. Chyba číslo 3: IT odděleni neuplatňuje základní postupy projektového managementu. To je druhá nejčastější chyba projektového managementu. V situaci, kdy chybí metodologie, zvyšuje se riziko, že úkoly spojené s projektem bude nutné přepracovat, což znamená značné překročeni rozpočtového a časového rámce projektu. Vypracována metodologie umožní efektivní start a průběh projektu, zároveň poskytne přehled všech spojených s vypracováním projektu aktivit. Navíc disponování základní kostrou projektu odstraňuje vznik možných rizik. Nutností je zavedeni standardizovaných procesů pro schvalování, alokací zdrojů, plánováni a komunikaci s partnery. Chyba číslo 4: IT odděleni je zahlceno mnoha procesy. Důsledkem spouštěni velkého množství procesů najednou je absolutně neflexibilní projektový tým, nepružnost kterého, frustruje projektové partnery. V případě, že se uvažuje o přidáni nové funkcionality navíc, by se mělo obrátit na uživatele aplikace a zjistit, jestli pro něj taková funkce bude užitečná čí vítaná. Na dodáni něčeho navíc není nic špatného, ale pouze za předpokladu, že není narušen původní časový plán nebo rozpočet. Flexibilnost a komunikativnost vůči investorům a zainteresovaným do projektu partnerům není nikdy na škodu. Chyba číslo 5: IT nesleduje vliv dílčích změn na rámec celého projektu. Důsledkem je překročení projektového rozpočtu a časového harmonogramu. Pro změnový proces je doporučován následující postup: individuální změny nad rámec projektu musejí být promítnutý do celého projektového dokumentu. Projektový manažer by pak měl stanovit, jaký vliv to bude mít na rozpočet a časový harmonogram projektu. Žádost o změnu musí být schválena sponzorem a investorem projektu. Chyba číslo 6: IT nemá aktuální přehled o stavu projektu. 42

44 Co se nedá analyzovat, se nedá ani řídit. Není možné koordinovat zdroje, reagovat na změny a jejích vlivy na projekt. Obvykle ale řešení má IT na dosah ruky. Možným řešením může být specializovány SW. Chyba číslo 7: IT ignoruje problémy. Problémy se samy nevyřeší, čím déle jsou ignorovány, tím víc se zhoršuje jejích stav, čímž vrhá negativní stín na plán projektu. Pokud něco se dělá špatně, jde jenom o to, jak rychlé chyba bude napravena. Přirozenou reakci lidi je zatloukání a nepřiznávání své víny. Schopnost pochopit, že něco jde špatně, uznat svou chybu a konzultovat jí s partnery projektu, dokáže uchránit před pádem do krize. Chyba číslo 8: IT nedefinovalo rozsah rámce celého projektu. V případě, že rámec projektu není dobře definován, projekt může skončit velmi špatně. V projektu pak chybí směr a srozumitelnost, což pak způsobuje to, že IT nedokáže projekt ukončit v plánovaném čase, v rámci stanoveného rozpočtu a požadavků zadavatele. Řešením je vytvoření jasného modelu finálního stavu. Chyba číslo 9: IT nebere v úvahu vzájemnou závislost mezi projekty. Projekty nejsou ostrovy, velmi často na ně mají vliv jiné projekty, vyvíjející se ve stejném čase. V okamžiku, kdy projektový manažer nevidí závislostí mezi jednotlivými projekty (např. jeden zaměstnanec pracuje na několika projektech současně), dochází ke zpomalení prací, což nepříznivě ovlivňuje všechny aktivity. Řešením je tvorba vhodných diagramů a komunikace s partnery. Chyba číslo 10: IT nebere v úvahu Murphyho zákon. Všechno co se může pokazit, se opravdu pokazí. Projekt sjede z cesty a IT se bude snažit zvládnout nečekaný zmatek. Řešením je zařadit analýzu možných rizik, jako součást projektového plánování. Zorganizovat týmový brainstorming a zkusit přijít na to, co všechno by mohlo projekt zpomalit. Pak řádně promyslet postupy k eliminaci takových rizik. Chyba číslo 11: IT odbývá řízení projektových změn. V situaci kdy uživatele nechtějí nebo nejsou schopni se nové změně přizpůsobit, veškeré peníze a těžká práce, které byly vynaloženy do dodávky nové technologie, mohou přijít 43

45 vniveč. Proto již během plánovací fáze by měl být věnován čas zkoumání toho, kde všude se v projektu mohou objevit překážky, které ho dokážou zpětně ovlivnit. Musejí se určit partnery a uživatele, práci kterých, změna ovlivní, a naplánovat komunikaci. Chyba číslo 12: IT ignoruje nesmyslně stanovovaná data ukončení dílčích aktivit projektu. Velmi často IT samo na sebe uplete bič z nesplnitelných termínů. I když se snaží termín dodržet, stejně se to vyústí v problémy, které prodlouží včasné dodáni projektu. Proto IT management musí vysvětlit výkonnému řediteli, za jakých okolností bude možné dodržet stanovený termín ukončení projektu a s ním i plánované náklady a využití zdrojů. Výkonný ředitel se pak musí rozhodnout co má větší prioritu: buď náklady, rámec projektu nebo časový harmonogram. Chyba číslo 13: Špatná komunikace mezi IT, stranami zainteresovanými v projektu a investory. Velmi často se stává, že oddělení IT nesplňuje požadavky projektu. Často IT poskytuje svým partnerům příliš složitou dokumentaci, která obsahuje podrobné systémové funkce a projektovou specifikaci. Zadavatele takovou podrobnou dokumentaci ignorují, protože nejsou schopni jí porozumět. Pak je oddělení IT frustrováno a nechápe jak je možné, že odevzdána práce neodpovídá požadavkům zadavatelů. Proto se doporučuje dodat každému zainteresovanému partnerovi kompletní projektovou dokumentaci, v rozsahu od návrhu po školeni. V dokumentu by měly být zdůrazněny aktivity, vyžadující interakci s partnery, a vysvětlení toho, proč a kde musí být zpětná vazba. 44

46 8. Microsoft Dynamics AX MS Dynamics AX je řešení, které je určeno pro globální podniky, podporující oborové i obecné provozní podnikové procesy. Také nabízí funkce plánování podnikových zdrojů (ERP) pro řízení jak lidských, tak i finančních zdrojů. Díky potřebným nástrojům pracovníky mohou líp předvídat obchodní změny a využívat je ku prospěchu organizace. MS Dynamics AX nabízí řešení pro obory: (7) Maloobchod řešení, které pokrývá: prodejní místa, správu všech distribučních kanálů, elektronické obchody, finance, dodavatelský řetězec, provoz prodejen apod. Veřejný sektor řešení, pro státní správu, oblast vzdělávání, oblast zdravotnictví, neziskové organizace. Finance řešení, které pokrývá: pojišťovnictví, bankovnictví, správu majetků a aktiv, nástroje pro týmy. Výroba řešení, které umožní: transformovat plánování a provoz, posílit inovace, zvýšit rychlost a agilitu, vybavit své zaměstnance. Služby řešení, které umožní: zpeněžit talent a zrychlit inovace, rozvíjet jedinečné a spolehlivé služby pro klienty, snížit čas potřebný k akci. Telekomunikace řešení, které pomůže: nabídnout zákazníkům různé možnosti, zvýšit provozní efektivitu, získávat informace přímo od zákazníků, pochopit zákazníky, posílit business intelligence Charakteristika společnosti X před zavedením MS Dynamics AX Společnost, kterou budu popisovat, si nepřála být jmenována, proto jí budu nazývat společnost X. Společnost X patří k institucím, poskytujícím finanční služby. Zabývá se retailovými a podnikovými finančními službami. Organizační struktura společnosti je tvořena samostatnými organizačními útvary, které jsou sdružené v lineární řídicí struktuře. Řídicí struktura je tvořena divizemi, které jsou řízeny jednotlivými členy představenstva. Divize se dál člení na další organizační útvary. Základní informace uvedu v tabulce níže, platné pro rok 2014: 45

47 Bilanční suma (v tis. Kč) Základní kapitál (v tis. Kč) Zisk nebo ztráta po zdanění (v tis. Kč) Průměrný stav zaměstnanců 365 Aktiva celkem (v tis. Kč) Pasiva celkem (v tis. Kč) Tabulka 6 Základní informace o společnosti X. Zdroj: výroční zprava společnosti. Jelikož společnost X poskytuje finanční služby, musí řídit i riziko likvidity, k tomu používá následující ukazatele: HLA/A poměr rychle likvidních aktiv k aktivům celkem Kumulativní likvidní pozice společnosti v jednotlivých časových pásmech Když jsem začala v společnosti X pracovat, bylo pro mne velkým překvapením, že se pracuje výhradně s Excelem. Veškeré údaje se držely v Excelech. Například odděleni IT zastřešovalo 3 nákladová střediska: 1. Operations 2. Development 3. Security Každý vedoucí jednotlivých středisek měl několik Excelů, ve kterých si hlídal rozpočet, kapacity na projekty, dodavatele apod. Odděleni financí taky mělo několik různých Excelů, ve kterých si hlídalo čerpání rozpočtů. Stejně tak i účtárna měla svůj Excel. I šéf oddělení IT měl svoje Excely. Každý přitom čerpal data z různých zdrojů: odděleni financí čerpalo zdroje z Abry, vedoucí jednotlivých středisek ze systému správy objednávek a faktur. A šéf odděleni HR ani neuměl s Excelem pracovat. Excely s osobními údaji zaměstnanců a mzdami byly zabezpečeny heslem, které nebylo problémem prolomit. Objednávky vznikaly na základě faktur (kolikrát i po splatnosti), mělo by to být ale naopak. Objednávky v interním systému se schvalovaly týdny. Projekty začínaly a končily, ani rámcové smlouvy k tomu nebyly. Nebyly uzavřeny smlouvy s drtivou většinou dodavatelů, ať už šlo o BodyShop, nebo o SW. Velké množství porad, na kterých se probíralo jedno a totéž. Před auditem zaměstnanci byli informování o tom, co smějí a co nesmějí auditorům říkat. 46

48 Pak přišla změna vedení a s tím i nápad zavést MS Dynamics AX. Začal dlouhý proces sběru požadavků, analýz, vývoje a testování. V tom se zjistilo, že většina interních procesů je nastavena špatně, existuje velké množství přebytečných procesů Cíle projektu a smluvní zajištění Cílem interního projektu zavádění Ms Dynamics AX 2012 bylo zajistit podporu: administrativní, obchodní a projektovou. K tomu bylo zapotřebí normalizovat a standardizovat podporu IT, aby bylo možné zpracovávat data z poboček a následně je konsolidovat. Projekt implementace ERP systému by měl být ošetřen smlouvou. Do procesu formulace smluvních podmínek byli zapojení: právníci, IT specialisti a zástupce sponzora. Ze smlouvy by mělo být zřejmé, jaký je cíl implementace. Cílem projektu zavádění Ms Dynamics AX byla rozsáhlá transformace procesů. Implementace systému ERP je doprovázena velkým množstvím různých smluv: licenční, implementační, smlouva na systémovou integraci a smlouva na údržbu. Pokud jde o zhotovení SW na míru dodavatelem, pak jde o zhotovení díla na objednávku dle autorského zákona, který zákazníkovi dává tzv. práva absolutní. Může ale být sjednán i režim práv odchylně, v situaci kdy dodavatel bude chtít používat SW nebo jeho část. V případě šíření SW třetích výrobců dodavatel musí seznámit s licenčními podmínkami zákazníka. Protože, pokud dojde k nelegálnímu užití takového SW, je pak obtížné hledat zodpovědnou osobu. (2) Smlouva o dílo zahrnuje: standardní údaje obou stran; cenu a platební podmínky; zádržné; účinnost smlouvy; platnost smlouvy a čas plnění; povinností obou stran; odpovědnost za vady; právo šíření a vlastnické právo; sankce; slovník pojmů. V případě smlouvy na systémovou integraci v průběhu implementace a využíváni produktu, vše je o něco složitější. Musí se rozhodnout, jak vlastně ta systémová integrace bude chápana: Jako koordinace a zastupování subdodavatelů vůči zákazníkovi Jako integrace technických a SW částí řešení Jako integrace technických a SW částí nového systému se stávajícím systémem 47

49 Jako integrace nového systému se systémem řízení podniku (pracnější, protože zahrnuje Business Process Reengineering) Existuje velké množství různých druhů licencí na SW. Odlišností licencí spočívají v dostupnosti zdrojového kódu, možnost provádět modifikace, vytvářet kopie atd.. V případě společnosti X: S nepřevoditelným právem užití Licence není časově omezená Zdrojový kód není dostupný Není možné modifikovat zdrojový kód (pouze dodavatel) Podmínky a možnosti ukončení smlouvy: odstoupeni Smlouva o údržbě obsahuje: seznám nabízených služeb; podmínky instalace nových verzí; podmínky pro odstraňování chyb během záruční doby; podpora při poruchách; dokumentace; DB chyb a poruch systému; platební podmínky; podmínky ukončení smlouvy. Smlouva na údržbu a licenční smlouva byly spojeny v jednu smlouvu pro postoupení a údržbu počítačových programů Vybrané moduly Ms Dynamics AX 2012 Společnost se může rozhodnout, které moduly si vybere a bude používat. Pro fungování systému není nutné implementovat všechny moduly, záleží na požadavcích klienta. Existují dva možné způsoby: výběr modulů a/nebo úprava nastavení a propojení. V případě společností X se jednalo o následující moduly, uvedu nejdůležitější z nich: Finance I základní funkce: hlavní kniha, správa banky, pohledávky, závazky, dlouhodobý majetek atd. Modul Finance II kvůli omezenému rozpočtu nebyl implementován, což je dle mého názoru je chyba, protože poskytuje pokročilé funkce hlavní knihy: správa vztahu mezi pobočkami a nadřazenou společností, vytváření prognóz CashFlow atd. Obchod pomáhá automatizovat celý proces nákupu a prodeje. Systém, při zadávaní prodejních objednávek, automatický kontroluje limity úvěru a účetní informace zákazníků. 48

50 Obchodní smlouvy umožňuje spravovat podrobné obchodní smlouvy s možností slev a speciálních cen pro různé zákazníky, dodavatele a položky, ve všech měnách. Možnost automatického načítaní cen a slev při zadávání objednávek, a definováni data platností cen pro položky i zákazníky. Workflow zjednodušuje obchodní procesy a pomáhá společnosti udržovat pohotovost. Také zajišťuje, aby zaměstnanci dodržovali doporučené postupy společnosti, což omezuje rizika a zjednodušuje zachování shody a legislativou. Předdefinované šablony usnadňují rychlou konfiguraci pracovních postupu pro obvykle obchodní činností/aktivity bez pomoci vývojáře. Projekt I modul, který já osobně považují za nejdůležitější, vzhledem k tomu, že společnost X je relativně mladá, tak má velké množství interních projektů. Modul dokáže analyzovat průběh projektu v reálném čase a porovnávat finanční výkonnost jednotlivých projektů i celé společnosti s předem stanovenými cíli. Modul Projekt II nebyl implementován, kvůli omezenému rozpočtu, což je škoda, protože obsahuje funkce: pokročilé správy financí pro různé typy projektů, přiznávání výnosu, nástroje pro účtování probíhajících práci a funkce pro práci s dodavatelskými řetězci projektů. Správa lidských zdrojů I umožňuje uchovávat informace o zaměstnancích a smlouvy s nimi, zaznamenávat důvody pro odstoupení a evidovat přechody mezi odděleními. Modul Správa LZ II kvůli omezenému rozpočtu nebyl implementován, takže společnost X přišla o funkce: shromažďováni informaci, související s řízením a náborem zaměstnanců, vč. příslušné korespondence, statistických přehledů a mediálních odezev, také sledování absence a porozumění trendům v absenci Organizace projektu S ohledem na složitost implementace ERP systému bývá dobrým zvykem zpracovat studií proveditelnosti, tzv. předimplementační projekt, který popisuje přípravu podniku na implementaci a upřesňuje požadavky na nový systém. Takový projekt nabízí i dodavatel Ms Dynamics AX. Předimplementační projekt musí obsahovat: (12) Definici potřeb řízení Definici systému řízení 49

51 Definicí datové základny Definici hlavních podnikových procesů Definici požadavků na aplikační SW a výběr ERP systému Smlouvy na nákup licencí, implementaci, údržbu ERP systému Před zahájením implementace se musí vypracovat základní dokument projektu, který musí být odsouhlasen jak společností, tak i dodavatelem. V dokumentu je popis implementaci jednotlivých komponent ERP systému, způsob vyhodnocení postupu prací a způsob řešení problémů, stanovení odpovědných pracovníku, časové termíny, náklady, vyhodnocení rizik a určení stupně důležitosti jednotlivých etap s ohledem na celkové řešení projektu. Obrázek 10 Struktura Základního dokumentu. Zdroj: (12) Základní dokument vyjadřuje celkovou koncepci řešení ERP, proto má zásadní vliv na jeho kvalitu. Dodavatel předkládá Základní dokument ke schválení řídicí komisi a teprve po jeho schválení přistupuje se k dalším fázím. Projekt Ms Dynamics AX byl organizován ve dvou fázích: Fáze I projektová příprava, návrh koncepci řešení, návrh prototypu, produkční provoz Fáze II implementace, optimalizace systému Ve Fází I byl vypracován základní dokument projektu s návrhem řešení a implementaci, s podrobným popisem: funkčního rozsahu (SW/HW), návrhu procesních změn společnosti, návrh časového harmonogramu a nákladů. Dokument byl vypracován projektovým týmem dodavatele. 50

52 Etapa Vstupy Výstupy Činnosti Analýza a návrh Globální detailní a návrh Návrh funkčního a procesního modelu ERP řešení postupů Organizační Návrh datové Úvodní studie Směrnice zákazníka Dokumentace ISO 9000 Dokumentace stávajícího ASW pravidla projektu Návrh smlouvy na implementaci ERP základny Návrh ZSW a HW Definování komponent systému atd. ERP Tabulka 7 Vstupy, výstupy a činností etapy Analýzy a návrhu řešení. Zdroj: projektová dokumentace. V celkovém návrhu postupů se popisuje globální schéma aplikační architektury: vazby mezi komponentami, návrh pokryti funkcí, návrh spolupráce komponent s okolními komponentami systému. Ve funkčním a procesním návrhu se vytváří kontextový diagram a definuji se moduly pro každou komponentu, zodpovědnosti, distribuce, pokrytí řešením dodavatele a alternativní způsoby řešení. V návrhu datové základny je popsán podrobný datový model, odhady objemu dat, návrh zodpovědností za DB, nároky na distribuci dat, požadavky na externí data, způsoby zajištění externích dat, požadavky na ochranu a zabezpečení dat. V návrhu aplikačního SW definují se komponenty a moduly, priority zavedení, charakter a stupně úprav, návrh vazeb mezi komponentami a moduly, seznam nezbytných úprav a doplněni. Návrh ZSW specifikuje operační systémy, sítě, DB, vývojové prostředí pro úpravy a údržbu komponent. V návrhu HW se řeší doby odezvy, spolehlivost, tj. provozní nároky projektu, analýza možností rozšiřování komponent a jejích integrace. Dále se provádí analýza dopadů řešení projektu na organizační změny podniku a návrh organizační struktury. Rozhoduje se o tom, která pracovní místa zaniknou/vzniknou, možností rekvalifikace pracovníku a školeni. Také se řeší návrh způsobů migrace dat, organizace migračních činností a specifikace doprovodných služeb dodavatele (podpora/školeni uživatelů atd.). 51

53 Hlavním zdrojem problémů, mimo jiné, bylo preferování definic požadavků na ERP systém před pochopením produktu, který se bude instalovat. Chyba spočívá v tom, že členové projekčních týmů ze strany zákazníka neznají obsahovou stránku ERP systému a způsoby řešení jednotlivých funkcí, nabízených dodavatelem. Rozumným řešením je komplexní školeni funkčnosti dodávaného ERP systému, což nebylo plně využito. Dalším zdrojem problémů je věnováni nedostatečné pozornosti ze strany zákazníka vlastních procesů a jejích racionalizaci. ERP systém se pak implementuje na neefektivní/zastaralé řídicí procedury, které velice často mají duplicity a nejasné zodpovědnosti. Možným řešením je BPR (Business Process Reengineering), který může být prováděn buď samostatně (před implementaci ERP) anebo paralelně v rámci jednoho projektu. Další možností je využití metainformačních systému: vytvoří se podnikový procesní model, umožňující nakonfigurování parametrů systému. Ani jedná z možností nebyla použita v rámci projektu Ms Dynamics AX. Další chybou byla předčasná instalace technických prostředků a systémového SW v plném rozsahu. Měly se vytvořit pouze školicí a testovací verze. Zákazník trval na předčasné instalaci. Problém, který negativně ovlivnil celkovou úroveň kooperace obou stran, je neúplná definice základních řídicích procedur projektu (předávací, testovací apod.) Rizika projektu Ms Dynamics AX (Axapta) Rizika projektu Ms Dynamics AX 2012: 1. Alokace konzultantů alokace konzultantů na jiné projekty. Důsledkem byly nepředpokládané posuny v harmonogramu. 2. Nepředpokládány růst nákladů kvůli neplánovanému programování. 3. Požadavky na programování nestandardních reportu reporty a formuláře ve standardní verzí Axapty 2012 nevyhovovaly společností X. Důsledkem byly nejenom posuny v harmonogramu, ale i zvýšení nákladů, kvůli navýšení personálních kapacit. 4. Schopnost společností plně se zapojit do procesu zavádění Ms Dynamicx AX. Nebyla vytvořena přesná pravidla ani směrnice, také nebyly jednoznačně stanoveny 52

54 odpovědností a pravomoci. Což způsobilo, že procesní scénáře na straně zákazníka, v místo třech pracovních dnů se schvalovaly měsíce. 5. Spolupráce klíčových uživatelů a konzultantů. Velkým problémem byla absolutní neochota klíčových uživatelů, testovat procesní scénáře. Většina klíčových uživatelů byla v předdůchodovém věku a nebyla schopna porozumět novému systému. Časté stížností typu: Po třech stránkách četní procesního scénáře nevím kde jsem! nebo Byla jsem si zvyklá, že tohle tlačítko se nachází tady a vypadá takhle. V místo toho, aby se řešily konkrétní problémy, jako jsou funkční požadavky, zákazník řešil grafické rozhrání systému, vzhled tlačítek atp. Dalším velkým problémem byla data, důležitá pro nastavování systému. Zodpovědnou stranou za sběr a přípravu dat byl zákazník. Konkrétní případ: zákazník má 250 pokladen a různých pobočkách, v Axaptě se museli nastavovat pro každou pokladu ručně: číselné řady, deníky, účty hlavní knihy, poklady zvlášť pro eura, dolary a koruny. Měsíc po tom, co všechny pokladny v Axaptě byly nastaveny, zákazník oznámil, že 50 pokladen ze seznamu, který dodal, už dávno zrušil. Což pro dodavatele znamenalo, že ze systému bude muset ručně odstraňovat 50 pokladen, vč. všech souvisejících záznamu, tj. práce navíc. Jenom protože zákazník nedbal na kvalitu, poskytovaných dat. Data pro migraci, které zákazník připravil, se nedařilo naimportovat, kvůli velmi špatné kvalitě dat. 6. Certifikovaný projektový manažer. Roli projektového manažera vykonával starší konzultant. Nehledě na vynikající znalost systému, neměl zkušenost s řízením projektů a lidi. Což také mělo svůj podíl na překročení harmonogramu. 7. Komunikace. Veškera komunikace mezi dodavatelem a zákazníkem probíhala prostřednictvím Oulooku. Pak nastala situace, kdy se v těch ech nikdo nevyznal. Proto bylo rozhodnuto pro komunikaci používat ProjectL (vyvinutý na zakázku, není součástí standardní verzi). ProjectL je modul, který se používá jako nástroj řízení projektů. Kombinuje v sobě seznám požadavků (Stand požadavek, pokrytý standardní verzí Axapty. Dev není pokrytý standardní verzi, je nutný vývoj.) a seznam nedodělků BackL, pomoci kterého se předávají úkoly mezi uživateli Realizace projektu V etapě implementace se navrhuje způsob realizace projektu. V něm se specifikuji jednotlivé kroky a určení zodpovědných osob, a termínu dokončení. 53

55 Etapa Vstupy Výstupy Činnosti Tvorba způsobu realizace Úvodní studie Dokument Stanovení postupů Harmonogram projektu Ekonomická analýza Návrh smlouvy na implementaci ERP Tvorba harmonogramu projektu Ekonomický rozbor projektu Tabulka 11 vstupy, výstupy a činnosti etapy tvorby způsobu realizace. Zdroj: projektová dokumentace. V harmonogramu projektu se specifikují etapy projektu: obsah, zahájeni, ukončeni, návaznost a vstupy/výstupy etap, vč. zodpovědnosti za realizaci etap. Dále v ekonomickém rozboru se propočítávají pořizovací/provozní náklady, specifikují se ekonomické/mimoekonomické efekty. Postupy zavádění modulů: (12) Velký třesk zavedení všech komponent ERP systému naráz do celé společnosti. Takový postup je velice náročný z hlediska kapacit. Jeho výhodou je rychlost. Existují ale jistá rizika, spojená s takovým postupem, např. že systém nebude plně integritní. Postupné zavádění jednotlivých komponent a modulů jeden za druhým to je nejméně náročný postup implementace ERP systému a obsahuje malá rizika neúspěchů. Jeho nevýhodou ale je časová náročnost a nutnost simulovat nezavedené moduly, aby se ověřila funkčnost právě zaváděného modulů. Roll out nejdřív se provádí pilotní implementace v jedné organizační jednotce. Implementace v ostatních jednotkách proběhnou jako opakovaný projekt. Pilotní projekt může probíhat jak velkým třeskem, tak i postupným zaváděním. Hlavní výhodou je menší množství rizik, jelikož problémy, které se vyskytnou v pilotní implementaci, se vyřeší a nepromítnou se do dalších implementací. Podstatnou výhodou, jsou nejnižší možné náklady na implementaci. Duplicitní provoz nový systém + předešlé systémy. Jako pomůcku, pro plánování postupu jednotlivých etap, činností a zdrojů je SW na podporu projektového řízení, nejznámější je MS Project. Dále je uveden časový harmonogram, pro Fázi I/II. Harmonogram je pouze orientační. 54

56 Činnost Období Zahájení Fáze I studie proveditelnosti a návrh řešení Zpracování zadání a návrh analýzy Do Průběh analýz Konec analýz, zpracování výstupního dokumentu Schválení dokumentu, start Fáze II Fáze II implementace Nákup HW Nastavení modulů Testování modulů Donastavení modulů školení Duplicitní provoz Import koncových stavů Import kmenových dat Start provozu Tabulka 12 orientační časový harmonogram. Zdroj: projektová dokumentace 8.7. Předávání systému Předávání systému je velmi důležitým krokem, hlavním cílem je zajistit oboustranné zápisy aktivit, které se použijí při rozhodováni o dalším postupu nebo přerušeni a návratu k předchozí činnosti. Jednotlivé vstupy a výstupy jsou popsány v tabulce níže. Etapa Vstupy Výstupy Činnosti Předávání Moduly ERP vč. instalované částí ERP dokumentace moduly vč. systému Dokumentace DB předávacích a návrhu protokolů o datových rozhrání instalaci Organizační nové DB vč. směrnice projektu smlouva předávacích protokolů o migraci dat předávací protokoly o instalaci HW a ZSW akceptační protokoly instalace HW + ZSW + moduly ERP systému migrace ostrých dat akceptace modulů a komponent integrace systému Tabulka 13 Vstupy a výstupy etapy Předávaní ERP systému. Zdroj: projektová dokumentace 55

57 Instalaci modulů u zákazníka zajišťuje dodavatel, pomoci svých specialistů, za přítomností zodpovědných osob zákazníka. Instalační protokol se sepisuje o instalaci každého modulu. Vlastní předání probíhá formou předvedení funkčnosti na DB obsahující vzorek dat. Protokol se sepisuje i o předání. Po předání následuje období, ve kterém zaměstnanci zákazníka ověřují předané moduly, o výsledku se sepisuje akceptační protokol Školení uživatelů Školení uživatelů by měla být věnována dostatečná péče, jedná se o to, aby každý uživatel, s ohledem na jeho roli, mohl plně využívat funkcionalit systému a dokázal systém ovládat. Školení může probíhat paralelně se zaváděním systému nebo až po jeho akceptaci. Nevýhodou paralelního školení je nutnost školení po úpravách systému, nemožnost produktivního systému a riziko, že postupy budou zapomenuty. Výhodou ale je, že po nasazení systému se společnost nemusí zdržovat školením a může plně využívat nový systém. Pro školení se musejí připravit manuály, učebna a harmonogram školení. Velice často se zapomíná na technickou přípravu učebny (připojení PC s IS, přidělení hesel atd). Pro školení by se měla připravit školicí data, stačí i několik záznamů. Školení se provádí v rovinách: Celkový přehled o systému v rámci školení nebylo Školení uživatelů dle rolí pouze exekutiva Doškolení uživatelů (typy a triky, rozšiřující funkce) nebylo vůbec Školení nových uživatelů (často se stává, že nové zaměstnance jsou školení stávajícími zaměstnanci, kteří jím mohou předat i své zlozvyky, a proškolují je ve funkcích, které používají nic víc) také ne Při školení je důležité upozornit uživatele na odlišností nového systému od starého, uspořádaní výstupních tiskových sestav. Nejčastější problémy jsou popsány v tabulce níže. 56

58 Problémy Špatně navržené akceptační testy Neochota ze strany dodavatele opravovat částí, které testy neprošly Špatně organizované školení Nechuť zaměstnanců účastnit se školení Zastaralé manuály Neúplné proškolení uživatelů Integrace s ostatními SW Řešení Důkladný návrh akceptačních testů + kritéria hodnocení výsledků. Mělo by to být ošetřeno ve smlouvě. Vyčlenit zodpovědnou osobu za přípravu školení: rozsah, počet účastníku, kapacity, prostory, manuály. Vyžadovat prezenční listinu, nebo provést závěrečný test. Dohlížet na aktualizaci. Seznámit školitele s náplní práce jednotlivých uživatelů, zpětná vazba ohledně školení od uživatelů ve formě dotazníku. Otestovat v rámci integračních testu i integraci ERP systému s ostatními SW Tabulka 14 Nejčastější problémy a možná řešení etapy předávaní ERP 8.9. Provoz Fáze provozu zahrnuje údržbu, servis, konzultační služby, zpracování provozních statistik, formulace a analýzy nových požadavků. Vstupy a výstupy fáze provozu jsou uvedeny v tabulce níže. Fáze Vstupy Výstupy Činnosti Provoz Uživatelská a Analýza a Zajištění systému provozní dokumentace Předávací protokoly k ERP systému, HW a ZSW monitoring provozu systému: využití funkci, poruchy, chyby, doba odezvy atd. Návrhy úprav vč. určeni závažnosti provozu systému a jeho optimalizace Podpora uživatelů Přizpůsobování systému dodatečným požadavkům Upgrade systému Vyhodnocování přínosů systému Tabulka 15 Vstupy a výstupy fáze provozu systému ERP. Zdroj: projektová dokumentace Zajištění provozu provádí útvar informatiky společnosti, který také zajišťuje provoz/rozvoj počítačové sítě společnosti. Náplň zajištěni provozu ERP je strukturována dle komponent. Pracovník útvaru informatiky společnosti má na starosti jeden nebo několik modulů. Také by 57

59 měl být určen pracovník zodpovědný za celý provoz ERP systému, který bude mimo jiné zajištovat komunikaci s dodavatelem. Také by měl být určen pracovník zodpovědný za správu pravidel pro centrální číselníky a parametrizaci systému. Struktury pracovníků pro zajištění provozu IS se liší s ohledem na velikost společnosti. Ve velkých společnostech útvar IT je docela rozsáhlý, každý pracovník vykonává jenom malou část úkolů/činností útvaru. V malých společnostech je útvar informatiky malý, některé role se sdružují do jedné, kterou pak vykonává jeden pracovník, což vede k vzájemné nezastupitelnosti pracovníků. Nejčastější problémy fáze Provoz jsou zobrazeny v tabulce níže. Problémy Při běžném provozu mohou mít uživatele metodické problémy Výpadky nebo chyby systému při provozu Řešení Zajistit fyzický přítomné nebo on-line konzultanty help-desk Pohotovost zásahu dodavatele. Tabulka 8 Problémy fáze provoz ERP. Zdroj: projektová dokumentace Výhody a nevýhody implementace MS Dynamics AX Společnost X definovala výhody a nevýhody implementace MS Dynamics AX, uvedu je v tabulce níže. Výhody Automatizace administrativních postupu Menší závislost mezi růstem strukturálních nákladů a růstem společností Implementace integrovaného řešení Koncentrace všech dat na jednom místě Konsolidace výsledku Standardní lokalizace pro oblastí účetnictví a HR Nevýhody Investiční náklady Růst nákladů v oblastí technické podpory a aplikační podpory systému Tabulka 9 Výhody a nevýhody implementace MS Dynamics AX. Zdroj: projektová dokumentace. Chtěla bych zmínit SWOT analýzu ERP systému, která je založena na názorech oslovených dodavatelů ERP systémů: (12) 58

60 Tabulka 10 SWOT analýza ERP systému. Zdroj: (12). Po zavedení ERP sytému do podniku nastává otázka efektivností podpory podnikových procesů novým systémem. To je velice složité pro manažery obou stran. Při takovém hodnocení se porovnávají náklady a přínosy. Vyčíslit náklady je poměrně snadno, kdyžto s vyčíslením příjmů jsou problémy. Hlavní příčiny jsou: (2) 1. Očekávané přínosy je velmi obtížně kvantifikovat, protože z velké částí mají kvalitativní charakter. 2. Některé investice do IT/IS jsou nutností k udržení anebo zlepšení postavení podniku na trhu, nebo k získání významného zákazníka. Proto nemá smysl vyčíslovat efektivnost takových investic. 3. Očekáváné přínosy jsou silně závislé na životním cyklu ERP systému. Chyby v jednotlivých fázích můžou investici znehodnotit. 4. Pokud nedojde k reengineeringu byznys procesů, systém ERP nebude efektivně podporovat podnikové cíle. 5. Kvůli tomu, jak systém ERP zasahuje do všech oblastí a podnikových procesů, je velice obtížně odlišit přínosy od jiných vlivů okolí. Bezprostřední přínosy jsou minimální, někdy i záporné, protože vlastní customizace systému ERP a zprovoznění v konkrétním prostředí je velice náročné. Hlavním zdrojem přínosů je 59