Poskytování ICT služeb v cloudu

Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Katedra informačních technologií
Studijní program: Aplikovaná informatika
Obor: Informační systémy a technologie
Poskytování ICT služeb v cloudu
DIPLOMOVÁ PRÁCE
Student
:
Bc. Jiří Neumann
Vedoucí
:
prof. Ing. Jiří Voříšek, CSc.
Oponent
:
Ing. Roman Kopecký
2012
Čestné prohlášení
Prohlašuji, že jsem diplomovou práci zpracoval samostatně, a že jsem uvedl všechny použité prameny
a literaturu, ze které jsem čerpal.
V Praze dne 30. dubna 2012
................................
Jméno a příjmení studenta
Poděkování
Rád bych tímto poděkoval panu prof. Ing. Jiřímu Voříškovi, CSc za cenné rady, pohotové nápady a
pozitivní přístup při vedení této práce. Dále bych chtěl poděkovat firmě Algotech BSC s.r.o.
za umožnění spolupráce a hlavně za drahocenný čas, který mi její představitelé věnovali.
Abstrakt
Práce se zaměřuje na všudypřítomný trend cloud computingu a konkrétně Software as a Service. Jejím
hlavním cílem je specifikace výhod a nevýhod, které tento koncept přináší, jak pro zákazníka, tak i
poskytovatele služeb. Globální pohled na cloud computing dále zužuje na Software as a Service a
nasazení ERP produktů tímto způsobem. Dalším cílem je stanovit vhodný postup pro analýzu firmy a
jejích potřeb před přechodem do cloudu. Z toho vyplývají doporučení, kdy je cloud vhodnější než onpremise řešení a naopak. Cílem je i sestavení postupu pro úspěšný přechod do cloudu a ošetření všech
důležitých aspektů pro budoucí využívání služeb. Teoretické výsledky a doporučení jsou prezentovány
na konkrétním praktickém příkladě nasazení ERP ve formě SaaS. K dosažení cílů slouží teoretická
analýza všech dostupných knižních a elektronických pramenů, zabývajících se danou problematikou a
konzultace s experty ze společnosti Algotech BSC. Hlavním přínosem práce je dvojí pohled na cloud
služby, vždy z pohledu zákazníka i poskytovatele s užším zaměřením na ERP. Autor dále vypracovává
vhodný postup pro přechod do cloudu a rady pro výpočet ROI, TCO a obsah všech potřebných smluv.
Klíčová slova: Cloud computing, SaaS, PaaS, IaaS, Software as a Service, On-premise, Private cloud,
ERP, ROI, TCO
Abstract
This thesis focuses on the ubiquitous cloud computing trend and particularly Software as a Service.
The main goal is to specify all pros and cons of this concept for its customers and also cloud providers.
The global perspective is then specified to Software as a Service and deployment of SaaS ERP
products. The next goal is to define an appropriate method to analyze a company’s needs prior to
switching to the cloud. Furthermore, recommendations as to whether the cloud is better than an onpremise version should result from the previous analysis. Another aim is to form a process for
successful switch to the cloud and ensure all important aspects of using cloud services are covered.
Theoretical findings and recommendations are used in a practical example of SaaS ERP deployment.
To reach all goals, a theoretical analysis of all available monograph and electronic sources, covering
cloud computing and consultations with experts from the company; Algotech BSC, were used. The
main added value is in the dual point of view on the topic, from customer’s and provider’s viewpoints
with a more detailed focus on ERP. The author suggests the right procedure for switching to the cloud,
guidance with calculating ROI, TCO and preparing all necessary contracts and agreements.
Keywords: Cloud computing, SaaS, PaaS, IaaS, Software as a Service, On-premise, Private cloud,
ERP, ROI, TCO
Obsah
1
2
Úvod ................................................................................................................................................ 8
1.1
Cíle a přínosy práce ................................................................................................................. 9
1.2
Rešerše dostupných zdrojů .................................................................................................... 10
Definice cloud computingu ........................................................................................................... 11
2.1
Vysvětlení používaných pojmů ............................................................................................. 12
2.1.1
2.2
Základní charakteristiky cloud computingu dle NIST [9] ............................................. 13
Modely služeb (kategorie cloudů): ........................................................................................ 14
2.2.1
Software as a Service (SaaS) ......................................................................................... 15
2.2.2
Platform as a Service (PaaS) ......................................................................................... 15
2.2.3
Infrastructure as a Service (IaaS) .................................................................................. 15
2.3
Modely nasazení cloud computingu dle NIST [9]: ............................................................... 16
2.3.1
Privátní cloud ................................................................................................................ 18
2.3.2
Komunitní cloud............................................................................................................ 18
2.3.3
Veřejný cloud. ............................................................................................................... 18
2.3.4
Hybridní cloud............................................................................................................... 18
2.4
Výhody a nevýhody cloud computingu z pohledu zákazníka ............................................... 19
2.4.1
Silné stránky .................................................................................................................. 19
2.4.2
Slabé stránky ................................................................................................................. 27
2.4.3
Příležitosti...................................................................................................................... 29
2.4.4
Hrozby ........................................................................................................................... 29
2.4.5
Shrnutí SWOT analýzy ................................................................................................. 30
2.5
Výhody a nevýhody cloud computingu z pohledu poskytovatele ......................................... 31
2.5.1
Silné stránky .................................................................................................................. 31
2.5.2
Slabé stránky ................................................................................................................. 32
2.5.3
Příležitosti...................................................................................................................... 34
2.5.4
Hrozby ........................................................................................................................... 34
2.5.5
Shrnutí SWOT analýzy ................................................................................................. 35
2.6
Vhodnost aplikací pro cloud ................................................................................................. 36
3
ERP řešení v cloudu ...................................................................................................................... 38
3.1
Situace na trhu a trendy dle analytických společností ........................................................... 38
3.1.1
Gartner Magic quadrant ................................................................................................ 40
3.1.2
Hype Cycle for ERP 2011 společnosti Gartner, Inc. [10] ............................................. 42
SWOT analýza ERP řešení v cloudu z pohledu zákazníka ................................................... 45
3.2
3.2.1
Silné stránky .................................................................................................................. 45
3.2.2
Slabé stránky ................................................................................................................. 48
3.2.3
Příležitosti...................................................................................................................... 49
3.2.4
Hrozby ........................................................................................................................... 50
3.2.5
Vyhodnocení SWOT analýzy z pohledu zákazníka ...................................................... 50
3.3
4
SWOT analýza ERP řešení v cloudu z pohledu poskytovatele ............................................. 51
3.3.1
Silné stránky .................................................................................................................. 51
3.3.2
Slabé stránky ................................................................................................................. 52
3.3.3
Příležitosti...................................................................................................................... 52
3.3.4
Hrozby ........................................................................................................................... 53
3.3.5
Vyhodnocení SWOT analýzy z pohledu poskytovatele ................................................ 53
3.4
Return On Investements - cloud vs. on-premise řešení ......................................................... 54
3.5
Total Cost of Ownership - cloud vs. on-premise řešení ........................................................ 56
Co řeší zákazník při/před přechodem na cloud řešení? ................................................................. 57
4.1
Definice cílů a metrik ............................................................................................................ 57
4.2
Analýza stávající situace a definice požadavků .................................................................... 58
4.2.1
Ekonomická situace a současné náklady – definice rozpočtu ....................................... 58
4.2.2
Velikost, struktura a geografické působení organizace ................................................. 60
4.2.3
Závislost firmy na IT - požadavky na výkon, dostupnost, flexibilitu, spolehlivost ...... 60
4.2.4
Specifika firmy a nároky na customizaci ...................................................................... 61
4.2.5
Citlivost dat a know-how – požadavek bezpečnosti...................................................... 61
4.2.6
Vlastní hardware a lidské zdroje ................................................................................... 62
4.2.7
Možnosti integrace stávajících systémů ........................................................................ 62
4.3
Volba vhodného modelu nasazení......................................................................................... 62
4.4
Výběr dodavatele (poskytovatele služeb).............................................................................. 64
4.5
Sepsání potřebných smluv a příprava exit strategie .............................................................. 66
4.5.1
Smlouva o mlčenlivosti (NDA – Non-Disclosure Agreement, CA - confidentiality
agreement) ..................................................................................................................................... 66
5
4.5.2
Smlouva o garanci úrovni poskytovaných služeb (SLA – Service Level Agreement) . 67
4.5.3
Exit Strategie ................................................................................................................. 71
4.6
Proces přechodu na SaaS....................................................................................................... 71
4.7
Průběh používání XaaS ......................................................................................................... 73
Případová studie na Oracle JD Edwards EnterpriseOne ............................................................... 75
5.1
Popis zákazníka ..................................................................................................................... 75
5.2
Popis dodávaného produktu .................................................................................................. 75
5.3
Ceny a podmínky variant ...................................................................................................... 76
5.3.1
Varianta 1 – Software as a Service................................................................................ 76
5.3.2
Varianta 2 – Private cloud ............................................................................................. 76
5.3.3
Varianta 3 – On-Premise ............................................................................................... 77
5.4
Výpočet ROI ......................................................................................................................... 77
5.5
Výpočet TCO ........................................................................................................................ 80
5.6
Požadavky firmy na systém a její specifika .......................................................................... 81
5.7
Doporučení vhodné varianty a upozornění na vzniklé souvislosti ........................................ 82
6
Závěr ............................................................................................................................................. 83
7
Seznam literatury........................................................................................................................... 85
8
Seznam obrázků, tabulek a grafů .................................................................................................. 90
9
Terminologický slovník ................................................................................................................ 91
10
Přílohy ....................................................................................................................................... 92
Příloha 1 – TCO jednotlivých variant nasazení ERP JD Edwards EnterpriseOne pro 35 uživatelů . 92
Příloha 2 - TCO variant ERP - sjednocený graf ................................................................................ 93
Příloha 3 – TCO Netsuite vs. Microsoft Dynamics a SalesForce.com [58] ...................................... 94
Příloha 4 – Grafy k TCO Netsuite vs. Microsoft Dynamics a SalesForce.com [58]......................... 95
1 Úvod
Cloud computing se stal všudypřítomným pojmem ve světě, jak podnikových informačních systémů,
tak ve veřejném sektoru služeb. Již jej nelze přehlížet jako jedno z největších buzzwords1 poslední
doby, ale naopak se všichni přizpůsobují, aby mohli co nejvíce těžit z tohoto přístupu. Vývojáři píšou
multi-tenant aplikace a firmy na druhém konci často zvažují výměnu on-premise2 řešení za SaaS3 při
plánování své IS/ICT strategie. Dle analýzy společnosti Gartner [1] pojem cloud computing stále
zůstává silně přeceněný a přináší přemrštěná očekávání. Na druhou stranu nepochybně přináší i značné
potenciální výhody. Společnost Gartner ovšem dodává, že pro porozumění těmto výhodám je nutné se
zbavit všudypřítomné mediální bubliny obklopující cloud computing a podívat se na mnohem více
dílčích částí, ze kterých se tento fenomén skládá. Až poté se lze bavit o jeho výhodách a nevýhodách.
Bohužel se stává trendem nazývat jakoukoliv hostovanou službu cloud computingem a přitom vůbec
nemusí splňovat potřebná kritéria, o kterých se píše v této práci.
Nástup cloud computingu je v České republice oproti světu trochu zpožděný. Výzkum, provedený
v roce 2010 ve spolupráci s katedrou informačních technologií na VŠE v Praze přinesl tato čísla.
Z 600 oslovených firem pouze 4 % uvádějí, že cloud computing využívají a jen 6 % ho plánuje nasadit
během dalších 2 let [2]. Může za to i špatná informovanost firem i laické veřejnosti. Z průzkumu
agentury Aspectio Research provedeného v září 2011 ve spolupráci s českým Googlem a Asociací
malých a středních podniků a živnostníků ČR (AMSP ČR) vyšly tyto výsledky [3]:
•
Téměř 70 % respondentů výzkumu předtím o cloud computingu neslyšelo a pouze čtvrtina zná
správný význam termínu.
•
16 % firem termín cloud computing nezná, ale nevědomky ho už využívá.
•
Po objasnění termínu projevilo o vyzkoušení cloud computingu zájem až 40 % podnikatelů a
firem účastnících se výzkumu.
•
92 % uživatelů cloudových aplikací z řad malých a středních podniků je spokojených a
oceňuje zejména flexibilní přístup k informacím.
Dle výzkumu CIO Economic Impact survey [4], kterého se účastnilo 291 IT manažerů, se cloud
computing stává prakticky běžnou záležitostí. Rozpočty na cloud computing se zvyšují podle 48
procent dotázaných. Ve srovnání s listopadem 2010, kdy takto odpovídalo 44 % a srpnem 2010 jen
38 % dotázaných jde opět o nárůst. 53 % CIO dále tvrdí, že očekávají zvýšení rozpočtu o 5 % během
následujícího roku.
1
Buzzword – populární a často přeceňovaný výraz
On- premise – software instalovaný na hardware zákazníka v místě firmy
3
SaaS – Software as a Service
2
8
Hlavním důvodem volby tohoto tématu byla hlavně jeho aktuálnost a spojení s praxí. Nabyté
zkušenosti a zjištěné závěry se budou hodit v profesním životě autorovi. Měly by také být použitelné
ve společnosti Algotech BSC4, se kterou autor na práci spolupracoval.
1.1 Cíle a přínosy práce
Tato práce má za úkol jednoznačně určit, co pojem cloud computing znamená, rozlišit všechny jeho
podoby a identifikovat nejvhodnější aplikace pro tento model nasazení. IT manager firmy by měl po
přečtení získat povědomí o všech pozitivech a negativech a být schopen se rozhodnout, kdy tuto
variantu zvolit na místo dosavadních technologií.
Dalším cílem je představit nasazení ERP5 řešení v cloudu, tedy formou SaaS. To zahrnuje zvážení
možných omezení a rizik a na druhé straně také definici veškerých kladů, které poskytování formou
SaaS u těchto systémů nabízí. Kromě teoretické analýzy vhodnosti ERP v prostředí cloudu, je také
cílem shrnout veškerá kritéria, která organizace při přechodu ke cloud computingu řeší.
Cíle teoretické části:
•
Definovat výhody a nevýhody cloud computingu, které přináší koncovým zákazníkům (B2B6)
a jeho poskytovatelům
•
Identifikovat služby z oblasti IS/ICT, které jsou nejvhodnější pro poskytování v cloudu.
•
Zhodnotit výhody a nevýhody ERP řešení nasazeného v prostředí cloudu pro zákazníka i
poskytovatele
•
Navrhnout vhodný postup a doporučení pro firmu uvažující o přechodu ke cloudu
Jako praktická část slouží případová studie nasazení Oracle JD Edwards EnterpriseOne v reálném
prostředí společnosti. Má za úkol analyzovat rozdíly SaaS vs. on-premise řešení a vyplynou z ní hlavní
doporučení pro konkrétní společnost.
Cíle praktické části:
•
Na reálném příkladu zákazníka uvažujícího o přechodu ke cloudu analyzovat jeho potřeby a
rizika spojená s přechodem.
•
Srovnání nasazení Oracle JD Edwards EnterpriseOne jako on-premise, SaaS a private cloud
Metodami k dosažení vytyčených cílů jsou hlavně teoretická analýza dostupných pramenů a
zkušeností z praxe autora a společnosti Algotech BSC. Pro praktickou část u případové studie slouží
marketingové materiály poskytovatele spolu s interními ceníky a osobní konzultace.
4
Algotech BSC – veškeré info o společnosti k dispozici na http://www.algotech.cz
ERP – Enterprise Resource Planning
6
B2B – Business to Business – komunikaci mezi firmami
5
9
Mezi přínosy autora tedy patří ucelený popis možných variant cloud computingu a zaměření na ERP
segment. Dále návrh doporučení pro firmy, které teprve uvažují o přechodu k tomuto modelu.
Teoretické poznatky se poté aplikují v případové studii, která již byla zmíněna.
Práce se dělí na pět hlavních kapitol. Kromě úvodu se druhá kapitola zabývá vymezením pojmu cloud
computing a všech jeho variant, které se na trhu vyskytují. Třetí zvažuje konkrétní nasazení ERP
řešení ve formě SaaS a hodnotí vzniklé vlastnosti spolu s návody na výpočet ROI a TCO. V kapitole
čtyři se autor zabývá zvážením všech aspektů, které jsou pro firmu důležité před přechodem do cloudu
a také zmiňuje, jak by měly vypadat důležité SLA a NDA smlouvy, které se k SaaS váží. Pátá kapitola
popisuje na konkrétním příkladu firmy nasazení ERP produktu ve třech variantách.
1.2 Rešerše dostupných zdrojů
Poskytováním software ve formě služby se zabývá již práce profesora Voříška a spol. v titulu
Aplikační služby IS/ICT formou ASP - Proč a jak pronajímat informatické služby [5]. Tato práce se
sice o cloud computingu nezmiňuje, ale píše o jeho předchůdci ASP. Hlavní charakteristiky jsou stejné
a kniha obsahuje pohled zákazníka i poskytovatele. Z knihy se autor inspiruje teoretickým základem a
také podrobným popisem SLA smlouvy. Další monografií zabývající se touto problematikou je opět
kniha prof. Voříška, a sice Principy a modely řízení podnikové informatiky [6]. Ta již mluví o SaaS a
srovnává služby s klasickým modelem dodávky software komplexním způsobem z pohledu odběratele
služby. Přesto je práce hlavní teoretickou podporou kvůli obecnému pohledu na řízení podnikové
informatiky a také nabízí rady ohledně ROI a TCO. Na tu to knihu navazuje článek [7] stejného
autora, který srovnává SaaS s ASP, doplňuje pohled poskytovatele a věnuje se více analýze trhu a
možných dopadů SaaS na trh IS/ICT do budoucna. Hlavním zdrojem pro definici všech oblastí cloud
computingu a jeho rozdělení na dílčí části jsou materiály Národního institutu pro standardy a
technologie Ministerstva obchodu Spojených států Amerických. Jak definice [8], tak dokument se
Souhrny a doporučeními [9] vykládají cloud computing vědeckým způsobem a nejvíce se blíží
pohledu autora na věc. I vzhledem k počtu citací, které má NIST v jiných pracích a odborných
článcích, se jedná o důvěryhodný zdroj, který lze doporučit všem, kteří se zajímají o teoretickou
stránku cloud computingu, která se straní účelovým marketingovým klišé. Autor dále čerpá zkušenosti
IT specialistů z mnoha odborných, ale i marketingových článků. Vyzdvihnout lze především webový
portál techtarget.com, který obsahuje mnoho hodnotných informací. Mezi použitými zdroji nejsou
výjimkou ani blogové příspěvky, videa nebo podcasty. V kapitole o ERP autor využívá i materiálů
analytických společností Gartner, Forrester a Panorama Consulting Group. Obzvlášť první dvě jsou
světově uznávané a vydávají zajímavé analytické práce jako například Hype Cycle for ERP [10] nebo
Hype Cycle for Cloud Computing [1].
10
2 Definice cloud computingu
Tato kapitola má za úkol splnit první dva cíle diplomové práce. To znamená defininovat cloud
computing a veškerý obsah ukrytý pod tímto názvem. Dále nalézt výhody a nevýhody cloudu, jak pro
zákazníka, tak i poskytovatele a specifikovat nejvhodnjší aplikace pro tento koncept.
Výraz cloud computing se poprvé začal objevovat v 90. letech 20tého století. Jeho ideovým
předchůdcem bylo ASP7, které se snažilo využít internetové horečky v letech 1996 - 2001. Tento
model, nabízející aplikace jako službu, se bohužel přestal propagovat s koncem internetové horečky.
Dle článku profesora Voříška [7] se ASP vrátilo hned, co se obnovila důvěra v internet a IT obecně,
ale již pod jiným názvem, a sice jako SaaS. Cloud computing, resp. hlavně SaaS ho tedy plně nahradil
a je považován spíše za jeho nástupce, než synonymum. [11] V jeho cestě na vrchol mu pomohly
technologie jako virtualizace, load balancing a hlavně multi-tenant aplikace, které umožňují těžit
z tohoto konceptu. Ten se začal hojně využívat nejen u veřejných služeb, jako je například webmail
nebo datová úložiště, ale také se dostává do firemního sektoru, kde mění pohled na řízení podnikové
informatiky. [5]
Cloud computing odvodil svůj název z anglického slova cloud (mrak, oblak), který představuje datová
centra, technologie, infrastruktury, platformy a služby dodávané přes internet. [12]
Definicí cloud computingu lze najít opravdu velmi mnoho a není zatím nijak standardizovaná. Jak IT
odborníci, tak samotné firmy používají definice, které se více méně podobají. Pro účely této práce bylo
čerpáno z více zdrojů ( [12] [13] [14] [15] [16]), dle preference autora. Mezi hlavní patří definice
Národního institutu pro standardy a technologie Ministerstva obchodu Spojených států Amerických
(dále jen NIST). [8] Ta definuje cloud computing jako model umožňující na vyžádání všudypřítomný
pohodlný síťový přístup ke sdíleným zdrojům konfigurovatelného výpočetního výkonu (například.:
sítě, servery, datová úložiště, aplikace a služby), který může být velmi rychle připraven a dodán
s minimálním úsilím a interakcí poskytovatele.
Analytici ve Forrester Research [16] definují cloud computing takto: „Standardizované IT možnosti
(služby, software, nebo infrastruktura) dodávané skrze internetové technologie a placené modelem
pay-per-use v samoobslužném prostředí / A standardized IT capability (services, software, or
infrastructure) delivered via Internet technologies in a pay-per-use, self-service way.“
Vznikly i sdružení, která se soustředí na tvorbu otevřených standardů pro cloud computing. Jedním
takovým je DMTF (The Distributed Management Task Force), které se skládá ze zástupců firem
jako AMD, Cisco, Citrix, EMC, HP, IBM, Intel, Microsoft, Novell, Red Hat, Savvis, Sun a VMware.
Společně navrhují vhodné standardy pro vývoj v této oblasti pro dosažení interoperability a potlačení
7
ASP – Application Service Providing [http://nb.vse.cz/~vorisek/FILES/Clanky/2008_PolanskyVorisek_SaaS_a_transformace_IT_prumyslu.pdf]
11
proprietárních systémů. Podskupinou DTMF je například OCSI (Open Cloud Standards Incubator),
která nadefinovala Architekturu pro řízení cloudů8. [12] [17]
2.1 Vysvětlení používaných pojmů
Označení cloud v práci zahrnuje všechny tři modely služeb9: SaaS, PaaS a IaaS. Dále se zde často
používá označení poskytovatel (provider, dodavatel) služeb a spotřebitel (consumer, subscriber), což
je zákazník odebírající dané služby. Klient označuje koncového uživatele, který SaaS aplikaci využívá
skrze webový prohlížeč na své koncové stanici.
Subjekty vystupující v cloudu dle NIST [18]:
•
cloud provider – poskytovatel, dodavatel cloud služeb. Zajišťuje a spravuje infrastrukturu pro
poskytování služeb.
•
cloud consumer – zákazník, spotřebitel, který odebírá nabízené služby.
•
cloud broker – zprostředkovatel služeb, který stojí mezi poskytovatelem a spotřebitelem.
•
cloud auditor – nezávislá strana zajišťující kontrolu poskytovatelů a jimi dodávaných služeb.
•
cloud carrier – strana zajišťující přenos služby mezi poskytovatelem a koncovým
zákazníkem. Většinou zajišťuje síťové spojení.
Cenové modely cloudu:
•
pay-per-use (pay-as-you-go) – zákazník má přístup k takřka neomezenému rozsahu služby, ale
platí jen to, co skutečně využívá (například počet uživatelů, virtuálních strojů, velikost storage
v GB a jiné).
•
pay-per-user – platí se částka za uživatele služby za určité období (většinou měsíčně). Jako
příklad lze uvést variantu Professional u CRM od společnosti salesforce.com10, která stojí
$65/uživatel/měsíc.
Modely nasazení software:
•
on-premise (on-site) – klasický model, kdy je software instalovaný na serveru zákazníka.
Vyžaduje koupi hardware, operačních systémů a licenci pro software.
•
on-demand (SaaS) – označuje software dostupný na vyžádání. Software lze využívat ihned po
zaplacení paušálního poplatku.
8
Achitecture for Managing Clouds - http://dmtf.org/sites/default/files/standards/documents/DSPIS0102_1.0.0.pdf
9
XaaS – X jako služba (X = software, infrastruktura, platforma) více vysvětleno dále v textu
10
Ceník salesforce.com [http://www.salesforce.com/crm/editions-pricing.jsp]
12
•
workload
nebo customer workloads (data storage and processing) - označuje zatížení
počítačových systémů. Znamená objem úloh ke zpracování pro počítač za danou jednotku
času. [19]
Druhy aplikací:
•
single-tenant – aplikace fungující v režimu 1 x 1. Jedna instance programu slouží jen jednomu
uživateli.
•
multi-tenant – aplikace fungující v režimu 1 x N. Jedna instalace programu na serveru slouží
více uživatelům (tenants). Jednotliví uživatelé, resp. firmy mají své instance customizované
dle možností aplikace.
2.1.1
Základní charakteristiky cloud computingu dle NIST [9]
Cloud computing musí dle NIST splňovat několik základních charakteristik, aby bylo možné mluvit o
tomto označení. Základní vlastnosti cloudu jsou vesměs společné pro všechny modely služeb.
Samoobslužný systém (On-demand self-service)
Spotřebitel si zde může sám zajišťovat výpočetní kapacity, jako například výkon serveru a velikost
síťového úložiště, přesně jak potřebuje a to automaticky bez potřeby jakékoliv lidské interakce
s poskytovatelem té či oné služby.
Všeobecný síťový přístup (Broad Network access)
Vše je dostupné skrze síťové připojení nebo standardní internetové protokoly. To znamená různorodé
tlusté nebo tenké klienty (mobilní telefony, notebooky, nebo PDA)
Sdílení zdrojů (Resource pooling)
Výpočetní zdroje poskytovatele jsou sdílené, aby obsloužily vícero spotřebitelů pomocí multi-tenant
modelu s rozdílnými fyzickými a virtuálními zdroji, které jsou dynamicky přidělovány spotřebiteli dle
jeho aktuální poptávky. Spotřebitel často nemá ponětí, kde se výpočetní zdroje nalézají, ale měl by mít
možnost určit alespoň zemi, nebo datové centrum. Výpočetní zdroje zahrnují výpočetní výkon
(procesory), paměť, datové úložiště, šířku pásma síťového připojení a virtuální stroje.
Rychlá flexibilita (Rapid elasticity)
Odebírané služby mohou být zajišťovány velmi rychle a hlavně pružně. V některých případech
dokonce automaticky, aby co nejrychleji pokryly požadované počty odběratele. Tomu se často zdají
být možnosti neomezené a mohou být nakoupeny kdykoliv a v jakémkoliv množství. Stejně tak lze
prostředky zase uvolnit v období menší spotřeby.
13
Služby musí být měřitelné (Measured Service)
Cloud systémy automaticky řídí a optimalizují využívání zdrojů. Mají měřící schopnosti na určité
úrovni abstrakce odpovídající typu služby (například velikost úložiště, processing, šířka pásma, nebo
počet aktivních uživatelských účtů). Využití daného zdroje může být monitorováno, kontrolováno a
reportováno velmi přehledně pro obě strany a to jak poskytovatele, tak spotřebitele užívané služby. [9]
Dle NIST je nutné splnit všechny výše uvedené charakteristiky, aby byly naplněny podmínky, kdy
mluvíme o cloud computingu. V běžné praxi je to ovšem jiné. Zvláště plně automatizovaný
samoobslužný provoz mohou mít pouze největší poskytovatelé, kteří mají své systémy již značně
propracované a určitě se bude jednat spíše o IaaS, nebo jednoduché SaaS aplikace. V případě
komplexnějších systémů bude vždy potřeba zásahu poskytovatele. Dle autora je nutné splnit základní
podmínky flexibility, sdílených výpočetních zdrojů a síťové dostupnosti z celého světa. Nelze se ale
obejít bez měření využitých zdrojů, jak hardwarových, tak i softwarových, aby bylo možné službu
měnit dle potřeb a hlavně účtovat zákazníkovi.
2.2 Modely služeb (kategorie cloudů):
Cloud computing je moc obecným pojem, který zaštiťuje všechny konkrétní modely služeb, s kterými
se na trhu lze setkat. Běžně se využívá označení XaaS, znamenající X as a Service. X označuje daný
produkt dodávaný ve formě služby. Dnes je možné se setkat s nepřeberným množstvím XaaS termínů,
které ovšem vycházejí spíše z marketingových oddělení. Základní modely služeb jsou tři. Konkrétní
obsah, který se pod zkratkami skrývá, názorně prezentuje obrázek 1.
Obrázek 1 - NIST Example Services Available to a Cloud Consumer [zdroj: NIST]
14
2.2.1
Software as a Service (SaaS)
Software jako služba je jedním z úplně prvních pojmů, který se v 90. letech začal vyskytovat v IT a
navazoval na ASP (Aplication Service Provider). Je dokonce předchůdcem označení cloud.
Nejjednodušší definice je vypůjčena od společnosti Microsoft [20]: „Software zavedený jako
hostovaná služba přístupná přes internet. / Software deployed as a hosted service and accessed over
the Internet.“
Umožňuje zákazníkovi používat aplikace poskytovatele, běžící na sdílené cloud infrastruktuře.
Aplikace jsou dostupné díky internetu na různých klientských zařízeních skrze rozhraní tenkého
klienta, jako je třeba webový prohlížeč, nebo mobilní zařízení. Spotřebitel služby neřídí a nespravuje
cloud infrastrukturu běžící na pozadí, jako jsou sítě, servery, operační systémy, úložiště, nebo jen
individuální schopnosti aplikace. Jedinou výjimkou je specifické nastavení aplikace pro daného
uživatele.
Příkladem takovéto služby je CRM od společností salesforce.com nebo ERP od Netsuite.
2.2.2
Platform as a Service (PaaS)
Poskytovatel (cloud provider) umožňuje spotřebiteli provozovat v cloud infrastruktuře vlastní, nebo
zakoupené/pronajímané aplikace pomocí programovacích jazyků a nástrojů poskytovatele. Spotřebitel
opět nemá možnost řídit a spravovat infrastrukturu na pozadí, ale má možnost spravovat své vlastní
aplikace a také nastavení hostovacího prostředí cloudu.
Dle společnosti Gartner [1]: „PaaS je všeobecně přijatý odkaz na střední vrstvu cloud technologie,
která se označuje jako služby aplikační infrastruktury. Termín “aplikační infrastruktura” se často
zaměňuje s termínem “middleware” a naopak. PaaS je velmi medializovaný pojem, ale ve skutečnosti
má částečně neurčitý význam. Komplexní PaaS balíček, obvykle znázorňovaný v cloud diagramech, je
široká sbírka služeb aplikační infrastruktury nabízena poskytovatelem cloud služby. Komplexní PaaS
balíček by měl obsahovat technologie aplikačních serverů, database management servery (DBMs),
portály, aplikační a datovou integraci, business process management balíčky, messaging a další
podoby aplikační infrastruktury. Všechny by samozřejmě mely být nabízeny ve formě služby.“
Příkladem PaaS mohou být: Google App Engine, nebo platforma force.com.
2.2.3
Infrastructure as a Service (IaaS)
Infrastruktura jako služba označuje služby, kdy si spotřebitel přímo najímá výpočetní výkon, datové
úložiště, sítě a další fundamentální výpočetní zdroje a zároveň má možnost si nainstalovat libovolný
software, což zahrnuje operační systémy a aplikace dle jeho výběru.
I v tomto případě se o samotný cloud na pozadí stará poskytovatel, ale spotřebitel má přístup
k operačním systémům, aplikacím, úložištím a limitovaný přístup k síťovým komponentám, jako je
například firewall.
15
Jako příklad lze uvést systémy: Amazon Web Services, Rackspace nebo Microsoft Windows Azure
Někdy se také mluví o Integration as as Service (integrace jako služba) a znamená to víceméně to
samé.
Obrázek 2 - NIST Cloud Provider –Service Orchestration [zdroj: NIST]
Obrázek 2 představuje kompletní přehled, jak je cloud infrastruktura sestavena od nejzákladnějšího
hardware až po konečnou službu. Vše začíná vrstvou fyzických zdrojů (Physical Resource Layer),
která obsahuje, jak veškerý hardware od výpočetního výkonu, diskových polí, síťových prvků, tak
například i chlazení, ventilaci a vše potřebné pro provoz datového centra. Na tuto vrstvu navazuje
abstraktní vrstva pro kontrolu a virtualizaci zdrojů (Resource Abstraction and Control Layer). Ta
obsahuje systémy pro rozdělení výpočetního výkonu, vytvoření virtuálních serverů a jejich správu.
Současně také musí splňovat všech pět charakteristik cloud computingu. Až nad těmito vrstvami se
nalézají služby XaaS, které již může spotřebitel ovlivňovat.
2.3 Modely nasazení cloud computingu dle NIST [9]:
Modely nasazení (deployment models) cloudu znamenají způsob, jakým je v praxi služba
provozována. Jedná se o technologický pohled na to, kde je fyzický hardware situován, kdo se o něj
stará a jak k němu zákazník přistupuje. V druhé řadě také zdali je privátní, nebo se jedná o veřejné
prostředí, které využívá sdílené zdroje. Vědci v NIST rozdělili modely nasazení služby do čtyř
kategorií. Pro všechny tyto modely platí určité vlastnosti, někdy i omezení.
Síťová závislost
Předplatitel cloudu, neboli zákazník potřebuje fungující a bezpečnou síť pro přístup do cloudu. Pokud
síť není spolehlivá, tak ani cloud nebude z pohledu klienta spolehlivý.
16
Zůstává nutnost IT personálu
Tím, že se o servery stará poskytovatel, se spotřebiteli snižuje potřeba po IT odbornících, ale nemohou
se jich zbavit úplně. Stále se ke cloudu přistupuje skrze místní systémy, které musí někdo spravovat a
hlídat jejich zabezpečení. I pro hodnocení nabízených služeb a jejich řízení je potřeba IT personálu.
Lokace zátěže zdrojů jsou alokovány dynamicky a jsou před klientem zatajeny
K efektivnímu řízení hardwarových zdrojů cloudu musí systém zvládnout přenést zatížení mezi
různými stroji bez omezení klienta. Klient si toho nesmí všimnout a nemělo by to pro něj znamenat
žádné změny.
Riziko multi-tenancy
Úlohy (workloads) různých klientů se mohou nalézat na stejném systému, respektive hardware. Jediné
co je odděluje od sebe, je přístupová politika implementovaná poskytovatelem. Jakýkoliv zmatek nebo
chyba v přístupových právech může ohrozit bezpečnost spotřebitele. V některých případech, například
u IaaS se zatížení rozděluje do určitých míst na určitý čas, než se zmigruje jinam. U PaaS se může
zatížení serveru rozdělit na sekvenční operace a každá se provede na jiném serveru, přičemž data
mohou být uložena v geograficky rozdílných úložištích
Import/export dat a výkonové omezení
Spotřebitel služby přistupuje do cloudu přes síť a proto velké objemy dat při importu nebo exportu
mohou překročit schopnost sítě přenést data včas. Kritické a real-time procesy se tedy nedávají do
cloudu kvůli síťovým zpožděním a dalším omezením.
Společnosti, přesouvající svá data a aplikace do cloudu, se také musí vzdát ve prospěch poskytovatele
dvou výsad a těmi jsou kontrola nad daty a schopnost vidět, kdo je ovládá.
Kontrola a řízení dat (control)
Poskytovatel má schopnost rozhodnout, kdo a kde má přístup k zákaznickým datům a programům a
vykonávat akce (mazání souborů, odpojení sítě). To vše s oboustranně vysokou důvěrou, že se
nevykoná nic jiného, co by nebylo v zájmu spotřebitele (například tajná kopie smazaného souboru).
Dohled nad daty (visibility)
Spotřebitel služby ztrácí možnost důvěryhodně sledovat nakládání s jeho daty, jejich status a kdo
k nim má přístup. [9]
17
2.3.1
Privátní cloud
Infrastruktura cloudu je provozována výhradně pro účely organizace. Může být spravována buď
samotnou organizací, když má svoje vlastní datové centrum, nebo třetí stranou. Taktéž může být
umístěna přímo ve firmě, nebo u některého z poskytovatelů. Tím pádem se dělí na:
•
on-site private cloud – privátní cloud na místě u zákazníka (vlastní datové centrum),
•
outsourced private cloud – privátní cloud je umístěn v datovém centru poskytovatele, který se
stará o jeho údržbu.
Účelem privátního cloudu s vlastní infrastrukturou je efektivní využití firemního hardware a možnost
nabízet software ve formě služby svým zaměstnancům a v efektivní podobě i dodavatelům nebo
zákazníkům firmy. Většinou se ale jedná o single-tenant aplikace. Multi-tenant lze využít v případě
rozšíření poskytování daných aplikací pro další pobočky, které by tím pádem značně ušetřily na IT
zdrojích.
Outsourcovaný privátní cloud znamená fyzické oddělení virtuálního stroje od ostatních zákazníků
v datovém centru poskytovatele. Není zde tedy riziko mulitenancy a sdílených zdrojů. Zákazník
v takovém případě ztrácí určité výhody cloud computingu, ale ušetří na nákupu hardware a nákladech
na jeho správu a údržbu (odpadají kapitálové výdaje).
2.3.2
Komunitní cloud
Infrastruktura cloudu je sdílena několika organizacemi a podporuje specifickou komunitu, která má
stejné zájmy (například mise, bezpečnostní požadavky nebo strategii). S umístěním infrastruktury je to
stejné jako u privátního cloudu. Může být buď hostovaná nebo on-site.
2.3.3
Veřejný cloud.
V tomto modelu nasazení je infrastruktura cloudu k dispozici široké veřejnosti nebo velké průmyslové
skupině a je vlastněna organizací prodávající cloud služby. Jedná se o nejčastější model, který se na
trhu vyskytuje. Veřejný cloud by měl představovat tu nejčistší variantu cloud computingu, která
splňuje všechny podmínky pro cloud a přináší tak veškeré výhody i možná rizika.
2.3.4
Hybridní cloud
Hybridní cloud je spojením dvou nebo více cloudů (privátních, komunitních nebo veřejných), které
zůstávají samostatné, ale jsou spojené standardizovanou nebo proprietární technologií, která umožňuje
datovou a aplikační přenositelnost (například cloud bursting11 pro load balancing12 mezi cloudy).
11
Cloud bursting – případ, kdy spotřebitel služby využívá svůj privátní cloud a v případě potřeby vyššího
výkonu se připojí na externí cloudy. [NIST2]
12
Load balancing – vyrovnávání zátěže mezi více hardware
18
2.4 Výhody a nevýhody cloud computingu z pohledu zákazníka
Cloud computing přináší velmi mnoho benefitů, ale i některé na první pohled skryté nevýhody. Zde
jsou popsány z pohledu zákazníka ve formě SWOT analýzy. Cloud computing je brán obecně a
v některých specifických případech tedy mohou být výsledky odlišné.
2.4.1
Silné stránky
Cena služby a náklady na IT
Prvotní investice do řešení v cloudu jsou mnohonásobně nižší, než při nákupu a implementaci onpremise řešení. Toto samozřejmě neplatí v případě privátního on-site cloud řešení. Na to navazují
platební modely, které se používají (například pay-as-you-go, pay-per-user). Díky těmto modelům
není třeba vynakládat velké kapitálové investice na hardware a licenci, které vyžadují delší plánování.
To firmám umožňuje nasadit SaaS velmi rychle a tím pádem i rychleji zvýšit svojí
konkurenceschopnost. Přesto se ale firmy nevyhnou například jednorázové investici za customizaci a
integraci systému. SaaS a cloud computing obecně má i pozitivní vliv na firemní cashflow. Tento
přístup má ještě jednu velikou výhodu. Výsledná cena za řešení je naprosto průhledná a lze s ní dobře
kalkulovat. Jako příklad lze uvést CRM od společnosti salesforce.com, které v provedení Professional
stojí $12513 za uživatele na měsíc. V ceně jsou veškeré náklady na běh služby (hardware, licence,
správa serverů a systému, zálohy, atd.) a také technická podpora určité úrovně.
Guy Creese ze společnosti Gartner ovšem na svém blogu [21] píše, že v dlouhodobém horizontu je
využíván SaaS dražší i přes to, že má nižší vstupní poplatky. Dále tvrdí, že po 3 až 4 letech placení
pravidelných SaaS poplatků firma zaplatí cenu srovnatelné softwarové licence. Zákazník ale značně
ušetří na hardware, mzdách IT odborníků a dokonce i elektřině. Za veškerý běh služby, zálohy dat a
funkčnost je zodpovědný poskytovatel, který ručí za její dostupnost. Zákazník má jen operační
náklady a nehrozí mu riziko neplánovaných investic v případě výpadků služby.
Flexibilita
Nejsilnější stránkou služeb na bázi cloudu je jistě jejich flexibilita. Zákazník může měnit odebírané
množství velmi pružně a tomu odpovídá i cena právě využívaných služeb. Platí se pouze za to, co
v dané chvíli reálně potřebuje, nebo využívá. Flexibilita ale není jen o cenovém modelu. Důležitá je
schopnost systému dynamicky měnit počty uživatelů, kteří mohou využívat software a také alokovat
hardwarové zdroje. Zákazník může kdykoliv požádat o přidání operační paměti, výkonu procesoru
nebo navýšit objem datového úložiště. Snadno tedy překoná výkonové špičky, které nastávají v období
například marketingových kampaní, nebo sezónní špičky, kvůli kterým by museli v případě vlastního
IT nakupovat další hardware. Ten by v ostatních měsících nevyužili a bylo by to velice neefektivní.
Hardwarové zdroje poskytovatele se pro koncového zákazníka služby mohou zdát takřka neomezené a
13
Ceník salesforce.com [http://www.salesforce.com/crm/editions-pricing.jsp]
19
co je podstatné, jsou velmi dobře zabezpečené. Pomocí systémů na řízení zdrojů a díky virtualizaci
může firma u privátního cloudu plně využívat svůj hardware. Velmi dobře toto popisuje OnlineTech
magazín [22] v článku o tom, proč přejít k privátnímu cloudu: „Virtualizace tedy značně zvyšuje
hodnotu fyzického serveru. Namísto 5 serverů s 10 procentním využitím CPU lze díky sdílení zdrojů
virtualizovat 5 serverů na jednom fyzickém stroji. Sníží to požadované místo v racku, odběr energie a
hlavně se servery mnohem lépe spravují. Díky virtualizaci lze servery také jednoduše klonovat a při
jakémkoliv problému velmi rychle obnovit. S využitím správných systémů pro řízení zdrojů lze také
automaticky alokovat potřebné zdroje, nebo naopak vypnout server, pokud není využíván.“
Best practices a IT experti
Cloud computing ve všech formách přináší zákazníkům best practices IT oboru. V případě SaaS se
například jedná o léty propracovaný software, který by si malé a střední firmy nikdy nemohly dovolit.
Vývojáři software tyto zkušenosti získají díky spolupráci s největšími firmami v oboru a opakovaným
procedurám. Díky SaaS je lze poté jednoduše nabízet pro všechny zákazníky. PaaS a IaaS nabízí
nejnovější trendy virtualizace a vyspělá datová centra jištěná proti výpadku. Pro malé a střední firmy
je cloud computing k nezaplacení, jelikož by se u vlastní infrastruktury k takové úrovni IT nedostaly,
nebo jen velmi těžko. To se týká i výhody využívání služeb zkušených a hlavně vyškolených expertů,
kteří služby v cloudu spravují. Platit si vlastní drahé IT odborníky plus všechna jejich školení
na aktuální verze systému a IT trendy si mohou dovolit jen velké firmy. Navíc by takoví lidé ani
nebyli naplno využiti. Tento přístup je tedy efektivnější pro všechny strany.
Žádná licence na software
SaaS přináší velmi účinné využívání softwarových licencí. Již není třeba licenci vlastnit a tím odpadají
prvotní vysoké náklady na její pořízení. Zákazník si pouze vybere službu, která zahrnuje i licencovaný
software daného druhu a veškeré licenční náklady jdou za poskytovatelem. Hlavní výhodou je, že
odběratel má zaručenu vždy nejnovější verzi, aniž by musel platit maintenance14 licence a upgrady
na nové verze software. Cena licence je samozřejmě započítána do pravidelného poplatku za SaaS, ale
jedná se o zlomek částky.
Automatické aktualizace a nové verze
Poskytovatel se stará o aktuálnost aplikace a pro zákazníka jsou tedy aktualizace, nebo upgrady
na novou verzi automatické. Přestože jsou změny vždy předem hlášeny, tak s sebou přináší i jistá
rizika. Automatický update občas může způsobit nečekané změny, které nemusí být vítány. V případě
větších změn v aplikaci je možné narazit na potíže v integraci s ostatními, například již
nepodporovanými systémy organizace. To se děje spíše výjimečně. Naopak upgrade on-premise
systému vždy vyžaduje pečlivé plánování, upozornění všech uživatelů a může znamenat i výpadek
systému, což ovlivňuje chod firmy. [23] K častým upgradům se váže další deviza, a to že díky
14
maintenance – udržovací poplatky za software (v překladu znamená údržba)
20
nepatrným změnám není nutné zajišťovat školení uživatelů. U klasických licencí je třeba instalovat
drobné aktualizace a nové verze se vydávají většinou v ročním nebo delším cyklu a pak může
následovat drahé školení uživatelů na novou verzi. Jsou ale časté i případy, kdy firma nemá peníze na
novou verzi, nebo naopak nová verze není plně kompatibilní s ostatními systémy, a z toho důvodu
provozují zastaralou verzi několik let. Poté ale vždy přijde okamžik nutné změny, který kromě
nutného školení často znamená kompletně novou implementaci. Takové případy jsou velmi nákladné a
mohou vést i ke změně řešení. [21]
Dostupnost služeb
SaaS aplikace se distribuují skrze „tenkého klienta“, kterým je v naprosté většině webový prohlížeč.
Standardem je dnes dostupnost služeb 99,95 % a více s dopředu plánovanými výpadky kvůli údržbě.
Důležitým prvkem v hodnocení dostupnosti cloud služeb je kvalita internetového připojení. Dnes je
sice internetová konektivita samozřejmostí, ale cloud computing je na rozdíl od on-premise aplikací
na internetové síti naprosto závislý. Vyžaduje tedy mnohem větší šířku pásma, tzn. rychlost připojení a
také rychlejší odezvy sítě. Čím více se využívají cloud služby, tím roste i objem přenesených dat.
Internetové připojení by tedy nemělo být zatíženo nízkými FUP15 limity, které se mohou objevit tam,
kde je menší dostupnost kvalitního připojení a je třeba tyto limity zavádět. V menších městech a
obcích může být právě kvalita připojení faktorem, který ztíží, nebo zabrání využívání cloud služeb.
Výkon SaaS aplikací není o nic menší, než jakých dosahují instalace u zákazníka. Díky sdíleným
zdrojům je cloud také schopný pojmout zátěžové špičky mnohem lépe, než dedikovaný hardware
daných parametrů. Úzkým hrdlem může být právě konektivita, která ovlivňuje rychlost přenosu dat
mezi cloudem a klientem. Uživatel může snadno dojít k názoru, že daná služba je pomalá jen z tohoto
důvodu. Společnost Cisco16 připravila Cloud Readiness Index (index připravenosti na cloudové
technologie), kterým hodnotí jednotlivé regiony na úrovni kontinentů a států v parametrech, jako je
rychlost připojení a odezva sítě.
Cisco dále prohlásilo své předpovědi ohledně datových přenosů [24]:„Přenos dat v datových centrech
by měl do roku 2015 vzrůst 4krát až na 4,8 zetabajtu ročně, přičemž největší podíl na tomto nárůstu
má přenos dat v cloudu. Celkově tak přenos v cloudu roste dvakrát rychleji než celkový přenos
v datových centrech. V roce 2014 by mělo dojít k převážení tohoto poměru a nadpoloviční většina
operací bude zpracovávána datovými centry na bázi cloudu. Z cloudu se tak postupně stává zásadní
prvek informační infrastruktury. Ze studie Cisco Connected World Report (2010) vyplývá, že 78 % IT
organizací na celém světě využívá či zvažuje využít cloudové technologie jako součást své IT strategie.
To je důkazem toho, že nastává doba cloudu. Drtivá většina přenosů v datových centrech však není
způsobena požadavky koncových uživatelů, ale samotnými datovými centry, ve kterých běží procesy
jako zálohování nebo replikace. Do roku 2015 by tak mělo být generováno 76 % veškerých datový
15
16
FUP – Fair Usage Policy – zajišťuje spravedlivé využívání internetového připojení
Cisco – lídr v oblasti síťových prvků (www.cisco.com)
21
přenosů v datových centrech jimi samotnými. Na služby pro koncové uživatele připadá 17 % datového
provozu a zbývajících 7 % připadá na přenos dat mezi datovými centry.“
Mobilita
SaaS aplikace podporují dnešní trendy pracovat odkudkoliv mimo kancelář. S nástupem chytrých
telefonů a tabletů je možné aplikace snadno přenést i na tyto platformy. Uživatelé pak mohou mít
přístup k důležitým obchodním datům kdykoliv a hlavně odkudkoliv. U on-premise řešení je integrace
do mobilních platforem složitější, protože systémy na to často nejsou připraveny. SaaS verze jsou od
začátku navrhovány pro webový a mobilní přístup. Dle studie CIO Economic Impact survey [4] z roku
2011 se mobilní aplikace rychle rozrůstají. 67 % respondentů plánuje zvýšit rozpočty na mobilní
aplikace (v listopadu 2010 to bylo jen 53 %). Podle 79 % CIO je pro zvýšení produktivity práce nutné
podporovat mobilní zařízení a adekvátní aplikace.
Technická podpora a SLA
Technická podpora cloud služeb by měla být stejná, jako je jejich dostupnost. Je to nutné již z důvodu
nabízení služeb do zemí s různým časovým pásmem, ale také kvůli počtu zákazníků. V případě
jakéhokoli globálního výpadku poskytovatele je nutné chybu co nejdříve odstranit. S on-premise
software firmy běžně nabízejí podporu 8h denně v pracovní dny. Pokud se tedy něco stane v pátek
odpoledne, tak je nutné čekat na řešení až do pondělí. Pro oba případy se dnes ale podepisují servisní a
Service Level Agreement smlouvy, které přesně vymezují co má zákazník obdržet, jaký je rozsah
technické podpory a případné pokuty za nedodržení podmínek. Výhodnější SLA pro zákazníka sice
stojí více peněz, ale zase má zajištěnu potřebnou úroveň podpory. Lze tedy říci, že s cloudem
automaticky přichází i intenzivnější technická podpora.
Bezpečnost dat
Počáteční strach a obavy ze ztráty nebo zneužití dat při využití cloudu se postupně vytrácejí.
Poskytovatelé cloud služeb si nemohou dovolit jakoukoli ztrátu dat, jelikož by mohli přijít nejen o
postiženého zákazníka, ale rychle by ztratili důvěryhodnost a tím i stávající, nebo potencionální
zákazníky. Naopak při nějakém problému se ztrátou dat je na tom spotřebitel lépe než u vlastního
řešení, poněvadž to může řešit na úrovni obchodního zákoníku a uvalit sankce dle SLA smlouvy.
Pokud zapříčiní ztrátu dat vlastní zaměstnanec při práci na vlastním serveru firmy, tak nelze vymáhat
téměř žádnou náhradu škody. Jedině, pokud by zaměstnanec šířil interní informace a měl podepsanou
NDA smlouvu. Dalším prvkem v bezpečnosti je fakt, že se data neukládají na počítač uživatele. Přesto
všechno je samozřejmě možné, že se nějaké potíže vyskytnou a pak záleží na úrovni sepsaných SLA a
NDA17 smluv.
17
NDA – Non-Disclosure Agreement – Smlouva o mlčenlivosti
22
Hlavní otázkou bezpečnosti v cloudu zůstává, kdo má k datům přístup a jak je tento přístup chráněn.
Ať už na úrovni uživatele, který se systémem pracuje, tak z pohledu poskytovatele a jeho pracovníků.
V datových centrech se hlídá jak fyzický přístup, tak hlavně ověření identity uživatelů, kteří k datům
vzdáleně přistupují. Dnes již často nestačí pouhá identifikace pomocí jména a statického hesla, ale
využívají se i dynamická jednorázová hesla, nebo bezpečnostní tokeny a hardwarové klíče.
Salesforce.com například při přihlášení z neznámého počítače vyžaduje ověření přes firemní
e-mailový účet. Poté se daný počítač zařadí do schválených zařízení. Je to určitá ochrana při vyzrazení
přihlašovacích údajů uživatele. Toto vše se řídí na úrovni Identity Managementu18, který řídí
přihlašovací politiky uživatelů. Databáze uživatelů by měla být vždy u poskytovatele. Neméně
důležité je i nastavení systémových rolí a přístupových práv k dalším datům a operacím. O to se stará
IRM (Information Rights Management), který stanovuje přístupová práva k na úrovni dokumentu,
nebo souboru. Identity management aplikace jsou dnes již také v cloudu. Jako příklad lze uvést služby
firem Ping Identity19, Okta20, nebo Symplified21. Tyto služby nabízejí ověření identity uživatele a
přihlášení do požadovaných cloud služeb. Podporují integraci s Microsoft Active Directory22, která je
velmi rozšířená díky Microsoft Windows Server operačním systémům a dokonce i Single Sign-On23.
SSO nabízí uživatelům přístup do všech systémů, resp. ke všem službám, ke kterým mají přístup, na
základě pouze jednoho přihlášení. Kromě identity a samotné informace musí být cloud bezpečný i na
úrovni infrastruktury ze které je sestaven. To znamená využití bezpečných komponent a dodržování
standardů. [25] [26] Před výběrem určitého poskytovatele služby je dobré si ověřit, jakou úroveň
detailu v oblasti přístupových práv nabízí a zdali je schopen spolupracovat se službami na řízení
identity a podporuje SSO.
O bezpečnost dat při cestě z cloudu poskytovatele do prohlížeče uživatele se stará protokol SSL24,
respektive jeho nástupce TLS25, kteří zajišťují autentizaci a šifrování dat. Toto zabezpečení je
dostatečné a svědčí o tom i praxe internetového bankovnictví většiny tuzemských bank. Stránky pro
ověření pravosti a šifrovaný přenos potřebují certifikát. Tuzemské banky nejčastěji používají SLL
certifikáty společnosti VerySign26. Ten samý certifikát využívá i služba salesforce.com. Pokud firma
potřebuje silnější zabezpečení spojení, tak se využívá VPN27 připojení případně i na úrovni routerrouter pro vytvoření bezpečného tunelu.
18
Identity Management – řízení identity
Ping Identity - https://www.pingidentity.com/
20
Okta - http://www.okta.com
21
Symplified - http://www.symplified.com
22
MS Active Directory – Adresářová struktura s uživateli a jejich právy
23
SSO – Single Sign-On – jednotné přihlášení uživatele do více systému/k více službám
24
SSL – Secure Sockets Layer – protokol pro zabezpečenou komunikaci http
25
TLS – Transport Layer Security - protokol pro zabezpečenou komunikaci http
26
VerySign – www.verysign.com (SSL certifikáty)
27
VPN – Virtual Private Network – virtuální privátní síť (vytvoří tunel mezi dvěma PC nebo sítěmi)
19
23
V dnešní době je samozřejmostí plnění normy kvality ISO 9001 a bezpečnosti informací ISO 27001.
Kromě zákona o ochraně osobních údajů a zákona o datových schránkách a archivaci dokumentů na
10 let v případě elektronického zpracování se v ČR nic specifického nevyžaduje. Například v Americe
je nutné dodržovat zákony typu HIPAA (Health Insurance Portability and Accountability Act / Zákon
o odpovědnosti za přenos údajů o zdravotním pojištění) při práci s daty pacientů, nebo například velmi
zmiňovaný Sarbanes–Oxley Act. Někteří poskytovatelé zavádějí PCI DSS (Payment Card Industry
Data Security Standard), což je standard ohledně bezpečnosti při zpracování údajů z platebních karet.
Ve finančním sektoru se také v Americe vyžaduje soulad se standardem SAS 7028 (Statement on
Auditing Standards No. 70) pro průhlednost a kontrolu řízení organizace. Objevují se dva typy I a II,
které se liší dobou účinnosti. SAS 70 nahradil 15. června 2011 standard SSAE 1629 (Statement on
Standards for Attestation Engagements No. 16), který slouží pro účely poskytování nezávislého
ověření souladu se zásadami řízení v organizacích poskytujících služby. Audit podle obou těchto
standardů umožňuje nezávislé ověření souladu se zásadami prvků zabezpečení a jejich účinnosti. [25]
[27] [28]
Dle zpětného zhodnocení odhadů na rok 2011 byla společností Forrester ověřena hypotéza, že cloud je
velmi bezpečný. Přední poskytovatelé cloud služeb získávají nejdůležitější bezpečnostní certifikáty
(ISO 27001, ISO 2000130, PCI-DSS a FISMA) a také prokazují transparentní provozní praktiky.
Zacházení s daty je na úrovni a hlavní datová centra jsou v Evropě a Asii. Pokrokem je ovšem
skutečnost, že si i samotní zákazníci začali uvědomovat svojí zodpovědnost týkající se bezpečnosti
cloudu. [29]
Veškeré bezpečnostní výhody jsou vykoupeny nutností vzdát se kontroly nad svými daty a nad tím, co
se s nimi zrovna děje, kdo je může vidět, měnit a mazat. Vše by proto mělo být řádně ošetřeno
smlouvou.
Nižší implementační rizika
Tím, že zákazník neinstaluje vlastní hardware, operační systémy, databáze, atd., se snižuje riziko
možných potíží během implementace jako je zpoždění dodávky nebo kompletní krach implementace.
Všechna tato rizika, která by mohla implementaci ohrozit, se přenáší na poskytovatele, který má již
svou infrastrukturu hotovu, takže se i celkově snižují. [49]
Nižší provozní rizika
Veškerý provoz, od zajištění elektřiny až po správné nastavení software má na starost poskytovatel a
tím pádem se snižují i provozní rizika.
28
SAS 70 – americký auditní standard pro společnosti poskytující služby
SSAE 16 – americký standard pro reporty
30
ISO 20001 - IT Service Management (ITSM) - certifikace o řízení a implementaci IT
29
24
Rychlost implementace
Oproti on-premise systémům je implementace výrazně rychlejší. Odpadá nutnost čekat na dodání
hardware, instalovat operační systémy a databáze. Zákazník v ideálním případě pouze obdrží
přístupové údaje pro přístup do aplikace a může ji začít používat. Při on-premise implementaci má
zákazník snahu skoro vše přizpůsobit své organizaci a tím se také implementace protahuje. V praxi se
často stává, že po roce úprav se vrátí k výchozímu nastavení aplikace a zjistí, že zbytečně vyhodil
peníze. Customizace31 dle potřeb zákazníka si u SaaS vyžádá stejný čas jako u on-premise. Celková
doba od oslovení dodavatele po začátek používání aplikace je vždy kratší.
Možnosti testování
Zřídit testovací účty u SaaS aplikace je otázkou pár minut. Většinou stačí registrace na stránkách
poskytovatele a hned je možné si aplikaci prohlédnout. U klasického software znamená testování
několik kroků. Nejdříve je třeba zjistit, zdali dodavatel software vůbec instalaci a trial licenci
poskytuje. Poté je nutné připravit fyzický, nebo virtuální stroj, kam je možné produkt nainstalovat. Již
při instalaci může zákazník software ovlivnit a následně s jeho funkčností nebýt spokojen. To se u
SaaS testování stát v podstatě nemůže. Po obdržení přístupových údajů má zákazník funkční
aplikaci/službu a může začít testovat. Zákazník často testuje aplikaci ve stejném stavu, jako bude její
produkční verze. Toho lze u on-premise docílit mnohem hůře a někdy to ani není možné. SaaS tedy
nejen, že zkracuje dobu nutnou na implementaci software, ale i testování, které ji předchází.
Ekologická zátěž
Cloudová řešení jsou mnohem šetrnější k životnímu prostředí. Nejen, že je v konečné fázi potřeba
méně fyzického hardware a tím pádem bylo použito méně toxických látek a vody k jeho výrobě, ale
také se mnohem méně starého hardware vyhazuje na skládky. Servery jsou efektivněji využívány a
spotřebuje se tedy i méně elektrické energie. Tím, že se veškeré výpočty provádějí na serverech, tak
není třeba tak výkonných koncových stanic. Z toho plyne, že může firma používat i starší koncové
stanice a neobměňuje je tak často.
Centralizované řízení a data
Pokud má organizace více poboček, tak je výhodou mít data na jednom centrálním bodě. Buď
ve formě privátního cloudu na centrální pobočce nebo u SaaS poskytovatele. Ani v jednom případě
není nutno spravovat decentralizované systémy a řešit jejich synchronizaci a integraci.
Zálohování dat a obnova dat po havárii (Disaster Recovery Plan)
Při využití cloud služeb nese veškerou zodpovědnost za dostupnost a zálohu firemních dat
poskytovatel. Díky tomu, že data nejsou fyzicky ve firmě, se není třeba obávat chyb hardware nebo
například přírodních katastrof. Dle výzkumu společnosti Proact [30] mezi 500 dotazovanými firmami
31
Customizace – uzpůsobení software dle potřeb zákazníka (z anglického slova customization)
25
trvá 54 % firem podnikajících v Česku obnovit svá data více než 1 den. Jejich připravenost nejlépe
shrnuje následující graf.
Obrázek 3 - Schopnost firem obnovit data po havárii [zdroj: Proact, 2011]
Alarmující na tom je hlavně skutečnost, že 15% firem není schopná obnovit svá data vůbec.
V takových případech záleží na stáří dat, jelikož stará data nemusí mít tak značný vliv, jako například
obchodní data posledních měsíců, kvůli kterým firma může přijít o rozjednané zakázky a tím pádem i
zkrachovat. Analýza dále tvrdí, že pouze 38% společností je schopno obnovit jen data starší několik
dní. Přichází tedy o aktuální data. Vzhledem k tomu, že je běžně i hodně důležitých dat pouze
na osobním počítači uživatele, SaaS přináší značné zlepšení a určitou jistotu pro firmy. Ušetří také
náklady nutné na tvorbu pravidelných a častých záloh a jejich zabezpečení. Pro jasnou představu lze
uvést srovnání CRM běžícího na serveru zákazníka zasaženého požárem oproti CRM formou služby.
V prvním případě je nutné zajistit nový hardware, odborný personál na jeho instalaci, obnovu instalace
CRM a nahrání dat ze zálohy (pokud nějaká existuje). Tento proces může trvat i několik dní. Při
využití SaaS se pro firmu nic nemění. I v případě zasažení koncových stanic lze k firemním datům
přistupovat dále odjinud. Dnes již fungují i zálohy ve formě služby. Firma pouze posílá svá data
k poskytovateli a nemusí se o nic více starat. Jako příklad lze uvést Amazon Web Services32.
Globální působnost firmy
Pro mezinárodní firmy, nebo společnosti s více pobočkami obecně má cloudové řešení velké přínosy.
Při zakládání nové pobočky lze využít předchozích nastavení systému a ušetřit značné implementační
náklady. Komunikace s dodavatelem může mít u zákazníka na starost jedno IT oddělení pro celý svět.
Díky multi-jazykovým a multi-měnovým službám lze systémy jednoduše spojovat pro efektivnější
obchodování a také jednotné vykazování finančních a jiných výsledků.
32
Amazon Web Services - http://aws.amazon.com/backup-storage/
26
2.4.2
Slabé stránky
Cloud computing je logický nástupce virtualizace a load balancingu a sám o sobě by neměl přinášet
žádná ryze technologická negativa. Ne každý druh aplikací se ovšem pro multi-tenant provoz v cloud
prostředí hodí. Více o vhodnosti aplikací se píše v odstavci 2.6. Vhodnost aplikací pro cloud.
Problém s umístěním dat
Data jsou fyzicky uložena u poskytovatelů služeb a tím pádem spotřebitel nad nimi nemá přímou
kontrolu. Jak již bylo psáno dříve, musí plně důvěřovat poskytovateli, že je s daty nakládáno, dle
dohody. Potenciálně zde existuje riziko úmyslného či neúmyslného zneužití, či poškození dat. Tomu
se ale nelze úplně ubránit ani u instalace on-site. Spíše je tedy nutné najít spolehlivé a důvěryhodné
poskytovatele s bezpečnostními certifikáty a mít tyto otázky ošetřené smluvně (SLA a NDA).
V dnešní době je zabezpečení dat u předních poskytovatelů na velmi vysoké úrovni. Ve většině
případů i mnohem vyšší, než jsou organizace schopné dosáhnout vlastními prostředky.
Data mohou být fyzicky uložena v jiné zemi, než sídlí poskytovatel a hlavně zákazník. Tato skutečnost
může představovat určité právní problémy, například v oblasti zpracování osobních nebo citlivých
údajů, autorských práv apod. Specifické požadavky pak mohou mít také orgány veřejné správy.
Někteří poskytovatelé služeb jsou si vědomi tohoto nedostatku a nabízejí řešení. Například
v salesforce.com zavedli DRO – Data Residency Option [31]. To znamená, že společnosti si mohou
zvolit, kde chtějí, aby byla jejich data fyzicky uložena, a zároveň nepřicházejí o výhody multi-tenant
aplikací, respektive služeb. Amazon S3 také nabízí možnost výběru umístění serverů na US Standard,
US West (Oregon), US West (Northern California), EU (Ireland), Asia Pacific (Singapore), Asia
Pacific (Tokyo), South America (Sao Paulo). [32]
Závislost na poskytovateli služeb
Značná závislost na poskytovateli služby a jeho řešení je další možnou slabinou. Odebírané
softwarové a hardwarové řešení je dáno poskytovatelem a obvykle jej nelze moc ovlivnit. V případě
převahy odebíraných služeb od jednoho dodavatele může být firma v nevýhodné vyjednávací pozici
například ohledně cenových podmínek. Může nastat případ, že firma vyvine aplikaci, která vyžaduje
určitý typ hardware, který poskytovatel cloudu nevlastní. Tím pádem si musí zajistit hardware sama a
jít cestou on-premise řešení nebo privátního cloudu. Dále je velmi důležité zmínit, že změna
poskytovatele služby může být velmi komplikovaná. Neměla by ale být nákladná, jako v případě
změny on-premise řešení. Záleží také na možnostech importu a exportu dat a možnosti přenést
business procesy do jiného systému. To se odvíjí také od toho, zdali poskytovatel používá proprietární
technologie, nebo jde cestou standardů. V prvním případě se zvyšuje závislost na poskytovateli a
ztěžuje případnou změnu. Už i přechod z klasického modelu provozování IS/ICT na cloud computing
může být poměrně náročný proces, který může zahrnovat jak výměnu, úpravu či vytvoření potřebných
aplikací tak i migraci dat ze stávajících systémů. Z technického hlediska to může být poměrně
27
komplikovaný úkol. Nesmí se zapomínat na exit strategii, která je popsána v odstavci 4.5.3. [33]
Závislost podporuje i ztráta IT expertů, kteří nejsou u SaaS potřeba.
Možnosti customizace
V případě klasického SaaS, kdy pronajímanou službu využívá nespočet dalších firem a jedná se tedy
o multi-tenant aplikaci, nejsou moc velké možnosti customizace. Již z povahy multitenancy vychází,
že se odběratelé dělí o stejný softwarový kód, který je schopný běžet ve více instancích na virtuálních
strojích. K tomu se váže určitá obecnost a nemožnost přizpůsobovat aplikaci na míru jedné straně,
protože druhá to vyžaduje jinak. V software se tedy používají oborové best practices a možnosti úprav
aplikace se smršťují na její parametrizaci a možnost nastavit workflow neboli následnost akcí.
Samozřejmostí jsou možnosti vlastního pojmenování polí, nastavení jazyka a měny.
U privátního cloudu se často nasazují single-tenant aplikace, kde jsou možnosti přizpůsobení omezené
jen daným software. Existuje i střední cesta, kdy zákazník nakoupí software licenci a provozuje
aplikaci v cloudu u poskytovatele, kde má vyhraněný svůj virtuální stroj. Poskytovatel se mu stará i o
daný software a díky single-tenant nasazení mohou být úpravy jakékoliv. Dle dřívějšího členění se
jedná o outsourced private cloud. Zákazník poté platí za odebíranou službu a úpravu kódu. Nevýhodou
je, že musejí nejdříve zakoupit i softwarovou licenci. Přichází tedy o flexibilní licencování, ale
zůstávají ostatní ušetřené náklady na hardware a související věci.
Vyšší provozní náklady na konektivitu k internetu
Vzhledem k podstatě cloud computingu, kdy jsou služby poskytovány prostřednictvím internetu,
přirozeně roste objem přenesených dat a současně se zvyšují požadavky na přenosovou rychlost a
latenci spojení. Tyto vyšší náklady však mohou být kompenzovány mnohem většími úsporami
v jiných oblastech. [15]
Guy Creese ve svém blogu [21] zmiňuje ještě velmi zajímavou věc. Tím, že SaaS nepřináší potřebu
vysoké investice na začátku, tak si firmy tolik své nákupy nepromýšlí. Dříve se za software neplatilo
kontinuálně a firmy používali určitou verzi produktu několik let, přes to, že již byla nová verze. Nákup
nové verze ale znamená velkou investici, školení jak uživatelů, tak administrátorů a také migraci dat.
V takových situacích se firmy poohlédnou, zdali na trhu není jiná a levnější alternativa, která by mohla
přinést více a často logicky přejdou k SaaS. Pointa příspěvku je v tom, že u SaaS licenčního modelu
takováto situace nenastává a platí se celkem stabilní částky za vždy aktualizovaný software. Problém
nastává, když firma zjistí, že má sice aktuální software, ale konkurence je už mnohem dál. Chybí zde
tedy ta velká investice, která by firmu přinutila se porozhlédnout po jiném řešení.
28
2.4.3
Příležitosti
Zákazníci mohou vyzkoušet a rychle začít používat jakékoliv cloud služby
Zákazníci mohou velmi snadno vyzkoušet a samozřejmě i provozovat systémy, které jim byly
v klasickém on-premise modelu zapovězeny. Například produkty společností SAP nebo ORACLE
byly svázány vždy jen s velkými podniky a nyní je formou SaaS mohou používat i menší firmy. Bez
velkých rizik je dnes možné využívat software, který vyvinula a poskytuje společnost z druhé části
planety, a v zemi zákazníka ho nikdo nedodává a nepodporuje. V případě špatné volby lze díky
pružnému licenčnímu modelu rychle od dodavatele odejít a neznamená to vysoké finanční ztráty.
Pokud tedy nebyla sepsána SLA smlouva na dobu určitou.
Sociální sítě
Sociální sítě, jakými jsou Facebook, LinkedIn, Twitter a jiné, jsou velmi oblíbené u veřejnosti po
celém světě a postupně prostupují i do firemního sektoru. Vývojáři podnikových aplikací se snaží
nabídnout firmám podobné možnosti komunikace, na kterou jsou uživatelé zvyklí. Například
společnost salesforce.com v roce 2010 zavedla Chatter [34], což je nadstavba jejich CRM řešení.
Chatter se velmi podobá sociální síti Facebooku a umožňuje sdílet myšlenky, jednoduše komentovat
nastalé situace, sdílet soubory s celou firmou nebo ve skupinách a mnohem více. SaaS model
podporuje jednoduchost zavedení takovýchto řešení a také dostupnost pro koncové uživatele. Celkově
tedy vytváří příležitosti pro nové aplikace. Jako příklad lze uvést platformu force.com společnosti
salesforce.com, která zajišťuje prostředí pro nasazení vlastních aplikací zákazníků, nebo jiných
vývojářů.
Nezávislost na interních lidských zdrojích a jejich fluktuaci
S on-premise řešením se váže riziko odchodu klíčových odborníkům, kteří systém spravují. To u SaaS
nehrozí a služba by měla být stále stejná i s expertní podporou v případě potřeby.
2.4.4
Hrozby
Únik a ztráta dat
Při použití veřejného cloudu mají firmy svá data uložena v datových centrech poskytovatele služeb.
Nemají je tedy plně pod kontrolou a u méně stabilních a prověřených providerů je určité riziko úniku
nebo ztráty dat.
S únikem dat souvisí i takzvaná teorie sdíleného prostředí. Ta se zabývá problematikou využívání
stejných procesorů, pamětí a hlavně diskových úložišť. Data jednotlivých uživatelů služby jsou
oddělena pomocí přístupových práv a politik. Může tedy nastat situace, že hlavní konkurenti na trhu
budou mít svá data na stejném pevném disku. Výhodou poskytovatele je to, že se to nikdy nedozví,
pokud bude zabezpečení fungovat správně
29
Nedostačující a nespolehlivá konektivita
V případě, že má firma svá data umístěna geograficky jinde, než sídlí a využívá SaaS služeb, tak se
stane konektivita velmi důležitým parametrem pro kvalitní odběr služeb. Může se stát, že cloud služby
mají odezvu dostatečnou, ale internetové připojení s úzkým pásmem a nevhodnou agregací učiní
služby nepoužitelné. Dalším rizikem je úplný výpadek konektivity. Například u e-mailového serveru,
provozovaného ve formě služby, kdy zákazník využívá pouze webový IMAP33 klient je uživatel při
výpadku konektivity náhle bez všech e-mailů. Otázkou je, zdali je to natolik kritické, poněvadž stejně
žádné odesílat nemůže a často s internetem přestává fungovat i IP telefonie. Do on-premise systémů
by přístup zůstal, ale stejně přestanou fungovat další B2B systémy. Ztráta a nízká kvalita konektivity
je tedy velkou hrozbou všech IT/ICT služeb, ale cloud computing postihuje ve větší míře.
Krach nebo významné změny na straně dodavatele
Krach poskytovatele služeb může zapříčinit značné problémy a těžko se dopředu odhaduje.
Dodavatele může také koupit jiná firma a změnit portfolio služeb, případně dané služby nadále
neposkytovat. Riziko je i vývoj aplikace směrem, který firmě nevyhovuje a musí se mu přizpůsobovat.
To vše může ohrozit dodávku odebíraných služeb a způsobit zákazníkovi škody.
2.4.5
Shrnutí SWOT analýzy
Níže uvedená tabulka shrnuje výsledky, které přináší cloud computing zákazníkovi. Pozitiva a
příležitosti silně převyšují negativa a možné hrozby.
Tabulka 1 - SWOT analýza - cloud computing z pohledu zákazníka
Silné stránky
Slabé stránky
Nízké prvotní náklady
Závislost na poskytovateli
Nevyžaduje investici do HW a licence
Náročnost na konektivitu
Vysoká dostupnost aplikací
Kontrola nad daty
Flexibilita/Škálovatelnost
Bezpečnost dat
Nižší implementační rizika
Nižší provozní rizika
Není třeba platit IT experty
Aktuálnost verze software
Nízká ekologická zátěž
Centralizace dat
Mobilita
Záloha dat a obnova po havárii
33
IMAP - Internet Message Access Protocol
30
Rychlá implementace a možnosti testování
Převažují operativní náklady
Globální působnost firmy
Příležitosti
Hrozby
Dostupnost nových aplikací
Únik a ztráta dat
Prostředí pro vlastní aplikace
Výpadek konektivity
Sociální sitě
Krach nebo změny u dodavatele
Nezávislost na interních zdrojích a jejich
fluktuaci
2.5 Výhody a nevýhody cloud computingu z pohledu poskytovatele
2.5.1
Silné stránky
Pravidelné příjmy z pronájmu služeb
Díky pravidelným poplatkům, které zákazníci platí, lze velmi dobře plánovat cashflow. Poskytování
služeb je většinou podmíněno smlouvou mezi oběma subjekty, takže jsou příjmy pro poskytovatele
relativně jisté a pravidelné. U klasického prodeje řešení s licencí je vždy velký jednorázový příjem a
pak záleží, zdali zákazník bude platit, nejčastěji roční, maintenance poplatky a servisní podporu.
Během roku se ale může ve firmě u zákazníka změnit situace jak ve strategii, tak například
ekonomická. Další příjem tedy není jistý, pokud není podmíněn smlouvou.
Silnější vazba se zákazníkem
Prodej služby zajistí větší kontrolu nad vztahem dodavatel-zákazník a nutí zákazníka více s firmou
komunikovat. Předejde se tak spíše stavům, kdy zákazník odejde jinam a dodavatel se nespokojenost
dozví až při jeho odchodu.
Výhody plynoucí z multitenancy (modelu 1 : N)
Jedná se zejména o možnost nabídnout zakoupenou nebo vlastními silami vyvinutou aplikaci více
zákazníkům současně. Díky mult-itenant architektuře a virtualizaci má poskytovatel usnadněnou práci
v oblasti implementace. Zaměstnanci SaaS poskytovatele pak díky opakovanému nasazení aplikace
u více zákazníků dosahují vyšší produktivity. [5]
Úspory z rozsahu
V případě vlastního datového centra dochází k úsporám z rozsahu. Hardwarové zdroje a zakoupené
licence jsou sdíleny, takže se náklady rozdělí mezi více zákazníků. Využiti zdrojů je efektivnější a
díky tomu může dosáhnout rychlejší návratnosti investovaných prostředků. [5]
31
Relativně vysoké náklady na změnu poskytovatele ze strany zákazníka
Záleží na povaze SLA smlouvy, ale často jsou ve smlouvě velké pokuty za její předčasné ukončení.
Z toho důvodu se zákazníkovi finančně nevyplatí měnit poskytovatele služby [5]
Jednoduchá a plně přístupná správa SW i HW
Poskytovatel má veškerý hardware ve své moci. To znamená nepřetržitý fyzický přístup k hardware a
tím pádem i k software na něm nainstalovaném. Již není nutné vyjíždět na zásahy do sídla zákazníka.
Může se tak vyvarovat problémům, kdy například zákazník software nainstaluje na slabý nebo
nespolehlivý stroj a odráží se to pak na běhu aplikace. I situacím, kdy řeší chyby aplikace přes
omezené vzdálené připojení a nemá dostatek informací.
Řízení incidentů a změn
Na předchozí bod navazuje i výhoda z globální změny verze systému a opravy případných chyb.
Snižuje se náročnost podpory zákazníků a zrychlují se reakční doby.
2.5.2
Slabé stránky
Vysoké náklady na zřízení datového centra.
Poskytovatel cloud služeb potřebuje velmi výkonné datové centrum (centrum sdílených služeb), které
jednak dokáže obsloužit vzrůstající počet zákazníků a jejich potřeb, ale bude také vystavěno dle
nejmodernějších standardů pro zálohování dat a chráněno proti výpadkům. To s sebou nese velké
počáteční investice a může být bariérou pro vznik nových poskytovatelů služeb. Řešením je pronájem
hardware infrastruktury u specializované společnosti (datová centra, tele-house, centrum sdílených
služeb), ale to s sebou nese nevýhody ve formě třetí strany, která může způsobit výpadky nebo jiné
potíže. Datová centra by měla splňovat technologické klasifikace Tier. Tato klasifikace je dílem
společnosti Uptime Institute, Inc. Začala se používat v roce 1995 a v podstatě popisuje historii vývoje
datových center. Klasifikace rozděluje datová centra na 4 úrovně, které se liší v kritériích na napájení,
chlazení, údržbu a další vlastnosti.
Tier I – Základní datové centrum dle klasifikace Tier 1 představuje neduplikovaný provoz. Poprvé se
objevilo v roce 1960. Nemá zdvojené napájení ani chlazení, a má pouze jeden přívod elektrické
energie do racku34. Systém musí být offline při plánovaném i neplánovaném výpadku. Při potřebě
údržby kterékoli části tedy přestane fungovat celý systém. Může, ale nemusí obsahovat záložní
generátor a UPS35 proti výpadku proudu. Používá se pouze pro vlastní IT firem, kde není třeba provoz
24/736, ale stačí pokrýt provoz pracovního týdne. Řešení má tedy relativně malou dostupnost
maximálně 99,671 %. Výpadek může být až 28,8 hodin v roce.
34
Rack – standardizovaná skříň na počítačový hardware
UPS – Uninterruptible Power Supply – nepřerušitelný zdroj elektrické energie
36
24/7 – nepřetržitý provoz 24 hodin a 7 dní v týdnu
35
32
Tier II – Datové centrum se zdvojeným napájením a chlazením. Stále má jednoduchý přívod energie
do racku. Musí obsahovat redundantní N+1 UPS a generátor. Údržba přívodu energie a ostatních
systémů si vyžádá výpadek. Takovéto datové centrum musí být opět vypnuto při plánované údržbě.
Dostupnost se pohybuje do 99,749 %. Výpadek může trvat až 22 hodin ročně. Vyskytuje se například
u internetových firem, které neplatí žádné pokuty za výpadek služby.
Tier III – Datové centrum je možno spravovat konkurenčně, což znamená, že údržba jakékoli části lze
provést bez výpadku. Má oproti Tier II několik přívodů elektřiny a jakýkoli elektrický prvek může být
vyměněn, aniž by bylo nutné vypnout počítačové systémy. Dostupnost tohoto datového centra se
pohybuje do 99,982 %, což znamená výpadek na 1,6 hodiny ročně. Na úrovni této certifikace by měla
být všechna velká datová centra, poskytující služby.
Tier IV – Nejvyšší možná úroveň datového centra, které je schopné odolat výpadku jakékoli
komponenty a je také chráněno proti ohni, vodě a také neúmyslné chybě personálu. Duplikováno je
úplně vše. K výpadku samozřejmě může dojít při údržbě, ale procento je velmi malé, protože takovéto
systémy spravují jen opravdoví profesionálové. Dostupnost je až 99,995 %. a to je pouhých 15 minut
ročně. Klasifikace dále vyžaduje přísná lokalizační kritéria a to znamená, že v České Republice
neexistuje jediné datové centrum, které by tuto certifikaci mohlo splnit. Takto zabezpečená datová
centra využívají ty největší firmy na světě a běží v nich i kritické aplikace. [35] [36] [37]
Dostupnost A se počítá dle jednoduchého vzorce [38]:
A=
MTBF
37
MTBF + MTTR
Nutnost získat důvěru zákazníků
Zavedení dodavatelé on-premise systémů budou mít při dodávce služeb vždy výhodnější pozici,
jelikož je již zákazníci znají. Přesto je zde nutný fyzický přesun dat, který často vyvolává psychické
zábrany. Nové firmy na trhu cloud computingu to mají mnohem těžší. Musí si jednak vybudovat
jméno a hlavně důvěru v jejich spolehlivost ve všech směrech. Přestože je dnes vše vázané smlouvou,
tak přetrvávají obavy ze zneužití nebo ztráty dat. Poskytovatel nebude mít důvěru zákazníka, že je
schopen dodržet smluvené podmínky.
Cenová variabilita
Při daném pay-per-user ceníku, který bývá zobrazen na webových stránkách, nemá poskytovatel
možnost hýbat s cenou při tvoření nabídek. U klasických licencí se často mění cena, dle typu a
kredibility zákazníka.
37
MTBF - Mean Time Between Failures – Průměrná doba mezi poruchami (doba kdy je vše v pořádku)
MTTR - Mean Time To Recovery – Průměrná doba k zotavení systému z poruchy (doba výpadku)
33
2.5.3
Příležitosti
Cloud computing nabízí takřka neomezené možnosti z pohledu nabízení IT služeb. Jakmile má
poskytovatel fungující infrastrukturu, tak své služby může lehce nabízet i do zahraničí a nevzniknou
mu v tomto ohledu téměř žádné dodatečné náklady. Díky tomu může dosáhnout značných úspor
z rozsahu a nabízet řešení levněji. To se týká všech forem cloud computingu.
Trh malých a středních podniků
Možnost expandovat na trh malých a středních podniků. Díky nižším a pravidelněji se opakujícím
platbám za využití aplikace se nabídka SaaS poskytovatele stává lákavá i pro malé a střední firmy,
které si nemohou dovolit nákup drahého krabicového řešení. [7]
Získání závislosti zákazníka
Vlastnictvím infrastruktury, na které má zákazník data a kde běží provozované aplikace, si buduje jeho
závislost na poskytovateli. Má silnější vyjednávací pozici než u on-premise a spíše si zákazníka udrží.
Přesunutí kompletního IT do cloudu
Poskytovatelé mohou do cloudu přesunout veškeré aplikace zákazníka a tím z něj vytěžit maximum.
Usnadní jim to i případné integrační záležitosti a ještě více si zavazují zákazníka.
2.5.4
Hrozby
Ztráta dat nebo narušení bezpečnosti datového centra
Díky precizní duplikaci všech prvků, raidovým polím a pravidelným zálohám na jiná média by se
žádná data ztratit neměla. I tak je to ale určitá hrozba, která spíše psychologicky odrazuje zákazníky.
Obyčejné firmy nikdy nebudou mít chráněný vstup k serverům jako u datového centra. Riziko
znamenají opět jen jednotlivci.
Ztráta důvěry zákazníků
Ztráty důvěry byť jediného referenčního zákazníka může silně zničit důvěryhodnost služeb a
samotného poskytovatele. Negativní zkušenosti a reference se šíří vždy mnohem rychleji, než ty
pozitivní. Toto se může stát v začátcích s prvními zákazníky, kteří mohou své potíže šířit dále, což je
v době odborných serverů a sociálních sítí více než jednoduché. Ztracená důvěra se zpět získává
špatně. Záleží na velikosti, době na trhu a známosti poskytovatele z jak dlouho se s problémy vyrovná
a jak to ovlivní jeho business.
Podpora partnerů ohledně licenčních podmínek
V případě vlastního software to nemusí být hrozba, ale pokud chce poskytovatel nabízet cizí software
ve formě služby je zde riziko neúspěšné dohody, nebo vypovězení smlouvy partnerem. Ať již se to
týká virtualizačních systémů, nebo koncového software.
34
Konkurence
Na trhu se mohou objevit poskytovatelé se stejným záměrem a většími prostředky na marketing, které
jim umožní lépe oslovit a získat zákazníky. Ne každý poskytovatel bude vlastnit své datové centrum a
tím pádem nemůže tolik hýbat s cenou. Začínající firmy může zlikvidovat nízká cena konkurence,
která je již zaběhlá a prvotní investice se jí vrátily. Na trhu poskytování služeb je potřeba získat určité
množství zákazníků, aby se začaly investice vracet.
Zároveň se s rozšiřujícími možnostmi nabízet služby do zahraničí zvyšují rizika, že z těchto trhů přijde
konkurence.
Nová technologie
Pojem cloud computing byl dlouho vnímán jen jako buzzword a nebyla mu přikládána dostatečná
vážnost. Více než v technologii si ho oblíbili lidé v marketingu. Dnes je již na trhu zavedený, je jen
otázkou času, kdy se objeví něco „lepšího a výkonnějšího“. Za pár let se tedy mohou IT strategie
ubírat jiným směrem, kterému pracně vybudovaná infrastruktura nebude odpovídat. Toto riziko se
ovšem dá včas podchytit a novým trendům se přizpůsobit. Cloud computing dost firem ignorovalo a
zaspalo vývoj, který se teď snaží dohnat.
IT zaměstnanci zákazníků
Pro některé stávající zaměstnance firmy, která uvažuje nahradit on-premise řešení službou, znamená
tato změna třeba i ztrátu zaměstnání. Není se tedy čemu divit, že mohou změně ve vlastním zájmu
bránit a ovlivňovat vedení ve prospěch on-premise a zachování vlastních pozic. Z IT manažerů, kteří
tuto změnu přečkají, se často stávají vyjednávači SLA smluv a kontroloři, zda je vše splněno.
Zaměstnanci podniků mohou být překážkou v přechodu na cloud služby.
2.5.5
Shrnutí SWOT analýzy
Tabulka 2 - SWOT analýza - cloud computing z pohledu poskytovatele
Silné stránky
Slabé stránky
Pravidelné příjmy
Vysoké počáteční náklady
Flexibilita/Škálovatelnost
Nutnost získat důvěru
Jednoduchá a plně přístupná správa SW i HW
Cenová variabilita
Řízení incidentů a změn
Úspory z rozsahu
Nízká ekologická zátěž
Silnější vazba se zákazníkem
Příležitosti
Hrozby
Úspory z rozsahu
Únik a ztráta dat
Možnosti nabízet služby i do zahraničí
Ztráta důvěry zákazníků
35
Trh malých a středních podniků
Nová technologie nebo trend
Pomoc při výpočtu ROI
Ztráta podpory partnerů
Získání závislosti zákazníka
Konkurence
Přesunutí kompletního IT do cloudu
IT zaměstnanci zákazníků
2.6 Vhodnost aplikací pro cloud
Jak již bylo dříve zmíněno, ne všechny aplikace jsou vhodné pro cloud. Naráží se zde na hlavní
problém a tím je spolehlivost, rychlost a datová propustnost sítě, přes kterou do cloudu přistupujeme.
Aplikace běžící v reálném čase, jako například řízení letového provozu, nebo výrobní robotická linka
vyžadují precizní načasování a neodpouštějí jakékoliv zpoždění, které může u SaaS nastat. Stejně tak i
kritické aplikace, u kterých chyba, nebo krátkodobý výpadek může znamenat lidský život nebo velké
ztráty na majetku. Není to ani tak problém SaaS, ale opět síťového spojení, které nikdy nebude
stoprocentně spolehlivé a předvídatelné. Čím dále je spotřebitel služby od poskytovatele, tím delší
může být odezva systému. Dalším druhem aplikací, které nejsou vhodné pro cloud jsou ty, při kterých
se přenáší velké množství dat. Opět se naráží na stejný problém a tím je síťová propustnost. [9]
Na druhé straně stojí aplikace, které byly jakoby pro cloud stvořeny. Jedná se například o CRM,
datová úložiště, e-mailové a collaboration servery nebo účetnictví. Obecně jsou tedy vhodné aplikace,
které nevyžadují velkou míru customizace od zákazníka a lze tedy plně využít multi-tenant režimu
1:N.
Dle Mandrya Saatyam [12] je cloud vhodný pro kohokoliv, kdo potřebuje zpřístupnit data a processing
velkému počtu uživatelů a má úlohy nebo aplikace s nepředvídatelnými nároky na výkon a kapacitu.
Následné dělení aplikací převzato z článku webového magazínu Computerworld [39]
Aplikace s potřebou masivního škálování
Tyto aplikace obsluhují velké množství uživatelů, které se mění nárazově. Nejčastějším případem jsou
webové aplikace, jako jsou například elektronické obchody. Pro tyto účely je cloud vhodný, jelikož
firma na začátku nezná počet uživatelů a neví, jaký hardware by bylo třeba pořídit. Zajistí si tedy
cloud o určitých parametrech a postupně je může dynamicky měnit. To je třeba v provozních a hlavně
sezónních špičkách. Týdny před Vánoci bude mít e-shop značně jinou návštěvnost než v březnu a
tomu musí odpovídat i jeho výpočetní kapacity. Firma si tedy může na prosinec a leden pronajmout
větší výkon svého virtuálního stroje nebo využít load-balancing a poté zase snížit.
Aplikace vyžadující vysokou dostupnost
Cloud obecně nabízí větší dostupnost, než jsou organizace schopné si zajistit svými silami.
Nejmodernější datová centra v ČR nabízejí dostupnost až 99,982%, což znamená výpadek maximálně
36
1,6h ročně. To vše díky klasifikaci Tier III, která je popsána v části 2.5.2. Aby firmy dosáhli takovéto
dostupnosti, tak by musely do vlastní infrastruktury investovat nesmírné prostředky. To se jim
nevyplatí finančně a také se zařízení nevyplatí budovat pro běh jedné aplikace. Je tedy vhodné využít
služeb cloud poskytovatele, který může rozložit náklady na provoz na více zákazníků. Další výhodou
je nepřetržitá technická podpora, kterou poskytovatelé nabízejí. Ta se hodí v případě nabídky služeb
do zemí s odlišným časovým pásmem. Dnešním trendem je také všudypřítomná dostupnost služeb,
kdy uživatel cestuje po celém světě a využívá jich i mimo pracovní dobu.
Aplikace s krátkou nebo neznámou životností
Pro aplikace s nejasnou budoucností, kdy není předem jasné, kolik lidí ji bude využívat a jak dlouho se
bude provozovat, nemá smysl zajišťovat hardware. Stejně tak pro začínající firmy nebo projekty,
u kterých není jasná jejich životnost. Pro tyto případy by investice do hardware byla příliš riziková.
Jako příklad lez zmínit aplikace na marketingové kampaně.
Aplikace, které nezapadají do firemního IT
Cloud je vhodný i v případě, že má firma svojí infrastrukturu, ale nyní potřebuje nasadit aplikaci, která
běží mimo její IT, nebo například vyžaduje jinou platformu. Pronájem cloud služby řeší veškeré
požadavky a odlehčuje firemnímu IT. Dalším případem je situace, kdy není dovolen přístup
k firemním serverům zvenčí a proto je nutné aplikaci umístit do cloudu.
Aplikace se širokou geografickou dostupností
Cloudové služby se díky dnešní pokročilé internetové síti dají distribuovat po celém světě a tím pádem
se cloud hodí pro aplikace, které vyžadují širokou geografickou dostupnost. Díky nadnárodním
poskytovatelům lze mít také pro určitá teritoria datové centrum blíže zákazníkům.
„Kupříkladu Windows Azure nabízí kromě umístění serveru v konkrétním datacentru (v Evropě
v irském Dublinu nebo nizozemském Amsterodamu) také tzv. Windows Azure Content Delivery
Network (CDN). Ta se skládá z celkem 24 uzlů (de facto proxy serverů) rozmístěných po celém světě
(vyjma Afriky), které umožňují vytvářet lokální kopie vaší aplikace co nejblíže vašim uživatelům, a to
dokonce i v rámci Evropy, kde je takových bodů hned osm.“ [39]
Aplikace vyžadující externí úložiště dat
Cloud vyhovuje i aplikacím vyžadujícím externí datové úložiště přístupné skrze internet. Zákazník
platí pouze za využitý prostor a může ho jakkoli zvětšovat. Nemusí se také starat o zabezpečení takové
storage a její zálohování.
37
3 ERP řešení v cloudu
Tato kapitola se zabývá konkrétním nasazením ERP v cloudu, resp. využívání modulů tohoto systému
formou SaaS. ERP (Enterprise Resource Planning) se skládá z modulů pro podporu samotné výroby,
logistiky, účetnictví, prodej a distribuci zboží a mnoha dalších. Je tedy jedním z nejdůležitějších
systémů, které se do firem dodávají. Cílem kapitoly je zhodnotit výhody a nevýhody, pokud je ERP
řešení poskytováno v cloudu.
Pod ERP balík aplikací mohou patřit tyto moduly: SCM (Supply Chain Management), CRM
(Customer Relationship Management), PLM (Product Lifecycle Management), HCM (Human Capital
Management), Manufacturing Management, Warehouse management, Asset management, Financial
management, Order management, Project management, Inventory management.
Z tohoto popisu je zřejmá komplexnost a často i složitost ERP systémů. SaaS naopak nahrává
jednodušším aplikacím, které nevyžadují nutnost velké customizace na míru zákazníka. Přerostlá
řešení, která se snažila vyhovět všem odvětvím, jsou zbytečně složitá na implementaci i užívání.
Současným trendem v oblasti ERP systémů je jejich zjednodušování a mobilita. Také se upouští od
módy jednoho globálního balíku podnikových aplikací, jak tomu bylo dříve. To vše nahrává cloud
computingu.
3.1 Situace na trhu a trendy dle analytických společností
Dle zprávy hodnotící rok 2011 konsultační společnosti Panorama Consulting Solutions bylo rozložení
ERP systémů následující.
Obrázek 4 - Typ ERP v roce 2011 dle modelu zavedení [41]
38
58 % trhu stále využívá klasické on-premise systémy a 21 % má své ERP hostované u poskytovatele.
SaaS zabírá 16 % z koláče, což není úplně zanedbatelné a značí to vzrůstající oblibu tohoto modelu.
Loňský výzkum zaznamenal téměř totožné hodnoty. Výzkum se ale převážně zaměřuje na americký
trh. Situace v Evropě může být lehce jiná a to spíše směrem k menšímu výskytu SaaS řešení.
Z grafu vyplývají základní možnosti, jak provozovat ERP:
•
On-Premise instalace
•
EPR hostované v cloudu (na dedikovaném serveru nebo v privátním cloud)
•
Software as a Service
Mezi hlavní hráče na trhu klasických ERP balíků patří SAP (produkty: SAP mySAP, SAP Business
ByDesign), ORACLE (produkty JD Edwards World, JD Edwards EnterpriseOne), a Microsoft
(produkty MS Dynamics AX, NAV, GP a další). Tyto firmy dodávají největší a nejprodávanější onpremise řešení na trhu. SAP nabízí nejrozsáhlejší portfolio business aplikací, které má dokonce na
míru připravené pro jednotlivá odvětví. Tyto produkty si ale mohou dovolit jen střední a velké firmy a
hlavně je stále řeč o on-premise, tedy řešeních dodávaných na hardware zákazníka a instalovaný
v místě firmy. Rozložení sil na trhu popisuje graf na obrázku číslo 5. Pro jeho bližší pochopení je třeba
uvést, co znamenají kategorie Tier u ERP systémů. Nejedná se o klasifikaci úrovně datových center,
ale o určité rozdělení trhu zákaznický firem, pro které je dané ERP řešení vhodné [40]:
•
Tier I – Velké organizace působící po celém světě s mnoha pobočkami. Jejich tržby převyšují
200 milionů USD. Typickými představiteli ERP pro tento segment jsou SAP, Oracle,
Microsoft Dynamics.
•
Tier II – Střední segment trhu, obsahující nejvíce zákaznických firem. Taková firma má
většinou několik poboček v rámci jedné země a tržbu mezi 20 a 200 miliony USD. Zde se
objevují řešení Microsoft Dynamics NV, Epicor Vantage.
•
Tier III – Trh firem mezi 5-35 uživateli a s tržbou do 40 milionu USD.
•
Tier IV – Začínající firmy s tržbou do 2 milionu USD.
Lze se setkat také s takzvanou dvouvrstvou strategií38 ERP, kdy organizace využívá dvě různá řešení.
Většinou je to robustní Tier I řešení pro centrálu a poté Tier II, nebo jiná pro ostatní pobočky.
Vyrovnávají se tím požadavky na robustní řešení pro centrálu a například silně oborově zaměřené pro
výrobní část podniku.
38
Two-Tier ERP Strategy – Jedno ERP řešení pro centrálu a jiné pro zbylé pobočky firmy [zdroj:
http://solutions.epicor.com/e-book/default.html]
39
Obrázek 5 - Tržní podíl dodavatelů ERP [zdroj: Panorama Consulting Solutions, 2011]
Rozmach cloud computingu dosáhl toho, že dříve zmiňované velké firmy na poli on-premise systémů
pochopili, že vedle drahé a časově náročné dodávky jejich systémů se složitou implementací musí
nabízet také software ve formě služby. Druhým impulsem je taky nasycenost trhu Tier I firem a snaha
o rozšíření působnosti. Společnost SAP nabízí SAP Sales On-Demand (v rámci Business ByDesign).
Oracle přišel s Oracle On Demand a nově dokonce nabízí i JD Edwards Enterprise One ve formě
multi-tenant aplikace. Jako službu ho ale budou poskytovat partneři Oraclu a ne přímo Oracle. Není
náhoda, že jako první modul nabízený jako SaaS je skoro vždy CRM. Pro prostředí cloudu a samotné
jeho vlastnosti je to velmi vhodný software. Není nikterak náročný na síťovou propustnost a jedná se
o aplikaci, kterou firmy využívají vesměs stejně. To znamená, že mají podobné business procesy a
není nutné aplikaci tolik přizpůsobovat.
Na trhu se ale vyskytly i společnosti, které využily přicházející vlnu cloud computingu a postavily
řešení, která dodávají výhradně formou SaaS. Mezi dnes nejúspěšnější patří rozhodně NetSuite ERP,
Aplicor, a se svým CRM také salesforce.com.
3.1.1
Gartner Magic quadrant
Analytická společnost Gartner většinou jednou za rok vydává analýzu trhu v jednotlivých odvětvích a
prezentuje jí ve svém Gartner Magic Quadrant grafu. Tento magický čtverec je zaměřen na ERP a
analýza specifikuje trh zákaznických firem o velikosti 100 - 999 zaměstnanců a ročním ziskem 50
milionů až 1 miliardu amerických dolarů. Pro lepší představu o trhu ERP uvádím srovnání roku 2009 a
2010. Jen je nutné upozornit, že rok 2010 nezahrnuje společnosti, využívají dvouvrstvou ERP
strategii. [41] [42]
Magic Quadrant se skládá ze 4 kvadrantů [41]:
•
Vůdci (Leaders) – Vůdci trhu, kteří mají jak vizi, tak schopnost ji převést v realitu. Obecně
mívají novější technologii, vizi pro investici do produktu a schopnost ho vést správným
směrem. Nabízejí širokou nabídku funkcí.
40
•
Vyzyvatelé (Challengers) – Vývojáři ERP software, kteří často soutěží a mají schopnost
realizovat své produkty. Tito hráči mají obvykle starší technologii a chybějící jednotnou vizi,
ale nabízejí kompletní set potřebných vlastností, jelikož jsou již delší dobu na trhu.
•
Visionáři (Visionaries) – Hráči, kteří nemají veškerou funkcionalitu, ale investují do produktu
a mají vizi, aby vedli produkt správným směrem.
•
Specializovaní hráči (Niche Players) – Řešení vhodné pro určitý specializovaný segment trhu,
ale obecně se jedná o řešení s malou investicí a neobsahuje širokou nabídku funkcí
Obrázek 6 - Gartner Magic Quadrant for ERP 2009 zdroj: [43]
Z kvadrantu k roku 2009 je vidět, že hlavním lídrem je Microsoft se svým Dynamics AX (vzniklo
z Axapta), jelikož patří mezi novější software, nezatížený starými přístupy. Spolu s ním se během roku
2010 do kvadrantu lídrů probojoval i SAP se svým SAP Business All-in-One balíkem. Mezi vizionáři
se objevil produkt Epicor 9 od stejnojmenné společnosti. Z grafu vyplývá, že mu chybí schopnost
převést vizi do reality, aby se propracoval mezi lídry. Mezi takzvané „Niche players“ patří produkty
firem Infor, Sage, nebo Exact Globe. Je zde zařazen i produkt Navision (koupen Microsoftem v roce
2002 a od roku 2005 distribuován pod názvem Microsoft Dynamics NAV [44]), což znamená, že díky
akvizicím má Microsoft široké portfolio produktů. Mimo jiné vlastní i Microsoft Dynamics GP (dříve
Great Plains Software) a Dynamics SL (dříve Solomon IV), které v grafu nejsou.
„Nejpoužívanějším nástrojem pro exportování a analyzování dat na trhu středně velkých firem je
Microsoft Excel / The most commonly used technology for extracting and analyzing data in the
midmarket companies is Microsoft Excel“ [42]
41
Obrázek 7 - Gartner Magic Quadrant for ERP 2010 zdroj: [41]
Hlavní rozdíly oproti roku 2009 jsou dle společnosti Gartner v tom, že si zákazníci zvykají
na přepracovaná uživatelská rozhraní, která přinášejí více na rolích postavených funkcí a také lepší
personalizační a komunikační funkce. SaaS model se bohužel v ERP zatím moc neprosadil a v době,
kdy se prováděla analýza, stále většina zákazníků provozovala on-premise řešení. Snaží se ale
cloudových služeb využívat v oblastech jako je CRM, nebo systémech pro spolupráci. Trh na to
reaguje nabídkou hostovaných řešení s cenovými modely a částečnými benefity, jako nabízí SaaS, ale
jen hrstka dodavatelů nabízí skutečné multi-tenant řešení. [42] Tento způsob, kdy je software
nainstalovaný u poskytovatele, ale je k dispozici jen jednomu zákazníkovi se nazývá managed
hosting39. Dle výzkumu společnosti Panorama Consulting Group, ERP tímto způsobem využívá
zhruba 20 % společností. Managed hosting tedy vyrovnává současnou poptávku po řešení, které
spravuje někdo jiný na svém hardware a zároveň má firma možnost plné customizace software.
3.1.2
Hype Cycle for ERP 2011 společnosti Gartner, Inc. [10]
Společnost Gartner vydává každoročně své studie trendů v nejrůznějších oblastech IT. Využívají
k tomu křivku, kterou nazývají hype cycle40. Ta nabízí pohled na zralost jednotlivých technologií, IT
metodik a manažerských disciplín. Snaží se zvýraznit, která očekávání jsou přehnaná a odhadnout jak
dlouho bude technologiím a trendům trvat, než dosáhnou své zralosti, aby se na trhu uchytily. Také
pomáhá organizacím rozhodnout se, kdy je vhodné dané technologie nasadit, aby neinvestovali
do prázdných marketingových pojmů. [45]
„There is always a risk of adapting the technology too soon, but there is also a risk, perhaps a bigger
risk, of adapting the technology too late“ [46]
39
40
Managed hosting – poskytovatel se stará o klientův HW i SW, dle smlouvy
Hype cycle - křivka humbuku (jak moc je technologie vnímána a jak se o ní mluví)
42
Křivka se dělí na tyto části:
•
Technology Trigger41 – Průlom, první představení produktu, které značně zaujme novináře a
odborníky z praxe.
•
Peak of Inflated Expectations42 – V této fázi nastává nesmírné nadšení a nerealistické
představy o tom, co vše může technologie přinést. Zažívá i pár úspěchů díky snaze
technologických lídrů, ale celkově je spíše neúspěšná, protože se dostává na hranice svých
možností. Jediní, kdo z ní těží, jsou organizátoři konferencí a novináři.
•
Trough of Disillusionment43 – Technologie, která absolutně nenaplní to, co se od ní očekávalo
v minulé fázi, rychle vychází z módy. Zájem médií slábne, kromě pár varovných příběhů.
•
Slope of Enlightenment44 – Cílené experimenty a poctivá práce různorodých organizací vede
k opravdovému porozumění možností technologie a možným přínosům a rizikům. Komerční
běžně dostupné metodiky a nástroje usnadňují proces vývoje.
•
Plateau of Productivity45 – V této fázi technologie přináší reálné užitky a je obecně přijata.
Nástroje a metodiky jsou stabilní, jelikož se jedná o jejich druhé nebo třetí generace.
Organizace se již nebojí technologie nasadit a postupně se rozšiřují. Okolo 20 % z cílové
kategorie, pro kterou je technologie určena, ji adoptovali na začátku této fáze.
Years to Mainstream Adoption46 – Čas vyžadovaný k tomu, aby technologie dosáhla „Plateau of
Productivity“.
Tato analýza je zaměřena jen na ERP a s ním související technologie. Na křivce k roku 2011 jsou vidět
technologie jako ERP Mobility, ERP application stores, které šplhají k vrcholu své současné slávy. To
podporuje současné trendy zjednodušování ERP systému a jejich všudypřítomnou dostupnost a
integraci do mobilních zařízení.
41
Technology trigger - spouštěcí mechanismus technologie
Peak of Inflated Expectations – vrchol přehnaných očekávání
43
Trough of Disillusionment – údolí rozčarování, zklamání, vystřízlivění
44
Slope of Enlightenment – svah osvícení
45
Plateau of Productivity – náhorní plošina produktivity
46
Years to mainstream adoption – kolik let zbývá k obecnému zaběhnutí technologie
42
43
Obrázek 8 - Hype Cycle for ERP, 2011 zdroj: [10]
Jako technologická novinka se objevily cloudové ERP systémy pro velké společnosti (Cloud ERP for
Large Enterprises) s tím, že zralosti by měly dosáhnout během 5-10 let. Podle Gartneru zatím nelze
nasadit cloudové EPR řešení, které by zajišťovalo kompletní běh velké společnosti, protože žádné
takové single-instance řešení ještě neexistuje. Pouze firmy jako NetSuite a Plex Systems dosahují
úspěchu na úrovni dceřiných společností nebo odloučených filiálek. Tento způsob nasazení by
podporoval two-tier strategii.
Z praxe lze uvést, že ORACLE uvedl na trh JD Edwards EnterpriseOne pro nasazení v cloudu. A to
dokonce i multi-tenant verzi. Tu sice nebude provozovat Oracle na svých serverech pro koncové
zákazníky, ale skrze své partnery. Bude tedy možné, že příští rok se objeví tato položka ve čtvrté části
grafu s úplně jiným odhadem. [zdroj: Algotech BSC]
Na cloudu založené systémy pro malé a střední firmy se dostávají na úplný vrchol očekávání
s odhadem, že se do 2-5 let na trhu prosadí.
44
Obrázek 9 - Hype Cycle for ERP, 2010 zdroj: [10]
3.2 SWOT analýza ERP řešení v cloudu z pohledu zákazníka
Tato analýza se zaměřuje na vlastnosti ERP systému poskytovaných ve formě SaaS z pohledu
zákazníka. Zmiňuje nejpodstatnější rozdíly od klasických on-premise systémů a specifika ERP, která
nejsou v obecných vlastnostech minulé kapitoly.
3.2.1
Silné stránky
Náklady na pořízení
Pořízení ERP systému je díky nižším prvotním nákladům mnohem jednodušší. S tím úzce souvisí i
nízké TCO47 a lepší ROI48. Díky předplatnému není třeba velkých investicí a shánění kapitálu
k pořízení nákladné licence a hardware. Nesmí se ovšem zapomínat na cenu implementace řešení,
které v případě zajištění třetí stranou může znamenat značný náklad hned na začátku. Pokud
implementaci provádí poskytovatel, tak je možné ji rozložit do více let, dle smlouvy. Pořízení drahého
systému se nemusí kompenzovat šetřením na jiných místech, například platech IT zaměstnanců. Stav
IT personálu se může zúžit a nemusí. Firma bude vždy někoho potřebovat i v případě SaaS, ale nebude
již potřeba lidí starajících se o hardware, na kterém by systém běžel a také o aktualizace. Nemusí tedy
platit ani IT experty, protože ti jsou na straně dodavatele. [47]
47
48
TCO – Total Cost of Ownership
ROI – Return On Investment
45
Flexibilita služby
V případě rozšíření firmy je velice jednoduché dokoupit službu pro další uživatele a naopak. Díky
měsíčním, nebo čtvrtletním platbám za uživatele, je SaaS velmi flexibilní a firma nemusí dopředu
plánovat, jak velkou licenci nakoupit. Vzhledem k vysokým cenám ERP řešení lze ušetřit v případě
snížení počtu uživatelů. Stejně tak si zákazník platí i za potřebný výkon a velikost datového úložiště.
S klasickou licencí lze ve valné většině hýbat jen směrem nahoru. Jednou byla licence nakoupena na
daný počet uživatelů a lze ho jen rozšiřovat. Flexibilita SaaS ERP se odvíjí od dodavatele ERP a
smlouvy. I zde se může stát, že SaaS bude mít stejné vlastnosti v oblasti změn počtu uživatelů jako
klasická licence.
Rychlost implementace a snížení implementačních rizik
Doba trvání projektů na zavedení on-premise ERP systémů je s každým rokem kratší, ale i tak dle
studie Panorama Consulting Group z roku 2012 [48] trvá zhruba 15 měsíců. V případě hostovaných
cloud řešení je cca o 4 měsíce kratší. To je ovšem řeč o velkých systémech, které nejsou k mání jako
SaaS. Menší a střední firmy mohou využít SaaS řešení, která jsou k dispozici okamžitě. Samozřejmě
se ani zde firma nevyhne určité customizaci, integraci se stávajícími systémy a školení. Implementaci
se vším okolo je možné zvládnout i během jednoho měsíce.
SaaS snižuje riziko špatné volby poskytovatele, jelikož ho lze relativně rychle změnit. Tato výhoda
ovšem platí jen za podmínky, že zákazník nepodepsal smlouvu o odebírání služby na dobu určitou a
spíše pro jednodušší systémy.
U on-premise systému je také velmi časté, že se nedodrží doba stanovená pro implementaci systému.
Dle naposled zmíněné studie jen 38 % projektů končí v plánovaném čase. Zhruba 31 % překročí
plánovaný čas o 0-25 %, což je značně velké číslo, s kterým je třeba počítat. Cloud zkracuje dobu
projektu, ale nejde říci, že zvýší úspěšnost plnění plánu.
Obrázek 10 - Dodržení plánované doby projektu [zdroj: Panorama Consulting Solutions]
46
Bezpečnost dat
ERP systémy obsahují nejcitlivější data firem, jako je účetnictví, informace o zákaznících nebo
obchodní a výrobní know-how. Data jsou u prověřených poskytovatelů služeb často ve větším
bezpečí, než na serveru firmy, ale stále se objevují obavy z toho, že firma nemá svá citlivá data
fyzicky u sebe. Jedná se tedy spíš o psychologickou bariéru na straně zákazníka, která může ERP
v cloudu uškodit. Naráží se zde i na právní normy dané země, které musí poskytovatel splnit. Pokud
ovšem firma vybere zavedeného poskytovatele a všechny případy ohrožení dat zajistí smluvně, tak zde
není o nic větší riziko, než u on-premise řešení a spíše naopak. [53] Veškeré obavy ošetří správně
sestavené SLA a NDA smlouvy, které jsou detailněji popsané v části 4.5.
Možnosti customizace ERP
ERP systémy jsou specifické svým napojením na obchodní nebo například i výrobní procesy ve firmě.
Z toho vyplývá různorodost, na kterou musí být připravené, a tím pádem i jejich složitost. To odporuje
požadavku SaaS, kde je snaha o co nejjednodušší aplikaci, která se snadno provozuje v modelu 1:N.
V odborné literatuře [6] [7] převládá názor, že SaaS obecně má jen velmi malé možnosti customizace.
Ty se většinou vztahují na přizpůsobení rozvržení obrazovek, změnu polí a jejich parametrů pro danou
firmu, případně změny workflow systému. Není ovšem možné dosáhnout takové úrovně customizace
jako u on-premise řešení, kde lze danou instalaci kompletně upravit dokonce na úrovni kódu. Nabízí
se otázka, zdali to není spíše výhoda. Při silné individualizaci systému se firma může dostat do jakési
pasti, kdy má dokonale přizpůsobený on-premise systém a kvůli tomu nemůže upgradovat na novou
verzi. Pro SaaS hovoří možnosti customizace, které se nevylučují s pravidelnými upgrady.
Customizace je jednoduchá a velmi rychlá. Lépe se tedy přizpůsobuje změnám v podnikání a hlavně
rychleji.
Příklad pokročilého SaaS řešení provozuje společnost Netsuite se svým SaaS ERP produktem, který je
navržen pro snadnou úpravu jak layoutu, tak workflow. Vyvrací tedy představy o tom, že SaaS nelze
snadno přizpůsobit podnikání a firmy musí spíše přizpůsobit svůj obchodní model možnostem
aplikace. Netsuite nabízí SuiteFlow49, což je grafický nástroj, který umožní uživateli měnit workflow
dle změn v businessu.
Přizpůsobení multi-tenant aplikací pravděpodobně vždy bude omezenější, než u on-premise nebo
hostovaného řešení. Střední a velké společnosti jsou tedy zvyklé mít ERP systém nastavený přesně dle
jejich obchodních a výrobních procesů. Se SaaS klesá možnost ladění software na míru organizaci a
také kontrola nad aktuální verzí. Menší firmy se spíše přizpůsobují, využívají zabudované best
practices a mění nebo teprve zavádějí své procesy dle používaného software. Organizacím bez jasných
cílů a definovaných obchodních procesů SaaS řešení nepomůže o nic více, než on-premise. [50]
49
SuiteFlow – grafický nástroj společnosti NetSuite pro přizpůsobení systému
[http://www.netsuite.com/portal/products/suiteflow.shtml]
47
Otázkou tedy zůstává, zdali se v blízké budoucnosti tyto role nevymění a SaaS ERP nebude bráno jako
nejlépe přizpůsobitelné obchodním procesům firmy. [51]
Globální působnost firmy
Tato výhoda byla již popsána v globálním hodnocení cloud computingu. Pro ERP je to ale více než
důležité, jelikož se jedná o systém, který je u větších firem nasazován na každé pobočce. Ušetřené
náklady za opakovanou implementaci mohou být značné. Hlavní přínos bude jednoduché propojení
systémů pro kontrolu hospodaření a řízení mezinárodních obchodních případů.
Mobilita
Řízení obchodních transakcí se dnes bez ERP neobejde, a proto jejich mobilita zvyšuje efektivitu
pracovníků i celé firmy. Uživatelé mohou mít přístup k důležitým obchodním datům odkudkoliv.
Potřebují k tomu jen přístup k internetu a potřebné přístupové údaje. Rozmáhá se také integrace do
mobilních platforem, která je u SaaS řešení mnohem jednodušší. SaaS verze jsou od začátku
navrhovány pro webový a mobilní přístup.
Lepší komunikace s dodavateli a zákazníky
Staré systémy jako například SAP R/3 nikdy nebyly navrhovány pro silně propojený svět a nutí firmy
doinstalovat drahé adaptéry nebo aplikace třetích stran a dělat CSV50 exporty. Jednoduše řečeno
nejsou orientované na služby. Jakmile se web stal mediem pro výměnu informací, tak začaly mít onpremise ERP systémy problémy. SaaS přináší reporty ve formě dashboardů pro management i běžné
uživatele. Zákazníci například chtějí vidět cenu a počet zboží skladem přímo na stránce organizace a
po objednávce také její status. Stejně tak změna dodavatele znamená nákladný integrační projekt a tím
pádem si to firma dobře rozmyslí. Na opačné straně stojí cloudové ERP systémy, které byly
navrhovány k propojení s jinými platformami a webovými aplikacemi v rámci organizace i mimo. Od
základů jsou navrhnuty jako stále dostupné služby, sloužící jak firmě, tak i jejím partnerům,
dodavatelům a hlavně i zákazníkům. [52]
3.2.2
Slabé stránky
Cena v dlouhém období
Firmy se často rozhodnou pro SaaS hlavně kvůli počátečním nižším nákladům. Důležité je ale také
spočítat, jaké budou náklady například po 2 letech a zjistit kdy se cenově protíná model SaaS s onpremise. Měsíční poplatky za ERP se ve větších firmách násobí opravdu velkými čísly a počáteční
nadšení se může v extrémním případě obrátit v neschopnost platit za službu tak vysoké měsíční
poplatky. U on-premise by v případě ekonomických problémů zákazníkovi zůstal licencovaný
software a případné finanční výpadky by překonala beze změny. U SaaS by byla služba bez placení
50
CSV – Coma Separated Values – hodnoty oddělené čárkou, nebo jiným separátorem
48
během krátké doby vypnuta. S náklady se ale určitě lépe pracuje z účetního a ekonomického hlediska
u SaaS verze. Pravidelné poplatky pomáhají lepšímu cashflow.
Integrace se stávajícími systémy
Integrace SaaS je stejně jako u on-premise závislá na možnostech software komunikovat s ostatními
systémy. Nejčastěji pomocí API51, nebo různých konektorů až po import a export dat. U SaaS ERP
systémů lze narazit na problémy v integraci se starými on-premise systémy. Buď se jedná o problém
na straně cloudu, kdy má omezené možnosti integrace, nebo zastaralých on-premise aplikací, které si
s ním nebudou rozumět. I to může odradit firmu od nasazení SaaS řešení. Vždy je tedy nutné si zjistit
možnosti napojení na stávající systémy organizace a partnerů, s kterými spolupracuje.
Této problematice se začalo věnovat několik firem, protože to byla jistá příležitost na trhu a je stále
aktuální. Existují tedy již systémy specializující se na integraci známých SaaS služeb (salesforce.com,
NetSuite, Google Apps), mezi sebou, ale i s firemními back office systémy. Jako příklad lze uvést
firmy Adeptia52, Jitterbit53 nebo Informatica Cloud54.
Vyzrálost a robustnost SaaS řešení
Většina SaaS řešení zatím není připravena pro nasazení jako hlavní software pro firmy typu Tier I, viz
studie Gartner Hype Cycle for ERP [10] v části 3.1.2. Netýká se ale například JD Edwards
od společnosti Oracle. Některá odvětví také mohou mít tak specifické požadavky, kterým se SaaS
nedokáže přizpůsobit.
3.2.3
Příležitosti
Rozšiřitelnost na více poboček
EPR v cloudu je vhodné pro takzvanou two-tier ERP strategii, která je vysvětlena v části 3.1.
Organizace s mnoha výrobními pobočkami ušetří implementační náklady a mohou systémy nasadit
dříve.
Jasně predikovatelné náklady pro budoucí rozvoj společnosti
Díky pravidelným poplatkům se lépe plánuje rozvoj společnosti a nehrozí tolik nečekaných výdajů,
které by ho mohly zbrzdit.
Moderní technologie
Poskytovatel se stará o využití nejmodernějších technologií pro zajištění výkonnosti a bezpečnosti
cloud infrastruktury a také software. Je to v jeho vlastním zájmu pro udržení konkurenceschopnosti a
zákazníci z toho těží.
51
API – Application Programming Interface – rozhraní aplikace pro komunikaci s jinými systémy
Adeptia - http://www.adeptia.com/
53
Jitterbit - http://www.jitterbit.com/
54
Informatica Cloud - http://www.informaticacloud.com
52
49
Výhody best practices
Opakované zavádění ERP a jednoduchost spojená s multitenancy přináší automaticky best practices
zákazníkovi.
3.2.4
Hrozby
Neschopnost platit poplatky
Firma může mít sezónní výkyvy cashflow a přitom stálý počet zaměstnanců. Z toho plyne riziko
neschopnosti platit pravidelné částky v horším období. Pokud je vázána smlouvou na dobu určitou, tak
v případě nutného šetření nemůže tento náklad eliminovat, aniž by doplatila zbytek peněz.
Zvýšení SaaS poplatku za uživatele
Stálost pravidelného poplatku řeší pouze smlouva. Po jejím ukončení je zde hrozba zvýšení poplatku.
Je to spíše nepravděpodobné, ale bylo by lepší tuto situaci předem s poskytovatelem probrat. Ideální je
vybírat poskytovatele, který má ceny jasně dané a veřejně dostupné. To je bohužel u ERP problém,
protože se cena skládá z mnoha modulů a cena se může lišit dle specifických požadavků zákazníka.
[54]
Ztráta a únik dat
Největší hrozbou pro zákazníky je stále ztráta dat a vyzrazení obchodního tajemství. Buď chybou
poskytovatele, nebo při útoku z vnějšku. Vzhledem k bezpečnostním opatřením poskytovatelů by toto
riziko mělo být mnohem nižší než u on-premise, ale je zde stále ten psychologický problém, že jsou
data ukládána mimo firmu. Určitým rizikem jsou i samotní uživatelé v případě zneužiti přístupu do
systému. To je ovšem stejné i u on-premise.
Omezení, výpadek internetového připojení
SaaS je závislé na konektivitě a proto je nutné mít tuto záležitost bezpečně zajištěnu. V případě
výpadku by celá firma nemohla pracovat a znamenalo by to pro ni ztráty. Možností, jak toto riziko
eliminovat, je dvojí nezávislé připojení. Vrůstají tím firmě náklady na provoz, ale v případě využití
více SaaS služeb se může velmi vyplatit.
3.2.5
Vyhodnocení SWOT analýzy z pohledu zákazníka
V případě ERP Software as a Service přináší hlavně jednoduchou a rychlejší implementaci,
rozšiřitelnost jednotlivých modulů, flexibilní licencování a nízké počáteční náklady. Například
v případě CRM od firmy salesforce.com stačí zakoupit potřebný počet uživatelů dané verze, nastavit
základní parametry, jako je měna, jazyk a firma může začít se systémem pracovat. Není tedy nutné
instalovat hardware, operační systémy, a dlouze implementovat samotné CRM. Samozřejmě je nutné
krátké úvodní školení pro uživatele, ale systém je dosti jednoduchý. Toto ocení hlavně menší firmy,
které by si velké řešení nemohly dovolit a i kdyby na to kapitál měly, tak by se jim to finančně silně
nevyplatilo. Malé a střední firmy díky cloudu mohou začít využívat dospělá řešení, stejně jako velké
50
korporace. Přináší jim to s sebou i best practices zapouzdřené v těchto systémech. Těm se většinou
malé firmy přizpůsobují. Také již úplně neplatí spojení SaaS s nemožností přizpůsobení software dle
procesů společnosti. Například dříve zmíněné ERP NetSuite se na tuto problematiku zaměřuje a sklízí
úspěch. Velké společnosti, které mají dostatek peněz na IT, budou zatím spíše preferovat on-site
řešení, které není výkonově brzděné internetovým připojením a je jednoduše robustnější.
Tabulka 3 - SWOT analýza - SaaS ERP z pohledu zákazníka
Silné stránky
Slabé stránky
Náklady na pořízení
Cena v dlouhém období
Flexibilita licencování
Integrace se stávajícími systémy
Rychlost implementace
Vyzrálost a robustnost SaaS řešení
Bezpečnost
Nižší implementační rizika
Nižší provozní rizika
Možnosti customizace
Globální působnost firmy
Mobilita
Lepší komunikace s dodavateli a zákazníky
Příležitosti
Hrozby
Rozšiřitelnost na více poboček
Neschopnost platit poplatky
Jasně predikovatelné náklady pro budoucí
rozvoj společnosti
Moderní technologie
Zvýšení SaaS poplatku za uživatele
Omezení, výpadek internetového připojení
Ztráta a únik dat
3.3 SWOT analýza ERP řešení v cloudu z pohledu poskytovatele
Pohled poskytovatele rozšiřuje obecný pohled kapitoly 2.5 z pohledu nasazení ERP v cloudu. Objevují
se totožné věci, jako u zákazníka, ale zde mohou mít opačné důsledky.
3.3.1
Silné stránky
Flexibilita řešení
Poskytovatel nabízí škálovatelné řešení, což přináší mnoho finančních výhod oproti on-premise. Může
lépe reagovat na poptávku a uspokojit širší řadu zájemců. Multi-tenant architektura umožňuje docílit
úspor z rozsahu.
51
Pravidelné příjmy
Stejně jako pro zákazníka rovnoměrné náklady i pro poskytovatele je lepší stabilní příjem, než
jednorázová částka. Ta bývá u ERP obzvlášť vysoká, a proto se bude řešení i lépe prodávat takzvaně
na splátky, než jednorázově. Podporuje to cashflow a rozvoj dodavatele.
Rychlost implementace
Zrychlení implementačních dob pomáhá i poskytovateli v rychlejším zajištění příjmů a uvolnění
lidských zdrojů pro další implementaci, nebo podporu zákazníků.
3.3.2
Slabé stránky
Náročnost na vybudování infrastruktury
Obdobně jako v obecných vlastnostech i u ERP záleží, zdali má poskytovatel svoji infrastrukturu,
která je velmi nákladná, nebo využívá služeb třetí strany pro hostování svého řešení.
3.3.3
Příležitosti
Efektivní využití zdrojů
Se stejným počtem zdrojů je poskytovatel schopen obsloužit více projektů a získat více zákazníků.
Získání závislosti zákazníka
Změna ERP není vůbec jednoduchá záležitost, takže při správné péči si může poskytovatel udržet
zákazníky velmi dlouho.
Nabídka i do okolních států
Pouhou změnou jazyka a legislativních detailů se může poskytovatel pokusit nabízet řešení i
za hranice. Nevznikají mu kvůli tomu žádné velké výdaje vzhledem k potenciálnímu zisku.
Pomoc při výpočtu ROI
Dodavatel si může na svou stranu získat zákazníka také tím, že mu pomůže spočítat ROI a ukáže
všechny výhody SaaS. To ovšem obnáší i identifikaci stávajících nákladů, které si zákazník nemusí
uvědomovat.
Pokrytí více tržních segmentů
Díky jednoduché škálovatelnosti a méně nákladné implementaci SaaS řešení se dodavatelé mohou
pokusit o trh středních a malých firem, které nemají prostředky na velké řešení a bylo by to pro ně
moc rizikové. Znamená to tedy více potencionálních zákazníků pro poskytovatele.
52
3.3.4
Hrozby
Globalizace
Stejně jako má poskytovatel možnosti vstupu na zahraniční trhy, tak mu z těchto trhů hrozí silná
konkurence. I přes zázemí tuzemské firmy může zákazník zvolit levnější variantu ze zahraničí.
Vysoké inicializační náklady pro zákazníka
Poskytovatel může přijít o SaaS zákazníky, pokud by vyžadoval nákladnou implementaci
v jednorázovém poplatku.
Nespolehlivá konektivita vs. garance dostupnosti
Pokud poskytovatel využívá služeb třetích stran.
Nedostatek zákazníků
V případě neschopnosti získat dostatečné množství zákazníků se poskytovateli nevrátí investice
do datového centra a může zkrachovat.
Ztráta a únik dat
Ke ztrátě nebo úniku nesmí dojít, jinak jsou aplikovány sankce a firma může přijít o stávající i budoucí
zákazníky.
3.3.5
Vyhodnocení SWOT analýzy z pohledu poskytovatele
Tabulka 4 - SWOT analýza - SaaS ERP z pohledu zákazníka
Silné stránky
Slabé stránky
Flexibilita řešení
Náročnost na vybudování infrastruktury
Pravidelné příjmy
Rychlost implementace
Příležitosti
Hrozby
Efektivní využití zdrojů
Globalizace
Získání závislosti zákazníka
Vysoké inicializační náklady pro zákazníka
Nabídka do okolních států
Nespolehlivá konektivita
Pomoc při výpočtu ROI
Nedostatek zákazníků
Pokrytí více tržních segmentů
Ztráta a únik dat
53
3.4 Return On Investements - cloud vs. on-premise řešení
Return On Investments, neboli návratnost investic je metoda, která se používá k hodnocení investice
nejen do IT. Vyžadují ji hlavně CFO55 firem, protože na IT se vynakládají velké prostředky s často
nejasnými výsledky. ROI by měla pomoci předpovědět kdy a zdali vůbec se organizaci tyto prostředky
vrátí. Firmy si musí spočítat návratnost jejich investice do hardware, software a jiných aktiv. K tomu
ale nejdříve musí vědět, co je stojí stávající provoz. To bývá částečně i problém této metodiky pro
výpočet návratnosti investice. Firmy, které neví, jaké mají dosavadní náklady na všechny oblasti,
těžko spočítají užitky a peníze ušetřené zavedením nového systému.
Například s nasazením ERP se vždycky očekává snížení operačních nákladů, stavu zásob, zvýšení
příjmů a jiné výhody. Dle výzkumu společnosti Panorama Consulting Group z roku 2012 [48] se ale
pouze 50 procentům zákazníků povedlo realizovat více jak 50 % očekávaných užitků. ROI tedy
neříká, zdali se cílů dosáhne a kdy, ale pouze odhaduje návratnost investice. Ani odhad nemusí být
splněn, pokud ERP z různých důvodů slibované efekty nepřinese.
„ROI je finanční metrika a neposkytuje žádné informace o účinnosti nebo efektivitě informačních
systémů / ROI is a financial measure and does not provide information about efficiency or
effectiveness of the information systems.“ [55]
Samotný výpočet je velmi jednoduchý. Čitatel představuje příjmy, které investice přinesla snížené o
vynaložené náklady. Právě čitatel značně ovlivňuje výsledek výpočtu. Zjistit zisk, který firmě přineslo
zavedení software, jak již bylo řečeno, není jednoduché a dělá se zde nejvíce chyb. Před výpočtem je
třeba určit veškeré oblasti, které investice ovlivnila, analyzovat změny a převést je na finanční čísla.
Problém měřitelnosti přínosů je i u ERP. Využívají se takzvané tvrdé a měkké metriky, ve kterých
byly zaznamenány pozitivní změny. [56]
Tvrdé metriky ERP:
•
zkrácení délky DSO56 (Days Of Outstanding)
•
zrychlení výroby
•
snížení stavu skladové evidence
Měkké metriky:
•
lepší přehled nad výrobou a skladem
•
efektivnější komunikace se zákazníky a dodavateli
•
jednodušší a rychlejší reporting pro management
55
CFO – Chief Financial Officer – Finanční ředitel
DSO – Days Sales Outstanding – průměrná doba za kterou firmy získají peníze z pohledávek
[http://en.wikipedia.org/wiki/Days_sales_outstanding]
56
54
Přínosy SaaS ERP [57]:
•
Rychlejší implementace
•
Lepší využívání aplikací uživateli (aplikace jsou jednodušší)
•
Snížení potřeby technické podpory
Odhady jsou tedy spíše o zkušenostech a je potřeba znát historická data firmy. Drobný příklad lze
uvést například u systému pro call centra. Lidé pracují určitý čas, což znamená určité mzdové náklady.
Systém uspoří operátorovi call centra 1 hodinu práce denně a při počtu 8 operátorů to znamená
jednoho pracujícího člověka a jeho plat.
Vynaložené náklady jsou shodné se zmiňovanými v další kapitole o TCO, nebo v Tabulka 5 - Seznam
nákladů ERP řešení.
Vzorec ROI:
ROI •
ří
žéá
100%
žéá
ROI < 100 % – Pokud není hodnota záporná, tak to znamená, že projekt vydělává. V prvních
letech po velké investici může být ROI dokonce záporné, kdy je firma ve ztrátě.
•
ROI = 100 % – Bod zlomu návratnosti investice. Příjmy se rovnají vynaloženým nákladům.
•
ROI > 100% – Představuje velmi výhodnou investici, která je během dané doby splacena a
generuje zisk.
Při výpočtu jednoduchého ROI se berou roční čísla. Výsledky budou ale z převážné většiny negativní,
protože u velkých systémů, kde se ROI počítá, se neočekávají přínosy hned během prvního roku a
hlavně systémy jsou plánovány na více let. V takovém případě se počítá s celkovými příjmy a náklady
na investici za dané období.
Pro porovnávání dvou investic lze říci, že čím vyšší je výsledné číslo, tím je investice výhodnější.
Musí se ale počítat se stejnými vstupními hodnotami. ROI má ještě jednu vadu a to, že nezahrnuje
změnu hodnoty peněz v čase. Kvůli tomu se doporučuje počítat s čistou současnou hodnotou.
Při hodnocení výběru stejného systému, kde je třeba zjistit, která varianta zavedení software je
výhodnější se doporučuje počítat jen s IT úspory SaaS a private cloud oproti On-Premise. Business
úspory ERP jsou pro všechny varianty stejné a ve výpočtu záleží na IT úsporách. ROI by mělo být
vždy výhodnější pro SaaS. Nejsou zde tak markantní prvotní náklady, nebo jsou rozloženy do více let.
On-Premise řešení jsou vždy zatížené prvotní investicí, která výsledky ovlivňuje a posouvá dobu, kdy
se projekt dostane do plusových čísel.
55
3.5 Total Cost of Ownership - cloud vs. on-premise řešení
„Přístup TCO byl poprvé publikován v roce 1987 Billem Kirwinem ze společnosti Gartner. Analýza
nákladů vlastnictví (Cost of Ownership) nebo také Analýza celkových nákladů vlastnictví (Total Cost
of Ownership – TCO) je používána jako jeden z velmi významných přístupů k hodnocení podnikové
informatiky. TCO může být považováno za finanční odhad zkalkulovaný s cílem pomoci zákazníkům a
podnikovým manažerům při hodnocení přímých a nepřímých nákladů spojených s IS/ICT (nákup a
provoz HW a SW). TCO umožňuje srozumitelně a jasně přiřadit náklady vynakládané na vlastnění a
řízení ICZ infrastruktury v podniku“ [6] Je tedy druhou nejčastěji používanou metodikou pro
hodnocení IT projektů. U SaaS poskytovatelů lze vidět zkratku TCO úplně všude, protože patří mezi
jeho hlavní výhodu, hlavně tedy v krátkém období.
Výpočet TCO se skládá z veškerých nákladů na řešení, které byla firma nucena vynaložit. Počítají se
tyto položky [58] [59]:
•
Náklady na licence / předplatné u SaaS
•
Náklady na hardware a jeho údržbu (on-premise)
•
Náklady na implementaci a customizaci
•
Náklady na integraci a migraci dat
•
Servisní a maintenance poplatky
•
Mzdy IT oddělení nutné pro údržbu HW a podporu uživatelů
•
Řízení změn
•
Náklady na školení
•
Konektivita
Náklady pro jednotlivé varianty nasazení ERP popisuje Tabulka 5 - Seznam nákladů ERP řešení.
Rozdíl v TCO u SaaS a on-premise je hodně závislý na počtu uživatelů. Jako příklad lze uvést
srovnání produktu NetSuite s Microsoft Dynamics + salesforce.com (v druhé variantě zastávalo CRM)
přesto že se nejedná o on-premise řešení). Pro 10 uživatelů vychází TCO po 8 letech u SaaS varianty o
77,3 % levněji, než on-premise (ušetřeno skoro 1 milion USD). S přibývajícím počtem uživatelů se
rozdíl snižuje. Například u 50 uživatelů je levnější o 54,6 % u 100 uživatelů o 44,5 %. Dokonce i při
500 uživatelích je levnější SaaS varianta o 39,3 %.[58] Detailní příklad výpočtu TCO je v příloze 3
spolu s grafy v příloze 4.
Rozhodně se vyplatí TCO kombinovat s ROI, kde je počítáno s náklady a zisky či úsporami,
a porovnat, zda jsou do obou veličin zahrnuty stejné náklady. Pro ERP se obecně počítá TCO a ROI
na 5 let. [60]
56
4 Co řeší zákazník při/před přechodem na cloud řešení?
Tato kapitola se soustředí na konkrétní otázky, které řeší organizace při zvažování cloud computingu.
Jedná se hlavně o porovnání ceny cloud vs. on-premise systému, zvážení bezpečnosti, možnosti
customizace a integrace a samotné dostupnosti služby. Cílem je vypracovat doporučení, jak by měla
firma při analýze postupovat a nastínit, co ji může čekat. Autor čerpá z kapitoly Kroky při výběru
poskytovatele služeb z knihy Aplikační služby IS/ICT formou ASP [7] a kapitoly o outsourcingu
z knihy Principy a modely řízení podnikové informatiky [6]. Dále z vlastních praktických zkušeností
v oblasti dodávky e-mailových řešení jak on-premise, tak v cloudu a zkušeností společnosti
Algotech BSC.
V prvé fázi si organizace musí uvědomit aktuální situaci a dokonale ji popsat. Většinou nastávají dvě
situace. Firma buď potřebuje zavést dosud nevyužívaný software na podporu podnikání a řešení
stávajících potíží, nebo naopak nahradit stávající software vhodnějším a často hlavně levnějším. Dále
je nutné, aby si stanovila jasné cíle, kterých chce dosáhnout zavedením software, respektive službou.
IT by vždy mělo podporovat business cíle organizace, a proto je nutné si převést možné přínosy
na reálné užitky pro organizaci. K cílům patří i metriky nutné ke zjištění, zdali firma cílů dosáhla a za
jakých podmínek.
Příprava na přechod do cloudu by měla obsahovat tyto body:
•
Definice cílů a metrik
•
Analýza stávající situace a definice požadavků na nové řešení
•
Výběr vhodného modelu zavedení SW
•
Výběr dodavatele
•
Sepsání potřebných smluv a příprava exit strategie
•
Proces přechodu do cloudu
4.1 Definice cílů a metrik
K zavedení nového software nebo změny stávajícího, firmu vždy vede určitá potřeba. Na jedné straně
to může být nepořádek a nejednotnost firemních dat, potřeba optimalizovat výrobní a prodejní procesy
a podpořit je IT systémem, nebo jen nutnost snížit náklady v určité oblasti. Tyto stimuly by měly
pomoci k definici cílů, kterých chce firma dosáhnout. Jako příklad cílů lze uvést snížení nákladů na
skladování zboží díky lepšímu řízení výroby a komunikaci s dodavateli nebo aktuální informace
o stavu obchodní zakázky pro všechny zaměstnance. Aby bylo možné zhodnotit, zdali se cílů dosáhlo
a byly veškeré náklady na software a jeho zavedení správně vynaloženy, je nutné stanovit metriky
dosažení cílů. To znamená určit cílová čísla, respektive stavy, kterých je nutné dosáhnout, aby bylo
možné cíle považovat za splněné. U ERP se to týká tvrdých a měkkých metrik, které jsou nastíněné
v kapitole 3.4.
57
4.2 Analýza stávající situace a definice požadavků
V prvé řadě si musí firma uvědomit současný stav svého IT a podmínek pro zavedení nového systému,
ať již klasickou formou nebo jako služby. Na základě této analýzy se bude firma rozhodovat, zdali
vůbec je pro ni cloud computing vhodný a je proto důležité ji nepodcenit a nehnat se za každou cenu
za novými technologiemi. Analýza by měla zvážit tyto oblasti:
•
Ekonomická situace a současné náklady
•
Velikost, struktura a geografické působení organizace
•
Závislost firmy na IT
•
Specifika firmy a nároky na customizaci
•
Citlivost dat a know-how (Preference vlastní infrastruktury)
•
Vlastní hardware – výkonnost, spolehlivost, rozšiřitelnost, záruky
•
IT a jiný odborný personál nutný pro zavedení systému
•
Možnosti integrace stávajících systémů
Na základě analýzy se stanoví požadavky na nový systém:
•
Podrobný rozpočet na první rok a orientační na další čtyři roky.
•
Požadavky na:
•
4.2.1
o
výkon,
o
dostupnost systému a konektivitu,
o
flexibilitu,
o
bezpečnost dat,
o
možnosti customizace,
o
integraci se stávajícími systémy,
Požadovaný stav IT personálu.
Ekonomická situace a současné náklady – definice rozpočtu
Pokud je jedním z cílů snížit náklady na používaný software a v dnešní době tento cíl asi nikdy nebude
chybět, je to podnět pro využití cloud computingu a služeb na něm postaveným. Záleží ale na velikosti
firmy a typu aplikace, jelikož SaaS nemusí být v dlouhém období vždy levnější variantou. [21] Pokud
ovšem firma musí daný software zavést, aby zůstala konkurenceschopná, tak je jistě SaaS vhodnější
variantou, jelikož ji na začátku nezatíží nutnou velkou investicí. Toto neplatí pro velmi malé firmy,
kde software většinou stojí mnohem menší peníze, než by stál pronájem služby na 12 měsíců. Je tedy
nutné zjistit ekonomickou situaci firmy a počet uživatelů, kteří software budou používat.
Pro vyhodnocení, zdali se firmě vyplatí přechod na cloud z on-premise řešení, musí znát současné
náklady a to jak kapitálové (CAPEX), tak operativní (OPEX). Nikdy nelze říci, kolik firma ušetřila,
58
pokud nezná stávající náklady. To bývá častým problémem při přechodu do cloudu. V případě pouhé
výměny SaaS poskytovatele se například ROI počítá vcelku snadno. U cloud varianty se počítá pouze
s operačními náklady, což výpočet také usnadňuje. Detaily výpočtů ROI a TCO jsou v kapitolách 3.4 a
3.5.
Výstupem této části by mělo být definování rozpočtu pro nový systém a související věci. Pro vedení
podniku je cena jedním z nejdůležitějších aspektů. Nákup a nasazení systému vždy schvaluje CFO,
který má jasné priority. Firma by si měla stanovit rozpočet, který bude mít k dispozici k dosažení cílů.
V rozpočtu se musí počítat minimálně s těmito položkami:
•
Náklady na licenci / předplatné u SaaS
•
Náklady na hardware a jeho údržbu (on-premise)
•
Náklady na implementaci a customizaci
•
Náklady na integraci a migraci dat
•
Servisní a maintenance poplatky
•
Mzdy IT oddělení nutné pro údržbu HW a podporu uživatelů
•
Řízení změn
•
Náklady na školení
ERP systémy jsou specifické velmi vysokými cenami za licence a druhá velká prvotní investice se
týká implementace. V případě implementace dodavatelem software může být práce na instalaci a
přizpůsobení aplikace firmě i vyšší než cena licence. Následující tabulka porovnává všechny tři
varianty nasazení ERP a zobrazuje související náklady.
Jednorázové (CAPEX)
Náklady
Licence ERP systému
Licence operační systém, databáze…
Hardware
Implementace
Customizace
Integrace
Migrace dat
Pravidelné (OPEX)
Tabulka 5 - Seznam nákladů ERP řešení
Školení
Poplatek za službu
Konektivita
Údržba hardware a aplikačního SW
Servisní podpora
Pronájem HW
Mzdy IT oddělení
SaaS
Private Cloud
On-Premise
59
Řízení změn
Aktualizace ERP licence
(maintenance)
Aktualizace OS, DB
Legenda: -obsahuje - neobsahuje - snížení -zvýšení
Napomáhá tedy i výpočtu ROI. Šipky označují zvýšené nebo snížená náklady dané varianty.
Rozpočtová omezení mohou velmi rychle rozhodnout ve variantu SaaS ERP, protože si firma nemůže
takové prvotní investice dovolit.
4.2.2
Velikost, struktura a geografické působení organizace
Cloud computing stále není vhodný pro všechny typy a velikosti organizací. Přináší mnoho příležitostí
pro malé firmy, úspory pro střední a velké firmy, ale ne vždy se na něj lze plně spolehnout. Dle studie
společnosti Gartner služby stále nejsou natolik vyspělé, aby nahradily robustní on-premise řešení
v největších firmách. SaaS ERP nachází uplatnění spíše pro více distribuovaných poboček v rámci
velkých organizací. Trh malých a středních firem může být s cloud verzí aplikace plně spokojen, ale
pro větší instalace stále vyhrává on-premise.
4.2.3
Závislost firmy na IT - požadavky na výkon, dostupnost, flexibilitu, spolehlivost
Ne pro každou organizaci je IT životně důležitým prvkem. Vysoká dostupnost systému je stěžejní pro
všechny firmy používající ERP. Bez funkčního IT se většinou zastaví celý běh firmy. V případě
požadavků na vysokou dostupnost vždy vychází lépe cloudová řešení. Datová centra na úrovni Tier
III, výjimečně i Tier IV (pouze mimo ČR) si mohou dovolit jen poskytovatelé služeb, nebo největší
firmy na světě, kterým se tato investice vrátí. Pokud má tedy firma vysoké nároky na dostupnost
aplikace, svými prostředky jich nedosáhne a je vhodné zvolit SaaS variantu, nebo využít outsourced
private cloud varianty. Značné rozdíly lze najít i v jednotlivých odvětvích. Například banky jsou
jedním z největších investorů do IT a jsou také velmi závislé na funkčnosti svých IT systémů. Lze tedy
říci, že pro ně i krátkodobý výpadek znamená opravdu velké ztráty a proto mají velmi vysoké nároky
na dostupnost, spolehlivost a hlavně zabezpečení provozovaných systémů. Přestože by i z minulých
kapitol mělo vyplynout doporučení využít cloud computingu, tak právě zde se tak zatím nikde neděje.
Banky budou mít ještě značnou dobu svá vlastní datová centra a tím pádem i on-premise řešení. Ne ani
tak kvůli tomu, že by poskytovatelé cloudu nebyli schopni dosáhnout stejné úrovně zabezpečení, nebo
dostupnosti, ale v tomto segmentu ještě nějakou dobu vydrží psychologické bariéry bránící svěřit svá
data někomu jinému. Druhým argumentem jsou nesmírné investice do vlastní infrastruktury a rozsah
IT zdrojů. Banky spíše přejdou k využití private cloud řešení a budou lépe využívat své zdroje, ale
public cloud zatím nepřipadá v úvahu.
60
Výkon aplikace může být dalším klíčovým bodem při rozhodování. On-premise systémy budou vždy
rychlejší a real-time aplikace nelze v cloudu z důvodu pomalejší odezvy provozovat. Pokud bude pro
firmu v první řadě důležitá okamžitá odezva aplikace, potřebuje přenášet velké objemy dat, tak je
vhodnější se přiklánět k on-premise řešení na dedikovaném hardware v místě působení. Naopak
aplikace náročné na počet operací, které nevyžadují okamžitou odezvu a kde se zátěž mění v čase, se
vyplatí situovat do cloudu. Výkon lze ale těžko měřit například při výpočtu ROI.
Flexibilita je jednou ze základních charakteristik pro cloud. Tím se pro všechny aplikace, kdy předem
nejsou jasné požadavky na výkon, počet uživatelů, objem zákaznických dat, nebo se tyto potřeby
v průběhu času výrazně mění, vyplatí zvolit cloudové služby. Stejně tak i pro aplikace s nejasnou
životností, nebo provozem omezeným na krátkou dobu. Nemusí se složitě plánovat potřebný počet
uživatelů na licenci a vypočítávat, kolik bude stát v budoucnu její rozšíření. V opačném případě při
nutnosti snížení s klasickými licencemi moc hýbat nelze. Licence je nakoupena na rok nebo více
dopředu a změny lze provádět případně až při placení ročního maintenance. Při restrukturalizaci
podniku může mít firma v licenci zbytečně utopené finance.[61]
4.2.4
Specifika firmy a nároky na customizaci
Organizace, silně se odlišující svými výrobními a obchodními procesy, budou hledat SaaS řešení hůře
a spíše si zaplatí on- premise řešení na míru. ERP musí podporovat dané odvětví a jeho specifika a až
pak se organizace rozhoduje, kterou variantou software nasadit. V komplexnosti a připravenosti
systému pro nejširší možná odvětví stále vede on-premise řešení SAP. Až na výjimky také obecně
platí pravidlo, že v případě nutnosti zásadně upravovat software na míru, je třeba zvolit klasickou
variantu software a upravovat instalaci u daného zákazníka. Pro začínající firmy nebo při zavádění
software, který řeší oblast, pro kterou ještě nejsou nastaveny procesy, se vyplatí využít best practices
ukryté v SaaS. Například CRM malé firmě přinese návod jak pracovat s daty o zákaznících od prvního
oslovení, přes jejich získání a následnou péči. Dále také záleží na typu aplikace, kterou firma
požaduje. Tomu se věnuje kapitola 2.6.
4.2.5
Citlivost dat a know-how – požadavek bezpečnosti
Povaha firemních dat může velmi rychle zavrhnout jakékoliv myšlenky o využití cloud služeb,
respektive přesunu vlastního systému do cloudu. To se týká i případu vlastní jedinečné aplikace,
kterou si firma bude chtít udržet v tajnosti a zůstane u on-premise řešení. Pokud jde o citlivost dat
v cloudu, tak ta lze řešit NDA smlouvami. Předchozí kapitoly 2.4 a 3.2 zřetelně vysvětlují, že cloud
computing služby jsou u zavedených a časem prověřených poskytovatelů naprosto bezpečné a
ve valné většině případů nejsou jejich zákazníci schopní dosáhnout lepší a často ani podobné úrovně
zabezpečení samotné aplikace ani dat. Ať již se jedná o zabezpečení fyzického přístupu do datového
centra, nebo nepřístupné firewally57. Pokud jde o bezpečnost, tak takřka vždy vítězí cloudové služby.
57
Firewall – ochranný prvek síťové vrstvy, který zamezí neoprávněnému přístupu do sítě
61
Nelze z toho ale usuzovat globální doporučení přecházet na cloud služby z důvodu bezpečnosti. Jsou
případy, kdy je nutné držet své on-premise řešení, nad kterým má firma plnou kontrolu a snižuje tak
možnost zneužití dat. Nejčastěji u kritických aplikací, nebo aplikací obsahujících know-how firmy,
jehož vyzrazení by mohlo znamenat ohrožení konkurenceschopnosti firmy. To se týká i ERP.
4.2.6
Vlastní hardware a lidské zdroje
Jinou výchozí situaci pro přechod do cloudu nebo využívání XaaS služeb má firma, která začíná své
podnikání takzvaně na zelené louce a ta, která před půl rokem investovala do nových serverů a
systémů pro zálohování dat a nepřerušení elektrické energie. V případě vlastních hardware zdrojů
bude pro firmu přechod na cloud méně výhodný, protože se ji investice do hardware nemusí nijak
vrátit. Na vlastní hardware se ale váží další náklady na jeho provoz a údržbu, což vyžaduje i odborný
personál. V situaci, kdy firma přechází z on-premise na cloud záleží jaké systémy zůstanou ve správě
firmy a kolik provozních záležitostí se přesune na poskytovatele. Z toho lze odvodit výsledný
požadavek na rozsah lidských zdrojů.
4.2.7
Možnosti integrace stávajících systémů
U stávajících systémů je nutné zjistit možnosti integrace a také formáty dat, přes které komunikují
stávající dodavatelé. Nasadit systém, s kterým nebude umět komunikovat okolí podniku, by bylo více
než neefektivní. Cloud služby nemají s integrací problémy a vývoj jde stále dopředu. Problémy se tedy
mohou vyskytnout spíše u individuálně vyvinutých aplikací a doplňků. Na základě těchto informací
lze stanovit požadavky na možnosti integrace nového systému. Požadavky jsou společné pro všechny
modely zavedení software. Pouze v případě větších objemů dat, které by měly migrovat mezi systémy,
je nutné zvážit odezvy systému a kapacitu síťového připojení. Další otázkou je integrace z cloudu
do cloudu oproti cloudu s on-premise systémem. V prvním případě je zákazník odkázán plně na
možnosti integrace jednotlivých cloud služeb a nelze zde dělat moc změn. Ve druhém se naskýtá
možnost úpravy kódu on-premise řešení tak, aby bylo schopné komunikace s cloud systémem. U méně
zavedených poskytovatelů se často objevuje proprietární řešení, které nejde cestou standardů a ztěžuje
možnosti integrace. Ty by sice měly být co nejširší, aby systém vyhovoval co nejvíce zákazníkům, ale
objevují se i případy, kdy je to naopak složité a dokonalá integrace funguje jen s ostatními produkty
daného poskytovatele. Typickým příkladem je Microsoft, který má široké portfolio produktů a nutí
zákazníka využívat jeho řešení právě z těchto důvodů.
4.3 Volba vhodného modelu nasazení
Volba může být pro organizaci jasná dle pěti potřebných vlastností a šestá vlastnost rozhodne pro
opak. Na zaváděný systém a situaci ve firmě je nutné nahlížet ze všech možných pohledů, které byly
zmíněny v této i předešlých kapitolách.
62
Zákazníkovi může pomoci vyplnění následující tabulky, kde označí danou oblast dle stupně důležitosti
v rozsahu nízká, střední, vysoká (počet hvězdiček).
Specifika dané firmy
Standardní kritéria
Tabulka 6 - Hodnotící tabulka kritérií pro ERP řešení
Požadavky na:
Dostupnost aplikace
Okamžitá odezva (real time aplikace)
Možnosti customizace
Mobilita
Bezpečnost
Flexibilní licencování
Škálovatelnost hardware
Výkon
Důležitost pro zákazníka
Rychlost implementace
Silně specifické prostředí
Závislost firmy na IT
Nároky na integraci
Vlastní hardware
Vlastní kapitál pro začátek
Dostupná konektivita
Na základě jejího vyplnění může výsledky porovnat s vlastnostmi daných variant a vybrat tu
nejvhodnější, pro jeho potřeby.
Specifika dané firmy
Standardní kritéria
Tabulka 7 - Parametry daných variant ERP řešení
Pohled hodnocení
Dostupnost aplikace
Okamžitá odezva (real time aplikace)
Možnosti customizace
Mobilita
Bezpečnost
Flexibilní licencování
Škálovatelnost hardware
Výkon
Rychlost implementace
Silně specifické prostředí
Závislost firmy na IT
Nároky na integraci
Vlastní hardware
Vlastní kapitál pro začátek
Dostupná konektivita
SaaS
Private Cloud
On-Premise
63
Níže jsou uvedena určitá doporučení, která mohou výběr usnadnit.
Faktory mluvící pro SaaS:
•
Kolísající potřeba hardwarového výkonu
•
Nejasná doba trvání firmy, nebo projektu
•
Potřeba vysoké dostupnosti a 24/7/365 podpory
•
Požadavek mobilního přístupu k aplikaci
•
Nedostatek prostředků pro jednorázovou investici
•
Více poboček se stejnými potřebami
•
Důležitá je rychlost implementace
•
Chybějící IT oddělení a zkušenosti
Faktory mluvící pro On-Premise a private cloud:
•
Výskyt kritické a real-time aplikace
•
Velká mezinárodní firma (Tier I)
•
Silně specifické a unikátní firemní prostředí (nutnost velké customizace)
•
Vlastní software a náročné integrační prostředí (custom development)
•
Vlastní datové centrum
•
Dostatek financí pro investici do licence
•
Slabá internetová konektivita v místě podnikání
Další odstavce této kapitoly předpokládají výběr SaaS varianty.
4.4 Výběr dodavatele (poskytovatele služeb)
Nejdříve je nutné si ujasnit, zdali firma poptává úplně novou funkcionalitu, nebo chce jen on-site
variantu přenést do cloudu, respektive ji nahradit SaaS variantou. V prvním případě firma nemá co
porovnávat a pouze hledá ideálního dodavatele služby. V případě že již firma nějaké řešení používá,
má také určité zkušenosti, jak se software, tak s jeho dodavatelem.
Redaktoři internetového magazínu TechTarget [62] položili velmi zajímavou otázku, zdali přejít do
cloudu ke stávajícímu poskytovateli současného in-house řešení, nebo přejít k jinému „SaaS only“58
poskytovateli ERP? Steve Phillips59 v takovéto situaci doporučuje otestovat funkčnost nabízeného
software, vhodnost daného balíčku a implementační podporu. Dále také předpokládaný další
dlouhodobý vývoj software, stabilitu a TCO dané technologie.
58
SaaS Only – Poskytovatel pouze SaaS služeb. Nenabízí on-premise řešení.
StevePhillips – ERP expert, redaktor TechTarget [http://searchmanufacturingerp.techtarget.com/expert/StevePhillips]
59
64
Pokud by firmu zajímala jen samotná podpora řešení a vynaložené náklady, tak je nutné se zamyslet
nad těmito body:
•
Pokud měla firma v minulosti problémy s podporou, tak je zbytečné očekávat, že u SaaS to
bude lepší. Lze ale sepsat lepší servisní, respektive SLA smlouvu, která bude vyžadovat lepší
technickou podporu pod pokutami.
•
U poskytovatele pouze SaaS řešení je důležité zjistit, v čem se jeho přístup liší od ostatních
firem. Jestli jen přiděluje více zdrojů pro SaaS, nebo ví více o software a má mnohem
stabilnější hostingové prostředí.
•
Pokud by firma zůstala u stejného poskytovatele, usnadní ji to přesun do cloudu? Nebo bude
migrace stejně složitá jako přechod k někomu jinému? Stejný poskytovatel by měl být na
takovéto případy připraven a vlastnit migrační nástroje. Sám zná nejlépe strukturu dat svého
software a přechod by tedy v ideálním případě měl být hladký.
•
Velmi důležitá myšlenka je také ta, že poskytovatel nebude chtít ztratit zákazníka a určitě
bude ochotný přistoupit na výhodnější cenové podmínky.
Na toto výborně navazuje blogový příspěvek Jamese Statona ze společnosti Forrester Research, Inc.
[63], který říká, že I&O60 profesionálové jsou pod nesmírným tlakem, aby přijali cloud služby.
Problém nastává, když se poskytovatelé snaží dodat služby, které nabízejí to samé co má firma
on-premise na svých strojích a nazývají to cloud službami. Tento případ společnost Forrester nazývá
„cloudwashing“61. Firma tím nemusí nijak trpět, ale nedostává se jí poté veškerých užitků, které má
cloud přinést.
„Pokud odmítáte opravdové cloud služby, tak nastal čas tento názor změnit. / If you are dismissing
true cloud services, it is time to change that attitude“ [63]
Proto, aby si firma lépe uvědomila jaká je její současná situace a co jí mohou cloud služby přinést, je
třeba si nejdříve uvědomit, zdali již některé cloud služby využívá a pokud ne, tak se o to ihned
pokusit. Stačí k tomu třeba i testovací zavedení určitého systému do cloudu, aby získala zkušenosti a
od těch se mohla odrazit při rozhodování, zdali se cloud služby hodí pro tu či onu aplikaci. [63]
Doporučení pro výběr poskytovatele:
•
Vybírat jen praxí ověřené a stabilní poskytovatele
•
Požadovat minimálně certifikáty ISO 9001, 27001 (vhodný je ISO 20001)
•
Pokud se poskytovatel brání bezpečnostnímu auditu a nezveřejňuje zpětně kvalitu svých
služeb, tak ho okamžitě zavrhnout
•
60
61
Vybírat poskytovatele, který využívá standardy a ne proprietární technologie
I&O – Infrastructure and Operations – Infrastruktura a provoz
cloudwashing – alternativa k „brainwashing“
65
•
Trvat na SLA a NDA smlouvách prověřených právníky z oboru IT
•
Zkusit kontaktovat referenční zákazníky a zeptat se na spokojenost s poskytovatelem služeb
•
Poskytovatel, který má za zákazníka firmy ve stejném oboru bude již danému odvětví lépe
rozumět
4.5 Sepsání potřebných smluv a příprava exit strategie
4.5.1
Smlouva o mlčenlivosti (NDA – Non-Disclosure Agreement, CA - confidentiality
agreement)
Tato smlouva se sepisuje mezi poskytovatelem a zákazníkem, aby nedošlo k vyzrazení nebo zneužití
zákazníkových dat, obsahujících citlivé informace a jedinečné know-how. Dohoda o mlčenlivosti dle
JUDr. Lukáše Jansy [64] by měla obsahovat tyto části:
Definice důvěrných informací
Smlouva by postrádala význam a těžko by se právně vymáhaly vzniklé škody, pokud není přesně
specifikováno, co je důvěrná informace a čeho všeho se smlouva týká. Dle JUDr. Jansy by za důvěrné
ve smyslu § 271 obchodního zákoníku, měly být považovány zejména technické či obchodní údaje
nebo jiné informace, které nejsou veřejně dostupné, know-how firmy, popis funkcionality softwaru,
zdrojové kódy, počítačové programy, procesy, návrhy, náčrtky, plány, výkresy, koncepce, specifikace,
databáze, cenové informace, podnikatelské, finanční a marketingové plány. Dále jsou to analýzy,
dokumenty, smlouvy a řešení tvořící součást nabídky zhotovitele softwaru. V neposlední řadě i
informace, vynálezy a jiné zákonem chráněné předměty duševního vlastnictví vytvořené z podnětu
zájemce o softwarové řešení nebo na základě jednání. Poté záleží na firmě, které další informace
označí jako důvěrné.
Definice závazku mlčenlivosti
Závazek znamená, že se výše uvedené informace budou chránit jako důvěrné a poskytovatel je
povinen zajistit, že nedojde k jejich zveřejnění nebo zneužití bez písemného souhlasu vlastníka dat.
Jansa dále doporučuje definovat závazek mlčenlivosti negativním vymezením. To znamená definovat,
kdy poskytnutí citlivých informací není v rozporu se smlouvou. Jedná se například o poskytnutí
informací orgánům, které mají ze zákona právo na kontrolu, nebo ostatním smluvně ošetřeným
stranám. Případně jiné specificky definované výjimky.
Stanovení sankce při porušení mlčenlivosti
K dodržení závazku musí zavázanou stranu vést určitá motivace. Nejčastěji je to smluvní pokuta
za nedodržení stanovených podmínek. Ta by měla být ve výši maximální možné škody hrozící
poškozené straně při vyzrazení dané informace. Bez jasně stanovených pokut se u soudu těžko
prokazuje utrpěná ztráta a tím pádem se i těžko vymáhá náhrada škody.
66
Doba trvání mlčenlivosti
Doba trvání by měla být v ideálním případě na neomezenou dobu. V praxi to bývá na dobu, kdy platí
určitý vztah mezi stranami a jistou dobu po jeho ukončení.
NDA je často obsahem i zaměstnaneckých smluv. Vzhledem k outsourcingu, nebo u služeb obecně se
někdy sepisuje smlouva o mlčenlivosti i s konkrétními zaměstnanci dodavatele.
4.5.2
Smlouva o garanci úrovni poskytovaných služeb (SLA – Service Level
Agreement)
SLA smlouva je nástroj zaručující odpovídající úroveň služeb a postihy za jejich nedodržení nejen
v oblasti cloudu. Tato smlouva se občas nesprávně zaměňuje se servisní smlouvou, která definuje
poskytovanou podporu. Servisní smlouva se omezuje pouze na definici rozsahu telefonické a
e-mailové podpory, kdy je možné se na dodavatele obracet, jakou formou hlásit vady, garantované
časy reakcí a oprav v případě vzniklých potíží. Smlouva o garanci úrovně poskytovaných služeb se
zabývá kvalitativními parametry služby, způsoby, kterými se parametry hodnotí a pokutami za
nedodržení smlouvy.
Úplná SLA smlouva by měla obsahovat následující části [5] [65] [66] [67] [68]:
Identifikace zákazníka a poskytovatele
Jako v každé smlouvě musí být uvedeno, mezi jakými stranami je smlouva sepsána. Je vhodné
definovat kontaktní osoby, které mají z obou stran přehled o smlouvě a provádějí hlášení problémů a
měření parametrů služby.
Přesný popis služeb a jejich obsahu
Služby, které jsou předmětem smlouvy, musí být přesně popsány. Stejně jako u smlouvy
o mlčenlivosti je i zde vhodné použít negativní vymezení, čeho se smlouva netýká a co není součástí
služeb.
Objem popisovaných služeb
Uvádějí se parametry jako počet uživatelů služby, parametry virtuálních strojů, rychlost internetového
připojení a další.
Kvalitativní charakteristiky služeb
Charakteristiky, které tvoří tu nejdůležitější část smlouvy, tedy to, co smlouva zaručuje. Nejčastěji se
jedná o garantovanou dostupnost služby. Ta se udává v procentech dostupnosti služby za měsíc nebo
rok. Měsíční výpočet je praktičtější, protože se služby nejčastěji platí měsíčně a výše platby se odvíjí
od splnění SLA. Výpočet dostupnosti je jednoduchý a je uveden v odstavci Vysoké náklady na zřízení
datového centra. části 2.5.2.
67
Další parametry je vhodné rozdělit dle typu služby:
•
SaaS – dostupnost, odezva systému,
•
PaaS – uptime serveru, odezva DB, dostupnost služeb,
•
IaaS – dostupnost, odezva, rychlost vytvoření virtuálního stroje, síťová propustnost, odezva
sítě, počet ztracených paketů.
Důležitá je i odezva systému, která definuje, za jaký okamžik systém zareaguje na zaslaný pokyn. Ta
se liší dle náročnosti aplikace a bývá v rozmezí ms až několika sekund. 100% dostupnost je k ničemu,
pokud má systém moc dlouhé odezvy. Pozor také na plánované výpadky kvůli údržbě systému, které
jistě ve výpočtu dostupnosti zahrnuty nebudou.
Obecně se garantuje hlavně technologie na pozadí, jako je spolehlivost hardwarových prvků díky
duplikaci a zálohování dat. Nelze garantovat 99,99% dostupnost SaaS služby, protože mezi datovým
centrem poskytovatele a koncovým monitorem uživatele je nesčetně prvků, které mohou mít na toto
číslo vliv.
Toto by měl vědět i zákazník a u ERP ve formě služby se vyskytují spíše jiné parametry. Jedním může
být například počet dní, kdy musí být předem hlášený výpadek služby kvůli údržbě. Rozdílná cena
SLA bude například u 3 nebo 30 dní dopředu.
Měření a reporting výsledků
Měření domluvených parametrů by měly provádět obě strany a to zcela průhledně a předem
nastaveným způsobem. Důvěryhodný poskytovatel má sám veřejně dostupné statistiky dostupnosti viz
například NetSuite62. Poté by nemělo docházet ke sporům a výmluvám, že za výpadek může někdo
jiný. Měření a reporting by měl dodávat data pro měsíční vyúčtování, takže se nejčastěji měří
v měsíčních cyklech. Pokud není způsob měření a reportování detailně zmíněný ve smlouvě, tak i
garance 99,99% dostupnosti pozbývá platnosti.
IaaS lze měřit například pomocí SNMP63, který hlídá funkci a změří s jakou odezvou server a různé
jiné síťové prvky odpovídají.
Dostupnost SaaS v praxi měřit nelze. Bylo by to možné pouze v případě vlastní dedikované síťové
linky mezi poskytovatelem a zákazníkem, což bývá velmi výjimečné. V opačném případě je zde, jak
již bylo řečeno, mnoho další vlivů, které neumožňují průkazné měření.
Více se měřením a reportingem zabývá kapitola 4.7.
62
63
NetSuite – Stav systému dostupný na https://status.netsuite.com/status_en_US.html
SNMP - Simple Network Management Protocol – protokol pro hlídání
68
Ceny služeb
Tato část obsahuje cenu služeb při dodržení všech podmínek a domluvené slevy při odchýlení od
těchto hodnot. Pokud se hlídané hodnoty odchýlí nad určitou mez, tak se služby poskytují zdarma,
nebo se snižuje pravidelný poplatek. Lze uvést tři používané druhy měření a souvisejících kreditů
respektive slev [69]:
•
Poměrný kredit (pro-rated credit) – Dle doby, kterou byla služba nefunkční, mimo
garantovanou dostupnost se zákazníkovi přidá kredit zdarma ve formě násobku doby výpadku.
Například GoGrid64 za jednu hodinu výpadku zákazník nabízí 100 h zdarma. Kredit nemůže
přesáhnout placenou částku za službu a nevrací se zde peníze.
•
Sleva při překročení určité doby výpadku (threshold credit) – sleva je aplikována až při
překročení určité doby výpadku. Poskytovatel může garantovat 99,99% dostupnost, ale slevu
za službu dostanete jedině při výpadku vyšším jak 30 minut. Má tedy určitý čas na vyřešení
problému.
•
Procentuální sleva (percentage credit) – v tomto případě zákazník obdrží procentuální slevu
z příští faktury dle překročení garantované dostupnosti. Například při horší jak 99,95%
dostupnosti, obdrží 10% slevu na další měsíc.
Bezpečnost
Z pohledu bezpečnosti SLA definuje jak fyzické zabezpečení datového centra, tak i autentizaci
uživatelů na úrovni software.
Zálohy a Disaster Recovery Plan
SLA dále popisuje zálohy zákaznických dat. Dle dohody se udává interval záloh (denní, týdenní,
měsíční), zdali je záloha kompletní nebo jen inkrementální, co se vše zálohuje a kam. Zákazníka
zajímá jak rychle mohou být data obnovena. Na to navazuje schopnost systému obnovy po výpadku
nebo například přírodní katastrofě (např. lokální požár, nebo záplavy). To se jmenuje Disaster
Recovery Plan, který definuje přesné kroky, pokud nastanou kritické situace a potřebný čas k obnově
dat a služeb.
Modifikace systému
Změny systému se u SaaS dějí většinou automaticky. Lze definovat ceny za případné nadstandardní
úpravy systému. Patří sem i ohlašovací povinnost jakýchkoliv poskytovatelem plánovaných změn.
Vlastnická práva
Ujednání, že za každých okolností zůstávají zákazníkovi výlučná práva na jeho data. Dále popis
autorských práv k využívaným službám. Je vhodné podchytit situaci, kdy chce firma od poskytovatele
64
GoGrid - http://www.gogrid.com/
69
odejít a potřebuje svá data zmigrovat. Ve smlouvě by měl být stanoven poplatek, za který poskytovatel
s touto migrací pomůže.
Postavení smlouvy, podmínky změny a ukončení smlouvy
Smlouva musí také obsahovat její postavení, zdali je samostatná nebo doplňkem jiné smlouvy. Pak
také povolené možnosti změn smlouvy a možnosti jejího ukončení v případě neplnění jedné nebo obou
stran. Mělo by být i stanoveno, co se bude dít po ukončení smlouvy, takzvaně „den poté“. Nelze
službu okamžitě vypnout, protože zákazník potřebuje data zmigrovat a navázat na jiný systém.
Jako jednoduchý příklad lze uvést smlouvu o úrovni služeb služby Google Apps65 nebo jednotlivé
SLA smlouvy pro Microsoft Windows Azure66. Precizně je sepsána smlouva67 společnosti GoGrid,
která se specializuje na IaaS.
SLA - obecná doporučení
Pokud poskytovatel služby nevlastní své datové centrum a využívá k tomuto účelu třetí stranu, vyplatí
se sepsat trojstrannou smlouvu. Standardně by totiž zákazník měl smlouvu jen s koncovým
poskytovatelem smlouvy a ten by se mohl vyhýbat plnění za nedodržení podmínek výmluvou na třetí
stranu. Tímto má zákazník jednak větší přehled o struktuře dodávané služby a také větší právní sílu
v případě řešení problémů.
Jedním z problémů bývá, že zákazník neví, jak má být SLA smlouva správně postavena. Tato situace
ovšem lze řešit najmutím externích konzultantů a právníků z oboru IT. Společnou věcí pro SLA
smlouvy je i neexistence žádného smluvního typu, do kterého by zapadaly. U soudu poté často není
jasné, dle jakých právních ustanovení daný nastalý problém posuzovat. [70]
Hlavní potíž je ta, že velcí SaaS poskytovatelé občas neumožňují takto konkrétní smlouvy sepsat.
Například salesforce.com se navenek tváří, jakoby žádné SLA smlouvy u nich neexistovaly a většina
zákazníků se patrně spoléhá na léty prověřenou důvěryhodnost firmy. Na speciálním webu68 se sice
mohou dočíst veškeré parametry zabezpečení, disaster recovery plan, zpětně se dozvědět výpadky
v kvalitě služby, plánovaná data výpadků kvůli údržbě a další informace. Nikde se ale zákazník
nedozví garantovanou dostupnost služby. Dle souhrnu webu online-crm.com [71] salesforce.com
nabízí SLA jen na vyžádání velkým společnostem. Je tedy na zákazníkovi, zdali bude schopný
vyjednat smlouvu s garantovanou dostupností a nějaké slevy na poplatku v případě jejího nedodržení.
Pozor by se mělo dát i na obecné SLA smlouvy, které se odkazují na výčty parametrů na webových
stránkách. Ty se mohou kdykoliv změnit a zákazník se proti tomu nemá jak bránit. [72]
65
Google Apps SLA – k dispozici na http://www.google.com/apps/intl/cs/terms/sla.html
Microsoft Windows Azure SLA – k dispozici na http://www.windowsazure.com/en-us/support/sla/
67
GoGrid SLA - http://www.gogrid.com/legal/sla.php
68
salesforce.com - http://trust.salesforce.com/trust/index.html
66
70
Z pohledu poskytovatele je zde otázka, zdali by měli mít jednodušší standardizované smlouvy, nebo je
psát na míru zákazníkům. Služba bude patrně vždy natolik kvalitní, aby vyhověla té nejtvrdší smlouvě,
protože se jedná o jednotné prostředí pro všechny zákazníky. Poskytovateli se tedy vyplatí spíše
jednotná garance kvality, když je řeč o dostupnosti. Tím, že nabízí výborné parametry dostupnosti
všem, přiláká i menší zákazníky. Vhodné je také specifikovat, že plánované výpadky se nepočítají do
měření dostupnosti služby. Smlouvy by se měly lišit spíše v definici poskytované technické podpory.
Kdo vyžaduje 24/7 telefonickou podporu a řešení problému do 2h, zaplatí mnohem více, než kdo se
spokojí s e-mailovou komunikací s garancí odezvy do 4h. Dražší bude i hlášení plánované odstávky
měsíc dopředu.
4.5.3
Exit Strategie
Před samotným přechodem do cloudu je nutné si rozmyslet i takzvanou exit strategii pro případ, že
zákazník zjistí, že je potřeba změnit poskytovatele, nebo produkt. Měla by obsahovat minimálně tyto
body [73]:
•
Možnosti získání veškerých dat uložených u poskytovatele a podmínky (formát, cena, způsob
dodání)
•
Možnosti migrace na jiné SaaS nebo on-premise řešení
•
Možnost přenosu nastavených procesů na jiné řešení
Export dat v případě ukončení služby by měl být ošetřen i v SLA smlouvě.
4.6 Proces přechodu na SaaS
Následující body nastiňují vhodný způsob samotného přechodu na SaaS.
•
Migrační strategie
•
Záloha všech dat
•
Nastavení uživatelů, jejich rolí a customizace nového systému
•
Integrace s ostatními systémy
•
Migrace dosavadních dat
•
Testování a převzetí
•
Školení zákazníka
Migrační strategie
Jako první je nutné zvolit migrační strategii, respektive plán migrace. Přechod na nový systém je
projekt, který by měl mít jasné fáze a termíny. V každé fázi musí být specifikováno, co je jejím cílem
a do kdy musí být splněna, protože na ni navazuje fáze další. Měly by být určeny jednající osoby nebo
týmy za obě strany. Migrační plán je důležitý spíše u změn systémů, například z Microsoft Dynamics
AX do JD Edwards EnterpriseOne ve formě SaaS. U instalace takzvaně na zelené louce se moc dat
71
nepřevádí a situace je jednodušší. Migrační strategie musí zahrnovat i zajištění bezpečnosti dat. Toto
vše by mělo být sepsáno v migrační smlouvě.
“Pro uživatele je totiž zcela zásadní ochrana dat, která jsou zpřístupněna i během migrace
zaměstnancům IT firem a naopak pro IT firmu zase odpovědnosti za ztrátu dat při migraci a definice
součinnosti, tak aby migrace proběhla bez jakýchkoliv obtíží.” JUDr.Lukáš Jansa [74]
Záloha všech dat
Před jakoukoli prací se stávajícím systémem je nutné zálohovat veškerá potřebná data. To znamená
obsah systémů, ale také jeho nastavení, seznamy uživatelů a jejich rolí. Záleží na dohodě, kdo bude
zálohu provádět.
Nastavení uživatelů, jejich rolí a customizace nového systému
V tomto bodě je nutné převést, nebo založit veškeré uživatele a jejich role v novém systému. Může
hodně pomoci synchronizace například s Active Directory. Přizpůsobuje se také používání systému
business procesům organizace.
Integrace s ostatními systémy
Pokud se nejedná o všeobsahující ERP balík, nebo ryze stand-alone aplikaci, pak je nutné zajistit
integraci se zbylými systémy, které se ve firmě používají. Může se ale jednat i o integraci se systémy
dodavatelů a odběratelů. Co a jak se bude integrovat a kdo to zařídí, by měla obsahovat již migrační
strategie.
Migrace dosavadních dat
Jeden z často velmi problémových milníků. Data mohou mít velmi různorodou podobu a hlavně
kvalitu. Většinou se jedná o databázovou záležitost, kde se používají nejrůznější datové pumpy, nebo
využití exportů a importů pomocí standardizovaných formátů (například CSV, XML). Po migraci je
nutné ověřit, zdali byla převedena opravdu všechna data a případné rozdíly dořešit.
Testování a převzetí
V této fázi by již měl být systém plně připraven a následuje testování funkčnosti a někdy i zátěžové
testy. Pokud vše souhlasí, tak se sepíše akceptační protokol a systém je převzat zákazníkem jako
kompletní a v pořádku. Případně může být převzat s výhradami, které se budou ještě řešit v rámci
změnového řízení.
Školení zákazníka
Školení je pro úspěch software a dosažení plánovaných cílů obecně velmi důležité. Školí se většinou
jen osoby, zastupující danou část firmy, a ty to nadále s podporou dokumentace předávají svým
spolupracovníkům.
72
4.7 Průběh používání XaaS
Samotný průběh využívání služby na první pohled nevyžaduje žádný popis. Zákazník jednoduše platí
poplatky za odebíranou službu a tím je vše vyřešeno. Tak by to ovšem fungovalo v ideálním prostředí,
kde jsou služby bezchybné a 100% dostupné za každých okolností. Jelikož tomu tak není a výpadky se
vyskytují i u nejspolehlivějších poskytovatelů, je nutné kvalitu služby měřit a dle toho žádat slevy
z pravidelných poplatků.
Monitoring
Popis samotného měření služeb je velmi důležitý bod SLA smlouvy, viz kapitola 4.5.2. Pro měření se
využívá služeb nebo aplikací nainstalovaných jak u poskytovatele, tak u zákazníka. Nejčastěji se
kontroluje dostupnost a odezva. Může to vypadat i tak, že se aplikace snaží chovat jako reálný uživatel
a pravidelně se ke službě připojuje a měří odezvu na její dotazy.
Pokud zákazník využívá například IaaS, nebo SaaS od světoznámých společností, jako je Amazon
Web Services, nebo salesforce.com, má situaci usnadněnou. Nejenže samotní poskytovatelé nabízejí
nástroje pro sledování dosažených výsledků jejich služeb, ale existuje i několik nezávislých
organizací, které měří a i zdarma prezentují dosažené výsledky dostupnosti a dokonce i odezvy.
Vlastní nástroje vybraných poskytovatelů:
•
Amazon Web Services - http://aws.amazon.com/cloudwatch/
•
salesforce.com - http://trust.salesforce.com/trust/status/
Nezávislé monitorovací systémy výkonu cloud služeb:
•
CloudSleuth - https://cloudsleuth.net/
•
CloudHarmony - http://cloudharmony.com/status
CloudSleuth je velice zajímavá služba, která je schopna reálně prezentovat odezvy systémů největších
poskytovatelů po celém světě. Docílili toho nainstalováním jednoduché aplikace k jednotlivým
poskytovatelům a s její pomocí měří odezvy. Služba na druhém konci světa může mí odezvu až 25s,
což je pro klasickou práci nepřijatelné. CloudHarmony je podobná služba sledující dostupnost více jak
sta poskytovatelů IaaS. Již se v těchto systémech zobrazují i čeští zástupci, jako například
Cloudee.eu69, takže je vhodné tyto systémy sledovat. Zákazník se může z historických dat přesvědčit o
spolehlivosti poskytovatele.
Důležitým faktem, který potvrzuje i Petr Loužecký ze společnosti Algotech BSC, je nemožnost měření
dostupnosti SaaS. Pro firmu je tedy důležitější například audit datového centra, který zaručí schopnost
technologie dosáhnout na klasifikaci Tier III a garantovat až 99,99% dostupnost spolu s vysokým
69
Cloudee - http://www.cloudee.eu/
73
zabezpečením. Zákazníci jsou tedy odkázáni na pravidelný report o dosažené dostupnosti od
poskytovatele. Co mohou rozporovat je například reakce technické podpory, nebo rychlost řešení
problémů.
Vyhodnocování
Na základě dosažených měření, která se provádějí, buď měsíčně, nebo v jiném časovém intervalu, dle
smlouvy, se vyhodnocují dosažené parametry. Výsledné reporty tedy nejčastěji posílá poskytovatel.
V případě měřitelných IaaS služeb je možné využitím vlastních nebo veřejných služeb dostupnost a
odezvy rozporovat. Na základě zjištěných nedostatků se přistupuje k aplikaci dohodnutých slev, nebo
bonusů. Pozor je nutné dát na tři různé přístupy slev definované v odstavci týkajícího se cen v kapitole
4.5.2.
74
5 Případová studie na Oracle JD Edwards EnterpriseOne
Tato studie srovnává nasazení stejného ERP produktu ve třech různých scénářích nasazení. Jsou zde
popsány všechny nutné investice a operační náklady. Jednotlivé varianty jsou porovnány pomocí ROI
a TCO metodik pro časový horizont 3 a 5 let. Ukazuje také využití hodnotící tabulky u požadavků
na systém.
5.1 Popis zákazníka
Zákazníkem pro tuto případovou studii je klasická výrobní firma v oblasti strojírenství, která
nakupuje, prodává, vyrábí a skladuje. Celkově má 150 zaměstnanců, ale jen 35 uživatelů, kteří přímo
pracují s ERP systémem. Před investicí měla dva IT specialisty. Obrat firmy je 300 milionů Kč a
na skladě drží zboží v ceně 50 milionů Kč. Na výrobku má firma 20% marži. IT oddělení tvoří dva IT
experti.
5.2 Popis dodávaného produktu
Jedná se o standardní ERP systém společnosti Oracle. Jméno systému je JD Edwards EnterpriseOne,
který vznikl po akvizicích původního JD Edwards a PeopleSoft. Řešení JD Edwards EnterpriseOne
obsahuje tyto moduly:
•
•
•
•
•
•
•
•
•
Oracle Technology Foundation
System Foundation
Financials
Financial Management and Compliance Console
Procurement and Subcontract Management
Inventory Management
Sales Order Management
Manufacturing Management
Quality Management
Nabízí se předpřipravené řešení Accelerate, které řeší Finance, Nákup, Prodej a Sklady. Jsou to
předpřipravené procesy, dle best practices u dřívějších zákazníků. Součástí je kompletní procesní
dokumentace, školení a případné drobné změny. Přednastavené řešení zahrnuje i implementaci
předpřipraveného řešení. Teoreticky není nutná žádná velká customizace. Zákazník si řešení vezme
tak jak je připravené a zdokumentované a jen se přiřadí potřebné uživatelské role všem uživatelům
zákazníka. Výhodou je velká úspora času, jelikož Accelerate řešení je teoreticky možné rozběhnout
do 1 měsíce od podpisu smlouvy v případě SaaS, nebo private cloud. U on-premise je implementace
zhruba o měsíc delší, jelikož se balíčky spíše přizpůsobují zákazníkovi a jeho systémům.
Výrobní modul (Manufacturing Management) obsahující MRP, kusovníky, plánování výroby, výrobní
náklady, výrobní projekty a jiné, je individuální a vyžaduje zvláštní implementaci.
75
JD Edwards EnterpriseOne může být k dispozici jak klasická on-premise instalace s licencí, nebo
ve formě SaaS, kterou nabízí lokální dodavatel. Je zde i třetí varianta, takzvaný private cloud.
5.3 Ceny a podmínky variant
Roční maintenance při koupi licence Oracle se platí 22 procent z pořizovací ceny licence. Délka
poskytování smlouvy pro variantu SaaS je minimálně 36 měsíců. Tato doba je nařízena přímo
společností Oracle.
5.3.1
Varianta 1 – Software as a Service
Úvodní investice:
•
Přednastavené řešení Accelerate
400 000 Kč
•
Nastavení výroby
100 000 Kč
Pravidelné poplatky:
Měsíční poplatek za SaaS (za uživatele)
•
•
•
•
•
•
•
•
2 900 Kč
Licence Oracle JD Edwards
Licence Accelerate
Licence Maintenance
Hardware a jeho údržba
Operační systém a jeho podpora
Zálohování
Servisní podpora
Legislativní podpora
Měsíční poplatek za SaaS (za uživatele) je kalkulovaný pro 35 uživatelů. V případě jiného počtu
uživatelů se může lišit. V poplatku jsou v něm zahrnuty prakticky všechny náklady se systémem.
Zákazník už v dalších letech nemá žádné nepředvídatelné náklady. Rychlost implementace je o cca
1-1,5 měsíce kratší, protože se nemusí čekat na dodávku hardware a práce s ním spojené.
Maintenance licencí Oracle je pro variantu licencování SaaS již zahrnutý v měsíčním poplatku
za uživatele.
5.3.2
Varianta 2 – Private cloud
Prakticky standardní implementace, kdy zákazník zakoupí vše na začátku, ale servery pro chod
systému si pronajímá měsíčně.
Úvodní investice
•
Licence Oracle JD Edwards
1 200 000 Kč
•
Licence Technologie
145 000 Kč
76
•
Přednastavené řešení Accelerate
1 500 000 Kč
•
Nastavení výroby
500 000 Kč
Pravidelné poplatky
•
Pronájem hardware měsíčně (servery, OS, zálohování)
26 000 Kč
•
Servisní podpora měsíčně
32 000 Kč
•
Roční maintenance Oracle licence – 22 % z ceny licencí
264000 Kč
5.3.3
Varianta 3 – On-Premise
Prakticky standardní implementace, kdy zákazník zakoupí vše na začátku, včetně hardware pro chod
systému a musí se sám za své náklady o vše starat. Má tedy náklady na lidské zdroje, údržbu systémů,
elektrickou energii, zálohování,…)
Úvodní investice
•
Licence Oracle JD Edwards
1 200 000 Kč
•
Licence Technologie
145 000 Kč
•
Přednastavené řešení Accelerate
1 500 000 Kč
•
Nastavení výroby
500 000 Kč
•
Hardware, OS, zálohování pro ERP
800 000 Kč
Pravidelné poplatky
•
Servisní podpora měsíčně
32 000 Kč
•
Roční maintenance Oracle licence – 22 % z ceny licencí
264 000 Kč
•
Roční mzda 1 IT specialisty na údržbu serveru a software
900 000 Kč
•
Infrastruktura (elektřina, chlazení, atd.) ročně
72 000 Kč
5.4 Výpočet ROI
Pro výpočet návratnosti investice byly rozděleny obchodní přínosy a úspory na IT. Obchodní přínosy a
úspory, které podniku nasazení ERP přinese, jsou pro všechny varianty stejné. Liší se hlavně
v počátečních investicích a provozních nákladech. Právě tyto rozdíly je třeba identifikovat a počítat
s nimi. Příklad je zjednodušen pro názornost a nezahrnuje všechny možné tvrdé a měkké metriky,
které by se daly v ROI zvážit při velmi detailní analýze a znalosti podniku. Období je počítáno
na 3 roky, aby se stihly projevit přínosy ERP a také kvůli 36 měsícům u SaaS smlouvy. Druhý výpočet
je na 5 let, což představuje dobu, na kterou se tyto systémy běžně nakupují.
77
Business přínosy a úspory
1. rok – zvýšení produkce o 5 % oproti výchozímu stavu a snížení skladových zásob o 10 %
na 45 milionů Kč
Obrat firmy je 300 milionů Kč a produkce se zavedením ERP zvýší o 5 %. Předpokládá se odbyt
produktů. Z 15 milionů obratu navíc firma získá při 20% marži zisk 3 miliony Kč.
Snížení skladových zásob o 5 milionů umožní zhodnotit tyto peníze jinak. Lze počítat s úsporou 15 %
z této částky, což je uspořených 750 tisíc Kč.
2. rok – snížení skladových zásob o 20 % oproti původnímu stavu, což je snížení
na 40 milionů Kč
Obrat se zvýší o 10 %, což znamená zisk 6 milionů Kč. Na skladových zásobách se ušetří
1,5 milionu Kč.
3. rok – ERE přináší stejné benefity jako v druhém roce. Na skladových zásobách je ušetřeno
1,5 milionu a zisk 6 miliónů Kč.
Celkem za 3 roky nasazení ERP firmě přinese, respektive uspoří 18,75 milionu Kč.
IT úspory
Zde se počítají rozdíly mezi variantami. Výchozí varianta je 5.3.3 On-Premise, vůči které se šetří
hlavně na lidských zdrojích.
Úspory varianty Private cloud:
•
snížení počtu IT specialistů na 1 = 900 tisíc Kč ročně
•
úspory za infrastrukturu (elektřina, chlazení, rack) = 72 tisíc Kč ročně
Celkem za 3 roky je úspora oproti On-Premise 2,916 mil. Kč
Úspory varianty SaaS:
•
snížení počtu IT specialistů na 1 = 900 tisíc Kč ročně
•
úspory za infrastrukturu (elektřina, chlazení, rack) = 72 tisíc Kč ročně
Celkem za 3 roky je úspora oproti On-Premise 2,916 mil. Kč
Samotný výpočet
Příklad výpočtu ROI na 3 roky v tisících Kč.
ROI$%!"# ří
&é''í á
&é''í
100%
á
&é''í
78
.
ROI(")*
+,!-+
18750 8741
114,51%
8741
U on-premise je návratnost po 3 letech 114,51 %, což znamená, že se investice navrátily a ERP firmě
přináší zisk.
ROI*.
!#+45$67
82916 < 18750= 5961
263,46%
5961
ROI private cloudu je 263,46 %, což znamená, že investice je již splacena a generuje více než
dvojnásobný zisk, než varianta on-premise.
.
ROI??
82916 < 18750= 4154
421,57%
4154
SaaS varianta dosahuje zdaleka nejlepšího výsledku 421,57 %. Investované náklady se vrací již během
prvního roku. Z grafu 1 je patrné, že nejlepší ROI mají varianty SaaS a private cloud. SaaS varianta
dosahuje více jak 100 % a tedy návratu investice v prvním roce, varianta private cloud ve druhém.
ROI pro další roky je patrné z grafu 1.
ROI jednotlivých variant
4,858877086
500%
4,610201042
4,215695715
3,899124477
400%
3,49386921
300%
3,354573039
2,634625063
ROI
SaaS
200%
1,816960187
1,74854482 1,638272346
1,533539234
On-Premise
1,145063494
100%
Private Cloud
0,579834293
0,168522643
0%
Rok 0
-0,318305763
Rok 1
Rok 2
Rok 3
Rok 4
Rok 5
-100%
Graf 1 -ROI jednotlivých variant
79
5.5 Výpočet TCO
Celkové náklady na vlastnictví se počítají součtem všech přímých a nepřímých nákladů na pořízení a
provoz ERP systému. Podrobně jsou sepsány pro jednotlivé roky v Příloha 1 – TCO jednotlivých
variant nasazení ERP JD Edwards EnterpriseOne pro 35 uživatelů.
TCO po 3 letech
TCO.?? 4154000KčTCO.*
!#+45$67
5961000KčTCO.(")*
+,!-+
8741000Kč
7881000KčTCOD(")*
+,!-+
11981000Kč
TCO po 5 letech
TCOD?? 6590000KčTCOD*
!#+45$67
TCO vychází logicky nejlépe pro SaaS variantu. Přestože se zdá, že se v budoucnu křivka SaaS protne
(viz graf 3) s náklady na private cloud, tak tomu tak nebude. Musí se počítat s náklady na softwarový
upgrade systému cca po 5 letech. U on-premise bude nutná i obměna hardware, která se v grafu TCO
projeví taktéž skokem nahoru. SaaS bude díky pravidelným poplatkům, které zahrnují vše, stále
lineární Náklady za jednotlivé roky ukazuje graf 2.
TCO variant ERP za jednotlivé roky
6000000
5000000
Náklady v Kč
4000000
SaaS
3000000
Private Cloud
On-Premise
2000000
1000000
0
Rok 1
Rok 2
Rok 3
Rok 4
Rok 5
Graf 2 - TCO variant ERP za jednotlivé roky
80
TCO variant ERP - kumulativní
14000000
12000000
Náklady v Kč
10000000
8000000
SaaS
Private Cloud
6000000
On-Premise
4000000
2000000
0
Rok 1
Rok 2
Rok 3
Rok 4
Rok 5
Graf 3 - TCO variant ERP – kumulativní
Příloha 2 zobrazuje předcházející grafy v jednom, pro lepší názornost nákladů jednotlivých variant.
5.6 Požadavky firmy na systém a její specifika
Specifika dané firmy
Standardní kritéria
Tabulka 8 - Požadavky firmy na ERP systém a její specifika
Požadavky na:
Dostupnost aplikace
Okamžitá odezva (real time aplikace)
Možnosti customizace
Mobilita
Bezpečnost
Flexibilní licencování
Škálovatelnost hardware
Výkon
Důležitost pro zákazníka
Rychlost implementace
Silně specifické prostředí
Závislost firmy na IT
Nároky na integraci
Vlastní hardware
Vlastní kapitál pro začátek
Dostupná konektivita
81
Firma preferuje vysokou dostupnost aplikace a díky kvalitní konektivitě ji SaaS varianta splní nejlépe.
Může těžit i z rychlosti implementace, která se také podepíše na lepším ROI. Firma nemá zvláštní
požadavky na mobilitu. Problematickým bodem by mohla být odezva systému. Ideální je tedy nejprve
systém otestovat, zdali budou reakce dostatečné. To samé platí u možností customizace. Nároky na
integraci má nízké, takže se také nemusí bát, že by ji SaaS ERP nestačilo. Firma vlastní starší
hardware a on-premise řešení by znamenalo pro ni jasnou investici.
5.7 Doporučení vhodné varianty a upozornění na vzniklé souvislosti
Dle teoretických předpokladů vychází varianta SaaS nejlépe a splňuje víceméně potřeby vyplněné
v tabulce. Varianta má také nejvyšší ROI a zároveň nejnižší TCO ze všech. Je tedy finančně
nejdostupnější a investice se vrátí již během prvního roku. Firma nemá problémy s počátečním
kapitálem, ale může ho díky SaaS využít na jinou oblast. Určitým omezením této varianty by mohlo
být v nutnosti podepsat smlouvu na 36 měsíců. U ERP systémů se ale nepředpokládá žádná dřívější
změna, takže to není negativum. Naopak má firma stanovený měsíční poplatek za uživatele a nemusí
se bát jeho navýšení. Firma zvolením SaaS ušetří značné náklady za jednoho IT pracovníka, ale zase
musí ošetřit rizika jeho nemoci a zastoupení v době dovolené. Externí pracovníci stojí zhruba
dvojnásobek.
Ani private cloud nevychází z finančního pohledu výrazně hůře a lze proto doporučit v případě potřeb
větších úprav systému na míru organizace, než nabízí první varianta. Firma také nemusí mít důvěru ve
sdílené prostředí SaaS. Varianta instalace systému on-premise vychází v TCO po pěti letech téměř
dvakrát dráž než SaaS a s přihlédnutím ke stejným přínosům, které přináší, ji není možné doporučit.
82
6 Závěr
V diplomové práci jsem definoval pojem computing a obsah všech jeho variant. Ačkoliv se na trhu
vyskytuje mnoho marketingových XaaS pojmů, mezi standardní stále patří jen IaaS, PaaS a SaaS,
v pořadí od základních fyzických zdrojů až po aplikační služby. Cloud computing se používá často
nesprávně pro jakékoliv hostované služby. Otázkou je, zdali je nutné splnit veškeré požadavky pro
toto označení, jaké jsou definované v druhé kapitole. Podle mého názoru nejsou třeba natolik striktní
podmínky, protože by se nabídka omezila na velmi úzké spektrum služeb. Nejlépe to splňují IaaS
poskytovatelé, kteří mají vše automatizované a tedy i samoobslužné. Za hlavní charakteristiky
veřejného cloudu, které by měly být splněny vždy, považuji sdílené flexibilní prostředí, měřitelnost a
všudypřítomnou dostupnost. Skutečnost, že například změnu velikosti datového úložiště musí potvrdit
zaměstnanec poskytovatele, nic nemění na kvalitě služeb a nemožnosti využívat názvu cloud
computing. Poskytovatelé cloud služeb by vždy měli mít zajištěnu odpovídající infrastrukturu, která je
jednak schopna dodržet alespoň 99,9% dostupnost a hlavně odpovídající zálohování zákaznických dat.
Spolu se splněním ISO norem, bezpečnostních standardů a sepsáním SLA a NDA smluv již
nepovažuji jakékoliv obavy o bezpečnost dat za opodstatněné. Přínosem práce je vždy dvojí pohled na
problematiku, který může pomoci jak zákazníkům, tak i začínajícím poskytovatelům služeb. Výhody a
příležitosti značně převyšují negativní stránky spolu s hrozbami, což znamená, že podíl XaaS služeb
na trhu bude stále růst. Druhou kapitolou tedy podávám kompletní přehled o cloud computingu
z pohledu zákazníka i poskytovatele a naplňuji tento cíl. V rámci této kapitoly jsem vyčlenil i
nejvhodnější aplikace pro provoz v cloudu.
V třetí kapitole jsem zúžil obecný pohled na cloud computing se zaměřením na SaaS ERP a zohlednil
jeho výhody a nevýhody oproti on-premise řešení. ERP v cloudu se pomalu začíná rozmáhat, přestože
ho zatím využívá spíše menšina, a to firmy typu Tier III. S příchodem SaaS varianty produktu JD
Edwards EnterpriseOne, se mohou statistiky postupně měnit, jelikož se jedná o variantu zavedeného
řešení, které již má své zákazníky ve verzi on-premise. Bude to ale ještě nějakou dobu trvat, protože
největší organizace budou spoléhat na svá dosavadní robustní on-premise řešení a také by se musely
zbavovat svého hardware. Přináší to ovšem nesmírné možnosti pro začínající firmy, které mají na
výběr mnoho variant. ERP systémy jsou ve formě SaaS finančně mnohem dostupnější a také rychleji
implementované. Touto částí práce tedy splňuji cíl týkající se ERP v cloudu.
Ze zjištěných teoretických a praktických poznatků v předchozích kapitolách jsem navrhl vhodnou
analýzu podniku před přechodem do cloudu, stanovení požadavků a vhodný proces samotného
přechodu. Postupy, které jsem uvedl, mohou velmi pomoci firmám, které o cloud computingu uvažují.
Sestavil jsem též srovnávací tabulku vlastností, která názorně shrnuje předešlá zjištění a umožňuje
vidět rozdíly variant (SaaS, private cloud, on-premise) na první pohled. Ve čtvrté kapitole uvádím také
nákladovou tabulku jednotlivých variant, která výrazně napomáhá představě o budoucích nákladech,
83
usnadňuje rozhodování a také pomáhá při výpočtech ROI a TCO daného řešení. Metody pro
hodnocení investic poté prezentuji na příkladu z praxe a také doporučuji vhodnou variantu pro
konkrétní firmu. Pro úspěšné využívání služeb dále upozorňuji na potřebné parametry a rizika
smluvních ujednání a také objasnění, jak je to v praxi s možnostmi měření kvalit těchto služeb.
Všechny cíle práce tedy považuji za splněné. Výhodou práce je i doplnění a konfrontace teoretických
poznatků o zkušenosti z reálného světa poskytování IT služeb.
84
7 Seznam literatury
1. Gartner, Inc. Hype Cycle for Cloud Computing, 2011. [Online] 27. červenec 2011. G00214915.
2. Feuerlicht, George, Burkon, Lukáš a Šebesta, Michal. Cloud Computing Adoption: What are the
Issues. [Online] 2011. [Citace: 13. březen 2012.] http://www.cssi.cz/cssi/system/files/all/si-2011-02p16-Feuerlicht-Burkon-Sebesta.pdf.
3. CIO Business World. Google: čeští podnikatelé nevědí, co je cloud. CIO Business World. [Online]
1. prosinec 2011. [Citace: 17. leden 2012.]
http://businessworld.cz/temata?id=2&article=on&article_id=8309&cat=&q=Cloud%20computing&si
d=google-cesti-podnikatele-nevedi-co-je-cloud.
4. Brousell, Lauren. CIOs are putting the cloud first. CIO.com. [Online] 14. červen 2011. [Citace: 22.
únor 2012.] http://www.cio.com/article/684338/Survey_CIOs_Are_Putting_the_Cloud_First.
5. Voříšek, J., Pavelka, J. a Vít, M. Aplikační služby IS/ICT formou ASP - Proč a jak pronajímat
informatické služby. Praha : Grada Publishing, 2004. ISBN: 80-247-0620-2.
6. Voříšek, Jiří. Principy a modely řízení podnikové informatiky. Praha : Oeconomica, 2008, 2008.
str. 446. ISBN: 978-80-245-1440-6.
7. Polanský, O. a Voříšek, J. SaaS model dodávky aplikací a z něho vyplývající transformace IT
průmyslu. [Online] 2008. [Citace: 6. únor 2012.]
http://nb.vse.cz/~vorisek/FILES/Clanky/2008_PolanskyVorisek_SaaS_a_transformace_IT_prumyslu.pdf.
8. Mell, Peter a Grance, Timothy. The NIST Definition of Cloud Computing. [Online] říjen 2011.
[Citace: 27. listopad 2011.] http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf.
9. Badger, Lee, a další. DRAFT Cloud Computing Synopsis and Recommendations. [Online] květen
2011. [Citace: 28. prosinec 2011.] http://csrc.nist.gov/publications/drafts/800-146/Draft-NIST-SP800146.pdf.
10. Gartner, Inc. Hype Cycle for ERP, 2011. [Online] 27. červenec 2011.
http://www.gartner.com/id=1753514. G00214665.
11. Chong, Frederick, Carraro, Gianpaolo. Software as a Service (SaaS): An Enterprise
Perspective. [Online] září 2010. [Citace: 6. leden 2012.] http://msdn.microsoft.com/enus/library/aa905332.aspx.
12. Mahyndra Satyam. Cloud Computing – Still a Long Way to Go. [Online] 16. prosinec 2009.
[Citace: 4. prosinec 2011.]
http://www.mahindrasatyam.com/corporate/documents/Cloud_Computing.pdf.
13. TechTarget. SearchCloudComputing Definiton: Cloud computing. TechTarget. [Online] prosinec
2007. [Citace: 19. únor 2012.] http://searchcloudcomputing.techtarget.com/definition/cloudcomputing.
14. Wikipedia. Cloud computing. Wikipedia. [Online] 18. únor 2012. [Citace: 19. únor 2012.]
http://en.wikipedia.org/wiki/Cloud_computing.
15. ManagementMania. Cloud Computing. [Online] 2011. [Citace: 12. prosinec 2011.]
http://managementmania.com/cloud-computing.
16. Forrester, Inc. The Evolution Of Cloud Computing Markets. [Online] 6. červenec 2010. [Citace:
8. prosinec 2011.] http://fm.sap.com/data/UPLOAD/files/Forrester%20%20The%20Evolution%20Of%20Cloud%20Computing%20Markets.pdf.
85
17. The Distributed Management Task Force. Cloud Management. dmtf.org. [Online] 2011.
[Citace: 13. prosinec 2011.] http://dmtf.org/standards/cloud.
18. Hogan, M. D., a další. NIST-SP 500-291, NIST Cloud Computing Standards Roadmap. NIST.
[Online] 10. srpen 2011. [Citace: 4. březen 2012.]
http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909024.
19. TechTarget. TechTarget SeachDatacenter Definition: Workload. [Online] 2004. [Citace: 18.
prosinec 2011.] http://searchdatacenter.techtarget.com/definition/workload.
20. Chong, Frederick, Carraro, Gianpaolo. Architecture Strategies for Catching the Long Tail.
[Online] duben 2006. [Citace: 4. leden 2012.] http://msdn.microsoft.com/en-us/library/aa479069.aspx.
21. Creese, Guy. SaaS vs. Software: The Pros and Cons of SaaS Pricing. Gartner. [Online] 2010.
květen 24. [Citace: 19. prosinec 2011.] http://blogs.gartner.com/guy-creese/2010/05/24/saas-vssoftware-the-pros-and-cons-of-saas-pricing/.
22. Online Tech Inc. Top 5 reasons why your company should transition to private cloud computing.
ONLINE TECH. [Online] 2012. [Citace: 6. listopad 2011.] http://www.onlinetech.com/resources/etips/cloud-computing/top-5-reasons-why-your-company-should-transition-to-private-cloudcomputing.
23. Baez, Ramon. Workday - Kimberly Clark case study [video]. [Online] 9. leden 2012. [Citace: 3.
březen 2012.] https://workdaymarketing.box.com/s/t21t355riu0k5n1pq2zl.
24. CIO Business World. Do roku 2015 vzroste přenos dat v cloudu 12krát. CIO Business World.
[Online] 2. prosinec 2011. [Citace: 17. leden 2012.]
http://businessworld.cz/temata?id=2&article=on&article_id=8306&cat=&q=Cloud%20computing&si
d=do-roku-2015-vzroste-prenos-dat-v-cloudu-12krat.
25. Scheier, Robert L. The cloud security checklist. Computerworld.com. [Online] 29. listopad 2011.
[Citace: 21. leden 2012.]
http://www.computerworld.com/s/article/358151/The_cloud_security_checklist.
26. Matějů, David. Role bezpečnosti v důvěryhodném cloudu. Cloud.cz. [Online] 2011. [Citace: 12.
prosinec 2011.] http://www.cloud.cz/bezpenost/175-role-bezpecnosti-v-duveryhodnem-cloudu.html].
27. Microsoft. Zabezpečení, audity a certifikace. [Online] 2011. [Citace: 31. březen 2012.]
http://www.microsoft.com/online/legal/v2/cs-cz/MOS_PTC_Security_Audit.htm.
28. Hamřík, Antonín a Stránský, Michal. Auditorská rizika a postupy vyplývající z využití ICT v
účetnictví. pwc.cz. [Online] 4. červen 2008. [Citace: 31. březen 2012.]
http://www.pwc.com/cz/cs/clanky-2008/auditorska-rizika-a-postupy-vyplyvajici-z-vyuziti-ict-vucetnictvi.jhtml.
29. Staten, James. Scoring Forrester's 2011 cloud predictions. zdnet.com. [Online] 14. listopad 2011.
[Citace: 27. prosinec 2011.] http://www.zdnet.com/blog/forrester/scoring-forresters-2011-cloudpredictions/774.
30. ERPsoftware360.com. ERP Software as a Service Benefits. ERPsoftware360.com. [Online] 2012.
[Citace: 17. duben 2012.] http://www.erpsoftware360.com/software-as-a-service.htm.
31. Proact. Havárie vyřadí polovinu firem z provozu na několik dní. emag.cz. [Online] 30. listopad
2011. [Citace: 13. březen 2012.] http://www.emag.cz/havarie-vyradi-polovinu-firem-z-provozu-nanekolik-dni/.
86
32. Greenberg, Paul. CRM Watchlist 2012 Winners Pt 1A - The Big Guns. ZDNet. [Online] 3. leden
2012. [Citace: 10. leden 2012.] http://www.zdnet.com/blog/crm/crm-watchlist-2012-winners-pt-1athe-big-guns/3835?tag=mantle_skin;content.
33. Amazon Web Services LLC. Amazon Simple Storage Service (Amazon S3). Amazon Web
Services. [Online] 2012. [Citace: 6. duben 2012.] http://aws.amazon.com/s3/.
34. Novák, Jiří. Cloud computing: Vyhněte se závislosti na dodavateli. ICT manažer. [Online] 14.
leden 2012. [Citace: 20. leden 2012.] http://www.ictmanazer.cz/2012/01/cloud-computing-vyhnete-sezavislosti-na-dodavateli/.
35. salesforce.com. Chatter. salesforce.com. [Online] 2012. [Citace: 17. únor 2012.]
http://www.salesforce.com/chatter/overview/.
36. Rafter, Edward P. The Data Center Tier Performance Standards and Their. Tierivgroup.com.
[Online] 4. květen 2007. [Citace: 22. leden 2012.]
http://www.tierivgroup.com/resources/papers/TierIVwp010.pdf .
37. Přibyl, Jaroslav. Základní parametry tříd serveroven a datových center TIER. [Online] 1. únor
2008. [Citace: 22. leden 2012.] http://www.i-development.cz/TIER.pdf.
38. netguru.cz. Slovníček k tématu Novinky v datových centrech. netguru.cz. [Online] 2010. [Citace:
22. leden 2012.] http://www.netguru.cz/11012-novinky-v-oblasti-datovych-center/slovniek-k-tematunovinky-dc-standardy-tier.html .
39. Wikipedie . Dostupnost. Wikipedie. [Online] leden 2012. [Citace: 22. leden 2012.]
http://cs.wikipedia.org/wiki/Dostupnost.
40. Havránek, Robert. Cloud pro pokročilé 3: Kdy je lepší použít cloud? Computerworld. [Online]
14. listopad 2011. [Citace: 2. prosinec 2011.] http://computerworld.cz/novinky-microsoftu/cloud-propokrocile-3-kdy-je-lepsi-pouzit-cloud-44121.
41. ERP and More! ERP Tiers: What Tier are you in? www.erpandmore.com. [Online] 28. říjen
2005. [Citace: 8. duben 2012.] http://www.erpandmore.com/2005/10/28/erp-what-tier-are-you-in/.
42. Sandeep, Walia. Finding the Best ERP and Accounting System for your Business. Ignify - ERP,
CRM and eCommerce blog. [Online] 3. leden 2011. [Citace: 26. únor 2012.]
http://blog.ignify.com/tag/gartner-erp-magic-quadrant/.
43. Gartner, Inc. Gartner Magic Quadrant for ERP, 2010. [Online] 17. 12 2010.
http://www.epicor.com/MRCDocumentLibrary/Gartner-Magic-Quadrant-2010-Ens.pdf.
44. Howlett, Dennis. Gartner's conservative mid-tier ERP Magic Quadrant. ZDNet. [Online] 11.
červen 2009. [Citace: 26. 2 2012.] http://www.zdnet.com/blog/howlett/gartners-conservative-mid-tiererp-magic-quadrant/985 .
45. Wikipedia. Microsoft Dynamics NAV. Wikipedia. [Online] 26. prosinec 2011. [Citace: 26. únor
2012.] http://cs.wikipedia.org/wiki/Microsoft_Dynamics_NAV.
46. Fenn, Jackie a Raskino, Mark. Understanding Gartner's Hype Cycles, 2011. [Online] 19.
červenec 2011. [Citace: 24. únor 2012.] http://www.gartner.com/id=1748018.
47. Natys, Yefim. Platform as a Service (Video). [Online] 2011. [Citace: 28. listopad 2011.]
http://www.gartner.com/technology/research/cloud-computing/report/paas-cloud.jsp.
48. ERPFacts.com. Benefits of ERP Software-as-a-Service (SaaS). ERPFacts.com. [Online] 2012.
[Citace: 15. leden 2012.] http://www.erpfacts.com/benefits-of-erp-saas.htm.
87
49. Panorama Consulting Solutions. 2012 ERP Report. [Online] 31. leden 2012. [Citace: 2. březen
2012.] http://panorama-consulting.com/resource-center/2012-erp-report/.
50. Panorama Consulting Group, SearchManufacturingERP.com Expert Contributors. SaaS
ERP vs. on-premise ERP software: Six key differentiators. SearchManufacturingERP.com. [Online]
12. březen 2009. [Citace: 10. prosinec 2011.]
http://searchmanufacturingerp.techtarget.com/news/1350684/SaaS-ERP-vs-on-premise-ERP-softwareSix-key-differentiators.
51. online-crm.com. The Realities of CRM SaaS - Advantages and Disadvantages. online-crm.com.
[Online] 2011. [Citace: 12. prosinec 2011.] http://www.onlinecrm.com/saas_advantages_disadvantages.htm.
52. Kepes, Ben. And Who Said SaaS Wasn’t Customizable? – NetSuite Rewrites the Rules and
Embraces Design Thinking in the process. Cloudave. [Online] 7. Duben 2010. [Citace: 10. březen
2012.] http://www.cloudave.com/550/and-who-said-saas-wasn-t-customizable-netsuite-rewrites-therules-and-embraces-design-thinking-in-the-process/.
53. NetSuite. The 8 ways outdated ERP damages your business. [Online] 2011. [Citace: 14. leden
2012.] http://www.netsuite.com/portal/pdf/wp-version-lock-erp.pdf .
54. Burian, Vojtěch. ERP systémy jako služba. erpforum.cz. [Online] 1. duben 2010. [Citace: 18.
duben 2012.] http://www.erpforum.cz/erp-trendy-28.html.
55. Wikipedia. Application Portfolio Management. [Online] 2012. [Citace: 13. únor 2012.]
http://en.wikipedia.org/wiki/Application_Portfolio_Management#Return_on_Investment.
56. Učeň, Pavel. Metriky jako nástroj řízení efektivity IS/IT. [Online] 2001. [Citace: 16. duben 2012.]
http://si.vse.cz/archive/proceedings/2001/metriky-jako-nastroj-rizeni-efektivity-is-it.pdf.
57. Herbert, L. a Erickson, J. The ROI Of Software-As-A-Service. [Online] 13. červenec 2009.
[Citace: 7. březen 2012.] http://www.workday.com/Documents/pdf/whitepapers/hr/workday-roi-ofsoftware-as-a-service-forrester-report.pdf.
58. truecloud.com. NetSuite - Total Cost of Ownership. truecloud.com. [Online] 2012. [Citace: 8.
duben 2012.] http://truecloud.dreamhosters.com/stub/calculator.
59. Schmidt, Marty J. Total Cost of Ownership (TCO). [Online] 15. únor 2011. [Citace: 20. březen
2012.] http://www.solutionmatrix.com/total-cost-of-ownership.html.
60. Švík, Martin. ROI, TCO a NPV: Svatá trojice. CIO Business World. [Online] 25. listopad 2009.
[Citace: 3. duben 2012.] http://businessworld.cz/it-strategie/roi-tco-a-npv-svata-trojice-5303.
61. Kimberling, Eric. Is SaaS ERP right for your organization. Panorama Consulting Solutions.
[Online] 20. červenec 2011. [Citace: 12. duben 2012.] http://panorama-consulting.com/is-saas-erpright-for-your-organization/.
62. Phillips, Steve. IT Challenge: Switching from in-house to SaaS ERP. TechTarget.com. [Online]
2011. [Citace: 4. únor 2012.] http://searchmanufacturingerp.techtarget.com/IT-Challenge-Switchingfrom-in-house-to-SaaS-ERP.
63. Staton, James. Another reason not to cloud wash - real cloud services are maturing fast.
ZDNet.com. [Online] 22. listopad 2011. [Citace: 12. leden 2012.]
http://www.zdnet.com/blog/forrester/another-reason-not-to-cloud-wash-real-cloud-services-arematuring-fast/780.
64. Jansa, Lukáš. Dohoda o mlčenlivosti v IT (NDA – non disclosure agreement, CA - confidentiality
agreement). pravoit.cz. [Online] 1. listopad 2009. [Citace: 1. duben 2012.]
88
http://www.pravoit.cz/article/dohoda-o-mlcenlivosti-v-it-nda-non-disclosure-agreement-caconfidentiality-agreement.
65. Druker, Daniel. Cloud / SaaS Service Level Agreement Redux. View from the cloud: The Intacct
blog! [Online] 26. červen 2009. [Citace: 31. březen 2012.] http://blog.intacct.com/2009/06/cloud-saasservice-level-agreement.html.
66. totalservice.cz. SLA smlouva. totalservice.cz. [Online] 2012. [Citace: 2. duben 2012.]
http://www.totalservice.cz/cesky/sluzby-a-reseni/ICT-Outsourcing/service-level.html.
67. Otevřel, Petr. Obchodní smlouvy v IT - 3. díl. pravoit.cz. [Online] 15. březen 2007. [Citace: 30.
březen 2012.] http://www.pravoit.cz/article/obchodni-smlouvy-v-it-3-dil.
68. —. Několik postřehů ze sjednávání smlouvy o IaaS. pravoit.cz. [Online] 28. březen 2012. [Citace:
30. březen 2012.] http://www.pravoit.cz/article/nekolik-postrehu-ze-sjednavani-smlouvy-o-iaas.
69. Cloud Harmony Blog. Do SLAs really matter? A 1 year case study of 38 cloud services .
blog.cloudharmony.com. [Online] 15. leden 2011. [Citace: 18. duben 2012.]
http://blog.cloudharmony.com/2011/01/do-slas-really-matter-1-year-case-study.html.
70. Otevřel, Petr. Vybrané právní aspekty SLA. systemonline.cz. [Online] 2009. [Citace: 21. duben
2012.]
71. online-crm.com. The Promise and Pitfalls of Service Level Agreements. online-crm.com. [Online]
[Citace: 9. duben 2012.] http://www.online-crm.com/sla.htm.
72. Ryba, Albert. Gartner: Nejčastější chyby smluv na cloudové služby. ictmanazer.cz. [Online] 4.
září 2011. [Citace: 17. únor 2012.] http://www.ictmanazer.cz/2011/10/gartner-nejcastejsi-chybysmluv-na-cloudove-sluzby/.
73. Nikaido, Brielle. What should be included in a cloud exit strategy? Do all organizations need one?
focus.com. [Online] červen 2011. [Citace: 19. duben 2012.] http://www.focus.com/questions/what-allshould-be-included-cloud-exit-strategy-do-all-need/.
74. Jansa, Lukáš. Migrační smlouva v rámci přechodu na Cloud Computing. pravovit.cz. [Online] 28.
březen 2012. [Citace: 30. duben 2012.] http://www.pravoit.cz/article/migracni-smlouva-v-ramciprechodu-na-cloud-computing.
89
8 Seznam obrázků, tabulek a grafů
Obrázek 1 - NIST Example Services Available to a Cloud Consumer [zdroj: NIST] .......................... 14
Obrázek 2 - NIST Cloud Provider –Service Orchestration [zdroj: NIST] ............................................ 16
Obrázek 3 - Schopnost firem obnovit data po havárii [zdroj: Proact, 2011] ......................................... 26
Obrázek 4 - Typ ERP v roce 2011 dle modelu zavedení [zdroj: Panorama Consulting Solutions] ...... 38
Obrázek 5 - Tržní podíl dodavatelů ERP [zdroj: Panorama Consulting Solutions, 2011] .................... 40
Obrázek 6 - Gartner Magic Quadrant for ERP 2009 zdroj: [43] ........................................................... 41
Obrázek 7 - Gartner Magic Quadrant for ERP 2010 zdroj: [41] ........................................................... 42
Obrázek 8 - Hype Cycle for ERP, 2011 zdroj: [10] .............................................................................. 44
Obrázek 9 - Hype Cycle for ERP, 2010 zdroj: [10] .............................................................................. 45
Obrázek 10 - Dodržení plánované doby projektu [zdroj: Panorama Consulting Solutions] ................. 46
Tabulka 1 - SWOT analýza - cloud computing z pohledu zákazníka ................................................... 30
Tabulka 2 - SWOT analýza - cloud computing z pohledu poskytovatele ............................................. 35
Tabulka 3 - SWOT analýza - SaaS ERP z pohledu zákazníka .............................................................. 51
Tabulka 4 - SWOT analýza - SaaS ERP z pohledu zákazníka .............................................................. 53
Tabulka 5 - Seznam nákladů ERP řešení .............................................................................................. 59
Tabulka 6 - Hodnotící tabulka kritérií pro ERP řešení .......................................................................... 63
Tabulka 7 - Parametry daných variant ERP řešení................................................................................ 63
Tabulka 8 - Požadavky firmy na ERP systém a její specifika............................................................... 81
Graf 1 -ROI jednotlivých variant .......................................................................................................... 79
Graf 2 - TCO variant ERP za jednotlivé roky ....................................................................................... 80
Graf 3 - TCO variant ERP – kumulativní ............................................................................................. 81
90
9
Terminologický slovník
Termín
Application
Programming interface
Application Service
Providing
Zkratka Význam [zdroj]
Business to Business
B2B
Capital Expenditures
Central Processing Unit
Customer Relationship
Management
CAPEX
CPU
Využívá se pro označení systémů, které slouží firmám a ne koncovým
zákazníkům [autor]
Kapitálové výdaje [autor]
Procesor, resp. centrální výpočetní jednotka [autor]
CRM
Řízení vztahu se zákazníky [autor]
Data Residency Option
DRO
Days Sales Outstanding
DSO
Enterprise Resource
Planning
Fair Usage Policy
Chief Financial Officer
Chief Information
Officer
Information rights
Management
Infrastructure as a
Service
Internet Message Access
Protocol
National Institute of
Standards and
Technology
Non Disclosure
Agreement
Operational
Expenditures
Platform as a Service
Return on Investment
Secure Socket Layer
Service Level Agreement
Single Sign-On
Software as a Service
API
Aplikační rozhraní pro komunikaci a volání procedur aplikace [autor]
ASP
Poskytovatel aplikačních služeb. Předchůdce cloud computingu [autor]
ERP
Systém pro řízení podnikových zdrojů [autor]
FUP
CFO
Politika limitů pro zajištění spravedlivého využití služby [autor]
Finanční ředitel [autor]
CIO
IT ředitel [autor]
IRM
Systém pro řízení přístupových práv k souborům [autor]
IaaS
Infrastruktura jako služba [autor]
IMAP
Internetový protokol pro vzdálený přístup k e-mailové schránce
[http://cs.wikipedia.org/wiki/Internet_Message_Access_Protocol]
NIST
Národní institut pro standardy a technologii [autor]
NDA
Smlouva o mlčenlivosti [autor]
OPEX
Operační výdaje [autor]
PaaS
ROI
SSL
SLA
SSO
SaaS
Platforma jako služba [autor]
Návratnost investice. Finanční metodika hodnocení investic. [autor]
Protokol pro šifrování http přenosu [autor]
Služba o garantované úrovni poskytovaných služeb
Systém pro jednotné přihlašování do aplikací [autor]
Software jako služba. [autor]
Celkové náklady na vlastnictví. Finanční metodika hodnocení investic.
[autor]
Protokol pro šifrování http přenosu [autor]
Virtuální privátní síť (vytvoří zabezpečený tunel mezi dvěma PC nebo
sítěmi) [autor]
Total Cost of Ownership TCO
Transport Layer Security TLS
Virtual Private Network
Možnost výběru uložení dat v rámci datových center u SaaS
poskytovatele [salesforce.com]
Průměrná doba za kterou firmy získají peníze z pohledávek
[http://en.wikipedia.org/wiki/Days_sales_outstanding]
VPN
91
10 Přílohy
Příloha 1 – TCO jednotlivých variant nasazení ERP JD Edwards EnterpriseOne pro 35 uživatelů
Rok 1
Náklady v Kč bez DPH
Licenční poplatky (SaaS poplatky)
Implementace/Customizace
Servisní podpora
Hardware a údržba
Infrastruktura (elektřina,
chlazení)
Total Cost of Ownership
SaaS
Rok 2
Private
Cloud
On-Premise
SaaS
Total Cost of Ownership
Private
Cloud
On-Premise
SaaS
Private
Cloud
On-Premise
1218000
500000
0
0
1345000
2000000
384000
312000
1345000 1218000
2000000
0
384000
0
1700000
0
264000
0
384000
312000
264000 1218000
0
0
384000
0
900000
0
264000
0
384000
312000
264000
0
384000
900000
0
1718000
0
72000
0
5501000
1218000
0
72000
0
1620000
1218000
0
72000
1620000
4041000
Rok 4
Náklady v Kč bez DPH
Licenční poplatky (SaaS poplatky)
Implementace/Customizace
Servisní podpora
Hardware a údržba
Infrastruktura (elektřina,
chlazení)
Rok 3
SaaS
960000
Rok 5
Private
Cloud
On-Premise
SaaS
960000
Celkem za 5 let
Private
Cloud
On-Premise
SaaS
Private
Cloud
On-Premise
1218000
0
0
0
264000
0
384000
312000
264000 1218000
0
0
384000
0
900000
0
264000
0
384000
312000
264000 6090000
0 500000
384000
0
900000
0
2401000
2000000
1920000
2148000
2401000
2000000
1920000
5300000
0
1218000
0
72000
0
1620000
1218000
0
72000
0
1620000
6590000
0
360000
11981000
960000
960000
8469000
92
Příloha 2 - TCO variant ERP - sjednocený graf
TCO variant ERP - sjednocený graf
14000000
12000000
10000000
Náklady v Kč
SaaS
8000000
Private Cloud
On-Premise
SaaS kumulativní
6000000
Private Cloud kulumativní
On-Premise kumulativní
4000000
2000000
0
Rok 1
Rok 2
Rok 3
Rok 4
Rok 5
93
Příloha 3 – TCO Netsuite vs. Microsoft Dynamics a SalesForce.com [58]
Rok 1
NetSuite
Subscription Costs
$36,000
Support/Maintenance Costs $0
Implem./Custom. Costs
$54,000
Servers/Maintenance Costs $0
Other Infrastructure Costs
$12,500
User Support Costs
$0
User Training Costs
$3,750
Total Cost of Ownership
OnPremise
$88,500
$17,220
$162,750
$70,000
$19,688
$65,000
$3,750
$106,250 $426,908
Rok 5
Rok 2
NetSuite
$36,000
$0
$2,700
$0
$12,500
$0
$1,875
$53,075
OnPremise
$27,000
$17,220
$6,638
$7,000
$19,688
$65,000
$1,875
$144,420
Rok 6
Rok 3
NetSuite
$36,000
$0
$2,700
$0
$12,500
$0
$1,875
$53,075
OnPremise
$27,000
$17,220
$6,638
$7,000
$19,688
$65,000
$1,875
$144,420
Rok 7
Rok 4
NetSuite
$39,600
$0
$2,970
$0
$12,500
$0
$1,875
$56,945
OnPremise
$27,000
$17,220
$6,638
$7,000
$19,688
$65,000
$1,875
$144,420
Rok 8
Celkem
NetSuite
Subscription Costs
$39,600
Support/Maintenance Costs $0
Implem./Custom. Costs
$2,970
Servers/Maintenance Costs $0
Other Infrastructure Costs
$12,500
User Support Costs
$0
User Training Costs
$1,875
OnPremise
$27,000
$17,220
$6,638
$7,000
$19,688
$65,000
$1,875
NetSuite
$39,600
$0
$2,970
$0
$12,500
$0
$1,875
OnPremise
$27,000
$17,220
$6,638
$70,000
$19,688
$65,000
$1,875
NetSuite
$39,600
$0
$2,970
$0
$12,500
$0
$1,875
OnPremise
$27,000
$17,220
$6,638
$7,000
$19,688
$65,000
$1,875
NetSuite
$39,600
$0
$2,970
$0
$12,500
$0
$1,875
OnPremise
$27,000
$17,220
$6,638
$7,000
$19,688
$65,000
$1,875
NetSuite
$306,000
$0
$74,250
$0
$100,000
$0
$16,875
OnPremise
$277,500
$137,760
$209,212
$182,000
$157,500
$520,000
$16,875
Total Cost of Ownership
$144,420
$56,945
$207,420
$56,945
$144,420
$56,945
$144,420
$497,125
$1,500,848
$56,945
94
Příloha 4 – Grafy k TCO Netsuite vs. Microsoft Dynamics a SalesForce.com [58]
95