Untersuchung der Möglichkeiten zur Automatisierung von Geschäftsprozessen, sowie Konzeption und prototypische Realisierung in das modulare Auftrags- und Fertigungssystem DIPPS

Inhaltsverzeichnis

Glossar

Abbildungsverzeichnis

Beispielverzeichnis

Tabellenverzeichnis

Anlagenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Problemstellung und Zielsetzung dieser Arbeit
1.2 Aufbau der Diplomarbeit
1.3 Arbeitsweise und Hilfsmittel

2 Grundlagen
2.1 Die wirtschaftlichen Entwicklungen
2.1.1 Die Globalisierung der Märkte
2.1.2 Der Begriff des E-Business
2.2 PPS-Systeme
2.3 Electronic Data Interchange (EDI)
2.3.1 Der Begriff des EDI
2.3.2 Die Geschichte des EDI
2.3.3 EDI in der Anwendung
2.3.4 Vorteile von EDI
2.3.5 Klassifikation von Standards

3 Die Kombination von PPS-Systemen und EDI
3.1 Ziele der Kombination allgemein
3.2 Ziele der Kombination für die Dresden Informatik GmbH

4 Konzeption
4.1 Ist-Analyse des DIPPS
4.1.1 Systemarchitektur
4.1.2 Entwicklungsumgebung des DIPPS
4.1.3 DIPPS-Datenmodell
4.2 Soll-Analyse des DIPPS
4.2.1 Anforderungen an den Prototyp
4.2.2 Testszenario
4.2.3 Änderungen am Datenmodell
4.2.4 Zusätzliche Änderungen am DIPPS
4.2.5 Ablauf des EDI im DIPPS

5 EDI (Electronic Data Interchange)
5.1 OAGIS
5.1.1 Allgemeines
5.1.2 Business Object Documents (BODs)
5.1.3 Die Kommunikation
5.1.4 Ausblick
5.2 RosettaNet
5.2.1 Allgemeines
5.2.2 Die Grundidee
5.2.3 Die Standards
5.2.4 Ausblick
5.3 BizTalk
5.3.1 Allgemeines
5.3.2 Die BizTalk Komponenten
5.3.3 Der Kommunikationsablauf
5.3.4 Ausblick
5.4 ebXML
5.4.1 Allgemeines
5.4.2 Der Ablauf eines Geschäfts in ebXML
5.4.3 Die ebXML Komponenten
5.4.3.1 Business Process Specification Schema (BPSS)
5.4.3.2 Registry/Repository
5.4.3.3 Collaboration-Protocol Profile (CPP) und Agreement (CPA)
5.4.3.4 Core Components
5.4.3.5 Messaging Service
5.4.4 Ausblick
5.5 UBL
5.5.1 Allgemeines
5.5.2 Aufbau der UBL
5.5.3 Business Information Entities (BIES)
5.5.4 Ausblick
5.6 xCBL
5.6.1 Allgemeines
5.6.2 Aufbau eines xCBL-Dokuments
5.6.3 Die unterstützten Schemasprachen
5.6.4 Zukunft von xCBL
5.7 UN/EDIFACT
5.7.1 Die Entwicklung des EDIFACT - Standards
5.7.2 Der Aufbau einer UN/EDIFACT-Nachricht
5.7.3 Die Kommunikation von UN/EDIFACT
5.7.4 Ausblick
5.8 cXML
5.8.1 Allgemeines zu cXML
5.8.2 Transportprotokolle
5.8.3 Die cXML Dokumente
5.8.4 Vor- und Nachteile von cXML
5.8.5 Ausblick

6 Vergleich von Techniken und Auswahl einer geeigneten Technik zur Implementierung
6.1 Auswahl der Kriterien
6.2 Auswahlverfahren
6.2.1 Einsatz des Standards und Investitionsschutz
6.2.2 Branchenspezifika
6.2.3 Flexibilität und Erweiterbarkeit
6.2.4 Kostenfaktor
6.2.5 Orientierung an offenen Standards
6.3 Zusammenfassung

7 Implementierung
7.1 Verwendete Technologien
7.1.1 eXtensible Markup Language(XML)
7.1.2 Java Web Services Developer Pack(JWSDP)
7.1.3 Java Native Interface(JNI)
7.1.4 Simple Object Access Protocol(SOAP)
7.2 Implementation des Prototypes
7.2.1 Implementation Phase
7.2.2 Discovery and Retrieval Phase
7.2.3 Run Time Phase
7.3 Zusammenfassung

8 Zusammenfassung und Ausblick

Anlagen

Literaturverzeichnis

Selbständigkeitserklärung

Glossar

API

Application Programmer Interface. Schnittstelle einer Programmbiblio­thek, mit der das Erstellen von Software erleichtert wird.

Applikation

Ein Programm, das eine bestimmte Aufgabe zu erfüllen hat.

B2B

Business-To-Business. - E-Commerce zwischen Unternehmen.

B2C

Business-To-Consumer. - E-Commerce zwischen Unternehmen und Endkunden.

Client

Eine Applikation oder ein Prozess, welcher Dienste von anderen Prozessen oder Komponenten auf - Servern anfordert.

Client-Server-Architektur

Ein Computermodell, in welchem Client-Applikationen Daten von entfernten Computern oder Servern anfordern. Der - Client dient der Interaktion mit dem Nutzer, der - Server stellt die Daten bereit.

Datenbank

Sammlung von Datenbankobjekten, zwischen denen Beziehungen bestehen. Dazu gehören Tabellen, Abfragen, Integritätsregeln und Indizes.

DCOM

Distributed Component Object Model., - Protokoll, das Softwarekomponenten die direkte Kommunikation über ein Netzwerk ermöglicht.

Delphi

Borland Delphi. Entwicklungsumgebung für Windows, in welcher die Objekt-Orientierte Sprache ObjectPascal eingesetzt wird.

DIPPS

Ein von der Dresden Informatik GmbH entwickeltes und vertriebenes - PPS-System.

DLL

Dynamic Link Library. Eine Bibliothek mit ausführbaren Programmen, auf die von anderen Programmen zugegriffen werden kann.

DTD

XML Document Type Definitions. Definiert das Format eines XML-Dokuments.

E-Commerce

Electronic Commerce. Kaufen und Verkaufen von Waren und Leistungen über das Internet oder andere Online-Medien.

EDI

Electronic Data Interchange. Elektronischer Datenaustausch von Geschäftsdaten.

Fakturierung

Stellt Bindeglied zwischen Produktion und dem Umsatz dar.

Formular

Teil einer HTML-Seite, wo Daten eingegeben werden können, die zum Server gesandt werden. In Delphi und DIPPS werden Anwendungsfenster als Formular bezeichnet.

FTP

File Transfer Protocol. - Protokoll zur Übertragung von Dateien zwischen zwei Rechnern. Es wird im - Internet oder in lokalen Netzen eingesetzt, die auf - TCP/IP-Basis arbeiten.

GUID

Globally Unique Identifier. Weltweit eindeutiger Identifikator.

HTTP

Hypertext Transfer Protocol. - Protokoll für die Kommunikation zwischen Webserver und Webclients.

Interface, Schnittstelle

Satz von Regeln/Methoden zur Interaktion von Objekten, die keine Verbindung zueinander haben.

Internet

Zusammenschluss vieler Computer und Computernetzwerke zum Datenaustausch. Die Kommunikation erfolgt über - TCP/IP und die darauf aufbauenden - Protokolle. Anderes Wort: - WWW.

Java

Plattformunabhängige Objekt-Orientierte Programmiersprache von SUN Microsystems.

JRE

Java Runtime Environment. Das JRE enthält alle Komponenten, die für die Ausführung von Java-Programmen benötigt werden.

JVM

Java Virtuelle Machine. Virtuelle CPU, die das Java-Programm in plattformabhängige Betriebssystembefehle umwandelt.

MIME

Multipurpose Internet Mail Extensions. Standard zur Beschreibung von verschiedenen Datenformaten für den Versand über das - Internet.

OMG

Object Management Group. Die OMG ist ein Standardisierungsgremium.

PPS-System

Softwaresystem zur Produktionsplanung und –Steuerung.

Protokoll

Standard für die kontrollierte Übermittlung von Daten.

Prototyp

Unfertige - Applikation mit eingeschränkter Funktionalität, welche Test- und Präsentations-zwecken dient.

Request

Vom Client an den Server geschickte Anforderung. Der Server reagiert darauf mit einer Antwort (- Response).

Response

Antwort auf Anfragen (- Request).

SCM

Supply Chain Management. Prozess der Rationalisierung der Wertschöpfungskette.

Server

Computer, der anderen Computern in einem Netzwerk Daten und Ressourcen zur Verfügung stellt.

SMTP

Simple Mail Transport Protocol. Protokoll zum Versand von e-Mails.

SOAP

Simple Objects Access Protocol. Standard zur prozessübergreifenden Kommunikation. Übertragung von XML-Daten über TCP/IP.

SOX

Schema Language for Object-Oriented XML. Wurde durch die Firma Commerce One als Schemasprache entwickelt und überwiegend für die eigenen Produkte genutzt.

Stammdaten

Daten innerhalb des - PPS-Systems, die über längere Zeit zur Verfügung stehen. z.B. Artikel, Kunden, Lieferanten.

TCP/IP

Transmission Control Protocol/Internet Protocol. Kommunikationsstan­dard für Netzwerke. Basis des Internets.

UML

Unified Modelling Language. Modellierungssprache zur grafischen Beschreibung von Objekt-Orientierten Modellen, welche durch die - OMG standardisiert ist.

URL

Uniform Resource Locator. Eine eindeutige Adresse im - World Wide Web.

W3C

World Wide Web Consortium. Koordiniert die Entwicklung des WWW und die Standardisierung von HTML, XML und deren Derivate.

WinCVS

Windows Concurrent Version System. Programm zur Versionskontrolle von gleichzeitig benutztem Quellcode.

WWW

World Wide Web. - Das Internet.

XDR

XML Data-Reduced. Schema zum Definieren von XML -Dokumenten, welches überwiegend in Microsoft´s BizTalk Umgebung verwendet wird.

XMI

XML Metadata Interchange. Format zur Darstellung eines - UML-Modells.

XML

Extensible Markup Language. Ein Datenformat zur Strukturierung von Dokumenten mit einem flexiblen und anwendungsspezifisch erweiterbaren Sprachschatz.

XML-Schema

Wie eine DTD definiert auch diese das Format eines XML-Dokuments, jedoch mit anderer Syntax.

XSD

XML Schema Definition. siehe XML Schema

XSDL

XML Schema Definition Language. Sprache zum Formulieren von Schemata.

ZIP

Programm, dass eine Komprimierung von Dateien für den schnelleren Versand über das - Internet ermöglicht.

Abbildungsverzeichnis

Abbildung 1: Die 3-Schichten Architektur des DIPPS

Abbildung 2: Use-Case Diagramm einer Bestellung

Abbildung 3: State-Diagramm einer Bestellung

Abbildung 4: E2E-Integration in OAGIS(aus [OAGIS WP 2003] S.7)

Abbildung 5: Grundstruktur einer BOD

Abbildung 6: Vergleich der Kommunikation(aus [ROSETTA 2003] Background)

Abbildung 7: Dokumentenaustausch mit BizTalk(aus [BIZTALK 2003] S.9)

Abbildung 8: Geschäftsablauf zwischen Partnern in ebXML(aus [EBXML-TA 2003] S.8)

Abbildung 9: Ablauf einer Kollaboration (aus [EBXML-BPSS 2003] S.16)

Abbildung 10: Aufbau der ebXML-Registry(aus [EBXML-TA 2003] S.25)

Abbildung 11: Überblick über CPP(aus [EBXML-CPP 2003] S.14)

Abbildung 12: Ablauf der Vereinbarungsphase (aus [EBXML-CPP 2003] S.14)

Abbildung 13: Struktur einer ebXML-Nachricht(aus [EBXML-MS 2003] S.12)

Abbildung 14: UBL Entwicklungsschema(aus [UBL 2003])

Abbildung 15: Darstellung einer BIE als XML-Schema und als Spreadsheet

Abbildung 16: UN/EDIFACT Element in XML-Syntax

Abbildung 17: Umfrage zu Prozessstandards (aus [BERLECON 2003] S.159)

Abbildung 18: ebXML Implementation

Abbildung 19: Erstellung eines CPP

Abbildung 20: CPP/CPA-Generator

Beispielverzeichnis

Beispiel 1: UN/EDIFACT-Nachricht im Streamformat (aus [EDIFACTORY 2003] )

Beispiel 2: Konfiguration von JVM in Delphi

Beispiel 3: Java Methode setEMailAddress

Beispiel 4: Nutzung von Java-Methoden in Delphi

Beispiel 5: ebXML Business Transaction

Beispiel 6: ebXML Business Document

Beispiel 7: ebXML BinaryCollaboration

Beispiel 8: Servlet zur synchronen Verarbeitung von SOAP-Nachrichten

Beispiel 9: Anwendung der JAXB

Beispiel 10: Erstellung einer ebXML-Nachricht

Tabellenverzeichnis

Tabelle 1: Überblick über EDI-Standards

Tabelle 2: Übersicht Auswahlverfahren

Anlagenverzeichnis

Anlage 1: BOD zur Anfrage der Verfügbarkeit eines Produktes(aus [OAGIS 2003])

Anlage 2: UML-Modell des RIM(aus [EBXML-RIM 2003] S. 11)

Anlage 3: CPP-Beispiel(aus [EBXML-CPP 2003] S. 94ff)

Anlage 4: Beispiel einer ebXML-Nachricht (aus [EBXML-MS 2003] S. 59)

Anlage 5: Struktur eines UBL-Dokumentes als XML-Schema(aus [UBL 2003])

Anlage 6: xCBL-Dokument über Status einer Bezahlung (aus [XCBL 2003])

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Problemstellung und Zielsetzung dieser Arbeit

In der heutigen Zeit, in welcher der Konkurrenzdruck zwischen Mitbewerbern in den verschiedensten Wirtschaftsgebieten immer mehr zunimmt, ist es von Nöten, den Informationsfluss in einem Unternehmen zu optimieren und damit die Kosten zu senken, um auch weiterhin konkurrenzfähig zu sein.

Die Firma Dresden Informatik GmbH entwickelt und vertreibt für diesen Zweck ein PPS-System namens DIPPS. Dieses ermöglicht es, den gesamten Informationsfluss in einem Unternehmen über den Vertrieb, die Auftragsbearbeitung, die Fertigungssteuerung, die Fertigungsplanung, die Lager- und Materialwirtschaft, den Einkauf bis hin zum Rechnungs- und Personalwesen hinaus, optimal zu koordinieren.

Eine immer größer werdende Rolle spielt dabei auch der Begriff des E-Business, insbesondere im Bereich des Business-To-Business (B2B). Dabei handelt es sich um nichts anderes, als „die digitale Abwicklung von Geschäftsprozessen zwischen Unternehmen“^[1].

Wenn man überlegt, dass rund „80 % der deutschen Unternehmen zuviel für ihre Geschäftsprozesse zahlen“^[2] kann man erkennen, dass in diesem Bereich noch ein hohes Einsparpotenzial vorhanden ist. Ein Grund für diese Mehrkosten ist, dass sie die Vorteile einer Automatisierung zwar erkennen, sich allerdings nicht trauen, diesen Schritt zu gehen. Sie vollziehen ihre Geschäftstransaktionen mit anderen Unternehmen lieber weiterhin auf dem manuellen und papierbasiertem Wege.

Das Ziel dieser Diplomarbeit liegt darin, Techniken zu untersuchen, mit welchen es möglich ist, die Geschäftsprozesse von Unternehmen untereinander zu automatisieren. Anschließend soll - nach Abwägung der Vor- und Nachteile der einzelnen Techniken - die für die Firma Dresden Informatik GmbH geeignetste Technik gefunden und in das modulare Auftrags- und Fertigungssystem DIPPS prototypisch integriert werden.

1.2 Aufbau der Diplomarbeit

Diese Diplomarbeit ist in acht Kapitel untergliedert. Im Anschluss an die in Kapitel eins gegebene Einleitung sollen in Kapitel zwei Grundlagen für das Verständnis der Diplomarbeit gegeben werden. Hier wird über den Sinn und den Nutzen von PPS-Systemen philosophiert und der Begriff des EDI erläutert. Im danach folgenden Kapitel drei soll über den Sinn und die Notwendigkeit des elektronischen Datenaustausches in Verbindung mit PPS-Systemen generell sowie für das PPS-System DIPPS der Firma Dresden Informatik GmbH im Speziellen nachgedacht werden.

Im vierten Kapitel wird dann die Konzeption des Projektes erarbeitet. Dazu wird eine Ist/Soll-Analyse durchgeführt, welche das DIPPS und seine Möglichkeiten zum jetzigen Zeitpunkt beschreibt und es werden Anforderungen an den Prototyp gestellt, die dieser erfüllen soll.

Im fünften und umfangreichsten Kapitel, werden mehrere Standards, die für die Durchführung des elektronischen Datenaustausches zwischen Unternehmen verwendet werden können betrachtet, ehe diese im sechsten Kapitel verglichen werden. Hier soll anhand von Auswahlkriterien eine geeignete Technik gefunden werden, die für das DIPPS prototypisch umgesetzt werden soll. Das siebte Kapitel betrachtet dann den Vorgang der Implementation des in vorangegangen Kapitel ausgewählten Standards für das DIPPS.

Im achten und letzten Kapitel soll anschließend eine Zusammenfassung über diese Arbeit gegeben und mit einem Ausblick für die weitere Nutzung des Prototyps abgeschlossen werden.

1.3 Arbeitsweise und Hilfsmittel

Zur Anfertigung dieser Diplomarbeit wurde als Textverarbeitungsprogramm Microsoft Word XP und zur Erstellung der UML Diagramme der Enterprise Architect von der Firma Sparx Systems in einer Testversion verwendet. Zur Recherche wurde neben Fachbüchern auch das Internet zur Hilfe genommen. Die verwendeten Quellen wurden im Literaturverzeichnis vermerkt und im Text wurde mit Fußnoten darauf verwiesen. Weiterhin wurden im Text Abkürzungen verwendet, die in einem Abkürzungsverzeichnis ausgeschrieben sind. Im Text verwendete Fremdwörter wurden im Glossar erklärt.

2 Grundlagen

In diesem Kapitel sollen die Grundlagen für ein besseres Verständnis der Diplomarbeit vermittelt werden. Zunächst soll auf die wirtschaftlichen Entwicklungen eingegangen werden, ehe danach der Sinn und die Notwendigkeit von PPS-Systemen aufgezeigt werden soll. Danach soll der Begriff von EDI erläutert und dessen Sinn erklärt werden.

2.1 Die wirtschaftlichen Entwicklungen

2.1.1 Die Globalisierung der Märkte

Zunächst stellt sich die Frage, was man überhaupt unter dem Begriff der Globalisierung versteht. „Globalisierung ist die weltweite Verflechtung, in erster Linie die wirtschaftliche“^[3]. Der Begriff der Globalisierung kam erst Anfang der 90er Jahre auf und bedeutet soviel wie das weltweite Zusammenwachsen der regionalen und kontinentalen Märkte zu einem gemeinsamen Markt. Der Hauptgrund dafür ist die rasante Entwicklung neuer Technologien. Eine dieser Technologien ist das Internet, welches sich in den letzten Jahren weltweit rasant verbreitet hat. Durch dieses Medium ist es möglich, über Staatsgrenzen hinweg, schnell und kostengünstig Informationen mit anderen Unternehmen oder Normalbürgern auszutauschen und somit auch Handel zu betreiben. Damit sind alle Unternehmen gezwungen, an der fortschreitenden Globalisierung teilzunehmen, da sonst die Gefahr besteht, auf der Strecke zu bleiben.

2.1.2 Der Begriff des E-Business

„Nach einer allgemeinen Definition ist Electronic Business (E-Business) jede geschäftliche Transaktion, deren Teilnehmer elektronisch interagieren“.^[4]

Des weiteren gibt es den Begriff des E-Commerce, welcher eine Untermenge des E-Business ist. Unter diesem Begriff sind alle Arten elektronischer Vermarktung und der Handel von Waren und Dienstleistungen über elektronische Medien, wie das Internet, zusammengefasst. Beim E-Commerce unterscheidet man noch zwischen zwei Formen: Zum einen wäre dies der Handel zwischen Unternehmen und Endkunden, Business-To-Consumer (B2C) und zum anderen der Handel zwischen Unternehmen untereinander, Business-To-Business (B2B).

Letzterer hat dabei die weitaus größere Bedeutung und dieser Trend wird, laut Studien^[5] vom Investmenthaus Goldman Sachs, die für 2004 mit einem Volumen von 1,5 Billionen Dollar rechnen, auch weiterhin anhalten.

2.2 PPS-Systeme

PPS ist die Abkürzung für Produktions-, Planungs- und Steuerungssysteme. Unter diesem Begriff versteht man „den Einsatz rechnerunterstützter Systeme zur organisatorischen Planung, Steuerung und Überwachung der Produktionsabläufe von der Angebotsbearbeitung bis zum Versand unter Mengen, Termin- und Kapazitätsaspekten.“^[6]

Die PPS-Hauptfunktionen^[7] sind:

- Produktionsprogrammplanung

In der Produktionsprogrammplanung wird festgelegt, welche Mengen welcher Produktarten in einem bestimmten Zeitraum hergestellt werden sollen.

- Mengenplanung

In der Mengenplanung wird festgelegt, welche Mengen an Vor- und Zwischenprodukten für die Produktion benötigt werden.

- Termin- und Kapazitätsplanung

Hier wird geplant, wann ein Zwischenprodukt hergestellt bzw. bestellt werden muss und mit welcher verfügbaren Kapazität dieser Fertigungsauftrag durchgeführt werden soll.

- Auftragsveranlassung

Sobald alle nötigen Ressourcen frei sind, wird hier der Fertigungsauftrag veranlasst.

- Auftragsüberwachung

Hier wird darüber gewacht, in wie weit die Durchführung eines Auftrags vorangeschritten ist.

Eine weitere wichtige Aufgabe eines PPS-Systems ist es, die Stammdaten zu verwalten und zu pflegen, da diese Daten die Grundmenge für alle Aktionen in dem System sind.

Der Nutzen von PPS-Systemen liegt darin begründet, dass die Lagerbestände möglichst gering gehalten werden sollen, um somit weniger Kapital zu binden. Des weiteren kann man den Ausschuss und damit auch eine eventuelle Nacharbeit am Produkt vermeiden. Als letzter direkter Nutzen bleibt zu nennen, dass man eine genauere (Vor-) Kalkulation vornehmen, sowie eine schnellere Fakturierung gewähren kann. Zu den indirekten Nutzen von solchen Systemen gehören eine höhere Transparenz über den Produktionsablauf, ein höherer Auftragsdurchsatz sowie eine höhere Qualität der produzierten Waren.

2.3 Electronic Data Interchange (EDI )

2.3.1 Der Begriff des EDI

EDI steht für Electronic Data Interchange und bedeutet übersetzt Elektronischer Daten-austausch. Ausgetauscht werden hier Geschäftsdaten unter Anwendung eines standardisierten Formates. Diese Standards sind notwendig, um die Unternehmensdaten in einer strukturierten Form und Reihenfolge zu übertragen, um diese korrekt interpretieren und weiterverarbeiten zu können. Ein Beispiel für nicht strukturierte Informationen ist eine E-Mail. Hier ist es nicht vorgeschrieben, in welchem Abschnitt das Datum platziert werden soll. Es kann also links oben oder auch rechts unten platziert werden. Des weiteren ist in diesen Standards beschrieben, wie diese Daten dann in Nachrichten verpackt werden, um über die Kommunikationsmedien übertragen werden zu können. Damit ermöglicht EDI „einen medienbruchlosen Informationsfluss zwischen verschiedenen Computersystemen“^[8].

2.3.2 Die Geschichte des EDI

„Seit den späten 60er Jahren nutzen Unternehmen EDI (Electronic Data Interchange) zum elektronischen Austausch strukturierter Geschäftsdokumente wie Bestellungen, Rechnungen etc.“^[9] Es fing zunächst damit an, dass Unternehmen über private, nicht öffentliche Netzwerke, so genannte VAN’s (Value Added Networks), geschäftsbezogene Daten untereinander austauschten, sowie diese Daten auch im innerbetrieblichen Netzwerk weiterleiteten. Jedoch entwickelten sich die ersten EDI-Standards erst in den frühen 80er Jahren. Diese wurden zuerst für einzelne Unternehmen entwickelt, was allerdings später zu Kompatibilitätsproblemen führte. Danach ging man dazu über, branchenspezifische Standards zu schaffen und später kamen dann auch noch länderspezifische Standards dazu.

Einen Überblick über diese Standards bietet die folgende Tabelle^[10]:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Überblick über EDI-Standards

Nach diesem Überblick soll nun etwas näher auf einige dieser Standards eingegangen werden.

UN/EDIFACT Auf diesen Standard soll im Punkt 5.7 näher eingegangen werden.

EANCOM^[11] Dies ist ein 100 %-ig kompatibles Subset von UN/EDIFACT. Hier ist anders, dass optionale Bestandteile aus den UN/EDIFACT Nachrichten entfallen können. Er wurde nur aus den tatsächlich, sowie optionalen Bestandteilen aufgebaut, welche als unbedingt benötigt angesehen wurden..

SEDAS S tandardregelung E inheitlicher D atenaust a usch s ysteme wurde in den 80er Jahren in Deutschland und Österreich für die Konsumgüterindustrie entwickelt und eingesetzt. Mittlerweile wird dieser Standard jedoch von dem UN/EDIFACT-Subset EANCOM immer mehr verdrängt.

ODETTE O rganisation for D ata E xchange by T ele T ransmission in E urope wird in der Europäischen Automobilbranche eingesetzt und ist zu einem Subset von UN/EDIFACT geworden. Diese Organisation nimmt auch an der Weiterentwicklung von UN/EDIFACT teil.

SWIFT S ociety for W orldwide I nterbank F inancial T elecommunication ist eine Organisation der Banken, welche den weltweiten Interbankverkehr, mittels SWIFT-Nachrichten regelt.

EDIFICE Dies ist die EDI-Organisation der Europäischen Elektronik-Industrie. Das EDIFICE-Subset ist wiederum eine Untermenge des UN/EDIFACT-Standards.

ANSI X.12 A merican N ational S tandards I nstitute, X.12 war der erste von einer Normungsorganisation registrierte Standard, der sich aber nur auf dem nordamerikanischen Markt durchgesetzt hatte. Er war zusammen mit der GTDI-Standard Basis für das UN/EDIFACT.

GTDI G uidelines on T rade D ata Interchange wurde Anfang der 80er Jahre in Großbritannien für den Europäischen Markt entwickelt. Dieser Standard war zusammen mit dem ANSI X.12 Standard die Basis für das spätere UN/EDIFACT.

Wie man sieht, hat sich UN/EDIFCAT zum globalen Standard im Traditionellen EDI entwickelt. Für andere Standards kann das Ziel nur lauten, sich UN/EDIFACT zu beugen und den eigenen Standard zu UN/EDIFACT kompatibel werden zu lassen.

2.3.3 EDI in der Anwendung

EDI ist im Allgemeinen in den USA am weitesten verbreitet und auch hier, sowie im Rest der Welt, zum größten Teil unter Großunternehmen, die sich die hohen Setup- und Betriebskosten für das traditionelle EDI leisten konnten. Nur vereinzelt nutzen auch kleine und mittelständige Unternehmen (KMU) diese Möglichkeit des Datenaustausches, da sie quasi von ihren großen Geschäftspartnern dazu genötigt werden. Im Zusammenhang mit diesem Zwang machte auch der Begriff des „EDI or die“^[12] die Runde. Man ging damals davon aus, dass man ohne EDI keine Geschäfte mehr machen könne und die Unternehmen, die sich EDI verweigerten, zu Grunde gehen würden. Es stellte sich jedoch heraus, dass diese Annahme überzogen war. Doch mit Hilfe der neuen Techniken XML, sowie dem Internet, kann sich das Blatt nun drehen und EDI könnte auch für KMU erschwinglich werden.

Ein weiterer Grund für die weite Verbreitung in den USA ist darin zu sehen, dass hier auch die Regierungsstellen immer mehr ihrer Aufträge elektronisch vergeben und somit viele Firmen gezwungen sind, auf diesen Zug aufzuspringen, um weiterhin staatliche Aufträge zu erhalten. „In Nord Amerika gab es im Jahre 1999 bereits 6 Millionen Firmen die EDI-Lösungen nutzten.“^[13]

2.3.4 Vorteile von EDI

Die Vorteile von EDI liegen darin, dass man ein hohes Einsparpotential an Zeit, Arbeitskraft und damit auch an Geld, sowie an Portokosten erzielt. Man muss Daten in einer Ablaufkette nicht mehr manuell in die verschiedenen Systeme eingeben, da dieses äußerst ineffizient, zeitraubend und fehleranfällig ist. „Es wird geschätzt, dass zwischen 70 % und 95 % aller in ein System neu einzugebender Inhalte mehrfach eingegeben werden, obwohl sie auf einem anderen System schon zur Verfügung stehen.“^[14] Ein weiterer wichtiger Vorteil von EDI ist, dass man durch die schnelle Verfügbarkeit der Daten die Möglichkeit hat, schneller auf Einflüsse von Außen zu reagieren und somit die Lagerhaltung möglichst gering zu halten und auch die damit verbundene Kapitalbindung zu senken. Des weiteren bleibt zu nennen, dass man viel schneller Angebote einholen kann und man damit immer auf dem aktuellen Stand des Marktes ist. Außerdem können Kunden schneller erreicht und bedient werden und damit wird eine höhere Bindung der Kunden an die Unternehmen erzielt.

Man kann mit EDI somit den Ablauf einer Versorgungskette effektiv gestalten und hohe Rationalisierungspotenziale nutzen. Dieser ganze Prozess wird als Supply Chain Management (SCM) bezeichnet.

Zusammenfassend kann man EDI auch „als eine Technologie zur Reorganisierung der Wertschöpfungskette bezeichnen.“^[15]

2.3.5 Klassifikation von Standards

Man kann die Standards für den Datenaustausch anhand ihrer Möglichkeiten klassifizieren. Man unterscheidet dabei in drei Kategorien:

- Katalogdaten-Standard

Dieser Standard hat das Ziel, den Austausch von Katalogdaten zu vereinfachen. Unter einem Katalog versteht man eine Sammlung von Produktdaten inklusive Preisen und Beschreibungen, welche zusätzlich noch Bilder und andere multimedialen Inhalte enthalten können.

- Transaktions-Standard

Die Transaktionsstandards setzen auf den Katalogdatenstandards auf und kümmern sich um das weitere Vorgehen des Geschäftes, wie z.B. eine Bestellung und anschließende Bezahlung. Dazu werden Geschäftsdokumente ausgetauscht, welche die Struktur der auszutauschenden Geschäftsdaten beschreiben.

- Geschäftsprozess-Standard

Die Geschäftsprozess-Standards haben noch ein höheres Niveau. Hier werden nicht nur Daten ausgetauscht, sondern komplexe Geschäftsprozesse bis ins Detail modelliert. Dazu werden alle möglichen Abfolgen eines Geschäftes betrachtet und für diese die jeweiligen Folgeschritte festgelegt. Somit soll ein Geschäft weitestgehend automatisch ablaufen, was eine Zeit- und damit auch Kostenersparnis mit sich zieht.

Im fünften Kapitel sollen Standards betrachtet werden, welche die neue XML-Technologie nutzen. Dabei sollen diese nach der Klassifikation eingeordnet werden.

3 Die Kombination von PPS-Systemen und EDI

3.1 Ziele der Kombination allgemein

Es gibt viele Ziele, die mit der Kombination von PPS-Systemen und EDI verwirklicht werden sollen. Der Großteil wurden bereits im vorangegangen Kapitel aufgezeigt. Man kann diese Ziele allerdings zu einem Primärziel zusammenfassen. Dieses Ziel ist die Verbesserung der Wettbewerbsfähigkeit des PPS-System einsetzenden Unternehmens. Dazu zählt zum einen die Kostenreduzierung, z.B. für das Versenden von Geschäftsdaten, aber auch, um den Ablauf bereits bestehender Geschäftsprozesse zu optimieren, um z.B. schneller neues Material zur Weiterverarbeitung zu ordern.

3.2 Ziele der Kombination für die Dresden Informatik GmbH

Die Ziele für die Firma Dresden Informatik GmbH liegen darin, eine neue Technik in ihr PPS-System DIPPS zu integrieren, mit welcher Geschäftsprozesse optimiert werden können. Die Gründe für diese Entscheidung sind, dass bereits Anfragen aus Kundenkreisen kamen, die eine Automatisierung von Geschäftsprozessen betreffen. Bisher ist im DIPPS noch keine solche Möglichkeit vorhanden, so dass nun, auf Grund der guten Zukunftsaussichten solcher Techniken, die Implementierung für das DIPPS voran getrieben werden soll.

Damit soll den Unternehmen, die als potenzielle Kunden gelten, ein weiterer Anreiz geboten werden, sich für das DIPPS und damit gegen andere Mitbewerber zu entscheiden.

4 Konzeption

In diesem Abschnitt soll das PPS-System DIPPS der Firma Dresden Informatik GmbH betrachtet werden, für welches eine Optimierung der Geschäftsprozesse erzielt werden soll. Anschließend sollen die Anforderungen an den Prototypen festgelegt und grundlegende Änderungen im DIPPS niedergeschrieben werden.

4.1 Ist-Analyse des DIPPS

Das DIPPS ist ein von der Firma Dresden Informatik GmbH entwickeltes und vertriebenes PPS-System, welches auch firmenintern zur Anwendung kommt. Im folgenden soll näher auf die Architektur des DIPPS eingegangen werden.

4.1.1 Systemarchitektur

Das DIPPS ist ein modulares PPS-System, welches alle wesentlichen Geschäftsprozesse in klein- und mittelständischen Unternehmen der herstellenden Industrie unterstützt. Zu den einzelnen Modulen, die separat vom Kunden gewählt werden können, gehören neben dem Systemkern- und Stammdatenverwaltungsmodul unter anderem

- das Einkaufs-,
- das Verkaufs-,
- das Kalkulations-,
- das Materialwirtschafts- und
- das Fertigungsmodul.

Das DIPPS besteht aus drei Schichten. Jede dieser Schichten ist eine eigenständige Einheit, welche bei Bedarf auf getrennten Rechnern installiert werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Die 3-Schichten Architektur des DIPPS

Die drei Schichten sind folgende(siehe Abbildung 1):

- DIPPS-Client

Die Client-Anwendung stellt die Benutzeroberfläche auf dem Rechner eines Benutzers bereit. Hier kann der Nutzer Daten eingeben oder auch Einstellungen vornehmen. Der DIPPS-Client ist auf x86-Workstations mit Microsoft-Betriebssystem ab Windows 95 bzw. Windows NT4 lauffähig.

- DIPPS-Server

Dieser befindet sich an einer zentralen Stelle im Netzwerk, damit die DIPPS-Clients auf ihn zugreifen können. Er stellt Dienste bereit, damit mit den Daten vom Datenbank-Server gearbeitet werden kann. Die Verbindung zur Datenbank wird mittels der Borland Database Engine (BDE) hergestellt. Der DIPPS-Server ist auf x86-Workstations mit Microsoft-Betriebs-system ab NT4.0 lauffähig.

- Datenbank-Server

Auf dem Datenbank-Server befindet sich das relationale Datenbank-System, welches die Daten beinhaltet. Die Daten werden vom DIPPS-Server aus an den Datenbankserver übermittelt bzw. vom Datenbankserver für den DIPPS-Server bereitgestellt. Als Datenbanksystem kann derzeit neben ORACLE auch Interbase genutzt werden.

Die Kommunikation der 3-Ebenen Architektur wird mittels des Distributed Component Object Model (DCOM) realisiert, welches die Kommunikation von Software-Komponenten in einem Netzwerk regelt^[16].

4.1.2 Entwicklungsumgebung des DIPPS

Die Entwicklung des DIPPS erfolgt mit Hilfe von Borland Delphi in der Version 6 unter den Microsoft Betriebssystemen Windows NT4, Windows 2000 sowie Windows XP. Borland’s Delphi ist eine Programmiersprache, die eine Objekt-Orientierte Programmierung unterstützt.

Zur Versionskontrolle der Quellcodes wird WinCVS eingesetzt, damit unkontrollierte Änderungen am Quellcode vermieden werden.

4.1.3 DIPPS-Datenmodell

Das DIPPS-Datenmodell umfasst eine Vielzahl von Tabellen zur Speicherung der Anwender- und Systemdaten des DIPPS. Ein Hauptteil der Daten umfasst der Artikelstamm, welcher durch verschiedene Tabellen repräsentiert wird. Ein weiterer wichtiger Teil ist der Kundendatenstamm, in welchem alle Informationen über Kunden hinterlegt sind. Dazu kommen noch Daten über Angebote an Kunden und Allgemeine Daten über Währungen oder Steuersätze.

4.2 Soll-Analyse des DIPPS

Das Ziel dieser Arbeit ist die Untersuchung von Standards, mit welchen Geschäftsvorgänge im DIPPS mit anderen Unternehmen automatisiert und damit schneller durchgeführt werden können. Nachdem alle Möglichkeiten gefunden wurden, soll die für das DIPPS geeignetste Variante umgesetzt werden, damit anschaulich gezeigt werden kann, wie ein solcher Prozess von statten gehen kann. Dazu werden hier alle Anforderungen an den Prototypen beschrieben, sowie ein Testszenario erstellt.

4.2.1 Anforderungen an den Prototyp

An den Software-Prototypen werden die folgenden Anforderungen gestellt:

- Die Implementation des Prototyps soll mit möglichst geringem Kostenaufwand von statten gehen.
- Die Implementation des Prototyps soll möglicht mit innovativen Technologien von statten gehen, welche gute Chancen haben, in Zukunft einen hohen Verbreitungsgrad zu haben, um eine langjährige Nutzung zu gewährleisten.
- Die Automatisierung eines Geschäftsprozesses soll anhand eines Beispieles gezeigt werden. Dafür ist der Vorgang einer einfachen Bestellung gut geeignet.
- Die prototypische Anwendung soll möglichst direkt aus dem DIPPS erfolgen, um die Anwendung zu vereinfachen.

4.2.2 Testszenario

Um die Funktionalität testen zu können, empfiehlt es sich, ein Szenario zu erstellen, dass anschließend bei der Implementierung, mit welcher Technik auch immer, umgesetzt werden soll.

Dazu soll hier ein einfacher Bestellvorgang dienen. Eine Bestellung wird immer zwischen zwei Akteuren ausgeführt. In der folgenden Abbildung ist dies in einem einfachen UML Use-Case Diagramm dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Use-Case Diagramm einer Bestellung

Im folgenden sollen die Einzelschritte wiedergegeben werden, die bei einer einfachen Bestellung auftreten.Zunächst wird vom Käufer die Bestellunganfrage an den Verkäufer gesendet. Dieser hat anschließend zwei mögliche Optionen: Zum einen hat er die Möglichkeit, den Kunden zu bedienen. Dann würde eine Bestätigung versendet werden. Zum anderen kann er dem Kunden das Gewünschte nicht liefern, dann würde eine Absage versendet werden. Die Abläufe dieser Bestellung kann man in folgendem UML State-Diagramm wiedergeben:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: State-Diagramm einer Bestellung

4.2.3 Änderungen am Datenmodell

Für eine Automatisierung von Geschäftsprozessen kommen eine Vielzahl von Daten in Betracht.

Dabei soll für die prototypische Umsetzung jedoch das Hauptaugenmerk auf den Artikelstamm und auf die Kundendaten gelegt werden, da diese für eine Bestellung nötig sind. Jedoch ist es nicht von Nöten, größere Änderungen am Datenmodell vorzunehmen, da die vorhandenen Daten wie sonst auch genutzt werden sollen, allerdings auf einem anderen, automatisierten Übertragungsweg. Denkbar ist allerdings die Erstellung einer neuen Tabelle, wo die auto-matisierten Vorgänge festgehalten werden. Diese kann z.B. Referenzen auf die automatisiert durchgeführten Aktionen haben und noch Angaben über deren aktuellen Status beinhalten.

4.2.4 Zusätzliche Änderungen am DIPPS

Um eine Geschäftsnachricht zu versenden ist es nötig, eine Technik zu implementieren, mit der dieses getätigt werden kann. Möglichkeiten wären hier der Transport über HTTP, FTP und SMTP. Es sind aber auch noch Techniken wie SOAP denkbar, welches als Umschlag für eine Nachricht dient.

4.2.5 Ablauf des EDI im DIPPS

Da ein automatisierter Geschäftsprozess ohne weitere Eingriffe ablaufen soll, wird es nicht nötig sein, im DIPPS großartige Änderungen vorzunehmen. Änderungen, die durch den Ablauf eines Geschäftsprozesses am Datenbestand getätigt werden, könnten direkt in der Datenbank modifiziert werden. Denkbar ist hier die Erstellung eines neuen Formulars für das DIPPS, in welchem die automatisierten Vorgänge extra dargestellt werden und wo deren aktueller Status gezeigt wird. Weiterhin sollen hier alle nötigen Einstellungen für die Durchführung eines Geschäftsprozesses gemacht werden.

5 EDI (Electronic Data Interchange)

In diesem Kapitel sollen nun verschiedene Techniken, welche zum Automatisieren von Geschäftsprozessen genutzt werden können, vorgestellt werden. Dabei soll das Hauptaugen-merk auf den Geschäftsprozess-Standards liegen, welche die eigentliche Automatisierung zur Aufgabe haben. Dazu zählen die folgenden Standards:

- OAGIS
- RosettaNet
- BizTalk
- ebXML
- UBL

Des weiteren sollen auch noch kurz Katalogdaten- bzw. Transaktions-Standards betrachtet werden, da diese ebenfalls für die Übertragung von Geschäftsdaten genutzt werden können, aber keine Automatisierung von Prozessen ermöglichen. Diese da wären:

- xCBL
- UN/EDIFACT
- cXML

Man kann Standards anhand ihrer Fähigkeiten in drei Kategorien unterteilen:

- Frameworks

Dies sind die so genannten Basistechnologien, bei welchen neben dem strukturierten Dokumentenaustausch zwischen Unternehmen, auch hauptsächlich die Kommunikationsprozesse im Vordergrund stehen. Beispiele dafür sind BizTalk, ebXML sowie RosettaNet.

- Functions oder Horizontals

Hierbei handelt es sich um branchenübergreifende Vorlagen für spezifische Geschäftsoperationen. Beispiele hierfür sind xCBL, OAGIS.

- Verticals

Hierbei handelt es sich um den Nachrichtenaustausch innerhalb einer Branche. Ein Beispiel für Verticals ist die FpML, welche im Finanzwesen Anwendung findet.

[...]

---

^[1] vgl. [WEITZEL 2001], S. 1

^[2] vgl. [SILICON 2002]

^[3] vgl. [WEISZÄCKER 2003]

^[4] vgl. [WEITZEL 2001]

^[5] vgl. [GOLDMAN 2003]

^[6] vgl. [HESTERMANN 2003]

^[7] vgl. [HESTERMANN 2003]

^[8] vgl. [WEITZEL 2001] S. 6

^[9] vgl. [WEITZEL 2001] S. 6

^[10] vgl. [VISIONLINE 2003] S.13ff

^[11] vgl. [EANCOM 2003]

^[12] vgl. [WEITZEL 2001] S. 8

^[13] vgl. [HARVEY 1999]

^[14] vgl. [WEITZEL 2001] S. 6

^[15] vgl. [HASENKAMP 1997] S. 8

^[16] vgl. [DI 2003] DIPPS