Die aktuelle Bedeutung von RosettaNet als Standard im e-business Datenaustausch. Diplomarbeit

Transkript

1 Die aktuelle Bedeutung von RosettaNet als Standard im e-business Datenaustausch Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Universität Hannover vorgelegt von Name: Troegner Vorname: Dagi Geb. am: in: Witzenhausen Erstprüfer: Prof. Dr. techn. W. Nejdl Zweitprüfer: Prof. Dr. U. Schmidt Hannover, den

2 Copyrighthinweis Die in dieser Arbeit verwendeten Firmennamen, Warenzeichen und Produktbezeichnungen dienen nur Identifikationszwecken. Sie verbleiben im alleinigen Eigentum der jeweiligen Rechteinhaber.

3 Inhaltsverzeichnis Abkürzungsungsverzeichnis I Abbildungsverzeichnis III Tabellenverzeichnis IV 1 Einleitung Ausgangslage Zielsetzung und Aufbau Abgrenzung Die Bedeutung von Standards für den e-business Datenaustausch Darstellung und Analyse wesentlicher Standards Klassifikation von Standards Ebenen einer standardisierten Interaktion Datenebene Prozessebene Kommunikationsebene Industriefokus Objekt des Datenaustausches Prozessbereich Überblick der Systematisierungskriterien Grundlagen der wichtigsten Standards EDI Varianten Kommunikation Klassifikation Stärken und Schwächen Ausblick cxml Kommunikation Klassifikation Stärken und Schwächen Ausblick xcbl Kommunikation Klassifikation Stärken und Schwächen Ausblick

4 3.2.4 BizTalk Kommunikation Klassifikation Stärken und Schwächen Ausblick ebxml Kommunikation Klassifikation Stärken und Schwächen Ausblick Gegenüberstellung der Ergebnisse Grundlagen von RosettaNet Entwicklung und Ziele Das RosettaNet-Konsortium Spezifikationen und Services Grundidee Partner Interface Processes RosettaNet Implementation Framework Dictionaries Product and Partner Codes Services Kommunikation Klassifikation Implementierungsprozess Programme RosettaNet Automated Enablement (RAE) Weiterentwicklungen PIPs Implementierungskosten Steigerung der Effizienz Ausblick Stärken und Potenzial von RosettaNet Hintergrund und Analyse wesentlicher Stärken Nutzen für Anwenderunternehmen Ordering Invoicing Zusammenfassung der Ergebnisse

5 6 RosettaNet: Success Stories Ordering Firmeninformation Ausgangssituation Zielsetzung Implementierung von RosettaNet Nutzenaspekte Invoicing Firmeninformation Ausgangssituation Zielsetzung Implementierung von RosettaNet Nutzenaspekte Anwendung und Verbreitung von RosettaNet Verbreitung Akzeptanz Unterstützung durch Standardsoftware i2 Technologies SAP Microsoft Oracle Peoplesoft Siebel Bewertung der Standards Bewertungskriterien Strategische Kriterien Investitionssicherheit Kostenfaktoren Technische Kriterien Anpassungsfähigkeit Skalierbarkeit Sicherheit Funktionale Kriterien Leistungsfähigkeit Unterstützung Vergleich und Bewertung

6 9 Fallstudie IBM (confidential) Schlussbetrachtung Anhang: Liste aktueller PIPs Glossar Literaturverzeichnis

7 Abkürzungsverzeichnis Abkürzungsverzeichnis ANSI: ASC: ASCII: BFC-Server: BPSS: CBL: CC: CPA: CPI: CPP: CPPA: CRM: cxml: DSW: DTD: DUNS: ebms: ebxml: EC: EDI: EDIFACT: EMEA: ERP: ESI: ESW: FTP: GTIN: HTTP: HTTPS: HVEC: IAO: IGF: IMB: IMS: IOL: ISO: KMU: LG: MIME: MNC: MQM: MSMQ: OASIS: ODETTE: PAO: PC/S: PGP: American National Standards Institute Accredited Standards Committee American Standard Code for Information Interchange BizTalk Framework Compliant Server Business Process Specification Schema Common Business Library Core Components Collaboration Protocol Agreement Customer Presentable Invoice Collaboration Protocol Profile Collaborative Profile Protocol Customer Relationship Management commerce XML Distributed Software Document Type Definitions Data Universal Numbering System e-business Messaging Service electronic business extended Markup Language Electronic Components Electronic Data Interchange Electronic Data Interchange for Administration, Commerce and Transport Europe, Middle East and Afrika Enterprise Resource Planning EMEA Single Invoicing System Entitled Software File Transfer Protocol Global Trade Item Number Hypertext Transfer Protocol HTTP Secure High Value Easy Configured Institut für Arbeitswissenschaft und Organisation IBM Global Financing Intelligent Message Broker IBM Messaging System InvoiceOnline International Organization for Standardization Kleine und mittlere Unternehmen Logistics Multipose Internet Mail Extensions Multinational Companies Message Queue Manager Microsoft Messaging Queue Organization for the Advancement of Structured Information Standards Organization for Data Exchange by Tele Transmission in Europe Passport Advantage Online PartnerCommerce/Servers Pretty Good Privacy I

8 Abkürzungsverzeichnis PIP: Partner Interface Process PMP: Payment Milestone Program PO: Purchase Order RAE: RosettaNet Automated Enablement RNBD: RosettaNet Business Dictionary RNIF: RosettaNet Implementation Framework RNTD: RosettaNet Technical Dictionary S/MIME: Secure / Multipose Internet Mail Extensions S/MIME/IETF: Secure / Multipose Internet Mail Extensions / Internet Engineering Taskforce SCM: Supply Chain Management SM: Semiconductor Manufacturing SMTP: Simple Mail Transfer Protocol SOAP: Simple Object Access Protocol SOL: Statement Online SP: Solution Providers SSL: Secure Sockets Layer SWIFT: Society for Worldwide Interbank Financial Telecommunication TC: Telecommunication TPIR-PF: Trading Partner Implementation Requirements Presentation Format TPIR-PIP: Trading Partner Implementation Requirements Partner Interface Process TxHub: TransactionHub UCC: Uniform Code Council UML: Unified Modeling Language UN/EDIFACT: United Nations Rules for Electronic Data Interchange for Administration, Commerce and Transport UN/SPSC: United Nations / Standard Product and Service Codes URI: Unique Remittance Identifier VAN: Value Added Network W3C: World Wide Web Consortium WPG: World Peace Group xcbl: extended Common Business Library XML: extensible Markup Language II

9 Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1: Zusammenhang der Systematisierungskriterien Abbildung 2: EDI- Szenario Abbildung 3: Punch-Out Chaining Abbildung 4: Übersicht des Dokumentenaustausches mit cxml Abbildung 5: Funktionsbereiche von xcbl-dokumenten Abbildung 6: Dokumentenaustausch mit BizTalk Abbildung 7: Aufbau einer BizTalk-Nachricht Abbildung 8: Kommunikationsablauf mit ebxml Abbildung 9: Aufbau des RosettaNet-Konsortiums Abbildung 10: Grundidee der RosettaNet-Spezifikationen Abbildung 11: Sequenzdiagramm des PIP 3A Abbildung 12: PIP-Interaktionsdiagramm Abbildung 13: RosettaNet Business Message Abbildung 14: Kommunikation über RosettaNet Abbildung 15: B2B-Integration mit RAE Abbildung 16: Kostenverlauf für eine PIP-Implementation Abbildung 17: Entwicklung von RosettaNet in Größe und Funktion Abbildung 18: Zahlungsprozess mit RosettaNet Abbildung 19: Auftragsmanagement zwischen WPG und Intel Abbildung 20: Vergleich des Prozesses Bestellanfrage Abbildung 21: Vergleich des Prozesses Bestellungsänderung Abbildung 22: Vergleich des Prozesses Bestellungsaktualisierung Abbildung 23: Vergleich des Prozesses Lieferdetails Abbildung 24: Zeitersparnisse durch RosettaNet Abbildung 25: Ausgangssituation Abbildung 26: Zahlungsprozess mit RosettaNet Abbildung 27: Verbreitung von e-business Standards Abbildung 28: Verbreitung in der High-Tech Branche Abbildung 29: Entwicklung der Anzahl von Partnerverbindungen Abbildung 30: Adaption der PIPs Abbildung 31: Langfristige Ausgestaltung der B2B-IntegrationFehler! Textmarke nicht definiert. Abbildung 32: Zeitplan des Projektes Fehler! Textmarke nicht definiert. Abbildung 33: Übersicht der Architekur für das B2B-InvoicingFehler! Textmarke nicht definiert. Abbildung 34: Ablauf einer Rechnungserstellung- Fehler! Textmarke nicht definiert. Abbildung 35: Erwarteter Nutzen einer RosettaNet-Implementation Fehler! Textmarke nicht definiert. III

10 Abkürzungsverzeichnis Abbildung 36: Nutzen der B2B-Integration mit MagirusFehler! Textmarke nicht definiert. Abbildung 37: Entwicklung und Einführung von RosettaNetFehler! Textmarke nicht definiert. Abbildung 38: Boarding weiterer Endkunden und HandelspartnerFehler! Textmarke nicht definiert. IV

11 Tabellenverzeichnis Tabellenverzeichnis Tabelle 1: Übersicht der Standards Tabelle 2: Arbeitsgruppen von ebxml und deren Aufgaben Tabelle 3: Übersicht der Ergebnisse Tabelle 4: Überblick der RosettaNet Councils Tabelle 5: Übersicht der Cluster und Segmente Tabelle 6: Übersicht aktiver RosettaNet-Programme Tabelle 7: Stärken und Nutzenaspekte von RosettaNet Tabelle 8: Vorteile eines Zahlungsprozesses mit RosettaNet Tabelle 9: Ausprägungen der Bewertungskriterien Tabelle 10: Befragung der Handelspartner Fehler! Textmarke nicht definiert. IV

12 1. Einleitung 1. Einleitung 1.1 Ausgangslage Mit der Globalisierung der Märkte und einem resultierenden Konkurrenzdruck sehen sich Unternehmen zunehmend der Erfordernis gegenüber, ihre Geschäftsprozesse effizienter zu gestalten. Dies bezieht sich neben der Neugestaltung interner Abläufe auch auf die Außenbeziehungen eines Unternehmens. So rücken die Kommunikations- und Informationsprozesse zwischen Handelspartnern in den Vordergrund vieler Optimierungsbemühungen. Gerade in den letzten Jahren entstanden durch das Internet und die Entwicklung der extensible Markup Language (XML) neue Möglichkeiten für eine effizientere Gestaltung der Handelsbeziehungen. Das Internet ermöglicht eine kostengünstigere Basis für eine zwischenbetriebliche Kommunikation und anhand von XML als Beschreibungssprache können Dokumente und Prozesse flexibel an die Anforderungen der Unternehmen angepasst werden. Die Unterstützung von Geschäftsprozessen durch den Einsatz der Informationstechnologie setzt jedoch voraus, dass geschäftsrelevante Informationen und Transaktionen so in elektronischer Form dargestellt werden, dass sie über Unternehmensgrenzen hinweg austauschbar sind. Grundlegend für den Erfolg von e-business ist daher die Einigung auf gemeinsame Standards. Gegenwärtig wird eine unüberschaubare Anzahl von Standards für das e-business zur Verfügung gestellt. Sie unterscheiden sich teilweise grundlegend in ihrer Funktionsweise und ihrem Anwendungsbereich. Die mangelnde Transparenz erhöht hierbei die Unsicherheit der Unternehmen und erschwert einen Entscheidungsprozess. 1.2 Zielsetzung und Aufbau Die vorliegende Arbeit unterliegt der Zielsetzung, dem Leser einen Überblick der bedeutendsten B2B-Standards zu verschaffen. Mit den grundlegenden Kenntnissen der einzelnen Standards sollen diese miteinander verglichen und hinsichtlich ihrer Eignung für eine B2B-Kommunikation bewertet werden. Hierbei soll besonders eine Herausarbeitung der relativen Bedeutung von RosettaNet erfolgen. Die Arbeit beginnt mit einer Darstellung der Notwendigkeit einer Verwendung von Standards für den zwischenbetrieblichen Datenaustausch (Kapitel 2). Die Brisanz des Themas soll hierdurch verdeutlicht werden und die Grundlage für die folgenden Erläuterungen liefern. Anhand von einzelnen Kriterien, welche der Kategorisierung und Einordnung verschiedener Standardisierungsbemühungen dienen, werden dann die gegenwärtig bedeutsamen Standards in ihrer Funktionsweise und ihrem Anwendungsbereich kurz dargestellt (Kapitel 3). Einer der Standards, welcher bereits große Akzeptanz erreicht hat, und daher einer gesonderten Analyse unterzogen wird, ist RosettaNet. Die folgenden drei Kapitel beziehen sich daher auf eine ausführliche Darstellung dieser Initiative. Kapitel 4 enthält zunächst eine detaillierte Erläuterung der technischen Grundlagen von RosettaNet. Mit deren Kenntnis werden die Nutzenaspekte einer standardisierten Kommunikation auf Basis von RosettaNet dargestellt (Kapitel 5) und durch Ergebnisse realer Implementierungen gestützt (Kapitel 6). Kapitel 7 geht anschließend auf die aktuelle Verbreitung der Standards ein und enthält weiterhin eine Betrachtung der Ausprägung und der Gründe für eine Akzeptanz 1

13 1. Einleitung von RosettaNet. Für die Verbreitung eines Standards ist auch die Unterstützung durch Standardsoftware ein wichtiger Aspekt. Auf diese wird in Kapitel 7 am Beispiel von RosettaNet ebenfalls kurz eingegangen. Die Zusammenführung der Ergebnisse erfolgt in Kapitel 8. Hier werden die Standards nach vorher definierten Kriterien eingehend auf ihre Eignung für eine B2B Integration analysiert und einander gegenübergestellt. Den Abschluss der Arbeit bildet eine Fallstudie des Unternehmens IBM mit einer detaillierten Darstellung eines Projektes zur Einführung von RosettaNet Abgrenzung Eine Betrachtung von Standards für die B2B-Integration berührt eine Vielzahl von Themengebieten. Daher wird für die vorliegende Arbeit eine Abgrenzung der Thematik vorgenommen, um sich auf den wesentlichen Aspekt, die Herausarbeitung der Bedeutung von RosettaNet, konzentrieren zu können. Folgende Annahmen werden getroffen: Die Anzahl verfügbarer B2B-Standards, welche auf EDI oder XML basieren, ist sehr umfangreich. Die Betrachtung beschränkt sich auf eine Auswahl der gegenwärtig bedeutsamen Standards EDI, ebxml, cxml, xcbl, BizTalk und vor allem RosettaNet. Diese Arbeit beschäftigt sich hauptsächlich mit den fachlichen Standards des e- business. Technische Standards werden nur als Grundlage für das Verständnis verwendet. Zu beachten ist hierbei, dass fachliche Standards häufig auf technische Standards aufbauen. 1 So nutzt etwa der fachliche Katalogstandard RosettaNet den technischen XML-Standard als Basisformat. e-business kann sich neben Geschäftsvorgängen zwischen Handelspartnern (B2B) auch auf Vorgänge zwischen Unternehmen und seinen Endkunden beziehen (B2C). Im Folgenden wird jedoch nur der Bereich des B2B betrachtet. Es wird vorausgesetzt, dass der Leser sich bereits mit der Thematik von XML auseinander gesetzt hat und somit über die erforderlichen Grundkenntnisse verfügt. Aufgrund der Aktualität dieses Themas basiert die Informationsbeschaffung einerseits auf der klassischen Literaturrecherche mit Integration des Internets und andererseits auf einer hohen Interaktion mit Vertretern aus der IT-Branche. Da in vielen Fällen der Informationsgehalt durch die Übersetzung englischer Begriffe nicht gewährleistet ist, wurden zur Verständlichkeit bewusst Anglizismen verwendet. 1 Vgl. Berlecon 2003, S.32 2

14 2. Die Bedeutung von Standards für den e-business Datenaustausch 2. Die Bedeutung von Standards für den e-business Datenaustausch Mit dem Wachstum des World Wide Web und der zunehmenden Globalisierung der Märkte verändert sich auch die Art der Interaktion zwischen Unternehmen und ihren Handelspartnern. Die Mehrzahl der Unternehmen haben den Schwerpunkt ihrer Geschäftstätigkeit bereits auf das Internet verlegt, um von potenziellen Vorteilen wie höherer Automation, effizienteren Geschäftsprozessen und globaler Präsenz profitieren zu können 2. Geschäftsmodelle wie das e-business sind bereits seit geraumer Zeit fester Bestandteil geschäftlicher Aktivitäten. Einer Studie von Gartner Group zufolge, soll allein in Europa im Jahr 2006 ein Gesamtumsatz von über 8 Billionen $ durch e-business erwirtschaftet werden 3. Die Verlagerung von Geschäftsaktivitäten auf das World Wide Web hat einen globalen Wettbewerb zufolge, der zu ständigem Innovations- und Preisdruck führt und damit die Unternehmen vor neue Herausforderungen stellt. Komplexer werdende Geschäftsprozesse, verkürzte Produktlebenszyklen sowie die Notwendigkeit schnellerer Auslieferungsintervalle sind Faktoren, die eine enge Zusammenarbeit von Handelspartnern erfordern. 4 Dieser Umstand hat zu einer zunehmenden Anzahl von Kooperationen zwischen Unternehmen einer Wertschöpfungskette geführt. Das Ziel hierbei ist, unternehmensübergreifende Geschäftsvorgänge vermehrt automatisiert ablaufen zu lassen, um angesichts eines steigenden Konkurrenzdruckes nicht nur Kosten sparen, sondern auch Erfahrungen und Ressourcen teilen zu können. Die Unterstützung der Geschäftsvorgänge durch den Einsatz von Informationstechnologie stellt den Kern des e-business dar. Vorraussetzung hierfür ist vor allem ein schneller, fehlerfreier und integrierter Datenaustausch zwischen den beteiligten Unternehmen und eine unternehmensübergreifende Abstimmung der Geschäftsprozesse, bei deren Abwicklung die Systeme der Partner genau definierte Rollen einnehmen. Die Kommunikation zwischen bestehenden Anwendungen dieser Partner kann durch eine Interoperabilität von Geschäftsdokumenten, Geschäftsprozessen und Nachrichtenübertragungswegen realisiert werden. Grundlegend für den Erfolg von e-business ist folglich die Einigung auf gemeinsame Darstellungskonventionen, so genannten Standards 5. Die wesentliche Aufgabe von Standards in diesem Kontext besteht darin, exakt festzulegen, auf welche Art und in welcher Form Daten zwischen beteiligten Systemen ausgetauscht werden. Wird auf einen gemeinsamen Standard verzichtet, muss ein Unternehmen die von einem Kommunikationspartner eingehenden Informationen häufig mit großem Aufwand in das eigene verwendete Datenformat konvertieren, um es für die Unternehmensanwendungen in eine verständliche Form zu überführen. Hat ein Unternehmen mehrere Handelspartner, wie es die zunehmende Vernetzung innerhalb von Wertschöpfungsketten forciert, kann dies in hohem Aufwand resultieren, wenn für jeden Partner verschiedene Standards generiert und umgesetzt werden müssen. Die ökonomischen Gewinne von Kompatibilität sind die treibenden Kräfte für Standardisierungsbemühungen. Standardisierungen bringen durch die Reduktion von Vielfalt Ordnung in die Unsicherheit. 6 2 Vgl. Medjahed 2003, S.59 3 Vgl. Gartner 2001, S.2 4 Vgl. Georg 2003, S.19 5 Vgl. Berlecon 2003, S David 1995, S.16 3

15 2. Die Bedeutung von Standards für den e-business Datenaustausch Die Vision einer Automatisierung von Geschäftsprozessen über Unternehmensgrenzen hinweg und damit einer vollständigen B2B-Integration beschreibt ein Umfeld, in dem alle Systeme einer Handelsgruppe Informationen austauschen und gemeinsame Prozesse verwenden. 7 Alle Aspekte einer Wertschöpfungskette (Supply Chain) von Beschaffung, Produktion, Bestellung, Lieferung und Rechnungserstellung würden hierbei automatisiert ablaufen. Für ein effizientes Supply Chain Management steht die Automatisierung komplexer Abläufe folglich im Vordergrund. Nicht nur der Austausch elektronischer Geschäftsdokumente (Transaktionen) sondern auch umfassende Prozesse müssen standardisiert werden, beispielsweise für Just-in-time- Lieferungen. Neben Dokumenten für den Informationsaustausch müssen daher auch normale Abläufe, Ausnahmen, Fehlerbehandlungen und ähnliches spezifiziert und mit Partnern vereinbart werden. 8 Die Verwendung von Standards für eine Supply Chain Integration bietet für Unternehmen eine Reihe von Vorteilen. Haben Hersteller, Lieferanten und Zwischenhändler die Möglichkeit, ihre Vorgänge miteinander zu verbinden, kann ihre Wertschöpfungskette optimiert und eine Vielzahl betriebswirtschaftlicher Vorteile, wie erhöhte Planungsqualität, reduzierte Lagerbestände und verbesserte Liefergenauigkeit, realisiert werden. Weiterhin liegen in der Nutzung von Standards technische Vorteile. Besteht bereits eine Einigung und Umsetzung eines Standards zwischen verschiedenen Unternehmen, wird die zusätzliche Integration weiterer Handelspartner vereinfacht, da die Einigung über gemeinsame Abläufe sowie deren Entwicklung entfällt. Kostenintensive, systemgebundene Individual-Lösungen können vermieden werden und geben damit auch kleinen Unternehmen die Möglichkeit einer B2B-Integration. Ein spezifisches Merkmal von Netzwerken allgemein ist darin zu sehen, dass ihr Wert mit jedem zusätzlichen Nutzer steigt (Netzwerk Effekt). In Bezug auf die Standardisierung für eine Supply Chain Integration bezieht sich dies auf die Tatsache, dass eine erhöhte Akzeptanz eines Standards und die dadurch steigende Anzahl verwendender Unternehmen zu einer Optimierung der Geschäftsabläufe beitragen. Die Einigung auf gemeinsame Standards und deren effiziente Implementierung ist dennoch risikobehaftet. Die Umsetzung ist mit erheblichen Kosten und einem daraus resultierenden Zugeständnis dauerhafter Nutzung verbunden. Der Verzicht einer Integration beinhaltet demgegenüber für ein Unternehmen, dass dieses sich nur schwer weiterentwickeln kann. Vor dem Hintergrund anhaltender Globalisierung ist dies gleichbedeutend mit einem dauerhaften Wettbewerbsnachteil. Unternehmen aus den Bereichen der Informationstechnologie, Elektronikbauteile und Halbleiterelektronik haben bei der Entwicklung und Umsetzung von Konzepten zum integrierten Datenaustausch schon immer eine Vorreiterrolle eingenommen. 9 So finden sich in der High-Tech Branche erste Implementierungen von umfassenden B2B-Integrationen, die nicht nur den elektronischen Austausch von Geschäftsdokumenten beinhalten sondern auch Geschäftsprozesse unternehmensübergreifend automatisieren. Hier spielt vor allem der Standard RosettaNet eine beachtliche Rolle, der mit dem Ziel der Supply Chain Integration sowohl Daten als auch Prozesse vereinheitlicht. 7 Vgl. Linthicum 2004, S Vgl. Berlecon 2003, S Vgl. Georg 2003, S.19 4

16 2. Die Bedeutung von Standards für den e-business Datenaustausch Das technische Ziel einer B2B-Integration ist es, unternehmensübergreifende Geschäftsprozesse zu automatisieren, um die mit manuellen Prozessen verbundenen Ineffizienzen zu reduzieren. 10 Betrachtet man das e-business als eine Verbindung zwischen Handelspartnern für eine gemeinsame Nutzung von Geschäftsinformationen, kann EDI (Electronic Data Interchange) als eine der ersten Formen des e- business angesehen werden. Die Intention hinter EDI war die Entwicklung einer Möglichkeit, menschliche Interventionen bei der Verarbeitung von Informationen zwischen Handelspartnern durch ein einheitliches Format für Geschäftsdokumente zu reduzieren. Die Erfahrungen mit EDI und die resultierenden Verbesserungspotentiale in Verbindungen mit neuen technologischen Ansätzen, führten in den letzten Jahren zu einer Vielzahl von Ansätzen für die B2B-Integration. Die Entwicklung der extensible Markup Language (XML) hat maßgeblich zur Weiterentwicklung des e-business Datenaustausches beigetragen, indem es diesen stark vereinfacht. XML wurde im Jahr 1999 vom World Wide Web Consortium (W3C) entwickelt und ermöglicht die Vereinbarung grundlegender Anforderungen für einen Datenaustausch es stellt damit ein Gerüst zur Verfügung, wie Standards generiert werden können (Meta-Standard). Aktuell wird XML von verschiedenen Industriezweigen für Standardisierungsvorhaben verwendet. Mehr als Hundert auf XML-basierende Standards sind derzeit beim W3C verzeichnet. Neben EDI gehören demnach auch XML- Standards wie RosettaNet, ebxml und BizTalk zu den derzeit bedeutendsten Kommunikationsstandards auf dem Markt. Sie unterscheiden sich teilweise grundlegend in Zielsetzung und Aufbau. Im folgenden Kapitel werden zunächst Kriterien für eine Kategorisierung der verschiedenen Standards vorgestellt. 10 Vgl. Badakhchani

17 3. Darstellung und Analyse wesentlicher Standards 3. Darstellung und Analyse wesentlicher Standards Dieses Kapitel befasst sich mit einer Darstellung der Standards, die neben Rosetta- Net eine bedeutende Rolle in der B2B- Integration einnehmen. Hierbei werden ausschließlich diejenigen Standards berücksichtigt, die nach Studien der Digital Foundry im Jahr 2004 Anwendung fanden 11. Es handelt sich hierbei um ebxml, cxml, xcbl, BizTalk und EDI. Dem Standard RosettaNet wird ein eigenes Kapitel gewidmet (Kapitel 4). Aufgrund der Vielschichtigkeit der betrachteten Standards, ist es für eine differenzierte Darstellung unumgänglich, Kriterien festzulegen, die eine Einordnung von Standards ermöglichen und somit die Grundlage für einen systematischen Vergleich bilden 12. Hierzu wird ein Modell mit vier grundlegenden Systematisierungskriterien verwendet. Diese werden zunächst in Abschnitt 3.1 einzeln vorgestellt. Anschließend erfolgt in Abschnitt 3.2 anhand der eingeführten Kriterien eine Darstellung der einzelnen Standards bezüglich ihrer Spezifikationen, Anwendungen und Zukunftsaussichten. Eine Gegenüberstellung der betrachteten Standards ermöglicht neben einer geordneten Übersicht auch eine Analyse der Verhältnisse der Standards zueinander, welches in Abschnitt 3.3 erfolgt. 3.1 Klassifikation von Standards Ein Standard für den elektronischen Datenaustausch wird allgemein als eine Grundlage definiert, die es ermöglicht, in Unabhängigkeit von verwendeten Systemen, Architekturen und Anwendungen Informationen zwischen Handelspartnern auszutauschen. 13 Diese Definition dient zwar einer ersten Einordnung der zu betrachtenden Thematik, dennoch sind einige Kriterien zur weiteren Klassifizierung von Standards vor allem bei Vergleichsbetrachtungen hilfreich. Im Folgenden werden vier Systematisierungskriterien dargestellt Ebenen einer standardisierten Interaktion Die einzelnen Standards unterscheiden sich bezüglich des Gegenstandes ihrer Spezifikation. 15 Es werden drei Ebenen einer standardisierten Interaktion unterschieden: Daten, Prozesse und Kommunikationsprotokolle. Während bei datenorientierten Standards hauptsächlich festgelegt wird, wie geschäftsrelevante Informationen, wie beispielsweise Produktdaten, standardisiert werden, beschäftigen sich demgegenüber prozessorientierte Standards mit der Frage, wie ganze Geschäftsprozesse unternehmensübergreifend in standardisierter Form abgebildet werden können. Auf der Ebene der Kommunikationsprotokolle wird hingegen festgelegt, auf welchem Weg Daten zwischen den Handelspartnern ausgetauscht werden sollen. Nicht alle Standards beinhalten Spezifikationen für alle Ebenen, sondern konzentrieren sich meist auf eine einzelne, dafür detailliertere Umsetzung. 11 Vgl. Digital Foundry 2004, S.6 12 Vgl. Berlecon 2003, S Vgl. Nurmilaakso 2004, S Vgl. Erni/ Leser 2001, S.10ff. 15 Vgl. Medjahed 2003, S.61 ff. 6

18 3. Darstellung und Analyse wesentlicher Standards Zur Verdeutlichung soll das folgende Beispiel dienen. Eine Computerfirma, hier A genannt, möchte mit einem ihrer Prozessor-Lieferanten, B, auf standardisiertem Weg Geschäftsvorgänge abwickeln. Zunächst müssen sich die Firmen A und B über gemeinsame Prozesse einigen. Diese könnten beispielsweise regelmäßige Bestellungen oder automatisierte Lieferintervalle betreffen. Firma B muss weiterhin die Fähigkeit besitzen, den Dateninhalt einer Bestellung, die von A gesendet wurde, zu verstehen und in seine Systeme zu integrieren. Ein gemeinsam verwendetes Kommunikationsprotokoll, mit dem Nachrichten zwischen A und B ausgetauscht werden sollen, ist ebenfalls Bestandteil einer Integration. Anhand dieses Beispieles werden im Folgenden die oben genannten Ebenen einer standardisierten Interaktion ausführlicher betrachtet Datenebene Verschiedene Handelspartner stellen ihre internen Informationen meist auf unterschiedliche Arten dar. Eine Interaktion zwischen Systemen auf Datenebene erfordert daher neben einer gemeinsamen Darstellung und Semantik von Dateninhalten auch eine Einigung über die möglichen Arten auszutauschender Dokumente. Die Festlegung gemeinsamer Geschäftsdokumente beinhaltet implizit ein Abkommen über diejenigen Informationen, welche fortan gemeinsam genutzt werden. Ein Standard hat hierbei die Aufgabe, ein Vokabular zur Verfügung zu stellen, welches neben den Strukturen auch verwendete Begriffe eines Dokuments beschreibt. Sendet Firma A aus vorangegangenem Beispiel eine Bestellung an Firma B, müssen in diesem Dokument neben Kunden- und Lieferantennamen auch Daten wie Produktbezeichnung, Bestellmenge und Maßeinheit des Produktes verzeichnet sein 16. Eine gemeinsame Sprache zur Darstellung von Objekten (zu speichernde Elemente, wie Kunde oder Produkt), Attributen (Eigenschaften des Objekts, wie Kundenname oder adresse), Beziehungen (Verhältnis zwischen Objekten, wie Bestellungen beziehen sich auf bestimmte Produkte ) und Bezeichnern (Kombinationen von Beschreibungen, die zusammen ein Objekt eindeutig identifizieren) ist dementsprechend notwendig 17. Derzeit werden hauptsächlich Document Type Definitions (DTD) und XML- Schema als Sprachen in der Datenebene verwendet. Als speziell wird ein Standard bezüglich der Datenebene angesehen, wenn nicht nur Strukturen spezifischer Geschäftsdokumente beschrieben werden sondern auch die Bedeutung verwendeter Begriffe definiert ist. Demgegenüber ist ein Standard generell, wenn er lediglich eine Modellierungsgrundlage für eine Definition von Dokumenten und Inhalten liefert Prozessebene Auf der Prozessebene werden komplexe Geschäftsabläufe modelliert. Hierfür sind eine umfassende Ausgestaltung der Semantik und Verfahrensweisen gemeinsamer Prozesse notwendig. Dies umfasst in der Regel die Festlegung von Sequenzen von Aktionen, derer Vor- und Nachbedingungen sowie Verzweigungen und Berechtigun- 16 Vgl. Nurmilaakso 2004, S Vgl. O Kelly 2001, S Vgl. Kotinurmi 2004, S.12. 7

19 3. Darstellung und Analyse wesentlicher Standards gen. Ebenso werden die Rollen der Handelspartner für die einzelnen Prozesse definiert. So kann in einem Geschäftsprozess Bestellung etwa modelliert werden, wer in Firma A berechtigt ist, eine Bestellung zu initiieren, wer diesem zustimmen muss (eventuell in Abhängigkeit von der Höhe des Bestellwerts) und an welche Stellen innerhalb von Firma B die Bestellung anschließend automatisch weitergeleitet wird. Prozessstandards legen diese Prozesse nicht notwendigerweise im Einzelnen fest, sondern liefern den Anwendern eine Grundlage zu deren Modellierung. Ein Prozess- Modell kann einfache Anfrage-/ Bestätigungs- Routinen aber auch umfassende Arbeitsabläufe beinhalten. Standards können auf verschiedene Arten das Kriterium eines Prozessstandards erfüllen. Ein Standard wird hier als speziell bezeichnet, wenn er den Sinninhalt einzelner Geschäftsprozesse und die dazugehörigen Rollen der Handelspartner beschreibt. Er sollte weiterhin die Arten von Geschäftsdokumenten definieren, die für die Prozesse notwendig sind, und den Ablauf ihres Austausches darlegen. Als generell wird ein Standard bezeichnet, wenn er weder einzelne Prozesse noch Abfolgen von Geschäftsdokumenten definiert. Dieser Ansatz gibt lediglich vor, wie anhand von XML diese Spezifikationen modelliert werden können. Werden hingegen zumindest die Abfolgen von Geschäftsdokumenten festgelegt, handelt es sich um einen partiellen Standard. 19 Prozessstandards führen zu einer höheren Interoperabilität als Dokumentenstandards, beinhalten damit jedoch auch die größere Herausforderung einer unternehmensübergreifenden semantischen Abstimmung von komplexen Abläufen Kommunikationsebene Innerhalb der Kommunikationsebene werden die Details einer Nachrichtenübertragung zwischen den Handelspartnern geregelt. Dies beinhaltet nicht nur die Festlegung der verwendeten Protokolle (z.b. HTTP, SOAP) bei räumlich getrennten Systemen, sondern auch die Spezifikation von Sicherheitsrichtlinien für einen verlässlichen Datenaustausch. Wurden Spezifikationen bezüglich der Geschäftsdokumente und prozesse in den zuvor dargestellten Ebenen erstellt, müssen sich die teilnehmenden Unternehmen noch auf einen Standard zur Komprimierung, Codierung und den Transport einigen. Das Simple Object Access Protocol (SOAP), stellt ein weit verbreitetes Beispiel eines solchen Kommunikationsstandards dar. Es gibt jedoch eine Vielzahl weiterer Modelle für Kommunikationsstandardisierungen, wie das RosettaNet Implementation Framework (RNIF, siehe Abschnitt 4.3.3) oder die electronic business messaging service (ebms, siehe Abschnitt 3.2.5). Die Ebenen einer Standardisierung stellen den Integrationsgrad eines Standards dar. Weitere Kriterien für eine Systematisierung von Standards beziehen sich hingegen auf ihre Ausrichtung. Diese kann Industrien, Objekte oder Prozessbereiche umfassen. 19 Vgl. Kotinurmi 2004, S.12. 8

20 3. Darstellung und Analyse wesentlicher Standards Industriefokus Standards werden im Allgemeinen mit der Absicht entwickelt, Ansprüchen einer bestimmten Branche zu genügen. Verschiedene Industrie- und Dienstleistungssektoren verlangen nach ihrem eigenen Vokabular und einem auf ihre spezifischen Geschäftsprozesse ausgelegten Standardisierungsmodell. Für eine Kategorisierung werden in diesem Rahmen die Branchen IT, Versicherungen, Transport & Logistik sowie Banken herausgegriffen. Weiterhin gibt es auch Standards, die keine bestimmte Fokussierung aufweisen. In diesen Fällen wird versucht, Bedürfnisse über mehrere Branchen hinweg zu erfüllen Objekt des Datenaustausches Ein weiteres Kriterium zur Unterscheidung von Standards bezieht sich auf den Informationstyp der zwischen Unternehmen ausgetauscht werden soll. 20 Man unterscheidet die drei Objekte: Partner bzw. Kunde, Produkt und Kontrakt. Wird ein Standard dem Objekt Partner/Kunde zugeordnet, werden hauptsächlich Daten über Geschäftspartner ausgetauscht. Hierbei enthalten sind sämtliche Informationen über Endkunden, Lieferanten oder Zwischenhändler. Adressangaben, spezielle Kundenrabatte oder Bestellhistorien sind nur einige mögliche Beispiele. Das Objekt Produkt bezieht sich andererseits auf bestimmte Produkte eines Unternehmens und umfasst häufig Daten wie Produktbeschreibungen, Mindestbestellmengen oder auch Lagerbestandslisten. Mit dem Objekt Kontrakt werden hingegen alle geschäftsrelevanten Informationen erfasst, die mit einer Leistung in Verbindung stehen. Dies umfasst alle Daten, die mit einer Vertragsabwicklung verbunden sind, von Bestellanfragen, Lieferscheinen bis zur Rechnungserstellung Prozessbereich Bei der Gestaltung von Standards werden in erster Linie übergeordnete Kooperationsprozesse zwischen Unternehmen berücksichtigt. Diese allgemeingültigen Prozesse, Metaprozesse genannt, sind zunächst in allen Branchen anwendbar. Sie dienen dann als Grundlage für branchenneutrale oder spezifische Spezifikationen auf den verschiedenen Ebenen einer Interaktion. 21 Die verschiedenen Prozessbereiche, auf die sich ein Standard beziehen kann, werden nun kurz vorgestellt. Content & Community Der übergeordnete Prozessbereich Content & Community umfasst sämtliche Teilprozesse, die sich auf einen zwischenbetrieblichen Austausch von betriebsinternen Daten beziehen. Auch Informationen über das Unternehmensumfeld gehö- 20 Vgl. Erni/ Leser 2001, S. 10ff. 21 Vgl. Erni/ Leser 2001, S. 10ff. 9

21 3. Darstellung und Analyse wesentlicher Standards ren in diesen Bereich. Beispielsweise gehören Standards, die es ermöglichen unternehmensübergreifend Personaldaten auszutauschen (Human Resources Management), oder Standards zur Beschreibung von Unternehmensstatistiken diesem Metaprozess an. Produktlebenszyklus Angefangen bei der Entwicklung von Produkten, über deren Produktion bis hin zu ihrer Entsorgung entstehen Daten, die auch für einen zwischenbetrieblichen Datenaustausch relevant sein können. Denkbar ist eine unternehmensübergreifende Kooperation bei der Erforschung und Entwicklung neuartiger Produkte, bei der Hersteller und Handelspartner zusammen arbeiten und Daten wie Forschungsergebnisse gemeinsam verwenden. Aber auch ein Austausch von Daten zur Mängel- und Fehlerbeseitigung gehört dem übergeordneten Prozess des Produktlebenszyklusses an. Handel Der Prozessbereich Handel umfasst Geschäftsdaten, die bei dem Verkauf von Produkten entstehen. Hierzu gehört neben der Erstellung von Produktkatalogen oder Bestelllisten, auch der Informationsaustausch über Lieferkonditionen. Ein standardisierter Austausch von Katalogdaten ist für die meisten Unternehmen elementar, daher sind vor allem diejenigen Standards, die diesen Prozessbereich unterstützen, weit verbreitet. Supply Chain Eine Supply Chain (Wertschöpfungskette) ist der Weg von Gütern, Finanzmitteln, Dienstleistungen und Informationen zwischen verschiedenen Bereichen einer oder mehrerer Unternehmungen. Der Prozessbereich der Supply Chain umfasst hierbei die Planung. Beschaffung, Produktion und Lieferung einzelner Produkte. Aufgabe ist es, die Bereitstellung von Ressourcen zu sichern und die verschiedenen Teilprozesse einer Supply Chain, wie beispielsweise die Nachfrageplanung und Materialbestellung zu koordinieren. After-Sales Services Diesem Bereich werden Standards zugeteilt, sofern sie Prozesse unterstützen, die nach dem Verkauf eines Produktes stattfinden. Kundendienst, Garantieleistungen oder Reparaturen fallen in diese Kategorie. Finanzen Standards können sich auch auf zwischenbetriebliche Prozesse der Zahlungsabwicklung beziehen. Ein Zahlungsprozess beginnt meistens mit der Rechnungserstellung und endet mit dem Zahlungseingang. Die Standardisierung dieses Prozessbereiches birgt eine Reihe von Vorteilen. In Kapitel 6.2 wird auf die spezifischen Vorteile in diesem Prozessbereich anhand eines realen Beispiels genauer eingegangen. 10

22 3. Darstellung und Analyse wesentlicher Standards Überblick der Systematisierungskriterien Die auf den letzten Seiten vorgestellten Kriterien und ihre Ausprägungen werden in Abbildung 1 noch einmal in einem gemeinsamen Kontext dargestellt. Die verschiedenen Standards wurden mit einer Fokussierung geschaffen, die sich auf bestimmte Objekte, Industrien oder Prozessbereiche beziehen kann. Während auf der Datenebene Geschäftsdokumente und Dateninhalte spezifiziert werden, enthalten Standards auf der Prozessebene umfassende Abläufe zwischenbetrieblicher Vorgänge. Eine Integration von Daten und Prozessen erfordert weiterhin eine zugrunde liegende Art des Nachrichtenaustausches. Abbildung 1: Zusammenhang der Systematisierungskriterien (Eigene Darstellung) Diese Systematik bildet nun die Grundlage für eine nähere Betrachtung der wesentlichen Standards. 3.2 Grundlagen der wichtigsten Standards Dieser Abschnitt dient einem grundlegenden Überblick fünf ausgewählter B2B- Standards. Die Auswahl erfolgte über deren Aktualität und Popularität. Es gibt jedoch weitere Standards und Standardisierungsvorhaben, welche in Zukunft ebenfalls eine Bedeutung für die B2B-Integration entwickeln könnten. Die hier behandelten Standards zuzüglich RosettaNet in Kapitel 4 sind somit nur als eine Auswahl zu betrachten. Am Ende dieses Abschnittes werden diese in die vorher betrachteten Kategorien eingeordnet und dahingehend miteinander verglichen. Tabelle 1 zeigt RosettaNet, ebxml, cxml, xcbl, BizTalk und EDI in einer ersten Übersicht mit aktuellen Versionen der Standardisierungen sowie Informationen über ihre Initiatoren (mit Angabe der offiziellen Website). 11

23 3. Darstellung und Analyse wesentlicher Standards Website Initiator aktuelle Version RosettaNet- PIPs (für jedes einzeln), RNBD 2.1, RNTD 4.0, RosettaNet Konsortium RNIF 2.0 OASIS, BPSS 1.01, ebrim 2.0, ebrs ebxml UN/ CEFACT 2.0, ebcppa 2.0, ebms 2.0 cxml Ariba xcbl Commerce One 4.0 BizTalk Microsoft proprietäre Lösung: BizTalk Server 2004, BizTalk Framework 2.0 EDI UN/EDIFACT; ANSI X12: release 5020; UN/EDIFACT: D.04B Tabelle 1: Übersicht der Standards (Eigene Darstellung) EDI Unter EDI (Electronic Data Interchange) wird der interventionsfreie Austausch strukturierter Geschäftsnachrichten zwischen zwei verschiedenen Computersystemen verstanden. 22 Bei der Definition von EDI sind zwei Punkte wesentlich. EDI Nachrichten sind strukturierte Geschäftsnachrichten, d.h. sie umfassen sämtliche Handelsdokumente, die Formularcharakter aufweisen, wie Rechnungen, Bestellungen, Angebote, Wareneingangsbestätigungen oder Speditionsaufträge. Weiterhin ist zu beachten, dass die Empfänger von EDI- Nachrichten stets Datenverarbeitungssysteme sind. EDI Nachrichten werden ohne manuellen Eingriff (interventionsfrei) zwischen Anwendungsprogrammen ausgetauscht. EDI entstand bereits Ende der 60er Jahre mit dem Grundgedanken, den Datenaustausch zwischen Geschäftspartnern und innerhalb von Unternehmen konsequent in digitaler Form zu gestalten. Ziel war es, die mit manuellen Prozessen verbundenen Faktoren, wie Kosten, Aufwand und Zeit, zu verringern. Notwendig hierfür ist die Einigung auf einen Standard zur Gestaltung der Daten und Dokumentstrukturen. EDI- Standards dienen hierbei als gemeinsame Sprache zwischen den verschiedenen Systemen. Sie spezifizieren die Darstellung und Reihenfolge der Datenelemente (Syntax), sowie den Aufbau einer Nachricht aus einzelnen Segmenten (z.b. Adresse, Preis). Andererseits legen sie fest, welche Bedeutung die einzelnen Datenelemente bzw. Segmente (Semantik) besitzen und definieren wie diese Daten in Nachrichten verpackt werden. EDI-Standards werden von offiziellen Standardisierungsgremien festgelegt und sind klar definiert. Jedoch gibt es im Bereich des EDI keine allumfassende Regelung für die Spezifikation der zu übertragenden Daten. Vielmehr existiert eine Vielzahl von Standards je nach Region, Branche und Initiator, welche Kataloge an vordefinierten Dokumenten für ihren Bereich bereitstellen. Als branchenunabhängiger, internationaler Standard hat sich dabei EDIFACT durchgesetzt, aber auch der branchenübergreifende, vorwiegend in den USA verwendete, Standard ANSI X.12 hat eine große Akzeptanz erreicht. Neuere Ansätze greifen die Vorzüge des Internet auf. Hierzu gehört beispielsweise EDIINT. 22 Vgl. Erni/ Leser 2001, S.6. 12

24 3. Darstellung und Analyse wesentlicher Standards Varianten ANSI X.12 wurde 1979 vom Accredited Standards Committee (ASC) im Auftrag des American National Standards Institute (ANSI) entwickelt 23. Ziel war ein einheitlicher Standard für den elektronischen Austausch von Geschäftsdokumenten mit Fokussierung auf die Ausarbeitung von Standards für den Beschaffungsprozess. Hauptsächlich wird X.12 damit für den Austausch von Daten bezüglich Prozessen wie Bestellung, Lieferung, Wareneingang, Rechnungslegung und Zahlungsverkehr, sowie für andere Daten, die im Zusammenhang mit der Lieferung von Produkten und Dienstleistungen anfallen, genutzt. Aktuell ist der unter ANSI X.12 bekannte Standard insbesondere in den USA und Kanada weit verbreitet und prägt branchenübergreifend die EDI-Landschaft vieler amerikanischer Firmen. ANSI X.12 wird nach wie vor weiterentwickelt und behält eine eigenständige Bedeutung neben UN/EDIFACT und neuen EDI- Austauschformaten. Der von der Wirtschaftskommission der Vereinten Nationen (UN/ECE) entwickelte EDI- Standard UN/EDIFACT (United Nations Rules for Electronic Data Interchange for Administration, Commerce and Transport) ist vor allem in Europa weit verbreitet. Im Jahr 1987 wurde er von der International Organization for Standardization (ISO) anerkannt und unter der Bezeichnung ISO 9735 publiziert. Er umfasst eine Zusammenstellung standardisierter Datenformate und Dokumentenstrukturen für den zwischenbetrieblichen Austausch, vor allem im Bereich des Handels von Produkten und Dienstleistungen. 24 EDIFACT umfasst sowohl Regeln zur Syntax als auch zur Semantik des elektronischen Datenaustauschs. Die EDIFACT- Syntax ist in dem ISO-Standard (ISO 9735) eindeutig festgelegt. Die EDIFACT- Semantik ist in so genannten Verzeichnissen (UN/EDIFACT Standard Directories) festgelegt, in denen auch alle Nachrichten (UN/EDIFACT Standard Messages, UNSM) beschrieben sind 25. Die EDIFACT- Verzeichnisse werden regelmäßig überarbeitet, um neue EDIFACT- Nachrichten aufzunehmen oder bestehende zu aktualisieren. Die verschiedenen Versionen der EDIFACT- Verzeichnisse haben Namen wie D.04B, aus denen das Jahr (hier 2004) und die Version innerhalb dieses Jahres (im Beispiel B, also die zweite Version im Jahr 2004) abgelesen werden können. Es gibt derzeit 208 verschiedene EDIFACT- Nachrichten für die verschiedensten Anwendungszwecke im Geschäftsverkehr. Jede Nachricht hat einen Kurznamen, bestehend aus 6 Großbuchstaben. Einige Beispiele sind: ORDERS (Bestellung) PRODAT (Produktdaten) DESADV (Lieferschein) INVOIC (Rechnung) PAYORD (Zahlungsanweisung) Komplexität und vielfältige Interpretierbarkeit des EDIFACT- Standards trugen dazu bei, dass sich branchenspezifische Untermengen, so genannte Subsets, verbreiteten. 26 Diese bilden eine exakte Teilmenge der Nachrichtenarten und Datenelemente Vgl. UNECE Vgl. Computerbase 2005a 26 Vgl. Ecin

25 3. Darstellung und Analyse wesentlicher Standards von EDIFACT. Beispiele hierfür sind der im Bereich der Konsumgüterindustrie europaweit etablierte Standard EANCOM oder der für die deutsche Automobilindustrie bedeutsame ODETTE. Während sich die einzelnen Subsets kompatibel zu EDIFACT verhalten, sind die verschieden Subsets untereinander meist inkompatibel. Die Verbindung von EDI mit Internet-Technologien scheint eine Vielzahl von Schwachstellen traditioneller EDI-Standards zu verbessern. Eine Initiative in diesem Bereich ist EDIINT (Electronic Data Interchange Internet Integration). 27 EDIINT wurde von dem Uniform Code Council (UCC) entwickelt, um die Methode des Austausches von EDI-Dokumenten über das Internet in eine standardisierte Form zu überführen. EDIINT ist ein Standard, der es Unternehmen ermöglicht, jegliche Form von Daten und Dokumenten über das Internet auf Basis des Simple Mail Transfer Protocols (SMTP), des Hyper Text Transfer Protocols (HTTP) oder des File Transfer Protocols (FTP) auszutauschen. EDIINT legt dabei lediglich die Regeln für die Kommunikation fest und definiert nicht das Nachrichtenformat selbst, welches vom individuellen Anwendungsszenario abhängt. Die sichere Zustellung der Nachrichten wird durch den Einsatz gängiger Verschlüsselungs- und Authentifizierungsverfahren gewährleistet. Der Vorteil von EDIINT liegt in der deutlichen Senkung der Kommunikationskosten, da der Einsatz kostspieliger Value Added Networks (VANs) für die Übermittlung der Daten entfällt. Diese drei Ansätze sind nur eine Auswahl der Vielzahl auf EDI-basierenden Standards. Auf eine detailliertere Beschreibung einzelner Ansätze wird in diesem Bereich verzichtet, da sämtliche EDI-Standards ähnliche Klassifikationsmerkmale besitzen und auch weitestgehend die mit traditionellem EDI verbundenen relativen Stärken und Schwächen teilen. Folglich wird nur noch von EDI als Standard gesprochen Kommunikation Es gibt verschiedene Wege eine EDI-Nachricht zu versenden. Die Übertragungsmöglichkeiten werden nachfolgend kurz erläutert. Punkt-zu-Punkt-Verbindung Die Kommunikation unter Verwendung von EDI, verlangt in ihrer ursprünglichen Form eine direkte Verbindung über eine Telefon- oder Datenleitung (Punkt-zu- Punkt-Verbindung) zu den Systemen der Kommunikationspartner. Hier werden die Nachrichten zwischen genau zwei Unternehmen ausgetauscht. Diese Übertragungsform hat jedoch einen relativ hohen Aufwand an der Programmierung der Schnittstellen und deren Pflege zur Folge und lohnt deshalb meist nur für die Datenübertragung mit den Hauptgeschäftspartnern. Der Vorteil liegt darin, dass man die volle Kontrolle über das Ergebnis der Übertragung hat. Als Nachteil lässt sich jedoch nennen, dass hohe Kosten durch die einzelnen Wahlvorgänge für den Verbindungsaufbau entstehen. 27 Vgl. EDIINT

26 3. Darstellung und Analyse wesentlicher Standards Value Added Networks (VANs) Eine weitere Möglichkeit stellen Anbieter dar, die eine Mailbox zur Verfügung stellen, über die EDI- Nachrichten ausgetauscht werden können. Wichtig für den Anwender ist der Aspekt, unabhängig von der Einsatzbereitschaft des Rechners beim Partner die Übermittlung der Daten vornehmen zu können und den Empfang bestätigt zu bekommen. Anbieter von derartigen Diensten nennt man Value Added Network Services oder Anbieter von Netzmehrwertdiensten (Netz-Clearing). Netz-Clearing Dienstleister übernehmen zusätzliche Funktionen im Vergleich zu VANs, z. B. die Konvertierung der Daten in ein EDI-konformes Format. Man spricht bei diesen Formen des Datenaustausches auch von dem traditionellen EDI. Übertragung über das Internet Neuere Ansätze ermöglichen auch einen Austausch von EDI- Nachrichten über das Internet. Die Daten können auf verschiedenen Wegen wie , HTTP oder FTP übertragen werden. Allerdings muss man hier zwischen zwei Varianten unterscheiden: EDI-over-the-Internet und Web-EDI. Beim EDI-over-the-Internet wird die Nachricht direkt von einem System über das Internet in ein anderes übertragen. Man spricht hier von einer medienbruchlosen Übertragung. Dies bedeutet, dass die Daten in dem anderen System direkt weiter verarbeitet werden können. Hingegen wird unter Web-EDI lediglich ein Web-Frontend zur Verfügung gestellt, worüber mittels eines Browsers Daten eingegeben werden, die dann in dem Empfängersystem weiterverarbeitet werden können. Dies ist eine häufig genutzte Variante bei Firmen, die eine EDI- Kommunikation mit ihren Handelspartnern wünschen, jedoch die Kosten und den Aufwand, die mit einem vollständigen EDI- System verbunden sind, scheuen. Der Ablauf einer Kommunikation mit EDI stellt sich nun folgendermaßen dar. Die Verwendung von EDI hat zunächst Einfluss auf drei Ebenen von Informationssystemen. In den Geschäftsapplikationen werden Geschäftsobjekte wie beispielsweise eine Bestellung erzeugt, die dann an einen Handelspartner übermittelt werden sollen. Übersetzungsapplikationen konvertieren die Geschäftsnachrichten zu EDI- Nachrichten, welche dann mittels Kommunikationsapplikationen an den Handelspartner übermittelt werden. In Abbildung 2 ist ein klassisches EDI-Szenario dargestellt Vgl. Medjahed 2003, S

27 3. Darstellung und Analyse wesentlicher Standards Abbildung 2: EDI- Szenario (Vgl. Medjahed 2003, S. 63) Die Geschäftsanwendung von Unternehmen A (beispielsweise ein ERP-System) sammelt die für eine Bestellung an Unternehmen B notwendigen Auftragsdaten. Die beteiligten Anwendungsprogramme, sofern sie nicht die Fähigkeit besitzen EDIkonforme Daten zu produzieren, werden mit einem so genannten Mapper verbunden, welcher eine diesbezügliche Umwandlung vornimmt. Die Translator Software erzeugt anschließend auf Grundlage dieser Daten eine EDI-Nachricht. Jede Nachricht besteht aus einem Umschlag, welcher vereinbarte Codenummern für Absender und Empfänger, sowie Nachrichteninhalt, Zeiten zur Rückverfolgung und Prüfelemente enthält. Über ein VAN bzw. eine Punkt-zu-Punkt Verbindung wird die Nachricht an Unternehmen B gesendet. Auf der Empfängerseite, hier B, wiederholt sich diese Abfolge in entgegengerichteter Form Klassifikation Die EDI- Standards konzentrieren sich hauptsächlich auf Spezifikationen der Datenund Kommunikationsebene. Sie besitzen besonders enge Standards bezüglich der Datenebene. Hier werden eine feste Anzahl von Geschäftsdokumenten für die Unternehmen zur Verfügung gestellt. Es existiert eine Vielzahl von vordefinierten Geschäftsdokumenten für jegliche Anwendungszwecke von Lieferstatus bis Zahlungseingang. Ein Nachteil ist darin zu sehen, dass die Unternehmen an diese Dokumente gebunden sind. Werden andere Parameter innerhalb eines Dokumentes gewünscht, kann dies mit Schwierigkeiten verbunden sein, da EDI sich in dieser Hinsicht als wenig flexibel herausstellt. Änderungen oder Erweiterungen eines Dokumentes erfordern das Einverständnis des zuständigen Standard-Komitees. 29 Bezüglich der Datenebene sind EDI-Standards als speziell einzuordnen, da neben Strukturen auch enthaltene Begriffe eindeutig festgelegt sind. Die Integration auf der Prozessebene ist hingegen lediglich als partiell anzusehen. Auf dieser Ebene stellen 29 Vgl. Medjahed 2003, S

28 3. Darstellung und Analyse wesentlicher Standards EDI-Standards lediglich ein Regelwerk für eine Abfolge von Geschäftsdokumenten zur Verfügung. So wird beispielsweise modelliert, dass als Antwort auf eine Bestellung, in zeitlicher Aneinanderreihung zunächst eine Bestätigung, später eine Rechnung und ein Lieferstatus folgen sollen. Auf der Kommunikationsebene sind für EDIINT eindeutige Spezifikationen vorhanden, um EDI- Nachrichten per , Internet oder FTP versenden zu können. Für traditionelles EDI sind allgemeine Regeln für eine Verbindung über VANs vorhanden. Mit der Vielzahl an Varianten und Subsets, die EDI besitzt, erreicht dieser Standard annähernd jeden Industriebereich. Zwar sind einzelne Subsets meist auf spezifische Branchen ausgelegt, übergeordnete Varianten wie EDIFACT hingegen branchenneutral gestaltet. Wurde ursprünglich EDI zur Unterstützung im Bereich der Bürokommunikation entwickelt, sind anschließend vor allem Spezifikationen für den Prozessbereich Handel und Finanzen entwickelt worden. Aktuell werden nun sämtliche Prozessbereiche durch EDI abgedeckt. Der Gegenstand des Datenaustausches umfasst in zahlreichen Dokumenten wie Kontoauszügen, Lieferantenkonditionen, Inventarlisten und Stellenbeschreibungen eine Vielzahl von Daten, die Kontrakten, Partnern und auch Produkten zuordenbar sind Stärken und Schwächen Der Austausch von Geschäftdokumenten in einem für beide Handelspartner verständlichen Datenformat beinhaltet große Einsparpotenziale in Bezug auf Zeit, Arbeitskraft und weitere Kostenfaktoren, wie z.b. Büromaterial. Daten aus Geschäftsvorgängen müssen nicht mehr manuell in die verschiedenen Systeme eingeben werden und Fehlerquellen können somit verringert werden. Dies sind jedoch Vorzüge, die auch in Bezug auf andere Standards Anwendung finden. Es gibt weiterhin eine Reihe EDI-spezifischer Merkmale. EDI hat seit seinen Anfängen große Verbreitung gefunden. Dies liegt an einer Vielzahl von Ursachen. Bei der Entwicklung von EDI wurde hauptsächlich auf das Volumen einer Nachricht geachtet. EDI-Nachrichten sind daher stark komprimiert und verwenden Codes für die Darstellung komplexer Daten. Große Unternehmen mit hohen Transaktionsvolumen haben daher den EDI-Standard schnell adaptiert. Die genaue Spezifikation einzelner Geschäftsdokumente erleichtert den Unternehmen weiterhin deren Implementierung, da Dokumenteninhalte und -strukturen bereits in vordefinierter Form vorliegen und eine Einigung und Ausgestaltung vereinfacht wird. Auf Änderungen von Ansprüchen der Marktteilnehmer wird versucht, durch ständige Aktualisierungen der Standards zu reagieren. Dennoch birgt das traditionelle EDI ein großes Verbesserungspotential im Vergleich zu neueren Ansätzen, welche hauptsächlich auf XML basieren. Einige dieser Aspekte wurden bereits aufgegriffen, wie z.b. durch die Ermöglichung eines EDI- Austausches auf Basis des Internet. Teure Verbindungen über VANs können durch diese Ansätze vermieden werden. Dennoch existieren eine Reihe Probleme in Bezug auf einen EDI-Nachrichtenaustausch. Ein wichtiger Punkt hierbei ist, dass vordefinierte Dokumente zwar einerseits oben diskutierte Vorteile bieten, aber andererseits mit dem Nachteil fehlender Flexibilität verbunden sind. EDI-Dokumente sind sehr un- 17

29 3. Darstellung und Analyse wesentlicher Standards flexibel, wodurch es Unternehmen erschwert wird auf Veränderungen, wie spezielle Kundenansprüche, reagieren zu können. Wichtig anzumerken ist auch, dass zunehmende Kooperationen zwischen Handelspartnern vor allem die Abstimmung und Optimierung unternehmensübergreifender Geschäftsabläufe erfordern. Dies bezieht sich auf Standards der Prozessebene, welche nicht von EDI abgedeckt werden. Die Vielfalt an verschiedenen EDI-Standards erschwert nicht nur die Auswahl der passenden Lösung für die Unternehmen, sondern verkompliziert auch deren Kommunikation untereinander. Auch wenn beide Unternehmen EDI verwenden, ist es nicht sichergestellt, dass sie eine gemeinsame Kommunikation aufbauen können, da Unterformate wie X.12 und EDIFACT nicht miteinander kompatibel sind bzw. nur mit umfangreichem Arbeitsaufwand. Weiterhin können beispielsweise Schwierigkeiten bei der Fehlersuche oder korrektur bei EDI-Transaktionen entstehen, da die Nachrichten kein von Menschen lesbares Format aufweisen und daher schwer auszuwerten sind. Ein ausführlicher technischer Vergleich und eine Herausarbeitung der relativen Stärken und Schwächen von EDI in Bezug zu anderen Standards erfolgt in Kapitel Ausblick Die Zukunft von EDI-Standards dürfte vorerst nicht gefährdet sein. Dies liegt zum einen an der weiten Verbreitung dieses Standards und zum anderen daran, dass die großen Unternehmen, die ihre Geschäftsdaten bereits auf Basis von EDI austauschen, keine Erfordernis sehen werden, etwas auszutauschen, was sich bewährt hat und in das viel investiert wurde. Dennoch werden prozessorientierte Standards in Zukunft eine größere Rolle in der B2B-Integration einnehmen. Nach einer Studie der Berlecon Research werden Unternehmen künftig verstärkt XML-basierte Standards einsetzen cxml commerce XML (cxml) wird von einem Konsortium aus Softwareherstellern und Anwendern getragen. Der Standard wurde im Jahr 1999 von der Firma Ariba entwickelt und konzentriert sich auf die Optimierung der Beschaffungsprozesse von Unternehmen. Schwerpunkt von cxml liegt in der Ausgestaltung von Geschäftsdokumenten, die Prozesse in den Bereichen Maintenance & Repair, Services und Commerce unterstützen. 31 Zwar besitzt dieser Standard nur einen eingeschränkten Anwendungsbereich, dennoch besitzt er durch seine branchenübergreifende Gestaltung eine weltweite Akzeptanz Kommunikation Eine Transaktion mit cxml wird über den Austausch von Dokumenten abgewickelt, bei denen es sich um einfache Textdateien mit klar definierten Formaten und Inhalten handelt. Diese werden durch Document Type Definitions (DTDs) definiert, welche Syntax und Struktur innerhalb der Dokumente festlegen. 30 Vgl. Berlecon 2003, S Vgl. cxml 2004a 18

30 3. Darstellung und Analyse wesentlicher Standards In der aktuellen Version umfasst cxml 34 verschiedene Dokumente. Dabei werden drei hauptsächliche Arten von cxml-dokumenten unterschieden: Kataloge, Punch-Outs und Bestellaufträge. 32 Kataloge (Catalogs) Kataloge sind Dateien, in denen Produkt- und Dienstleistungsinhalte für potenzielle Käuferunternehmen zur Verfügung gestellt werden. Zusätzlich zu Produkten und Leistungen sind auch Informationen zu aktuellen Preisen und Rabatten enthalten. Kataloge können grundsätzlich für jede Art von Produkten oder Leistungen erzeugt werden. Jeder Artikel des Katalogs muss jedoch mit einer minimalen Beschreibung versehen sein. Viele optionale Katalogeigenschaften stehen innerhalb der cxml-spezifikationen zur Verfügung, wie z. B. mehrsprachige Produktbeschreibungen. Kunden können diese Kataloge in ihr E-Procurement System integrieren und bei Bestellungen auf dessen Inhalte zugreifen. Punch-Outs Bisher wurden statische Katalogdateien betrachtet. Punch-Outs hingegen sind dynamische, interaktive Kataloge. 33 Damit ist ein einfach zu implementierendes Protokoll gemeint, welches interaktive Sitzungen über das Internet in Echtzeit verwaltet und Nutzern die Möglichkeit gibt, auf einfache Art auf aktuelle Produktbzw. Dienstleistungsinformationen zuzugreifen. 34 Der cxml- Standard unterscheidet hierbei drei verschiedene Typen von Punch- Outs. Procurement Punch-Outs stellen Lieferanten eine Alternative zu statischen Katalogdaten zur Verfügung. Die Punch-Out Seiten sind hierbei interaktive Kataloge, die auf Webseiten betrieben werden. Anbieter von Waren können diese in ihre Webseiten integrieren und so eine Kommunikation mit ihren Beschaffungsanwendungen über cxml ermöglichen. 35 Für die Punch-Out-Produkte wird innerhalb des Kataloges anstatt Produkt- und Preisdetails lediglich ein Button angezeigt. Bei Betätigung dieses Buttons zeigt der Webbrowser des Kunden Seiten der lokalen Website des Lieferanten an. Je nach Umfang einer Integration stehen dem Kunden dann zusätzliche Funktionen und Informationen, wie Produktkonfigurationen zur Verfügung. Mit der Bestellbestätigung des Kunden wird dann eine Nachricht an die Beschaffungsanwendung ausgelöst. 36 Eine weitere Form ist das Punch-Out Chaining. Dieses ähnelt dem Procurement Punch-Out, jedoch sind hier mehr als ein Punch-Out einbezogen. Bestellungen werden nicht direkt beim Lieferanten vorgenommen, sondern der Kunde bezieht seine Waren über einen virtuellen Marktplatz, der die Angebote mehrerer Lieferanten vereinigt. Abbildung 3 zeigt einen solchen Vorgang. 32 Vgl. cxml 2004a, S Vgl. Erni/ Leser 2001, S Vgl. cxml 2004a, S Vgl. cxml 2004a, S.20ff. 36 Vgl. cxml 2004a, S.20ff. 19

31 3. Darstellung und Analyse wesentlicher Standards Buyer M arketplace Supplier Abbildung 3: Punch-Out Chaining (cxml 2004a) Bei einer Bestellung, die Produkte mehrerer Lieferanten umfassen kann, werden automatisch Nachrichten nicht nur an den virtuellen Marktplatz sondern auch an alle involvierten Lieferanten gesendet. Diese Funktionalität wird durch das Path Routing von cxml ermöglicht. Es hat die Aufgabe, die Wege der einzelnen Dokumente zu erfassen und damit eine evtl. später zu erfolgende Abrechnung zu ermöglichen. Provider Punch-Outs beinhalten Spezifikationen, die es ermöglichen, mit entfernten Anwendungen zu kommunizieren, die zusätzliche Dienstleistungen anbieten. Diese können beispielsweise eine Kreditkartenprüfung oder eine Kundenidentifikation beinhalten Bestellungen (Purchase Orders) Ein Bestellauftrag kann durch ein Punch-Out oder eine Auftragserfassung in einem statischen Katalog ausgelöst werden. Dieser Bestellauftrag, ein OrderRequest-Dokument im cxml-format, wird an die Internet-Adresse des Lieferanten gesendet, bei welcher es intern an das zentrale Auftragsverwaltungssystem weitergeleitet wird. Nach einer semantischen Analyse des Inhaltes dieses Dokuments, sendet das System des Lieferanten ein OrderResponse-Dokument an den Käufer zurück und beendet somit den Bestellvorgang. 37 Beispiele der oben genannten Dokumente sind auf der Website des Standards angegeben. Die folgende Abbildung verdeutlicht noch einmal die möglichen Arten eines Austausches von Geschäftsdokumenten mit cxml. 37 Vgl. Erni/ Leser 2001, S

32 3. Darstellung und Analyse wesentlicher Standards Abbildung 4: Übersicht des Dokumentenaustausches mit cxml (Erni/Leser 2001) cxml unterscheidet zwei verschiedene Arten einer Kommunikation. 38 Bidirektionale Kommunikation (One-Way) Bei der bidirektionalen Kommunikation baut Unternehmen A eine Verbindung mit der Web-Seite des Unternehmens B auf. Anschließend sendet A ein cxml Dokument an diese Seite und wartet auf eine Antwort. B Leitet die Daten an den dafür zuständigen Händler weiter. Nach Bearbeitung der Anfrage wird ein weiteres cxml-dokument erstellt und mit den erforderlichen Daten an A geschickt. Hier wird das empfangene Dokument weiterverarbeitet und die Verbindung wird geschlossen. Für diesen Vorgang ist eine HTTP- bzw. HTTPS-Verbindung notwendig. Unidirektionale Kommunikation (Request/ Response) Bei dieser Form der Kommunikation wird ein cxml-dokument von einem Unternehmen erstellt und an einen Empfänger versandt. Der Empfänger öffnet und bearbeitet anschließend das Dokument. Dem Sender wird der Empfang einer Nachricht hierbei nicht bestätigt. Eine HTTP-Verbindung ist bei der unidirektionalen Kommunikation nicht notwendig Klassifikation Auf der Datenebene definiert cxml eine Reihe von XML DTDs für eine Beschreibung von Dokumenten für den Beschaffungsprozess. Produktkataloge in cxml enthalten die Elemente: Supplier, Index, and Contract. Das Element Supplier enthält Daten des Lieferanten, wie Adressangaben. In dem Index ist das Angebot des Lieferanten gespeichert (z. B. Produktbeschreibung, Artikelnummer). Vereinbarte Auftragsdaten 38 Vgl. cxml 2004a, S.29ff. 21

33 3. Darstellung und Analyse wesentlicher Standards zwischen Käufer und Lieferant werden im Element Contract festgehalten (z. B. Preis, Anzahl, Zahlungsbedingungen). 39 Bezüglich der Datenebene stellt cxml einen speziellen Standard dar. Neben Dateninhalten und elementen werden auch die Strukturen von Dokumenten in den DTDs festgelegt. Auf der Prozessebene wird zwischen bidirektionalen und unidirektionalen Abläufen von Geschäftsprozessen unterschieden. Die beiden Arten einer Kommunikation stellen lediglich ein Regelwerk zur Ausgestaltung einer Interaktion dar, in der die Abfolge eines Austausches von Geschäftsdokumenten, sowie die Rollen der Handelspartner noch zu definieren sind. Der Standard cxml ist damit auf dieser Ebene als generell anzusehen. Die Kommunikationsebene von cxml beinhaltet einen Transport der Nachrichten über die Protokolle HTTP und HTTPS. Der Umfang der spezifizierten Dokumente in cxml ermöglicht den Austausch von Daten verschiedener Informationstypen. Bestellvorgänge benötigen im Allgemeinen Daten, wie Kundenadresse, Produktbezeichnung und vereinbarte Rabatte. Die Objekte Produkt und Kontrakt werden demzufolge mit cxml abgedeckt. Während sich cxml hauptsächlich auf die Beschaffungsseite eines Unternehmens konzentriert, ist dieser dennoch für alle Branchen gleichsam anwendbar. Eine Anwendung findet sich jedoch meistens in Industriebereichen, bei denen eine enge Zusammenarbeit mit Lieferanten vorgesehen ist. Innerhalb der betrachteten Branchen ist daher der IT-Sektor hervorzuheben. Beschaffungsprozesse umfassen Vorgänge von Anfragen, Bestellungen, Lieferbarkeitsinformationen, Bestellbestätigungen bis hin zu Rechnungen. Handel, Supply Chain und Finanzen sind daher die Prozessbereiche, in denen cxml anwendbar ist Stärken und Schwächen cxml beinhaltet eine feste Vorgabe von DTDs, welche sich auf den eingeschränkten Anwendungsbereich der Beschaffung konzentrieren. Dieser Standard ist damit zwar leicht handhabbar, aber ähnlich wie EDI, weniger flexibel und leistungsfähig als andere Standards. Ein weiterer Nachteil ist darin zu sehen, dass cxml nicht mit dem weit verbreiteten Standard EDIFACT kompatibel ist und damit in manchen Bereichen eine Integration zwischen Handelspartnern erschwert. Es gibt jedoch eine Reihe Vorteile, die mit einer Verwendung von cxml verbunden sind. 40 cxml ist standardmäßig in die Softwarelösungen der Firma Ariba integriert. Durch die hohe Verbreitung dieser Produkte, wird cxml bereits häufig in Unternehmen eingesetzt. Auch in der Verwendung von Punch-Out-Verfahren liegen Vorteile für ein Unternehmen. Diese stellen eine effiziente Möglichkeit dar, angebotene Produktkataloge mit den dahinter liegenden Beschaffungssystemen interaktiv zu verbinden. Damit wird ermöglicht, mit Bestellungen verbundene Aktionen automatisch auszulösen. cxml ist bisher der einzige Standard, der ein Punch-Out ermöglicht. 39 Vgl. Medjahed 2003, S Vgl. Ariba 2004b 22

34 3. Darstellung und Analyse wesentlicher Standards Ausblick Die Unterstützung von cxml durch die Firma Ariba und weiteren namhaften Unternehmen hat zu einer weiten Verbreitung dieses Standards vor allem in den USA geführt. Grund hierfür ist die Entscheidung des marktführenden Lieferanten für Elektronikkomponenten, Newark, cxml Punch-Out in seine Anwendungen zu integrieren. 41 Auch eine Vielzahl von Verhandlungen mit Entwicklern anderer B2B-Standards, wie Microsoft (Entwickler von BizTalk), hat dazu geführt, dass auch Konkurrenzprodukte eine Kommunikation mit cxml ermöglichen. Ariba arbeitet intensiv daran, ihren Standard zu etablieren. cxml wird daher voraussichtlich weiterhin neben anderen Standards bestehen, sich jedoch ausschließlich im Bereich des Beschaffungswesens etablieren xcbl Mit seiner Entstehung bereits im Jahr 1997 ist xcbl (extended Common Business Library) einer der ersten e-business Standards. 42 Das Unternehmen Veo Systems leitete zu jener Zeit ein Forschungsprojekt zur Untersuchung der Grenzen von XML für das e-business. Als Grundlage diente die CBL. Später wurde Veo Systems von dem Softwareanbieter CommerceOne übernommen, welcher auch die CBL übernahm und weiterentwickelte. Es entstand die erste publizierte Version des Standards xcbl 2.0, welchem ein x voran gestellt wurde, um eine Verbindung zu der Sprache XML zu verdeutlichen. xcbl wird derzeit von vielen Hardware- und Softwareanbietern sowie weiteren Unternehmen im Bereich des e-commerce unterstützt. Wie auch im Fall von Ariba (mit cxml), wird xcbl von CommerceOne in seine Softwarelösungen standardmäßig integriert und hat hierdurch weltweite Verbreitung erlangt. Die Spezifikationen beinhalten eine umfangreiche Sammlung von XML-basierten Geschäftsdokumenten. Hierbei werden vor allem Geschäftsvorgänge in den Bereichen Supply Chain, direkte und indirekte Beschaffung, Auktionen, Rechnungserstellung sowie Bezahlung unterstützt. xcbl stellt ein branchenübergreifendes Vokabular für Dokumente bereit, jedoch werden weder Geschäftsprozesse noch Nachrichtentransport im Detail adressiert. Dies drückt auch der Name Common Business Library aus, welcher die Konzentration auf eine Bibliothek für Geschäftsdokumente verdeutlicht. Bei der Gestaltung von xcbl wurde darauf geachtet, eine Interoperabilität mit den EDI-Standards zu gewährleisten. Dies wird durch eine Ähnlichkeit in der Semantik erreicht. Mit der aktuellen Version 4.0 wird Unternehmen eine einfache Migration von EDI zu XML-basierten Standards ermöglicht Kommunikation xcbl beinhaltet eine Sammlung von XML-Modulen (Building Blocks), aus welchen die Datentypspezifikationen wie z.b. Bestellungen, Rechnungen oder Produktkataloge hervorgehen. 43 Die Spezifikationen beinhalten hierbei eine strikte Trennung zwischen dem Inhalt eines XML-Dokuments und dessen Transport. 44 In xcbl existiert keine Bindung an eine Transportart wie das HTTP. Es sind hier nur Definitionen vor- 41 Vgl. Newark Vgl. xcbl 2005e 43 Vgl. Weitzel 2001, S.135ff. 44 Vgl. tnem

35 3. Darstellung und Analyse wesentlicher Standards handen, die den inhaltlichen Aufbau eines XML-Dokuments betreffen. Die aktuelle Version xcbl 4.0 beinhaltet 44 verschiedene Geschäftsdokumente, die sich 8 Funktionsbereichen zuordnen lassen. Abbildung 5 zeigt eine Übersicht dieser Funktionsbereiche mit Beispielen zugehöriger Dokumententypen. Auf der Webseite von cxml finden sich ausführliche Beschreibungen. 45 Application Integration Catalog Content Financial Management AccountCheck GetERPData ProductCatalog RemittanceAdvice PaymentRequest Statistics and Forecasting xcbl Material Management TimeSeriesRequest TimeSeriesResponse GoodsReceipt InventoryReport Order Management ChangeOrder OrderRequest Pre Order Management PriceCheckRequest AvailabilityCheckResult Message Management ApplicationResponse ErrorResponse Abbildung 5: Funktionsbereiche von xcbl-dokumenten (Eigene Darstellung) Der Aufbau eines xcbl-dokuments ist modular gestaltet. Ein Dokument, wie z. B. die Order, lässt sich in drei Abschnitte unterteilen: Header, Detail und Summary. 46 Header-Bereich Neben einem Bezeichner für referenzierte Dokumente sind im Header-Bereich die Rahmendaten eines Geschäfts enthalten. Hierzu gehören die Identifikationsnummern des Käufers, des Lieferanten und der Bestellung. Zusätzlich wird in einem PurposeCode der Ziel und Zweck des Dokuments spezifiziert. Mögliche Codes hierfür sind z.b. Original, Cancellation, Replace, Confirmation, Duplicate, Change und InformationOnly. 45 Vgl. xcbl 2005a 46 Vgl. xcbl 2005b 24

36 3. Darstellung und Analyse wesentlicher Standards Detail-Bereich Der Detail-Bereich enthält die hauptsächlichen Daten einer Bestellung. Dies sind vor allem Produktbezeichnungen und Mengenangaben. Ein OrderStatusRequest könnte zusätzliche Daten wie Lieferdatum oder Verzögerungszeitraum beinhalten. Summary-Bereich Im letzten Teil eines xcbl-dokuments werden die Preise der bestellten Artikel, sowie die Steuern zusammengerechnet und die Währung nochmals definiert. Entscheidet sich eine Unternehmung für ein Bestellwesen mit xcbl, ergeben sich mehrere Optionen für den Bestellprozess. 47 Zunächst kann ein Interessent eine Bestellanfrage an einen Lieferanten senden, die OrderRequest. Dieser antwortet mit einer Offerte, dem OrderResponse. Ist der Käufer mit angebotenem Preis und Lieferbedingungen einverstanden, sendet er eine Order an den Lieferanten zurück. Nach Erhalt der Bestellung schickt der Lieferant eine Bestellbestätigung an den Kunden, die OrderResponse. Mit der ChangeOrder kann der Käufer nachträglich noch Änderungen an seiner Bestellung vornehmen. Das einzige Muss-Element bei einem Bestellprozess mit xcbl ist das Dokument Order. OrderRequest, OrderResponse und ChangeOrder stellen in einer xcbl-kommunikation nur Optionen dar. Ihre Nutzung bleibt den Handelspartnern überlassen. Die in xcbl definierten Dokumente können durch eigene Definitionen erweitert werden. Dies gibt jedem Anwender zusätzlich die Möglichkeit, selbst neue Elemente und Strukturen zu erstellen und diese in bereits bestehende Module zu integrieren. Eine optimale Anpassung an bestehende Anforderungen ist damit gewährleistet. 48 Dies unterscheidet xcbl wesentlich von cxml Klassifikation xcbl beinhaltet eine umfassende Sammlung von Geschäftsdokumenten, deren Strukturen und Elemente eindeutig festgelegt sind. xcbl stellt damit einen speziellen Standard auf der Datenebene dar. Die Ausgestaltung einer Abfolge von Geschäftsdokumenten ist für xcbl rein deskriptiv formuliert. Es werden Richtlinien für eine Modellierung von überbetrieblichen Geschäftsprozessen aufgestellt. Weiterhin enthält die Dokumentation Darstellungen möglicher Abfolgen an Dokumenten je nach Funktionsbereich. 49 Die Prozessebene ist in diesem Fall partiell ausgestaltet. xcbl 4.0 beinhaltet weiterhin keine Aussage über die Art des Nachrichtenaustausches. Der Austausch von Geschäftsdokumenten zwischen Handelspartnern ist unabhängig von dem zugrunde liegenden Protokoll. Mit xcbl können hauptsächlich die Prozessbereiche Supply Chain, Handel und Finanzen unterstützt werden. Dies wird vor allem durch eine Betrachtung der verschiedenen Dokumentarten, die xcbl zur Verfügung stellt, deutlich. 47 Vgl. Erni/ Leser 2001, S Vgl. xcbl 2005e 49 Vgl. xcbl 2005c 25

37 3. Darstellung und Analyse wesentlicher Standards Daten werden mit xcbl ausgetauscht, um Verträge abzuwickeln oder Informationen bezüglich Produkten auszutauschen. Dies kann mit einer Versendung eines Kataloges an einen Kunden verbunden sein, aber auch die Erfüllung eines Auftrages zum Ziel haben, wie Bestellanfragen oder Zahlungseingangsbestätigungen. Objekte des Datenaustausches sind bei diesem Standard daher Produkte und Kontrakte. xcbl wurde nicht auf die Anwendung innerhalb einer Branche ausgerichtet. Er ist branchenübergreifend anwendbar Stärken und Schwächen xcbl wurde auf Grundlage umfassender Analysen von konkurrierenden Standardisierungsvorhaben und Anwenderanforderungen entwickelt. Dieser Standard berücksichtigt damit die Faktoren anderer Standardisierungen, die weite Akzeptanz gefunden haben. Er baut auf die Semantik der EDI-Standards auf und ermöglicht dadurch Unternehmen mit EDI-Systemen, diesen neuen Standard zu adaptieren ohne ihre Investitionen zu verlieren. Auch kleine und mittlere Unternehmen (KMU) erhalten mit xcbl die Möglichkeit, eine Kommunikation per EDI mit ihren größeren Geschäftspartnern aufzubauen. Dies bezieht sich jedoch nur auf die Standards X.12 und EDIFACT. Hierfür wurden spezielle Mapping-Tabellen erstellt, die eine Konvertierung zwischen EDIFACT-/X.12- und xcbl-transaktionen ermöglichen. 50 Die Kompatibilität erstreckt sich in der aktuellen Version noch nicht auf EDI-Subsets. Durch seine offene Gestaltung, kann xcbl an jegliche Erfordernisse angepasst werden. Hierdurch entsteht zwar eine große Flexibilität im Hinblick auf die Gestaltung, doch mit der Flexibilität steigen auch die Kosten, die notwendig sind um Systeme und Prozesse zwischen Unternehmen zu vereinbaren. Eine Schwachstelle von xcbl liegt in seiner mangelnden Kompatibilität mit früheren Versionen. Eine Integration kann hierbei nicht ohne erheblichen Datenverlust erfolgen Ausblick CommerceOne und weitere unterstützende Unternehmen arbeiten kontinuierlich an Aktualisierungen des Standards. Die Bibliothek wird ständig weiterentwickelt und neuen Erfordernissen angepasst. Die Detailliertheit der xcbl-dokumente und deren Anpassbarkeit an individuelle Anforderungen stellen ein wesentliches Merkmal dieses Standards dar. Hierin liegt die Stärke von xcbl. Vor allem aber die Möglichkeit einen XML-Standard einzusetzen, der mit vorhandenen EDI-Systemen kompatibel ist, wird auch in Zukunft zu Adaption und Bestand dieses Standards führen BizTalk Bei BizTalk handelt es sich um eine Initiative der Firma Microsoft aus dem Jahr BizTalk ist ein Produkt von Microsoft und daher nicht, wie die bisher betrachteten Standards, frei verfügbar. Enthaltene Spezifikationen dienen vor allem einer Integra- 50 Vgl. xcbl 2005d 26

38 3. Darstellung und Analyse wesentlicher Standards tion von Applikationen innerhalb und zwischen Unternehmen (Application Integration). Damit unterscheidet sich BizTalk von anderen Ansätzen in seinem Grundgedanken. Gegenstand einer Spezifikation ist die Integration von Applikationen, während auf Elemente einer umfassenden B2B-Integration verzichtet wird. Ziel von BizTalk ist demnach, verschiedene Anwendungsapplikationen miteinander kommunizieren zu lassen, nicht aber die Definition von Prozessen oder Geschäftsdokumenten zwischen Geschäftspartnern. Diese werden als gegeben vorausgesetzt. Ebenso wie cxml, xcbl, ebxml und RosettaNet basiert BizTalk auf der Sprache XML. BizTalk besteht im Wesentlichen aus zwei verschiedenen Komponenten. Diese umfassen das BizTalk Framework und einen BizTalk Compliant Server. Deren Aufgaben werden kurz erläutert. 51 BizTalk Framework Das BizTalk Framework dient als Gerüst zur Verwendung von BizTalk-konformen Geschäftsdokumenten. Hier werden Formatvorschriften und Elemente einer Biz- Talk-Nachricht definiert. Das BizTalk Framework liegt aktuell in der Version 2.0 vor. BizTalk Framework Compliant Server (BFC-Server) Der BFC-Server regelt die Kommunikation. Seine Aufgabe ist es, ein BizTalk- Dokument in eine BizTalk-Nachricht zu übersetzen und an die korrekte Stelle zu transportieren. Microsoft bietet hierfür den BizTalk Server 2004 an. Aber auch andere Implementierungen sind laut der BizTalk-Dokumentation möglich. Vorraussetzung ist lediglich die Konformität zum Standard BizTalk. Bis Juni 2002 gab es ebenfalls eine dritte Komponente, die BizTalk Repository. Hier konnten XML-Schemata zur Beschreibung von Geschäftsdokumenten in einer Datenbank abgelegt und jedem Interessierten über das Portal zur Verfügung gestellt werden. Zugunsten anderer Repositories wurde das Portal vor zwei Jahren geschlossen. BizTalk stellt lediglich einen Rahmen für den Austausch von Geschäftsdokumenten zur Verfügung, so dass eine BizTalk-Nachricht auch mit Dokumenten anderer Spezifikationen versehen sein kann, z.b. xcbl oder cxml. Im Folgenden wird nur auf das BizTalk Framework eingegangen, für weitere Informationen zum BizTalk Server wird auf die Homepage von Microsoft verwiesen Kommunikation Die Spezifikationen von BizTalk legen die Bestandteile einer Nachricht, die zwischen zwei Unternehmen versendet wird, eindeutig fest. Damit wird ein Rahmen für einen applikations- und unternehmensübergreifenden Datenaustausch festgelegt. Weder spezielle Datenelemente noch Strukturen von Geschäftsdokumenten werden spezifiziert. 51 Vgl. Microsoft 2005a, S

39 3. Darstellung und Analyse wesentlicher Standards Eine Integration mit BizTalk erstreckt sich über drei verschiedene Ebenen einer Implementierung. Dies sind die Geschäftsapplikationen der Handelspartner, sowie die BFC-Server und das Transportmedium. 53 Applikationen kommunizieren bei Anwendung von BizTalk durch Versenden und Empfangen von Geschäftsdokumenten über BFC-Server. Der Transport der Nachrichten zwischen den Servern verschiedener Handelspartner geschieht hierbei über Kommunikationsprotokolle wie HTTP oder Microsoft Messaging Queue (MSMQ). Der Ablauf einer Kommunikation mit BizTalk wird anhand der Abbildung 6 näher erläutert. Applikation Applikation Dokument Dokument BFC-Server BFC-Server Transport Transport Abbildung 6: Dokumentenaustausch mit BizTalk (Vgl. Microsoft 2005a, S. 9) Als erstes wird durch ein auftretendes Ereignis innerhalb einer Geschäftsapplikation ein XML-Geschäftsdokument erstellt. Anschließend werden zusätzliche Angaben hinzugefügt, die für das Routing benötigt werden. Danach wird dieses BizTalk Dokument an den BFC-Server weitergeleitet. Dieser transformiert das Dokument in eine BizTalk-Nachricht und verschickt es anschließend an den Server des Empfängers. Hier muss nun die Nachricht entpackt, validiert und anschließend an die Empfangsanwendung weitergegeben werden. Das Kommunikationsmedium ist für die Übertragung frei wählbar. 54 BizTalk unterscheidet streng zwischen Dokumenten und Nachrichten. Das von einer Applikation erstellte Geschäftsdokument wird zunächst in ein BizTalk-Dokument umgewandelt. Ein BizTalk-Dokument enthält Instruktionen über den Nachrichtenversand, wie Routing oder Identifikation, und angehängte Geschäftsdokumente, wie 53 Vgl Microsoft 2005a, S Vgl. Weitzel 2001, S

40 3. Darstellung und Analyse wesentlicher Standards Rechnungen oder Bestellungen. Diese werden jedoch bei der BizTalk-Spezifikation nicht definiert. Der Verwender kann entscheiden, eigene XML-Dokumente für den Datenaustausch anzufertigen oder Standards anderer Initiativen zu verwenden. Der Aufbau einer BizTalk-Nachricht ist in Abbildung 7 dargestellt. Abbildung 7: Aufbau einer BizTalk-Nachricht (Zhao/Sandahl 2002, S.2) BizTalk-Nachrichten sind erweiterte SOAP-Nachrichten (SOAP 1.1, SOAP with Attachments). 55 Das Simple Object Access Protokoll (SOAP) ist ein Netzwerkprotokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können. SOAP stützt sich hierbei auf die Dienste anderer Standards, wie XML zur Repräsentation von Daten und Internet-Protokolle zur Übertragung der Nachrichten. 56 Eine komplette BizTalk-Nachricht besteht aus einem BizTalk-Dokument und einem Transport-Umschlag. Dieser Umschlag enthält Informationen über Destination und Verwendung des Dokumentes. Hierzu zählen Empfänger und Senderdaten, die Art der Versendung aber auch Informationen über die Notwendigkeit einer Bestätigungsnachricht nach Erhalt. Weiterhin unterteilt sich ein BizTalk-Dokument in zwei Bereiche, Header und Body. Das BizTalk Framework enthält so genannte BizTags, welche als Erweiterungen des SOAP-Headers um zusätzliche Schichten für Sicherheit und Zuverlässigkeit dienen. Dies kann z. B. das Element endpoint sein. Seine Aufgabe ist die Information des Servers und der Applikationen über das Routing und den Empfang einer BizTalk-Nachricht. Der Body enthält das eigentliche Geschäftsdokument. BizTalk unterstützt ferner die Versendung von Empfangsbestätigungen. 57 Ein Biz- Talk-Receipt ist eine BizTalk-Nachricht, welche den Erhalt einer vorausgegangenen 55 Vgl. Wittenbrink 2003, S Vgl. Computerbase 2005b 57 Vgl. Erni/ Leser 2003, S.42ff. 29

41 3. Darstellung und Analyse wesentlicher Standards BizTalk-Nachricht bestätigt. Dabei werden zwei Arten von Bestätigungen unterschieden. 58 Die erste Variante ist der DeliveryReceipt. Hier wird lediglich der Eingang des Dokuments bestätigt. Der CommitmentReceipt geht eine Stufe weiter und informiert den Sender, ob der Server das Dokument angenommen und weiterverarbeitet hat. Bei diesen Nachrichtenarten befinden sich sämtliche Informationen im Header des Dokuments, der Body bleibt hierbei leer Klassifikation Auf der Datenebene werden von BizTalk keine Spezifikationen getroffen. Es wird auf externe Repositories oder eigene Entwicklungen für Inhalte und Strukturen von Dokumenten verwiesen. Dieser Standard von Microsoft wird daher der Kategorie generell zugeordnet. Auch die Prozessebene wird von BizTalk nicht im Einzelnen festgelegt. Die Modellierung von Geschäftsabläufen wird als gegeben vorausgesetzt. Mit dem BizTalk Server 2004 sind jedoch erstmals BizTags enthalten, die Informationen über den Kontext einzelner BizTalk-Dokumente enthalten und damit die Modellierung von Geschäftsabläufen unterstützen. BizTalk wird auf dieser Ebene als generell angesehen. BizTalk-Nachrichten können auf verschiedene Arten transportiert werden. Der Standard ermöglicht derzeit einen Nachrichtenaustausch über HTTP, SMTP und das Microsoft-eigene Protokoll MSMQ. Der Standard kann branchenübergreifend verwendet werden und ist durch seine offene Gestaltung auch für jeden Informationstyp und Prozessbereich anwendbar Stärken und Schwächen Ein wichtiger Punkt bei der Betrachtung des von Microsoft erstellten Standards ist die Tatsache, dass es sich hierbei um eine proprietäre Lösung handelt. BizTalk ist so konzipiert, dass es auf BizTalk Server 2004, Windows Server, SQL Server und Visio aufbaut. Besitzt ein Unternehmen bereits diese Produkte, kann BizTalk mit geringen Kosten eingeführt werden. Müssen alle diese Produkte zusätzlich angeschafft werden, sind jedoch hohe Kosten zu erwarten. Zwar ist BizTalk laut Microsoft nicht an diese Produkte gebunden, doch sind die enthaltenen Spezifikationen auf die Funktionalitäten der Microsoft-Produkte ausgerichtet. Die Verwendung anderer Lösungen kann daher zu Anpassungsproblemen führen. Eine Entscheidung für BizTalk ist dementsprechend langfristig mit einer Bindung an Software von Microsoft verbunden. Die Kombination des BizTalk Framework 2.0 und BizTalk Server 2004 stellt dennoch eines der vollständigsten B2B-Systeme dar, die es auf dem Markt gibt 59. Die eindeutige Festlegung der Bestandteile einer BizTalk-Nachricht gibt einen verlässlichen Rahmen vor, in den beliebige Geschäftsdokumente integriert werden können. Damit ist BizTalk für jedes Anwendungsszenario geeignet. 58 Vgl. Microsoft 2005b, S Vgl. Fitzgerald 2001, S

42 3. Darstellung und Analyse wesentlicher Standards Ausblick Microsofts BizTalk stellt eine gute Grundlage für die Erstellung und Übertragung von Nachrichten zwischen Unternehmen zur Verfügung. Eine Implementierung kann jedoch mit relativ hohen Kosten verbunden sein und damit kleine Unternehmen von einer Integration mit BizTalk abhalten. Allerdings ist nicht nur die Kommunikation zwischen BizTalk Servern möglich. Es können auch mit dem Standard konforme Server eingesetzt werden, um BizTalk-Nachrichten erstellen und verstehen zu können. Weiterhin integriert BizTalk vollständig konkurrierende Standards wie Rosetta- Net, welche mittels zusätzlichem BizTalk Accelerator (Werkzeug zur Übersetzung) genutzt werden können. 60 Zwar wurde im Juni 2002 die Repository von BizTalk eingestellt, doch wird dieser Standard auch weiterhin seine Bedeutung für den zwischenbetrieblichen Datenaustausch ausbauen. Neben der Integration anderer B2B- Standards ist hier auch die Vermarktung durch Microsoft als größtem Softwarekonzern als wichtiger Grund zu berücksichtigen ebxml Ende des Jahres 1999 entstand in einer gemeinsamen Initiative von OASIS und UN/CEFACT ein Projekt mit dem Namen electronic business XML (ebxml). ebxml wird von einer Reihe namhafter Unternehmen wie z.b. SUN, CommerceOne und IBM unterstützt. 61 Grundgedanke von ebxml ist der Entwurf von offenen technischen Spezifikationen, die einen einheitlichen, weltweiten, konsistenten Austausch elektronischer Geschäftsdaten auf der Grundlage von XML ermöglichen. 62 Besonderes Ziel der ebxml-initiative ist dabei, die Eintrittsbarrieren für das e-business für kleine und mittlere Unternehmen (KMU) sowie Entwicklungsländer zu senken. Daher wurde bei der Entwicklung darauf geachtet die finanziellen (technischen und auf Software bezogenen) Anforderungen für die Teilnahme an der ebxml-infrastruktur möglichst gering zu halten. ebxml ist im Gegensatz zu anderen Standards nicht darauf beschränkt, nur ein Standard für Geschäftsdokumente zu sein. Man hat mit ebxml die Möglichkeit, Geschäftsprozesse und darauf bezogene Transaktionen zu modellieren und diese in einem Verzeichnis, der so genannten Registry, zu hinterlegen. Unternehmen, die eine Kommunikationsstruktur mit ebxml aufgebaut haben, können ihre Daten und vereinbarten Geschäftsbeziehungen mit anderen Teilnehmern in dieser Registry speichern. Diese Daten können dann von allen Teilnehmern eingesehen werden und für neue Kooperationen genutzt werden. Über einen Messaging Service kann darauf aufbauend ein Nachrichtenaustausch konfiguriert werden. 63 Der wesentliche Unterschied zu den bisher vorgestellten Standards liegt darin, dass mit ebxml nicht nur schon langfristig bestehende Geschäftsbeziehungen zwischen bereits bekannten Partnern automatisiert werden können, sondern dieses auch mit bisher unbekannten Unternehmen möglich ist. Damit kann man nicht nur den Informationsaustausch optimieren, sondern gleichzeitig auch neue Kunden gewinnen. 60 Vgl. Microsoft 2005c 61 Vgl. Weizel 2001 S.116ff. 62 Vgl. ebxml Vgl. ebxml 2001, S.6ff. 31

43 3. Darstellung und Analyse wesentlicher Standards Die ersten in ebxml enthaltenen Spezifikationen wurden Anfang Mai 2001 veröffentlicht. Die Weiterentwicklung von ebxml wurde auf verschiedene Arbeitsgruppen aufgeteilt, welche sich z.b. um die Modellierung der Geschäftsprozesse oder um den Aufbau des Nachrichten-Services kümmern. Tabelle 2 gibt einen Überblick der verschiedenen Arbeitsgruppen und ihren Aufgaben. Aufgabengruppe Business Process Core Components Technical Architecture Transport/Routing & Packaging Registry & Repository Technical Coordination & Support Aufgabe/ Umsetzung Generierung des Metamodells Definition von Geschäftsprozessen Interaktion mit anderen Modellen Definition von Struktur und Inhalt der Kernkomponenten Kernkomponenten in syntaxneutraler Darstellung Wiederverwendbarkeit/ Erweiterbarkeit sicherstellen Definition des Wie bei den Geschäftsprozessen Darstellung von Geschäftsprozessen in Unabhängigkeit der technischen Lösung Definition, Implementierung und Bereitstellung einer Bibliothek mit Standard-Geschäftsprozessen Definition eines verbindlichen Vokabulars und einer eindeutigen Semantik Definition des Transfers und der Verpackung von Geschäftsdokumenten Physische und/oder logische Adressierung Routing der Nachrichten Vereinigung zusammen gehörender Nachrichten in eine so genannte Collection Sicherheitsaspekte beim Transport Entwurf einer detaillierten Vorlage für das Repository Definition von Schnittstellen zu anderen XML- Geschäftsprozessstandards Zusammentragen der Modelle/Vorlagen der Prozesseigentümer Sicherstellung des Zugriffs auf Repository/Registry über Web-Schnittstellen Metagruppe des Projekts Koordination der Arbeitsgruppen Einhaltung der ebxml-definitionen Tabelle 2: Arbeitsgruppen von ebxml und deren Aufgaben (Erni/Leser 2001, S. 22) Seit dem 11.Mai 2001 hat OASIS die auf die Infrastruktur von ebxml bezogenen Aufgaben übernommen. Hierzu gehören unter anderem der Transport (ebms), das Collaborative Profile Protocol (CPPA) sowie das Registry und Repository. UN/CEFACT arbeitet hingegen an den geschäftsbezogenen Komponenten eines Datenaustausches, den Geschäftsprozessen (BPSS) und den Core Components (CC). Im Folgenden werden die wichtigsten in ebxml enthaltenen Komponenten kurz in ihrer Funktionsweise vorgestellt. Diese umfassen die Spezifikationen Business Pro- 32

44 3. Darstellung und Analyse wesentlicher Standards cess Specification Schema, Core Components, Collaboration Protocol Profile, Collaboration Protocol Agreement, e-business Messaging Service und die Registry/Repository. 64 Business Process Specification Schema (BPSS) Das BPSS dient als Schema zur Spezifikation von Geschäftsprozessen. Um Geschäftsprozesse über das Internet abwickeln zu können, wird anhand des BPSS versucht, die Geschäftsprozesse in ihre Bestandteile zu zerlegen, zu analysieren und daraus Modelle zu entwickeln. Ziel von BPSS ist es also, Prozessmodelle in einer Geschäftssprache auszudrücken, der XML zugrunde liegt. Dies kann ein UML-Diagramm, ein XML-Schema oder eine Document Type Definition (DTD) sein. Ein Geschäftsprozess wird weiterhin durch seine Zustände charakterisiert. Es werden ein Anfangs- und ein Endzustand (startstate und completionstate) deklariert, zwischen denen beliebig viele Zwischenzustände auftreten können. Ein Übergang zwischen zwei Zuständen wird durch die Aktivitäten (transitions) der Unternehmen ausgelöst. BPSS enthält zwei verschiedene Arten einer Interaktion. Die BinaryCollaboration umfasst den Geschäftsprozess zweier Teilnehmer, während eine MultiPartyCollaboration die Interaktion mehrerer Parteien innerhalb eines Geschäftsprozesses beschreibt. Die Rollenverteilung zwischen den einzelnen Partnern bestimmt die Durchführung einer Transaktion. Der initiierende Teilnehmer beginnt mit einem request. Der weitere Verlauf wird von den Partnern ausgestaltet. Core Components (CC) Ein besonderes Merkmal der ebxml-spezifikation sind die so genannten Core Components. Dies sind wiederverwendbare und syntaktisch neutrale Bausteine, aus denen Geschäftsdokumente zusammengestellt werden können. Beispiele für Core Components wären das Kaufdatum oder das Währungszeichen, welche in vielen Geschäftsdokumenten zur Anwendung kommen. Collaboration Protocol Profile (CPP) ebxml enthält eine Definition von speziellen XML-Dokumenten, die zum einen Eigenschaften von ebxml-teilnehmern und zum anderen Kooperationsvereinbarungen zwischen Partnern beschreiben. Ersteres wird als Collaboration Protocol Profile (CPP), letzteres als Collaboration Protocol Agreement (CPA) bezeichnet. Ein CPP beinhaltet eine Beschreibung eines Unternehmens bezüglich seiner Eigenschaften im e-business. Dies beinhaltet neben Kontaktinformationen und Branchenangehörigkeit auch Angaben zu technischen Ausgestaltungen, wie unterstützte Geschäftsfelder oder Transport- und Mitteilungsprotokolle. Collaboration Protocol Agreement (CPA) CPAs bauen auf den verschiedenen CPPs der Geschäftspartner auf. Sie stellen im Allgemeinen eine Schnittmenge der formulierten CPPs dar. In ihnen werden vereinbarte Transaktionen für bestimmte Geschäftsprozesse festgelegt. CPAs 64 Vgl. ebxml 2001, S.16ff. 33

45 3. Darstellung und Analyse wesentlicher Standards können als Verträge zwischen zwei Geschäftspartnern verstanden werden. e-business Messaging Service (ebms) Der ebxml-messaging Service (ebms) bietet die Möglichkeit, Nachrichten und Dokumente zwischen den Geschäftspartnern unabhängig vom Kommunikationsprotokoll auszutauschen. Er definiert nur, wie eine Nachricht verpackt werden muss, um als ebxml-nachricht zu gelten. So ist es möglich, im Message Payload, der als Art Anhang zu verstehen ist, auch andere Nicht-XML-Daten zu versenden. Dies kann eine ASCII-Datei (von EDIFACT für Datenversand genutzt) aber auch ein XML-Dokument einer anderen Spezifikation, wie RosettaNet oder xcbl sein. Für den Transport können verschiedene Protokolle verwendet werden, auch wenn in der Standardspezifikation zunächst nur HTTP und SMTP beschrieben werden. Repository/Registry Die grundlegenden Komponenten einer ebxml-implementierung sind jedoch das Verzeichnis (Registry) und das Archiv (Repository). 65 Das Repository dient als zentraler Speicherort für sämtliche Informationen, die bei der Abwicklung eines Datenaustausches zwischen Unternehmen notwendig sein könnten. Neben den CPPs, CPAs und CCs werden hier auch andere wichtige Daten gespeichert. Auch Multimedia-Daten werden unterstützt. Die in der Registry enthaltenen Objekte sind Metadaten für die Inhalte der Repository. Damit übernimmt die Registry die Verwaltung dieser Daten und bietet zusätzliche Services an, wie z. B. eine komplexe Suche über die im Repository gespeicherten Dokumente. Die vorgestellten Komponenten bilden den umfangreichsten Standard, den es zurzeit gibt. Zwar sind die Geschäftsdokumente und Prozesse nicht bis ins Detail spezifiziert, es werden aber Modellierungsgrundlagen für deren Erstellung zur Verfügung gestellt. Vor allem aber die Repository/Registry ist eine Komponente, welche in anderen Standards bisher nicht enthalten ist. Wegen der Komplexität und dem Umfang der in ebxml enthaltenen Spezifikationen und Beschreibungen einer Infrastruktur konzentriert sich diese Arbeit lediglich auf die grundlegenden Merkmale von ebxml. Eine detailliertere Beschreibung findet sich in der Dokumentation des Standards Vgl. Wittenbrink 2003, S ebxml

46 3. Darstellung und Analyse wesentlicher Standards Kommunikation Dieser Abschnitt befasst sich mit einer Darstellung der grundlegenden Architektur und Funktionsweise von ebxml. Die Abbildung 8 zeigt den Verlauf einer Anbahnung und Durchführung von Handelskooperationen. Abbildung 8: Kommunikationsablauf mit ebxml (IBM 2005f) Die obige Abbildung zeigt, wie zwei Unternehmen zueinander finden, um Geschäfte zu tätigen. Hierbei können 6 aufeinander folgende Schritte unterschieden werden Nachdem das Unternehmen von der ebxml Registry erfahren hat, entscheidet es sich, daran teilzunehmen. 2. Unternehmen A entwickelt oder erwirbt eine ebxml-konforme Anwendung. 3. Um selbst von anderen Unternehmen gefunden werden zu können, stellt Unternehmen A ihr Geschäftsprofil (CPP) in die ebxml-registry ein. In diesem sind alle Informationen über die von ihr unterstützten ebxml- Schnittstellen, sowie Geschäftsszenarien enthalten. Dieses so genannte Business Profile wird anschließend in der Repository gespeichert. 4. Unternehmen B besitzt bereits ein ebxml-konformes System. B sucht in der Registry nach einem Handelspartner, welcher die gesuchten Geschäftsprozesse unterstützt und findet das Unternehmen A. Er ruft dessen Business Profile ab. 67 Vgl. ebxml 2001, S.8ff. 35

47 3. Darstellung und Analyse wesentlicher Standards 5. Daraufhin sendet Unternehmen B eine Nachricht direkt an die ebxml- Schnittstelle von Unternehmen A. Dieses enthält Angaben über eine gewünschte Handelsbeziehung. 6. Es folgt eine Verhandlungsphase, in der die Einzelheiten einer Kooperation definiert werden. Einigen sich die beiden Unternehmen, beginnt die Zusammenarbeit über den Austausch von ebxml-nachrichten. Für eine ausführlichere Darstellung der Architektur von ebxml sei auf die Dokumentation verwiesen. 68 In dieser befinden sich ebenfalls detaillierte Erläuterungen der Einführungs-, Entdeckungs-/Datenauffindungs- und Betriebsphase. Auf Basis eines vorher definierten Modells einer Transaktion kann der Austausch von Nachrichten organisiert werden. 69 Dabei wird XML nicht für eine Definition der Inhaltsformate verwendet, sondern lediglich als ein Umschlag für ein Geschäftsdokument mit Informationen über Sender, Adressat, Datum oder Geheimhaltungsvorschriften. ebxml Messaging Specification definiert ein generelles Format für Nachrichten mit einem in XML beschriebenen Kopfbereich (Header), einer Unterstützung für digitale Signaturen und potenziell beliebigen Formaten für Dokumenteninhalte. 70 Der Header einer ebxml-nachricht greift hierbei auf die Daten der an der Transaktion beteiligten Partner-CPAs zurück. Ansonsten gleicht der Aufbau einer ebxml- Nachricht denen, die bereits unter xcbl dargestellt wurden. Beide Standards benutzen SOAP-Spezifikationen Klassifikation Auf der Datenebene interagieren Unternehmen durch den Austausch von Geschäftsdokumenten. Hierbei stellen die einzelnen Geschäftsdokumente lediglich einen Teil eines umfassenden Prozesses dar. In ebxml werden Geschäftsdokumente aus drei verschiedenen Elementen zusammengesetzt. Core Components werden in der Core Library der Repository bereitgestellt. Diese sind branchenübergreifend verwendbar. Es gibt weitere Elemente wie domain components und business information objects. Sie sind auf verschiedene Branchen oder Geschäftsbereiche ausgerichtet und werden in speziellen Bibliotheken (z. B. Branchenportalen) abgelegt. Diese Komponenten spezifizieren Dateninhalte. Die Struktur eines Geschäftsdokumentes ist damit nicht allgemein vorgegeben. Auf der Datenebene ist ebxml als generell zu verstehen. ebxml besitzt als einer der wenigen Standards auch Spezifikationen für die Prozessebene. Das Business Process Specification Schema (BPSS) liefert eine Modellierungsgrundlage für die Spezifikation von Rollen der Geschäftspartner und Abfolgen von Geschäftsdokumenten. ebxml ist bezüglich der Prozessebene generell. Auf der Kommunikationsebene wird durch den Messaging Service von ebxml eine Transaktion ermöglicht. Hierbei wird kein spezielles Transportprotokoll vorgeschrieben. Jedes bekannte Protokoll wie FTP, SMTP oder HTTP wird unterstützt. Wie auch im Fall von BizTalk gibt es bei ebxml keine Branchenausrichtung. Der 68 ebxml Vgl. Wittenbrink 2003, S Vgl. Wittenbrink 2003, S

48 3. Darstellung und Analyse wesentlicher Standards Standard wird bewusst für alle Branchen gleichermaßen verwendbar gehalten und ermöglicht den Austausch von Daten jeden Informationstyps und Prozessbereichs. Dennoch findet der Standard in den Branchen Banken, Versicherungen und Transport/Logistik häufiger Anwendung Stärken und Schwächen ebxml ist ein offener Standard, der es auch kleinen Untenehmen ermöglicht eine B2B-Integration zur realisieren. Zudem bietet er die umfangreichsten Spezifikationen im Vergleich zu konkurrierenden Ansätzen. Vor allem in den zusätzlichen Möglichkeiten, die die Partnersuche beinhalten, liegen für Unternehmen große Vorteile bei der Anbahnung von Geschäften und der Integration von neuen Handelspartnern. ebxml ist weiterhin sehr flexibel gestaltet. Geschäftsdokumente beinhalten allgemeingültige Kernkomponenten, können aber dennoch anhand branchenspezifischer Elemente erweitert und an spezielle Anforderungen angepasst werden. Gerade in einem Umfeld sich ständig ändernder Marktverhältnisse sind flexible Strukturen von hoher Bedeutung. Ein weiterer Vorteil liegt darin, dass der Messaging Service, ähnlich wie bei BizTalk, einen Versand von Geschäftsdokumenten anderer Standards ermöglicht, indem der Inhalt in einen ebxml-konformen Umschlag integriert wird. Eine Kommunikation mit Unternehmen, die bereits andere Standards verwenden, ist daher in eingeschränkter Form möglich. ebxml befindet sich aktuell jedoch noch in der Entwicklungsphase. Erfolgreiche Implementierungen sind daher noch selten. Die Entscheidung, einen derartig umfangreichen Standard für seine Geschäftsabläufe zu nutzen, ist daher nicht nur mit einem hohen Entwicklungsaufwand, sondern auch mit einer unsicheren Zukunft verbunden Ausblick Bei der Betrachtung der Infrastruktur von ebxml wird deutlich, dass es sich um einen komplexen, aber auch weitestgehend kompletten Standard handelt, mit welchem Geschäfte abgewickelt werden können. Der Standard unterstützt nahezu alle benötigten Geschäftsprozesse und diese können bei Bedarf auch noch erweitert werden. ebxml bietet damit Unternehmen jeder Branche und Größe eine Lösung, miteinander elektronisch Daten auszutauschen und Prozesse unternehmensübergreifend zu gestalten. Dieser Standard spricht damit einen größeren Anwenderkreis an als diejenigen, die sich nur auf spezifische Bereiche konzentrieren. Mit der Zusammenarbeit von UN/CEFACT und OASIS bei der Entwicklung von ebxml stehen hinter diesem zwei namhafte Organisationen im Bereich des e-business. Durch deren kontinuierliche Unterstützung und erste Implementierungen innerhalb von bekannten Unternehmen, wie z.b. SUN, ist es sehr wahrscheinlich, dass ebxml sich zu einem der führenden Standards für die B2B-Integration entwickeln wird. 3.3 Gegenüberstellung der Ergebnisse Die Standards EDI, xcbl, cxml, BizTalk und ebxml wurden im letzten Abschnitt bezüglich ihrer Funktionsweise dargestellt und in die zuvor eingeführten Kategorien eingeordnet. Tabelle 3 zeigt einen Überblick der Ergebnisse. Hierbei werden der Vollständigkeit halber die Eigenschaften von RosettaNet bereits aufgeführt. Sie werden in Kapitel 4 eingehend betrachtet. 71 Vgl. Chiu 2002, S

49 3. Darstellung und Analyse wesentlicher Standards Tabelle 3: Übersicht der Ergebnisse (Vgl. Erni/Leser 2001, S. 75) 38

50 3. Darstellung und Analyse wesentlicher Standards Die Ergebnisse werden an dieser Stelle noch einmal zusammengefasst und einander gegenüber gestellt 72. Sowohl bei ebxml als auch bei RosettaNet handelt es sich um Standards, die neben der Datenebene auch die Prozessebene spezifizieren. Ebenso bieten sie ein umfangreiches Repository an, welches bei RosettaNet als Dictionary bezeichnet wird und dennoch dieselben Funktionen erfüllt. Bei ebxml sind bisher keine eigenen Dokumente erstellt worden, aber es werden andere Sprachen wie beispielsweise diejenige von xcbl unterstützt. Die bei RosettaNet verwendeten Geschäftsdokumente enthalten hingegen eine Fülle von Spezifikationen. Aktuell werden 130 verschiedene Dokumente von RosettaNet zur Verfügung gestellt. Die Objekte, die mit den beiden Standards abgedeckt werden können, sind nicht eingeschränkt. Ebenso gibt es für ebxml und RosettaNet wenige Einschränkungen bei den abgebildeten Prozessen. Eine umfassendere Unterstützung liegt jedoch in den Bereichen Handel und Supply Chain. Beide Organisationen sind für mehrere Industriebereiche anwendbar, konzentrieren sich derzeit jedoch auf einige bestimmte Sektoren. Hierbei handelt es sich bei ebxml um Banken, Versicherungen und die Logistikunternehmen und bei Rosetta- Net um die IT-Branche. Bei der Entwicklung von cxml und xcbl steht die Datenebene deutlich im Mittelpunkt. So werden von cxml aktuell 34 verschiedene Dokumente bereitgestellt und von xcbl sogar 44 Dokumente. cxml hat hierbei den Vorteil der Spezifikation von Punchout-Sitzungen, welche klar definiert und von anderen Standards bisher nicht unterstützt werden. Sowohl bei xcbl als auch bei cxml findet keine Einschränkung auf einen Industriesektor statt. Bei beiden Standards ist jedoch eine Fokussierung auf die Objekte Produkt und Kontrakt, sowie die Ausrichtung auf die Prozesse Handel, Supply Chain und Finanzen festzustellen. BizTalk enthält lediglich generelle Spezifikationen auf der Daten- und Prozessebene. Für den Austausch von Geschäftsdokumenten wird auf externe Schemata zurückgegriffen. Auch die Prozessebene beinhaltet kaum Spezifikationen. Bei der Beschreibung von BizTalk wird meist angegeben, dieser Standard würde auf eine Gestaltung der Prozessebene verzichten. 73 Doch neueste Entwicklungen haben zur Ausgestaltung von speziellen BizTags geführt, welche zumindest den Kontext beschreiben, in den Dokumente einzuordnen sind. Daher wird BizTalk in dieser Arbeit als generell bezüglich der Prozessebene bezeichnet. Wegen der offenen Gestaltung von BizTalk gibt es sowohl beim Industriefokus als auch bei den Objekten und Prozessen keine Einschränkungen. BizTalk ist jedoch der einzige Standard, der Eigentum eines Unternehmens ist. Er muss daher käuflich erworben werden. Für eine Einschätzung der entstehenden Kosten dient das folgende Beispiel. Ein einzelner BizTalk Server 2004 kostet in der Standard Edition Dollar. 74 Dieser ermöglicht die Integration von 10 Unternehmen. Er benötigt allerdings wiederum den Microsoft SQL-Server, der ebenfalls in der Standard Edition Dollar kostet. Hinzu kommt noch eine Windows Server Version die 999 Dollar kostet und zur Beschreibung noch Microsoft Visio 2002, welches 199 Dollar pro Nutzer kostet. Evtl. benötigte Acceleratoren zur Adaption weiterer Standards, wie z.b. RosettaNet kosten 72 Vgl. Erni/ Leser 2001, S. 58ff. 73 Vgl. Medjahed 2003, S Vgl. Microsoft 2005d 39

51 3. Darstellung und Analyse wesentlicher Standards jeweils Dollar. Damit würde man bei kompletter Neuanschaffung eines BizTalk- Systems ca Dollar an Software benötigen. Hierbei sind jedoch noch keine Projektkosten für eine Implementierung enthalten, die mit den Partnern durchgeführt werden muss. Auch die Standards xcbl und cxml werden von Unternehmen geführt, sie sind dennoch wie RosettaNet und ebxml und im Gegensatz zu BizTalk frei verfügbar. Im Vergleich der Standards kann festgestellt werden, dass branchenübergreifende Standards, wie xcbl ein allgemeines Vokabular für einen weiten Anwendungsbereich besitzen, aber für die Erhaltung der Flexibilität auf Daten- und Prozessebene eher generell gestaltet sind. ebxml beispielsweise definiert Geschäftsdokumente, Prozesse und Nachrichtenversand. Weiterhin stellt es eine Datenbank für eine Partnersuche zur Verfügung. Doch bis auf die Ebene der Kommunikation wird dies generell gestaltet. 75 Industriespezifische Standards, wie die verschiedenen EDI-Subsets, gehen bei der Gestaltung ihrer Spezifikationen bezüglich Dokumenten, Prozessen und Kommunikationsarten mehr ins Detail. Sie stellen ein auf den Industriebereich bezogenes Vokabular zur Verfügung und geben auch eine spezielle Beschreibung von Geschäftsprozessen und Dokumenten vor. EDIFACT unterscheidet z. B. zwischen verschiedenen Rechnungsdokumenten je nachdem für welche Branche es verwendet wird. So existiert ein Rechnungsdokument für die Automobilbranche und ein anderes für die Forstwirtschaft. xcbl hingegen kennt nur eine Rechnung. 75 Vgl. Kotinurmi 2004, S.14ff. 40

52 4. Grundlagen von RosettaNet 4. Grundlagen von RosettaNet In diesem Kapitel werden die Grundlagen des Standards RosettaNet betrachtet. Der erste Abschnitt (4.1) beginnt mit einer Darstellung der historischen Entwicklung und einer Herausarbeitung der grundlegenden Ziele dieser Initiative. Für die Erreichung dieser Ziele verfolgt das Konsortium hinter RosettaNet eine klare Strategie. Ihre Organisation ist genau festgelegt und einzelne Aufgaben werden bestimmten Mitgliedern zugeteilt. Nach einer kurzen Darstellung der Organisationsstruktur von RosettaNet (4.2) folgt der zentrale Abschnitt dieses Kapitels. Er enthält eine detaillierte Darstellung der entwickelten Spezifikationen und zusätzlich angebotenen Services (4.3). Darauf aufbauend wird dann die Funktionsweise einer Kommunikation mit RosettaNet erläutert (4.4). Mit den Grundlagen für ein Verständnis des RosettaNet- Standards erfolgt anschließend dessen Klassifikation gemäß der in Kapitel 3 eingeführten Kriterien (4.5). Entscheidet sich ein Unternehmen für eine Implementierung des RosettaNet-Standards, ist eine Reihe an Schritten für dessen Einführung erforderlich. Diese Implementierungsphasen können je nach Unternehmen unterschiedlich ausgestaltet sein. Ein Rahmenmodell hierfür wird in Abschnitt 4.6 vorgestellt. RosettaNet ist sehr um die Verbreitung und Akzeptanz ihres Standards bemüht, vor allem produktive Implementierungen werden eingehend gefördert. Für die Erreichung dieser langfristigen Ziele besitzt RosettaNet eine Reihe von Programmen, welche in Abschnitt 4.7 dargestellt werden. Auch wird der Standard ständigen Analysen und bei möglichen Schwachstellen Veränderungen oder Neuentwicklungen unterzogen. Die bereits durchgeführten und geplanten Weiterentwicklungen werden im Abschnitt 4.8 dargestellt. Das Kapitel schließt, wie die Betrachtungen der anderen Standards, mit einer Einschätzung der Zukunftsaussichten (4.9) ab. 4.1 Entwicklung und Ziele RosettaNet ist ein nicht auf Gewinn ausgerichtetes Konsortium und wurde im Februar 1998 in den USA gegründet. 76 Anfänglich bestand RosettaNet aus 40 Unternehmen aus dem Bereich der Informationstechnologie. Es ist seither schnell gewachsen und umfasst aktuell über 500 Unternehmen, zu denen namhafte Firmen wie Microsoft, Intel oder Cisco Systems gehören. Im August 2002 wurde RosettaNet in das Uniform Code Council (UCC) eingegliedert, es besteht jedoch eigenständig als Tochterunternehmen weiter. Das UCC beschäftigt sich mit der Entwicklung und Verbreitung von Standards und soll RosettaNet helfen, weitere Industriebereiche in seine Standardisierungsbemühungen zu integrieren. Die Bereiche Informationstechnologie, Elektronikbauteile, Halbleiterproduktion, Telekommunikation, Solution Provider und Logistik werden bereits durch RosettaNet unterstützt. 77 Als nächste Branchen sind Luft- und Raumfahrt sowie Unterhaltungselektronik geplant. Neben einer Ausweitung innerhalb von Industriebereichen, wird von RosettaNet auch dessen weltweite Akzeptanz gefördert. Regionale Außenstellen befinden sich derzeit in Amerika, China, Europa, Japan, Korea, Malaysia, Philippinen, Singapur und Taiwan Vgl. RosettaNet 2005c 77 Vgl. RosettaNet 2005c, Industry-Wide Partnership 78 Vgl. RosettaNet 2005c, Uniting Businesses Around The World 41

53 4. Grundlagen von RosettaNet RosettaNet wurde nach dem Rosetta-Stein benannt, welcher im Jahr 1799 in der Nähe der Stadt Rosette (Rashid) in Ägypten entdeckt wurde. 79 Der Stein ist auf 196 v. Chr. datiert und enthält Inschriften in drei verschiedenen Sprachen. Anhand dieses Steines war es Wissenschaftlern möglich verschiedene ägyptische Sprachen untereinander zu übersetzen und damit erstmalig Hieroglyphen zu entziffern. Die Mission von RosettaNet ist der des Rosetta-Steins ähnlich. RosettaNet hat die Aufgabe, Sprachbarrieren zu durchbrechen und eine gemeinsame Kommunikation zu ermöglichen. Ziel der RosettaNet-Initiative war ursprünglich die Homogenisierung von Prozessen zwischen Unternehmen der High-Tech Supply Chain. Das Konsortium begann mit der Entwicklung dieses Standards nach ausführlichen Analysen von Prozessen, welche innerhalb dieser Branche von Bedeutung sind. Die einzelnen Elemente dieser Prozesse wurden identifiziert und eingehend geprüft. Erst nach Analysen sämtlicher Ebenen der Supply Chain und einer Eliminierung von Ineffizienzen und Unstimmigkeiten, wurde eine Reihe von Geschäftsprozessen modelliert, die eine Automation von Abläufen zwischen Handelspartnern ermöglichen sollte. Allgemein wird die Zielsetzung von RosettaNet heute als die Entwicklung, Implementierung und Förderung eines offenen e-business Standards formuliert. 80 RosettaNet umfasst hierbei nicht nur die Festlegung eines Nachrichtenformats, sondern auch die Gestaltung von Regeln und Abläufen für Transaktionen zwischen Handelspartnern. 4.2 Das RosettaNet-Konsortium Für ein besseres Verständnis der Arbeitsweise der RosettaNet-Initiative wird zunächst der organisatorische Aufbau des Konsortiums beschrieben. Der Standard RosettaNet ist allgemein für alle Unternehmen offen verfügbar. Dennoch beinhaltet eine Mitgliedschaft in dessen Konsortium zusätzliche Möglichkeiten. Mitglieder von RosettaNet können direkten Einfluss auf die Entwicklung und Bewertung neuer Komponenten ausüben. Ihnen bietet sich ebenfalls der Zugang zu weitreichenden Wissens- und Erfahrungsbeständen und Services für effiziente Implementierungen. 81 Den Unternehmen werden verschiedene Ebenen einer Mitgliedschaft angeboten. Hierzu gehören Council Member, Partner und Associate Partner. Global Council Mitglieder des Global Councils beeinflussen die strategische Ausrichtung der Initiative und entscheiden über weitere Entwicklungen des Standards. 82 Sie stellen erforderliche Ressourcen und finanzielle Mittel für Maßnahmen der Weiterentwicklung und Verbreitung des Standards zur Verfügung. Hierzu gehört z.b. die Finanzierung der RosettaNet-Programme. RosettaNet besitzt sechs Global Councils, welche die Vertretung verschiedener Industriebereiche übernehmen. Sie setzen sich aus führenden Unternehmen der Bereiche Halbleiterelektronik (SM), Elektronikbauteile (EC), Unterhaltungselektronik (CCE), Telekommunikation (TC), Solution Providers (SP), und Logistik (LG) zusammen. Tabelle 4 zeigt einen Überblick der einzelnen Councils mit Informationen über deren Zusammenset- 79 Vgl. RosettaNet 2005d 80 Vgl. RosettaNet 2005a 81 Vgl. RosettaNet 2005a 82 Vgl. RosettaNet 2005e 42

54 4. Grundlagen von RosettaNet zung und einer Angabe beispielhafter Mitgliederunternehmen. 83 Council Beschreibung Mitglieder CCE Council Repräsentiert den Industriebereich Unterhaltungselektronik mit Herstellern, Zwischenhändlern und Service Providern. EC Council LG Council SM Council SP Council TC Council Repräsentiert Unternehmen der Elektronikbauteile-Industrie mit Komponentenherstellern, Lieferanten für Elektronikbauteile, Konnektoren und Zusatzteilen. Zusätzlich Zwischenhändler, Händler und Endkunden. Repräsentiert den Logistiksektor mit sämtlichen Transportunternehmen, wie See- und Luftfahrtunternehmen. Repräsentiert Unternehmen, wie Hersteller, Materiallieferanten und Unternehmen für Zusammenbau, Test und Prüfung der Komponenten. Repräsentiert Unternehmen im Bereich Solution Provider wie Applikationsentwickler, Implementierungs- Services und Beratungsunternehmen. Repräsentiert Unternehmen im Telekommunikationssektor wie Gerätehersteller oder Unternehmen für Netzbetrieb. Arrow Cisco Systems Compaq Toshiba Samsung Philips UPS APS Logistics Schenker Shinko Electric Industries Texas Instruments Intel i2 Technologies webmethods BEA Systems Deutsche Telekom Motorola Nokia Tabelle 4: Überblick der RosettaNet Councils (Eigene Darstellung) Aus den Mitgliedern dieser Ebene werden Vertreter für das Executive Committee und das Architectural Advisory Committee gewählt. Partner Unternehmen, die weder die nötige Zeit noch erforderliche Ressourcen für eine Teilnahme als Global Council Member aufbringen können, wird die Möglichkeit einer Mitgliedschaft als Partner angeboten. Partner erhalten Zugang zu umfassenden Wissensbeständen, Erfahrungen, Services und Unterstützung. Sie können ebenfalls an Entwicklungsprogrammen für Standards teilnehmen. Die Vorteile einer Partnerschaft liegen weiterhin in einem Angebot an RosettaNet-Seminaren und Ressourcen für Implementierungsvorhaben. 83 Vgl. RosettaNet 2005e, Levels of Membership 43

55 4. Grundlagen von RosettaNet Associate Partner Eine Mitgliedschaft als Associate Partner beinhaltet zusätzliche Vorteile im Vergleich zu einer normalen Partnerschaft. Mitglieder dieser Ebene erhalten neben Informationen über andere Partnerunternehmen auch Benachrichtigungen über neue oder erweiterte Spezifikationen. Weiterhin wird ihnen ein Zugang zur RosettaNet-Website ermöglicht mit Rechten eigene Informationen bezüglich Unternehmensprofil, angebotenen Seminaren oder themenbezogenen Foren zu publizieren. Seit dem 1. August 2002 wird RosettaNet von der Uniform Code Council geleitet. Das Konsortium untersteht damit in erster Linie dem Board des UCC. In diesem sind drei gewählte Vertreter aus dem RosettaNet Executive Committee vertreten, welches wiederum aus Vertretern der einzelnen Industry Boards zusammengesetzt ist. Das RosettaNet Executive Commitee wird bei seinen Aufgaben von zwei weiteren Komitees beraten, dem Architectural Advisory und dem Marketing Advisory Commitee. Das Architecture Advisory Committee wurde erst Ende 2004 gegründet und ist für die Entwicklung der RosettaNet-Architektur verantwortlich. 84 Es hat die Aufgabe der Beratung des Executive Committee in diesbezüglichen Fragestellungen. Hingegen fungiert das Marketing Advisory Committee als zentrale Stelle für die strategische Förderung der Verbreitung und Akzeptanz von RosettaNet. Abbildung 9 zeigt eine Zusammensetzung des RosettaNet-Konsortiums. Board of Uniform Code Council Architecture Advisory Committee RosettaNet Executive Committee Marketing Advisory Committee SP Council (gegründet 2001) CCE Council (gegründet 1998) SM Council (gegründet 2000) EC Council (gegründet 1999) TC Council (gegründet 2003) LG Council (gegründet 2004) Abbildung 9: Aufbau des RosettaNet-Konsortiums (Vgl. IBM 2004a) 84 Vgl. RosettaNet 2005f, 2004 RosettaNet Press Releases 44

56 4. Grundlagen von RosettaNet 4.3 Spezifikationen und Services Grundidee Die von RosettaNet entwickelten Spezifikationen beinhalten einen gemeinsamen Grundgedanken. Sie orientieren sich an der Kommunikation zwischen Menschen. 85 Die Mensch-zu-Mensch Kommunikation ist bei Geschäftsvorgängen sehr erfolgreich und effizient, da sich die beteiligten Geschäftspartner über gemeinsame Prozesse auf der elementarsten Ebene einigen können. Menschen erzeugen und hören Laute und verwenden ein gemeinsames Alphabet, aus welchen Wörter generiert werden. Mit gemeinsamen grammatischen Regeln können aus diesen Wörtern Dialoge geformt werden. Diese Dialoge dienen nun im Geschäftsleben dazu, einen Geschäftsprozess zu beschließen. Dies geschieht bei Verhandlungen über ein Kommunikationsinstrument wie beispielsweise dem Telefon. Ähnlich stellt sich eine Kommunikation mithilfe der Informationstechnologie dar. Anstelle der Laute von Menschen werden nun Informationen von Servern über das Internet ausgetauscht. Die Sprachen HTML oder XML nehmen die Funktion des Alphabets ein und die e-business-applikationen der Geschäftspartner dienen als Instrumente zur Übermittlung von e-business-prozessen. Dazwischen besteht jedoch ein Mangel an Vereinbarungen, welche die Wörter, die Grammatik und den Dialog regeln, um e-business Prozesse unterstützen zu können. An dieser Stelle setzen die Spezifikationen von RosettaNet an (Vgl. Abbildung 10). Telephone Telefon Geschäftsprozess Dialog Grammatik Wörter Alphabet Klänge/Laute E-commerce Application e-business Prozess Partner Interface Process (PIP) RNI Framework Dictionaries XML Internet RosettaNet Mensch-zu-Mensch Geschäftsaustausch System-zu-System Geschäftsaustausch Abbildung 10: Grundidee der RosettaNet-Spezifikationen (Vgl. Nickull 2001) 85 Vgl. RosettaNet 2005c, E-Business Standards Initiative 45

57 4. Grundlagen von RosettaNet Die RosettaNet Dictionaries stellen die notwendigen Wörter zur Verfügung, das RosettaNet Implementation Framework (RNIF) agiert als eine gemeinsame Grammatik und die RosettaNet Partner Interface Processes (PIPs) formen den Geschäftsdialog für eine Unterstützung von e-business-prozessen Partner Interface Processes Den Kern der RosettaNet-Spezifikationen stellen die Partner Interface Processes (PIPs) dar. Mit den PIPs werden Geschäftsprozesse und damit verbundene Dokumente spezifiziert. Gegenwärtig werden von RosettaNet mehr als einhundert verschiedene PIPs unterschiedlicher Anwendungsbereiche zur Verfügung gestellt. 86 Sie werden ständig weiterentwickelt, wobei die Versionierung jedes PIPs einzeln erfolgt. Bei der Entwicklung eines PIPs werden eine Reihe von Phasen durchlaufen, bis dieser von Anwenderunternehmen für die Automatisierung eines Geschäftsvorganges genutzt werden kann. Der Standardisierungsprozess umfasst die Bewertung durch RosettaNet-Mitglieder und Test-Implementierungen durch Partner-Unternehmen. 87 Erst nach einer Bewährung in realen Implementierungsszenarien und der Akzeptanz innerhalb des Konsortiums wird der neue PIP publiziert. Jeder verfügbare PIP wird hierbei mit seinem aktuellen Status versehen, z. B. in production oder waiting validation. PIPs sind XML-basierte System-zu-System-Dialoge, welche Geschäftsprozesse zwischen Handelspartnern unterstützen. Ein Geschäftsprozess besteht hierbei aus mehreren Schritten, die zusammen einen Vorgang komplettieren. Ein Kunde beispielsweise, der eine mit Produktbezeichnung und -anzahl versehene Anfrage an dessen Hersteller senden möchte, initiiert eine Beschaffungsanfrage (Request Purchase Order). Der Hersteller prüft die Verfügbarkeit seines Produkts in seinem Lagerbestandssystem und sendet eine Bestätigung oder Ablehnung an den Interessenten. Der Prozess der Beschaffungsanfrage ist hierdurch abgeschlossen. Nicht alle hiermit verbundenen Vorgänge sind für beide Parteien sichtbar. Man unterscheidet zwischen öffentlichen und privaten Prozessen. Private Prozesse finden innerhalb des Systems eines Partners statt, wie die Prüfung der Produktverfügbarkeit. RosettaNet definiert jedoch nur öffentliche Prozesse, diese sind für beide Parteien sichtbar und erfordern Aktivitäten zwischen ihnen. Die PIP-Spezifikationen können als ein zusammengesetztes Paket von der Rosetta- Net-Website heruntergeladen werden. Ein solches Paket enthält neben einer strukturellen und inhaltlichen Definition von Geschäftsdokumenten (basierend auf DTDs), auch exakte Angaben zu Prozesslaufzeiten, Reaktionen der Partner und Fehlerzustands-Mechanismen. Diese sind in Sequenzdiagrammen modelliert und in einem ausführlichen Implementierungsleitfaden beschrieben. 86 Eine vollständige Liste entwickelter PIPs befindet sich im Anhang. 87 Vgl. RosettaNet 2005a 46

58 4. Grundlagen von RosettaNet Im Einzelnen werden die folgenden Komponenten von PIPs spezifiziert 88 : 1. PIPs beinhalten Definitionen der einzelnen Rollen, die Handelspartner in einem Geschäftsprozess einnehmen. 2. Den einzelnen Rollen werden innerhalb eines Geschäftsprozesses verschiedene Aktivitäten zugeordnet. 3. Ein PIP enthält je nach Geschäftsprozess verschiedene Dokumentarten. Deren Inhalt und Aufbau, sowie die Sequenzen von Nachrichten, die innerhalb eines Prozesses zwischen den Rollen ausgetauscht werden, sind in den Spezifikationen enthalten. 4. PIPs definieren die Attribute eines Nachrichtenaustausches, wie z. B. Reaktionszeiten, Authentifikation, Autorisierung und Anzahl der Wiederholungsversuche bei fehlerhafter Übermittlung. Ein PIP stellt eine für sich abgeschlossene Komponente dar, er kann jedoch mit anderen kombiniert oder in andere PIPs integriert werden, um einen weitreichenderen Geschäftsvorgang zu automatisieren. PIPs werden für verschiedene Geschäftsprozesse entwickelt. Aktuell werden von RosettaNet, acht verschiedene Kernprozesse (Cluster) unterschieden, denen die einzelnen PIPs zugeordnet werden können. 89 Man unterscheidet Cluster für Support, Partner, Produkt und Dienstleistungen, Produktinformationen, Auftragsmanagement, Lagerverwaltung, Marketing, Service und Support und Herstellung. Die einzelnen Cluster werden nochmals in Unterkategorien unterteilt, die Segmente, welche die einzelnen PIPs beinhalten. Tabelle 5 enthält eine Übersicht der Cluster mit zugehörigen Beschreibungen und eine Auflistung enthaltener Segmente. Es werden weiterhin Beispiele für PIPs der jeweiligen Kategorie gegeben. Bezeichnung Beschreibung Segmente Beispiele enthaltener PIPs Cluster 0 Support Administrative Funktionen von RosettaNet A: Administration C: Testing PIP 0A1: Notification of Failure Cluster 1 Cluster 2 Partner, Produkt und Dienstleistungen (Partner Product and Service Review) Sammlung, Wartung und Distribution von Daten über Geschäftspartner (Handelspartnerprofil) Produktinformationen (Product Information) Produktbeschreibungen, Änderungsnachweise und Synchronisation mit Produktkatalogen A: Partner Review B: Product and Service Review A: Preparation for Distribution B: Product Change Notification C: Product Design Information D: Collaborative Design and Engineering PIP 1B2: Request Authorization Status PIP 2A1: Distribute New Product Information 88 Vgl. RosettaNet 2005i, S Vgl. RosettaNet 2005g 47

59 4. Grundlagen von RosettaNet Cluster 3 Cluster 4 Cluster 5 Cluster 6 Cluster 7 Bezeichnung Beschreibung Segmente Beispiele enthaltener PIPs Auftragsmanagement (Order Management) Marketing (Marketing Information Management) Auftragsabwicklung: Bestellung, Konfiguration, Versand, finanzielle Abwicklung Lagerverwaltung (Inventory Management) Lagerbestandsmanagement: Nachbestellungen, Auswertungen Vermittlung von Marketing-informationen, wie Aktionen oder Sonderverkäufe Service und After-Sales-Services: Support (Service Garantieleistungen, and Support) Technischer Support Herstellung (Manufacturing) Austausch von Daten zu Produktdesigns, Konfigurationen, Qualitätsmaßstäben A: Quote and Order Entry B: Transport and Distribution C: Returns and Finance D: Product Configuration A: Collaborative Forecasting B: Inventory Allocation C: Inventory Reporting D: Inventory Replenishment E: Sales Reporting F: Price Protection A: Lead Opportunity Management B: Marketing Campaign Management C: Design Win Management D: Ship from Stock and Debit A: Provide and Administer Warranties, Service Packages and Contract Services B: Provide and Administer Asset Management C: Technical Support and Service Management A: Design Transfer B: Manage Manufacturing WO and WIP C: Distribute Manufacturing Information PIP 3A4: Request Purchase Order PIP 3C3: Notify of Invoice PIP 4B2: Notify of Shipment Receipt PIP 5B1: Distribute Marketing Activity Information PIP 6C2: Request Warranty Claim PIP 7C3: Notify of Quality Goals Tabelle 5: Übersicht der Cluster und Segmente (Eigene Darstellung) Die Bezeichnung des einzelnen PIPs erfolgt nach dem Schema PIP<ClusterNr.><SegmentNr.><AktivitätsNr.>. Nach den Namenskonventionen von RosettaNet bezeichnet dementsprechend der PIP 3A1, die Aktivität 1 im Segment A des Clusters 3. Eine beispielhafte Transaktion unter Verwendung von Partner Interface Processes wird anhand einer Request Purchase Order (PIP 3A4) kurz erläutert. Die Request Purchase Order ermöglicht es dem Käufer eines Produktes eine Anfrage für einen Bestellauftrag zu formulieren und an einen Verkäufer zu senden. Dieser kann hierauf dann mit einer Nachricht antworten, die den Auftrag bestätigt, ablehnt oder über dessen Bearbeitung informiert. 90 Wird lediglich eine Nachricht über den Bearbeitungsstatus der Anfrage an den Käufer übermittelt, kann später anhand 90 Vgl. RosettNet 2005h, S.5 48

60 4. Grundlagen von RosettaNet des PIP 3A7 Notify of Purchase Order Acknowledgement eine verzögerte Bestätigung oder Ablehnung erfolgen. Der PIP 3A4 ordnet sich insgesamt in ein Prozessszenario ein, in dem einige Aktivitäten bereits erfolgt sein sollten. 91 Hierzu gehört die Preis- und Lieferbarkeits-Anfrage bezüglich eines Produktes (z.b. durch PIP 3A2) und eine Anfrage bezüglich der zu bestellenden Menge eines Produktes (z.b. durch PIP 3A1). Auf den PIP 3A4 können weitere Prozesse wie eine Auftragsänderung (z. B. durch PIP 3A8), eine Stornierung des Auftrages (z.b. durch PIP 3A9) oder eine Anfrage über den Auftragsstatus (z.b. durch PIP 3A5) erfolgen. 92 Sind die Aktivitäten, die in einem PIP definiert sind nicht durchführbar, erfolgt automatisch eine Fehlermeldung, das PIP 0A1. Die Vorbedingungen, die Ausführung und mögliche nachfolgende Aktivitäten werden für die Request Purchase Order in Abbildung 11 anhand eines Sequenzdiagrammes dargestellt. Abbildung 11: Sequenzdiagramm des PIP 3A1 (Vgl. RosettaNet 2005m) 91 Vgl. RosettNet 2005h, S.6 92 Vgl. RosettaNet 2005h, S.6 49

61 4. Grundlagen von RosettaNet Die einzelnen PIPs enthalten Spezifikationen der Rollen, welche die Handelspartner in einem Geschäftsprozess einnehmen. Bei der Request Purchase Order sind dies die Rollen Käufer und Verkäufer. 93 Die einzelnen Rollen führen innerhalb eines PIPs verschiedene Geschäftsaktivitäten aus. Der PIP 3A4 enthält hierbei die Aktivität Request Purchase Order, welche von dem Käufer initiiert wird und eine automatische Nachricht über einen Bestellauftrag an den Verkäufer sendet. Eine Geschäftsaktivität verwendet als Grundlage verschiedene Dokumente. Diese werden anhand der für jeden PIP definierten Message Guidelines von den beiden Rollen generiert und untereinander ausgetauscht. Die Request Purchase Order enthält zwei verschiedene Dokumente, die Purchase Order Request, welche eine Anfrage des Käufers über die Annahme eines Bestellauftrages an den Verkäufer darstellt, sowie die Purchase Order Confirmation. 94 Sie wird vom Verkäufer an den Käufer gesendet und enthält Informationen über die Annahme, Ablehnung oder Bearbeitung des Auftrages. Notwendige Datenelemente dieser Dokumente (Business Data Entity, Fundamental Business Data Entity und die Global Indentifying Properties) sind im RosettaNet Business Dictionary (RNBD) enthalten. Abbildung 12 zeigt ein PIP-Interaktionsdiagramm anhand des PIP 3A4, aus welchem die Rollen der Geschäftspartner, die Nachrichten zwischen den Handelspartnern sowie deren Abfolge hervor gehen. Abbildung 12: PIP-Interaktionsdiagramm (Vgl. RosettaNet 2005h, S.13) Die Nachrichten die in einer Transaktion ausgetauscht werden, können den Kategorien Aktions-Nachrichten und Signal-Nachrichten zugeordnet werden. 95 Aktions- Nachrichten enthalten geschäftsrelevante Daten, z.b. ein Geschäftsdokument wie die Purchase Order Request (Schritt 1. und 1.2 in der Abbildung). Signal-Nachrichten 93 Vgl. RosettaNet 2005h, S.8 94 Vgl. RosettaNet 2005i, S6 95 Vgl. RosettaNet 2005i, S.5 50

62 4. Grundlagen von RosettaNet sind hingegen Benachrichtigungen an den Absender einer Nachricht. Sie können ein positives oder negatives Signal enthalten. Das positive Signal an den Absender nennt man Receipt-Acknowledgement (Schritt 1.1 und in der Abbildung). Sie wird bei Implementierung eines PIPs von dem Empfängersystem automatisch generiert und versendet, wenn die eingetroffene Nachricht in ihrer Struktur und Syntax fehlerfrei ist. Ist die Nachricht fehlerbehaftet, wird hingegen eine Receipt- Acknowledgement-Exception-Nachricht mit Angabe der fehlerbehafteten Datenelemente an den Sender übermittelt RosettaNet Implementation Framework Das RosettaNet Implementation Framework (RNIF) dient der Realisierung eines Datenaustausches über PIPs. 96 Es stellt ein allgemeines Regelwerk für den Aufbau einer Kommunikation zwischen Handelspartnern dar. Hierbei umfasst das RNIF Spezifikationen für Inhalt und Aufbau der Nachrichten, Transportprotokolle und Sicherheitsmechanismen. Den Kern des RNIF bildet die Business Message Specification, welche die RosettaNet-Nachricht definiert. Abbildung 13 zeigt die wesentlichen Bestandteile einer RosettaNet Business Message. Abbildung 13: RosettaNet Business Message (Vgl. RosettaNet 2005i, S.10) Das RNIF ermöglicht das Verständnis der Nachrichten für die Handelspartner durch die Angabe detaillierter Regeln für die Zusammensetzung einzelner Nachrichten und den Ablauf ihres Versands. Alle Nachrichten müssen aus einem Preamble Header, einem Delivery Header, einem Service Header und einem Service Content Document 96 Vgl. RosettaNet 2005i, S.1 51

63 4. Grundlagen von RosettaNet bestehen. 97 Während der Preamble Header Daten des Standards und dessen Version enthält, werden im Delivery Header grundlegende Versanddaten, wie die Partner- Identifikationsnummer definiert. Der Service Header enthält hingegen Angaben bezüglich des Kontextes einer Nachricht innerhalb eines Prozesses. Hierzu gehört z. B. die Rollendefinition der Handelspartner. Der so genannte Payload besteht aus dem Service Content und optional einigen Attachments. In ihm sind die geschäftsrelevanten Daten einer Transaktion enthalten. Der Service Content enthält entweder eine Aktion oder ein Signal eines spezifischen PIPs. Im Fall einer Aktions-Nachricht können dem Payload einige Anhänge hinzugefügt werden. Die Anhänge müssen im Gegensatz zum Service Content keine XML- Dokumente enthalten. 98 Word-Dokumente, PDF s, GIF s oder andere Formate können an dieser Stelle als zusätzliche Information zum eigentlichen Geschäftsdokument integriert werden. Wie in Abbildung 13 zu sehen ist, verwendet das RNIF im Gegensatz zu den bisher betrachteten Standards nicht SOAP als Transportcontainer. Es verpackt Nachrichten in einem MIME- bzw. S/MIME-Envelope (Secure/ Multipose Internet Mail Extensions). Je nachdem ob eine Nachricht verschlüsselt, unverschlüsselt oder mit hinzugefügter digitaler Signatur versendet wird, erfolgt die Art der Verpackung unterschiedlich. 99 Zu den verschiedenen Verfahrensweisen wird auf die RNIF-Spezifikation verwiesen. 100 Momentan kann die Übertragung einer RosettaNet-Nachricht über die Transportprotokolle HTTP, HTTPS und SMTP erfolgen. 101 Bei der Definition der Transportprotokolle wurde auf eine weitgehende Unabhängigkeit des Verpackungsprozesses einer Nachricht und der Art ihrer Versendung geachtet. Hierdurch wird für die Implementierung eine hohe Flexibilität bei der Auswahl eines geeigneten Protokolls gewährt. Neben einer erhöhten Flexibilität wird durch die aktuelle Version des RNIF ebenfalls versucht, einen hohen Grad an Kompatibilität zu ermöglichen. Alle Solution Provider sind verpflichtet ein spezielles Transportprotokoll in ihre Produkte zu implementieren. Hierfür wurde HTTP ausgewählt. Alle Unternehmen, die das RNIF 2.0 verwenden, können sich durch diese Maßnahme auf die Unterstützung durch ein allgemeines Protokoll verlassen. Eine RosettaNet-Implementierung zwischen Handelspartnern wird hierdurch erheblich erleichtert. Der Transport geschäftsbezogener Daten ist ohne den Einsatz von Sicherheitsmechanismen jedoch risikobehaftet. Die aktuelle Version des RNIF umfasst dementsprechend Definitionen bezüglich Identifikation, Authentifikation, Autorisierung, Nicht- Zurückweisbarkeit und Rückverfolgung. Identifikation Die Identifikation stellt die Basis einer sicheren Transaktion zwischen Handelspartnern dar. Mit ihr können die Identitäten der einzelnen Parteien eindeutig festgestellt werden. 102 Bei RosettaNet ist die Identifikation ein Bestandteil des Headers einer Nachricht. Das RNIF spezifiziert hierzu die GlobalBusinessIdentifier 97 Vgl. RosettaNet 2005i, S Vgl. RosettaNet 2005i, S Vgl. RosettaNet 2005i, S Vgl. RosettaNet 2005i, S.39ff 101 Vgl. RosettaNet 2005i, S.59ff 102 Vgl. SoberIT 2004, S

64 4. Grundlagen von RosettaNet als ein Element des Delivery Headers. Die GlobalBusinessIdentifier ist eine DUNS-Nummer (Data Universal Numbering System), die zwischen zwei Handelspartnern zur Identifikation der Gegenseite vor einer Transaktion ausgetauscht wird. Eine Erweiterung der DUNS-Nummer um zusätzliche vier Ziffern (DUNS+4) kann optional erfolgen, um neben der Identifikation eines Unternehmens auch dessen Standort eindeutig zu identifizieren. Während die Verwendung der DUNS- Nummer im RNIF vorgeschrieben ist, kann der Einsatz einer DUNS+4 optional erfolgen. Mehr zu den von RosettaNet verwendeten Identifikationsnummern erfolgt in Abschnitt Authentifikation Nachdem die Handelspartner einer Transaktion identifiziert wurden, erfolgt in einem zweiten Schritt die Überprüfung der angegebenen Identitäten. Eine Authentifikation ist demnach die Folge einer Identifikation. 103 Für B2B-Transaktionen werden für diesen Zweck meist digitale Zertifikate eingesetzt. Ein digitales Zertifikat wird von einer autorisierten Zertifizierungsstelle ausgestellt und enthält Informationen über dessen Inhaber sowie einen Verschlüsselungs-Key, mit welchen Nachrichten digital signiert werden können. Eine digitale Signatur ist ein relativ fälschungssicheres Kennzeichen, welches durch ein Verschlüsselungsverfahren erzeugt wird und mit dem man die Echtheit und Herkunft von digitalen Daten belegen kann. 104 Sie funktioniert hierbei durch den Einsatz eines öffentlichen und eines privaten Schlüssels (asymmetrisches Verschlüsselungsverfahren). Während der öffentliche Schlüssel allgemein bekannt sein muss, kennt den privaten Schlüssel nur dessen Inhaber. Bei der Übermittlung von Daten wird beispielsweise der öffentliche Schlüssel des Empfängers dazu verwendet, eine Nachricht zu verschlüsseln. Zur Entschlüsselung kann hingegen nur dessen zugehöriger privater Schlüssel verwendet werden. Da es keine Möglichkeit gibt, aus dem öffentlichen den zugehörigen privaten Schlüssel zu berechnen, kann mit diesem Verfahren die Authentizität der Daten sowie deren Herkunft eindeutig belegt werden. Die Authentifikation wird im RNIF durch die Anforderung einer Integration von digitalen Signaturen in Nachrichten gewährleistet. Die einzelnen PIP- Spezifikationen enthalten Angaben darüber, welche der enthaltenen Nachrichten mit einer digitalen Signatur zu versehen sind. Eine Authentifikation ist demnach nicht zwingend für alle PIPs vorgeschrieben. Während der PIP 3C6, welcher eine Zahlungsanweisung an eine Bank darstellt, eine Verpflichtung zur Verwendung einer digitalen Signatur beinhaltet, ist deren Verwendung bei einer Preis- und Verfügbarkeitsanfrage an einen Verkäufer (PIP 3A2) lediglich als eine generelle Empfehlung ausgestaltet. Eine RosettaNet-Nachricht wird hierbei nach den S/MIME/IETF Spezifikationen digital signiert. 105 Autorisierung Mit einer Autorisierung wird definiert, welche Personen oder Systeme eine Berechtigung für den Zugriff zu bestimmten Informationen besitzen. 106 In einem Geschäftsszenario sind verschiedene Autorisierungsebenen denkbar. So könnte ein 103 Vgl. SoberIT, S Vgl. Brockhaus 2004, S Mehr zu den IETF-Spezifikationen unter Vgl. SoberIT, S

65 4. Grundlagen von RosettaNet Unternehmen A den Lagerbestand eines Unternehmens B erfragen, demgegenüber jedoch keine Berechtigung besitzen, um bei B Verkaufsdaten abzufragen. Die Ebene der Autorisierung ist im RNIF ebenfalls über die Verwendung von digitalen Zertifikaten geregelt. Die Handelspartner einigen sich über die PIPs, mit denen Geschäftsdaten ausgetauscht werden und über den Einsatz digitaler Zertifikate, um die einzelnen Nachrichten einer Transaktion zu signieren. In den Spezifikationen der einzelnen PIPs sind Anweisungen darüber enthalten, ob für diesen PIP eine Autorisierung notwendig ist. Eine Autorisierung erfolgt hierbei in zwei Schritten. In einem ersten Schritt wird der sendende Partner anhand seiner DUNS-Nummer identifiziert und geprüft, ob er die notwendige Autorisierung für die erfragten Informationen besitzt. In einem zweiten Schritt wird das Unternehmen des Senders anhand der digitalen Signatur identifiziert und hinsichtlich seiner Berechtigungen überprüft. Erfolgen beide Schritte mit positivem Ergebnis, wird die Autorisierung erteilt. Nicht-Zurückweisbarkeit Die Nicht-Zurückweisbarkeit ermöglicht, dass der Versand und der Empfang einer Nachricht eindeutig belegbar sind. 107 Für den Sender einer Nachricht ist damit eindeutig feststellbar, ob seine Nachricht angekommen ist. Ebenso kann der Empfänger einer Nachricht belegen, welcher Sender die Nachricht übermittelt hat. RosettaNet spezifiziert wie bereits dargestellt Aktions- und Signalnachrichten. Bei einem Empfang einer RosettaNet-Nachricht wird automatisch ein Signal an dessen Sender ausgelöst, so dass dieser über den Erhalt seiner Nachricht umgehend informiert wird. Auf der Seite des Senders wird die Nicht-Zurückweisbarkeit dadurch sichergestellt, dass seine Aktionsnachrichten mit einer digitalen Signatur versehen sind, welche ihn eindeutig identifiziert. Weiterhin wird im RNIF festgelegt, dass sämtliche Nachrichten für einen vereinbarten Zeitraum gespeichert werden müssen. Hierdurch kann vermieden werden, dass Sender oder Empfänger einer Nachricht den Versand bzw. Empfang zu einem späteren Zeitpunkt zurückweisen können. Integrität Mit der Integrität von Daten wird gewährleistet, dass diese in einer unveränderten Form bei ihrem Empfänger ankommen. 108 Gerade bei einem Datenaustausch ü- ber das Internet ist dies eine komplexe Aufgabe. Bei einem Nachrichtenversand über das HTTP, kann zusätzliche Sicherheit durch den Einsatz von SSL (Secure Sockets Layer) erreicht werden. SSL ist ein Internetprotokoll, welches eine Verschlüsselung während des Datentransports durchführt. Neben dem Einsatz von SSL können auch digitale Signaturen als zusätzliche Verschlüsselungsmechanismen verwendet werden. SMTP besitzt im Gegensatz zu HTTP keinen geeigneten Sicherheitsmechanismus für einen Datentransport. Von RosettaNet wird daher der Einsatz von HTTP in Verbindung mit SSL bei einer Übermittlung sensibler Daten empfohlen. Weiterhin spezifiziert das RNIF, dass beim Empfang einer Nachricht immer eine Signal-Nachricht generiert und anschließend an den Sender übermittelt wird. Ent- 107 Vgl. SoberIT, S Vgl. SoberIT, S

66 4. Grundlagen von RosettaNet stehen Probleme bei der Lesbarkeit einer Nachricht oder scheint diese in ihrem Inhalt verändert worden zu sein, geschieht dies in Form eines Fehler-Signals an den Sender. Auch im Fall einer erfolgreichen Nachrichtenübertragung wird ein Signal ausgelöst, das ReceiptAcknowledgement. Wird in einem vordefinierten Zeitraum nach Versand einer Aktions-Nachricht daher kein Signal erhalten, sieht das RNIF vor, dass der Versand der Nachricht wiederholt wird bis ein entsprechendes Antwortsignal entweder in positiver oder negativer Form eintrifft. Hierdurch soll die Verbreitung fehlerhafter Daten vermieden werden. Zurückverfolgbarkeit Mit einer Zurückverfolgbarkeit wird den Handelspartnern ermöglicht, einzelne Schritte einer Transaktion bis zu ihrem Ursprung zu rekonstruieren. 109 Für einen solchen Vorgang ist die Aufzeichnung jedes einzelnen Schrittes notwendig. Gerade in B2B-Transaktionen ist dieser Aspekt von hoher Bedeutung. Fehlersituationen können schneller gelöst und Problembereiche schneller identifiziert werden. Als Beispiele hierfür seien verloren gegangene Bestellungen oder deren Bestätigungen genannt. Das RNIF ermöglicht eine Nachverfolgung von Transaktionen, in dem jede Nachricht die Zeit ihres Versands beinhaltet. Diese wird im Delivery Header unter MessageTrackingID festgelegt. Die Signal- und Aktions-Nachrichten enthalten damit sämtliche Informationen, die für eine Rückverfolgung der durchgeführten Schritte einer Transaktion notwendig sind. Das RNIF 2.0 und vorhergehende Versionen können über die Website bezogen werden. Sie enthalten neben den Spezifikationen, drei Header (Preamble, Delivery und Service Header) für den Nachrichtenaufbau und zwei Signale (Acknowledgement und Exception) Dictionaries Eine grundlegende Schwierigkeit bei der Automatisierung von Geschäftsprozessen zwischen Handelspartnern liegt in der Verwendung unterschiedlicher Terminologien. Das RosettaNet-Konsortium tritt diesem Problembereich entgegen, indem es ein umfassendes allgemeines Vokabular für die Definition von Prozessen und Dokumenten innerhalb der Supply Chain zur Verfügung stellt. Man unterscheidet hierbei das RosettaNet Business Dictionary und das RosettaNet Technical Dictionary. 110 RosettaNet Business Dictionary (RNBD) In dem RNBD wird die Semantik für eine Vielzahl von grundlegenden Begriffen definiert, welche für den Austausch von Geschäftsinformationen notwendig sind. In den Definitionen enthalten sind z.b. Business Properties (Eigenschaften der Geschäftspartner, wie Adressen), Business Data Entities (Datenobjekte, wie ActionIdentity) und Fundamental Business Data Entities (Datenobjekte, wie BusinessTaxIdentifier oder AccountNumber). 109 Vgl. SoberIT, S Vgl. Rosettanet 2005n 55

67 4. Grundlagen von RosettaNet RosettaNet Technical Dictionary (RNTD) Das RNTD stellt die Objekteigenschaften zur Beschreibung von Produkten, Komponenten, Bauteilen und Dienstleistungen zur Verfügung. Dies wird anhand der Definition einer einheitlichen Semantik der für Produktbeschreibungen und zusätzlichen Informationen notwendigen Daten erreicht. Die früher getrennten Technical Dictionaries für die Bereiche EC und IT, wurden vor einigen Jahren in ein gemeinsames Dictionary, das RNTD, überführt. Die Verwendung eines allgemeinen Vokabulars ermöglicht eine weitgehende Unabhängig von den firmeninternen Systemen. Es werden mit einem PIP lediglich Identifikationsnummern übermittelt, welche auf ein im Dictionary definiertes Produkt zeigen. Die eigene Begriffsverwendung kann daher aufrechterhalten werden, es muss lediglich die Übersetzung zwischen intern und extern verwendeter Terminologie sichergestellt werden. Die Verwendung dieser Identifikationsnummern beinhaltet den weiteren Vorteil einer erhöhten Komprimierung der Nachrichten Product and Partner Codes In den Spezifikationen von RosettaNet sind drei bereits existierende Identifikationssysteme enthalten. 111 Diese sollen zu weiteren Integrationen von Handelspartnern beitragen und eine eindeutige Identifikation von Partnern und Produkten ermöglichen. Global Company Identifier Die von RosettaNet entwickelten PIPs enthalten ein Element zur eindeutigen Identifikation der Handelspartner. Dies wird durch die Integration des Data Universal Numbering Systems (D-U-N-S) ermöglicht. Eine neunstellige Nummer, die von dem Unternehmen Dun and Bradstreet (D&B) vergeben wird, dient einer eindeutigen Identifikation eines Unternehmens. Die neunstellige DUNS-Nummer kann optional um vier weitere Ziffern erweitert werden (DUNS+4), welche dann zusätzlich den Standort eines Unternehmens angibt. Innerhalb eines PIPs werden diese Codes als GlobalBusinessIdentifier und GlobalLocationIdentifier bezeichnet. Global Product Identifier Mit der Verwendung der Global Trade Item Number (GTIN) wird eine eindeutige Identifikation verschiedener Produkte und Dienstleistungen ermöglicht. Diese vierzehnstellige Nummer ist weltweit in vielen Industrie- und Dienstleistungsbereichen anerkannt. Global Class Identifier 111 Vgl. RosettaNet 2005j 56

68 4. Grundlagen von RosettaNet PIPs ermöglichen des Weiteren die Verwendung der United Nations/ Standard Product and Service Codes (UN/SPSC). Dieses hierarchisch gegliederte Codiersystem stellt einen offenen und weltweiten Standard für eine Klassifikation von Produkten und Dienstleistungen zur Verfügung. Innerhalb eines PIPs wird dieser als GlobalProductClassificationCode bezeichnet. Die Verwendung der dargestellten Identifikationssysteme trägt zu einer verlässlichen Kommunikation zwischen den Handelspartnern bei. Die Sicherheit über die Identität des Partners und der zu handelnden Produkte vereinfacht die Durchführung eines automatisierten Datenaustausches Services RosettaNet bietet zusätzlich zu seinen offenen Spezifikationen auch weitergehende Services an. Diese können teilweise nur von Mitgliedern genutzt werden, andere hingegen sind für alle Anwenderunternehmen und Interessenten gleichermaßen zugänglich. Die angebotenen Services, wie die Trading Partner Directory, die Subscriptions and Permissions, das Software Compliance Testing and Certification sowie die Digital Certificates dienen nicht nur der Unterstützung von aktuellen Implementierungen, sondern sind ebenfalls Ausdruck des Engagements der RosettaNet- Initiative in der Förderung weiterer Adaptionen des Standards. 112 Trading Partner Directory Die Trading Partner Directory bietet eine zentrale Zugangsstelle für die Suche und Darstellung von Geschäftsprofilen der RosettaNet-Anwender. 113 Neben Informationen über den Status aktueller PIP-Implementierungen sind hier auch Daten über Schnittstellen für Handelspartner enthalten. Dieser Service ist für alle Unternehmen über die RosettaNet-Website öffentlich zugänglich. Subsciptions and Permissions Mitglieder der RosettaNet-Initiative haben die Möglichkeit, sich auf der Website registrieren zu lassen (Subscription). 114 Sie erhalten dann automatisiert Informationen über Standard-Updates, geänderte und neue Geschäftsprofile sowie Änderungen im Inhalt der Website. Auch einzelne Seiten oder Sektionen der Website können in den Informationsdienst aufgenommen werden. Mitglieder können weiterhin anderen Unternehmen Zugang zu ihren Kommunikationsprofilen einrichten (Permissions). Software Compliance Testing and Certification Dieser Service ermöglicht die Überprüfung von Software-Produkten hinsichtlich ihrer Unterstützung von RosettaNet-Standards. 115 Die Prüfung erfolgt seit Oktober 2004 über ein von RosettaNet gefördertes Tool, dem ebusinessready. Die Nut- 112 Vgl. RosettaNet 2005j 113 Vgl. RosettaNet 2005j, Trading Partner Directory 114 Vgl. RosettaNet 2005j, Subscription and Permission 115 Vgl. RosettaNet 2005j, Software Compliance Testing and Certification 57

69 4. Grundlagen von RosettaNet zung dieses Tools ist für alle Unternehmen gleichermaßen kostenpflichtig. Software-Produkte, die sich als kompatibel erweisen, erhalten eine offizielle Kennzeichnung, das RosettaNetReady - bzw. ebusinessready -Siegel. Im Rosetta- Net Software Compliance Center (einer Seite von rosettanet.org) werden alle Produkte gelistet, die RosettaNet-Standards implementiert haben und mit den veröffentlichten Standards, wie RNIF und/oder speziellen PIPs kompatibel sind. Der Nutzen dieser Prüfung und Zertifizierung liegt in einer Erhöhung der Übersichtlichkeit für Anwenderunternehmen bei der Suche nach Software zur Unterstützung ihrer vorhandenen oder zukünftigen RosettaNet-Implementierung. Digital Certificates Mitgliedern der RosettaNet-Initiative (Partnern und Council-Teilnehmern) wird die Möglichkeit geboten ihre B2B-Kommunikation sicherer zu gestalten. 116 In Zusammenarbeit mit dem Partnerunternehmen Identrus wird Mitgliedern kostenlos ein Server Digital Certificate angeboten. Dieses unterstützt die Verschlüsselung von Daten über SSL, S/MIME oder Digitale Signaturen. Eine Erstlizenz ist hierbei kostenfrei, zusätzliche Lizenzen können zu einem vergünstigten Preis erworben werden. Associate Partner sind von diesem Service jedoch ausgeschlossen. 4.4 Kommunikation Die Grundlagen für ein Verständnis der einzelnen Spezifikationen ermöglicht nun die Betrachtung einer Kommunikation unter Verwendung von RosettaNet. Abbildung 14 zeigt die einzelnen Spezifikationen, PIPs, RNIF und Dictionaries und die Art ihrer Zusammenarbeit für einen Nachrichtenaustausch zwischen zwei Unternehmen. 116 Vgl. RosettaNet 2005j, Digital Certificates 58

70 4. Grundlagen von RosettaNet Abbildung 14: Kommunikation über RosettaNet (Vgl. RosettaNet 2005i, S.2) Auf Basis der Technical und Business Dictionaries, RNIF- und PIP-Spezifikationen erfolgt die Initiierung eines Bestellprozesses durch Unternehmen A. Die erforderlichen Daten werden aus den Back-End-Systemen zusammengestellt und mit Hilfe eines Konverters in eine RosettaNet-Nachricht transformiert. Nachdem die Nachricht anschließend verpackt und signiert wurde, erfolgt die Datenübertragung zum Empfänger, dem Unternehmen B. Eine Kommunikation zwischen Unternehmen, hier A und B, erfolgt zumeist auf Basis des HTTP-Protokolls. Die Systeme der Partner nehmen hierbei die Rollen von Server und Client ein. 117 Der Sender ist hierbei der Client, der Empfänger der Server. Vor dem Aufbau einer Verbindung wird zwischen Client und Server je Sitzung zunächst die in den PIPs enthaltene Session-ID ausgetauscht. Nach Verschlüsselung der MIME-Datei wird diese an den Server gesendet. Dort wird zunächst ihre RosettaNet- Konformität geprüft. Ist sie RosettaNet-konform wird sie an einen Konverter übergeben, welcher die Transformation in das vom Empfänger verwendete Datenformat übernimmt. Verlaufen Überprüfung und Konvertierung erfolgreich wird eine Nachricht (ReceiptAcknowledgement) generiert, die dies dem Sender bestätigt und in einem MIME-Dokument an ihn übermittelt. Verläuft entweder die Prüfung oder Konvertierung nicht erfolgreich, wird eine Nachricht mit der Angabe des fehlerhaften Dokumententeils generiert (ReceiptAcknowledgementException). Diese wird ebenfalls als MIME-Datei an den Sender übermittelt. ReceiptAcknowledgement und auch die ReceiptAcknowledgementException sind eigenständige RosettaNet-Nachrichten (Signale). 118 Sie enthalten Preamble Header, Service Header und auch einen Service Content. 4.5 Klassifikation Die Verwendung von RosettaNet für eine B2B-Integration erfordert auf der Kommunikationsebene den Einsatz gängiger Internet-Transportprotokolle. Das RosettaNet Implementation Framework unterstützt momentan HTTP, SMTP und HTTPS. Eine Ausweitung bezüglich weiterer Protokolle ist geplant. Noch ist jedoch eine Entscheidung für RosettaNet mit einer Bindung an diese Protokolle verbunden. Andere gelten als nicht kompatibel. Geschäftsdokumente werden beim Standard RosettaNet einzelnen Prozessbereichen zugeordnet und innerhalb der ihnen angehörenden PIPs definiert. Mit der Verwendung eines gemeinsamen Vokabulars für die Definition von Geschäftsprozessen wird das Problem heterogener Semantiken adressiert. Dokumente sind bezüglich ihrer Terminologie und Struktur eindeutig vorgegeben. Auf der Datenebene gilt RosettaNet daher als spezieller Standard. Auch die Nachrichtenelemente und strukturen sind durch das RNIF eindeutig vorgegeben. Der Austausch dieser Nachrichten unterliegt hierbei verschiedenen Anforderungen. So wird z.b. die Abfolge von Dokumenten innerhalb eines Geschäftsprozesses anhand von Sequenzdiagrammen modelliert. Die Prozessebene ist demnach ebenfalls als speziell anzusehen. 117 Vgl. Georg 2003, S Vgl. Georg 2003, S.21 59

71 4. Grundlagen von RosettaNet Die RosettaNet-Initiative hat ihren Ursprung in der Informationstechnologie. Es werden jedoch ständig Erweiterungen des Standards vorgenommen, um den Ansprüchen weiterer Industriebereiche zu genügen. Daher wird der RosettaNet-Standard zwar als branchenfokussierend betrachtet, die Integration weiterer Industriebereiche führt ihn jedoch langfristig zu einer branchenübergreifenden Eigenschaft. Daten jeglichen Informationstyps und Prozessbereichs können anhand der Rosetta- Net PIPs abgebildet werden. Es werden die Objektarten Produkt, Partner und Kontrakt sowie sämtliche in den Klassifikationskriterien enthaltenen Prozessbereiche unterstützt. 4.6 Implementierungsprozess Für einen effizienten Einsatz des RosettaNet-Standards, müssen zunächst eine Reihe grundlegender Phasen durchlaufen werden. Diese sind teilweise allgemein auf Systemeinführungen bezogen, anderenteils besonders bei einer Implementierung von RosettaNet zu beachten. Am Anfang jedes Projektes steht die Erstellung eines Pflichtenheftes. Es enthält die aus einer Ist- und Anforderungsanalyse resultierenden Ergebnisse mit Angaben zu Rahmenbedingungen, Anforderungen und Vorgaben für das zu entwickelnde System. Inbegriffen ist eine Auswahl der von RosettaNet entwickelten PIPs, welche zukünftig für eine Transaktion mit einem Handelspartner dienen sollen. Basierend auf den zu verwendenden PIPs müssen die damit zusammenhängenden Geschäftsprozesse neu definiert oder angepasst werden. In einem nächsten Schritt werden die privaten Prozesse innerhalb des Unternehmens identifiziert, die mit den PIPs interagieren müssen. Anschließend wird eine Integration der PIP-Nachrichten in die Back- End-Systeme vorgenommen. Dies ist gleichbedeutend mit einer Entwicklung eines Transaktionsmoduls für eine Übersetzung zwischen dem Datenformat, welches die Back-End-Systeme verwenden und dem RosettaNet-Datenformat. Daraufhin folgt eine Einführungs- und Testphase, in der die Interaktion von privaten und öffentlichen Prozessen mit einem Pilotpartner erprobt wird. Als letzter Schritt ist nach erfolgreicher Einführung eine Schulung der Mitarbeiter und Information der Handelspartner durchzuführen. Studien von RosettaNet über die Einführungen von PIPs haben ergeben, dass 20% des Integrationsaufwandes auf das Design und die Entwicklung einer Interaktion mit privaten Prozessen entfällt % der Aufwendungen geht auf Schulungen der Mitarbeiter und Handelspartner zurück, während der größte Anteil von 50% für technische Implementierungen und Softwareanpassungen aufgewendet werden muss. 4.7 Programme Für eine weitgehende Ausgereiftheit des RosettaNet-Standards spricht dessen steigende Anzahl an Implementierungen. Mehr als einhundert verschiedene PIPs wurden seit der Gründung des Konsortiums entwickelt, um schnell den unterschiedlichen Anforderungen vielfältiger Prozessbereiche gerecht zu werden. Aktuell werden jedoch weniger Anstrengungen in weitere Entwicklungen, als vielmehr in deren produk- 119 Vgl. Demodaran 2004b 60

72 4. Grundlagen von RosettaNet tive Implementierungen gesetzt. RosettaNet besitzt drei verschiedene Gruppen von Programmen zur Förderung des Fortschritts und der Akzeptanz ihres Standards. Milestone, Foundational und Validation Programs. 120 Die erste Gruppe an Programmen sind die Milestone Programs. Sie beinhalten Implementierungsziele für bestimmte Prozessbereiche. Diese gilt es zu erreichen, in dem unterschiedliche Interessen innerhalb eines Industriebereiches zusammengeführt werden und verschiedene Prioritäten zwischen Handelspartnern und Solution Providern vereinheitlicht werden. Die Entwicklungen und Implementierungen von PIPs können daraufhin beschleunigt werden. Die Milestone Programs erfordern die Zustimmung des Executive Committee und der RosettaNet-Mitglieder, welche Ressourcen für das Programm zur Verfügung stellen und sich verpflichten, resultierende Spezifikationen zu implementieren. Die Foundational Programs begleiten die Erst- und Weiterentwicklungen aller RosettaNet-Spezifikationen, wie RNIF, RNTD und RNBD. Dies umfasst die Erweiterungen eines Standards hinsichtlich Funktionalität und Inhalt, Verbesserungen der Architektur und Maßnahmen zur Integration weiterer Standards. Hierzu gehört die Verwendung neuer XML-Technologien für die Definition von Geschäftsdokumenten oder die Umformulierung von Geschäftsprozess-Beschreibungen in ein Computerlesbares Format. Weiterhin zählt zu den Programmen von RosettaNet das Validation Program. Es ist weniger als ein Programm zu sehen, vielmehr als ein formaler Prozess der Rosetta- Net-Initiative, der eine schnelle Implementierung neu publizierter PIPs sicherstellen soll. Dies dient einer hohen Qualität der zur Verfügung gestellten PIPs. Dem Validation Program gehören eine Reihe von Mitgliederunternehmen an, welche sich verpflichten neue PIPs zu implementieren. Sie setzen den PIP für einen bestimmten Zeitraum in ihre Systeme ein und führen dann eine Bewertung bezüglich seiner Bewährung innerhalb realer Szenarien durch. Anhand der Resonanz verschiedener Unternehmen kann beurteilt werden, inwieweit der PIP die vorher definierten Anforderungen erfüllt. Damit ermöglicht dieses Programm eine schnelle Weiterentwicklung des Standards und verringert zukünftige Änderungserfordernisse. Tabelle 6 zeigt eine Übersicht der derzeit aktiven RosettaNet-Programme mit einer kurzen Beschreibung ihres Tätigkeitsfeldes. Name des Programms Beschreibung Dictionary Architecture Erstellung einer skalierbaren Architektur für die RosettaNet Dictionaries Foundational Programs Domain Model RNBD Development RNTD Development Wiederverwendbarkeit von XML- und UML- Objekten Erweiterungen des RNBD für Interaktion mit neuen PIPs Anpassung des Dictionaries an neue Anforderungen 120 Vgl. RosettaNet 2005k 61

73 4. Grundlagen von RosettaNet ecustoms Declaration Engineering Information Management Automatisierung und Standardisierung von Import- /Export-Prozeduren Erstellung eines elektronischen Austauschformates für technische Daten Milestone Programs Validation Program Material Composition Ermöglichen des Austausches von Daten bezüglich Materialzusammensetzungen OMJ - Advanced Förderung der Adaption des Standards im Bereich der Elektronikbauteile-Industrie Payment Entwicklung und Verbesserung von Zahlungsprozessen, z. B. automatisierter Rechnungsbegleichung Product Catalog Information Austausch von Produktdaten RosettaNet Automated Ermöglichung einer RosettaNet-Implementierung Enablement (RAE) für KMU durch skalierbare, flexible Architektur Sales Reporting Entwicklung eines Standardprozesses für die Ü- bermittlung von Verkaufsdaten Semiconductor Test Entwicklung eines Standardprozesses zur Übermittlung von Halbleiterelektronik-Testdaten Data Exchange Service Contract Entwicklung eines Standardprozesses für das Management von Dienstleistungsvertragsdaten Information Management Shipment Booking and Status Shipment Notification Management Warranty PIP-Implementierung Entwicklung einer bidirektionalen Kommunikation zwischen Verschiffung, Logistik und Transport für ausführliche Auftragsinformationen Austausch detaillierter Versandinformationen (Statusinformationen) Automatisierung von Garantieanspruchsprozessen Reihe von Mitgliederunternehmen, welche sich verpflichten, neu publizierte PIPs zu implementieren Tabelle 6: Übersicht aktiver RosettaNet-Programme (Eigene Darstellung) Im Folgenden wird aufgrund aktueller Bedeutung das RosettaNet Automated Enablement (RAE), ein Programm aus dem Bereich der Milestone Programs, eingehender betrachtet RosettaNet Automated Enablement (RAE) Obwohl die zunehmende Bedeutung des RosettaNet-Standards vor allem im Bereich der High-Tech Supply Chain unbestreitbar ist, entscheiden sich kleine und mittlere 62

74 4. Grundlagen von RosettaNet Unternehmen meist gegen eine Integration auf Basis dieses Standards. 121 Grund ist die Komplexität einer RosettaNet-Architektur und die relativ hohen Kosten einer Implementierung. Das Resultat ist, dass nur die größten 10-20% der Lieferanten eines Unternehmens RosettaNet verwenden. Es verbleibt ein Anteil von 80%, welcher größtenteils aus kleinen und mittleren Unternehmen besteht. Ein relativ neues Programm der RosettaNet-Initiative mit dem Namen RosettaNet Automated Enablement (RAE) wurde Ende 2003 gegründet. Das Programm wird von namhaften Unternehmen, wie Hewlett-Packard, Intel, Motorola, Nokia und Texas Instruments unterstützt. Ziel dieses Programmes ist es, eine Integration auf Basis von RosettaNet zwischen Unternehmen mit multinationaler Tätigkeit (MNCs) sowie kleinen und mittleren Unternehmen (KMU) zu ermöglichen. Die Entwicklung einer Lösung für die Integration von KMUs ist in der Bewährungsphase. Bereits im Mai 2005 soll sie schließlich einsetzbar sein und offiziell als Standard publiziert werden. Das RAE stellt eine kostengünstige Alternative zu einer traditionellen B2B-Integration dar. Durch einen geringeren Bedarf an Zeit und an Fachpersonal bei einer Implementierung, wird der Kostenaufwand erheblich gemindert. Technologische Grundanforderungen werden gesenkt. RAE stellt eine Reihe von Spezifikationen zur Erreichung dieses Ziels zur Verfügung. TPIR-PIPs (Trading Partner Implementation Requirements - Partner Interface Processes) ermöglichen Handelspartnern die Verwendung kommerzieller XML- Editing-Tools für eine Anpassung von PIPs. Manuelle Anpassungsprozesse entfallen. Dies wird dadurch erreicht, dass die TPIR-PIP, im Gegensatz zu traditionellen PIPs, in einer Maschinen-lesbaren Form definiert sind. Mit dem TPIR-PF (Trading Partner Implementation Requirements - Presentation Format) wird ein Präsentationsformat (Adobe PDF) für RosettaNet-Daten definiert, dessen Darstellung an Standardformularen ausgerichtet ist. PIPs werden in diesem Szenario nicht mehr zwischen zwei Systemen ausgetauscht, sondern ermöglichen eine Maschine-zu-Mensch-Interaktion. Eine Registry-Spezifikation dient der Definition der Anforderungen für Empfang und Versand von TPIR-PIPs und TPIR-PFs. Diese drei RAE-Spezifikationen ermöglichen es den Handelspartnern eine Rosetta- Net-Transaktion über den Austausch von Adobe PDF-basierten Formularen zu realisieren. Es ist keine vollständige Integration mehr mit Back-End-Systemen notwendig. Unternehmen müssen lediglich ein von Menschen lesbares Formular ausfüllen und versenden. Vorteil hierbei ist die bereits weite Verbreitung von Adobe Reader Produkten. Wie in Abbildung 15 zu sehen ist, läuft eine Kommunikation unter Verwendung von RAE folgendermaßen ab. Der Prozess eines Datenaustausches beginnt zunächst auf der Seite der MNC. Dessen Systeme erstellen unter Verwendung eines RosettaNet- Adapters eine traditionelle RosettaNet-Nachricht. Anhand der RAE-Spezifikationen wird anschließend die Nachricht in ein RAE-konformes TPIR-PF Formular umgewandelt. Dieses wird dann über das RosettaNet Implementation Framework an den zugehörigen Empfänger gesendet, welcher das Formular in seinen Systemen bearbei- 121 Vgl. Scheneker

75 4. Grundlagen von RosettaNet tet, Änderungen an Daten vornimmt oder neue Daten erstellt. Das bearbeitete Formular wird dann zurück an die MNC geschickt. Die Systeme der MNC extrahieren die Daten aus dem Formular und wandeln diese in einen Standard-PIP um, welcher dann zur weiteren Verarbeitung an deren Back-End-Systeme geleitet wird. Abbildung 15: B2B-Integration mit RAE (Ebizq 2005) In technologischer Hinsicht erfordert diese Art der Integration von RosettaNet einen geringeren Aufwand von den Handelspartnern. So ist auch keine klassische Integration mit Back-End-Systemen mehr notwendig. Die Kommunikation erfolgt über den Versand von Formularen. Auf diesem Weg können auch kleine Unternehmen eine RosettaNet-Integration mit ihren Handelspartnern realisieren. Die Anforderungen einer Implementierung verbleiben überwiegend bei dem realisierenden Großunternehmen und dessen Solution Providern. Hierzu gehören z. B. die notwendigen Sicherheitskonzepte, Dateiverzeichnisse, Nachrichtenaufbewahrungen und weiterleitungen, Datentransformation und Test Management, welche eine Erstellung und Verwendung RAE-basierter PIPs ermöglichen. Das RAE-Projekt befindet sich derzeit in der Bewährungsphase, welche von der Intel Corporation geleitet wird. PIPs des Prozessbereichs Auftragsmanagement (z.b. die PIPs 3A4, 3A7, 3B2, 3C3 und 3C4) wurden bereits erfolgreich entsprechend dem neuen Format umdefiniert und werden nun Tests in realen Implementierungsszenarien unterzogen. Ergebnisse dieser Phase werden Ende April 2005 erwartet. 4.8 Weiterentwicklungen Der Standard RosettaNet wird ständigen Analysen unterzogen. Hierdurch können Schwachstellen möglichst schnell ausfindig gemacht und neue Anforderungen erkannt und umgesetzt werden. In diesem Abschnitt sollen einige Ansätze der RosettaNet-Initiative dargestellt werden, die zu einer Verbesserung und einer Erweiterung des Standards beitragen PIPs Aktuell umfasst die Spezifikation von RosettaNet mehr als einhundert verschiedene 64

76 4. Grundlagen von RosettaNet PIPs. Diese werden nicht nur ständig weiterentwickelt, um Anforderungen der Supply Chain und Marktveränderungen gerecht zu werden, sondern es kommen auch neu entwickelte PIPs hinzu. Anfang des Jahres 2004 hat RosettaNet zwei für die High- Tech Branche bedeutsame PIPs entwickelt. 122 Einer davon ist der PIP 2A13, er ermöglicht den Austausch von Daten bezüglich der Materialzusammensetzung von Produkten. Bei Produkten, die aus mehreren Komponenten zusammengesetzt werden und daher eine Vielzahl von Herstellern bei ihrer Produktion beteiligt sind, ist eine Verfolgung der im Endprodukt enthaltenen Materialen oft problembehaftet. Gerade bei risikobehafteten Materialien, wie z.b. Quecksilber darf oft eine Höchstgrenze aufgrund regionaler Bestimmungen nicht überschritten werden. Anhand des PIP 2A13 kann nun über die komplette Supply Chain hinweg der Materialanteil verfolgt werden. Auch der PIP 2A10 wurde um Angaben der Materialzusammensetzung erweitert, um dieses Problem zu adressieren. Dies ist nur ein Beispiel für Weiterentwicklungen des RosettaNet-Standards, eine Vielzahl weiterer PIPs wurden erstellt oder weiterentwickelt Implementierungskosten RosettaNet ist vor allem unter großen Unternehmen weit verbreitet. Die relativ hohen Kosten einer Implementierung dieses Standards haben jedoch bisher kleine und mittlere Unternehmen (KMU) von einer Adaption abgehalten. 124 Gerade bei kleinen Unternehmen ist die Anzahl der Transaktionen, die über RosettaNet durchgeführt werden, relativ gering. Eine Investition ist daher oft nicht gerechtfertigt. Dennoch sehen sich diese Unternehmen oft einem großen Druck durch ihre größeren Handelspartner ausgesetzt, einen B2B-Standard zu implementieren. Dies zeigt eine Studie der Digital Foundry, nach der über 40% aller Unternehmen angaben, einen B2B-Standard auf Wunsch von Kunden oder Partnern implementiert zu haben. 125 RosettaNet hat erkannt, dass vor allem Kosten einen wichtigen Faktor für die weitere Verbreitung ihres Standards darstellen. Im vorigen Abschnitt wurde bereits das RosettaNet Automated Enablement (RAE) vorgestellt, welches KMUs eine Lösung für eine kostengünstige Implementierung bietet. Neben diesem Programm, versucht das Konsortium die mit RosettaNet verbundenen Kosten durch eine Reihe weiterer Maßnahmen zu senken. RosettaNet ermöglicht seit kurzer Zeit neben dem RNIF auch die Verwendung alternativer Spezifikationen für den Transport von PIPs. Hierzu gehört z. B. auch das ebms von ebxml. Weiterhin wird die Erstellung von PIPs erleichtert, in dem weniger Aufwand für deren Erstellung notwendig ist. Aus den definierten UML-Diagrammen kann nun automatisiert ein XML-basierter PIP erstellt werden. Der durch manuelle Prozesse entstehende Ressourcenaufwand und die darin enthaltene Fehlerquelle entfallen. 126 Durch das Technical und das Business Dictionary stellt RosettaNet konsistente Definitionen der in verschiedenen Prozessen gebräuchlichen Begriffe zur Verfügung. Die Benennung, Syntax und Semantik der einzelnen in den Nachrichten enthaltenen E- 122 Vgl. Jorgensen 2004, S Vgl. RosettaNet 2005l 124 Vgl. Damodaran 2004a, S Vgl. Digital Foundry Vgl. Damodaran 2004a, S

77 4. Grundlagen von RosettaNet Elemente werden vereinheitlicht. Für die Entwicklung und Verwendung einheitlicher PIP Nachrichtenstrukturen, hat RosettaNet weiterhin ein Informationsmodell für übergreifende Prozessbereiche erstellt. Diese werden mit den einzelnen PIPs zur Verfügung gestellt. Sie sollen sicherstellen, dass miteinander verbundene PIPs die gleichen Datenstrukturen verwenden. Auch für spezielle Anforderungen an die Ausgestaltung von PIPs, wie besondere Produkteigenschaften, wird eine Lösung angeboten. In manchen Firmen werden Datenelemente benötigt, welche in einem Standard-PIP nicht enthalten sind. Für dieses Problem ist das RosettaNet Appliance Program gegründet worden. Es beschäftigt sich mit der Entwicklung derartiger PIPs und der Sicherstellung einer Kompatibilität mit den Standard-Prozessen Steigerung der Effizienz Wie bereits in Kapitel 3 dargestellt wurde, ist der Standard EDI sehr um die komprimierte Darstellung ihrer Nachrichten bemüht. XML-Nachrichten hingegen sind im Allgemeinen 7 bis 10 Mal umfangreicher als die von EDI. 127 RosettaNet-Nachrichten haben die Eigenschaft sehr groß zu werden, da viele Daten aus vorhergehenden in der aktuellen Nachricht wiederholt werden. Die RosettaNet Integrationsarchitektur spezifiziert jedoch keine Technik, mit der die aus vorhergehenden Nachrichten stammenden Daten innerhalb einer zu versendenden Nachricht identifiziert werden können. Die Handelspartner übermitteln daher wiederholt redundante Daten. Dies erschwert nicht nur den Versand sondern auch die Verarbeitung der Nachrichten. RosettaNet versucht derzeit, mithilfe einer Spezifikation von Komprimierungstechniken, Unternehmen eine Möglichkeit zu bieten, den Umfang ihrer Nachrichten zu verringern. Das grundlegende Problem der Redundanz wird hierdurch jedoch nicht gelöst. Ein weiterer Bereich, dessen Effizienz durch Maßnahmen von RosettaNet gesteigert wurde, liegt in der Koordination mehrerer aufeinander folgender PIPs. 128 Der vollständige Prozess einer Bestellung beginnt mit einer Anfrage für ein Produkt, verläuft über den Versand und endet mit einem Zahlungseingang beim Verkäufer. Innerhalb des Order-to-Cash-Prozesses können eine Vielzahl von PIPs für dessen automatische Realisierung eingesetzt werden. Jeder einzelne spezifiziert die genaue Abfolge ihrer enthaltenen Aktions-Nachrichten. Die genaue Modellierung der Abfolge einzelner PIPs in einem übergreifenden Prozess bleibt bisher jedoch den Geschäftspartnern überlassen. RosettaNet versucht aktuell einen gemeinsamen Kontext für PIPs verwandter Prozessbereiche zu definieren. 4.9 Ausblick Eine vollständige Bewertung und Analyse des Standards RosettaNet erfolgt in Kapitel 8, in welchem die bisher betrachteten Standards einander gegenübergestellt werden und hinsichtlich ihrer Eigenschaften für eine B2B-Implementierung bewertet werden. Dennoch wird im Abschluss dieses Kapitels ein kurzer Einblick in die Zukunftsaussichten von RosettaNet gegeben. 127 Vgl. Damodaran 2004a, S Vgl. Damodaran 2004a, S

78 4. Grundlagen von RosettaNet RosettaNet stellt neben ebxml einen der umfassendsten Standards für die Automatisierung von Geschäftsprozessen dar. Während ebxml jedoch Dokumentenstrukturen und Prozessabläufe nur auf einer generellen Ebene spezifiziert, werden mit RosettaNet detaillierte Vorgaben für deren Ausgestaltung gegeben. In Zukunft wird die unternehmensübergreifende Optimierung von Geschäftsprozessen innerhalb einer Supply Chain an Bedeutung gewinnen. Daher werden gerade RosettaNet und ebxml auch in Zukunft für Unternehmen bedeutsam sein. Ein wichtiger Faktor für die Verbreitung eines Standards ist dessen Initiative. Nicht nur die Weiterentwicklung von Spezifikationen, sondern auch Programme zur Optimierung und Verbreitung eines Standards sind für dessen Akzeptanz von hoher Bedeutung. RosettaNet ist bisher der einzige Standard mit einem eigenen Marketing Komittee und einer aktiven Bemühung um die Akzeptanz der Unternehmen. Die Verbreitung von RosettaNet wird durch Initiativen zur Erschließung weiterer Industriebereiche und eine weltweite Präsenz mithilfe regionaler Außenstellen gefördert. Neben umfangreichen Programmen zur Verbesserung des Standards wird den Unternehmen auch dessen Implementierung wesentlich vereinfacht, indem RosettaNet zunehmend auch andere Standards unterstützt. Als erster Schritt wird beispielsweise der ebxml Messaging Service für einen Versand von PIPs ermöglicht. Bald sollen auch andere Dokumentenstandards innerhalb einer RosettaNet-Nachricht übermittelt werden können. Auch die Unterstützung von Microsoft als Marktführer bei Software- Produkten trägt zu einer weiteren Akzeptanz von RosettaNet bei. Durch eine Integration des RosettaNet-Standards in die BizTalk-Produkte, ist dessen weiterer Bestand aus heutiger Sicht gesichert. 67

79 5. Stärken und Potenzial von RosettaNet 5. Stärken und Potenzial von RosettaNet RosettaNet gehört zu den am weitesten verbreiteten und akzeptierten Standards, die derzeit für eine B2B-Integration zur Verfügung stehen. Die Adaption dieser relativ neu entwickelten Spezifikationen liegt an einer Vielzahl von Gründen. Die Stärken von RosettaNet und die daraus resultierenden Vorteile, die sich für einzelne Unternehmen bei deren Implementierung ergeben können, werden in diesem Abschnitt betrachtet. Neben dem allgemeinen Nutzen einer B2B-Integration mit RosettaNet können sich für ein Anwenderunternehmen spezifische Vorteile in einer Automation je nach Prozessbereich ergeben. Die aktuell bedeutsamen Prozessbereiche Ordering und Invoicing werden daher einer eingehenden Analyse unterzogen. 5.1 Hintergrund und Analyse wesentlicher Stärken Die Besonderheit von RosettaNet gegenüber anderen Standardisierungsbemühungen liegt im Wesentlichen in der permanenten Bemühung und der Initiative des dahinter stehenden Konsortiums. Kein anderer Standard setzt sich in gleichem Maße für eine Etablierung und Verbreitung ihrer Spezifikationen ein. Unternehmen können sich für RosettaNet auf drei verschiedene Arten engagieren, als Council Member, Partner oder Associate Partner. Eine Mitgliedschaft als Council Member verlangt neben der Bereitstellung von finanziellen und personellen Ressourcen als eine aktive Teilnahme bei der Entwicklung, auch das Zugeständnis resultierende Standards innerhalb des eigenen Unternehmens und für eine Kommunikation mit Handelspartnern zu implementieren. Ein Partner bzw. Associate Partner kann hingegen keinen direkten Einfluss auf die Entwicklung ausüben. Die Entwürfe der Spezifikationen stehen ihm jedoch für Testimplementierungen zur Verfügung und resultierende Ergebnisse fließen in weitere Entwicklungen ein. Die Struktur der RosettaNet-Organisation unterscheidet sich wesentlich von denen anderer Standardisierungsbemühungen. 129 Während RosettaNet mehrere Ebenen einer Mitgliedschaft und Teilnahme für die Entwicklung des Standards anbietet, werden bei anderen Organisationen sämtliche Mitglieder mit gleichen Rechten ausgestattet. Bei einer Gleichstellung von Rechten verschiedener Mitglieder können unterschiedliche Aspekte und Interessen in einem Standardisierungsprozess aufeinander treffen, welche es in einem stark verlangsamten Abstimmungsprozess zu vereinheitlichen gilt. 130 Im Gegensatz hierzu, steht hinter der RosettaNet-Organisation die Idee, den Unternehmen je nach Interessenfokus ein bestimmtes Level an Mitspracherechten anzubieten. Ziel ist es, eine maximale Beteiligung derjenigen Unternehmen zu erreichen, für die der zu entwickelnde Standard von hoher Bedeutung ist. Ihnen wird ein maximales Mitbestimmungsrecht bei der Ausgestaltung gegeben. Demgegenüber wird Unternehmen mit geringerer aber dennoch signifikanter Wertschätzung die Möglichkeit einer frühen Implementierung und Bewertung ermöglicht. Die Entwicklung neuer Standards bedarf daher eines kürzeren Zeitraumes, als es bei anderen Organisationsformen möglich ist. Auf neue Marktbedingungen oder Änderungen der Anwenderinteressen kann folglich schneller reagiert werden. Bei RosettaNet sind Council Member im Vergleich zu anderen Mitgliedern an der Entwicklung zukünftiger Spe- 129 Vgl. Xia 2003, S Vgl. Xia 2003, S.4 68

80 5. Stärken und Potenzial von RosettaNet zifikationen offenbar in einem höheren Maß beteiligt. 131 Sie nehmen aktiv an Entwicklungsprogrammen teil und haben damit einen größeren Einfluss auf das Endergebnis. Dieser hochgradig interaktive Standardisierungsprozess, der eine Kommunikation zwischen den Entwickler-Unternehmen (Board Members) und den Anwender- Unternehmen (Board Member, Partner und Associate Partner) erfordert, stellt eine hohe Qualität der resultierenden Standards sicher. RosettaNet wird hierbei von zahlreichen Unternehmen und Organisationen unterstützt. 132 Hierzu zählen neben namhaften Unternehmen, wie IBM, Intel oder HP auch Standardisierungs-Organisationen, wie das Uniform Code Council (UCC) oder die Open Applications Group (OAGI). Diese Mitglieder steuern vom Konzept bis zur Implementierung eines Standards technologische Ressourcen, fachliche Kompetenz, ein ausgereiftes Projektmanagement, Support für Implementierungen und Problemlösungsansätze für deren Umsetzung bei. Die speziell ausgerichtete Struktur von RosettaNet ermöglicht dementsprechend, dass Fachleute hochgradiger Kompetenz aus Unternehmen und Organisationen marktführender Bedeutung zusammen arbeiten, um einen Standard für die IT Branche zu entwickeln. 133 Es entstehen Spezifikationen, die aus speziellen Branchenbedürfnissen heraus für die eigene Branche entwickelt wurden. Spezifische Anforderungen können daher aufgegriffen und umgehend umgesetzt werden. Das Validation Program stellt weiterhin sicher, dass die einzelnen Standards vor ihrer Publikation eingehend geprüft und von Mitgliedern implementiert wurden. Die von RosettaNet bereitgestellten Standards basieren demnach nicht nur auf fundiertem Wissen, sondern weisen auch eine Vielzahl produktiver Implementierungen auf. Unternehmen, die sich für RosettaNet entscheiden, können sich demzufolge auf eine hohe Qualität der Spezifikationen verlassen. Der aufwendige Entwicklungsprozess trägt nicht nur zu einer hohen Qualität des Standards bei, sondern dient auch der Bildung von Vertrauen in RosettaNet. In der Adaption und Verbreitung der Spezifikationen liegt neben der kontinuierlichen Weiterentwicklung des Standards eines der wesentlichen Arbeitsgebiete der RosettaNet- Initiative. Zahlreiche Programme, welche bereits kurz in Kapitel 4 dargestellt wurden, greifen die aus umfassenden Analysen stammenden Anforderungen auf und versuchen diese den Bedürfnissen der Anwender entsprechend umzusetzen. Die Aufgaben der verschiedenen Programme bauen hierbei aufeinander auf. Die Foundational Programs beschäftigen sich mit der Umsetzung von neuen Anforderungen an die Spezifikations-Architektur, das Validation Program stellt die Qualität des Standards durch einen weitreichenden Entwicklungsprozess sicher und die Milestone- Programs dienen letztendlich der Realisierung von Implementierungszielen. Auch die Bereiche Service und Support sind bei RosettaNet umfassend ausgestaltet. Diese Eigenschaft lässt sich derzeit bei kaum einem anderen Standard auffinden. Ausnahme ist BizTalk, welches jedoch ein kommerzielles Produkt darstellt und daher einen regulären Support für Verkaufsprodukte durch das Unternehmen Microsoft aufweist. Doch gerade die Ausgestaltung einer ausführlichen Information der Anwender und einer weitreichenden Unterstützung bei Implementierungen trägt in erheblichem Umfang zur Adaption und Verbreitung eines Standards bei. RosettNet hat diese Notwendigkeit erkannt und stellt einen umfassenden Service und Support für deren Anwenderunternehmen zur Verfügung. 131 Vgl. Xia 2003, S Vgl. RosettaNet 2005a 133 Vgl. RosettaNet 2005a 69

81 5. Stärken und Potenzial von RosettaNet Die Services von RosettaNet wurden bereits in Abschnitt vorgestellt. Für eine zusätzliche Sicherheit beim Versand sensibler Daten wird Mitgliedern ein kostenfreies Digitales Zertifikat zur Verfügung gestellt. Die Subscriptions und Permissions helfen den Anwenderunternehmen und ihnen angeschlossenen Handelspartnern sich laufend über zusätzliche oder weiterentwickelte Standards zu informieren. Das Software Compliance Testing hilft weiterhin den Anwenderunternehmen eine problemorientierte Lösung für ihre Implementierungsvorhaben zu finden. Besonders die Trading Partner Directory birgt jedoch für RosettaNet-Anwender eine Reihe bedeutsamer Nutzenaspekte. 134 Sie stellt Anwendern eine zentrale Zugangsstelle zur Verfügung, mit der den Mitgliederunternehmen und weiteren Anwenderunternehmen auf einfache Weise die Publikation und Suche von Geschäftsprofilen und Implementierungsstati der Handelspartner ermöglicht wird. Auf der Website können sich Unternehmen ein solches Profil einrichten. Die Veröffentlichung erfolgt dann in der Regel innerhalb von zwei bis drei Werktagen. Die Erstellung und Veröffentlichung eines Profils ist mit der Umsetzung bzw. mindestens der Planung einer RosettaNet-Implementierung verbunden. Die Ansicht der veröffentlichten Profile ist hingegen für alle Unternehmen gleichermaßen zugänglich. Mit der Trading Partner Directory kann ein Unternehmen viel Zeit sparen, welche anderenfalls für die Beschaffung von Informationen bezüglich der Identifikation neuer Handelspartner oder zusätzlicher PIPs aufgewendet werden müsste. Die Directory enthält ebenfalls wertvolle Informationen für geschäftsrelevante Entscheidungen. Hierzu gehört die Auswahl von Handelspartnern für neue Projekte oder die Eingrenzung, welche PIPs mit welchem Partner implementiert werden können. Eine Registrierung in der Directory birgt weiterhin den Vorteil einer offenen Kommunikation mit anderen RosettaNet-Anwendern. Hierdurch entsteht eine Transparenz über die Bedürfnisse und Anforderungen der verschiedenen Unternehmen und so kann die Weiterentwicklung des Standards sowie des Service-Bereichs in eine für die Unternehmen wertvolle Richtung gefördert werden. Die Veröffentlichung eines Profils ermöglicht es den Handelspartnern eines Unternehmens auch laufend über Änderungen informiert zu werden. Dies geschieht über den Versand automatischer Benachrichtigungen bei einer Änderung des Profils oder des Status. Auch kann die Directory dazu dienen, das eigene Unternehmen gegenüber der Konkurrenz hervorzuheben. Eine weltweite Verfügbarkeit des Profils und der Informationen über geplante oder bereits realisierte Implementierungen für Anwender und Solution Provider steigert die Bekanntheit und den Fortschritt eines Unternehmens. Der Support umfasst umfangreiche Sammlungen von Implementierungsleitfäden für PIP-Einführungen. Anwenderunternehmen und Entwickler stellen hierbei aus ihren Implementierungserfahrungen resultierende Ergebnisse als unterstützende Materialien zur Verfügung. 135 Ein solcher Leitfaden ist derzeit für die meisten PIPs bereits erhältlich. Zusätzlich werden Mitgliederunternehmen für eine Unterstützung von Implementierungsvorhaben personelle und fachliche Ressourcen zur Verfügung gestellt. In Amerika und Europa wurden bereits User Groups gebildet, welche wöchentliche Treffen anbieten, bei denen Umsetzungsstrategien und Implementierungsschwierigkeiten gemeinsam diskutiert und gelöst werden können. 136 An einer B2B-Integration interessierte Unternehmen sind primär darum bemüht, einen Standard auszuwählen, der ihre Anforderungen bestmöglich umsetzt. Weiterhin 134 Vgl. RosettaNet 2005o 135 Vgl. RosettaNet 2005r 136 Vgl. RosettaNet 2005s 70

82 5. Stärken und Potenzial von RosettaNet sind anfallende Kosten und der aus einer Umsetzung resultierende Nutzen wichtige Entscheidungsaspekte. Diese sind bei einer Implementierung nicht nur von den vorhandenen technischen und personellen Ressourcen abhängig, sondern auch von den zu automatisierenden Prozessen, welche je nach Unternehmen unterschiedlich ausgestaltet sein können. Die hierbei anfallenden Implementierungskosten sind durch verschiedenartige Rahmenbedingungen oft nur sehr schwer einzuschätzen. RosettaNet stellt auf ihrer Website eine Reihe von Case Studies der Mitgliederunternehmen zur Verfügung, die eine erste Einschätzung der für eine Einführung von RosettaNet erforderlichen Ressourcen und resultierenden Nutzen ermöglicht. Neben diesen Einblicken in reale Implementierungen ermöglicht RosettaNet auch eine Einschätzung der im eigenen Unternehmen anfallenden Kosten und Nutzen. Hierzu hat RosettaNet in Zusammenarbeit mit der Stanford Universität einen Rechner für die Kosten einer PIP-Implementierung und einen weiteren Rechner für die Schätzung des daraus resultierenden Nutzens entwickelt. Diese beiden Rechner werden ebenfalls über die Website bereitgestellt. 137 Momentan sind diese für die gebräuchlichsten Prozessbereiche Lagerverwaltung (Cluster 4) und Auftragsmanagement (Cluster3) verfügbar. Der Rechner besteht in beiden Fällen aus einer Excel-Datei, welche sechs bzw. neun verschiedene Arbeitsblätter beinhaltet. 138 Diese müssen teilweise von dem Anwender mit Daten des Unternehmens ausgefüllt werden. Hierzu gehören Angaben grundlegender Daten des Unternehmens, eine Aufstellung der Kosten bei einer Implementierung von RosettaNet und eine Einschätzung der Kostenersparnisse bei vollständiger Automatisierung der Prozessabläufe. Anhand dieser Angaben erfolgt die Kalkulation notwendiger Investitionen und des resultierenden Nutzens, sowie auf den jeweiligen Zusammenfassungsblättern eine Gegenüberstellung der Kosten und Nutzen im Vergleich mit und ohne RosettaNet. Diese Nutzen- und Kosten-Rechner helfen den Unternehmen eine realistische Einschätzung der Input- und Output- Faktoren einer RosettaNet-Implementierung zu entwickeln. In Case Studies wurden mithilfe dieser Rechner bereits einige aussagekräftige Ergebnisse erzielt. So konnten für Einsatz von RosettaNet in dem Bereich des Auftragsmanagements zwischen den Unternehmen Nabisco Inc. und Wegmans Food eine Steigerung der Verkäufe um bis zu 12% ermittelt werden. Der benötigte Zeitraum für eine Inventur ging um durchschnittlich 2,5 Tage zurück. 139 RosettaNet setzt sich weiterhin für eine Konvergenz der verschiedenen Standards ein. Diese erhöht nicht nur die Interoperabilität zwischen den Supply Chains eines Industriebereichs, sondern ermöglicht RosettaNet ebenfalls die Konzentration auf den wesentlichen Aspekt ihrer Standardisierung, die Automation von Prozessabläufen. RosettaNet arbeitet bereits mit UCC und OAGI eng zusammen. Das Konsortium wird auch weiterhin die Zusammenarbeit mit etablierten Standardisierungsorganisationen fördern und versuchen, den eigenen Standard mit bereits eingesetzten oder entwickelten Standards in seiner Funktion zu erweitern. Beispiele hierfür sind die unterstützten Komponenten einer Transportinfrastruktur wie HTTP, MIME oder das vom W3C entwickelte XML Schema. Weiterhin gehört die Unterstützung des ebms für einen Transort von PIPs in diesen Bereich. Die Anwenderunternehmen profitieren hierbei durch eine erhöhte Flexibilität bei der Auswahl einzelner Standardkomponenten und einer größeren Kompatibilität von RosettaNet mit anderen B2B-Standards. Diese Initiative von RosettaNet, eine Konvergenz zwischen Standards zu erreichen, 137 Vgl. RosettaNet 2004p 138 Vgl. RosettaNet 2005t, S.9ff 139 Vgl. RosettaNet 2005t, S.18 71

83 5. Stärken und Potenzial von RosettaNet wird langfristig auch zu einer Senkung der Implementierungskosten einer B2B- Integration führen. Gerade hohe Implementierungskosten haben in den letzten Jahren die Adaption von RosettaNet eingeschränkt. Für eine Implementierung von RosettaNet sind neben Personal auch die notwendige Software und Hardware für die Gestaltung der Systemarchitektur, Analysen der Prozessabläufe, Prozess- sowie Projektmanagement, Entwicklungen, Netzwerkarchitekturen, Testmanagement und -durchführungen notwendig. 140 So hat zu Anfang die Implementierung eines PIP um die $ an Kosten verursacht. Gerade kleine und mittlere Unternehmen sehen eine derartige Investition oft nicht gerechtfertigt. Das RosettaNet-Konsortium hat seitdem große Anstrengungen unternommen, um diese Kosten auf ein Level zu senken, welches auch KMUs die Möglichkeit einer Integration über RosettaNet bietet. Nach Angaben von Jennifer Hamilton, Präsidentin des Konsortiums, ist das langfristige Ziel für Implementierungen eine Senkung auf Dollar. 141 Abbildung 16 zeigt den Verlauf der Kosten für eine PIP-Verbindung seit dem Jahr der ersten Veröffentlichungen von RosettaNet. Anfänglich hohe Implementationskosten pro Verbindung sinken als RosettaNet Unternehmenslizenzen für mehrfache Verbindungen abschafft und aus frühen Fehlern gelernt wurde. Durchschnittl. Kosten einer PIP-Verbindung $ $ $ $1.000 EDI: $ für eine Transaktion Die Implementationskosten sanken auch bis zum Jahr 2002 weiter kontinuierlich. Die Kurve wird in diesem Zeitraum jedoch allmählich flacher aufgrund notwendiger Back-End Integrationen neuer PIPs. Implementationskosten liegen aktuell je nach Prozessbereich und Unternehmensvoraussetzung zwischen $ pro PIP RosettaNet Automated Enablement (RAE) soll eine Implementation für $500 für einen einfachen PIP und $1.000 für einen komplexen PIP bis zum zweiten Quartal 2005 ermöglichen. Auch bei Erst-Implementationen Abbildung 16: Kostenverlauf für eine PIP-Implementierung (Vgl. IBM 2004a) Durch verschiedene Maßnahmen (siehe Abschnitt 4.8.2) und Programme (siehe Ab- 140 Vgl. Harvard 2004, S Vgl. Jorgensen 2004, S.37 72

84 5. Stärken und Potenzial von RosettaNet schnitt 4.7.1) konnten die Kosten einer regulären Implementierung für ein Unternehmen auf Dollar gesenkt werden, bei Verwendung der RAE- Spezifikationen sogar auf 500 Dollar pro eingesetztem PIP. RosettaNet nähert sich damit den vergleichsweise niedrigen Kosten einer EDI-Transaktion stetig an. RosettaNet bemüht sich wie in diesem Abschnitt dargestellt wurde, neben der Optimierung ihres Standards vor allem auch um dessen Verbreitung und Akzeptanz. Das Ergebnis ist ein offener, sicherer und qualitativ hochwertiger B2B-Standard, der nicht nur reale Implementierungen aufweisen kann, sondern sich auch intensiv um die Unterstützung der Anwenderunternehmen bei Implementierungsvorhaben kümmert. Hierin liegen die wesentlichen Stärken und das herausragende Potenzial von RosettaNet. Die aus einer Implementierung betriebswirtschaftlich resultierenden und messbaren Nutzenaspekte werden anschließend in Abschnitt 5.2 dargestellt. 5.2 Nutzen für Anwenderunternehmen Anwender des RosettaNet-Standards profitieren von einer umfassenden Ausgestaltung. Mit einer Fokussierung auf den am häufigsten automatisierten Prozessbereich einer B2B-Integration, dem Auftragsmanagement, werden auch eine Vielzahl weiterer Bereiche mit PIPs spezifiziert. Alle erdenklichen Abläufe, darunter auch Garantieleistungen, Rücksendungen oder Materialzusammensetzungen, können derzeit mit RosettaNet automatisiert werden. Allein der Prozessbereich Bestellmanagement umfasst hierbei über 50 verschiedene PIPs. Von Vorteil für ein Unternehmen ist nicht nur die detaillierte Ausgestaltung eines Prozessbereichs, sondern auch die global konsistente Formulierung sämtlicher Spezifikationen. Weder Subsets noch Variationen behindern eine industrie- und länderübergreifende Integration zwischen Unternehmen. Die Ausrichtung von RosettaNet auf die Industriebereiche Informationstechnologie, Elektronikbauteile, Halbleiterproduktion, Telekommunikation, Solution Provider und Logistik ermöglicht auch die Ausgestaltung spezifischer Anforderungen einzelner Branchen. Durch ständige Weiterentwicklungen und eine zunehmende Verbreitung des Standards ist dessen weitere Existenz und Bedeutsamkeit für B2B-Integrationen gesichert. Abbildung 17 zeigt die Entwicklung der RosettaNet-Spezifikationen hinsichtlich des Wachstums in Funktionalität und Netzwerkgröße. 73

85 5. Stärken und Potenzial von RosettaNet Tiefe der Funktionalitäten Zusammenarbeit (Vorhersagen, Design) Transparenz (Supply Chain, Anfragestatus) Transaktion (Direktes und indirektes Beschaffungswesen) Basis ( , Papierdokumente, Web) Die B2B-Funktionaliäten werden erweitert: Geschäftsprozessbasierte Standards mit sorgfältig abgestimmtem Transaktionsablauf Reaktionen in Echtzeit Anregung, Prozesse im Unternehmen und auch übergreifend zu optimieren Unterstützung einer Zusammenarbeit Das Netzwerk von RosettaNet vergößert sich stetig: Implementationsleitfäden Trading Partner Directory Sinkende Implementationskosten Demnächst: RosettaNet Automated Enablement Netzwerkgröße (Anzahl Partner) Abbildung 17: Entwicklung von RosettaNet in Größe und Funktion (Vgl. IBM 2004a) RosettaNet ist bestrebt, die Funktionalitäten des Standards ständig den Erfordernissen der einzelnen Branchen anzupassen. Hierdurch wurden Spezifikationen entwikkelt, die über eine grundlegende Automation hinausgehen und manuelle Bearbeitungen weitestgehend reduzieren. Es können mithilfe von PIPs Transaktionen mit Handelspartnern durchgeführt werden und es kann eine erhöhte Transparenz zwischenbetrieblicher Abläufe realisiert werden. Die Unternehmen können ebenfalls übergreifende Nachfragevorhersagen und ein gemeinsames Produktdesign mit dem Einsatz von RosettaNet umsetzen. Die Weiterentwicklungen wurden bereits eingehend in dieser Arbeit dargestellt. Sie sind die Ursache für eine weitgehende Akzeptanz von RosettaNet. Detaillierte Angaben zu dem Grad der Verbreitung werden schließlich in Kapitel 7 gegeben. RosettaNet beinhaltet eine Reihe von Nutzenaspekten für dessen Anwender. Diese sind teilweise bereits durch eine Automation von B2B-Prozessen gegeben, anderenteils jedoch speziell in der Verwendung von RosettaNet begründet. RosettaNet ermöglicht den Unternehmen dem erhöhten Wettbewerb einer zunehmenden Globalisierung und Automation standzuhalten. 142 Es stellt eine Infrastruktur zur Verfügung, welche bewährte Spezifikationen und Implementierungshilfen umfasst und dementsprechend auch Integrationen von Geschäftsprozessen mit Handelspartnern über Ländergrenzen hinaus ermöglicht. Ebenfalls bietet es ein dynamisch ge- 142 Vgl. RosettaNet 2005q 74

86 5. Stärken und Potenzial von RosettaNet staltetes Netzwerk, welches eine schnelle Integration mit Handelspartnern ermöglicht und damit Geschäftsbeziehungen durch eine intensivere Zusammenarbeit, gemeinsame Informationsverwendung und Kommunikation enger gestaltet. Eine Implementierung von RosettaNet betrifft auch die Operationseffizienz eines Unternehmens, welche durch dessen Einsatz erheblich gesteigert werden kann. 143 Der Einsatz von PIPs ermöglicht es den Anwendern, ihre internen Prozessabläufe zu a- nalysieren und Schwachstellen aufzudecken. Die Automation zwischenbetrieblicher Prozesse hilft ferner, die Transparenz komplexer Abläufe zu erhöhen und Geschäftsabläufe dementsprechend über die gesamte Supply Chain hinweg zu optimieren. Eine Standardisierung erlaubt es auch, einzeln ausgestaltete Prozesse mit anderen Handelspartnern weiterzuverwenden. Durch eine global konsistente und standardisierte Gestaltung der RosettaNet-Spezifikationen können Implementierungskosten bei Anschluss weiterer Partner beträchtlich gesenkt werden. Nach Studien der Yankee Group verringern sich diese Kosten bei Integration weiterer Handelspartner von ursprünglich Dollar bei einer Erst-Integration um mehr als 90%. 144 Wurde eine Integration mit einem Handelspartner bereits durchgeführt, verringern sich die Anschlusskosten weiterer Partner damit erheblich. Einem Anwenderunternehmen bieten sich weiterhin verbesserte Geschäftsmöglichkeiten. 145 Diese liegen vor allem in der Zunahme geschäftlicher Aktivitäten, welche durch die zunehmende Vergrößerung des RosettaNet-Netzwerks ermöglicht wird. Veröffentlichte Profile und Projekte sind weltweit einsehbar und fördern dementsprechend die Entstehung neuer Geschäftskontakte. Auch werden bestehende Geschäftsbeziehungen intensiviert, da eine gemeinsame Prozessverwendung und die daraus resultierende Effizienz die Grundlage für eine Ausweitung auf weitere Produktebereiche beinhaltet. Die Automation zwischenbetrieblicher Abläufe ermöglicht weiterhin die Optimierung der hiermit verbundenen Prozesse. Zum einen kann der Lebenszyklus eines Produktes vom Design bis zur Auslieferung effizienter gestaltet werden, da nun dessen Herstellungsprozess über mehrere Unternehmen hinweg analysiert werden kann. Andererseits können Reaktionszeiten deutlich gesenkt und Auslieferungsintervalle deutlich verringert werden. Die Kundenzufriedenheit wird hierbei erheblich gesteigert. Manuelle Eingriffe entfallen weitestgehend und eine Transaktion kann schneller bearbeitet werden. Auch können die Kosten, die für eine Transaktion anfallen, deutlich gesenkt werden. Geringere Fehlerquellen durch die Automation und ein minimierter Personaleinsatz führen hierbei zu einer Kostenersparnis. Die erhöhte Transparenz ermöglicht ebenfalls eine effizientere Planung des Materialbedarfs, wodurch ein minimierter Lagerbestand und eine geringere Kapitalbindung realisiert werden können. Einer der wichtigsten Vorteile der Verwendung von RosettaNet gegenüber anderen Standards ist jedoch der Schutz der getätigten Investitionen. Während eine Vielzahl der derzeit verfügbaren B2B-Standards weder produktive Implementierungen noch eine andere Form der Bewährung oder Sicherung ihres Fortbestehens aufweisen, ist der weitere Bestand von RosettaNet durch namhafte Mitglieder, geprüfte Implementierungen und ausgereifte Spezifikationen weitestgehend gesichert. Das Uniform Co- 143 Vgl. RosettaNet 2005q 144 Vgl. Yankee Group 2004a, S Vgl. RosettaNet 2004q 75

87 5. Stärken und Potenzial von RosettaNet de Council, eines der am meisten respektierten Entwickler weltweiter Standards, steht ebenfalls hinter dem weiteren Bestand und einer zunehmenden Verbreitung von RosettaNet. Weitere Vorteile von RosettaNet liegen in dessen technologischer Gestaltung begründet. Hierzu gehört die Möglichkeit, Transaktionen in Echtzeit durchführen zu können, eine closed-loop -Architektur, welche das Verschwinden von Nachrichten verhindert, ein ausgereiftes Fehlermanagement und die Kompatibilität mit einer Reihe ebenfalls bedeutsamer Standards. Eine eingehendere Betrachtung der relativen technischen Stärken im Vergleich zu den in Kapitel 3 vorgestellten Standards und eine Bewertung hinsichtlich vorher definierter Kriterien erfolgt in Kapitel 8. In den nächsten beiden Abschnitten erfolgt zunächst eine Darstellung des mit einer Automation der Prozessbereiche Auftragsmanagement (Ordering) und Rechnungserstellung (Invoicing) realisierbaren Nutzens für ein Anwenderunternehmen Ordering Das Auftragsmanagement ist eines der am detailliertesten ausgestalteten Prozessbereiche mit mehr als 50 verschiedenen Partner Interface Processes in vier verschiedenen Segmenten. Diese umfassen die Produktkonfiguration, Mengenanfragen und Bestellungen, Transport und Rücklieferung sowie die finanzielle Abwicklung eines Auftrages. Die Verwendung von RosettaNet beinhaltet für den Ordering-Bereich zwei verschiedene Arten von Nutzenaspekten für ein Unternehmen. 146 Einerseits profitiert ein Unternehmen von Aspekten, die allgemein aus der Automatisierung eines Prozesses resultieren. Auf der anderen Seite existieren viele Vorteile speziell durch die Implementierung der RosettaNet-Spezifikationen. Auf beide Kategorien wird kurz nacheinander eingegangen. Die folgenden Verbesserungen können bei einer Automatisierung von Prozessen im Bereich des Ordering realisiert werden: Geringerer Personaleinsatz Die traditionelle Ausgestaltung des Auftragsmanagements benötigt eine Vielzahl von personalintensiven Prozessen. Allein für die Annahme von Bestellungen (über Telefon, Fax oder ), die manuelle Überprüfung der Kreditwürdigkeit oder ähnliche Sicherheitsmaßnahmen, sowie die Übertragung der Auftragsdaten in ein Back-End-System sind eine Menge von Kundenbetreuern notwendig. Der manuelle Prozess wird vom Planungs- und Produktionspersonal fortgeführt, welches Daten in die jeweils verwendeten Systeme eingibt und wiederum Bestellungen an Lieferanten formuliert. Eine Automatisierung dieser Prozesse verringert die menschliche Intervention und damit die Anzahl an notwendigem Personal für die Durchführung hiermit verbundener Aktivitäten. 146 Vgl. RosettaNet 2005t, S.11ff 76

88 5. Stärken und Potenzial von RosettaNet Reduzierte Transaktionskosten Zusätzlich zu einem geringeren Personalbedarf, werden durch eine Automation unter Verwendung des Internets die Kommunikationskosten stark gesenkt. Kosten für Telefon, Fax und EDI sinken und damit auch die gesamten Transaktionskosten. Verringerung der Fehleranfälligkeit Die meisten Fehler entstehen durch einen menschlichen Eingriff. Manuelle Prozesse mit einer Vielzahl menschlicher Interventionspunkte, wie die Eingabe von Daten in Back-End-Systeme oder Fax-Übertragungen sind meist mit mehr Fehlern versehen als es bei einer Automatisierung der Fall ist. Reduktion des Zeitaufwandes Manuelle Prozesse sind nicht nur anfälliger für Fehler, sondern sie erfordern auch mehr Zeit im Vergleich zu einer Automatisierung. Es wird Zeit für den Empfang und die Bearbeitung einer Anfrage benötigt, für das Senden einer Anfragebestätigung und einer Initiierung interner Prozesse, die mit der Bestellung ausgelöst werden müssen. Die Zeit für eine vollständige Bearbeitung einer Bestellung kann deutlich gesenkt werden. Unternehmen haben hierdurch die Möglichkeit, die Kundenzufriedenheit durch verkürzte Reaktionszeiten zu steigern. Hiermit verbunden sind auch verkürzte Zeiten für Auftragsabwicklungen, welches zu einer schnelleren Realisierung von Umsätzen führt. Verringerte Lagerbestände und Lagerhaltungskosten Lagerbestände werden meist an der benötigten Zeit für eine Auftragsbearbeitung und anschließende Lieferung ausgerichtet: Lange Bearbeitungszeiten erfordern im Allgemeinen einen höheren Reservebestand. Eine Automation des Auftragsmanagements, welches ebenso Lieferanten befähigt schneller auf Bestellungen zu reagieren, führt zu verringerten Bearbeitungszeiten und einer schnelleren Beschaffung des erforderlichen Materials. Hierdurch ist letztendlich ein geringerer Lagerbestand notwendig. Auch die mit der Haltung eines hohen Lagerbestands verbundenen Kosten können damit verringert werden. Transportoptimierung Eine erhöhte Transparenz der Versandpläne verschiedener Kunden, erlaubt es den Logistikanbietern ihre Lieferungen zu verbessern. Sie können einzelne Lieferungen besser aufeinander abstimmen oder Lieferungen an verschiedene Kunden miteinander kombinieren. Die Lasten eines Transports und die erforderlichen Routen können dementsprechend optimiert werden. Geringere Lieferkosten Aufgrund einer Optimierung der Abläufe eines Logistikanbieters, kann dieser seine Transportkosten deutlich senken. Ein Teil dieser Kostenersparnis wird meistens in Form geringerer Lieferkosten an deren Kunden weitergegeben. 77

89 5. Stärken und Potenzial von RosettaNet Schnellere Reaktion auf Änderungen und Probleme Die automatische Benachrichtigung bei Änderungen und Problemzuständen, ermöglicht es den Logistikanbietern schneller an ihren Lieferplänen Modifikationen durchzuführen und damit Verzögerungen zu verhindern. Erhöhte Liefereffizienz Mit genaueren Angaben der Transportunternehmen bezüglich der Lieferzeiten kann der Versand und Empfang von Gütern zwischen Unternehmen effizienter gestaltet werden. Erforderliche Ressourcen für Be- und Entladung, wie Maschinen und Personal, können zeitgenau nach den Angaben der Transportunternehmen geplant werden. RosettaNet bietet auch Vorteile, die nicht auf eine Automation von Prozessen zurückzuführen sind. Hierzu gehören im Bereich des Ordering vor allem zwei Aspekte. Skalierbarkeit Der Standard Rosettanet ist im Gegensatz zu anderen Ansätzen skalierbar. Mit einer Standardisierung können die Erfahrungen einer ersten Implementierung mit einem Handelspartner auf weitere Handelspartner übertragen werden. Ein bereits integrierter PIP kann für weitere Integrationen verwendet werden. Hierbei ermöglicht RosettaNet nicht nur einen schnelleren, sondern auch kostengünstigeren Zusammenschluss mit weiteren Handelspartnern. Geringere Lieferantenpreise Die Ausgestaltung eines Angebots als Reaktion auf eine Ausschreibung erfordert die Investition wertvoller Zeit. Lieferanten werden auf eine Ausschreibung nicht reagieren, wenn die Chance auf den Auftrag nicht in einem angemessenen Verhältnis zu den erforderlichen Aufwänden steht. Werden Angebote hingegen in einem Standardformat erstellt und übermittelt reduziert sich der Aufwand für den Anbieter erheblich. Mehr Unternehmen werden auf eine Ausschreibung reagieren und der Käufer hat eine größere Auswahl an Angeboten. Durch die Konkurrenzsituation der Anbieter sind damit auch regelmäßig Kostenersparnisse beim Kauf eines Produktes realisierbar. Eine Automatisierung von Geschäftsprozessen durch den Einsatz von RosettaNet ermöglicht gerade im komplexen Bereich des Auftragsmanagements die Umsetzung zahlreicher Vorteile. Diese müssen von den einzelnen Anwendern für eine effizientere Gestaltung der Supply Chain jedoch zunächst erkannt und anschließend umgesetzt werden. 78

90 5. Stärken und Potenzial von RosettaNet Invoicing Die Bearbeitung eingehender Rechnungen ist ein aufwendiger und besonders fehleranfälliger Prozess. Studien zur Ermittlung der Kosten für die Bearbeitung ausgehender und eingehender Rechnungen ergaben eine Kostenspanne von Dollar pro Rechnung. Auf einen Verkaufsumsatz von etwa 1 Milliarde Dollar entfallen damit allein über 27 Millionen Dollar auf die Durchführung von Zahlungsprozessen. 147 Zu einem Zahlungsprozess gehört die manuelle Erstellung und der Versand von Rechnungen sowie möglicher Zahlungserinnerungen, die Zahlungseingangsidentifizierung und der anschließende Ausgleich eingehender Forderungen, die Initiierung ausstehender Verbindlichkeiten, Rechnungsbestätigungen oder änderungen sowie letztendlich auch die Kommunikation mit den Kunden. Eingehende Geldmittel stehen im Normalfall am Tag des Eingangs bei der Hausbank für weitere Transaktionen zur Verfügung. Der Tag des Eingangs ist jedoch meistens nicht genau vorhersehbar, zu viele Prozesse liegen zwischen der Zahlungsanweisung des Kunden und dem Eingang des Geldes beim Verkäufer. Die Effizienz eines Zahlungsprozesses kann für die beteiligten Unternehmen erheblich durch eine Vergrößerung der Transparenz der Abläufe und einem verlässlichen Zeitpunkt für den Zahlungseingang gesteigert werden. Von der Initiierung einer Zahlung eines Kunden an dessen Bank können bis zum Zahlungseingang bei dem Verkäufer bis zu 7 Tage vergehen. Dies kann im Verkäuferunternehmen in einigen Fällen zu einer erneuten Überprüfung des Kreditlinie eines Kunden führen und möglicherweise anschließende Lieferungen an diesen verzögern. Vor allem aber kleine Unternehmen können von einer Automatisierung und der daraus resultierenden verbesserten Informationsverfügbarkeit profitieren. Kleinen Unternehmen werden im Vergleich zu ihren größeren Handelspartnern meist weniger günstige Bankgebühren und zusätzliche Services angeboten. 148 Eine Automation hilft ihnen ebenfalls Kostenersparnisse zu realisieren und anhand zusätzlicher Informationen Vorteile in der Ausgestaltung der Abläufe zu erzielen. Das Verständnis der einzelnen Vorteile einer Automation von Zahlungsprozessen erfordert zunächst das grundlegende Verständnis eines Ablaufs einer Transaktion mit RosettaNet. Dieser Vorgang wird in Abbildung 18 dargestellt. 147 Vgl. RosettaNet 2005u 148 Vgl. RosettaNet 2005v 79

91 5. Stärken und Potenzial von RosettaNet VENDOR VENDOR BANK CUSTOMER CUSTOMER BANK Product is shipped (Goods Issued) triggers a billing document to the billings due list Invoice is generated 3C3 Invoice Customer accepts the invoice into their ERP system as is. Vendor receives payment advice into ERP system 3C6 Payment Advice Customer sends Payment Advice and informs bank to transfer funds to Vendor Bank transfers funds to Vendor Bank If the funds = the invoice: cash is applied to the account and the document is closed. Vendor Bank receives funds and notifies Vendor of payment End Abbildung 18: Zahlungsprozess mit RosettaNet (RosettaNet 2005v) Mit der Lieferung eines Produktes wird ein Rechnungsdokument automatisch erstellt und über den PIP 3C3 an den Kunden übermittelt. Der Kunde kann über diesen PIP daraufhin eine Bestätigung oder auch einen Makel für die eingegangene Rechnung erstellen. Wird die Rechnung akzeptiert übernimmt der Kunde die Daten aus der Rechnung in sein Back-End-System. Über den PIP 3C6 wird eine Zahlungsanweisung an seine Hausbank initiiert. Gleichzeitig wird ein Beleg dieser Anweisung an den Verkäufer versandt. Die Bank des Käufers nimmt die Gutschrift des Kaufbetrages bei der Bank des Verkäufers vor. Mit der Gutschrift auf dessen Konto erhält der Verkäufer eine Nachricht, welche neben den Überweisungsdetails auch eine Bestätigung über den Eingang der Geldmittel enthält. Anhand der in dieser Nachricht enthaltenen Daten kann anschließend der Ausgleich der ausstehenden Forderung an den Kunden automatisch gebucht werden. Die Besonderheit bei der Durchführung dieses Zahlungsprozesses ist die frühe Sichtbarkeit eingehender Geldmittel noch vor der tatsächlichen Gutschrift. Unternehmen haben hierdurch die Möglichkeit ihre Geschäfte tagesaktuell zu planen und Kundenzahlungen genau zu verfolgen. Einige Finanzdienstleister und Banken bieten den zusätzlichen Service an, die in einem Prozess ausgelösten Zahlungen, auch innerhalb ihrer Finanznetzwerke weiter zu verfolgen. 149 RosettaNet hat eine Reihe verschiedener Programme zur Optimierung einzelner Zahlungsprozesse. Das bereits abgeschlossene Global Billing Milestone Program hatte die Zielsetzung, die Fähigkeiten des PIP 3C3 zu erweitern, um dessen Einsatz für das e-invoicing sicherer und effizienter zu gestalten. Rechtliche Anforderungen und Besteuerungsregeln wurden in den bestehenden PIP integriert, um speziellen Anforderungen verschiedener Regionen und Länder zu genügen. 149 Vgl. RosettaNet 2005w 80

92 5. Stärken und Potenzial von RosettaNet Das derzeit aktive Payment Milestone Program (PMP) versucht einen einzigen umfassenden Zahlungsprozess zu entwickeln, mit welchem der Ausgleich von Forderungen und Verbindlichkeiten sowie eine verbesserte Informationsverfügbarkeit realisiert werden kann. 150 Auch soll die Transparenz von Zahlungen für eine zielgerichtete Planung von Geldmitteln ermöglicht werden. Hierdurch können vor allem Prozesskosten verringert werden, da der Ausgleich von Zahlungen automatisiert erfolgt und der Informationsfluss ebenfalls verbessert wird. Das PMP hat hierbei nicht die Zielsetzung, neue Standards für den Finanzbereich zu entwickeln. Die Spezifikationen dienen lediglich als ein Gerüst um vorhandene Standards, Sicherheitsmechanismen und Überweisungsvorlagen in einen automatisierten Prozess zu integrieren. Die bestehenden PIPs 3C3 und 3C6 werden hierfür um zusätzliche Funktionen erweitert. Zu diesem Zweck kooperiert das PMP bei ihren Entwicklungen mit zahlreichen Banken, wie der Bank of America oder der Citibank. Die neue Lösung für Zahlungsprozesse verwendet einen Unique Remittance Identifier (URI), welches ein 18-stelliger Code zur Identifizierung eines Zahlungsinitiators ist. Dieser Code ist in sämtlichen Nachrichten zwischen dem Sender und Empfänger enthalten. Er ist auch in den Zahlungsanweisungen an die Bank enthalten, welche ihn unberührt lässt und auch bei der anschließenden Bestätigung an den Empfänger in die Nachricht integriert. Geht eine Gutschrift von der Bank bei dem Empfänger ein, wird diese anhand des URI- Codes mit der zugehörigen Rechnung an den Sender verglichen und automatisch in den Systemen verbucht. Die Forderung ist hierdurch ausgeglichen. Ebenso funktioniert der Ausgleich einer Verbindlichkeit, jedoch mit umgekehrten Rollen innerhalb des Prozesses. Die bisher genannten Nutzenaspekte werden nun nocheinmal kurz zusammengefasst. Reduzierte Bearbeitungskosten für Eingangsrechnungen Handelspartner, die einen Zahlungsprozess über RosettaNet ausführen, haben die Möglichkeit ihre Prozesskosten durch einen geringeren manuellen Aufwand erheblich zu senken. Zusätzlich kann durch die Integration einer automatischen Zahlungsanweisung (PIP 3C6) dieser Vorteil weiter verstärkt werden. Verbesserte Informationsverfügbarkeit Durch eine erhöhte Transparenz der Zahlungsflüsse zwischen Unternehmen kann die Verwendung verfügbarer Geldmittel effizienter geplant werden. Diese Automation kann zwar den erforderlichen Zeitraum bis zur Gutschrift beim Empfängerunternehmen nicht verringern, aber die aktuelle Menge verfügbarer Geldmittel wird umgehend nach einer Zahlungsanweisung aktualisiert. Verzögerte Lieferungen aufgrund überzogener Kreditlinie können vermieden werden und die Vorhersagbarkeit der aktuellen Liquidität wird verbessert. Verfolgung des Zahlungsvorganges Einige Finanzdienstleister und Banken bieten den Anwendern des PIP3C6 den zusätzlichen Service, die Transparenz der Zahlungen auch innerhalb ihrer eigenen Netzwerke zu erhöhen. Eine Zahlung kann demnach von der Vekäufer- und 150 Vgl. RosettaNet 2005u 81

93 5. Stärken und Potenzial von RosettaNet Käuferpartei ohne Unterbrechung von ihrer Initiierung bis zu ihrer Gutschrift verfolgt werden. Kooperation mit bestehenden Standards Für die Spezifikationen werden bereits existierende Standards verwendet. Die Automation erfolgt unter Verwendung des in der Finanzbranche am häufigsten verwendeten Transportmechanismus SWIFT sowie bekannten Sicherheitsmechanismen. 5.3 Zusammenfassung der Ergebnisse Die in den letzten Kapiteln dargestellten Stärken von RosettaNet und die möglichen Vorteile für Anwenderunternehmen werden in Tabelle 7 noch einmal zusammenfassend dargestellt. Ausgestaltung von RosettaNet Stärken und Potenzial Initiative für Verbreitung und Akzeptanz Organisationsstruktur Interaktiver Entwicklungsprozess Schnelle Reaktion auf Änderungen der Marktbedingungen und Anforderungen der Anwender Hohe Qualität des Standards Unterstützung durch namhafte Unternehmen und Organisationen Prüfung und Bewährung vor Publikation Ständige Weiterentwicklung durch zahlreiche Programme Umfangreicher Service und Support Regelmäßige Information von Mitgliedern Sicherheit (Digitale Zertifikate, SSL, S/MIME) Implementierungsunterstützung Einschätzung der Kosten und Nutzen einer Implementierung Produktive Implementierungen (Case Studies) Konvergenz mit anderern Standards Programme zur Senkung der Implementierungskosten Differenzierte Partizipationsmöglichkeit (Board Member, Partner, Associate Partner) Nutzenaspekte für Anwenderunternehmen Spezifikationen für viele Prozessbereiche (über 100 PIPs) Globale Konsistenz Beachtung spezifischer Branchenerfordernisse Ständiges Wachstum in Funktion und Netzwerkgröße 82

94 5. Stärken und Potenzial von RosettaNet Engere Geschäftsbeziehungen Verbesserte Operationseffizienz Sinkende Anschlusskosten weiterer Handelspartner Verbesserte Geschäftsmöglichkeiten Senkung der Reaktionszeiten Optimierung des Produktlebenszyklus Geringerer Bedarf an manuellen Eingriffen Schnellere und kostengünstigere Transaktionen Sinkende Personalkosten Effizientere Planung des Materialbedarfs Investitionsschutz Durch eine Prozess-Automation: Bereich Ordering Geringerer Personaleinsatz Reduzierte Transaktionskosten Verringerte Fehleranfälligkeit Reduktion des Zeitaufwandes Verringerte Lagerbestände und Lagerhaltungskosten Transportoptimierung Geringere Lieferkosten Schnellere Reaktion auf Änderungen Erhöhte Liefereffizienz Durch den Einsatz von RosettaNet: Skalierbarkeit Geringere Lieferantenpreise Auftragsmanagement eines der am detailliertesten ausgestalteten Prozessbereiche Bereich Invoicing Geringerer Personaleinsatz Reduzierte Transaktionskosten Verringerte Fehleranfälligkeit Zinsgewinn durch schnellere Zahlung bzw. schnellere Zuordnung der Zahlung Programme zur Optimierung von Zahlungsprozessen Kooperation mit existierenden Standards Zusammenarbeit mit zahlreichen Banken und Finanzdienstleistern Reduzierte Bearbeitungskosten für den Ausgleich eingehender Forderungen und beglichener Verbindlichkeiten Verbesserte Informationsverfügbarkeit Verfolgung des Zahlungsvorganges Tabelle 7: Stärken und Nutzenaspekte von RosettaNet (Eigene Darstellung) 83

95 6. RosettaNet: Success Stories 6. RosettaNet: Success Stories RosettaNet wird von vielen Unternehmen bereits produktiv eingesetzt. Allein in der Trading Partner Directory sind gegenwärtig über 1000 Unternehmen als Anwender verzeichnet. Dieses Kapitel befasst sich mit einigen erfolgreich durchgeführten Implementierungen und den dabei festgestellten Nutzenaspekten. Die Betrachtung bezieht sich auf zwei Success Stories aus dem Bereich des Auftragsmanagements (Cluster3). Sie umfassen Erläuterungen der Ausgangssituation, der Zielsetzungen für eine neue Lösung, der durchgeführten RosettaNet-Implementierung sowie der daraus resultierenden Vorteile. Die erste Success Story, hier Ordering genannt, zeigt diese Aspekte für eine Automatisierung der Prozesse Anfrage und Bestellung (Segment 3A - Qoute and Order Entry) sowie Lieferung und Transport (Segment 3B - Transport and Distribution). In der zweiten Success Story, die im folgenden als Invoicing bezeichnet wird, soll hingegen eine Automation des Zahlungsprozesses (Segment 3C - Finances) anhand der PIPs 3C3 und 3C6 sowie dessen Ergebnisse dargestellt werden. 6.1 Ordering Innerhalb der letzten fünf Jahre hat Intel große Anstrengungen unternommen, die Automation von Abläufen innerhalb des eigenen Unternehmens voranzutreiben und ebenso gemeinsame Prozesse mit Handelspartnern effizienter zu gestalten. So hat das Unternehmen Anfang 2004 mit der World Peace Group eine RosettaNet- Implementierung für den Bereich des Auftragsmanagements (Cluster 3) durchgeführt. 151 Die in dieser Success Story dargestellten Aspekte umfassen sowohl die Ausgestaltung der Prozesse in ihrer Ausgangssituation, als auch die für eine Implementierung von RosettaNet an ihnen vorgenommenen Änderungen. Der neue Prozessablauf wird daraufhin abgebildet und mit der alten Lösung verglichen. Im Rahmen dieses Projektes konnten für Intel und WPG eine Reihe von Nutzenaspekten durch RosettaNet realisiert werden Firmeninformation Intel Semiconductor Ltd., eines der Mitglieder von RosettaNet, ist der führende Hersteller von Mikrobausteinen (Chips) mit einem Umsatz von 34,2 Milliarden Dollar. 152 Das Unternehmen wurde 1968 mit dem Ziel einer Produktion von Halbleiter-Speichern gegründet und entwickelte 1971 den ersten Mikroprozessor. Gegenwärtig werden von Intel mehr als Mitarbeiter beschäftigt. Das Unternehmen ist weltweit der bedeutendste Lieferant der High-Tech-Industrie mit einem Produktangebot von Chips, Platinen, Systemen und Softwaremodulen. Diese Komponenten werden von führenden Unternehmen für die Herstellung von Computer- und Kommunikationssystemen eingesetzt. Die World Peace Group (WPG) wurde 1981 in der Asien-Pazifik Region gegründet und ist heute einer der führenden Lieferanten von Halbleiter-Komponenten. Das 151 Vgl. Intel Vgl. Intel

96 6. RosettaNet: Success Stories Unternehmen vertreibt gegenwärtig über 60 Produkte von Anbietern wie Intel, Philips oder Texas Instruments. Mit über Mitarbeitern realisierte WPG einen Umsatz von 2,26 Milliarden Dollar im vergangenen Geschäftsjahr. 153 Verkaufs- und Service- Filialen von WPG befinden sich im ganzen asiatischen Raum, u.a. in Taiwan, Hong Kong und Singapur. Intel und WPG sind langjährige Handelspartner. Die World Peace Group ist ein wichtiger Kunde von Intel, da das Unternehmen als führender Händler für dessen Produkte im asiatischen Raum gilt Ausgangssituation Vor dem Beginn des Projektes wurde die Kommunikation zwischen Intel und WPG über Webportale, Fax, , Telefon und EDI geführt. Die Prozesse im Bereich des Auftragsmanagements waren hierdurch sehr langsam und haben das mögliche Informationsvolumen für eine Speicherung und Nutzung von Daten stark eingeschränkt. In der Ausgangssituation wurden Bestellungen von WPG über ein von Intel bereit gestelltes Webportal aufgegeben. Zwar konnte durch dieses Webportal die Informationsverfügbarkeit für Intel verbessert werden, Käufer sahen sich jedoch weiterhin der Anforderung einer doppelten Dateneingabe gegenüber. Die Eingabe fehlerhafter Produktnummern, Preisdetails, Lieferangaben oder Mengenanzahlen führte vor allem auf der Seite von WPG zu aufwendigen Korrekturmaßnahmen. Innerhalb WPG s Supply Chain waren Bestellungen daher mit einem großem Zeitaufwand verbunden. Genau an dieser Stelle sollte das gemeinsame Projekt der beiden Unternehmen ansetzen und die geschilderten Probleme beheben. Mit einer B2B-Integration der Bestellprozesse über RosettaNet sollten Nutzenaspekte für beide Handelspartner realisiert werden. Übergreifende Prozesse sollten nicht nur die Effizienz steigern, sondern ebenfalls den Kundenservice durch eine geringere Fehleranfälligkeit und kürzere Antwortzeiten verbessern Zielsetzung Die Integration von Systemen verschiedener Handelspartner und die Automatisierung manueller Prozesse ermöglicht eine effizientere und kostengünstigere Durchführung von Geschäftsvorgängen. WPG und Intel haben sich zunächst auf eine Implementierung von PIPs für das Auftragsmanagement geeinigt. Diese umfassen in der gegenwärtigen Umsetzung die PIPs 3A4, 3A7, 3A8 und 3B2. Mit der neuen Lösung versuchen die beiden Unternehmen eine Reihe von Nutzenaspekten zu realisieren. Verbessertes Lagerbestandsmanagement Mit einem geringeren Lagerbestand können die mit der Lagerhaltung verbundenen Kosten deutlich reduziert werden. Die erhöhte Informationsverfügbarkeit und die schnellere Durchführbarkeit von Prozessen führt weiterhin zu einer genaueren und damit effizienteren Materialplanung. 153 Vgl. WPG

97 6. RosettaNet: Success Stories Sinkende Kommunikationskosten Eine Automation von Prozessen führt zu einem sinkenden Bedarf an Personal und zu einer geringeren Nutzung traditioneller Kommunikationssysteme. Geringere Bearbeitungszeiten Die Kundenzufriedenheit kann aufgrund geringerer Bearbeitungszeiten und daraus resultierenden kürzeren Reaktions- und Lieferzeiten erhöht werden. Reduktion manueller Eingriffe Durch die Automation von Bestellprozessen sinkt der Aufwand für die Eingabe und Verarbeitung von Daten. Somit entfallen Fehlerkorrekturen und die frei gewordenen Ressourcen können für produktivere Aufgaben genutzt werden. Diese Aspekte zeigen die grundlegende Zielsetzung von WPG und Intel für eine Automation ihrer gemeinsamen Prozesse anhand von RosettaNet auf. Die Ausgestaltung der erfolgten Implementierung und die Gegenüberstellung mit der alten Lösung wird im weiteren näher erläutert Implementierung von RosettaNet Das Pilotprojekt und die anschließende Einführung von RosettaNet dauerten insgesamt acht Monate. In dieser Zeit wurden die gemeinsamen Auftragsprozesse identifiziert und hinsichtlich ihres Verbesserungspotenzials analysiert. Die Identifikation von Unstimmigkeiten bei der Durchführung einzelner Schritte des Prozesses ermöglichte den beiden Unternehmen auch ihre internen Vorgehensweisen zu überdenken und einen effizienteren Rahmen für den Einsatz von PIPs zu entwickeln. Intel und WPG einigten sich zunächst auf eine Implementierung von PIP 3A4, 3A7, 3A8 und 3B2. Die Zahlungsprozesse 3C3 und 3C6 sollten zu einem späteren Zeitpunkt für eine Vervollständigung des Auftragsmanagements folgen. RosettaNet verbessert die Kommunikation zwischen Intel und WPG durch den intensiven Einsatz von XML. Hierdurch kann ungeachtet der verwendeten Hardware oder ERP-Systeme der einzelnen Handelspartner, ein direkter Informationsaustausch zwischen den Unternehmen realisiert werden. Das standardisierte Nachrichtenformat und die in ihrer Semantik festgelegten Elemente ermöglichen eine weitgehende Automatisierung, so dass sich die Mitarbeiter auf die wesentlichen Aspekte ihres Aufgabenbereichs, wie z.b. der Kundenberatung, konzentrieren können. Die Ausgestaltung des Prozessbereichs mit RosettaNet wird in Abbildung 19 dargestellt. 86

98 6. RosettaNet: Success Stories Abbildung 19: Auftragsmanagement zwischen WPG und Intel (Intel 2004) WPG kann mit dem PIP 3A4 eine Bestellung an Intel auslösen. Intel kann auf die erhaltene Nachricht mit einer Bestätigung, Ablehnung oder einem Bearbeitungsstatus reagieren. Wird die Bestellung akzeptiert kann Intel bei Änderungen seiner Lieferfrist oder der Warenverfügbarkeit nachträglich anhand des PIP 3A7 eine Aktualisierung der Bestellungsinformationen an WPG übermitteln. Der PIP 3A8 ist ähnlich wie der 3A4 aufgebaut und enthält eine Nachricht des Käufers über eine Änderung seiner Bestellung. Dies kann beispielsweise den gewünschten Lieferzeitpunkt, die Bestellmenge oder die Produktkomponenten betreffen. Je nach Verfügbarkeit und Realisierbarkeit der Änderung kann Intel mit einer entsprechenden Nachricht reagieren. Nach der vollständigen Bearbeitung der Bestellung erfolgt die Lieferung an den Kunden. Intel kann den PIP 3B2 dazu verwenden, die Lieferkonditionen mit Angaben über den erwarteten Lieferzeitpunkt an WPG zu senden. Den Abschluss des Auftragsprozesses bilden die mit einer Rechnung verbundenen Vorgänge. Während der PIP 3C3 die Übermittlung des Rechnungsdokuments an WPG übernimmt, kann mit dem PIP 3C6 ein Zahlungsvorgang veranlasst und später der Eingang des Geldes belegt werden. Die Zahlungsprozesse werden ausführlicher in der zweiten Success Story Invoicing dargestellt. Abschnitt 6.1 beschränkt sich auf eine Erläuterung der mit einer Bestellrealisation verbundenen Vorgänge. Die einzelnen automatisierten Vorgänge werden nun der Reihe nach mit einem Vergleich zur alten Lösung vorgestellt. Den Kern des Auftragsmanagements bildet die Bestellanfrage eines Käufers. Sie enthält sämtliche für eine Auftragserfüllung notwendigen Daten, wie Produktbezeichnungen, Mengenangaben und Lieferkonditionen. In Abbildung 20 werden die für eine Bestellung notwendigen Schritte im Vergleich vor und nach Einführung von RosettaNet dargestellt. 87

99 6. RosettaNet: Success Stories Abbildung 20: Vergleich des Prozesses Bestellanfrage (Intel 2004) Vor der B2B-Integration musste WPG, die in seinen ERP-Systemen formulierte Bestellung, erneut in das Webportal von Intel (WOM) eingeben. Die Überführung von Informationen bezüglich des Bearbeitungsstatus erforderte das wöchentliche Herunterladen notwendiger Daten von Intel s Portal und die manuelle Eingabe in WPG s ERP-Systeme. Mit dem PIP 3A4 werden die einzelnen Vorgänge des Bestellprozesses deutlich vereinfacht. Die Initiierung einer Bestellung und die darauf folgende Auftragsbestätigung werden direkt an die ERP-Systeme der Handelspartner übermittelt. Die doppelte Eingabe von Daten entfällt und die Informationsverfügbarkeit zwischen den Unternehmen wird deutlich von einem wöchentlichen Download auf eine Echtzeit- Verfügbarkeit gesenkt. Manchmal besteht die Notwendigkeit eine bereits getätigte Bestellung nachträglich zu ändern. Hat WPG beispielsweise eine fehlerhafte Produktbezeichnung verwendet oder ist nachträglich eine Änderung der Bestellmenge erforderlich, muss der Käufer über eine Möglichkeit verfügen dies dem Verkäufer mitzuteilen (Bestellungsänderung). Abbildung 21: Vergleich des Prozesses Bestellungsänderung (Intel 2004) 88

100 6. RosettaNet: Success Stories Die Durchführung von Änderungen an einer bereits veranlassten Bestellung war bis zur Einführung von RosettaNet sehr zeitaufwendig. WPG musste sich im Webportal von Intel einloggen und die Daten der Bestellung manuell ändern. Intel sah die Änderungen in seinen Systemen ein und übernahm die neuen Daten manuell in sein ERP- System. Der Änderungsprozess von RosettaNet ist hingegen eine vollständig geschlossene Kette an Vorgängen mit zeitnahen Benachrichtigungen über dessen Realisierbarkeit durch Intel. WPG gibt im Rahmen der neuen Lösung lediglich die geänderten Daten in sein ERP-System ein und löst den damit zusammenhängenden PIP 3A8 aus. Intel reagiert hierauf mit dem PIP 3A7, welche die Aktualisierung von WPG s Bestellung beinhaltet. Sämtliche enthaltenen Daten können von Intel und WPG direkt in deren ERP-Systeme übernommen und dort weiterverarbeitet werden. Auch der Verkäufer eines Produktes kann nachträglich Änderungen an einer eingegangenen Bestellung ausführen. Diese Bestellungsaktualisierung ist beispielsweise notwendig, wenn der Käufer eine bestimmte Produktmenge nicht vollständig liefern kann oder sich der Zeitpunkt der Lieferung verschiebt. Abbildung 22 enthält eine Darstellung der Prozesse im Vergleich zwischen der alten und neuen Lösung. Abbildung 22: Vergleich des Prozesses Bestellungsaktualisierung (Intel 2004) Jegliche Änderungen von Intel an den Details einer Bestellung erforderten in der Ausgangssituation zunächst eine Aktualisierung der betroffenen Daten in dessen Webportal. Es erfolgte weiterhin eine Benachrichtigung per an WPG. Eine Änderung der Daten in WPG s ERP-System erforderte wiederum den manuellen Download und die Übertragung der entsprechenden Daten von Intel. Eine Automatisierung des Vorgangs ermöglicht den Systemen von Intel die direkte Übertragung einer Bestellungsaktualisierung an WPG. Diese verfügt gegenwärtig nahezu über eine Echtzeit-Information bezüglich der Stati seiner Bestellungen. WPG kann hierdurch nicht nur den manuellen Aufwand reduzieren, sondern auch die Lagerhaltung effizienter planen. Der Verkäufer eines Produktes informiert den Käufer über die Lieferdetails seiner Bestellung. Dies umfasst Angaben zu der Lieferadresse und dem voraussichtlichen Liefertermin. Abbildung 23 zeigt die Durchführung eines solchen Prozesses für Intel und WPG. 89

101 6. RosettaNet: Success Stories Abbildung 23: Vergleich des Prozesses Lieferdetails (Intel 2004) Vor der Implementierung des PIP 3B2 wurden die Lieferinformationen einer Bestellung ebenfalls manuell aus dem Webportal von Intel heraus bezogen. Die Daten mussten dann per Hand in die verwendeten Systeme eingegeben werden. Der PIP 3B2 ermöglicht nun den automatischen Versand dieser Informationen durch Intel und erhöht damit die Verfügbarkeit aktueller Daten für WPG Nutzenaspekte Die automatisierten Arbeitsabläufe zwischen Intel und WPG zeigen die grundlegenden Vorteile einer Ablösung manueller Bestellprozesse durch RosettaNet PIPs auf. Zusätzlich zu den direkten finanziellen und operativen Nutzenaspekten, wie sinkenden Transaktionskosten und Lieferzeiten, wurden auch eine Reihe von indirekten Vorteilen festgestellt. Hierzu gehört der deutliche gesunkene Zeitbedarf für Entscheidungen des Supply Chain Managements. Mit der Automatisierung kann für beide Unternehmen deren Effizienz gesteigert werden. Die Neu-Konstruierung der Geschäftsprozesse und anschließende Implementierung von RosettaNet hat den Bedarf einer manuellen Intervention deutlich gesenkt. Lediglich Ausnahmesituationen, wie spezielle Lieferbedingungen oder zusätzliche Kundenwünsche, erfordern in dem automatisierten Bestellprozess noch einen geringen Personalaufwand. Einige der nach der Implementierung von RosettaNet festgestellten Nutzenaspekte werden im folgenden zusammengefasst. Effizientere Arbeitsabläufe Manuelle Prozesse konnten auf ein geringes Maß gesenkt werden. Vor allem die doppelten Dateneingaben bei der Initiierung einer Bestellung oder deren Änderung über Fax, Telefon oder das Webportal von Intel entfielen. Die Anzahl notwendiger Arbeitsstunden für Bestellvorgänge wurden deutlich gesenkt. WPG gibt nun Bestellanfragen direkt in sein ERP-System ein, womit mehrfache Eingaben in unterschiedliche Systeme entfallen. 90

102 6. RosettaNet: Success Stories Geringere Kommunikationskosten Die gesamten Transaktionskosten konnten durch die Verringerung einer Kommunikation über Telefon, Fax oder gesenkt werden. Informationen werden mit RosettaNet direkt an die Systeme des Handelspartners übermittelt und dort automatisch weiterverarbeitet. Geringere Fehleranfälligkeit Mit der Verringerung der manuellen Eingriffe und redundanter Prozesse, konnte die Fehlerwahrscheinlichkeit bei den Bestelldaten gesenkt werden. Dementsprechend seltener sind auch Rücksendungen, die auf fehlerhaften Eingaben beruhen. Schnellere Auftragsbearbeitung WPG erhält die Bestellbestätigungen und Nachrichten über den Bearbeitungstatus innerhalb eines kürzeren Zeitraumes. Vor Einführung von RosettaNet wurden von WPG wöchentliche Downloads dieser Informationen von Intel s Website in ihre ERP-Systeme vorgenommen. Im Vergleich zur alten Lösung ist damit die Informationsverfügbarkeit deutlich erhöht worden. Geschäftsentscheidungen können hierdurch auf Basis genauerer Informationen getroffen werden. Die erhöhte Informationsverfügbarkeit führt außerdem zu einer schnelleren Auftragsbearbeitung und damit zu einer schnelleren Realisation von Umsätzen. Verbesserte Kommunikation Die Systeme der Handelspartner versenden automatisierte Benachrichtigungen (Signale) bei erfolgreichem Versand oder Transaktionsproblemen. Hierdurch können Kommunikationsabläufe effizienter gestaltet werden. Effizienteres Lagerbestandsmanagement Geringere Bearbeitungszeiten führen zu einer optimierten Lagerhaltung. Die Materialplanung kann hierdurch tagesaktuell erfolgen und Kosten können gesenkt werden. Geringere Lieferzeiten Die Verfügbarkeit vollständiger und aktueller Daten ermöglicht die Realisation kürzerer Lieferzeiten. Logistikunternehmen können schneller auf Änderungen reagieren und ihre Pläne anpassen, so dass Verzögerungen verhindert werden können. Bei der Implementierung von RosettaNet für den Bereich Auftragsmanagement konnten die vor der Einführung entwickelte Zielsetzung umfassend erfüllt werden. Im direkten Vergleich zwischen der Ausgangssituation und der Implementierung von RosettaNet trat die deutliche Reduktion des Zeitaufwandes innerhalb der einzelnen Prozesse besonders hervor. Dies wird in Abbildung 24 dargestellt. 91

103 6. RosettaNet: Success Stories Zeitaufwand (Std. pro Woche) Lieferdetails Bestellaktualisierung Bestellanfrage Ausgangssituation Implementierung von PIPs Abbildung 24: Zeitersparnisse durch RosettaNet (Vgl. Intel 2004) Die größte Zeitersparnis liegt in der Automation der Bestellanfrage zwischen Intel und WPG. Hier konnten durch den Einsatz von RosettaNet bis zu 13 Stunden pro Woche an Zeit eingespart werden. Die 7 Stunden Arbeitszeit, die anfänglich für die Aktualisierung einer Bestellung aufgewendet werden mussten, konnten auf 3 Stunden gesenkt werden. Auch bei der Übermittlung der Lieferdetails an den Kunden konnte die Effizienz gesteigert werden. In diesem Prozess konnte der Personalaufwand um einen Anteil von 50% reduziert werden. 6.2 Invoicing Die Intel Corporation setzt sich stark für den Fortschritt des Payments Milestone Programs ein. Die Spezifikationen des in Abschnitt bereits vorgestellten Programms befinden sich seit Ende 2004 in der Testphase. Hierbei werden die weiterentwickelten PIPs 3C3 und 3C6 in produktiven Szenarien eingesetzt und anschließend bewertet. Intel hat in diesem Rahmen mit einigen seiner Handelspartner, wie u.a. Nokia, eine Implementierung dieser Spezifikationen vorgenommen. Die Ergebnisse dieser Phase wurden bereits auf der Website von RosettaNet veröffentlicht. 154 Sie werden im Folgenden zusammengefasst Firmeninformation Da die Intel Corporation bereits im vorigen Abschnitt vorgestellt wurde, erfolgt hier nur noch eine kurze Darstellung des Unternehmens Nokia. Nokia ist der führende Anbieter im Bereich der mobilen Kommunikation mit über Mitarbeitern und einem weltweiten Nettoumsatz von 29,4 Milliarden. 155 Das Unternehmen ist ebenfalls einer der bedeutendsten Lieferanten für Multimedia- 154 Vgl. Tearnen Vgl. Nokia

104 6. RosettaNet: Success Stories Produkte, Telekommunikationsnetzwerke und zugehörige Services. Nokia ist Mitglied des Telecommunication Boards von RosettaNet und arbeitet hier zusammen mit Intel an zahlreichen Projekten. Abgesehen davon ist Nokia ein langjähriger Kunde des Unternehmens Intel. Aufgrund dieser engen Kooperation haben sich die Firmen für eine Automation ihrer gemeinsamen Zahlungsvorgänge entschieden Ausgangssituation In einen Zahlungsprozess sind vier verschiedene Parteien involviert, der Käufer, der Verkäufer sowie deren Banken. Diese erschweren durch ihre unterschiedlichen Zielsetzungen und die Verwendung verschiedener Systeme sowie Mechanismen die effiziente Gestaltung einer gemeinsamen Zahlungsabwicklung. Erst die Einführung eines allgemeinen Standards ermöglicht eine übergreifende Automation. Auf diese Weise können die Interessen der Beteiligten auf einfache Weise zusammengeführt werden. Das Payment Milestone Program versucht einen solchen umfassenden Standard für die Abwicklung von Zahlungsprozessen zu entwickeln. Vor der Einführung des PIP 3C3 und 3C6 wurden zwischen Intel und Nokia derartige Prozesse manuell durchgeführt. In Abbildung 25 ist die Ausgangssituation vor der Einführung von RosettaNet zwischen den beiden Unternehmen dargestellt. Abbildung 25: Ausgangssituation (Tearnen 2004) Nachdem die Lieferung an seinen Kunden (Nokia) veranlasst wurde erstellt der Lieferant (Intel) manuell eine Rechnung und übermittelt diese per Fax, EDI oder Brief an Nokia (Invoice Notification). Nach Eingang und Überprüfung der Rechnung übernimmt der Kunde die erforderlichen Daten manuell in sein Back-End-System. Er sendet anschließend eine Nachricht an Intel, welche eine Benachrichtigung über die Initiierung der Zahlung, den Zahlungsavis, enthält (Remittance Advice). Ebenfalls wird ein verbindlicher Zahlungsauftrag an die Hausbank des Kunden übermittelt 93

105 6. RosettaNet: Success Stories (Initiate Payment). Diese führt die Überweisung des Rechnungsbetrages an die Bank des Verkäufers durch (Interbank Clearing), welche nach Gutschrift eine Bestätigung hierüber an den Verkäufer sendet (Receive Payment). Abschließend erfolgt ein manueller Vergleich des Zahlungsavis des Käufers und der Zahlungseingangsbestätigung der Bank. Wenn der Zahlungseingang den offenen Forderungen entspricht, kann der Ausgleich der Forderung im System des Verkäufers gebucht werden kann. Der soeben dargestellte Zahlungsprozess ist nicht nur sehr zeitaufwendig, sondern durch den erforderlichen Personalaufwand auch sehr kostenintensiv. Rechnungen müssen zunächst manuell erstellt und übermittelt werden, eingehende Forderungen von Nokia mit den Daten des Kunden verglichen und anschließend manuell in den Systemen gebucht werden. Die hierbei nötige menschliche Intervention stellt nicht nur einen Kostenfaktor dar, sondern birgt ebenso die Gefahr einer hohen Fehleranfälligkeit. Aufgrund einer mehrtägigen Bearbeitungszeit der Banken für Zahlungsvorgänge und eine anschließende Verzögerung durch einen manuellen Vergleich und eine Verbuchung der Belege, sind Geldmittel oft bis zu 7 Tage später für eine weitere Verwendung verfügbar. Dies führt neben einem erhöhten Administrationsaufwand auch zu einer ineffizienten Nutzung der Geldmittel (Opportunitätskosten). Die Intransparenz der Prozesse kann auch zu Problemen bei weiteren Verkäufen an einen Kunden führen. Dies ist der Fall, wenn ein Kunde über eine bestimmte Kreditlinie verfügt und im System offene Forderungen in gleiche Höhe bestehen, die zwar bereits bezahlt aber noch nicht zugeordnet wurden. Erhält ein Verkäuferunternehmen erst spät die Benachrichtigung einer Gutschrift, ist es manchmal systemseitig oft nicht möglich weitere Aufträge anzunehmen. Die Kreditlinie als Instrument zum Ausfallmanagement wirkt durch die Intranzparenz der Zahlungsprozesse hierbei geschäftshemmend. Ein weiterer Problembereich dieses traditionellen Vorgehens ist die Verfügbarkeit einer Vielzahl von Standards innerhalb des Finanzsektors für eine Bestätigung des Zahlungseinganges. Ist keine Einigung auf ein gemeinsames Format für derartige Nachrichten getroffen worden, haben die Parteien Schwierigkeiten, erhaltene Daten automatisch in die eigenen Systeme zu übertragen und weiterzuverarbeiten. An dieser Stelle ist wieder manueller Aufwand notwendig. Die Herausforderung bei der Standardisierung eines Zahlungsprozesses liegt in der Vereinheitlichung der verschiedenen Interessen und der Formulierung eines gemeinsamen Standards. Das Problem zwischen Käufer und Verkäufer ergibt sich hierbei aus der Vielzahl von XML-basierten Standards für den Zahlungsavis und die Zahlungseingangsbestätigung sowie weiterhin einem fehlenden Zusammenhang zwischen diesen beiden Belegen. Je nach Unternehmen führt dies zu unterschiedlich ausgestalteten Zahlungsvorgängen und einer erschwerten Durchführung von Buchungen eines Zahlungsausgleiches. Für eine effiziente Automatisierung ist ebenfalls eine Identifikation einer initiierten Zahlung notwendig, um diese nicht nur während des Prozesses verfolgen zu können, sondern auch einen Vergleich mit anderen Belegen zu vereinfachen. Das Fehlen eines solchen Identifikationsmechanismus stellt eine weitere Aufgabe dar, die von einer Standardisierung zu lösen ist. Auch müssen verschiedene Überweisungsvorlagen 94

106 6. RosettaNet: Success Stories innerhalb des Finanzsektors vereinheitlicht und die Transparenz der Vorgänge erhöht werden, um die unnötige Verzögerung von Lieferungen vermeiden und das Kreditrisiko eines Unternehmens verringern zu können Zielsetzung Die verschiedenen Vorgänge auf der Käufer- und Verkäuferseite bieten, wie im letzten Abschnitt dargestellt wurde, ein großes Verbesserungspotenzial. Die Zielsetzung einer Implementierung von RosettaNet und der damit verbundenen Automation von Prozessen liegt aus der Sicht des Käufers im Wesentlichen in den folgenden Aspekten: Die Automation ermöglicht eine schnellere Gutschrift auf dem Konto des Empfängers. Der Käufer kann hierdurch seine Kreditlinie bei dem Verkäufer optimal ausnutzen und eine Verzögerung anschließender Lieferungen kann hierdurch leichter vermieden werden. Die manuelle Formulierung und Übermittlung eines Zahlungsavis und einer Zahlungsanweisung entfällt. Daten müssen nicht doppelt eingegeben werden. Beide Vorgänge werden von RosettaNet ohne menschliche Intervention nacheinander automatisch ausgelöst. Der geringere Bedarf manueller Eingriffe verringert nicht nur die Personalkosten, sondern auch den notwendigen Aufwand für Fehlerbeseitigungen. Auch auf der Verkäuferseite liegen die Nutzenaspekte im Wesentlichen in einer Reduktion des manuellen Aufwandes und einer erhöhten Verfügbarkeit von Informationen. Durch die Automation eines Zahlungsprozesses kann weiterhin der Umsatz und der damit verbundene Spielraum für Investitionen erhöht werden. Die Zielsetzungen des Verkäuferunternehmens werden an dieser Stelle nocheinmal kurz dargestellt. Die Automation des Zahlungsprozesses ermöglicht die maximale Ausnutzung der Kunden-Kreditlinie. Damit können mehr Verkäufe realisiert und die Umsätze erhöht werden. Die manuelle Verarbeitung des Zahlungavis und der Zahlungseingangsbestätigung der Bank entfällt. Die Daten innerhalb der Rosettanet-Nachrichten können direkt in die Back-End-Systeme übernommen werden. Durch eine Automation von RosettaNet kann Personalaufwand reduziert und das Auftreten von Fehlern verringert werden. Mithilfe der Kostenersparnis und zusätzlichen Umsätzen wird es den Verkäuferunternehmen ermöglicht, Ersparnisse zu bilden, welche dann für zusätzliche Investitionen zur Verfügung stehen können. 95

107 6. RosettaNet: Success Stories Aufgrund dieses Verbesserungspotenzials eines traditionellen Zahlungsprozesses haben sich die Unternehmen Intel und Nokia für eine Piloteinführung von RosettaNet im Rahmen des Payment Milestone Programs entschieden. Der nächste Abschnitt befasst sich mit der Umsetzung der PIPs 3C3 und 3C Implementierung von RosettaNet Das Payment Milestone Program hat in Zusammenarbeit mit namhaften Unternehmen des IT-Sektors sowie Banken und Finanzdienstleistern einige Spezifikationen entwickelt, die den Zahlungsprozess eines Unternehmens optimieren sollen. Hierzu wurden die bestehenden RosettaNet-Spezifikationen 3C3 und 3C6 adaptiert, um die Kommunikation zwischen Käufern und Verkäufern zu vereinheitlichen. Der PIP 3C3 (Notify of Invoice) ermöglicht dem Verkäufer den Versand einer standardisierten Rechnung. Der Verkäufer kann auf diese mit einer Bestätigung bzw. Ablehnung reagieren. Auch können auf beiden Seiten die enthaltenen Daten direkt in den Back-End-Systemen verarbeitet werden. Mit dem PIP 3C6 kann ein Käufer einen Zahlungsavis übermitteln und eine Zahlungsanweisung an seine Bank veranlassen. Für eine Nachrichtenübermittlung zwischen einem Handelspartner und seiner jeweiligen Bank, sowie zwischen verschiedenen Banken wurde der SWIFT-Standard ausgewählt. Dieser wird gegenwärtig innerhalb des Finanzsektors von 7650 Instituten in über 200 Ländern für den Nachrichtentransport eingesetzt. Im Rahmen von RosettaNet unterstützt er den Versand von Nachrichten für eine Zahlungsanweisung und eine Zahlungseingangsbestätigung. Zusätzlich wurde ein Unique Remittance Identifier (URI) entwickelt, welcher als Element sämtlicher Nachrichten die Identifikation einer initiierten Zahlung ermöglicht und die Transparenz des übergreifenden Prozesses erhöht. Dieser Zahlungsprozess mit RosettaNet wird in Abbildung 26 dargestellt. Abbildung 26: Zahlungsprozess mit RosettaNet (Tearnen 2004) 96

108 6. RosettaNet: Success Stories Der Verkäufer übermittelt anhand des PIP 3C3 eine Rechnung über die bestellte Ware an dessen Käufer (Notify of Invoice). Akzeptiert der Käufer die Rechnung, kann er die enthaltenen Daten direkt in seinen Systemen verarbeiten und eine Zahlung veranlassen. Mit dem PIP 3C6 wird zunächst ein Zahlungsavis an den Verkäufer übermittelt (Notify Remittance Advice) und anschließend automatisch eine auf SWIFT basierende Zahlungsanweisung an die Bank gesendet (Payment Instruction). Diese beiden Nachrichten enthalten bereits einen von den Käufer-Systemen erstellten URI-Code, welcher der Identifikation während des gesamten Prozesses dient. Auch die Überweisung des Rechnungsbetrages zwischen den Banken (Interbank Clearing) enthält diesen Code. Nach Gutschrift des Betrages wird von der Bank des Verkäufers eine Zahlungseingangbestätigung übermittelt (Credit Advice). Anhand des URI kann der eingegangene Beleg mit dem Zahlungsavis des Käufers verglichen und direkt verbucht werden. Sämtliche hier geschilderten Vorgänge verlaufen beinahe ohne einen manuellen Eingriff Nutzenaspekte Neben der verringerten Fehleranfälligkeit des automatisierten Prozesses sowie den geringeren Personal- und Transaktionskosten, wurden von Intel und Nokia eine Reihe weiterer Nutzenaspekte als Ergebnis ihrer Implementierung festgestellt. Diese werden in Tabelle 8 zusammengefasst. Zusätzlich verfügbare Geldmittel Dauer bis zum Zahlungseingang Automatische Zuordnung eingehender Geldmittel Aufwand für Buchung der Zahlung Ausgangssituation Nach Implementierung von RosettaNet 0$ pro Tag 5-8 Millionen $ pro Tag 3-5 Tage 30 Minuten 0% 81,5% Manuell: 50$ pro Zahlungsvorgang Automatisch: Senkung auf bis zu 0$ Tabelle 8: Vorteile eines Zahlungsprozesses mit RosettaNet (Vgl. Tearnen 2004) Während der Eingang einer Zahlung bei einem traditionellen Zahlungsprozess bis zu 5 Tagen dauern kann, ist der Rechnungsbetrag bei Verwendung dieser RosettaNet- Implementierung nach bereits 30 Minuten beim Empfänger verfügbar. Hierdurch sind bei Intel zusätzliche Geldmittel in einer Höhe von 5-8 Millionen Dollar pro Tag früher verfügbar. Die eingegangenen Geldmittel können in bis zu 81,5 % der Fälle automatisch zugeordnet werden und verringern dementsprechend den nötigen Personalaufwand. Eine manuelle Bearbeitung von Rechnungen kostete in der Ausgangsituation etwa 50 Dollar pro Rechnung. In 81,5 % der Fälle konnten diese Kosten durch den Einsatz von RosettaNet eingespart werden. Dies ist auf die beinahe vollständige Automation und die Verringerung der Fehleranfälligkeit zurückzuführen. Informationen bezüglich der konkreten Zeitpunkte von Geldbewegungen ermöglichen den Unternehmen eine effizientere Liquiditätsplanung. Auch die Kreditlinie eines Unternehmens kann durch schnellere Zahlungsvorgänge effizienter 97

109 6. RosettaNet: Success Stories ausgenutzt werden. Zusätzlich kann man mit der neuen Lösung ein automatischer SWIFT-Bericht über die tagesaktuellen Eingangsgelder in den ERP-Systemen erstellt werden, um die Transparenz der Zahlungsaktivitäten eines Tages zu erhöhen. Die hier vorgestellten Success Stories haben das Verbesserungspotenzial traditioneller Prozesse aufgezeigt und verdeutlicht welche Nutzenaspekte mit einer Implementierung von RosettaNet verbunden sein können. Neben einem reduzierten manuellen Aufwand und dadurch freigegegebenen Ressourcen, ist hierbei vor allem die verbesserte Informationsverfügbarkeit ein wichtiger Faktor. Für die Unternehmen wird eine Grundlage geschaffen, welche es ihnen ermöglicht ihre Geschäftsabläufe effizienter zu gestalten und Kostenersparnisse zu realisieren. Eine detailliertere Betrachtung einer Implementierung von RosettaNet für das Invoicing erfolgt anhand einer Fallstudie von IBM in Kapitel 9. 98

110 7. Anwendung und Verbreitung von RosettaNet 7. Anwendung und Verbreitung von RosettaNet Nachdem sich die letzten Kapitel mit einer Darstellung der Spezifikationen eines Standards und den resultierenden Vorteilen einer Implementierung beschäftigt haben, geht dieses Kapitel nun auf die gegenwärtige Verwendung der einzelnen Standards ein. Hierbei soll die relative Bedeutung von RosettaNet im Vergleich zu anderen Initiativen herausgearbeitet werden und eine nähere Betrachtung hinsichtlich dessen gegenwärtiger Akzeptanz durch Unternehmen erfolgen. Weiterhin wird ein wichtiger Faktor für die weitere Verbreitung eines Standards, die Unterstützung durch Standardsoftware, für RosettaNet kurz dargestellt. 7.1 Verbreitung Auch in den kommenden Jahren wird eine B2B-Integration für Unternehmen und ihre Handelspartner von hoher Bedeutung sein. Dies wird aus aktuellen Zahlen zu Investitionsplanungen deutscher Unternehmen für die nächsten 12 Monate deutlich. So gaben in einer Studie vom Juni % der befragten Unternehmen an, über 1 Million Dollar für Investitionen in den B2B-Bereich eingeplant zu haben. Weitere 21% rechnen mit Investition zwischen Dollar für das nächste Jahr. 156 Anhand dieser Daten wird deutlich, dass Unternehmen zunehmend der Erfordernis gegenüber stehen, Prozesse mit ihren Handelspartnern effizienter zu gestalten und die Vorgänge in ihrer Supply Chain zu optimieren. Im Bereich des B2B nimmt vor allem aber die Verbreitung von XML-Standards stark zu. Das Transaktionsvolumen über XML hat bereits im Jahr 2003 einen Zuwachs von 160% erlangt. 157 Transaktionen auf Basis von EDI sind demgegenüber innerhalb desselben Zeitraumes lediglich um 18% angestiegen. Dies zeigt neben der zunehmenden Bedeutung einer standardisierten Kommunikation, andererseits auch die augenblicklich höhere Relevanz von XML im Vergleich zu EDI. Langfristig gesehen wird bei einer Fortsetzung des aktuellen Trends XML den EDI-Standard daher bald eingeholt oder vielleicht sogar abgelöst haben. Die Yankee Group führt den starken Anstieg an XML-Adaptionen vor allem auf die sinkenden Kosten einer damit verbundenen Implementierung zurück. 158 Die steigende Investitionstätigkeit wird hierbei meistens von großen Firmen vorangetrieben. Beispiel hierfür ist das Unternehmen Intel, welches angekündigt hat, seine EDI-Systeme bis 2006 vollständig durch RosettaNet zu ersetzen. 159 Damit stehen auch dessen Handelspartner unter dem zunehmenden Druck, diesem Ansatz zu folgen. Mit der Vielzahl großer Unternehmen, die die Verwendung von XML-Standards unterstützen, werden sich diese daher auch zunehmend innerhalb der Supply Chains verbreiten. Gegenwärtig werden sehr viele Standards für die unterschiedlichsten Anwendungsbereiche zur Verfügung gestellt. Unternehmen, die sich für eine B2B-Integration entscheiden, sehen sich mit einer schwer überschaubaren Vielfalt und einem erschwerten Entscheidungsprozess konfrontiert. Aufgrund dieser Gegebenheit hat das Fraunhofer Institut für Arbeitswissenschaft und Organisation (IAO) zu diesem Thema im Zeitraum Januar bis Februar 2003 eine schriftliche Befragung von ca Unter- 156 Vgl. Digital Foundry, S Vgl. Yankee Group 2004a, S Vgl. Yankee Group 2004a, S Vgl. Managing Automation

111 7. Anwendung und Verbreitung von RosettaNet nehmen der deutschen Wirtschaft durchgeführt. Ziel war die Erstellung einer Übersicht der aktuell eingesetzten bzw. geplanten e-business Standards. Befragte waren B2B-Entscheider jeder Funktionalebene aus Unternehmen jeglicher Bereiche des Industrie- und Dienstleistungsgewerbes. 160 Abbildung 27 zeigt eine Übersicht der hierbei festgestellten Ergebnisse. Abbildung 27: Verbreitung von e-business Standards (e-facts 2004, S.7) EDIFACT war mit 52% der im Jahr 2003 von den Unternehmen am häufigsten eingesetzte Standard. Weiterhin ist die EDI-Variante unter den Befragten der bekannteste Standard. cxml folgt mit 16% getätigten und weiteren 17% geplanten Implementierungen. Lediglich 7% gaben weiterhin an, ebxml für eine B2B-Kommunikation zu verwenden. 12% planen jedoch aktuell dessen Einsatz in ihrem Unternehmen. xcbl wird deutlich seltener im Vergleich zu den anderen Standards eingesetzt. Nur 3% der Unternehmen verwenden ihn bereits und 2% planen eine Implementierung. 161 Die Befragung zeigt für RosettaNet Anfang 2003 einen Bekanntheitsgrad von 38%. Davon verwenden nur 3% diesen Standard in ihrer Kommunikation mit Handelspartnern und 2% planen einen Einsatz. Bei dieser Studie und den resultierenden Daten ist jedoch zu beachten, dass diese 160 Vgl. IAO 2003, S An dieser Stelle wird auf eine Betrachtung der übrigen in der Abbildung gezeigten Standards verzichtet. Sie beziehen sich wie beispielsweise BMEcat auf die Definition eines standardisierten Katalogaustauschformates. Die in dieser Arbeit betrachteten Standards gehen über diesen Anwendungsbereich mit Spezifikationen für umfassende Prozesse weit hinaus. 100

112 7. Anwendung und Verbreitung von RosettaNet vor bereits 2 Jahren durchgeführt wurde. Gerade für den Bereich der Internet- Technologie ist dies aufgrund ständiger Veränderungen ein langer Zeitraum. Außerdem wurden gerade innerhalb der letzten zwei Jahre vom RosettaNet-Konsortium hohe Anstrengungen unternommen, die Verbreitung und Akzeptanz des Standards zu fördern. Die erhobenen Daten repräsentieren ebenfalls den gesamten Wirtschaftsraum. RosettaNet hingegen fokussierte anfangs die High-Tech-Branche und unternimmt erst seit kurzer Zeit Anstrengungen, die Anforderungen weiterer Industriebereiche zu unterstützen. Demzufolge ist das Ergebnis einer Bekanntheit von Rosetta- Net mit 38% der Befragten auch im Vergleich zu den anderen Standards ein noch relativ gutes Ergebnis. Eine neuere Studie der Digital Foundry aus dem Jahr 2004 zeigt die Verbreitung von e-business Standards für die High-Tech Branche. 162 Im Juli letzten Jahres wurden einige Unternehmen aus den Bereichen Unterhaltungselektronik (4%), Elektronikbauteile (13%), Halbleiterelektronik (22%), Softwarelösungen (22%), Telekommunikation (26%) und Logistik (9%) hinsichtlich ihrer Nutzung von B2B-Standards befragt. Die Verbreitung einzelner Standards lässt sich aus Abbildung 28 ersehen. Abbildung 28: Verbreitung in der High-Tech Branche (Digital Foundry 2004, S. 7) Hier zeigt sich ein völlig anderes Bild als in der vorherigen Darstellung. RosettaNet ist mit 34% an Implementierungen beinahe genauso weit verbreitet wie die EDI- Standards mit 37%. Die Befragten gaben ebenfalls an, sie schätzten RosettaNet nicht nur als einen stark wachsenden Standard ein, sondern sähen sich in den letzten 12 Monaten auch einem steigenden Druck durch Handelspartner ausgesetzt, diesen zu implementieren. 163 Anhand dieser Daten und den Vorhersagen der Yankee Group für eine zunehmende Verbreitung der XML-Standards gegenüber EDI, ist die gegenwärtige und zukünftige Bedeutsamkeit der RosettaNet-Spezifikationen für das B2B faktisch nachgewiesen. 7.2 Akzeptanz 162 Vgl. Digital Foundry 2004, S Vgl. Digital Foundry 2004, S

113 7. Anwendung und Verbreitung von RosettaNet Im Kontext der B2B-Integration bedeutet Akzeptanz die Bereitschaft potenzieller Anwender, eine neue Technologie anzunehmen. Dies setzt neben dem grundlegenden Verständnis der Spezifikationen und ihrer Zielsetzungen, auch die intensive Unterstützung der Anwender bei deren Implementierung voraus war für das RosettaNet-Konsortium ein ausschlaggebendes Jahr. Eine zunehmende weltweite Präsenz und zahlreiche produktive Implementierungen haben die Verbreitung und die Akzeptanz des Standards erhöht. Zahlreiche Milestone Programs haben nicht nur die Implementierung existierender Standards gefördert, sondern auch neue Spezifikationen für die Prozessbereiche Logistik, Finanzen und Service Management entwickelt. Das RosettaNet-Konsortium hat weltweit regionale Außenstellen. Sie helfen nicht nur die Bekanntheit des Standards zu erhöhen, sondern bieten auch einen effektiven Support für Implementierungsvorhaben. 164 Die Aufgabenschwerpunkte dieser Organisationen liegen im Wesentlichen in einem umfassenden Angebot an Schulungen sowie der Förderung eines gemeinsamen Netzwerkes. In vielen Fällen findet weiterhin eine enge Zusammenarbeit mit den örtlichen Regierungen statt, welche Empfehlungen für die Verwendung eines Standards aussprechen und so dessen Akzeptanz weiter fördern. RosettaNet-Organisationen befinden sich derzeit in ganz Amerika sowie Europa, Korea, Taiwan, Japan, China, Malaysia, Singapur und Australien. Durch die hierbei erzielte regionale Präsenz und Unterstützung der Unternehmen, kann RosettaNet die weitere Akzeptanz des Standards gewährleisten. Die Mitglieder von RosettaNet setzen sich ebenfalls aktiv für die Akzeptanz des Standards ein. So führen sie, wie im letzten Kapitel für das Unternehmen Intel beschrieben, zunehmend Implementierungen mit ihren Handelspartnern durch. Aus Berichten des RosettaNet-Councils geht hervor, dass die Anzahl von Partnerverbindungen innerhalb des letzten Jahres von 3000 auf 4400 angestiegen ist, was ein Wachstum von über 47% bedeutet. Diese Daten beschränken sich hierbei nur auf Implementierungen durch die Mitglieder des Global Councils. Partner und nichtregistrierte Anwender sind demnach in den aktuellen Daten nicht enthalten. 165 Hochrechnungen ergeben jedoch eine Schätzung von insgesamt 5000 Verbindungen. In Abbildung 29 wird die Anzahl der realisierten Partnerverbindungen im zeitlichen Verlauf seit dem Jahr der ersten Spezifikations-Veröffentlichungen dargestellt. 164 Vgl. RosettaNet 2005x, S Vgl. RosettaNet 2005x, S.5 102

114 7. Anwendung und Verbreitung von RosettaNet 2H'01 1H'02 Oct'02 Dec'02 Oct'03 Dec'03 Oct'04 Dec'04 (Projected) Source: Rosettanet Council Membrs Scorecards October Total Partner Connections World s leading known RosettaNet users* Sony (947 partner/pip connections) Intel (440) Molex (373) Cisco (262) HP (190) Nokia (200) Arrow (105) IBM (104) Exel Logistics (83) National Semiconductor (70) ST Microelectronics (63) Texas Instruments (60) Tyco Electronics (60) Sony has committed to ending EDI by 2004 and Intel by 2006 Abbildung 29: Entwicklung der Anzahl von Partnerverbindungen (IBM 2004a) In der Abbildung ist ebenfalls eine Übersicht der führenden Unternehmen mit RosettaNet-Implementierungen aufgeführt. Sony hat beispielsweise eine Kommunikation mit 947 PIP-Implementierungen realisiert. Das Unternehmen hat bereits Ende 2004 seine Kommunikation über EDI abgeschafft. Bei den bereits eingesetzten PIPs lässt sich eine deutliche Bevorzugung einzelner Prozessbereiche erkennen. So werden beinahe die Hälfte aller PIPs (42%) im Bereich des Auftragsmanagements eingesetzt. Aber auch der Finanzbereich (14%), die Planung (23%) und Logistik (13%) bilden einen hohen Anteil aktuell eingesetzter PIPs. Abbildung 30 zeigt die Prozessbereiche in einem Vergleich ihrer relativen Anteile produktiv eingesetzter PIPs. Abbildung 30: Adaption der PIPs (RosettaNet 2004x, S.5) 103