Zum Inhalt springen
Insight

Procurement Operating Model: Governance vor Digitalisierung

Ein neues ERP löst keine unklaren Mandate. Warum Organisation, Rollen, Category Ownership und Entscheidungsrechte vor der Systemkonfiguration geklärt werden müssen.

10. Juli 2026 · 3 Min. Lesezeit
ProcurementVerhandlungsfähigkeit

ERP- und Source-to-Pay-Programme erzeugen einen starken Veränderungsdruck. Prozesse müssen beschrieben, Rollen im System hinterlegt und Freigaben konfiguriert werden. Genau darin liegt die Chance – und ein erhebliches Risiko.

Wenn die Organisation ihre fachliche Governance nicht geklärt hat, digitalisiert das System bestehende Unklarheit. Workflows werden dann präzise, ohne dass Entscheidungen besser werden.

Ein Operating Model ist mehr als ein Organigramm

Ein Procurement Target Operating Model beschreibt, wie der Einkauf Wirkung erzeugt. Dazu gehören:

  • strategischer Auftrag und Ziele
  • Organisation und Governance
  • Rollen, Mandate und Entscheidungsrechte
  • Category- und Lieferantenverantwortung
  • Prozesse und Schnittstellen
  • Fähigkeiten und Kapazitäten
  • Kennzahlen und Performance-Steuerung
  • Daten und Systeme

Technologie ist ein Bestandteil dieses Modells, nicht dessen Ersatz.

Unklare Governance wird im System sichtbar – aber nicht gelöst

Wer darf eine Warengruppenstrategie verbindlich setzen? Wer entscheidet über Lieferanten? Welche Rolle hat die Technik? Wer trägt die Verantwortung für Savings, Risiko und Vertragsabdeckung?

Ohne Antworten entstehen Systemrollen, die formal korrekt, aber fachlich leer sind. Freigabeworkflows ersetzen dann echte Verantwortung durch zusätzliche Schleifen.

Category Ownership vor Workflow

Eine zentrale Designfrage lautet, wie Kategorien über Standorte und Gesellschaften geführt werden. Ein centre-led Modell kann gemeinsame Strategie, Standards und Transparenz mit lokaler Markt- und Bedarfsnähe verbinden.

Damit dies funktioniert, müssen Category Leads ein klares Mandat besitzen. Ebenso wichtig ist die Rolle lokaler Einkäufer, Bedarfsträger und technischer Funktionen. Erst danach lässt sich sinnvoll entscheiden, welche Aufgaben ein System unterstützt oder erzwingt.

Strategische und operative Arbeit trennen

Viele Einkaufsorganisationen erwarten strategische Wirkung, binden ihre Kapazität aber überwiegend in Bestellabwicklung, Terminverfolgung und Ausnahmen. Ein Operating Model muss deshalb nicht nur Rollen benennen, sondern Arbeit tatsächlich verlagern, standardisieren oder automatisieren.

Andernfalls bleibt „strategischer Einkauf“ eine Stellenbezeichnung ohne verfügbaren Zeithorizont.

KPIs folgen dem Auftrag

Ein System kann nahezu jede Kennzahl erzeugen. Relevant ist, welche Entscheidungen die Kennzahl verbessert. Savings allein reichen nicht. Vertragsabdeckung, frühe Einbindung, Versorgung, Risiko, Durchlaufzeit, Compliance und Lieferantenentwicklung können ebenso wichtig sein.

Die KPI-Architektur muss zum Zielmodell passen und Verantwortlichkeiten abbilden. Sonst entsteht Reporting ohne Steuerung.

Das ERP-Fenster richtig nutzen

Die fachliche Klärung darf nicht warten, bis das Systemdesign abgeschlossen ist. Besonders Rollen, Freigaben, Stammdatenverantwortung, Prozessvarianten und Berichtsdimensionen müssen früh in das Programm einfließen.

Gleichzeitig sollte das Target Operating Model nicht ausschließlich aus heutigen Systemgrenzen abgeleitet werden. Die richtige Reihenfolge lautet:

  1. Geschäftliche Ziele und Probleme klären.
  2. Governance, Rollen und Prozesse entwerfen.
  3. Systemanforderungen daraus ableiten.
  4. Abweichungen bewusst entscheiden.

Transformation wird sequenziert

Nicht alles muss vor dem Go-live vollständig umgesetzt sein. Ein belastbarer Blueprint unterscheidet zwischen Voraussetzungen für das Core Design, kurzfristig aktivierbarer Governance und längerfristigem Capability- beziehungsweise Organisationsaufbau.

So wird Digitalisierung zum Beschleuniger eines fachlich begründeten Modells – statt zur technisch sauberen Festschreibung historischer Schwächen.