Gedimas užregistruotas, bilietų sistema rodo raudoną spalvą, ir naudotojai norės žinoti: kas vyksta, kiek tai dar užtruks ir kada jie sulauks kitos žinutės. Tai darbas, kurį techninės pagalbos ir komunikacijos specialistai atlieka kasdien. Klausimas čia nėra tas, ar DI gali rašyti tekstą, bet ar DI gali savarankiškai perimti šį konkretų komunikacijos darbą. Atsakymas: dalinai, ir tai labai priklauso nuo to, kokio pobūdžio yra gedimas.
Užduotis įvertinta aukštu struktūrizuotumo balu (4): gedimo pranešimas dažnai seka fiksuotą modelį — kas neveikia, nuo kada, kurios sistemos paveiktos, koks numatomas pašalinimo laikas. Tas modelis yra tiksliai tai, ką kalbos modelis gali gerai užpildyti, jei tik pagrindinė informacija yra tiksli. Taip pat fiziškumas (5) nėra kliūtis: nereikia jokio veiksmo realiame pasaulyje, tik teksto, kurį reikia išsiųsti.
Tačiau klientų kontaktas įvertintas žemai (1). Tai iš esmės komunikacija su žmonėmis, kurie dažnai jau yra nusivylę, nes jų darbas sustojo. Žinutės tonas, momentas ir tikslumas nulemia, ar naudotojai jaučiasi išklausyti, ar priešingai — ignoruojami. Sugeneruotas pranešimas, kuris yra faktiškai tikslus, bet neteisingai įvertina skubumą, padaro daugiau žalos nei jo nebuvimas.
Klaidų kaina (3) yra vidutinė, bet ne nereikšminga: neteisingas pašalinimo laikas arba būsena, kuri neatnaujinama, mažina pasitikėjimą ir sukelia papildomų klausimų srautą — tiksliai tą darbą, kurį norėjote sutaupyti. Atitiktis (4) įsijungia, kai incidentas patenka į SLA susitarimų ar, kai kuriuose sektoriuose, pareigos informuoti sritį: tada komunikacija turi būti įrodomai išsiųsta laiku ir pagal nustatytus standartus. Sprendimo laisvė (2) ir kūrybiškumas (2) yra žemi: liko mažai laisvės patiems nusprendus, ką pranešti, tai daugiausia šablono su aktualiais duomenimis sekimas. Apimtis (4) yra didelė: didelio gedimo atveju kalbama apie šimtus ar tūkstančius naudotojų, kuriems reikia to pačio pranešimo, ir tai tiksliai ta sritis, kur automatizavimas sutaupo laiko.
Trys ašys nulemia bendrą vaizdą. Struktūrizuotumas daro tai technologiškai įmanomu: jei incidento būsena vienareikšmiškai fiksuojama sistemoje, kalbos modelis gali iš to sudaryti pranešimą pagal fiksuotą šabloną. Bet žemas klientų kontaktas tai stabdo — ne todėl, kad DI negali parašyti taisyklingo sakinio, bet todėl, kad neteisingu laiku ar netinkamu tonu pateikto pranešimo rizika yra didesnė nei vidinio ar administracinio teksto atveju. Ir klaidų kaina reiškia, kad priežiūra tebėra būtina: būsenos atnaujinimas, kuris išsiunčiamas prieš patvirtinant taisymą, arba kuris pernelyg optimistiškai įvertina pašalinimo laiką, sukelia naujų skundų, o ne mažina jų.
Pavyzdys tai paaiškina konkrečiai. Vidinio el. pašto sistemos gedimo atveju, kai poveikis žinomas ir pašalinimo laikas gana nuspėjamas, DI gali sudaryti pirminį pranešimą ir tarpinį būsenos atnaujinimą pagal bilietą, o darbuotojas trumpai patvirtina prieš pranešimo išsiuntimą. Gedimo, paveikiančio klientų mokėjimo funkcionalumą, kai yra finansinių padarinių ir neapibrėžtas pašalinimo laikas, atveju situacija kitokia: čia reikalingas žmogaus vertinimas, ką sakyti, ko nesakyti ir kada tai daryti.
Įmonėje su išplėtota būsenos puslapiu ir bilietų sistema, kuri automatiškai užpildo reikiamus laukus, DI galima pavesti didesnę dalį darbo: tekstas gali būti sudarytas tiesiai iš struktūrizuotų duomenų. Įmonėje, kur gedimai perduodami žodžiu, atskiruose Slack pranešimuose ar per IT vadovą, kuris pats įvertina situaciją, trūksta struktūrizuoto pagrindo, ir mažai kas gali būti savarankiškai sudaryta DI. Taip pat svarbi ir naudotojų prigimtis: vidiniai darbuotojai priima trumpą, faktinį atnaujinimą; išoriniai klientai su sutartimi ir SLA tikisi tono ir išsamumo, kuris labiau reikalauja žmogaus kontrolės.
Ši užduotis nėra atskirta nuo likusios incidentų grandinės. Ar gedimas komunikuojamas efektyviai, priklauso nuo to, kaip gerai stebima sistemų veikla — be patikimo stebėjimo nėra aktualios būsenos, kurią būtų galima komunikuoti. Tai taip pat susiję su tuo, kaip incidentas registruojamas ir prioritetizuojamas, nes tai nulemia, kokie duomenys yra prieinami pranešimui sudaryti. Ir kai kuriais atvejais komunikacija vyksta paraleliai su faktiniu pirmos linijos IT incidento sprendimu, kur atnaujinimas yra tik toks geras, koks yra faktiškai padarytas pažangumas.
Konkrečiai: teksto sudarymas pagal fiksuotus šablonus, su aktualia incidento būsena kaip įvestimi, yra įmanomas, kai yra šios dvi sąlygos. Sprendimas, kada pranešimas išsiunčiamas, kokiu tonu ir ar pašalinimo laikas suformuluotas realistiškai, tebėra darbuotojo rankose. Tai nėra tarpinis etapas kelyje į pilną perėmimą — tai struktūra, kuri tinka šio tipo komunikacijai tol, kol netinkamo pranešimo klaidų kaina viršija laiką, kurio reikia jį patikrinti.
Jei šis analizė paskatina jus susimąstyti apie techninės pagalbos ar komunikacijos specialistų darbo vietas, tam taikomi atskiri teisiniai reikalavimai, susiję su darbu ir darbuotojų atstovavimu; šis puslapis nesuteikia personalo valdymo patarimų ir nėra pagrindas atleidimo sprendimui. Dėl platesnio rūpestingumo, susijusio su pareigybių keitimu, žr. rūpestingumas, naikinant pareigybes.
Norite žinoti, kiek gedimų komunikacijos jūsų įmonėje šiandien jau atitinka šias sąlygas? Nemokamas FTE TO AI greitasis patikrinimas susideda iš dvylikos klausimų, nereikalauja paskyros ir suteikia orientacinį įvertinimą, kokią dalį šio profilio valandų šiandien galima perduoti DI. Pilna darbo analizė, su išsamia užduočių analize kiekvienai komandai, dar kuriama — jos čia sąmoningai kol kas nepasiūlome.
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.