Modularity for dummies, part IV
In the previous part we learned how, by offering more variants and applying control technology and software, the complexity of products continues to increase. Even LEGO cannot escape this: see LEGO Mindstorms (a programmable robot) in the image above this article.
It also turned out that modularity can hide this complexity, but it does not simplify it. And we learned that modularity mainly offers advantages for sales, logistics, production and service.
Engineering will always have to control complexity down to the smallest detail.
Denying complexity in the sales phase bounce back . . . up on the desk of engineering. This is the well-known ‘gap’ between sales and engineering; two worlds that don’t always seem to understand each other.
Imagine the frustration when it turns out that the LEGO box you just bought doesn’t contain the correct blocks to build the robot pictured on the front!! An expectation that cannot be met….. Or … you have to wait a longer for the delivery … because LEGO still has to find the right blocks together ….
There are several ways to prevent this. Ideally, you remove engineering entirely from the supply chain. Just like car manufacturers and IKEA do. That works fine for large volumes of products with a long innovation cycle of several years. Product development and innovation then takes place in a separate R&D department.
With smaller volumes and continuous product development, one cannot avoid having engineering to work in closely cooperation with sales, production and service. Every new customer request can initiate an innovation and contribute to the further development of the product. But how do you ensure that sales and engineering know how to find each other?
Setting up a product configurator is a good way to close the gap between sales and engineering.
After all, a few important questions need to be answered when setting up a product configurator:
- what is the product we make? Which parts is it made up of?
- how do we make the product? How are the parts assembled into one whole?
- which products do we sell? Which variants do we want to offer?
- why customers want our products? Which functionalities have added value?
Configurator software can be used as a means of getting these questions answered. Questions 1 and 2 can be answered by your engineers and questions 3 and 4 by your sales people.
Product configurators are on the rise because product suppliers want to satisfy the customer and still want to keep the number of product variants under control. All (technically) possible and (business-economically) desirable combinations are defined within the product configurator.
You don’t have a product configurator for your product? Then you might wonder; how and by whom, and at what point in your value chain, it is determined which product variants are possible and permitted?
Perhaps that is the reason that in practice, despite the use of a product configurator, the gap with engineering is still not closed. In such a case I see things go wrong on a number of points:
- the output of the sales configurator leaves room for interpretation; the level of detail is insufficient (modularity index <100%) and leaves room for ‘creative’ interpretation by engineering or production departments.
- the modularity is good enough to cover the variants in the sales brochure, but does not correspond to the actual product structure.
- the output of the sales configurator is incomplete; for example, produces the mechanical Bill of Materials only. Software and electrical parts are not taken into consideration.
In all cases we see a mismatch here between the product model as seen by sales and the product model as seen by engineering. Because of this, something goes wrong in the information transfer … and someone will have to fix that.
Some companies are already a bit further and have managed to link their sales configurator to the product configurator of the engineering. In this way a seamless transfer of information can be achieved.
In the next part I will try to come to a nice conclusion … because we can write 100 more articles about modularization!