Die meisten Unternehmen haben längst erkannt, dass bei immer komplexer werdenden Produkten an Systems Engineering kein Weg vorbeiführt. Trotzdem wird erstaunlich häufig nach wie vor in isolierten Silos gearbeitet. Unter anderem liegt das sicherlich daran, dass Systems Engineering für die meisten ein schwer fassbarer Begriff ist. Georg Kraft, Senior Director für das Consulting im Bereich Industrial Equipment Business Experience, bringt Licht und Struktur ins Thema.
Herr Kraft, beginnen wir am besten damit, den Begriff Systems Engineering zu definieren. Was verstehen Sie darunter?
Systems Engineering ist kurz gefasst eine Technologie, um interdisziplinär zusammenarbeiten zu können. Das Problem ist ja, dass heutige Produkte zum einen immer komplexer werden und zum anderen viele Disziplinen beteiligt sind – Mechanik, Elektrik, Elektronik, Software, Hydraulik und so weiter. Und diese Disziplinen auch heute noch viel zu oft nebeneinander her arbeiten. Ein Kunde sagte mir einmal: „Wir haben keine Probleme in der Kommunikation zwischen den Abteilungen Mechanik und Elektrik – weil keine Kommunikation stattfindet!“ So oder ähnlich ist das oft. Systems Engineering ist ein Weg, diese Sprachlosigkeit aufzulösen und eine gemeinsame Basis zu finden, auf der gearbeitet werden kann. Eine zweite Stufe ist dann das sogenannte Model Based Systems Engineering, wo das Verhalten komplexer Systeme simuliert wird.
Was sind die Voraussetzungen für die erfolgreiche Einführung von Systems Engineering?
Die erste Hürde ist die Digitalisierung aller Teile. Alle Elemente eines Produkts müssen erfasst werden – und zwar in allen ihren Facetten und Eigenschaften. Das wird heute gerne in Excel-Tabellen oder im ERP-System gemacht, weil in letzterem oft schon die entsprechenden Strukturen und eine Sachmerkmalsleiste vorhanden sind.
Wichtig ist, dass die digitale Beschreibung eines Objekts wirklich alle Eigenschaften enthält. Den Mechaniker interessieren beispielsweise an einer Lichtschranke üblicherweise nur der Bauraum und die Befestigungspunkte. Der Elektriker benötigt schon mehr Informationen wie Verkabelungsanschlüsse, Schaltplansymbole, Eigenschaften wie Reichweite, Stromaufnahme und so weiter, die Charakteristik und vieles mehr. Und nun müssen diese Daten aus verschiedenen Welten zusammengebracht werden, damit in jeder der Welten klar ist, dass man über dasselbe Teil spricht.
Es geht um eine Bibliothek, nicht im Sinne einer Normteilebibliothek, sondern im Sinn einer Sammlung aller Bauteile und Elemente, die im Unternehmen zum Einsatz kommen, mit all ihren Eigenschaften. Dieser digitale Datenbestand bildet die Basis jeder interdisziplinären Zusammenarbeit. Das verbindende Element kann dann beispielsweise die Engineeringstückliste bilden.
Und wie baut man dann darauf weiter auf, um zum Systems Engineering zu kommen?
Der nächste Schritt und die zweite Hürde ist ein sauberes PDM-System, in dem die Dokumente gesammelt werden, die das Bauteil oberhalb der beschriebenen Metaebene beschreiben: CAD-Modelle, Datenblätter und anderes. Auch diese Daten könnte man grundsätzlich ins ERP-System legen, dort stehen sie jedoch nicht für eine engere Einbindung der Authoring-Tools zur Verfügung sondern erlauben nur, diesen die Datendateien zur Verfügung zu stellen. Deshalb ist es besser, diese Ebene mit einem PDM-System im Engineeringbereich zu realisieren, idealerweise Datenbank basierend.
Oft ist gar nicht klar einzuordnen, ob eine Eigenschaft nun elektrisch oder mechanisch ist beziehungsweise wo sich eine Änderung auswirkt. Beispielsweise ändert die Elektrik-Abteilung den Typ eines Sensors, um ihre Anforderungen besser zu erfüllen. Dieser neue Sensor könnte dann ein Kabel mehr benötigen, was für den Elektriker kein größeres Problem darstellt. Der Mechaniker jedoch könnte durchaus in Situationen kommen, in denen das zusätzliche Kabel nicht mehr durch einen Durchlass oder in eine Kabelführung passt. So triggert eine Änderung auf der Elektronikseite eine Änderung des Mechanik-CAD-Modells.
Ein ähnliches Thema ist die Freigabe. Wenn die Mechanikseite fertig ist, heißt das noch lange nicht, dass sie die Konstruktion freigeben kann – wie eben gezeigt kann die noch weiterlaufende Entwicklungsarbeit der Elektriker durchaus noch Änderungen am mechanischen Modell erfordern. Beide Szenarien erfordern ein Engineering Change Management, das den Änderungsprozess an alle betroffenen Disziplinen verteilt und die Erfüllung überwacht. Dabei ist die laufende Synchronisierung dieser Prozesse notwendig, da sonst die Mechanik wartet, bis die Elektrik fertig ist, um alle Änderungen in einem Rutsch zu erledigen – und umgekehrt. Dann entsteht wiederum ein sequentieller Prozess statt einer parallelen Entwicklung. Paralleles Concurrent Engineering erfordert zwingend funktionierende Workflows für Engineering Change Management und Freigabe.
Nun sind wir immer noch nicht beim Systems Engineering, oder? Was ist die dritte Hürde?
Nun taucht das Problem der Nachvollziehbarkeit auf – warum wurde wann welche Änderung angestoßen und was sind die Auswirkungen dieser Änderung? Das ist in einfachen Produkten mit wenigen Varianten nicht weiter schwierig, wir sprechen aber heute über individualisierte, flexible Produkte mit wechselnder Funktionalität. Mit der wachsenden Bedeutung von Software für den Funktionsumfang der Maschinen lassen sich die Funktionen schnell erweitern oder ändern – doch welche Auswirkungen haben diese Änderungen?
Das führt uns zum Requirements Management. Das Requirements Management, verbunden mit dem Engineering Change Management, ermöglicht einerseits das Nachvollziehen von Änderungen und der Gründe, die diese ausgelöst haben. Zum anderen ermöglicht das Requirements Management eine schnelle, automatisierte Prüfung, ob die Anforderungen an das Produkt nach einer Änderung noch erfüllt werden.
Wenn nun alle beteiligten Disziplinen auf alle relevanten Funktionen zugreifen können und sichergestellt ist, dass immer die aktuellen Daten vorliegen, haben wir schon den ersten Schritt in Richtung Systems Engineering geschafft. Sind diese beteiligten Authoring Produkte, die von den unterschiedlichen Disziplinen genutzt werden nun auch noch objektorientiert auf einer Datenbank integriert, wird jede Änderung für alle Disziplinen sofort sichtbar und unnötige Iterationen können vermieden werden.
Heutige Produkte haben eine Unzahl von Use Cases, die bei jeder Änderung geprüft und mit den Requirements verglichen werden müssen. Auf der letzten Hannover Messe hatten wir Miele auf dem Stand. Deren Ingenieure erzählten mir, dass ein Waschmaschinen-Controller heute bereits mehr als 3.000 Use Cases und über 500 Fehlerfälle haben kann, mit steigender Tendenz. Man kann sich gut vorstellen, was passiert, wenn man einen auf den ersten Blick unbedeutenden Sensor tauscht – alle diese Use Cases müssen auf Erfüllung der Requirements durchgetestet werden. Das ist realistisch gesehen nur noch automatisiert zu schaffen, sonst ist jegliche konstruktive Freiheit verloren. Dafür brauchen wir dann Modellbasiertes System Engineering.
Das ist ein interessanter Gesichtspunkt. Blockieren nicht die immer komplexeren Verwaltungssysteme die Kreativität der Entwickler und deren Anspruch, die optimale Lösung zu finden?
Nein, im Gegenteil. Eine Lösung wie die 3DEXPERIENCE Plattform, die all die beschriebenen Prozesse unterstützt, jederzeit die richtigen Daten zur Verfügung stellt und Abläufe soweit möglich automatisiert, gibt dem Konstrukteur die Freiheit, seine Ideen umzusetzen und gleichzeitig sicher zu sein, dass er im Rahmen der Requirements und Bestimmungen bleibt. Er kann sich auf die optimale Lösung konzentrieren, statt ständig in der Angst leben zu müssen, dass seine Optimierungsidee an anderer Stelle Probleme erzeugt – das System ist in der Lage, ihn sofort auf solche Probleme hinzuweisen.
Um Systems Engineering erfolgreich anzugehen, muss schon bei der Einführung einer Engineering Plattform weiter gedacht werden als bisher häufig üblich, wenn kurzfristige Themen wie Datenmanagement gelöst werden: Ohne eine Business Plattform, die alle vorher angeführten Prozesse unterstützt, bleibt man an eben solchen Hürden hängen und wird nicht zum Systems Engineering kommen.
Herr Kraft, vielen Dank für das Gespräch!
