EAM#13: Run und Change neu steuern - Was Architektur möglich macht

00:00:04: Architektur entscheidet über Komplexität, über Kosten und Übersteuerbarkeit.

00:00:09: Ich bin David Hohl und heiße Dich herzlich willkommen.

00:00:12: bei Enterprisearchitektura wirkt der Podcast zu.

00:00:15: RM!

00:00:20: Servus grüßt Dich und herzlich Willkommen zu einer neuen Folge.

00:00:25: heute möchte ich über etwas sprechen das viele Unternehmen für völlig normal halten und dass trotz dem aus meiner Sicht eine der größten strukturellen Verzehrungen in Steuerung erzeugt und das ist diese Trennung einfach zwischen Run und Change.

00:00:48: Ich habe in der letzten Folge viel über versteckte Kostentreiber gesprochen, über Shared Asset, über capability-basierte Kostenmodelle, über Dinge in klassischen TCO Modellen oft unsichtbar bleiben.

00:01:05: Und heute möchte ich eigentlich einen Schritt mal wieder weitergehen.

00:01:10: Denn irgendwann kommt halt die Frage, wenn ich das alles weiß was du mir da erzählst wie steuere ich denn dann anders?

00:01:23: Genau und das geht's heut Wenn man ganz klassisch darauf schaut Dann wirkt halt Run und Change erstmal recht logisch.

00:01:40: Run hält heute den Betrieb stabil, wie du weißt und Change verändert das Ganze.

00:01:47: Run ist eher eine Kostenlogik in solchen, zeigt im Endeffekt immer Dauerkosten.

00:01:55: Und Change eher ist ein Investitionslogik oder ja... Das klingt mal okay aber trotzdem bin ich der Meinung dass genau hier etwas Spannendes passiert.

00:02:11: Wir erzeugen nämlich zwei Optimierungswelten.

00:02:14: Auf deiner Seite haben wir den Betrieb, der optimiert ist auf Effizienz und dann die Projekte optimieren auf Delivery Und irgendwo dazwischen sitzt halt die Architektur und versucht später die Folgen, die daraus entstehen einzufangen.

00:02:35: Genau das ist häufig der Fehler Bei Lachtektur zu spät einfach ins Spiel kommt.

00:02:44: Wir werden zu späht eingebunden, nicht als Steuerung gesehen sondern wir sind dann einfach nur der Reparatur wegen da und ich glaube das sollte sich schon drehen.

00:03:00: Das habe ich halt auch sehr oft erlebt dass ein Projekt mit einem wirklich perfekten Business Case gestartet ist.

00:03:09: Alles ist fein Alles ist gut durchgerechnet, alles ist auch sauber aufgelegt und erklärt.

00:03:19: Und trotzdem explodiert dann später diese Betriebskosten.

00:03:25: Und jeder fragt sich halt warum?

00:03:30: Weil der Business Case meistens das Zielbild kalkuliert also wie die Reise dort hingeht.

00:03:41: Gerade diese Transitions sind aber das teure Also das Bild von, wo bin ich jetzt?

00:03:48: Wo möchte ich hin und das dazwischen.

00:03:50: Das ist es was uns in die Mangel nimmt.

00:03:55: Dieser Parallelbetrieb der kostet vor allem auch die Koordination.

00:04:00: und die Koordination habe ich echt da könnte ich habe ich magend Geschmüre manchmal bekommen wie viel Diskussion eigentlich notwendig sind von A nach B zu kommen Denn auch die temporäre Architektur, die man sich aufbauen muss, kostet.

00:04:16: Und vor allem etwas ist einfach die Menschen dazwischen, die reiten sich halt und das kostet noch mehr weil man dreht danach noch mehr Schleifen Nur steht das selten vorne in der Kalkulation etwa?

00:04:36: Und genau deshalb sage ich viele Run-Kosten sind eigentlich einfach nur ein Changefolgekosten.

00:04:46: Das ist eine sehr unbequeme Thesen, finde ich.

00:04:51: Aber ich denke eine sehr wichtige für uns.

00:04:55: Lass uns noch einen Schritt weitergehen!

00:04:57: Ich glaube nämlich auch viele Diskussionen über Run-Cost laufen oft halt an der eigentlichen Ursache vorbei weil wir versuchen immer wieder die Symptome effizienter zu machen.

00:05:12: Wir wollen uns einfach mehr Automationen, mehr Workflows, mehr alles Standard und das lassen sie ganz einfach auch noch auswachsen.

00:05:23: Aber manchmal ist nicht der Betrieb ineffizient sondern die Architektur erzeugt zu viel unnötiger Betriebslast.

00:05:34: Das ist halt was anderes.

00:05:36: Dann hilft auch keine Optimierung mehr finde ich.

00:05:38: Und dann hilft nur Eins, wir müssen die Struktur verändern.

00:05:44: Und das ist halt genau... ...hännte man sich auch über Diktaturmanagement und nichts anderes.

00:05:50: Vielleicht mal ein anderes Beispiel?

00:05:53: Was ich auch oft dazu erlebt habe, dass Betriebsteams unter viel Kostendruck stehen oder standen.

00:06:03: Und zwar in Run Budget muss halt reduziert werden.

00:06:10: Das ist ein sehr klassischer Effekt, wo man oder Reflex was man dann sofort machen muss wenn man da Budget- oder Kostendruck hat, dann muss mal irgendwas reduzieren.

00:06:19: Klar!

00:06:20: Das haben wir jeder im BWL oder in Rechnungswesen früher gelernt.

00:06:24: aber gleichzeitig laufen echt zig Change Initiativen einfach weiter die permanent neue Betriebsoffender erzeugen und das hat halt keiner wirklich im Blick.

00:06:39: Beziehungsweise jeder weiß, dass aber das zu kontrollieren ist eine komplett andere Geschichte.

00:06:45: Und dann optimiert man nämlich Run auf einer Seite während man auf der anderen Seite ständig neu Last produziert.

00:06:57: Das ist ja schon wirklich fast Paradox.

00:07:01: Genau deshalb glaube ich... wenn man das ein bisschen näher betrachtet, Run and Change getrennt zu steuern erzeugt oft Zielkonflikte die wir später Kosten nennen.

00:07:16: Und das ist der eigentliche Punkt.

00:07:21: und jetzt kommt für mich die spannende Gegenbewegung Wie steuert Architektur wirklich dagegen?

00:07:29: Das Ballwerk!

00:07:31: Ich glaube als erstes in dem Architektur diese künstliche Trennung nicht akzeptiert einfach.

00:07:38: Das klingt mal banal, ja klar ist das aber nicht!

00:07:42: Denn viele Architektorarbeit passiert innerhalb von Bestehen und Steuerungslogen.

00:07:47: also wir sind in diesem Fluss gefangen.

00:07:49: da auszubreichen ist relativ schwierig.

00:07:53: man kann natürlich den Bad Cop spielen da bin ich Weltmeister drinnen Wieder einer oder andere weiß, der was ihr vielleicht auch gerade zuhört.

00:08:03: Aber eigentlich müssten die Architekten als solches die eigene Logik einmal selbst infrage stellen und sagen Vielleicht ist nicht die Kostenhöhe unser Problem hier sondern das Steuerungsmodell.

00:08:19: Das ist ein Unterschied Und genau deshalb glaube ich so stark an Capabilitys als Bezugsraum Nicht primär immer aus Kostenmodellen, sondern als gemeinsames Steuerungsobjekt.

00:08:36: Weil Budget ist einfach oft trennen aber Capabilities die machen was Geiles sie verbinden wenn Betrieb und Veränderung beide auf dieselbe Fähigkeit schauen verändert sich plötzlich auch das Gespräch.

00:08:55: dann geht es nicht um Übergaben dann geht es um gemeinsame Verantwortung und das verändert interessanterweise erstaunlich viel.

00:09:10: Ich habe das in einer Diskussion mal erlebt, sobald man nicht mehr über Projektkosten nämlich spricht also als Betriebskosten sondern über die Zukunftsfähigkeit einer Capability wird das Gespräch sofort strategischer.

00:09:31: Das vielleicht einmal auf einem.

00:09:33: Ich probiere dieses Gespräch ein bisschen zu analysieren und das ein bisschen näher beleuchten für dich.

00:09:40: Vor einigen Jahren habe ich in einem Automotiv-Kontext sehr konkret was erlebt.

00:09:50: Da ging es ursprünglich vermeidlich um eine klassische IT Thema, also Vertriebs- und Vertragssysteme sollten einfach angepasst werden.

00:09:59: Und vor allem ging es, wenn ich mich recht ins Sinn einfach darum weil man halt nur Absatzmodelle aufbauen wollte.

00:10:07: Liesige Varianten, flexible Finanzierungsmodelle aber später auch vor allem erste Überlegungen Richtung Subscription von Fahrzeugen und die Diskussion startet genauso wie sie halt oft startet Die Frage, was natürlich sofort reingeschossen kommt.

00:10:29: Was kostet denn uns diese Anpassung?

00:10:31: Welches Budget, Projektbudget brauchen wir und welche Betriebsaufwände kommen später am Schluss auf uns zu?

00:10:40: Und vor allem auch die typische Run and Change Diskussionen, an denen ich echt schon ein bisschen leid bin.

00:10:49: Und ehrlich, wir sind dabei erst mal nicht wirklich weitergekommen.

00:10:52: da haben unsere Mal sehr lange im Kreis gedreht Weil einfach jeder seinen Kopf und Topf argumentiert hat, der Vertrieb ist so.

00:11:00: Der IT ist wieder so und Controlling an dieser Stelle auch wieder anders.

00:11:05: Und irgendwann hat die Diskussion einfach sich ein bisschen gedreht und das war recht spannend auch zu sehen, denn wir haben danach nicht mehr was kostet unseres Vorhand diskutiert sondern die Richtung ist mir in die andere Richtung gegangen.

00:11:19: Wie gut ist eigentlich unsere Fähigkeit Absatzmodelle überhaupt flexibel zu verändern?

00:11:25: Das ist ja unabhängig jetzt von der IT nicht wahr!

00:11:28: Und plötzlich war das komplett ein anderes Gespräch und man diskutierte endlich mal die richtige Richtung.

00:11:35: Auf einmal ging es nämlich genau nicht mehr um die Anpassung der Systeme, sondern darum wie schnell unsere Vertragsmodelle in den Markt gebracht werden können und wie schnell man auf Nachfrage Schwankungen reagieren kann – und vor allem wie stark auch in diesem Kontext-Händlerprozesse aufgehängt sind und Herstellungslogiken.

00:12:01: Und für die Nutzierungsmodelle eigentlich architektonisch zusammenhängen.

00:12:06: Das war spannende Aufgabe auch als Enterprise Architekt oder Alterslurschenarchitekt vor allem, um das im Endeffekt wirklich sichtbar zu machen.

00:12:17: Es ging nicht primär um das IT-Projekt an mir, es ging halt mehr um die strategische Vertriebsfähigkeit.

00:12:28: Was dahinter war, ab dem Moment wurde auch einiges anders oder wurde halt prinzipiell einfach anders über Investitionen gesprochen.

00:12:39: Auch im Nachgang beim Café oder so.

00:12:41: da hat man auf einmal das ganze Kommen des anderen Licht gesehen.

00:12:45: Das Coole ist dann auch gewesen dass man dann Architektur einfach anders gesehen hat und zwar ob die Architektur künftig wirklich unseren Absatz flexibilisiert.

00:12:59: Ja, das tut es wenn man's richtig macht!

00:13:03: Und das ist halt eine komische andere Sachlage weil ich nicht mehr dann nur Kosten diskutiere sondern über die Marktreaktionsfähigkeit.

00:13:12: und genau da habe ich für mich sehr stark verstanden was die KPB sich eigentlich wirklich verändern kann.

00:13:20: und auch hier ein Tipp wenn es in die krassesten Systemdiskussionen geht und man dreht sich da im Kreis einfach aus technischer Natur ein Stopp einführen, die Hand hochhalten und sagen so was bedeutet das eigentlich auf Capability Ebene?

00:13:39: Lassen Sie uns das auf dieser Sicht betrachten und dann wie wir es technisch umsetzen.

00:13:45: Denn die Umsetzung dahinter gibt sich automatisch.

00:13:48: Das kann ich dir versichern Denn auf einmal wird auch die Kostenfrage eine strategische Steuerungsfrage, und das macht einen riesen Unterschied.

00:14:01: Zurück zu dem eigentlichen Thema.

00:14:05: Architektur wird zur dritten Steuungsebene.

00:14:08: Diese Gedanken den mag ich halt wirklich sehr Weil wir oft nur in zwei Ebenen denken Auf der einen Betrieb steuert oder Portfolio steuern und Architektur halt dokumentiert.

00:14:23: Ich glaube einfach, das ist zu wenig.

00:14:26: Architektor muss immer mitsteuern Sie müssen vor allem halt diese Entscheidungen stabilisieren gegen diese kurzfristigen Budgetlogiken die halt am Start sind Und sie müssen die Roadmaps nicht nur begleiten sondern vor allen prägen.

00:14:46: Es müssen manchmal auch gegen scheinbare wirtschaftliche Entscheidungen argumentieren können wenn sie langfristig strukturell teurer werden.

00:14:56: Und das ist zwar recht, hofft sich sehr einfach an aber es ist schon sehr schwierig gerade in solchen Diskussionen da die Oberhand zu gewinnen wenn es um Oberhände geht.

00:15:07: Aber es ist in der Tat schwierig auch hier diese Diskussion in die richtige Richtung zu lenken weil das oft halt sehr viele Sturkköpfe aufeinander und der Enterprise-Architekt ist das Geschäft dahinter, das People Business.

00:15:24: Und dann muss man halt auch den richtigen Ton treffen.

00:15:26: Ich muss noch mal ein bisschen konkreter machen wie würde ich gegensteuern?

00:15:34: Also was würde ich tun?

00:15:37: Ich glaube über drei Dinge die man sich da vorhaben sollte.

00:15:42: Erstens Man sollte gemeinsam priorisieren Warum eigentlich getrennte Backlogs über Run und Change da und anzufangen?

00:15:53: Warum nicht bewusst, einfach gemeinsame Privatisierung auch vor Architekturwirkung.

00:15:58: Das ist fast Produktdenken, nicht wahr?

00:16:00: Spannend!

00:16:02: Wenn man darüber noch ein bisschen weiter denkt.

00:16:04: vorher haben wir immer geredet, na Run ist das was im Betrieb ja läuft, das was er aktuell zieht und danach habe ich Change mit Veränderungen Investitionen, die ich halt in dem reinziehe und die sind ja wirklich getrennt voneinander.

00:16:21: Das sind zwei verschiedene Betriebsteams in der Regel.

00:16:25: So wenn sich diese zusammensetzen und der Architekt eigentlich hier auch die Leitung hat das Ganze zusammenzuführen dann gemeinsam zu priorisieren.

00:16:35: haben wir das richtig mal rund das Rad.

00:16:39: Und zweitens was noch Veränderungen muss Betriebswirkung mitverantworten.

00:16:48: Das sind wir halt einfach sehr auch provokant gesagt, aber es heißt das ein Projekt sollte nicht beim Go Live aus der Verantwortung schwindeln oder verschwinden so sondern einfach spätere Betriebfolgen immer mitdenken.

00:17:05: wenn das passieren würde würde nämlich die Entscheidungen oft auch anders aussehen das garantiere ich.

00:17:13: und drittens Betrieb soll halt Veränderbarkeit mitfinanzieren.

00:17:21: Jetzt würde ich wahrscheinlich jeder im Betrieb sagen, was?

00:17:24: Ich sollte auch noch Change bezahlen.

00:17:26: Das ist ja wahnsinnig!

00:17:28: Aber das finde ich eigentlich schon sehr spannend wenn man das jetzt wirklich macht.

00:17:34: Warum finanziert einfach das Rumpage Budget fast nur die Stabilität vom System?

00:17:41: Worum kann es nicht gezielt für Architekturverbesserungen ... genutzt.

00:17:48: Nebenbei, dann spare ich mich auch als Enterprise-Redakteur anzuklopfen beim Geschäftsführer... ..."Hey!

00:17:54: Ich brauche BG, ich brauche mehr

00:17:56: Leute.".

00:17:57: Das ziehe ich mir danach ja aus den Eigensystemtöpfen die eigentlich diese ganzen ... ... Dampfungszauereien verantworten was Change angeht.

00:18:07: Warum kann ich davon nicht mit profitieren?

00:18:09: oder beziehungsweise nicht ich sondern worum können die Systeme nicht von mir profitieren?

00:18:14: Weil am Schluss schaffen wir genau diese Entkoppelung, wir machen Schuldenabbau und wir verbessern die Struktur.

00:18:22: Und das wäre wirklich eine echte Gegensteuerung.

00:18:25: Genau das ist was ich meinte mit was Architektur wirklich möglich macht.

00:18:32: Und vielleicht genau deshalb glaube ich dass Robemaps oft falsch verstanden werden als vor allem Delivery Pläne.

00:18:40: Ich sehe sie aber eigentlich aus Entlastungsfade.

00:18:45: Das klingt anders.

00:18:47: Es ist aber fundamental anders, eine gute Robene sollte finde ich nicht nur zeigen was geliefert wird sondern was danach verschwindet und zwar unsere drei Majorpunkte die Komplexität Die Aufwände Und Abhängigkeiten.

00:19:08: Wenn das nicht mehr sichtbar wird Ist es oft Aktivität Aber noch keine Architektur Wirkung.

00:19:19: Und dann vielleicht noch ein letzter Gedanke, der ich finde auch sehr wichtig ist.

00:19:24: Ich glaube manche Kostenmodelle fragen Wie verteile ich Kosten richtig?

00:19:33: aber mich interessiert viel mehr wie verhindere ich dass diese Kosten überhaupt entstehen?

00:19:40: und das ist halt einfach andere Perspektive.

00:19:44: und ehrlich Das ist Architektor Nicht Kosten sauber buchen, sondern Ursachen anders bauen.

00:19:52: Das ist für mich ein riesiger Unterschied Wenn ich das zusammenziehe.

00:19:58: und dann geht es bei Run and Change neue Steuern eigentlich nicht darum zwei Budget-Höpfe besser zu koordinieren.

00:20:06: Es geht darum Architektur als eigentlicher Steuerungsraum einfach immer ernst zu nehmen Und das ist deutlich mehr als Cost Management Ein komplett anderes Operationenmodel.

00:20:20: Und vielleicht genau deshalb eine sehr zentrale EM-Frage, in die er aus der Folge nur einsatz vielleicht hängen bleiben sollte.

00:20:28: dann vielleicht dieser viele Unternehmen versuchen Run und Change besser zu managen.

00:20:36: ich glaube wir sollten anfangen beides gemeinsam architektonisch zu steuern und das ist etwas anderes und genau deshalb wirkt EIM.

00:20:51: Somit sind wir schon wieder am Ende unserer Folge angelangt.

00:20:56: Bevor ich hier abschließe, hätte ich noch ein paar Inputen.

00:21:05: Ich habe mir jetzt den letzten Zeit so ein bisschen überlegt wie auch die Interessarchitektur weitergeht.

00:21:11: dabei habe ich mich probiert mit Videobodcast.

00:21:14: das hat irgendwie nicht so ganz geklappt.

00:21:17: vielleicht was es aber geben wird habe ich mir überlegt man sehr rudimentieren youtube video zu machen über steuerungswirkung kostenmodelle um das danach auch ein bisschen in assets wiederzugeben.

00:21:31: falls sich das interessiert laske an feedback da schick mir eine mail dann werde ich dahin auch ein bischen mehr zeit investieren.

00:21:41: und bis dahin ja servus und baba bis bald.