EAM#9: Unsichtbare Run-Kosten - Warum dein Betrieb immer teurer wird?

Architektur entscheidet über Komplexität, über Kosten, über Steuerbarkeit. Ich bin David Hohl und heiße dich herzlich willkommen bei Enterprise Architektur wirkt, der Podcast zu ERM. Servus, grüß dich und herzlich willkommen zu einer neuen Folge. Letztens ging es ja erst billig, dann teuer und warum passiert das eigentlich? Ich hoffe die Folge hat dir auch ein bisschen die Augen geöffnet oder die Ohren, dass man bei TCO genauer hinschauen sollte und dass der dir am Ende des Tages noch ein bisschen mehr verraten könnte. Heute gehe ich jedoch einen Schritt weiter. Ich schaue dahin, wo die Kosten wirklich entstehen. Nicht bei der Entscheidung, nicht bei der Unterschrift, sondern im Betrieb. Wenn ich mit Leuten über Kosten spreche, dann kommt eigentlich in der Regel fast immer das gleiche raus. Ja, die Zensen, die sind teuer, unsere Infrastruktur, die frisst uns auf. Der Support und immer dieses Weiterentwickeln und Optimieren. Als genau das, was man direkt sieht. Und das ist auch nicht falsch, verstehen wir ihn da nicht. Irgendwie verkehrt. Aber es ist halt nur ein Teil der Wahrheit. Denn der teuerste Teil, deine IT, taucht in dieser Sicht gar nicht auf. Der entsteht jeden Tag im Betrieb und bleibt unsichtbar. Wie Komplexität eigentlich wirklich entsteht, das passiert natürlich ganz langsam. Das Ganze passiert nicht mit einem großen Knall. Auf einmal, zack, ist alles da und teuer und kompliziert. Sondern ganz unspektakulier. Ich führe ein System ein, dann kommt noch eins dazu und dann noch ein weiteres. Und jedes Mal ist die Begründung völlig logisch. Das brauchen wir halt jetzt. Punkt, aus. Und meistens stimmt es auch. Das Problem ist nicht die einzelne Entscheidung. Das Problem ist halt die Summe. davon. Und wenn du tiefer reinhörst, wie zum Beispiel in den Folgen 3 bis 6 meiner ERM-Podcast-Serie, da reden wir genau darüber, wie solche Dinge eigentlich wirklich entstehen, wie Integration, Daten, Customization und Login-Schulden überhaupt herauskommen und was du auch dagegen tun kannst und wie du dagegen steuern kannst. Hier reicht mir heute auch ein Gedanke dazu. Diese Schulden entstehen nicht auf einmal, sondern einfach Schritt für Schritt. Und irgendwann habe ich Systeme, die miteinander sprechen müssen, ganz klar. Daten, die gegenseitig sich brauchen. Abhängigkeiten, die keiner mehr sauber überblickt. Und damit entsteht das ganze Übel. Der laufende Aufwand, der dahinter steckt. Und das ist das Stückische daran. Am Anfang merke ich natürlich nichts davon. Man sieht auch nichts. Bis es irgendwann dann den Betrieb dominiert. Lange funktioniert das alles, glaube ich, auch immer erstaunlich gut. Immer wenn ich da reinhöre, es pfeift, alles ist fein. Bis man dann irgendwann merkt, irgendwas verändert sich. irgendwas, die Zahnräder, die greifen nicht mehr. Denn es gibt auf einmal mehr Inzidenz. Es ist mehr Abstimmungsbedarf notwendig. Die Meetings werden immer größer, immer mehr Stakeholder kommen dazu. Jeder hat seinen Senf dazu zu kleben. Dinge dauern dann einfach länger. Und dann passiert etwas, dass ich fast in jedem Unternehmen sehe. Der Betrieb wird auf einmal professionalisiert. Tja, bevor ich hier weitermache, lassen Sie uns mal kurz etwas einordnen. Wenn ich jetzt von ESM spreche, also Enterprise Service Management, da meine ich nicht nur die IT, sondern den Betrieb im gesamten Unternehmen. Also alles, was intern als Service läuft. Die IT natürlich, aber genauso wie die HR, die gesamten Onboarding und Offboarding Prozesse, die dafür notwendig sind, der Finance-Bereich, Freigabenbuchungen und so weiter oder auch der Einkauf und Legal. Im Kern geht es für mich um eine Frage. Wie organisiert ein Unternehmen seinen Betrieb? Und ein Punkt, den ich immer wieder sehe, wenn ich über ESM spreche, dann meinen eigentlich alle ITSM, genau. Nur ich rede halt von ESM und das ist ein bisschen größer gedacht. Also, die gleichen Mechaniken, die gleichen Prozesse, nur auf mehrere Bereiche ausgewählt, Punkt. Das ist es. Die Grundlage dafür kommt, wie oft, immer aus dem ITIL raus. ITIL ist natürlich kein Tool, sondern einfach ein Framework. Und was wir eigentlich aus Frameworks immer gelernt haben, ist, also wir wollen uns Best Practice daraus ziehen. Und genau in diesem Kontext, wie ich meinen Betrieb stabil halte. Und das funktioniert auch. Gerade am Anfang. Ich bringe eine neue Struktur rein, ich schaffe Klarheit, ich bekomme den Chaos in den Griff, glaubt man. Und jetzt kommt der spannende Teil. Mit ESM hebe ich das Ganze auf Unternehmensebene und bringen halt genau dieses Enterprise mit rein. Das heißt, mehr Bereiche sind da halt involviert, mehr Übergaben entstehen und mehr Abstimmung ist natürlich notwendig. Tja, und plötzlich wird was sichtbar. Wie viel Betrieb eigentlich wirklich passiert? Falls du jetzt ein eitel Evangelist bist, verstehe das Ganze nicht falsch, bitte. Ich schaue nur auf die wirklichen Langzeitfolgen, gerade bei Einführung von allen Methodiken, Frameworks und Modellen, die es so am Markt gibt. Wie auch immer. Und genau hier wird es nämlich dann interessant. Denn jetzt habe ich etwas erreicht. Der Betrieb ist strukturiert. Und er ist steuerbar. Aber die Komplexität ist immer noch da. Die ist nicht weg. Nehmen wir mal so ein Beispiel, gerade dieser sogenannte Ticket-Effekt, wie ich ihn nenne. Und dann sehe ich plötzlich Dinge, die vorher einfach untergegangen sind. Zum Beispiel Tickets, viele Tickets, Abstimmungen, Eskalationen und die Durchlaufzeiten dafür. Und die erste Reaktion ist fast immer, wir müssen unsere Prozesse verbessern. Unser BPM ist nicht cool und es funktioniert alles so richtig. und wir sind anders. Wir können nicht den Standard nutzen. Wir müssen darin optimieren. Aber das greift halt zu kurz, denn das Ticket ist nicht das Problem. Das Ticket ist das Symptom. Da, wo es auf einmal was rauskommt, sichtbar ist, wie bei einer Krankheit, auf einmal kommt der Pickel, okay, ist keine Krankheit, als Jugendlicher vielleicht damals schon, aber es ist auf einmal sichtbar. Es ist vielleicht, wenn ich nicht früher oft genug waschen habe, im Gesicht und deswegen haben wir heute Pickett bekommen. Die eigentliche Frage ist, warum entstehen diese Tickets überhaupt? Und die Antwort liegt nicht halt im Prozess, sondern du sagst das, in der Architektur. Wenn Systeme voneinander abhängig sind, wenn Daten einfach hin und her geschoben werden müssen, wenn Übergaben einfach notwendig sind, dann entsteht halt Arbeit. Und zwar eine dauerhafte. Jeder Übergang kostet. Immer wieder. Und jetzt kommt der Punkt, den ich bewusst so formuliere, um einfach da auch Klarheit zu schaffen. Für mich ist ITAL, so macht den Betrieb auch effizient. Nicht falsch verstehen. Aber wenn die Architektur falsch ist, macht Eitel genau das blöderweise effizienter, was am Schluss halt die Kosten hoch umtreibt, was teuer macht. Ich werde besser darin, natürlich Tickets zu bearbeiten, Abläufe strukturieren und Themen sauber durchzuziehen. Als Unternehmen natürlich. Aber gleichzeitig produziere ich mehr von genau diesen Themen, die ich eigentlich gar nicht am Tisch haben möchte. Deswegen ist nicht das Framework deswegen schuld, sondern die Architektur, die einfach da drunter liegt. Und wenn ich natürlich jetzt ein Framework einhaue, das was ein Betrieb optimieren sollte, dann beruht das natürlich auf einer Architekturgrundlage. Und wenn die schon falsch ist, dann optimiere ich genau diese Fehler. Unbewusst. Und mit der Zeit passiert genau das, was ich halt immer wieder beobachte. Workarounds werden einfach normal, Sonderfälle werden Standard. Übergaben werden als selbstverständlich dargestellt. Und irgendwann habe ich eine Organisation von mir, die perfekt darin ist, Komplexität zu managen. Aber nicht mehr sie zu reduzieren. Und jeder fragt sich, warum das danach am Ende des Tages so lange dauert. Ja, jetzt weißt du es. Die Architektur war vielleicht nicht sauber gestreckt am Anfang. Ein Punkt wird dabei fast immer unterschätzt. Mein Goldschatz, mein Liebling, die Daten. Sobald mehrere Systeme im Spiel sind, habe ich automatisch mehrere verschiedene Wahrheiten. Und die Daten werden halt kopiert und nicht reduziert. Man verdoppelt sie, man synchronisiert sie. Manchmal blöderweise auch noch manuell. Darüber haben wir auch mal gesprochen. Und jedes Mal steckt dahinter Abstimmung, Klärung und eine Nacharbeit, die notwendig ist. Also wieder Betrieb. Und jetzt komme ich auf den wichtigsten Punkt. Der Übergang. Die Transition. Ich führe etwas Neues ein. Aber das Alte bleibt. Weil es noch gebraucht wird. Weil Abhängigkeiten da sind. Weil das Risiko einfach zu hoch ist. Das abzuschalten. Das kennst du bestimmt auch. Und das bedeutet, Dinge laufen einfach doppelt weiter und die Verantwortung ist einfach an der Stelle unklar. Und da natürlich der Aufwand steigt. Wenn der Aufwand steigt, steigen die Kosten sichtbarerweise auch. Und das nicht über ein paar Wochen, sondern oft über Jahre streckt sich das hin. Wenn ich mir jetzt nur den klassischen TCO anschaue, dann wirkt das alles relativ sauber. Da stehen nämlich die Kosten drinnen, da steht der Betrieb drinnen. Und da reden wir halt von unseren OPEX, genau. Aber was fehlt? Genau diese Zwischenzustände, diese Reibungen, die da entstehen und diese Parallelität, die einfach dabei aufgebaut wird. Also genau das, was wirklich teuer ist. Und ich rede noch gar nicht über die technischen Schulden. Und jetzt der Punkt nochmal, der für mich noch wichtiger ist wie der folge Punkt. Betrieb ist People Business. Es geht nicht um Technik. Es geht um Abstimmung, Kommunikation, wir reden miteinander, wir brauchen Verständnis, das was wir da tun und wir müssen uns gemeinsam halt koordinieren etwas zu schaffen. Und das skaliert halt nicht mit Systemen. Das skaliert nur mit Komplexität, blöderweise. So, ich habe vielleicht ganz kurz ein Beispiel. Ich habe ein Inzident und plötzlich sitzen mehrere Leute zusammen. Das ist auf einmal. Jeder schaut auf das System. Was ist das Problem? Und jeder hat nur einen Teil der Wahrheit. Was passiert? Es wird koordiniert. Und genau das kostet am Ende des Tages wieder. Nicht die Technik dahinter. Die Systeme sind meine Grundkosten schuld. Aber umso mehr Leute zusammenkommen, umso mehr Koordinierungsaufwand notwendig, umso mehr Kosten habe ich. Das ist das 1x1, das kennt jeder. Und genau deshalb steigen halt diese Run-Kosten. Nicht weil alles teuer wird, sondern weil die Struktur komplexer wird. Und die Komplexität verschwindet halt nicht einfach. Sie bleibt, sie wächst einfach weiter. Und genau deshalb steigen halt diese Run-Kosten. Nicht, weil alles teurer wird, sondern die Struktur wird komplexer. Und ich sehe das halt immer wieder in ganz konkreten Dingen. Da kommt halt ein neues System dazu, vielleicht ein Marketing-Automation oder irgendeine CM-Erweiterung für sich genommen, völlig legitim. Und ich würde wahrscheinlich genauso entscheiden. Aber genau dann passiert halt etwas, dass halt im Endeffekt mehr Daten gebraucht werden und die ganzen Interfaces dazwischen. und dann gibt es halt den Fehler, ich brauche halt ein Monitoring dahinter, dann kommen die Sonderfälle also baue ich Workarounds und irgendwann merke ich halt das System war wirklich nie das Problem, denn der Betrieb drumherum ist halt einfach explodiert und ein zweites Muster, das ich halt oft sehe ich ersetze etwas, irgendein System oder irgendwas Plugin oder Modul und irgendwas, das halt einfach nicht passt. Und natürlich sage ich, das Alte lassen wir erstmal noch laufen, nur für den Übergang und dieser Übergang dauert dann nicht drei Monate, sondern sechs oder vielleicht sogar manchmal zwölf oder noch länger wie zwei, drei Jahre. Und in der Zeit passiert halt Folgendes, dass die Dinge, die halt laufen, Einfach doppelt, die Daten werden doppelt gepflegt, doppelt Interfaces sind unterwegs, die Eskalierung geht nach oben, die Systeme sind doppelt überlastet, Abstimmungen entstehen, die es einfach vorher gar nicht gab. Und genau das ist halt der Punkt, diese Kosten siehst du halt vorher nicht. Du zahlst sie halt nur jeden Tag. Und dann, wenn man halt genau den Betrieb mit Methodiken und Themen optimieren möchte oder professionalisieren, dann kommt halt ESM ins Spiel und plötzlich sehe ich dann halt mehr Tickets, einfach mehr Abstimmungen, mehr Themen aus völlig unterschiedlichen Bereichen, alles noch legitim und alles okay, also nicht falsch verstehen. Und dann melden sich auf einmal die Bereiche. HR meldet was, Finance meldet was und so weiter. Und IT, die haben sowieso immer was zu sagen. Und dann wird halt einfach eins klar, Das ist halt kein IT-Problem. Das ist halt ein Architektur- oder halt ein Strukturproblem, das gelöst werden muss. Die eigentliche Perspektive, die einfach da einfach wichtig ist, die, was man einnehmen soll. Ich muss aufhören, in Systemen zu denken. Und halt einfach anfangen, in Capabilities zu denken, also in Fähigkeiten von Unternehmen. Nebenbei darüber werden wir noch speziell im nächsten Monat im Mai sehr, sehr ausführlich sprechen, was Capabilities sind und was für einen Mehrwert du daraus ziehst. Du nutzt sicher die eine Art von Business Capability schon, aber nicht meine Perspektive und ich hoffe, die wird dir weiterhelfen. Wie auch immer, ich nehme mal ein ganz einfaches Beispiel. Wir verwalten Kunden. Das kann ich in einem System machen. Oder halt verteilt über mehrere. Was die Regel ist. Und in beiden Fällen kann ich sagen, es funktioniert doch. Der Unterschied liegt halt woanders. Im ersten Fall habe ich Klarheit. Im zweiten Fall habe ich Abstimmung. Und genau das ist der Punkt. Abstimmung ist Betrieb. Und was viele dabei einfach unterschätzen. Kosten entstehen nicht nur heute, sondern halt über die Zeit. Ich glaube, da könnte ich mir schon langsam tätowieren. Wenn ich heute was entscheide, zum Beispiel in dem Fall Systeme enger zu koppeln, eher zusammenzubringen, dann zahle ich dafür natürlich bei jeder Änderung, bei jedem Inzident, bei jeder Erweiterung. Und das halt nicht einmal, sondern einfach über Jahre. Und dann brauche ich nur bloß Rechner lernen. Deshalb ist halt für mich ein Satz so wichtig, den du dir vielleicht auch mal einrahmen könntest. Architektur ist halt kein Kostenblock. Architektur ist ein Kostenverlauf. Und es liegt in unserer Kraft, das zu steuern. In unserer Macht auch das, in eine richtige Richtung zu lenken. Wir sind keine Mitschwimmer, wir sind die Vorschwimmer, die im Endeffekt aufzeigen, wie man Architektur richtig lenken soll. Und das ist der Enterprise-Architekt. Ich habe vorhin auch einen Satz gesagt, den ich nochmal bewusst wiederholen möchte. Der Betrieb ist nicht teuer, weil er schlecht organisiert ist. Er ist teuer, weil einfach die Architektur ihn teuer macht. Und ich ergänze ihn nochmal den Satz. Und genau deshalb reicht es nicht, den Betrieb zu optimieren. Ich muss die Ursache darunter verändern. Und damit komme ich zur eigentlichen Grundfrage dieser Folge. Dabei soll sie nicht lauten, wie optimiere ich meinen Betrieb. Den höre ich leider zu oft, gerade in Gesprächen, die im Service-Management-Bereich auch stattfinden. sondern die Frage sollte eigentlich in die Richtung gesetzt werden, wie reduziere ich die Notwendigkeit im Betrieb. Und genau da kommt halt Enterprise-Architektur, Management ins Spiel. Da sind die Enterprise-Architekten unterwegs. Ganz konkret, ich reduziere halt damit halt Übergaben, ich entkopple Systeme, ich reduziere Komplexität, ich kläre, wer eigentlich wirklich verantwortlich ist. ERM ist People Business. und nichts anderes. Zum Schluss noch. Ich hatte mal so einen Fall. Einfach, dass halt mehrere Systeme für mehrere Kundendaten im Einsatz waren. Das ist auch nichts Spezielles. Zu dem Zeitpunkt haben auch alle Systeme die Notwendigkeit gehabt, die Daseinsberechtigung war einfach da. Aber niemand hatte halt die Verantwortung dahinter und die Diskussion, die ich damals geführt habe, war immer am folgenden Punkt, wie können wir das besser synchronisieren? Dann hat der eine Solucion-Architekt immer gesagt, ja, dann haben wir halt den ESB dazwischen, dann machen wir Mittelwehr und dann tun wir da nochmal die Business-Logik oder die Logik der Daten verändern. Und die nächste Frage natürlich, wie kommen wir das nachher stabil? Wie können wir gerade bei Skalierungen oder Skalierungsevents das besser auch in den Griff kriegen? Und ich habe gesagt, hey Leute, stopp. Das ist nicht das Problem, was wir hier haben. Kommt es mal wieder runter. Ihr habt es einfach. Das Problem ist, es gibt halt einfach hier keine klare Entscheidung. Also haben wir genau das gemacht. Das System eingeführt. Und der Rest richtet sich dann auch. Punkt. Und plötzlich, was ist weniger geworden? Wir haben weniger Abstimmungen. Wir haben weniger Tickets gehabt. Weniger Inzidenz, klarerweise. Weil es halt Nummer 1 System ist. Die die Daten oder hat. Deswegen ist genau halt Reduktion an der Stelle, war halt gerade die einzige Lösung, im Endeffekt um die Hauptprobleme in den Griff zu bekommen. Und dann haben wir halt den Betrieb reduziert. Und das ist der Punkt, den ich dir mitgeben will. Die meisten Unternehmen versuchen einfach immer wieder, ihren Betrieb effizienter zu machen. Check. Aber die Wichtigsten stellen sich einfach nicht die Frage, ob sie diesen Betrieb überhaupt in der Form brauchen. Und genau das schaue ich mir in der nächsten Folge an. Wie komme ich da wieder raus und wo setze ich konkret an? Und was kann ich wirklich reduzieren? Servus und Baba und bis auf bald.