Z VL Á ŠTNÍ NEPRODE JNÁ PŘÍLOHA | ŘÍJEN 2014
Systémová integrace a řízení IT 2014 Nové výzvy systémové integrace Jak řízení IT ovlivňuje konkurenceschopnost Srovnání ITIL, ISO 20000 a COBIT
CW17-II-VIII.indd I SI_2014_235x297.indd 17
17.10.144:30 16:46 10/17/14 PM
SYSTÉMOVÁ INTEGRACE A ŘÍZENÍ IT
Nové výzvy systémové integrace Systémová integrace neustále prochází vývojem a procesem přizpůsobová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žadavky na výměnu nebo odstranění části podnikové informatiky. V Í T PE T R JANO Š
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í dogmatické vodopádové pojetí vývoje informačních systémů a požadují po integrátorech flexibilně nastavitelnou 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é metodické 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ákaznickým portálem, je kriticky důležitá právě znalost metodiky a správného postupu,“ upozorňuje Rutrle. 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 pravdě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 informačního systému v kvalitě, kvantitě, termínu a rozpočtu,“ uvádí Lukáš Zrzavý, provozní ředitel Unicorn 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žadavky 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 protichů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ý.
II
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 problé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 nezmě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 jejich 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 monitorem 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í inovativní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 existují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. Dodavatelé 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 konfigurovatelná, připomíná Skořepa. Systémoví integrátoři primárně odbourávají přebytečnou administrativu během dodávek systémů a využívají vhodné metody realizace konkré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 kamenem, 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 architekturu, 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řirozené, ž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 rizika 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 použ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 systému však vhodný prostor pro „zkoušení“ nových technologií mnohdy ani neexistuje. Naopak v méně kritické části, kde nová technologie může přinést podstatné úspory, se vyplatí po odzkoušení na prototypech technologii nasadit. Je třeba vždy dobře zvážit rizika, a to je role integrá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 kontinuální proces, který nesměřuje k předem definované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í novinky, 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 inovativní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 jejich včasnou adopcí, přičemž upravují běžné postupy 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
CO M P U T E RWO R L D 17–18 | 2014
CW17-II-VIII.indd II
17.10.14 16:02
SYSTÉMOVÁ INTEGRACE A ŘÍZENÍ IT vytvářejí oddělené realizační struktury, financování a infrastruktura. Implementaci často připravuje úzký řešitelský tým za využití agilních přístupů s cílem ověřit jeho potenciál. Problematické 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 nasazování nových technologií a doplňuje: „Předpoklady úspěchu tohoto přístupu závisejí na rozsahu požadované integrace s existujícím informačním systé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é integrace 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í, servisně orientovaná IT architektura, která umožní snadnější integraci jakýchkoliv, tedy i nových a neodzkoušených komponent a technologií, podotýká Zoth z KPMG. Firmy musí zohledňovat míru přínosů a rizik vyplývajících z použití takový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 rizika Některé české firmy jen nerady akceptují rizika vyplývající z rychlého spuštění integrovaných systé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í systé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 pobočkách, nasazení systému obvykle nebylo managementem tolik podceňováno jako dnes, připomí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ásledují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 dodavatele, 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ů vyplývající z neúspěšných implementací, avšak mnohdy nemají vhodné znalosti a schopnosti takové 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žadovaných funkcí, verifikace cílů a účelu implementace 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 pochopení 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 problémů s úpravou interních provozních postupů ▶
Inzerce
CO M P U T E RWO R L D.C Z
CW17-II-VIII.indd III
III 17.10.14 16:02
SYSTÉMOVÁ INTEGRACE A ŘÍZENÍ IT a procesů souvisejících se spuštěním nové ICT služby, které se v průběhu provozu dodatečně dopracovávají,“ konstatuje Jaroch. Podniky by měly nastavit základní pravidla flexibilní IT architektury a efektivně je prosazovat. Správně nastavená, servisně orientovaná architektura zrychlí a zlevní i zásadní změny komponent, například přesun částí systémů do cloudu, rozdělení společnosti či akvizici jiné organizace, říká Zoth z KPMG.
Proměnlivost prostředí Podniky musí brát stále více v potaz proměnlivost vnitřního i vnějšího prostředí. Před současnou systémovou integrací mnohdy stojí požadavek na výměnu nebo úplné odstranění části podnikové 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 takového rozhodnutí překreslí hranice mezi interní a externí informatikou, resp. mezi informatikou a byznysem 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řechodu 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 rozhodně nezmizí, věří Rutrle. „Pomocí integračních platforem lze tuto problematiku ř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í duplicitní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é informatiky patří do ICT strategie podniku. Musí ho udělat management podniku v návaznosti na strategii celého byznysu, dostupnosti lidských zdrojů, finančních zdrojů, know-how apod. Systémová integrace 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 konvergovaný 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í konvergované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 pomůže identifikovat ideální model a způsob fungová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. ■
IV
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 PETR JANO Š
K
valita řízení podnikového IT, jeho spolehlivost, 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 strategie 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á schopnost 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 flexibilita a rychlost mohou jít proti spolehlivosti a kvalitě,“ upozorňuje Moc. Tento „rozpor“ se dá překonat budováním tzv. dvourychlostní IT organizace, kde se na standardní dodávky používá kvalitní 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í dynamičtější společnosti, kde větší úlohu hrají procesy 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é analý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 Klimeš 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živatele 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í architektury v návaznosti na podporované byznys procesy 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é produkty či služby, musí IT útvar dokázat agilně vyhledávat a nasazovat vhodná IT řešení. Toho lze dosáhnout především díky správně nastavené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 pravidelné zapojení IT do přípravy nových služeb a výrobků, tak aby IT mohlo pracovat na budoucích potřebách byznysu s dostatečným předstihem 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í rizik společnosti EY. Uměním IT manažera pak je, aby skloubil hromadící se požadavky na rozvoj 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 finančních institucí v ČR mohu potvrdit, že nejdůležitější je předvídatelnost dodávek IT služeb z hlediska 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 byznys 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 investicemi do řízení IT služeb, varuje Bělina. Podle něj občas dané investice míří správně a koncepč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
CO M P U T E RWO R L D 17–18 | 2014
CW17-II-VIII.indd IV
17.10.14 16:02
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časného řízení IT řadíme schopnost být flexibilní a přinášet a implementovat 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řipravenost IT architektury a dostupnost interních nebo externích relevantních znalostí. Schopnost využít a nasadit inovace v rámci IT vyžaduje zkušenosti s řízením velké změny společnosti a s nasazením řešení v reálném byznysu – 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é podnikové cíle má to, jak se s takovým nástrojem pracuje, podotýká Tomáš Rutrle, jednatel společnosti Komix. Úkolem IT je shromažďovat, zpracovávat a vyhodnocovat podniková data i data o okolí a v zásadě musí být schopné dodávat manaž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ě komplikovat, ani zatěžovat zbytečnými náklady, shrnuje Rutrle.
Vztah IT a byznysu O 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 procesů, 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 konkurenčním prostředí. IT je vnímáno téměř jako útvar 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 pokračuje: „V řadě jiných oborů, napadá mne třeba výroba dusíkatých hnojiv, hraje IT roli zcela okrajovou. Odpověď je tedy různá podle toho, o jakém odvě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 poslední době se podle něj u mnoha společností posouvají IT útvary z role pouhého technologicky orientovaného provozovatele IT služeb do proaktivní role partnera byznysu se snahou o porozumě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 druhou stranu mnoho IT útvarů prochází touto přemě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 nepotřeboval pro svůj chod?“ ptá se Studený z firmy Alvao a pokračuje: „Proto je jasné, že IT služby nemohou existovat bez vazby na byznysové služby. Pokud 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 byznysu 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 nevrá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 souvisí i otázka, zda je IT podpůrný útvar nebo útvar, který je byznysu rovnocenný. „Častěji se setkáváme s částečným či úplným oddě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 rozhodování, nikoliv jen až jako důsledek detailního plánování a úprav obchodních procesů,“ vysvětluje Pavel 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í Plecháč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 technologicky vyspělých společnostech lze najít úzké propojení IT funkcionalit a služeb do procesů, například při obsluze klienta v call centru, dodává Plecháček. „Mnoho firem prohlašuje, že propojuje byznys a IT. Z vlastní zkušenosti mohu potvrdit, že zejména v severských zemích k tomuto propojování hodně dochází a IT je vnímáno jako partner podporují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í vysvětlit byznys straně. Mnohokrát i z neznalosti fungování byznysu dané společnosti a nezvládnuté 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 charakteristická 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ě proaktivita a inovace.
Standardy kontra útvary Standardy 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 nalezne 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 procesním a liniovým způsobem řízení v návaznosti na vhodnost jejich aplikace pro konkrétní procesy, 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í podnikový 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í použitých při řízení podniku to pak znamená integrovat ERP s nástrojem pro projektové či procesní řízení nebo použít přímo integrovaný ▶ CO M P U T E RWO R L D.C Z
CW17-II-VIII.indd V
V
17.10.14 16:02
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ě orientované 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 implementované standardy umožňují srovnání z hlediska efektivity mezi organizacemi a řídicími strukturami. „Nebo ještě jinak: v liniově řízených organizací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 oblasti 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, procesní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í provozních, taktických a strategických cílů, ale také zajistit efektivní přidělování zdrojů a kontinuální revizi celého mechanismu sledování výkonnosti. To vyžaduje uplatnění maticové struktury, kde je nutné nastavit výkonnostní parametry pro více než jeden uvedený způsob řízení. Inspiraci pro řízení výkonnosti v takovéto maticové struktuře lze podle Klimeše hledat například v metodě Balanced Scorecard. Ta umožňuje kombinovat jak procesní, tak liniové klíčové indikátory výkonnosti KPI pro různé úrovně řízení a následně je agregovat tak, aby bylo možné sledovat 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í kombinovat různé pohledy. Základní snahou by mělo být nevytvářet komplexitu, která bude brzdit fungování či rozvoj, ale hledat vhodné kompromisy. Užitečným nástrojem je sladit celkové cíle všech zainteresovaných a dále definovat eskalační procedury a pravomoci pro známé či předpokládané případy, kde by mohlo dojít ke konfliktu 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 členě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.
VI
„Ř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,“ konstatuje 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 podpory 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é skuteč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 Alvao. 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ě procesů a sdílení nástroje, který vyhovuje oběma týmům, dává smysl. Dokonce se to děje i mimo útvar 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é spojování v oblasti personálního, kvalitativního, bezpeč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 procesech je základem prostý selský rozum. Je nutné mít na paměti, že neplánované a neřízené spojová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 produktový produkční charakter, flexibilita s agilitou a s menší mírou centralizace pak v oblasti inovace 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 prostupná) „membrána“ podporovaná managementem a umožňující pronikání odborníků oběma směry, tak aby nevznikala „sila“ či „slonovinové věže“, uzavírá Moc. Podle Štěpána Jarocha z Deloitte Advisory závisejí možnosti sjednocení podpory na typu externí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 využívaných těmito zákazníky. „V případě, že dokážeme identifikovat rutinní, často opakované požadavky, u kterých není vyžadová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ší technické aspekty uživatelských požadavků či vzniklý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í externích a interních uživatelů a služby. „Spojení podpory ve většině případů dává rozhodně smysl,“ tvrdí Bělina z Devoteamu. V současnosti jsou často externí zákazníci preferová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 obchodního oddělení, které nemá problém s hodinovým výpadkem. Rozdělit striktně podporu dává smysl v případech, kdy to vyžadují například legislativní prostředí nebo neslučitelnost jednotlivých podporovaných byznys aktivit, upřesňuje Bělina. „Podle naší zkušenosti firmy velmi zřídka poskytují IT služby interním a externím uživatelům rozdí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. Rozdíl je jen v úrovni formalizace vztahů a v některých případech mohou být jiné požadavky na úroveň služeb definovanou smlouvami SLA. ■
CO M P U T E RWO R L D 17–18 | 2014
CW17-II-VIII.indd VI
17.10.14 16:02
SYSTÉMOVÁ INTEGRACE A ŘÍZENÍ IT
Praktická použitelnost aktuálních verzí ITIL, ISO/IEC 20000 a COBIT Pro 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í.
ITIL Aktuální verze knihovny infrastruktury informačních technologií ITIL (Information Technology Infrastructure Library) nese označení ITIL 2011 Edition a jejích pět ústředních titulů (Service Strategy, Service Design, Service Transition, Service Operation a Continual Service Improvement) 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 procesů, aktivit a funkcí potřebné.
Je zřejmé, že málokterý podnik na světě, pokud vůbec nějaký, potřebuje mít nasazeny všechny tyto procesy, aktivity, funkce a role najednou. ITIL je sbírka nejlepší praxe, což znamená, ž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 postavit, a podle toho si musíme vybírat kostičky, které se k sobě hodí a jež jsou určeny pro
typ objektu, který chceme postavit. Pokud nemá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 inspirovat 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é spokojeni?“, nenajdeme v ITIL, ale v ISO/IEC 20000 a v COBIT. V ITIL můžeme hledat odpovědi na konkrétní otázky typu: „Které role s jakými odpovědnostmi a pravomocemi jsou potřebné pro realizaci procesu XY či aktivity ABC?“, „Na jaký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- ▶
CO M P U T E RWO R L D.C Z
CW17-II-VIII.indd VII
VII 17.10.14 16:02
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 koncová zařízení používají svoje vlastní?“ či „Jak koncept BYOD změní procesy řízení incidentů, problé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.
„pouhý“ kvalitativní standard, jenž může být zají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 eliminovat. Samozřejmě pro podrobné informace, jak tyto prvky designovat, je již třeba sáhnout po ITIL.
ISO/IEC 20000 Tato 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 systé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 aktualizovány a obě jejich verze rovněž byly, jako dosud 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 reference 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 pohledu 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 nemě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 explicitní odpověď na otázku, jaké prvky z ITIL bychom 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 rozsá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
VIII
COBIT Metodika COBIT (Control Objectives for Information 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 strategické, 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 dokonce 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 dosud 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 nekompatibilit v procesním pojetí mezi ITIL a COBIT došlo již s vydáním COBIT 4.0, takže od té doby nic nebrání tomu používat COBIT jako celkový 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 neobsahuje 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 Objective (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 publikací 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 informačních technologií, poslouží publikace Controls 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 Objectives for Cloud Computing vydaný v roce 2011. A našli bychom další užitečné monotematické tituly reagující na nové IT trendy: Securing Mobile Devices Using COBIT 5 for Information Security, 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 konkré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 nalezneme příčinu, aniž budeme experty na problematiku projektového řízení. ■ Potřebujeme zlepšit postupy testování? Mnoho inspirujících prvků najdeme v ITIL publikaci 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 managementu? 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).
CO M P U T E RWO R L D 17–18 | 2014
CW17-II-VIII.indd VIII
17.10.14 16:02
