Die Ablösung von Legacy-Systemen ist weit mehr als ein technisches Projekt – es ist ein Transformationsprozess, der das gesamte Unternehmen betrifft. In dieser Episode verrät uns Tanja Friedel, warum das frühzeitige Einbinden von Produktmanager:innen sicherstellt, dass neue Systeme nicht nur technisch moderner sind, sondern tatsächlich echten geschäftlichen Mehrwert schaffen - denn anders kann man ein solches Investment auch kaum rechtfertigen.

2025-01-31 Thumbnail

PeerTube Video - no Big Tech!

YouTube Video

Audio als Podcast

MP3 Download
Infos und Feeds zum Audio als Podcast

Hinweis: Die nachfolgenden Texte wurden mit KI erstellt und können somit Fehler enthalten.

Warum Legacy-Transformation mehr als nur Technik braucht

Die Migration von Legacy-Systemen wird oft als rein technische Aufgabe betrachtet. Dabei geht es vermeintlich nur darum, alte, schwer wartbare Systeme durch moderne, besser wartbare Lösungen zu ersetzen. Doch dieser Ansatz greift zu kurz und verschenkt enormes Potenzial. Um wirklich erfolgreiche Legacy-Transformationen durchzuführen, braucht es eine ganzheitliche Perspektive – und vor allem Produktmanagement.

Mehr als nur technische Modernisierung

Produktmanagement geht weit über das rein Technische hinaus. Es umfasst die strategische Steuerung eines Produkts von der Marktanalyse über die Konzeption bis zur kontinuierlichen Weiterentwicklung. Produktmanager:innen bringen dabei ein breites Skillset mit:

Bei Legacy-Transformationen ist dieses ganzheitliche Skillset besonders wichtig. Denn eine reine 1:1-Migration des Status Quo verschwendet die Chance, echten Business Value zu generieren.

Business Value durch nutzerzentrierte Transformation

Ein Beispiel aus der Praxis: Ein Legacy-System für die Bestellung stark konfigurierbarer Produkte sollte abgelöst werden. Die erneute Bestellunge einer bereits erstellten Konfiguration war ein wichtiger, schlecht unterstützer Use Case, der gleichzeitg einfach implementierbar war. Bei der Ablösung wurde er zuerst implementiert und der Prozess optimiert. Ergebnis: Zeit- und Kostenersparnis für alle Beteiligten mit wenig Entwicklungsaufwand.

Dieser Fall zeigt: Der eigentliche Mehrwert entsteht nicht durch die technische Modernisierung an sich, sondern durch das Verständnis und die Optimierung der zugrundeliegenden Geschäftsprozesse. Dafür braucht es:

Erfolgsfaktoren für die Transformation

Damit Legacy-Transformationen ihr volles Potenzial entfalten können, sind folgende Aspekte entscheidend:

  1. Frühzeitige Einbindung des Produktmanagements
  2. Nutzerzentrierte statt rein technische Perspektive
  3. Stakeholder Management über alle Ebenen
  4. Schrittweises Vorgehen mit schnell sichtbarem Mehrwert
  5. Transparente Kommunikation der Ziele und des Nutzens

Besonders wichtig ist dabei das Change Management. Technische Neuerungen können bei Mitarbeitern Ängste auslösen (“Dann braucht man mich ja nicht mehr”). Hier gilt es durch intensive Kommunikation aufzuzeigen, dass die Transformation sie bei ihrer Arbeit unterstützt statt ersetzt.

Fazit

Eine Legacy-Transformation ist weit mehr als ein technisches Projekt. Sie bietet die Chance, echten Business Value zu generieren - aber nur wenn sie ganzheitlich und nutzerzentriert angegangen wird. Produktmanagement ist dafür der Schlüssel. Es sorgt dafür, dass nicht nur modernere Technik entsteht, sondern bessere Produkte für Nutzer und Unternehmen. Der zusätzliche Aufwand für diese breitere Perspektive zahlt sich durch nachhaltigen Mehrwert mehr als aus.

Die Alternative - eine rein technische Migration - verschwendet nicht nur Potenzial, sondern auch Budget. Denn am Ende steht dann zwar ein moderneres System, aber kein besseres Produkt. Legacy-Transformation braucht beides: technische Expertise und Produktmanagement.

Key Takeaways

  1. Legacy-Transformationen sind nicht nur technische Projekte, sondern müssen auch Business-Value generieren
  2. Produktmanagement ist essentiell für erfolgreiche Legacy-Transformationen
  3. Stakeholder-Management und Nutzerbedürfnisse müssen berücksichtigt werden
  4. Reine 1:1 Migrationen ohne Mehrwert sollten vermieden werden
  5. Technische Teams sollten mit Business/Produktteams zusammenarbeiten

Wichtige Fragen der Folge

  1. Warum reicht technische Expertise alleine nicht aus?
  2. Wie kann man Business-Value in Legacy-Transformationen integrieren?
  3. Wie können Nutzer und Stakeholder eingebunden werden?
  4. Wie geht man mit unterschiedlichen Erwartungshaltungen um?
  5. Welche Rolle spielt das Produktmanagement bei Legacy-Transformationen?

Glossar

Vollständige Transkription

Hinweis: Dieses Transkript wurde mit KI erstellt und kann somit Fehler enthalten.

So, dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream.

Einleitung und Vorstellung

Heute geht es um das Thema, warum Legacy Transformation mehr braucht als Techniker mit Tanja.

Tanja, schön, dass du da bist.

Genau, bevor wir loslegen, noch so ein paar Hinweise sozusagen in eigener Sache.

Aktuelle Updates

Die eine Sache ist, wir haben jetzt dank Ralf, der ja zu uns ins Team gestoßen ist, eine Zusammenfassung verschiedener Episoden, also der letzten drei Episoden.

Das ist dieses KI-Panel, die KI-Episode mit Christian Bayer und die Episode zu autonomen Teams.

Und das ist KI generiert.

Und da gibt es auch ein Open-Source-Projekt, was man bei Ralf im GitHub findet, wo man sehen kann, wie er es genau gemacht hat.

Und ich weise noch mal kurz hin auf die KI-AN-Konferenz, die wir machen in 14 Tagen am Montag.

Und die ist halt kostenlos.

Wir sitzen uns da mit zusammen, reden über das Thema KI und Software-Architektur.

Und da kann man sich einfach registrieren.

Da gibt es einen Link bei Zoom.

Kostenlos vier Stunden von 14 bis 18 Uhr.

Genau, soweit sozusagen dazu.

Wie gesagt, heute soll es halt um etwas anderes gehen, also tatsächlich vermutlich KI-frei.

Und zwar um das Thema eben, warum Legacy eigentlich ein Thema ist, was auch Produktmanagement mindestens betrifft.

Und dazu habe ich mit meiner Kollegin Tanja eingeladen.

Schön, dass du Zeit hattest und dazu gekommen bist.

Willst du kurz zwei Worte über dich sagen, was du so machst und wer du so bist?

Sehr gern.

Danke erstmal überhaupt für die Einladung.

Ich bin Tanja Friedl.

Vorstellung der Gäste

Ich bin Partnerin und Principal Consultant bei Swaglab.

Swaglab ist eine Digitalisierungsberatung.

Das heißt, wir kümmern uns um strategische Konzeptionen, aber auch operative Umsetzung von digitalen Programmen und Projekten bei unseren Kunden.

Und meine Rolle bei Swaglab, beziehungsweise bei unseren Kunden, ist vielseitig.

Ich bin gerne als Projektmanagerin tätig oder Projektleitung.

Das heißt, ich begleite beim Kunden digitale Transformationsprozesse.

Ich arbeite sehr gern, und das ist ja auch so ein Thema, das wir hier heute diskutieren wollen, als Produktmanagerin beziehungsweise Productownerin.

Da geht es dann oftmals entweder darum, Produkte von der grünen Wiese aufzuentwickeln oder im späteren Lebenszyklus zu begleiten und zu optimieren.

Eine Rolle, die ich auch noch gerne bekleide, ist die Business-Analyse, also Geschäftsprozesse analysieren, optimieren.

Und das ist ja oftmals auch so eine Sidekick-Rolle vom Produktmanagement.

Meine Vergangenheit habe ich allerdings in der User Experience.

Das heißt, das ist noch so eine Nebenrolle.

Ich sehe mich auch immer gerne als Anwältin der Nutzerinnen und Nutzer und arbeite da sehr, sehr gerne kundenzentriert.

Ja, das vielleicht einmal kurz für mich zum Ja.

Genau, und irgendwie geht es ja heute darum, dass Legacy-Migration eben nicht nur ein technisches Thema ist, sondern eben auch ein Thema, wo nach deinem Dafürhalten, was halt eben etwas mit Produktmanagement zu tun hat.

Was ist denn über Produktmanagement und warum ist das relevant?

Also gerade insbesondere bei Legacy-Ablösungen ist es halt dahingehend wichtig, dass Produktmanagement nochmal über das Technische hinausgeht.

Rolle des Produktmanagements

Also als Produktmanagerin kümmere ich mich um die ganzheitliche Steuerung von einem Produkt.

Das heißt, das geht oftmals los, dass ich mich mit Marktanalysen beschäftige.

Ich konzipiere eine Produktstrategie.

Ich begleite den Entwicklungsprozess.

Ich schaue, wie sich das Produkt gut im Markt positionieren kann.

Und dann im weiteren Lebenszyklus geht es dann natürlich auch darum, kontinuierlich das Produkt zu verbessern.

Also ändert sich vielleicht was an den Kundenbedürfnissen, an den Marktgegebenheiten oder auch manchmal an den Geschäftszielen, dass man da dann wiederum Anpassungen im Produkt vornehmen muss.

Skills im Produktmanagement

Und wenn ich mir so einen klassischen Produktmanager oder eine Produktmanagerin anschaue, dann bringen die halt auch meistens ein großes Skillset mit.

Also es fängt damit an, dass die natürlich auch ein technisches Verständnis mitbringen müssen.

Das heißt, sie müssen natürlich auch mit den TechnikerInnen sprechen und die verstehen können.

Auf der anderen Seite muss ich genau dieses Verständnis auch meinen Stakeholdern nahebringen und auch vermitteln können.

Ich muss ja auch fundierte Entscheidungen treffen.

Das heißt, auch da hilft es, wenn ich mich zumindest technisch grundsätzlich mit den Herausforderungen da auskenne.

Und ich muss natürlich auch, wenn ich einen Blick in die Zukunft richte, schauen, wie kann ich die Produkte dann weiterentwickeln.

Und dafür ist natürlich auch ganz relevant, dass ich verstehe, was da machbar ist und was nicht.

Aber neben dem technischen Verständnis ist es natürlich auch wichtig, dass ich ein strategisches Verständnis habe.

Also sprich, ich muss in der Lage sein, von einer Unternehmensvision meiner Kunden auch eine Produktvision abzuleiten und dann strategische Ziele entsprechend für das Produkt zu entwickeln.

Das heißt, ich muss dahin kommen, dass ich das große ganze Unternehmensziel für mein Produkt runterbrechen kann und das dann entsprechend vorantreiben kann.

Und am Spring muss ich dann natürlich auch schauen, dass die Ergebnisse messbar sind.

Das heißt, ich kann ja nicht nur hergehen und sagen, ja, das Produkt ist viel besser geworden, sondern das muss ja auch in irgendeiner Form, was will man sagen, mit KPIs messbar sein.

Ob das einen echten Mehrwert gebracht hat und wie ich mich dann da mit dem Produkt positioniert habe.

Und ein ganz, ja Entschuldigungsgegeber, Harald?

Nee, sprich dich aus.

Nicht, bei den Skills, da könnte ich mich noch sehr viel weiter austoben.

Also aus meiner Sicht ist auch immer ganz, ganz wichtig, dass eine Produktmanagerin oder ein Produktmanager auch ein Verständnis von Nutzerzentriertheit hat.

Also auch ich muss als Produktmanagerin wissen, wie kicken meine NutzerInnen überhaupt, also was haben die für Bedürfnisse?

Und da muss ich natürlich dafür sorgen, dass ich die auch ideal bedienen kann.

Das erhöht dann unterm Strich natürlich auch die Rezeptanz bei den Nutzerinnen und Nutzern, wenn ich auf genau diese Ziele dann einzahle.

Und bevor Ziele, ich muss natürlich auch in der Lage sein, Ziel zu definieren und auch zu priorisieren.

Ebert, jetzt will ich dich aber nicht wieder unterbrechen.

Ja, also erstmal vielen Dank sozusagen für den Einblick.

Jetzt ist ja das Thema, über das wir ja reden wollen, ist ja eine Legacy-Transformation.

Jetzt könnte ich mich ja hinstellen und könnte halt sagen, also als Techniker ist Legacy-Code halt Code, den ich nicht mehr verstehe, der halt irgendwie schwer wartbar ist.

Das heißt, das ist eine technische Aufgabe.

Am Ende steht irgendwie wartbarer Code.

Und wozu brauche ich dann einen Produktmanager?

Also eigentlich kann ich jetzt irgendwie die KPIs von den Nordsprachs, kann ich halt selber ermitteln.

Ich kann dann sagen, der Code ist halt anschließend wartbar, der war vorher nicht wartbar, fertig.

Warum muss ich jetzt gerade bei einer Legacy-Migration Produktmanagement haben?

Legacy Transformation und Business Value

Also das, was du gerade schildert, das passiert ja auch in Unternehmen.

Und das kann auch mal gut gehen, weil der Zufall so will, dass das, was ich tue, auch auf ein Businessziel einzahlt.

Aber das ist halt oftmals der Zufall.

Und wir gehen ja jetzt erstmal davon aus, dass die Systeme, die Technik, die man zur Verfügung stellt, nicht zum Selbstzweck da sind, sondern ja auch im Idealfall das Unternehmen unterstützen soll, die Geschäftsziele unterstützen soll.

Das heißt, wenn ich als Technikerin das Unternehmensziel gar nicht kenne, kann ich ja auch nur nach bestem Wissen und Gewissen, und zwar nach bestem technischem Gewissen und Gewissen, handeln.

Und das heißt, im Idealfall weiß ich ja aber, wo das Ganze hingehen soll, wo das Produkt hingehen soll, wo das Unternehmen hingehen soll, damit ich dann entsprechend auch für meinen Bereich planen kann und auf diese Ziele hinarbeiten kann.

Also ich habe da schon Projekte erlebt, da ging es auch darum, ein Legacy-System abzulösen.

Und da hat man das dann so geplant, dass man sagt, im ersten Schritt bilden wir einfach nur den Status quo ab.

Das heißt, das Ganze wurde einfach nur auf ein neues, also wurde neu nachgebaut und neu geschaffen.

Mehrwert schaffen

Aber der große Haken an der Geschichte ist ja, dann habe ich als Unternehmen sehr, sehr viel Geld in so eine Migration, also so eine Transformation ausgegeben.

Aber unterm Strich habe ich dem Kunden überhaupt gar keinen Mehrwert geliefert.

Und das ist der Punkt, wo ich dann denke, da sollte man auf jeden Fall mal mit dem Produktmanagement sprechen, um genau diesen Mehrwert schaffen zu können.

Und das würde ich, glaube ich, irgendwie auch gerne nochmal unterstreichen.

Also auch aus der technischen Perspektive muss einem ja klar sein, wenn man halt Immigration macht, das ist halt fast sowas wie irgendwie Neubauen.

Und wie du halt sagst, das ist halt ein signifikantes Investment.

Und wenn man dann irgendwie anschließend BenutzerInnen oder KundInnen sagt, alles so wie vorher, ist das halt irgendwie komisch.

Weil, also dann hat man halt viel Geld ausgegeben, aber halt eben keinen Businesswert geschaffen.

Was empfiehlst du denn dann, wie würdest du dann vorgehen?

Also was ist deine Alternative dazu?

Also ich stelle mich jetzt irgendwie hin, ich sage, okay, ich habe ein altes, vergurktes System.

Das ist irgendwie nicht mehr erwartbar.

Ich möchte es halt irgendwie wartbar bekommen.

Was wäre deine Empfehlung, da an dieses Problem heranzugehen?

Also grundsätzlich macht es natürlich erstmal Sinn zu schauen, was ist überhaupt das Bedürfnis von jedem Unternehmen?

Also das geht dann auch in die Stakeholder-Kommunikation.

Das heißt, ich muss zum einen erstmal identifizieren, was sind denn gerade die Herausforderungen überhaupt, die ich bedienen will?

Was ist der Nutzen, den ich erreichen will?

Und dann zu schauen, wie kann man denn da schrittweise vorgehen, um in kleinen Schritten immer schon einen Mehrwert zu schaffen.

Das heißt, manches Mal ist es ja aus Sicherheitsgründen getrieben, dass man sagt, die Systeme bergen gerade ein hohes Sicherheitsrisiko.

Dann ist es natürlich sinnvoll, dass man das als wichtiges Thema erstmal adressiert.

Das Geschäftsrisiko vorhanden ist.

Aber grundsätzlich ist meine Empfehlung immer, einfach zu schauen, also einmal den Status quo zu betrachten, die Geschäftsziele abzugleichen.

Und dann aber auch zu schauen, was sind denn für Bedürfnisse da von meinen Nutzerinnen und Nutzern?

Das kann man auch unterschiedlich betreiben.

Also manchmal ist es schon ein guter Anfang, dass man sagt, man spricht zum Beispiel mal mit dem Support und schaut, was kommt bei denen eigentlich für Fehlerfälle auf?

Worüber beklagen sich die Nutzerinnen und Nutzer?

Ein Thema kann sein, dass man mit dem Außendienst mal spricht und sagt, was erfahrt ihr denn so in Gesprächen mit euren Kundinnen und Kunden?

Was wünschen die sich?

Aber das ist ja immer schon so ein bisschen gebiased.

Das heißt, da kommen dann ja auch immer noch sehr viele eigene Meinungen rein.

Und auch im Support, die Kolleginnen und Kollegen im Support, die haben natürlich auch immer die Menschen am Telefon, die vielleicht grundsätzlich keine hohe Technikaffinität haben.

Also deshalb wäre auch immer meine Empfehlung, darüber hinaus immer noch in den Dialog mit den Nutzerinnen oder Nutzern zu gehen.

Sei es durch Interviews, sei es durch Tests oder da gibt es eine Vielzahl an Methoden, die man da anwenden kann.

Aber auf jeden Fall, um deine Frage nochmal zu beantworten, pauschal kann man es nicht sagen.

Also es gibt keine Lösung, wo man jetzt sagt, wenn du es so machst, dann ist es richtig.

Sondern einfach mit dem Wissen im Hintergrund, die Unternehmensziele müssen durch dieses Thema abgebildet werden und der Kundennutzen muss vor allen Dingen bedient werden.

Da hat man schon mal eine ganz gute Brille auf, um sich die Herausforderungen dann anzuschauen und zu bewerten.

Genau.

The Travelling IT Consultant sagte gerade auf YouTube, prinzipiell kann man natürlich argumentieren, ein wartbares System stellt selbst schon einen gewissen Mehrwert dar.

Nur reicht das vermutlich nicht.

Das ist so ein bisschen der Punkt.

Wartbar an sich ist ja die eine Geschichte.

Die Frage ist ja, wie wartbar ist es denn und mit wie tief will ich denn in die Zukunft gucken.

Also grundsätzlich kann man natürlich auch sagen, da gibt es ja auch Kunden, die sagen, mein System funktioniert doch nicht.

Ja, ich weiß, irgendwann muss ich mich da mal drum kümmern, aber aktuell will ich es eigentlich gar nicht so gern anfassen, weil solange es funktioniert, muss ich ja auch nicht diese im zweiten, zweiten Jahr doch sehr hohen Kosten dann in die Hand nehmen.

Ich glaube, dass eigentlich seine Bemerkung so ein bisschen ganz gut passt zu dem, was du vorher gesagt hast.

Also wenn ich mich jetzt aus der Technikperspektive hinstelle und sage, okay, das System ist danach wartbar, dann habe ich eben ein bestimmtes Ziel erreicht.

Aber ich könnte eben so viel mehr erreichen, wenn ich eben mal anfange und halt mit Menschen rede, die halt irgendwie Input für dieses System haben, wie du ja sagtest.

Und er kann dadurch eben das Projekt deutlich wertvoller machen.

Und das ist eigentlich eher die umgekehrte Frage, warum sollte ich das halt nicht tun?

Also ich, das Einzige, was ich damit erreiche, wenn ich es nicht tue, ist halt, dass ich irgendwie sozusagen Potenzial auf der Straße legen lasse.

Und das ist sicher keine gute Idee.

Gibt es so ein paar, genau, ich schaue gerade, gibt es so ein paar, wie macht man das denn jetzt businessgetrieben?

Hast du da konkrete Beispiele, hast du irgendwas, was dir da einfällt, wo man das sozusagen konkret tatsächlich sehen kann?

Ja, spontan fällt mir da ein Business Case ein, für den ich mal aktiv war.

Und da ging es darum, dass auf beiden Seiten, sowohl auf Kundenseite, wie auch auf Unternehmensseite, sehr, sehr hohe zeitliche Aufwände entstanden sind, wenn es um einen Versicherungsfall von einem hochkonfigurierbaren Produkt geht.

Das heißt, der bisherige Prozess war halt, es mussten Formulare ausgefüllt werden.

Man musste halt in das Einzelhandelsgeschäft gehen, sich dann mit einer Person auseinandersetzen.

Wobei der reine Prozess dahinter eigentlich ein ganz einfacher ist, denn wir kannten ja die Auftragsdaten von dem Kunden oder der Kundin.

Das heißt, wir kennen das Produkt, wir wissen, was erfolgen muss, um dieses Produkt zu reproduzieren.

Und das war dann zum Beispiel ein Case, den wir dann automatisiert haben.

Das heißt, das wurde dann halt einfach beschleunigt.

Das hatte den Vorteil für die Kundinnen und Kunden, sie mussten nicht mehr in das Geschäft gehen, konnten das dann von zu Hause aus auslösen.

Es musste umgekehrt in der Ladenfläche sich niemand damit beschäftigen und sich da einarbeiten in diesem Fall, wenn es im Grunde einfach nur so ein Nachbestellungsprozess ist.

Und auch da vielleicht noch ein zweiter Case, also Stichwort Nachbestellungsprozess, das ist ja immer was, wo man gut Zeit einsparen kann.

Also wenn ich da auch ein Unternehmen habe, welches auf der Fläche sehr, sehr viel Kundschaft hat und ich als Kundin aber eigentlich nur ein Produkt, von dem ich schon genau weiß, was ich benötige, einfach nur nachkaufen möchte und dann dort aber erst mal 20 Minuten in der Schlange stehe, dann ist der Frust natürlich hoch.

Und auf der Gegenseite kann man dann natürlich als Unternehmen genau darauf einzielen, indem man sagt, pass mal auf, das ist ganz einfach, du bestellst das von zu Hause aus.

Wir kennen dich ja, liebe Kundinnen, wir wissen, was du brauchst.

Also musst du ja eigentlich nur noch auf den Nachbestellknopf drücken.

Und das wiederum führt dann halt auch wieder zu einer großen Zeitersparnis sowohl innerhalb der Ladenfläche wie auch bei mir als Kundin, die dann nicht mehr das Haus verlassen muss.

Und im Zweifelsfall hat man ja auch vielleicht nicht unbedingt das fachkundige Personal vor Ort, das genau das Produkt kennt und weiß, was die Kundin oder Kunde braucht und wie das im System erfasst wird.

Das heißt, auch da, wenn man die Prozesse einfach oder das Wissen aus den Köpfen der Mitarbeiter in das System verlegt, haben wir natürlich sehr, sehr schnell einen Mehrwert für alle Beteiligten geschaffen.

Genau.

Also wir hatten das ja im Vorgespräch auch schon mal diskutiert.

Und was ich dabei irgendwie so spannend finde, ist, dass dadurch dieses System, was ja, wie du gesagt hast, eigentlich dazu dient, um hochkonfigurierbare Produkte zu konfigurieren.

Dann in diesem spezifischen Fall muss man da gar nichts bauen, oder?

Nicht für die Konfiguration, weil das ist ja etwas, wo man einfach sagt, das ist ja wie vorher.

Was eben bedeutet, das ist technisch einfach.

Sorry, genau.

Nee, ganz genau.

Also wir haben ja Auftragsdaten in dem Fall.

Und auch wenn dieses Produkt hochkonfiguriert ist, ist es ja tatsächlich nur ein Klon dieses Auftrags.

Das heißt, so viel Businesslogik muss an der Stelle da gar nicht rein.

Was aus der technischen Perspektive bedeutet, dass man sich darum herumdrücken kann, im ersten Schritt zumindest diese ganz komplizierten Sachen zu implementieren, aber gleichzeitig, wie du ja gesagt hast, eine hohe Menge an Business-Wert zu generieren.

Wie seid ihr auf die Idee gekommen?

Habt ihr dann tatsächlich mit den Leuten vor Ort gesprochen, die das System benutzen?

Ist das dann irgendwie offenbar geworden oder wie seid ihr dahin gekommen?

Das ist tatsächlich auch so ein bisschen, ich will nicht sagen, aus der Not herausgetrieben.

Aber das hat halt gleich, also es war ein Unternehmen, was wirklich eine sehr, sehr hohe Kundenanzahl auf der Fläche hat und diese Flächen sollten halt entlastet werden.

Und das war halt ein Schmerz, der sich durch das ganze Unternehmen getragen hat.

Das heißt unterm Strich ja auch, je mehr Menschen in der Einzelhandelsfläche warten, desto weniger kann ich ja verkaufen.

Und das heißt, so wurde das im Grunde getrieben und dann ist auch tatsächlich der Schritt gleich der erste gewesen, dass man ein Team aufgestellt hat, was natürlich auch zum einen die Kolleginnen und Kollegen oder in dem Fall war es ein Kollege direkt aus der Fläche mit in das Projekt reingezogen hat.

Das ist für mich auch aus meiner Sicht immer ein ganz, ganz wichtiger Prozess, dass man nicht aus seinem, ich nenne es jetzt mal Elfenbeinturm heraus, solche Entscheidungen halt regt, sondern dass man auch unbedingt die Personen mit einbeziehen soll.

Und das sind halt zum einen dann die Mitarbeiterinnen und Mitarbeiter vor Ort, die auch den engsten Kundenkontakt haben.

Aber natürlich muss man dann auch in den Kontakt mit Kunden treten, um zu schauen, wie bereit sind die dann?

Wie hoch ist dann auch das Vertrauen in so ein neues Produkt?

Also gerade wenn es vielleicht auch noch ein kritisches Produkt ist, wo die Kunden einen sehr, sehr hohen Anspruch an die Korrektheit haben, dann muss auch das im Vorwege natürlich mit den Kundinnen und Kunden verglichen werden.

Ich kann ja das schönste Produkt bauen, weil ich denke, dass die Kundinnen und Kunden das brauchen.

Und wenn sich das mit der Realität überhaupt gar nicht deckt, dann auch dann habe ich sehr viel Geld verbraten, ohne dass es von den Endkunden dann genutzt wird.

Okay, was also letztendlich bedeutet?

Also ich glaube, du hast jetzt so implizit eigentlich drei unterschiedliche Rollen definiert.

Also die Endkunden, also die Menschen, die tatsächlich Kunden des Unternehmens sind.

Die Menschen, die vom Unternehmen aus mit diesen Kunden arbeiten.

Und dann irgendwie noch der Fachbereich.

Und ich brauche sie halt irgendwie alle und muss dann da sozusagen Input bekommen.

Nun gibt es, also ich muss halt denken an dieses eine Mastodon-Posting, was ich vor einiger Zeit gesehen habe, wo halt jemand geschrieben hat, also das letzte Mal, dass ich mit irgendwelchen Menschen, die ja tatsächlich mit dem System arbeiten, gesprochen habe, ist irgendwie über ein Jahr her.

Also was ist denn der konkrete Tipp?

Also wie kriegt man da diesen Umdenkprozess hin, dass man halt genau das benötigt und halt diesen Input dadurch braucht?

Das sind ja Menschen, die in den Unternehmen eigentlich machtlos sind, nicht?

Also das sind ja die, die halt tatsächlich, die nicht im Management sitzen, die also eigentlich keine Entscheidungskompetenz haben, aber da ganz wichtigen Input haben.

Und dass die halt überhört werden, kann ich mir vorstellen, ist halt relativ häufig der Fall.

Das ist es halt leider.

Und oftmals sind das ja genau die Menschen, die maßgeblich für den Umsatz verantwortlich sind.

Und deshalb, also mein Appell wäre es halt wirklich, und wobei ich nicht sage, dass es jeder und jede in einem Entwicklungsteam das tun muss, aber dass es auf jeden Fall eine Person gibt, die sich genauso im Sinne der Anwenderinnen und Anwender darauf stellt, dass das auch einfach ein kontinuierlicher Prozess ist.

Es ist ja auch nicht so, dass ich das Produkt einmal fertig stelle und sage, so jetzt haben wir ja alles geschafft, jetzt ist das Produkt für die Ewigkeit.

Sondern auch da kommen ja immer mal wieder neue Impulse.

Es gibt neue Technologien, neue Möglichkeiten, die Einfluss auf dieses Produkt nehmen können.

Und da ist es umso wichtiger, dass man im engen Austausch auch mit seinen Nutzerinnen und Nutzern, und das heißt ja nicht nur die Endkundinnen, sondern tatsächlich auch die Nutzer, die die Systeme innerhalb des Unternehmens benutzt, wie du ja auch schon sagst.

Das heißt, das sind im Grunde ja auch meine Kundinnen oder beziehungsweise meine Nutzerinnen und Nutzer an der Stelle, die ich ja auch im Zweifelsfall genauso bedienen möchte wie die Endkunden, weil auch die Bedürfnisse haben.

Der einfache Tipp ist auf jeden Fall zuhören, wenn die Bedürfnisse äußern, Fragen stellen und auch immer mal wieder mit denen ins Gespräch gehen.

Und im Idealfall auch nicht auf die Art, was braucht ihr denn, wie können wir es besser machen, sondern da auch nochmal ein bisschen tiefer einzusteigen.

Also ich hatte beispielsweise einmal im Gespräch, da ging es auch darum, dass wir ein neues System einführen sollten.

Und dazu habe ich Interviews geführt, beziehungsweise habe auch in dem Umfeld der entsprechenden Mitarbeiterinnen und Mitarbeiter mich aufgehalten und habe deren Tagesabläufe beobachtet.

Und das ist toll, weil da kann man ganz, ganz viele Fragen stellen, weil die erste Aussage war, ja, IT, wir brauchen eigentlich nur schnellere Rechner.

Und ja, das klingt so ein bisschen wie, wir brauchen schnellere Pferde und genau das steckte da auch hinter.

Also wenn man dann da so ein bisschen nachfasst und sagt, warum braucht ihr denn schnellere Rechner, kam man dann über so eine Kaskade dazu, dass sie die schnelleren Rechner brauchten, weil sie so große Excel-Dateien in Hand haben mussten.

Und so kann man da immer tiefer einsteigen, was sind denn das für Dateien, was kommen da für Daten rein.

Und so halt immer tiefer auf das Kern des Problems gehen, sodass man nicht die Nutzerinnen und Nutzer nach ihren Bedürfnissen fragt, sondern versucht rauszufinden, was der, also man spricht davon so schön von Jobs to be done, also was muss denn damit erledigt werden.

Und das kann man halt nur rausfinden, wenn man sich auch intensiv mit den Nutzerinnen und Nutzern beschäftigt.

Und ich glaube, das ist auch das, was mir sozusagen am Anfang, als du heute über Produktmanagement im Allgemeinen gesprochen hast, so ein bisschen aufgefallen ist.

Also eigentlich habe ich das Gefühl, wir reden darüber, wie man sozusagen sinnvolle Software entwickelt und dass Kundeninvolvierung halt ein wichtiges Thema.

Und vielleicht wäre sozusagen einer von den Punkten, naja, wenn ich jetzt irgendwie anfange, also vielleicht gehen wir da auch gerade wieder zum selben Thema zurück oder ich gehe da zum selben Thema zurück.

Wenn ich jetzt anfange und eine große Menge Geld in die Hand nehme, um das System irgendwie grundlegend zu migrieren, sollte ich vielleicht mal mit den Menschen reden, so wie ich halt im Allgemeinen eigentlich immer mit denen reden sollte.

Aber gerade da ist eben die Möglichkeit, vielleicht nochmal besonders viel zu erreichen.

Was wäre denn jetzt dein Tipp?

Also ich bin, oder ich definiere mich ja immer noch so ein bisschen als Techniker.

Das heißt, ich nehme jetzt mal, ich bin irgendwie Architekt oder Entwickler oder so in irgendeinem Projekt.

Und was mache ich denn jetzt konkret, wenn sich das für mich sinnvoll anhört?

Also sollte ich jetzt irgendwie anfangen und versuchen, mit Benutzern zu sprechen?

Ist das das Ergebnis?

Also das würde ich jetzt per se erstmal niemanden aufzwingen wollen.

Ich glaube, wichtiger ist eigentlich, dass man sich jemanden sucht, der Fragen beantworten kann.

Also Fragen wie zum Beispiel, was ist denn der Business-Value?

Was nützt denn unseren Kundinnen und Kunden?

Und einfach darauf so ein bisschen hinauszusteuern, dass man sich nicht nur halt mit technischen Anforderungen beschäftigt, sondern auch im Blick hat, wo das Unternehmen eigentlich hin will, wie die Nutzerinnen und Nutzer so ticken.

Das heißt, wenn ich selber jetzt nicht das Bedürfnis habe, als Technikerin loszuziehen und zu sagen, ich gehe jetzt auf die Straße und frage zehn Leute, dann sollte ich zumindest das Unternehmensintern einfach mal klären.

Und im Zweifelsfall genau die Personen fragen, die mit einer Anforderung auf mich zukommen.

Warum machen wir das?

Worauf zahlt das dann ein?

Und da einfach auch immer so ein bisschen den Blick aufs Ziel haben zu können.

Und ich glaube, das ist aber so eine Denke, die sich in manchen Unternehmen auch erst entwickeln muss, weil manchmal ist das auch gar nicht gewünscht, dass die Entwicklerinnen und Entwickler oder beziehungsweise Architekten sich da so massiv mit einbringen.

Das ist leider auch oftmals der Fall.

Aber das führt dann halt im Zweifelsfall auch zu dem Ergebnis, dass man irgendwie am Unternehmensziel dann doch vorbei arbeitet.

Und insofern hat das natürlich auch noch den Mehrwert, dass, sobald ich mehr weiß über den Business Value als Technikerin, kann ich natürlich auch dazu beitragen.

Also das ist ja keine Einbahnstraße, dass das Produktmanagement des Weges kommt und sagt, hier, wir sollten übrigens so und so vorgehen, sondern ich kann ja auch aus der Gegenrichtung sagen, ich habe eine tolle Idee.

Also wenn wir noch diese oder jene Erweiterung machen, dann heißt es, dass die Nutzerinnen auch im offenen Modus arbeiten können.

Und dann können wir beispielsweise unserem Kunden noch dieses oder jenes ermöglichen.

Also das ist ja im Zweifelsfall auch ein Geben und Nehmen.

Genau.

Und ich glaube, das ist ein wichtiger Hinweis, dass man da halt selber auch aktiv werden kann und zumindest diese Fragen stellen kann.

Und wir hatten ja tatsächlich auch mal eine gemeinsame Episode vor einiger Zeit zusammen noch mit Ralf, wenn ich mich recht entsinne, zu diesem Spiel, wo man halt Themen in eine Organisation einbringen kann.

Und ich glaube, das zieht sich da gerade so ein bisschen durch, dass man als Techniker vielleicht nicht die Pflicht hat, aber schon die Möglichkeit, Feedback zu geben und zu schauen, ob man in diese Richtung etwas weitergeben kann.

Und die andere Sache ist eben auch tatsächlich diese Geschichte, das finde ich auch total wichtig, dass wir gerade sehr gut illustriert nachfragen.

Also wenn ein Requirement kommt, wie schnellere Rechner, da kommt dann am Ende heraus, dass es eigentlich darum geht, vielleicht ein System mal ganz anders aufzusetzen, weil da eine Excel-Schatten-IT ist, die absurd ist und wo man halt irgendwas machen muss und vielleicht auch irgendwie Werte generieren kann.

Weil man kann eben nicht alle Probleme mit Excel erschlagen.

Ich glaube, das ist auch ein sehr wichtiges Thema.

Hast du noch mehr Stories aus deiner Vergangenheit oder aus deiner Erfahrung, die diese Themen illustrieren können oder konkrete Hinweise?

Es gibt natürlich halt dann auch immer noch so Randerscheinungen.

Es ist ja nicht immer so, dass man sagt, man kommt mit einem Business-Value und das führt dann zu einer Transformation.

Systemkonsolidierung

Manchmal ist es ja auch von außen gesteuert.

Also wenn beispielsweise InVert stattfindet, kommen wir in eine Situation, wo vielleicht verschiedene Systeme zusammengefügt werden müssen oder migriert werden müssen.

Also das ist ja zum Beispiel auch immer noch so ein Thema.

Herausforderungen bei der Zusammenführung

Das sind natürlich Sachen, die kommen dann aus einem anderen Hintergrund, aber nichtsdestotrotz führt das ja dazu, dass wir die gleichen Fragen stellen müssen.

Also da vielleicht sogar noch mal ein bisschen komplexer, weil im Zweifelsfall sind es dann zwei gleichwertige Fachbereiche, die unterschiedliche Ansichten darüber haben, die vielleicht auch noch unterschiedliche Backlogs haben, die miteinander verheiratet werden müssen.

Also das meine ich, dass da halt auch der Schritt in Richtung Produktmanagement sehr sinnvoller ist.

Weil gerade wenn man sich die ganzen Fachbereiche anschaut bei so einem Transformationsprozess, dann sieht natürlich jeder Fachbereich oftmals erst mal nur sich selbst.

Das liegt auch in der Natur der Sache.

Die möchten natürlich, dass ihre Anforderungen und ihre Prozesse als erstes abgebildet werden.

Und das ist ja in der Regel überhaupt nicht möglich, dass man sagt, man macht irgendwie alles auf einmal.

Das heißt, da ist es wirklich gut, wenn es da eine Produktmanagerin oder einen Produktmanager gibt, die halt auch dann alle Fachbereiche an die Hand nimmt.

Und das ist auch nochmal ein ganz wichtiger Aspekt.

Ein Produktmanager oder eine Produktmanagerin sollte unbedingt Stakeholdermanagement als Skill mitbringen, weil da ansonsten sehr, sehr viel verbrannt werden kann.

Also auch in meiner Erfahrung, wenn man da die jeweiligen Fachbereiche, das Management nicht rechtzeitig abholt, dann können sich da ganz, ganz schnell Aversionen aufbauen.

Also das ist auch nochmal ein ganz wichtiger Appell.

Kommunikation im Unternehmen

Im Zweifelsfall steht und fällt der Erfolg eines Produktes damit, wie gut das kommuniziert wurde, auch im Unternehmen.

Weil das kann sonst ganz schnell mal so laufen, dass sich irgendjemand nicht abgeholt fühlt und dann im Zweifelsfall parallel noch irgendwelche Dienstleister beauftragt, weil sie sagen, es geht mir ja alles nicht schnell genug und ach die IP.

Und so ist der Ruf dann halt auch ganz, ganz schnell ruiniert, wenn man da nicht transparent mit allen Bereichen und Abteilungen arbeitet und auch dann Verständnis für generiert, wo gerade der Stand ist, den Kolleginnen und Kollegen dann da auch entsprechend noch die Möglichkeit gibt, ihren Input mit einzubringen.

Also das ist halt auch dahingehend nochmal ganz, ganz wichtig, dass so ein Transformationsprozess halt immer ein ganzes Unternehmen betrifft und nicht nur die IP.

Genau, also da ist auch, glaube ich, ein ganz wichtiger Punkt drin, nicht dieses Stakeholder-Management, das ist ja eigentlich auch ein Architektur-Team, also ist auch etwas, was Architekten betreiben müssen, weil sie halt eben verschiedene Leute beteiligen müssen an den technischen Entscheidungen und eben letztendlich das, was eben aus dem Produktmanagement kommt, glaube ich, auch bis zu einem gewissen Maße umsetzen müssen.

Und da ist, glaube ich, ein deutlicher Berührungspunkt, also es ist eine ähnliche Herausforderung, die da existiert.

Du sprachst jetzt gerade, glaube ich, über die Konsolidierung von verschiedenen Systemen, dass man daraus irgendwie eins macht.

Und ich glaube, da habe ich jetzt auch zwei wichtige Punkte mitgenommen.

Also einmal bedeutet das eben, dass ich damit auch zwei unterschiedliche Benutzerschaften sozusagen habe, weil ich ja zwei Systeme habe mit zwei unterschiedlichen Benutzerschaften und da wird dann Stakeholder-Management ein wichtiger Punkt, wie du ja sagtest.

Und das, glaube ich, ist irgendwie auch eine total spannende Sache, weil das eben bedeutet, dass eben nicht nur ich mache aus zwei technisch unterschiedlichen Systemen eins, das ist nicht die Aufgabe, sondern ich mache damit irgendwie auch aus zwei Benutzergruppen eine.

Das hat irgendwie weitreichende Konsequenzen, wie du halt sagtest, dass ich die dann irgendwie hören muss und mir irgendwie anschauen muss, dass ich die halt auch alle irgendwie betrachte und halt mit einbeziehe in die Weiterentwicklung.

In dem Kontext, also vielleicht da nochmal die Frage, da könnte man ja jetzt argumentieren oder das ist etwas, was ich zumindest manchmal, glaube ich, scheinbar höre, naja, wenn ich zwei Systeme habe und ich mache daraus eins, dann habe ich halt am Ende weniger Kosten, weil zwei sind halt teurer als eins.

Reicht das schon als Businesswert?

Also ist das etwas, wo du sagen würdest, dass wir brauchen eigentlich nicht mehr uns darum zu kümmern, wie wir mit diesen Leuten umgehen, also wir müssen da nicht mehr so tief reingucken, sondern dadurch wird sich ja das Projekt schon rechnen.

Also sagen wir es mal so, es ist per se ja erstmal kein schlechter Businesswert.

Kostenersparnis, im Zweifelsfall ja nachhaltig, Effizienz innerhalb der IT, weil ich wieder andere Kolleginnen und Kollegen freispiele dadurch, wenn ich nur noch ein Produkt bedienen muss beziehungsweise betreuen muss.

Aber darüber hinaus, das hängt ja auch ein bisschen davon ab, was die Anforderungen sind.

Also sage ich, ich benutze jetzt nur noch dieses eine System weiter und das andere schmeiße ich weg.

Das wird ja in der Regel nicht darauf hinauslaufen oder beziehungsweise in den seltensten Fällen.

Das heißt, ich mache mir sowieso Gedanken über die Fachlichkeit der Produkte und spätestens dann beschäftige ich mich ja auch damit, was sind die Bedürfnisse von System Nummer 1, was sind die Bedürfnisse von den Nutzerinnen und Nutzern von System 1 und System 2.

Und auch die müssen dann ja irgendwie nochmal analysiert und bewertet werden.

Und ich bin mir ziemlich sicher, wenn man da drauf schaut, kann man noch weitere Businessvalues da entdecken und identifizieren, die über die Kostenersparnis, was ja schon was Tolles ist, hinausgehen.

Hintergrund der Frage ist halt auch, ich finde das halt gerade spannend, wir haben ja tatsächlich mindestens ein Projekt, was halt in diese Richtung gerade geht und wo meiner Ansicht nach das Ziel tatsächlich ist, eben nicht diese Kosten zu sparen, sondern eigentlich zu sagen, wenn wir aus zwei System eins machen, sind wir dazu in der Lage, schneller Produkte zu launchen, was ja irgendwie bedeutet, dass wir ein ganz anderes Geschäft haben, was ja irgendwie zu der Frage führt, kann man nicht andere Projekte, die also so ein bisschen die Anfangsfrage, die du ja auch gestellt hast, kann man nicht andere Projekte, die halt jetzt so ein rein technisches Ding machen, wo sie halt sagen, alte Code-Basis, neue Code-Basis, kann ich nicht auch bei einer Vereinheitlichung von zwei Systemen halt sagen, okay und dadurch kriege ich halt die Möglichkeit, schneller irgendwelche Änderungen zu machen, dadurch habe ich halt einen höheren Business-Wert, dadurch kann ich halt vielleicht neue Kunden gewinnen, die halt neue Features halt gut finden oder was auch immer und das wäre vielleicht etwas, was man den Menschen halt auch mit auf den Weg geben kann.

Genau, wo es eine weitere Möglichkeit ist.

Was ja auch eigentlich kein Wert an sich ist, sondern nur dann hilft, wenn ich eben auch tatsächlich Requirements habe, die ich halt umsetzen muss.

Ganz genau.

Also lustigerweise kommen ja auch häufig Anfragen für eine Legacy-Ablösung, die rein von der IT gesteuert sind, weil die IT selber gemerkt hat, ich habe da gerade, ich habe hier so viele Probleme, dass wir die nur lösen können, wenn wir das alles modernisieren und das ist aber manchmal prägt sich das auch das ganze Unternehmen, weil die, sei es nur eine schlechtere Wartbarkeit, dass das alles immer so ewig dauert, bis was umgesetzt werden kann oder so.

Das ist ja schnell auf die IT geschoben.

Also das ist ja die IT, die da nicht vorankommt und die mit ihren Systemen und das heißt oftmals ist das aus der IT heraus das Bedürfnis geweckt worden und das per se ist ja jetzt erst mal was Gutes, aber es hilft ja nicht und an dem Punkt waren wir ja im Grunde auch schon.

Es hilft ja nicht, das dann nur mit IT zu bedienen, weil dann hat man im Zweifelsfall die Probleme gelöst, die vielleicht innerhalb der IT aufgekommen sind, aber nicht darüber hinaus und deshalb auch noch mal an dieser Stelle der Appell, es ist immer wichtig, sich auch mit den Unternehmenszielen da auseinanderzusetzen und nicht einfach, also nur, sage ich jetzt mal, dieses Thema einfach auf einen aktuelleren Stand zu heben.

Beziehungsweise das, was du sagst, geht ja noch mal in eine andere Richtung.

Verbündete finden

Man könnte es ja auch übersetzen als, wenn du halt aus der IT heraus das Gefühl hast, du willst halt irgendwie die Systeme erneuern.

Ja, guter Punkt, aber such dir doch bitte Verbündete, die außerhalb der IT sind und vielleicht willst du dann das Projekt irgendwie breiter aufstellen, was ja zahlreiche Vorteile hat und das ist, glaube ich, so ein bisschen der Hinweis, den ich daraus gehört habe aus meiner Sicht.

Ja, plus, also in dem Fall, weil es sind ja auch extrem hohe Kosten, die dabei entstehen und ich brauche als IT dann ja auch einen Sponsoren und wenn ich damit zur Geschäftsleitung gehe und sage, ich würde hier gerne meine Systeme modernisieren, das kostet x Millionen Euro, dann ist es gut, auch gleich Argumente mitzubringen, warum das für das ganze Unternehmen nachhaltig ist und nicht nur so ein rein technisches Thema ist.

Das heißt, auf jeden Fall wird man an den Punkt kommen, wo die Frage gestellt wird, wozu ist denn das gut und was haben dann unsere Kundinnen und Kunden davon.

Genau und ich glaube, das ist so ein bisschen auch etwas, was wir, also das war für mich auch die Motivation, diese Episode zu machen, auch mit dir zusammen, weil das ist ja etwas, was wir tatsächlich bei unseren Kunden beobachten, dass halt viele von den Kunden eigentlich irgendwie und ja auch schon vorher in anderen Kontexten, dass halt eigentlich die Migration von Systemen am Ende halt sehr oft auf Business-Themen zurückzuführen ist.

Ich habe halt ein Business-Problem und ich muss es halt lösen und das kriege ich halt mit dem jetzigen System nicht mehr hin.

Also nehme ich so viel Geld in die Hand, dass ich das System irgendwie ablöse, dann muss ich halt darauf achten, dass ich eben tatsächlich diese Business-Themen auch erreiche, beziehungsweise der andere Hinweis ist halt, wenn ich das nicht habe, weil ich irgendwie sozusagen aus der IT mit so einem mulmigen Gefühl irgendwie rumgehe oder halt sage, das ist halt irgendwie alt, das System, dann sollte ich halt das Spiel in diese Richtung treiben, weil ich dann halt ein besseres Projekt habe, ein Projekt, was eben mehr Wert generiert, weniger Risiko hat und so weiter.

Und ich glaube, das ist, also vielleicht wäre das sozusagen eine Hausaufgabe beim eigenen Projekt oder bei der nächsten Legacy-Migration, sich halt die Frage zu stellen, sind wir eigentlich an der Stelle, dass wir Business-getrieben jetzt migrieren, weil wir halt irgendwas mit dem alten System nicht mehr umsetzen können oder sind wir noch nicht an dieser Stelle und ist da halt noch eine Optimierungsmöglichkeit, sich eben genau diese Sache halt anzuschauen und halt zu schauen, dass wir da halt besser werden.

Und in beiden Fällen macht es eben Sinn, mit Produktmanagement zusammenzuarbeiten, weil als Techniker will man das wahrscheinlich nicht oder kann das halt auch schlicht nicht so gut.

Richtig.

Oder hat halt auch tatsächlich nicht die Ressourcen dafür, weil die will man ja idealerweise auch in der eigentlichen Umsetzung da sehen.

Genau.

Jetzt muss ich mal schauen, was wir uns noch aufgeschrieben haben.

Das haben wir noch nicht erwähnt.

Du hast auch noch einen Link in die Brust geschrieben diese Woche, wo es halt darum ging, dieses Thema halt zu diskutieren.

Den verlinke ich später auch nochmal.

Ich weiß nicht, ob du darauf nochmal tiefer eingehen wolltest oder ob da noch irgendwelche Themen sind, die wir aus dem Brust rausziehen können.

Ich glaube, wir haben jetzt schon ganz, ganz viel hier diskutiert, was wahrscheinlich ein Umfang reicher ist als der LinkedIn-Post, wo man ja per se erst mal auf eine bestimmte Zahlschlusszahl beschränkt ist.

Aber vielleicht der wichtige Impuls doch mal.

Ich trinke auch gerne einen virtuellen Kaffee und bin gerne bereit, auch da ins Gespräch zu gehen.

Das heißt, wenn jetzt hierüber hinaus, wenn ihr das seht und sagt, ich habe noch Fragen, ich habe da noch Themen, die ich gerne mit dir, Tanja, diskutieren würde.

Und ich glaube, Eberhard, du wirst diesen Link dann auch nochmal posten.

Würde ich mich freuen, wenn ihr euch bei mir über Calendly zu einem Kaffeetermin anmeldet.

Also das gerne nochmal als Angebot jetzt hier in die Runde.

Genau.

Ich packe das jetzt, glaube ich, auch gleich mal in den Chat.

Vielleicht kurz nehmen wir es dazu.

Das ist ja etwas, was wir alle bei Perspektive anbieten.

Ich packe den Link für mich auch nochmal in den Chat, dass man einfach eine Stunde mal mit jemandem von uns sprechen kann, um Dinge zu diskutieren aus dem eigenen Projektkontext.

Das ist halt unverbindlich, kostenlos und ist halt immer eine ganz nette Sache, um sich den Themen zu nähern.

Ich glaube, das ist halt gerade, weil das eben ein Thema, also nicht, weil wir hier eine eher technische Audienz haben und du halt ein anderes Skillset hast.

Das ist, glaube ich, etwas, was sehr wertvoll ist, um sich da vielleicht mal Rat und Tat sozusagen zu bringen, zu holen.

Und genau der Link den Post ist das andere.

Das verlinke ich auch nochmal und packe es auch nochmal in den Chat.

Ich glaube, wir haben es dann auch soweit, oder?

Hast du noch irgendetwas, was du den Menschen sozusagen so mitgeben willst?

Ich glaube, ich habe schon so eine Appelle hier verpackt.

Also, wenn jetzt aus den Chats keine Fragen mehr offen sind, dann habe ich hoffentlich die Punkte gemacht, weshalb es unbedingt wichtig ist, sich in Transformationsprozessen auch mit dem Produktmanagement auseinanderzusetzen oder zumindest die richtigen Fragen zu stellen, falls es nicht verfügbar ist und einfach auch da immer im Blick zu haben, was schafft ein Mehrwert für unsere Kundinnen und Kunden?

Was schafft ein Mehrwert für das Business?

Und wie können wir uns dem am besten nähern?

Genau diese Frage, was bringt es eigentlich euren Kunden?

Die habe ich einmal in einem Review gestellt und das war wahrscheinlich die wichtigste Frage, die ich in dem Review gestellt hatte.

Was eben bedeutet, dass man auch als Mensch keinen Hintergrund hat in diesem Bereich mit solchen dummen Fragen, die ein bisschen weiter draußen sind, was er erreichen kann.

So, wir haben jetzt bei Twitch hat der Strudelhund69 eine Frage gestellt.

Ich lese die mal vor.

Ich habe sie nur überflogen, da habe ich sie noch nicht ganz verstanden.

Also, sie schrieb, hi, wie geht man eigentlich gut mit den Erwartungen von Firmen um, wenn sie alte Systeme und schlechte Teamführung haben, aber große Softwareprojekte von einem neuen Projekt erhoffen?

Wie geht man eigentlich mit den Erwartungen von Firmen um, wenn sie alte Systeme und schlechte Teamführung haben, aber große Softwareprodukte von einem neuen Projekt erhoffen?

Das wäre jetzt meine erste Frage, wo die schlechte Teamführung stattfindet, wenn wir jetzt davon ausgehen, dass das innerhalb der Umsetzung ist, also innerhalb der IT und Entwicklung.

Ich habe da gerade mehr Fragen.

Also, wer würde dann tatsächlich, wenn du davon sprichst, wie Firmen und die Erwartungshaltung, dann ist das vermutlich das Management, das sagt, ich habe hier ein Projekt geplant und dann im Grunde das Szenario, das du da beschreibst, ist dann im Grunde wahrscheinlich, aber die IT ist da gar nicht für aufgestellt.

Das wäre jetzt meine Interpretation von dieser Frage.

Gut, da müsste ich tatsächlich noch Rückfragen stellen.

Da kommen jetzt noch weitere hohe Fluktuationen in der Firma.

Viele Gruppen statt Teams.

DevOps ist ein Team mit Pflichten statt einer Philosophie.

Also, ich glaube, das ist etwas, was man wirklich sehr gut in genauso einem virtuellen Kaffee klären kann.

Und wie soll ich sagen, so blöd wie das ist, aber übermäßige Erwartungshaltung an Softwareentwicklungsteams oder überbordende Erwartungshaltung an Softwareentwicklungsteams ist bedauerlicherweise nicht so selten, wie man sich das vorstellt.

Und das ist ein komplexes Thema.

Ich bin da voll bei dir.

Ich glaube, da sind ja verschiedene Thesen drin.

Impliziert ist eigentlich die These, die wollen, dass wir irgendetwas Tolles bauen und wir werden das neben dem hinbekommen.

Das ist so ein bisschen die Ansage, die da mitschwingt.

Da müsste man jetzt tatsächlich draufgucken, was das denn konkret bedeutet.

Eigentlich ist es irgendwie etwas, wo man Review machen würde und schauen würde, wie man da weiterkommt.

Und es klingt auch schon so ein bisschen, als würde eine Struktur vorherrschen, die erstmal nicht so viel Vertrauen in die Mitarbeiterinnen und Mitarbeiter setzt.

Also, das schwingt für mich da schon so ein bisschen durch.

Und da würde man dann im nächsten Schritt überhaupt mal nachhaken, woran liegt das?

Sind das einfach schlechte Erfahrungswerte, die die Unternehmensführung vielleicht hat gegenüber den Teams?

Und dann müsste man halt schauen, wie kann man die aushebeln?

Wie kann man da die Brücke schlagen, damit man auf Augenhöhe miteinander arbeiten kann und auch, also unterm Strich auch Erwartungsmanagement betreiben kann und sagen kann, okay, was ist die Erwartungshaltung von der Führungsebene?

Was ist der Beitrag von dem Team und wie kann man sich da auf den Weg treffen?

Genau.

Und damit sind wir eigentlich zwar nicht bei dem Produktmanagement, aber bei den Themen, für die du ja auch sonst stehst, eben genau solche Sachen wie, wie geht man mit Teams um?

Wie macht man eigentlich Projekte und so weiter?

Und das ist die Ebene, auf der da sicher die Lösung liegt.

Ich glaube nicht, dass die, also das war ja auch so ein bisschen, zieht sich, glaube ich, durch die ganze Episode nicht.

Also das gibt halt technische Probleme.

Wir müssen irgendwie Software bauen, Legacy ablösen.

Aber am Ende sind es eben genau diese Menschen- oder Produktprobleme, die halt in Wirklichkeit die Herausforderungen darstellen.

Und deswegen ist es ja so gut, dass wir eben tatsächlich bei uns beide Dinge, glaube ich, sehr gut abdecken können.

Menschlicher Faktor

Dieser menschliche Faktor ist halt auch ein ganz, ganz wesentlicher.

Also ich habe das ja vorhin schon mal angesprochen, dass halt auch die ganzen, sowohl die Fachbereiche, wie auch sämtliche andere Stakeholder abgeholt werden müssen.

Und wenn man das nicht tut, dann ist auch die Kooperationsbereitschaft innerhalb eines Unternehmens halt sehr, sehr zierig.

Also es müssen sehr viele Brücken gebaut werden, damit auch alle an einem Strang ziehen können.

Ja, genau.

Und da haben wir auch tatsächlich diese Broschüre geschrieben von uns aus.

Ich verlinke die auch nochmal mit dem Menschen-Mittelpunkt.

Und da haben ja, glaube ich, irgendwie alle von uns ein Essay jeweils geschrieben.

Und ich fand das halt total spannend.

Du hattest, glaube ich, diese Geschichte geschrieben, von wegen, man muss halt irgendwie auch die Benutzer mitnehmen.

Ja, ich glaube, wenn ich rekapituliere, Wer hat Angst vor Software, war, glaube ich, der Titel.

Und genau das ist der Punkt, nämlich auch die Menschen mitzunehmen, die sich vielleicht auch abgehängt fühlen dadurch.

Ängste und Vorbehalte

Und das ist nämlich auch eine große Gefahr, wenn man so Sätze hört wie, ja, dann braucht man mich ja gar nicht mehr, wenn es das System gibt.

Das sorgt halt auch sehr, sehr schnell für ein sehr schlechtes Klima innerhalb eines Unternehmens.

Und das fand ich halt total spannend, weil also für mich als Techniker, als Techniker bin ich in erster Linie positiv besetzt.

Und technischer Fortschritt ist etwas, woran ich arbeite und was ich halt auch total spannend finde.

Ich fand halt diesen Aspekt total spannend, dass das eben durchaus nicht selbstverständlich ist.

Und das hat zu Recht an einige Leute dann eher da ja schlicht Angst haben und dass man die halt irgendwie abholen muss.

Und deswegen fand ich das halt noch einen guten Punkt da.

Vielleicht noch den Satz ergänzen und auch dazu ist es halt wichtig, im regelmäßigen Austausch mit den Mitarbeiterinnen und Mitarbeitern, wir hatten es vorhin zum Beispiel auf den Flächen, die den Kunden Kontakt haben, zu sprechen und auch da einfach beruhigend einzuwirken, dass genau das, was du sagst, Eberhard, dass Software per se erstmal was Positives auch sein kann.

Und man diese Kolleginnen und Kollegen im Zweifelsfall auch freispielt für Dinge, die nicht halt Software bedienen sind, weil die eine hohe Komplexität haben, sondern weil sie dann vielleicht auch wieder viel mehr Zeit für die Kundinnen und Kunden haben und ihren eigentlichen Beruf ausführen können.

Und das ist, glaube ich, ein total wichtiger Punkt und glaube ich auch ein bisschen im Kern dieser Episode.

Also am Ende bauen wir halt irgendwie Hilfsmittel und Werkzeuge zur Unterstützung und das muss irgendwie wieder, also das kann gar nicht zu sehr in den Köpfen drin sein.

Genau, der Strudelhund69 hat gesagt, okay, danke, ja, gute Punkte.

Also das scheinen wir von daher oder scheinst du von daher gut beantwortet zu haben.

Dann haben wir es aber, glaube ich, tatsächlich soweit, wenn nicht noch weitere Themen sind.

Genau, wir haben nächste Woche voraussichtlich eine Episode, ich muss gestehen, wir haben es noch nicht inhaltlich geplant.

Und dann würde ich sagen, haben wir es soweit und dann wünsche ich noch einen schönen letzten Arbeitstag vor dem Wochenende und dann ein schönes Wochenende.

Von meiner Seite auch und danke, Eberhardt, dass ich hier sein durfte.

Ja, sehr gerne.

Schön, dass du da warst und vielen Dank für deine Einblicke und deine Einsichten.

Sehr gerne.