Warum gute Ingenieure schweigen, wenn Systems Engineering im Alltag klemmt – und die Silos bleiben

Eine Geschichte über Systems Engineering, den ganz normalen Arbeitsalltag und die Ingenieursfalle

Systems Engineering im Alltag zeigt sich selten im Methodenhandbuch, sondern an einem ganz normalen Mittwochmorgen.

Nennen wir ihn Martin. Martin arbeitet seit vielen Jahren bei der AlpenWeg Caravan GmbH, einem Hersteller von Wohnwagen, die solide gebaut sind, zuverlässig funktionieren und bei ihren Kunden einen guten Namen haben.

Sein aktuelles Projekt heißt intern BackGuide und gehört zum neuen Familien-Caravan Canto 540. Die Aufgabe klingt im ersten Moment überschaubar: Der Fahrer soll seinen Caravan auf einem engen Campingplatz sicher rückwärts auf die Parzelle bringen können, während hinten die Hecke wartet, rechts der Stromkasten steht, die Kinder nach fünf Stunden Fahrt keine Geduld mehr haben und die ersten Nachbarn bereits freundlich zuschauen.

Martin gefällt diese Aufgabe, weil sie aus seiner Sicht alles enthält, was gutes Engineering ausmacht.

Das mechanische Fahrverhalten des Caravans, die Kupplung, ein Knickwinkelsensor, eine Rückfahrkamera, Ultraschallsensoren, das Steuergerät, die Warnlogik und eine Anzeige im Zugfahrzeug müssen so zusammenspielen, dass der Fahrer nicht einfach mehr Informationen bekommt, sondern mehr Sicherheit und Ruhe beim Rangieren erlebt.

Genau für solche Aufgaben hat AlpenWeg vor einem Jahr begonnen, Systems Engineering einzuführen. Die Geschäftsführung hatte erkannt, dass aus einem früher weitgehend mechanischen Produkt zunehmend ein System aus Mechanik, Elektronik, Software, Daten und Bedienerlebnis wird.

Eine neue Teamcenter-Struktur wurde vorbereitet, Schulungen fanden statt, erste Systemmodelle entstanden, und Martin war einer derjenigen, die schnell begriffen, welche Chance darin liegt. Endlich würde sichtbar werden, dass die Rückfahrhilfe weder in der Kamera noch im Sensor noch in der Halterung steckt, sondern in der Wirkung des gesamten Zusammenspiels.

Für den Dienstagstermin hat Martin deshalb sauber vorbereitet. Auf dem Bildschirm steht der Anwendungsfall: „Canto 540 sicher und ruhig rückwärts auf einen Stellplatz führen.“ Darunter hat er die Funktionskette dargestellt, von der Erfassung der Umgebung über die Erkennung des Knickwinkels und die Berechnung der Fahrsituation bis zur Anzeige für den Fahrer. Er zeigt die Kamera, die Sensorik, das Steuergerät, das Display, die mechanischen Randbedingungen und die Service-Rückmeldungen, aus denen deutlich wird, an welcher Stelle Kunden beim Rangieren bisher nervös werden.

Während Martin präsentiert, entsteht für einen Moment genau das, worauf er gehofft hatte. Jana aus der Elektronik erkennt, dass die Sensorposition nicht einfach nur eine Einbaufrage ist. Sven aus der Software versteht, warum eine Warnmeldung dem Fahrer zu früh oder zu spät erscheinen kann.

Herr Berger aus dem Produktmanagement beginnt über das Erlebnis der Familie auf dem Campingplatz zu sprechen, und die Kollegin aus dem Service ergänzt, dass Kunden vor allem beim letzten Meter das Vertrauen in die eigene Einschätzung verlieren.

Martin spürt Freude. Der Zusammenhang steht im Raum. Das neue Vorgehen funktioniert. Systems Engineering bringt die Beteiligten endlich auf dieselbe Wirklichkeit.

Am Ende bittet der Projektleiter darum, die Darstellung im Teamcenter-Projektraum abzulegen, damit beim nächsten Meilenstein darauf aufgebaut werden kann. Martin macht das direkt nach dem Termin, versieht die Dokumente mit den passenden Bezeichnungen, stellt die Beziehungen zwischen Anwendungsfall, Funktionen und Komponenten her und geht am Abend mit dem guten Gefühl nach Hause, einen wirklichen Schritt geschafft zu haben.

Am Mittwochmorgen meldet der Kameralieferant, dass die vorgesehene Kamera in der geplanten Ausführung erst deutlich später verfügbar sein wird. Eine alternative Baureihe kann kurzfristig geliefert werden, hat allerdings ein anderes Gehäuse, einen leicht veränderten Sichtwinkel und einen anderen Kabelabgang.

In der Fertigung wartet bereits der Prototyp, der Einkauf braucht eine Entscheidung, der Projektleiter möchte bis zum Nachmittag eine belastbare Aussage und aus einem anderen Fahrzeugprogramm kommt gleichzeitig eine dringende Änderungsanfrage herein.

Martin öffnet die Einbaudaten der neuen Kamera und sieht sofort, dass die bisherige Aufnahme an der Deichsel angepasst werden muss. Er weiß auch, dass ein veränderter Sichtwinkel eigentlich zurück in den Zusammenhang von Kamerabild, Fahrerwahrnehmung, Warnlogik und Rangiererlebnis gehört. Genau dafür hatten sie am Vortag das Systembild aufgebaut.

Für einen Moment überlegt er, die Runde wieder zusammenzuholen. Doch Jana steckt in der Absicherung eines Steuergeräts, Sven muss einen Softwarestand für einen anderen Termin fertigbekommen, der Einkauf drängt auf die Bestellung und der Projektleiter braucht etwas, das er in seiner Statusrunde vertreten kann. Martin kennt diese Situation gut genug, um zu wissen, wie sie ausgeht, sobald er jetzt einen weiteren Abstimmungstermin anregt.

Alle werden zustimmen, dass der Zusammenhang wichtig ist, und gleichzeitig wird jeder mit Blick auf seinen Termin fragen, ob die Halterung für den Prototyp rechtzeitig fertig wird.

Also beginnt Martin zu konstruieren.

Er modelliert eine neue Kamerahalterung, prüft den Schwenkbereich der Deichsel, verändert die Befestigungspunkte, führt das Kabel sauber aus dem Kollisionsraum und entdeckt dabei sogar eine Lösung, die stabiler und montagefreundlicher wirkt als die bisherige Variante. Nach einer guten Stunde sieht die neue Aufnahme wirklich gut aus. Sie ist sauber, nachvollziehbar und technisch eine Verbesserung.

Martin lehnt sich kurz zurück und empfindet genau jene Zufriedenheit, die ihn an seinem Beruf immer begeistert hat. Ein Problem hatte sich vor ihm aufgebaut, er hat es verstanden und etwas geschaffen, das sichtbar besser funktioniert.

Die offene Diskussion über Wirkzusammenhänge, Kundenwahrnehmung und neue Arbeitsweisen war wichtig, doch diese Halterung ist jetzt real. Sie kann gefertigt, geprüft und eingesetzt werden. Sie bringt das Projekt voran.

Er legt die neue Variante im Projektbereich ab, sendet dem Einkauf eine Rückmeldung und informiert den Projektleiter, dass die mechanische Integration der Alternativkamera lösbar ist.

Der Projektleiter ist erleichtert. Der Einkauf kann weiterarbeiten. Die Fertigung bekommt einen Stand. Martin hat geliefert.

Nur BackGuide ist an diesem Nachmittag wieder ein kleines Stück zurück in seine Einzelteile gefallen.

Die Kamera ist jetzt untergebracht. Die Sensorik wird separat weiterbearbeitet. Die Software wartet auf ihre Eingangsdaten.

Das Produktmanagement formuliert inzwischen den Ausstattungsumfang für den Vertrieb.

Der Service sammelt weitere Erfahrungen aus Kundengesprächen. Teamcenter enthält das Systembild, die Beziehungen und die Dokumentation des guten Dienstagstermins, während der tatsächliche Projektalltag längst wieder in den vertrauten Bahnen läuft, die jeder Beteiligte unter Druck hervorragend beherrscht.

Systems Engineering im Alltag: Als der Zusammenhang wieder verschwindet

In der nächsten Besprechung fragt niemand offen, ob die alternative Kamera das Erlebnis der Familie beim Rückwärtsfahren verändert.

Martin spricht es ebenfalls kaum noch an, weil er seinen Teil erklärt, dargestellt und sauber abgelegt hat. Er hat gezeigt, wie der Zusammenhang gedacht werden müsste. Die Methode war vorhanden, die Plattform war vorhanden, die richtigen Menschen waren sogar für einen Augenblick gemeinsam am selben System.

Als dieser gemeinsame Blick im Alltag wieder stecken blieb, hat Martin das getan, was seiner Natur entspricht: Er ist zu der Aufgabe zurückgekehrt, die er mit seinem Können wirksam lösen konnte.

Das ist die Ingenieursfalle.

Sie entsteht selten aus Unfähigkeit oder Widerstand. Sie entsteht aus der Freude daran, etwas sauber zu lösen, aus der Verantwortung für Termine, aus der Erfahrung, mit der ein Ingenieur auch unter Druck noch etwas Tragfähiges zustande bringt.

Sie entsteht, wenn die Zukunft wieder wie eine technische Aufgabe behandelt wird, die sich nur präzise genug vordenken, modellieren, absichern und anschließend implementieren lässt.

Systems Engineering macht diese Falle besonders deutlich, weil die Methode genau den Zusammenhang sichtbar machen möchte, der im Alltag so leicht wieder verloren geht.

Eine Plattform wie Teamcenter oder Windchill kann Beziehungen speichern, Prozesse führen und Informationen organisieren. Ein KI-Agent kann Varianten vergleichen, Dokumente auswerten und Zusammenhänge schneller verdichten. All das kann wertvoll werden.

Doch sobald die Menschen im Unternehmen ihre Richtung noch immer aus derselben vertrauten Denkbewegung heraus suchen, organisiert das neue Werkzeug vor allem das, was bereits vorher gelaufen ist. Der Zusammenhang liegt dann in der Plattform, während die Menschen unter Druck wieder in ihren greifbaren Aufgaben weiterarbeiten.

Das System ist vorhanden, und die alte Arbeitsweise lebt weiter.

Martin braucht in diesem Moment keine weitere Präsentation darüber, warum Systems Engineering richtig wäre. Er hat das längst verstanden. Seine Kollegen brauchen auch keine weitere Erklärung der Plattform. Sie wissen ebenfalls, dass sie für das Unternehmen wichtig ist.

Was fehlt, lässt sich am Besprechungstisch kaum hervorbringen, weil dort jeder wieder in der Rolle sitzt, in der er seine Verantwortung, seinen Termin und seinen lösbaren Anteil vertritt. Die gewohnte Richtung wird dort mit jedem guten Argument noch besser begründet.

Der Wechsel beginnt erst, wenn die Menschen aus dieser Ordnung herauskommen.

Bei AlpenWeg könnte der Canto 540 dafür wieder im Mittelpunkt stehen, real in der Halle oder als digitales Modell im DMU-Gespräch.

Martin, Jana, Sven, der Service, das Produktmanagement und die Führung sehen gemeinsam auf BackGuide und auf die Situation, für die dieses System einmal Bedeutung bekommen soll. Danach bleiben sie nicht am Tisch sitzen, um den Zusammenhang noch präziser zu zerreden.

Sie gehen.

Im Gehen verändert sich der Zugang. Martin muss seinen Kamerahalter nicht verteidigen, Jana ihren Sensor nicht absichern und Sven seine Softwarelogik nicht sofort begründen.

Während sie sich bewegen, kann aus der technischen Aufgabe wieder die Szene werden, um die es einmal ging: eine Familie, die mit ihrem Caravan ankommt, rückwärts in die Parzelle fährt und erleben soll, dass dieses Manöver ruhig, verständlich und sicher wird.

Aus dieser Bewegung kann ein Zukunftsbild entstehen, das stärker trägt als eine weitere Liste von Anforderungen.

Die Beteiligten erleben gemeinsam, wofür BackGuide wirken soll, und kehren mit dieser Richtung zurück in ihr Systemmodell, ihre Plattform, ihre Prozesse und ihre Entscheidungen im Alltag.

Dann bekommt Teamcenter seinen Sinn. Dann kann ein Systemmodell helfen. Dann kann eine KI verdichten und unterstützen. Dann wird aus dem Werkzeug ein Diener einer Richtung, die bereits von den Menschen getragen wird.

Systemwirkung beginnt deshalb vor der Einführung der nächsten Methode, vor dem Vertrauen in die nächste Plattform und vor der Idee, Zukunft zuerst vollständig planen zu müssen.

Sie beginnt dort, wo ein Unternehmen erleben kann, dass sein vertrautes Engineering bei der Neuausrichtung selbst zum festgefahrenen Medium geworden ist.

Die Ingenieursfalle lautet: Wir glauben, wir müssten Zukunft noch genauer engineeren.

Der Ausweg beginnt in Bewegung.

Und wenn die Menschen danach gemeinsam wieder an ihr Produkt, ihr Systemmodell und ihren Arbeitsalltag zurückkehren, kann aus exzellentem Engineering erneut etwas entstehen, das auch in einer veränderten Welt trägt.

Herzlich willkommen in der Ingenieursfalle.

Und herzlich willkommen in der Systemwirkung.