* 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
In recent years, the number of manufacturing enterprises reporting ERP systems has increased significantly. And it is not tens, but hundreds. First of all, we are talking about discrete production, and by âproduction ERPâ we mean any system that claims this proud name. In terms of the frequency of our âcollisionsâ, the most common âworking in productionâ ERPs are BaaN / InforLN, InforERPSyteLine, the constantly growing âarmyâ of plants with 1C, and a small amount of SAPERP and other exotic ones.
This article will be of interest primarily to âadvancedâ ERP users, to a greater extent with custom-made type of production (âpullingâ to order or to a warehouse, including âpullingâ to a demand forecast), to those who have automated (possibly - "As is") processes of accounting for the progress of production, i.e. the formation of production tasks (hereinafter - PZ. In different systems: SFC-orders, Job-Orders, JOBs, Orders for Production, Production orders, etc.) and their tracking, but it was not able to confidently produce (and supply - MTO (Logistical Support)) to plan, as it could not put up monitoring of production, incl. and custom. With ongoing attempts to still start planning, and / or with attempts to ensure planning using magic algorithms and / or systems such as APS, MES.
Due to the limited volume of the article, we will not dwell on the analysis of why âtraditionalâ ERPs are poorly implemented and / or work AND for planning AND for production management, as well as on the analysis of why the âmagicâ of APS or MES systems turns on at most of our plants into quackery. The purpose of the article is to show how to build a closed system of planning / monitoring not on the wreckage, but using what is now, of a certain category of enterprises that recognize themselves as written below.
We are confident that this article will also be of interest to factories or holdings that are only faced with the choice of a system or at the beginning of an implementation project. Because will help to avoid the traditional mistakes that we have observed over the past approximately 8 years.
Problem statement for a typical custom production business
Typical complaints, consequences and causes
- "Counting" business problems of the enterprise.
- Uncontrolled failure to meet the deadlines for fulfilling orders, especially in conditions of private changes in orders (accepting new ones, changing existing ones) -> loss of turnover.
- Increased (high, relative to profit) labor costs for production administration, emergency work -> increased costs.
- Non-optimal (high, relative to turnover) volume of wages (work in progress)
increased costs, increased cycles, loss of throughput (insufficient bandwidth) of production.
- Are a consequence of ....
- The impossibility of reliable "forecasting" (it should be - the calculation of planned / settlement dates) the timing of the execution of customer orders.
- Lack of information about existing and future (throughout the production cycle) problems in order fulfillment.
- Non-optimal loading of bottlenecks (they handle the wrong thing, at the wrong time, in the wrong sequence).
- They are consequences of the following (non-root!) Reasons.
- The lack of a formalized system of quick <order> planning:
1) taking into account the loading of bottlenecks (the processing queue of the components of the order);
2) taking into account the priorities of orders. - Lack of traceability and visualization of the status of the order (s) throughout the production chain.
goal
- Reliable determination of terms of order fulfillment - for single and urgent orders. Taking into account production / purchase cycles (on critical âbranchesâ of the composition of the order product) and taking into account free stocks (materials, PKI (purchased component parts), wages and salaries) and expected receipts for salaries (orders to suppliers) and PP.
- Minimization of weighted average breakdowns for âlong-term ordersâ:
- through the overall balancing of the issue,
- through a prioritized production plan and execution,
- through monitoring the implementation of the plan with visualization of deviations from the deadlines.
- Maximum bottleneck loading.
A typical planning model for a typical plant with an underdeveloped âproduction ERPâ
general description
- Currently, âproduction ERPâ is used to manage production and supply.
- MTO Management, Production Tracking, Inventory Management, incl. production - very often made at a good level.
- At the same time, Planning is partially implemented, using system functions not intended for this and / or independent development.
- Release Planning (âUpperâ Planning Level - Formation of the Basic Production Plan). Not implemented at all, or implemented in MS-Excel. Without reference to the model and parameters of real production. Excluding the current state of production:
1) run or planned to launch PP / RFP,
2) stocks of PKI, materials and WIP, in different statuses of âconsolidationâ (distribution) of customer orders,
3) free / expected stocks of finished products manufactured âat the warehouseâ (under the demand forecast or reorder point),
4) taking into account the resource model (resource = specialty), but without the necessary detail. - Production Planning (Planning Level - Synchronized Production and Supply Planning).
1) Production planning is implemented through the creation of production tasks (execution control objects!) Throughout the entire product structure of the order and calculation of launch-release dates using the simple network planning method (end of work - production cycle = start. = End of incoming component - ...). This approach does not provide the information necessary to achieve the above goals and has many shortcomings (see below), which is why it is practically not used for real planning and production management. Production is controlled âmanuallyâ; PPs are used only for accounting!
2) Deliveries (MTO) are planned under the formed PP. The accuracy of such a plan = the accuracy of the PP planning, i.e. - quite low. But since âCustom-made product compositionsâ (or âPZ chainâ) are deliberately extended and do not take into account existing stocks, MTO almost always succeeds in avoiding production shortages. In the absence of a planning system that constantly takes into account internal (production, MTO, stocks) and external (orders, forecasts) changes, this is obviously achieved by overstated stocks of materials and PKI.
Detailed analysis of the used planning model
Planning model
- Execution management objects (Production tasks of the PP) are used not for their intended purpose - not to control the execution, but to create the Production (custom) Product Composition (PSI), and also for custom planning (planning attempts). In the absence of the functions of "end-to-end" order planning and order composition in the IT system, this becomes the only option that allows you to "at least somehow" manage the entire chain of the customerâs order. This approach has the following fundamental disadvantages.
- PSI created using execution objects is fixed. Changes that occur, for example, in the CSI / TSI (Design / Technological staff) due to the design and technological changes, can only be taken into account manually. In practice, with a large volume of control objects, this means: <no way>. As a result, errors in plans can be solved only through laborious and ineffective manual control.
- PPs, by definition, are poorly handled by 2nd level production planning planners (synchronization schedulers, APSPlanners, and even MRPs, including âcustomâ ones, see below). Including because for the planner PPs are fixed expected arrivals, and not flexible <elements> PSIs calculated by the planner (planned orders, pln).
- When planning PSI, modeled on the basis of the PP, the stocks and expected receipts of DSEs that can be used to complete this order are not taken into account in accordance with the rules for the distribution / marking of reserves / expected receipts.
- Planning is carried out through an algorithm of our own development, in one iteration, with the composition being discovered, the gross quantities needed (!) Are determined and the start dates of the PP are shifted to the left. In this case, the available limited set of times of the operational model (operational route) is used, for the operations of which (models), as a rule, the necessary planning times are not determined, such as <time before>, <time after>, <buffer before>, <buffer after >, <queue time>, <move time>, etc. This leads to large and difficult to manage errors in the calculated terms.
- For planned PPs, through the standard planning algorithm, the requirements for purchased materials and CRPs are calculated, management objects are formed - expected receipts, RFP.
Under ideal conditions, such a model could work. Under the conditions of constant internal and external changes in the real world, it very quickly becomes unstable.
Critical issue number 1
If there is stock in production or the expected arrival of DSEs that can be used to complete the order (which could very well happen due to changes in the PSI of another order, changes in priorities / dates of orders, and many other reasons), the needs of production and procurement fundamentally change - see the example in the figures above. The previous "hard-to-order-perfect" plan can only be changed manually (really, for hundreds and thousands of control objects - a PP, this is extremely difficult and is not implemented). This leads to the re-purchase of materials and CRPs, and as a result - to âfreezingâ of the turnover, potential illiquid assets, and overproduction. If re-purchase is bad, but somehow you can still live (if there are no problems with turnover :) - because <will go to other orders:>, the production of "unnecessary" <now> DSEs, especially in bottlenecks, takes away precious <ruble-hours> of the entire turnover of the plant. As a result - a decrease in turnover, profits (including due to additional costs for emergency calls), disruption of the terms of orders. As a result - loss / underestimation of market share.
Another problem with the use of such simple planning is the actual lack of reaction to what is happening in production / procurement. Incorrect definition or even loss of priorities of the defense industry in the "black box" of production. Even and first of all, when determining the order of processing orders (parts of the <product> order) in PM (bottlenecks).
Critical issue number 2
- Suppose initial planning (this is unlikely using only the 2nd planning level, but theoretically possible) provides quasi-optimal (close to optimal) loading of the bottleneck.
- However, the lack of quick and frequent rescheduling along the entire chain of order fulfillment (resynchronization) does not allow taking into account situations typical of real production, such as: unavoidable failure to meet the production / purchase deadlines for any components, changing priorities / dates of orders or stopping them, changing TSI and etc.
- As shown in the example below, the fatal failure of the terms of order XX leads to the postponement of the terms of its readiness and shipment. At the same time, in the absence of a resynchronization system, the bottleneck will lose time for processing the DSE of this order, which could and should be processed later. If there are new or urgent orders, or orders with removable deadlines, UM will not be able to process their details, because, most likely, no one will show this section the correct sequence / processing priorities! As a result, less than output (finished products) could be, loss of turnover and profit.
Critical issue number 3
Consolidated Planning. Planning with the consolidation of produced DSEs, when working with bottlenecks in the production and logistics chain of order fulfillment, also leads to misuse of bottleneck time. Which, again, leads to loss / loss of turnover / profit.
- Custom bottleneck planning.
- Planning with the consolidation of produced DSE either by order or by production plan. Consolidation according to the 2nd planning options below leads to a decrease in production throughput (issuing fewer orders for the period).
The main (root) problem and point of improvement
We note one more, for many, the only, extremely important and root problem of the low efficiency of the production system. Namely, a low reaction rate to external / internal disturbances.
- According to the <System Dynamics> as applied to complex production and logistics systems, all of them (systems) experience constant fluctuations in the level of stocks, and the required / used capacities, due primarily to the reaction rate. See: Industrial Dynamics, Jay Forrester, Productivity Press, 1961; Factory Physics: Foundations of Manufacturing Management and derivatives of these works . The frequency and amplitude of the oscillations are directly proportional to the fundamental variable of the system - the reaction rate <to external and internal changes>, or - the response time.
- Shortening the response time (increasing the reaction rate) increases the frequency of fluctuations in the reserves / power, but reduces their amplitude. The amplitude of stock fluctuations (a well-known graphic illustration of fluctuations - a sawtooth curve of changes in stock levels during batch purchase / batch processing) uniquely determines the volume of stocks (for the period), including the amount of wage in the system. Moreover, according to the law of Little (LittleLow) <Queue Theory>, a reduction in inventory levels leads to a reduction in queues <PZ pending processing>, i.e. - to reduce the cycles of the execution of orders! More details: <Reaction rate of an industrial enterprise>, Peterkin SV, Internet.
- Speaking <Russian language>: more often we plan, execute in smaller (custom) batches - we can execute orders more per unit of time. The ratio that JayForrester cited is - <2 times reduction in response time leads to a 1.7-fold decrease in inventory levels throughout the chain> . Speaking <Russian language>:
- we just start (re) planning the entire production and logistics chain more than 2 times (instead of <once a month> - <once every 2 weeks>) - we increase output <about> 1.7 times,
- we just launch the minimum batches of DSE into production - increase the output <approximately> 1.7 times,
- ...
The figure of 1.7 is calculated and theoretical. The value in practice, of course, depends on the type of production and procurement, the type of demand, etc. But at least, you can count on the first tens of %% improvement in output: Just by changing management approaches:
However, looking the truth in the eye, itâs impossible to simply change management approaches (often re-plan, often launch small batches), in complex production, without an adequate planning system.
findings
- The above cases are just a small part of the examples that clearly demonstrate the practical inoperability of the presented planning model. A description of all possible examples and problems with its use is beyond the scope of this document. In addition, I only note that in addition to adequate planning, such a system does not provide any coherent monitoring of what is happening, including custom monitoring. Those. does not give decision makers any tool to increase manual productivity
- Another very important point! As can be seen from the problems described above, the lack of algorithms of "precise", "detailed", "optimization", <planning to the machine / person>, <planning taking into account capacities, are not the key reasons for the low efficiency of most production and logistics systems. And their presence is not at all a "golden key" to its increase.
If you still have doubts about the adequacy of the existing planning system and / or the possibility of bringing it "to life" without changing the fundamental approaches, answer the question: <whether the existing <management> System and the information system supporting it can provide at least a week time response?>.
Description of proposed solutions is in the next part of the document.