Product variants under an Industry 4.0 based CTO model

4 mins read

The ability to offer as many product variants under an Industry 4.0 based CTO model will depend heavily on engineering data management efficiency.

Industry 4.0 remains an extremely hot topic, encompassing as it does IoT, cloud computing and automated data exchanges. It is also accommodating automated configure-to-order (CTO) within manufacturing scenarios, which gives companies the ability to define customer-specific functionality in a controlled process.

Within manufacturing, CTO is fast becoming a cost-effective alternative to engineer-to-order (ETO) practices and is regarded as a better way of managing the growing number of customer-specific product variants; though switching from ETO to CTO is not without challenges (see box).

Offering product variety is considered key to the survival of most OEMs as it allows them to improve supply and demand alignment. Or, to put it another way, if one OEM doesn’t offer a particular feature set there’s a chance a competitor will. Similarly, the need for new combinations of features (including new ones) may be indicative of a new trend.

Unfortunately, a growing number of product variants leads to greater product and supply chain complexities; threatening margins and introducing quality risks.

Determining the optimum value/cost relationship for variants, requires consolidated inputs from many departments and disciplines

The first step is therefore the analysis of market requirements and their representation in a Feature Tree. It allows only valid feature permutations; e.g. a car manufacturer won’t offer an option whereby a car can have a soft-top and a sunroof. As engineers, working with colleagues in procurement, QA, HR, finance etc., we can then create a Variant Tree to give ourselves sight of the complexities associated with all variants. Complexities will include component costs, lead times, inventory logistics, tooling costs and operator skills. In addition, it could be that each product variant requires its own test strategy. And what about certification? Regulatory compliance? There’s also the documentation to consider; schematics, bills of materials, assembly instructions (for manual operations) and output files for automated assembly lines.

However, this should not be uncharted waters for some. As a process, CTO can be thought of as automating many aspects of build-to-order (BTO), which most OEMs and many CEMs already operate; e.g. part-building products (base units) and holding them in Kanban until the required variant and quantities thereof are known.

As OEMs and CEMs push further into Industry 4.0, the automated steps for CTO will need to increase in number and link to form unique flows for each possible product variant. Understandably, automated CTO will require bullet-proof data management within a highly integrated supply chain.

Given that component data is available from the engineering tools, it can be leveraged in a CTO model so that product variants start to exist the moment engineers bring together hardware, software and mechanical elements. But are today’s tools and methodologies up to the task?


Many engineering departments manage their design data within their organisation’s enterprise resource planning (ERP) system. Characteristics of an ERP include real (or near real) time performance and a common database;

However, ERP software is typically focused on business processes and the utilization of resources. For this reason, some companies also use one or more complementary solutions/tools for:

Product lifecycle management (PLM) – the process of managing the entire life of a product from inception through to disposal/recycling if applicable. It covers all stages in between such as engineering design, manufacture, test, commissioning and in-service maintenance and support.

Product data management (PDM) - a subset of PLM, is the use of software tools to track and control data related to a product, or variant thereof. Data tracked includes technical specifications, materials/components needed and costs. PDM will also include CAD models, drawings and associated documents. Metadata will include the identification of file owners, file check-in and check-out details, and change management.

Material requirement planning (MRP) and manufacturing resource planning (MRP II). Both are predecessors of ERP though are still widely used, independently and as modules of more comprehensive ERP systems. They are designed to facilitate decision making for production line managers, increase the efficiency of the production line and help managers determine the timing of raw material purchases (and quantities).

Document management systems (DMS) - used to track, manage and store documents, reduce paper and keep records of the various versions created and modified by different users (history tracking).

From ETO to CTO

Due to the growing complexity of engineering-to-order strategies, many companies are aiming to reduce the proportion of engineered product content in favour of configured content; i.e. switch from ETO to CTO. However, that switch cannot be made by simply re-organising and managing existing product content. Instead, the switch requires a thorough analysis and consolidation of the existing engineering portfolio, and a reengineering of organisational and supporting processes.

All stakeholders in the process need to have a clear understanding of the impact of variants on complexity. This requires a seamless process integration of all involved disciplines, especially engineering, sourcing and production.

However, the above tools are point solutions; isolated pockets of improvement through automation. Between the pockets is a host of manual activities, such as phone calls and emails made between engineers to clarify issues. Things get worse when a design is signed off and the bill of material needs to tie in with physical items. More calls need to be made, this time between engineers and purchasers and between purchasers and suppliers.

Automated CTO (as part of Industry 4.0) is all about having far greater digital connectivity and avoiding all the time-consuming, manual and prone-to-misinterpretation communications. It also promises to remove the wealth of admin tasks that currently distract us from our core activities; engineering, adding value etc.

The ultimate goal? Any company operating truly automated CTO (and therefore within Industry 4.0) could be characterised as:

Not having any physical/geographic limitations and is connected to sister companies, partners and suppliers via the cloud;

Is competing against similarly omnipresent companies;

Emails and phone calls are seldom necessary and are activity discouraged;

There are seamless exchanges of data between all engineering design tools (e.g. electrical/electronic CAD and mechanical CAD), PLM, ERP, PDM and DDM tools etc;

Extremely flexible – and offering as many product variants as is practical;

In step with all market needs (i.e. a dynamic Feature Tree);

Having engineers that create modular components (be they hardware, software, mechanical etc..) that can be automatically configured in (only) legitimate combinations (i.e. as policed by the Variant Tree).

Increasingly, markets will be served by configured standards. Those competing in the markets will need to establish a formal mapping for their product development, identify all complexity, and have a sound IT infrastructure in place

Regarding this last point, it will be interesting to see how engineering time can and should be valued moving forward. The creation of the modular components requires up-front human effort, but ROI becomes increasingly dependent on automation.

In summary, variety-induced complexity is a necessary evil under CTO. Companies that stand to do well will be those that set out not to reduce complexity but rather find the optimum tools and processes with which to embrace it.

Author details:

Oliver Hechtl is Head of Data Management and Integration Solutions at Zuken