ERP for engineer-to-order and project manufacturing
ERP (Enterprise Resource Planning) was developed from MRPII (Manufacturing Resource Planning) which was in turn developed from MRP (Materials Requirements Planning), so all full-functionality ERP systems offer good manufacturing functionality; although companies have to choose carefully because not all ERP systems are full-functionality systems but are just accounting systems with some basic buy/assemble/stock/sell functionality added.
But there is a second problem; and that is that manufacturing is actually a spectrum, with continuous processing at one end and engineering job shops at the other. The roots of ERP/MRPII/MRP are in batch manufacturing, where the same products are in continuous, or at least continual, production but, as we move towards the job shop end of the spectrum, some ERP systems (and their implementers) can become increasingly challenged.
Job shops tend to be small and can generally get by with just having an accounting system, backed up by spreadsheet-based manual systems, but alongside them on the spectrum are ETO (engineer to order) and project manufacturing companies (for brevity; we'll use the term ETO for both) whose needs are more demanding.
These companies are not making the same items repeatedly and, although some of their products will be variations on a theme, they require functionality that not all ERP systems can offer. Companies should not choose a mainstream system that does not fit their needs just because they think that is all that is available because, if they look carefully, they will find what they need.
But, before they commence their search, they need to know how even some very well-known, and expensive, systems can have weaknesses and gaps. This blog looks at functionality requirements in:
Companies that make the same items repetitively have a pretty good idea of what they cost to make and usually make price lists available to their customers, but with ETO manufacture there is little repeat business and so most orders require a cost estimate to be prepared before a price can be calculated.
An ERP system can help by holding the last purchase price against bought-in items and can also help by allowing the bills of material and manufacturing routings of previous similar jobs to be copied and used as the basis for new quotes (even when products differ, some sub-assemblies can be similar).
Take a manufacturer of specialist motor vehicles. Some will allow a standard body to be built onto the customer's choice of running gear or chassis cab, and might also allow customer-specific modifications to that body. With a fire truck for example: as well as a choice of running gear, different fire departments may have different equipment preferences.
The system also needs to handle changes to the initial estimate which can happen when design errors are identified or when the customer requests design changes. This usually requires change history, usually by having separate estimate revisions, along with the reason for the change and an indication of whether the changes are chargeable to the customer or not.
ETO companies have costing requirements that can differ from those of batch manufacturing companies. The latter need to ensure that costs from batch to batch remain on track and generally use Standard Costing to measure and track both purchasing and manufacturing variances so that remedial action can be taken where appropriate.
But ETO companies rarely have that option so Standard Costing is not a good option because variances are written to a separate file and not to the job and so the final item cost does not reflect those variances. That makes it anything from very difficult to actually impossible to know if a job is on budget during manufacture and, on completion, whether it has returned a profit or loss.
Larger jobs place additional demands on the system. One is that management frequently needs a “cost to go”, and this is not usually as simple as “estimate minus cost so far”. When a job is running over-estimate (and see the comments above about the importance of actual costs), the estimate or budget may need to be adjusted to reflect both that and future expectations.
The second major difference is that, in large jobs, stage payments are common. These may be time-related or may be linked to progress milestones and, in either case, the ability to hold a project structure on the system, and to be able to link both costs and revenue to particular nodes of that structure, are major benefits.
Although the price is usually the first question in a prospective customer's mind, delivery times come a very close second but quoting an accurate and achievable delivery date can be difficult for two reasons, the first of which is that companies may have to quote a delivery date before the detailed design has been completed.
Good capacity scheduling systems are affordable today but they can't schedule tasks if they don't know how long those tasks will take, so the key to their success in ETO environments is an appropriate level of detail in the estimate. It is worth remembering that sometimes design time is a very significant factor and many companies have seen value in using their capacity scheduling system to also schedule work in their design department.
The second problem that ETO companies can face is that, although some can quote delivery from the date of order, some have to commit to a specific date in order to win the order. Calculating an achievable delivery date is not a problem but, if there is a delay between raising the quotation and the customer accepting it, then there can be a need to reserve capacity in key departments.
The question, from a business point of view, is how long that capacity should be reserved, given that it might prevent other orders from being accepted, and how best to reserve it on the system.
The functionality available in the main ERP system and in the capacity scheduling system usually dictates the methodology. Sometimes a quotation can be entered into an ERP as a sales forecast with an expiry date but, although this can work from a capacity perspective, companies have to satisfy themselves that their system's MRP module will not react to it and order materials prematurely.
Frequently it is better to reserve resources in the capacity scheduling module even though procedures have to be put in place to ensure that such reservations are cleared down when they cease to be relevant.
The need to reserve capacity is not enough, because there is little point in doing so if the materials required for those orders are not going to be available, and so the system must allow for materials to be reserved also. How it does so will vary from system to system but, just as with capacity, there needs to be a way to release these reservations if a quotation is not accepted in good time.
Frequently, though, materials will need to be ordered in for specific jobs. Many companies like to use MRP to consolidate requirements in order to benefit from volume discounts and reduce purchasing costs but most MRP systems have multiple options for satisfying demand: they can increase an existing order, they can pull forward an existing order and they can raise a new order. MRP knows the source of each demand but it doesn't really care, so usually, orders are not hard-linked to requirements.
Imagine a scenario where items have been ordered for Job A but now a new order, Job B, arrives and that customer requires a quick delivery (before Job A). In these circumstances, MRP may want to use the materials ordered for Job A to satisfy Job B and then reorder the Job B items.
But perhaps delivery of that new order is required within the supplier's normal lead time and the company has to pay a premium price. Now Job A is being penalized and the true costs of Job B are being understated; meaning, of course, that the profitability calculations on both jobs are inaccurate.
And if both jobs are running in parallel, and both sets of materials are in stock together, most systems will want to issue those materials on a FIFO basis, so even hard-linking the purchase orders won't necessarily solve the problem.
Now; to make things even worse, imagine that the materials for Job A were actually customer supplied, and imagine telling that customer that their order has been delayed because you used their materials on another customer's job. The reality is that many companies have to hard link both purchase orders and stocks to particular jobs and that is not something that all ERP systems can do.
One final thought on materials management is that many ETO companies need to subcontract some operations, such as plating or specialist testing and inspection. For maximum operational efficiency, the system needs to be able to prompt for purchase orders to be raised for such activity, be able to prompt for the dispatch of items to the subcontractor, and be able to apply the costs automatically to the appropriate job.
ETO companies have a number of requirements that not all ERP systems can satisfy. Even though not all companies need all of the functionality discussed here, if one or more of these issues is being handled manually (via spreadsheets, for example) then they are not operating as efficiently as they could or should be. And if they are looking at a new system that lacks the functionality they need, perhaps they should look further.
Featured white papers
Manufacturing ERP: 10 steps to success
Complete step-by-step guide to manufacturing ERP softwareDownload
Manufacturing ERP Implementation Checklist
Over 70 actionable steps to rolling out new manufacturing ERP softwareDownload
Top 10 Manufacturing ERP Software Comparison
Compare the best manufacturing ERP systemsDownload
9 manufacturing ERP modules to look for in your next ERP
The top manufacturing ERP modules you need to factor into your requirements
Why a food specific ERP system is a must-have
Key features and requirements food companies should consider when searching for an ERP
Process manufacturing ERP: formulas and recipes
Find out about the challenges your process manufacturing ERP will face when it comes to recipes a...