Gauta žinutė: naudotojas negali prisijungti, spausdintuvas neveikia, serveris rodo klaidos pranešimus. Kažkas aptarnavimo centre tai paverčia bilietu, pasirenka kategoriją ir nustato skubumą. Ar tai gali perimti DI? Iš esmės taip, su viena svarbia išimtimi, kuri skiriasi pagal įmonę.
Lemiamą reikšmę turi trys ašys: apimtis, sprendimo laisvė ir klientų kontaktas.
Apimtis yra didelė. Aptarnavimo centras kasdien apdoroja dešimtis ar šimtus pranešimų, ir daugelis jų yra variacijos nedidelio skaičiaus žinomų problemų: pamirštas slaptažodis, nėra prieigos prie bendrinamo katalogo, nešiojamasis kompiuteris neįsijungia. Esant didelei apimčiai ir kartojimuisi, užduotis pagal apibrėžimą tinka automatizuoti, nes modelis mokosi iš dažnai kartojamų šablonų.
Sprendimo laisvė yra ribota. Skubumas ir kategorija dažniausiai išplaukia iš sprendimų medžio: kiek naudotojų paveikta, ar yra laikina išeitis, kuri sistema tai yra. Tai tiksliai tokio pobūdžio darbas, kuriame tekstiniai modeliai yra gerai: perskaityti pranešimą, išgauti požymius ir sulyginti su kategorizavimo modeliu. Tai, ką DI šiandien sugeba apdoroti, yra tekstas — patys pranešimai, dažnai laisva forma įrašyti naudotojo, ir jų pavertimas atgal į struktūruotą bilietą.
Klientų kontaktas yra funkcinis, ne santykinis. Naudotojas, kuris praneša apie gedimą, pirmiausia nori, kad tai būtų sprendžiama, o ne kad kiltų pokalbis. Situacija skiriasi, kai kas nutrūksta arba tampa jautru — apie tai žr. taip pat, kaip gedimas pranešamas naudotojams, nes tai yra kita užduotis su kitokiu profiliu.
Fizinis komponentas neturi reikšmės: tai administracinis darbas prie ekrano, ne veiksmas su įranga. Klaidos kaina yra vidutinė. Neteisingai prioritetizuotas pranešimas retai sukelia tiesioginę žalą, tačiau sistemose, kurioms taikoma atitiktis — finansinė sistema, paciento byla — situacija skiriasi, ir atitikties ašis šiuo atveju vertinama aukščiau nei vidutiniškai. Gedimas aplinkoje su teisine pranešimo pareiga reikalauja užfiksuoto klasifikavimo pagrindimo, ne tik žymos.
Silpnoji vieta yra kūrybiškumas, ir tai tiksliai kodėl tai nėra visiškas perėmimas. Pranešimas, kuris netelpa į žinomą šabloną — nauja simptomų kombinacija, sistema, kuri pirmą kartą nutrūksta, naudotojas, kuris neaiškiai aprašo problemą — reikalauja žmogaus, kuris mąsto, o ne klasifikuoja. Tam reikia priežiūros: DI pasiūlo kategoriją ir skubumą, žmogus patvirtina arba pakoreguoja, su pagrindimu. Tai kitokia struktūra nei visiškas perėmimas, ir tai taip pat dažniausia praktika įmonėse, kurios tai jau naudoja.
Įmonėje su nedidele, aiškia programų aplinka ir keliais šimtais naudotojų, devyniasdešimt procentų pranešimų yra kažko, kas jau kartojosi šimtą kartų, pasikartojimas. Ten modelis su geru kategorizavimo modeliu gali savarankiškai apdoroti didžiąją dalį priėmimo, o žmogus mato tik išimtis.
Įmonėje su daug pasenusių sistemų, individualiai pritaikytos programinės įrangos ir susijungimų istorija šablonas yra mažiau nuspėjamas. Pranešimai yra įvairesni, kategorijos mažiau aiškiai apibrėžtos, ir tikimybė, kad pranešimas neatitiks žinomo šablono, yra didesnė. Ten didesnė darbo dalis lieka žmogui, ne todėl, kad DI to nenorėtų daryti, bet todėl, kad įvestis yra pernelyg nestruktūruota, kad iš jos automatiškai gautųsi kažkas patikimo.
Taigi ribojanti sąlyga yra ne technologija, o priėmimas: struktūruotos priėmimo formos ir išplėtotas incidentų kategorizavimo modelis daugiausia nulemia, kiek šio darbo šiandien jau galima perduoti. Be šių dviejų dalykų didžioji dalis darbo išlieka rankinė, su DI kaip pagalbine priemone, o ne vykdytoju.
Tai nėra personalo patarimas ir ne pagrindimas mažinti aptarnavimo centro komandą. Ar ir kaip organizacija daro personalinius sprendimus dėl kintančio darbo, priklauso nuo darbdavio, ir tam taikomi atskiri teisiniai reikalavimai; dėl su tuo susijusio atsargumo žr. atsargumo aspektus mažinant pareigybes. Šis puslapis aprašo tik tai, kas vyksta su pačia užduotimi.
Naudinga taip pat nežiūrėti į šią užduotį atskirai nuo likusios IT veiklos. Incidentų registravimas siejasi su darbu, tokiu kaip sistemos veikimo stebėjimas, kuris dažnai duoda ankstyvus signalus dar prieš pranešimą, ir su valdymo užduotimis, tokiomis kaip atsarginių kopijų kūrimo ir tikrinimo ar pagrindinių duomenų valdymo ir atnaujinimo, kurios turi tą pačią didelės apimties ir ribotos sprendimo laisvės kombinaciją. Kas nori sužinoti, kur poslinkis jau vyksta visame IT skyriuje, geriausiai žiūri į visas užduotis kartu, ne į vieną bilietų procesą.
Jūsų aptarnavimo centro rezultatas priklauso nuo to, kiek jūsų pranešimų patenka į atpažįstamus šablonus ir kaip gerai jūsų priėmimas jau yra struktūruotas. Tai skiriasi pagal įmonę ir negali būti nusakoma fiksuota taisykle.
Nemokamas FTE TO AI greitasis testas suteikia tam pirminę nuorodą: dvylika klausimų, be paskyros, su nuoroda, kokią dalį jūsų profilio valandų šiandien galima perduoti DI. Visas darbo skenavimas, kuris visos įmonės darbą užduotis po užduoties perskaičiuoja į etatų pajėgumą, dar kuriamas.
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.