Řízení informatických služeb dle MMDIS

1. Řízení informatických služeb dle MMDIS Jiří Voříšek katedra IT, VŠE vorisek@vse.cz nb.vse.cz/~vorisek

2. ICT služby v podniku

3. Nutnost nového stylu řízení IS/ICT • růst závislosti podniku a jeho konkurenceschopnosti na IS/ICT • růst výdajů do IS/ICT - problémy s návratností investic • architektury a řízení IS/ICT jsou neustále komplikovanější • starost o IS/ICT odvádí často podnik od jeho hlavního předmětu podnikání (viz cíl: zavést nový ERP) • ICT nepřináší efekty samo o sobě, ale vhodným spojením s podnikovými procesy • je potřebné vytvořit interface mezi řízením podnikových procesů a řízením informatiky • východisko  řízení IS/ICT na bázi služeb – souvisí se změnou podnikové kultury (primární je pomoc lidem, technologická excelence může být nástrojem)

4. Cíle řízení IS/ICT dle služeb • zajistit lepší vazbu IS/ICT na podnikové procesy a větší flexibilitu IS/ICT vůči změnám v požadavcích uživatelů • zákazník dostane ty služby, které si objednal (ani ne méně ani více) – eliminace nepotřebného • definovat, standardizovat, customizovat a integrovat informatické služby • řídit dodávku škálovatelných informatických služeb (SLM) • zprůhlednit náklady poskytovaných služeb, umožnit jejich přeúčtování uživatelským útvarům (procesům) a umožnit tak detailnější posuzování nákladů IS/ICT • připravit podmínky pro srovnání s eventuálním outsourcingem informatických služeb

5. Model SPSPR metodiky MMDIS

6. Výchozí konceptuální model - SPSPR

7. Struktura manažerů a jejich zodpo-vědností

8. Cíle modelu • zprůhlednění způsobu dekompozice podnikových cílů až na úroveň řízení provozu IS/ICT, • přesně vymezit zodpovědnosti různých typů manažerů v jejich vztahu k IS/ICT – oprostit interface byznys – ICT od technologických a implementačních detailů • vytvoření schématu, ze kterého je možné odvodit vhodné metriky úspěšnosti jednotlivých typů procesů a za ně odpovědných manažerů.

9. Otázky SPSPR modelu • je vhodné/nutné definovat architekturu ICT služeb? Nevystačíme s informační a aplikační architekturou? • je SPSPR model aplikovatelný i pro podniky, které nejsou procesně řízeny a nemají byznys procesy definovány ?

10. Kategorie ICT služeb

11. ICT služba - definice • ICT služba: = koherentní aktivity a/nebo informace dodávané poskytovatelem ICT služby příjemci služby. ICT služba je vytvářena ICT procesy, které při svém průběhu konzumují ICT zdroje (hardware, software, data, lidé atd.). Služba se realizuje na základě dohodnutých obchodních a technických podmínek. • obchodní a technické podmínky by měly odpovědět na otázky: • komu a kde bude služba poskytována, • kým bude služba poskytována, • co je předmětem služby, • jak bude služba poskytována, • jaký bude objem poskytované služby (počet oprávněných uživatelů, objem předávaných/zpracovávaných dat apod.), • jaké budou kvalitativní charakteristiky poskytované služby (dostupnost, doba odezvy, spolehlivost, stáří předávaných dat apod.), • jaká bude cena poskytované služby (plus případné bonusy/malusy za překročení/nedodržení sjednané kvality služby poskytovatelem), • jakými znalostmi a/nebo technologiemi musí disponovat příjemce služby, aby mohl službu konzumovat. • detailněji – viz SLA

12. Proč kategorizovat ICT služby a proč hovořit o architektuře ICT služeb • ITIL, COBIT a CMMI zaměřeny především na ICT procesy (jejich kvalitu, zralost, efektivnost atd.). O tom jak strukturovat ICT služby a jak vytvářet architekturu ICT služeb se v těchto přístupech moc nehovoří individuální přístupyke strukturaci a granularitě služeb pomalá standardizace služeb  obtíže při nákupu služeb na trhu • různé služby vyžadují různá SLA • návrh architektury služeb na základě standardizovaných ICT služeb zprůhledňují katalog služeb pro tvůrce i pro zákazníky

13. Typy ICT služeb • „ ICT služby byznysu (koncovým uživatelům) • informační • aplikační • infrastrukturní • podpůrná • ICT služby rozvoje IS/ICT • vývoj SW • implementace SW • integrace IS • rozvoj technologické infrastruktury • poradenství • …

14. Typy ICT služeb (kategorizace dle předmětu služby) • informační služba • Informační službou dodává poskytovatel zákazníkovi požadovanou informaci, resp. data (např. stav kurzů na burze cenných papírů, předpověď počasí, mapu požadované lokality, knihu, fotografii, audionahrávku, film) • Informace je dodána v požadované struktuře, formátu a čase • I když dodaná informace může být produktem softwarové aplikace, tak funkcionalita aplikace je pro zákazníka služby nepodstatná • Specifikou některých informačních služeb je, že se na ně vztahuje autorský zákon, který omezuje uživatele služby, jak může s poskytnutou informací nakládat • Snadná replikace s nízkými náklady • Poskytovatel služby odpovídá za správnost a aktuálnost dodaných informací

15. Typy ICT služeb (kategorizace dle předmětu služby) 2. aplikační služba • Předmětem aplikační služby je funkcionalita softwarové aplikace (např. účetnictví, CRM, e-mail, vyhledávač atd.) • Poskytovatel tuto aplikaci provozuje na vhodné ICT infrastruktuře a zákazník užívá funkcionalitu aplikace • Data, která aplikace zpracovává jsou buď výhradně zákazníka (účetnictví, CRM), nebo provozovatele (vyhledávač typu Google). Může se ale jednat i o kombinaci dat poskytovatele a zákazníka (Google Earth s objekty označenými zákazníkem) • Poskytovatel služby odpovídá za správnost transformace dat, majitel dat (ten kdo data vkládá) odpovídá za správnost vstupních dat • Funkcionalita aplikace realizuje jednu nebo více aktivit podnikového procesu - dva podtypy • služba podporuje určitý podnikový proces • služba realizuje celý podnikový proces (internet banking) • Je často dodávána v balíčku s podpůrnými službami bezprostředně s aplikací spojenými (např. školení uživatelů aplikace, help desk, customizace, drobné změny aplikace).

16. Typy ICT služeb (kategorizace dle předmětu služby) • infrastrukturní služba • Předmětem infrastrukturní služby je vybudování a provoz ICT infrastruktury (servery, koncové stanice, sítě LAN a WAN, operační systémy, databázové systémy, monitorovací systémy atd.) potřebné pro bezchybný chod aplikace nebo aplikací • tyto služby také mohou manipulovat s daty, ale pouze ve smyslu transferu a uložení dat, nikoliv ve smyslu změny obsahu dat • Do infrastrukturních služeb patří pořizování nového HW/SW, upgrade HW/SW, budování a rozšiřovaní síťové konektivity, řešení poruch a výpadků atp. • Dělí se obvykle do dvou skupin: • koncové stanice • ostatní infrastruktura - je obvykle „neviditelná“ uživatelům, její náklady jsou rozpočítány do aplikačních služeb

17. Typy ICT služeb (kategorizace dle předmětu služby) 4. podpůrné služby • doprovodné služby, které jsou potřebné / vhodné pro zajištění služeb informačních, aplikačních a infrastrukturních • jedná se zejména o školení, customizaci a integraci aplikací, služby help desku, služby poradců při tvorbě kontraktů nebo při realizaci výběrového řízení.

18. Typy ICT služeb (kategorizace dle předmětu služby) 5. služby rozvoje IS/ICT • zahrnují vývoj / dodávku požadovaného software nebo ICT infrastruktury • řeší se klasickým informatickým projektem s definovaným cílem, rozpočtem a dobou řešení • na každý projekt uzavřena samostatná smlouva definující podíl případného ext. dodavatele, informatického útvaru a uživatelského útvaru na projektu • po ukončení projektu se překlápí do ICTslužby byznysu Pozn: při outsourcingu charakter služby nabývají i externí dodávky procesů a zdrojů

19. Životní cyklus ICT služeb

20. ITILv3: IT Service Life Cycle SERVICE DESIGN • Service Catalog Management • Service Level Management • Supplier Management • Capacity Management • Availability Management • IT Service Continuity Management • Information Security Management SERVICE STRATEGY • Service Strategy • Service Portfolio Management • Financial Management • Demand Management SERVICE TRANSITION • Transition Planning and Support • Change Management • Service Asset & Configuration Management • Release & Deployment Management • Service Validation • Evaluation • Knowledge Management SERVICE OPERATION • Event Management • Incident Management • Problem Management • Request Fulfillment • Access Management CONTINUAL SERVICE IMPROVEMENT • Service Measurement • Service Reporting • Service Improvement Zdroj: ITIL-v3 – The introduction to the ITIL service lifecycle

21. Životní cyklus ICT služeb dle MMDIS Strategie architektura služeb – integrace – standardizace - „balíčkování“ služeb - sourcing identifikace potřeby a její deskripce definice služby, návrh/design služby, vytvoření/sestavení služby, testování služby, přizpůsobení (customizace), nákup/prodej, instalace/nasazení služby, zahájení provozu/aktivace, provoz a dodávání služby konkrétnímu zákazníkovi včetně podpůrných služeb ke službě se vázajících, monitoring a řízení kvality dodávané služby, škálování, údržba/modifikace/kontinuální zlepšování služby, zpoplatnění, ukončení provozu.

22. Operace nad službami Operace nad jednou službou • definice služby (sběr požadavků, dimenzování služby vůči byznysu, popis služby pomocí SLA), • návrh služby (analyzuje požadavky, jejich dopady na ICT procesy a zdroje a navrhuje způsob realizace služby, tj. ICT procesy a ICT zdroje, které budou službu produkovat), • realizace (vytvoření aplikací, technologické infrastruktury a ICT procesů), • nákup/prodej (uzavření smlouvy včetně případné modifikace parametrů SLA), • přizpůsobení/customizace (úprava standardní služby tak, aby odpovídala požadavkům konkrétního zákazníka), • instalace služby (tj. instalace aplikace, technologické infrastruktury, ICT procesů, změny byznys procesů, změny organizace a podnikových předpisů, instalace znalostní databáze, školení provozovatelů a uživatelů), • testování služby - ověřování, správnosti aplikací a procesů a správného dimenzování zdrojů, kontrola, zda služba má kvalitativní charakteristiky, jak byly popsáno v SLA

23. Operace nad službami Operace nad jednou službou • zahájení provozu (zkušební a ostrý provoz), • provoz a dodávání služby konkrétnímu zákazníkovi , provoz aplikací, technologické infrastruktury a podpůrných služeb; řešení incidentů a problémů, měření hodnot metrik, vykazování hodnot metrik zákazníkům, • monitoring a řízení kvality dodávané služby (dostupnost, doba odezvy, spolehlivost, bezpečnost), • škálování (řízení objemu služby a kapacit zdrojů nutných pro její zabezpečení), • údržba/modifikace/kontinuální zlepšování služby (řízení změn služby, instalace nových verzí SW, změny technologické infrastruktury, rozvoj znalostní databáze a znalostí provozovatelů a uživatelů), • zpoplatnění (určení cenového modelu služby, účtování služeb), • ukončení provozu.

24. Operace nad službami Operace nad všemi službami • strategie služeb (plánování rozvoje služeb jako součásti informační strategie), • architektura služeb (určení služeb, které budou zahrnuty do aktuálního katalogu služeb a určení jejich vzájemných vazeb), • sourcing služeb (rozhodnutí, které služby budou zajišťovány interně a které budou nakoupeny od externích poskytovatelů), • integrace služeb (řízení vzájemných vazeb služeb, řízení aplikací a ICT infrastruktury sdílené více službami), • standardizace služeb (sloučení několika podobných služeb do jedné služby, sjednocování/unifikace ICT procesů a ICT zdrojů zajišťujících různé služby), • „balíčkování“ služeb (balíček služeb je nabízen a zpoplatněn jako jeden celek).

25. Architektura ICT služeb

26. Architektura ICT služeb podniku– místo v hierarchii architektur

27. Architektura ICT služeb – vymezení • Systém =~ IS • Komponenta =~ informatická služba • inf. služby se přiřazují k: • jednotlivým typům uživatelů služeb - veřejnost, partneři, zákazníci, zaměstnanci • jednotlivým podnikovým procesům, na jejichž podporu služby slouží • jednotlivým aplikacím, které zajišťují funkcionalitu služby (vazba GA a aplikační architektury)

28. Architektura ICT služeb – vymezení • katalog služeb (id, název služby, typ služby, stav služby - plánovaná, v provozu) • typy služeb: informační, aplikační, infrastrukturní, podpůrná, smíšená • parametry každé služby • efekty a jejich metriky • zákazník (proces, útvar, partner, veřejnost,…) • dodavatel • obsah – funkcionalita, školení, služby help desku,… • objem – počet uživatelů, objem dat, počet transakcí,… • kvalita – dostupnost, doba odezvy, spolehlivost, bezpečnost,… • cena (neměla by být větší než efekty služby) • vazby mezi službami • klíčová data vyměňovaná mezi službami a čas/událost předání • časová posloupnost uvedení služeb do provozu Klíčové parametry pro návrh dílčích architektur

29. Cíle architektury služeb • Cíle u uživatelské organizace • zajistit (interně či externě) všechny služby, které jsou požadovány podnikovými procesy a tyto služby navzájem integrovat • Cíle u dodavatelské organizace • nabízet a dodávat takové portfolio integrovaných služeb, takovému segmentu zákazníků a v těch teritoriích, které přinese nejvyšší zisk

30. Doporučení pro architekturu aplikačních služeb v uživatelské organizaci • Existují tři varianty postupu při strukturaci služeb: • aplikační služby korespondují se strukturou podnikových procesů (resp. činností) • aplikační služby korespondují se strukturou software, který je pro zajištění služeb použit (dle sw balíků) • aplikační služby korespondují se základními typy uživatelů (partneři, zákazníci, top mng,…) a se strukturou útvarů podniku (pro interní uživatele) • Při tvorbě služeb je vhodné vzít v úvahu všechny možnosti.

31. Výhody a nevýhody variant Služby podle procesů (extrémní situace: pro každý podnikový proces jedna služba) + nejvyšší provázanost s podnikáním (s věcnou oblastí procesu) + služby se budou vyvíjet a měnit dle změn v byznysu a ne dle změn v technologii (jakým SW je služba zajištěna) a také ne dle změn v organizační struktuře firmy + jasně odděluje architekturu služeb od aplikační architektury - duplicity v obsahu služeb - složitější rozpočet zdrojů a reporting, pokud je jedním aplikačním SW podporováno více procesů - nemusí korespondovat se strukturou služeb dostupných na trhu (viz klasické ERP). + naopak koresponduje se službami dle SOA Proces

32. Výhody a nevýhody variant Služby podle SW instalovaného a dostupného na trhu (co SW komponenta, to služba) • nejčastěji používaná varianta, vhodná zejména v případě standardizovaného SW (PAM, účetnictví, zákazníci, dodavatelé, fakturace, MTZ, prodej, majetek, sklady, výroba, CAD/CAM, OIS, E-mail, internet, intranet, …) + snadné nalezení odpovídající služby na trhu – vhodná podmínka externího zajištění služby: nabídka služby od více subjektů na trhu (snižuje závislost zákazníka na poskytovateli) + snadné určení hranic služeb (minimální nebo žádné duplicity v obsahu služeb) + snadné reportování + koresponduje s chápáním služeb uživatelů i informatiků - když strukturace dle konkrétních produktů - do businessu se promítne technologie a strukturace problému konkrétním dodavatelem  vhodnější je strukturace generalizací obdobných produktů na trhu - uživatelé i pracovníci podnikové informatiky se dívají na službu očima dodavatele SW – např. požadavky na úpravu funkcionality směřují ke konkrétnímu SW, i když z architektonického pohledu by řešení jiným SW bylo výhodnější

33. Výhody a nevýhody variant Služby podle typů uživatelů a dle organizace (co typ uživatele to služba) + aplikační služba je na míru sestavena pro příjemce a tím je pro něj snadno pochopitelná, + tato varianta je nejméně konfliktní při prosazování v aktuální organizační struktuře, + každý příjemce platí pouze za jednu službu - služby budou brzdou při každé reorganizaci – petrifikace org. struktury • značné duplicity v obsahu služeb • problémy s účtováním služeb Aplikovatelné zejména u velkých firem, kde lze např. definovat 3 úrovně SLA (korporátní – služba stejná ve vše lokalitách, skupinová – služba shodná pro řadu útvarů, specifická)

34. 1 transakce= 1 služba Granularita aplikačních služeb - jak jemně či hrubě jsou služby strukturovány Jemná granularita – např. při procesní strukturaci služby korespondují s jednotlivými činnostmi podnikového procesu Př: rezervace letenky, hotelu, zájezdu (viz fa Sabre); Při definici jemně granulovaných služeb je vhodné využít principy abstraktních datových typů, resp. objektového přístupu • + lze s výhodou využít SOA a web services • + malé nároky na customizaci a integraci • -+ služba neobsahuje procesní „best pratice“, tj. propojení služby na podnikový proces je samostatným problémem se službou přímo nesouvisejícím • + unikátní „sešití“ takových služeb a jejich zkombinování s podnikovým procesem může přinést konkurenční výhodu • - pro systémy s rozsáhlou standardizovanou funkcionalitou (viz ERP, OIS) přináší příliš pracné a nákladné řízení takto jemně strukturovaných služeb

35. 1 modul ERP = 1 služba Granularita aplikačních služeb Hrubá granularita – služba zahrnuje velký objem funkcionality obvykle včetně procesního best-practice Př: Finance (modul FI SAP R3), CRM (od SalesForce) • + výsledek strukturace je malý počet dobře řiditelných služeb • + pro zabezpečení služby lze s výhodou využít standardizované SW balíky • - vysoké nároky na customizaci a integraci v případě, že podnik má unikátní procesy

36. Granularita aplikačních služeb • cíl architektury ICT služeb - vhodná volba mezi jemnou a hrubou granularitou aplikačních služeb • kritéria: • míra znovupoužitelnosti služby • jednotnost SLA pro uživatele služby • stabilita služby (nízké nároky na údržbu/rozvoj) • granularita ICT služby musí odpovídat rozlišovací úrovni, kterou používá úroveň řízení, která je zodpovědná za řízení procesu, ve kterém se ICT služba využívá

37. Architektura ICT služeb – interní vers. externí služby • pro poskytovatele služeb může být výhodné odlišit konkrétní dohodnuté služby a standardní interně zajišťované služby • na standardní služby jsou nastaveny interní IT procesy • dohodnuté služby vzniknou kombinací a parametrizací (zejména objem, kvalita) interních služeb (např. pro zjednodušení vykazování i řízení IT může být výhodné malému zákazníkovi dodat službu kvalitnější ale standardní než méně kvalitní, ale nestandardní) • pozor ale na velké množství „vrstev“ služeb – dodavatel každé vrstvy si vytváří „objemový a kvalitativní buffer“ a buffery jednotlivých vrstev se sčítají a mohou vést k až k nesmyslným požadavkům na základní HW, SW a lidské zdroje

38. Děkuji za pozornostOtázky ?