Пилот получился. На одном процессе помощник показал результат, все довольны, есть договорённость «расширяем на другие отделы». Проходит три месяца — расширения нет. Пилот продолжает жить сам по себе, иногда о нём вспоминают, но дальше одного участка дело не идёт.
Эта ситуация типична, и причины у неё не технические. Разберём, что именно ломается при переходе от одного процесса к нескольким. Про то, как ИИ-помощник для отдела устроен на практике, — отдельный разбор.
Причина первая: пилот делали под пилот
Первая и главная причина: пилот часто собирают как демонстрацию, а не как часть будущей системы.
Что происходит: результат достигается любой ценой — ручными правками, участием конкретного человека, обходом неудобных случаев. Пока участок один, это работает. При переносе на второй процесс выясняется, что переносить нечего: вся конструкция держалась на том, что её кто-то подправляет руками.
Как выглядит со стороны: «на демо всё летало, а в работе — нет».
Что с этим делать: пилот надо сразу собирать как первый экземпляр системы, а не как исключение из неё. Правила, которые нужны для работы на втором участке, стоит закладывать на первом.
Полезное наблюдение из разборов: в рабочем решении на саму модель приходится примерно треть работы, остальное — обвязка вокруг неё. Именно эта обвязка (очереди, обработка сбоев, повторы, согласованность с системами) и определяет, масштабируется ли решение. Пилот, где обвязки нет, выглядит эффектно и не переносится никуда.
Причина вторая: данные не готовы
Второй по частоте слом. Пилот работал на участке, где данные были в порядке. На следующем участке — хаос.
Что именно ломает:
- разные форматы. В одной системе адрес записан одним способом, в другой — другим. В одной компании внутри одного файла можно встретить несколько разных форматов одного и того же адреса
- дубли и устаревшее. Справочники, которыми давно не занимались, содержат позиции, которых уже нет, и записи, которые противоречат друг другу
- данные есть, но не там. Информация существует, но лежит в файлах, которые никто не ведёт
Что это значит на практике: работа с данными — не подготовительный этап в начале проекта, а постоянная часть работы. И это самый недооценённый объём: часто он больше, чем сама настройка.
Что с этим делать: смотреть на состояние данных до выбора участка. И закладывать время на приведение их в порядок как отдельную работу, а не как «мелочь перед стартом».
Причина третья: нет ответственного
Третья причина выглядит организационной, но именно она чаще всего останавливает всё.
Как это начинается: пилотом занимался конкретный человек — он хотел, он вникал, он настраивал. Проект жил его энергией.
Что происходит дальше: человек переключился на другое. Никто не смотрит, как работает помощник, не уточняет правила, не решает, что делать с нестандартными случаями. Система не деградирует резко — она просто постепенно перестаёт соответствовать реальности, потому что процессы изменились, а правила остались прежними.
Что с этим делать: ответственный должен быть назначен явно, и это не «руководитель проекта внедрения», а человек из бизнеса, который пользуется результатом. Он же и должен иметь возможность менять правила — без программиста.
Причина четвёртая: правила живут у разработчика
Связанная причина, но отдельная.
Если любое изменение — «помощник должен отвечать иначе», «это обращение надо относить к другой категории» — требует обращения к техническому специалисту, система быстро теряет актуальность. Изменения копятся, ждут очереди, а потом признаются неактуальными.
Признак проблемы: в течение недели у вас три раза возникла мысль «надо поправить», и ни разу вы этого не сделали.
Что с этим делать: правила работы помощника (что отвечать, по какой логике, что передавать человеку) должны меняться человеком из бизнеса. Это требование к тому, как устроено решение, и его стоит озвучивать до старта, а не после.
Причина пятая: первый участок выбрали неудачно
Бывает, что пилот сам по себе получился, но переносить его некуда.
Это происходит, когда первый участок выбрали по принципу «здесь проще всего показать эффект», а не «здесь самая сильная боль». Тогда он остаётся изолированной демонстрацией: технически работает, но ни на что не влияет и никуда не ведёт.
Что с этим делать: первый участок должен быть частью потока, а не отдельным островком. Тогда второй шаг очевиден: соседний этап того же процесса, а не «что-нибудь ещё».
Признаки того, что масштабирование состоится
Проверить себя можно по нескольким вопросам ещё на этапе пилота.
- Работает ли пилот без ежедневного вмешательства? Если кто-то подправляет результат руками каждый день — масштабировать нечего.
- Описаны ли правила так, что их прочитает новый человек? Если знание живёт в голове одного сотрудника, оно не переносится.
- Может ли человек из бизнеса изменить правило сам? Если нет — изменения будут копиться.
- Ясны ли данные, которые нужны для второго участка? Если на них никто не смотрел, будут сюрпризы.
- Есть ли ответственный, который останется после пилота? Если проект держится на энтузиазме одного человека, он остановится вместе с ним.
- Является ли пилот частью потока, а не отдельным островком? От этого зависит, куда идти вторым шагом.
Что делать, чтобы масштабировалось
Собирать пилот как первый экземпляр системы. Не демонстрацию, а рабочий участок с правилами, которые можно повторить.
Закладывать работу с данными в план. Не как мелочь перед стартом, а как отдельную задачу со своим временем.
Назначить ответственного. Из бизнеса, а не из проекта внедрения.
Обеспечить смену правил без программиста. Это условие, а не улучшение.
Выбирать участок по боли, а не по простоте. Тогда второй шаг будет очевиден.
Проверять пилот на «переносимость». Задавать себе вопрос: а если завтра то же самое нужно на другом участке — что помешает?
Где остаётся человек
Решения о расширении. Что дальше, в каком порядке, стоит ли вообще — это управленческие решения, а не технические.
Правила. Что считается правильным, как поступать с нестандартным.
Ответственность. За результат перед людьми отвечает человек, не система.
Работа с сопротивлением. Автоматизация меняет характер работы сотрудников, и это то, что нужно проводить руками.
Честно про ограничения
Не всё масштабируется, и это нормально. Некоторые процессы действительно уникальны для конкретного отдела. Вопрос не в том, чтобы перенести всё, а в том, чтобы понимать, что именно переносится.
Работа с данными может занять больше времени, чем ожидалось. И это почти всегда так.
Пилот может показать, что подход не подходит. Тоже полезный результат: вы узнали это на одном участке, а не после внедрения во все отделы.
Эффект от масштабирования не суммируется линейно. Второй участок даётся обычно легче первого, но каждый следующий требует своей работы с данными и своими правилами.
Помощник усиливает тот процесс, в который его поставили. Показать, как это может выглядеть на ваших процессах — до того, как что-то решать.
Как это устроено целиком — внедрение ИИ-агентов: от выбора процесса до запуска.