17.1 Historische Entwicklung

Es ist ein altes Thema. Schon bald nach dem Aufkommen der Computer stellte sich die Frage, ob und wie diese die Geschäftstätigkeit von Unternehmen und anderen Organisationen ("Volkszählung") unterstützen können. Dabei ging es erstmal um einzelne Aufgaben (Finanzwesen, Lagerverwaltung, …) und das ganz normale operative Geschäft.

Als dann die Zahl der Computer in den Organisationen größer wurde, begann das Thema Integration Bedeutung zu gewinnen. Und nur wenige Jahre später wurde dies durch den Prozessgedanken geprägt. Seitdem hängen IT-Integration und Geschäftsprozesse untrennbar zusammen. Die Geschichte der betrieblichen Informatik im Allgemeinen und die der betrieblichen Anwendungssysteme im Besonderen kann auch als ein ständiger Versuch interpretiert werden, die Geschäftsprozesse der Organisationen immer stärker durch IT zu unterstützen. Dies war anfänglich nur in Form von Insellösungen möglich, weshalb es darum ging, diese "Inseln" zu integrieren. Dadurch sollten die Prozesse effizienter und effektiver werden.

Integration und Prozessgedanke

Im Rahmen der IT-Entwicklung dehnte sich die Softwareunterstützung immer mehr aus, von der Unterstützung einzelner weniger Funktionen (in den 1950-er Jahren) bis zur heutigen flächendeckenden Geschäftsprozessunterstützung. Parallel wurde und wird die Prozessunterstützung immer detaillierter. Wurden anfangs in den Geschäftsprozessen nur einzelne Funktionen und die Informationsflüsse zwischen ihnen unterstützt, geht es heute teilweise in die Vollunterstützung, bei der nur die Entscheidungen den Menschen überlassen bleiben.

Softwareunterstützung

So kommt es, dass heute die integrierte prozessorientierte Software (z.B. von SAP) die Nutzer für die Interaktion von Maske zu Maske leitet und der Prozess ansonsten automatisiert abläuft. Das machte es auch möglich, dass das Geschäftsmodell der Internet-Unternehmen auf weitgehend vollautomatisierten Prozessen beruht, und dies nicht nur im E-Commerce, sondern auch dahinter. Lediglich bei Konfliktfällen kommen hier noch Menschen zum Einsatz.

Automatisierung

Dies war möglich, weil seit dem Aufkommen des Prozessgedankens eine immer detailliertere Erfassung und Modellierung der Geschäftsprozesse erfolgte. Sie diente als Grundlage und wurde zum Trend, der bis zur heutigen teilweise vollautomatischen Abwicklung von Geschäftsprozessen reicht.

Trend zu immer detaillierterer Erfassung

Warum eigentlich Integration?

Geschäftsprozesse in Unternehmen bestehen, knapp zusammengefasst, aus zusammenhängenden Handlungen zur Erreichung der Organisationsziele. Dazu gehören u.a. Datenflüsse aller Art und ein Kontrollfluss. Integration von IT-Systemen bedeutet nun, dass Informationssysteme, die unverbunden nebeneinander einzelne Aufgaben in den Geschäftsprozessen erledigen so verknüpft werden, dass sie Daten aller Art austauschen können. Mit dieser Integration kann eine gegenüber dem vorigen Integrationsstand weitere Optimierung der Geschäftsprozesse und der gesamten IT erreicht werden, denn „Nicht-Integration“ bedeutet Defizite in der Prozess- und Datenintegration, die mit viel Aufwand überwunden werden müssen.

Die durch Nicht-Integration entstehenden Reibungsverluste äußern sich v.a. als großer Aufwand für die Informationsweitergabe. Wenn z.B. von der Abteilung Produktion Daten zur Abteilung Vertrieb weitergegeben werden sollen, müssen die Formate jeweils umgewandelt werden. Falls die beiden Abteilungen unterschiedliche Hardware nutzen, muss auch dies überwunden werden.

„Kosten“ der „Nicht-Integration“

Eine weitere Konsequenz der Nicht-Integration von Datenbeständen sind oft Redundanzen. Werden z.B. die Daten der Kunden ganz oder teilweise in verschiedenen Datenbanken gehalten, kann es leicht geschehen, dass in der einen Datenbank dieselbe Information anders festgehalten ist als in der anderen. Für die Absicherung der Geschäftsprozesse durch Datenbanken ist dies eine verhängnisvolle Situation.

Ein weiterer Grund für Integrationsanstrengungen ist der Wunsch nach einer immer detaillierteren Abbildung der Geschäftsprozesse durch die Software. Höhere Detaillierung bedeutet, dass der jeweilige Geschäftsprozess immer detaillierter durch die Software abgedeckt wird. Dies ist ein ständiges Verlangen, seit es die ersten einzelne Funktionen unterstützende Anwendungssoftware gab und vor allem seit entsprechende integrierte prozessorientierte Software (ERP-Software) entwickelt wurde, weshalb diesbezüglich tatsächlich von einem Trend gesprochen werden kann.

Höhere Detaillierung

Seit einigen Jahren ist nun diesbezüglich ein weiterer Trend sehr deutlich zu erkennen, der nach vollständig automatisierten Geschäftsprozessen. D.h. nach Geschäftsprozessen, die ganz durch Software umgesetzt werden. Beispiele bieten die Internet-Unternehmen, deren Geschäftsmodelle ohne diese Automatisierung (v.a., was die Prozesse mit den Kunden angeht) nicht denkbar wäre. Die Entwicklung hat aber inzwischen auch die übrigen Organisationen erreicht (vgl. die folgenden zwei Kapitel).

Automatisierte Geschäftsprozesse – vollständig in Software gepackt

Konkrete Entwicklungsschritte

Zumindest ein klein wenig soll der Blick auf die oben angedeutete historische Entwicklung vertieft werden. V.a., weil man hier tatsächlich aus der Vergangenheit lernen kann, weil sich defizitäre Muster von damals heute wieder zeigen.

Geschäftsprozesse wurden schon immer realisiert, seit es Organisationen mit zielgerichtetem Handeln gibt. Bis in die 1950-er Jahre allerdings ohne Computerunterstützung.

Insellösungen

In den Jahren des ersten kommerziellen Einsatzes von Computern (in den 1960er Jahren), die damals alle Großrechner waren, wurden die Computer für wichtige einzelne Aufgaben (Finanzwesen, Lagerwesen, …) genutzt und dies auf eine Weise die wir heute funktionsorientiert nennen würden.

1960er-Jahre – Geschäftsprozesse erhalten IT-Unterstützung für einzelne Funktionen

Natürlich war die Geschäftstätigkeit damals auch durch Geschäftsprozesse geprägt. Dies wurde aber nicht erkannt, der Schwerpunkt der Betrachtung lag auf Stellen und ihren Aufgaben [Anmerkung] . Die einzelnen Anwendungssysteme lösten Aufgaben, die wir aus heutiger Sicht als sehr einfache bezeichnen würden: Verarbeitung von Massendaten im Bereich der wertorientierten Abrechnungssysteme, z.B. im Finanz- und Personalwesen. Die Anwendungssysteme standen isoliert nebeneinander, mit u.U. sehr unterschiedlicher Hardware und Software (proprietäre Systeme) und lösten ihre „punktuellen“ Aufgaben. Aus der heutigen, durch Geschäftsprozesse geprägten Sicht lösten die damaligen Anwendungssysteme also nur einzelne isolierte (d.h. unverbunden nebeneinanderstehende) Funktionen. Deshalb wurde damals von Insellösungen gesprochen.

Insellösungen

Ihr Einsatz brachte Produktivitätsgewinne, weil durch sie die Verarbeitung von Massendaten wesentlich effizienter erledigt werden konnte. Bei dieser Vorgehensweise, Großrechner mit entsprechender Software isoliert nebeneinander für einzelne Aufgaben einzusetzen, blieb es auch eine ganze Weile, solange nämlich, wie diese Vorgehensweise Produktivitätsgewinne erlaubte.

Die folgende Abbildung veranschaulicht den Zustand am Ende dieser Phase. Zahlreiche Aufgaben oder kurze Geschäftsprozesse waren auf Anwendungssystemen (AS) realisiert, in der Regel isoliert voneinander. Einzelne von ihnen wurden aber auch schon (mit hohem Aufwand) „verknüpft“, was bedeutet, dass das eine Anwendungssystem Informationen an ein anderes weitergeben konnte.

AS: Anwendungssysteme

Erste Integrationsbemühungen

Die automatische Weitergabe von Daten von einem IT-gestützten Teilprozess zu einem anderen war zunächst kein Thema. Dies änderte sich aber, als die Zahl der Anwendungssysteme zunahm und die von ihnen abgedeckten Aufgaben immer umfangreicher wurden. Es fielen nun öfter in einem Prozessabschnitt Daten an, die in einem anderen benötigt wurden. Die Schnittstellen zwischen den Insellösungen wurden schmerzhaft (teuer, weil sie durch menschliches Tun überwunden werden mussten) und als Medienbrüche erkannt. Es setzte sich die Erkenntnis durch, dass weitere Produktivitätssteigerungen nur möglich waren, wenn die Schnittstellen zwischen den Anwendungssystemen automatisiert wurden.

Medienbrüche

Die folgende Abbildung verdeutlicht diese Situation. Die einzelnen IT-gestützten Prozessabschnitte wurden, soweit es sinnvoll war, verknüpft, so dass Daten ausgetauscht werden konnten. Daten, die in der einen Anwendung entstanden und die in der anderen als Input benötigt wurden.

Damit wurde Ende der 1960er Jahre die Integration der Informationsverarbeitung zu einem zentralen Thema. Nicht nur in der betrieblichen Informatik sondern auch und gerade in der (neu entstehenden) Wirtschaftsinformatik. Der wichtigste Vertreter dieser Denkrichtung war und ist Peter Mertens, dessen Buch Integrierte Informationsverarbeitung in Erstauflage im Jahr 1969 und 2007 in 16. Auflage erschienen ist (vgl. [Mertens 2013]).

Peter Mertens

Die Integration der vorhandenen IT-gestützten Prozessabschnitte (Hard- und Software) war von nun an das zentrale Thema. Ein wichtiges Analyseinstrument waren Datenflussdiagramme, in denen untersucht wurde, welche Informationen sinnvollerweise von einem Prozessabschnitt zum anderen fließen sollten.

Datenflüsse

Diese Sichtweise, das Informations- und Kommunikationssystem eines Unternehmens als ein Miteinander von IT-gestützten Insellösungen zu sehen, die in Interaktion gebracht werden müssen, blieb eine ganze Zeit lang dominierend. Solange mit ihr Produktivitätsgewinne zu erzielen waren. Doch die Entwicklung ging weiter und in den 1980er Jahren setzte sich langsam die Erkenntnis durch, dass weitere Effizienzgewinne nur zu erzielen waren, wenn die Integrationsbemühungen auf eine neue Basis gestellt wurden. Das größere Ganze, die Gesamtaufgabe, und nicht die Datenweitergabe nur von Funktion zu Funktion, von Anwendungssystem zu Anwendungssystem, sollte betrachtet werden.

Der Geschäftsprozess­gedanke

Dieses neue Konzept war der Geschäftsprozessgedanke. Die Betrachtung der Geschäftsprozesse eines Unternehmens, ob sie nun schon automatisiert waren oder nicht, erlaubt viel fundiertere Produktivitätsgewinne als die Optimierung der vorhandenen IT hinsichtlich der auszutauschenden Informationen. Wichtigster Träger dieses Konzepts/Gedankens war und ist August-Wilhelm Scheer mit seinem Standardwerk Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse (vgl. [Scheer 1997]). Er begann mit der Arbeit an diesem Buch 1983, die bisher letzte Auflage (7.) erschien 1997 (2011 erschien ein Softcover reprint der 1997er-Ausgabe).

August-Wilhelm Scheer

Seine Hauptaussage ist, dass die Integration der Informationsverarbeitung viel effizienter betrieben werden kann, wenn sie auf der Analyse der Geschäftsprozesse erfolgt. Mit seinem ARIS-Konzept und seinem Y-CIM-Modell legte er gleichzeitig auch wichtige theoretische Grundlagen bzw. gab erfolgreiche Architekturhinweise.

ARIS: Architektur integrierter Informationssysteme

Er stellte, was damals neu war, Geschäftsprozesse in den Mittelpunkt seines Vorschlags. Das ARIS-Konzept kann verstanden werden als eine Empfehlung, die IT einer Organisation ausgehend von einer Analyse der Geschäftsprozesse zu gestalten. Für die Erfassung, d.h. Modellierung der Geschäftsprozesse erarbeitete sein Team die Methode der Ereignisgesteuerten Prozessketten (EPK). In dieser Phase erreichte die Prozessmodellierung ihre erste Blüte.

Geschäftsprozesse im Mittelpunkt

Die folgende Abbildung veranschaulicht, den damit erreichten Stand. Es wurde erkannt, dass Geschäftsprozesse, wenn sie nicht zu eng definiert werden, quer durch das Unternehmen „gehen“, d.h. zahlreiche Organisationseinheiten und Anwendungssysteme tangieren. Sie liegen dann „quer“ zur klassischen Aufbauorganisation. Denken wir nur an eine Auftragsabwicklung in einem Industrieunternehmen, die klassischerweise durch die Bereiche Vertrieb, Beschaffung, Lagerhaltung, Produktion und Versand abgedeckt wird.

Entlang der Geschäftsprozesse fließen Informationen (auf allen Trägern) in beide Richtungen. Integrationsbemühungen haben sich also an wichtigen Geschäftsprozessen zu orientieren.

Die Prozessmodellierung war in dieser Zeit wesentlich durch die Methode EPK geprägt.

Methode EPK

Der Geschäftsprozessgedanke führt aber ganz automatisch dazu, dass man auch Geschäftsprozessabschnitte, die noch nicht mit Hilfe von Anwendungssystemen realisiert werden, in die Analyse miteinbezieht. Die Betrachtung dieser noch nicht unterstützten Geschäftsprozessabschnitte (in der Abbildung mit „NI“ bezeichnet) ist von besonderer Bedeutung, wenn es um Produktivitätsgewinne geht. Hier stellt sich immer die Frage, ob ihre Unterstützung bzw. Automatisierung sinnvoll ist oder ob sie besser nicht oder nur teilweise unterstützt bzw. automatisiert werden sollen.

Integrierte prozessorientierte Software

Der nächste Schritt war dann ein nahe liegender: Wenn schon Integration, dann nicht durch (teure) Überwindung zahlreicher Schnittstellen (bei Hardware und Software), sondern durch die Realisierung aller automatisierten Abschnitte in einem einzigen Anwendungssystem, mit einer einzigen Datenbank, auf einer einzigen Hardwareplattform. Damit entfallen die Hardwareschnittstellen, die Softwareschnittstellen mutieren zu Datenübergaben zwischen Programmmodulen innerhalb einer einzigen Datenbank.

Ein Anwendungssystem, eine Datenbank, eine Hardware-Plattform

Eine solche Software bedarf der umfassenden Modellierung der Geschäftsprozesse des Anwendungsbereichs.

Nimmt man noch dazu, dass eine solche Software natürlich prozessorientiert ist, alle (kaufmännischen) Funktionsbereiche und vielleicht noch etwas mehr abdeckt sowie an die konkreten Geschäftsprozesse unterschiedlicher Unternehmen anpassbar ist, dann sind wir bei dem Softwaretyp ERP-Software (Enterprice Resource Planning, auch: betriebswirtschaftliche Standardsoftware) angelangt. Idealtypisch vereinfacht sich dann die IT eines Unternehmens im kaufmännischen Bereich zu dem, was die folgende Abbildung andeutet: Eine integrierte prozessorientierte Software bedient die Geschäftsprozesse des Unternehmens. Vgl. für eine Kurzbeschreibung dieses Softwaretyps Abschnitt 17.4.

In der Abbildung ist auch angedeutet, dass es daneben für einzelne Prozessabschnitte Anwendungssysteme außerhalb der ERP-Software gibt, in Verbindung mit dieser (z.B. eine Data-Warehouse-Lösung) oder auch nicht (z.B. ein isoliertes Programm für die Erstellung von Absatzprognosen).

Zurück mit der Integration – Serviceorientierte Architekturen

Es gab dann in den 1980-er Jahren einen Vorschlag, der – genau betrachtet – eine Rücknahme der Prozessintegration vorschlug, die sog. Serviceorientierten Architekturen. Er ist in Abschnitt 17.5. kurz beschrieben. Kurz zusammengefasst war die Idee, die Gesamtleistung des Geschäftsprozesses in einzelne Abschnitte aufzuteilen, die Services, und diese durch Software, vor Ort oder aus der Cloud (WebServices) realisieren zu lassen. Aktuelle Ansätze, rund um Robotic Process Automation (vgl. Kapitel 19), ähneln – zumindest in der Grobarchitektur – diesem Vorschlag.

Rücknahme Prozessintegration

Integration über Unternehmensgrenzen

Unsere arbeitsteilig organisierten Wirtschaftssysteme sind durch einen intensiven und globalen Austausch von Gütern und Leistungen gekennzeichnet. Dieser Austausch verlangt die Weitergabe von Daten, Belegen, von Koordinierungsinformationen (Koordination des Abwicklungsprozesses) oder – mit anderen Worten – die Fortsetzung der Geschäftsprozesse über Unternehmensgrenzen hinweg. Anfang und Ende eines Geschäftsprozesses sind damit in den meisten Fällen nicht mehr so sehr an den Unternehmensgrenzen orientiert, sondern an der umfassenden logistischen Kette von Vorlieferanten zu Endkunden.

Unternehmens-übergreifende Flüsse

Wenn traditionell Handel betrieben wird, ist damit ein reger Austausch von Daten verbunden: Ausschreibungsinformationen, Angebote, Lieferscheine, Rechnungen, Versandavise, Frachtpapiere, Stornierungen, Zahlungen und Bestätigungsschreiben - für jedes dieser Dokumente sind zwischen Auftraggeber und einer beliebigen Menge von Auftragnehmern Daten auszutauschen. Traditionell erfolgte diese Kommunikation per Post und auf Papier. Mit Aufkommen der Daten- und Rechnernetze wurde es jedoch möglich, sie auch auf elektronischem Weg auszutauschen. Damit entstanden die Zwischenbetrieblichen Informationssysteme.

Zwischenbetriebliche Informationssysteme

Diese verbinden die IT-Systeme zweier oder mehrerer Unternehmen. Ziel ist der automatisierte Austausch von Koordinierungsinformationen im Rahmen der Abwicklung von Geschäftsprozessen über Unternehmensgrenzen hinweg. Beispiele sind der elektronische Austausch von Bestellungen, Lieferscheinen oder Rechnungen. In diesem Zusammenhang spricht man auch vom Extended Enterprise, weil hier juristische Grenzen des (einzelnen) Unternehmens durchbrochen werden, wenn gemeinsame Funktionen und Prozesse zum gemeinsamen Vorteil integriert werden.

Extended Enterprise

Dieser klassische elektronische Datenaustausch verursacht hohe Implementierungskosten und ist nicht sehr flexibel. Deshalb gibt es seit nun schon vielen Jahren Anstrengungen, EDI auf der Basis des Internet und mit Hilfe von XML zu betreiben.

XML (Extensible Markup Language) liefert Standards für Aufbau, Inhalt und Aussehen von Dokumenten zur direkten Weiterverarbeitung in der IT der beteiligten Unternehmen. Im Gegensatz zu EDI benötigt XML keine gesonderte Infrastruktur, da hier die Internettechnologien genügen. Es ist eine Weiterentwicklung von HTML (einer typographischen Auszeichnungssprache) mit dem Ziel, den erfassten Texten semantische Eigenschaften zuzuweisen, wodurch XML zu einer sog. semantischen Auszeichnungssprache wird (vgl. [Hansen und Neumann 2009, S. 457]).

Die wirklich aufwendigen Medienbrüche liegen damit heute an den Unternehmensgrenzen. Hier werden Informations- und Kontrollflüsse unterbrochen oder gehemmt, hier wird (sozusagen) die Datenautobahn zur Landstraße. Der Aufwand ist auch deshalb recht hoch, weil es schon lange nicht mehr nur um den einfachen Austausch von Daten geht, sondern darum, ein Geschäftsobjekt(Rechnung, Angebot usw.) bzw. eine Koordinierungsinformation (Eingangsbestätigung usw.) als solche zu übermitteln. Dann kann das empfangende System des anderen Unternehmens z.B. die Rechnung als solche erkennen und gleich dem Prozessverlauf entsprechend weiter handeln. Falls dies realisiert ist, sprechen wir von semantischer Prozessintegration.

Aufwendige Medienbrüche

Eine zentrale Rolle bei der softwaretechnischen Realisierung nimmt hierbei ERP-Software ein, die zusätzlich zu ihren bisherigen Aufgaben noch diese übernimmt, unterstützt allerdings durch Software für die eigentliche unternehmensübergreifende Kommunikation, sei es zwischen Unternehmen (B2B), zwischen Unternehmen und Kunden (B2C) oder sonst wo.

Rolle der ERP-Software

Klappt die Integration über Unternehmensgrenzen, sind die Vorteile enorm. Die dann entstehenden Wertschöpfungsketten weisen folgende Merkmale auf:

• Enge Verzahnung betrieblicher und zwischenbetrieblicher Leistungsprozesse.
• Verstärkte digitale Steuerung der Abläufe unter steigender Einbeziehung interner und externer Informationen.
• Steigende Anzahl beteiligter Partner.
• Sich verkürzende Zeitspanne zwischen Leistungsanforderung und Leistungserstellung.

Die dabei erzielbaren Vorteile sind im wesentlichen Zeitvorteile in der logistischen Kette (z.B. Wiederbeschaffungszeiten) und Rationalisierungspotenziale im administrativen Bereich.

Außenwelt und Cloud Computing

Ganz grundsätzlich ist jede Organisation heute in eine dichte informationelle Umwelt eingebettet. Dies bedeutet, dass Geschäftsprozesse des Unternehmens mit anderen aus der Außenwelt in Kontakt treten müssen. Sei es, dass einem Prozess von außen "zugeliefert" wird, dass er von außen angestoßen wird ("Auftragseingang"), sei es, dass er Richtung Kunde weiter geht. Gelingt hier die Anbindung, wird dies Integration genannt in dem Sinne, dass die Geschäftsprozesse ohne Brüche miteinander gekoppelt werden. In der folgenden Abbildung steht die gestrichelte Linie für einen solchen Geschäftsprozess. Es könnte die Leistungserbringung sein, da diese in der Regel eine solche Struktur aufweist: Sie benötigt Vorleistungen von außen und sie wirkt nach draußen weiter in Richtung Kunden, Wartung, usw. Diese Schnittstellen werden seit einigen Jahren schon intensiv beackert und der teilweisen Automatisierung näher gebracht. Stichworte sind hier semantische Prozessintegration und Portallösungen. Hier muss die Prozessmodellierung Klarheit schaffen und die Grundlagen für die Automatisierungsbemühungen liefern.

Informationelle Umwelt;

Vgl. zu Cloud Computing Abschnitt 17.7

Informationelle Umwelt

Jede Organisation ist in eine informationelle Umwelt eingebettet. Dorthin sendet sie Informationen, von dort erhält sie Informationen. Zur informationellen Umwelt von Unternehmen gehören die Partner, die Wettbewerber, die staatliche Verwaltung, die Kunden, die zuständigen Gewerkschaften, usw. Der Informationsaustausch erfolgt auf allen denkbaren Trägern, natürlich auch mit den Internet-basierten, z.B. durch Auswerten von Daten, die im Social Web entstehen.

In der Abbildung ist auch angedeutet, dass die Gesamtleistung eines Geschäftsprozesses u.U. von mehreren IT-Systemen und WebServices erbracht wird, zusammen mit einem ERP-System. Dies ist heute durchaus Realität. Auch dann gibt es vielfältige Schnittstellen, die zu bewältigen sind. Diese Schnittstellen sind durch ein grafisches Symbol angedeutet. Sie müssen geklärt und durch eine effektive Prozessmodellierung bewältigt werden.

Mehrere IT-Träger und ihre Verknüpfung

Das gleiche gilt für die unter Umständen eingefügten WebServices. Unabhängig davon, ob sie im normalen IT-Umfeld eingefügt oder ob sie in die Leistungen der ERP-Software eingebettet sind, es ergeben sich Schnittstellen und diese müssen bewältigt werden. Eine entsprechende Prozessmodellierung ist dafür unabdingbar.

WebServices

Genau dasselbe gilt für die moderne Form des Outsourcings, die Verlagerung von Teilen der IT in irgendwo auf dem Globus eingerichtete Servicerechenzentren. Dieses Cloud Computing wird inzwischen von vielen Unternehmen genutzt. Konkret bedeutete es, dass ganze Geschäftsprozesse oder Teile von Geschäftsprozessen in die Cloud verlegt werden (vgl. den Punkt Cloud-AS in der folgenden Abbildung). Geschieht dies, müssen die Schnittstellen zwischen den Geschäftsprozessen in der eigenen Organisation und den ausgelagerten geklärt werden. Insbesondere auch, welche Informationen hin und welche zurückfließen. Auch dafür ist eine umfassende Prozessmodellierung unabdingbar, insbesondere auch was die Informationsobjekte (Datenbestände) angeht.

Cloud Computing Weitere Schnittstellen

Cloud Computing

Diese moderne Version des Outsourcings unterscheidet sich von älteren Formen dieses Angebots v.a. durch eine größere Flexibilität. Bei den meisten Angeboten ist es möglich, schnell und unkompliziert zu skalieren (die benutzten Kapazitäten auszubauen oder zu reduzieren). Bezüglich der technischen Realisierung dieser Servicerechenzentren ist v.a. die umfassende Virtualisierung dieser Leistungen zu nennen. Vgl. auch Abschnitt 17.7.

Dabei ist meist zuerst Desintegration zu leisten. Bezieht man nicht die gesamte IT-Leistung auf diesem Weg, muss man Bereiche bestimmen, die man auf diese Weise auslagern möchte. Beispielsweise die wöchentlichen Versandaktionen, die gesamte Buchhaltung, die vierteljährliche Prognoserechnung oder auch gleich das gesamte Finanzwesen. Egal wie, anschließend muss diese Leistung in die übrigen Anwendungssysteme integriert werden. Welche Informationen werden hin gesandt, welche Aktionen werden von dort erwartet, welche Informationen und Koordinierungsinformationen sollen zurückkommen, usw. Auch dies muss die IT eines Unternehmens gegebenenfalls leisten.

Desintegration

Die folgende Abbildung illustriert dies. Der Geschäftsprozess verlässt an einer Stelle die Organisations-IT und setzt seinen Weg "in der Cloud" fort. Die erste durch Prozessmodellierung zu klärende Schnittstelle ist gegeben. Später, wenn der Geschäftsprozess in die Organisation "zurückkehrt", ganz oder teilweise, gibt es wieder eine solche.

Inzwischen schreitet die Integration munter voran. Seit einigen Jahren unter dem Stichwort Robotic Process Automation (mit und ohne KI). Dazu mehr in Kapitel 19.

17.2 Dauerthema Integration

Fassen wir zusammen: Integration von Geschäftsprozessen und die damit verbundene Integration der IT sind ein Dauerthema. Nicht nur für das IT-Management der Organisationen, sondern auch für das Geschäftsprozessmanagement.

Die Integration von Geschäftsprozessen ist eingebettet in das Thema der ganz grundsätzlichen Integration der verschiedenen Anwendungssysteme, die insgesamt zur Gesamtleistung der IT beitragen. Damit lassen sich beim gegenwärtigen Stand der IT-Entwicklung drei Integrationsaufgaben feststellen:

• IT-Integration: Integration der IT-Systeme im eigenen Unternehmen.
• Prozessintegration: Integration der IT-Systeme entlang eines Geschäftsprozesses, auch über Unternehmensgrenzen hinweg - mit oder ohne Internet.
• Cloud-Integration: Integration „mit der Wolke“ - Cloud Computing. Typischerweise, indem Angebote aus dem Web für die eigene IT genutzt werden, oder indem die eigene IT ganz oder teilweise ins Web verlagert wird.

Sucht man nach den Ursachen für diese Integrationsbemühungen, wird man schnell fündig: Es ist der von Beginn des IT-Zeitalters an beobachtbare Trend, der oben beschrieben wurde: ständige Ausdehnung der Prozessunterstützung durch die IT [Staud, 2006, Kapitel 2]. Heute gibt es kaum eine Aufgabe in den Unternehmen, die nicht von Anwendungssystemen unterstützt wird. Und dies bei der oben beschriebenen immer detaillierteren Unterstützung der Geschäftsprozesse durch die Anwendungssysteme, die inzwischen zur Automatisierung geführt hat (vgl. Kapitel 18, 19).

Ursache: Immer mehr, immer detaillierter

Weitere Integrationsbemühungen sind notwendig, falls Teile der IT-Leistung von Cloud-Angeboten bezogen werden. Nutzt man das Cloud Computing, ist meist zuerst Desintegration zu leisten: Bezieht man nicht die gesamte IT-Leistung auf diesem Weg, muss man Bereiche bestimmen, die man auf diese Weise auslagern möchte. Beispielsweise die wöchentlichen Versandaktionen, die gesamte Buchhaltung, die vierteljährliche Prognoserechnung oder auch gleich das gesamte Finanzwesen. Egal wie, anschließend muss diese Leistung in die übrigen Anwendungssystemen integriert werden. Welche Informationen werden hin gesandt, welche Aktionen werden von dort erwartet, welche Informationen sollen zurückkommen, usw. Auch dies muss die IT eines Unternehmens gegebenenfalls leisten.

Integration mit „der Wolke“

Das gleiche gilt für die unter Umständen eingefügten WebServices. Unabhängig davon, ob sie im normalen IT-Umfeld eingefügt oder ob sie in die Leistungen der ERP-Software eingebettet sind, es ergeben sich Schnittstellen und diese müssen bewältigt werden.

WebServices

Die hier anstehenden Aufgaben löst in erster Linie das IT-Management. Das Geschäftsprozessmanagement sollte aber mitentscheiden. Z.B. bei Fragen mit strategischer Bedeutung: Soll (Kann) die Personalabrechnung ausgelagert werden? Kann der Mailserver zu einem Anbieter ausgelagert werden, bei dem nicht klar ist, wo er den Server betreibt?

IT-Management

Nicht-Integration bedeutet Defizite in der Prozess- und Datenintegration, die mit viel Aufwand überwunden werden müssen. Die Reibungsverluste äußern sich als großer Aufwand für alle Maßnahmen der Informationsweitergabe. Wenn z.B. von der Produktion Daten zum Vertrieb weitergegeben werden sollen, müssen die Formate jeweils umgewandelt werden. Falls die beiden Abteilungen unterschiedliche Hardware nutzen, muss auch dies überwunden werden.

Defizite in der Prozess- und Datenintegration

Damit ist die Integration der einzelnen Systeme (Hardware und Software) die große Herausforderung. Eine solche Integration ist notwendig, um eine weitere Optimierung der Geschäftsprozesse und der gesamten IT zu erreichen

Eine weitere Konsequenz der „Nicht-Integration“ von Datenbeständen sind oft Redundanzen. Werden z.B. Kundendaten in verschiedenen Datenbanken verwaltet, kann es leicht geschehen, dass im einen Datenbestand dieselbe Information anders festgehalten ist als im anderen.

Redundanzen

Ein weiterer Grund für Integrationsbemühungen ist der oben schon erwähnte Wunsch nach einer Automatisierung der Geschäftsprozesse (vgl. Kapitel 18, 19).

Automatisierung

Integration in allen Aspekten (Technik, Organisation, Geschäftsprozesse, Programme) ist also unabdingbar. Eine solche Integration von Anwendungssystemen wird auch unter dem Stichwort Enterprise Application Integration (EAI) diskutiert.

In den nächsten Abschnitten werden wichtige IT-Systeme, mit denen zentrale Prozessbereiche unterstützt werden, kurz vorgestellt.

17.3 ERP-Software

17.3.1 Definition

Wenn es um die IT-Unterstützung für die Geschäftstätigkeit geht, muss an ersten Stelle ERP-Software (Enterprise Resource Planning) genannt werden. Sie ist geradezu Ausdruck der Prozessorientierung, die vor ca. 50 Jahren [Anmerkung] einsetzte.

Bis Anfang der 1990er-Jahre wurden in den Unternehmen vorwiegend Großrechner- oder PC-Lösungen eingesetzt. Diese unterstützten aber meistens nur einen Teilbereich des Betriebes und waren nicht oder nur unzureichend miteinander integriert, wie in Abschnitt 17.1 gezeigt.

Mit dem Aufkommen leistungsfähiger Netze und Computer wurde der Einsatz integrierter Software möglich und auch gefordert. Die Entwicklung solcher integrierten Anwendungssysteme, die möglichst alle Unternehmensbereiche verbinden und abdecken sollen, benötigt eine große Kapazität an Entwicklungsressourcen und umfangreiche Kenntnisse in der Informationstechnologie und den Anwendungsbereichen, die nur wenige Softwareentwickler bieten können. Deshalb entwickelte man immer weniger „maßgeschneiderte“ Individualsoftware , sondern setzt auf gekaufte Software „von der Stange“, auf Standardsoftware. Im betriebswirtschaftlichen Bereich hat sich hier ERP-Software durchgesetzt.

Individualsoftware,
Standardsoftware,
prozessorientierte Standardsoftware

Dieser Softwaretyp hat sich, trotz aller Prognosen, die immer wieder ein baldiges Verschwinden ankündigten, bis heute bewährt. Er stellt für viele Organsationen das "Rückgrat" der IT dar. Diese Integrierte prozessorientierte Standardsoftware, die meist ERP-Software genannt wird, hat (idealtypisch) folgende Eigenschaften:

Der Text dieses Abschnitts fasst Ausführungen von [Staud 2006, Kapitel 3] zusammen.

• Sie ist prozessorientiert in dem Sinn, dass sie ganze Geschäftsprozesse unterstützt und nicht nur einzelne Funktionen (wie z.B. eine Textverarbeitung).
• Sie unterstützt alle Geschäftsprozesse des kaufmännischen bzw. betriebswirtschaftlichen Bereichs eines Unternehmens einschließlich der Produktionsplanung (1. Integrationsaspekt).
• Sie ist für die konkreten Strukturen und Geschäftsprozesse vieler Unternehmen geeignet (2. Integrationsaspekt).

Mit den beiden Integrationsaspekten ist dieser Softwaretyp von Textverarbeitungen, Tabellenkalkulationen, usw. abgegrenzt, die ja auch als Standardsoftware bezeichnet werden.

ERP-Software ist auch auf die Zusammenarbeit mit zwischen- und überbetrieblichen Geschäftsprozessen zum Beispiel zum Supply Chain Management oder zum Customer Relationship Management vorbereitet.

Das Konzept

Damit beruht ERP-Software auf einer Grundannahme, die sich wie folgt formulieren lässt: Es ist möglich, für die Anforderungen von Organisastionen (insbesondere Unternehmen) eine gemeinsame, integrierte und prozessorientierte Software zu erstellen. Dies beruht auf zwei Eigenschaften heutiger Geschäftsprozesse:

• Die meisten Geschäftsprozesse sind standardisiert, d.h. sie laufen bei Wiederholung gleich ab und es gibt nicht zu viele Varianten (vgl. Kapitel 4).
• Es gibt so viele Gemeinsamkeiten zwischen den Geschäftsprozessen verschiedener Unternehmen, dass es möglich ist, für eine Aufgabe eine gemeinsame „Software von der Stange“ zu schreiben.

„Durchschnittliche“ und vorgedachte Geschäftsprozesse

Um dies leisten zu können, hat ERP-Software verschiedene Bedingungen zu erfüllen. Die wichtigste ist, dass sie Modelle von Geschäftsprozessen in ihrer Datenbank und in ihren Programmen realisiert hat und dass diese - mithilfe entsprechender Analysen realer Geschäftsprozesse - den tatsächlichen Abläufen und Strukturen in den Unternehmen möglichst ähnlich sein müssen. Denn natürlich gibt es zwischen den Geschäftsprozessen der einzelnen Unternehmen trotz aller Ähnlichkeit Unterschiede, sodass eine so konzipierte Software den realen Geschäftsprozessen immer nur mehr oder weniger ähnlich, aber nicht voll mit ihnen übereinstimmend sein kann.

Modelle von Geschäftsprozessen

Deshalb ist es unvermeidlich, dass ERP-Software softwaretechnisch so realisiert sein muss, dass sie in einem gewissen Umfang an die realen Strukturen des jeweiligen Unternehmens angepasst werden kann. Diese Möglichkeit der Anpassung durch das Verstellen von Parametern ("Customizing", vgl. unten) ist konstituierend für ERP-Software.

1. Integrationsaspekt

Doch nun zurück zu den oben angeführten Definitionsmerkmalen. Zumindest vom Grundprinzip her soll dieser Softwaretyp möglichst alle betriebswirtschaftlichen/kaufmännischen Bereiche einschließlich der Produktionsplanung umfassen.

Etwas genauer kann die Abgrenzung mit dem Ansatz von Scheer [Anmerkung] bzw. Mertens vorgenommen werden, da diese die horizontale Integration (über die klassischen Bereiche wie Produktion, Beschaffung, Lagerhaltung, Rechnungswesen, Personal, usw.) von der vertikalen (zwischen Administrations- und Dispositionssystemen, Wertorientierten Abrechnungssystemen, Berichts- und Kontrollsystemen, usw.) unterscheiden. Davon ausgehend kann festgestellt werden, dass heutige ERP-Software bei den Wertorientierten Abrechnungssystemen ihren Schwerpunkt hat, mehr oder weniger gut auch die Ebene der mengenorientierten operativen Systeme abdeckt (ohne Forschung/Entwicklung und die eigentliche Produktionssteuerung) und sich auch zunehmend in die Berichts- und Kontrollsysteme hinein ausdehnt.

Genauere Agrenzung

Diese Eigenschaft von ERP-Software, weite Teile der betriebswirtschaftlich/kauf­männischen Geschäftsprozesse abzudecken, wurde oben schon 1. Integrationsaspekt genannt. Hintergrund davon ist der Anspruch, das gesamte Informationssystem des beschriebenen Bereichs integriert zu organisieren. Zum einen, was die Daten angeht, am besten in einer einzigen unternehmensweiten Datenbank, zum anderen bezüglich der von der Software zur Verfügung gestellten Funktionalitäten.

Dieser erste Integrationsaspekt hat auch etwas mit dem Ziel der Optimierung der innerbetrieblichen Abläufe und der schlankeren Gestaltung des Informationssystems zu tun, denn beides kann nur realisiert werden, wenn die Integration der verschiedenen betriebswirtschaftlichen Anwendungsprogramme gelingt.

2. Integrationsaspekt

Der 2. Integrationsaspekt meint den Umstand, dass ERP-Software vielen unterschiedlichen Unternehmen dienen soll. Auch diese Eigenschaft kann nur mithilfe einer fundierten Analyse der Geschäftsprozesse – über verschiedene Unternehmen hinweg – realisiert werden. Diese ist Teil des durch die beiden Integrationsaspekte erzwungenen unabdingbaren tragfähigen Modellierungskonzepts.

Ist der Bereich, den eine ERP-Software abdecken soll, auf eine bestimmte Branche begrenzt, wird sie Branchensoftware genannt.

Branchensoftware

Das Gegenstück zu Standardsoftware ist Software, die für ein bestimmtes Unternehmen und die dort vorliegenden Abläufe und Strukturen gefertigt wurde. Sie wird Individualsoftware genannt und kann von den eigenen Entwicklern des Unternehmens oder von einem Softwarehaus stammen.

Individualsoftware

Anspruch und Customizing

Der Anspruch von ERP-Software, für viele (wenn nicht alle) Unternehmen geeignet zu sein, ist schon erstaunlich, denn betrachten wir, über eine größere Zahl von Unternehmen hinweg, einen bestimmten betriebswirtschaftlichen Anwendungsbereich, z.B. die Finanzbuchhaltung, die Auftragsabwicklung, die Kontaktbearbeitung oder das Personalwesen, so stellen wir fest, dass dieser in den einzelnen Unternehmen natürlich durchaus unterschiedlich gestaltet sein kann. Dies gilt selbst für Bereiche wie die Finanzbuchhaltung, die durch Vorschriften, gesetzliche Regelungen und betriebswirtschaftliche Theorien vorgeprägt sind, viel mehr aber für Gebiete wie Materialwirtschaft, Produktionsplanung, usw., die durch das Produkt, den Produktionsprozess, die jeweilige Firmenkultur und andere Dinge geprägt und daher sehr unterschiedlich sind. Die standardisierten Geschäftsprozesse sind deshalb in ERP-Software recht flexibel gestaltet, sodass man sie in gewissem Rahmen an die einzelnen Bedürfnisse in den Unternehmen anpassen kann. Man spricht dann von Customizing (vgl. unten).

Anpassund der Software an die realen Prozesse

Darüberhinaus hat sich in den vergangenen Jahrzehnten aber auch immer wieder gezeigt, dass der Leistungsumfang der jeweiligen ERP-Produkte nicht ausreichte und neue Softwarelösungen in die vorhanden IT-Architektur mit hinzu genommen wurden, von CRM-Lösungen bis zu den ganz aktuell diskutierten Softwarerobotern.

Ergänzungen

17.3.2 Grundlage

Grundlage von ERP-Software ist damit eine möglichst umfassende Analyse der in den Unternehmen konkret vorliegenden Geschäftsprozesse. Versetzen wir uns in die Position der Ersteller von prozessorientierter Standardsoftware, besteht die zu lösende Aufgabe in Folgendem:

• Herausfinden der Gemeinsamkeiten all der verschiedenen Realisationen eines konkreten Geschäftsprozesses (z.B. einer Auftragsabwicklung). Dabei entsteht eine Art „durchschnittlicher Geschäftsprozess".
• Festlegen von als „sinnvoll“ erachteten Abweichungen (vom „durchschnittlichen Geschäftsprozess“), die ebenfalls in der Software realisiert werden.
• Eventuelle Miteinbeziehung neuer Methoden für den jeweiligen Geschäftsprozess (z.B. neuer Verfahren der Absatzplanung in den entsprechenden Geschäftsprozess)
• Anbieten eines Instrumentariums, mit dem die Kunden dann ihre Variante der Geschäftsprozesse festlegen können (Customizing bzw. Parametrisierung)

Customizing

Mit dem Begriff Customizing wird, siehe oben, die Anpassung der Standardsoftware an die realen Prozesse beschrieben. Zumindest der größere Teil dieser Anpassung soll bei Standardsoftware so ablaufen, dass nicht programmiert werden muss, sondern dass nur die wie auch immer gestalteten Parameter der Standardsoftware verstellt werden. Ein eventueller Rest kann dann mit einer mitgelieferten Programmiersprache z.B. Java, früher bei SAP ABAP) erledigt werden.

Anpassung Software an reale Prozesse

Überwindung der „Lücke“

Eine Aufgabe, vor das das Geschäftsprozessmanagement immer wieder steht, ist die Bewältigung der "Lücke" zwischen den realen Geschäftsprozessen (durch Istanalysen erhoben) und denen der zugekauften oder gemieteten prozessorientierten Software (automatisiert oder unterstützend). Gemeint sind damit die Unterschiede zwischen den beiden Prozessvarianten. Diese Lücke ist auch dann vorhanden, wenn im Auswahlprozess für die prozessorientierte Standardsoftware dieser Punkt intensiv mit bedacht wurde.

Reale Geschäftsprozesse und „Software-Prozesse“

Grundsätzlich sind für die Überwindung einer solchen Lücke folgende Vorgehensweisen denkbar:

1. Umfassende Anpassung der realen Geschäftsprozesse an die der ERP-Software.

2. Umfassende Anpassung der Geschäftsprozesse der ERP-Software an die realen.

3. Kompromiss aus 1) und 2).

4. Optimierung der realen Geschäftsprozesse und Kompromiss aus 1) und 2), evtl. in Kombination mit einer vorhandenen oder anstehenden Zertifizierung.

Wahrscheinlich erscheinen die ersten beiden Lösungen als sehr radikal. Nichtsdestotrotz werden sie gewählt. Die erstgenannte z.B. bei Supportprozessen, die zweitgenannte eher nicht und wenn, dann höchstens im Bereich der Kernprozesse, falls für diese nicht gleich eine Individuallösung gewählt wird.

Jede Vorgehensweise hat ihre Konsequenzen. Die erste Lösung (die im Übrigen auch nicht ohne minimales Anpassen auskommen wird) bedeutet einen tiefen Einschnitt in die bis dahin vorhandenen Unternehmensabläufe und schafft von daher u.U. Akzeptanzprobleme bei den Nutzern. Außerdem entsteht ein erhöhter Schulungsaufwand, da es nicht nur um das Gewöhnen an eine neue Programmoberfläche mit leicht veränderten Abläufen geht, sondern um meist grundsätzlich veränderte Geschäftsprozesse. Außerdem bedeutet sie u.U. einen starken Profilverlust. Sie ist aber, was den Aufwand bei Einführung und Releasewechseln angehtangeht, die preiswerteste Lösung. Oft wird sie in Unternehmen gewählt, die auf eine rasche Entschärfung ihrer Kostensituation angewiesen sind.

Konsequenzen

Mit Releasewechsel werden Lieferungen einer neuen Version der Software mit wenigen oder vielen, manchmal auch grundlegenden Änderungen, bezeichnet. Sie erfolgen relativ oft (bei einzelnen Herstellern bis zu jährlich).

Viele Unternehmen entscheiden sich auch dafür, diese erste Lösung für die unterstützenden Geschäftsprozesse zu wählen und für die Kernprozesse eine der anderen.

In allen Punkten geradezu entgegengesetzt ist die zweite Lösung. Treibt man dies weit genug, reproduziert man sich die alte Individualsoftware (vor allem deren Ablauflogiken, weniger deren Oberflächen) und hat großen Aufwand bei der Einführung und bei jedem Releasewechsel, wo dann alle früher getätigten Änderungen dahingehend überprüft werden müssen, ob sie mit der neuen Basisversion der Standardsoftware noch funktionieren. Noch aufwendiger gestaltet sich oft der Abgleich der veränderten Datenstrukturen. Natürlich gibt diese Variante aber die Möglichkeit, Profilverlusten aller Art energisch entgegenzutreten.

Reproduktion der „alten“ Software

„Zwischenlösung“

Eine Lösung, die als Variante 1b bezeichnet werden könnte, traf der Verfasser öfters in Unternehmen an. Dabei bleibt die ERP-Software selbst so gut es geht unverändert, damit die neuen Versionen relativ problemlos eingespielt werden können. Die gewünschten Änderungen (deren Umfang auf das Nötigste beschränkt wird) werden über externe Programmierwerkzeuge, die über einfache Schnittstellen mit der Standardsoftware kommunizieren, realisiert. Diese Lösung wird allerdings nur für die Supportprozesse ergriffen.

Meist wird bei der Überwindung der Lücke zu einem Kompromiss gegriffen, wie er oben als dritte Lösung angeführt ist. Änderungen, die unabdingbar erscheinen werden vorgenommen, ansonsten werden die Geschäftsprozesse der ERP-Software übernommen.

Reengineering

Auch die vierte obige Lösung wird sehr oft gewählt. Da die Beschäftigung mit Standardsoftware meist sowieso dazu führt, sich mit den Geschäftsprozessen näher zu befassen, wird die Einführung dann gleich für Optimierungsvorhaben genutzt. Dieses Reengineering erfolgt dann unter gleichzeitiger Berücksichtigung der realen Geschäftsprozesse und denen der Standardlösung.

ISO-Zertifizierung

In vielen Unternehmen kommt noch ein vierter zu berücksichtigender Faktor hinzu, eine ISO-Zertifizierung. Da diese natürlich auch auf die Geschäftsprozesse Einfluss nimmt, müssen dann

• reale Geschäftsprozesse,
• die der Standardlösung,
• die Optimierungswünsche und
• die Zertifizierungsvorgaben

zusammengebracht werden.

17.3.3 Echtzeit und Datenintegration.

Wichtig für jede integrierte Software ist, dass die einzelnen Anwendungen umfassend miteinander verknüpft sind, sowohl bezüglich der Prozesse als auch der Daten. Auf den Punkt gebracht bedeutet dies, dass eine Information ab dem Zeitpunkt ihrer Entstehung überall dort zur Verfügung steht, wo sie benötigt wird. Erfolgt beispielsweise die Erfassung einer Lieferung im Wareneingang, wird nicht nur die Bestandsführung angepasst, sondern es erfolgt auch sofort die wertmäßige Verbuchung. Diese Verknüpfung erfordert eine leistungsstarke, voll integrierte Datenbank. Hier werden die Informationen für die Module redundanzfrei und konsistent gehalten, z.B. Materialien (Artikel), Lieferanten, Kunden, Mitarbeiter, Sachkonten, Kostenstellen, Aufträge, Bestellungen, Lieferscheine usw.

Umfassende Verknüpfung

In Richtung schnellerer Auswertungszeiten zielt die InMemory-Technologie (Hana) von SAP. Sie verbindet spezifische Hardware- und Softwaretechnologien, um die auszuwertenden Daten im Arbeitsspeicher zu halten. Damit werden die Auswertungszeiten stark verkürzt. Zum Einsatz kommt diese Technologie überall dort, wo große Datenmengen verarbeitet werden müssen, z.B. im Kundenbeziehungsmanagement oder bei der Auswertung von Daten aus dem Social Web.

17.3.4 Beispiel SAP

Das Softwarehaus SAP war das erste, das eine ERP-Softwarr angeboten hat, und es ist damit groß geworden. Das erste Produkt hatte die Bezeichnung R/2 und war eine Großrechnerlösung. Es hatte bereits den Charakter einer integrierten prozessorientierten Software, allerdings auf dem damaligen (Gründungsjahr SAP: 1972) Stand der Technik. Das Nachfolgeprodukt war R/3, eine Client/Server-basierte Software.

Inzwischen bietet das Unternehmen SAP eine Vielzahl von Produkten an. Eines davon, SAP Business One, ist für Kleine und Mittelständische Unternehmen (KMU) gedacht. Es weist das für heutige ERP-Software typische Leistungsspektrum auf (Abruf der Daten von der SAP-Webseite am 5.6.2013. Da hat sich bis heute (2020) natürlich auch einiges geändert, die Grundstruktur blieb aber gleich. Eine aktuelle Darstellung folgt.):

• Integriertes Finanzmanagement (Buchhaltungs- und Finanzprozesse, Geschäftsabschlüsse erstellen, usw.)
• Lagerverwaltung und Produktionsplanung (Lagerdatenverwaltung für Bestandsführung und Fertigungssteuerung)
• Kundenbeziehungsmanagement (Unterstützung der Vertriebsprozesse vom Lead-Management bis zum Kundenservice)
• Beschaffung (alle Beschaffungsprozesse)
• Mobilität (Verwaltung von Aufgaben, Aktivitäten und Kundendaten mit dem mobilen Gerät)
• Integrierte Berichtsfunktion und Business Intelligence (Erstellung von Berichten, Auswertung von Daten)

Durch den Einsatz der von der SAP entwickelten InMemory – Datenbanktechnologie (vgl. Abschnitt 17.8) sind teilweise Auswertungen in Realzeit möglich.

Eher auf größere Unternehmen zielt das Produkt SAP ERP. Dieses besteht aus folgenden Komponenten:

SAP ERP.

• SAP ERP Financials,
• SAP ERP Human Capital Management,
• SAP ERP Operations,
• SAP ERP Corporate Services.

SAP ERP Financials unterstützt die finanzwirtschaftlichen Prozesse und deckt kon­kret folgende Funktionen ab:

• Finanzbuchhaltung und Controlling
• Financial Supply Chain Management für die Auftragsabwicklung, den Cashflow und die Verwaltung des Umlaufvermögens
• Treasury für die Verwaltung der finanziellen Mittel
• Corporate Governance für die Verwaltung und die verbesserte Einhaltung gesetzlicher Vorschriften

SAP ERP Human Capital Management (SAP ERP HCM) unterstützt die Geschäftsprozesse im Personalwesen. Besondere Erwähnung finden auf den Webseiten der SAP die folgenden:

• Personalanalyse – hier werden in Echtzeit Personaldaten zur Verfügung gestellt, mit allen Kosten und den ROI aus Personalprojekten,
• Talent Management für die Personalentwicklung,
• Workforce Process Management zur Gestaltung von Personalprozessen, auch auf einer globalen Plattform,
• Workforce Deployment für den Personaleinsatz und die Auswertung der dabei anfallenden Daten.

SAP ERP Operations für die operativen Prozesse (bezogen auf Industrieunternehmen). Ausdrücklich nennt die SAP auch die damit gegebene Möglichkeit der Automatisierung dieser Prozesse:

• Beschaffung und Logistik für alle anfallenden Prozesse, von Bestellanforderungen per Self-Service bis hin zur flexiblen Fakturierung und Zahlungsabwicklung sowie der Optimierung des physischen Materialflusses im Unternehmen.
• Produktentwicklung und Fertigung für den gesamten Produktentwicklungs- und Fertigungskreislauf.
• Vertrieb und Service für die kundenorientierten Prozesse, den Vertrieb von Produkten und Dienstleistungen, die Beratungsservices und die dafür evtl. erforderlichen internen Prozesse, beispielsweise die Berechnung von Provisionen und leistungsorientierten Vergütungen.

SAP Corporate Services für die Verwaltung von Immobilien, der Vermögenswerte im Unternehmen, von Projektportfolios, Geschäftsreisen, der Einhaltung von Umweltschutzauflagen, Gesundheitsvorschriften und Sicherheitsrichtlinien, von Qualität und Außenhandel. Konkret sind enthalten:

• Immobilienmangement für die Erschließung von Bauland, Vermietung und das Immobilienmanagement.
• Enterprise Asset Management für die Wartung und Pflege des Anlagevermögens. Enthalten sind Funktionen für regelmäßige Wartungsarbeiten, die Budgetierung von Wartungskosten, die planmäßige Ausführung von Maßnahmen und die Abwicklung von Freischalteverfahren.
• Projekt- und Portfoliomanagement für das strategische Portfoliomanagement,
• Reisemanagement zur Verwaltung von Geschäftsreisen.
• Umwelt-, Gesundheits- und Arbeitsschutz in der Anwendung SAP Environment, Health, and Safety Management (SAP EHS Management), es erlaubt die Umsetzung der entsprechenden Strategien und rechtlichen Vorgaben auf lokaler Ebene sowie standort- und länderübergreifend.
• Qualitätsmanagement für die unternehmensweite Umsetzung der hier geplanten Maßnahmen.
• Außenhandel für die Verwaltung der internationalen Lieferkette, z.B. auch für den elektronischen Austausch von Daten mit den Systemen der entsprechenden Behörden.

Soweit ein kurzer Blick auf das Angebot der SAP. Diese Auflistung sollte den Leistungsumfang von integrierten Anwendungssystemen deutlich machen. Einen ähnlichen Leistungsumfang weisen auch die Produkte der anderen einschlägigen Softwarehäuser auf.

17.3.5 Aktuelle Situation

Nutzung von Cloud-Lösungen

Marc Pfeifer (Lufthansa Industry Solutions) skizziert die aktuelle Situation:

SAP C/4 HANA Suite (auch: SAP Customer Expereience Suite) besteht aus "fünf Clouds", die einerseits verknüpft sind, die aber "je nach Bedarf sepaat eingesetzt werdne können"

SAP

<<mehr und aktuelles in Kürze>>

17.3.6 Konsequenzen

Es gibt heute in der Regel keinen Weg mehr, der am Einsatz von ERP-Software vorbeiführt. Zumindest für den Bereich der Supportprozesse. Trotzdem sollen einige Konsequenzen angesprochen werden, die ja - im Überschneidungsbereich von Geschäftsprozessmanagement und IT-Management bedacht werden sollten.

Hat ein Unternehmen ERP-Software eingeführt, erfolgen Weiterentwicklung und Wartung außerhalb des eigenen Unternehmens.Wenn nicht ein eigenes „Competence Center“ eingerichtet wird, das dann nicht nur hausinterne Kompetenz realisiert, sondern auch fundiert Änderungsvorschläge an das Softwarehaus macht, von dem die Standardsoftware kommt.

Fremdbestimmung

Dies realisieren derzeit aber nur sehr wenige und sehr große Unternehmen.Die Innovation ist im Wesentlichen verlagert auf das Softwarehaus, das auch das volle Entwicklungsrisiko trägt. Natürlich nimmt das Standardsoftwarehaus (wenn es kompetent ist) ständig die Veränderungen der Geschäftsprozesse in den Unternehmen wahr (auch in Form von Veränderungsvorschlägen der Kunden) und versucht, seine Strukturen anzupassen, aber dies ist eine völlig andere Situation als bei einer eigenen Entwicklermannschaft im Haus.

Durch ERP-Software entsteht damit eine große Abhängigkeit vom Softwareherstel­ler. Sie ist mit der Abhängigkeit vergleichbar, die gegenüber dem Anbieter von Individualsoftware besteht, allerdings sind die Gewichte sehr unterschiedlich. Die großen Anbieter von Standardsoftware haben ein so großes Gewicht, dass zumindest ein einzelner Kunde (ein einzelnes Unternehmen) schwerer Gehör findet als z.B. bei einem regionalen Ersteller von Individualsoftware.

Abhängigkeiten

Ein Unternehmen, das vor der Einführung von ERP-Software ein hervorragendes und auf dem Stand der Technik befindliches IT-System mit entsprechender Anwendungssoftware hatte, verliert durch die Einführung unter Umständen seine Vorteile vor den Mitbewerbern, es wird diesbezüglich „durchschnittlich“ und erleidet einen Profilverlust. Natürlich kann auch durch den mehr oder weniger geschickten Einsatz von Standardsoftware Profil gewonnen werden, allerdings nicht in dem Umfang wie bei Individuallösungen.

Profilverlust

In der Regel ist es aber so, dass ein so hervorragend ausgestattetes Unternehmen auf die Übernahme einer Standardlösung verzichten wird.

17.3.7 Vor- und Nachteile

Trotz der dominanten Position von ERP-Software kann man sich mit der Frage beschäftigen, was für und gegen ERP-Software spricht.

Dafür spricht u.a.:

Vorteile

• Kosteneinsparung gegenüber Eigenentwicklung
• Verkürzung der Einführungszeiten, da die Software sofort verfügbar ist
• hohe Programmqualität aufgrund der größeren Erfahrung der Programmierer
• Wartung und Weiterentwicklung der Software erfolgt durch den Anbieter
• Anwendungen lassen sich auch realisieren, wenn kein oder nur unzureichend qualifiziertes DV-Personal im Unternehmen verfügbar ist; die eigenen Ressourcen werden geschont
• mit der Software wird betriebswirtschaftliches Know-how, das in der Software abgebildet ist, in die Unternehmen gebracht

Demgegenüber stehen u.a. folgende Nachteile:

Nachteile

• Wegen des Charakters als Standardsoftware sind evtl. die Geschäftsprozesse des Unternehmens nicht umfassend abgedeckt, insbesondere im Bereich der Kernprozesse der Unternehmen.
• Der Leistungsumfang ist sehr groß, trifft aber nur teilweise die Bedürfnisse des Unternehmens, denn es handelt sich immer um eine Standardlösung.
• Gewisse Unflexibiltät gegenüber Weiterentwicklungen, ganz aktuell z.B. gegenüber den Bemühungen um Prozessautomatisierung. Hier wird dann "ergänzt", vgl. Abschnitt 19.2.
• Abhängigkeit vom Hersteller der Software. Angesichts des Leistungsumfangs und auch der preislichen Dimension sind die Kosten für einen Wechsel zu einer anderen ERP-Software sehr hoch. Braucht man – um nur ein Beispiel zu nennen – die InMemory-Technologie des derzeitigen Softwarehauses nicht wirklich, ist eine Vermeidung und/oder ein Wechsel recht schwierig.

Aktuelles Beispiel zum letztgenannten Punkt: Nach einer Studie der Hochschule Koblenz, steht derzeit (2019) in vielen Unternehmen die Frage des Umstiegs auf S/4 HANA an. Das Support-Ende für das Vorgänger Release ERP Central Componente (ECC) ist für 2025 angekündigt. Der Artikel zur Studie deutet auch die Probleme der Nutzer an, z.B. die Umstellung des Datenmodells. Mehr dazu in [Bayer 2019d].

Abschließend kann hier folgendes angemerkt werden. Zumindest bei den Supportprozessen ist es heute für ein Unternehmen nicht mehr möglich, ohne eine ERP-Software auszukommen. Eine Individualsoftware wäre heute hier schlicht zu teuer. Nicht so bei Kernprozessen. Hier sind in den Unternehmen tatsächlich sehr oft Eigenentwicklungen oder eine stark durch Anpassungen („Customizing“) veränderte ERP-Software anzutreffen. Betrachtet man die gesamte IT, ergibt sich also fast immer ein Zusammenspiel verschiedener Anwendungsprogramme, übrigens unter Umständen auch von Programmen verschiedener Anbieter von ERP-Software.

Ganz anders ist die Situation bei den großen Internet-Unternehmen. Hier wird in großem Umfang webbasierte Individualsoftware programmiert (vgl. Kapitel 20).

17.3.8 Perspektiven

Einen Eindruck von der aktuellen Situation rund um ERP-Software gibt [Bayer 2019c]. Auch hier wird deutlich, dass ERP-Software weiterhin für viele Unternehmen das Rückgrat ihrer IT darstellt.

<<mehr in Kürze>>

17.3.9 Nicht nur ERP-Software

Man könnte oben den Eindruck gewinnen, dass „nichts mehr geht“ ohne ERP-Software und dass sie völlig ausreicht für die Gestaltung der IT, so dass Eigenentwicklungen nicht mehr nötig sind. Die Umsätze der entsprechenden Softwarehäuser (SAP, Oracle, …) deuten auch in diese Richtung.

Dagegen spricht, dass tatsächlich in vielen Unternehmen (immer noch bzw. wieder) eigene Software entwickelt wird. Softwareentwicklung ist ein wichtiges Thema, ständig werden alte Entwicklungsplattformen verbessert, neue angeboten und neue Methoden vorgeschlagen (nur ein Beispiel: agile Entwicklung). Es ist tatsächlich so, dass ERP-Software (als integrierte prozessorientierte Software, die auf den betriebswirtschaftlichen Teil fokussiert) und andere Programme – auch eigenentwickelte – koexistieren. Der Grund liegt darin, dass durch die Ergänzungen der ERP-Software das IT-mäßige Leistungsprofil der Unternehmen ergänzt werden kann und oft auch ergänzt werden muss. Ganz aktueller Ausdruck hiervon sind die Bemühungen rund um Geschäftsprozessautomatisierung, z.B. das Einfügen von Softwarerobotern in vorhandene IT-Landschaften.

Individualsoftware – immer wieder

Es gibt auch Bereiche, in denen ERP-Software, so weit man einen Einblick gewinnen kann, keine dominante Rolle spielt. Dies sind die großen Internet-Unternehmen. Hier ist Individualsoftwaredominant. V.a. für die Durchführung der Geschäftstätigkeit. Mehr dazu in Kapitel 20.

Vor allem Individualsoftware

17.3.10 Die führenden Anbieter

Gemäß einer Gartner-Studie sind im Jahr 2018 folgende Unternehmen die führenden Anbieter im ERP-Markt:

17.4 Workflow-Management-Systeme

Wenn in der einschlägigen betriebswirtschaftlichen Literatur von IT-Unterstützung für Geschäftsprozesse die Rede ist, dann wird meist an Workflow-Management-Systeme gedacht (vgl. z.B. [Gadatsch 2015, Abschnitt 2.3], [Schmelzer und Sesselmann 2013]).

17.4.1 Definition

Ein Workflow ist ein ganz oder teilweise automatisierter Abschnitt eines Geschäftsprozesses. Laudon et al. sprechen diesbezüglich von Geschäftsvorfall, Vorgang und Arbeitsablauf. Er besteht aus einzelnen Aktivitäten und ist ausdrücklich auf der operativen Ebene angesiedelt, "idealerweise so exakt, dass die folgende Aktivität durch den Ausgang der jeweils vorangehenden determiniert ist." [Laudon, Laudon und Schoder 2010, S. 918].

Workflow

Ein Workflow hat einen definierten Anfang, einen fixierten Kontrollfluss und ein definiertes Ende. "Allgemein sind Workflows organisationsweite arbeitsteilige Prozesse, in denen die anfallenden Tätigkeiten von Personenen bzw. Softwaresystemen koordiniert werden." [ebenda]

Laudon et al. definieren dann Workflow-Management (WfM) wie folgt:

Workflow-Management

"Workflow-Management umfasst alle Aufgaben, die bei der Modellierung, Spezifikation, Simulation sowie bei der Ausführung und Steuerung von Workflows erfüllt sein müssen." [ebenda]

Das umfasst dann auch die Aufgabe, "eine Spezifikation für die technische Ausführung von Arbeitsabäufen zu liefern" und kann deshalb als "eine technische Umsetzung des Geschäftsprozessmanagements verstanden werden." [ebenda]

Workflow-Management beruht auf dem, was früher Vorgangsbearbeitung genannt wurde. Ein Vorgang (vgl. Abschnitt 2.2) besteht (hier) aus einer Folge von Tätigkeiten und, falls notwendig, dem Weg des Vorgangs über mehrere Arbeitsplätze. Dazu gehörten Entscheidungsalternativen, die zu Verzweigungen führten. Mehrere miteinander verknüpfte Vorgänge können dann zu dem führen, was hier Geschäftsprozess genannt wird.

Historische Seite

Workflow-Management war lange Zeit und ist auch heute noch im Ansatz dokumentenzentriert. Erfasst werden daher die differenzierten Befugnisse von Einzelnen oder Gruppen bzgl. der Bearbeitung der Dokumente auf dem Laufweg entlang des Kontrollflusses (lesen, ändern, löschen, usw.).

Dokumentenzentriert

Die Abwicklung der Workflows erfolgt mit Hilfe eines Workflow-Management-Systems (WfMS). Dies geschieht weitgehend automatisiert, die beteiligten Menschen realisieren (noch) nicht automatisierbare Vorgänge (z.B. kreativer Natur), treffen nicht automatisierbare Entscheidungen und greifen bei Sonderfällen ein.

Workflow-Management-System

Grundidee

Die zugrundeliegende Idee ist also, einen Geschäftsprozess in kleine Abschnitte zu zerlegen und diese einer Software zur Ausführung zu überlassen. Die eher kleinen Abschnitte (also nicht ganze Prozesse) können automatisch oder teilweise automatisch umgesetzt sein. "Automatisch" bedeutet auch hier vollkommen durch Software realisiert, "teilweise automatisch" bedeutet, dass die Software einen menschlichen Partner mit einplant (z.B. für Entscheidungen). Diese Abschnitte wirken dann zusammen und arbeiten (mit oder ohne menschliche Unterstützung) den Geschäftsprozess ab. Da es ohne Kontrollfluss, Nachrichtenfluss usw. nicht geht, muss das Workflow-Management-System diesen realisieren. Es werden also entlang des vorgegebenen Kontrollflusses die einzelnen Prozessabschnitte angestoßen, Nachrichtenflüsse initiiert, usw.

Etwas konkreter kann die Aufgabe eines Workflow-Management-Systems so beschrieben werden: Arbeitsaufträge werden, einschließlich benötigter Informationen und Dokumente, dem zuständigen Mitarbeiter elektronisch übermittelt. Die einzelnen Schritte werden überwacht und protokolliert. Nutzer werden über neue Aufgaben informiert, bei Nichtbearbeitung erfolgen Warnhinweise. Teilprozesse ohne gegenseitige Abhängigkeit werden parallelisiert.

Etwas konkreter

Zuerst Geschäftsprozess-, dann Workflowmodellierung

Die Modellierung der Workflows baut auf der Prozessmodellierung auf. Ist diese kompetent durchgeführt (mit allen Informationsweitergaben, Geschäftsobjekten, usw.), ist die Abbildung in den Workflow nicht aufwendig. Hinzu kommt immer die Hinterlegung der Kontroll- und Nachrichtenflüsse im Workflowsystem.

Je nach Detaillierungsgrad der Prozessmodellierung werden die Aktivitäten des Prozessmodells so verfeinert, dass das Workflowsystem damit umgehen kann. Wurde die hier vorgestellte Standardprozessmodellierungdurchgeführt, bei der ja die Geschäftsobjekte vollumfänglich erkennbar sind, sollte nicht allzuviel Verfeinerung nötig sein. Der Detaillierungsgrad soll einerseits die automatische Ausführung durch das Workflowsystem und andererseits eine simulationsbasierte Analyse von Workflows gestatten [Gadatsch 2015, Pos. 257].

17.4.2 Softwareseitige Realisierung

Ein Workflow-Management-System beruht also auf einer IT-Lösung mit dem Workflow-Management-System und einer Hardwarebasis. Letzteres ist meist eine Client-Server-Architektur.

Diese Softwaresysteme wickeln Prozesse ab, indem sie die Ausführungsreihenfolge der Aktivitäten (des Kontrollflusses) eines Prozesses überwachen, Daten für die Ausführung einzelner Aktivitäten bereitstellen, anstehende Aktivitäten menschlichen oder technischen Bearbeitern zur Ausführung zuordnen und Anwendungssysteme für die Bearbeitung der Aktivitäten zur Verfügung stellen. Das Workflow-Management-System stößt dann die entsprechenden Bausteien an.

Ein weiteres wichtiges Architekturmerkmal für WfMS ist, dass sie zur Ausführung von Workflows diverse andere IT-Systeme aus den abgedeckten Bereichen einsetzen. Es gibt also neben der Software, die den Ablauf realisiert, verschiedene IT-Systeme, die zur Erledigung einzelner Aufgaben eingesetzt werden. Von Textverarbeitung bis zu prozessorientierter Software.

Die zentrale Komponente, die mit der Realisierung der Workflows beauftragt ist, wird Process Engine oder auch Workflow Engine genannt.

Process Engine

Bei dieser Architektur ist es leicht möglich, den Ablauf der Workflows automatisiert zu überwachen, z.B. zum Zwecke des Process Mining (vgl. Abschnitt 19.3). Stimmen dann die erreichten Ergebnisse nicht mit den Erwartungen überein, werden die Workflows verändert, bzw. die Workflowabwicklung angepasst. Dies ist i.d.R. leichter möglich, als in einer konventionell programmierten Software (vgl. Abschnitt 21.1) und da liegt der Charme dieser Lösung. Alle diese Ansätze, die Gesamtaufgabe (den Gesamtprozess) zu zerlegen und durch das Zusammenwirken zu realisieren, beruhen auf dem Versuch, die Komplexität des gesamten Prozesses (der gesamten Software) zu reduzieren, bzw. erst beherrschbar zu machen. Dies ist eine in der Informatik seit langem vertraute Strategie, ohne die moderne Softwaresysteme nicht möglich wären. Hier also in Form von Workflows. Vergleiche zu diesem Problem der Komplexitätsbewältigung Kapitel 22.

Überwachung

17.4.3 Automatisierungsstufen

Oben wurde schon ausgeführt, dass die Workflows eines Geschäftsprozesses in der Regel nicht vollständig automatisiert realisiert werden, so dass Automatisierungsstufen unterschieden werden können. Gadatsch beschreibt folgende Einteilung:

• Stufe 0 – Manuelle Ausführung. Dabei werden die Geschäftsprozesse ohne IT-Unterstützung durchgeführt. Als Beispiel nennt er die Ermittlung des zuständigen Sachbearbeiters zu einer Kundenanfrage.
• Stufe 1, Ad Hoc - Workflow. Geschäftsprozesse werden mit optionaler IT-Unterstützung ausgeführt. Z.B. bei einer Angebotsprüfung: Bearbeiter können freiwillige vorgeschlagene Tools verwenden.
• Stufe 2, Fallbezogener Workflow. Die meisten Geschäftsprozesse werden computergestützt ausgeführt. Die Arbeitsabläufe sind weitgehend strukturiert, Teilaufgaben sind noch unstrukturiert. Das Anwendungssystem wählt eine geeignete Applikation aus und startet sie. Der Arbeitsablauf wird jedoch noch von individuellen Entscheidungen beeinflusst. Beispiel Antwortbrief: Ein Nutzer wird durch ein IT-System aufgefordert, einen Antwortbrief zu verfassen. Das Anwendungssystem startet selbstständig ein Textverarbeitungsprogramm.
• Stufe 3, Allgemeiner Workflow. Alle Geschäftsprozesse werden computerunterstützt ausgeführt. Das IT-System wählt eine geeignete Applikation aus, startet sie und fügt vorhandene Daten ein. Die Arbeitsabläufe sind stark strukturiert, weisen Wiederholcharakter auf und sind vollständig spezifiziert. Beispiel Anlegen Kundenauftrag: Das Anwendungssystem startet die Transaktionen und füllt relevante Daten (Auftragsnummer, Kundennummer) selbstständig aus.
• Stufe 4, Applikationsautomatisierung. Hier ist an einen vollständig automatisierten Ablauf der Geschäftsprozesse gedacht. Beispiel: Nach Lieferscheinerstellung wird durch das Anwendungssystem automatisch eine Rechnung erstellt.

Vgl. [Gadatsch 2012, Pos. 4359].

<<Klären Sie anhand von [Gadatsch 2012], welche Arbeitsabläufe in den einzelnen Stufen wohl typischerweise vorliegen.>>

17.4.4 Workflow-Management Coalition

Seit 1993 befasst sich die Workflow-Management Coalition (WfMC), eine Vereinigung von Forschungsinstituten, Hochschulen, Anwendern und Softwareherstellern, mit Standards im Bereich des Workflow-Managements. Sie versteht den Workflow als einen ganz oder teilweise automatisierten Geschäftsprozess, in dem Dokumente, Informationen oder Aufgaben von einem Teilnehmer an einen anderen zur Ausführung entsprechend einer Menge von prozeduralen Regeln übergeben werden. Workflow-Management-Systeme sind somit auch hier "Softwaresysteme, deren Kernaufgabe die Unterstützung betrieblicher Prozessabläufe durch die Koordination von Aktivitäten, Anwendungen, Daten und prozessbeteiligten Personen ist" [zur Mühlen und Hansmann 2012, S. 367].

17.4.5 Beispiele

<<mehr dazu im Seminar/in der Vorlesung>>

17.5 Serviceorientierte Architekturen

Vorbemerkung: Serviceorientierte Architekturen werden derzeit im Kontext der Geschäftsprozesse nicht diskutiert. Sie sind aber weiterhin von Bedeutung für die IT-gestützte Realisierung von Geschäftsprozessen.

Die Idee hinter dem Konzept der serviceorientierten Architekturen lässt sich kurz so beschreiben: Im Internet werden Softwarelösungen für einzelne (von vielen benötigte) Aufgaben abgelegt („Services“), die von der Unternehmens-IT genutzt und in ihre vorhandenen IT-Lösungen eingefügt werden können. Dabei muss man zweierlei unterscheiden: Einige Unternehmen nehmen dieses Konzept im Wesentlichen einfach als eine neue Architektur für ihre Anwendungssoftware, die in einzelne Services zerlegt wird, die miteinander über klar definierte Schnittstellen kommunizieren. Der eigentliche Anspruch ist aber ein anderer: Zusammenstellen der Services von verschiedenen Anbietern aus dem Web, in Ergänzung zur vorhandenen Software.

Idee

Die folgende Abbildung will dies ausdrücken. Dabei gehen wir von Geschäftsprozessen aus. Auf der linken Seite der Abbildung ist angedeutet, dass verschiedene Anwendungssysteme (AS1, AS2, AS3) und Services (ServA, ServB) koordiniert werden und zusammen die Geschäftsprozessabschnitte unterstützen. Auf der rechten Seite ist angedeutet, dass eine ERP-Software vorliegt, bei der einzelne Aufgaben durch WebServices unterstützt werden.

Anmerkung: AS steht für Anwendungssysteme, Serv für einen Service, Web für die Herkunftsangabe.

Ein WebService ist eine unabhängige, in sich geschlossene Anwendung, die eine genau definierte Aufgabe erfüllt. Er kapselt Daten und Anwendungslogik und tauscht Nachrichten über eine standardisierbare Schnittstelle aus und steht im Web zur Nutzung zur Verfügung.

Grundlagen

Einige Beispiele:

• Transportplanung für ein Lieferfahrzeug unter Berücksichtigung der aktuellen Verkehrslage im Rahmen der Versandlogistik [Mertens 2013, S. 16].
• Umwandlung eines Textdokuments in ein PDF-Dokument (FPDF)
• Durchführung von Prognoserechnungen

Eine beliebte Programmiersprache zur Erstellung von WebServices ist PHP.

Wie kommt es nun zum Einsatz dieser WebServices. Stellen wir uns ein Zusammenspiel zwischen Dienstnachfrager, Dienstanbieter und einem Verzeichnisdienst vor. Jetzt allerdings im Web und nicht im Intranet. Diese müssen zusammenfinden, sie müssen, um es mit Mertens zu sagen, verteilte Softwaresysteme aus lose gekoppelten Funktionsbausteinen mit klar umrissenen Aufgaben bilden [Mertens 2013, S. 16]. Dabei haben die drei Parteien folgende Aufgaben:

Serviceorientierte Architekturen.

• Der Anbieter von Diensten (service provider) erstellt den WebService und stellt eine Funktionsbeschreibung bereit, die mit einer Web-Service-Description-Language (WSDL) erstellt wurde. Diese ist in einem öffentlich zugänglichen Universal-Description-Discovery-and-Integration (UDDI)-Verzeichnis hinterlegt.
• Der Nachfrager nach Diensten (service consumer) startet für seinen Bedarf Suchanfragen, um einen relevanten Dienst aufzuspüren.
• Der Verzeichnisdienst verwaltet das UDDI-Verzeichnis.

Vgl. auch die folgende Abbildung. Die bei all dem notwendige Kommunikation erfolgt über offene Protokolle und standardisierte Formate (in der Regel XML).

Grundlage des ganzen Geschehens ist, dass Diensteanbieter ihre Services veröffentlichen, z.B. ein neues Programm zur Absatzprognoserechnung. Hat nun ein Nachfrager einen entsprechenden Bedarf, wird das Verzeichnis abgefragt und gegebenenfalls die Beschreibung des Dienstes zurückgeliefert. Entsprechen die Spezifikationen den Wünschen des Nachfragers nutzt er den WebService des Diensteanbieters. Und dies u.U. regelmäßig.

Ablauf

Ganz konkret: Ein Nutzer (normalerweise ein Programm) sucht eine Anwendung, die in der Datenbank einer Fluggesellschaft eine Buchung vornimmt. Er stellt eine Suchanfrage an einen Verzeichnisdienst. Dort finden sich Beschreibungen verschiedener einschlägiger WebServices. Nachdem ein Anbieter für die Anwendung gefunden wurde, können Nutzer und Anbieter eine Verbindung aufbauen und über das Internet miteinander kommunizieren. So können sie die gemeinsame Aufgabe erfüllen (das Nutzungsprogramm steuert die Angaben zum Passagier und zum Flugziel bei, der Web-Service übernimmt die Buchung). Dienstsuche, Verbindungsaufbau und Kommunikation erfolgen automatisiert auf der Basis von XML-Nachrichten.

Beispiel

In der Literatur ist manchmal auch von völlig automatisierten Lösungen die Rede: Die Software des Unternehmens (in ihrer Architektur dann auch serviceorientiert) sucht selbständig den am besten geeigneten WebService mit (zum Beispiel) Absatzprognoserechnung oder den am besten zum Wandeln von Text in PDF-Dokumente geeigneten (um bei den oben angeführten Beispielen zu bleiben). Dies konnte der Verfasser bis heute in der Praxis allerdings noch nicht antreffen.

Wird ein solches Anwendungssystem realisiert spricht man einer Serviceorientierten Architektur (SOA). Diese ist somit eine Form einer verteilten Informationsarchitektur, deren Fokus auf der Ankündigung, dem Auffinden und dem dynamischen Aufrufen von anwendungsnahen und in sich abgeschlossenen Diensten liegt.

Der Grundgedanke ist bestechend. Im Web werden eine Vielzahl von Services bereitgestellt, die jeweils eine wichtige Aufgabe in Geschäftsprozessen zu lösen bereit sind. Es gibt sogar konkurrierende, so dass wir wählen können. Wir stellen für unseren Geschäftsprozess relativ problemlos die Services zusammen, tauschen sie auch mal aus, wenn wir – oder das System selbst – bessere entdecken, und haben somit immer einen „bestausgestatteten“ Geschäftsprozess. Dies alles in Zusammenarbeit von IT-Management (IT-technisch) und Geschäftsprozessmanagement (fachlich).

Nutzen

Bei den auszulagernden Abschnitten geht es nicht so sehr um Funktionen bzw. Aktionen von Geschäftsprozessen. Beim heutigen Stand der Technik geht es eher um kleine abgeschlossene Aufgaben, die bei einer Prozessmodellierung vielleicht in eine Funktion gekapselt werden und die zu den vor- und nachgelagerten Prozessabschnitten klar definierte Schnittstellen haben. Das sollten auch die oben angeführten Beispiele verdeutlichen.

Stand der Technik

Die Idee der Auslagerung von Services ins Web und die Vorstellung, den Geschäftsprozess mit vielen solchen Webkomponenten auszustatten, ist völlig konträr zu dem Integrationsgedanken, wie er ansonsten heute gepflegt wird (integrierte Datenbank, integrierte prozessorientierte Software). Wer sich angesichts der Vorstellung einer serviceorientierten Architektur an heterogene Systemwelten erinnert fühlt, hat nicht unrecht. Allerdings wird diese heutige heterogene Lösung auf einer anderen technologischen Basis realisiert als früher.

Integration

Beherrschbar wird diese Technologie, wenn es um klar abgegrenzte Aufgaben mit exakt definierten Schnittstellen zu den vor- und nachgelagerten Prozessabschnitten geht und wenn das Problem der Datenhaltung geklärt ist. Der einfachste Fall liegt vor, wenn dem WebService replizierte Daten übergeben werden (z.B. die monatlichen Absatzzahlen der letzten fünf Jahre) und wenn er fest definierte zurückliefert, die dann in die unternehmensweite integrierte Datenbank eingefügt werden (die Prognosen des Folgejahres).

Stellt man sich eine ganze Anwendungssoftware serviceorientiert vor, ist das Problem des Kontrollflusses zu lösen. Denn die Services allein lösen nur ihre Aufgabe, tragen zum Kontrollfluss aber nichts bei. In konkreten Architekturen wird dabei eine Komponente vorgeschlagen, die dies dann leistet. Der verwendete Begriff dafür ist Orchestrierung, da diese Komponente die Services sozusagen zum korrekten Miteinander bringt.

Durch Orchestrierung zum Kontrollfluss.

Betrachten wir als Beispiel die Lösung von SAP, NetWeaver . Es ist eine Lösung, die in einer serviceorientierten Architektur die benötigte Funktionalität selbst enthält, die aber erlaubt, WebServices sowie auch die Leistungen anderer IT-Systeme zu nutzen.

Stand 2016 war dieses Konzept Grundlage der allgemeinen ERP-Lösung von SAP:

Stand 2016

"SAP ERP is based on the architecture of SAP NetWeaver. This Integration allows customers unparalleled access to the capabilities of the SAP NetWeaver platform (SAP ERP 2004 on SAP NetWeaver'04 and SAP ERP 6.0 on SAP NetWeaver 7.0)." (http://scn.sap.com/community/netweaver-technical-integration-with-erp, Abruf am 29.4.2016)

NetWeaver ist der Kern der sog. Enterprise Services Oriented Architecture (ESOA), dem Grundlagenkonzept der SAP für WebService-Lösungen. Sie integriert alle Systeme, die wichtig für den jeweiligen Geschäftsprozess sind, unabhängig davon, ob es sich um interne oder externe, um SAP- oder um Nicht-SAP-Systeme handelt. Die ESOA ermöglicht das Design der kompletten Lösung für einen Geschäftsprozess, wobei existierende IT-Systeme und Anwendungen einbezogen werden. Zentrale Komponente ist dabei das Composite Application Framework, das Werkzeuge, Methoden, Regeln und Bausteine enthält, die es SAP, deren Partnern und Anwendern ermöglicht, komponentenbasierte Anwendungen zu entwickeln.

17.6 Weitere Anwendungssysteme

17.6.1 CRM

Begriff: Customer Relationship Management (CRM)

Kurzbeschreibung: Software für die integrierte Planung, Steuerung und Kontrolle der Kundenbeziehungen; Integration aller kundenbezogenen Prozesse in Marketing, Vertrieb und Service.

<<mehr dazu im Seminar/in der Vorlesung>>

17.6.2 SCM

Begriff: Supply Chain Management (SCM)

Kurzbeschreibung: integrierte Planung, Steuerung und Kontrolle der innerbetrieblichen und zwischenbetrieblichen Lieferkette; Integration von Beschaffung, Herstellung und Lieferung von Produkten, Systemen, Anlagen und Dienstleistungen.

<<mehr dazu im Seminar/in der Vorlesung>>

17.6.3 PLM

Begriff: Product Lifecycle Management (PLM)

Kurzbeschreibung: Integrierte Planung. Steuerung und Kontrolle von Produkten über ihren gesamten Lebenszyklus; Integration von Produktplanung, Produktentwicklung, Produktfertigung, Produktservice bis zur Produktausphasung.

<<mehr dazu im Seminar/in der Vorlesung>>

17.6.4 EAI-Plattformen

In der konkreten Praxis heutiger IT-Lösungen ist es so, dass unterschiedliche Softwareprodukte zum Einsatz kommen. Z.B. neben einer ERP-Software noch weitere spezialisierte Softwaresysteme. Dies können die oben erwähnten oder andere sein, die ergänzend hinzugefügt werden. Grundsätzlich ist es in der Regel immer so, dass abhängig von der Branche und ihrer spezifischen Geschäftstätigkeit, das Leistungssprektrum der ERP-Software ergänzt werden muss.

Dies ist – vor allem bei Kernprozessen – auch Individualsoftware. Z.B. für die Produktion (bei Industrieunternehmen) oder für die Kundenkontakte (bei Internet-Unternehmen).

Individualsoftware

Seit einigen Jahren erfolgen Ergänzungen auch mit dem Ziel der Prozessoptimierung durch Softwareroboter (Bots). Auch diese müssen mit der übrigen Software in Kontakt auftreten. Vgl. dazu Abschnitt 19.2.

Softwareroboter

Eine sehr große Vielfalt an Softwarelösungen also, die im Zusammenspiel helfen, die Geschäftsprozesse der Organisation IT-gestützt zu realisieren.

Für das damit notwendige Zusammenspiel wurden sog. Enterprise Application Integration - Systeme (EAI-Systeme) entwickelt. Mit ihnen ist es möglich, unterschiedliche Softwaresysteme über klar definierte Schnittstellen zu verknüpfen. Dazu stellt ein EAI-Portal eine Benutzeroberfläche bereit, über die auf die einzelnen Anwendungen zugegriffen werden kann. Wichtigste Aufgabe dabei ist, die Datenweitergabe zwischen den Softwaresystemen zu realisieren. Dazu gehört die Anpassung der verschiedenen Datenformate und die konkrete Weiterleitung. Hierfür findet sehr oft XML Verwendung.

Enterprise Application Integration - Systeme

<<mehr dazu im Seminar/in der Vorlesung>>

17.6.5 Eigenentwickelte Software

Es wurde mehrfach erwähnt. Individualsoftware ist "nicht tot". In vielen Bereichen der IT-Architekturen werden individuelle Softwarelösungen erstellt (in der Organisation selbst oder durch ein Softwarehaus). Die beeindruckendsten Beispiele finden sich bei den großen im Internet tätigen Unternehmen. Bei diesen Internet-Unternehmen entstand mit hohem personellen Aufwand eine leistungsstarke Software, die auch ständig weiterentwickelt wird und für die methodisch neue Lösungen entwickelt werden mussten. Vgl. dazu Kapitel 20.

Individualsoftware

Aber auch in anderen Organisationen finden sich Beispiele. Hier sind es oft Kerngeschäftsprozesse, für die eine leistungsstarke, die eigenen Erfolgsfaktoren sicherende Softwarelösung programmiert wird. Bei Industrieunternehmen sind dies oftmals Programme für die Produktion.

Für das Geschäftsprozessmanagement bedeutet dies folgendes:

• Evtl. Nichtzuständigkeit, falls das Projekt ganz und gar im technischen Bereich angesiedelt ist, z.B. in der Produktion. Ein klein wenig Zuständigkeit entsteht aber meist doch, da solche Softwarelösungen heute und schon lange mit der übrigen IT integriert sein müssen. Dies haben schon Mertens und Scheer vor Jahrzehnten thematisiert.
• Falls die zu unterstützenden Geschäftsprozesse in die Zustsändigkeit des "ganz normalen" Geschäftsprozessmanagements fallen, bedeutet Individualsoftware, dass erstmal geklärt werden muss, ob überhaupt eine (in der Regel teurere) Individualoftware erstellt werden soll oder ob auf eine Standardasoftware zurückgegriffen wird. Hier sollte neben der Geschäftsleitung und der Fachabteilung auch das Geschäftsprozessmanagement mitwirken.
• Kommt es dann zur Individualsoftware muss das Geschäftsprozessmanagement bei der Anforderungsentwicklung mitwirken: Festlegung der Plattform (Cloud?), der fachlichen Anforderungen (zusammen mit der Fachabteilung), usw.

17.6.6 Electronic Business

Die globale Vernetzung über das Internet hat zu einer tiefgreifenden Veränderung der Märkte und der Geschäftstätigkeiten über dieses Medium geführt. Die Marktveränderungen sind durch folgende Punkte gekennzeichnet:

• veränderte Kundenerwartungen
• Kontakt mit potenziellen Kunden auf der ganzen Welt
• verstärktes Angebot von Leistungen in elektronischer Form, insbesondere Aufbau von neuen Dienstleistungen wie Suchdienste, Agenten usw.
• dramatische Senkung der Eintrittsschwelle für neue Wettbewerber
• Entstehung neuer Geschäftsmodelle
• Erweiterung der Geschäftsprozesse über Unternehmensgrenzen hinweg
• neue Organisationsformen durch veränderte Wertschöpfungsketten

Anmerkung

Agenten sind Softwaremodule, die autonom, insbesondere in vernetzten Systemen, Aufgaben im Auftrag eines Nutzers zielgerichtet lösen (auch: Software-Roboter oder Soft-Bots).

Electronic Business (E-Business) hat somit eine große Bedeutung für Unternehmen gewonnen. Es wurde dadurch auch zu einem wichtigen Einflussfaktor für die Gestaltung der IT. Kein Unternehmen wird heute bei der Planung seiner IT-gestützten Geschäftsprozesse darauf verzichten können, die Anforderungen des E-Business zu berücksichtigen.

Mit dem E-Business hat sich die informationelle Umwelt von Organisationen grundsätzlich geändert. Während es noch vor einigen Jahrzehnten im Wesentlichen um überschaubare Kontakte zu Lieferanten, Kunden und staatlichen Verwaltungen ging, sind die Organisationen heute in die globalen Netzwerke, v.a. die des Internets, eingebettet, wovon die IT jeweils unmittelbar betroffen ist. Denn diese muss entweder die zusätzlichen Aufgaben mit übernehmen oder mit anderen Systemen kommunizieren.

Informationelle Umwelt

Für die elektronische Unterstützung von unternehmensübergreifenden geschäftlichen Aktivitäten gibt es zahlreiche Begriffe. Die beiden wichtigsten sind:

E-Business und E-Commerce

• Electronic Business (kurz: E-Business) meint alle Geschäftsprozesse innerhalb und außerhalb von Organisationen, die mit elektronischen Medien über globale öffentliche und private Netze durchgeführt werden.
• Electronic Commerce (kurz: E-Commerce) meint die kommerziellen Aktivitäten, die sich zwischen Marktteilnehmern/Handelspartnern abspielen. Er ist derjenige Teil des E-Business, der auf die Vereinbarung und Abwicklung rechtsverbindlicher Geschäftstransaktionen ausgerichtet ist.

Vereinfacht kann man sagen, dass E-Business die elektronische Geschäftsabwicklung und E-Commerce den elektronischen Handel umfasst. E-Commerce ist damit ein Teil vom E-Business.

Die Aktivitäten im E-Business sind sehr zahlreich, neben dem E-Commerce sind auch die elektronische Beschaffung (E-Procurement), z.B. über Online-Kataloge, Portale, Online-Auktionen, der elektronische Zahlungsverkehr (E-Banking) sowie der Online-Vertrieb (z.B. über Online-Shops) und das Online-Marketing besonders zu erwähnen. Letztlich läuft die elektronische Unterstützung all dieser Aktivitäten auf eine unternehmensübergreifende Integration von Geschäftsprozessen und damit von IT-Systemen hinaus. Nur so können moderne Produktions- und Logistikkonzepte auf der einen Seite, sowie ein konsequent kundenorientiertes Informationsmanagement auf der anderen Seite, sinnvoll verwirklicht werden.

Für das Geschäftsprozessmanagement stellen sich in diesem Zusammenhang v.a. zwei Fragen;

• Ausmaß der Nutzung "des E-Business" für die eigene Geschäftstätigkeit
• Form der Realisierung: Cloud-Lösung, "eigene Lösung", usw.

17.7 Cloud Computing

Zuerst von nicht wenigen belächelt, inzwischen Realität. Die moderne Form des Outsourcing hat sich ihren Platz erkämpft. Sie reicht von der Einbeziehung einzelner Funktionalitäten („Prognoserechnung“) oder ausgewählter Geschäftsprozesse (Mailing-Aktion, Finanzwesen) bis zur Nutzung vollständiger ERP-Software „aus der Wolke“. Man kann dort ganze Plattformen, einzelne Server oder bestimmte Programme buchen und nutzen.

Cloud Computing meint die Nutzung großer Servicerechenzentren, die mit starken Leitungen „irgendwo“ im Internet“ platziert sind und über das Internet nutzbar sind. Für immer mehr Unternehmen stellt sich die Frage, ob und welche IT-Leistung von diesen Rechenzentren bezogen werden sollte. Denn das Angebot ist verführerisch:

Um was geht's?

• Die in Anspruch genommene Leistung ist leicht skalierbar.
• Kein Betrieb eigener Hardware ist notwendig, keine eigenen diesbezüglichen Aufwendungen.
• Durch die Möglichkeit der Virtualisierung in den Servicerechenzentren der Cloud u.U. eine Lösung, die dem Kunden wie eine individuelle anmutet (eigener Entwicklungsserver, eigene ERP-Software)

Voraussetzung ist natürlich ein leistungsstarkes Servicerechenzentrum in „der Cloud“ (oder auch mehrere verteilte), das gegen die vielfältigen Risiken dieser Zeit abgesichert ist (was in den letzten Jahren nicht immer der Fall war). Dann entsteht die Win-Win-Situation, die dem Erfolg dieses Outsourcing-Angebots zugrunde liegt: Die Nachfrager nach IT-Leistung sparen den Aufwand für eine IT, die oftmals nicht ausgelastet ist, der Cloud-Anbieter kann durch die Vielzahl seiner Kunden und durch die Virtualisierbarkeit eine hohe Auslastung erreichen.

Natürlich können hier keine maßgeschneiderten Lösungen für Kernprozesse erwartet werden. Es ist aber nicht risikoreich, zu prognostizieren, dass in der Zukunft immer mehr Software für die Supportprozesse in „die Cloud“ verlagert werden wird.

Supportprozesse

IT-gestützte Geschäftsprozesse können also – grob gesagt - auf der organisationseigenen Hardware, in einem externen Rechenzenrum "in der Nähe" oder "in der Cloud" realisiert werden. Dabei haben die Cloud-Lösungen in den letzten Jahren ständig an Bedeutung gewonnen. Sie sind also auch ein Thema für ein zeitgemäßes Geschäftsprozessmanagement.

Plattformen

Die Cloud-Rechenzentren sind inzwischen so umfangreich und leistungsstark, dass von Serverfarmen gesprochen wird. Angemerkt werden muss, dass diese Geschäftsidee nur funktionieren konnte, weil die Übertragungsleistung des Internet in den letzten Jahrzehnten ständig ausgebaut wurde und inzwischen sehr groß ist, denn die Kunden verlangen sehr kurze Antwortzeiten.

Serverfarmen

Die so angebotene Rechnerleistung ist typischerweise skalierbar, d.h. man kann auf einfache Weise mehr oder weniger Leistung „buchen“. Wenn also z.B. für eine Marketingaktion vorüberhend mehr Rechenkapaziät benötigt wird, kann dies auf einfache Weise hinzugebucht werden. kann problemlos an eine vorübergehende Lastspitze (intensives Testen der neuen Software, Erstellung des wöchentlichen „Builds“, …) angepasst werden.

Skalierbarkeit

Dieses Angebot wird Cloud Computing genannt [Hansen und Neumann (Hrsg.) 2009, S. 268] . Dabei steht der Begriff cloud als Metapher für das Internet. Er drückt auch aus, dass der Nutzer des Dienstes nicht unbedingt weiß, wo der Server steht, von dem er die Leistung bezieht. Will man dies nicht, muss man einen Cloud-Anbieter wählen, der explizit mitteilt, wo seine Serverfarmen stehen. Auch dies wird, gerade in Deutschland, inzwischen angeboten.

Begriff

Cloud Computing ist eine moderne Form des Outsourcing, d.h. des Auslagerns von IT-Leistung zu einem anderen Unternehmen (so wie der Steuerberater u.U. seine Buchungen von der DATEV machen lässt).

Zu dieser Entwicklung kam es, als große Internet-Unternehmen im B2C bemerkten, dass ihre riesigen Rechenzentren (hier auch Serverfarmen genannt), die für das Weihnachtsgeschäft unbedingt benötigt wurden, im Rest des Jahres ziemlich wenig ausgelastet waren. Da diese Serverfarmen ja auch auf hervorragende Weise mit dem Internet verbunden sind, kam man auf die Idee, diese Rechnerkapazitäten außerhalb der Weihnachtszeit anderen Unternehmen anzubieten. Der Kunde weiß dabei nicht, in welchem der Rechenzentren seine IT-Leistungen realisiert werden. Er bezieht sie einfach aus „der Wolke“.

Ursprung

Vorreiter war hier Amazon. Inzwischen haben zahlreiche andere Unternehmen, z.B. Microsoft und IBM nachgezogen und ebenfalls solche Serverfarmen aufgebaut, auch mit anderen Rahmenbedingungen (z.B. mit regionalen Festlegungen).

Beispiel VW Industrial Cloud (Quelle: [Bayer 2019b, S. 8f])

Wie sehr das Cloud Computing in die Realität der heutigen IT auch globaler Unternehmen vorgedrungen ist, zeigt ein Beispiel von Volkswagen. Im April 2019 konnte man lesen, dass VW mit Amazon Web Services (AWS) eine Kooperation vereinbart hat. Dabei geht es um eine "Industrial Cloud" über sämtliche Fabriken des Konzerns hinweg. In ihr sollen "die Daten aller Maschinen, Anlagen und Systeme aus sämtlichen 122 Fabriken des Konzerns zusammenlaufen" [ebenda]. Motivator ist das Ziel, dass die Anlagen bis 2025 "um ein Drittel produktiver arbeiten sollen als heute".

"Dabei soll die "IT auf der Fertigungsebene von Maschinen, Anlagen und Systemen - etwa für die Produktionsplanung und Lagerhaltung - … über alle 122 Fertigungsstatten des Konzerns hinweg einheitlich gestaltet und verknüpft werden."

Die Zusammenarbeit geht aber noch weiter: "Konkret ist geplant, in den Bereichen Internet of Things (IoT), Machine Learning und Computing Services auf Amazon-Technologien aufzusetzen, die speziell für das Produktionsumfeld entwickelt und für die Anforderungen der Automobilindustrie erweitert werden sollen. Als Architekturbasis dient die neue Digital Production Platform (DPP) der Niedersachsen, an die künftig alle Standorte im Konzern wie auch weitere Unternehmen andocken sollen. Diese Plattform soll den system- und werksübergreifenden Datenaustausch vereinheitlichen und vereinfachen. Dazu zählten eine effizientere Steuerung des Materialflusses, die frühzeitige Erkennung und Korrektur von Lieferengpässen und Prozessstorungen sowie eine optimierte Fahrweise von Maschinen und Anlagen in jeder Fabrik. Darüber hinaus erhofft man sich bei VW, neue Technologien und Innovationen schneller und standortübergreifend bereitstellen zu können.

"Mit Hilfe intelligenter Robotik und Analytics wollen die Wolfsburger werksübergreifend Prozesse analysieren und vergleichen. Zudem ließen sich neue Anwendungen, zum Beispiel in der IT-Sicherheit für Anlagen, über die Cloud-basierte Plattform direkt auf alle weltweiten Standorte skalieren Der Autobauer will an dieser Stelle auch auf Best-Practice-Erfahrungen von AWS setzen.

Die Volkswagen-Verantwortlichen planen sogar noch weiter. Die Industrial Cloud werde als offene Plattform angelegt. Langfristig gehe es auch um die Integration der globalen Lieferkette des Konzerns mit über 30.000 Standorten und mehr als 1500 Zulieferern und Partnerunternehmen."

17.8 InMemory

Auch bei diesem Thema stellt sich die Frage, was es mit Geschäftsprozessmanagement zu tun hat, denn es geht ja in erster Linie um eine neue und in mancherlei Hinsicht effizientere Datenbanktechnologie. Nun, die Antwort ist schnell gegeben. Jeder Geschäftsprozess benötigt Daten und damit Datenbanken. Die Menge der Daten wurde in den letzten Jahrzehnten immer umfangreicher und ihre Verarbeitung mit klassischen Datenbanktechnologien immer mühsamer. Denken wir nur an den Wunsch, operative und strategische Daten integriert zu verwalten. Dieser Leidensdruck führte zur Entwicklung von InMemory-Datenbanksystemen.

Hintergrund

Ausgangspunkt für die Entwicklung dieser Datenbanktechnologie waren die großen Datenmengen aus dem Customer Relationship Management (CRM) und anderswoher, deren Speicherung, Verwaltung und Auswertung mit den in den Unternehmen vorliegenden (i.w. relationalen) Datenbanken und der klassischen Hardwarearchitektur nur mit Mühe zu bewältigen ist. Da die heute für Computer dominante von Neumann – Architektur die strikte Trennung der Arbeitsspeicher und der peripheren Speicher vorsieht, stellt sich der Datenverkehr zwischen diesen als Engpass heraus, trotz Cache und anderer Techniken zur Zugriffsbeschleunigung. Deshalb kam schon früh die Idee auf, die Datenbank in den Arbeitsspeicher zu laden und die Verarbeitungsschritte dort durchzuführen.

Ausgangspunkt

Der Unterschied zwischen herkömmlichen Datenbanksystemen und InMemory-Datenbanksystemen ist also, dass nicht der Festplattenspeicher zum Lesen und Schreiben der Daten verwendet wird, sondern der Arbeitsspeicher, in den die Datenbank geladen wurde. Die Festplatte bekommt dann die Aufgabe der Sicherung und – falls notwendig – der Wiederherstellung. Denn ein Arbeitsspeicher ist ja recht flüchtig. Die Vergrößerung des Arbeitsspeichers erfolgt durch den Einsatz von Bladeservern mit Multi-Core-CPUs und Hauptspeicher in der Größe von Terabyte.

Daten im Arbeitsspeicher

Der wichtigste Vorteil einer solchen Lösung ist die Verkürzung der Zugriffszeiten. Diese sind beim Arbeitsspeicher um einiges kürzer als bei Festplatten (unabhängig davon, ob es sich um eine Magnetplatte oder eine SSD handelt). Dadurch können die Datenbankoperationen und die Auswertungen signifikant schneller erfolgen. Mit einer entsprechenden Lösung ist es möglich, riesige Datenbestände bei gleichzeitig hoher Anzahl von Abfragen und trotz der Nutzung durch sehr viele Nutzer in angenäherter Echtzeit zu verarbeiten und zu analysieren.

Zugriffszeiten

Eine weitere Besonderheit dieser Anwendungssysteme besteht im Aufbau der In-Memory-Datenbank . Entgegen den relationalen Datenbanksystemen, wo die Daten zeilenweise gespeichert werden, verfolgt die In-Memory-Datenbank-Technologie meist eine spaltenorientierte Speicherung der Daten (vgl. [Staud 2015, Abschnitt 24.11]) beziehungsweise eine Kombination aus beiden Techniken.

Andere Datenstruktur

Falls zum Datenmodell auch aggregierte Daten gehören (z.B. bei Data Warehouse - Lösungen) können bei diesen Datenbanken und ihren Systemen diese aus den Basisdaten bei Bedarf berechnet werden. Die Aggregate werden also nicht vorher berechnet und gesondert gespeichert (wie ansonsten in Business Intelligence / Data Warehousing), sondern bei Bedarf (wenn eine entsprechende Datenauswertung ansteht).

Die hohe Zugriffsgeschwindigkeit erlaubt nicht nur obiges, sondern ganz generell Auswertungen in Echtzeit oder, falls die Auswertungen sehr umfangreich sind, wesentlich beschleunigt. Wenn z.B. Millionen von Belegen bei einer Krankenversicherung auszuwerten sind, bedeutet dies Minuten statt Stunden.

Diese Leistungsstärke erlaubt Lösungen, an die vor Einführung dieser Technologie nicht zu denken war, z.B. die Einrichtung einer einzigen Datenbank für operative und analytische Daten. Operative Daten werden typischerweise in einem OLTP-Datenbanksystem verwaltet (vgl. [Staud 2015, Abschnitt 24.1]). Für ein OLAP-System (ebenda) werden dann ausgewählte Daten mittels eines ETL-Prozesses periodisch in ein OLAP-Datenbanksystem geschrieben. Bei InMemory-Technologien ist diese Trennung von OLTP und OLAP teilweise aufgehoben, so dass die Anfragen in Echtzeit realisiert werden können.

Bei sehr großen Datenbeständen ist für InMemory-Datenbanksysteme an Parallelverarbeitung gedacht. Eine solche Parallelrechner - Architektur erlaubt, Datenbankoperationen gleichzeitig auf mehreren Hauptprozessoren auszuführen. Dies erhöht die Leistungsstärke solcher datenverwaltender Systeme nochmals deutlich.

Es gibt inzwischen zahlreiche Anbieter von ERP-Software und Datenbanksystemen, die Produkte mit InMemory-Technologie anbieten, darunter ORACLE und SAP. Das bekannteste ist SanssouciDB von SAP, eine Kombination aus relationalen und spaltenorientierten multidimensionalen Datenbanktechnologien. Vgl. für eine Beschreibung [Plattner und Zeier 2011, S. 41ff].

Beispiele

17.9 Schattenseiten?

Die IT-Unterstützung von Geschäftsprozessen, deren mögliche Strukturen hier skizziert wurden, ist heute unabdingbar. Es ist heute keine Organisation denkbar, die ohne eine solche auskommt. Wenn es hier also um Schattenseiten dieser Entwicklung geht, dann nur in dem Sinn, dass die gewählten Realisierungen Risiken bergen oder noch Verbesserungsbedarf haben.

Diskutieren wir die folgenden Punkte.

Zementierung

Jedes Abbilden von Geschäftsprozessen in Software führt zu einer "Zementierung" des Geschäftsprozesses in dem Sinn, dass für jede auch noch so kleine Änderung des Prozesses eine Änderung der Software nötig wird.

<<Diskussion: Einschätzung, Wirkung, Bewältigung>>

Abhängigkeit

Die Abhängigkeit der Organisationen von ihren Softwarelieferanten war schon immer sehr groß. Dies ist inzwischen noch verschärft. Viele der neuen Lösungen führten zu einer größeren Abhängigkeit vom jeweiligen Anbieter. Z.B. bei Cloud-Lösungen. Der Wechsel eines nennenswerten Teils der IT-Lösung vom einen zum anderen Cloud-Rechenzentrum ist nicht so einfach, wie es viele versprechen.

Oder der Wechsel des ERP-Anbieters. Dieser war schon immer aufwendig. In Zeiten von InMemory-Lösungen ist er noch schwieriger, auch weil dabei auf standardisierte Lösungen verzichtet wird. Es sind ja jetzt nicht mehr relationale Datenbanken, die im Fall des Falles migrieren müssen und deren grundsätzliche Struktur durch Standards und eine Theorie einigermaßen gefestigt ist, sondern Lösungen ohne einen solchen Hintergrund. Dies führt letztendlich zu proprietären Lösungen, die durch spaltenorientierte Dateistrukturen bzw. Speichertechniken nicht weniger proprietär werden.

<<Diskussion: Einschätzung, Wirkung, Bewältigung>>

Rückkehr der Insellösungen

Es gab eine Zeit, da wurde die Überwindung von Insellösungen als großer Fortschritt gefeiert. Das war die Phase der Einführung von ERP-Software. Inzwischen wird doch recht "ungebremst" wieder zu Insellösungen gegriffen. D.h. Programme für die Prozssabwicklung werden zusammengefügt, Schnittstellen müssen definiert und gepflegt werden.

Dies geschieht im Übrigen noch "ungebremster" im Rahmen der Automatisierung von Geschäftsprozessen, vgl. die nächsten zwei Kapitel.

<<Diskussion: Einschätzung, Wirkung, Bewältigung>>

Eigene Kompetenz

Aktuelle Lösungen für die IT-Unterstützung der Geschäftstätigkeit basieren oftmals auf Cloud-Lösungen. Dies kann zu einem Abbau von IT-Kompetenz in der eigneen Organisaion führen.

<<Diskussion: Einschätzung, Wirkung, Bewältigung. Z.B.: Soll man in der eigenen Organisation IT-Kompetenz vorhalten? Soll man verzichten. Was ergeben sich für Konsequenen aus dem einen oder anderen.>>