Что произошло в Nakkila Works

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

Файл «финальная_версия_2» может звучать как шутка, но угадывать по названию правильную редакцию чертежа системе нельзя.

Именно такой документный участок финская Nakkila Works, производитель резервуаров и технологического оборудования, выбрала для пилота с центром цифровых инноваций Robocoast. По опубликованному описанию European Digital Innovation Hubs Network компания обрабатывала около 200 сложных пакетов запросов на коммерческое предложение (RFQ) в год. Команда сначала разобрала фактический поток документов, затем вместе с поставщиками решения испытала автоматический приём, извлечение, классификацию и структурирование данных для существующего процесса продаж.

Организаторы кейса сообщают о сокращении времени анализа отдельных пакетов до 90% относительно ручного процесса и о снижении ошибок ручной обработки. Это результат, заявленный в описании пилота, а не обещание такой же экономии каждой мастерской. Открытой методики замеров, распределения времени по сложности запросов и стоимости внедрения в публикации нет. Поэтому на эту цифру нельзя опирать закупочный бюджет без собственного контрольного замера.

Где здесь полезен ИИ, а где достаточно правил

Самая ценная часть процесса — не «написать предложение за инженера». Машина может быстро собрать черновую опись входящего пакета: какие файлы получены, какова версия, где в документах указаны размеры, материалы, сроки и исключения. Затем система предлагает структуру для проверки специалистом. Инженер по-прежнему отвечает за техническую интерпретацию, расчёт, допущения и окончательную цену.

Робот-стажёр пусть раскладывает бумаги по полкам; подписывать смету ему рано.

Для российского небольшого производственного предприятия разумна последовательность из четырёх слоёв:

  • Входящий контур сохраняет письмо и исходные вложения без изменения, присваивает заявке номер и фиксирует отправителя, время и версию. Это обычная автоматизация, модель не нужна.
  • Парсер извлекает текст из PDF и таблиц; для сканов добавляется OCR. Таблицы и чертежи требуют отдельной проверки: видимый на картинке размер не всегда превращается в надёжное поле данных.
  • Классификатор помечает тип документа, а модель помогает найти и предложить значения для заранее заданной схемы: изделие, материал, единица измерения, количество, срок и особые условия. Каждое значение должно сохранять ссылку на исходную страницу или ячейку.
  • Экран проверки показывает человеку исходный фрагмент и предложенное поле рядом. Только подтверждённые данные переходят в CRM, ERP или расчётную таблицу. Неясные и конфликтующие значения отправляются на разбор.

Это редакционная схема для похожего пилота, а не раскрытая архитектура Nakkila Works: исходный кейс не называет конкретные модели, OCR-движок или место размещения вычислений. Такой разрыв важен. Без него легко приписать удачный результат произвольному стеку, которого в проекте могло не быть.

Какие данные понадобятся до закупки модели

Начните с 30–50 завершённых запросов разных типов, если договоры позволяют использовать их в тестовом контуре. Нужны исходные письма, все версии вложений, утверждённые расчёты и пометки о том, что эксперт действительно проверял. Обезличивание заказчиков и разграничение доступа следует решить до загрузки в какой-либо сервис. Для локального контура отдельно учитываются хранение исходников, резервные копии и журнал доступа.

На части выборки эксперт размечает эталон: список документов, требуемые поля, единицы измерения, обнаруженные противоречия и ссылки на страницы. Эта разметка дороже красивой демонстрации, но именно она позволяет измерить пропуски. Нельзя проверять систему только на десяти ровных PDF, если реальные запросы приходят сканами, архивами и таблицами с несколькими листами.

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

Пилот без долгого проекта

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

Для каждой заявки сравнивайте с ручным эталоном:

  • время от получения пакета до проверенной карточки;
  • долю правильно найденных обязательных полей и отдельно число опасных пропусков;
  • время человека на исправление черновика;
  • долю заявок, отправленных на ручной разбор;
  • стоимость обработки одной принятой карточки, включая инфраструктуру и проверку.

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

Экономика и ограничения переноса

При 200 запросах в год даже заметная экономия на каждом пакете может не окупить дорогую интеграцию. Модельный расчёт: если ручная подготовка карточки занимает 60 минут, суммарно это 200 часов в год. Если после учёта проверки экономится 40%, высвобождается 80 часов. При условной полной стоимости часа специалиста 1 500 рублей это 120 000 рублей потенциально высвобождаемого времени за год — не денежная выручка и не подтверждённый результат Nakkila Works. Из этой величины ещё надо вычесть внедрение, обслуживание, разметку, хранение и исправление ошибок. Измените любое допущение — изменится решение.

Локальная модель имеет смысл, когда коммерческие предложения и чертежи нельзя передавать во внешний сервис или поток достаточно устойчив для собственной инфраструктуры. Но «локально» не означает «бесплатно»: нужны сервер, обновления, мониторинг, контроль доступа и ответственный за качество. Если поток редкий, начните с правил, OCR и ручного подтверждения; модель добавляйте только там, где она устраняет измеримый узкий участок. RAG здесь полезен не как универсальный чат, а при сопоставлении запроса с утверждёнными каталогами, типовыми узлами и внутренними правилами расчёта — с указанием источника и версии. Агенту не стоит разрешать самостоятельно отправлять цену клиенту.

В исследовании OECD 2026 года на нерепрезентативной выборке более 2 000 МСП отмечены ограничения времени, затрат на сопровождение и нехватки навыков при внедрении ИИ. Это не оценка Nakkila Works и не статистика российского рынка, но полезное напоминание: сопровождение процесса входит в экономику наравне с ценой модели.

У Nakkila Works сложные пакеты и финансирование пилота с участием EDIH; российскому малому предприятию нельзя автоматически переносить ни размер эффекта, ни условия оплаты. Переносим принцип: сначала карта процесса и эталон, затем извлечение с проверяемыми ссылками, после этого — интеграция. Если черновая карточка не сокращает время эксперта без новых опасных ошибок, следующий шаг — улучшить документы и правила, а не искать модель крупнее.