Мы создали ИИ-агента для ServiceNow. Реальные проблемы оказались гораздо уже, чем предполагалось в нашей дорожной карте
На нашей платформе ITSM никогда не было недостатка в данных, но понять, о чём они говорят и какие действия следует предпринять, было не всегда просто — несмотря на время, потраченное на создание элементов каталога, интерпретацию данных и лицензий на использование, а также поддержание работоспособности CMDB.
В этом году моя компания создала цифрового сотрудника, который помогает нашей ИТ-команде вернуть часть этого времени и получить больше отдачи от инвестиций в ITSM. Нам нужен был не универсальный агент, а решение, которое действительно понимает и умеет выполнять задачи ITSM, действительно влияющие на производительность и расходы из-за своей сложности и трудоёмкости.
Как мы создали и внедрили цифрового сотрудника для ITSM
Изначально мы разработали цифрового сотрудника в начале 2025 года, используя доступную тогда технологию «управления браузером», которая позволяла ИИ выполнять задачи через интерфейсы приложений в веб-браузере. Наша цель заключалась в автоматизации задач по внедрению и сопровождению ServiceNow и других корпоративных приложений, чтобы у ИТ-команд оставалось больше времени на более важную работу.
Позже мы усовершенствовали решение, чтобы оно использовало протокол контекста модели (MCP) для прямого подключения к API и более быстрого выполнения задач. Мы также создали собственную агентную среду — программное обеспечение, которое координирует работу ИИ и то, как он выполняет работу. Эта среда цифрового сотрудника поддерживает несколько больших языковых моделей (LLM) и сочетает вероятностные рассуждения модели с детерминированным кодом, обеспечивая более последовательную проверку и выполнение задач. Именно благодаря этому сочетанию система, способная отвечать на вопросы о ServiceNow, превращается в инструмент, который стабильно и надёжно выполняет задачи в ServiceNow.
Чтобы цифровой сотрудник был максимально полезным, нам пришлось научить его тому, как устроена наша организация. В каждой организации свои представления о том, каким должна быть хорошая статья в базе знаний, что следует включать в элемент каталога и как нужно называть скрипты. Мы рассматриваем этот процесс как адаптацию нового коллеги: знакомим его с рабочей средой, рассказываем о лучших практиках команды и даём необходимый контекст для качественного выполнения работы. Мы использовали повторно применимые инструкции, в том числе файлы SKILL.md, а также корпоративные знания и память для хранения общих стандартов и индивидуальных предпочтений. Кроме того, мы научили цифрового сотрудника интерпретировать наши документы с требованиями, чтобы он мог выявить недостающую информацию до начала работы.
С точки зрения безопасности и ответственности цифровой сотрудник должен был гарантировать, что разработчики и администраторы ServiceNow сохраняют контроль над ключевыми операциями. Перед выполнением любой операции записи человек проверяет и утверждает её. Цифровой сотрудник безопасно подключается через OAuth с использованием учётной записи пользователя в ServiceNow, соблюдая ролевое управление доступом и разрешения. Наборы обновлений дают нашей команде привычный способ проводить изменения конфигурации через процесс развёртывания или отменять их.
Важна была и наблюдаемость: команда должна понимать, что сделал агент, сработал ли результат и во что это обошлось. Мы используем эти данные наряду с тестированием и проверками на реальных данных ServiceNow, чтобы улучшать работу сотрудника и оценивать его ценность.
Две задачи оказались сложнее, чем мы ожидали: надёжно научить цифрового сотрудника интерпретировать формат требований организации и разобраться в реальных проблемах внедрения, которые оказались более узкими и повторяющимися, чем предполагалось в нашей дорожной карте. Оба урока указывают на одно и то же: начинать нужно с одного рабочего процесса, а не с универсального агента для ITSM. Выбирайте процесс, который повторяется, подчиняется правилам, выполняется в больших объёмах, легко поддаётся оценке и может быть без труда отменён.
Протестировав первую версию, мы обратились к нашей небольшой команде ITSM из четырёх человек и предложили внедрить решение в рабочем экземпляре в рамках пилотного проекта, чтобы выяснить, чем оно может им помочь. Вот чего нам удалось добиться и как.
Сценарий № 1: сокращение затрат на разработку элементов каталога на 80%
Создание одного элемента каталога обычно занимает несколько часов или дней, а в зависимости от сложности может растянуться на 1–2 недели. Большинство команд фиксируют требования к элементам каталога в каком-либо стандартном формате — в Excel, Word или задаче Jira. После сбора требований их передают разработчику, который интерпретирует их, создаёт переменные и поля формы, настраивает рабочий процесс и, возможно, разрабатывает дополнительные скрипты и соглашения об уровне обслуживания (SLA). Такие повторяющиеся задачи требуют высокой внимательности и знания платформы, отнимая у ИТ-команды значительную часть времени и ресурсов.
Наш цифровой сотрудник обладает диалоговыми возможностями LLM, а также понимает специфические для нашей организации форматы требований и лучшие практики, поэтому с ним легко взаимодействовать, задавать вопросы и выполнять задачи. Он также соблюдает правила доступа, поэтому пользователи могут вносить только те изменения, на которые у них уже есть разрешение в платформе ITSM. Если дать задание цифровому сотруднику и загрузить требования в стандартном формате, он создаст элемент каталога примерно за 20 секунд, включая рабочий процесс и связанные с ним скрипты. Команда может сразу просмотреть результат — например, форму запроса, — не выходя из цифрового сотрудника, а после окончательного утверждения перенести его на платформу всего за несколько щелчков мышью.
Возможности цифрового сотрудника по созданию каталогов стали настоящим прорывом для нашей небольшой команды. На этапе сбора требований мы по-прежнему заполняем тот же шаблон, что и раньше, но теперь можем сразу запустить конструктор каталогов и почти мгновенно увидеть результат. Это экономит несколько дней при создании простого элемента каталога и до недели при разработке более сложных рабочих процессов. Кроме того, мы можем вместе с заказчиком проверить результат, внести изменения и гораздо быстрее протестировать идеи, не проходя через долгий цикл согласований и доработок.
Автоматизировав всю дальнейшую разработку элементов каталога и широко применяя цифрового сотрудника в этой области, мы рассчитываем сократить затраты команды на разработку на 80% и высвободить около 25% её ресурсов для более приоритетных задач, связанных с платформой.
Сценарий № 2: от дашбордов — к быстрому выявлению и устранению проблем ITSM
Ещё одна область, где мы внедрили цифрового сотрудника, — анализ тенденций по запросам и инцидентам. Данные платформы ITSM всегда можно проанализировать, чтобы получить нужные сведения. Традиционно для этого приходится создавать отчёты и дашборды, просматривать списки, а иногда и изучать отдельные заявки. В инструменте ITSM можно создать сколько угодно дашбордов, но извлекать из них реальные выводы гораздо сложнее и дольше.
Интерпретация статичных дашбордов и просмотр длинных списков заявок в отчётах уходят в прошлое. Будущее — за возможностью задавать вопросы и быстро получать ответы и выводы от разговорного ИИ.
Например, мы можем попросить цифрового сотрудника проанализировать инциденты и запросы за последние 60 или 90 дней. Он сразу сравнивает текущие объёмы с базовым уровнем, позволяя понять, растёт или снижается активность и где происходят необычные изменения. Кроме того, он использует машинное обучение, чтобы группировать заявки и выявлять ключевые слова, темы и повторяющиеся проблемы, число которых может резко увеличиваться. Поэтому вместо графика заявок по приоритету мы можем сразу увидеть группы заявок, связанных со сбоями резервного копирования, задержками репликации, производительностью или подключением.
Затем мы можем в диалоговом режиме подробнее изучить любую из этих областей и спросить: «Что вызывает эту проблему?» или «На чём нам следует сосредоточиться?» Цифровой сотрудник интерпретирует исходные данные и объясняет, что происходит на самом деле. Дашборд может показать, что число заявок выросло, а цифровой сотрудник — объяснить причину, выявить несколько заявок, которые могут быть связаны с одной и той же проблемой, и предложить дальнейшие действия. Это помогает нам раньше устранять неполадки и направлять ресурсы туда, где они принесут наибольшую пользу.
В рамках этого процесса постоянной проблемой становится нехватка времени у экспертов, которым нужно создавать статьи базы знаний, помогающие сократить число заявок. Анализируя тенденции по заявкам и инцидентам, цифровой сотрудник может выявить пробелы в базе знаний и даже сразу помочь составить статью, обобщив связанные инциденты и другие соответствующие данные.
Анализ, на который раньше уходило несколько часов, теперь можно провести за 10–15 минут общения с цифровым сотрудником. Повторяющиеся анализы также можно запланировать на регулярное выполнение. Мы тратим меньше времени на создание дашбордов и ручную интерпретацию данных и больше — на решение проблем, которые выявляют эти данные.
Сценарий № 3: оптимизация ролей пользователей и перераспределение неиспользуемых премиальных лицензий
Раньше наша команда тратила много времени на создание дашбордов, проверку отчётов о соответствии требованиям и попытки устранить расхождения между нашими внутренними данными и результатами проверок. Процесс был сугубо реактивным. Когда отчёт показывал превышение лимита, команде приходилось выяснять, почему его данные настолько расходились с показателями наших отчётов. Иногда ServiceNow меняет определения ролей, и следить за такими изменениями действительно непросто. Многие организации проводят подробную проверку лишь раз в год — если вообще проводят, — поскольку анализ ролей и активности пользователей на платформе отнимает слишком много времени.
С помощью цифрового сотрудника мы можем изучить роли отдельного пользователя и узнать не только, когда он последний раз входил в систему, но и как именно использует возможности, доступные в рамках премиальных ролей. Например, если у кого-то есть лицензия ITIL, но он не использует функции управления изменениями, инцидентами, знаниями, проблемами, запросами или каталогом услуг, мы можем определить, нужна ли ему эта лицензия, и, возможно, передать её другому сотруднику. Такой же анализ можно провести для всей команды. Вместо того чтобы проверять пользователей по одному, мы можем попросить цифрового сотрудника проанализировать группу и показать, как распределены лицензии, какими правами наделены сотрудники и используют ли они их на самом деле.
Кажется, что кому-нибудь всегда нужна ещё одна лицензия. Без такой прозрачности легко выделить слишком много лицензий и неоправданно увеличить расходы. Теперь мы можем принимать более взвешенные решения о распределении лицензий и избегать ненужного роста затрат.
Традиционно системы ITSM служили системами учёта: они отлично собирали данные, но для их интерпретации и превращения в конкретные действия требовались значительные время и опыт. Цифровой сотрудник открывает возможность создать интеллектуальный уровень, который поможет ИТ-командам делать больше за меньшее время и получать большую отдачу от инвестиций в платформу ITSM.
Эксперименты с разговорным ИИ позволили нашей команде тратить меньше времени на работу с дашбордами, анализ записей и выполнение повторяющихся административных задач и больше — на действия, основанные на данных платформы. В конечном счёте это помогает повысить операционную эффективность и лучше обслуживать внутренних клиентов.
Ричард Мендис — директор по маркетингу и стратегии.
Брайан Кинг — старший инженер по продуктам ИИ в компании Bytemethod.ai.
Добро пожаловать в сообщество VentureBeat!
В рамках нашей программы гостевых публикаций технические специалисты делятся своими знаниями и предлагают независимый, неангажированный подробный анализ ИИ, инфраструктуры данных, кибербезопасности и других передовых технологий, формирующих будущее корпоративного сектора.
Читайте другие материалы нашей программы гостевых публикаций и ознакомьтесь с правилами , если хотите предложить собственную статью!
