«Чтобы продать что-нибудь ненужное, надо сначала купить что-нибудь ненужное… а у нас денег нет»
Эта реплика дяди Фёдора из «Простоквашино» давно стала мемом — и неожиданно точно описывает будни отделов закупок на большинстве наших заводов.
Деньги на «ненужное» всегда находятся, а вот на то, что действительно определяет конкурентоспособность бизнеса, порой не хватает ни бюджета, ни внимания.
Типовой сценарий «закупочного абсурда»
📉 Нет прогноза продаж.
Отдел сбыта живёт по принципу «примем всё, что упадёт в почту». Чтобы не опозориться перед клиентом, завод держит горы готовой продукции «на всякий случай». Парадокс — нужных позиций всё равно не оказывается.
📦 Пустые полки комплектующих.
Как только появляется заказ на «дефицитную» номенклатуру, выясняется, что на складе нет пары критичных компонентов. Лояльность заказчика проседает.
📑 Не ведётся сквозной BOM отгрузки.
В финальный состав изделия редко попадают упаковка, паллеты, этикетки, а альтернативы и замены вообще теряются. Итог — закупают «чтобы было», а не «что нужно».
🔩 Мелочь блокирует выручку.
Отсутствие копеечного винтика останавливает отгрузку продукции стоимостью на миллионы. Себестоимость элемента — доли процента, но сервис-уровень падает до нуля.
🏭 Растёт склад готовой продукции.
«А вдруг спрос подскочит?» — и в цехах копятся месяцы производства.
🧱 Растут и запасы сырья… но не того.
Материалы «подешевле и побольше» закуплены, а вот точных позиций под реальные заказы нет.
🛒 Падает уровень сервиса.
Дистрибьюторы и розница отдают полки тем, кто способен поставлять регулярно и без сбоев.
💸 Кассовый разрыв вместо прибыли.
Выручка на бумаге неплохая, а свободного капитала нет — всё «лежит» на складах. Кредиты становятся нормой.
Как разорвать порочный круг?
Все вышеперечисленные проблемы — следствие не «плохих закупок», а отсутствия системного процесса планирования спроса и снабжения.
🧭 S&OP (Sales & Operations Planning) внедряет сквозной цикл:
прогноз → план продаж → план производства → план закупок → финансовая сверка.
⚙️ APS / DDMRP / Demand-Driven S&OP помогают синхронизировать реальные сроки поставок, мощности цехов и цикл пополнения запасов.
🖥 Специализированные информационные системы (APS-планировщики, demand-planning-платформы) делают это в реальном времени — 1С, как учётная система, просто не предназначена для подобного класса задач.
‼️ Важно: речь не об очередном «учёте в 1С», а о том, чтобы превратить данные о спросе, производственных возможностях и запасах в единое, согласованное решение для бизнеса.
Эта реплика дяди Фёдора из «Простоквашино» давно стала мемом — и неожиданно точно описывает будни отделов закупок на большинстве наших заводов.
Деньги на «ненужное» всегда находятся, а вот на то, что действительно определяет конкурентоспособность бизнеса, порой не хватает ни бюджета, ни внимания.
Типовой сценарий «закупочного абсурда»
📉 Нет прогноза продаж.
Отдел сбыта живёт по принципу «примем всё, что упадёт в почту». Чтобы не опозориться перед клиентом, завод держит горы готовой продукции «на всякий случай». Парадокс — нужных позиций всё равно не оказывается.
📦 Пустые полки комплектующих.
Как только появляется заказ на «дефицитную» номенклатуру, выясняется, что на складе нет пары критичных компонентов. Лояльность заказчика проседает.
📑 Не ведётся сквозной BOM отгрузки.
В финальный состав изделия редко попадают упаковка, паллеты, этикетки, а альтернативы и замены вообще теряются. Итог — закупают «чтобы было», а не «что нужно».
🔩 Мелочь блокирует выручку.
Отсутствие копеечного винтика останавливает отгрузку продукции стоимостью на миллионы. Себестоимость элемента — доли процента, но сервис-уровень падает до нуля.
🏭 Растёт склад готовой продукции.
«А вдруг спрос подскочит?» — и в цехах копятся месяцы производства.
🧱 Растут и запасы сырья… но не того.
Материалы «подешевле и побольше» закуплены, а вот точных позиций под реальные заказы нет.
🛒 Падает уровень сервиса.
Дистрибьюторы и розница отдают полки тем, кто способен поставлять регулярно и без сбоев.
💸 Кассовый разрыв вместо прибыли.
Выручка на бумаге неплохая, а свободного капитала нет — всё «лежит» на складах. Кредиты становятся нормой.
Как разорвать порочный круг?
Все вышеперечисленные проблемы — следствие не «плохих закупок», а отсутствия системного процесса планирования спроса и снабжения.
🧭 S&OP (Sales & Operations Planning) внедряет сквозной цикл:
прогноз → план продаж → план производства → план закупок → финансовая сверка.
⚙️ APS / DDMRP / Demand-Driven S&OP помогают синхронизировать реальные сроки поставок, мощности цехов и цикл пополнения запасов.
🖥 Специализированные информационные системы (APS-планировщики, demand-planning-платформы) делают это в реальном времени — 1С, как учётная система, просто не предназначена для подобного класса задач.
‼️ Важно: речь не об очередном «учёте в 1С», а о том, чтобы превратить данные о спросе, производственных возможностях и запасах в единое, согласованное решение для бизнеса.
🔥1
«Начать надо с архитектуры» — банально, но другого пути нет.
На многих заводах S&OP пытаются запустить по принципу «ну у нас же есть 1С». Дальше — боль. Потому что 1С не считает альтернативы, не понимает сезонность, не умеет строить сценарии. А главное — она фиксирует прошлое, а не помогает договориться о будущем.
В серийке — один перекос: «давайте заложим ещё запас, на всякий случай». Склад пухнет, оборачиваемость падает, сервис при этом всё равно хромает — нужной позиции как всегда нет.
В позаказном — другой: «нам нужно срочно понять, успеем ли сделать». А цех уже перегружен, закупка компонентов — в Excel или накорячено в 1С, а загрузка ресурсов — «в голове у мастера». Угадайте, кто виноват, если клиент уйдёт?
Типовой запуск S&OP без головы выглядит так:
🔧 ИТ начинают «пилить решения» без требований — получаем кастомную воронку Excel в интерфейсе 1С.
📉 Бизнес не понимает, кто что планирует — спрос отдельно, производство отдельно, закупки — «по факту».
🧱 В итоге вместо единого плана — три набора таблиц, не совпадающих ни по срокам, ни по номенклатуре.
Что делать?
Сначала — описать, как вы *хотите* планировать. На уровне логики. Кто отвечает за прогноз. Как согласовываются мощности. Что считается на горизонте месяца, а что — по дням. Где и как принимаются решения.
Потом — руками. Таблицы, белая доска, один цикл обсуждений.
Если не работает на бумаге — не заработает и в цифре.
Проверили механику — зафиксировали роли и календарь. Только потом подключаем IT.
‼️ Важно: оцифровка — не в 1С.
ERP не предназначена для S\&OP. Она не тянет сценарное планирование, не умеет считать по уровням агрегирования, и не даст вам “что если мы отгрузим раньше?”. А всё, что не тянет — дорабатывается. До первой ошибки.
Правильный путь — отдельный слой планирования:
📊 Сценарии.
📦 Видимость запасов и мощностей.
📅 Прогноз → производство → закупки — в одном системе.
Специализированных систем хватает. Важно не *какая* система, а *когда* её подключают.
Сначала — логика. Потом — дисциплина. Затем — цифра.
И никакой магии. Только порядок.
На многих заводах S&OP пытаются запустить по принципу «ну у нас же есть 1С». Дальше — боль. Потому что 1С не считает альтернативы, не понимает сезонность, не умеет строить сценарии. А главное — она фиксирует прошлое, а не помогает договориться о будущем.
В серийке — один перекос: «давайте заложим ещё запас, на всякий случай». Склад пухнет, оборачиваемость падает, сервис при этом всё равно хромает — нужной позиции как всегда нет.
В позаказном — другой: «нам нужно срочно понять, успеем ли сделать». А цех уже перегружен, закупка компонентов — в Excel или накорячено в 1С, а загрузка ресурсов — «в голове у мастера». Угадайте, кто виноват, если клиент уйдёт?
Типовой запуск S&OP без головы выглядит так:
🔧 ИТ начинают «пилить решения» без требований — получаем кастомную воронку Excel в интерфейсе 1С.
📉 Бизнес не понимает, кто что планирует — спрос отдельно, производство отдельно, закупки — «по факту».
🧱 В итоге вместо единого плана — три набора таблиц, не совпадающих ни по срокам, ни по номенклатуре.
Что делать?
Сначала — описать, как вы *хотите* планировать. На уровне логики. Кто отвечает за прогноз. Как согласовываются мощности. Что считается на горизонте месяца, а что — по дням. Где и как принимаются решения.
Потом — руками. Таблицы, белая доска, один цикл обсуждений.
Если не работает на бумаге — не заработает и в цифре.
Проверили механику — зафиксировали роли и календарь. Только потом подключаем IT.
‼️ Важно: оцифровка — не в 1С.
ERP не предназначена для S\&OP. Она не тянет сценарное планирование, не умеет считать по уровням агрегирования, и не даст вам “что если мы отгрузим раньше?”. А всё, что не тянет — дорабатывается. До первой ошибки.
Правильный путь — отдельный слой планирования:
📊 Сценарии.
📦 Видимость запасов и мощностей.
📅 Прогноз → производство → закупки — в одном системе.
Специализированных систем хватает. Важно не *какая* система, а *когда* её подключают.
Сначала — логика. Потом — дисциплина. Затем — цифра.
И никакой магии. Только порядок.
🔥1
🔧 Оперативное планирование на базе APS: как запустить завод без инфаркта
Что такое APS и с чем его едят
* APS (Advanced Planning & Scheduling) — мозг, который собирает:
📈 спрос → 🏭 мощности → 🔗 материалы → 🔄 переналадки → ⏱ ограничения по времени.
Итог — посекундный график, который реально выполним.
* MES (Manufacturing Execution System) — нервная система цеха. Она исполняет то, что придумал APS: пускает смены, собирает факты, снимает телеметрию, отгружает показатели в ERP.
* APS + MES — когда мозг и нервы идут в одном коробочном решении. Звучит красиво, но не путайте: APS планирует, MES исполняет. Можно внедрить одно без другого, но вместе они творят магию.
---
Принцип №1: не пытайтесь спланировать ВСЁ и сразу
Начните с нормируемых операций — там, где:
* ✔️ оборудование стабильно (линии, печи, роботы),
* ✔️ известен производственный такт,
* ✔️ легко снять фактические часы простоя/работы.
Им именно и задаём такт ⏱. Это «сердцебиение» завода.
Принцип №2: всё подстраивается под главный такт
1. Запланировали линии → получили «бутылочное горлышко».
2. От этого горлышка планируем в обратную сторону:
* 🚚 логисты подгоняют материалы «во что бы то ни стало»,
* 🔧 наладчики крутят гайки ночами, чтобы не сбить такт,
* 📦 склад отчитывается по минутам, как пополняет буфер.
У обеспечивающих служб поначалу нет норм? Так вешаем KPI напрямую от такта: не уложился — видно сразу, где порвалась цепочка.
Принцип №3: «Давайте сделаем в 1С» — путь на кладбище бюджетов
1С - отличная учётная система, но модель оперативного планирования на её базе превращается в:
* бесконечные ТЗ 📜,
* консалт-спринты без результата 🥲,
* миллионные счета за «допилить отчёт».
🔴 Не городите APS внутри ERP! Лучше купить коробочное APS-решение или open-source движок, чем клепать велосипед из регистров.
Принцип №4: нельзя «тупо» импортировать техпроцессы и нормы
* У разных систем разный уровень детализации и представления сменных данных.
* На пилотном проекте лучше вообще без интеграций: вручную заведите 20-30 маршрутов, выверьте такты, размеры партий, времена переналадок.
* Потом уже чистите мастер-данные и пишите коннектор, но только после того, как пилот показал результат.
---
Как стартовать APS-проект без боли
1. 🎯 Выберите одну линию как ограничение и зафиксируйте такт.
2. 📊 Снимите факты: просто телефоном или в Excel если ничего больше нет.
3. 🧩 Нарисуйте упрощённый маршрут (≤ 5 операций) и прогоните через APS-движок.
4. 🔄 Сравните расписание с реальными отгрузками.
5. 🚀 Расширяйте охват только после того, как OTD (on-time delivery) вырос хотя бы на 10 pp.
---
ИТОГО:
* APS планирует, MES исполняет.
* Начинайте с тех мест, где можно задать жёсткий такт.
* Всё второстепенное планируется от конца к началу, подчиняясь бутылочному горлышку.
* 1С ≠ APS: не тратьте деньги на безысходность.
* Технормы? Сначала проверяем на пилоте, потом интегрируем.
Пусть завод бьётся в унисон, а не в конвульсиях. 🏭⚡
Что такое APS и с чем его едят
* APS (Advanced Planning & Scheduling) — мозг, который собирает:
📈 спрос → 🏭 мощности → 🔗 материалы → 🔄 переналадки → ⏱ ограничения по времени.
Итог — посекундный график, который реально выполним.
* MES (Manufacturing Execution System) — нервная система цеха. Она исполняет то, что придумал APS: пускает смены, собирает факты, снимает телеметрию, отгружает показатели в ERP.
* APS + MES — когда мозг и нервы идут в одном коробочном решении. Звучит красиво, но не путайте: APS планирует, MES исполняет. Можно внедрить одно без другого, но вместе они творят магию.
---
Принцип №1: не пытайтесь спланировать ВСЁ и сразу
Начните с нормируемых операций — там, где:
* ✔️ оборудование стабильно (линии, печи, роботы),
* ✔️ известен производственный такт,
* ✔️ легко снять фактические часы простоя/работы.
Им именно и задаём такт ⏱. Это «сердцебиение» завода.
Принцип №2: всё подстраивается под главный такт
1. Запланировали линии → получили «бутылочное горлышко».
2. От этого горлышка планируем в обратную сторону:
* 🚚 логисты подгоняют материалы «во что бы то ни стало»,
* 🔧 наладчики крутят гайки ночами, чтобы не сбить такт,
* 📦 склад отчитывается по минутам, как пополняет буфер.
У обеспечивающих служб поначалу нет норм? Так вешаем KPI напрямую от такта: не уложился — видно сразу, где порвалась цепочка.
Принцип №3: «Давайте сделаем в 1С» — путь на кладбище бюджетов
1С - отличная учётная система, но модель оперативного планирования на её базе превращается в:
* бесконечные ТЗ 📜,
* консалт-спринты без результата 🥲,
* миллионные счета за «допилить отчёт».
🔴 Не городите APS внутри ERP! Лучше купить коробочное APS-решение или open-source движок, чем клепать велосипед из регистров.
Принцип №4: нельзя «тупо» импортировать техпроцессы и нормы
* У разных систем разный уровень детализации и представления сменных данных.
* На пилотном проекте лучше вообще без интеграций: вручную заведите 20-30 маршрутов, выверьте такты, размеры партий, времена переналадок.
* Потом уже чистите мастер-данные и пишите коннектор, но только после того, как пилот показал результат.
---
Как стартовать APS-проект без боли
1. 🎯 Выберите одну линию как ограничение и зафиксируйте такт.
2. 📊 Снимите факты: просто телефоном или в Excel если ничего больше нет.
3. 🧩 Нарисуйте упрощённый маршрут (≤ 5 операций) и прогоните через APS-движок.
4. 🔄 Сравните расписание с реальными отгрузками.
5. 🚀 Расширяйте охват только после того, как OTD (on-time delivery) вырос хотя бы на 10 pp.
---
ИТОГО:
* APS планирует, MES исполняет.
* Начинайте с тех мест, где можно задать жёсткий такт.
* Всё второстепенное планируется от конца к началу, подчиняясь бутылочному горлышку.
* 1С ≠ APS: не тратьте деньги на безысходность.
* Технормы? Сначала проверяем на пилоте, потом интегрируем.
Пусть завод бьётся в унисон, а не в конвульсиях. 🏭⚡
🔥1
“1С ERP” знает, сколько метров швеллера вам понадобится (на самом деле нет)… а у нас уже пять проектов стучат в дверь»
Типовая ситуация на любом заводе металлоконструкций
📉 Нет прогноза сделок.
Отдел продаж кидает заявки, когда контракт подписан. Прогноза — ноль, поэтому закупки не могут спланировать поставку, а проект рискует сорваться ещё до старта.
🗂 Спецификация рвётся по этапам и постоянно изменяется
Инженеры собрали полную спецификацию, но сразу внесли изменения, не передав обновленную потребность в закупки.
⏳ Не ведётся прогноз сроков поставок.
В системе товар давно «заказан», но фактический приход — через три недели. Монтаж простаивает, бригаде оплачиваем ожидание.
🛒 Закупки дробятся и дорожают.
Шесть проектов идут параллельно, а заявок шесть — вместо одной агрегированной. Потерян объём, потеряна скидка, деньги размазаны тонким слоем по складу.
🏭 Цех живёт «по ощущениям».
План-график рисуют в Excel. Узкое место на мостовом кране всплывает только утром понедельника, когда сразу все навалилось.
💸 Деньги в излишних запасах, сроки горят.
Без прогноза сделок закупки страхуются «про запас». Листы и профили лежат штабелями, а нужный крепёж везется срочной доставкой. Финансист считает оборачиваемость складов и хватается за голову.
Почему 1С ERP тут не волшебная палочка
1С прекрасна для налогов и ПФР. Но она не:
* собирает прогноз сделок;
* считает прогноз сроков поставок под каждый этап;
* агрегирует заявки по нескольким проектам, учитывая скидку;
* пересчитывает график цеха при переносе монтажа.
1С отражает факты, а не будущее — для планирования нужен отдельный процесс.
Что реально нужно металлоконструкторам
1. Нарисовать цепочку этапов.
Инжиниринг → Резка → Сборка → Монтаж. К каждому этапу — перечень материалов и услуг из единой спецификации.
2. Вести живую спецификацию на весь проект с постоянными обновлениями
Одна цифровая «книга рецептов», которая знает, куда идёт каждая шайба, а не набор разрозненных ведомостей.
3. Запустить регулярный цикл S&OP.
Прогноз сделок → проверка мощностей → план закупок → сверка с финансами. Один ритм для всех.
4. Считать прогноз сроков поставок заранее.
Каждый материал имеет ожидаемый срок прихода; эта информация вшивается в график, а не вспоминается, когда вагон уже ушёл.
5. Агрегировать закупки по всем проектам.
Сводим потребность на неделю-месяц, бьём по поставщикам, берём объёмную скидку. Деньги экономятся, склад не раздувается.
6. Покупать «под заказ» только на базе прогноза.
Когда прогноз точен, закупки берут ровно столько, сколько нужно. Если же покупать строго после подписания контракта, срок выполнения вырастает минимум на время поставки, а оборачиваемость падает.
7. Интегрировать 1С только по документам.
Заказы, накладные, проводки — да. Планирование и оптимизация живут в специализированной системе, дружно связанной с учётной.
Итог
Без цепочки S&OP любое «допиливание» 1С превратится в бесконечное латание дыр.
Сначала ставим процесс: прогнозируем сделки, считаем сроки поставок, агрегируем закупки, ведём одну агрегированную спецификацию.
А потом уже подключаем учётную систему — чтобы фиксировать победы, а не оправдываться за срывы.
Типовая ситуация на любом заводе металлоконструкций
📉 Нет прогноза сделок.
Отдел продаж кидает заявки, когда контракт подписан. Прогноза — ноль, поэтому закупки не могут спланировать поставку, а проект рискует сорваться ещё до старта.
🗂 Спецификация рвётся по этапам и постоянно изменяется
Инженеры собрали полную спецификацию, но сразу внесли изменения, не передав обновленную потребность в закупки.
⏳ Не ведётся прогноз сроков поставок.
В системе товар давно «заказан», но фактический приход — через три недели. Монтаж простаивает, бригаде оплачиваем ожидание.
🛒 Закупки дробятся и дорожают.
Шесть проектов идут параллельно, а заявок шесть — вместо одной агрегированной. Потерян объём, потеряна скидка, деньги размазаны тонким слоем по складу.
🏭 Цех живёт «по ощущениям».
План-график рисуют в Excel. Узкое место на мостовом кране всплывает только утром понедельника, когда сразу все навалилось.
💸 Деньги в излишних запасах, сроки горят.
Без прогноза сделок закупки страхуются «про запас». Листы и профили лежат штабелями, а нужный крепёж везется срочной доставкой. Финансист считает оборачиваемость складов и хватается за голову.
Почему 1С ERP тут не волшебная палочка
1С прекрасна для налогов и ПФР. Но она не:
* собирает прогноз сделок;
* считает прогноз сроков поставок под каждый этап;
* агрегирует заявки по нескольким проектам, учитывая скидку;
* пересчитывает график цеха при переносе монтажа.
1С отражает факты, а не будущее — для планирования нужен отдельный процесс.
Что реально нужно металлоконструкторам
1. Нарисовать цепочку этапов.
Инжиниринг → Резка → Сборка → Монтаж. К каждому этапу — перечень материалов и услуг из единой спецификации.
2. Вести живую спецификацию на весь проект с постоянными обновлениями
Одна цифровая «книга рецептов», которая знает, куда идёт каждая шайба, а не набор разрозненных ведомостей.
3. Запустить регулярный цикл S&OP.
Прогноз сделок → проверка мощностей → план закупок → сверка с финансами. Один ритм для всех.
4. Считать прогноз сроков поставок заранее.
Каждый материал имеет ожидаемый срок прихода; эта информация вшивается в график, а не вспоминается, когда вагон уже ушёл.
5. Агрегировать закупки по всем проектам.
Сводим потребность на неделю-месяц, бьём по поставщикам, берём объёмную скидку. Деньги экономятся, склад не раздувается.
6. Покупать «под заказ» только на базе прогноза.
Когда прогноз точен, закупки берут ровно столько, сколько нужно. Если же покупать строго после подписания контракта, срок выполнения вырастает минимум на время поставки, а оборачиваемость падает.
7. Интегрировать 1С только по документам.
Заказы, накладные, проводки — да. Планирование и оптимизация живут в специализированной системе, дружно связанной с учётной.
Итог
Без цепочки S&OP любое «допиливание» 1С превратится в бесконечное латание дыр.
Сначала ставим процесс: прогнозируем сделки, считаем сроки поставок, агрегируем закупки, ведём одну агрегированную спецификацию.
А потом уже подключаем учётную систему — чтобы фиксировать победы, а не оправдываться за срывы.
🔥1
С чего начинается цифровой завод или почему PLM - фундамент ИТ
1. «Фундамент vs. фасад» 🏗️
Представьте, что вы строите дом с крыши. Красиво? Возможно. Устоит? Вряд ли.
Так и в ИТ-ландшафте: внедрять ERP, не разобравшись с управлением составами изделий, из чего состоит продукт, — значит поставить фасад без основания.
2. Что такое управление составом изделия (BOM) 🔍
- Единственный источник правды о деталях, материалах, рецептурах, ПО, и других входящих в конечный продукт ингридиентах.
- Версионирование и изменения (ECM) с контролем исполнителей и дат.
- Альтернативы и опции: 150 %-BOM хранит все допустимые замены ещё до того, как грянёт дефицит.
Именно эта структура — ядро PLM.
3. Почему все остальное «нанизывается» именно на PLM 🧵
Что ERP берёт из PLM: составы изделий и изменения. Что делает: Считает деньги, закупки, управляется контрактами и пр.
Что APS/MES берет из PLM: Технлогические процессы, нормы, основные и альтернативные варианты изготовлений. Что делает: Планирует операции на линиях, выдает задания в цех и снимает факт производства.
Что SCM/SRM берет из PLM: полный список поставляемых позиций и их аналоги. Что делает: Управляет цепочками поставок, агрегирует закупочные заказы. Ведет историю взаимодействия с поставщиками.
Что CRM/CPQ берет из PLM: Варианты сборок, зависимости, ограничения. Что делает: Конфигурирует изделия под заказ клиента.
Без чистого BOM каждая надстройка получает «свой» набор данных → постоянные пересчёты, ручные выгрузки, конфликт версий.
4. Типовой цикл после внедрения PLM 🔄
- Инженер меняет деталь → создаёт запрос на изменение.
- PLM фиксирует связь «новая версия детали — новая спецификация».
- MRP(ERP) автоматически пересчитывает план закупок и себестоимость.
- APS/MES корректирует маршрут и выдаёт обновлённые инструкции на станки.
- SCM видит замену и предлагает альтернативного поставщика.
Изменение, которое раньше «гуляло» недели, проходит сквозь контур за часы.
5. С чего начать? 🚀
Оцифруйте существующие BOM’ы — пусть спецификации в Excel или из CAD переедут в PLM.
Настройте процесс ECM: роли, статусы, электронные подписи.
Опишите альтернативы и правила их выбора.
Только после этого запускайте ERP-модули MRP, закупки и финансы.
6. Ключевая мысль 💡
BOM — это нить, PLM — игла, а ERP и все остальные системы — бусины.
Попробуйте собирать ожерелье без нити и иглы — получите россыпь данных вместо единого цифрового продукта.
1. «Фундамент vs. фасад» 🏗️
Представьте, что вы строите дом с крыши. Красиво? Возможно. Устоит? Вряд ли.
Так и в ИТ-ландшафте: внедрять ERP, не разобравшись с управлением составами изделий, из чего состоит продукт, — значит поставить фасад без основания.
2. Что такое управление составом изделия (BOM) 🔍
- Единственный источник правды о деталях, материалах, рецептурах, ПО, и других входящих в конечный продукт ингридиентах.
- Версионирование и изменения (ECM) с контролем исполнителей и дат.
- Альтернативы и опции: 150 %-BOM хранит все допустимые замены ещё до того, как грянёт дефицит.
Именно эта структура — ядро PLM.
3. Почему все остальное «нанизывается» именно на PLM 🧵
Что ERP берёт из PLM: составы изделий и изменения. Что делает: Считает деньги, закупки, управляется контрактами и пр.
Что APS/MES берет из PLM: Технлогические процессы, нормы, основные и альтернативные варианты изготовлений. Что делает: Планирует операции на линиях, выдает задания в цех и снимает факт производства.
Что SCM/SRM берет из PLM: полный список поставляемых позиций и их аналоги. Что делает: Управляет цепочками поставок, агрегирует закупочные заказы. Ведет историю взаимодействия с поставщиками.
Что CRM/CPQ берет из PLM: Варианты сборок, зависимости, ограничения. Что делает: Конфигурирует изделия под заказ клиента.
Без чистого BOM каждая надстройка получает «свой» набор данных → постоянные пересчёты, ручные выгрузки, конфликт версий.
4. Типовой цикл после внедрения PLM 🔄
- Инженер меняет деталь → создаёт запрос на изменение.
- PLM фиксирует связь «новая версия детали — новая спецификация».
- MRP(ERP) автоматически пересчитывает план закупок и себестоимость.
- APS/MES корректирует маршрут и выдаёт обновлённые инструкции на станки.
- SCM видит замену и предлагает альтернативного поставщика.
Изменение, которое раньше «гуляло» недели, проходит сквозь контур за часы.
5. С чего начать? 🚀
Оцифруйте существующие BOM’ы — пусть спецификации в Excel или из CAD переедут в PLM.
Настройте процесс ECM: роли, статусы, электронные подписи.
Опишите альтернативы и правила их выбора.
Только после этого запускайте ERP-модули MRP, закупки и финансы.
6. Ключевая мысль 💡
BOM — это нить, PLM — игла, а ERP и все остальные системы — бусины.
Попробуйте собирать ожерелье без нити и иглы — получите россыпь данных вместо единого цифрового продукта.
🔥1
«Купили, но не то»: главная боль проектного производства
Почему двух систем — PLM + SCM — достаточно, а ERP только мешает для компаний, занимающихся проектированием и производством под заказ (Engineering-to-Order, ETO).
1. Что ломает сроки на заводе «под заказ»
Уникальные составы изделий (проектов) BOM’ы — каждое изделие живёт с собственный составом и постоянными ревизиями.
Материалы приходят поздно или «чуть-другие»: модификация конструкции, изменение техпроцессов, как итог срыв сроков и штраф по контракту.
Изменения идут лавиной. Клиент решил поменять ТЗ, его не устраивает предлагаемая марка стали, комплектующих хочет особенные? Меняем в КД, но закупка об этом узнаёт последней.
Простой станков и персонала ≠ главный риск. Когда на участок поступил «правильный» пакет деталей, механо- и сборочные линии успевают нагнать график. Опоздавший болт дороже простоя.
👉 Опоздание или несоответствие поставки — причина ≥ 70 % срывов* в engineer-to-order.
* усреднённые данные аудиторов по ETO-заводам
2. Минимальный цифровой контур для ETO
- PLM. Управлять BOM, версиями и изменениями. У каждой балки, узла, прошивки есть «единственная правда»
- SCM / SRM. Доставить нужный материал в нужный день на основе потребности, сформированной на базе составов в PLM.
Срывает сроки не станок, а болт М36, пришедший на неделю позже.
Другие задачи — склад, финансы, зарплата — не влияют на дедлайн напрямую; их можно держать в «лёгком» бухгалтерском контуре ERP.
3. Логика: как две системы гасят хаос
- Конструктор меняет профиль 200×200 на 250×250.
- PLM фиксирует новую ревизию, закрывает старую.
- SCM тут же аннулирует старый заказ, бронирует новый профиль, подтягивает альтернативных поставщиков.
- Цех получает именно тот металл в момент, когда его ждут.
ERP-лайт просто видит сумму счета и НДС — ему не надо понимать, почему профиль изменился.
⏱️ Раньше на пересогласование + перезаказ уходили недели; теперь — часы.
4. Чем ERP мешает ETO-заводу
- MRP-планирование. Требует фиксированный BOM и циклический спрос → не работает с ревизиями «каждый день».
- Производственный календарь. Каждый продукт нестандартный, с большим количеством изменений, и преимущественно ручным трудом, что делает невозможным даже относительно точный расчет мощностей.
- Сквозной учёт затрат. Строки бюджета «прыгают» при каждом изменении, отчёты устаревают быстрее, чем формируются
Итог: ERP превращается в «ручной Excel-слой», который надо постоянно согласовывать с реальностью, тратя время персонала.
5. Как запустить «2-платформенную» схему PLM + SCM
- Запуск ведения BOM в PLM; Excel и чертежи вне PLM — под запретом.
- Настроить управление изменениями по ролям: минимально обеспечить роль конструктора, технолога, закупщика. Обеспечить сквозное обновление связей.
- Интегрировать SCM непосредственно с PLM, а не через ERP: заказчик меняет узел — поставщик узнаёт за минуту.
- Оставить ERP только для БУ/НУ (финансы, зарплата, склад по факту).
Измерять KPI: время от изменения до подтверждённой поставки. Если > 48 ч — искать узкое место.
6. Ключевая мысль 💡
Срыв проекта начинается не в цехе, а в поставке.
Дайте инженеру PLM, снабжению — SCM, и 80 % «горящих» дедлайнов исчезнут.
Всё остальное можно дописать в учётную «бухгалтерию» потом.
Почему двух систем — PLM + SCM — достаточно, а ERP только мешает для компаний, занимающихся проектированием и производством под заказ (Engineering-to-Order, ETO).
1. Что ломает сроки на заводе «под заказ»
Уникальные составы изделий (проектов) BOM’ы — каждое изделие живёт с собственный составом и постоянными ревизиями.
Материалы приходят поздно или «чуть-другие»: модификация конструкции, изменение техпроцессов, как итог срыв сроков и штраф по контракту.
Изменения идут лавиной. Клиент решил поменять ТЗ, его не устраивает предлагаемая марка стали, комплектующих хочет особенные? Меняем в КД, но закупка об этом узнаёт последней.
Простой станков и персонала ≠ главный риск. Когда на участок поступил «правильный» пакет деталей, механо- и сборочные линии успевают нагнать график. Опоздавший болт дороже простоя.
👉 Опоздание или несоответствие поставки — причина ≥ 70 % срывов* в engineer-to-order.
* усреднённые данные аудиторов по ETO-заводам
2. Минимальный цифровой контур для ETO
- PLM. Управлять BOM, версиями и изменениями. У каждой балки, узла, прошивки есть «единственная правда»
- SCM / SRM. Доставить нужный материал в нужный день на основе потребности, сформированной на базе составов в PLM.
Срывает сроки не станок, а болт М36, пришедший на неделю позже.
Другие задачи — склад, финансы, зарплата — не влияют на дедлайн напрямую; их можно держать в «лёгком» бухгалтерском контуре ERP.
3. Логика: как две системы гасят хаос
- Конструктор меняет профиль 200×200 на 250×250.
- PLM фиксирует новую ревизию, закрывает старую.
- SCM тут же аннулирует старый заказ, бронирует новый профиль, подтягивает альтернативных поставщиков.
- Цех получает именно тот металл в момент, когда его ждут.
ERP-лайт просто видит сумму счета и НДС — ему не надо понимать, почему профиль изменился.
⏱️ Раньше на пересогласование + перезаказ уходили недели; теперь — часы.
4. Чем ERP мешает ETO-заводу
- MRP-планирование. Требует фиксированный BOM и циклический спрос → не работает с ревизиями «каждый день».
- Производственный календарь. Каждый продукт нестандартный, с большим количеством изменений, и преимущественно ручным трудом, что делает невозможным даже относительно точный расчет мощностей.
- Сквозной учёт затрат. Строки бюджета «прыгают» при каждом изменении, отчёты устаревают быстрее, чем формируются
Итог: ERP превращается в «ручной Excel-слой», который надо постоянно согласовывать с реальностью, тратя время персонала.
5. Как запустить «2-платформенную» схему PLM + SCM
- Запуск ведения BOM в PLM; Excel и чертежи вне PLM — под запретом.
- Настроить управление изменениями по ролям: минимально обеспечить роль конструктора, технолога, закупщика. Обеспечить сквозное обновление связей.
- Интегрировать SCM непосредственно с PLM, а не через ERP: заказчик меняет узел — поставщик узнаёт за минуту.
- Оставить ERP только для БУ/НУ (финансы, зарплата, склад по факту).
Измерять KPI: время от изменения до подтверждённой поставки. Если > 48 ч — искать узкое место.
6. Ключевая мысль 💡
Срыв проекта начинается не в цехе, а в поставке.
Дайте инженеру PLM, снабжению — SCM, и 80 % «горящих» дедлайнов исчезнут.
Всё остальное можно дописать в учётную «бухгалтерию» потом.
Огромное количество российских разработчиков ломанулись разрабатывать MES-системы, забыв, что у дома без фундамента стены падают сами собой.
Типовой сценарий «APS-иллюзий»
🧑💻 Разработчик врывается в рынок.
«1С для серьёзного планирования не годится — напишем своё APS!»
📊 Стартовые демо блестят графиками.
Gantt-чарт мельтешит, «оцифровка производства» звучит громко.
📦 А состава изделия… нет.
Про PLM ни строчки: что именно собираем, из каких ревизий, когда внесли изменения — неизвестно.
🔄 Изменения застревают на совещаниях, в почте, в корпоративных мессенджерах.
Инженер поменял деталь, снабженец не узнал, производство выпустило «старую» версию.
🚚 План закупок бьёт мимо цели.
APS рисует «красивый» график выпуска, но каждый второй заказ — неукомплектован.
Итог — откат сроков до прихода «покупнины».
📆 Сдвиги съедают маржу.
Сервис-уровень падает, клиенты недовольны, склад гудит от неликвида.
Почему так происходит?
PLM игнорируется.
Без централизованного управления составами и изменениями APS слеп и глух.
SCM ставят «потом».
Нет сквозной логики запасов и сроков поставок — планирование в вакууме.
1С «для всего».
Учёт-то ведётся, но данные разрознены: финансы живут отдельно от техники и логистики.
Правильный маршрут цифровизации
1️⃣ PLM Управление составами изделий и изменениями - Всегда актуальный и единственный BOM
2️⃣ SCM (DDMRP / S&OP) - Синхронизируем спрос, запасы, поставщиков. Закупаем вовремя и в нужном объёме
3️⃣ APS / MES. Детальное расписание и диспетчеризация. Производство идёт без срывов
Важно: 1С остаётся учётным «контуром», но роль мозга берут на себя специализированные PLM → SCM → APS-системы.
Что делать уже сегодня?
🔍 Проверьте, где вы ведете составы изделий (BOM).
📝 Опишите процесс изменений (ECM). Без него любой планинг - пустая анимация.
🤝 Сведите в единый цикл S&OP. Прогноз → план закупок → финансы — ежемесячно.
🛠 Только потом выбирайте APS/MES. Пусть система планирует то, что реально можно произвести, а не влажные мечты об увеличенных производственных мощностях (на которые не поставлены материалы и комплектующие).
Правильная последовательность цифровизации спасёт и бюджет, и репутацию.
Типовой сценарий «APS-иллюзий»
🧑💻 Разработчик врывается в рынок.
«1С для серьёзного планирования не годится — напишем своё APS!»
📊 Стартовые демо блестят графиками.
Gantt-чарт мельтешит, «оцифровка производства» звучит громко.
📦 А состава изделия… нет.
Про PLM ни строчки: что именно собираем, из каких ревизий, когда внесли изменения — неизвестно.
🔄 Изменения застревают на совещаниях, в почте, в корпоративных мессенджерах.
Инженер поменял деталь, снабженец не узнал, производство выпустило «старую» версию.
🚚 План закупок бьёт мимо цели.
APS рисует «красивый» график выпуска, но каждый второй заказ — неукомплектован.
Итог — откат сроков до прихода «покупнины».
📆 Сдвиги съедают маржу.
Сервис-уровень падает, клиенты недовольны, склад гудит от неликвида.
Почему так происходит?
PLM игнорируется.
Без централизованного управления составами и изменениями APS слеп и глух.
SCM ставят «потом».
Нет сквозной логики запасов и сроков поставок — планирование в вакууме.
1С «для всего».
Учёт-то ведётся, но данные разрознены: финансы живут отдельно от техники и логистики.
Правильный маршрут цифровизации
1️⃣ PLM Управление составами изделий и изменениями - Всегда актуальный и единственный BOM
2️⃣ SCM (DDMRP / S&OP) - Синхронизируем спрос, запасы, поставщиков. Закупаем вовремя и в нужном объёме
3️⃣ APS / MES. Детальное расписание и диспетчеризация. Производство идёт без срывов
Важно: 1С остаётся учётным «контуром», но роль мозга берут на себя специализированные PLM → SCM → APS-системы.
Что делать уже сегодня?
🔍 Проверьте, где вы ведете составы изделий (BOM).
📝 Опишите процесс изменений (ECM). Без него любой планинг - пустая анимация.
🤝 Сведите в единый цикл S&OP. Прогноз → план закупок → финансы — ежемесячно.
🛠 Только потом выбирайте APS/MES. Пусть система планирует то, что реально можно произвести, а не влажные мечты об увеличенных производственных мощностях (на которые не поставлены материалы и комплектующие).
Правильная последовательность цифровизации спасёт и бюджет, и репутацию.
Channel name was changed to «FactoryFlow - производство без хаоса 1С»
Роботы ждут своего часа: почему на российских заводах — штучные установки, а в Германии — десятки тысяч новых манипуляторов ежегодно
Факты без иллюзий
- Германия. По данным Международной федерации робототехники (IFR), в 2022 г. немецкие предприятия смонтировали 25 636 промышленных роботов, а в 2023 г. показали новый рекорд — 28 355 единиц — +7 % за год.
- Россия. Национальная ассоциация участников рынка робототехники (НАУР) насчитала ≈2 100 роботизированных комплексов, введённых в 2023 г. — это всего 7 % от немецкого уровня и менее 1 % от китайского.
В начале десятилетия импорт в РФ держался на ~2 000 роботов в год, что подтверждает многолетнюю «планку» в «пары тысяч», а не в десятки тысяч.
Итого: разрыв на порядок величины.
В то время как Германия ежегодно добавляет сорок с лишним роботов на каждый рабочий день, российскому рынку пока хватает одного-двух на сутки.
Почему производственные роботы в России не находят применения:
📉 Микросерии или штучное производство вместо потока. 500 штук сегодня, 23 завтра, потом новая конфигурация — классический make-to-order.
🔧 Вариантов изделий огромное количество - оснастки не напасешься.
🛠 Дефицит интеграторов. Вся страна опирается на 7-10 компаний-интеграторов — очереди измеряются месяцами.
💼 Управленческая инерция. Там, где немецкий директор сразу «видит» место для манипулятора, российский чаще даже не формулирует ТЗ.
💵 Дешёвая ручная операция. Свариваем «болгаркой и молотком» — и CAPEX в робот кажется неподъёмным.
⚙️ Планирование без такта. Нет фиксированного ритма — нет шанса «подстроить» окружающие процессы под робот.
Корень проблемы
- Низкая повторяемость изделий. Роботы превосходны в массе и ритме, а не в уникальных партиях «по 12 штук».
- Частые изменения конструкции. Каждый эскиз «на коленке» = час перенастройки робота.
- Отсутствие культурной нормы. Робот = «дорогое чудо», а не обыденный инструмент (как пресс или ЧПУ-станок).
- Нехватка компетенций. Инженеры-программисты переходят в IT, а интеграторы забронированы на год вперёд.
- Слабое финансовое плечо. В Германии льготные лизинги и субсидии покрывают 30-40 % стоимости, в РФ пока экспериментируют с пилотными скидками.
Реальное время
Когда роботизация действительно работает
- Повторяемость партии. ≥ 1 000 шт. модели/год
- Стабильность изделия. < 2 рейдизайна/год. Каждый редизайн — новые захваты/программы.
- Цикловое время > 50 % рабочего дня тратится на однотипную операцию, позволяет задать такт.
- Дефицит кадров. Вакансия закрывается > 3 мес. Робот компенсирует «кадровую дыру».
- Окупаемость ≤ 3,5 года при TCO-расчёте (Европейский benchmark для CAPEX)
Как ускорить «настоящее» внедрение
- Стандартизировать изделие. Платформенная архитектура (каркас + модули) сокращает переналадку.
- Внедрить S&OP / APS. Прогноз → план → загрузка робота → закупки; «цифровой двойник» производственного такта.
- Учить руководителей «видеть» роботов. KPI не «стоимость человека/час», а «стоимость цикла/шт».
- Развивать локальные центры компетенций. ЦК сокращают путь «инженер–цех» с месяцев до недель.
Госстимулы по модели CAPEX-50 %. Половину стоимости погашает субсидия при локализации, вторую — лизинг.
Вывод
Промышленная роботизация в РФ не «отстаёт» в технологическом смысле — ей мешает производственная фрагментарность и управленческая инерция. Как только продуктовая линейка стабилизируется, а такт станет бизнес-метрикой, роботы перейдут из «витрины» в «норму». До тех пор задача № 1 — консолидировать спрос (укрупнять партии, унифицировать оснастку) и растить интеграторов. Тогда «сотни в год» превратятся в «десятки тысяч» — доказано примером Германии.
Факты без иллюзий
- Германия. По данным Международной федерации робототехники (IFR), в 2022 г. немецкие предприятия смонтировали 25 636 промышленных роботов, а в 2023 г. показали новый рекорд — 28 355 единиц — +7 % за год.
- Россия. Национальная ассоциация участников рынка робототехники (НАУР) насчитала ≈2 100 роботизированных комплексов, введённых в 2023 г. — это всего 7 % от немецкого уровня и менее 1 % от китайского.
В начале десятилетия импорт в РФ держался на ~2 000 роботов в год, что подтверждает многолетнюю «планку» в «пары тысяч», а не в десятки тысяч.
Итого: разрыв на порядок величины.
В то время как Германия ежегодно добавляет сорок с лишним роботов на каждый рабочий день, российскому рынку пока хватает одного-двух на сутки.
Почему производственные роботы в России не находят применения:
📉 Микросерии или штучное производство вместо потока. 500 штук сегодня, 23 завтра, потом новая конфигурация — классический make-to-order.
🔧 Вариантов изделий огромное количество - оснастки не напасешься.
🛠 Дефицит интеграторов. Вся страна опирается на 7-10 компаний-интеграторов — очереди измеряются месяцами.
💼 Управленческая инерция. Там, где немецкий директор сразу «видит» место для манипулятора, российский чаще даже не формулирует ТЗ.
💵 Дешёвая ручная операция. Свариваем «болгаркой и молотком» — и CAPEX в робот кажется неподъёмным.
⚙️ Планирование без такта. Нет фиксированного ритма — нет шанса «подстроить» окружающие процессы под робот.
Корень проблемы
- Низкая повторяемость изделий. Роботы превосходны в массе и ритме, а не в уникальных партиях «по 12 штук».
- Частые изменения конструкции. Каждый эскиз «на коленке» = час перенастройки робота.
- Отсутствие культурной нормы. Робот = «дорогое чудо», а не обыденный инструмент (как пресс или ЧПУ-станок).
- Нехватка компетенций. Инженеры-программисты переходят в IT, а интеграторы забронированы на год вперёд.
- Слабое финансовое плечо. В Германии льготные лизинги и субсидии покрывают 30-40 % стоимости, в РФ пока экспериментируют с пилотными скидками.
Реальное время
Когда роботизация действительно работает
- Повторяемость партии. ≥ 1 000 шт. модели/год
- Стабильность изделия. < 2 рейдизайна/год. Каждый редизайн — новые захваты/программы.
- Цикловое время > 50 % рабочего дня тратится на однотипную операцию, позволяет задать такт.
- Дефицит кадров. Вакансия закрывается > 3 мес. Робот компенсирует «кадровую дыру».
- Окупаемость ≤ 3,5 года при TCO-расчёте (Европейский benchmark для CAPEX)
Как ускорить «настоящее» внедрение
- Стандартизировать изделие. Платформенная архитектура (каркас + модули) сокращает переналадку.
- Внедрить S&OP / APS. Прогноз → план → загрузка робота → закупки; «цифровой двойник» производственного такта.
- Учить руководителей «видеть» роботов. KPI не «стоимость человека/час», а «стоимость цикла/шт».
- Развивать локальные центры компетенций. ЦК сокращают путь «инженер–цех» с месяцев до недель.
Госстимулы по модели CAPEX-50 %. Половину стоимости погашает субсидия при локализации, вторую — лизинг.
Вывод
Промышленная роботизация в РФ не «отстаёт» в технологическом смысле — ей мешает производственная фрагментарность и управленческая инерция. Как только продуктовая линейка стабилизируется, а такт станет бизнес-метрикой, роботы перейдут из «витрины» в «норму». До тех пор задача № 1 — консолидировать спрос (укрупнять партии, унифицировать оснастку) и растить интеграторов. Тогда «сотни в год» превратятся в «десятки тысяч» — доказано примером Германии.
Channel name was changed to «FactoryFlow - производство без хаоса»
На большинстве заводов и холдингов сегодня царит «зоопарк» приложений: ERP ведёт финансы, CRM — клиентов, PDM — чертежи, MES — цех, E-Proc — тендеры… Каждое звено «по-своему право», но единой сквозной картины нет.
И самое удивительное — готовой MonoCore-системы на рынке до сих пор нет: только «ещё-одна-ERP» или «ещё-одна-APS». Посмотрим, что нам это стоит и почему пора делать ставку на единую корпоративную среду управления.
Типовой сценарий «зоопарка систем»
📂 Дубли мастер-данных. Артикул «123-A/1» живёт в ERP, «123-A_rev1» — в PDM, а в MES его зовут «123A». Данные улетают «не туда» — ищите крайних.
🔗 Интеграционные гирлянды. Обновление версии 1С → падают кастомные интеграции, недели «горящих» фиксов.
⏳ Зависшие изменения. Конструктор сменил материал на детали, но до планировщика APS доехало спустя 10 дней, а закупки уже «выстрелили» старый материал.
💰 Стоимость владения раздувается. Лицензии + сопровождение + обновления = десятки миллионов рублей в год. И это без учёта потерь от несинхронизированных запасов.
🛑 Стоп-фактор инноваций. Любой AI-пилот тонет в согласованиях доступа к десятку БД.
Почему рынка MonoCore до сих пор нет?
(Спойлер: дело не только в консервативных заказчиках)
1. Инертность и возражения рынка
- «У нас уже 1С + PDM + MES — просто докрутим»
Кажется дешевле «доработать привычное», но каждое обновление 1С рвёт кастомные API, а разрывы CRM → BOM → MRP всё равно остаются.
- «Перенести BOM — титанический труд».
На деле миграция нужна лишь для живых позиций: парс CAD → Excel-шаблон → API-импорт. 2 инженера × 3 мес. = 10 000 строк, и половина номенклатуры спокойно «доживает» в старой 1С-могиле.
- «Будем работать в нескольких системах сразу».
В MonoCore весь операционный цикл — в одном веб-кокпите; в старую ERP заходит только главбух для редких операций.
2. …и узость самих разработчиков
- Синдром «пилю то, что знаю».
Команды выросли из доработок отдельных подсистем (MES-shop, PDM-cad, CRM-web) и боятся «залезать не в свою епархию». В итоге появляется ещё одна MES вместо сквозного ядра.
- Кадровая специализация по вертикали, а не по процессу
— Java-бэкендер, что писал WMS, не знает, как строится AI-прогноз спроса.
— Data-science-группа умеет LSTM, но не представляет физику смены ревизии в цехе.
Чтобы сварить MonoCore, нужны T-shape инженеры, видящие и финансы, и механику склада, и ML — таких мало и они заняты «латанием» текущих ERP.
- Отсутствие доменных библиотек
Каждый вендор городит свой BOM-движок, свой планировщик мощностей, своё MDM-ядро. Нет общих open-source-«кирпичей», значит каждое решение начинается «с нуля» и тонет в сроках.
- Финансирование под «быстрый MVP»
Инвестор видит спрос на APS-добавку к популярной ERP — получает прибыль за 18 мес.
MonoCore-платформа требует 3–4 лет R&D и кросс-доменной экспертизы → денег не дают.
Выводы — куда катится «зоопарк» и откуда вырастет MonoCore
1. Пока все собираю ещё один “1С‐костыль”, рынок тихо устает от интеграционных ожогов.
Каждое новое «допиленное» окошко лишь удлиняет цепочку ошибок — а значит, вскоре потребность в едином ядре станет не капризом ИТ-директора, а условием выживания бизнеса.
2. Серая зона породит белого лебедя.
В стороне от громких релизов «ERP v.13» уже собирается команда, знающая и физику цеха, и ML-прогноз, и бухгалтерский контур. Именно там варится MonoCore, потому что крупным вендорам не до долгих четырёх лет R&D, а узкоспециализированные интеграторы не видят всей картины.
3. Деньги потекут за сквозной ценностью, а не за количеством модулей.
Заводы, прожигающие миллионы на гирлянды API, с радостью отдадут те же бюджеты тому, кто покажет одну-единственную «красную кнопку».
4. T-shape-инженеры станут новой нефтью.
Разработчики, умеющие смотреть шире своей «MES-полянки», срастят CRM, BOM, AI и план мощностей в одну логику. Они и станут ядром команды MonoCore — всем остальным придётся переучиваться или уходить в нишевые патчи.
5. Инерция закончится внезапно.
Достаточно одного-двух публичных кейсов с окупаемостью < 20 месяцев, чтобы волна «поделок на 1С» схлынула, а спрос на единый цифровой поток вырос экспоненциально.
И самое удивительное — готовой MonoCore-системы на рынке до сих пор нет: только «ещё-одна-ERP» или «ещё-одна-APS». Посмотрим, что нам это стоит и почему пора делать ставку на единую корпоративную среду управления.
Типовой сценарий «зоопарка систем»
📂 Дубли мастер-данных. Артикул «123-A/1» живёт в ERP, «123-A_rev1» — в PDM, а в MES его зовут «123A». Данные улетают «не туда» — ищите крайних.
🔗 Интеграционные гирлянды. Обновление версии 1С → падают кастомные интеграции, недели «горящих» фиксов.
⏳ Зависшие изменения. Конструктор сменил материал на детали, но до планировщика APS доехало спустя 10 дней, а закупки уже «выстрелили» старый материал.
💰 Стоимость владения раздувается. Лицензии + сопровождение + обновления = десятки миллионов рублей в год. И это без учёта потерь от несинхронизированных запасов.
🛑 Стоп-фактор инноваций. Любой AI-пилот тонет в согласованиях доступа к десятку БД.
Почему рынка MonoCore до сих пор нет?
(Спойлер: дело не только в консервативных заказчиках)
1. Инертность и возражения рынка
- «У нас уже 1С + PDM + MES — просто докрутим»
Кажется дешевле «доработать привычное», но каждое обновление 1С рвёт кастомные API, а разрывы CRM → BOM → MRP всё равно остаются.
- «Перенести BOM — титанический труд».
На деле миграция нужна лишь для живых позиций: парс CAD → Excel-шаблон → API-импорт. 2 инженера × 3 мес. = 10 000 строк, и половина номенклатуры спокойно «доживает» в старой 1С-могиле.
- «Будем работать в нескольких системах сразу».
В MonoCore весь операционный цикл — в одном веб-кокпите; в старую ERP заходит только главбух для редких операций.
2. …и узость самих разработчиков
- Синдром «пилю то, что знаю».
Команды выросли из доработок отдельных подсистем (MES-shop, PDM-cad, CRM-web) и боятся «залезать не в свою епархию». В итоге появляется ещё одна MES вместо сквозного ядра.
- Кадровая специализация по вертикали, а не по процессу
— Java-бэкендер, что писал WMS, не знает, как строится AI-прогноз спроса.
— Data-science-группа умеет LSTM, но не представляет физику смены ревизии в цехе.
Чтобы сварить MonoCore, нужны T-shape инженеры, видящие и финансы, и механику склада, и ML — таких мало и они заняты «латанием» текущих ERP.
- Отсутствие доменных библиотек
Каждый вендор городит свой BOM-движок, свой планировщик мощностей, своё MDM-ядро. Нет общих open-source-«кирпичей», значит каждое решение начинается «с нуля» и тонет в сроках.
- Финансирование под «быстрый MVP»
Инвестор видит спрос на APS-добавку к популярной ERP — получает прибыль за 18 мес.
MonoCore-платформа требует 3–4 лет R&D и кросс-доменной экспертизы → денег не дают.
Выводы — куда катится «зоопарк» и откуда вырастет MonoCore
1. Пока все собираю ещё один “1С‐костыль”, рынок тихо устает от интеграционных ожогов.
Каждое новое «допиленное» окошко лишь удлиняет цепочку ошибок — а значит, вскоре потребность в едином ядре станет не капризом ИТ-директора, а условием выживания бизнеса.
2. Серая зона породит белого лебедя.
В стороне от громких релизов «ERP v.13» уже собирается команда, знающая и физику цеха, и ML-прогноз, и бухгалтерский контур. Именно там варится MonoCore, потому что крупным вендорам не до долгих четырёх лет R&D, а узкоспециализированные интеграторы не видят всей картины.
3. Деньги потекут за сквозной ценностью, а не за количеством модулей.
Заводы, прожигающие миллионы на гирлянды API, с радостью отдадут те же бюджеты тому, кто покажет одну-единственную «красную кнопку».
4. T-shape-инженеры станут новой нефтью.
Разработчики, умеющие смотреть шире своей «MES-полянки», срастят CRM, BOM, AI и план мощностей в одну логику. Они и станут ядром команды MonoCore — всем остальным придётся переучиваться или уходить в нишевые патчи.
5. Инерция закончится внезапно.
Достаточно одного-двух публичных кейсов с окупаемостью < 20 месяцев, чтобы волна «поделок на 1С» схлынула, а спрос на единый цифровой поток вырос экспоненциально.
О вреде и пользе мониторинга станков
Типовой перечень вопросов, на который нужно ответить перед принятием решения о мониторинге станков выглядит следующим образом:
🪵 Узкое место всегда найдётся. Расширил одно — подперло другое. Зачем что-то мерить?
📦 Главные простои из-за материалов, а не работы оборудования. Нет металла — какая разница, что шпиндель работает не в самом производительном режиме?
🔀 Маршруты и техпроцессы постоянно меняются. Такт рвётся, ритм сбивается — мониторинг что-то изменит?
🎲 Операторы сами решают, что точить. Сегодня «удобное», завтра «срочное». Куда тут датчики вставлять?
⚙️ Можно просто «выкрутить» режимы резания. Станок быстрее, а материалы всё равно ждём.
Где правда, брат?
Станочный мониторинг не лечит все болезни. Он нужен, когда вы готовы лечиться по протоколу, а не «по ощущениям».
Последовательность внедрения:
- Управление составами изделий (BOM). Чёткая структура продукта, строгий change-management в PDM/PLM.
- Согласованное обеспечение цехов. DDMRP / MRP-II + сквозной S&OP гарантируют, что всё нужное приезжает вовремя.
- Утверждённые ЧПУ-программы. DNC-сервер, контроль ревизий NC — чтобы одна деталь точилась одинаково.
- Оперативный производственный план. APS отвечает, кто-что-когда делает сегодня, завтра, послезавтра.
- Мониторинг узких переделов. MES/ОЕЕ-система с датчиками проверяет, выполняется ли план «на земле».
📌 Правило: сначала план, потом замер. Иначе фиксируем хаос вместо процесса.
«А если всё равно материал не пришел?»
- Фиксирует факт простоя, а не версию сменного мастера.
- Разделяет "нет заказа", "нет материала", "нет инструмента" и пр. Разные триггеры — разные действия.
- Даёт честный такт для APS. Планировщик видит реальную, а не паспортную производительность.
- Успокаивает споры о новых станках. Данные показывают, сколько шпиндель реально режет, а не стоит.
Когда мониторинг точно лишний
- Нет верифицированного BOM.
- Маршруты не согласованы.
- Показатели мониторинга и успеха не определены.
Итоговая дорожная карта
1. Навести порядок в данных изделия (BOM, ревизии, маршруты).
2. Обеспечить стабильный поток материалов под утверждённые составы.
3. Синхронизировать цеха через оперативное планирование (APS).
4. Раздать станкам актуальные NC-программы и зафиксировать их версии.
5. Включить мониторинг только на ключевых переделах:
- подтвердить расчётный такт;
- выявить скрытые потери;
- аргументировать инвестиции.
Станочный мониторинг — это не «магический чип», а лаборатория проверки гипотез.
Когда диагноз понятен, он экономит миллионы; когда плана нет — он просто измеряет хаос.
Типовой перечень вопросов, на который нужно ответить перед принятием решения о мониторинге станков выглядит следующим образом:
🪵 Узкое место всегда найдётся. Расширил одно — подперло другое. Зачем что-то мерить?
📦 Главные простои из-за материалов, а не работы оборудования. Нет металла — какая разница, что шпиндель работает не в самом производительном режиме?
🔀 Маршруты и техпроцессы постоянно меняются. Такт рвётся, ритм сбивается — мониторинг что-то изменит?
🎲 Операторы сами решают, что точить. Сегодня «удобное», завтра «срочное». Куда тут датчики вставлять?
⚙️ Можно просто «выкрутить» режимы резания. Станок быстрее, а материалы всё равно ждём.
Где правда, брат?
Станочный мониторинг не лечит все болезни. Он нужен, когда вы готовы лечиться по протоколу, а не «по ощущениям».
Последовательность внедрения:
- Управление составами изделий (BOM). Чёткая структура продукта, строгий change-management в PDM/PLM.
- Согласованное обеспечение цехов. DDMRP / MRP-II + сквозной S&OP гарантируют, что всё нужное приезжает вовремя.
- Утверждённые ЧПУ-программы. DNC-сервер, контроль ревизий NC — чтобы одна деталь точилась одинаково.
- Оперативный производственный план. APS отвечает, кто-что-когда делает сегодня, завтра, послезавтра.
- Мониторинг узких переделов. MES/ОЕЕ-система с датчиками проверяет, выполняется ли план «на земле».
📌 Правило: сначала план, потом замер. Иначе фиксируем хаос вместо процесса.
«А если всё равно материал не пришел?»
- Фиксирует факт простоя, а не версию сменного мастера.
- Разделяет "нет заказа", "нет материала", "нет инструмента" и пр. Разные триггеры — разные действия.
- Даёт честный такт для APS. Планировщик видит реальную, а не паспортную производительность.
- Успокаивает споры о новых станках. Данные показывают, сколько шпиндель реально режет, а не стоит.
Когда мониторинг точно лишний
- Нет верифицированного BOM.
- Маршруты не согласованы.
- Показатели мониторинга и успеха не определены.
Итоговая дорожная карта
1. Навести порядок в данных изделия (BOM, ревизии, маршруты).
2. Обеспечить стабильный поток материалов под утверждённые составы.
3. Синхронизировать цеха через оперативное планирование (APS).
4. Раздать станкам актуальные NC-программы и зафиксировать их версии.
5. Включить мониторинг только на ключевых переделах:
- подтвердить расчётный такт;
- выявить скрытые потери;
- аргументировать инвестиции.
Станочный мониторинг — это не «магический чип», а лаборатория проверки гипотез.
Когда диагноз понятен, он экономит миллионы; когда плана нет — он просто измеряет хаос.
«Хотели “один-единственный 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, который работает не только в чертежах, но и в цеху, на складе и даже у клиента.
а получили десяток 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, который работает не только в чертежах, но и в цеху, на складе и даже у клиента.
🔥3❤2👍2🙊1
Что такое 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-модуль, а управленческая привычка.
Когда привычка закреплена, система лишь убирает рутину и делает цифры прозрачными.
Любая компания что-то покупает → что-то с этим делает → кому-то продаёт.
Пока сделок немного, всё держится в голове руководства, либо разрозненных табличках 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-модуль, а управленческая привычка.
Когда привычка закреплена, система лишь убирает рутину и делает цифры прозрачными.
❤1🔥1
Самое дорогое в машиностроении — коммерческое предложение, которого не будет
Уравнение суровое: инженеры тратят до половины фонда своего рабочего времени, чтобы описать изделие, которое никогда не увидит свет.
Конкурс проигран, а время и деньги сгорели.
---
⚙️ Как мы докатились
Сегодня большинство заводов работает по схемам 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 → производство».
---
🎯 Итог
Пока конкуренты отправляют «чуть-чуть не то» через две недели,
вы уже подготовили правильное КП в несколько кликов.
Уравнение суровое: инженеры тратят до половины фонда своего рабочего времени, чтобы описать изделие, которое никогда не увидит свет.
Конкурс проигран, а время и деньги сгорели.
---
⚙️ Как мы докатились
Сегодня большинство заводов работает по схемам 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 → производство».
---
🎯 Итог
Пока конкуренты отправляют «чуть-чуть не то» через две недели,
вы уже подготовили правильное КП в несколько кликов.
❤4🔥2
Взлёт и падение 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, рынок уже голосует курсором: писать текст оказалось проще, чем тянуть стрелочки.
✈️ Пики спроса
В пандемийный 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, рынок уже голосует курсором: писать текст оказалось проще, чем тянуть стрелочки.
👍5❤1🔥1💯1