Gesellschaft für Informatik e.V.

Lecture Notes in Informatics


INFORMATIK 2005, Informatik LIVE! Band 1, BeitrĂ€ge der 35 Jahrestagung der Gesellschaft fĂŒr Informatik e.V. (GI), 19. bis 22. September 2005 in Bonn P-67, 251-255 (2005).


2005


Editors

Armin B. Cremers, Rainer Manthey, Peter Martini, Volker Steinhage (eds.)


Contents

Referenzmodell fĂŒr situierte und individualisierte GeschĂ€ftsentscheidungen

I. Walther , S. Gillessen and P. Mertens

Abstract


Die Autoren schlagen eine Architektur zur betrieblichen EntscheidungsunterstĂŒtzung vor, die situative Komponenten, wie beispielsweise die Branche und die GrĂ¶ĂŸe des Unternehmens, ebenso wie individuelle Einflussfaktoren, etwa die Rolle des Entscheiders und seine persönlichen PrĂ€ferenzen, berĂŒcksichtigt. Ihre prototypische Umsetzung und Anregungen fĂŒr die Nutzung des Systems werden anschließend beschrieben. Motivation Bisherige Referenzmodelle beziehen sich in erster Linie auf Administrationssysteme, und dort wiederum auf den Auftragsdurchlauf. Es ist aber denkbar, dass in Zukunft auch Referenzmodelle fĂŒr Planungsund Kontrollsysteme geschaffen werden. Im Gegensatz zur ĂŒblichen Referenzmodellierung, bei der Prozesse als Abfolgen von Ereignissen und TĂ€tigkeiten im Fokus stehen, oder zu Funktions- und Organisationsmodellen muss man bei der Abbildung von Planungs- und Kontrollsystemen andere Konstrukte, und zwar Situationen, Entscheidungen, Methoden, Menschen und Ressourcenanforderungen mitsamt ihrer Deckung aus inner- und außerbetrieblichen Quellen verknĂŒpfen. In einem Unternehmen ist dem einzelnen Mitarbeiter eine Rolle zugewiesen, die er abhĂ€ngig von objektiven Vorgaben ausfĂŒhren muss und welche nur teilweise Spielraum fĂŒr subjektive Gestaltung lĂ€sst [SĂŒGi2003]. Die Anforderungen an die Rolle sind u. a. bestimmt durch Unternehmensmerkmale wie Typ, Wirtschaftszweig und die Phase im Lebenszyklus des Betriebs. Es besteht die Gefahr, dass die verschiedenen Aspekte gesondert und damit nicht methodisch untersucht werden, weil ein Bezugsrahmen (\?Framework“) fehlt. So sind Systematiken auszuarbeiten beziehungsweise weiterzuentwickeln, welche die jeweiligen Informationsbedarfe unterschiedlicher Anspruchs- 1 Bayerischer Forschungsverbund fĂŒr Situierung, Individualisierung und Personalisierung in der Mensch- Maschine-Interaktion 251 gruppen identifizieren. Das GerĂŒst soll vor allem den Entwicklern verschiedener Typen betrieblicher Informationssysteme als eine Art \?Checkliste“ zur VerfĂŒgung stehen, die aus einer FĂŒlle möglicher Informationen eine vom Adressaten \?verkraftbare“ Auswahl zu treffen haben und daher Filter benötigen. Aufbauend auf der Klassifizierung von Rollen und Situationen [WaGG2004] ergab sich die Idee, ein Modell zu erstellen, welches alle Einflussfaktoren betrachtet und diese miteinander verknĂŒpft. Die in Abbildung 1 gezeigte Entscheidungsarchitektur bildet hierfĂŒr die Basis. Es ist vorstellbar, dass eines Tages Module in irgendeiner technischen AusprĂ€gung, z. B. als Web Service, gehandelt werden. Indiv Indi id vi uali du si alis uali eru ieru si ng Branche/ bestimmen Aufgaben Betriebstyp/ Lebensphase des Rolleno le rientierung Betriebs determinieren Pflichten lic aus Roll aus en Roll typische Entscheidungen Pers Pe onalisierung werden durch entscheidungs- PrĂ€ferenz er en enz v en on v unterstĂŒtzende Entschei tsc de hei rn de Methoden/Systeme Situier ui ung un vorbereitet determinie in ren ie Informa or ti ma ons ti bedar ons f bedar legen ge Au n fb Au er fb ei er tu ei ng tu en ng Bescha Besc ff ha ung ff nahe na , z he . , z B. K B en . K nzah nz le ah n le von vo inne n n inne bedingen beding Datenbed Datenb ar ed f ar Bescha Besc ff ha ung ff von vo auß n en Abbildung 1 Entscheidungsarchitektur (Erweiterung zu [MeGr2002]) Modellierung entscheidungsorientierter Informationssysteme Es wurde ein ReprĂ€sentationsformalismus entwickelt, um die Daten ausgehend von der betrieblichen Problemstellung systemunabhĂ€ngig zu beschreiben [Zehn2002] und die betriebliche Situation in Form von Daten und Beziehungen zu prĂ€sentieren [FBPC2001]. Ein konzeptionelles Datenmodell bildet die einzelnen Elemente der Entscheidungsarchitektur ab und stellt zudem die Beziehungen zwischen den Bestandteilen der Entscheidungsarchitektur dar [Walt2005, 98]. Wegen der MehrdimensionalitĂ€t und der damit einhergehenden KomplexitĂ€t werden die Ergebnisse des Datenmodells in einem Entity- Relationship-Modell dargestellt (vgl. Abbildung 2), sodass man variabel Ausschnitte beziehen kann, welche ganz unterschiedliche InformationsbedĂŒrfnisse decken. Um die gesammelten Informationen erfassen zu können, empfehlen wir, ein so genanntes \?Role Dictionary“ als Hilfsmittel zur Codierung zu verwenden. Dieses stellt eine Übersicht dar, die die detaillierte Beschreibung der einzelnen Rollen, der fĂŒr die 252 AufgabenerfĂŒllung und Entscheidungsfindung benötigten Informationen und der Beziehungen zwischen den verschiedenen Rolleninhabern enthĂ€lt [Walt2005, 69]. Die Idee hierbei ist, zu Unternehmenssituationen die Entscheidungen, zu Entscheidungen die Methoden, zu Methoden die Informationsbedarfe und zu Informationsbedarfen die internen und externen Quellen zu prĂ€sentieren. Dazu erfolgt sowohl die Verkettung von der Situation bis zu Datenquelle \?hinunter“ als auch der umgekehrte Weg \?treppaufwĂ€rts“. Abbildung 2 Ausschnitt des Entity-Relationship-Modells An einem Beispiel sei illustriert, wie die Entscheidungsarchitektur im Unternehmen zum Einsatz kommt: Die Rolle \?Produktentwickler“, die im Funktionsbereich \?Forschung \& Entwicklung“ angesiedelt ist, hat die Aufgabe \?Lebenszyklusmanagement“, die beispielsweise durch die entscheidungsunterstĂŒtzende Methode \?Fischer-Verfahren“ vorbereitet werden kann (vgl. Abbildung 3). Abbildung 3 Exemplarische Methoden fĂŒr die Aufgabe \?Lebenszyklusmanagement“ Da das Medium Papier die Darstellung des entscheidungsorientierten Modells nur sehr beschrĂ€nkt erlaubt, findet sich unter http://www.siprum.de eine ĂŒber das Internet zugĂ€ngliche Sammlung von derzeit circa 100 Rollen, die mit etwa 500 Aufgaben, 900 Entscheidungen, 300 Methoden, 1700 Informationsbedarfen, 540 externen Datenquellen sowie 330 Datenlieferanten verbunden sind. Das System erlaubt vielfĂ€ltige Abfragen. So 253 ist der Fall denkbar, dass ein bisher genutzter Datenlieferant eine deutliche Preissteigerung ankĂŒndigt. In diesem Moment kann ein Unternehmer mithilfe der Datenbank recherchieren, welche weiteren Lieferanten Ă€hnliche Informationen anbieten. Im Vortrag werden u. a. eine Reihe von Abfragen in betrieblichen Situationen gebracht, z. . SchlĂŒsse von Datenlieferanten auf Methoden oder von Methoden auf Rollen. Die bilaterale VerknĂŒpfung von jeweils zwei Stufen der Treppe zeigt exemplarisch Tabelle


Full Text: PDF

ISBN 3-88579-396-2


Last changed 24.01.2012 21:50:48