Большинство разговоров о внедрении ИИ начинаются слишком рано. Компания ещё не понимает, какой именно процесс хочет улучшить, но уже обсуждает модели, стоимость запросов, локальное размещение и архитектуру будущих агентов. В итоге технология появляется раньше задачи, а потом команда пытается придумать, куда бы её пристроить.
Гораздо надёжнее идти в обратную сторону. Сначала понять, как компания работает сейчас, где люди тратят время, какие данные переходят между системами, где появляются дубли, кто вручную переносит одно и то же из почты в Excel, из Excel в CRM, из CRM в 1С. И только после этого обсуждать, есть ли здесь место для ИИ.
Именно поэтому хорошее внедрение почти всегда начинается с обследования.
Наблюдать за реальной работой полезнее, чем собирать общие пожелания
Если просто спросить сотрудников, где им нужен ИИ, ответы будут слишком абстрактными. Кто-то попросит умного помощника, кто-то — чат-бота, кто-то — автоматизацию «всего рутинного». Но такие формулировки мало помогают. Нужно видеть не пожелания, а саму работу.
Как сотрудник разбирает входящую почту. Сколько времени занимает перенос данных в 1С. Как готовится отчёт. Сколько раз одна и та же информация переписывается между системами. Где возникают ожидания, согласования и ручные проверки.
Именно на этом этапе важны наблюдение, разговоры и хронометраж. Не для тотального контроля людей, а для понимания процесса.
Практика показывает, что в небольших и средних компаниях болевые точки выглядят очень приземлённо. Один сотрудник вручную заносит заказы в 1С. Другой сначала пишет что-то в CRM, а потом ту же информацию переносит ещё куда-то. Третий каждый месяц собирает отчёты в Excel. Четвёртый весь день разбирает письма от клиентов и сортирует их вручную. Это и есть настоящие кандидаты на изменение.
На этапе обследования важны факты, а не обещания
Обследование полезно тем, что возвращает разговор из области идей в область фактов. Вместо «кажется, здесь много ручной работы» появляются конкретные наблюдения: процесс возникает 40 раз в день, в нём участвуют три человека, на одну операцию уходит в среднем 12 минут, данные дублируются между двумя системами, ошибки исправляются вручную, а согласование занимает ещё два часа ожидания.
Только после появления таких данных можно всерьёз обсуждать экономику автоматизации. Иначе компания рискует потратить силы на задачу, которая выглядит эффектно, но почти не влияет на бизнес.
Здесь особенно полезно фиксировать несколько видов информации. Во-первых, частоту процесса. Во-вторых, время на один проход. В-третьих, участников процесса. В-четвёртых, стоимость ошибки. И, наконец, качество исходных данных: документы, письма, таблицы, справочники, внутренние статусы.
Когда эти факты собраны, становится видно, где нужна просто нормальная интеграция, а где есть настоящий участок неопределённости, для которого уже имеет смысл привлекать ИИ.
Не трогайте системы раньше времени
Одна из лучших практик на старте — работать в режиме «только чтение». Иными словами, на этапе обследования команда ещё ничего не автоматизирует и ничего не меняет. Она смотрит, как данные живут в 1С, CRM, почте, таблицах и внутренних сервисах. Сопоставляет пути документов, сверяет статусы, разговаривает с теми, кто реально делает работу руками.
Такой подход дисциплинирует. Он защищает от соблазна немедленно начать писать сценарии на основании поверхностного представления о процессе. Очень часто именно в этот момент выясняется, что реальная схема работы не совпадает с той, как её описывают на совещании.
Например, документ может формально попадать в один ящик, но фактически дополнительно пересылаться между сотрудниками в мессенджере. Или заявка может считаться закрытой в CRM, хотя бухгалтерия об этом узнаёт только после ручной таблицы. Или сотрудник держит в голове неформальное правило, без которого формально корректный процесс на самом деле не работает.
Если начать автоматизировать раньше времени, система закрепит неясности и хаос вместо того, чтобы их прояснить.
Хороший путь: обследование → пилот → отдел → масштабирование
Одна из самых жизнеспособных схем внедрения ИИ выглядит очень просто. Сначала проводится ограниченное обследование. Затем выбирается один узкий пилотный процесс. Если он даёт результат, решение внедряется в одном отделе. И только после этого обсуждается более широкая инфраструктура, сопровождение, регламенты и обучение.
Такая последовательность кажется менее эффектной, чем обещание быстро «внедрить ИИ во всю компанию», но именно она снижает риски. Пилот нужен не ради галочки, а чтобы проверить три вещи. Первая — действительно ли процесс выбран правильно. Вторая — даёт ли новое решение измеримую пользу. Третья — выдерживает ли оно реальные данные и реальные исключения.
Переход к одному отделу после пилота тоже неслучаен. Даже если решение хорошо отработало на ограниченном объёме, в более широкой эксплуатации появляются новые роли, более грязные данные, соседние процессы, которые до этого не были видны, и потребность в регламентах. Если перескочить этот этап, компания рискует столкнуться с тем, что успешный пилот оказывается плохо масштабируемым.
Что именно искать во время обследования
Если говорить совсем практично, у обследования есть несколько основных объектов внимания.
Первый — повторяющаяся ручная работа. Где люди снова и снова делают одно и то же.
Второй — дублирование данных. Где одна и та же информация появляется в разных системах и переписывается вручную.
Третий — участки, где данные приходят в неструктурированном виде: письма, документы, сканы, фотографии, свободный текст.
Четвёртый — задержки и ожидания. Где процесс технически короткий, но бизнес-цикл растягивается из-за согласований и очередей.
Пятый — цена ошибки. Что будет, если система ошибётся: придётся ли просто поправить карточку, или последствия затронут деньги, документы, клиента, юридически значимые действия.
Шестой — критерий успешности. Как компания поймёт, что после внедрения стало лучше.
Эти пункты помогают отличить хороший кандидат на пилот от просто заметной боли. Иногда процесс выглядит раздражающим, но возникает слишком редко. Иногда наоборот — занимает много времени, но решается обычной интеграцией и не требует ИИ. А иногда именно сочетание частоты, рутины и неструктурированных входящих данных делает задачу идеальной для первого эксперимента.
Не каждый найденный процесс требует ИИ
Это принципиальный момент. Цель обследования не в том, чтобы во что бы то ни стало доказать необходимость ИИ. Хорошее обследование вообще может закончиться выводом, что на первом этапе компании полезнее сделать обычную автоматизацию, навести порядок в справочниках, убрать ручное дублирование или перестроить регламент.
Например, если сотрудники переписывают числа из одной системы в другую, это вовсе не задача для модели. Если данные доступны через программный интерфейс или выгрузку, здесь нужен простой и надёжный обмен. ИИ стоит обсуждать там, где обычных правил уже не хватает: в разборе документов, писем, звонков, больших массивов текстовой информации, поиске по внутренней базе знаний.
Обследование как раз и нужно для того, чтобы отделить одно от другого.
Пилот должен быть маленьким, но измеримым
После обследования почти всегда хочется взяться сразу за всё. Особенно если в компании нашлось много процессов, которые раздражают сотрудников. Но хороший пилот — это не «автоматизируем весь отдел», а «берём один поток операций и измеряем результат».
Например, не «делаем ИИ для всей бухгалтерии», а «автоматизируем подготовку черновиков по одному типу входящих документов». Не «помощник для всей службы продаж», а «классификация входящих обращений по одной очереди». Не «цифровой ассистент компании», а «поиск ответов по конкретному набору внутренних регламентов».
Важно, чтобы у пилота был короткий цикл обратной связи. Компания должна быстро увидеть, сколько времени тратилось раньше, как стало теперь, где модель ошибается, сколько операций ушло на ручную проверку, и стоит ли расширять проект.
Без этого ИИ остаётся красивой инициативой без понятного результата.
Что должно получиться на выходе обследования
Хорошее обследование — это не презентация о перспективах искусственного интеллекта. И не список модных технологий, которые стоит попробовать. Это конкретный рабочий документ.
В нём должно быть видно, какие процессы были рассмотрены, как они устроены, где возникают ручные действия, какие системы участвуют, какие данные ходят между ними, где есть узкие места и какова цена ошибки. Отдельно должен быть список кандидатов на пилот и краткое объяснение, почему выбран именно этот.
Тогда обсуждение ИИ сразу становится взрослым. Не «давайте что-нибудь внедрим», а «вот процесс, вот текущие затраты, вот возможный формат пилота, вот ожидаемый эффект, вот где требуется участие человека».
С чего начинать компании, если ИИ у неё ещё не было
Если компания только подходит к теме ИИ, я бы не начинал с универсального ассистента или агентной системы на всю организацию. Гораздо полезнее провести короткое, но честное обследование.
Посмотреть на реальные процессы. Получить доступ на чтение к основным системам. Поговорить с сотрудниками, которые делают работу руками. Посчитать частоту, время и ошибки. Понять, где данные дублируются и где информация приходит в неструктурированном виде.
После этого почти всегда появляется один-два хороших кандидата на пилот. И вот только тогда разговор о модели, архитектуре и конкретной реализации становится уместным.
Потому что внедрение ИИ — это не покупка умной функции. Это изменение процесса. А процесс сначала нужно увидеть.
