Serviceorientierte Entscheidungsunter-

stützungssysteme mit Agent -Support

Ben Bergen

AKADS.DE

 

Serviceorientierte  Entscheidungsunterstützungssysteme    

mit  Agent-­Support    

Ben  Bergen    

 

 

Eine  Publikation  von  AKADS.DE  

Kurzfassung 2

Kurzfassung  Seit den 1980er-Jahren kommen in Unternehmen sogenannte Entscheidungsunter-stützungssysteme (EUS) bzw. Decision Support Systems (DSS) zum Einsatz. Da die Abläufe in Unternehmen immer komplexer wurden, wuchs der Wunsch nach Lösungen, die Fach- und Führungskräfte in ihrem Planungs- und Entscheidungs-prozess unterstützen – idealerweise mit Modellen, praktischen Methoden und prob-lembezogenen Daten. Man bezeichnet diese Systeme in der Literatur auch häufig abgekürzt als Planungssysteme.

Entscheidungsunterstützungssysteme sind in der Regel in komplexe Umgebungen eingebettet und somit oft ein Bestandteil eines Managementunterstützungssystems (MUS). Kennzeichnend für EUS ist die „ausgeprägte Modell- und Methodenorien-tierung, durch die eine situationsspezifische Unterstützung des Managers gewähr-leistet wird”1. EUS sind auf strukturierte und semistrukturierte betriebliche Prob-leme im operativen Management spezialisiert. Doch die Anforderungen haben sich in der Vergangenheit drastisch verändert. EUS dienen heute dazu, die Entschei-dungsvorbereitung auf den Führungsebenen zu unterstützen. Dazu werden die ent-scheidungsrelevanten Informationen verdichtet2 und für die Entscheider in einer ge-eigneten Form aufbereitet.

Typische Anwendungsbereiche sind heute die Aufbereitungen von schlecht zu strukturierenden Problemen eines betrieblichen Funktionskreises, man denke bei-spielsweise an die Planung von Werbebudgets oder die Cashflow-Planung. Da die Zielgruppe keine Techniker, sondern überwiegend Manager und Entscheider sind, sind die Werkzeuge entsprechend leicht handhabbar und erlauben die einfache Durchführung von Alternativrechnungen und Simulationen. Dabei können in der Regel auch verschiedene Modellvarianten und -änderungen berücksichtigt werden. Unternehmen kommt dabei zugute, dass bereits Werkzeuge wie MS Excel einfache Entscheidungsunterstützungsfunktionen bieten.

In den letzten Jahren wurde das Design von Decision Support Systems (DSS) um Web-Funktionalitäten erweitert. Damit folgt man zwar einem Trend hin zu mehr Web-Unterstützung, doch erzielen diese und die automatisierte Verarbeitung von Daten bislang nicht die optimalen Ergebnisse. Aktuelle Systeme weisen eine kon-zeptionelle Schwachstelle auf: Sie berücksichtigen das Zusammenspiel zwischen Entscheidungsträgern und organisatorische Prozessen zu wenig.3

1 Vgl. Gabriel (2016) 2 Vgl. Lackes (2016) 3 Vgl. Dong / Srinivasen (2012)

Kurzfassung 3

Das Design aktueller DSS-Lösungen krankt an einem weiteren Punkt: Ihnen man-gelt es an der Fähigkeit, sich an geänderte Anforderungen und Rahmenbedingungen anzupassen. Dieses Problem verschärft sich, wenn Ressourcen über unterschiedli-che Standorte verteilt sind. In solchen, in der Wirtschaft eher üblichen als unübli-chen Szenarien, müssen die Entscheidungsprozesse integriert und das Zusammen-spiel von Entscheidungsträgern optimiert werden.

Dong und Srinivasan haben die Unzulänglichkeiten bisheriger Designansätze als erstes dokumentiert und haben bisherige Ansätze um die serviceorientierte Sicht auf Organisationen erweitert. Eine solche Erweiterung berücksichtigt auch den Um-stand organisatorischer Dynamik in modernen Unternehmen.

In Unternehmen besteht die Notwendigkeit der kollaborativen Entscheidungsfin-dung.4 Aus dieser Notwendigkeit heraus müssen heutige Entscheidungsunterstüt-zungssysteme zu einer Agenten-fähigen serviceorientierten Architektur erweitert werden.

Im Rahmen dieser Arbeit werden Stärken und Schwächen der klassischen Entschei-dungsunterstützungssysteme analysiert. Darauf aufbauend wird diese Ansätze um Agent- und Serviceunterstützung erweitert. Die Arbeit spiegelt den aktuellen Stand der Wissenschaft wider und gibt einen Ausblick auf mögliche zukünftige Entwick-lungen.

4 Vgl. Dong / Srinivasen (2012)

Inhaltsverzeichnis 4

Inhaltsverzeichnis  

Kurzfassung ..................................................................................................... 2  

Abkürzungsverzeichnis .................................................................................. 4

1   Einleitung ............................................................................................. 5  

2   Grundlagen von Entscheidungsunterstützungssystemen ................ 9  

3   Erweiterung um die Agent-Komponente ........................................ 12  3.1   Agenten-fähige Komponentendienste ................................................. 14  

3.2   Agent-Kommunikation ........................................................................ 14  3.3   Agent-Lebenszyklus ............................................................................ 15  

3.4   Implementierung .................................................................................. 16  

Zusammenfassung und Ausblick ................................................................. 17  

Literaturverzeichnis ..................................................................................... 18  

Abkürzungsverzeichnis  

ASDSS – Agent-enabled Service-oriented Decision Support System

EUS – Entscheidungsunterstützungssystem

FIS – Führungsinformationssystem

DSS – Decision Support System

MIS – Management-Informationssystem

MSS – Management Support System

NLP – Natural Language Processing

OOP – Objekt-Orientierte Programmierung

UIMA – Unstructured Information Management Architecture

XML – Extensible Markup Language

1 Einleitung 5

1   Einleitung  In der Wirtschaft ist in den letzten Jahren ein Trend erkennbar, der die Nutzung von Produkten und Dienstleistungen in den Mittelpunkt stellt: Unternehmen definieren ihre wichtigste Aufgabe als Service und nicht mehr als Produkt. Dieser Trend ist unabhängig von der Unternehmensgröße, der Branche und dem Standort wahr-nehmbar. Die Zustellung dieser Dienste basiert mehr und mehr auf Verbindungen innerhalb von Unternehmen und zwischen diesen. Die Nutzung von sozialen und technischen Verbindungen spielt dabei eine zentrale Rolle.

Entscheidungsunterstützungssysteme kommen heute in vielen Unternehmen zum Einsatz und ihr Einsatz wird schon lange in der Fachwelt thematisiert. Aber die traditionellen Systeme weisen konzeptionelle Schwächen auf. Heute benötigt man Werkzeuge, die auch die servicezentrierte Sichtweise berücksichtigen. Dabei müs-sen auch die internen Abläufe Berücksichtigung finden und abgebildet werden. Die Bereitstellung von Diensten muss ebenfalls berücksichtigt werden und in die De-signimplementierung einfließen. Ein weiterer Knackpunkt: Moderne Tools müssen auch die organisatorische Ebene erkennen. Dabei erweisen sich die Serviceinterak-tionen als Schlüsselfunktionen für den Erfolg von Unternehmen. Man denke in die-sem Zusammenhang nur an die Lieferketten in Unternehmen.

Seit geraumer Zeit werden Services als Grundlage für den wirtschaftlichen Aus-tausch und den damit verbundenen Erfolg bewertet5. Die Märkte haben sich verän-dert und tendieren mehr und mehr in Richtung serviceorientierte Dienstleistungen. Damit geht auch eine geänderte Ausrichtung der Forschung einher, die sich in Rich-tung Dienstleistungsforschung orientiert. Palmisano6, Maglio und Spohrer7 sowie weitere sprechen in diesem Zusammenhang von der „Wissenschaft der Services“. Ihr Ziel ist die Entwicklung von neuen Theorien und praktischen Ratschlägen für diesen neuen Bereich. In diesem Prozess spielt die Informationstechnologie eine entscheidende Rolle als wichtigstes Hilfsmittel für das Sammeln und Verarbeiten der relevanten Informationen.

Ein dienstleistungsorientiertes Unternehmen lebt von der Interaktion und dem In-formationsaustausch mit dem Kunden. Ohne eine Kundenbeteiligung geht oftmals wenig und sie ist häufig eine der zentralen Voraussetzungen für eine erfolgreiche Kooperation. Der technische Fortschritt bietet dabei Unternehmen heute andere Möglichkeiten, als diese noch vor zehn, zwanzig oder dreißig Jahren zur Verfügung standen. Die moderne IT-Technologie bietet Möglichkeiten, Geschäftsprozesse zu

5 Vgl. Vargo / Lush (2004), S. 1-17 6 Vgl. Palmisano (2006), S. 127-136 7 Vgl. Maglio / Spohrer (2008), S. 18-20

1 Einleitung 6

definieren, verteilte Projekte zu managen und die Koordinierung zwischen den Pro-jektteams zu optimieren.

Abbildung 1: Die Charakterisierung von Servicesystemen.8

Ein typisches Service Framework besteht aus drei Komponenten. Die erste Kom-ponente ist der sogenannte Serviceprovider – ein Begriff, den man aus der Internet-Technologie kennt, der in diesem Szenario eine ähnliche Funktion übernimmt: Er stellt bestimmte Dienste seinen Kunden zur Verfügung. Ein Serviceprovider ist durch die Kombination von Individuen, Organisationen und Technologien gekenn-zeichnet. Die zweite tragende Komponente ist der Service-Client. Er nimmt die an-gebotenen Dienstleistungen des Serviceproviders in Anspruch. Meist handelt es sich bei dem Client um eine Kombination aus Einzelpersonen und Organisationen.

Die dritte Komponente, bezüglich der Provider und Client interagieren, ist der Ser-vice. Der Begriff Service muss dabei losgelöst von der typischen Vorstellung einer Dienstleistung betrachtet werden. Ein Service kann eine Kombination aus Men-schen, Organisationen, Verfahren, Technologien, Informationen etc. sein. Aus die-sem sehr weit gefassten Begriff ergeben sich verschiedensten Aspekte und Prob-leme. Abbildung 1 verdeutlicht einige dieser Punkte. Insbesondere die Wechselwir-kung zwischen den Komponenten des Rahmens und der intra- und interorganisato-rischen Konnektivität kennzeichnen moderne serviceorientierte Systeme.

Aus den vielfältigen Wechselwirkungen resultiert ein komplexer Prozess, der durch sich ändernde Anforderungen, Zielsetzungen und beteiligten Personen sowie Ver-

8 Vgl. Maglio / Spohrer (2008), S. 18–20

1 Einleitung 7

antwortlichkeiten gekennzeichnet ist. Fortlaufende Veränderungen auf den Organi-sationsebenen erschweren die Zusammenarbeit zwischen den Entscheidungsträgern erheblich. Ein weiteres Problem sind strukturierte, semistrukturierte oder unstruk-turierte Daten und Ausgangsinformationen.

An diesem Punkt setzen die sogenannten Decision Support Systeme9, kurz DSS, an. Dabei handelt es sich um computerbasierte Systeme, die der Unterstützung der Ent-scheidungsfindungsprozesse für die Entscheidungsträger dienen. Sie unterstützen Entscheider insbesondere bei der Lösung von semistrukturierten und unstrukturier-ten Problemen. Von solchen Systemen wird eine hohe Adaptivität und Flexibilität verlangt. Sie müssen den Zugriff von unterschiedlichen Standorten und auf ver-schiedene Netzwerkressourcen erlauben. Von derlei Systemen verlangt man auch, dass sie iterative Methoden wie beispielsweise die Was-wäre-wenn-Analyse unter-stützen.

Um den hohen Anforderungen in Unternehmen gerecht zu werden, müssen DSS sich an Veränderungen der externen und internen Systemumgebungen anpassen können. Sie müssen außerdem die Manipulation von Komponenten und Prozessen erlauben. Relevante Entscheidungskomponenten müssen bei Bedarf in die Ent-scheidungsfindung integriert und wieder ausgeschlossen werden können. Eine wei-tere Anforderung: Die Architektur sollte das Hinzufügen von weiteren Komponen-ten zur Laufzeit erlauben.

Dong und Srinivasen haben in ihrem 2012 veröffentlichten Artikel „Agent-Enabled Service-Oriented Decision Support Systems“ die Erweiterung bestehender Ansätze diskutiert und dabei eine mehrdimensionale Architektur entwickelt:

•   Entscheidungsfindungssysteme müssen um die Möglichkeit der Zusam-menarbeit zwischen den Entscheidern erweitert werden. Ein effektiver In-formationsaustausch ist ein Muss.

•   Das Systemdesign sollte so konzipiert sein, dass ein Informationsaustausch sinnvoll erfolgt. Durch unterschiedliche Ansichten und die Bereitstellung entsprechender Dienste werden Entscheider unterstützt.

•   Außerdem sollten die Systeme sich an dynamisch veränderte Organisations-einheiten anpassen und heterogene Strukturen abbilden können10.

Eine entsprechende Architektur kann die serviceorientierten Anforderungen mo-derner Unternehmen unterstützen. Aber wie kann eine solche Architektur konkret aussehen? In jüngerer Zeit wurden verschiedene Lösungsansätze publiziert, die

9 Vgl. Bonczek R. et al. (1981); Liew / Sundraran (1997), S. 786-802 10 Vgl. Dong / Srinivasen (2012)

1 Einleitung 8

diese Problematik adressieren. Bhargava, Power und Sun11 haben das Standardde-sign von DSS um ein Web-Interface erweitert, allerdings fehlen noch komplexe Design-Erweiterungen.

Ein notwendiges Feature im DSS-Design ist die Unterstützung verteilter Entschei-dungsfindungsprozesse. Zhang und Goddard12 haben eine mehrschichtige Soft-warearchitektur mit Web-Schnittstelle entwickelt, die den verteilten Einsatz erlaubt und den Schwerpunkt auf die Datenorientierung legt. Wieder andere Autoren wie Madhusudan und Uttamsingh13 plädieren für weitgehend automatisierte Verfahren zur Zusammenführung von Web-Services, um insbesondere menschliche Eingriffe in Entscheidungsprozesse zu minimieren. Wieder andere Autoren sehen die Ver-wendung von Semantic Web14 als einen Lösungsweg, um die bestehende Ansätze bei der Entscheidungsfindung mit mehr „Intelligenz“15 auszustatten. Die bislang in der Fachwelt diskutierten Ansätze und Problemlösungen kann man in vier Dimen-sionen unterteilen:

•   Quelle: Die Dimension bezieht sich auf Komponenten bzw. Dienste wie Modelle, Daten, Solver und Visualisierungen.

•   Ort: Diese Dimension bezieht sich auf die Verteilung von Ressourcen. •   Lebenskreislauf: Diese Dimension bezieht sich auf die Abfolge von Pro-

zeduren oder Tätigkeiten während des gesamten Entscheidungsprozesses. •   Zeit: Diese Dimension bezieht sich auf die zeitliche Abfolge von Entschei-

dungen.

In der Vergangenheit wurden die verschiedensten Frameworks und Architekturen entwickelt, doch kaum eines berücksichtigt alle vier Dimensionen gleichermaßen. Die Lösung muss daher in der Erweiterung bzw. im Redesign entsprechender An-sätze liegen. Als bislang vielversprechendster Ansatz gilt die Integration von DSS-Komponenten und Services unter Berücksichtigung dynamischer Entscheidungs-prozesse. Das Ziel ist eine intelligente Lösung, die den Benutzern die Möglichkeit bietet, die Prozessausführung zu steuern und zu führen.

11 Vgl. Bhargava / Power / Sun (2007), S. 1083-1195 12 Vgl. Zang / Goddard (2007), S. 1133-1150 13 Vgl. Madhusudan / Uttamsingh (2006), S. 325–357 14 Vgl. W3C (2016) 15 Vgl. Bose / Sugurmaran; Vgl. Deokar/ El-Gayar (2010)

2 Grundlagen von Entscheidungsunterstützungssystemen 9

2   Grundlagen  von  Entscheidungsunterstützungssystemen  

Oben wurde der Begriff Entscheidungsunterstützungssysteme bereits eingeführt. Er soll nun konkretisiert und um die Service- und Agent-Unterstützung erweitert wer-den. Bei einem EUS handelt es sich um rechnergestützte Systeme, die die Entschei-dungsträger bei schlecht strukturierten Entscheidungssituationen unterstützten. „Das Problemlösungsverfahren ist interaktiv, d. h., es läuft im Mensch-Maschine-Dialog ab.“16 Dabei geht es nicht darum, Entscheidungen voll zu automatisieren, sondern vielmehr sind die Erfahrungen und das Urteilsvermögen der Entscheider gefragt. EUS sollten die Entscheidungsprozesse unterstützen und effektiver gestal-ten.

 

Abbildung 2: Die Systematik der Managementunterstützung17.

Abbildung 2 verdeutlicht die Einordnung von Entscheidungsunterstützungssyste-men in Bezug zu verwandten Systemen wie EIS, MIS und MSS. Die sogenannten „Management Support Systeme (MSS) sind der Oberbegriff für sämtliche Systeme, die mit informations- und kommunikationstechnischer Unterstützung Entschei-dungsträgern bei Managementaufgaben helfen“18. EUS unterscheiden sich von Ma-nagement-Informationssystemen (MIS), die man präziser als Data Support Systems

16 Back (2002), S. 369 17 Vgl. Krallmann / Mertens / Rieger (2001), S. 287 18 Vgl. Back (2002), S. 370

2 Grundlagen von Entscheidungsunterstützungssystemen 10

bezeichnen sollte. Diese Systeme stellen keine Methoden oder Modelle für die Ent-scheidungsfindung bereit. Die Entscheidungsunterstützungssysteme stellen Ent-scheidern formale, computergestützte Modelle zur Verfügung. Sie führen verschie-dene Berechnungen auf unterschiedlichen Annahmen durch. Dabei werden unter-schiedlichste Szenarien (Was-wäre-wenn) durchgespielt und Fragestellungen be-antwortet.

Abhängig von dem Entscheidungsproblem können die Modelle als Tabellenkalku-lations-, Optimierungs- und Simulationsmodelle, als Expertensysteme oder als wis-sensbasierte Systeme bezeichnet werden. Sie verwenden meist Regelwerke, um das zugrundliegende Datenmaterial zu analysieren und Diagnosen zu liefern bzw. Prog-nosen abzuleiten.

Dong und Srinivasen erweitern diese Basissysteme um die Service- und Agent-Komponenten. Dabei werden Services als Abstraktion zwischen dem Geschäfts-prozess und der Software-Anwendungsschicht betrachtet. Services und serviceori-entierte Architekturen unterstützen die Geschäftsprozesse mit Flexibilität und Agi-lität. Im EUS-Kontext sind Services durch Schnittstellen definiert, die Systemkom-ponenten miteinander verknüpfen und Entscheidungsprozesse unterstützen. Solche Dienste werden von Software-Agents bereitgestellt.

Eine intelligente Lösung muss die vier oben beschriebenen Entscheidungsdimensi-onen berücksichtigen. Ein serviceorientiertes System muss daher als interaktive, computergestützte Lösung definiert werden, die die flexible Integration von Kom-ponenten zur Lösung von semi-strukturierten und unstrukturierten Problemen er-laubt. Dong und Srinivasen schlagen hierfür ein Framework vor, dass die EUS-Kernfunktionen um adaptive, serviceorientierte Schnittstellen erweitert.

Dieser Erweiterung fehlt noch eine weitere essenzielle Komponente, die die Gege-benheiten in modernen Unternehmen abbildet: verteilte Strukturen. Verteilte Prob-lemlösungen sind notwendig, um physikalisch verteilte Probleme an unterschiedli-chen Standorten oder Servern abbilden zu können.

2 Grundlagen von Entscheidungsunterstützungssystemen 11

 

Abbildung 3: Die Architektur eines serviceorientierten Entscheidungsunterstüt-zungssystems19.

Zu unterschiedlichen Etappen bei der Entscheidungsfindung können in einer sol-chen flexiblen Architektur unterschiedliche Modelle zum Einsatz kommen. In der Literatur spricht man in diesem Zusammenhang auch von „Multi Model Usage“20.

19 Vgl. Dong / Srinivasen (2012), S. 368 20 Vgl. Liew / Sundraran (1997), S. 786-802

3 Erweiterung um die Agent-Komponente 12

3   Erweiterung  um  die  Agent-­Komponente  Um den Anforderungen in modernen Unternehmen gerecht zu werden, bedarf es der Erweiterung der Architektur der serviceorientierten Entscheidungsunterstüt-zungssysteme um die Agent-Komponente. In der englischsprachigen Literatur spricht man auch von Agent-Enabled Service-Oriented DSS, kurz ASDSS. Solche Systeme besitzen eine mehrschichtige Architektur mit vielen Facetten und Kompo-nenten. Durch die Erweiterung um die Agent-Komponente wird die serviceorien-tierte Entscheidungsunterstützung über das Netzwerk hinweg möglich.

Die Software-Agenten sorgen für die Verbindung und den Datenaustausch zwi-schen den Serviceprovidern und seinen Komponenten. Die Serviceprovider stellen beispielsweise Datenanalysen, Daten aus Data Warehouses, Solver, Visualisierun-gen und Szenarien bereit und integrieren diese in die Entscheidungsunterstützungs-systeme. Damit entsteht eine Umgebung, die eine verteilte Problemlösung über lo-kale und zeitliche Grenzen hinweg erlaubt. Ein Serviceprovider kann dabei Dienste und Daten für mehrere Service-Clients zur Verfügung stellen.

Im Mittelpunkt der ASDSS-Architektur stehen die Komponenten-Services und Software-Agenten. Die Services stellen unabhängige Objekte wie Daten, Modelle etc. über das Netzwerk bereit. Bei den Agents handelt es sich um intelligente und mobile Agenten. Sie können dabei unterschiedliche Rollen einnehmen:

•   Daten Service-Agent •   Modell Service-Agent •   Solver Service-Agent •   Szenario Service-Agent •   Verzeichnisdienst-Agent •   Broker Service-Agent •   Manager Service-Agent

Welcher Agent im Einzelfall zum Einsatz kommt bzw. implementiert werden soll, ist von der jeweiligen Umgebung abhängig.

3 Erweiterung um die Agent-Komponente 13

 

Abbildung 4: Die um Agent-Unterstützung erweiterte SDSS-Architektur21.

Dank der Mobilität bzw. deren Mobilitätsfähigkeiten können sich die mobilen Agents beliebig im Netzwerk bewegen bzw. nahezu beliebig positioniert und ein-gesetzt werden. Die Agents sind – je nach Implementierung – auch in der Lage, interaktiv zu agieren, spezifische Daten zu ermitteln und den Entscheider bzw. das DSS mit den relevanten Informationen zu versorgen.

Aus der Kombination von klassischem SDSS und den Komponentendiensten, die durch die Agents ermöglicht werden, entsteht ein ASDSS. Die mobilen Agents lö-sen auch die Ort- und Zeitprobleme, da sie unabhängig von ihrem Einsatzort und dem Einsatzzeitpunkt Daten sammeln und an das SDSS übergeben können – und zwar synchron und asynchron.

Dabei sind die unterschiedlichsten Szenarien denkbar: Man könnte beispielsweise einen Solver-Dienst verwenden, um ähnliche Probleme an verschiedenen Orten zu lösen. Alternativ könnte man mehrere Solver-Dienste nutzen, um ein Problem an einer Stelle zu lösen. Man könnte auch mehrere Solver-Dienste für unterschiedliche Probleme an verschiedenen Standorten verwenden. Hinsichtlich der Flexibilität sieht die von Dong und Srinivasen vorgeschlagene ASDSS-Architektur keinerlei Einschränkungen vor. Die Grenzen werden lediglich durch die Implementierung gezogen.

21 Vgl. Dong / Srinivasen (2012), S. 370

3 Erweiterung um die Agent-Komponente 14

Ein Agent stellt seine Funktionen über eine sogenannte Agent-Shell zur Verfügung. Über diese erfolgt die Kommunikation mit den SDSS. Die Shell besteht aus ver-schiedenen Komponenten: Kommunikationsmodul, Socket, Plug-in-Socket, Mes-sage Controller, Aktionen und Event Handler. Der Communicator, das Kommuni-kationsmodul, ist für das Senden und Empfangen von Nachrichten von anderen Diensten oder Agents zuständig. Der Socket Connector stellt eine Low-level-Kom-munikation zur Verfügung, die insbesondere für den Datenaustausch zwischen he-terogenen Agenten-Systeme benötigt wird. Für den Versand und Empfang von Nachrichten verfügt der Agent über eine spezielle Nachrichtensteuereinheit.

3.1   Agenten-­fähige  Komponentendienste    Die sogenannten Komponentendienste sind die grundlegenden Bausteine von Ent-scheidungsunterstützungssystemen. Die wichtigsten Dienste sind dabei die Daten, Modelle, Solver, Visualisierung und Szenarien. Modellierungsdienste werden ver-wendet, um die realen Probleme darzustellen, Solver-Services liefern Lösungen für die Modelle. Eine wichtige Aufgabe übernehmen die Visualisierungsdienste, die visuelle Darstellungen von Komponenten generieren. Außerdem bilden Szenario-Objekte Momentaufnahmen bestimmter Zeitpunkte ab.

Damit die verschiedenen Komponentendienste sinnvoll ineinandergreifen, muss zwischen diesen eine Bindung erzeugt werden. Erst so wird ein Daten- und Infor-mationsaustausch möglich. Die Bindung kann manuell und automatisch hergestellt werden. Da die verschiedenen Dienste unterschiedliche Aufgaben abdecken und damit verschiedene Daten verarbeiten und liefern, unterliegt die Bindung allerdings gewissen Einschränkungen bezüglich der austauschbaren Datentypen. Dank mo-derner Techniken wie XML und Java ist allerdings eine Transformation und die Entwicklung von geeigneten Kommunikations- und Austauschmöglichkeiten mög-lich.

3.2   Agent-­Kommunikation  In der ASDSS-Architektur kommen Agents und Objekte zum Einsatz. Während Agents untereinander kommunizieren, rufen Objekte die Methoden und Funktionen anderer Objekte auf. Die Agent-Kommunikation verlangt nach dem Austausch von Nachrichten. Das wiederum setzt ein einheitliches Nachrichtenprotokoll und -for-mat voraus. Alle verwendeten Agents müssen dieses Protokoll unterstützen. Neben dem klassischen Eins-zu-eins-Nachrichtenversand macht auch die Implementie-

3 Erweiterung um die Agent-Komponente 15

rung eines Broadcast-Mechanismus Sinn, damit ein Agent alle anderen Agents kon-taktieren kann – und zwar auch dann, wenn der Sender nicht weiß, welche Agents wo zum Einsatz kommen.

3.3   Agent-­Lebenszyklus  Erst die Erweiterung der SDSS-Architektur um die Agent-Komponente liefert die ASDSS-Architektur, die den verteilten Entscheidungsfindungsprozess geeignet un-terstützen kann. Die Agents kooperieren dabei mit den DSS-Komponenten und un-terstützen somit die verteilten Entscheidungsprozesse. Die ASDSS-Agents durch-laufen bei ihrer Verwendung mehrere Phasen (man spricht in diesem Zusammen-hang auch von einem Lebenszyklus) 22:

•   Erzeugung – Der Agent wird von der Agent-Umgebung erzeugt. •   Instanziierung – Der Agent mit den Komponentendiensten wird instanziiert. •   Klonen – Der Agent kann mit Komponentendiensten reproduziert werden. •   Dispatching – Der Agent wird von einem Host zu einem anderen übertra-

gen. •   Zurückziehen – Nach dem Dispatching kann der Agent zurückgezogen wer-

den. •   Deaktivierung – Agent kann gesichert und gespeichert werden. •   Aktivierung – Agent kann aus dem deaktivierten Status wieder reaktiviert

werden. •   Löschung – Schließlich kann der Agent gelöscht werden.

Nach Dong und Srinivasen sind Daten, Modelle, Löser und Visualisierungen die grundlegenden Bausteine der SDSS-Architektur. In Verbindung mit dem Einsatz von Agents entsteht daraus eine ASDSS-Architektur, die die Probleme Ressource, Lebenszyklus, Ort und Zeit löst. Die ASDSS-Architektur adressiert das Ressour-cenproblem durch den Einsatz unabhängiger Komponentendienste wie Daten, Mo-delle, Solver und Visualisierungen. Ein objektorientiertes Paradigma löst das Le-benszyklusproblem und die Messaging-Fähigkeiten; die Mobilität der Agents löst das Raum- und Zeitproblem. Allerdings bleibt die Frage, wie eine mögliche Imple-mentierung einer solchen komplexen Architektur in der Praxis aussehen kann. IBM hat als eines der ersten Unternehmen einen ASDSS-Prototyp mit Agent-Technolo-gien als Proof-of-Concept implementiert23.

22 Vgl. Dong / Srinivasen (2012), S. 371 23 Vgl. Lange / Oshima (1998); Liberman / Griffel / Merz / Lamersdorf (1997)

3 Erweiterung um die Agent-Komponente 16

3.4   Implementierung  Entscheidungsunterstützungssysteme kommen heute bereits vielfach in der Wirt-schaft, in der Industrie und im Gesundheitswesen zum Einsatz. Anhand einer Bei-spielimplementierung zeigen Dong und Srinivasen, wie sich die ASDSS-Architek-tur sinnvoll nutzen lässt24. Danach ließe sich diese Architektur beispielsweise zur Lösung des CPFR-Problems (Collaborative Planning, Forecasting and Replenish-ment) nutzen. Das Ziel von CPFR ist es, auf Grundlage von Marktprognosen eine Planung zu entwerfen, die die Produktion und Lagerhaltung der tatsächlichen Nach-frage berücksichtigt sowie den Warenfluss und die Verkaufsförderungsmaßnahmen optimal aufeinander abstimmt.

In der Praxis ließe sich ein ASDSS wie folgt in den Unternehmensablauf und zur Unterstützung der Entscheidungsprozesse integrieren:

•   Schritt 1: Die Händler erstellen mit einem Prognosemodell ihre Umsatz-prognose (Ressourcen- und Lifecycle-Dimensionen).

•   Schritt 2: Die Verkaufsabteilung des Händlers erzeugt auf Grundlage der Umsatzprognose der einzelnen Händler eine aggregierte Umsatzprognose (Standort-Dimension).

•   Schritt 3: Die Verkaufsabteilung des Herstellers generiert Prognosen auf der Grundlage ihrer Verkaufsaufzeichnungen und den Kundeninformatio-nen (Zeitdimension).

•   Schritt 4: Die Umsatzprognosen von Händler und Hersteller werden abge-glichen (Lifecycle-Dimension).

•   Schritt 5: Auf Grundlage des Datenabgleichs, der Umsatzprognose, des Be-stands und des Produktionsplans stimmen Hersteller und Händler eine Auf-tragsprognose ab (Ressource-, Ort- und Lifecycle-Dimension).

Begleitet wird dieser Prozess durch die Information der Entscheidungsträger, wenn sich beispielsweise signifikante Abweichungen ergeben und Anpassungen von Ver-einbarungen notwendig sind. In einem solchen komplexen Szenario werden insbe-sondere Umsatzprognosen genutzt, um die Produktionsvolumina und Liefermengen zu ermitteln.

 

 

24 Vgl. Dong / Srinivasen (2012), S. 371

Zusammenfassung und Ausblick 17

Zusammenfassung  und  Ausblick    Wie Power, Burstein und Sharda zeigen, haben sich Entscheidungsunterstützungs-systeme in den letzten Jahrzehnten in Unternehmen fest etabliert und sich dabei immer wieder an geänderte Anforderungen angepasst25. Die Kernaufgabe von sol-chen Systemen ist es, die Entscheidungsträger dahingehend zu unterstützen, aus unstrukturierten bzw. semistrukturierte Daten verwertbare Informationen zu schaf-fen, die die Manager in ihrer Entscheidungsfindung unterstützen. Da die Entschei-dungsträger aber oft geographisch verteilt sind und sich ihre Entscheidungsfindung gegenseitig beeinflusst, benötigt man heute eine neue Generation von EUS. Dazu bedarf es eines Redesigns bzw. einer Erweiterung der DSS-Architektur.

Eine entsprechende Architektur muss dabei nicht nur die Verteilung von Entschei-dern und Datenquellen auf unterschiedliche Standorte berücksichtigen, sondern sie muss auch flexibel auf jede Form der Veränderung der Umgebung reagieren kön-nen. Kurz: Sie muss ein Maximum an Anpassungsfähigkeit und Flexibilität bieten. Ein solches verteiltes DSS-Framework und eine Agent-fähige verteilte DSS-Archi-tektur können die Entscheidungsprozesse optimal unterstützen. Dabei können die unterschiedlichsten Daten, Modelle, Solver, Visualisierungen und Szenarien ge-sammelt und in die Entscheidungsunterstützungssysteme integriert werden.

Durch Techniken wie Apache UIMA (Unstructured Information Management Ar-chitecture)26, NLP (Natural Language Processing), XML (Extensible Markup Lan-guage), OOP (Objekt-Orientierte Programmierung) und Java steht einer Implemen-tierung entsprechender Lösungen zumindest aus technologischer Sicht nichts im Wege. Letztlich werden die unternehmensrelevanten Entscheidungen allerdings von Menschen gefällt werden müssen. Eine vollständige Automatisierung erscheint wenig sinnvoll. Aber ASDSS könnten Entscheider dabei hervorragend begleiten.

25 Vgl. Power / Burstein / Sharda (2010), S. 25-42 26 Vgl. Apache UIMA-Projekt

Literaturverzeichnis 18

Literaturverzeichnis    

Apache UIMA (2017): Offizielle Projekt-Website, Online: http://uima.apache.org (Zugriff: 01.11.2017)

Back, Andrea (2002): Entscheidungsunterstützungssysteme, Online: http://www.kooths.de/teaching/bits-wbs/back-eus.pdf (Zugriff: 01.11.2017)

Bhargava, H.K. / Krishnan, R. /Muller, R. (1997): Decision support on demand: emerging electronic markets for decision technologies, in Decision Sup-port Systems

Bonczek, R. / Holsapple, C. / Whinston, A. (1981): Foundations of Decision Sup-port Systems

Dong, C.-S. J. / Srinivasen, A. (2012): Agent-enabled service-oriented decision support systems, Elsevier

Gabriel, Roland (2016): Entscheidungsunterstützungssystem, Online: http://www.enzyklopaedie-der-wirtschaftsinformatik.de/lexikon/ueber-greifendes/Kontext-und-Grundlagen/Informationssystem/Entscheidungs-unterstutzungssystem (Zugriff: 01.11.2017)

Krallmann, H. / Mertens, P. / Rieger, B. (2001): Management Support Systems (MSS), in: Lexikon der Wirtschaftsinformatik, hrsg. v. Mertens, Peter / Back, Andrea / Becker, Jörg

Krallmann, H. / Merstens, P. / Rieger, B. (2001): Entscheidungsunterstützendes System (EUS), in: Lexikon der Wirtschaftsinformatik, hrsg. v. Mertens, Peter / Back, Andrea / Becker, Jörg

Lackes, Richard (2016): Decision Support System, Online: http://wirtschaftslex-ikon.gabler.de/Definition/decision-support-system-dss.html (Zugriff: 01.11.2017)

Lange, D. /Oshima, M. (1998): Programming and Deploying Java Mobile Agents with Aglets

Liberman, B. / Griffel, F. / Merz, M. /Lamersdorf, M. (1997): Java-based mobile agents – how to migrate, persist, and interact on electronic service markets

Liew, A. /Sundaram, D. (2009): Flexible modelling and support of interrelated de-cisions, Decision Support Systems 46

Literaturverzeichnis 19

Madhusudan, T. / Uttamsingh, N. (2006): A declarative approach to composing to

composing web services in dynamic environments, in: Decision Support Systems 41

Power, D. J. / Burstein, F. /Sharda, R. (2010): Decision Support: An Examination of the DSS Discipline

W3C (2016): Semantic Web – Spezifikation des W3C, Online: https://www.w3.org/standards/semanticweb/ (Zugriff: 01.11.2017)

Zhang, S. / Goddard, S. (2007): A software architecture and framework for web based distributed decision support systems, in: Decision Support Systems 43

Literaturverzeichnis 20