# Wann eine KI-Investition sich rechnet > Time-to-Value entscheidet, ob eine KI-Investition im Vorstandsbericht steht oder unter 'Digitalisierung' verbucht wird. Sechs Kennzahlen, drei Verzögerungsarten und die Frage, wann ein Pilot beendet werden muss. Veröffentlicht: 2026-09-12 Wer KI in einem Unternehmen einführt, steht innerhalb der ersten drei Monate vor einer Frage, die im Innovationsbudget selten steht: wann sehen wir das Geld zurück? Die Frage ist berechtigt, die Antwort ist unbequem, und die Disziplin, mit der sie beantwortet wird, entscheidet darüber, ob das Programm im nächsten Budgetzyklus weiterläuft oder als gescheitertes Pilotprojekt endet. Wer die ökonomische Seite noch nicht kennt, dem hilft [Die wahren Kosten eines Tokens](/posts/kosten-eines-token/) weiter, wer die Beschaffungsseite kennt, der findet sie in [KI-Beschaffung ohne Lock-in](/posts/beschaffung-und-lock-in/), und wer das Risiko am Rand der Verteilung versteht, dem hilft [Tail Risk in der KI-Adoption](/posts/tail-risk-ki/) weiter. Was an dieser Stelle fehlt, ist die Brücke zwischen Investment und Ergebnis. ## Auf den Punkt Wer die nächsten fünf Minuten nicht hat: **Time-to-Value ist die einzige Kennzahl, die im Vorstand zählt.** Wer KI einführt, misst sechs Werte: Adoption-Rate, Median-Usage-pro-User, Cost-per-Resolved-Task, Substitution-Rate, Time-to-First-Value und Break-Even-Quartal. Wer auf eine dieser sechs verzichtet, hat nach zwölf Monaten eine Präsentation, die nicht überzeugt. Wer alle sechs misst und monatlich reportet, hat nach zwölf Monaten eine Belegkette, die das Budget für die nächsten drei Jahre sichert. ## Glossar {% definition term="Time-to-First-Value" description="Die Zeit zwischen dem ersten Login eines Nutzers und dem ersten messbaren Ergebnis, das mit der KI erreicht wurde. Wer Time-to-First-Value misst, weiss, wie schnell ein Nutzer vom Probieren zum Produzieren kommt. Wer es nicht misst, weiss nicht, ob das Tool benutzt wird." /} {% definition term="Substitution-Rate" description="Der Anteil einer Aufgabe, der durch KI ersetzt wird, gemessen in Stunden oder Vorgängen. Eine Substitution-Rate von 30 Prozent in der Doku-Pflege heisst, dass 30 Prozent der bisherigen Stunden wegfallen, nicht, dass 30 Prozent der Aufgaben verschwinden. Wer Substitution-Rate nicht von Substitution-Rate trennt, argumentiert später gegen sich selbst." /} {% definition term="Adoption-Rate" description="Der Anteil der lizenzierten Nutzer, die das Produkt innerhalb eines Monats aktiv verwenden. Eine Adoption-Rate unter 20 Prozent nach drei Monaten ist fast immer ein Produktproblem, kein Change-Management-Problem." /} {% definition term="Cost-per-Resolved-Task" description="Die totalen Kosten (Lizenz, Token, Review, Schulung) pro erfolgreich abgeschlossener Aufgabe. Wer diese Kennzahl misst, hat eine direkte Vergleichbarkeit zu klassischer Software und zur menschlichen Bearbeitung. Wer sie nicht misst, hat nur eine Gesamtkostenrechnung ohne Aussage." /} {% definition term="Break-Even-Quartal" description="Das Quartal, in dem die kumulierten Einsparungen die kumulierten Investitionen übersteigen. Wer das Break-Even-Quartal bei Planung festlegt, sollte drei Quartale Verzögerung einkalkulieren, weil die ersten beiden Quartale fast immer unter Annahmen laufen, die in der Praxis nicht stimmen." /} {% definition term="Vorstands-Reporting" description="Die monatliche oder quartalsweise Berichterstattung an den Vorstand über den Stand einer KI-Investition. Wer hier nur Lizenzkosten reportet, hat eine Diskussion über Kosten. Wer Time-to-Value reportet, hat eine Diskussion über Wertschöpfung." /} ## Die zwei Lager, die sich nicht verstehen In den meisten Unternehmen, die ich in den letzten Monaten gesehen habe, gibt es zwei Lager, die über KI reden, ohne voneinander zu wissen. Das eine Lager ist das Engineering, das redet über Modelle, Pipelines, Drift und Token-Kosten. Das andere Lager ist das Finance, das redet über Investition, Amortisation und Vorstandsbericht. Beide reden über dasselbe Programm, beide haben Recht, und beide verstehen einander nicht. Das Problem ist nicht die Sprache, sondern die Granularität. Engineering reportet Token-Kosten pro Quartal, Finance reportet Lizenzkosten pro Jahr. Beides sind Zahlen, aber keine davon beantwortet die Frage, die der Vorstand stellt: bekommen wir das Geld zurück, das wir investiert haben? Die Antwort auf diese Frage ist eine eigene Disziplin. Sie heisst im einfachsten Fall **Value-Tracking**, im ausgebauten Fall **AI-Controlling**, und sie hat sechs Kennzahlen, die monatlich gemessen werden müssen. Wer keine dieser sechs Kennzahlen hat, sollte mit dem Programm nicht in den Vorstand gehen, weil die Diskussion, die dann entsteht, eine Diskussion über Glauben ist, nicht über Zahlen. ## Sechs Kennzahlen, die im Vorstand zählen ### Kennzahl eins: Adoption-Rate Die Adoption-Rate misst, wie viele der lizenzierten Nutzer das Produkt tatsächlich verwenden. Eine Adoption-Rate unter 20 Prozent nach drei Monaten ist fast immer ein Symptom dafür, dass das Produkt nicht das tut, was die Nutzer brauchen. Wer an dieser Stelle mit Change-Management argumentiert, hat das Problem verschoben, nicht gelöst. Wer die Adoption-Rate misst und unter 20 Prozent reagiert, hat die Chance, das Produkt anzupassen, bevor es zu spät ist. In der Praxis liegt die gesunde Adoption-Rate nach drei Monaten zwischen 40 und 60 Prozent. Wer darüber liegt, hat ein Produkt, das im Workflow gebraucht wird. Wer darunter liegt, hat ein Produkt, das im Probier-Modus steckt. ### Kennzahl zwei: Median-Usage-pro-User Die Median-Usage misst, wie viel ein typischer Nutzer das Produkt pro Woche verwendet. Diese Zahl trennt Power-User von Gelegenheitsnutzern, und sie ist die Grundlage für jede Folgekalkulation. Wer Token-Kosten pro Nutzer prognostiziert, ohne die Median-Usage zu kennen, prognostiziert aus dem Mittelwert und irrt systematisch. In den Projekten, die ich gesehen habe, schwankt die Median-Usage zwischen drei und zwölf Sitzungen pro Woche, je nach Use-Case. Wer in einem Use-Case eine Median-Usage von eins pro Woche misst, hat ein Produkt, das nicht in den Workflow integriert ist, sondern daneben liegt. ### Kennzahl drei: Cost-per-Resolved-Task Diese Kennzahl ist die direkte Brücke zwischen Technik und Finance. Sie setzt die totalen Kosten eines Use-Cases ins Verhältnis zur Anzahl der gelösten Aufgaben. Wer diese Kennzahl hat, kann beantworten, ob ein Use-Case günstiger ist als die menschliche Bearbeitung, die er ersetzt. Die ehrliche Rechnung in den meisten Use-Cases, die ich gesehen habe, zeigt, dass KI die menschliche Bearbeitung um den Faktor 3 bis 10 günstiger macht, wenn der Use-Case gut gewählt ist. Wer aber Use-Cases wählt, die nicht gut passen, hat eine Cost-per-Resolved-Task, die teurer ist als die menschliche Bearbeitung, und dann ist KI kein Effizienzgewinn, sondern ein Effizienzverlust. ### Kennzahl vier: Substitution-Rate Die Substitution-Rate misst, wie viel menschliche Arbeit durch KI ersetzt wird. Hier liegt der häufigste Fehler in der KI-ROI-Diskussion. Wer sagt, KI ersetzt 50 Prozent der Arbeit, hat in den meisten Fällen 50 Prozent der Aufgaben gemessen, nicht 50 Prozent der Stunden. Aufgaben sind binär, Stunden nicht. Wer eine Stunde Doku-Pflege durch 15 Minuten KI plus 10 Minuten Review ersetzt, hat eine Substitution-Rate von 58 Prozent in Minuten, nicht in Aufgaben. Wer das nicht trennt, übersieht den Review-Aufwand, der durch KI nicht wegfällt. In der Praxis liegt die echte Substitution-Rate, gemessen in Stunden, zwischen 20 und 45 Prozent. Wer 60 Prozent oder mehr verspricht, hat in den seltensten Fällen Recht, und wer 60 Prozent verspricht und im Vorstand nicht liefert, hat das Programm in der nächsten Budgetrunde nicht mehr. ### Kennzahl fünf: Time-to-First-Value Time-to-First-Value misst, wie schnell ein Nutzer vom ersten Login zum ersten messbaren Ergebnis kommt. Diese Kennzahl ist eng mit der Adoption-Rate verwandt, aber sie misst etwas anderes: nicht ob das Produkt benutzt wird, sondern ob es innerhalb des ersten Tages etwas liefert, das den Nutzer überzeugt. Eine Time-to-First-Value über einer Stunde ist fast immer ein Zeichen dafür, dass die Onboarding-Strecke zu lang ist. Wer in dieser Kennzahl über einer Stunde liegt, hat ein Produkt, das die meisten Nutzer in der Probierphase verliert. ### Kennzahl sechs: Break-Even-Quartal Das Break-Even-Quartal ist die Summe aller vorherigen Kennzahlen, ausgedrückt in einem Datum. Wer im Planungsdokument Break-Even-Quartal Q3/2026 sagt, sollte bei der ersten Vorlage Q4/2027 sagen, weil die Verzögerung zwischen Plan und Realität in den meisten Programmen zwischen zwei und vier Quartalen liegt. {% questionAnswer question="Wann ist ein Pilot erfolgreich?" answer="Wenn nach zwei Quartalen drei der sechs Kennzahlen im Zielkorridor liegen. Wer nach zwei Quartalen nur Lizenz-Kosten und keine der sechs Kennzahlen hat, hat einen Pilot, der Daten produziert, aber keinen Wert." /} {% bar-horizontal caption="Break-Even-Quartale aus zwölf KI-Programmen. Die Verteilung ist das, was den Planungs-Puffer definiert — nicht der Mittelwert allein." data="{\"items\":[{\"label\":\"Pilot 1\",\"value\":3},{\"label\":\"Pilot 2\",\"value\":5},{\"label\":\"Pilot 3\",\"value\":4},{\"label\":\"Pilot 4\",\"value\":7},{\"label\":\"Pilot 5\",\"value\":4},{\"label\":\"Pilot 6\",\"value\":6},{\"label\":\"Pilot 7\",\"value\":5},{\"label\":\"Pilot 8\",\"value\":8},{\"label\":\"Pilot 9\",\"value\":4},{\"label\":\"Pilot 10\",\"value\":6},{\"label\":\"Pilot 11\",\"value\":5},{\"label\":\"Pilot 12\",\"value\":7}],\"max\":8}" /} ## Die drei Verzögerungen, die jeder Plan unterschätzt Wer ein KI-Programm plant, unterschätzt drei Verzögerungen, die zwischen Plan und Realität liegen. Wer sie kennt, plant mit Puffer. Wer sie nicht kennt, plant mit Überzeugung und landet im Vorstand mit einer Rechtfertigung. **Verzögerung eins: Onboarding.** Die meisten Nutzer brauchen zwischen vier und acht Wochen, bis sie ein neues KI-Werkzeug produktiv nutzen. Wer ein Programm mit einer Onboarding-Phase von zwei Wochen plant, hat nach acht Wochen ein Programm, in dem 60 Prozent der Nutzer das Werkzeug noch nicht produktiv einsetzen. Diese Verzögerung ist konstant, sie beträgt in fast allen Programmen zwischen einem und zwei Monaten. **Verzögerung zwei: Use-Case-Spezifikation.** Die ersten Use-Cases sind selten die Use-Cases, die nach sechs Monaten den Wert produzieren. Wer ein Programm mit den ersten drei Use-Cases aus dem Business-Case fährt, hat nach sechs Monaten typischerweise zwei Use-Cases, die ausgetauscht werden müssen. Diese Verzögerung ist nicht konstant, sie beträgt zwischen einem und drei Monaten, je nach Use-Case-Reife. **Verzögerung drei: Review-Disziplin.** KI-Output muss reviewt werden, und die Review-Disziplin braucht Zeit, bis sie sitzt. Wer ein Programm ohne Review-Disziplin startet, hat nach drei Monaten Outputs, die nicht besser werden. Wer eine Review-Disziplin von Anfang an einbaut, hat nach drei Monaten Outputs, die sich mit jeder Iteration verbessern. Die Verzögerung der Review-Disziplin beträgt zwischen vier und acht Wochen. ## Wer im Vorstand steht Wer eine KI-Investition im Vorstand verteidigt, muss eine ehrliche Antwort auf drei Fragen haben. Wer auf eine dieser Fragen keine Antwort hat, sollte das Programm nicht vorstellen. **Frage eins: Wann sehen wir das Geld zurück?** Die Antwort ist das Break-Even-Quartal, plus ein Puffer von zwei Quartalen, plus eine ehrliche Angabe der Annahmen. Wer hier mit einem einzigen Datum antwortet, hat den Plan nicht verstanden. **Frage zwei: Was passiert, wenn das Programm scheitert?** Die Antwort ist die Exit-Strategie, die im Vertrag steht (siehe [KI-Beschaffung ohne Lock-in](/posts/beschaffung-und-lock-in/)), plus die Möglichkeit, den Use-Case zu wechseln, ohne die Architektur neu zu bauen. Wer hier keine Exit-Strategie hat, hat ein Programm, das bei Misserfolg neu verhandelt werden muss. **Frage drei: Wer verantwortet das Ergebnis?** Die Antwort ist eine Person, nicht ein Komitee. Die Person hat einen Titel, ein Mandat und ein Incentive, das an das Ergebnis gekoppelt ist, nicht an die Aktivität. Wer das Ergebnis auf ein Komitee verteilt, hat am Ende niemanden, der verantwortlich ist. ## Was am Ende zählt Eine KI-Investition rechnet sich, wenn sechs Kennzahlen gemessen werden, drei Verzögerungen eingeplant sind und drei Antworten im Vorstand vorbereitet sind. Wer das tut, hat ein Programm, das in der nächsten Budgetrunde weiterläuft. Wer es nicht tut, hat ein Programm, das in der nächsten Budgetrunde als gescheitertes Pilotprojekt endet. Die sechs Kennzahlen sind nicht das Ziel, sondern das Mittel. Das Ziel ist eine ehrliche Diskussion im Vorstand, die auf Zahlen beruht, nicht auf Überzeugung. Wer die Diskussion führt, gewinnt das nächste Budget. Wer die Diskussion verliert, hat im dritten Jahr kein Programm mehr. ## Weiterführend - **[McKinsey: The State of AI in 2025](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai)**, wer die Verbreitung von KI-Investitionen im Markt benchmarken will, findet hier die Zahlen, mit denen sich eigene Programme vergleichen lassen. - **[Bessemer Venture Partners: State of the Cloud](https://www.bvp.com/atlas/state-of-the-cloud-2024)**, wer SaaS-Kennzahlen mit KI-Kennzahlen vergleichen will, findet hier den Benchmark, an dem sich jede eigene Cost-per-Resolved-Task messen lassen muss. - **[Lenny's Newsletter: Measuring Product-Led Growth](https://www.lennysnewsletter.com/)**, wer Adoption-Rate in produktgetriebenen Programmen verstehen will, findet hier die Diskussion, die in vielen KI-Programmen noch fehlt.