Daten-, Funktions- und Prozeß-Standardsfür Virtuelle Unternehmen- strategische Überlegungen

Universität Leipzig, Institut für Wirtschaftsinformatik Universität Erlangen-Nürnberg, Bereich Wirtschaftsinformatik I

Arbeitspapier der Reihe

„Informations- und Kommunikationssysteme als Gestaltungselement Virtueller Unternehmen“

Nr. 12/1997

Herausgeber Prof. Dr. Dieter Ehrenberg

Prof. Dr. Joachim Griese Prof. Dr. Dr. h.c. mult. Peter Mertens Wolfgang Faisst und Momme Stürken

Daten-, Funktions- und Prozeß-Standards für Virtuelle Unternehmen

- strategische Überlegungen

Engehaldenstraße 8, CH-3012 Bern, Tel. +41/31/631-4785, FAX +41/31/631-4682 Marschnerstraße 31, D-04109 Leipzig, Tel. +49/341/4941-281, FAX +49/341/476633 Lange Gasse 20, D-90403 Nürnberg, Tel. +49/911/5302-284, FAX +49/911/536634

Wolfgang Faisst und Momme Stürken: Daten-, Funktions- und Prozeß-Standards für Virtuelle Unternehmen - strategische Überlegungen.^*) Arbeitspapier der Reihe „Informations- und Kommunikationssysteme als Gestaltungselement Virtueller Unternehmen“ Nr. 12/1997. Institut für Wirtschaftsinformatik der Universität Bern, Institut für Wirtschaftsinformatik der Universität Leipzig, Bereich Wirtschaftsinformatik I der Universität Erlangen-Nürnberg, Bern Leipzig Nürnberg 1997.

*) Der vorliegende Beitrag basiert auf Erkenntnissen aus dem Forschungsprojekt „Informations- und Kommunikations- systeme als Gestaltungselement Virtueller Unternehmen“, welches von der DFG unter Me 241/16-1 und Eh 127/3-1 gefördert wird. Beteiligte Partner sind der Bereich Wirtschaftsinformatik I der Universität Erlangen-Nürnberg (Prof. Dr. P. Mertens), das Institut für Wirtschaftsinformatik der Universität Leipzig (Prof. Dr. D. Ehrenberg) und assoziiert das Institut für Wirtschaftsinformatik der Universität Bern in der Schweiz (Prof. Dr. J. Griese).

Zusammenfassung

Der Bericht erörtert Möglichkeiten und Grenzen des Einsatzes von Daten-, Funktions- und Prozeß-Standards zur flexiblen Kopplung von Partnern zu einem Virtuellen Unternehmen (VU). Zunächst werden spezifische Anfor- derungen von VU hinsichtlich Standards präsentiert. Für die Verbindung von Anwendungssystemen gilt es, ver- schiedene Verfahren der Vergabe, unterschiedliche Geltungsbereiche und Art und Weise der Spezifikation von Standards zu beachten. Weiterhin sind der gegenwärtige Stand der Schnittstellenentwicklung und moderne Stan- dardisierungsinitiativen wie CALS zu berücksichtigen. Anschließend beschreibt der Beitrag exemplarisch Felder der Normierung, wobei dem Konstruktionsbereich besondere Bedeutung zukommt. Aber auch der Dokumenten- austausch, die technische Dokumentation, das Übertragen kaufmännischer Daten, der Planungsdatenaustausch und das Workflow Management werden untersucht. Zudem sind Standardabläufe, -verträge und -geschäftsprakti- ken für schnelle Zusammenschlüsse von Unternehmen von Interesse. Schließlich werden Vor- und Nachteile von Standards für VU diskutiert und auf die Frage eingegangen, welche Strategien zum Einsatz von Normen ein Un- ternehmen wählen sollte.

Schlüsselbegriffe: Virtuelle Unternehmen, Standards, Normierung, flexible Kopplung, zwischenbetrieb- liche Integration

Abstract

This report discusses the possibilities and borders of data, function, and process standards for flexible coupling of partners to a virtual enterprise (VE). First, we present specific requirements with regard to VE. Connecting appli- cation systems, one has to care for the various methods, different fields, and ways of specifying standards.

Furthermore, the current state of developing interfaces and modern standardization initiatives like CALS are mentioned. Following this, the paper describes representative fields of standardization with special emphasis on the construction area. But also document exchange, technical documentation, and transmission of business and planning data are analysed as well as workflow management. Standard processes, contracts, and business rules play an important role for rapid formation of a VE. Finally, we discuss pros and cons of standards for VE, and examine the question what strategies a company may choose for the use of standards.

Key Words: Virtual Enterprise, Standards, Standardization, Flexible Coupling, Cross-enterprise Integration

Inhaltsverzeichnis

1 Motivation 4

2 Spezifische Anforderungen von Virtuellen Unternehmen hinsichtlich Standards 5

2.1 Flexible Kopplung 5

2.2 Prototypische IV-Infrastruktur 6

3 Stand der Standardisierungstechnik 8

3.1 Unterschiedliche Philosophien der Vorgabe von Standards 8

3.1.1 Formale vs. Defacto-Standards 8

3.1.2 Branchenübergreifende vs. Branchenstandards 9

3.1.3 Austauschformate vs. Spezifikationssprachen 10

3.2 Stand der Schnittstellenentwicklung 12

3.3 CALS als moderne Standardisierungsinitative 13

4 Exemplarische Felder der Standardisierung 15

4.1 Konstruktionsbereich 15

4.2 Dokumentenaustausch 17

4.3 Technische Dokumentation 18

4.4 EDIFACT 19

4.5 Electronic Planning Interchange 19

4.6 Workflow Management Coalition 19

4.7 Standardabläufe, -verträge und -geschäftspraktiken 20

4.8 CORBA 21

4.9 Internet-Banking 21

5 Vor- und Nachteile von Standards 22

5.1 Vorteile 22

5.2 Nachteile 25

6 Strategien zum Einsatz von Standards im Virtuellen Unternehmen 27

7 Ausblick 28

8 Literatur 29

1 Motivation

Die besondere Herausforderung Virtueller Unternehmen (VU) im „klassischen“ Felde der zwischen- betrieblichen Integration liegt in der Notwendigkeit, die Informationsflüsse nicht nur an die momen- tanen Geschäftspartner, sondern möglichst flexibel an wechselnde Systemlandschaften potentieller Partner anzupassen. Die Fähigkeit zum raschen Auf-, Um- und Abbau der zwischenbetrieblichen In- formationsverarbeitung ist somit eine Schlüsselkomponente, die über den Erfolg einer VU-Idee ent- scheidet (s. Abschnitt 2.1).¹

Doch zeigen die vermehrten Kooperationsprojekte (als strategische Alternative) gegenwärtig in aller Deutlichkeit die Schwächen der betrieblichen Informationsverarbeitung auf, die eine temporäre Inte- gration ohne zeitraubende Abstimmungsprozesse und Schnittstellendefinitionen massiv behindern. So ist die meist historisch gewachsene Informationsstruktur heutiger Unternehmen typischerweise durch vielfältige Insellösungen mit größtenteils isolierten Datenbeständen geprägt. Zwar werden Teilabläufe sehr effizient durch Anwendungsprogramme abgedeckt, doch fehlt es an geeigneten Schnittstellen zur Integration der einzelnen (über)betrieblichen Prozeßabläufe. Oft zitierte Probleme sind etwa die Mehrfacheingabe und -identifikation von Daten und Dokumenten, redundante und inkonsistente Da- tenverwaltungen, unzureichende Transparenz bei der Ablauforganisation, zunehmende Vielfalt der eingesetzten (Standard-)Software mit in der Regel proprietären Formaten oder mangelnde Unterstüt- zung von systemübergreifenden Kontroll- und Steuerungsaktivitäten (vgl. [AbLL96, S.1], [AnKa96, S. E7], [Gron96, S. E24], [Eign96, S. 395], [O.V.96, S. 25], [Lebe95, S. 43], [FVIN95, S. 9-11]).

Die Ursachen für die genannten Probleme und Hindernisse werden gemeinhin im Fehlen einheitlicher Datenformate und -strukturen sowie der dadurch bedingten unterschiedlichen Interpretationen der ausgetauschten Informationen gesehen. Die Komplexität virtueller Strukturen ist nur dann zu über- winden, wenn die verschiedenen Anwendungssysteme ihre Ergebnisse nicht mehr über proprietäre externe Formate austauschen, die nur von homogenen Systemen gelesen werden können, sondern über offene, neutrale Schnittstellen. Dies setzt (international) anerkannte Standards für das Bereitstellen, Aufbereiten, Verdichten und Verarbeiten von Informationen voraus, die den Anforderungen der unter- schiedlichen Teilprozesse des Produktlebenszyklus genauso gerecht werden wie denen des zwischen- betrieblichen Datenaustausches. Angesichts der bereits in den 80er Jahren einsetzenden vielfältigen Bemühungen einer Schnittstellennormierung, die eine Fülle von Standards hervorgebracht hat, stellt sich die Frage, auf welche Formate und Strukturen ein VU heute zurückgreifen soll.

Als ein Schwerpunkt der Untersuchung wurde der Konstruktionsbereich gewählt. Zum einen, weil hier der Ursprung der Bemühungen um überbetriebliche Standards liegt (s. Abschnitt 4.1). Zum ande- ren zeichnet sich dieser Anwendungsbereich durch eine ausgesprochen hohe Komplexität aus, wes- halb die dortigen Bemühungen als Vorbild auch für andere Zweige des Virtuellen Unternehmens her- angezogen werden können. Komplexitätsfördernd im Hinblick auf die Informationsverarbeitung (IV) wirkt hierbei nicht nur die verstärkte Verbreitung von Rechnern im Konstruktionsbereich selbst, son- dern auch der zunehmende Einsatz von datenerzeugenden CAx-Systemen in den nachgelagerten Sta- dien des Produktlebenslaufes - verbunden mit dem Wunsch, den konsistenten Austausch dieses ge- waltigen (Produkt-) Datenvolumens über den gesamten Lebenszyklus hinweg sicherzustellen.

1 In dem parallel zur Untersuchung Virtueller Unternehmen laufenden Projekt CESH (Competence in Electronic Shopping) am Bayerischen Forschungszentrum für Wissensbasierte Systeme (FORWISS), das auf die Realisierung einer Electronic Shopping Mall mit umfassenden integrierenden Funktionen abzielt (vgl. [MeSc96]), stellt sich eine ähnliche Problematik: Man hat es mit den unterschiedlichsten, gewachsenen IV-Strukturen der (oft wechselnden) Anbieter zu tun.

Die verschiedenartigen miteinander zu verbindenden Angebotssysteme weisen i.d.R. proprietäre Daten- und Dateiformate auf, die einen konsistenten anwendungs- und anbieterübergreifenden Informationsaustausch nicht oder nur beschränkt erlauben und die Einbindung der Shopping-Anwendungen in unternehmensübergreifende Prozeßketten erschweren. In dem Projekt sollen die Voraussetzungen geschaffen werden, um die in der Mall erzeugten Informationen in angrenzende Systeme - insbesondere der rechnergestützten Konstruktion und Planung - zu übernehmen und umgekehrt (vgl. [Stür97]).

2 Spezifische Anforderungen von Virtuellen Unternehmen hinsichtlich Standards

2.1 Flexible Kopplung

Beim Gründen eines VU muß es das Ziel sein, eine schnelle Kopplung zu erreichen und dabei die Freiheit zu haben, sich den „besten“ Partner auszusuchen. Langwierige Verhandlungen, welche Daten wann und in welcher Form auszutauschen sind, wie die Abstimmung erfolgt oder wie Datenschutz und Datensicherheit zu gewährleisten sind, stehen diesem Ziel entgegen. Mit der Reduktion von Rüst- zeiten und -kosten steigt die Fähigkeit zum schnellen Zusammenschluß mit vorher unbekannten Part- nern. Dafür müssen aber zuerst Potentialinvestitionen dafür getätigt werden, die beim VU besonders unter dem Lichte eines kurzen Planungshorizonts zu sehen sind. Als weitere Einflußfaktoren gelten Betriebsgröße und Änderungsrhythmus der eingesetzten Technologien. Eine schnelle Kopplung nach dem „Plug-and-Play“-Prinzip bei Stereoanlagen erfordert in bezug auf die IV eine gewisse Flexibilität zur Umgestaltung (Konfigurierbarkeit und Parametrisierbarkeit).

Für ein schnelles Koppeln bedarf es einer Art „Architektur der Schnittstellen“. Die notwendige Um- konfiguration der betrieblichen IV beim Wandel der Unternehmensstrukturen könnte wissensbasiert und rechnergestützt, und damit quasi automatisch ablaufen (zu wissensbasierten Konfiguratoren vgl.

[Günt95]). Die zunehmende Verbreitung von (modularer) Standardsoftware sowie der konsequente Einsatz des objektorientierten Programmierparadigmas (mit Daten- und Methodenkapselung) unter- stützen diese Flexibilität.

Upton und McAfee fassen die Anforderungen an die IT-Infrastruktur von VU in folgenden drei Punkten zusammen [UpMc96]:

1. Einbeziehen von Partnern auf allen Stufen der Kopplung („dating“, „engaged“, „married“) 2. Einbeziehen von Partnern mit allen Graden der IV-Reife („naive“, „experienced“)

3. Bereitstellen aller benötigten Funktionalitäten von der einfachen Datenübertragung über den Da- tenzugang bis zur Telepräsenz

2.2 Prototypische IV-Infrastruktur

Das folgende Beispiel für eine prototypische IV-Infrastruktur zur Unterstützung von VU zeigt deren mögliche Komponenten:

Das Modell einer IV-Architektur Virtueller Unternehmen basiert auf Madnick (vgl. [Madn91]). In diesem fiktiven Beispiel sind vier Partner aus Hongkong, Nürnberg, Leipzig und Bern durch ein Kommunikations- sowie ein Datenmanagementsystem miteinander verbunden. Das offene System sollte flexibel genug sein, um organisatorische und geographische Veränderungen sowie wechsel- weise Zentralisierung und Dezentralisierung der IV zu ermöglichen. Die Benutzerschnittstelle eröffnet einen individuellen Systemzugang (z.B. durch entsprechende Sprachfilter).

Das Kommunikationssystem sorgt für das Routing von Nachrichten, übersetzt gegebenenfalls bei un- terschiedlichen Protokollen und überwacht das Weiterleiten der Nachrichten (Monitoring, Statusmel- dungen, Integritätswahrung). Von jedem Terminal oder PC sollte ein Zugang zu allen Anwendungen möglich sein, sofern der Zugriff autorisiert ist. Zunächst sollte man eine ausreichende Auskunftsfä- higkeit der Partner durch Monitoring-Module realisieren, die es erlauben, jederzeit quasi „online“ die relevanten ressourcen-, prozeßketten- und auftragsnetzbezogenen Informationen abzurufen. Diese In- formationen müssen vor der Weitergabe an Partner für jene entsprechend aufbereitet werden. Sensible Daten, z.B. über einzelne Kundenaufträge, bei denen keine Zusammenarbeit erfolgt, müssen ggf.

durch eine Selektion oder auch durch Kapseln geschützt werden können. Um für den Partner eine Datenflut zu vermeiden, müssen Einzelinformationen ebenfalls selektiert und partnergerecht verdich- tet werden können (z.B. Er- und Übermitteln der aktuellen Durchlaufzeit eines Erzeugnisses in einem Fertigungssegment statt Arbeitsvorgangsdurchlaufzeiten an einzelnen Systemen).

Die weiteren Schichten sind unabhängig von der jeweiligen Anwendungssoftware, die sich in Trans- aktions- und Informationsverarbeitung sowie administrative Unterstützung aufteilen läßt. Unter die Transaktionsverarbeitung (TV) fällt die Unterstützung operativer Aktivitäten, wie der Auftragsein- gang in einem PPS-System. Im Sinne einer Validation ist sicherzustellen, daß alle benötigten Infor- mationen vorhanden sind und daß die gemeinsam aufgestellten Grenzen, Bedingungen und Regeln nicht verletzt werden. Von der TV geht ein Anstoß zur Datenänderung aus. Die Informationsverarbei- tung (in Anlehnung an Madnicks Begriff „Information Processing“) erfüllt Aufgaben wie Analysie-

TV IV AU

2 2 2 AU₄

Minimale Installation

Verteiltes System

Mainframe- Ansatz

Teilweise Installation IV3

Benutzer- schnittstelle

Kommunika- tionssystem Anwendungs- software

- Transaktionsverarbeitung - Informationsverarbeitung - Administrative Unterstützung BS2

Datenmanage- mentsystem Datenbank Hong-

kong 1

Nürn- berg

2

Leip- zig

3

Bern 4

TV3 AU 3

BS2 BS2 BS2 BS2 BS2 BS2 BS2

Abbildung 1: Prototypische Infrastruktur zur Unterstützung von VU - modifiziert nach [Madn91]

ren, Berechnen und Umstrukturieren von Daten. Administrative Unterstützung leisten beispielsweise Programme für Email oder Textverarbeitung.

Das Datenmanagementsystem koordiniert den Zugriff auf die verteilten Informationen, routet Abfra- gen aus den einzelnen Anwendungssystemen und führt diese durch. Jedes Programm kann grundsätz- lich (sofern nicht anders vereinbart) alle verteilten Datenbestände nutzen.

Eine wirkliche Integration ist erst mit dem Einsatz einer gemeinsamen Datenbasis möglich, die den Anwendungen eine logisch zentrale Datenhaltung bereitstellt. Logisch deswegen, da den Anwendun- gen nur eine einheitliche Sicht, eine sog. „One Copy View“, bereitgestellt wird. Eine physikalisch zentrale Umsetzung wäre aufgrund der vorzufindenden Rechnerinfrastrukturen verbunden mit den aktuellen Rightsizing-Trends kein gangbarer Weg. Dies gilt insbesondere vor dem Hintergrund einer standortübergreifenden Integration der Informationstechnik. Folglich müssen objektorientierte Daten- banken physisch verteilt realisiert werden. Bisherige Kopplungsansätze behandeln vorrangig Pro- bleme wie die Integration heterogener Schemata [FaNe93], Ablaufmodelle [GrRe93] und Datenbe- stände durch Föderation [Ram93]. Konzepte zum Lokalisieren und zur Migration von Objekten inner- halb von verteilten objektorientierten Datenbanken werden in [KoKe94] diskutiert.

3 Stand der Standardisierungstechnik

Das folgende Kapitel umfaßt die unterschiedlichen Philosophien der Vorgabe von Standards, den Stand der Schnittstellenentwicklung sowie eine moderne Standardisierungsinitative.

3.1 Unterschiedliche Philosophien der Vorgabe von Standards 3.1.1 Formale vs. Defacto-Standards

Ein Defacto-Standard stellt eigentlich eine proprietäre Technologie dar, die von einem Unternehmen entwickelt und gehalten sowie von anderen Unternehmen kopiert bzw. gegen Gebühr imitiert wird (Bsp. Postscript von Adobe Systems).

Industriestandards werden in einem spezifischen Markt oder für eine Anwendung entwickelt. Dies geschieht durch eine Industrievereinigung wie etwa das Institute of Electrical and Electronic Engi- neers (IEEE) oder die American Society of Mechanical Engineers (ASME). Deren Vorschläge bieten sich zur formalen Standardisierung an, falls sie von generellem Interesse für die gesamte Industrie sind (z.B. IEEE 802.3 - Ethernet). Vielfach spricht man aber davon, daß man mit Wortschöpfungen wie "Industrie"- oder "Defacto-Standards" nur Industrie-Darwinismus verschleiern will.

Formale Standards sammeln Normungsgemeinschaften wie etwa das National Standards Institute (ANSI) in den USA oder weltweit die International Organization for Standardization (ISO) und die International Electro-technical Commission (IEC).

Im Gegensatz zu einem Defacto-Standard ist die von einer Normungsgemeinschaft offiziell festge- legte Norm nicht an das Leistungsspektrum eines Systemanbieters angepaßt, sondern soll einen Kom- promiß aller marktrelevanten Systeme verkörpern („gemeinsamer Nenner“). Da eine eventuelle Wei- terentwicklung des formalen Standards in entsprechenden unternehmensübergreifenden Arbeitskrei- sen stattfindet, ist das Risiko geringer, daß bei einem neuen Release des systemneutralen Aus- tauschformates die Übersetzungsvorgänge nicht mehr funktionieren. Dagegen sind die Schnittstellen für den Defacto-Standard eines Herstellers bei jedem Versionswechsel an das jeweils neueste Release anzupassen (z.B. um neue Elemente oder zusätzliche bzw. modifizierte Attribute bereits existierender Entities zu berücksichtigen). Einem zuverlässigen Datenaustausch ist das natürlich nicht zuträglich.

Die Leistungsfähigkeit der Systemschnittstellen eines Herstellers übersteigt auch nicht in jedem Fall die eines offiziellen Standards. Vergleicht man etwa das CAD-Format DXF² mit der ISO-Norm STEP³, so stellt man fest, daß „die proprietäre und technisch mangelhafte Schnittstelle DXF“

[AEMN93, S. 27] den Anforderungen des überbetrieblichen CAD-Datenaustausches weitaus weniger genügt.⁴

2 DXF (Drawing Exchange File) ist das externe Austauschformat des CAD-Systems AutoCAD, dem „Standard unter den PC-gestützten CAD-Programmen“ [Popp96, S. 3], das sich im „Austauschalltag“ von technischen Zeichnungen und Geometriemodellen als das am weitesten verbreitete Format durchsetzen konnte [Sche96, S. 1].

3 Der offizielle Name dieser von der internationalen Normungsorganisation ISO entwickelten Normenreihe ISO 10303 lautet: „Industrial automation systems and Integration - Product data representation and exchange“. Es hat sich jedoch die Bezeichnung STEP als Abkürzung für „STandard for the Exchange of Product model data“ eingebürgert.

4 So verfügt AutoCAD beispielsweise über die marktgängigen Techniken der assoziativen Bemaßung und der Definition von Maßketten, läßt jedoch im DXF-Format - im Gegensatz zu STEP - nicht den Austausch dieser Strukturierungsoptio- nen zu. Weitere Defizite des DXF-Formates sind die Auffassung von Schraffuren als Vielzahl von Linien (dadurch wird nicht nur das Austauschfile stark aufgebläht, auch die Assoziation zur schraffierenden Fläche geht verloren), die Übertra- gung von Symbolen als Blöcke (somit lassen sich Gruppen nicht mehr von Symbolen unterscheiden, so daß die Möglichkeit, auf gemeinsame Symbolbibliotheken zurückzugreifen, versperrt ist) oder die nicht festgelegte Interpretation von Sachdaten, die mit geometrischen oder grafischen Daten verknüpft werden (vgl. auch [Haas93, S.42-46] und [Auto96, S. 121-127]).

Andererseits sprechen Monse und Reimers [MoRe94] angesichts der Probleme, geeignete Institutio- nen zu schaffen, die auch die Interessen kleiner und mittlerer Unternehmungen wirkungsvoll vertreten können, von der institutionellen Lücke.

Einen abschließenden Vergleich der Charakteristika von Defacto- und formalen Standards zeigt Ta- belle 1.

Tabelle 1: Vergleich von Defacto- und formalen Standards

Defacto-Standards Formale Standards

Ausgangspunkt Einzelne Unternehmen Vereinigungen

Verbindlichkeit gering hoch

Verbreitungsgrad mittel bis hoch oft gering

Beispiele SAP R/3, Microsoft OLE, Auto-

CAD DXF

EDIFACT, STEP, IGES

3.1.2 Branchenübergreifende vs. Branchenstandards

Ähnlich wie man bei der Branchensoftware auf einen Kompromiß zwischen individuell erstellten Programmen auf der einen und vereinheitlichter Software auf der anderen Seite abzielt,⁵ wird mit Branchenstandards versucht, die für Betriebe eines Zweiges vergleichbaren Anforderungen an die auszutauschenden Informationsmengen festzulegen und verbindliche, branchenbezogene Übertra- gungsmodelle zu definieren. So verkörpert etwa EDI (Electronic Data Interchange) einen nach Bran- chen gruppierten Normenkatalog für Standardnachrichten. Dabei ist ein EDI-Standard (z.B. VDA) in der Regel inkompatibel zu Standards, die in anderen Branchen eingesetzt werden (vgl. [Buxm96, S.

16-17], [MiSc94, S. 557-558] und [ScNo96, S. 15]).

Der Vorteil einer branchenspezifischen Norm liegt darin, daß kein „Ballast“ aus anderen Bereichen mitzuschleppen ist. Da man je nach Branche spezielle Elemente für den Informationsaustausch zu de- finieren hat - ein Hersteller mechanischer Produkte benötigt beispielsweise für die Produktbeschrei- bung andere Objekte als ein Produzent elektronischer Erzeugnisse - fällt bei einer branchenübergrei- fenden Norm, die die Anforderungen aller Bereiche zu berücksichtigen hat, die Dokumentation in der Regel äußerst umfangreich aus. So ist etwa im Konstruktionsbereich der Standard IGES (Initial Gra- phics Exchange Specification) wegen seiner zu breiten Ausrichtung⁶ häufig kritisiert (vgl. stellvertre- tend für viele [Schn93, S. 8-11]) und schließlich vielfach durch branchenbezogene Untermengen (z.B.

VDAIS in der Automobilindustrie) ersetzt worden.

Dagegen bildet eine branchenbezogene Standardisierung lediglich eine Insellösung. Insbesonders für Teilnehmer virtueller Kooperationen, die u.U. nach dem Ende der Mission den Wirtschaftszweig wechseln, sind isolierte Branchenstandards wenig nützlich. Hier stellt sich die Forderung nach umfas- senden Konzepten, die die verstärkte Informationsintegration über die Branchengrenzen hinweg un- terstützen. Modernere Standardisierungsinitativen wie STEP oder UN/EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) zeigen unterschiedliche Wege auf, um die branchenbezogenen Insellösungen zu überwinden:

5 Mertens et al. stellen hier auch eine Analogie zur Bekleidung mit der „Maßkonfektion als Mittelweg zwischen dem maßgeschneiderten Anzug und der kaum individualisierbaren Massenware“ [MeHL95, S. 340] auf.

6 Die Dokumentation des IGES-Standards umfaßt in der gegenwärtigen Version 5.0 mehr als 500 Seiten und beinhaltet mehr als 160 Entity-Typen.

Der Standard EDIFACT erhebt den Anspruch, als „Obermenge alle branchenspezifischen und auch (inter-)nationalen Anforderungen in sich zu vereinen“ [MiSc94, S. 558]. Um sich leichter an ver- schiedene Branchen anzupassen und die Gestaltungsspielräume der Norm einzuengen, werden in EDIFACT Subsets mit branchenspezifischen „Muß-“ und „Kann-Feldern“ definiert. Diese Subsets - z.B. EANCOM (European Article Number Communication) für den Konsumgüterbereich - stellen ei- nen auf die jeweilige Branche zugeschnittenen Auszug aus der EDIFACT-Norm dar. Allerdings wird häufig kritisiert, daß dieser Weg zu einer semantisch nicht standardisierten Vielfalt unterschiedlicher Subsets führt, die den Standardisierungscharakter der EDIFACT-Norm erheblich beeinträchtigt (vgl.

[ScNo96, S. 40-41]).

Eine andere Möglichkeit zur Lösung dieser Problematik zeigt der Partialmodellansatz von STEP auf:

Die ISO-Norm unterscheidet zwischen allgemeinen Grundmodellen (dem sogenannten Integrierten Produktmodell) und darauf aufbauenden Anwendungsmodellen (den sogenannten Anwendungsproto- kollen). Letztere spezifizieren Teilmengen der universellen Grundmodelle zur DV-technischen Unter- stützung spezieller Prozeßketten in bestimmten industriellen Anwendungsbereichen.⁷ Das Wieder- verwenden der gemeinsamen Kernmodelle gewährleistet eine einheitliche Grundstruktur für die Mo- dellierung von Produktdaten und sichert somit die konsistente Datenspezifikation über die große Bandbreite industrieller Anwendungsfelder hinweg. Die dadurch bewirkte Vereinheitlichung indu- strieller Anwendungssemantik ermöglicht es den unterschiedlichen Applikationen erst, die Daten ge- meinsam zu nutzen.

3.1.3 Austauschformate vs. Spezifikationssprachen

a) Standardisierte Daten-/Dateiformate

Bisher wird der genormte Datenaustausch zwischen unterschiedlichen IV-Systemen in der Regel über Dateien mit systemneutralen Austauschformaten realisiert. Vor der Übertragung ist dabei das impli- zite Format des jeweiligen Anwendungsprogramms in das normierte explizite Dateiformat zu überset- zen⁸, anschließend wird die Datei übertragen und in das Zielsystem eingelesen. Durch das Festlegen

7 Z.B. das Anwendungsprotokoll 214 „Core Data for Mechanical Automotive Design Processes“ für die mechanische Konstruktion im Automobilsektor.

8 Anwendungssysteme erstellen und verarbeiten Daten in systemspezifischen internen Datenformaten, die speziell auf ihre Funktionalität zugeschnitten sind (abhängig von der verwendeten Rechner-Architektur sowie der jeweiligen Software- Release). Die Daten liegen dabei in einer binären Form vor, so daß der Rechner sie ohne weitere Umwandlungen direkt verarbeiten kann. Die Anwendungssysteme verfügen in der Regel neben dem internen Format auch über ein sogenanntes externes Format, in dem die Daten als Klartext (meist in ASCII-Form) dargestellt sind. Vor dem Datenaustausch wird

NC- Daten NC-Programmier-

system

CAD- Daten CAD- System

Pre-

Prozessor IGES

Post- Prozessor Datenfluß

Legende

Abbildung 2: Beispiel für den Datentransfer über Dateien mit standardisierten Formaten

der einheitlichen Formatierung und Interpretation der übertragenen Informationen gewährleistet man, daß das empfangende System die Daten ordnungsgemäß interpretieren und in sein eigenes implizites Format übersetzen kann. Abbildung 2 zeigt den Ablauf eines derartigen automatisierten Datentrans- fers am Beispiel einer „klassischen“ CAD/CAM-Kopplung über das neutrale Austauschformat IGES.

Bekannte Beispiele für derartige Schnittstellennormierungen sind neben IGES aus dem Konstrukti- ons- auch die ebenfalls bereits im vorherigen Kapitel 3.1.2 genannte Norm EDIFACT aus dem kauf- männischen Bereich.

Typisch für diese Art von Standards ist, daß sie zwar die Syntax, aber nicht die genaue Semantik festlegen. Bei EDIFACT bleiben Aussagen über Layoutstrukturen ebenso offen wie die zu verwen- denden Kommunikationsmedien. Ebenso definiert IGES zwar ein spezielles 80-Zeichen Festformat für den Austausch von Daten, gibt jedoch keine Referenzstruktur vor, so daß auch hier entsprechende Implementierungsspielräume vorliegen.

Die Standardisierungen der Schnittstellen richten sich bei diesen Verfahren ausschließlich auf die Normierung der Dateistruktur aus. Dabei legt die Norm gleichzeitig die Repräsentation (das Daten- modell) und die Implementierung (Dateistruktur) fest.

Aus einem derartig realisierten Konzept zum überbetrieblichen Datenaustausch resultieren die be- kannten Probleme einer Dateiorganisation, die jeweils nur bestimmte Anwendungs- bzw. Informati- onsprobleme unterstützt (unkontrollierte Redundanz von Daten, Mehrfachaufwand für die Speiche- rung und Dokumentation der Dateien, geringe Flexibilität bezüglich neuer Anwendungen oder organi- satorischer Veränderungen, fehlende Vorkehrungen zur Behandlung von Inkonsistenzen etc.). Dafür ist die Standardisierung technisch relativ einfach und mit niedrigen Kosten realisierbar (vgl. [Stic91, S. 4-5] und [Öste95, S. 247]). Zudem kann die Datenhaltung der beteiligten Unternehmen unabhängig voneinander erfolgen - lediglich die ausgetauschten Daten müssen standardisiert sein. Dieser Aspekt ist angesichts der häufigen Partnerwechsel gerade für Virtuelle Unternehmen sehr interessant. Zudem lassen es die bisherigen Standards nicht zu, das standardisierte Datenschema zu erweitern - z.B. um die Besonderheiten spezifischer Kooperationen zu ergänzen -, da es vom Dateiformat implizit ab- hängt.

b) Formale Spezifikationssprachen

Moderne Standardisierungsinitiativen aus dem Konstruktionsbereich, wie etwa das CAD*I- oder PDES-Projekt (s. Abschnitt 4.1), zielen darauf ab, Austauschmodelle mit Hilfe einer formalen Des- kription der Struktur der auszutauschenden Informationen (sogenannte Schemabeschreibungssprache) zu definieren. Das Dateiformat kann dann aus der formalen Beschreibung abgeleitet werden und ist somit nicht mehr der primäre Normierungsgegenstand.⁹ Die Repräsentation und die Implementierung der Datenbeschreibung werden somit voneinander getrennt.¹⁰ Dadurch ist es (mit Hilfe von Software- werkzeugen) möglich, ein logisches Referenzmodell automatisch in verschiedene Zielimplementie- rungen abzubilden (z.B. Datei, Datenbank, Archiv).

dann das interne in das Klartextformat übertragen. Die einzelnen Datenwerte stehen dabei in der Austauschdatei, d.h. in der Regel sequentiell hintereinander (vgl. [Haas93, S. 48-51]).

9 Aus den Modellen der auszutauschenden Informationsobjekte werden (halb-)automatisch konkrete Repräsentationssche- mata und die zugehörigen Zugriffsschnittstellen erzeugt (automatisierte Ableitung eines normierten Dateiformats oder Datenbankschemas mit Hilfe der neutralen Spezifikationssprache).

10 In STEP etwa sind die Schemata der Produkte in der Schemabeschreibungssprache EXPRESS spezifiziert (Part 11) [ISO94b], während andere Teilnormen die beiden Möglichkeiten einer Austauschdatei (Part 21) [ISO94c] und einer Datenbankzugriffsschnittstelle (Part 22) [ISO95] für die Implementierung festlegen.

Zudem erlaubt es eine solche formale Spezifikationssprache, je nach den Bedürfnissen der Aus- tauschpartner beliebige zusätzliche Informationseinheiten zu definieren und semantische Aspekte stärker zu berücksichtigen.

3.2 Stand der Schnittstellenentwicklung

Heute ist es die Regel, daß man bei der Kopplung eine individuelle Schnittstellenlösung program- miert. Editoren im EDI-Bereich bzw. Schnittstellenvisualiserungstools weisen den Weg zu einer transparenten und effizienten Schnittstellenverwaltung. Abbildung 3 zeigt einen Ausschnitt des Tools

„VUWizard“, das am Bereich Wirtschaftsinformatik I der Universität Erlangen-Nürnberg entstanden ist [Fais97]. So kann hier die Struktur eines Virtuellen Unternehmens mit seinen Partnern, deren An- wendungssystemen, Schnittstellen, Kopplungen und Konvertierregeln abgelegt sowie graphisch dar- gestellt werden.

Im Sinne des raschen Anbindens von Fremdanwendungen geht SAP mit ALE (Application Link En- abling ) bereits einen Schritt in Richtung Integration von verteilten Anwendungen zu einem Gesamt- system voran. Ziele sind dabei:

1. Konsistenz der Daten in verteilten Anwendungen durch dynamische Aktualisierungsprozesse 2. Koexistenz unterschiedlicher Release-Stände innerhalb verteilter R/3^®-Systeme

3. Integration von R/2^® und Fremdsystemen in den ALE-Verbund

Die nachfolgende Abbildung zeigt die Kopplung von R/3^® mit einem Fremdsystem mittels ALE:

Abbildung 3: Ausschnitt aus dem VUWizard

3.3 CALS als moderne Standardisierungsinitative

CALS (Computer aided Acquisition and Logistics Support) wurde ursprünglich - im September 1985 - als Initiative des amerikanischen Verteidigungsministeriums gestartet. Ziel war es, den Informations- austausch zwischen Behörden und Unternehmen bei großen Militärprojekten durch ein Konzept zum koordinierten Einsatz von Standards und Normen zu verbessern. Seitdem wird CALS fortlaufend weiterentwickelt und gewinnt als Strategie für die Nutzung modernster Informationstechnologien und internationaler Standards im überbetrieblichen Datenaustausch immer mehr auch in Branchen außer- halb der Rüstungsindustrie (wie der Luft- und Raumfahrt- oder der Automobilindustrie) an Bedeu- tung. Um den Ausbau des Konzeptes zu dokumentieren, wird CALS inzwischen auch mit den Begrif- fen Continuous Acquisition and Life Cycle Support bzw. Commerce at Light Speed belegt ([Hoff95, S. 101] und [Schi96, S. 205]).

Das wesentliche Anliegen von CALS ist, den Informationsaustausch kooperierender Unternehmen entlang der Wertschöpfungskette qualitativ zu verbessern und zu beschleunigen. Das Grundprinzip bildet dabei die Einbindung aller Beteiligten in den gesamten Lebensweg, um so sicherzustellen, daß Informationen beliebiger Art rechtzeitig und in einer wiederverwertbaren Form bereitgestellt werden - unabhängig davon, wo und in welchen Systemen sie gespeichert sind (s. Abb. 5).

Bei CALS handelt es sich nicht um ein vollständig neu entwickeltes Konzept, sondern um eine Samm- lung bereits bestehender Richtlinien, Austauschregeln, kaufmännischer und technischer Standards und Normen. Mit dem Stufenkonzept verfolgt CALS einen durchaus pragmatischen Ansatz zur Integration von Daten und Prozessen: Um den Aufbau einer (bei einem VU nur befristeten) überbetrieblichen Kooperation nicht mit zu hohen Anforderungen an die IV zu belasten, sieht das CALS-Konzept in der ersten Phase - sog. CALS I - lediglich die Weitergabe aller Projektdokumente über geeignete Stan- dardaustauschformate vor. Die dadurch bedingte redundante Datenhaltung der Informationen soll in der zweiten Stufe von CALS - sog. CALS II - überwunden werden, indem eine integrierte Projektda- tenbank (sog. Contractor Integrated Technical Information Service, CITIS) aufgebaut wird (vgl.

[Schi96, S. 206] und [Bund95]). Der Vorteil dieser zweistufigen Vorgehensweise liegt darin, daß die meisten Unternehmen die Implementierung von CALS I mit einem vertretbaren Aufwand realisieren können.

Da aber CALS derzeit lediglich einen Rahmen für einer Vielzahl verschiedener Standards, Verfahren und Methoden zum Umgang mit Daten bildet, deren Ausgestaltung und Anwendungsbereich zudem

teilweise noch nicht in allen Einzelheiten geklärt ist, genügt es nicht, für eine überbetriebliche Koope- ration nur allgemein die Anwendung von CALS zu vereinbaren. Es muß festgelegt werden, für welche Funktionen welche Standards aus dem „Baukasten“ von CALS Anwendung finden.

R/3

Anwendung ALE-Schicht Konverter Fremd-

Anwendung Master

IDOC ^IDOC

IDOC IDOC

Ausgangs- verarbeitung

Eingangs- verarbeitung

Translator

Zertifizierung RFC

RFC

Abbildung 4: Kopplung von SAP R/3 mit Fremdsystemen

Die End-Vision des CALS-Konzeptes sieht die vollständige informationstechnische Verknüpfung aller unternehmensinternen und -übergreifenden Abläufe während des gesamten Lebenszyklus eines Pro- dukts vor. Alle vorhandenen und künftigen rechnerunterstützten Systeme sollen auf einem gemeinsa- men Konzept zur Vereinfachung der Geschäftsabläufe und zur Integration bisher voneinander ge- trennter, nicht kompatibler Datenhaltungen aufsetzen (s. Abb. 5).

Das angestrebte totale Produktmodell umfaßt in seiner vollen Realisierung dazu ein Verbraucher-, Markt-, Umwelt-, Branchen-, Zulieferer-, Gebrauchs-, Qualitäts-, Prozeß-, Konstruktions-, Produkt- konzept- und Anforderungsmodell. Hinsichtlich der Implementierung dieses Produktmodells ist auch vorstellbar, daß im Zentrum keine zentrale integrierte Produkt- und Prozeßdatenbank angesiedelt ist und die Projektteilnehmer über Verweise auf dezentrale Projektdaten zugreifen.

Effiziente Gestaltung der Prozesse

Informationsaustausch: elektronisch, schnell, unternehmensübergend Entwickler

Bewerber/

Angebots- und Auftragsbearbeitung

Hersteller

Auftraggeber/

Nutzer Instandhalter

Entsorger

Daten

Zulieferer

Dokumente

Abbildung 5: Integrierte Informations- und Kommunikationsarchitektur in CALS

4 Exemplarische Felder der Standardisierung 4.1 Konstruktionsbereich

Das Bedürfnis nach zwischenbetrieblichem Datentransfer tauchte zuerst im CAD-Bereich auf, so daß hier der Ursprung aller Bemühungen um überbetriebliche Standards liegt. Bereits Ende der 70er Jahre wurde mit der Norm IGES das erste genormte Dateiformat überhaupt entwickelt. Ziel war zunächst nur der systemneutrale Austausch von technischen Zeichnungen mit externen Partnern und Zuliefe- rern.¹¹ Trotz zahlreicher Probleme bei der IGES-basierten Datenübertragung¹², die zunächst zu einem außerordentlich schlechten Ruf der Norm führten, ist der Standard noch heute das verbreiteste Aus- tauschformat im Konstruktionsbereich.

Bevor die Mängel von IGES gegen Ende der achtziger Jahre (zumindest teilweise) behoben werden konnten, hatten bereits eine Reihe von Benutzergruppen auf nationaler Ebene Formate entwickelt, die den Austausch von Geometriebeschreibungen in verschiedenen Ausprägungen ermöglichen sollten (s.

Abb. 6).

So enstand durch Initiative des Verbandes der deutschen Automobilindustrie (VDA) die Flächen- schnittstelle VDAFS¹³, weil die einfachen Datenschemata der frühen IGES Versionen nicht die im Automobilbau vielfach vorkommenden Freiformenflächen (z.B. bei Karosserieteilen oder Autositzen) abbilden konnten. Die Norm SET (Standard d´Echange et de Transfert) wurde - ebenfalls 1983 - in der französischen Luft- und Raumfahrtindustrie entwickelt, da die seinerzeit gültige Version IGES 2.0 nicht geeignet erschien, die geometrisch-technologischen Daten beim Bau des Airbus A320 handzu- haben.¹⁴ Die wegen des Verzichts auf Konformitätstests verbreiteten Übertragungsprobleme bei IGES-Dateien führten dazu, daß der Verband der Automobilindustrie mit VDAIS ein Subset von IGES für den Austausch von CAD/CAM-Daten in der Automobilindustrie festlegte.¹⁵ Projekte wie CAD*I¹⁶

11 Die Version 1.0 wurde 1980 als ANSI Y 14.26 veröffentlicht. Diese erste Version konzentrierte sich lediglich auf die Übertragung von 2D-Geometriedaten und Zeichnungsinformationen mit Hilfe von Datentypen für Linien- und Flächen- geometrie sowie Strukturierungselementen. Die gegenwärtig gültige Version 5.0 berücksichtigt dagegen auch Kanten-, Flächen- und Volumenmodelle sowie Finite-Elemente-Netze. Sie ist somit in der Lage, verschiedene, systemspezifisch verwaltete CAD-Datenbasen miteinander zu verknüpfen.

12 Beispiele sind der zu breite Ansatz von IGES (s. Abschnitt 3.1.2), das aufwendige und ineffiziente Dateiformat, die oft fehlerhafte und unvollständige Implementierung der für IGES entwickelten Pozessoren, die fehlende Referenzstruktur oder die zu zahlreichen Informationsverluste (insbesondere bei Strukturinformationen).

13 Die Flächenschnittstelle des VDA wurde 1983 entwickelt und 1986 als DIN-Norm 66301 veröffentlicht. Noch heute ist VDAFS in der Version 2.0 die federführende Schnittstelle für den Austausch geometrischer Informationen.

14 Die Schnittstelle SET wies vor allem ein im Vergleich zu IGES verbessertes, sehr kompaktes physisches Dateiformat auf;

die 1987 vorgestellte Version 2.0 enthielt sogar schon Elemente zur Repräsentation von 3D-Modellen. In die konzeptio- nellen Überlegungen der Norm flossen zudem die Anforderungen ein, alle im CAD/CAM-Bereich anfallenden Daten übertragen zu können und eine zentrale Produktdatenbank zu realisieren. International konnte sich die Norm allerdings nicht durchsetzen.

15 Diese 1986 veröffentlichte erste Version beschränkte sich - als Subset der IGES-Version 3.0 - auf die Basisgeometrie, das Zeichnungslayout und Bemaßungselemente. 1989 wurde ein zweiter Teil von VDAIS als Untermenge der IGES-Version 4.0 vorgestellt, der auch die Beschreibung von Freiformenflächen ermöglichte. Die Teilmengen von IGES wurden so zusammengestellt, daß der CAD-Datenaustausch zwischen diesen Beteiligten einfach und verlustfrei durchgeführt werden kann. Insbesondere die Gliederung der VDAIS in Leistungsstufen sollte zudem eine genaue Beurteilung der Leistungsfähigkeit der Übersetzer erlauben.

16 Das 1984 initiierte ESPRIT-Projekt 322 mit dem Titel CAD-Interfaces (CAD*I) brachte einen Satz von Forschungs- schnittstellen zum standardisierten Austausch verschiedener strukturierter 3D-Geometrie- und Finite-Element-Modelle hervor. Die CAD*I-Schnittstellen kamen zwar nie in der Industrie zum Einsatz, jedoch gingen die Ergebnisse und Erfah- rungen dieses Projektes in die Entwicklung von STEP ein.

oder PDES¹⁷, in denen man formale Spezifikationssprachen zur Modellierung beliebiger Informati- onseinheiten definierte (s. Abschnitt 3.1.3), wurden durchgeführt, da mit IGES der Informationsfluß lediglich als Dateiaustausch zu realisieren ist.¹⁸

Alle bisher genannten Normen beschränken sich auf die Repräsentation von Gestaltdaten. Mit dem breiten Einführen von CAD-Systemen und der wachsenden Rechner-Durchdringung anderer Stadien des Produktlebenszyklus wuchs jedoch der Wunsch, nicht mehr nur 2D-Zeichnungen und 3D-Modelle für nachgeschaltete Prozesse bereitzustellen, sondern auch andere in der Konstruktion festgelegte Daten, wie etwa Konstruktions-Stammdaten, Teile-Stammdaten und -Strukturen oder abgeleitete Geometriedaten (z.B. NC-Programme, FEM-Berechnungen). So zielen auch die neueren Entwicklun- gen im CAD-Bereich - neben der hard- und softwaretechnischen Unterstützung immer komplexerer Geometriedarstellungen - vor allem auf die Entwicklung weitreichender Informationsmodelle (z.B.

Feature-Modelling, Produktmodelle, multidirektionale Assoziativität). Die Tendenz geht dabei in die Richtung der Abbildung aller Informationen des Lebenszyklus eines Produktes, die sämtlichen Betei- ligten den Zugriff auf alle Daten und gewünschten Aggregationen von Daten erlaubt (vgl. [Haas95, S.

49-59] und [AnKa96, S. E6]; s. Abschnitt 1).

Hier ruhen die Hoffnungen auf der derzeit von der ISO entwickelten Normenreihe 10303 STEP, die durch die Definition eines den gesamten Lebenszyklus umfassenden Produktmodells neue Perspekti- ven für die CIM-Integration bieten soll.

Ein wesentliches Ziel von STEP ist es, die Vielfalt der im Konstruktionsbereich genutzten Produktda- ten-/Engineering-Standards zu reduzieren. Die auseinanderlaufende Entwicklung von Normen wie IGES, SET, VDAFS, VDAIS und Forschungsschnittstellen wie CAD*I wird - so die Wunschvorstel- lung - durch eine konzeptionelle und inhaltliche Zusammenführung der Standards in der neuen ISO- Norm STEP integriert. In Zukunft soll es mit STEP nur noch eine internationale Norm für den Pro- duktdatenaustausch geben. So wurde auch die Weiterentwicklung von IGES 1990 wegen der beab- sichtigten Ablösung der Norm durch STEP eingestellt.

17 PDES war ursprünglich ein in den USA gestartetes nationales Forschungsprojekt, in dem ein neutrales, den gesamten Produktlebenszyklus umfassendes Produktdatenmodell entwickelt werden sollte. Die Ergebnisse dieses Projektes gingen dann jedoch vollständig in der Entwicklung der ISO-Norm STEP auf, was sich in der heutigen Bezeichnung „Product Data Exchange using STEP“ widerspiegelt.

18 Daraus resultieren wiederum hybride Produktbeschreibungen, deren Konsistenz und Wiederverwendung nur unter bestimmten Voraussetzungen möglich ist (vgl. [KrJV96, S. E16-E17]).

Die folgende Abbildung - in Anlehnung an [Lühr96, S. 3] und [Schn93, S. 10] - gibt eine Übersicht der wichtigsten Meilensteine der Standardisierung im Konstruktionsbereich.

4.2 Dokumentenaustausch

Ein weiteres klassisches Standardisierungsgebiet ist die Erstellung, Verarbeitung und Datenhaltung modularisierter, digitaler Dokumente. Anwendungsmöglichkeiten applikationsneutraler dokumen- tenorientierter Daten liegen vor allem in der systemneutralen Archivierung und dem elektronischen Austausch von Büro- und Geschäftsdokumenten.

Die derzeit gängigsten system- und herstellerunabhängigen Standards für den elektronischen Doku- mentenaustausch sind die Beschreibungssprachen SGML (Standard Generalized Markup Language)¹⁹ und ODA (Open Document Architecture)²⁰. Beide Normen legen (in textueller Form) die Strukturen und Inhalte beliebiger Dokumente fest; ODA definiert zusätzlich noch eine Layoutstruktur für jedes

19 Die Metasprache SGML wird unter ISO 8879 seit 1986 standardisiert. Dabei enthalten die SGML-kodierten Dokumente neben den eigentlichen Nutzdaten ausschließlich solche Zusatzinformationen, die der Darstellung der logischen Struktur des Dokumentes (hierarchische Markup-Struktur) dienen - inklusive der Verknüpfungen zu externen Daten (z.B. Grafi- ken, Tabellen) oder Prozessen. Die bislang bedeutendste Anwendung von SGML stellt das World Wide Web dar, dessen Sprache HTML (Hypertext Markup Language) ab der Version 2.0 SGML-Dokumenttypdefinitionen nutzt.

20 Im Gegensatz zu SGML ist bei ODA (ISO 8613) zusätzlich die Semantik für die Verarbeitungsstruktur (v.a. zur geome- trischen Anordnung der Attribute der logischen Struktur auf den Seiten) definiert. Wesentliches Ziel von ODA ist die Bildung eines Rahmens zur Integration weiterer Subarchitekturen in die normierte (Baum-)Struktur. Bislang berücksich- tigt ODA die Inhaltselementtypen Text, Raster- und Vektorgrafik. Zukünftig sollen auch Hypertext- und Hypermedia- Anwendungen unterstützt werden. Als Anwendungsszenario diente für ODA die Kommunikation zwischen Verlag und Autoren im Verlagswesen.

1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994

USA (NIST) BRD (VDA/DIN) Frankreich (AEROS) EG (ESPRIT)

IGES 1.0

IGES 2.0

IGES 3.0

IGES 4.0

IGES 5.0

PDES

VDAFS 1.0

VDAFS 2.0 VDAIS

VDAIS

SET 1.0

SET 2.0 SET 1.1

CAD*I 1.0 CAD*I 2.1

CAD*I 3.3

STEP 1.0 ...

Abbildung 6: Historie der Produktdatennormen

Dokument, so daß das Dokument in der vom Absender beabsichtigten äußeren Form beim Empfänger ausgegeben bzw. angezeigt wird (Sicherstellung einheitlicher Layouts und Formatierungen).²¹

In zunehmendem Maße konzentrieren sich die Standards nicht mehr nur auf das logische Strukturieren und Beschreiben von Textdokumenten (inklusive der Verknüpfungen zu externen Daten wie Grafiken, Tabellen etc.), sondern auch auf die Repräsentation zeitabhängiger Dokumentenbestandteile (Video- und Audiosequenzen) sowie das Einbeziehen anwenderdefinierter zeit- bzw. ereignisgesteuerter Ab- laufprozesse (etwa zur Unterstützung des Computer Based Training) in das elektronische Dokument.

Neben entsprechenden Entwicklungen beim ODA-Standard wurde für SGML-codierte Dokumente zu diesem Zweck die standardisierte Beschreibungssprache HyTime (Hypermedia Time-based Structu- ring Language) entwickelt.

4.3 Technische Dokumentation

Zur Standardisierung der technischen Dokumentation existieren spezielle Normen, die gegenwärtig vor allem im Rahmen der logistischen Unterstützung des Wartungs- und Instandsetzungsbereiches zur Anwendung kommen.

Mit der standardisierten Beschreibung technischer Dokumente kann man den Dokumentationsauf- wand reduzieren, indem bereits verfügbare Informationen wiederverwendet und die gesamte Doku- mentationsaufgabe - nach am Concurrent Engineering orientierten Vorstellungen - in parallel zu bear- beitende Teilaufgaben zerlegt werden (sog. „Collaborative Editing“; vgl. [GrKu95, S. 47]).

Die derzeit führenden Normen für die Technische Dokumentation sind:

a) IETM (Interactive Electronic Technical Manual), das fünf Klassen unterschiedlicher technischer Komplexität unterscheidet²²,

b) VNS als verfahrensneutrale Schnittstelle für die Dokumentation elektrotechnischer Anlagen, c) die Beschreibungssprache VHDL (Very High Description Language) für den Elektronikentwurf

und dessen Dokumentation,

d) das von Halbleiterfirmen und CAD/CAE-Anbietern entwickelte, von Menschen und Maschinen lesbare Format EDIF (Electronic Design Interchange Format), welches Einzelheiten und Sichten eines Elektronik-Entwurfs (z.B. Schaltplan, Schaltplan-Netzlisten) darstellt.

Künftig soll insbesondere der integrierte Dokumentationsansatz auf Basis des STEP-Produktmodells - mit der direkten Verfügbarkeit aller Produktmodellinformationen - zu einer Effizienzsteigerung der Werkzeuge für die Erstellung und Verwaltung technischer Dokumente führen.²³

21 Dies ist allerdings bei SGML mit Hilfe der zusätzlichen dokumententypabhängigen Ausgabevereinbarung DSSSL (Document Style Semantics and Specification Language) auch möglich.

22 Class 1 dient zur einfachen Ganzseitendarstellung eines elektronischen Dokumentes, Class 2 erlaubt zusätzlich Hypertextlinks zwischen den einzelnen Informationsblöcken des Dokumentes, Class 3 ermöglicht es, mit Hypertextlinks einzelne Datenmodule zu einem modular strukturierten Dokument zu verknüpfen, Class 4 speichert die Datenmodule in einer gemeinsamen Datenbank, Class 5 erlaubt zusätzlich die Integration eigenständiger logistischer Prozesse und Appli- kationen (z.B. zur Materialbewirtschaftung).

23 Im Rahmen des EG-Forschungsprojektes DOCSTEP wurde ein System zur Erstellung und Verwaltung technischer Dokumente auf Basis des integrierten Produktmodells von ISO 10303 spezifiziert. Auch die STEP-Arbeitsgruppe TC184/SC4/WG3/T14 „Product Documentation“ bemüht sich um die Entwicklung eines Modells zur Abbildung von Dokumentinformationen als Teil des STEP-Produktmodells (vgl. [GrKu95] und [AnWe95]).

4.4 EDIFACT

Der Standard EDIFACT, der eine Spezifikation zur Darstellung verschiedener Dokumenttypen ver- einbart, ist eine Möglichkeit, Dokumente software- und hardwareunabhängig zwischen Unternehmen auszutauschen. Es zeigt sich in der Praxis, daß ein gewünschtes „Plug-and-Play“ noch nicht erreicht ist. Jedoch schätzt man den Aufwand für das Ankoppeln eines weiteren Partners in ein EDI-Netzwerk auf ca. eine Personen-Woche²⁴ ein, so daß EDIFACT prinzipiell für eine schnelle Anbindung geeignet erscheint.Da die Einführung und Nutzung zum Teil auch einen beträchtlichen Aufwand für die Un- ternehmen darstellen, findet man gegenwärtig eine Vielzahl von Initiativen, die suboptimale (im Hinblick auf die Integration) und auf ihre Bedürfnisse abgestimmte Normen bevorzugen. So entwik- kelt ein Verbund britischer Betriebe einen vereinfachten EDIFACT-Standard für den Datenaustausch zwischen Zulieferern und Herstellern.

4.5 Electronic Planning Interchange

Das Softwareunternehmen i2 hat einen Standard zum elektronischen Austausch von Planungsdaten (Electronic Planning Interchange - EPI) entwickelt (vgl. [Bell96]). EPI geht weiter als der EDI X.12 Standard, weil dieser nur Zeichen und Feldlängen berücksichtigt und keine Zeiten und Abhängigkei- ten. Mit der Verbreitung dieses Standards wird die Integration der Logistikkette vorangetrieben. Teil- nehmer sind große Handelshäuser und ihre Zulieferer in den USA, die drei größten amerikanischen Automobilhersteller mit ihrer Zuliefererkaskade sowie Energieversorger. Zur Entscheidungsunterstüt- zung müssen etwa Geschäftsregeln und -vorgehensweisen übertragbar sowie Bestände und Kapazi- täten sichtbar sein. Von Seiten der Daten sollten bspw. verfügbar sein: Freie und reservierte Kapazitä- ten, Fertigstellungstermine, Versandtermine, Bestandsprofile, Kosten, Zulieferer, Kundenzufrieden- heit, Status oder Ort.

4.6 Workflow Management Coalition

4.6.1.1 Systemarchitektur

Die Workflow Management Coalition (WfMC) [WfMC94] gibt das Referenzmodell vor, das in Abb. 7 dargestellt ist. Den Kern dieses Modells bildet die sog. Workflow-Engine, welche mit Hilfe von Prozeßdefinitionen die einzelnen Workflows ausführt, d.h. die Benutzer mit den durchzuführen- den Aufgaben und den dazu benötigten Daten versorgt. Wichtig für das Koppeln von Unternehmen mit verschiedenen Workflow-Management-Systemen (WMS) ist das Interface 4, die Schnittstelle zwi- schen zwei WMS (zu einer genaueren Beschreibung des Referenzmodells der WfMC vgl. [Vers95]).

4.6.1.2 Interoperabilität von Workflow-Management-Systemen

Workflow-Interoperabilität wird von der WFMC definiert als „die Fähigkeit zweier oder mehrerer Workflow-Engines zur Kommunikation und Zusammenarbeit, um Workflow-Instanzen zu koordinie- ren und Engine-übergreifend auszuführen“ [Ande95]. Ein solches System ist dann „offen“, „wenn es seine Schnittstellen der System- und Anwendungssoftware zur Zusammenarbeit mit anderen System ,offenlegt‘“ [Rein93].

24 Die Einschätzung stammt aus einem großen deutschen Softwarehaus.

Zum Zweck der Kooperation müssen WMS zum einen Workflow-relevante Daten und zum anderen Applikationsdaten austauschen. Erstere können den Ablauf eines Geschäftsprozesses beeinflussen.

Beispielsweise mag ein Kundenanfrageformular eines Maschinenbauunternehmens ein Feld enthalten, in dem der Kunde angibt, ob er eine FMEA (Failure Mode and Effects Analysis) wünscht; kreuzt der Kunde dieses Feld nicht an, so wird diese Aktivität im Workflow übersprungen [MoRW96]. Das Do- kumenten-Management-System (DMS) verwaltet im vorliegenden Fall eines DMS-basierten WMS die Applikationsdaten.

Liegen zwei oder mehrere auf verschiedenen Hardware- und Software-Systemen laufende WMS vor, so stellt sich die Frage nach der Verteilung des darunterliegenden DMS. Im Falle zweier getrennter Unternehmen oder weitgehend selbständig arbeitender Geschäftseinheiten können auch zwei völlig separierte DMS vorliegen, die miteinander kommunizieren und Dokumente austauschen müssen. Ge- nauso gut lassen sich aber auch zwei WMS vorstellen, die auf demselben DMS aufsetzen.²⁵

4.7 Standardabläufe, -verträge und -geschäftspraktiken

Neben der Übertragbarkeit von Daten sollte für den reibungslosen Ablauf des Tagesgeschäftes die be- triebswirtschaftliche Anwendungslogik der Anwendungssysteme harmonisiert werden. Beispiele hier- für sind Elektronische Produktpräsentation und -konfiguration, Produktdatenbanken, Kalkulationsme- thoden, zwischenbetriebliche Leistungsverrechnung, Projektmanagementsysteme oder auch CAD-Sy- steme mit Oberflächen- oder Volumenmodellierung. Data Dictionaries und semantische Kontexthilfen stellen die Grundlage für die Zusammenarbeit mit Daten unterschiedlicher Semantik und Syntax dar.

Zudem ist an eine Unterstützung etwa der Vereinbarungsphase von VU durch elektronische Vertrags- konfiguration²⁶ aus Standardbausteinen zu denken.

In einigen Beispielen von vernetzten Unternehmen wurde die Ablauforganisation weitgehend standar- disiert, um jedem Partner eine Orientierung zu geben und Abstimmungsprobleme zu verringern, so bspw. bei der Seitz AG, Pforzheim [Sieb97]. Besonders im Bereich der Softwareentwicklung sind standardisierte Vorgehensmodelle verbreitet. In [HoHS96] wird in diesem Zusammenhang der Aufbau

25 Für weitere Ausführungen siehe [WeFa96].

26 Als Beispiel sei hier das System „It’s legal“ als Analogie aus dem Bereich privater Verträge angeführt.

Workflow-Engine

Workflow-Ausführungsservice Workflow API und Datenformate

Interface 1

Interface 5

Prozeßdefinitions- tools

Administrations- und Monitoring-

Tools

Interface 2 Interface 3

Applikationen Workflow-

Clients

Workflow-Engine

Anderer Workflow- Ausführungsservice

Interface 4

Abbildung 7: Referenzarchitektur für ein WMS

eines Baukastensystems für Prozesse vorgeschlagen. Fraglich ist allerdings, inwieweit eine Standar- disierung hier möglich (wegen der Einmaligkeit von Missionen) und wünschenswert (wegen der In- dividualität als Differenzierung vom Wettbewerb) erscheint.

4.8 CORBA

Die DCE (Distributed Computer Environment) der Open Software Foundation bietet einen verbin- dungsorientierten Netzwerkdienst, der auf dem Mechanismus des Funktionsfernaufrufs (RPC, Remote Procedure Call) beruht. Darauf setzt die Object Management Group im Bereich der objektorientierten Programmierung mit CORBA (Common Object Request Broker Architecture) auf. Der Standard er- möglicht die Kommunikation verteilter Objekte, die zudem auch noch mit verschiedenen Program- miersprachen realisiert sein können [Rösc95].

Beispielsweise sind CORBA-Objekte in der Lage, unabhängig von ihrer Programmiersprache und ih- rem Betriebssystem über Rechnergrenzen hinweg miteinander zu kommunizieren. Ein CORBA-Bestel- lungsobjekt vom Informationssystem eines Unternehmens vermag sich direkt mit dem zugehörigen CORBA-Lieferungsobjekt beim Lieferanten auszutauschen, um immer über den Status auf dem lau- fenden zu sein. Durch die ständige Verfügbarkeit von Datennetzen kann diese firmenübergreifende CORBA-Objektkommunikation online ablaufen (vgl. [Rösc95, S. 96]). Voraussetzung ist aber ein ab- gestimmtes Software-Modell in beiden Firmen (Objekt a muß die Methode, Vor- und Nachbedingun- gen des Objekts b kennen).

4.9 Internet-Banking

Während die S.W.I.F.T (Society for Worldwide Interbank Financial Telecommunication) mit dem S.W.I.F.T.II-System ein strukturiertes Kommunikationsnetzwerk geschaffen hat, das eine rationelle Abwicklung des Zahlungsverkehrs zwischen Banken auf internationaler Ebene ermöglicht, existiert noch keine einheitliche Software für das Abwickeln von Kundenzahlungen, Geld-, Devisen- und Wertpapierhandelsgeschäften, Akkreditiven etc. im „privaten“ Geschäftsverkehr.

Standards wie der Interbank File Transfer im S.W.I.F.T.II-System müssen auch für den privaten Zah- lungsverkehr geschaffen werden, bevor an globales Internet-Banking auch nur im entferntesten ge- dacht werden kann. Unbedingt geklärt werden muß die rechtliche Absicherung bei Online-Transak- tionen, insbesondere welche Gesetze überhaupt zur Anwendung kommen sollen. Das Internet berück- sichtigt keine Landesgrenzen. Daher müssen Zuständigkeiten dringend zugewiesen werden.

Aus eben diesem Grund ist Mitte November 1996 in Nizza das Open Banking Consortium (OBC)²⁷ ins Leben gerufen worden, das sich unter anderem das Entwickeln und Etablieren von Standards für Internet-Banking auf die Fahnen geschrieben hat. Obwohl der Schwerpunkt der Arbeit des OBC klar im Bereich Banking liegt, sollen verwandte Finanzsektoren wie beispielsweise Versicherungs- oder Maklerwesen nicht ausgeklammert bleiben.

27 Vgl. URL: http://internet-banking.com.

5 Vor- und Nachteile von Standards

Um die Kommunikation zwischen den an der virtuellen Kooperation mitwirkenden Unternehmen zu ermöglichen, müssen die zu übermittelnden Informationen (beispielsweise die geometrische Be- schreibung eines Teils) zwischen den Beteiligten abgestimmt werden, so daß die integrierten Pro- gramme die übertragenen Daten ordnungsgemäß interpretieren können. Bei der softwaretechnischen Kopplung ist zu unterscheiden, ob jeweils bilateral zwischen dem datenempfangenden und dem lie- fernden Teilsystem Konvertierungsprogramme definiert oder eine einheitliche, für alle Systeme gül- tige Schnittstelle verwendet werden (s. Abb. 8).

Die folgenden Abschnitte stellen für die Kommunikation normierte Schnittstellen proprietären Forma- ten gegenüber.

5.1 Vorteile

a) Kostenreduzierung

Bei einer Anwendungsintegration mit Hilfe paarweiser Verbindungen sind u.U. eine Vielzahl von Schnittstellen und eingesetzten Datenformaten gleichzeitig zu verwalten und zu pflegen (s. Abb. 8).

Verwendet man dagegen Standards, so muß man entsprechende Implementierungen nur einmal vor- nehmen und kann diese beliebig oft nutzen.²⁸ Aus dem Einsatz eines normierten Austauschformates resultiert folglich ein reduzierter Erstellungs- und Änderungsaufwand für die Schnittstellen zu den (bei einem VU häufig wechselnden) Kooperationspartnern.

Zudem bindet die Eigenentwicklung von Übertragungmodellen Ressourcen für Lösungen, die mögli- cherweise bereits von neutralen Normungsgremien erarbeitet wurden. Der Einsatz von standardisier-

28 Der direkte Informationsaustausch zwischen n verschiedenen Anwendungssystemen erfordert insgesamt n * (n-1) Über- setzungsprogramme zur Übertragung der Dateiformate aller Systeme. Wird dagegen ein gemeinsames Austauschformat für alle Datenübertragungen verwendet, so reichen 2 * n Konvertierungsprozessoren für alle n verschiedenen Systeme.

Modell A

System A

Modell C

System C

Modell B

System B

Modell D

System D

Modell A

System A

Modell C

System C

Modell B

System B

Modell D

System D

Allgemeines Austausch-

modell

Normiertes Austauschformat Bilateral vereinbarte Austauschformate

Abbildung 8: Bilateral vereinbarte und normierte Austauschformate

ten Formaten bietet somit die Möglichkeit, die Kosten und das Projektrisiko für die Schnittstellen- entwicklungen auf die Normungsgremien zu übertragen.

Dem steht allerdings wiederum der Nachteil gegenüber, daß der erforderliche Aufwand für das An- passen der Informationssysteme an die ständig wechselnden Unternehmensgegebenheiten eines VU mit der Anwendungsintegration über paarweise Verbindungen expandiert.²⁹

b) Zeitersparnisse

Standards stehen sofort zur Verfügung und erlauben daher den schnellen informations-technischen Aufbau einer Geschäftsverbindung ohne zeitaufwendige Verabredungen mit den Teilnehmern der Kommunikationskette - ein Aspekt, der angesichts der vom Markt geforderten Reduzierung der Pro- duktanlaufzeiten (time to market, time to customer) immer wichtiger wird.

c) Qualitätsverbesserung

Normierte Schnittstellen sind aufgrund der größeren Erfahrung der Entwickler häufig von besserer Qualität als eigenentwickelte Austauschformate (kaum Risiken in Form von „Kinderkrankheiten“

bzw. „Lehrgeld“).

Die für alle Beteiligten einheitlichen Formate und Interpretationen der Informationen ermöglichen es zudem, Fehler frühzeitig zu erkennen und damit u.U. zu vermeiden.

d) Verringertes Investitionsrisiko

Die höhere Verbindlichkeit von Standards sichert Investitionen in Software und Daten. Mit Hilfe von Standards ist somit der Übergang auf neue DV-Technologien und die Migration in Nachfolgesysteme ohne Datenverluste problemlos möglich.³⁰ Im Hinblick auf Virtuelle Unternehmen sichern Standards den Rücklauf einer Investition im Bereich der IV auch beim Partnerwechsel.

e) Lösung von Semantikproblemen

Wenn die Daten, Funktionen und Prozesse bei den verschiedenen an einer überbetrieblichen Koope- ration beteiligten Unternehmen auf der Grundlage eines einheitlichen Standards beschrieben sind und alle Partner mit den gleichen Datenobjekten und genormten Definitionen operieren, werden Mißver- ständnisse aufgrund unterschiedlicher Dateninterpretationen vermieden. Hierdurch erhöht sich das Verständnis für die Abläufe bei den Partnern und somit auch die gemeinschaftliche Kommunikations- und Entscheidungsfähigkeit.

f) Größere Flexibilität in der Zusammenarbeit

Die Vereinheitlichung der Schnittstellen reduziert die Abhängigkeiten der Partner voneinander und erlaubt somit die freie Auswahl konkurrierender Systeme und Partner nach rein funktionalen und wirtschaftlichen Gesichtspunkten. Ferner erleichtert die Unabhängigkeit der Standards von der Zu- sammensetzung der Projektpartner auch den schnellen Auf- bzw. Abbau neuer Zulieferer- /Abnehmerbeziehungen.

29 In diesen paarweisen Verbindungen legt man fest, welche Daten ausgetauscht werden, in welcher Sortierfolge sie vorlie- gen, wann sie übertragen werden, wie die Abstimmung erfolgt und wie Datenschutz/-sicherheit gewährleistet sind etc.

30 Diesbezüglich haben sich neutrale Datenformate als besonders vorteilhaft für die Archivierung erwiesen (etwa um bei Produktdaten trotz der immer kürzeren Lebenszyklen von Hard- und Software die Einhaltung der gesetzlichen Vor- schriften zur Produkthaftung zu gewährleisten) (vgl. [Lebe95, S. 44]).