Pragmatisch modellieren: Interview mit Christian Tschirner
Christian Tschirner ist stellvertretender Vorsitzender der Gesellschaft für Systems Engineering (GfSE). Vor zwei Jahren gründete er die Firma Two Pillars, die das japanische Werkzeug iQuavis vertreibt und für den Maschinen- und Anlagenbau weiterentwickelt. iQUAVIS ist eine schlanke Plattform für die modellbasierte Produktentwicklung. iQuavis setzt nicht auf SysML, sondern auf einen leichtgewichtiges Datenmodell.
Am 27. April 2020 führte ich mit Christian ein Gespräch zu dem Thema Modellierung, in dem es um den Pragmatismus in der Systemmodellierung ging.
Michael Jastram: Was ist Deine Meinung zur SysML?
Christian Tschirner: EINE Meinung zur SysML kann es gar nicht geben. An sich halte ich viel von der Idee, die Leute schon vorne im Projekt zusammenzubringen und dann auch durchgängig mit einer Methode in einer Sprache zu unterstützen. Dass es die SysML geworden ist, ist durchaus gut und zeigt die Bedeutung der Aufgabe – auch wenn der Prozess nun seit 14 Jahren andauert, etwas Einheitliches daraus zu machen.
Aber es gibt eben Geburtsfehler, die man 14 Jahre später versucht mit der SysML 2.0 auszumerzen. Wir sind also mitten in der Pubertät. Wenn man dann noch mal einen Schritt zurückgeht, mit der SysML als Profil der UML, dann ist die Idee noch viel älter.
Die SysML ist nun 14 Jahre alt, und damit mitten in der Pubertät
Christian Tschirner
Die UML hatte eigentlich eine noch einfachere Ausgangslage als die SysML. Die UML wollte nur die Softwaretechniker zusammenbringen. Trotzdem hat man da schon Paradigmen eingeführt, die fast alles auf den Kopf gestellt haben. Ich erinnere mich an eine Studie zur Verbreitung der UML von 2016, in der gesagt wurde, dass die aktive Anwendung von UML bei lediglich 8% der Unternehmen der Studie stattfindet. Und der große Schocker war tatsächlich der Tag des Systems Engineering 2017, mit der Keynote von Google. Google ist ja das innovative Unternehmen schlechthin. Und da kam heraus, dass selbst die nicht modellbasiert entwickeln.
Das war für mich wirklich ein großer Schock, aber bezogen auf meine „Heimat“ Maschinenbau irgendwie auch eine Erleichterung. Es ist ja nicht nur eine Domäne vorhanden, wie in der Softwaretechnik! Und im Systems Engineering besteht der Anspruch, nicht nur technische, sondern auch nicht-technische Domänen in das Projekt einzubringen. Da ist die Aufgabe ungemein größer. Da strauchelt man immer wieder wenn man versucht, den Ansatz der Softwareentwicklung einfach zu verallgemeinern.
Und das kann in meinen Augen nur schiefgehen. Es ist immer noch der Beweis notwendig, dass es gutgeht. Nur weil SysML-Werkzeuge verfügbar sind, die sich aus der UML entwickelt haben und auch gekauft werden, heißt das noch lange nicht, dass der Ansatz erfolgreich ist. In der Basisidee ist er aber hochgradig sinnvoll. Trotzdem gibt es Schwierigkeiten. Unternehmen haben aber auch keine Zeit und keine Lust, darauf zu warten, dass die Schwierigkeiten überwunden werden. Es ist wichtig zu begreifen: Es hilft das, was heute hilft!
Wenn ich mich zu sehr damit beschäftigen muss, etwas großes einzuführen, das vielleicht nur 3%-4% meiner Belegschaft am Anfang versteht, dann kann das nicht das Allheilmittel werden. Dann darf ich nicht dogmatisch einer zu entwickelnden Sprache hinterherrennen, die im Kern gut ist, aber mir heute nicht und morgen auch noch nicht weiterhilft. Sondern ich muss etwas nehmen, was mir jetzt hilft, ein Produkt in ein bis drei Jahren auf den Markt zu bringen. Und solche Ansätze gibt es.
Unternehmen brauchen etwas, das ihnen heute hilft, DAS NÄCHSTE Produkt besser auf den Markt zu bringen. SysML erfüllt dies nicht.
Christian Tschirner
Wir haben lange bei Fraunhofer in Paderborn in meinem Forschungsbereich gar nicht auf die SysML gesetzt, da wir aus der Maschinenbauwelt kommen. Themen wie Objektorientierung, Vererbung und Ähnliches, die die Grundlage der SysML bilden, werden da meist gar nicht verstanden. Und die Unternehmen haben noch weniger Zeit, da sie direkt für einen Kunden entwickeln. Sie können sich keinen Overhead von 10% leisten – auch wenn es zur Einführung von Systems Engineering sicherlich nicht nur mutig, sondern auch sinnvoll wäre. Wir haben stattdessen starken Wert auf Methodik gelegt und diese über kleinere Softwareprototypen eingebracht. Ich finde, dass dies gerade für den Maschinen- und Anlagenbau sinnvoll ist , wo viele kunden- und auftragsgetriebene Projekte von einem vereinheitlichten Ansatz profitieren könnten.
Die Leute müssen schnell im Kundengespräch Sachen dokumentieren können. Das tun sie heute „chaotisch“ mit Stift und Zettel. Und wenn ich mit ein bisschen Methodik und ein bisschen Softwareunterstützung den technischen Vertriebler unterstütze, ein Boundary-Diagramm zu erstellen, dann ist viel mehr gewonnen als mit einer komplizierten Sprache. Da gibt es tolle Ansätze, die das unterstützen. Ich sage immer plakativ: Am Ende geht es nicht darum zu diskutieren ob der Port „rechtsherum oder linksherum drehen muss“ beim Modellieren, sondern um das, was hinten im Datenmodell abgebildet ist. Und es ist eine Sache, wie es reinkommt und eine andere wie es rauskommt aus dem Datenmodell. Und dafür brauche ich erst einmal die SysML nicht.
Es gibt tatsächlich wunderbare Bilder von DODAF 2.0 die zeigen, dass das Datenmodell im Mittelpunkt steht. Das sagen auch die ganzen Normen wie ISO 42010. Und es hat bei vielen Leuten lange gedauert, das zu verstehen. Aber es werden immer mehr!
Die Aktivitäten der SysML 2.0 sind gut und gehen in die richtige Richtung, auch wenn wir 2012 für die heute in der 2.0 adressierten Themen von der Kern-Community fast ans Kreuz genagelt wurden. Wir haben aber inzwischen unsere Wunden geleckt. Ich glaube aber, dass es langfristig eher in Richtung Austauschformat geht.
Was ist denn die Alternative zu einer Notation/Sprache, um effektiv Ergebnisse im Systems Engineering zu bekommen?
Das ist ja die Killer-Frage! Die Alternative ist die Demoktratie… also die denkbar schlechteste aller Lösungen, obwohl es (k)eine bessere gibt. Also genau das, was heute gemacht wird: Word, Excel, Powerpoint, denn das ist der Status Quo und damit immer die Alternative in der Diskussion. Denn da fühlen die Leute sich wohl. Der Mensch ist bequem, und wenn nichts überzeugt, dann bleibt man da wo man ist: „Never change a running system“. Aber offen: Die neuen Ansätze überzeugen schon, der Mensch ist wie gesagt einfach nur bequem…
Wenn ich modellbasiert Systems Engineering machen möchte, dann halte ich sehr viel von dem was Sandy Friedenthal schon vor ca. 12 Jahren irgendwo in seinem berühmten Buch gesagt hat, nämlich einen hybriden Ansatz. Vielleicht hat er es ein wenig anders gemeint, aber ich interpretiere es auch im Sinne des Change: Ich arbeite papierbasiert und bringe die Menschen an die Methodik heran, und was ich auf der Softwareseite einsetze ist fast egal, solange ich alle Daten ansteuern kann. Das kann dann auch ein proprietärer Ansatz sein, denn am Ende sind alles Entitäten und Beziehungen. Und die Digitalisierung mit Themen wie Künstlicher Intelligenz wird mir kurz über lang ohnehin helfen, informale Inhalte zu formalisieren.
Wenn wir von Entitäten und Relationen reden, dann müsste hier ein DOORS, bzw. eine moderne Alternative wie Jama ausreichend sein, oder?
Ein eindeutiges Jein. Diese Werkzeuge haben gute Ansätze, sind aber von der Usability so ausgelegt, dass sie schnell missverstanden werden, und als verbessertes Excel eingesetzt werden. Die feine Granularität von Datenelementen kann schnell anders benutzt werden. Die Gefahr der falschen Benutzung ist inzwischen so in den Köpfen verankert, dass es da in meinen Augen nicht mehr reicht. Da muss es zwei Veränderungen geben:
Zum einen brauchen wir eine eindeutige Usability. Die Leute müssen in ihren Möglichkeiten eingeschränkt werden, was sie modellieren, da sind wir wieder bei Methodik. Zum anderen der Preis. Das ist kein Plädoyer für Open Source, sondern für eine feinmodulare, leicht verständliche Struktur der Software, die ich anbiete. Pricing muss sich an den Bedüfrnissen der Kunden orientieren.
Dann müsstest Du den Ansatz Capella mit der Methode Arcadia eigentlich befürworten, oder?
So die Theorie. Vom Ansatz her ist das in Ordnung, und trotzdem: BMW, Audi und andere Herstellen bauen alle gute Autos, die am Markt platziert werden können. Das Monopol einer einzigen Software halte ich nicht für zielführend.
Capella läuft mir immer häufiger über den Weg. Es muss trotzdem viel investiert werden, wenn ich mit dem Ansatz gut vorankommen möchte. Bei einem bekannten Automobilzulieferer weiß ich, dass dort stark auf Capella gesetzt wird, was mich freut. Der Ansatz ist schon smart. Aber ich komme wieder auf den Maschinen- und Anlagenbau zurück: Wenn ich nicht investiere, komme ich auch bei Capella über das einfache Malen nur schwer hinaus. Ich brauche eine Anbindung an Methoden in der Produktentstehung, ich will eine FMEA befeuern, Issues tracken, und und und. Ein wenig investieren muss man schon, um nicht nur zu malen. Als Unternehmen des Maschinen- und Anlagenbau bin ich aber aufgeschmissen, wenn ich für jede Anpassung und jeden Wunsch mir entweder alles entwickeln lassen muss oder es von Anfang an teuer einkaufen soll.
Wenn ich in der Modellierung nicht investiere, komme ich über das einfache Malen nicht hinaus
Christian Tschirner
Wie löst Dein Produkt iQuavis dieses Dilemma?
Unser Ansatz ist „Systems Engineering machen„. Wir schaffen es, innerhalb von einem halben Tag ein Team eigenständig mit der Software arbeiten zu lassen. Sinnvoll ist – ja, klassischer Berater! – allerdings eine Prozessbegleitung. Aber: iQUAVIS kann auch ohne Prozessanpassung eingeführt werden. Ich kann die heutige Arbeitsweise abbilden und habe trotzdem diese Vorzüge des modellbasierten Systems Engineering. Ich habe den kollaborativen Aspekt mit dabei. Daher auch der Firmenname Two Pillars, die zwei Säulen eines guten Engineeringprojekts: eine gute Systemspezifikation gekoppelt mit Projektmanagement + Zusammenarbeit, wozu auch Methoden und Prozesse gehören. Wir sind eigentlich eine kleine, einfache Plattform.
Wo kommt bei iQuavis die Entwicklungsmethodik her?
Es gibt da drei Stöme. iQuavis heißt „Quality Visualization“. Die Nutzung von Daten war der eigentliche Trigger für Qualitätzwecke bei Toyota. Parallel kamen Projektmanagementthemen auf. Beide bauen auf einer Datenbasis auf. Als drittes kamen dann klassische Entwicklungsmethodiken dazu, akribisch umgesetzt. Das ganze ist stark von der japanischen Kultur geprägt: Möglichst einfach und lean. Irgendwann kamen unsere japanischen Kollegen mit den Forschungsarbeiten meiner Abteilung bei Fraunhofer in Kontakt, wo wir SE-Methodik über Jahre aus Sicht des Maschinen- und Anlagenbaus ergänzt haben. Das haben wir erst auf Projektebene im japanischen Automobilbau gemacht, und dann entschieden, das wir das lieber nach Europa holen. Unsere Arbeiten haben wir dann in das Werkzeug überführt, das wir heute auch in Deutschland weiterentwicklen.
Was werden in den nächsten fünf Jahren die größten Herausforderungen im Systems Engineering sein?
Das sind meines Erachtens drei Dinge:
Erstens eine Lifecycle-Betrachtung! Damit meine ich jetzt aber nicht zwingend nur PLM. Ich finde es faszinierend, was technologisch möglich ist, auch was bspw. an Produkten für Smart Maintenance auf den Markt kommt. Aber ich habe das Gefühl, dass es trotzdem alles wieder Inseln sind. Die beste Smart Maintenance-Lösung bringt mir nichts, wenn ich nicht nach vorne den Lebenszyklus schließe und wieder die Probleme, die ich im Feld finde auf die Anforderungen mappe und daraus einen Nutzen für die neue Produktentwicklung ziehe. Solange Word, Powerpoint und Excel die stumpfen Waffen in den Händen der kreativen und guten Ingenieure sind, habe ich ganz große Bauchschmerzen, diesen Kreis zu schließen. Das Wissen ist immer noch in den Köpfen der Leute, aber worauf sich die Änderungen auswirken, das kann keiner wissen – das sprengt die kognitiven Kapazitäten.
Das zweite ist der Sprung aus der technischen Spezifikation zur Kommunikation. Wenn ich nicht in etwas reingehe, das modellbasiert ist, kann ich keine effektive problem- und lösungsorientierte Kommunikation starten. Hieran krankt viel in der Zusammenarbeit und diese Erkenntnis hat sich bislang kaum durchgesetzt. Durch Corona könnte hier vielleicht ein Umdenken stattfinden.
Mein dritter Punkt ist aber: Bezüglich Digitalisierung und Unternehmensprozesse habe ich die Sorge, dass es zu viel Irrationalität gibt. Die Leute schauen immer nur auf das Eine Große, auf die vollkommene durchgängige digitalisierte Entwicklungsumgebung, die technologisch, prozessual, kognitiv in meinen Augen nach heutigem Stand unmöglich ist. Da ist jede kleinere Lösung scheinbar unattraktiv; aber eigentlich sinnvoller – weil sie den Menschen mitnimmt und sich ja auch entwickeln kann.
