Eine moderne Einkaufsplattform vor SAP

1Ausgangslage

Der Einkauf läuft heute über eine Anwendung, die auf Infor Mongoose gebaut wurde. Mongoose ist keine Einkaufslösung, sondern Infors Entwicklungsplattform: ein Werkzeugkasten, mit dem Unternehmen eigene Anwendungen aus Metadaten, Formularen und sogenannten IDOs zusammensetzen. Das ist eine wichtige Unterscheidung, weil sie erklärt, warum ein Wechsel ansteht.

• Es gibt keinen Produktstandard, der sich einfach aktualisieren ließe. Was die Anwendung kann, wurde einmal gebaut. Jede Verbesserung ist ein Entwicklungsauftrag, kein Versionssprung.
• Die Oberfläche folgt der Plattform, nicht dem Einkäufer. Formulare und Tabellenraster sind die natürliche Ausdrucksform von Mongoose. Eine Suchoberfläche, die sich wie ein Webshop anfühlt, ist damit möglich, aber teuer.
• Einkaufsfachlichkeit fehlt im Kern. Rahmenvertragserkennung, PunchOut nach OCI, Katalognormalisierung, Lieferantenbewertung – all das müsste eigens entwickelt und dauerhaft gepflegt werden.
• Das Wissen hängt an wenigen Köpfen. Der Markt für Mongoose-Entwickler ist klein. Das ist ein Betriebsrisiko, das mit den Jahren wächst.

Die Ablösung ist deshalb keine Technikfrage, sondern eine Produktfrage: An die Stelle einer gewachsenen Eigenentwicklung soll ein wiederverwendbares Produkt treten, das sich aktualisieren lässt, ohne dass jemand den ursprünglichen Bauplan im Kopf haben muss.

2Zielbild

Eine herstellerunabhängige Einkaufsplattform, die sich für Anwender wie ein Webshop anfühlt, im Hintergrund aber sauber mit SAP zusammenarbeitet. SAP bleibt führend für Stammdaten, Kontierung und operative Belege. Die neue Plattform übernimmt Suche, Führung durch den Einkauf, Kataloge, Regeln, Freigaben, Lieferanteninteraktion und später weitere Source-to-Pay-Bausteine.

Der Kern des Nutzens liegt in fünf Sätzen, die heute in vielen Konzernen nicht gleichzeitig wahr sind: schnell finden, richtig kaufen, Vertrag nutzen, korrekt kontieren, sauber an SAP übergeben.

3Warum nicht SAP nachbauen

Ein vollständiger Ariba-Funktionsumfang ab Tag eins wäre unnötig riskant und würde das Vorhaben in genau die Schwergewichtigkeit führen, die es vermeiden soll. Ebenso wenig sinnvoll ist es, Buchhaltungs- oder Bestandslogik nachzubauen. Die Abgrenzung lautet:

4Erster Produktumfang: Katalog mit SAP-Anbindung

Der erste sinnvolle Produktumfang ist ein zentraler Einkaufskatalog. Mitarbeiter suchen Artikel und Leistungen, legen sie in einen Warenkorb, ergänzen die Kontierung und übergeben den Bedarf an SAP. Die bestehende SAP-Prozesslandschaft bleibt damit unverändert, während die Oberfläche deutlich einfacher wird.

Die fünf Beschaffungswege

Der Ablauf, den der Prototyp zeigt

Schritte 1 bis 6 laufen im Prototyp vollständig. Schritte 7 und 8 sind Attrappen: Sie zeigen die erzeugte Nutzlast und beschreiben, was der Connector täte.

5SAP-Integration

Die Integrationsschicht wird bewusst vom Frontend und von der Fachlogik getrennt. Dadurch kann dieselbe Plattform unterschiedliche SAP-Landschaften bedienen – ECC, S/4HANA On-Premise oder Cloud-Szenarien – ohne dass der Produktkern kundenspezifisch wird.

6Umfang des MVP

Der MVP ist bewusst kein vollständiger Ariba-Klon, sondern ein produktiv nutzbares Guided-Buying- und Katalogsystem mit sauberer SAP-Integration.

7Ausbau zu Source-to-Pay

Ein echter Ariba-Ersatz ist wesentlich mehr als ein Katalog. Sinnvoll ist deshalb eine modulare Plattform, bei der Kunden nur die benötigten Bausteine aktivieren.

8Unterscheidungsmerkmale

Ein Katalog allein ist austauschbar. Die folgenden sechs Funktionen sind der Grund, warum sich das Produkt gegen eine Suite und gegen einen Eigenbau durchsetzen kann. Vier davon zeigt der Prototyp bereits.

Lieferantenübergreifende Produktsuche im Prototyp

Ein Suchbegriff zeigt Vertragsartikel, Alternativen, Lieferzeiten und Preise verschiedener Quellen nebeneinander – mit Materialnummer, Warengruppe, Kreditor und Vertragsbezug in derselben Zeile. Rahmenverträge und bevorzugte Lieferanten stehen oben, nicht weil sie zufällig billiger sind, sondern weil das Regelwerk es so vorgibt.

Bedarf in eigenen Worten im Prototyp

Der Anwender schreibt „Ich brauche fünf robuste Akkuschrauber für Werk 1000“. Das System übersetzt den Satz in Menge, Werk und Suchbegriffe, zeigt sichtbar, wie es den Satz gelesen hat, und begründet jeden Vorschlag. Entscheidend ist nicht die Sprachverarbeitung, sondern dass die anschließende Reihenfolge regelbasiert und nachvollziehbar bleibt – sonst ist sie im Konzernumfeld nicht genehmigungsfähig.

Automatische Kontierung im Prototyp

Aus Warengruppe, Benutzer, Kostenstelle, Werk und historischen Regeln entsteht ein Kontierungsvorschlag. Vor der Übergabe wird geprüft, ob das Sachkonto zur Warengruppe passt – im Portal, nicht erst beim Buchen in SAP.

Schutz vor Einkauf am Vertrag vorbei im Prototyp

Nicht bevorzugte Lieferanten, fehlende Verträge, ungewöhnliche Preise und günstigere Rahmenvertragsartikel werden vor dem Kauf gemeldet, mit einem Knopf zur Lösung. Bewusst als Hinweis, nicht als Sperre: Verbote werden umgangen, Hinweise mit einer Ein-Klick-Alternative werden befolgt.

Erkennung ungenutzter Verträge im Prototyp

Das System prüft, ob vorhandene Verträge genutzt werden und ob die Katalogpreise den hinterlegten Konditionen entsprechen. Ein Vertrag mit 22 % Rabatt, dessen Katalogpreis nur 19 % abbildet, fällt sonst niemandem auf – im Prototyp erscheint er als Befund mit Betragsangabe.

Katalognormalisierung späterer Ausbau

Unterschiedliche Lieferantenbeschreibungen, Einheiten und Kategorien werden vereinheitlicht, Dubletten und vergleichbare Produkte erkannt. Das ist die Voraussetzung dafür, dass die lieferantenübergreifende Suche mit echten Katalogdaten so gut funktioniert wie mit gepflegten.

9Technische Architektur

Eine modulare Architektur verhindert, dass aus dem Produkt ein unwartbarer SAP-Sonderbau wird. Von oben nach unten gelesen: Die Oberfläche kennt keinen SAP-Feldnamen, der Kern kennt keine Kundenlandschaft, und nur die unterste eigene Schicht spricht mit fremden Systemen.

Mandantenfähigkeit

Strikt getrennte Daten je Mandant, mit kundenspezifischem Erscheinungsbild, Regelwerk, Katalogen, SAP-Zuordnungen und Rollen. Für große Kunden bleibt eine eigene Instanz möglich – das ist bei Konzernen regelmäßig Voraussetzung für die Freigabe durch die Informationssicherheit.

10Datenmodell

Die zentralen Objekte: Mandant, Benutzer, Rolle, Gesellschaft, Einkaufsorganisation, Werk, Kostenstelle, Sachkonto, PSP-Element, Lieferant, Katalog, Katalogposition, Material, Vertrag, Preiskondition, Warenkorb, Anforderung, Freigabe, Bestellbezug, Ausschreibung, Angebot, Wareneingangsbezug, Rechnungsbezug, Protokolleintrag.

11Fahrplan

Zeitangaben für ein kleines, eingespieltes Team. Sie beschreiben Entwicklungsdauer, nicht Einführungsdauer beim Kunden – die hängt an Stammdatenqualität und Abstimmungswegen, nicht an Technik.

12Aufwand und Einführung

Die Schnittstellen sind der Teil, den Fachbereiche unterschätzen und IT-Abteilungen zuerst bewerten. Deshalb hier die Einzelschätzungen, wie sie auch im Prototyp hinter jeder Schnittstellenkarte stehen:

13Risiken und wie man sie klein hält

14Positionierung und Geschäftsmodell

Eine schlanke, moderne Einkaufsplattform für SAP-Kunden: schneller einführbar als große Source-to-Pay-Suiten, modular, schnittstellenoffen, mit besonders starkem Fokus auf Katalog und geführten Einkauf.

Daraus ergeben sich zwei Erlösmodelle, die sich nicht ausschließen: als Mietmodell mit monatlicher Lizenz je Nutzer und Mandant, oder als Plattform plus Einführungsprojekt für SAP-Integration, Katalogaufnahme, Anpassung und Prozessberatung. Das zweite trägt den Anfang, das erste trägt die Jahre danach.

15Empfehlung für den Start

Der klickbare Prototyp liegt vor. Der nächste Schritt ist nicht mehr Entwurf, sondern Nachweis:

• Einen konkreten SAP-Testprozess vereinbaren. Benutzer anmelden → Artikel suchen → Warenkorb → Kontierung → Freigabe → BANF in SAP. Ein Werk, eine Warengruppe, ein Lieferant.
• Die drei Schnittstellen bauen, die der Nachweis braucht: Stammdaten lesen, Bedarfsanforderung übergeben, Status zurückmelden. Zusammen 14–21 Personentage.
• Technische Benutzer und Berechtigungen in SAP sofort beantragen – das ist der längste Terminblocker und hängt nicht vom Entwicklungsfortschritt ab.
• Parallel die Zuordnung Warengruppe zu Sachkonto mit dem Rechnungswesen klären. Ohne sie funktioniert die automatische Kontierung nicht, und mit ihr entfällt der häufigste Grund für Umbuchungen.

Wenn dieser Weg von Anfang bis Ende stabil läuft, ist die technische Grundlage für alle weiteren Module gelegt – und aus einer Kundenlösung wird ein Produkt.