Bei der Preisverhandlung für ein maßgeschneidertes Softwareprojekt sind die Einheiten, die von beiden Parteien am häufigsten abgestimmt werden,„Mensch und Himmel“: Wie viele Ingenieure, wie viele Tage, welcher Einheitspreis. Dieses Modell funktioniert nur, wenn die Anforderungen stabil und die Liefergrenzen klar definiert sind; sobald sich die Vor-Ort‑Regeln häufig ändern, die KI‑Tools die Codier‑Effizienz deutlich steigern, die Auftraggeberseite jedoch weiterhin nach dem Prinzip der „Menschenaufstockung“ abnimmt, kommt es zwangsläufig zu Konflikten – die Auftragnehmer sehen eine Ausuferung der Anforderungen, während die Auftraggeber das Gefühl haben: „Es wurden zwar nicht weniger Leute hinzugefügt, aber es ist trotzdem nichts dazugekommen.“
Politische Signale: Vom Verkauf von Köpfen zum Verkauf von Ergebnissen
Im September 2026 veröffentlichte das Ministerium für Industrie und Informationstechnologie den „Aktionsplan zur speziellen Initiative ‚Künstliche Intelligenz + Software‘“, in dem mehrfach die Förderung des Wandels der Softwareproduktionsmodelle sowie die Entwicklung von „Model-as-a-Service“ und „Agent-as-a-Service“ erwähnt wird. Zudem wird klar festgelegt, dass bis 2028 in Schlüsselbranchen Benchmark-Anwendungen für Agentensoftware geschaffen werden sollen. Das Dokument lehnt maßgeschneiderte Entwicklungen nicht ab, vermittelt jedoch eine klare Ausrichtung:Bei der Bewertung des Softwarewerts kommt es zunehmend auf die konkrete Effektivität an, statt nur darauf zu achten, wie viele Mann-Tage investiert wurden.。
Für Unternehmen, die derzeit ERP-, MES-, CRM- oder branchenspezifische Management‑Systeme einsetzen, bedeutet dies: Wenn im Vertrag weiterhin lediglich „XX Personen × XX Tage“ festgehalten wird, droht nach der Inbetriebnahme leicht das Problem, dass „der Code fertig ist, aber die Geschäftsprozesse nicht genutzt werden können“. Eine nachhaltigere Formulierung besteht darin, die Lieferung in … aufzuteilen.Abnahmefähige Geschäftsergebnisse。
Geschäftslogik: Meilensteine sind detaillierter als Personentage.
Das Projekt wurde von „Stufenzahlung“ auf „Meilensteinzahlung“ umgestellt; jeder Meilenstein muss gleichzeitig vier Voraussetzungen erfüllen:
- Geschäftsszenario: Wer nutzt es und welche Vorgänge werden damit abgewickelt (z. B. „Lagermitarbeiter scannen beim Wareneingang“ statt „Abschluss des Wareneingangsmoduls“).
- Datenkonsistenz: Welche Stammdaten, Statusfelder und Berechtigungsbereiche sind betroffen, und wie lautet die Stichprobenregel?
- Abnahmeskript: Anhand der vorgegebenen Testdaten, welche Prozesse werden durchlaufen und welche Dokumente oder Berichte werden erstellt.
- Ausnahmeverarbeitung: Wie wird das System im Falle eines Fehlers benachrichtigt, wer ist berechtigt, Änderungen vorzunehmen, und werden Spuren hinterlassen?
Meilensteine sollten nicht überschreiten2–4 WochenEin; zu lang und es würde wieder in die „Black-Box-Entwicklung“ zurückfallen. Typisches Aufteilungsbeispiel: Stammdaten und Berechtigungen → geschlossener Kreislauf der Kernbelege → Berichte und Abstimmungen → Schnittstellen und Live-Umschaltung.
Designlogik: Umfang, Änderungen und „intelligente Unterstützung“ werden in den Vertrag aufgenommen.
KI-gestütztes Codieren, automatische Generierung von Testfällen und intelligente Dokumentenergänzung werden den Personentageaufwand für dieselbe Funktion verändern, aberDie Geschäftskomplexität ändert sich nicht automatisch.. Im Vertrag und in der Anforderungsspezifikation wird empfohlen, eine separate Spalte einzufügen:
- Bereichsbaseline (Baseline): Funktionsliste + Liste der nicht im Umfang enthaltenen Punkte (Out of Scope); Änderungen müssen über eine Änderungsanforderung abgewickelt werden.
- Änderung der Preisgestaltungsregeln: Neue Meilensteine werden nach dem „Szenario + Abnahmeskript“ bewertet, statt die Arbeitsstunden nachträglich hinzuzufügen.
- Intelligente Unterstützungsgrenze: Welche Prozessschritte können durch KI effizienter gestaltet werden (Code-Generierung, Dokumentenentwürfe), und welche müssen zwingend von Hand unterzeichnet werden (Sicherheit, Compliance, externe Verpflichtungen)?
- Wissensablagerung zugehörig: Wer ist im Besitz der Prozessdokumentation, Konfigurationen und Skripte, um einen Betriebs‑ und Wartungsbruch nach der Übergabe zu vermeiden?
Entwicklung und Umsetzung: Automatisierung und Beobachtbarkeit der Abnahmeprüfung
Damit „ergebnisorientiertes Handeln“ umsetzbar wird, müssen auf der technischen Seite drei Dinge berücksichtigt werden:
- Eingang der Testfälle zur Abnahme: Jeder Meilenstein entspricht einer Gruppe automatisierter oder halbautomatisierter Testfälle, die wiederholt ausgeführt werden können.
- Umwelt- und Datenisolierung: Die UAT-Umgebungsdaten können zurückgesetzt werden, um zu vermeiden, dass das System „nur in der Demo-Umgebung funktioniert“.
- Beobachtbares Protokoll: Bei kritischen Vorgängen gibt es Auditprotokolle, sodass im Streitfall nachvollziehbar ist, wer was geändert hat.
Wenn das Projekt einen Agenten oder eine Regelengine enthält, sollte die Abnahme um folgende Punkte erweitert werden:Stichprobenprüfmechanismus: Zufällig eingebene Grenzfälle werden getestet, um zu prüfen, ob die Ablehnung der Antwort, die Weiterleitung an den Kundendienst sowie die Rechte‑ und Berechtigungsfilter gemäß dem Design funktionieren – und nicht nur, ob „gechattet werden kann“.
Drei häufige Streitigkeiten und deren Prävention
Streitpunkt 1: „Die Funktionen sind alle implementiert, warum wird das System von den Geschäftsbereichen nicht genutzt?“—— Prävention: Die Meilensteine sind an die jeweiligen Stellen und deren Arbeitsabläufe gebunden; bei der Abnahme erfolgt eine Vor-Ort‑Durchlaufkontrolle, wobei nicht nur die PPT‑Präsentation gezeigt wird.
Streitpunkt zwei: „Warum soll für eine kleine Anforderung extra bezahlt werden?“——Prävention: In der Änderungsanforderung sind die betroffenen Meilensteine, Skripte und der Zeitplan klar anzugeben; erst nach Unterzeichnung durch beide Parteien darf mit der Entwicklung begonnen werden.
Streitpunkt drei: „AI hat die Effizienz gesteigert – können wir die Personentage reduzieren?“——Prävention: Verträge unterscheiden zwischen „Realisierungskosten“ und „Geschäftskomplexität“; Effizienzgewinne können sich im Gesamtpreis oder im Zeitraum niederschlagen, jedoch dürfen die Abnahmekriterien nicht abgesenkt werden.
Pilotvorschlag: Beginnen Sie mit einem geschlossenen Modul.
Es ist nicht nötig, darauf zu warten, dass das gesamte System den Vertrag neu schreibt. Wählen Sie eines aus.2–3 Wochen können geschlossen werdender Module (wie Warenein- und -ausgang, Arbeitsauftragsabrechnung, Kostenfreigabe) mit dem neuen Vorlage‑Zusatzvertrag: Liste Szenarien, Skripte, Ausnahmen und Zahlungs‑Knotenpunkte. Nach erfolgreicher Durchführung wird es auf das gesamte Projekt ausgerollt. Die Erfolgsmessung erfolgt anhand vonReduziert der Änderungsauftrag die Zeit für Streitigkeiten?、Ist die Erfolgsquote beim UAT auf den ersten Versuch gestiegen?, und nicht danach, wie viele Personentage die andere Partei zu wenig gemeldet hat.
Der Mensch wird nicht über Nacht verschwinden, doch er wandelt sich von der „einzigen Einheit zur Preisfestlegung“ hin zur „Referenz für Kostenschätzungen“. Meilensteine und Abnahmeskripte in den Vertrag zu integrieren, ist die grundlegende Fähigkeit, damit maßgeschneiderte Software auch im Kontext von „Künstlicher Intelligenz + Software“ vertrauenswürdige Ergebnisse liefern kann.
In Zusammenarbeit mit dem Festpreis und den agilen Iterationen
Die Meilensteinabnahme schließt Agilität nicht aus: Jeder Sprint kann weiterhin ein demonstrierbares Inkrement liefern, aberZahlung und formelle AbnahmeAn größeren Meilensteinen angehängt. Bei Festpreisverträgen ist insbesondere der „Umfangsfrierpunkt“ klar festzulegen – nach welcher Abstimmung zusätzliche Anforderungen über Änderungsaufträge abgewickelt werden, um mündliche Funktionsergänzungen zu vermeiden. Für Module mit intelligenten Agenten empfiehlt sich eine separate Meilensteinabnahme nach dem Kriterium „Regelversion + Stichprobenbestätigungsrate“, die nicht pauschal mit der Gesamtinbetriebnahme des Systems verbunden werden sollte.
Branchendaten zeigen, dass etwa … % der Softwareprojekte scheitern.Ein DrittelDies liegt nicht an der technischen Umsetzung selbst, sondern an unklaren Anforderungen und Abnahmekriterien. Es ist weitaus sinnvoller, zunächst festzulegen, was „als abgeschlossen gilt“, als darüber zu streiten, wie viele Programmierer durch KI ersetzt wurden. Bei der nächsten Projektbewertung sollte man zunächst fragen: Wenn morgen das gesamte Team von XYN Tech in den Urlaub geht, könnten wir dann anhand eines Skripts beurteilen, ob der aktuelle Meilenstein erreicht wurde? Kann man diese Frage nicht beantworten, deutet dies darauf hin, dass die Abnahmekriterien noch nicht klar formuliert sind.