Der erste Teil des Artikels machte bereits deutlich, wie sich maschinelles Lernen technologisch umsetzen lässt. Doch stellt sich die Frage, wie die aus der Perspektive des Engineering neu dazugekommenen Experten im Entwicklungsablauf eingeordnet werden sollen. Ist es eine neue ‚Über-Disziplin‘, die über das Prinzip ‚Wissen ist Macht‘ alle anderen Disziplinen dominieren kann – so wie am Schluss der Finanzvorstand nach dem Motto ‚Wer zahlt schafft an‘ den Geldhahn auf und zu drehen kann? Oder wurde nun das buchstäblich letzte Glied in der Kette der Produktentwicklung gefunden, das am Ende eines sequenziellen Entwicklungsprozesses nach der Software-Entwicklungsabteilung eingereiht wird?

Einen echten mechatronischen Entwicklungsprozess in der Praxis umzusetzen, ist schon eine enorme Herausforderung für sich und erfordert neben der Offenheit des Managements und der jeweiligen beteiligten Personen eine systematische Koordination der Prozesse. Kommt nun die Datenanalyse und maschinelles Lernen als weitere Disziplin hinzu, wird die Gemengelage noch ein Stück unübersichtlicher. Für den Einstieg ist es daher wichtig, zuerst die zentralen organisatorischen Schnittstellen für die mit der neuen Querschnitts-Engineering-Aufgabe betrauten Kollegen zu schaffen. Der Wert der Arbeit steht und fällt mit der Qualität der Daten, die im Entwicklungsprozess vorliegen und später im laufenden Betrieb der Maschine gesammelt und verarbeitet werden können. Stellen sich die ­weiteren am Entwicklungsprozess beteiligten Disziplinen und die Unter­nehmens-IT nicht darauf ein, so ist, wenn überhaupt, nur ein suboptimales Ergebnis zu erwarten. Ein ausgewogenes und interdisziplinäres Miteinander ist Pflicht!

Optimalerweise ist zudem eine Werkzeugunterstützung, die auch auf Datenebene ein gemeinsames paralleles und kooperatives Arbeiten ermöglicht, mit berücksichtigt. Dieses sogenannte Concurrent-Engineering beziehungsweise Simultaneous Engineering beginnt mit einem gemeinsamen übergreifenden Anforderungs- und Fehlermanagement sowie der Versionsverwaltung über ein gemeinsames Projektmanagement bis hin zu ganzheitlichen Systemsimulationen.

Verschachtelte Prozesse

Die Prozessschritte bei der Datenanalyse sind wie bei der Software-Entwicklung am effizientesten, wenn diese in sehr kurzen Intervallen stattfinden können. Oftmals sind tägliche Meeting-Zyklen zu Beginn eines neuen Projekts und kurze Abstimmungsintervalle von zwei Wochen zur gesamten Projekt­laufzeit erforderlich. Nur so kann den Unsicherheiten entgegnet werden:

• Auf Kundenseite: Was erwarte ich mir von den Daten beziehungsweise welche Datenqualität kann zur jeweiligen Fragestellung überhaupt zur Verfügung gestellt werden?
• Auf Auftragnehmer-Seite: Was muss beziehungsweise kann überhaupt erreicht werden?

Bild 2: Das CRISP-Modell im industriellen Kontext.

© Ingenieurbüro lean-digital-transformation

Für das Zusammenspiel mit Disziplinen wie der Mechanik- oder Elektrokonstruktion, welche  traditionell in längeren Zyklen denken und kurze Abstimmungsrunden schnell als Kommunikations-Overhead empfinden, bedeutet dies neben den Abstimmungen mit den Software-Kollegen neues Konfliktpotenzial. Ohne aktive Moderation durch das Management entstehen schnell hohe Reibungsverluste. Die prozesstechnische Verschmelzung mit der Software-Entwicklung hingegen wird in agil arbeitenden Teams deutlich einfacher sein und sich leicht umsetzen lassen. Generell steigt der Druck für alle Disziplinen, sich kurzfristig abzustimmen. Nur so können neue Erkenntnisse beziehungsweise geänderte oder neue Anforderungen gezielt berücksichtigt werden. Es ist damit sozusagen zu wenig, die informationstechnische Vernetzung lediglich technologisch auf der Maschine umzusetzen, diese muss auch ein integraler Bestandteil im Miteinander der unterschiedlichen Engineering-Teams sein (siehe Bild 1).

Die Erkenntnis, dass nur iteratives Vorgehen zielführend ist, ist aus Sicht der Autoren einer der wesentlichsten Punkte, die über Erfolg oder Misserfolg eines Analytics-Projekts entscheiden. Dies spiegelt sich auch darin wieder, dass bereits vor mehr als 15 Jahren der ‚Cross-Industry Standard Process for Data Mining‘ (kurz CRISP) definiert wurde, der einen inhärenten Zyklus von Prozess- und Datenverständnis, Datenaufbereitung, Modellierung sowie Evaluierung beschreibt, bevor am Ende ein Modell ausgerollt werden kann (siehe Bild 2).

Stakeholder eines Analytics-Projekts

Eine praxisnahe Auslegung des CRISP-Modells bedeutet beispielsweise, dass man zu Beginn des Projekts für einen ersten kurzen Durchlauf sorgt, um für jeden einzelnen Punkt ein Gefühl dafür zu bekommen, welche Ergebnisse mit einfachen ersten Ansätzen möglich sind und welche Know-how-Träger für die weiteren Durchläufe einzubinden sind. Auch kann damit hinderlichen Erkenntnissen und Einstellungen projektbeteiligter Personen – wie „Die gefundenen Zusammenhänge sind bereits bekannt“, „Es ist zu wenig Hintergrundwissen in die Analysen integriert“, „Die eigentlich notwendigen Daten sind noch nicht bereitgestellt“ – entgegengewirkt werden. In vielen Projekten hat sich die Richtigkeit des CRISP-Modells auch dahingehend gezeigt, dass sich viele positive Nebeneffekte eines solchen Projekts von der Datenerfassung über die Datenqualität bis hin zu einem gesteigerten Prozessverständnis – und eventuell sogar verbessertem Prozess – einstellen.

Autoren:
Dr.-Ing. Hans Egermeier ist selbstständiger Management Consultant mit dem Schwerpunkt Lean Digital Transformation;
Dr. Thomas Natschläger ist Scientific Head of Data Analysis Systems Group im Software Competence Center Hagenberg;
Markus Riedenbauer ist Projektleiter im Bereich Research & Development bei Siemens Transformers Austria.