Um zu verstehen, was diese Plattform leistet, hilft ein Blick auf das Problem, für das sie gebaut wurde. In gewachsenen Unternehmen läuft Beschaffung selten an einer Stelle zusammen. Der Fachbereich bestellt Verbrauchsmaterial per E-Mail, die Instandhaltung ruft beim Stammlieferanten an, das Marketing bucht Agenturleistungen über einen Rahmenvertrag, den außer zwei Personen niemand kennt, und der strategische Einkauf verhandelt Jahresvereinbarungen in Tabellen, die auf einem Netzlaufwerk liegen. Am Ende landet alles in der Buchhaltung, wo Rechnungen mit Bestellungen abgeglichen werden sollen, die es teilweise nie gab. Der Effekt ist bekannt: niemand kennt das tatsächliche Ausgabenvolumen je Lieferant, Rahmenverträge werden nicht ausgeschöpft, und Einsparungen, die im Verhandlungsprotokoll stehen, kommen im Zahlungslauf nicht an.
Genau an dieser Lücke setzt eine Source-to-Pay-Plattform an. Sie führt Bedarfe in einen definierten Kanal, verknüpft sie mit Katalogen und Verträgen, erzwingt Genehmigungen nach hinterlegten Regeln, erzeugt Bestellungen mit eindeutiger Referenz, empfängt Bestätigungen, Lieferavise und Rechnungen elektronisch und stellt Auswertungen über alle Ausgaben bereit. Die Software ist dabei nur die halbe Miete. Die andere Hälfte ist die Frage, ob es gelingt, die Lieferanten auf denselben Kanal zu bringen – und das ist bei Ariba nicht ein Nebenaspekt, sondern der Kern des Modells.
Der Prozess, den die Plattform abbildet, zerfällt in zwei Hälften, die in vielen Unternehmen organisatorisch getrennt sind. Die erste Hälfte heißt Source-to-Contract und ist die Domäne des strategischen Einkaufs: Bedarfsbündelung, Marktanalyse, Lieferantenauswahl, Ausschreibung, Verhandlung, Vergabe und Vertragsabschluss. Die zweite Hälfte heißt Procure-to-Pay und ist die Domäne des operativen Einkaufs und der Fachbereiche: Bedarfsanforderung, Genehmigung, Bestellung, Wareneingang, Rechnungsprüfung und Zahlungsfreigabe. Der Anspruch einer integrierten Plattform ist, dass die zweite Hälfte automatisch auf den Ergebnissen der ersten aufsetzt – dass also ein verhandelter Preis tatsächlich der Preis ist, zu dem im Fachbereich bestellt wird.
Diese Verbindung klingt selbstverständlich und ist es in der Praxis selten. Sie ist der eigentliche Nutzenversprechen jeder Procurement-Suite: Vertragsdaten, Preislisten und zugelassene Lieferanten sind nicht Dokumente, sondern Stammdaten, aus denen operative Vorgänge gespeist werden. Wenn das gelingt, sinkt der Anteil an Ausgaben, die an Verträgen vorbeilaufen – im Fachjargon Maverick Buying –, und die Einkaufsabteilung kann erstmals belegen, welcher Teil des verhandelten Vorteils tatsächlich realisiert wurde. Wenn es nicht gelingt, hat man eine teure Bestellmaske eingeführt.
Drei Abgrenzungen ersparen im Auswahlprozess viel Enttäuschung. Erstens: Ariba ist kein ERP. Es führt keine Finanzbuchhaltung, keine Anlagenbuchhaltung und keine Materialwirtschaft im Sinne von Beständen, Bewertung und Disposition. Bestände, Materialstämme und Buchungen bleiben im führenden ERP-System, typischerweise SAP S/4HANA oder eine ältere ECC-Landschaft, in Mittelstandsprojekten auch häufig ein Fremdsystem. Ariba erzeugt Belege und Vorgänge, die im ERP verbucht werden, und liest Stammdaten von dort.
Zweitens: Ariba ist kein Lagerverwaltungs- oder Transportsystem. Es beschafft Waren und Leistungen, aber es steuert weder Einlagerung noch Kommissionierung noch Frachtvergabe. Für die Lieferkettenausführung sind andere Systeme zuständig; Berührungspunkte gibt es über Lieferavise und Bestellbestätigungen, nicht über die physische Steuerung. Drittens: Ariba ist keine Vertragsdatenbank im Sinne eines juristischen Dokumentenmanagements für sämtliche Unternehmensverträge. Es verwaltet Beschaffungsverträge mit ihren kommerziellen Konditionen; Gesellschaftsverträge, Arbeitsverträge oder Kundenverträge gehören woanders hin.
Positiv gewendet: Ariba ist die Schicht, in der Einkaufsentscheidungen getroffen, dokumentiert und in wiederholbare operative Abläufe überführt werden – und in der die Kommunikation mit Lieferanten stattfindet. Wer diese Rolle klar zuschneidet, kann den Nutzen realistisch bewerten. Wer erwartet, dass ein Beschaffungssystem nebenbei die Materialplanung ordnet, wird das Projekt überfrachten.
Der Punkt, der Ariba von reinen Einkaufswerkzeugen unterscheidet, ist das Netzwerkmodell. Klassische Beschaffungssoftware ist eine Anwendung, die ein Unternehmen für sich betreibt und an die es Lieferanten über Schnittstellen anbindet – jede Verbindung ein eigenes Projekt. Das Netzwerkmodell dreht die Logik um: Lieferanten sind einmal auf der Plattform registriert und können mit allen dort vertretenen Käufern arbeiten. Ein Lieferant, der bereits für einen anderen Kunden angebunden ist, muss für das nächste Unternehmen nicht bei null anfangen.
Dieser Effekt ist real und in Projekten spürbar, vor allem bei größeren, international tätigen Lieferanten, die ohnehin über mehrere Netzwerke abwickeln. Er hat aber eine Kehrseite, die offen benannt gehört: Die Teilnahme am Netzwerk ist für Lieferanten in vielen Konstellationen kostenpflichtig, abhängig von Transaktionsvolumen und Nutzungsumfang. Für kleine regionale Lieferanten – den Schlosser, die Druckerei, den Elektrobetrieb um die Ecke – ist das ein Thema, das über Zustimmung oder Widerstand entscheidet. Wir kommen darauf in den Kapiteln zur Einführung und zu den Kosten ausführlich zurück, weil sich an dieser Frage im Mittelstand mehr Projekte entscheiden als an Funktionsvergleichen.
Aus diesem Modell folgt eine strategische Einsicht: Der Nutzen von Ariba steigt nicht linear mit der Zahl der eingeführten Module, sondern mit dem Anteil des Ausgabenvolumens, der tatsächlich über die Plattform läuft. Ein Unternehmen, das drei Module einführt und damit einen großen Teil seiner Lieferanten erreicht, hat mehr gewonnen als eines, das sechs Module einführt, die von der Hälfte der Lieferanten ignoriert werden. Diese Kennzahl – Abdeckungsgrad des Ausgabenvolumens – gehört von Beginn an in die Projektsteuerung.
SAP hat seine Anwendungen rund um Ausgaben unter dem Begriff Intelligent Spend Management gebündelt. Neben Ariba gehören dazu vor allem zwei weitere Bausteine, deren Abgrenzung im Auswahlgespräch immer wieder gebraucht wird. SAP Fieldglass adressiert die Beschaffung externer Arbeitsleistungen: Zeitarbeit, Werkverträge, freiberufliche Dienstleistungen – also Ausgaben, bei denen nicht ein Produkt, sondern Arbeitszeit oder ein Leistungsergebnis eingekauft wird, mit eigenen Anforderungen an Bedarfsmeldung, Ausschreibung, Zeiterfassung und Abrechnung. SAP Concur adressiert Reise- und Spesenmanagement, also Ausgaben, die Mitarbeitende auslösen und die nachträglich belegt und erstattet werden.
Die Logik dahinter ist, dass ein Unternehmen erst dann eine belastbare Sicht auf seine Ausgaben hat, wenn indirekte Beschaffung, externe Arbeit und Reisekosten gemeinsam betrachtet werden. In der Praxis mittelständischer Unternehmen ist diese Vollausbaustufe selten der Startpunkt. Verbreiteter ist ein Einstieg über den Bereich mit dem größten Leidensdruck – meist entweder die operative Beschaffung indirekter Materialien oder das Lieferantenmanagement mit seinen Nachweispflichten – und ein späterer Ausbau. Wichtig ist zu wissen, dass die drei Linien technisch eigenständige Anwendungen sind und dass die Integration untereinander ein eigener Projektbestandteil bleibt.
Für die Einordnung hilft außerdem der Blick auf die SAP-Landschaft insgesamt. Ariba ist nicht die einzige Stelle, an der Beschaffung stattfindet. In S/4HANA existiert eine eigene Einkaufsfunktionalität mit Bestellanforderungen, Bestellungen, Lieferantenstämmen und Rechnungsprüfung. Die Frage, welche Vorgänge im ERP bleiben und welche in Ariba wandern, ist deshalb eine der ersten Architekturentscheidungen – und keine, die sich pauschal beantworten lässt. Sie hängt davon ab, wie hoch der Anteil kataloggestützter indirekter Beschaffung ist, wie viele Fachbereichsnutzer beteiligt sind und wie stark die Lieferantenkommunikation elektronisch laufen soll.
Eine Unterscheidung, die den Zuschnitt eines Ariba-Projekts stärker prägt als jede Modulentscheidung, ist die zwischen direktem und indirektem Material. Indirekte Beschaffung umfasst alles, was nicht in das eigene Produkt eingeht: Büromaterial, IT-Ausstattung, Instandhaltungsbedarf, Dienstleistungen, Werkzeuge, Betriebsstoffe. Charakteristisch sind viele kleine Vorgänge, viele beteiligte Personen aus Fachbereichen, hohe Lieferantenzahl und ein hoher Anteil an Vorgängen, die ohne System an jeder Kontrolle vorbeilaufen. Hier liegt der klassische Kernbereich von Guided Buying und Katalogbeschaffung, und hier ist der Nutzen am schnellsten sichtbar.
Direkte Beschaffung umfasst Materialien, die in das eigene Erzeugnis eingehen. Charakteristisch sind wenige, dafür strategisch wichtige Lieferanten, hohe Volumina, enge Terminbindung an die Produktionsplanung, Lieferpläne statt Einzelbestellungen sowie Qualitätsanforderungen mit Prüfvorschriften. Der zugehörige Baustein ist Supply Chain Collaboration; die Anforderungen an Datenaustausch, Terminverfolgung und Rückmeldungen sind hier deutlich anspruchsvoller. Für produzierende Mittelständler ist das der eigentlich interessante Bereich – gleichzeitig der mit dem höheren Integrationsaufwand, weil Bedarfe aus der Materialplanung des ERP kommen und Rückmeldungen dorthin zurückfließen müssen.
Unsere Erfahrung aus Auswahlprojekten: Wer beide Welten gleichzeitig angeht, verlängert das Projekt erheblich. Sinnvoller ist eine bewusste Reihenfolge, die sich am Ausgabenvolumen und am Leidensdruck orientiert, und eine ehrliche Antwort auf die Frage, ob die eigene Fertigung überhaupt eine Lieferantenkollaboration in dieser Tiefe braucht. Für einen Handelsbetrieb oder einen Dienstleister ist die indirekte Strecke fast immer der richtige Einstieg.
Weil das Angebot modular ist, entsteht in Auswahlprozessen regelmäßig ein Missverständnis: Die Präsentation zeigt einen durchgängigen Prozess von der Ausschreibung bis zur Zahlung, das Angebot enthält aber nur einen Teil der dafür nötigen Bausteine. Wir empfehlen deshalb, jede Anforderung im Lastenheft ausdrücklich einem Baustein zuzuordnen und beim Anbieter oder Implementierungspartner schriftlich bestätigen zu lassen, welcher Teil im angebotenen Umfang enthalten ist und welcher zusätzlich lizenziert werden müsste. Das klingt nach Formalismus und ist der wirksamste Schutz gegen Budgetüberraschungen im zweiten Projektjahr.
Ein zweiter Punkt betrifft die Nutzerlogik. Beschaffungsplattformen unterscheiden zwischen wenigen intensiven Nutzern im Einkauf und vielen gelegentlichen Nutzern in den Fachbereichen, die nur Bedarfe anfordern oder genehmigen. Wie diese Gruppen lizenztechnisch behandelt werden, hat erheblichen Einfluss auf die Gesamtkosten und auf die Frage, ob sich eine breite Ausrollung im Unternehmen lohnt. Auch das ist eine Frage, die früh und schriftlich geklärt gehört – konkrete Modelle und Konditionen sind beim Anbieter zu erfragen.
Drittens lohnt der Blick auf die Ausbaufähigkeit. Ein Baustein, der heute nicht gebraucht wird, kann in drei Jahren relevant werden, etwa wenn Berichtspflichten zu Lieferketten steigen oder wenn ein zweites Werk mit eigener Beschaffung hinzukommt. Eine Plattform, die diesen Ausbau ohne Systemwechsel erlaubt, hat einen Wert, der sich in einer reinen Funktionsmatrix nicht abbildet. Umgekehrt gilt: Ausbaufähigkeit rechtfertigt keine Überdimensionierung im ersten Schritt. Der Einstieg sollte so klein wie möglich und so groß wie nötig sein.
Der operative Einstieg beginnt bei der Bedarfsanforderung. Fachlich ist das eine schlichte Aufgabe: Jemand braucht etwas, beschreibt es, gibt Menge, Termin und Kontierung an, und jemand anders genehmigt. Praktisch entscheidet genau diese Maske über den Erfolg des gesamten Projekts, weil sie von Menschen bedient wird, die Beschaffung nicht als Beruf ausüben, sondern nebenbei erledigen. Eine Oberfläche, die Einkaufslogik voraussetzt, führt zuverlässig dazu, dass Bedarfe wieder per E-Mail an den Einkauf gehen – und damit an der Plattform vorbei.
Guided Buying ist die Antwort auf dieses Problem: eine vereinfachte, an Suchbegriffen und Warengruppen orientierte Einstiegsschicht, die den Anwender zur richtigen Beschaffungsstrecke führt. Bei einem Katalogartikel landet er direkt im Warenkorb. Bei einer Dienstleistung wird er durch ein Formular geführt. Bei einer Warengruppe mit Rahmenvertrag wird der Vertragslieferant vorgeschlagen. Bei einem genehmigungspflichtigen Sonderfall werden zusätzliche Angaben abgefragt. Der Charme dieses Ansatzes liegt darin, dass Einkaufsrichtlinien nicht als Dokument existieren, sondern als Wegführung im System – Regeln, die man befolgen muss, statt Regeln, die man kennen sollte.
Die Katalogseite ist die stille Dauerbaustelle. Es gibt im Wesentlichen drei Formen: intern gepflegte Kataloge auf Basis von Preislisten, vom Lieferanten bereitgestellte und geprüfte Kataloge sowie Punch-out, bei dem der Anwender in den Shop des Lieferanten springt, dort seinen Warenkorb zusammenstellt und diesen zurück in die Anforderung übergibt. Punch-out reduziert Pflegeaufwand erheblich, verlagert aber Preishoheit und Sortimentssteuerung zum Lieferanten – die vertragliche Absicherung von Preisen und Konditionen wird damit wichtiger, nicht unwichtiger. Für jede Warengruppe gehört bewusst entschieden, welche Form gilt.
Auf der strategischen Seite unterstützt die Plattform Vergabeprozesse. Eine Ausschreibung wird strukturiert angelegt: Positionen, Mengen, Fragenkataloge, Anlagen, Fristen, Teilnehmerkreis. Lieferanten geben ihre Angebote über das Netzwerk ab, das System stellt sie vergleichbar dar, und es lassen sich mehrere Runden fahren. Ergänzend sind elektronische Auktionen möglich, bei denen Lieferanten in einem definierten Zeitfenster Gebote abgeben und den jeweils aktuellen Stand sehen. Solche Formate eignen sich für klar spezifizierte, austauschbare Leistungen mit ausreichend Wettbewerb – und sind fehl am Platz bei Entwicklungspartnerschaften oder bei Lieferanten, deren Zusammenarbeit über den Preis hinausgeht.
Der eigentliche Qualitätssprung entsteht weniger durch die Auktionsmechanik als durch die Struktur. Wer Ausschreibungen im System abwickelt, hat automatisch eine nachvollziehbare Dokumentation: Wer wurde angefragt, wer hat abgegeben, welche Angebote lagen vor, auf welcher Grundlage wurde vergeben. Für Unternehmen mit Compliance-Anforderungen oder mit interner Revision ist das ein handfester Vorteil gegenüber der Vergabe per E-Mail. Voraussetzung ist allerdings ein sauberer Leistungsbeschrieb – ein unscharf formulierter Bedarf wird durch ein Vergabewerkzeug nicht besser, sondern nur schneller unscharf vergeben.
Realistisch einzuschätzen ist der Aufwand je Vergabe. Eine strukturierte elektronische Ausschreibung erfordert Vorbereitung: Positionsstruktur, Bewertungskriterien, Fragenkatalog, Zeitplan. Das lohnt sich bei wiederkehrenden Vergaben und bei größeren Volumina. Für die Einzelbeschaffung einer Maschine, die einmal in fünf Jahren ansteht, ist der Nutzen begrenzt. Eine ehrliche Bestandsaufnahme, wie viele Vergabeprozesse pro Jahr tatsächlich anfallen und welchen Wert sie haben, ist deshalb Teil jeder Wirtschaftlichkeitsbetrachtung.
Das Vertragsmodul schlägt die Brücke zwischen Verhandlung und operativer Abwicklung. Verträge werden mit Metadaten angelegt: Vertragspartner, Laufzeit, Kündigungsfristen, Volumina, Konditionen, Verantwortliche. Aus einer Klauselbibliothek lassen sich Standardtexte zusammenstellen, Freigaben laufen über Workflows. Der entscheidende Mehrwert entsteht dort, wo Konditionen nicht nur dokumentiert, sondern in die Preisfindung des operativen Einkaufs übernommen werden – dann bestellt der Fachbereich automatisch zu verhandelten Preisen, und Abweichungen werden sichtbar statt unbemerkt zu bleiben.
Auf der Bestellseite geht es um Zuverlässigkeit im Austausch. Eine Bestellung wird an den Lieferanten übermittelt, dieser bestätigt sie mit Termin und Menge, meldet Abweichungen, kündigt Lieferungen an und stellt anschließend die Rechnung. Jeder dieser Schritte kann elektronisch erfolgen, und je vollständiger die Kette ist, desto weniger Nachfragen entstehen. In der Praxis ist der begrenzende Faktor nicht die Technik, sondern die Bereitschaft und Fähigkeit der Lieferanten, diese Rückmeldungen konsequent zu liefern. Eine Bestellbestätigung, die nur bei jedem zweiten Lieferanten kommt, erzeugt keine belastbare Terminsicht.
Der Rechnungsabgleich ist der Punkt, an dem sich Aufwand am direktesten in Entlastung übersetzt. Klassisch ist der Dreiwegeabgleich: Rechnung gegen Bestellung gegen Wareneingang. Stimmen Menge, Preis und Empfang innerhalb definierter Toleranzen überein, kann die Rechnung ohne manuelle Prüfung weiterlaufen. Weicht etwas ab, entsteht ein Klärungsfall mit klarer Zuständigkeit. Die Arbeit liegt im Regelwerk: Welche Abweichung ist tolerabel, wer klärt was, wie werden Teillieferungen und Preisstaffeln behandelt, was passiert bei Rechnungen ohne Bestellbezug. Wer diese Regeln vorher nicht durchdenkt, verlagert Handarbeit nur an eine andere Stelle.
Ein Hinweis mit wachsender Bedeutung: Die elektronische Rechnung ist in Deutschland und in der EU zunehmend regulatorisch geprägt. Formatanforderungen, Empfangs- und Aufbewahrungspflichten entwickeln sich weiter. Welche Formate eine Plattform unterstützt und wie sie sich zu nationalen Anforderungen verhält, gehört ausdrücklich beim Anbieter geprüft und mit der Steuerberatung abgestimmt. Wir geben dazu bewusst keine rechtliche Bewertung ab.
Der vierte Funktionsblock betrifft die Lieferanten selbst. Der Lebenszyklus beginnt mit der Registrierung: Ein Lieferant hinterlegt Stammdaten, Bankverbindung, Ansprechpartner, Steuerinformationen und Nachweise. Daran schließt die Qualifizierung an, bei der je nach Warengruppe und Risikoeinstufung unterschiedliche Anforderungen gelten – Zertifikate zu Qualitätsmanagement oder Umwelt, Versicherungsnachweise, Selbstauskünfte zu Arbeitsbedingungen, Erklärungen zu Verhaltensgrundsätzen. Das System kann diese Nachweise mit Ablaufdaten führen und Erinnerungen auslösen, wenn Gültigkeiten enden.
Der Nutzen liegt in der Ablösung von Tabellen und Postfächern. In vielen mittelständischen Unternehmen liegen Lieferantennachweise verteilt: ein Teil im ERP-Stammsatz, ein Teil im Qualitätsmanagement, ein Teil im E-Mail-Archiv einer Person, die seit zwei Jahren im Ruhestand ist. Ein strukturiertes Lieferantenmanagement schafft hier eine gemeinsame Grundlage – und wird damit zur Voraussetzung dafür, Sorgfaltspflichten in der Lieferkette überhaupt belegen zu können. Auf diesen Zusammenhang gehen wir im Kapitel zu Kosten und Recht gesondert ein.
Die Bewertungsseite ergänzt das um Leistungsdaten: Termintreue, Qualitätsmeldungen, Reklamationsquoten, Reaktionszeiten, ergänzt um qualitative Einschätzungen aus Fachbereichen. Solche Kennzahlen sind wertvoll, wenn sie aus dem laufenden Prozess entstehen, und wertlos, wenn sie in einer jährlichen Fragebogenaktion erhoben werden, die niemand ernst nimmt. Der praktische Rat: klein anfangen, mit wenigen Kennzahlen, die automatisch entstehen, und die Lieferantenbewertung mit einer konkreten Konsequenz verbinden – etwa der Entscheidung, welche Lieferanten in die nächste Ausschreibungsrunde eingeladen werden.
Zunächst eine Einordnung, die im Alltag mehr hilft als jede Funktionsliste: Der größte Automatisierungshebel im Einkauf liegt nicht in intelligenten Verfahren, sondern in konsequenter Regelanwendung. Ein Bestellvorgang, der ohne menschliches Zutun durchläuft, weil er katalogbasiert ist, unterhalb einer Wertgrenze liegt, gegen einen gültigen Vertrag läuft und eine Rechnung erzeugt, die im Toleranzband liegt – dieser Vorgang ist automatisiert, ohne dass ein einziges lernendes Modell beteiligt wäre. Wer diese Basis nicht gelegt hat, wird von KI-Funktionen wenig haben. Wer sie gelegt hat, kann sie sinnvoll ergänzen.
Die erste und wichtigste Stelle ist die Rechnungsverarbeitung. Der Abgleich von Rechnung, Bestellung und Wareneingang ist regelbasiert automatisierbar, und lernende Verfahren können darüber hinaus Muster in Abweichungen erkennen: welche Lieferanten regelmäßig abweichende Mengen fakturieren, welche Positionen typischerweise Klärungsbedarf auslösen, welche Abweichungen erfahrungsgemäß unkritisch sind. Der praktische Effekt ist eine bessere Priorisierung: Klärungsfälle werden nicht chronologisch abgearbeitet, sondern nach Wahrscheinlichkeit und Wert. Das ist bescheidener als vollautomatische Prüfung und im Alltag deutlich wertvoller.
Die zweite Stelle ist die Klassifizierung von Ausgabendaten. Ein wiederkehrendes Problem im Einkauf lautet: Man weiß, wie viel Geld an wen geflossen ist, aber nicht wofür. Buchungstexte sind uneinheitlich, Warengruppen werden falsch oder gar nicht gepflegt, dieselbe Leistung erscheint unter fünf Bezeichnungen. Verfahren zur automatischen Zuordnung von Belegpositionen zu Warengruppen adressieren genau diese Lücke und schaffen die Grundlage für Ausgabenanalysen und Bündelungsentscheidungen. Wichtig ist zu wissen, dass solche Zuordnungen Vorschläge sind, die geprüft und korrigiert werden müssen, und dass die Qualität stark von der Ausgangsdatenlage abhängt.
Die dritte Stelle ist die Anwenderführung im Guided Buying. Vorschläge für passende Artikel, Hinweise auf vorhandene Rahmenverträge, Warnungen bei Bestellungen außerhalb bevorzugter Lieferanten, Vervollständigung von Angaben aus früheren Vorgängen – all das reduziert Reibung und erhöht die Wahrscheinlichkeit, dass ein Bedarf über den vorgesehenen Kanal läuft. Das ist keine spektakuläre Technologie, aber es adressiert das zentrale Akzeptanzproblem jeder Beschaffungsplattform.
Aufbauend auf klassifizierten Ausgabendaten werden Analysen möglich, die manuell kaum zu erstellen sind: Welche Warengruppen werden bei wie vielen Lieferanten gleichzeitig beschafft? Wo liegen Preisunterschiede für vergleichbare Leistungen zwischen Standorten? Welche Lieferanten decken ein so kleines Volumen ab, dass die Betreuungskosten den Nutzen übersteigen? Aus solchen Auswertungen entstehen Bündelungskandidaten und Ausschreibungsvorschläge. Systeme können hier unterstützen, indem sie Auffälligkeiten hervorheben – die Entscheidung, ob eine Bündelung fachlich sinnvoll ist, bleibt beim Einkauf, der Marktkenntnis und Versorgungsrisiken einschätzen muss.
Lieferantenempfehlungen sind ein verwandtes Feld: Vorschläge, welche Lieferanten für eine Ausschreibung in Frage kommen, abgeleitet aus Warengruppenzuordnung, bisheriger Zusammenarbeit, Qualifizierungsstatus und Netzwerkinformationen. Solche Vorschläge sind ein Startpunkt für die Marktrecherche, kein Ersatz dafür. Besonders im DACH-Mittelstand mit stark regional geprägten Lieferantenbeziehungen gilt: Ein System kennt die Werkstatt, die seit zwanzig Jahren zuverlässig liefert, nur so gut wie die Daten, die über sie gepflegt wurden.
Anomalie- und Compliance-Erkennung schließlich betrifft die Prüfung von Vorgängen auf Auffälligkeiten: Rechnungen, die doppelt eingereicht wurden, Lieferantenstammdaten mit identischen Bankverbindungen bei unterschiedlichen Namen, ungewöhnliche Häufungen von Bestellungen knapp unterhalb einer Genehmigungsgrenze, Vergaben ohne Wettbewerb in Warengruppen, in denen sonst ausgeschrieben wird. Solche Prüfungen sind ein sinnvoller Baustein interner Kontrollsysteme. Sie erzeugen Hinweise, keine Urteile – jeder Treffer muss von Menschen bewertet werden, und ein System, das zu viele falsche Treffer produziert, wird nach kurzer Zeit ignoriert.
Drei Voraussetzungen entscheiden darüber, ob Automatisierungsfunktionen im eigenen Haus Wirkung entfalten. Die erste ist Datenqualität: Ohne einheitliche Warengruppen, gepflegte Lieferantenstämme und vollständige Bestellbezüge fehlt die Grundlage. Die zweite ist Volumen: Lernende Verfahren brauchen genügend gleichartige Vorgänge, um Muster zu bilden – ein Unternehmen mit wenigen hundert Bestellungen im Jahr wird hier weniger sehen als eines mit einem Vielfachen davon. Die dritte ist Prozessdisziplin: Wenn ein erheblicher Teil der Beschaffung weiterhin an der Plattform vorbeiläuft, bilden alle Analysen nur einen Ausschnitt ab und führen zu falschen Schlüssen.
Zu den Grenzen gehört ein nüchterner Blick auf die Verantwortung. Vergabeentscheidungen, Vertragsabschlüsse und die Bewertung von Lieferantenrisiken sind unternehmerische Entscheidungen mit rechtlichen Folgen. Systemvorschläge können sie vorbereiten, aber nicht ersetzen. Für Unternehmen mit dokumentierten internen Kontrollen empfiehlt sich, ausdrücklich festzuhalten, welche Entscheidungen automatisiert getroffen werden dürfen, welche einen Vorschlag darstellen und wer sie freigibt. Diese Festlegung gehört in die Verfahrensdokumentation und nicht in eine mündliche Verabredung.
Schließlich die Datenschutzseite. Beschaffungsdaten enthalten personenbezogene Daten – Ansprechpartner bei Lieferanten, anfordernde und genehmigende Mitarbeitende, Kommunikationsverläufe. Wenn Auswertungs- oder Sprachfunktionen zum Einsatz kommen, ist zu klären, wo die Verarbeitung stattfindet, ob Daten zur Modellverbesserung genutzt werden, welche Unterauftragnehmer beteiligt sind und wie sich die Nutzung im Verarbeitungsverzeichnis abbildet. Auch die Frage, ob Auswertungen eine Leistungs- oder Verhaltenskontrolle von Mitarbeitenden ermöglichen, gehört früh geprüft – in mitbestimmten Unternehmen ist das ein Thema für den Betriebsrat und keines, das man nachträglich klärt.
Der Regelfall im Umfeld dieser Plattform ist die Anbindung an eine SAP-Landschaft. Dabei sind zwei Richtungen zu unterscheiden. Aus dem ERP fließen Stammdaten in die Beschaffungsplattform: Materialstämme, Warengruppen, Kostenstellen und Innenaufträge für die Kontierung, Organisationsstrukturen wie Einkaufsorganisationen und Werke, Lieferantenstämme mit ihren Zahlungsbedingungen, gegebenenfalls Budgets. In die Gegenrichtung fließen Vorgänge: Bestellanforderungen oder fertige Bestellungen, Bestellbestätigungen, Wareneingangsmeldungen, Rechnungen zur Verbuchung sowie Vertrags- und Konditionsdaten.
Der Aufwand liegt weniger in der technischen Verbindung als in der Abstimmung der Datenmodelle. Warengruppenschlüssel, Einheiten, Steuerkennzeichen, Kontierungsobjekte und Nummernkreise müssen zwischen beiden Systemen konsistent sein, sonst entstehen laufend Fehler bei der Verbuchung. Besonders unterschätzt wird die Frage der Führungshoheit: Wo wird ein neuer Lieferant angelegt, wo eine Bankverbindung geändert, wo eine Warengruppe ergänzt? Ohne eindeutige Festlegung entstehen zwei Wahrheiten, und dann ist nicht mehr klar, welche gilt. Wir empfehlen, diese Zuordnung schriftlich in einer Datenverantwortungsmatrix festzuhalten, bevor die erste Schnittstelle gebaut wird.
Ein zweiter Punkt betrifft die Frage, welcher Prozessschritt wo stattfindet. Es gibt Konstellationen, in denen die Bedarfsanforderung in Ariba entsteht und die Bestellung im ERP erzeugt wird, und andere, in denen die vollständige Bestellabwicklung in der Beschaffungsplattform läuft und das ERP nur die Buchungen erhält. Beide Varianten sind praktikabel, haben aber unterschiedliche Folgen für Berechtigungen, Auswertungen und Fehlersuche. Diese Architekturentscheidung sollte bewusst getroffen und dokumentiert werden, statt sich aus Implementierungsgewohnheiten zu ergeben.
Für die technische Verbindung stellt SAP mit der Business Technology Platform eine Integrationsebene bereit, über die Datenflüsse zwischen Cloud-Anwendungen und ERP-Systemen abgebildet werden. Praktisch bedeutet das: Es gibt vorbereitete Integrationsinhalte für die typischen Objekte, die konfiguriert und an die eigene Landschaft angepasst werden. Für Unternehmen, die ohnehin mit SAP-Integrationswerkzeugen arbeiten, ist das ein vertrauter Weg. Für Unternehmen ohne diese Basis kommt eine zusätzliche Komponente hinzu, die betrieben, überwacht und mit Wissen im Haus begleitet werden muss – ein Punkt, der in Aufwandsschätzungen häufig fehlt.
In gewachsenen Landschaften kommen weitere Wege vor: bestehende Middleware-Plattformen, Integrationsdienste von Drittanbietern oder dateibasierte Verfahren für einzelne Objekte. Alle sind machbar, unterscheiden sich aber in Betriebsaufwand und Fehlertransparenz. Unsere Empfehlung aus Projekten: Legen Sie von Beginn an fest, wie Fehler sichtbar werden. Eine Schnittstelle, die still ausfällt, ist gefährlicher als eine, die laut abbricht. Konkret gehört dazu ein Monitoring mit benannten Zuständigkeiten, eine Wiederaufsetzlogik für fehlgeschlagene Übertragungen und eine regelmäßige Abstimmprüfung, etwa der Abgleich von Belegzahlen zwischen beiden Systemen.
Für den Mittelstand relevant ist die Frage nach Fremd-ERP-Systemen. Der Betrieb einer Beschaffungsplattform ohne SAP im Hintergrund ist grundsätzlich möglich – die Anbindung erfolgt dann über Standardschnittstellen und Datenformate. Realistisch ist aber einzuplanen, dass vorbereitete Integrationsinhalte in erster Linie für die SAP-Welt existieren und dass jede andere Verbindung individueller ausfällt. Wer kein SAP-ERP betreibt, sollte deshalb besonders sorgfältig prüfen, ob der Integrationsaufwand im Verhältnis zum Nutzen steht, und alternative Procurement-Lösungen ernsthaft in den Vergleich nehmen.
Die zweite Integrationsrichtung führt zu den Lieferanten, und hier gibt es im Wesentlichen drei Wege mit unterschiedlichem Aufwandsprofil. Der erste ist die reine Portalnutzung: Der Lieferant meldet sich an einer Weboberfläche an, sieht dort Bestellungen, bestätigt sie und erstellt Rechnungen manuell. Das erfordert auf Lieferantenseite keine Technik, aber Disziplin und Zeit – und funktioniert gut für kleinere Partner mit überschaubarem Belegvolumen, solange die Bedienung einfach bleibt.
Der zweite Weg ist der Dokumentenaustausch über strukturierte Formate. Im Netzwerkumfeld ist cXML das prägende Format für Bestellungen, Bestätigungen, Lieferavise, Kataloge und Rechnungen; daneben spielen klassische EDI-Formate eine Rolle, insbesondere bei Lieferanten, die bereits EDI-Verbindungen zu anderen Kunden betreiben. Für den Punch-out-Zugriff auf Lieferantenshops ist ein definiertes Protokoll erforderlich, das der Lieferant unterstützen muss. Der Aufwand liegt bei ihm – was erklärt, warum größere Lieferanten hier oft bereits vorbereitet sind und kleinere nicht.
Der dritte Weg ist die Anbindung über Dienstleister, die als Konverter zwischen dem eigenen System des Lieferanten und dem Netzwerk arbeiten. Das kommt in Betracht, wenn ein Lieferant zwar elektronisch arbeiten möchte, aber ein anderes Format nutzt. Für die Projektplanung heißt das: Die Lieferantenlandschaft muss vorab segmentiert werden – wer wickelt über Portal ab, wer über strukturierten Austausch, wer über einen Konverter, und wer bleibt vorerst außen vor. Diese Segmentierung ist Kernstück jedes Onboarding-Plans und Thema des Kapitels zur Einführung.
Ein letzter Aspekt betrifft angrenzende Systeme jenseits von ERP und Lieferanten. In der Praxis bestehen Berührungspunkte zu Dokumentenmanagement und Archivierung für Verträge und Rechnungen, zu Qualitätsmanagementsystemen für Lieferantenzertifikate, zu Auskunfteien und Risikodatenanbietern für Bonitäts- und Sanktionsprüfungen sowie zu Identitäts- und Berechtigungsdiensten für die Anmeldung. Jede dieser Verbindungen ist einzeln überschaubar und in Summe ein Projektbestandteil, der geplant gehört. Welche davon als vorbereitete Anbindung existieren und welche individuell entstehen, ist beim Anbieter beziehungsweise beim Implementierungspartner zu klären.
Funktionsmatrizen mit hunderten Zeilen führen in Auswahlprojekten regelmäßig in die Irre, weil nahezu alle etablierten Anbieter nahezu alle Zeilen mit einem Häkchen versehen können. Belastbarer sind wenige Achsen, an denen sich Systeme tatsächlich unterscheiden. Die erste ist die Systemnähe: Wie eng ist die Verzahnung mit dem eigenen führenden ERP, und wie viel Integrationsarbeit entsteht? Wer eine SAP-Landschaft betreibt und deren Weiterentwicklung plant, hat mit einer SAP-eigenen Beschaffungslösung strukturelle Vorteile bei Stammdaten, Belegflüssen und Ansprechpartnern. Wer kein SAP betreibt, verliert genau diesen Vorteil und sollte den Vergleich entsprechend anders gewichten.
Die zweite Achse ist die Lieferantenreichweite. Netzwerkbasierte Modelle spielen ihre Stärke aus, wenn die eigenen Lieferanten dort bereits vertreten sind. Bei international tätigen Zulieferern und großen Handelsunternehmen ist das häufiger der Fall als bei regionalen Handwerks- und Dienstleistungsbetrieben. Eine praktische Vorgehensweise: Nehmen Sie die Lieferanten, die den größten Teil Ihres Ausgabenvolumens abdecken, und prüfen Sie stichprobenhaft, wie diese heute elektronisch mit ihren Kunden arbeiten. Das Ergebnis sagt mehr über den zu erwartenden Onboarding-Aufwand als jede Marktzahl.
Die dritte Achse ist die Bedienbarkeit für Gelegenheitsnutzer. Beschaffungsplattformen werden nicht nur von Einkäufern bedient, sondern von Hunderten Menschen, die einmal im Quartal etwas anfordern. Der Unterschied zwischen Anbietern liegt hier oft weniger im Funktionsumfang als in der Zahl der Klicks bis zum abgeschickten Bedarf. Testen Sie diesen Weg im Auswahlprozess mit echten Anwendern aus Fachbereichen, nicht mit dem Projektteam – Projektteams gewöhnen sich an jede Oberfläche, Fachbereiche nicht.
Die vierte Achse ist der Betreuungs- und Partneraspekt. Wer implementiert, wer betreut nach dem Go-live, wie erreichbar ist der Support, in welcher Sprache, mit welchen Reaktionszeiten? Für mittelständische Unternehmen ohne eigene Procurement-IT ist das häufig der entscheidende Punkt, und er lässt sich nur beantworten, wenn man mit Referenzkunden vergleichbarer Größe spricht – nicht mit den Vorzeigeprojekten aus dem Konzernsegment.
Im deutschsprachigen Raum verschieben sich einige Gewichte gegenüber der internationalen Diskussion. Erstens die Lieferantenstruktur: Viele Mittelständler beschaffen einen erheblichen Teil ihres indirekten Bedarfs bei kleinen, regional verwurzelten Betrieben, die weder EDI betreiben noch Interesse an zusätzlichen Portalen haben. Lösungen, die auf einfache Teilnahme ohne technische Voraussetzungen und ohne spürbare Kosten für den Lieferanten setzen, haben hier einen Akzeptanzvorteil. Das ist einer der Gründe, warum Anbieter mit ausgeprägter Mittelstandsorientierung im DACH-Raum eine starke Stellung halten.
Zweitens die Rechts- und Buchhaltungspraxis. Umsatzsteuerliche Anforderungen, Aufbewahrungspflichten, die Verfahrensdokumentation und die Anbindung an im Mittelstand verbreitete Buchhaltungswege sind Themen, an denen international konzipierte Lösungen zusätzlichen Anpassungsaufwand erzeugen können. Drittens die Mitbestimmung: Die Einführung von Systemen, die Arbeitsvorgänge protokollieren, ist in Unternehmen mit Betriebsrat ein Beteiligungsthema. Wer das früh einplant, gewinnt Zeit; wer es übergeht, verliert sie doppelt.
Viertens die Sprach- und Dokumentationslage. Deutschsprachige Oberflächen, Hilfetexte, Vertragsunterlagen und Schulungsmaterialien sind kein Luxus, wenn Lagerpersonal, Werkstattleitung und Verwaltungskräfte das System bedienen sollen. Auch die Frage, in welcher Sprache Lieferanten angesprochen werden, gehört bedacht. Diese Punkte tauchen in Analystenberichten selten auf und entscheiden in Projekten regelmäßig über Akzeptanz.
Aus unserer Projektpraxis lassen sich drei Muster ableiten, die die Auswahl erleichtern. Erstes Muster: Unternehmen mit gewachsener SAP-Landschaft, laufender oder geplanter Transformation nach S/4HANA und einem Einkauf, der über mehrere Standorte oder Länder arbeitet. Hier ist die SAP-eigene Beschaffungsplattform eine naheliegende Option, weil Integration, Stammdaten und Roadmap zusammenlaufen – vorausgesetzt, das Lieferantenprofil passt zum Netzwerkmodell.
Zweites Muster: Mittelständler ohne SAP, mit überwiegend regionalen Lieferanten und einem Einkauf von wenigen Personen, der vor allem operative Entlastung sucht. Hier ist eine schlankere, mittelstandsorientierte Lösung häufig die wirtschaftlichere Wahl, weil Einführungsdauer, Betreuungsaufwand und Lieferantenakzeptanz die Funktionsbreite überwiegen. Drittes Muster: Unternehmen mit sehr spezifischen, nicht standardisierbaren Beschaffungsprozessen – etwa in stark regulierten Branchen oder bei projektbezogener Beschaffung. Hier zählt Konfigurierbarkeit stärker als Netzwerkreichweite, und der Vergleich verschiebt sich entsprechend.
Was in allen drei Mustern gilt: Die Entscheidung sollte nicht auf einer Funktionsliste beruhen, sondern auf drei bis fünf realen Prozessbeispielen aus dem eigenen Haus, die jeder Anbieter im System zeigen muss – vom Bedarf bis zur Rechnung, mit den eigenen Sonderfällen. Ein Vergleich, der auf dieser Grundlage entsteht, ist belastbar. Ein Vergleich, der auf Werbematerial beruht, ist es nicht.
Wenn Projekte mit dieser Art von Plattform scheitern oder sich verzögern, liegt es in unserer Erfahrung selten an der Software und fast immer am Onboarding. Der Grund ist einfach: Das einkaufende Unternehmen trifft die Entscheidung, aber der Aufwand entsteht zu einem erheblichen Teil bei Dritten, die nicht weisungsgebunden sind. Ein Lieferant muss sich registrieren, Stammdaten pflegen, Nachweise hochladen, gegebenenfalls einen Katalog aufbereiten, Mitarbeitende schulen und seine internen Abläufe anpassen – für einen Kunden unter vielen.
Daraus folgt ein Vorgehen, das über den Erfolg entscheidet. Erstens Segmentierung nach Wichtigkeit: Die Lieferanten, die den Großteil des Ausgabenvolumens abdecken, werden persönlich betreut, nicht per Serienmail. Zweitens ein klares Nutzenargument aus Lieferantensicht – schnellere Rechnungsfreigabe, weniger Rückfragen, planbare Zahlungsläufe, verbindliche Bestelldaten. Drittens ein realistischer Zeitplan mit Wellen statt eines Stichtags für alle. Viertens eine Eskalationslogik, die klärt, was passiert, wenn ein Lieferant nicht mitzieht: Wird er weiterhin klassisch abgewickelt, wird eine Übergangsfrist gesetzt, oder wird die Zusammenarbeit überprüft? Diese Frage sollte beantwortet sein, bevor sie zum ersten Mal akut wird.
Ein häufiger Fehler ist, die Ansprache dem Einkauf zusätzlich zum Tagesgeschäft aufzuladen. Onboarding ist ein eigenes Arbeitspaket mit eigener Kapazität. In Projekten, die gut laufen, gibt es eine benannte Person, die nichts anderes tut, als Lieferanten zu betreuen, Rückfragen zu beantworten, Registrierungen nachzuhalten und Kataloge zu prüfen – befristet, aber mit klarem Auftrag. In Projekten, die schlecht laufen, macht das jemand nebenbei.
Ein Punkt, der im deutschsprachigen Mittelstand besondere Aufmerksamkeit verdient, ist die Kostenseite auf Lieferantenseite. Netzwerkbasierte Modelle sehen in bestimmten Konstellationen Gebühren für teilnehmende Lieferanten vor, abhängig etwa von Transaktions- oder Belegvolumen und vom genutzten Funktionsumfang; daneben existieren typischerweise kostenfreie Basiszugänge mit eingeschränktem Umfang. Konkrete Modelle, Schwellen und Beträge ändern sich und sind ausdrücklich beim Anbieter zu prüfen – wir nennen hier bewusst keine Zahlen.
Wichtiger als die Höhe ist die Wirkung. Für einen international tätigen Zulieferer, der über mehrere Netzwerke abwickelt, sind solche Kosten kalkulierbare Vertriebsausgaben. Für einen regionalen Handwerksbetrieb mit wenigen Rechnungen im Jahr an diesen einen Kunden kann dieselbe Anforderung als Zumutung wirken – und die Reaktion reicht von Widerspruch über Preisaufschläge bis zur Ablehnung der weiteren Zusammenarbeit. In Ausschreibungen taucht dieses Thema als Nachfrage auf, und wer darauf keine Antwort hat, verliert Verhandlungsposition.
Unsere Empfehlung: Behandeln Sie die Frage im Auswahlprozess als eigenes Kriterium und nicht als Detail der Vertragsverhandlung. Klären Sie beim Anbieter, welche Modelle für welche Lieferantengrößen gelten, welche Zugänge ohne Kosten nutzbar sind und wie sich das für Ihre konkrete Lieferantenstruktur auswirkt. Rechnen Sie die Konsequenz durch: Wenn ein Teil der Lieferanten nicht elektronisch abwickelt, bleiben Parallelprozesse bestehen – und Parallelprozesse sind der teuerste Zustand, weil zwei Wege gepflegt werden müssen. Manchmal ist die richtige Antwort, für bestimmte Lieferantensegmente bewusst bei einem einfacheren Verfahren zu bleiben und den Anspruch auf Vollabdeckung aufzugeben.
Nach dem Go-live beginnt die Arbeit, die dauerhaft anfällt. An erster Stelle steht die Katalogpflege: Preise ändern sich, Artikel entfallen, neue Produkte kommen hinzu, Lieferanten liefern aktualisierte Dateien in wechselnder Qualität. Ohne feste Zuständigkeit und ohne Prüfroutine veralten Kataloge innerhalb weniger Monate, und veraltete Kataloge sind schlimmer als keine – sie erzeugen falsche Erwartungen, Rückfragen und Rechnungsdifferenzen. Praktisch bewährt hat sich eine feste Kadenz je Lieferant, eine automatisierte Plausibilitätsprüfung auf auffällige Preissprünge und eine Freigabe durch den zuständigen Einkäufer statt eines ungeprüften Imports.
An zweiter Stelle stehen die Klärungsfälle. Jeder Vorgang, den die Automatik nicht durchlaufen lässt, landet in einer Liste: Rechnungen ohne Bestellbezug, Mengenabweichungen, fehlende Wareneingänge, abgelaufene Nachweise, Bedarfe ohne gültige Kontierung. Diese Listen gehören täglich bearbeitet, mit klarer Zuständigkeit und mit einer regelmäßigen Ursachenanalyse: Welche Fehlerart tritt am häufigsten auf, und was ist ihre strukturelle Ursache? Ein Klärungsfall, der zehnmal im Monat aus demselben Grund entsteht, ist kein Bearbeitungsproblem, sondern ein Konfigurations- oder Stammdatenproblem.
An dritter Stelle steht die Steuerung über Kennzahlen. Sinnvoll sind wenige, die tatsächlich verfolgt werden: der Anteil des Ausgabenvolumens, der über die Plattform läuft, der Anteil der Bestellungen mit Vertragsbezug, der Anteil automatisch verarbeiteter Rechnungen, die Durchlaufzeit vom Bedarf bis zur Bestellung, die Zahl offener Klärungsfälle und der Anteil qualifizierter Lieferanten mit gültigen Nachweisen. Diese Kennzahlen zeigen, ob die Plattform ihren Zweck erfüllt – und sie sind die einzige belastbare Grundlage für die Entscheidung, ob weitere Bausteine oder Ausrollungswellen sinnvoll sind.
Nicht zu vergessen ist der Umgang mit Änderungen auf Anbieterseite. In einem Cloud-Modell bestimmt der Anbieter Versionsstände und Wartungsfenster. Neue Funktionen kommen, Oberflächen ändern sich, gelegentlich entfallen Optionen. Dafür braucht es eine benannte Person, die Release-Informationen liest, Auswirkungen bewertet und Anpassungen anstößt – und, wo verfügbar, eine Testumgebung, in der Änderungen vor dem produktiven Einsatz geprüft werden. Ob und in welcher Form eine solche Umgebung bereitsteht, ist beim Anbieter zu klären.
Ein einfacher, aber tragfähiger Prüfansatz: Multiplizieren Sie die Zahl Ihrer Beschaffungsvorgänge pro Jahr mit dem geschätzten Bearbeitungsaufwand je Vorgang – von der Anforderung über die Bestellung bis zur Rechnungsprüfung, einschließlich Rückfragen. Stellen Sie dem den erwarteten Anteil gegenüber, der sich durch Katalogbeschaffung, Genehmigungsworkflows und automatischen Rechnungsabgleich ohne Handarbeit erledigen ließe. Diese Rechnung ist grob, aber sie zeigt schnell, ob überhaupt eine relevante Größenordnung im Spiel ist. Ergänzen Sie sie um den zweiten Nutzenblock: den Anteil der Ausgaben, der heute an Verträgen vorbeiläuft, und den Preisvorteil, der bei konsequenter Vertragsnutzung realisierbar wäre.
Deutlich für eine vollwertige Plattform spricht es, wenn mehrere der folgenden Punkte zutreffen: Es wird an mehreren Standorten oder in mehreren Ländern beschafft. Es gibt eine dreistellige Zahl aktiver Lieferanten oder mehr. Ein großer Teil der Belege betrifft wiederkehrende Standardbedarfe. Der Einkauf soll strategisch arbeiten, ist aber mit operativer Abwicklung ausgelastet. Es bestehen dokumentierte Nachweispflichten gegenüber Kunden, Zertifizierern oder Gesetzgeber. Es läuft ohnehin eine ERP-Transformation, in deren Rahmen Prozesse neu geschnitten werden. Und schließlich: Es existiert eine benannte Person, die den Einkaufsprozess fachlich verantwortet – ohne diese Rolle ist jede Plattform ein Softwareprojekt ohne Eigentümer.
Ein weiterer Aspekt betrifft die Perspektive. Eine Beschaffungsplattform ist eine Investition mit langem Horizont; der Nutzen entsteht über Jahre durch Prozessdisziplin, nicht in den ersten Monaten durch Funktionsumfang. Unternehmen, die einen schnellen, sichtbaren Effekt brauchen, sollten den Einstieg entsprechend zuschneiden – etwa auf eine Warengruppe mit hoher Belegmenge – statt einen Vollausbau zu planen, dessen Wirkung erst nach zwei Jahren messbar wird.
Es gibt gute Gründe, sich bewusst gegen eine große Suite zu entscheiden. Wenn die Beschaffung überwiegend aus wenigen, großen Vorgängen besteht, deren Vorbereitung ohnehin individuell erfolgt, bringt Prozessautomatisierung wenig. Wenn die Lieferantenstruktur stark regional geprägt ist und die Partner elektronische Abwicklung weder anbieten noch akzeptieren, bleibt ein erheblicher Teil des Nutzens unerreichbar. Wenn der Einkauf aus zwei Personen besteht, die sich abstimmen können, ohne ein System zu befragen, ist der organisatorische Nutzen begrenzt. Und wenn das eingesetzte ERP bereits eine solide Bestell- und Rechnungsprüfungsfunktion mitbringt, die schlicht nicht konsequent genutzt wird, liegt das Problem nicht in fehlender Software.
Für solche Konstellationen kommen schlankere Wege in Betracht: eine konsequentere Nutzung der Beschaffungsfunktionen des vorhandenen ERP, eine spezialisierte Lösung für den Bereich mit dem größten Leidensdruck – etwa Rechnungseingangsverarbeitung oder Vertragsverwaltung –, oder eine mittelstandsorientierte Beschaffungslösung mit geringerem Einführungsaufwand. Wichtig ist, diese Alternativen im Auswahlprozess ernsthaft zu prüfen und nicht als Verlegenheitslösung zu behandeln. Die teuerste Entscheidung ist regelmäßig nicht die falsche Software, sondern eine richtige Software in einem Unternehmen, das die Voraussetzungen für ihre Nutzung nicht mitbringt.
Ein dritter Weg, der in der Praxis oft übersehen wird: die schrittweise Vorbereitung. Warengruppen vereinheitlichen, Lieferantenstämme bereinigen, Rahmenverträge erfassen, Ausgabenanalysen aufbauen – all das lässt sich mit vorhandenen Mitteln beginnen und zahlt unabhängig davon ein, für welche Plattform man sich später entscheidet. Unternehmen, die diese Vorarbeit geleistet haben, führen anschließend deutlich schneller ein und mit weniger Reibung.
Die Gesamtkosten entstehen aus vier Blöcken, die nur gemeinsam ein Bild ergeben. Der erste ist die Subskription für die genutzten Bausteine, in aller Regel jährlich und an Kennzahlen gestaffelt. Der zweite ist der Einführungsaufwand: externe Beratung, Konfiguration, Integration in die bestehende Systemlandschaft, Datenbereinigung, Schulung, Projektsteuerung. Der dritte ist der interne laufende Aufwand für Katalogpflege, Lieferantenbetreuung, Klärungsfälle und Weiterentwicklung. Der vierte ist die Netzwerkseite: Auch wenn Gebühren dort nicht das eigene Unternehmen treffen, wirken sie auf Preise, Verhandlungen und Akzeptanz zurück.
Für die Gegenrechnung eignen sich vier Nutzengrößen, die sich mit vorsichtigen Annahmen beziffern lassen. Erstens die Prozesskosten je Beschaffungsvorgang, die durch Katalogbeschaffung und automatischen Rechnungsabgleich sinken. Zweitens der Preisvorteil aus höherer Vertragstreue: Ausgaben, die heute an Rahmenverträgen vorbeilaufen, werden zu verhandelten Konditionen abgewickelt. Drittens die Bündelungseffekte, die erst durch Ausgabentransparenz sichtbar werden. Viertens die vermiedenen Kosten aus Fehlern und Nacharbeit – Doppelzahlungen, falsche Preise, verspätete Reklamationen, verpasste Kündigungsfristen. Rechnen Sie diese vier Größen konservativ und über drei Jahre; eine Rechnung, die nur bei optimistischen Annahmen aufgeht, geht nicht auf.
Zwei Warnhinweise aus der Praxis. Erstens: Angebotsvergleiche zwischen Anbietern sind selten direkt möglich, weil Preismodelle an unterschiedlichen Größen ansetzen – Nutzer, Belege, Ausgabenvolumen, Bausteine. Schreiben Sie Ihr Mengengerüst auf und lassen Sie jeden Anbieter genau dieses bepreisen, einschließlich der erwarteten Entwicklung. Zweitens: Der Einführungsaufwand wird regelmäßig unterschätzt, weil die Angebotskalkulation von idealen Stammdaten ausgeht. Fragen Sie ausdrücklich, welche Annahmen zur Datenqualität dem Angebot zugrunde liegen, und lassen Sie sich zeigen, was passiert, wenn diese Annahmen nicht zutreffen.
Dass der Anbieter seinen Sitz in Deutschland hat, ist ein Ausgangspunkt, ersetzt aber keine Prüfung. Cloud-Dienste großer Anbieter werden auf verteilter Infrastruktur betrieben, häufig unter Beteiligung mehrerer Konzerngesellschaften und Dienstleister. Zu klären ist deshalb konkret: In welchem Rechenzentrum werden die Daten verarbeitet und gespeichert? Besteht die Möglichkeit, die Verarbeitung auf europäische Standorte zu begrenzen? Welche Support- und Administrationszugriffe erfolgen aus welchen Ländern, und wie sind sie abgesichert? Welche Unterauftragnehmer sind beteiligt, und wie wird über Änderungen informiert? Diese Fragen gehören schriftlich beantwortet und in die eigene Dokumentation übernommen.
Der zweite Aspekt der Datenhoheit ist die Ausstiegsfähigkeit. Eine Beschaffungsplattform sammelt über Jahre wertvolle Daten: Lieferantenstämme mit Qualifizierungshistorie, Vertragsdaten mit Konditionen, Vergabedokumentationen, Belegverläufe, Ausgabenanalysen. Wer diese Daten am Vertragsende nicht vollständig und in verwertbarer Struktur zurückerhält, hat ein Abhängigkeitsproblem. Sichern Sie deshalb vertraglich zu, welche Datenobjekte in welchem Format und in welcher Frist exportiert werden können, und testen Sie diesen Export einmal während der Laufzeit – nicht erst, wenn er gebraucht wird. Dasselbe gilt für Archivierungspflichten: Rechnungen und Verträge unterliegen Aufbewahrungsfristen, die über die Laufzeit eines Softwarevertrags hinausreichen können.
Ein dritter Punkt betrifft die Rollenverteilung im Datenschutz. Ein Softwareanbieter verarbeitet die Daten seiner Kunden typischerweise nach deren Weisung, sodass eine Auftragsverarbeitung vorliegt; verantwortlich bleibt das einsetzende Unternehmen. Bei Netzwerkmodellen ist die Betrachtung differenzierter, weil der Netzwerkbetreiber gegenüber den teilnehmenden Lieferanten eine eigene Rolle einnehmen kann. Diese Konstellation gehört mit dem eigenen Datenschutzbeauftragten geprüft und in Verarbeitungsverzeichnis und Datenschutzinformation abgebildet.
Ein Grund, aus dem Unternehmen ihr Lieferantenmanagement strukturieren, sind gewachsene Sorgfaltspflichten in der Lieferkette. Das deutsche Lieferkettensorgfaltspflichtengesetz verpflichtet Unternehmen ab bestimmten Größenordnungen unter anderem zu Risikoanalysen, Präventionsmaßnahmen, Beschwerdeverfahren und Dokumentation. Auf europäischer Ebene wirkt die Richtlinie über die Sorgfaltspflichten von Unternehmen im Bereich der Nachhaltigkeit in dieselbe Richtung, mit eigener Ausgestaltung und eigenen Fristen. Der genaue Anwendungsbereich, die Schwellenwerte und der Zeitplan sind Gegenstand fortlaufender Rechtsentwicklung; die verbindliche Bewertung des eigenen Falls gehört zur Rechtsberatung.
Praktisch relevant ist der mittelbare Effekt: Auch Unternehmen, die selbst nicht unmittelbar verpflichtet sind, erhalten Anforderungen von größeren Kunden weitergereicht – in Form von Fragebögen, Verhaltensgrundsätzen, Nachweisen und Auditzusagen. Für viele Mittelständler ist das inzwischen ein regelmäßiger Aufwand, der bislang in Tabellen und E-Mail-Verläufen bewältigt wird. Genau hier kann ein Lieferantenmanagementsystem einen belegbaren Beitrag leisten: strukturierte Selbstauskünfte, Verhaltensgrundsätze mit dokumentierter Zustimmung, Zertifikate mit Gültigkeitsdaten und automatischer Nachverfolgung, Risikoeinstufungen je Warengruppe und Region, dokumentierte Maßnahmen bei Auffälligkeiten sowie ein nachvollziehbarer Verlauf, wer wann was geprüft hat.
Was ein System dabei nicht leistet, gehört ebenso klar benannt. Es ersetzt weder die eigene Risikoanalyse noch die fachliche Bewertung, weder das Beschwerdeverfahren noch die Berichterstattung, und es garantiert keine Rechtskonformität. Ein System schafft die Datengrundlage und die Nachvollziehbarkeit – die Beurteilung, welche Risiken in der eigenen Lieferkette bestehen und welche Maßnahmen angemessen sind, bleibt eine unternehmerische und rechtliche Aufgabe. Wer eine Software mit dem Versprechen kauft, damit Sorgfaltspflichten zu erfüllen, kauft eine Illusion; wer sie kauft, um Nachweise strukturiert führen zu können, kauft ein Werkzeug.
Für die praktische Umsetzung hat sich ein risikobasiertes Vorgehen bewährt: Lieferanten nach Warengruppe, Beschaffungsregion und Kritikalität einstufen, für jede Stufe festlegen, welche Nachweise verlangt werden, diese Anforderungen in den Qualifizierungsprozess einbauen und die Erfüllung automatisch überwachen. Wichtig ist die Verbindung zum operativen Prozess: Ein Lieferant ohne gültige Qualifizierung sollte im Bestellprozess sichtbar sein – ob als Warnung oder als Sperre, ist eine Festlegung, die zur eigenen Risikopolitik passen muss. Ohne diese Verknüpfung bleibt Lieferantenmanagement eine Dokumentensammlung neben dem eigentlichen Geschäft.
