10. KI-Gewinne richtig rechnen: Kapazität, Durchlaufzeit, CFO

Otto

Wenn mir noch ein einziger Softwarevertreter vorrechnet, dass vierhundert eingesparte Entwicklerstunden mal hundert Euro Stundensatz exakt vierzigtausend Euro Gewinn bedeuten... dann gehe ich aus dem Raum.

Leonie

Weil das Geld ja nicht auf dem Girokonto landet. Man, man entlässt die Leute ja nicht, und das Budget schrumpft dadurch auch nicht magisch.

Otto

Genau das! Bei einem Rüstungs- und Technologiekonzern wie Thales fliegst du mit so einer Milchmädchenrechnung beim Finanzchef sofort hochkant raus. Zeit auf dem Papier ist keine harte Einsparung.

Leonie

Wir müssen das, was wir neulich über GitLab Credits diskutiert haben, jetzt mal operativ sauber aufdröseln. Wenn vierhundert Stunden kein Bargeld sind, was sind sie dann? Wir müssen drei Töpfe trennen.

Otto

Erstens: harte Einsparungen. Das ist echtes Geld, das nicht ausgegeben wird. Ein teures Altsystem wird abgeschaltet, externe Beraterverträge werden gekündigt. Physische Server fallen weg. Das sieht der CFO in der Gewinn und Verlustrechnung.

Leonie

Und zweitens: Kapazitätswert. Die Ingenieure sind ja da, sie sind hochbezahlt, aber sie stecken in Routine fest. Wenn du ihnen vierhundert Stunden frei schaufelst, können sie an fest beauftragten Programmen arbeiten, für die sonst neue Leute eingestellt werden müssten.

Otto

Vorausgesetzt, das Team ist wirklich überlastet und die gewonnene Zeit verpufft nicht beim Kaffeetrinken. Und der dritte Topf ist der Durchlaufzeit Wert. Wenn eine sicherheitskritische Software zwei Wochen früher einsatzbereit ist, verhindert das Verzugsstrafen oder sichert Meilensteine.

Leonie

Und das ist der Kern dieser ganzen Business Outcome Engine. Du startest niemals, absolut niemals mit einer Prognose, wie viele KI Credits du verbrauchen willst. Oder mit einer glitzernden Demo von irgendeinem Chatbot.

Otto

Sondern? Wo fängt man an?

Leonie

Du nimmst dir einen ganz konkreten, schmerzhaften Workflow. Misst, wie viele Minuten echte Menschen heute daran herumdoktern, wie lange das Zeug dumm in der Gegend herumliegt und was Fehler kosten. Erst wenn diese Nulllinie steht, darf überhaupt über Werkzeuge geredet werden.

Otto

Da berührst du einen wunden Punkt, den die meisten völlig übersehen: den Unterschied zwischen aktiver Arbeit und Liegezeit.

Leonie

Erklär das mal an einem konkreten Beispiel aus der Softwareentwicklung.

Otto

Aktiver Aufwand ist, wenn ein Entwickler zweiundzwanzig Minuten lang hochkonzentriert Codezeilen liest. Oder fünfunddreißig Minuten lang ellenlange Build Logs durchforstet, um einen Fehler zu finden. Da verbrennt Gehirnschmalz und Arbeitszeit.

Leonie

Und Liegezeit ist das, was dazwischen passiert?

Otto

Genau. Der Merge Request ist fertig, aber er liegt vierzehn Stunden untätig im Postfach, weil der Senior Reviewer in Meetings sitzt. Niemand arbeitet daran. Das Projekt steht einfach still.

Leonie

Das heisst, wenn ich die zweiundzwanzig Minuten Lesezeit verkürze, schaffe ich Kapazität für den Entwickler. Wenn ich die vierzehn Stunden Wartezeit kille, verbessere ich den Durchlauf.

Otto

Richtig. Ich habe das vor Jahren mal bei einem Team erlebt. Da wurden ultrachice, neue Entwicklungsumgebungen eingeführt. Die Leute haben angeblich dreißig Prozent schneller Code getippt. Riesiger Jubel im Management.

Leonie

Und das Projekt war drei Monate früher fertig?

Otto

Keinen einzigen Tag! Weil der schnell getippte Code danach fünf Tage lang in einer unbesetzten Review Warteschlange verschimmelt ist. Sie haben die aktive Zeit optimiert, aber der Flaschenhals war die Liegezeit.

Leonie

Genau deshalb braucht man diese sogenannte zwanzig Fragen Karte. Jeder Anwendungsfall muss da durch. Wer macht heute was? Wie viele Minuten dauert es aktiv? Wie viele Stunden liegt es? Welche Governance Regeln greifen? Und ganz entscheidend: Wer ist der benannte Metric Owner?

Otto

Also die Person auf Kundenseite, die am Ende unterschreibt und sagt: Ja, diese Messung stimmt und das hat uns wirklich geholfen.

Leonie

Exakt. Ohne diesen Namen und ohne vorher definierte Kriterien für Erfolg oder Misserfolg hast du keinen Business Case. Du hast nur ein unkontrolliertes Softwareexperiment.

Otto

Lass uns das mal an den Zahlen festmachen, die bei GitLab offiziell auf dem Tisch liegen. Nimm den Code Review Flow. Was kostet so etwas eigentlich in der Realität?

Leonie

Man rechnet da nicht in Tausenden von Euro, sondern in Centbeträgen. Nach den offiziellen Raten kriegst du beim Code Review Flow vier Durchläufe pro GitLab Credit, wenn du das verwaltete Modell nutzt. Bei einem Listenpreis von einem Dollar pro Credit sind das fünfundzwanzig Cent pro Review.

Otto

Und wenn Thales das Modell selbst hostet, sind es fünf Durchläufe pro Credit, also zwanzig Cent pro Prüfung. Das ist überschaubar. Aber, und das ist in der Rüstung zentral: Der Agent ersetzt nicht die menschliche Freigabe.

Leonie

Niemals. Der Agent macht die Vorarbeit, fasst zusammen, sucht nach offensichtlichen Schnitzern im Kontext des gesamten Repositories. Aber die Freigabe, das Vier Augen Prinzip, bleibt zwingend beim menschlichen Ingenieur.

Otto

Und wie sieht das bei kaputten Pipelines aus? Das war ja im ersten Interview mit André ein riesiges Thema.

Leonie

Der Fix CI CD Pipeline Flow ist mittlerweile allgemein verfügbar. Der Agent zieht sich die Logs, die Fehlermeldungen, die Exit Codes und vergleicht das mit den Änderungen im Merge Request. Er schlägt dann direkt eine Korrektur vor oder erstellt einen neuen Zweig.

Otto

Und wenn die Ursache unklar ist oder sicherheitsrelevante Skripte berührt werden? Pfuscht die KI dann einfach drauflos?

Leonie

Eben nicht. Die Dokumentation sagt ganz klar: Wenn der Kontext nicht reicht oder Sicherheitsbedenken bestehen, stoppt das System und liefert nur eine strukturierte Erklärung für den Menschen. Da wird nichts blind überschrieben.

Otto

Das bringt uns zum wichtigsten Prinzip überhaupt: Scale or Stop. Skalieren oder stoppen.

Leonie

Ja! Wenn du einen Pilotversuch mit einem Team machst, misst du vorher den Aufwand und danach den Aufwand plus die verbrauchten Credits. Wenn die Rechnung unterm Strich nicht aufgeht oder die Qualität leidet, machst du das Ding eiskalt zu.

Otto

Ohne Gesichtsverlust. Das ist der Unterschied zwischen blindem KI Hype und Ingenieurdisziplin. Man rollt nichts für fünftausend Entwickler aus, nur weil es modern klingt. Man beweist den Grenznutzen an einem Workflow, oder man lässt es bleiben.

Leonie

Am Ende zählt nicht, wie viele Leute einen KI Knopf im Editor haben. Es zählt einzig und allein, was das fertige, geprüfte Ergebnis pro Durchlauf kostet. Und ob die Software dadurch sicherer und schneller fliegt.