ZA071: Lean Systems Engineering – Stand der Dinge

Heute geht es um Lean System Engineering und meinen aktuellen Stand meines „kleinen Forschungsprojekts“. Ich war am 04.12. als Speaker auf dem ESE 2013 und ihr hört in dieser Episode den Live-Mitschnitt von meinem Vortrag.

Die Themen der Episode:

  1. Den Kundennutzen des Systems kennen
  2. Eine klare Systemabgrenzung schaffen
  3. Eine sinnvolle Strategie schaffen
  4. Schnelles Lernen ermöglichen
  5. Engpässe entfernen
  6. Führung leben
  7. Respektvolle Zusammenarbeit
  8. Eine effektive Umgebung schaffen

Meine Folien zu dem Vortrag:

Hinweise in der Episode:

Subscription link

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

iTunes | Zune | RSS

Euer Feedback

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

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

Frage: Wie ist Eure Erfahrung? Welche Fähigkeiten sind aus eurer Sicht wichtig?

Comments

  1. Torsten says:

    HAllo,
    tolle Sache, die Idee von Systems Engineering!
    Meine Einstellung seit Jahr(zehnten), dass man immer das Ganze sehen soll/muß, damit die einzelnen MAs nicht aneinander vorbei arbeiten.
    In Deutschland ist die Einstellung ja noch sehr verbreitet:
    Der andere Aufgabenbereich geht mich nichts an, auch wenn ich dort mit meiner Vorgehensweise (Mehr-)Arbeit schaffen könnte.
    Habe SW schon entwickelt, als man das Glück hatte vom ersten Gespräch an beim Kunden dabei zu sein und Lasten- / Pflichtenheft etc. mit ihm in (auch ungeplanten) mehreren Gesprächen mit den jeweilig besten Ansprechpartnern unterschiedlicher Abteilungen/Funktionen wirklich nutzbringende Infos für die Vorgaben zu erarbeiten.
    Danach mußte dann auch nicht viel umgeworfen werden. Fragen auf die zukünftige Ausrichtung wurden ja schon vorab gestellt und ggf. die SW darauf vorbereitet :-).
    Auch Pflichtenhefte kann man so formulieren, dass sie zum Einen die Anforderungen wiederspiegeln und gleichzeitig so aufgebaut sind, dass atomare Testfälle sich daraus (größtenteils) automatisch ableiten lassen.

    • Hallo Torsten,

      ja, ich denke wir müssen hier oft noch viel Erklärungsarbeit leisten. Gerade wenn Systeme komplexer und Entwicklungsteams größer werden, ist die häufige Reaktion die ich erlebe, dass sich die Teams auf ihren eigenen Kernbereich zurückziehen. Umso wichtiger wird die Rolle des Systemingenieurs, der vielleicht nicht die Tiefenkenntnis zu jedem Umsetzungsdetail hat, aber das große ganze Bild sieht.

      Dann wird es auch für den Testbereich einfacher, besser zu testen.

      Schönen Gruß aus Köln,

      Maik

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen