Noch ein Projekt-KI-Tool? Was der CIO vor der Freigabe entscheiden sollte

Vor dem Kauf eines zusätzlichen Projekt-KI-Tools sollte der CIO klären, welche konkrete Entscheidung bisher zu spät oder auf widersprüchlicher Basis fällt. Anschließend sind Datenherkunft, gemeinsame Definitionen, Verantwortlichkeiten und Aktualität für genau diese Entscheidung zu prüfen. Erst dann lassen sich drei Optionen seriös vergleichen: ein isoliertes Spezialtool einsetzen, eine begrenzte gemeinsame Steuerungsdatenbasis schaffen oder ein ungeeignetes Bestandssystem ersetzen. Entscheidend sind nicht die Anzahl der Dashboards oder ein demonstrierter KI-Output, sondern die Verlässlichkeit der Information und die Fähigkeit, daraus eine Handlung abzuleiten. Der folgende Fünf-Gate-Test macht die Freigabe prüfbar.

In einem am 13. Oktober 2026 veröffentlichten Beitrag beschreibt McKinsey die digitale und KI-gestützte Steuerung großer Investitionsprojekte. Der Kern der Beratungsposition: Zusätzliche Einzellösungen entfalten wenig Wert, solange Daten und Entscheidungen aus Engineering, Procurement, Ausführung und Controlling nicht zusammenwirken. McKinsey weist insbesondere auf getrennte Tools, verspätete Contractor-Meldungen und fehlende Verbindungen zwischen Risiko, Termin und wirtschaftlicher Wirkung hin. Die Beratung empfiehlt, den Einstieg an wenigen Entscheidungen mit hohem Hebel auszurichten – nicht an der bloßen Einführung weiterer Technologie.[1]

Die Evidenzgrenze ist wichtig: McKinseys Beispiele betreffen vor allem große Bau- und Infrastrukturprogramme. Sie belegen weder, dass jedes IT- oder Marketingprojekt dieselbe Lage hat, noch einen garantierten Nutzen für ein bestimmtes Softwareprodukt. Die zugrunde liegende Entscheidungslogik lässt sich jedoch als Prüfmodell für Unternehmen mit mehreren externen Projektpartnern nutzen.

Eine zweite, unabhängige Perspektive kommt aus der britischen öffentlichen Projektpraxis: In einem Protokoll der Data Standards Authority vom März 2025 wird beschrieben, dass inkonsistente, schlecht zugängliche und qualitativ schwache Projektdaten die Aufsicht und das Steuern großer Vorhaben erschweren. Der dort diskutierte Project Data Standard soll gemeinsame Attribute, Formate und Verantwortlichkeiten schaffen. Er ist ein Vorgehen für britische Regierungsprojekte, keine verbindliche Norm für private Unternehmen in Deutschland.[2]

Für den CIO ergibt sich eine präzise Frage: Brauchen wir wirklich eine neue Anwendung – oder zuerst gemeinsame Definitionen für die Daten, die über unsere Projekt- und Dienstleisterlandschaft verteilt sind?

„Reporting mit KI verbessern“ ist keine ausreichende Antwort. Besser ist eine Entscheidungsformulierung wie: „Können wir vor dem nächsten Steering Committee erkennen, ob die Leistung von Supplier A den Start von Supplier B gefährdet – und wer die Eskalation verantwortet?“ Oder: „Sind die noch offenen externen Leistungszusagen bereits im Forecast enthalten?“

Fehlt diese Frage, droht ein weiteres Reporting-Werkzeug, dessen Ergebnisse zwar lesbar, aber nicht entscheidungsfähig sind. Als Ergebnis von Gate 1 müssen Entscheidung, verantwortliche Rolle und spätester sinnvoller Entscheidungszeitpunkt feststehen.

Für ein Multi-Supplier-Projekt können etwa fünf Informationen genügen: genehmigter Scope, tatsächlich erbrachte Leistung, offene Verpflichtung, Terminabhängigkeit und verantwortliche Stelle. Diese Informationen können in Verträgen, ERP-Systemen, Planungstools, Lieferantenberichten und Fachbereichstabellen liegen.

Der CIO sollte für jedes entscheidungsrelevante Feld festhalten: Quellsystem, fachlichen Owner, Definition, Zeitstempel und Abgleichregel. Eine gemeinsame Datenbasis bedeutet nicht, sämtliche Daten zentral neu zu erfassen. Sie bedeutet zunächst, dass dieselbe Managementfrage nicht mit widersprüchlichen Definitionen beantwortet wird.

Wenn ein externer Partner seine Termin- oder Leistungsstände nicht in der benötigten Qualität liefern kann oder darf, löst ein zusätzliches KI-Tool dieses Hindernis nicht. Zu prüfen sind der tatsächliche Datenzugang, vertragliche Rechte, Lieferfrequenz, Definitionen sowie Aufwand und Zustimmung der Partner. Nicht jede Information muss automatisiert aus einem Fremdsystem kommen; in einem kleinen Pilotprojekt können definierte und geprüfte Exporte ausreichen.

Ergebnis dieses Gates ist ein umsetzbarer Datenaustausch für die ausgewählte Entscheidung, nicht die Zusage einer technisch perfekten Vollintegration.

Ein Test mit zwei Projekten und wenigen Quellen kann die Antwort zeigen. Lassen sich die wichtigsten Abweichungen mit einer gemeinsamen Definition, einem klaren Verantwortlichen und einer einfachen Konsolidierung zuverlässig erkennen, ist ein neuer KI-Baustein möglicherweise zunächst überflüssig.

Umgekehrt kann eine spezialisierte Lösung sinnvoll sein, wenn die Datenbasis steht, die Entscheidungslogik klar ist und der Nutzen gerade aus einer Fähigkeit entsteht, die mit vorhandenem Aufwand nicht vertretbar bereitgestellt werden kann. Nicht jeder Medienbruch verlangt einen Plattformwechsel – und nicht jedes Spezialproblem verlangt eine neue Managementebene.

Vergleichen Sie nicht nur Lizenzpreise. Prüfen Sie Einführungs- und Wartungskosten, externe Datenaufbereitung, die verbleibende interne Abstimmung, Migrationsrisiken, Datensicherheit und die Frage, wie sich die Lösung später wieder ablösen lässt. Gleichzeitig muss eine belastbare Verbesserung für die definierte Managemententscheidung sichtbar sein.

| Option | Wann sie sinnvoll sein kann | Wichtigster Nachteil | Mindestnachweis vor Freigabe | |---|---|---|---| | A: Gezielt ein Spezialtool ergänzen | Quellen und Definitionen sind bereits konsistent; eine klar umrissene Auswertung fehlt. | Weiterer Anbieter, Kosten und möglicherweise neue Datenkopien. | Reale Entscheidung mit verifizierten Eingangsdaten erfolgreich durchgespielt. | | B: Zunächst entscheidungsrelevante Daten verbinden | Informationen liegen verteilt; das operative Projektwerkzeug soll bestehen bleiben. | Abstimmung von Datenmodellen, Verantwortlichkeiten und Zugriffen kostet Zeit. | Zwei kritische Projekt-/Supplier-Fragen werden mit gemeinsamen Definitionen nachvollziehbar beantwortet. | | C: Ein ungeeignetes Kernsystem ablösen | Das Bestandssystem lässt sich technisch, vertraglich oder wirtschaftlich nicht tragfähig einbinden. | Hohe Übergangs- und Migrationsrisiken; Aufwand bei allen Beteiligten. | Beleg, warum A und B das Kernproblem nicht lösen und der Wechsel insgesamt vertretbar ist. |

Es gibt keine generell richtige Reihenfolge. In einem stabilen Bestandssystem kann die kleine Integration wirtschaftlich sein. Bei fehlender Datenportabilität oder nicht unterstützten Altsystemen kann eine Ablösung trotz höherem Anfangsaufwand besser begründet sein. Umgekehrt ist ein Toolkauf vertretbar, wenn er eine bereits definierte und ausreichend dokumentierte Managemententscheidung tatsächlich verbessert.

Ausdrücklich fiktives Planungsszenario. Die Zahlen sind keine Ramp7-Kundenwerte, Marktpreise oder Benchmarks. Sie dienen nur dazu, Entscheidungskosten sauber zu trennen. Betrachtungszeitraum: erstes Jahr; Beträge ohne steuerliche Bewertung.

Ein Unternehmen steuert ein Portfolio mit drei externen Dienstleistern. Zur Auswahl stehen ein isoliertes zusätzliches Cockpit (Option A) und eine begrenzte Verbindung der für den Review nötigen Daten (Option B).

| Größe im ersten Jahr | A: Spezialtool | B: Datenverbindung | |---|---:|---:| | Lizenz und Einrichtung beziehungsweise externe Umsetzung | 80.000 € | 95.000 € | | Externer laufender Abgleich und Support | 25.000 € | 30.000 € | | Geplante zahlungswirksame Ausgaben | 105.000 € | 125.000 € | | Kalkulatorischer Wert interner Projekt- und IT-Kapazität | 10.000 € | 20.000 € | | Rechnerischer Gesamtressourceneinsatz | 115.000 € | 145.000 € |

Option A benötigt in diesem fiktiven ersten Jahr 20.000 € weniger Zahlungsbudget und 30.000 € weniger Ressourcenwert. Daraus folgt noch keine Freigabeempfehlung: Das Tool kann bei ungeklärten Definitionskonflikten ein zusätzliches Dashboard liefern, ohne die Managementfrage zu lösen. Ebenso kann die Datenverbindung teurer sein, ohne ausreichende Wirkung zu erzielen.

Die nächste Prüfung muss deshalb den Nutzen sichtbar machen: Welche der beiden Lösungen kann in einem Test dieselbe konkrete Budget-, Termin- oder Supplier-Entscheidung mit nachvollziehbarer Datenherkunft treffen helfen? Erst wenn der Unterschied in der Entscheidungsqualität und den Folgewirkungen geprüft ist, sollte eine Mehrinvestition wirtschaftlich begründet werden.

Die 10.000 beziehungsweise 20.000 € für interne Kapazität sind ein kalkulatorischer Ressourcenwert, keine automatisch realisierbare Einsparung und kein zusätzlicher Cash-Abfluss. Auch vermiedene Abstimmungsstunden werden erst zahlungswirksam, wenn beispielsweise externe Rechnungen oder tatsächlich geplante Neueinstellungen entsprechend entfallen.

Ein belastbarer Freigabebeschluss braucht keinen 80-seitigen Transformationsplan. Für den ersten begrenzten Schritt reichen sieben konkrete Felder:

Damit wird nicht die Technologie zur Hauptfigur, sondern die Entscheidung, die sie unterstützen soll. Auch ein negativer Pilot kann wertvoll sein: Er zeigt früh, ob eine Daten- oder Verantwortlichkeitslücke zuerst gelöst werden muss.

Zwischen operativen Teamwerkzeugen, Verträgen, Einkaufsdaten und Managemententscheidungen fehlt oft ein gemeinsamer Kontext. Aus Sicht von Ramp7 lautet die übergeordnete Steuerungsfrage deshalb:

Welcher Supplier erbringt welche Leistung in welchem Projekt, welche Kosten und Terminfolgen entstehen daraus – und wer muss wann entscheiden?

Welche technische Umsetzung für die vorhandene Systemlandschaft geeignet ist, muss im konkreten Projekt geprüft werden – einschließlich Datenzugang, Verantwortlichkeiten und möglicher Grenzen.

Ein neuer Bildschirm kann hilfreich sein. Ein gemeinsamer, prüfbarer Informationsstand für die anstehende Managemententscheidung ist die eigentliche Anforderung.

Wählen Sie eine kritische Entscheidung aus einem laufenden Projekt mit mehreren Dienstleistern. Ordnen Sie die fünf dafür benötigten Datenfelder ihren Quellen und Verantwortlichen zu. Lassen Sie sich erst danach zeigen, ob eine neue Lösung diese Entscheidung tatsächlich besser unterstützt.

Mehr zum Ansatz: Project Intelligence bei Ramp7. Demo buchen – auf Basis Ihrer konkreten Steuerungsfrage, nicht einer angenommenen Standardintegration.