Считаем baseline до внедрения
Фиксируем время цикла, долю ручных операций и стоимость обработки одной заявки — иначе эффект внедрения невозможно доказать.
AI для бизнес-процессов
Автоматизируем процессы, где есть журнал событий и повторяемые правила, — и оставляем человека там, где он нужен
Сначала считаем процесс по фактам: выгружаем журнал заявок, документов и согласований, строим карту переходов и находим, где время уходит впустую. Потом автоматизируем именно эти шаги — извлечение полей из документов, классификацию обращений, маршрутизацию, подготовку проекта решения. Пилот на одном процессе занимает 4–6 недель и заканчивается измеримым результатом либо честным «здесь ИИ не нужен».
- Baseline до внедрения: время цикла, доля ручных операций, стоимость обработки одной заявки
- Прототип на ваших документах и заявках, а не на демонстрационных примерах из документации модели
- Каждое предложение модели — со ссылкой на источник и уровнем уверенности, сомнительные случаи уходят человеку
- Модель можно держать в вашем контуре: обработка данных без выхода во внешние сервисы
Разбор одного процесса
Опишите процесс, который съедает больше всего времени. Вернёмся с тем, что из него можно снять с помощью ИИ, а что — обычным кодом.
Не передаём данные третьим лицам
Модель можно держать в вашем контуре
- 4–6 недель
- Пилот на одном процессе
- 1 процесс
- Берём на старте
- 3 метрики
- Фиксируем до внедрения
- 60 000 ₽ / мес.
- Поддержка после запуска
Работающий контур на реальных данных, а не презентация возможностей модели
Не «внедрить ИИ в компании», а один процесс с понятным владельцем и метрикой
Время цикла, доля операций без человека, стоимость обработки одной заявки
Мониторинг качества, дообучение на новых примерах, разбор исключений
Сроки этапов и ориентиры бюджета — публичные условия работы, они же указаны в других разделах сайта. Эффект от внедрения зависит от процесса и считается индивидуально: до замера baseline его нельзя назвать честно.
Процесс сначала измеряем, потом автоматизируем
Операционные процессы в российских компаниях редко ломаются целиком: обычно они состоят из десятка шагов, часть которых выполняется вручную — перенос данных между системами, разбор писем, сверка документов, согласование заявок. Именно эти шаги съедают время сотрудников и создают очереди.
Мы работаем с процессами, где уже есть цифровой след: заявки в CRM и Service Desk, счета и акты, логи согласований, история загрузки исполнителей. Чем больше следов, тем точнее можно посчитать текущее состояние процесса и предсказуемее получить эффект от внедрения ИИ.
Прототип на ваших данных
Первые результаты показываем на реальной выборке документов и заявок, а не на демо-примерах из документации модели.
ИИ там, где он уместен
Классификация, извлечение полей, поиск по регламентам. Там, где нужна арифметика и детерминизм, остаётся обычный код.
Люди остаются в контуре
Модель предлагает решение и уровень уверенности, сотрудник подтверждает. Исключения уходят на ручной разбор.
Почему автоматизация процессов не доходит до результата
Шесть причин, из-за которых проект останавливается после демонстрации или тихо умирает в проде. Мы начинаем с проверки, нет ли их у вас.
Регламент описывает процесс, которого нет
Схема на совещании и реальные действия сотрудников расходятся: часть шагов делается в почте и мессенджерах, часть не делается вовсе. Автоматизировать по регламенту — значит автоматизировать фантазию и получить систему, которой никто не пользуется.
Пилот на демонстрационных данных не переносится в прод
Модель уверенно разбирает аккуратные примеры из документации и рассыпается на сканах, письмах без темы и счетах от поставщиков, которые верстали вручную. Проверять гипотезу нужно на вашей выборке — включая самые неудобные документы.
Модель отвечает уверенно и неправильно
Ответ без ссылки на источник и без оценки уверенности невозможно проверить, а значит нельзя и подписывать. В процессах, где решение имеет последствия, такое поведение модели недопустимо: сотрудник либо перепроверяет всё вручную, либо ошибается вместе с ней.
Взялись автоматизировать всё сразу
Проект «внедрить ИИ в компании» не имеет ни границ, ни критерия готовности, ни владельца. Через три месяца он превращается в набор несвязанных прототипов, и решение о продолжении принимать не по чему. Один процесс, одна метрика, один срок.
Эффект нечем доказать
Если время цикла и стоимость операции не измерены до старта, после запуска остаётся только мнение: одному кажется, что стало быстрее, другому — что добавилось работы на разборе ошибок. Замер до внедрения стоит две недели и снимает этот спор навсегда.
Документы и обращения приходят в неудобном виде
Сканы без текстового слоя, письма без темы, вложения в мессенджерах, таблицы с объединёнными ячейками, поставщики, у каждого из которых свой формат счёта. Это не мешает автоматизации — это и есть основная работа по подготовке данных, и её нужно заложить в план.
Если хотя бы один пункт описывает вашу ситуацию — это не повод отказываться от проекта, а повод начать с диагностики. Все шесть причин снимаются на этапе замера baseline: он стоит 1–2 недели и заканчивается картой процесса с числами. Дальше решение принимается по данным, а не по презентации.
Карта процесса строится по журналу событий, а не по регламенту
Выберите типовой процесс и переключите состояние — увидите, как выглядит разбор: какие переходы съедают время, что снимается автоматически и что остаётся человеку. Ровно такой документ вы получаете по итогам диагностики, только с вашими числами.
Источник данных
журнал заявок в CRM или Service Desk
Объём
1 000 обращений в месяц
Время цикла
17 ч 6,4 ч
Ручных шагов
2 / 5
Снимается автоматически: 3
-
Письмо, форма с сайта и сообщение в мессенджере приводятся к одной карточке: контакты, тема, вложения, история клиента. Человек подключается, только если обращение не удалось разобрать.
-
Тип обращения, срочность и профильная очередь определяются по тексту и истории похожих обращений. Спорные случаи помечаются и уходят на разбор, а не решаются наугад.
-
Договор, лимиты, история платежей и прошлые обращения подтягиваются из учётной системы. Это детерминированные запросы, а не ИИ: там, где нужна точность, остаётся обычный код.
-
Здесь нужен человек: решение зависит от контекста, которого нет в данных. ИИ готовит черновик ответа, находит применимые пункты регламента и подкладывает прецеденты — специалист правит и подписывает.
-
Маршрут согласования строится автоматически по сумме и типу решения, но подпись остаётся за ответственным. Просроченные согласования возвращаются напоминанием, а не теряются в почте.
Источник данных
журнал поступления документов и проводок
Объём
4 000 документов в месяц
Время цикла
18 ч 4,4 ч
Ручных шагов
1 / 5
Снимается автоматически: 4
-
Документ забирается из почты, ЭДО и папки: определяется тип (счёт, акт, накладная, договор), отсекаются дубли и письма без вложений.
-
OCR для сканов и модель извлечения для реквизитов: контрагент, суммы, НДС, даты, номера. Для каждого поля возвращается уверенность — низкая уверенность означает проверку человеком, а не запись наугад.
-
Сопоставление позиций, сумм и условий оплаты с закупкой. Расхождения формируются списком с указанием, чем именно документ отличается от ожидаемого.
-
Решение по расхождению принимает человек: принять, вернуть поставщику или провести корректировкой. Система экономит не решение, а поиск того, что именно не сходится.
-
Проведение в учётной системе и укладка документа в архив с полным набором атрибутов. Здесь ИИ не нужен вовсе — это интеграция.
Источник данных
журнал версий и согласований
Объём
300 договоров в месяц
Время цикла
30 ч 12,8 ч
Ручных шагов
2 / 5
Снимается автоматически: 3
-
Проверяется, что приложены все документы контрагента и что карточка заполнена. Неполные комплекты возвращаются инициатору сразу, а не на этапе подписи.
-
Модель находит отклонения от утверждённого шаблона и показывает их рядом с эталонным пунктом. Юрист читает список расхождений, а не 40 страниц текста.
-
Скоринг подсказывает, на что смотреть, и предлагает маршрут по сумме и типу отклонений — но решение о риске принимает человек: цена ошибки здесь выше скорости.
-
Переговоры не автоматизируются. Система ведёт протокол версий и напоминает о зависших договорах, чтобы они не оставались в чьём-то ящике на неделю.
-
Выгрузка в ЭДО, фиксация подписанной версии, запись условий в учётную систему и постановка сроков на контроль.
Снимается автоматически
Остаётся за человеком
Нажмите на шаг, чтобы увидеть, что происходит с ним после внедрения
Цифры в карте — иллюстрация формата разбора на типовых процессах, а не обещанный результат: на вашем процессе они будут другими. Что именно получится снять с сотрудников, видно только после выгрузки вашего журнала событий — этим и занимается диагностика.
Где в контуре действительно ИИ, а где обычный код
Мы разделяем контур на слои и для каждого честно отвечаем, чем он реализован. Модель ставится туда, где входной формат нестабилен, а правила не описываются формулой. Всё, что можно посчитать точно, считается кодом — это дешевле, быстрее и проверяемо.
Пять слоёв из шести содержат элементы ИИ. Полностью детерминированный — только журнал и контроль.
обычный код
Слой 1 из 6
Источники данных
Интеграции, выгрузки, журналы событий
Первым делом собираем то, что уже есть: историю заявок, документов, согласований и назначений. Здесь нет ИИ и не должно быть — это интеграции и выгрузки. Важно другое: без этого слоя невозможно ни посчитать baseline, ни проверить гипотезу, поэтому диагностика начинается именно здесь.
- На входе
- CRM, Service Desk, 1С, ЭДО, почта, телефония, файловые хранилища
- На выходе
- Единый набор событий с метками времени, участниками и признаками объекта
ИИ
Слой 2 из 6
Извлечение и нормализация
Документы, письма, сканы, вложения
Здесь начинается ИИ. OCR поднимает текст со сканов, модель извлечения достаёт реквизиты и сущности, правила приводят справочники к единому виду. Ключевое требование: по каждому полю возвращается уверенность, а низкая уверенность означает проверку человеком, а не запись наугад.
- На входе
- PDF, сканы, DOCX, письма без темы, вложения из мессенджеров
- На выходе
- Структурированные поля со ссылкой на фрагмент источника и оценкой уверенности
ИИ
Слой 3 из 6
Знания и регламенты
Поиск по внутренней базе (RAG)
Ответ на вопрос «как правильно» ищется не в памяти модели, а в ваших документах: регламентах, инструкциях, договорах, истории решений. Модель формулирует, поиск находит, ссылка на источник обязательна. Именно это отличает рабочую систему от чата, который уверенно придумывает пункт регламента.
- На входе
- Регламенты, инструкции, типовые формы, база знаний, архив прецедентов
- На выходе
- Ответ с указанием документа и пункта, на основании которого он дан, плюс уровень уверенности
ИИ + код
Слой 4 из 6
Классификация и скоринг
Тип обращения, риск, приоритет, маршрут
Задача с числовым ответом: определить тип, оценить риск, расставить приоритеты, выбрать маршрут согласования. Здесь ИИ соседствует с правилами: пороги, лимиты и обязательные проверки задаются кодом и настраиваются вами, а не выводятся моделью. Пороговая логика должна быть видна и объяснима.
- На входе
- Нормализованные поля, история похожих случаев, суммы и сроки
- На выходе
- Метка класса, оценка риска, приоритет в очереди, предложенный маршрут
ИИ + код
Слой 5 из 6
Человек в контуре
Черновики, подтверждение, разбор исключений
Модель готовит черновик решения и показывает основания — сотрудник подтверждает, правит или отклоняет. Правки не теряются: они становятся примерами для дообучения и показывают, где контур ошибается. Исключения не прячутся в общий поток, а собираются в отдельную очередь, чтобы их можно было разбирать и уменьшать.
- На входе
- Черновик, источники, оценка уверенности, приоритет
- На выходе
- Подтверждённое решение, исправление модели, пример для дообучения
обычный код
Слой 6 из 6
Журнал, метрики и контроль качества
Аудит решений, эффект, деградация модели
Каждое решение записывается с версией модели, входными данными и тем, что подтвердил человек. Это нужно не для отчётности, а для эксплуатации: без журнала невозможно ни доказать эффект, ни заметить, что качество упало после смены формата счетов у поставщика. Проверки тоже детерминированы и работают по расписанию.
- На входе
- Все решения контура с версиями и правками
- На выходе
- Отчёт по метрикам, сигнал о падении качества, выборка для приёмки этапа
Итог по составу: элементов с ИИ — 4 из 6, полностью детерминированный слой — один (журнал и контроль качества). Всё, что можно посчитать точно, считается кодом: это дешевле в эксплуатации и проверяется тестами, а не оценкой качества модели.
Ручная работа, интеграция или ИИ: что подходит в вашем случае
Три способа убрать ручные шаги. Мы выбираем не самый современный, а тот, который решает задачу с наименьшей ценой ошибки — и часто это не ИИ.
| Критерий | Ручная работа | Интеграция и правила | ИИ с проверкой человеком |
|---|---|---|---|
| Стабильный формат входных данных | Да | Да | Да |
| Неструктурированный текст, сканы, письма | Да | Нет | Да |
| Правила описываются формулой | Да | Да | Частично |
| Гарантированная точность каждого шага | Частично | Да | Нет |
| Стоимость при росте объёма | Нет | Да | Частично |
| Скорость на старте | Да | Частично | Нет |
| Нужна проверка человеком | Нет | Нет | Да |
| Работает при смене формата у поставщика | Да | Нет | Частично |
«ИИ с проверкой человеком» проигрывает по гарантированной точности — это не недостаток реализации, а свойство вероятностных моделей. Поэтому в контуре всегда остаётся контур подтверждения и всегда есть очередь исключений. Обещать 100 % точности на неструктурированных данных нельзя ни на одной модели.
Данные, модели и развёртывание
Вариант развёртывания выбирается до начала работ и фиксируется в договоре вместе со схемой потоков данных. Ниже — два рабочих варианта и то, что происходит с данными в каждом из них.
Применяется, когда данные не являются персональными или чувствительными: типовые регламенты, общие вопросы, черновики формулировок. Работает быстрее и дешевле, качество формулировок выше.
Покидает ваш контур
- Обезличенный текст запроса без реквизитов и персональных данных
- Фрагменты общедоступных регламентов и инструкций
- Формулировки, не содержащие сумм, имён и номеров договоров
Остаётся у вас
- Персональные данные и реквизиты контрагентов
- Документы с суммами, счетами и номерами договоров
- База знаний целиком: во внешний сервис уходят только найденные фрагменты
- Журнал решений и правок сотрудников
Применяется, когда данные персональные, коммерчески чувствительные или есть прямое требование службы безопасности. Ни один фрагмент не покидает ваш контур — включая запросы к модели.
Покидает ваш контур
- Ничего: внешние сервисы в контуре не используются
Остаётся у вас
- Документы, обращения, реквизиты и персональные данные
- Запросы к модели, включая промежуточные
- База знаний и архив решений целиком
- Веса моделей, журнал решений и метрики качества
Открытые модели в вашем контуре
Для закрытого варианта разворачиваем открытые модели на вашем оборудовании: Qwen, Llama, семейство Mistral и специализированные модели для OCR и извлечения. Никаких запросов во внешние сервисы в этом варианте не происходит вовсе.
Требования к оборудованию считаются заранее
До старта считаем, какие ресурсы нужны под ожидаемый объём: закрытый контур требует GPU, и это заметная часть бюджета. Если объём небольшой, иногда дешевле гибридный вариант — говорим об этом прямо, а не продаём железо.
Разметка на обезличенной выборке
Дообучение и отладка идут на обезличенных данных: персональные данные заменяются маркерами, реальные реквизиты — синтетическими. Доступ к продуктивным данным у разработчика не требуется для большинства задач.
Обработка персональных данных по 152-ФЗ
Работаем в рамках поручения на обработку персональных данных: определяем состав данных, сроки хранения, круг доступа и место обработки. Схема утверждается вашей службой безопасности до старта.
Журнал для аудита
Каждое решение модели записывается вместе с входными данными, версией модели, источниками и тем, что подтвердил сотрудник. Это позволяет разобрать любое решение задним числом и предъявить его проверяющему.
Проверка на устойчивость к подмене входа
Промпт-инъекции в документах и обращениях — реальный вектор: в текст счёта можно дописать инструкцию модели. Контур проверяется на такие попытки, а решение модели никогда не выполняется напрямую как команда.
Вариант развёртывания влияет на бюджет, поэтому выбирается на диагностике, а не после. Гибридный вариант дешевле и качественнее на формулировках; закрытый — единственный допустимый, если данные персональные или этого требует служба безопасности.
Проверим, есть ли в вашем процессе предмет для ИИ
Автоматизация с помощью ИИ уместна не везде. Ниже — условия, при которых проект даёт результат, и случаи, в которых мы от него отговорим.
Сработаемся
- Есть цифровой след: заявки в CRM или Service Desk, счета и акты, логи согласований, история загрузки исполнителей
- Процесс повторяется: десятки и сотни однотипных операций в месяц, а не единичные исключения
- Часть шагов — это разбор неструктурированного текста, документов или обращений, где правила не удаётся описать одной формулой
- Есть владелец процесса, который готов две–три недели отвечать на вопросы и подтверждать, что считается правильным результатом
- Готовы начать с одного процесса и оценивать результат по метрике, а не по впечатлению
Скорее всего, не подойдёт
- Процесс держится на экспертизе и переговорах: продажи крупным клиентам, сложные юридические споры, антикризисное управление
- Данных нет вовсе: операции не фиксируются ни в одной системе, восстановить историю невозможно
- Требуется гарантированная точность 100 % там, где ошибка недопустима: ИИ даёт вероятностный результат и всегда требует контура проверки
- Задача решается обычным правилом или интеграцией: если поля документа всегда одинаковые, модель здесь только удорожает решение
- Нужен результат «на следующей неделе»: замер baseline и пилот занимают недели, а не дни
Если хотя бы один пункт про вас — скажите об этом в заявке. Мы предложим другой формат работы или честно скажем, что здесь мы не поможем: брать проект, который не даст результата, дороже для репутации, чем отказаться.
Четыре направления работ
Обычно начинают с одного — чаще всего с оптимизации процесса, потому что она даёт измеримый результат быстрее остальных. Остальные направления подключаются, когда первый контур работает.
Оптимизация процессов
Разбираем процесс по журналам событий, находим узкие места и автоматизируем ручные операции: извлечение данных из документов, классификацию заявок, маршрутизацию и контроль сроков.
Карта процесса с числами и конвейер, снимающий ручные шаги
- process mining по журналам событий
- извлечение полей из документов
- классификация и маршрутизация обращений
- контроль сроков и эскалация
Поддержка принятия решений
Системы, которые находят нужный пункт регламента, оценивают риск сделки и предлагают вариант решения с обоснованием. С указанием источников, уровня уверенности и журналом для аудита.
Ответы на вопросы «как правильно» со ссылкой на пункт регламента
- поиск по внутренней базе знаний (RAG)
- скоринг сделок и контрагентов
- объяснение рекомендации и источников
- журнал решений для аудита
Распределение ресурсов
Прогнозируем спрос и загрузку, строим расписания с учётом квалификаций и ограничений, оптимизируем маршруты и распределение задач между исполнителями и подрядчиками.
Прогноз загрузки и расписание, собранное с учётом ограничений
- прогноз спроса и загрузки
- планирование смен и назначений
- оптимизация маршрутов и очередей
- контроль переработок и простоев
Управление рисками
Оцениваем контрагентов и сделки по данным, отслеживаем отклонения в поведении клиентов и операций, приоритизируем инциденты и алерты так, чтобы служба риска разбирала важное, а не всё подряд.
Очередь сигналов, отсортированная по значимости, а не по дате
- скоринг и мониторинг контрагентов
- выявление отклонений в поведении
- ранжирование алертов и инцидентов
- разбор причин и обратная связь
Какой процесс автоматизировать первым
Пять вопросов о данных, объёме и людях. Ответите — увидите, где в вашем случае вероятнее всего окажется результат, с какого шага начинать и где ИИ, скорее всего, не понадобится вовсе.
Пять вопросов, около минуты. Ответы можно отправить нам вместе с заявкой — разберём их и скажем, с чего начинать.
Вопрос 1 из 5
≈ 1 минута
Ответ виден сразу — телефон не нужен
Как проходит проект: от журнала событий до работающего контура
Пять этапов с результатом на каждом. Если на этапе выясняется, что процесс автоматизировать нечем или что задача решается обычной интеграцией, мы говорим об этом сразу — до того, как вы заплатите за следующий этап.
-
01
Диагностика и выбор процесса
1–2 недели
Разбираем, как процесс работает сейчас: выгружаем журнал событий, размечаем переходы, считаем время цикла на каждом шаге, долю ручных операций и стоимость обработки одного экземпляра. Проверяем, есть ли в процессе предмет для ИИ, и честно говорим, если его нет.
Результат этапа: Карта процесса с числами и обоснованный выбор шага, с которого начинать
-
02
Проверка гипотезы на ваших данных
1–2 недели
Берём вашу выборку — включая самые неудобные документы и обращения — и проверяем, тянет ли модель задачу в принципе: какая точность достижима, на чём она ломается, сколько случаев уйдёт на ручной разбор. Это дешёвый способ не потратить бюджет на заведомо неработающий сценарий.
Результат этапа: Отчёт с замеренной точностью на ваших данных и границами применимости
-
03
Пилот на одном процессе
4–6 недель
Собираем работающий контур: интеграции с вашими системами, извлечение и нормализация, поиск по регламентам, классификация, интерфейс сотрудника с черновиками и подтверждением. Пилот идёт на реальных данных, но в ограниченном контуре — без риска для основного учёта.
Результат этапа: Работающий контур на реальных данных и сотрудники, которые им пользуются
-
04
Оценка результата и решение
1 неделя
Сравниваем измеренные метрики с baseline: время цикла, доля операций без человека, точность извлечения, доля исключений, стоимость обработки. Считаем, при каком объёме операций решение окупается. Дальше решение принимаете вы — по числам, а не по впечатлению от демонстрации.
Результат этапа: Отчёт по метрикам с расчётом окупаемости и решение о продолжении
-
05
Внедрение, обучение и поддержка
от 4 недель
Переносим контур в продуктив, подключаем остальные процессы и роли, обучаем сотрудников и службу поддержки. Дальше следим за качеством: новый формат документов у поставщика или смена регламента — обычная причина падения точности, и её нужно замечать до того, как это заметят клиенты.
Результат этапа: Процесс в проде, документация, доступы и регламент передачи знаний
С чем интегрируемся
- 1С:ERP и 1С:Управление торговлей
- 1С:Документооборот
- 1С:ЗУП
- Bitrix24
- amoCRM
- SAP
- Naumen Service Desk
- Jira
- ЭДО Диадок
- СБИС
- Exchange и почтовые шлюзы
- Telegram и мессенджеры
- PostgreSQL и ClickHouse
- REST и SOAP API учётных систем
- Файловые хранилища и сканеры
Этапы можно брать по отдельности. Диагностика имеет смысл сама по себе: даже если проект не продолжится, у вас останется карта процесса с числами — с ней можно идти к другому подрядчику или решать задачу своими силами.
Что входит в пилот
Состав работ фиксируется в договоре до старта. Ниже — полный перечень: если пункт здесь есть, он входит в этап, а не появляется отдельной строкой в смете по ходу проекта.
01
Разбор процесса по журналам событий
Восстанавливаем фактический маршрут процесса: какие шаги действительно выполняются, сколько занимают, где копятся очереди и возвраты. Расхождение с регламентом показываем отдельно — обычно именно оно объясняет, почему прежние попытки оптимизации не дали эффекта.
- Выгрузка и разметка событий
- Расчёт времени цикла по переходам
- Поиск узких мест и возвратов
- Карта процесса в виде документа
02
Подготовка данных
Самая недооценённая часть проекта. Приводим в порядок то, на чём будет учиться и работать контур: собираем выборку, размечаем правильные ответы, чистим справочники, отбираем неудобные случаи. Без этого шага точность модели на реальных документах непредсказуема.
- Сбор и разметка выборки
- Нормализация справочников
- Отбор пограничных случаев
- Протокол качества данных
03
Контур извлечения и нормализации
OCR для сканов, извлечение реквизитов и сущностей, приведение к единой схеме. По каждому полю возвращается уверенность и ссылка на фрагмент источника, поэтому любое значение можно проверить, не открывая документ целиком.
- OCR и работа со сканами
- Извлечение полей и сущностей
- Оценка уверенности и источник
- Очередь на проверку человеком
04
Поиск по регламентам и базе знаний
Контур RAG по вашим документам: ответ формируется на основании регламентов, инструкций и архива решений, а не из памяти модели. В каждом ответе — ссылка на документ и пункт, по которому он дан.
- Индексация регламентов и инструкций
- Ответ со ссылкой на источник
- Разграничение прав по ролям
- Актуализация при смене документов
05
Интерфейс сотрудника и разбор исключений
Рабочее место, где видно черновик решения, основания и уверенность модели — и где решение подтверждается одной кнопкой. Исключения собираются в отдельную очередь, чтобы их можно было разбирать и постепенно уменьшать их долю.
- Черновик и подтверждение решения
- Очередь исключений
- Сбор правок для дообучения
- Уведомления и эскалации
06
Метрики, приёмка и передача
Метрики считаются контуром, а не отчётом подрядчика: время цикла, доля операций без человека, точность извлечения, доля исключений, стоимость обработки. По ним проводится приёмка этапа, и они же остаются у вас после передачи проекта.
- Дашборд метрик процесса
- Протокол приёмки по числам
- Документация и схемы
- Передача доступов и обучение
Когда автоматизация процесса окупается
Подставьте объём операций, время на одну операцию и стоимость часа сотрудника — увидите, сколько часов в месяц освобождается и за какой срок окупается работа. Формулы открыты и показаны рядом с результатом: цифру можно проверить, а не принимать на веру.
Ваши показатели
2 000
шт.
Однотипные операции одного процесса: обращения, счета, заявки, согласования
12
мин.
Время сотрудника целиком, включая поиск данных, ожидание и переключение между системами
700
₽ / час
Полная стоимость часа с налогами и рабочим местом, а не оклад, делённый на часы
40
%
Сколько операций контур закроет полностью. Главная неизвестная: определяется на диагностике
900 000
₽
Стоимость работ, окупаемость которых считаем: пилот от 900 000 ₽, внедрение от 1 500 000 ₽
Что получается
- Ручного времени сейчас
- 400 ч / мес
- Освобождается
- 160,0 ч / мес
Столько часов сотрудников съедает процесс целиком
Это 1,00 ставки — при условии, что высвобожденное время пойдёт на другую работу, а не растворится
Накопленная экономия за 12 месяцев
1 344 000 ₽
1 мес.
6 мес.
12 мес.
Полная высота столбца — бюджет этапа 900 000 ₽. Выделенные столбцы — месяцы, к которым накопленная экономия перекрыла бюджет.
Окупаемость этапа
Бюджет 900 000 ₽ окупается за 8,0 месяцев при экономии 112 000 ₽ в месяц. За год экономия перекрывает бюджет 1,5×.
Как это посчитано
- Экономия часов = объём операций × время на операцию × доля снимаемых операций
- Экономия в месяц = сэкономленные часы × стоимость часа сотрудника
- Окупаемость в месяцах = бюджет этапа ÷ экономия в месяц
Значения в полях — демонстрационные, для примера расчёта. Подставьте свои: точные числа видны из журнала событий, и именно их мы считаем на этапе диагностики.
Обсудить расчёт с менеджеромРасчёт уйдёт вместе с заявкой — пересказывать цифры по телефону не придётся.
Считаем…
Стоимость этапов
Ориентиры по бюджету и срокам. Точная смета появляется после диагностики: без замера процесса любая названная цифра была бы угадыванием, а фиксировать в договоре угаданную сумму — плохая идея для обеих сторон.
Диагностика процесса
от 150 000 ₽
- Формат:
- 1–2 недели, фиксированная цена
- Результат:
- карта процесса с числами
Разбор процесса по журналам событий, расчёт baseline и проверка гипотезы на вашей выборке. Этап имеет самостоятельную ценность: карта процесса остаётся у вас, даже если проект не продолжится.
- Выгрузка и разметка журнала событий
- Время цикла, доля ручных операций, стоимость операции
- Проверка достижимой точности на ваших данных
- Обоснованный выбор шага для автоматизации
- Заключение: где ИИ уместен, а где достаточно интеграции
Пилот на одном процессе
от 900 000 ₽
- Формат:
- 4–6 недель, смета по итогам диагностики
- Результат:
- работающий контур на реальных данных
Сборка контура от интеграций до рабочего места сотрудника: извлечение и нормализация, поиск по регламентам, классификация, черновики решений и разбор исключений. Заканчивается замером метрик и решением о продолжении.
- Интеграции с вашими системами и источниками
- Контур извлечения с оценкой уверенности
- Поиск по регламентам со ссылкой на источник
- Рабочее место сотрудника и очередь исключений
- Дашборд метрик и протокол приёмки
Внедрение и развитие
от 1 500 000 ₽
- Формат:
- от 4 недель, этапами
- Результат:
- процессы в продуктив, поддержка от 60 000 ₽/мес
Перенос контура в продуктив, подключение остальных процессов и ролей, обучение сотрудников, мониторинг качества и дообучение на новых примерах. Объём следующего этапа определяется по результатам пилота.
- Перенос в продуктив и нагрузочная проверка
- Подключение остальных процессов и ролей
- Обучение сотрудников и службы поддержки
- Мониторинг деградации качества
- Дообучение на правках сотрудников
Ориентиры указаны для планирования бюджета. Итоговая смета фиксируется в договоре после диагностики и меняется только по согласованной заявке на изменение объёма — «уточнение по ходу проекта» в этом проекте не используется как способ увеличить цену.
Что фиксируем до начала работ
Цена и срок этапа фиксируются в договоре
Смета этапа считается после диагностики и дальше не меняется. Изменение объёма оформляется отдельной заявкой с новой ценой и новым сроком — до начала работ, а не после.
Метрика приёмки согласуется заранее
До старта пилота фиксируем, по какому числу принимается результат: точность извлечения на согласованной выборке, доля операций без человека, время цикла. Приёмка идёт по замеру, а не по перечню выполненных работ.
Честное «здесь ИИ не нужен»
Если по итогам диагностики окажется, что задача решается обычной интеграцией или что данных недостаточно, мы скажем это до пилота. Отказ от заведомо неработающего проекта дешевле для репутации, чем сдача формально выполненного.
Данные и модели остаются под вашим контролем
Контур можно развернуть в вашем контуре и на открытых моделях, без передачи данных во внешние сервисы. Выбор варианта фиксируется в договоре вместе со схемой потоков данных.
Код, документация и доступы передаются вам
После этапа у вас остаются исходный код, схемы интеграций, описание контура и доступы к средам. Мы не удерживаем проект технической недоступностью: поддержку можно не продлевать.
Правки сотрудников не теряются
Каждое исправление решения человеком записывается и становится примером для дообучения. Это же и способ доказать, что качество со временем растёт, а не остаётся на уровне первого запуска.
Что измеряем и как считается эффект
Шесть метрик, по которым проводится приёмка этапа. Все они считаются контуром автоматически — отчёт не нужно собирать вручную, и подрядчик не может показать только удобные числа.
- Время цикла
- Как считаем: медиана времени от первого события процесса до последнего, по журналу, отдельно для каждого типа обращения
- Главный показатель: именно он определяет, сколько обращений успевает пройти процесс за месяц и где скапливается очередь.
- Доля операций без человека
- Как считаем: отношение числа экземпляров, прошедших процесс без правок и подтверждений, к общему числу
- Показывает реальную разгрузку сотрудников. Если показатель низкий, контур работает, но люди по-прежнему заняты тем же самым.
- Точность извлечения полей
- Как считаем: доля полей, извлечённых верно, на согласованной выборке документов, включая пограничные случаи
- Без замера на неудобных документах точность на демонстрационных примерах ничего не говорит о продуктивной работе.
- Доля исключений
- Как считаем: отношение числа экземпляров, ушедших на ручной разбор, к общему числу, с разбивкой по причинам
- Разбивка по причинам показывает, что именно дорабатывать. Снижение этой доли — основная работа после запуска.
- Стоимость обработки одного экземпляра
- Как считаем: сумма часов сотрудников, потраченных на процесс, умноженная на стоимость часа, делённая на число экземпляров
- Переводит эффект в деньги и позволяет посчитать окупаемость этапа, а не обсуждать «стало удобнее».
- Время до первого ответа
- Как считаем: медиана времени от поступления обращения до первого содержательного ответа
- Для внешних процессов это то, что чувствует клиент. Улучшение времени цикла без улучшения этого показателя ему не видно.
Метрики считаются на вашей стороне и остаются у вас после завершения проекта. Если мы расходимся в оценке результата, спор решается по журналу, а не по презентации.
Что нужно с вашей стороны
Проект автоматизации не делается «за клиента»: без доступа к данным и человека, который знает процесс, диагностика превращается в догадки. Ниже — минимум, без которого мы не начинаем.
-
1
Доступ к журналам и данным
Выгрузка или доступ на чтение к системам, где живёт процесс: заявки, документы, согласования, назначения. На этапе диагностики достаточно обезличенной выгрузки.
-
2
Владелец процесса
Человек, который отвечает за процесс и может подтвердить, что считается правильным результатом. Две–три встречи в неделю на этапе диагностики и пилота.
-
3
Образцы неудобных случаев
Не только аккуратные документы, но и те, на которых всё ломается: плохие сканы, письма без темы, поставщики со своим форматом. Именно на них проверяется, будет ли контур работать.
-
4
Среда для пилота
Тестовый контур или отдельная копия системы, где можно работать с реальными данными, не рискуя основным учётом. Требования к среде определяются после диагностики.
Частые вопросы
Отвечаем на то, что спрашивают до начала работ: про деньги, сроки, доступы и данные.
Интеграция и скрипт работают там, где формат входных данных стабилен и правила описываются формулой: если все счета приходят из одной системы с фиксированными полями, ИИ в этой задаче только удорожает решение — мы делаем обычную интеграцию. ИИ подключается там, где формат нестабилен: сканы разного качества, письма от сотен поставщиков, обращения, написанные свободным текстом, документы, у которых каждый второй контрагент верстает по-своему. На диагностике мы разбираем процесс по шагам и для каждого шага говорим, чем он реализуется — моделью или кодом.
Цифровой след — это записи о том, что происходило в процессе: заявки с датами и статусами, документы с историей версий, согласования с участниками, история загрузки исполнителей. Если такие записи есть хотя бы в одной системе, процесс можно измерить и автоматизировать. Если операция не фиксируется нигде — сначала придётся её фиксировать, и это отдельная работа, которую мы честно называем до старта. Оценить свой случай можно за один разговор: опишите процесс и системы, в которых он живёт.
Диагностика процесса — от 150 000 ₽ и 1–2 недели, это фиксированная цена этапа. Пилот на одном процессе — от 900 000 ₽, срок 4–6 недель. Внедрение и развитие — от 1 500 000 ₽, этапами; поддержка после запуска — от 60 000 ₽ в месяц. Цена зависит от трёх вещей: объёма и качества данных, числа интеграций и сложности правил принятия решения. Закрытый контур на своём оборудовании дороже гибридного: нужны GPU. Точная смета фиксируется в договоре после диагностики.
Через шесть недель будет работающий контур на ваших данных: интеграции с вашими системами, извлечение и нормализация, поиск по регламентам, классификация и рабочее место сотрудника с подтверждением решений. Пилот идёт в ограниченном контуре, не затрагивая основной учёт. На выходе — замеренные метрики, сравнение с baseline и расчёт окупаемости, по которым вы принимаете решение о продолжении. Демонстраций «возможностей модели» в этом этапе нет: показываем только то, что работает на ваших документах.
Не обязательно. Есть два варианта. Гибридный: во внешний сервис уходят только обезличенные фрагменты без персональных данных и реквизитов — он дешевле и даёт лучшее качество формулировок. Закрытый: открытые модели разворачиваются на вашем оборудовании, и тогда ни один фрагмент, включая запросы к модели, не покидает ваш контур. Второй вариант обязателен, если данные персональные или есть требование службы безопасности. Вариант выбирается на диагностике и фиксируется в договоре вместе со схемой потоков данных.
Выбор зависит от задачи, а не от предпочтений: для извлечения реквизитов из документов — специализированные модели и OCR, для работы с текстом и формулировками — большие языковые модели (в гибридном варианте YandexGPT или GigaChat, в закрытом — открытые Qwen, Llama, Mistral на вашем оборудовании), для поиска по регламентам — контур RAG поверх векторного индекса ваших документов. Привязки к одному поставщику нет: контур строится так, чтобы модель можно было заменить без переделки интеграций и интерфейса.
Модель ошибается всегда — это свойство вероятностных систем, и строить процесс в расчёте на безошибочность нельзя. Поэтому в контуре три вещи: оценка уверенности по каждому решению, обязательная ссылка на источник для ответов по регламентам и подтверждение человеком там, где решение имеет последствия. Случаи с низкой уверенностью не решаются наугад, а уходят в очередь исключений. Доля исключений измеряется и является одной из метрик приёмки: её снижение — основная работа после запуска.
Нет. Контур передаётся вместе с документацией, а типовые операции — обновление базы знаний, разбор очереди исключений, просмотр метрик — выполняются сотрудниками без технической подготовки, для этого мы делаем интерфейс и обучение. Для развития контура (подключение новых процессов, дообучение на новых примерах) нужна поддержка; её можно взять у нас от 60 000 ₽ в месяц или выполнять своими силами — код и документация у вас.
До старта фиксируются baseline и метрика приёмки: обычно это время цикла, доля операций без человека и стоимость обработки одного экземпляра. Метрики считает сам контур по журналу решений, поэтому они не зависят от того, какой отчёт мы подготовим. Если по итогам пилота эффекта нет — вы это увидите по тем же числам, что и мы, и продолжать не обязаны. Именно для этого пилот ограничен одним процессом и шестью неделями: проверить гипотезу дешевле, чем внедрять сразу.
С 1С (ERP, Управление торговлей, Документооборот, ЗУП), Bitrix24, amoCRM, SAP, Naumen Service Desk, Jira, системами ЭДО (Диадок, СБИС), почтовыми шлюзами и Exchange, мессенджерами, хранилищами документов и сканерами. Там, где есть API, работаем через него; где API нет — через выгрузки, обмен файлами или прямые запросы к базе в режиме чтения. Конкретный способ обмена для каждой системы описывается в схеме интеграции после диагностики.
У вас останутся карта процесса с числами, отчёт о достижимой точности на ваших данных, работающий пилотный контур, исходный код, схемы интеграций, документация и доступы. Ничего не отключается и не удерживается: поддержку можно не продлевать, а развитие продолжить своими силами или с другим подрядчиком. Карта процесса имеет самостоятельную ценность — с ней можно выстроить требования к любой системе, не только к ИИ.
Часто да, и обычно дело не в модели. Типичные причины неудачи: проверяли на демонстрационных примерах, а не на своих документах; автоматизировали весь процесс сразу, не имея критерия готовности; не заложили ручной разбор исключений, и качество упало после первых нетиповых случаев. На диагностике мы начинаем с разбора того, что уже было сделано: посмотреть на прежний прототип, выборку и замеры полезно, это экономит время. Если окажется, что ограничение принципиальное — данных нет или задача не того типа, — скажем прямо.
Не нашли свой вопрос? Задайте его в заявке — ответим вместе с расчётом.
Начнём с одного процесса
Опишите процесс, который съедает больше всего времени, и системы, в которых он живёт. Разберём, есть ли в нём предмет для ИИ, что можно снять автоматически и с чего начинать.
- 1 Ответим, есть ли в вашем процессе предмет для ИИ — или задачу дешевле решить интеграцией
- 2 Назовём, какие данные понадобятся для диагностики и что видно уже по вашему описанию
- 3 Скажем честно, если данных недостаточно или результат не окупится при вашем объёме операций
- 4 Предложим минимальный первый шаг вместо проекта целиком
Предпочитаете позвонить — +7 (962) 368-39-51
Пн–Пт, 10:00–19:00 МСК
Расскажите, как процесс работает сейчас
Где живут заявки, документы и согласования; что делается руками и сколько людей занято. Вернёмся с тем, есть ли в процессе предмет для ИИ и с чего начинать.