Subjektivitätsmanagement für die Referenzmodellierung: Vorgehensmodell und Werkzeugkonzept

Subjektivitätsmanagement für die Referenzmodellierung: Vorgehensmodell und Werkzeugkonzept

Jörg Becker, Ralf Knackstedt, Dominik Kuropka, Patrick Delfmann

Westfälische Wilhelms-Universität Münster Institut für Wirtschaftsinformatik Leonardo-Campus 3 48149 Münster

Tel: +49(0)251/83-38 100 Fax: +49(0)251/83-38 109 E-Mail: {isjobe | israkn | isdoku | ispade}@wi.uni-muenster.de WWW: www.wi.uni-muenster.de/is

2

Subjektivitätsmanagement für die Referenzmodellierung: Vorgehensmodell und Werkzeugkonzept

Im Rahmen der Modellierung zielt Subjektivitätsmanagement darauf ab, Versio-nen von Modellen zur Verfügung zu stellen, die auf die abweichenden Bedürfnisse unterschiedlicher Nutzergruppen ausgerichtet sind. Der Beitrag betrachtet das Subjektivitätsmanagement speziell aus der Sicht des Referenzmodellerstellers. Zur Berücksichtigung der Anforderungsunterschiede werden die Modelle um das Kon-strukt der Perspektive ergänzt. Es wird der Prozess der Erstellung entsprechender Referenzmodelle strukturiert und Ansätze zu seiner Werkzeugunterstützung aufge-zeigt.

1 Wirtschaftliche Bedeutung multiperspektiver Referenzmodelle

Die Entwicklung von Referenzmodellen1 ist in der Regel eine aufwändige, kosten-intensive und risikoreiche Tätigkeit. Der Referenzmodellersteller2 muss wie der Hersteller jeden anderen Produktes seinen Markt identifizieren und ist von der Akzeptanz seines Produktes durch den Markt abhängig. Der Referenzmodell-ersteller steht bei der Abgrenzung seines Marktes vor dem folgenden Dilemma: Als Auswahlkriterium dient Unternehmen – neben der Qualität des betriebswirt-schaftlichen Know-how, das durch das Modell transferiert wird – insbesondere die Berücksichtigung der Unternehmensspezifika, die einen geringen Änderungsbe-darf verspricht. Die Einschränkung der Allgemeingültigkeit des Modells birgt für den Referenzmodellersteller allerdings ein erhöhtes Absatzrisiko ob des einge-schränkten Marktes.

Einen Ausweg aus dem Dilemma können konfigurierbare Referenzmodelle bedeu-ten. Konfigurierbare Referenzmodelle enthalten Regeln, wie das Referenzmodell

1 Der Begriff Referenzmodell wird im Folgenden als Kurzform für Referenz-

Informationsmodell verwendet. Referenz-Informationsmodelle formulieren Gestal-tungsempfehlungen für eine Klasse von Unternehmen. Zur Definition vergl. [BHKS00, S. 87-91].

2 Im Folgenden wird vom Referenzmodellersteller im Singular gesprochen. Selbstver-ständlich werden auch Referenzmodelle nicht von einzelnen Personen geschaffen, sondern von Teams. Von den Rollenverteilungen innerhalb der Gruppe der an der Re-ferenzmodellerstellung Beteiligten wird im Folgenden allerdings abstrahiert.

3

in Abhängigkeit unternehmensspezifisch gewählter Ausprägungen von Konfigura-tionsparametern zu verändern ist. Mit der Unterstützung des Konfigurationsme-chanismus wird der Änderungsaufwand reduziert, was die Akzeptanz einer größeren Nutzerschaft sichern kann.

Die Konfiguration von Referenzmodellen betrifft insbesondere zwei Dimensio-nen: In der für konfigurierbare Referenzmodelle obligatorischen Dimension ordnet sich das anwendende Unternehmen in ein Klassensystem von Unternehmen ein. Als Konfigurationsparameter dienen hierbei speziell Unternehmensmerkmale. Von multiperspektiven Referenzmodellen wird gesprochen, wenn als weitere Dimension die speziellen Anforderungen von Benutzergruppen innerhalb der Unternehmen Berücksichtigung finden. Der Ansatz, das wirtschaftliche Risiko der Referenzmodellerstellung über eine Ausweitung der Nutzergruppen, wie z. B. die Berücksichtigung der Anwendungssystemgestalter neben den Organisaitonsgestal-tern, zu reduzieren steht im Fokus dieses Beitrags.

Zunächst werden Grundlagen der multiperspektiven Modellierung eingeführt (Kapitel 2). Es wird insbesondere die Anwendung von multiperspektiven Model-len im Allgemeinen und von multiperspektiven Referenzmodellen im Speziellen erläutert. Darauf aufbauend wird der Prozess der Erstellung multiperspektiver Referenzmodelle betrachtet (Kapitel 3) und ein Konzept zu dessen Werkzeugun-terstützung dargestellt (Kapitel 4).

2 Subjektivierung und Multiperspektivität

Wahrnehmung und Erkenntnis sind subjektabhängige Phänomene.3 Strukturierun-gen der vom Menschen unabhängigen Welt sind nicht per se gegeben, sondern stellen Konstruktionsleistungen von Subjekten dar. Das Subjekt richtet sein Han-deln nach seiner individuell konstruierten Vorstellung von Wirklichkeit aus. Diese Subjektivierung stellt nach LUHMANN eine wesentliche Strategie zur Absorption von Komplexität dar und ist damit pragmatisch bedingt [Luhm99, S. 181-183]. Die Subjektivierung erhöht die Lösungschancen von Problemen, indem sie ihnen eine spezielle, lösbar erscheinende Fassung verleiht.

Gerade die ingenieurmäßige Problemlösung ist durch die Anwendung von Model-len geprägt. Modelle erfüllen die Aufgabe der Repräsentation des Problems in seinem jeweils aktuellen Bearbeitungsstand bzw. positiv formuliert der Repräsen-

3 Die Autoren nehmen eine Position des radikalen Konstruktivismus ein und fassen

Wahrnehmung und Erkenntnis als konstruktive und nicht abbildende Tätigkeiten auf [Glas00, S. 29-30]. Kognition ist demnach subjektabhängig und beruht nicht auf iko-nischer Widerspiegelung. Zur Bedeutung der erkenntnistheoretischen Positionierung im Rahmen von Forschungsarbeiten der Wirtschaftsinformatik vergl. z. B. [Schü98, S. 13-68], [Schü99], [KrSø96].

4

tation von Lösungsbeiträgen (Zwischenlösungen oder endgültigen Lösungen) eines Entwicklungsproblems [Zele99, S. 44]. Die Qualität eines Modells wird von Seiten des Modellnutzers umso höher bewertet werden, desto stärker es seiner problembedingten individuellen Subjektivierung entspricht [Rose00, S. 45-46]. Die Erstellung von Modellen bzw. Modellsystemen, die zugleich unterschiedli-chen Subjektivierungen gerecht zu werden versuchen, wird multiperspektive Mo-dellierung genannt. Mit der Unterscheidung verschiedener Perspektiven versuchen multiperspektive Modelle die Differenzen zwischen den Subjektivierungen von Modellnutzern bzw. von Gruppen von Modellnutzern zu repräsentieren.4

Neben der Möglichkeit, das Risiko der Modellbildung durch die Berücksichtigung mehrerer Einsatzgebiete zu reduzieren [Rose00, S. 45-47], motiviert die multiper-spektive Modellierung insbesondere die Notwendigkeit, das Handeln von Subjek-ten, die sich in ihren Relevanzstrukturen und Konzeptionalisierungen unterscheiden, im Rahmen gemeinsamer Gestaltungsziele zu koordinieren. Neben dem Problemlösungspotenzial wohnt den unterschiedlichen Subjektivierungen der Modellnutzer eine mögliche Gefährdung der sozialen Handlungsfähigkeit inne, die sich z. B. in inkonsistenten Gesamtlösungen ausdrückt. Besonders die unzu-längliche organisatorische Einbindung von Informationssystemen hat den Blick speziell auf die Unterschiede zwischen Organisations- und Anwendungssystemge-staltern geschärft und die Notwendigkeit einer Vermittlung zwischen den Subjekti-vierungen aufgezeigt [Fran94, S. 12].

4 Die Begriffe „Subjektivierung“ und „Perspektive“ werden hier nicht synonym ver-

wendet. Perspektiven werden als Bestandteile multiperspektiver Modelle aufgefasst. Perspektiven sind Produkte der Modellbildung und stellen damit Explikationen von Konstruktionen der Modellersteller dar. Die explizierten Konstruktionen sind die Vor-stellungen des Modellerstellers über die Differenzen der Vorstellungswelten der Mo-dellnutzer. Unter Subjektivierung wird das Erklärungsprinzip verstanden, dass sich die Individualität von Menschen insbesondere aus den Unterschieden ihrer subjektab-hängigen Vorstellungswelten ergeben. Anders verwendet den Begriff „Perspektive“ zum Beispiel WOLLNIK, der den Begriff „Perspektivendifferenzen“ prägt und darunter die Auffassungsunterschiede der Sub-jekte versteht [Woll86, S. 13]. Ebenso definiert FRANK eine Perspektive als ein „Konglomerat von Auffassungen, Prädispositionen und Präferenzen, die die Wahr-nehmung einzelner Personen oder Personengruppen in bestimmten Kontexten wesent-lich bestimmen“ [Fran94, S. 164, ohne Hervorhebungen]. Mit der hier gewählten Begriffsverwendung wird betont, dass zwischen den Subjekti-vierungen und den Perspektiven Differenzen oder Unschärfen bestehen, die der Mo-dellersteller bewusst aber notgedrungen in Kauf nimmt. Die Differenzen ergeben sich daraus, dass dem Modellersteller einerseits bei der Unterscheidung von Perspektiven komplexitätsmäßige Grenzen gesetzt sind (vgl. Abschnitt 3) und er anderseits in aller Regel kein vollständiges Wissen über die Subjektivierungen erhalten kann. Zudem kann – gemäß der hier eingenommenen erkenntnistheoretischen Position – le-diglich über die Zweckdienlichkeit der eingeführten Perspektiven nicht aber über de-ren Richtigkeit geurteilt werden [Schü98, S. 13-68].

5

Die Vergleichbarkeit der Vorstellungswelten verschiedener Subjekte wird auf zwei Wegen hergestellt [Schm00, S. 152-153]: Einerseits wirkt auf die Organisa-tion der Vorstellungswelt eine nach Brauchbarkeit (Viabilität) selektierende Aus-lese [Glas00, S. 23-31].5 Andererseits wird die Wirklichkeitskonstruktion von sozialer Kontrolle begleitet. Soziale Handlungsfähigkeit hat den Aufbau konsen-sueller Interaktionsbereiche durch die Vermittlung korrespondierender Konzepte der unterschiedlichen Subjektivierungen zur Bedingung [Fran94, S. 36-37; Schm00, S. 153-154]. Multiperspektive Modelle stellen ein geeignetes Hilfsmittel für den Vergleich und die Integration der Vorstellungswelten der an der Unter-nehmensgestaltung Beteiligten dar.6

Vorschläge zur Gestaltung multiperspektiv ausgerichteter Modellsysteme liegen insbesondere in Form von Informationssystemarchitekturen vor. Sie unterscheiden sich insbesondere in den berücksichtigten Perspektiven und verwenden den Per-spektivenbegriff selbst ebenfalls uneinheitlich. Prominente Beispiele für Informa-tionssystemarchitekturen sind ARIS [Sche01], CIM-OSA [Espr89], der Zachman-Framework [Zach87] sowie MEMO [Fran99]. Den Architekturen ist folgendes Prinzip gemeinsam: Die Architekturen spannen einen Raum von sog. „building blocks“ auf.7 Über ihre Koordinaten sind die „building blocks“ insbesondere den verschiedenen Perspektiven zugeordnet. Innerhalb der „building blocks“ sind in Form von Metamodellen die relevanten Konzeptionalisierungen festzulegen. In-dem die Konstrukte der einzelnen Metamodelle „building block“-übergreifend miteinander in Beziehung gesetzt werden, erhält man ein integriertes Gesamtme-tamodell der Informationssystemarchitektur. Durch die Auswahl derjenigen „buil-ding blocks“, die einer speziellen Perspektive zugeordnet sind, gelangt man zu einem perspektivenspezifischen Metamodell, das die speziellen Anforderungen der Perspektive berücksichtigt. Diese Basisoperation zur Berücksichtigung verschiedener Perspektiven wird hier Metamodellprojektion genannt.

5 Der radikale Konstruktivismus ist durchaus mit der Vorstellung einer das Handeln

beschränkenden, außerhalb der Vorstellungswelt existierenden Welt vereinbar, wo-durch er sich vom Soliphismus unterscheidet. In Abrede wird lediglich die Möglich-keit eines zweifelsfreien Erkennens dieser Welt gestellt [Glas00, S. 29-31].

6 Es wird nicht gesagt, dass die Integration der Vorstellungswelten vollständig gelingt. 7 Mit dem Begriff der „building blocks“ wird hier nicht notwendigerweise der Aufbau

der Architektur in Matrixform verbunden (vgl. [Fran94, S. 164]). Der Begriff wird vielmehr im Sinne von Einheiten verwendet.

6

Kunde istermittelt

Prüfe, obKunde als

Stammsatzvorhanden

XOR

Kunden-stammsatz

istvorhanden

Kunden-stammsatz

ist nichtvorhanden

Lege Kunden-stammsatz

an

Kunden-stammsatzist angelegt

XOR

ErfasseAuftrag

Kunden-stammsatzist angelegt

AuftragFB

KundeFB

Verkauf

ist Mehrfach-Merkmal von

ist Merkmal vonErteilungs-datum FB

KundeFB

AuftragFB

Modellvarianteder Perspektive

Organisationsgestaltung

Kunde istermittelt

Prüfe, obKunde als

Stammsatzvorhanden

XOR

Kunden-stammsatz

istvorhanden

Kunden-stammsatz

ist nichtvorhanden

Lege Kunden-stammsatz

an

Kunden-stammsatzist angelegt

XOR

ErfasseAuftrag

Kunden-stammsatzist angelegt

SAP R/3

AuftragFB

KundeFB

DataWarehouse

SAP R/3

Kunden-zuordnung

Auftrags-erteilung

Zeit

Auftrag

Kunde

(1,1)

(1,n)

(0,1)

(0,n)

ist Mehrfach-Merkmal von

ist Merkmal vonErteilungs-datum FB

KundeFB

Modellvarianteder Perspektive

Anwendungssystem-gestaltung

AuftragFB

Vorstand

Einkauf Produkt Verkauf

Controlling

Anwendungs-architektur

OrganigrammeErweiterteEreignisgesteuerte

Prozessketten

EntityRelationship-Modelle

Fachbegriffs-modelle

PerspektiveAnwendungs-

system-gestaltung

Verwendung

Verwendung

PerspektiveOrganisations-

gestaltung

Verwendung

Tra

nsf

orm

atio

n

Anwendungs-architektur

OrganigrammeErweiterteEreignisgesteuerte

Prozessketten

EntityRelationship-Modelle

Fachbegriffs-modelle

Verwendung

Verwendung

Verwendung

Tra

nsf

orm

atio

n

Verwendungdurch dieNutzergruppeder Organisa-tionsgestalter

Verwendungdurch dieNutzergruppeder Anwendungs-systemgestalter

Gesamt-metamodell

Metamodellprojektion

Anwendung

Abbildung 1: Metamodellprojektion

7

Die Metamodellprojektion wird im Folgenden anhand eines Beispiels illustriert (vgl. Abbildung 1). Als eine Informationssystemarchitektur, die eine gute Aus-gangsbasis für die multiperspektive Modellierung zur Verfügung stellt, erscheint eine sich an ARIS orientierende Verknüpfung der Modellierungstechniken Orga-nigramme, Anwendungssystemarchitekturen, erweiterte ereignisgesteuerte Pro-zessketten (EPK) [KeNS92], Fachbegriffsmodelle (FBM) [KuRo98] und Entity Relationship Modelle (ERM) [Chen76].8 Die Verwendung von FBM und ERM berücksichtigt die Unterscheidung zwischen semantischer und konzeptioneller Datenmodellierung [Heym95, S. 15-18; Spec01, S. 70-75]. Die FBM besitzen eine semantisch stärkere Ausdruckskraft als ERM und sind in der Regel leichter lesbar. Mit ihnen lassen sich In- und Outputs von Funktionen spezifizieren, die hinsicht-lich ihres Strukturierungsgrades stark variieren. Dagegen sind die ERM auf In- und Outputs spezialisiert, die sich mit Hilfe von Datenbankmanagementsystemen verwalten lassen. Die korrespondierenden Teile der FBM lassen sich in ERM transformieren [Spec01, S. 70-75]. Bei grober Unterscheidung der Perspektiven Anwendungssystem- und Organisationsgestaltung können ERM und Anwen-dungssystemarchitekturen eindeutig der Perspektive Anwendungssystemgestal-tung zugeordnet werden, während die detaillierte Gestaltung der Aufbauorganisation im Verantwortungsbereich des Organisationsgestalters liegen wird, weshalb Organigramme Teil seiner Perspektive sind. In diesem Beispiel zeigt sich die Unterschiedlichkeit der Perspektiven in der Verwendung verschie-dener Modellierungstechniken, was sich in Differenzen der perspektivenspezifi-schen Metamodelle auswirkt. Die Konsistenz zwischen den Perspektiven wird dadurch gesichert, dass sich die perspektivenspezifischen Metamodelle in Form von Projektionen auf ein integrierendes Gesamtmodell beziehen.9

Die Definition perspektivenspezifischer Metamodellprojektionen ermöglicht es, aus dem Gesamtmodell Modellvarianten abzuleiten, die den Subjektivierungen der Modellnutzer besser gerecht werden, als ein Modell, das auf diesen Ableitungs-mechanismus verzichtet. Die Anwendung eines multiperspektiven Modells kann in zwei Phasen gegliedert werden.10 In der ersten Phase wählt der Modellanwender die für ihn relevante Perspektive. Auf der Basis dieser Entscheidung wird dem Anwender eine angepasste Modellversion angeboten. Das multiperspektive Mo-dell muss explizite Anpassungspunkte und Konstrukte zur Variantenabbildung enthalten, um diese Phase der Konfiguration unterstützen zu können. Nachträgli-che Veränderungen, die der Modellanwender individuell an der erhaltenen Aus-

8 Zur Anwendung an dieser Informationssystemarchitektur angelehnter Modelle im

Rahmen eines Reorganisationsprojektes, das bei einem Unternehmen der Dienstleis-tungsbranche durchgeführt wurde, siehe [BeKR00].

9 In Abbildung 1 werden die Metamodellprojektionen für die Perspektive Organisati-onsgestalter durch farbliche Hinterlegung und für die Perspektive Anwendungssys-temgestalter durch Umrandung kenntlich gemacht.

10 Die Unterscheidung der Phasen erfolgt in Analogie zur Gliederung der Anwendung von konfigurierbaren Referenzmodellen [Schü98, S. 314].

8

gangslösung vornimmt und die vom multiperspektiven Modell nicht vorwegge-nommen werden können, sind Gegenstand der zweite Phase, die hier Anpassung genannt wird.

Multiperspektivität von Modellen ist eine auf mehreren Stufen der Modellverwen-dung zum Tragen kommende Zielsetzung (vgl. Abbildung 2). Das Informations-management eines Unternehmens hat die Aufgabe, einer hinsichtlich ihrer Subjektivierungen heterogenen Gruppe von Modellnutzern Unternehmensmodelle zur Verfügung zu stellen. Um die Akzeptanz der Unternehmensmodelle zu si-chern, wird es versuchen, perspektivenspezifische Modellversionen zur Verfügung zu stellen, die den Unterschieden der Subjektivierungen möglichst gerecht wer-den. Wird berücksichtigt, dass die Subjektivierungen von Projektgruppen sich signifikant von den Subjektivierungen der gesamten Unternehmensangehörigen unterscheiden können, so bietet es sich an, den Ableitungsprozess innerhalb des Unternehmens sogar mehrstufig zu gestalten. Aus einem multiperspektiven Mo-dell sollten daher nicht ausschließlich monoperspektivische Modelle ableitbar sein. Um die Bedürfnisse von Projektgruppen zu unterstützen, sollte das Ergebnis der Anwendung eines multiperspektiven Modells auch wiederum ein multi-perspektives Modell sein können.

Referenzmodelle per se formulieren Gestaltungsempfehlungen für eine Klasse von Unternehmen. Die Anwendung von Referenzmodellen kann wie die Anwendung multiperspektiver Modelle in die Phasen Konfiguration und Anpassung unter-schieden werden [Schü98, S. 314]. Über die Spezifikation von Merkmalsausprä-gungen und manuelle Anpassungen lassen sich aus konfigurierbaren Referenzmodellen unternehmensspezifische Modelle ableiten. Multiperspektivität von Referenzmodellen bedeutet, dass das Referenzmodell verschiedene Perspekti-ven berücksichtigt, die bei der Anwendung des Referenzmodells auf das unter-

Anwendung desmultiperspektivenReferenzmodells

Modell 1

Referenzmodell-ersteller

Unternehmens-informations-management

Projektgruppe einzelnerModellnutzer

Groß-handel

Einzel-handel

Unternehmensmerkmale:

Wissens-management Manager

Perspektiven:

Zertifizierung Fachkonzept

Bench-marking

Implemen-tierung

Modell 2

Groß-handel

Einzel-handel

Unternehmensmerkmale:

Wissens-management Manager

Perspektiven:

Zertifizierung Fachkonzept

Bench-marking

Implemen-tierung

Modell 3

Groß-handel

Einzel-handel

Unternehmensmerkmale:

Wissens-management Manager

Perspektiven:

Zertifizierung Fachkonzept

Bench-marking

Implemen-tierung

Modell 4

Groß-handel

Einzel-handel

Unternehmensmerkmale:

Wissens-management Manager

Perspektiven:

Zertifizierung Fachkonzept

Bench-marking

Implemen-tierung

Anwendung desmultiperspektiven

Modells

Anwendung desmultiperspektiven

Modells

Abbildung 2: Mehrstufige Anwendung multiperspektiver Modelle

9

nehmensspezifische Modell übertragen werden. Das Referenzmodell kann z. B. Perspektiven vorsehen, die von den Modellanwendern eines bestimmten Unter-nehmens nicht benötigt werden und daher im Rahmen der Konfiguration des Refe-renzmodells eliminiert werden sollten. Die Phase der Konfiguration wird entsprechend um die Auswahl der für das Unternehmen relevanten Perspektiven ergänzt und das Referenzmodell muss entsprechende Anpassungspunkte enthalten. Andererseits können dem Referenzmodell wichtige Perspektiven fehlen, so dass über eine Anpassung des Referenzmodells die fehlenden unternehmensspezifi-schen Perspektiven zu ergänzen sind. Das abgeleitete unternehmensspezifische Modell ist in der Regel wiederum ein multiperspektives Modell. In Ausnahmefäl-len wird bei der Konfiguration des multiperspektiven Referenzmodells eine einzi-ge Perspektive gewählt. Dass mit der Anwendung des multiperspektiven Referenzmodells Anpassungspunkte zur perspektivengerechten Konfiguration erhalten bleiben, stellt eine Besonderheit der multiperspektiven Referenzmodellie-rung dar. Die Anpassungspunkte zur Berücksichtigung der unterschiedlichen Un-ternehmensklassen werden bei der Anwendung des Referenzmodells in der Regel eliminiert.

Während multiperspektive Modelle in diesem Kapitel vorrangig aus der Sicht der Modellanwender betrachtet wurden, wird im Folgenden die Position des Erstellers eines multiperspektiven Referenzmodells eingenommen. Im Blickfeld stehen seine Vorgehensweise und das Konzept eines Werkzeuges, das ihn bei seiner Arbeit unterstützt.

3 Vorgehensmodell

Mit der Zielsetzung, Referenzmodelle multiperspektiv zu gestalten, ergibt sich die Notwendigkeit, das Vorgehensmodell der Referenzmodellierung um einige zusätz-liche bzw. modifizierte Aufgabentypen zu ergänzen, die im Folgenden unter dem Begriff des Subjektivitätsmanagements zusammengefasst werden (vgl. Abbildung 3). Die Aufgabentypen bauen logisch aufeinander auf, werden in der Praxis aber kaum streng zeitlich sequenziell bearbeitet werden.

Grundlage der multiperspektiven Referenzmodellierung ist die Identifikation der Modellnutzer. Neben der obligatorischen Eingrenzung der durch das Referenzmo-dell abzudeckenden Unternehmensklassen11 tritt im Rahmen des Subjektivitäts-management speziell die Abgrenzung des zu unterstützenden Personenkreises in das Blickfeld.

11 Zur Abgrenzung von Unternehmensklassen vgl. [MLEM99]. Zum allgemeinen Vor-

gehensmodell für die Referenzmodellierung vgl. [Schü98, S. 185].

10

Subjektivitätsmanagement

Modellnutzeridentifizieren

Perspektivendefinieren

Anforderungenanalysieren

Perspektiven-spezifitätherstellen

§Gegenstände§Modellierungs-

elemente§Modellierungs-

techniken§ Detaillierungs-

grade§ Visualisierung§ Bezeichnungs-

konventionen

Rollen

Zwecke

individuelleEinflüsse

Anwendung derTechniken desSubjektivitäts-managements(Metamodell-

projektion)

Unternehmenidentifizieren

Unternehmensmerkmaledefinieren

Großhandel Einzelhandel

Investitions-güter

Konsumgüter

Referenzmodellierungstechnik definierenund Referenzmodell erstellen

Auswahl undModifikation derModellierungs-

techniken

Referenz-modellrahmen

definieren

Referenz-modell verfei-nern und ver-vollständigen

Referenzmodell evaluierenund anwenden

RM1

M2M3

Abbildung 3: Subjektivitätsmanagement und Referenzmodellierung

11

Auf der Basis der Identifikation der Modellnutzer sind die Perspektiven zu defi-nieren. Unter einer Perspektive soll hier ein Konstrukt verstanden werden, mit dem ein Modellersteller die unterschiedlichen Subjektivierungen verschiedener Modellnutzer zu berücksichtigen versucht. Da es prinzipiell mindestens genauso viele unterschiedliche Subjektivierungen wie Modellnutzer gibt, wird der Modell-nutzer in der Praxis nicht in der Lage sein, jedem Modellnutzer ein individualisier-tes Modell zur Verfügung zu stellen. Statt dessen versucht er über Perspektiven Clustern von Modellnutzern geeignete Modellvarianten anzubieten. Die Cluster-bildung unterliegt einer Kosten-Nutzen-Abwägung: Indem perspektivenspezifi-sche Modelle zur Verfügung gestellt werden, reduziert sich die Komplexität für den Modellnutzer. Die Akzeptanz der Modelle durch die Modellnutzer wird daher steigen. Andererseits nimmt mit der Berücksichtigung zusätzlicher Perspektiven die Komplexität und damit der Aufwand der konsistenten Wartung und Verwal-tung der Modelle zu. Das Subjektivitätsmanagement wird daher zwangsläufig durch ein Komplexitätsmanagment begleitet.

Bereits der Vergleich der oben genannten Informationssystemarchitekturen zeigt, dass es keine einheitliche Meinung gibt, mittels welcher Abgrenzungskriterien Perspektiven zu definieren sind. Ein geeignetes Raster zur Perspektivenfindung erscheint die Unterscheidung der folgenden drei Dimensionen:

Zwecke: Die Diskussion der multiperspektive Modellierung wird stark von der Dichotomie der Zwecke der Modellanwendung Anwendungssystem- und Organi-sationsgestaltung geprägt [Schü98, Teub99]. Die Anwendungssystemarchitektur MEMO unterscheidet ergänzend zu den Perspektiven Organisation und Informati-onssystem zusätzlich die strategische Perspektive. Der Zweck der Anwendungs-systemgestaltung lässt sich verfeinern beispielsweise in die Auswahl von Standard-Software, Workflowmanagement und Softwareentwicklung, während der Organisationsgestaltung die Zwecke Benchmarking, Zertifizierung, Ge-schäftsprozessmanagment und Wissensmanagement zugeordnet werden können. Mit der Dimension der Zwecke werden die Projektziele spezifiziert.

Rollen: Orthogonal zu der Fragestellung, welche Zielsetzung das Projekt verfolgt, dem der Modellnutzer zugeordnet ist, ist die Unterscheidung der Rolle, die er innerhalb dieses Projektes einnimmt. Innerhalb des Zachman-Framework werden die Rollen Planner, Owner, Designer, Builder und Subcontractor unterschieden. Die Rollen lassen sich auch dahingehend interpretieren, ob der Modellnutzer schwerpunktmäßig mit der Erstellung des Fachkonzepts, des DV-Konzepts oder der Implementierung beauftragt ist, womit die Beschreibungsebenen von ARIS Berücksichtigung finden. Die Orthogonalität der Dimensionen Zwecke und Rollen wird deutlich, wenn man sich vergegenwärtigt, dass die Rolle, die betriebswirt-schaftlichen Anforderungen zu spezifizieren, sowohl im Rahmen eines Wissens-managementprojektes als auch innerhalb eines Softwareentwicklungsprojektes

12

eingenommen werden kann. Die Orthogonalität bedeutet allerdings nicht, dass die Ausprägungen der Dimensionen beliebig kominierbar sind.12

Individuelle Einflüsse: Um im Idealfall eine 1:1-Zuordnung zwischen Perspekti-ven und Subjektivierungen herstellen zu können, sind noch zahlreiche weitere Aspekte relevant, in denen sich Modellnutzer unterscheiden können, wie zum Beispiel Methodenkompetenz aber auch farbliche oder layouttechnische Präferen-zen. Die Dimension der individuellen Einflüsse kann daher lediglich auf diese Residualgrößen verweisen, die allerdings von den anderen beiden Dimensionen dominiert werden dürften.

Bei der Definition der Perspektiven kann der Referenzmodellersteller zu dem Ergebnis gelangen, dass es sinnvoll ist, einzelne der genannten Dimensionen zu vernachlässigen. Für jede der unterschiedenen Perspektiven ist eine Anforde-rungsanalyse durchzuführen, die die wesentlichen Merkmale des perspektivenge-rechten Modellsystems identifiziert. Die Anfordungsanalyse klärt insbesondere die folgenden Fragen [Rose00, S. 55-58; Uthm01, S. 195-197]:

l Welche Gegenstände müssen betrachtet werden?

l Welche Modellierungselemente sind notwendig?

l Wie sind die Modellierungselemente zu interpretieren?

l Welche Modellierungstechniken eignen sich?

l Welche Detaillierungsgrade sind angemessen?

l Welche Präferenzen ergeben sich hinsichtlich der Visualisierung?

l Welche Bezeichnungskonventionen sind zu beachten?

Auch für die Anforderungsanalyse gibt es keinen einheitlichen Rahmen. Dominant für die Einteilung der Betrachtungsgegenstände bzw. Modellelemente erscheint allerdings eine Orientierung an der Systemtheorie, die eine Untergliederung der Anforderungsaspekte nach Struktur und Verhalten nahe legt. In ARIS werden dagegen die Informationsobjekttypen nach den Sichten „Daten“, „Funktionen“, „Prozesse“, „Organisation“ und „Leistungen“ differenziert, wobei Verhaltensas-pekte hauptsächlich der Sicht „Prozesse“ zugeordnet werden. Ein geeignetes Ana-lyseraster stellt insbesondere die Orientierung an Interrogativen dar [Fran94, S. 152-153]. In der ersten Version des Zachman-Frameworks verweisen z. B. die Interrogative „was“, „wie“ und „wo“ auf die Sichten „material“, „function“ und „location“.

12 Vgl. die Kritik von FRANK an der Unterteilung der Organisationssicht in „Fachkon-

zept“, „DV-Konzept“ und „Implementierung“, wie sie in ARIS vorgenommen wird [Fran94, S. 164].

13

Auf der Basis der Anforderungsanalyse ist die Referenzmodellierungstechnik zu definieren. Die Besonderheit der multiperspektiven Referenzmodellierung besteht darin, dass in die Modellierungstechnik Mechanismen integriert werden müssen, die die Separierung der perspektivenspezifischen Modellvarianten erlauben. Die Herausforderung dieser Aufgabe besteht darin, die zahlreichen Möglichkeiten der Perspektivendifferenzierung zu berücksichtigen. Der Fragenkatalog der Anforde-rungsanalyse zeigt, dass prinzipiell alle Aspekte eines Modells Gegenstand der Perspektivendifferenzierung sein können. Aufgrund der komplexen Beziehungen zwischen den Modellteilen muss die Pflege des multiperspektiven Referenzmo-dells werkzeugunterstützt erfolgen. Für die Werkzeugunterstützung ist ein Kon-zept zu entwickeln, das eine flexible Definition und Pflege der Modellvarianten ermöglicht.

4 Werkzeugkonzept

Basis für die Konzeption eines multiperspektiven Modellierungswerkzeugs ist ein Konzept für die Realisierung von Modellprojektionen. Die Modellprojektion ist eine Abbildung einer Instanz eines Modells m1 auf ein anderes Modell m2. Handelt es sich bei der Modellierungssprache um eine Datendefinitionssprache einer rela-tionalen Datenbank wie zum Beispiel SQL, kann eine solche Abbildung immer dann durchgeführt werden, wenn es sich bei dem Modell m2 um eine beschränkte aber syntaktisch und semantisch korrekte Version des Modells m1 handelt. Algo-rithmisch ist die Modellprojektion einer Datenbank zu dem Datenbankmodell m1 auf ein neues Datenbankmodell m2 besonders gut realisierbar, wenn sich das Da-tenbankmodell m2 nur durch neu hinzugefügte Constraints oder entfernte Attribute oder Tabellen vom ausgehenden Datenbankmodell m1 unterscheidet. In diesem Falle kann die Modellprojektion durch das Kopieren der Modellinstanz (also des gesamten Datenbankinhaltes) unter Berücksichtigung der neu hinzugekommenen Contraints bzw. der gelöschten Attribute oder Tabellen realisiert werden. Alterna-tiv zu dem Kopieren ist auch die Programmierung einer Datenbanksicht (View) denkbar.

Ein Werkzeug, welches multiperspektives Modellieren unterstützt, kann die oben genannte Eigenschaft der Modellprojektion zur automatisierten Generierung von Perspektiven nutzen. Zu diesem Zweck verwaltet und speichert das Werkzeug die multiperspektiven Modelle in einer relationalen Datenbank (Repository). Das heißt, die multiperspektiven Modelle sind Instanzen (also Daten) der Datenbank, die durch das Datenbankmodell strukturiert werden. Dieses Datenbankmodell ist gleichzeitig das multiperspektive Metamodell der Modelle. Eine Metamodellpro-jektion der multiperspektiven Modelle ist somit durch eine Modellprojektion der Daten in der Datenbank realisierbar. Konkret heißt das, dass ein beliebiges per-spektivenspezifisches Modell automatisiert generiert werden kann, indem die

14

Perspektive durch ein Datenbankmodell spezifiziert wird. Dieses perspektivenspe-zifische Datenbankmodell sollte sich möglichst nur durch das Hinzufügen von Contraints oder das Weglassen von Attributen oder Tabellen von dem ausgehen-den Datenbankmodell unterscheiden, um eine einfache Realisierbarkeit zu ermög-lichen.

Eine Werkzeugarchitektur, die auf dem Einsatz der Modellprojektion basiert, enthält die folgenden Komponenten (vgl. Abbildung 4): Über den multiperspekti-ven Modelleditor hat der Referenzmodellierer die Möglichkeit, die multiperspek-tiven Modelle im Repository abzulegen und die Perspektiven zu definieren. Das Repository umfasst dabei sowohl die multiperspektiven Modelle als auch die Regelbasis für die verschiedenen Perspektiven und ihre Constraints auf dem mul-tiperspektiven Metamodell. Der Perspektivengenerator ist in der Lage, basierend auf den in der Regelbasis definierten Constraints eine Metamodellprojektion durchzuführen und somit die verschiedenen Perspektiven verfügbar zu machen.

Das Datenmodell des Repositories hält alle für die verschiedenen Perspektiven und Modellierungssprachen notwendigen Daten vor. Der multiperspektive Editor unterstützt den Referenzmodellierer, indem er entweder eine alle Modellierungs-sprachen übergreifende Gesamtsprache anbietet oder die Möglichkeit zur Verfü-gung stellt, Verknüpfungen zwischen Elementen der verschiedenen Modellierungssprachen und Perspektiven zu definieren. Um den Umgang mit den Perspektiven zu erleichtern, sollte die Regelbasis für die verschiedenen Modellie-rungssprachen eine Menge von Standard-Constraints (z. B. für EPK, ERM, Orga-nigramme etc.) zur Verfügung stellen, die über einen Assistenten in Bezug auf perspektivenspezifische Details (z. B. Verzicht auf bestimmte Elemente eines Prozesses etc.) verfeinert werden können.

Multi-perspektiverModelleditor

Modellierungs-techniken desSubjektivitäts-managements

Repository

Multiperspektives Modellund Regelbasis

PerspektivenspezifischesModell 1

Perspektiven-generator

Metamodell-projektion

PerspektivenspezifischesModell 2

PerspektivenspezifischesModell n

...

Abbildung 4: Werkzeugarchitektur für das Subjektivitätsmanagement

15

Nicht-EDI-Rechung isteingetroffen

Nicht-EDI-Rechnungensind sortiert

Nicht-EDI-Rechnungweist keineFehler auf

Nicht-EDI-Rechnungenweist Fehler

auf

EDI-Rechung isteingetroffen

ErfasseRechnung

Rechnungim System

XOR

XOR

XOR

BucheFolge-belege

Rechnungist gebucht

ET

ET

ET

Organisations-gestaltung

A

A

ETAnwendungssystem-gestaltung

B

ETB

Anwendungssystem-gestaltung

C

Sonst

ET C

Sortieremanuell

Nicht-EDI-Rechnungen

Prüfemanuell

Nicht-EDI-Rechnungen

Korrigieremanuell

Rechnung überRücksprachemit Lieferant

ÜbernimmvollautomatischEDI-Rechnung

ins System

Abbildung 5: Perspektivenspezifische Auswahl von Modellteilen

16

Die Spezifikation der perspektivenspezifischen Besonderheiten der Modelle kann grundsätzlich über die Data Manipulation Language des Datenbankmanagement-systems des Repositories erfolgen. Um die Kommunikation zwischen den Refe-renzmodellerstellern zu unterstützen, sollten zusätzlich auch visuelle Darstellungsformen für die Perspektivendifferenzierung unterstützt werden. Ne-ben dem Sprachkonzept für das Repository und die Funktionsweise des Ableitungsmechanismus umfasst das Werkzeugkonzept daher auch die Entwick-lung von Modellierungstechniken, welche die Grundlage der Editorkomponente zur Referenzmodellerstellung bilden. Die Modellierungsaktionen des Editors werden in entsprechende Veränderungen der Inhalte des Repositories umgesetzt.

Einzelne Informationsobjekte innerhalb von Modellen können über sogenannte Buildtime-Operatoren den Perspektiven zugeordnet werden [BHKS00, S. 101]. Mittels der Operatoren kann z. B. in Modellen berücksichtigt werden, dass voll-ständig manuell ausgeführte Tätigkeiten für den Anwendungssystemgestalter keine Relevanz besitzen, während vollautomatisierte Vorgänge für den Organisa-tionsgestalter nicht von Interesse sind (vgl. Abbildung 5). Buildtime-Operatoren können auch für das Mapping von Modellen verwendet werden.13 Zu Buildtime-Operatoren alternative Notationsformen stellen z. B. die Parametrisierung von Modellteilen und die Attributierung von Basisworten dar.14

5 Schlussbemerkungen und Ausblick

Im Rahmen dieses Beitrags wurden als wichtiges Konzept zur Akzeptanzsiche-rung von Referenzmodellen deren multiperspektive Gestaltung vorgestellt. Die detaillierte Umsetzung des vorgestellten Rahmenkonzeptes anhand geeigneter Informationssystemarchitekturen ist Gegenstand des von der Deutschen For-schungsgemeinschaft (DFG) geförderten Projektes „Konstruktion konfigurierbarer Referenzmodelle für die integrierte Anwendungssystem- und Organisationsgestal-tung (KOREAN)“. Insbesondere anhand einer erweiterten Fassung des in Abbil-dung 1 vorgestellten Gesamtmetamodells werden die Operationen zur Definition und Ableitung der perspektivenspezifischen Modelle konkretisiert.

13 Das Konzept des Mappings reagiert auf den Umstand, dass die Lesbarkeit der Model-

le ab einer bestimmten Anzahl von Buildtime-Operatoren leidet. Das Konzept sieht vor, dass Modellvarianten, die sich in vielen Punkten unterscheiden, nicht in einem Modell integriert werden, sondern dass einzelne Modelle geschaffen werden, für die ausgewiesen wird, dass sie sich auf den gleichen Gegenstand beziehen. Da der Mo-dellgegenstand selbst nicht subjektunabhängig (objektiv (im traditionellen abendlän-dischen Sinne)) festlegbar ist, wird hier vorgeschlagen auf seine Spezifikation zu verzichten und stattdessen das Mapping innerhalb eines Modells zu verwalten, das mit einem Buildtime-Operator beginnt und mit einem Buildtime-Operator endet.

14 Zu den Darstellungsalternativen vgl. ausführlicher [BHKS00, S. 99-103].

17

Für die Realisierung des Werkzeugkonzeptes bietet sich grundsätzlich der Rück-griff auf Meta-CASE-Tools an.15 Die Spezifikation der Modellierungstechnik des multiperspektiven Referenzmodells im Meta-CASE-Tool birgt das Potenzial einer Verwendung der Editorkomponenten des Werkzeugs. In der Regel ist eine Erwei-terung der Werkzeuge um die Funktionen der Modellprojektion und spezifischen Konstrukte der Referenzmodellierung vorzunehmen. Mit den entsprechenden Anpassungen erschließen sich in Form der multiperspektiven Referenzmodellie-rung neue Anwendungsperspektiven für Meta-CASE-Tools.

Neben der Formalisierung der vorgestellten Konzepte bietet auch die Entwicklung eines Ansatzes zum Komplexitätsmanagement für die Referenzmodellierung Ent-wicklungspotenziale. Im Rahmen des Komplexitätsmanagements steht der Refe-renzmodellersteller vor der Herausforderung, die exogenen und endogenen Komplexitätstreiber des Referenzmodells zu beherrschen [Blis00, S. 163]. Exoge-ne Komplexitätstreiber ergeben sich aus der Dynamik und Variantenvielfalt des Absatzmarktes (insbesondere in Form der vom Referenzmodell avisierten Klasse von Unternehmen), der mit dem Referenzmodellersteller aktuell oder potenziell im Wettbewerb stehenden Anbieter alternativer Referenzmodelle und der techno-logischen Bedingungen der Referenzmodellierung selbst. Endogene Komplexitäts-treiber sind auf die Beziehungen der Modellteile (insbesondere in Form von Konsistenzbedingungen) zurückzuführen.

Literatur

[BeKR00] Becker, J.; Kugeler, M.; Rosemann, M. (Hrsg.): Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung. 2. Aufl., Berlin et. al. 2000.

[BHKS00] Becker, J.; Holten, R.; Knackstedt, R.; Schütte, R.: Referenz-Informationsmodellierung. In: F. Bodendorf, F.; Grauer, M. (Hrsg.): Ver-bundtagung Wirtschaftsinformatik 2000. Aachen 2000, S. 86-109.

[Blis00] Bliss, C.: Management von Komplexität. Ein integrierter, systemtheoreti-scher Ansatz zur Komplexitätsreduktion. Wiesbaden 2000.

[Chen76] Chen, P. P.: The Entity-Relationship-Model. Toward a Unified View of Data. ACM Transactions on Database-Systems, 1 (1976) 1, S. 9-36.

[Espr89] ESPRIT Consortium AMICE: Open System Architecture for CIM. Berlin et. al. 1989.

15 Meta-CASE-Tools bieten im Vergleich zu CASE-Tools zusätzlich eine Definitions-

umgebung, mit deren Hilfe eigene Modellierungstechniken definiert bzw. existierende angepasst werden. Vgl. u. a. [Heym95, S. 19-70], [JKSK00, S. 392].

18

[Fran94] Frank, U.: Multiperspektivische Unternehmensmodellierung. Theoretischer Hintergrund und Entwurf einer objektorientierten Entwicklungsumgebung. München, Wien 1994.

[Fran99] Frank, U.: Eine Architektur zur Spezifikation von Sprachen und Werkzeuge für die Unternehmensmodellierung. In: E. Sinz (Hrsg.): Modellierung be-trieblicher Informationssysteme. Proceedings der MobIS-Fachtagung 1999. Bamberg 1999, S. 154-169.

[Glas00] von Glasersfeld, E.: Konstruktion der Wirklichkeit und des Begriffs der Objektivität. In: Einführung in den Konstruktivismus. 5. Aufl., München, Zürich 2000, S. 9-39.

[Heym95] Heym, M.: Prozeß- und Methoden-Management für Informationssysteme. Überblick und Referenzmodell. Berlin et. al. 1995.

[JKSK00] Junginger, S.; Kühn, H.; Strobl, R.; Karagiannis, D.: Ein Geschäftspro-zessmanagement-Werkzeug der nächsten Generation – ADONIS: Konzep-tion und Anwendungen. Wirtschaftsinformatik, 42 (2000) 5, S. 392-401.

[KeNS92] Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozeßmodellierung auf der Grundlage „Ereignisgesteuerter Prozeßketten (EPK)“. Veröffentli-chung des Instituts für Wirtschaftsinformatik Nr. 89. Saarbrücken 1992.

[KrSø96] Krogstie, J.; Sølvberg, A.: A Classification of Methodological Frameworks for Computerized Information Systems Support in Organisations. In: S. Brinkkemper, K. Lyytinen, R. J. Welke: Method Engineering. Principles of method construction and tool support. Proceedings of the IFIP TC8, WG8.1/8.2, Working Conference on Method Engineering, 26-28 August 1996, Atlanta, USA. London et. al. 1996, S. 278-295.

[KuRo98] Kugeler, M.; Rosemann, M.: Fachbegriffsmodellierung für betriebliche Informationssysteme und zur Unterstützung der Unternehmenskommunika-tion. In: Fachausschuss 5.2 der Gesellschaft für Informatik e. V. (GI) (Hrsg.): Informationssystem-Architekturen, 5 (1998) 2, S. 8-15.

[Luhm99] Luhmann, N.: Zweckbegriff und Systemrationalität. Über die Funktion von Zwecken in sozialen Systemen. 6. Aufl., Frankfurt am Main 1999.

[MLEM99] Mertens, P.; Ludwig, P.; Engelhardt, A.; Möhle, S.; Kaufmann, T.; Ließ-mann, H.: Ausgewählte Experimente zu Mittelwegen zwischen Individual- und Standardsoftware. In: J. Becker, M. Rosemann, R. Schütte (Hrsg.): Re-ferenzmodellierung. State-of-the-Art und Entwicklungsperspektiven. Hei-delberg 1999, S. 70-106.

[Rose00] Rosemann, M.: Vorbereitung der Prozessmodellierung. In: J. Becker, M. Kugeler, M. Rosemann (Hrsg.): Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung. 2. Aufl., Berlin et. al. 2000, S. 45-90.

[Sche01] Scheer, A.-W., ARIS – Modellierungsmethoden, Metamodelle, Anwendun-gen. 4. Aufl., Berlin et. al. 2001.

19

[Schm00] Schmidt, S. J.: Vom Text zum Literatursystem. Skizze einer konstruktivisti-schen (empirischen) Literaturwissenschaft. In: Einführung in den Konstruk-tivismus. 5. Aufl., München, Zürich 2000, S. 147-166.

[Schü98] Schütte, R.: Grundsätze ordnungsmäßiger Referenzmodellierung. Konstruk-tion konfigurations- und anpassungsorientierter Modelle. Wiesbaden 1998.

[Schü99] Schütte, R.: Basispositionen in der Wirtschaftsinformatik – ein gemäßigt-konstruktivistisches Programm. In: J. Becker, W. König, R. Schütte, O. Wendt, S. Zelewski (Hrsg.): Wirtschaftsinformatik und Wissenschaftstheo-rie. Bestandsaufnahme und Perspektiven. Wiesbaden 1999, S. 211-241.

[Spec01] Speck, M. C.: Geschäftsprozessorientierte Datenmodellierung. Referenz-Vorgehensmodell zur fachkonzeptionellen Modellierung von Informations-strukturen. Münster (Westfalen), Univ., Diss 2001.

[Teub99] Teubner, R. A.: Organisations- und Informationssystemgestaltung. Theore-tische Grundlagen und integrierte Methoden. Wiesbaden 1999.

[Uthm01] von Uthmann, C.: Geschäftsprozesssimulation von Supply Chains. Ein Praxis-Leitfaden für die Konstruktion von Management-orientierten Model-len integrierter Material- und Informationsflüsse. Ghent et. al. 2001.

[Woll86] Wollnik, M.: Implementierung computergestützter Informationssysteme. Berlin, New York 1986.

[Zach87] Zachman, J. A.: A Framework for Information Systems Architecture. IBM Systems Journal, 26 (1987) 3, S. 277-293.

[Zele99] Zelewski, S.: Grundlagen. In: H. Corsten, M. Reiß (Hrsg.): Betriebswirt-schaftslehre. 3. Aufl., München, Wien 1999, S. 1-125.