Herausforderungen des Source-to-Pay Prozesses bei der Digitalisierung unter Anwendung des semantischen Objektmodells

1 Zielsetzung

Der unternehmerische Einkauf und deren Unterstützung durch geeignete IT-Systeme stand in den letzten zwei Dekaden im Vordergrund vieler unternehmerischer Optimierungsprojekte und Publikationen. Zur Zeit hat im transaktionalen Bereich verstärkt eine End-To-End-Betrachtung eingesetzt, d.h., dass der Einkauf mit der Kreditorenbuchhaltung zu einem Source-To-Pay-Prozess verschmilzt, um einen größtmöglichen Automatisierungsgrad zu erreichen. Fokus der dabei entwickelten Lösungen im ERP-Umfeld sind die transaktionalen Abwicklungen für indirekte Bedarfe und normierte Bedarfe von Serienfertiger und „First-Mover“-Branchen (z.B. Automobil). Sonderprozesse und insbes. komplexe und spezielle Bedarfe anderer Branchen wie des Maschinen- und Anlagenbaus wurden ausgeblendet. Mithilfe der Digitalisierung kann nun der Lückenschluss der Automatisierung im Source-to-Pay-Prozess durch die komplexe Vernetzung der einzelnen IT-Architekturen.
Ziel des Beitrags ist es dahingehend, die komplexen IT-Architekturen für die Digitalisierung im gesamtunternehmerischen Kontext von der Bedarfsgenerierung über den Einkauf bis zur Bezahlung (Source-to-Pay) zu beschreiben, unter dem Aufzeigen spezieller Anforderungen unterschiedlicher Geschäftstypen. Zur strukturierten Beschreibung wird dazu das von den Lehrstühlen der Wirtschaftsinformatik Prof. Ferstl und Prof. Sinz der Universität Bamberg entwickelte Semantische Objektmodell herangezogen. Abschließend werden noch kurz die Erfolgsfaktoren zur Vorgehensweise der Gestaltung und Entwicklung von Einkaufsarchitekturen vorgestellt

2 Rahmenbedingungen

2.1 Überblick über die historische Entwicklung im Source-to-Pay

Insbesondere die Einführungswelle von Enterprise-Resource-Planning (ERP) Systemen (z.B. SAP-R/3) prägte den Einkauf seit den 90er-Jahren nachhaltig. Durch das damit einhergehende Process Re-Engineering konnte die Beschaffung in die unternehmensinterne Wertkette effizienter integriert werden. Zunächst wurde im transaktionalen Procure-to-Pay-Abschnitt die operativen Bestellabwicklungszeiten deutlich reduziert sowie die nachgelagerten Schritte ‚Wareneingang‘, ‚Rechnungsprüfung‘ und ‚Zahlläufe‘ schon hochautomatisiert integriert. In einem zweiten Schritt wurde die aus den ERP-Systemen zusammengefassten Einkaufs-, Bestell- und Zahldaten in sogenannte Information Warehouses integriert. Zu unternehmensweiten Auswertungszwecken wurde diese zur Datenharmonisierung angereichert, wie zur z.B. der Vergleichbarkeit von Zahlungs- und Lieferbedingungen oder Materialgruppen.

Der eCommerce-Hype um die Jahrtausendwende lief ebenfalls in zwei Schritten. Einerseits wurde versucht, durch eAuctions neue Lieferanten und damit verbundene Einsparpotenziale zu erzielen. Während diese aber nicht einmal annähernd den versprochenen Erfolg erreichten, begann systemisch der Durchbruch mit elektronischen Katalog- und Warenkorb-Systemen wie z.B. das SAP-EBP, als eProcurement-Tool zur Abbildung von Bestellanforderungen und -Freigaben. Dadurch gelang es im indirekten Einkauf für geringwertige Güter enorme Prozesseinsparungen zu erzielen.


Abbildung 1: Historische Entwicklung von Optimierungsansätzen

Im Anschluss an diese Phase des Process-Re-Engineerings auf Basis von ERP-Einführungen wurde verstärkt strategische Einkaufsprojekte initiiert. Diese befassten sich vor allem mit dem zentralisierten Synergieansatz, dem sogenannten Materialgruppen-Management oder Category-Management. Ziel war es jeweils, die Bündelungspotenziale zwischen Teilkonzernen auf dem Markt zu nutzen. Mit dem Lead-Buyer-Ansatz wurde organisatorisch der Rahmen geebnet. Im kreditorischen Umfeld wurde ebenfalls die Zentralisierung vorangetrieben, mit dem Fokus unternehmensweite Zahlungsharmonisierung bzgl. Skonto-Ausnutzung und Doppelzahlungsanalysen.
Die notwendige Transparenz sollten dabei der weitere Ausbau der Information Warehouse bieten, in dem die Ausgaben eines Unternehmens in mehrere Dimensionen analysiert wurden (Spend Analysis). Da aber die Category-Management-Projekte oft von Unternehmensberatern durchgeführt werden, wurden die benötigten Daten aus dem Beschaffungssystem zwar abgezogen und in eine Extra-Datenbank der Unternehmensberater gespeichert, aber nur in den seltensten Fällen wurden die aufbereiteten Ergebnisse für spätere Analysen zurückgespielt.
Nach der Wirtschaftskrise hielt eine neue Welle der Transformation mit der Digitalisierung Einzug, um Wertschöpfungsnetze effizient auszubauen. Dabei gewann das aktive und integrierte Lieferantenmanagement mit den Top-Supplier weiter an Bedeutung. Mit den Kernlieferanten wurden Entwicklungspartnerschaften ausgebaut und ergänzt um das kreditorische aktive Cash-Management zur Cash-Flow-Steuerung.
Auch Unternehmensintern wurde der Trend des Business Process Outsourcing zu sogenannten Multi-Shared Service Center mit ganzheitliche Prozessketten fortgeführt. Dabei umfasst der Automatisierungsfokus alle Stufen, vom strategischen Einkauf über den operativen Einkauf bis hin zur Kreditorenbuchhaltung die Wertschöpfungsnetzwerke effizient zu gestalten. Hier spielt zunehmend die neue Digitalisierung eine wichtige Rolle, in der die bisherigen Standard-ERP-Prozesse durch „neue“ Smart Services und Cloud Lösungen übergreifend erweitert werden. So werden im strategischen Einkaufsanalyse erste Testimonials mit artificial und semantische Ansätze zu Big Data Marktanalyse durchgeführt. Front-end-Robots sollen die bislang noch komplexeren manuellen Tätigkeiten im operativen Einkauf und Kreditoren-Buchhaltung ersetzen und Artifical Intelligent Systeme soll die Kommunikation im Lieferanten-Helpdesk optimieren.

2.2 Das Semantische Objektmodell

Das Semantische Objektmodell (SOM) dient der Analyse und Gestaltung betrieblicher Systeme. Kern der Methodik ist eine Unternehmensarchitektur mit den Modellebenen Unternehmensplan, Geschäftsprozessmodell und Aufgabenträgerspezifikation (Abbildung 2 links).
Der Unternehmensplan stellt ein betriebliches System aus Außensicht dar. Er beschreibt das Objektsystem und das Zielsystem eines betrieblichen Systems. Das Objektsystem beinhaltet die Abgrenzung von Diskurswelt und Umwelt, sowie die Beziehungen zwischen Diskurswelt und Umwelt. Das Zielsystem bestimmt Art und Zweck der Leistungserstellung sowie den Erfüllungsgrad.


Abbildung 2:Unternehmensarchitektur der SOM-Methodik [FeSi08] und ihre Erweiterung [Krumb97]

Die Innensicht eines betrieblichen Systems wird in Form von Geschäftsprozessen gestaltet. Sie sind Lösungsverfahren für die Umsetzung des Unternehmensplans. Zur Abbildung von Geschäftsprozessen werden die Modellbausteine Leistung, betriebliches Objekt, betriebliche Transaktion, Aufgabe, Ereignis sowie deren Beziehungen verwendet.
Ein Geschäftsprozess wird durch ein betriebliches Objekt und ein oder mehrere betriebliche Transaktionen repräsentiert. Das betriebliche Objekt erstellt Leistungen, die über Transaktionen an empfangende betriebliche Objekte übergeben werden. Weitere betriebliche Transaktionen des Geschäftsprozesses dienen der Leistungsübernahme von anderen – sendenden – betrieblichen Objekten. Betriebliche Objekte sind eindeutig einem Geschäftsprozess zugeordnet. Betriebliche Transaktionen sind gemeinsamer Bestandteil angrenzender Geschäftsprozesse. Die Interaktion zwischen Geschäftsprozessen wird nicht-hierarchisch durch Anbahnungs- (A), Vereinbarungs- (V) und Durchführungs- (D) Transaktionen koordiniert (Verhandlungsprinzip). Innerhalb von Geschäftsprozessen werden im allgemeinen hierarchische Strukturen gemäß dem Regelungsprinzip mit Zielvorgaben (Z) bzw. mit Steuer- (S) und Kontroll- (K) Transaktionen verwendet. Diese Strukturaspekte werden in einem Interaktionsschema und einem Leistungsschema dargestellt.
In der dritten Ebene der Unternehmensarchitektur werden Aufgabenträger als Ressourcen zur Durchführung von Geschäftsprozessen betrachtet und dabei personelle Aufgabenträger (Personal) und maschinelle Aufgabenträger (insbes. Anwendungssysteme) unterschieden.
In der erweiterten Unternehmensarchitektur ist die Zuordnung von Anwendungssystemen zu den Aufgaben eines Geschäftsprozesses Gegenstand der Aufgabenträgerzuordnungsebene (Abbildung 2, rechts). Diese Modellebene umfaßt dann vier Sichten. Die Automatisierungssicht grenzt die zu automatisierenden Aufgaben und Transaktionen eines Geschäftsprozesses ab, die Anwendungssystemzuordnungssicht (Kartierung) ordnet den Aufgaben und Transaktionen Anwendungssysteme zu und die Integrationssicht erfaßt die Integrationsformen von Anwendungssystemen. Parallel dazu werden Aufgaben, die von Personen durchzuführen sind, in der Zuordnungssicht auf Organisationseinheiten abgebildet.

3 Gestaltung und Darstellung der Einkaufsarchitektur

Der Aufbau und die Gestaltungsmöglichkeiten des Source-to-Pay-Process werden anhand des Semantischen Objektmodells strukturiert (Siehe Abbildung 3).
Auf der Unternehmensplanebene wird die strategische Positionierung vorgenommen und das abgeleitet. Davon ausgehend werden auf der Geschäftsprozessebene end-to-end Source-to-Contract-Prozesse und deren besonderen Anforderungen vorgestellt. Diese bilden dann die Grundlage, um in der dritten und vierten Ebene die mögliche Informationssysteme als Aufgabenträger zu beschreiben und deren Unterstützungspotenzial für die Einkaufsprozesse zu zuordnen.


Abbildung 3: Fokus der SOM-Ebenen

3.1 Ebene U-Plan: Strategische Positionierung des Einkaufs

Die Aufstellung und die strategische Positionierung – also die Außensicht – von Source-to-Pay ist einerseits in die gesamtbetriebliche Wertschöpfungskette (Diskurswelt) und anderseits zu Lieferanten zu untersuchen (Siehe Abbildung 4).


Abbildung 4: Strategische Positionierung des Einkaufs

Innerhalb der Wertschöpfungskette lassen sich vier generische Grundtypen mit ihren spezifischen Zielsetzungen unterscheiden (Siehe Abbildung 5):

Geschäftstyp Zielsetzung
Produktgeschäft • Best-Preis
• Feste Lieferantenbasis
• Serielle Bedarfe und Abwicklung
Projektgeschäft • Einhaltung der Projektbudgets
• Sicherstellung des Fertigstellungsgrads
• Versorgungssicherheit der Baustelle
• Vertragskonformität zu den Endkunden
• Einmalbeschaffung
Servicegeschäft
(After-Sales)
• Schnelle Verfügbarkeit
• Langfristige Versorgungspotenziale
Indirekter Bedarf • Preisoptimierte Beschaffung von Gütern und Leistungen zum Ausbau und Erhalt der Betriebsmittel:
• Investitionsbeschaffung (z.B. IT, Produktionsmaschinen)
• Versorgung von wiederkehrenden Geschäftsvorfällen
(z.B. Mieten, Energie)
• Einmalbedarfe und Dienstleistungen
(z.B. Werkzeuge, Office, Zeitarbeit)

Abbildung 5: Zielsetzungen für Source-to-Pay nach Geschäftstypen

Vor dieser Zielsetzung ist prinzipiell auch die organisatorische Gestaltung des Source-to-Pay-Prozesses zu bestimmen. Auch wenn zunehmend der Trend zu gesamthaften Multi-Shared Service Center anhält, sind in der unternehmerischen Praxis diverse Organisationsmodelle vorzufinden.
Die Abgrenzung und Zuordnung der betrieblichen Objekte zu den Organisationsmodellen im Geschäftsprozess spielt in der Objektzerlegung sowie in der Aufgabenträgerebene (Ebene 3 und 4) eine wichtige Rolle. Denn hierbei gilt es aus der übergeordneteten Governance abgeleiteten Anforderungen (z.B. bzgl. Sicherheitstechnik, organisatorischer Regulierungen) zu erkennen und die Verantwortung dafür (z.B. Datensicherheit, Prozessleitung) eindeutig zu zuordnen. Im folgenden Beitrag wird hierauf jedoch nicht weiter eingegangen und das Steuerungskonzept für das Objekt „Procurement“ entsprechend vereinfacht dargestellt.

3.2 Ebene Geschäftsprozesse: Source-to-Pay-Prozesse

Die Gestaltung und das Zusammenwirken der Einkaufsprozesse im Sinne eines Source-to-Pay-Ansatzes wird in der Ebene der Geschäftsprozesse beschrieben. Die strategische Wertkette des Source-to-Pay lässt sich dazu in drei Interaktionspakete zerlegen. Dies beschreibt einen ganzheitlichen Kreislauf; vom Bedarfsfall, über die Bestellung der Anlieferung, bis zur Bezahlung (Siehe Abbildung 6). Die Ausprägung der Interaktionssegmente ist nach Geschäftstyp und strategischer Ausrichtung zu verfeinern.
Im Einkauf wird zwischen den strategischen und operativen Aufgaben unterschieden. Im strategischen Einkauf wird die Bedarfsermittlung, Ausschreibung und Verhandlung von Kontrakten fokussiert. Der operative Einkauf umfasst die Bestellabwicklung sowie die logistische Versorgung. Jedoch kann in Abhängigkeit von den Geschäftstypen auch die physikalische Logistik organisatorisch abgegrenzt werden. In der unternehmerischen Praxis von Großkonzernen wird organisatorisch manchmal auch noch der taktische Einkauf abgegrenzt. Dabei werden Einmalbedarfe unterhalb einer Wertgrenze wie im strategischen Einkauf auch ausgeschrieben und bestellt. Besonders
Die Kreditorenbuchhaltung ist in der Regel zentralisiert je nach Geschäftstyp ist jedoch Grade der Integration zu Anlagenbuchaltung zu beachten.


Abbildung 6: Interaktionssegmente im Einkauf

3.2.1 Procurement Cycle

Im Produktgeschäft startet der Einkauf auf Basis von Bedarfsprognosen zu einem Produkt (siehe Abbildung 7, Procurement Cycle). Auf deren Basis werden Ausschreibungen zu den einzelnen Produktkomponenten durchgeführt. Hier, insbesondere im Seriengeschäft, spielt die Zusammenarbeit mit der Entwicklungsabteilung eine maßgebliche Rolle. Die Spezifikationen sind so zu neutralisieren, dass die Bedarfe ausschreibbar sind, um preisgünstige und vergleichbare Lieferantenangebote zu erhalten.
Nach Verhandlung wird mit den Lieferanten ein Rahmenvertrag geschlossen und als Bezugsquelle an den operativen Einkauf bzw. die Business Unit gemeldet.


Abbildung 7: Produktgeschäft

Das Projektgeschäft ist dagegen kundenauftragsorientiert (Siehe Abbildung 8 – Procurement Cycle). Dabei werden mehr und mehr komplexe Systembedarfe aus Material und Dienstleistung – insbesondere im Bau auch Gewerk genannt – nachgefragt. Die Lieferanten sollen auf Basis der Bauspezifikation des Endkunden ihre technischen Lösungsvorschläge für das eine spezifische Projekt einreichen. In mehreren Zyklen werden diese zusammen mit der Konstruktion auf ihre Umsetzbarkeit geprüft und detailliert. Nach der technischen und kommerziellen Freigabe wird dann der Lieferant dafür ausgewählt und ein Individualvertrag bzw. eine Einzelbestellung ausgelöst.
Die Herausforderung im Projektgeschäft liegt dabei darin, dass für die termingerechte Abarbeitung des Kundenprojektes eine große Anzahl von unterschiedlichsten Einzelbedarfen in einem sehr engen Zeitfenster im Markt platziert werden müssen. Entsprechend aufwendig für den Einkauf ist die Kontrolle des Angebotsstatus einer Ausschreibung.


Abbildung 8: Projektgeschäft

3.2.2 Supply Cycle

Im Supply Cycle werden die operativen Einkaufsaktivitäten dargestellt.
Im Produktgeschäft bezieht der operative Einkauf gegen den im ‎Kapitel 3.2.1 beschriebenen Rahmenvertrag. Auf Basis des Dispositionslaufs werden aus der Produktionsplanung Bestellanforderungen ausgelöst, die dann; wie meist im Seriengeschäft, als Lieferabruf oder in Form einer Einzelbestellung mit Bezug zum Rahmenvertrag an den Lieferanten gesendet werden.
In der Lieferversorgung stellt der stetige Ausbau logistische Konzepte wie z.B. Just-in-time, Just-in-Sequence, Vendor Managed Inventory eine große Herausforderung an die Lieferabwicklung. Mit einem ständigen Lieferstatusreport (Order Trace and Tracking) soll gewährleistet werden, dass die Produktionskette geschlossen bleibt und etwaige Lieferstörungen rechtzeitig erkannt werden, so dass in solch einem Fall durch Umplanung kein Produktionsstillstand entsteht.

Im Projektgeschäft ist mit der eigentlichen Bestellung bereits der Übergang zum operativen Einkauf fließend. Jedoch hat hier der operative Einkauf die Überwachung der Bestellabwicklung zur Aufgabe. Zum einen muss durch ein Expediting (Terminverfolgung) sichergestellt werden, dass der Lieferant seinen Systemvertrag erfüllt, zum anderen ergeben sich während der Bauzeit konstruktive Änderungen und in der Regel auch Terminverschiebungen, die durch Bestelländerungen im Einkauf an die Lieferanten weitergegeben werden müssen.
Auch die Anlieferung im Projektgeschäft geschieht oftmals dezentral – direkt auf die Baustellen. Hier obliegt es dem operativen Einkauf, die Koordination und Sicherstellung des Informationsflusses bzgl. des Lieferstatus und des Wareneingangs.

3.2.3 Invoice Cycle

Mit dem Invoice Cycle wird das letzte Interaktionssegment beschrieben.
Im Produktgeschäft, vor allem im automotiven Seriengeschäft, wird die Zahlungsabwicklung vermehrt über das Gutschriftsverfahren abgewickelt. Zielsetzung ist es hier, die aufwendige Rechnungsprüfung auf den Lieferanten zu übertragen. Nach Anlieferung wird durch die Wareneingangsbuchung die Kontrolle der Waren und die Rechtmäßigkeit der Lieferung gegen den Lieferabruf durchgeführt. Aus diesen Informationen werden die Zahlungen vorbereitet und der zugehörige steuerliche Beleg als Gutschriftsanzeige an den Lieferanten versendet. Der Lieferant hat nun zu prüfen, ob der Betrag mit seiner Lieferung übereinstimmt.
Im Projektgeschäft findet die Zahlungsabwicklung auf Basis der Rechnungsstellung statt. Über das Abrechungsmanagement wird u.a. auch der kaufmännische Fertigstellungsgrad errechnet. Die Transaktionen sind aber wesentlich heterogener und müssen individuell geprüft und freigegeben werden. Durch unterschiedliche Liefer- und Leistungspakete zu unterschiedlichen Zeitpunkten (z.B. Fundamente und Unterwasserkomponenten im Schiffsbau vorab, Hauptlieferung, Inbetriebnahmen, Ersatzteilpakete zur Übergabe), sind die Zahlungsbedingungen aber systemisch oft nur schwer abbildbar. Zum anderen sind im Projektgeschäft Anzahlungen üblich. Dabei ist prinzipiell auch die Integration zur Anlagenbuchhaltung wichtig, die hier vereinfacht in der Business Unit dargestellt ist. Während die Liefer- und Leistungsrechnungen zu Aktivierung (Anlagen im Bau) herangezogen werden, sind die Anzahlungen „nur“ Cash-Flow wirksam.
Aufgrund von nicht zu vertretenden Terminverschiebungen werden Rechnungen auch oft bereits vor Leistungsfertigstellung gestellt. Darüber hinaus gehende Mehrkosten, wegen Änderungsverlangen oder Baubehinderungen, werden ebenso in Rechnung gestellt. Andererseits wird zur Abnahme vom Zurückbehaltungsrecht Gebrauch gemacht, um Lieferanten zur Fertigstellung ihres Auftrags zu bewegen.

3.3 Ebene Aufgabenträger und –zuordnung

In der Ebene Aufgabenträger lässt sich im Rahmen der SOM-Methodik das Datenmodell und der personelle Einsatz ableiten. Durch den Einsatz von unterschiedlicher Standardsoftware ist dabei aber auch die Zuordnung des angebotenen Funktionsspektrums in das Interaktionsmodell (Kartierung – Aufgabenträgerzuordnung) eine wichtige Erweiterung der Methodik. Damit lässt sich vereinfacht die Funktionsparametrierung sowie Schnittstellen zwischen den Softwarepaketen identifizieren.


Abbildung 9: schematische Zuordnung von Funktionsbausteinen

Nach der Zuordnung der Software-Komponenten können relevante Parameter identifiziert und im Geschäftsprozessmodell dokumentiert werden. Beispielsweise kann der Bedarf („DEMAND“) weiter untergliedert werden und spezifische Freigaberegeln („APPROVAL“) nach Kategorie und Wertgrenze im Customizing abgebildet werden. Ferner kann die Folge-Aktivität z.B. anhand des Positionstyps gesteuert werden. Da ein Kernsortimentsartikel in einem Lieferantenkatalog i.d.R. bereits verhandelt ist, kann es mit einem Flag „Core Assortment“ ausgezeichnet und dadurch ohne weitere Einkaufsaktion direkt bestellt werden. Für eine Freitextposition dagegen sehen die Einkaufsregularien normalerweise vor, dass mindestens 3 Angebote eingeholt werden müssen.

Der Automatisierungsgrad von Transaktionen wird durch Symbole dargestellt:

  • vollständig
  • teilautomatisiert
  • nicht automatisiert


Abbildung 10: vereinfachtes SOM Vorgangs-Ereignis-Schema für Kernsortimentsartikel

Der Aktivitätenablauf wird in der SOM-Methodik im Vorgangs-Ereignis-Schema des Geschäftsprozessmodells dargestellt. Abbildung 10 zeigt dazu einen Ausschnitt der Ablaufsicht für Geschäftsprozesse, Katalogbestellung von Kernsortimentsartikel. Die teilautomatisierten Vorgänge zeigen dabei, wo die Nutzerschnittstellen für Einkäufer oder Besteller, als auch explizite Freigabe notwendig sind. Ferner zeigt es die Schnittstellen zwischen den einzelnen Standard-Softwarepaketen. So greift beispielsweise das SAP-EBP-System mittels einer sogenannten OCI-Schnittstelle auf das Catalogue-System zu. Es zeigt desweiteren, inwieweit Folgetransaktionen vollständig automatisiert durchgeführt werden können, wenn die notwendigen Konfigurationsparameter hinterlegt sind. So können die EBP Baskets im SAP-R/3 durch die BAPI-Schnittstelle direkt als PO angelegt und über EDI-Schnittstellen auch an den Lieferanten übermittelt werden.

3.4 Reporting

Eine besondere Rolle ist das Reporting im Source-To-Pay-Process. Basis hierfür sind die sogenannten Procurement Analytics (Siehe Abbildung 3, II.1.-3.). Mit Hilfe von multidimensionalen Analysen soll ermöglicht werden, die Bedarfe und die Ausgaben nach Kategorien in einem Portfolio zu segmentieren, sowie die Bestell-, Liefer- und Zahlungskonditionen zu vergleichen, um daraus Einkaufs- und Skonto- bzw. Cash-Flow-potenziale zu ermitteln. Dazu werden die Kategorien bzgl. deren strategischer Wichtigkeit, unter Berücksichtigung der Einkaufs- und Lieferantenmacht sowie der Relevanz für die Wertkette gewichtet. Die Potenziale in den einzelnen Kategorien werden unter dem Einsatz von Einkaufshebeln (z.B. Ausschreibungen, Volumen- und Bedarfsbündelung, Spezifikationsbereinigung, Prozessoptimierung) sowie Zahlungskonditionen (Zahlungsziele, nachlaufende Auszahlungen, vorauslaufende Skontoeffekte) bestimmt. Ferner findet eine Priorisierung statt. In der Regel werden schnell realisierbare Einkaufserfolgpotentiale, sogenannte „Quick-wins“, dann sofort angegangen.
Bei den Analysen wird auf Geschäftsprozessebene zwischen Ad-hoc- und Standardreports unterschieden. In Ebene 3 wird das Datenmodell (z.B. Star-Datenmodell) für ein geeignetes Einkaufsinformationssystem und dessen Anreicherung beschrieben, so dass Analysen über alle Business Units vergleichbar und standardisierbar sind. Entsprechend sind die notwendigen Geschäftsinformationen bei den Transaktionen mitzugeben. Da in der Regel bei Großkonzernen unterschiedliche Systeme im Einsatz sind, werden die Geschäftsinformationen beim Datenimport durch einheitliche Übersetzungstabellen (für z.B. Liefer- und Zahlungsbedingungen, Währungen, Liefereinheiten) im Einkaufsinformationssystem standardisiert. Zunehmen werden aber auch Big-Data Ansätze integriert. Damit sollen zur Lieferantenansteuerung Marktpreisentwicklung und Cash-Flow-Prognosen durch predictive Analytics optimiert werden.

4 Ganzheitliche Vorgehensweise zur Gestaltung und Entwicklung von Source-toPay-Architekturen

Die vorangegangen Kapitel haben aufgezeigt, dass IT-Systeme im Source-to-Pay, über die gesamthafte Prozesskette und in ihrer technischen Umgebung zu betrachten sind. Durch die neuen Digitalisierungsansätze nehmen zudem kleine agile Anwendungen, die über einen kurzen Zeitablauf auch noch variieren, zu. Die klassische Einführungsvorgehensweise von IT-Systemen genügt daher gerade nur noch für eine Momentaufnahme, eine nachhaltige Entwicklung ist aber nicht gewährleistet. Entsprechend sind zwingend Implementierungen um ein agiles Programm-Management über alle SOM-Ebenen, begleitet aus dem Fachbereich, zu erweitern. Dies ermöglicht es, die dynamischen und globalen Herausforderungen durch Zentralisierung und Multi-Shared Services als weiteren wichtigen Erfolgsschlüssel zu berücksichtigen. Dahingehend ist auch ein begleitendes Change Management wichtig, um die Flexibilität und Wettbewerbsfähigkeit bei Mitarbeiter und der Systembetreuer ständig zu vergegenwärtigen.

5 Literatur

A.T. Kearney, „Einkaufsschachbrett“, Berlin, 2009
Ferstl, O.K., Sinz, E.J.: Grundlagen der Wirtschaftsinformatik, 6. Aufl., 2008
Krumbiegel J.: „Integrale Gestaltung von Geschäftsprozessen und Anwendungssystemen in Dienstleistungsbetrieben.“ Wiesbaden, 1997.
Hazebrouck, J.-P.; „Braucht der Einkauf ein Supplier Relationship Management Tool?“
Vortrag Im Rahmen der Deloitte Consulting Kundenkonferenz, Düsseldorf, 2004
Hazebrouck, J.-P.; „Strukturierung von Einkaufsarchitekturen unter Anwendung des Semantischen Objektmodells“, S. 211-224; in Suchan, C. / Frank, J. „Analyse und Gestaltung leistungsfähiger IS-Architekturen“, Berlin, 2012
SAP: „SAP Business Maps”: http://www.sap.com/germany/solutions/business-suite/srm/businessmaps/index.epx, 2011

Originaler Text: It-Architekturen für PTP-v4