В прошлом году к нам пришел дистрибьютор медоборудования. У них уже были 1С, CRM, почта, Excel, сервис-деск и бот в Telegram, но заявка все равно жила в 5 интерфейсах, а по одному заказу продажи и бухгалтерия видели разные цифры. Проблема была не в нехватке софта. Нужно было собрать разорванный процесс и убрать ручные переносы, на которых терялись время и деньги.
Я вижу это регулярно. Бизнес покупает еще один инструмент, хотя узкое место находится в другом месте: данные приходят в разном виде, а решение по ним человек принимает «как обычно». Именно здесь нужен AI-слой - узкий, прикладной, с понятным KPI и сроком проверки в 4-8 недель.
Где правила еще работают, а где уже нужен AI-слой
Обычная автоматизация хорошо работает, пока вход аккуратный: форма заполнена, документ типовой, маршрут известен заранее. Такие цепочки мы спокойно собираем на Laravel 11, PostgreSQL 16 или Node.js 20 + NestJS, и они годами дают результат.
Проблемы начинаются, когда в процесс попадают письмо с вложением, кривой скан, комментарий менеджера в свободной форме или голосовое от клиента. Я сам когда-то пытался закрыть это только бизнес-правилами, но через пару спринтов список условий стал дороже ручной работы.
На сервисном проекте для B2B-поддержки мы поставили связку OCR + LLM + workflow. OCR вытаскивал текст из вложений, модель определяла тип обращения, правила проверяли обязательные поля, после чего задача уходила в сервис-деск. За 6 недель получили 78% автоклассификации и сократили первый ответ с 25 минут до 6 минут. Здесь нет никакой магии: машина просто взяла на себя тот участок, где раньше человек вручную сортировал хаос.
Правила оставляйте для типовых шагов. ИИ ставьте туда, где данные грязные, а маршрут спорный.
Окупается не самый модный процесс, а самый дорогой ручной участок
Если процесс нельзя описать через время, ошибку и стоимость одной операции, в него рано ставить ИИ. Деньги обычно лежат не в красивом демо, а в скучной операционке: счета, акты, сверки, triage заявок, поиск по старым перепискам.
У нас был проект в оптовой торговле. Бухгалтерия заносила документы из PDF и сканов вручную, на один комплект уходило 8-10 минут. Мы собрали контур с OCR, извлечением полей через LLM и валидацией по правилам 1С. Через 6 недель без ручного ввода проходило 67% документов, а среднее время упало до 2 минут.
Давайте посчитаем: если в день идет 300 документов, экономия даже в 6 минут на каждом - это 30 часов в сутки. При ставке оператора 700 ₽ в час получаем 21 000 ₽ в день, или около 420 000 ₽ в месяц при 20 рабочих днях. Цифры говорят: пилот за несколько недель уже можно сравнивать с бюджетом внедрения, а не с презентацией про будущее.
Чаще всего я смотрю на три признака:
- операция повторяется десятки раз в день;
- ошибка ручного ввода бьет по деньгам или срокам;
- цикл реально можно сократить хотя бы на 30%.
AI-слой обычно ставят поверх текущего зоопарка систем
Редко есть смысл менять CRM или ERP ради ИИ. В реальном бизнесе уже есть 1С, CRM, WMS, таблицы, почта и мессенджеры, просто связаны они людьми. Сотрудник открывает три окна, переносит данные в четвертое, а потом еще пишет коллеге в чат.
Ниже разница между обычной схемой и смарт-подходом:
| Что происходит | Как есть | После AI-слоя |
|---|---|---|
| Входящие документы | Сотрудник читает и переносит | OCR + извлечение полей |
| Проверка | Ручная по чек-листу | Правила + модель |
| Передача в системы | Переключение между окнами | API и middleware |
| Исключения | Теряются в почте | Очередь на разбор |
| Управление | Отчеты задним числом | BI по cycle time |
Email/PDF -> OCR -> LLM extraction -> validation rules
-> middleware/API -> ERP/1C/CRM
-> exception queue -> human review
-> dashboard: cycle time / error rate / STP
На одном таком проекте у клиента были 1С, amoCRM и внутренний сервис-деск. После оркестрации ручные переключения между системами снизились на 46%, а ошибки на стыке продаж и учета просели почти на треть.
Частая ошибка - сначала купить AI-платформу, а потом искать ей применение. Рабочий подход другой: берем один дорогой ручной участок, считаем baseline и уже вокруг него строим слой автоматизации.
Пилот должен отвечать на один вопрос: где вы уже платите за хаос каждый день
Для SMB хороший пилот - это один процесс, один тип данных, один KPI. Если пилот размазан по 12 подразделениям, это уже дорогой способ ничего не проверить.
Обычно разговор с клиентом выглядит так: компания хочет внедрить ИИ в обработку заявок, но не знает, сколько заявок проходит за день и сколько минут уходит на одну. В такой ситуации внедрять пока нечего - сначала нужно считать базу.
На старте достаточно пяти метрик: время обработки, доля операций без участия человека, частота ошибок, стоимость операции и часы команды. На практике подготовка занимает не квартал, а 3 дня: выгрузить историю, посмотреть путь заявки, найти ручные развилки и выбрать участок, где бизнес уже платит за хаос каждый день.
Был и неудачный проект. Клиент хотел полностью убрать людей из разбора нестандартных претензий дилеров. Данных мало, формулировки плавают, цена ошибки высокая. Мы остановили идею полной автономии и вернули человека в цикл. Формально скорость стала ниже, но TCO процесса уменьшился, потому что перестали тратить деньги на исправление неверных решений модели.
Что сделать в ближайшие 3 дня
Возьмите один процесс, где люди копируют данные между системами, и вручную посчитайте 50 последних операций: сколько минут ушло, сколько было ошибок, сколько раз сотрудник переключался между окнами. После этого задайте себе один вопрос: какую ручную работу вы готовы перестать оплачивать через два месяца. Если ответ звучит в рублях и часах, у вас уже есть основа для нормального пилота.
