В последнее время наблюдается значительное увеличение количества разных промышленных предприятий, заявляющих о внедрении систем ERP. Если раньше речь шла о десятках таких компаний, то сегодня их число исчисляется сотнями, причем преимущественно в сфере исключительно дискретного производства. В нашем повествовании Под “производственной ERP” подразумеваются системы, претендующие на это звание. Наиболее распространенными системами ERP, используемыми в производстве по нашим наблюдениям, являются BaaN/InforLN, InforERPSyteLine, а также растущая группа предприятий, использующих 1С. В меньшей степени встречаются SAPERP и другие реже используемые системы. Данная статья будет полезна для опытных пользователей ERP, в первую очередь для тех, кто работает с позаказным типом производства (производство под заказ или на склад, включая производство по прогнозу спроса) и уже автоматизировал процессы учета хода производства, такие как формирование производственных заданий.

В разных системах: SFC-заказы, Job-Orders, JOBs, Заказы на Производство, Производственные заказы и т.п.) и их отслеживания, но так и не смог уверенно производство (и поставки – МТО (Материально-Техническое Обеспечение)) планировать, как и не смог поставить мониторинг производства, в т.ч. и позаказный. С непрекращающимися попытками все-же запустить планирование, и/или с попытками обеспечить планирование с использованием волшебных алгоритмов и/или систем типа APS, MES.

В силу ограниченности объема статьи мы не будет останавливаться на разборе того, почему «традиционные» ERP плохо внедряются и/или работают И для планирования И для управления производством, а также на разборе того, почему «магия» APS или MESсистем превращается на большинстве наших заводов в шарлатанство. Цель статьи – показать, как определенной категории предприятий, которые узнают себя в написанном ниже, построить замкнутую систему планирования/мониторинга не на обломках, но с использованием того, что есть сейчас.

Уверены, что настоящая статья будет интересна также и заводам или холдингам, только стоящим перед выбором системы или в начале проекта внедрения. Т.к. поможет избежать традиционных ошибок, наблюдаемых нами на протяжении последних примерно 8 лет.

Постановка задачи для типичного позаказного производственного бизнеса

Типичные жалобы, следствия и причины

1. «Счетные» бизнес-проблемы предприятия.
   • Неуправляемые срывы сроков выполнения заказов, в особенности, в условиях частных изменений заказов (прием новых, изменение существующих) –> потеря оборота.
   • Увеличенные (высокие, относительно прибыли) трудозатраты на администрирование производства, авральные работы –> увеличенные издержки.
   • Неоптимальный (высокий, относительно оборота) объем НзП (Незавершенное производство)
     увеличенные издержки, увеличенные циклы, потеря пропускной способности (недостаточная пропускная способность) производства.
2. Являются следствием….
   • Невозможности надежного «прогнозирования» (должно быть — расчета плановых/расчетных дат) сроков выполнения заказов клиентов.
   • Отсутствия информации о существующих и будущих (по всему циклу производства) проблемах в выполнении заказа.
   • Неоптимальной загрузки узких мест (обрабатывают не то, не в то время, не в той последовательности).
3. Являются следствиями следующих (некорневых!) причин.
   • Отсутствие формализованной системы быстрого <позаказного> планирования:
     1) с учетом загрузки узких мест (очередь обработки составляющих заказа);
     2) с учетом приоритетов заказов.
   • Отсутствие прослеживаемости и визуализации состояния заказа(ов) по всей производственной цепочке.

Цель

1. Надежное определение сроков выполнения заказа – для разовых и срочных заказов. С учетом циклов производства/закупки (по критическим «веткам» состава изделиязаказа) и с учетомсвободных запасов (материалов, ПКИ (покупных комплектующих изделий), НзП) и ожидаемых приходов по ЗП (заказы поставщикам) и ПЗ.
2. Минимизация средневзвешенных срывов сроков для «долгосрочных заказов»:
   1. через общую балансировку выпуска,
   2. через приоретизированный план производства и исполнение,
   3. через контроль исполнения плана с визуализацией отклонений от сроков.
3. Максимально-эффективная загрузка узких мест.

Типичная модель планирования типичного завода с недовнедренной «производственной ERP»

Общее описание

1. В настоящее время для управления производством и поставками используется «производственная ERP».
2. Управление МТО, Учет хода производства, Управление запасами, в т.ч. производственными – очень часто сделаны на хорошем уровне.
3. При этом, Планирование реализовано частично, с использованием не предназначенных для этого функций системы и/или — самостоятельных разработок.
   • Планирование выпуска («Верхний» уровень планирования – формирование Основного Производственного Плана). Никак не реализовано, или реализовано в MS-Excel. Без привязки к модели и параметрам реального производства. Без учета существующего состояния производства:
     1) выполняемых или запланированных к запуску ПЗ/ЗП,
     2) запасов ПКИ, материалов и НзП, в разных статусах «закрепления» (распределения) за заказами клиентов,
     3) свободных/ожидаемых запасов готовых изделий, выпускаемых «на склад» (под прогноз спроса или точку перезаказа),
     4) с учетом ресурсной модели (ресурс = специальность), но без необходимой детализации.
   • Планирование производства (Уровень планирования — Синхронизированное Планирование Производства и Поставок).

     1) Планирование производства реализовано через создание производственных заданий (объектов управления исполнением!) по всей структуре изделия заказа и расчета дат запуска-выпуска методом простейшего сетевого планирования (конец работ — цикл производства = начало. = конец входящего компонента — …). Такой подход не обеспечивает необходимой для достижения указанных выше целей информации и имеет массу недостатков (см.ниже), в силу чего для реального планирования и управления производством практически не используется. Производство управляется «вручную», ПЗ используются только для учета!

     2) Поставки (МТО) планируются под сформированные ПЗ. Точность такого плана = точности планирования ПЗ, т.е. – достаточно низкая. Но т.к. «позаказные составы изделия» (или — «цепочка ПЗ») заведомо растянуты и не учитывают существующих запасов, МТО почти всегда удается не допускать дефицитов производства. В отсутствии системы планирования, которая постоянно учитывает внутренние (производство, МТО, запасы) и внешние (заказы, прогнозы) изменения, это достигается, очевидно, завышенными запасами материалов и ПКИ.

Детальный разбор используемой модели планирования

Модель планирования

1. Объекты управления исполнением (Производственные задания ПЗ) используются не по назначению — не для управления исполнением, но для созданияПроизводственного (позаказного) Состава Изделия (ПСИ), а также — для позаказного планирования (попытки планирования). При отсутствии в ИТ-системе функций <сквозного> позаказного планирования и позаказного состава это становится единственным вариантом, позволяющим <хоть как-то> управлять всей цепочкой выполнения заказа клиента (ЗК). Такой подход имеет следующие принципиальные недостатки.
   • ПСИ, созданный с использованием объектов исполнения — фиксированный. Изменения, возникающие, например, в КСИ/ТСИ (Конструкторский/Технологический составы) из-за конструкторско-технологических изменений, могут учитываться только вручную. На практике, при большом объеме объектов управления это означает: <никак>. Как результат — ошибки в планах, решаемые только через трудоемкое и неэффективное ручное управление.
   • ПЗ, по определению, плохо обрабатываются планировщиками 2го уровня производственного планирования (планировщики-синхронизаторы, APSPlanner’ы и даже MRP, в т.ч. <позаказные> — см. ниже). В т.ч. потому, что для планировщика ПЗ — это фиксированные ожидаемые приходы, а не рассчитываемые планировщиком гибкие <элементы> ПСИ(плановые заказы, pln).
   • При планировании ПСИ, смоделированного на основании ПЗ, не учитываются запасы и ожидаемые приходы ДСЕ, которые могут быть использованы для выполнения данного заказа, в соответствии с правилами распределения/разметки запасов/ожидаемых приходов.
2. Планирование выполняется через алгоритм собственной разработки, в одну итерацию, с разузлованием состава, определением потребных количеств брутто (!) и смещением влево дат начала ПЗ. При этом используется имеющийся ограниченный набор времен пооперационной модели (пооперационный маршрут), для операций которой (модели), как правило, не определены необходимые для планирования времена, типа <время до>, <время после>, <буфер до>, <буфер после>, <время очереди>, <время перемещения> и т.п. Это приводит к большим и трудно управляемым погрешностям рассчитываемых сроков.
3. Под спланированные ПЗ через стандартный алгоритм планирования рассчитываются потребности в закупаемых материалах и ПКИ, формируются объекты управления — ожидаемые приходы, ЗП.

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

Критическая проблема №1

В случае наличия запаса в производстве или ожидаемого прихода ДСЕ, которые могут быть использованы для выполнения заказа (что вполне может случится из-за изменений в ПСИ другого заказа, изменений приоритетов/дат заказов и многих других причин), — потребности производства и закупок принципиально меняются — см. пример на рисунках выше. Прежний <жестко-позаказно-идеальный> план может быть изменен только вручную (реально, для сотен и тысяч объектов управления — ПЗ, это крайне затруднительно и не выполняется). Это приводит к перезакупке материалов и ПКИ, а в итоге — к <замораживанию> оборотки, потенциальным неликвидам, и перепроизводству. Если с перезакупкой плохо, но как-то еще можно жить (если нет проблем с обороткой:) — т.к. <пойдет на другие заказы:>, то производство <ненужных> <сейчас> ДСЕ, особенно в узких местах, отнимает драгоценные <рубле-часы> всего оборота завода. Как результат — уменьшение оборота, прибыли (в т.ч. за счет доп.расходов на авралы), срывы сроков заказов. Как итог — потеря/неувеличение доли рынка.

Еще одна проблема использования такого простейшего планирования — фактическое отсутствие реакции на происходящее в производстве/закупках. Неправильное определение или даже потеря приоритетов ЗК в <черном ящике> производства. Даже и прежде всего при определении очередности обработки заказов (частей <изделия>заказа) в УМ (узких местах).

Критическая проблема №2

Допустим, первоначальное планирование (это маловероятно с использованием только 2го уровня планирования, но теоретически возможно) обеспечивает квази-оптимальную (близкую к оптимальной) загрузку узкого места.

1. Однако, отсутствие быстрого и частого перепланирования по всей цепочке выполнения заказа (ресинхронизация) не позволяет учесть такие типичные для реального производства ситуации, как: неустранимый срыв сроков производства/закупки каких-либо комплектующих, изменение приоритетов/дат заказов или их остановка, изменение ТСИ и т.п.
2. Как показано в примере ниже, неустранимый срыв сроков заказа ХХ ведет к переносу сроков его готовности и отгрузки. При этом, при отсутствии системы ресинхронизации, узкое место потеряет время на обработку ДСЕ этого заказа, которые могли бы и должны быть обработаны позже. При наличии новых или срочных заказов, или заказов с устранимыми срывами срока, УМ не сможет обрабатывать их детали, т.к., скорее всего, никто не покажет данному участку правильную последовательность/приоритеты обработки! Как результат — меньший, чем мог бы быть выпуск (готовых изделий), потеря оборота и прибыли.

Критическая проблема №3

Планирование с консолидацией. Планирование с консолидацией производимых ДСЕ, при работе с узкими местами в производственно-логистической цепочке выполнения заказа, также ведет к неправильному использованию времени узкого места. Что, опять же, ведет к потере/недополучении оборота/прибыли. Планирование с позаказной загрузкой узкого места.

Планирование с консолидацией выпускаемых ДСЕ либо по заказу, либо по плану производства. Консолидация по приведенным ниже 2м вариантам планирования приводит к уменьшению пропускной способности производства (выпуску меньшего количества заказов за период).

Основная (корневая)проблема и точка улучшения

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

1. Согласно <Системной динамике> в приложении к сложным производственно-логистическим системам, все они (системы) испытывают постоянные колебания уровня запасов, и потребных/используемых мощностей, обусловленные прежде всего скоростью реакции. См.: Industrial Dynamics, Jay Forrester, Productivity Press, 1961; Factory Physics: Foundations of Manufacturing Management и производные этих работ. Частота и амплитуда колебаний прямо пропорциональны фундаментальной переменной системы — скорости реакции <на внешние и внутренние изменения>, или — времени отклика.
2. Сокращение времени отклика (увеличение скорости реакции) увеличивает частоту колебаний запасов/мощности, но снижает их амплитуду. Амплитуда колебаний запасов (общеизвестная графическая иллюстрация колебаний — пилообразная кривая изменения уровня запасов при партионной закупке/партионной обработке) однозначно определяет объем запасов (за период), в т.ч. объем НзП в системе. При этом, согласно закону Литтла (LittleLow) <Теории очередей>, сокращение уровня запасов приводит к сокращению очередей<ПЗ в ожидании обработки>, т.е. — к сокращению циклов выполнения заказов! Подробнее: <Скорость реакции промышленного предприятия>, Питеркин С.В., интернет.
3. Говоря <русским языком>: чаще планируем, исполняем меньшими (позаказными) партиями — больше можем выполнить заказов в единицу времени.Соотношение, которое приводилJayForrester — <сокращение времени отклика в 2 раза приводит к снижению уровня запасов по всей цепочке в 1,7 раз>. Говоря <русским языком>:

• • просто начинаем (пере) планировать всепроизводственно-логистическую цепочку чаще в 2 раза (вместо <раз в месяц> — <раз в 2 недели>) — увеличиваем выпуск <примерно>в 1,7 раз,
  • просто запускаем минимальные партии ДСЕ в производство — увеличиваем выпуск <примерно>в 1,7 раз,
  • …
    Цифра в 1,7 — расчетная и теоретическая. Значение на практике, естественно, зависит от типа производства-закупок, типа спроса и т.п. Но как минимум, на первые десятки %% улучшения выпуска — рассчитывать можно: Просто изменяя подходы к управлению:
    Однако, глядя правде в глаза, просто изменить подходы к управлению (чаще перепланировать, чаще запускать небольшие партии), в сложном производстве, без адекватной системы планирования — невозможно.

Выводы

1. Приведенные выше случаи — лишь небольшая часть примеров, которые наглядно показывают практическую неработоспособности представленной модели планирования. Описание всех возможных примеров и проблем при ее использовании — выходит за рамки настоящего документа. В дополнение лишь отмечу, что помимо адекватного планирования, такая система не обеспечивает и сколь-нибудь внятного мониторинга происходящего, в т.ч. позаказного мониторинга. Т.е. не дает лицам, принимающим решения, никакого инструмента по повышению продуктивности ручного управления
2. Еще одно, крайне важное замечание! Как видно из описанныхвыше проблем, отсутствие алгоритмов <точного>, <детального>, <оптимизационного>, <планирования до станка/человека>, <планирования с учетом мощностей, , — не являются ключевыми причинами низкой эффективности большинства производственно-логистических систем. А их наличие — совсем не <золотой ключик> к ее повышению.
3. Если у вас еще остались сомнения, по адекватности существующей системы планирования и/или по возможности приведения ее <в чувство> не меняя принципиальных подходов, ответьте на вопрос:<сможет ли существующая <управленческая> Система и поддерживающая ее информационная, обеспечить хотя бы недельное время отклика?>.

Предлагаемая модель планирования: ERP+СПМ

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

Концепция Системы Планирования и Мониторинга (СПМ) Райтстеп

Система планов

1й уровень планирования

Отвечает за моделирование/планирование (выпуска) и балансировку (мощностей). С учетом мощностей. Но, для сохранения внешней простоты и управляемости системы – с планированием с учетом ресурсных ограничений только в узких местах. И/или — с учетом запасов критических закупаемых и/или производимых ДСЕ, и/или с учетом критических циклов выполнения заказа. Как показано на рисунках ниже.

Замечание. 1й уровень планирования мало кто реализует «по-честному». Из-за этого все нерешенные на этом уровне проблемы или конфликты (ресурсов и спроса) «падают» вниз, «на пол» (в производство). Где «решаются»:

1) либо через ежедневные, по 2 и более раз в день планерки,

2) либо, при наличии «сильного» ИТ-отдела предприятия – через попытки разгрести их (проблемы верхнего уровня) путем внедрения систем/функций детального планирования, в т.ч. с учетом мощностей (в т.ч. «готовых» MES-систем). Не зная или не обращая внимания на то, что указанные функции/системы работают только с надежными (адекватными) планами верхнего уровня. Возможно не очень точными, но уже просеянными через «фильтр» балансировки, устранивший основные ресурсные конфликты, в т.ч. и через совещания «Производство vs. Продажи».

Важно! Никакая, даже самая чудесная система планирования, не способна устранить вред, нанесенный производству неправильными обещаниями заказчику (рынку). А обещания – это 1й уровень планирования, никак не «цеховой».

2й уровень планирования и исполнение

2й уровень планирования (синхронизация спроса и внутренней ситуации на производстве/в МТО) и далее, исполнения:

• строится на модели «нормального» формирования ПСИ под каждый заказ,
• с их (заказов — ПСИ) последовательным (по приоритетам) планированием,
• с учетом дат и приоритетов заказов,
• с учетом мягкого/жесткого/условного (пере)распределения запасов и ожидаемых приходов (ЗП, ПЗ) под потребности заказов,
• с возможностью консолидированного исполнения (при позаказном планировании!)

С постоянной (не реже, чем еженощно) актуализацией «директивной» версии плана (от даты заказа, с учетом приоритетов, «вниз и влево» — «как должно быть»), и расчетной – «как получается…». Через сравнение которых и строятся весь позаказный и производственный «мониторинг», принимаются оперативные решения.

Создание целостной системы

1. При наличии хорошо внедренной в части учетных функций «производственной ERP», где:

• надежно реализованы и поддерживаются в актуальном состоянии «день-в-день» объекты управления исполнением/ожидаемые приходы, ЗП ПЗ,
• своевременно «день-в-день» отслеживаются перемещения запасов, изменения объектов управления спросом (заказы клиентов, прогнозы спроса, точки перезаказа и пр.),
• изменения в КСИ/ТСИ…
• … реализация целостной системы, ERP + СПМ, выглядит следующим образом.

2. По системам, объектам управления и функциям процессы планирования, исполнения и мониторинга реализуются следующим образом (бизнес-логика).

a. Для 1го уровня планирования (моделирование, планирование, балансировка).
i. В СПМ передаются:

• ТСИ, с преобразованием в рСИ (ресурсные составы). Как вариант, рСИ могут быть созданы в СПМ вручную,
• запасы и ожидаемые (ЗП, ПЗ) приходы для ключевых элементов рСИ,
• запасы готовых изделий,
• параметры мощности производственных ресурсов – узких мест (календари работы, численность, эффективность и пр., согласно модели ресурсного планирования). Как вариант, могут поддерживаться в СПМ независимо,
• объекты управления спросом (Заказы, прогнозы, точки перезаказа готовых изделий и т.п.).

ii. По завершению процесса моделирования из СПМ в ERP передаются заказы с измененными датами, изменения в ТСИ/ПСИ (для реализации раннего запуска каких-либо ДСЕ), графики работы узких мест.

b. Для второго уровня планирования (синхронизация).
i. В СПМ передаются:

• ПСИ. Или ТСИ с преобразованием в СПМ в ПСИ,
• ЗП, ПЗ, и их статус (% выполнения или «обещанные даты» завершения),
• Запасы. Закупаемые, производимые и готовых изделий. И/или – действия с запасами.

ii. В СПМ выполняются действия по планированию производства и МТО (синхронизированное, несколько-итерационное, позаказное).

iii. ПДО/ПДБ цехов/участков анализируют план запуска, запускают производство – формируют объекты исполнения — ПЗ.

iv. Ответственные сотрудники МТС выполняют аналогичные действия с формированием ЗП.

v. По факту формирования из СПМ в ERP передаются сформированные ПЗ и ЗП (СПМ) с автоматическим формированием ПЗ ERP

• Исполнение, т.е. действия с ЗП, ПЗ, действия с запасами – выполняются в ERP, факт передаетс в СПМ (см.п.b.i.2).
• Мониторинг (позаказный, производственный, МТО) – в СПМ.

3. С т.зр. системной архитектуры, интеграция систем может быть описана следующим образом.

a. На физическом уровне решаются низкоуровневые вопросы, индивидуальные для каждого конкретного предприятия: 1) механизм обмена: через какую-то интеграционную шину/готовое ETL приложение, напрямую между системами; 2) правила сопоставления кодов справочников: принята единая кодификация, каждая система работает в “своих” кодах и есть какая-то MDM система, к которой обращаются за переводом кодов системы-источника в коды системы-приемника.

b. Какими интеграционными возможностями обладает каждая из систем:

• предоставляется ли REST API,
• форматы данных, с которыми работает система.

СПМ готова практически к любому сценарию интеграции:

• СПМ предоставляет REST API для выполнения CRUD операций со своими объектами,
• каждый объект СПМ имеет поле mdm_code, для хранения соответствия с записью в MDM системе,
• в СПМ есть своя внутренняя очередь заданий на выгрузку:
  • задания на выгрузку данных попадают в очередь по событиям в системе (например, создание объекта, смена статуса итд). Есть настройка, определяющая какие объекты по каким событиям следует выгружать,
  • очередь обрабатывается асинхронно отдельным процессом в фоновом режиме,
  • результатом обработки задания может являться: отправка http(s) запроса по определенному адресу, сохранение файла в директорию.
  • Поведение системы при возникновении ошибок выполнения заданий также настраивается для каждого типа объектов. Например, при отправке http запроса внешняя система оказалась недоступна. Варианты поведения:
    • игнорировать ошибку, продолжать выполнение других заданий,
    • остановить очередь, пока ошибка не будет исправлена,
    • ждать ручного решения оператора,
    • попытаться отправить запрос повторно через m минут, прекратить попытки после n неудачных запросов;
    • формат выгружаемых и загружаемых в СПМ данных — JSON. Возможна настройка конвертации в другие форматы.

Заключение

Наша практика показала практическую реализуемость предлагаемой схемы. Целостная система ERP+СПМ может быть реализована достаточно быстро, c практически гарантированным получением как операционного (адекватное планирование производства и МТО, оперативный и достоверный мониторинг), так и бизнес-результата (увеличение пропускной способности производства и т.п.). Последний, однако, зависит от желания и возможности изменения концепции управления. Немаловажную часть в котором играет отказ (поэтапный) от сдельной оплаты труда, отказ от попериодной (месяц) парадигмы планирования, с фиксацией и выдачей месячных планов «под подпись» и некоторых других, вполне возможных к реализации изменений.

Авторы: Питеркин Сергей, Меркулов Михаил
Источник: https://habr.com/