Как превратить условно-работающую ERP в реальный инструмент управления производством и поставками.
1 часть (пред.статья): проблемы использования для планирования внедренных «учетных» ERP
2 часть (данная статья): 2я жизнь — постановка Планирования и Мониторинга производства и поставок с внешним планировщиком. Концепция и реализация.
Питеркин Сергей, Меркулов Михаил, «Райтстеп»
Предлагаемая модель планирования: ERP+СПМ
Ниже представлены тезисы модели планирования, которая может быть реализована относительно просто и быстро. И, что немаловажно, без потери денежных и временных инвестиций, вложенных во внедрение «учетной части» «производственной ERP».
Концепция Системы Планирования и Мониторинга (СПМ) Райтстеп
Система планов
1й уровень планирования
Отвечает за моделирование/планирование (выпуска) и балансировку (мощностей). С учетом мощностей. Но, для сохранения внешней простоты и управляемости системы – с планированием с учетом ресурсных ограничений только в узких местах. И/или — с учетом запасов критических закупаемых и/или производимых ДСЕ, и/или с учетом критических циклов выполнения заказа. Как показано на рисунках ниже.
Замечание. 1й уровень планирования мало кто реализует «по-честному». Из-за этого все нерешенные на этом уровне проблемы или конфликты (ресурсов и спроса) «падают» вниз, «на пол» (в производство). Где «решаются»:
1) либо через ежедневные, по 2 и более раз в день планерки,
2) либо, при наличии «сильного» ИТ-отдела предприятия – через попытки разгрести их (проблемы верхнего уровня) путем внедрения систем/функций детального планирования, в т.ч. с учетом мощностей (в т.ч. «готовых» MES-систем). Не зная или не обращая внимания на то, что указанные функции/системы работают только с надежными (адекватными) планами верхнего уровня. Возможно не очень точными, но уже просеянными через «фильтр» балансировки, устранивший основные ресурсные конфликты, в т.ч. и через совещания «Производство vs. Продажи».
Важно! Никакая, даже самая чудесная система планирования, не способна устранить вред, нанесенный производству неправильными обещаниями заказчику (рынку). А обещания – это 1й уровень планирования, никак не «цеховой».
2й уровень планирования и исполнение
2й уровень планирования (синхронизация спроса и внутренней ситуации на производстве/в МТО) и далее, исполнения:
a) строится на модели «нормального» формирования ПСИ под каждый заказ,
b) с их (заказов — ПСИ) последовательным (по приоритетам) планированием,
c) с учетом дат и приоритетов заказов,
d) с учетом мягкого/жесткого/условного (пере)распределения запасов и ожидаемых приходов (ЗП, ПЗ) под потребности заказов,
e) с возможностью консолидированного исполнения (при позаказном планировании!)
С постоянной (не реже, чем еженощно) актуализацией «директивной» версии плана (от даты заказа, с учетом приоритетов, «вниз и влево» — «как должно быть»), и расчетной – «как получается…». Через сравнение которых и строятся весь позаказный и производственный «мониторинг», принимаются оперативные решения.
Создание целостной системы
1. При наличии хорошо внедренной в части учетных функций «производственной ERP», где:
a) надежно реализованы и поддерживаются в актуальном состоянии «день-в-день» объекты управления исполнением/ожидаемые приходы, ЗП ПЗ,
b) своевременно «день-в-день» отслеживаются перемещения запасов, изменения объектов управления спросом (заказы клиентов, прогнозы спроса, точки перезаказа и пр.),
c) изменения в КСИ/ТСИ…
… реализация целостной системы, ERP + СПМ, выглядит следующим образом.
2. По системам, объектам управления и функциям процессы планирования, исполнения и мониторинга реализуются следующим образом (бизнес-логика).
a. Для 1го уровня планирования (моделирование, планирование, балансировка).
i. В СПМ передаются:
1) ТСИ, с преобразованием в рСИ (ресурсные составы). Как вариант, рСИ могут быть созданы в СПМ вручную,
2) запасы и ожидаемые (ЗП, ПЗ) приходы для ключевых элементов рСИ,
3) запасы готовых изделий,
4) параметры мощности производственных ресурсов – узких мест (календари работы, численность, эффективность и пр., согласно модели ресурсного планирования). Как вариант, могут поддерживаться в СПМ независимо,
5) объекты управления спросом (Заказы, прогнозы, точки перезаказа готовых изделий и т.п.).
ii. По завершению процесса моделирования из СПМ в ERP передаются заказы с измененными датами, изменения в ТСИ/ПСИ (для реализации раннего запуска каких-либо ДСЕ), графики работы узких мест.
b. Для второго уровня планирования (синхронизация).
i. В СПМ передаются:
1) ПСИ. Или ТСИ с преобразованием в СПМ в ПСИ,
2) ЗП, ПЗ, и их статус (% выполнения или «обещанные даты» завершения),
3) Запасы. Закупаемые, производимые и готовых изделий. И/или – действия с запасами.
ii. В СПМ выполняются действия по планированию производства и МТО (синхронизированное, несколько-итерационное, позаказное).
iii. ПДО/ПДБ цехов/участков анализируют план запуска, запускают производство – формируют объекты исполнения — ПЗ.
iv. Ответственные сотрудники МТС выполняют аналогичные действия с формированием ЗП.
v. По факту формирования из СПМ в ERP передаются сформированные ПЗ и ЗП (СПМ) с автоматическим формированием ПЗ ERP
c. Исполнение, т.е. действия с ЗП, ПЗ, действия с запасами – выполняются в ERP, факт передаетс в СПМ (см.п.b.i.2).
d. Мониторинг (позаказный, производственный, МТО) – в СПМ.
3. С т.зр. системной архитектуры, интеграция систем может быть описана следующим образом.
a. На физическом уровне решаются низкоуровневые вопросы, индивидуальные для каждого конкретного предприятия:
1) механизм обмена:
через какую-то интеграционную шину/готовое ETL приложение,
напрямую между системами;
2) правила сопоставления кодов справочников:
принята единая кодификация,
каждая система работает в “своих” кодах и есть какая-то MDM система, к которой обращаются за переводом кодов системы-источника в коды системы-приемника.
b. Какими интеграционными возможностями обладает каждая из систем:
1) предоставляется ли REST API,
2) форматы данных, с которыми работает система.
СПМ готова практически к любому сценарию интеграции:
1) СПМ предоставляет REST API для выполнения CRUD операций со своими объектами,
2) каждый объект СПМ имеет поле mdm_code, для хранения соответствия с записью в MDM системе,
3) в СПМ есть своя внутренняя очередь заданий на выгрузку:
a) задания на выгрузку данных попадают в очередь по событиям в системе (например, создание объекта, смена статуса итд). Есть настройка, определяющая какие объекты по каким событиям следует выгружать,
b) очередь обрабатывается асинхронно отдельным процессом в фоновом режиме,
c) результатом обработки задания может являться:
отправка http(s) запроса по определенному адресу,
сохранение файла в директорию.
d) Поведение системы при возникновении ошибок выполнения заданий также настраивается для каждого типа объектов. Например, при отправке http запроса внешняя система оказалась недоступна. Варианты поведения:
1) игнорировать ошибку, продолжать выполнение других заданий,
2) остановить очередь, пока ошибка не будет исправлена,
3) ждать ручного решения оператора,
4) попытаться отправить запрос повторно через m минут, прекратить попытки после n неудачных запросов;
4) формат выгружаемых и загружаемых в СПМ данных — JSON. Возможна настройка конвертации в другие форматы.
Заключение
Наша практика показала практическую реализуемость предлагаемой схемы. Целостная система ERP+СПМ может быть реализована достаточно быстро, c практически гарантированным получением как операционного (адекватное планирование производства и МТО, оперативный и достоверный мониторинг), так и бизнес-результата (увеличение пропускной способности производства и т.п.). Последний, однако, зависит от желания и возможности изменения концепции управления. Немаловажную часть в котором играет отказ (поэтапный) от сдельной оплаты труда, отказ от попериодной (месяц) парадигмы планирования, с фиксацией и выдачей месячных планов «под подпись» и некоторых других, вполне возможных к реализации изменений.
