WEBVTT 00:00:00.000 --> 00:00:02.040 Система тікетів виглядає доречно лише на папері. 00:00:02.140 --> 00:00:04.120 Ви отримуєте цифри, черги, дашборди. 00:00:04.280 --> 00:00:07.840 Але насправді ця модель вимірює біль лише тоді, коли система вже дала збій. 00:00:08.020 --> 00:00:10.740 Найдорожча частина проблеми зазвичай виникає значно раніше. 00:00:10.940 --> 00:00:14.160 Все починається, коли працівник втрачає 10 хвилин, потім 20, а зрештою просто здається. 00:00:14.360 --> 00:00:15.380 Вони пробують знову. 00:00:15.520 --> 00:00:16.640 Вони запитують колегу. 00:00:16.760 --> 00:00:19.880 Вони пропускають зустріч або діляться не тим файлом, бо правильний шлях перестав працювати. 00:00:19.880 --> 00:00:22.640 І це та частина, яку більшість команд підтримки досі не бачать. 00:00:22.760 --> 00:00:26.120 Найкраща сучасна модель внутрішньої підтримки – це не швидше сортування тікетів. 00:00:26.240 --> 00:00:28.340 Це повне усунення потреби в сортуванні. 00:00:28.500 --> 00:00:32.880 Уявіть автономного агента в Microsoft 365, який стежить за контекстом, 00:00:33.000 --> 00:00:37.160 вчасно помічає перешкоди і діє до того, як людина взагалі подумає відкрити портал. 00:00:37.300 --> 00:00:40.780 У цьому епізоді я хочу показати вам, чому модель служби підтримки ламається, 00:00:40.920 --> 00:00:44.040 що приходить її на зміну і як нею керувати, не створюючи хаосу. 00:00:44.040 --> 00:00:48.000 Якщо цей сув важливий для вашої роботи, підпишіться на M365FM, 00:00:48.080 --> 00:00:51.780 бо якщо копнути глибше, справжня проблема не в черзі, а в моделі, що стоїть за нею. 00:00:51.900 --> 00:00:54.980 Смерть тікета. Старий потік підтримки досі повсюди. 00:00:55.160 --> 00:00:59.300 Щось ламається. Користувач помічає це. Користувач намагається це пояснити. 00:00:59.460 --> 00:01:03.640 Потім IT перекладає це пояснення у категорію, пріоритет і, можливо, групу призначення. 00:01:03.780 --> 00:01:08.100 Проблема потрапляє в чергу. Хтось її сортує. Хтось інший запитує деталі. 00:01:08.100 --> 00:01:11.940 Долучається інша команда. Час йде, а реальна робота стоїть на місці. 00:01:12.100 --> 00:01:15.280 Цей процес здається нормальним, бо він знайомий, але знайомий і ефективне. 00:01:15.400 --> 00:01:16.360 Це не одне й те саме. 00:01:16.480 --> 00:01:20.360 Тікет – це не підтримка. Тікет – це доказ того, що підтримка запізнилася. 00:01:20.520 --> 00:01:24.400 До моменту створення тікета працівник уже зіткнувся з труднощами і втратив контекст. 00:01:24.600 --> 00:01:27.520 Вони вже відволіклися від роботи, яку намагалися виконати. 00:01:27.700 --> 00:01:30.720 Черга – це не сервіс. Черга – це запис про несправність. 00:01:30.720 --> 00:01:34.700 У великих середовищах Microsoft 365 ручне сортування стає справжнім вузьким місцем. 00:01:34.840 --> 00:01:37.120 Це відбувається не тому, що команди підтримки ліниві. 00:01:37.240 --> 00:01:41.140 Це відбувається тому, що від людей вимагають робити те, що вже не відповідає масштабам середовища. 00:01:41.260 --> 00:01:44.500 У вас більше користувачів, більше пристроїв, більше застосунків, більше політик. 00:01:44.580 --> 00:01:49.620 У вас більше виняткових випадків, що перетинають команди SharePoint Exchange, Intune та Entra одночасно. 00:01:49.760 --> 00:01:52.720 Обсяг не просто зростає. Зростає кількість комбінацій. 00:01:52.880 --> 00:01:54.240 Ось де ламається стара модель. 00:01:54.240 --> 00:01:56.640 Більшість команд реагують на це додаванням структури. 00:01:56.760 --> 00:01:59.940 Вони будують ще один портал, ще одного бота чи ще одне правило маршрутизації. 00:02:00.100 --> 00:02:03.860 Але насправді це лише додає ще один рівень між працівником і розв'язанням проблеми. 00:02:04.020 --> 00:02:09.340 Система досі чекає, поки користувач помітить проблему, опише її та попросить допомоги у правильний спосіб. 00:02:09.540 --> 00:02:17.380 Робота починається не на порталі підтримки, вона починається в Teams, в Outlook, у документи, який потрібен прямо зараз або на зустрічі, що розпочнеться за 30 секунд. 00:02:17.380 --> 00:02:21.900 Саме там насправді виникає потреба в підтримці, а модель тікетів повністю відірвана від того моменту. 00:02:22.040 --> 00:02:24.820 Приховані витрати значно більші, ніж показують ваші звіти про черги. 00:02:24.980 --> 00:02:26.780 Люди постійно перемикаються між контекстами. 00:02:26.940 --> 00:02:29.220 Дублювані інциденти накопичуються під різними мітками. 00:02:29.440 --> 00:02:30.520 Бази знань старіють. 00:02:30.680 --> 00:02:35.360 Аналітики витрачають весь день на сортування, маршрутизацію та уточнення замість того, щоб реально вирішувати проблеми. 00:02:35.480 --> 00:02:41.220 Час вирішення розтягується, бо кожна передача завдання додає затримку, а кожна затримка позбавляє справу початкового контексту. 00:02:41.220 --> 00:02:45.000 Дослідження агентного щі та IT-операції вказують на ту саму структурну проблему. 00:02:45.160 --> 00:02:48.940 Принаймні 80% зусиль досі заблоковані в реактивній роботі за моделю ITIL. 00:02:49.100 --> 00:02:52.220 Це число важливе, бо воно точно показує, куди спрямовуються ресурси. 00:02:52.380 --> 00:02:55.300 Вони йдуть не на стійкість чи запобігання, вони йдуть на реагування. 00:02:55.300 --> 00:02:59.200 Як тільки ви це побачите, тікет почне виглядати не як модель роботи, а як симптом. 00:02:59.360 --> 00:03:02.620 Це симптом системи, яка реагує лише тоді, коли збитки вже очевидні. 00:03:02.620 --> 00:03:07.800 Тож наступне питання не в тому, як швидше обробляти тікети, а в тому, що система має робити до того, як тікет взагалі знадобиться. 00:03:07.980 --> 00:03:09.500 Модель невидимого працівника. 00:03:09.740 --> 00:03:11.540 Отже, що насправді замінює тікет? 00:03:11.700 --> 00:03:17.080 Це не просто черговий чат-бот поверх того самого безладу, і це точно не гарніші двері до тієї ж самої старої черги. 00:03:17.080 --> 00:03:23.660 Зміна набагато глибша, бо невидимий працівник – це оперативний співробітник, який живе всередині вашого середовища Microsoft 365. 00:03:24.180 --> 00:03:28.080 Цей агент має власну ідентичність, визначений обсяг роботи, пам'ять про те, що він робив учора, 00:03:32.620 --> 00:03:37.240 Чат-бот чекає, поки ви введете запит, а невидимий працівник стежить за зміною умов. 00:03:37.400 --> 00:03:39.620 Він починає з контексту, а не з розмови. 00:03:39.740 --> 00:03:46.460 Оскільки він бачить стани входу, стан пристроїв, статус ліцензії та те, як надається доступ до файлів, йому не потрібно чекати, поки виникне перешкода. 00:03:46.460 --> 00:03:51.580 Замість того, щоб питати, чим він може допомогти після поломки, він постійно ставить у фоновому режимі інше питання, 00:03:51.760 --> 00:03:55.900 що відхиляється від стану, необхідного цьому працівнику для виконання своєї роботи прямо зараз. 00:03:56.060 --> 00:03:57.400 Саме тут все змінюється. 00:03:57.400 --> 00:03:59.980 Модель вбудована безпосередньо в саму роботу. 00:04:00.160 --> 00:04:05.760 Коли хтось приєднується до зустрічі і аудіо не працює, або гість не може відкрити файл, який йому щойно надіслали, 00:04:05.920 --> 00:04:08.360 старий світ створює звіт і передає задачу далі. 00:04:08.360 --> 00:04:15.440 У новій моделі агент миттєво розпізнає шаблон, перевіряє, чи відповідає умова відомій проблемі і вживає наступних безпечних дій для її виправлення. 00:04:15.440 --> 00:04:22.100 Можливо, він скидає шлях або ініціює перевірку політик, або перенаправляє запит і вимагає багатофакторну автентифікацію перед документуванням виправлення. 00:04:22.280 --> 00:04:22.960 Суть проста. 00:04:23.120 --> 00:04:27.660 Перша відповідь більше не потребує людини, яка мала б читати розплив частий опис і вгадувати, що сталося. 00:04:27.660 --> 00:04:32.820 Це непомітно. Коли все працює добре, бо немає кімнати очікування чи форми, будь ласка, виберіть категорію, яку треба заповнювати. 00:04:32.940 --> 00:04:35.280 Підтримка проявляється як відновлений робочий процес. 00:04:35.280 --> 00:04:40.180 Співробітник просто повертається до роботи і в багатьох випадках він навіть не бачить механізмів, що працюють за лаштунками. 00:04:40.340 --> 00:04:43.300 Ви вже бачите, як це змінює логіку формування вашого штату. 00:04:43.300 --> 00:04:49.080 Стара модель передбачає наймання людей для обробки обсягів, сортування запитів та виправлення розірваних контекстів між різними командами. 00:04:49.220 --> 00:04:56.580 Нова модель потребує менше людей для сортування та більше тих, хто створює захисні механізми, визначає бажані стани та контролює поведінку агентів з часом. 00:04:56.580 --> 00:05:00.720 Люди залишаються в системі, але сама форма їхньої щоденної роботи змінюється. 00:05:00.920 --> 00:05:04.400 Дослідження агентного щі в підтримці продовжують вказувати на цей напрямок. 00:05:04.400 --> 00:05:11.600 Рутинна підтримка може перейти до обробки на основі винятків, що забезпечує значне підвищення ефективності, коли середовище та політики чітко обмежені. 00:05:11.740 --> 00:05:14.600 Ця остання частина є життєво важливою, тому що це не магія. 00:05:14.760 --> 00:05:20.200 Якщо ваші дані слабкі або процеси заплутані, агент не стане розумним лише тому, що ви вирішили назвати його автономним. 00:05:20.200 --> 00:05:26.580 У мене все склалося в єдину картину, коли я перестав думати про агента як про функцію ПЕЗе і почав розглядати його як нелюдського працівника з перепусткою. 00:05:26.700 --> 00:05:31.380 Справжньому працівнику потрібні ідентифікація, посадова інструкція, права доступу та керівник, якому він звітує. 00:05:31.520 --> 00:05:37.500 Агенту потрібні рівно ті самі речі, оскільки цінність полягає в надійних діях у середині системи, а не в розумних фразах у вікні чату. 00:05:37.680 --> 00:05:40.360 Цей невидимий працівник – не просто фокус інтерфейсу. 00:05:40.360 --> 00:05:49.160 Це новий рівень підтримки, який стежить за проблемами в екосистемі Microsoft 365, діє в межах політик і спрямовує увагу людини на винятки, що дійсно потребують судження. 00:05:49.300 --> 00:05:52.520 Коли ця модель стає зрозумілою, наступне питання стає дуже практичним. 00:05:52.660 --> 00:05:54.440 Як насправді працює превентивність? 00:05:54.740 --> 00:05:56.060 Архітектура превентивності. 00:05:56.200 --> 00:05:59.080 Отже, як насправді працює превентивність у Microsoft 365? 00:05:59.660 --> 00:06:03.000 Відбувається перехід від запиту та відповіді до аналізу подій та оркестрації. 00:06:03.160 --> 00:06:06.300 Це звучить технічно, але модель проста, як тільки ви її розберете. 00:06:06.300 --> 00:06:14.960 Спочатку щось змінюється в середовищі, потім система інтерпретує, чи означається зміна ризик або відхилення, і зрештою вживає схвалених дій, використовуючи наявні у вашому стеку інструменти. 00:06:15.060 --> 00:06:16.360 Почніть із рівня подій. 00:06:16.520 --> 00:06:23.960 Microsoft 365 вже генерує сигнали всюди, Entra бачить поведінку під час входу, а Intune відстежує стан і відповідність пристрою. 00:06:24.120 --> 00:06:29.660 DaFenda стежить за підозвілою активністю, а Teams точно показує, коли зустріч зривається або погіршується якість зв'язку. 00:06:29.660 --> 00:06:36.120 SharePoint та Exchange виявляють схеми доступу та активність із вмістом, а сигнали про стан служб підказують, коли проблема в самій платформі. 00:06:36.260 --> 00:06:40.080 Коли ви додаєте до цього дії користувачів, ви отримуєте постійний потік контексту. 00:06:40.240 --> 00:06:44.520 Більшість організацій збирають ці сигнали, але дуже мало хто використовує їх як систему підтримки. 00:06:44.680 --> 00:06:49.080 Сері події самі по собі не допомагають, бо їм потрібен рівень логічного аналізу, щоб розібратися в цьому шумі. 00:06:49.220 --> 00:06:53.940 Саме тут невидимий працівник перестає бути імітацією автоматизації і починає діяти як справжній оператор. 00:06:53.940 --> 00:06:58.980 Агент аналізує сигнал, порівнює поточний стан із бажаним і вирішує, які дії безпечно вжити. 00:06:59.160 --> 00:07:05.060 Проблема зі звуком на зустрічі – це не те саме, що ризикований вхід, а не працююче посилання для спільного доступу відрізняється від невідповідності ліцензій. 00:07:05.200 --> 00:07:10.120 Агент має спочатку класифікувати проблему, бо в життя заходів без класифікації лише пришвидшує припускання помилок. 00:07:10.220 --> 00:07:11.780 Потім настає оркестрація. 00:07:11.960 --> 00:07:15.580 Щойно агент розуміє проблему, він може використати потрібний механізм для реагування. 00:07:15.580 --> 00:07:21.080 Це може бути Pava Otamate для робочих процесів, Co-Pilot Studio для логіки або Microsoft Graph для системних дій та контексту. 00:07:21.240 --> 00:07:24.360 Інструменти важливі, але головне, як вони взаємодіють між собою. 00:07:24.520 --> 00:07:29.240 Ви будуєте не один розумний запит, а цілий ланцюжок, здатний виявляти, вирішувати, діяти та перевіряти. 00:07:29.440 --> 00:07:31.740 Цю останню частину постійно випускають з уваги. 00:07:31.920 --> 00:07:34.820 Система самокоригування не зупиняється після виконання дії. 00:07:34.820 --> 00:07:41.600 Вона запускає цикл, виявляє проблему, перевіряє умови, застосовує виправлення та підтверджує результат, перш ніж записати, що сталося. 00:07:41.760 --> 00:07:49.280 Дослідження логіки самокоригування чітко показують, що ці системи працюють через зворотний зв'язок та моделі виправлень, а не через одну окрему відповідь мовної моделі. 00:07:49.420 --> 00:07:56.000 Якщо перша дія виявилася невдалою, системі потрібен спосіб оцінити причину, щоб переглянути наступний крок, залишаючись у визначених межах. 00:07:56.140 --> 00:07:59.180 Це можна чітко уявити на прикладах із Microsoft 365. 00:07:59.180 --> 00:08:05.840 Коли користувача блокують через невідповідність ліцензії та політики, агент виявляє це і перевіряє цільовий профіль ролі. 00:08:05.980 --> 00:08:11.820 Він застосовує дозволене виправлення, підтверджує наявність доступу у користувача та реєструє зміни безсторонньої допомоги. 00:08:11.960 --> 00:08:17.720 Якщо вент раз'являється ризикований вхід, агент бачить подію ризику та негайно перевіряє ваші правила умовного доступу. 00:08:17.860 --> 00:08:23.860 Він запитує додаткову перевірку або блокує доступ згідно з вашою політикою, а потім фіксує результат для подальшого огляду людиною. 00:08:23.860 --> 00:08:30.540 Коли застаріле посилання для спільного доступу постійно видає помилку, в SharePoint агент порівнює поточний шлях до дозволів із очікуваними правилами доступу. 00:08:30.680 --> 00:08:40.340 Він замінює пошкоджений корінь на правильний і надсилає виправлене посилання в контексті, що закриває питання ще до того, як аналітик техпідтримки прочитає тікет із заголовком «Термінова проблема з доступом». 00:08:40.340 --> 00:08:42.540 Підтримка на рад – ще один чудовий приклад. 00:08:42.540 --> 00:08:48.820 Якщо пристрій у кімнаті виходить із ладу або шлях підключення переривається за секунди до початку дзвінка, агент може виявити цю проблему та перевірити збій. 00:08:48.960 --> 00:08:54.320 Він виконує кроки для відновлення з низьким рівнем ризику та сповіщає організатора в Teams з оновленням статусу саме там, де відбувається робота. 00:08:54.480 --> 00:08:57.100 Цей рівень комунікації є величезною частиною дизайну. 00:08:57.240 --> 00:08:59.700 Підтримка має бути там, де виникає перерва в роботі. 00:08:59.700 --> 00:09:05.480 Якщо ваша робота відбувається в Teams, Outlook та робочому просторі М365, то підтримка має відповідати вам також там. 00:09:05.640 --> 00:09:09.880 Вам не варто перенаправляти користувача кудись інде, якщо можна вирішити проблему в контексті події. 00:09:10.060 --> 00:09:13.840 Це не означає повну автоматизацію всіх завдань, адже це було б необачно. 00:09:14.040 --> 00:09:18.960 Дії з низьким ризиком можуть виконуватися автоматично, але для серйозних змін усе ще потрібне схвалення людини. 00:09:19.100 --> 00:09:23.700 Цей шлях схвалення має бути частиною архітектури від самого початку, а не додаватися згодом. 00:09:23.700 --> 00:09:27.720 Агент повинен знати, коли діяти, коли запитати і чітко знати, коли зупинитися. 00:09:27.860 --> 00:09:32.340 І як тільки ви впровадите це у робочий процес, розмова перестане стосуватися лише функцій автоматизації. 00:09:32.580 --> 00:09:36.260 Вона стане розмовою про контроль, управління, довіру та ідентичність агента. 00:09:36.440 --> 00:09:40.160 Коли підтримка починає діяти самостійно, негайно виникає складне питання. 00:09:40.320 --> 00:09:42.120 Хто насправді виконує цю роботу? 00:09:42.300 --> 00:09:44.900 Якщо відповідь на нього розмита, уся модель руйнується. 00:09:44.900 --> 00:09:49.460 Агент не може існувати у вашому середовищі як незрозумілий помічник із широким доступом і без чіткого власника. 00:09:49.640 --> 00:09:51.640 Він потребує реальної ідентичності Вентра. 00:09:51.800 --> 00:09:56.700 Він потребує визначеного власника, окресленої сфери дії та життєвого циклу, що має чітку причину для початку та завершення. 00:09:56.880 --> 00:10:00.720 Якщо цей агент може читати дані, запускати робочі процеси або надсилати повідомлення користувачам, 00:10:00.800 --> 00:10:03.060 ви повинні керувати ним як активним учасником орендаря Тенан. 00:10:03.180 --> 00:10:06.440 Ви не можете ставитися до цього як до функції, яку хтось увімкнув і забув. 00:10:06.440 --> 00:10:09.420 Ось чому ідентичність агента є такою критичною для системи. 00:10:09.520 --> 00:10:14.540 Ви повинні точно знати, що це за агент, до яких систем він має доступ і хто отримає сповіщення, якщо все почне виходити з ладу. 00:10:14.640 --> 00:10:17.040 Принцип найменших привілеїв має бути тут базовим стандартом. 00:10:17.200 --> 00:10:21.320 Не можна погоджуватися на надмірну зручність або тішити себе думкою, що ви обмежите дозволи пізніше. 00:10:21.480 --> 00:10:24.620 Оскільки зона впливу агента підтримки повністю залежить від його дозволів, 00:10:24.700 --> 00:10:28.120 проєктовання цих дозволів є основною частиною побудови системи підтримки. 00:10:28.120 --> 00:10:34.860 Agent 365 служить необхідним рівнем контролю в цій системі, оскільки забезпечує повновидимість усього середовища агентів. 00:10:35.000 --> 00:10:39.940 Він надає реєстр, робочі процеси затвердження та шаблони політик, що гарантують безпечну роботу. 00:10:40.140 --> 00:10:44.720 Хоча ці елементи можуть здаватися адміністративною рутиною, вони вирішують величезну структурну проблему. 00:10:44.920 --> 00:10:51.060 Більшість організацій мають труднощі не через брак функцій ЩІ, а через неможливість бачити або контролювати те, що вже працює в їхньому середовищі. 00:10:51.060 --> 00:10:53.320 Дослідження щодо цього питання прямолінійні. 00:10:53.460 --> 00:10:58.740 Лише невелика меншість великих підприємств можуть повністю інвентаризувати всіх агентів, що зараз працюють у їхній системі. 00:10:58.820 --> 00:11:03.720 Перш ніж керівники почнуть говорити про масштабування автономної підтримки, вони мають відповісти на значно простіше питання. 00:11:03.880 --> 00:11:07.320 Чи взагалі ми знаємо, які агенти існують і що вони роблять прямо зараз? 00:11:07.460 --> 00:11:09.680 Нагляд також має відповідати рівню ризику. 00:11:09.680 --> 00:11:16.300 Персональний агент продуктивності, що працює у вузькій сфері – це одне, а агент для спільної роботи, що взаємодіє зі спільним контентом – зовсім інше. 00:11:16.440 --> 00:11:21.240 Крім того, є корпоративні агенти, які діють у чутливих робочих процесах, що належать до іншої категорії ризику. 00:11:21.420 --> 00:11:25.300 Ось чому модель зон ризику – персональна, спільна та корпоративна – має таке велике значення. 00:11:25.300 --> 00:11:28.620 Ваша модель контролю повинна посилюватися відповідно до можливого впливу. 00:11:28.620 --> 00:11:35.140 Якщо ви ставитеся до всіх агентів однаково, низькоризикова робота потоне в повільних погодженнях, а високоризикова просле з небезналежного нагляду. 00:11:35.320 --> 00:11:39.780 Щонайменше, ваш стек контролю в Microsoft 365 має виглядати знайомим для вашої команди. 00:11:39.900 --> 00:11:44.240 Ви використовуєте ідентифікацію вентра, межі даних через перв'ю та моніторинг через дафенда. 00:11:44.240 --> 00:11:49.560 Ви застосовуєте умови доступу через умовний доступ і забезпечуєте можливість аудиту з самого початку. 00:11:49.560 --> 00:11:54.620 Ви повинні мати можливість відтворити все, що сталося, не вдаючись до здогадок після виникнення інциденту. 00:11:54.760 --> 00:11:58.720 Людський нагляд має бути закладений у логіку, а не імпровізуватися під час кризи. 00:11:58.880 --> 00:12:02.200 Дії з високим рівнем впливу завжди повинні вимагати підтвердження людиною. 00:12:02.360 --> 00:12:06.080 Обґрунтування має реєструватися у формі, яку люди можуть реально перевірити та зрозуміти. 00:12:06.260 --> 00:12:10.060 Шляхи відкату повинні існувати ще до того, як запрацює перша автономна дія. 00:12:10.060 --> 00:12:16.020 Якщо агент оновлює доступ або змінює політику маршрутизації, хтось повинен мати змогу відстежити це рішення та чітко скасувати його. 00:12:16.160 --> 00:12:20.220 Існує ще один фактор, який керівники часто пропускають, тому що ранні демонстрації виглядають дуже привабливо. 00:12:20.360 --> 00:12:21.380 Вартість переробки 00:12:21.380 --> 00:12:25.880 Якщо агент створює цикли виправлень для вашої команди, прогнозована економія миттєво зникає. 00:12:26.020 --> 00:12:27.380 Це податок на переробку. 00:12:27.520 --> 00:12:32.880 Це час, витрачений на виправлення невдалих результатів, скасування неправильних дій або усунення небажаних побічних ефектів. 00:12:32.880 --> 00:12:38.680 Якщо ваша команда економить 10 хвилин на виконанні, але витрачає 8 хвилин на прибирання безладу, ви насправді не автоматизували підтримку. 00:12:38.820 --> 00:12:41.460 Ви просто перемістили труднощі на іншу частину процесу. 00:12:41.580 --> 00:12:44.660 Довіра не виникає завдяки гарним презентаціям із політиками чи гучним анонсам. 00:12:44.800 --> 00:12:46.640 Вона виникає завдяки доказам під час роботи. 00:12:46.760 --> 00:12:50.180 Людям важливо бачити, що саме бачив агент, які рішення він ухвалив і що реально змінилося в системі. 00:12:50.300 --> 00:12:52.520 Саме так будується довіра до автономної підтримки. 00:12:52.520 --> 00:12:56.340 Докази мають базуватися на поведінці інструменту, а не на брендингу проєкту. 00:12:56.520 --> 00:13:02.060 Коли фундамент управління стає міцним, розмова нарешті переходить від безпекового жаргону до мови керівників. 00:13:02.220 --> 00:13:04.600 Що це насправді змінює для фінансових результатів? 00:13:04.740 --> 00:13:07.120 Новий показник ROI для невидимої підтримки. 00:13:07.240 --> 00:13:10.680 Коли лідери приймають модель контролю, фінансові питання починають змінюватися. 00:13:10.840 --> 00:13:16.120 У старій моделі цінність підтримки вимірюється видимою роботою, закритими тікетами, обробленими дзвінками та дотриманнями селей. 00:13:16.120 --> 00:13:19.680 Ці цифри все ще важливі, але вони лише описують реакцію на проблему. 00:13:19.860 --> 00:13:25.480 Вони не показують, скільки збоїв не дійшло до черги і скільки часу співробітників було збережено завдяки ранньому усуненню проблеми. 00:13:25.600 --> 00:13:27.120 Це ключова проблема обліку. 00:13:27.320 --> 00:13:30.240 Невидима підтримка створює цінність завдяки своїй відсутності. 00:13:30.380 --> 00:13:37.240 Ви бачите цінність тоді, коли немає тікета, ескалації та аналітика, який витрачає 20 хвилин на відновлення проблеми з неповних нотаток. 00:13:37.240 --> 00:13:42.060 Якщо вимірювати лише видимі зусилля команди підтримки, ви втрачаєте результат, якого насправді прагнули. 00:13:42.180 --> 00:13:44.760 Ви прагнули стабільної роботи з меншою кількістю переривань. 00:13:44.880 --> 00:13:47.880 Обсяг тікетів – це слабкий сигнал, якщо розглядати його окремо. 00:13:48.020 --> 00:13:53.100 Зменшення кількості тікетів може означати падіння попиту, але також те, що середовище стало здоровішим, а рівень підтримки – розумнішим. 00:13:53.220 --> 00:13:54.700 Це дві зовсім різні історії. 00:13:54.880 --> 00:13:58.420 Керівникам потрібен набір KPI, який дозволяє відрізнити одне від іншого. 00:13:58.420 --> 00:14:01.580 Вам варто почати з оцінки рівня автономного вирішення запитів. 00:14:01.700 --> 00:14:07.240 Це не про кількість розмов бота, а про те, скільки запитів було вирішено від початку до кінця без втручання людини. 00:14:07.400 --> 00:14:10.520 Вам також потрібно відстежувати скорочення середнього часу вирішення. 00:14:10.680 --> 00:14:15.540 У середовищах на базі ЩІ-процеси, де важлива діагностика, часто покращується на від 40 до 60%. 00:14:15.540 --> 00:14:19.620 Потім можна оцінити вартість одного вирішення та відновлену продуктивність користувачів. 00:14:19.760 --> 00:14:24.260 Останній показник легко пропустити, оскільки він не вписується у стандартний звіт сервісної служби. 00:14:24.260 --> 00:14:26.780 Проте саме там часто криється справжня цінність. 00:14:26.900 --> 00:14:31.800 Людина, яка заблокована на 15 хвилин ще до відкриття тікета, вже створила збитки для компанії. 00:14:31.980 --> 00:14:35.900 Якщо помножити це на переривання зустрічей та проблеми з доступом у великій організації, 00:14:36.020 --> 00:14:38.480 приховані втрати значно перевищують показники черги. 00:14:38.620 --> 00:14:41.780 Ось чому модель вартості бездіяльності така важлива для бізнес-кейсу. 00:14:41.900 --> 00:14:45.880 Ви розраховуєте години, витрачені наручну працю ще до того, як розпочинається формальна підтримка. 00:14:46.020 --> 00:14:48.300 Потім додайте вартість помилок і повторної роботи. 00:14:48.300 --> 00:14:51.620 Раптом аргумент на користь превентивних заходів перестає звучати як теорія. 00:14:51.760 --> 00:14:54.160 Ви фінансуєте не просто футуристичний рівень підтримки. 00:14:54.340 --> 00:14:57.700 Ви усуваєте податок, який роками був частиною вашої щоденної роботи. 00:14:57.840 --> 00:15:00.300 Економіка вузьких кейсів робить це ще очевиднішим. 00:15:00.440 --> 00:15:05.640 Дослідження агентної ІТ-підтримки оцінюють обробку людиною приблизно у вісьмох доларів США і 75 центів за запит. 00:15:05.760 --> 00:15:10.500 Натомість вузька агентна обробка може коштувати менше, ніж 50 центів після розробки системи. 00:15:10.500 --> 00:15:15.960 Це не означає, що кожна дія підтримки буде такою дешевою і керівникам варто бути обережними із загальними середніми показниками. 00:15:16.120 --> 00:15:21.240 Якість телеметрії та управління завжди впливатимуть на кінцеву вартість, але напрямок тренду є беззаперечним. 00:15:21.420 --> 00:15:24.660 Це момент, коли ІТ виходить із застарілого образу центру витрат. 00:15:24.860 --> 00:15:31.360 Це відбувається не тому, що підтримка зникає, а тому, що вона стає рівнем надійності, який захищає продуктивність працівників у фоновому режимі. 00:15:31.500 --> 00:15:35.440 Бізнес відчуває це як більш плавний робочий процес, а не як драматичну подію в підтримці. 00:15:35.440 --> 00:15:40.060 Ви отримуєте менше перерв, швидше відновлення та менше витраченого часу на маршрутизацію та уточнення. 00:15:40.240 --> 00:15:43.360 Все ж таки, погані вимірювання можуть легко створити ілюзію прогресу. 00:15:43.500 --> 00:15:48.100 Якщо ваша телеметрія слабка, агент може просто швидше підсумувати збій замість того, щоб реально його запобігти. 00:15:48.240 --> 00:15:52.200 Якщо переробка залишається поза межами звітності, ROI виглядатиме набагато кращим, ніж є насправді. 00:15:52.320 --> 00:15:56.820 Якщо повернений час знову витрачається на низьковартісні завдання, керівники перебільшать досягнення. 00:15:56.820 --> 00:16:01.760 Фінансове обґрунтування має базуватися на твердих доказах, як-от запобігання інцидентам та зменшення ручного втручання. 00:16:01.900 --> 00:16:04.800 Ви повинні вимірювати час, реально повернути й до корисної роботи. 00:16:04.920 --> 00:16:09.200 Коли ви вимірюєте це належним чином, функція підтримки перестає виглядати як накладні витрати, які треба скорочувати. 00:16:09.400 --> 00:16:12.960 Вона починає виглядати як операційна потужність, яку бізнес нарешті повертає собі. 00:16:13.120 --> 00:16:15.100 Що це означає для команди підтримки? 00:16:15.100 --> 00:16:22.200 Подумайте, що це насправді дає команді на місцях, адже ця зміна не про скорочення штату, а про зміну того, чим люди займаються протягом дня. 00:16:22.380 --> 00:16:28.280 У старій системі більшість потужностей підтримки витрачається на скидання паролів, маршрути зацію тікетів і нескінченні уточнення. 00:16:28.480 --> 00:16:33.200 Ваші люди ганяються за оновленнями та переносять дані між системами, які ніколи не були розраховані на взаємодію. 00:16:33.340 --> 00:16:37.420 Жодна з цих робіт не робить середовище стабільнішим, вона лише запобігає переповненню черги. 00:16:37.420 --> 00:16:42.360 Коли агенти перебирають цю передбачувану рутинну роботу, людські зусилля нарешті переходять на новий рівень. 00:16:42.520 --> 00:16:47.880 Інженери підтримки починають витрачати свій час на визначення стану стабільної роботи та налаштування логіки схвалень. 00:16:48.060 --> 00:16:53.920 Вони зосереджуються на вдосконаленні баз знань, тестуванні політик і забезпеченні того, щоб агент діяв у встановлених межах. 00:16:54.040 --> 00:16:59.540 Це зовсім інша робота, ніж цілий день вдивлятися в теми листів, намагаючись вгадати, чого насправді хоче користувач. 00:16:59.540 --> 00:17:02.040 Саме тут більшість впроваджень і зупиняється. 00:17:02.220 --> 00:17:07.860 Організації намагаються зберегти свої старі зламані процеси, просто додаючи агента зверху в очікуванні кращого результату. 00:17:07.980 --> 00:17:12.560 Але процес залишається реактивним, передача завдань не чіткою, а базова база знань – слабкою. 00:17:12.700 --> 00:17:15.680 Агент стає просто ще одним шаром фарби на стіні, що руйнується. 00:17:15.860 --> 00:17:19.720 Він може швидше відповісти на запитання, але не виправить модель підтримки, побудовано на затримках. 00:17:19.860 --> 00:17:22.200 Кращий шлях – спочатку перепроєктувати саму роботу. 00:17:22.200 --> 00:17:26.740 Ви повинні визначити, які завдання залишаться за людьми, бо вони потребують суджень або чутливого спілкування. 00:17:26.900 --> 00:17:31.360 Потім ви вирішуєте, яка робота переходить в автономні потоки, оскільки результат передбачуваний, а дії безпечні. 00:17:31.480 --> 00:17:34.340 Цей поділ життєво важливий, адже команди підтримки нікуди не зникають. 00:17:34.500 --> 00:17:37.520 Вони просто стають людьми, які розробляють засоби контролю та обробляють винятки. 00:17:37.660 --> 00:17:40.420 Це означає, що спосіб навчання персоналу також має змінитися. 00:17:40.560 --> 00:17:44.500 Команди мають навчитися наглядати за системою, а не просто виконувати ручне завдання. 00:17:44.500 --> 00:17:49.300 Їм потрібно розуміти логіку відкату, аудиторські перевірки та як тестувати агента перед запуском. 00:17:49.440 --> 00:17:54.680 Вони також повинні вміти помічати, коли модель дає збій, адже автоматизований поганий робочий процес – це все ще поганий процес. 00:17:54.840 --> 00:17:56.280 Він просто ламає все швидше. 00:17:56.440 --> 00:18:00.560 Якщо ви наймаєте людей для цього майбутнього, вам, ймовірно, не потрібен черговий універсальний спеціаліст для сортування тікетів. 00:18:00.680 --> 00:18:06.460 Вам потрібен той, хто зможе оркеструвати потоки в стеку Microsoft 365 і визначати засоби контролю, які стримують агентів. 00:18:06.460 --> 00:18:11.620 Вам потрібні люди, які можуть покращити середовище, щоб попит на підтримку падав, а не накопичувався. 00:18:11.780 --> 00:18:16.240 Отже, як насправді почати це, щоб не перетворити все на масивний багаторічний проєкт трансформації? 00:18:16.420 --> 00:18:21.280 Найкращий крок – обрати один потік, що викликає постійні тертя у вашому середовищі Microsoft 365. 00:18:21.780 --> 00:18:27.220 Відновлення доступу зазвичай є чудовим кандидатом, але ви також можете розглянути підтримку на рад або передачу відповідності пристроїв. 00:18:27.320 --> 00:18:33.240 Неважливо, що ви оберете, головне, щоб цей шаблон повторювався часто і ви точно знали, як має виглядати успішний результат. 00:18:33.240 --> 00:18:36.900 Маючи ціль, ви повинні визначити основи з реальною дисципліною. 00:18:37.060 --> 00:18:42.060 Вам потрібно знати, як виглядає нормальний стан і які саме події свідчать про відхилення від курсу. 00:18:42.220 --> 00:18:46.620 Вирішіть, які дії безпечно автоматизувати і де саме має починатися залучення людини. 00:18:46.740 --> 00:18:53.140 Перш ніж запускати щось у роботу, переконайтеся, що у вас є базові показники кількості тікетів, ручних операцій та часу очікування користувачів на виправлення. 00:18:53.260 --> 00:18:55.680 Ви також повинні впровадити управління з першого ж дня. 00:18:55.680 --> 00:19:00.440 Надайте агенту конкретну ідентичність, призначте відповідальну людину та встановіть чіткі правила затвердження. 00:19:00.580 --> 00:19:03.480 Кожна дія, яку виконує агент, має фіксуватися в журналі. 00:19:03.580 --> 00:19:08.980 Також слід мати план на випадок відключення чи перепризначення агента, щоб він не перетворився на автоматизацію привид. 00:19:09.120 --> 00:19:12.900 Коли цей перший робочий процес запрацює, уся ваша операційна модель почне змінюватися. 00:19:13.060 --> 00:19:16.540 Підтримка перестане діяти як стіл реєстрації, що просто реагує на проблеми. 00:19:16.540 --> 00:19:20.860 Натомість вона почне працювати як механізм надійності, вбудований безпосередньо в систему. 00:19:21.020 --> 00:19:24.060 Підтримка переходить від помітної реакції до вбудованого запобігання. 00:19:24.220 --> 00:19:25.940 Тікет ніколи не був самою послугою. 00:19:26.100 --> 00:19:28.420 Це було доказом того, що послуга надійшла занадто пізно. 00:19:28.560 --> 00:19:32.520 Оберіть один процес підтримки цього кварталу та переробіть його для попередження проблем, а не відповіді на них. 00:19:32.660 --> 00:19:37.060 Якщо хочете дізнатися більше про M365 Co-Pilot, Azure, безпеку та моделі роботи з іщі, 00:19:37.160 --> 00:19:39.880 підписуйтесь на M365FM і залишайте відгуки. 00:19:39.880 --> 00:19:43.980 Зв'яжіться зі мною, Мірко Пітером, у LinkedIn і запропонуйте наступну тему для розбору.