Die Modernisierung eines Altsystems scheitert selten an der Technik. Sie scheitert an einer Sitzung, in der ein Entwicklungsleiter erklärt, dass das System in einem schlechten Zustand ist, und eine Geschäftsführung fragt, was das denn nun kostet und was dafür herauskommt.
An dieser Stelle fällt fast immer das Wort von den technischen Schulden. Es ist ein gutes Bild und ein schlechtes Argument, denn es beschreibt ein Gefühl, keine Zahl. Die Gegenseite hört: Die Entwickler hätten gern besseren Code. Und das ist, aus ihrer Sicht, kein Grund für ein Budget.
Dieser Artikel beschreibt, wie man denselben Sachverhalt so aufschreibt, dass er eine Entscheidung trägt. Er enthält keine Rhetorik, sondern vier Kostenarten, ihre Messung und die Stellen, an denen man sich nicht verrechnen darf.
Warum „technische Schulden" als Argument nicht funktioniert
Der Begriff hat einen Konstruktionsfehler: Er verlangt vom Zuhörer, eine Übersetzung selbst zu leisten. Schulden sind etwas, das man zurückzahlt. Nur steht bei echten Schulden die Summe im Kontoauszug, und hier steht sie nirgends.
Dazu kommt, dass der Begriff nach innen gerichtet ist. Er beschreibt, wie sich Arbeit anfühlt, nicht was sie kostet. In einer Geschäftsführung sitzen Menschen, die Entscheidungen über Kapital treffen und dabei Alternativen vergleichen: diese Modernisierung gegen zwei zusätzliche Vertriebsstellen, gegen eine Messe, gegen nichts tun. In diesem Vergleich verliert jedes Argument, das keine Zahl hat, gegen jedes, das eine hat.
Das ist keine Ignoranz, sondern die richtige Vorsicht gegenüber einem Vorhaben ohne sichtbares Ergebnis. Ein Modernisierungsprojekt sieht von außen aus wie ein Jahr Arbeit, nach dem das Produkt genauso aussieht wie vorher. Warum das trotzdem ein Geschäftsrisiko ist, habe ich an anderer Stelle beschrieben. Hier geht es um den Schritt danach: die Rechnung.
Die vier Kostenarten, die sich beziffern lassen
Der Zustand eines Altsystems kostet Geld an vier Stellen. Drei davon stehen in Systemen, die Ihr Haus ohnehin führt; die vierte ist eine Schätzung, die man als solche kennzeichnet.
Betriebskosten. Server, Lizenzen, Wartungsverträge, externe Dienstleister, verlängerter Sicherheitssupport. Der Posten ist der kleinste und der einzige, der oft schon vollständig irgendwo steht. Wichtig ist nur, ihn zusammenzuziehen: Er verteilt sich regelmäßig über drei Kostenstellen, und niemand hat die Summe je gesehen.
Änderungskosten. Was kostet es, eine Änderung in dieses System zu bekommen, im Vergleich zu einem gesunden. Das ist der größte Posten und der, den man messen kann, ohne zu schätzen. Wie, steht im nächsten Abschnitt.
Ausfallkosten. Häufigkeit mal Dauer mal Umsatz oder Kosten je Stunde. Die Häufigkeit steht im Ticketsystem, die Dauer auch, den dritten Wert nennt Ihnen die Finanzabteilung in fünf Minuten.
Verhinderte Vorhaben. Das ist die Liste der Dinge, die jemand wollte und die nicht gemacht wurden, weil sie in diesem System zu teuer oder zu riskant waren. Diese Liste existiert immer, sie steht nur in keinem System, sondern in den Köpfen von zwei bis drei Menschen. Sie einzusammeln ist eine Stunde Arbeit und liefert den Posten, der am meisten bewegt.
Änderungskosten messen statt schätzen
Der Satz „bei uns dauert alles dreimal so lange" ist wahr und wertlos. Nützlich wird er, wenn eine Zahl daran hängt, und die steht im Ticketsystem.
Gemessen wird die Durchlaufzeit: die Zeit von „jemand hat entschieden, dass das gemacht wird" bis „es läuft in Produktion". Nicht die geschätzten Personentage, denn die messen die Schätzung, nicht das System.
-- Durchlaufzeit je Vorgang, Median über die letzten zwölf Monate
SELECT
DATE_FORMAT(fertig_am, '%Y-%m') AS monat,
COUNT(*) AS vorgaenge,
ROUND(AVG(DATEDIFF(fertig_am, begonnen_am))) AS tage_schnitt
FROM vorgang
WHERE art = 'feature' AND fertig_am >= DATE_SUB(CURDATE(), INTERVAL 12 MONTH)
GROUP BY monat
ORDER BY monat;Drei Auswertungen machen daraus ein Argument.
Der Vergleich über die Zeit. Wenn die Durchlaufzeit vor drei Jahren bei neun Tagen lag und heute bei einundzwanzig, ist das die Aussage. Sie braucht keinen Vergleich mit anderen Unternehmen, weil sie den Trend im eigenen Haus zeigt, und sie ist damit gegen den häufigsten Einwand immun.
Der Vergleich zwischen den Bereichen. Wenn Änderungen im neuen Teil der Plattform vier Tage brauchen und im alten zwanzig, ist der Unterschied nicht die Mannschaft, sondern das System. Dieser Vergleich ist der stärkste, den es gibt, weil er alle anderen Erklärungen ausschließt.
Der Anteil der Nacharbeit. Wie viele Vorgänge sind Fehlerbehebungen an Dingen, die im selben Quartal ausgeliefert wurden. Steigt dieser Anteil, wird nicht langsamer gearbeitet, sondern doppelt.
Aus dem Unterschied wird Geld, indem Sie ihn mit dem multiplizieren, was ein Entwicklertag im Haus kostet. Das ist eine Zahl, die die Personalabteilung kennt, und sie muss in dieser Rechnung nicht genau sein, weil das Ergebnis Größenordnungen liefert und keine Nachkommastellen.
Risiko rechnen, statt mit Angst zu argumentieren
Der vierte Posten ist der, bei dem die meisten Präsentationen ins Rutschen kommen, weil sie mit dem Schlimmsten argumentieren. „Wenn die Datenbank ausfällt, steht das Unternehmen." Das mag stimmen und es wirkt trotzdem nicht, weil jeder im Raum weiß, dass es seit acht Jahren nicht passiert ist.
Was wirkt, ist ein Erwartungswert: Wahrscheinlichkeit mal Schaden, offen als Schätzung gekennzeichnet.
Risiko p/Jahr Schaden Erwartungswert
Ausfall > 4 h wegen Altsystem 0,30 120.000 € 36.000 €
Sicherheitsvorfall (EOL-Paket) 0,10 250.000 € 25.000 €
Schlüsselperson fällt aus 0,20 80.000 € 16.000 €
--------
77.000 €Drei Dinge machen den Unterschied, ob eine solche Tabelle überzeugt oder als Zahlenspiel abgetan wird.
Die Wahrscheinlichkeiten kommen aus der eigenen Historie, nicht aus einer Studie. Zwei Ausfälle in fünf Jahren sind 0,4 pro Jahr. Das ist angreifbar, aber nachvollziehbar, und angreifbar plus nachvollziehbar schlägt unangreifbar plus erfunden.
Der Schaden wird aus dem eigenen Umsatz gerechnet, mit genannter Formel. Vier Stunden Ausfall an einem normalen Werktag sind ein Bruchteil des Tagesumsatzes plus die Arbeitszeit der Menschen, die in dieser Zeit nicht arbeiten können.
Die Tabelle nennt, was sie nicht weiß. Eine Spalte mit der Herkunft jeder Zahl (gemessen, geschätzt, angenommen) macht sie glaubwürdiger, nicht schwächer. Wer Unsicherheit ausweist, wird bei der einen Zahl angegriffen, die unsicher ist. Wer sie versteckt, verliert die ganze Tabelle, sobald jemand eine Zahl anzweifelt.
Was Sie nicht in die Rechnung schreiben
Drei Posten tauchen regelmäßig auf und schwächen jede Vorlage, in der sie stehen.
Produktivitätsgewinne in Prozent. „Dreißig Prozent schnellere Entwicklung" ist eine Zahl ohne Quelle. Sie klingt nach Beleg und ist eine Hoffnung, und die erste Nachfrage bringt das ans Licht. Die gemessene Durchlaufzeit aus dem eigenen Haus leistet dasselbe und hält stand.
Zufriedenheit im Team. Sie ist real und sie ist ein Ergebnis, kein Argument. In einer Investitionsrechnung wirkt sie wie ein Zugeständnis, dass die harten Zahlen nicht reichen.
Moderne Technik als Wert an sich. Eine neue Sprachversion, ein neues Framework, eine andere Architektur: Das sind Mittel. Wer sie als Ziel aufschreibt, bestätigt genau den Verdacht, gegen den die ganze Vorlage argumentiert.
Die andere Seite der Rechnung, also was das Vorhaben selbst kostet und wovon der Preis abhängt, steht in Was eine Modernisierung kostet.
Die eine Folie
Am Ende steht eine Seite, und sie hat vier Zeilen. Alles andere ist Anhang für die Nachfragen.
Heute kostet das System ~ 310.000 € / Jahr
davon Betrieb 60.000 € (gemessen)
davon Mehraufwand je Änderung 140.000 € (gemessen, Durchlaufzeit)
davon Risiko, Erwartungswert 77.000 € (geschätzt)
davon verhinderte Vorhaben 33.000 € (geschätzt, 3 Vorhaben)
Das Vorhaben kostet ~ 380.000 € über 14 Monate
Danach bleibt ~ 120.000 € / Jahr
Amortisation ~ 24 Monate ab AbschlussDer entscheidende Teil dieser Folie ist die rechte Spalte, nicht die linke. Sie sagt, welche Zahl gemessen und welche geschätzt ist, und genau diese Unterscheidung ist es, die eine Geschäftsführung von einer technischen Vorlage sonst nicht bekommt.
Und noch etwas gehört dazu: eine Zeile für den Fall, dass nicht entschieden wird. Nichts zu tun ist eine Option, die auch einen Preis hat, und sie ist in dieser Rechnung die teuerste.
Wenn die Folie sitzt, fehlt noch der Zuschnitt: Zwölf Wochen Modernisierung.
Der Einwand, der immer kommt
„Wenn das System so teuer ist, rechnet sich der Umbau in vierundzwanzig Monaten, und in vierundzwanzig Monaten kann viel passieren."
Der Einwand ist berechtigt, und die Antwort darauf ist keine Rhetorik, sondern ein Zuschnitt: Das Vorhaben wird so geschnitten, dass es nach drei Monaten das erste Mal etwas zurückgibt. Nicht eine Modernisierung mit einem Ergebnis am Ende, sondern eine Folge von Schritten, von denen jeder einzeln produktiv geht.
Damit ändert sich die Frage, die zur Entscheidung steht. Sie lautet nicht mehr „vierzehn Monate und 380.000 Euro, ja oder nein", sondern „drei Monate und 80.000 Euro für den ersten Schritt, und danach entscheiden wir wieder". Das ist eine Frage, die eine Geschäftsführung beantworten kann, und es ist nebenbei die einzige Art, Modernisierung zu betreiben, die ich für verantwortbar halte: alles andere ist ein Neubau mit einem anderen Namen.
Wenn Sie an einer solchen Vorlage sitzen: wie ich eine schrittweise Modernisierung schneide, steht auf einer eigenen Seite. Die Rechnung oben können Sie auch ohne mich aufstellen, und das ist der Punkt.
Dieser Artikel gehört zu einer Reihe über Systeme, die es schon gibt. Der Rückblick ordnet alle Artikel der Reihe nach Anlass.
