Как понять, готова ли компания к внедрению ИИ: оценка до старта проекта

Готовность к внедрению искусственного интеллекта почти никогда не определяется наличием денег или интересом руководителя. Я видел компании с бюджетом в десятки миллионов, которые полтора года не могли вывести ни одну модель в работу, и производственные предприятия среднего размера, запустившие прогноз спроса за восемь недель силами двух человек. Разница была не в технологиях и не в подрядчике, а в том, насколько компания понимала собственные процессы и данные до начала проекта. Эта часть статьи посвящена тому, как провести такую диагностику самостоятельно и честно.

Что считается готовностью компании к внедрению ИИ

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

Удобно рассматривать готовность как три слоя, каждый из которых может быть развит независимо от остальных.

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

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

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

Почему готовность определяется не технологиями

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

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

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

Три типичные стартовые ситуации

Прежде чем переходить к чек-листу, определите, в какой из ситуаций находится ваша компания. От этого зависит, какие пункты проверки для вас критичны, а какие можно пока отложить.

1. Запрос пришёл сверху. Руководитель или собственник прочитал отраслевой обзор и поставил задачу разобраться. Главный риск — проект без конкретной бизнес-метрики, который превращается в серию демонстраций.
2. Запрос пришёл снизу. Конкретное подразделение упирается в ручную работу и просит автоматизации. Главный риск — отсутствие поддержки на уровне, где принимаются решения о бюджете и изменении процессов.
3. Запрос пришёл от рынка. Клиенты или партнёры начали требовать скорости, которую невозможно обеспечить текущей численностью. Это самая благоприятная ситуация, потому что экономика проекта считается легко, но и самая рискованная по срокам.

Чек-лист оценки: 7 направлений проверки

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

1. Бизнес-задача и измеримые метрики результата

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

Хорошая формулировка задачи отвечает на четыре вопроса.

• Какой показатель должен измениться и на сколько процентов или рублей.
• Какое значение этот показатель имеет сегодня и как оно измеряется.
• Кто именно изменит своё поведение после внедрения и в какой системе он работает.
• Что произойдёт, если модель ошибётся, и какая цена этой ошибки.

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

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

2. Данные: объём, качество, доступность, хранение

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

Проверяйте по шести параметрам.

• Глубина истории. Для прогноза спроса с учётом сезонности нужно минимум два полных года, лучше три. Для классификации обращений достаточно нескольких тысяч размеченных примеров.
• Наличие целевого признака. Это то, что модель будет предсказывать. Если вы хотите прогнозировать отток, в данных должен быть зафиксирован факт ухода клиента с датой, а не просто отсутствие покупок.
• Полнота заполнения ключевых полей. Поле, заполненное в сорока процентах записей, бесполезно, и это выясняется только выборочной проверкой, а не опросом сотрудников.
• Единство справочников. Один и тот же контрагент или товар в разных системах часто существует под разными идентификаторами, и сведение этих записей обычно занимает больше времени, чем обучение модели.
• Техническая доступность. Можно ли выгрузить данные регулярно и автоматически или каждая выгрузка требует участия единственного человека, который знает структуру базы.
• Фиксация результата. Будет ли система сохранять, какое предсказание было сделано и что произошло на самом деле. Без этого модель невозможно улучшать после запуска.

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

В большинстве проектов, которые я разбирал, подготовка и сверка данных занимала от шестидесяти до восьмидесяти процентов трудозатрат. Обучение модели — редко больше десяти.

3. ИТ-инфраструктура и вычислительные ресурсы

Этот пункт выглядит сугубо техническим, но содержит два управленческих вопроса. Первый касается того, где будут выполняться расчёты, второй — куда попадёт результат.

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

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

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

4. Описанность и стабильность процессов

Модель встраивается в процесс, а не заменяет его. Поэтому процесс должен существовать в описанном виде и быть достаточно стабильным, чтобы решение не устарело раньше, чем будет внедрено.

Признаки процесса, пригодного для автоматизации.

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

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

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

5. Команда, роли и компетенции

Для первого проекта не нужен отдел из десяти специалистов. Нужны четыре роли, причём одна из них незаменима подрядчиком.

1. Владелец задачи со стороны бизнеса. Человек, который отвечает за показатель, который мы собираемся улучшить, и имеет полномочия изменить регламент работы своего подразделения. Это та роль, которую нельзя передать вовне.
2. Знаток данных. Сотрудник, понимающий, как устроены учётные системы, где лежит нужная информация и какие в ней известные искажения. Обычно это аналитик или сопровождающий учётную систему специалист.
3. Технический исполнитель. Тот, кто строит модель и обвязку вокруг неё. Эту роль разумно закрывать подрядчиком на первом проекте.
4. Представитель будущих пользователей. Человек из тех, кто будет ежедневно смотреть на результат. Его участие с первых недель снижает сопротивление при внедрении в разы.

Проверяйте не наличие людей, а наличие их времени. Формально выделенный владелец задачи, у которого нет четырёх-шести часов в неделю на проект, равнозначен отсутствию владельца. Это самая частая причина затягивания сроков, и она почти всегда маскируется под технические сложности.

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

6. Бюджет, сроки и источник финансирования

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

При планировании учитывайте пять статей, из которых обычно помнят только первую.

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

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

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

7. Безопасность данных и регуляторные ограничения

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

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

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

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

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

Уровни зрелости: от ручных процессов до ИИ в продакшене

Оценки по семи направлениям полезны, но они статичны. Чтобы понять, что именно делать дальше, их нужно соотнести с общим уровнем зрелости компании. Зрелость показывает не то, насколько компания технологична, а то, насколько управляемы её данные и решения. Переход между уровнями занимает от трёх месяцев до двух лет, и перескочить через уровень не получается почти никогда.

Ниже пять уровней, которые я использую при диагностике. Определите свой по худшему из совпадающих признаков, а не по лучшему.

Уровень	Состояние данных и процессов	Что реально внедрить сейчас
Нулевой. Ручная работа	Учёт ведётся в таблицах и переписке, единой системы нет, история решений не сохраняется	Ничего из области моделей. Нужен базовый учёт и единый справочник
Первый. Учёт есть, аналитики нет	Работает учётная система, данные накапливаются, но отчёты собираются вручную под каждый запрос	Готовые языковые модели по подписке для текстовых задач, не требующих ваших исторических данных
Второй. Регулярная отчётность	Есть согласованные показатели, отчёты обновляются автоматически, расхождения между системами известны и объяснимы	Первый пилот на одной задаче с измеримой метрикой. Классификация, прогноз, приоритизация
Третий. Модель в работе	Одно или два решения встроены в ежедневные процессы, результат фиксируется, есть ответственный за качество	Масштабирование на смежные задачи, автоматизация переобучения, снижение зависимости от подрядчика
Четвёртый. Системная практика	Есть внутренняя команда, повторяемый порядок вывода решений в работу, учёт экономического эффекта по каждому	Сложные сценарии с несколькими моделями, оптимизация, работа с нестандартными данными

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

Между красивым отчётом и пригодными для обучения данными лежит примерно столько же работы, сколько между складским учётом и красивым отчётом.

Как определить свой уровень за один день

Долгий аудит не нужен. Достаточно проверить четыре вещи и сделать это на конкретном примере, а не в обсуждении.

1. Попросите назвать текущее значение показателя, который вы хотите улучшить, и его значение год назад. Если цифры собираются дольше двух дней, вы на первом уровне или ниже.
2. Попросите выгрузить историю по одной сущности за два года с ключевыми полями. Если выгрузка требует участия нескольких подразделений или вызывает спор о том, какая система правильная, вы на первом уровне.
3. Проверьте, сохраняется ли в системе дата и автор изменения статуса. Отсутствие истории изменений почти всегда означает, что целевой признак придётся восстанавливать косвенно, и это снижает достижимое качество.
4. Спросите, кто отвечает за корректность справочника контрагентов или номенклатуры. Если ответственного нет, задачи на уровне рекомендаций и сопоставлений пока недоступны.

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

Как трактовать результат проверки

Сложите оценки по семи направлениям и посмотрите на распределение, а не только на сумму. Максимум составляет четырнадцать баллов. Но суммарный результат обманчив, потому что два направления работают как условия отсечения, а не как слагаемые.

• Бизнес-задача и метрики. Ноль по этому направлению обнуляет проект целиком, какими бы хорошими ни были остальные оценки. Без понимания, какое решение меняется, внедрять нечего.
• Безопасность и регуляторные ограничения. Жёсткий запрет здесь не отменяет проект, но меняет его архитектуру и бюджет, иногда в два-три раза.
• Данные. Единица по этому направлению допустима, потому что подготовка данных может стать первым этапом работы. Ноль означает, что сначала нужен отдельный проект по учёту.
• Инфраструктура, бюджет, инфраструктурные доработки. Эти направления компенсируются деньгами и временем, поэтому низкие оценки здесь не критичны, а просто дороги.
• Процессы и команда. Низкие оценки здесь самые опасные, потому что они не решаются внешними ресурсами и требуют управленческих решений.

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

Признаки, что компания готова

Эти признаки проявляются в поведении, а не в заявлениях. Их удобно проверять в разговоре, потому что готовая компания отвечает на такие вопросы без подготовки.

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

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

Признаки, что внедрять ещё рано

Признаки неготовности почти всегда звучат как разумные вещи, поэтому их пропускают. Разберу те, которые встречаются чаще всего, с объяснением, почему именно они останавливают проект.

• Задача формулируется через технологию, а не через результат. Фраза о внедрении искусственного интеллекта в продажах не содержит ни одного проверяемого критерия, и проект будет закрыт при первой смене приоритетов.
• Нет согласия о цифрах. Два подразделения называют разную выручку по одному направлению, и спор не разрешается за один день. Модель унаследует это расхождение и усилит его.
• Владелец задачи не может выделить время. Формальное назначение без часов в календаре означает, что решения будут приниматься с задержкой в недели.
• Данные существуют только в выгрузках, которые делает один человек. Уход или отпуск этого человека останавливает проект, а после запуска останавливает работу решения.
• Процесс активно перестраивается. Параллельная реорганизация почти гарантированно делает результат неактуальным к моменту готовности.
• Ожидается точность выше девяноста пяти процентов на задаче, где люди ошибаются в двадцати процентах случаев. Это говорит о непонимании природы вероятностных решений и приведёт к отказу от рабочего инструмента.
• Нет бюджета на сопровождение. Решение будет запущено и через год перестанет использоваться без формального закрытия.
• Инициатива не имеет поддержки на уровне, где утверждаются изменения регламентов.

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

Неготовность редко выглядит как отсутствие ресурсов. Чаще она выглядит как отсутствие человека, который готов отвечать за изменение показателя своим именем.

Что делать с промежуточным результатом

Самая распространённая оценка попадает в середину диапазона, и именно здесь принимаются худшие решения. Компания видит восемь баллов из четырнадцати и выбирает одну из двух крайностей. Либо откладывает проект до полной готовности, которая не наступает никогда, либо запускает полномасштабное внедрение, игнорируя пробелы.

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

Как выбрать первую задачу для ИИ

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

Прогоняйте каждую задачу-кандидата через шесть фильтров, в указанном порядке.

1. Частота. Решение принимается не реже нескольких десятков раз в месяц. Редкие решения не дают ни экономии, ни обратной связи для улучшения.
2. Измеримость. Эффект считается в деньгах или в часах по формуле, которую принимает финансовая служба.
3. Наличие истории. Данные за нужный период уже накоплены, их не нужно начинать собирать с нуля.
4. Цена ошибки. Неверное предсказание приводит к потере времени или небольших денег, а не к репутационному или юридическому риску.
5. Границы изменений. Внедрение затрагивает одно подразделение и одну-две системы. Задачи, требующие согласования между тремя службами, плохо подходят для первого раза.
6. Заинтересованный владелец. Есть руководитель, который получит личную выгоду от улучшения показателя.

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

Задачи, подходящие для старта

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

• Классификация и маршрутизация обращений. Входящие письма и заявки распределяются по категориям и ответственным. История переписки обычно есть, разметку можно взять из прошлых решений, эффект измеряется временем первой реакции.
• Извлечение данных из документов. Накладные, счета, акты, спецификации переводятся в структурированный вид. Эффект считается прямо в часах работы операторов ввода.
• Прогноз спроса по товарным группам. Требует двух-трёх лет истории продаж, даёт экономию на складских запасах и снижение упущенных продаж.
• Приоритизация обращений в продажах. Модель упорядочивает список, менеджер звонит сверху вниз. Цена ошибки низкая, эффект проявляется за один цикл сделки.
• Прогноз оттока клиентов в компаниях с подписочной или регулярной моделью. Работает при условии, что факт ухода фиксируется датой.
• Подготовка черновиков типовых текстов. Описания товаров, ответы на повторяющиеся вопросы, выдержки из регламентов. Контроль остаётся за человеком, риск минимален.
• Поиск по внутренним документам с ответами на вопросы сотрудников. Снимает нагрузку на экспертов, при этом не требует исторических данных о решениях.
• Контроль качества на производстве по изображениям. Требует размеченной выборки дефектов, но даёт быстро измеримый эффект на браке.

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

Задачи, с которых начинать не стоит

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

• Динамическое ценообразование. Задача сильно связана с стратегией, затрагивает несколько подразделений и требует согласованной позиции по рискам. Срок согласования обычно превышает срок разработки.
• Полностью автономная поддержка клиентов без участия оператора. Цена ошибки высокая и видна снаружи, а обработка исключений требует больше работы, чем основной сценарий.
• Оценка сотрудников и прогноз их результативности. Чувствительная тема с кадровыми и юридическими последствиями, сопротивление гарантировано.
• Прогноз на горизонт больше года в нестабильных категориях. Качество будет низким по объективным причинам, и это будет воспринято как неудача технологии.
• Единая платформа данных как первый шаг. Правильное решение в долгой перспективе, но проект без видимого результата в течение года не выживает политически.
• Задачи без накопленной истории, где сбор данных нужно начинать с нуля. Между решением собирать данные и возможностью обучить модель проходит от года.
• Копирование кейса конкурента без проверки своих условий. Одинаковая задача при разной структуре учёта требует совершенно разных трудозатрат.

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

Пилот как проверка готовности на практике

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

Правильно построенный пилот отвечает не на вопрос о том, работает ли технология. Он отвечает на четыре вопроса о самой компании.

• Можно ли получить нужные данные регулярно и без ручного участия.
• Достаточно ли в них сигнала, чтобы качество предсказаний превысило текущий ручной способ.
• Станут ли сотрудники использовать результат, если он появится в их рабочем окне.
• Способна ли компания принимать решения по проекту в темпе, который не убивает сроки.

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

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

Метрики успеха пилота

Метрики нужно разделить на три группы и смотреть на все три. Перекос в сторону технических показателей приводит к ситуации, когда модель хорошая, а пользы нет.

Группа	Что измеряем	Ориентир для решения о продолжении
Техническая	Точность предсказаний в сравнении с текущим ручным способом или простым правилом	Превосходство над текущим способом не менее чем на четверть по выбранной метрике
Процессная	Доля случаев, где сотрудник воспользовался результатом, время на одну операцию	Использование не менее половины случаев без административного принуждения
Экономическая	Изменение целевого показателя на пилотной выборке в деньгах или часах	Расчётный эффект на полном масштабе окупает вложения за год

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

Пилот, завершившийся выводом о нецелесообразности, — это успешный пилот. Его стоимость в десять раз ниже стоимости того же вывода, сделанного через полтора года.

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

Расчёт затрат и ожидаемого эффекта

Расчёт экономики делается до пилота, а не после. Причина простая. Если на салфетке эффект не складывается, пилот тоже не поможет, потому что он даст в лучшем случае ту же цифру с меньшей погрешностью. Грубая оценка с точностью плюс-минус пятьдесят процентов занимает несколько часов и отсеивает значительную часть идей, которые выглядят привлекательно, но не окупаются.

Считайте по четырём блокам, причём первый блок почти всегда недооценивают в два-три раза.

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

Эффект считайте от частоты операции, а не от общего размера показателя. Это главное правило, которое удерживает расчёт в реальности. Формула складывается из количества операций в месяц, экономии на одной операции и доли случаев, где модель действительно применима.

Параметр	Как получить значение	Типичная ошибка
Количество операций	Выгрузка из системы за последние двенадцать месяцев, среднее по месяцу	Берут прогнозный рост вместо фактического объёма
Экономия на операции	Замер времени на выборке из двадцати-тридцати случаев с секундомером	Используют оценку сотрудника по памяти, завышенную вдвое
Доля применимости	Результат пилота или консервативная оценка в шестьдесят процентов	Считают, что модель покроет сто процентов случаев
Стоимость часа	Полная стоимость сотрудника с налогами и накладными расходами	Берут оклад без начислений, занижая эффект
Цена ошибки	Средние потери на одном неверном решении, умноженные на ожидаемую долю ошибок	Не учитывают вовсе, из-за чего эффект завышается

Отдельная статья эффекта, которую стоит считать осторожно, — высвобождение людей. Если по итогам внедрения вы не планируете сокращать численность или перераспределять задачи, экономия часов остаётся бумажной. Финансовая служба это заметит, и доверие к расчётам по следующим проектам упадёт. Честнее указать высвобожденное время как ресурс для роста объёма без расширения штата и зафиксировать, какой именно объём будет принят.

Как выглядит реалистичный расчёт

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

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

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

Если проект окупается только за счёт сокращения часов, он почти всегда окупается на бумаге. Устойчивые проекты держатся на показателях, которые видит клиент.

Горизонт расчёта и ставка осторожности

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

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

Частые ошибки при оценке готовности

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

Ошибки в оценке данных

• Объём принимают за качество. Пять лет истории с незаполненными ключевыми полями хуже восемнадцати месяцев полных данных. Проверка делается только выборочным просмотром записей, опрос сотрудников даёт завышенную картину.
• Не проверяют, что было известно на момент решения. Данные обогащаются постфактум, и модель, обученная на такой выборке, показывает блестящее качество на тестах и проваливается в работе. Это самая коварная техническая ошибка, и она почти не видна без специальной проверки.
• Считают наличие дашбордов признаком пригодных данных. Агрегированная отчётность и детальная история событий существуют независимо друг от друга.
• Игнорируют разрыв в данных из-за смены системы. Переход на новую учётную систему два года назад часто означает, что сопоставимая история начинается с этой даты, а не раньше.
• Не учитывают аномальные периоды. Данные за месяцы с нетипичным спросом или организационной перестройкой искажают обучение, и их нужно либо исключить, либо отметить.

Ошибки в оценке организации

• Путают заинтересованность с готовностью отвечать. Руководитель может искренне поддерживать проект на совещаниях и ни разу не принять решение, которое требует изменения регламента в его подразделении.
• Считают, что внедрение сделает подрядчик. Подрядчик строит решение. Встроить его в ежедневную работу людей может только внутренний руководитель, и его участие нельзя купить.
• Не проверяют наличие времени у ключевых участников. Назначение без выделенных часов в календаре — главная причина срыва сроков, которую потом списывают на технические сложности.
• Оценивают готовность в кабинете руководителя. Полную картину даёт разговор с тем, кто выполняет работу руками, и его оценка обычно сильно отличается от управленческой.
• Забывают про того, кто будет сопровождать решение через год. Проект принимается без ответа на этот вопрос, и через год решение тихо выходит из употребления.

Ошибки в постановке и ожиданиях

• Формулируют задачу через технологию. Запрос на внедрение искусственного интеллекта в отделе продаж не содержит критериев проверки, поэтому проект невозможно ни завершить, ни защитить.
• Требуют точности, недостижимой по природе задачи. Если люди ошибаются в каждом пятом случае, ожидать от модели девяноста восьми процентов бессмысленно. Правильный ориентир — текущее качество процесса, а не абстрактный идеал.
• Выбирают самую заметную задачу вместо самой проверяемой. Первый проект должен дать результат, а не впечатление. Заметные проекты обычно затрагивают несколько подразделений и тонут в согласованиях.
• Считают пилот обязательством продолжать. Отсутствие заранее описанного сценария остановки превращает отрицательный результат в чью-то личную неудачу, после которой тема закрывается на годы.
• Не фиксируют базовый уровень показателя до старта. Через два месяца спор об эффекте становится неразрешимым, и проект закрывают из-за невозможности доказать пользу.
• Берут кейс конкурента как ориентир по срокам. Публичные истории описывают проекты третьего и четвёртого уровня зрелости, умалчивая о подготовке учёта, которая им предшествовала.

Ошибки в расчётах и сроках

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

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

План подготовки, если компания не готова

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

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

Если просадка в данных

Срок от трёх до шести месяцев. Работа делится на последовательные шаги, и начинать нужно с сужения области, а не с общего наведения порядка.

1. Выберите одну сущность, связанную с будущей задачей. Контрагенты, номенклатура, обращения, заказы. Не берите все сразу.
2. Назначьте ответственного за её справочник с правом отклонять некорректные записи. Без полномочий роль не работает.
3. Проведите разовую чистку дублей и сведение идентификаторов между системами. Зафиксируйте правила, по которым чистка велась.
4. Добавьте в учёт фиксацию того, чего не хватает для задачи. Причина отказа, фактическая дата, автор изменения статуса, история цены.
5. Настройте регулярную автоматическую выгрузку, которая не зависит от конкретного человека.
6. Через три месяца проверьте полноту заполнения новых полей. Если она ниже восьмидесяти процентов, проблема в процессе ввода, а не в системе.

Важный момент. Новые поля начинают накапливать историю с момента включения, поэтому запускать их нужно как можно раньше, даже если проект отложен. Три месяца ожидания означают три месяца потерянных данных.

Если просадка в процессах

Срок от двух до четырёх месяцев. Задача не в написании толстого регламента, а в описании точек решения.

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

Если просадка в команде и полномочиях

Срок от одного до двух месяцев, но это самый сложный сценарий, потому что он требует управленческих решений, а не работы.

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

Если просадка в регуляторных ограничениях

Срок непредсказуем и зависит от внутренних процедур, поэтому начинать нужно сразу и параллельно всему остальному.

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

Что делать параллельно подготовке

Подготовка не должна быть периодом ожидания. Пока закрываются пробелы, есть смысл набирать опыт на задачах, которым не нужна ваша историческая база. Обработка документов, черновики типовых текстов, поиск по внутренним регламентам работают на готовых моделях и дают результат за несколько недель.

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

Порядок действий на следующие сто дней для компании, которая только начинает, выглядит компактно.

1. Первые две недели. Прогон чек-листа по семи направлениям с тремя независимыми мнениями, определение уровня зрелости.
2. Третья и четвёртая недели. Выбор двух-трёх задач-кандидатов, прогон через шесть фильтров, грубый расчёт экономики на салфетке.
3. Второй месяц. Закрытие критичных пробелов по худшему направлению, включение фиксации недостающих данных, назначение владельца задачи и фиксация его времени.
4. Третий месяц. Запуск пилота на одной задаче с записанным базовым уровнем показателя и заранее описанными критериями продолжения и остановки.
5. Конец третьего месяца. Решение по трём группам метрик, а не по впечатлению от демонстрации.

Готовность не является состоянием, которое однажды наступает. Это набор привычек работы с данными и решениями, который формируется постепенно и проверяется каждым следующим проектом. Компании, которые начинают с честной диагностики и небольшой задачи, через два года оказываются заметно впереди тех, кто ждал полной готовности или сразу брался за масштабное внедрение.

Внедрение искусственного интеллекта начинается не с выбора технологии, а с ответа на вопрос, какое решение в вашей компании сегодня принимается хуже, чем могло бы, и кто готов отвечать за то, чтобы это изменилось.