AI-трансформация компании не начинается с закупки ассистентов и подсчёта токенов. CEO Precisely Валид Абу-Хадба сформулировал четыре управленческих правила: начинать с бизнес-цели, упрощать процесс до автоматизации, пересобирать работу людей и измерять итог для бизнеса. Для российских IT-команд это полезное напоминание: генерация кода в четыре раза быстрее не даст четырёхкратного эффекта, если изменения неделями стоят в очереди на ревью, согласование и релиз.
Об этом сообщает The New Stack в авторской колонке Абу-Хадбы, опубликованной 15 октября. Precisely поставляет ПО, данные и консалтинг в области целостности данных; по информации из профиля автора, услугами компании пользуются более 12 тысяч организаций, включая 95 компаний из Fortune 100. Сам текст при этом не рассказывает о новом продукте или методике внедрения: это взгляд руководителя на то, где AI-трансформация компании чаще всего буксует — и, что характерно, проблема обычно не в модели.
Первое правило — сформулировать бизнес-результат до выбора инструмента. Целью могут быть рост, более быстрый вывод идей на рынок, улучшение продукта, отношения с клиентами или маржинальность. Формула «давайте внедрим ИИ» для этого не годится: она описывает средство, но не направление. Когда цель не названа, организация получает коллекцию чат-ботов, агентов и пилотов, а вместе с ней — ещё один слой сложности. Руководителю и владельцу продукта придётся прямо ответить, что команда начнёт делать, что улучшит и от какой работы откажется.
Абу-Хадба предлагает считать ИИ не стратегией, а частью операционной модели. Стратегия отвечает, куда идёт бизнес и зачем; ИИ может изменить скорость и способ движения. Для CIO это важное различие: дорожную карту стоит строить не вокруг перечня моделей, а вокруг конкретных узких мест. Например, у разработки может быть задача сократить время от гипотезы до работающей функции, у поддержки — повысить качество решения обращений, у аналитики — ускорить получение проверяемых выводов. Уже после этого можно решать, нужен ли RAG, агент, классическая автоматизация или вообще пересмотр процесса без ИИ.
Второе правило звучит почти обидно для любителей красивых демо: сначала упростить, потом ускорять. Автоматизация бесполезного процесса лишь быстрее производит бесполезную работу. Если добавить ИИ к одному этапу, но оставить прежние лишние согласования, встречи, передачи между командами и точки принятия решений, ограничение просто переедет дальше по цепочке. Автор приводит пример разработки: инженер может генерировать код в четыре раза быстрее, но ценность не вырастет вчетверо, если код по-прежнему ждёт в тех же очередях и проходит через те же передачи.
Отсюда практическая последовательность: убрать действия без ценности, упростить оставшиеся, а затем применять ИИ для ускорения. Это хорошая проверка для любой инициативы: до запуска помощника стоит нарисовать путь задачи целиком — от постановки до результата у пользователя — и найти реальное ограничение. Команде разработки, например, важнее не число принятых подсказок, а время цикла, частота поставки, доля доработок и устойчивость сервиса. Иначе AI-инструмент станет быстрым конвейером, который упирается в старый ручной турникет.
Третье правило касается людей. Доступ к ИИ и метрика использования сами по себе не меняют организацию. В Precisely за десятинедельную летнюю стажировку автор наблюдал, как практическая работа с ИИ меняла отношение стажёров к собственным возможностям: они быстрее двигались, глубже изучали задачи и увереннее брались за них. Это не доказательство универсального эффекта и не замена измерениям, но показательный сигнал: новые инструменты меняют не только скорость исполнения, но и границы задач, которые сотрудник готов взять на себя.
По мере того как ИИ забирает часть рутинного исполнения, людям остаются постановка направления, проверка результата, сложное решение проблем, работа с клиентом и профессиональное суждение. Значит, нужно пересматривать роли и процессы: где именно в них допустим ИИ, что он делает самостоятельно, на каком шаге обязателен человек и кто отвечает за ошибочный результат. Для HR это также вопрос развития навыков: скорость освоения роли и вклад начинающих специалистов могут меняться, но требования к проверке, контексту и ответственности никуда не исчезают.
Четвёртое правило — не путать активность с эффектом. Число пользователей, развёрнутых агентов и обработанных токенов показывает, что инструментом пользуются, но не доказывает пользу. Автор сравнивает ИИ с электронной почтой и таблицами: бизнес обычно оценивает не количество отправленных писем или созданных документов, а результат работы. Производительность должна превращаться в высвободившуюся мощность — более быстрые релизы, больше экспериментов, лучшее клиентское обслуживание, а затем в измеримые показатели бизнеса.
Самая неудобная часть этой логики — отказ смотреть на ИИ только как на механизм сокращения штата. Абу-Хадба считает, что краткосрочное снижение затрат не равно долгосрочной ценности; более сильный сценарий — расширить возможности уже имеющейся команды. Главный вопрос для любой AI-трансформации компании поэтому не «сколько агентов мы запустили?», а «что бизнес теперь способен сделать такого, чего не мог раньше?». Полный текст с позицией автора доступен у .