Chemielogistik (Markt, Geschäftsmodelle, Prozesse) || Logistik-Geschäftsprozess-Integration von IT-Systemen

Reemers Publishing Services GmbHO:/Wiley/Suntrop/3d/c14.3d from 21.03.2011 13:59:123B2 9.1.431; Page size: 170.00mm x 240.00mm

14Logistik-Geschäftsprozess-Integration von IT-SystemenKlaus Heep

14.1Vorbemerkung

Nicht alles, was technisch machbar ist, ist auch betriebswirtschaftlich sinnvoll undnotwendig. Dieser durchaus vernünftige Ansatz ist insbesondere für kleine undmittlere Unternehmen (KMU) – und damit dem Gros der deutschen Wirtschaft –besonders relevant, wenn es darum geht, Entscheidungen für oder gegen dieAdaption von neuen Entwicklungen in der Informationstechnologie zu treffen.Große Unternehmen verfügen in der Regel über ausreichend Spezialkompetenz,

besitzen vielfach sogar eigene Abteilungen, die sich ausschließlich den Themender neuen Informations- und Kommunikationstechnologien widmen. In kleinenund auch vielen mittleren Unternehmen bleibt es dagegen häufig der Geschäfts-führung überlassen, diesbezügliche Entscheidungen zu durchdenken, vorzuberei-ten und zu treffen. Beim Tempo der fortschreitenden informationstechnologi-schen Entwicklungen ist es dabei nicht verwunderlich, wenn entsprechendePlanungsaufgaben und Entscheidungen eher zurückhaltend bzw. mit kritischerDistanz oder aber durch teure Berater bearbeitet werden.Analog verhält es sich auch oft mit dem Thema serviceorientierte Architektur

(SOA). Der Begriff ist meist in KMU nicht bekannt bzw. besetzt oder aber dasKonzept und der Nutzen für die Unternehmung lassen sich schwer darstellen bzw.werden nicht verständlich in die Unternehmen transportiert. Oft fehlt es auch ankonkreten Beispielen und einfachen Kriterien, um die Sinnhaftigkeit für denEinsatz serviceorientierter Architektur (SOA) zu dokumentieren.Um das eigentliche Themengebiet besser inhaltlich abschätzen und bewerten zu

können, wird nachfolgend in diesem Abschnitt des Buches versucht, das Themasoftwareorientierte Architektur einerseits thematisch differenzierter darzustellen.Andererseits wird der Versuch gestartet, mögliche Ansatzpunkte und Potenzialeim Hinblick auf die Geschäftsprozess-Integration für Logistikanforderungen imUmfeld eines Chemie- bzw. Industrieparks aufzuzeigen. Damit soll ein Beitrag zurVerfügung gestellt werden, den in der Fachpresse und von den Anbietern pro-pagierten Weg der softwareorientierten Architektur in eine für die Unternehmen

281

Chemielogistik: Markt, Geschäftsmodelle, Prozesse, 1. Auflage. Herausgegeben von Carsten SuntropCopyright © 2011 WILEY-VCH Verlag GmbH & Co. KGaA, Weinheim


nachvollziehbare Diskussion mit dem Ziel der Nützlichkeit und Einsetzbarkeit zubegleiten.

14.2Serviceorientierte Architekturen (SOA)

14.2.1Ausgangssituation

Serviceorientierte Architektur gilt in der Informationstechnologie- (IT-) Brancheseit einiger Zeit als Trend, der die Enterprise-Lösungen der Zukunft entscheidendverändern soll und wird. Der Grundgedanke dabei ist, die IT-Struktur einesUnternehmens an den tatsächlichen Geschäftsprozessen entlang zu gestalten.Neu ist, dass nicht in der üblichen Weise komplette, monolithische Applikationenfür die Abbildung dieser Geschäftsprozesse verwendet werden, sondern vielmehrProgramme aus einzelnen Komponenten/Modulen in Form von Services zusam-mengesetzt werden.In der Literatur wird diese Art der Zusammensetzung häufig mit Lego-Baustei-

nen verglichen, die für sich alleine über die erforderlichen Grundeigenschaftender Adaption bzw. Kommunikation verfügen und beliebig mit anderen Bausteinen,die in identischer Weise konzipiert und strukturiert sind, kombiniert werdenkönnen. Grundlage für Lösungen mit softwareorientierter Architektur ist daherein solides Fundament zur Integration bzw.Verankerung der einzelnen Services ineine konsistente Servicelandschaft.Damit trägt softwareorientierte Architektur den sich ändernden Anforderungen

für die Unternehmen Rechnung. Prozesse und Produkte müssen im globalenWettbewerb standardisiert werden, um Kostenvorteile zu realisieren. Gleichzeitigzwingt die dynamische Entwicklung der Märkte die Unternehmen dazu, flexibelzu agieren, Kooperationen bzw. Allianzen einzugehen und möglichst schnell aufVeränderungen zu reagieren. Die zunehmende Durchdringung der Unternehmenmit Informationstechnologie macht daher viele Geschäftsprozesse auch zu einemIT-Prozess, der damit aus der Sichtweise eines reinen Funktionslieferanten zueinem integralen Bestandteil der Prozesskette wird. Dies führt bei allen Chancenzu einer Vielzahl neuer Anforderungen.

14.2.2Ziele und Herausforderungen

Die Ziele, die mit serviceorientierter Architektur verfolgt werden und zu Kosten-einsparungen führen sollen, sind vielseitig. Die modulare Struktur verspricht dieWiederverwendbarkeit einzelner Services. Damit verbunden ist insbesondere dieMöglichkeit, (einzelne) Services unter dem Aspekt der Wiederverwendbarkeit inder Konzeptionsphase so zu entwickeln, dass diese in unterschiedlichen Ge-schäftsprozessen einsetzbar sind und im Fall erforderlicher Modifikationen nicht

282 14 Logistik-Geschäftsprozess-Integration von IT-Systemen


in allen individuellen Teilsystemen modifiziert werden müssen. Die Vorteile imHinblick auf höhere Produktivität und Kostenersparnis liegen auf der Hand.In einer Umfrage von McKinsey von Oktober 2006 gaben 2/3 der befragtenManager an, ab 2007 mit der Implementierung einer serviceorientierten Architek-tur beginnen zu wollen. Im Nachgang zu dieser Analyse sieht die Realität bei allenChancen allerdings noch anders aus. Um Aufwand und Nutzen in einen vernünf-tigen, nachvollziehbaren Kontext zu bringen, müssen die Anforderungen an die ITin diesem Zusammenhang im Detail genau betrachtet und analysiert werden.

14.2.2.1 Herausforderungen für die ITWie bereits erwähnt, ergeben die sich ständig verändernden Rahmenbedingungenfür die Geschäftswelt eine Vielzahl von Herausforderungen an die IT:Ausgangssituation: Anwendungen und IT-Systeme werden zu einem bestimmten

Zeitpunkt und gemäß aktuellen, betriebswirtschaftlichen Forderungen entwickelt.Um den viel zitierten Vorwürfen gegenüber IT-Projekten zu begegnen, dass sie Zeit,Kosten und Risiken nicht in geeigneter Weise im Griff haben, sind IT-Implementie-rungs-Projekte darauf angewiesen, die geltenden Erwartungen zu einem definiertenZeitpunkt zu fixieren (gleichsam einzufrieren: Frozen Zone) und damit möglichsteinvernehmlich und eindeutig in Abstimmung mit dem relevanten Stakeholdern zudefinieren. Diese formulierten und gegenseitig bestätigten Definitionen werdenschließlich in die IT-technische Umsetzungsphase überführt.Die dabei entstehenden IT-Lösungen und Softwareanwendungen sind dann so

konzipiert und programmiert, dass sie die zu unterstützenden Geschäftsprozesseund die Funktionalität, die der einzelne Nutzer im Rahmen dieses Geschäfts-prozesses benötigt, möglichst optimal abbilden.Die zentralen Anforderungen entstehen aber genau in dem Augenblick, wenn

vorhandene und funktionierende Implementierungen auf Grund veränderter Rah-menbedingungen modifiziert werden müssen. Was ist die Ursache?Eine Vielzahl von Einflüssen führen in der modernen Geschäftswelt zu Ände-

rungen in den betriebswirtschaftlichen Bereichen, die notwendige Anpassungenin den Geschäftsabläufen und damit auch in den Softwarelösungen nach sichziehen. Beispielhaft seien dazu genannt:

• Mergers & Akquisition (M & A)• Neue gesetzliche Anforderungen bzw. Auflagen• Veränderung in der Geschäftstätigkeit (z. B. neue Produkte, Erweiterung derGeschäftsfelder)

• Optimierung der Supply Chain/des Sales Channel• Neue Kundenanforderungen/Wettbewerbsdruck

Die aufgeführten Ursachen erheben sicherlich nicht den Anspruch auf Voll-ständigkeit, allerdings lässt sich auf ihrer Basis bzw. weiteren Einflussfaktorenableiten, dass die Anpassungsfähigkeit der vorhandenen und zu entwickelndenSoftwarelösungen auf die Bedarfe des Marktes hin auszurichten sind bzw. aus-gerichtet werden müssen.

14.2 Serviceorientierte Architekturen (SOA) 283


Flexibilität ist damit eine entscheidende Forderung für die Entwicklung undUmsetzung moderner System- und Anwendungsarchitekturen (zeitnah undidealerweise in vollem Funktionsumfang). Die Anwendungslösung muss flexibelsein und mit wenig Aufwand an die Änderungsanforderungen angepasst werdenkönnen.Neben der geforderten Flexibilität der Anwendungen spielen insbesondere

betriebswirtschaftliche Faktoren eine weitere entscheidende Rolle. Bereits getätigteInvestitionen in implementierte Lösungen müssen unter dem Aspekt Investitions-schutz im Rahmen des Life Cycle Management (LCM, Abbildung 14.1) weiterentwickelbar sein. Die Begründung ist einfach und trivial: Anpassungen undÄnderungen an bestehende Anwendungen erfordern grundsätzlich Aufwand unddamit in den meisten Fällen auch zusätzliche Kosten für den Betrieb der ange-passten Lösung. Eine Neu-Implementierung dagegen erfordert einen deutlichenhöheren Investitionsaufwand in Verbindung mit der damit einhergehenden wei-teren zeitlichen Verzögerung.Um diesen Aspekt der Weiterentwicklung nachvollziehen zu können, erscheint

es sinnvoll, den Lebenszyklus einer Anwendung etwas genauer zu betrachten:Zu Beginn des Produktiveinsatzes einer Lösung werden die Anforderungen in

der Regel sehr gut abgedeckt (Voraussetzung ist natürlich neben einer sauberenFormulierung der Anforderung die spezifikationsgerechte Implementierung). Siegewährleistet ein hohes Maß an Lieferfähigkeit im Sinne von Unterstützung dergeforderten Geschäftsfunktionalität. Diese gute Abdeckung drückt sich idealer-weise auch in der Zufriedenheit der Anwender aus. Über den Zeitverlauf steigtjedoch auf Grund der Einflussfaktoren und Veränderungen die Anzahl der Än-derungsanforderungen. In gleicher Weise sinkt der funktionale Abdeckungsgradder Softwarelösung und damit auch der wahrgenommene Nutzen für die Anwen-

Abb. 14.1 Software-Lebenszyklus-Modell (Schema). A. Zeller, Saarland Universität, Saarbrücken.



der. Der gleichzeitig steigenden Zahl von Änderungsanforderungen kann nicht injedem Fall nachgekommen werden.

Mögliche Ursachen:• Auf Grund der bestehenden Architektur des Systems sind geforderte Anpassun-gen nicht oder nur mit einem unverhältnismäßigen Aufwand möglich (tech-nische Hindernisse).

• Die eigentliche Umsetzung kann aus zeitlichen Aspekten oder wirtschaftlichenErwägungen (Kostengründen) nicht durchgeführt werden.

Die Lieferfähigkeit der betreffenden Systeme nimmt damit über den Zeitverlaufin der Regel ab. Der Lebenszyklus der Softwarelösung tritt dann final in die Phaseder Degeneration ein, die dadurch hervorgerufen wird, dass durchzuführendeAnpassungen zu einer gesteigerten Komplexität der Softwarelösung führen.Verstärkt wird dieser Effekt durch nachträgliche Änderungen, die in der Regel

nur bedingt in das Gesamtkonzept der bestehenden Lösungsarchitektur hinein-passen und gleichzeitig weitere Abhängigkeiten und Fehlermöglichkeiten erzeu-gen (z. B. Performance-Verschlechterungen, Nebenfunktionalitäten im Hinblickauf Stammdatenmanagement, etc.). Schnittstellen und Verbindungen zwischenden Anwendungen steigern zusätzlich die zu berücksichtigenden Abhängigkeitenund erhöhen damit den Komplexitätsgrad exponentiell. Der Aufwand für Zuver-lässigkeit und Beherrschbarkeit des Gesamtsystems verhalten sich in gleicherWeise und begünstigen das Risiko von Fehlern bzw. Systemausfällen.Insgesamt besteht also die Gefahr, dass die Qualität der Lösung über den

gesamten Lebenszyklus deutlich abnimmt. Gleichzeitig verringert sich über den

Abb. 14.2 Lebenszyklus von Softwareprodukten und die Herausforderungen für die service-orientierte Architektur. LCM – Infraserv Höchst.



Zeitverlauf betrachtet damit auch die Adaptierbarkeit der eingesetzten IT-Lösun-gen für die eigentlichen Geschäftsprozesse. Die Phase der Degeneration droht undist, einmal aufgetreten, nicht mehr aufzuhalten.Um dieses Dilemma aufzulösen, ist eine grundsätzliche Renovierung der betref-

fenden Anwendungslösung und der damit verbunden Systeme (Applikationsnetz-werk) erforderlich. Notwendig sind dazu innovative architektonische Prinzipienmit deren Hilfe es gelingt, Offenheit, Flexibilität, Effizienz und Transparenzwiederzugewinnen (Abbildung 14.2).

14.2.3Definition softwareorientierte Architektur

Serviceorientierte Architekturen schlagen die Brücke zwischen Geschäftswelt undIT, schaffen Flexibilität und ermöglichen die verbesserte Abbildung von Geschäfts-realität.Vor dem Hintergrund der formulierten Anforderungen und Rahmenbedingun-

gen bietet die serviceorientierte Architektur nunmehr die Chance und das Kon-zept, betriebswirtschaftliche Aspekte mit systemarchitektonischen zu verbindenund damit die Brücke zwischen der Geschäftswelt und IT zu schlagen.Der betriebswirtschaftliche Teil der softwareorientierten Architektur strebt eine

an den gewünschten Geschäftsprozessen ausgerichtete IT-Infrastruktur an, dieschnell auf veränderte Anforderungen im Geschäftsumfeld reagieren kann. DasSystemarchitektur-Konzept sieht die Bereitstellung fachlicher Dienste und Funk-tionalitäten in Form von Services vor und stellt diese den Anforderungen jeweilszugeordnet zur Verfügung. Services sind in diesem Zusammenhang als gekapsel-te, wiederverwendbare (Geschäfts-) Funktionalitäten, die über standardisierteSchnittstellen in Anspruch genommen werden können, definiert.Softwareorientierte Architektur bietet Flexibilität und Anpassbarkeit, indem lose

gekoppelte Komponenten und Services für die Abbildung von Geschäftsprozessenmit überschaubarem Aufwand miteinander verbunden und schnell neu kom-biniert werden können (SAP bezeichnet diese Applikationen als so genannteComposite Applications als Teil der aktuellen ESOA – Netweaver Systemarchitek-tur-Strategie).Softwareorientierte Architektur bietet somit einen modernen prozessorientiertenIT-architektonischen Lösungsansatz, der nachweisbare und nachhaltige Verbes-serungen hinsichtlich vieler der zuvor beschriebenen Schwierigkeiten verspricht.Um den wachsenden Anforderungen und immer rascheren Veränderungen derGeschäftswelt nachhaltig und flexibel begegnen zu können, werden bereits seiteinigen Jahren serviceorientierte Ansätze verfolgt, die bereits Einzug in die Praxisgefunden haben.Die Entwicklung und Verbreitung von Standards wie z. B. Webservices, WSDL

(Web Services Description Language), XML (Extensible Markup Language) oderSOAP (Simple Object Access Protocol) und mit ihnen verbundene Technologienhaben die Aufmerksamkeit in Richtung serviceorientierte Architektur zusätzlicherhöht.



Softwareorientierte Architektur ist ein vielversprechendes Konzept zur Verbes-serung der Abbildung von Geschäftsrealitäten auf IT-Landschaften in einer ad-äquaten Form. In ihrem Kern verfolgt softwareorientierte Architektur zusammen-gefasst einen Ansatz zur Kapselung von Geschäftsfunktionalitäten in autonomenServices. Diese Services werden zur Abbildung von Geschäftsprozessen unterVerwendung moderner Webstandards für die Beschreibung von Schnittstellen(WSDL) und die Übertragung von Nachrichten (z. B. SOAP) oder anderer dienst-basierter Technologien (DCOM, CORBA) miteinander verknüpft (lose Kopplung).Durch die Anstrengungen führender Hersteller von Geschäftsanwendungen ist

es heute möglich, diese Vorteile für das eigene Unternehmen nutzbar zu machen.Das Konzept der serviceorientierten Architektur ist weitestgehend etabliert undverfolgt viele akzeptierte Prinzipien, nachfolgend in den Grundzügen beispielhaftaufgeführt:

• Dekomposition und KapselungZerlegung eines Geschäftsprozesses in kleinere Einheiten und Kapselung vonProzessfunktionalitäten

• AbstraktionDefinition eines Service in Form einer Servicebeschreibung als Abstraktions-schicht für den Servicenutzer und unabhängig von der konkreten technischenIT-Implementierung

• WiederverwendbarkeitVerwendung des gleichen Service in unterschiedlichen Geschäftszusammen-hängen und Prozessen

• Lose KopplungAutonomie der miteinander verbundenen Services und Vermeidung von Ab-hängigkeiten

• KompositionVerkettung der Orchestrierung von wiederverwendbaren Services zu (Teil‑)Pro-zessen und Möglichkeit der Austauschbarkeit.

14.2.3.1 Abstraktionsprinzip als Grundlage für die Einsetzbarkeit in der RealitätDas grundlegende Prinzip besteht darin, eine Abstraktionsschicht zwischen dergekapselten betriebswirtschaftlichen Funktionalität des Service und seiner tatsäch-lichen IT-technischen Realisierung zu ziehen (Abbildung 14.3). Aus betriebswirt-schaftlicher Sicht bedient sich der gesamte Geschäftsprozess eines oder mehrererServices. Der Geschäftsprozess tritt als Servicenutzer auf (Service Consumption).Parallel dazu stellt die IT-technische Implementierung den Service zur Verfügungund tritt als Lieferant des Dienstes (Service Provider) auf.Zum besseren Verständnis ist anzufügen, dass die Services die gekapselte

Geschäftsfunktionalität und Geschäftsprozessfunktionalität enthalten und übereindeutige Definitionen und Zugriffsmethoden identifizier- und adressierbar sind,d.h. für Benutzer, Prozesse, Anwendungen, Verknüpfungen, etc. zur Verfügungstehen.



14.3Diskussion der Umsetzbarkeit im Bereich Logistik für die Prozessindustrie(Chemie, Pharma, Logistik)

14.3.1Allgemeine Kriterien

Die aus den vorgenannten Aspekten resultierenden Aufgaben für die Formulierung,Aufnahme und Umsetzung im Hinblick auf die IT-Anforderungen sind vielfältig.Wesentlicher Bestandteil ist die hinreichende Identifikation und vollständige Inte-gration von Funktionalitäten und den dazugehörigen, relevanten Objekten (dieseliegen i.d.R. in Form von Stamm- und Bewegungsdaten vor). Gerade die Notwendig-keit der Massenverarbeitung von Stamm- und Bewegungsdaten als Grundlage derwarenwirtschaftlichen Prozesse sind einerseits im Hinblick auf die Beherrschbarkeitund sinnvolle Nutzung die grundsätzliche Voraussetzung, um andererseits eineerfolgreiche Implementierung und Weiterentwicklung des Geschäfts überhaupt erstzu ermöglichen. Die vollständige Informationstransparenz bildet daher die Basis, umPotenziale für Kostensenkungen und Prozessverbesserungen zu erkennen.Betrachtet man Effizienz und Qualität von Geschäftsprozessen unter dyna-

mischen Gesichtspunkten, nimmt das Thema Flexibilität als zentraler Erfolgs-

Abb. 14.3 Softwareorientierte Architektur. Geschäftsprozesse nutzen den Service-Marktplatz.



faktor einen wichtigen Stellenwert ein. Es gilt daher Mittel und Wege zu finden,diese Ansprüche schnell und effektiv (strategisch zielführende Themen) bzw.effizient (priorisierte und erfolgreiche Umsetzung) umzusetzen.Die Bedeutung der Logistik als Instrument der Rationalisierung und Differen-

zierung im direkten Wettbewerbsumfeld ist auf Grund der Produkte und Service-leistungen unumstritten. Einer Vielzahl von Güterflüssen steht ein immenswichtiger, korrespondierender Informationsfluss gegenüber. Diese enge Verzah-nung erfordert die genaue Betrachtung von Lieferketten mit den damit verbunde-nen IT-Systemen. Auf Grund der Internationalität der Geschäftsmodelle sindschnelle Antworten auf Lieferkettenprobleme zu finden. Daraus ergibt sich einweitgefasstes Aufgaben- und Betätigungsgebiet, das zunächst unter strategischenGesichtspunkten analysiert und mit operativen Handlungsempfehlungen versehenund abgeleitet werden muss. Diese Empfehlungen müssen sowohl die unmittel-baren operativ dringenden als auch die abgeleiteten strategischen Themen in einervernünftigen zeitlichen Abfolge als „nächste Schritte“ formulieren.Gerade das Thema Logistik kann ein interessantes und zielführendes Einsatz-

gebiet sein, um Margenvorteile auf der Grundlage intelligenter IT-Systeme überUnternehmens- und Systemgrenzen hinweg zu erwirken. Ein erster Blick in diesesMarktsegment unter dem Aspekt softwareorientierte Architektur kann interes-sante Hinweise für mögliche Einsatz- und Optimierungsszenarien bieten.

14.3.2Bewertung der Einsatzmöglichkeiten im Bereich der Logistik

Die heutige IT-Unterstützung der Prozesse im Bereich der Transport- und Logis-tikunternehmen ist geprägt von einer gewachsenen, heterogenen Applikations-und Systemlandschaft, die meist als eigenständige Lösungen implementiert undunter dem Aspekt Life Cycle Management bereits deutlich „in die Jahre gekom-men“ sind (proprietäre Systeme).Ergänzt wird diese Situation noch durch die Tatsache, dass die Kommunikation

bzw. der Datenaustausch mit unterschiedlichsten Zielsystemen gerade unterIntegrationsaspekten (Bahn, Straße, Luft, Wasser, etc.) in gleicher Weise heterogenist, d.h. es gibt viele Schnittstellen, die mit unterschiedlichsten, meist selbstentwickelten Anwendungen verbunden sind. Daraus ergeben sich für die software-orientierte Architektur interessante Ansatzpunkte.Auf der Grundlage dieser Vermutung lassen sich die Einsatzgebiete bzw.

Schwerpunkte insbesondere unter dem Aspekt der Optimierung grundsätzlich indie Bereiche Kunden bzw. Interne Prozesse als mögliches Strukturierungsmerk-mal differenzieren:

• Integration in Kundenprozesse und in die Supply Chain– Integriertes Order Management– Warehouse-Management (schnelle Ein- und Ausgangsverarbeitung und opti-mierte Lagerverwaltung)

14.3 Diskussion der Umsetzbarkeit im Bereich Logistik für die Prozessindustrie 289


– Transportmanagement-System (TMS, multimodale Eingangs- und Ausgangs-transporte incl. Tourenplanung bzw. Transportkostenmanagement)

– Proaktives Störungsmanagement (Threshold Monitoring)– Visualisierung Supply Chain (End-2-End)– Kundenspezifischer, einheitlicher Zugang für Logistikservices (SPOC: Singlepoint of Contact)

• Erhöhung der Performance auf Basis der Logistik relevanter Produktionsfaktoren– Verbesserung der Transportwege– Reduktion der manuellen Arbeitslast und Erhöhung des Automatisierungs-grades

– Erhöhung des Lagerumschlages durch Konsolidierung• Unternehmenssteuerung/Controlling– Konsistenz der Business-Modelle, Prozesse, KPI und Service Level– Optimierung der betriebswirtschaftlichen Kennzahlen/Prozessgüte (Reduzie-rung von Betriebsmitteln, Bindung des Betriebskapitals durch Anlagever-mögen, Verbesserung der Umschlagszeiten)

– Durchgängigkeit des Prozesses Anfrage–Kalkulation–Angebot–Rahmenver-trag–Auftrag–Abrechnung (Order-2-Cash)

Die Erfahrungen aus dem betrachteten Zielsegment zeigen, dass die gegen-wärtige Vorgehensweise zur Abdeckung dieser Anforderungen in der Regel pro-prietäre Lösungen und Systeme verwendet, deren Datenbasis unter Designge-sichtspunkten für Datenbanken (DBMS: Date Base Management System) wederkonsistent sind noch den grundsätzlichen Normalformen entsprechen (bspw. 3.Normalform (3NF) zur Vermeidung von Redundanzen – Anm.: 3NF ist in derPraxis schon ausreichend, um eine Datenbank ohne Redundanz zu erstellen).Auch der Blick auf den Bereich der Applikationen kann dabei außerordentlich

hilfreich sein, denn auch hier findet sich eine Vielzahl von Anomalien bzw.Inkonsistenzen, hervorgerufen durch funktionelle Überlappungen bis hin zu teil-weise semantischen Dead-Lock-Situationen (Programme behindern sich gegen-seitig bei der Modifikation von Variablen, die meist nur durch manuelle Inter-aktionen aufgelöst werden können).Die Folgen sind eindeutig und bei vielen Unternehmen im Zielsegment erkennbar:

• Extremer Aufwande, um spezifische Kundenanforderungen systemseitig zeitnahabbilden zu könnenGrund: Vielzahl von unmittelbar Beteiligten und betroffenen Prozessen

• Hohe Folgekosten bei Modifikationen am DatenmodellGrund: Analyse der Veränderungen und Bewertung der Implikationen fürrelevantes System i.d.R. sehr zeitaufwändig und auch nur sehr schwierig in einGesamtbewertung einbeziehbar

• Prozessgüte ist nicht durchgängig sichergestelltGrund: Fehlende Integration der Einzelprozesse führt zu erhöhtem Interaktions-aufwand über Prozessgrenzen hinweg sowohl auf Datenbasis, als auch beimanueller Interaktion.



14.3.2.1 Wie kann eine Lösung dieser Anforderung generell bzw. fürLogistikdienstleister aussehen?

Wesentliche Vorarbeit für die Definition der künftigen Unternehmensarchitektur istdie grundlegende Analyse der Prozesse auf Basis der aktuellen und geplantenZielzustände und deren Visualisierung via Prozesslandkarte (Abbildung 14.4). Aufdieser Grundlage müssen die zur Erbringung der Funktionalitäten erforderlichenDienste als flexible Services (Designprinzipien s.o.) entlang der Wertschöpfungs-kette zur Verfügung gestellt werden. Prozessanalyse bedeutet, dass ein Vorgang inseine Bestandteile zerlegt wird, um diese im Anschluss genau zu untersuchen(Komponenten = Menschen, Werkzeuge, Zusammenhang + Wechselwirkungendieser Komponenten, etc.). Für die spätere Lösungsfindung ist es elementar, diekonkreten Arbeitsprozesse im Sinne dieser Definition sehr genau zu analysieren. Indiesem Zusammenhang ist es übrigens auch aufschlussreich, diejenigen Prozesseherauszufinden, die einfach nur deshalb so sind, weil sie „schon immer so waren“.Das Finden der Prozessflexibilität (nicht zu verwechseln mit der Aufgabe derOrganisationsoptimierung!) wird in diesem Zusammenhang als ein besonderswichtiger Punkt der Prozessanalyse gesondert herausgestellt.Mögliche Ansatzpunkte für die Bewertung zur genaueren, weiterführenden

Analyse können folgendermaßen aussehen:

• Relation der vorhandenen Daten zueinander bzw. Verfügbarkeit von Informatio-nen/Daten

• Genauigkeitsgrad der Informationen im Prozess (In/Out) bzw. Fehlerquote imProzess

• Einfluss durch die Steuerungsparameter Mensch/Maschine/Technik

Abb. 14.4 Beispiel einer Prozesslandkarte.



• Motivation für die Existenz der jeweiligen Prozesse• Wertschöpfender Beitrag eines Prozessschrittes.

Darauf aufbauend können in der nun folgenden, nächsten Differenzierungs-stufe die dazu erforderlichen prozessrelevanten Daten identifiziert bzw. analysiertwerden. In der Abbildung 14.5 finden sich beispielhaft dargestellt produktions-relevante Daten für den Bereich der Versandlogistik.Neben der intensiven Analyse der Prozesse für das Design der Services ist die

Ausprägung der dazu charakteristischen Daten von außerordentlicher Bedeutung.Die Frage, die in diesem Zusammenhang zu beantworten ist, orientiert sich anden modularen Kriterien für Wieder- und Weiterverwendung bzw. Erweiterung(intern/extern) vorhandener bzw. zu identifizierender Daten.

• Daten werden auf einer einheitlichen, konsistenten Plattform als gemeinsamesRepository für alle Services (Anwendungen) als Teil der SOA zur Verfügunggestellt (Funktionsumfang für die fachlich differenzierten Anforderungen)

• Syntax und Semantik der verwendeten Datenobjekte sind einheitlich definiertund für die zugehörigen Services zugreifbar, d.h.– Einheitliche Standards bzw. Definitionen der Daten für die Zusammenarbeitvon IT-Systemen verschiedener Softwarefirmen bzw. Softwareanwendungen(Einzelne für spezielle Anforderungen ausgereifte Module interagieren voll-ständig)

– Einheitliche dafür notwendige Standard-Datenaustausch-Formate incl. derdazugehörigen Infrastruktur stehen zur Verfügung (Stichwort EDI: ElectronicData Interchange).

Abb. 14.5 Differenzierung von Produktionsprozessen.



14.3.3Mögliche Einsatzszenarien im Umfeld eines Industrieparks

14.3.3.1 Praxisbeispiel: Anbindung von zusätzlichen Waagen an ein vorhandenesautomatisches Wiegesystem

Die grundlegende Analyse der Prozesslandkarte führt zu einer klaren und struk-turierten Service Map, die alle relevanten Services aus der Sicht eines Logistik-dienstleister an einen Industriepark enthält. Bei genauerem Hinsehen lassen sichmögliche SOA-Anwendungen auf der Grundlage der Service Map (Abbildung 14.6)identifizieren, formulieren und implementieren.Im Bereich des Supportprozesses Transport, der unterschiedlichste Services und

Prozessschritte integriert, wird als wichtiger Prozessschritt ein Service „Verwie-gung“ aufgegriffen.Bei näherer Betrachtung des Verwiegeprozesses, der an unterschiedlichen

Transportknotenpunkten mit unterschiedlichen Anforderungen eines Industrie-parks immer wieder bedient werden muss, ergeben sich einfache Ansätze für dieRealisierung und Optimierung auf der Basis des SOA-Ansatzes:

1) Grundfunktionalitäten wie Messungen, Kontrolle, Dokumentation, Versionie-rung, Zulassungen, etc. werden als separate Dienste gekapselt und via gemein-same Stammdatenverwaltung als Repository zur Verfügung gestellt.

2) Alle Waagen werden einheitlich bzw. eindeutig an den zentralen Wiegeserverangebunden.

3) Alle Wagen werden via Videokontrolle beobachtet und ggf. remote gesteuert,d.h. zentraler Zugriff auf alle dezentralen Waagen zur Steuerung bzw. Fehler-kontrolle durch Integration auf Basis der vorhandenen Kommunikations-Infra-struktur.

4) Der dazugehörige Verwiegevorgang wird konsistent für alle Waagen erfasst unddurch den zentral zur Verfügung gestellten Service „Bild-Dokumentation“revisionsfest via Videoserver abgelegt.

5) Design und Ausprägung der Wiegescheine (revisionsfeste Dokumentation)inkl. Printout kann auf jedem beliebigen Drucker (vor Ort oder remote) durcheine zentrale, hoch verfügbare Druckerqueue sichergestellt werden (Service„Print“).

Anmerkung: Der bei den Grundlagen bereits angedeutete, weitere Vorteil imHinblick auf die Erweiterbarkeit lässt sich im realen Fall sehr gut nachvollziehen.Die Hinzunahme bzw. die Konsolidierung von Wiegestationen auch außerhalb desunmittelbaren Campus-Netzes ist auf Basis der vorhandenen SOA-Infrastruktur(abgesehen von den durchzuführenden baulichen Maßnahmen) erwartungsgemäßeinfach.Auch die Modifikation bzw. Anpassung der Services bspw. im Hinblick auf

spezielle Begleitdokumente kann deutlich einfacher realisiert werden. Als weiterenpositiven Begleiteffekt reduziert sich die Vorhaltung spezifischen Entwickler-Know-Hows dadurch massiv.



Abb. 14.6 Klassische Supportprozesse im Logistikumfeld.



Zwischenfazit: Durch die einheitliche (Infra-) Struktur werden sämtliche Modifi-kationen (Update, Alter, Delete) konsistent und eindeutig definiert. Die Hin-zunahme neuer Waagen vor Ort oder auch remote kann mit minimalem Aufwandrealisiert werden. Das Praxisbeispiel zeigt die Verifizierbarkeit und Einsetzbarkeitdieser SOA-Strategie empirisch.

14.4Zusammenfassung

14.4.1Technische Zusammenfassung

Aus den vielen, auch widersprüchlichen Aussagen und Meinungen kann m. E. festgehaltenwerden:

• Serviceorientierte Architekturen (SOA) bieten gerade bei starkem Leistungs- undUnternehmenswachstum, bei Internationalisierung und Kooperation bis hin zuUnternehmensnetzwerken generell Vorteile wie Effizienzsteigerung, Kostensen-kung sowie Flexibilität und Unabhängigkeit der IT von einzelnen Anbietern.Auch Sicherheitsvorteile und langfristige Kostenvorteile bei Erneuerungen undErweiterungen sind sichtbar.

• Die geringe Bekanntheit und Verbreitung von SOA gerade in kleinen Unterneh-men verhindert eine weitere Verbreitung.

• Hinter dem Begriff softwareorientierte Architektur versteckt sich eine ganzePhilosophie und ein komplexes Konzept, das sich Unternehmen mit geringemIT-Wissen nicht sofort erschließt und die Inhalte und den Nutzen nicht soforterkennen lässt. Aber gerade die nicht in der IT vorgebildeten Manager sind – alsMachtpromotoren – die Entscheider über die Einführung von SOA. Hinzukommt das Problem, dass einige Anbieter ihre Produkte direkt mit den Namensoftwareorientierte Architektur (SOA) versehen und so zu Verwechslungen undIrritationen beitragen, weil das SOA-Prinzip mit dem Produkt der Anbieterfir-men gleichgesetzt wird.

• Unternehmensverbände sind in diesem Kontext auch keine Hilfe, da diese bisauf sehr wenige keine Informationen oder Hilfen zu (SOA) anbieten. In denmeisten Verbänden ist der Begriff sogar unbekannt.

• Auch in einigen IT-Systemhäusern ist der Begriff softwareorientierte Architektur(SOA) unbekannt, andere Anbieter preisen das technisch maximal Mögliche.

14.4.2Ergänzende Anmerkungen

Laut „SOA Check 2009” arbeiten derzeit 47 % von 111 befragten Unternehmen an einerserviceorientierten Architektur (SOA). In einer vergleichbaren Vorjahresstudie waren esnoch 11% weniger. Die Ergebnisse der SOA Check 2009 weisen auf einen wichtigen

14.4 Zusammenfassung 295


Aspekt hin, der im Rahmen der SOA-Diskussion immer wieder in den Hintergrundgedrängt wird: die Integration des Change Management. Nur 35 % Prozent der IT-Chefssetzen ein Change Management auf, um die Fachabteilungen in die Projekte dersoftwareorientierten Architektur einzubeziehen. 31 % beschränken sich auf einfacheKommunikationsmaßnahmen. 24 % betrachten softwareorientierte Architektur als rei-nes IT-Thema (Abbildung 14.7).

14.5Fazit

Geschäftsprozessmanagement auf Basis einer softwareorientierte Architektur(SOA) ermöglicht automatisierte, zuverlässige, revisionssichere und anpassungs-fähige Prozesse über Geschäftsfunktionen, Abteilungen und sogar Unternehmenhinweg. Dank SOA ist es möglich, Prozesse unabhängig von den zugrundeliegenden IT-Systemen zu konzipieren und zu modifizieren. Prozesslogik undProzessablauf sind somit von der Geschäfts- und Anwendungslogik getrennt.Damit wird den Anforderungen des Managements insbesondere im KontextLogistik Rechnung getragen, indem reaktives Implementieren durch aktive Steue-rung der erforderlichen Services ersetzt wird. Das Business wird in die Lageversetzt, die erforderlichen Services aktiv und selbständig zu managen.Softwareorientierte Architektur ist demnach kein Selbstzweck, sondern bildet die

Voraussetzung, damit Business und IT auf der Grundlage eines gemeinsamenVerständnisses die Integration von Fachabteilungen und IT intensiv unterstützenund damit die erforderliche Weiterentwicklung ermöglichen. So ist neben denwichtigen, technischen Anforderungen zur Realisierung dieser Kollaborations-architektur die enge Verzahnung zwischen Business und IT einer der wichtigen

Abb. 14.7 Softwareorientierte Architektur (SOA): Implementierung und Einbindung der Fach-bereiche. SOA Check 2009.



Erfolgsfaktoren. Dazu werden insbesondere Logistiker mit IT-Kenntnissen benö-tigt, die in hohem Maße Prozesskenntnis und IT-Know-How für die Abstraktionder gedanklichen Modelle konzipieren und realisieren können.Diese Kompetenz ist schon deshalb erforderlich, weil eine serviceorientierte

Architektur als Produkt bzw. Service nicht fertig auf dem Markt verfügbar ist.SOA ist vielmehr das Konzept, welches auf die jeweiligen individuellen Gegeben-heiten – sowohl hinsichtlich der Organisation als auch bezüglich der bestehendenAnwendungslandschaft – eines Unternehmens angepasst werden muss. Eineserviceorientierte Architektur ist demnach nie abgeschlossen, sondern unterliegtmit dem Unternehmen vor dem Hintergrund eines dynamischen Marktumfeldeseiner permanenten Weiterentwicklung.Die Erfahrungen in Unternehmen haben gezeigt, dass die Einführung und

Implementierung einer softwareorientierten Architektur ein langer, steiniger Wegist. Allerdings motivieren die bereits erzielten Erfolge zur Fortführung diesesWeges.

Tabelle 14.1 Softwareorientierte Architektur: Anbieter und deren Informationen und Hilfen fürSOA-Anwender.

Anbieter WWW Informationsquelle und deren Qualität Informationen

Accenture Ja Umfangreiche und kompetenteInformationen (jedochhauptsächlich auf Englisch)

Informationen zu SOAallgemein, Fallbeispiele,Studien, Podcasts

Atos Origin Keine expliziten Informationenzu SOA

BEA keine spezifischen InformationenSOA

Informationen zu SOAund Fallbeispiele, SOAReadiness Assessment

Capgemini Ja Umfangreiche (englische) Informa-tionen, kein KMU-individuellesInformationsangebot

Studien, Fallbeispiele

CSC Ja Kompetente Informationen, jedochFokus auf große Mittelständler undGroßunternehmen

Allgemeine Informatio-nen und Fallbeispiele

T-Systems SOA wird vor allem für Großunter-nehmen thematisiert, keine mittel-standsspezifischen Angebote

Vorgehensmodell SOA-Implementierung

EDS Ja Keine Informationen auf der Website,aber eigene Tochter mit KMU-Fokus

Keine Informationen

Hewlett-Packard

Ja Allgemeine Informationen SOA Maturity Assess-ment,

Online SOA Diskussions-forum

IBM Ja Grundlagen von SOA SOA BenefIT-Calculator,Leitfaden zur ROI-Berech-nung, IT-Lösungen

14.5 Fazit 297


Anbieter WWW Informationsquelle und deren Qualität Informationen

Microsoft Ja Informationen zuMS-Produkten

Oracle Ja Umfassende Informationen, jedochwenig KMU-spezifisch

White Paper, Online SOAAssessment, Fallstudien

SAP Ja ESOA, Informationen bietenÜberblick

Informationen zumNutzen von SOA undFallbeispiele

Software AG Ja Fachkompetenz Roadmap, mögliche IT-Lösungen entsprechendden Kundenbedürf-nissen

SUN Ja Hohe Fachkompetenz, allerdingswaren die Informationen sehrtechnisch

Mögliche IT-Lösungen


Documents

Chemielogistik (Markt, Geschäftsmodelle, Prozesse) || Logistik-Geschäftsprozess-Integration von IT-Systemen