Avšak překvapivě málo organizací si uvědomuje dopad ITILu na procesy organizace mimo IT oddělení. Pokud implementace ITILu omezí přímou komunikaci mezi jednotlivými pracovníky IT a zbytkem firmy, objeví se třecí plocha, s níž se při implementaci většinou nepočítalo. Pracovníci mimo IT si často postupně vytváří komunikační vztah s vybranými jedinci v IT a řeší své potřeby přímo s nimi. Tito oblíbení pracovníci IT pak nejsou schopni kvůli neustálému odvádění od činnosti vykonávat delší pracovní úkoly během pracovní doby a přesouvají je buď do mimopracovní doby, nebo na své kolegy. Důslednou implementací ITILu se tato komunikace omezí, zohlední se však pravé důvody této komunikace – sdílení znalostí o chodu společnosti mezi IT a zbytkem organizace.
Uveďme si dva nejčastější případy podobné firemní praxe – řešení nestandardního chování informačních systémů a požadavky na změny v informačních systémech.
NESTANDARDNÍ CHOVÁNÍ IS
Pracovník, jemuž IS odmítá poskytovat očekávanou odezvu, se potřebuje ujistit, zda jde o chybu v systému nebo jen o nepochopení funkcí systému z jeho strany. Vžijme se teď do situace mladého prodejce na bankovní přepážce, k němuž přijde zákazník s dotazem, zda může svou půjčku u banky převést na hypotéku. Pracovník z terminálu zjistí výši nesplacené půjčky včetně bankovních poplatků, nicméně také odhalí, že danému zákazníkovi nelze hypotéku prodat (zákazník přišel s příslušnými doklady včetně odhadu nemovitosti od smluvního odhadce banky), neboť je veden na černém seznamu. A fronta dalších zákazníků narůstá …
Takovýto pracovník znejistí a začne hledat pomoc u standardních zdrojů, jimiž jsou:
- Popis pracovního postupu – ve většině organizací v České republice (na rozdíl od SRN nebo Velké Británie) se však bude marně pídit po aktuální verzi takovéhoto postupu. I když jsou bankovní domy většinou výjimkou, jeden z největších na našem území pro tuto situaci postup neměl.
- Uživatelská příručka systému – tato většinou popisuje jen význam jednotlivých polí v systému, nikoliv řešení situací výše uvedeného typu.
- Volání do IT oddělení – pokud je IT chráněno „Dohodou o úrovni poskytovaných služeb“ (SLA) v důsledku implementace ITIL nebo kvůli outsourcingu, pak může být takovéto volání zpoplatněno (jedna outsourcingová organizace požaduje za každé volání i 10 euro), na což většinou v oddělení není rozpočet. A navíc v tomto konkrétním případě IT odpovědělo, že se nejedná o chybu, ale o běžnou funkci systému (černý seznam je aktualizován jednou denně).
- Kontaktování zkušenějšího kolegy – ten je tímto vyrušen od své práce. Navíc velmi často takováto situace vyžaduje hlubší náhled a rozebrání příčin a postupně je do řešení vtahováno stále více pracovníků i z jiných oddělení. Navíc, pokud je iniciátorem nový pracovník, málokdo ze starších pracovníků přizná, že si se situací také neví rady. A přitom v minulosti stačilo zavolat do IT a „přehrát“ problém na ně dotazem, kde je tedy chyba, když ne v aplikaci.
Nyní se pro úplnost podívejme také na řešení pomocí implementace principů ITILu zpět do oddělení:
- Vedoucí oddělení vyhradí několika pracovníkům v oddělení čas na pomoc svým kolegům.
- Každý jednotlivý pracovník v oddělení pak ví, kdo mu může pomoci s neočekávanými problémy, a nezdržuje se s hledáním pomoci jinde.
- Pracovník-pomocník má také možnost konzultovat situaci s jinými takto určenými kolegy z jiných oddělení či lokalit, aniž by se tím narušovala činnost oddělení.
- Pokud pracovník-pomocník zjistí, že se jedná o chybu informačního systému, vždy se může obrátit na IT, které postupuje podle procesů ITIL v oblasti řízení incidentů.
- U větších organizací se pak přímo vydělují z řad takovýchto pracovníků-pomocníků metodici, jejichž jedinou pracovní náplní je právě pomoc (pokud nepíší pracovní postupy).
Navíc tato implementace zefektivní také činnost samotného IT, které by jinak muselo odhadnout počet pracovníků svého servisního centra podle počtu koncových uživatelů (z nichž každý může kdykoliv zavolat). Současně u mnohonárodních organizací je možno vybírat takové pracovníky, kteří umí některý světový jazyk, a tím redukovat nutné požadavky na IT podporu.
POŽADAVKY NA ZMĚNU IS
Pokud se někdo v organizaci začne dožadovat změny v informačních systémech, můžeme většinou využít tyto základní postupy:
Implementace rozsáhlé změny na níž participuje více oddělení – nový produkt, změna v řízení zásob v distribuci, změna v práci s prodejci či dodavateli, implementace do účetnictví apod.
Zavedení malého zlepšení – například změna průchodu jednotlivými políčky formuláře, oprava nejasných zkratek, předvyplnění hodnoty do políčka a povinnost vyplnění polí v souladu se zavedenou praxí v pracovním postupu – umožňující zvýšit efektivitu příjmu zakázky.
Provedení jednoduché změny – např. změna textu „čas v m“ na „čas v min.“ nebo změna barev v rozhraní.
U jednoduchých změn se správnou SLA zamezuje nekonečné kreativitě zaměstnanců na obou stranách – IT by rádo dělalo jen výše uvedené jednoduché změny, ostatní oddělení budou mít zase pocit povolené tvořivosti. Naneštěstí pro žádost o změnu začíná IT oddělení vyžadovat souhlas odpovědné osoby – pracovníka-pomocníka, metodika či vedoucího oddělení – , čímž proces tvůrčího rozletu zbrzdí, ne-li úplně zastaví. Ono totiž dostat ze dvou různých lokalit žádost o změnu pozadí jednou na červeno-bílé a jednou na červeno-žluté není pro IT jednoduchou záležitostí: Musí se rozhodnout, komu vyhovět a komu ne.
U implementace malých zlepšení jde většinou o doladění příslušných rozdílů mezi generickou IT aplikací a schválenými pracovními postupy. Umístění políček na obrazovkách je většinou poplatné struktuře databáze a bývá ovlivněno i kreativitou výrobce v oblasti použití různých záložek a grafických efektů. Malá zlepšení pak z generického nástroje vytvoří aplikaci použitelnou pro konkrétní pracovní postupy ve firmě, i když se často mění. Ideálním kandidátem pro navrhování takovýchto změn je metodik (ručící za obsah) ve spolupráci s vedoucím oddělení (ručícím za finanční pokrytí požadavku).
ROZSÁHLÉ ZMĚNY
Posledním typem změn jsou rozsáhlé změny vyvolané nějakou iniciativou mimo IT. IT pak od této iniciativy dostane několik zadání, aby byla implementována změna v základních aplikacích, přidány specifické aplikace pro danou iniciativu a podpořeny nově vzniklé pracovní postupy.
IT vyžaduje od zbytku organizace jasné zadání změn formou přesně formulovaných požadavků, aby mohlo zahájit proces návrhu IT řešení, a bylo tak schopno ocenit požadavek formou finanční (s pomocí „člověkodnů“) a prostřednictvím případných změn SLA. Toto ocenění se pak stává součástí investičního záměru dané iniciativy – záleží na organizaci, do jaké úrovně podrobnosti toto ocenění požaduje.
Tady začíná kámen úrazu – i když se jedná o jednu novou iniciativu, zadání do IT je směřováno z různých oddělení, kterých se metodika týká. Dobře volenou SLA je možno omezit počet zadání i jeho změn (např. vybíráním poplatků za jednotlivé změny), omezit neplánovitost – např. zadání musí být známo deset pracovních dní předem, aby bylo možno zkontrolovat jeho úplnost, v opačném případě je účtován vyšší poplatek. Ostatně i na proces výběru dodavatele (RFP) je běžně ponechán čas, tak proč ne i pro vnitřního dodavatele IT.
Co může vypadat jako jednoduchá změna na straně marketingu (přidání nepřímých zákazníků do zákaznické databáze), může na straně IT vyvolat velké změny, které není možno zajistit během jednoho dne (navýšení kapacity disků, licence na databáze, výkonnostní testy aj.), a je nutné změnit stávající dohody s dodavateli technologií.
Nejvýraznějším problémem je, že IT je pak většinou první instancí, která skládá mnohdy protichůdné požadavky jednotlivých oddělení zpět do zadání jediné změny vyvolané iniciativou. A pokud se neobtěžuje se skládáním a zjišťováním prapříčiny, může indikovat vyšší náklady, než by bylo nutné, pokud by požadavek přišel najednou. Současně pokud metodik daného oddělení spojí požadavky několika iniciativ do jediného požadavku na IT, může zrušení některé iniciativy způsobit následnou změnu původního IT zadání. Častým případem také je, že se některé oddělení „zapomene“ a své požadavky do IT dodá se zpožděním, kdy již IT má požadavky ostatních oddělení řešené nějakým nevhodným kompromisním způsobem, neboť nebylo možno čekat na chybějící zadání (nebo se o nevhodnosti na úrovni IT ani nevědělo).
JAK NA TO?
Dobré řešení je většinou takové, které používá jednak zřetězení požadavků přes identifikaci iniciativy v jednotlivých požadavcích stejné iniciativy, jednak podávání požadavků souhrnně přes vedení programu, který změnu požaduje. Je také vhodné zařadit IT část přímo do programu a kontrolovat zpoždění a rizika centrálně než prostřednictvím projektů (úkolů) jednotlivých oddělení.
Součástí dobrého řešení je i koordinace mezi metodiky při formulaci zadání tak, aby se zamezilo nejasnostem v zadání. Zatímco ve fázi zadání je možno najít kompromisní variantu snáze, ve fázi návrhu řešení či v implementační fázi, kdy by to znamenalo změnu zadání do IT, jde spíše o prestiž a neochotu zadavatele připustit vlastní pochybení.
Kontrola procesu zadávání ať již drobných, malých či rozsáhlých řešení pomůže nejen IT (které je díky implementaci principů ITIL schopno ve velmi krátkém čase přinést poměrně přesný rozpad nákladů na jednotlivá oddělení), ale zrychlí i implementaci nových iniciativ. ITIL totiž zrychlí vývojový cyklus na straně IT, ale neodstraní neustálé změny a odvolávání zadání.
Na závěr varování: Většina z nás volá po zprůhlednění a vyšší efektivitě IT, ale když ji ITIL pomůže zajistit, většinou se objevují nedostatky v zadávání a znalosti pracovních postupů v ostatních částech organizace. Nepřesné hlášení typu „mám problém s počítačem“ se dá totiž vyložit různými způsoby.
PŘEDPLATNÉ
ČLÁNKY DO MAILU