Null Projektausfälle seit 2007 – die Engineering-Regeln dahinter
Ich habe Software Tailor 2006 gegründet. Neunzehn Jahre später hat das Unternehmen vier deutlich verschiedene Konjunkturzyklen, sechs Fortune-Global-500-Kunden aus den Branchen Pharma, Finanzen, Behörden, Recht, Verteidigung und Energie sowie null Projektausfälle seit 2007 hinter sich gebracht. Diese letzte Zahl ist die, nach der Investoren und Einkaufsprüfer am häufigsten fragen, und sie ist die einzige, die einer Erklärung bedarf. Hier sind die vier Engineering-Regeln, die diese Bilanz halten.
Regel 1: Ein Liefermodell, keine Vermischung von Service und Produkt
Jedes Engagement von Software Tailor läuft nach demselben Liefermodell – eine eng gefasste Pilotphase, die funktionierende Software ausliefert, gefolgt von einer Erweiterung, die der Kunde auf Basis des Ausgelieferten zu finanzieren wählt (oder nicht). Wir betreiben keine separate „Services"-Praxis, die gegen Anforderungsdokumente liefert, und keine separate „Produkt"-Praxis, die gegen Roadmaps liefert. Beide würden konkurrieren; eine würde immer die andere quersubventionieren.
Das einzige Modell bedeutet, dass jede Ingenieurin weiß, wie „fertig" aussieht, bevor sie beginnt. Das ist die Voraussetzung dafür, nicht zu scheitern.
Regel 2: Disziplin in der Kundenkohorte – nur Kunden, für die wir liefern können
Unsere Kundenkohorte ist ausgewählt – nicht opportunistisch. Sechs Fortune-Global-500-Kunden in 19 Jahren sind keine langsame Vertriebspipeline; sie sind eine bewusste Auswahlhürde. Jeder Kunde, den wir aufnehmen, muss vor dem Kickoff drei Tests bestehen: Ihr Problem ist eines, das wir bereits gelöst haben; ihr interner Sponsor ist die Person, die die Software selbst nutzen wird (nicht eine Zwischenschicht); und ihre Hardware-/Datenumgebung erlaubt uns, ohne sechsmonatigen Einkaufsumweg auszuliefern.
Ein Kunde, der einen dieser Tests nicht besteht, wird zur Empfehlung an jemand anderen, nicht zum Projekt. Diese Regel kostet uns am häufigsten Umsatz. Sie ist auch diejenige mit null Ausnahmen über 19 Jahre.
Regel 3: Engineering-Disziplin, abgebildet auf ein anerkanntes Rahmenwerk
Lange bevor das KI-Risikomanagement sein eigenes Rahmenwerk hatte, passten die Engineering-Regeln, die ich für Software Tailor kodifiziert habe, mustergleich auf dieselbe Form: die Arbeit steuern, die Risiken kartieren, die Ergebnisse messen, die Änderungen managen. NIST AI RMF 1.0 [1] hat dieses Muster 2023 für KI formalisiert, und das Critical-Infrastructure-Profil vom April 2026 [1] hat es auf regulierte Branchen erweitert. Wenn man diese Dokumente liest, lässt sich unsere interne Disziplin sauber auf die vier Funktionen abbilden.
Was uns das gibt: Jedes Projekt ist Ende-zu-Ende gegen ein externes Rahmenwerk auditierbar, nicht nur gegen unsere eigenen Gewohnheiten. Wenn ein Einkaufsteam fragt, wie der Umfang der Pilotphase entschieden wird, ist die Antwort dieselbe Antwort, die NIST für Risikomanagement geben würde – und das Compliance-Team des Kunden hat dieses Vokabular bereits verinnerlicht.
Regel 4: Aufzeichenbar, wiederherstellbar, reproduzierbar
Die vierte Regel ist älter als das Audit-Trail-Vokabular, das wir heute für die AI Suite verwenden. Jedes Engagement von Software Tailor läuft in einem Zustand, in dem jede Entscheidung, jedes Artefakt, jede Version des Codes aus versionskontrollierten Eingaben rekonstruiert werden kann. Das ist im Software-Engineering generell nicht ungewöhnlich; ungewöhnlich ist, dass wir es auf das Projekt anwenden, nicht nur auf die Codebasis. Sprint-Entscheidungen, Scope-Änderungen, Kundenfreigaben – alles aufgezeichnet, alles wiederherstellbar.
Diese Disziplin ist der Grund, warum unser Ansatz der inhaltsfreien Audit-Logs für die AI Suite so ausgeliefert wurde, wie er ist. Das Audit-Eintrag-Muster ist dasselbe Muster, das wir bereits auf Projekte angewendet haben. Das Vokabular ist aus Compliance-Rahmenwerken entliehen; die Praxis ist aus der Art und Weise entliehen, wie wir ausliefern.
Was sich auf die AI Suite übertragen hat
Die Linie aus Local AI Suite + AI Admin Console — siehe Warum wir KI als installierbare Binärdateien ausliefern, nicht als Cloud-SaaS — ist dieselbe Engineering-Disziplin, angewendet auf eine Produktlinie statt auf ein kundenspezifisches Engagement. Dasselbe einheitliche Liefermodell (Desktop-Installer, die der Kunde in seiner eigenen Umgebung ausführt), dieselbe Kundenkohorten-Disziplin (regulierte Branchen mit klaren Datenresidenz-Beschränkungen), dieselbe Framework-Zuordnung (NIST AI RMF + EU-AI-Act-Betreiberpflichten), dieselbe aufzeichenbar-wiederherstellbar-reproduzierbare Audit-Haltung.
Null Projektausfälle seit 2007 ist kein Slogan. Es ist das Ergebnis einer kleinen Zahl von Regeln, ohne Ausnahme angewandt. Dieselben Regeln steuern jetzt, wie die AI Suite gebaut wird.
Quellen
- NIST. „AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. Abgerufen am 2026-07-15.
Verwandte Artikel
Testen Sie dieselbe Disziplin an einer realen Arbeitslast.
Die On-Premises-KI-Plattform ist auf denselben Regeln gebaut, die die Bilanz erzeugt haben — aufzeichenbar, wiederherstellbar, reproduzierbar, ausnahmslos angewendet. Stellen Sie sie an einer realen Arbeitslast in Ihrer eigenen Umgebung bereit und halten Sie sie an denselben Standard.