Undeveloped ERP in production: in intensive care or in a morgue? (continued)
How to turn conditional ERP into a real production and supply management tool.
Part 1: problems of use for planning the implemented “accounting” ERP
Part 2: 2nd life - setting up Planning and Monitoring of production and supplies with an external planner. Concept and implementation.
Peterkin Sergey , Merkulov Mikhail, Reitstep
Below are the abstracts of a planning model that can be implemented relatively simply and quickly. And, importantly, without loss of cash and temporary investment made in the implementation of the “accounting part” of “production ERP”.
Responsible for modeling / planning (release) and balancing (capacity). Given the capacity. But, to maintain the external simplicity and controllability of the system - with planning taking into account resource limitations only in bottlenecks. And / or - taking into account the stocks of critical purchased and / or produced by DSE, and / or taking into account the critical cycles of the order. As shown in the pictures below.
Remark . The 1st level of planning, few implement "honestly." Because of this, all problems or conflicts unresolved at this level (resources and demand) “fall” down, “to the floor” (into production). Where are "solved":
1) either through daily, 2 or more times a day, planning meetings,
2) either, in the presence of a “strong” IT department of the enterprise - through attempts to clear them (top-level problems) by introducing systems / functions of detailed planning, incl. taking into account capacities (including “ready-made” MES-systems). Not knowing or not paying attention to the fact that these functions / systems work only with reliable (adequate) top-level plans. Perhaps not very accurate, but already sifted through the balancing “filter”, which eliminated the main resource conflicts, including and through the meetings “Production vs. Sales. "
Important! No, even the most wonderful planning system, is able to eliminate the harm caused to production by incorrect promises to the customer (market). And promises are the 1st level of planning, not the “shop floor” in any way.
2nd level planning and execution
2nd level of planning (synchronization of demand and the internal situation at the production / in MTO) and further, execution:
a) is based on the model of “normal” formation of PSI for each order,
b) with their (orders - PSI) sequential (priority) planning,
c) taking into account dates and priorities of orders,
d) taking into account the soft / hard / conditional (re) distribution of stocks and expected receipts (RFP, PP) according to the needs of orders,
e) with the possibility of consolidated execution (with custom planning!)
With constant (no less than nightly) updating of the “directive” version of the plan (from the date of the order, taking into account priorities, “down and to the left” - “as it should be”), and estimated - “how it turns out ...”. Through comparison of which the entire custom and production “monitoring” is built, operational decisions are made.
1. If there is a well-established “production ERP” in terms of accounting functions, where:
a) day-to-day performance management facilities / expected arrivals, RFA PP are reliably implemented and maintained in an up-to-date state,
b) inventory movements, changes in demand management objects (customer orders, demand forecasts, reorder points, etc.) are monitored on a timely basis “day-to-day”,
c) changes to the CSI / TSI ...
... the implementation of a holistic system, ERP + SPM, is as follows.
2. For systems, control objects and functions, the processes of planning, execution and monitoring are implemented as follows (business logic).
a. For the 1st level of planning (modeling, planning, balancing).
i. The following are transmitted to the JMP:
1) TSI, with conversion to RSI (resource staff). Alternatively, RSI can be created manually in the JMP,
2) stocks and expected (, ) receipts for key elements of RSI,
3) stocks of finished products,
4) the parameters of the capacity of production resources - bottlenecks (work calendars, number, efficiency, etc., according to the resource planning model). Alternatively, they can be supported independently in the JMP,
5) demand management objects (Orders, forecasts, reorder points of finished products, etc.).
ii. Upon completion of the modeling process, orders with changed dates, changes to TSI / PSI (for the implementation of early launch of any DSE), and work schedules of bottlenecks are transferred from the PSD to ERP.
b. For the second level of planning (synchronization).
i. The following are transmitted to the JMP:
1) PSI. Or TSI with conversion to PSD in PSI,
2) , , and their status (% of completion or “promised dates” of completion),
3) Stocks. Purchased, manufactured and finished products. And / or - actions with stocks.
ii. In SPM, actions are taken to plan production and MTO (synchronized, multi-iterative, custom).
iii. PDO / PDB of workshops / sections analyze the launch plan, start production - form execution objects - PP.
iv. Responsible employees of MTS perform similar actions with the formation of the RFP.
v. Upon the formation from SPM to ERP, the generated PP and RFP (SPM) with the automatic generation of the ERP PP are transferred
c. Execution, i.e. actions with RFP, PP, actions with stocks - are performed in ERP, the fact is transferred to the PSD (see clause bi2).
d. Monitoring (custom, production, MTO) - in SPM.
3. With so.z. system architecture, system integration can be described as follows.
a. At the physical level, low-level issues are solved that are individual for each particular enterprise:
1) exchange mechanism:
through some kind of integration bus / ready ETL application,
directly between systems;
2) rules for matching reference codes:
unified codification adopted
each system operates in “its own” codes and there is some kind of MDM system that is used to translate the source system codes into the receiver system codes.
b. What integration capabilities does each of the systems have:
1) is there a REST API provided
2) data formats with which the system works.
SPM is ready for almost any integration scenario:
1) JMP provides a REST API for performing CRUD operations with its objects,
2) each PSD object has an mdm_code field for storing compliance with a record in an MDM system,
3) the JMP has its own internal queue of tasks for unloading:
a) tasks for uploading data are queued for events in the system (for example, creating an object, changing status, etc.). There is a setting that determines which objects for which events should be unloaded,
b) the queue is processed asynchronously by a separate process in the background,
c) the result of processing a task may be:
sending http (s) request to a specific address,
save the file to a directory.
d) The behavior of the system when job execution errors occur is also configured for each type of object. For example, when sending an http request, the external system was not available. Behavioral options:
1) ignore the error, continue to perform other tasks,
2) stop the queue until the error is fixed,
3) wait for the operator’s manual decision,
4) try to send the request again after m minutes, stop trying after n failed requests;
4) the format of the data uploaded and loaded into the JMP is JSON. You can customize the conversion to other formats.
Our practice has shown the feasibility of the proposed scheme. The holistic ERP + SPM system can be implemented quickly enough, with practically guaranteed receipt of both operational (adequate production planning and MTO, operational and reliable monitoring), and business result (increase in production throughput, etc.). The latter, however, depends on the desire and possibility of changing the concept of management. An important part in which is the refusal (phased) of piecework wages, the rejection of the periodical (month) planning paradigm, with fixing and issuing monthly plans “for signature” and some other changes that are quite possible to implement.
Part 1: problems of use for planning the implemented “accounting” ERP
Part 2: 2nd life - setting up Planning and Monitoring of production and supplies with an external planner. Concept and implementation.
Peterkin Sergey , Merkulov Mikhail, Reitstep
Proposed Planning Model: ERP + SPM
Below are the abstracts of a planning model that can be implemented relatively simply and quickly. And, importantly, without loss of cash and temporary investment made in the implementation of the “accounting part” of “production ERP”.
Wrightstep Planning and Monitoring System (JMP) Concept
System of plans
1st level planning
Responsible for modeling / planning (release) and balancing (capacity). Given the capacity. But, to maintain the external simplicity and controllability of the system - with planning taking into account resource limitations only in bottlenecks. And / or - taking into account the stocks of critical purchased and / or produced by DSE, and / or taking into account the critical cycles of the order. As shown in the pictures below.
Remark . The 1st level of planning, few implement "honestly." Because of this, all problems or conflicts unresolved at this level (resources and demand) “fall” down, “to the floor” (into production). Where are "solved":
1) either through daily, 2 or more times a day, planning meetings,
2) either, in the presence of a “strong” IT department of the enterprise - through attempts to clear them (top-level problems) by introducing systems / functions of detailed planning, incl. taking into account capacities (including “ready-made” MES-systems). Not knowing or not paying attention to the fact that these functions / systems work only with reliable (adequate) top-level plans. Perhaps not very accurate, but already sifted through the balancing “filter”, which eliminated the main resource conflicts, including and through the meetings “Production vs. Sales. "
Important! No, even the most wonderful planning system, is able to eliminate the harm caused to production by incorrect promises to the customer (market). And promises are the 1st level of planning, not the “shop floor” in any way.
2nd level planning and execution
2nd level of planning (synchronization of demand and the internal situation at the production / in MTO) and further, execution:
a) is based on the model of “normal” formation of PSI for each order,
b) with their (orders - PSI) sequential (priority) planning,
c) taking into account dates and priorities of orders,
d) taking into account the soft / hard / conditional (re) distribution of stocks and expected receipts (RFP, PP) according to the needs of orders,
e) with the possibility of consolidated execution (with custom planning!)
With constant (no less than nightly) updating of the “directive” version of the plan (from the date of the order, taking into account priorities, “down and to the left” - “as it should be”), and estimated - “how it turns out ...”. Through comparison of which the entire custom and production “monitoring” is built, operational decisions are made.
Creating a holistic system
1. If there is a well-established “production ERP” in terms of accounting functions, where:
a) day-to-day performance management facilities / expected arrivals, RFA PP are reliably implemented and maintained in an up-to-date state,
b) inventory movements, changes in demand management objects (customer orders, demand forecasts, reorder points, etc.) are monitored on a timely basis “day-to-day”,
c) changes to the CSI / TSI ...
... the implementation of a holistic system, ERP + SPM, is as follows.
2. For systems, control objects and functions, the processes of planning, execution and monitoring are implemented as follows (business logic).
a. For the 1st level of planning (modeling, planning, balancing).
i. The following are transmitted to the JMP:
1) TSI, with conversion to RSI (resource staff). Alternatively, RSI can be created manually in the JMP,
2) stocks and expected (, ) receipts for key elements of RSI,
3) stocks of finished products,
4) the parameters of the capacity of production resources - bottlenecks (work calendars, number, efficiency, etc., according to the resource planning model). Alternatively, they can be supported independently in the JMP,
5) demand management objects (Orders, forecasts, reorder points of finished products, etc.).
ii. Upon completion of the modeling process, orders with changed dates, changes to TSI / PSI (for the implementation of early launch of any DSE), and work schedules of bottlenecks are transferred from the PSD to ERP.
b. For the second level of planning (synchronization).
i. The following are transmitted to the JMP:
1) PSI. Or TSI with conversion to PSD in PSI,
2) , , and their status (% of completion or “promised dates” of completion),
3) Stocks. Purchased, manufactured and finished products. And / or - actions with stocks.
ii. In SPM, actions are taken to plan production and MTO (synchronized, multi-iterative, custom).
iii. PDO / PDB of workshops / sections analyze the launch plan, start production - form execution objects - PP.
iv. Responsible employees of MTS perform similar actions with the formation of the RFP.
v. Upon the formation from SPM to ERP, the generated PP and RFP (SPM) with the automatic generation of the ERP PP are transferred
c. Execution, i.e. actions with RFP, PP, actions with stocks - are performed in ERP, the fact is transferred to the PSD (see clause bi2).
d. Monitoring (custom, production, MTO) - in SPM.
3. With so.z. system architecture, system integration can be described as follows.
a. At the physical level, low-level issues are solved that are individual for each particular enterprise:
1) exchange mechanism:
through some kind of integration bus / ready ETL application,
directly between systems;
2) rules for matching reference codes:
unified codification adopted
each system operates in “its own” codes and there is some kind of MDM system that is used to translate the source system codes into the receiver system codes.
b. What integration capabilities does each of the systems have:
1) is there a REST API provided
2) data formats with which the system works.
SPM is ready for almost any integration scenario:
1) JMP provides a REST API for performing CRUD operations with its objects,
2) each PSD object has an mdm_code field for storing compliance with a record in an MDM system,
3) the JMP has its own internal queue of tasks for unloading:
a) tasks for uploading data are queued for events in the system (for example, creating an object, changing status, etc.). There is a setting that determines which objects for which events should be unloaded,
b) the queue is processed asynchronously by a separate process in the background,
c) the result of processing a task may be:
sending http (s) request to a specific address,
save the file to a directory.
d) The behavior of the system when job execution errors occur is also configured for each type of object. For example, when sending an http request, the external system was not available. Behavioral options:
1) ignore the error, continue to perform other tasks,
2) stop the queue until the error is fixed,
3) wait for the operator’s manual decision,
4) try to send the request again after m minutes, stop trying after n failed requests;
4) the format of the data uploaded and loaded into the JMP is JSON. You can customize the conversion to other formats.
Conclusion
Our practice has shown the feasibility of the proposed scheme. The holistic ERP + SPM system can be implemented quickly enough, with practically guaranteed receipt of both operational (adequate production planning and MTO, operational and reliable monitoring), and business result (increase in production throughput, etc.). The latter, however, depends on the desire and possibility of changing the concept of management. An important part in which is the refusal (phased) of piecework wages, the rejection of the periodical (month) planning paradigm, with fixing and issuing monthly plans “for signature” and some other changes that are quite possible to implement.
All Articles