System ticketingowy wygląda na papierze przejrzyście. Widzisz liczby, kolejki, pulpity nawigacyjne, ale w rzeczywistości ten model mierzy problemy dopiero wtedy, gdy system już zawiódł. Kosztowna część problemu zazwyczaj zaczyna się znacznie wcześniej. Zaczyna się, gdy pracownik traci 10 minut, potem 20, a w końcu po prostu się poddaje. Próbuje ponownie, prosi współpracownika, nie pojawia się na spotkaniu lub udostępnia niewłaściwy plik, ponieważ prawidłowa ścieżka przestała działać. I to jest ta część, której większość zespołów wsparcia wciąż nie dostrzega. Najlepszy wewnętrzny model wsparcia nie polega na szybszej triażu. Chodzi o całkowite wyeliminowanie potrzeby triażu. Wyobraź sobie autonomicznego agenta w Microsoft 365, który monitoruje kontekst, wcześniej wykrywa tarcia i działa, zanim ktoś pomyśli o otwarciu portalu. W tym odcinku chcę pokazać, dlaczego model helpdesku się psuje, co go faktycznie zastępuje i jak można nim zarządzać bez tworzenia chaosu.

Jeśli ta zmiana ma znaczenie dla Twojej pracy, zasubskrybuj M365FM, ponieważ o poziom głębi prawdziwym problemem nie jest kolejka, ale model, który za nią stoi. Śmierć zgłoszenia, stary przepływ pomocy technicznej wciąż jest wszechobecny. Coś się psuje, użytkownik to zauważa. Użytkownik próbuje to wyjaśnić. Następnie dział IT tłumaczy to wyjaśnienie na kategorię priorytet i ewentualnie grupę zadań. Zgłoszenie trafia do kolejki. Ktoś je triażuje. Ktoś inny prosi o więcej szczegółów. Inny zespół się angażuje. Czas płynie, podczas gdy praca stoi w miejscu. Ten proces wydaje się normalny, ponieważ jest znajomy, ale znajomy i skuteczny to nie to samo. Zgłoszenie to nie pomoc techniczna. Zgłoszenie to dowód na to, że pomoc techniczna dotarła z opóźnieniem. Zanim zgłoszenie w ogóle powstanie, pracownik już napotkał tarcie i stracił kontekst. Odwrócił już swoją uwagę od pracy, którą próbował wykonać.

Kolejka to nie usługa. Kolejka to rejestr awarii. W dużych środowiskach Microsoft 365 ręczna triaż staje się prawdziwym punktem zapalnym. Nie dzieje się tak dlatego, że zespoły pomocy technicznej są leniwe. Dzieje się tak, ponieważ ludzie są proszeni o wykonanie czegoś, co już nie pasuje do skali środowiska. Masz więcej użytkowników, więcej urządzeń, więcej aplikacji, więcej zasad. Masz więcej przypadków brzegowych, które przecinają zespoły SharePoint, Exchange, Intune i Entra w tym samym czasie. Nie tylko rośnie liczba zgłoszeń. Rosną również kombinacje. To właśnie tutaj stary model zawodzi. Większość zespołów reaguje, dodając więcej struktury. Budują kolejny portal, kolejnego bota lub kolejną regułę routingu. Ale w rzeczywistości dodaje to tylko kolejną warstwę między pracownikiem a rozwiązaniem. System wciąż czeka, aż użytkownik zauważy problem, opisze go i poprosi o pomoc we właściwy sposób.

Praca nie zaczyna się w portalu pomocy technicznej, zaczyna się w Teams, zaczyna się w Outlooku, zaczyna się w dokumencie, którego ktoś potrzebuje natychmiast lub na spotkaniu, które rozpoczyna się za 30 sekund. To właśnie tam zaczyna się zapotrzebowanie na wsparcie, a model zgłoszeń jest całkowicie oderwany od tego momentu. Ukryty koszt jest znacznie wyższy niż pokazuje raport z kolejki. Kontakty między osobami się zmieniają. Duplikaty zgłoszeń gromadzą się pod różnymi etykietami. Artykuły z bazy wiedzy stają się nieaktualne. Analitycy spędzają cały dzień na sortowaniu routingu i wyjaśnianiu, zamiast faktycznie naprawiać problemy. Czas rozwiązania problemu wydłuża się, ponieważ każde przekazanie powoduje opóźnienie, a każde opóźnienie usuwa pierwotny kontekst. Badania nad agentową sztuczną inteligencją i operacjami IT wskazują na ten sam problem strukturalny. Co najmniej 80% wysiłku jest nadal uwięzione w reaktywnej pracy w stylu ITIL.

Ta liczba ma znaczenie, ponieważ wskazuje dokładnie, dokąd zmierza praca. Nie jest ona przeznaczona na odporność ani zapobieganie, lecz na reakcję. Kiedy to zauważysz, zgłoszenie zaczyna wyglądać mniej jak model operacyjny, a bardziej jak symptom. To symptom systemu, który reaguje dopiero po zauważeniu uszkodzenia. Zatem kolejne pytanie nie brzmi, jak szybciej przetwarzać zgłoszenia, ale co system powinien zrobić, zanim zgłoszenie będzie w ogóle potrzebne. Model niewidzialnego pracownika. Co więc tak naprawdę zastępuje zgłoszenie? To nie jest kolejny hotbot siedzący na tym samym bałaganie, ani z pewnością nie jest to ładniejsza brama do tej samej starej kolejki. Zmiana sięga znacznie głębiej, ponieważ niewidzialny pracownik to pracownik operacyjny działający w środowisku Microsoft 365. Ten agent ma swoją własną tożsamość, zdefiniowany zakres pracy, pamięta, co robił wczoraj i ścisłe zasady dotyczące tego, co może, a czego nie może robić.

To rozróżnienie ma znaczenie. Hotbot czeka, aż wpiszesz monit, ale niewidzialny pracownik obserwuje zmiany warunków. Zaczyna od kontekstu, a nie od rozmowy. Ponieważ widzi stany logowania, stan urządzenia, status licencji i sposób udostępniania plików, nie musi czekać na pojawienie się problemów. Zamiast pytać, jak może pomóc, gdy coś się zepsuje, ciągle zadaje inne pytanie w tle. Co odbiega od stanu, którego pracownik potrzebuje do wykonywania swojej pracy w danej chwili? To właśnie tutaj wszystko się zmienia. Model jest osadzony bezpośrednio w samej pracy. Gdy ktoś dołącza do spotkania i przekierowywanie audio zawodzi lub gość, nie może otworzyć pliku, który właśnie otrzymał. Stary model tworzy raport i przekazuje zadanie. W nowym modelu agent natychmiast widzi wzorzec, sprawdza, czy warunek pasuje do znanego problemu i podejmuje następne bezpieczne działanie, aby go rozwiązać. Być może resetuje ścieżkę, uruchamia sprawdzanie zasad, a może przekierowuje żądanie i uruchamia uwierzytelnianie wieloskładnikowe MFA przed udokumentowaniem poprawki.

Chodzi o to, że pierwsza odpowiedź nie wymaga już od człowieka przeczytania niejasnego opisu i zgadywania, co się stało. To wydaje się niewidoczne, gdy działa dobrze, ponieważ nie ma poczekalni ani formularza, proszę wybrać kategorię do wypełnienia. Wsparcie pojawia się jako przywrócony przepływ. Pracownik po prostu wraca do pracy i w wielu przypadkach nawet nie widzi mechanizmów działających za kulisami. Już teraz widać, jak zmienia to logikę zatrudnienia. Stary model zatrudniał osoby do obsługi dużej liczby zgłoszeń, sortowania żądań i usuwania uszkodzonych kontekstów między różnymi zespołami. Nowy model wymaga mniejszej liczby osób zajmujących się triażem, a większej liczby osób projektujących zabezpieczenia, definiujących pożądane stany i nadzorujących zachowanie agentów w czasie. Ludzie pozostają w systemie, ale cały przebieg ich codziennej pracy ulega zmianie. Badania nad agentową sztuczną inteligencją w wsparciu wciąż wskazują na ten kierunek.

Rutynowe wsparcie może ewoluować w kierunku obsługi opartej na wyjątkach, co generuje ogromny wzrost wydajności, gdy środowisko i zasady są dobrze ograniczone. Ta ostatnia część jest kluczowa, ponieważ to nie magia. Jeśli twoje dane są słabe lub proces chaotyczny, agent nie stanie się inteligentny tylko dlatego, że zdecydujesz się nazwać go autonomicznym. Wszystko to stało się dla mnie jasne, gdy przestałem myśleć o agencie jako o funkcji oprogramowania i zacząłem postrzegać go jako pracownika z identyfikatorem, który nie jest człowiekiem. Prawdziwy pracownik potrzebuje tożsamości opisu stanowiska uprawnień i przełożonego, któremu podlega. Agent potrzebuje dokładnie tych samych rzeczy, ponieważ wartość płynie z niezawodnego działania w systemie, a nie z inteligentnego języka w oknie czatu. Niewidzialny pracownik to nie sztuczka interfejsu użytkownika. To nowa warstwa wsparcia, która monitoruje tarcia w całym środowisku Microsoft 365, działa zgodnie z zasadami i kieruje uwagę człowieka na wyjątki, które faktycznie wymagają oceny.

Gdy ten model jest jasny, kolejne pytanie staje się bardzo praktyczne. Jak właściwie działa wywłaszczanie? Architektura wywłaszczania. Jak więc właściwie działa wywłaszczanie w Microsoft 365? Przejście od żądania i odpowiedzi do wnioskowania o zdarzeniach i ich orkiestracji. Brzmi to technicznie, ale model jest prosty, gdy się go rozłoży na czynniki pierwsze. Najpierw coś w środowisku ulega zmianie, następnie system interpretuje, czy ta zmiana oznacza ryzyko, czy dryf, a na końcu podejmuje zatwierdzoną akcję, korzystając z narzędzi już dostępnych w stosie. Zacznij od warstwy zdarzeń. Microsoft 365 generuje już sygnały wszędzie, co oznacza, że Entra monitoruje zachowania logowania, podczas gdy Intune śledzi stan i zgodność urządzenia. Defender monitoruje podejrzaną aktywność, a Teams pokazuje dokładnie, kiedy spotkanie się nie powiedzie lub jakość połączeń spadnie. SharePoint i Exchange ujawniają wzorce dostępu i aktywność treści, a sygnały dotyczące kondycji usług informują, kiedy problem leży po stronie samej platformy.

Dodając do tego działania użytkowników, otrzymujesz stały strumień kontekstu. Większość organizacji gromadzi te sygnały, ale bardzo niewiele z nich faktycznie wykorzystuje je jako system wsparcia. Same surowe zdarzenia nie pomagają, ponieważ potrzebują warstwy wnioskowania, aby zrozumieć szum. To tutaj niewidzialny pracownik przestaje być teatrem automatyzacji i zaczyna działać jak prawdziwy operator. Agent analizuje sygnał, porównuje stan bieżący ze stanem docelowym i decyduje, jaką klasę działań można bezpiecznie podjąć. Problem z dźwiękiem podczas spotkania to nie to samo, co ryzykowne logowanie, a uszkodzony link udostępniania to co innego niż niezgodność licencji. Agent musi najpierw sklasyfikować problem, ponieważ podejmowanie działań bez klasyfikacji tylko przyspiesza powstawanie błędów. Następnie następuje orkiestracja. Gdy agent zrozumie problem, może użyć odpowiedniego mechanizmu, aby zareagować.

Może to być power automaty dla przepływów pracy, kopilot studio dla logiki lub Microsoft Graph dla działań systemowych i kontekstu. Narzędzia mają znaczenie, ale ważniejsze jest to, jak są one ze sobą powiązane. Nie tworzysz jednego inteligentnego monitoru, ale raczej łańcuch, który może wykrywać, podejmować decyzje, działać i weryfikować. Ta ostatnia część jest ciągle pomijana. System samokorygujący nie zatrzymuje się po podjęciu działania. Uruchamia pętlę, w której wykrywa problem, testuje stan, stosuje poprawkę i weryfikuje wynik, zanim zarejestruje to, co się stało. Badania nad samokorygującymi się logikami jasno pokazują, że systemy te działają poprzez sprzężenie zwrotne i wzorce korekcji, a nie jedną odizolowaną odpowiedź z modelu językowego. Jeśli pierwsza czynność się nie powiedzie, system musi mieć możliwość oceny przyczyny, aby móc zmodyfikować kolejny krok, nie przekraczając zdefiniowanych limitów.

Można to sobie wyraźnie wyobrazić na przykładzie kilku przypadków z Microsoft 365, gdy użytkownik zostaje zablokowany z powodu niezgodności licencji i zakresu zasad. Agent wykrywa niezgodność i sprawdza odpowiedni profil roli. Stosuje dozwoloną korektę, potwierdza, że użytkownik ma dostęp i rejestruje zmianę bez pytania. Jeśli w Entra pojawi się ryzykowne logowanie, agent widzi to zdarzenie i natychmiast sprawdza reguły dostępu warunkowego. Monituje o silniejszą weryfikację lub blokuje dostęp na podstawie zasad, a następnie rejestruje wynik do późniejszego przeglądu przez użytkownika. Gdy nieaktualny link udostępniania ciągle nie działa w programie SharePoint, agent porównuje bieżącą ścieżkę uprawnień z oczekiwanymi regułami udostępniania. Zastępuje uszkodzony link główny zatwierdzonym i wysyła poprawiony link w kontekście, co zamyka pętlę, zanim analityk techniczny będzie musiał zapoznać się z biletem zatytułowanym Pilny problem z dostępem.

Wsparcie podczas spotkań to kolejny świetny przykład. Jeśli urządzenie w pokoju ulegnie awarii lub ścieżka do łączania zostanie przerwana na kilka sekund przed rozpoczęciem połączenia, agent może wykryć problem i zweryfikować usterkę. Próbuje wykonać krok odzyskiwania o niskim ryzyku i powiadamia organizatora w Teams o aktualnym stanie pracy w miejscu, w którym jest ona wykonywana. Ta warstwa komunikacji stanowi istotną część projektu. Wsparcie musi działać tam, gdzie występuje przerwa. Jeśli praca jest wykonywana w Teams Outlooku i obszarze roboczym M365, wsparcie powinno również tam udzielić odpowiedzi. Nie musisz przeciągać użytkownika w inne miejsce, gdy możesz spotkać się z wydarzeniem w kontekście. Nie oznacza to jednak pełnego zakresu zadań dla każdego zadania, ponieważ byłoby to lekko myślne. Działania o niskim ryzyku mogą być uruchamiane automatycznie, ale zmiany o dużym wpływie nadal wymagają zatwierdzenia przez osobę.

Ta ścieżka zatwierdzania musi być częścią architektury od samego początku, a nie być dodawana później. Agent powinien wiedzieć, kiedy działać, kiedy pytać i kiedy dokładnie przerwać. A gdy już to wbudujesz w przepływ, rozmowa przestaje dotyczyć funkcji automatyzacji. Staje się kwestią kontroli, zarządzania, zaufania i tożsamości agenta. Kiedy wsparcie techniczne zaczyna działać samodzielnie, natychmiast pojawia się trudne pytanie. Kto właściwie wykonuje pracę? Jeśli ta odpowiedź jest niejasna, cały model się rozpada. Agent nie może istnieć w Twoim środowisku jako rozmyty pomocnik z szerokim dostępem i bezwyraźnego właściciela. Potrzebuje prawdziwej tożsamości w Entra. Potrzebuje nazwanego właściciela zdefiniowanego zakresu i cyklu życia, który zaczyna się i kończy z konkretnego powodu. Jeśli agent może odczytywać dane, uruchamiać przepływy pracy lub wysyłać wiadomości do użytkowników, musisz nim zarządzać jak aktywnym uczestnikiem dzierżawy.

Nie możesz traktować go jak funkcji, którą ktoś włączył, a potem o niej zapomniał. Dlatego tożsamość agenta jest tak kluczowa dla systemu. Musisz dokładnie wiedzieć, czym jest agent, z których systemów może korzystać i kto odbiera połączenie, gdy sytuacja zaczyna się komplikować. Najniższe uprawnienia muszą być tutaj podstawą. Nie możesz poprzestać na szerokiej wygodzie ani wmawiać sobie, że później zaostrzysz uprawnienia. Ponieważ zasięg agenta wsparcia zależy wyłącznie od jego uprawnień, ich zaprojektowanie jest kluczowym elementem projektowania wsparcia. Agent 365 pełni w tym rozwiązaniu funkcję niezbędnej warstwy kontrolnej, ponieważ zapewnia przejrzysty wgląd w cały zasób agentów. Zapewnia rejestr przepływy pracy związane z zatwierdzaniem i szablony zasad, które zapewniają bezpieczne działanie. Choć te elementy mogą wydawać się zadaniami administracyjnymi, rozwiązują one poważny problem strukturalny.

Większość organizacji boryka się z problemami nie z powodu braku funkcji sztucznej inteligencji, ale z powodu braku wglądów w to, co już działa w ich środowisku, ani możliwości kontrolowania tego, co już działa. Badania w tym zakresie są jednoznaczne. Tylko niewielka część dużych przedsiębiorstw jest w stanie w pełni zinwentaryzować wszystkich agentów aktualnie działających w ich systemie. Zanim liderzy zaczną mówić o skalowaniu autonomicznego wsparcia, muszą odpowiedzieć na znacznie prostsze pytanie. Czy w ogóle wiemy, którzy agenci istnieją i co robią w danej chwili? Nadzór musi być również dostosowany do poziomu ryzyka. Agent produktywności osobistej pracujący w wąskim zakresie to jedno, ale agent współpracujący, który zajmuje się współdzielonymi treściami, to zupełnie inna sprawa. Następnie mamy agentów korporacyjnych podejmujących działania w ramach wrażliwych przepływów pracy, co plasuje się w innej kategorii ryzyka.

Właśnie dlatego model stref ryzyka osobisty, współpracujący i korporacyjny ma tak duże znaczenie. Twój model kontroli powinien rosnąć wraz z potencjalnym wpływem. Jeśli traktujesz każdego agenta, tak samo zadania o niskim ryzyku zostają pogrzebane w powolnych zatwierdzeniach, podczas gdy zadania o wysokim ryzyku prześlizgują się przez słabą kontrolę. Twój stos kontroli w Microsoft 365 powinien wyglądać znajomo dla Twojego zespołu. Używasz tożsamości w Entra, granic danych za pośrednictwem Perview i monitorowania za pośrednictwem Defender. Stosujesz warunki dostępu poprzez dostęp warunkowy i zapewniasz wbudowaną audytowalność od samego początku. Musisz być w stanie dokładnie odtworzyć, co się stało, bez konieczności zgadywania po wystąpieniu incydentu. Nadzór ludzki musi być wkomponowany w logikę, a nie improwizowany w czasie kryzysu. Działania o dużym wpływie powinny być zawsze wstrzymywane do momentu uzyskania podpisu.

Rozumowanie powinno być rejestrowane w formie, którą ludzie mogą faktycznie sprawdzić i zrozumieć. Potrzebujesz ścieżek wycofania, zanim pierwsza autonomiczna akcja zostanie uruchomiona. Jeśli agent zaktualizuje dostęp lub zmieni zasady routingu, ktoś musi mieć sposób na prześledzenie tej decyzji i jej jednoznaczne cofnięcie. Jest jeszcze jeden czynnik, który liderzy często pomijają, ponieważ wczesne wersje demonstracyjne wyglądają tak dobrze. Koszt przeróbek. Jeśli agent tworzy pętle czyszczące dla Twojego zespołu, przewidywane oszczędności znikają natychmiast. To jest podatek od przeróbek. To czas poświęcony na korygowanie błędnych wyników, cofanie błędnych działań lub ściganie niezamierzonych skutków ubocznych. Jeśli Twój zespół oszczędza 10 minut na realizacji, ale marnuje 8 minut na sprzątanie bałaganu, tak naprawdę nie zautomatyzowałeś wsparcia. Po prostu przeniosłeś tarcie na inną część procesu.

Zaufanie nie pochodzi z dopracowanej prezentacji zasad ani wielkiego ogłoszenia o uruchomieniu. Pochodzi z dowodów w czasie wykonywania. Ludzie muszą zobaczyć, co zobaczył agent, jakie podjął decyzję i co faktycznie zmieniło się w systemie. W ten sposób buduje się zaufanie do autonomicznego wsparcia. Dowód musi znajdować się w zachowaniu narzędzia, a nie w marce projektu. Gdy ten fundament zarządzania jest solidny, rozmowa może wreszcie odejść od żargonu bezpieczeństwa i przejść do języka zarządczego. Co to tak naprawdę zmienia dla wyniku finansowego? Nowy zwrot z inwestycji ROI w niewidzialne wsparcie. Gdy liderzy zaakceptują model kontroli, pytania finansowe zaczną się zmieniać. W starym modelu wartość wsparcia jest mierzona widoczną pracą, taką jak zamknięte zgłoszenia, obsłużone połączenia i realizacja SLA. Te liczby nadal mają znaczenie, ale opisują jedynie reakcję na problem. Nie mówią, ile przerw nie dotarło do kolejki ani ile czasu pracowników pozostało nienaruszone dzięki wczesnemu rozwiązaniu problemu.

To jest sedno problemu księgowego. Niewidoczne wsparcie tworzy wartość poprzez nieobecność. Wartość widać, gdy nie ma zgłoszenia, eskalacji i analityka poświęcającego 20 minut na rekonstrukcję problemu na podstawie niedokończonych notatek. Jeśli mierzysz tylko widoczny wysiłek zespołu wsparcia, tracisz wynik, na którym tak naprawdę Ci zależało. Chciałeś stabilnej pracy z mniejszą liczbą przerw. Liczba zgłoszeń jest słabym sygnałem, gdy działa samodzielnie. Spadek liczby zgłoszeń może oznaczać spadek popytu, ale może również oznaczać, że środowisko stało się zdrowsze, a warstwa wsparcia stała się mądrzejsza. To dwie zupełnie różne historie. Kadra kierownicza potrzebuje zestawu KPI, który pozwoli odróżnić je od siebie. Powinieneś zacząć od analizy autonomicznego wskaźnika rozwiązywania problemów. Nie chodzi o liczbę rozmów, które odbył bot, ale o liczbę zdarzeń wsparcia, które zostały rozwiązane kompleksowo, bez ingerencji człowieka.

Należy również śledzić skrócenie średniego czasu potrzebnego na rozwiązanie problemu. W środowiskach opartych na sztucznej inteligencji przepływy wymagające dużej liczby diagnoz często odnotowują poprawę w zakresie od 40 do 60%. Następnie można przeanalizować koszt rozwiązania problemu i odzyskaną produktywność użytkowników. Tę ostatnią metrykę łatwo pominąć, ponieważ nie jest ona wyraźnie widoczna w standardowym raporcie pomocy technicznej. Jednak to właśnie tam często kryje się prawdziwa wartość. Osoba, która jest zablokowana na 15 minut, zanim jeszcze otworzy zgłoszenie, już generuje koszty dla firmy. Po pomnożeniu tego przez liczbę przerw i trudności z dostępem w dużej firmie ukryta strata jest znacznie większa niż sugeruje kolejka. Dlatego model kosztów bezczynności jest tak ważny w uzasadnieniu biznesowym. Oblicza się godziny spędzone na pracy ręcznej jeszcze przed rozpoczęciem formalnego wsparcia.

Następnie dodaje się koszt błędów i powtarzanych czynności. Nagle argument za wywłaszczaniem przestaje brzmieć jak teoria. Nie finansujesz tylko futurystycznej warstwy wsparcia. Usuwasz podatek, który od lat ciążył na twojej codziennej pracy. Ekonomia wąskiego przypadku jeszcze bardziej to uwypukla. Badania nad agentowym wsparciem IT szacują, że obsługa przez człowieka kosztuje około 8,75 dolara za zgłoszenie. Natomiast wąska obsługa agentowa może spaść poniżej 50 centów za zgłoszenie po opracowaniu systemu. Nie oznacza to, że każde działanie wsparcia będzie tak tanie, a liderzy powinni ostrożnie podchodzić do szerokich średnich. Jakość i zarządzanie telemetrią zawsze będą wpływać na ostateczny koszt, ale kierunek trendu jest niepodważalny. To moment, w którym IT odchodzi od starej narracji o centrach kosztów. Nie dlatego, że wsparcie znika, ale dlatego, że wsparcie zmienia się w warstwę niezawodności, która chroni przepustowość pracowników w tle.

Firma odbiera to jako płynniejszą pracę, a nie dramatyczne zdarzenie. Otrzymujesz mniej przerw, szybsze przywracanie i mniej pracy marnowanej na routing i wyjaśnienia. Mimo to, błędne pomiary mogą łatwo zafałszować postęp. Jeśli twoja telemetria jest słaba, agent może po prostu szybciej podsumować awarię, zamiast jej faktycznie zapobiec. Jeśli przeróbki nie będą widoczne na pulpicie, zwrot z inwestycji ROI będzie wyglądał znacznie lepiej niż jest w rzeczywistości. Jeśli odzyskany czas po prostu powróci do działań o niskiej wartości, liderzy będą przeceniać korzyści. Uzasadnienie finansowe musi opierać się na twardych dowodach, takich jak zapobiegnięte incydenty i mniejsza liczba ręcznych czynności. Trzeba mierzyć czas rzeczywiście poświęcony na użyteczną pracę. Gdy to się odpowiednio zmierzy, funkcja wsparcia przestaje być postrzegana jako obciążenie, które należy ograniczyć. Zaczyna przypominać zdolność operacyjną, którą firma w końcu odzyskuje.

Jak to wpływa na zespół wsparcia? Pomyśl o tym, jak to faktycznie wpływa na zespół w terenie, ponieważ ta zmiana nie polega tak naprawdę na redukcji etatów, ale na zmianie sposobu, w jaki pracownicy faktycznie spędzają dzień. W starym modelu większość zasobów wsparcia jest pochłaniana przez resetowanie haseł, kierowanie zgłoszeń i niekończące się pętle wyjaśnień. Ludzie ścigają aktualizacje i przesyłają dane między systemami, które nigdy nie zostały zaprojektowane do komunikacji ze sobą. Żadna z tych prac nie zwiększa stabilności środowiska, a jedynie zapobiega przepełnieniu kolejki. Kiedy agenci przejmują tę przewidywalną, rutynową pracę, ludzki wysiłek w końcu wkracza na wyższy poziom. Inżynierowie wsparcia zaczynają poświęcać czas na definiowanie prawidłowego stanu i dostrajanie logiki stojącej za zatwierdzeniami. Koncentrują się na ulepszaniu źródeł wiedzy, testowaniu działania polityk i upewnianiu się, że agent pozostaje w wyznaczonych granicach.

To zupełnie inna praca niż całodniowe wpatrywanie się w tematy wiadomości i próba odgadnięcia, czego tak naprawdę chce użytkownik. Właśnie w tym momencie większość wdrożeń się zatrzymuje. Organizacje starają się utrzymać stare, niedziałające procesy i po prostu powierzyć je agentowi, oczekując lepszych rezultatów. Jednak proces nadal jest reaktywny, przekazywanie zadań jest chaotyczne, a wiedza bazowa słaba. Agent staje się po prostu kolejną warstwą farby na rozpadającej się ścianie. Może szybciej odpowiedzieć na pytanie, ale nie naprawi modelu wsparcia zbudowanego wokół opóźnień. Lepszym rozwiązaniem jest najpierw przeprojektowanie pracy. Trzeba zdecydować, które zadania pozostają ludzkie, ponieważ wymagają osądu lub wrażliwej komunikacji. Następnie należy zdecydować, które zadania przechodzą do autonomicznych przepływów, ponieważ wynik jest przewidywalny, a działania bezpieczne. Ten podział jest niezbędny, ponieważ zespoły wsparcia nie znikną.

To one po prostu stają się osobami projektującymi mechanizmy kontroli i obsługującymi wyjątki. Oznacza to, że sposób, w jaki szkolimy ludzi również musi się zmienić. Zespoły muszą nauczyć się nadzorować system, a nie tylko wykonywać zadania manualne. Muszą rozumieć logikę wycofywania zmian, audyty i testować agenta przed jego uruchomieniem. Muszą również umieć rozpoznawać awarię modelu, ponieważ zautomatyzowany, błędny przepływ pracy nadal jest błędnym przepływem pracy. To tylko przyspiesza proces. Jeśli rekrutujesz z myślą o przyszłości, prawdopodobnie nie potrzebujesz kolejnego specjalisty do selekcji zgłoszeń. Potrzebujesz kogoś, kto potrafi organizować przepływy w całym stosie Microsoft 365 i definiować mechanizmy kontroli, które kontrolują agentów. Potrzebujesz osób, które potrafią ulepszyć środowisko, aby zapotrzebowanie na wsparcie faktycznie spadło, a nie tylko rosło. Jak więc to zrobić, aby nie przerodziło się w ogromny, wieloletni projekt transformacji?

Najlepszym rozwiązaniem jest wybór jednego przepływu pracy, który powoduje ciągłe tarcia w środowisku Microsoft 365. Naprawa dostępu jest zazwyczaj dobrym rozwiązaniem, ale można również rozważyć spotkania dotyczące wsparcia lub przekazywania zgodności urządzeń. Nie ma znaczenia, którą opcję wybierzesz, o ile schemat powtarza się często i dokładnie wiesz, jak powinien wyglądać pomyślny wynik. Po ustaleniu celu musisz zdefiniować podstawy z prawdziwą dyscypliną. Musisz wiedzieć, jak wygląda sytuacja prawidłowa, a które konkretne zdarzenia wskazują, że sprawy zbaczają z kursu. Zdecyduj, które działania można bezpiecznie zautomatyzować i gdzie dokładnie należy rozpocząć eskalację ludzką. Zanim cokolwiek wdrożysz, upewnij się, że masz punkt odniesienia dla liczby zgłoszeń, ręcznych zmian i tego, jak długo użytkownicy czekają na rozwiązanie. Musisz również wdrożyć zarządzanie od pierwszego dnia.

Nadaj agentowi konkretną tożsamość, przypisz jej ludzkiego właściciela i ustal jasne reguły zatwierdzania. Każda czynność podejmowana przez agenta musi być rejestrowana. Powinieneś również mieć plan na wypadek, gdyby agent został wycofany z pracy lub ponownie przypisany, aby nie stał się po prostu zautomatyzowanym widmem. Gdy ten pierwszy przepływ zacznie działać, cały model operacyjny zacznie się zmieniać. Wsparcie przestaje działać jak recepcja, która reaguje tylko na problemy. Zamiast tego zaczyna zachowywać się jak silnik niezawodności wbudowany bezpośrednio w system. Wsparcie przechodzi od widocznej reakcji do wbudowanego zapobiegania. Zgłoszenie nigdy nie było usługą. Było dowodem na to, że usługa pojawiła się za późno. Wybierz jeden przepływ wsparcia w tym kwartale i przeprojektuj go tak, aby przewidywał wyprzedzanie, a nie reagowanie. Jeśli chcesz dowiedzieć się więcej o M365 Copilot Azure, bezpieczeństwie i modelach operacyjnych AI, zasubskrybuj M365FM i zostaw recenzję.

Dołącz do mnie, Mirko Pitera, na LinkedIn, aby omówić kolejny temat, który chcesz omówić.