Product Configuration and Engineering
One of the most common business questions we encounter is whether the ERP system is able to combine product configuration with additional engineering.
We understand the question. Many of our customers sell configurable equipment where customer specific enhancements are common. These enhancements have to do with specific applications that the equipment is used in and can never be part of a configuration. For engineering these enhancements are not a big design challenge. The problem lies in the workflow and whether an ERP system is able to handle this business scenario.
Configurators are primarily designed to produce a BOM and a Route, in addition to things like pricing and configured product descriptions (or even entire manuals). The idea behind the configurator functionality is that the produced BOM and Route are complete, so a sales order can become a production order immediately. But for many of our customers this is simply not how their process works.
Considerations…
If the business frequently requires additional engineering on top of a configured product, three things have to be investigated in the ERP system:
Can the BOM as produced by a configurator be changed? This will normally be the case but doing this will create difficulties for the re-use of existing configurations. If the re-use functionality would copy an existing BOM and route of a previously configured item, we would copy the engineered modifications also. What should be done instead is to make copy of the configured BOM and add the uniquely engineered part numbers to it. On the BOM a sales order# or project# should be added for later searching. The copy of the configured BOM then becomes the correct ‘Sales-BOM’ with the engineered enhancements.
The second thing is the use of projects. Project functionality is typically required when engineering activities take place. Design cost has to be captured and design time has to be planned for. So it has to be possible to run the configurator in the project module or in a sales order with a project number attached. This starts the discussion with cost accounting: whether configured products should be considered “standard” products and should have a standard cost. For the “clean” configure-to-order scenario, the answer would be yes, in our scenario, when using projects, actual cost makes more sense. It depends on the product and the company and we have seen different outcomes of this discussion.
Finally, the configurator model that contains the logic of configuration should be flexible enough to capture requirements for this additional engineering. A typical example would be when the configurator-user enters dimensions that exceed a certain standard range. The configurator could then display a message that this would require engineering and offer a text box for further details. This could trigger an alert to engineering and the quote or sales order would be routed to engineering for completion. The specs in the text would be converted into specific time and material estimates. When it is a sale, new part numbers and BOM’s would be created. But there is another potential complication. When the configurator is allowed to create new finished good part numbers, an automated cost roll typically follows. In a standard cost environment, a new item master typically requires to be costed in order to proceed with manufacturing and shipping. This process would have to be interrupted for these ‘engineered specials’ that require further BOM definition and will be cost estimated later. This is another argument to use actual cost if a company typically sells configurations with additional engineering required.
ERP software vendors typically have separated the functionality for “assembly to order” (configuration) and “engineer-to-order” in different modules.
It is up to experienced implementors to use these functionalities in combination in order to create the fit with the customer’s business process.
The end result will be a solid ERP business process from Quote to Order Fulfillment where the traditional strengths of configurators can be used in an Engineer-to-Order environment.
Evert Bos. CPIM, CIRM – Sr. Solution Architect, Streamline Systems, LLC
Tags: BOM, Dynamics AX, Engineer-to-order, Engneering, ERP System, functionality, Product Configuration
Product configuration is one of the greatest challenges for ERP systems. There are many good web-based add-on programs that now integrate with MS Dynamics AX and other Tier 1 and 2 ERP packages. Companies who have been able to modularize their products and offer sellable configurations have often reduced the overhead associated with product engineering and reduced the time to market significantly. There are substantial savings to be gained!
typical example would be when the configurator-user enters dimensions that exceed a certain standard range. The configurator could then display a message that this would require engineering and offer a text box for further details. This could trigger an alert to engineering and the quote or sales order would be routed to engineering for completion
Isn’t removing this step, one of the main reasons and benefits of using a configurator based on engineering rules and constraints? Consultation between customers, sales and engineering lengthen quote to order times and eat up margin.
Do you have a specific example of customers who are using the scenario you explain and reasons why they are not allowing customers to configure the “extras”?
Thanks,
Ryan
The context for the blog is in manufacturing environments that often require engineering “post-configuration”. We agree and typically push for as complete a configuration or modular product structure as allowable which provides the optimum benefits and cost savings. We do have a few customers that we work with who have this unique instance of additional engineering either required or requested in addition to their normal product configurations. They can satisfy the majority of their customers with configurations with “extras” but due to the complexity of the machines have run into cases where additional engineering was required in addition to the complete configuration.
I believe we have found that these instances often then find their way into the library of rules and can eliminate future instances of post-configuration engineering but having an approach to address them formally as they surface has enabled them to maintain customer satisfaction in a demanding market.