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:
Praha
doc. Ing. Vlasta Svatá, CSc.
duben 2015
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
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
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
Obsah Úvod ....................................................................................................................................... 6 1. Proces a pojmy řízení rizik ..................................................................................................... 8 2.Základy správy rizik .............................................................................................................. 13 2.1. Risk apetit a tolerance.................................................................................................... 13 2.2. Odpovědnost za risk management ................................................................................. 14 2.3. Povědomí a komunikace ................................................................................................ 16 2.4. Kultura rizik................................................................................................................... 19 3. Základy vyhodnocování rizik ............................................................................................... 21 3.1. Dopad na byznys ........................................................................................................... 21 3.2. Rizikové scénáře ............................................................................................................ 23 4. Základy reakce na rizika ....................................................................................................... 26 4.1. Indikátory rizik .............................................................................................................. 26 4.2. Definice reakcí na rizika a prioritizace .......................................................................... 28 5. Analýza rizik......................................................................................................................... 31 5.1. Metoda Delphi ............................................................................................................... 33 5.2. Kvantitativní metody pro počítačové zpracováni ......................................................... 34 6. Softwarové nástroje .............................................................................................................. 36 6.1. CRAMM ........................................................................................................................ 37 6.2. Enterprise Risk Manager ............................................................................................... 37 6.3. GRC ............................................................................................................................... 38 7. Projektová rizika ................................................................................................................... 39 7.1. Nejčastější chyby v IT projektech ................................................................................. 40 8. Microsoft Dynamics AX ...................................................................................................... 45 8.1. Charakteristika společnosti X před zavedením MS Dynamics AX ............................... 45 4
8.2. Cíle projektu a smluvní zajištění ................................................................................... 47 8.3. Vybrané moduly Ms Dynamics AX 2012 ..................................................................... 48 8.4. Organizace projektu ....................................................................................................... 49 8.5. Rizika projektu Ms Dynamics AX (Axapta) ................................................................. 52 8.6. Realizace projektu ......................................................................................................... 53 8.7. Předávání systému ......................................................................................................... 55 8.8. Školení uživatelů ........................................................................................................... 56 8.9. Provoz ............................................................................................................................ 57 8.10. Výhody a nevýhody implementace MS Dynamics AX .............................................. 58 8.11. Závěrem o projektu zavádění MS Dynamics AX ve společnosti ................................ 60 9. Trendy ERP pro rok 2015..................................................................................................... 61 9.1. Trendy v architektuře..................................................................................................... 61 9.2. IT trendy v ERP ............................................................................................................. 62 9.3. Trendy ERP v oblasti implementace ............................................................................. 62 Závěr ..................................................................................................................................... 63 Seznam použité literatury. .................................................................................................... 64 Seznam použitých obrázku. .................................................................................................. 66 Seznam použitých tabulek. ................................................................................................... 67
5
Ú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
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 2012. 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
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
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
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
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
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
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
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.
2.2. 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
4.2. 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
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
Úč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
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
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
Úroveň závažnosti důsledku Katastrofické
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.
Kritické Závažné
Nevýznamné
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.
A B C D E
Kategorie Časté Pravděpodobné Občasné Ojedinělé 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
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.
5.2. 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 rizik: @RISK 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
zpracováni výsledků, které byly získaný ze souborů otázek, které jsou strukturovány podle bezpečnostních oblasti.
35
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í ISMS2 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.3 2. 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 3
ISMS – systém řízení informační bezpečnosti. CRAMM – CCTA Risk Analysis and Management Method.
36
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 27001.(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.
6.2. 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
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).
6.3. 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
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
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é.
7.1. 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
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
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
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
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
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.
8.1. 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
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ů Aktiva celkem (v tis. Kč) Pasiva celkem (v tis. Kč)
18 158 975 2 261 000 -394 145 365 18 167 307 18 167 307
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
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ů.
8.2. 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
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ů.
8.3. 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
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.
8.4. 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
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
Etapa Vstupy Analýza Úvodní studie a návrh Směrnice ERP zákazníka řešení Dokumentace ISO 9000 Dokumentace stávajícího ASW
Výstupy Činnosti Globální a Návrh funkčního a detailní návrh procesního modelu postupů Návrh datové Organizační základny pravidla projektu Návrh ZSW a HW Návrh smlouvy Definování na implementaci komponent ERP ERP systému atd.
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
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.).
8.5. 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
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 e-mailech 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.
8.6. 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
Etapa Tvorba způsobu realizace
Vstupy Výstupy Činnosti Úvodní studie Harmonogram Tvorba Dokument projektu harmonogramu Stanovení Ekonomická analýza projektu postupů Návrh smlouvy na Ekonomický implementaci ERP 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
Činnost Zahájení Fáze I – studie proveditelnosti a návrh řešení Zpracování zadání a návrh analýzy 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
Období 7.02.2014 Do 17.02.2014 18.02.2014-28.02.2014 1.03.2014-10.03.2014 13.03.2014 20.04.2014 25.04.2014-11.05.2014 15.05.2014-25.06.2014 27.05.2014-28.06.2014 1.07.2014-15.07.2014 16.07.2014-20.07.2014 21.07.2014-1.09.2014 2.09.2014-7.09.2014 5.09.2014-07.09.2014 08.09.2014
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é instalace HW + částí ERP dokumentace moduly vč. ZSW + moduly systému Dokumentace DB předávacích ERP systému a návrhu protokolů o migrace „ostrých“ datových rozhrání instalaci dat Organizační nové DB vč. akceptace modulů směrnice projektu předávacích a komponent smlouva protokolů o integrace systému migraci dat předávací protokoly o instalaci HW a ZSW akceptační protokoly
Tabulka 13 Vstupy a výstupy etapy Předávaní ERP systému. Zdroj: projektová dokumentace
55
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.
8.8. Š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
Řešení Důkladný návrh akceptačních testů + kritéria hodnocení výsledků. Neochota ze strany dodavatele Mělo by to být ošetřeno ve smlouvě. opravovat částí, které testy neprošly Špatně organizované školení Vyčlenit zodpovědnou osobu za přípravu školení: rozsah, počet účastníku, kapacity, prostory, manuály. Nechuť zaměstnanců účastnit se Vyžadovat prezenční listinu, nebo provést závěrečný školení test. Zastaralé manuály Dohlížet na aktualizaci. Neúplné proškolení uživatelů Seznámit školitele s náplní práce jednotlivých uživatelů, zpětná vazba ohledně školení od uživatelů ve formě dotazníku. Integrace s ostatními SW Otestovat v rámci integračních testu i integraci ERP systému s ostatními SW Problémy Špatně navržené akceptační testy
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 Provoz systému
Vstupy Výstupy Činnosti Uživatelská a Analýza a Zajištění provozu provozní monitoring systému a jeho dokumentace provozu optimalizace Předávací systému: využití Podpora uživatelů protokoly k ERP funkci, poruchy, Přizpůsobování systému, HW a chyby, doba systému ZSW odezvy atd. dodatečným Návrhy úprav požadavkům vč. určeni Upgrade systému závažnosti 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
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 konzultanty – help-desk Pohotovost zásahu dodavatele.
on-line
Tabulka 8 Problémy fáze provoz ERP. Zdroj: projektová dokumentace.
8.10. 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 Nevýhody Automatizace administrativních Investiční náklady postupu Růst nákladů v oblastí technické Menší závislost mezi růstem podpory a aplikační podpory systému 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
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
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
zefektivnění provozu. Nejdůležitějším možným přínosem systému ERP je rozšíření podnikatelských schopností a nabídka nových služeb. Co se týče vlastních ukazatelů hodnocení efektivnosti, tak je možné použít: CBA – Cost Benefit Analysis, jako například ROI, ROA, ROE, EPS, EVA apod. Všechny tyhle ukazatele vycházejí z přínosů a nákladů. Výše plateb vychází ze dvou metrik: hodnotové (value metric) a objemové (amount per metric). (2)
8.11. Závěrem o projektu zavádění MS Dynamics AX ve společnosti Bohužel jsem odešla ze společnosti X dřív než byl projekt ukončen, zůstala jsem ale se svými bývalými kolegy v kontaktu a dozvěděla jsem se, že nejsou s tím systémem spokojení. Připadá jím zbytečně složitý. Myslím si, že to způsobeno tím, že na kvalitní školení nebylo dost peněz. Školení bylo jenom pro řídicí pozice, ale pro ty zaměstnance, kteří s tím systémem mají pracovat každý den, žádné školení nebylo. Jako důsledek je velké množství zaměstnanců, kteří na systém nadávají a neumějí s ním pracovat, tj. nevyužívají funkcionality, které jím měly práci usnadnit. Dále byla velice problémová komunikace mezi zákazníkem a dodavatelem, protože zákazník dodavateli hlásil nové požadavky jako chyby. Což celkový průběh projektu jenom prodlužovalo, kvůli čemuž došlo k přečerpání kapacit. Dle mého názoru nekvalitní školení, špatná komunikace, velmi omezený rozpočet, představují rizika, která způsobily, že projekt je celkově neúspěšný, nehledě na to že byl „úspěšně“ dokončen, i když se třítýdenním zpožděním. Nehledě na nedostatky, hlavní cíl projektu – restrukturalizace procesů byl naplněn, procesy toku dokumentů ve společnosti, schvalováni, objednáváni a fakturace, po zavedení Ms Dynamics AX jsou mnohem komplexnější, nedochází k takovému množství chyb a časové prodlevě.
60
9. Trendy ERP pro rok 2015 Dnes už nejsou klasické ERP, odehrávají se změny v rámci funkcionality, forem, architektury a způsobu poskytování ERP.
9.1. Trendy v architektuře Budoucí trh ERP už nemusí být reprezentován „tradičními“ ERP. Například Salesforce4, roste podíl bolt-ons Salesforce a dalších non-ERP, což narušuje známou dnes představu o ERP aplikacích. Takže podnik může v místo pořizování tradičního ERP, pořídit samostatný CRM, logistického nebo finančního systému, a následně rozšířit jeho funkcionalitu do funkcionality ERP systému.(13) Návrat řešení typu Best-of-Breed. Trend poskytovatelů non-ERP umožňuje integraci nejvhodnějších řešení pro danou oblast, do komplexního celkového řešení. Což pro podnik znamená existenci více možností, tj. podnik není omezován limity integrovaných ERP. Ale na druhou stranu to znamená ještě složitější proces výběru vhodného systému vč. jeho integrace. Stoupající význam integraci a požadavků na vhodnou architekturu. Stoupající význam systémů Best-of-Breed a dalších doplňkových aplikaci zvyšuje nároky na konzultanty ERP a CIO. Nastává otázka integraci systémů vč. sdílení dat. Proto nedílnou a důležitou součástí dodání bude vhodná celková architektura. Oslabující se rozdíly mezi CRM a ERP. Nehledě na to, že v minulosti, z hlediska funkčnosti, mohly být CRM a ERP chápany jako dva samostatné systémy, dnes rozdíly mezi nimi se postupně eliminují, tj. snižuje se rozdíl mezi back a front officem. Oslabující zřetelné rozhraní mezi SaaS and on-permise software a ERP formou. Dodavatele ERP nabízejí obě formy a v mnoha případech podniky také využívají obě formy.
4
Salesforce – představitel CRM produktů.
61
9.2. IT trendy v ERP Využívání možnosti mobility. Pokračuje trend v rámci mobilní dostupností podnikových aplikací. Dostupnost nejenom pro obchodníky a manažery, ale i pro ostatní. Data – Business Intelligence. Podniky začínají investovat do analytických nástrojů typu BI. Snaha získat víc z implementací ERP v oblasti podpory rozhodování a zároveň zlepšit návratnost implementace ERP. Data – Big Data. V roce 2015 se očekává rozšíření efektivních nástrojů pro analýzu velkých dat. Nástroje by měly zpracovávat kromě existujících dat i nové zdroje dat. Také se očekává automatizace práce s daty s menším zásahem uživatelů. Cloudová řešení ERP. Očekává se, že většina podniků bude uplatňovat hybridní přístup. Internet věcí. Bude možný transfer dat prostřednictvím sítě, a to bez zásahu uživatele, a následně jejich vložení do ERP v cloudu pro analýzu. Konfigurovatelnost ERP. Vzroste počet modulů pro určitý proces nebo sektor. Přínosem pro uživatele bude nižší pracnost upgradu.
9.3. Trendy ERP v oblasti implementace Problémy a chyby při implementaci ERP. Důvod je přílišná komplexita ERP a vysoká rizikovost úspěšnosti, platí to pro všechny typy organizací. Zvýšení dichotomie mezi úspěšnou a neúspěšnou implementací. Úspěšné nasazení závisí na úspěšné implementací.
62
Závěr Cílem diplomové práce bylo zjistit, jaké rámce, metody, SW a postupy řízení rizik existují. Cíl je splněn. V teoretické části jsem popsala: proces a pojmy řízení rizik (kap. 1.), základy správy rizik (kap. 2.), základy vyhodnocování rizik (kap. 3.), základy reakce na rizika (kap. 4.), analýzu rizik (kap. 5.) a softwarové nástroje (kap. 6.). Základním pramenem byl dokument The Risk It Practitioner Guide, vydávány organizaci ISACA. V praktické částí jsem se zaměřila na rizika zavádění systému ERP do podniku. Popsala jsem nejčastější projektová rizika a chyby na IT projektech (kap. 7.) a projekt implementace systému Ms Dynamics AX (kap. 8.). Základními prameny byly: část projektové dokumentace, dokumentace od Microsoft a názory klíčových uživatelů. Konkrétní rizika projektu jsou popsána v kapitole 8.5. (Rizika projektu Ms Dynamics AX (Axapta)). Kapitola 9 se zaměřuje na trendy ERP pro rok 2015. V průběhu zpracovávání praktické částí jsem zjistila, že to, jestli projekt bude úspěšný, závisí na velkém množství faktorů, naprostou většinu kterých společnost dokáže ovlivnit. K tomu, aby projekt neskončil neúspěchem, by se měla definovat rizika, pro všechny fáze projektu by měly být navržený možná řešení nebo opatření, která by rizika buď snižovala na přijatelnou úroveň anebo eliminovala. Projekt zavádění ERP do podniku, patří k nejvíce rizikovým projektům. Souhlasím s názorem Ing. Václava Šebka, CSc. o tom, že žádná přečtená moudra nepomohou. Jedině kvalitní výběrové řízení na špičkového dodavatele se značnou a doloženou zkušeností v dané oblasti. V případě, že projekt se bude realizovat interně, tak pomoci výběrového řízení najít si uznávanou poradenskou firmu, která vypracuje analýzu rizik a navrhne opatření.
63
Seznam použité literatury. SMEJKAL, Vladimír a Karel RAIS. Řízení rizik ve firmách a jiných
(1)
organizacích. 4., aktualiz. a rozš. vyd. Praha: Grada, 2013, 483 s. Expert (Grada). ISBN 978-80-247-4644-9. SVATÁ, Vlasta. Audit informačního systému. 1. vyd. Praha: Professional
(2)
Publishing, 2011, 219 s. ISBN 978-80-7431-034-8. (3)
Managementmania [online]. 2014 [cit. 2015-01-22]. Dostupné z: https://managementmania.com/cs/rizeni-rizik KUBÁT. Risk management. Praha, 2014. Semestrální práce. VŠE. Vedoucí
(4)
práce doc. Ing. Vlasta Svatá, CSc. (5)
Risk Management Framework [online]. 2014 [cit. 2015-01-24]. Dostupné z: http://www.rmf.org/
(6)
What is M_o_R? [online]. 2014 [cit. 2015-01-26]. Dostupné z: https://www.axelos.com/best-practice-solutions/mor/what-is-mor
(7)
MS
Dynamics
AX [online].
2014
[cit.
2015-01-26].
Dostupné
z: http://www.microsoft.com/cs-cz/dynamics/erp-ax-overview.aspx (8)
ISACA. The Risk IT Framework [online]. USA, 2009 [cit. 2015-02-07]. ISBN 978-1-60420-111-6. Dostupné z: https://www.isaca.org
(9)
IT projekty. In: Chyby v IT projektech [online]. 2013 [cit. 2015-02-07]. Dostupné z: http://businessworld.cz/business-rizeni-podniku/
(10)
COSO [online]. 2013 [cit. 2015-02-10]. Dostupné z: http://www.coso.org/erm-
integratedframework.htm
(11)
PROTIVITI INDEPENDENT RISK CONSULTING. Guide to Enterprise Risk
Management. 2012. (12)
Vrana, I., Richta, K.: Zásady a postupy zavádění podnikových informačních
systémů: praktická příručka pro podnikové manažery, Grada Publishing, Praha 2005, ISBN 80-247-1103-6 (13)
GARTNER. Gartner GRC Reset: And the Vendors are… [online]. 2014 [cit.
2015-04-16]. Dostupné z: http://blogs.gartner.com/paul-proctor/2014/09/08/gartnergrc-reset-and-the-vendors-are/
64
(14)
BASL, Josef. Lokální i globální trendy ERP. Specifické trendy ERP pro rok
2015. 2015, 1/2015.
65
Seznam použitých obrázku. Obrázek 1 IT riziko v hierarchii rizik. Zdroj: (8) ....................................................................... 9 Obrázek 2 Principy pro řízení rizik IT. Zdroj: ( 8) ................................................................... 11 Obrázek 3 Mapa rizik. Zdroj: (8).............................................................................................. 14 Obrázek 4 Komponenty komunikace. Zdroj: (8)...................................................................... 17 Obrázek 5 Elementy kultury rizik. Zdroj: (8) ........................................................................... 20 Obrázek 6 Možnosti popisu IT rizik pomocí terminologie srozumitelné pro byznys. Zdroj: (8) .................................................................................................................................................. 21 Obrázek 7 Vývoj scénářů rizik. Zdroj: (8) ............................................................................... 23 Obrázek 8 Komponenty scénáře rizik. Zdroj: (8) ..................................................................... 24 Obrázek 9 Možností reakci na rizika a prioritizace. Zdroj: (8) ................................................ 29 Obrázek 10 Struktura Základního dokumentu. Zdroj: (12) ...................................................... 50
66
Seznam použitých tabulek. Tabulka 1 Role a důvody pro zavádění rámce Risk IT. Zdroj: (8) ........................................... 10 Tabulka 2 Role a jejích odpovědností. Zdroj: (8) ..................................................................... 15 Tabulka 3 Komunikační tok. Zdroj: (8).................................................................................... 19 Tabulka 4 Klasifikace závažnosti důsledků události/poruch. Zdroj: (1) .................................. 33 Tabulka 5 Klasifikace a frekvence poruch/události. Zdroj: (1) ................................................ 33 Tabulka 6 Základní informace o společnosti X. Zdroj: výroční zprava společnosti. ............... 46 Tabulka 7 Vstupy, výstupy a činností etapy Analýzy a návrhu řešení. Zdroj: projektová dokumentace. ............................................................................................................................ 51 Tabulka 8 Problémy fáze provoz ERP. Zdroj: projektová dokumentace. ................................ 58 Tabulka 9 Výhody a nevýhody implementace MS Dynamics AX. Zdroj: projektová dokumentace. ............................................................................................................................ 58 Tabulka 10 SWOT analýza ERP systému. Zdroj: (12). ........................................................... 59
67
