Ein Vendor liefert nicht zu spät, weil das Statusmeeting zu kurz war. Er liefert zu spät, wenn Abhängigkeiten, Entscheidungsrechte und Abnahmekriterien im Programm nicht eindeutig geführt werden. Genau hier entscheidet Vendor Management bei IT-Programmen darüber, ob ein Transformationsprogramm planbar bleibt oder ob interne Teams permanent Lieferprobleme, Nachträge und Eskalationen verwalten.
In Enterprise-Programmen mit SAP-Integration, MES, Netzwerkmodernisierung, Cloud-Migration oder Shopfloor-Digitalisierung arbeiten selten nur ein oder zwei externe Partner. Systemintegratoren, Softwarehersteller, Infrastrukturprovider, Spezialberater und lokale Rollout-Partner liefern parallel. Jeder Vertrag kann für sich sauber aussehen. Das Programm scheitert dennoch, wenn niemand die Schnittstellen zwischen den Verträgen operativ steuert.
Warum einzelne Lieferanten nicht das Problem sind
Die meisten Eskalationen werden vorschnell als Vendor-Problem etikettiert: Qualität unzureichend, Termin verfehlt, Ressourcen zu knapp. Häufig liegt die Ursache jedoch im Programm selbst. Anforderungen ändern sich ohne formale Bewertung. Fachbereiche entscheiden verspätet. Testumgebungen stehen nicht bereit. Ein Provider wartet auf eine Freigabe, während der Integrator bereits für seinen nächsten Meilenstein eingeplant ist.
Der Lieferant sieht seinen Scope. Die Programmleitung muss den End-to-End-Erfolg sehen. Diese Perspektivlücke ist besonders kritisch, wenn OT- und IT-Komponenten zusammenkommen. Im Werk kann ein MES-Partner technisch bereit sein, aber die Schnittstelle zum ERP ist nicht final spezifiziert. Bei einem FTTH-Rollout ist die Bauleistung abgeschlossen, doch Dokumentation, Aktivierung und Übergabe an den Betrieb folgen unterschiedlichen Taktungen. Ohne zentrale Steuerung wird aus einer kleinen Verzögerung schnell ein verschobener Go-live.
Gutes Vendor Management ist deshalb keine Einkaufsdisziplin mit erweiterten Statusreports. Es ist ein Steuerungsmodell für Leistung, Risiko, Schnittstellen und Entscheidungen.
Vendor Management bei IT-Programmen beginnt vor dem Kick-off
Die operative Qualität wird oft bereits in der Vergabe entschieden. Wenn Leistungsbeschreibungen nur Ziele benennen, aber keine prüfbaren Ergebnisse definieren, sind spätere Konflikte vorprogrammiert. „Implementierung der Lösung“ ist kein ausreichend steuerbarer Liefergegenstand. Ein belastbarer Scope beschreibt, welche Artefakte, Funktionen, Tests, Dokumentationen und Abnahmen erwartet werden – und wer die Voraussetzungen dafür bereitstellt.
Dabei geht es nicht darum, jeden Arbeitsschritt vertraglich zu ersticken. Gerade in agilen oder explorativen Teilen eines Programms braucht ein Partner Handlungsspielraum. Der entscheidende Unterschied: Flexibilität bei der Umsetzung darf nicht zu Unklarheit über Ergebnis, Budgetverantwortung und Entscheidungsweg führen.
Vor dem Kick-off sollten Programmleitung, Einkauf, Fachbereich und Vendor mindestens vier Fragen gemeinsam beantworten:
- Welches konkrete Ergebnis wird zu welchem Zeitpunkt abgenommen?
- Welche Inputs, Entscheidungen und Plattformen muss der Kunde bereitstellen?
- Welche anderen Lieferanten sind für die Leistung kritisch?
- Wer entscheidet bei Scope-Konflikten, Architekturfragen und Terminabweichungen?
Diese Klarheit reduziert spätere Eskalationen stärker als zusätzliche Jour-fixe-Termine. Sie trennt berechtigte Change Requests von Leistungen, die ohnehin im vereinbarten Scope liegen.
Abhängigkeiten brauchen einen eigenen Steuerungsrhythmus
Einzelne Workstreams können grün melden und das Gesamtprogramm trotzdem gefährden. Der Grund sind fast immer Schnittstellen. Deshalb genügt es nicht, Meilensteine pro Vendor nachzuhalten. Ein Programm braucht ein gemeinsames Abhängigkeitsregister mit Verantwortlichen, Fälligkeiten, Auswirkungen und Eskalationslogik.
Ein typisches Beispiel aus der Produktionsdigitalisierung: Der MES-Implementierungspartner plant den Integrationstest. Dafür müssen Stammdaten bereinigt, Schnittstellen zum ERP freigegeben, Testchargen verfügbar und Rollen im Shopfloor eingerichtet sein. Keine dieser Voraussetzungen liegt vollständig beim MES-Partner. Ohne transparentes Tracking bleibt sein Terminplan formal korrekt, während der tatsächliche Go-live gefährdet ist.
Die Regel lautet: Jede programmrelevante Abhängigkeit bekommt einen Owner auf Kundenseite und einen Owner beim jeweiligen Lieferanten. Ein Eintrag ohne klaren Eigentümer ist keine Steuerungsinformation, sondern eine offene Gefahr.
Governance: Weniger Reporting, mehr Entscheidungen
Viele Programme reagieren auf Unsicherheit mit mehr Folien. Das schafft Sichtbarkeit, aber noch keine Kontrolle. Entscheidend ist eine Governance, in der Probleme früh sichtbar werden und Entscheidungen innerhalb eines definierten Zeitfensters fallen.
Ein wirksames Modell trennt drei Ebenen. Auf Arbeitsebene klären Teams technische Details, offene Anforderungen und kurzfristige Blocker. Auf der Lieferantenebene werden Leistungsfortschritt, Qualität, Ressourcen und vertragliche Pflichten bewertet. Im Steering werden nur Entscheidungen behandelt, die Budget, Priorität, Risikoakzeptanz oder übergreifende Zielarchitektur betreffen.
Diese Trennung schützt das Steering Committee vor operativer Überlastung. Gleichzeitig verhindert sie, dass kritische Entscheidungen zu lange in Fachrunden hängen bleiben. Für internationale Programme ist zusätzlich wichtig, dass Entscheidungsrechte nicht nur bekannt, sondern dokumentiert sind. Unterschiedliche Regionen, Werke oder Business Units dürfen nicht denselben Architekturentscheid erneut verhandeln, wenn dadurch zentrale Standards aufgeweicht werden.
Die Kennzahlen müssen steuerbar sein
Eine Ampel allein ist zu ungenau. Sie zeigt, dass etwas kritisch ist, aber nicht, ob die Gegenmaßnahme wirkt. Leistungskennzahlen sollten sich direkt auf programmrelevante Ergebnisse beziehen.
Bei Infrastruktur-Rollouts können das etwa die Quote technisch abgenommener Standorte, First-Time-Right bei Installationen, Zeit bis zur Störungsbehebung und Vollständigkeit der As-built-Dokumentation sein. Bei Software- und Integrationsprogrammen zählen unter anderem bestandene Testfälle, Defect-Aging, Abdeckung kritischer Prozesse, Durchlaufzeit von Changes und Stabilität nach Deployment.
Nicht jede Kennzahl passt in jedes Programm. Ein Fixpreisprojekt braucht andere Kontrollpunkte als ein Time-and-Material-Modell. Auch bei agiler Lieferung wäre es falsch, ausschließlich auf Termine zu starren. Dann sind Produktwert, Lieferfähigkeit und Qualität mindestens ebenso relevant. Unverzichtbar bleibt jedoch: Jede KPI braucht einen Zielwert, eine Datenquelle, einen Verantwortlichen und eine definierte Reaktion bei Abweichung.
Eskalationen professionell führen statt Beziehungen beschädigen
Eskalation ist kein Zeichen von schlechtem Vendor Management. Zu spät oder emotional zu eskalieren ist es. Wenn ein Lieferant wiederholt Zusagen nicht einhält, benötigt die Programmleitung eine nachvollziehbare Faktenbasis: vereinbarter Liefergegenstand, gemeldeter Status, tatsächlicher Fortschritt, Auswirkung, erforderliche Entscheidung und Frist zur Korrektur.
Diese Struktur schützt beide Seiten. Der Kunde kann keine zusätzlichen Leistungen stillschweigend erwarten. Der Vendor kann Risiken nicht hinter allgemeinen Hinweisen auf Komplexität verstecken. Besonders wirksam ist ein Recovery Plan, der konkrete Maßnahmen statt Absichtserklärungen enthält: zusätzliche Kompetenz, Termin für ein revidiertes Konzept, Testplan, Führungstermine und messbare Zwischenziele.
Die Geschäftsbeziehung darf dabei nicht zur Ausrede für fehlende Konsequenz werden. Strategische Partner brauchen eine faire, verlässliche Zusammenarbeit. Sie brauchen aber auch klare Erwartungen. Wer dauerhafte Minderleistung toleriert, verlagert Risiken auf interne Teams und gefährdet am Ende Akzeptanz und Business Case des gesamten Programms.
Der häufigste Fehler: Verträge und Realität laufen getrennt
Einkauf verwaltet Vertragsdaten, das Projektteam arbeitet mit Backlogs und Terminplänen, Fachbereiche führen eigene Prioritätenlisten. Wenn diese Sichtweisen nicht zusammengeführt werden, entstehen blinde Flecken. Das Team nimmt vielleicht zusätzliche Anforderungen auf, ohne Budgeteffekt zu bewerten. Oder ein Vertrag enthält Abnahmekriterien, die in der Testplanung gar nicht abgebildet sind.
Ein integriertes Vendor Cockpit schafft hier Kontrolle. Es verbindet Scope, Meilensteine, offene Changes, Risiken, Rechnungsstatus, Qualität und Abnahmen in einer steuerbaren Sicht. Das muss kein komplexes Tool sein. In einem kleineren Programm kann eine sauber geführte Struktur reichen. In einem Multi-Vendor-Programm mit mehreren Ländern, Werken oder Releases braucht es dagegen ein belastbares PMO-Setup mit einheitlichen Datenständen und klaren Reporting-Zyklen.
Der Aufwand lohnt sich, weil Entscheidungen nicht mehr auf Einzelmeinungen beruhen. Die Programmleitung erkennt, welcher Vendor wirklich blockiert, wo der Kunde selbst in Verzug ist und welche Risiken den kritischen Pfad treffen.
Was Führungskräfte jetzt anders entscheiden sollten
Vendor Management wird oft erst dann ernst genommen, wenn ein Go-live wackelt oder ein Nachtrag auf dem Tisch liegt. Dann ist der Handlungsspielraum bereits begrenzt. Der größere Hebel liegt darin, das Steuerungsmodell zu Beginn des Programms aufzusetzen und konsequent zu betreiben.
Für CIOs, Programmleiter und PMO Leads bedeutet das: Nicht den Lieferanten möglichst eng kontrollieren, sondern die gemeinsame Lieferfähigkeit messbar machen. Klare Ergebnisse, transparente Abhängigkeiten, verbindliche Entscheidungen und faktenbasierte Eskalationen schaffen die Kontrolle, die komplexe Transformationen brauchen. So wird aus einer Ansammlung externer Verträge ein steuerbares Programm mit belastbaren Ergebnissen.
