Z V L Á Š T N Í N E P R O D E J N Á P Ř Í L O H A | Ř Í J E N 2 0 1 4

Nové výzvy systémové integrace Jak řízení IT ovlivňuje konkurenceschopnost Srovnání ITIL, ISO 20000 a COBIT

Systémová integracea řízení IT

2014

SI_2014_235x297.indd 17 10/17/14 4:30 PMCW17-II-VIII.indd ICW17-II-VIII.indd I 17.10.14 16:4617.10.14 16:46

II CO M P U T E RWO R L D 17–18 | 2014

SYSTÉMOVÁ INTEGRACE A ŘÍZENÍ IT

Nové výzvy systémové integraceSystémová integrace neustále prochází vývojem a procesem přizpůso-bování měnícím se vnějším podmínkám. Musí reagovat na zrychlování, zjednodušování a zmenšování, na zavádění nových technologií i na poža-davky na výměnu nebo odstranění části podnikové informatiky.

VÍT PETRJANOŠ

V dnešní éře zrychlování, agility, zjednodu-šování a zmenšování se samotná podstata systémové integrace nemění. Postupně se

však mění nástroje, s nimiž integrátor pracuje, i jeho kompetence. Podniky opouštějí dogma-tické vodopádové pojetí vývoje informačních sy-stémů a požadují po integrátorech flexibilně na-stavitelnou IT architekturu.

Podle Tomáše Rutrleho, jednatele společnosti Komix, se podoba systémové integrace postupně mění. Tradiční systémová integrace představuje propojení mezi hardwarovými a softwarovými komponentami různých dodavatelů takovým způsobem, aby celek fungoval bezchybně a plnil požadované funkce.

Tradiční solidní přístup k integraci, založený na technologické kompetenci, se však dnes musí vypořádat se světem, v němž je část řešení dodá-vána „as a service“, ve kterém je extrémní tlak na návratnost a v němž byznys požaduje dodávku řešení okamžitě a přínosy vzápětí.

„Systémová integrace musí nutně změnit své me-todické postupy a ‚best practices‘. Položím -li otázku, jak integrovat firemní ERP s cloudovým CRM a oba dohromady pak s právě vyvíjeným mobilním zákaz-nickým portálem, je kriticky důležitá právě znalost metodiky a správného postupu,“ upozorňuje Ru-trle. Právě na této znalosti musí podle něj systé-moví integrátoři dlouhodobě stavět, přičemž konkrétní technická řešení se budou v čase prav-děpodobně rychle měnit.

„Role integrace je z určitého pohledu stále stejná, ale mění se nástroje, se kterými integrátor pracuje. Zákazníci od integrace očekávají stále stejné a jediné, že se jim ‚postará‘ o dodávku infor-mačního systému v kvalitě, kvantitě, termínu a roz-počtu,“ uvádí Lukáš Zrzavý, provozní ředitel Uni-corn Systems.

Zkracování času dodávky, snižování rozpočtů a více vzájemně integrovaných systémů se dnes berou jako vstupní parametry pro dodavatele úplně stejně jako požadavky na funkčnost nebo výkon požadovaného informačního systému. Je úkolem integrátora se se všemi těmito poža-davky správně vypořádat, soudí Zrzavý a dodává, že často je úkolem integrátora také „přesvědčit“ investora (čili zákazníka) o chybných a proti-chůdných požadavcích.

„Dobrý integrátor musí zvládnout každé zadání. A k jakémukoli zadání existuje dobré řešení, ale ně-kdy je náročné dokázat, že navrhované řešení je pro zákazníka nejvhodnější,“ tvrdí Zrzavý.

Radek Moc, ředitel řešení a služeb společ-nosti T -Mobile, je přesvědčen, že základní a obecná role systémové integrace – řešit pro-blémy svých zákazníků, přinášet jim úspory, zvy-šovat jejich efektivitu, pomáhat a umožňovat jim plnění jejich obchodních cílů – zůstává stále ne-změněna. Nicméně jednotlivé kompetence, jak tuto roli naplňovat (ať už jde o analýzu, vývoj nebo integraci), se samozřejmě velmi dynamicky mění ruku v ruce s technologickým vývojem.

„Systémový integrátor dneška musí počítat s tím, že aplikace mohou běžet prakticky kdekoliv, že je-jich vzájemná integrace by měla být definována standardními rozhraními, že zobrazovací a ovlá-dací zařízení uživatele již není pouze počítač s mo-nitorem a klávesnicí a podobně,“ konstatuje Moc. Pokud systémový integrátor nedokáže na tyto a v budoucnu i na další trendy reagovat, pří-padně se přímo podílet na jejich tvorbě, nemůže být podle Moce dlouhodobě úspěšný.

Podle Jakuba Skořepy z Deloitte Advisory je jednou z možností, jak skloubit požadavky na zrychlování a zjednodušování a zmenšování, opuštění dogmatického vodopádového pojetí vý-voje informačních systémů a využití inovativ-ních přístupů, jako jsou například agilní vývoj, prototypování nebo extrémní programování. Další možností, respektive úlohou systémové integrace je zajistit výběr, nasazení a integraci balíkových nebo nyní i cloudových softwarových řešení, která nejlépe a s minimem zákaznických úprav podporují podnikové procesy.

V koncepční rovině systémové integrace lze vysledovat snahy o budování (nebo výběr existu-jících) flexibilních integračních vrstev pro řízení byznys logiky. Tím lze urychlit splnění nových obchodních požadavků i vývoj dalších produktů či jejich parametrizaci při zachování běžných požadavků na integraci, bezpečnost atd. Dodava-telé softwarových řešení na tento trend reagují návrhem, vývojem a nabídkou řešení, která jsou již předintegrovaná a uživatelsky snadno konfi-gurovatelná, připomíná Skořepa.

Systémoví integrátoři primárně odbourávají přebytečnou administrativu během dodávek sy-stémů a využívají vhodné metody realizace kon-krétních druhů dodávky. Zároveň je ale správně zvládnutá schopnost systémové integrace, která vede k flexibilně nastavené IT architektuře zalo-žené na službách, základním stavebním kame-nem, jenž tyto efekty umožní, říká Marek Zoth, manažer v oddělení IT poradenství společnosti KPMG Česká republika.

Aby firma mohla přejít na flexibilní IT archi-tekturu, měla by postupně a koncepčně měnit celkovou IT architekturu, nikoliv se omezovat jen na aktuálně měněné systémy. Investice do budování konceptu flexibilní IT architektury nemají přímou finanční návratnost, ale výrazně zrychlí a zlevní integraci nových komponent a realizaci změn, upozorňuje Zoth.

Inovace něco stojíInovativní, dosud neodzkoušené informační a komunikační technologie mohou výrazně zvý-šit výkonnost, při nesprávném zavedení však mohou fungovat jako časovaná bomba a způsobit velké až fatální škody. Systémová integrace se musí s nástrahami těchto technologií efektivně vypořádat.

„Systémová integrace se s novými technologiemi potkává dnes stejně jako před deseti či dvaceti lety. A nebude tomu asi jinak ani v budoucnu,“ soudí Zrzavý z Unicorn Systems a dodává: „Je přiro-zené, že při návrhu nových informačních systémů se používají technologie osvědčené i méně vyzkou-šené či úplné novinky.“

Dobrý integrátor podle Zrzavého posuzuje ri-zika dodávky informačního systému z několika úhlů pohledu. Jedno z těchto hledisek je pohled „přes technologie“, jenž si klade otázku: Je po-užitá technologie dostatečně ověřená vzhledem k situaci, ve které bude použita? Pokud ne, musí se vytvořit prototypy a vše odzkoušet.

Pro klíčové části/funkčnosti informačního sy-stému však vhodný prostor pro „zkoušení“ no-vých technologií mnohdy ani neexistuje. Naopak v méně kritické části, kde nová technologie může přinést podstatné úspory, se vyplatí po od-zkoušení na prototypech technologii nasadit. Je třeba vždy dobře zvážit rizika, a to je role inte-grátora společně s investorem, nabádá Zrzavý.

Systémová integrace může nástrahám nových technologií čelit tak, že se promění v konti-nuální proces, který nesměřuje k předem defino-vanému stavu, nýbrž postupuje od milníku k milníku, tak jak postupně získává zkušenosti s adopcí nové technologie. Standardní jsou formy pilotních či jinak omezených projektů, které ověří nejen technické řešení konkrétní no-vinky, nýbrž i její přínos pro byznys, říká Rutrle z Komixu.

Skořepa z Deloitte Advisory souhlasí s tím, že implementace dosud neodzkoušených a ino-vativních řešení představuje významná rizika, která je nutné znát a řídit. Podniky si uvědomují, že maximálního tržního a obchodního potenci-álu nových technologických inovací lze využít je-jich včasnou adopcí, přičemž upravují běžné po-stupy jejich nasazování.

V úvodních fázích je akceptováno vyšší riziko spojené s neúspěšnou implementací a zmařením takové investice. Pro zavádění těchto řešení se

CW17-II-VIII.indd IICW17-II-VIII.indd II 17.10.14 16:0217.10.14 16:02

CO M P U T E RWO R L D.C Z III

SYSTÉMOVÁ INTEGRACE A ŘÍZENÍ IT

vytvářejí oddělené realizační struktury, financo-vání a infrastruktura. Implementaci často při-pravuje úzký řešitelský tým za využití agilních přístupů s cílem ověřit jeho potenciál. Proble-matické aspekty, jako např. provozní, integrační a realizační, jsou řešeny až v pozdějších fázích projektu, popisuje Skořepa postupy při nasazo-vání nových technologií a doplňuje: „Předpo-klady úspěchu tohoto přístupu závisejí na rozsahu požadované integrace s existujícím informačním sy-stémem a bývají významně podmíněny i možnostmi využití existujících integračních technologií.“

Pavel Dostál, technický ředitel GEM System, poznamenává, že volná vazba systémové inte-grace dovoluje velmi pružně reagovat na nové technologie. Na druhou stranu nové technologie často již obsahují implementaci řady standardů integračních rozhraní, které dovolují snadné za-členění do existujících systémů.

Cílem systémové integrace je flexibilní, ser-visně orientovaná IT architektura, která umožní snadnější integraci jakýchkoliv, tedy i nových a neodzkoušených komponent a technologií, po-dotýká Zoth z KPMG. Firmy musí zohledňovat míru přínosů a rizik vyplývajících z použití tako-vých technologií a v rámci své organizace vytvo-řit mechanismy, které identifikují vhodné příle-

žitosti pro aplikaci těchto technologií nejprve v omezeném rozsahu a po úspěšném ověření i v širším měřítku.

Jak na rizikaNěkteré české firmy jen nerady akceptují rizika vyplývající z rychlého spuštění integrovaných sy-stémů a snaží se je přesunout na dodavatele. Často totiž nemají vhodné schopnosti a znalosti. Naproti tomu při nasazování méně kritických systémů mnoho organizací riziko podceňuje.

Někdy je dobré si vzpomenout, že v dobách, kdy systémy nebyly centralizované a nasazení sy-stému znamenalo u velkých podniků, bank či pojišťoven instalaci na desítky či stovky serverů a stovky či tisíce pracovních stanic na všech po-bočkách, nasazení systému obvykle nebylo ma-nagementem tolik podceňováno jako dnes, při-pomíná Zrzavý z Unicorn Systems.

„Všichni tak nějak ‚tušili‘, že jde o významnou akci, a věnovali jí náležitou pozornost. Současná centralizovaná řešení, která se nasazují ‚přes noc‘ a jsou jako mávnutím kouzelného proutku následu-jící pracovní den dostupná všem pracovníkům na všech pobočkách, vedou k podcenění rizik souvisejí-cích s nasazením informačního systému,“ upozor-ňuje Zrzavý.

Firmy jsou v tomto ohledu velmi pragmatické a snaží se posunout maximum rizik na dodava-tele, podotýká Rutrle z Komixu. V době ostrého konkurenčního boje se jim to často podaří, a firmy tak ztratí motivaci podnikat proti hrozí-cím rizikům odpovídající protiopatření. Což je přístup poněkud krátkozraký, soudí Rutrle.

V Deloitte Advisory mají s akceptací takových rizik různé zkušenosti. Jak poznamenává tamní manažer Štěpán Jaroch, společnosti si stále více uvědomují významnost řízení rizik a dopadů vy-plývající z neúspěšných implementací, avšak mnohdy nemají vhodné znalosti a schopnosti ta-kové situace vyhodnocovat nebo jim předcházet.

„V případě tlaku na rychlé spuštění klíčového systému nebo systému s vysokou mírou integrace není management ochoten bez řádné validace poža-dovaných funkcí, verifikace cílů a účelu implemen-tace takové riziko akceptovat,“ uvádí Jaroch.

Na druhou stranu u méně kritických systémů dochází k urychleným spuštěním informačních systémů často – a mnohdy bez hlubšího pocho-pení možných rizik (mnohdy významných a skrytých) a bez jejich detailnějšího porovnání s potenciálními přínosy.

„V obou případech jsme však často svědky pro-blémů s úpravou interních provozních postupů

Inzerce

▶

CW17-II-VIII.indd IIICW17-II-VIII.indd III 17.10.14 16:0217.10.14 16:02

IV CO M P U T E RWO R L D 17–18 | 2014

SYSTÉMOVÁ INTEGRACE A ŘÍZENÍ IT

Dobré řízení IT přispívá ke konkurenceschopnostiŘízení IT může ovlivnit výkonnost podniku, kvalitu a prodejnost jeho výrobků a služeb a zákaznickou spokojenost. S tím přímo souvisejí propojenost IT služeb a procesů s byznys procesy a potřeba uvést do souladu procesně orientované standardy pro řízení výkonnosti podniku a liniovou organizaci podnikových útvarů.

VÍT PETRJANOŠ

Kvalita řízení podnikového IT, jeho spolehli-vost, rychlost, flexibilita a náklady mohou výrazně ovlivnit základní podnikatelské

cíle. Pokud chce IT útvar k dosahování těchto cílů efektivně přispívat, musí především zajistit koncepční rozvoj ICT, ideálně pomocí IT strate-gie orientované na byznys. Jedním z klíčových předpokladů je i pravidelné zapojení IT do pří-pravy nových služeb a výrobků.

Kvalitou a spolehlivostí myslíme převážně provozní kvalitu z pohledu dostupnosti IT slu-žeb, říká Radek Moc, ředitel řešení a služeb ve společnosti T -Mobile. Rychlost znamená schop-nost rychle dodat na trh nové produkty, resp. neustále zlepšovat podnikové procesy, které firmě umožní obstát v konkurenčním prostředí. Flexibilitou se míní převážně schopnost IT pružně reagovat na poptávku nových produktů, služeb a byznys procesů na velmi dynamickém ICT trhu. Nízké náklady umožní firmě také marže, které jsou akcionářem očekávány.

„Z výše uvedeného může vyplynout, že flexibi-lita a rychlost mohou jít proti spolehlivosti a kva-litě,“ upozorňuje Moc. Tento „rozpor“ se dá pře-konat budováním tzv. dvourychlostní IT organi-zace, kde se na standardní dodávky používá kva-litní vodopádová metoda vývoje, zatímco tam, kde se vyžaduje flexibilita a rychlost, se uplatní agilní metody.

„Vždy záleží na typu podnikání. Některé společ-nosti mají stabilní byznys model a bude pro ně zá-sadní spíše provoz služeb, u něhož je již řada IT na slušné úrovni,“ uvádí Aleš Studený, ředitel slu-žeb ve firmě Alvao. Kromě toho existují dyna-mičtější společnosti, kde větší úlohu hrají pro-cesy nasazení nových IT služeb nebo vylepšení současných. Tyto procesy jsou už složitější a vy-žadují silnější propojení na byznys.

V dnešní době je důležité hledat nové IT služby, které zvýší prodejnost, nikoliv pouze ušetří náklady. Byznys zajímá zvýšení objemu prodeje u existujících zákazníků nebo získání nových. IT může například nabídnout integraci systémů na sociální sítě nebo zákaznické ana-lýzy, navrhuje Studený.

„Aby IT útvar dokázal efektivně podporovat zmíněné podnikové cíle, musí především zajistit koncepční rozvoj ICT, ideálně pomocí IT strategie

orientované na byznys,“ prohlašuje Martin Kli-meš z Deloitte Advisory. Naplnění podnikových cílů bude IT podle něj uskutečňovat především poskytováním ICT služeb, tj. z pohledu uživa-tele primárně služeb podnikových informačních systémů, a to v požadované kvalitě zajištěné procesem řízení úrovně služeb.

Dalším podstatným aspektem je koncepční a flexibilní řízení podnikové architektury, tj. technologické, datové a aplikační architek-tury v návaznosti na podporované byznys pro-cesy při splnění stanovených technologických standardů. Aby podnik dokázal pružně reagovat na měnící se podmínky trhu a zavádět nové pro-dukty či služby, musí IT útvar dokázat agilně vy-hledávat a nasazovat vhodná IT řešení. Toho lze dosáhnout především díky správně nastave-nému a dělanému řízení inovací, řízení změn, vývoje, testování a nasazování, uvádí Klimeš.

Jedním z klíčových předpokladů je pravi-delné zapojení IT do přípravy nových služeb a výrobků, tak aby IT mohlo pracovat na budou-cích potřebách byznysu s dostatečným předsti-hem a zároveň bylo schopné nabídnout řešení, o nichž se dříve neuvažovalo, upozorňuje Petr Plecháček, manažer IT poradenství a řízení ri-zik společnosti EY. Uměním IT manažera pak je, aby skloubil hromadící se požadavky na roz-voj s tradičními IT procesy, které zajišťují, aby byznys mohl fungovat tak jako dosud.

„Na základě práce na strategii řízení IT služeb pro několik významných výrobních podniků i fi-nančních institucí v ČR mohu potvrdit, že nejdůle-žitější je předvídatelnost dodávek IT služeb z hle-diska kvality, množství, času a ceny,“ tvrdí Radek Bělina, manažer pro excelenci IT služeb firmy Devoteam.

Pokud některý parametr významně selže a má přímý dopad na výrobu nebo dodávku byz-nys služeb, padají hlavy. Bohužel až tato situace často donutí vrcholové manažery k věnování pozornosti IT a někdy i k zamyšlení nad investi-cemi do řízení IT služeb, varuje Bělina. Podle něj občas dané investice míří správně a kon-cepčně a někdy se jen hledá, jak rychle zalepit díru implementací nějakého nástroje, jako jsou nový servicedesk, monitoring a podobně.

„Pokud se v té době najde šikovný manažer IT služeb, může tuto situaci využít pro opravdovou

a procesů souvisejících se spuštěním nové ICT služby, které se v průběhu provozu dodatečně do-pracovávají,“ konstatuje Jaroch.

Podniky by měly nastavit základní pravidla flexibilní IT architektury a efektivně je prosazo-vat. Správně nastavená, servisně orientovaná ar-chitektura zrychlí a zlevní i zásadní změny kom-ponent, například přesun částí systémů do cloudu, rozdělení společnosti či akvizici jiné or-ganizace, říká Zoth z KPMG.

Proměnlivost prostředíPodniky musí brát stále více v potaz proměnli-vost vnitřního i vnějšího prostředí. Před součas-nou systémovou integrací mnohdy stojí požada-vek na výměnu nebo úplné odstranění části pod-nikové informatiky.

„Rozhodnutí o výměně nebo úplném odstranění části podnikové informatiky je obvykle zdůvodněno očekávanými finančními úsporami. Realizace tako-vého rozhodnutí překreslí hranice mezi interní a ex-terní informatikou, resp. mezi informatikou a byz-nysem vůbec,“ podotýká Rutrle z Komixu.

Jestliže v původní konstelaci řešila systémová integrace zejména témata technická, a to uvnitř organizace, pak při novém uspořádání přibývají i otázky smluvní a z nich vyplývající finanční vůči externím partnerům. Část úloh systémové integrace se tedy v případě outsourcingu či pře-chodu na cloudová řešení sice přenese na bedra externího poskytovatele, ale současně se objeví zvýšené požadavky v jiné oblasti. Role systémové integrace se možná změní, ale její význam roz-hodně nezmizí, věří Rutrle.

„Pomocí integračních platforem lze tuto proble-matiku řešit velmi elegantně, a to přesměrováním komunikace na nové agendy. V rámci systémové integrace je však třeba dbát na zamezení duplicit-ních funkcí a služeb a případné odstranění starých systémů řešit komplexně,“ uvádí Dostál z GEM System.

„Rozhodnutí o outsourcingu části podnikové in-formatiky patří do ICT strategie podniku. Musí ho udělat management podniku v návaznosti na stra-tegii celého byznysu, dostupnosti lidských zdrojů, fi-nančních zdrojů, know -how apod. Systémová inte-grace pro toto rozhodnutí může připravit materiály, ale rozhodnutí jako takové jí podle mého názoru nepřísluší,“ konstatuje Zrzavý z Unicorn Systems.

Osamocený systémový integrátor má velké problémy v tomto trendu obstát. Naopak konver-govaný ICT operátor zákazníkům může vyjít vstříc nabídkou cloudových řešení, uvádí Moc z T -Mobile.

Služby systémové integrace v podání konver-govaného operátora pak podle Moce hrají zá-sadní roli „zprostředkovatele“, který zákazníkovi zaručí hladký přechod do cloudového prostředí. Její hlavní role je pak poradní (zákazníkovi po-může identifikovat ideální model a způsob fun-gování v cloudu), dále integrační (systémy a aplikace zákazníka přizpůsobí cloudovému prostředí a zajistí jejich migraci) a role servisní, případně inovátorská – zákazníkovy systémy v cloudu dále udržuje, rozvíjí a modernizuje. ■

CW17-II-VIII.indd IVCW17-II-VIII.indd IV 17.10.14 16:0217.10.14 16:02

CO M P U T E RWO R L D.C Z V

SYSTÉMOVÁ INTEGRACE A ŘÍZENÍ IT

▶

koncepční změnu, spustit rychlou transformaci těchto služeb a navá-zat fungování IT procesů přímo na byznys procesy,“ radí Bělina.

Mezi klíčové aspekty součas-ného řízení IT řadíme schopnost být flexibilní a přinášet a imple-mentovat inovace, které napomá-hají efektivní realizaci byznys procesů, míní Jan Krob, ředitel pro IT poradenství společnosti KPMG Česká republika. V rámci flexibility jsou stěžejní připrave-nost IT architektury a dostupnost interních nebo externích rele-vantních znalostí. Schopnost vy-užít a nasadit inovace v rámci IT vyžaduje zkušenosti s řízením velké změny společnosti a s nasa-zením řešení v reálném byz-nysu – pak je možné generovat reálný přínos pro klienta.

IT je především pouze nástroj či soubor ná-strojů a největší vliv na shora uvedené podni-kové cíle má to, jak se s takovým nástrojem pra-cuje, podotýká Tomáš Rutrle, jednatel společ-nosti Komix. Úkolem IT je shromažďovat, zpra-covávat a vyhodnocovat podniková data i data o okolí a v zásadě musí být schopné dodávat ma-nažerům včasný, správný a relevantní obraz toho, jak si příslušná organizace stojí. Přitom by nemělo podnikové procesy neúměrně kompliko-vat, ani zatěžovat zbytečnými náklady, shrnuje Rutrle.

Vztah IT a byznysuO propojování byznysu a IT se mluví už bezmála deset let, přesto ne všechny firmy tento krok zvládly. Je vůbec potřebné, aby se IT služby a procesy staly součástí byznys procesů?

„IT služby a procesy jsou součástí byznys pro-cesů, a to bez ohledu na segment trhu, skladbu zá-kazníků a velikost firmy,“ říká Moc z T -Mobile. I vedení účetnictví doma na PC je podle něj IT jako součást byznys procesů. Bez toho, aby to tak bylo, nedokáže firma obstát v dnešním konku-renčním prostředí. IT je vnímáno téměř jako út-var rovnocenný byznysu.

„Mnoho byznys procesů nelze bez IT vůbec uskutečňovat – v takovém případě opravdu platí IT rovná se byznys,“ souhlasí Rutrle z Komixu a po-kračuje: „V řadě jiných oborů, napadá mne třeba výroba dusíkatých hnojiv, hraje IT roli zcela okrajo-vou. Odpověď je tedy různá podle toho, o jakém od-větví mluvíme.“

To, do jaké míry jsou IT služby a IT procesy součástí byznys procesů nebo i produktů a slu-žeb, závisí do značné míry na charakteru daného odvětví, uvádí Klimeš z Deloitte Advisory. V po-slední době se podle něj u mnoha společností posouvají IT útvary z role pouhého technolo-gicky orientovaného provozovatele IT služeb do proaktivní role partnera byznysu se snahou o po-rozumění a efektivní podpoření podnikových potřeb a cílů.

„Tento trend vnímáme primárně jako důsledek rostoucího významu ICT, kdy se v mnoha odvětvích IT služba stává klíčovou komponentou koncového produktu,“ podotýká Klimeš a dodává, že na dru-hou stranu mnoho IT útvarů prochází touto pře-měnou proto, aby obhájily svoji užitečnost a hodnotu pro organizaci. Dalším důvodem může být snaha zabránit nekontrolovanému po-řizování IT služeb byznysem přímo od externích dodavatelů. To je díky cloudovým službám snazší než dříve, upozorňuje Klimeš.

„Proč by si byznys kupoval službu, kdyby ji nepo-třeboval pro svůj chod?“ ptá se Studený z firmy Alvao a pokračuje: „Proto je jasné, že IT služby ne-mohou existovat bez vazby na byznysové služby. Po-kud se to stane, něco je špatně. Například může jít o službu, kterou v historii byznys požadoval, ale dnes už ji nechce.“

Pokud je IT služba zdarma, nejsou lidé z byz-nysu nijak motivováni čerpání služby ukončit. „Mluvím teď o běžných věcech, jako jsou e -mailový účet, účet do ERP nebo také staré PC, které se ne-vrátí na IT, ale zůstává v byznysu pro ‚strýčka Pří-hodu‘,“ objasňuje Studený. Aby se tomu předešlo, je podle něj dobré nastartovat tržní prostředí mezi IT a byznysem. Nikdo nebude chtít platit za něco, co už nepotřebuje.

S propojováním IT a byznysu ve firmách sou-visí i otázka, zda je IT podpůrný útvar nebo út-var, který je byznysu rovnocenný.

„Častěji se setkáváme s částečným či úplným od-dělením těchto dvou rovin. Pokud jsou IT procesy u klienta jen podpůrné, je důležité, aby byly navá-zány na byznys již v rovině strategického rozhodo-vání, nikoliv jen až jako důsledek detailního pláno-vání a úprav obchodních procesů,“ vysvětluje Pa-vel Dostál, technický ředitel GEM System.

Role a postavení IT ve společnostech se liší podle hlavního předmětu podnikání, uvádí Ple-cháček z EY. IT jako tradiční podpůrný útvar se vyskytuje již poměrně málo, snahou určitě je, aby IT bylo rovnocenným partnerem, který usnadňuje současný byznys a snaží se napomá-

hat hledat nové příležitosti. Tradiční IT služby a procesy jsou stále doménou IT oddě-lení, nicméně v technolo-gicky vyspělých společnos-tech lze najít úzké propojení IT funkcionalit a služeb do procesů, například při ob-sluze klienta v call centru, dodává Plecháček.

„Mnoho firem prohlašuje, že propojuje byznys a IT. Z vlastní zkušenosti mohu po-tvrdit, že zejména v sever-ských zemích k tomuto propo-jování hodně dochází a IT je vnímáno jako partner podpo-rující podnik a v některých případech i generující nové obchodní příležitosti,“ tvrdí Bělina z Devoteamu.

V České republice je podle něj zatím situace trochu jiná a IT je často jen nákladovou položkou. Důvodem je, že IT a často ani externí konzultanti z poradenských firem nedokážou benefit tohoto propojení vy-světlit byznys straně. Mnohokrát i z neznalosti fungování byznysu dané společnosti a nezvlád-nuté implementace změny řízení IT.

Podle Kroba z KPMG bylo dříve IT vnímáno jako podpůrný útvar byznysu, pro nějž byla cha-rakteristická obhajoba vlastní pozice ve společ-nosti a který vůči okolí fungoval víceméně jako „black -box“. Oproti tomu se dnes IT posouvá více k partnerskému vztahu s byznysem, pro nějž jsou typické společné cíle a odpovědnosti, transparentnost, efektivnost a jednoznačně pro-aktivita a inovace.

Standardy kontra útvaryStandardy pro řízení výkonnosti podniku jsou obvykle procesně orientované, naproti tomu vět-šina podnikových útvarů je organizována a ří-zena liniově. Většina odborníků v tom nevidí rozpor, protože dnešní podniky umějí jednotlivé pohledy kombinovat.

Podle Kroba z KPMG se na trhu jen těžko na-lezne společnost, která by byla organizována silně procesně nebo pouze liniově – většinou jde o kombinace těchto stylů řízení v závislosti na aktivitách podniku. Důležitým faktorem úspě-chu je nalezení rozumné rovnováhy mezi pro-cesním a liniovým způsobem řízení v návaznosti na vhodnost jejich aplikace pro konkrétní pro-cesy, jejich cíle, povahu zaměstnanců a kulturu společnosti, podotýká Krob.

„Tento ‚rozpor‘ trvá již téměř sto let a literatura i praxe se s ním umějí vypořádat,“ uvádí Rutrle z Komixu. Základem je podle něj kvalitní podni-kový model a vhodný rozpad procesních metrik, tak aby mohly být použity v rámci jednotlivých organizačních jednotek. Z hlediska aplikací po-užitých při řízení podniku to pak znamená inte-grovat ERP s nástrojem pro projektové či pro-cesní řízení nebo použít přímo integrovaný

CW17-II-VIII.indd VCW17-II-VIII.indd V 17.10.14 16:0217.10.14 16:02

VI CO M P U T E RWO R L D 17–18 | 2014

SYSTÉMOVÁ INTEGRACE A ŘÍZENÍ IT

softwarový balík, který zvládne jak pohled přes procesy, tak přes organizační jednotky.

Podle Moce z T -Mobile jsou procesně orien-tované standardy po svém zavedení do firmy v taktické, strategické, projektové, liniové a mnoha dalších variantách řízení jednak měří-cími body efektivity řízení a zároveň definují rozhraní a obsah přechodů mezi strukturami a modely řízení. Zároveň takto definované a im-plementované standardy umožňují srovnání z hlediska efektivity mezi organizacemi a řídi-cími strukturami.

„Nebo ještě jinak: v liniově řízených organiza-cích představují procesně orientované standardy jednotně definovanou společnou metodu vzájemné interakce, která je stejná pro všechny společnosti se stejnými a zavedenými procesními standardy. V ob-lasti byznysu pak prokázaná shoda s definovanými standardy použitými při řízení dokazuje kvalitu struktury organizace,“ říká Moc.

„V praxi se u našich klientů obvykle setkáváme s kombinací tří způsobů řízení, a to liniového, pro-cesního a projektového,“ uvádí Klimeš z Deloitte Advisory. Ve všech třech způsobech je z pohledu výkonnosti důležité nejen sledovat plnění pro-vozních, taktických a strategických cílů, ale také zajistit efektivní přidělování zdrojů a konti-nuální revizi celého mechanismu sledování vý-konnosti. To vyžaduje uplatnění maticové struk-tury, kde je nutné nastavit výkonnostní parame-try pro více než jeden uvedený způsob řízení.

Inspiraci pro řízení výkonnosti v takovéto ma-ticové struktuře lze podle Klimeše hledat napří-klad v metodě Balanced Scorecard. Ta umožňuje kombinovat jak procesní, tak liniové klíčové in-dikátory výkonnosti KPI pro různé úrovně řízení a následně je agregovat tak, aby bylo možné sle-dovat i plnění strategických a taktických cílů.

Plecháček z EY soudí, že většina organizací se dnes snaží fungovat maticově, proto umí kombi-novat různé pohledy. Základní snahou by mělo být nevytvářet komplexitu, která bude brzdit fungování či rozvoj, ale hledat vhodné kompro-misy. Užitečným nástrojem je sladit celkové cíle všech zainteresovaných a dále definovat eska-lační procedury a pravomoci pro známé či před-pokládané případy, kde by mohlo dojít ke kon-fliktu priorit.

„Nám se osvědčilo, když roli manažera IT služeb dostal na starost vysoce postavený manažer v IT, například zástupce CIO nebo vedoucí provozu, a jednotliví procesní manažeři mu přímo procesně i liniově odpovídali,“ uvádí Bělina z Devoteamu.

Nastavení pyramidově strukturovaného čle-nění měřitelných KPI (klíčových indikátorů vý-konnosti) v závislosti na roli je nezbytností. Často už ani nevadilo, když několik procesních manažerů bylo mimo přímé liniové řízení, ale věděli, kdo je za celý systém řízení IT odpovědný a že jsou mu procesně podřízeni a jejich KPI mají vliv na variabilní složku výplaty, pokračuje Bělina. Pro zajištění spolupráce mezi byznysem a IT na správné úrovni je nezbytně nutná přímá vazba business relation managementu a service level managementu na nejvyšší úrovně řízení IT.

„Řekl bych, že toto dilema řeší i tým stojící za metodikou ITIL, protože v nových verzích se snižuje důraz na procesy a zvyšuje důraz na služby. Liniový útvar pak zodpovídá za dodávku služeb,“ konsta-tuje Studený z firmy Alvao. Služba by měla být definována, aby byla dobře srozumitelná jak pro útvar, který ji odebírá, tak pro útvar, jenž ji dodává.

„Je třeba definovat kvalitu a cenu (parametry SLA). Pak muže být byznysu v podstatě jedno, zda používáme procesní řízení, protože to je jen cesta. Stejně jako je mu jedno, jak funguje uvnitř telefonní operátor, důležitější je, zda hovory nepadají a jsou levné,“ doplňuje Studený.

Jednota prospěšná, nebo škodlivá?Vyplatí se sjednotit poskytování IT služeb a pod-pory externím a interním uživatelům? Někdy to není reálné, jindy může být jednotná technická podpora výhodná.

„Znám jen velmi málo organizací, které sku-tečně sjednotily interní i externí poskytování IT slu-žeb, a to nejen procesně, ale i do jednoho nástroje. Je třeba si uvědomit, že to často není reálné a nese to s sebou omezení,“ varuje Studený z firmy Al-vao. Takové omezení si v interním IT lze dovolit, ale v byznysovém IT zaměřeném na zákazníky to jde jen stěží. Může to znamenat ztrátu klientů, což si může dovolit jen málokdo.

Kromě toho sdílení zkušeností ve formě pro-cesů a sdílení nástroje, který vyhovuje oběma tý-mům, dává smysl. Dokonce se to děje i mimo út-var IT – procesní řízení a dodávka služeb jsou inspirací pro další útvary v organizaci, ať už jde o vozový park, správu budov, administrativu, ří-zení lidských zdrojů nebo finance, dodává Studený.

Vhodnost či výhodnost sjednocení je třeba měřit dopadem na čtyři dříve zmíněné aspekty řízení IT, tj. jaký dopad bude mít případné spojo-vání v oblasti personálního, kvalitativního, bez-pečnostního a finančního řízení IT, podotýká Moc z T -Mobile. Přitom je nutné nepodcenit ani jeden z těchto aspektů. IT je velmi komplexní systém a „spojování a rozpojování“ bez analýzy je velkým hazardem.

Na druhou stranu plánovaný a řízený proces v této oblasti má velký pozitivní potenciál. Co tedy má a nemá smysl?

Při všech těchto vznosných slovech a proce-sech je základem prostý selský rozum. Je nutné mít na paměti, že neplánované a neřízené spojo-vání zvyšuje komplexitu a snižuje flexibilitu a mnohdy očekávané pozitivní dopady v oblasti finančního řízení se nedostavují vůbec nebo s velkým zpožděním, upozorňuje Moc.

Na druhou stranu však velká fragmentace má úplně stejný dopad. Jak tedy postupovat?

Jeden z obecných a stále platných principů postupu v IT, ale i kdekoliv jinde, je následující: Koncentrace a spojování při zachování bezpeč-nosti všude tam, kde existují liniový či produk-tový produkční charakter, flexibilita s agilitou a s menší mírou centralizace pak v oblasti ino-vace a rozvoje.

Firmy si však musí dát pozor na lidské zdroje a klíčové odborníky z obou oblastí. Mezi těmito sférami musí existovat (a být oběma směry pro-stupná) „membrána“ podporovaná manage-mentem a umožňující pronikání odborníků oběma směry, tak aby nevznikala „sila“ či „slono-vinové věže“, uzavírá Moc.

Podle Štěpána Jarocha z Deloitte Advisory zá-visejí možnosti sjednocení podpory na typu ex-terních uživatelů a jejich vztahu ke společnosti. Pro externí uživatele kategorie B2C (business--to -customer) platí, že využívají jiné IT služby než interní uživatelé, a to obvykle orientované na produkt. Je tedy důležité zajistit, aby první úroveň podpory byla vysoce zákaznicky zamě-řená právě z pohledu znalostí o produktech vy-užívaných těmito zákazníky.

„V případě, že dokážeme identifikovat rutinní, často opakované požadavky, u kterých není vyžado-vána hlasová interakce s produktovým specialistou, lze je splnit jedním týmem podpory společným pro externí i interní uživatele,“ říká Jaroch. Určité sjednocení je podle něj doporučeno zejména pro druhou úroveň podpory, která obvykle řeší tech-nické aspekty uživatelských požadavků či vznik-lých situací.

Sjednocení lze také uskutečňovat využitím jednotného nástroje pro řízení uživatelských po-žadavků a jejich vyhodnocování. Předpokladem je však podle Jarocha jednoznačné rozlišení ex-terních a interních uživatelů a služby.

„Spojení podpory ve většině případů dává roz-hodně smysl,“ tvrdí Bělina z Devoteamu. V sou-časnosti jsou často externí zákazníci prefero-váni přesně definovanými smlouvami SLA (Service Level Agreement) nebo vyšší prioritou jejich požadavků na servicedesk. Děje se to i ve firmách, kde poskytování služeb externím organizacím například v rámci koncernu tvoří minoritu.

„Osobně zastávám názor, že nastavení služeb by mělo probíhat v souladu s potřebami byznysu napří-klad na základě analýzy dopadů na byznys nebo podle ochoty zaplatit danou cenu nebo podíl na ná-kladech nezávisle na tom, zda je zákazník interní nebo externí,“ pokračuje Bělina.

Potřeby jsou občas v rozporu s požadavky. Často se ukáže, že na menším oddělení, které konzumuje malé množství kritických služeb, zcela závisí chod výroby celého podniku, ale jeho požadavky se řeší až po potřebách obchod-ního oddělení, které nemá problém s hodinovým výpadkem.

Rozdělit striktně podporu dává smysl v přípa-dech, kdy to vyžadují například legislativní pro-středí nebo neslučitelnost jednotlivých podporo-vaných byznys aktivit, upřesňuje Bělina.

„Podle naší zkušenosti firmy velmi zřídka posky-tují IT služby interním a externím uživatelům roz-dílným způsobem,“ zdůrazňuje Krob z KPMG. Pravidla by podle něj měla být v principu stejná, ať už jde o dodávky dovnitř nebo vně firmy. Roz-díl je jen v úrovni formalizace vztahů a v někte-rých případech mohou být jiné požadavky na úroveň služeb definovanou smlouvami SLA. ■

CW17-II-VIII.indd VICW17-II-VIII.indd VI 17.10.14 16:0217.10.14 16:02

CO M P U T E RWO R L D.C Z VII

SYSTÉMOVÁ INTEGRACE A ŘÍZENÍ IT

▶

Praktická použitelnost aktuálních verzí ITIL, ISO/IEC 20000 a COBITPro oblast řízení podnikové informatiky máme již čtvrt století k dispozici dva komplexní znalostní rámce, ITIL a COBIT, a již deset let existuje z ITIL vycházející norma ISO/IEC 20000.

JIŘÍ SKÁL A

Během doby byl každý z těchto informačních zdrojů několikrát aktualizován, přičemž se měnil nejen obsah, ale i způsob použití.

Ukažme si, v čem se jejich aktuální verze dopl-ňují a překrývají, v čem se liší a k čemu se každá z nich nejlépe hodí.

ITILAktuální verze knihovny infrastruktury infor-mačních technologií ITIL (Information Techno-logy Infrastructure Library) nese označení ITIL 2011 Edition a jejích pět ústředních titulů (Ser-vice Strategy, Service Design, Service Transition, Service Operation a Continual Service Improve-ment) na celkem 1 884 stranách obsahuje kromě desítek konceptů a zásad pro řízení životního cyklu služeb IT především popis 26 procesů, cca stovky dalších aktivit, čtyř komplexních funkcí a asi stovky rolí, jež jsou pro realizaci těchto pro-cesů, aktivit a funkcí potřebné.

Je zřejmé, že málokterý podnik na světě, po-kud vůbec nějaký, potřebuje mít nasazeny všechny tyto procesy, aktivity, funkce a role na-jednou. ITIL je sbírka nejlepší praxe, což zna-mená, že obsahuje soupis toho, co se někde osvědčilo. To ale neznamená, že jsou všechny v něm popsané prvky zapotřebí vždy a v každé situaci. ITIL 2011 Edition můžeme přirovnat ke stavebnici lego: musíme vědět, co chceme posta vit, a podle toho si musíme vybírat kos-tičky, které se k sobě hodí a jež jsou určeny pro

typ objektu, který chceme postavit. Pokud ne-máme jasno v tom, jak má naše stavba vypadat, nemůžeme vědět, které prvky best practice z ITIL opravdu potřebujeme.

Je tedy třeba nejprve vytvořit architekturu stavby, tj. architekturu našeho systému řízení služeb, a to s pomocí ISO/IEC 20000, případně COBIT, a teprve při detailním designu se inspi-rovat v ITIL. Jinými slovy, odpověď na otázku „Které prvky řízení služeb musím bezpodmínečně aplikovat, aby byli zákazníci a uživatelé spoko-jeni?“, nenajdeme v ITIL, ale v ISO/IEC 20000 a v COBIT. V ITIL můžeme hledat odpo-vědi na konkrétní otázky typu: „Které role s ja-kými odpovědnostmi a pravomocemi jsou potřebné pro realizaci procesu XY či aktivity ABC?“, „Na ja-kých principech je dobré založit systém schvalování změn?“, „Jakým způsobem je vhodné prioritizovat incidenty?“ apod.

Nicméně množina otázek, na něž je ITIL schopen odpovídat, je limitována skutečností, že po obsahové stránce je současná nejaktuálnější verze ITIL de facto sbírkou nejlepší praxe z let 2005–2006. Vysvětlení je zřejmé: ITIL 2011 Edition, jenž vyšel v červenci 2011, je totiž více méně pouze po formální stránce přepracova-

CW17-II-VIII.indd VIICW17-II-VIII.indd VII 17.10.14 16:0217.10.14 16:02

VIII CO M P U T E RWO R L D 17–18 | 2014

SYSTÉMOVÁ INTEGRACE A ŘÍZENÍ IT

nou verzí ITIL V3, která byla vydána v červenci 2007, ale na níž se začalo pracovat v dubnu 2005. ITIL tedy nedokáže pomoci s řešením aktuálních problémů typu: „Jak vytvořit katalog služeb v situaci, kdy uživatelé mají polovinu služeb IT od komerčních poskytovatelů cloudových služeb, druhou polovinu od interního IT oddělení a kon-cová zařízení používají svoje vlastní?“ či „Jak kon-cept BYOD změní procesy řízení incidentů, pro-blémů a změn?“. Odpovědi na taková aktuální té-mata je třeba hledat u profesních sdružení jako itSMF a ISACA, na odborných konferencích či v internetových diskuzích, newsletterech a webinářích.

ISO/IEC 20000Tato mezinárodní norma pro oblast řízení služeb se skládá ze 13 částí, i když některé z nich nebyly dosud vydány. Mezi odbornou veřejností jsou nejvíce známé první dvě části, jež jsou rovněž považovány za nejdůležitější. První část normy je primárně určena k certifikačnímu auditu sy-stému řízení služeb, přičemž obsahuje výčet mandatorních požadavků, které takovýto systém musí splňovat. Druhá část pak obsahuje stručné vysvětlení jednotlivých požadavků uvedených v části první. Oba tyto díly již byly jednou aktua-lizovány a obě jejich verze rovněž byly, jako do-sud jediné z celé řady norem ISO/IEC 20000, převzaty do českého systému norem a vydány jako dvojjazyčné, tj. v česko -anglickém znění.

Ostatní části normy jsou méně známé, což ale neznamená, že jsou nedůležité. Za zmínku stojí zejména část čtvrtá, jež obsahuje tzv. process re-ference model, s jehož pomocí lze snadno vytvořit procesní rámec systému řízení služeb, jenž bude splňovat mandatorní požadavky první části normy.

Všechny požadavky normy na systém řízení služeb vycházejí z ITIL, a i když se v některých svých předchozích verzích ITIL a první dvě části normy rozcházely, jsou jejich současné aktuální verze v principiální shodě. V této větě je důle-žité slovo „principiální“, neboť již při prvním po-hledu na procesy v ČSN ISO/IEC 20000 -1:2012 a v ITIL 2011 Edition zjistíme řadu rozdílů: v této normě jsou některé ITIL procesy sloučeny do procesu jednoho nebo se jinak jmenují, norma obsahuje procesy, které v ITIL nejsou, a naopak ITIL obsahuje procesy, jež nenajdeme v této normě. Tyto nekonzistence by nás ale ne-měly od používání normy odradit, jakkoli nám schází logické vysvětlení, proč tomu tak je.

Norma ISO/IEC 20000 doplňuje ITIL přesně v tom aspektu, jenž mu schází a který v něm mnozí postrádají. Norma totiž dává zcela expli-citní odpověď na otázku, jaké prvky z ITIL by-chom měli zavést, aby v IT organizaci všechno správně fungovalo. Přínos normy je tedy rovněž v tom, že poskytuje filtr pro nahlížení do roz-sáhlé knihovny ITIL, a tím umožňuje rychle se zorientovat v tom, co je z ITIL skutečně důležité.

Norma ISO/IEC 20000 je mezi odbornou ve-řejností vnímána zcela nezaslouženě jako

„pouhý“ kvalitativní standard, jenž může být za-jímavý pouze pro firmy, které chtějí být podle této normy certifikovány. Přitom norma ISO/IEC 20000, resp. její první a druhá část, by měla být povinnou četbou každého IT manažera. Podle ní lze například učinit rychlý assessment stavu systému řízení služeb IT v organizaci, identifikovat jeho slabá místa a určit, kterými prvky best practice by bylo vhodné je elimino-vat. Samozřejmě pro podrobné informace, jak tyto prvky designovat, je již třeba sáhnout po ITIL.

COBITMetodika COBIT (Control Objectives for Infor-mation and related Technology) po celou dobu své existence trpí podobným stigmatem jako norma ISO/IEC 20000: většina IT manažerů je přesvědčena, že je to nástroj patřící výhradně do rukou IT auditorů a top manažerů nadnárodních společností. Přitom již od verze 4.0, jež vyšla v roce 2005, je COBIT smysluplně použitelný a v praxi skutečně používaný nejen pro strate-gické, ale i pro taktické řízení celého prostředí podnikové informatiky, a to nejen ve velkých korporacích.

Současná aktuální verze COBIT se pak do-konce považuje za tzv. Business Framework for the Governance and Management of Enterprise IT, což je zároveň i podtitul ústřední publikace COBIT 5, která byla vydána v dubnu 2012. Z dalších do-sud vydaných publikací rodiny COBIT 5 stojí za zmínku dvěstětřicetistránkový titul COBIT 5: Enabling Processes, jenž má ambici, a nutno říci, že oprávněnou, sloužit k designování skuteč-ného komplexního procesně orientovaného rámce pro řízení celé podnikové informatiky, a to od strategické úrovně přes taktickou až po operativní.

Ohledně praktické použitelnosti COBIT je důležité zmínit tři skutečnosti:

1. K odstranění veškerých systémových ne-kompatibilit v procesním pojetí mezi ITIL a CO-BIT došlo již s vydáním COBIT 4.0, takže od té doby nic nebrání tomu používat COBIT jako cel-kový procesní rámec podnikové informatiky a ITIL jako příručku pro designování některých jeho prvků – a opravdu jen některých, protože ITIL i přes svůj obrovský rozsah zdaleka neobsa-huje všechny procesy a aktivity, které jsou obsa-ženy ve všech IT procesech podle COBIT. Mimo jiné v ITIL zcela schází oblast řízení IT zdrojů,

řízení IT projektů, vzdělávání uživatelů služeb IT a další oblasti.

2. COBIT, na rozdíl od ITIL a ISO/IEC 20000, obsahuje všechny prvky, které by měly být v IT prostředí pod manažerskou kontrolou. Pokud tedy IT manažer adresným způsobem řídí vše, co COBIT uvádí jako Control Obje-ctive (pojetí podle COBIT 4.0 a 4.1), resp. jako Management Practice (pojetí podle COBIT 5), může mít jistotu, že na něj nikde nečíhá žádné nepříjemné překvapení. Podobné ujištění mu nemůže poskytnout ani ITIL, ani ISO/IEC 20000.

3. Popisy procesů podle COBIT jsou jednotně strukturovány, jejich jednotlivé vlastnosti jsou dokonce číslovány, takže se na ně lze například snadno odvolávat v manažerské komunikaci či řídicí dokumentaci. A samozřejmě je celý text mnohem přehlednější než esejová forma publi-kací ITIL.

V odstavci věnovanému ITIL jsme museli konstatovat, že jde sice o nejlepší praxi řízení služeb IT, ale deset let starou. COBIT je na tom v tomto směru mnohem lépe. Jako důkaz toho, že COBIT dokáže držet krok s vývojem infor-mačních technologií, poslouží publikace Cont-rols and Assurance in the Cloud: Using COBIT 5, jež vyšla v letošním roce, přičemž již pro verzi COBIT 4.1 byl k dispozici titul IT Control Objecti-ves for Cloud Computing vydaný v roce 2011. A našli bychom další užitečné monotematické tituly reagující na nové IT trendy: Securing Mo-bile Devices Using COBIT 5 for Information Secu-rity, Configuration Management Using COBIT 5 atd.

Co čekat?Všechny tři informační zdroje mají své místo v knihovničce IT manažera. Důležité je vědět, co lze od každého z nich očekávat, a podle toho s nimi pracovat. Uveďme si na závěr tři kon-krétní ilustrativní příklady toho, jak těžit ze synergie těchto tří znalostních zdrojů:

■ Potřebujeme zjistit, proč se nám zpožďují projekty?

Porovnejme naši současnou praxi s Control Objectives procesu PO10 podle COBIT 4.1 nebo s Management Practice procesu BAI01 podle COBIT 5 a pravděpodobně velmi rychle nalez-neme příčinu, aniž budeme experty na proble-matiku projektového řízení.

■ Potřebujeme zlepšit postupy testování? Mnoho inspirujících prvků najdeme v ITIL pub-likaci Service Transition, a pokud jsou pro nás tyto informace příliš podrobné, podívejme se před tím na popis procesu AI7 podle COBIT 4.1, nebo BAI07 podle COBIT 5.

■ Potřebujeme se rychle zorientovat v tom, jaké jsou nejdůležitější principy capacity ma-nagementu? Odpověď poskytne první, druhá a případně ještě čtvrtá část normy ISO/IEC 20000. ■

Autor je nezávislý konzultant zaměřený na řízení IT služeb (IT service management).

CW17-II-VIII.indd VIIICW17-II-VIII.indd VIII 17.10.14 16:0217.10.14 16:02