When a production management system fails to take hold in an engineer-to-order plant, the explanation almost always given is that the software lacked features. Yet lining up feature lists side by side never removes the unease people feel on the floor. The problem is not what the package can or cannot do. It is that the package is built on the assumption that master data exists first. This article reframes the difference between production types as a difference in when each piece of information becomes fixed, and sets out what has to be decided on paper before any product is selected, using conditions that Japanese-affiliated factories in Thailand actually face.
Why a production management system is said not to fit engineer-to-order manufacturing
When a factory starts looking at a new system, the first document handed over is, almost without exception, a feature list. Requirements planning, inventory allocation, shop floor progress, costing, purchasing, quality records. Requirements run along one axis, vendors along the other, and circles, triangles and crosses fill the grid. The capital request is then built on top of that grid.
Six months after go-live, though, the conversation on the floor is not about missing features. It is “we cannot register it because the part number has not been decided”, “the bill of materials is not settled but purchasing has already started”, and “we only find out whether a project made money two months after it shipped”. Functions that had a circle beside them are sitting there unable to start at all.
That is less a selection mistake than a sign that the axis of comparison was wrong from the beginning. A feature list quietly assumes that every input a function needs is already available. Requirements planning needs a fixed bill of materials. Variance analysis needs a standard cost. Shop floor progress needs a fixed routing. In a make-to-stock plant, all of that exists before an order arrives. In an engineer-to-order plant, none of it does.
This is the central argument of the article. An engineer-to-order plant finds a production management system a poor fit not because features are missing, but because the package was built on the assumption that master data comes first. The difference between production types is not a difference in features. It is a difference in the point at which each item becomes fixed. So the first thing to examine during selection is not the feature list. It is how the system handles information that is not yet fixed.
The general statistics on ERP implementation do not contradict that view. The 2026 ERP Report from Panorama Consulting Group draws on 170 respondents, data collected between January 2025 and January 2026, a median project duration of 9 months, 56.5% of organisations operating multinationally and a median annual revenue of 200.5 million US dollars. In that population, more than a quarter of organisations reported that their project went over budget. The same report attributes the overruns to critical misfits surfacing late in the project, which then pushes organisations towards additional technology, expanded scope and custom development. A misfit that surfaces late is precisely a mismatch of assumptions.
Four production types – make-to-stock, assemble-to-order, make-to-order and engineer-to-order
The first step is to settle, in words, which production type your own plant belongs to. If that stays vague, the whole company walks into requirements definition carrying different pictures of the same business.
The four definitions
Make-to-stock (MTS) forecasts demand, builds ahead and ships from inventory. Your own company decides the product specification. The item code, the bill of materials, the routing and the standard cost are all fixed before any order arrives.
Assemble-to-order (ATO) builds parts and sub-assemblies to forecast and combines them into a finished product after the order lands. The configuration options are defined in advance, and taking an order is the act of choosing which combination applies.
Make-to-order (MTO) starts manufacturing after the order lands. The product itself, however, is an existing design, and the drawings and routings already exist inside the company. Only the timing of production moves after the order.
Engineer-to-order (ETO) designs the product after the order lands. At the moment the order is taken, the product does not yet exist. There is a specification document, a general arrangement sketch and a quotation. The bill of materials and the routing are still to be created.
The assumption breaks between the third type and the fourth
Most packages are designed with make-to-stock and assemble-to-order as their home ground. Make-to-order still works, because existing designs are reused and the assumption that master data comes first survives. The assumption collapses the moment you cross into engineer-to-order.
The misunderstanding that comes up most often on the floor is that many plants describing themselves as make-to-order are, in substance, engineer-to-order. The test is simple. Ask whether the drawings and the bill of materials exist inside the company at the moment the order is taken. If they exist, it is make-to-order. If they are still to be drawn, it is engineer-to-order. Put that single question to design, manufacturing, purchasing and sales, and compare the answers. Departments often answer differently, and that gap itself tells you in advance where requirements definition will get stuck.
A view of what changes between production types, mapped against the main functions of a system, is set out in our production management system comparison. This article deals with the step before that comparison, which is working out which type you actually are.
The difference is not features but the point at which each item becomes fixed
Here is the table that carries the skeleton of this article. It lines up, for each production type, when the five pieces of information a system depends on become fixed.
| Production type | Item code | Bill of materials | Routing | Standard cost | Delivery commitment |
|---|---|---|---|---|---|
| Make-to-stock (MTS) | Fixed before the order | Fixed before the order | Fixed before the order | Fixed before the order | Fixed before the order |
| Assemble-to-order (ATO) | Fixed before the order | Fixed at order entry | Fixed before the order | Fixed at order entry | Fixed at order entry |
| Make-to-order (MTO) | Fixed before the order | Fixed before the order | Fixed before the order | Fixed before the order | Fixed at order entry |
| Engineer-to-order (ETO) | Fixed when design is complete | Fixed when design is complete | Fixed when design is complete | Fixed after shipment | Fixed when design is complete |
Compare the top row with the bottom row. In make-to-stock, all five are fixed before the order arrives. In engineer-to-order, not one of them is. That is how the table should be read – there is no reason to expect a single tool wearing the label “production management system” to apply to both in the same way.
The two middle rows deserve a note as well. Make-to-order reuses existing designs, so the only thing not fixed is the delivery commitment. In assemble-to-order, the bill of materials and the standard cost are shown as fixed at order entry because, although the options themselves are defined beforehand, which combination is going to be built is decided when the order arrives. Neither of these two rows requires the plant to run procurement or production while holding information that is not fixed. The assumption genuinely breaks only when you drop into the bottom row.
A few clarifications are needed. The delivery commitment for engineer-to-order is shown as fixed when design is complete, yet in practice a delivery date is promised at order entry. What the table describes is the point at which that promise acquires a basis. Until design finishes, the part count, the presence of long-lead items and the volume of subcontracting are all unknown, so the date given at order entry is a placeholder derived by analogy from the estimate. There is nothing wrong with a placeholder as such. The problem is when the placeholder enters the system flagged as fixed and is treated as the baseline from then on.
Standard cost is shown as fixed after shipment for the same reason. In engineer-to-order work it is not unusual never to build the same product again. The concept of a standard cost exists so that repeated production can be compared against it. Setting a standard for something built once leaves nothing to compare it with. So in practice the plant accumulates actual cost by project, and that only closes after shipment.
Check the fixing points before you compare features
That leads to three questions that come before any feature comparison.
First, can procurement proceed on a bill of materials that is not yet fixed. Before part numbers are issued, or before the part count is settled, can long-lead items be ordered against a provisional structure, and can those orders then be connected to the formal bill of materials once it exists.
Second, can costs incurred before drawing numbers exist be attached to the project. Design hours, prototype costs, travel, subcontractor set-up charges. None of these attach to an item. What you are looking for is a structure that lets them be posted directly to a container called a project.
Third, can an engineering change be traced backwards. When a change occurs, can the system show in one place how it affects parts already ordered, operations already started and costs already posted.
The answers to those three questions decide the outcome of an implementation far more strongly than the circles and crosses on a feature list. Even with a full row of circles, a system whose answer to those three is negative will not start up in an engineer-to-order plant.
The four assumptions that break first in engineer-to-order work
Experience says the places where a package’s assumptions break are almost always the same. Elevatiq, writing on the difficulties of ERP implementation in engineer-to-order businesses, points to the same places. The product does not exist at the moment of order, and the bill of materials changes dynamically as design progresses. When the bill of materials lives inside CAD and is re-keyed by hand into ERP, version mismatches and procurement errors follow. Long-lead items have to be ordered early against a provisional design, before a complete bill of materials is settled. Project profitability is only known after the project closes. Engineering changes end up managed outside the system. The way an estimate is built diverges from the cost structure inside ERP. And unless the boundary of record ownership between PLM and ERP is decided, duplicate items and inconsistent bills of materials appear.
This article treats these as four fault lines. Fault line 1 is the bill of materials, fault line 2 is cost, fault line 3 is engineering change and fault line 4 is the estimate. The next four sections take them one at a time.
One structural point is worth stating up front. All four fault lines share a feature – a substitute already exists outside the system. The bill of materials lives in CAD and spreadsheets, cost lives in a finance summary sheet, engineering change lives on paper and in email, and the estimate lives in a sales quotation format. All of them work. So when a new system arrives, the floor does not throw the outside mechanism away. It keeps both, ends up running them in parallel, and eventually stops updating the system side. What people describe as a system that never took hold is this parallel operation with one half left to wither.
Fault line 1 – procurement starts before the bill of materials is finished
An engineer-to-order bill of materials is not something that gets completed on a particular day. Branches grow as design progresses, branches get swapped out along the way, and manufacturing proceeds with part of it still unsettled to the end.
Waiting for a complete structure means missing the delivery date
The problem is that waiting for the bill of materials to be complete means missing the delivery date. In engineer-to-order industrial machinery, the structure contains long-lead items such as gearboxes, servo units, large machined parts, special steels and imported components. Unless these are ordered before the design is fully settled, the downstream schedule cannot be built at all.
So the floor places orders against a provisional structure. Once the specification is broadly settled, the model number is secured, and if details change later the item is swapped out. This is not bad practice. In engineer-to-order work it is unavoidable practice. Yet most packages have no container for it, because requirements planning takes a fixed bill of materials as its input and purchase orders are assumed to be raised against part numbers already registered in the item master.
The result is that early procurement of long-lead items runs on spreadsheets and email alone. The system only receives the data later, when the bill of materials is finished, at which point items already on order are entered together with everything else. At that moment the system records parts that were actually ordered weeks ago as if they had been ordered today. Both the requirements planning result and the progress picture end up lagging reality.
Double entry between CAD and the system creates version drift
The second route in is the entry of the bill of materials itself. Design builds an E-BOM in CAD. Manufacturing and purchasing work from an M-BOM. Industry commentary consistently notes that maintaining both by hand invites missed updates, and that ordering or building from an outdated bill of materials causes rework. When design, manufacturing and purchasing each hold the bill of materials in a separate document, the information fragments and integrated BOM management never happens.
In engineer-to-order work this double entry occurs many times within a single project. What a make-to-stock plant experiences a handful of times across a product lifecycle is compressed into the few weeks of a design period. When the frequency changes, the same operating rule produces a different outcome.
What has to be decided to close the fault line
Three decisions close the bill of materials fault line.
Which side carries responsibility for the record. Either the item master and the product structure are held in PLM or on the CAD side and fed into the system, or the system is the record of authority and design enters data into it. Either is workable. The worst state is not having decided. Without a decision, separate part numbers appear on both sides and reconciliation becomes a job in itself.
How an unsettled branch is represented. Either the part of the structure with an undetermined count is held with dummy part numbers, or the structure is phased so that only settled branches are released. If dummies are used, decide as well how ordered quantities carry across when a dummy is replaced by a formal part number.
Which container carries early procurement. Either a procurement allocation is created directly against the project, or orders are raised under provisional part numbers and transferred later. Go live without deciding this and early procurement will, without fail, end up outside the system.
Fault line 2 – project cost only appears after the project ends
The second fault line is cost. In engineer-to-order work, project-based costing tends to settle into a state where a project’s profitability is only known after the project has closed.
Why it arrives late
There are three reasons. First, because no standard cost exists, there is no variance analysis to give an early reading. Second, part of the spend does not attach to an item, so it falls outside the system’s costing. Design hours, on-site adjustment, travel for witness testing, re-engineering triggered by a customer specification change. These are project costs, but they do not ride on a unit price. Third, subcontractor and imported-part invoices arrive late. Nothing is posted until an invoice arrives, and until it is posted the project cost cannot close.
The consequence is that cost only becomes visible after the monthly accounting close, and then only once post-shipment invoices are all in. Even on a project where engineering changes inflated the hours, that shows up as a number only after the project has ended. There is a loop in which it is always too late to feed the result into the next estimate.
What early visibility actually buys
What changes when project cost is visible while the project is still running is that problems are noticed while there are still moves available. Simplify the design, change the subcontractor, shift towards standard parts, negotiate the additional specification with the customer. None of these can be executed after design is complete or past the first half of manufacturing. Once a loss is confirmed after shipment, all that remains is reflection.
The point here is not to produce a perfect cost figure early. It is to show settled costs and unsettled costs separately. In-flight engineer-to-order cost always contains an estimated portion. Display it with the estimate included and show the settled proportion alongside, and it is more than good enough for decision-making. A mechanism that only displays settled cost is close to blank while the project is running, and stops being used.
How project cost is accumulated, and where direct charging ends and allocation begins, is covered in our article on manufacturing cost management systems, which works through how to break the spend down. Whether cost is held inside the production management system or moved to a separate mechanism is a decision to be taken after that breakdown exists.
Fault line 3 – engineering changes run outside the production management system
The third fault line is engineering change. Industry commentary describes the particular difficulty of engineer-to-order work as follows. Trial-and-error design changes and repeated customer-driven specification changes demand a high degree of flexibility, and each occurrence requires irregular handling of delivery delays, cost status and information sharing. When that irregular handling happens outside the system, you have a fault line.
Write out the route a change travels
Start by writing out, for your own plant, the route an engineering change travels from the moment it arises until it reaches the floor. In most plants it looks like this. A request comes from the customer to sales, sales passes it to design verbally or by email, design revises the drawing, the revised drawing is distributed to manufacturing and purchasing, purchasing checks what has already been ordered, and if necessary raises a change order. The production management system appears nowhere on that route.
The system is updated after the route has run its full circuit. What is more, only the outcome is recorded. The reason for the change, the purchase orders it affected and the extra hours it consumed leave no trace. The next time the same thing happens, there is no record to refer back to.
Immediate visibility of impact is the real requirement
What you should expect a system to do about engineering change is not to register the change. It is to show immediately what the change affects. Specifically, the higher-level assemblies that use the part, the quantities ordered but not yet received, the operations already started and the costs already posted to the project. If those four appear on one screen, the decision on whether to accept the change gets faster in itself.
On a feature list, all of this appears as a single line reading “engineering change management”. Behind that one line sit four connections – version control of the bill of materials, reconciliation against open purchase orders, linkage to shop floor records and retrospective treatment of cost. When you sit through a demonstration, ask for all four to be run on real data. In a demonstration environment where master data is fully prepared, every package performs beautifully. What you need to see is the behaviour when a change is applied while the bill of materials is only partly fixed.
Count the failures of communication
On top of that, put numbers to your own current state. For projects over the past 6 months, count three things – the number of engineering changes, how many of those reached manufacturing or purchasing late, and how many of the late ones caused rework. Those three numbers are the only basis you will have for judging whether the costs discussed later are reasonable. Industry averages from other companies are of no use here.
Fault line 4 – the estimate is built one way and the system costs another
The fourth fault line is the estimate. It tends to be taken lightly, yet it is where post-implementation confusion drags on longest.
Estimates build up by hierarchy, systems build up by item
An engineer-to-order estimate is usually built by function or by unit. Conveying section, processing section, control panel, frame, installation, commissioning, spare parts. Each carries an allowance for material, machining, subcontracting, design hours and installation hours, with a risk margin added on top to reach a total. Sales and design have refined that quotation format over many years, and the coefficients and productivity factors are embedded in the format itself.
The system, on the other hand, builds cost up by item and by operation. Material cost per part, machining time and labour rate per operation, unit prices for purchased parts. The axis of aggregation is different. So the cost corresponding to the estimate line called “conveying section” is scattered across several items and operations inside the system, and the two cannot be matched up in any simple way.
Without a match, budget-versus-actual management dies
A different axis on its own would only require a conversion. Without a conversion rule, though, budget-versus-actual comparison stops being possible at all. The estimate total and the actual cost total can be placed next to each other, but where the gap opened up cannot be identified. Comparing totals alone will never improve the accuracy of the next estimate.
Closing this fault line means building, before implementation, a mapping table between the estimate hierarchy and the system’s aggregation axis. It is the work of writing out, one to one or one to many, which project, which category and which group of operations each line of the quotation rolls up into. If a line turns out to have no counterpart, the choice is either to change the quotation format or to add a category on the system side. Defer that choice until after go-live and it comes back as an add-on.
Do not make the estimate too granular
There is a failure in the opposite direction as well. In the name of budget-versus-actual management, some organisations try to break the estimate down to match the system’s item level. At the estimating stage of an engineer-to-order project, neither the part count nor the model numbers are decided. Building up something undecided in finer detail does not improve accuracy – it only adds estimating hours. Leave the estimate at the functional level and bridge across with a mapping table, which is far more realistic.
High-mix low-volume production is not the same as engineer-to-order
At this point it is worth separating two terms that get confused. High-mix low-volume production and engineer-to-order production overlap, but they are not the same thing.
What differs
High-mix low-volume production describes a state where the number of variants is large and the quantity per variant is small. The variants are existing ones, and drawings and bills of materials exist. A model designed 10 years ago might be built once this year. In that case the master data exists. The pain is in changeover frequency, purchase prices on small lots, dormant inventory and the difficulty of building a plan.
Engineer-to-order production describes a state where no drawing exists at the moment the order is taken. The number of variants is beside the point. A plant that takes only 3 orders a year is engineer-to-order if each of those 3 is a new design.
What you need from a system changes
That difference changes what you should be asking a system to do.
| Point of comparison | High-mix low-volume | Engineer-to-order |
|---|---|---|
| State of master data | Exists, but there is a lot of it and maintenance is heavy | Does not exist at order entry. Created project by project |
| Main pain points | Changeover, small-lot purchasing, dormant inventory, replanning | Procurement on unsettled information, project cost, tracing engineering change |
| Unit of planning | Item and quantity. Levelling the load is central | Project and inter-operation dependency. Rescheduling is central |
| View of cost | Actual cost by item against standard variance | Cumulative plus estimate-to-complete by project |
| System priority | Accuracy of requirements planning and the scheduler | Version control of the bill of materials and earlier project cost |
What works on the high-mix low-volume side is the quality of the scheduler. Whether a plan can be built that accounts for setup time in the sequence, equipment constraints and people constraints decides how much effective capacity you get. How to choose in this area is covered in our production scheduler comparison.
On the engineer-to-order side, by contrast, improving scheduler accuracy has limited effect. The routing and the hours that feed the plan are not fixed until design is complete. Running a high-precision calculation over inputs that are not fixed does not improve the precision of the output. Shortening the time until things become fixed works better.
What to do in a plant that is both
In practice many plants have both characters. Modification projects on existing models and completely new design projects flow down the same line. In that case, split projects into two streams and define separate operating rules for each. Trying to run both with one rule means imposing the heavy procedure designed for new projects onto modification work, and the floor stops following it. One criterion is enough to split them – whether a drawing exists at the moment the order is taken.
What bites first changes by industry – metal fabrication, plastic moulding, automotive parts and electronic components
Even within engineer-to-order work, the first place things jam depends on the processes involved. Here are four areas that come up most often in enquiries from Japanese-affiliated factories in Thailand, viewed through the question of when information becomes fixed.
| Industry | Characteristic in terms of when things become fixed | Where it jams first |
|---|---|---|
| Metal fabrication and machining | Material procurement runs ahead of design. Once grade and dimensions are set, material can be ordered even without a model number | Connecting early material procurement to a bill of materials that is fixed later |
| Plastic moulding (injection moulding) | Mould design and manufacture run on a schedule separate from the project itself. Mould cost and moulding cost are accounted for differently | Projects treating the mould as an asset mixed with projects treating it as an expense |
| Automotive parts | Pre-production prototyping and jig manufacture are engineer-to-order, while volume production is close to make-to-stock. Two types coexist in one plant | Master data structures are not separated between prototype and volume production, so part numbers get mixed |
| Electronic components | Board assembly is mostly subcontracted and component part numbers change frequently. Switching to alternates is routine | Version control of alternate parts, and changes that never reach project cost |
Where metal fabrication bites
In engineer-to-order metal fabrication, material procurement runs first. Even before the drawing is finished, material can be secured once the grade and rough dimensions are known. In fact, unless it is secured, the delivery date is out of reach. This is the textbook case of fault line 1. Whether you can build a route in the system to procure material early against the project and later transfer it to the corresponding item on the finished bill of materials is what decides the outcome. Without that transfer, material cost sits in inventory and never reaches the project cost.
Where plastic moulding bites
In plastic moulding, the mould has a life of its own separate from the project. Designing and building the mould is engineer-to-order work in itself, while moulding is repetitive production. One project number therefore contains both a one-off mould build and the repeated moulding that follows it. Accounting differs too, depending on whether the mould is invoiced as a customer asset or held as a company asset and absorbed into the moulding unit price. If the system cannot distinguish the two, project cost stops meaning anything. Defining how moulds are treated as a project category is work that belongs before selection.
Where automotive parts bite
In automotive parts, pre-production prototyping and the manufacture of jigs and inspection fixtures are engineer-to-order, and once volume production starts the operation shifts to something close to make-to-stock. Two production types coexist in one plant. What goes wrong here is a tangled part numbering scheme. Provisional part numbers issued at the prototype stage are not switched over to formal numbers at the transition to volume production, and both survive. The same part ends up held in inventory under two numbers, and requirements planning stops adding up. Decide in advance whether to separate the master data structures for prototype and volume work, or to define a migration procedure.
Where electronic components bite
In electronic components, part number changes and switches to alternate parts happen routinely. What makes this area distinctive is that most engineering changes are driven not by the customer but by the supply side. The immediate visibility of impact described in fault line 3 matters here more than in any other industry. On top of that, where assembly is mainly subcontracted, you need to confirm that the bill of materials handed to the subcontractor matches the version held internally. Handing an old version to a subcontractor takes far longer to discover than internal rework.
Decide it on paper before selection – how to build the fixing-point table
Everything so far now turns into pre-selection work. Before you approach any vendor, build one table inside your own company. Here is how.
The procedure
Start by writing out the categories of project you handle. Completely new design, modification of an existing model, repeat order, prototype, service parts. Because the fixing points differ by category, do not mix them into one table.
Next, draw a time axis for each category. Enquiry, quotation submitted, order received, design started, basic design complete, detailed design complete, bill of materials fixed, procurement complete, manufacturing started, assembly, inspection, shipment, invoicing, project close. Substitute whatever terms your own plant actually uses.
Then fill in what becomes fixed at each point along that axis. There are 8 entries to fill – item code, bill of materials, routing, delivery commitment, hours estimate, material cost, subcontracting cost and project cost. Four of the five entries used in the first table carry across unchanged – item code, bill of materials, routing and delivery commitment – standard cost is replaced with project cost, and hours estimate, material cost and subcontracting cost are added. Standard cost is dropped because, as described earlier, a standard does not function as a basis of comparison in engineer-to-order work.
Finally, write in what is happening during the periods when nothing is fixed. Early procurement of long-lead items, design hours accruing, specification discussions with the customer, enquiries going out to subcontractors. What happens during those periods is the work that your system does not carry.
What the table tells you once it exists
Once the table exists, the questions you put to vendors change. Instead of asking whether a feature exists, you can ask “during the period between order entry and the bill of materials being fixed, on which screen do you record these four activities”. How many weeks that period runs in your plant is written on the time axis you just filled in. A vendor who cannot answer does not carry the work of that period. If that vendor put a circle beside the feature anyway, it will come back at you during requirements definition as an add-on.
The phenomenon the Panorama report describes, of critical misfits surfacing late in the project, can be avoided to a considerable degree by bringing this check forward. The same report also records that almost a quarter of organisations went over their planned schedule, and explains that even where technical execution went to plan, approvals, sign-offs and cross-departmental agreement slipped and the schedule stretched. The fixing-point table is also a tool for bringing that cross-departmental agreement forward. A state in which sales, design, manufacturing, purchasing and finance have all looked at the same table and agreed “this is not fixed here” is a state in which half of requirements definition is already done.
The granularity at which shop floor progress is captured is decided after this table exists. How to choose that granularity and what it costs is covered in our article on process management systems.
Where package, custom build and hybrid divide
Once the fixing-point table exists, choose the implementation approach. There are 3 options.
| Approach | Conditions it suits | Main risk |
|---|---|---|
| Standard package | Few project categories, fixing points close to the industry norm, and a willingness to adapt operations to the product | If handling of unsettled information is weak, outside workarounds survive and you end up with parallel management |
| Custom development | Fixing points are genuinely unusual and there are many project categories. Someone in-house can write a specification | Maintenance depends on individuals. Requirements move during the development period |
| Hybrid | Purchasing, inventory and accounting on a package, with project management and cost custom-built or on a separate product | Get the integration design wrong and a new reconciliation task appears |
Where the line falls
The dividing line is how the fixing-point table fills in.
A plant with one or two categories that can at least fix the item code at order entry has room to lean towards a standard package. If part numbers can be issued first, the later addition of the bill of materials and the routing can largely be absorbed by the package’s version control.
A plant with 4 or more categories, each with different fixing points, will struggle with a standard package. Each category needs its own branch in the operating rules, and those branches usually cannot be expressed in standard functionality. Here a hybrid is the realistic answer. Note, though, that with a hybrid the integration design becomes the main body of work. Which side holds the master record for items, which side owns the link between project and item, and which side closes cost. Line up products without settling those 3 points and a new reconciliation task is created.
Custom development is limited to cases where the fixing points really are unusual and that uniqueness is a source of competitive advantage. The thing to watch is that much of what a plant believes to be unique is in fact common across the industry. Before considering a custom build, take the fixing-point table to several package vendors and test it against them. The amount you end up investing differs greatly between discovering you are unusual after testing and deciding you are unusual without testing.
Count the add-ons in advance
Once the approach is chosen, count the areas that will be developed as add-ons. In engineer-to-order work the typical candidates are 4 – early procurement against an unsettled bill of materials, in-flight aggregation of project cost, display of engineering change impact, and conversion between the estimate and the system. Make all 4 into add-ons and the cost jumps. As the next section shows, the number of add-ons feeds directly into payback.
Break the cost into 5 layers
Before comparing quotations, split the cost into layers. Without layers there is no way to tell whether a cheap proposal is cheap or simply narrow in scope.
Assumptions for the model plant
Everything from here is an estimate produced for this article. Change the assumptions and the conclusion changes. All assumptions are stated.
The model is a plant on the outskirts of Bangkok with 180 employees. It builds engineer-to-order industrial machinery and jigs, and handles 240 projects a year. Annual revenue is 300,000,000 baht and the average order value per project is 1,250,000 baht. Lead time from quotation to shipment averages 14 weeks per project, made up of 4 weeks of design, 4 weeks of procurement, 5 weeks of manufacturing and assembly, and 1 week of inspection and shipping.
The average hourly rate for design, production control and purchasing is set at 300 baht. That is built up from a monthly salary of 30,000 baht plus 40% for statutory benefits, giving 42,000 baht, divided by 173 hours a month to reach roughly 243 baht, with about 23% added as an overhead allocation for premises and IT. This rate is a foundational assumption that feeds three places – effect 1, effect 2a and the in-house hours in layer 4 – so replace it with your own actual figure when you run the numbers. Currency is converted at roughly 4.4 yen to the baht and roughly 32 baht to the US dollar.
Users number 25, made up of 6 in design, 5 in production control, 4 in purchasing, 6 in manufacturing management and 4 in finance and administration.
The 5 layers
| Layer | Content | Initial cost | Annual cost |
|---|---|---|---|
| Layer 1 licence and subscription | 25 users at 1,600 baht per user per month | — | 480,000 baht |
| Layer 2 implementation support and requirements definition | Current-state survey, organising the fixing points, process design, test planning, training, 3 months of post-go-live support | 1,200,000 baht | — |
| Layer 3 add-on development | Developing 3 of the 4 candidate areas from the previous section – early procurement on an unsettled bill of materials, in-flight aggregation of project cost, display of engineering change impact | 1,800,000 baht | — |
| Layer 4 data migration and master data preparation | 600,000 baht outsourced plus 360,000 baht for 1,200 hours of in-house work | 960,000 baht | — |
| Layer 5 maintenance and enhancement | 15% a year on the sum of layers 2 and 3 | — | 450,000 baht |
| Total | — | 3,960,000 baht | 930,000 baht |
Initial cost totals 3,960,000 baht and annual cost totals 930,000 baht. At 4.4 yen to the baht, that is roughly 17.4 million yen and roughly 4.1 million yen.
Make layer 4 visible as in-house hours
The layer most often overlooked in that table is layer 4. Data migration and master data preparation appears in vendor quotations as a small line item for “support”, while the bulk of the actual work stays on your side. In engineer-to-order plants the hours balloon here in particular, because historical project data survives in a different shape for every project. This estimate carries 1,200 hours of in-house work. That is the level implied by 3 people drawn from design, production control and purchasing each putting in an average of 4 hours a day over 4 months, or 100 working days.
Leave those hours out of the quotation and the capital request looks cheap while normal operations grind to a halt during execution. Convert in-house hours into money and put them in the capital request.
Layer 3 decides the size of the investment
The other key point is that add-on development in layer 3 governs the whole. In this estimate, 3 areas come to 1,800,000 baht, about 45% of the initial cost. Of the 4 candidate areas listed in the previous section, conversion between the estimate and the system has been excluded here, because the mapping table described in fault line 4 can be maintained as a working practice rather than developed. Develop all 4 without narrowing the candidates and both initial and annual costs rise further. Layer 5 maintenance is tied to layer 3 as well, so it feeds the annual cost too. A comparison with add-ons narrowed to a single area is given in the payback calculation below.
The additional technology, expanded scope and custom development that the Panorama report cites as the background to budget overruns is exactly the route by which layer 3 inflates. The only way to stop layer 3 inflating is to build the fixing-point table before selection and decide which areas will be met by standard functionality.
The payback calculation
Effects are limited to 2. Reduction in rework caused by engineering changes that fail to reach the right people, and earlier visibility of project cost. Inventory reduction and lead time reduction sit outside the argument of this article, so they are not added to the effects.
Effect 1 – reducing rework from engineering changes that fail to reach the right people. With 240 projects a year and an average of 4 engineering changes per project, that is 960 changes a year. Setting the proportion that turns into rework because it reached manufacturing or purchasing late at 5% gives 48 cases a year. The loss per rework case is set at 25,000 baht, made up of 6,000 baht for 20 hours of labour and 19,000 baht for re-procuring material and subcontract work. The current annual loss is therefore 1,200,000 baht. If immediate visibility of impact halves the failure rate to 2.5%, the result is 24 cases and 600,000 baht a year, a reduction of 600,000 baht a year.
Effect 2 – earlier visibility of project cost. This splits in two. The first part is reconciliation work in indirect departments. Production control and finance are assumed to spend 40 hours a month, or 480 hours a year, reconciling project cost on spreadsheets. Halving that to 240 hours and multiplying by 300 baht gives a saving of 72,000 baht a year. The second part is correcting loss-making projects while they run. Setting the projects that end in a loss at 10% of 240, which is 24 projects, and the average loss per project at 100,000 baht, which is 8% of the 1,250,000 baht average order value, gives an annual total loss of 2,400,000 baht. That total deliberately excludes the rework losses from engineering change failures counted in effect 1, so that the same loss is not counted twice. If cost becomes visible 4 weeks after start rather than 2 months after shipment, and design simplification, subcontractor changes and negotiation of additional charges compress 25% of the loss, that is 600,000 baht a year. Effect 2 therefore totals 672,000 baht.
The total annual effect is 600,000 baht plus 672,000 baht, which is 1,272,000 baht.
Case A, developing all 3 add-on areas. As set out above, that is 3,960,000 baht initial and 930,000 baht annual. Annual net benefit is 1,272,000 less 930,000, which is 342,000 baht. Dividing 3,960,000 by 342,000 gives a simple payback of 11.6 years.
Case B, using the fixing-point table and the mapping table to separate what standard functionality and working practice can absorb, narrowing add-ons to the single area of the unsettled bill of materials. Layer 3 falls from 1,800,000 to 800,000 baht, and layer 5 becomes 15% of the 2,000,000 baht sum of layers 2 and 3, which is 300,000 baht. Initial cost is 1,200,000 plus 800,000 plus 960,000, which is 2,960,000 baht, and annual cost is 480,000 plus 300,000, which is 780,000 baht. Annual net benefit is 1,272,000 less 780,000, which is 492,000 baht. Dividing 2,960,000 by 492,000 gives a simple payback of 6.0 years.
| Item | Case A | Case B |
|---|---|---|
| Layer 3 add-on development | 1,800,000 baht | 800,000 baht |
| Total initial cost | 3,960,000 baht | 2,960,000 baht |
| Total annual cost | 930,000 baht | 780,000 baht |
| Annual effect | 1,272,000 baht | 1,272,000 baht |
| Annual net benefit | 342,000 baht | 492,000 baht |
| Simple payback | 11.6 years | 6.0 years |
The gap is 5.6 years. What produced that gap is not a difference between products. It is whether the decisions were made on paper before selection, so that the areas developed as add-ons could be narrowed down.
Apply a sensitivity factor only to the effect it belongs to
The least certain of the assumptions is the 5% rate at which engineering changes fail to reach the right people. Reset that to 3% and effect 1 becomes 0.6 times its value, or 360,000 baht. The 72,000 baht of reconciliation hours and the 600,000 baht of loss-making project correction in effect 2, however, do not depend on that rate. Reconciliation hours are determined by project volume and aggregation method, and loss correction is determined by when cost becomes visible.
| Effect | Treatment when the failure rate moves from 5% to 3% | Amount |
|---|---|---|
| Effect 1 reduction in engineering change rework | Multiply by 0.6 | 360,000 baht |
| Effect 2a reduction in reconciliation hours | Unchanged, no dependency | 72,000 baht |
| Effect 2b correcting loss-making projects in flight | Unchanged, no dependency | 600,000 baht |
| Total | — | 1,032,000 baht |
On that basis, the net benefit in case B is 1,032,000 less 780,000, which is 252,000 baht, and payback is 2,960,000 divided by 252,000, which is 11.7 years. In case A it is 1,032,000 less 930,000, which is 102,000 baht, and 3,960,000 divided by 102,000 gives 38.8 years.
Do not apply the factor uniformly to every effect. Multiply the whole 1,272,000 baht by 0.6 and you get 763,200 baht, which falls below the 780,000 baht annual cost in case B. Net benefit turns negative and the conclusion comes out as “it never pays back”. The correct answer for case B is 11.7 years. A uniform multiplication applied in the belief that it is the conservative view flips the investment decision. When you set a sensitivity, write one line stating which effect the factor is tied to before you apply it.
Three issues specific to Japanese-affiliated factories in Thailand
Evaluating a production management system in Thailand happens under different conditions from Japan. Here are 3 issues that bear on engineer-to-order work.
Issue 1 – investing while capacity utilisation is low
Thai manufacturing is in a difficult phase right now. According to the Office of Industrial Economics (OIE) under the Ministry of Industry, the Manufacturing Production Index (MPI) for June 2026 was down 3.1% year on year. Average capacity utilisation for the second quarter of 2026 was 57.47%. The largest declines were in automotive and petroleum, while sugar, cleaning products, soap and cosmetics and other everyday necessities increased.
A separate series, sourced from the Bank of Thailand, puts capacity utilisation at 57.61% in June 2026 and 59.59% in May 2026. Within that same series, the average from 2000 to 2026 is 67.85%, the high is 78.07% in January 2008 and the low is 49.21% in November 2011. The two series differ in source and in method of calculation, so do not merge them into a single figure. The long-run average of 67.85% is published only within the Bank of Thailand series, so the only comparable figure is 57.61% for June 2026 from that same series. The gap there is about 10 points. Do not subtract the OIE figure of 57.47% from 67.85%.
What carries weight in this phase is not investment premised on increased output. It is precisely when orders are falling that a mechanism for controlling profitability project by project earns its keep. Project cost visible while work is in progress supports both the decision to avoid a loss-making order and the decision to chase an order worth winning. Framed another way, it is an investment that stops a project taken at a low price during a weak period from turning out, much later, to have lost money.
Issue 2 – the hours required for training and adoption
A system does not run the moment it is installed. In engineer-to-order work a great deal of operational judgement stays with the people on the floor, so training carries more weight than in other production types.
As a reference point, consider the Japanese domestic statistics. According to the 2026 White Paper on Manufacturing Industries (overview), the proportion of manufacturing establishments that conducted off-the-job training in fiscal 2024 was 76.0% for permanent employees and 29.0% for non-permanent employees. The smaller the establishment, the lower the rate. At establishments with 30 to 49 employees the figures were 58.2% and 13.6%, whereas at establishments with 1000 employees or more they were 100.0% and 52.4%. Establishments supporting employee self-development stood at 83.7%. The underlying source is the Basic Survey of Human Resources Development, establishment survey, published by the Ministry of Health, Labour and Welfare in June 2025.
These are Japanese domestic numbers and do not describe Thailand directly. The tendency for planned training to fall away as establishment size decreases, however, is a structural pattern that transfers readily to a Thai site. Most Japanese-affiliated factories in Thailand run with fewer people than the Japanese head office, and in an environment where Japanese, Thai and English are all in use at once. A plan that covers training with “two days at go-live” is not realistic in engineer-to-order work. Make 3 months of post-go-live support an explicit part of the layer 2 implementation support.
Issue 3 – the double demand from the Japanese head office
A production management system at a Thai site carries two roles – running the local business, and producing the reports the Japanese head office asks for. The two often differ in granularity and in closing timing. Head office asks monthly for cost and inventory by item, while the site needs in-flight cost by project.
What tends to happen here is that requirements get set to match the head office reporting format. As a result, the project-based view the site needs most is pushed to the back of the queue. Reverse the order. Decide first the shape used in the local business, and build head office reporting by aggregation, and you get a system that is used daily. A system that is not used daily turns into a data entry exercise at month end to make the numbers agree, and the reliability of the data falls.
One further note. If you intend to apply for investment promotion measures, confirm eligibility before finalising equipment specifications or contracts. Depending on the requirements, conditions may attach to the scope covered or to the timing of implementation.
The order of implementation – the first 90 days and the first 6 months
Initiatives described under the heading of production management transformation usually fail to land because the scope is too wide. In engineer-to-order work, the realistic order is as follows.
The first 30 days – count
Do not talk about systems. Count the current state. The things to count are the number of projects by category, the days from order entry to the bill of materials being fixed, the number of engineering changes per project, the number of rework cases caused by communication failures, the days until project cost closes, and the reconciliation hours in indirect departments. Those 6 numbers are the foundation of every judgement that follows. The counting does not have to be perfect. Take the last 6 months and pull what you can from existing records.
Day 31 to day 60 – build the table
Build the fixing-point table. Put one person each from sales, design, manufacturing, purchasing and finance in the same room and fill it in together. Differences in how departments see the business will surface. Surfacing them is the point. Resolve them at this stage and rework during requirements definition falls away.
At the same time, build the mapping table between the estimate hierarchy and the system’s aggregation axis. That is the work described in fault line 4.
Day 61 to day 90 – test it against products
Take the two tables you have built and test them against several packages. When you sit through demonstrations, ask for 3 things to be run on real data – an engineering change applied while the bill of materials is only partly fixed, early procurement against an unsettled structure, and display of in-flight project cost. How far those 3 run on standard functionality determines the add-on cost in layer 3.
Month 4 to month 6 – narrow the scope and start
Do not go live across the whole company. Pick one project category and start there. Choose the category with high volume and the simplest fixing points. Do not start with completely new design projects. Launch on the hardest category and the early stumbles become the verdict on the whole thing.
Run one category for 3 months, close the operational gaps that surface, and then extend to the next category. This phased approach also works against the main cause of schedule overruns identified in the Panorama report, namely delays in approvals, sign-offs and cross-departmental agreement. The narrower the scope, the faster agreement comes. The same report also records that 55.3% of respondents said they had implemented business intelligence extensively. Rather than spreading the reporting layer too wide from the start, begin with a single view – project cost – which is the right order for engineer-to-order work.
Five failures that keep repeating
Finally, here are the failures that show up again and again in engineer-to-order implementations.
| Failure | What happens | How to avoid it |
|---|---|---|
| Selecting on a feature list | Functions with a circle beside them never start, because the inputs are not available | Build the fixing-point table first and turn the unsettled periods into questions |
| Assuming you are make-to-order | Requirements definition proceeds on the assumption that drawings exist, then collapses late on | Confirm across departments whether drawings exist at order entry |
| Piling on add-ons without narrowing the candidates | Layers 3 and 5 inflate and payback moves out of reach | Decide before selection which areas go to standard functionality and working practice |
| Leaving in-house hours out of the capital request | Normal operations stall during data migration and go-live slips | Convert the layer 4 in-house hours into money and include them |
| Starting with the hardest project category | Early stumbles become the verdict on the whole thing and usage stops | Start with a high-volume category with simple fixing points |
The third of these has the largest impact. This article compares case A, which piles on 3 of the 4 candidate areas, against case B, which narrows to 1, and simple payback moves from 11.6 years to 6.0 years. Develop all 4 and the gap widens further. Add-ons should not be determined by how many people asked for something. They should be narrowed to the areas the fixing-point table identifies as impossible to express in standard functionality.
The second failure is not a minor one either. Misjudging your own production type by one step in the easier direction shifts the entire premise of requirements definition. The gap surfaces at integration testing, and correcting the premise from there puts you straight onto the budget overrun path the Panorama report describes.
Frequently asked questions
Does an engineer-to-order plant need a production management system at all?
Rather than asking whether you need one, decide first what you are installing it for. In engineer-to-order work the usual justifications, such as inventory reduction and accuracy of requirements planning, have little traction. What has traction is earlier visibility of project cost and visibility of engineering change impact. If you can judge those 2 to be valuable, the investment makes sense. The material for that judgement is 3 numbers from the past 6 months – the count of engineering changes, the count of rework cases caused by communication failures, and the days until project cost closes. Decide to implement without counting those 3 and you will not be able to explain the effect after go-live.
What is the difference between high-mix low-volume production and engineer-to-order production?
High-mix low-volume production describes a state with many variants and small quantities per variant, where drawings and bills of materials exist. Engineer-to-order production describes a state where no drawing exists at the moment the order is taken, and the number of variants is beside the point. What you need also changes. In high-mix low-volume work, scheduler accuracy that accounts for setup pays off. In engineer-to-order work, the routing and hours that feed the plan are not fixed until design is complete, so improving scheduler accuracy has limited effect. In a plant with both characters, split projects in two according to whether a drawing exists at order entry, and define separate operating rules for each.
How much does a production management system for engineer-to-order work cost?
In the estimate used in this article, a model plant on the outskirts of Bangkok with 180 employees, 240 projects a year and 25 users comes to 3,960,000 baht initial and 930,000 baht annual. At 4.4 yen to the baht that is roughly 17.4 million yen and roughly 4.1 million yen. The breakdown is 480,000 baht a year for licences, 1,200,000 baht for implementation support and requirements definition, 1,800,000 baht for add-on development, 960,000 baht for data migration and master data preparation, and 450,000 baht a year for maintenance. These figures rest on model assumptions and move a great deal with the number of project categories and the number of add-on areas. Narrowing add-ons from 3 areas to 1 brings initial cost down to 2,960,000 baht and annual cost to 780,000 baht.
Are packages genuinely unusable?
Some plants can use them. The dividing line is the number of project categories and whether at least the item code can be issued at order entry. With one or two categories and an item code that can be fixed at order entry, the later addition of the bill of materials and the routing can largely be absorbed by the package’s version control. In a plant with 4 or more categories where the fixing points differ by category, a hybrid is realistic – purchasing, inventory and accounting on a package, with project management and cost handled separately. If you choose a hybrid, settle 3 things first – which side holds the master record for items, which side owns the link between project and item, and which side closes cost.
Does the same thinking apply to injection moulding and metal fabrication?
The thinking is the same, but the first place it jams changes. In metal fabrication, connecting early material procurement to a bill of materials fixed later is the pressure point. In plastic moulding, mould manufacture and repeat moulding coexist within the same project, so you have to define in advance whether the mould is invoiced as a customer asset or held as a company asset. In automotive parts, part numbering between prototype and volume production tangles easily, and in electronic components the frequency of switching to alternate parts makes display of engineering change impact matter more. The work of building the fixing-point table itself is common to every industry.
Can procurement before the bill of materials is settled be handled inside a system?
Some products handle it and some do not. The 3 things to check are whether there is a container for procurement linked directly to the project, whether quantities ordered under a provisional part number can be transferred to a formal part number, and whether the posting to project cost carries across at that transfer. In a demonstration, ask for a state to be set up where the bill of materials is only partly fixed, and then have early procurement and the transfer actually run. In a demonstration environment with master data fully prepared, every product performs beautifully. What you need to see is the behaviour starting from an unsettled state. If that does not run on standard functionality, it has to be costed as one add-on area.
Summary
An engineer-to-order plant finds a production management system a poor fit not because features are missing. It is because the package was built on the assumption that master data comes first, and in engineer-to-order work the product does not yet exist at the moment the order is taken. The difference is not features. It is the point at which each item becomes fixed.
In make-to-stock, all 5 items – item code, bill of materials, routing, standard cost and delivery commitment – are fixed before the order arrives. In engineer-to-order, not one of them is. Build that table and you gain an axis for evaluating products that is entirely separate from the circles and crosses on a feature list.
There are 4 fault lines. Procurement starts before the bill of materials is finished. Project cost only appears after the project ends. Engineering changes run outside the system. The way the estimate is built does not match the system’s cost structure. In all 4, a substitute already exists outside the system, so leaving them alone produces parallel operation.
High-mix low-volume production and engineer-to-order production are not the same. In the former, drawings and bills of materials exist and scheduler accuracy is what pays. In the latter, no drawing exists at order entry, and what pays is version control of the bill of materials and earlier project cost. Where it jams first also varies by industry – early material procurement in metal fabrication, the treatment of moulds in plastic moulding, part numbering between prototype and volume production in automotive parts, and version control of alternates in electronic components.
Cost splits into 5 layers. In the estimate used here, a model plant with 180 employees, 240 projects a year and 25 users comes to 3,960,000 baht initial and 930,000 baht annual. Limiting the effects to 2 – 600,000 baht from reducing engineering change rework and 672,000 baht from earlier project cost visibility – gives an annual effect of 1,272,000 baht and a simple payback of 11.6 years. Narrowing add-ons from 3 areas to 1 gives 2,960,000 baht initial and 780,000 baht annual, and payback shortens to 6.0 years. The 5.6 year gap comes not from a difference between products but from whether the decisions were made on paper before selection so that the add-on scope could be narrowed.
When you look at sensitivity, apply the factor only to the effect it belongs to. If you lower the engineering change failure rate from 5% to 3%, the only thing to multiply is effect 1. Reconciliation hours and loss-making project correction do not depend on that rate. Apply 0.6 uniformly by mistake and the conclusion becomes “it never pays back”, whereas the correct answer for case B is 11.7 years.
Factor in Thai conditions as well. MPI for June 2026 was down 3.1% year on year. Capacity utilisation averaged 57.47% in the second quarter of 2026 according to the OIE, and stood at 57.61% in June 2026 according to the Bank of Thailand series. Only the Bank of Thailand series is comparable with the long-run average of 67.85%, and June 2026 in that series sits about 10 points below it. It is precisely when orders are falling that a mechanism for controlling profitability project by project earns its keep.
So what has to be decided tomorrow is not a product name. Write out the fixing points for each project category on a single sheet. Count the days from order entry to the bill of materials being fixed and the number of engineering changes. Build the mapping table between the estimate hierarchy and the system’s aggregation axis. And separate, before selection, the areas that go to standard functionality from the areas that become add-ons. Get those 4 filled in before you request quotations and every vendor’s proposal will land on the same ground.
Even at the stage where your own company has not yet agreed internally whether it is engineer-to-order or make-to-order, it is perfectly reasonable to engage with us just to write out the fixing-point table together. TOMAS TECH supports Japanese-affiliated manufacturers in Thailand end to end, from measurement on the floor and process design through technical advice on product selection to hands-on support after go-live. Sometimes the exercise reveals that fixing the way an existing mechanism is operated is enough, so please feel free to get in touch through our contact page even if you are not assuming a system implementation.
References
- 2026 ERP Report — Panorama Consulting Group 170 respondents, data collected January 2025 to January 2026, median project duration 9 months, 56.5% multinational, median annual revenue 200.5 million US dollars, more than a quarter over budget, almost a quarter over schedule, 55.3% implemented business intelligence extensively
- Engineer-to-Order ERP Implementation Challenges — Elevatiq the product does not exist at the point of order, the bill of materials changes dynamically as design progresses, early procurement of long-lead items, project profitability known only after completion, engineering change managed outside the system, divergence between estimate and ERP cost structure, the boundary of record ownership between PLM and ERP
- Thailand manufacturing production index and capacity utilization for June 2026, released by the Office of Industrial Economics — Xinhua English MPI for June 2026 down 3.1% year on year, average capacity utilisation of 57.47% for the second quarter of 2026, declines in automotive and petroleum, increases in sugar, cleaning products, soap and cosmetics
- Thailand Capacity Utilization — Trading Economics capacity utilisation sourced from the Bank of Thailand, 57.61% in June 2026, 59.59% in May 2026, average of 67.85% from 2000 to 2026, high of 78.07% in January 2008, low of 49.21% in November 2011
- 2026 White Paper on Manufacturing Industries, overview — hosted on the Ministry of Health, Labour and Welfare site off-the-job training in manufacturing in fiscal 2024 at 76.0% for permanent and 29.0% for non-permanent employees, 58.2% and 13.6% at establishments of 30 to 49 employees, 100.0% and 52.4% at establishments of 1000 or more, self-development support at 83.7%, sourced from the Basic Survey of Human Resources Development, establishment survey
- Challenges and process improvement in engineer-to-order production — DIRECTOR the demand for high flexibility created by trial-and-error design changes and repeated specification changes, and the irregular handling required each time for delivery delays, cost status and information sharing
- Challenges in BOM management — SmartF missed updates arising from maintaining E-BOM and M-BOM by hand, rework caused by ordering and manufacturing from an outdated bill of materials, and the fragmentation that follows when design, manufacturing and purchasing each hold the bill of materials in a separate document
