Все статьи

Независимый разбор

Лучшая автоматизация тикетов — это 15 минут до начала работы инженера

Ранние результаты Aderant в production указывают на более узкую и практичную точку входа для ИИ в операциях: убрать подготовительное расследование, которое задерживает эксперта в очереди, прежде чем поручать модели решение инцидента.

MP
Max PerfiljevFounder & CEO, AES · Архитектор автономных организаций
Read in English

Первой практической задачей ИИ в работе квалифицированных операционных команд может быть не решение тикета. Ею может стать устранение 15 минут подготовительного расследования, которые проходят до того, как инженер вообще приступит к решению.

Именно такой вывод позволяют сделать ранние production-результаты Intelligent Ticket Analyzer компании Aderant. Система помогает команде SierraOps из 38 человек, обслуживающей Expert Sierra в 268 клиентских средах. Прежде чем предложить исполнителя или следующий шаг, она собирает контекст из Jira, Confluence, Amazon Athena и Microsoft SharePoint. Затем классифицирует тикет, сопоставляет его с доступными знаниями и готовит отправную точку для специалиста, который возьмёт работу.

Это намеренно менее масштабная цель, чем автономное устранение инцидентов. Но она гораздо ближе к реальному источнику трения в очереди многих команд поддержки и разработки. Эксперту часто не хватает не возможного ответа. Его задерживает работа по установлению самого вопроса: какой среды он касается, что происходило раньше, где находится документация и кому правильнее передать задачу. Эта подготовка повторяется, проходит через несколько систем и необходима. Её границы конкретнее, чем границы экспертного суждения, поэтому она и является более подходящей целью для автоматизации.

Начинать стоит с работы до работы

До внедрения Aderant измерила исходный уровень: на ручное расследование одного тикета уходило 15–25 минут, а средний недельный поток составлял 34–40 тикетов. Из этого получается понятная оценка: если поток снимает заметную часть подготовки, он может высвобождать 8–14 инженерных часов в неделю. Это расчёт Aderant на основе четырёхнедельного базового периода, а не напрямую измеренный прирост производительности, финансовый эффект или сокращение времени решения для клиента.

Различие принципиально. Для тикета всё ещё могут понадобиться сложная диагностика, общение с клиентом, изменение кода или координация с другой командой. Более качественная маршрутизация не доказывает, что любой из этих этапов ускорится. Но она меняет начальные условия экспертной работы: инженер получает задачу с собранным контекстом, предложенным назначением и рабочей первой гипотезой, а не пустую запись в очереди и необходимость искать сведения в нескольких системах.

Именно здесь многие программы автоматизации начинают не с того места. Они противопоставляют решение человеком решению машиной, а затем обнаруживают, что трудность не в генерации ответа. Трудность — собрать верные операционные факты и связать их с определённым действием. Более надёжный подход — сначала сделать эту подготовку видимой и измеримой, а затем автоматизировать части с повторяемыми входными данными и наблюдаемыми результатами.

Модель — лишь один компонент подготовленного процесса

Решение Aderant не следует воспринимать как самостоятельную работу языковой модели. Его полезный результат зависит от детерминированных интеграций, плановой оркестрации, операционных метаданных, существующей документации и логики маршрутизации — наряду с модельным выводом. Анализатор запускается каждый час в будние дни, а не непрерывно. Он собирает доступную запись о задаче, после чего формирует рекомендации по назначению и следующим шагам внутри процесса, построенного вокруг подключённых систем.

Для команд, планирующих подобную работу, из этой архитектуры следует важный вывод: прежде чем расширять свободу модели, улучшите сбор контекста. Хорошо сформулированная рекомендация не компенсирует отсутствие истории тикета, разрозненные базы знаний или неясное распределение ответственности. Напротив, если нужный контекст можно собирать последовательно, задача модели сужается: интерпретировать подготовленный случай, классифицировать его и вернуть структурированную рекомендацию, пригодную для людей и следующих систем.

Этому внедрению предшествовал другой проект Aderant, объединивший поиск по шести системам. Это содержательная последовательность. Поиск, вызываемый человеком, сформировал общий способ находить операционные знания. Плановая автоматизация процесса затем применила эти связанные знания к входящей работе. Это не автономная система, созданная с нуля, — и ей не нужно ею быть. Операционная ценность состоит в том, чтобы превратить повторяющийся поиск и сортировку в уже подготовленную рабочую задачу.

Узкое право на действие нужно заслужить результатами живой работы

От концепции до production Aderant дошла за пять недель; примерно две из них система работала в режиме только мониторинга на живых тикетах до запуска в production. В начальный период измерения — с 30 июня по 17 июля 2026 года — анализатор обработал 109 тикетов. Зафиксированы четыре ошибочные маршрутизации, что Aderant описывает как приблизительно 96% точности маршрутизации. Показатель получен сравнением назначения системы с командой, которая в итоге решила тикет.

Это полезное свидетельство, но оно говорит ровно об одном: в этой выборке рекомендация по маршрутизации обычно совпадала с командой, реально завершившей работу. Это не точность решения тикетов. Результат не показывает, что анализатор правильно диагностировал инциденты, автономно их устранял или сокращал сквозное время решения. И 109 тикетов за примерно две с половиной недели не образуют зрелого долгосрочного бенчмарка.

Тем не менее это именно тот тип свидетельства, который нужен для введённого Aderant действия. Команда не перепрыгнула от прототипа к широкой автономии. Она наблюдала рекомендации на реальной работе, сопоставляла их с фактическими исходами, а затем разрешила ограниченное операционное воздействие. Тикеты, для которых достигается настроенный порог уверенности, могут направляться автоматически. Классификации с меньшей уверенностью отправляются на проверку человеку.

Такая последовательность применима шире, потому что связывает масштаб автоматизации с доказательствами, а не с амбициями. Режим только мониторинга проверяет процесс, не меняя очередь. Сопоставление с исходами позволяет понять, соответствует ли предложенное назначение тому, как организация действительно решает задачи. Порог уверенности формирует практическую границу: автоматизировать случаи, для которых система заслужила достаточно доверия, и сохранять проверку для остальных.

Измеряйте трение в очереди, а не амбиции модели

Заявленная экономика дополнительно подтверждает пользу старта с подготовки. В начальный период Aderant сообщила об общих операционных расходах менее $30 в месяц, при этом на inference в Bedrock приходилось менее $1 в месяц. Эти цифры относятся к конкретной реализации и периоду; их нельзя превращать в универсальный ориентир стоимости. Но они яснее показывают стратегический смысл. Когда автоматизация устраняет повторяющееся расследование в уже существующих системах, стоимость inference может оказаться небольшой частью операционной картины. Дорогим ресурсом часто оказывается внимание квалифицированных специалистов, которые заново собирают контекст.

Поэтому для руководителя операционной функции первый вопрос должен быть предельно конкретным: где опытные люди снова и снова тратят 10, 15 или 25 минут, чтобы подготовиться к настоящей работе? Ищите очереди, в которых перед первым содержательным решением сотруднику приходится вручную собирать историю, детали среды, сведения о владельце, известные исправления и подтверждающие документы. До автоматизации измерьте поток, время подготовки и фактический исход.

После этого проектируйте процесс по порядку. Детерминированно собирайте фактический контекст. Требуйте от модели структурированную классификацию и рекомендацию, а не свободный рассказ. Запустите её на живой работе без права действия. Сопоставьте рекомендации с реальным назначением или результатом. И только затем автоматизируйте конкретные действия, которые подтверждены этой историей, сохранив понятный путь к человеку при неопределённости.

Задача не в том, чтобы сделать вид, будто сложное инженерное суждение исчезло. Задача — перестать тратить экспертное время на один и тот же подготовительный поиск в начале каждого тикета. Ранние данные Aderant не доказывают существование автономной службы поддержки. Они показывают нечто более применимое уже сейчас: с очередью легче работать, когда первые пятнадцать минут приходят уже собранными.

ПОСТРОИТЬ С AES

Превратите архитектуру в работающую компанию.

AES связывает стратегию, задачи, организационную память, знания, агентов, людей и согласования в единой среде исполнения.