Wpływa zgłoszenie: użytkownik nie może się zalogować, drukarka nie działa, serwer wyświetla komunikaty o błędach. Ktoś na service desku przekształca to w zgłoszenie (ticket), wybiera kategorię i określa priorytet. Czy AI może to przejąć? W dużej mierze tak, z jednym istotnym wyjątkiem, który różni się w zależności od firmy.
Rozstrzygają trzy osie: wolumen, przestrzeń oceny i kontakt z klientem.
Wolumen jest wysoki. Service desk przetwarza codziennie od kilkudziesięciu do kilkuset zgłoszeń, a wiele z nich to warianty niewielkiej liczby znanych problemów: zapomniane hasło, brak dostępu do udziału sieciowego, laptop nie uruchamia się. Przy wysokich wolumenach i powtarzalności zadanie z definicji nadaje się do automatyzacji, ponieważ model uczy się na wzorcach, które często się powtarzają.
Przestrzeń oceny jest ograniczona. Priorytet i kategoria wynikają zwykle z drzewa decyzyjnego: ile użytkowników jest dotkniętych, czy istnieje rozwiązanie zastępcze, jakiego systemu to dotyczy. To właśnie rodzaj pracy, w którym modele tekstowe są dobre: przeczytanie zgłoszenia, wyodrębnienie z niego cech i porównanie ich z modelem kategoryzacji. To, co AI dziś potrafi obsłużyć, to tekst — same zgłoszenia, często wpisywane przez użytkownika w swobodnej formie, oraz przekształcenie tego z powrotem w ustrukturyzowany ticket.
Kontakt z klientem jest funkcjonalny, nie relacyjny. Użytkownik zgłaszający awarię przede wszystkim chce, żeby zajęto się problemem, a nie żeby powstała rozmowa. Sytuacja wygląda inaczej, gdy coś idzie nie tak lub staje się wrażliwe — zobacz w tym celu również, jak komunikuje się awarię do użytkowników, ponieważ to inne zadanie o innym profilu.
Składnik fizyczny nie odgrywa roli: to praca administracyjna przy ekranie, nie czynność przy urządzeniach. Koszty błędu są średnie. Nieprawidłowo priorytetyzowane zgłoszenie rzadko prowadzi do bezpośredniej szkody, ale w przypadku systemów objętych zgodnością (compliance) — systemu finansowego, dokumentacji pacjenta — sytuacja wygląda inaczej, i oś zgodności ocenia się tu wyżej niż średnio. Awaria w środowisku z ustawowym obowiązkiem zgłaszania wymaga udokumentowanego uzasadnienia klasyfikacji, nie tylko etykiety.
Słabym punktem jest kreatywność, i właśnie dlatego nie jest to pełne przejęcie. Zgłoszenie, które nie wpisuje się w znany wzorzec — nowa kombinacja symptomów, system, który zawodzi po raz pierwszy, użytkownik, który niejasno opisuje problem — wymaga kogoś, kto myśli, a nie tylko klasyfikuje. Wiąże się z tym nadzór: AI proponuje kategorię i priorytet, człowiek zatwierdza lub koryguje, z uzasadnieniem. To inna konfiguracja niż pełne przejęcie i jest to też najczęściej spotykana praktyka w firmach, które już z tym pracują.
W firmie z niewielkim, przejrzystym krajobrazem aplikacji i kilkuset użytkownikami dziewięćdziesiąt procent zgłoszeń to powtórzenie czegoś, co już wystąpiło setki razy. Tam model z dobrym modelem kategoryzacji może samodzielnie obsłużyć większą część przyjmowania zgłoszeń, a człowiek widzi tylko wyjątki.
W firmie z wieloma systemami legacy, oprogramowaniem szytym na miarę i historią fuzji wzorzec jest mniej przewidywalny. Zgłoszenia są bardziej zróżnicowane, kategorie są mniej wyraźnie zdefiniowane, a szansa, że zgłoszenie wypadnie poza znany wzorzec, jest większa. Tam większa część pracy pozostaje przy człowieku, nie dlatego, że AI nie chciałaby jej wykonać, ale ponieważ dane wejściowe są zbyt nieustrukturyzowane, aby automatycznie zrobić z nich coś wiarygodnego.
Warunkiem granicznym nie jest więc technika, lecz przyjmowanie zgłoszeń: ustrukturyzowane formularze zgłoszeniowe i dopracowany model kategoryzacji incydentów w dużej mierze determinują, jaka część tej pracy jest już dziś przekazywalna. Bez tych dwóch elementów większa część pracy pozostaje pracą manualną, z AI jako pomocą, nie wykonawcą.
To nie jest porada personalna ani uzasadnienie dla redukcji zespołu service desku. Czy i jak organizacja wyciąga konsekwencje personalne ze zmieniającej się pracy, zależy od pracodawcy, i obowiązują tu odrębne wymogi prawne; zobacz w tym zakresie punkty uwagi przy likwidacji funkcji. Ta strona opisuje wyłącznie to, co dzieje się z samym zadaniem.
Warto również nie postrzegać tego zadania w oderwaniu od resztry operacji IT. Rejestracja incydentów jest związana z pracą taką jak monitorowanie wydajności systemów, które często dają wczesne sygnały, jeszcze zanim powstanie zgłoszenie, oraz z zadaniami zarządczymi, takimi jak wykonywanie i kontrola kopii zapasowych czy utrzymywanie aktualności danych podstawowych, które charakteryzują się tą samą kombinacją wysokiego wolumenu i ograniczonej przestrzeni oceny. Kto chce wiedzieć dla całego działu IT, gdzie już nastąpiło przesunięcie, najlepiej spojrzy na wszystkie zadania razem, nie na jeden proces obsługi zgłoszeń.
Wynik dla własnego service desku zależy od tego, jaka część zgłoszeń wpisuje się w rozpoznawalne wzorce i jak dobrze ustrukturyzowane jest już przyjmowanie zgłoszeń. To różni się w zależności od firmy i nie da się tego określić stałą praktyczną zasadą.
Bezpłatny quickscan FTE TO AI daje pierwszą wskazówkę w tym zakresie: dwanaście pytań, bez konta, ze wskazaniem, jaka część godzin w państwa profilu jest dziś do przejęcia przez AI. Pełny werkscan, który przelicza pracę całej firmy zadanie po zadaniu na pojemność fte, jest wciąż w budowie.
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.