Episode 230 – Die goldene Mitte für Modellierungstools, Herzlich willkommen beim Zukunftsarchitekten, der Systems Engineering Podcast für Machende und Entscheidende. Am Mikrofon ist wieder Björn Schaure. Als Systemingenieur gebe ich dir Tipps und Impulse, damit du dein Projekt zum Erfolg führen kannst. Music. So wirst du in der heutigen Episode erfahren, was Modellierungstools aus meiner Sicht leisten können und wie diese Tools miteinander in Verbindung gesetzt werden können.
Ja, herzlich willkommen in einer neuen Folge des Zukunftsarchitekten-Podcasts. Bevor wir in das Thema einsteigen, möchte ich ein bisschen Koordination und Betriebsführung machen. Und zwar habe ich ein paar Neuigkeiten, die ich einmal mitteilen möchte. Und zwar bin ich gerade dabei, das Design meiner Webseite und des Zukunftsarchitekten zu zu überarbeiten und auf neue Füße zu stellen. Also es wird was geben in Richtung Farbkonzept. Dort wird sich was ändern.
Ich denke, dass wir auch ein bisschen in Richtung Logos und Icons uns was überlegen und da was Neues machen. Also da passiert dann doch einiges. Hauptsächlich erst mal optisch, was die Webseite angeht, was die Logos angehen und so weiter. Da wird sich ein bisschen was ändern und da darfst du sehr gespannt drauf sein, was sich dort ergibt.
Und dann spreche ich aber auch natürlich mit meinen bekannten Freunden, Beratern darüber, wie können wir die Inhalte besser strukturieren, besser darstellen und das heißt also, es wird sich dort auch dann an dem Aufbau der Webseite, denke ich mal, auch ein bisschen was ändern, sodass das intuitiver wird, besser nutzbar und dass du dich da besser darauf zurechtfinden wirst. Also da darfst du sehr gespannt sein, was da kommen wird.
Dann das Zweite, wo ich überlege, ist eine Systems Engineering Community. Denn auf dem letzten TDSE bin ich angesprochen worden und gesagt worden, hey Björn, ich möchte mich ganz gerne ein bisschen weiterentwickeln, ich finde aber nicht so richtig die Möglichkeiten, das zu tun. Also ich habe Fragen über das hinaus, was ich als Systemingenieur gelernt habe.
Und da fehlt mir etwas, da fehlt mir der Austausch mit Gleichgesinnten und da habe ich mir Gedanken gemacht darüber, dass ich das sowieso schon länger im Hinterkopf hatte, sowas aufzubauen und ja, ich würde das ganz gerne in Angriff nehmen. So, jetzt muss ich natürlich überlegen, wie gestalte ich das? Also was mache ich da für ein Format? Welche Inhalte bringe ich da rein, sodass es für dich auch dann einen wirklichen Mehrwert bietet? Und wie sieht das mit Terminen aus? Sind Termine wichtig?
Abgleichtermine, wo man gemeinsam über gewisse Dinge spricht, was wir auf gar keinen Fall machen werden und das ist etwas, was allen, die sich daran beteiligen wollen und werden, bewusst sein muss. Wir werden natürlich dort keine Preisabsprachen oder Ähnliches treffen. Wir werden uns nicht austauschen über technische Details, die zu dem Kern-Know-how der jeweiligen Firma, also zu deiner Firma dann gehören. Das, um Gottes Willen, wird hier nicht ausgetauscht.
Was wir machen wollen, sind über Methoden sprechen, über Tools sprechen, über mögliche Weiterentwicklungen, Weiterbildungen, ja, all sowas. Oder vielleicht auch dann doch nochmal den einen oder anderen Tipp geben, hier, versucht das doch mal so rum oder so rum. Also die Verfeinerung der Methoden, Workflows, Tools, Prozesse. Also darüber wollen wir sprechen. Wir wollen keine Preisabsprachen und auch keine technischen Details des Kern-Know-Hows austauschen.
Das schon mal so als Vorgeschmack, eine Systems Engineering Community, das ist das, was ich ganz gerne erwähne. Etablieren möchte, was ich ganz gerne mit euch aufbauen will. Dazu brauche ich aber Rückmeldung. Rückmeldung von euch, von dir speziell. Wenn dich das interessiert, schreib mir zurück, was ist dir wichtig? Welche Fragen möchtest du beantwortet haben? Welche Inhalte möchtest du sehen? Möchtest du dich regelmäßig auch irgendwie treffen? Und wenn ja, wann?
Einmal im Monat, zweimal im Monat? Reicht dir einmal im Vierteljahr? Möchtest du dich physisch treffen? Oder reicht es auch, wenn wir uns virtuell treffen? Was spricht dich da am ehesten an? Das ist das, was ich wissen muss. Auch Inhalte. Möchtest du ganz gerne irgendwelche Vorlagen haben? Prozessbeschreibungen, Case Studies oder, oder, oder. Also diese Informationen, gib mir die.
Dann kann ich das mir anschauen, bewerten, was kann ich denn tun, was kann ich denn bereitstellen und da einen Mehrwert zu schaffen. Also, schreibt mir an feedback-at-zukunftsarchitekten-podcast.de und teilt mir mit, was wären eure, wäre deine Wünsche an so eine Systems Engineering Community. Den Link dazu findest du natürlich auch in den Shownotes.
So, das dritte wäre eine sogenannte Tool-Offensive, habe ich es mal genannt, denn ich werde immer mal wieder gefragt, hey, welches Tool kannst du denn empfehlen für dieses Thema oder für ein anderes Thema? Ich bin aber nicht derjenige, der hier hergeht und spezielle Tools anpreist und irgendwo vorstellt. Und deswegen habe ich mir überlegt, dass ich versuche, Menschen vor das Mikrofon zu bekommen, die mir Antworten auf deine Fragen geben können.
Also, ich versuche, diese Kontakte herzustellen, ich versuche, die Menschen hier zu mir in den Podcast zu bekommen und stelle dann entsprechende Fragen, die dich interessieren, die du mir vielleicht geschickt hast, damit ich sie halt auch für alle einmal stelle und dass sie auch entsprechend beantwortet werden.
Auch wenn du tool hersteller bist und das jetzt hier hörst und ganz gerne deine antworten geben möchtest auf meine fragen die ich stelle dann melde dich gerne bei mir und wir werden irgendwie zusammenkommen also, Die Meldung bitte auch an feedback-at-zukunftsarchitekt-podcast.de, sodass wir dort zusammenkommen, dass ich dann die Kontakte aufbauen kann und die Interviews hier platzieren kann. Kommen wir zum Inhalt der heutigen Episode.
Zu Anfang möchte ich ganz gerne noch einen Disclaimer loswerden und zwar, ich werde hier heute über Tools sprechen. Ich werde vielleicht auch das ein oder andere Tool vom Namen her in den Mund nehmen, aber ich habe keine Zusammenarbeit mit irgendeinem Toolhersteller. Ich habe keine finanziellen Interessen daran, dass ich den einen oder anderen hier nenne oder vielleicht auch eben nicht nenne. Das kann durchaus sein, dass ich jemanden nicht nenne, weil es gibt hunderte von Tools am Markt.
Meine Expertise, meine Erfahrung, die ich hier hereinbringe, basiert darauf, dass ich mit diesem jeweiligen Tool einmal gearbeitet habe oder am Rande damit zu tun gehabt habe. Also, das ist mein Disclaimer. Da habe ich ansonsten kein finanzielles Interesse dran. Und falls ich irgendwelche Features vergessen habe, dann liegt das durchaus daran, dass diese Tools so viele Features heutzutage schon mitbringen, dass ich die nicht alle hier im Detail erklären kann.
Genau, kommen wir zum Inhalt und kommen wir dazu, was diese Tools oder wie man dort eine goldene Mitte in den Modellierungstools in diesem Dschungel finden kann. Zu Anfang möchte ich einmal darauf eingehen, dass Tools in der Regel, wenn sie hergestellt werden, zweckgebunden gemacht werden. Das heißt also, in dem Moment, wo ein Toolhersteller funktioniert, hergeht und ein Tool entwickelt, hat er damit einen oder möchte er ganz gerne einen gewissen Zweck damit erfüllen.
So ist zum Beispiel MS Project damals entstanden worden oder entwickelt worden, weil Projektmanager ein Werkzeug an die Hand gegeben haben wollten, mit dem sie ihre Projekte übersichtlich gestalten konnten, wo sie darstellen können, Wann sind wir denn fertig? Welche Aufgaben gibt es alles? Und so weiter. Also das wäre in diesem Fall der Zweck. Ich möchte meine Projekte leiten können, steuern können.
Und so gibt es auch andere Tools, die hergestellt werden, um zum Beispiel Anforderungen zu verwalten. Und es gibt Tools, die hergestellt werden, um Modelle, Systemmodelle oder Softwaremodelle herzustellen. Oder auch 3D-Modelle in der Mechanikentwicklung herzustellen. Also alle diese Tools haben einen bestimmten Zweck, einen Fokus, warum sie hergestellt werden. Das muss man erstmal so verstehen. Und... Wenn dieser Zweck erfüllt worden ist, sind sie natürlich dann auch an den Markt gegangen.
Jetzt haben diese Tools, wenn sie dann entwickelt worden sind, eine gewisse Architektur, die dieser Entwicklung zugrunde liegt. Und wenn dann ein neuer Kundenwunsch hinzukommt, dann haben sich die ein oder anderen Tool-Hersteller überlegt, das könnten wir auch noch mit bei uns einbauen. Und jetzt ist es aber so, dass diese zugrunde gelegte Architektur, mit der der ursprüngliche Zweck dieser Tools erfüllt worden ist, dass diese Architektur dann nicht unbedingt immer mehr ausreicht.
Also diese grundlegende Architektur ist nicht dafür ausgelegt, bestimmte neue Features zu realisieren. Also, wenn ich ein Anforderungsmanagement-Werkzeug gebaut habe und am Markt platziert habe und dann kommt irgendjemand daher und sagt, es wäre ja aber auch cool, wenn ihr da jetzt grafische Modelle mit darstellen könnt, dann kann es sein, dass die Basisarchitektur für das Requirements-Werkzeug das gar nicht aufnehmen kann oder das gar nicht realisieren kann.
Und dann baut man da vielleicht irgendwas und setzt das da drauf. Umgangssprachig sagt man dann auch schon mal, wir flanschen das da dran. Und genau so ist es dann nämlich auch, das ist da dran gepflanscht. Und diese Erweiterungen sind dann oft nicht so leistungsfähig wie andere Tools, wo von Anfang an gesagt worden ist, hey, wir wollen grafische Darstellungen machen. Wir wollen grafische Darstellungen von unseren Systemen, von unseren Produkten, die wir herstellen, machen.
Und dann ist ein Anforderungsmanagementswerkzeug, wird dann um irgendwelche grafischen Features erweitert, aber diese grafischen Features sind gar nicht so leistungsfähig, wie wenn ich ein wirkliches Modellierungswerkzeug herannehme. So, das ist etwas länger erklärt, aber das ist mir wichtig, dass du das weißt, dass diese Tools in der Regel zweckgebunden sind. So, dann ist die nächste Frage, warum muss modelliert werden?
Also die Frage kam ja rein, wo ist die goldene Mitte von Modellierungstools? Und die Frage ist halt, warum muss hier modelliert werden? und ich stelle mal eine andere Frage, was kann durch ein Modell beantwortet werden? Und Modelle können natürlich vieles sein. Die erste Idee, die man hat, ist eine grafische Darstellung der eigenen Idee. Es kann aber auch eine textuelle Auflistung sein, eine tabellarische Auflistung, auch das wäre möglich.
Sobald ich dann aber solche Dinge in Verbindung setze, also die textuelle oder die tabellarische, sobald ich da irgendwelche Dinge miteinander in Verbindung setze, bin ich dabei, ein Modell zu erzeugen. Ein Modell kann ich dann drehen und wenden und von verschiedenen Seiten betrachten und sehe immer wieder oder habe dadurch immer wieder neue Erkenntnisse. Und das ist für mich etwas, wo ich dann von einem Modell spreche.
Und das kann bei textuellen Darstellungen sein, indem ich dann Metadaten habe, die ich in einer anderen Art und Weise darstellen kann oder die ich mit einem anderen Filter belegen kann und dann gewisse andere Dinge darstelle. Und so habe ich dann auch von einer Summe von textuellen Darstellungen könnte ich mir dann auch ein entsprechendes Modell erzeugen.
Um das konkreter zu machen, ihr habt mehrere Anforderungen untereinander stehen, die haben verschiedene Zustände und wenn ich jetzt diese Zustände herausfiltern möchte, wo ich eine Freigabe drauf erteilt habe, dann habe ich nur noch eine gewisse Ansicht, nämlich nur noch die Anforderungen, die freigegeben sind und die anderen sehe ich gar nicht mehr und damit habe ich eine Sicht auf dieses Anforderungsmodell geschaffen. So, nun haben wir ein Verständnis darüber, was ist denn ein Modell?
Das Modell dient auch immer als Kommunikationsmittel, als Austausch mit anderen im Projekt oder in der Firma, aus meiner Sicht mit dem größten Hintergrund, den man erreichen kann, ein gemeinsames Verständnis. Denn mir ist es gerade auch wieder passiert in einem Projekt, ich habe etwas aufgezeichnet, ich habe das den Kollegen im Projekt gezeigt und die sagten mir, ach, so siehst du das.
Guck mal, ich sehe das ganz anders, wir müssen hier diesen einen Baustein, das werden wir, oder ein Stück Software, das kriegen wir dort nicht unter, das müssen wir irgendwie anders machen. Und das ist dieses gemeinsame Verständnis. Ich hatte eine andere Idee, wie wir das denn bauen könnten oder wie das denn platziert sein müsste.
Und dann habe ich diese Rückmeldung bekommen, wenn das so sein soll, dann geht das unter Umständen technisch nicht oder wir müssen das noch mit dem Auftraggeber abstimmen, wie es denn sein soll. Und dieses gemeinsame Verständnis zu erzeugen, dafür ist ein Modell auch unglaublich wichtig. Von daher...
Also, stellt euch an den Flipchart, stellt euch ans Whiteboard, fangt an zu zeichnen und wenn ihr sagt, okay, da haben wir was geschaffen, dann, ja, in dem einfachsten Fall fotografiert ihr das und nehmt es mit und habt dort ein gemeinsames Verständnis erzeugt. Was ein Modell auch mitbringt oder bewirkt, ist, den Kontext korrekt abzugrenzen.
Das bedeutet, ihr zieht eine Linie um das, was ihr bauen wollt oder bauen sollt laut Projektbeschreibung und auch da fällt es wieder rein, dieses gemeinsame Verständnis, was ihr erzeugt. Weil ihr werdet dann merken, dass der eine oder andere sagt, ja Moment mal, aber das müssen wir doch eigentlich aus diesem Systemkontext herausziehen, das muss woanders gemacht werden. Das ist doch nicht das, was wir herstellen, das ist doch nicht unsere Kernkompetenz.
Also da den Kontext korrekt abgrenzen, was gehört zu meinem System dazu, was müssen wir entwickeln und was eben nicht. Und damit gelingt dann auch eine Fokussierung auf dieses Zielsystem, was wiederum wichtig fürs Projektmanagement ist. Die Menschen, die im Projektmanagement dann tätig sind, die müssen doch wissen, was müssen wir in unsere Planung mit aufnehmen. Wo müssen wir Arbeitspakete planen? Wo müssen wir Menschen mit beauftragen, dass sie das für uns erledigen?
Und da müssen wir uns darauf fokussieren, damit wir das richtige Zielsystem dort dann bauen können. Angenommen, du hast dann ein Modell erstellt, dann stellt sich ja die Frage, was kann man mit so einem Modell denn noch machen, außer den Kontext abgrenzen und ein gemeinsames Verständnis erreichen. Mit einem Modell können noch viele weitere Dinge gemacht werden.
Zum Beispiel können textuelle Beschreibungen, wie zum Beispiel in einem Lastenheft oder einem Pflichtenheft, durch die grafischen Darstellungen aus einem Modellierungswerkzeug, also einem reinen Werkzeug, wo grafische Darstellungen auf sogenannten Diagrammen gemacht werden, Die können wir jetzt übernehmen, also wir könnten da jetzt einen Export machen und diese Darstellung dann mit in das Lastenheft, wo üblicherweise, vielleicht kennst du das auch,
üblicherweise viel Text drin steht, Text oder Tabellen. Und ich mache das immer ganz gerne, dass ich das damit dann ergänze und weitere Informationen dann aus diesen grafischen Darstellungen ableite. Was kann man noch mit einem Modell machen? Es gibt die Möglichkeit, eine sogenannte Modell-zu-Modell-Transformation zu machen.
Das heißt also, wenn du Daten in einem Modell stehen hast, zum Beispiel die Aufteilung deines Systems, sprich in Subsysteme oder Sub-Subsysteme, das ist eine Aufteilung, eine hierarchische Aufteilung deines Systems, dann könntest du diese Teile in ein anderes Modell überführen, nämlich in die sogenannte Work-Breakdown-Structure. Auch das ist ein Modell, auch da kann ich dann nachher drauf filtern. Und diese Überführung nennt man dann eine Modell-zu-Modell-Transformation.
Wenn ich jetzt nicht physische Elemente darstelle, sondern eine andere Sicht in meinem Modell wähle, nämlich die funktionale Architektur, dann habe ich dort Funktionen definiert. Und jetzt kannst du hergehen und diese Funktionen auch wieder exportieren und zum Beispiel in deine FMA importieren. Also importierst du diese Dinge in deine FMA, hast dort schon die ganzen Funktionen drinstehen und füllst diese dann aus. Also auch da hast du eine Modell-zu-Modell-Transformation.
Das heißt also, auch da macht es Sinn, ein Modell zu erzeugen und weiterzunutzen. Und natürlich zu guter Letzt kannst du auch dein System modellieren. Also das, was du dann modelliert hast, Entschuldigung, nicht modellieren, simulieren. Du kannst dein Modell simulieren. Das heißt also, du kannst diesen kleinen Aspekt, den du betrachtet hast, den kannst du zum Leben erwecken und dort irgendwas sich bewegen lassen.
Durch ein Aktivitätsdiagramm könnte zum Beispiel ein Token durchlaufen und du kannst sehen, wie sich dieser Token verteilt. Oder du hast ein thermisches Flussdiagramm oder ein thermisches Flussmodell aufgebaut und du kannst dann dort sehen, wie Luft oder wie Flüssigkeiten durch irgendwas durchströmen. Auch das ist eine Simulation, auch das kann man dann machen, wenn man ein Modell aufbaut. Modell erzeugt hat.
Welche Voraussetzungen braucht man denn dafür, wenn man jetzt Modelle hat und darüber hinaus diesen Mehrwert nutzen will? Das ist total unterschiedlich, je nach Tools, die du verwendest und je nach Anwendungsfall, was du damit machen willst. Ich sage immer, das Allerallereinfachste, was man machen kann, ist, wenn man ein Modell hat und dabei ist es völlig egal, wie man das und in welchem Tool man das hergestellt hat.
Das Einfachste ist, Namen kopieren und im nächsten Tool verwenden und dann aber auch diszipliniert beibehalten. Damit bekommt man eine sogenannte Traceability by Name aufgebaut und kann darüber halt dann in das jeweilige nächste Tool referenzieren. Das bricht natürlich genau in dem Moment, wo ich diese Traceability nicht mehr habe. Die Tools, die man da verwendet, sind oftmals Word, als Textprogramm und dann Zeichenprogramme wie ein PowerPoint.
Ja, ist nicht unbedingt das Zeichenprogramm, aber es wird dazu immer wieder verwendet. Oder neuerdings webbasiert RAW.io gibt es oder auch andere Tools, wo halt ein Export oder ein Screenshot eines Bildes möglich ist, damit ich das dann weiterverarbeiten kann in anderen Tools wie zum Beispiel Word. Besser ist da dann schon, wenn ich einen Export aus dem einen Tool machen kann und einen Import in einem anderen Tool.
Damit muss ich aber auch festlegen, wer ist jetzt mein Leader, also welches ist das führende Tool und welches ist das folgende Tool. Da spricht man dann von Leader und Follower oder Main und Replika. Also das muss man sich klar haben, wo muss ich die Änderungen machen, damit ich sie dann in das andere Tool importieren kann.
Das ist dann nicht mehr so fehleranfällig wie mit dem Kopieren der Namen, weil dann ist klar, wenn ich in dem zweiten Tool, in der Replika irgendwas ändere, wird es zwangsläufig irgendwann überschrieben, dadurch, dass ich wieder einen Import mache. Das geht auch, muss man sich natürlich genau gucken, welche Exportmöglichkeiten hat das eine Tool und welche Importmöglichkeiten hat das andere Tool, damit das auch diese Schnittstellen zusammenpassen.
So, und dann gibt es noch eine coole Sache, das ist dann, ich sage jetzt mal, die Top-Lösung, die ich aktuell kenne, und zwar über eine sogenannte Synchronisationsschnittstelle, wie zum Beispiel OSLC. Den Link dazu, was OSLC ist und wo das beschrieben wird, packe ich auch in die Shownotes. Das ist auf jeden Fall eine Standardschnittstelle, die viele Tools schon unterstützen und worüber dann Informationen zu Modellen ausgetauscht werden können.
Für diese beiden letzten Möglichkeiten, also den Export und Import bzw. Über eine Sync-Schnittstelle, da ist es unbedingt notwendig, dass wir eine formalisierte Sprache haben bzw. Auf diese formalisierte Sprache der OSLC-Schnittstelle angepasst worden sind, die Modellelemente, damit diese Informationen durch die Maschinen oder Programme gelesen werden können.
Teilweise kann sowas dann auch durch Menschen gelesen werden, wie zum Beispiel die SysML V2, wobei da muss ich dann auch wieder vorsichtig sein, das ist dann wiederum beides eine Darstellung, eine grafische Darstellung des Modells und eine textuelle Darstellung des Modells, aber das läuft dann irgendwo im Hintergrund. Tools für diesen zweiten und dritten Fall wären zum Beispiel Polarion, Codebeamer oder Doors für die Requirements.
Es gibt im Projektmanagement Tools wie Microsoft Project, Redmine vielleicht, können auch importieren oder Jira. Und für die Modellierung fallen mir dann so im ersten Moment AI, also Enterprise Architect, Cameo und Rhapsody ein. Das wären so Tools, wo dann ja auch teilweise diese OSLC-Schnittstelle schon verfügbar ist. Wie gesagt, ich habe teilweise nur am Rande damit gearbeitet mit den Tools, habe nicht unbedingt immer die ganzen Schnittstellen-Integrationen mitgemacht.
Das ist etwas, was du dann in einer Evaluierung unter Umständen mal erfragen musst von den jeweiligen Herstellern. Und, schleife zu meiner Ankündigung vom Anfang des Podcasts, ich versuche auch solche Fragen dann in der Tool-Offensive zu stellen, um herauszukitzeln, wer kann denn hier was machen. Und bei meiner Überlegung sind mir dann noch weitere Möglichkeiten aufgefallen, die möglich sind bei diesen Tools. Und zwar gibt es sogenannte integrierte Tools.
Also diese Tools haben dann gewisse Aspekte von Anfang an auf ihrer Agenda gehabt, dass sie das integriert betrachten wollen. Da fällt mir zum Beispiel das Tool iQuavis ein, das wird hier in Deutschland von Two Pillars vertrieben. Das kann Anforderungen aufnehmen, kann aber auch im nächsten Schritt Modellierung mittels einer doch recht einfachen Sprache, nämlich Konsens, durchführen.
Das Tool hat dann weiterhin die Möglichkeit, das Ganze in eine Projektmanagement-Sicht zu überführen und weil ich da nur mal eine Evaluierung mitgemacht habe, weiß ich nicht genau, ob das Projektmanagement dann integriert ist oder ob das angeschlossen ist, aber wer weiß, wie es funktioniert, kann mich gerne kontaktieren und mir das einmal schreiben, dann kann ich das ja noch als Hinweis mit in die Shownotes packen.
Genau, also wie gesagt, Projektmanagement und die haben auch die Möglichkeit an gängige Office-Tools ich meine Microsoft Office wäre es gewesen, dass sie dort Anbindungen herstellen können und ja, Mails verschicken, Aufgabenpakete als Aufgaben einplanen und so weiter also sowas geht dann auch mit diesem Tool Aquavis wunderbar wie gesagt. Das stand bei diesem Tool schon von Anfang an auf der Agenda, dass Sie das so bauen wollen. Ein anderes Tool, was auch integriert arbeitet, ist SPICY SE.
Das habe ich auch im Rahmen einer Evaluierung kennenlernen können. Es geht hier dabei um die Modellierung mit einer relativ eigenen und einfachen Syntax und die Möglichkeit, an diese Elemente, die man dann dort designt hat, Anforderungen dran zu schreiben. Da fängt man also gleich an mit der Kontextabgrenzung, Kontextmodellierung und schreibt dann dort schon die ersten Anforderungen an diese Teile entsprechend dran. Und die sieht man dann auch immer direkt in einem zweiten Fenster.
Je nachdem, wo man dann hinklickt, tauchen dann diese ganzen Anforderungen dort entsprechend auf. Beide Tools, die ich jetzt hier noch vorgestellt habe, sind auch wirklich webbasiert und damit kollaborativ. Also da kann man wunderbar zusammen mit arbeiten. So, und ich habe jetzt das ein oder andere Tool genannt. Die letzten zwei habe ich sogar noch ein bisschen genauer vorgestellt, aber das ist bestimmt nicht ausreichend. Ich habe bestimmt nicht alle Features erwähnt. Ähm...
Deswegen entbindet dich das nicht davon, eine entsprechende eigene Bewertung für dein Projekt, für deine Organisation zu machen, um herauszufinden, welche Möglichkeiten wollt ihr denn unbedingt umsetzen bei euch im Projekt, was ist euch super wichtig, was ist notwendig überhaupt, dass ihr gute und sichere Produkte herstellen könnt. Und das, wie gesagt, meine Vorstellung, meine Ideen, was möglich ist, was ihr benötigt, da müsst ihr selber nochmal drauf gucken. Und so komme ich zum Fazit.
Ihr merkt, es ist eine große Auswahl an Tools, die es gibt am Markt. Die sind auch alle teilweise mit einem entsprechenden Geldinvest versehen, teilweise auch dann noch Zeitinvest und Konfigurationsaufwand, der dahinter steckt. Aber ich bin der Meinung, wenn man sich auf etwas festgelegt hat, wenn man etwa vorher eine Evaluierung vorgeschoben hat, dann bieten diese Umsetzung dann auch immer einen großen Mehrwert, den man langfristig daraus ziehen kann.
Die eine goldene Mitte, die gibt es leider nicht. Es gibt bestimmt Konfigurationen, wo ich sagen würde, okay, das könnte man übernehmen für das ein oder andere Projekt oder die ein oder andere Organisation und die gleichen sich dann nachher, also zwei verschiedene Organisationen, aber im Detail werden die dann dort auch wieder auseinander gehen. Was ihr, was du speziell für dein Projekt brauchst, musst du herausfinden. Und zwar habe ich da drei Tipps in meiner Zusammenfassung für dich.
Also zusammenfassend zur heutigen Episode. Meine drei Tipps für dich. Fangt einfach erstmal mit dem an, was da ist und probiert das aus. Das Einfachste, was dort ist, sind erstmal Whiteboards und Flipcharts und Fotoapparate. Word und Excel und so weiter das ist ja auch oftmals da und probiert aus, was mit den Modellen, die ihr dann dort erstellt ihr denn alles modellieren könnt und wo vielleicht dann entsprechende Fragen auftauchen.
Lass uns doch das mal noch ein bisschen tiefer analysieren oder das mal ein bisschen tiefer analysieren. Also fangt einfach damit an, was da ist mit den Tools, die da sind und das Einfachste ist Papier und Stift. Und guckt, welche Fragen ihr in euren Projekten immer wieder beantworten müsst. Dann, und das könnt ihr schon parallel machen, mein zweiter Tipp, sammelt eure Kriterien ein. Was ist wichtig für das Projekt oder die Projekte und was ist wichtig für die Organisation?
Wie wollt ihr zusammenarbeiten? Welche Modelle beantworten euch die wichtigsten Fragen? Wo habt ihr Risiken? Was benötigt der Projektmanager von euren technischen Entwürfen, die ihr da herstellt? Also, diese Kriterien sammeln. Welches Geld steht euch zur Verfügung? Welches Lizenzmodell hat das ein oder andere Tool? Wie sind die Schnittstellen? Also, das sind alles so Kriterien, die ihr für euch herausarbeiten müsst.
Und wenn ihr diese Kriterien habt, dann könnt ihr Tools heranholen, heranziehen, gegen diese Kriterien bewerten, dann habt ihr bestimmt einen Fokus auf gewisse Tools, holt euch Teststellungen, das machen die Tool-Hersteller eigentlich immer ganz gerne, weil sie ja dann wissen, sie kommen in die engere Auswahl. Führt diese Teststellung durch, bewertet die Kriterien und sucht euch dann ein entsprechendes Tool oder Toolset aus.
Ja, du bist dabei, Systems Engineering anzuwenden oder musst es in deiner Firma einführen, aber der Fortschritt lässt zu wünschen übrig, dann scrolle in den Shownotes nach unten. Dort findest du meine E-Mail-Adresse und schreib mir eine Mail. Wir sprechen dann darüber, wie ich dir und deinem Projekt helfen kann. 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 viel Spaß an dem, was du machst und vor allem wünsche ich dir einen hohen Wirkungsgrad. Tschüss und bis zum nächsten Mal. Music.