Také se v posledních letech často setkáváte s názory, že informační podpora je drahá a její kvalita neodpovídá očekáváním byznysu? Jste schopni na tyto názory, ať již změnou kvality IT podpory a vynaložených nákladů, nebo podloženou argumentací o srovnatelnosti vaší informační podpory s vnějším trhem, reagovat? Na tyto otázky budete velmi těžko hledat odpovědi, pokud nebudete mít svůj informační systém a jeho řízení vůči svým zákazníkům dostatečně transparentní. V následujícím článku se pokusím velmi stručně naznačit směr, který by mohl pomoci těm, kdo se vydají na nelehkou cestu změny od technologického a poněkud démonizovaného pojetí informatiky k transparentní informační podpoře, poskytující pro dosažení cílů byznysu optimální informační podporu s minimálními náklady. Jsem si vědom, že každá z následujících kapitol by mohla být námětem na samostatný článek. Poučeným čtenářům se proto předem omlouvám za stručnost a uvedení kapitol, které již mají vyřešeny.

Iniciace změny

Každá změna je nějakým způsobem iniciována a je velmi důležité, kdo a s jakými cíli a očekáváními ji požaduje. Zamysleme se tedy společně, v čím zájmu transparentní informační podpora je a od koho můžeme očekávat při realizaci této změny podporu. Jsou to lidé z informatiky? Budeme od nich požadovat standardizaci, omezení tvůrčího rozletu a investic do posledních technologických hitů, možná i nějakou, z jejich hlediska zbytnou administrativu. Tedy nic, z čeho by byli primárně nadšeni. Jsou to naši uživatelé? Omezíme jim administrátorská práva, standardizujeme koncové stanice, budeme po nich například chtít, aby své požadavky směřovali přes jednotné kontaktní rozhraní na service desk, a ne přímo na známého informatika. Zde tedy asi také nenalezneme zvláštní podporu. Je to management? Management očekává, že do této podpůrné oblasti nebude muset investovat více, než je nezbytně nutné, a že za tyto náklady dostane nejméně takovou informační podporu, jakou má konkurence, přičemž jako bonus rád přijme i možnost konkurenční výhody. Z výše uvedeného zjednodušení vyplývá, že pokud je tato změna iniciována top managementem a získáme-li jeho skutečnou, nikoli pouze deklarativní podporu k eliminaci odporu prvních dvou skupin, máme napůl vyhráno. Významným faktorem je také osobnost a pozice nositele změny. Je zřejmé, že silná a vrcholovým managementem respektovaná osobnost, má na rozdíl od slabé osobnosti bez mandátu vedení podstatně větší předpoklady k úspěšnému dosažení cílů.

Vize a cíle

Je velice nepravděpodobné, že se nám podaří zasáhnout cíl, který nevidíme. Je tedy nutné definovat jasnou vizi a v jakém časovém horizontu jí chceme dosáhnout. Je naším primárním cílem absolutní snížení IT nákladů (limity), nebo dosažení nákladů srovnatelných s konkurencí (benchmark), dosažení konkurenční výhody (náš business produkt bude na trhu dříve a bude levnější), zvýšení úrovně podpory businessu (snížíme náklady core businessu), nebo máme jiné cíle? Musíme tedy tuto vizi jasně a srozumitelně formulovat a získat pro ni vrcholový management, bez jehož souhlasu a podpory není rozumné se do změny pouštět.

Vymezení teritoria
Nejdříve je nutné si ujasnit, co bude předmětem našeho zájmu. Jednoduše řečeno vykolíkovat si prostor, kterému budeme říkat informatika, a určit co bude za jejími hranicemi. Tato zdánlivě jednoduchá otázka se stane velmi složitou v okamžiku, kdy ji začneme řešit, a řešení je velmi často založeno na vzájemné dohodě a potřebě zúčastněných stran. Předem je nutné se rozhodnout, budou-li příslušné prostředky v majetku útvarů informatiky a které to budou. Budou předmětem našeho zájmu, mimo koncových stanic, serverů a tiskáren, také LAN, WAN, EPS, EZS, přístupové systémy, systémy technické ochrany, technologické systémy a další technické prostředky? Jak budeme definovat rozhraní pro tyto systémy, pokud se z nějakých důvodů rozhodneme, že nebudou do našeho operačního prostoru zahrnuty? Dále je třeba identifikovat všechny pracovníky, kteří se v podniku informatikou zabývají, a nepřipustit, aby nám v podniku zůstala „šedá informatika“, ukrytá s podporou středního managementu pod nejrůznějšími funkcemi. V budoucnu by nám tyto zdroje svými zásahy do informačního systému komplikovaly jeho správu i rozvoj a představovaly duplicitní a obtížně identifikovatelné náklady systému.

Identifikace nákladů

Víme tedy, jaké materiální a lidské zdroje máme k dispozici. Jako první předpoklad úspěchu je třeba zajistit, aby všechny náklady organizačních jednotek v naší informační struktuře související s těmito zdroji byly plánovány a směrovány na nákladová střediska s jednotnou účetní osnovou. Nebude to jednoduché a nebude to hned. První přehled o nákladech námi vymezené informatiky získáme zhruba po roce. Pokud se nám navíc podaří sledovat náklady na informatiku i ve struktuře využitelné pro srovnání s externím trhem, můžeme v této době také provést již první srovnání naší nákladové úrovně formou benchmarků s využitím volně přístupných nebo placených informačních zdrojů a vedení poskytnout informace o reálné nákladové úrovni informační podpory.

Standardizace řízení

Centralizace a transformace zdrojů informatiky nám vytvořila prostor pro standardizaci řízení. Není rozumné jít v této oblasti vlastní cestou a snažit se znovu vynalézt kolo. V současné době již existuje celá řada metodik a nejlepších postupů, které nám umožňují zvýšit výkonnost vlastních procesů. Poslední verze metodiky ITIL, která se již stala obecně uznávaným neformálním standardem řízení informačních procesů, metodika COBIT zaměřená zejména na hodnocení a audit informačních systémů a v neposlední řadě i ISO 20000, která této oblasti dává žádoucí legislativní rámec, nám mohou v našem snažení významně pomoci. Standardizace procesů řízení nám umožní tyto procesy popsat, řídit a nadále zlepšovat. Umožňuje měřit výkonnost jednotlivých procesů a přes KPI provázat jejich parametry výkonnosti na motivaci jejich vlastníků.

Inventarizace nabídky

Současně s činnostmi předchozích kapitol a při znalosti našich zdrojů a nákladů bychom měli inventarizovat možnosti naší nabídky. Jaké služby, v jakém rozsahu a kvalitě jsme schopni našim zákazníkům poskytovat? Do jaké doby jsme schopni našimi procesy zpracovat a uspokojit požadavky našich zákazníků na podporu? Jsme schopni při našem technologickém a aplikačním vybavení nabídnout našim zákazníkům kvalitu služeb srovnatelnou s trhem? Máme tuto kvalitu a podporu dostatečně smluvně podpořenou našimi subdodavateli? Po vyřešení těchto příkladů otázek a mnohých dalších bychom měli být schopni kriticky posoudit naše možnosti nabídky služeb našim zákazníkům a mít tak hrubou představu o jejich struktuře a kvalitě.

Identifikace zákazníků

Další zdánlivě jednoduchou otázkou je ve velkém podniku identifikace zákazníků. Je zjevné, že jimi nebude několik tisíc uživatelů, ale že našimi zákazníky budou dostatečně velké organizační celky, s jejichž představiteli jsme schopni jednat o rozsahu a kvalitě služeb. Předpokládejme, že s těmito zákazníky budeme uzavírat interní dohody. V organizačních celcích velkého podniku bude zcela jistě různá představa o úrovni sjednávání. Naší snahou by mělo být sjednocení. Pokud bychom přistoupili na různou úroveň zákazníků v jednotlivých organizačních jednotkách, komplikovali bychom si budoucí standardizaci smluvních vztahů, zejména pokud by součástí budoucích dohod bylo i přeúčtování nákladů za služby. Přestože naším zákazníkem, tedy tím, kdo podepíše příslušnou dohodu a bude nám za služby platit, bude zřejmě ředitel příslušné divize nebo obdobného organizačního celku, službu budeme s největší pravděpodobností sjednávat s jím pověřeným zástupcem. Je na nás, abychom takové osoby byli schopni identifikovat a s příslušným zákazníkem se dohodli, že je tímto úkolem pověří. Pokud bychom totiž museli jednat se všemi útvary zákazníka, výsledku bychom se těžko dobrali. Transformace informační podpory na interní nebo externí vztah je poměrně náročný proces a jeho aktéři potřebují nějaký čas, aby se v těchto nových rolích dokázali orientovat.

Inventarizace potřeb zákazníků

Máme tedy s kým jednat a máme mu co nabídnout. Je to ale skutečně to, co náš zákazník potřebuje? Je ochoten za nabízený rozsah a kvalitu služeb také zaplatit námi kalkulovanou cenu? Je naše podpora dostatečně rychlá? S našimi zákazníky musíme řešit celou řadu podobných otázek a společně hledat shodu.

Návrh portfolia služeb

Na základě znalostí získaných v předchozích kapitolách jsme schopni přistoupit k návrhu našeho portfolia služeb. Jejich počet v portfoliu by neměl být velký, a to i za cenu, že budeme muset provést vhodnou agregaci. Doporučoval bych počet služeb zhruba do dvou desítek s tím, že některé je vhodné dále členit na jednotlivé, samostatně oceněné produkty. Má to docela prozaický důvod. Je třeba si uvědomit, že budeme muset každou službu podrobně popsat, sjednávat a monitorovat její kvalitu, kalkulovat její cenu a reportovat o dodržení sjednaných parametrů. Při velkém počtu služeb bychom si tak způsobili nezvládnutelný problém a významné navýšení transakčních nákladů poskytování služeb. Do portfolia služeb zařazujeme takové služby, které je zákazník schopen identifikovat. Jedná se například o přístup ke klíčovým aplikacím, internetu, podporu koncové stanice apod. Naopak do nabízených služeb nezařazujeme například infrastrukturní služby typu provoz serverů, LAN apod. Zákazníkům je celkem jedno, kde a na jaké technologii jejich aplikace běží. Pro ně je důležité, že na jejich obrazovce aplikace funguje a mají jejím prostřednictvím přístup ke svým datům, a pokud ne, tak se tak v krátké době stane.

Struktura služeb

Při navrhování služeb je důležité neztratit ze zřetele jejich vnitřní strukturu. Pokud již v této fázi budeme finální služby skládat z dílčích komponent a bude nám jasné, kdo je jejich vnitřním dodavatelem, umožní nám to nastavit uvnitř informatiky dodavatelské vztahy, které můžeme v ideálním případě zastřešit interními dohodami provozních útvarů informatiky o dodávce jednotlivých komponent a úrovni jejich kvality (OLA). Vhodná struktura komponent nám umožní přesnou alokaci nákladů na jednotlivé služby a jejich transparentní kalkulace, včetně možnosti srovnatelnosti s vnějším trhem. Podrobnější informace, které nám mohou pomoci při řešení tohoto problému, nám může poskytnout metoda Activity Based Costing (ABC). Pozdější implementace tohoto přístupu je již vážným zásahem do celého systému.

Popis služeb

Jednotlivé služby je třeba poměrně přesně popsat, a to jazykem srozumitelným pro poskytovatele i zákazníka. Způsob popisu je limitován úrovní obou subjektů. Tam, kde lze očekávat velký interval mezi úrovní poskytovatele a uživatelů, je nalezení společného jazyka náročným úkolem. Naopak v případě, kdy se jedná o vyspělé uživatele, může být popis služeb sofistikovanější. Popis služby by měl být co nejvíce strukturovaný. Musí obsahovat nejméně popis předmětu služby, kvalitu služby a podmínky její dodávky. Podrobný způsob a forma popisu IT služeb je samostatným tématem mimo možnosti rozsahu tohoto článku. Soubor popisu jednotlivých služeb je obecně znám pod pojmem katalog služeb, sloužícím jako nabídkový dokument, případně jako součást smlouvy o poskytování služeb.

Kvalita služeb

Zákazník očekává, že obdrží sjednanou kvalitu služeb. K tomu účelu je nutné stanovit kvalitativní parametry, které budou jednoznačně prokazatelné, měřitelné a kontrolovatelné zákazníkem. Dalším krokem je potom dohoda o konkrétních smluvních hodnotách těchto parametrů. Je nesmyslem stanovit takové parametry, které nejsme schopni měřit, nebo takové hodnoty parametrů, které nejsme schopni dosáhnout, třeba proto, že nemáme na potřebné úrovni sjednanou podporu třetích stran. Kvalitativních parametrů by nemělo být mnoho a měly by být pokud možno ve všech službách stejné, včetně snahy o standardizaci jejich hodnot. Solidní poskytovatel služeb by měl vystačit s několika málo parametry. Z hlediska typu můžeme parametry rozdělit do dvou základních skupin. Na parametry dokladující úroveň podpory a parametry prokazující úroveň stability a kontinuity dodávky. Příkladem první skupiny je například reakční doba na požadavek nebo doba realizace požadavku, příkladem druhé skupiny je dostupnost systému. Prvou skupinu požadavků jsme schopni sledovat prostřednictvím evidence service desku, monitoring druhé skupiny parametrů je podstatně složitější a nákladnější a je převážně realizován prostřednictvím dohledových systémů.

Cena služeb

Kvalitu služeb je nutné svázat s jejich cenou. Vztah kvality a ceny není lineární. V odborné literatuře se obecně uvádí, že cena služby narůstá v závislosti na kvalitě exponenciálně. Kvalitnější služba tedy musí být dražší, méně kvalitní levnější. Pokud chceme zákazníka motivovat k úsporám a na druhé straně snížit i vlastní náklady informační podpory úsporou investic vyvolaných nereálným tlakem zákazníka na kvalitu služby, je účelné, aby zákazník měl v úrovni služby, a tedy i ceny volbu. Pokud jsme v přípravě naší transformace neopominuli kroky uvedené v předchozích kapitolách, neměli bychom mít s kalkulací ceny služeb problém. Náklady máme tedy alokované na jednotlivé komponenty služeb a můžeme z nich snadno výslednou cenu služby poskládat. Pokud jsme tento přístup v předchozích krocích zanedbali, nevyhneme se při rozpuštění celkových nákladů informatiky do jednotlivých služeb křížovým dotacím, a to ve svém důsledku povede k cenové nekonkurenceschopnosti některých služeb s externím trhem a oprávněným výtkám zákazníků, že na externím trhu lze konkrétní službu pořídit levněji. Ve svém důsledku by to mohlo vést i k nesprávné interpretaci a parciálnímu outsourcingu služby.

Smlouva o úrovni služeb

Celý tento článek popisuje proces tvorby korektního rozhraní mezi poskytovatelem a zákazníkem IT služeb. Završením tohoto procesu je jeho formalizace. Pokud jsme ve fázi, že vytváříme tento vztah uvnitř právního subjektu, postačí jej formalizovat formou dohod mezi útvarem informatiky a jednotlivými interními zákazníky s tím, že případné nesoulady řeší liniové vedení. Snažíme se ale, aby tento vztah měl pokud možno všechny atributy předchozích kapitol. Transformační proces a zvládnutí rolí zákazníka a poskytovatele chce nějaký čas a interní fáze zavedení řízení úrovně poskytovaných IT služeb je vhodnou přípravou na případné vyčlenění tohoto procesu z organizace. K rozhodnutí o případném vyčlenění IT podpory tak budeme mít již dostatek přesných a ověřených informací. Budeme znát náklady na IT podporu, služby, které za to dostáváme, budeme mít identifikované zákazníky a zvládnuty jejich role při sjednávání, přejímce a kontrole služeb. Jsme tedy podstatně připravenější na řízení tohoto vztahu. Nelze předpokládat, že pokud nejsme schopni uřídit informační podporu interně, podaří se nám tento vztah beze ztrát uřídit s externím dodavatelem. Pokud jsme po předchozích krocích dospěli k závěru, že bude účelnější IT služby zajišťovat externě a tento návrh je vedením společnosti akceptován, je nutné vztah mezi právními subjekty poskytovatele a příjemce služby řešit již standardním smluvním vztahem, smlouvou o poskytování IT služeb obecně známou jako service level agreement (SLA). V této smlouvě již musíme mít, mimo základních smluvních atributů, jako je předmět, termín a cena, samozřejmě ošetřeny i další náležitosti, jako například způsob přejímky, reporting o kvalitě a rozsahu apod.

Přejímka služeb

Jsme tedy ve fázi, kdy již máme sjednané služby a realizovaný proces jejich poskytování. Z hlediska zákazníka je nutné si ujasnit, jakým způsobem a jak podrobně budeme sledovat kvalitu dodávky služeb, jakým způsobem je budeme věcně přejímat jako předpoklad pro akceptaci fakturace, jakým způsobem budeme kontrolovat rozsah dodaných služeb, a mít to vše předem ošetřeno v SLA. Pokud je vedením společnosti zákazníka požadováno rozúčtování nákladů za IT služby na jednotlivá nákladová střediska a společnost současně prochází permanentní organizační změnou, musí mít poskytovatel k dispozici průběžně aktualizovanou evidenci. Evidence umožní detailní mapování spotřeby služeb na jednotlivé uživatele a lze z ní generovat fakturační podklad v členění podle jednotlivých zákazníků a jejich nákladových středisek. Je pro obě strany výhodné, pokud se dohodnou, že před vystavením faktury bude tento fakturační podklad, dokladující odebrané množství jednotek služeb, jejich kvalitu a množství odebraného materiálu, odsouhlasen oběma stranami. Vyhneme se tak vracení faktur a následným dohadům o správnosti fakturace.

Spokojenost zákazníků a uživatelů

Poslední a neméně důležitou kapitolou je zjišťování spokojenosti zákazníka a jeho uživatelů. Je to důležité pro obě smluvní strany. Poskytovatel tak zjistí slabé stránky svého procesu a zástupce zákazníka si udělá představu o spokojenosti jednotlivých cílových skupin uživatelů a zákazníků. Zjišťování spokojenosti uživatelů můžeme provádět několika způsoby. Lze k tomu využít databáze zpětných dotazů ze service desku pro zjištění spokojenosti koncových uživatelů nebo formy pravidelných anket. V případě anketního průzkumu je vhodné určit významné cílové skupiny, například management, skupinu zástupců zákazníků pověřených řízením vztahu a v neposlední řadě skupinu koncových zákazníků. Pokud je v některé skupině například velké množství koncových zákazníků, pak musíme provést náhodný výběr tak, abychom získali statisticky významný vzorek respondentů. Pro každou skupinu zpracujeme soubor relevantních otázek. Anketní průzkum není vhodné opakovat v častých intervalech. Vzhledem k tomu, že budete potřebovat nějaký čas na jeho vyhodnocení, přijetí a realizaci opatření, doporučoval bych maximálně půlroční interval. Výsledky průzkumu je nutné včetně přijatých opatření zveřejnit. Pokud by respondenti získali dojem, že jejich aktivita není využita a nevede ke zlepšování stavu, při příští anketě se to zcela jistě projeví na návratnosti dotazníků. A spokojenost zákazníka a jeho uživatelů by měl být jeden z hlavních cílů každého poskytovatele IT služeb. Každý zákazník právem očekává, že za co nejmenší peníz dostane co nejvíce muziky a neexistuje důvod, proč bychom si měli myslet, že se odběratel IT služeb bude chovat jinak. To je i jeden z hlavních hybných faktorů současné transformace informatiky na standardního poskytovatele IT služeb.

Autor je vedoucím oddělení řízení úrovně služeb ICT ve společnosti ČEZ.