Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

30.05.1997 - 

Grenzen von Standardsoftware/EDI- und Internet: Studie nimmt Standardsoftware unter die Lupe

Zwischenbetriebliche Integration stößt an Grenzen

Die inner- und zwischenbetriebliche Integration boomt. Mit einem jährlichen Wachstum von 13 Prozent geht das Marktforschungsunternehmen Input im Jahr 2000 allein in Europa von einem Marktvolumen von annähernd einer Milliarde Dollar aus. EDI, Internet & Co stehen für Innovation, Kosteneinsparung, Image und die Chance, neue Märkte zu erschließen. Euphorisch werden die Prognosen der milliardenschweren wirtschaftlichen Auswirkungen von Online-Marketing, Vertrieb, Tracking- und Außendienst-Informationssystemen sowie Unternehmensintegration aufgenommen.

Viel zu oft mißverstehen Unternehmen EDI und Internet als Wundermittel gegen jede Art von Problem. Zweifellos bieten neue integrative Technologien Chancen - aber nur dann, wenn sie sinnvoll im Unternehmen und innerhalb der Wertschöpfungskette zwischen Lieferant, Handel, Industrie, Banken und Dienstleister eingesetzt werden.

Doch inwieweit sind die betrieblichen Anwendungssysteme auf die technischen Anforderungen von Internet, WWW und EDI vorbereitet? Und inwieweit erlauben sie die organisatorische Umsetzung von Strategien wie Efficient Consumer Response, virtuelle Unternehmung, Business-to-Business-Marketing, integrierten Geschäftsprozeßketten oder Online-Vertrieb?

Anbieter großer Standardanwendungspakete wie SAP, Oracle, Baan, Peoplesoft oder JD Edwards propagieren bereits seit Jahren die EDI-Fähigkeit ihrer Produkte und nun auch die Anbindung an das Internet beziehungsweise WWW.

Als ärgerlich erweist sich die Informationspolitik vieler Anbieter, die vielfach weder über brauchbare "Informationen" zu ihren EDI- und Internet-Schnittstellen noch über adäquate Ansprechpartner verfügen. SAP nutzt einmal mehr diese Chance, um sich mit Ankündigungen, Beschreibungen ihrer EDI- und Internet-Architektur sowie Strategiepapieren auch in diesen Bereichen als Trendsetter zu positionieren.

Untersuchungen des Lehrstuhls für Wirtschaftsinformatik von Rainer Thome und der Integratio GmbH in Würzburg sorgen für Ernüchterung, zeigen aber auch das emsige Treiben der Anbieter bei EDI, EDI via Internet sowie EDI und WWW auf.

EDI: Der klassische Integrationsansatz

Der klassische Integrationsansatz ist EDI, da es auf den automatisierten Datenaustausch zwischen Anwendungssystemen abzielt, die auf Standardaustauschformaten wie Edifact basieren. Betriebswirtschaftliche Anwendungen benötigen zusätzlich zu den traditionellen Schnittstellen der manuellen Erfassung am Terminal und dem Papierausdruck ein elektronisches Äquivalent, um einzelne Geschäftsnachrichten möglichst automatisiert zu ex- beziehungsweise zu importieren.

Die funktionale Aufteilung einer integrierten EDI-Lösung zeigt die EDI-Kette. Die Schnittstelle des Anwendungssystems umfaßt den Ex- und Import von Zwischenstrukturen (Flat Files), einen Selektionsmechanismus, der die Daten beim Export aus der Datenbasis in die Zwischenstruktur einstellt und interaktiv mit dem vorgeschalteten EDI-System austauscht. Eingehende Geschäftsdaten sind auf Fehler und Unstimmigkeiten zu prüfen, gegebenenfalls anzupassen und in die anwendungsinterne Vorgangsbearbeitung einzuschleusen.

So entstehen Integrationslösungen, die den wechselnden Anforderungen moderner Kooperationsstrategien genügen. Daneben wird aber auch klar, daß flexible EDI-Schnittstellen aufwendig zu konstruieren sind.

Die Realität sieht vielfach noch anders aus. Von den zur Zeit rund 200 Edifact-Nachrichtentypen werden durchschnittlich 4,4 Nachrichtentypen von den "EDI-fähigen" Anwendungssystemen unterstützt. Die technisch einfacher zu erstellende Ausgangsverarbeitung (Export) dominiert mit 5,1 Nachrichtentypen klar gegenüber der Eingangsverarbeitung (Import) mit 3,8 Nachrichtentypen. Während die Nachrichtentypen "Bestellung" (54 Prozent) und "Lieferabruf" (35 Prozent) in der Eingangsverarbeitung - aufgrund der häufigen Nutzung und ihres zeitkritischen Charakters - am meisten verbreitet sind, dominiert in der Ausgangsverarbeitung der Nachrichtentyp "Rechnung" (50 Prozent), gefolgt von den Nachrichten "Bestellung" und "Liefermeldung" mit jeweils 42 Prozent (siehe Abbildung 1).

Unterschiedlich gestalten sich die bereitgestellten EDI-Funktionen (siehe Abbildung 2). Der Verarbeitungsstatus einer EDI-Nachricht wird von einem Drittel der Anwendungen dargestellt. Aufgetretene Fehler zu protokollieren und anzuzeigen ist bei 58 Prozent der Systeme gegeben, jedoch nur 38 Prozent können eine Nachricht lesbar darstellen (Flat File). Als noch erweiterungsbedürftig zeigt sich die Dokumentation. So sind bei nur 54 Prozent der Anwendungen Installation und Konfiguration dokumentiert, wobei die Zwischenstruktur nur in jedem zweiten System beschrieben wird. Zuordnungshinweise für die Konvertierung der Zwischenstruktur in Edifact bieten 35 Prozent der Produkte. Ein Customizing der EDI-Schnittstelle wird von knapp der Hälfte der EDI-fähigen Anwendungssysteme unterstützt. Bei 62 Prozent erfolgen die Anpassungen durch den Anbieter.

Ein zentraler EDI-Vorteil resultiert aus der schnellen und automatisierten Weiterverarbeitung der Daten. Bei 58 Prozent der Anwendungen erfolgt eine direkte Verbuchung der eingegangenen Nachrichten mittels Batch Input.

Manuell läßt sich der Import bei 42 Prozent der Anwendungen durchführen. Externe Daten in die betreffende Erfassungsmaske des Anwendungssystems zu übernehmen, leisten 31 Prozent der Produkte. Der Sachbearbeiter kann so Anpassungen vornehmen und die Weiterverarbeitung anstoßen. Die Fähigkeit zur Umsetzung codierter Daten, zum Beispiel Artikelnummer und Datumformate, ist bei exakt der Hälfte aller Anwendungen gegeben, während sich immerhin acht Prozent der Produkte als Interactive-EDI-fähig bezeichnen.

Nach Aussagen der Anbieter stehen für 47 Prozent aller Produkte entweder integrierte EDI-Schnittstellen oder Zusatzmodule zur Verfügung, beziehungsweise lassen sich "problemlos" individuell realisieren. Sieht man von der Automobilindustrie als klassische EDI-Branche einmal ab, herrscht bei den Anbietern Aufbruchstimmung (siehe Abbildung auf Seite 60).

Zusatzmodule bilden Übergangslösung

Viele der am Markt verfügbaren Standard-SW-Pakete entstanden zu einem Zeitpunkt, als sich die Bedeutung des elektronischen Geschäftsdatenaustauschs noch nicht abschätzen ließ und faktisch keine Nachfrage bestand. EDI wurde weder im Datenmodell noch bei den angebotenen Funktionen berücksichtigt (siehe Abbildung 3).

Individualentwicklungen bilden hier die einzige Möglichkeit zur EDI-Fähigkeit. Aufgrund des Entwicklungsaufwands beschränken sich die betroffenen Unternehmen auf das Notwendigste und realisieren Minimallösungen für die benötigten Nachrichtentypen mit allen negativen Konsequenzen für die Erweiterung und Pflege dieser "Schnittstellen".

Mit EDI-Zusatzmodulen versuchen Anbieter, den Wandel im Anforderungsprofil nachzuvollziehen. So bietet beispielsweise SNI für sein seit 1976 auf dem Markt verfügbares Produkt "Comet" seit 1994 das EDI-Schnittstellenmodul "Comet-EDI" an.

Unterstützt werden hierbei nur die wichtigsten Nachrichtentypen mit eingeschränktem Datenumfang und einer starr vorgegebenen Strukturierung der Flat Files. Prozeß- und Verwaltungsfunktionalität konzentrieren sich auf das Wesentliche. Auch in diesen Fällen ist die Erweiterung und Pflege der Schnittstellen nicht unproblematisch und bedarf einer engen Zusammenarbeit mit dem Anbieter. EDI-Zusatzmodule bilden Übergangslösungen, um bestehende Installationen weiterbetreiben zu können.

Softwarehäuser wie SAP, Baan, Peoplesoft oder JD Edwards begannen bereits Anfang der 90er, in ihre Produkte verstärkt EDI-Schnittstellen zu integrieren. Neuentwicklungen wie R/3 oder Baan IV bieten dementsprechend eine aktive Integrationsstrategie, mit der bereits im Datenmodell und in den Standardfunktionen der elektronische Geschäftsdatenaustausch stattfindet.

SAP hat sich mit R/3 und der Idoc-Schnittstelle (Intermediate Document) und dem darauf aufbauenden ALE-Ansatz (Application Link Enabeling) zum Aufbau verteilter Systeme auf die Situation eingestellt. Als interessant zeichnet sich der Idoc-Ansatz ab, der eine klar definierte und dokumentierte Schnittstelle zu beliebigen EDI-Systemen darstellt. Unter Berücksichtigung von Format und Wertebereich der Datenfelder werden Geschäftsdokumente gezielt als Datei (Intermediate Document) für den EDI-Konverter bereitgestellt beziehungsweise verarbeitet.

Internet bietet mit Web-EDI eine Lösung

Durch mitgeführte Kontroll- und Statusinformationen lassen sich durchlaufene Verarbeitungszustände eindeutig identifizieren und verfolgen. Für die automatische Weiterverarbeitung liefert der Hersteller in der Nachrichtensteuerung Standardvorgänge mit, die durch Parametrisierung und Programmierung erweiterbar sind. Die Kopplung mit dem Workflow-Management erfolgt auf Basis der Konditionstechnik oder im Partnerstamm. Verstärkt wird dieser Trend durch die zunehmende Anzahl von Anwendern sowie EDI-Systemanbietern, die ihre Systeme von SAP zertifizieren lassen.

Die Zeit- und Kosteneinsparungen in der elektronischen Geschäftsabwicklung sind unbestritten, setzen jedoch die möglichst weitgehende Umstellung aller Transaktionen mit dem Partner sowie ein hohes Transaktionsvolumen voraus.

Für viele der kleineren Unternehmen stehen die bestehenden EDI-Einführungskosten (EDI-System, Anwendungsintegration, Absprachen) in keinem Verhältnis zu den durch sie erzielbaren Vorteilen. Hier findet sich auch die Hauptursache der zögerlichen EDI-Verbreitung in der Vergangenheit.

Unter dem Schlagwort Web-EDI bietet das Internet auch hier die "ideale" Lösung. Unternehmen stellen im WWW ihren Partnern elektronische Formulare, zum Beispiel für Bestellung, Lieferabruf, Anfragen, auf Basis von HTML und Java zur Verfügung. Mit einem beliebigen Browser lassen sich diese abrufen und bearbeiten. Die vom WWW-Server in einer Datenbank gespeicherten und an das EDI-System weitergeleiteten Geschäftsdaten können nun auch von den nicht EDI-fähigen Partnern über die EDI-Schnittstelle automatisch verarbeitet werden. Selbst spontane oder sehr seltene Geschäftstransaktionen kommen ohne langwierigen Koordinationsaufwand aus.

Für den Geschäftspartner, der selbst keine Anbindung an sein Anwendungssystem vornimmt, entfallen sämtliche EDI-Integrationsvorteile, jedoch auch die Investitions- und Betriebskosten klassischer EDI-Lösungen.

Web-EDI-Services werden zunehmend auch von Anbietern wie GE (Trade Web) oder Vantree angeboten. Erfahrungen existieren faktisch noch nicht, obwohl viele Unternehmen bereits Untersuchungen und Projekte hierzu betreiben.

Die dritte und von ihren Einsatzmöglichkeiten umfassendste Alternative ist der direkte Zugriff via Internet und WWW-Front-ends auf das Anwendungssystem des Partners. Standardisierte Datenaustauschformate, EDI-Systeme oder EDI-Schnittstellen sind nicht erforderlich. Der Abruf der aktuellen Bestands-, Produkt- und Lieferdaten ist ebenso möglich wie die Bestelldatenerfassung oder der Aufbau von Intranet- und Außendienstlösungen.

Anbieter wie Oracle, SAP oder Baan arbeiten intensiv an WWW-Schnittstellen zu ihren Anwendungssystemen. Strategische Partnerschaften sind dabei die Regel. So arbeitet Baan mit Sun Microsystems an der Erweiterung der Java Enterprice API, einer Schnittstelle für die Anwendungsprogrammierung in verteilten Systemen. Peoplesoft kooperiert mit BEA an Java-basierten Clients, die heruntergeladen werden und die die Transaktionsabwicklung mit dem Server verbessern (Java Online Transaction Processing). SAP seinerseits arbeitet mit Ixos an Internet-Transaktions-Servern, die über R/3 Internet Application Components auf BAPIs (definierte betriebswirtschaftliche Schnittstellen) im R/3 zugreifen (siehe Abbildung 4).

Aus dem Internet-Zugang ergeben sich für Unternehmen zwangsläufig Sicherheitsprobleme: angefangen bei der Zuverlässigkeit (Verlust von Daten) und Leistungsfähigkeit (Übertragungsbandbreiten, Zeitverhalten) bis hin zum Schutz der unternehmensinternen Daten und Anwendungen vor unerlaubtem Zugriff Dritter. Lösungen bieten Sicherheitstechnolo- gien wie die Datenverschlüsselung sowie Firewall-Konzepte.

Die Vorteile des direkten Zugriffs auf Anwendungssysteme mittels WWW sind offensichtlich. Unterschätzt werden bislang vielfach noch die organisatorischen Konsequenzen, die sich aus der Zusammenarbeit und dem Geschäftsabwicklungsprozeß mit Online-Partnern ergeben und ein völliges Überdenken bestehender Abwicklungsprozesse, sowohl inner- als auch zwischenbetrieblich erfordern. Auf Erfahrungen kann man bisher nicht zurückblicken. Die Leistungsfähigkeit der einzelnen WWW-Schnitt- stellen muß sich in der Praxis erst zeigen.

ANGEKLICKT

Bestehende betriebswirtschaftliche Anwendungssysteme müssen technisch und insbesondere organisatorisch für die Geschäftsabwicklung mit externen Partnern angepaßt, vielleicht sogar in Teilbereichen neu konzipiert werden. Im Bereich EDI existieren schon einige gute Lösungen, daneben gibt es aber auch viel Stückwerk, was den betroffenen Unternehmen einen hohen Aufwand und viel Geduld abverlangt. Das Internet mit seinen Möglichkeiten ist noch zu neu, als daß bereits ausgereifte Lösungen im Angebot wären. Bestehende Sicherheitsrisiken und Know-how-Defizite bremsen die Online-Euphorie und den Elan, die sich bietenden Möglichkeiten auch in die Tat umzusetzen.

*Rainer Scheckenbach ist Geschäftsführer der Integratio Gesellschaft für zwischenbetriebliche Integration und Electronic Commerce mbH in Würzburg.