ГК «ФОРОНЕЙ» — Материалы

Робот или найм: как директору посчитать роботизацию и где лежат 20%

2026-09-10T00:00:00.000Z

## Коротко Роботизация считается не ценником манипулятора, а сравнением двух денежных потоков: полная стоимость владения ячейкой против фонда оплаты труда участка с налогами, браком и простоями. Сверху — субсидии: в июне 2026 Минпромторг компенсировал до 20% затрат на роботов (до 80 млн ₽ на предприятие). Тот отбор закрыт, но window открывается регулярно — к нему готовятся заранее, с ТЭО на руках. ## Шаг 1. Сколько стоит участок сейчас Не зарплата оператора, а всё вместе за год: ``` ФОТ × (1 + страховые взносы) + брак + сверхурочные + текучка и обучение ``` Текучка на монотонных операциях — главная скрытая статья. Оператор паллетайзера увольняется, месяц ищем, месяц учим, всё это время линия идёт медленнее. В [расчёте LCC](/insights/lcc-iso-15686/) мы показываем тот же принцип: ценник это 35–45% полных затрат, остальное — владение. ## Шаг 2. Сколько стоит ячейка ``` CAPEX (робот + оснастка + шкаф + монтаж + ПНР) + энергия и расходники в год + сервис и ЗИП в год + простой на обслуживании в деньгах − остаточная стоимость через 7–10 лет ``` Дорогой манипулятор с дешёвым сервисом часто дешевле «скидочного» за 10 лет: переплата 15% на CAPEX закрывала больше 40% OPEX и MRO на реальных контурах. Поэтому [робота выбирают расчётом, а не каталогом](/insights/robot-selection-checklist/): момент на осях, повторяемость, reach. ## Шаг 3. Простое правило окупаемости ``` Окупаемость (лет) = CAPEX ячейки / (годовые затраты участка − годовые затраты ячейки) ``` Ориентир по типовым проектам — 6–18 месяцев. Если по вашим цифрам выходит больше трёх лет — честно скажем, что ячейка не нужна. Именно это считает [аудит за 7 дней](/razbor/): модель линии и ТЭО до контракта на железо. ## Где лежат 20%: субсидии Факты лета 2026 (проверяйте актуальность в ГИСП — окна открываются и закрываются): - Минпромторг, отбор 15–30 июня 2026: компенсация **до 20% затрат** на промышленных роботов, конвейеры, краны-штабелёры и подъёмные машины (коды ОКПД 2: 28.99.39.200, 28.99.39.210, 28.22.17.110, 28.22.14.160, 28.22.18.260). Лимит — **80 млн ₽** на предприятие, бюджет — больше **912 млн ₽**. Заявки — через ГИСП, внедрить — до 31 декабря 2026. - Трёхлетка 2026–2028: на поддержку роботизации заложено около **43 млрд ₽** (9+ в 2026, 11 в 2027, почти 23 в 2028). Цель — топ-25 стран по плотности роботизации к 2030 (сейчас 41-е место). - Займы Фонда развития промышленности на модернизацию — под **3% и 5%** годовых. - Сеть региональных центров робототехники: 20 к концу 2026, ещё 10 в 2027 — там консультируют и помогают с внедрением. Важно: субсидия возмещает затраты на оборудование из перечня, а не «проект целиком». Робототехнические комплексы, ячейки и линии целиком в код 28.99.39.200 **не входят** — возмещаются роботы и периферия по списку. ТЭО и спецификация должны лечь на эти коды заранее — ещё одна причина считать до закупки, а не после. ## Когда робот не нужен - Такт низкий и рваный: сначала [порядок в процессе](/insights/bpmn-formal-chaos/), иначе автоматизируете хаос. - Изделие меняется каждую неделю, партии мелкие — оснастка и переналадка съедят эффект. - Нет человека, который примет ячейку: оператор и механик нужны и после пуска, просто другие. ## Что дальше Прикиньте порядок цифр на [калькуляторе ROI](/roi-calculator/), потом приходите с планом цеха на [аудит участка](/razbor/) — через 7 дней будет ТЭО, с которым можно идти и к собственнику, и за субсидией.

Железо не бонус к лицензии ДОКА

2026-08-22T00:00:00.000Z

Когда говорим «модели на серверах завода», речь про стойку. Лицензия и работы по [ДОКА](https://дока.рус/) не включают сервер, GPU и СХД. В смете ПО: пилот, внедрение, интеграция с Альта-ГТД / 1С, регламент. Ориентиры на [дока.рус/services](https://дока.рус/services/). Отдельно заказчик считает хост под vision и три роли и диск под пакеты инвойсов. Плюс кто дежурит, когда контур «не отвечает». Если подходящий хост уже есть, используем. Если нет, требования фиксируем после оценки объёма. Это CAPEX или аренда заказчика. Наумов на своей площадке отдельно пишет: локальный стек без as-is даёт безопасный бред. Чеклист: [aiprocesses.ru/insights/as-is-checklist](https://aiprocesses.ru/insights/as-is-checklist/). Наш разбор on-prem стека: [/services/local-ai/](/services/local-ai/). *Аксёнов Юрий Васильевич*

Как ДОКА готовит XML из инвойса: четыре шага и три роли

2026-08-15T00:00:00.000Z

[ДОКА](/projects/doka/) это продукт ГК «ФОРОНЕЙ»: инвойс на десятки страниц становится спецификацией, кодом ТН ВЭД ЕАЭС и проектом XML для Альта-ГТД. Подачу делает декларант. Модели живут на сервере заказчика. Правообладатель ООО «ГК Фороней». Автор: Аксёнов Юрий Васильевич. Свидетельство Роспатента №2026681995. Каноническое описание метода на сайте продукта: [дока.рус/method/](https://дока.рус/method/). ## Зачем отдельный контур Инвойсы из Китая, Турции и Ближнего Востока приходят на 30–50 страниц. Коды ТН ВЭД либо нет, либо они в зарубежной схеме. Ручной перенос в Альта-ГТД занимает часы. Ошибка в одном знаке кода даёт КТС, простой на СВХ и риск по ст. 16.2 КоАП РФ. Публичный чат для таких файлов обычно закрыт политикой ИБ и 152-ФЗ. ДОКА ставится on-prem: инвойсы не уезжают во внешний API. ## Четыре шага ### 1. Извлечение из многостраничных PDF Алгоритм читает таблицы, сканы, спецификации и MSDS. Цель: не сдвинуть строки и не потерять артикул. На плотных и размытых сканах включается визуальный анализатор геометрии таблиц. Вход ниже 300 DPI ломает этот шаг. Про это отдельно: [скан и OCR](/insights/doc-preparation/). ### 2. Три роли на одном инвойсе Каждую позицию смотрят три независимых контура: - **Юрист** сверяет нетарифные ограничения, акты ЕЭК и приказы ФТС. - **Инспектор** подбирает код ТН ВЭД ЕАЭС по базе решений ФТС и пишет, почему соседняя субпозиция отброшена. - **Координатор** сводит риски КТС и собирает итоговый вердикт. Три контура спорят между собой и оставляют текст для человека. Одну модель, которая «угадала HS», сюда не ставим. ### 3. Платежи и риски КТС К коду привязываются ставка пошлины и НДС. Цена сверяется со средневзвешенным профилем риска. Декларант видит, где инспектор, скорее всего, задаст вопрос, до подачи. ### 4. XML и выгрузка Система собирает schema-валидированный проект XML для Альта-ГТД (ориентация также на Контур.Декларант) и спецификацию в 1С:ERP / 1С:УТ. Финальная проверка и подпись остаются у специалиста. ## Что измеряем На тестовых прогонах 32-страничный инвойс уходит из контура за 5–6 минут. Ручной разбор того же объёма у декларанта обычно 3–4 часа. Это время подготовки проекта, не юридическая приёмка и не гарантия нулевой КТС. Старт без выноса ваших файлов в публичное облако: [разбор 5 инвойсов](https://дока.рус/razbor/) на сайте продукта. ## Кто за что отвечает | Роль | Что делает | |------|------------| | ГК «ФОРОНЕЙ» | Правообладатель, внедрение, контур на серверах завода | | Аксёнов Ю.В. | Автор продукта, постановка внедрения | | Наумов П.В. | Архитектура процесса и локального ИИ, [aiprocesses.ru](https://aiprocesses.ru/) | | Декларант | Проверка кода, Графы 31 и подача | ## Читать дальше - Кейс на этом сайте: [ДОКА, инвойс → XML](/projects/doka/) - Метод на сайте продукта: [четыре модуля и HowTo](https://дока.рус/method/) - О продукте: [дока.рус/about/](https://дока.рус/about/) - Чеклист as-is до любого пилота: [Наумов, aiprocesses.ru](https://aiprocesses.ru/insights/as-is-checklist/) и [перепечатка здесь](/insights/as-is-checklist/)

Готов ли завод к ИИ? Семь вопросов до закупки

2026-07-23T00:00:00.000Z

Текст [Наумова Павла Владимировича](https://aiprocesses.ru/about/), архитектора системы [ДОКА](https://дока.рус/). Впервые опубликован на [aiprocesses.ru](https://aiprocesses.ru/insights/as-is-checklist/). Здесь та же последовательность: сначала факт процесса, потом модель. ## Зачем чеклист Без as-is пилот ИИ отвечает по регламенту, которым никто не пользуется. Вопросы, которые автор задаёт (и которые можно задать себе) **до** выбора модели и закупки GPU. ## 1. Границы процесса - Где процесс **начинается** и чем **заканчивается** для вас? - Кто заказчик результата (не «инициатор цифровизации», а тот, кто пользуется выходом)? - Что считается браком / срывом / возвратом? Если границы плывут («ну это весь завод»), сузьте до одного потока. ## 2. Люди и роли - Кто делает шаг руками? - Кто подписывает / останавливает? - Кто подменяет, когда основного нет? - Где решение «по жизни» принимает не тот, кто в регламенте? ## 3. Системы и теневые контуры - Что в ERP / СЭД / PLM / MES? - Что в Excel, почте, мессенджере, бумаге? - Где правда, если система и человек расходятся? Именно «теневые» места чаще всего едят время, и именно их забывают в ТЗ на ИИ. ## 4. Данные - В каком виде вход: скан, чертёж, строка в БД, устный запрос? - Что структурировано, что нет? - Какие справочники живые, какие мёртвые? - Что **нельзя** выносить из контура? ## 5. Время и качество - Нормативное время шага vs фактическое? - Где самые длинные ожидания? - Какие ошибки повторяются? - Как сейчас меряют «хорошо / плохо»? Без хотя бы грубой метрики пилот нельзя честно закрыть. ## 6. Исключения - 20% случаев, которые ломают «идеальный» сценарий? - Сезонность, особые заказчики, «сделайте вчера»? - Обходы, которые все знают и никто не пишет? ИИ, обученный только на «счастливом пути», бесит в первый же понедельник. ## 7. Готовность к пилоту - Есть ли хозяин процесса на связи? - Дадут ли доступ к системам и примерам (в контуре)? - Согласны ли на узкие границы пилота? - Что будет считаться успехом через 4–8 недель? ## Как использовать Пройдите список на одном созвоне. Пустой пункт это место работы до ИИ, а не оценка «как плохо ответили». Дальше по методу автора: [метод APRE](https://aiprocesses.ru/method/), [когда нужен локальный ИИ](https://aiprocesses.ru/insights/local-ai-when-needed/). На этом сайте та же логика в разборе [BPMN до робота](/insights/bpmn-formal-chaos/) и в продукте [ДОКА](/projects/doka/). *Наумов Павел Владимирович, Санкт-Петербург. Текст можно цитировать; первоисточник: [aiprocesses.ru/insights/as-is-checklist/](https://aiprocesses.ru/insights/as-is-checklist/).*

Реконструкция процессов с ИИ: сначала as-is, потом модель

2026-07-23T00:00:00.000Z

Текст [Наумова Павла Владимировича](https://aiprocesses.ru/about/), архитектора системы [ДОКА](https://дока.рус/). Впервые опубликован на [aiprocesses.ru](https://aiprocesses.ru/insights/what-is-apre/). Здесь та же последовательность, которой мы пользуемся на внедрениях: сначала факт процесса, потом контур. ## Коротко **Реконструкция бизнес-процессов с ИИ** (часто *AI Process Reverse Engineering*, APRE): сначала аудируют, как работа устроена на практике, затем перестраивают процесс и только потом ставят локальный ИИ туда, где он ускоряет, а не «просто есть». Не путать с reverse engineering **программ**: здесь не вскрывают чужой код. «Обратный ход» только к процессу: от факта работы к модели. На этом сайте та же логика в разборе [BPMN до робота](/insights/bpmn-formal-chaos/) и в [чеклисте as-is](/insights/as-is-checklist/). ## Зачем это ГК «ФОРОНЕЙ» Большинство «ИИ на заводе» ломается не на выборе модели: - в чат кладут регламент, которым никто не пользуется; - обходят Excel, почту и «так исторически сложилось»; - данные уезжают во внешний сервис вопреки политике; - ждут, что нейросеть «сама поймёт завод». Поэтому линию, ячейку и инвойс мы считаем до закупки железа. [ДОКА](/projects/doka/) выросла из того же правила: сначала кто переносит строки в Альта-ГТД, потом три роли на GPU заказчика. ## Четыре шага ### 1. Как есть (as-is) След процесса: системы, документы, логи, интервью, исключения. Нужен факт, без обвинений. Вопросы в [чеклисте](/insights/as-is-checklist/). ### 2. Модель Роли, входы/выходы, системы, правила, развилки. Для линии это BPMN с Pools & Lanes. Для ВЭД: кто готовит Графу 31 и кто подписывает декларацию. ### 3. Как должно (to-be) Где скрипт, где ИИ, где только человек. Не «цифровизация отдела». ### 4. Пилот в контуре Один процесс, одна метрика, свои или согласованные серверы. Решение «идём / стоп» по факту, не по слайду. ## Как это стыкуется с ДОКА На сайте продукта метод разобран четырьмя модулями: [дока.рус/method/](https://дока.рус/method/). На этом сайте: [как ДОКА готовит XML](/insights/doka-invoice-xml/). Архитектор пишет о продукте у себя: [aiprocesses.ru/insights/doka-ved/](https://aiprocesses.ru/insights/doka-ved/). ## Читать дальше - Оригинал метода: [aiprocesses.ru/insights/what-is-apre/](https://aiprocesses.ru/insights/what-is-apre/) - Когда локальный ИИ нужен: [aiprocesses.ru/insights/local-ai-when-needed/](https://aiprocesses.ru/insights/local-ai-when-needed/) - Наш контур: [локальный ИИ](/services/local-ai/)

Скан ниже 300 DPI: OCR не спасёт

2026-07-12T00:00:00.000Z

## Коротко Без предобработки OCR и мультимодальная модель на реальных сканах дают плохую точность. Пайплайн, который ставим на контурах ВЭД-документов: 1. Оцифровка не ниже 300 DPI, вход PDF/A или TIFF. 2. Deskew и бинаризация в OpenCV: наклон ломает сегментацию строк. 3. Сегментация структуры LayoutLMv3: зоны, таблицы, пары «ключ-значение». 4. Распознавание: лёгкий CRNN-конвейер для CPU-инференса, полностью локально. 5. Бизнес-валидация: контрольные суммы, сверки, справочники. Отклонения уходят человеку. ## Почему всё разваливается именно на данных Когда ставим ИИ на счета-фактуры, таможенные декларации или спецификации, модель класса LayoutLM или OCR-движок часто не видит заплывшие цифры и кривые таблицы. Проблема почти никогда не в самой модели. На вход уходит мусор. За полтора года работы с документами ВЭД мы убедились: 70 % качества даёт предобработка, а не очередная модель. Контур: скан → очистка → структура → распознавание → валидация бизнес-правилами → экспорт в 1С/ERP. ## Этап 1. Оцифровка по промышленным стандартам Разрешение ниже 300 DPI считаем браком. На 150 DPI границы символов пропадают уже на бинаризации. Нейросеть это не восстановит «по смыслу»: для неё это шум. Входящий формат: несжатый PDF/A или TIFF. Сжатые JPEG внутри PDF (а они повсеместно) дают блочные артефакты, которые адаптивные пороги читают как шум. Если сканирование идёт офисным сканером «как получится», на аудите берём 2–3 типовых листа, прогоняем через конвейер и только потом согласуем ТЭО. Иначе потом выясняется, что «у нас бумага другая». ## Этап 2. Коррекция наклона и бинаризация в OpenCV Отсканированные листы имеют наклон (skew) в 1–5 градусов. Человек этого не замечает. Сегментатор строк уже нет: строки плывут, токены разваливаются. Рабочий срез: deskew через `minAreaRect` плюс адаптивная бинаризация. На части контуров вместо неё стоит конвейер под GLM-OCR, логика та же: ```python import cv2 import numpy as np def deskew_and_threshold(img_path): # Загружаем в градациях серого img = cv2.imread(img_path, cv2.IMREAD_GRAYSCALE) # 1. Оценка угла наклона по инвертированному содержимому coords = np.column_stack(np.where(img < 255)) angle = cv2.minAreaRect(coords)[-1] if angle < -45: angle = -(90 + angle) else: angle = -angle # Поворот на оценённый угол (h, w) = img.shape[:2] center = (w // 2, h // 2) M = cv2.getRotationMatrix2D(center, angle, 1.0) rotated = cv2.warpAffine( img, M, (w, h), flags=cv2.INTER_CUBIC, borderMode=cv2.BORDER_REPLICATE, ) # 2. Адаптивная бинаризация (ориентир — Sauvola-порог) thresh = cv2.adaptiveThreshold( rotated, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 25, 9, ) return thresh ``` Нюансы, о которых молчат туториалы: - `minAreaRect` считает угол по облаку тёмных пикселей, поэтому важно инвертировать условие (`img < 255`), иначе получите угол по белым полям; - адаптивный порог (блок 25×25, C=9) живёт там, где документ «желтизна + пятна» хуже, чем глобальный OTSU; - для документов с двойной печатью (двусторонние сканы) добавляем этап удаления проступлений через морфологию. ## Этап 3. Сегментация структуры (LayoutLMv3) Чистый текст без ролей не годится: дата договора может приехать к неверному номеру. Изображение режем на семантические зоны. Здесь LayoutLMv3: она смотрит на текстовый слой, координаты bounding box'ов и визуальные фичи (CNN-ветка). На наших сборках (таможенные декларации, ГТД, спецификации) стабильно выходит до 98,4 % точности локализации таблиц и привязки пар «ключ-значение». Система отличает «просто таблицу» от привязки даты к конкретному номеру договора. На выходе список зон: `{type: "table" | "header" | "signature_zone" | ...}`, bbox, порядок чтения. Дальше по зонам идёт распознавание. ## Этап 4. Распознавание (OCR) Для цифровых документов (счета, ТТН) держим быстрый и дешёвый вариант: CRNN-конвейер (Connectionist Temporal Classification + LSTM), оптимизированный под CPU-инференс. Для нормальных PDF достаточно одного инференса на страницу. Заказчики с 152-ФЗ и объектами КИИ просят одно и то же: весь инференс локально, на сервере предприятия. Облачный OCR не ставим. Номера контрактов и реквизиты контрагентов не должны покидать контур. Конвейер из этапов 1–4 собираем в один Docker-образ и поднимаем на том же GPU/CPU-ноде, где живёт RAG-контур. ## Этап 5. Бизнес-валидация Распознанный текст в 1С сразу не кладём. Сначала бизнес-логика. Минимальный набор проверок в каждом проекте: - контрольные разряды ИНН (10 или 12 цифр) и КПП: ошибка в одном разряде ловится сразу; - сопоставление кодов ТН ВЭД со справочником ЕЭК в реальном времени (ловит опечатки-соседи); - математическая сверка: сумма без НДС + НДС = итого к оплате, с допуском на округление. Всё, что не прошло, складывается в лог на ручную модерацию. Оператор видит конкретную зону документа с подсветкой противоречия, а не строку «ошибка №123». Успешно прошедшие данные уходят в XML-схему для разгрузки в 1С/ERP. ## Чек-лист перед стартом | # | Вопрос | Зачем | |---|--------|-------| | 1 | Сканируем сами или нам присылают файлы? | Контроль DPI/формата на входе | | 2 | Есть ли «красные» типы документов (кривые сканы, рукописные пометки)? | Решает, нужен ли ручной контур и его доля | | 3 | Где живут данные заказчика? | Локальный инференс (наш стандарт) или изолированный контур | | 4 | Что считать успехом: % автопропуска без модерации? | Закрепляем метрику в ТЭО до пилота | ## Вывод На реальных проектах до 80–90 % документов после такого контура проходят без человека. Дальше держим стандарты на входе, метрику качества и очередь, куда складывается то, в чём модель не уверена. Все этапы работают локально. Данные предприятия остаются в контуре предприятия.

Почему автоматизация не чинит хаос: сначала процесс, потом ИИ

2026-07-05T00:00:00.000Z

## Коротко Автоматизировать можно только то, что описано. Методика, которую гоняем на внедрениях: 1. Формализация. BPMN-схема с явными зонами ответственности (Pools & Lanes). Становится видно, где документы зависают в ожидании подписи и где рутина. 2. Дедупликация. Ищем и убираем дублирующие цепочки, которые едят время и расходятся по данным. 3. Метрика PCE (Process Cycle Efficiency): `PCE = (Value-Added Time / Total Cycle Time) × 100%`. На неоптимизированных предприятиях PCE редко превышает 5–7 %. С ИИ-шлюзами может подняться до 45–60 %. 4. ИИ в пайплайне. В процессных движках вроде Camunda BPM искусственный интеллект это Service Task: REST-вызов к микросервису распознавания. 5. Эффект в цифрах. Вместо ручной проверки входящих счетов модель за 2 секунды извлекает реквизиты, сверяет цены со справочником контрактов и закрывает шлюз «Авто-согласовано». Экономия до 90 % рабочего времени сотрудников. ## Почему хаос не автоматизируют, а «цифровизируют» Хаос на предприятии невозможно автоматизировать. Если наложить софт или ИИ на непрописанный процесс, бумажные пробки получают интерфейс, а очередь остаётся. Только теперь она электронная. Внутри мы это называем цифровой имитацией неэффективности. Сначала описание, потом автоматизация. Моделирование почти всегда дешевле, чем доводить до продакшена контур, в котором неясно, где процесс тормозит, кто за что отвечает и какие шаги создают ценность. Неописанный процесс нельзя ни оптимизировать, ни измерить. BPMN 2.0 (Business Process Model and Notation) это математический язык описания логики выполнения операций. Схему одинаково читает менеджер, исполнитель и процессный движок. Формализация даёт и договорённость, и исполнимый артефакт. ## Зачем нужна формализация BPMN-схемы закрывают то, без чего дальше не двигаемся. Явное разграничение зон ответственности (Pools & Lanes). На дорожках видно, какой шаг чей и кто кому передаёт. Частая жалоба: заказ лежит в отделе, а чья подпись непонятно. На схеме это место, где поток выходит из одной дорожки и не входит в другую. Его сразу чинят. Узкие места. Документы зависают в ожидании ручной подписи, возврата согласующего или освобождения ресурса. В BPMN такие участки не прячутся в коробке: это элементы с несоразмерно большим временем пребывания. Рутинные шаги, которые можно отдать алгоритмам: распознавание документов, сверка реквизитов, типовые проверки. На таких этапах экономия от автоматизации максимальна, а риск минимален. > Формализацию начинаем с as-is, не с «как должно быть». As-is рисуем так, как процесс реально работает, включая ручные обходы и «передаём по телефону». Вопросы к as-is задаёт [Наумов](/insights/as-is-checklist/); мы по этой схеме уже ставим движок. To-be, оторванный от реального процесса, никто не сверяет с production-контуром. Он становится украшением. ## Как мы строим модель: от схемы к процессному движку Минимально полная BPMN-модель, которую мы готовы передавать в движок, содержит: - Pools & Lanes, матрицу ответственности. Дорожка это роль или сервис безымянных систем. Если у шага нет дорожки, процесс ещё не описан. - События старта и завершения с понятными условиями: что запускает процесс и при каком состоянии он считается закрытым. - Задачи пользовательские (делает человек) и сервисные (делает система). Для каждой фиксируем, что на входе, что на выходе и кто отвечает за шаг. - Шлюзы: точки ветвления по условию («ОК / не ОК») или параллельные ветки. Именно шлюзы определяют, куда ИИ может дописать процесс. Модель уверена: идёт по автоветке. Нет: уходит на человека. - Таймеры и сообщения: этапы ожидания (дольше SLA, эскалация) и внешние триггеры. По готовой модели прогоняем сценарий. Сначала на бумаге, потом в движке. По шагам проверяем времена каждого этапа и только потом передаём схему платформе. Процессные движки вроде Camunda BPM принимают BPMN-модель и превращают её в работающие экземпляры, но только если нотация закрывает все ветки. Незакрытый шлюз или задача без владельца превращаются в зависшие токены в мониторинге. Отдельный шаг: вылавливание дублирующих цепочек. Одна и та же или похожая операция выполняется в разных точках процесса разными ролями. Копирование данных, повторные сверки, повторное согласование того, что уже согласовано. Это лишнее время цикла и расхождение данных: два контура видят разные значения одного поля. Дубли склеиваем в один шаг либо явно отдаём ответственность в одну дорожку. И только потом схема идёт в движок. ## Метрика PCE (Process Cycle Efficiency) Когда модель готова, эффективность считаем не по ощущениям, а показателем PCE (Process Cycle Efficiency): ```text PCE = (Value-Added Time / Total Cycle Time) × 100% ``` Value-Added Time это время непосредственной полезной работы (составление чертежа, сварка). Total Cycle Time это общее время выполнения процесса, включая простои, очереди и согласования. Два вывода из работы с этой метрикой: - на неоптимизированных предприятиях PCE редко превышает 5–7 %. Это baseline, не повод для паники. Процесс физически работает малую долю времени, остальное он стоит в очередях; - автоматизация рутинных шагов, включая ИИ-шлюзы, сокращает Total Cycle Time без потери полезного времени. Так поднимаем PCE, не трогая саму логику работы. Поэтому такие шаги берём первыми. Внедрение ИИ-шлюзов позволяет поднять показатель до 45–60 %. Как считаем на практике. Процессный движок ставит метки времени по входам и выходам каждого элемента. Total Cycle Time раскладывается на работу (задачи, шлюзы) и ожидание (таймеры, очереди). Если движка нет, берём логи ДЭД/СЭД с временными метками согласований. Точность важнее сопоставимости: «до» и «после» меряем одним инструментом, иначе сравнивать нечего. ## Как интегрировать ИИ в BPMN-пайплайн В процессных движках вроде Camunda BPM искусственный интеллект это системная задача (Service Task), которая ходит к микросервису распознавания по REST API. У ИИ есть место в схеме, тайм-аут, запасной маршрут и статус в мониторинге. Он перестаёт быть сторонним сервисом рядом. Типовой пример из наших проектов: входящие счета от поставщиков. Вместо ручной проверки процесс направляет PDF в ИИ-модель. За 2 секунды модель извлекает реквизиты, сверяет цены со справочником контрактов и пропускает процесс дальше по шлюзу «Авто-согласовано». Экономия до 90 % рабочего времени сотрудников. Нештатный кейс процесс не ломает: шлюз переводит заявку в ручной контур. Оператор видит не голый файл, а конкретное расхождение (цена вне контракта, несовпадение сумм). Перед тем как вешать ИИ-шлюз на этап, проверяем четыре вещи: - формат ввода достаточно стабилен. Если входящие документы слишком разнородны по структуре, сначала приводим вход в порядок на предыдущем этапе, иначе модель будет творчески расставлять поля; - есть бизнес-правило «правильности». ИИ без бизнес-валидации (контрольные суммы, сверки со справочниками) производит уверенный мусор; - спроектирован fallback. Куда и к кому уходит процесс при низкой уверенности. Пороги автопропуска прописаны явно, не по ощущениям; - инференс в локальном контуре. Для корпоративных данных микросервис живёт на сервере предприятия. Содержимое документов не уходит в сторонние облака. > Пример из практики ГК «ФОРОНЕЙ»: тот же паттерн закрывали на потоке таможенных документов. Движок отдаёт скан микросервису распознавания, бизнес-валидация сверяет реквизиты, дальше автоподтверждение или оператор. На счетах поставщиков то же самое. Менять нужно механизм передачи задачи (Service Task + REST + fallback), не «робота». ## Как начать: четыре шага 1. Выбрать один процесс с измеримым циклом. Не «цифровизацию отдела» целиком. 2. Построить as-is в Pools & Lanes с владельцами шагов и зафиксировать время каждого этапа. 3. Посчитать baseline PCE и выписать топ ожиданий и дублирующих цепочек. 4. Спроектировать to-be с ИИ-шлюзами на рутинных сервисных задачах, отсимулировать и посчитать новый PCE. Если PCE не вырос на бумаге, процесс не готов к автоматизации. Первая оптимизация дешевле любой нейросети. ## Итог Схема делает видимыми зоны ответственности, очереди и дубли. PCE даёт единую мерку до и после. Процесс, который не умеют описать, нельзя ни оптимизировать, ни автоматизировать. To-be без as-is остаётся украшением. ИИ в такой модели это Service Task, микросервис и шлюз с fallback. Точка входа одна: as-is, времена, baseline PCE. Потом to-be с ИИ-шлюзами на рутине.

Как выбрать робота и не переплатить за лишние оси?

2026-06-28T00:00:00.000Z

## Коротко Манипулятор выбирают расчётом. Ошибка потом вылезает износом редукторов или тем, что фланец не достаёт до детали. Чек-лист, который гоняем до заказа: 1. Масса груза и момент инерции захвата: `J = m × d² + J_c`, где `d` это смещение центра тяжести от фланца, `J_c` это собственный момент инерции гриппера. Суммарный момент не должен превышать паспортные ограничения осей `J5` и `J6`. 2. Повторяемость позиционирования (Repeatability). Не путать с абсолютной точностью. Для сварки и сборочных прецизионных узлов выбирают модели ≤ ±0.02 мм (серия KUKA KR AGILUS, Fanuc LR Mate). 3. Район рабочей зоны (Reach) и сингулярности. Проектирование ячейки должно исключить траектории, проходящие через точки, где оси выстраиваются в линию. 4. Сравнение брендов. KUKA, Fanuc, ABB закрывают разные trade-off. Выбор делаем под конкретную ячейку, не под «лучший бренд». ## Почему выбор это расчёт, а не просмотр каталога Выбор робота-манипулятора это инженерный расчёт. Если взять модель из каталога «на глаз», робот первые месяцы как-то работает. Потом изнашиваются редукторы осей, падает точность позиционирования или манипулятор не достаёт до детали на конвейере. Это закладывается ещё на этапе выбора: нагрузка на оси, повторяемость под конкретную операцию и геометрия рабочего пространства. Отдельная тонкость: номинал из каталога и реальная работа. Паспортная грузоподъёмность и охват это опорные данные на конкретном расстоянии центра тяжести. Ваша ячейка всегда живёт не в эталонном положении. Поэтому расчёт начинается не с выбора марки, а с фиксации задачи в числах: что берём, где центр масс, каковы скорость, точность и геометрия ячейки. ## 1. Масса груза и расчёт момента инерции захвата Номинальная грузоподъёмность робота (например, 10 кг) указывает на максимальную массу на фланце при определённом расстоянии центра тяжести (CoG) от оси вращения 6-й оси. Это первая ловушка каталога. «10-кило» манипулятор с коротким штатным гриппером перестаёт быть «10-кило», как только вы дооборудуете его длинной оснасткой. Расстояние `d` определяет момент на осях. Считать нужно момент инерции, не саму массу. Расчёт момента инерции груза: ```text J = m × d² + J_c ``` где: - `m` это масса груза; - `d` это смещение центра тяжести относительно фланца осей; - `J_c` это собственный момент инерции самого захватного устройства (гриппера). Если суммарный момент превысит паспортные ограничения осей `J5` и `J6` (двух осей, наиболее нагруженных при вращательных движениях), робот будет уходить в ошибку перегрузки при резких разворотах. Заметьте квадрат на `d`: удвоенная длина захвата даёт кратный рост момента. «Немного вытянуть руку» стоит не денег за оснастку, а другого класса манипулятора. Практика, которую закладываем в каждый расчёт: - CoG берём из замера, не из TDS. Масса и смещение центра тяжести фиксируются на финальном комплекте «гриппер + адаптер + типичная заготовка». В каталоге гриппера центр масс указан как в эталонном исполнении. С вашей оснасткой он будет другим, и ошибка в `d` квадратично уходит в момент. - Отдельно считаем статику и динамику. Статика: удержание и балансировка в позах. Динамика: развороты с ускорениями при производственном такте. Манипулятор, который держит деталь в покое, может не дотягивать по динамике до требуемого такта именно из-за динамического момента. На него первым отзывается редуктор, не контроллер. - Выбираем по минимальному запасу по траектории. Строим таблицу «поза → `d` → `J` → запас до ограничения `J5`/`J6`». Минимальный запас по всем позам становится самым слабым местом ячейки. Если он тонкий, меняем не раскладку, а класс манипулятора или схему захвата. ## 2. Повторяемость позиционирования (Repeatability) Не путать с абсолютной точностью. Повторяемость это способность манипулятора возвращаться в одну и ту же точку миллионы раз подряд. Прикладывали деталь в точке A и снимаете её из A с разбросом в пределах объявленного значения. Абсолютная точность это попадание в заданную точку с первого раза. В производственной ячейке её обычно закрывает калибровка и система визуализации. Для высокоточных задач (сварка, сборка прецизионных узлов) выбирают модели с повторяемостью ≤ ±0.02 мм, например серия KUKA KR AGILUS или Fanuc LR Mate. Критерий здесь допуск операции, не «чем точнее, тем лучше». Если сборка допускает зазор в разы больше, переплата за повторяемость даёт неоправданный класс манипулятора. В наших проектах допуск операции фиксируется в ТЗ до выбора модели. Тогда повторяемость берётся как «допуск + запас», а не как маркетинговая опция. ## 3. Анализ рабочей зоны (Reach) и сингулярности Огибающая сфера из каталога не значит, что любая точка внутри неё одинаково полезна. Внутри рабочей зоны робота существуют особые точки, сингулярности осей: когда две оси выстраиваются в одну линию и для продолжения движения математический расчёт требует бесконечной скорости вращения сустава. Вблизи сингулярностей манипулятор замедляется, траектории искажаются, а на осях возникают избыточные моменты. Проектирование ячейки должно исключать прохождение траектории через точки сингулярности. Как проверяем: берём не углы зоны, а реальные производственные пути (забор, транспортировку, установку, разворот) и прогоняем их в симуляторе производителя на производственной скорости. Если где-то траектория проседает по скорости или контроллер показывает близость к сингулярности, точку меняем перестановкой оснастки, поворотом оси базирования или другим коридором движения. ## Сравнительный анализ ведущих брендов | Производитель | Преимущества | Недостатки | |---|---|---| | **KUKA (Германия)** | Отличный софт (KRL), лёгкость интеграции с внешними сенсорами, высокая траекторная точность. | Высокая стоимость оригинальных запчастей. | | **Fanuc (Япония)** | Экстремальная надёжность «железа», фирменные встроенные системы зрения (iRVision). | Устаревший интерфейс пульта программирования (Teach Pendant), закрытая экосистема софта. | | **ABB (Швеция)** | Алгоритмы плавности движения TrueMove и QuickMove, мощный софт RobotStudio. | Сложность настройки интерфейсов для несведующих специалистов. | Комментарии к таблице из практики выбора: - у KUKA KRL и интеграция с сенсорами решают многое в ячейках с vision-контролем и коллаборацией. Стоимость оригинальных запчастей это строка в LCC владения, не пункт «минус» в презентации. См. [статью про жизненный цикл](/insights/lcc-iso-15686/); - у Fanuc iRVision это зрение из коробки, сокращающее интеграцию. Закрытая экосистема софта это риск при смене интегратора или переходе на внутренние компетенции; - у ABB TrueMove/QuickMove это про цикл-тайм как bottleneck. Сложение интерфейсов дороже, но окупается, если у клиента есть сильная интеграционная команда. ## Итоговый чек-лист выбора | № | Пункт | Что проверять / считать | Критерий «прошло» | |---|---|---|---| | 1 | Грузоподъёмность | `m`, `d` (замер CoG), `J_c` захвата | `J = m × d² + J_c` с запасом ниже лимитов `J5`/`J6` | | 2 | Повторяемость | Допуск операции против класса модели | Объявлено ≤ ±0.02 мм для высокоточных задач | | 3 | Рабочая зона | Геометрия ячейки, зоны загрузки/выгрузки, безопасность | Все точки траектории внутри полезной зоны, а не «огибающей» | | 4 | Сингулярности | Реальные пути движения на рабочей скорости | Ни одна производственная траектория не проходит через точку сингулярности | | 5 | Бренд/экосистема | Сенсоры, vision, сервис, внутренние компетенции | Trade-off бренда закрывают требования ячейки, а не наоборот | > Наблюдение из проектов ГК «ФОРОНЕЙ»: почти всегда решающим пунктом чек-листа оказывается замер CoG против каталога. Расчёт по TDS гриппера и расчёт по фактической оснастке дают разные классы манипулятора. Прогоняем оба. Если расхождение есть, покупаем под худший расчёт. ## Итог Манипулятор выбирается расчётами: момент инерции (`J = m × d² + J_c` против лимитов осей `J5`/`J6`), повторяемость под допуск операции и рабочая зона, проверенная на сингулярности по реальным траекториям. Номинал из каталога и огибающая из паспорта это входные данные. Дальше сравнение брендов: KUKA, Fanuc, ABB каждый закрывает свой trade-off, и выбор делается под конкретную ячейку. Чек-лист целиком в числах можно защитить в бюджете.

CAPEX это 40% чека. Остальное считает LCC

2026-06-23T00:00:00.000Z

## Коротко На ценник внедрения смотрят все. По ISO 15686-5 железо это 35–45% полной стоимости жизни контура. Остальное: энергия, сервис, простой, демонтаж. 1. **C (CAPEX):** закупка, логистика, монтаж, лицензии; 2. **Q:** проект, согласование, ПНР; 3. **Ops:** энергия, расходники, операторы; 4. **M (MRO):** плановый сервис, запчасти, аварии; 5. **D:** демонтаж и утилизация. ## Формула ``` LCC = C + Q + Ops + M + D ``` Деньги через год дешевле сегодняшних. Затраты года `t` приводят к сегодняшней стоимости: ``` PV = Cost_t / (1 + r)^t ``` `r` это ставка дисконта, которую утверждает финдиректор, не «средняя по отрасли». ## Зачем это на аудите ячейки Дорогой манипулятор с дешёвым сервисом и меньшим простоем часто дешевле «скидочного» за 10 лет. Переплата 15% на CAPEX на реальных контурах закрывала больше 40% OPEX и MRO. Считаем LCC до контракта на железо. Иначе покупают ценник, а платят простой.

Какая сделка стоит времени менеджера? Считает скоринг в CRM

2026-06-18T00:00:00.000Z

## Коротко «Холодный / горячий» глазами менеджера теряет крупные контракты. Модель считает вероятность закрытия по сумме, отрасли, числу касаний и длине цикла. Цепочка: CRM (Битрикс24), приём вебхука на FastAPI, инференс LightGBM. ## Инференс ```python from fastapi import FastAPI, HTTPException from pydantic import BaseModel import joblib import numpy as np app = FastAPI() model = joblib.load("models/lightgbm_scoring.pkl") scaler = joblib.load("models/scaler.pkl") class DealData(BaseModel): deal_sum: float client_industry_code: int touchpoint_count: int cycle_days: int @app.post("/api/score") def get_deal_score(data: DealData): features = np.array([[ data.deal_sum, data.client_industry_code, data.touchpoint_count, data.cycle_days, ]]) probability = model.predict_proba(scaler.transform(features))[0][1] return {"probability": float(probability)} ``` ## Правило очереди - вероятность > 70%: менеджер берёт первым; - < 15%: авторассылка, не живой звонок. На рабочих воронках это давало +18–24% к закрытию. Модель расставляет очередь: куда звонить первым, куда достаточно авторассылки.

Сколько держать на складе? Считает модель, а не правило Уилсона

2026-06-14T00:00:00.000Z

## Коротко EOQ Уилсона ломается, когда спрос скачет и поставка едет не в тот день. Тогда это MILP: целые партии, задержка, штраф за дыру на сборке. Пусть `I_t` запас на конец дня, `X_t` заказ, `d_t` спрос, `h` хранение, `p` штраф дефицита, `L` lead time. ``` min ∑ (h · I_t + p · shortage_t) I_t = I_{t-1} + X_{t-L} − sales_t X_t ≥ 0, кратно MOQ ``` ## Решатель ```python import gurobipy as gp from gurobipy import GRB m = gp.Model("Inventory_Optimization") T = 30 demand = [120, 150, 100, 90, 110, 130] * 5 h, p, lead_time = 5.0, 50.0, 3 X = m.addVars(T, vtype=GRB.INTEGER, name="Order_Qty") I = m.addVars(T, vtype=GRB.CONTINUOUS, name="Inventory_Level") shortage = m.addVars(T, vtype=GRB.CONTINUOUS, name="Shortage") for t in range(T): prev_inv = I[t - 1] if t > 0 else 100 order_arrival = X[t - lead_time] if t >= lead_time else 0 m.addConstr(I[t] == prev_inv + order_arrival - demand[t] + shortage[t]) m.addConstr(X[t] >= 0) m.setObjective(gp.quicksum(h * I[t] + p * shortage[t] for t in range(T)), GRB.MINIMIZE) m.optimize() ``` ## Что вышло На логистике машиностроительного холдинга излишки уехали на 32%. Останов цеха из-за пустой ячейки на горизонте модели свели к нулю. Считали конкретный горизонт, MOQ и штраф, которые заказчик подписал.

Когда цифровой двойник — просто картинка? Четыре уровня готовности

2026-06-11T00:00:00.000Z

## Коротко Цифровой двойник это поток с датчиков, модель и прогноз. Красивый цех в браузере без этого остаётся картинкой. Пороги, без которых внедрение рано. ## Чек-лист инфраструктуры | Уровень | Что должно стоять | Критерий | |---|---|---| | Полевой (IIoT) | Ток, вибрация, температура на критических узлах, выгрузка в ПЛК | Узлы, от которых зависит простой, закрыты сенсорами | | Сеть | Ethernet, OPC UA / MQTT / Modbus TCP, свои шлюзы | Задержка датчик → сервер < 50 мс | | Хранение | TSDB: InfluxDB, ClickHouse или TimescaleDB | Запись до 50 000 метрик/с | | CAD / BIM | Актуальные 3D станков и план цеха | glTF/OBJ, кинематика прописана | ## Когда не ставим Нет истории телеметрии. Нет шлюза. Модели в «архиве 2014». Тогда сначала датчики и сеть. Картинку в WebGL можно нарисовать и без этого. К прогнозу по датчикам она не привяжется.

Где поставщик закладывает лишнее? Ловим аномалии в прайсах

2026-06-02T00:00:00.000Z

## Коротко Сверка с «базой» ломается о сезон и доставку. Ищем выброс без учителя: аномальной точке нужно меньше разбиений, чтобы отделиться от облака. Признаки: цена за тонну, объём, плечо доставки. `contamination=0.03`. ## Обучение ```python import pandas as pd import numpy as np from sklearn.ensemble import IsolationForest data = pd.read_csv("procurement_prices.csv") X = data[["price_per_ton", "volume_tons", "delivery_distance_km"]].values clf = IsolationForest(n_estimators=150, contamination=0.03, random_state=42) clf.fit(X) data["is_anomaly"] = clf.predict(X) == -1 print("подозрительных позиций:", int(data["is_anomaly"].sum())) ``` ## Куда втыкаем Модель в ONNX на сервере завода. Согласование счёта в 1С:ERP бьёт в API. Аномалия: блок и ручной разбор, без автооплаты. Доказательством сговора это не считается. Для СБ это очередь, куда смотреть первым.