Ein Delivery-Modell ohne Steuerung neu aufbauen und ~43 % der jährlichen Delivery-Kosten zurückgewinnen

1. Das modellierte Gesamtrisiko über sechs Kategorien kam fast an die Delivery-Kosten eines ganzen Jahres heran.
2. Rund 39 % der gesamten Delivery-Kosten waren mit hoher Sicherheit vermeidbare Verschwendung, belegt durch die eigenen Delivery-Daten des Kunden.
3. Führungskräfte auf Kundenseite verbrachten ~240 Stunden pro Monat damit, die Delivery am Laufen zu halten, statt das Unternehmen zu führen.
4. 32,5 % der gelieferten Arbeit war Nacharbeit, die noch einmal zu vollen Delivery-Kosten erledigt wurde.

Die Lücke betraf das ganze Unternehmen zugleich: einen strategischen Pivot, ein Betriebsmodell und eine Codebasis. Deshalb lief die Diagnose auf drei Ebenen gleichzeitig.

• Strategie

  Was kostet die Lücke in der Delivery?

  Der Pivot zum Enterprise-Produkt setzt eine glaubwürdige Delivery voraus, die das heutige Modell noch nicht vorweisen kann. Deshalb hat die Diagnose die Lücke zuerst in Geld beziffert. Sie hat den Wandel vom Beratungs- zum Produktgeschäft mit den Delivery-Fähigkeiten abgeglichen, auf die Enterprise-Käufer achten, die tatsächlichen Vollkosten der Delivery ermittelt statt nur der sichtbaren Teamkosten und belegte Verschwendung vom modellierten Risiko getrennt.

• Betrieb

  Wohin geht die Zeit wirklich?

  Die Delivery hing an Einzelnen, ohne Rhythmus und ohne Verantwortlichen. Die Koordination blieb deshalb an den Führungskräften des Kunden hängen. Die Diagnose wies ~240 Stunden pro Monat nach, die diese Führungskräfte darauf verwendeten, die Delivery am Laufen zu halten. Sie bezifferte die Nacharbeit auf 32,5 % der gelieferten Arbeit und stellte fest, dass Kanban ohne festen Rhythmus lief und es keinen verbindlichen Release-Plan gab.

• Technologie

  Kann das System sicher ausliefern?

  Code ging ohne Review und ohne Quality Gates raus, und die Architektur konnte keinen zweiten Enterprise-Kunden aufnehmen. Die Diagnose fand ~50 % Merge Requests ohne Peer Review, einen einzigen fest codierten Mandanten, der das Onboarding weiterer Mandanten blockierte, sowie einen ungeprüften Teams-Bot und ungeprüfte KI-Module, dazu keine stabile DEV-/Demo-Umgebung.

• Belegte Verschwendung steht vorn, nicht die größte Zahl.

  Der Business Case hätte mit dem vollen modellierten Risiko beginnen können. Er beginnt stattdessen mit den ~39 % der Kosten, die aus den eigenen Daten des Kunden stammen. So stützt sich die Entscheidung auf eine Zahl, die sich nicht kleinreden lässt.

• Die überlastete Rolle aufteilen, statt einen CTO einzustellen.

  Ein CTO in Vollzeit wurde mit einem sechsstelligen Jahresgehalt kalkuliert und verworfen. Er wäre für Budget und Unternehmensphase zu viel des Guten, seine Einstellung dauert 60 bis über 90 Tage, und die tägliche Delivery würde er trotzdem nicht steuern. Drei klar definierte Rollen beheben das eigentliche Problem: fehlende Verantwortung, nicht fehlende Seniorität.

• Erst das Betriebsmodell, dann Mandantenfähigkeit und Zertifizierung.

  SOC 2, ISO 27001 und ein mandantenfähiger Neubau sind echte Blocker. Wer sie zuerst angeht, gibt aber Geld aus, bevor man sich darauf verlassen kann, dass die Delivery sie auch umsetzt. Der Plan nimmt sie deshalb erst in Angriff, wenn ein fester Rhythmus läuft und Reviews den gesamten Code abdecken.

• Erst beweisen, dass die Messung trägt, dann den vollen Auftrag anfragen.

  Die Einsparung bei den Meetings stammt aus einer Retrospektive und ist bereits erzielt, nicht nur hochgerechnet. Sie zeigt, dass das Tracking funktioniert, bevor sich der Kunde zu mehr verpflichtet.