|
|
|
|
|
|
Collaborative SCM in Branchen |
Diesen
Beitrag stellt zur Verfügung: 
Der folgenden Beitrag ist aus dem Buch "Collaborative SCM
in Branchen" von Rainer Schenkenbach und Alexander Zeier
entnommen.
Total Business Integration: Web Services - EAI - Middleware
Die Integration von Wertschöpfungsketten - unabhängig davon, ob es sich hierbei um die kooperative Absatz-, Logistikplanung, Financial SCM oder CRM-Ansätze handelt - bedingt die Integration der in den Unternehmen bestehenden Anwendungssysteme. Zum Leidwesen aller sorgt die inflationäre Nutzung von Schlagworten wie B2Bi, TBI, EAI, A2A, MOM, UDDI, SOAP, Data Cleansing oder Web Services mehr für Verwirrung als für Klarheit. Ohne an dieser Stelle die Sinnhaftigkeit der direkten Übertragbarkeit (komplexer) interner SCM-Prozesse auf unternehmensübergreifende Integrationsarchitekturen oder die Durchsetzbarkeit illusorischer Informationsanforderungen bei Partnern zu diskutieren, sollte generell zwischen innerbetrieblichen und zwischenbetrieblichen Integrationsanforderungen unterschieden werden.
Beiden gemein sind die folgenden Anforderungen:
- Kompatibilität der auszutauschenden Daten
- Konnektierbarkeit der Prozesse
- Kompatibilität der Business-Logik bzw. ERP-Schnittstelle
Die innerbetrieblichen Anforderungen wurden in der Vergangenheit gerne sehr technisch anhand konkreter Integrationsaufgaben auf Bit- und Byte-Ebene diskutiert. Dem Thema Middleware war dadurch jede Chance genommen, auf Management-Ebene als Instrument für Geschäftsprozesse wahrgenommen zu werden. Anders zeigt sich die Situation zwischenbetrieblich, wo aufgrund fehlender Erfahrungen recht ungestüm über Standards, Architekturen und Strategien philosophiert wird. Anstrengungen, Geschäftsprozesse bzw. Daten über Anwendungs- und Unternehmensgrenzen hinweg zu integrieren, sind keineswegs neu. Leidvolle Erfahrungen der letzten Jahrzehnte in den Bereichen Middleware (innerbetrieblich) und EDI (zwischenbetrieblich) belegen dies, wobei selbst nach mittlerweile 30 Jahren noch erhebliche Verbesserungspotenziale bestehen. Hier einige Äußerungen zu den Investitionserwartungen für Business-to-Business-Integration in der Wirtschaft:
"Application integration is a rapidly developing technology and market. The typical Global 2000 corporation has over 49 enterprise applications and spends 25-33 % of its IT budget on application interoperability solutions." [META GROUP]
"Application packages can provide at most 30 % of the functionality required in Fortune 1000 Enterprises." [GARTNER GROUP]
"40-60 % of IS development and maintenance costs go on integration." [GARTNER GROUP]
Aussagen aus der Wirtschaft belegen die der Integration zugemessene Bedeutung sowie das Wissen darum, erst am Anfang zu stehen. Umso wichtiger ist der Blick auf bestehende Standards, Prozesse und Technologien, um Fehler zu vermeiden und schneller zu akzeptablen Lösungen zu gelangen - insbesondere, da Unternehmen bereits Milliardenbeträge in klassische Technologien investiert haben, die weder technologisch noch ökonomisch einfach abgelöst werden können.
Integration mit Tradition
Bereits Ende der Sechzigerjahre wurde begonnen, an der Idee eines elektronisch integrierten Geschäftsdatenaustauschs für die Automation der kostenintensiven und fehleranfälligen "Schnittstelle" Mensch zu arbeiten. Neben den anfänglich massiven technischen Kommunikationsproblemen wurde die Notwendigkeit von Standards zur Minimierung des Absprache- und Implementierungsaufwands schnell offensichtlich.
Nach 20 Jahren Entwicklung und mühseligen Verhandlungen war man sicher, unter dem Schlagwort EDI (Electronic Data Interchange) standardisierte Geschäftsdatenaustauschformate wie EDIFACT (international, branchenneutral), VDA (Deutschland, Automotive), SEDAS (Deutschland, Handel) oder ANSI X12 (USA, branchenneutral) koordiniert und ausgearbeitet zu haben, die zwar untereinander inkompatibel waren, aber zumindest für die jeweiligen Branchen und Interessengruppen eine spürbare Erleichterung brachten. Die Konnektierbarkeit der Prozesse erfolgte auf der Basis simpler Batch-Interaktionslogiken mit standardisierten Kommunikationsprotokollen wie X.400 oder Odette File Transfer (OFTP), die zusammen mit Format- bzw. EDI-Konvertern Ende der Achtzigerjahre die ersten Standardtools ergaben. Value Added Services, d. h. Mehrwertdienstanbieter, stellten für sich genommen proprietäre Kommunikationsservices bereit, die jedoch die einzige Möglichkeit darstellten, die Kluft zwischen den inkompatiblen nationalen Netzen zu schließen.
Die erforderliche Business-Logik zur Realisierung von Geschäftsprozessen zwischen den ERP-Systemen beschränkte sich auf vergleichsweise simple batchorientierte Import-/Exportschnittstellen, um klassische Geschäftsdokumente wie Rechnungen, Bestellungen oder Lieferabrufe als Datei erzeugen bzw. verarbeiten zu können. Aspekte wie Eskalationsmanagement, Prozess-Controlling oder die semantische Prüfung der Transaktionsplausibilität waren damals kein Thema.
Unabhängig hiervon entstand in den Achtzigerjahren auch innerbetrieblich der Bedarf, heterogene Systemlandschaften zu integrieren. Die Abkehr von isolierten Bereichsanwendungen und die Zuwendung hin zu integrierten Anwendungslandschaften wurde getrieben von Initiativen wie CIM (Computer Integrated Manufactoring), Workflow-Management und dem Controlling zur bereichsübergreifenden Bewertung von Transaktionen, Finanzströmen sowie einer strategischen Geschäftsplanung.
Unter dem Schlagwort Middleware entstanden Integrationswerkzeuge, deren primäre Aufgabe es war, heterogene Systemlandschaften technisch zu verbinden und transaktionsgesichert Daten auszutauschen. Bis heute ist der messageorientierte Datentransfer MOM (Message Oriented Middleware) dominant. Der Bedarf an Standards war gering, da die Anwendungen zum einen hochgradig individualisiert waren und zum anderen die Probleme im eigenen Unternehmen durch Individualentwicklungen schneller realisiert wurden - zumindest was Datenformate und Anwendungsschnittstellen betraf.
Mit dem Aufkommen von Data Warehouses entwickelten sich in den Neunzigerjahren ETL-(Extraction-, Translation-, Loading-)Tools, deren Fokus im Gegensatz zur Middleware nicht auf dem batchorientierten Im- und Export von Transaktionsdaten zwischen Applikationen lag, sondern in der zeitnahen Zusammenführung (dem Auslesen) von Daten aus unterschiedlichsten Datenquellen und Anwendungen in einen Datenpool.
Diese vormals völlig unabhängigen Disziplinen wachsen durch die neuen Anforderungen des C-Business zusammen. Die "neuen" Integrationsstrategien EAI und Web Services lassen sich als Weiterentwicklungen interpretieren, wobei EAI seine Wurzeln in der Middleware bzw. ETL und Web Services im EDI-Umfeld hat.
Kommunizieren - Verstehen - Handeln
Die wirtschaftliche Zusammenarbeit in Industrie und Handel hat sich bereits so stark verändert, dass nicht nur traditionelle Geschäftsprozesse auf der Basis des Internets elektronifiziert werden. Entstanden sind neuartige Business-Modelle im Bereich der elektronischen Marktplätze (B2B-Martplätze, Portals), der Wertschöpfungsketten (SCM, Procurement) sowie der Kundenservices (ECR). Auslöser waren die Fantasien, die in der zweiten Hälfte der Neunzigerjahre durch den Internet-Boom und die sich entwickelnden technischen Möglichkeiten (Internet, WWW, XML, Java) zu Business-Modellen herangereift sind (GARTNER GROUP, siehe
folgende Abbildung).
Abbildung: RoI bei der inner- und zwischenbetrieblichen Integration
Diese evolutionären und damit für das wirtschaftliche Überleben essenziellen Geschäftsstrategien setzen eine hochaktuelle Informationstransparenz und Transaktionsabwicklung voraus, die über die Unternehmensgrenzen hinweg gesichert sein müssen. Der bloße Austausch von Daten ist unzureichend, wenn die Gegenseite diese nicht automatisch interpretieren und weiterverarbeiten kann.
Diese neuartige Form der Abwicklung und auch völlig neue Geschäftsmodelle bedingen zudem standardisierte, akzeptierte Prozesse und Interaktionsmodelle. Ebenso sind Methoden erforderlich, mit deren Hilfe die notwendigen Anpassungen oder Erweiterungen effektiv ausgehandelt und implementiert werden können.
Die Aufgabenstellung umfasst hierbei:
- Technischen Transfer von Daten (Protokolle, Packaging, Codierung)
- Semantische Standards (Integrationsdatenmodelle, Produktkataloge, Syntax)
- Prozess- und Interaktionsschemata (Secure Transaction Loops, Prozessmodelle)
- Methoden zur Definition von Standards bzw. deren Spezifikation im Rahmen von Implementationen (Frameworks)
So ist beispielsweise der XML-Standard als hochflexibler "Werkzeugkasten" nicht unmittelbar für die Definition von Daten- und Darstellungsformaten nutzbar. Es fehlen die allgemein anerkannten und durchdachten Spezifikationen, die z. B. vorgeben, wie exakt eine Information (z. B. Produktkatalog, Rechnung) mithilfe von XML (Namespaces, Dokumentensyntax) darzustellen ist. Gleiches gilt für Kommunikationsprotokolle wie TCP/IP, HTTP oder Packaging-Mechanismen wie MIME, die zu generisch sind, um die spezifischen Anforderungen wie Security (Authentifikation, Nachvollziehbarkeit, Vertraulichkeit), Routing (ERP-Weiterleitung) und Transaktionssicherheit zu unterstützen. Klassische Formatstandards wie EDIFACT oder ANSI X12-Interaktionsmodelle und Systeme wie EDI genügen nicht mehr den wachsenden Anforderungen der Realtime-Verarbeitung sowie der Anforderung, unterschiedlichsten Datenarten und -volumina gerecht zu werden. Auch erweisen sie sich als zu proprietär, um an die neuen Technologien angepasst werden zu können (META GROUP, siehe
folgende Abbildung).
Abbildung: Investitionserwartungen für Business-to-Business-Integration
Strategien, Technologien und Erfahrungswerte noch vor kurzem eigenständiger Fachdisziplinen sind gezwungen zu migrieren. Hierzu zählen u. a. die Folgenden:
- Middleware (Komponentenkopplung, Plattformkopplung, Routing, Load Balancing, innerbetriebliche
Transaktionsabwicklung
- ETL (Extraction, Translation, Loading)
- Processware (Prozessorganisation, Prozess- und Interaktionssicherung, Bedienung verschiedener Datenquellen)
- EDI (Datentransformation, Semantische Datenformatstandards, messageorientierte ERP-Schnittstellen, rechtliche Geschäftssicherung)
- Communicationware (Formular- und Integrationsschnittstellen, Enveloping, Transferprotokolle, Sicherheitstechnologien, Routing)
Enterprise Application Integration und Web Services stellen zurzeit die dominanten Integrationsansätze dar. Während EAI im Wesentlichen Elemente aus den Bereichen Middleware, Processware und Communicationware zu einer innerbetrieblichen Integrationsarchitektur beinhaltet, stehen bei Web Services Standards zur zwischenbetrieblichen Interaktion im Vordergrund. Standardisierungsgremien und Interessengruppen wie ebXML, BizTalk oder RosettaNet sind angetreten, um diese Bedarfe mit Produkten, Frameworks, Prozessmodellen und Datenformatstandards zu schließen. Die Aktivitäten erweisen sich bislang noch als wenig koordiniert, sodass konkurrierende Ansätze (z.B. ebXML, RosettaNet) keine Seltenheit darstellen.
Anwendungsbereiche der Business-to-Business-Integration
Mittlerweile wurde eine Vielzahl möglicher Einsatzszenarios für alle Phasen der Geschäftsabwicklung innerhalb der Wertschöpfungskette entwickelt. Es zeigt sich, dass bei den bestehenden Kommunikations- und Integrationsansätzen erhebliche Defizite bei der Interoperabilität (z. B. proprietäre Packaging- oder Formatierungsmethoden) sowie bei der Erfüllung von betriebswirtschaftlichen Grundvoraussetzungen (wie etwa Geschäftssicherheit, Prozess- und Interaktionsstandards) bestehen (siehe
folgende Tabelle).
|
Supply Chain Management (SCM) |
Austausch von Logistik-, Planungs- und Steuerungsinformationen zwischen Lieferanten, Kunden und Logistikdienstleistern |
|
Efficient Consumer Response (ECR) |
Austausch von Abverkaufszahlen, Forecast-, Lagerstands- und Produktionsdaten zwischen Handel und den vorgelagerten Stufen |
|
E-Procurement |
Austausch von Produkt-, Preis-, Verfügbarkeits- und Bestelldaten zwischen Mitarbeitern sowie Lieferanten |
|
Customer Relationship Management (CRM)/Sales Force Automation (SFA) |
Austausch von Kundendaten, Angeboten, Auftragsdaten, Korrespondenz und Produktinfos für den Vertrieb/Außendienst |
|
Marktplätze/Portale |
Austausch von Unternehmens-, Bedarfs- und Verfügbarkeitsdaten sowie diverser Service- und Finanzdienste |
|
Geschäftsdatenaustausch (EDI, XML/EDI, WebEDI) |
Austausch aller Formen von Geschäftsdaten für die Transaktionsabwicklung und -steuerung |
|
Systemkopplung/Data Warehouse |
Datenaustausch, -sammlung und -aufbereitung zwischen heterogenen System- und Applikationswelten |
Tabelle: Anwendungsbereiche der Business-to-Business-Integration
Als problematisch erweisen sich weniger die Basistechnologien wie TCP/IP, MIME, HTTP, PKI oder XML als vielmehr deren Zusammenspiel und Umsetzung in implementierbare Produkte und Lösungsszenarios (siehe Abbildung 1.7). Entwicklungen werden zurzeit in folgenden Bereichen betrieben:
"Technische" Standards
Definition und Realisierung von "höheren technischen Services" (z.B. UDDI, SOAP, WSDL)
Frameworks
Methodiken für die Vorgehensweise von Definitions- und Abstimmungsprozessen
Business-Standards
- Geschäftsprozesse
- Interaktionsmechanismen
- Datenformate für konkrete betriebswirtschaftliche Problemstellungen (z. B. Procurement) oder Branchenanforderungen (z. B. Hightech-Industrie)
Abbildung: Zusammenhang zwischen verschiedenen Technologien und Initiativen Abgrenzung von Enterprise Application Integration und Business-to-Business-Integration
Es hat sich mittlerweile eingebürgert, dass Trendthemen und Schlagworte, wie Business-to-Business-Integration (z. B. Web Services, EDI, Katalog-/Datenformate) und Enterprise Application Integration (z. B. Middleware, ETL, MOM), sehr freizügig in der Presse und im Marketing genutzt werden. Dazu gehören kreative Wortschöpfungen und die falsche bzw. platte Nutzung von Fachbegriffen als "Buzz-Word". Im Folgenden werden nun die beiden großen Bereiche EAI und B2Bi kurz erläutert und mit ihren Aufgabengebieten einander gegenüber gestellt (siehe auch Kapitel
4 in dem Buch "Collaborative SCM in Branchen"). EAI - Enterprise Application Integration
Das Schlagwort EAI steht für Enterprise Application Integration. Umschrieben werden damit Methoden, Strategien sowie Technologien zur Kopplung von Anwendungssystemen innerhalb eines Unternehmens. Typische Einsatzgebiete sind die Kopplung heteroger bzw. verteilt organisierter Systemlandschaften oder die Anbindung sogenannter E-Business-Anwendungen, etwa E-Procurement-, EDI-, SCM- oder CRM-Systeme (siehe
folgende Abbildung). 
Abbildung: Anwendungsbereiche von EAI 
Abbildung:
Gegenüberstellung von inner- und zwischenbetrieblichen Integrationsansätzen
Als Aufgabenschwerpunkt ist die technisch-organisatorische Anbindung der betrieblichen Anwendungssysteme auf sehr hohem Niveau zu erkennen. Zu nennen sind beispielsweise synchrone und asynchrone Kommunikationsarchitekturen, Transaktionsüberwachung, Interface Definitions und Connectoren, Object-Management-Architekturen sowie Unterstützungs-Tools wie Prozessdesign oder komplexere
Format-Mappings.
EAI ist eine Weiterentwicklung klassischer Middleware-Ansätze, die meist batch-/messageorientiert auf die technische Kopplung unterschiedlicher Rechnerplattformen ausgelegt sind. EAI erweitert diesen Ansatz um die Bereiche Datentransformation, Prozessmanagement sowie die Anbindung nach außen orientierter
Systeme. Neben Middleware- finden sich auch ETL-(Extraction-, Transformation-, Loading-) Funktionen. Kennzeichnend sind die nur lesenden Zugriffe auf verschiedene Datenquellen bzw. Anwendungen sowie die Zusammenführung der Informationen. Einsatzgebiete sind insbesondere Data-Warehouse- bzw. Business-Intelligence-Ansätze. Die Kommunikation erfolgt synchron, d. h., die Anwendung oder Datenbank reagiert unmittelbar auf die Anfrage und liefert ein Ergebnis. Müssen Daten verbucht, d. h. funktional vom System prozessiert werden, dominieren asynchrone, d. h. messageorientierte Kommunikationsstrategien. Ursache ist die enorme Komplexität zur Prozessierung synchroner Anfragen: Die Funktionslogik der Anwendungen ist in der Regel nicht für synchrone, externe Anfragen und Transaktionen (z. B. Zeitverhalten, Performance, Datenintegrität) ausgelegt. B2Bi - Business-to-Business-Integration
Demgegenüber liegt der Schwerpunkt von B2Bi auf der Organisation und Abwicklung zwischenbetrieblicher Wertschöpfungsprozesse. Hier stehen nicht die Basistechnologien im Vordergrund, sondern deren Kombination und Ausgestaltung zu "höheren Services". Hinzu kommen Frameworks mit Methoden zur Definition und Implementierung dieser Services. Hierzu zählen:
- Automatisiert interpretierbare und standardisierte Geschäftsnachrichten (EDIFACT, XML/EDI)
- (Rechts-)Sicherheit der Kommunikation (PKI, SOAP, E-Business-Gesetzte)
- Verbindlichkeit von elektronischen Transaktionen (elektronische Signatur, Secure Transaction Loops)
- Vorgehensmodelle zur Aushandlung von technischen, organisatorischen und wirtschaftlich-rechtlichen Vereinbarungen (Business Agreements)
Die Grundlage der B2Bi bilden zurzeit EDI aufgrund der bestehenden installierten Basis in der Wirtschaft sowie zukünftig die neu entstehenden Web-Service-Infrastrukturen. Die Ausgestaltung der Letztgenannten steckt noch in den Kinderschuhen, da erst "Basistechnologien" wie der Verzeichnisdienst UDDI (Vorgaben zur Erstellung), WSDL und WSFL (Dienste und Schnittstellenbeschreibungen) sowie SOAP (messageorientierter Kommunikationsstandard) bereitstehen. B2Bi kann nicht losgelöst von EAI betrachtet werden. Die Grenzen sind schwimmend - insbesondere, da viele der ehemals rein auf Middleware spezialisierten Anbieter ihre Produkte auf die unternehmensübergreifende Integrationsaufgabenstellung erweitern. In einer B2Bi-Aufgabenstellung bildet EAI den "Connector" zu den betrieblichen Anwendungssystemen (siehe
folgedneTabelle).
|
Kriterium |
Bedeutung für EAI |
Bedeutung für B2Bi |
|
Aufgabenfokus
|
Technische ERP-Anbindung/-Kopplung
|
Betriebswirtschaftlich-organisatorische Abwicklung von Geschäftstransaktionen
|
|
Geografischer Integrationsfokus
|
Innerbetrieblich
|
Zwischenbetrieblich
|
|
Kopplung unterschiedlicher
IT-Plattformen
|
Hoch
|
Gering
|
|
Software-technische Adaption
|
Hoch
|
Mittel
|
|
ERP-Konnektoren
|
Zentraler Bestandteil
|
Externe EAI-Produkte
|
|
Integrations- und Web-Kommunikation
|
Hoch
|
Mittel
|
|
Prozesse
|
Hoch (IT-Transaktionen)
|
Hoch (Geschäftsprozesse)
|
|
Realtime Information Broker
|
Hoch
|
Mittel
|
|
Transaktionsfähigkeit
|
Hoch
|
Mittel
|
|
Komplexität der Transaktionsabwicklung
|
Hoch
|
Gering
|
|
Standards
|
Gering
|
Hoch
|
|
Bedeutung technischer Standards/Protokolle
|
Hoch
|
Hoch, Weiterentwicklung zu höheren Services
|
|
Datenformatstandards
|
Gering
|
Hoch
|
|
Kommunikationsstandards
|
Gering
|
Hoch
|
|
Interface-Standards
|
Mittel (bedingt verfügbar)
|
Mittel (in Entwicklung)
|
|
Security
|
Mittel
|
Hoch
|
|
Kommunikationssicherheit
|
Gering
|
Hoch
|
|
Authentizität/Autorisation
|
Gering
|
Hoch
|
|
Datenintegrität
|
Hoch
|
Hoch
|
|
Datenqualität
|
Hoch
|
Hoch
|
|
Interaktionssicherheit
|
Transaktionssicherheit
|
Prozessintegrität
|
|
Zeitverhalten
|
Mittel bis hoch
|
Mittel
|
|
Rechtssicherheit
|
Gering
|
Hoch
|
|
Business Agreements/Rechtsicherheit (Archivierung, elektronische Signatur)
|
Gering
|
Hoch
|
|
Gesetzgebung
|
Gering
|
Hoch
|
|
Partner Agreements
|
Gering
|
Hoch
|
|
Produktverfügbarkeit
|
Mittel
|
Mittel
|
|
Verfügbares Know-how/Erfahrungen
|
Mittel
|
Mittel
|
Tabelle: Gegenüberstellung der wesentlichen Anforderungsprofile von EAI und B2Bi
|
|
