In dieser Podcast-Episode wird das Thema Wertstrommanagement in der IT tiefgehend erörtert. Die Moderatoren, erfahrene DevOps-Trainer und Coaches, beleuchten die Bedeutung und Anwendung von Wertstrommanagement für die Optimierung von Produktions-, Material- und Informationsflüssen in IT-Organisationen. Sie diskutieren die Unterschiede zu traditionellem Prozessmanagement, die Relevanz von Metriken und die Bedeutung der Kundenperspektive. Am Ende der Episode wird angekündigt, dass ein zweiter Teil folgen wird, der sich konkreter mit der praktischen Umsetzung von Wertstromanalysen beschäftigen soll.
Inhalt
- Einführung in das Thema Wertstrommanagement
- Unterschied zwischen Wertströmen und traditionellem Prozessmanagement
- Bedeutung von Kundenperspektive im Wertstrommanagement
- Diskussion über die Relevanz von Metriken im Wertstrommanagement
- Der Einfluss von Wertstrommanagement auf IT-Organisationen
- Ankündigung eines zweiten Teils der Diskussion mit Fokus auf praktische Anwendung
Shownotes
Dierks Roman zu Wertstrommanagement
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts
DevOps auf die Ohren und ins Hirn. Gestaltet und produziert von Luca Ingianni, Dierk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Heute freuen wir uns auf das Thema Wertstrommanagement.
Und zu Gast haben wir…
Ta-da-da-da! Niemanden!
Heute habt ihr eine Folge mit uns dreien.
Wir haben uns dieses Thema mal angenommen, dass wir drei darüber sprechen.
Mein Name ist Dierk Söllner.
Ich habe ja die letzten Folgen mit Abwesenheit geglänzt,
weil wir uns einfach auch besprochen haben, dass wir nicht mit drei Moderatoren,
nicht mit drei Gastgebern und einem Gast in eine Long-Shield begeben.
Also kurzum, heute sind nur wir drei dabei.
Alles klar.
Ja.
In unserem Podcast haben wir…
In unserem Podcast haben wir die Tradition, all unsere Gäste nach ihrer persönlichen Definition von DevOps zu fragen.
Und da wir heute unsere eigenen Gäste sind und um das Ganze etwas spannender zu machen,
außerdem haben wir unsere Definition ja bereits auch mehrfach in den vergangenen Folgen genannt und erklärt.
Lasst uns das Ganze mal auf maximal drei Worte beschränken.
Also, Dirk, wie lautet deine Definition von DevOps in drei Worten?
Ja, das könnte ich so tun, das müsste ich überlegen.
Die Frage habe ich ja erwartet.
Ich sage mal, Philosophie hochperformanter IT-Organisationen.
Darf ich es auch noch erklären oder reicht es nur mit diesen drei Worten?
Das Ziel war es, in drei Worten kurz und knackig zu halten.
Erklären können wir es vielleicht, wenn wir es in der Runde nochmal ein wenig hinterfragen wollen.
Wenn wir es zum Thema vielleicht auch in Beziehung setzen wollen.
Luca, wie sieht es bei dir aus?
Was ist deine Definition von DevOps in drei Worten?
Naja, jemand hatte mir da in den Mund gelegt, Wertschleifen.
Und ich setze da jetzt aber einen drauf.
Ich sage, Wertschleifen, nicht Wertströme.
Falco, jetzt müssen wir dich fragen, was denn deine drei Worte sind zum Thema DevOps.
Meine DevOps-Definition in drei Worten lautet,
Wird digitale Transformation kundenfokussiert?
So, für die geneigten Zuhörer, die jetzt noch nicht ganz schlau geworden sind,
ihr dürft gerne die alten Folgen anhören.
Da haben wir ganz viele tolle Definitionen von DevOps.
Und wenn Falco uns oder mich in diesem Fall nicht auf drei Worte begrenzt hätte,
dann hätte ich noch eine Definition aus einer der ersten Folgen genannt,
nämlich nachhaltige Geschwindigkeit.
Ich glaube, das war die Folge 4.
4 oder 5, also das ist ja schon Jahre her.
Der Podcast hat ja auch schon einige Jahre auf dem Buckel.
Und das fand ich eine ganz tolle Definition.
Also nachhaltige Geschwindigkeit haben wir immer noch in unseren DevOps-Folien
und Schulungsunterlagen getrennt.
Also kurzum, das wäre noch eine Ergänzung dazu.
Aber wir haben ja heute nicht DevOps, wir haben heute ja Value Stream Management.
Und wenn wir so ein Thema haben, dann ist ja auch immer die Frage,
was steckt dahinter?
Die, die von euch, die jetzt schon ein bisschen,
dabei geblieben sind, die müssen ja irgendwie ein Interesse
im Value Stream Management haben.
Also haben sie vielleicht eine ungefähre Folge,
eine ungefähre Vorstellung von dem, was da hinter steckt.
Und ich fange mal an mit der Definition von Wertstrommanagement
aus unseren Schulungsunterlagen.
Wir haben ja eine Schulung, zwei Tage zum Thema Wertstrommanagement.
Und uns wird heute bestimmt noch das eine oder andere Mal
auf Value Stream rausrutschen.
Das wäre die englische Übersetzung dazu.
Das können wir auch nochmal diskutieren.
Wir fangen mal an mit Wertstrommanagement.
Und das ist für uns.
Für uns ein betriebswirtschaftlicher Ansatz,
um den Produktions-, den Material- und den Informationsfluss zu optimieren
und eine Organisation konsequent an der Wertgenerierung
für den Kunden auszurichten.
Und wenn man sich das anschaut,
ich denke, der eine oder andere von euch wird stolpern
über Produktionsfluss oder Materialfluss.
Das soll aus unserer Sicht quasi der übergreifende Ansatz sein.
Das ist ja ein übergreifender Ansatz.
Und wir wollen heute auch ein bisschen darüber sprechen,
was steckt denn dahinter?
Was steckt in Value Stream Management?
Genau.
Und jetzt haben wir viel über Management
und Management von Wertströmen, Value Streams gesprochen.
Für mich ist erstmal wichtig zu klären,
was überhaupt ein Wertstrom ist.
Warum reden wir dann über Wertströme?
Warum ist das wichtig?
Und zum Verständnis,
wir sehen ein Wertstrom als eine Sequenz,
eine Aneinanderreihung von Aktivitäten,
in einem Team oder einer Organisation,
die es möglich macht,
Wert für einen Kunden oder für Stakeholder im Allgemeinen zu generieren
und so auf Kundenwünsche, Kundenanforderungen und Bedürfnisse zu reagieren.
Jetzt könnte man das Ganze noch ein Stück weiter treiben
und das Thema Wert noch ein Stück hinterfragen.
Das ist, glaube ich, eins von den Steckenpferden von Luca,
wenn er schon sagt, Wert schleifen.
Magst du dazu was sagen?
Na ja, Wert ist eben genau das,
was unsere Kunden, unsere Nutzer, unsere Stakeholder erzielen wollen.
Es ist keine Aktivität, es ist kein Produkt,
es sind all diese Dinge nicht,
sondern es ist wirklich das,
um es mit Helmut Kohl zu sagen, was hinten rauskommt.
Da finde ich es immer interessant,
was der CEO von Black & Decker mir in Feldsein Name gesagt hat.
Man könnte glauben, dass wir den Kunden Bohrer verkaufen,
denn immerhin stellen wir Bohrer her.
Aber wer das glaubt, der hat leider Unrecht,
denn was wir den Kunden verkaufen, ist ein Loch in der Wand.
Der Bohrer ist vollkommen uninteressant.
Keiner will einen Bohrer haben.
Die Leute wollen ein Loch in der Wand.
Und das ist, glaube ich, die Perspektive, die man einnehmen muss,
wenn man über Wert nachdenkt.
Was ist Mittel und was ist Zweck?
Und nicht das eine versehentlich mit dem anderen.
Ja, und dann vielleicht auch den Ende-zu-Ende-Gedanken
noch ein Stück zu verfolgen.
Das Loch in der Wand ist meiner Meinung nach
auch nur ein Schritt in der Mitte,
weil selten möchte man echt Löcher in der Wand haben,
sondern üblicherweise Mittel und Wege finden,
zum Beispiel um Bilder anzubringen
oder um Strom- oder Wasserleitungen durch Wände zu verlegen
oder andere Gründe, die dahinter stecken.
Also auch da aus meiner Sicht noch einen Schritt weiter
wirklich zu schauen,
was der Kunde will
und nicht nur den einen Schritt von Bohrer zum Loch in der Wand zu gehen.
Ich finde das ganz toll, dass du das gesagt hast, Falco.
Und auf die Gefahr hin,
dass ich jetzt vielleicht einen Schritt zu weit nach vorne rase schon.
Das ist auch etwas, was man, glaube ich,
wenn man Wertströme sich überlegt,
wenn man die mappt und so,
dass man sich dessen immer bewusst sein muss.
Es gibt ganz verschiedene Perspektiven
und alle haben ein gewisses Maß an Gültigkeit.
Es gibt nicht den einen amtlichen Wertstrom.
Das muss ich auch mal an der Stelle sagen.
Sondern ein Wertstrom ist ja nur ein Modell.
Und ich glaube, Einstein hat gesagt,
alle Modelle sind falsch, aber manche sind nützlich.
Insofern ein Modell, das dir dabei hilft,
zu verstehen, was du tust,
beziehungsweise was du tun solltest,
das ist nützlich.
Wo setzt man dann dieses Modell Wertstrom sinnvollerweise ein?
Das klingt nach einer Frage für Dirk.
Ja, der Dirk wollte jetzt erst noch mal auf das Thema Value eingehen.
Also, ich stelle die Frage mal zurück
oder stell du die Frage mal zurück.
Ich wollte auf das Thema Wert eingehen,
weil was ich auch noch interessant finde oder wichtig finde,
ist, wenn wir über Wert sprechen,
den wir erzeugen mit einem Wertstrom,
mit einem Wertströmen,
dann sind das unterschiedliche Werte, die wir erzeugen.
Also, wir haben ja gesagt,
unsere Sichtweise ist,
dass es ein betriebswirtschaftlicher Ansatz ist.
Aber es geht aus meiner Sicht,
wenn wir über Value sprechen, auch über andere Dinge.
Also zum Beispiel den Value,
den wir auch vielleicht für den Mitarbeiter erzeugen,
den Value, den wir für Lieferanten oder von Lieferanten bekommen.
Es geht darum, dass wir,
wie das der Black-and-Decker-CEO gesagt hat,
dass wir mehr machen als nur Output.
Wir reden also auch über Outcome.
Aber der Wert ist eben etwas,
was ein bisschen, ich finde, auch weiter gefasst ist.
Wir könnten auch überlegen,
ob nicht auch Nachhaltigkeit
oder soziales Engagement mit reinspielt.
Also rein eine Sichtweise,
eine Sichtweise,
wir müssen die Wertströme optimieren,
um möglichst viel Geld zu machen,
um Deckungsbeitrag zu erhöhen.
Das ist ein Wert.
Das kann ein Wert sein.
Es kann aber auch sein,
dass man einen Wert anders bezeichnet.
Also dieser Begriff Wert ist für mich total weit gefasst.
Sehr, sehr vielfältig.
Das wollte ich noch ergänzen zu der Sicht auf Wert.
Das bringt mich jetzt wieder zu einem anderen spannenden Punkt,
der mir da gerade eingefallen ist,
während du geredet hast, Dirk.
Wenn ich nämlich mich zurück erinnere
an Taichi Ohno,
der bei Toyota viele dieser Techniken und Überlegungen,
wie soll ich sagen, ins Leben gerufen hat.
Der hat ganz ausdrücklich gesagt,
Wertstromanalyse heißt für uns,
den Ablauf zu untersuchen zwischen
Kunde erteilt einen Auftrag für ein Auto
und Kunde bezahlt für das Auto.
Das war für ihn der Wertstrom.
Also er hat das ganz klar auf Kohle gemünzt.
Stopp.
Auf Kunde gemünzt.
Stopp.
Widerspruch.
Er hat es nicht nur auf Kunde gemünzt,
er hat es auch auf die Mitarbeiter gemünzt,
weil er schon darauf hingewiesen hat.
Vielleicht habe ich da ein unglückliches Wort verwendet.
Ich habe nämlich gesagt Kohle, Geld.
Ja, ja, aber jetzt hast du gesagt,
wenn du dich an den Herrn Ohno erinnerst,
ich hoffe, dass du nicht so alt bist,
dass du ihn noch persönlich erlebt hast an der Stelle.
Aber ich habe das Buch nicht gelesen,
das muss ich hier zugestehen,
aber ich habe mich damit beschäftigt.
Deswegen weiß ich, dass es eben auch nicht nur darum ging,
den Wert für den Kunden zu haben,
sondern auch auf die Mitarbeiter zu achten,
die in diesem Wertstrom agieren.
Also das vielleicht als kleine Ergänzung.
Ansonsten ist das okay für mich.
Okay.
Also so doll alt muss man nicht sein,
um ihn theoretisch noch persönlich kennengelernt zu haben,
da er bis 1990 sein Leben gefristet hat.
Aber persönlich habe ich ihn nicht kennengelernt.
Wie sieht es bei euch aus?
Naja, auch nicht.
Auch nicht.
Gut, dann hatten wir gerade die Frage zurückgestellt,
die ich dann jetzt einfach wieder vorhole.
Und zwar lautete die,
das Modell des Wertstroms zum Nutzen für irgendwas.
Wo habt ihr denn gute Erfahrungen gemacht
bei der Nutzung dieses Modells von Wertströmen?
Die Frage hast du mir ja eben gestellt.
Und dann werde ich jetzt auch nochmal die Chance ergreifen,
zu sagen, warum ich dieses Thema so interessant finde.
Nun kommen wir alle drei ja aus der IT-Welt.
Und die IT-Welt lebt ja davon,
wir auch, Methoden und Frameworks zu kaufen,
zu trainieren, anzuwenden.
Und das ist für mich etwas,
wo ich eigentlich sozusagen so einen übergreifenden Ansatz sehe.
Also wir reden hier nicht darüber,
dass irgendein Framework da ist,
was wir anwenden.
Also was wir sozusagen in der IT irgendwie fest anwenden.
Für mich ist das eine Art Sichtweise.
Also ich schaue mir meine Wertströme an.
Ich organisiere mich anhand von Wertströmen.
Und das ist für mich eben eher so eine,
es kann man auch Philosophie sagen,
aber es ist auf jeden Fall nicht ein Framework,
was ich sehen würde im Vergleich zu ITIL oder DevOps
oder Scrum oder anderen Dingen.
Für mich ist es eben ein Ansatz,
ein Unternehmen,
ein Unternehmen zu gestalten.
Und das ist das,
was ich einfach interessant finde an diesem Begriff,
an diesem Modell.
Ja, vielleicht müssen wir an der Stelle
dann auch tatsächlich noch mal
das so ein bisschen ausdifferenzieren und sagen,
es gibt einerseits das,
was du gerade angesprochen hast,
nämlich das Konzept,
vielleicht sogar die Philosophie eines Wertstromes,
das man sich zu eigen machen kann,
das man nutzen kann,
um über Prozesse und ihre Möglichkeiten
und Verbesserungen nachzudenken.
Und dann ist man eigentlich beim Wertstrommanagement gelandet
als eine Konsequenz,
sagen wir mal,
aus dieser Wertstromperspektive.
Sprich, sich gezielt und bewusst darüber Gedanken zu machen,
was sehe ich denn hier vor mir
in Form eines Wertstromes
und wo erkenne ich da Möglichkeiten,
etwas zu verändern, etwas zu verbessern.
Und dabei, um das jetzt auch noch zu sagen,
gibt es Techniken wie zum Beispiel
Value Stream Mapping,
die einem dabei helfen sollen,
zu visualisieren und systematisch Prozesse zu analysieren,
einen Ist-Zustand zu erfassen
und wie gesagt daraus dann
Verbesserungsprozentiale abzuleiten.
Und das finde ich ja genau das Coole,
das, was du gerade auch gesagt hast.
Ich komme nicht mit einem festgeschriebenen Framework,
mit einem festgeschriebenen Ansatz und sage,
das müsst ihr jetzt so machen
oder das solltet ihr so machen,
sondern ich komme mit dem Ansatz,
den Ist-Zustand mir anzuschauen.
Ich analysiere den Ist-Zustand
und das kann ich auf einer ganz abstrakten Ebene machen,
also ziemlich weit oben in einem Unternehmen.
Ich kann es aber auch total detailliert
auf einer tieferen Ebene machen.
Aber für mich ist es einfach super interessant,
immer zu sagen, es gibt einen Ist-Zustand
und den analysiere ich, den mappe ich,
wie du es gerade gesagt hast,
mit einer bestimmten Technik.
Also ich fange da an, wo das Unternehmen gerade ist.
Das finde ich so interessant.
Ja, nichtsdestotrotz ist es ja Teil von vielen Frameworks.
Wenn ich da jetzt an so einen großen Staubsauger
von Best Practices wie SAFE denke
oder an DevOps,
wo wir es in den Grundlagenschulungen
auch immer wieder definiert
und teilweise auch genutzt haben,
immer wieder tauschen,
immer wieder taucht das Thema auf.
Und wenn man sich die Historie mal anschaut,
kommt es ja, wie wir es gerade gesagt haben,
auch aus dem Lean-Ansatz, Lean-Management,
Toyota-Produktionssystem oder den ganzen anderen
darauf aufbauenden Gedanken und Sammlungen.
Und wir beziehen es aktuell aus unserer Sicht
natürlich mit unserem Podcast
DevOps auf die Ohren und ins Hirn
ja auch auf DevOps und die IT-Welt.
Und da finde ich eine Beschreibung,
die das Value-Stream-Management-Konsortium gemacht hat.
Wo kommt denn DevOps her?
Wo taucht es auf?
Aber genauso auch, wo ist denn der Bezug
zu Wertstrommanagement?
Und dass man sagt, okay,
man hat diese Projektdenkweise,
die dann über die Zeit vom Wasserfall,
über Scrum, Extreme Programming,
andere agile Frameworks,
Safe, Less und anderes
auch in Richtung große Unternehmen skaliert reinpasst.
Und man hat die Flow-Organisation,
den operativen Wertstrom,
die Produktionsprozesse,
die Dinge, die halt auch die längere Historie haben,
wie bei Toyota, wo man sagt,
okay, von der Bewegungsstudie,
Zeitaufnahme, Zeitreihenaufnahmen und ähnliches
über Lean und Kanban in der Produktion,
wo dann das Wertstrommanagement aufgetaucht ist.
Aber auch,
Lean IT,
Application Lifecycle Management,
agiles System administrieren,
agile IT Service Management Prozesse,
wo jetzt auch wieder das Thema
Wertstrommanagement auftaucht.
Es kommt also wieder,
also ist die Frage,
warum kommt es denn wieder?
Warum ist es jetzt gerade aktuell?
Warum ist es genauso
in den betriebswirtschaftlichen Sichten
in Produktionssystemen?
Relevant und aktuell,
aber auch in der IT-Welt
ein aktuell relevantes Thema.
Wie seht ihr das?
Da kann ich vielleicht darauf antworten
mit einem Schwank aus meiner Jugend.
Ich bin gespannt.
Genau.
Ich glaube,
du kennst die Geschichte auch schon.
Nämlich,
ich habe ja meine berufliche Laufbahn begonnen als Tester.
Und nach wie vor mag ich testen wahnsinnig gern.
Es ist unter allen Sorgen,
unter allen Softwareentwicklungsaktivitäten,
die, die mir am meisten Spaß macht.
Und als ich irgendwann mal
den Gedanken gefasst habe,
mich selbstständig zu machen,
habe ich mir gedacht,
ja, weißt du was,
dann wirst du irgendwie
selbstständiger Softwarequalität,
dann wirst du irgendwie Softwaretester.
Das kannst du, das magst du gerne, passt.
Bis ich irgendwann mal draufgekommen bin,
das geht gar nicht.
Ich kann nicht am Ende einer Entwicklung
irgendwie auftauchen
und dann eine Qualität hineinzaubern,
und das ist das,
damals habe ich von dem Begriff Wertstrom
und so noch nie was gehört gehabt.
Aber das ist das,
was mich schlussendlich auch zu DevOps geführt hat,
dass ich gesagt habe,
ich muss diese komplette Kette
irgendwie in den Blick bekommen,
damit ich am Ende sicher sein kann,
ein zufriedenstellendes,
ein wertvolles Ergebnis zu liefern.
Und ich glaube,
das ist die Antwort auf die Frage, Dirk.
Ja.
Was ist denn die Aufgabe eines Testers?
Ja,
Bugreports schreiben, ne?
Ja, Fehler finden.
Und da sage ich, nein, das ist es genau nicht,
weil es ist ja nicht deine Aufgabe als Tester,
Fehler zu finden,
sondern im Idealfall findest du keinen Fehler,
weil keiner drin ist.
Ja, andererseits,
als altgehender Tester,
lass mir sagen,
es ist wie mit dem Staubsauger,
es macht nur Spaß,
wenn es im Schlauch rasselt.
Okay, gut, alles klar.
Deswegen bin ich auch vielleicht kein Tester geworden.
Aber vielleicht,
um jetzt wieder weg vom Staubsauger
und von einem anderen Schwank aus deiner Jugend zu kommen,
ich glaube,
Volker wollte so ein bisschen auch in die Richtung,
wozu kann man das überhaupt sinnvoll verwenden?
Warum machen wir das überhaupt?
Und da finde ich auch einen ganz wichtigen Punkt.
Also abgesehen davon,
dass man natürlich mit so einer,
mit so einem Value Stream Mapping,
also mit der Transparenz machen des Wertstroms,
kann man natürlich sehr gut kommunizieren und optimieren.
Was ich aber sehr interessant finde,
ist,
dass genau über das Thema Lean Management
auch eine ganze Reihe,
auch eine ganze Reihe von Metriken mitkommt.
Und aus meiner persönlichen Sicht,
also ich bin überzeugter Angelist,
aber aus meiner persönlichen Sicht
gibt es zu wenig Messgrößen in Scrum jetzt zum Beispiel.
Und das finde ich einfach interessant,
dass ein paar Metriken mitkommen,
wonach ich eben auch optimieren kann.
Also ich kann etwas messen
und kann einen,
habe eine sachliche Grundlage über die Diskussion.
Es geht ja nicht darum,
dass ich mit diesen Messen Menschen,
ja,
ich sozusagen,
also Menschen loswerden will,
sondern ich möchte einen Ablauf messen,
um zu gucken,
ist das denn gut oder ist das nicht gut?
Und dieses Messen sollte,
diese Metriken sollten sozusagen auch transparent nachvollziehbar sein.
Und deswegen finde ich es wichtig oder interessant
beim Wertstrommanagement,
dass Metriken mitgeliefert werden,
dass Metriken mitgeliefert werden,
um etwas zu messen.
Wie gesagt,
ich will niemanden kontrollieren,
also keine Personenkontrolle und so etwas.
Aber ich möchte versuchen,
aber ich möchte verlässliche,
ich möchte sachliche Grundlagen haben,
auf denen ich etwas messen und bewerten kann.
Welche Metriken würdest du denn empfehlen?
Was sind denn die Metriken aus deiner Sicht,
die am hilfreichsten sind?
Durchlaufzeit zum Beispiel.
Wie lange braucht etwas,
um durchzulaufen?
Also eine,
wenn ich jetzt an die Autos denke,
dann ist das ein Auto,
weil ein Auto bringt erst dann Wert,
wie Luca ja vorhin schon gesagt hat,
wenn der Kunde es hat und bezahlt hat.
Und wenn ich das übertrage auf die IT,
sind das einfach Aufgaben,
die so schnell wie möglich durchlaufen sollten.
Und wenn sie nicht so schnell durchlaufen,
dann schaffen sie keinen Wert,
Wert Strom.
Und dann sollte ich dafür sorgen,
dass sie so schnell wie möglich durchlaufen.
Also dann Blockaden beseitigen,
Hindernisse beseitigen zum Beispiel.
Aber Luca,
du kennst bestimmt auch noch eine Metrik, oder?
Durchlaufzeit ist auf jeden Fall spannend.
Spannend ist auch die Frage nach der,
wie nennt sich das dann,
nach der Zykluszeiteffizienz.
Das heißt,
von der Durchlaufzeit,
ich sage jetzt mal in Kalenderzeit,
und der tatsächlich investierten Arbeitszeit.
Da kommen nämlich zum Teil ganz,
ganz furchtbar enttäuschende Effizienzen raus,
von unterhalb von einem Prozent.
Mit anderen Worten,
man arbeitet konkret an einer gegebenen Aufgabe
eine vergleichsweise kurze Zeitspanne,
ich sage jetzt mal zwei Stunden.
Aber dieser Auftrag braucht irgendwie zwei Monate,
um unseren Prozess zu durchlaufen.
Und diese Effizienzen,
von unterhalb einem Prozent,
hören sich erstmal völlig abstrus
und aus der Luft gegriffen an.
Aber jeder von uns, glaube ich,
kennt aus seiner persönlichen Erfahrung
solche Prozesse.
Und es ist natürlich jedem leicht ersichtlich,
dass das zumindest wahnsinnig frustrierend ist,
aber zum Teil eben auch ein wirkliches,
ernsthaftes geschäftliches Problem darstellen kann.
Und allein sich solche Umstände bewusst zu machen
und zu sagen,
was passiert denn hier,
was für ein Missverhältnis existiert denn hier,
kann häufig ein sehr heilsamer Anstoß sein,
zu sagen,
irgendwas müssen wir doch machen können.
Und wenn wir es nur von zwei Monaten Wartezeit
auf anderthalb Monate reduzieren,
dann ist zwar die Prozentzahl nicht besonders größer geworden,
aber de facto wartet der Kunde schon mal zwei Wochen kürzer.
Das ist doch auch schon mal schön.
Und vor allen Dingen,
was ich daran interessant finde an deinem Beispiel ist,
normalerweise würde man ja diese zwei Stunden Tester zum Beispiel,
dass man sagt, Tester, zwei Stunden sind zu lang,
wir müssen schneller werden,
teste mal in einer Stunde.
Das heißt, man gewinnt mit einem vergleichsweise hohen,
vergleichsweise hohen Einsatz,
nämlich den Druck auf den Tester auszuüben,
eine Stunde.
Wenn man aber diese Wartezeit,
diese Liegezeit verkürzen würde,
was vielleicht mit einer Prozessoptimierung
oder Wertstromoptimierung viel einfacher wäre,
gewinnt man zwei Monate.
Also an den richtigen Stellen.
Und das finde ich einfach auch,
das ist wirklich das,
was ich eben meinte mit dem Beispiel.
Es geht darum, den Durchfluss eben zu optimieren
und das auch transparent zu machen.
Also insofern gutes Beispiel.
Da habe ich auch eine kleine Anekdote,
die ich mit einbringen will.
Und zwar der Aspekt,
den ein CIO mal gebracht hat.
Und zwar fokussiert euch auf das,
was Wert liefert.
Ihr Entwickler,
es wäre zwar schön,
wenn ihr schneller tippt,
aber das alleine,
nur schneller zu tippen,
liefert keine schnellere Wertschöpfung.
Ja, das stimmt.
Ja.
Ich würde gerne noch eine weitere Metrik ergänzen.
Ich bin ja ein Freund von Qualitätsmanagement
und von Qualität,
also von eingebauter Qualität.
Und da gibt es diese schöne Kennzahl
oder den schönen Ansatz
first time right.
Also mach es auf Anhieb richtig.
Und die Frage ist ja immer,
wie gehe ich damit um,
wenn mir jemand schlechte Qualität liefert
in meiner, ich sage mal Prozesskette.
Es kann ja auch ein Wertstrom sein.
Es ist ja im Prinzip erstmal das Gleiche.
Wie gehe ich damit um,
wenn ich am Ende der Kette,
also Luca wieder als Tester,
da sitze ich und der liefert mir schlechten Code.
Ja, was mache ich denn?
Und das finde ich einfach interessant,
zu gucken,
wie viele Ansätze haben wir gebraucht,
um es richtig hinzubekommen.
Also wenn ich jetzt first time right nehme,
mit dem Ziel,
es auf Anhieb richtig zu machen.
Und dass Luca eben als Tester
von hinten versuchen sollte,
die Qualität nach vorne zu bringen,
also shift left,
ist ja auch ein DevOps-Thema.
Das eben hinzubekommen
und das mit einer Kennzahl zu versehen,
wie oft mussten wir quasi zurückgehen
und wie oft haben wir es geschafft,
auf Anhieb einen richtigen Job zu machen,
finde ich interessant.
Und da kommt auch, glaube ich,
manchmal auch eine gewisse Problematik her.
Jetzt kommen wir auch zu der Frage,
vielleicht auch zu der Frage,
wann sollte man sich
um Baystream-Management kümmern
und was bedeutet das überhaupt?
Und das bedeutet für mich,
organisatorisch auch etwas zu verändern.
Denn ich muss ja,
ich nehme wieder Luca als Tester,
ich muss ja von hinten,
ich muss ja von hinten nach vorne gehen
und damit gehe ich eventuell über Bereichsgrenzen,
über Abteilungsgrenzen.
Ich gehe aus meinem Silo raus
in einen anderen Silo vielleicht rein.
Und das finde ich einfach auch super interessant,
wenn man das über ein Mapping transparent macht,
also mal aufzeigt, was da passiert,
diese zweieinhalb Monate Wartezeit.
Und wenn man dann dahin geht und sagt,
wie können wir das verändern?
Wie können wir da ein besseres Verhältnis hinbekommen?
Und auch,
haben wir denn was verändert?
Wenn ich jetzt zum Beispiel
wieder auf dein Beispiel von vorhin zurückgreife, Dirk,
und sage,
jetzt habe ich es irgendwie geschafft,
keine Ahnung,
meine Testabläufe zu optimieren
und anstelle von zwei Stunden
brauche ich jetzt für den Test
bloß noch eine Stunde.
Und dann schaue ich mir meine Durchlaufzeiten an
und stelle fest,
oder meine Zykluszeiteffizienz,
ja auch die Durchlaufzeit,
es hat sich genau gar nichts geändert.
Das ist völlig,
geht dem Rauschen unter.
Und jetzt weiß ich es wenigstens schwarz auf weiß,
auch wenn ich es natürlich nicht gerne höre,
aber dieser Ansatz führte zu nichts.
Da weiß ich jetzt Bescheid.
Zumindest für den Test.
Zumindest für den Kunden,
wenn man aus Kundensicht schaut.
Ich meine,
für die Entwickler vielleicht schon,
weil sie ein Stück ihrer Aufgaben automatisiert haben
oder weil sie jetzt schneller durch die Testsuite kommen,
weil sie vielleicht ein paar Tests auch eliminiert haben,
die nicht werthaltig waren,
aber für den Kunden halt nicht.
Ja gut,
aber ich sage es mal so,
wenn es für den Kunden was gebracht hat,
dann müsste es sich ja an irgendeiner Stelle bemerkbar machen.
Was heißt denn nicht,
dass ich insgesamt schneller
oder dass ich mehr Features in der gleichen Zeit auf den Markt bringe oder so,
auch wenn die Durchlaufzeit pro Feature immer noch unbefriedigend ist oder sowas.
Also wenn du tatsächlich was Positives bewirkt hast,
dann muss es ja an irgendeiner Stelle erkennbar werden.
Auch wenn man jetzt natürlich sagen kann,
ja, wir messen wahrscheinlich nicht alles.
Und so wie du sagst,
Falco, auch Entwicklerzufriedenheit ist ja ein ein lohnendes Ziel,
dass jemand sagt,
meine Arbeit macht mir mehr Spaß,
weil meine,
weil mein Prozess mir nicht auf den Senkel geht.
Also wann ist der richtige Zeitpunkt,
über Value Stream Management,
Wertstrommanagement Gedanken zu machen,
wenn wir bereit sind,
auch Veränderungen vorzunehmen?
Ja, also das ist ein guter Punkt.
Wenn man sowieso nicht in der Lage ist,
entweder sachlich oder gedanklich etwas zu verändern,
dann braucht man sich über Veränderungen keine Gedanken zu machen.
Das ist wahr.
Aber wenn ich auf dem Standpunkt stehe,
dass ich sage,
irgendwas muss ich doch besser machen können,
ich glaube,
dann bist du schon an der richtigen Stelle.
Und dann kann diese Wertstromperspektive
hilfreiche Impulse liefern.
Finde ich auch interessant,
weil damit wird für mich ja auch klar,
dass Wertstrommanagement,
auch wenn es so klingt wie betriebswirtschaftlicher Ansatz
und wir haben Kennzahlen,
es ist ein Mittel für Organisationsentwicklung,
für Transformation.
Und damit passt es natürlich auch sehr schön in das Thema DevOps mit rein.
Also wenn ich auch wieder auf den Titel unseres Podcasts schaue.
Also klingt ganz spröde,
Wertstrommanagement,
aber da steckt ganz viel,
ganz viel mit drin.
Und wie ihr sagtet,
es geht darum,
Veränderungen anzustoßen,
Veränderungen zu begleiten.
Und vielleicht auch da wieder,
was mir besonders gut daran gefällt,
ist vielleicht auch ein bisschen naiv.
Das können wir gleich nochmal diskutieren.
Wen nehme ich denn mit dazu?
Also wen beteilige ich denn?
Und das finde ich eben auch interessant.
Der erste Schritt sollte eigentlich sein.
Nein,
es ist nicht der erste Schritt.
Ihr dürft mich gleich korrigieren.
Ich sage jetzt mal,
es ist der erste Schritt,
die richtigen Menschen zusammenzubringen.
Nämlich die Menschen,
die in dem Wertstrom arbeiten.
Und das finde ich eben super interessant.
Nämlich nicht irgendwelche Berater oder Führungskräfte.
Die müssen auch mit dabei sein oder sollten auch mit dabei sein.
Aber die Menschen,
die in diesem Wertstrom arbeiten,
die diesen Wert erzeugen,
die mit dazu zu nehmen,
weil die wissen nämlich,
wo diese zweieinhalb Monate Testzeit herkommen.
Luca, der Tester am Ende der Nahrungskette hinten,
der sieht,
dass er immer nur Müll bekommt beispielsweise.
Und jetzt fragt ihn mal einer
und jetzt kann er berichten,
wie häufig er Dinge zurückgeben muss.
Ja, oder wie häufig dann auch,
das ist ja das klassische Leid des Testers,
dass die Sachen dann viel zu spät ankommen,
ganz kurz vorm Auslieferungstermin,
weil alle trödeln rum,
alle lassen sich Zeit.
Und der, der sich keine Zeit mehr lassen kann,
weil er am Ende von der Nahrungskette ist,
das ist dann halt der Tester.
Das habe ich so oft erlebt,
dass ich eigentlich offiziell ein Zeitfenster von,
ich weiß nicht,
zwei Wochen gehabt hätte,
um eine Lieferung in aller Ruhe zu testen
und bereit zu machen für die Auslieferung.
Ja, dann kam das Softwarepaket aber doch erst 18 Stunden
vor der Auslieferung bei Benja an.
Und dann waren sie irgendwie alle ganz enttäuscht,
dass ich das jetzt nicht in 18 Stunden
alles irgendwie durchbollere.
Hast du keine Testautomatisierung
in der Entwicklungszeit aufgebaut?
Oder wie?
Wieso ging das nicht?
Die Tests waren vollautomatisiert.
Aber das waren sprichwörtlich waschkorbweise Steuergeräte,
Automotive Steuergeräte.
Allein,
allein die alle anzustecken und abzustecken
dauert quasi diese 18 Stunden.
Ach so, physische Hardware in the Loop Tests.
Warum habt ihr da keine Virtualisierung vorgenommen?
Die war vorher schon.
Das war wirklich die Probe aufs Exempel.
Geht das Ding wirklich?
Das war cool,
wenn ich das jetzt mal so am Rande sagen darf.
Da gab es wirklich Racks,
da liefen auch wirklich Einspritzpumpen drin.
Also da haben dann wirklich die Einspritzpumpen drin gerattert.
Und wenn der seine Tests gefahren hat,
dann hast du auch gehört,
jetzt fährt er schneller,
dann rattern die schneller
und dann rattern sie wieder langsamer und so.
War schon,
war schon cool.
War schon cool, was die da gemacht haben.
Klingt wirklich cool.
Ja, das stimmt.
Genau.
Aber ich finde,
wir müssen noch mal einen kleinen Schritt zurückgehen,
bevor wir uns darüber unterhalten,
wer da alles dazukommen soll.
Weil ich finde,
wir haben das jetzt gerade so ein bisschen zu flapsig abgebügelt
mit dem,
wann ist denn der richtige Zeitpunkt
für so eine Wertstromanalyse,
für so ein Wertstrommapping.
Wann denn?
Wenn der Prozess noch gar nicht existiert,
wenn der schon längst existiert,
wenn der prototypisch existiert,
wenn die Firma,
keine Ahnung,
mehr als 50 Mitarbeiter hat.
Was sagt ihr denn?
Was sind denn so Paradebeispiele,
wo es vielleicht eine blöde Idee ist
oder wo es eine gute Idee ist?
Lass mal überlegen.
Also wir haben letztendlich eine Möglichkeit,
wenn wir über Wertstromdesign nachdenken,
auch zum Zeitpunkt,
wo man über neue Prozesse nachdenkt,
einen werthaltigen Prozess von Anfang an
zu designen.
Fände ich letztendlich sinnvoll,
wenn man das auch visualisiert
und das in Form von einer Wertstrommap letztendlich,
Value Stream Map,
auch als Diskussions- und Kommunikations-
und Designmedium nutzt.
Von daher,
vielleicht auch bevor ein Prozess am Laufen ist.
Häufig ist es gut,
wenn man Kommunikation zwischen Abteilungen
über Silo-Grenzen und anderes hinweg
aufbrechen will
und Ende-zu-Ende-Prozesse
vielleicht auch im Rahmen einer Transformation,
wenn man sowieso schon über Veränderungsprozesse nachdenkt,
dann gleich in der Form bringen will,
die dann auch von allen Beteiligten besprochen worden ist,
sodass auch jeder sich da wiederfindet,
dass auch jeder sieht,
was die anderen machen.
Dass man halt auch überlegen kann,
gibt es Prozesse, die Prozessschritte,
die in dem Wertstrom ablaufen,
die vielleicht gar keinen Kundennutzen
oder keinen Unternehmensnutzen haben,
die man vielleicht einfach,
wegen ihrer langen Warte- und Liegezeiten
irgendwo anfassen und optimieren muss,
sodass man eine Chance hat,
am Ende einen Prozess zu haben,
den man vielleicht auch im Ganzen
gut automatisieren kann.
Dass man halt auch an den Stellen
über Übergaben und anderes nachdenkt
und am Ende letztendlich dahin kommt,
die Durchlaufzeit
vielleicht von Monaten auf Minuten zu reduzieren,
weil man halt sagt,
okay, da sind so viele Dinge dabei,
wo man Wartezeiten reduzieren kann,
wo man letztendlich optimieren kann,
wie die Rücklauf- oder Durchlaufquoten
oder die Erfolgsquoten First-Time-Ride zu 100 Prozent
ist natürlich immer super,
wenn man das erreichen kann
und dazu ist es letztendlich hilfreich
und das passt auch gut zum DevOps-Gedanken.
Dieses Ende-zu-Ende-Fluss
von der Kundenanforderung bis zum Kundennutzen,
als durchgängigen Prozess zu verstehen
und ihn dann so weit zu bringen,
dass man einen möglichst hohen Automatisierungsgrad
und dadurch wenig Liegezeiten
und insofern dann auch eine kurze Durchlaufzeit generieren kann.
Das erinnert mich ganz stark an meine Doktorandenzeit
an der Uni Magdeburg im Lehrstuhl für Logistik.
Kommt auch spannend aus deiner Jugend, Falco.
Ja, genau, darum ging es halt.
Die Prozesse meist dann im produzierenden Gewerbe zu hinterfragen
und dann auch aufzunehmen, zu visualisieren
und dann so weit zu optimieren,
dass es möglichst einfach ist,
dann halt zum Beispiel Robotertechnik einzusetzen,
Fließbänder und so dann mit Automatisierung zu arbeiten,
aber eben auch an den Stellen, wo manuelle Arbeit
in Fertigungsgruppen,
in Fertigungszentren oder Ähnlichem organisiert ist,
dann so zu bringen,
dass sie halt zum Beispiel in einer Taktstraße,
in einem gemeinsamen Rhythmus,
gemeinsamen Takt entsprechend ablaufen können.
Das ist mich auch wieder so an Iterationen im agilen Arbeiten,
Scrum, Sprints oder Save-Iterationen und Programmingremente erinnert,
dass man da halt versucht, irgendwie einen gemeinsamen Rhythmus zu erreichen,
dann regelmäßig dann die Fortschritte zu integrieren,
und dann halt im nächsten Schritt wieder weiterzubringen,
sehe ich immer wieder Parallelen.
Ich finde das auch spannend, Falco,
dass du ja jetzt auf physische Produktionsprozesse
und sowas gegangen bist,
weil ich finde, da ist ein ganz starkes Argument drin
für Value-Stream-Mapping,
insbesondere in unserem IT-Kontext,
in unserem nicht-physischen Kontext,
weil diese Analysen da glaube ich noch viel wirkmächtiger sind,
gerade wenn ich dann Wertströme mal visualisiere
und wirklich in Gedanken abnehme,
in Gedanken abschreite.
Eine Produktionslinie,
die kann ich immer wirklich mit meinen eigenen zwei Füßen entlanglaufen,
und wenn da irgendwo 100 Paletten mit Getriebegehäusen stehen,
dann stehen da 100 Paletten mit Getriebegehäusen,
und jeder kann sehen, dass das blöd ist,
und dass die im Weg sind.
Aber 1000 Jira-Tickets schauen auch nicht anders aus als 10 Jira-Tickets.
Und insofern, um das einfach nochmal zu sagen,
es ist glaube ich ein noch viel mächtigeres Kommunikationsmedium,
Werkzeug, um überhaupt erstmal auf einen gemeinsamen Stand zu kommen,
um überhaupt sich eine gemeinsame Sprache zu erarbeiten,
eine gemeinsame Sicht zu erarbeiten.
Dirk, ich habe dich lange genug warten lassen.
Och, ich konnte nochmal ein bisschen sammeln
und meine Wörter nochmal in die richtige Reihenfolge bringen jetzt.
Vielleicht nochmal zurück zu der Frage.
Die Frage war ja,
kann man es im Prinzip auf der grünen Wiese auch anwenden?
Und meine erste Antwort wäre gewesen, nein.
Beziehungsweise wende ich es meistens an,
wenn schon etwas da ist,
also um Dinge zu analysieren.
Und ich bin jetzt durch Falkos Aussage,
er hat ja ganz viel über Prozesse gesprochen,
ich glaube Luca hat auch immer das Wort Prozesse genommen,
bin ich so ein bisschen an das Buch erinnert worden,
was ich gerade mit sechs anderen wunderbaren Menschen
zusammen geschrieben habe.
Ich erkläre das Buch ganz, ganz kurz.
Entschuldigt dieses Product Placement,
diese Sendung wird finanziert von das Buch.
Nein, Spaß beiseite.
Und ich erkläre auch gleich, warum ich auf dieses Buch gekommen bin.
Also, das Buch heißt,
das Buch heißt wertvoll, eine Value Stream Story.
Und dieses Buch besteht quasi aus zwei Teilen,
nämlich einem ersten Romanteil.
Und das war der erste Punkt, wo ich daran erinnert worden bin.
In diesem Roman nutzen wir quasi Wertstrommanagement,
wir nennen es im Roman, schreiben wir von Value Stream,
nutzen wir das, um anhand einer fiktiven Unternehmung,
Jakobsens Apfelsaftproduktion, nutzen wir Value Stream Management,
um das Unternehmen ein bisschen voranzubringen.
Also, da ist es im Prinzip schon so, dass man zwar Abläufe hat,
aber mit Value Stream Management zumindest in unseren fiktiven Unternehmen
einen neuen Ablauf designt.
Und das andere, der zweite Teil dieses Buches,
das sind zehn Fachbeiträge.
Und das ist der Punkt, wo ich darauf gestoßen bin.
Ein Fachbeitrag heißt, Value Streams sind ungleich Prozesse.
Also, es ist nicht so,
dass wir mit Value Stream Management jetzt ein wunderschönes neues Wort
für Prozessmanagement haben.
Da steckt schon ein bisschen was mit dahinter,
nämlich der Punkt, dass wir uns wirklich an den Wert orientieren,
dass wir uns an den Kunden orientieren.
Prozesse laufen ja ab und produzieren irgendetwas.
Und deswegen verweise ich gerne auf dieses Buch.
Wir packen bestimmt in die Shownotes auch einen Link rein,
dass man das Buch zumindest mal weiß, was dahintersteckt.
Man kann es auch kaufen.
Kleiner Hinweis, in Deutschland wird man von Fachbüchern nicht reich.
Also, wenn ich jetzt dafür Werbung mache,
ist das nicht so, dass ich davon reich werde.
Um das auch kurz zu erklären.
Also, für mich ist das einfach auch ein wichtiger Punkt.
Wertströme sind ungleich Prozesse.
Und man kann mit Wertströmen, denke ich,
auch auf der grünen Wiese anfangen.
Also, das ist das, was ich quasi eben im Rahmen eurer Erläuterung gelernt habe.
Ja, ich glaube, man kann es vielleicht ein bisschen verallgemeinern
und kann sagen, es gibt ein paar Naturwerte,
man kann sagen, es gibt ein paar natürliche Punkte,
wo sich Wertströme oder wo sich Wertstromanalysen anbieten,
weil sie einem schon fast so ein bisschen in den Schoß fallen.
Einer dieser Fälle ist, wenn man gerade anfängt,
sich über einen nagelneuen Ablauf Gedanken zu machen,
dann kann man ja direkt diese von dir eingangs zitierte
Wertstromperspektive einnehmen, Dirk.
Man kann sagen, okay, wenn ich es aus dieser Warte betrachte,
macht das denn alles Sinn, was ich mir jetzt gerade so einbilde?
Genauso auch, was der Falco vorhin gesagt hat,
wenn ich eine tiefgreifende Veränderung mache,
zum Beispiel, weil ich Automatisierung einführen möchte,
dann quasi als Nebenprodukt fällt mir da ja etwas raus,
das schaut schon aus wie eine Wertstromanalyse.
Dann muss ich ja zerlegen in verschiedene Schritte,
in Arbeitsergebnisse, die muss ich irgendwie, keine Ahnung,
hin und her transportieren, übertragen, transformieren und so fort.
Das heißt, es gibt so gewisse Punkte,
da kriege ich eine Wertstromanalyse eigentlich für lau.
Insofern, ich glaube, erstens, es ist immer eine gute Idee,
und zweitens, manchmal ist es eine besonders gute Idee.
Ja, es hat halt immer Vorteile,
je nachdem, wofür man letztendlich das Konzept nutzen will.
Wenn es halt nur darum geht, gemeinsames Verständnis zu erzeugen,
was aus meiner Sicht auch ein legitimes Mittel ist,
einfach Transparenz, Sichtbarkeit, Visualisierung zu nutzen,
um überhaupt zu erklären, was machen wir und wie läuft das,
was machen wir und wie läuft das ab?
Hat das an sich einen Wert, die Kommunikation, das Verständnis?
Dann kann man es natürlich in die Analyse gehen und Optimierungen vornehmen.
Man kann auch einfach an der Stelle aufhören und sagen,
wir verstehen jetzt, wie es geht, und das reicht uns fürs Erste.
Kann ja völlig okay sein.
Häufig geht man natürlich den weiteren Schritt, versucht zu optimieren,
wertschöpfende Tätigkeiten in den Vordergrund zu stellen,
und vielleicht Verschwendung zu eliminieren, Wartezeiten, Liegezeiten
und Ähnliches zu eliminieren.
Es kann hilfreich sein, um eine gemeinsame Sprache aufzubauen.
Also der eine spricht halt, keine Ahnung, vom Testen,
der andere spricht von Qualitätssicherung,
der nächste spricht halt von Kundenfreundlichkeit und gutem Produkt.
Letztendlich reden sie vielleicht alle von dem gleichen Schritt
in der Wertstromkette.
Insofern kann auch da es hilfreich sein,
zum Verständnisaufbau auch eine gemeinsame Sprache zu finden.
Und es ist natürlich ein hilfreiches Werkzeug,
um auch Arbeitsprozesse zu vergleichen.
Zum Beispiel habe ich in einem Unternehmen,
das IT-Servicemanagement macht,
virtuelle Maschinenserver in verschiedenen Rechenzentren hostet
und für Kunden auch zur Verfügung stellt.
Und da gibt es halt in den unterschiedlichen Standorten
unterschiedliche Arbeitsweisen.
Unterschiedliche Toolsets, die im Einsatz sind,
unterschiedliche Reihenfolgen,
teilweise sogar von Wertstromprozessen oder Wertstromsichten.
Und da kann auch eine Vereinheitlichung ein sinnvolles Ziel sein,
wenn man halt zwei Produktionsstraßen hat,
die ähnliche Ergebnisse liefern,
aber trotzdem unterschiedlich darin vorgehen.
Und wenn man versucht, dann halt vielleicht auch
eine Vereinheitlichung zu erreichen,
um das Ganze mehr gemeinsam zu optimieren
oder auch die Tool-Landschaft zu vereinheitlichen,
kann das hilfreiches Mittel und Medium sein,
eine Wertstromanalyse.
Ist die Wertstromanalyse,
Value-Stream-Mapping, der erste Schritt?
Muss man vorher noch an irgendwas anderes denken?
Welchen Wertstrom will ich denn genau angucken?
Ist ja vielleicht so ein Thema,
eine Frage, die man sich vielleicht vorher beantworten muss.
Ja, also erstmal die Frage, welchen Wertstrom?
Und ich habe ja vorhin gesagt,
ihr dürft mich gerne korrigieren.
Ihr habt es bis jetzt noch nicht gemacht,
wenn ihr euch erinnert,
so vor 10, 15 Minuten habe ich was erzählt von,
dass die richtigen Leute zusammenkommen,
also die, die im Wertstrom mitarbeiten.
Und davor finde ich noch einen ganz wichtigen Punkt.
Und Falco, du hast mich eben schon auf diesen Hinweis
von mir jetzt gebracht,
du hast von Kunden gesprochen und von gemeinsamer Sprache.
Das, was ich eben auch interessant finde, ist,
wenn man mit dieser Technik von dem Value-Stream-Mapping,
wenn man startet, ist eigentlich sozusagen der erste Schritt,
also der Schritt Null quasi, die Stimme des Kunden.
Ja, also sich zu überlegen, aha, ich will Wert schöpfen.
Ja, ist ja wunderschön.
Da muss ich ja jemanden haben, der bewerten kann,
ob das wertvoll ist, also ob das Wert für ihn generiert.
Und auch das, finde ich, ist ein Unterschied,
zumindest in der Sichtweise zu einem Prozessmanagement.
Also insofern, um das mal klar zu machen,
der erste Schritt ist, wenn man diese Frage generiert,
wenn man diese Frage geklärt hat, wir können etwas verändern,
wir wollen etwas verändern, dass man dann sagt,
okay, was ist die Stimme des Kunden?
Was will der Kunde von uns?
Und allein das ist auch schon mal häufig eine sehr hilfreiche
und wertvolle Aktivität, nämlich klar zu machen,
was will der Kunde von uns?
Und da ist man dann manchmal auch vielleicht gar nicht ehrlich
oder man weiß gar nicht, was der Kunde wirklich will.
Und auch das finde ich einen schönen Nebeneffekt.
Man macht sich mal wirklich Gedanken,
was liefern wir alle in einem Wertstrom,
einen Wert für einen Endkunden?
Also insofern, das ist vielleicht nochmal
der Vollständigkeit halber zu ergänzen.
Der erste Schritt ist, sich über den Wunsch,
über die Stimme des Kunden Gedanken zu machen.
Im Rahmen einer Wertstromanalyse, also Value-Stream-Mapping?
Oder noch davor?
Also für mich ist das, also man kann es natürlich vorher machen,
aber für mich ist es so,
Schritt oder Aktivität in der Value-Stream-Mapping,
also in der Analyse,
weil ich damit eben auch sicherstellen kann,
über welchen Wertstrom rede ich überhaupt?
Also ich habe mir einen Wertstrom überlegt
und dann fange ich an,
wer ist der Kunde dieses Wertstroms?
Was sind die Stakeholder?
Und welchen Wert liefere ich diesen Kunden,
diesen Stakeholdern?
Wie geht es dann weiter,
wenn man letztendlich weiß,
was man wert,
was man an Wert liefert,
für welche Kunden?
Wie muss man sich so eine Wertstromanalyse vorstellen?
So, verehrte Zuhörerinnen und Zuhörer,
an der Stelle etwas überraschend knall ich euch jetzt
mitten in die Aufnahme hinein,
denn wir haben während der Unterhaltung festgestellt,
dass wir das Thema so ein bisschen unterschätzt haben
und dass wir ihm gerne den Raum einräumen wollen,
der ihm gebührt.
Mit anderen Worten,
dass 45 Minuten einfach zu kurz sind,
um sich diesem Thema ausrechnen zu können.
Daher haben wir beschlossen,
dass wir diesen Podcast
wieder mal zu einem Zweiteiler machen.
Was ihr jetzt gehört habt,
war der erste Teil.
Der zweite Teil wird in Kürze folgen
und enthält dann unsere Gespräche darüber,
wie man das denn vielleicht praktisch umsetzt,
wie man eine Wertstromanalyse
jetzt tatsächlich konkret handwerklich angeht,
was einem dabei vielleicht passieren kann,
was man dabei beobachten kann,
wie man damit umgeht.
Das heißt,
diese Folge, die jetzt gerade endet,
war vielleicht ein bisschen
eine etwas theoretischere,
auf höherer Flughöhe befindliche Folge
und die nächste Folge wird hoffentlich
noch etwas konkreter,
noch etwas unmittelbarer sein.
Ich bedanke mich bis hierhin
ganz herzlich für eure Aufmerksamkeit
und ich hoffe,
dass ihr euch auch die zweite Folge
noch mit großem Genuss anhören werdet.
Die ist ein bisschen kürzer als diese hier.
Die ist, glaube ich,
bloß ungefähr 35, 40 Minuten.
Aber jedenfalls,
da ist auch ganz viel tolles Zeug dabei.
Ich habe sie auch schon fertig geschnitten.
Und ich freue mich schon darauf,
dass ihr sie anhört.
An dieser Stelle vielen Dank fürs Zuhören,
auch im Namen von Dirk und Falko,
die jetzt natürlich nicht
ihre üblichen Grüße am Ende reinwerfen,
weil das alles so ein bisschen
holteripolter mitten unterm Gespräch war
und wir wollten unseren Fluss nicht verlieren.
Macht’s wunderbar gut.
Habt ein wundervolles Weihnachtsfest.
Ich schneide diese Episode am 23.12.
und werde sie jetzt auch gleich veröffentlichen.
Ich freue mich mit euch
auf ein ganz schönes Jahr 2023.
Macht’s gut. Bis bald. Ciao.
Auf Wiedersehen.