Implementierung eines Desktop Purchasing Systems anhand eines Fallbeispiels
Dem Fallbeispiel liegen folgende Punkte zugrunde:
Die Wahl der Software fiel auf SAP EBP, da einerseits das Unternehmen bereits SAP R/3 als ERP-System im Einsatz hatte und sich im Zuge der Evaluierung mehrerer möglicher Lösungen SAP EBP sich als die praktikabelste und auch kostengünstigste herausgestellt hatte.
Die Projektziele waren:
Treiber des Projekts war der technische Einkauf. Dem Einkauf stand mit Desktop Purchasing erstmals die technische Möglichkeit zur weiteren Dezentralisierung zur Beschaffung von MRO-Teilen zur Verfügung. In diesem Kontext ist es wichtig zu bemerken, dass es bereits vor der Einführung des DP-Systems starke Tendenzen zur Dezentralisierung der operativen Beschaffung gegeben hatte. Somit waren die vielerorts gepriesenen Einsparungseffekte in diesem Unternehmen nur noch eingeschränkt vorhanden, da sie durch langjährige Praxis bereits zum Teil vorweggenommen worden waren. Andererseits unterstütze diese Tatsache das Verständnis bei den Mitarbeitern, denen mit DP ein praktikables Tool zur Beschaffung in die Hand gegeben werden sollte.
Ein wichtiger Punkt bei der Einführung eines DP-Systems ist das Instrument der Delegation, mit dem man einerseits eine Entlastung des Einkaufs zu erreichen versucht, andererseits die Kompetenz der Bedarfsträger dahingehend erweitert, als dass diese mit dem DP-System in einem definierten Rahmen selbst beschaffen können. Dies bedeutet für den einzelnen Bedarfsträger eine Erweiterung seiner Kompetenzen, was einen nicht unwesentlichen Motivationsfaktor darstellt. Auf der anderen Seite kann sich der Einkauf auf seine wesentliche Aufgabe - die des strategischen Einkaufs - konzentrieren. Bei dem Unternehmen aus diesem Beispiel gab es für die einzelnen Bedarfsträger - auch auf unteren Ebenen - Zielvereinbarungen in Form von Budgets für die Beschaffung von MRO-Materialien, bei deren Erreichung (bzw. Unterschreitung) monetäre Bonifikationen gewährt werden. Durch diese Tatsache konnte ein sehr wesentlicher Aspekt bei der Einführung des DP-Systems realisiert werden: Es gibt in diesem System keinerlei automatische Workflows! Wesentlich ist dieser Umstand deshalb, weil einerseits die Verlockung, Workflows zu implementieren sehr groß ist, da DP-Systeme diese auf komfortable Weise ermöglichen. Andererseits vergisst man nur allzu gerne, dass DP-Systeme eigentlich zur Einsparung von Prozesskosten, zur Entlastung von höheren Hierarchieebenen und zur Beschleunigung des Beschaffungsprozesses geschaffen wurden und durch Genehmigungsworkflows diese Ziele ad absurdum geführt werden.
Der Katalog sollte als Inhouse Katalog implementiert werden. Die Gründe hierfür waren:
Die Pflege des Katalogs übernahm der Implementierungspartner. Als Katalogsoftware wurde der im SAP EBP Paket enthaltene Standardkatalog verwendet, um möglichst geringe Probleme mit der Schnittstelle zwischen Katalog und DP-System zu haben. Außerdem war dieser Katalog im Gesamtpaket enthalten, weswegen für die Katalogsoftware keine weiteren Kosten anfielen.
Da die Artikeldaten im elektronischen Katalog zur Verfügung stehen und diese Daten (Bezeichnung, Mengeneinheit, Artikelnummer, Preis, ...) direkt vom jeweiligen Lieferanten kommen, bietet sich erstmals die Möglichkeit, mit Lieferanten sinnvoll ein Gutschriftsverfahren einzurichten, das die Prozesskosten bei der Rechnungsprüfung mit einem Schlag auf 0 reduziert, da die Tätigkeit der Rechnungsprüfung wegfällt. Bei diesem Verfahren wird der Preis (aus dem Katalog) mit der bestätigten Menge (aus der Wareneingangsbuchung, die der Bedarfsträger selbst erfasst; siehe unten!) multipliziert und dieser Betrag dem Lieferanten in Form einer Gutschrift übermittelt. Beim herkömmlichen Verfahren würde der Lieferant eine Rechnung schicken, die dann manuell der Bestellung (bzw. der Wareneingangsbuchung) gegenübergestellt werden müsste.
Ein weiterer Punkt war die strikte Orientierung am SAP-Standard. Ausschlaggebend war das Ziel, Probleme, die bei der Aktualisierung der DP-Software entstehen, weil sie bei der Implementierung modifiziert worden war, möglichst zu vermeiden.
Der Beschaffungsprozess, der letztendlich definiert wurde, hat folgendes Aussehen:
Der linke Teil stellt das DP-System dar, der rechte das ERP-System (SAP R/3).
Entscheidend ist hier der Umstand, dass sich der Bedarfsträger lediglich im linken Teil bewegen muss und ihm das "Expertensystem" SAP R/3 "erspart" bleibt. Dennoch hat er stets aktuelle Informationen über den Fortlauf des Prozesses zur Verfügung, da die Daten zwischen beiden Systemen ständig aktualisiert werden.
Die Tätigkeiten des Bedarfsträgers beschränken sich auf Folgende:
Ein wichtiger Aspekt ist die Behandlung von Abweichungen und Fehlern: Das oberste Ziel bei der Einführung eines DP-Systems ist die Vereinfachung der Oberfläche für den Bedarfsträger als Basis für die Dezentralisierung. Würde man nun alle möglichen Fälle, die im Ablauf eines Bestellprozesses auftreten können, berücksichtigen, so erreichte man bald die Komplexität eines ERP-Systems. Genau diese Komplexität will man aber vermeiden, daher wird im DP-System nur ein Standardfall abgebildet. Alle Abweichungen (z.B. fehlerhafte Ware, Unterlieferung, Überlieferung) werden außerhalb des DP-Systems abgebildet und direkt zwischen Bedarfsträger und Lieferanten abgeklärt. Entscheidend ist immer das Wissen, dass der Lieferant den Betrag, der aus Wareneingangsmenge mal Katalogpreis resultiert, erhält (wichtig z.B. bei Unterlieferungen).
Die nachstehende Übersicht soll die Unterschiede zwischen den Prozessen vor und nach der Einführung des Desktop Purchasing Systems veranschaulichen. Die Werte stellen den Zeitaufwand für jeweils eine Position dar.
|
Prozess-schritt
|
Beschreibung des Prozessschrittes
|
Ungefährer Zeitaufwand ohne Desktop Purchasing System [min]
|
Ungefährer Zeitaufwand mit Desktop Purchasing System [min]
|
|
1
|
Bedarfsträger benötigt Artikel |
0
|
0
|
|
2
|
Suche in Papierkatalog |
10
|
-
|
|
3
|
Suche in elektronischem Katalog |
-
|
5
|
|
4
|
Erstellung des Einkaufskorbs |
-
|
3
|
|
5
|
Erstellung der Bestellanforderung |
10
|
-
|
|
6
|
Identifizieren des geeigneten Rahmenvertrags |
5
|
-
|
|
7
|
Anlegen der Bestellung zum Rahmenvertrag (mit Bezug auf die Bestellanforderung) |
5
|
-
|
|
8
|
Übermittlung der Bestellung an den Lieferanten |
5
|
-
|
| Summe des Zeitaufwands für die Erstellung der Bestellung |
35
|
8
|
|
9
|
Prüfung der Ware beim Empfang der Ware
|
2
|
2
|
|
10
|
Buchen des Wareneingangs im System |
5
|
2
|
| Summe des Zeitaufwands für die Erstellung des Wareneingangs |
7
|
4
|
|
11
|
Erfassung der Rechnung im ERP-System
|
5
|
-
|
|
12
|
Prüfung der Rechnung mit Bezug auf die Bestellung |
8
|
-
|
| Summe des Zeitaufwands für die Rechnungsprüfung |
13
|
0
|
|
9
|
Gesamtbearbeitungszeit je Bestellposition
|
55
|
12
|
Anmerkungen:
Die Ziele konnten zum größten Teil realisiert werden:
Die Desktop Purchasing Lösung von SAP (EBP: Enterprise Buyer Professional) besteht im Wesentlichen aus folgenden Komponenten:
Es gibt einerseits eine Schnittstelle zwischen EBP-System und Katalog und andererseits die Schnittstelle zwischen EBP-System und dem Backend System (ERP-System), in dem die betriebswirtschaftlichen Prozesse abgebildet sind.
Katalogschnittstelle: Für diese Schnittstelle hat SAP ein Format definiert, die sogenannte OCI-Spezifikation. Diese Spezifikation regelt, welche Daten zwischen dem Katalog und dem EBP-System zur Laufzeit (also dann, wenn ein Bedarfsträger Artikel im Katalog ausgewählt hat und diese ins EBP-System übernehmen möchte) ausgetauscht werden. Dazu gehören
Schnittstellen zwischen EBP- und ERP-System: Über diese Schnittstellen erfolgt die Kommunikation zwischen dem EBP-System und dem ERP-System. Es werden Stamm- und Bewegungsdaten ausgetauscht:
Als Kataloge kommen im Prinzip alle verfügbaren Katalogsysteme in Frage, die die von SAP vorgegebene OCI-Spezifikation erfüllen. Die Auslieferung des SAP EBP-System erfolgt jedoch bereits mit einem Katalog, nämlich dem von Requisite (www.requisite.com), daher ist dieser Katalog kostenlos.
Einige weitere Kataloge, die die OCI-Spezifikation erfüllen, sind (Liste nicht vollständig):
Weitere Informationen findet man auf der SAP EBP Homepage (http://www.sap.com/solutions/e-procurement/).