By Ondek, 10 May, 2024

ITSM.express

Verzia 1.1, 18. apríla 2024

Autorský tím

Projektový manažér

Štefan Ondek

Autori

Johann Botha
Etienne Shardlow
Dolf van der Haven

Recenzenti

Suzanne van Hove
Wim Hoving

Prekladatelia do slovenčiny

Marian Bartko
Juraj Fendrich

Odborný a jazykový korektor slovenského prekladu

Štefan Ondek

Prehlásenie o vylúčení zodpovednosti

Uznávame, že existujú mnohé pohľady na riadenie služieb – ide o „riadenie IT služieb“ alebo len o „riadenie služieb“? Alebo o niečo iné? Aby sme zodpovedali túto otázku, v zmysle tohto dokumentu, musíme sa spýtať: „Ktorá služba nie založená na nejakej forme technológie?“ Odpoveď na takúto otázku je jednoduchá – v súčasnosti neexistuje služba nevyužívajúca istú formu technológie, digitálnych informácií atď.. Preto, ako naznačuje už náš názov, hovoríme o riadení IT služieb, ale všetci uznávame, že informácie obsiahnuté v tomto dokumente sú aplikovateľné aj aj mimo vertikály „technologické“/„digitálne“.

Preto naša definícia riadenia služieb zahŕňa všetky spôsobilosti, procesy a štruktúru organizácie podporujúce aktivity jej personálu na dodávanie služieb počas celého ich životného cyklu s cieľom poskytovať hodnotu svojim zákazníkom a samotnej organizácii.

Riadenie IT služieb (angl. IT service management – ITSM) je podmnožinou riadenia služieb zameranou na služby primárne pozostávajúce z informačno‑technologických prvkov.

Pre jednoduchšie čítanie (a písanie) budeme používať pojem „riadenie služieb“ a naše príklady/ diskusie sa zamerajú na technický podnik (inštitúciu).

Úvod

Tento dokument je minimalistická, bezplatná príručka pokrývajúca úplné základy riadenia služieb. Je zámerne napísaná tak, aby sa ju bolo možné ľahko naučiť, aplikovať a vyučovať. Príručka je určená predovšetkým pre ľudí a organizácie, ktoré sú na počiatku svojej cesty v oblasti riadenia služieb, implementujú nový systém riadenia služieb alebo vylepšujú existujúci. Príručka sa neodvoláva na existujúce komerčné rámce (frameworks) – jediné externé odkazy sú na štandardy (normy). Je to tak preto, aby táto príručka mohla byť bezplatná a dostupná pre každého, kto sa zaujíma o riadenie služieb.

Obsah, aj keď minimalistický, je v súlade s normou ISO/IEC 20000-1:2018. Zatiaľ čo ISO/IEC 20000-1 a väčšina iných systémov riadenia (IT) služieb nakladajú s jednotlivými akciami na poli riadenia služieb nezávisle, táto príručka ukazuje, ako vytvoriť efektívny systém riadenia služieb a to prostredníctvom štyroch hlavných akcií riadenia služieb: Definujte, Vyhotovte, Poskytujte a Odpovedajte.

Túto príručku napísali veteráni a špičkoví odborníci z odvetvia: Johann Botha, Dolf van der Haven, Etienne Shardlow a zrevidovali Suzanne Van Hove a Wim Hoving. Redaktorom a „otcom myšlienky“ je Štefan Ondek, ostrieľaný školiteľ, konzultant a odborník v oblastiach projektového riadenia i riadenia služieb. Všetci menovaní vykonali všetku prácu na tejto príručke ako dobrovoľníci, bez akejkoľvek odmeny. Patrí im za to veľká vďaka.

Vlastníkom práv duševného vlastníctva je nezisková organizácia ITSM.express registrovaná na Slovensku. Táto príručka je vydaná pod licenciou Creative Commons Attribution. Môžete ju slobodne:

Zdieľať (Share) — kopírovať a redistribuovať príručku v akomkoľvek formáte, prostredníctvom akéhokoľvek média na akýkoľvek účel, vrátane komerčného.
Prispôsobovať (Adapt) — remixovať, transformovať a upravovať príručku na akýkoľvek účel, vrátane komerčného.
Vlastník licencie nesmie obmedziť vyššie uvedené slobody, pokiaľ dodržiavate licenčné podmienky.

Za dodržania nasledovných podmienok:

Uvedenie zdroja (Attribution) — Musíte uviesť zdroj, poskytnúť link na licenciu a uviesť, či boli vykonané zmeny. Môžete to urobiť akýmkoľvek primeraným spôsobom, ale nie spôsobom, ktorý by naznačoval, že poskytovateľ licencie podporuje vás alebo váš spôsob použitia.

Žiadne dodatočné obmedzenia — nesmiete aplikovať právne podmienky alebo technologické opatrenia, ktoré by právne obmedzovali iných (tretie strany) robiť čokoľvek, čo licencia povoľuje.

Neposkytujú sa žiadne záruky na akékoľvek použitie alebo aplikáciu tejto príručky. Použite váš vlastný úsudok.

Obsah

Autorský tím.. 2

Prehlásenie o vylúčení zodpovednosti 3

Ďalšie informácie. 10

Ďalšie informácie. 13

Interakcia so spotrebiteľom.. 13

Ďalšie informácie. 16

Vyhotovte. 17

Vybudujte. 17

Návrh služby (service design) 17

Podmienky používania. 17

Analýza potrieb. 18

Vybudovať alebo kúpiť 19

Služby zahŕňajúce viacerých dodávateľov. 19

Monitorovanie služby. 19

Agregácia služieb. 19

Riadenie uvoľňovania a nasadzovania (release and deployment management) 23

Chráňte – informačná bezpečnosť 26

Ciele. 26

Proces. 26

Ovládanie prístupu. 27

Meranie výsledkov. 33

Riešenie požiadaviek (queries) 34

Proces odpovedania. 34

Definujte

Etapa definovania zahŕňa návrh služby vrátane základných organizačných procesov ako dozor („governance“) a riadenie rizík. Tu sa kladú základy pre systém riadenia podporujúci životný cyklus služby.

Dozor (Governance)

Ciele

Dozor („governance“) je funkcia, ktorá poskytuje organizácii usmernenie vo forme smerníc, politík a všeobecného dohľadu nad celkovým fungovaním organizácie. Má na zreteli ciele organizácie z hľadiska biznis výsledkov ako ziskovosť, skúsenosti zákazníkov a zamestnancov a dodržiavanie platných zákonov i predpisov.

Podľa noriem ako ISO 37000 (Dozorovanie organizácií) a ISO/IEC 38500 (Dozorovanie IT) je v organizácii, ktorá vykonáva tieto funkcie, hlavným útvarom „dozorný orgán“ („governing body“), napríklad predstavenstvo alebo inak relatívne nezávislá osoba či skupina na vrchole organizácie. V praxi by však dozor mal byť vykonávaný na každej úrovni riadenia organizácie vhodným vedením (líderstvom), primeraným rozsahu zodpovedností danej úrovne riadenia.

Prínosy

Dobrý dozor („governance“) je rozhodujúci pre chod akejkoľvek organizácie vrátane poskytovateľov služieb. Prínosy sú nasledovné:

lepší dohľad nad výkonnosťou organizácie ako celku
zodpovednosť na všetkých úrovniach organizácie za jej prevádzkovú a strategickú výkonnosť
jasnosť obchodného smerovania organizácie
lepšia informovanosť zamestnancov o relevantnosti ich aktivít v širšom kontexte účelu organizácie
zlepšené rozhodovanie založené na pozorovaní relevantných informácií.

Kľúčové koncepty

Dobrý dozor („governance“) je založený na niekoľkých zásadách, ktoré si každá organizácia môže stanoviť sama, ale pravdepodobne sú podobné jednej alebo viacerým z nasledujúcich:

účel pre organizáciu
vytváranie hodnoty pre organizáciu a jej spotrebiteľov
ustanovenie stratégie pre organizáciu
poskytovanie dohľadu nad činnosťou organizácie
angažovanie zainteresovaných strán ako spotrebitelia, zamestnanci, verejná správa
riadenie rizika
zameranie na udržateľnosť.

Proces

Vyššie uvedené zásady a prípadne i ďalšie zásady poskytujú východiskový bod pre budovanie organizačnej funkcie dozoru („governance“). Praktické činnosti založené na týchto zásadách sú tieto:

Určite poslanie a víziu organizácie: Čo chce organizácia dosiahnuť? Ako to chcete urobiť?
Ktoré faktory ovplyvňujú činnosť organizácie, interné aj externé? Zamyslite sa nad súčasnými požiadavkami spotrebiteľov, legislatívou, cieľmi udržateľnosti, dostupnosťou zdrojov a celkovými silnými i slabými stránkami organizácie.
Kto sú zainteresované strany v aktivitách organizácie? Sú tu zamestnanci a manažéri samotnej organizácie, ale aj spotrebitelia, verejná správa, možno aj médiá a akcionári, ktorí sa zaujímajú o to, aké výkony organizácia podáva a ako je úspešná.

V norme ISO/IEC 38500:2024 existuje jednoduchý model stanovujúci, ktoré aktivity sa majú vykonávať v rámci riadiacej funkcie. Sú to tieto, skrátene EDMS (Evaluate, Direct, Monitor, Stakeholder Engagement):

Vyhodnocujte (Evaluate): Posudzujte, ako sa organizácii darí, na základe zásad uvedených vyššie.
Usmerňujte(Direct): Usmerňujte organizáciu, aby zmenila svoje činnosti, ak sa to považuje za potrebné na základe hodnotenia vykonaného v predchádzajúcom kroku.
Monitorujte (Monitor): Monitorujte, ako organizácia funguje na základe ukazovateľov sú kľúčové ukazovatele výkonnosti (KPI), kľúčové ukazovatele rizika (KRI) alebo iné.
Angažujte zainteresované strany (Stakeholder Engagement): poskytujte dostatočnú komunikáciu o tom, o čo dozor („governance“) chce, rôznym interným a externým zainteresovaným stranám, aby dozorovaná organizácia vedela, čo má robiť na operatívnej úrovni.

Tieto štyri aktivity sa veľmi ľahko implementujú ako zodpovednosti všetkých úrovní riadenia v organizácii. Centrálna riadiaca funkcia, ako je predstavenstvo, by mala vykonávať všetky štyri aktivity pre organizáciu ako celok, aby jej podriadení manažéri mali potrebné usmernenia na implementáciu obdržaného smerovania v prevádzke organizácie. Líder tímu zamestnancov by však mal robiť to isté na svojej vlastnej úrovni: vyhodnocovať výkonnosť tímu, usmerňovať tím v tom, čo je potrebné urobiť na zlepšenie dosahovania jeho cieľov, monitorovať, ako sa tímu darí na základe zavedených KPI a často komunikovať o danom smerovaní a výkonnosti tímu.

Manažéri v organizácii preto nosia dva klobúky: na jednej strane musia uvádzať do praxe (dozorom určené) smerovanie, ktoré dostávajú „zhora“. Na druhej strane musia sami poskytovať dozorné usmernenia tímu alebo časti organizácie, ktorá im podlieha. Toto rozdelenie medzi dozor (aktivity EDMS) a manažment (prenášanie dozorných usmernení do prevádzkovej praxe) sa niekedy preháňa, ale v skutočnosti sú dozor a riadenie integrovaným celkom pre každú úroveň riadenia v organizácii.

V praxi existuje dokonca aj tretí „klobúk“, ktorý manažéri nosia. Je to ten, ktorý vyžaduje, aby riadili nahor: je to „monitorovacia“ funkcia governance, ktorá poskytuje prehľad vyššej úrovni riadenia, ktorá môže na základe tohto vyhodnocovať výkonnosť organizácie pod sebou a podľa potreby poskytnúť nové smerovanie.

Bežné úskalia

Bežné problémy týkajúce sa dozoru zahŕňajú:

„Dozor“ nie je „vláda“ – vláda je politická entita na rôznych úrovniach spoločnosti, ktorá vedie ľudí v rámci svojich kompetencií a určuje politické smerovanie. Dozor, aj keď má s vládou podobné činnosti, je funkciou na rôznych úrovniach v podniku alebo v organizácii, ale nemá žiadne politické záujmy.
Dozor nie je obmedzený len na radu dozoru („Governance Board“) na vrchole organizácie. V skutočnosti by sa mal v organizácii vykonávať na každej úrovni riadenia.
Aktivity v oblasti dozoru a manažmentu nie sú jasne oddelené. Malo by sa jasne rozlišovať medzi strategickými aktivitami dozoru (Evaluate, Direct, Monitor, Communicate) a riadiacimi aktivitami, ktoré sú potrebné na uvedenie prijatých usmernení do praxe v organizácii.
Dozor sa nesprávne interpretuje ako harmonogram stretnutí medzi rôznymi zainteresovanými stranami. S dozorom sú spojené jasné ciele a aktivity, ako je opísané vyššie. Je zrejmé, že si vyžaduje určité stretnutia, ale ich účel musí byť jasný účastníkom, ktorí majú zodpovednosť za dozor.

Ďalšie informácie

Ďalšie informácie ohľadne vstupov a dodávok dozoru nájdete na webovej stránke ITSM.express.

Riadenie rizík

Ciele

Riziko možno definovať ako akúkoľvek neistotu, ktorá môže ovplyvniť ciele organizácie. Tieto neistoty môžu byť pozitívne alebo negatívne. Pozitívne riziko je niečo, čo môže stimulovať dosiahnutie cieľov, a preto sa označuje aj ako „príležitosť“, ktorú organizácia môže chcieť dosiahnuť. Negatívne riziko je niečo, čo ľudia zvyčajne považujú riziká: prekážka brániaca dosahovaniu cieľov organizácie, ktorej by sme sa mali vyhnúť alebo ju aspoň minimalizovať. Oba typy rizík sú relevantné pre riadenie rizík. Riziká sú dôležitou súčasťou vstupov pre dozornú funkciu na všetkých úrovniach organizácie. Aj riadenie rizík by sa preto malo vykonávať na všetkých úrovniach organizácie. Riadenie rizík je súčasťou mnohých ďalších oblastí riadenia služieb, vrátane riadenia informačnej bezpečnosti, riadenia kapacít a ďalších procesov.

Normou pre riadenie rizík je ISO 31000 (Riadenie rizík), s ktorou je táto časť príručky vo všeobecnosti zosúladená.

Prínosy

Riadenie rizík je podobne ako dozor základnou praktikou riadenia organizácie. Prínosy vykonávania riadenia rizík sú nasledovné:

včasné varovanie pred možnými hrozbami a zraniteľnosťami
možnosť zasiahnuť, ak sa riziká naplnia, zavedením účinných ovládačov
jasný prehľad o hrozbách
vytvorenie povedomia v celej organizácii o tom, čo môže stáť v ceste dosahovaniu biznis výsledkov.

Kľúčové koncepty

Riziká sú potenciálne udalosti, ktoré môžu mať vplyv na organizáciu rôznymi spôsobmi: môžu existovať riziká súvisiace s udržiavaním informácií o organizácii alebo jej zákazníkoch v bezpečí (riziká informačnej bezpečnosti), riziká prevádzkovej výkonnosti organizácie (schopnosť organizácie plniť svoje KPI), riziká nedodržiavania externých predpisov, ako sú zákony o ochrane súkromia alebo iné predpisy (riziká súladu) alebo riziká súvisiace s externými dodávateľmi (riziká tretích strán). Pri riadení rizík je možné všetko, ale je potrebné určiť, aké závažné je riziko v skutočnosti.

Riziko sa zvyčajne klasifikuje na základe dvoch jeho aspektov: pravdepodobnosti, že sa riziko skutočne vyskytuje v praxi (napr. na stupnici od 1 do 5) a ak sa vyskytne, dopadu, ktorý by malo na organizáciu (napr. na stupnici od 1 do 5). Po určení pravdepodobnosti a dopadu môžete vypočítať úroveň rizika tak, že použijete súčin:

Úroveň rizika = pravdepodobnosť x dopad

Táto úroveň rizika slúži ako celkový ukazovateľ závažnosti rizika.

Proces

Riadenie rizík, ako je definované v norme ISO 31000, má niekoľko fáz:

Posúdenie rizík je fáza, v ktorej sa vykonávajú tieto tri kroky:
1. Identifikácia rizík: Na základe rozsahu procesu riadenia rizík, kontextu organizácie a kritérií toho, čo sa považuje za prijateľné, sa identifikujú riziká. V tejto fáze identifikácia pozostáva z určenia hrozieb, ktoré môžu mať vplyv na zraniteľnosti v organizácii.
2. Analýza rizík: Hrozby a zraniteľnosti identifikované v predchádzajúcom kroku analyzujú ľudia v organizácii, ktorí majú schopnosť určiť potenciálny dopad rizika, ak sa naplní (materializuje) a pravdepodobnosť, že sa riziko skutočne naplní (materializuje). To vedie k úrovni rizika uvedenej vyššie.
3. Vyhodnotenie rizík: Na základe úrovní rizík, ktorá bola zistená počas analýzy rizika, by sa malo určiť, aké akcie je potrebné prijať.

Akcie na zmiernenie rizika vo veľkej miere závisia od povahy rizika, ale spadajú do nasledovných troch hlavných kategórií:

Ošetrite riziko: V tomto prípade sa rozhodnete prijať opatrenia na zníženie pravdepodobnosti rizika alebo jeho dopadu alebo oboch. Prijaté opatrenie je známe ako zavedenie ovládača. Ovládač je administratívne (napíšte a implementujte proces alebo politiku), technické (implementujte firewall) alebo fyzické (pridajte zámky na dvere) opatrenie, ktoré znižuje pravdepodobnosť alebo dopad rizika.
Prijmite riziko: Môžete sa rozhodnúť, že úroveň rizika nie je dostatočne vysoká na to, aby oprávňovala vynaložiť čas alebo peniaze na jeho ošetrenie. Inými slovami, riziko je na prijateľnej úrovni. Jedná sa o rozhodnutie, ktoré by sa nemalo brať na ľahkú váhu: iba náležitá úroveň riadenia má byť oprávnená akceptovať riziká podľa jej zverených právomocí a len do určitej povolenej úrovne rizika. Napríklad to môže byť zásada, že akceptované môže byť iba riziko po strednú úroveň a len tou úrovňou riadenia, ktorá je zodpovedná za časť organizácie ovplyvnenú rizikom. Táto prijateľná úroveň rizika je známa ako ochota riskovať (risk appetite).
Preneste riziko: Ak je riziko takej povahy, že zodpovedná za prijatie opatrení na jeho ošetrenie je zodpovedný iný tím, iná časť organizácie alebo dokonca externá strana, riziko sa môže preniesť na túto entitu. Prenesenie zahŕňa kontaktovanie druhej strany, vysvetlenie rizika, vášho posúdenia daného rizika a získanie potvrdenia druhej strany, že ona je zodpovedná za ošetrenie daného rizika. Druhá strana sa potom môže sama rozhodnúť, či si myslí, že je potrebné ošetriť riziko alebo nie. V každom prípade, ak riziko skutočne nastane (materializuje sa), je to druhá strana, ktorá je zodpovedná za vplyv takejto udalosti na organizáciu. Ak napríklad identifikujete riziko, že neoprávnení zamestnanci môžu vstúpiť do vyhradených priestorov v budove, ako napríklad dátové centrum, môžete toto riziko preniesť na skupinu v organizácii, ktorá je zodpovedná za fyzickú bezpečnosť zariadení. Táto skupina by potom mala prijať vlastníctvo rizika a určiť, či musia prijať opatrenia na zabezpečenie vyhradenej oblasti.
Využite riziko: V prípade pozitívnych rizík (príležitostí) môže organizácia chcieť riziko využiť, čo znamená, že výskyt rizika by mal byť stimulovaný, aby sme získali pozitívny vplyv rizika. Možno to urobiť napríklad vtedy, keď sa očakáva, že sa zlepšia finančné podmienky ako napr. daňové predpisy alebo ceny energií, čím sa zlacní poskytovanie služieb a tým sa zlepší trhová pozícia poskytovateľa služieb.

Ak sa riziko ošetrí, čo znamená, že sa zavedie určitá forma ovládačov, pravdepodobnosť a/ alebo dopad rizika by mal byť nižší ako pôvodná pravdepodobnosť a/alebo dopad. Výsledkom je nová úroveň rizika, opäť vypočítaná ako pravdepodobnosť x dopad, ktorá je známa ako reziduálne riziko. Reziduálne riziko je akékoľvek riziko, ktoré zostane po zavedení ovládača. Ovládač často znižuje úroveň rizika len do určitého bodu, ale neodstraňuje dané riziko úplne. Reziduálne riziko je ukazovateľom toho, aké riziko zostáva po jeho ošetrení a malo by byť pod prijateľnou úrovňou rizika (t. j. ochotou riskovať). Ak je reziduálne riziko stále vyššie ako ochota riskovať, môže byť potrebné zaviesť dodatočné ovládače na dostatočné zníženie úrovne rizika.

Bežné úskalia

Riadenie rizík sa zanedbáva. Vďaka zavedeniu praktického a jednoduchého rámca riadenia rizík nemusí byť riadenie rizík ťažkopádne, ale môže byť integrované do každodennej prevádzky organizácie.
Príliš veľa rizík sa skôr akceptuje ako ošetruje. Je to znak lenivých vlastníkov rizík – namiesto toho, aby analyzovali riziká a zaviedli ovládače, idú do daného rizika a ignorujú jeho možný vplyv na biznis výsledky organizácie.
Účinnosť obvládačov rizík sa pravidelne nekontroluje. Keď sa zavedie ovládač na ošetrenie rizika, jeho účinnosť sa musí pravidelne kontrolovať, pretože hrozby sa môžu zmeniť a nakoniec prelomiť dané ovládače. Ovládače bude možno potrebné posilniť alebo nahradiť inými, aby ostali účinné.
Osoba, ktorá riziko označí, ho automaticky vlastní. Zodpovednosť za riziko by mala niesť osoba, ktorá je v najlepšej pozícii sa s ním vysporiadať, čo nemusí byť nevyhnutne osoba, ktorá ho označila ako prvá. Postoj „dotkni sa toho a vlastníš to“ v organizácii odradí ľudí od upozorňovania na riziká v budúcnosti.

Ďalšie informácie

Ďalšie podrobnosti o konceptoch a praktikách riadenia rizík nájdete na webovej stránke ITSM.express.

Interakcia so spotrebiteľom

Ciele

Služba je vyvinutá na to, aby ju používali koncoví používatelia alebo spotrebitelia. Je možné vyvinúť službu bez interakcie so spotrebiteľmi, ale to vytvorí službu, ktorá pre nich nemusí byť zaujímavá, a preto sa nepoužíva. Interakcia so spotrebiteľmi má prebiehať od prvotného okamihu vývoja služby až do momentu jej vyradenia.

Prínosy

Prínosy interakcie so spotrebiteľom sú nasledovné:

lepšie pochopenie toho, čo spotrebitelia služieb potrebujú, aby dosiahli svoje biznis výsledky
pravidelné overovanie skúseností spotrebiteľov a ich spokojnosti so službou, aby sa služba mohla v prípade potreby zlepšovať
pravidelné spravodajstvo pre spotrebiteľov o výkonnosti služby, aby bolo možné overiť, či služba funguje podľa očakávaní a dohodnutých podmienok
usmernenia pre rozvoj služby s cieľom zabezpečiť, že spĺňa potreby spotrebiteľov.

Kľúčové koncepty

Spotrebitelia sa zriedka zaujímajú o službu kvôli službe samotnej. Zvyčajne chcú službu využiť na dosiahnutie svojich cieľov. Spotrebitelia odvodzujú hodnotu od používania vašej služby na dosiahnutie svojich vlastných výsledkov. Táto spotrebiteľská hodnota môže byť niečo úplne odlišné od hodnoty, ktorú od služby odvodzujete vy ako poskytovateľ služieb. Vašou hodnotou môže byť získanie výnosov, spokojných zákazníkov, podielu na trhu alebo podpora širších biznis výsledkov vašej spoločnosti. Spotrebiteľ služby zvyčajne vidí službu ako umožňovateľ jeho vlastných výsledkov ako napr. schopnosť odosielať a prijímať e-maily, spracovávať dáta, riešiť finančné transakcie.

Prvým krokom pri interakcii s (potenciálnymi alebo existujúcimi) spotrebiteľmi vašej služby je zistiť, čo považujú za hodnotu služby oni. To je veľmi základná otázka, ale je aj najdôležitejšia, ak chcete dosiahnuť, aby spotrebitelia vašu službu používali. Z vyjadrenia hodnoty vyplývajú požiadavky na službu, ako aj základ pre vytváranie vzťahov so spotrebiteľmi.

Proces

Z vyššie uvedenej definície hodnoty pre spotrebiteľov môžete odvodiť ich požiadavky na službu, ktorú poskytujete. Aké aspekty e‑mailovej služby potrebujú na čo najefektívnejšie vykonávanie svojej práce (napríklad zdieľané poštové schránky, časované odosielanie atď.)? Ktoré aspekty finančnej služby potrebujú na dosiahnutie svojich biznis výsledkov (napríklad mzdy, účtovníctvo atď.)?

Rôzni spotrebitelia majú rôzne požiadavky. Má zmysel zhromaždiť zoznam skutočných a potenciálnych požiadaviek na vaše služby a priorizovať ich na základe toho, čo potrebuje väčšina spotrebiteľov a čo je dosiahnuteľné za určitý čas. Väčšina spotrebiteľov má súbor spoločných požiadaviek na služby. Tieto požiadavky by sa mali považovať za súčasť základnej služby. Existujú aj požiadavky, ktoré rozširujú základnú službu a pridávajú funkcie, z ktorých má prospech veľká skupina spotrebiteľov: tieto môžu byť najprv považované za „prémiovú“ funkčnosť alebo môžu byť uvedené v cestovnej mape (roadmap) rozvoja služby pre vývoj v blízkej budúcnosti. Treťou kategóriou požiadaviek sú úplne špecifické (individuálne) požiadavky, ktoré sa vzťahujú len na jedného alebo niekoľkých spotrebiteľov. U týchto požiadaviek treba zvážiť, či stojí za to vyvinúť službu plne na mieru len pre niekoľkých spotrebiteľov. Záleží na vašom vlastnom biznis modeli, či sa chcete zamerať primárne na štandardné služby alebo máte flexibilitu prispôsobovať ich.

Požiadavky spotrebiteľov, ako aj vaše vlastné, interne zhromaždené požiadavky sa premietajú do procesu vývoja služieb. Tento proces preberáme ďalej v tejto knihe v sekcii Vyhotovte.

Vzťahy so spotrebiteľmi služby sa nekončia, keď zhromaždíte požiadavky a predáte alebo poskytnete službu. Spotrebitelia musia byť zapojení do každého kroku cesty, aby mohli dať svoju spätnú väzbu o službe, ktorú im poskytujete. To je známe ako riadenie spotrebiteľskej skúsenosti (CX, Customer Experience) a na úrovni koncových používateľov riadenie používateľskej skúsenosti (UX, User Experience). CX/ UX tvoria množinu informácií o tom, aký názor na službu majú jej používatelia. To v sebe zahŕňa použiteľnosť, funkcionalitu, ich skúsenosti so získavaním služby, fakturáciu (ak je to relevantné), následnú starostlivosť, požiadavky na zmenu, riešenie incidentov a akékoľvek zlepšenia, ktoré robíte pre používateľov. Zakaždým, keď spotrebiteľ interaguje s vašou organizáciou alebo vašou službou, vzniká bod dotyku a každý bod dotyku vedie k tomu, že spotrebiteľ získava určitú skúsenosť. Základom riadenia vzťahov so spotrebiteľmi je, že môžete zistiť zákaznícku skúsenosť v týchto bodoch dotyku, vziať ju do úvahy a v prípade potreby implementovať zlepšenia, ak vám to zákaznícka skúsenosť hovorí.

Pri zohľadňovaní potrieb zákazníkov nezabudnite na potreby vašich zamestnancov. Zamestnanecká skúsenosť je základom poskytovania úspešných služieb. Sú to zamestnanci, kto robí všetku prácu pre zákazníkov, a preto je dôležité, aby boli pri svojej práci spokojní. Zamestnanecká skúsenosť sa môže merať podobným spôsobom ako zákaznícka skúsenosť, napr. pravidelnými prieskumami alebo získavaním spätnej väzby v individuálnych alebo tímových diskusiách. Táto spätná väzba by sa potom mala preniesť do procesu neustáleho zlepšovania, aby sa v prípade potreby vykonali zmeny službieb.

Dôležitým aspektom interakcie so spotrebiteľmi je poskytovať im spravodajstvo o službe, ktorú od vás odoberajú. Spravodajstvo môže to mať rôzne formy, ale často sa opiera o určité ciele (kvality) služieb, na ktorých sa dohodnete so spotrebiteľmi. Ciele služby môžu byť podobné nasledujúcim:

včasnosť reakcie na požiadavky na službu, incidenty, požiadavky na zmenu
dostupnosť služby
výkonnosť služby
spoľahlivosť služby
spotrebiteľská skúsenosť (vrátane ľahkosti používania, efektívnej podpory koncových používateľov, vhodnosti vlastností služby pre stanovený účel)
presnosť služby

Ciele služby môžu byť súčasťou štandardnej zmluvy alebo môžu byť prispôsobené pre konkrétnych spotrebiteľov. V oboch prípadoch môžu odkazovať na zmluvu o úrovni služieb (Service Level Agreement - SLA), ktorá, ak sa zameriava viac na CX/ UX, môže zahŕňať dohodu o úrovni skúsenosti (Experience Level Agreement - XLA).

Bežné úskalia

Prístup „jedna veľkosť pre všetkých“. To znamená, že sa očakáva, že všetci spotrebitelia budú so službou rovnako spokojní bez ohľadu na to, aké sú ich vlastné potreby. V praxi má každý spotrebiteľ iný názor na to, čo by pre neho mala služba robiť, takže môže byť potrebné prispôsobenie, aby služba vyhovovala individuálnym potrebám spotrebiteľov.
Interakcia so spotrebiteľmi sa nedeje dostatočne často. Závisí od typu spotrebiteľov, či je potrebná častejšia alebo menej pravidelná interakcia s nimi. Niektorí spotrebitelia uprednostňujú mesačné podávanie správ, iným vyhovuje ročná správa o výkonnosti.
Interakcia prebieha rovnakým spôsobom pre všetkých spotrebiteľov. Podobne ako frekvencia, aj typ interakcie so spotrebiteľom môže vyžadovať prispôsobenie, aby vyhovoval ich špecifickým potrebám a očakávaniam.
Interné ciele nie sú zosúladené so spotrebiteľskými zmluvami o úrovni služieb (SLA). To je žiaľ celkom bežné: kľúčové ukazovatele výkonnosti tímov podporujúcich službu môžu byť v nesúlade s tým, čo bolo dohodnuté v spotrebiteľských SLA. Napríklad interné ciele doby odozvy môžu znemožniť splnenie SLA o dobe odozvy voči spotrebiteľovi. Interné a vonkajšie ciele musia byť zladené a zamestnanci podporujúci služby musia poznať ako svoje vlastné KPI aj spotrebiteľské SLA.

Ďalšie informácie

Ďalšie podrobnosti o interakcii so zákazníkmi vrátane merania zákazníckej skúsenosti a spravodajstva nájdete na webovej stránke ITSM.express.

Vyhotovte

Etapa riadenia služieb „Vyhotovte“ vyvíja službu jej budovaním, implementáciou a testovaním. Tu sa používajú procesy ako riadenie zmien a release manažment na ovládanie poskytovania služby v produkčnom prostredí predtým, ako ju budú používať spotrebitelia.

Služba je spôsob, ako priniesť hodnotu zákazníkom splnením definovaných potrieb zákazníkov. Služba je preto zvyčajne nehmotná, hoci môže byť dodaná spolu s (hmotným) produktom.

Vybudujte

Pred dodaním a nasadením služieb je potrebné ich vytvoriť, čo znamená, že všetky komponenty služby sú vytvorené a zhromaždené, organizácia je pripravená podporovať službu a služba je vybudovaná na základe návrhu služby. V ideálnom prípade sa to robí v spolupráci so spotrebiteľom, aby poskytovateľ služby aj spotrebiteľ získali z vytvorenia služby čo najväčšiu hodnotu. Hodnota odvodená od služby môže byť pre jej poskytovateľa a spotrebiteľa veľmi odlišná, ale pri vytváraní služby je potrebné zohľadniť obe strany. Spotrebiteľskou hodnotou môže byť napríklad uľahčenie biznis procesu, ktorý vedie k naplneniu jedného z biznis výsledkov. Hodnota pre poskytovateľa služby môže spočívať v získaní alebo udržaní podielu na trhu, zvýšení spokojnosti zákazníkov alebo generovaní výnosov. Vlastnosti služby majú vychádzať z potrieb zákazníka, ktoré majú uspokojiť, ale to nestačí. Mali by sa zvážiť aj ďalšie vstupy:

model dozoru (Governance) a stratégia organizácie (Je to služba, ktorú by sme mali poskytovať?)
schopnosti organizácie alebo partnerov (Vieme túto službu dodať?)
schválená organizačná architektúra vrátane technickej architektúry používanej organizáciou (Vieme túto službu efektívne vybudovať a udržiavať?).

Pri premýšľaní o potrebách zákazníkov musí organizácia zvážiť nielen funkcionalitu, ale aj záručné („warranty“) aspekty služby, ktorú sa chystá navrhnúť alebo vybudovať, ako bude pristupovať k pridaniu služby do portfólia a ako ju bude po pridaní do portfólia ponúkať a udržiavať.

Návrh služby (service design)

Podmienky používania

Poskytovatelia služieb musia pochopiť, ako a kde budú zákazníci služby využívať, pretože to určuje návrh záruky („warranty“) služby.

Prvky záruky, ktoré je potrebné zvážiť, sú minimálne nasledovné:

Dopyt po službe, ktorý určuje zaťaženie zdrojov používaných na poskytovanie služby (napríklad koľko lokalít, koľko používateľov, koľko transakcií) a mal by sa použiť pri navrhovaní služby tak, aby boli prítomné nielen funkcie, ktoré zákazníci potrebujú, ale aj schopnosť vždy dodávať zákazníkom hodnotu.
Dostupnosť služby, ktorá zohľadňuje, ako bude zákazník službu používať, za akých podmienok a čo zákazníci považujú za prijateľnú úroveň dostupnosti. Kedy by mala byť služba dostupná, kde by mala byť dostupná, čo sa považuje za dostupnú (napríklad pomalá odozva sa môže považovať za nedostupnú, takže v prípade počítačového systému bude dostupnosť zahŕňať prvky ako doba odozvy na transakciu a objem transakcií ktorý by služba mala byť schopná zvládnuť).
Kapacita služby, ktorá je prevedením vyššie uvedených dvoch prvkov do technických možností základných stavebných prvkov služby. V prípade počítačového systému sa to najnižšej úrovni opäť premieta do prvkov ako šírka pásma siete, objem databázy, rýchlosť čítania/ zápisu, úložná kapacita, výpočtový výkon (zvyčajne kapacita CPU a pamäte).

Analýza potrieb

Mala by sa vykonať hĺbková analýza potrieb zákazníkov. Malo by sa to vnímať v kontexte konkurenčného prostredia, aby sa určilo, či sa nová (plánovaná) služba môže životaschopne poskytnúť zákazníkom.

Analýza potrieb by mala brať do úvahy nielen vlastnosti, ktoré zákazníci požadujú (užitočnosť, ktorú by mala služba poskytovať zákazníkom), ale aj podmienky používania, aby bolo možné určiť záručné prvky služby.

Najlepšie je, ak je analýza potrieb založená na jasne definovanej analytickej metóde, ktorá závisí nielen od rozhovorov so zákazníkmi alebo používateľmi, ale aj od pozorovania vykonávanej práce, pochopenia potrieb podobných organizácií a toho, čo je na trhu (konkurenčné prostredie).

Navrhnutie a vybudovanie služby bez jedinečnej alebo zreteľnej ponuky hodnoty pôsobí svojvoľne a organizácie by sa mali snažiť ponúknuť zákazníkom viac hodnoty alebo lepšiu hodnotu.

Pochopenie toho, ako a kde sa bude služba používať, tvorí kľúčovú súčasť analýzy a často je potrebné, aby tento aspekt premietol do technickejších požiadaviek špecialista.

Vybudovať alebo kúpiť

Po dokončení návrhu služby sa organizácie musia kriticky pozrieť na svoju schopnosť dodávať všetky aspekty služby po jej vybudovaní. Často to znamená, že organizácie sa rozhodnú pre strategické partnerstvá na dodávanie niektorých aspektov služby.

Z hľadiska architektúry sa organizácie môžu tiež rozhodnúť použiť jednu z troch možností pri premýšľaní o komponentoch služby:

Vyvinúť komponenty sami o vybudovať službu od nuly.
Vyvinúť niektoré komponenty a použiť existujúce stavebné bloky na dokončenie ponuky.
Kúpiť alebo obstarať štandardné stavebné bloky, ktoré je možné zostaviť do jedinečnej konfigurácie a stačí ich nakonfigurovať (nie vyvinúť).

Náklady na vyššie uvedené možnosti sa môžu značne líšiť a organizácia by mala nielen zvážiť svoje schopnosti, ale aj vybudovať finančný model na určenie krátkodobej a dlhodobej životaschopnosti návrhu (dizajnu).

Služby zahŕňajúce viacerých dodávateľov

Ak organizácia dodáva službu, ktorá závisí od iných poskytovateľov služieb, súčasťou kritérií návrhu služby by malo byť zabezpečenie toho, aby ostatné strany mohli plniť svoje záväzky, keďže celková výkonnosť služby bude závisieť od všetkých jej komponentov.

Musia sa zaviesť dohody o úrovni služby a prostriedky na to, ako sa budú riadiť, merať a aké akcie by sa mali prijať v prípade ohrozenia kvality služieb. Väčšina ľudí okamžite myslí na právne dôsledky, ale to už môže byť príliš málo a príliš neskoro. Je potrebné dohodnúť, aké opatrenia majú prijať všetky strany na zabezpečenie ošetrenia vplyvu degradácie služby na zákazníkov.

Podrobný vhľad do tejto oblasti poskytujú prístupy ako integrácia a riadenie služieb (Service Integration and Management - SIAM).

Monitorovanie služby

Ak je to možné, monitorovacie systémy by mali byť navrhnuté ako súčasť návrhu služby, ktorý umožní poskytovateľovi služieb proaktívne konať v prípade degradácie služby.

Týmto aspektom sa budeme podrobnejšie zaoberať v sekcii monitorovania služby.

Agregácia služieb

Poskytovatelia služieb často spravujú aj služby, ktoré klientovi ponúkajú iní dodávatelia. Nejde o tú istú situáciu, ktorá je opísaná vyššie, ale skôr o poskytovateľov služieb, s ktorými uzavrel zmluvu o dodávaní služieb priamo zákazník, čo často môže mať vplyv na dodávku služieb ako celok.

Pri takýchto scenároch poskytovatelia služieb pri výpadku alebo degradácii služby často ukazujú prstom na iných namiesto toho, aby spolupracovali pre dobro zákazníka. Pre zákazníka môže byť rozumné určiť agitátora služby, ktorý riadi všetkých poskytovateľov služieb od začiatku do konca.

Podrobný vhľad do tejto oblasti poskytujú prístupy ako integrácia a riadenie služieb (Service Integration and Management - SIAM).

Riadenie zmien

Ciele

Účelom riadenia zmien je ovládať zmeny implementované v produkčnom prostredí. Slovo „ovládať“ môže znieť obmedzujúco, ale v praxi to tak nemusí byť. Často je potrebné nájsť rovnováhu medzi schopnosťou rýchlo a flexibilne implementovať zlepšenia služieb a potrebou udržiavať služby stabilné. Práve túto rovnováhu by malo poskytovať riadenie zmien.

Prínosy

Dobrý proces riadenia zmien má rôzne prínosy:

zabezpečenie stability služieb pri zavádzaní zmien
zabezpečenie minimálneho oneskorenia pri zavádzaní zmien
informovanie všetkých príslušných zainteresovaných strán o plánovaných zmenách
napomáhanie uprednostňovaniu takých typov zmien, ktoré majú menší dopad na službu.

Kľúčové koncepty

Riadenie zmien sa začína požiadavkou na zmenu (RFC, Request for Change): ide o požiadavku od koncového používateľa, vývojového tímu alebo inej strany, aby sa niečo zmenilo v službe, ktorú poskytujete. RFC môžu zahŕňať veľmi malé zmeny, napr. úpravu rýchlosti sieťového rozhrania alebo oveľa väčšie, napr. upgrade hardvéru servera.

Mala by sa zaviesť politika riadenia zmien usmerňujúca, ako by sa mali riešiť rôzne typy zmien:

Veľké zmeny so závažným vplyvom na službu možno budú musieť prejsť projektom so zapojením viacerých zainteresovaných strán, aby zmenu implementovali bez narušenia služby. Takýto projekt bude stále zahŕňať kroky, ktoré si vyžaduje proces riadenia zmien.
Malé zmeny môžu byť vopred schválené a vykonané bez ďalšieho odkladu. Často sa posielajú do procesu plnenia požiadaviek, čo je skrátená verzia procesu riadenia zmien (podrobnosti nájdete v časti „Odpovedajte“);
Všetky ostatné zmeny prejdú riadnym procesom riadenia zmien.

Existuje kategória zmien, ktorá je súčasťou riešenia incidentu a nazýva sa núdzová zmena (emergency change). Núdzové zmeny je potrebné implementovať bezodkladne v prípade, že existuje naliehavá potreba opraviť incident ako napríklad útok DDoS (Distributed Denial of Service) alebo závažná softvérová chyba, ktorú je potrebné okamžite opraviť. Môže byť zavedený samostatný postup na ošetrenie takýchto núdzových zmien. Tento postup zvyčajne spočiatku obíde bežný proces riadenia zmien popísaný nižšie a zmenu okamžite zavedie. Potom bude potrebné dodržať bežné kroky na zdokumentovanie, čo sa urobilo.

Ako popísané, všetky typy zmien môže riadiť spoločným proces riadenia zmien.

Proces

Keď poskytovateľ služieb dostane RFC, prvým krokom po jeho registrácii je nechať ho prejsť triedením (triáž, triage), čo znamená, že by sa mala posúdiť povaha zmeny, aby bolo možné určiť jej potenciálny vplyv. Výsledkom triedenia je odoslanie RFC buď do bežného procesu riadenia zmien alebo do plnenia požiadaviek alebo projektovej organizácii na riešenie.

Ak RFC prejde do pravidelného procesu riadenia zmien, jej platnosť by mal vyhodnotiť tím, ktorý ju má implementovať. Tím sa možno bude musieť poradiť so žiadateľom, aby overil podrobnosti a dohodol sa na časovom období, v ktorom môže byť zmena nasadená („okno pre zmenu“). Možno bude potrebné vytvoriť plán vrátenia (rollbacku) alebo vycúvania, aby sa ošetrila situácia, že nasadenie zlyhá a zmena sa musí vrátiť späť.

Vo veľkých a zložitých prostrediach môže byť potrebné mať samostatnú skupinu, ktorá dohliada na všetky RFC, ktoré sú prijaté a overuje, či niektoré z nich nemôžu byť navzájom v rozpore, a preto by mali byť nasadené samostatne. Táto skupina sa označuje ako poradný výbor pre zmenu (CAB, Change Advisory Board) a ako napovedá jej názov, radí, ako je potrebné zaobchádzať s RFC. Zapojenie CAB by však nemalo viesť k oneskoreniam pri zavádzaní, ale môže byť potrebné na zabezpečenie stability služieb a predchádzanie incidentom súvisiacim so zmenami.

Schválenie zmeny by mal vykonať tím, ktorý má najviac vedomostí o povahe zmeny a jej vplyve na živé služby. Preto sa robí na najnižšej možnej úrovni v organizácii, ktorá má právomoc schvaľovať žiadosti o zmenu.

Po schválení a naplánovaní prejde RFC do procesov uvoľňovania (release) a nasadzovania (deployment) (pozri ďalšiu sekciu).

V plne automatizovaných prostrediach ako DevOps vývoj môžu byť všetky vyššie uvedené kroky automatizované, pokiaľ sú stanovené správne kritériá pre triedenie, hodnotenie a schvaľovanie zmien. Tým sa zabezpečí minimálne oneskorenie pri zavádzaní zmien.

Bežné úskalia

Procesy riadenia zmien, ktoré implementovali rôzne organizácie, často čelia kritike, zvyčajne s odkazom na neprijateľné oneskorenia pri zavádzaní RFC. Príčinami tejto kritiky sú nasledujúce úskalia:

Všetky zmeny musia prejsť cez CAB. Je to úplne zbytočné, pretože to vždy prináša oneskorenia pre zmeny s malým vplyvom. CAB používajte len v komplexných prostrediach, kde existuje riziko konfliktov medzi rôznymi RFC a uistite sa, že CAB sa stretáva často.
Pred nasadením zmeny je potrebné získať veľa schválení. Pokiaľ sú príslušné zainteresované strany informované, na zmenu je potrebný iba jeden skutočný súhlas, ktorým je súhlas tímu, ktorý ju skutočne nasadí. Ak chcete znížiť potrebu schvaľovania, zistite tiež, či je možné vykonať jednoduché zmeny bez toho, aby ste museli prejsť schvaľovacím procesom: tento koncept je známy ako „štandardné zmeny“, ktoré je možné implementovať bez ďalších schválení.
Agilné a DevOps prostredia majú tendenciu „zabúdať“ na riadenie zmien kvôli rýchlosti nasadenia, ktorú spotrebiteľ očakáva. V skutočnosti spôsob, akým Agile zaobchádza s užívateľskými príbehmi (user stories), je jednoducho riadenie zmien, pokiaľ zahŕňa posúdenie požadovanej funkcionality, vplyv na existujúce služby a zníženie konfliktov s inými užívateľskými príbehmi. V DevOps, kde sa čo najviac automatizuje, je možné vykonať rovnaké kroky, aj automatizovaným spôsobom, v závislosti od povahy služieb. Väčšina automatizácie DevOps je však v oblasti riadenia uvoľňovania (release) a nasadzovania (deployment), ktorá bude pokrytá nižšie.

Riadenie uvoľňovania a nasadzovania (release and deployment management)

Riadenie uvoľňovania a nasadzovania v riadení služieb sú úzko súvisiace, ale odlišné procesy.

Jednoducho povedané, release manažment je o tom, či a kedy uvoľniť službu alebo prvok služby, zameriava sa na širší obraz a zabezpečuje súlad s biznis cieľmi, zatiaľ čo nasadenie (deployment) je o tom, ako sa vysporiadať s technickými špecifikami uvedenia novej alebo aktualizovanej služby do živej prevádzky.

Ciele

Hlavným cieľom riadenia uvoľňovania a nasadzovania je plánovať, časovať a ovládať pohyb releasov do testovacích a živých prostredí. Jeho primárnym cieľom je zabezpečiť ochranu integrity živého prostredia a uvoľňovanie správnych komponentov.

Implementácia dobre štruktúrovaných procesov riadenia uvoľňovania a nasadzovania (release and deployment management) pomáha minimalizovať prerušenia, zlepšovať kvalitu služby a zabezpečovať, že zmeny sú dodávané kontrolovaným spôsobom.

Prínosy

Hlavné prínosy dobrých procesov uvoľňovania a nasadzovania sú nasledovné:

Zlepšená kvalita služby: Efektívnym riadením uvoľňovania je možné znížiť negatívny vplyv zmien na kvalitu služieb.
Zlepšené riadenie rizík: identifikácia a riadenie rizík spojených s uvoľňovaním pomáha minimalizovať narušenia živého prostredia.
Zvýšená efektívnosť: zladenie procesov uvoľňovania a zasadzovania vedie k efektívnejšiemu využívaniu zdrojov.

Kľúčové koncepty

Release manažment zahŕňa aktivity zamerané na plánovanie, časovanie a ovládanie pohybu releasov do testovacích a živých prostredí. Jeho primárnym cieľom je zabezpečiť ochranu integrity živého prostredia a uvoľňovanie správnych komponentov. Zahŕňa dohľad nad viacerými zmenami a funkciami, ktoré sa spájajú do jedného releasu zabezpečujúci, aby sa pred nasadením integrovali a otestovali v predprodukčnom prostredí. Tento proces, často zdokumentovaný v release pláne, zahŕňa koordináciu medzi rôznymi tímami, plánovanie okien uvoľňovania, dokumentovanie releasov (napr. release notes) a komunikáciu a školenie pre zainteresované strany.

Nasadzovanie (deployment) je zas proces presunu releasu do iného (prípravného - stagingového, testovacieho alebo živého/produkčného) prostredia alebo do rúk používateľov. Je technickejšie a zahŕňa činnosti potrebné na implementáciu novej alebo aktualizovanej služby do prevádzky. To zahŕňa prípravu cieľového prostredia, inštaláciu komponentov, ich konfiguráciu tak, aby zodpovedali živým nastaveniam a vykonanie všetkých potrebných testov na zabezpečenie toho, že nasadenie spĺňa požadované štandardy.

Niektoré ďalšie koncepty v týchto procesoch sú:

Politika releasov: Súbor pravidiel, ktoré usmerňujú, ako sa v rámci organizácie riadia releasy vrátane načasovania releasov, požiadaviek na školenie, dokumentačných potrieb, komunikácie o releasoch atď.
Balíček releasu (Release Package): Súbor konfiguračných položiek (CI, Configuration Items), hardvéru, softvéru, dokumentácie atď., ktoré sa majú uvoľniť spoločne.
Plán nasadenia (deployment plan): Podrobný plán, ktorý popisuje, ako sa release presunie do živého prostredia.
Prostredie: Vzťahuje sa na živé, testovacie a vývojové časti alebo oblasti, kde sa služby budujú, testujú, nasadzujú a riadia.

Proces

Naplánujte release: Definujte rozsah, plán a zdroje potrebné pre release.
Vybudujte a otestujte: Vytvorte balíček releasu a vykonajte dôkladné testovanie, aby ste sa uistili, že spĺňa funkčné aj nefunkčné požiadavky. Zvážte testovanie používateľských, bezpečnostných, kvalitatívnych a ďalších požiadaviek.
Kontrola pripravenosti na uvoľnenie: Uistite sa, že všetky aspekty releasu sú úplné a pripravené na nasadenie. To môže zahŕňať aj zabezpečenie aktualizácie používateľskej dokumentácie a toho, že podporné tímy boli vyškolené alebo inak pripravené podporiť release v cieľovom prostredí.
Nasaďte (deploy): Presuňte balíček releasu do živého prostredia podľa plánu nasadenia.
Skontrolujte a uzavrite: Po nasadení skontrolujte proces releasu, aby ste identifikovali všetky získané ponaučenia a formálne uzavrite vydanie. To môže zahŕňať uzavretie akýchkoľvek súvisiacich ticketov (listkov) o problémoch alebo incidentov, ktoré má nasadenie vyriešiť. Teraz by sa mali zaktualizovať aj šetky zmeny zahrnuté do releasu.

Bežné úskalia

Nedostatok komunikácie: Zlá komunikácia medzi tímami môže viesť k nedorozumeniam a chybám počas procesu uvoľňovania.
Nedostatočné testovanie: Nedostatočné testovanie môže mať za následok releasy, ktoré spôsobia viac problémov než vyriešia.
Zlé plánovanie: Bez dôkladného plánovania môžu releasy trpieť oneskoreniami, nedostatkom zdrojov a neriadeným nafukovaním rozsahu (scope creep).
Zlyhanie riadenia rizík: Neidentifikovanie a neriadenie rizík môže viesť k neočakávaným situáciám počas nasadenia.
Neadekvátna dokumentácia: nedostatočné zdokumentovanie releasu a jeho komponentov môže viesť k zmätku a ťažkostiam pri odstraňovaní obtiaží.

Poskytujte

Tretia etapa prístupu ITSM.express zahŕňa komplexný prístup k ochrane, meraniu a zlepšovaniu IT služieb. V tejto etape sa služby, ktoré boli navrhnuté, vybudované a dodané, chránia pred hrozbami v prevádzkovom prostredí. Veľa z týchto hrozieb by malo byť identifikovaných a zaevidovaných v registri rizík v etape Definujte, hoci nové hrozby môžu a mali by byť identifikované a riadené vo všetkých etapách. V tejto etape by sa malo zabezpečiť aj to, že poskytovateľ služby plní sľuby, ktoré dal v skorších etapách meraním výkonnosti služby a jej poskytovateľa. V tejto etape by sme mali aj neustále zlepšovať služby ponúkané našim spotrebiteľom. Príležitosti na zlepšenie je možné identifikovať meraním služieb a tiež inováciou.

Chráňte – informačná bezpečnosť

Ciele

Pokiaľ ide o informačnú bezpečnosť, mal by sa použiť prístup založený na rizikách s použitím usmernení z oblasti riadenia rizík z etapy Definujte. Ako rámcové usmernenie sa tu používa norma ISO 31000. Čo sa týka informačnej bezpečnosti je dôležité poznamenať, že každý v organizácii poskytovateľa služieb, dodávatelia, partneri a spotrebitelia by mali pozitívne prispievať k informačnej bezpečnosti. Prostredie informačných hrozieb sa neustále vyvíja, preto je dôležité zostať popredu a pravidelne aktualizovať posúdenia rizík a stratégie na ich zmierňovanie. Tento proaktívny prístup pomáha udržiavať bezpečnosť informácií a tiež zabezpečuje súlad s príslušnými nariadeniami o bezpečnosti informácií a o ochrane súkromia.

Medzinárodným štandardom pre informačnú bezpečnosť je ISO/IEC 27001. Obsahuje oveľa viac požiadaviek a podrobností o prevádzke systému riadenia informačnej bezpečnosti, ako je uvedené tu.

Proces

Aby bolo možné identifikovať riziká informačnej bezpečnosti, je potrebné najprv pochopiť, čo by malo byť chránené. Je dôležité identifikovať a zaznamenať aktíva informačnej bezpečnosti s porozumením, aké kritické alebo cenné sú tieto aktíva pre poskytovateľa služby a spotrebiteľov. Aktíva informačnej bezpečnosti môžu zahŕňať fyzické informácie (napr. papierové záznamy), ako aj digitálne alebo osobné údaje. To umožňuje poskytovateľovi služby aplikovať na aktíva informačnej bezpečnosti primeranú úroveň ochrany.

Akonáhle je známe, ktoré aktíva informačnej bezpečnosti potrebujú ochranu, malo by sa vykonať dôkladné posúdenie rizík s identifikáciou hrozieb, ktorým môžu tieto aktíva čeliť. Je dôležité poznamenať, že hrozby nie sú vždy zlovoľné: informačné aktíva sú zraniteľné aj voči prírodným živlom (požiare, záplavy, vlhkosť) a nehodám. Podľa opísaného prístupu riadenia rizík zhodnoťte potenciálne hrozby a zraniteľnosti, ktoré by mohli mať vplyv na tieto aktíva. Pochopením pravdepodobnosti a potenciálneho dopadu rôznych hrozieb je možné zodpovedajúco priorizovať ošetrenie s rizík informačnej bezpečnosti.

Ošetrenie zahŕňa vypracovanie stratégie na zmiernenie týchto rizík implementáciou robustných bezpečnostných opatrení. To zahŕňa vytvorenie jasných politík a procedúr na bezpečné riadenie informácií, implementáciu logických a fyzických ovládačov prístupu a ďalších ovládačov, ako napr. ochrana pred škodlivým softvérom a zálohovanie. Ovládače informačnej bezpečnosti majú zahŕňať aj školenie zamestnancov o štandardných prevádzkových postupoch (na budovanie kompetencie a predchádzanie chybám), ako aj školenia o najlepších praktikách v oblasti bezpečnosti.

Dôležitým podprocesom v oblasti informačnej bezpečnosti je ovládanie prístupu, ktoré je súčasťou fyzickej bezpečnosti (prístup do budovy, bezpečné oblasti) a aplikačnej bezpečnosti (prístup k aplikáciám a serverom).

Ovládanie prístupu

Ovládanie prístupu sa týka procesov a technológií používaných na riadenie a monitorovanie prístupov k sieťovým zdrojom, aplikáciám a dátam. Používa sa na zabezpečenie toho, aby k určitým informáciám a funkcionalite mali prístup iba autorizovaní používatelia a systémy, čím sa zvyšuje bezpečnosť a súlad s predpismi. Ovládanie prístupu je rozhodujúce pre zachovanie dôvernosti, integrity a dostupnosti informácií. Ovládaním toho, kto má k čomu prístup, môžu organizácie chrániť citlivé údaje pred neoprávneným prístupom, predchádzať narušeniu údajov a dodržiavať regulačné požiadavky.

Implementácia ovládania prístupu zahŕňa definovanie politík, rolí a povolení, ktoré určujú, ku ktorým zdrojom môžu používatelia pristupovať ktoré akcie môžu vykonávať. To zvyčajne zahŕňa procesy autentifikácie, autorizácie a auditu používateľov, často podporované systémami správy identity a prístupu (IAM) alebo súvisiacimi technológiami.

Meranie

Ciele

Efektívne meranie IT služieb je kľúčové pre pochopenie ich výkonnosti, zlepšenie poskytovania služieb a ich zosúladenie s potrebami spotrebiteľov a biznis cieľmi.

V časti Definujte bolo popísané spravodajstvo pre spotrebiteľov a poskytovateľ služby by mal tiež merať služby a ich výkonnosť, aby potvrdzoval a podal správy, že poskytuje či neposkytuje požadované úrovne služieb.

Prínosy

Poznatky získané z analýzy údajov by mali poskytovateľovi služby pomôcť pri prijímaní informovaných rozhodnutí. To by malo zahŕňať ošetrenie oblastí, kde výkon zaostáva, prerozdelenie zdrojov či vykonanie zmien v službách alebo procesoch. To indikuje príspevok merania k ďalšiemu procesu opísanému v časti Poskytujte, k procesu neustáleho zlepšovania.

Kľúčové koncepty

Služby sú merané z viacerých dôvodov vrátane zlepšenia spokojnosti spotrebiteľov, zníženia výpadkov alebo optimalizácie využívania zdrojov. V časti Definujte bolo popísané spravodajstvo pre spotrebiteľa a potreba stanoviť jasné ciele, konkrétne merateľné metriky a ich cieľové hodnoty. Meranie pre spravodajstvo kritické. Existuje mnoho technických služieb, ktoré spotrebiteľ nevidí a prispievajú k službám orientovaným na zákazníka, ktoré by sa tiež mali merať. Tieto merania môžu prispieť ku prehľadu o výkonnosti a identifikácii významných udalostí, ktoré si môžu vyžadovať zásah na obnovenie normálneho výkonu a úrovne služieb.

Proces

V rámci tohto procesu by malo byť určené, ktoré údaje sa majú zbierať a ako sa tieto dáta budú interpretovať a používať pre metriky výkonnosti vrátane výberu správnych nástrojov a procesov. Poskytovateľ služieb môže napríklad použiť automatizované monitorovacie nástroje na sledovanie výkonnosti systému alebo použiť prieskumy na meranie spokojnosti spotrebiteľov. Meracie činnosti, najmä ak sú automatizované, môžu generovať veľké objemy údajov, takže je dôležité, aby ste pochopili, ktoré údaje sa zhromažďujú a prečo: Akú hodnotu majú údaje pre dosiahnutie cieľov organizácie?

Po nasadení potrebných nástrojov, technológií a prieskumov na zhromažďovanie údajov by mal poskytovateľ služieb zabezpečiť, aby boli tieto nástroje správne integrované so súvisiacimi systémami a aby boli údaje zachytávané presne a konzistentne.

Zozbierané údaje by sa mali pravidelne analyzovať, aby ste získali prehľad. Mali by ste hľadať trendy, vzorce a problémové oblasti. Tento krok často zahŕňa použitie nástrojov na analýzu údajov, ktoré dokážu spracovať veľké objemy dát, poskytujú zmysluplné vizualizácie a môžu prispieť k činnostiam a nástrojom na správu udalostí alebo dokonca tvoriť základ činností pre správu udalostí.

Súhrnné zistenia zdôrazňujúce obavy, výnimky a trendy by mali byť zahrnuté do jasných a stručných správ. Tieto správy by mali byť prispôsobené svojej cieľovej skupine – napríklad technické tímy môžu potrebovať podrobné údaje o výkonnosti, zatiaľ čo výkonný manažment, vlastníci a manažéri služieb a spotrebitelia môžu preferovať rámcové zhrnutia.

Bežné úskalia

Kontrola a úprava: IT prostredia a potreby biznisu sa neustále menia, preto je dôležité pravidelne kontrolovať a podľa potreby upravovať metriky, metódy zberu alebo analytické techniky. To zaisťuje, že merania zostanú relevantné a v súlade s biznis cieľmi.

Zlepšujte

Ciele

Rovnako ako u riadenia rizík a informačnej bezpečnosti môže každý v organizácii poskytovateľa služieb, dodávatelia, partneri a spotrebitelia pozitívne prispievať ku neustálemu zlepšovaniu. Organizácia by sa mala učiť zo spätnej väzby od zákazníkov a z údajov zhromažďovaných, analyzovaných a reportovaných v rámci skupiny aktivít „merajte“, aby to pomáhalo robiť iteratívne zmeny na zlepšenie poskytovania služby, lepšie plnenie cieľov služieb a biznis potrieb alebo zlepšenie samotných cieľov služieb.

Proces

Spoločný a priamočiary prístup k neustálemu zlepšovaniu zahŕňa nasledujúce kroky:

Identifikujte príležitosť na zlepšenie: Rozpoznajte oblasti, v ktorých služba nespĺňa očakávania, kde sú procesy alebo prevádzkové postupy neefektívne alebo kde existujú iné príležitosti na zlepšenie. Tieto príležitosti možno identifikovať prostredníctvom spätnej väzby od zákazníkov, výkonnostných metrík, riadenia rizík, riadenia informačnej bezpečnosti alebo pravidelných revízií služieb.
Porozumejte súčasnému stavu: Preskúmajte existujúcu službu, proces alebo iný cieľ zlepšenia, aby ste získali správny východiskový bod (baseline) pred zlepšením a pochopili, aké zlepšenia je možné spraviť. Môže to zahŕňať preskúmanie správ o incidentoch, tokoch práce alebo prideľovanie zdrojov.
Stanovte si jasné a realistické ciele: Akonáhle je známe, čo je potrebné zlepšiť, organizácia by si mala stanoviť jasné, merateľné ciele, ktoré sú dosiahnuteľné. Malé, časté, iteratívne vylepšenia často prinášajú skvelé výsledky s minimálnym narušením alebo odporom. Ujasnite si, čo chcete zlepšením dosiahnuť. Môže to byť rýchlejšia doba odozvy, menej chýb alebo vyššia spokojnosť spotrebiteľov. V tomto kroku by sa malo určiť, ako sa bude merať úspešnosť zlepšenia a mali by sa stanoviť očakávané ciele. Má zmysel používať rovnaké metriky alebo metódy spätnej väzby, ktoré identifikovali potrebu zlepšenia.
Naplánujte zlepšenie: Na základe analýzy vytvorte plán, ako vykonať zlepšenia. Plán by mal zahŕňať konkrétne akcie, požadované zdroje a harmonogram. Je dôležité byť realistický a zvážiť potenciálne výzvy.
Implementujte zlepšenie: Uveďte plán do praxe. Tento krok môže zahŕňať školenie personálu o nových postupoch, aktualizáciu hardvéru alebo softvéru, vyladenie alebo odstránenie procesných krokov, pridanie ovládacích prvkov alebo zmenu metód komunikácie so zákazníkmi.
Monitorujte a kontrolujte zlepšenie: Po implementácii zmien pozorne sledujte službu, aby ste zistili, či zlepšenia fungujú, merajte zlepšenie pomocou metrík a cieľov plánovaných pri stanovovaní cieľov pre zlepšenie. Na základe monitorovania môže byť potrebné vykonať ďalšie úpravy vykonaných zlepšení.

Zlepšovanie služby nie je jednorazová záležitosť, prebieha sústavne, je to neustály cyklus zlepšovania, takže ďalším krokom je opäť ísť na prvý krok a identifikovať ďalší cieľ zlepšovania.

Odpovedajte

Poskytovatelia služieb musia často komunikovať so spotrebiteľmi v rámci poskytovania služieb – konkrétne s koncovými používateľmi služieb, bez ohľadu na to, či túto komunikáciu iniciuje poskytovateľ služby alebo používateľ.

Je dôležité, aby existovali jasne definované komunikačné prostriedky, ktoré poskytujú aj auditnú stopu. Najlepším spôsobom, ako to urobiť, je poskytnúť jednotné kontaktné miesto, ako napríklad service desk. To by však nemalo byť nesprávne chápané ako jediný prostriedok kontaktu.

Procesy odpovedania sú usmerňované komunikáciou facilitovanou spoločným kontaktným bodom. Systémy zavedené na facilitovanie tejto komunikácie poskytujú prostriedky na eskaláciu, sledovanie aktivity a stavu aj každodenné meranie a riadenie.

Tradičné procesy nachádzajúce sa v etape Odpovedajte sú:

Riadenie požiadaviek
Riadenie incidentov
Riadenie problémov
Spravodajstvo o službách
Riadenie používateľských aktualizácií/ upozornení

Proces odpovedania načrtnutý v nasledujúcom texte je prezentovaný ako jednotný prístup k riešeniu používateľských požiadaviek vrátane riadenia incidentov, riadenia požiadaviek a riadenia problémov. Tento jednotný proces nazývame proces odpovedania. Jednotný kontaktný bod pre komunikáciu okolo tohto procesu sa nazýva service desk.

Service desk

Ciele

Ciele service desku sú:

poskytnúť jednotné kontaktné miesto pre spotrebiteľov služby (predovšetkým používateľov)
sprostredkovať obnovu služby
smerovať požiadavky používateľov a facilitovať výsledky
poskytovať prvú úroveň riešenia incidentov a požiadaviek tam, kde je to možné
zaznamenávať a sledovať komunikáciu a zasiahnuť, ak aktivity procesu nespĺňajú štandardy kvality (zvyčajne špecifikované v SLA) a
byť kanálom na efektívne riešenie nečakaných situácií, keď je poskytovateľ závislý od podpory tretích strán (napr. riadenie eskalácie).

Prínosy

Používatelia presne vedia, koho kontaktovať a ako kontaktovať poskytovateľa služby.
Nečakané situácie (predovšetkým incidenty) a požiadavky na služby môžu byť zaznamenané a preto riadené tak, aby sa zabezpečilo dodržiavanie štandardov služieb.
Zaznamenané údaje možno použiť na:
- zlepšovanie služieb a komponentov služieb
- spravodajstvo o výkonnosti poskytovateľa služby a
- lepšie porozumenie stavu služby s cieľom zlepšiť budúcu hodnotu služby.

Proces

Service desk zvyčajne:

zaznamenáva používateľské požiadavky (incidenty a požiadavky na služby)
odpovedá na požiadavky používateľov poskytovaním prvej úrovne podpory
komunikuje s tretími stranami, od ktorých je služba závislá
poskytuje používateľom spätnú väzbu
informuje zainteresované strany (napr. počas výpadkov služieb) a
podáva správy o zozbieraných údajoch kľúčovým zainteresovaným stranám.

Druhá odrážka je obzvlášť dôležitá, pretože agent service desku by mal mať technické zručnosti a nástroje na vyriešenie a uzavretie väčšiny požiadaviek (incidentov a požiadaviek na služby) zaznamenaných service deskom.

Service desk (najmä v malých organizáciách) môže byť poverený aj vykonávaním iných prevádzkových činností ako monitorovanie služieb, zálohovanie a riadenie činností prevádzkovej podpory.

Bežné úskalia

Niektoré bežné problémy, ktoré sa vyskytujú pri prevádzke service desku a ako ich opraviť, sú nižšie:

Nedostatok porozumenia biznisu (používateľskému kontextu)

Zamestnanci service desku musia pochopiť, ako funguje biznis spotrebiteľa a okamžite zistiť, či sa dopyt používateľa týka kritického prvku biznis úspechu.

Agenti service desku musia absolvovať základné školenie, ktoré im pomôže porozumieť kontextom požiadaviek, s ktorými sa môžu počas svojich povinností vysporiadať.

Nedostatok technického porozumenia

Agenti service desku musia rozumieť návrhu (dizajnu) služieb a závislosti medzi komponentmi služieb a súvisiacimi technickými zručnosťami, aby boli schopní „na prvý hovor“ vyriešiť väčšinu nečakaných situácií zaevidovaných service deskom.

Agenti service desku musia mať rámcový prehľad o architektúre svojich služieb. To im pomáha rýchlo identifikovať ďalšie body eskalácie, ak nedokážu vyriešiť problém sami.

Zaistite, aby agenti service desku mali dostatočné znalosti na to, aby mohli vyriešiť väčšinu používateľských požiadaviek na prvom bode kontaktu.Škoľte agentov service desku o technickom prostredí, ktoré musia podporovať a poskytnite im správny nástroj na riešenie požiadaviek používateľov.

Nedostatok správnych informácií/ údajov a integrovaných nástrojov

Service desk nemôže fungovať bez správnych podporných nástrojov a pretože nástroje service desku sa často používajú na podporu a technické riadenie, je potrebné starostlivé zváženie, výber a investície. Na vykonávanie tohto druhu činností je ideálne použiť integrovaný systém riadenia služieb.

Podpora bude vždy suboptimálna, pokiaľ nemožno efektívne spravovať zaznamenané údaje o používateľských požiadavkách v rámci celého kontextu pôsobenia poskytovateľa. Obzvlášť dôležité sú tri prvky:

Na dosiahnutie výsledkov kvality služieb je potrebné zaznamenávať správne údaje.
Tok práce musí byť jednoduchý a konfigurovateľný, aby zodpovedal typu riešenej požiadavky.
Údaje o všetkých zaznamenaných požiadavkách a prístup k ďalším dátam, ktoré pomôžu pri riešení požiadavky, musia byť voľne dostupné a ľahko prístupné.

Nedostatok komunikačných zručností a empatie

Poskytovatelia služieb by mali investovať do školenia, ktoré agentom pomôže lepšie komunikovať a vcítiť sa do situácie používateľov. Efektívne sprostredkovanie výsledkov v tomto scenári nie je len o technických schopnostiach. Spokojnosť používateľov často závisí výlučne od ich interakcií so service deskom.

Meranie výsledkov

Meranie výkonnosti service desku je možné robiť niekoľkými spôsobmi a úzko to súvisí s procesom merania a neustálym zlepšovaním v etape Poskytujte.

Možné metriky pre pracovisko service desku z pohľadu používateľa sú:

jednoduchosť kontaktovania service desku
kvalita riešenia požiadaviek
rýchlosť riešenia požiadaviek
skúsenosť s interakciou so service deskom

Možné metriky pre service desk z pohľadu poskytovateľa služieb sú:

doba odozvy na požiadavku
doba na vyriešenie požiadavky
% požiadaviek vyriešených v rámci prvého kontaktu
počet spracovaných požiadaviek na jedného agenta (za časové obdobie)
počet vyriešených požiadaviek na jedného agenta (za časové obdobie)
% opätovne otvorených požiadaviek – aj keď niektorí môžu nesúhlasiť s opätovným otváraním hovorov, je dôležité zabezpečiť, aby po uzavretí hovorov bola požiadavka úspešne vyriešená a minimalizoval sa opakovaný výskyt – to sa meria tu.

Riešenie požiadaviek (queries)

Tu prezentujeme jednoduchý proces na spracovanie všetkých používateľských požiadaviek – čo môžu byť v tradičných podmienkach riadenia služieb incidenty, požiadavky na služby a dokonca aj problémy.

To, čo je uvedené tu, je jednoduchý základ, ktorý možno vždy rozširovať podľa toho, ako sa vyvíjajú potreby organizácie. Komplexnosť však prináša množstvo ďalších výziev.

Požiadavky používateľov sa často neriešia úplne, pretože sa zavádzajú náhradné riešenia (workarounds) alebo dočasné opravy na rýchle obnovenie služby s vedomím, že prvotná príčina výpadku nebola vyriešená. Usmernenie v tejto sekcii je založené na skúsenosti, že väčšina organizácií hovorí o riešení hlavných príčin až po udalosti, a preto tu je načrtnutý „jednoprocesový“ prístup.

Proces odpovedania

Ciele

Cieľom tohto procesu je neustála dostupnosť služieb. Tento to proces zabezpečuje facilitovaním komunikácie a požiadaviek používateľov, obnovením služby pri výpadku a zabezpečením, aby sa výpadky služby neopakovali.

Prínosy

zlepšená produktivita koncových používateľov služby
zlepšená produktivita personálu poskytovateľa služby
presné údaje o zhoršení alebo výpadkoch služby a uľahčenie návrhu a plánovania služby
facilitovanie lepšieho pochopenia nákladov na nedostupnosť služby a skutočných nákladov na službu.

Kľúčové koncepty

Tento proces sa zaoberá tromi kľúčovými konceptmi a líniami práce. Poskytovatelia, ktorí ich chcú rozdeliť do troch samostatných procesov, to môžu urobiť. Sme však presvedčení, že medzi tým, ako sa riešia incidenty a požiadavky je tak málo rozdielov, že v mnohých organizáciách je toto rozlišovanie akademické.

V priebehu desaťročí sme pozorovali, že keď sa stane prvoradým cieľom riešenie incidentov (napríklad nedostupnosti alebo degradácie služby), zanedbáva sa riešenie prvotnej príčiny po obnovení služby (všeobecne označované ako riadenie problémov – problem management). Preto sa domnievame, že integrovaný prístup je opodstatnený a tam, kde sa uplatňuje, je obozretný.

Čo však sú incidenty, problémy a požiadavky, ktorými sa tento proces zaoberá?

Incidenty sú prerušenia alebo zhoršenia služby, ktoré bránia používateľovi získať plné prínosy, ktoré má služba ponúkať. Tieto prípady prerušenia alebo zníženého výkonu služby sú často výsledkom niektorých základných štrukturálnych problémov v rámci návrhu alebo prevádzky služby, ktoré často nie sú zjavne viditeľné. Napriek tomu, ak sa tieto problémy správne nevyriešia, budú sa opakovať, pretože prvotné príčiny incidentov zostávajú. Riešenie prvotnej príčiny incidentov sa často nazýva riadenie problémov (problem management).

Akákoľvek iná požiadavka (query) používateľa týkajúca sa používania služby je požiadavka (request). To zahŕňa otázky o jej používaní, prístup ku službe alebo jej funkciám alebo akcie poskytovateľa služieb, ktoré používateľom pomôžu maximalizovať prínosy z používania služby. Často zahŕňajú požiadavky na prispôsobený výstup služby, spotrebný materiál používaný pri poskytovaní služby alebo špeciálny výstup – napríklad správy o službe.

Všimnite si, že požiadavky na poskytnutie nových alebo zmenených funkcií služby sa nevybavujú ako požiadavky na službu, ale skôr ako požiadavky na zmenu a sú podporované procesom riadenia zmien. Tento proces je možné použiť na zaznamenanie takýchto požiadaviek a ich následné odovzdanie procesu, ktorý sa zaoberá zmenou a prispôsobením služby.

Mnohé zo zmien, ktoré požadujú používatelia, sú však často vopred dobre pochopené a riziká sú známe. Takéto zmeny môžu byť riadené splnením požiadavky v rámci určitých hraníc a personál prvej línie podpory sa môže naučiť, ako facilitovať túto štandardizovanú zmenu.

Organizácie priraďujú žiadostiam úrovne priority na základe dopadu a naliehavosti požiadavky a súvisiacich harmonogramov, ktoré ovplyvňujú realizáciu negatívneho účinku.

Služby sa často obnovujú pomocou dočasnej opravy alebo riešenia a koncepčne sa incident uzavrie, keď používateľ môže obnoviť svoje normálne denné funkcie.

Treba poznamenať, že aj keď sa zdá, že incident je uzavretý, prvotná príčina nebola vyriešená a to čo často vedie k ďalšiemu zhoršovaniu služby, nestabilnej službe a ďalším prerušeniam služby – čo sa čoskoro môže stať začarovaným kruhom.

V tradičnom prístupe k riadeniu služieb sa na nájdenie základných príčin a implementáciu trvalých opráv používa samostatný proces (riadenie problémov) – jediným problémom je, že len veľmi málo organizácií to vôbec robí alebo to robí skutočne dobre.

Navrhujeme integrovaný prístup k riadeniu incidentov/ problémov. Dôkazy naznačujú, že pravdepodobnosť toho, že príčiny incidentov sa budú riešiť, je oveľa vyššia pri použití integrovaného prístupu.

Všetky bežné prístupy k nájdeniu a odstráneniu základnej príčiny jedného alebo viacerých incidentov majú spoločné nasledovné:

Definovanie, v čom je problém.
Nájdenie prvotnej príčiny – uvedomte si, že kauzálna analýza nie je potrebná. Analýza prvotných príčin môže mať príčinu sama o sebe. Ak chcete problém vyriešiť natrvalo, musíte vystopovať príčinu príčin, kým sa nedostanete ku koreňu problému.
Vykonávanie opatrení na odstránenie prvotnej príčiny.

Tu je namieste opatrnosť – nepredpokladajte, že existuje jediná prvotná príčina – často existujú viaceré prvotné príčiny.

Nie všetky požiadavky používateľov by mali zahŕňať posúdenie prvotnej príčiny, ale tie s vysokou prioritou by určite mali.

Proces

Celkový proces na zabezpečenie komplexnej odpovede na požiadavky na službu zahŕňa nasledujúce komponenty:

Zaznamenajte, klasifikujte a stanovte prioritu požiadavky

Keď sa evidujú požiadavky používateľov, agenti service desku by mali službám rozumieť dostatočne dobre nielen na to, aby zaznamenali požiadavku, ale aj správne klasifikovali typ požiadavky a priradili požiadavke prioritu je v súlade s dopadom alebo účinkom na biznis.

Zaznamenanie zvyčajne zahŕňa informácie ako podrobnosti o používateľovi, poloha, dotknutá služba a typické príznaky alebo účinky.

Klasifikácia zahŕňa rozhodnutie, o aký typ požiadavky ide (napríklad požiadavka na informáciu, požiadavka na oprávnenie na službu alebo degradácia či zlyhanie služby – používa sa na spustenie konkrétneho toku práce) a napokon vplyv na biznis, ktorý sa používa na definovanie priority požiadavky.

Na základe typu požiadavky je možné použiť špecifický tok práce alebo postup, ktorý umožní rýchle uzavretie požiadavky.

Service desk

To, že service desk je jednotným kontaktným miestom, neznamená, že telefón je jediným zdrojom prístupu k service desku. Service desk by mal byť schopný účinne facilitovať požiadavky používateľov bez ohľadu na prostriedok kontaktovania, ktorý používateľ použil.

Poskytnite informácie

Organizácie často pripravujú štandardnú odpoveď na často kladené otázky (FAQ), čo je praktický zdroj na zodpovedanie požiadaviek používateľov. Dá sa to urobiť online a malo by byť dostupné aj všetkým agentom service desku.

Ak požiadavku používateľa na informáciu nemožno uspokojiť poskytnutím štandardnej odpovede, service desk by mal postúpiť požiadavku zdroju v organizácii, ktorý na to má najlepšie predpoklady – opäť sú na to potrebné znalosti biznisu.

Oprávnenia na služby

Oprávnenia na služby sú povolenia pre koncových používateľov na prístup ku zdrojom, ako napr. prístup k aplikácii alebo dokumentu. Tento typ požiadavky možno jednoducho spracovať na service desku, len čo agent overí oprávnenie.

Niekedy je však tiež potrebné eskalovať oprávnenia na služby na jednotlivca so zručnosťami, prístupom a senioritou potrebnými na to, aby sa mohol špecificky zaoberať týmto typom požiadavky.

Obnova služby

Obnova zlyhaných alebo degradovaných služieb si často vyžaduje technickú kompetenciu. Hlboké technické znalosti však nie sú vždy potrebné, ak sa riadne zaznamená predchádzajúce úsilie a použije sa ako referenčná databáza.

Definovanie možného riešenia bežne sa vyskytujúcich problémov so službami na service desku môže zlepšiť podiel vyriešenia požiadaviek „na prvý hovor“.

Ak agent service desku nedokáže vyriešiť incident, mal by mať dostatok technických znalostí na preposlanie (eskaláciu) dopytu tomu technickému zdroju, ktorý je s najväčšou pravdepodobnosťou schopný vyriešiť incident.

Ak sa incidenty eskalujú, service desk musí sledovať priebeh a overovať s používateľmi, že incident bol vyriešený k ich spokojnosti, keď technický zdroj a koncový používateľ indikujú, že incident bol vyriešený.

Tu je vložený podproces, zvyčajne definovaný ako samostatný proces nazývaný riadenie problémov (problem management).

Pred uzavretím incidentov by mal service desk zistiť, či je incident kritickej povahy s významným dopadom na biznis alebo nie. Ak je odpoveď kladná, incident nie je možné uzavrieť, ale mal by byť priradený seniornejšiemu technickému zdroju na analýzu prvotnej príčiny. V tomto prípade môže byť incident uzavretý až po identifikácii a vyriešení prvotnej príčiny degradácie alebo zlyhania služby.

Ošetrenie prvotných príčin

Všetky degradácie služieb a ich zlyhania, ktoré mali podstatný vplyv na biznis spotrebiteľa, sa musia vyšetriť hlbšie (po obnovení služby), aby sa určila prvotná príčina týchto výpadkov. Keďže tieto výpadky mali významný vplyv na biznis, poskytovateľ služby nemôže zanedbať zabezpečenie toho, aby sa výpadok alebo zhoršenie služby nevyskytol znovu v budúcnosti.

Metóda, ako to spraviť, je na poskytovateľovi služby.

Jediným špecifickým usmernením, ktoré tu zostáva, je, že je nepravdepodobné, že by táto úloha bola pridelená jednotlivcovi, pretože žiadny jednotlivec nebude mať zručnosti potrebné na to, aby sa na problém pozrel z rôznych uhlov pohľadu. Riešenie problémov sa najlepšie vykonáva pomocou multidisciplinárneho tímu technických a biznis expertov, aby ste skutočne pochopili prvotnú príčinu alebo príčiny degradácie alebo výpadku služby.

Po nájdení prvotnej príčiny by mali byť podniknuté akcie na trvalé ošetrenie problému. To často zahŕňa akcie, ktoré si vyžadujú formálne posúdenie vykonania týchto zmien a mal by ich riešiť proces zmeny.

Uzatvorenie požiadavky a spravodajstvo

Všetky požiadavky by sa mali formálne zrevidovať a uzavrieť. Môže to byť často také jednoduché ako spýtať sa používateľa, ktorý zaevidoval požiadavku, či je spokojný s odpoveďou a ponúknutým riešením.

Avšak formálne zrevidovanie a implementácia nápravných opatrení (ošetrenie príčin/y, zvyčajne podliehajúce riadeniu zmien) sú kritériami na konečné uzavretie degradácie a zlyhania služby, ktoré mali významný vplyv na biznis.

V týchto prípadoch je tiež rozumné vyhodnotiť trendy požiadaviek, aby sa potvrdilo, že riešená oblasť vykazuje výrazné zlepšenie z hľadiska kvality poskytovanej služby, s využitím analýzy trendov na vyhodnotenie dostupnosti služby a zlepšenie kapacity.

Prístup k service desku a dátam o procese riešenia by mali byť prístupný a anonymizovaný, čo sa týka súkromných informácií, predtým, ako budú zdieľané s inými disciplínami služby.

Podrobnejšie usmernenia sú v rámci procesu spravodajstva o službe.

Bežné úskalia

Aktivity odpovedania sú účinné len vtedy, ak sa v organizácii zachováva disciplinovaný prístup k zaznamenávaniu, sledovaniu, reagovaniu a riešeniu nečakaných situácií. To často znamená významné vzdelávanie zamestnancov zákazníka aj poskytovateľa služieb. Každý by mal pochopiť, čo sa robí, ako sa to robí a čo môže očakávať.
Agenti service desku, ktorí nedokážu vyriešiť väčšinu otázok na prvom bode kontaktu, nie sú nápomocní a neposkytujú správnu úroveň služieb. Mali by sme sa vyhnúť typickému prístupu „zachytiť a preposlať“, ktorý prijali mnohé organizácie – to nie je service desk, pretože nemá schopnosť poskytovať používateľom a iným spotrebiteľom hodnotu služby. Agenti service desku by mali byť v tomto procese dobre zbehlí a mali by mať správne zručnosti, informácie a technológiu na uľahčenie hladkého riešenia požiadaviek používateľov.
Metódy komunikácie by mali vyhovovať kontextu, v ktorom sú nasadené. Buďte opatrní s nasadzovaním svojpomocného zaznamenávania incidentov tam, kde nie sú významné zručnosti užívateľov a pochopenie kontextu služby. Poslanie e-mailu, na základe ktorého musí niekto zo service desku zavolať späť a znova zapísať požiadavku, nie je produktívne a predlžuje výpadok služby.
Zabezpečte, aby sa vyšetrili príčiny všetkých degradácií a zlyhaní služieb, ktoré mali významný vplyv na biznis a aby bola zavedená trvalá oprava na ošetrenie príčin.

ITSM.express Manual v 1.1 SK

Odpovedajte