Wenn Vertrauen zum Arbeitsauftrag wird – ein laufendes S/4 Programm unter Druck

Wie wir ein laufendes S/4 Programm stabilisierten – ohne neue Tools, aber mit Verantwortung und Struktur.

Es gibt Anrufe, die man nicht vergisst. Der Anruf erreichte uns an einem ruhigen Novembermorgen – von einem Kunden, mit dem uns über fünfzehn Jahre gemeinsamer Projektgeschichte verbinden. In den letzten Jahren hatten wir nur noch sporadisch Kontakt, ein paar Gespräche, ein paar Grüße. Und dann dieser Satz: 
„Wir stecken mitten in einer S/4‑Transformation. Unser Testmanagement bricht weg. Der Programmleiter meldet sich bei Ihnen.“ 

Am nächsten Tag meldete er sich tatsächlich. Kurz, direkt, ohne Umschweife. Die Testmanagerin – eine interne Kollegin – hatte gekündigt und würde das Unternehmen in zwei Wochen verlassen. Das System stand noch im Upgrade, die ersten Tests sollten übernächste Woche starten. 
Seine Worte: „Mir wurde gesagt, ich kann Sie blind einkaufen.“ 

Solche Sätze verstehen wir nicht als Kompliment, sondern als Verpflichtung. Ein Vertrauensvorschuss ist kein bequemes Kissen, sondern ein Arbeitsauftrag. Also warteten wir nicht auf Verträge. Wir warteten nicht auf Freigaben. Wir legten los. Erst Verantwortung, dann Formalitäten. 
Boutique ist für uns eine Haltung: echte Verantwortung übernehmen und Entscheidungen treffen – auch unter Druck. 

Vor Ort zeigte sich schnell, wie kritisch die Lage war: Jeder Stream arbeitete mit eigenen Excel‑Listen, teils völlig unterschiedlich strukturiert. Reporting? Wöchentliche Zurufe. Issue‑Management? Eine separate Datei irgendwo im Projektlaufwerk. Für ein S/4‑Programm eines globalen Automobilzulieferers war das nicht nur unübersichtlich – es war ein echtes Risiko. 

In einem offenen Austausch mit dem Testmanager des Implementierungspartners bestätigte sich der Eindruck: Die Herausforderungen waren allen bewusst, der Implementierungspartner hatte die Risiken früh adressiert – aber ohne Zustimmung des Kunden war ein neues Tool keine Option. Kein Fingerzeig, kein Vorwurf. Einfach die Realität großer Programme: Manchmal laufen kritische Themen zu lange nebenher. 

Während wir Transparenz herstellten und ein erstes, pragmatisches Reporting aufsetzten, wurde deutlich: Hier würde kein neues Tool die Situation retten. Keine Vorlage. Keine Methodik aus der Schublade. 
Hier ging es darum, Verantwortung zu übernehmen, während die Uhr gnadenlos tickte.

Die Ausgangslage – viel Excel, wenig Steuerbarkeit 
Der Kunde hatte sich für eine selektive Datenmigration entschieden, die Systemlandschaft war komplex: drei produktive Stränge, drei zugehörige Q‑Systeme, ein gemeinsames D‑System. Geplant waren drei Testzyklen je Systemstrang, jeweils mit drei Phasen: Data Validation, IT‑Prozesstests, Business‑Prozesstests. 
In Summe: 27 Testphasen, teils parallel – plus Schnittstellen, Fiori‑Apps und Add‑Ons ab Zyklus zwei. 
Das vorhandene Setup: viele Excel‑Listen, wenig Struktur, keine integrierte Sicht auf Fortschritt, Blocker oder Risiken. Transparenz entstand in Meetings – nicht im eigentlichen Testgeschehen. 

Schritt 1: Stabilisieren, ohne das Team auszubremsen 
In 24 Stunden haben wir ein leichtgewichtiges Reporting aufgebaut, das die bestehenden Listen minimal harmonisierte. Gerade genug Struktur, um einen belastbaren Überblick zu ermöglichen – ohne die Streams aus ihren Arbeitsweisen zu reißen. 
Der Effekt war unmittelbar spürbar: Der Programmleiter konnte erstmals sehen, wo Tests stockten, welche Bereiche sauber liefen und welche Risiken sich abzeichneten. Nicht perfekt. Aber verlässlich. 

Schritt 2: Verantwortung vor Tool‑Debatte – wir nutzen, was da ist 
Eine neue Testmanagement‑Software einzuführen war ausgeschlossen – die Tests hatten bereits begonnen, und das Team hätte sich an ein neues Tool anpassen müssen, während die Uhr lief. 
Also haben wir das Testmanagement in eine Plattform überführt, die bereits da war: Microsoft Teams und SharePoint. 

Mit der richtigen Struktur ist das mächtiger, als viele glauben: 

1. Zentrale Testfall‑Bibliothek in SharePoint mit klaren Metadaten und Versionierung 
2. Defects direkt verknüpft mit ihrem jeweiligen Testfall 
3. Workflows für Statuswechsel (New → In progress → to be re-tested → solved) 
4. Dashboards für Programmblick: Abdeckung, Durchlauf, Fehlerraten, Top‑Blocker, Trends 
5. Filter, Ansichten, Favoriten, damit alle in Sekunden finden, was sie brauchen 

Parallel haben wir eine Teststrategie formuliert, How‑Tos erstellt und Tester Kick‑off‑Sessions durchgeführt. Natürlich war die Stimmung anfangs skeptisch – doch sobald die ersten Tester erlebten, wie schnell sie Defects finden, Tests dokumentieren und Fortschritt melden konnten, drehte sich das Bild. Aus Skepsis wurde Akzeptanz, aus Akzeptanz Routine. 

 Zusammenarbeit mit dem Implementierungspartner – professionell und lösungsorientiert 

Mit dem Implementierungspartner haben wir offen und konstruktiv zusammengearbeitet. Trotz der angespannten Gesamtsituation war die Zusammenarbeit sachlich, respektvoll und zielorientiert. Alle Beteiligten hatten dasselbe Ziel: das Programm stabilisieren und die Tests zum Laufen bringen. Genau so entsteht echter Projektfokus. 

 Vom stabilisierten Testmanagement zur nächsten Vertrauensentscheidung 

Als die Tests liefen – stabil, strukturiert, kontrolliert – stellte der Programmleiter die Frage: „Können Sie auch das Cut‑Over übernehmen?“ 

Unsere Antwort war nicht reflexartig „Ja“. Für uns heißt Haltung auch: Klarheit über die eigenen Stärken – und über die eigenen Grenzen. 
Wir sind „too small to fail“: Als Boutique sind Vertrauen, Reputation und Ergebnis untrennbar mit unserer Leistung verbunden.  
Unser Team vor Ort war stark in Struktur, Kommunikation, Risikoarbeit und Koordination. Die technische Detailtiefe für die einzelnen Schritte war bereits im Projekt vorhanden – bei den Fachteams des Kunden und beim Implementierungspartner. Es wäre weder sinnvoll noch effizient gewesen, dieses Wissen zu duplizieren. Unsere Rolle war es, diese Expertise zusammenzuführen und so zu orchestrieren, dass daraus ein sicherer, steuerbarer Cut‑Over wird. 

Unsere Lösung: Co‑Creation. Wir orchestrieren – die Fachteams liefern die Tiefe. 

Cut‑Over – Führung unter Zeitdruck, nicht Technik 

Gemeinsam mit den Teams haben wir einen Cut‑Over‑Plan aufgebaut, der trägt: Einzelinterviews, Teamsessions, Mock‑Runs und Dress‑Rehearsals für alle drei Systemstränge. 
Die Dress‑Rehearsals fanden bewusst während der normalen Arbeitszeiten statt – inhaltlich identisch zum späteren Produktiv‑Cut‑Over, aber ohne 24/7‑Takt. Ziel: Abläufe verproben, Abhängigkeiten klären, Risiken sichtbar machen. 

Die produktiven Cut‑Over selbst waren dann der Härtetest: 
drei Systeme, drei Wochenenden, drei Umstellungen – jeweils im 24/7‑Betrieb. 
Je nach System lagen wir zwischen 43 und 57 Stunden Durchführungszeit. Jedes Mal derselbe Anspruch: Ruhe, Struktur, Führung. 

MS Project – mehr als Standard 
Wir nutzten MS Project konsequent – und über den Standard hinaus: Wir haben eigene Entwicklungen und Automatisierungen eingesetzt, um Abhängigkeiten scharf zu steuern, Startzeiten zu berechnen und automatisch anzustoßen, Benachrichtigungen gezielt auszulösen und Status‑Aggregationen für Live‑Reports zu generieren. Alle Beteiligten konnten jederzeit sehen, wo ihr Slot lag – und ob er sich verschob. 
Während der Cut‑Over‑Wochenenden generierten wir alle vier Stunden Statusberichte. Ein 24/7‑Steuerungscall mit begleitendem Chat sorgte für Klarheit und direkte Kommunikation. Aktivitäten wurden strukturiert „angetriggert“, Rückmeldungen liefen in Live‑Reports, die sofort zeigten, welche Schritte starten konnten und welche kurz davorstanden. 

Das Ergebnis: Ruhe, Transparenz, reibungslose Übergänge. Kein Chaos, keine Panik. Drei Cut‑Over – sauber, kontrolliert, erfolgreich. 

Was Entscheider daraus lernen können 

1. Verantwortung schlägt Tool. Ohne Führung hilft keine Software. Nutzen Sie, was da ist – und machen Sie es wirksam. 
2. Transparenz zuerst. Ohne Übersicht gibt es keine Steuerung. Erst sichtbar machen, dann vereinheitlichen, dann automatisieren. 
3. Rollen klären. Beratung, Operative, Führung – jede Rolle ist wertvoll. Entscheidend ist, dass alle wissen, was sie beitragen. 
4. Cut‑Over ist Leadership. Planen Sie nicht nur Aufgaben, planen Sie Kommunikation, Eskalationen und Entscheidungen. 
5. Boutique ist eine Haltung. Nahbar, verbindlich, klar – und auf Kundenseite. 

Warum „blind eingekauft“ für uns kein Schönwetter‑Satz ist 
Es ist ein Auftrag. Ein Anspruch. Ein Vertrauenssignal, das man nicht verwaltet, sondern einlöst. 
Wir haben geliefert – weil wir Verantwortung ernst nehmen. Und weil wir Programme führen, als wären sie unsere eigenen. 

Und der Kunde? 
Er plant bereits die nächste S/4‑Transformation – und hat uns frühzeitig eingeplant. Nicht wegen Präsentationen. Sondern wegen Haltung, Klarheit, Struktur – und sichtbarem Erfolg.

Wenn Sie gerade in einem Programm stecken, das sich schwer steuern lässt: Lassen Sie uns sprechen. Kein Sales‑Pitch. Ein ehrlicher Austausch auf Augenhöhe.

Titelbild erstellt mit KI