Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Katedra informačních technologií
Student : Ondřej Smolík
Vedoucí bakalářské práce : Ing. Tomáš Žídek Recenzent bakalářské práce : Ing. Jakub Hejtmánek
TÉMA BAKALÁŘSKÉ PRÁCE
ASP (Application Service Providing) - význam tohoto modelu distribuce aplikací pro malé a střední podnikání v
ČR
ROK : 2006
Prohlášení
Prohlašuji, že jsem bakalá skou práci zpracoval samostatn a že jsem uvedl všechny použité pramenyř ě a literaturu, ze kterých jsem erpal.č
V Praze dne 27.08.2006 ...
podpis
Abstrakt
Tato práce se zabývá poskytováním aplikačních služeb v prostředí malých a středních firem (SME – Small and Medium Enterprises). Model ASP pochází z 90. let dvacátého století, takže je ještě celkem mladý, přesto však prošel už velkým vývojem. Jeho využití by mělo být výhodné hlavně pro malé a střední firmy, které nemají dostatek finančních zdrojů, aby mohly investovat do hardware a software. V práci jsou uvedeny klady a zápory tohoto modelu. Je zde uveden příklad vládní podpory poskytování aplikačních služeb pro SME v Koreji.
Seznámení s možnostmi jak ASP aplikace integrovat pomocí standardů založených na XML a webových službách
Abstract
This work deals with Application Service Providing in the specific environment of small and medium enterprises (SMEs). ASP model was developed in the 1990s, so it is quite young, despite that it came through great devlopment. It’s usage should be profitable especially for small and medium enterprises, which lacks of financial resources for inveting into hardware and software. In this work are discussed pros and cons. The example of promoting ASP for SME in Korea is issued here too. And the possibility of ASP integration based on Web services.
1 Úvod ... 2
2 Úvod do problematiky ASP ... 4
2.1 Outsourcing ... 4
2.1.1 Co si můžeme představit pod pojmem outsourcing? ... 4
2.1.2 Historie outsourcingu ... 4
2.1.3 Důvody k využití outsourcingu ... 5
2.1.4 Co outsourcovat ... 5
2.2 ASP ... 7
2.2.1 Co je to ASP ... 7
2.2.2 Základní charakteristiky ASP ... 7
2.2.3 Výhody: ... 7
2.2.4 Nevýhody: ... 8
3 ASP jako alternativa pro informatizaci SME ... 9
3.1 Některé aspekty využívání ASP ... 10
3.1.1 Softwarové licence ... 10
3.1.2 Servery ... 12
3.1.3 Zaměstnanci IT ... 12
3.1.4 Odbornost IT zaměstnanců ... 13
3.1.5 Bezpečnost ... 14
3.1.6 Závislost na dodavateli ... 15
3.1.7 Nedostatečná vazba ... 15
3.1.8 Integrace s ostatními vnitropodnikovými aplikacemi ... 15
3.2 Nejdůležitější zákaznické metriky ... 16
3.2.1 Dostupnost ... 16
3.2.2 Doba odezvy ... 17
3.2.3 Garance služeb v ČR ... 18
4.1 Definice SLA ... 19
4.2 Co by měla SLA obsahovat ... 21
4.3 Oblasti které by měla SLA pokrývat ... 23
4.3.1 Poskytované sužby ... 23
4.3.2 Řízení výkonnosti ... 23
4.3.3 Problem Management (Řízení sporů) ... 24
4.3.4 Povinnosti zákazníka ... 24
4.3.5 Záruky a pojištění ... 24
4.3.6 Bezpečnost ... 24
4.3.7 Zotavení při havárii a kontinuita obchodu ... 25
4.4 SLA v ČR ... 25
5 Projekt ASP pro SME v Koreji ... 26
6 Propagace ASP založených na webových službách (Web-Services) ... 28
7 Podpora spolupráce různých aplikací ... 30
8 Nové modely pro dodávání obchodních aplikačních služeb ... 31
8.1 Model SPSR (Strategy-Process-Services-Resources) ... 31
8.2 Collaborative Service Providing – CSP ... 34
9 Vlastní zkušenosti s ASP ... 35
9.1 SAP/R3 ... 35
9.2 Zoner Inshop ... 35
10 Závěr ... 36
11 Seznam použité literatury ... 37
12 Slovníček zkratek a pojmů ... 38
1 Úvod
Model poskytování aplikačních služeb je jednou forem vytěsnění (outsourcingu) vývoje údržby a správy IT ze společnosti. Je to model který by měl pomoci zavést informační systémy potřebné ke konkurenceschopnosti podniků, do společností, které nemají dostatek finančních prostředků na investice do hardware a programového vybavení.
Cílem této práce je seznámit čtenáře s problematikou poskytování aplikačních služeb a s jejich využití v malých a středních podnicích (SME). Ukázat jim výhody a nevýhody tohoto modelu, případně odstranit jejich obavy ohledně ASP.
2 Úvod do problematiky ASP
V této části bych chtěl uvést čtenáře do problematiky outsourcigu a poskytovaní aplikačních služeb, upozornit na jejich základní vlastnosti, a zmínit nejčastěji uváděné výhody a nevýhody
2.1 Outsourcing
2.1.1 Co si můžeme představit pod pojmem outsourcing?
Podstatou outsourcingu je zajišťování vybraných činností a služeb IS/IT externími dodavateli.
Podle toho co je předmětem outsourcingu rozlišujeme:
•Outsourcing rozvoje IS/IT (implementace standardních aplikací a technologií, vývoj aplikací podle přání zákazníka)
•Outsourcing provozu IS/IT (provozování jednotlivých aplikací, nebo celého systému na technice a SW dodavatele; dodavatel se stará i o údržbu a rozvoj techniky)
•Totální outsourcing (dodavatel zajišťuje provoz a rozvoj kompletně)
2.1.2 Historie outsourcingu
Outsourcing IS/IT je záležitost stará skoro půl století, avšak v každé době je jiná forma. V šedesátých letech minulého století docházelo k outsourcingu hardware, protože počítače byly velmi velké a drahé. V počátku 70 let se začalo přecházet k programování na objednávku (contract programming), důvodem byl vzrůstající požadavek po vývoji programů, avšak nedostatek programátorů. V 80 letech s příchodem osobních počítačů a změnami v manažerském myšlení, bylo IT považováno za důležitou součást podniku a trend
směřoval k vývoji vlastních podnikových systémů. V 90 letech zájem o outsourcing opět vzrostl a to hlavně v řízení sítí a telekomunikací, integraci distribuovaných systémů, vývoji aplikací a systémovým operacím.
2.1.3 Důvody k využití outsourcingu
•koncentrace podniku na hlavní předmět podnikání
•přístup k technologiím a službám, které jsou na světové úrovni
•sdílení rizik
•uvolnění podnikových zdrojů pro jiné účely
•získání zdrojů, které nejsou dostupné uvnitř podniku
•vytěsnění činností, které jsou těžko ovladatelné nebo zcela mimo kontrolu
•uvolnění kapitálových prostředků (outsourcing je nakupovaná služba, nikoliv investice)
•získání finančních prostředků (odprodejem aktiv, která již nejsou v podniku dále potřebná)
•snížení operativních nákladů
2.1.4 Co outsourcovat
Všeobecný názor říká, že trh neplatí firmu za dělání věcí, které nejsou její core- business. Přijmeme-li tuto premisu, jakákoliv IT funkce, která není částí core-businessu je kandidát pro outsourcing.
Například systémy ERP by nemusel být specialitou společnosti, takže je to nadějný kandidát pro outsourcing.. Na druhou stranu společnosti jako Wal-Mart by mohly požadovat od ERP schopnost předpovídat chování zákazníků, což u ovšem je jejich core-business, nevhodný pro outsourcing.
Na rozhodnutí o tom, co se bude outsourcovat by se neměli podílet jenom IT manažeři, ale celý management společně, protože je třeba určit co je core-business, kolik má firma zdrojů, jaké budou přínosy aplikací apod. Toto rozhodnutí může být někdy velmi
budoucnosti již nemusí, nebo obráceně. Někdy však může být vhodnější outsourcovat funkci která souvisí s core-business a naopak neoutsourcovat takovou, která s ním nesouvisí.
Někteří IT manažeři si myslí že by měli outsourcovat pouze věci, kterým rozumí, protože potom nejsou v nevýhodě při sjednávání kontraktu a řízení procesu doručení služby.
Obráceně, pak tito manažeři nechtějí outsourcovat cokoliv co nesouvisí s jejich core- businessem, i kdyby to pro ně mělo ekonomický přínos
Jak je vidět je třeba si promyslet jestli je vhodné ponechat si činnosti jako vývoj aplikací nebo strategické plánování IT ve vlastní firmě, když to poskytovatelé služeb dokážou dělat mnohem efektivněji.
Důležitou věcí při vybírání poskytovatele služeb, je že se budou pro jednotlivé služby lišit cenové modely. IT služby dávají poskytovatelům služeb mnohem vyšší provizi než ostatním.
2.2 ASP
2.2.1 Co je to ASP
ASP je zkratka pro Application service providing (provider), v překladu tedy poskytování aplikačních služeb.
ASP Consortium definuje ASP firmu jako organizaci, která poskytuje aplikace a počítačové služby více zákazníkům současně, prostřednictvím internetu nebo privátní sítě.
Dle ČSSI: „Specializovaná firma (Application Service Provider) na vlastní nebo pronajaté informační a komunikační technologii provozuje služby, které nabízí k použití externím zákazníkům. Zákazník je k aplikaci obvykle připojen přes Internet. Služby v sobě integrují software, hardware, síťové technologie a vhodné konzultační služby do jednoho balíku. K jejich využití je z technologického hlediska obvykle potřeba pouze připojení k Internetu a WWW prohlížeč na osobních počítačích uživatelů zákazníka. ASP poskytují své aplikace velkým i malým podnikům i spotřebitelům.“
2.2.2 Základní charakteristiky ASP
• Doručování po síti. ASP nabízí přístup k aplikacím pomocí počítačové sítě – pomocí Internetu, virtuální privátní sítě (VPN), pronajaté linky.
• Externě řízená. Aplikační služba je externě řízená poskytovatelem služeb z jednoho centra, radši než přímo u zákazníka.
• Služba pro více zákazníků. (1:N, One-to-many service). Model ASP je navržen jako služba pro více zákazníků. ASP obvykle nabízí standardizované, nebo jen málo kustomizované aplikace velkému počtu zákazníků.
• Cena ve formě poplatků za službu. ASP je většinou zpoplatněno pomocí paušálu za dobu užívání, nebo jako poplatek určený podle využívání služeb založený na čase, počtu transakcí, počtu uživatelů, nebo nějakých dalších ukazatelů.
2.2.3 Výhody:
•nižší náklady (Dle současných studií přitom více než 60 procent celkových nákladů dle TCO modelu (Total Cost of Ownership) tvoří podpora provozu klíčových aplikací. Odhad
úspor, kterých lze využitím vhodného ASP/outsourcingového modelu dosáhnout je až 50% (GartnerGroup).)
•predikovatelné náklady
•přesun z investičních nákladu mezi provozní
•více prostředků na investice do jiných oblastí
•škálování výkonu umožňující růst podniku (možnost rozšiřovat aktivity, aniž by bylo nutné čekat na to, než k tomu bude připravena IT infrastruktura.)
•soustředění na vlastni core-business, zvýšení produktivity
•jistota efektu - aplikaci lze předem vyzkoušet
•levná profesionální technická podpora
•geograficky neomezená přístupnost
•vyřešení nedostatku IT personálu
•veškeré služby od jednoho partnera
•zkrácení implementačních cyklů
•radikálně efektivnější využití odborných IT kapacit
(odborníci se shodují, že pouze masivní rozvoj ASP a outsourcingu může, alespoň částečně, vyřešit celosvětový nedostatek odborných IT specialistů (zejména technicky orientovaných profesí))
2.2.4 Nevýhody:
•vhodná infrastruktura
•obava o data a bezpečnost - jsou mimo vlastni firmu
•integrace s ostatními vnitropodnikovými aplikacemi
•ztráta kontroly nad vlastní aplikací (velmi subjektivní, manažeři nevědí, co se děje uvnitř a proto tomu nevěří)
•větší důvěra ve vlastní (a dražší) zaměstnance než v externí odbornou firmu
•není dostatečná nabídka
•příliš vysoká cena
3 ASP jako alternativa pro informatizaci SME
K prosazení ASP nestačí jen vyvíjet přidružené technologie, ale je třeba zavést různorodé politiky. Jednou ze slibných strategií z národního pohledu je adoptovat ASP jako nový model dodávání IT pro společnosti s omezenými zdroji, jako jsou malé a střední podniky. Pokusím se zde ukázat některé s obtíží se kterými se stýkají malé a střední podniky , abych ukázal, že jsou vhodnými cíli pro ASP.
Malé a střední podniky jsou rozděleny podle počtu zaměstnanců. Malé podniky mají méně než 50 zaměstnanců, zatímco střední podniky mají přibližně 50-300 zaměstnanců. Malé a střední podniky jsou ve většině zemí považovány za aktivní mechanismus, který posiluje ekonomiku. Ve většině zemí malé a střední podniky dosahují 99% podniků, a jsou řídící silou v rostoucích ekonomikách, protože nabízejí pracovní zkušenosti a vytvářejí pracovní místa.
Navzdory významné roli, tyto podniky čelí mnoha problémům spojenými se svou velikostí.
Jednou z velmi významných věcí je, že je zde velký rozdíl v přijetí IT mezi SME a velkými podniky. Problém vyplývá z toho, že malé a střední podniky postrádají finanční zdroje a možnosti dozvědět se o IT.
Například v Koreji, nevyžívá počítač k provádění obchodních transakcí více než 26,6% SME. Mimoto SME chtějí minimalizovat celkové náklady na vlastnění programového vybavení a udržovat ho bez IT zaměstnanců kvůli nedostatku zdrojů[K5]. V podstatě malé a střední podniky nesměřují k využívání propracovaných informačních systémů, jako je řízení dodavatelských řetězců (SCM), protože mají pouze malé pobočky a jejich rozpočet na investice je dost malý. Hlavními e-businessovými řešeními jsou plánování zdrojů podniku (ERP – enterprize resource planning), řízení vztahů se zákazníky (CRM – customer relationship management) a systémy řízení znalostí (KMS – knowledge management systém).
Takové obchodní aplikace jsou velmi drahé a pro SME je náročné je zavést. Pokud by mohly být implementovány pomocí ASP, mnoho SME by z nich mohlo získat velké výhody.
Nicméně samotná technologie ASP k přesvědčení SME k její využití. Vznikly názory, že pro dosažení impulsu je vhodné aby i vlády v základní fázi finančně a technicky podporovaly rozšíření ASP do malých a středních podniků. Kdyby SME vybavené ASP byly systematicky podporovány vládou, přínosy by byly mnohem větší pro SME než pro velké podniky, přestože velké podniky dříve přijaly model ASP.
3.1 Některé aspekty využívání ASP
V této části bych se chtěl podrobněji zabývat jak kladnými tak zápornými stránkami ASP a uvést je do prostředí malých a středních společností. A chtěl bych zde také diskutovat některé obavy zákazníků ohledně tohoto dodavatelského modelu.
3.1.1 Softwarové licence
V minulosti někteří dodavatelé neposkytovali slevy za vícenásobné licence. Někteří potom dávali například dvě licence za cenu jedné a půl, pět za cenu dvou, deset za cenu tří, ale ti vyžadovali nákup licencí pro každého zaměstnance ve firmě, přestože pouze část zaměstnanců bude využívat programy ve stejném čase. Což ovšem opět vede k nevyužité přebytečné kapacitě. Jak společnost přidávala uživatele, užitečná cena za kopii rostla. Pro společnosti s několika zaměstnanci, byly zlomové body nerealistické, protože poměr nákladů k počtu licencí klesal mnohem pomaleji, než poměr nákladů k počtu konkurenčních uživatelů.
Někteří dodavatelé zavedli plovoucí licence jako způsob jak rozpustit nákladové skoky.
Plovoucí licence spočívají v tom, že pro mnoho uživatelů, nakoupíte pouze relativně málo licencí, licence je potom vázána na počet aktuálně pracujících uživatelů. V případě, že by chtělo současně pracovat s programem více uživatelů, dostanou od systému zprávu, že systém je pro ně v současné době nedostupný, kvůli příliš vysokému počtu přihlášených uživatelů.
Otázkou však je v jaké míře zaměstnanci tyto aplikace využívají a kolik času potřebují na provedení konkrétních operací.
Zdroj:[PISTOLE05]
Obrázek ukazuje čtyři licenční možnosti při 100 dolarové kancelářské aplikaci pro firmu do sta zaměstnanců. Cena bez slev je 100 dolarů na zaměstnance. Možnost při slevě ukazuje výrazně nižší cenu, jak se počet uživatelů blíží stu. Dvě varianty plovoucích licencí sdílejí menší množství licencí mezi 100 uživatelů. Za cenu 10 plnocenných licencí dostanou uživatelé zprávu o nedostupnosti v 10% procentech případů, a v případě 17 plnocenných licencí dostanou uživatelé zprávu o nedostupnosti v 1% případů. Někteří poskytovatelé používají model plovoucích licencí pouze při poskytování formou ASP.
3.1.2 Servery
Až do nedávné doby, výpočetní a paměťová technika nenabízela v nižší třídě, žádná možnosti zlevnění pro navýšení kapacity. Malé a střední podniky měly jedinou možnost jak navýšit výpočetní a paměťovou kapacitu, tj. přidávat servery po jednotkách. Jejich průměrné roční náklady byly okolo 80 000 dolarů [STUART03]. Dnes však existuje platforma blade serverů, která umožňuje zdvojnásobení kapacity, při zvýšení nákladů 1,3 až 1,6 krát. Nicméně konfigurace je velmi složitá, s mnoha kombinacemi procesorů a rychlostmi sběrnic, pamětí, kapacity disků, a šířkou komunikačního pásma.
I přesto jsou tyto blade servery celkem drahé a jejich provoz je svázán s prací stále se učících odborníků. Některé společnosti proto začaly pronájem výpočetní kapacity, placenou za hodinu využití procesoru.
3.1.3 Zaměstnanci IT
Předpokládejme, že podpora a údržba nové desktopové aplikace zvýší vytížení IT zaměstnanců o 0.3 ekvivalentu plné pracovní doby (FTE – full-time equivalent). Řekněme, že společnost má smlouvu s poskytovatelem služeb, ale rozhodne se držet tuto novou službu ve svých rukou. Nájem nového zaměstnance bude podle [STUART03] stát okolo 100 000 dolarů ročně, a navíc to bude společnost zatěžovat přebytkem zaměstnanecké kapacity 0,7 FTE.
Tohle pravděpodobně bude pro malou společnost nepřípustné. Přidá-li společnost tento úkol k již existující smlouvě, poskytovatel služeb může podporovat novou aplikaci bez zátěže v podobě nadbytečné zaměstnanecké kapacity, což se projeví v nižších nákladech pro společnost.
Zdroj:[PISTOLE05]
Když však zavedení nové aplikace zvýší vytížení IT zaměstnanců o 0,9 FTE, pravděpodobně již nebude taková výhoda přidat tento nový úkol k již existující smlouvě s poskytovatelem služeb. V tomto případě bude nadbytečná kapacita (0,1 FTE) zanedbatelná a cena poskytovatele služeb mírně vyšší než náklady společnosti při řešení vlastními silami.
Společnosti však při rozhodování dělají jednu základní chybu: neuvažují náklady obětované příležitosti. Protože peníze, které ušetří v případě, že se rozhodnou využít služeb poskytovatele, mohou využít na něco úplně jiného, například mohou tyto peníze investovat do cenných papírů apod.
3.1.4 Odbornost IT zaměstnanců
Dodavatelé aplikačních služeb se na rozdíl od svých zákazníků specializují na svou činnost, a mají jisté know-how v oboru. Tj. vědí o věcech o kterých zákazník nemusí ani tušit.
Jejich zaměstnanci jsou pravidelně seznamováni s novými trendy a technologiemi v daném oboru. Vzhledem k tomu, že poskytovatelé služeb nemají pouze jednoho zákazníka, ale poskytují služby více zákazníkům najednou , mohou využívat zkušenosti získané u ostatních zákazníků i ve vašem případě a uplatnit tak best-pratice. Je třeba si uvědomit, že služby poskytované formou ASP, nejsou služby konkurenční výhody, ale běžně využívané aplikace, a tak je pravděpodobně vhodnější, standardní řešení, než jedinečné řešení spravované vlastními silami. Zákazník již dále nemusí sledovat trendy v IT oblasti a vyvíjet aktivity na zajištění údržby, oprav, a další technické podpory a může se plně soustředit na svůj core-bussiness.
Spojíme-li tyto příklady dohromady, tj. náklady na kvalitní hardwarové vybavení, náklady na programové vybavení a náklady na odborníky, kteří jednotlivým částem rozumí a umí je ovládat, dostaneme se k otázce, jak tyto náklady co nejúčinněji snížit. A v případě investic do software a hardware jak je co nejlépe rozdělit do jednotlivých období, abychom neměli velké výdaje a nemuseli si půjčovat na úrok. Řešením je právě služba poskytování aplikací nebo poskytování aplikačních služeb (Application service providing).
Poskytovatel aplikačních služeb nám poskytne k dispozici svoje kvalitní hardwarové vybavení, navíc k tomu přibalí i konkrétní programové vybavení a ještě technickou podporu.
Samozřejmě to neznamená, že bychom se mohli zbavit všech počítačů a programů ve firmě, ale postačí nám například pouze počítače s minimální konfigurací a připojení k internetu.
3.1.5 Bezpečnost
Jedním z největších argumentů proti ASP je riziko bezpečnosti a úniku informací.
Firmy se bojí využívat těchto služeb, protože jejich data jsou spravována mimo jejich firmu a navíc cizími lidmi. Je potřeba si však uvědomit, že i vlastní zaměstnanci přináší riziko bezpečnosti, a to mnohem větší protože pracují v právě v tom oboru jako vaše firma, a v případě změny zaměstnání, budu pravděpodobně pracovat ve stejném oboru dále. Zatímco zaměstnanci společnosti zabývající se poskytováním aplikačních služeb pracují v úplně jiném oboru, a navíc taková společnost nemá zájem na tom zneužívat informace poskytnuté zákazníkem, protože jakákoliv skvrnka na důvěryhodnosti jí může naprosto a definitivně zničit, protože přijde o všechny své zákazníky a v nejbližší době ani žádné nové nezíská.
Další otázkou je zabezpečení uložených dat proti útoku zvenčí. Firmy které nabízejí ASP dokáží lépe a levněji zajistit určitá zabezpečení proti útoku zvenčí, protože spravují data desítek a někdy i stovek či tisíců firem. Jedná se hlavně o zabezpečení které si malá nebo střední firma nemůže dovolit, a ani by se jí nevyplatily, protože riziko úniku informací jedné firmy se většinou nevyrovná nákladům na různá zabezpečení, zatímco poskytovatel je shopen rozdělit tyto náklady mezi všechny své zákazníky.
Dalším hlediskem bezpečnosti může být i hledisko ochrany dat před ztrátou či poškozením způsobených jiným než lidským jednáním. Může jít například o poruchy počítačového vybavení (porucha disku), nebo případy živelných katastrof. Proti těmto nehodám se lze bránit dobrou zálohovací strategií, a využitím kvalitního hardware.
Samozřejmě, že toto riziko hrozí i v případě, kdy máte data uložená vevnitř ve své firmě.
Ostatně otázka bezpečnosti je jednou z významných částí SLA a dobře postavená SLA dokáže snížit riziko pro zákazníka, nebo alespoň pocit rizika.
Bezpečnost lze měřit těmito nástroji[VIT04]:
• Analýza rizika – jde o odhad pravděpodobnosti určitého typu pokusu o neoprávněný přístup a vyvážení nákladů na jeho zabezpečení a nákladů vzniklých úspěšným pokusem
• Popis jednotlivých metod a technologií zabezpečení. Přestože se jedná o popis, lze pomocí vhodného systému ohodnotit úroveň i číselně, a tak lépe porovnávat různé poskytovatele ASP
• Měření úsilí nutného k prolomení bezpečnostních opatření systému. Vychází z předpokladu, že vyšší úsilí znamená také vyšší bezpečnost.
3.1.6 Závislost na dodavateli
Samozřejmě jako všechny partnerské vztahy i ASP nese jisté riziko, které se však dá minimalizovat spoluprácí s důvěryhodným solidním dodavatelem, který má dlouhodobé zkušenosti, dobré reference, tradici a kredit. Důležitá je v tomto směru i správně sepsaná SLA s definovanými sankcemi při porušení smlouvy.
3.1.7 Nedostatečná vazba
Vzhledem k tomu, že se jedná o spolupráci s externí firmou a její zaměstnanci nejsou a ani nemohou být neustále přítomni u zákazníka, nemohou ani vědět jak přesně daná firma funguje a tyto věci je třeba si nejprve ujasnit a zajistit tak dobrou komunikaci mezi oběma stranami.
3.1.8 Integrace s ostatními vnitropodnikovými aplikacemi
S tímto problémem se setkáte vždy, když si nebudete vyvíjet software vlastní silou, nebo od jediného dodavatele. Vždy narazíte na nějakou nekompatibilitu dat a podobné věci, proto je celkem vhodné při výběru poskytovatele služeb, nejprve zvážit , jestli neexistuje nějaký, který nabízí všechny požadované sužby najednou, nebo jestli nám někdo nenabízí službu s nějakým standardním rozhraním, například výměnu dat pomocí formátu XML, případně nějakým jiným strukturovaným formátem, na nějž se dá navázat i jiná aplikace.
Já jsem se například setkal s vazbou balíkového ekonomického softwaru na aplikaci elektronického obchodu poskytovanou formou ASP (každé od jiného dodavatele).
Ekonomický software uměl exportovat data do několika různých elektronických obchodů, a to tak že spolupracoval s klientskou aplikací pro správu obchodu. Navíc samotná aplikace obchodu byla schopna importovat data z různých databází.
3.2 Nejdůležitější zákaznické metriky
3.2.1 Dostupnost
Asi nejsledovanější metrikou je otázka dostupnosti. Dostupnost vyjadřuje dobu po kterou může uživatel aplikaci využívat v plném rozsahu bez jakýchkoliv omezení. Číselné vyjádření dostupnosti bývá stanoveno procentuálně k určitému časovému úseku, například den či měsíc. Nejedná-li se o kriticko aplikaci, je pro uživatele důležité, aby byla dostupná po celou pracovní dobu. Je potřeba si uvědomit, že aplikace je potřeba také udržovat a také vylepšovat, proto bývá definována doba, kdy může být aplikace nedostupná, je tomu tak většinou v nočních hodinách, kdy se očekává nejméně požadavků. Tato doba se zpravidla do celkové dostupnosti nezahrnuje.
Důležitá pro stanovení dostupnosti je i délka období ke kterému se dostupnost vztahuje. Následující tabulka ukazuje procentuální dostupnost přepočítanou na skutečnou dobu, kdy může být aplikace nedostupná.
Procento
dostupnosti: Den Týden Měsíc Rok
99,99% 8,6 sekundy 1 minuta 4,3 minuty 52,5 minuty
99,90% 1,4 minuty 10,1 minuty 43,2 minuty 8,8 hodiny 99,00% 14,4 minuty 1,7 hodiny 7,2 hodiny 87,6 hodiny 98,00% 28,8 minuty 3,4 hodiny 14,4 hodiny 7,3 dne
97,00% 43,2 minuty 5 hodin 21,6 hodiny 11 dnů
Jak je z tabulky vidět, tak při garantované 99% dostupnosti za den se může stát, že aplikace bude nedostupná 14,4 minuty, bude-li však garantovaná dostupnost roční tak se může stát, že se nám k aplikaci nepodaří připojit několik po sobě následujících dní.
Za co poskytovatel aplikace při garanci ručí? Pokud od si od poskytovatele nepronajmete i přenosové cesty, pak ručí pouze za dostupnost serveru a aplikace. To znamená, že i když je aplikace dostupná, nemusí se vám podařit se k ní připojit. Někteří poskytovatelé aplikačních služeb, řeší otázku dostupnosti strategickým partnerstvím s telekomunikačními společnostmi a zákazníkovi jsou pak také schopny garantovat připojení k Internetu.
Dalším důležitým hlediskem z pohledu dostupnosti je, kde se garantovaná dostupnost měří. Dostupnost je možné měřit přímo na serveru, nebo například v lokální síti poskytovatele. Pro zákazníka je si nejvhodnější měří-li se dostupnost přímo u něj ve firmě, avšak i toto bývá otázkou peněz.
3.2.2 Doba odezvy
Další často používanou metrikou je doba odezvy. Její nejčastější využití je při měření vlastnosti nějaké služby, aplikace, databáze, nebo kvality síťové infrastruktury (například za jak dlouho dostanete výsledek, pokoušíte-li se na internetu vyhledat spojení z Prahy do Brna) U ASP může jít o skloubení všech uvedených případů.
Faktory ovlivňující dobu odezvy[VIT04]:
• Počet zákazníků používajících zároveň danou službu - poskytovatel musí brát v potaz zvyšující se zátěž systému při používání aplikace mnoha zákazníky naráz. Musí vhodně vyvážit počet možných připojení a přijatelnou dobu odezvy služby.
• Přenosová rychlost - rychlost přenosu dat je také jedním z důležitých činitelů ovlivňujících dobu odezvy. Může se lišit v jednotlivých úsecích přenosové cesty.
• Typ aplikace - rozdílné požadované doby odezvy závisí i na tom, o jakou aplikaci se jedná. Některé potřebují velmi rychlé reakční doby (např. software využívaný pro podporu pracovníků call-centra), jiným ke svému normálnímu provozu posta í i reakce v řádech desítek sekund a vyšší.
• Typ požadavku - i v rámci jedné aplikace je rozdílná doba odezvy pro různé požadavky. Ty se mohou lišit v závislosti na objemu dat se kterými se pracuje buď minimálně (např. vložení jedné faktury vs. vyhledání faktur podle druhu zboží) nebo výrazně (vyhledání faktury vs. vypracování účetní sestavy za kalendářní měsíc).
• Výkonnost HW a SW infrastruktury nutné pro běh aplikace - hardware musí být dostatečně dimenzován a software optimalizován pro dosahování nízké doby odezvy (v modelu ASP jde samozřejmě o stranu poskytovatele, nároky na výkon HW u zákazníka jsou většinou minimální).
Je-li poskytovatel aplikačních služeb zároveň i poskytovatelem připojení, nebo má-li smlouvu s telekomunikační společností, jako jsem uvedl v části o dostupnosti, pak může garantovat dobu odezvy přímo u uživatele. Obvyklejší však je že poskytovatel nemá kontrolu nad některou částí přenosové cesty a pak ani nemůže garantovat dobu odezvy přímo u uživatele, je pak třeba měřit na sytému poskytovatele, například jako dobu od příchodu požadavku do systému.
Pro měření doby odezvy, je také potřeba specifikovat, čeho se doba odezvy bude týkat.
Jestli má být každá reakce aplikace provedena do této doby, či zda to bude doba odezvy nejpoužívanější akce v běhu aplikace, nebo průměrná doba odezvy. Hodnoty je třeba měřit v pravidelných intervalech.
3.2.3 Garance služeb v ČR
Dle [KRT04] poskytovatelé ERP služeb formou ASP zákazníkovi nejčastěji garantují zálohování a zákaznickou podporu, dále aktualizaci, dostupnost, bezpečnost a upgrade, vše nad 82% firem. Nejméně je v ČR garantována doba odezvy aplikace.
Zdroj:[KRT04]
4 Service Level Agreement (SLA) - Dohoda o úrovni služeb
4.1 Definice SLA
Service Level Agreement (SLA) je pojem, který byl vynucen potřebou co nejpřesněji definovat rozsah, úroveň a intenzitu externě poskytovaných sužeb.
Dle ČSSI je SLA „Dohoda o úrovni služeb. V řízení podnikových informačních systémů: smlouva s provozovatelem IS (s dodavatelem v případě outsourcingu nebo v případě interního provozu vnitropodniková) nebo její součást, která vymezuje parametry provozu (metriky IS aplikačního software a hodnoty těchto parametrů, které mají být provozovatelem splněny (úroveň služby, Service Level). Pokud provozovatel nesplní sjednanou úroveň služby, bývá penalizována, způsob penalizace však musí být přesně sjednán. SLA jsou sjednány obvykle ve formě strukturovaných dokumentů. Úroveň služby bývá sjednána pro jednotky užití ASW: pro aplikace IS a pro kategorie uživatelů jednotlivých aplikací. Úroveň služby je tak rozdílná pro různé potřeby užití ASP.“
Podle [UCEN01] je SLA „pojem, který primárně vzniknul jako nástroj měření úrovně poskytovaných služeb externím poskytovatelem rámci outsourcingu, outhostingu, resp.
v rámci jiného typu smluvního vztahu, jako je kupř. servisní smlouva. Naměřené hodnoty potom podmiňují výši plateb, resp. uplatnění sankcí, ve vztahu k externímu poskytovateli.“
V intencích ISACA je SLA definován jako minimální hranice, nad jejíž úrovní jsou dodávané služby ještě akceptovatelné [ISACA]. SLA je formálně stanovená smlouva mezi poskytovatelem služeb a jejich uživatelem, která přesně vymezuje podmínky vztahů a odpovědností při poskytování definovaného rozsahu, objemu a úrovně služeb.
Podle Service Level Agreement Advisory Group je SLA klíčová součást smlouvy která se zabývá pozorováním a měřením kvality úrovně sužeb. Každá služba musí být měřitelná a výsledky analyzovány a reportovány.
SLA je dokument, který definuje vztah mezi dvěma stranami: poskytovatelem a příjemcem.
Je to samozřejmě velmi důležitá součást dokumentace pro obě strany. Je-li užívána důkladně tak by měla:
• Identifikovat a definovat zákazníkovy potřeby
• Poskytnout rámec pro dohodu
• Zjednodušit komplexní problémy
• Omezit konfliktní oblasti
• Povzbudit dialog v případech sporu
• Odstranit nereálná očekávání
4.2 Co by měla SLA obsahovat
SLA se dle [UCENO1] skládá ze tří částí:
a) Základní specifikace, podmínky a pravidla:
• Kategorie příjemců.
• Přesné vymezení počtu a umístění příjemců dané kategorie.
• Popis služeb.
• Objem poskytovaných služeb (aplikace ve vztahu k počtu zpracovávaných dokladů v dané periodicitě apod.)
• Poskytovatel - bližší určení (uvádí se, má-li smysl, resp. je-li uživatelů více).
• Měření - postup, způsob, periodicita, odpovědnost a vykazování výsledků.
• Ověřování - postup, způsob, periodicita, odpovědnost a vykazování výsledků ověřování správnosti měření.
• Určení a způsobu realizace podpory (kupř. fyzicky na místě, vzdáleně apod.).
• Návazné podpůrné služby spojené s danou službou (kupř. trénink na místě, resp. na učebně).
• Cena služby.
• Platební podmínky.
• Pravidlo pro změny služby.
• Práva a povinnosti obou stran - podmínky součinnosti.
• Ostatní podmínky pro realizaci SLA (bezpečnost, právo informovanosti, odpovědnost za vady a škody apod.).
b) Tvrdé metriky:
• Dostupnost (v % vyjádřený skutečný čas disponibility aplikace na daném zařízení uživatele ve vztahu k celkovému efektivnímu fondu pracovní doby za určenou časovou jednotku).
• Běžná a maximální přípustná (kritická) doba odezvy na požadavek - tzv. incident (v členění na jednotlivé typy požadavků, jako je např. hlášení poruchy aplikace , poruchy HW, přemístění koncové stanice, apod.).
• Běžná a maximální přípustná (kritická) doba řešení požadavků (v členění na jednotlivé typy požadavků).
• Průměrná a mezní odezva aplikace v rámci služby.
c) Měkké metriky:
• Ostatní metriky pro danou službu (kvalitativní ukazatele typu "akceptace", "zápis",
"potvrzení realizovaného školení a prezenční listina", "hodnocení lektora školení",
"hodnocení účastníka školení", apod.).
V souvislosti s tvrdými metrikami jako součást SLA (jako jsou kupř. odezva, dostupnost apod.) jsou v některých případech stanovovány až tři úrovně tohoto parametru:
a) Servisní úroveň - požadovaná hodnota parametru za standardních podmínek (např.
dostupnost na úrovni 0,97 a vyšší)
b) Minimální servisní úroveň - pod tuto mez nesmí hodnota daného parametru nikdy klesnout (např. dostupnost 0,94)
c) Motivační (incentive) servisní úroveň - má motivovat poskytovatele k poskytování nadstandardní úrovně služeb (kupř. dostupnost nad 0,99).
Nedosažení "servisní úrovně" vede dle podmínek definovaných v SLA ke snížení plateb za služby. Nedosažení ani minimální servisní úrovně je událostí, která způsobí uplatnění předem definovaných sankcí. Dosažení motivační úrovně naopak zakládá nárok poskytovatele na bonus.
Tzv. "paušál plateb za poskytované služby" je v podmínkách outsourcingu stanoven ve vztahu k "servisní úrovni". Platebními podmínkami je stanoven vliv minimální servisní úrovně a motivační servisní úrovně na skutečnou výši plateb za dané období.
4.3 Oblasti které by měla SLA pokrývat
Výslovně by měla zahrnovat velký rozsah otázek. Mezi nimiž jsou obvykle tyto[SLAZ]:
• Služby, které mají být poskytovány
• Sledování a vykazování výkonnosti
• Řízení sporů
• Právní svolení a řešení sporů
• Zákazníkovy povinnosti a zodpovědnosti
• Bezpečnost
• Duševní práva vlastnictví a důvěrné informace
• Ukončení
4.3.1 Poskytované sužby
To je nejkritičtější část dohody popisující služby a způsob jakým mají být dodávány.
Běžné sužby jsou většinou odděleny od kustomizovaných služeb, ale toto oddělení není rozhodující.
Informace o službách musí být přesné a musí obsahovat detailní specifikace toho co má být poskytováno.
4.3.2 Řízení výkonnosti
Klíčová část SLA, která se zabývá sledováním a měřením plnění úrovně služeb. Každá služba musí být měřitelná a výsledky měření analyzovány a vykazovány. Testy, cíle a metriky musí být specifikovány přímo ve smlouvě.
Úroveň kvality služeb musí být pravidelně hodnocena oběma stranami.
4.3.3 Problem Management (Řízení sporů)
Cílem problem managementu je minimalizovat záporné dopady incidentů a spor.
Obvykle se tu specifikuje, že musí být náležitý postup jak zacházet a řešit neplánované incidenty a to že musí také být preventivní aktivity vedoucí k omezení těchto neplánovaných nehod.
O všech incidentech a sporech musí být vedeny formální záznamy.
4.3.4 Povinnosti zákazníka
Pro zákazníka je také důležité uvědomit si, že on má také povinnosti podporovat proces doručení služeb. SLA definuje vztah, který je samozřejmě oboustranný
Obvykle zákazník musí zajistit přístup, vybavení a zdroje pro dodavatelovi zaměstnance kteří potřebují pracovat na místě.
4.3.5 Záruky a pojištění
Tato sekce SLA obvykle pokrývá tyto klíčové oblasti:
Kvalitu služeb Zabezpečení Nároky třetí strany
Odškodnění při porušení smlouvy Výjimky
Vyšší moc
4.3.6 Bezpečnost
Bezpečnost je obzvlášť významná část jakékoliv SLA
Zákazník musí poskytnout kontrolovaný fyzický i logický přístup ke svým předpokladům a informacím. Zároveň dodavatel musí respektovat a souhlasit s bezpečnostní politikou a procedurami zákazníka.
4.3.7 Zotavení při havárii a kontinuita obchodu
Zotavení při havárii a kontinuita obchodu může být kritická záležitost. Tento fakt by měl být odražen v SLA.
Téma zotavení při havárii je obvykle zahrnuto do části o bezpečnosti. Nicméně je často taky obsaženo v oblasti problem managementu.
4.4 SLA v ČR
Dle průzkumu [KRT04] 76% českých firem využívá (nabízí) Service Level Agreement a pouze 24% českých ERP firem SLA nevyužívá.
5 Projekt ASP pro SME v Koreji
V roce 2001 Korejská vláda ohlásila projekt ASP pro malé a střední podniky. Tento projekt byl zaměřen na poskytnutí levnějších a přijatelnějších řešení v porovnání s balíkovými produkty, aby pomohl překonat nedostatek IT specialistů v malých firmách[OECDO4].
Hlavním úkolem tohoto projektu bylo sestavit společenství ASP vedené významnějšími telekomunikačními společnostmi. Společenství jsou řízena vládou, což jim také zajišťuje finanční a technologickou podporu. Následující obrázek ukazuje strategii prosazování ASP pomocí společenství ASP. Podle plánu, informatické společnosti spolupracují v jednom ze společenství a vyvíjejí různá řešení vhodná pro SME. Vláda poskytuje finanční pomoc, aby IT společnosti mohli vyvíjet obchodní řešení, a také poskytuje počítačové vybavení, jako datová úložiště, potřebná pro ASP servery. Pak společenství poskytují SMP aplikační služby pomocí širokopásmového připojení k Internetu každého společenství.
Obrázek: Strategie podpory ASP pomocí společenství ASP
Zdroj: [KIM05]
V roce 2004, Korejská vláda založila nadaci díky které ASP mohou spontánně pronikat do různých průmyslových odvětví. Následně pět společenství hrálo velkou roli
v informatizaci SME: Korea Telecom Bizmeka, Dacom eBizmart, Hanaro Bizfos, Korea Information and Communication Company Bizcheck a Elion Bizfirst. Společenství získala více než 120 členských společností, které mhou vyvíjet základní obchodní řešení jak SCM a CRM. IT řešení pokrývají různé obchodní typy a umožňují meziodvětvové transakce. Detailní informace o společenstvích jsou uvedeny následující tabulce
Tabulka: Pět společenství pro podporu modelu ASP v Koreji
Zdroj: [KIM05]
6 Propagace ASP založených na webových službách (Web-Services)
Jako výsledek projektu na propagaci ASP, do roku 2004, 370 000 SME v Koreji (12%
z celkového počtu 2 950 000 SME) využilo ASP projektu pro Informatizaci SME[PAEK04].
Nicméně rozdíl mezi SME a velkými podniky se nezmenšil dostatečně. V blízké budoucnosti model ASP bude srovnávat rozdíl mezi velkými a malými společnostmi, ale bude mít problém získávat zákazníky výbušně. To je proto, že ASP stále čelí problémům kustomizace specializace ve specifických typech softwaru nebo aplikacích specifických pro určitá průmyslová odvětví; přesněji SME mají velkou pestrost potřeb na IT aplikace ve srovnání s velkými společnostmi. Ačkoliv dodavatelé IT se více zaměřují na SME, není jednoduché produkovat různorodá řešení šitá na míru SME, při použití běžných technologií ASP.
Kustomizační úsilí může výrazně snížit rentabilitu poskytovatelů ASP.
Není tomu dlouho co poskytovatelé ASP začali používat technologii webových služeb, aby překonali problém kustomizace.
Nicméně společnosti poskytující aplikační služby založené na webových službách se zaměřily pouze na malou skupinu řešení. Pro oživení Odvětví ASP založeného na webových službách jsou potřebné více progresivní činnosti jako zakládání spojených institučních systémů. K propagaci ASP v Korejském projektu ohlásila vláda čtyřletý plán pro ASP založené na webových službách který běží od roku 2005 do roku 2008. Jako cíl si tento plán stanovuje informatizaci jednoho miliónu malých a středních podniků. Pro podpoření plánu vláda v roce 2004 spustila Korea IT Rental Industrial Association (KITRIA) a v roce 2005 založila Web Services Center. Web Services Center vyvíjí národní UDDI, které je základem pro tvorbu distribučního sytému komponent ASP, a které bude také garantovat kvalitu a bezpečnost webových služeb.
Druhý projekt ASP dělá hodně pro scelení infrastruktury ASP založených ne webových službách. V tomto kontextu, všechny potřebné komponenty, jako ověření uživatele, účtování a bezpečnost budou vyvíjeny s technologií webových služeb. Pak budou vybírány běžné části služeb, které mohou být sdíleny mezi různorodými průmyslovými odvětvími a různá obchodní řešení. Konkrétněji drahá obchodní řešení jako ERP, CRM, SCM a groupware budou transformována do ASP založených na webových službách, pokud bude o těchto řešeních v malých a středních podnicích zájem. V současnosti se vláda snaží podporovat
společnosti, které mohou nabídnout kustomizované ASP služby; je od nich očekáváno upokojení různých požadavků z 1099 průmyslových oblastí. Navíc jsou již vyvinuté komponenty webových služeb registrovány v UDDI, aby je ostatní vyvíjející společnosti, ASP partneři a SME mohli společně vyžít.
Dalším efektivním řešením, které podporuje model ASP, je prosazovat brokerské společnosti webových služeb. Ve většině případů, komponentové produkty a služby nabízené ve formě ASP jsou doručovány pomocí série zprostředkujících vztahů mezi různými dodavateli. Broker webových služeb je obchodní entita, která vykonává kustomizační aktivity a implementuje uživatelské rozhraní, aby SME zákazníci mohli ASP využívat jednoduše. Aby byl brokerský model rentabilní, vláda bude mít velký zájem ve vývoji těchto brokerských společností.
7 Podpora spolupráce různých aplikací
V současné době je většina dodávaných aplikačních služeb založena proprietárních architekturách firem které je vyvinuly a je obtížené je přímo propojit s dalšími obchodními aplikacemi. Potřeba propojení aplikací je hnána především vývojem elektronického obchodování, ale je také potřeba v rámci jednoho podniku, abychom mohli propojit více různých obchodních řešení sdílejících data a obchodní procesy. V minulosti bylo možné využít tohoto propojení pouze, pokud jeden poskytovatel dodával tato řešení najednou.
Současný vývoj vede na řešení ASP založená na webových službách a přidružených standardech.
Základní myšlenkou webových služeb je zpřístupnit business procesy ve formě služby definované a doručené pomocí standardních protokolů a rozhraní. Webové služby umožňují poskytovaní služeb mnohem větší jemnosti než je běžné v klasickém modelu ASP. Pomocí webových služeb je možné zpřístupnit jednotlivé procesy, jako je např. ověření uživatele, nebo proces objednávání a propojit je na jiné aplikace. Hodně dodavatelů již nabízí nástroje, které umožňují vytvoření webových služeb z již existujících komponent aplikací, sjednocující webové služby pomocí J2EE nebo Microcoft .Net.
Webové služby jsou standardní cestou integrace aplikací založených na webu užitím standardizované výměny zpráv pomocí XML, složené ze protokolu jednoduchého přístupu k objektům (SAOP), popisného jazyka webových služeb (WSDL) a standardu univerzálního popisu, zpřístupnění a integrace (UDDI): SOAP je protokol přenosu zpráv založený na XML, pro přenos dat mezi dvěma entitami; WSDL jazyk formátu XML pro popis dostupných služeb; UDDI je prohledávatelný distribuovaný seznam, který obsahuje dostupné služby.
Webové služby umožňují různým aplikacím založeným na různých platformách mezi sebou komunikovat bez čas spotřebovávajícího překódování. Konkrétněji, s pomocí webových služeb založených na komponentách a business-procesech, bude možné implementovat ASP služby na objednávku, začleněním jednotlivých modulů pro obchodní řešení.
8 Nové modely pro dodávání obchodních aplikačních služeb
Nové modely pro dodávání a implementaci obchodních aplikací, musí být promýšleny v kontextu nových obchodních modelů. To je hlavně platné v situacích kdy outsourcované aplikací mají spolupracovat s aplikacemi vnitropodnikovými.
8.1 Model SPSR (Strategy-Process-Services-Resources)
Autoři modelu věří, že pro využití všech výhod modelu ASP, organizace potřebují splnit dva předpoklady:
1. procesně orientované řízení klíčových obchodních činností
2. řízení IT a informačních systémů na bázi řízení informačních služeb.
Oba tyto předpoklady jsou splněny při využití modelu SPSR znázorněného na následujícím obrázku. Model formuluje jak jsou informační služby řízeny v procesně orientovaných společnostech.
Určení: jaké produkty a služby, jakým zákazníkům, s jakými partnery
Hlavní proces 1
Hlavní proces "p"
Dodavatelé pro hlavní procesy
Zákazníci
Neinformatická služba / Podpůrný proces "pp"
Informatická služba 1 Informatická služba "s"
Zdroj 1 Zdroj 2
VRSTVA HLAVNÍCH A PODPŮRNÝCH
PROCESŮ
= "Process Business Value MNG"
VRSTVA INFORMATICKÝCH
SLUŽEB
= "IT Service Business Value MNG"
VRSTVA INFORMATICKÝCH
ZDROJŮ
= "Resource Business Value MNG"
Produkt/
Služba 1
Produkt/
Služba "p"
VRSTVA STRATEGICKÉHO
ŘÍZENÍ
"S"
"P"
"S"
"R"
Zdroj "z"
Trh a procesy
dodavatelů Trh
produktů a služeb podniku
Trh IS/IT zdrojů
Trh služeb IS/IT
Trh IS/IT zdrojů Pronájem / prodej
nadbytečných zdrojů
Záměrem rozdělení obchodního řízení do čtyřech vrstev je možnost jednoznačně identifikovat zodpovědnosti jednotlivých typů manažerů v mnohem transparentnějším způsobu, který zobrazuje obchodní cíle až po vrstvu řízení IS/IT
Strategické řízení podniku je zodpovědné za ukazování obchodních cílů a priorit a za vytváření podmínek a zdrojů umožňujících těchto cílů dosahovat. To znamená, že jeho prací je ukazovat co je hlavní činností podniku (core-business), kdo jsou základní zákazníci – ti na které je obchod orientován, jaké produkty a služby chtějí poskytovat a kdo jsou hlavní obchodní partneři. Je také zodpovědný za vytváření a udržování zdrojů, jako jsou lidé, znalosti finance, technologie, potřebných k dosahování nastavených cílů.
Vrstva hlavních a podpůrných procesů obsahuje následující aktivity: 1)definici a optimalizaci obchodních procesů, 2)operativní řízení procesů a kapacit, 3)sledování procesů a 4)vykonávání procesů. Manažer zodpovědný za popis a optimalizaci je zodpovědný za nastavování procesu do takového stavu aby proces vedl k produkci konkurenčního výrobku nebo služby ve správném čase, objemu, kvalitě a za přijatelnou cenu.
Část definic procesů, musí také být podkladem pro informační služby, které budou optimálně tyto procesy podporovat. To je ve skutečnosti popsaná zodpovědnost manažera procesů za objednaný obsah, množství a kvality informačních služeb. Manažer procesu musí spočítat akceptovatelnou sumu za objednané služby. Cena informačních služeb je jednou z nákladových položek, a jakmile vyroste příliš vysoko, finální produkt přestane být konkurenceschopný. To je jedním z klíčových bodů tohoto modelu.
Pokud není možné zajistit požadovanou informační službu za tuto stanovenou cenu, pak je nutné seřídit hlavní proces a jeho požadavky po informačních službách.
Manažer procesů nakupuje potřebné informační služby od manažera informačních služeb. V případě centralizovaného IT managementu, zodpovědnou osobou za všechny informační služby je CIO. On také rozhoduje o formě (interní, externí, kombinace) jejich zajištění. Je vhodné použít stejnou definici informačních služeb a jejich strukturu (SLA) pro interní i externí dodávku. Použijeme-li stejnou definici služby, pak je mnohem jednodušší rozhodnout, jestli službu pořídíme interně nebo od externího dodavatele.
Když jsme toto všechno udělali, dostáváme se do třetí vrstvy business managementu, do vrstvy informačních služeb. Informační služby jsou činnosti, které formují nový
informační produkt integrací konkrétních zdrojů IS/IT. Tento produkt formuje vstup do hlavních nebo podpůrných obchodních procesů.
V případě, že manažer rozhodne pořídit službu od externího dodavatele, problém řízení informační služby se omezí na tvorbu kontraktu a kontrolu jeho výsledků. Smlouva obsahuje SLA pro všechny nasmlouvané služby.
Kritérii efektivnosti manažera služeb IS/IT není pouze míra plnění parametrů služby dohodnutých v SLA, ale také dosahování nákladů služby, které jsou nižší nebo stejné jako dohodnutá cena, a zároveň porovnatelné s cenami podobných služeb na trhu.[VORISEK02]
8.2 Collaborative Service Providing – CSP
Model CSP se zaměřuje na to jak jsou externí aplikace služby implementovány, jak jsou tyto služby doručovány společnosti, a kdo se podílí na dodávce těchto služeb.
[VORISEK02]
Zdroj: [VORISEK02b]
Model CSP obsahuje osm hlavních aktérů, kteří se podílejí v řetězci na doručení aplikační služby koncovému uživateli. Každý jednotlivý produkt vyžadující vytvoření komplexní aplikační služby potřebuje speciální zdroje a expertízu.
Seskupení různých partnerů nemusí vždy odpovídat přesně tomu co je na předchozím obrázku. Ve skutečnosti existují společnosti, které hrají několik rolí najednou.
Zákazník - v roli konzumenta
služeb ASP/Outsourcer
- provoz aplikace - poskytování aplikačních služeb
Výrobce / prodejce technologie - výroba a dodávky
HW, sít. prvku a ZSW Software house
- tvorba ASW
ISP, NSP - poskytovatel
konektivity - přenos dat a
připojení na Internet
Telekomunikace - poskytovatel telekomunikační
infrastruktury Provozovatel
technologické infrastruktury - provoz serverů, koncových stanic a
diskových polí
Konzultant - řešení problémů vyžadujících specif.
znalosti Implementátor
a syst.
integrátor - iplementace ASW
- systémová integrace
9 Vlastní zkušenosti s ASP
Jakožto pokročilý uživatel počítače se denně setkávám s aplikačními službami, jako je poskytování emailu, nebo například webhosting, který se v určitém smyslu dá také považovat jako ASP. Ale už jsem se setkal i s rozsáhlejšími aplikacemi poskytovanými formou ASP, tak bych se zde chtěl s vámi podělit o své uživatelské zkušenosti.
9.1 SAP/R3
Během studia jsem se setkal s ERP aplikací SAP/R3, nejdříve ve společnosti, kde jsem pracoval, kde měli tento software nainstalovaný na serveru, a poté na kurzu „Aplikační software“, kde jsme používali verzi přístupnou přes webové rozhraní poskytovanou formou ASP. Jednalo se tedy o stejnou verzi softwaru, avšak přístup byl proveden jinak. Vzhledem k tomu, že jsem již byl asi rok s tímto softwarem seznám na základní uživatelské úrovni, neměl jsem žádný velký problém se zvládnutím této aplikace přes webové rozhraní. Kdyby celé uživatelské rozhraní nebylo orámováno oknem prohlížeče, pravděpodobně bych ani nepoznal, že používám software, který nemám na svém počítači nebo na serveru ve své lokální síti. Všechna rozložení obrazovek byla téměř identická, a ikony stejné. Jediné v čem se grafika lišila, bylo několik tlačítek zvýrazněných nápisem, bez kterých se uživatel, který tento software dříve nepoužíval, obejde.
Samozřejmě aplikace používaná ve škole s trochu lišila, protože nebyla uzpůsobena žádnému konkrétnímu zákazníkovi a měla zpřístupněnu většinu funkcí (možná všechny), protože byla určena pro účely výuky.
9.2 Zoner Inshop
Další aplikace poskytovaná formou ASP byl elektronický obchod. Obchod běží na serveru poskytovatele, a uživatel k němu má přístup pomocí správcovské aplikace, kterou si nainstaluje na svém počítači připojeném k internetu. Správcovská aplikace umožňuje dostatečně mnoho nastavení pro kustomizaci obchodu. S použitím předinstalovaných šablon je možné upravit i vzhled obchodu. Pokud chce uživatel udělat zásadnější úpravy ve vzhledu obchodu je možné vytvořit si podle příručky šablonu vlastní, nebo nějakou přepracovat a uzpůsobit si ji dle vlastních představ. V aplikaci je také možné nastavit jaké způsoby platby a dodání zboží budete nabízet a další základní nastavení potřebná pro bezproblémový provoz obchodu.
10 Závěr
Ukázal jsem, že ASP je pro malé a střední podniky rozhodně zajímavou příležitostí, jak s co nenižšími počátečními náklady, získat kvalitní aplikace. Je to model, který je v některých zemích podporován vládními projekty, protože ho i vlády považují za nástroj, který může zvýšit výkonnost ekonomiky tím, že pomůže překonat SME potíže při získávání zdrojů na vývoj a provoz dnes již takřka nepostradatelných informačních systémů.
Dále jsem ukázal, že se tento model stále vyvíjí a že se poskytovatelé aplikačních služeb snaží dovést aplikace do stavu, aby se daly integrovat s jinými aplikacemi a aby se daly přizpůsobit konkrétním požadavkům uživatele.
11 Seznam použité literatury
[KRT04] M. Krt, Výzkum českého trhu „Nabídka ERP formou ASP“, 2004 [VIT01] M. Vít, Jan Pavelka, Analýza Trhu ASP v ČR, 2001
[VIT04] M. Vít, Zákaznické metriky v modelu ASP, VŠE 2004
[UCEN01] P. Učeň a kol., Metriky v informatice. Jak objektivně zjistit přínos IS.
Grada 2001
[PISTOLE05] Linda.L.Pistole , A.W.Bragg, Making IT outsourcing work for smaller enterprises, IT Pro 2005, http://doi.ieeecomputrsociety.org/10.1019/MITP.2005.92
[KIM05] Han-joon Kim, Ki Hun Paek, Promoting the Application Service Provision (ASP) model, IEEE 2005 http://doi.ieeecomputersociety.org/10.1109/DEEC.2005.20
[PAEK04] Ki Hun Paek, SP-based e-Business Project for Small Business, European E- Business Support Network Workshop, 2004
[OECD04] OECD, ICT Diffusion to Busines, Peer Review, Country Report: Korea 2004
[VORISEK02] J.Voříšek, G. Feuerlicht, Delivering Application Services: Who will Benefit? http://nb.vse.cz/~vorisek/texty.htm
[VORISEK02b] J.Voříšek, G. Feuerlicht, Na cestě k ASP, 2002 http://nb.vse.cz/~vorisek/texty.htm
[SLAZ] Service Level Agreement Zone, 2002 http://sla-zone.co.uk/
[ISACA] IS Auditing Guidelines for Outsourcing of IS Activities to Otrhe Organizations,2000 http://www.isaca.org/
[STUART03] A. N. Stuart:“Hardware down, humans up“, CFO magazine, 1Feb 2003, http://www.cfo.com/article.cfm/3008174/c_3036063
12 Slovníček zkratek a pojmů
ASP – Application Service Providing, Poskytování aplikačních služeb SME – Small and Medium Enterptises, malé a střední podniky
SLA – Service Level Agreement, Dohoda o úrovni služeb CRM – Customer Relationship Management
SCM – Supply Chain Management ERP – Enterprise Resource Planning ASW – Aplikační software
SOAP (Simple Object Access Protocol) - XML protokol 2. generace překonává slabiny předchozích dvou. Prostřednictvím mechanismu jmenných prostorů (XML Namespaces) je snadno rozšiřitelný. Kvůli podpoře binárních dat byl definován i protokol SOAP s attachementy.
UDDI - Universal Description, Discovery and Integration – Na standardech založený přístup k implementaci registru služeb.
XML - eXtensible Markup Language je značkovací jazyk obsahující příkazy definující syntax (strukturu) dokumentu, definovaný doporučením W3C (WWW Consortium).
