Методология APRE

От «как делают» к пилоту ИИ

Локальный ИИ имеет смысл, когда он опирается на реальный процесс и доступные данные — а не на красивый PDF и общий промпт «будь полезным ассистентом завода».

Не путать с reverse engineering программ. Здесь речь о разборе бизнес-процессов и ИИ, который работает с ними внутри вашего контура.

Архитектура данных APRE

Схема движения данных: от As-Is следа к локальному ИИ

01. AS-IS DATA Фактический след Логи ERP / СЭД / MES 3D CAD / Спецификации Сканы ГОСТ / Нормы 02. FORMAL MODEL BPMN & Граф знаний BPMN 2.0 XML Схема Векторный индекс RAG Правила контроля 03. TO-BE PIPELINE Разделение ролей Скрипты (Код) ИИ-агенты (LLM/Vision) Human-in-the-loop 04. ON-PREM AIR-GAP Локальный ИИ-Контур vLLM + DeepSeek-R1 / Qwen3 Запрет внешних вызовов Измеримый KPI и ROI
Метод

Четыре шага от факта к пилоту

Нажмите этап — что смотрим, что получаем, на что опираемся

Шаг 1

Смотрим, как процесс идёт на деле

Не «как в инструкции», а как люди и системы работают сейчас: обходы, Excel, почта, ожидания, исключения. Без этого ИИ будет учить красивую легенду.

  • Смотрим: системы, документы, логи, интервью, хронометраж
  • На выходе: карта факта и разрывов с регламентом
  • Не делаем: вид, что «у нас всё по полочкам», если это не так
process_trace_as_is.json
{
  "process_id": "CTPP-2026-BUR",
  "declared_time_hours": 4.0,
  "actual_time_hours": 28.5,
  "bottlenecks": [
    "Ручная выверка спек 3D CAD vs ГОСТ 2.106",
    "Согласование отклонений материалов по e-mail"
  ],
  "data_sources": ["ERP_1C", "Kompas_3D", "Paper_Scans"]
}
Шаг 2

Собираем модель, на которую можно опереться

Роли, шаги, данные, системы, исключения — в виде схемы, с которой потом работают поиск, правила и пилот. Формат вторичен; важна полнота для следующих шагов.

  • На выходе: схема процесса, глоссарий, связи систем
  • Зачем: контекст для ИИ и автоматизации, а не картинка на слайд
  • Ограничение: модель не отменяет здравый смысл и хозяина процесса
process_graph.bpmn.xml
<bpmn:process id="TechPrepPipeline">
  <bpmn:task id="VerifyCAD" name="Анализ геометрии детали">
    <bpmn:extensionElements>
      <apre:aiAgent target="Aist-CAD-Engine" mode="Deterministic" />
    </bpmn:extensionElements>
  </bpmn:task>
</bpmn:process>
Шаг 3

Решаем, где ИИ уместен — а где нет

Часть шагов закрывается обычным кодом и правилами. Часть — поиском и моделью. Часть остаётся за человеком. ИИ — не награда за проект, а один из инструментов на схеме.

  • Скрипты и правила: там, где логика жёсткая
  • ИИ: разбор, черновики, поиск по своей базе
  • Человек: подпись, ответственность, спорные случаи
agent_role_matrix.yaml
pipeline_target: "To-Be КТПП"
roles:
  cad_parsing: "Automated Python Step"
  normative_check: "On-Prem LLM Agent (DeepSeek-R1)"
  gcode_generation: "CAM Script + AI Validation"
  chief_technologist: "Human Approval Guardrail"
Шаг 4

Пилот в согласованном контуре

Один процесс, понятная метрика, свои или согласованные серверы. Данные не уезжают «куда удобно API», если политика против. По итогам — идём дальше или останавливаемся.

  • Scope: узкий, с хозяином процесса
  • Контур: локально / гибрид — по риску, не по моде
  • Итог: go / no-go без самообмана
airgap_hardware_status.log
# LOG: ON-PREM AIR-GAP CONTOUR
Status: Active
Model: DeepSeek-R1-Distill-32B (Local vLLM Air-Gap)
Network: Outbound Blocked (Strict Air-Gap)
Latency: 18ms (first token)

Четыре фазы

Архитектура цепочки APRE

01

Как есть на деле

Смотрим документы, системы, переписки, людей. Не «как написано», а как действительно делают шаг за шагом.

02

Модель процесса

Собираем понятную схему: роли, данные, системы, исключения. Это опора для поиска, правил и будущих агентов.

03

Как должно стать

Решаем, где ИИ уместен, где хватит обычной автоматизации, а где обязательно остаётся человек.

04

Пилот в своём контуре

Один процесс, свои серверы, понятная метрика. По итогам — идём дальше или останавливаемся.

Что остаётся на руках после каждого шага

После разбора

Карта «как есть»

Откуда берётся правда, где регламент врёт, какие Excel и почта держат процесс, кто реально решает.

После модели

Схема, на которую можно опереться

Роли, данные, системы, исключения. Не «диаграмма для слайда», а каркас для поиска, правил и пилота.

После to-be

Где ИИ, а где нет

Что отдать модели, что закрыть скриптом, что оставить человеку. Меньше магии — больше ответственности.

После пилота

Ответ go / no-go

Один процесс, свой контур, метрика. Можно масштабировать — или честно остановиться.

Почему не «сразу чат-бот поверх регламента»

Без картины факта модель повторяет шум: выдуманные шаги, мёртвые согласования, лишние данные наружу. Сначала фиксируем, как процесс живёт. Потом усиливаем узкие места.

С чего обычно начинают работу

Разбор as-is → схема to-be → пилот на одном участке. Форматы — на странице услуг, примеры — в кейсах, определение метода — в материалах.