«Хотели “один-единственный PLM на все случаи жизни”…
а получили десяток Excel-файлов, кучу скриптов и кастомизаций, плюс армию недовольных технологов.

Монолитный PLM, тесно связанных с родным CAD, — идеален для 3D-моделей, но всё, что начинается после работы с моделями, превращается в цифровой лабиринт. Вот почему крупные компании все чаще строят двухслойную архитектуру: PDM для CAD-данных и отдельный "Factory-PLM" для производственно-сервисных процессов.

Почему «мегасистема» трещит по швам

Приоритет CAD. Вендор шлифует интеграцию «PDM ↔ CAD», потому что на CAD он зарабатывает основные деньги. А модули для технологов, логистики и ТОиР делает «чтоб было» — получается сыро.
Одинокий EBOM. При попытке вести технологический состав (MBOM), состав техпроцессов (BOP) или экземплятный состав изделия (As-Built) начинается ручная синхронизация и лоскутное кастомирование.
Закрытые дверцы. Проприетарные API осложняют обмен данными с MES, ERP и сервисными платформами.
Кома кастомизации. Чтобы залатать дырки, PDM обрастает кастомизациями и скриптами; апгрейд становится болью.

---

Двухслойный PLM: что за уровни

1. CAD-management

* Управляет чисто инженерными данными: CAD-файлы, ревизии, EBOM, изменениями.
* Глубоко вшит в конкретную САПР.
* Главный клиент — конструктор.

2. Factory-PLM

* Забирает EBOM и превращает его в MBOM, BOP и другие составы.
* Ведёт As-Built, As-Maintained, процессы производства, качества, закупок и сервиса.
* Предлагает открытые API и low-code для быстрой настройки под реальные цеховые и сервисные процессы.
* Главные клиенты — технолог, логист, сервис-инженер, снабженец.

Короткое правило:

* Всё, что рождается в CAD, — в PDM.
* Всё, что зарабатывает деньги после release, — в Factory-PLM.

---

Aras Innovator: яркий Factory-PLM

Aras стал де-факто эталоном «второго слоя» благодаря набору готовых сервисов:

* Multi-BOM и их синхронизация. EBOM, MBOM, Service-BOM живут в одном ядре, изменения распространяются автоматически.
* Manufacturing Process Planning. Быстрое создание маршрутов и операций, линк к MES/APS.
* As-Built / As-Maintained. Реальная история каждого серийного номера — основа цифровых двойников.
* Change & Quality workflows. Встроенные ECR/ECO, NCR, 8D и полная трассировка.
* Supplier & Compliance. Управление поставщиками, REACH/ROHS, Digital Product Passport (EU 2027).

К сожалению, подобного уровня продуктов на российском рынке сейчас нет, но можно создать комбинированную систему, с аналогичным или близким функционалом.

Как «развести» уровни на практике

* Сначала разграничьте ответственность. Оставьте модели и EBOM там, где конструкторы работают быстрее всего — в PDM.
* BOM-ы мигрируйте постепенно. Начните с MBOM и BOP в Factory-PLM, затем подтяните As-Built и сервисные данные.
* Интегрируйте через открытые инструменты — это удешевит поддержку и апгрейды.
* Измеряйте выгоду бизнес-метриками. Сокращение времени запуска, снижение незавершенки, повышение сервис-уровня — вот критерии успеха, а не «закрыли все галочки в ТЗ».

---

Итог

Монолитный «One-PLM-XXX-All-in-One» хорош в фантазиях, но жизнь требует разной скорости и глубины на разных этапах жизненного цикла изделия. Двухслойная модель PDM + Factory-PLM даёт:

* быстрый и удобный CAD-контур для конструкторов;
* сквозную цифровую нить от R&D до послегарантийного ремонта;
* гибкость модернизации процессов без длительных доработок ядра.

Внедрите разделение и настройте интеграцию — получите PLM, который работает не только в чертежах, но и в цеху, на складе и даже у клиента.

Что такое S&OP и зачем это нужно производственной компании?

Любая компания что-то покупает → что-то с этим делает → кому-то продаёт.

Пока сделок немного, всё держится в голове руководства, либо разрозненных табличках Excel: сколько закупаем, что и когда производим, кому и когда обещали отгрузить.
Но стоит контрактов стать десяткам, а SKU — сотням, начинается хаос: производство и закупки работают рассинхронизированно, клиенты не получают продукцию в срок и нервничают.

Именно в этот момент появляется Sales & Operations Planning (S&OP) — процесс, который склеивает закупки, производство и продажи в единый, согласованный план.

Откуда взялся подход
• Конец 1970-х — начало 1980-х. Консультант в области производственного планирования Oliver Wight искал способ вывести MRP за пределы цеха и связать его с коммерческим спросом. Так родилось S&OP.
• С самого начала это была методика управления, а не «ещё один модуль ERP»: ежемесячные совещания, сводные таблицы, совместные решения.
• В 2000-х S&OP трансформировался в IBP (Integrated Business Planning), но суть не изменилась — баланс спроса, предложения и денег.

Почему S&OP ≠ «очередная IT-система»
S&OP — это управленческий ритуал, а не кнопка “Сформировать план”.
— Люди: продажники, снабжение, производство, финансы, топ-менеджеры.
— Процессы: единый календарь встреч, регламент согласования, KPI сервиса и оборачиваемости.
— Данные: прогнозы, уровни запасов, мощности, маржа.
— Инструменты лишь помогают быстро собрать цифры и показать «что будет, если…».

Пять шагов классического цикла
1️⃣ Сбор фактов — собираем прогнозы, остатки, заказы, мощности → получаем «чистую» базу данных.
2️⃣ План спроса — спорим о прогнозе, учитываем акции и маркетинг → формируем Demand Plan.
3️⃣ План предложения — сверяем мощности, закупаем узкие места → получаем Supply Plan.
4️⃣ Пред-S&OP — сводим спрос + предложение, считаем деньги, готовим варианты решения.
5️⃣ Исполнительная S&OP-встреча — дирекция утверждает один сценарий и поручения → рождается единый One-Number Plan.
⏰ Цикл крутится ежемесячно, горизонт планирования чаще всего 12–24 месяца.

Как начать внедрение
🔹 Назначить владельца процесса (обычно директор по закупкам, цепочке поставок и пр.).
🔹 Определить календарь: даты закрытия факта, дедлайны прогнозов, день S&OP-совещания.
🔹 Согласовать шаблоны: какую матрицу SKU агрегируем, какие KPI показываем.
🔹 Обучить команду: зачем нужен процесс и что от кого ждут.
🔹 Пилот 3–4 цикла на ключевых продуктах — закрепляем ритуал, не гонимся за 100 % точностью.
🔹 Раскатка на всю линейку, тонкая настройка метрик и автоматизация рутинных расчётов.

Инструментарий без фанатизма
• Excel / Google-таблицы — отлично для старта: быстро, дёшево, наглядно.
• BI-дашборды (Power BI и пр.) — показывают отклонения и сценарии.
• CRM — управляет информацией о потенциальных сделках, составах потенциальной поставки, требуемым датам.
• Базовые SCM-системы — делают процесс закупок и поставок прозрачным, агрегируют потребности разных подразделений, показывают отклонения в поставках.
• APS-планировщики — считают варианты производственного плана с привязкой к производственным заказам и поставкам сырья и материалов.
• ERP / 1С / SAP — учетно-бухгалтерский контур.

Главное правило: автоматизируем только устоявшийся процесс; «купить систему, чтобы она сама внедрила S&OP» не сработает.

Что получаем в итоге
🎯 Оцифрованный, согласованный, сведенный между доментами закупок, продаж и производства план— один набор правды для всех.
📉 Запасы ↓, оборачиваемость ↑ — деньги высвобождаются из склада.
🚚 Уровень сервиса растёт: клиенты получают вовремя «то, что обещали».
🤝 Команда говорит на одном языке: меньше пожарных совещаний, больше проактивных решений.

S&OP — это не IT-модуль, а управленческая привычка.
Когда привычка закреплена, система лишь убирает рутину и делает цифры прозрачными.

Самое дорогое в машиностроении — коммерческое предложение, которого не будет

Уравнение суровое: инженеры тратят до половины фонда своего рабочего времени, чтобы описать изделие, которое никогда не увидит свет.
Конкурс проигран, а время и деньги сгорели.

---

⚙️ Как мы докатились

Сегодня большинство заводов работает по схемам CTO (Configure-to-Order, конфигурация под заказ) или ETO (Engineer-to-Order, инжиниринг под заказ).
Продажи идут через тендеры крупных заказчиков, а конверсия в сделку после КП — около 5 %.
Итого: на один выигранный контракт приходится 20 ТКП.

Что происходит внутри предприятия:

🔂 Инженеры превращаются в продавцов
Вместо разработки — копипастят спецификации и считают цены.

⏳ Срок ответа — недели
Пока готовим КП, конкурент уже в финале тендера.

💰 “Золотые” КП
Неоплачиваемая работа инженеров съедает маржу от проектов.

🧩 Множество вариантов
Excel-версии, ручные расчёты, ошибки в комплектации.

📑 Разные шаблоны документов
Каждый отдел держит свою форму КП с разными конфигурациями и принципами построения документа.

---

🚀 CPQ: Configure • Price • Quote

Системы CPQ (конфигурирование, оценка, предложение) автоматизируют весь цикл подготовки технико-коммерческих предложений:
конфигурируют изделие ↔ рассчитывают цену ↔ собирают красивое КП.

Что внутри

🧩 Конфигуратор на базе 150 % BOM для каждого высокоуровневого модуля/узла
Хранит «суперспецификацию» модулей и узлов: все возможные комплектующие, опции, материалы.
Правила (if-then) выбирают нужные позиции и собирают *BOM 100 %* под заказ.

💸 Ценообразование
Берёт актуальные цены материалов, нормы трудоёмкости, наценки, скидочные матрицы.
Можно видеть маржу в реальном времени и играть параметрами.

📄 Автогенерация КП
Word/PDF с фирстилем, 3D-превью, перечнем узлов, сроками и подписью ответственного лица — за секунды.

Интеграции

🔗 CRM — тянет лида, фиксирует конверсию, наполняет воронку факт-данными.
🔗 PLM / ERP — получает утверждённый BOM и трудоёмкости после победы.
🔗 Порталы тендеров — публикует КП прямо в закупочную систему заказчика.

---

📈 Результаты, которые видят заводы

Было ↔ Стало с CPQ
Подготовка КП — 2 – 4 недели ↔ 1 – 2 дня
20-50 % времени КБ уходит в пустоту ↔ < 5-10 %
Ошибки в цене / составе — частое явление ↔ ~ 0 % (правила + единый источник данных)
Конверсия 5 % ↔ 8–12 % *(сокращённый цикл ответа)*

---

🏁 С чего начать внедрение

1. Опишите “150 % BOM” для узлов и модулей
Соберите все варианты, опции, взаимные исключения.
2. Формализуйте правила конфигурации
Если диаметр > 300 мм — ставим подшипник А, иначе — В.
3. Пересчитайте нормы и цены
Обновите прайс-листы, тарифы цехов и аутсорса.
4. Сделайте MVP CPQ на одну линейку
Достаточно Excel-BOM + скрипт генерации КП, чтобы показать эффект.
5. Интегрируйте с CRM и ERP
Пусть данные не дублируются, а текут по цепочке «лид → BOM → производство».

---

🎯 Итог

Пока конкуренты отправляют «чуть-чуть не то» через две недели,
вы уже подготовили правильное КП в несколько кликов.

Взлёт и падение Low-Code

✈️ Пики спроса
В пандемийный 2020-й компании отчаянно искали разработчиков любого уровня. Потребности в развитии ИТ росла быстрее, чем компании успевали нанимать программистов, а команды успевали писать ТЗ. На этом хайпе вырос спрос на платформы Low-/No-Code: «щёлкай мышкой — и получишь MVP».

🔥 Кульминацией стала покупка Mendix концерном Siemens за $730 млн — крупнейшая сделка в истории Low-Code.

💰 Gartner и Forrester сулили рынку двузначные темпы роста до 2030-х, а «гражданские разработчики» грозились затмить профи.

⚙️ Механика успеха
Low-Code обещал решить класс «простых» задач, где написать ТЗ дольше, чем саму функцию. Если бы бизнес-эксперт умел кодить как джун, он бы всё сделал сам. Но не умеет → за него «кликает» визуальная платформа.

🪄 Поворот: приход LLM
С 2023-го большие языковые модели (LLM) научились:
- генерировать рабочий код на естественном языке;
- объяснять, как развернуть и протестировать приложение;
- быть репетиторами, разбирая ошибки «на лету».

⚡️Эффект от LLM для разработки: GitHub сообщает — базовые задачи разработки завершаются на 55 % быстрее с ИИ. McKinsey фиксирует снижение времени на сложные задачи ещё на 12 %.

📉 Учиться стало проще?
Надёжных метрик «время на обучение Low-Code vs LLM» мало, но косвенные данные показывают:

освоить ChatGPT + VS Code новичку-разработчику получается примерно на треть быстрее, чем втянуться в корпоративный Low-Code-фреймворк (данные опросов AWS и GitHub, сопоставление по часам онбординга).

LLM-стиль обучения не требует запоминать GUI-логики платформы — лишь основы языка и просьбу «объясни, почему тест упал».

🕯 Почему тренд Low-Code угасает
📌 Невидимая сложность. После пары drag-and-drop экранов всё равно всплывает необходимость SQL-запроса, регулярного выражения или кастомного API-вызова. Там, где Low-Code «заканчивается», LLM только разогревается.
📌 Стоимость владения. Корпоративные лицензии Low-Code-платформ обходятся крайне дорого, особенно если добавить скрытую цену DevOps-интеграций.
📌 Закрытый стек. Выход из платформы = миграция всего приложения. Код, который написал собственный программист лежит в git и портируется куда угодно.
📌 Вектор инвестиций. Большие вендоры сами добавляют GenAI-ассистентов в свои Low-Code-IDE… фактически превращая визуальные блоки в «UI над LLM».

🔮 Что дальше

Low-Code не исчезнет: он станет «обёрткой» для GenAI, удобной бизнес-пользователям.

Но главная революция — дешёвый персональный «джун»-ИИ в каждом редакторе кода.

В компаниях снова возрастёт спрос на архитекторов и техлидов, способных выстроить качественный продукт из быстро напечатанных ИИ-фрагментов.

💡 Итог
Low-Code взлетел на потребности «быстро и без программистов», но упёрся в потолок гибкости. LLM-ассистенты вернули власть тому, кто формулирует задачу словами, а не перетаскивает квадратики. Пока визуальные платформы учатся дружить с GenAI, рынок уже голосует курсором: писать текст оказалось проще, чем тянуть стрелочки.

🏭 Завод — это постоянные изменения

Ни один цех не работает «по одному рецепту» десятилетиями.
Появляются новые поставщики, меняются материалы, инженеры проводят улучшения конструкции или находят ошибки —⁠ и конструкторская документация обновляется. Технологи модифицируют маршруты и операции, меняют инструмент и оснастку. Всё вместе порождает ревизии —⁠ версии составов изделия (BOM), по которым завод живёт сегодня.

---

Зачем вообще нужна ревизия

1. Одна версия правды. Каждый видит, какую модификацию собирать.
2. Прослеживаемость. Можно узнать, из чего собран любой серийный номер.
3. Контроль качества. Точное понимание, как должно было быть произведена продукция.
4. Управление улучшениями. Любое изменение фиксируется датой, автором и обоснованием.

---

Как ревизии проходят цепочку

1. Конструкторский состав изделия (EBOM) —⁠ конструктор меняет чертёж → ревизия B.
2. Технологический состав изделия (MBOM) —⁠ технолог видит ревизию B, корректирует операции и оснастку.
3. Ведомость покупных PBOM / закупочная спецификация создаётся системой автоматически: закупщик работает уже по ревизии B, без писем и Excel.

При условии, что это один объект в единой системе, а не три разрозненных файла.

---

Применимость ревизии

* По времени: действует с 01.07 → до этой даты заказываем старую деталь.
* По серийному номеру: новая плата ставится, начиная с № 3000.
* По комплектации: «люкс» собирают по rev C, «стандарт» — по rev B.

---

Замены: глобальные и локальные

* Глобальная — винт M6 меняем на Torx во всех изделиях: новая ревизия, повторный техаудит.
* Локальная — разрешён альтернативный подшипник только в конкретном изделии или партии Х123–Х125: правило *допустимо к применению*, ревизия BOM не растёт.

---

Что даёт цифровая связка «конструктор —⁠ технолог —⁠ закупщик

Закупщик видит новую ревизию в тот же момент
Сокращаются запасы и неликвид
Время начала выпуска существенно сокращается за счет более быстрой комплектации заказов


---

Как запустить у себя

1. Картируйте процесс изменения: от кнопки «сохранить» до заказа поставщику.
2. Уберите разрывы: E-, M- и P-BOM должны жить в одном ядре.
3. Задайте правила применяемости прямо в карточке ревизии.
4. Автоматизируйте уведомления: пуш в мессенджер закупщику при любой правке.
5. Обучите команду отличать глобальные и локальные замены.

---

Итог

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

«Кадры решают всё» — но в 2025-м платить за лишние часы уже дорого
69% российских заводов жалуются на кадровый дефицит, а безработица держится на рекордных 2,4%. При этом энерго- и сырьевые затраты растут, а рынок требует гибкости. Вывод прост: эффективнее использовать тех, кто уже есть.

Почему «ручное» планирование больше не спасает

📋 Excel-планы не учитывают взаимосвязь операций — оборудование и персонал то не загружено, то все горит.
🕳 Узкие места видны только пост-фактум.
🤝 Дублирование ролей раздувает штат.
📡 Ручной ввод данных и учет крадёт рабочее время.

Что даёт связка APS + MES

🧠 APS (Advanced Planning & Scheduling) строит реалистичный, ресурсно-сбалансированный график.
📡 MES (Manufacturing Execution System) сверяет факт с планом в реальном времени и подсвечивает отклонения.

Результат:

🔄 равномерная загрузка смен;
⏱ меньше ожиданий (материалы + наладка + люди работают синхронизировано);
👥 прозрачно видно, где чаще всего не хватает людей — их можно переучить, или временно отправить на другой участок, а не нанимать;
⚡️ авто-сбор данных избавляет операторов от бумаг;
🧮 норматива хватает, чтобы «подрезать» лишние человеко-часы.


Сколько экономии реально

Однозначная российская статистика отсутствует, но иностранная практика на основе данных McKinsey и ряда разработчиков ПО говорит о следующем: до 25 % фонда труда высвобождается за 6-12 месяцев после полного цикла внедрения.

≈8 % — исчезают простои и «сидение без задания».
≈6 % — падают сверхурочные (оvertime на 10-20 % ниже в производстве).
≈5 % — уходит бумажная рутина.
≈3 % — склад и вспомогательные службы работают по точному таймингу.
≈3 % — мастерам больше не нужно «обходить» цех: система сама сигналит.

⚠️ Речь не про «массовые увольнения». Персонал перераспределяют на дефицитные операции, новые проекты или закрывают вакансии без найма.

Почему критично именно сейчас

1. Демография — молодых рабочих станет на 23 % меньше к началу 2030-х.
2. Инфляция + курс — каждый рубль ФОТ, сэкономленный сегодня, завтра спасает маржу.
3. Импортозамещение — нужно выпускать больше, но теми же руками.
4. Волатильный спрос — держать «резерв в людях» слишком дорого.

Как запустить APS + MES

1. Замерить факт — иметь слепок производственного факта за некоторый период времени, например в 1 цеху.
2. Пилот APS — один цех, либо участок. Результат через 6-8 недель.
3. Развернуть MES — автоматический сбор данных вместо бумаг.
4. Оптимизировать персонал — переобучить персонал, оптимизировать рабочий график, оптимизировать штат под новый график.
5. Оптимизировать техпроцессы — при построении планов APS становятся видны узкие места и понятны способы оптимизации техпроцессов для повышения выработки.
5. Ввести цикл постоянных улучшений.


APS + MES — не ещё одна система отчетности. Это инструмент, который переводит ФОТ из фиксированных расходов в управляемый ресурс. Уже через 6-12 месяцев предприятие получает до четверти высвобожденных человеко-часов и запас гибкости для новых заказов — то, что сейчас ценится дороже любого станка.

Алгоритм всё знает, кроме того, чего не знает никто…

Несколько лет назад рынок накрыла волна «волшебных» систем предсказания спроса. Разработчики обещали превратить хаос продаж в точные цифры, а склады — в часы. Что получилось на практике?

Что пошло не так

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

🆕 Новая продукция = новые промахи.
Алгоритм «учится» на прошлых данных. У новинок прошлого нет, поэтому погрешность взлетает: либо закладывается завышенный запас, либо товар исчезает с полок быстрее, чем цех успевает запуститься.

🌍 Экономика и конкуренты не в модели.
Изменение экспортных пошлин, колебания курсов, демпинг соперников или агрессивный промо-бюджет конкурента могут обнулить самый точный прогноз. Большинство решений смотрят только на внутреннюю историю продаж.

Когда система предсказания спроса всё же работает

🚚 Стабильный ассортимент и длинный жизненный цикл.
Чем дольше товар «живёт» без радикальных изменений, тем больше данных и тем точнее модель.

🛒 Регулярная повторяемость заказов.
FMCG, запасные части, фармсегмент — где продажи «дёргаются» меньше, модель ловит сезонность и промо-пики.

🔄 Есть обратная связь с планированием производства.
Когда прогноз сразу идёт в MRP/APS и возвратом «учит» модель, эффект от внедрения выходит за рамки склада — снижает переналадку линий, запасы и незавершенное производство.

Что ещё важно, но обычно остаётся «за кадром»

1. Маркетинг и ценовая политика. Планируемые акции, ребрендинг, выход в новые каналы часто хранятся в головах бренд-менеджеров, а не в базе для Data Science.
2. Время выхода на рынок (time-to-market). Чем дольше согласовывают рецептуру, упаковку и сертификаты, тем выше риск, что прогноз устареет до запуска.
3. Ограничения поставщиков. Даже идеальный прогноз не спасёт, если критичный компонент производится по квотам или под заказ на 120 дней.
4. Производственные мощности и графики ТОиР. Алгоритм может «видеть» спрос, но не знает, что на следующей неделе главная линия уходит в плановый ремонт.
5. Внешние шоки. Санкции, стихийные бедствия, всплески цен на сырьё — их сложно встроить в модель, но без сценариев «что-если» риск взрыва запасов велик.

Итого

Система предсказания спроса работает там, где процесс продаж и производства замкнут в единый контур данных.
Главные риски — новинки и внешние факторы. Для них нужен гибрид: статистический прогноз + экспертная корректировка + what-if-анализ.
Без связи с S&OP и APS эффект ограничен. Прогноз должен сразу трансформироваться в план производства и закупок, иначе склад по-прежнему будет «дышать» в такт ошибкам.
Будущее в расширенной модели. Добавляем маркетинг, сроки поставщиков, экономические индикаторы, событийный слой (конкурентные акции, регуляторные изменения) и регулярно переучиваем алгоритм. Тогда система становится навигатором бизнеса, а не очередным дэшбордом.

➡️ Мораль: вкладываться в предсказание спроса стоит, когда в компании созрела культура сквозного планирования (хотя бы S&OP) и есть готовность кормить модель не только историей продаж, но и «живой» информацией о рынке и мощности собственного завода. В остальных случаях проще (и дешевле) вовремя слышать реальный спрос, чем пытаться угадать его по звёздам.

Зачем вообще «связывать» ИТ-системы?

🏭 На заводах, как правило, несколько островков информации:

— 1С хранит заказы и остатки.
— Система планирования производства (APS) строит график работ по цехам.
— PLM-платформа хранит чертежи, 3D модели и составы изделий.

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

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

Почему интегрировать трудно

🔀 Разные форматы
1С отправляет XML-файлы, APS ждёт JSON по сети, а старый станок может выдать данные только в формате txt. Нужно «переводить» данные, иначе системы друг друга не поймут.

🗺 Несогласованные справочники
Артикул «123-А» в 1С = «0123A» в PLM. Без единого каталога детали «теряются» на пути от конструкторов к закупкам.

⏰ Разный ритм работы
APS пересчитывает план каждые 15 минут, 1С обновляет остатки ночью, а инженеры могут менять данные вообще без какого-либо расписания. Состыковать эти циклы — отдельная задача в рамках проекта интеграции.

🔒 Информационная безопасность
Открыть 1С наружу или пустить заводские данные в «облако» — всегда риск. Правила доступа и шифрование нужно закладывать заранее, иначе любой обмен остановят безопасники.

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

👥 Люди и процессы
Если инженер ведёт составы в Excel, никакая «магическая» связь программ не поможет. Придётся менять привычки и правила работы.


Живой пример

1. Конструктор меняет болт М8 на М10 и сохраняет новую ревизию в PLM.
2. APS не узнаёт об изменении и продолжает планировать выпуск по старому составу.
3. 1С закупает «старые» болты, склад забит, производство встаёт, когда обнаруживается несоответствие.

Без автоматической передачи данных «ревизия → план → закупка» завод теряет дни и деньги.


Универсальный рецепт «с нуля»

1. Нарисуйте простую карту данных
Что такое «Заказ», «Деталь», «Наряд»? Где объект появляется, кто им пользуется? Бумажная схема на одной странице раскроет 80 % проблем.

2. Начните с самого узкого места
Чаще всего это обмен остатками и заказами между 1С и APS. Сделайте маленький, но рабочий обмен (хоть CSV-файл по расписанию) и убедитесь, что цифры сходятся.

3. Встроите безопасность сразу
HTTPS, логины-пароли, журнал изменений — не «после запуска», а до первой передачи данных.

4. Измеряйте полезность
▪ Сколько ручных операций убрали?
▪ Насколько снизились запасы?
▪ Как быстро проходит новый заказ?
Видимые цифры убеждают руководство лучше любой презентации.

5. Расширяйте постепенно
Добавляйте PLM, подключайте цеховое оборудование, вводите события «партия готова» и пр. Но каждый шаг — после того, как предыдущий стабильно работает.

Главное
Интеграция — это про то, чтобы конструкторская идея без искажений стала готовым изделием, а директор видел реальную картину в одной системе, а не в пяти отчётах, на месяц позже чем нужно. Начните с малого, считайте выгоду в цифрах и не забывайте: самые сложные «шестерёнки» в этой передаче — люди и их привычки. Тогда связка 1С, APS и PLM станет опорой, а не головной болью.

SMED расшифровывается как Single Minute Exchange of Die, буквально «обмен штампа за одну минуту».

История возникла в 1950-х на заводе Toyota. На прессе для штамповки переналадка занимала часов восемь. Восемь часов! Это были демонтаж старого штампа, монтаж нового, регулировка, наладка, проверка. Неэффективно. Toyota нужна была гибкость, нужно было быстро переходить с одного продукта на другой.

Инженеры разобрали процесс переналадки на все смежные операции и разделили их на две категории.

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

Вторая категория: операции, которые нужно делать, пока станок остановлен. Это демонтаж старого штампа и монтаж нового, нельзя распараллелить.

Toyota стала готовить всё заранее (внешние операции) и оставила только критические операции на время остановки (внутренние).

Результат: переналадка сократилась с восьми часов до пятнадцати минут. Это сокращение простоев из-за переналадок в 32 раза!

Аналогичный принцип может применяться и для других переналадок, например смены типа сварки и подготовка электродов. Внешние операции: подготовить новые электроды, проверить кабели, кондукторы. Внутренние: остановить аппарат, вынуть старые электроды, вставить новые, регулировка силы тока.

Если сварщик ждёт до остановки и делает всё подряд, это минут сорок. Если заранее подготовит электроды и кондуктора, разложит всё рядом, то после остановки останется только вставить и отладить. Минут десять. Сэкономленные тридцать минут — уже существенная дополнительная мощность. Пять переналадок в смене — два с половиной часа сэкономили. За год уже сотни часов.

SMED не требует денег, требует ума: что можно подготовить заранее? Стандартизация (всегда делать одинаково, научить/натренировать людей), расстановка инструмента (всё в одном месте), параллелизм (несколько человек работают одновременно), предготовка (готовим все до остановки), автоматизация (в крайнем случае, если переналадка частая).

На типичном российском заводе SMED применяется редко. Переналадка занимает часы, потому что никогда не думали об этом. В крайнем случае объединяют партии в рамках горизонта планирования чтобы уменьшить количество переналадок.

Результат: небольшие заказы неэффективны. Если переналадка часа три, то запускать заказ на 10 часов работы нет смысла. Запускаешь заказ на 50 часов, собираешь большую партию. Но потом эта партия лежит три недели перед следующим участком.

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