Upozornění pro čtenáře a uživatele této knihy
Všechna práva vyhrazena. Žádná část této tištěné či elektronické knihy nesmí být reprodukována a šířena v papírové, elektronické či jiné podobě bez předchozího písemného souhlasu nakladatele. Neoprávněné užití této knihy bude trestně stíháno.

Jaroslav Procházka, Cyril Klimeš

Provozujte IT jinak
Agilní a štíhlý provoz, podpora a údržba informačních systémů a IT služeb

TIRÁŽ TIŠTĚNÉ PUBLIKACE:

Vydala Grada Publishing, a.s.
U Průhonu 22, Praha 7
jako svou 4625. publikaci

Kniha byla schválena vědeckou redakcí.
Členové vědecké redakce pro počítačovou literaturu: Ing. Jiří Přibil, Ph.D., Ing. Petr Odehnal.

Odpovědný redaktor Pavel Němeček
Sazba Tomáš Brejcha
Počet stran 288
První vydání, Praha 2011
Vytiskla Tiskárna PROTISK, s.r.o., České Budějovice

© Grada Publishing, a.s., 2011

V knize použité názvy programových produktů, firem apod. mohou být ochrannými známkami nebo registrovanými ochrannými známkami příslušných vlastníků.

ISBN 978-80-247-4137-6

ELEKTRONICKÉ PUBLIKACE:

ISBN 978-80-247-7294-3 pro formát PDF
ISBN 978-80-247-7295-0 pro formát EPUB

Motivace

Každý, kdo pracuje ve vývoji, provozu, podpoře či údržbě IT systémů (ať již komplexních informačních systémů, základního softwaru, IT infrastruktury či outsourcovaných aplikačních IT služeb) je denně konfrontován s incidenty a jinou operativní činností, díky nimž nemá čas řešit věci systémově, tj. hledat příčiny problémů, automatizovat a vylepšovat poskytované služby. Říkáme, že pracuje v reaktivním módu. Důsledkem toho klesá motivace pracovníků, ti schopní odcházejí, mnohdy nejsou peníze na školení či nákup nových softwarových licencí, a pokud je někdo poslán na školení, neví, jak nově nabyté poznatky zavést v jeho konkrétním prostředí, kde začít s realizací změny.

Další zkušeností je jistá odpojenost manažerů na různých úrovních od produkčních týmů. Tato odpojenost je projevuje několika způsoby:

❚ manažeři se na problémy neptají, chtějí slyšet, že je všechno v pořádku a že dodáme na čas, za dohodnutou cenu a v očekávané kvalitě;

❚ manažeři problémy nevidí, i když na ně členové týmu upozorňují, nebo je ignorují ať již z důvodu nadřazenosti, zbožného přání, že všechno nějak dopadne, či z důvodu neznalosti disciplín vývoje, provozu a údržby IT systémů.

Jednou z příčin této odtrženosti je však také neschopnost členů produkčních týmů problémy vizualizovat v „manažerské“ řeči, tj. co vše je pro realizaci třeba udělat, jaký bude dopad na finance (náklady a přínosy), datum dodání či další sledované ukazatele.

V neposlední řadě podle naší zkušenosti rigorózní formální procesy brání kreativitě a učení. Předpoklad známý z výrobních a montážních procesů, který říká, že do procesu musíme zakódovat detailní znalost, aby pracovníci produkovali očekávaný výstup, v této abstraktní a komplexní oblasti, kterou je práce s IT systémy, nefunguje. Proces popisující veškeré aktivity, který nedává prostor pro chybu, nedává prostor ani pro kreativitu a omezuje příležitost k učení (kolik z vás se setkalo buď s procesem či příkazem sdělujícím: „Teď máš dvě hodiny na to být kreativní a přinést lepší řešení…“?). Právě učení a kreativita je ale to, co odlišuje procesy tvorby a provozu IT systémů od procesů montážních. Detailní preskriptivní proces je také těžké denně měnit z důvodu adaptace na rychle se měnící podmínky trhu a znalostní ekonomiky dneška. Před několika dekádami a snad ještě i jednotkami let byl ustálený detailní proces předpokladem úspěchu. V dnešní turbulentní době musí organizace rychle reagovat na měnící se požadavky a potřeby zákazníků a trhu samotného. V neposlední řadě takové procesy brání učení tím, že mají dlouhou dobu odezvy přinášející zpětnou vazbu (produkt až na konci vývoje, komentář zákazníka v momentě, kdy už je těžké něco měnit, apod.). Člověk se učí a zlepšuje okamžitou zpětnou vazbou. Proto si například vývojáři používající vývojářské (unit) testy, tento přístup tak chválí, protože dostanou odpověď na kvalitu svého kódu v řádu sekund. Chyba, kterou by opakovali neustále v jakékoli napsané komponentě, může být odstraněna ihned.

Problémem organizací je také sub-optimalizace v rámci organizačních jednotek vystavěná na domněnce, že výsledný výstup bude správný a nejlepší (firma bude úspěšná), jen když bude správný a nejlepší výstup každé jednotky (zisková a prosperující bude každá jednotka). Proto dekomponujeme cíle jednotlivých organizačních jednotek a očekáváme, že přispějí k celkovému cíli. Místo spolupráce však dostaneme soupeřící prostředí, které neprodukuje to, co jsme očekávali. Příkladem může být plně ziskové a fungující vývojové oddělení doručující kód rychle bez potřebného testování a následování dobrých praktik, na což doplatí oddělení provozu a údržby, které bude přetížené a bude muset odstraňovat problémy zanesené při nekvalitním vývoji. Jaký je navíc smysl maximální ziskovosti oddělení údržby? Neměli bychom se spíše snažit vytvářet, dodávat a provozovat maximálně kvalitní produkt či službu přinášející hodnotu a obsahující minimum chyb? Teorie systémů [FJ93], [Se09] nám odhaluje, že výsledný systém není pouhým složením jeho částí, ale spíše výsledkem interakcí těchto částí. Úspěch systému tedy závisí na tom, jak dobře spolu jednotlivé části kooperují. Teorie omezení [Sc99], [Go1], [Go2], [Go3], systémové myšlení [Se09] a štíhlá (Lean) filozofie [Po06], [Po09] jasně ukazují, že pro úspěch celku (firmy) je třeba odstraňovat úzká místa systému a optimalizovat celek.

Tato kniha vznikla jako reakce na výše popsané problémy. Cílem knihy není přinést teoretický postup, který je vzdálený od problémů v realitě, ani znovu vynalézat již vynalezené. Naším cílem je naopak poskytnout poznatky a předat zkušenost s agilním a „štíhlým“ (ve smyslu anglického Lean) způsobem provozu a údržby IT systémů (komplexních informačních systémů a IT služeb provozovaných interně či třetími stranami). Agilní a štíhlé přístupy jsou ověřeným přístupem k tvorbě softwaru. O jejich použití v kontextu provozu, podpory a údržby informačních systémů, respektive IT služeb mnoho literatury nenalezneme. Většina zmínek je o jejich nízké aplikovatelnosti v této oblasti či o aplikaci konkrétních metod jako je Extrémní programování nebo Scrum. Je však pravdou, že pokud organizace vyvíjí software agilně, pak její proces již v sobě obsahuje i údržbu. Kniha, kterou držíte nyní v rukou, má za cíl prezentovat holistický přístup k agilnímu a štíhlému provozu a údržbě, který je postaven na zkušenostech z denní praxe. Holistický přístup musí pokrývat nejen provoz, podporu a údržbu, ale nutně musí být zaměřen i na proces vývoje IS a IT služeb, organizační strukturu a řízení organizace či způsob uzavírání a formu kontraktů. Zaměření pouze na provoz, podporu a údržbu IS a IT služeb by byl sub-optimalizací jen jedné části celku. To je důvod, proč v celé knize zmiňujeme návaznost na prodej, proces vývoje či celkovou organizaci a způsob vedení firmy. Postupy jsou popsány ve formě principů, praktik i konkrétních doporučení a příkladů z praxe.

Kniha je zaměřena na podporu činnosti pro všechny pracovníky provozu a údržby, vývoje i obchodu, na manažery i výkonné pracovníky:

❚ pracovníky (interního či externího) Service Desku na všech úrovních;

❚ vývojáře opravující chyby a implementující změny;

❚ testery či test manažery;

❚ specialisty sestavující pravidelné verze a výsledný produkt;

❚ obchodníky a týmy připravující nabídky pro výběrová řízení;

❚ a také (či spíše především) manažery pomáhající těmto lidem (manažery pro styk se zákazníky, projektové manažery či manažery služeb, liniové manažery, dokonce i CEO, CIO).

Běžná námitka, kterou můžeme slyšet při představení principů agilního a štíhlého provozu a údržby, je následující: „Toto není nic nového, vždyť už je všechno popsáno ve standardech a existujících procesech.“ Potom je nasnadě ptát se:

❚ Proč je stále takový problém s chybovým softwarem a neúspěšnými projekty (kterých je více než polovina, viz [SG])?

❚ Proč se zvyšuje cena provozu a údržby mnohdy dosahující až 90 % celkových IT rozpočtů firem (vlastní zkušenost z velkých mezinárodních společností a empirické výzkumy [Ga08IT], [Ga09IT], [Ho08], [Bo81])?

❚ Proč je velká fluktuace a demotivace lidí v týmech podpory a údržby, když všechno funguje, jak má a je přesně popsáno ve standardech?

Odpovědí je několik. Jednou z nich jsou procesy nerespektující lidskou přirozenost, tj. nepochopení specifik jednotlivce, potřeby zpětné vazby, prostoru pro kreativitu a učení. Důsledkem je návrh firemních systémů (procesů) jdoucích proti lidské přirozenosti, nefungující učení či chybějící napojení služeb a projektů na podnikové cíle zákazníka. Proto chceme popsat zkušenost s procesně orientovanými frameworky, standardy a metodami, které tyto aspekty opomíjí, a uvést agilní a štíhlý provoz, podporu a údržbu IT systémů (IT služeb a informačních systémů) tak, jak jej používáme a jak jsme si ověřili jeho účinnost v praxi na projektech a službách v České republice, Evropě (převážně Skandinávii) a Indii.

Dnešní procesní přístupy k provozu a údržbě jsou několik (až desítky) let zpožděny za stavem ve vývoji softwaru a s tímto zpožděním evoluci v metodách vývoje softwaru kopírují. Přístupy k vývoji softwaru prošly od ad hoc vývoje v raných dobách tvorby softwaru, přes detailní a rigorózní procesy až po dnešní stav prezentovaný převážně iterativně inkrementálními (resp. agilními) přístupy s důrazem na tým a učení, komunikaci se zákazníkem a delegaci rozhodování. Proč se tedy nepoučit z evoluce přístupů vývoje softwaru a nepřeskočit slepé evoluční větve? O tento krok se snažíme.

Úvodní kapitoly knihy se věnují představení pojmů a současných problémů oblasti provozu a údržby IT systémů, resp. informačních systémů a IT služeb. Mezi hlavní problémy patří rostoucí procento nákladů na provoz a údržbu, které ubírají z financí na inovace a nové projekty. Součástí je také představení současného stavu na poli metod, standardů a metodik pro provoz a údržbu softwaru, IS a IT služeb (zajímá nás tedy hlavně způsob práce a řízení v této oblasti). Úspěšnost těchto metod je diskutabilní, proto kapitola přináší empirické důkazy z akademické i industriální sféry a diskutuje možná řešení založená na agilních a štíhlých principech.

Jádrem knihy jsou principy agilního a štíhlého provozu a údržby, které se ale ve smyslu systémového myšlení nezaměřují jen na provoz, podporu a údržbu, ale integrují tyto činnosti do celého řetězce doručování hodnoty zákazníkovi, tj. do vývoje, obchodu i řízení firem. Agilní principy představují základní filozofii přístupu k provozu a údržbě, která pokrývá jak provozní, tak také řídicí činnosti organizace. Praktiky pomáhají aplikovat tuto filozofii do denních činností v řízení, provozu a údržbě. Pro snazší pochopení a implementaci dané filozofie a praktik se kniha snaží přinést množství příkladů z praxe a popsat těžkosti a návody k řešení reálných situací, se kterými jsme se setkali.

Ve třetí části je představen důležitý aspekt agilního a štíhlého provozu, údržby a podpory, který je často opomíjen, jedná se o tzv. soft aspekty (komunikace, týmová práce, typologie a psychologie lidí) a poznatky kognitivních věd. Většina pracovníků v IT sféře má vzdělání technického či ekonomického směru, díky němuž rozumí a chápe, jak fungují přírodní zákony, matematické důkazy, či pravidla trhu a oběhu peněz, ale znalost lidského chování, pochopení nepředvídaných reakcí, způsobu myšlení či společné spolupráce je z teoretického i praktického pohledu minimální. Avšak právě tyto aspekty jsou při vývoji, provozu a údržbě kritické, jelikož software je tvořen kreativními lidmi a díky své nehmatatelné přirozenosti je jeho diskutování a mentální uchopení obtížnější. Do této části je zařazena také diskuse o kontraktech, jelikož jsou počátkem (resp. dalším nezbytným krokem po optimalizaci pracovního postupu týmu) všech projektů a služeb a jelikož nevhodně nastavený kontrakt může významně omezit jakoukoli možnost interní změny či zlepšení.

Moderní přístupy řešící problémy provozu a údržby deklarují a významně používají nástroje nové generace, mezi něž patří například umělá inteligence či 3D modely a světy. Proto jsou některé z nich představeny v závěrečné části knihy. Tyto přístupy však vyžadují významné investice do nástrojů, procesů, lidských kapacit a schopností. Cílem této knihy je snaha o představení principů a technik, které mohou se stávajícími nástroji a lidským personálem zásadně zefektivnit provoz a údržbu informačních systémů či IT služeb. Cílem je tedy zlepšení poskytovaných služeb a efektivnosti týmu s minimem finančních investic. O to více je třeba osobní investice každého pracovníka či manažera (změna myšlení a chování, nalezení vůdců uvnitř týmů apod.).

Struktura knihy je následující:

Úvod

Zaměření a aplikovatelnost popsaného přístupu

Kniha je zaměřena na provoz, podporu a údržbu informačních systémů a IT služeb, a tudíž se jako taková zabývá hlavně softwarem a aplikacemi a způsobem práce na úrovni týmů. Ve většině případů však bereme v potaz také oblast správy infrastruktury a nutnost komunikace mezi týmy vývoje a provozu (respektive údržby). Ve většině případů se tedy nebudeme omezovat jen na správu informačních systémů a IT služeb z pohledu softwaru. Další perspektivou, kterou je nutné uvážit, je perspektiva řídicí versus věcná. Zaměřujeme se převážně na perspektivu věcnou, tedy jaké kroky, jak a kdy vykonávat při provozu a údržbě na úrovni týmů a jejich vedoucích. Zaměřujeme se ale také na perspektivu řídicí na úrovni vedoucích týmu a samo-řízení týmu, méně již na perspektivu řídicí na úrovni středního a vyššího managementu (CIO, CEO). I pro organizační a řídicí perspektivu vyšší úrovně však máme určitá doporučení a vzory týkající se delegace pravomocí, řízení a rozdělení týmů.

Pro čtenáře neznalého agilních a štíhlých principů je nutné již na úvod zbořit jeden mýtus. Totiž chaos a neřízenost není agilita a už vůbec ne štíhlost (z anglického Lean). Agilní principy by mohly evokovat jistou vágnost a neformálnost v pozadí agilních přístupů. Opak je však pravdou a také na tomto nepochopení ztroskotává mnoho implementací těchto principů do praxe. Agilita je silně disciplinovaný způsob práce, stavějící na lidské disciplíně, plnění závazků a důvěře mezi všemi zúčastněnými stranami. Bez těchto pilířů se nedá o agilitě mluvit. Ostatně to dokazují příklady empirických studií popisující existující implementace agilních přístupů v organizacích s certifikovanou úrovní CMMI ML5 [Su08]. Více o základních principech viz kapitola 2.

Přístup zde představený byl aplikován v týmech českých i zahraničních firem, od malých (desítky zaměstnanců) po velké mezinárodní (desítky tisíc zaměstnanců). Jednalo se o různě velké týmy, organizace, zákazníky i velmi rozdílné problémové domény (telekomunikace, veřejný sektor, bankovnictví) a také zcela rozdílné technologie, od specifických Business inteligence, přes skriptovací jazyky, Javu, .NET, Perl až po různé databáze s vnořenými procedurami. Představený přístup je navíc založen na principech, které je samozřejmě nutné implementovat v kontextu daných organizací. K tomu použijeme různé praktiky s odlišným důrazem. Proto tvrdíme, že na úrovni týmů a nižšího managementu je možné tento přístup použít téměř univerzálně při respektování rizik a předpokladů přístupu. Jistá omezení vyplývají jen z:

❚ technologií (objektově orientované mají větší potenciál ke zvýšení efektivnosti, bezpečnosti a produktivity vývoje a nástrojů třetích stran);

❚ požadavků na detailní dokumentaci v papírové formě (dokumentace v představeném přístupu má spíše spustitelnou formu);

❚ organizační struktury a procesů organizace (role definované organizací, způsob rozhodování, reportování).

Tradičním omezením použitelnosti přístupu jsou také kontrakty, jelikož v některých případech specifikují způsob práce, průběžně dodávané artefakty (většinou ve formě papírové dokumentace popisující budoucí změnu, řešení) a zapojení zákazníka. K jistým omezením aplikovatelnosti přispívá také nutná důvěra mezi týmem a zákazníkem, možnost být se zákazníkem ve spojení, možnost automatizovat určité kroky a také ochota lidí změnit se. Tyto body jsou největším omezením představeného přístupu. Více detailních informací o aplikaci popsaného přístupu v konkrétních IT službách a výsledcích této aplikace uvádíme v kapitole 7.4.

Prohlášení a poděkování

Autoři si nepřisuzují žádné zásluhy za vynalezení agilních a štíhlých metod, praktik či jejich principů. Tyto byly představeny, aplikovány a popsány řadou významných autorů, z nichž jmenujme například Kenta Becka, Kena Schwabera, Mika Cohna, Scotta W. Amblera či Mary Poppendieck. V odborné literatuře z oblasti softwarového inženýrství se s těmito principy můžeme setkat již od 70. let minulého století, v oblasti managementu dokonce již v 30. a 50. letech minulého století (viz analýza v [NC10], [Ri10]). Osobně jsme ale s těmito přístupy a disciplínami roky pracovali, zkoumali, experimentovali, kombinovali a zkoušeli aplikovat v různých oblastech (konkrétně vývoj, provoz, údržba, Service Desk, vztah se zákazníky – CRM a kontrakty), organizacích a službách. Naším přínosem je tedy definice principů agilní údržby a způsobu jejich aplikace v praxi. Cílem agilního a štíhlého provozu a údržby není implementovat nový postup, tento postup je pouze prostředkem k ustavení prostředí pro udržitelné dodávky kvalitní (naplňující potřeby a očekávání uživatelů) IT služby, informačního systému s vestavěným mechanismem zlepšování. Jedná se o holistický pohled zaměřený na disciplínu řízení a inženýrské disciplíny, jenž je výsledkem praktických zkušeností obsahující prvky systémového myšlení [Se09], agilních a štíhlých přístupů (např. [Be99], [Co04], [Kr03a], [Kr03b], [Lu05], [Po06], [Sch04] či česky [Bu09], [Pr07b], [Pr09]), principů IBM Measured Capability Improvement Framework® [Kr07] a praktik správy IT služeb [ITIL]. Cílem knihy je poskytnout popis principů a jejich aplikace na množství příkladů v kontextu provozu a údržby včetně implementačního přístupu.

V celé knize budeme používat terminologii, která je běžná v oblasti provozu a údržby a vychází ze standardu IEEE Std. 610.12 [IEEE] a také ze zavedené terminologie správy IT služeb [ITIL], které jsou brány jako de facto standard v diskutované oblasti. Více se definici některých důležitých pojmů budeme věnovat v úvodních kapitolách, případně při jejich prvním výskytu. Následující úvodní vymezení pojmů uvádíme z důvodu sjednocení jazyků čtenáře a autorů. Pojmosloví je důležité hlavně v případě pojmů jako incident a problém, které jsou v intuitivním použití zaměňovány jako jeden koncept.

Tato práce nemohla vzniknout bez přispění kolegů, spolupracovníků, týmů provozu a údržby a denní spolupráce s nimi, proto naše poděkování směřuje všem těmto lidem a především kolegům, členům P&M týmu, díky nimž jsou naše názory denně podrobovány konstruktivní kritice a zpětné vazbě ať již náhodně nebo formou pravidelné párové a týmové práce. V této knize jsou využity výstupy interních grantů Ostravské univerzity „Softwarový nástroj pro fuzzy modelování“ (reg. číslo SGS19/PřF/2010) a „Fuzzy modelovací nástroj pro testování informačních systémů realizujících business procesy“ (reg. číslo SGS20/PřF/2011) a také výzkumného centra MŠMT ČR Data-Algoritmy-Rozhodování (projekt 1M0572), v nichž jsou autoři zapojeni.

Recenzenti:

❚ doc. Ing. Alena Buchalcevová, Ph.D., Vysoká škola ekonomická v Praze

❚ Ing. Lubomír Jankových, CSc., Bankovní institut vysoká škola, a.s. Praha

❚ PhDr. Jarmila Kristiníková, Ph.D., Ostravská univerzita v Ostravě (kapitola 4)

❚ RNDr. Martin Štěpnička, Ph.D., Ostravská univerzita v Ostravě (kapitola 8)

Úvodní definice pojmů

Provoz (ve smyslu anglického Operations) – pod tímto pojmem rozumíme veškeré aktivity týkající se denních operativních činností prováděných za účelem bezproblémového doručení IT infrastruktury a také programového vybavení (software) zákazníkovi.

Údržba (ve smyslu anglického Maintenance) – pod tímto pojmem rozumíme veškeré aktivity týkající se navození, nalezení, odstranění a testování chyb, implementace změněných a nových funkčností. Nedílnou součástí údržby je také proaktivní zkoumání ICT infrastruktury a programového vybavení, sledování trendů a jejich predikce za účelem odhalení a odstranění možných příčin incidentů.

Podpora (ve smyslu anglického Support) – pod tímto pojmem rozumíme reaktivní podporu uživatelů IT služeb na několika úrovních (řešení incidentů, poskytování informací, samoobslužné služby apod.) a také proaktivní informování uživatelů o budoucích změnách, poskytovaných službách či případných problémech.

Dodávka softwaru/řešení (ve smyslu anglického Release) – pod tímto pojmem zahrnujeme jak aktivitu dodání softwarového řešení či jeho aktualizace, tak i konkrétní dodávaný produkt či jeho aktualizaci. Proces, který tyto aktivity zastřešuje, nazýváme Release Management.

Incident – jedná se o událost, která má neblahý dopad na kvalitu provozované služby, snížení dostupnosti, nefungující službu, menší počet zpracovávaných transakcí apod. Často je tento pojem znám také pod obecnějším pojmem tiket.

Problém – neznámá příčina jednoho či více incidentů v ICT infrastruktuře či programovém vybavení.

Změna či požadavek na změnu (CR – Change Request) – požadavek zaměstnanců pracujících s aplikací či službou nebo požadavek IT oddělení/týmu na změnu v IT infrastruktuře či v programovém vybavení.

Dohoda o úrovni služeb (Service Level Agreement – SLA) – jedná se o dohodu (pozor, ne formální smlouvu) mezi dodavatelem a odběratelem IT služby, která specifikuje kvalitativní cíle poskytované IT služby, odpovědnosti obou stran, způsob měření a reportování. Obvykle bývá součástí kontraktu.

ICT (Information and Communication Technology) – informační a komunikační technologie. Pojem zahrnuje nejen hardwarové a síťové prvky, ale také softwarové vybavení (základní a aplikační software). Komunikační technologie značí prostředky pro komunikaci mezi počítači resp. s jejich pomocí.

ICT infrastruktura – technologie a prvky nutné k provozu IT, jedná se nejen o vlastní využívaný software (poskytovaný často jako IT služba), hardware (datová centra, servery, počítače, notebooky), základní software (operační systémy, databáze), sítě a síťové prvky, ale také o periferie (monitory, tiskárny, skenery), telefony a telefonní ústředny. Jedním z prvků ICT infrastruktury jsou IT systémy.

IT systém – pod tímto pojmem rozumíme převážně aplikace podnikové informatiky (zahrnující jak základní, tak aplikační software) včetně různých forem jeho provozu (IT služba, Application Service Providing – ASP, Software as a Service – SaaS). Více o tomto tématu viz kapitola 1.

IT služba – tento pojem chápeme v kontextu jak interních, tak externích poskytovatelů různých částí IS. IT službou tedy nechápeme pouze formu outsourcingu, ale obecně poskytování a provoz určitého modulu, sady funkčností IS (zahrnující potřebnou ICT infrastrukturu, základní i aplikační software, prostory, licence, lidi, data) podporující podnikové procesy organizace. Více o tomto tématu viz kapitola 1.

Podnikový proces (Business process) – jedná se o sled činností prováděných zaměstnanci za účelem doručení hodnoty koncovému zákazníkovi. Tento pojem zahrnuje jak procesy obchodní (prodej, nákup), personalistiku, ekonomiku, tak také výzkum, výrobu, skladování či jiné specifičtější procesy. Často se můžeme v české literatuře setkat s omezeným překladem „obchodní proces“, což je však pouze malá podmnožina všech procesů existujících v podniku, které je možné podporovat IS či IT službou.

Tyto pojmy budou blíže vysvětleny v kontextu dále v textu, především v kapitole 1. Cílem tohoto úvodního vysvětlení je snaha upozornit na pojmosloví, abychom předešli nepochopení z důvodu neznalosti dané terminologie.

Použité piktogramy uvozující jednotlivé části kapitol za účelem dosažení vyšší čitelnosti a strukturovanosti této knihy.

Vymezení důležitého pojmu či definice

Případová studie či delší příklad

Praktická ukázka či krátký příběh z praxe jsou uvedeny v ohraničeném boxu na šedém pozadí.

Vymezení pojmů a problému, současný stav

V úvodu jsme zmínili pojem IT systém, informační systém a také IT služba. Tyto pojmy nejsou synonyma a mají své definice a rozdílný význam, který vysvětlíme v této kapitole. Pro pochopení aplikace principů agilní a štíhlé podpory a údržby přiblížíme také koncept a princip IT služeb, jelikož k němu v dnešní době směřují i interní poskytovatelé IT. Dále se v kapitole budeme zabývat vymezením kontextu a základních pojmů v oblasti provozu, podpory a údržby IT systémů. Představíme základní aspekty a problému současných postupů a také postupy samotné.

1.1 IT systém, informační systém, IT služba

V průběhu posledních desítek let se změnilo jádro problémů, které řešíme pomocí softwaru. Cílem dřívějšího softwaru bylo automatizovat rutinní a strukturované úkoly, příkladem jsou typické aplikace dané doby, tzv. Transaction Processing Systems – TPS či první typy manažerských informačních systémů (MIS). První MIS systémy byly orientovány na sběr a ukládání dat produkovaných transakčními systémy, pozdější pak začaly používat tato data ke generování reportů různého typu (trendy, souhrny, výjimky) podporujících řízení [LL09]. Zákazníků, respektive zainteresovaných osob (anglicky stakeholders) bylo u těchto typů projektů málo a měli dosti podobné potřeby, které byly interním vývojářům více méně známy. Jejich výraznější zapojení do projektu proto nebylo ani vyžadovalo ani očekáváno. V průběhu času se však změnila povaha projektů od výše zmíněných k projektům strategického rázu.

Informační systém (IS) lze podle Laudona a Laudona [LL09] chápat jako:

„Sociálně-technický systém, ve kterém lidé, technologie, podnikové procesy a organizace na sebe navzájem působí ve snaze sbírat, zpracovávat, archivovat a distribuovat informace s cílem podpořit řízení, koordinaci a rozhodování v organizaci.“

Informační a komunikační technologie (ICT) (hardware, software, telekomunikace) jako kritická komponenta IS hrají rozhodující roli v transformaci podnikání. Poutavý pohled na tuto transformaci přináší formou příběhu Goldratt v [Go1] a [Go2], kde také ukazuje problémy, které mohou díky této významné transformaci nastat. Goldratt poskytuje řešení ve formě Teorie omezení (ToC). Některé z nástrojů Teorie omezení také využíváme v našem implementačním postupu. O’Hara poskytuje konceptualizaci tří úrovní změn, které se zrodily díky zavedení IT. Každá úroveň změny ovlivňuje technologii, podnikové procesy, lidi a organizaci různě [Oh99]:

❚ Změna prvního řádu zahrnuje prvotní snahy IT o automatizaci rutinních úkolů, kdy technologie a procesy hrají primární roli.

❚ Změna druhého řádu ovlivňuje pracovní zvyklosti a ustálené role a zdůrazňuje sociální dimenzi a potřebu porozumět složitým vztahům mezi lidmi, technologiemi a procesy. Cílem těchto systémů není pouhá automatizace, ale také poskytování hodnotné a přesné informace ve správný čas za účelem využití příležitostí, které nabízí trh.

❚ Změna třetího řádu má dalekosáhlý vliv na organizaci, změnou nejsou ovlivněni pouze lidé, technologie a procesy, ale také struktura samotné organizace.

Tuto konceptualizaci O’Hary můžeme shrnout následovně. Čím vyšší řád změny způsobený IS, tím větší dopad na efektivitu, konkurenceschopnost a strategickou orientaci organizace. Naproti tomu změny vyššího řádu s sebou přináší nejistotu a je mimořádně obtížné je vykonávat a řídit [NC10]. Co to znamená, že je orientace dnešních projektů více strategická? Odpověď můžeme opět najít v publikacích z různých disciplín. Strategické projekty jsou podle [MR76] méně strukturované a nelze je zcela přesně a konkrétně vymezit pro potřeby rozhodnutí. Dále podle [DW83], jak se projekty stávají více strategickými, zahrnují více oblastí a disciplín (tzv. cross-functional), které přesahují tradiční ohraničené funkční jednotky jako je marketing, provoz, výroba či nákup. IT již také není konkurenční výhodou, ale nutností a tak se konkurenční výhodou stává spíše rychlost implementace nových služeb, respektive reakce na změny trhu. Důsledkem těchto tvrzení je fakt, že strategické projekty mají zřídkakdy „jediné nejlepší řešení“. Zvlášť vhodné pro tento typ strategických projektů se ukázaly agilní přístupy [NC10], [Ri10]. Tento fakt je třeba si uvědomit a promítnout jej také do postupů vývoje, ale také provozu, podpory a údržby informačních systémů. Je tedy nezbytné definovat metodiky a postupy založené na principech, ne na detailně popsaných procedurách, kdy dané principy budou v konkrétních případech implementovány rozdílnými technikami.

Výše v textu jsme již poskytli definici informačního systému, nyní ještě definujeme pojem IT systém, IT služba či podniková informatika a vymezíme se v jejich chápání a použití v následujícím textu.

„IT systémem rozumíme obecný systém využívající IT infrastrukturu, základní či aplikační software k jistému účelu, kterým nemusí být nutně podnikání. Tento pojem zahrnuje různé typy aplikací a také formy jeho provozu.“

Podnikovým informačním systémem potom rozumíme oblasti IT systémů, které jsou využívány podniky k podpoře a řízení podnikových procesů a mohou být také nositelem nových obchodních příležitostí [GP09]. Prvky podnikového IS jsou pak kromě ICT také lidé či data.

V textu také dále zmiňujeme aplikovatelnost našeho postupu na provoz, podporu a údržbu informačních systémů (IS) či IT služeb. Pojem IT služba je detailněji vysvětlen v následující kapitole. Pro základní představení však můžeme říci, že IT službou uvažujeme jak interní, tak externí poskytování různých funkčností IS koncovým uživatelům, bez nutnosti provozovat či vlastnit určité specifické části, pracovníky, prostory či licence. IT službou tedy nechápeme pouze formu outsourcingu, ale obecně poskytování a provoz určité sady funkčností, modulů IS (zahrnující potřebnou ICT infrastrukturu, základní i aplikační software, prostory, licence, lidi, data) podporujících podnikové procesy organizace.

1.1.1 Informační systém versus IT služba

Pojem služba se v ICT vyskytuje v různém kontextu. Se službou se můžeme setkat jako se základním prvkem servisně orientované architektury (Service Oriented Architecture – SOA). Typický význam slova služba je poskytovaná služba dodavatelem, například poskytovaná telefonická podpora řešení problémů či garantovaná rychlost implementace změn při změně zákonů. V neposlední řadě je pojem služba uvažován v kontextu řízení provozovaných aplikací, spíše a pouze jen v jejich outsourcované formě. Více o této problematice lze nalézt například v [GP09] nebo [Voř08]. V dnešním světě však již nelze odlišovat infrastrukturu od aplikací a ostatních služeb (konzultace, školení, právní služby). Zákazník dnes očekává dodání IT jako celku „na klíč“, bez ohledu na potřebu počtu licencí na software, serverů, nutné šířky pásma, prostor, lidí či tiskáren. Zákazník prostě po IT chce, aby podpořilo a zefektivnilo jeho podnikové procesy, případně vygenerovalo nový trh či nový typ služeb. Zákazník také očekává, že IT bude reagovat na jeho potřeby, potřeby podnikání a trhu. Proto je nutné se na poskytování různého typu softwaru, převážně však systémů podnikové informatiky a infrastruktury (ať sítí, hardwaru či základního softwaru), dívat jako na komoditu, ne na její jednotlivé části zvlášť. V takovém stavu pak oddělení či podnik musí dokonce hrát roli koordinátora jednotlivých složek či poskytovatelů IT. Tento obrázek je často zdrojem chápání IT jako nutného nákladu, který nepřináší hodnotu, viz například výzkum [Mat] nebo [Voř08].

1.1.2 Pojetí IT služby

V dnešní době častých a rychlých změn je tedy nutné, aby organizace upustily od orientace na provoz a poskytování hardwaru, softwaru, infrastruktury a staly se poskytovateli IT služeb podporujících podnikání dané organizace přesně podle jejich potřeb. Poskytování IT služeb je v našem odvětví stále ještě chápáno pouze jako oblast outsourcingu. Interní IT oddělení pracují a fungují stále jako nákladová centra poskytující hardware a jeho správu, stejně tak jako software a jeho správu. Uživatel se pak musí sám snažit dostat k IT týmům a sdělit, co vlastně potřebuje, pokud možno v IT řeči. IT již dávno není v dnešní době chápáno jako konkurenční výhoda, ale jako nutnost, proto je třeba zviditelnit výdaje na IT, jejich smysl a účelnost. Poslední výzkumy rozpočtů ukazují, že výdaje na provoz a údržbu IT neustále stoupají (při téměř stejné hodnotě IT rozpočtů) a tudíž zbývá méně na vývoj nových funkčností IS a IT služeb zvyšující konkurenceschopnost organizace (viz např. [Ga08IT], [Ga09IT]). Ve skutečnosti je třeba, aby nejen poskytovatelé outsourcovaných služeb, ale naopak hlavně interní poskytovatelé IT začaly chápat IT jako celek, jako službu a snažili se ji co nejvíce a flexibilně propojit s potřebami podnikání daného subjektu.

Pojďme nyní představit definici služby podle ITSM instance zvané ITIL®. ITIL® je celosvětově rozšířený framework [Mat] k řízení a poskytování IT služeb a jako takový propaguje propojenost podniku a jeho procesů s IT pokud možno ve formě IT služeb. ITIL® o službě říká následující [ITIL]:

„A service is a means of delivering value to clients by facilitating outcomes clients want to achieve without the ownership of specific costs and risks.“

Česky bychom zmíněnou definici mohli volně přeložit následovně [ITCZ]:

„Služba je prostředek dodávání hodnoty zákazníkovi tím, že zprostředkovává výstupy, jichž chce zákazník dosáhnout, aniž by vlastnil specifické náklady a rizika.“

Dva základní principy, které jsou v definici zmíněny, jsou:

❚ Služba musí podle definice pomáhat uživatelům k dosažení požadovaných (podnikových) cílů.

❚ Klient si kupuje služby za účelem přenesení rizik a nákladů na odborníka.

Z definice je tedy jednoznačně vidět propojení podnikových cílů organizace s IT. V následující části představíme výsledky výzkumu společnosti Materna, který odhalil, že za skutečnou podporu podnikání považuje IT pouze malé procento manažerů středních a velkých společností (a to nejen v ČR ale i v Evropě), naopak většina z nich považuje IT za náklad, což je dost špatný obrázek, když si uvědomíme, že dnešní podniky bez IT téměř nemohou fungovat (rozhodně ne v případě bankovních domů, telekomunikačních operátorů, pojišťoven, leteckých operátorů). Proto je nutné orientovat řízení IT na podporu podnikových procesů a zahájit pravidelné diskuse s koncovými uživateli našich služeb (tento princip a techniky, jak principu dosáhnout, bude popsán dále v této kapitole a také v kapitole 2.2).

Abychom si udělali obrázek, co v praxi taková IT služba je, uvedeme několik příkladů:

❚ poskytování e-mailu;

❚ poskytování informací o průběhu doručení poštovní zásilky v kurýrních službách (ať pro potřeby dispečerů a obchodníků, tak pro potřeby vlastního zákazníka);

❚ podpora monitorování vytíženosti lůžek a operačních sálů v nemocnici (tato služba má přímý dopad na obrat/zisk nemocnice, volné lůžko totiž znamená možnost příjmu dalšího pacienta, IT systém umožní zviditelnit obsazenost a také „poptávku“ na tato lůžka).

Jelikož je většina čtenářů tohoto textu technicky orientovaná, je dobré si představit také pozadí IT služby, z čeho všeho se tedy IT služba skládá, co je viditelné pro uživatele, případně pro jakou část IT. Situaci názorně ukazuje následující obrázek:

Obrázek 1.1: IT služby, jejich pozadí a také viditelnost pro koncové uživatele (zdroj: vlastní)

Jak je z obrázku zřejmé, IT služba se skládá z různých komponent, mezi které patří hardware serverů a stanic a software na nich běžící (autorizace a autentifikace, firewally, databáze, middleware, aplikační servery), datová úložiště, mainframe systémy, sítě a síťové prvky nutné k doručení IT služby k zákazníkovi (často také internet jako páteřní síť) a samozřejmě vlastní aplikace/jejich kombinace či část informačního systému. Všechno toto by mělo být běžnému uživateli neviditelné, jakoukoli chybu či pokles kvality by měl reportovat jako incident^1 spojený s danou službou.

IT naopak technické informace potřebuje. Proto, aby tým podpory mohl urychleně vyřešit nějaký incident, který nastal v infrastruktuře, nějaký výpadek či pokles kvality, je třeba vědět, jaké aplikace, síťové prvky či hardware podporují běh dané služby. Jelikož je IT služba konzumována koncovými uživateli s doménovou znalostí a podporována IT profesionály, měla by být popsána z obou pohledů včetně popisu odpovědností jednotlivých stran. IT služby většinou popisujeme v katalogu služeb (více viz následující kapitola).

Cíle a kvalita poskytovaných IT služeb, stejně jako odpovědnosti dodavatele a odběratele služby, způsob měření a reportování výsledků bývá specifikována v dokumentu Dohoda o úrovni služeb, takzvané SLA (Service Level Agreement). Tato dohoda bývá většinou součástí kontraktu o poskytování IT služeb, jelikož samotná nemá status smlouvy, ale pouze dohody.

Pokud je tedy cílem IT poskytovat služby, vše z pohledu IT by se mělo točit kolem správy a řízení IT služeb (anglicky ITSM – IT Service Management). Následující obrázek znázorňuje místo IT služeb a jejich správy, podnikových procesů a podnikové strategie. Obrázky 1.1 a 1.2 popisují kontext, kde základem podniku je jeho podniková strategie, která definuje směr, kterým se chce podnik ubírat. Dále co prodává či jaké nabízí služby, na jaké zákazníky se zaměřuje, v jakých lokalitách chce působit, zda bude mít kamenné pobočky či pouze elektronický obchod a spoustu dalšího. Pro realizaci těchto cílů slouží podnikové procesy (více o podnikových procesech a procesním řízení viz například [Ře06] a [Pr06]). Proto, aby mohly být podnikové procesy efektivně vykonávány, používáme IT služby, jež dané podnikové procesy podporují. K provozu těchto služeb využíváme ICT infrastrukturu, aplikace, týmy IT expertů. Samotné služby pak potřebují být také nějakým způsobem spravovány, tj. definovány, nasazovány, provozovány, k tomu slouží správa IT služeb.

Obrázek 1.2: Vztah podnikové strategie, procesů, IT služeb a jejich správy (zdroj: vlastní)

Následující obrázek ukazuje toto obecné rozdělení na příkladě. Cílem podnikového procesu nazvaného „Vytvoření a zaslání ceníku“ je doručit zákazníkovy aktuální ceník produktů. Proto, abychom mohli výstup tohoto procesu uskutečnit, potřebujeme dvě IT služby, konkrétně kancelářskou aplikaci (např. Star Office, StarWriter, StarCalc či MS Word, MS Excel…) a e-mail. Tyto IT služby spravuje správa IT služeb a provozovány jsou na ICT infrastruktuře organizace, což je připojení k síti, e-mailový server, PC stanice, na kterých je nainstalována nebo provozována kancelářská aplikace a v neposlední řadě připojení k internetu, aby mohl být e-mail odeslán. Pro jednoduchost vynecháváme další nezbytné prvky infrastruktury, jako jsou switche, e-mailový server apod.

Obrázek 1.3: Příklad podnikového procesu a IT služeb (zdroj: vlastní)

Ještě uvedeme jeden důvod, proč je vhodné uvažovat v kontextu IT služeb, ne v kontextu oddělených technických položek, jako jsou hardware, software, sítě apod. Pokud mluvíme o IT službě, máme na mysli veškeré technologie nutné k běhu služby, ale také další nedílné součásti a aspekty jako jsou licence na softwarové produkty či lidé provozující a podporující aplikaci. Součástí definice služby jsou také vlastnosti a cíle jako náklady na provoz a podporu, doba provozu a podpory, kvalitativní parametry, rozpočet na změny. Proto je také pro IT vhodné mluvit o službách, jelikož jsme schopni vyčíslit konkrétní náklad na danou službu a její provoz, jsme schopni ji spojit s určitými parametry a podnikovým procesem.

Tolik demonstrace IT služeb a jejich struktury. Na závěr ještě uvedeme, že iniciátorem této změny od provozovatele HW, SW a sítí k poskytovateli IT služeb by mělo být samotné IT oddělení či samotný dodavatel IT. Je v zájmu IT přinášet osvětu, vysvětlovat přínos IT služeb pro organizaci a iniciovat diskuse se zákazníkem, jak se to ostatně dozvíme v dalších kapitolách.

1.1.3 Katalog IT služeb

IT služba popsaná v katalogu služeb může obsahovat podle potřeby takové informace, aby uživatelé věděli, k čemu služba slouží, jak ji získat, jaké jsou její parametry a podpora, závislosti či případná cena/náklad a také jaké jsou povinnosti uživatele takové služby. IT pracovníkům pak poskytuje katalog služeb stejné informace a navíc detailní přehled ICT komponent a verzí, ze kterých se daná IT služba skládá. Tato informace pomáhá rychlejšímu řešení incidentů (nečekaných výpadků služby) a identifikaci příčin těchto problémů.

Možná struktura katalogu IT služeb:

❚ popis služby, pro koho slouží;

❚ verze služby a revize včetně následujících dohodnutých termínů;

❚ pracovní hodiny provozu služby a její podpory (interní/externí, jazyk podpory);

❚ co je třeba provést a kam zapsat pro reportování incidentu, požadavku, dotazu (či odkaz na popis ve formě dokumentu, wiki stránek nebo jiného nástroje);

❚ seznam parametrů služby a jejich popis;

❚ právní aspekty IT služby – její použití, bezpečnost, omezení ukládání dat (použití například jen v zemích EU);

❚ procedura popisující změnové řízení (či odkaz na popis ve formě dokumentu, wiki stránek nebo jiného nástroje);

❚ seznam aktuálně poskytovaných IT služeb;

❚ seznam ostatních služeb, na které má uživatel právo nebo které dříve používal.

Přílohou katalogu IT služeb pak mohou být další údaje o službách, například:

❚ tabulky dohodnutých priorit pro incidenty a požadavky na změny;

❚ seznam provozních parametrů služby;

❚ reporty dostupnosti služby;

❚ zmínka o externích dodavatelích či nutný kontakt na ně.

Příklad možných kategorií služeb Provoz a správa PC, notebooků, PDA NekritickáProvoz služeb týkajících se hlavních podnikových procesů KritickáSpráva a provoz datových úložišť KritickáProvoz sítě Kritická

Tabulka 1.1: Příklad jednoduchého katalogu IT služeb

Název služby

Uživatelé

Odpovědnosti

Postupy

Konfigurační položky

Správa objednávek

Marie Kupková (ekonom)

Vedení

Uživatele:

– reportuje incident pomocí Service Desk

– účastní se pravidelných měsíčních přezkoumání SLA

Reportování incidentu (odkaz)

Požadavek na změnu (odkaz)

Žádost o informace (odkaz)

Objednávky v 1.1

Tomcat v 5.5

Oracle 9i

Red Hat Enterprise Linux 5

Server Prague

Switch S1

Intranet

Internet

Všichni uživatelé

…

Telefon: 800 669 908

Internet Service Provider – poskytovatel připojení

Firewall Zone F v3.2

Vyhledávání dokumentů

Všichni uživatelé

Nejsou definovány

Gogole Desktop Search

Katalog IT služeb (portfolio) také v praxi slouží obchodníkům, aby věděli, co mají nabízet zákazníkům. Katalog by měl v tomto kontextu odpovídat následující otázky:

❚ Jaké IT služby umíme nejlépe? A tudíž je máme nabízet jako hlavní.

❚ Jaké IT služby a jejich konfigurace jsou standardní? Jaké jsou náklady a rizika u těch nestandardních?

Pokud takový katalog (portfolio) pro obchodníky neexistuje, pak v praxi velmi často u větších firem dochází k tomu, že obchodníci nabízí, co je napadne, či to co si zákazník nadiktuje, bez znalosti možných problémů v konfiguraci serverů, sítí, aplikací. Důsledkem je pak:

❚ Dlouhá doba dodání řešení oproti standardnímu až několikanásobná.

❚ Vyšší cena údržby: více práce ke konfiguraci, nižší úroveň automatizace (manuální práce) způsobující větší chybovost a tudíž více možných incidentů.

1.1.4 Vytvoření katalogu IT služeb

Jelikož způsob poskytování IT služeb a způsob myšlení pracovníků služby poskytujících se liší od správců HW a SW, nastíníme také postup tvorby služeb a katalogu a způsob uvažování v kontextu IT služeb.

Jak jsme již zmínili výše, jsou IT služby napojeny na podnikové procesy s cílem je podpořit (automatizovat, zefektivnit, generovat nové oblasti služeb). Je tedy zřejmé, že prvním krokem bude pochopení vlastního podnikání a zmapování podnikových procesů a možnosti jejich podpory IT službami. Je velmi těžké vytvářet a provozovat službu pro burzovního makléře, pokud nevíme, co je to akcie, finanční derivát či volatilita. Součástí mapování a popisu podnikových procesů jsou rozhovory s uživateli, kdy zjišťujeme opravdovou potřebu uživatelů^2 a podle nich vybíráme či upravujeme funkčnosti systému, který bude součástí IT služby. V průběhu těchto rozhovorů také vysvětlujeme možnosti IT, resp. použitých IT technologií, abychom nastavili realistická očekávání uživatelů.3 Díky těmto rozhovorům také IT pracovníci pochopí, že je třeba se uživatelům věnovat, vysvětlovat přínosy a omezení použitých IT technologií, jiné (levnější) varianty a také otevřeně prezentovat náklady, o kterých uživatelé nemají ani ponětí. Důležitým krokem je také identifikace závislostí či případných rizik a omezení vyplývajících z kontraktu, použité technologie, geografické lokality či typu podnikání zákazníka. Typicky tím může být další poskytovatel/dodavatel, jehož služby nejsou pokryty dohodou o kvalitě služeb (tzv. SLA) a tudíž může dohodnutý čas reakce a řešení posunout do úplně jiných dimenzí (z hodin se mohou stát týdny). Pokud tuto závislost neodhalíme, můžeme nést jako dodavatel služby odpovědnost za tyto prodlevy, i když na třetí stranu nemáme žádný vliv.

V dalším kroku je vhodné identifikovat slovník podnikových a IT pojmů, nezbytných konceptů a významů a navázat projekty na cíle a potřeby podniku. Pokud neexistuje IT strategie organizace, je nutné ji vytvořit (její místo v organizaci viz obrázek 1.6). Tato strategie vychází z cílů podniku a jeho možných směrů vývoje a definuje základní infrastrukturu organizace a základní IT služby s cílem naplnit tyto potřeby. Pokud IT služby neexistují, je vhodné definovat projekt implementace těchto služeb (přesně definované cíle, rozpočet a další zdroje), buď ze stávajících prostředků nebo na zelené louce, vlastními silami či s pomocí externích dodavatelů.

Třetím krokem je identifikace jednotlivých částí služby (tzv. konfiguračních položek) a jejich přiřazení službě. Tento vztah zachytíme také v technické části (nepřístupná běžným uživatelům) katalogu IT služeb.

Výsledkem těchto kroků je tabulka či seznam popisující IT služby (opět příklady viz dále), jejich zákazníky a dodavatele. Nyní je možné ověřit správnost katalogu a identifikovaných IT služeb včetně dosažitelnosti jejich SLA pilotním provozem, kterého se účastní vybraní koncoví uživatelé daných IT služeb. Díky jejich zapojení do pilotního provozu dostaneme neocenitelnou zpětnou vazbu. Součástí pilotního provozu musí být pravidelné schůzky s těmito uživateli a diskuse o službách a jejich parametrech a požadovaných změnách. Pilotní provoz typicky trvá několik týdnů až měsíců podle významu, rozsahu a důležitosti služby.

Jedním z důležitých podpůrných faktorů je také správný nástroj, který umožní zpřístupnit katalog IT služeb a také umožní základní práci s nimi, včetně jejich objednání a reportování incidentů a požadavků na změnu. Vestavěnou funkčností nástroje by mělo být automatické měření definovaných parametrů služeb a jejich reportování. Dobrým příkladem a námětem funkčnosti takového nástroje jsou portály mobilních operátorů, kde si uživatel sám může vzdáleně přes webové rozhraní administrovat svá mobilní telefonní čísla, přidávat či odebírat služby, volit jejich parametry či řešit fakturaci.

Kritickým faktorem úspěchu katalogu služeb a vlastních IT služeb je tedy následující:

❚ zapojení koncových uživatelů do návrhu služeb a pochopení potřeb podniku lidmi z IT;

❚ pilotní provoz a pravidelná zpětná vazba (i v rámci provozu) od koncových uživatelů.

Závěrem jen připomeňme, proč je dobré uvažovat o IT službách místo o hardwaru, softwaru, sítích a přidružených službách jako jsou konzultace. Prvotní výhodou je navázanost na podnikové procesy. Vidíme, jaké IT systémy a infrastruktura je podporují a jak. Je zřejmý přínos a dopad na podnikání. Za druhé je to jednotná (konečná) cena za službu jako celek, což zahrnuje i licence či náklady na provoz a zaměstnance (IT tedy není pouze nákladovou položkou). V neposlední řadě známe údaje o době provozu a podpory IT služby, parametry služby či plánovaný rozpočet na změny na dané období.

1.1.5 Poskytování softwaru jako služby (SaaS)

V souvislosti s poskytováním IT služeb se mluví o trendu posledních let zvaném Software jako služba (Software as a Service – SaaS). Příkladem takové služby je například Google Apps for Business.4 Rozvoj tohoto konceptu jde ruku v ruce s rozvojem tzv. cloudu (více o této problematice viz kapitola 9.3 pojednávající o trendech v oblasti provozu a údržby). Software jako služba není rozhodně nový koncept, je v podstatě dalším evolučním krokem poskytování aplikace jako služby ASP (Application Service Providing), které je známé na IT trhu již delší dobu. Díky tomu by se mohlo zdát, že skutečně funguje a umíme využít jeho potenciálu. Jaká je však skutečnost?

SaaS deklaruje nízkou cenu a vysoký výkon/výnos. Podle studie společnosti Gartner z prosince roku 2008 [Ga08] je však situace odlišná, stejně jako zkušenosti zákazníků. Gartner provedl průzkum mezi 333 předními společnostmi v USA a Velké Británii, a vyplývá z něj, že model SaaS je přijímán jako životaschopný, ale uživatelské reakce nejsou rozhodně nadšené. Podívejme se blíže na některá čísla [Ga08]:

❚ 58 % respondentů uvedlo, že v dalších dvou letech plánují pouze udržovat současnou úroveň využívání SaaS;

❚ 32 % respondentů hodlá zvýšit využití SaaS;

❚ a pouze 5 % chce využití snížit a dalších 5 % chce SaaS přestat využívat úplně.

Tato čísla by mohla ukazovat všeobecnou akceptovatelnost a spokojenost s danou službou. Výsledky průzkumu však toto nepotvrdily. Zákazníci nebyli zcela spokojeni s hlavní deklarovanou výhodou služby, což je nízká cena a vysoký výkon. Jako další diskutabilní oblasti byly zmíněny bezpečnost a důvěryhodnost poskytovatele. Navíc velmi nízké hodnocení s překvapivě malým rozptylem bylo u odpovědí týkající se SaaS z pohledu spokojenosti. Průměrem bylo hodnocení 4.7 na 7 bodové stupnici. Velmi nízký rozptyl byl nejen u celkové spokojenosti, ale také u otázek typu poskytované funkčnosti, schopnost reakce poskytovatele, spolehlivost a podpora služby.

Překvapivé je zjištění, že zákazníci, kteří o zavedení SaaS uvažovali, ale nakonec od něj upustili, uvedli ve 42 % jako důvod příliš vysoké roční náklady, resp. vyšší, než očekávali. Je to zajímavé zjištění, když si uvědomíme, že hlavní deklarovanou výhodou této služby je nízká cena a vysoký přínos. Již méně překvapivý je druhý argument, jímž je náročnost implementace této změny a vazba na existující systémy (uvedlo 38 % respondentů). Třetí v pořadí faktorů nespokojenosti se umístila rychlost implementace a technické požadavky (uvedlo 33 % respondentů).

Je tedy zřejmé, že poskytovatelé SaaS mají co dohánět a že reklamní slogany typu levně, přesně podle potřeb vašeho podnikání a zprovoznění již dnes, jsou stále ještě spíše jen slogany, realita tomu neodpovídá. Ekonomická krize a nižší náklady na IT, stejně jako potřeba rychlé reakce ze strany IT otevírá trh pro daný typ služby. Je však potřeba nalézt efektivní způsob komunikace se zákazníky, skutečně identifikovat jejich potřeby a poskytnout cenově efektivní řešení. Návodem, jak toto naplnit mohou být námi definované agilní principy představené v kapitole 2.2.

1.2 Problémy provozu, podpory a údržby IT systémů

V dnešní době je oblast provozu, podpory a údržby IT systémů velmi dobrou podnikatelskou příležitostí, ale také předmětem zkoumání akademické komunity. Již delší dobu se můžeme setkat se snahou pomoci (netechnickým) koncovým uživatelům s nasazením a používáním informačních systémů ať již ve formě IT služeb, či přístupu k provozu ve formě Application Service Providing (ASP) či software jako služba (Software as a Service - SaaS), kdy se podnik nestará o technickou a provozní stránku IS, resp. IT služeb. Na rozdíl od vývoje informačního systému^5 trvá provoz mnohonásobně déle. Systémy uvažované na několik let fungují klidně i desítky let,6 což se samozřejmě musí projevit i v nákladech na provoz, údržbu a případné rozšiřování těchto systémů. Díky existenci zastaralých systémů a architektur se pak jejich údržba a zapracovávání změn stává složitějším, což je klasický obrázek v bankovní a telekomunikační sféře, kde se začalo se zaváděním ICT nejdříve. Díky složité infrastruktuře těchto organizací musíme často řešit návaznost na desítky, někdy i stovky systémů a každou změnu vůči těmto rozhraním testovat, což jde v praxi velmi těžce a dále ztěžuje údržbu.

Nárůst komplexnosti systémů a hlavně prostředí, ve kterém musíme systémy udržovat a dále rozšiřovat, má za důsledek to, že pouze malá část dnešních podnikových výdajů na IT je věnována nové funkcionalitě. Obecně lze výdaje na IT rozdělit do následujících tří kategorií [Ho08]:

❚ Udržení setrvalého stavu – náklady na udržení chodu a nezbytnou údržbu existujících IT systémů.

Vážení čtenáři, právě jste dočetli ukázku z knihy Provozujte IT jinak.
Pokud se Vám líbila, celou knihu si můžete zakoupit v našem e-shopu.