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

Провал редко про технологию

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

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

Почему производственные данные — отдельная история

У производственного бизнеса есть специфика, которая делает провал вероятнее, если её не учесть на этапе оценки задачи, а не после запуска проекта.

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

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

Как оргструктура убивает проект тише, чем технология

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

• Нет владельца проекта

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

• Решение навязано сверху

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

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

Что стоит проверить до старта, а не после

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

• ✓

  Есть ли у проекта конкретный владелец

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

• ✓

  Достаточно ли данных для решаемой задачи

  И проверялись ли они на противоречия и пропуски, а не только на факт существования.

• ✓

  Участвовали ли в обсуждении будущие пользователи

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

• ✓

  Понятно ли, что изменится в привычном процессе

  Если внедрение пройдёт успешно — не только технически, но и в действиях конкретных людей.

• ✓

  Есть ли план на случай, если решением никто не воспользуется

  Или ставка сделана только на успех.

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

Что в итоге

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