Schlagwortarchiv für: systems engineering

ZA212 - Digitalisierung im Maschinenbau - Quo Vadis?

14.11.2023 38 Minuten



Zusammenfassung

In der heutigen Sendung reflektieren Maik Pfingsten und Björn Schorre die bedeutenden Veränderungen und Entwicklungen, die sich in den letzten 520 Wochen im Bereich Maschinenbau und Technologie ereignet haben. Wir beziehen sich dabei auf einen Blogbeitrag von Maik aus dem Jahr 2014, der die zunehmende Bedeutung von Software im Maschinenbau betont und als einen zentralen Wertetreiber der Zukunft identifiziert.

Wir wollen Einblicke geben in die Entwicklung des Maschinenbaus und aufzeigen, wie Unternehmen und Ingenieure sich auf die wachsende Bedeutung von Software in ihren Produkten vorbereiten können.

Begleite uns, während sie die Zukunft des Maschinenbaus und die entscheidende Rolle von Software in dieser Podcast-Episode beschreiben.

 

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

###############

Brauchst Du Unterstützung bei der Erstellung eines Lastenheftes oder hast eine Frage dazu, dann findest Du meine Email in den Shownotes. Klicke darauf oder kopiere sie in Dein Emailprogramm und schicke mir eine Mail und wir sprechen darüber.

Dann kannst Du Dir in meinem Online-Kalender auch gerne direkt einen Termin buchen: https://kalender.bjoernschorre.de

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

On Air in dieser Episode

avatar
Björn Schorre

ZA211 - Wie werden Anforderungen in Subsysteme zerlegt?

31.10.2023 28 Minuten



Zusammenfassung

In dieser Episode des Zukunftsarchitekten-Podcasts geht es darum, wie du Anforderungen in Subsysteme aufteilen kannst und welche Vorteile dies für dein Projektmanagement hat. Du wirst verstehen, dass es wichtig ist, die Anforderungen von Kunden und dem Markt zu kennen, um erfolgreich Produkte verkaufen zu können. Neben den Systemanforderungen gibt es auch auf Unternehmensebene spezifische Anforderungen an Software, Elektronik, Elektrik und andere Bereiche. Du musst diese Anforderungen aufteilen, um die Umsetzung durch die entsprechenden Teams zu ermöglichen und Arbeitspakete zu bilden.

Teile die Anforderungen in funktionale Elemente auf, um ihnen bestimmte Funktionen zuzuweisen. Dadurch kannst du die Anforderungen genauer planen und die entsprechenden Attribute und Metadaten festlegen. Eine bewährte Methode ist die Dreiteilung, bei der du die Anforderungen grob und auf einer High-Level-Ebene aufschreibst, dann die Funktionen bestimmst, die mit diesen Anforderungen erfüllt werden müssen, und schließlich eine logische Aufteilung des Systems vornimmst. Nutze den morphologischen Kasten, um verschiedene Möglichkeiten zur Erfüllung der Funktionen zu betrachten und Varianten zu bilden, die später bewertet werden können. Dadurch kannst du die Anforderungen strukturiert aufteilen und besser verfolgen, welche bereits umgesetzt sind und welche noch bewertet werden müssen.

Bei der Architekturbewertung kannst du verschiedene Kriterien wie Preis oder Entwicklungsgeschwindigkeit betrachten. Nachdem du deine Auswahl aus dem morphologischen Kasten getroffen hast, überführst du deine funktionale Architektur in eine logische Architektur und weist dort die einzelnen Elemente zu. Es kann sein, dass beim Einbau der Elemente in das Produkt weitere Anforderungen auftauchen, die zuvor nicht berücksichtigt wurden. Diese Anforderungen werden ebenfalls dokumentiert und den logischen Elementen zugewiesen.

Auf der physikalischen Ebene betrachtest du die mechanischen Bauteile, Elektronik und Software, die auf dem System läuft. Auch Software betrachtest du als physikalisches Element, da sie auf dieser Ebene besser einzuordnen ist und oft ein eigenes Software-Team vorhanden ist. Bei den physikalischen Elementen schaust du zunächst, welche bereits im Unternehmen vorhanden sind und wiederverwendet werden können. Falls dies nicht der Fall ist, guckst du, was mit kleinen Änderungen wiederverwendet werden kann. Im schlimmsten Fall entsteht ein neues Teilprodukt oder eine Bausteinvariante. Im besten Fall kann ein Baustein sowohl im alten als auch im neuen System verwendet werden. Es spart Zeit, vorhandene Bausteine wiederverwendet, solange die Änderungen akzeptabel sind. Es besteht auch die Möglichkeit, Zukaufteile wie Widerstände oder Embedded-Systeme wie Arduino oder Raspberry Pi zu verwenden. Diese müssen jedoch auch Industrie-Tauglichkeit, EMV, etc. erfüllen. Du kannst sie entweder direkt zukaufen oder bei der eigenen Entwicklung oder einem externen Entwicklungsunternehmen beauftragen.

Es entstehen weitere Anforderungen, wenn du physikalische Elemente gestaltest, die deinen logischen und funktionalen Architekturen entsprechen. Zum Beispiel benötigst du für die Erhitzung eines Gartengrills einen Brenner. Die Implementierung eines solchen Brenners erfordert spezifische Schnittstellen wie ein Ventil zum Regulieren des Gaseinlasses. Hier musst du dir überlegen, welche Anforderungen sich aus dem Einsatz dieses Ventils ergeben, wie beispielsweise der Durchmesser und die Anschlussgeometrie. Auch die Luftzufuhr und der Abgasschutz müssen berücksichtigt werden. Indem du dein System dekomponierst und Entscheidungen triffst, kannst du die erforderlichen Anforderungen filtern und ihnen Traceability und Informationen zuordnen.

 

 

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

###############

Brauchst Du Unterstützung bei der Erstellung eines Lastenheftes oder hast eine Frage dazu, dann findest Du meine Email in den Shownotes. Klicke darauf oder kopiere sie in Dein Emailprogramm und schicke mir eine Mail und wir sprechen darüber.

Dann kannst Du Dir in meinem Online-Kalender auch gerne direkt einen Termin buchen: https://kalender.bjoernschorre.de

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

On Air in dieser Episode

avatar
Björn Schorre

ZA134 - Mentoring im Projektmanagement und was HILTI anders macht

15.08.2017 28 Minuten



Zusammenfassung

Verweise in der Episode

Transcript

Herzlich Willkommen beim Zukunftsarchitekten, der Projektmanagement Podcast für Entscheider. Am Mikrophon ist wieder Maik Pfingsten. Als Trouble Shooter aD gebe ich euch Tipps und Impulse, damit ihr eure Projekte zum Erfolg führen könnt.

Ich werde immer wieder gefragt, was Mentoring eigentlich ist und wie das funktioniert. Und dabei fällt es mir selbst oftmals sehr schwer zu erklären, was da eigentlich so hinter steckte. So dachte ich mir, ich lade einfach meinen ehemaligen Menti ein und der kann eure Fragen aus seiner Sicht viel, viel besser beantworten. So wirst du in der Episode erfahren, warum Mentoring für dein Projekt so wertvoll sein kann, wie ein Unternehmen davon profitiert und was für spannende, persönliche Entwicklungen sich daraus ergeben.

Ja, heute darf ich einen ganz besonderen Menschen im Podcast begrüßen. Er ist Diplom-Ingenieur Verfahrenstechnik, hat das in Stuttgart studiert, ist dann 2003 als Projektingenieur bei Hilti in die Entwicklung eingestiegen, 2005 den nächsten Schritt gemacht in Richtung technische Projektleitung und dann 2010 in die Projektleitung übergegangen. Und ich darf heute sagen, er macht einen ganz wesentlichen neuen Schritt und über den werden wir heute reden und ich freue mich sehr, hier im Podcast zu begrüßen Christoph, Christoph Wetter.

Maik: Hallo Christoph.

Christoph: Hallo Maik. Schön von dir zu hören.

Maik: Ja, ich dachte, wir besprechen heute mal ein etwas außergewöhnliches Thema, weil ich glaube, dass du, und vor allem mit dir zusammen, dein Unternehmen, ihr geht ja gerade einen Schritt, der aus meiner Sicht außergewöhnlich ist und ich glaube, das einmal ein bisschen zu besprechen, kann durchaus sehr interessant sein. Wir beide kennen uns ja im Grund schon seit, ich sage mal, round about fast über drei Jahre und wir haben ja jetzt in dieser Zeit zwei verschiedene, ich sage mal, Situationen oder Zeit miteinander verbracht. Das eine war ja dein Projekt, wo ich als Mentor dich und dein Projekt begleitet habe. Und der zweite Teil eben, da geht es drum, Aufbauen des internen Mentors. So ein bisschen haben wir das hier auch für die Hörer ein bisschen aufgedröselt und ich würde sagen, wir steigen einfach mal in diesen ersten Teil ein. Mentoring im Projekt. Warum habt ihr damals das Mentoring gestartet? Und was waren aus deiner Sicht so die Highlights dazu?

Christoph: Okay, gestartet hat es eigentlich bei uns im Projekt beziehungsweise auch bei uns intern in der Firma, wir sind in das Thema Requirements Engineering eingestiegen und haben dann doch festgestellt, ganz so trivial ist die ganze Geschichte nicht und es hat auch, intern gab es wenig Erfahrungen, wie man das denn nun über so einen ganzen Projektlebenszyklus durchzieht. Wir haben es zwar dann vielleicht hergekriegt auf der einen Seite irgendwelche Requirements niederzuschreiben, aber wir haben uns extrem schwer getan, dann doch konsequent so Themen, wie Auseinanderhalten von den Requirements und den Projektanforderungen und den Anforderungen für das Produkt. Wo gehört jetzt was hin? Und da kam eigentlich die Idee auf, lasst uns doch einen erfahrenen Kollegen suchen und lasst uns doch einmal so einen Projektlebenszyklus durchspielen vom Anfang, vom Aufnahme der Anforderung an das Produkt bis zum Ende und das irgendwie darstellen auch übersichtlich mit Hand und Fuß, dass wir dort einfach einen Schritt weiterkommen, weil selber wären wir mehr oder weniger ein bisschen planlos durch die Gegend gerannt und vermutlich auch gescheitert, insbesondere weil wir eben auch aus dem Projektteam extrem wenig Erfahrung hatten, was das anging.

Maik: Und ich erinnre mich noch gut, wir haben ja dann vor drei Jahren quasi gestartet miteinander, da waren ja eine ganze Menge, ich sage mal, viele grundlegende Fragen erstmal im Raum. Das war ja so das, was ich am Anfang wahrgenommen habe. Wie hast du das gesehen?

Christoph: Es kam natürlich sehr viel Unsicherheit und eben auch diese Fragen, was machen wir überhaupt mit dem und was bringt es uns? Und jetzt müssen wir alles neu machen oder das kostet uns ja so viel Zeit, das hat doch früher auch immer alles funktioniert. Da waren schon sehr viele Bedenken auch im Projektteam und da jemand  zu haben, der einfach die Erfahrungen mit sich bringt aus zig Jahren, aus zig Projekten und das rüberzubringen, das war schon sehr wichtig und auch enorm hilfreich. Weil, das hat ein bisschen diesen Impuls gebracht, a lasse uns das jetzt doch probieren und lasse uns das durchziehen und ein bisschen Begeisterung reinzubringen, weil ohne das hätten wir das nicht geschafft.

Maik: Genau.

Christoph: Und das war sicherlich auch eines der Highlights, weil wir einfach jemand hatten, der uns da so an der Hand genommen hat und der auch gesagt hat, jetzt machen wir das, das und das. Und wir hätten halt dann wahrscheinlich viele Sachen einfach nur halbherzig beziehungsweise wären auch verloren gegangen und man hätte sie gar nicht gemacht. Das wäre sicherlich passiert, wenn wir niemand hatten, der das gut und strukturiert durchzieht.

Maik: Wie war so für dich und dein Team die Erfahrung? Wir haben ja den Kickoff-Workshop gemeinsam gemacht, auch zusammen mit dem Kollegen aus dem Marketing, mit dem Franz. Und haben dort mit dem System Footprint ja erstmal überhaupt diese Diskussion, was sind die Wünsche, was sind die Anforderungen aus Sicht des Marketings an euer Produkt, was ihr ja im Rahmen dieses Projektes entwickeln wolltet. Dann sind wir aber übergegangen in dieses Veto-Elementoring. Das heißt, wir haben ja dann uns vereinbart einmal die Woche eine Stunde in einer Skype-Session quasi über eure Themen zu diskutieren, über eure Probleme zu diskutieren, über eure Fragen zu diskutieren. Und ich erlebe häufig immer in Gesprächen, dass dieser virtuelle Ansatz oftmals noch so ungewohnt ist. Wie war so eure Erfahrung damit?

Christoph: Unsere Erfahrung war, am Anfang war das tatsächlich ungewohnt. Muss ich mal ganz ehrlich zugeben, aber wir haben uns, im Laufe der Zeit haben wir uns da richtig in das Thema eingearbeitet und das Coole ist einfach, man hat solche kurzfristigen Ziele und man kann auch in diesen, wenn man das wöchentlich macht oder auch zweiwöchentlich, man gibt sich Sachen vor, man committet sich zu Themen und man bearbeitet die. Und es kommen dann einfach viele Fragen auch in dieser Bearbeitungszeit und die kann man dann relativ schnell und konsequent lösen. Und das hilft einem natürlich dann im Laufe der Zeit, weil man selber immer besser wird und man lässt das Thema auch nicht schleifen. Das ist ja oftmals ein kritischer Baustein, dass man zwar dann schön startet mit einem Workshop und dann flacht das dann ab und dann schläft das dann ein und irgendwann so ganz am Ende, jetzt muss ich dann ja doch noch mal schnell das irgendwie zusammenschreiben. Und unsere Erfahrung war einfach durch die Kontinuität in diesem Prozess und in diesem Mentoring, dass wir einfach dieses Level hochhalten konnten und das Interesse hoch halten konnten und am Ende auch ein extrem gutes Dokument herausgekommen ist.

Maik: Ich erinnere mich noch an so zwei Aussagen, zwei Momente, die du in der Zeit damals mal gemacht hast. Das ist mir bis heute hängen geblieben. Das eine war, wir haben, ich versuche es noch mal zusammen zu kriegen, wir haben irgendwann mal einen Call gehabt, da hattet ihr eine super brennende Frage. Ich weiß noch quasi, ihr seid mir um 10:00 Uhr mehr oder weniger durchs Skype ins Büro gefallen mit dieser Frage rein, die euch so auf dem Herzen gebrannt hat, die für euch so entscheidend war, ihr habt auch, glaube ich, schon Tage vorher darüber diskutiert und dann haben wir das besprochen und ich habe aus meiner Sicht Feedback gegeben, wie ich das lösen würde. Und dann waren wir nach 20 Minuten durch und alles klar und dann seid ihr sofort losgezogen, jetzt wissen wir, wie wir es umsetzen. Gut alles klar, bis nächste Woche. Wir nehmen uns das und das und das vor. Und ja, schönen Tag. Und ich saß da so nach 20 Minuten, denke so, wo du mir im Nachhinein mal reflektiert hast, das war so wertvoll, wie war das für dich?

Christoph: Ja, das war einfach, wir sind dann oft gescheitert an solchen Formulierungsthemen oder wie setzt man irgendwelche, Variantenmanagement und solche Themen, das war, glaube ich, genau der Punkt, um. Und wir hatten so eine Idee und wir wussten nicht, wie wir die umsetzen können. Und dann hat Maik uns einfach auch seine Erfahrung und ein paar Hints gegeben und wo wir, Licht auf, genauso müssen wir das machen und wir haben gesagt, brauchen wir nicht mehr den Kollegen, das machen wir jetzt selber. Und das hat sich eben so ein bisschen so eingebürgert dann, weil wir einfach festgestellt haben, wir werden ja selber fit in diesem Thema. Und wir haben halt auch gesehen, dass das Dokument so viel wertvoller war, als das, was wir vorher hatten und uns auf der einen Seite zwar viele Fragen aufgeworfen hat, aber am Ende deutlich mehr Antworten. Und wir dann einfach auch projektmäßig oder produktmäßig so genau wussten, was wir denn eigentlich haben wollen und wir konnten das auch nach extern extrem gut, also extern, das heißt, innerhalb unserer Firma so gut vertreten und so gut verkaufen, mit so wenig Rückfragen und so viel Klarheit, dass die Leute gesagt haben, „stark, Projekt super, so etwas Gutes hatten wir noch gar nicht.“ Und das war eigentlich so der Knackpunkt, wo die Leute dann selber eingestiegen sind in das Thema und dann auch weiter arbeiten wollten und das Ding eigentlich auch zu einem Ende bringen wollten und das war eigentlich so mit der größte Erfolg eigentlich in der ganze Geschichte.

Maik: Also ich erinnere mich noch gut. Wir haben ja im Grunde drei Teile damals durchgesprochen. Das Lastenheft, dann Systems Requirement Specification und die System Architecture Spezification. Ihr habt ja wieder intern andere Begrifflichkeiten für diese Artefakte und von Mal zu Mal, wenn wir diese Review-Workshops gemacht haben, wurde das irgendwie auch insgesamt für alle Beteiligten einfacher. Ich habe noch nie so eine Review-Workshop erlebt, wie den bei dem dritten Artefakt, also der Architektur-Spezifikation oder bei euch ja DES, wo wir ja innerhalb von drei Stunden, glaube ich, durch waren.

Christoph: Ja, so ungefähr.

Maik: Also da habe ich dich angeguckt und gesagt, wow, ihr habt es wirklich komplett begriffen. Die andere Sache, wo ich mich gut daran erinnere noch aus der Zeit damals. Wir hatten ja eine Flatrate vereinbart, eine monatliche Flatrate unabhängig davon, komme, was wolle, einfach diese monatliche Flatrate. Auch das ist ja ungewöhnlich so im normalen Kontext, den ich in Projekten häufig erlebe, und da kamst du mal irgendwann, ich glaube, ein halbes, dreiviertel Jahr später, weiß ich noch, haben wir darüber gesprochen und du sagtest, du warst heilfroh, dass wir das damals vereinbart haben, weil irgendein Top-Manager um die Ecke kam, so nach dem Motto, Management by Corner, jetzt hast du einen neuen Zusatzjob an der Backe, wo sie dich damals in einen, ich glaube, Arbeitskreis oder so reinstecken wollten, wo du sagen konntest, okay, ja können wir machen, aber da sitzt der Herr Pfingsten, der kriegt sein Geld, ob ich jetzt da in den Call gehe oder nicht. Und dann ist so ein Nachdenken bei deinen Chefs im Kopf passiert. „Ja, Herr Wetter, gehen Sie besser noch mal zum Herrn Pfingsten, das ist schon okay“, wo du merktest, das hat für dich noch mal auf einer ganz anderen Ebene einen Hebel. Wie war das? Wie siehst du das?

Christoph: Ja, der Vorteil an der Flatrate war einfach am Anfang, dass wir so unbedarft einfach anfragen konnten, ohne mir Gedanken zu machen, muss ich da jetzt schon wieder 500 Euro plus, minus irgendwo verbuchen oder dann wieder meinen Chef fragen, da brauche ich noch Budget, weil ich da noch mal oder ich habe da noch mal mehr gebraucht, wie ich eigentlich geplant hatte. Das hat halt uns relativ auf der Kostenseite sehr viel Sicherheit gegeben und wir konnten einfach darauf los fragen und mussten nicht überlegen, jetzt sind es schon wieder, jetzt ist die Zeit schon wieder abgelaufen. Es war so ein, insbesondere weil wir halt doch alle blutige Anfänger waren auf dem Thema und das bietet sich so am Anfang schon einfach an, weil man den Druck da herausnimmt und extrem viele Freiheiten hat und man kann natürlich eben auch dann wiederum die Karte spielen, wir haben uns jetzt dazu committed, wir ziehen das durch, wir zahlen auch dafür. Management, bitte lasst uns das jetzt auch konsequent durchziehen und zieht uns da nicht ab und lassen wir die Kohle da brach liegen. Das hat so zwei Vorteile. Aber der größte, sehe ich schon, in dem Punkt, wir können einfach fragen und zwar egal wann, egal wie, egal wie oft.

Maik: Stimmt, das habt ihr auch gerade am Anfang sehr positiv wahrgenommen, dass ihr wirklich viel genutzt habt. Das waren jetzt so die ersten eineinhalb Jahre, wo ich dich und dein Projekt begleitet habe und dann ist ja etwas entstanden, also da war das Projekt abgeschlossen im Grunde, also das Mentoring, das Projekt war nicht abgeschlossen. Es ging ja jetzt in die Umsetzung und in den Test und so weiter. Da seid ihr ja gerade im Launch in Richtung Markt. Aber du kamst dann damals mit einem Gedanken auf mich zu, nach den eineinhalb Jahren, erinnere ich mich noch gut, wo du sagtest, „hör mal ich habe mit meinen Chef gesprochen, wir haben da eine Idee, wir gehen da einen neuen Weg. Kannst du mich da unterstützen?“ Was ist damals passiert?

Christoph: Ja, was damals passiert ist? Bei uns in der Firma gibt es natürlich Gruppen, die sich rein um diese Prozesse und so weiter kümmern. Was wir aber hier festgestellt haben, dass oftmals diese Leute extrem weit von den Projekten weg waren. Und dann kam so die Idee, wäre es vielleicht sinnvoll, dass wir hier intern bei uns in der Projektleitergruppe so eine Art eigenen Mentor haben, der diese Philosophie in die einzelnen Projekte quasi hineinträgt. Es gibt da wirklich spezifisch um dieses Thema Requirements Engineering und wie können wir die Projekte intern bei uns motivieren, begeistern, unterstützen, supporten und muss das immer ein Externer sein oder können wir das auch als eine interne Stelle definieren und zwar nicht eine Vollzeit, sondern ganz spezifisch nur einen Teil des Jobs, weil wir gesagt haben, es macht natürlich Sinn, dass diese Person auch weiterhin selber Projekte bearbeitet und immer am Puls der Zeit ist und nicht irgendwo aus dem Projekt-Alltag herausfällt, weil das eine ist reines Consulting und das andere ist reine Projektleitung und wir haben gesagt, vielleicht macht so eine Mischstelle ja ganz viel Sinn, weil man hat einfach auch diese Tücken und Schwierigkeiten im Projektmanagement einfach hautnah und kontinuierlich miterlebt. Und da kam einfach so dieser Gedanke auf, vielleicht sollten wir uns überlegen so etwas bei uns intern aufzubauen.

Maik: Also ich erinnere mich auch gerade sehr gut an diese Zeit, wo du dann auch auf mich halt  zu kamst und sagte auf der einen Seite, ihr habt genau diese Gespräche geführt und die Entscheidung zusammen mit deinen Chefs war eben halt, du gehst dieser Rolle als Person dann auch in diese Richtung, als interner Mentor in Richtung System Engineering und zum einen hast du direkt die klare Frage gestellt so, Weiterbildung zu einem Systems Engineering, ob ich das machen könnte oder ob ich da eine Empfehlung hätte und auf der andere Seite eben halt den Wunsch noch mal quasi im Anschluss eine Begleitung als Mentor. Also ist schon ganz lustig. Als Mentor fürs Mentoring, also quasi, dass du eben in diese Rolle hineinwachsen kannst und von mir das ganze Handwerkszeug lernst, dass du selbst als Mentor intern starten kannst. Und da haben wir damals darüber gesprochen, dass ich dir sehr empfohlen habe die Systems-Engineering-Weiterbildung von der GfSE, also im Incose dieser Weltverband zu machen, weil das aus meiner Sicht eine sehr gute, sehr umfangreiche Fortbildung ist. Und ich werde auch immer wieder gefragt, ist das was? Kann man da hingehen? Wie war deine Erfahrung? Wie war dein Erlebnis? Was hast du da so an Highlights?

Christoph: Also das Highlight? Das waren alles Highlights. Wie gesagt, ich hatte ja mit, ich bin ja so Quereinsteiger in das Thema Requirements Engineering und dann kam eben dieses Thema System Engineering so ein bisschen ins Spiel und ich war dann auf dieser Schulung für den Level C in Hamburg. Das war extrem genial. Ich habe so viele Leute kennengelernt, die mit den gleichen Themen zu tun haben und man hat erstmal auch, ich sage mal so, ein Eye-Opener war das, es dreht sich nicht nur alles um die Anforderungen, sondern es sind so viele Themen und so viele Perspektiven und Sachen, die man eigentlich als System-Engineer betrachten sollte und auch kann. Da kann man ein ganzes Berufsleben, glaube ich, mit füllen. Und für mich war eigentlich dann der Punkt, wo mir dann der Maik auch wieder extrem geholfen hat, okay, welche Themen sind denn jetzt für uns vielleicht die gewinnbringendsten, weil man kann nicht immer alles auf einmal machen und alles super und perfekt, sondern man muss ich einfach auch fokussieren und konzentrieren und durch diese Diskussion, die wir zwei geführt haben, Maik, haben wir natürlich ein bisschen die Fokuspunkte herausgearbeitet, wo wir gesagt haben, an der Stelle, an der Stelle und an der Stelle sehen wir eigentlich einen großen Benefit für uns in der Company. Das können wir auch gut transportieren. Da müssen wir nicht alles neu erfinden, aber wir können hier ganz viel Knowhow und Wissen bei uns in die Firma hineinbringen. Und das war eigentlich das, was wir dann in der letzten Zeit eigentlich so ausgearbeitet haben, wie können wir das Thema System-Engineering hier stärken? Und wie können wir das transportieren? Und welche Elemente nutzen wir aus dem ganzen Sammelsurium und aus der ganzen Vielfalt dieses Themas und was ist am gewinnbringendsten für uns?

Maik: Wir sind ja jetzt im Sommer 2017 und sind jetzt quasi an dem Punkt, wo dieser zweite Teil, also das Mentoring und den Aufbau deiner Rolle als internen Mentor quasi abgeschlossen haben und gerade so in den letzten, ich sage mal, zwei, drei Wochen kam das richtig wunderschön auf den Punkt mit dieser Roadmap, wo du ja jetzt, aus meiner Sicht, das ganze Handwerkszeug an der Hand hast, dass du eben in diese Rolle einsteigst oder es ja auch schon tust. Zum Beispiel jetzt im Moment, du hast ja auch schon aktiv einige Sachen, wo du Dinge da bei euch intern vorantreibst. Wir haben ja dann diese Roadmap, wie kannst du zukünftig als Mentor eure internen Projekte aufnehmen? Wie macht ihr das Onboarding? Wie sind die verschiedenen Phasen? Sodass ich auch ein super gutes Gefühl habe als Mentor nach der Zeit, dich dort quasi dann auch laufen lassen zu können, also das du alles hast und ich das Gefühl habe du kannst es auch super umsetzen. Wenn jetzt jemand sagt, ich bin mir nicht sicher, ich weiß nicht, ist das was für mich? Ist das nichts für mich? Jetzt völlig unabhängig davon, ob das jetzt nun Geschichte ist, ich als externer Mentor begleite dich als Menti im Unternehmen oder eben halt du jetzt in Zukunft ja, und das ist das, was ich so genial finde, den Schritt, den ihr da geht eben, dass ihr diesen internen Mentor als Rolle mit dir aufbauen für die Projekte, sodass dort eben dieser Wissenstransfer können die Projekte gleich von Anfang an die richtige Richtung laufen. Was würdest du jemandem sagen, der sich nicht sicher ist, ob das Mentoring wirklich für ihn einen Nutzen hat?

Christoph: Das ist eine gute Frage. Ich glaube es hängt vielleicht auch ein bisschen an der Persönlichkeit, ob das das richtige ist. Ich glaube, ob das für jeden das Richtige ist, das weiß ich nicht. Wichtig ist vor allem, dass man am Anfang ein eigenes Interesse da an das Thema heranbringt. Wenn man hingeschickt wird und sagt, jetzt macht du mal das und wir bezahlen dir den Maik und der macht jetzt Mentor für dich. Ich weiß nicht, ob das der richtige Ansatz ist, weil dann wird man ein bisschen gezwungen. Bei mir war es eigentlich eher so herum, es kam sehr viel aus viel Eigeninteresse und Eigeninitiative. Und das Schöne halt an der ganzen Geschichte ist, man kann da mit dem Maik so gute Dialoge und so gute, ich sage, Dialoge führen über die Sache und Erfahrungen austauschen und dann ist das Mentoring extrem gewinnbringend, weil man einfach selber Interesse hat und ich möchte mich selber in dem Thema, ich möchte selber darin aufleben und möchte selber da etwas lernen. Das ist für mich, glaube ich, das ist ganz wichtig, dass man sowas mitbringt. Nur weil es von außen gesagt wird, du musst das jetzt machen, hat das, glaube ich, extrem wenig oder wenig Benefit, weil man muss natürlich auch regelmäßig selber an dem Thema selbstständig daran arbeiten und diese Sachen auch selbstständig wieder zum Maik in die Diskussionen mit zurück bringen. Weil, wenn man das nicht macht, kann der Maik auch nur da sitzen und sagen, ja mache mal das, mache mal das, mache mal das und das Gegenüber nickt halt dann und sagt, ja vielleicht eventuell. Ich glaube, das wäre vielleicht so als Persönlichkeit vielleicht ganz wichtig, das man da mitbringt. Und man braucht natürlich auch den Support aus der Firma. Und da kann ich nur sagen, steter Tropfen ölt den Stein. Das hat bei uns auch so angefangen. Da waren auch zuerst ganz viele Bedenken, schon damals mit dem RE und ich habe einfach gesagt, nein, ich will das jetzt machen. Nein ich will das jetzt machen, da dieses, das geht nicht  und dann muss man sich halt irgendwelche Umwege suchen, die es dann halt doch möglich macht. Da muss man schon hartnäckig bleiben und das zahlt sich am Ende dann aus. Das wären so meine zwei Punkte. Man muss Eigeninitiative haben oder drei Punkte. Man muss Rückgrat haben und man muss das einfach durchziehen wollen und dann wird es eine extrem coole Geschichte, weil dann lernt man den Maik auch richtig gut kennen und dann gibt er einem auch die richtig guten Tipps. Sonst gibt er sie nicht weiter.

Maik: Ja, Christoph, jetzt haben wir eine ganze Menge über das Mentoring im Projekt gesprochen, also diese ersten eineinhalb Jahre. Und dann jetzt eben dann auch über das Mentoring, um quasi dich in deiner internen Rolle für die Zukunft da aufzubauen als Mentor in deinem Unternehmen. Haben wir noch irgendwas vergessen?

Christoph: Was wir noch vergessen haben? Ist eine gute Frage. Was halt cool ist, vielleicht noch zusätzlich. Maik hat halt noch so unglaublich viele andere Kontakte und er kann einen auch an irgendwelche Leute weiterleiten und Verbindungen herstellen, die dann vielleicht zu Themen kommen, die so im Laufe der Zeit so immer mal wieder aufpoppen. Sei es zu irgendwelchen Themen a, wir wollen jetzt eine neue Software einführen und dann sagt Maik, da kenne ich auch jemand und er kann dann die Leute zusammenbringen und die können dann einfach so einen Erfahrungsaustausch auf einer anderen Ebene gehen. Dafür ist der Maik halt super als Kontaktgeber. Das schätze ich sehr, weil man oft dann bei solchen Themen dann möglicherweise in der Firma ein bisschen allein gelassen wird oder man wurschtelt halt einfach in der eigenen Suppe und wenn man solche Themen einfach mit anderen Externen austauschen kann, hilft das einem ungemein weiter. Das ist so ein Punkt, den finde ich schon noch wirklich nennenswert, was mir jetzt so spontan noch einfällt.

Maik: Wunderbarer Punkt. Das stimmt. Wir haben gerade die letzten zwei, drei Sessions auch noch mal darüber diskutiert. Ich weiß, ich habe dich auch mit einem Entscheider in einem anderen Unternehmen mal zusammengebracht, wo ihr nämlich beide an dem gleichen Problem herum arbeitet oder gleichen Tool, war es glaube ich?

Christoph: Ja.

Maik: Genau. Ja, wenn jetzt jemand noch Fragen hat oder denkt, dieser Austausch ist interessant oder ich gehe auch gerade diesen Weg und das, was der Christoph da macht, ist eine interessante Sache, würde ich natürlich gerne die Möglichkeit den Hörern geben, dich zu finden. Was wäre wahrscheinlich der beste Anlaufpunkt, den ich auch hinterher hier in die Shownotes packen kann?

Christoph: Wo man mich finden kann?

Maik: Ja.

Christoph: Ja, am besten ist, frage den Maik, der hat meine Adresse, der hat meine E-Mail, der hat meine Telefonnummer und der soll die an euch einfach weiterleiten. Wie wäre das?

Maik: Ja, können wir machen. Ist ja im Grunde auch das, was wir letztens ja schon besprochen haben, dass ich dann die Kontakte. Also wenn ihr irgendwie Fragen habt an den Christoph, wenn ihr Gedanken habt und mit Christoph den Kontakt gerne mal sucht euch auszutauschen, sprecht mich einfach an und dann stelle ich den Kontakt zwischen euch her. Gut. An der Stelle, es war mir eine Freude, es war mir eine Ehre. Schön, dass du hier im Podcast mit dabei warst und auch mal so ein bisschen aus deiner Sicht erzählt hast, was Mentoring ist und wo die Reise da hingehen kann. An dieser Stelle, vielen, vielen Dank Christoph.

Christoph: Maik, bitte gern geschehen. Es hat mir auch sehr viel Spaß und Freude bereitet mit dir die letzten Jahre zusammenzuarbeiten und ich freue mich schon, wir werden uns im Herbst ja in Köln treffen.

Maik: Genau. Genau. Wir sehen uns im Herbst wieder auf dem Requirement Engineering Camp und werden mit Sicherheit wieder einige Gedanken spinnen und Ideen und Fragen haben. Genau. Ja. Super. An dieser Stelle vielen Dank Christoph.

Christoph: Dir auch Maik.

On Air in dieser Episode

avatar
Maik Pfingsten
avatar
Christoph Wetter

ZA106 - Zwei alte Hasen im Troubleshooting tauschen sich aus

02.10.2015 56 Minuten



Zusammenfassung

Zwei alte Hasen im Troubleshooting tauschen sich aus

Was sind die Erkenntnisse aus über 10 Jahren Troubleshooting, wenn sich zwei alte Hasen austauschen?

Ich sitze mit Georg Lohrer zusammen und wir unterhalten und über die Erfahrungen, die wir als Troubleshooter in über 10 Jahren gemacht haben. Wir geben Tipps und Tricks weiter, damit Projekte nicht in Schieflage geraten.

Der Inhalt

  • Was bedeutet für dich Troubleshooting?

  • Warum müssen sich Firmen und Mitarbeiter auf internationale Zusammenarbeit einstellen?

  • Welche Erfahrung hast du mit Führung im internationalen Kontext?

  • Du hast jetzt einen Podcast Mastering Embedded Systems gestartet. Warum hast du damit begonnen?

Hinweise in der Episode

 

On Air in dieser Episode

ZA092 - Wie finde ich wirklich gute Spezialisten?

10.07.2014 00:00:00.000 Stunden 00:00:00.000 Minuten



Zusammenfassung

In den letzten Monaten haben mich viele Entscheider aus Unternehmen angesprochen und nach Unterstützung gefragt. Es ging um Speaking-Gigs, Coaching vor Ort, Web-Coaching, Erstellen von Lastenheften, Review von System-Architekturen, Moderation von System Footprint Workshops, Projektleitung, Functional Safety und so weiter …

Mein Problem ist nur, ich kann mich nicht teilen und musste so viele Anfragen ablehnen – ohne das ich eine guten Vorschlag machen konnte, der vielleicht weiter hilft.

Gleichzeitig bin ich auf vielen der letzten Hörertreffen mit Freiberuflern ins Gespräch gekommen. Meistens langjährig berufserfahrene Ingenieure, die sich schon im Systems Engineering bewegt haben. Diese haben mich angesprochen, ob ich einen Tipp habe, wo es vielleicht ein spannendes Projekt oder einen guten Kontakt gibt.

So reifte in den letzten Wochen die Idee, wie ich die Plattform des Podcast nutzen kann, um euch zusammen zu bringen.

Der Inhalt dieser Episode:

  1. Warum ist das zueinanderfinden (Entscheider in Unternehmen + freiberuflichen Spezialisten) oft so schwierig?
  2. Wie wird das Problem typischerweise gelöst?
  3. Was ist meine Idee es anders zu machen?
  4. Wie könnt ihr als Entscheider profitieren?
  5. Wie könnt ihr als Freiberufler profitieren?

Hinweise in der Episode:

Was wäre euch wichtig bei der Weiterentwicklung der Projektbörse? Schreibt mir eine Mail an feedback@zukunftsarchitekten-podcast.de

Subscription link

Wenn Euch der Podcast gefällt, abonniert Ihn und erhaltet zukünftig kostenlos alle neuen Episoden direkt auf Eurer Smartphone:

iTunes | RSS

Wenn euch die Episode gefallen hat, bitte bewertet sie bei iTunes und schreibt eine ehrliche Meinung. Das würde sehr helfen, die Commuity zu erweitern! Danke.

 

On Air in dieser Episode

ZA087 - Von der Anforderungsliste zum semantischen Lastenheft – Wie kann ich Spezifikationen miteinander verknüpfen?

08.05.2014 00:00:00.000 Stunden 00:00:00.000 Minuten



Zusammenfassung

Lastenhefte in komplexen Systemen können einen Umfang einnehmen, der nicht so ohne weiteres handbar ist. Gerade wenn auch noch das Variantenmanagement mit hinzu kommt. Durch den Einsatz der semantischen Verknüpfung und der Fundamental Modeling Concepts können wir dieser Herausforderung entgegentreten. Ich bin im Gespräch mit Dr. Oskar v. Dungern, der sich seit Jahren mit dieser Methode beschäftig und sie in der Praxis einsetzt.

Der Inhalt dieser Episode:

  1. Warum ist semantische Verknüpfung so hilfreich?
  2. Was sind Probleme im Umgang mit komplexen Lastenheften?
  3. Was kann Fundamental Modeling Concepts bewirken?
  4. Wie kann ich Traceability verbessern?

Oskar v. Dungern im Netz

Buchempfehlung aus der Episode

Subscription link

Wenn Euch der Podcast gefällt, abonniert Ihn und erhaltet zukünftig kostenlos alle neuen Episoden direkt auf Eurer Smartphone:

iTunes | RSS

Euer Feedback

Wenn ihr eine Idee habt für den Podcast oder eine Frage für eine der zukünftigen Episoden, schreibt mir eine Mail an feedback@zukunftsarchitekten-podcast.de

Wenn euch die Episode gefallen hat, bitte bewertet sie bei iTunes und schreibt eine ehrliche Meinung. Das würde sehr helfen, die Commuity zu erweitern! Danke.

On Air in dieser Episode

ZA084 - Systems Engineering erfolgreich einführen - Do's and Don'ts

03.04.2014 00:00:00.000 Stunden 00:00:00.000 Minuten



Zusammenfassung

Ich erhalte in letzter Zeit einige Fragen von Entwicklungsleitern und Managern, wie Systems Engineering am Besten einzuführen ist. Parallel erlebe ich viele kontroverse Diskussionen, wenn es um das richtige Vorgehen geht. In dieser Episode fasse ich meine Erfahrungen zusammen. Ihr erfahrt, in welchen verschiedenen Situationen die Unternehmen stecken können und welche Do’s and Dont’s es gibt, um Systems Engineering erfolgreich umzusetzen.

Der Inhalt dieser Episode:

  1. Warum macht Systems Engineering Sinn?
  2. Warum ist das Einführen nicht so einfach?
  3. In welchen Situationen stecken Unternehmen gerade?
  4. Wie kann Systems Engineering erfolgreich eingeführt werden?
  5. Was sind die Do’s and Don’ts?

Hinweise in der Episode:

Subscription link

Wenn Euch der Podcast gefällt, abonniert Ihn und erhaltet zukünftig kostenlos alle neuen Episoden direkt auf Eurer Smartphone:

iTunes | RSS

Euer Feedback

Wenn ihr eine Idee habt für den Podcast oder eine Frage für eine der zukünftigen Episoden, schreibt mir eine Mail an feedback@zukunftsarchitekten-podcast.de

Wenn euch die Episode gefallen hat, bitte bewertet sie bei iTunes und schreibt eine ehrliche Meinung. Das würde sehr helfen, die Commuity zu erweitern! Danke.

Frage: Wie ist die Situation in eurem Unternehmen?

On Air in dieser Episode

ZA080 - Wie gestalte ich wirkungsvolle Präsentationen?

13.02.2014 00:00:00.000 Stunden 00:00:00.000 Minuten



Zusammenfassung

Ich bin im Gespräch mit Karin Widera. Sie ist Journalistin und kümmert sich um Vorträge von Führungskräften deutscher DAX Unternehmen. Wir unterhalten uns über Präsentationen und Sie gibt uns Tipps und Tricks, wie techniklastige Präsentation besser wirken können.

Inhalt dieser Episode:

  1. Warum sind Präsentationen so grausam?
  2. Wie kann ich meine Folien verbessern?
  3. Was sind typische Fallstricke?
  4. Wie kann ich mit einfachen Mitteln schon viel bewirken

Verweis auf weitere Episode

Subscription link

Wenn Euch der Podcast gefällt, abonniert Ihn und erhaltet zukünftig kostenlos alle neuen Episoden direkt auf Eurer Smartphone:

iTunes | Zune | RSS

Euer Feedback

Wenn Ihr eine Idee habt für den Podcast oder eine Frage für eine der zukünftigen Episoden, schreibt mir eine Mail an feedback@zukunftsarchitekten-podcast.de

Wenn Euch die Episode gefallen hat, bitte bewertet sie bei iTunes und schreibt eine ehrliche Meinung. Das würde sehr helfen, die Commuity zu erweitern! Danke.

On Air in dieser Episode

ZA073 - Mechatronik vs. Systems Engineering

19.12.2013 00:00:00.000 Stunden 00:00:00.000 Minuten



Zusammenfassung

Widersprechen sich Mechatronik und Systems Engineering? Ist es einfach nur die gleiche Idee unter zwei verschiedenen Begriffen? In dieser Episode erläutere ich die Herkunft und die Denke der Mechatronik und des Systems Engineering und beleuchte, wie beide zusammen hängen und was sie unterscheidet.

Die Themen der Episode:

  1. Warum gibt es Mechatronik?
  2. Warum gibt es Systems Engineering?
  3. Wie hängen die Beiden zusammen?
  4. Was bedeutet das für mittelständische Unternehmen?
  5. Mein Gedanken über die gemeinsame Zukunft beider Sichten

Hinweise in der Episode:

Subscription link

Wenn Euch der Podcast gefällt, abonniert Ihn und erhaltet zukünftig kostenlos alle neuen Episoden direkt auf Eurer Smartphone:

iTunes | Zune | RSS

Euer Feedback

Wenn Ihr eine Idee habt für den Podcast oder eine Frage für eine der zukünftigen Episoden, schreibt mir eine Mail an feedback@zukunftsarchitekten-podcast.de

Wenn Euch die Episode gefallen hat, bitte bewertet sie bei iTunes und schreibt eine ehrliche Meinung. Das würde sehr helfen, die Commuity zu erweitern! Danke.

Frage: Wie wird Systems Engineering oder Mechatronik bei euch eingesetzt?

On Air in dieser Episode

ZA062 - Wie kann ich beim Troubleshooting richtig starten?

03.09.2013 00:00:00.000 Stunden 00:00:00.000 Minuten



Zusammenfassung

Bei einem Vortrag kam anschießend die Frage der Teilnehmer auf, wie ich als Troubleshooter starte, wenn ich ein Projekt übernehme. Es war das erste mal, dass ich meine Vorgehensweise als Skizze auf einem Whiteboard aufmalte. Daraufhin habe ich mir das Thema für den Podcast gemerkt und eine eigene Episode geschaffen, in der ich mein Vorgehen als Troubleshooter erkläre. Zum Abschluss gebe ich noch ein paar Tipps im Umgang mit Taskforces.

Die Themen der Episode:

  • Phase 0 (< Startpunkt X): Macht Troubleshooting überhaupt Sinn?
  • Phase 1 (Erste 2 Wochen): Lage sichten, Strategie entwickeln
  • Phase 2 (Erster Release-Cycle): Erste Ergebnisse schaffen und lernen
  • Phase 3 (Zweiter Release-Cycle): Verantwortung übergeben
  • Phase 4 (Dritter Release-Cycle): Troubleshooting abschließen

Hinweise in der Episode:

Phase 0 (< Startpunkt X): Macht Troubleshooting überhaupt Sinn?

Phase 1 (Erste 2 Wochen): Lage sichten, Strategie entwickeln

  1. Schritt – Kontakt aufbauen
  2. Schritt – Unterlagen sichten
  3. Großes Bild schaffen
    System Footprint: Episode #4: The System Footprint – Anforderungen strukturieren und visualisieren
  4. Strategie aufbauen
  5. Team aufbauen
  6. Commitment des Management einholen

Phase 2 (Erster Release-Cycle): Erste Ergebnisse schaffen und lernen

  • Leadership aufbauen
  • Sprintgedanken lernen
  • Kommunikation lernen
  • Retrospective lernen
  • Schnelles Testen lernen
  • Ergebnisse liefern lernen
  • Management abschirmen
  • Team formen – Nay-sayer aussortieren
  • Taktik überprüfen
  • Zweiten Release-Cycle planen

Mein Tipp: Holt Euch einen Mentor mit dazu (intern/extern)

Phase 3 (Zweiter Release-Cycle): Verantwortung übergeben

  • Vorgehen stabilisieren
  • Vereinfachen
  • Ich werde nicht mehr gebraucht

Phase 4 (Dritter Release-Cycle): Troubleshooting abschließen

  • Das muss ein Ende haben
  • Große Retrospektive durchführen
  • QA einbinden zum Überdenken der Prozesse
  • Management einbinden zum Überdenken des Leadership

Mich live als Speaker treffen

Subscription link

Wenn Euch der Podcast gefällt, abonniert Ihn und erhaltet zukünftig kostenlos alle neuen Episoden direkt auf Eurer Smartphone:

iTunes | Zune | RSS

Euer Feedback

Wenn Ihr eine Idee habt für den Podcast oder eine Frage für eine der zukünftigen Episoden, schreibt mir eine Mail an feedback@zukunftsarchitekten-podcast.de

Wenn Euch die Episode gefallen hat, bitte bewertet sie bei iTunes und schreibt eine ehrliche Meinung. Das würde sehr helfen, die Commuity zu erweitern! Danke.

Frage: Wie ist Eure Erfahrung mit Troubleshooting?

 

On Air in dieser Episode