Internet-Technologien in der Beschaffung

Dipl.-Wirtsch.-Ing. Ralph Dolmetsch, Prof. Dr. Hubert Österle, Institut für Wirtschaftsinformatik, Universität St. Gallen Dr. Elgar Fleisch,

In Pilotprojekten läßt sich beobachten, daß die Browser-basierten Beschaffungslösungen bisherige Bemühungen zur Kostensenkung integrieren oder ersetzen. Alternative Ansätze existieren heute etwa im Outsourcing der Beschaffungsabwicklung, wie sie in den USA beispielsweise von Unternehmen wie Corpro 2000 angeboten werden, oder im Einsatz von sogenannten Purchasing Cards.

Probleme bei der Beschaffung indirekter/Maintenance-Repair-and-Operations-Produkte sind auf den Mangel zurückzuführen, den Mitarbeitern einen einfachen Zugriff auf aktuelle Anbieterinformationen zur Verfügung zu stellen. Desktop- Purchasing-Systeme konsolidieren Produkt- und Anbieterinformationen in einem Multi-Lieferanten-Produktkatalog und integrieren gleichzeitig den Zugriff auf die entsprechenden Daten im hauseigenen Legacy- oder ERP-System. Die Systeme bieten dem Benutzer Zugang zum Multi-Lieferanten-Produktkatalog, in dem in Volumenverträgen verhandelte Produkte abgelegt sind. Im Gegensatz zum gewöhnlich wenig intuitiv zu bedienenden User-Interface von ERP-Systemen unterstützt die einfache Browser-basierte Benutzeroberfläche dieser Systeme auch die unregelmäßige Nutzung durch selten bestellende Mitarbeiter. DPS stellen deshalb insbesondere eine Lösung für die Beschaffung von C-Artikeln dar.

Neben einer Reihe von Unternehmen wie Ariba, Commerce-One, Elekom, Rightworks, Trade ‘Ex (Procurement & Trade) oder auch Netscape haben ERP-Softwareanbieter wie SAP und Oracle eigene Lösungen im Bereich der DPS angekündigt. Auch andere maßgebliche Hersteller wie IBM und Microsoft kommen demnächst mit eigenen Produkten auf den Markt.

Die heute auf dem Markt erhältlichen DPS sind alle mit ähnlicher Funktionalität ausgestattet. Abhängig von den durchgeführten Pilotprojekten entwickeln die Hersteller die vom Unternehmen noch vermißten Funktionen. Neue Releases werden derzeit im Monatsrhythmus lanciert.

Orientieren wir uns an der Anzahl von Implementierungsprojekten, dominieren den Markt derzeit im wesentlichen die Hersteller Ariba, Commerce One und Netscape. Ariba kann derzeit wohl die meisten Projekte aufweisen. Nachfolgend werden die drei Anbieter genauer betrachtet:

•Ariba Operating Resources Management System (ORMS), Ariba Technologies, Inc.: Das 1996 gegründete Unternehmen aus Sunny Vale in Kalifornien bietet ein System mit einem sehr benutzerfreundlichen, Java-basierten Frontend an. Das ORMS umfaßt eine leistungsstarke Suchmaschine, die es erlaubt, für jede Produktgruppe Suchkriterien vorzudefinieren, und eine komfortable, einfach zu bedienende grafische Workflowkomponente, die heute einzigartig ist und wohl zu einem guten Teil ausschlaggebend für die führende Stellung von Ariba in diesem Markt. Für die Integration mit den Legacy- und ERP-Systemen auf Kundenseite bietet Ariba sogenannte Adapter an, die als wiederverwendbare Schnittstellenlösungen ausgeprägt sind. Für den Austausch von Katalogdaten mit dem Anbieter entwickelte Ariba mit CIF (Catalog Interchange Format) einen proprietären Standard.

Ariba betont die Fähigkeit, neben Handelswaren auch Dienstleistungen im Produktkatalog abbilden zu können.

•Commerce-One Buy-Site/Market-Site, Commerce-One: Das Unternehmen mit Sitz in Walnut Creek, Kalifornien, wurde im Jahre 1994 gegründet. Es startete als Anbieter von CD-ROM-Produktkatalogen, bevor es sich im Jahre 1996 mehr der Beschaffungsseite zuwendete. In jüngster Zeit korrigierte das Unternehmen die eigene Geschäftsstrategie erneut, indem es sich zunehmend mehr als Katalog-Content-Provider sieht und das gegenwärtige Leistungsangebot im Bereich Katalog- und Content-Services sowie Transaktions-Management über ihre Market-Site-Komponente ausbaut. Market-Site ist ein wichtiges Differenzierungsmerkmal gegenüber der wachsenden Konkurrenz im Softwaremarkt bei den DPS. Um die Katalog-Services über das Internet anbieten zu können, arbeitet Commerce-One in den USA mit MCI und in Europa mit British Telecom zusammen. Commerce-One ist heute außerdem der einzige Hersteller, der eine vollständige Echtzeitintegration über entsprechende Schnittstellen, sogenannte Application Programming Interfaces (APIs), mit den Informationssystemen sowohl auf Beschaffungs- als auch Anbieterseite anbietet. Dadurch ist eine Lagerbestandsabfrage in Echtzeit auch für die aktuellen Verfügbarkeiten beim Lieferanten möglich.

•Netscape Buyer-Xpert/ EC-Xpert, Netscape Communications Corp.: Netscape mit Sitz in Mountain View, Kalifornien, wurde 1994 von James Clark und Mark Andreessen, der den NCSA Mosaic-Web-Browser entwickelte, gegründet. Die Beschaffungslösung Buyer-Xpert ist Teil der Lösungspalette Commerce-Xpert, die zusätzlich noch die Lösungen EC-Xpert, Developer-Xpert, Seller-Xpert, Publishing-Xpert und Merchant-Xpert umfaßt. Buyer-Xpert baut auf der EC-Xpert-Komponente auf, die Basisfunktionalitäten zum Austausch von Geschäftsdokumenten mit internen Systemen und den Lieferanten zur Verfügung stellt. Die Produkte von Netscape verwenden offene Standards wie beispielsweise CORBA IIOP für die Applikationsarchitektur und EDIINT als Kommunikationsprotokoll. Netscape ist ebenfalls beteiligt bei der Entwicklung des OBI-Standards und hat diesen unlängst – als einer der ersten Hersteller – sowohl im Buyer-Xpert als auch Seller-Xpert implementiert.

An dieser Stelle sollen auch die Lösungen von Aspect Development (Morocco), Harbinger (Trusted-Link-Procurement) und GE (Purchasing-Expert) erwähnt werden, die ebenfalls vergleichbare Funktionalitäten anbieten. Ähnlich wie Commerce-One, agieren diese Unternehmen zusätzlich als Content-Provider und unterhalten einen umfangreichen Multi-Lieferanten-Katalog mit den Produkten aus hunderten von Katalogen verschiedener Anbieter. Diese Content-Services sind komplementär zur Funktionalität der DPS und entlasten Unternehmen von vielen manuellen Aufgaben beim Content-Management. Darüberhinaus fehlen ihnen aber Funktionalitäten, wie sie im folgenden dargestellt werden.

Alle oben vorgestellten Systeme basieren auf einem privaten Multi-Lieferanten-Katalog, der auf dem Intranet des beschaffenden Unternehmens abgelegt ist. Die Benutzer-Interfaces der Systeme sind als HTML-Dokumente und/oder Java Applets realisiert und verfügen über vergleichbare Funktionalität. Unterschiede bestehen allerdings in der Benutzerführung. Einige Anbieter bieten dem Benutzer ein Cockpit an, andere ermöglichen Dialogtransaktionen über mehrere Bildschirmseiten.

Wie in Bild 2 dargestellt, bieten die Systeme Funktionalität zum Generieren von Bestellanforderungen, den dazugehörigen Genehmigungsworkflow, die elektronische Bestellung beim Anbieter, die Warenannahme am Schreibtisch durch den jeweiligen Besteller, die finanzielle Verbuchung der beschafften Produkte sowie Funktionalität für das Tracking und Reporting von Genehmigungs- und Bestellprozessen. Typischerweise verwenden die Pilotanwender die Systeme für geringwertige Handelsgüter wie Ersatzteile oder Büromaterial, die von den Mitarbeitern häufig bestellt werden.

Der Einsatzbereich der Systeme beschränkt sich damit heute auf vorverhandelte, nicht dynamisch konfigurierbare Produkte und Dienstleistungen. Typische Beispiele geeigneter Produktesegmente faßt Tabelle 1 zusammen.

Ariba bietet ausschließlich eine kundenseitige Softwarekomponente an. Im Gegensatz dazu liefern Commerce-One und Netscape optional zusätzlich Tools für die Anbieterseite, die dem Lieferanten beim Extrahieren der aktuellen Produktkatalogdaten aus den entsprechenden Datenbanken helfen.

Im konkreten Projekt können die in Bild 1 dargestellten Systemkomponenten über die Organisationseinheiten des Kunden, der Anbieter oder eines dazwischengeschalteten Katalog-Content-Providers verteilt sein.

Kritischer Erfolgsfaktor der Akzeptanz eines DPS ist die Aktualität und Vollständigkeit der Produktinformationen im privaten Multi-Lieferanten-Katalog (MLK) des Unternehmens. Dort sind im Idealfall vollständige und aktuelle Datensätze zu den verhandelten beziehungsweise relevanten Produkten aller Anbieter abgelegt. Der Benutzer im Unternehmen muß sich also nicht die Kataloge verschiedener Anbieter besorgen und durchsehen, sondern lediglich den unternehmensspezifischen MLK durchsuchen. Von verschiedenen Anbietern müssen dazu die Daten in einem Katalog konsolidiert und in einer einheitlichen Struktur entsprechend geordnet und abgelegt sein. Diese Katalogstruktur ist eine Hierarchie von Produktsegmenten und -gruppen, die sich aus den Anforderungen der unterschiedlichen Beschaffergruppen im Unternehmen ableitet.

Nachfolgend werden die einzelnen Komponenten von DPS etwas genauer betrachtet.

Beim Content-Management vereinbart ein Unternehmen mit seinen Anbietern einheitliche Datenformate und Datensätze sowie Regeln und Mechanismen für die Replikation im Rahmen der Katalog-Updates. Folgende Aspekte des Content-Managements werden kurz aufgegriffen:

•Klassifikation von Content

•Content-Aggregation

•Personalisierung von Content

Ziel eines Klassifikationsschemas ist es, für MLK einen anbieterunabhängigen Kategorisierungsvorschlag für Produktgruppen und Produkte vorzugeben. Klassifikationsschemata sind wichtig für die Pflege beziehungsweise Aktualisierung von MLK und erleichtern die strukturierte Suche. ERP-Systeme erlauben heute im Gegensatz zu den untersuchten DPS meist nur flache Klassifizierungshierarchien. So läßt beispielsweise SAP R/3 nur zwei Kategorisierungsebenen zu.

Derzeit orientieren sich alle wesentlichen Systemanbieter am UN/SPSC-Standard. Der Standard Product and Services Code, kurz SPSC, ist von Dun & Bradstreet entwickelt und zwischenzeitlich von der UN verabschiedet worden.

Neben der Klassifizierung von Produkten ist es für Unternehmen ebenso wichtig, für jede Produktklasse zusätzlich die Attribute eines Produktdatensatzes festzulegen. Hier wird unterschieden zwischen Textfeldern wie Produktnummern oder Adressangaben und Multimediadaten wie beispielsweise Produktbilder oder PDF-Files zur detaillierten Funktionsbeschreibung.

Alle untersuchten Systeme erlauben die Definition produktgruppenspezifischer Datensätze. Jedes Textfeld kann prinzipiell Attribut der elektronischen Suche im Katalog sein.

Ein Unternehmen benötigt die Katalogdaten von verschiedenen Anbietern, um diese im privaten MLK zu konsolidieren. Umgekehrt hat ein Anbieter meist mehrere Kunden, die verschiedene Produktdatensätze in unterschiedlichen Datenformaten verlangen. So entsteht eine n-zu-m-Beziehung. Der Aufwand kann durch den Einsatz eines Content-Providers und eine dadurch entstehende n-zu-1-zu-m-Beziehung reduziert werden. Ein Content-Provider ist ein Dienstleister, der sich auf die Aggregation und das Management von MLK spezialisiert hat.

Bisher haben sich keine allgemeingültigen Standards für den Austausch von Katalogdaten durchgesetzt. Ariba hat für diesen Zweck den oben angesprochenen auf UN/SPSC und ANSI X.12 basierenden CIF-Standard entwickelt und offengelegt. Die Lieferanten der Ariba-Kunden benutzen den CIF-Standard, um ihre Katalogdaten zu übermitteln. CIF ist derzeit aber kein allgemeingültiger Standard.

Heute bieten deshalb alle Hersteller ihren Kunden zusätzliche Hilfe bei der Adoption und Integration ihrer Lieferanten an. Chevron, einer der Pilotkunden von Ariba, nutzt zusätzlich Harbinger als Content-Provider. Harbinger ist zuständig für die Normalisierung und Strukturierung der Katalogdaten sämtlicher Anbieter von Chevron. Ähnliche Services offerieren Commerce-One/MCI mit dem Market-Site-System sowie TPN Register, ein Joint Venture von Thomas Register und GEIS.

Wir unterscheiden zwei Stufen der Personalisierung von MLK:

•Personalisierte Unternehmenskataloge: Sowohl Commerce-One/MCI als auch Harbinger bieten das Content Management privater MLK auf Kundenseite an. Beim Replizieren berücksichtigen sie dazu die Metastruktur des Kataloges beim Kunden, die Datenfelder der Produktdatensätze sowie die unternehmensspezifischen Preise. Der Content-Provider legt für jedes einzelne Produkt verschiedene kundenindividuelle Preise ab.

Das Market-Site von Commerce-One/MCI führt zusätzliche Preisdegression automatisch nach. Sobald der Marktpreis unter den individuell verhandelten Kundenpreis sinkt, aktualisiert das System den MLK im Kundenunternehmen. Insbesondere bei stark preisdegressiven High-Tech-Produkten ist dies von Vorteil.

•Personalisierung im Unternehmen auf Mitarbeiterebene: Alle untersuchten Systeme ermöglichen den Unternehmen, auf Mitarbeiter- oder Benutzergruppenebene spezielle Sichten auf den MLK zu definieren. Abhängig vom individuellen Benutzerprofil hat ein Mitarbeiter nach dem Einloggen ins System dann beispielsweise nur Zugriff auf spezielle Produktgruppen oder Produkte bis zu einem festgelegten Höchstpreis. Weitere Regeln sind vom Unternehmen frei definierbar.

Alle DPS bieten heute eine Administrationskomponente an, die auf Daten über Benutzerprofile, Anbieterprofile und Beschaffungsrichtlinien zugreift. Abhängig von diesen Daten

•durchläuft eine Bestellanforderung einen Genehmigungsworkflow, bevor sie zur Bestellung wird;

•gibt das DPS einem Benutzer Zugriff auf eine bestimmte Sicht des MLK;

•kann ein Benutzer nur bis zu einer definierten Budgetobergrenze bestellen;

•priorisiert das System die Lieferanten.

In vielen Unternehmen sind einige der relevanten Mitarbeiterdaten schon in anderen Systemen hinterlegt. Das DPS kann entweder auf die Daten eines entsprechenden ERP/Legacy-Systems in Echtzeit zugreifen oder die Daten im DPS ablegen. Außerdem bieten die meisten DPS Schnittstellen zu zentralen Directory-Servern an.

Produktkonfiguration: Keines der untersuchten Systeme bietet heute die Möglichkeit, komplexe Produkte regelbasiert zu konfigurieren und dynamisch mit Preisen zu versehen. Die Pilotkunden definieren aus diesem Grund eine Reihe vorkonfigurierter Produkte, die sie genau wie nicht-konfigurierbare Produkte im MLK ablegen. Im Bereich von Computer-Hardwareprodukten kommt dieses Vorgehen den Standardisierungsbemühungen von Unternehmen entgegen. Durch die vordefinierte, eingeschränkte Auswahl können Mitarbeiter nur Produkte gemäß dem Unternehmensstandard auswählen und beschaffen.

Einige Hersteller planen, in Zukunft Schnittstellen zu optionalen Konfigurationskomponenten von Drittanbietern anzubieten.

Produktsuche: Alle Hersteller bieten komfortable Suchmaschinen für das Browsen im MLK an. Die Systeme unterstützen verschiedene Arten der Suche: Nach Schlüsselwörtern, nach Attributen oder durch Browsen in der Produkthierarchie.

Sourcing: Falls ein Produkt von verschiedenen Lieferanten angeboten wird, zeigt die Reihenfolge der gefundenen Angebote die Priorisierung entsprechend der Beschaffungspolitik des Unternehmens an. Für die Reihenfolge kann der niedrigste Preis ebenso wie die bevorzugte Beschaffung bei speziellen Lieferanten ausschlaggebend sein. Falls ein Unternehmen ein eigenes Lager unterhält, kann dieses Lager wie ein externer Anbieter im MLK repräsentiert und mit hoher Priorität versehen werden.

Verfügbarkeitsprüfung: Commerce-One unterstützt heute als einziger Anbieter, über die Möglichkeit einer Echtzeitanbindung, das Abfragen von Lagerbeständen und Preisinformationen im ERP/Legacy-System der Lieferanten.

Ausschreibungen und Auktionen: DPS richten sich insbesondere an Besteller von Büro- und Industriebedarf. Komplexe Verhandlungsmechanismen auf mehrere Attribute (wie Produktfunktionalität, Preis und Lieferkonditionen), wie sie beispielsweise professionelle Einkaufsdisponenten im direkten Bereich oder bei teuren Anlagegütern verwenden, sind deshalb im Funktionsumfang der DPS heute nicht abgedeckt.

Keines der DPS unterstützt derzeit Ausschreibungen.

Bestellanforderung: Der Besteller wählt Produkte und/oder Dienstleistungen aus dem MLK aus und stellt einen elektronischen Einkaufskorb zusammen, aus dem eine oder mehrere elektronische Bestellanforderung generiert werden. Häufig nachgefragte Leistungen können mit „Bookmarks“ gekennzeichnet und repetetiv beschaffte Einkaufskörbe können abgespeichert werden. So kann ein Unternehmen beispielsweise einen Einkaufskorb zur Ausstattung eines gesamten Arbeitsplatzes für neue Mitarbeiter ablegen. Zu diesem Zweck kann eine Bestellanforderung bei den meisten Systemen heute Leistungen von verschiedenen Anbietern umfassen.

Genehmigungs-Workflow: Abhängig vom Benutzerprofil des Bestellers und von der jeweils bestellten Leistung durchläuft eine Bestellanforderung einen Genehmigungs-Workflow, bevor sie das Unternehmen als Bestellung an einen Anbieter schickt. Das System informiert die jeweiligen Genehmigungsinstanzen durch verschicken von E-Mails. Bei den DPS können verschiedene Arten von Genehmigungsworkflows identifiziert werden: Ein Genehmigungs-Workflow pro

–Bestellung,

–Bestellanforderung oder

–bestellten Produktes.

Bei den untersuchten Systemen bestehen Unterschiede in der Benutzerfreundlichkeit der Workflow-Komponenten. Durch besondere Benutzerfreundlichkeit zeichnet sich der Ariba Workflow aus.

Bestellungen: Nach der Genehmigung der Bestellanforderung erstellt das DPS eine Bestellung für jeden Lieferanten automatisch und verschickt diese an das interne ERP/Legacy-System und die entsprechenden Lieferanten. Je nach Implementierungsvariante kann auch das ERP/Legacy-System für die Generierung der Bestellungen und das Verschicken zuständig sein. E-Mail, Fax oder EDI sind in Frage kommende elektronische Medien für die Kommunikation mit den Lieferanten.

Empfang von Waren: Der Empfang einer bestellten Ware muß im DPS erfaßt werden. Es gibt zwei Alternativen für den Warenempfang: Lieferung an den Schreibtisch des Bestellers oder eine zentrale Anlieferung (eventuell mit Zwischenlagerung). DPS unterstützt beide Alternativen. Das DPS zeigt eine Bestelltransaktion als nicht beliefert an, bis der Empfang bestätigt ist. Über Tracking- und ReportingFunktionalitäten haben der einzelne Benutzer oder der zentrale Beschaffungsbereich jederzeit Kontrollmöglichkeiten über den aktuellen Status einer Bestellung und die zeitliche Abwicklung des Geschäftsvorfalls.

Bezahlung: DPS unterstützen neben der Prozessvariante klassischer Überweisungen zusätzlich den Einsatz von Procurement-Cards. Die untersuchten Pilotanwender nutzen die bestehenden Zahlungsmechanismen mit ihren Lieferanten nach der Einführung eines DPS weiter.

Finanzielle Verbuchung: Ein Besteller muß bei der Bestellanforderung von Produkten diese je nach Verwendungszweck auf Kostenstellen verbuchen und abhängig vom Preis ebenfalls als Anlagegut aktivieren. Bei allen untersuchten Systemen kann der Benutzer für jedes Produkt eine oder mehrere Kostenstellen angeben. Je nach Implementierung und Grad der Integration mit den entsprechenden ERP/Legacy-Systemen schlägt das System eine Kostenstelle und ein passendes Anlagekonto aus dem Kontenplan des Unternehmens vor.

Tracking: Die Tracking-Funktionalität der DPS gibt Benutzern einen Überblick sowohl über den Genehmigungsstatus einer Bestellanforderung als auch über den Status einer Bestellung. Einige Anbieter planen für die nächsten Releases zusätzlich die Integration heute üblicher Tracking-Informationen von Transportintermediären wie beispielsweise Fedex oder UPS.

Reporting: DPS bieten eine detaillierte Reporting-Funktionalität an. Unternehmen können Führungsgrößen der Beschaffung für jeden Mitarbeiter, jedes Produkt oder jede Produktgruppe bzw. jeden Anbieter definieren. In der Vergangenheit hatte das Controlling nur wenige Möglichkeiten, Beschaffungsmuster und -volumen zu erheben oder Anbieter zu beurteilen.

Um Mehrfacheingaben von Daten zu vermeiden, muß das DPS mit dem internen Informationssystem des beschaffenden Unternehmens wie auch mit den Informationssystemen der Lieferanten elektronisch kommunizieren. Wir unterscheiden zwei Arten der Integration mit Legacy/ERP-Systemen:

•asynchroner Austausch von elektronischen Dokumenten, beispielsweise über branchenspezifische EDI-Formate beziehungsweise ALE-IDOCs bei SAP R/3;

•direkter und synchroner Aufruf von Prozeduren und Funktionen über RPCs (Remote Procedure Calls) mit speziellen APIs (Application Programming Interfaces) der Applikationsebene eines Legacy/ERP-Systems.

Ein Real-Time-Zugriff auf Daten im ERP/Legacy-System über RPC benötigt offengelegte APIs. Viele, insbesondere ältere Legacy-Systeme unterstützen keinen direkten Zugriff auf ihre Funktionalitäten über APIs. In solchen Fällen ist ein Unternehmen gezwungen, eine dokumentenbasierte asynchrone Integration zu realisieren. Alle Hersteller von DPS behaupten heute, eine Real-Time-Anbindung über APIs der marktführenden ERP-Systeme von SAP, Oracle und Baan realisieren zu können.

Die SAP AG als der führende Anbieter betriebswirtschaftlicher Standardsoftware verfolgt seit einiger Zeit das Konzept der BAPIs. BAPIs sind APIs, die den Zugriff auf wesentliche, semantisch über das Referenzmodell definierte Methoden erleichtern, und die über mehrere Release-Stände der Software unverändert bleiben. Die DPS-Hersteller nutzen BAPIs, um die entsprechenden Daten aus dem SAP R/3-System des Kundenunternehmens auszulesen und zurückzuschreiben.

Eine Echtzeitintegration mit den Systemen der Anbieter, um beispielsweise die aktuellen Lagerbestände oder Preise abzufragen, scheitert heute oft am Aufwand zur Realisierung eines sicheren Zugriffs auf die entsprechenden Transaktionen im Lieferantensystem. Aus diesem Grund findet der Datenaustausch mit Anbietern heute meist asynchron und dokumentenbasiert über EDI statt. Unternehmen verwenden Filetransfer, E-Mail und Fax zur Übermittlung von Dokumenten.

Commerce-One ist der einzige Anbieter, der eine Echtzeit-Integration ermöglicht. Auf Wunsch wird dazu das ERP-System eines Lieferanten über die entsprechenden APIs mit Market-Site und dadurch mit dem DPS des beschaffenden Unternehmens integriert. Commerce-One nutzt ein proprietäres TCP/IP-Protokoll. Der Transaktionsserver von Commerce-One steht in den USA bei MCI. MCI stellt den notwendigen Datendurchsatz durch dedizierte Frame-Relay-Schaltungen für die Kunden sicher.

Einsparungspotentiale lassen sich in drei Bereichen erzielen:

•Beschaffungsprozeß: Der Prozeß ist automatisiert, schneller, weniger fehleranfällig und bindet weniger Mitarbeiterressourcen für Abstimmungen;

•Günstigere Preise: DPS ermöglichen es, einerseits das Bestellvolumen im Unternehmen zu bündeln und so günstigere Preise mit den Lieferanten auszuhandeln. Andererseits erlauben die Systeme den Mitarbeitern, Produkte und Preise zu vergleichen und beim günstigsten Lieferanten einzukaufen.

•Lagerbestände: Der gesamte Beschaffungsprozeß ist zeitlich kürzer und die Lagerbestände sind über das System für jeden Mitarbeiter einsehbar. Insgesamt reduziert sich der Lagerbestand dadurch.

Im Gegensatz zur Einführung von ERP-Systemen hat die Implementierung von DPS und allgemein von E-Commerce-Applikationen häufig keinen Platz auf der Agenda strategischer IT-Projekte im Unternehmen. Ein E-Commerce-Projektvorgehen trägt diesem Aspekt Rechnung, indem es die betroffenen Prozesse nicht im Rahmen einer Big-Bang-Einführung von einem Tag auf den anderen umstellt. Vielmehr ist es üblich, mit einem abgegrenzten Piloten zu starten, welcher bei entsprechender Akzeptanz dann ausgeweitet wird.

Was für die Umstellung der Prozesse gilt, trifft im gleichen Maße für die Adoption der Lieferanten und Anbieter zu. Bei der Einführung des DPS startet ein Unternehmen gewöhnlich mit den Produktkatalogen der 5 bis 15 wichtigsten Lieferanten und nimmt später weitere Anbieter mit ihren Produktkatalogen in das System auf.

Abhängig von der Akzeptanz des Systems im Unternehmen, dem Grad der Integration mit anderen Systemen, des Abdeckungsgrades aller Produktsegmente und der Vollständigkeit bei der Unterstützung des gesamten Beschaffungsprozesses mit all seinen Varianten realisiert ein Unternehmen erst langsam die potentiellen Einsparungspotentiale.

Bis Ende 1998 hatten erst wenige Unternehmen einen DPS-Produktivstart. Erste Pilotanwender in den USA sind beispielsweise Chevron, Cisco, Country of Los Angeles, Mastercard, Pacific Gas & Electric und VISA.

–Aberdeen Group, Internet Procurement Automation: Separating the EC Wheat from the Chaff, Volume 11, Number 6, March 1998

–Dolmetsch, R., Fleisch, E., Österle, H., Beschaffung von indirekten/MRO-Leistungen mit Desktop-Purchasing-Systemen: Markt- und Funktionsüberblick – Pilotprojekte – Implementierungsvorgehen, Arbeitsbericht IM HSG/CC iBN/11, Institut für Wirtschaftinformatik der Universität St. Gallen, St. Gallen 1998

–Killen & Associates, Operating Resources Management: How Enterprises can Make Money by Reducing ORM Costs, White Paper, Palo Alto 1997

Jeder Mitarbeiter eines Unternehmens kann direkt vom Schreibtisch aus, über seinen eigenen PC und ein leicht zu nutzendes Browser-basiertes System Bestellvorgänge vollständig abwickeln, ohne dabei ein kompliziertes Warenwirtschaftssystem bedienen zu müssen. Desktop Purchasing (DPS) bezeichnet genau dieses Konzept.

Ariba Technologies Polaris Avenue 53 NL-2132 JH Hoofdoorp Tel. 0031/23/5 68 47 42

Commerce One Europe Dreikönigstrasse 31A CH-8002 Zürich Tel. 0041/1/3 08 36 26

Netscape Communications Thurgauerstrasse 66 CH-8050 Zürich Tel. 0041/1/3 08 51 11