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í.

Část I. Definice pojmů, současný stav provozu, údržby a podpory IS

1. Vymezení pojmů aproblému, současný stav

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

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

Vprů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í astrukturované ú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 auklá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 utěchto typů projektů málo amě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. Vprůběhu času se však změnila povaha projektů od výše zmíněných kprojektům strategického rázu.

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

„Sociálně-technický systém, ve kterém lidé, technologie, podnikové procesy aorganizace na sebe navzájem působí ve snaze sbírat, zpracovávat, archivovat adistribuovat informace scílem podpořit řízení, koordinaci arozhodování vorganizaci.“

Informační akomunikační technologie (ICT) (hardware, software, telekomunikace) jako kritická komponenta IS hrají rozhodující roli vtransformaci 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é znástrojů Teorie omezení také využíváme vnaš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 aorganizaci různě [Oh99]:

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

❚ Změna druhého řádu ovlivňuje pracovní zvyklosti austálené role azdůrazňuje sociální dimenzi apotřebu porozumět složitým vztahům mezi lidmi, technologiemi aprocesy. Cílem těchto systémů není pouhá automatizace, ale také poskytování hodnotné apř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 aprocesy, 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 astrategickou orientaci organizace. Naproti tomu změny vyššího řádu ssebou přináší nejistotu aje 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 vpublikacích zrůzných disciplín. Strategické projekty jsou podle [MR76] méně strukturované anelze je zcela přesně akonkrétně vymezit pro potřeby rozhodnutí. Dále podle [DW83], jak se projekty stávají více strategickými, zahrnují více oblastí adisciplí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í atak 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 apromítnout jej také do postupů vývoje, ale také provozu, podpory aúdržby informačních systémů. Je tedy nezbytné definovat metodiky apostupy založené na principech, ne na detailně popsaných procedurách, kdy dané principy budou vkonkrétních případech implementovány rozdílnými technikami.

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

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

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

Vtextu 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 vná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í aprovoz určité sady funkčností, modulů IS (zahrnující potřebnou ICT infrastrukturu, základní iaplikač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 vICT vyskytuje vrů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ů. Vneposlední řadě je pojem služba uvažován vkontextu řízení provozovaných aplikací, spíše apouze jen vjejich outsourcované formě. Více otéto problematice lze nalézt například v[GP09] nebo [Voř08]. Vdnešním světě však již nelze odlišovat infrastrukturu od aplikací aostatní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 azefektivnilo 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í atrhu. Proto je nutné se na poskytování různého typu softwaru, převážně však systémů podnikové informatiky ainfrastruktury (ať sítí, hardwaru či základního softwaru), dívat jako na komoditu, ne na její jednotlivé části zvlášť. Vtakové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

Vdnešní době častých arychlých změn je tedy nutné, aby organizace upustily od orientace na provoz aposkytování hardwaru, softwaru, infrastruktury astaly se poskytovateli IT služeb podporujících podnikání dané organizace přesně podle jejich potřeb. Poskytování IT služeb je vnašem odvětví stále ještě chápáno pouze jako oblast outsourcingu. Interní IT oddělení pracují afungují stále jako nákladová centra poskytující hardware ajeho správu, stejně tak jako software ajeho správu. Uživatel se pak musí sám snažit dostat kIT týmům asdělit, co vlastně potřebuje, pokud možno vIT řeči. IT již dávno není vdneš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ů) atudíž zbývá méně na vývoj nových funkčností IS aIT 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 asnažili se ji co nejvíce aflexibilně propojit spotř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í aposkytování IT služeb ajako takový propaguje propojenost podniku ajeho procesů sIT pokud možno ve formě IT služeb. ITIL® oslužbě říká následující [ITIL]:

„Aservice is ameans 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 arizika.“

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

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

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

Zdefinice je tedy jednoznačně vidět propojení podnikových cílů organizace sIT. Vná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 avelkých společností (ato nejen vČR ale ivEvropě), naopak většina znich 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 vpří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ů azahájit pravidelné diskuse skoncovými uživateli našich služeb (tento princip atechniky, jak principu dosáhnout, bude popsán dále vtéto kapitole ataké vkapitole 2.2).

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

❚ poskytování e-mailu;

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

❚ podpora monitorování vytíženosti lůžek aoperačních sálů vnemocnici (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 ataké „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í ataké viditelnost pro koncové uživatele (zdroj: vlastní)

Jak je zobrázku zřejmé, IT služba se skládá zrůzných komponent, mezi které patří hardware serverů astanic asoftware na nich běžící (autorizace aautentifikace, firewally, databáze, middleware, aplikační servery), datová úložiště, mainframe systémy, sítě asíťové prvky nutné kdoručení IT služby kzákazníkovi (často také internet jako páteřní síť) asamozř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 incident1 spojený sdanou službou.

IT naopak technické informace potřebuje. Proto, aby tým podpory mohl urychleně vyřešit nějaký incident, který nastal vinfrastruktuř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 sdoménovou znalostí apodporována IT profesionály, měla by být popsána zobou pohledů včetně popisu odpovědností jednotlivých stran. IT služby většinou popisujeme vkatalogu služeb (více viz následující kapitola).

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

Pokud je tedy cílem IT poskytovat služby, vše zpohledu 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 ajejich správy, podnikových procesů apodnikové strategie. Obrázky 1.1 a1.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, vjakých lokalitách chce působit, zda bude mít kamenné pobočky či pouze elektronický obchod aspoustu dalšího. Pro realizaci těchto cílů slouží podnikové procesy (více opodnikových procesech aprocesní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í. Kprovozu 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, ktomu slouží správa IT služeb.

Obrázek 1.2: Vztah podnikové strategie, procesů, IT služeb ajejich 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í azaslá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…) ae-mail. Tyto IT služby spravuje správa IT služeb aprovozovány jsou na ICT infrastruktuře organizace, což je připojení ksíti, e-mailový server, PC stanice, na kterých je nainstalována nebo provozována kancelářská aplikace avneposlední řadě připojení kinternetu, 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 aIT služeb (zdroj: vlastní)

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

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

1.1.3 Katalog IT služeb

IT služba popsaná vkatalogu 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 apodpora, závislosti či případná cena/náklad ataké jaké jsou povinnosti uživatele takové služby. IT pracovníkům pak poskytuje katalog služeb stejné informace anavíc detailní přehled ICT komponent averzí, 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) aidentifikaci příčin těchto problémů.

Možná struktura katalogu IT služeb:

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

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

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

❚ co je třeba provést akam 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 ajejich popis;

❚ právní aspekty IT služby– její použití, bezpečnost, omezení ukládání dat (použití například jen vzemí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 oslužbách, například:

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

❚ seznam provozních parametrů služby;

❚ reporty dostupnosti služby;

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

Příklad možných kategorií služeb Provoz aspráva PC, notebooků, PDA NekritickáProvoz služeb týkajících se hlavních podnikových procesů KritickáSpráva aprovoz 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 oinformace (odkaz)

Objednávky v1.1

Tomcat v5.5

Oracle 9i

Red Hat Enterprise Linux 5

Server Prague

Switch S1

Intranet

Internet

Všichni uživatelé

…

Telefon: 800669908

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é vpraxi slouží obchodníkům, aby věděli, co mají nabízet zákazníkům. Katalog by měl vtomto kontextu odpovídat následující otázky:

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

❚ Jaké IT služby ajejich konfigurace jsou standardní? Jaké jsou náklady arizika utěch nestandardních?

Pokud takový katalog (portfolio) pro obchodníky neexistuje, pak vpraxi velmi často uvětších firem dochází ktomu, že obchodníci nabízí, co je napadne, či to co si zákazník nadiktuje, bez znalosti možných problémů vkonfiguraci 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 atudíž více možných incidentů.

1.1.4 Vytvoření katalogu IT služeb

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

Jak jsme již zmínili výše, jsou IT služby napojeny na podnikové procesy scí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í azmapování podnikových procesů amožnosti jejich podpory IT službami. Je velmi těžké vytvářet aprovozovat službu pro burzovního makléře, pokud nevíme, co je to akcie, finanční derivát či volatilita. Součástí mapování apopisu podnikových procesů jsou rozhovory suživateli, kdy zjišťujeme opravdovou potřebu uživatelů2 apodle nich vybíráme či upravujeme funkčnosti systému, který bude součástí IT služby. Vprů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 aomezení použitých IT technologií, jiné (levnější) varianty ataké otevřeně prezentovat náklady, okterých uživatelé nemají ani ponětí. Důležitým krokem je také identifikace závislostí či případných rizik aomezení vyplývajících zkontraktu, 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 okvalitě služeb (tzv. SLA) atudíž může dohodnutý čas reakce ařešení posunout do úplně jiných dimenzí (zhodin 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, ikdyž na třetí stranu nemáme žádný vliv.

Vdalším kroku je vhodné identifikovat slovník podnikových aIT pojmů, nezbytných konceptů avýznamů anavázat projekty na cíle apotřeby podniku. Pokud neexistuje IT strategie organizace, je nutné ji vytvořit (její místo vorganizaci viz obrázek 1.6). Tato strategie vychází zcílů podniku ajeho možných směrů vývoje adefinuje základní infrastrukturu organizace azákladní IT služby scí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 adalší zdroje), buď ze stávajících prostředků nebo na zelené louce, vlastními silami či spomocí externích dodavatelů.

Třetím krokem je identifikace jednotlivých částí služby (tzv. konfiguračních položek) ajejich přiřazení službě. Tento vztah zachytíme také vtechnické čá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 adodavatele. Nyní je možné ověřit správnost katalogu aidentifikovaný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 stěmito uživateli adiskuse oslužbách ajejich parametrech apožadovaných změnách. Pilotní provoz typicky trvá několik týdnů až měsíců podle významu, rozsahu adůležitosti služby.

Jedním zdůležitých podpůrných faktorů je také správný nástroj, který umožní zpřístupnit katalog IT služeb ataké umožní základní práci snimi, včetně jejich objednání areportování incidentů apožadavků na změnu. Vestavěnou funkčností nástroje by mělo být automatické měření definovaných parametrů služeb ajejich reportování. Dobrým příkladem aná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 avlastních IT služeb je tedy následující:

❚ zapojení koncových uživatelů do návrhu služeb apochopení potřeb podniku lidmi zIT;

❚ pilotní provoz apravidelná zpětná vazba (ivrámci provozu) od koncových uživatelů.

Závěrem jen připomeňme, proč je dobré uvažovat oIT službách místo ohardwaru, softwaru, sítích apřidružených službách jako jsou konzultace. Prvotní výhodou je navázanost na podnikové procesy. Vidíme, jaké IT systémy ainfrastruktura je podporují ajak. Je zřejmý přínos adopad na podnikání. Za druhé je to jednotná (konečná) cena za službu jako celek, což zahrnuje ilicence či náklady na provoz azaměstnance (IT tedy není pouze nákladovou položkou). Vneposlední řadě známe údaje odobě provozu apodpory 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)

Vsouvislosti sposkytováním IT služeb se mluví otrendu posledních let zvaném Software jako služba (Software as aService– SaaS). Příkladem takové služby je například Google Apps for Business.4 Rozvoj tohoto konceptu jde ruku vruce srozvojem tzv. cloudu (více otéto problematice viz kapitola 9.3 pojednávající otrendech voblasti provozu aúdržby). Software jako služba není rozhodně nový koncept, je vpodstatě 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 aumíme využít jeho potenciálu. Jaká je však skutečnost?

SaaS deklaruje nízkou cenu avysoký výkon/výnos. Podle studie společnosti Gartner zprosince 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 vUSA aVelké Británii, avyplývá zně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 vdalších dvou letech plánují pouze udržovat současnou úroveň využívání SaaS;

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

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

Tato čísla by mohla ukazovat všeobecnou akceptovatelnost aspokojenost sdanou službou. Výsledky průzkumu však toto nepotvrdily. Zákazníci nebyli zcela spokojeni shlavní deklarovanou výhodou služby, což je nízká cena avysoký výkon. Jako další diskutabilní oblasti byly zmíněny bezpečnost adůvěryhodnost poskytovatele. Navíc velmi nízké hodnocení spřekvapivě malým rozptylem bylo uodpovědí týkající se SaaS zpohledu spokojenosti. Průměrem bylo hodnocení 4.7 na 7 bodové stupnici. Velmi nízký rozptyl byl nejen ucelkové spokojenosti, ale také uotázek typu poskytované funkčnosti, schopnost reakce poskytovatele, spolehlivost apodpora služby.

Překvapivé je zjištění, že zákazníci, kteří ozavedení 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 avysoký přínos. Již méně překvapivý je druhý argument, jímž je náročnost implementace této změny avazba na existující systémy (uvedlo 38% respondentů). Třetí vpořadí faktorů nespokojenosti se umístila rychlost implementace atechnické 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í azprovoznění již dnes, jsou stále ještě spíše jen slogany, realita tomu neodpovídá. Ekonomická krize anižší 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 aposkytnout cenově efektivní řešení. Návodem, jak toto naplnit mohou být námi definované agilní principy představené vkapitole 2.2.

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

Vdneš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 snasazením apoužíváním informačních systémů ať již ve formě IT služeb, či přístupu kprovozu ve formě Application Service Providing (ASP) či software jako služba (Software as aService - SaaS), kdy se podnik nestará otechnickou aprovozní stránku IS, resp. IT služeb. Na rozdíl od vývoje informačního systému5 trvá provoz mnohonásobně déle. Systémy uvažované na několik let fungují klidně idesítky let,6 což se samozřejmě musí projevit ivnákladech na provoz, údržbu apřípadné rozšiřování těchto systémů. Díky existenci zastaralých systémů aarchitektur se pak jejich údržba azapracovávání změn stává složitějším, což je klasický obrázek vbankovní atelekomunikač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 istovky systémů akaždou změnu vůči těmto rozhraním testovat, což jde vpraxi velmi těžce adále ztěžuje údržbu.

Nárůst komplexnosti systémů ahlavně prostředí, ve kterém musíme systémy udržovat adá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 anezbytnou údržbu existujících IT systémů.

❚ Naplnění regulačních opatření– změny vpodnikových procesech vynucené novými zákony, předpisy či jinými požadavky vdané oblasti (například neustálé změny vsociálních azdravotních odvodech, vdaních aodpočtech či nutnost implementace důsledků Sarbanes-Oxley).

❚ Inovační oblast– náklady na zavedení nových funkčností avlastností ataké nových technologií vdané organizaci.

Výzkumy společnosti Gartner [Ga08IT], [Ga09IT], [Ga09] stejně jako Barry Boehm v[Bo76] nebo také [CNet], [ISS10], ukazují, že IT rozpočty organizací, které jdou na inovace, vývoj nových aplikací aslužeb apořízení počítačů aserverů se již několik let snižují ato právě zdůvodu dražší údržby, resp. pouhého udržení systémů vchodu. Například vroce 2008 bylo pouze 19% IT rozpočtů použito na transformaci podnikání ainovace, zbylých 81% bylo použito na provoz IT. Je zajímavé, že IT rozpočty jako takové stagnují či se naopak spíše zvyšují, viz [Ga08IT], [Ga09IT], [CNet], [ISS10].

Obrázek 1.4: Pokles IT rozpočtů na podnikové inovace aprocenta využití IT rozpočtů (zdroj: [Ga08IT], [Ga09IT])

Dalším problémem vdiskutované oblasti bývá tzv. dominový efekt. Jednoduchá změna hardwarové komponenty, která je vjednoduchém prostředí (osobní PC, notebook, malá firemní síť) triviální azabere maximálně několik desítek minut (nepočítáme případy, kdy je nutné přeinstalovat OS Windows zdůvodu neporozumění si svyměněnou komponentou), může vkomplexním prostředí podnikové infrastruktury vyvolat zmíněný dominový efekt. Oco se vlastně jedná? Běžně se stává, že koncoví uživatelé vyžadují novou funkčnost na nové platformě, či že zastarává určitý produkt, končí doba jeho podpory aje třeba jej vyměnit. Vizolovaném prostředí může tato změna vypadat jako triviální, ale ve složité infrastruktuře vyvolá většinou změna middleware či verze databáze nutnost dalších změn vjiných vrstvách či systémech (tzv. dominový efekt), ať již kvůli změně chování či zajištění kompatibility. To, co začalo jako malá změna, je nakonec velká arozsáhlá změna velké části IT infrastruktury, jejíž dokončení může vrámci velké organizace trvat i6 až 18 měsíců [Ho08]. Situaci popisuje obrázek 1.5.

Obrázek 1.5: Dominový efekt vkomplexní podnikové infrastruktuře (zdroj: vlastní).

Vtéto knize popisujeme principy, přístupy atechniky, jejichž aplikace může pomoci snížit zmíněné problémy, tj. jak zvyšující se cenu údržby, tak rostoucí složitost informačních systémů aaplikací vdůsledku implementace legálních omezení (pravidel, zákonů, vyhlášek, směrnic) či odstranění dominového efektu.

Velmi důležitým abohužel také často opomíjeným aspektem provozu aúdržby jsou lidé. Motivace jednotlivců, sdílení znalostí ařešení, komunikace svývojáři informačního systému auživateli jsou jedny znejzásadnějších faktorů úspěchu, pokud tomu tak není, setkáme se stypickými problémy [BF87], [LS81], [Ho08], [CC95], [dS07], [PPN95], [Pr10a], [Pr08b]:

❚ nejsou implementovány prioritní funkčnosti (či nejsou známé priority) navržené zákazníkem;

❚ jsou přetížení členové týmu, před nasazením nové verze kulminuje množství úkolů, které je třeba udělat, apo nasazení vzniká spousta nových chyb;

❚ každá změna vaplikaci (upgrade) znamená nové problémy;

❚ neznalost architektury řešení vtýmu atudíž implementace nesystémových změn způsobujících těžce udržitelnou aplikaci;

❚ znovu vynalézání kola– problémy ajejich řešení nejsou sdíleny amusíme je vymýšlet znovu aznovu, což stojí organizace mnoho peněz; ztrátou zaměstnance ztrácíme iznalost.

Zpohledu uživatele pak [Ho08], [Pr10a]:

❚ informační systémy či IT služby nepodporují podnikové procesy, či dokonce přidávají práci;

❚ při reportování problému či vyřizování požadavku musíme neustále opakovat všem osobám ze strany IT, ke kterým se dostaneme, to samé;

❚ kvalita podpory je jiná ráno, vpoledne či večer;

❚ vzahraničních společnostech jsme často překvapeni, když se na druhém konci telefonu ozve asijskou angličtinou mluvící Ind.

Obrázek 1.6: Kontext popisované problematiky: od strategie podnikání kIS/IT službám ajejich správě (zdroj: vlastní)

Proto se dále zabýváme také motivací člověka zpohledu psychologie, typologií osobnosti aspoluprací mezi lidmi. Dalším zdůležitých aspektů provozu aúdržby IS je proaktivita týmu, identifikace trendů, návrh strukturálních řešení ať vICT infrastruktuře, tak varchitektuře softwarového systému. Proto ale musí být tým znalý nejen problémové domény zákazníka, ale také jeho cílů azáměrů.

Obrázek 1.6 popisuje kontext problematiky, kde se nacházíme vorganizaci, jaký je smysl informačních akomunikačních technologií (ICT), potažmo informačních systémů. Smyslem existence každého podniku je vytvářet zisk, bez ohledu na to, jestli vyrábím, nakupuji aprodávám, vyvíjím či poskytuji služby. Smysl existence podniku je definován vtzv. globální (podnikové) strategii. Tato strategie stručně říká, co děláme, kdo jsou naši zákazníci, na jaké trhy se orientujeme, kde ajaké zdroje na to vezmeme (peníze, lidi, technologie). Strategie pouze udává směr, ojejí realizaci se starají podnikové procesy. Podnikový proces je sled aktivit, které musíme vykonat, abychom vyprodukovali nějaký přínosný výstup. Příkladem podnikových procesů může být prodej anákup, fakturace, naskladnění, výzkum, výroba, vývoj, personalistika atd. Proto, aby tyto procesy fungovaly efektivně apokud možno automatizovaly manuální, opakující se činnosti, slouží ICT. ICT musí podporovat procesy vorganizaci amusí pomáhat naplnit cíle definované globální podnikovou strategií. Jak jsme již uvedli vúvodní kapitole, povaha informačních systémů se změnila směrem ke strategickému významu. Proto je jejich napojení na strategii podniku kritické. Směr acíle ICT jsou definovány vIT strategii, která určuje, co ajak budeme pomocí ICT podporovat, automatizovat, jaké technologie aplatformy použijeme ajaké jsou preferované modely provozu apořízení softwaru (nákup, vývoj, systémová integrace). Tato IT strategie musí být vsouladu spodnikovou strategií. Více oproblematice viz např. [GP09]. Obrázek ještě naznačuje malou část IT strategie– globální architekturu IS, což je vlastně celková koncepce provozovaných systémů (např. technologické platformy, komunikační vrstva, SOA model) [DP97]. Jelikož jsme si již řekli, vjakém kontextu vpodniku se pohybujeme, můžeme se zabývat problematikou provozu aúdržby zteoretického pohledu. Řekneme si, co do dané disciplíny patří podle literatury aco nikoli, zmíníme různé pohledy, definice ataké doporučení, resp. standardy aframeworky významných institucí aspolečností používané vdaném oboru.7

1.3 Rozsah podpory aúdržby IT systémů

Pojmy podpora aúdržba (anglicky support, resp. maintenance) jsou všeobecně známy aintuitivně by je dokázal popsat každý vysokoškolsky vzdělaný technik. Pro sjednocení pochopení použijeme standardní definice IEEE. IEEE definuje disciplínu údržby následovně [IEEE]:

“Software maintenance is the process of modifying asoftware system or component after delivery to correct faults, improve performances or other attributes, or adapt to achanged environment.”

Česky bychom výše zmíněnou definici mohli volně přeložit následovně:

„Údržba softwaru je procesem modifikace softwarového systému či komponenty po doručení uživateli za účelem korekce chyby, zlepšení výkonu či jiného atributu nebo adaptace systému změnám prostředí.“

Tato definice obsahuje jednu diskutabilní myšlenku, atou je počátek disciplíny podpory aúdržby začínající až vmomentě doručení softwaru uživatelům. IT experti tuto problematiku diskutovali avýsledkem jejich diskusí byl procesně orientovaný ISO model životního cyklu vývoje softwaru [ISO1]. Tento životní cyklus zahrnuje disciplínu údržby softwaru, která může začínat již brzy vrámci životního cyklu projektu azabývá se opravou chyb.

Výše zmíněné standardy či doporučení také definují tři kategorie údržby softwaru. Jedná se onásledující [IEEE], [ISO1]:

❚ Korektivní údržba (Corrective maintenance)– reaktivní modifikace softwarového produktu za účelem korekce objeveného problému, chyby, které jsou vykonávány po doručení (verze) produktu do produkce/zákazníkovi.

❚ Adaptivní údržba (Adaptive maintenance)– modifikace softwarového produktu za účelem změny funkčnosti zdůvodu měnícího se prostředí. Tyto modifikace jsou také vykonávány po doručení (verze) produktu do produkce/zákazníkovi.

❚ Zlepšující údržba (Perfective maintenance)– modifikace softwarového produktu za účelem zlepšení výkonnosti (tzv. performance) či jednoduchosti údržby (tzv. maintainability) prováděné taktéž po doručení (verze) produktu do produkce/zákazníkovi.

Obecně vIT ataké dále vtextu se můžeme setkat spojmem podpora informačního systému či IT služby (anglicky support). Tento pojem je dokonce dobře známý ine IT uživatelům,8 což je ujiných pojmů zexotické IT řeči spíše výjimka. Podívejme se tedy opět, jak IEEE definuje tuto disciplínu [IEEE]:

„Product support is providing of information, assistance, and training to install and make software operational in its intended environment and to distribute improved capabilities to users.“

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

„Podporou produktu rozumíme poskytování informací, pomoci aškolení za účelem instalace či provozu softwaru vprostředí ktomu určeném ataké jí rozumíme distribuci zlepšených funkčností softwaru ke koncovým uživatelům.“

Zvýše zmíněných definic adruhů údržby je zřejmé, že pojmy podpora aúdržba se týkají aktivit spojených sprovozem IT systémů, korekcí chyb, zlepšením výkonu či úpravy funkčností, ale také aktivit spojených sposkytováním informací aškolení, vše převážně po konečném dodání (verze) systému zákazníkovi. Důležité je upozornit na slovíčko převážně. Běžně totiž existují činnosti, které provádíme (ačasto imusíme) již před samotným nasazením uzákazníka, mezi příklad takových aktivit patří následující:

❚ nábor pracovníků na pozice vpodpoře;

❚ školení pracovníků podpory (např. formou práce vpáru na reálných úkolech– viz popis praktiky dále vkapitole 2);

❚ sdílení, transfer adokumentace znalostí od dodavatele systému kprovozovateli poskytujícímu podporu (nejlepším řešením je využití členů vývojového týmu ipro podporu aprovoz, jelikož tito lidé znají systém nejlépe);

❚ příprava dokumentace apostupů, procesů (toto může být například forma učení se systému);

❚ příprava prostředí– instalace serverů asítí, operačních systémů, databází ajejich test.

Obrázek 1.7 ukazuje místo provozu aúdržby vživotním cyklu IT systému podle fází Rational Unified Process. Provoz aúdržba tedy oficiálně začíná dnem nasazení aplikace do ostrého provozu, ikdyž už víme, že vrealitě musíme provádět určité akce (akceptační testy, školení personálu, přenos znalostí, příprava prostředí ainstalace, pilotní provoz) vprůběhu vývoje. Obrázek 1.8 pak ukazuje návaznost mezi jednotlivými verzemi IT systému ajejich nejčastější vstupy.

Obrázek 1.7: Životní cyklus SW projektu amísto provozu aúdržby vjeho kontextu (zdroj: vlastní)

Obrázek 1.8: Rozdílné verze systému ajejich životní cyklus avstupy: změny, opravy chyb (zdroj: vlastní).

Jako poslední vtéto kapitole si vysvětlíme pojem provoz IT ve významu anglického „IT Operations Management“. IT Operations Management (OM) je podle [IEEE]:

„Proces provozu počítačového systému vurčeném prostředí (IT infrastruktuře) pro určené účely.“

ITIL® [ITIL] popisuje proces provozu počítačového systému (OM) jako funkci odpovědnou za neustálou správu aúdržbu IT infrastruktury organizace scílem zajistit dohodnutou úroveň IT služeb pro zákazníka. Jedná se tedy osadu dennodenních aktivit prováděných za účelem správy aprovozu IT infrastruktury. Mezi prováděné aktivity patří:

❚ Správa provozních aktivit audálostí vIT infrastruktuře.

❚ Správa, provoz amonitoring pracovních stanic, serverů adatových center.

❚ Zálohy aobnovy dat anastavení.

❚ Plánování aprovádění rutinních úloh, skriptů.

❚ Správa ařízení tiskových ajiných výstupů.

❚ Fyzická alogická správa akonsolidace serverů adatových úložišť.

Hlavní rozdíl vzáměru představených definic je tedy zaměření na softwarovou část (vpřípadě údržby softwaru) ačást IT infrastruktury (vpřípadě OM). Pro bližší pochopení rozdílů těchto dvou světů si ilustrujme na dvou příkladech pohled ajazyk člověka zjedné adruhé strany:

Tabulka 1.2: Rozdíl azaměření správy aplikací asprávy IT infrastruktury

Pojem

Pohled údržby softwaru

Pohled OM– správa IT infrastruktury

Změna

Změna funkčnosti, chování, vzhledu softwarového systému

Změna čehokoli vIT infrastruktuře (tj. základní SW, databáze, HW či také nárůst kapacity úložiště, vyladění výkonnosti)

Konfigurace

Všechny části softwarového systému vdaných verzích (zdrojové, konfigurační, datové soubory) sloužící kběhu

Cokoli vIT infrastruktuře (HW, uživatelské stanice, tiskárny, sítě, aktivní prvky, operační systémy)

Pozorný čtenář si jistě všimne, že vprincipu se jedná ostejné pohledy, jen je předmětem jiná věc: software vs. infrastruktura (hardware, sítě azákladní software). Vpodstatě by se tento pohled dal zjednodušit na hmatatelné (infrastruktura) vs. nehmatatelné (aplikace, software). Tímto se dostáváme kproblematice existence různých skupin lidí vorganizaci ajejich světů aznich plynoucích jiných jazyků.

Na závěr ještě shrňme chápání představených definic vkontextu naší knihy. Vtextu se zaměřujeme se na obě kategorie, provoz aúdržbu softwaru isprávu aprovoz IT infrastruktury sprimárním důrazem na softwarovou stránku. Dále vtextu tyto aktivity budeme souhrnně nazývat „provoz aúdržba“.

Obrázek 1.9 ukazuje typický problém většiny organizací, které používají IT kpodpoře svých podnikových procesů. Vkontextu IT existují vdnešních organizacích následující skupiny (sila) vytvořená způsobem vývoje aprovozu IT systémů:

❚ Koncoví uživatelé– používají IT systémy ke své práci (pracovníci výroby, skladování, obchodníci, výzkumníci adalší), tyto systémy by jim měly přinášet hodnotu, pomáhat automatizovat aurychlovat jejich denní činnosti.

❚ Správci IT systémů– provozují audržují vchodu IT infrastrukturu ajednotlivé IT systémy, mohou být součástí dané organizace či 3. Strany (tzv. outsourcing).

❚ Vývojáři IT systémů– sbírají požadavky koncových uživatelů, analyzují je, navrhují, implementují atestují IT systémy na základě těchto požadavků; mohou být součástí organizace, externě poskytováni 3. stranou (tzv. outsourcing) či může být již vyvinutý produkt zakoupen.

Obrázek 1.9: Tři základní skupiny zpohledu IT ve většině organizací (zdroj: vlastní)

Tyto tři skupiny spolu musí často komunikovat avyjasňovat si společné cíle akroky. Koncoví uživatelé musí spolupracovat svývojáři na požadavcích apravidelných demonstracích vyvíjeného produktu (IT služby), čímž mohou ovlivňovat výsledek adostat produkt, který opravdu řeší jejich problémy. Údržba musí komunikovat aspolupracovat na vývoji, aby byla přenesena znalost produktu ataké naplněny požadavky na rozšiřitelnost audržovatelnost ataké, aby výsledný produkt splňoval definované požadavky na výkon (definovány vtzv. SLA– Service Level Agreement, dohoda okvalitě poskytované služby).

Pokud tato obousměrná komunikace nefunguje, může situace vypadat jako na následujícím obrázku, tedy jako vreálném životě většiny organizací. Každá ze zúčastněných rolí mluví jiným jazykem, výsledkem čehož je nepochopení na všech stranách avpřípadě tvorby IT služby pak nevhodné funkčnosti. Vývojáři hovoří technickou řečí (pojmy jako Java, XML, release), koncoví uživatelé, od kterých sbíráme požadavky, používají pojmy dané problémové domény (vpřípadě skladníka například: skladová položka, výdejka, dodací list) anejvyšší vedení poskytující finance pro tvorbu IT služeb hovoří vřeči financí.

Obrázek 1.10: Rozdílné pohledy na IT vkomplexním prostředí arozdílné jazyky spolupracujících rolí: analytik, podpora, koncoví uživatelé, vývojáři, vedení, manažer projektu/IT služby, analytik (zdroj: vlastní)

Výše uvedené skupiny jsou základní pohledy na IT vorganizaci. Bohužel díky složitosti arozdílnosti jednotlivých systémů atechnologií jsou tyto pohledy (anglicky „views“) vrámci všech tří skupin dále fragmentovány. Jeden člověk totiž nemůže pojmout celé řešení ze všech pohledů. Nemůže mít detailní znalost podnikových procesů, požadavků, znát architekturu ijednotlivé metody aatributy na úrovni kódu (představte si typickou podnikovou aplikaci mající několik tisíc tříd!). Výsledkem jsou pak různé pohledy (většinou podle rolí), které navíc informace duplikují azkreslují avedou klokální optimalizaci. Tato lokální optimalizace (nechtěně či záměrně) opomíjí ostatní pohledy asnaží se problém vyřešit pouze ze svého pohledu, což má za následek generování dalších problémů či dokonce celkový neúspěch aukončení projektu vytvoření či provozu IT služby. Princip (2) agilního provozu aúdržby je zaměřen na komunikaci azapojení všech rolí, což se projevuje:

❚ neustálou komunikací požadavků skoncovými uživateli ve formě pravidelných (například týdně) demonstrací spustitelné verze;

❚ měřením projektů aIT služeb vzhledem kpodnikovým cílům (společný, ne suboptimalizovaný anedekomponovaný cíl);

❚ vizualizací stavu projektu či IT služby různým rolím vjejich jazyce (splněné milníky pro projektové manažery; fungující mini-verze či SLA tabulky pro koncové uživatele; splněné rozpočty adata dodávky pro vlastníky projektů; trendy chyb aimplementovaných požadavků pro vývojový tým).

Tento tzv. systémový pohled prezentovaný tímto principem je jedním zřešení problému zapojení různých rolí ajejich odlišných jazyků aperspektiv.

Spolu srozdílnými pohledy ajinými jazyky těchto pohledů vstupuje jako problematický ještě faktor nejasnosti amnohoznačnosti lidského jazyka azpůsobu zpracování informace lidským mozkem. Podle kontextu se může význam daného slova či věty zásadně lišit ataké náš mozek nedokáže popsat kompletně složitý abstraktní systém, jímž je každý software (více viz princip (1) a(2) apraktika Boj smnohoznačností). Proto je nutné nepředávat požadavky koncových uživatelů pouze ve formě textu, ale komunikovat, vysvětlovat aprovádět pravidelné demonstrace koncovým uživatelům (iterativně inkrementální přístup).

Tato lidská přirozenost je vysvětlována na známé anglické říkance „Mary had alittle lamb“ ajejí interpretaci pomocí vícero významů výkladového slovníku [Le00]. Pokud jako klíčová slova vybereme „had“ a„lamb“ anahlédneme do výkladového slovníku, můžeme dostat desítky kombinací.

Samozřejmě asi nikdo nebude vyvíjet program na základě této věty, ale přesto je zajímavé se ptát, co vlastně tato věta znamená? Díky variabilitě amnohoznačnosti lidského jazyka se můžeme dostat až ktakovým absurdním kombinacím jako jsou následující [Le00]:

❚ Mary porodila malou antilopu.

❚ Mary snědla kousek jehněčího masa.

Skutečný sémantický význam této věty je pak: Mary měla jehňátko.

Nejasnost lidského jazyka aneschopnost našeho mozku popsat abstraktní složité systémy je nutné reflektovat při komunikaci mezi koncovými uživateli aIT pracovníky.

1.4 Metodiky, postupy, standardy

Adopci metodik vpraxi ztěžuje několik aspektů, respektive omezení. Jedná se o:

❚ Různou velikost týmů azaměření projektů:

❚ Enterprise Unified Process (EUP);

1.4.1 Správa IT služeb (ITSM)

…

1.4.2 Standard ISO 20000

1.4.3 Standard IEEE 1219

1.4.4 Standard ISO 12207

1.4.5 Microsoft Operations Framework (MOF)

1.4.6 Metodika MANTEMA

1.4.7 Enterprise Unified Process

1.4.8 CobiT

1.5 Shrnutí tradičních přístupů ajejich diskuse

1.6 Souhrn obecných problémů údržby IT systémů