WEBVTT

00:00:00.000 --> 00:00:04.520
Система этикетов выглядит аккуратно на бумаге. Вы получаете цифры, очереди, дашборды. Но в

00:00:04.520 --> 00:00:09.040
реальности эта модель измеряет боль лишь тогда, когда система уже дала сбой. Самая затратная часть

00:00:09.040 --> 00:00:12.780
проблемы обычно начинается гораздо раньше. Она начинается, когда сотрудник теряет 10 минут,

00:00:12.920 --> 00:00:17.220
потом 20, а затем просто сдается. Они пытаются снова. Они спрашивают коллегу. Они пропускают

00:00:17.220 --> 00:00:20.500
встречу или делятся не тем файлом, потому что привычный путь перестал работать. И это-то,

00:00:20.620 --> 00:00:24.040
чего большинство служб поддержки до сих пор не видят. Лучшая модель внутренней поддержки

00:00:24.040 --> 00:00:28.060
сегодня — это не ускорение сортировки заявок. Это полное устранение необходимости в такой

00:00:28.060 --> 00:00:32.880
сортировке. Представьте автономного агента в Microsoft 365, который очлеживает контекст,

00:00:33.100 --> 00:00:37.320
находит проблемы на раннем этапе и действует до того, как человек подумает об открытии портала.

00:00:37.460 --> 00:00:42.400
В этом выпуске я хочу показать, почему модель службы поддержки ломается, что ее заменяет и как

00:00:42.400 --> 00:00:46.140
управлять этим процессом без хаоса. Если эти изменения важны для вашей работы,

00:00:46.300 --> 00:00:51.080
подпишитесь на M365FM, ведь на уровень глубже реальная проблема не в очереди, а в модели,

00:00:51.260 --> 00:00:56.020
стоящей за ней. Смерть тикета. Старый процесс поддержки все еще повсюду. Что-то ломается.

00:00:56.020 --> 00:01:00.500
Пользователь замечает это. Пользователь пытается объяснить проблему. Затем ИТ переводит это

00:01:00.500 --> 00:01:05.240
объяснение в категорию «Приоритет» и, возможно, группу назначения. Заявка попадает в очередь.

00:01:05.380 --> 00:01:09.720
Кто-то сортирует ее. Кто-то другой запрашивает больше деталей. Подключается другая команда.

00:01:09.900 --> 00:01:13.960
Время идет, а реальная работа стоит на месте. Этот процесс кажется нормальным, потому что он

00:01:13.960 --> 00:01:19.020
привычен, но привычное и эффективное — не одно и то же. Тикет — это не поддержка. Тикет — это доказательство

00:01:19.020 --> 00:01:23.720
того, что поддержка опоздала. К моменту создания тикета сотрудник уже столкнулся с препятствиями и потерял

00:01:23.720 --> 00:01:27.780
контекст задачи. Они уже переключили свое внимание с работы, которую пытались выполнить.

00:01:27.900 --> 00:01:32.500
Очередь — это не сервис. Очередь — это журнал сбоев. В крупных инфраструктурах Microsoft 365

00:01:32.500 --> 00:01:37.080
ручная сортировка становится настоящим узким местом. Это происходит не из-за лени команд поддержки.

00:01:37.200 --> 00:01:41.120
Это происходит потому, что от людей требуют делать то, что уже не соответствует масштабу среды.

00:01:41.240 --> 00:01:45.480
У вас больше пользователей, больше устройств, больше приложений, больше политик. У вас больше сложных

00:01:45.480 --> 00:01:49.820
случаев, затрагивающих команды, SharePoint, Exchange, InTune и Intra одновременно.

00:01:49.820 --> 00:01:54.240
Объем не просто растет. Растет количество комбинаций. Вот где старая модель ломается.

00:01:54.480 --> 00:01:57.980
Большинство команд реагируют добавлением новой структуры. Они создают еще один портал,

00:01:58.060 --> 00:02:01.940
еще одного бота или еще одно правило маршрутизации. Но в реальности это лишь добавляет еще один

00:02:01.940 --> 00:02:06.600
уровень между сотрудником и решением проблемы. Система все еще ждет, когда пользователь заметит

00:02:06.600 --> 00:02:11.560
проблему, опишет ее и правильно попросит о помощи. Работа начинается не на портале поддержки,

00:02:11.680 --> 00:02:15.580
а в Teams, в Outlook, в документе, который нужен прямо сейчас, или на собрании,

00:02:15.580 --> 00:02:19.420
которая начнется через 30 секунд. Именно там возникает потребность в поддержке,

00:02:19.580 --> 00:02:23.240
а модель тикетов полностью оторвана от этого момента. Скрытые издержки гораздо выше,

00:02:23.420 --> 00:02:26.760
чем показывают ваши отчеты по очередям. Людям приходится переключаться между задачами.

00:02:27.000 --> 00:02:30.760
Дублирующиеся инциденты накапливаются под разными метками. Статьи базы знаний устаревают.

00:02:30.940 --> 00:02:34.220
Аналитики весь день занимаются сортировкой, маршрутизацией и уточнением вместо того,

00:02:34.360 --> 00:02:38.160
чтобы реально исправлять проблемы. Время решения растягивается, так как каждая передача задачи

00:02:38.160 --> 00:02:42.120
добавляет задержку, а каждая задержка стирает первоначальный контекст. Исследования в области

00:02:42.120 --> 00:02:45.740
агентного ИИ и IT-операции указывают на одну и ту же структурную проблему. По меньшей мере,

00:02:45.840 --> 00:02:50.580
80% усилий все еще уходят на реактивную работу в стиле ITIL. Эта цифра важна, потому что она точно

00:02:50.580 --> 00:02:54.080
показывает, куда уходят трудозатраты. Они уходят не на обеспечение устойчивости или

00:02:54.080 --> 00:02:57.840
предотвращение, а на реагирование. Как только вы это видите, тикет начинает выглядеть не как

00:02:57.840 --> 00:03:01.420
операционная модель, а как симптом. Это симптом системы, которая реагирует только тогда,

00:03:01.580 --> 00:03:05.200
когда ущерб уже стал очевиден. Поэтому следующий вопрос не в том, как быстрее обрабатывать тикеты,

00:03:05.200 --> 00:03:08.960
а в том, что система должна делать до того, как тикет вообще понадобится. Модель невидимого

00:03:12.120 --> 00:03:16.260
не просто очередной чат-бот поверх того же хаоса, и уж точно не более красивый фасад для все

00:03:16.260 --> 00:03:20.800
той же старой очереди. Сдвиг гораздо глубже, потому что невидимый сотрудник – это операционный

00:03:20.800 --> 00:03:25.820
работник, живущий внутри вашей среды Microsoft 365. У этого агента есть своя идентичность,

00:03:26.000 --> 00:03:29.640
определенный круг обязанностей, память о том, что он делал вчера, и строгие правила того,

00:03:29.780 --> 00:03:34.620
к чему он может и не может прикасаться. Это различие важно. Чат-бот ждет, пока вы введете запрос,

00:03:34.620 --> 00:03:39.720
а невидимый сотрудник следит за изменением условий. Он начинает с контекста, а не с разговора.

00:03:39.720 --> 00:03:44.340
Поскольку он видит состояние входа, работоспособность устройств, статус лицензий и способы обмена

00:03:44.340 --> 00:03:48.700
файлами, ему не нужно ждать появления проблем. Вместо того, чтобы спрашивать, чем он может помочь

00:03:48.700 --> 00:03:53.260
после поломки, он постоянно задает в фоновом режиме другой вопрос. Что отклоняется от состояния

00:03:53.260 --> 00:03:57.460
необходимого сотруднику для выполнения работы прямо сейчас? Именно здесь все меняется.

00:03:57.680 --> 00:04:01.820
Модель внедрена непосредственно в саму работу. Когда кто-то присоединяется к собранию,

00:04:01.820 --> 00:04:06.060
избоит маршрутизация аудио, или гость не может открыть только что отправленный ему файл,

00:04:06.060 --> 00:04:10.580
старый мир создает отчет и передачу задачи. В новой модели агент мгновенно распознает шаблон,

00:04:10.740 --> 00:04:14.780
проверяет, соответствует ли условия известной проблеме, и выполняет следующее безопасное действие

00:04:14.780 --> 00:04:18.360
для ее устранения. Может быть, он сбрасывает путь или запускает проверку политик,

00:04:18.480 --> 00:04:22.200
или перенаправляет запрос и запрашивает МФА перед тем, как задокументировать исправление.

00:04:22.400 --> 00:04:26.840
Суть проста. Первый ответ больше не требует, чтобы человек читал расплывчатое описание и гадал,

00:04:26.840 --> 00:04:31.100
что произошло. Когда все работает хорошо, это кажется незаметным, ведь нет никакого зала ожидания и формы,

00:04:31.180 --> 00:04:34.900
пожалуйста, выберите категорию для заполнения. Поддержка выглядит как восстановление рабочего

00:04:34.900 --> 00:04:38.700
процесса. Сотрудник просто возвращается к работе, и во многих случаях он даже не видит,

00:04:38.800 --> 00:04:42.920
как работает механизм за кулисами. Вы уже можете видеть, как это меняет вашу логику подбора

00:04:42.920 --> 00:04:47.260
персонала. Старая модель нанимает людей для обработки объемов, сортировки запросов и устранения

00:04:47.260 --> 00:04:51.600
разрывов в контексте между разными командами. Новой модели нужно меньше людей на сортировке и больше

00:04:51.600 --> 00:04:56.400
тех, кто создает правила, определяет желаемые состояния и контролирует поведение агентов с течением

00:04:56.400 --> 00:05:01.360
времени. Люди остаются в системе, но весь характер их повседневной работы меняется. Исследования

00:05:01.360 --> 00:05:06.100
агентного и в поддержке постоянно указывают на это направление. Рутинная поддержка может перейти

00:05:06.100 --> 00:05:11.040
к управлению на основе исключений, что создает огромный прирост эффективности, когда среда и политики

00:05:11.040 --> 00:05:15.800
четко ограничены. Последнее крайне важно, потому что это не магия. Если ваши данные слабы,

00:05:15.900 --> 00:05:20.260
а процессы хаотичны, агент не станет умным только потому, что вы решили назвать его автономным.

00:05:20.260 --> 00:05:24.160
Для меня все встало на свои места, когда я перестал думать об агенте как о функции ПА и начал

00:05:24.160 --> 00:05:28.280
рассматривать его как нечеловеческого сотрудника с пропуском. Настоящему работнику нужны личность,

00:05:28.280 --> 00:05:32.740
должностная инструкция, права доступа и менеджер, которому он отчитывается. Агенту нужно ровно то же

00:05:32.740 --> 00:05:37.080
самое, потому что ценность заключается в надежных действиях внутри системы, а не в умных фразах

00:05:37.080 --> 00:05:41.520
в окне чата. Невидимый сотрудник – это не трюк интерфейса. Это новый уровень поддержки,

00:05:41.640 --> 00:05:46.740
который следит за трениями в экосистеме Microsoft 365, действует в рамках политик и переключает

00:05:46.740 --> 00:05:50.820
внимание людей на исключения, требующие суждения. Как только эта модель становится ясной,

00:05:51.020 --> 00:05:54.480
следующий вопрос становится очень практичным. Как именно работает превентивность?

00:05:54.480 --> 00:05:59.360
Архитектура превентивности. Итак, как именно работает превентивность внутри Microsoft 365?

00:05:59.780 --> 00:06:04.200
Сдвиг происходит от запроса и ответа к анализу событий и оркестрации. Звучит технически,

00:06:04.420 --> 00:06:09.100
но модель проста, если ее разобрать. Сначала что-то меняется в среде, затем система интерпретирует,

00:06:09.200 --> 00:06:13.400
означает ли это изменение риск или отклонение, и, наконец, предпринимает одобренное действие,

00:06:13.400 --> 00:06:19.060
используя инструменты в вашем стеке. Начнем с уровня событий. Microsoft 365 уже создает сигналы

00:06:19.060 --> 00:06:24.040
повсюду. Интро очлеживает поведение при входе, а инчун – состояние и соответствие устройств.

00:06:24.040 --> 00:06:27.180
Defender следит за подозрительной активностью, а Teams точно показывает,

00:06:27.340 --> 00:06:31.900
когда произошел сбой встречи или упало качество связи. SharePoint и Exchange раскрывают схемы доступа

00:06:31.900 --> 00:06:35.720
и активность с контентом, а сигналы о состоянии службы сообщают, когда проблема на стороне

00:06:35.720 --> 00:06:39.440
платформы. Если добавить к этому действия пользователей, у вас появится постоянный поток

00:06:39.440 --> 00:06:43.520
контекстных данных. Большинство организаций собирают эти сигналы, но лишь немногие используют

00:06:43.520 --> 00:06:48.040
их как систему поддержки. Сами по себе сырые события бесполезны, им нужен уровень логического анализа,

00:06:48.220 --> 00:06:51.700
чтобы упорядочить этот шум. Именно здесь невидимый сотрудник перестает быть имитацией

00:06:51.700 --> 00:06:55.040
автоматизации и начинает работать как реальный оператор. Агент анализирует сигнал,

00:06:55.220 --> 00:06:59.280
сравнивает текущее состояние с целевым и решает, какие действия можно безопасно предпринять.

00:06:59.420 --> 00:07:03.520
Проблема со звуком на встрече – это не то же самое, что рискованный вход, а неработающая ссылка

00:07:03.520 --> 00:07:07.160
отличается от несовпадения лицензий. Агент должен сначала классифицировать проблему,

00:07:07.400 --> 00:07:10.140
иначе действия без классификации лишь быстрее приведут к ошибкам.

00:07:10.340 --> 00:07:14.780
Затем следует оркестрация. Как только агент понимает проблему, он может использовать подходящий

00:07:14.780 --> 00:07:17.660
механизм для ответа. Это может быть Power Automate для рабочих процессов,

00:07:17.660 --> 00:07:21.020
Copilot Studio для логики или Microsoft Graph для действий в системе и контекста.

00:07:21.180 --> 00:07:25.440
Инструменты важны, но самое главное – то, как они связаны друг с другом. Вы создаете не один

00:07:25.440 --> 00:07:29.340
умный запрос, а цепочку, которая может обнаруживать, решать, действовать и проверять.

00:07:29.460 --> 00:07:33.320
Эту последнюю часть постоянно упускают из виду. Самокорректирующаяся система не

00:07:33.320 --> 00:07:37.260
останавливается после выполнения действия. Она работает в цикле, обнаруживает проблему,

00:07:37.560 --> 00:07:41.640
тестирует условия, применяет исправление и проверяет результат, прежде чем записать итог.

00:07:41.840 --> 00:07:45.780
Исследования самокорректирующейся логики показывают, что такие системы работают через

00:07:45.780 --> 00:07:49.360
обратную связь и паттерны исправления, а не через один ответ языковой модели.

00:07:49.560 --> 00:07:53.860
Если первое действие не помогло, система должна оценить причину, чтобы скорректировать

00:07:53.860 --> 00:07:58.120
следующий шаг в рамках заданных ограничений. Это хорошо видно на примере нескольких сценариев

00:07:58.120 --> 00:08:02.980
в Microsoft 365. Когда пользователя блокируют из-за несоответствия лицензии и политик,

00:08:03.240 --> 00:08:07.820
агент обнаруживает проблему и проверяет нужный профиль роли. Он применяет допустимое исправление,

00:08:08.120 --> 00:08:11.660
подтверждает доступ пользователя и логирует изменения без участия человека.

00:08:11.660 --> 00:08:16.200
Если в интро фиксируется рискованный вход, агент видит событие риска и немедленно сверяется с

00:08:16.200 --> 00:08:20.360
вашими правилами условного доступа. Он запрашивает дополнительную проверку или блокирует доступ

00:08:20.360 --> 00:08:24.120
согласно политике, а затем записывает результат для последующего анализа человеком.

00:08:24.220 --> 00:08:28.240
Когда устаревшая общая ссылка в SharePoint перестает работать, агент сравнивает текущий

00:08:28.240 --> 00:08:32.360
путь доступа с ожидаемыми правилами общего доступа. Он заменяет нерабочий корневой путь на

00:08:32.360 --> 00:08:35.960
корректный и отправляет исправленную ссылку в контексте, закрывая вопрос до того,

00:08:36.100 --> 00:08:40.320
как специалист техподдержки успеет прочитать тикет с пометкой «Срочно, проблема с доступом».

00:08:40.320 --> 00:08:44.720
Поддержка собраний – еще один отличный пример. Если устройство в переговорной выходит из строя или

00:08:44.720 --> 00:08:48.300
путь подключения обрывается за секундой до начала звонка, агент может обнаружить проблему и

00:08:48.300 --> 00:08:51.860
подтвердить сбой. Он выполняет безопасное действие по восстановлению и уведомляет организаторов

00:08:51.860 --> 00:08:56.340
Teams, предоставляя отчет о статусе прямо там, где ведется работа. Этот уровень взаимодействия – важнейшая

00:08:56.340 --> 00:09:01.100
часть архитектуры. Поддержка должна находиться там, где происходит сбой. Если ваша работа проходит в

00:09:01.100 --> 00:09:06.240
Teams, Outlook и рабочем пространстве M365, то и поддержка должна отвечать вам там же. Не стоит заставлять

00:09:06.240 --> 00:09:09.780
пользователя переходить в другие системы, если можно решить проблему прямо в контексте работы.

00:09:09.780 --> 00:09:13.600
Все это не означает полную автоматизацию всех задач без исключения, так как это было бы

00:09:13.600 --> 00:09:17.500
опромечиво. Действия с низким уровнем риска могут выполняться автоматически, но значимые изменения

00:09:17.500 --> 00:09:21.280
все равно требуют подтверждения человеком. Путь для такого подтверждения должен быть частью

00:09:21.280 --> 00:09:25.640
архитектуры с самого начала, а не добавляться позже. Агент должен знать, когда действовать,

00:09:25.820 --> 00:09:29.660
когда спрашивать и когда именно остановиться. И как только вы внедрите это в рабочий процесс,

00:09:29.940 --> 00:09:33.940
дискуссия перестанет касаться только функции автоматизации. Она перейдет к вопросам контроля,

00:09:34.100 --> 00:09:37.940
управления, доверия и идентификации агента. Когда поддержка начинает действовать

00:09:37.940 --> 00:09:42.280
самостоятельно, сразу возникает сложный вопрос. Кто на самом деле выполняет эту работу?

00:09:42.480 --> 00:09:46.800
Если ответ на него расплывчат, вся модель рушится. Агент не может существовать в вашей среде как

00:09:46.800 --> 00:09:50.660
некий абстрактный помощник с широким доступом и без четкого владельца. Ему нужна полноценная

00:09:50.660 --> 00:09:54.540
учетная запись в интро. Ему нужны назначенный владелец, определенная область действия и жизненный

00:09:54.540 --> 00:09:58.280
цикл, который начинается и заканчивается по конкретной причине. Если агент может читать данные,

00:09:58.520 --> 00:10:02.220
запускать рабочие процессы или писать пользователям, вы должны управлять им как полноправным

00:10:02.220 --> 00:10:06.360
участником арендатора. Нельзя относиться к нему как к функции, которую кто-то включил и забыл.

00:10:06.360 --> 00:10:10.560
Именно поэтому идентификация агента так критически важна для системы. Вы должны точно знать,

00:10:10.720 --> 00:10:14.640
что это за агент, каким системам он имеет доступ и кому поступит звонок, если что-то пойдет не так.

00:10:14.760 --> 00:10:18.580
Принцип минимальных привилегий должен стать здесь основой. Нельзя довольствоваться общим доступом

00:10:18.580 --> 00:10:22.460
ради удобства или обещать себе, что вы ограничите разрешение позже. Поскольку зона поражения

00:10:22.460 --> 00:10:26.480
агента поддержки полностью зависит от его разрешений, проектирование этих разрешений является

00:10:26.480 --> 00:10:31.980
ключевой частью проектирования поддержки. Агент 365 служит необходимым уровнем контроля в этой системе,

00:10:32.160 --> 00:10:35.940
поскольку позволяет полностью контролировать весь парк агентов. Он предоставляет реестр,

00:10:35.940 --> 00:10:40.160
рабочие процессы согласования и шаблоны политик, которые обеспечивают безопасность работы.

00:10:40.300 --> 00:10:44.420
Хотя эти элементы могут показаться административной рутиной, они решают огромную структурную

00:10:44.420 --> 00:10:48.460
проблему. Большинство организаций испытывают трудности не из-за нехватки функций и, а потому,

00:10:48.640 --> 00:10:52.700
что они не видят и не контролируют то, что уже работает в их среде. Исследования по этому вопросу

00:10:52.700 --> 00:10:56.300
однозначны. Лишь небольшое число крупных предприятий могут полностью инвентаризировать

00:10:56.300 --> 00:10:59.980
каждого агента, работающего в их системе в данный момент. Прежде чем руководители начнут

00:10:59.980 --> 00:11:03.640
говорить о масштабировании автономной поддержки, им нужно ответить на гораздо более простой вопрос.

00:11:03.640 --> 00:11:07.180
Знаем ли мы вообще, какие агенты существуют и чем они занимаются прямо сейчас?

00:11:07.340 --> 00:11:11.520
Надзор также должен соответствовать уровню связанного с ним риска. Агент личной продуктивности,

00:11:11.700 --> 00:11:15.780
работающий в узкой нише, это одно, а агент для совместной работы с общим контентом – совсем

00:11:15.780 --> 00:11:19.640
другое. Кроме того, существуют корпоративные агенты, выполняющие действия в критически важных

00:11:19.640 --> 00:11:23.360
процессах, что относится к иной категории риска. Вот почему модель зон риска – личная,

00:11:23.540 --> 00:11:27.080
совместная и корпоративная – так важна. Ваша модель контроля должна усиливаться

00:11:27.080 --> 00:11:30.720
пропорционально возможному воздействию. Если вы относитесь ко всем агентам одинаково,

00:11:30.720 --> 00:11:34.860
низкорисковая работа застревает в долгих согласованиях, а высокорисковая проходит без должного

00:11:34.860 --> 00:11:39.700
внимания. Как минимум, ваш стэк контроля в Microsoft 365 должен быть знаком вашей команде.

00:11:39.860 --> 00:11:43.840
Вы используете идентификацию в интро, границы данных через первью и мониторинг через

00:11:43.840 --> 00:11:48.060
Defender. Вы применяете условия доступа через условный доступ и обеспечиваете встроенную

00:11:48.060 --> 00:11:51.660
возможность аудита с самого начала. Вы должны иметь возможность точно восстановить

00:11:51.660 --> 00:11:56.120
произошедшее, не гадая после того, как случился инцидент. Человеческий контроль должен быть

00:11:56.120 --> 00:11:59.940
заложен в логику, а не импровизироваться во время кризиса. Действия с высоким уровнем

00:11:59.940 --> 00:12:04.080
воздействия всегда должны ожидать подтверждения человеком. Обоснования должны записываться в форме,

00:12:04.200 --> 00:12:07.940
которую люди могут реально проверить и понять. У вас должны быть пути отката еще до того,

00:12:08.120 --> 00:12:12.060
как начнет выполняться первое автономное действие. Если агент обновляет доступ или меняет

00:12:12.060 --> 00:12:15.580
политику маршрутизации, у кого-то должна быть возможность отследить это решение и корректно

00:12:15.580 --> 00:12:18.980
отменить его. Есть еще один фактор, который руководители часто упускают из виду, потому что

00:12:18.980 --> 00:12:23.160
ранние демо-версии выглядят так хорошо. Стоимость переделки. Если агент создает циклы доработки

00:12:23.160 --> 00:12:27.880
для вашей команды, прогнозируемая экономия мгновенно исчезает. Это налог на переработку. Это время,

00:12:27.880 --> 00:12:32.060
затрачиваемое на исправление ошибок, отмену неверных действий или устранение непредвиденных

00:12:32.060 --> 00:12:36.200
побочных эффектов. Если ваша команда экономит 10 минут на выполнении, но тратит 8 минут на

00:12:36.200 --> 00:12:39.840
разбор последствий, вы на самом деле не автоматизировали поддержку. Вы просто переместили

00:12:39.840 --> 00:12:43.580
трудности в другую часть процесса. Доверие не возникает из красивых презентаций с политиками

00:12:43.580 --> 00:12:46.720
или громких анонсов запуска. Оно появляется на основе доказательств в процессе работы.

00:12:46.920 --> 00:12:50.220
Людям нужно видеть, что видел, агент, какие решения принял и что именно изменилось в системе.

00:12:50.220 --> 00:12:54.260
Именно так вы строите доверие к автономной поддержке. Доказательства должны заключаться в

00:12:54.260 --> 00:12:58.840
поведении инструмента, а не в брендинге проекта. Как только фундамент управления станет прочным,

00:12:59.080 --> 00:13:03.940
разговор наконец перейдет с жаргона безопасности на язык бизнеса. Что это на самом деле меняет

00:13:03.940 --> 00:13:08.860
для итоговой прибыли? Новый ROI невидимой поддержки. Когда руководители принимают модель контроля,

00:13:09.060 --> 00:13:13.500
финансовые вопросы начинают меняться. В старой модели ценность поддержки измеряется видимой работой,

00:13:13.680 --> 00:13:19.200
закрытыми тикетами, звонками и соблюдением SLA. Эти цифры все еще важны, но они описывают лишь реакцию

00:13:19.200 --> 00:13:23.520
на проблему. Они не показывают, сколько сбоев не попало в очередь или сколько времени сотрудников было

00:13:23.520 --> 00:13:28.380
сохранено, потому что проблему устранили сразу. Это главная проблема учета. Невидимая поддержка

00:13:28.380 --> 00:13:33.420
создает ценность через свое отсутствие. Вы видите ценность, когда нет тикета, нет эскалации и

00:13:33.420 --> 00:13:38.040
аналитику не нужно 20 минут восстанавливать проблему по неполным заметкам. Если вы измеряете

00:13:38.040 --> 00:13:41.900
только видимые усилия команды поддержки, вы упускаете тот результат, который действительно

00:13:41.900 --> 00:13:46.460
хотели. Вам нужна стабильная работа с минимумом перерывов. Объем тикетов – слабый показатель,

00:13:46.640 --> 00:13:50.680
если рассматривать его отдельно. Падение числа тикетов может означать спад спроса, но также может

00:13:50.680 --> 00:13:54.960
означать, что среда стала здоровее, а поддержка умнее. Это две совершенно разные истории.

00:13:55.420 --> 00:14:00.200
Руководителям нужен набор KPI, способный их различить. Начните с анализа коэффициента

00:14:00.200 --> 00:14:05.180
автономного решения. Речь не о том, сколько диалогов провел бот, а о том, сколько инцидентов было

00:14:05.180 --> 00:14:09.760
решено от начала до конца без участия человека. Вам также нужно отслеживать сокращение среднего

00:14:09.760 --> 00:14:15.620
времени решения. В средах и в процессах, требующих диагностики, улучшения часто составляют от 40 до 60%.

00:14:15.620 --> 00:14:19.640
Затем можно оценить стоимость одного решения и возвращенную продуктивность пользователей.

00:14:19.640 --> 00:14:23.820
Последний показатель легко пропустить, так как он не вписывается в стандартные отчеты службы

00:14:23.820 --> 00:14:28.880
поддержки. Однако именно в нем часто скрыта реальная ценность. Человек, заблокированный на 15 минут

00:14:28.880 --> 00:14:33.800
еще до того, как открыл тикет, уже создал убыток для компании. Если умножить это на срывы встреч и

00:14:33.800 --> 00:14:38.380
проблемы с доступом в крупной компании, скрытые потери гораздо выше, чем показывает очередь.

00:14:38.540 --> 00:14:43.040
Вот почему модель стоимости бездействия так важна для бизнес-кейса. Вы почитываете часы,

00:14:43.180 --> 00:14:47.420
потраченные наручные действия еще до начала формальной поддержки. Затем добавьте к этому стоимость

00:14:47.420 --> 00:14:51.620
ошибок и передела. Внезапно аргументы в пользу превентивных мер перестают звучать как теория.

00:14:51.800 --> 00:14:55.500
Вы не просто финансируете футуристичный уровень поддержки. Вы избавляетесь от налога,

00:14:55.600 --> 00:14:59.340
который годами был скрыт в вашей повседневной работе. Экономика узкоспециализированных кейсов

00:14:59.340 --> 00:15:03.100
делает это еще более очевидным. Исследования агентской ИТ-поддержки оценивают работу человека

00:15:03.100 --> 00:15:07.660
примерно в 8,75 доллара за запрос. Напротив, стоимость обработки узкоспециализированным

00:15:07.660 --> 00:15:12.260
агентом может упасть ниже 50 центов, как только система будет внедрена. Это не значит, что любое обращение

00:15:12.260 --> 00:15:16.040
будет стоить так дешевой, поэтому лидерам следует осторожнее относиться к общим средним показателям.

00:15:16.200 --> 00:15:20.980
Качество телеметрии и управления всегда будут влиять на итоговую стоимость, но направление тренда

00:15:20.980 --> 00:15:25.680
очевидно. Это момент, когда ИТ перестает быть просто центром затрат. Это происходит не потому,

00:15:25.940 --> 00:15:30.400
что поддержка исчезает, а потому, что она превращается в уровень надежности, который фоново защищает

00:15:30.400 --> 00:15:35.100
продуктивность сотрудников. Бизнес ощущает это как более плавный рабочий процесс, а не как череду кризисных

00:15:35.100 --> 00:15:39.660
ситуаций. У вас меньше прерываний, быстрее восстановление и меньше труда тратится на маршрутизацию и

00:15:39.660 --> 00:15:44.300
уточнение. Тем не менее, плохие показатели могут легко создать иллюзию прогресса. Если телеметрия

00:15:44.300 --> 00:15:48.080
слабая, агент может просто быстрее резюмировать сбой, вместо того, чтобы предотвратить его.

00:15:48.240 --> 00:15:52.000
Если переделки не отображаются на дашбордах, ROI будет выглядеть гораздо лучше, чем есть на самом

00:15:52.000 --> 00:15:56.560
деле. Если высвобожденное время снова уходит на низкоценные задачи, лидеры переоценят полученный

00:15:56.560 --> 00:16:00.520
эффект. Финансовое обоснование должно опираться на твердые факты, такие как предотвращенные инциденты

00:16:00.520 --> 00:16:04.600
и сокращение ручных операций. Необходимо измерять время, которое действительно вернулось в полезную

00:16:04.600 --> 00:16:08.080
работу. Как только вы начнете измерять это правильно, поддержка перестанет выглядеть как накладные

00:16:08.080 --> 00:16:12.060
расходы, которые нужно сокращать. Она начнет выглядеть как операционный ресурс, который бизнес

00:16:12.060 --> 00:16:16.560
наконец возвращает себе. Что это дает команде поддержки? Подумайте о том, как это влияет на

00:16:16.560 --> 00:16:20.700
сотрудников на местах. Этот сдвиг не столько о сокращении штата, сколько об изменении того,

00:16:20.900 --> 00:16:24.920
чем люди занимаются в течение дня. В старой модели большая часть ресурсов поддержки съедается

00:16:24.920 --> 00:16:29.280
сбросом паролей, маршрутизацией этикетов и бесконечными циклами уточнений. Люди тратят время на

00:16:29.280 --> 00:16:32.800
отслеживание обновлений и перенос данных между системами, которые никогда не были рассчитаны на

00:16:32.800 --> 00:16:36.860
взаимодействие. Ничего из этой работы не делает среду стабильнее, это лишь не дает очереди

00:16:36.860 --> 00:16:41.180
переполниться. Когда агенты берут на себя эту предсказуемую рутину, человеческие усилия наконец

00:16:41.180 --> 00:16:44.780
выходят на новый уровень. Инженеры поддержки начинают тратить время на определение того,

00:16:44.980 --> 00:16:49.600
что такое здоровое состояние системы и настройку логики согласований. Они фокусируются на улучшении

00:16:49.600 --> 00:16:53.820
баз знаний, тестировании политик и проверке того, чтобы агент оставался в заданных рамках.

00:16:53.960 --> 00:16:57.960
Это совершенно другая работа, нежели целыми днями смотреть на темы писем и пытаться угадать,

00:16:57.960 --> 00:17:02.340
чего на самом деле хочет пользователь. Именно на этом этапе большинство внедрений заходит в тупик.

00:17:02.340 --> 00:17:06.840
Организации пытаются сохранить старые неэффективные процессы, просто добавив сверху агента и

00:17:06.840 --> 00:17:11.220
ожидая лучших результатов. Но процесс остается реактивным, передача задач запутанной,

00:17:11.380 --> 00:17:15.820
а база знаний слабой. Агент становится лишь еще одним слоем краски на разрушающейся стене.

00:17:15.940 --> 00:17:19.820
Он может быстрее ответить на вопрос, но не исправит модель поддержки, построенную на задержках.

00:17:20.000 --> 00:17:24.420
Лучший способ – сначала пересмотреть саму работу. Нужно решить, какие задачи останутся за людьми,

00:17:24.420 --> 00:17:28.720
так как они требуют суждения или деликатного общения. Затем решить, что перейдет в автономные

00:17:28.720 --> 00:17:32.580
потоки, где результат предсказуем, а действия безопасны. Это разделение жизненно важно,

00:17:32.780 --> 00:17:36.080
ведь команды поддержки никуда не исчезнут. Они просто станут людьми, которые проектируют

00:17:36.080 --> 00:17:39.740
системы контроля и обрабатывают исключения. Это значит, что и подход к обучению сотрудников

00:17:39.740 --> 00:17:43.700
должен измениться. Командам нужно учиться контролировать систему, а не просто выполнять

00:17:43.700 --> 00:17:48.840
ручные операции. Они должны понимать логику отката, аудита и то, как тестировать агента перед

00:17:48.840 --> 00:17:53.880
запуском. Они также должны видеть, когда модель дает сбой, ведь плохой рабочий процесс в автоматизации

00:17:53.880 --> 00:17:57.960
остается плохим. Он просто быстрее все ломает. Если вы нанимаете людей для такого будущего,

00:17:58.100 --> 00:18:00.700
вам вряд ли нужен очередной специалист широкого профиля для разбора этикетов.

00:18:00.860 --> 00:18:06.200
Вам нужен тот, кто сможет выстраивать потоки в стеке Microsoft 365 и определять правила контроля

00:18:06.200 --> 00:18:11.720
агентов. Вам нужны люди, которые улучшат среду так, чтобы спрос на поддержку падал, а не рос.

00:18:11.860 --> 00:18:16.100
Как же начать это, не превращая все в масштабный многолетний проект по трансформации?

00:18:16.100 --> 00:18:21.420
Лучший шаг – выбрать один поток, который постоянно вызывает трение в вашей среде Microsoft 365.

00:18:21.420 --> 00:18:25.560
Восстановление доступа обычно отлично подходит, но можно рассмотреть поддержку встреч или

00:18:25.560 --> 00:18:30.480
передачу задач по комплайнсу устройств. Неважно, что вы выберете, главное, чтобы ситуация повторялась

00:18:30.480 --> 00:18:34.560
часто и вы точно знали, каким должен быть успешный результат. Как только цель ясна,

00:18:34.820 --> 00:18:39.560
нужно определить основы с железной дисциплиной. Вы должны знать, как выглядит норма и какие именно

00:18:39.560 --> 00:18:43.920
события сигнализируют о том, что все идет не по плану. Определите, какие действия безопасно

00:18:43.920 --> 00:18:47.960
автоматизировать и где именно должно начинаться вмешательство человека. Перед запуском обязательно

00:18:47.960 --> 00:18:52.400
зафиксируйте базовые показатели, количество тикетов, ручных операций и время ожидания решения

00:18:52.400 --> 00:18:56.260
пользователями. Вам также нужно внедрить систему управления с самого первого дня. Присвойте

00:18:56.260 --> 00:18:59.640
агенту четкую идентичность, назначьте ответственного сотрудника и установите правила

00:18:59.640 --> 00:19:03.600
утверждения действий. Каждое действие, которое выполняет агент, должно фиксироваться в журнале.

00:19:03.740 --> 00:19:07.800
Также у вас должен быть план на случай вывода агента из эксплуатации, чтобы он не превратился

00:19:07.800 --> 00:19:12.060
в автоматизацию призрак. Как только первый процесс начинает работать, вся ваша операционная модель

00:19:12.060 --> 00:19:16.180
начинает меняться. Служба поддержки перестает быть просто стойкой регистрации, которая лишь реагирует

00:19:16.180 --> 00:19:19.860
на проблемы. Вместо этого она начинает действовать как механизм надежности, встроенный

00:19:19.860 --> 00:19:23.380
непосредственно в систему. Поддержка переходит от заметного реагирования к встроенному

00:19:23.380 --> 00:19:27.340
предотвращению проблем. Тикет никогда не был самой услугой. Он был лишь доказательством того,

00:19:27.520 --> 00:19:31.280
что услуга запоздала. Выберите один процесс поддержки в этом квартале и переработайте его для

00:19:31.280 --> 00:19:35.740
упреждения, а не реагирования. Если вам интересно узнать больше о М365 Капайлот, Азур,

00:19:35.860 --> 00:19:40.780
безопасности и операционных моделях, подпишитесь на М365FM и оставьте отзыв. Свяжитесь со мной,

00:19:40.780 --> 00:19:44.000
Мирку Питером, в LinkedIn и предложите следующую тему для разбора.