ZA214 - Strategien und Methoden für effektiven Wissenstransfer

13.02.2024 41 Minuten



On Air in dieser Episode

avatar
Björn Schorre
avatar
Elena Schüßler-Roggenhofer

Zusammenfassung

Mein Gast heute ist Elena Schüßler-Roggenhofer, eine erfahrene Wissensmanagerin und Autorin digitaler Lerninhalte. Gemeinsam werden wir den Unterschied zwischen Wissen und Information untersuchen und den Kreislauf des Wissensmanagements erläutern.

Elena erklärt, dass Wissen aus Informationen entsteht, denen ein Erfahrungskontext hinzugefügt wird. Sie betont, dass es sowohl explizites Wissen gibt, das in Dokumenten festgehalten werden kann, als auch implizites Wissen, das in den Köpfen der Menschen liegt. Das Ziel des Wissensmanagements ist es, beide Arten von Wissen zugänglich zu machen und effektiv zu nutzen. Björn und Elena diskutieren auch die verschiedenen Aspekte des Wissensmanagements, sowohl strategisch als auch operativ.

Der strategische Aspekt beinhaltet das Setzen von Wissenszielen und die Evaluierung des Erfolgs. Der operative Aspekt umfasst die Identifizierung, den Erwerb, die Entwicklung, Verteilung, Nutzung und Bewahrung des Wissens. Dabei betonen sie die Notwendigkeit, sowohl explizites als auch implizites Wissen zu dokumentieren und für andere zugänglich zu machen.

Um dies zu erreichen, erklären sie den Kreislauf des Wissensmanagements, der verschiedene Iterationen umfasst. Zunächst identifizieren sie das relevante Wissen und erstellen eine Wissenslandkarte. Anschließend priorisieren sie die transferrelevanten Aspekte und setzen geeignete Transfermethoden um. Dieser Kreislauf dient als theoretisches Konstrukt, um wertvolles Wissen zu dokumentieren und für andere nutzbar zu machen. Sie betonen auch die Bedeutung von Strukturen und Plattformen, die den Zugriff auf das Wissen erleichtern.

Sie diskutieren auch die Herausforderungen des Wissensmanagements, insbesondere in Bezug auf das Ausscheiden von Mitarbeitenden und den demografischen Wandel. Es ist wichtig, das Wissen im Unternehmen zu bewahren und nachhaltig zugänglich zu machen, um den Wissenstransfer zu gewährleisten. Sie betonen, dass vernünftiges Wissensmanagement Zeit spart und die Effizienz steigert.

Abschließend gibt Elena praktische Tipps zur Umsetzung des Wissensmanagements, wie die Schaffung einer Wissensdatenbank und die Nutzung geeigneter Plattformen. Sie betont, dass Wissensmanagement eine gemeinsame Anstrengung ist, bei der verschiedene Abteilungen zusammenarbeiten sollten. Sie empfiehlt auch, sich an Experten für Wissensmanagement zu wenden und gemeinsam mit diesem eine Kultur der Wissensteilung im Unternehmen zu fördern.

Zusammenfassend geben sie drei Tipps für das Wissensmanagement: das Setzen von Zielen, das Sammeln und Zugänglichmachen von Wissen sowie die Motivation und Unterstützung der Mitarbeitenden beim Dokumentieren von Wissen.

Wenn Dir diese Episode gefallen hat, kannst Du sie gerne weiterempfehlen, sodass auch andere von den Tipps profitieren. Du kannst auch die Online-Bibliothek von Björn nutzen, um auf das Wissen des Systems Engineering zuzugreifen.

 

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

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

Elena’s Mailadresse: elena@knowlibri.de

Webseite von Knowlibri: https://www.knowlibri.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

ZA213 - Richtiges Einordnen von Normenanforderungen

09.01.2024 20 Minuten



On Air in dieser Episode

avatar
Björn Schorre

Zusammenfassung

Bist du unsicher, wie du Anforderungen aus Normen korrekt kategorisieren sollst? In unserer kommenden Episode tauchen wir tief in dieses Thema ein, um dir Klarheit zu verschaffen!

In dieser Episode wirst du erfahren:

  1. Korrekte Kategorisierung von Normenanforderungen: Wie werden Anforderungen aus Normen richtig eingeordnet? Wir beleuchten beispielsweise, ob die aktive Entladung eines HV-Systems eine Einschränkung ist oder als funktionale Anforderung definiert werden kann.
  2. Aufteilung von Normenanforderungen: Wie weit müssen Normen-Anforderungen aufgeschlüsselt werden, um sie sinnvoll zu handhaben? Wir nehmen dabei spezifische Normen wie LV123 genauer unter die Lupe und diskutieren, ob sie detailliert aufgedröselt oder allgemein nur referenziert werden sollten.
  3. Definition von DTCs auf Systemebene: Brauchst du eine genaue Festlegung von Prioritäten, Verlernzählern usw. bei der Definition von Diagnose-Fehlercodes auf Systemebene? Oder geschieht dies erst auf einer späteren Abstraktionsebene? Wir klären, welche Herangehensweise hier am effektivsten ist.

Verpasse diese Episode nicht, um deine Kenntnisse zu erweitern und deine Herangehensweise an Normenanforderungen zu verbessern!

 

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

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

ZA212 - Digitalisierung im Maschinenbau - Quo Vadis?

14.11.2023 38 Minuten



On Air in dieser Episode

avatar
Björn Schorre

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

ZA211 - Wie werden Anforderungen in Subsysteme zerlegt?

31.10.2023 28 Minuten



On Air in dieser Episode

avatar
Björn Schorre

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

ZA210 - Mehr Erfolg, weniger Rätsel: Return on Investment im Systems Engineering

17.10.2023 51 Minuten



On Air in dieser Episode

avatar
Björn Schorre
avatar
David Endler

Zusammenfassung

In dieser Podcast-Episode tauchen wir tief in die Welt des Systems Engineering ein und zeigen dir, wie du den Return on Investment (RoI) effektiv berechnen kannst. Wir beleuchten zwei entscheidende Aspekte: den Vergleich verschiedener RoI-Berechnungsmethoden und die Umsetzung in der Praxis.

Der erste Take-Away führt dich durch die verschiedenen RoI-Berechnungsmethoden und hilft dir, fundierte Entscheidungen zu treffen. Du wirst lernen, welche Methoden existieren und wie Du die Vor- und Nachteile der Methoden bewerten musst.

Der zweite wichtige Aspekt ist die Umsetzung in der Praxis. Wir präsentieren ein anschauliches Praxisbeispiel und erörtern die Herausforderungen, die auftreten können. Du erfährst, wie du diese Hürden erfolgreich bewältigen kannst, um den RoI in deinem Systems Engineering Projekt zu maximieren.

Begleite uns in dieser informativen Episode, um deine RoI-Berechnungskompetenzen zu erweitern und sicherzustellen, dass deine Projekte auf dem richtigen Weg sind.

 

Das Dokument ist hier auf Davids Webseite kostenfrei zu erhalten: Link zum Paper

Das Paper ist auch im Tagungsband des TdSE von 2013 enthalten: Link zum Tagungsband des TdSE 2013 (Kosten: EUR 39,90)

 

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

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

Davids Mailadresse: de@davidendler.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

Sinnvolles Glossar

ZA209 - Wie du ein sinnvolles Glossar anlegst und verwaltest

05.09.2023 22 Minuten



On Air in dieser Episode

avatar
Björn Schorre

Zusammenfassung

In der heutigen Episode spreche ich über das Glossar eines Projektes. Mir ist es gerade in einem aktuellen Projekt passiert, dass ich gefragt wurde, wozu so ein Glossar den gut sei. Man würde doch schon wissen, was die Abkürzungen bedeuten.

Daher möchte ich einmal im Podcast darauf eingehen, warum ich immer beim Einstieg in ein Projekt ein Glossar anfange. Egal ob es ein Glossar vom Projektteam schon gibt oder nicht. Aus meiner Sicht hilft Dir so ein Glossar ungemein – zu Anfang, um für Dich Begriffe zu klären und später, um diese Begriffe anderen weiterzugeben.

Hör in meinen Podcast rein, denn das sind nicht die einzigen Gründe, warum ein Glossar wichtig ist.

 

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

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

 

Bild zu Rollen im RE

Die Rollen im Anforderungsmanagement

Neben den Anforderungsdokumenten haben wir auch noch die verschiedenen Rollen bei der Erstellung von Spezifikationen.

Auf der einen Seite haben wir den Kunden, der in seinem Lastenheft ein Problem beschreibt, das er gelöst haben will. Zusätzlich haben wir die Interessensgruppen, die ebenfalls ein Problem beschreiben, das sie allgemeingültig gelöst haben wollen.

Auf der anderen Seite haben wir das Projektteam mit jemandem, der sich mit dem ganzen Thema Requirements Engineering beschäftigt und versucht, überhaupt das Problem zu begreifen. Dann gibt es jemanden, der sich mit dem ganzen Systemdesign beschäftigt. Das ist jemand, der versucht, aus den Anforderungen eine Lösung zu definieren. Und dann haben wir einen Projektmanager, der halt in diesem ganzen Kontext noch versucht, das Team zum Erfolg zu führen.

Das zusammen ist genau die Schnittstelle, und wir sehen auch da: Auf der einen Seite liegen die Lastenhefte und auf der anderen Seite die Pflichtenhefte nach der klassischen Beschreibung.

Rollen im Anforderungsmanagement

Rollen im Anforderungsmanagement

Am Ende bilden die Rollen auch die Arbeitsergebnisse ab. Ein Requirements Engineer wird also die Anforderungsspezifikation (SRS) erschaffen. Ein Systemdesigner oder ein Systemarchitekt wird die Architekturspezifikation (SAS) schreiben, und der Projektmanager beschreibt in der Regel in seinem Projekthandbuch all die nichttechnischen Anforderungen an ein System.

Je komplexer Systeme werden oder je dynamischer ihre Funktion ist, desto wichtiger wird es, sich intensiv mit diesen Dokumenten und Spezifikationen zu beschäftigen. Ein System, das einen relativ einfachen Aufbau hat und auch keine großartige Dynamik besitzt, muss nicht in aller epischer Breite sämtliche oben beschriebenen Spezifikationen besitzen, wenn eigentlich klar ist, was wichtig ist. Das bedeutet aber, sie nicht komplett wegzulassen, sondern mit Sinn und Verstand nur das, was gebraucht wird, umzusetzen.

Je komplexer ein System wird oder gar je mehr Unterlieferanten dabei sind, also je mehr Menschen auch in diesem Projekt eingebunden sind, desto wichtiger werden Spezifikationen. Denn Spezifikationen sind am Ende nichts anderes als eine Dokumentation von Wissen.

Requirements-Engineering mit Word und Excel

Immer wieder melden sich Leser, die in ihren Unternehmen die nötigen Anforderungen und Spezifikationen für Projekte schaffen, aber kein Requirements-Engineering-Werkzeug haben. Entsprechend versuchen sie, mit Word und Excel zu arbeiten, was nicht immer einfach ist – und weswegen ich die nächsten Beiträge diesem Thema widmen möchte.

Ich werde im Folgenden die vielen Fragen aufgreifen, die sich um Requirements Engineering mit Word und Excel drehen.

Viele, gerade kleine und mittelständische Firmen haben für ihre Projekte oftmals keine aufwändigen und großen Requirements-Engineering-Tools, wie man sie aus komplexen Projekten kennt.

Diese Tools sind in der Regel recht teuer, oft sehr vielschichtig und relativ komplex zu bedienen. Also nutzen viele Unternehmen – beinahe „traditionell“ – die Word- oder auch Excel-Werkzeuge.

Hinzu kommt häufig, dass die fachliche Ausbildung in Sachen Requirements Engineering fehlt: Viele wissen schlicht nicht, was es bedeutet und wie relevant es ist. Entsprechend nehmen sie einfach das, was sie haben – in der Regel Microsoft Office – und versuchen, ihre Requirements damit zusammenzubauen.

Das Ziel dieser Episoden ist es, euch das nötige KnowHow und viele Tipps zu vermitteln, um eure Spezifikationen mit Word zu handhaben. Zunächst habe ich ein paar Begriffsklärungen und ein wenig Hintergrundwissen für Leser, die die vorangegangenen Beiträge noch nicht kennen.

Tiger and Turtle, Duisburg

ZA208 - Agilität im Systems-Engineering

25.07.2023 46 Minuten



On Air in dieser Episode

avatar
Björn Schorre
avatar
Thaddäus Dorsch

Zusammenfassung

In dieser Folge tauchen wir in die Welt der Systemtechnik ein und untersuchen die Einbeziehung von Agilität in den Prozess. Mein heutiger Gast ist Dr. Thaddäus Dorsch, ein Experte auf dem Gebiet des Systems-Engineering und der agilen Methoden. Wir erfahren etwas über die Kernkonzepte des Systems-Engineering, wie Agilität eine entscheidende Rolle spielt, Best-Practice-Benchmarks für die Implementierung von Agilem Systems Engineering und die wichtigsten Erfolgsfaktoren, damit es effektiv funktioniert.

Das agile Manifest der Software-Entwicklung: https://agilemanifesto.org/iso/de/manifesto.html (bitte zuerst lesen)

Link auf das agile Manifest der System-Entwicklung: https://www.agile-systems-engineering.com/

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

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

 

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

Du brauchst Hilfe bei der Definition der Anforderungen an Dein Produkt?

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

 

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

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

 

Wie detailliert soll ich Anforderungen beschreiben?

In Pflichtenheften für komplexe Systeme ergibt es mit Sicherheit keinen Sinn, die letzten Controller-PINs oder den Variablennamen im Quellcode zu beschreiben.  Wichtig ist, dass ich das, was ich konzeptionell erwarte, z.B. ein Geschwindigkeitssignal in einer gewissen Auflösung in einem gewissen Wertebereich, beschreibe.  Wie das Software-Team das unten auf deren Ebene in seine Spezifikation und in seine Lösung umsetzt und dass da irgendwelche Coding-Styleguides berücksichtigt werden usw. usw., das werde ich oben auf Systemebene schon gar nicht beschreiben.

Das tue ich schlicht aus dem Grund, dass ich dem Team auch einen Lösungsraum bereithalte, mit dem es arbeiten kann. Das macht es gerade dann besonders schwierig, und das ist häufig auch meine Erfahrung, wenn Kunden versuchen, im Pseudocode im Lastenheft Funktionen zu beschreiben. Dann bin ich auf der Systemebene immer gefordert, davon wieder zu abstrahieren, um klar zu verstehen, was will der Kunde eigentlich will. In der Regel nehme ich dann SysML, um ein Verhalten als Diagramm darzustellen. Ein Pseudocode im Lastenheft geht nämlich schon fast bis zu Variablennamen herunter. Damit ist es a) schwer verständlich und b) schränkt es den Lösungsraum auf 0 ein.

Das mag zwar ganz nett sein, aber wir haben immer bei komplexen Systemen das Problem, dass wir zwischen verschiedenen Lösungsmöglichkeiten abwägen müssen. Wenn ich keinen Handlungsspielraum mehr habe, werde ich an der Stelle dermaßen fixiert, dass ich möglicherweise das gesamte System überhaupt nicht lösungs- und zielorientiert umsetzen kann. Bei all diesen Spezifikationen gilt für einen pragmatischen Einsatz: Je einfacher ein System und je weniger Anforderungen vorhanden sind, desto weniger müssen Sie sich mit komplexen Spezifikationsstrukturen herumschlagen.
Bei manchen reicht aus meiner Erfahrung heraus die Architekturspezifikation (SAS) völlig aus. Man soll in Verbindung mit dem System Footprint auf der Lastenheftebene (= Kundenebene = „Wünsch-dir-was“ des Kunden oder Produktmanagements) einfach pragmatisch bleiben.

Wichtig: Weglassen heißt nicht komplett weglassen, sondern nur, das, was sie mit Sinn und Verstand als nutzlos nicht brauchen. Aber definitiv lassen sie nicht diese gesamte Ebene weg, sonst kommen sie in Situationen, dass sie nachher nicht mehr nachvollziehen können, was sie da eigentlich wollten, und der Kunde nicht das Gewünschte bekommt.