Zavedení proaktivního přístupu v poskytování služeb zákazníkům do organizace

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Zavedení proaktivního přístupu v poskytování služeb zákazníkům do organizace

DIPLOMOVÁ PRÁCE

Bc. Jiří Sláma

Brno, 2014

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Vedoucí práce: Ing. Aleš Studený

ii

Poděkování Rád bych poděkoval vedoucímu své diplomové práce, Ing. Aleši Studenému, za vedení mé diplomové práce a poskytnuté rady. Dále bych chtěl poděkovat společnosti ALVAO s. r. o. za to, že mi poskytla všechny potřebné prostředky pro vytvoření tohoto díla.

iii

Shrnutí Cílem práce je analyzovat možnosti zajištění spokojenosti zákazníků s poskytovanými službami. V úvodní části je popsána teorie způsobu dosažení definovaných cílů (spokojenost zákazníka, dosažení kvality služeb) pomocí přechodu z reaktivního módu řízení služeb na proaktivní s použitím nejlepších praktik publikovaných v Information Technology Infrastructure Library (ITIL®). V praktické části jsou dříve vysvětlené metodiky uvedeny do praktického použití ve společnosti ALVAO s. r. o. Závěrečná pasáž je věnována shrnutí získaných výsledků a zhodnocením přínosu nasazení proaktivního módu řízení v poskytování služeb zákazníkovi ve zmiňované společnosti.

iv

Klíčová slova ITIL®, proaktivní mód, neustálé zlepšování služeb, služba, ITSM, technická podpora, ALVAO Service Desk

v

Obsah Úvod ....................................................................................................................................................... 1 1

2

3

4

Správa služeb IT ........................................................................................................................... 3 1.1

Správa služeb IT (ITSM) ...................................................................................................... 3

1.2

IT služba ................................................................................................................................. 4

1.3

Katalog služeb ....................................................................................................................... 4

1.4

Dohoda o úrovních služeb (Service Level Agreement, SLA) ......................................... 5

1.5

Proces ..................................................................................................................................... 6

1.6

Poskytovatelé služeb ............................................................................................................ 7

Information Technology Infrastructure Library (ITIL®) ........................................................ 8 2.1

Proč je ITIL® úspěšný? ........................................................................................................ 9

2.2

Přínosy ITIL® pro organizace............................................................................................. 9

2.3

Struktura životního cyklu služby ....................................................................................... 9

2.3.1

Strategie služby (Service Strategy) ........................................................................... 10

2.3.2

Návrh služby (Service Design) ................................................................................. 11

2.3.3

Přechod služby (Service Transition) ........................................................................ 12

2.3.4

Provoz služby (Service Operation) .......................................................................... 12

2.3.5

Neustálé zlepšování služby (Continual Service Improvement. CSI) .................. 15

Analýza stávajícího prostředí organizace ............................................................................... 24 3.1

ALVAO s. r. o. ..................................................................................................................... 24

3.2

Technická podpora (TP) .................................................................................................... 24

3.2.1

Tým ............................................................................................................................... 25

3.2.2

Řešení požadavků ...................................................................................................... 27

3.2.3

Správa procesů ............................................................................................................ 33

3.2.4

Zákaznický feedback.................................................................................................. 34

3.2.5

ALVAO Service Desk ................................................................................................. 37

Návrh změn ................................................................................................................................. 38 4.1

Změny týkající se nepřímo služby technické podpory ................................................. 38

4.2

Změny týkající se přímo služby technické podpory ..................................................... 40

4.2.1

Držení služeb TP konzultanty .................................................................................. 40

4.2.2

Proaktivní zjišťování aktuálního stavu používání systému ................................. 41

4.2.3

Nabídka profylaktické kontroly ............................................................................... 42

4.2.4

Definice přesných pracovních procesů ve službě TP ............................................ 42 vi

4.2.5

Pravidelná kontrola reportů o dodržování SLA ve službě TP ............................. 44

4.2.6

Kontrola využívání L3 supportu při poskytování služby TP .............................. 45

4.2.7

Zavedení termínů pro vyřešení požadavků ve službě TP .................................... 46

4.2.8

Nastavení upozornění na neřešení požadavků či poruše SLA ............................ 47

4.2.9

Zvýšení kvalifikace L1 supportu .............................................................................. 49

4.2.10

Zavedení nové služby „Technická podpora/Dotazy“ ........................................... 50

4.3 5

6

Shrnutí návrhů na změny.................................................................................................. 51

Implementace změn ................................................................................................................... 52 5.1

Realizované změny ............................................................................................................ 52

5.2

Změny čekající na realizaci ............................................................................................... 54

Vyhodnocení přechodu na proaktivní přístup ...................................................................... 55 6.1

Kvalita služeb ...................................................................................................................... 55

6.1.1

Trend ve vytváření požadavků ................................................................................ 55

6.1.2

Reakční doby ............................................................................................................... 57

6.1.3

Řešení požadavků ...................................................................................................... 58

6.1.4

Zákaznický feedback.................................................................................................. 61

6.2

Další dopady ....................................................................................................................... 63

6.2.1

Redukce zapojení L3 úrovně do služby technické podpory ................................ 63

6.2.2

Zvýšení prodeje dalších služeb................................................................................. 65

7

Závěr............................................................................................................................................. 66

8

Přílohy .......................................................................................................................................... 67

Literatura ............................................................................................................................................. 77

vii

Úvod V dnešní době jsou počítačové systémy nedílnou součástí většiny podniků a v mnoha případech mají přímý dopad do byznysu dané společnosti, proto je velmi důležité nastavit správně firemní procesy, aby se předešlo různým výpadkům či nedostupnosti důležitých služeb. Ve většině případů se toto téma řeší v organizacích až v případě, kdy dojde k nějakému selhání, které významně ovlivnilo byznys. Tuto situaci si můžeme ukázat na následujícím příkladu. Ve společnosti se porouchá stroj, který vyrábí důležité součástky. Z důvodu této odstávky dojde ke zpoždění výroby objednaného množství výsledných výrobků. Odběratel má ve smlouvě termín dodání zakoupeného zboží, a pokud není tento termín dodržen, může po výrobci požadovat slevu. Jelikož nejsou ve společnosti řízeny procesy, které pevně definují, jak se zachovat v podobném případě, dojde k porušení stanovené doby dodání, což znamená, že odběratel může po výrobci požadovat sankce. V lepších případech se příčina selhání analyzuje a vyvodí se z ní patřičné preventivní kroky, aby se výpadek či porucha znovu neopakovala. V řadě případů se však po vyřešení incidentu další opatření nevydávají a je jen otázkou času, kdy se objeví další problém. Do řady podniků se z výše uvedených důvodů zavádí procesní řízení, např. dle nejlepších praktik publikovaných v knihovně ITIL®, či implementují softwarová řešení od různých dodavatelů. Zavedení nových procesů či implementace nového nástroje na podporu byznysu stojí organizace nemalé finanční prostředky. Samotná implementace je v některých případech velmi časově náročná a může trvat i roky. Pokud se však zavedení nových procesů či implementace podpůrného nástroje povede, může to vést k ušetření velkých finančních prostředků společnosti v budoucnosti. Pokud se organizace rozhodne pro implementaci nějakého nástroje, který ji pomůže nastavit procesy, aby mohla lépe řídit dodávku poskytovaných služeb, ať již interně svým zaměstnancům, či externě svým zákazníkům, je velmi důležité zvolit vhodný nástroj. Na trhu je dnes nepřeberné množství různých nástrojů pro podporu řízení služeb. Některé řešení se mohou chlubit různými oceněními např., že podporují různé množství procesů dle ITIL®, či ocenění od jiných certifikačních autorit. Během mého studia se mi naskytla příležitost pracovat ve společnosti ALVAO s.r.o., která se zabývá vývojem a nasazením řešení pro řízení podnikového IT, které lze rozšířit i do ostatních servisních oddělení v organizaci jako je např. správa vozového parku, personální oddělení a další. Primárně je však určen pro IT oddělení, kde se dá jeden z vyvinutých systémů využít jako helpdeskový systém. Tato aplikace je určena

1

ÚVOD

uživatelům, aby mohli zadávat problémy (požadavky), které potřebují vyřešit a mohou v ní sledovat i průběh samotného řešení. Ve společnosti ALVAO je tento produkt využíván jak interně pro evidování různých činností, které zaměstnanci společnosti ve své pracovní době provedli, tak i externě. S tímto druhým způsobem použití bude spojena převážná část této diplomové práce. Externím použitím je myšleno, že pomocí tohoto systému jsou evidovány veškeré připomínky od zákazníků na jednom místě (Single point of contact, SPOC). Pro zákazníky je vytvořena speciální služba technické podpory, do které zakládají svoje požadavky např. chyby v produktu, na které narazily během používání systému, problémy s používáním produktu či návrhy na jeho zlepšení. Díky tomu, že jsou všechny problémy evidovány na jednom místě, lze lépe tuto poskytovanou službu zákazníkům řídit. Ve většině oddělení, které se zabývají technickou podporou, se používá reaktivní přístup při řešení problémů. Pracovníci na technické podpoře jsou tedy připraveni na telefonu, e-mailu případně jiném komunikačním kanálu a čekají, až se zákazníkovi něco porouchá, aby mu mohli s jeho problémem pomoci. Na druhé straně tohoto přístupu stojí proaktivní mód. Ten se vyznačuje tím, že pracovníci technické podpory nejen, že vykonávají stejnou práci jako pracovníci při použití reaktivního přístupu, ale navíc se snaží analyzovat problémy zákazníků, vyvodit z nich závěry a provést patřičná opatření, aby se opakované chyby zákazníků již nevyskytovaly. Mezi další rysy proaktivního řízení patří provádění průběžných kontrol provozovaných systémů u zákazníků. Pokud jsou nalezeny nějaké nesrovnalosti v chování systémů či v práci jejich uživatelů, jsou okamžitě prováděny potřebné kroky k nápravě.

2

1 Správa služeb IT Cílem této kapitoly je vysvětlení, co to vlastně služby informačních technologií jsou a popsání důvodů, proč se zabývat jejich řízením. Ve většině případů totiž nestačí, pokud budou fungovat servery, tiskárny a ostatní IT zařízení a budou pro uživatele dostupná všechna data a všechny aplikace, které podniková informatika spravuje. Pro lepší představu zde uvedu příklad z praxe. Jste zaměstnancem pobočky banky a přijde za Vámi zákazník sjednat výhodné pojištění. Vše se Vám podaří během chvilky zadat do systému a máte výslednou smlouvu ve formátu PDF, kterou potřebujete vytisknout k podpisu. Pošlete tedy výsledný soubor na sdílenou tiskárnu k vytisknutí. Bohužel Vás však předběhne kolega, který tiskne mnohastránkový materiál na interní použití. Jak nyní budete vysvětlovat netrpělivému zákazníkovi, že musí 10 minut počkat, než se tisková úloha Vašeho kolegy dokončí? Z výše uvedeného příkladu je vidět, že všechny IT prostředky fungují, tiskárna je v pořádku, aplikace pro vytváření smluv je také v pořádku, ale stejně je nakonec zákazník nespokojen. Aby se podobným situacím předcházelo, zavádí se do firemní politiky řízení IT služeb. Je tedy nutné provést vydefinování a popis služeb, kdo službu poskytuje a pro koho a další specifika. Tímto vším se právě zabývá obor správa služeb IT (IT Service Management, ITSM). Popis nejlepších praktik a návodů je publikován v sadě knižních publikací Information Technology Infrastructure Library (ITIL®). [1]

1.1 Správa služeb IT (ITSM) Je definována jako systém specifických organizačních schopností (klíčových kompetencí), které zákazníkovi přináší přidanou hodnotu ve formě služeb. Zdroje jsou pomocí nasazených funkcí a procesů transformovány na kvalitní služby. Výhody jsou tak převedeny, jak směrem k vlastnímu podnikání, tak i na stranu zákazníka. Základním bodem klíčových publikací ITIL® je myšlenka životního cyklu a zaměřuje pozornost na spojení obchodních cílů zákazníka s IT neustálým zdůrazňováním faktu, že IT musí napomáhat tvorbě hodnot. Na správu služeb je potřeba nahlížet jako na implementaci a správu kvality služeb IT, které splňují potřeby businessu. Správa služeb IT je vykonávána poskytovateli služeb IT za využití vhodné kombinace lidí, procesů a informačních technologií. [2]

3

SPRÁVA SLUŽEB IT

1.2 IT služba Prostředek poskytování hodnoty zákazníkovi prostřednictvím výstupů, kterých zákazník chce dosáhnout bez vlastnictví specifických nákladů a rizik. Termín „služba“ se někdy užívá jako synonymum pro klíčovou službu, službu IT nebo balíček služby. Služba IT je poskytovatelem služeb IT poskytována internímu nebo externímu zákazníkovi. Skládá se z kombinace informačních technologií, personálu a procesů. Služba IT orientovaná na zákazníka přímo podporuje podnikové procesy jednoho či více zákazníků a ve smlouvě o úrovni služeb (Service Level Agreement, SLA) by měly být definovány cíle úrovní služeb. Další služby IT, nazývané podpůrné služby, nejsou podnikáním přímo využívány, ale pro provoz služeb orientovaných na zákazníka jsou nezbytné. Klíčová služba poskytuje zákazníkovi relevantní výsledky ve formě žádaného zhodnocování. Toto je základní část poskytování služeb. Přitom v pozadí poskytují podporu další (většinou) technické služby IT (Supporting Services). Podpůrná práce je realizována pomocí služeb, které klíčovou službu rozšiřují či vůbec umožňují, tedy poskytují základní funkčnost. Za tuto základní funkčnost neplatí zákazníci přímo (např. za Domain Name System, DNS). Tyto náklady však mohou být poměrně rozděleny. [2]

1.3 Katalog služeb Databáze nebo strukturovaný dokument obsahující informace o všech službách IT v provozu včetně těch, které jsou připraveny na nasazení. Katalog služeb je součástí portfolia služeb a obsahuje informace o dvou typech služeb IT: o službách používaných přímo zákazníky, které jsou pro business viditelné; a o podpůrných službách, vyžadovaných poskytovatelem služeb pro dodávku služeb v kontaktu se zákazníkem. [3] Katalog služeb může v praxi vypadat, viz následující obrázek (Obrázek 1 - Katalog služeb v ALVAO Service Desk). Je možné si nadefinovat různé služby, které mají vlastní pravidla, procesy a oprávnění.

4

SPRÁVA SLUŽEB IT

Obrázek 1 - Katalog služeb v ALVAO Service Desk

1.4 Dohoda o úrovních služeb (Service Level Agreement, SLA) Dohoda mezi poskytovatelem služeb IT a zákazníkem. Dohoda o úrovních služeb popisuje službu IT, dokumentuje cíle úrovní služeb a specifikuje odpovědnosti poskytovatele služeb IT a zákazníka. Jedna dohoda o úrovni služeb může pokrývat řadu služeb IT nebo více zákazníků. [3]

5

SPRÁVA SLUŽEB IT

1.5 Proces Strukturovaná množina činností navržená pro dosažení určitého specifického cíle. Proces má jeden či více definovaných vstupů a přetváří je do definovaných výstupů. Může obsahovat jakékoli role, odpovědnosti, nástroje a manažerské kontrolní mechanismy požadované pro spolehlivou dodávku výstupů. Proces může v případě potřeby definovat politiky, normy / standardy, směrnice, činnosti a pracovní instrukce. [3] Skládá se z množství prostředků a činností. K prostředkům může patřit personál, finanční zdroje, zařízení, instalace, techniky a metody. Prostředky a činnosti jsou ve vzájemném vztahu. Proces vyžaduje vstupy a bývá spuštěn konkrétními vnějšími aktivitami. Proces má výstupy, což představuje přidanou hodnotu. Proces představuje model jednání pro neustále se opakující činnosti.

Obrázek 2 - Zobrazení procesu [2]

6

SPRÁVA SLUŽEB IT

1.6 Poskytovatelé služeb Je potřeba rozlišovat mezi různými typy poskytovatelů služeb. Většina aspektů správy služeb sice platí pro všechny typy, nicméně u každého typu poskytovatele je na otázky týkající se trhů, smluv, hospodářské soutěže, zisku a strategie kladen odlišný důraz. Poskytovatel služby může existovat v různých formách vztahu ke svému zákazníkovi. Obecně platí, že poskytovatel služby IT může mít jak interní, tak externí zákazníky: ■

Interní poskytovatel služeb (Internal Service Provider): Je takový poskytovatel služeb IT, který je součástí té samé organizace, jako jeho zákazník. Růst poskytovatele služeb je omezen na odvětví, pro které interní poskytovatel služeb pracuje.

■

Sdílený poskytovatel služeb (Shared Service Provider): Je interní poskytovatel služeb, který centrálně zajišťuje služby IT pro více než jednu část organizace. Úkoly, funkce nebo činnosti, které byly doposud ve stejné nebo podobné formě prováděny na více místech organizace, jsou od nynějška sdruženy do jednoho centrálního místa. Aby dostaly odpovídající službu, mohou se na toto místo jednotlivá odvětví, obchodní jednotky nebo oddělení obracet dle potřeby.

■

Externí poskytovatel služby (External Service Provider): Jedná se o poskytovatele služeb IT, který náleží k jiné organizaci než zákazník. Zákazníci mohou pocházet z rozdílných míst i firem. Externí poskytovatelé služeb si navzájem konkurují, jsou flexibilní a také používají různé cenové strategie. [2]

7

2 Information Technology Infrastructure Library (ITIL®) Knihovna infrastruktury IT, světově známá pod zkratkou ITIL®, je veřejně dostupným souborem ověřených nejlepších praktik v oblasti správy a řízení IT v organizacích. Pojednává komplexně o službách a zaměřuje se na neustálé měření a zlepšování kvality dodávaných služeb, a to jak z pohledu zákazníka, tak i byznysu. Toto všestranné zaměření je hlavním důvodem celosvětového úspěchu ITIL®. Všestrannost také přispěla k rozšířenému využití ITIL® v mnoha organizacích, které aplikovaly tyto techniky a procesy ve svých organizačních strukturách. Pohled byznysu: ITIL® je lehce upravitelný rámec nejlepších zkušeností z praxe, s pomocí kterého byznys organizace dosáhne požadovanou kvalitu IT služeb a překoná překážky, související s rozvojem svých IT systémů. Pohled IT: ITIL® je fyzicky sada knižních publikací, která obsahuje sbírku nejlepších zkušeností z oboru řízení služeb informačních technologií. Tyto publikace jsou ve vlastnictví britské společnosti AXELOS Ltd., která kromě ITIL® spravuje ještě šest dalších celosvětově používaných manažerských rámců a metodik, z nichž v ČR nejznámější je metodika řízení projektů PRINCE2®. [1] ITIL® není předpis (není to norma / standard) V ITIL® je jen velmi málo imperativů, většinou se jedná o doporučení. Základní pravidlo práce s ITIL®: Přijmi a přizpůsob (adopt and adapt). ITIL® je zdravý rozum (common sense) a nejlepší zkušenost z praxe (best practice) Pokud něco dnes nedělám v souladu s ITIL®, nemusí to být špatně. ITIL® zákonitě reaguje se zpožděním = to, co je dnes běžná praxe se zítra (možná) dostane do publikací ITIL®. ITIL® je rámec ITSM, nikoliv metodika ITIL® neřeší žádný velký detail, dává jen obecné návody, nikoliv podrobné popisy toho, jak reagovat na každou specifickou situaci, resp. řešit podporu služeb ve specifických podmínkách.

8

INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY (ITIL®)

2.1 Proč je ITIL® úspěšný? Postupy pro správu služeb jsou použitelné v každé IT organizaci. Nezávislost na konkrétní technologické platformě. ITIL® nabízí robustní, zralé a léty prověřené postupy. Použitelný ve veřejném i soukromém sektoru, pro malé, střední i velké podniky. Osvědčené

postupy

ITIL®

jsou

vyzkoušeny

u

nejlepších

světových

poskytovatelů služeb. ITIL® popisuje praktiky, které organizacím umožní návratnost investic a trvalý úspěch.

2.2 Přínosy ITIL® pro organizace Zvýšení spokojenosti s poskytovanými službami jak ze strany uživatelů, tak ze strany zákazníků. Zvýšení dostupnosti a spolehlivosti poskytovaných služeb. Finanční úspory vyplívající z eliminace zbytečné práce. Omezení nákladů na realizaci změn v business procesech. Zvýšení produktivity a lepší využívání existujících znalostí. Zlepšení komunikace mezi zákazníkem a poskytovatel služeb a další.

2.3 Struktura životního cyklu služby Jádro ITIL® se skládá z pěti publikací popisujících vždy určitou část životního cyklu služby. Každá část obsahuje pokyny potřebné pro integrovaný přístup podle požadavků normy ISO/IEC 20000 standardní specifikace. Základním principem je řízení životního cyklu služby a dodání hodnoty pro zákazníka. ITIL® doporučení lze upravit pro podporu různých podnikatelských prostředí a organizačních strategií. Doplňkové ITIL® publikace poskytují flexibilitu při nastavování a provádění v nejrůznějších prostředích. Všechna doporučení mají za cíl zvýšit trvanlivost a přenosnost znalostních aktiv a chránit investice vložené do schopnosti řídit služby IT.

9


Obrázek 3 - Životní cyklus služby podle ITIL®

2.3.1

Strategie služby (Service Strategy)

Procesy strategie služeb se starají o manažerské řízení správy služeb. Zajišťují solidní strategický a finanční základ pro poskytování služeb a dále po všechny fáze životního cyklu zajišťují orientaci na celkovou strategii. Strategie poskytovatele služeb se přitom zaměřuje v závislosti na typu poskytovatele služeb na strategii interního nebo externího zákazníka. Organizace by měly používat Strategii pro služby IT pro stanovení cílů a uspokojování potřeb zákazníků. Účelem strategie je identifikovat, vybrat a upřednostnit příležitosti na trhu při poskytování IT služeb. Dále musí zajistit připravenost organizací vypořádat se s náklady a riziky spojenými s portfoliem jejich služeb. ITIL® Service strategy vybízí organizace poskytující služby IT, aby si promyslely, co je třeba udělat, než přemýšlet o tom, jak to udělat. [2]

10


2.3.2

Návrh služby (Service Design)

Účelem této části životního cyklu je návrh a tvorba hodnotných služeb v souladu se strategií služeb. Návrh služby tvoří společně s přechodem služby a provozem služeb vnitřní životní cyklus služby. Již během návrhu služby jsou zohledněny a implementují se zlepšovací aspekty a mechanismy pro použití ve fázi přechodu a v pozdějším provozu. Mezi neustálým zlepšováním služeb (Continual service improvement, CSI) a návrhem služby proto existuje zvláště úzké propojení. Návrh služby má zajistit, aby byla zachována funkční a kvalitní konzistence a integrita všech aktivit a procesů v rámci technologie IT a obchodních procesů. Již během fáze návrhu služby je tematicky zpracováno vytvoření metrik a měřicích metod jako vstupu procesu neustálého zlepšování. Pro zákazníky je výsledná hodnota tvořena pomocí vysoce kvalitních, efektivních a na obchod orientovaných služeb. Účinné poskytování služeb je vždy spojeno s plánováním kapacit, financí, dostupnosti a kontinuity. [2] Přijetí a provádění návrhu služeb podle standardních přístupů zahrnuje: Snížení celkových nákladů na vlastnictví (Total cost of ownership, TCO). TCO lze minimalizovat v případě, že všechny aspekty procesů, služeb a technologií jsou navrženy a realizovány v souladu s návrhem. Zlepšení kvality služeb, které jsou lépe navrženy a splňují požadavky zákazníka. Zlepšit soudržnost služeb v souladu s firemní strategií, dostupnou architekturou a omezeními. Zavádění nových nebo změněných služeb vytvořením komplexních balíčků služeb. [4]

11


2.3.3

Přechod služby (Service Transition)

Třetí kniha ITIL®, tj. fáze následující po návrhu služby, se zaměřuje na téma přechodu služby. Tematicky shrnuje přechod koncipované služby do provozu. Společně s návrhem služby a provozem služby tvoří přechod služby vnitřní životní cyklus služby, který se točí okolo jádra strategie služeb a je obklopen, potažmo protkán neustálým zlepšováním služeb (CSI). Přechod služby jako fáze životního cyklu služby přejímá zodpovědnost za převedení strategie služby, obsažené v balíčku návrhu služby (Service design package, SDP), z teorie do praxe, tj. řízené a organizovaně převést službu IT se všemi jejími částmi do provozu. Balíček návrhu služby obsahuje například: Definici služby a strukturu služby. Finanční modely a přístupy, modely kapacit a zdrojů. Specifikace návrhu a rozhraní, návrh releasu. Plán nasazení, kritéria přijatelnosti, žádosti o změnu. [2] Cílem životního cyklu přechod služby je: Plánování a řízení změn služeb hospodárně a efektivně. Řídit rizika na nových, měněných a vyřazovaných službách. Zajistit úspěšné nasazení služby do prostředí, které je podporováno. Nastavit správné očekávání zákazníků na výkonnost a využívání nových nebo změněných služeb. Ujistit se, že nové nebo změněné služby vytváření očekávaný přínos pro business. Poskytovat kvalitní znalosti o nových a měněných službách a aktivech. [5]

2.3.4

Provoz služby (Service Operation)

Čtvrtá kniha ITIL® Edice 2011 se věnuje fázi následující po přechodu služby, tématu provozu služeb. Procesy a funkce, které sem spadají, se věnují oblasti organizace IT, která má za cíl zvyšování účinnosti a efektivnosti při poskytování služeb. Stabilita služeb IT by měla být zajištěna za všech okolností. Společně s návrhem služby a přechodem služby tvoří provoz služeb vnitřní část životního cyklu služby. Provoz služeb popisuje část životního cyklu služby, kterou zákazník poskytovatele služeb vnímá jako primární. Skutečná hodnota služby se realizuje a je pro zákazníka viditelná. Vyžaduje správnou kontrolu a řízení, sledování výkonu, hodnocení metrik a shromažďování provozních údajů.

Cílem provozu služeb je:

12


Udržet spokojenost zákazníka a jeho důvěru v IT, prostřednictvím účinné a efektivní dodávky a podpory IT služeb. Minimalizovat dopad výpadků služeb. Ujistit se, že přístupy k dohodnutým IT službám jsou poskytovány pouze autorizovaným osobám. Provoz služeb se netýká pouze správy služeb a infrastruktury. Stejně jak je potřeba nalézt v rámci životního cyklu rovnováhu mezi jednotlivými fázemi, je potřeba ji najít i mezi různými dynamickými faktory v rámci provozu. Existují čtyři základní aspekty, které musí být vyvážené: Interní versus externí pohled: Externí obchodní pohled je způsob, jakým vnímají služby zákazníci a uživatelé. Interní pohled IT se zaměřuje na to, jakým způsobem jsou provozovány komponenty a systémy. Je důležité najít rovnováhu, která umožňuje jak kontinuitu a spolehlivost, tak i orientaci na zákazníka. Stabilita versus flexibilita: Když organizace IT sleduje např. nové technologie, filozofie a přístupy, zůstává otevřená aktuálnímu vývoji. Navíc musí proaktivně podporovat integraci správy úrovně služeb a dalších procesů, zavčas provádět změny a udržovat dobrou kulturu komunikace. Takto je možné dosáhnout vyváženosti mezi stabilitou a flexibilitou. Kvalita služby versus náklady: Priority v rámci poskytování služeb se určují podle dohodnutých úrovní služeb. Přitom aby bylo možné službu poskytovat účinně a efektivně, je potřeba optimálně využívat zdroje. Reaktivní versus proaktivní správa služeb: Rovnováhu mezi oběma aspekty vykazuje organizace IT, která je na jedné straně schopná provádět proaktivní vylepšení, na druhé zvládá reagovat na poruchy a chyby a nezanedbává je. [2]

13


Obrázek 4 - Balanční model

Klíčové funkce Service Desk: Poskytuje primární centrální bod kontaktu pro všechny uživatele IT. Service Desk obvykle zaznamenává a spravuje všechny incidenty, servisní požadavky a požadavky na přístupy a je rozhraním pro všechny ostatní procesy a činnosti Provozu služeb. Technická správa: Zahrnuje veškerý personál poskytující technickou odbornost a správu infrastruktury IT. Správa aplikací: Zahrnuje veškerý personál poskytující technickou odbornost a správu aplikací. Má tedy velmi podobnou roli jako Technická správa, avšak tato role je zaměřená na softwarové aplikace. Správa provozu IT: Odpovídá za správu a údržbu infrastruktury IT potřebné pro dodávání dohodnutých úrovních služeb IT businessu.

14


2.3.5

Neustálé zlepšování služby (Continual Service Improvement. CSI)

Této části se budu věnovat nejpodrobněji, jelikož poznatky z této 5. knihy ITIL® jsem nejvíce využil při praktické části této práce. CSI Je zodpovědné za průběžné přizpůsobování služeb IT měnícím se obchodním požadavkům a za odhalování optimalizačního potenciálu pomocí identifikace a provádění zlepšení služeb IT během celého životního cyklu. Zlepšování služeb se zaměřuje na nárůst efektivnosti, maximalizaci účinnosti a optimalizaci nákladů na služby a na za tím stojící správu služeb IT (ITSM). Během celého životního cyklu přitom nedochází pouze k optimalizaci kvality služeb, ale i ke zvyšování stupně zralosti poskytovatele služeb. Důležitý faktor pro identifikaci příležitostí ke zlepšení je měření aktuálního výkonu služeb. Není možné řídit to, co není možné ovládat. Není možné kontrolovat to, co není možné měřit. Není možné měřit to, co není možné definovat. Důvod proč měřit aktuální výkon služeb jsou možné vyšší náklady organizace, ztráta dobré pověsti, případně i riziko neúspěchu v podnikání, což může vést ke ztrátě zákazníků. CSI není novou koncepcí, avšak v mnoha organizacích stále nepokročilo z diskuzní fáze. CSI se stává projektem u mnoha organizací až tehdy, když něco selhalo a významně ovlivnilo business. Poté, co je tento incident vyřešen, zůstane koncepce zapomenuta až do výskytu další velké poruchy. Separátní projekty s pevnými časovými milníky jsou stále požadovány, avšak aby bylo CSI úspěšné, musí být součástí kultury organizace a stát se rutinní činností. Model CSI viz Obrázek 5- Model neustálého zlepšování služeb ukazuje organizační cestu, jak mohou být identifikovány a řízeny odpovídající zlepšování prostřednictvím srovnání jejich současné pozice a hodnot, které jsou poskytovány businessu, s dlouhodobými cíli a zjištěním všech rozporů, které existují. To se uskutečňuje kontinuálně, aby byly zachyceny změny v požadavcích businessu a v technologii a aby byla udržena vysoká kvalita. [6]

15


Obrázek 5- Model neustálého zlepšování služeb [6]

Stanovení vize podporující obchodní cíle (sladění obchodu / IT). Zhodnocení aktuální situace pro zjištění přesného a objektivního současného stavu. Pochopení a dohoda priorit zlepšování, odvozených z dříve stanovené vize. Zatímco velké vize podniku mohou být ještě léta vzdálené, dává tento krok konkrétní cíle na konkrétní časový úsek. Vytvoření podrobností plánu CSI pro poskytování kvalitnějších služeb díky implementaci nebo zlepšení procesů správy služeb IT. Ověření dostupnosti měřicích metod a metrik, které mají zjišťovat dosažení stanovených cílů, míru shody procesů a umožnění a podporu dosažení obchodních cílů a priorit pomocí dohodnutých úrovní služeb. Nakonec je potřeba pomocí začlenění změn do organizace zajistit zachování elánu pro zlepšování kvality a ustálení dosud dosaženého.

16


Demingův cyklus (Plan-Do-Check-Act) Používá se k podpoře zlepšovacího přístupu a jeho provádění. Každý úspěšný krok týkající se zlepšení kvality souladu IT a businessu je důležité následně pevně zakotvit. Explicitní ověřovací krok (Check) zároveň umožňuje flexibilitu a zajištění optimálního sladění procesů a služeb s obchodními cíli. Demingův cyklus je iterativní, viz (Obrázek 6 - Demingův cyklus ve správě služeb IT ). Úvodním krokem cyklu je plánování, během kterého se kontroluje potenciál ke zlepšení aktuálního stavu (v praxi bývá často proveden jistý druh „odhadu“, nebo explicitní počáteční nastavení) a vytváří plán zlepšení kvality. Při analýze slabých míst a potenciálu ke zlepšení často vyjdou najevo konkrétní opatření ke zlepšením sledovaných procesů a služeb. Tato opatření se následně realizují ve fázi „Do“. Poté co jsou opatření provedena, je potřeba zkontrolovat, zda změny proběhly v pořádku (Check). S ohledem na dříve definované cíle se kontroluje, zda vzniká očekávaný užitek nebo, zda vznikly vedlejší efekty a jak je vyhodnotit. Ve čtvrtém kroku (Act) se pro dosažení dříve definovaného cíle realizují opatření ke korekci zjištěných odchylek, změny plánů nebo zlepšení systému správy kvality. Pokud se „kolo kvality“ neustále otáčí, dojde časem ke zlepšení dle definovaného záměru. [2]

Obrázek 6 - Demingův cyklus ve správě služeb IT

[7]

17


Zlepšovací proces v 7 krocích Zahrnuje kroky požadované pro sběr smysluplných dat, analýzu těchto dat kvůli identifikaci trendů a problémů, prezentaci informací managementu za účelem nastavení priorit a schválení a nasazení zlepšení. Každý krok viz (Obrázek 7 - Zlepšovací proces v 7 krocích) je podněcován strategickými, taktickými a provozními cíli definovanými ve Strategii a v Návrhu služeb.

Obrázek 7 - Zlepšovací proces v 7 krocích

Krok 1 - Definice toho, co by se mělo měřit Návrh množiny měření, která plně podporuje cíle organizace a zaměřuje se na identifikaci toho, co je třeba pro plné uspokojení cílů udělat, aniž se uvažuje, zda jsou tato data aktuálně dostupná. Krok 2 - Definice toho, co je možné měřit Organizace mohou objevit existující omezení, které lze aktuálně měřit, avšak je důležité brát na vědomí, že takovéto mezery existují a jaká rizika s tím mohou být spojena. V tomto případě je na místě vytvořit diferenční analýzu mezi tím, co je anebo může být měřeno a tím, co je ideálně požadováno. Report výchozích rozdílů a jejich důsledků předložit businessu, zákazníkům a managementu IT.

18


Krok 3 - Shromáždění dat V tomto kroku dochází k monitorování a sběru dat. Měla by se zavádět kombinace monitorovaných nástrojů a ručních procesů pro sběr dat potřebných pro definovaná měření. Kvalita je klíčovým cílem monitorování pro CSI. Monitorování se zaměřuje na efektivitu služby, procesu, nástroje nebo organizace. Důraz je kladen na zjištění, kde by se dala provést zlepšení stávající úrovně služby nebo výkonu IT a provádí se detekcí výjimek a řešení. CSI se nezajímá jen o výjimky. Kontroluje se také plnění dohodnuté úrovně služby, a jestli se tato úroveň nedá udržet při nižších nákladech nebo zda při stávajících nákladech nelze povýšit (zkrácení reakčních dob, dob do vyřešení, zvýšení dostupnosti služby). Krok 4 - Zpracování dat Nashromážděná data se zpracují do požadovaného formátu s ohledem na výkonnost služeb a procesů od začátku až do konce (end-to-end). Tento krok je důležitou činností CSI, ale bývá často přehlížen. Zatímco monitorování a sběr dat u jedné komponenty infrastruktury jsou důležité, klíčem k úspěchu je především porozumění dopadu této komponenty na rozsáhlejší infrastrukturu a službu IT.

Krok 5 - Analýza dat Analýza transformuje informace do znalostí o událostech, které na organizaci dopadají. Výsledky zpracované do informací lze analyzovat a odpovědět na otázky: Dosahujeme cílů? Jsou tu nějaké jasné trendy? Jsou nutné nápravné akce? Jaké jsou náklady?

19


Krok 6 - Prezentace a využití informací V tomto kroku se prezentují získané znalosti v takové podobě, aby jim šlo snadno rozumět a umožnilo příjemcům učinit strategická, taktická a provozní rozhodnutí. Cílová skupina musí obdržet tyto informace na správné úrovni a správným způsobem. Tyto informace by měly poskytnout hodnotu užitku, registrovat výjimky služby a identifikovat veškeré přínosy, které byly identifikovány během určitého období. IT musí dnes víc než kdy jindy investovat čas pro porozumění specifickým cílům businessu a přeložit metriky IT tak, aby reflektovali dopady vůči těmto cílům businessu. Často je tu rozdíl mezí tím, co IT vykazuje, a tím, co je zájmem businessu. Většina výkazů se soustředí na oblasti se špatnou výkonností, ale měly by být sdělovány také dobré zprávy. Výkaz ukazující zlepšující se trendy je nejlepším marketingovým prostředkem služeb IT.

Krok 7 - Implementace nápravných akcí Získané znalosti jsou využity k optimalizaci, zlepšení a nápravě služeb, procesů a všech dalších podpůrných činností a technologií. Požadované nápravné akce, které vedou ke zlepšení služby, je nutné identifikovat a komunikovat je v organizaci. CSI bude identifikovat mnohé příležitosti pro zlepšení, naproti tomu organizace určuje priority založené na vlastních cílech, rovněž tak dostupné zdroje a financování. [6] Měření služeb Aby bylo vůbec možné dosáhnout spolehlivých měření, je pro potřeby pozdějšího srovnání, nastavit indikátory nebo výchozí hodnoty (Baselines). Výchozí hodnoty se používají i k určení počátečních hodnot. Aby bylo možné zjistit, zdaje potřeba zlepšit proces nebo službu („zlepšila se doba odezvy služby?“), porovnávají se později s aktuálním stavem. Pokud nebyly stanoveny počáteční hodnoty, slouží jako výchozí hodnoty čas a výsledky prvního měření. Důvody měření jsou: Aby bylo možné něco prohlásit za platné a správné (validovat): např. rozhodnutí mohou být validována pomocí monitorování a kontroly. Nasměrování (direct): např. lze díky monitorování a kontrole nasměrovat aktivity k dosažení určitých cílů. Ospravedlnění (justify): např. lze díky faktům zjištěným z monitorování a kontroly dokázat, že je nutný konkrétní postup. Aby bylo možné zasáhnout (intervene): např. lze díky monitorování a kontrole identifikovat místo k zásahu včetně následných změn a korekčních aktivit.

20


Tyto čtyři zásadní důvody měření služeb a procesů vedou ke třem rozhodujícím otázkám: Proč něco měříme a kontrolujeme? Kdy s tím skončíme? Využije někdo data z měření? Až příliš často nejsou měření a kontrola účinné a efektivní. Možná probíhají měření, která již nikdo nevyužívá, nebo jsou příliš nákladná. Plýtvání zdroji a výkonem přitom není neobvyklé. [2] Metody a techniky Pro měření aktivit v CSI je k dispozici široký výběr metod a technik, od „měkkých a vágních“ až po „vědecké a založené na faktech“. Pro výsledky měření je často používána směs výše uvedených. Mezi tyto metody můžeme zařadit posuzování, benchmarking, měření služeb, metriky, návratnost investic, vykazování služeb.

Posuzování Tato

metoda

je

založena

na

porovnávání

aktuálního

procesního

prostředí

s výkonnostními standardy (např. normami). Hlavním účel tohoto mechanismu je měření zlepšených schopností procesů nebo k nalezení případných nedostatků, které je potřeba vyřešit. Výhodou této metody je to, že lze vybrat pouze část procesů a otestovat pouze je.

Benchmarking (benchmark = srovnávací hodnota) Tato metoda měření je v praxi několikanásobně ověřená. Jsou zde porovnávány relevantní aspekty s jejich benchmarky, které by měly být nastaveny na vysokou výkonnost. Stav objektu zaznamenaný v určitém čase lze chápat jako benchmark. Ten lze vytvořit pro konfiguraci, proces nebo libovolný soubor dat. Benchmarking podporuje hledání řešení, založených na nejlepších praktikách a výchozích stavech a měl by vést podnik ke špičkovým výkonům, přičemž jde o hledání a využití potenciálů úspěchu.

21


Metriky Nezbytným základem pro měření v organizaci jsou metriky. Metriky jsou systémy ukazatelů nebo postup k měření kvantifikovatelné veličiny. Pomocí metrik lze měřit výsledky konkrétního procesu nebo aktivity. Při vytváření metriky je potřeba dbát na to, aby sledovala odpovídající cíle procesu. Existuji tři typy metrik, které má organizace sbírat pro podporu činnosti CSI i dalších procesů [2]

Technologické metriky: často spojovány s metrikami založenými na komponentách a aplikacích, jako je výkonnost a dostupnost Procesní metriky: získávány ve formě kritických faktorů úspěchu (CSF), klíčových ukazatelů výkonnosti (KPI) a metrik o činnostech Metriky služby: výsledky služby z pohledu koncového uživatele (end-to-end). Metriky komponent/technologie jsou užívány pro výpočet metrik služeb. [6] Rozhodující faktory úspěchu (Critical success factors, CSF) a klíčové ukazatele výkonnosti (KPI, Key performance indicator) - Úspěch projektu, procesu nebo služby IT závisí na různých faktorech. Rozhodující faktor úspěchu definuje vstupní veličinu, která je absolutně nezbytná pro úspěšný proces nebo službu IT. K měření dosažení nebo přítomnosti CSF se používají ukazatele výkonnosti. Aby bylo možné objektivně prokázat zlepšení, je potřeba definovat příslušné ukazatele výkonnosti procesů a služeb s relevantními veličinami a zobrazit je pomocí měření. CSF lze ve vztahu k „ochraně služeb IT při provádění změn“ měřit pomocí ukazatelů jako jsou „počet neúspěšných změn“ a „podíl změn, které způsobily incident“ atd. Pro každý CSF by měl existovat alespoň jeden ukazatel výkonnosti. Na počátku zlepšovacího přístupu lze vystačit se dvěma až třemi ukazateli výkonnosti. Počet a výběr ukazatelů výkonnosti by se měl pravidelně kontrolovat a v případě potřeby upravit. Zda jsou používány vhodné ukazatele výkonnosti, vyplývá například z následujících otázek: Dosáhneme svých cílů, pokud splníme ukazatele výkonnosti? Je možné správně interpretovat ukazatele výkonnosti? Kdo tyto informace potřebuje? Kdy a jak často? Kdo sbírá a analyzuje měření? Kdo je zodpovědný za zlepšení vzešlá z těchto informací?

22


Obecně lze rozlišit kvantitativní a kvalitativní ukazatele výkonnosti. Rozdíl spočívá v měřitelnosti ukazatelů, přičemž kvantitativní cíle lze vyjádřit přímo číselnými hodnotami, přímo měřit a tím pádem i snadněji optimalizovat. Kvalitativní cíle nelze přímo kvantifikovat. Například spokojenost zákazníků představuje kvalitativní cíl, přičemž její měřitelnost se v takovém případě často odvozuje od dílčích cílů. [2] Návratnost investic Otázkou návratnosti investic do CSI se zabývá každá společnost, která tento model chce využívat. V tomto případě proti sobě stojí výdaje, které společnost musí vynaložit, aby zlepšil kvalitu dodávaných služeb. Na druhé straně stojí to, čeho organizace díky těmto investicím získá. Většinou je velice těžké dopředu odhadnout, jaký bude výsledek těchto investic, jestli se vyplatí vkládat jakékoliv úsilí do CSI s ohledem na následující zisk. Je tedy důležité znát jaký je aktuální stav, jaké náklady vznikají dne (např. způsobené pravidelnými výpadky) a ty porovnat s náklady na jejich odstranění. Pro provedení zlepšovacích aktivit je velmi důležité průběžně měřit skutečný užitek těchto investic. Lze tak zjistit, jestli zlepšovací kroky vedly k očekávanému užitku. Lze si položit např. následující otázky: Byla předpokládaná zlepšení realizována? Bylo pomocí zlepšení dosaženo očekávaného užitku? Uběhl dostatek času, aby bylo možné provádět měření přínosu? Vykazování služeb Tato metoda je založena na sbírání a monitorování významného množství dat při denních dodávkách kvalitních služeb businessu, avšak jen malá část z toho je pro business opravdu zajímavá a důležitá. Business s oblibou nahlíží na historickou reprezentaci výkonů minulého období, zobrazující jeho zkušenost, avšak více jej zajímají ty historické události, které se mohou vyvinout do hrozeb a co IT plánuje udělat pro zmírnění těchto hrozeb. Nestačí prezentovat výkazy popisující soulad s dohodou o úrovních služeb (Service level agreement, SLA) či další detaily. IT musí vybudovat akční přístup k vykazování, tj. co se stalo, co udělalo IT, jak IT zajistí, že se to nebude opakovat znovu, a jak IT pracuje na celkovém zlepšení dodávky služeb. Způsob vykazování zaměřující se jak na budoucnost, tak i na minulost poskytuje IT prostředek, který slouží marketingu v nabídkách svázaných s pozitivní nebo negativní zkušeností businessu.

23

3 Analýza stávajícího prostředí organizace V této kapitole bych se chtěl věnovat analýze prostředí organizace ALVAO s.r.o. před implementací proaktivního přístupu poskytování služeb svým zákazníkům. Pozornost bude především zaměřena na tým a procesy, které souvisí s poskytováním služby technické podpory svým zákazníkům.

3.1 ALVAO s. r. o. Společnost ALVAO s.r.o. se od počátku své třináctileté existence zaměřuje na optimalizaci metodik a vývoj softwarových nástrojů na podporu servisních procesů. Stěžejní produkty společnosti tvoří informační systémy pro řízení zdrojů a služeb hlavně v odděleních správy informačních a komunikačních technologií ICT: ALVAO Asset Management, ALVAO Service Desk a ALVAO Monitoring. ALVAO je Microsoft Certified Partner a při vývoji svých produktů ALVAO se strategicky orientuje na platformu společnosti Microsoft®. Své produkty vyvíjí v souladu s jejími technologickými a bezpečnostními standardy. ALVAO s. r. o. má dvě pobočky, ve kterých je zaměstnáno zhruba 30 zaměstnanců. V brněnské pobočce je soustředěn vývoj systémů, zaměstnanci ve žďárské pobočce se zaměřují především na poskytování služeb zákazníkům. Autor diplomové práce je v organizaci zaměstnán šestnáct měsíců, kdy nejprve působil ve firmě formou zkráceného pracovního úvazku na pozici operátora technické podpory. Po uplynutí šesti měsíců nastoupil na pozici specialista technické podpory, na které působí dodnes. Během této doby se seznámil se všemi procesy, které jsou ve společnosti používány a se službami, které organizace poskytuje svým zákazníkům. Především služba technické podpory se později stala předmětem zlepšování, které bylo hlavním cílem této práce.

3.2 Technická podpora (TP) Poskytování služby technické podpory zákazníkům je jedním z hlavních zaměření oddělení služeb v rámci organizace. Jakmile je dokončena implementace některého z nabízených systému do organizace zákazníka a je zákazníkem akceptována, tak jsou veškeré jeho dotazy směrovány právě na oddělení technické podpory. Mezi komunikační kanály především patří e-mail, telefon nebo použitím helpdeskového portálu. Jaký komunikační kanál využívali zákazníci pro podání nového požadavku na službu technické podpory je vidět na následujícím grafu (Obrázek 8 - Způsob podání požadavku na službu technické podpory společnosti ALVAO s. r. o. v roce 2013).

24

ANALÝZA STÁVAJÍCÍHO PROSTŘEDÍ ORGANIZACE

osobní jednání 0,32%

telefon 5,38%

dopis 0,16%

ostatní 2,14% e-mail formulář

formulář 30,09%

ostatní osobní jednání telefon e-mail 61,92%

dopis

Obrázek 8 - Způsob podání požadavku na službu technické podpory společnosti ALVAO s. r. o. v roce 2013

3.2.1

Tým

Oddělení technické podpory čítá dohromady 5 lidí. Jedna osoba pracuje jako operátor této služby, což v době psaní této práce vykonával autor. Jeho hlavním úkolem je provést správnou kategorizaci příchozích požadavků a poté provedení první reakce směrem k zákazníkovi, vykonává tzv. L1 support. Operátor by měl být schopný vyhledat řešení problému v rámci již vyřešených požadavků či provést nasměrování na správné řešení pomocí báze znalostí nebo svých vlastních zkušeností s používáním vyvíjených nástrojů. Pokud není schopen problém vyřešit sám, obrací se na L2 support, který v případě společnosti ALVAO s. r. o. vykonávají tři zaměstnanci na pozici produktový specialista či konzultant. Tyto osoby provádějí implementace systémů u zákazníků, tudíž mají praktické zkušenosti s nasazováním aplikací a znají i IT infrastrukturu v jejich organizacích. Všechny tyto čtyři osoby jsou podřízenými řediteli služeb, který vystupuje v roli manažera služby technické podpory. Na tuto osobu jsou eskalovány např. upozornění o nedodržení stanovených SLA vůči zákazníkovi či rozhodování o zlepšovacích návrzích, které vzniknou v rámci služby technické podpory. Do služby technické podpory zasahuje i vývojový tým, který poskytuje L3 support. Organizačně však spadá do vývojového oddělení, ale velkou měrou se také podílí na správném chodu služby technické podpory. Jednotlivé role v rámci společnosti ALVAO s. r. o. jsou zobrazeny organigramu (Obrázek 9 - Organigram společnosti ALVAO s. r. o. - služby + vývoj).

25


ALVAO Oddělení služeb

Oddělení vývoje

Ředitel služeb

Ředitel vývoje

Konzultanti (L2)

Vývojáři (L3)

Technická podpora(L1) Obrázek 9 - Organigram společnosti ALVAO s. r. o. - služby + vývoj

Pro lepší představu, jak se jednotlivé úrovně podpory zapojují do řešení požadavků ve službě technické podpory, byl vytvořen obrázek (Obrázek 10 - Přehled vykázaných hodin v roce 2013 ve službě technické podpory dle jednotlivých úrovní), který zobrazuje zapojení jednotlivých úrovní do řešení servisních požadavků od zákazníků. Čím více se do řešení požadavků zapojují úrovně L2 a L3, tím se zvyšuje cena provozu služby technické podpory pro dodavatele. Primárním cílem je tedy co nejvíce omezit práci úrovně L3 v této službě, jelikož osoby pracující na této úrovni jsou pro dodavatele nejdražší a snahou je využít jejich kapacitu na vývoj produktů a testování a ne pro poskytování podpory zákazníkům. Na začátku roku vykázala úroveň L3 do služby technické podpory 60 hodin práce (milník 1), což bylo způsobeno nástupem nového zaměstnance na pozici operátora technické podpory. Postupně se podařilo tuto hodnotu snižovat. V prvním a druhém kvartálu byla tato hodnota zhruba 30 hodin měsíčně (milník 2), což bylo způsobeno vydáním opravného balíčku k produkční verzi. V červenci tato hodnota opět výrazně vzrostla (milník 3), tento výkyv byl způsoben nastoupení operátora technické podpory na úplný úvazek, tudíž i stoupla celková doba vykázaná na práce ve službě technické podpory. V dalších měsících se podařilo hodnotu zapojení úrovně L3 do řešení požadavků na technické podpoře ustálit na zhruba 15 hodin měsíčně, což je výrazný pokles oproti 60 hodinám v lednu.

26


250

milník 1

milník 2

milník 3

200 60,15 150

38,9

26,88

18,91 29,82

30,59

62,85

20,61

30,47 35,31

100 48,31 50

103,6

84,24 59,55

9,87

14,82 6,44

26,65 14,7 2,6

15,53 5,85

35,58

40,23

83,45

38,24

59,26

105,15 114,62 104,15

125

15,46 75,02

69,42

27,71 26,19

0

L1

L2

L3

Obrázek 10 - Přehled vykázaných hodin v roce 2013 ve službě technické podpory dle jednotlivých úrovní

3.2.2

Řešení požadavků

Jakmile je systém implementován u zákazníka a ten akceptuje předání, je mu nabídnuta služba technické podpory. Každý zákazník má právo žádat pomoc s případnými problémy spojenými s provozem dodaných systémů. Ve společnosti ALVAO s. r. o. jsou zákazníci rozděleni do 4 skupin dle poskytované úrovně technické podpory: Neplacená technická podpora B4: Zákazníci s touto úrovní TP mohou zasílat náměty na vývoj, nerozpoznané softwarové detekce pro aktualizaci knihovny softwarových produktů a dotazy na chyby v jejich produktu. Nejsou oprávněni aktualizovat si nové verze systému ALVAO ani aktualizovanou knihovnu softwarových vzorů (SwLib). Řešitelé požadavků odpovídají v negarantovaném termínu a začne-li se požadavek řešit později než žadatel žádá, nemohou požadovat sankce za neřešení.

27


Základní technická podpora B3: Zákazníci s touto úrovní TP mohou zasílat náměty na vývoj, nerozpoznané softwarové detekce pro aktualizaci knihovny softwarových produktů, dotazy na chyby v produktu a mohou zadávat požadavky nejen prostřednictvím e-mailové zprávy, ale také telefonicky s operátory TP. Mohou stahovat novou verzi systému z webu a poté si ji i nainstalovat, stahovat aktualizace knihovny softwarových vzorů. Stahování a instalaci aktualizací provádí sám odběratel služby. Služba je poskytována v rámci platby za „Maintenance“ nebo „Pronájem produktu“. Reakční doba do započetí řešení požadavku je stanovena 5 pracovních dní. V případě nedodržení reakční doby, nemůže žadatel požadovat sankce za neřešení. Garantovaná technická podpora B2, B1: Zahrnuje všechny předešlé úrovně technické podpory. Zákazník s touto speciální úrovní TP může dále vyžadovat technické konzultace o produktu, má přístup do systému Service Desk poskytovatele skrze webové rozhraní, přístup do Báze znalostí poskytovatele skrze webové rozhraní. Poskytovatel garantuje započetí řešení požadavku do 2 pracovních dnů, v případě nedodržení termínu započetí řešení připadá za každý zpožděný den neřešení sankce. Služba je poskytována v rámci „Maintenance“ nebo „Pronájem produktu“. Reakční doba a doba do vyřešení Reakční doba: Touto dobou se myslí čas od zadání požadavku na službu do první reakce od poskytovatele služby směrem k uživateli této služby. V systému ALVAO Service Desk to znamená první lidskou komunikaci směrem od řešitele/operátora služby směrem k žadateli dané služby. Tato komunikace může být vedena prostřednictvím e-mailové zprávy, telefonu nebo osobního jednání. Doba do vyřešení: V tomto případě se jedná o termín, do kdy by měl být servisní požadavek vyřešen. Ve společnosti ALVAO s. r. o. se na službě technické podpory tato doba negarantuje v žádné z výše uvedených skupin zákazníků. Doba do první reakce je jedna z hlavních složek při definici SLA. Tuto dobu společnost ALVAO s. r. o. garantuje svým zákazníkům, pokud si zaplatí jednu z výše uvedených úrovní technické podpory. Na následujícím grafu je znázorněn počet překročení této garantované doby v roce 2013 dle jednotlivých měsíců a poté i celkový počet

28


vytvořených

požadavků

na

službu.

Na

prvním

obrázku

120 100 80 60 40 20

111

97

26

23

14

0

73

67

63

49

32

13

14

74

58 12

17

60 8

1.12.2012 1.1.2013 1.2.2013 1.3.2013 1.4.2013 1.5.2013 1.6.2013 1.7.2013 1.8.2013 Počet překročení SLA

Počet požadavků

Obrázek 11 - Počet překročení první reakce v organizaci ALVAO s. r. o.). 120 100 80 60 40 20

111

97 49 23

26

14

73

67

63 13

32

14

74

58 12

17

60 8

0 1.12.2012 1.1.2013 1.2.2013 1.3.2013 1.4.2013 1.5.2013 1.6.2013 1.7.2013 1.8.2013 Počet překročení SLA

Počet požadavků

Obrázek 11 - Počet překročení první reakce v organizaci ALVAO s. r. o.

Jak již bylo uvedeno výše, tak společnost ALVAO s. r. o. negarantuje svým zákazníkům dobu do vyřešení jejich požadavků, tudíž není tato doba nikde hlídána a nepracuje se s ní. I přesto byla provedena analýza tohoto faktoru. Byly zkoumány pouze služby „Technická podpora/Pomoc s provozem“, „Technická podpora/Dotazy“ a „Technická podpora/Úpravy knihovny SW vzorů!. U všech třech služeb byla zjišťována průměrná doba řešení požadavků dle skupin zákazníků podle placené technické podpory. Výsledkem byl graf (Obrázek 12 - Průměrná doba řešení požadavků v jednotlivých službách dle skupiny žadatele), na kterém můžeme vidět, že průměrná doba řešení požadavků ve službě „Technická podpora/Pomoc s provozem“ se pohybuje bez ohledu na žadatele průměrně kolem 75,76 hodin. Ve službě „Technická podpora/Dotazy“ se tato

29


hodnota pohybuje kolem 49,7 hodin a v poslední službě „Technická podpora/Úpravy knihovny SW vzorů“ je to průměrně 60,22 hodin. 120

Bez rozdílu SLA

B1

B2

B3

B4

Průměrná doba řešení požadavku (hodiny)

100 96

80 60 40

83,03

75,66 53,73 43,8

49,7

55,43 34,36

20

60,22

56,96

35,91

0 Pomoc s provozem

Dotazy

Úpravy knihovny SW vzorů

Kategorie služby technické podpory

Obrázek 12 - Průměrná doba řešení požadavků v jednotlivých službách dle skupiny žadatele

Zákazník může kontaktovat technickou podporu telefonicky, e-mailem nebo přes helpdeskový portál. Informace poskytnuté jedním z těchto kanálů jsou uloženy do systému ALVAO Service Desk. Více o tomto nástroji v sekci

30


ALVAO Service Desk. Jakmile je přijata zpráva od žadatele na službu technické podpory, vzniká požadavek, který má za úkol operátor technické podpory správně kategorizovat. Jednotlivé kategorie se liší procesem, kterým se daný požadavek ve službě dále řídí. Na službě technické podpory se jedná o požadavky typu: Incident: Jedná se neplánovaný výpadek poskytované služby nebo některé její části, řízený procesem Incident Management. V našem případě se jedná většinou o špatnou konfiguraci systému způsobenou neznalostí zákazníka nebo výpadkem systémů dodavatelů třetích stran. Jako incident jsou také klasifikovány i chyby v samotném produktu. Hlavním cílem tohoto procesu je obnovit co nejrychleji normální provoz systému a to s důrazem na minimalizaci dopadu výpadku na uživatele. Jakmile je od více zákazníků hlášen identický požadavek, tak vzniká navázaný požadavek typu Problém, který se již řídí procesem Problem Management. Pokud není známo úplné řešení problému nebo incidentu je navrhnuto a poté nasazeno náhradní řešení (workaround), které omezí nebo úplně vyloučí jejich dopad. V systému ALVAO Service Desk se služby poskytovány zákazníkům společnosti ALVAO s. r. o. nazývá „Technická podpora/Pomoc s provozem“ a „Technická podpora/Chyby v produktu“. Požadavek na službu: Formální požadavek uživatele na něco, co má být poskytnuto. Požadavek na službu je tedy charakterizovaný jako úkon, který je třeba provést proto, aby uživatel mohl využívat službu IT tak, jak byla navrhnuta, avšak uživatel sám tento úkol provést nemůže nebo nesmí, přičemž vznik požadavku na službu je více méně zcela mimo vliv úseku podnikové informatiky. [1] Jedná se na např. o požadavek na informaci nebo radu, na obnovení hesla pro přístup na helpdeskový portál, nebo na zaslání instalačních balíčků systému. Tento typ požadavku je řízen procesem Request fulfilment. Služby poskytované zákazníkům společnosti ALVAO s. r. o. se v tomto případě nazývají „Technická podpora/Dotazy“ a „Technická podpora/Úpravy knihovny SW vzorů“.

31


Požadavek na změnu: Organizace ALVAO s.r.o. umožňuje všem zákazníkům posílat náměty na změny v systému, přičemž jim negarantuje realizaci těchto změn, pokud nejsou ochotni sponzorovat vývoj této změny. Společnost se snaží jít směrem krabicového řešení, jinak řečeno, aby systémy mohlo používat co největší množství zákazníků bez nutnosti programových úprav a dalších „customizací“. Pokud však nějakou změnu požaduje více zákazníků, je realizace daleko reálnější, protože přinese hodnotu více uživatelům. Tyto náměty mohou zákazníci zakládat jako požadavky do služby „Technická podpora/Zlepšovací návrhy“. V době tvorby této diplomové práce neexistovala žádná možnost monitoringu systémů, které jsou poskytovány zákazníkům, tudíž všechny problémy s nimi spojené musí zákazník hlásit sám. Během roku 2013 bylo ve službě technické podpory vytvořeno celkem 1221 požadavků, z toho nejvíce bylo požadavků typu incident (589), 462 tiketů bylo založeno do služby „Technická podpora/Pomoc s provozem“ a ve zbývajících 127 případech se jednalo o chyby v produktu. Po incidentech následovaly požadavky na službu (513). 369 požadavků bylo vytvořeno do služby „Úpravy knihovny SW vzorů“ a ve zbylých 144 požadavcích se řešily obecné dotazy k produktům. Poslední kategorií je služba „Technická podpora/Zlepšovací návrhy“, do které bylo založeno ze všech služeb nejméně požadavků a to přesně 119 za toto sledované období. Všechny tyto údaje jsou zobrazeny pro lepší přehlednost na grafu Pomoc s provozem

462

Chyby v produktu

144


369

Dotazy

127

Zlepšovací návrh

119 0

50

100

150

200

250

300

350

400

450

500

Obrázek 13 - Počet vytvořených požadavků do jednotlivých služeb TP ve společnosti ALVAO s. r. o.Obrázek 13 - Počet vytvořených požadavků do jednotlivých služeb TP ve společnosti ALVAO s. r. o.)

32


Pomoc s provozem

462

Chyby v produktu

144


369

Dotazy

127

Zlepšovací návrh

119 0

50

100

150

200

250

300

350

400

450

500

Obrázek 13 - Počet vytvořených požadavků do jednotlivých služeb TP ve společnosti ALVAO s. r. o.

3.2.3

Správa procesů

Ve službě technické podpory není pevně daný pracovní postup, kterým se má řešitel požadavků řídit, jestliže je tiket řízen procesy Incident Management, Request Fulfilment a Change Management. Je zkoušeno více přístupů: Na požadavky s chybami v produktu jsou navázány tikety do vývoje, ale samotný požadavek od zákazníka je obratem uzavřen, i když zatím není vydána oprava. Neexistuje jednotný postup jak postupovat v případě, že zákazník zašle zlepšovací návrh, tudíž se zvětšuje množina požadavků, které se vůbec neřeší. Dále je zkoušen postup, že po zaslání návodu na vyřešení incidentu či požadavku na službu je tiket zákazníka ihned uzavřen, řešitel tedy nečeká na zaslání zpětné vazby od žadatele, než požadavek uzavře. Není vytvořen postup, jak pracovat s požadavky na úpravu knihovny SW vzorů. Na následujícím grafu (Obrázek 14 - Počet znovuotevřených požadavků dle jednotlivých služeb TP) je zobrazen počet znovu otevřených požadavků ve službách technické podpory v roce 2013. Průměrný počet znovu otevřených požadavků byl 15 za měsíc. Nejvíce jich připadalo na službu „Technická podpora/Pomoc s provozem“, mezi 7 - 8 požadavky měsíčně.

33


25

Technická podpora/Dotazy Technická podpora/Chyby v produktu Technická podpora/Zlepšovací návrhy

Technická podpora/Pomoc s provozem Technická podpora/Úpravy knihovny SW produktů

20 5 15

10

4

2 12

6

2 2 3

10 7 5

0

5

2 2 1

1 2

1 2

3 1

8

3 10

6 3

2 1

1 1

2

1 1

6 1 4

7 1

3

Obrázek 14 - Počet znovuotevřených požadavků dle jednotlivých služeb TP

3.2.4

Zákaznický feedback

Na službě technické podpory je v organizaci ALVAO s. r. o. používán anonymní dotazník sloužící k získání zpětné vazby od zákazníků. S jeho pomocí se zjišťuje kvalita dodávaných služeb uživatelům systémů ALVAO. Dotazník je sestaven z několika otázek, ve kterých se zjišťuje spokojenost zákazníků s rychlostí řešení jejich problémů, ale i odbornost a profesionalita členů řešitelského týmu technické podpory. První tři otázky jsou zkonstruovány právě pro zjištění kvality dodávané služby: Jste spokojen s rychlostí řešení Vašeho požadavku? Jste spokojen s úrovní odborných znalostí pracovníků? Jste spokojen s profesionalitou pracovníků Další otázka je věnována ceně řešení a poslední slouží k poskytnutí jakéhokoliv názoru či komentáře. V prvních dvou případech může vyplňovatel vybírat z množiny odpovědí: Spokojen, spíše spokojen, spíše nespokojen a nespokojen. V odpovědi na třetí otázku na zákazník možnost vybírat z možností: Dobrá, spíše dobrá, spíše špatná, neúnosná. Na následujících obrázcích (Obrázek 15 - Zákaznický feedback za rok 2012 rychlost řešení, Obrázek 16 - Zákaznický feedback za rok 2012 - odborné znalosti pracovníků a Obrázek 17 - Zákaznický feedback za rok 2012 - profesionalita pracovníků) jsou zobrazeny výsledky získané za rok 2012. Anonymní dotazník celkem vyplnilo v tomto období 49 zákazníků. Je zde vidět, že zákazníci společnosti ALVAO s. r. o. byli ve většině případů spokojeni s poskytovanou službou technické podpory. Největší

34


výhradu měli ve sledovaném období k době řešení jejich požadavků, kdy jich 16 odpovědělo, že je s dobou řešení spokojeno pouze částečně, dva zákazníci byli spíše nespokojeni a jeden dokonce nespokojen.

Rychlost řešení požadavků

12 nespokojen 16

spíše nespokojen částečně spokojen

30

spokojen

Obrázek 15 - Zákaznický feedback za rok 2012 - rychlost řešení

Odborné znalosti pracovníků

5 nespokojen spíše nespokojen častecne spokojen spokojen 44

Obrázek 16 - Zákaznický feedback za rok 2012 - odborné znalosti pracovníků

35


Profesionalita pracovníků

1 4 neúnosná spíše špatná spíše dobrá dobrá 44

Obrázek 17 - Zákaznický feedback za rok 2012 - profesionalita pracovníků

36


3.2.5

ALVAO Service Desk

Hlavním nástrojem, který se v organizaci používá na řízení požadavků v rámci různých oddělení je ALVAO Service Desk. Tento nástroj slouží jako centrální kontaktní bod pro komunikaci se zákazníkem. Jsou zde zaznamenávány a spravovány veškeré incidenty, servisní požadavky, události a je rozhraním pro všechny ostatní procesy a činnosti provozu služeb. Z pohledu zákazníka jde o kontaktní místo, kde může hlásit problémy a požadavky a kde mu budou poskytnuty relevantní a přesné informace k daným případům. Hlavní výhodou tohoto nástroje je vysoká přizpůsobitelnost funkcionality pro řízení různých servisních oddělení. Je zde možné např.: Definovat vlastní procesy (workflow) Nastavovat priority jednotlivým tiketům Definovat žadatelský a řešitelský tým v rámci poskytované služby Sledování vykázané práce Vytvoření statistik a reportů Jednoduchá komunikace v rámci týmu i se žadatelem Vyhledávání informací pomocí filtrů Řízení menších projektů Použití plánování řešení požadavků

Systém je navrhnut, aby co nejvíce spolupracoval s aplikacemi a jinými systémy od společnosti Microsoft. Je tedy možné systém propojit MS Outlook, MS Active Directory, MS Exchange, MS SQL Server, MS Office 365 a samozřejmě běží na operačních systémech Windows. Tento produkt je používán i ve velkých společnostech, kde se musejí zabývat řízením IT oddělení. V organizaci ALVAO s. r. o. je systém nepostradatelným nástrojem při každodenní práci. V systému jsou uloženy a požadavky napříč oddělenými celé organizace a dále i např. interní CRM se všemi kontakty na stávající zákazníky společnosti či docházkový systém, na jehož základě jsou zaměstnancům vypláceny mzdy. V tomto systému jsou optimalizovány nejvíce používané procesy řešení každodenních potíží (Incident Management), realizace běžných žádostí (Request Fulfilment), evidence veškerých IT služeb, IT zařízení a SW licencí (Service Asset & Configuration Management), řízení změn (Change Management), řešení problémů (Problem Management) a správa katalogu služeb ( Service Catalog Management). V době psaní této diplomové práce byl tento nástroj v procesu certifikace podle ITIL 2011 edition u renomované mezinárodní autority Pink Elephant.

37

4 Návrh změn Jakmile byla dokončena analýza stávajícího stavu služby technické podpory, bylo potřeba navrhnout seznam změn, které by měly být v této službě implementovány, aby byl možný přechod z reaktivního módu poskytování této služby na mód proaktivní. Již na začátku projektu bylo jasné, že tato transformace se nejvíce dotkne kapacit lidských zdrojů, které se budou na této službě podílet. V této kapitole bude tedy popsán návrh všech změn, které byly navrhnuty k implementaci. V první řadě bylo nutné si uvědomit, že pokud chce společnost nasadit pro zákaznický přístup, tak se tyto změny nedotknou pouze služby technické podpory, ve které se dříve ve většině případů pouze už „hasily“ problémy zákazníků, ale bude muset provést změny v širším pojetí. Změny se tedy dotknuly i oddělení zabývajícím se marketingem a prodejem produktu. V následujících dvou podkapitolách bude následovat výčet návrhů na změny, které by měly pomoci k dosažení transformace z reaktivního módu na proaktivní. V první kapitole se bude jednat o návrhy, které nejsou úzce spjaty se službou technické podpory, ale dopad těchto změn se do této služby projeví. Druhou skupinou jsou změny, které jsou navrhnuty k realizaci přímo ve službě technické podpory.

4.1 Změny týkající se nepřímo služby technické podpory Vytvoření služby Péče o zákazníka: Do této služby je vždy založen požadavek pro každého zákazníka společnosti ALVAO s. r. o., který si zakoupil některý z nabízených produktů a je již úspěšně ukončena implementace a vyřešena fakturace za odvedenou práci. V rámci tohoto požadavku se řeší hlavní komunikace se zákazníkem, která vznikla na základě osobní návštěvy nebo telefonátu, kterým se zjišťuje aktuální stav spokojenosti se systémy ALVAO. Jakmile je zjištěn nějaký problém s používáním produktu, jsou založeny navázané požadavky do příslušné kategorie služby technické podpory, kde se jim operátor věnuje dle definovaného SLA daného zákazníka. V rámci tohoto požadavku se řeší i případné nabídky na upgrade systémů či zakoupení dalšího systému nebo některého z modulů.

38

NÁVRH ZMĚN

Osobní návštěvy u zákazníků: Z důvodu zjištění aktuálního stavu spokojenosti s dodanými službami zákazníkovi se realizují osobní návštěvy v místě uživatele produktu. Osobní návštěva má vždy největší váhu a na zákazníka působí velmi pozitivně. Je poté přesvědčen, že je pro organizaci ALVAO s. r. o. velmi důležitý a vážený. Aby bylo možné tyto osobní návštěvy realizovat, musí vzniknout nová pracovní pozice, která bude stát na rozhraní mezi prodejním týmem a týmem z oddělení služeb. Hlavním úkolem osoby pracující na této pozici je zjistit aktuální stav používání produktu, spokojenost s dodávkou služeb a nabízet případně další služby jako např. údržbu (maintenance). V rámci společnosti ALVAO s. r. o. umožňuje tato služba zákazníkovi upgrade na nejnovější verze systémů, stahovat aktuální verzi knihovny SW produktů). Dále nabízí služby jako workshopy (řeší se především použitelnost aplikací či školení produktu), asistovaný upgrade a prodej modulů. Všechny informace zjištěné při osobní schůzce jsou zapisovány do požadavku ve službě „Péče o zákazníky“, další postup je řízen procesem viz předchozí část (Vytvoření služby Péče o zákazníky). Vytvoření služby Neztracení stávajícího zákazníka: Pokud se při osobní návštěvě nebo při telefonátu z důvodu zjišťování spokojenosti s produktem zjistí, že je zákazník nespokojen a chtěl by přestat produkt používat čili rozvázat spolupráci se společností ALVAO s. r. o., je založen požadavek do služby Neztracení stávajícího zákazníka. V rámci tohoto požadavku je vedena komunikace se zákazníkem s cílem udržet stávajícího zákazníka a především zjistit informace ohledně důvodu, který ho vede k tomu, že chce dát výpověď. Pokud se jedná o rozhodnutí mateřské společnosti, tak se nemusí jedna o vážný problém (chyba není na straně ALVAO s. r. o.). Pokud je ale nespokojen s produktem nebo službami, které jsou mu dodávány, je to zdroj informací pro změny v organizaci. Workshopy se zákazníky o dalším vývoji systémů: Společnost ALVAO s. r. o. pořádá celkem 4 workshopy se zákazníky o směřování dalšího vývoje produktů ALVAO. V rámci těchto workshopů mají zákazníci možnost navrhnout různá vylepšení stávajících systémů tak, aby pro ně používání přineslo co největší hodnotu. Jednotlivé návrhy jsou diskutovány s vedením vývojového oddělení a probíhá hledání možných řešení. Pokud změnu vyžaduje pouze jeden zákazník, je hůře znovu použitelná pro ostatní uživatele. Pokud se k ní vyjádří větší skupina, najde se obvykle lepší řešení s větší použitelností pro všechny. Na závěr workshopu je každému účastníkovi předán seznam diskutovaných zlepšení systémů a jejich úkolem je jim přidělit body, tímto způsobem se provádí první vlna stanovení priority daných změn. Představení nových verzí systémů ALVAO: Před vydáním nové plné verze uspořádá společnost ALVAO s. r. o. setkání se zákazníky, na kterém bude představena

39

NÁVRH ZMĚN

nová verze. Na tuto akci bude zvát své zákazníky informací na svých webových stránkách, prostřednictvím newsletterů a v neposlední řadě během různých příležitostí, kdy přijde kdokoliv ze společnosti do kontaktu z jednotlivými zákazníky. Na této konferenci budou představeny hlavní novinky v nové verzi pro jednotlivé systémy s ukázkami na „živém“ systému. Bude připomenuta stávající funkcionalita a samozřejmě nebude chybět prostor pro diskuzi ohledně používání systému. Získání zpětné vazby z pořádaných akcí: Ze všech pořádaných akcí společností ALVAO s. r. o., jako workshopy o směřování dalšího vývoje nebo konference týkající se představení nové verze, bude zjišťována zpětná vazba od zákazníků, aby organizace věděla, co pro příští konání těchto akcí zlepšit. Zpětná vazba bude zjišťována pomocí dotazníků, které budou během akce rozdány. Další informace mohou být získány prostřednictvím osoby, která má na starosti stávající zákazníky, ať již během osobní návštěvy či telefonního rozhovoru.

4.2 Změny týkající se přímo služby technické podpory 4.2.1

Držení služeb TP konzultanty

Zajištění větší podpory ze strany úrovně L2 pro operátora služby technické podpory (úroveň L1). Jelikož mají členové úrovně L2 větší zkušenosti s produkty a znají většinou i problémy, které mohou nastat při používání systémů, tak je vyžadována větší podpora pro operátora technické podpory, který při nahlášení problému zákazníkem, umí řešení pouze vyhledat v již vyřešených problémech či bázi znalostí. Konzultant by měl být operátorovi k dispozici, když už není možné, aby byl fyzicky přítomen v kanceláři, tak alespoň na telefonu, aby mohl operativně řešit problémy vyskytující se ve službě technické podpory. Při řešení jednotlivých potíží se operátor technické podpory učí od konzultanta či produktového specialisty, jaký je správný postup při zjišťování příčiny problému a jaký je následný postup při jeho řešení. Dalším důvodem pro vznik této podpory od úrovně L2 úrovni L1 je, snaha o snížení využívání L3 úrovně při řešení problémů, které nejsou způsobeny chybami v produktu, ale pouze chybným nastavením. Důsledkem snížení odpracovaných hodin úrovní L3 ve službě technické podpory bude velký pokles nákladů na provoz této služby. Tato změna reaguje na zapojení jednotlivých skupin do řešení požadavků v roce 2013, které je zobrazeno na grafu Čím více se do řešení požadavků zapojují úrovně L2 a L3, tím se zvyšuje cena provozu služby technické podpory pro dodavatele. Primárním cílem je tedy co nejvíce omezit práci úrovně L3 v této službě, jelikož osoby pracující na této

40

NÁVRH ZMĚN

úrovni jsou pro dodavatele nejdražší a snahou je využít jejich kapacitu na vývoj produktů a testování a ne pro poskytování podpory zákazníkům. Na začátku roku vykázala úroveň L3 do služby technické podpory 60 hodin práce (milník 1), což bylo způsobeno nástupem nového zaměstnance na pozici operátora technické podpory. Postupně se podařilo tuto hodnotu snižovat. V prvním a druhém kvartálu byla tato hodnota zhruba 30 hodin měsíčně (milník 2), což bylo způsobeno vydáním opravného balíčku k produkční verzi. V červenci tato hodnota opět výrazně vzrostla (milník 3), tento výkyv byl způsoben nastoupení operátora technické podpory na úplný úvazek, tudíž i stoupla celková doba vykázaná na práce ve službě technické podpory. V dalších měsících se podařilo hodnotu zapojení úrovně L3 do řešení požadavků na technické podpoře ustálit na zhruba 15 hodin měsíčně, což je výrazný pokles oproti 60 hodinám v lednu. 250

milník 1

milník 2

milník 3

200 60,15 150

38,9

26,88

18,91 29,82

30,59

62,85

20,61

30,47 35,31

100 48,31 50

103,6

84,24 59,55

59,26

9,87

14,82 6,44

26,65 14,7 2,6

15,53 5,85

35,58

40,23

83,45

38,24

105,15 114,62 104,15

125

15,46 75,02

69,42

27,71 26,19

0

L1

L2

L3

Obrázek 10 - Přehled vykázaných hodin v roce 2013 ve službě technické podpory dle jednotlivých úrovní) s cílem snížit celkovou dobu řešení požadavků. Tato změna také zaručí, že úroveň L1 bude mít dostatečnou podporu od úrovně L2, jelikož konzultanti si musejí vyhradit kapacitu na pomoc při řešení požadavků ve službě technické podpory. Podpora od úrovně L2, také zajistí menší zatížení L3 úrovně.

4.2.2

Proaktivní zjišťování aktuálního stavu používání systému

U zákazníků, u kterých již není kapacita, aby se uskutečnila osobní návštěva, jsou prováděny telefonické rozhovory z důvodů zjištění aktuálního stavu používání

41

NÁVRH ZMĚN

produktů. Během těchto telefonátů je zjišťována verze systémů. Pokud se jedná o starší produkt, je nabízena možnost asistovaného upgrade, ať již v místě zákazníka nebo vzdáleně. Dále je nabízena možnost profylaktické kontroly systémů, která se skládá z kontroly nastavení všech komponent a funkčnosti celého systému. Více o profylaxi v dalším bodu. Pokud je během telefonátu nahlášen od zákazníka nějaký problém s provozem systémů, je zákazníkovi sdělen kontaktní e-mail na technickou podporu nebo telefonní spojení. Na základě zjištěných podrobností o problému je založen požadavek do služby technické podpory, kde se mu dále věnuje L1 support. Dalším účelem proaktivního zjišťování aktuálního stavu je i snaha zjistit celkovou spokojenost zákazníka se spoluprací se společností ALVAO s. r. o. Pokud je zjištěna nespokojenost s dodávkou služeb, je založen požadavek do služby o Neztracení stávajícího zákazníka, který se řídí procesem, viz výše. Tato změna je navrhnuta s cílem zjistit aktuální stav používání produktu a celkové spokojenosti zákazníka s poskytovanými službami společností ALVAO s. r. o.

4.2.3

Nabídka profylaktické kontroly

V rámci předchozího bodu byla zmíněna možnost provedení profylaktické kontroly vzdáleně u zákazníka. Cílem této kontroly je potvrdit bezchybný chod všech aplikací a správné nastavení jednotlivých komponent systémů. V případě nalezení drobných chyb se provádí okamžitá náprava. Tato kontrola by měla trvat maximálně půl hodiny, přičemž, když se narazí na chyby, které nelze odstranit v krátkém časovém horizontu, jsou založeny požadavky do služby technické podpory, kde se jim dále věnuje L1 support. V rámci udržování dobrých vztahů se zákazníky a použití proaktivního přístupu by měly být tyto kontroly zdarma. Cílem profylaktických kontrol je odbourání případů, kdy systém nefunguje dle specifikace a některé z jeho součástí vykazují chybné chování. Tato změna reaguje na zjištění skladby požadavků zakládaných ve službě technické podpory, viz graf (Obrázek 13 - Počet vytvořených požadavků do jednotlivých služeb TP ve společnosti ALVAO s. r. o.), Bylo zjištěno, že nejvíce požadavků je typu incident, který není způsoben chybou v produktu, ale jedná se o problémy způsobené chybnou konfigurací systému. Tyto problémy souvisí se snahou zákazníku o nasazení systémů bez asistence pracovníků společnosti ALVAO s. r. o.

4.2.4

Definice přesných pracovních procesů ve službě TP

Cílem této změny je definovat přesné postupy, jak řešit jednotlivé požadavky typu řešení potíží, běžné žádosti a změny. Při přijetí požadavku typu incident je úkolem

42

NÁVRH ZMĚN

operátora případně konzultanta zjistit, zdali se jedná o chybu v nastavení nebo o chybu v produktu. Pokud se jedná o chybu v produktu je požadavek přesunut do služby „Technická podpora/Chyby v produktu“ a úkolem řešitele je zajistit kontaktování hlavního vývojáře daného produktu. Ten provede založení navázaného požadavku pro analýzu daného problému. Pokud se potvrdí, že se jedná o chybu v produktu je změněn stav původního požadavku na „Čeká na vydání“. Řešitel původního požadavku, který založil zákazník, provede jeho zkontaktování, že se jedná o chybu v produktu a o vydání verze s opravou tohoto problému bude informován. Jakmile je navázaný požadavek uzavřen s tím, že je vydána verze, ve které je tato chyba opravena, je o této akci informován zákazník a jeho požadavek je uzavřen. Nikdy tedy již nedojde k uzavření požadavku dříve než je k dispozici opravená verze produktu, jak k tomu docházelo dříve. Pokud se jedná o požadavky na službu, konkrétně o požadavek na úpravu knihovny SW vzorů, je aplikován nový proces, kterým se tato služba řídí. Do této služby mohou přijít dva druhy požadavků: o

Žádost o přidání nového produktu

o

Žádost o přidání SW podle nerozpoznaných registrů

První požadavek je operátorem této služby předán na osobu, které má na starosti zapracování nových produktů do SW knihovny a stav požadavku je změněn na „Zapracování do SW knihovny“. Jakmile je produkt přidán, je požadavek předán na osobu, která má na starosti vydávání této knihovny a stav je změněn na „Publikování SW knihovny“. Po vydání knihovny je tento požadavek uzavřen s informací o této skutečnosti žadateli. Druhý typ požadavku je operátorem služby přidělen vydavateli knihovny a jeho stav je změněn na „Publikování SW knihovny“. Mezitím je automaticky systémem přidán do DB požadavek o rozpoznání tohoto SW dle registrů. Osoba, která je zodpovědná za zapracování těchto změn, vidí na speciálním portálu tento produkt a přiřadí mu pravidlo na rozpoznání. Jakmile vydavatel na portále zjistí, že je tento produkt již rozpoznán uzavírá daný požadavek s informací žadateli. Posledním typem požadavku je žádost o změnu v produktu. Žadatel zašle návrh na změnu v produktu do služby technické podpory, kde ji po zjištění dalších podrobností přesune řešitel do služby „Technická podpora/Zlepšovací návrhy“ a změní stav na „Čeká na rozhodnutí“. Zároveň zakládá navázaný požadavek do služby „Vývoj produktů/Změny v produktech“, kde je tento požadavek ohodnocen prioritou a dále se mu vývojové oddělení věnuje dle stanovené priority. Jakmile je tento navázaný požadavek realizován, jde informace řešiteli původního požadavku o této skutečnosti. Ten obratem kontaktuje zákazníka, že byla vydána verze systému, ve které byl tento zlepšovací návrh realizován.

43

NÁVRH ZMĚN

Důvodem vzniku tohoto návrhu na změnu je výskyt situací, kdy některé požadavky nejsou řešeny správně, většinou z důvodu, že není definován přesný pracovní postup (např. ve službě Úpravy knihovny SW vzorů). Tyto situace mají dopad na dlouhou dobu řešení jednotlivých požadavků (Obrázek 12 - Průměrná doba řešení požadavků v jednotlivých službách dle skupiny žadatele) a na počet požadavků, které jsou znovu otevírány žadateli, z důvodu předčasného uzavření bez vyřešení problému viz graf (Obrázek 14 - Počet znovuotevřených požadavků dle jednotlivých služeb TP).

4.2.5

Pravidelná kontrola reportů o dodržování SLA ve službě TP

Vytvoření speciálního reportu, ve kterém budou sledovány klíčové faktory ovlivňující spokojenost zákazníků. Hlavní je důraz na porušení SLA při provedení první reakce směrem od dodavatele služby k jejímu odběrateli. Dále tento report obsahuje i informace o počtu aktuálně řešených požadavků a rozdělení mezi jejich řešitele případně dle rozdělení do jednotlivých kategorií služby technické podpory. Nakonec tento report obsahuje i informace z vyplněných dotazníků žadateli jednotlivých požadavků, který jim je zasílán společně se zprávou o uzavření jejich požadavku. Tento report by měl být prezentován na poradě týmu oddělení služeb minimálně jednou za kvartál, aby se mohli vysledovat trendy v poskytování služby technické podpory. Tato změna reaguje na zjištění, že dle grafu

120 100 80 60

20

111

97

40 49 23

26

14

73

67

63 13

32

14

74

58 12

17

60 8

0 1.12.2012 1.1.2013 1.2.2013 1.3.2013 1.4.2013 1.5.2013 1.6.2013 1.7.2013 1.8.2013 Počet překročení SLA

Počet požadavků

Obrázek 11 - Počet překročení první reakce v organizaci ALVAO s. r. o.) se průměrně ve 3 – 4 požadavcích měsíčně překročí doba první reakce u uživatelů s placenou technickou podporou.

44

NÁVRH ZMĚN

4.2.6

Kontrola využívání L3 supportu při poskytování služby TP

Tento bod plynule navazuje na předchozí ohledně vytvoření reportů technické podpory. Část tohoto reportu by měla být věnována i odpracovaným hodinách ve službě technické podpory a hlavně být zaměřena na využívání jednotlivých úrovní podpory (L1, L2, L3). Hlavním předmětem analýzy by měla být úroveň L3, u které se předpokládá v prvních fázích nasazení proaktivního přístupu pokles vykázaných hodin ve službě technické podpory. Úroveň L3 by se měla zapojovat především do požadavků ve službách „Technická podpora/Chyby v produktu“ a „Technická podpora/Zlepšovací návrhy“. V dalších kategoriích by se měl výskyt práce úrovně L3 výrazně omezit, především z důvodu zavedení větší podpory L2 úrovně operátorovi služby technické podpory viz Držení služeb TP konzultanty. Důvodem vzniku tohoto návrhu na změnu je reakce na graf Čím více se do řešení požadavků zapojují úrovně L2 a L3, tím se zvyšuje cena provozu služby technické podpory pro dodavatele. Primárním cílem je tedy co nejvíce omezit práci úrovně L3 v této službě, jelikož osoby pracující na této úrovni jsou pro dodavatele nejdražší a snahou je využít jejich kapacitu na vývoj produktů a testování a ne pro poskytování podpory zákazníkům. Na začátku roku vykázala úroveň L3 do služby technické podpory 60 hodin práce (milník 1), což bylo způsobeno nástupem nového zaměstnance na pozici operátora technické podpory. Postupně se podařilo tuto hodnotu snižovat. V prvním a druhém kvartálu byla tato hodnota zhruba 30 hodin měsíčně (milník 2), což bylo způsobeno vydáním opravného balíčku k produkční verzi. V červenci tato hodnota opět výrazně vzrostla (milník 3), tento výkyv byl způsoben nastoupení operátora technické podpory na úplný úvazek, tudíž i stoupla celková doba vykázaná na práce ve službě technické podpory. V dalších měsících se podařilo hodnotu zapojení úrovně L3 do řešení požadavků na technické podpoře ustálit na zhruba 15 hodin měsíčně, což je výrazný pokles oproti 60 hodinám v lednu.

45

NÁVRH ZMĚN

250

milník 1

milník 2

milník 3

200 60,15 150

38,9

26,88

18,91 29,82

30,59

62,85

20,61

30,47 35,31

100 48,31 50

103,6

84,24 59,55

9,87

14,82 6,44

26,65 14,7 2,6

15,53 5,85

35,58

40,23

83,45

38,24

59,26

105,15 114,62 104,15

125

15,46 75,02

69,42

27,71 26,19

0

L1

L2

L3

Obrázek 10 - Přehled vykázaných hodin v roce 2013 ve službě technické podpory dle jednotlivých úrovní), kdy se zapojení L3 suportu v některých měsících pohybovalo kolem 25 hodin měsíčně. Úroveň L3 provádí koncepční práci, tudíž jakékoliv vyrušení znamená snížení jejího výkonu.

4.2.7

Zavedení termínů pro vyřešení požadavků ve službě TP

Na všech požadavcích technické podpory je nastaven a hlídán termín do první reakce dle příslušné SLA zákazníka. Pokud si zákazník platí technickou podporu a je zařazen do skupiny B1, B2 nebo B3, tak mu společnost ALVAO s. r. o. garantuje započetí řešení jeho požadavku ve službě technické podpory dle dohodnuté SLA. Není však garantována doba do vyřešení jednotlivých požadavků., proto se v některých případech může stát, že doba řešení požadavku může být pro zákazníka nesnesitelně dlouhá, což se poté odráží ve vyplněných dotaznících spokojenosti. Pro lepší přehlednost řešení jednotlivých požadavků by tedy měly být nastaveny i termíny vyřešení požadavků, které

jsou

zařazeny

do

služeb

„Technická

podpora/Dotazy“,

„Technická

podpora/Pomoc s provozem“ a „Technická podpora/Úpravy knihovny SW vzorů“ u chyb v produktu a zlepšovacích návrhů tento termín nemá smysl, jelikož není nikdy dopředu známo, do jaké verze se vylepšení stihne realizovat nebo do jaké verze bude chyba opravena., tudíž by tento termín byl stejně ve většině případů překročen. Tyto termíny by poté ulehčily práci operátorům/ řešitelům v daných službách, jelikož by si

46

NÁVRH ZMĚN

lépe mohli naplánovat svoji práci a termíny vyřešení požadavku by se s největší pravděpodobností zkrátily. Nastavení jednotlivých termínů vyřešení není jednoduché, proto byla provedena analýza aktuálního stavu, aby bylo zjištěno, jak dlouho trvá průměrné řešení požadavků v jednotlivých kategoriích. Toto měření bylo provedeno v kapitole 3.2.2 Řešení požadavků. Na základě této analýzy bylo doporučeno nastavit termíny vyřešení požadavků následovně: „Technická podpora/Úpravy knihovny SW vzorů“: Termín vyřešení měl být stanoven na 10 dní v provozní době dané služby, jelikož je knihovně publikována každý týden. V některých případech je nutné získat další doplňující informace, proto je termín stanoven na tuto dobu. „Technická podpora/Dotazy“: Požadavky v této službě by měly být vyřešeny do 5 dní v provozní době, jelikož se většinou jedná o jednoduché dotazy, které by měl být schopen zodpovědět operátor služby případně s pomocí konzultanta. „Technická podpora/Pomoc s provozem“: Nastavení tohoto termínu je nejsložitější. Už z analýzy je jasné, že řešení těchto požadavků zabere řešitelskému týmu největší problémy. Ve všech případech řešení je potřeba spolupráce zákazníka a v některých případech i podpory L2 případně L3. Řešení těchto požadavků se v některých případech protáhne i na dva měsíce. Je tedy doporučeno stanovit termín vyřešení těchto požadavků na 30 dní v provozní době služby s ohledem na provedenou analýzu požadavků v roce 2013. Tento návrh na změnu byl vytvořen v reakci na dlouhé doby řešení jednotlivých požadavků, viz graf (Obrázek 12 - Průměrná doba řešení požadavků v jednotlivých službách dle skupiny žadatele). Dalším důvodem vzniku tohoto návrhu je usnadnění plánování řešení požadavků jednotlivým členům řešitelského týmu, kteří si poté snadno mohou sestavit frontu požadavků k řešení.

4.2.8

Nastavení upozornění na neřešení požadavků či poruše SLA

V návaznosti na předchozí bod, musí být zavedeny upozornění na neřešení jednotlivých požadavků ze strany řešitelského týmu a také upozornění na porušení dohodnutého SLA. Odesílání těchto upozornění musí být zvoleno v závislosti na termínu první reakce příp. termínu vyřešení, aby mohl řešitel ještě zabránit porušení daného SLA. Upozornění na blížící se termín první reakce by mělo přijít poprvé jeden den předem, později by se mělo stupňovat až nakonec by mělo přijít i operátorovi služby nebo jeho manažerovi, aby stihl vykonat nápravu a zabránil tak porušení SLA. Upozornění na blížící se termín vyřešení požadavku by měl být závislý na službě, ve které se požadavek nachází.

47

NÁVRH ZMĚN

48

NÁVRH ZMĚN

Pokud by byl ve službě „Technická podpora/Dotazy“, tak první upozornění řešiteli by mělo přijít 3 dny před vypršením termínu a postupně se opět stupňovat a případně eskalovat na vyšší role dané služby. Předpokládá se, že v této službě jsou pouze dotazy na funkcionalitu systému nebo otázky ohledně nastavení, tudíž by neměl být problém během 3 dnů v provozní době takový požadavek vyřešit. U služby „Technická podpora/Úpravy knihovny SW vzorů“ by tento termín měl být nastaven v závislosti na skutečnost, že knihovna je vydávána každý týden. Tudíž první upozornění by mělo přijít týden před vypršením termínu vyřešení a poté ho opět stupňovat a případně upozornit role postavené výše v hierarchii této služby. U požadavků založených do služby „Technická podpora/Pomoc s provozem“ je nejtěžší tento termín určit, protože v některých případech se řešení může protáhnout na delší časové období. V tomto případě bych navrhoval, aby první upozornění řešitelskému týmu přišlo deset dní před termínem vyřešení, jelikož za tento časový interval se většina problémů dle mých zkušeností stihne vyřešit. Jako v předešlých případech by se upozornění stupňovalo. Tato změna reaguje na zjištění v grafech

120 100 80 60 40 20 0

111

97

23

26

14

73

67

63

49

13

32

14

74

58 12

17

60 8


Počet požadavků

Obrázek 11 - Počet překročení první reakce v organizaci ALVAO s. r. o. a Obrázek 12 Průměrná doba řešení požadavků v jednotlivých službách dle skupiny žadatele), na kterých je vidět překročení v některých případech SLA a dlouhé řešení jednotlivých požadavků.

4.2.9

Zvýšení kvalifikace L1 supportu

Cílem tohoto bodu je dosáhnout stavu, kdy osoby vykonávající tuto úroveň podpory by měly být schopni zodpovědět většinu dotazů od zákazníků ohledně funkcionalit systému a vyřešit převážnou část incidentů nahlášených ve službě technické podpory s minimální pomocí ostatních úrovní podpory. Aby bylo tohoto cíle dosaženo, je nutné provádět produktová školení, kterých se musejí tyto osoby bezpodmínečně účastnit.

49

NÁVRH ZMĚN

V rámci těchto školení by měly být zodpovězeny všechny otázky, které účastník má. Operátoři technické podpory musejí být schopni si nainstalovat produkt v testovacím prostředí a provádět v něm základní analýzy a testy problémů, které jim hlásí uživatelů systémů. Další pomocí pro zlepšení kvalifikace je provedení implementací systému přímo u zákazníků. Díky tomu se operátor seznámí s problémy, které mohou při instalaci nastat a snaží se je i samostatně nebo případně s pomocí úrovně L2 vyřešit. Kromě produktových školení a účastí na implementacích systémů by bylo vhodné, aby tyto osoby absolvovali i školení systémů, se kterými produkty ALVAO spolupracují. Čím vyšší kvalifikaci budou mít osoby na úrovni L1, tím méně budou do řešení zasahovat ostatní úrovně podpory. Tato změna byla navrhnuta z důvodu, aby co nejvíce požadavků bylo vyřešeno v rámci úrovně L1 bez asistence dalších úrovní, případně s pomocí úrovně L2.

4.2.10 Zavedení nové služby „Technická podpora/Dotazy“ Cílem zavedení této služby je snadnější oddělení incidentů, které jsou zakládány do služby „Technická podpora/Pomoc s provozem“ (jedná se o nefunkčnost sytému, která není způsobena chybou v systému, ale chybnou konfigurací) od dotazů na funkcionalitu jednotlivých systémů či dotazů na doporučenou konfiguraci produktů ALVAO. Toto odlišení je zejména z důvodu reportingu, aby při prezentaci poskytování služby technické podpory bylo lépe viditelné, který typy požadavků na tuto službu převládají a kde je potřeba případně navýšit kapacitu řešitelů. Změna reaguje na špatnou přehlednost reportů o skladbě typů požadavků, které jsou vedeny ve službě technické podpory.

50

NÁVRH ZMĚN

4.3 Shrnutí návrhů na změny Reference

Popis

Cíl

4.2.1

Držení služeb TP konzultanty

Rychlejší reakce a vyřešení požadavků, menší zátěž L3 supportu.

4.2.2

Proaktivní zjišťování používání systémů

4.2.3

Nabídka profylaktické kontroly

4.2.4

Definice pracovních postupů ve Incidenty od zákazníků jsou službě TP uzavírány až po vyřešení, odstranění neinformovanosti zákazníků.

4.2.5

Kontrola dodržování SLA ve službě Nedochází k TP garantovaných SLA.

4.2.6

Kontrola využívání L3 supportu

Úroveň L3 je využívána k primárnímu účelu a ve službě technické podpory pouze k řešením chyb v produktech.

4.2.7

Zavedení termínů vyřešení

Zkrácení doby řešení požadavků, vyšší spokojenost zákazníků s rychlostí řešení, řešitelský tým si lépe organizuje práci.

4.2.8

Nastavení notifikací na neřešení či Nedochází k poruše SLA či poruše SLA zbytečnému prodlužování řešení požadavků.

4.2.9

Zvýšení kvalifikace L1 supportu

Většinu požadavků vyřeší L1 support bez asistence dalších úrovní nebo s pomocí L2

4.2.10

Zavedení služby „Technická podpora/Dotazy“

lepší přehlednost reportu o skladbě typů požadavků ve službě TP

stavu Zjištění problémů u zákazníka a jeho spokojenost s produkty. Opravy chybných konfigurací systémů, méně nahlášených incidentů na TP.

poruše

51

5 Implementace změn V předchozí kapitole byly sepsány návrhy na změny, které by měly přispět k úspěšnému přechodu od reaktivního přístupu poskytování služeb zákazníkům společnosti ALVAO s. r. o. k proaktivnímu. Všechny zmíněné body byly diskutovány na poradách s ředitelem služeb. Většina těchto návrhů na změny byla implementována během psaní této práce, na některé se však z kapacitních důvodů doposud nedostalo, ale stále figurují na seznamu změn, které budou uvedeny do praxe v budoucnu.

5.1 Realizované změny Většina navrhnutých změn se dočkala realizace před dokončením tvorby tohoto dokumentu. Mezi realizované změny patří následující: Vytvoření služeb „Péče o zákazníka“ a „Neztracení stávajícího zákazníka“. Osobní návštěvy u zákazníků. Workshopy se zákazníky o dalším vývoji systémů. Představení nových verzí systémů ALVAO. Získání zpětné vazby z pořádaných akcí. Držení služeb TP konzultanty. Definice přesných pracovních procesů ve službě TP. Kontrola využívání L3 supportu při poskytování služby TP. Pravidelná kontrola reportů o dodržování SLA ve službě TP. Nastavení upozornění na neřešení požadavků či poruše SLA. Zvýšení kvalifikace L1 supportu. Zavedení nové služby „Technická podpora/Dotazy“. Změny, které se nepřímo týkaly služby technické podpory, byly realizovány v rozsahu návrhu. Vznikla nová pozice „Manažer pro klíčové zákazníky“, který má na starosti řešení prvních třech bodů a zodpovídá za jejich správný chod. V dubnu tohoto roku (2014) proběhly dvě konference nazvané „ALVAO Technology Day“, jedna v Praze a druhá v Brně. Na těchto setkání byly prezentovány nové funkcionality verze ALVAO 8. Během těchto konferencí byly účastnící vyzváni k poskytnutí zpětné vazby pomocí dotazníku, který je uveden v příloze.

52

IMPLEMENTACE ZMĚN

Doporučení, která se týkala přímo služby technické podpory, se podařilo realizovat skoro v plném rozsahu. Byl vytvořen plán služeb podpory operátora technické podpory pro konzultanty (návrh 4.2.1), kteří drží tuto služby vždy celý týden. Pokud má konzultant daný týden tuto službu držet, tak se snaží neplánovat si žádné výjezdy k zákazníkům a je operátorovi plně k dispozici minimálně na telefonu. Ve všech kategoriích služby technické podpory byly pevně definované procesy (návrh 4.2.4), které napomáhají řešiteli ke správnému postupu při řešení jednotlivých požadavků. Součástí přílohy této práce je proces, který byl aplikován ve službě „Technická podpora/Úpravy knihovny SW vzorů“. Pro účely prezentace aktuálních trendů v poskytování služby technické podpory byl vytvořen speciální report (návrh 4.2.5 a 4.2.6), ve kterém jsou sledovány všechny důležité aspekty, které se sledují, jako např. aktuální počet požadavků ve službě technické podpory dle jednotlivých kategorií a řešitelů, dále je sledována dodržování SLA či odpracované hodiny v této službě dle jednotlivých řešitelů. Tento report je součástí příloh. Dále byl vytvořen „dashboard“, který je pravidelně obnovován a zobrazuje aktuální počet požadavků každého řešitele. Tento „dashboard“ je také součástí přílohy. Na všech dohodnutých SLA byly definovány upozornění na neřešení požadavků nebo při poruše daného SLA, které jsou zasílány řešitelům, operátorům a nakonec i manažerovi služby (návrh 4.2.8). Příklad nastaveného SLA a definovaného upozornění lze nalézt v příloze této práce. Operátor technické podpory prošel během sledovaného období (leden 2013 – květen 2014) řadou produktových školení, dále absolvoval školení ITIL®, které ukončil zkouškou na úrovni ITIL® 2011 Foundation. Účastnil se řady konzultací s kolegy, při kterých prohluboval znalosti ohledně produktů ALVAO a v neposlední řadě implementoval jednotlivé systémy u zákazníků společnosti, což zahrnuje samotnou instalaci a školení používání (návrh 4.2.9). Nakonec byla vytvořena nová kategorie služby technické podpory „Technická podpora/Dotazy“, do které byly přesunuty odpovídající požadavky od ledna 2013, z důvodu přehlednějšího reportování. Všechna nastavení převzala tato kategorie ze služby „Technická podpora/Pomoc s provozem“.

53

IMPLEMENTACE ZMĚN

5.2 Změny čekající na realizaci Některé změny se do ukončení tvorby této práce nepodařily z kapacitních důvodů realizovat. Mezi změny čekající na realizaci patří: Zavedení termínů pro vyřešení požadavků ve službě TP (návrh 4.2.7). Proaktivní zjišťování aktuálního stavu používání systému (návrh 4.2.2). Nabídka profylaktické kontroly (návrh 4.2.3). Poslední dva body se začaly v částečném rozsahu realizovat týden před dokončením této práce. Vzniknul formulář profylaktické kontroly, který je uveden v příloze. V rámci praxe se poslednímu bodu věnovala studentka střední školy, která začala obvolávat stávající zákazníka z cílem zjistit aktuální stav používání produktu a nabídnout možnost asistovaného upgrade na verzi ALVAO 8. Bohužel nebyl dostatečný prostor pro sledování ohlasů této změny, proto je zmíněn jen okrajově. Ostatní změny byly odsouhlaseny ředitelem služeb a v blízkém časovém horizontu by měly být realizovány v navrženém rozsahu.

54

6 Vyhodnocení přechodu na proaktivní přístup Tato kapitola je věnována vyhodnocení implementace proaktivního přístupu v poskytování služeb zákazníkům společnosti ALVAO s. r. o. Čtenář v této části práce nalezne srovnání stavu před přechodem na proaktivní přístup pomocí dříve uvedených změn se stavem po implementaci těchto doporučení. Snahou bylo docílit vyšší spokojenosti zákazníků s poskytovanými službami a také zvýšit kvalitu dodávaných služeb. Aby bylo možné sledovat, jestli se přechod k proaktivnímu přístupu promítl do kvality dodávaných služeb, zachycují jednotlivé grafy a výstupu období od září 2013 do dubna 2014. Nejprve bude sledováno, jestli se podařilo docílit zvýšení kvality poskytovaných služeb.

6.1 Kvalita služeb První podkapitola je věnována vyhodnocení, zdali se podařilo dosáhnout zvýšení kvality služeb. Mezi sledované faktory patří počet překročení SLA, průměrná doba reakce, průměrná doba vyřešení požadavků, počet znovu otevřených požadavků a analýza zpětné vazby od zákazníků.

6.1.1

Trend ve vytváření požadavků

Pro představu, kolik bylo otevřeno požadavků k jednotlivým měsícům ve všech kategoriích služby technické podpory, byl vytvořen graf Obrázek 18 - Počet otevřených požadavků k jednotlivým měsícům ve službě TP ve společnosti ALVAO s. r. o. Na grafu jsou vidět hlavní tři zlomy: Milník 1 zachycuje dobu vydání opravného balíčku k verzi 7.1, v reakci na tuto akci byl pozorován nárůst vytvořených tiketů. Druhý milník zachycuje období, kdy byla vydána verze 8.0 BETA, ve které bylo značné množství chyb, které odhalily zákazníci společnosti ALVAO s. r. o. Poslední milník reflektuje vydání verze produkční verze 8.0, což mělo za následek největší nárůst vytvoření požadavků ve sledovaném období.

55

VYHODNOCENÍ PŘECHODU NA PROAKTIVNÍ PŘÍSTUP

milník 2

milník 1

milník 3

Počet otevřených požadavků

180 160 140 120 100 80 60 40 20 0 1.9.2013 1.10.2013 1.11.2013 1.12.2013 1.1.2014 1.2.2014 1.3.2014 1.4.2014 1.5.2014 Obrázek 18 - Počet otevřených požadavků k jednotlivým měsícům ve službě TP ve společnosti ALVAO s. r. o.

Na následujícím grafu Obrázek 19 - Průtok požadavků ve všech kategoriích služby TP ve společnosti ALVAO s. r. o. je zobrazen průtok požadavků ve všech kategoriích služby technické podpory. Ve sledovaném období. Kopíruje trend grafu o počtu otevřených požadavcích. Milníky jsou stejné a je zde vidět, že v měsíci březnu byl velký nárůst vytvořených požadavků, které byly odstraněny. Jednalo se o chybu v systému, kdy se generovalo velké množství požadavků na přidání SW knihovny SW vzorů. 180

169 156 148

160 140

114 116

120 100

82

82 52

48

103

86

76

80 60

105

98

85 54

46

41

40 20

2

2

3

4

2

2

2

3

2

0 1.9.2013 1.10.2013 1.11.2013 1.12.2013 1.1.2014 Vytvořeno

Uzavřeno

1.2.2014

1.3.2014

1.4.2014

1.5.2014

Odstraněno

Obrázek 19 - Průtok požadavků ve všech kategoriích služby TP ve společnosti ALVAO s. r. o.

56


6.1.2

Reakční doby

Prvním sledovaným faktorem, který velmi ovlivňuje kvalitu poskytovaných služeb, jsou reakční doby dodavatele. Prvním typem je doba do první reakce, která je součástí definice dohody o úrovni služeb a společnost ALVAO s. r. o. ji svým zákazníkům garantuje. Na prvním grafu (Obrázek 20 - Doba do první reakce ve službě technické podpory) je zobrazen počet požadavků, u kterých byla tato doba překročena ve sledovaném období. 140 120 100 80 132

60 85

40 20 0

65

45 3

2

3

70

61 7

5

76

57 3

14

10

2

42


Počet požadavků

Obrázek 20 - Doba do první reakce ve službě technické podpory

Pokud tento graf porovnáme za stejné dlouhé období před přechodem na proaktivní přístup, tak je výsledek, viz graf (Obrázek 21 - Porovnání v počtu překročení před implementací proaktivního přístupu). Před implementací proaktivního přístup byl počet překročených požadavků ve službě technické podpory zhruba 18 požadavků měsíčně, po přechodu byl zaznamenán pokles na necelých 6 požadavků, což je snížení o 66%. Na tomto poklesu se nejvíce podílely aspekty zmíněné v kapitole Změny týkající se přímo služby technické podpory. Jedná se především o držení služeb TP konzultanty, kteří mohou nahradit v době nepřítomnosti operátora technické podpory a provést první reakci místo něj.

57


Porovnání překročení 35

Počet překročení

30 25 20 32

15 10 5

26

23

14 7

2

14

13 3

7

5

12 14 3

17 10

8

2

0 měsíc1

měsíc2

měsíc3

měsíc4

měsíc5

Před přechodem

měsíc6

měsíc7

měsíc8

měsíc9

Po přechodu

Obrázek 21 - Porovnání v počtu překročení před implementací proaktivního přístupu

6.1.3

Řešení požadavků

Dalším objektem měření je průměrná doba otevření požadavku, která nám ukazuje, jak rychle jsou požadavky řešeny. V případě, že jsou hodnoty příliš vysoké, dochází ke kumulování požadavků a porušování SLA. Průměrná doba řešení požadavků dle jednotlivých kategorií služby technické podpory a SLA je zobrazen na grafu (Obrázek 22 - Průměrná doba řešení požadavků v jednotlivých kategorií služby TP dle SLA). 90 80 76,74

Průměrná doba řešení

70 69,05

60 50 40

58,695 53,49 47,4849,39

54,32

Dotazy


48,965 45,5

48,08 40,91

30 20 10 0 Pomoc s provozem Bez rozdílu SLA

B1

B2

B3

B4

Obrázek 22 - Průměrná doba řešení požadavků v jednotlivých kategorií služby TP dle SLA

58


Pokud srovnáme tento graf s grafem, ve kterém byl sledován stejný faktor v kapitole Řešení požadavků, srovnání je zobrazeno na grafu (Obrázek 23 - Porovnání doby řešení požadavků ve službě technické podpory), tak můžeme vidět, že průměrná doba řešení požadavků byla ve službě „Technická podpora/Pomoc s provozem“ 75,66 hodin, ve službě „Technická podpora/Dotazy“ 49,7 hodin a ve službě „Technická podpora/Úpravy knihovny SW vzorů“ 60,22 hodin. Po přechodu na proaktivní mód se tyto hodnoty podařilo snížit zhruba o 15% ve v kategorii „pomoc s provozem“, v kategorii „dotazy“ zůstala tato hodnota stejná a v poslední kategorii „úpravy knihovny SW vzorů“ byla snížena o 10%. Největší vliv na toto snížení mělo zavedení větší podpory ze strany konzultantů úrovni L1, kteří pomáhali s řešením jednotlivým problémů. Dalším faktorem, který se podílel na tomto výsledku, byla i zvýšená kvalifikace úrovně L1. Toto srovnání sice nezachycuje příliš velké zlepšení, přesto jsou zákazníci více spokojeni s dodávanými službami. To je způsobeno lepším lidským přístupem, kdy se více dbá na větší komunikaci se zákazníkem. Poté zákazník lépe vnímá situace, kdy trvání trvá déle. Toto tvrzení dokazují i komentáře u vyřešených požadavků: „Rád bych vyzdvihl p.XXX, se kterým jsem řešil několik konkrétních problémů a jsem velice potěšen jeho přístupem, ochotou, profesionalitou a trpělivostí. Velké díky.“ „Profesionalita pracovnikov viac nez len dobra, uroven odbornych znalosti fantasticka a rychlost riesenia poziadavkov bleskova. Radost byt partnerom Alvao.“ „Rychlá a dobrá pomoc panem XXX. Děkuji.“ „Chtěl bych vyzdvihnout ochotu a trpělivost s jakou p. XXX řeší mé uživatelské problémy spojené s ALVAO Asset Managementem.“ „Vynikající komunikace a navedení ke zprovoznění aplikace ServiceDesk.“

Doba řešení požadavků (hodiny)

Porovnání doby řešení 80 70 60 50 40 30 20 10 0

70,444

58,695

46,472

Pomoc s provozem

48,965

Dotazy Před přechodem

60,22

54,32


Po přechodu

Obrázek 23 - Porovnání doby řešení požadavků ve službě technické podpory

59


Následující graf (Obrázek 24 - Počet znovu otevřených požadavků dle jednotlivých kategorií služby TP) je věnován počtu znovuotevřených požadavků v jednotlivých kategoriích. Technická podpora/Dotazy Technická podpora/Chyby v produktu

Technická podpora/Pomoc s provozem Technická podpora/Úpravy knihovny SW produktů

Technická podpora/Zlepšovací návrhy 15 2

1

10 7

7

4

11

5

5 2

1

1 1 1

1.9.2013

1.10.2013 1.11.2013 1.12.2013

3 0

4

1

4

3 1 1

3

3

1

3 1

1

1.1.2014

1.2.2014

2

1 1.3.2014

1.4.2014

1.5.2014

Obrázek 24 - Počet znovu otevřených požadavků dle jednotlivých kategorií služby TP

Pokud tento graf srovnáme se stejným grafem v kapitole Řešení požadavků (Obrázek 25 - Porovnání počtu znovu otevřených požadavků), kde byl průměrný počet znovu otevřených požadavků 14 - 15 měsíčně. Ve sledovaném období tento počet klesnul na 8 požadavků měsíčně. Tento pokles zapříčiněn lépe definovanými procesy ve službě technické podpory, kdy mají řešitelé v této službě jasně definované pracovní postupy, podle kterých postupují.

Porovnání počtu znovu otevření 25 20 15 10

17

20 14

5

13 13

16 10

10

13 12

15

12 4

3

7

18 9 3

0 měsíc1

měsíc2

měsíc3

měsíc4

měsíc5

Před přechodem

měsíc6

měsíc7

měsíc8

měsíc9

Po přechodu

Obrázek 25 - Porovnání počtu znovu otevřených požadavků

60


6.1.4

Zákaznický feedback

Tato podkapitola je věnována analýze dotazníků spokojenosti, které vyplňují žadatelé servisních požadavků. Pozorovaným obdobím byl v tomto případě rok 2013 a první tři měsíce v roce 2014. Výsledky jednotlivých otázek jsou vidět na grafech (Obrázek 26 Zákaznický feedback - rychlost řešení požadavku, Obrázek 27 – Zákaznický feedback – profesionalita pracovníků, Obrázek 28 - Zákaznický feedback – profesionalita pracovníků)

Rychlost řešení požadavku

13

6

nespokojen spíše nespokojen částečně spokojen spokojen

61

Obrázek 26 - Zákaznický feedback - rychlost řešení požadavku

Profesionalita pracovníků

1 5 neúnosná spíše špatná spíše dobrá dobrá 65

Obrázek 27 – Zákaznický feedback – profesionalita pracovníků

61


Odborné znalosti pracovníků

7 nespokojen spíše nespokojen častecne spokojen spokojen 64

Obrázek 28 - Zákaznický feedback – profesionalita pracovníků

Výsledky tohoto průzkumu jsou velmi pozitivní. Největšího zlepšení se podařilo dosáhnout v rychlosti řešení požadavků. Toto porovnání je zobrazeno na grafu (Obrázek 29 - Porovnání spokojenosti s rychlostí řešení), při vytváření tohoto grafu byly odpovědi ohodnoceny známkami 1 – 4, kdy číslo 1 odpovídalo spokojen a číslo 4 odpovědi nespokojen. V kapitole Zákaznický feedback měli zákazníci ve sledovaném období k době řešení jejich požadavků největší výhrady, kdy jich 16 odpovědělo, že je s dobou řešení spokojeno pouze částečně, dva zákazníci byli spíše nespokojeni a jeden dokonce nespokojen. Po implementaci změn se podařilo tento faktor zlepšit, kdy ze 71 respondentů bylo 61 s rychlostí řešení spokojeno, 6 spokojeno částečně, 3 spíše nespokojeni a 1 nespokojen. Zbylé dvě otázky byly zodpovězeni zhruba stejně jako před transformací na proaktivní přístup. V otázkách profesionality a odbornosti neměli zákazníci žádné výhrady k pracovníkům technické podpory. Největší vliv na zlepšení rychlosti zavedení větší podpory ze strany konzultantů úrovni L1, kteří pomáhali s řešením jednotlivým problémů. Dalším faktorem, který se podílel na tomto výsledku, byla i zvýšená kvalifikace úrovně L1.

62


Porovnání spokojenosti s rychlostí řešení 1,6 1,4 1,2 1 Před přechodem

0,8

1,51

0,6

Po přechodu 1,21

0,4 0,2 0 Obrázek 29 - Porovnání spokojenosti s rychlostí řešení

6.2 Další dopady Přechod od reaktivního přístupu k proaktivnímu měl i další dopady, mezi které patří redukce využívání L3 úrovně při poskytování služby technické podpory zákazníkům či zvýšení prodeje dalších služeb.

6.2.1

Redukce zapojení L3 úrovně do služby technické podpory

Odpracované hodiny jednotlivých úrovní ve službě technické podpory po implementaci proaktivního přechodu jsou zachyceny na následujícím grafu (Obrázek 30 Odpracované hodiny jednotlivých úrovní ve službě technické podpory společnosti ALVAO s. r. o.)

63


250

Opracované hodiny

200

18,34 28,39 14,01 14,82 6,44

150 9,98 14,7 2,6

100

25,93 6,29 11,99 14,29

7,99 14,44

13,6 15,53 5,85

116,11

27,71

75,02

7,05

23,49

9,94 15,46

125

104,15

50

12,58 36,57

89,07

70,89

109,55

7,88 9,64 12,25 53,24

26,19 0 září

říjen

listopad L1

prosinec

L2

L3

leden

únor

březen

duben

květen

L3 - bez zlepšováků a chyb

Obrázek 30 - Odpracované hodiny jednotlivých úrovní ve službě technické podpory společnosti ALVAO s. r. o.

Před sledovaným obdobím byla využívána tato úroveň při řešení problémů zákazníků, které nebyly způsobeny chybou v produktech, průměrně 18 hodin měsíčně. Ve sledovaném období to bylo průměrně 11 hodin měsíčně, což je redukce o necelých 40%, což je veliký posun, který je zachycen na grafu (Obrázek 31 - Porovnání využití úrovně L3). Společnost ALVAO s. r. o. tedy zredukovala náklady na dodávku této služby zákazníkům, přičemž byla zároveň zvýšena kvalita této služby, viz předchozí kapitola.

Porovnání využití úrovně L3 40

35,31

35 30 23,36

25 20 15

13,99

14,01

21,12 18,34

16,84 13,6

9,98

12,58

8,93 9,94

10

19,16

7,99 5,08

13,99 7,88

6,29

5 0 měsíc1

měsíc2

měsíc3

měsíc4

měsíc5

L3 před přechodem

měsíc6

měsíc7

měsíc8

měsíc9

L3 po přechodu

Obrázek 31 - Porovnání využití úrovně L3

64


6.2.2

Zvýšení prodeje dalších služeb

Tento bod je věnován srovnání prodeje doplňkových služeb stávajícím zákazníkům společnosti ALVAO s. r. o. Jedná se především o upgrade systémů, prodej modulů do systému, školení produktů či jiné konzultace poskytované pracovníkem ALVAO s. r. o. Sledované období je v tomto případě rok 2012 – květen 2014 (Obrázek 32 - Prodej doplňkových služeb v letech 2012 – 2014). 25000

Poměrová hodnota

20000

15000

10000

19 161,3 16 566,1

15 423,1

2012

2013

5000

0 2014

Obrázek 32 - Prodej doplňkových služeb v letech 2012 – 2014

Hodnoty v grafu jsou vyjádřené poměrem, jelikož si společnost nepřála zveřejnit přesné hodnoty zisku z této aktivity. Z grafu lze vyčíst velké zvýšení prodeje v roce 2014. Jelikož je sledované období v roce 2014 nejkratší (leden - květen), dá se očekávat, že příjmy v roce 2014 budou ještě vyšší a výrazně překročí průměrnou hodnotu z let 2012 a 2013, která se pohybovala okolo hodnoty 16000. Důvody, proč se tak výrazně zvýšil příjem z doplňkových služeb lze hledat za zavedením modulů do systému, nabídkou asistovaných upgrade na verzi 8.0 v místě zákazníka, ať již při osobních návštěvách nebo proaktivním zjišťováním stavu používaných verzí systému. Dalším faktorem, který se na zvýšení podílel, byla uspořádaná konference, na které byla nová verze představena.

65

7 Závěr Tato diplomová práce byla zaměřena na transformaci v poskytování služeb zákazníkům společnosti ALVAO s. r. o. Úkolem bylo provést přechod z reaktivního módu dodávky služeb na proaktivní z cílem dosáhnout zvýšení kvality poskytovaných služeb a zajištění spokojenosti zákazníků s odebíranými službami. V teoretické části byla popsána knihovna ITIL®, která je v současné době jednou z nejvíce používaných metodik pro řízení servisních odděleních v organizacích. Byly popsány jednotlivé etapy při návrhu a provozu služeb, které se staly inspirací pro implementaci proaktivního přístupu. Hlavní část práce je zaměřena na provedení přechodu z reaktivního přístupu na proaktivní ve společnosti ALVAO s. r. o. Nejprve byla provedena analýza stavu před implementací, aby mohly být zjištěny klíčové faktory, které bylo potřeba zlepšit. Po provedení analýzy byly navrženy změny, které by měly přispět ke zlepšení sledovaných faktorů. Všechny návrhy byly konzultovány s vedoucím oddělení služeb, aby se mohl stanovit rozsah těchto změn s ohledem na volné kapacity ve společnosti. Implementace jednotlivých změn trvala delší období, proto u některých faktorů byl brán v potaz delší časový horizont, aby se mohla projevit změna v postoji zákazníků. Po provedení vyhodnocení sledovaných faktorů bylo zjištěno, že se dosáhlo v některých případech výrazného zlepšení. Základní dva cíle – zvýšení kvality služeb a dosažení spokojenosti zákazníků byly naplněny. Jelikož se implementace některých změn provedla pár měsíců před dokončením této práce, nebylo možné sledovat dosažené výsledky. Dalším rozvojem této práce by bylo nadále monitorovat všechny klíčové faktory, aby bylo zjištěno v delším časovém horizontu, zda všechny implementované změny měly pozitivní dopad na poskytování služeb. Dále by mohlo být provedeno srovnání s jiným přístupem v poskytování služeb u jiných společností a poté vyhodnocení klíčových faktorů. Dále by bylo vhodné provést další analýzu stavu po implementaci všech návrhů na změny a zaměřit se na problematická místa a navrhnout další opatření, aby se kvalita dodávaných služeb a spokojenost zákazníka ještě zvýšila.

66

8 Přílohy Dotazník ALVAO Technology Day:

67

PŘÍLOHY

Proces ve službě „Technická podpora/Úpravy knihovny SW vzorů“:

68

PŘÍLOHY

69

PŘÍLOHY

Dashboard: 1) Řešitelé dle termínu

2) Řešitelé dle SLA

70

PŘÍLOHY

Nastavení SLA a upozornění na neřešení požadavků: 1) A1 – kritická chyba v produktu Název SLA: Popis:

Provozní doba: Doba do první reakce: Doba do vyřešení:

A1 - kritická chyba v produktu Chyba způsobuje provozní problémy znemožňující používání produktu, tj.: a) "zhroucení" celého systému nebo jeho části během normálního používání; b) ztrátu nebo porušení dat během normálního používání a současně neexistuje postup pro náhradní řešení problému. 5x8 8 hodin v provozní době nespecifikováno

Upozorňování: Příjemci upozornění Manažeři Manažeři Operátoři Operátoři Řešitel

Neaktivní uživatelé Řešitel Operátoři Řešitel Operátoři Řešitel

Doba neaktivity 16:00 12:00 8:00 2:00 5:00

Opakování

8:00 8:00 8:00

71

PŘÍLOHY

2) B1 - garantovaná nadstandardní TP (TP004) Název SLA: Popis:

Provozní doba: Doba do první reakce: Doba do vyřešení:

B1 - garantovaná nadstandardní TP (TP004) 1. Přijímání námětů na vývoj 2. Řešení chyb v systému 3. Zaslat nerozpoznané softwarové detekce pro aktualizaci knihovny softwarových produktů 4. Možnost stáhnout novou verzi produktu na webu 5. Možnost stáhnout novou verzi knihovny softwarových produktů 6. Možnost telefonického zadávání požadavků 7. Technická podpora produktu v souladu s dokumentací a FAQ 8. Technické konzultace 9. Přístup do Service Desk poskytovatele skrze web 10. Přístup do Znalostní báze Poskytovatele skrze web Garance započetí řešení do 2 pracovních dnů 5x8 16 hodin v provozní době nespecifikováno

Upozorňování: Příjemci upozornění Manažeři Manažeři Operátoři Operátoři Řešitel

Neaktivní uživatelé Řešitel Operátoři Řešitel Operátoři Řešitel

Doba neaktivity 24:00 16:00 12:00 4:00 10:00

Opakování

8:00 8:00 8:00

72

PŘÍLOHY

E-mailové upozornění vytvořené systémem ALVAO Service Desk:

73

PŘÍLOHY

Formulář profylaktické kontroly: Odběratel: Dodavatel:

Protokol profylaktické kontroly Firma 123, s. r. o. ALVAO, spol. s r. o.

Datum: Zapsal:

14. 11. 2013 Jiří Sláma

Seznam účastníků: Za odběratele: Za dodavatele:

David Ostrý Jiří Sláma

Zápis výsledků kontroly: Instalované Verze: Produkt Způsob provádění upgrade ALVAO Admin konzole ALVAO Asset Management ALVAO Monitoring ALVAO Service Desk Verze databáze

Verze Specialisti ALVAO v místě zákazníka / Vzdáleně / Sami + vzdálená podpora 7.0.215 7.0 Nepoužívají 7.0 80

Logy aplikací: Aplikace Collector MailboxReader Monitoring

Množství / závažnost 0 1 – nezdařilý pokus o odeslání jedné emailové zprávy 12 – chyby se zpracováním některých souborů

Asset Management: Kontrolováno Používají aktivně Asset Počet objektů všechny / z toho PC Detekce úspěšné / neúspěšné Stáří poslední detekce Používají SW licence Počet zadaných licencí Odesílá collector data Datum SW knihovny / platnost podpory

Výsledek kontroly ANO – košatý strom, různé objekty 158 / 2745 316 / 28 16. 8. 2013 ANO – provádí i pravidelné audity desítky ANO – email také vyplněn 14. 8. 2013 / 30. 4. 2014

Monitoring: Kontrolováno Počet monitorovaných počítačů

Výsledek kontroly 180

74

PŘÍLOHY

Počet počítačů s daty starší více než 17 měsíc Počet souborů ve složce 0 „Downloaded“ Počet souborů ve složce „Failed“ 7

Service Desk: Kontrolováno Počet uživatelů / požadavků Počet neodeslaných emailů Počet služeb v katalogu Popisy služeb, ikony portálu

Výsledek kontroly 154 / 3890 17 1 – používají pouze HelpDesk NE / ANO

Portály + IIS: Kontrolováno Používané portály Kontrola oprávnění Kontrola AppPool

Zápis Pouze SD, AM nechtějí pustit mezi lidi, MON nemají Nastaveno správně (Windows ověření) Špatně nastaven recyklační čas

Další kontrola: Kontrola oprávnění na SQL – někteří lidé mají problém s přihlášením Kontrola velikosti DB – Zálohy DB jsou neúměrně veliké

Během kontroly bylo ihned opraveno: Někteří uživatelé neměli přístup do DB, přidání oprávnění dle zadání Administrátora Proveden shrink DB a files – databáze se zmenšila z 11GB na 6,4GB Oprava času recyklace u AppPoolu

Doporučení: Během kontroly byla zjištěna stará verze. Doporučuji provést upgrade na nejnovější verzi.

75

PŘÍLOHY

76

Literatura [1] Omnicom s.r.o., „http://www.itsmportal.cz/cs/-ITSM-ITIL-/-Co-je-to-ITSM.alej,“ Omnicom s.r.o.. [Online]. [Přístup získán 17 únor 2014]. [2] M. Bucksteeg, N. Ebel, F. Eggert, J. Meier a B. Zurhausen, ITIL 2011, Stručný a srozumitelný výklad, Brno: Computer Press, 2012. [3] „ITIL® – výkladový slovník a zkratky v češtině [online]. v1.1.,“ 6 Leden 2012. [Online].

Available:

http://www.itil-

officialsite.com/InternationalActivities/ITILGlossaries_2.aspx. [4] ITIL®: Service Design, London: Stationery Office, 2011. [5] ITIL®: Service Transition, London: Stationery Office, 2011. [6] ITIL®: Continual Service Improvement, London: Stationery Office, 2011. [7] ITIL®: Service Operation, London: Stationery Office, 2011. [8] ITIL®: Service Strategy, London: Stationery Office, 2011. [9] ITIL®: Service Continual Improvement, London: Stationery Office, 2011. [10] C. R. I. M. J. W. S. R. a. A. C. Ashley HANNA, Úvodní přehled ITIL® V3, itSMF Czech Republic, o.s. s laskavou pomocí firmy Hewlett-Packard, s.r.o., 2007.

77

Zavedení proaktivního přístupu v poskytování služeb zákazníkům do organizace

Recommend Documents