Стратегия — это отказ от лишнего, а не список технологий

Приоритизация начинается с двух чисел на каждую инициативу: ожидаемый эффект и стоимость реализации вместе с эксплуатацией. Эффект считается консервативно — через объём операций и стоимость единицы работы, а не через процент «улучшения эффективности». Если инициатива обещает «рост производительности на 30%», её нужно разложить на конкретику: какие операции, сколько их в месяц, сколько времени уходит сейчас.

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

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

Данные — главный ограничитель AI-проектов, и проверять их надо до включения инициативы в план, а не после. Минимальный набор вопросов выглядит так. Есть ли история за достаточный период и полна ли она: если система начала писать нужные события полгода назад, прогноз на сезонность построить не получится. Есть ли целевая переменная: для задач прогноза нужно знать, что произошло в прошлом, а для обучения с учителем — иметь разметку.

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

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

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

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

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