Кейс: производитель станков связал закупки с заказами клиентов
Кто клиент
Компания проектирует и выпускает небольшие промышленные станки и технологическую оснастку под требования заказчиков. В производстве работают конструкторский отдел, механический участок, сборка и испытания. Одновременно выполняются от 20 до 35 заказов разной сложности.
Большая часть металла и стандартного крепежа хранится на складе. Электродвигатели, приводы, датчики, контроллеры и специальные подшипники закупаются под конкретный проект. Срок поставки некоторых компонентов достигает восьми недель.
Что было до проекта
Менеджер фиксировал состав станка в коммерческом предложении. После оплаты конструктор готовил спецификацию, производство — отдельный план, а закупщик вручную переносил потребность в таблицу. Между документами не было сквозной связи.
Что было
- несколько версий спецификации;
- потребность собирают в Excel;
- склад не видит назначение резерва;
- срок поставки уточняют вручную;
- дефицит находят после запуска.
Что внедрили
- заказ клиента как источник потребности;
- ресурсные спецификации;
- заказы на производство;
- обособленное обеспечение;
- график закупок и поставок.
Что изменилось
- виден источник каждой потребности;
- дефицит определяется до запуска;
- поставка влияет на срок заказа;
- изменения проходят согласование;
- руководитель видит исключения.
Почему закупки не успевали
Проблема выглядела как слабая работа снабжения, но аудит показал разрыв данных:
- заказ клиента не был связан с производственной потребностью;
- конструктор менял состав после передачи таблицы закупщику;
- одинаковый компонент назывался по-разному в спецификациях;
- складской остаток не разделялся на свободный и зарезервированный;
- поставка считалась обеспечением сразу после создания заказа поставщику;
- плановая дата запуска не учитывала длинный срок закупки;
- аналоги применялись без фиксации изменения конструкции.
Закупщик получал финальную потребность слишком поздно и вынужден был ускорять поставку, дробить заказы или искать более дорогой аналог.
Цель проекта
Компания сформулировала цель не как «внедрить 1С:ERP», а как единый управленческий процесс:
заказ клиента → согласованная спецификация → заказ на производство → потребность в материалах → резерв или закупка → подтверждённая дата поставки → обеспеченный запуск → выпуск и отгрузка.
Для каждого дефицита руководитель должен видеть, какой заказ клиента находится под угрозой, кто отвечает за поставку и насколько изменение даты повлияет на выпуск.
Шаг 1. Очистили номенклатуру
Перед настройкой процессов объединили дубли комплектующих, назначили единицы измерения, производителей и допустимые аналоги. Для покупных изделий зафиксировали основной срок поставки, минимальную партию и поставщика.
Важным результатом стала единая карточка компонента для конструктора, склада и снабжения. До этого один датчик мог существовать как «датчик индуктивный», «ДИ-18» и артикул поставщика.
Шаг 2. Настроили ресурсные спецификации
Типовые узлы станка описали ресурсными спецификациями: рама, привод, шкаф управления, защитное ограждение и оснастка. Спецификация содержит выходное изделие, материалы, полуфабрикаты, трудозатраты и последовательность этапов.
Для конфигурируемых изделий использовали варианты и параметры. Это позволило не копировать полностью новую спецификацию при каждом изменении мощности двигателя или размера рабочей зоны.
Шаг 3. Сделали заказ клиента источником потребности
После технического согласования заказ клиента запускал заказ на производство. Материальная потребность больше не возникала из отдельной таблицы. Система показывала её источник и назначение.
Стандартные материалы обеспечивались из свободного остатка. Дорогие и специальные комплектующие закупались обособленно под заказ. Благодаря этому двигатель, купленный для одного проекта, нельзя было незаметно отдать другому.
Шаг 4. Связали производство и снабжение
Рабочее место «Состояние обеспечения заказов» использовали как общую точку контроля. По каждому заказу проверялись:
- общая потребность по спецификации;
- свободный и зарезервированный остаток;
- уже заказанное количество;
- подтверждённая дата поставки;
- необеспеченные позиции;
- заказ клиента и этап, который зависит от материала.
В 1С:ERP заказ поставщику может формироваться на основании расчёта потребности. В документе фиксируются условия, желаемая дата поступления и график оплаты. Это позволило отказаться от дублирующего реестра снабжения.
Шаг 5. Ввели контроль изменений
После запуска заказа спецификацию нельзя было менять незаметно. Конструктор создавал изменение с причиной: требование клиента, недоступность компонента, исправление ошибки или технологическая замена.
Система пересчитывала потребность. Закупщик видел, что нужно отменить, заказать или переназначить. Менеджер получал сигнал, если изменение влияло на цену или срок клиента.
Шаг 6. Подтверждали реалистичный срок
До проекта менеджер называл срок по опыту и позже уточнял его у производства. Теперь проверялись три ограничения:
- готовность конструкции и спецификации;
- доступность материалов и даты поставок;
- график производственных этапов и рабочих центров.
Если редкий привод поступал позже плановой сборки, система показывала ограничение до обещания клиенту. Менеджер мог согласовать другую комплектацию или честную дату.
Управленческий дашборд
Руководителю не требовался длинный перечень всех закупок. На дашборд вынесли исключения:
- заказы с необеспеченными критичными позициями;
- поставки без подтверждённой даты;
- просроченные заказы поставщикам;
- изменения спецификации после закупки;
- материалы, пришедшие позже даты потребности;
- дорогие остатки завершённых проектов;
- срочные закупки и их причины.
Как внедряли
- Недели 1–2. Аудит заказа, конструкторской подготовки, производства и закупок.
- Недели 3–4. Очистка номенклатуры и поставщиков.
- Недели 5–7. Ресурсные спецификации типовых станков.
- Недели 8–9. Обеспечение, резервы и заказы поставщикам.
- Недели 10–11. Производственный график и контроль изменений.
- Неделя 12. Пилот на трёх реальных заказах.
- Недели 13–14. Обучение, корректировка нормативов и запуск.
Как рассчитаны результаты
Время подтверждения считалось от технического согласования заказа до передачи клиенту проверенной даты выпуска. Срочной считалась незапланированная закупка с ускоренной доставкой или заменой поставщика.
Запуском без обеспечения считался заказ, по которому на дату начала отсутствовал хотя бы один критичный материал без подтверждённой поставки. Связность потребностей измерялась долей строк материалов, имеющих источник — заказ клиента или внутренний заказ на производство.
Показатели сравнивались на сопоставимом потоке заказов после трёх месяцев стабильной работы. Это модельные цифры: результат конкретного предприятия зависит от длительности цикла, качества спецификаций и дисциплины поставщиков.
Что можно повторить
- Определить заказ клиента как источник позаказной потребности.
- Убрать дубли компонентов до настройки планирования.
- Разделить складское и обособленное обеспечение.
- Зафиксировать сроки поставки критичных комплектующих.
- Связать ресурсную спецификацию с заказом на производство.
- Запретить неучтённые изменения после запуска.
- Контролировать не весь список, а исключения и угрозы сроку.
- Проверить схему на нескольких реальных заказах.
Как помогает KULPS
KULPS описывает сквозной процесс от заявки клиента до снабжения и выпуска, очищает нормативно-справочную информацию, проектирует правила обеспечения и настраивает 1С:ERP. Проект запускается поэтапно, с пилотом и измеримыми контрольными показателями.
Если закупка узнаёт о дефиците после запуска заказа, закажите аудит. Покажем, где разрывается связь между клиентом, спецификацией, производством и поставщиком, и подготовим архитектуру автоматизации.