Nové výzvy systémové integrace Jak řízení IT

Nové výzvy systémové integrace Jak řízení IT

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