#4 Implementierung – Woran scheitern MBSE-Initiativen?

Shownotes

Warum scheitern eigentlich so viele MBSE-Initiativen – und wie lässt sich das verhindern? In dieser Folge nehmen wir die typischen Stolpersteine bei der Einführung von modellbasiertem Systems Engineering unter die Lupe.

Gemeinsam mit Prof. Dr. Martina Königbauer (TH Augsburg) und Martin Schelkle (Rohde & Schwarz) sprechen wir über konkrete Erfahrungen aus Forschung und Praxis: von kulturellen Hürden über fehlende Methodenkompetenz bis hin zu unrealistischen Erwartungen an Tools und Prozesse.

Dabei wird schnell klar: Die Liste der möglichen Fallstricke ist zwar lang, aber oft überraschend gut beherrschbar. Wer die häufigsten Fehler kennt, kann sie frühzeitig erkennen – und gezielt vermeiden. Eine Folge für alle, die MBSE nicht nur verstehen, sondern erfolgreich im Unternehmen etablieren wollen – praxisnah, ehrlich und mit klaren Handlungsempfehlungen.

Weitere Informationen zu dieser und weiteren Folgen des Podcast MBSE: https://www.vde-bayern.de/de/facharbeit-regional/netzwerk-mbse/podcast-mbse

Weitere Informationen zum Netzwerk MBSE im VDE Bayern: https://www.vde-bayern.de/de/facharbeit-regional/netzwerk-mbse

Zu Gast:

Prof. Dr. Martina Königbauer (TH Augsburg): https://www.linkedin.com/in/martinakoenigbauer/

Martin Schelkle (Rohde & Schwarz): https://www.linkedin.com/in/martin-schelkle-587155a7/

Der Podcast des Netzwerks MBSE ist eine Produktion des VDE Bayern. Sprecher des Netzwerks MBSE sind Hans Krautlager (hans.krautlager@vde-online.de und Thomas Gessner (thomas.gessner@de.zuken.com

Abonniere unseren Podcast, um keine Folge rund um das Thema MBSE mehr zu verpassen!

Unsere Social Media Kanäle: Instagram: vde.com/instagram LinkedIn VDE: vde.com/linkedin Facebook: vde.com/facebook

Der VDE, eine der größten Technologie-Organisationen Europas, steht seit mehr als 130 Jahren für Innovation und technologischen Fortschritt. Als einzige Organisation weltweit vereint der VDE dabei Wissenschaft, Standardisierung, Prüfung, Zertifizierung und Anwendungsberatung unter einem Dach. Das VDE Zeichen gilt seit mehr als 100 Jahren als Synonym für höchste Sicherheitsstandards und Verbraucherschutz.

Wir setzen uns ein für die Forschungs- und Nachwuchsförderung und für das lebenslange Lernen mit Weiterbildungsangeboten „on the job“. Im VDE Netzwerk engagieren sich über 2.000 Mitarbeiterinnen an über 60 Standorten weltweit, mehr als 100.000 ehrenamtliche Expertinnen und rund 1.500 Unternehmen gestalten im Netzwerk VDE eine lebenswerte Zukunft: vernetzt, digital, elektrisch. Wir gestalten die e-diale Zukunft.

Sitz des VDE (VDE Verband der Elektrotechnik Elektronik und Informationstechnik e.V.) ist Frankfurt am Main. Mehr Informationen unter www.vde.com

Transkript anzeigen

00:00:12: Willkommen

00:00:12: zu Next Generation

00:00:14: Engineering, dem Podcast des Netzwerks MWSE im VDE Bayern.

00:00:20: Hier sprechen wir über aktuelle Themen und Herausforderungen in der Produktentwicklung und darüber wie ein modellbasiertes Vorgehen helfen kann.

00:00:30: Viel Spaß beim Zuhören!

00:00:31: Damit herzlich willkommen zur vierten

00:00:33: Folge unseres

00:00:35: Podcasts Next Level Engineering aus dem Netzwerk MWSe im VDE Bayern.

00:00:40: Mein Name ist Thomas Gessner, ich begrüße Sie ganz herzlich zu dieser Folge.

00:00:43: Und bei mir die mitwirkenden und Hauptgestaltenden dieser Folge sind Prof.

00:00:49: Martina König-Bauer bekannt aus dem Ersten und Zweiten Podcast.

00:00:54: Und ebenso bekannt aus den Ersten & Zweiten podcast Martin Schädtel von Roter&Schwarz.

00:00:59: Herzlich willkommen euch beide!

00:01:01: Wir sind eigentlich schon hier fast eine halbe Stunde dabei zu erzählen und uns über die Köpfe heißt zu reden.

00:01:07: Und dabei kam schon eine eigene Literaturempfehlung raus, zu einem Thema was heute heißt woran scheitern MSE-Initiativen?

00:01:14: Und interessanterweise die Literatur.

00:01:16: Empfehlung, die wir uns gerade an den Kopf geworfen haben.

00:01:18: Die habe ich mit der MSE gar nichts zu tun gehabt.

00:01:20: Da war von dem Martin acht Regeln für völligen Stillstand von Prof.

00:01:26: Kraus.

00:01:29: Was haben wir noch diskutiert?

00:01:34: Achieve

00:01:35: greatness, genau.

00:01:37: Und dann haben wir ... Martina, du hattest eingeworfen die Anleitung zu Unglücklichsein von dem, glaub ich von uns allen sehr verehrten Paul Watzler weg.

00:01:45: Genau.

00:01:46: Damit fang' ich mal an!

00:01:48: Wir können natürlich diesen Podcast, diese Folge auch nennen was muss ich tun damit ein MBSE-Projekt richtig gut funktioniert?

00:01:55: Man hat damals aber als Paul Lotz halt dieses Buch rausgebracht, das hat man eingefragt.

00:01:59: Sag mal, wieso haben Sie denn dieses Buch Anleitung zum Unglücklichsein genannt?

00:02:04: Und wie so nennen wir diese Folge, woran können MBE-Projekte und Initiativen scheitern?

00:02:10: Nun, Paul Watzlamik hat es damals so beantwortet.

00:02:12: Ich sagte, hätte ich das Buch genannt Anleitung zum Glücklichsein?

00:02:16: Niemand hätte's gelesen!

00:02:18: Und so denke ich mal hoffe auch, dass gibt den Zugehörerinnen mit dem Podcast heute auch dass wir sagen, woran können MBC-Initiativen scheitern?

00:02:27: Ist vielleicht die größere Schlagzeile als wie stelle ich sicher, dass sie nicht scheitert.

00:02:31: Damit sind wir eigentlich schon mitten im Thema und ich glaube, wir haben für uns selber so im Kopf eine ganz lange Liste mit Fremderfahrungen und vielleicht auch teilweise auch selbst Erfahrungen wo andere Initiativen Scheitern können.

00:02:46: Vielleicht gehen mal ganz kurz mal in durch die Runde durch.

00:02:51: was sind denn so?

00:02:53: Ich hätte es fast gesagt Top drei, aber fangen wir doch einfach mit einem prägnanten Grund an der euch spontan einfällt oder der vielleicht ganz oben auf der Liste steht.

00:03:03: Was ist so einer der offensichtlichen Gründe warum?

00:03:08: MBE-Initiativentscheid hat vielleicht, Martina du hast eine ganz lange Liste.

00:03:11: Deswegen

00:03:12: frage ich dich mal als erstes genau.

00:03:15: Also bei dem heutigen Podcast muss ich meine Gedanken ein bisschen sortieren anders als mit den ersten beiden wo wir ja so fröhlich drauf los gesprochen haben.

00:03:22: Weil ich würde sagen gibt es immer zwei Perspektiven die man mit berücksichtigen muss.

00:03:28: das eine ist das sind Punkte die auch bei anderen Change oder Veränderungsinitiativen wenn man so möchte relevant wären.

00:03:36: also können wir jetzt auch über andere Themen übertragen.

00:03:39: und dann gibt es die, die wirklich modellspezifisch sind.

00:03:41: Wo man sagt ist das dann wirklich sehr spezifischer auf MBSE ausgerichtet.

00:03:46: Und ganz

00:03:48: oben als

00:03:49: Toppunkt der allgemeinen Punkte, die zum Scheitern führen können oder eigentlich so eine Initiative schon zum Scheidern vorgeralten ist wenn man nicht weiß warum man das eigentlich macht.

00:03:59: also was soll am Ende der Nutzen einer modelbasierten Herangehensweise sein?

00:04:05: und damit auch verbunden auf der Top-Liste sehr spezifischen Punkte im Bereich MBSE.

00:04:12: Wenn ich nicht weiß, was soll da nutzen?

00:04:15: Der Modell ist sein dann baue ich die vielleicht oder dann bau ich sie zum Selbstzweck und das würde ich sagen ist ja die beste Vorbereitung zum Scheitern eines solchen Vorhabens.

00:04:28: Warte wie siehst du das?

00:04:30: Also ich werde einen Punkt nochmal einstatt zurückgehen weil der Punkt ist ganz wichtig.

00:04:35: Man vergisst meistens, dass es auch ein Change ist

00:04:38: und eine

00:04:38: Transformation.

00:04:39: Also speziell wenn man aus dem Dokumentenbasierten System Engineering kommt wird oftmals angenommen das man ja ganz häufig nur einen Tool einführt was an sich schon falsch war ein BSE zwar tools bedingt oder Tools benötigt aber eigentlich eine Methodik ist Das Thema hat man schon mal in der früheren Runde ausgebig diskutiert Diese Transformation, diesen Change ganz oft vernachlässigt und nicht berücksichtigt.

00:05:07: Und der zweite Punkt, der für mich ganz wichtig ist,

00:05:11: vielleicht

00:05:11: gar nicht so sehr die Frage was oder warum will ich es tun?

00:05:16: Sondern viel mehr die Frage, was konkret will ich eigentlich tun?

00:05:20: Also MBE ist ja ein riesiges Feld

00:05:23: da kann ich

00:05:23: ganz viele Dinge tun.

00:05:25: Was ich häufig feststelle ist dass man sich nicht die Mühe macht zu überlegen, was brauche ich denn eigentlich?

00:05:32: Was aus diesem ganzen MBE-Kontext ist eigentlich das, was ich einsetzen möchte?

00:05:36: Was mir Nutzen bringt und was ich erreichen muss.

00:05:40: Ich vergleiche das gerne mit so diesen CMMI Diskussionen.

00:05:45: CMMI hat für mich einen riesen Manco und es sind diese Leveln.

00:05:48: Es gibt Level Eins bis Fünf Und wenn man jetzt fragt welches Level brauchen wir dann irgendwie chronisch kommt die fünf und es mag manchmal zutreffend sein Das mag aber in manchen Bereichen auch ein Level zwei oder drei vollkommen Hausereien sein.

00:06:03: Und genau so eine Untersuchung zu einer Analyse, welche Fähigkeiten brauche ich

00:06:08: eigentlich

00:06:08: und wie tief muss ich in das Thema reingehen?

00:06:11: Bäre

00:06:12: ist für

00:06:12: mich

00:06:13: eine Grundvoraussetzung um eine MBE-Strategie auch festzulegen.

00:06:18: Das kann in einem größeren Unternehmen durchaus unterschiedlich sein, je nachdem in welchem Kontext ich es mache.

00:06:25: Und das fehlt mir ganz häufig.

00:06:28: Ich weiss mehr über den Hanger aus.

00:06:29: Das erste was sich aushöre die Nutzenorientierung, du hast das allgemein beschrieben, Martina.

00:06:37: Du bist jetzt ein bisschen konkreter geworden in der Sache und hast gesagt okay ich muss,

00:06:42: ich sage es mal

00:06:42: in meinen Worten so die Use Cases definieren.

00:06:44: also was will ich denn eigentlich besser können?

00:06:47: Und das dann sozusagen in einzelne Packages reinpacken und dann sehe ich auch welche Fähigkeiten zu diesen, zu diesem use cases am Ende gehören.

00:06:57: Ich glaube ist das eine was ich ausgelesen habe.

00:06:59: Das andere Vielleicht habe ich da einen gewissen Bias, vor allem über Anti-Bias gesprochen.

00:07:06: Aber da ist mein Bias für mich ganz rum auf der Liste.

00:07:10: wäre so okay machen wir es zum Toolproblem.

00:07:13: also MVSE einführen ja super dazu noch mal ein Tool aus oder das für mich dass tatsächlich das negative Beispiel Anleitung zum Scheitern wäre haben.

00:07:24: jetzt hat mir mein Chef gesagt Ich muss MVCE einführen?

00:07:26: Na gut!

00:07:27: Dann hole ich mir meinen Werkstudenten und das würde die verschiedenen Tools angucken.

00:07:30: Das ist nicht untypisch, aber das wäre für mich genau das Gegenteil von Erfolg.

00:07:36: Weil man dann den Aspekt, den du gerade genannt hast, nämlich den Change und auch den Wandel in den Köpfen vom Dokumentenbasierten arbeiten, im Modellgetriebenes Arbeiten, dass den ich nur rät, weil dann ja auch Komplettung sagt okay na es sind Toolprobleme für mal ein neues Tool rein.

00:07:54: So würde ich auch noch das bisschen charakterisieren, macht das Sinn?

00:07:59: Absolut!

00:08:00: Du hast gerade eben so einen Szenario geschrieben, aus dem sich ja schon wieder weitere Punkte ableiten lassen die ein Vorheim zum Scheitern vorbereiten.

00:08:09: Wenn du sagst es wird delegiert an den wassers-duck sagt Studie oder Praktikanten dann fehlen auch da schon wieder Punkte wie z.B.

00:08:17: so ein Commitment etwas wo ich einfach nicht ins Team gebe sondern nach außen delegiere an jemanden der vielleicht mal wirklich tief integriert ist ins Team, dann ist es so ein Seitenthema das vielleicht noch nicht das nötige Commitment auch hat von der Führung im Unternehmen.

00:08:36: Und

00:08:37: was auch ein mögliches Resultat aus so etwas sein könnte, dass es zu einem Seidenthema wird – wir haben vorhin auch bevor die Mikros anwand schon darüber gesprochen -, dass plötzlich so isolierte kleine Teams oder Einzelpersonen entstehen, die ihr eigenes Süppchen

00:08:54: kochen.

00:08:56: Die Frage ist, wenn wir so vorgehen, dann machen wir ja MBE im Wesentlichen zu einem weiteren Silo.

00:09:05: Oder bestenfalls zum weiteren Siloschlimmstenfalls hat der Werkstudent mehrere Tools sich angeschaut und hat die größte Freude dabei gehabt.

00:09:13: Dann sagt man okay das ist das beste Tool!

00:09:15: Und dann erklären wir die Schlacht für gewonnen.

00:09:18: Das ist der schlechteste Fall.

00:09:20: Im Bestenfall haben wir tatsächlich irgendwo, ja wir führen das ein Ja, irgendjemand modelliert da Sachen.

00:09:28: Aber was der genau

00:09:29: macht weiß

00:09:30: kein Mensch und versteht uns dann auch keiner.

00:09:34: Also die Frage ist dann auch das geht ja schon mehr in Richtung, vielleicht in Richtung Lösung Wie schaffen wir es dass wir eben MBSE gerade nicht zu einem Silo machen?

00:09:47: Das wäre ja tatsächlich das ultimative Schaltern.

00:09:50: Wir haben es erfolgreich implementiert, wir haben eine Methode und ein Tool und Experten.

00:09:57: Und jetzt sitzt er irgendwann im Keller und modelliert von sich hin.

00:09:59: Das sind auch Sachen die man aus der Realität findet.

00:10:03: Jetzt spiele ich mal noch euch zurück.

00:10:04: Ich will nicht zu viel reden hier.

00:10:07: Seht ihr das als ein mögliches Scheitern?

00:10:10: Dass man sagt okay,

00:10:11: wir bauen da eigentlich nur ein zusätzliches Ziel auf, eine zusätzliche Komplexität auf.

00:10:17: Das wird dann irgendwie auch so gesehen vom Management, dass da eigentlich ja irgendwelche Methoden Leute irgendwas machen oder was genau die machen weiß man nicht.

00:10:26: wie sieht ihr das?

00:10:26: Ist das der reale

00:10:28: Gefahr?

00:10:29: Also für mich ist es definitiv ne reale Gefahr und was mir häufig fehlt ist in der Governance.

00:10:35: also das geht los mit Modulierungsregeln wenn ich möchte, dass möglichst viele Leute mit dem selben Modell arbeiten können.

00:10:44: Da muss ich einmal das Modell natürlich verteilen können, dass es tatsächlich erschreckend schwach gelöst bei vielen Plattformen oder Tools die es auf dem Markt gibt.

00:10:55: also dieser kollaborative Ansatz ist es tatsächlich im Doing nicht unbedingt optimal gelöst.

00:11:05: in den Datenblättern haben sie es alle stehen.

00:11:08: nutzbarkeit kann man diskutieren.

00:11:13: Das zweite Thema ist aber dann brauche ich eine Governance, ich brauche Modulierungsregeln.

00:11:17: Also wie moduliere ich?

00:11:19: was bedeutet das?

00:11:20: Und da reicht es halt nicht zu sagen wir machen SysML Version eins Punkt sieben oder jetzt Sys ML Version zwei und das ist ja nur

00:11:28: ein Rahmenwerk.

00:11:30: Ich muss für mich der Sprache definieren wie ich es benutzen möchte damit ich dann auch entsprechend das Ganze teilen kann.

00:11:39: Es geht auch dahin zu sagen, was will ich denn eigentlich sehen?

00:11:42: Also wenn wir über MBE reden haben die meisten Grafiken im Kopf.

00:11:48: Bei MBE denken ja die wenigsten an das Modell und die Datenbank die im Hintergrund liegt wo einfach nur strukturierte Daten ablegen sondern die meisten denken ja an das was du im

00:11:59: Tool

00:12:00: oder was du dann in der Visualisierung siehst.

00:12:03: Und wenn ich da aufziehe dass Visualisierungen entstehen mit dreißig, vierzig, fünfzig Elementen drauf.

00:12:12: Was kein Mensch mehr erfassen kann und genau dieser Nutzen zu sagen vielleicht einige mich darauf höchstens fünf Elemente und da gehören auch Linien dazu weil auf eine Linie ist ein Element Und mehr packe ich in einen View.

00:12:27: nicht rein Solche Grundsätze solche grundsätzlichen Festlegungen die sind aus meiner Sicht extrem wichtig damit ich dann das Ding auch tatsächlich teilen kann und mehrere Leute darauf gucken.

00:12:43: Und gerade was du ansprichst, nicht technische Disziplinen, Sales – und mögen mir jetzt alle verzeihen wenn ich sie jetzt als Nichttechnisch bezeichne aber die halt in der Materie selber nicht drin sind oder im Systemischen so nicht drin sein haben ja kaum eine Chance wirklich einen Zugang zu dem Modell zu finden.

00:13:06: Woher sage ich, mehr Chaos da wird oder mehr Irritation als wirklich

00:13:10: einen echten Nutzen?

00:13:12: An der Stelle sitze ich jetzt noch

00:13:14: eins obendrauf.

00:13:14: Ich glaube, ich habe es in einem der ersten beiden Podcasts ja auch schon gesagt keine schönen Bildchen ohne dass sie mir irgendwas draus ableiten

00:13:20: können

00:13:21: und an der Stelle wird's dann wieder relevant vorprogrammiert.

00:13:26: das ein solches Vorhaben scheitert ist auch, wenn ich mein Modell nicht in irgendeiner systematischen, in dem Fall systematische Art und Weise in meine Entscheidungsfindung einbinde.

00:13:37: Das heißt es soll schon klar sein an welchen Stellen will ich denn mit wem?

00:13:43: In welcher

00:13:44: Hunde vielleicht

00:13:44: im Gremium drauf schauen und auf die Information, die mir zur Verfügung gestellt wird zurückgreifen.

00:13:51: D.h.,

00:13:52: das ist nicht nur das Modell des schöne Bildchen sondern dann integriert in einen internen Prozess, wenn man

00:14:02: so möchte.

00:14:03: Das ist ein ganz wichtiger Punkt glaube ich die prozessuale Unterstützung weil ich glaube immer noch dass Prozesse dazu dienen Methoden und vorgegensweisen operationell handelbar zu machen oder zumindest sollten sie das tun.

00:14:19: und das heißt auch wenn ich heute im Prozess für System Engineering habe der auf einem Dokumenten basierten System Engineering aufsetzt muss ich mir die Frage stellen, wie und an welchen Stellen muss sich diesen Prozess anpassen damit er eben wegkommt von den Dokumenten und hin zum Modell.

00:14:37: Und das glaube ich ist genau diese Richtung, die meistens nicht wirklich bedacht wird weil es halt ja nur eine andere Methode oder nur ein Tool ist was man einsetzt

00:14:48: und das

00:14:49: sorgt auch für ganz viele Reibungen und dann auch viel Ablehnung.

00:14:53: und dann sind wir wieder beim Change.

00:14:58: Je höher ich die Eintrittsürden mache und je schwerer ich den Zugang mache, desto höher ist die Wahrscheinlichkeit dass es... ...dass die Leute halt nicht darauf aufspringen.

00:15:06: Und das als zusätzlichen Aufwand, als Komplexität, als noch was und jetzt muss ich da noch hin und jetzt möchte ich das nochmal machen einfach ablehnen und Management Unterstützung hin oder her selbst wenn das C-Level felsenfest dahinter steht und überzeugt ist der Change findet auf der Arbeitsebene statt.

00:15:29: Genau, da kann dann auch wieder handwerklich einiges schiefgehen weil wenn man dann so einen kritischen Zeitraum hat und der zu lange wird in dem Dinge doppelt zu pflegen sind zum Beispiel in den Dokumenten plus in einem Modell wird die Ablehnung nicht weniger werden.

00:15:49: Also dass wenn der Arbeitsaufwand, wie du es sagst zunimmt, das ist ein konkretes Beispiel, das man in der Praxis ja oft sieht, dass dann den gedoppelt gepflegt werden müssen über einen langen Zeitraum, dann wird sie zur Frustration führen

00:16:01: ganz klar.

00:16:01: Ich habe jetzt schon mal ganz fleißig mitgeschrieben für mich weil ich finde es auch für meine Arbeit natürlich, für meine eigene Arbeit sehr wichtig.

00:16:08: also wir haben jetzt an... ich glaube wir sind schon ziemlich am Zentrum da und das sozusagen dieses Kernproblems.

00:16:15: Wir haben jetzt angefangen um zu fragen okay Wer muss denn alles dabei sein?

00:16:19: Da haben wir gesagt, gut dann müssen wir neu Deutsch gesagt die Stakeholder alle einbinden und das sind eben nicht nur die Ingenieure sondern manche haben gesagt es kann auch der Vertrieb sein.

00:16:27: Das können auch andere sein.

00:16:30: Wir können den Stakeholders natürlich auch nicht trennen von den

00:16:32: Prozessen.

00:16:33: d.h.,

00:16:34: wir haben letztlich repräsentieren dieses Stakeholder ja im Prozess der Vertriebe.

00:16:39: Repräsentiert hier auch einen Vertriebs- und Angebotsprozess und Produkt.

00:16:42: Man repräsentiert den Prozess, der zu einem Produkt für Domäne ist Und all diese Personen in ihren Prozessen, in die jeweiligen Prozesse zu unterstützen und einzubinden.

00:16:55: Aber das ist ganz wichtig!

00:16:58: Nur als dritter Punkt – und das kam jetzt von der Martina interessant.

00:17:06: Da stecken mir was dahinter, du hast gesagt ja ich muss die Zeit, in der ich Dinge redundant mache.

00:17:13: Die muss ich vermeiden.

00:17:15: also irgendwo kreisen wir jetzt um die Frage der Implementierung herum.

00:17:20: Wie implementiere ich solche Initiativen in eine vernünftige Art und Weise, dass ich wirklich wenig Oberhälter zeuge?

00:17:28: Also du hast angefangen vorhin mit dem Nutzen Und jetzt geht es noch ein Schritt weiter, dann sagst du ja okay den Nutzen habe ich jetzt meinetwegen identifiziert und ich habe aber das Dekor eingebunden wie du es gesagt hast Martin.

00:17:40: Aber jetzt geht's einen Schritt weiter.

00:17:41: dann sagts jetzt will ich das Real machen und jetzt stoße ich auf echte Schwierigkeit weil da hab' ich halt jetzt ein Produkt was

00:17:48: gerade in Entstehung

00:17:49: ist und dass wird eben traditionell gemacht und gleichzeitig will ich mit dem Produkt vielleicht auch noch MBE einführen.

00:17:55: Das scheint mir jetzt ein Reibungspunkt zu sein gerade in Implementierung.

00:17:59: Frage Also, Reibungspunkt und Problem.

00:18:03: Wie gehen wir damit um?

00:18:04: Wie lösen wir das idealerweise?

00:18:06: Dass wir eben diese Redundanz kleinhalten, dass wir nicht zu viel Oberhätten generieren oder keine Komplexität, die dann so empfunden wird als da muss ich noch was machen.

00:18:17: Wie können wir das auch

00:18:18: lösen?

00:18:19: Grundsätzlich

00:18:20: erstmal zu schauen

00:18:22: wie der abgeleitet von den Zielen wo wir hin wollen passende Pilotprojekte suchen Egal ob man jetzt bei NDSC schaut, ob man bei der Einführung von Projektmanagement ist.

00:18:34: Immer eins meiner Themen

00:18:35: oder irgendwelchen Workflow-Systemen,

00:18:38: Dokumentenmanagement – was auch immer!

00:18:40: Wenn ich ein zu kompliziertes Beispiel als Einstieg suche, dann werde ich zur Sicherheit vielleicht am Anfang noch mehr Doppelpflege betreiben um mal bei diesem Beispiel zu bleiben.

00:18:52: deswegen vielleicht lieber zu einem einfacheren Beispiel gehen, sodass ich dann auf diesen mutigen Schritt gehen kann direkt nur noch mit dem Modell zu arbeiten.

00:19:01: und ja das wäre ein möglicher Schritt.

00:19:06: Und genau im Hinterkopf hatte auch noch den Punkt zu sagen wenn es zu komplizierte Modelle sind so dass sich zu sehr in die Details gehen muss schon bei meinem ersten Beispiel dann ist es auch wie mit sehr großen Breakdplänen.

00:19:26: In dem Moment, wo ich's anwenden möchte, ist das was ich da irgendwann einmal hingebastelt habe im Anfang, ne?

00:19:32: Dann ist das schon wieder veraltet.

00:19:34: Das heißt Ich werde nie in ein operatives Tun kommen wenn ich schon von Anfang an immer zu kompliziert einsteige.

00:19:43: Deswegen will ich da auch an die Position von Martin nochmal vertreten erstmal einfache reduzierte Modelle benutzen und ergänzend

00:19:55: ins Tun zu kommen.

00:19:56: Also ich glaube das sind ja zwei Sachen, die du erwähnest.

00:19:58: bevor ich jetzt dich Martin frage, wie habe ich gar keine einfachen Produkte?

00:20:03: Und ich

00:20:03: kann mir vorstellen dass es

00:20:04: eine Herausforderung

00:20:05: ist.

00:20:06: aber es sind im Wesentlichen zwei Sachen die du sagst.

00:20:09: was eine ist Ich muss das grob irgendwie richtig werden.

00:20:11: Das muss handhabbar sein So wie ich's lese oder wie ichs verstehe.

00:20:15: Entschuldige wenn ich es falsch interpretiere Ich glaube so, vielleicht noch aus meiner alten Beratersicht.

00:20:20: Also wenn ich als Berater reingehe und den Kunden alles mache dann kann das natürlich komplex sein.

00:20:24: aber wenn ich will dass der Kunde das versteht Wenn ich will, dass der im Fahrer sitzt ist Dann muss sich das irgendwie einfach machen sodass er lernt wie es selber geht.

00:20:33: Das

00:20:34: wäre schon ein How-to.

00:20:36: Da sind wir schon in dem Positiven Und nicht mehr.

00:20:38: eben how to fail Okay?

00:20:41: Ja genau, Wahnsinn.

00:20:43: Aber der zweite Punkt Aber ein bisschen versteckt in dem was du gesagt hast.

00:20:47: Den halte ich aber für genauso entscheidend.

00:20:50: Ich muss überlegen wo ich mit den Modellieren aufhöre, ich sag's mal ganz platt.

00:20:56: Also du hast gesagt wenn ich finde ich auch in einem Projektplan zu komplex und so gerade lah wäre Dann ist er unhandbar ähnlich wie du es vorhin gesagt hast Martin mit den mit den Visualisierungen.

00:21:05: Wenn ich da vierzig Elemente offener, offener Visualisierung habe dann verstehts kein Mensch mehr.

00:21:10: also ich muss irgendwo auch die den aus den Endpunkt des Modellierens klug machen und den klug definieren.

00:21:19: Das scheint mir zumindest mal, oder ich höre es zumindest mal.

00:21:22: Also habe ich das richtig gehört?

00:21:24: Das habe ich irgendwie falsch

00:21:25: verstanden jetzt gerade.

00:21:27: Ist ja immer die Frage wo setzt man jetzt an um dieses einfache Beispiel zu definieren?

00:21:33: Du hast grad mein einfache Beispiel gibt's oft nicht stimmt schon Die Prozesse sind immer irgendwie kompliziert weil man Schnittstellen hat.

00:21:40: aber vielleicht findet man ein Beispiel bei dem im Verhältnis zu anderen Projekten weniger Stakeholder involviert sind zum Beispiel, dass man da erstmal Sprache die Legitregelung finden kann.

00:21:53: Die sollte aber natürlich um dann nicht wieder diese Insellösungen zu haben das meine wegen z.B.

00:21:57: nur noch die IT mit dem neuen MVSE-Tool oder der neuen Sprache, die man ja im Endeffekt entwickelt arbeitet, dass wir auch interdisziplinär auf alle Fälle schon mehr unterwegs ist.

00:22:09: Aber es müssen ja eine gleich zehn Abteilungen mit beteiligt sein.

00:22:13: Es reicht ja vielleicht am Anfang, wenn erst um drei oder vier mit beteiligt sind die vielleicht auch noch die nötige Offenheiten mitbringen.

00:22:21: Jetzt Martin ich werde dich nicht fragen als Praktiker und als Vertreter von Ruder & Schwarz, wo ihr gescheiter seid ganz bestimmt nicht aber vor dem Hintergrund der Produkte, die er macht, die ja alles andere als einfach sind würde ich jetzt das Ganze mal positiv drehen Du in deiner Rolle MBSE im Unternehmen zu tragen, wenn du das machst und dir die einzelnen Abteilungen als ein Projekt da anschaust.

00:22:49: Was sind denn also die Dinge auf die du achtest um eben die Erfolgswahrscheinlichkeiten der Erfolgsaussichten dann wirklich hochzuhaben?

00:22:59: Das erste was ich getan habe war, warum sie jetzt in dem Kontext ist.

00:23:02: Ich hab den Begriff MBSe nicht mehr verwendet.

00:23:06: Ich hab eine neue Abkürzung erfunden Die nennt sich Model Aided System Engineering, Maze.

00:23:16: Sehr schön!

00:23:16: Das ist wie vor zwanzig Jahren der Begriff Prozesse schon relativ

00:23:20: verheizt war.

00:23:21: Ja und die Idee kam eigentlich aus einem sehr klassischen Modellierungskontext nämlich der D-Modellierung.

00:23:32: Wenn ich an die Konstruktionsrück denke dann gab es früher mal

00:23:35: Konstruktionen

00:23:36: auf dem Zeichenbrett.

00:23:38: irgendwann

00:23:39: gab's dann

00:23:39: Computerunterstützung dafür und das nannte sich damals auch Computer Edit, Design CAD.

00:23:46: Und es waren die Vorläufer von dem was wir heute unter dreidimensionalen Modulierungen und drei D-Design kennen.

00:23:54: Der Gedanke ist letztendlich derselbe Ich will den Sprung nicht machen vom ich komme von einem dokumentenbasierten Ansatz und

00:24:04: versuche morgen

00:24:05: einen modellbasierten ansatz zu fahren Sondern ich nutze erstmal bestimmte Aspekte aus diesem Kontext MBSE, um mein System-Engineering zu unterstützen.

00:24:18: Und wenn ich jetzt an MBSe denke dann fallen mir da zwei Bereiche ein die ich sehr früh und sehr gut unterstützen kann.

00:24:28: Das ist das Thema Requirements Engineering also das Modellieren von Requirement und vor allem von Requirement Beziehungen Was ein sehr wichtiges Thema ist, um Komplexität transparent zu machen

00:24:42: und auch

00:24:44: eher handelbar.

00:24:46: Und das Zweite ist Architektur zu unterstützen.

00:24:50: Und zwar funktionale und logische Architekuren.

00:24:54: Dafür kann ich wunderbar aus dem MBE bestimmte Diagrammtypen benutzen die mir genau diese Information, die ich haben will liefern.

00:25:03: Gleichzeitig bewege ich mich damit wenn ich erzeige ich mache Ich modelliere die Requirements, ich modelle logische Architekturen.

00:25:11: Ich modelle funktionale Architekaturen, komme ich dahin wo die meisten ja hin wollen nämlich ich habe ein Modell das einen funktionalen Prototypen darstellt ohne aber im Vorfeld zu sagen mein Ziel ist es einen funktionalen

00:25:25: Prototyp

00:25:27: zu bilden.

00:25:30: der Aspekt ist glaube ich eher ein psychologischer Aspekt nämlich zu verhindern dass was du angesprochen hast Thomas Wann höre ich aufzumodellieren?

00:25:41: Das ist ja immer diese Herausforderung.

00:25:43: Wenn ich aber als Zielsetzung sage, ich will nur eine Unterstützung haben... ...ich will nicht jedes Detail modelliert haben!

00:25:49: Ich will nicht alles zu hundert Prozent modellieren sondern ich will die zwanzig Prozent modillieren, die mehr achtzig Prozent Verständnis liefern.

00:26:03: Dann habe ich einen ganz massiven Nutzen trotzdem eine gewisse Einfachheit

00:26:07: behalten

00:26:10: vielleicht sogar dazu geeignet ist, aus komplexen Zusammenhängen

00:26:14: nur noch

00:26:15: komplizierte zu machen.

00:26:18: und das ist so der Ansatz wo ich sage dass es für mich ein erfolgsversprechender Ansatz also wenn wir es rumdrehen zu schalten idealerweise sofort ansetzen sagen.

00:26:30: Ich will den digitalen Zwilling Das ist mein Ziel Den will ich morgen haben und dafür mache jetzt MBC.

00:26:36: Das schließt sich ein Kreis, weil letztlich haben wir ganz am Anfang schon von Peter Kruse gesprochen.

00:26:42: Und ich weiß nicht welche der acht Regeln für den totalen Stillstand im Unternehmen das jetzt war.

00:26:47: aber da erzählt er doch auch, wir müssen entweder einfach wirklich in die Extreme gehen, entweder alles kontrollieren oder komplette Freiheit lassen.

00:26:54: und in dem Fall finde ich schließlich der Kreis wieder, entwieder alles modellieren oder gar nix irgendwo... ...die Realität und das Richtige liegt irgendwo auf diesem Spektrum dazwischen?

00:27:07: Ja Der gute Begriff für alles Neumachen ist eben Boil the Ocean.

00:27:13: Das finde ich immer ganz gut, weil er sagt okay wir müssen jetzt sofort alles alles neu machen und alles anders um das Unternehmen auf links drehen und das wird ja vermutlich mal auch im operativ und sofort schreit dann auch nicht, zumindest man nicht akzeptiert werden.

00:27:27: Ich glaube auf der anderen Seite haben wir schon das zweite auch diskutiertes Zweidagestrem, nämlich das zu kleinen Denken.

00:27:32: also zu klein denken hieße da in dem Gegenteil einfach nur vom Tool zu denken.

00:27:36: Also irgendwo genau dazwischen müssen uns bewegen.

00:27:39: Und wenn ich jetzt mal so meine Eigelbeste mal angucke Wir haben angefangen,

00:27:44: wir brauchen

00:27:45: Klarheit über die Ziele Das hast du erwähnt Mathias?

00:27:48: Wir müssen den Nutzen

00:27:50: klar artikulieren.

00:27:52: im Rückbezug auf den letzten Punkt, wenn du jetzt gerade genannt hast oder wenn ich das will dann muss ich halt genau das tun.

00:27:58: Also wenn ich ein funktionales Modell will um was weiß wie funktionelle Simulation zu machen, dann muss sich halt genau dass tun und rechts und links brauche ich vielleicht erstmal auch gar nicht.

00:28:05: also die Nutzenartikulieren.

00:28:06: wir haben gesagt wir wollen die...nicht mehr wollen, wir müssen die Stakeholder alle Stakeholders

00:28:12: Produktes

00:28:13: involvieren mit Denken vermutlich mal von Anfang an Das würde ich jetzt mal dazu fügen die

00:28:21: zugehörigen

00:28:21: Prozesse verstehen innerhalb der uns bewegen.

00:28:24: Wir brauchen vernünftiges Erplimentierungsmodell und wir dürfen es nicht MBS erinnern, aber ist die Liste damit komplett?

00:28:34: Oder haben wir jetzt da so bar ganz zentrale Themen noch vergessen, wo wir – wenn wir all das richtig machen, wenn wir alles machen – immer noch hervorragend scheitern können.

00:28:45: Was denkt ihr?

00:28:46: Fällt euch dann noch was ein, dass wir unbedingt den Hörerinnen wieder auf den Weg geben

00:28:49: müssen?".

00:28:50: Also mir freuen noch zwei Dinge ein, die ich dich da noch reinbringen würde, wo beide nicht MBE-spezifisch sind und es geht eher in die Richtung, wie Martin am Anfang angesprochen hat.

00:29:00: Das hat auch immer der Changegedanke mitschwingen muss Und das ist einmal in Richtung der Leute, die es tatsächlich dann tun müssen, ihnen das Gefühl zu geben dass das was bisher getan wurde nicht gut ist.

00:29:14: Also das wird ja relativ oft und gerne im Kontext gemacht.

00:29:18: MBEs die Next Level System Engineering, Advanced Level klingt alles danach als wäre es viel besser ist nicht zwangsläufig besser, als es einfach nur ein anderer Weg ist zu tun.

00:29:32: Und in ganz bestimmten Rahmenbedingungen funktioniert das besser oder ist es erfolgsversprechender?

00:29:40: Aber es ist nicht per se damit gesagt dass alles was bisher im System Engineering gemacht wurde schlecht ist.

00:29:45: Also das der eine Punkt und der zweite Punkt den ich

00:29:51: öfter mal beobachte

00:29:52: und auch aus Diskussionen mit Kollegen von

00:29:57: anderen Firmen

00:29:59: öfter mal feststelle ist, solche Initiativen haben oft sehr viel Aufmerksamkeit am Anfang.

00:30:07: Die nimmt dann über die Zeit

00:30:09: ein bisschen ab.

00:30:10: Man erwartet dann die Quick Wins und irgendwann schlägt diese Aufmerksamkeit den Druck um.

00:30:17: Und dann müssen Quick Wints präsentiert werden.

00:30:20: Ich glaube man muss sich wirklich im Klaren sein wenn ich MBE einführen möchte, dann ist das eine Investition die ich tätigen muss Egal ob das über die Doppelarbeit ist, egal ob

00:30:30: das für die

00:30:31: Implementierung einer Toolkette ist.

00:30:35: Weil es geht ja nicht nur darum ein Modellierungs-Tool zu haben sondern da hängen noch ganz viele andere Tools mit dran die entweder eine Schnittstelle haben müssen oder die in der Konsequenz genauso an Gepastung geändert werden müssen.

00:30:49: und diese Bereitschaft

00:30:51: tatsächlich

00:30:51: das zu investieren im richtigen Maß Das ist halt auch eine Herausforderung, weil der Return of Invest wie man so schön sagt lässt ja durchaus gerade in größeren Umgebungen auch gerne mal zwei drei Jahre auf sich warten.

00:31:13: Also es ist jetzt kein Quick Change wo ich sage heute ändere ich was und übermorgen sehe die positiven Effekte sondern ich fange heute an dann habe langen Prozess, bis ich tatsächlich die positive Effekte sehe und das muss ich aushalten.

00:31:30: Und zwar auf allen Ebenen.

00:31:31: in einem Unternehmen muss sich das aushalten

00:31:33: können.

00:31:34: Den Punkt hatte ich auch noch auf der Liste, den der Quick-Wins.

00:31:38: Der Martin hat jetzt gerade erwähnt dass man dann auch die Ressourcen investieren muss.

00:31:45: Auf meiner schlauen Liste steht auch damit drauf die Frage habe ich diese Ressoursen überhaupt?

00:31:50: Weil Die lange Dauer, dann auch die hohe Intensität solcher Vorhaben.

00:31:56: Das sollte man sich auf alle Fälle sicher sein, dass man auch diese Ressourcen zur Verfügung hat.

00:32:02: Ressoursen klingt immer so unschön und da geht es natürlich darum, wie die Leute können ihre Zeit in den Umfang einbringen, der heute nötig ist.

00:32:13: Und vorhin hatten wir noch mit dieses Tool-Thema, da wir zwei Punkte auf meiner Liste besprechen von diesem Modell

00:32:20: und dem

00:32:21: Tool dass man da auch im Blick hat, nicht jetzt irgendwie zehn Tools auf so einen Vorhaben drauf zu werfen.

00:32:29: Dass man sich immer darüber im Klaren ist was

00:32:32: schon alleine ein

00:32:33: Tool und die Einführung von einem Werkzeug mit sich bringt und das muss er einfach nicht übertragen.

00:32:41: Also dass man das wirklich sehr reflektiert angeht für welche Themen man welches Tool braucht und dann nicht versucht ein mega Software Projekt drauszumachen.

00:32:53: auch die Leute, wenn man dann schon mal in der Software drin sind.

00:32:56: Das ist dann wieder so ein Punkt

00:32:57: für...

00:32:58: Wir sind jetzt schon mittendrin im MBE-Projekt und wir haben uns darauf geeinigt welche Werkzeuge wirklich verwendet werden, dass man dann auch hergeht und sagt Schule!

00:33:07: Die Leute vernünftig

00:33:08: das

00:33:08: klingt jetzt super

00:33:09: nahe

00:33:11: aber es gehört dazu.

00:33:13: Wenn ich die Leute heute schule und erwarte, dass sie ihn am halben Jahr noch wissen was sie damit anfangen sollen, dann denke ich mir ist das utopisch Es ist eine schöne Idee, aber es wird nicht funktionieren.

00:33:24: Das heißt also auch das zu orchestrieren halte ich für dringend notwendig.

00:33:31: Befähigung?

00:33:32: Das ist jetzt eines genau.

00:33:33: Da gehört Schulung dazu.

00:33:35: Quik Winz sagst du Martin.

00:33:37: Das ist unter Ausstellung schwierig, je nach, vielleicht auch noch Komplexität der Organisation schnelle Ergebnisse darzustellen.

00:33:44: Vielleicht gilt das für Qualitative Ziele, aber vielleicht gar nicht mehr so sehr viel qualitative.

00:33:51: Wenn ich sage innerhalb von drei Monaten sehe ich gewisse Sachen besser kann ich besser entscheiden habe ich vielleicht mehr Transparenz ist es jetzt vielleicht nicht unbedingt das Ziel was sich in euros ausdrücke aber es ist ein qualitatives Ziel oder qualitives Ergebnis was ich durchaus kommunizieren kann.

00:34:10: Aber du wolltest gerade noch etwas sagen?

00:34:11: Ja ich hatte nur einen Punkt, den du getrickert hast Martina mit der Schulung.

00:34:20: Was ich manchmal feststelle ist, in dem Moment wo das Thema MBI und damit das Thema Tool unterstützt kommt, kommt oft auch so ein bisschen der Gedanke auf.

00:34:32: Die Leute müssten weniger qualifiziert und weniger geschult im System Engineering sein.

00:34:39: Speziell jetzt im Kontext von der SUSM-LV II die ja eine textbasierte Repräsentation

00:34:46: vom Modell

00:34:48: kommen natürlich ganz viele jetzt auf den Gedanken zu sagen, ja dann kann ich mit einem LLM-Modell.

00:34:54: Mit einer KI kann ich ja dann im BSE machen.

00:35:03: Grundsätzlich wenn ich weiß

00:35:07: wie

00:35:08: ich System Engineering anwende und dieser Kernpunkt dass die Leute die damit arbeiten müssen ein systemisches Verständnis brauchen, systemisch denken können müssen die Leute, die die Modelle generieren und erzeugen nicht nur ein Tool bedienen können müssen.

00:35:24: Und die Regeln fürs Tool gern müssen sondern eben auch die Grundsätze des System Engineering's beherrschen müssen.

00:35:32: Das ist glaube ich auch

00:35:33: was wo man

00:35:35: manchmal in die Versuchung verfällt zu sagen naja jetzt habe ich ja einen Tool und es gibt ja diverse Tools auf dem Markt die haben das die Arbeit erleichtern noch bestimmte Fähigkeiten ersetzen.

00:35:51: Aber wie gesagt im System Engineering reden wir meistens ja nicht von wiederholenden Repetitiven Aufgaben, sondern wir reden ja meistens davon dass wir ein neuartiges Problem gelöst kriegen wollen.

00:36:02: und da glaube ich steckt eine relativ große Gefahr drin das man das vernachlässigt und dann eben die Meinung ist das Modell ersetzt den Experten oder MBE ersetzt die Bedarf an Experten.

00:36:15: Das ist ein guter Punkt, wenn ich das ergänzen darf.

00:36:19: Aus meiner Praxis immer, wenn man nicht weiter weiß heute dann sagt, komm, das machen wir mit der KI und da gibt es einen alten Spruch, der heißt Gabelte in Gabeltaut.

00:36:30: Wenn ich mich nicht auskenne, wirklich will ich nicht weiß welche Fragen ich zu stellen habe wie ich dieses mächtige Werkzeug zu fahren habe.

00:36:38: Dann kommt natürlich auch ganz großer Unsinn raus Insofern weder das Tool noch eine KI kann tatsächlich an der Stelle denjenigen ersetzen der die Frage richtig stellen kann, der die Fragestellung überhaupt komplett verstehen und überreißen kann.

00:36:54: Aber wir sind jetzt fast schon von der Anleitung zum Unglücklichsein zu einer Anleitern zum glücklichen Leben in MBSG gekommen.

00:37:03: Das ist ja auch total super dass das wir auch so positiv sind.

00:37:06: Auch mal mit Blick auf den Scope des heutigen Podcasts.

00:37:09: Ich glaube wir haben schon ein paar Dinge angerissen.

00:37:10: da sind noch neue Folgen.

00:37:12: dritten.

00:37:12: Ich glaube das Thema AI und MBC ist hier eine ganz gute Geschichte, das Thema Befähigung ist eine gute Geschichte.

00:37:19: Das Thema Implementierung, Scoping

00:37:21: usw.,

00:37:22: ich glaube da haben wir schon bestimmt drei oder vier neue Folgenden die wir uns ausdenken können wo wir Material hätten.

00:37:29: aber für heute sagen lassen wir mal vielleicht in diesem Scope dann auch gut sein.

00:37:33: Ganz zum Schluss die klassische Frage drehen wir es um die top drei Tipps nochmal.

00:37:40: Wir wissen jetzt, wie wir überscheiden können.

00:37:42: Vielleicht noch ein paar ganz kurze Stichwortartige Punkte, die wir es eben nicht tun von euch beiden, also mal ganz extemporeert.

00:37:49: Woran sollten wir denken?

00:37:50: Also machen wir das einfach umgekehrt wie vorher.

00:37:53: Martina magst du nochmal anfangen so ein paar Augenmerker Achtung darauf achten dann werdet ihr glücklich mit der BSE.

00:38:01: Also dann werden wir glücklich.

00:38:05: Positiv?

00:38:05: Ja, wir sind ja schon gedreht.

00:38:08: Ihr habt die Diskussion auch

00:38:10: schon gedroht.

00:38:10: Wir haben Sitzschirparme hin und her geht es nicht, deswegen muss ich mich immer mehr versichern.

00:38:14: Also nachdem ich anfangs das mit den Zielen genannt habe will ich das jetzt wieder einbringen.

00:38:18: einfach Klarheit darüber schaffen.

00:38:20: worum braucht

00:38:21: man das?

00:38:21: was soll unser Nutzen davon sein?

00:38:24: Es eben nicht nur als Toolprojekt, also Software-Projekt verstehen sondern

00:38:28: auch als

00:38:29: ganzheitliches Projekt ist sowohl die Systemdenkweise organisatorische Aspekte, prozessuale Aspechte und dann eben auch die Modellaspekte mit einbezieht.

00:38:39: Und vielleicht auch Geduld mitbringen weil es einfach eine längere Baustelle

00:38:46: ist.

00:38:47: Ziele, Nussen, Geduld super das wären ja in der Tat all!

00:38:51: Martin,

00:38:51: deine Top-Dreif.

00:38:52: Es wird schon schwierig, weil

00:38:53: das ist eine

00:38:54: sehr schöne Top-Frei.

00:38:56: Ich schließe mich bei von

00:38:57: Ihnen alleinander.

00:38:59: Ich versuche das mal zu vermeiden

00:39:01: und mich einfach

00:39:01: da anzuschließen.

00:39:05: Ein Punkt ist für mich, da will ich ein bisschen präziser sein, eine echte Bedarfsanalyse zu machen.

00:39:13: was brauche ich wirklich?

00:39:15: Was muss ich wirklich tun?

00:39:16: Was will ich wirklich erreichen?

00:39:21: die benutzen für ein sauberes Erwartungsmanagement.

00:39:26: Und zwar auf allen Ebenen, sowohl in Richtung

00:39:28: des Management

00:39:29: und des Top-Managements aber auch in Richtung

00:39:32: der

00:39:32: Kollegen oder der Mitarbeitenden, die dann auf der Arbeitsebene das Ganze nutzen müssen.

00:39:41: Ich glaube man muss über den zumindest gewissen Level von ITI-Tektur nachdenken.

00:39:50: Wie möchte ich das Ganze realisieren und umsetzen?

00:39:54: Und dann muss man sehr ehrlich mal kalkulieren, was kostet mich das ganze denn voraussichtlich.

00:40:05: Empfehlend würde ich sagen einfach den, dass was rauskommt mit Faktor drei multiplizieren und davon ausgehen, dass es auch dreimal so lange dauert und sich dann dazu entscheiden ob ich das tun möchte oder nicht.

00:40:21: Pragmatismus, Erwartungshaltung, Umsetzung auf mehreren Ebenen.

00:40:26: Da gehört natürlich auch die Bewegungen, da gehören auch die IT dazu und die ganze Touching.

00:40:29: Super!

00:40:30: Das sind schon mal hervorragende sechs Punkte.

00:40:32: Ich glaube damit haben wir tatsächlich schonmal so eine kleine Mini-Anleitung geschafft.

00:40:38: wie man aus dem umglücklich sein ins glücklich sein kommt mit MbSE scheint ja gar nicht so vieljährig zu sein.

00:40:43: das ist toll.

00:40:45: dann bedanke mich ganz herzlich bei euch beiden für die tolle Mitgestaltung.

00:40:51: den Dreh vom negativen ins positive, der ganz zwangsläufig passiert ist heute fand ich richtig klasse und ich freue mich auf nächste Folgen mit euch, mit dem wir vielleicht auch diese Themen noch mal vertiefen.

00:41:05: Ganz herzlichen Dank!

00:41:07: An unsere

00:41:08: Zuhörer auch natürlich herzliche Dank.

00:41:09: Wir haben heute ein bisschen den Podcast länger gemacht.

00:41:12: Das Thema gibt es her.

00:41:14: Ich danke für ihre Geduld Und ihrer Aufmerksamkeit.

00:41:19: Gerne für Rückfragen, Kommentare zur Verfügung.

00:41:21: Nutzen Sie dazu gerne die Kontakt-Taten den Shownotz und ich würde mich sehr freuen wenn wir uns dann beim nächsten Mal in der Folge V wieder hören!

00:41:30: Vielen Dank, machen sie es gut!

00:41:39: Der Podcast Next Generation

00:41:41: Engineering

00:41:42: ist eine Produktion des VDE Bayern Redaktion Hans Krautlager und Thomas

00:41:48: Gessner.

Neuer Kommentar

Dein Name oder Pseudonym (wird öffentlich angezeigt)
Mindestens 10 Zeichen
Durch das Abschicken des Formulars stimmst du zu, dass der Wert unter "Name oder Pseudonym" gespeichert wird und öffentlich angezeigt werden kann. Wir speichern keine IP-Adressen oder andere personenbezogene Daten. Die Nutzung deines echten Namens ist freiwillig.