Darbības traucējums ir pieteikts, biļešu sistēmā deg sarkans, un lietotāji vēlas zināt: kas notiek, cik ilgi tas vēl ilgs, un kad viņi saņems nākamo ziņu. Tas ir darbs, ko servisa dienesta un komunikācijas darbinieki veic ikdienā. Šeit jautājums nav par to, vai MI var uzrakstīt tekstu, bet gan par to, vai MI var patstāvīgi pārņemt tieši šo komunikācijas darbu. Atbilde: daļēji, un tas lielā mērā ir atkarīgs no tā, kāda veida darbības traucējums tas ir.
Uzdevums iegūst augstu novērtējumu strukturētības ziņā (4): darbības traucējuma paziņojums bieži seko fiksētam modelim — kas nav kārtībā, kopš kura brīža, kuras sistēmas ir skartas, kāds ir paredzamais novēršanas laiks. Šis modelis ir tieši tas, ko valodas modelis var labi aizpildīt, ja vien pamatā esošā informācija ir pareiza. Arī fiziskums (5) nav šķērslis: nav vajadzīga nekāda darbība reālajā pasaulē, tikai teksts, kas jāizsūta.
Turpretī klientu kontakts iegūst zemu novērtējumu (1). Tā pēc definīcijas ir komunikācija ar cilvēkiem, kuri bieži jau ir frustrēti, jo viņu darbs ir apstājies. Ziņojuma tonis, brīdis un precizitāte nosaka, vai lietotāji jūtas sadzirdēti vai tieši pretēji — ignorēti. Ģenerēts ziņojums, kas ir faktiski pareizs, bet nepareizi novērtē steidzamību, rada vairāk kaitējuma nekā ziņojuma neesamība.
Kļūdu izmaksas (3) ir mērenas, bet ne nenozīmīgas: nepareizs novēršanas laiks vai statuss, kas netiek atjaunināts, mazina uzticību un rada virkni papildu jautājumu — tieši to darbu, ko vēlējāties ietaupīt. Atbilstība (4) kļūst nozīmīga, tiklīdz incidents ietilpst SLA vienošanās ietvaros vai, dažās nozarēs, paziņošanas pienākumā: tad komunikācijai jābūt pierādāmi savlaicīgai un atbilstošai fiksētiem standartiem. Lēmumu pieņemšanas brīvība (2) un radošums (2) ir zemi: ir maz telpas pašam noteikt, ko paziņot, tas lielākoties ir veidnes ievērošana ar aktuāliem datiem. Apjoms (4) ir augsts: liela darbības traucējuma gadījumā runa ir par simtiem vai tūkstošiem lietotāju, kuriem nepieciešams tas pats ziņojums, un tieši tur automatizācija atbrīvo laiku.
Trīs asis nosaka kopainu. Strukturētība padara to tehniski iespējamu: ja incidenta statuss sistēmā ir viennozīmīgi fiksēts, valodas modelis no tā var izveidot ziņojumu pēc fiksētas veidnes. Taču zemais klientu kontakta rādītājs to bremzē — nevis tāpēc, ka MI nevar uzrakstīt pareizu teikumu, bet tāpēc, ka nepareizi laika ziņā izvēlēta vai nepareizā tonī veidota paziņojuma risks ir lielāks nekā iekšēja vai administratīva teksta gadījumā. Un kļūdu izmaksas nosaka, ka uzraudzība joprojām ir nepieciešama: statusa atjauninājums, kas tiek nosūtīts, pirms ir apstiprināts risinājums, vai kas pārāk optimistiski novērtē novēršanas laiku, rada jaunas sūdzības, nevis mazina tās.
Piemērs to padara konkrētu. Iekšēja e-pasta sistēmas darbības traucējuma gadījumā, kur ietekme ir zināma un novēršanas laiks ir samērā paredzams, MI var sagatavot pirmo paziņojumu un starplaika statusa atjauninājumu, pamatojoties uz biļeti, ar darbinieku, kurš to īsi apstiprina pirms ziņojuma nosūtīšanas. Darbības traucējuma gadījumā, kas skar klientu maksājumu funkcionalitāti, ar finansiālām sekām un neskaidru novēršanas laiku, situācija ir citāda: tur nepieciešams cilvēka vērtējums par to, ko teikt un ko nē, un kad.
Uzņēmumā ar nobriedušu statusa lapu un biļešu sistēmu, kas automātiski aizpilda pareizos laukus, MI spēju daļa ir lielāka: tekstu var tieši veidot no strukturētiem datiem. Uzņēmumā, kur darbības traucējumi tiek paziņoti mutiski, atsevišķos Slack ziņojumos vai caur IT vadītāju, kurš to novērtē pats, strukturētā bāze trūkst, un ir maz, ko MI var patstāvīgi sagatavot. Nozīme ir arī lietotāju veidam: iekšējie darbinieki pieņem īsu, faktoloģisku atjauninājumu; ārējie klienti ar līgumu un SLA sagaida toni un pilnīgumu, kas drīzāk prasa cilvēka kontroli.
Šis uzdevums nav nošķirts no pārējās incidentu ķēdes. Vai darbības traucējums tiek efektīvi komunicēts, ir atkarīgs no tā, cik labi tiek uzraudzīta sistēmas veiktspēja — bez uzticamas uzraudzības nav aktuāla statusa, ko komunicēt. Tas ir saistīts arī ar to, kā incidents tiek reģistrēts un prioritizēts, jo tas nosaka, kādi dati ir pieejami, lai uz tiem balstītu ziņojumu. Un dažos gadījumos komunikācija norit paralēli faktiskajai pirmā līmeņa IT incidenta risināšanai, kur atjauninājums ir tikai tik labs, cik labs ir faktiski panāktais progress.
Konkrēti: teksta sagatavošana, pamatojoties uz fiksētām veidnēm, ar aktuālo incidenta statusu kā ievades datu, ir iespējama, tiklīdz šie divi priekšnoteikumi ir izpildīti. Lēmums par to, kad ziņojums tiek nosūtīts, kādā tonī, un vai novēršanas laiks ir reāli formulēts, paliek darbinieka ziņā. Tā nav starpposma fāze ceļā uz pilnīgu pārņemšanu — tā ir struktūra, kas atbilst šāda veida komunikācijai, kamēr nevietā izteikta ziņojuma kļūdu izmaksas ir augstākas par laiku, kas nepieciešams tā pārbaudei.
Ja šī analīze liek jums padomāt par servisa dienesta vai komunikācijas darbinieku nodarbinātību, tad uz to attiecas savas likumīgās prasības par darbu un līdzdalību; šī lapa nesniedz personāla konsultācijas un nav pamatojums atlaišanas lēmumam. Par plašāku rūpību saistībā ar amatu izmaiņām skatiet rūpība amatu likvidēšanā.
Vai vēlaties uzzināt, cik liela daļa darbības traucējumu komunikācijas jūsu uzņēmumā jau šodien atbilst šiem priekšnoteikumiem? FTE TO AI bezmaksas ātrā pārbaude sastāv no divpadsmit jautājumiem, neprasa kontu, un sniedz norādi par to, kādu daļu no šī profila stundām MI jau šodien var pārņemt. Pilnais darba audits, ar detalizētu uzdevumu analīzi katrai komandai, vēl tiek izstrādāts — to šeit apzināti vēl nepiedāvājam.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.