The first part of the article already made it clear how machine learning can be implemented technologically. However, the question arises as to how the new experts from the engineering perspective should be classified in the development process. Is it a new 'super-discipline' that can dominate all other disciplines through the principle of 'knowledge is power' - just as the CFO can ultimately turn the money tap on and off according to the motto 'he who pays creates'? Or has the literal last link in the product development chain been found, which is placed at the end of a sequential development process after the software development department?

Implementing a genuine mechatronic development process in practice is an enormous challenge in itself and requires systematic coordination of the processes in addition to the openness of the management and the people involved. If data analysis and machine learning are added as an additional discipline, the situation becomes even more confusing. To get started, it is therefore important to first create the central organizational interfaces for the colleagues entrusted with the new cross-sectional engineering task. The value of the work stands and falls with the quality of the data that is available in the development process and can later be collected and processed during the ongoing operation of the machine. If the other disciplines involved in the development process and the company's IT are not prepared for this, only a suboptimal result can be expected, if at all. Balanced and interdisciplinary cooperation is a must!

Ideally, tool support that also enables joint, parallel and cooperative work at data level should also be taken into account. This so-called concurrent engineering or simultaneous engineering begins with joint, comprehensive requirements and error management and version management through to joint project management and holistic system simulations.

Nested processes

As with software development, the process steps in data analysis are most efficient when they can take place at very short intervals. Daily meeting cycles are often required at the start of a new project and short coordination intervals of two weeks for the entire duration of the project. This is the only way to counteract uncertainties:

• On the customer side: What do I expect from the data or what data quality can be provided for the respective question?
• On the contractor side: What must or can be achieved at all?

Figure 2: The CRISP model in an industrial context.

© Engineering office lean-digital-transformation

For the interaction with disciplines such as mechanical or electrical design, which traditionally think in longer cycles and quickly perceive short coordination rounds as a communication overhead, this means new potential for conflict in addition to coordination with software colleagues. Without active moderation by management, high friction losses quickly arise. In contrast, merging processes with software development will be much simpler in agile teams and easy to implement. In general, the pressure increases for all disciplines to coordinate at short notice. Only in this way can new findings or changed or new requirements be taken into account in a targeted manner. It is therefore not enough to simply implement information technology networking on the machine; it must also be an integral part of the cooperation between the various engineering teams(see Figure 1).

In the authors' view, the realization that only an iterative approach is effective is one of the key factors that determine the success or failure of an analytics project. This is also reflected in the fact that the 'Cross-Industry Standard Process for Data Mining' (CRISP for short) was defined more than 15 years ago, which describes an inherent cycle of process and data understanding, data preparation, modeling and evaluation before a model can be rolled out at the end(see Fig. 2).

Stakeholders of an analytics project

A practical interpretation of the CRISP model means, for example, that an initial short run-through is carried out at the start of the project in order to get a feeling for each individual point, which results are possible with simple initial approaches and which experts need to be involved for the subsequent runs. This can also counteract obstructive findings and attitudes of people involved in the project - such as "The correlations found are already known", "Too little background knowledge is integrated into the analyses", "The data actually required has not yet been provided". In many projects, the CRISP model has also proven to be correct in that many positive side effects of such a project, from data collection and data quality to an increased understanding of the process - and possibly even an improved process - have been achieved.

Authors:
Dr.-Ing. Hans Egermeier is an independent management consultant specializing in lean digital transformation;
Dr. Thomas Natschläger is Scientific Head of Data Analysis Systems Group at the Software Competence Center Hagenberg;
Markus Riedenbauer is Project Manager in the Research & Development department at Siemens Transformers Austria.