Co přesně je tedy plnění žádostí? Plnění žádostí poskytuje uživatelům kanál, skrze který můžou žádat a čerpat standardní služby, ke kterým existuje předem definovaný proces schvalování a třídění. Jeho smyslem je zajistit, abychom při každé nové žádosti nemuseli „znovu vynalézat kolo“. Model žádostí je potom způsob, jak dopředu určit kroky, které musíme podniknout, abychom daný proces správně řídili. Jak to vypadá v praxi?

Položit správné základy

Nejprve potřebujete vytvořit katalog žádostí o službu (service request catalog). Ve své nejzákladnější podobě se jedná o seznam všech žádostí o službu, které byznys může vznést na IT oddělení.

Nejjednodušší způsob, jak toto udělat, je zeptat se přímo řešitelů na service desku poté, co stráví celý den řešením právě takových požadavků. Poproste je, aby sepsali list nejčastějších žádostí o službu. Ten poslouží jako výchozí bod pro přetvoření záznamů v katalogu žádostí o službu do plně zmapovaného a automatizovaného modelu žádostí.

Druhá klíčová věc, kterou musíte udělat, je odlišit incidenty od žádostí v ITSM nástroji. Konec konců, jedná se o dvě odlišné věci! Když řeknete lidem z byznysu, že na service desk přišlo 10 000 incidentů, zní to jako konec světa. Říct jim, že jste obdrželi 1 000 hlášených incidentů a 9 000 žádostí o novou výbavu, to už je úplně jiný příběh.

Postavte model žádostí

Bez toho se prostě neobejdete. Proces plnění žádostí bez modelu žádostí je jen takové pohrávání si. Celý smysl procesu plnění žádostí je v tom, znát dopředu všechny nutné kroky; informace, které budete muset sbírat a kdy je budete sbírat; kdo reálně vykonává požadované akce a autorizace. Tohle je duší a centrem plnění žádostí. Sbírat všechny tyto informace, aniž bychom je transformovali do modelu (může se jednat o stanovenou manuální proceduru nebo ideálně automatizaci přímo v ITSM nástroji) je prostě hloupé.

Nechte je povídat o aktivitách zahrnutých v plnění žádosti. Můžete využít lepicí papírky, abyste si základní flow procesu vizualizovali na stěně. Jakmile odsouhlasíte všechny kroky a jejich pořadí, vraťte se zpět k detailům: co se děje během každého kroku; kdo krok vykonává; jakou informaci potřebuje, aby krok splnil; jaké jsou dohodnuté termíny či nutné autorizace, atd. Z mé zkušenosti tento proces zabere zhruba půl dne u středně složitých žádostí, jako je sestavení a dodání počítače nováčkům. Jakmile je model hotový, zdokumentujte jej ve formálním dokumentu a následně jej použijte, abyste nakonfigurovali zvolené ITSM nástroje k automatizaci žádosti.

Plnění žádostí je jednoduché, nikoliv snadné

Hodně lidí udělá chybu, kdy podlehnou klamnému dojmu, že „dělat“ proces plnění žádostí nezabere více než týden či dva. Řekněme ale, že máte 800+ známých typů žádostí o službu. Zlaté pravidlo je vyhradit si půl dne na zmapování modelu žádosti. Vypracujeme všechny kroky, a kdo je vykonává. Dále potřebujeme dalšího půl dne, abychom toto zdokumentovali ve formátu, který můžeme uložit, je srozumitelný a lze jej sdílet s ostatními. Následně přidejte ještě půl dne, abychom postup zanesli do nástroje. Ze dvou týdnů se rázem stane 1 200 dní práce!

Nejlepší rada, jakou mohu dát, je vybrat si pro začátek nějakou srozumitelnou a nepříliš složitou žádost. Když začnete něčím jednodušším, získáte v postupu větší jistotu. Až si to celé zažijete, můžete se vrhnout i na složitější procesy, jako je nástup nového zaměstnance.

Nejvýstřednější chyba ve vztahu k plnění žádostí, jakou jsem kdy zažil, bylo, když jeden CIO slíbil lidem z výkonné rady, že 95 % všech žádostí o službu vyřídí do pěti dnů. Postačí k tomu říci, že jsem málem spadl ze židle. Nakonec jsem ho po schůzce tiše a nenápadně vzal stranou a řekl, že jim právě dal velmi odvážný slib… vadilo by mu, kdybych se ho zeptal na pár otázek?

Odešel jsem a vytvořil model žádosti pro tento proces. Ukázalo se, že sestavení laptopu vyžaduje 37 různých kroků napříč čtyřmi týmy a zahrnuje rovněž dvě externí organizace, které měly vlastní smluvně danou dobu odezvy. Kdyby vše šlo podle plánu, trvalo by 10 dní dokončit celý cyklus. Tento CIO v podstatě připravil půdu pro vlastní pád a na výkonné radě dostával zabrat dalších 6 měsíců, kdykoliv se objevil na schůzi.

Ponaučení z tohoto příběhu? Rozumějte všem krokům a termínům zahrnutým v procesu, než se zavážete k cílům SLA.

Výhody plnění žádostí

Vždycky lidem říkám „nehlídejte si sami svůj pozemek, když jste si k tomu koupili psa“. Většina ITSM nástrojů je postavená na výborných workflow základech s příslušnými pravidly pro upozorňování. A … nečekaně … stejně tak funguje plnění žádostí. Jednou vypracujete, co obsahuje konkrétní žádost, kdo je za ni zodpovědný, co by měl dělat, atd. Následně tuto těžko nabytou informaci vezmete a nahrajete do nástroje jako model žádosti. Od té chvíle dělá nástroj těžkou práci za nás. Pomůže nám přesunout žádost správnému týmu. Zajistí, že tým dostane všechny podstatné informace na stříbrném podnose, a dokonce upozorní příslušné autority, pokud porušíme nastavená kritéria.

Někdo musí dělat všechny věci, které jsem tu popsal. A pokud nemáte nástroj, který je bude dělat (podpořený vašimi procesy, samozřejmě), potom to vaši řešitelé na service desku musí dělat ručně, což vede pouze k tomu, že za chvíli máte řešitele, který se ručně stará o žádosti a vysvětluje naštvaným uživatelům, proč jejich laptop ještě není nachystaný. Pokud používáte proces plnění žádosti, většinu této práce za vás udělá nástroj díky modelu žádosti. Přesto se vždy ujistěte, že finální vlastnictví žádostí patří service desku. Důvěřuj, ale prověřuj.

Poznámka na závěr

Postavte se k plnění žádostí čelem. Řešit plnění žádostí ručně významně vyčerpává vaše zdroje na service desku a zároveň je to největší příčina nespokojenosti zákazníků.

Můžete buď řešit každou věc jednu po jedné, tak jak se objeví, nebo můžete investovat nějaký počáteční čas k identifikaci 10 nejčastějších žádostí, které přistávají na service desku, a vytvořit z nich modely žádostí. Následně je zpracujete v nástroji, automatizujete notifikace a pravidla pro rozřazování.

Proces plnění žádostí uvolní ruce vašemu service desku a zachrání řešitelům čas, takže nemusí bloudit v kruhu ve snaze zjistit, jaký je další krok v řadě a s kým by o něm měli promluvit. Automatizováním základních věcí uvolníte tým k tomu, aby se mohl zaměřit na důležitější oblasti.

Peter Hubbard Autor článku je jedním z hlavních konzultantů prestižní společnosti Pink Elephant. Má za sebou dvacetileté zkušenosti na poli IT Service Management ve firmách, jako je Rolls Royce, Heinz nebo British Petroleum. Pravidelně přednáší na významných oborových konferencích a letos bude hlavním řečníkem na ALVAO Inspiration Day v Praze 17. 5. 2018.