Smart customization is regarded as the success formula for OEM developers in machine and equipment construction who have to compete with low-cost machine builders. This way, they can, with a flexibly equipped order creation process, build a great variety of products on client specification and in small series (or even individual items). Thus, they meet customer demand with predictable quality, short runtime and low costs. But to be able to live up to this, these OEM developers of course need to have their product range in order. The process for organizing smart customization is made up of several steps: the problem definition, the setting of goals, a portfolio analysis, setting up the portfolio strategy, the MFD analysis and setting up a product roadmap.

In this article, I will discuss the first two steps in the process towards smart customization.

From a product point of view, modularisation is the basis for smart customization: setting up a product portfolio from cleverly designed, modularly built product families. The result is a product platform for effortlessly putting together orders from standard components and flexible modules that often are available in several variants (configure-to-order).

The first important steps are described below.

Problem definition and goals

Smart customization starts with structuring product families by cleverly defining the modules from which a family is built up. Demarcation of the various modules occurs on the basis of customer need (market research and order history) and functional analysis. The development of these product families then requires an integral approach in which the design of the machine, the organisation of the (business) process and the design of the supply chain, are attuned.

In order to properly structure this trajectory, we start with an orientation and definition phase. This should result in a clear problem definition and broad-based objectives. Because before we can label smart customization as the answer, we must get clear what the problem is with regard to the present product portfolio. Can it be found in the internal process, or in the match with customer demand, is it mainly a matter of costs and runtime of rather of quality?

An integral look at the order creation process should result in a clearly defined problem definition. On the basis of that, goals can be formulated. For example:

• Reduction runtime (9 to 6 months);
• Reduction integral cost price ( > 30%);
• Improvement (technological) performance;
• Reducation customization.

Portfolio analysis

Charting one’s own product range may look strange (“we all know this, don’t we?”), but it is often useful and can even be a real eye-opener. Because it (finally) produces a clear overview of the various customer requests and of product implementations and the variation that have occurred here as a result of customer demand. An important benchmark is the number of engineering hours per million Euros turnover. A value that is too high could indicate that there is an uncontrolled growth in customer specificity. Result of the exercise is a product map which presents an overview of all base blocks and the various options and variants from which different configurations are compiled.

From the product map design parameters are distilled that are responsible for product diversity: which user requirements pave the way for variation in implementations? The trick is to describe this in terms of several clearly defined functions that gather in the product. Because thinking in functions is crucial if you want to be able to make the step towards modularisation.

The product map shows what exactly has been possible on the supply side of things. Then the demand side comes into the picture by quantifying the order history. What has been sold over the past years: which versions were preferred by the customer, which options were popular, and which variants were not in high demand? It is important here to look at the dynamics and follow the design parameters during that period. Were there any trends in market demands that led to a different preference for certain implementations? This too can shed a new light on the existing product portfolio.

It is especially interesting to find out if the range across the entire scope connects with market demand. It might very well be that the range has been broad in its scope and that in practice the demand is limited to part of the product range. Then effort is put into it and perhaps even a supply for implementations is build up for which is no, or hardly any, demand. Probably there are too many specific versions that remain ‘on the shelf’ while with just a limited number of – smartly defined and flexible – modules it is much easier to meet customer demand. A significant reduction of complexity and operating burden is then possible.

After the problem definition, objectives and portfolio analysis, comes the setting up of the portfolio strategy, the MFD analysis and setting up of a product roadmap. This will be discussed in part 2.

Want to know more about modular designing? Please get in contact.