S2P Operating Model: Ownership vor Rollout

Der echte S2P-Bruch entsteht selten im Tool. Er entsteht zwischen Ownership, Handoffs und Entscheidungen, lange bevor der Rollout sichtbar stockt.

Das Signal: Der Rollout ist live, aber Ownership nicht

S2P-Programme starten häufig mit einer sehr klaren Oberfläche. Es gibt ein Zielbild, ein Tool, Prozessdesign, Trainingspläne, Rollout-Wellen, KPI-Definitionen und ein Steering. Auf dem Papier sieht es aus, als könne die Organisation jetzt vom fragmentierten Arbeiten in einen durchgängigen Source-to-Pay-Fluss wechseln. In der Praxis zeigt sich oft etwas anderes: Die Lösung ist live, aber Ownership ist nicht live.

Das Signal taucht meistens nicht am ersten Tag auf. Zuerst sieht alles wie normale Rollout-Reibung aus. Einzelne Regionen nutzen Workarounds. Business-Bereiche umgehen Intake-Regeln. Maverick Buying wird als Adoption-Thema gelesen. Finance fragt nach Value Proof. Procurement fragt nach Compliance. IT fragt nach Ticket-Qualität. Shared Services fragt nach sauberen Inputs. Lieferanten fragen nach Klarheit. Jeder Bereich sieht einen Teil des Problems, aber niemand besitzt das End-to-End-Ergebnis.

Genau hier beginnt der Bruch. S2P wird nicht dadurch stabil, dass ein Prozess dokumentiert ist. S2P wird stabil, wenn klar ist, wer den Fluss besitzt, wer Ausnahmen entscheidet, wer Handoffs schützt, wer Governance wirksam hält und wer dafür sorgt, dass Wert nicht nur versprochen, sondern realisiert wird.

Warum S2P politisch schwierig wird

Source-to-Pay berührt viele Funktionen gleichzeitig. Procurement will bessere Steuerung und Wertbeitrag. Finance will Kontrolle, Validierung und Transparenz. IT will eine saubere Plattformarchitektur. Legal will Risiken schützen. Operations will Geschwindigkeit. Business Stakeholder wollen Einfachheit. Shared Services will skalierbare Standards. Supplier wollen klare Interaktion. Diese Perspektiven sind alle legitim. Schwierig wird es, wenn keine Architektur existiert, die diese Perspektiven in einen Entscheidungsfluss übersetzt.

Dann wird jedes operative Problem politisch. Eine Region nennt es lokale Realität. Procurement nennt es Non-Compliance. Finance nennt es fehlende Validierung. IT nennt es Change Request. Business nennt es Bürokratie. Shared Services nennt es Input-Qualität. Das Problem ist dann nicht fehlende Motivation. Das Problem ist, dass das Operating Model nicht sagt, welche Perspektive wann entscheidet und welche Konsequenzen daraus folgen.

Viele S2P-Rollouts versuchen, diesen Bruch mit mehr Training, mehr Kommunikation oder mehr Tool-Konfiguration zu lösen. Das hilft begrenzt. Wenn ein Prozess aber keinen eindeutigen Owner hat, macht Training Menschen nur besser darin, eine unklare Realität zu bedienen. Wenn Exception Ownership fehlt, erzeugt Kommunikation nur mehr Kanäle für ungelöste Fragen. Wenn Decision Rights fehlen, wird Tool-Konfiguration zur Ersatzpolitik.

Die Ownership-Fragen, die wirklich zählen

Ein belastbares S2P Operating Model muss einige harte Fragen beantworten. Wer besitzt den End-to-End-Fluss von Bedarf bis Zahlung? Wer entscheidet, ob eine Ausnahme akzeptiert, abgelehnt oder in den Standard überführt wird? Wer besitzt Stammdatenqualität nicht nur technisch, sondern als geschäftliche Voraussetzung für Prozessstabilität? Wer kann Prioritäten setzen, wenn Prozessstandard, lokale Geschwindigkeit und Kontrollinteresse kollidieren? Wer trägt die Verantwortung dafür, dass realisierter Wert sichtbar wird?

Diese Fragen wirken einfach, aber sie schneiden tief. Sie trennen Rollenbeschreibung von Outcome Ownership. Viele Organisationen haben Process Owner, aber keine Outcome Owner. Sie haben Governance Boards, aber keine klaren Decision Rights. Sie haben KPI-Reports, aber keine Adoption Evidence. Sie haben Eskalationswege, aber keine Entscheidungslogik. Sie haben ein Tool, aber kein System.

Der Unterschied ist entscheidend. Ein Tool kann Workflows abbilden. Ein Operating Model legt fest, wer für Bewegung verantwortlich ist. Ein Tool kann Regeln erzwingen. Ein Operating Model legt fest, wann Regeln verändert werden dürfen. Ein Tool kann Daten sammeln. Ein Operating Model legt fest, wer aus Daten Entscheidungen macht.

Was ein stärkeres S2P Operating Model enthält

Ein starkes S2P Operating Model ist nicht nur ein RACI-Dokument. Es ist ein praktisches Execution System. Es definiert Prozess-Ownership, Business-Ownership, Decision Rights, Governance Rhythm, Exception Handling, Stammdatenverantwortung, Value Tracking und Capability-Aufbau. Vor allem definiert es die Übergänge zwischen diesen Elementen.

Der kritische Punkt liegt in den Handoffs. Vom Business Need zum Intake. Vom Intake zur Sourcing-Entscheidung. Von der Entscheidung zum Vertrag. Vom Vertrag zum Katalog, zur Bestellung, zum Wareneingang, zur Rechnung und zur Zahlung. In jedem Handoff kann Klarheit verloren gehen. Und in jedem Handoff braucht es eine explizite Antwort: Was muss übergeben werden? Wer prüft? Wer entscheidet? Was passiert bei Abweichung? Welche Evidenz zeigt, dass der nächste Schritt wirklich ausführbar ist?

Wenn diese Handoffs nicht gestaltet sind, wird S2P langsam, auch wenn das Tool schnell ist. Menschen bauen Nebenwege, weil der Hauptweg ihre Realität nicht trägt. Governance wird zur Rettungsinstanz. Exceptions werden zum Alltag. Das System wirkt digital, aber die eigentliche Arbeit bleibt manuell, politisch und interpretationsbedürftig.

Die 60-Tage-Korrektur

Eine sinnvolle Korrektur beginnt nicht mit einem neuen Rollout-Deck. Sie beginnt mit einer schmalen Diagnose. Wählen Sie einen S2P-Fluss, der sichtbar weh tut: Intake zu Sourcing, Contracting zu Buying Channel, Purchase Order zu Invoice, Supplier Onboarding zu Compliance oder Savings Idea zu Value Capture. Folgen Sie echten Fällen, nicht dem Soll-Prozess.

Markieren Sie alle Stellen, an denen Arbeit wartet, zurückspringt, eskaliert oder lokal gelöst wird. Dann fragen Sie nicht zuerst, welches Tool-Feld fehlt. Fragen Sie, welche Ownership fehlt. Welche Entscheidung ist unklar? Welcher Handoff ist zu schwach? Welche Governance schützt Geschwindigkeit und welche erzeugt Verzögerung? Welche Kennzahl zeigt nur Aktivität und welche zeigt echten Fluss?

Nach dieser Diagnose sollte ein 60-Tage-Move entstehen. Zum Beispiel: einen Decision Owner für kritische Intake-Fälle benennen, Exception-Kategorien vereinfachen, Stammdaten-Ownership geschäftlich verankern, eine wöchentliche Handoff-Cadence zwischen Procurement, Finance und Shared Services einführen und Value Tracking früher mit Business Adoption verbinden. Das ist kein großes Programm. Es ist ein Systemeingriff.

Der Leadership Shift

S2P-Führung braucht weniger Tool-Optimismus und mehr Operating-Model-Klarheit. Das bedeutet nicht, Technologie kleinzureden. Es bedeutet, Technologie nicht mit Verantwortung zu verwechseln. Ein gutes System lässt Technologie wirken, weil Ownership, Entscheidungen, Governance und Value Logic bereits tragfähig sind.

Wenn S2P funktioniert, erleben Nutzer nicht einfach ein neues Tool. Sie erleben einen klareren Weg, um Bedarf, Entscheidung, Kontrolle und Wert zusammenzubringen. Procurement wird nicht dadurch strategischer, dass es S2P besitzt. Procurement wird strategischer, wenn es den End-to-End-Fluss so gestaltet, dass Business, Finance, IT und Operations schneller zu besseren Entscheidungen kommen.

Das Signal ist einfach: Wenn der Rollout live ist, aber Ownership unklar bleibt, skaliert das System nur die Ambiguität. Klären Sie Ownership vor Rollout, Entscheidungsrechte vor Eskalation und Handoffs vor Automatisierung. Dann wird S2P nicht nur eingeführt. Es wird ausführbar.