Ein Mitarbeiter benötigt ein neues Netzteil für sein Notebook. Bis es auf seinem Tisch liegt, ist die Anzahl der einzelnen Bestellprozess-Schritte immens: Laut Studie von Pricewaterhouse-Coopers umfasst ein derartiger Ablauf durchschnittlich 22 Schritte, dauert 15 Tage und kostet 108 bis 248 Mark - Produktkosten nicht eingerechnet. Elektronisches Bestellen, so genanntes E-Procurement, soll Abhilfe schaffen.

Pricewaterhouse-Coopers schätzt, dass sich der traditionelle Beschaffungsprozess dank E-Procurement auf durchschnittlich noch zwölf Schritte reduziert, sieben Stunden dauert und nur noch ein Fünftel, nämlich zwischen 31 bis 52 Mark, kostet. Für viele Unternehmen könnten also deutliche Einsparungspotenziale in der elektronischen Beschaffung versteckt sein. Typischerweise gilt das vor allem für standardisierte Betriebsgüter (MRO = Maintenace Repair and Operating).

Vor allem Kosten reduzierenDie Motive der Käufer beim E-Procurement sind klar: Sie wollen zuerst und vor allem Kosten reduzieren. Das geht nur über geglättete und fehlerfreie Prozesse, Konditionsverbesserungen durch Aggregation des Einkaufsvolumens sowie kräftige Reduktion der Lagerbestände. Aber auch ein Mehr an Transparenz und Kontrolle über die Beschaffungsvorgänge scheint erstrebenswert. Eine höhere Integration kann zudem Doppelerfassungen und Medienbrüche erheblich vermindern.

Auch den Verkäufern bieten sich große Vorteile: Sie erhalten Zugang zu neuen Kunden. Nicht zuletzt lassen sich durch eine höhere Integration in ihre Backend-Systeme wiederum Kosten senken und die Qualität der Prozesse erhöhen.

Aus technischer Sicht handelt es sich bei E-Procurement um eine Bestellabwicklung, welche die Lieferanten, zumindest was den Datenfluss betrifft, in das entsprechende System einbindet. Gegenwärtig werden hauptsächlich solche Systeme betrachtet, die den Web-Browser zugleich als Benutzerschnittstelle definieren und bei denen die Integration in verschiedenste Lieferantensysteme auf Basis von frei verfügbaren und stark verbreiteten Internet-Technologien stattfinden kann.

Das Kernstück im System des Käufers bildet der Procurement-Server, der die erworbene oder lizenzierte Software abbildet. Mittels der verfügbaren Applikationen lassen sich alle für den Einkauf notwendigen Daten und Prozesse verwalten sowie die Abwicklung und Auswertung der einzelnen Einkaufsprozesse vereinfa-chen. Darüber hinaus werden hier auch die Schnittstellen zu den relevanten Informationssystemen des Käufers gelegt. Das System selbst verwaltet Bewegungsdaten, Definitionen der Beschaffungsworkflows, Tabellen zur Datenkonversion sowie Angaben zu offenen und ausgeführten Beschaffungen. Zudem wird es mit Daten zum Angebot und mit aktuellen Preisen gespeist. Die Nutzung eines solchen Systems ist in der Regel einfach: Sie erfolgt über eine Browser-Schnittstelle, die das Rollout der Applikation auf das ganze Unternehmen ermöglicht.

Hubs übersetzen die DatenBei zunehmender Komplexität der Kataloginformationen wie beispielsweise bei konfigurierbaren Artikeln, bei kritischen Verfügbarkeitsinformationen oder spezifischen Nettopreisen mit komplexen Rabattstrukturen kommt es zu einem typischen Bruch dieser Architektur. Erst über einen "Roundtrip" oder durch einen "Punch-Out" auf einen Server des Lieferanten kann dann ein wesentlicher Teil des Beschaffungsvorganges abgewickelt werden. Um möglichst viele Systeme auf der Verkaufsseite unterstützen zu können, bedarf es eines hohen Maßes an Unabhängigkeit von Lieferantensystemen. Das lässt sich über eine Abstraktionsebene zwischen den Systemen gewährleisten: Als so genannte Hubs übersetzen derartige Systeme alle ausgetauschten Daten zwischen Käufer und Lieferant in nutzbare Formate, sorgen aber auch dafür, dass Transaktionsdetails der entsprechenden Gegenpartei unbekannt bleiben.

Auf der Lieferantenseite sind die Schnittstellen so vielfältig wie möglich ausgestaltet: Der Hub, das unterstützende Abwicklungssystem, weist einen eingehenden Kaufauftrag mehreren Lieferanten zu und übersetzt die zugewiesenen Daten in die Formate der Lieferanten. Dabei sind nicht nur das "klassische" EDI möglich, sondern auch XML-basierende Formate, Fax, E-Mail oder die Benutzung des Systems über einen Webbrowser. Andere typische Architekturvarianten sind zum Beispiel der Betrieb des Procurement-Servers durch ein Partnerunternehmen, die "Hosted Buysite", oder die vollständige Abwicklung über den Hub. In einem solchen Fall handelt es sich dann um elektronische Marktplätze.

Es werden mehrere Ebenen integriertIm Wesentlichen werden zwischen Käufer- und Lieferantensystemen an vorderster Stelle Produkt- und Leistungsdetails ausgetauscht, dicht gefolgt von Auftragserteilungen, Bestätigungen, Änderungen, Statusberichten, Antworten auf Anfragen und Versandbenachrichtigungen. Lediglich Rechnungen und Zahlungsvorgänge sind heute noch nicht implementiert.

Bleibt die Kommunikation zwischen den interagierenden Systemen: Schließlich werden dort mehrere Ebenen integriert - sprich der Datentransport, die Datenformate, die Semantik der Daten, der Workflow und das Routing sowie die Anwendung. Beim Datentransport einer einzelnen Nachricht ist der Verlauf noch einfach, weil er über gängige Internet-Protokolle vonstatten geht. Die reine Übermittlung der Nachrichten erfolgt typischerweise über http oder verschlüsselt über https. Zusätzliche Protokolle kommen dann bei Fax, EDI und E-Mail zum Zuge. Auch die Ebene Datenformat folgt dem klaren Trend zu XML. Komplizierter wird dann die Ebene der Semantik: Sie ist mit Abstand die größte Herausforderung. Hier geht es um den kontextbezogenen Informationsgehalt einer Nachricht.

Wie eine asynchrone MiddlewareDie Funktionsweise eines Hubs kann mit der einer asynchronen Middleware verglichen werden, die verschiedenartige Systeme zeitverzögert miteinander kommunizieren lässt. Dafür werden eingehende Nachrichten in einer Warteschlange platziert und je nach Konfiguration, Sicherheitsrichtlinien, Auslastung oder Verfügbarkeit der Zielsysteme unmittelbar oder zeitverzögert abgearbeitet. Zusätzlich greifen hier Regeln zur Weiterleitung und Datenkonversion. Systeme, die sich an diesen Hub anschließen lassen, verwenden entweder Schnittstellen, die der Hub definiert, oder kommunizieren über Konnektoren, welche die Datenformate der installierten Systeme in Nachrichten umwandeln. Prominente Beispiele für einen solchen Hub sind http://www.marketsite.net/ von Commerce One, http://service.ariba.com/ oder http://mysap.com/.

"Sellside" und "Buyside", oder Käufer und LieferantAuch für E-Procurement hat sich der Webbrowser als universeller Client durchgesetzt. Aus Benutzersicht handelt es sich dabei dann um einen personalisierten Shop. Die Benutzerschnittstelle muss den Anforderungen einer Geschäftslösung genügen. Ursprünglich einfach realisierbare Anpassungen an diese Schnittstelle werden häufig dadurch erschwert, dass unter anderem die Anbietern von E-Procurement-Software zu wenig auf die Benutzerbedürfnisse und die Kompatibilität mit möglichst vielen Anwendersystemen achten.

Acht typische Hindernisse bei der IntegrationProbleme bei der E-Procurement-Integration lassen sich nur erkennen, indem man Teilaspekte oder besser noch durchgängige Prozesse prototypisch implementiert. Mittlerweile erlauben alle großen Plattformen die Teilnahme an einem gebührenfreien Testmodus. Hersteller sollten Qualität stets mit Referenzen nachweisen können. Auch folgende Überlegungen müssen beachtet werden:

- Katalog-Management: Nicht optimal auf Kundenbedürfnisse und Zielsystem abgestimmte Kataloge verhindern eine glatte Integration.

- Datenqualität: Für die Lieferanten bedeutet die Einbindung in ein E-Procurement-System häufig, den Kunden erstmals einen direkten Blick in mehr oder weniger sensible Daten zu erlauben. Informationen, die lediglich hausintern wichtig sind, sollten für Kunden unzugänglich bleiben.

- Integration: Ist eine erste einfache Einbindung in das E-Procurement-System mit Excel und Browser möglich, sollte das Softwaresystem mit fortschreitender Optimierung ebenfalls durchgängige und automatisierte Prozesse erlauben.

- Artikelkomplexität: Nicht ohne Grund werden in populären E-Procurement-Beispielen immer Bleistifte beschafft. Ab einem gewissen Komplexitätsgrad gelangen die meisten Systeme ins Hintertreffen.

- Preiskomplexität: Die meisten Systeme gehen davon aus, dass ein Produkt pro Kunde nur einen Preis hat. Bereits eine einfache Rabattstaffel lässt sich nur selten abbilden.

- Online-Prüfungen: Häufig arbeiten die Systeme mit einem Hub, der die Endpunkte unter anderem zeitlich isoliert. Gehen damit auch deutliche Vorteile einher, so sind Online-Prüfungen der Lagerverfügbarkeit oder offener Posten damit dennoch unmöglich.

- Lokalität: Die Realität ist nicht weltumspannend, sondern eher lokal. Das zeigen nicht nur die meisten Logistikprozesse, sondern auch lokale Gesetze und Bestimmungen, die beachtet werden müssen.

- Zahlung: Ein standardisierter Zahlungsverkehr, wie er bereits möglich wäre, findet kaum statt.

Kein Lieferant sollte so lange warten, bis ihn ein Kunde zwingt, sich an seiner E-Procurement-Lösung anzubinden. Vielmehr sollte jeder Lieferant von sich aus unter den bestehenden Kunden diejenigen ermitteln, die bereits E-Procurement-Systeme einsetzen oder planen. Damit entstehen deutliche Zeitvorteile und Wissensvorsprünge zugleich. Dasselbe gilt für die digitalen Marktplätze der jeweiligen Branche.

*Jürg Stuker ist Technology Manager und Partner der Namics AG in Frankfurt am Main

Abb.1: Der Hub im Mittelpunkt

Architektur eines E-Procurement-Systems, eine "Private Buysite". Quelle: Namics

Abb.2: Kommunikationsmodell

Die zehn Sessions bei der Kommunikation Käufer/Lieferant. Quelle: Ariba

Abb.3: Mehrere Ebenen

Die Ebenen der Integration von E-Procurement. Quelle: Stucker