Представим крупную компанию, в которой одновременно работают два ИИ-агента. Первый экономит сотрудникам около 20 часов в неделю — это примерно 0,5 FTE, но для его работы требуется значительная часть доступных вычислительных мощностей. Второй высвобождает уже 4 FTE, однако оставшихся ресурсов ему не хватает: обработка каждого запроса занимает полчаса, пользователи недовольны скоростью и постепенно возвращаются к прежнему порядку работы.
Формально оба внедрения успешны: заданные функции выполняются, трудозатраты сокращаются, хотя общая инфраструктура используется нерационально. Менее полезный агент получает значительную долю мощности, а инструмент с большей отдачей теряет пользователей из-за задержек.
Пока таких внедрений два-три, распределение ресурсов можно корректировать вручную. Когда подразделения запускают десятки ассистентов, чат-ботов и аналитических сервисов, уже недостаточно выяснить, окупается ли каждый из них сам по себе. Приходится определять, чему отдать приоритет, что доработать, что масштабировать, — то есть управлять не отдельными решениями, а общим портфелем ИИ-проектов.
Окупаемость не делает проект приоритетным
Обычно пилот отвечает на узкий вопрос: помогает ли технология ускорить конкретную операцию или сократить трудозатраты. ROI показывает, оправдывает ли достигнутый результат расходы, но не учитывает альтернативу: возможно, те же вычислительные мощности, бюджет и время специалистов принесут больше пользы в другом сценарии.
Поэтому положительный ROI еще не означает, что проект должен первым получить ресурсы. При сопоставимых затратах преимущество может оказаться у инструмента, который экономит больше рабочего времени, чаще используется или поддерживает более критичный для бизнеса процесс.
Как сравнивать проекты
Юридический ассистент, классификатор обращений и помощник разработчика приносят пользу в разных процессах и по-разному нагружают инфраструктуру. Чтобы выбрать между ними, необходимо оценить их сразу по нескольким параметрам.
Бизнес-эффект. Это может быть сокращение трудозатрат, рост числа обработанных обращений без расширения штата, уменьшение срока выполнения задачи или количества ошибок. Все исходные показатели фиксируются до внедрения: если заранее неизвестно, например, сколько времени занимала операция и во сколько обходилась ошибка, результаты пилота будет не с чем сравнить.
Объем использования. Сервис может хорошо справляться с задачей, но запускаться, допустим, всего десять раз в месяц. Даже существенное сокращение трудозатрат при каждом запуске не всегда в целом оправдывает расходы на разработку, интеграцию и сопровождение. Чем чаще инструментом пользуются, тем меньшая доля постоянных издержек приходится на одно обращение.
Полная стоимость эксплуатации. Помимо серверных мощностей или токенов, учитывают подготовку и хранение данных, интеграции, информационную безопасность, контроль качества, мониторинг, доработку и поддержку. Если часть расходов остается в общем бюджете ИТ-подразделения, бизнес-заказчик видит только часть фактических затрат.
Требования к скорости и надежности. Полчаса ожидания допустимы при подготовке еженедельного аналитического отчета, но не во время разговора сотрудника с клиентом. Значение имеют не только объем потребления, но и последствия задержки или остановки рабочих операций.
Потенциал масштабирования. Один инструмент можно распространить на всю компанию почти без изменений, другой при подключении каждого подразделения потребует отдельной настройки, интеграции и базы знаний. Условно, это один агент, но с точки зрения затрат — несколько самостоятельных внедрений.
Бизнес отвечает за эффект, ИТ — за общие ресурсы
ИТ-подразделение не может самостоятельно определить, каким ИИ-проектам отдать приоритет. ИТ, безусловно, видит загрузку серверов, стоимость инфраструктуры и очередь запросов, но не всегда может оценить последствия задержки для бизнеса. Бизнес-заказчик, наоборот, понимает пользу своего сценария,но может не знать, во сколько тот обходится всей организации. Поэтому ответственность приходится разделять: владелец процесса задает целевую метрику и подтверждает полученный результат; ИТ-специалисты рассчитывают стоимость запусков, отслеживают загрузку серверов, применяемые модели и качество работы; команда информационной безопасности определяет, к каким данным может обращаться система и где их следует обрабатывать
Все это можно фиксировать в едином реестре с указанием владельцев, затрат, метрик и технических требований — вовсе необязательно создавать еще один комитет, который будет раз в месяц обсуждать таблицу с агентами. Но без общей картины каждое подразделение продолжит доказывать ценность собственной разработки, а обоснованно расставить приоритеты не сможет никто.
Поиск перспективных сценариев и ответственность за результат остаются у функциональных подразделений. Централизованного управления требуют общая инфраструктура, доступ к данным, мониторинг, учет расходов и условия перехода от пилота к промышленной эксплуатации.
Наращивать мощности стоит только после оптимизации нагрузки
Выделять каждому проекту фиксированную квоту удобно только на старте. Со временем может выясниться, что одни агенты не используют зарезервированные мощности, а другим их постоянно не хватает. Поэтому при распределении стоит учитывать характер нагрузки: критичным приложениям предоставить гарантированный объем, фоновые аналитические задачи перенести на менее загруженные часы, а для типовых действий выбрать более компактные модели.
Перед закупкой дополнительных серверов нужно проверить и способ автоматизации. Если агент выполняет устойчивую последовательность действий со структурированными данными, дешевле может оказаться API, программный робот или функция уже используемой корпоративной системы. Генеративный ИИ оправдан там, где требуется обрабатывать неструктурированную информацию, учитывать контекст и работать с вариативными формулировками.
Врезка: Дополнительные серверы оправданны, если после оптимизации нагрузки значимым для бизнеса системам по-прежнему не хватает ресурсов. В противном случае вместе с инфраструктурой компания масштабирует неэффективные решения.
Технический успех еще не повод для масштабирования
Условия промышленного запуска нужно определить до начала пилота. После тестирования компания проверяет достигнутые результаты и выясняет, можно ли исправить экономику точечной доработкой или выбором другой технологии.
Иногда пилот показывает, что система справляется с задачей, но использовать ее будут слишком редко или тот же процесс выгоднее автоматизировать другим способом. В таком случае от промышленного внедрения разумно отказаться. Пилот все равно выполнил свою задачу: компания проверила гипотезу до масштабных инвестиций. Высвободившиеся вычислительные мощности и время команды можно направить на другой проект с большей отдачей для бизнеса.
Источник: Сергей Азаров, руководитель направления «Цифровая трансформация» в департаменте бизнес-решений «Софтлайн Решения» (ГК Softline); Кирилл Александров, руководитель направления комплексных решений «Софтлайн Решения» (ГК Softline)
