Episode 227 Innovation neu beleben, wie Systems Engineering deutschen Unternehmen zu neuer Exzellenz verhilft. Music. Herzlich willkommen beim Zukunftsarchitekten, der Systems Engineering Podcast für Machende und Entscheidende. Am Mikrofon ist wieder Björn Schorre. Als Systemingenieur gebe ich dir Tipps und Impulse, damit du dein Projekt zum Erfolg führen kannst.
So wirst du in der Episode heute erfahren, warum du komplizierte Inhalte transparenter vermitteln sollst und wie die Innovationskraft deines Unternehmens durch Vereinfachung der Systems Engineering Methoden wächst. Heute darf ich einen ganz besonderen Menschen hier bei mir im Podcast begrüßen. Er hat an der Technischen Universität Darmstadt studiert, hat da sein Master of Science gemacht und zwar in Mechanical Process Engineering.
Danach hat er gearbeitet bei verschiedenen Unternehmen als Model-Based Systems Engineering Consultant, später dann auch als Systems Engineer mit der Aufgabe, Funktionen zu entwickeln und auszuliefern. Genau, und ja, dann hat er sich selbstständig gemacht, hat eine Firma gegründet und polarisiert damit im Moment die Systems Engineering Welt. In diesem Sinne begrüße ich hier ganz herzlich im Podcast Robert Hämisch, hallo. Hallo. Ja, hallo Björn. Vielen Dank für die Einladung. Ich freue mich,
das hier heute mit dir zu machen. Ja, freue ich mich auch. Schön, dass du zugesagt hast. Sag, habe ich irgendwas vergessen, was deinen Werdegang vielleicht besser beschreibt oder ausschmückt? Vielleicht eine, ja, ich würde gar nicht sagen Kleinigkeit, aber ich durfte neben meinen Rollen im Systems Engineering auch mal eine Zeit lang wirklich als Coder arbeiten, also auf der Softwareentwicklungsseite.
Und daraus ist bei mir auch sozusagen die Passion entstanden, die Welten Systems Engineering, Software Engineering und die ganzen anderen Domänen-Disziplinen besser miteinander zu verzahnen, besseres Verständnis zu schaffen. Und das war auch der Grund für die Gründung von Spicy. Ja, genau. Spicy SE ist eine Firma, die du gegründet hast und vielleicht kommen wir da auch noch im Laufe des Gesprächs mal drauf.
Ja, ich sagte es gerade schon, du bist dabei, dich auch so ein bisschen zu polarisieren gerade. Auf LinkedIn gehen deine Posts ziemlich ab, was du da veröffentlicht. Und deswegen habe ich gedacht, da muss ich dich mal was fragen zu. Und zwar die erste Frage, die ich mir dann da aufgestellt habe. Warum ist deiner Meinung nach das aktuelle Vorgehen im Systems Engineering oder rund um diese Tätigkeiten für Unternehmen ein Problem?
Was stellst du dir darunter vor? Wenn ich da mal, ich sage mal, makroökonomisch im Großen anfange, dann sehen wir ja gerade aktuell die Nachrichten der Autozulieferindustrie ganz schön unter Druck. Es werden Kosten gespart, es werden Stellen gestrichen, bis hin zu tatsächlich Leute entlassen. Das heißt, wir merken vor allen Dingen, aus Fernost kommt Innovationsdruck, würde ich es nennen. Innovationsdruck, Preisdruck, wir müssen schneller werden. Und das stellt natürlich alles auf die Probe.
Alle Geschäftsprozesse, alle Abteilungen, Organisationsschnitte, Hierarchie-Ebenen und so weiter wird ganz viel durcheinandergewürfelt werden und natürlich mein Bereich, das Systems-Software-Engineering, ist davon natürlich betroffen. Und da ist natürlich wichtig, sich zu fragen, was wollen wir denn mit Systems Engineering erreichen und tun wir das.
Erreichen wir das mit minimalem Aufwand? Können wir quasi die Welt des Systems Engineering, wie sie leben, können wir sie verteidigen durch diese Phase des externen Drucks? Also du bist, prinzipiell bist du ja Systems Engineer. Du sagst, das Ganze muss irgendwo zusammengebracht werden, diese ganzen Fachbereiche oder Domänen, je nachdem, wie man das bezeichnet.
Du sagst aber, das ist eine große Herausforderung, das zu machen und die Möglichkeiten, die uns da aktuell gegeben sind, die sind nicht die optimalsten. Ich würde das sehen, vielleicht kann man sich das so mit dem klassischen Pareto 80-20 vorstellen. Wir haben im Systems Engineering natürlich tolle Möglichkeiten, Dinge zu tun, mit Sprachen, mit Methodiken, mit Tools.
Wir haben aber die Gefahr, dass wir ganz, ganz schnell ins Expertentum abgleiten, wo uns dann viele Domänen-Experten, die uns dahin nicht folgen wollen, wo wir die dann verlieren. Und ich glaube persönlich, für eine gemeinschaftliche Entwicklung von komplexen Systemen ist es erstmal wichtig, dass wir alle den gleichen Marktplatz haben, auf dem wir uns befinden und auf dem wir offen unsere Ideen austauschen können.
Und hier muss aus meiner Sicht Systems Engineering keine Hürde schaffen durch das Nutzen von komplexen Ansätzen, sondern die Hürden der Kommunikation reduzieren. Ähm, was meinst du, kannst du konkret sagen, was du damit meinst, die Experten können uns nicht folgen, also uns, meinst du jetzt die Systems Engineers, die dann daherkommen und sagen, wir müssen ein bisschen was anderes machen oder wir müssen dies oder jenes nutzen. Genau.
Also ich werde ganz konkret aus der Praxis, wenn ich in die System A gehe und ich habe, Achtung, jetzt ist was für die Systems Engineering Nerds, ich habe die Komposition und die Aggregation, das ist einmal ein Diamant, der ist leer und einmal ein Diamant, der ist gefüllt. Ja, genau. Das heißt, wenn ich jetzt als jemand, der noch keine System L-Erfahrung hat, noch keine Schulung genießen durfte und so weiter, wenn ich auf so ein Diagramm schaue, dann sehe ich, hier ist Wissen.
Hier ist Wissen versteckt, weil es sind zwei verschiedene Diamanten. Ich weiß aber im ersten Schritt, ich kann ja so ein System L-Diagramm auch ohne Ausbildung erstmal grob begreifen. Das ist ja das Schöne. Aber dann fehlt mir natürlich als Ingenieur genau das Wissen, was ich brauche und merke jetzt, oh, hier ist mehr drin, als ich sehe. Ich muss mich hier einarbeiten, weil ich bin ja Ingenieur und ich will ja präzise mitreden können.
Und dann geht es ganz schnell, wenn ich sage, oh, okay, hier wird in einer Sprache gesprochen, die ich nicht spreche, als Domänen verantwortlicher. Ich ziehe mich hier zurück aus diesem Feld. Auf dieser Ebene sollen andere sprechen. Und das finde ich schade. Oder beziehungsweise, hier wieder beim 80-20, es gibt sicherlich, Herausforderungen und Anwendungen, wo wir die Präzision einer SysML sehr gewinnbringend nutzen können.
Aber es gibt eben auch den Großteil der Kommunikation in komplexen, vielleicht auch über Content verteilten Teams, wo wir sagen, hier ist ein gegenseitiges erstmal Grundverständnis schaffen, erstmal ein ganz basic Fundament zu schaffen, wichtiger. Genau. Ah, das ist ein super Ansatz, den ich ja prinzipiell jetzt auch erstmal mal gut finde.
Das ist nämlich das, was wir auch damals bei Vargo mit den Kollegen zusammen herausgefunden haben, dass wir andere Menschen im Unternehmen mit, genau wie du es gesagt hast, SysML eher verschreckt haben. Und dann haben wir gesagt, lass uns doch da irgendwie pragmatische Ansätze wählen und haben die dann versucht, damit besser abzuholen. Genau.
Ähm, Also das ist jetzt das konkrete Vorgehen, wo du sagst, das ist das, was für Unternehmen, wenn sie Systems Engineering einführen oder einführen sollen oder wollen, je nachdem, was für die Unternehmen ein Problem ist. Weil da kommt jemand daher und sagt, ihr müsst jetzt dein Beispiel SysML benutzen und dann bringst du, anstatt dass du die Leute zusammenbringst, bringst du sie auseinander.
Genau, die Grundfrage muss hier sein, was ist eigentlich unser Problem und das klingt jetzt natürlich so banal, aber was ist unser Problem und lösen wir das? Dann möchte ich ein Beispiel machen, ich hatte einen Austausch mit jemandem, der verantwortlich war für eine extrem große Industrieanlage, also reden wir über Milliarden-Invests, staatlich gefördert und.
Er erklärte dann, dass es da ganz viele verschiedene Energiekonsumenten, Stromkonsumenten gibt in seinen Prozessen, um das Produkt, um das es ging, von A nach B zu bringen. Und ja, dann ging es darum, wie man das modelliert. Und dann fing er an und sagte, ja, aber jetzt wäre es doch toll, wenn jetzt hier das Tool automatisch die ganzen Stromverbräuche aufsummieren würde und das parametrisch und so weiter.
Und ja, das wäre toll, auf jeden Fall, gar keine Frage, das wäre super, aber weißt du denn überhaupt, welche Stromverbraucher du hast und haben die dir alle tagesaktuell ihre aktuelle Stromverbrauchsschätzung gegeben und in dein Modell geliefert, ohne dass du sie fragen musstest? Und da war die Antwort, nee, ich bin mir nicht mal hundertprozentig sicher, dass ich weiß, ob ich alle in meinem Modell habe und ich bin mir sehr sicher, dass die Zahlen outdated sind.
Und da denke ich mir wieder Pareto-mäßig, ja, das wäre cool, das würde sich automatisch summieren. Aber wenn ich weiß, ich habe diese 17 Verbraucher und die geben mir tagesaktuell ihre Schätzung in das Modell, weil sie so eine niedrige Hürde haben, dass sie das einfach selbstständig machen können ohne große Zusatzausbildung, dann die 17 Zahlen in den Taschenrechner zu tippen oder in Excel, das kriege ich dann auch noch hin.
Aber hier wieder das Fundament, die Basis ist doch erstmal, dass alle meine Stakeholder, alle meine Beteiligten es schaffen, ihr Wissen zu mir zu tragen. Das ist aus meiner Sicht die Grundvoraussetzung und in dem Fall hier viel wichtiger als das super coole, kann ich mich ja auch für begeistern, da bin ich ja auch nicht fremd von, als das super coole parametrische Diagramm. Da ist halt genau die Frage, wieder komme ich zum Anfang zurück.
Was haben wir für ein Problem hier? Was wollen wir? Und ist das, was wir gerade vorhaben, ist das wirklich die Lösung? Oder beziehungsweise, lass mal was versuchen und im halben Jahr gucken, haben wir das Problem denn eigentlich gelöst? So eine klassische Hypothese-Experimentschleife, die wir in der Industrie mit allen unseren Produkten ja machen, muss ich sagen, vermisse ich hier und da ein bisschen bei der Einführung von Systems Engineering. Okay, ja.
Ja, damit haben wir ja dann auch eine zunehmende Komplexität in unseren Produkten. Also das, was du jetzt gerade gesagt hast, bleib mal bei diesem Beispiel, du hast 17 oder so eine unbekannte Anzahl von Energieverbrauchern, und der Wunsch ist jetzt, das automatisch zu ermitteln, die Energieverbräuche, die dort anfallen. Der Wunsch ist, wie du es gesagt hast, definitiv da, das dann zusammenzuführen.
Die Frage ist ja nur, wie kann man das dann machen? Und da entsteht ja eine Kompliziertheit, vielleicht sogar eine Komplexität, weil die das alles dann unterschiedlich übermitteln, ja, übermitteln wollen. Kann Systems Engineering denn da irgendwie helfen, dass diese Probleme bewältigt werden? Und wenn ja, wie? Ich denke ja und ich würde gerne da noch ein bisschen präzisieren. Es muss nicht automatisiert laufen.
Im ersten Schritt wieder, auch hier wie bei Pareto. Wichtig ist, dass wenn ich jetzt Gesamtsystem verantwortlich bin und ich bleibe bei dieser großen Industrieanlage. Und. Die Verantwortlichkeit von so einem kleinen, kleineren Teilsystem muss aber ja erstmal auf dem Schirm haben, okay, für irgendwen anders ist es wichtig, dass ich meinen Energieverbrauch, wenn ich merke, meine Schätzung verändert sich, dass ich die in ein Gesamtmodell liefere. Das ist Nummer eins, das muss verstanden sein.
Und Nummer zwei ist, wenn ich auf die Idee komme, dass ich merke, ach, meine Schätzung hat sich verändert, ich sollte mal ein Update geben, dass ich das auch innerhalb von, ich sag mal, Minuten hinbekomme. Denn auch hier, aus meiner Sicht ist hier wieder wichtig, dass jemand, der Gesamtsystem verantwortlich ist, der möchte ja nicht immer alle abtelefonieren oder alle manuell irgendwie fragen müssen, sondern wir wollen ja so ein bisschen ein Push-Prinzip bekommen.
Ja, genau. Und was kann Systems Engineering hier tun? Systems Engineering kann ein Gesamtsystemmodell schaffen, aus meiner Sicht, in dem alle Subsystem-Eigner und Eignerinnen drin sind und wissen, aha, hier sind meine Interfaces, nach außen, nach oben, nach wo auch immer hin, hier weiß ich, was ich bekomme und wen ich versorgen muss. Und so eine Welt, sage ich mal, aufzubauen, eine Kommunikationswelt aufzubauen, wäre für mich erstmal das Fundament.
Ja gibt natürlich wie gesagt man kann das ist eine tolle tolle dinge bauen aber ich habe das gefühl persönlich wenn erst mal das fundament steht dann kann ich da weitermachen das fundament ist für mich die kommunikation zu erleichtern das verständnis dafür zu schaffen welches wissen brauche ich von wem wann warum das erst mal zu ermöglichen ja du hast gerade was ganz also ganz zu Anfang von deiner Erläuterung gerade gesagt, es ist nicht notwendig, dass zu Anfang gleich alles automatisiert läuft.
Und ich muss ja erstmal das verstehen, was ich da überhaupt tun möchte. Egal wo ich bin, entweder bin ich in der Entwicklung tätig und muss da verstehen, wie die Entwicklung funktioniert oder ich habe ein System oder eine Systemintegration und ich muss da verstehen, wie die miteinander kommunizieren. Und sobald ich das verstanden habe, dann kann ich auch Automatisierungen, ich sage jetzt mal, obendrauf setzen und das weiter vereinfachen.
Ich finde, das ist schon ein ganz guter Ansatz, einfach mal das Ganze zu verstehen und diese Basis erstmal zu schaffen. Gibt es aus deiner Sicht irgendwie spezifische Methoden oder Werkzeuge, die für diese, die Bewältigung dieser Herausforderungen angewendet werden können? Ja, das ist natürlich, gut, du fragst mich nach Tools und ich habe eine Toolfirma gegründet, das ist jetzt schwer, jetzt hier nicht in einen Werbemonolog zu starten.
Ja, aber vielleicht hast du ja auch irgendwie Methoden, wo du sagst, die haben wir als Basis genommen und da drin verarbeitet. Da möchte ich auch so ein, ja, das ist auch was, wo ich auf LinkedIn, du hattest es angesprochen, ich möchte nicht mit Absicht polarisieren. Ich gebe meine Meinung preis und da ergeben sich schöne, lebhafte Diskussionen, die ich auch sehr, sehr schätze.
Und eine diskussion ist die wie komme ich zum systems engineering und hier habe ich eine erstaunliche feststellung gemacht viele die im system engineering sind kommen über die die methode über die prozesse dann über die tools und dann zum work product das sind die die sich quasi die natürliches interesse daran hegen sage ich mal mal. Ähm.
Die anderen, sage ich jetzt mal ganz fies oder ganz platt, die das Systems Engineering quasi dann erst lernen, wenn sie in einer Company sind und sie sind jetzt, was weiß ich, Simulationsingenieure oder gucken, wie sie den Chip auf die Platine so kriegen, dass die Kühlung gut läuft, haben so ein Expertenwissen, die dann mit dem Systems Engineering, wo man so möchte, konfrontiert werden.
Die finden ihren einstieg meist über hey mach mal was in dem werkzeug was wir dir geben ja das ist für ich würde fast sagen die mehrheit der menschen die mit system engineering konfrontiert werden die dort mitarbeiten sollen ist das der einstieg das heißt um jetzt jetzt bin ich wie so ein politiker und rede an deiner frage vorbei bevor ich auf die methode schiele ist es aus meiner sicht erstmal mal wichtig dann diesen einstieg und das ist meistens das tool deswegen habe ich auch nur
tool firma mitbegründet das muss erst mal attraktiv sein weil wenn ich an dieser stelle schon eine hürde baue und es so kompliziert machen dass die leute sagen er kommt gehen wir weg soll jemand anders machen dann habe ich nichts gewonnen wie gesagt aus meiner sicht ist, für viele viele menschen in organisationen gerade ganz ganz spitze nischen experten ist das tool der Einstieg und nicht die Methode.
Das heißt, es muss erstmal das Tool schön wirken, dass ich überhaupt das Interesse bekomme, dass ich was über Methoden erzählen darf und dass ich was über Methoden aufschlauen darf und in Prozesse integrieren darf und so weiter. Ich glaube aber, bevor du dann in so ein Tool einsteigst, du hast ja meistens auch schon irgendwelche anderen Tools, gerade wenn du hast ja auch Softwareentwicklung gemacht, hast du ja gesagt, und dann bist du ja mit irgendwelchen.
Programmierumgebungen unterwegs, die ja der meistens auch keine Diagramme oder solche Modelle unterstützen, sondern das hat man sich dann doch früher auch üblicherweise über Visio oder Papier oder Flipchart oder Whiteboard erarbeitet. Genau. Und ich glaube, darüber kommst du dann auch von der Softwareentwicklung in Richtung, hey, wir müssen auch mal mit anderen sprechen, weil unsere Software ist nicht das Einzige, was hier in dem System läuft.
Läuft und ohne andere Teile, wie zum Beispiel Elektronik, wird die gar nicht wirklich funktionieren. Gerade wenn ich dann, also ich komme halt auch aus dem Embedded-Bereich, ohne Elektronik bist du da aufgeschmissen. Also dann hast du da zwar irgendwas auf einer CD oder sowas, aber du brauchst natürlich die anderen Dinge auch dazu.
Deswegen bin ich ja auch zum Systems Engineering gekommen, weil ich gesehen habe, da sind auch Verbindungen zu anderen Teilen, die wir mitentwickeln oder die mitentwickelt werden müssen. Also du hast gesagt, Werkzeug, darüber den Einstieg zu finden, und da habe ich mir jetzt gerade so ein bisschen den Kopf gemacht, das ist so ähnlich wie der Akkuschrauber, den ich ja bei mir rumstehen habe. Also da weiß ich auch, okay, damit kann ich eine Schraube irgendwo in der Wand machen.
Und das ist dann schon, relativ einfach, weil ich den kenne, weil ich den auch relativ schnell dann benutzen kann und wenn ich den dann mal benutzt habe, dann kommen ja vielleicht auch irgendwann weitere Ideen dazu wie ich den, wie ich mir das Leben mit diesem Werkzeug vielleicht noch vereinfachen kann. Oder ob ich darüber vielleicht noch irgendwelche anderen Daten ermittle. Ja, oder vielleicht auch in die Welt des Bastelns und Bauens.
Wenn es dir Spaß gemacht hat, das Bild aufzuhängen und die Schraube in die Wand zu treiben, dann kommst du vielleicht von da, um jetzt bei deiner Metapher zu bleiben, von da auf die Idee, lass doch mal noch eine Säge kaufen und vielleicht ein Vogelhäuschen bauen. Das hat das Spaß gemacht. Und so zieht sich das dann rein. Weil das Erlebnis mit dem Akkuschrauber hat Spaß gemacht.
Wenn der Akkuschrauber mir irgendwie Probleme macht und wenn ich nicht verstehe, wo der Knopf ist, damit er endlich schraubt, dann habe ich keinen Spaß. Dann kriege ich mit Mühe und Not mein eines Bild an die Wand und dann gehe ich wieder. Genau, dann lege ich den noch wieder weg und dann war es das. Dann mache ich dann doch wieder das, was ich vorher gemacht habe. Oder das, was mir einfacher von der Hand geht.
Ja. Ja, okay, das ist natürlich auch ein Ansatz, kann ich auch gut verstehen, so wie du das dann argumentierst, dass man mit diesen Werkzeugen dann mehr Motivation entwickelt, sich um solche komplizierteren oder auch komplexeren Probleme zu kümmern. Du hattest vorhin von den Zusammenhängen gesprochen. Als ich hier im Vorhinein über unseren Podcast nachgedacht habe, musste ich an ein Mietauto denken, was ich neulich fuhr.
Und wenn man dort auf den Sprachsteuerungsknopf gedrückt hat, ging die Klimaanlage runter. Und da dachte ich, Mensch, das ist ja cool. Das ist ja mal ein richtig gutes Beispiel für angewandtes Systems Engineering. Jetzt muss ja jemand, der die Spracherkennungssoftware geschrieben hat, irgendwie eine Traceability gefunden haben zu denjenigen, die die Klimaanlage regeln. Das ist ja ganz toll. Und das zeigt, glaube ich, wie komplex Dinge doch zusammenhängen können.
Und du hattest vorhin davon gesprochen, dass auch Software kann natürlich auf dem Schirm haben, dass es nicht nur, wenn man so schön sagt, Software gibt, sondern auch andere Sachen, das heißt wir müssen es schaffen, dass jede und jeder, Expertin und Experte in ihren Feldern sieht, was beeinflusse ich noch, wie sind meine Interfaces, wie sind meine Kontexte und das nach Möglichkeit wieder ohne Hürde, ohne zweiwöchige Tool-Schulung, um in irgendwelche Traceability-Matrizen
und sonst was reinzukommen, sondern in der Einfachheit eines Confluence und eines Visio und eines PowerPoint aus meiner Sicht, sollte zu verstehen sein, welche anderen Gewerke interface ich denn, was tausche ich denn aus, wie bette ich mich denn in ein größeres Ganzes ein.
Und das muss aus meiner Sicht auch wieder eins von diesen von diesen foundation basis zielen von systems engineering sein verständlich zu machen mir gehört diese systemgrenze und an dieser systemgrenze hängen diese interfaces wir beeinflussen mit dieser systemgrenze diese und jene andere systemgrenze und das sollte ich noch möglichkeit mit drei klicks visualisiert sehen ohne große schulung und ähnliches ja das.
Ich weiß jetzt nicht, in wie tief du jetzt gedanklich da drin warst, aber ich stelle mir das so vor, man muss als Projektteam oder als Team in einem Unternehmen, was jetzt für ein System verantwortlich ist, am Ende des Tages doch gemeinsam das Verständnis aufgebaut haben, was ist das große Ganze, was wir jetzt mit unserem System erreichen wollen.
Und dann kann sich, glaube ich, auch jeder herausnehmen oder über Gespräche herausbekommen, was ist denn mein Teil, den ich dazu beisteuern möchte oder muss. Ich glaube, das ist ganz wichtig, das dann zu erkennen und das gemeinsam herauszuarbeiten. Und dann kann ein schöner Flow entstehen, glaube ich. Weil dann gemeinsam gemeinsam ist hier ein super gutes Stichwort. Ja, ich glaube, alle Systems Engineers kennen das.
Wenn ein Manager klopft und sagt Hey, ich brauche mal dies und jenes im entsprechenden Modellierungs Werkzeug sich das anguckt und sagt Nee, das versteht meine Audience nicht. Das bitte vereinfacht im PowerPoint. Malen wir das mal als Folie.
Ich brauche es heute Nachmittag um vier. ich glaube so oder ähnliche anfrage hat dann doch jeder schon mal bekommen und das ist genau dieses gemeinsam können wir nicht ein verständnis schaffen was von absolut konzeptuell man wirft den top managern immer vor dass sie nur powerpoints verstehen fiesermaßen können wir nicht auf so einer Basis was Gemeinsames schaffen.
Weil das Problem ist nämlich, wenn wir es nicht schaffen und wenn es irgendwen gibt, der sagt, ah, nee, ich traue mich hier nicht rein, in dieses Modellierungswerkzeug, ich sehe, hier ist was modelliert. Aber ich habe hier eine Bar, da sind 700 Buttons und ich kann ganz viel machen und ganz viele Elemente reinfügen und zusammenfügen. Ich traue mich nicht, ich kenne mich nicht aus, ich weiß es nicht,
dann gehe ich woanders hin. Dann gehe ich in den PowerPoint und skizziere es erstmal in den PowerPoint, damit ich dann darüber reden kann mit meiner Peergroup. Und schon, schwuppsiwupps, habe ich eine second source of truth, wenn man so will, geschaffen. Schon habe ich eine Wissensquelle geschaffen, die nicht zentralisiert ist, was ich ja eigentlich wollte. Und das geht ganz, ganz schnell. Sobald sich nicht wohlgefühlt wird in der Welt der Methoden,
Sprachen, Tools, gibt es eine andere. Ja, genau. Und da sehe ich auch wirklich, so wie du es sagst, eine große Gefahr, wenn ich gleich von Anfang an in irgendwelche anderen elektronischen Tools gehe, die mir vermeintlich diese Probleme oder dieses Handling lösen. Generell finde ich das mega wichtig, dass man ein gemeinsames Verständnis im Projektteam erarbeitet.
Ich empfehle dazu immer ganz gerne Whiteboards oder Flipcharts, weil da kann man wunderbar mit irgendwelchen Post-its drauf arbeiten, da kann man auch nochmal was wegwischen. Flipchart jetzt nicht, aber auf dem Whiteboard und dann kann man das nochmal abändern und dieses gemeinsame Verständnis aus den Köpfen der beteiligten Personen herausholen.
Und wenn das gemacht ist, dann ist die nächste Empfehlung, und jetzt nehmt euch ein Tool und kippt das dann da rein, damit es dann halt auch zentral und, wie du sagst, als Single Source of Truth genutzt werden kann. Von dort aus gehen wir jetzt weiter vor und machen weitere Schritte, Modellierung, Anforderungsableitung, was auch immer. Wenn du jetzt Unternehmen, empfehlen würdest, die Systems Engineering einführen wollen, was wären denn da die wichtigsten Schritte?
Also aus meiner Sicht ist der erste Schritt ist, warum? Und die Antwort, ja, wir bringen was in Serie und jetzt haben wir da diese Norm, die führt meistens, klar, ich erfülle dann mein Assessment, aber was ich dann habe, ist so ein Klassiker, Projektbudget 10 Millionen, oh wir müssen Ace Buys machen, 12 Millionen. Auf einmal ist Systems Engineering keine Erleichterung, keine Beschleunigung, sondern auf einmal ist es ein Kostenfaktor und so sollte es ja eigentlich nicht sein.
Das heißt, was ich einem Unternehmen raten würde, was Systems Engineering macht, ist zum einen die Frage zu stellen, was will ich denn erstmal erreichen? Und da auch gleich einen Vorschlag zu geben. Ich will erreichen, dass ich genau weiß, wer fühlt sich verantwortlich für welche Systemgrenze? Kann diese Person sehen, welche Requirements für sie relevant sind?
Ihre ihre tests verknüpfen und so weiter also dieses ist einfach das basic v modell machen ja und ganz wichtig auch sehen womit mit welchen anderen systemgrenzen bin ich im austausch so dass das wäre für mich die basis dass das will ich erst mal schaffen.
Dann kommen so Sachen wie Reuse, wie lösungsneutrale logische Architekturen, die ich dann in eine gelöste physikalische Architektur überführe, ausführbare Activity und Sequence Diagrams, das ganze coole Zeug, was wir im System Engineering kennen und können, kommt für mich, wenn ich diese Basis im Unternehmen etabliert habe.
Ja, das ist so geil, weil das ist ja auch genau das, was im Automotive Spice, also A-Spice, wie du gerade gesagt hast, für die Hörer, die vielleicht nicht aus dem Automobil-Kontext kommen, das ist ein Prozessmodell, wie man vorgehen kann und da gibt es verschiedene Level, die man erreichen kann. Und der erste Level ist, ich glaube, der heißt ATOC, glaube ich. Nee, ATOC war das ganz chaotische. Naja, auf jeden Fall dieser Level 1, den man dann erreichen kann.
Da ist es genau wie du es sagst, man macht erstmal Dinge, damit man überhaupt dieses Produkt, dieses System an den Start kriegen kann, um damit auch mit anderen darüber zu sprechen, sprechen zu können. Also so gewisse Grundschritte, Basispraktiken nennt man die dann da. Genau. Und dann werden weitere Schritte etabliert. Die du gerade schon mal angesprochen hast. Genau, man muss sich aus meiner Sicht erstmal das Fundament gießen.
Für mich, aus meiner Erfahrung in der Industrie, und je größer das Unternehmen, desto extremer. Der größte Kostenfaktor ist doch eigentlich Kommunikation. Meetings, mein persönlicher Favorit, Review-Meetings, wo aus Gründen weitere Follow-Ups stattfinden mit noch mehr Leuten und noch mehr Leuten und noch mehr Leuten. Ja, ganz großartig. Genau, das ist aus verschiedenen Gründen ein Kostentreiber. Natürlich zuerst die Zeit, die ich verkonsumiere.
Die Opportunitätskosten, weil die Hirne der Leute, die da drin sind, die habe ich ja für was anderes eingestellt. Diese Hirne sollen ja gerade über was ganz anderes nachdenken eigentlich. Das machen sie aber jetzt nicht, weil sie sind ja im Requirements Review gefangen. Und außerdem, das muss man auch dazu rechnen, der Requirements-Review ist irgendwie um 1, Mittagessen war um halb 1 vorbei, was mache ich denn jetzt in der halben Stunde noch? Werde ich da so irgendwas Geniales denken? Nee.
Dann mache ich so ein bisschen Halbgas, bis dann das Meeting anfängt und dann war das anstrengend und dann brauche ich wieder so ein Meeting. Konsumiert mehr Hirnzeit, als das Meeting lang ist. Das muss man sich bewusst machen. Das heißt, meine eine Stunde Requirements-Review mit acht Leuten, konsumiert am Ende wahrscheinlich den ganzen Arbeitstag, oder nee, den ganzen Tagtag, also 24 Stunden Brainpower. Und das möchte ich mir als Unternehmen nicht leisten.
Das heißt, ich muss es schaffen, für mich im ersten Schritt Kommunikation, nein, anders, nicht produktverbesserungsgerichtete Kommunikation zu minimieren. Also nochmal, nicht produktverbesserungsgerichtete. Genau, also solange es nicht um das geht, was die Hirne, die ich eingestellt habe, wenn es nicht darum geht, wie mache ich die Kühlung von meinem Chip besser oder wie mache ich den Algorithmus schneller oder sowas, darüber natürlich kommunizieren
bitte so viel es geht. Dafür seid ihr alle eingestellt. Aber alles, was Reviewen, Verlinken, Korrigieren, Requirements neu formulieren und so weiter, das muss minimiert werden. Es darf nicht, Obacht, was Robert jetzt nicht gesagt hat, nicht weglassen. Aber minimieren. Natürlich müssen wir sicherstellen, dass wir ein Vier- oder Sechs-Augen-Prinzip gemacht haben, dass wir auch Rechtschreibprüfung gemacht haben. Aber das können wir mit den Tools heutzutage automatisiert machen.
Dafür brauche ich mich nicht in ein Meeting zu setzen, in ein Review zu setzen. Auch das habe ich schon erlebt, dass ich dann rausgegangen bin und hatte 1.000 Findings gefühlt, aber nichts Fachliches dabei, weiß, sondern alles nur, hier ist ein N zu wenig und da ein Komma zu viel und so ein Kram. Diese Reviews sind wichtig, damit wir frühzeitig schon Probleme aufdecken.
Aber du hast recht, das muss minimiert werden, weil du hast ja aber auch, ja, du hast ja recht, Entschuldigung, dass ich da reinquatsche, ums Fachliche soll es gehen. Und vor allen Dingen, und das ist meine persönliche Erfahrung oder mein persönliches Waterloo, wie man will, die Diskussion darüber, ob ein Requirement auf der richtigen Systemgrenze formuliert ist oder nicht, die ist aus meiner Sicht nötig, natürlich, aber auch wieder unnötig, wenn man die Systemgrenzen vorher klarer zöge.
Und das ist für mich einer der größten Zeitkiller. Die Formulation Requirement ist eigentlich recht klar, wenn meine Systemgrenze recht klar ist. Und dann gibt es beim Review auch nur noch ein Ja oder Nein oder fachlich hast du nicht recht, 5 Kilo ist zu viel, was auch immer, die Themen, über die wir reden möchten. Ich möchte noch kurz einen Punkt einschieben, den ich wichtig finde, aber vorhin vergessen habe.
Ich habe diese Leute, die ich, wie gesagt, in den Reviews binde, die ja eigentlich was anderes machen sollten, was ich auch sehen muss, und da finde ich, wir Ingenieure, ich verallgemeine jetzt mal wieder ganz platt, denken sehr, sehr oft an unsere Produkte, die wir bauen, und weniger an die Menschen. Und jemand, Jemand, der nicht in der Zone seiner Genialität denken darf gerade, der strengt sich mehr an.
Also für jemanden, der Fluid-Simulationen macht, der denkt ganz, ganz schwere Dinge den ganzen Tag und das Hirn raucht, aber es ist nicht so anstrengend, wie im Requirements-Review zu sitzen. Das heißt also, das ist eine Area, wo viele der Fachexperten, die wollen da gar nicht sein. Die wollen da gar nicht sein und es ist anstrengender für sie. Das heißt, nicht nur, dass ich verschwende den Kontextwechsel, die Zeit vor und nach dem Meeting, das Meeting selber.
Ich strenge meine Leute vielleicht auch so an, dass wenn sie vormittags den Requirements Review haben, sie nachmittags keine guten Ideen mehr haben zur Strömungssimulation oder was auch immer sie machen sollen. Das finde ich, das ist auch ein wichtiger Punkt, der unterschätzt wird in Bezug auf, lass uns mal kommunikation aufs Nötigste minimieren.
Okay, ja klar da habe ich so noch gar nicht drüber nachgedacht, natürlich, also die Leute oder ist mir auch schon passiert, dass ich dann da gesessen habe und gedacht habe puh, also so richtig kannst du jetzt hier nichts dazu beitragen, zu dem Thema oder zu dem Review genau, und so geht es ja bestimmt anderen dann auch. Der nächste Punkt, also das waren so die wichtigsten Schritte, schaff eine Basis, sieh zu, dass du diese Basis.
Beherrschen kannst, dass du da gemeinsames Verständnis schaffst und schau dann, wo kannst du da noch immer besser werden. Und dann hol dir andere Möglichkeiten vielleicht noch mit rein, indem du mehr Richtung Modellierung gehst, mehr Richtung Automatisierung. Also erstmal das Handwerk auch wirklich können. Genau, und ganz wichtig, frag warum und überprüfe, haben wir es geschafft.
Und gib auch, wenn du jetzt als Engineering Manager sagst, wir machen jetzt was in Richtung Systems Engineering, gib vor, wir machen das jetzt und das wollen wir erreichen. Wir wollen unsere Meeting-Zeit um so und so viel reduzieren, unsere Ausschusszeit, unsere Release-Iterations verkürzen oder weniger haben oder weniger retesten oder was auch immer. Gib ein Ziel vor und feiere, wenn das erreicht ist und verbessere, wenn das nicht erreicht ist. Aber mach es klar deinem Team.
Warum? Warum machen wir das? Und sei auch ehrlich, wenn es nicht klappt und sagst, oh Mist, okay, wir wollten das erreichen, wir haben das hier eingeführt, war doof, lass mal anders machen. So wie wir es, wenn wir unsere Produkte entwickeln, machen wir das ja auch. Und lass uns einfach die gleichen Systeme auf unsere Methoden, Organisationen, Tools, was auch immer anwenden. Ja, gerne, gerne. Ist das schon ein Schritt, um auch Widerstände bei solchen Veränderungen zu überwinden?
Also da kommt jemand daher und sagt, wir müssen jetzt Systems Engineering machen oder wir müssen R-Spice einführen oder wir müssen irgendeine ISO erreichen. Heißt es dann, muss das wirklich sein? Das ist doch, wie du gerade sagst, zwei Millionen oben drauf geknallt an Kosten, weil wir vermuten, dass es Aufwand ist. Ist das jetzt, was du gerade gesagt hast, ist das schon ein Schritt, um Widerstand zu überwinden?
Ich hoffe es. Also auch da muss ich sagen, du hattest mein LinkedIn-Zeug angesprochen, dieser Return on Invest von Systems Engineering, der ist ein bisschen so eine Wolke. Ja. Das wirklich zu vermitteln und zu sagen, wenn wir das jetzt machen und ihr euch jetzt das lernt und in dieses neue Tool kommt und vielleicht das hier ein bisschen anders denkt, dann sparen wir hinten raus das und das.
Weil dann müssen wir eine Testkampagne, die am Samstag läuft, dann nicht fahren in drei Monaten oder in sechs Monaten, was auch immer ich für Zykluszeiten habe. Das ist sehr schwer zu vermitteln und vor allen Dingen, wenn es nicht klappt. Und deswegen sage ich, mach es messbar, sag, was du willst und erzähl dann, ob es geklappt hat. Wenn ich das nicht messbar gemacht habe, dann kann jeder einfach nur meckern.
Und Behauptungen aufstellen. Genau, wenn ich das messbar gemacht habe und vor allen Dingen auch im Vorhinein sage, das ist ein Experiment. Meine Hypothese ist, wir führen jetzt diese Methode, dieses Tool ein, wir holen jetzt diesen Consultant, der bringt euch jetzt zwei Tage lang was bei und meine Hypothese ist, dass wir dann vor Weihnachten dieses und jenes Problem nicht haben werden, das verbessert haben werden. Und dass ich dann aber auch sage, hey, ich bin offen, dass das hier scheitert.
Ich bitte euch mitzumachen. Ich bitte euch, dass wir das ausprobieren und dass ihr meinem Ziel hier folgt und unterstützt. Aber ich bin auch offen, wenn ihr sagt, das war Schrott, dann machen wir es anders. Ich glaube, das ist sowieso für Leute, deren Hirn ingenieursmäßig verdrahtet ist, ist dieses Hypothese-Experiment-Veränderung ganz wichtig. Du hast gerade den Return on Invest erwähnt.
Eigentlich ist es ja wirklich schwer, sowas zu berechnen, weil erstens jedes Unternehmen ist anders, jede Branche ist anders, du musst andere Grundlagen dafür schaffen. Das ist immer super schwer. Ich habe das zweimal versucht anzuwenden. Es waren zwei komplett unterschiedliche Firmen, wo ich das gemacht habe, aber beides Mal haben mir die Ergebnisse gezeigt, vielleicht, dass es funktioniert, dass da wirklich was bei rumkommen kann.
Und das ist nicht gerade wenig, was bei so einem ordentlichen Systems Engineering Ansatz am Ende wirklich rumkommen kann. Ich betone das so am Ende, weil das ist genauso, wie du es gesagt hast. Wenn du nur kleine Schritte machst zu Anfang, wird sich das nicht so extrem auswirken, als wenn du die irgendwann beherrschst und dann auch noch eine Automatisierung obendrauf setzen kannst.
Dann wird es natürlich richtig geil und dann bringt dir das richtig was in die Kassen. Ja. Und das Gleiche gilt ja auch dann für, wenn du diese Methoden, Schritte, was auch immer dann verstanden hast und umgesetzt hast, das bringt dir ja dann auch enorm Zeitgewinn und damit auch ein Return on Invest, wenn du mal vor so einem Audit stehst oder vor so einem Assessment stehst.
Ich weiß nicht, ob du das auch schon mal erlebt hast oder die Hörer gerne schreibt uns gerne irgendwie euer Feedback wie ist das bei euch, wenn ihr, Audits oder Assessments habt gibt es dann so eine Schlussredaktion kurz vor einem Assessment wo nochmal alles auf Vordermann gebracht wird, die die gibt es aus meiner erfahrung und da muss ich auch gleich schon wieder meine linkedin audience polarisieren denn ich bin ich bin der meinung es kann nicht sein dass die die dönerbude
bei der ich mir mittags meinen döner hole da kann das gesundheitsamt zu jeder zeit einfach rein geiles beispiel ja dann musste dann muss der döner frisch sein und die zwiebeln frisch und es auch egal wer am döner spieß steht ob der ob der altgediente chef dort ist oder sein sein Praktikant oder die Aushilfe oder was auch immer. Der Dönerladen muss sauber sein, zu jeder Zeit. Sonst kommt das Gesundheitsamt und sagt, nee, hier ist zu.
Wir haben es irgendwie geschafft, dass wir unsere Assessments ankündigen und dass wir dieses, so, ja, das ist wie früher, wenn Mama gesagt hat, ich komme nach dem Abendessen und gucke, ob dein Zimmer ordentlich ist. Und dann weiß ich, bis wann ich aufräumen muss. Das ist doch, da machen wir es uns doch leicht, beziehungsweise wir machen es uns leicht und schwer gleichzeitig, denn wir haben jetzt keinen Grund, quasi von Minute 1.
Unseren Ace Buys-Richtlinien oder was auch immer für eine ISO uns regiert, zu folgen. Wir können es uns leisten, quasi wenn man so möchte, Chaos, ich sage es ganz vorsichtig, weil meistens ist es das nicht, aber produktives Chaos zu haben und dann zu sagen, jetzt aber zwei Wochen lang alle ins Requirements-Werkzeug und verlinken wie der Teufel.
Das können wir uns aktuell leisten. Das könnten wir uns nicht leisten, wenn die Audits es nicht gescheduled werden, wenn es jeden Tag passieren könnte und es auch eine ernste Konsequenz gäbe, wie beim Döner.
Und da würde ich auch sagen, da glaube ich, das würde sogar bei der Einführung auch helfen, wenn man dann sagt, okay, diese Haurucks, die sind anstrengend und das ist teilweise mit Überstunden und Abendsarbeiten und samstags sich hinrocknen, Requirements verlinken und das wieder als jemand, der wie gesagt, seine Genialitätszone ganz woanders hat, das kenne ich aus eigener Erfahrung,
Das ist das Furchtbarste, was du Leuten antun kannst. Und wenn dann in den Köpfen verknüpft ist, oh, Systems Engineering, das ist das, wo ich alle vier Monate an einem Samstag hocke und dann verlinke ich Requirements, dann verlierst du die Leute sofort. Jo, definitiv, weil da hat keiner Bock drauf. Am Samstag kann ich was anderes machen. Da hast du völlig recht. Und die Dönerbude, das ist so geil, dieses Beispiel. Finde ich super. Ja, genau, das Gesundheitsamt kommt rein, macht dir die Bude zu.
Und dieser Druck, der hat mir manchmal gefehlt. Der war bei, in der Automobilbranche war der noch eher da, weil man ja dann die Zulassung zur Lieferung ans Band nicht bekommen hat, unter Umständen. Es sei denn, man hat dann nochmal nachgearbeitet, dies, das und so weiter. Aber das hat auf den Prozess dann nachher keine Auswirkung gehabt. Dann hat man ad hoc irgendwie was nachgearbeitet, dann durfte man doch liefern.
Aber in anderen Branchen, wo kein einzelner Kunde dahinter steht und vor allem nicht so ein einflussreicher Kunde dahinter steht, wie die Automobilbranche, da habe ich das leider nie erlebt. Und der wurde natürlich dann auch einfach so in den Tag hinein entwickelt. Und nächste Woche ist Abgabe, ja, aber wir haben ja noch dies und jenes und eigentlich sind wir erst zu 60% fertig und wir müssen das alles schieben.
Ja, wurde dann vom Projektleiter und vom Produktmanager gesagt, ja, das ist ja ärgerlich, ja, ja, dann schieben wir es. Und ja, total ärgerlich, weil alle komplett durch die Bank unzufrieden waren auch. Und ich bin der Meinung auch, das muss auch eingesetzt werden oder diese Schritte müssen auch eingesetzt werden, um Zufriedenheit zu schaffen.
Und du kannst das schaffen dadurch, weil dann alle sich gegenseitig auf die Schulter klopfen können und sagen, wow, da haben wir richtig was Geiles geschaffen hier. Das war anstrengend, aber jeder, wie du es sagst, wie du es gesagt hast, die Genialität, die jeder in sich trägt, zielgerichtet einzusetzen, um dann coole Produkte zu erstellen. Ja, vor allem durch diese Horrocks hast du noch ein anderes Problem und zwar.
In sehr vielen Branchen. Ich sage mal, wenn ich jetzt ein Raumschiff baue, was den Jupiter umkreist, das kann ich nicht so viel in echt testen. Mein Rasenmäher, mein Küchengerät, mein Auto auch, da kann ich mal, ich sage mal jetzt auch wieder ganz plakativ, da kann ich mal eben rausgehen und ich probiere mal.
Und da konkurriere ich, das muss man so sagen, als Systems Engineer mit meinem strategischen Approach eine gute Lösung, sich konzeptuelles Aufschlüsseln und Nachdenken zu finden, da konkurriere ich, wenn ich so möchte, mit den Trial-and-Error-Leuten. Und am besten wir konkurrieren nicht, am besten wir ergänzen uns gut, ganz klar, aber wenn ich so eine Hauruck-Aktion mache, dann wird alles Wichtige von den Trial-and-Errors gefunden funden und dann im Hauruck nachdokumentiert.
Und da in der Organisation dann den Benefit davon und dann zu erzählen, ja, Moment, wir machen ja Systems Engineering, weil wir an alles denken wollen und weil wir und so weiter, was man halt so erzählt, wenn man Systems Engineering propagieren will, aber die gelebte Realität ist, wir finden alles auf der Teststrecke oder an der Testbench raus. Und dann, wenn das Assessment droht, dann machen wir mit Hauruck, schreiben wir es in eines von euren komplexen Tools.
Wie gesagt, ich provoziere mit Absicht, Weil so oder so ähnlich ist es mir in diversen Organisationen gespiegelt worden oder habe ich auch selber erleben dürfen. Dann verliere ich die Leute, die und ich als Systems Engineer, das sind meine Kunden, ich will das Systems Engineering schmackhaft machen. Ich bin nicht, das höre ich leider auch sehr oft, ja, aber das Management müsste mehr auf die Ausbildung achten oder sie wollen ja nicht im System denken und so weiter. Das glaube ich nicht.
Ich bin als Systems Engineer verantwortlich dafür, dass ich das nach außen trage und dass ich das allen anderen schmackhaft mache. Dafür ist niemand anders. Ich muss auf meine eigene Party einladen und die Leute müssen kommen. Komm, ich kann niemand anders dafür verantwortlich machen, wenn das nicht klappt. Da fürchte ich, dass, wie gesagt, dieses, ja, lass mal machen und dann hau ruck, das geht da ganz, ganz krass entgegen.
Wenn Leute das einmal, zweimal, dreimal erlebt haben, diese Hauruck-Phasen, dann kriege ich die auch nur noch ganz schwer. Mhm, genau. Sag mal, vielleicht kommen wir so langsam mal zum Abschluss von der Episode, aber wenigstens eine wichtige Frage habe ich noch. Kann Systems Engineering der deutschen Industrie helfen, ihren Wettbewerbsvorteil auf dem globalen Markt zu erhalten oder vielleicht sogar wiederherzustellen?
Weil du hast ja ganz zu Anfang gesagt, da gibt es ganz genauen Druck aus anderen Regionen der Welt. Ich werde gleich antworten und will vorher noch auf einen anderen lustigen Learning vom LinkedIn-Content heraus. Und zwar unter fast jedem meiner Beiträge über Systems Engineering kommt ein Kommentar, der sagt, ja, bist du sicher, dass du eigentlich selber verstanden hast, was Systems Engineering ist?
Das heißt, und jetzt steige ich da tatsächlich ein und schreibe dir diesen Kommentar mündlich auch drunter, es kommt darauf an, was du meinst mit Systems Engineering. Um jetzt aber deine Frage zu beantworten. Wenn wir es schaffen, die Zeit der Hirne unserer Leute, nicht außerhalb ihrer Genialitätszone zu verbringen, schwieriger Satz, also ich formuliere es positiv.
Wenn wir es schaffen, so viel Zeit wie möglich die Leute dort sein zu lassen, wo ihre Genialität hingehört, aber wir trotzdem diesen Austausch ermöglichen, wir trotzdem dieses, ich hatte das mit der Klimaanlage und der Sprachsteuerung, wir es trotzdem schaffen, allen Verantwortlichen von Teilsystemen und Teil-Teilsystemen ihren Impact bewusst zu machen und ihren Einfluss, den sie haben und ihre Verbindung, ihre Interfaces, wenn wir das aufzeigen können auf eine einfache Art und Weise,
auf eine einladende Art und Weise, auf eine anregende Art und Weise, werden wir extrem viel schneller und man muss ja auch so sagen.
Besser gelaunt arbeiten ich durfte selber an projekten mit mitarbeiten von selbstfahrenden lkws wie cool ist das denn wenn du das meinem neunjährigen lego technik bauen denn ich erzählt hat ist dass ich mal einen echten selbstfahrenden lkw muss eigentlich doch jeden abend nach hause gehen und wer auch immer dort auf dich wartet stolz berichten wie cool das war und wie cool das ist dass du in der autofirma an selbstfahrenden lkws mitarbeiten wir kennen es selber das ist
nicht das was wir dem dem oder derjenigen berichten die wir auf uns zu hause wartet weil dann meckern wir uns schimpfen wir und auch der chef und die prozesse und dies und das und das geht nicht und ich glaube wenn man diese basis legt von der wir gesprochen hatten immer diese basis legt und es ermöglicht dann ist nicht nur ja dass wir schneller und kostengünstiger und so weiter alles schön und gut aber ich glaube nach hause zu kommen und einfach stolz zu sein dass was
du heute wieder Cooles gebaut hast, wie du deine Genialität verwenden konntest, damit irgendwann eine Drohne sich selber fliegt oder ein Chirurg aus Japan im Sudan eine Operation macht. Wir machen ja als Ingenieure so tolle Sachen. Und es wäre doch cool, wenn wir einfach jeden Abend mit stolz geschwellter Brust nach Hause kommen dürften. Ich glaube, das können wir schaffen. Das können wir erreichen. Ja, wow. Das ist schon fast ein tolles Schlusswort, Robert. Wunderbar.
Ja, genau. Also ich glaube auch, dass wir durch das Arbeiten auf ein bestimmtes Ziel hin, was man sich gemeinsam vorgenommen hat, dass man dadurch mehr Freude, mehr Effektivität reinbringt, zufriedener wird. So wie du es gerade mit anderen Worten wunderbar beschrieben hast. Man ist stolz auf die Dinge, die man erschaffen hat. Das bringt uns, also da müssen wir wieder hinkommen, das bringt uns voran. Das glaube ich auch. Genau. Wunderbar. Robert, das war ein ganz tolles Gespräch.
Wir haben viele Dinge gestriffen hierbei und ich glaube, wir könnten auch noch weitersprechen über diese Themen, denn das beschäftigt dich, das beschäftigt mich, wir haben viel Erfahrung, die wir da schon mitbringen. Du hast ja auch ein Tool entwickelt, vielleicht planen wir gleich im Anschluss die nächste Episode, damit wir darüber nochmal ein bisschen sprechen können, wo uns das da unterstützen kann.
Und bevor wir aufhören, noch die Frage, haben wir irgendwas vergessen, was wir vielleicht heute noch zu dem Thema Innovation neu beleben, wie Systems Engineering deutsche Unternehmen dem zu neuer Exzellenz verhelfen kann. Können wir da noch irgendwas zu sagen? Haben wir da noch irgendwas vergessen?
Ich würde vielleicht, wenn ich mir jetzt denke, dass sich das hier Menschen anhören, die sich überlegen, in ihrer Organisation Systems Engineering einzuführen oder zu verändern, würde ich da vielleicht noch einen Punkt machen, der mir aufgefallen ist. Und zwar hier wieder auch das Menschliche. Wir sind als Ingenieure und Ingenieurinnen naturgemäß an Produkten interessiert. Sonst hätten wir wahrscheinlich diese Karriere nicht gemacht.
Sehr oft wählen wir Dinge wie zum Beispiel Prozesse, Methoden, Tools, wählen wir aus nach Features, so wie wir ein Auto kaufen. Wir überlegen uns, kann es das, kann es jenes, kann es welches, kann es und so weiter. Wir machen unsere Liste, machen unsere Häkchen und wählen damit unseren Ansatz, unser Tool, unser was auch immer aus. Was wir ein bisschen unterschlagen und was ich glaube super, super wichtig ist, ist zu fragen, wen habe ich denn da im Team?
Was haben die für Stärken und Schwächen? Und mit dem Ansatz, den ich fahre, wie lange brauche ich, bis meine Leute das können mit den Werkzeug-Methoden-Prozessen, die ich jetzt einführen will. Wie viel Aufwand muss ich bringen? Wie sehr strapaziert sie das? Wie sehr werden sie das freiwillig machen? Und so weiter. Ich glaube, eine Lösung nicht nur nach ihren Features zu bewerten, sondern zu sagen, wie ist denn mein Team mit der Lösung?
Wie wird das denn sein? Und verschiedene Lösungsmöglichkeiten durchzuspielen mit, wen habe ich denn da und wie wird das wohl funktionieren, wenn ich diese Leute auf diese Lösung loslasse? Also, weil ich glaube, dann kann es sein, dass Lösungen, die sich auf den ersten Blick suboptimal von dem Kästchen und den Häkchen her anfühlen, wenn ich sie auf mein Team projiziere, vielleicht optimal werden.
Okay, das heißt also, du siehst jetzt das System, das zu entwickelnde System nicht nur aus technischer Sicht, sondern es kann dieses eine System mit dem einen Team super gut entwickelt werden? Hättest du jetzt aber andere Leute zur Verfügung, dann müsstest du zwangsläufig auch irgendwie einen anderen Aufbau deines Systems wählen, um die Lösung zu bekommen, um optimalste Lösungen zu bekommen. Also diese Kombination Team und Systemarchitektur ist auch ungemein.
Ja, ich meinte eher, wenn ich jetzt wähle, welche Prozesse, Methoden, Tools führe ich ein, um zum System Engineering zu kommen, dass ich dann erstmal überlege, wer macht denn da mit. Ah, okay, ja, alles klar. Also noch die Metasicht da drauf quasi. Genau, die Menschensicht. Okay. Super. Robert, vielen Dank, dass du dir die Zeit genommen hast, hier bei mir im Podcast zu sein. Wie gesagt, ich finde es spannend.
Wir haben jetzt zumindest einmal kurz dein Tool erwähnt, was du entwickelt hast mit deiner Firma. Ich werde das alles auch schon verlinken in den Shownotes. Aber ich glaube, selbst ich und ich hoffe auch der eine oder andere Hörer hat Blut geleckt und würde jetzt ganz gerne mehr wissen über das Tool, was das denn macht oder wo uns das denn beim Systems Engineering das Leben einfacher macht. Von daher, lass uns gleich noch einen Folgetermin vereinbaren. Ja, sehr gerne.
Vielen Dank, dass du hier warst. Es war mir eine Ehre. Danke, dass du mich eingeladen hast. Es war mir ebenso eine Ehre. Ich hoffe, es war interessant. Das war mein Interview mit Robert Helmisch, dem Gründer von Spicy SE. Zusammenfassend zur heutigen Episode meine drei Tipps. Überlege dir genau, wie du komplizierte Inhalte vermitteln möchtest. Schau dir an, welche Fähigkeiten und Verständnisse dein Team und deine Stakeholder haben und brauchen.
Schaffe ein gemeinsames Verständnis von dem, was ihr bauen wollt. Brauchst du Unterstützung bei der Erstellung von Lastenheften oder hast eine Frage dazu, dann findest du meine E-Mail in den Show Notes. Klicke da drauf oder kopiere sie in dein E-Mail-Programm und schicke mir eine Mail. So können wir darüber sprechen. Das war die heutige Episode des Zukunftsarchitekten, der Systems Engineering Podcast für Machende und Entscheidende.
Mein Name ist Björn Schorre und ich danke dir fürs Zuhören. Hab Spaß an dem, was du machst und vor allem wünsche ich dir einen hohen Wirkungsprozess. Tschüss und bis zum nächsten Mal.