Desktop Purchasing: I-Net-Technologien in der Beschaffung Dipl.-Wirtsch.-Ing. Ralph Dolmetsch Institut für Wirtschaftsinformatik, Universität St. Gallen Email: [email protected] Dr. Elgar Fleisch Institut für Wirtschaftsinformatik, Universität St. Gallen Email: [email protected] Prof. Dr. Hubert Österle Institut für Wirtschaftsinformatik, Universität St. Gallen Email: [email protected]

Version 0.9

Inhalt 1 Problemstellung........................................................................................................ 1 2 Desktop Purchasing ................................................................................................. 3 2.1 2.2 2.3 2.4 2.5 2.6

Anbieter von Desktop Purchasing-Systemen..................................................... 4 Überblick über Systemkomponenten und Funktionalität................................... 5 Content-Management......................................................................................... 7 Systemadministration......................................................................................... 9 Prozessunterstützung und Systemfunktionalität .............................................. 10 Integration mit Legacy/ERP-Systemen ............................................................ 13

3 Einsparungspotentiale von Desktop Purchasing-Systemen ............................... 14 4 Literatur.................................................................................................................. 15

1

Desktop Purchasing

1 Problemstellung In den letzten Jahren hat sich das Gesicht vieler Unternehmen durch Business Process Reengineering und/oder die Einführung von integrierter Standardsoftware, sogenannter ERP-Systeme (Enterprise Resource Planning) wie beispielsweise SAP R/3, Oracle Applications oder Baan Triton, stark verändert. BPR-Projekte beschäftigen sich insbesondere mit der Schnittstelle zum Kunden und greifen in den wenigsten Fällen bis auf die Beschaffungsfunktion der Organisation durch. In der Beschaffung sind die organisatorischen Gestaltungsbemühungen traditionell stärker technologisch bestimmt. Im Zusammenhang mit der Einführung von ERPoder MRP-Systemen gestalten Industrieunternehmen die Beziehung zu den Geschäftspartnern auf Anbieterseite neu. Sie konzentrieren sich dabei insbesondere auf den direkten Bereich, also die Beschaffung von Material für die Produktion. Unternehmen gehen dabei oft enge Partnerschaften ein, bei denen die Produktionsplanung bzw. Materialwirtschaft die Beschaffungsaufträge automatisch auslöst und über EDI-Verbindungen ohne menschliches Zutun direkt ins System des Lieferanten sendet. Anders sieht es bei der Beschaffung von sogenannten indirekten/MRO-Leistungen (Maintainance, Repair und Operations) aus, also denjenigen Leistungen, die nicht direkt ins Endprodukt eingehen oder weiterverkauft werden. Unternehmen haben die Beziehung zu Anbietern von indirekten/MRO-Leistungen und die damit verbundenen Beschaffungsprozesse im Unternehmen in den letzten Jahren kaum verändert [s. Killen & Associates 1997]. Genau hier verbergen sich aber grosse Verbesserungspotentiale durch den Einsatz moderner Informationstechnologie und insbesondere von Internet-Technologien [vgl. Gebauer/Beam/Segev 1998]. Prozessführung

Katalog- und Sourcing-Dienste

Bestellanforderung und Bestellung

Lieferung und Empfang

Bezahlung und Verbuchung

Bild 1: Kernprozess der Beschaffung Aus der Analyse der Beschaffungsprozesse für indirekte/MRO-Leistungen in vierzehn Unternehmen aus unterschiedlichen Branchen haben wir einen generischen Kernprozess abgeleitet [vgl. Dolmetsch et al. 1998]. Der Kernprozess für die Beschaffung besteht danach aus fünf Prozessgliedern. Bild 1 stellt die Glieder des Kernprozesses dar. Die Beschaffung von indirekten/MRO-Leistungen wickeln Unternehmen heute häufig ebenfalls über ihre ERP-Systeme ab. Diese Systeme bieten eine Fülle von Funktionalität an, die es Mitarbeitern, welche das System nicht täglich nutzen, kaum

Institut für Wirtschaftsinformatik der Universität St. Gallen

ermöglichen, dieses zu beherrschen. Aus diesem Grund richten Unternehmen heute im indirekten Bereich verbreitet die Rolle sogenannter Bestellanforderer ein. Eine Bestellanforderung ist der noch nicht genehmigte Bestellantrag eines Mitarbeiters. Der Bestellanforderer ist für eine Anzahl von Mitarbeitern zuständig und gibt für seine Kollegen die Bestellanforderungen ins entsprechende Legacy- oder ERP-System ein. Vorteile dieses Vorgehens sind:

m m

Der Bestellanforderer hat Übung im Umgang mit dem Bestellsystem. Das Unternehmen benötigt entsprechend weniger Benutzerlizenzen für das ERPSystem.

Anhand eines typischen Szenarios wollen wir nachfolgend die Nachteile bei der Beschaffung indirekter/MRO-Leistungen aufzeigen: Viele Unternehmen verhandeln die Beschaffung von Leistungen an zentraler Stelle, um entsprechende Volumenverträge mit den Anbietern abzuschliessen. Benötigt ein Mitarbeiter heute ein neues Notebook, muss er sich erst einmal nach den IT-Standards im Unternehmen erkundigen. Anschliessend fragt er beim zentralen Einkauf nach, mit welchem Anbieter Verträge bestehen. Da der Produktkatalog zu den jeweiligen Geräten beim zentralen Einkauf bereits drei Monate alt ist, besorgt der Mitarbeiter bei den Vertragspartnern neue Kataloge. Aufgrund der erhaltenen Unterlagen hat er sich für ein Notebook entschieden, ist aber nicht sicher, ob die gewünschte Konfiguration technisch möglich ist. Er holt sich entsprechende Auskünfte ein und lässt sich direkt ein Angebot zusenden. Nachdem er das Angebot per Fax erhalten hat, gibt er es zusammen mit einem ausgefüllten Beschaffungsantragsformular mit der internen Hauspost an die IT-Abteilung, die als technische Genehmigungsinstanz den Beschaffungsantrag abzeichnet. Nachdem auch der Vorgesetzte des Mitarbeiters der Beschaffung zugestimmt hat, bearbeitet der zentrale Einkauf den Antrag. Er prüft, ob der ausgewiesene Preis den verhandelten Konditionen entspricht. Ist alles in Ordnung, gibt er den Antrag ins Beschaffungssystem ein, verbucht die Bestellung auf den Rahmenvertrag, druckt eine Bestellung aus und schickt diese dem Anbieter. Die wichtigsten Nachteile des beschriebenen Vorgehens sind:

m m

Der Prozess ist zeitaufwendig, fehleranfällig, arbeits- und abstimmungsintensiv. Eine mitarbeitergenaue Auswertung der Beschaffungskosten und des Bestellverhaltens ist nicht oder nur durch Eingabe zusätzlicher Daten möglich.

Nach Angaben von Industrieunternehmen gehen durchschnittlich etwa 80% aller Einkaufstransaktionen auf die Beschaffung sogenannter indirekter/MRO-Leistungen zurück [Intersearch 1998; Netscape 1998]. Rechnet man Anlagegüter zu den indirekten Leistungen, verursachen diese nach Untersuchungen von [Killen & Associates 1997, S. 2] bei amerikanischen Unternehmen im Durchschnitt etwa ein Drittel der gesamten Kosten eines Unternehmens. Neben den Kosten für direkte

3

Desktop Purchasing

Leistungen und Personal stellen indirekte/MRO-Leistungen damit den grössten Kostenblock eines Unternehmens dar. Bild 2 zeigt die wichtigsten Kostenblöcke eines Unternehmens. Steuern und Abgaben 13% Direkte Leistungen 25%

Profit 13% indirekte/MRO Leistungen 33%

Personalkosten 16%

Bild 2: Kostenblöcke eines Unternehmens [Killen & Associates 1997, S. 2] Einsparungen bei der Beschaffung indirekter/MRO-Leistungen wirken sich zu mehr als 50% direkt als Profit aus [vgl. Killen & Associates 1997, S. 9; AMR 1997, S. 4; SAP 1998, S. 3]. Angesichts dieser Situation und der Tatsache, dass eine Bestelltransaktion bei den von uns befragten Unternehmen unabhängig vom eigentlichen Bestellwert häufig über 100 USD kostet, gilt die Internet-basierte Beschaffung als das heute wohl attraktivste Gebiet des Electronic Commerce im Business-to-Business Bereich [vgl. Gebauer/Beam/Segev 1998]. Das Angebot an Beschaffungslösungen für den indirekten Bereich wird zunehmend unübersichtlicher. Desktop Purchasing-Systeme (DPS) sind eine Kategorie von Applikationen, die in jüngster Zeit grosse Beachtung finden. Es gibt heute zwar erst wenige produktive Implementierungen, angesichts eines hohen ROIs der Projekte wächst das Interesse bei Unternehmen und Behörden an DPS aber schnell. In den Pilotprojekten lässt sich beobachten, dass 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.

2 Desktop Purchasing Die eingangs erwähnten Probleme bei der Beschaffung indirekter/MRO-Leistungen sind auf den Mangel zurückzuführen, den Mitarbeitern einen einfachen Zugriff auf aktuelle Anbieterinformationen zur Verfügung zu stellen. Die unten beschriebenen DPS konsolidieren Produkt- und Anbieterinformationen in einem Multi-AnbieterProduktkatalog (wir sprechen im Folgenden von Multi-Lieferanten-Produktkatalogen, MLK) und integrieren gleichzeitig den Zugriff auf die entsprechenden Daten im Legacy- oder ERP-System. Die Systeme bieten dem Benutzer Zugang zum MLK, in dem in Volumenverträgen verhandelte Produkte abgelegt sind. Im Gegensatz zum gewöhnlich wenig intuitiv zu bedienenden User-Interface von Legacy- oder ERPSystemen unterstützt die einfache Browser-basierte Benutzeroberfläche dieser

Institut für Wirtschaftsinformatik der Universität St. Gallen

Systeme auch die unregelmässige Nutzung durch selten bestellende Mitarbeiter. DPS stellen deshalb insbesondere eine Lösung für die Beschaffung von indirekten/MROLeistungen dar.

2.1 Anbieter von Desktop Purchasing-Systemen Neben einer Reihe von Start-Up-Unternehmen wie beispielsweise Ariba, CommerceOne, Elekom, Rightworks, Trade'Ex oder auch Netscape haben ERPSoftwareanbieter wie SAP und Oracle eigene Lösungen im Bereich der DPS angekündigt. Auch andere massgebliche Hersteller wie IBM und Microsoft kommen in den nächsten Monaten 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 vermissten Funktionen. Neue Releases werden derzeit im Monatsrhythmus lanciert. Orientieren wir uns an der Anzahl von Implementierungsprojekten, dominieren den Markt derzeit im wesentlichen drei Hersteller, von welchen Ariba und CommerceOne wohl die meisten Projekte aufweisen können. Nachfolgend betrachten wir die drei Anbieter genauer:

m

Ariba Operating Resources Management System (ORMS), Ariba Technologies, Inc.:

Das 1996 gegründete Unternehmen aus Sunnyvale in Kalifornien bietet ein System mit sehr benutzerfreundlichem Java-basiertem Frontend an. Das ORMS umfasst eine leistungsstarke Suchmaschine, die es erlaubt, für jede Produktgruppe Suchkriterien vorzudefinieren, und eine komfortable, einfach zu bedienende Workflowkomponente. Für die Integration mit Legacy- und ERP-Systemen auf Kundenseite bietet Ariba sogenannte Adapter an, die als wiederverwendbare Schnittstellenlösungen ausgeprägt sind. Von den Anbietern erwartet Ariba, dass diese ihre Produktkataloge im eigenentwickelten CIF-Standard (Catalog Interchange Format) vorhalten [vgl. CommerceNet 1998, S. 61; Ariba 1998a; Ariba 1998b] Ariba betont die Fähigkeit, neben Handelswaren auch Dienstleistungen im Produktkatalog abbilden zu können.

m

CommerceOne BuySite/MarketSite, CommerceOne:

CommerceOne mit Sitz in Walnut Creek, Kalifornien, wurde im Jahre 1994 gegründet. Das Unternehmen 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 Produktstrategie erneut, indem es gegenwärtig das Leistungsangebot im Bereich Katalog- und Content-Services sowie TransaktionsManagement über die MarketSite-Komponente betont. MarketSite ist ein wichtiges

5

Desktop Purchasing

Differenzierungsmerkmal gegenüber der wachsenden Konkurrenz im Markt der DPS. CommerceOne ist heute ausserdem der einzige Hersteller, der eine vollständige Echtzeitintegration über entsprechende APIs mit den Informationssystemen auf Käufer- und Verkäuferseite anbietet.

m

Netscape BuyerXpert/ ECXpert (als Teil der CommerceXpert-Familie), Netscape Communications Corp.:

Netscape mit Sitz in Mountain View, Kalifornien, wurde 1994 von James Clark und Mark Andreessen, die den NCSA MosaicWeb Browser entwickelten, gegründet. Die Beschaffungslösung BuyerXpert ist Teil der CommerceXpert-Lösung, die zusätzlich noch die Lösungen ECXpert, DeveloperXpert, SellerXpert, PublishingXpert und MerchantXpert umfasst [s. Netscape 1998b]. BuyerXpert baut auf der ECXpertKomponente auf, die Basisfunktionalitäten wie Transaktionsmanagement und Sicherheit zur Verfügung stellt. Die Produkte von Netscape verwenden offene Standards wie beispielsweise CORBA IIOP für die Applikationsarchitektur und EDIINT als Kommunikationsprotokoll [s. Netscape 1998a]. Netscape ist ebenfalls beteiligt bei der Entwicklung des OBI-Standards [s. OBI 1998] und hat diesen unlängst - als einer der ersten Hersteller - im CommerceXpert-System implementiert. An dieser Stelle wollen wir auch die Lösungen von Aspect Development, Harbinger und TPN Register von GE IS und Thomas Register erwähnen, die ebenfalls vergleichbare Funktionalitäten anbieten. Ähnlich wie CommerceOne agieren diese Unternehmen zusätzlich als Content-Provider und unterhalten einen umfangreichen MLK mit den Produkten aus hunderten von Katalogen verschiedener Anbieter. Diese Content-Leistungen sind komplementär zur Funktionalität der DPS und entlasten Unternehmen von vielen manuellen Aufgaben beim Content-Management.

2.2 Überblick über Systemkomponenten und Funktionalität Alle oben vorgestellten Systeme basieren auf einem privaten MLK, der auf dem Intranet des beschaffenden Unternehmens abgelegt ist. Die Benutzerinterfaces der Systeme sind in HTML oder Java realisiert und verfügen über in etwa vergleichbare Funktionalität. Die Systeme bieten Funktionalität zum Generieren von Bestellanforderungen, den dazugehörigen Genehmigungsworkflows, für die elektronische Bestellung beim Anbieter, die finanzielle Verbuchung der beschafften Leistungen 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.

Institut für Wirtschaftsinformatik der Universität St. Gallen

Produkte

Dienstleistungen

Computer (vorkonfiguriert) Software Magazine, Bücher und Zeitungen Bürobedarf (Bleistifte, Papier usw.) Büromöbel KFZ (der Unternehmensflotte) Uniformen Werbematerial Industrieprodukte (Maintenance und Repair)

Werbedienstleistungen Bankdienstleistungen Cafeteria und Catering Beratung und Hot-Line Dienste Kopierservice Kurierdienste Parkplatzreservation Reisedienstleistungen Schulungen

Tabelle 1: Typische Beispiele abgebildeter Leistungskategorien Ariba bietet ausschliesslich eine kundenseitige Softwarekomponente an. Im Gegensatz dazu liefern CommerceOne und Netscape optional zusätzlich Lösungen für die Anbieterseite, die beim Extrahieren der aktuellen Produktkatalogdaten helfen, und ebenfalls dedizierte Transaktionsserver, die für die Kommunikation zwischen Kunden und Anbietern zuständig sind. Im konkreten Projekt können die in Bild 3 abgebildeten Systemkomponenten über die Organisationseinheiten des Kunden, der Anbieter oder eines dazwischen geschalteten Katalog-Content-Providers verteilt sein. User Interface / Web Browser

Genehmigungsworkflow APIs

Workflow Engine

Bestellungen: • Bestellung • Bestellstatus • Verbuchung • Abwicklung • Warenempfang

Fax

Genehmigungsregeln

Bestellungen

Suche

Sourcing

Konfiguration

Content Management Multi-Lieferanten Katalog

APIs

Datenbank APIs

Contentmanagement, Katalog- und Sourcingdienste Katalog APIs

E-Mail

Transactionsserver

Bestelldaten APIs

Bestellanforderungen: • Bestellanforderungen • Statuscheck • Ausschreibungen • Verfügbarkeits- und Preisprüfung

Bestellanforderungen

Admin. APIs

Integration mit dem internen Informationssystem

Anforderungs- und Bestelldienste

EDI

Systemadministration Benutzerprofile

Beschaffungspolitik

Lieferantenprofile

Benutzer & Lieferanten

XML

Integration mit den Lieferanten-Informationssystemen

Sicherheitslayer (SSL)

Netzwerkinfrastruktur

Bild 3: Funktionalität und Komponenten von Desktop Purchasing-Systemen Kritischer Erfolgsfaktor der Akzeptanz eines DPS ist die Aktualität und Vollständigkeit der Produktinformationen im privaten MLK des Unternehmens. Im

7

Desktop Purchasing

privaten MLK sind im Idealfall vollständige und aktuelle Datensätze zu den verhandelten bzw. relevanten Produkten aller Anbieter abgelegt. Der Benutzer im Unternehmen muss sich also nicht die Kataloge verschiedener Anbieter besorgen und durchsehen, sondern lediglich den unternehmensspezifischen (privaten) MLK durchsuchen. Von verschiedenen Anbietern müssen dazu die Daten in einem Katalog konsolidiert und in einer Metastruktur entsprechend geordnet und abgelegt sein. Die Metastruktur ist eine Hierarchie von Produktkategorien und -gruppen, die sich aus den Anforderungen der unterschiedlichen Beschaffergruppen im Unternehmen ableitet. Die in Bild 3 dargestellten Systemkomponenten behandeln wir nachfolgend im Detail.

2.3 Content-Management 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 ContentManagements wollen wir nachfolgend aufgreifen:

m

Klassifikation von Content

m

Content-Aggregation

m

Personalisierung von Content

Klassifikation 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 bzw. Aktualisierung von MLK und erleichtern die strukturierte Suche in einem MLK. ERP-Systeme erlauben heute im Gegensatz zu den untersuchten DPS meist nur flache Klassifizierungshierarchien. So lässt beispielsweise SAP R/3 nur zwei Kategorisierungsebenen zu. Die wichtigsten und am häufigsten benutzten Klassifizierungsschemata sind folgende:

m m m

Der Standard Product and Services Code (SPSC) von Dun & Bradstreet [vgl. Dun & Bradstreet 1998], das Schema von Thomas Register [vgl. Thomas Register 1998] sowie das North American Industry Classification System (NAICS), das 1997 in den USA und Kanada und 1998 auch in Mexico die Standard Industrial Classification (SIC) abgelöst hat [vgl. U.S. Census Bureau 1997].

Derzeit orientieren sich alle untersuchten Systemanbieter am SPSC-Standard.

Institut für Wirtschaftsinformatik der Universität St. Gallen

Neben der Klassifizierung von Produkten ist es für Unternehmen ebenso wichtig, für jede Produktklasse zusätzlich die Attribute eines Produkt-Datensatzes festzulegen. Hier unterscheiden wir Charakter-Daten und Multimedia-Daten wie beispielsweise Produktbilder oder PDF-Files zur detaillierten Funktionsbeschreibung. Alle untersuchten Systeme erlauben die Definition spezifischer Datensätze für jede Produktklasse. Content-Aggregation 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 Intermediär, der sich auf die Aggregation und das Management von MLK spezialisiert hat. Lieferanten -Katalog 1

Käufer-Katalog 1

Lieferanten -Katalog 1

Lieferanten -Katalog 2

Käufer-Katalog 2

Lieferanten -Katalog 2

Käufer-Katalog 3

Lieferanten -Katalog 3

Lieferanten -Katalog 3

Käufer-Katalog 1 InformationBroker

Käufer-Katalog 2 Käufer-Katalog 3

Katalog-Replikation •Sicherstellen der Datenqualität •Einheitliche Metastruktur •Erstellen und Pflegen der privaten Kundenkataloge

Bild 4: Content-Aggregation und Replikation mit und ohne Information-Broker [vgl. Aberdeen Group 1998, S. 4] Die untersuchten Unternehmen adressieren die Replizierung und Aggregation von Content unterschiedlich: CommerceOne und Netscape verteilen an die Anbieter spezielle Software, um den Unternehmen einfach zu ermöglichen, die notwendigen Daten aus den entsprechenden Datenbanken auszulesen. Bisher haben sich keine allgemeingültigen Standards für den Austausch von Katalogdaten durchgesetzt. Ariba hat für diesen Zweck den auf SPSC und ANSI X.12 basierenden CIF-Standard entwickelt und offengelegt [vgl. Ariba 1998]. Die Anbieter 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 der Anbieter an. Chevron, ein Pilotkunde von Ariba, nutzt zusätzlich Harbinger als Content-Provider. Harbinger ist zuständig für die Bereinigung, Normalisierung und Formatierung der Katalogdaten sämtlicher Anbieter von Chevron.

9

Desktop Purchasing

Ähnliche Services offerieren CommerceOne/MCI mit dem MarketSite-System sowie TPN Register, ein Joint Venture von Thomas Register und GE IS. Personalisierung von Content Wir unterscheiden zwei Stufen der Personalisierung von MLK:

m

Personalisierte Unternehmenskataloge

Sowohl CommerceOne/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 MarketSite von CommerceOne/MCI führt zusätzlich Preisdegression automatisch nach. Sobald der Marktpreis unter den individuell verhandelten Kundenpreis sinkt, aktualisiert das MarketSite den MLK im Kundenunternehmen. Insbesondere bei stark preisdegressiven High Tech-Produkten ist dies von Vorteil.

m

Benutzersichten auf einen personalisierten Unternehmenskatalog

Alle untersuchten Systeme ermöglichen den Unternehmen, zusätzlich auf Mitarbeiteroder Benutzergruppenebene spezielle Sichten auf den MLK zu definieren. Je nach individuellem Benutzerprofil hat ein Mitarbeiter nach dem Einloggen ins System nur Zugriff auf spezielle Produktgruppen oder Produkte bis zu einem festgelegten Höchstpreis. Weitere Regeln sind vom Unternehmen frei bestimmbar.

2.4 Systemadministration Alle DPS bieten heute eine Administrationskomponente an, die auf Daten über Benutzerprofile, Anbieterprofile und Beschaffungsrichtlinien zugreift. Abhängig von diesen Daten m durchläuft eine Bestellanforderung einen Genehmigungsworkflow, bis sie zur Bestellung wird; m gibt das DPS einem Benutzer Zugriff auf eine bestimmte Sicht des MLK; m kann ein Benutzer nur bis zu einer definierten Budgetobergrenze Leistungen pro Zeiteinheit bestellen; m priorisiert das System Anbieter. In vielen Unternehmen sind die relevanten Profildaten schon in anderen Systemen hinterlegt. Das DPS kann entweder auf die Daten eines entsprechenden ERP/LegacySystems real-time zugreifen oder die Daten im DPS ablegen. Ausserdem bieten die

Institut für Wirtschaftsinformatik der Universität St. Gallen

meisten DPS LDAP Schnittstellen zu zentralen Directory-Servern an.

2.5 Prozessunterstützung und Systemfunktionalität Gegliedert nach den Prozessschritten des in Bild 1 dargestellten Kernprozesses stellen wir die Funktionalität der DPS dar: Katalog- und Sourcing-Dienste

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 entsprechend den nicht-konfigurierbaren Produkten 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äss dem Standard auswählen und beschaffen. Einige Hersteller planen, in Zukunft Schnittstellen Konfigurationskomponenten von Drittanbietern zu offerieren.

zu

optionalen

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 Anbietern verkauft wird, zeigt die Reihenfolge der gefundenen Angebote die Priorisierung entsprechend den Beschaffungsgrundsätzen des Unternehmens an. Für die Reihenfolge kann der niedrigste Preis ebenso wie die bevorzugte Beschaffung bei speziellen Anbietern 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:

11

Desktop Purchasing

CommerceOne unterstützt heute als einziger Anbieter über das ECN und die Möglichkeit einer Echtzeitanbindung das Abfragen von Lagerbeständen und Preisinformationen im ERP/Legacy-System des Anbieters. Über ein proprietäres TCP/IP-Protokoll und den Zugriff über APIs kann der Benutzer diese Daten über den Aufruf der entsprechenden Transaktionen im produktiven ERP/Legacy-System der Anbieter aus der Datenbank auslesen. 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 die Ausschreibung von RFQ (Request for Quotations). Bestellanforderung und Bestellung

Bestellanforderung: Der Besteller wählt Produkte und/oder Dienstleistungen aus dem MLK aus und stellt einen elektronischen Einkaufskorb zusammen, aus dem eine elektronische Bestellanforderung generiert werden kann. Häufig nachgefragte Leistungen können mit Bookmarks gekennzeichnet und zusammengestellte 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. Genehmigungsworkflow: Abhängig vom Benutzerprofil des Bestellers und von der jeweils bestellten Leistung durchläuft eine Bestellanforderung einen Genehmigungsworkflow, bevor sie das Unternehmen als Bestellung an einen Anbieter schickt. Das System informiert die jeweiligen Genehmigungsinstanzen über E-Mail. Bei den DPS identifizierten wir verschiedene Arten von Genehmigungsworkflows: Ein Genehmigungsworkflow pro Bestellung, Bestellanforderung oder bestellter Leistung. Bei den untersuchten Systemen bestehen Unterschiede in der Benutzerfreundlichkeit der Workflowkomponenten.

Institut für Wirtschaftsinformatik der Universität St. Gallen

Bestellungen erstellen und übermitteln: Nach der Genehmigung der Bestellanforderung erstellt das DPS die Bestellung für jeden Anbieter automatisch und verbucht diese im ERP/Legacy-System. Aus dem ERP/Legacy-System oder dem DPS selbst verschickt ein Unternehmen die Bestellungen per E-Mail, Fax oder EDI. Keines der Systeme unterstützt derzeit XML-Formate. Auch ist es heute nicht möglich, Bestellungen zurückzuhalten und zu bündeln, um ein grösseres Bestellvolumen pro Transaktion erzielen zu können. Lieferung und Empfang

Empfang von Leistungen: Der Empfang einer bestellten Leistung muss im DPS erfasst werden. Es gibt zwei Alternativen für den Warenempfang: Lieferung an den Schreibtisch des Bestellers/Benutzers oder eine zentrale Anlieferung (evtl. 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 Reporting-Funktionalitä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 und Verbuchung

Bezahlung: DPS unterstützen heute meist den Einsatz von Procurement Cards. Die untersuchten Pilotanwender nutzen die bestehenden Zahlungsmechanismen mit ihren Anbietern nach der Einführung eines DPS weiter. Die Anbieter sehen andere elektronische Bezahlungsarten wie Electronic Cash, Checks oder Smart Cards eher im Bereich des Business-to-Consumer Geschäfts als relevant an und unterstützen diese daher nicht. Finanzielle Verbuchung:

13

Desktop Purchasing

Ein Besteller muss bei der Bestellanforderung von Leistungen diese auf Kostenstellen verbuchen und gegebenenfalls als Anlagegut aktivieren. Bei allen untersuchten Systemen kann der Benutzer für jede Einzelleistung eine Kostenstelle angeben. Einige Hersteller bieten zusätzlich die Möglichkeit, die Kosten für eine Einzelleistung auf verschiedene Kostenstellen zu verteilen. Prozessführung

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össen der Beschaffung für jeden Mitarbeiter, jedes Produkt oder jede Produktgruppe bzw. jeden Anbieter definieren. In der Vergangenheit hatten Unternehmen nur wenig Möglichkeiten, Beschaffungsmuster und -volumen zu erheben oder Anbieter zu beurteilen.

2.6 Integration mit Legacy/ERP-Systemen Um Mehrfacheingaben von Daten zu vermeiden, muss das DPS mit dem internen Informationssystem des beschaffenden Unternehmens wie auch mit den Informationsystemen der Anbieter verbunden sein. Wir unterscheiden zwei Arten der Integration mit Legacy/ERP-Systemen:

m m

Asynchroner Austausch von elektronischen Dokumenten, beispielsweise über branchenspezifische EDI-Formate bzw. ALE-IDOCs bei SAP R/3; Direkter Aufruf von Prozeduren über RPCs (Remote Procedure Calls) mittels spezieller Schnittstellen, sogenannter APIs (Application Programming Interaces) der Applikationsebene des Legacy/ERP-Systems.

Integration mit dem internen Informationssystem Ein real-time Zugriff auf Daten im ERP/Legacy-System über RPC benötigt offengelegte APIs. Viele, insbesondere ältere Legacy-Systeme unterstützen keinen

Institut für Wirtschaftsinformatik der Universität St. Gallen

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 Releasestände der Software unverändert bleiben [s. Hantusch et al 1997, S. 113 ]. Die DPS-Anbieter nutzen BAPIs, um die entsprechenden Daten aus dem SAP R/3-System des Kundenunternehmens auszulesen und zurückzuschreiben. Integration mit dem Anbieter-Informationssystem 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 eines ERP/Legacy-Systems der Anbieter. Ausserdem verfügt die vorhandene Netzwerkinfrastruktur häufig nicht über die notwendige Funktionalität und Verlässlichkeit, um eine Echtzeit-Intregration zu verwirklichen. Aus diesem Grund findet der Datenaustausch mit Anbietern heute meist asynchron und nachrichtenbasiert statt. Unternehmen verwenden heute EDI, E-Mail und Fax zur Übermittlung von Dokumenten. CommerceOne ist der einzige Anbieter, der eine Echtzeit-Integration ermöglicht. Auf Wunsch integriert CommerceOne dazu das ERP-System eines Anbieters über die entsprechenden APIs mit dem ECN und dadurch mit dem DPS des beschaffenden Unternehmens. CommerceOne nutzt ein proprietäres TCP/IP-Protokoll. Der Transaktionsserver von CommerceOne steht bei MCI. MCI stellt den notwendigen Datendurchsatz durch dedizierte Frame Relay Schaltungen für die Kunden sicher.

3 Einsparungspotentiale von Desktop Purchasing-Systemen In einer Vorstudie erhebt das Unternehmen die Prozessanforderungen und Kostensenkungspotentiale. Einsparungspotentiale lassen sich grundsätzlich in drei Bereichen erzielen [vgl. Dolmetsch et al. 1998]:

m m

Beschaffungsprozess: Der Prozess 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 bei den Anbietern auszuhandeln. Andererseits erlauben die Systeme den Mitarbeitern, Produkte und Preise zu vergleichen und beim günstigsten Anbieter einzukaufen.

15

m

Desktop Purchasing Lagerbestände: Der gesamte Beschaffungsprozess 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 Realisierung von ECommerce-Applikationen und damit auch die Implementierung von DPS häufig keinen Platz auf der Agenda strategischer IT-Projekte im Unternehmen. Ein ECommerce-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. %-Anteil am gesamten Einsparungspotential

100 90 80 70 60 50 40 30 20 10 0 Legende:

0

6

12

18

24

30

Monate nach dem Produktivstart

= Einsparung durch das DPS = Einsparungen durch den Einsatz eines Katalog-Content-Providers

Bild 5: Typischer Verlauf realisierten Einsparungspotentials Was für die Umstellung der Prozesse gilt, trifft im gleichen Masse für die Adoption der Lieferanten/Anbieter zu. Bei der Einführung des DPS startet ein Unternehmen gewöhnlich mit den Produktkatalogen der 20 bis 30 wichtigsten Anbieter und nimmt später weitere Anbieter mit ihren Produktkatalogen in das System auf. Bild 5 zeigt den typischen Verlauf realisierter Einsparungen bei Unternehmen. Abhängig von der Akzeptanz des Systems und damit vom Verlauf der Kurve in Bild 5 sprechen Systemanbieter von einem Break-Even zwischen verursachten Projektkosten und realisierten Einsparungen nach etwa 1 bis 2.5 Jahren. Zum Zeitpunkt unserer Untersuchung konnten die befragten Unternehmen noch keine Angaben über den tatsächlichen ROI geben. Bis Ende 1998 hatten erst wenige Unternehmen einen DPS-Produktivstart. Erste Pilotanwender sind beispielsweise VISA, Mastercard, Chevron, Pacific Gas & Electric, Country of Los Angeles und Cisco in den USA.

4 Literatur [AberdeenGroup 1998]

Institut für Wirtschaftsinformatik der Universität St. Gallen

AberdeenGroup, Internet Procurement Automation: Separating the EC Wheat from the Chaff, Volume 11, Number 6, March 1998 [AMR 1997] AMR, Internet Enabled Indirect Procurement: A Low Risk/High Return Project?, Whitepaper, Boston, July 1997 [Ariba 1998a] Ariba Technologies, The Ariba ORMS: Operating Resource Management for the Enterprise, Product Whitepaper, Sunnyvale, March 1998 [Ariba 1998b] Ariba Technologies, Catalog Interchange Format (CIF), 2.1 Specification, Technical White Paper, Sunnyvale, April 1998 [Dolmetsch et al. 1998b] 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 [Gebauer/Beam/Segev 1998] Gebauer, J., Beam, C., Segev, A., Impact of Internet on Procurement, Workingpaper, Haas School of Business, Berkeley 1998 [Intersearch 1998] Intersearch Corp., National Purchasing Organisations User Group Survey, Palo Alto 1998 [Killen & Associates 1997] Operating Resources Management: How Enterprises can Make Money by Reducing ORM Costs, White Paper, Palo Alto 1997 [Netscape 1998a] Netscape, Netscape BuyerXpert - An Internet Commerce Application for Enterprise Purchasing, Product Whitepaper, Mountain View 1998, http://www.netscape.com/commapps/expert/buyerx_data.html [Netscape 1998b] Netscape, Netscape ECXpert Whitepaper, Product Whitepaper, Mountain View 1998, http://www.netscape.com/commapps/expert/ecxpert/ecxpert_white_paper.html [OBI 1998] The OBI Consortium, Open Buying on the Internet (OBI) Technical Specifications - Release V1.1, Juni 1998, http://www.openbuy.org/obi/library.html [SAP 1998] SAP AG, SAP Businss-to-Business Procurement, Whitepaper, Walldorf, Juni 1998, http://www.sap.com