Qualitätssicherung im CC BAI

Abstract

Der vorliegende Beitrag beschäftigt sich mit dem Thema Qualitätssicherung, welches im Rahmen des CC BAI ebenenübergreifend
betrachtet wurde. Die Zielsetzung bestand darin, die Konstruktion von Referenzmodellen einer Systematik zu unterwerfen, mit
deren Hilfe eine Qualität der erstellten Modelle „produziert“ werden sollte. Im vorliegenden Beitrag wird aufbauend auf einer
Einführung in die Thematik der Grundsätze ordnungsmässiger Referenzmodellierung die konkrete Anwendung des Frameworks auf
die im CC BAI untersuchte Problematik von Informationsarchitekturen von Banken vorgestellt.

Full text

Qualitätssicherung im CC BAI
Dr. Reinhard Schütte
Universität Essen
Institut für Produktion und Industrielles Informationsmanagement
Prof. Dr. St. Zelewski
D – 45141 Essen
E-Mail: Reinhard.Schuette@pim.uni-essen.de
Gregor Zellner
Universität St. Gallen
Institut für Wirtschaftsinformatik
Prof. Dr. R. Winter
CH – 9000 St. Gallen
E-Mail: Gregor.Zellner@unisg.ch
Zusammenfassung: Der vorliegende Beitrag beschäftigt sich mit dem Thema Qua-
litätssicherung, welches im Rahmen des CC BAI ebenenübergreifend betrachtet
wurde. Die Zielsetzung bestand darin, die Konstruktion von Referenzmodellen
einer Systematik zu unterwerfen, mit deren Hilfe eine Qualität der erstellten Mo-
delle „produziert“ werden sollte. Im vorliegenden Beitrag wird aufbauend auf
einer Einführung in die Thematik der Grundsätze ordnungsmässiger Referenzmo-
dellierung die konkrete Anwendung des Frameworks auf die im CC BAI unter-
suchte Problematik von Informationsarchitekturen von Banken vorgestellt.
Schlüsselworte: Qualitätssicherung, Konventionen, Qualitätskriterien, Geschäfts-
modell, Referenzprozessmodell, Applikationsebene

1. Einleitung
Im Rahmen des CC BAI wurde versucht auf jeder der drei Ebenen (Geschäftsebe-
ne, Prozessebene und Applikationsebene) ein Modell im Sinne einer Referenz zu
konstruieren. Um die Vorgehensweise qualitativ abzustützen, fanden die Grunds-
ätze ordnungsmässiger Referenzmodellierung nach [Schütte 1998] Berücksichti-
gung bei der Erstellung der Modelle auf der jeweiligen Ebene. Es wird zunächst
auf den Nutzerkreis und den Verwendungszweck von Informationsmodellen ein-
zugehen sein, um danach die mit der Qualitätssicherung verfolgten Ziele und die
Massnahmen zur Erreichung derselben zu erörtern.
Der Beitrag stellt in den Kapiteln 2 bis 4 zunächst die theoretische Basis für das
Konzept der Qualitätssicherung dar, um dann in Kapitel 5 die Anwendung und
Umsetzung im Rahmen des CC BAI aufzuzeigen. Dabei werden die einzelnen
Ebenen Geschäftsebene (Kapitel 5.1), Prozessebene (Kapitel 5.2) und Applikati-
onsebene (Kapitel 5.3) betrachtet. Kapitel 6 gibt eine Zusammenfassung der The-
matik.
2. Zwecke und Nutzer von Referenzmodellen
Bei einer Spezifikation der Verwendungszwecke von Referenzmodellen sind u. a.
folgende Verwendungsbereiche zu differenzieren [Rosemann, Schütte 1999], die
sich in Praxisprojekten als wesentliche Zwecke für den Einsatz von Referenzpro-
zessmodellen herausgestellt haben.
2.1. Zwecke der Anwendungssystemgestaltung
Auswahl von Standardsoftware
Sofern die unternehmensspezifischen Anforderungen einerseits und die Möglich-
keiten der Standardsoftware andererseits in Modellform vorliegen, wird ein Mo-
dellvergleich - in Grenzen - möglich. Die wesentlichen Probleme eines Modellver-
gleichs sind i. d. R. die nicht korrespondierenden Detaillierungsgrade der Modelle
und die Modellsemantik, die sich insbesondere durch fehlende gemeinsame Be-
griffs- und Namenskonventionen einem Vergleich entzieht.
Referenzmodellbasiertes Customizing
In Standardsoftwarepaketen sind in unterschiedlichem Umfang bereits Lösungen
vorhanden, mit denen die Konfiguration der Software durch ein Modellcustomi-
zing möglich ist. Auf diese Weise wird der Software-Einführungsprozess be-
schleunigt und qualitativ hochwertiger, da Domänenwissen ohne zusätzliches

technisches Wissen für die Softwareeinführung - in weiten Bereichen - ausrei-
chend ist. Die Verantwortung für das Customizing kann damit stärker den Fach-
vertretern übertragen werden.
Softwareentwicklung
Tradiertes Einsatzgebiet von Informationsmodellen ist das Software Engineering.
Durch die Ermittlung der Anforderungen auf der Basis von Referenzmodellen und
deren sukzessiven Formalisierung entstehen Dokumente, die den Ausgangspunkt
einer softwaretechnischen Umsetzung bilden können.
Workflowmanagement
Der automatisiert steuerbare Teil eines Prozessmodells wird als Workflow be-
zeichnet. Referenzmodelle können als Grundlage für die Identifikation und Spezi-
fikation von Workflows dienen. Dazu sind sie u. a. um die unternehmensin-
dividuellen Organisationseinheiten, insb. die Rollen, um Datenstrukturen und um
die eingebetteten Applikationen anzureichern. Im Vergleich zu Geschäftsprozess-
modellen weisen sie eine feinere Granularität auf.
Simulation
Die Simulation dient der Untersuchung des Systemverhaltens im Zeitablauf. Sie
unterstützt zum einen die Identifikation von Schwachstellen, die sich bei einer
reinen Modellbetrachtung nicht offenbaren (z. B. unzureichende Kapazitätsauslas-
tung, hohe Liegezeiten). Zum anderen soll durch die Simulation aus einer gegebe-
nen Menge von Handlungsalternativen die optimale ausgewählt werden. Damit die
Simulation durchgeführt werden kann, sind Zeit-, Mengen- und Kostendaten und
die Ressourcenverfügbarkeit im Simulationsmodell zu spezifizieren.
2.2. Zwecke der Organisationsgestaltung
Geschäftsprozessmanagement
In der Popularität des Verwendungszwecks Geschäftsprozessmanagement ist der
wesentliche Grund für die hohe Verbreitung und Akzeptanz von Prozessmodellen
zu sehen. Existentiell sind hierfür anschauliche Prozessmodelle, damit sich beste-
hende Schwachstellen schnell erschliessen lassen. Zugleich müssen die Modelle
aber auch hinreichend formal sein, um beispielsweise den Vergleich von Soll- und
Ist-Modellen zu erlauben.
Zertifizierung nach DIN ISO 9000ff.
Die erfolgreiche Zertifizierung eines Unternehmens nach DIN ISO 9000ff. setzt
vor allem eine umfassende Dokumentation voraus, so dass sich insbesondere Or-

ganisations- und Prozessmodelle für diese Aufgabe empfehlen. Durch die Verwal-
tung der entsprechenden Aktivitäten in einem zentralen Repository sind Änderun-
gen bei einem Aufgabentyp nur einmalig und nicht mehrmalig vorzunehmen, wie
dies bei einer rein textuellen Beschreibung der Fall ist (dort ist eine Aufgabe, die
in unterschiedlichen Kontexten benötigt wird, in jeder Kontextsituation zu än-
dern). Sofern Textdokumente erforderlich sind, wie für die Erstellung der Ablauf-
beschreibungen und Arbeitsanweisungen eines Qualitätsmanagementhandbuchs,
kann mit den heutigen informationstechnischen Möglichkeiten aus den graphi-
schen Beschreibungsformen der erforderliche Text generiert werden. Ein Refe-
renzmodell, welches die Zertifizierung unterstützen soll, muss an die unterneh-
mensindividuellen Gegebenheiten anpassbar sein, eine möglichst anschauliche
Modellierungsmethode verwenden und tool-technisch die Referenz bzw. sogar die
Erstellung von Verfahrensanweisungen sowie das Generieren von entsprechenden
Reports ermöglichen.
Benchmarking
Beim Benchmarking werden Vergleichszahlen als Referenzpunkte (sog. Bench-
marks) konkreten Unternehmenszuständen gegenübergestellt. Die Anreicherung
von Referenzmodellen um derartige Benchmarkinganforderungen fördert den
Sollcharakter von Referenzmodellen, weil durch die Ergänzung um Best-Practice-
Angaben der Nutzen der Modellumsetzbarkeit erhöht wird. Soll das Referenzmo-
dell für die Zwecke des Benchmarking verwendet werden, sind Attribute vorzuse-
hen, welche die Pflege von Best-of-Breed-Mengengerüsten erlauben.
Wissensmanagement
Das Wissen über betriebliche Gegebenheiten in einer einheitlichen Form zu expli-
zieren hat den Vorteil, dass alle Aufgabenträger auf diesen Wissensfundus zugrei-
fen können. Die Explikation von Wissen (für die Wissensbewahrung und die Wis-
sensverteilung) ist damit notwendige Voraussetzung des Wissensmanagements. Je
nach Anwendungssituation sind unterschiedliche Sprachen für die Wissensreprä-
sentation geeignet. Im betriebswirtschaftlichen Kontext hat sich gezeigt, dass
semi-formale Beschreibungssprachen i. d. R. geeignet sind, Wissen über die be-
triebliche Realität in Modellform darzustellen. Modelle eignen sich aus diesem
Grund auch für die Einarbeitung in betriebliche Sachverhalte und die Schulung.
Referenzmodellen kommt dabei eine hohe Bedeutung für die frühen Phasen des
Wissensmanagement bei (Wissensakquisition).
Neben dem jeweiligen Verwendungszweck, besitzen bestimmte Charakteristika
der in den Modellerstellungs- bzw. -nutzungsprozess involvierten Person(en)
signifikanten Einfluss auf die notwendige Modellausgestaltung. Hierzu zählen
primär die methodische Kompetenz (z. B. Vertrautheit mit Modellierungstech-
niken) sowie die Rolle, welche die Person einnimmt. Die methodische Kompetenz
ist von hoher Relevanz bei der Auswahl einer adäquaten (hier im Sinne einer ver-
ständlichen) Sprache; die von der Person eingenommene Rolle determiniert den

Blickwinkel auf die Modellinhalte. So wird beispielsweise der Geschäftspartner
eines Unternehmens einen Prozess als „black-box“ begreifen (funktionale System-
sicht), während das Unternehmen, in dessen Kontrollsphäre sich der Prozess be-
findet, den Prozess zumeist aus strukturaler Sicht betrachtet. Somit muss neben
dem Verwendungszweck auch eine Personenorientierung bei der Modellkon-
struktion berücksichtigt werden.
3. Ziele
Ziele dienen der Bewertung von Modellierungsmassnahmen, damit eine zielge-
richtete Bewertung von Massnahmen zur Verbesserung der Modellqualität vorge-
nommen werden kann. Nachfolgend werden Zielklassen bzw. Ziele skizziert, die
in konkreten Projekten übernommen oder den spezifischen Bedingungen entspre-
chend angepasst werden können. Insbesondere ist auch festzulegen, welche Be-
deutung die einzelnen Ziele und Zielklassen besitzen, um eine Gewichtung der
Ziele vornehmen zu können. I.d.R. wirken die in Kapitel 4 skizzierten Massnah-
men auf mehrere Ziele, so dass eine Gewichtung der Ziele untereinander unver-
zichtbar ist, um zu einer rationalen Auswahl der Modellierungsmassnahmen zu
gelangen. Ein wichtige Bedeutung haben hierbei die in Kapitel 2 skizzierten Mo-
dellierungszwecke, da zumeist die Gewichtung der Ziele von den verfolgten Zwe-
cken abhängt. Die Ziele für die Referenzprozessmodellierung sind vor allem die
Konstruktions-, die Sprachadäquanz, die Wirtschaftlichkeit, die Klarheit, der sys-
tematische Aufbau und die Vergleichbarkeit (vgl. im folgenden [Schütte 1998]
sowie zu anderen Ansätzen u.a. [Batini et al. 1992], [Moody/Shanks 1994],
[Moody/Shanks 1998]).
3.1. Konstruktionsadäquanz
Bei dem Grundsatz der Konstruktionsadäquanz wird auf die angemessene Mo-
dellkonstruktion fokussiert. Die Konstruktionsqualität eines Modells bedingt aus
Sicht des Anwenders zum einen, dass über das im Modell zu repräsentierende
Problem Konsens besteht (Kriterium der Problembestimmung (K1)1). Dieser kann
erst durch eine Befragung der Betroffenen geprüft werden. Neben dem Konsens
über das zu konstruierende Problem bedarf es auch des Konsenses über die Art der
Konstruktion, d. h. es ist ein Konsens über die Modelldarstellung herzustellen
(Kriterium der Problemrepräsentation (K2)). Es ist die Eindeutigkeit der Informa-
tionsobjekte zu fordern, derzufolge Informationsobjekte immer in der gleichen Art
und Weise verwendet werden. Zur Eindeutigkeit gehört die kontextinvariante Mo-
1 Mit K1 bis K7 werden diejenigen Qualitätskriterien markiert, welchen in Kapitel
5.1.3. Massnahmen zur Zielerreichung zugeordnet werden.

dellierung von Problemen. Die im Rahmen der Integration von Modellen unter-
suchten Konflikte unterschiedlicher Modellrepräsentationen eines realen Sachver-
haltes belegen die Bedeutung von Konventionen und die Subjektivität der Modell-
konstruktion. Ein Modellkonsens dient damit der Berücksichtigung von Intra- und
Inter-Modellbeziehungen, die auf die Anwendung einheitlicher Modellierungs-
konstrukte für gleiche Sachverhalte abzielen. Intra-Modellbeziehungen zielen auf
die einheitliche Anwendung von Konstrukten innerhalb eines Modells ab. Inter-
Modellbeziehungen zielen auf die einheitliche Darstellung realer Sachverhalte in
unterschiedlichen Modellen einer Modellierungssicht ab. Die Konstruktionsadä-
quanz betrachtet nicht den Zusammenhang zwischen Modellen unterschiedlicher
Modelltypen im Sinne der vorgenommen Trennung von Struktur- und Verhaltens-
modellen, da dieser Gegenstand des Grundsatzes des systematischen Aufbaus ist.
3.2. Sprachadäquanz
Die Modellerstellung erfolgt mit Hilfe einer (künstlichen) Sprache, die der Kon-
kretisierung eines Gegenstands dient, so dass an die Stelle der Gegenstände die
Wörter treten. Somit sind die Gegenstände das, was mit einem Wort der Sprache
bezeichnet wird. Dies führt dazu, dass wir nicht mehr über die Realität an sich
sprechen, sondern über die Sprache. Während der Grundsatz der Konstruktions-
adäquanz das Kriterium zur Bewertung der Problemrepräsentation im Modell
darstellt, wird beim Grundsatz der Sprachadäquanz die Relation zwischen dem
Modellsystem und der verwendeten Sprache betrachtet. Hierzu zählen die Sprach-
eignung und die Sprachrichtigkeit. Die Spracheignung betrifft insbesondere die
problembezogene Auswahl der Modellierungstechnik und die Selektion relevanter
Modellierungskonstrukte. Das Problem und der Modellierungszweck determinie-
ren die erforderliche semantische Mächtigkeit einer Modellierungsmethode (Krite-
rium der semantischen Mächtigkeit (K3)). Der Einsatzzweck des externen Modells
erfordert mitunter einen bestimmten Formalisierungsgrad der Sprache, damit bei-
spielsweise Simulationen durchgeführt werden können. Die bei einem Modell-
adressaten vorhandenen Kenntnisse, die auch die bisherigen Erfahrungen mit Mo-
dellierungstechniken umfassen, determinieren in Form der Sprachverständlichkeit
die subjektive Eignung einer Sprache. Dem Kriterium der Sprachverständlichkeit
ist auch die verfügbare Werkzeugunterstützung zuzuordnen. Die Sprachrichtigkeit
betrachtet die korrekte Anwendung der Sprachsyntax, d. h. der Grammatik. Die
Anwendung einer Sprache erfüllt die Forderung nach Richtigkeit, wenn sie den
Vorgaben des Metamodells gehorcht, d. h. wenn das Modell vollständig und kon-
sistent zum Metamodell ist.
3.3. Wirtschaftlichkeit
Mit dem Grundsatz der Wirtschaftlichkeit wird eine ökonomische Restriktion
formuliert. Jede Tätigkeit in ökonomischen Institutionen ist dem Wirt-

schaftlichkeitspostulat zu unterwerfen. Diese generelle Maxime gilt auch für die
Informationsmodellierung. Negativ wirken sich die durch Informationsmodelle
hervorgerufenen Kosten aus, während positiv die durch Informationsmodelle
möglichen Kostensenkungen und Erlössteigerungen zu bewerten sind. Der Grund-
satz der Wirtschaftlichkeit stellt häufig eine Restriktion dar, die der Modellie-
rungsintensität eine obere Grenze setzt. Der Grundsatz der Wirtschaftlichkeit ist
i. d. R. konfliktär zu den anderen Grundsätzen. Die Forderung nach Wirtschaft-
lichkeit lässt sich unmittelbar auf die genannten Grundsätze beziehen und besitzt
besondere Bedeutung hinsichtlich der Konsensfindung. Die verwendete Sprache
verursacht mit der Kompliziertheit ihrer Anwendung Kosten. Verständliche Spra-
chen erlauben eine schnellere Modellierung von Sachverhalten. Gegenteilige öko-
nomische Tendenzen sind u. a. möglich, wenn die Modellierung einer Sprache
nicht die erforderliche semantische Mächtigkeit aufweist, so dass für den inten-
dierten Zweck “Nacharbeiten” zu einem späteren Zeitpunkt erforderlich werden
(Kriterium der Modellrobustheit (K4)). Die Wirtschaftlichkeit eines Modells wird
erhöht, wenn eine Übersetzung einer Sprache in eine andere erfolgen kann, vo-
rausgesetzt die Übersetzung ist für das Modellierungsprojekt erforderlich. Die
sichtenübergreifenden Aspekte des systematischen Aufbaus eines Modells deter-
minieren den Grundsatz der Wirtschaftlichkeit in Abhängigkeit von der verfolgten
Zielsetzung des Modelleinsatzes, da bei bestimmten Modellierungszwecken be-
wusst sichtenübergreifende Zusammenhänge zu vernachlässigen sind.
3.4. Klarheit
Der Grundsatz der Klarheit bezieht sich auf die Verständlichkeit und die Eindeu-
tigkeit von Modellsystemen. Unter der Klarheit werden die Ziele der adressaten-
gerechten Hierarchisierung, Layoutgestaltung und Filterung subsumiert. Für grö-
ssere Informationsmodelle, die mehrere hundert Informationsobjekte beinhalten,
sollte die Hierarchisierung (Dekomposition) genutzt werden, damit das Modell-
system auf unterschiedlichen Abstraktionsebenen verständlich bleibt. Bei der
Bildung von Hierarchien sind Kriterien (z. B. organisations- oder anwendungssys-
tembezogene Betrachtung, struktur- oder verhaltensorientierte Betrachtung, Kon-
zentration auf Güter- oder auf Informationsflüsse, Ausrichtung auf spezifische
Modellanwender) zu fordern, die in den Modellsystemen einheitlich angewendet
werden, da die Verständlichkeit umfassender Modellsysteme dadurch erhöht wird.
Die Verständlichkeit der Layoutgestaltung bezieht sich auf die graphische Anord-
nung der Informationsobjekte im Raum und unterstützt damit insbesondere die
Deutlichkeit eines Modells. Beispielsweise können die Minimierung der Kanten-
überschneidungen, die vertikale oder horizontale Modellausrichtung, die Symmet-
rie der Informationsobjekte des Modells oder weitere Kriterien formuliert werden,
um die Modellanschaulichkeit zu erhöhen. Unter der Verständlichkeit der Filte-
rung wird hier die adressatengerechte Aufbereitung eines Modells verstanden.
Filterungen nehmen im Gegensatz zu Verdichtungen, die von der Semantik ab-

strahieren, eine Einschränkung der enthaltenen Semantik vor, da die potentiellen
Aussagen des Modells reduziert werden. Es können inhaltliche (unterschiedliche
Detaillierungsgrade eines Sachverhaltes) und methodische Filter (Konfiguration
des Metamodells) differenziert werden.
3.5. Systematischer Aufbau
Der Grundsatz des systematischen Aufbaus trägt der allgemein akzeptierten Diffe-
renzierung der Modellierung in unterschiedliche Sichten Rechnung. Informati-
onsmodelle beschreiben den logischen Aufbau von Struktur und Verhalten von In-
formationssystemen. Somit konkretisiert der Grundsatz des systematischen Auf-
baus die Forderung nach einer Inter-Modellkonsistenz zwischen Struktur- und
Verhaltensmodellen. Dies erfordert notwendigerweise ein sichtenübergreifendes
Metamodell, damit ein Modell der Verhaltenssicht auch ein entsprechendes struk-
turelles Pendant erzwingt und umgekehrt. Sichtenübergreifende Metamodelle
beschreiben die für die Struktur- und Verhaltenssicht verwendete Modellsprache.
Der Forderung nach gleichzeitiger Berücksichtigung von strukturellen und verhal-
tensorientierten Aspekten dient beispielsweise die einheitliche Verwendung von
Informationsobjekten in der struktur- und der verhaltensorientierten Sicht.
3.6. Vergleichbarkeit
Der Grundsatz der Vergleichbarkeit zielt auf den semantischen Vergleich zweier
Modelle ab, d.h. es sollen die mit zwei Modellen beschriebenen Inhalte hinsicht-
lich ihrer Deckungsgleichheit untersucht werden. Der Modellvergleich kann auf
Ebene des Modell- und auf Ebene des Metamodellsystems erfolgen. Ein Vergleich
zweier Modellsysteme erfordert den Abgleich der den jeweiligen Modellen zu-
grundeliegenden Probleme. Die Modelle sind vergleichbar, wenn Äquivalenzrela-
tionen zwischen den miteinander verglichenen Modellen angegeben werden kön-
nen. Ein Vergleich auf Metamodellebene ist nur dann gegeben, wenn die unter-
schiedlichen Sprachen, d.h. die Metamodelle oder Grammatiken, “kompatibel” zu-
einander sind.
4. Konventionen
In konkreten Modellierungsprojekten sind zur Erreichung der im vorhergehenden
Kapitel skizzierten Ziele Konvention (Massnahmen) zu ergreifen. Aufgrund der
Erfahrungen aus diversen Projekten hat sich herauskristallisiert, dass eine Unter-
scheidung zwischen Referenz-Konventionen, die unabhängig von einem konkre-
ten Modellierungstool gültig sind, und an Tools orientierten Konventionen sinn-

voll ist. Dabei werden in den nachfolgenden Kapitel exemplarisch solche Konven-
tionen beschrieben, die eine gewisse Allgemeingültigkeit besitzen. Dem Modellie-
rer in einem konkreten Modellierungsvorhaben wird somit ein „Baukasten“ von
Konventionen geboten, aus dem er die für sein spezifisches Projekt wichtigsten
Konventionen selektieren kann.
4.1. Tool-unabhängige Referenz-Konventionen
Bei den Tool-unabhängigen Konventionen werden Namenskonventionen, Be-
griffsbausteine, Referenzmodelle, Layoutkonventionen und die Modellhierarchi-
sierung unterschieden [vgl. Schütte 1998].
Namenskonventionen
Unter Namenskonventionen werden die syntaktischen Regeln zur Benennung der
Modellierungskonstrukte der einzelnen Beschreibungssprachen verstanden. Bei
der Auswahl mehrerer Beschreibungssprachen berücksichtigen die Namenskon-
ventionen auch die Inter-Sprachen-Aspekte der Benennung.
In Abbildung 1 ist ein Beispiel enthalten, in dem ein Prozessmodell ohne Na-
menskonventionen einem mit der Einhaltung von Namenskonventionen gegen-
übergestellt wird.
Die Buchung
der Bestands-
veränderung ist
durchgeführt
worden
Die Prüfung
des Transport-
verlaufsfindet
statt
Kommissio-
nierung
XOR
Aktions-WE
wurde geprüft
und anschlie-
ßend erfaßt
Die Prüfung hat
stattgefunden
Bestands-
veränderung
ist gebucht
Prüfe
Transport-
verlauf
Transport-
verlauf ist
geprüft
Kommissio-
nierung
XOR
Aktions-WE
ist geprüft
und erfaßt
Prozessmodell unter
Missachtung der GoM
(keine Namenskonventionen)
Prozessmodell unter
Einhaltung der GoM
(Namenskonventionen)
Abbildung 1: Beispiel für die Einhaltung von Namenskonventionen

Begriffsbausteine
Unter Begriffskonventionen werden Regeln aufgestellt, mit welcher Semantik
bestimmte Benennungen verbunden sind. Beispielsweise sollten Wortbestandteile
in einem fest definierten Sinn verwendet werden, so dass eine einheitliche Wort-
bestandteilsbenennung von Informationsobjekten sichergestellt wird
Nutzung von Referenzmodellen
• Nutzung von Strukturbausteinen
Eine wichtige Aufgabe zur Beherrschung der Komplexität von Informations-
modellen liegt in der Identifikation und Nutzung von Strukturanalogien, d.h.
solcher Kombinationen von Informationsobjekten, die die gleiche Struktur in
unterschiedlichen Kontexten besitzen. Beispielsweise besitzen die Prozesse
„Kundenzahlung“ und „Lieferantenbezahlung“ die gleiche Struktur, so dass
Strukturanalogien bei der Modellkonstruktion genutzt werden sollten. Eine
Reihe von Strukturanalogien existiert bereits, sie werden in Form einer Bau-
steinbibliothek auf Modellebene dem Modellierer zur Verfügung gestellt. Das
Tool hält Strukturanalogien für diverse Sprachen bereit, so dass die Vergleich-
barkeit von Modellen, die mit unterschiedlichen Sprachen erstellt wurden, ver-
bessert wird. Zudem können Strukturbausteine durch ihre Mehrfachverwen-
dung zu einer Verbesserung der Wirtschaftlichkeit des Modellerstellungspro-
zesses beitragen. Beispielsweise sind die Kreditoren- und die Debitorenzah-
lung ebenso strukturanalog, wie die Belegstrukturen des Beschaffungs- und
des Distributionsprozesses im Handel (vgl. Abbildung 2).
Geschäftspartner
Lieferant
Zeit
Lieferanten-
anfrage-
kopf
Lieferanten-
angebots-
kopf
(0,m)
(0,m)
(0,m)
Bestell-
kopf
(0,m)
(0,m)
(0,m)
(0,m)
(0,m)
(0,m)
(0,m)
(0,m)
WE-
kopf
(0,m)
(0,m)
Lieferanten-
rechnungs-
kopf
Lieferanten-
zahlun gs-
kopf
(0,m)
(0,m)
(0,m)
(0,m)
(0,m)
(0,m)
(0,m)
Geschäftspartner
Abnehmer
Zeit
Abnehmer-
anfrage-
kopf
Abnehmer-
angebots-
kopf
(0,m)
(0,m)
(0,m)
Abnehmer-
auftrags-kopf
(0,m)
(0,m)
(0,m)
(0,m)
(0,m)
(0,m)
(0,m)
(0,m)
Kommis-
sionierauf-
tragskopf
(0,m)
(0,m)
Abnehmer-
lieferschein-
kopf
Abnehmer-
rechnungs-
kopf
(0,m)
(0,m)
(0,m)
(0,m)
(0,m)
Abnehmer-
zahlungs-
kopf
(0,m)
(0,m)
(0,m)
(0,m)
Abbildung 2: Strukturanalogien zwischen Beschaffungs- und Distributionsprozess
• Nutzung semantisch mächtigerer Modellierungskonstrukte
Im Datenmodell geben die Kardinalitäten in der (min, max)-Notation, die un-

bedingt verwendet werden sollten, eine genaue Darstellung des betriebswirt-
schaftlichen Objektsystems. Viel Information geht verloren, wenn die Kardina-
litäten überhaupt nicht oder nur in der (häufig anzutreffenden) max-Notation
angegeben werden. In der max-Notation wäre die Zuordnung eines Artikels
zur Warengruppe 1:m. In der (min, max)-Notation ist die Zuordnung eine
(1,1):(0,m)-Beziehung, d.h. jeder Artikel muss einer Warengruppe zugeordnet
sein. Der Artikel ist damit existentiell abhängig von der Warengruppe. Auch
eine m:m-Beziehung zwischen Lieferschein und Bestellung gibt Freiheitsgrade
vor, die möglicherweise (wenn die Minimalkardinalität 1 beträgt) nicht gege-
ben sind, so dass bei einem Verzicht auf die (min, max)-Notation ein Verstoss
gegen den Grundsatz der semantischen Richtigkeit vorliegen würde.
Layoutkonventionen
Dem Grundsatz der Klarheit tragen horizontale und vertikale Anordnungsbezie-
hungen Rechnung. Beispielsweise sollen die Objekte des Datenmodells entspre-
chend ihrer Existenzabhängigkeit von links nach rechts angeordnet werden. Unter
Massgabe dieser Vorschrift ist beispielsweise die Anzahl an Kantenkreuzungen zu
minimieren, wie dies anschaulich in Abbildung 3 dargestellt wird.
Prüfe Art der
MTV-
Abwic klu ng
Abneh mer-
retoure
Ware ist
zum Versand-
bereich tran s-
portier t
Retouren-
auftr. ist als
Rückl.
gekennz .
Abneh mer
ist benach-
richtigt
Prüfe, ob
Retoure
zurückgeliefert
wird
Retoure ist
vorhanden
Keine
Retoure
vorhanden
XOR
XOR
Prüfe Art der
MTV-
Abwicklu ng
Abnehmer-
retoure
Ware ist
zum Versand-
bereich trans-
portiert
Retouren-
auftr. ist als
Rückl.
gekennz.
Abnehmer
ist benach-
richtigt
Prüfe, o b
Retoure
zurückgeliefert
wird
Retoure ist
vorhanden
Keine
Retoure
vorhanden
XOR
XOR
Ohne Einhaltung der GoM Mit Einhaltung der GoM
Abbildung 3: Beispiel für die Einhaltung des Grundsatzes der Klarheit bei der EPK

Hierarchisierung
Die Hierarchisierung von Modellen stellt eine der wichtigsten und zugleich
schwierigsten Aufgaben bei der Modellierung dar. Es sollten einheitliche Kriterien
der Dekomposition von Modellen definiert werden, die sich entweder an psycho-
logischen Erkenntnissen (nicht mehr als 7 Modellelemente je Modellhierarchie-
ebene) oder an inhaltlichen Kriterien ausrichtet (z. B. Auftrag, Bestellung etc. als
Cluster für damit zusammenhängende Objekte in einem Datenmodell). Aufgrund
der Vielschichtigkeit der Aufgabe und der Abhängigkeit der Hierarchisierung vom
Modellierungszweck (z. B. Ist- vs. Sollmodell) wäre in einem konkreten Projekt
die Festlegung der Dekompositionskriterien vorzunehmen (zu bewerten).
4.2. Tool-abhängige Referenz-Konventionen
Aufgrund der Spezifität der tool-abhängigen Konventionen sollen nachfolgend für
das ARIS-Toolset als dem am weitverbreitetsten Tool nur exemplarische Konven-
tionen skizziert werden, die in einem konkreten Projekt wesentlich detaillierter
auszuarbeiten wären, um einen unnötigen Wildwuchs bei der Tool-Nutzung zu
vermeiden [vgl. auch zu detaillierten Hinweisen für das Toolset Be-
cker/Kugeler/Rosemann (2001)].
Ein grundsätzliches Problem in den meisten Tools stellt die Ablage von Modellen
in einer Verzeichnisstruktur dar. Es wäre beispielsweise denkbar, folgende Struk-
turierung zu wählen:
• Fachbegriffe
• Soll-Modellierung
o Risikomanagement
o Cash Management
• Ist-Modellierung
Die Gruppe Fachbegriffe ist die einzige Gruppe, in der nur Fachbegriffe angelegt
werden. Die Soll-Modellierung umfasst eine verfeinerte Darstellung anhand der
wichtigsten Funktions- / Prozessbereiche. Alternativ wäre es auch denkbar, dass
diese Bereiche auf der obersten Gliederungsebene angeordnet werden.
Weitergehende Konventionen können die Definition der verwendeten Modellie-
rungsobjekte (Ereignis, Funktion, Datenobjekt, Beziehungsobjekt, Stelle, etc.)
mitsamt Beispielen sowie konkrete Regeln für die Wahl der Farben von Modellie-
rungsobjekten oder den Abstand dieser betreffen.

5. Die Anwendung im CC BAI
Das oben beschriebene Vorgehen fand im Sinne einer Absicherung der Qualität
bei Modellierungsprojekten im CC BAI Verwendung. Ausgehend von einem
Verwendungszweck der Modellierung und einem für das Modell bestimmten
Nutzerkreis wurden Ziele zur Realisierung der Modellqualität bestimmt, welche
durch Einführung abgestimmter Konventionen erreicht werden sollten. Die ge-
troffenen Massnahmen wirken hierbei bereits bei der Erstellung der Modelle qua-
litätssichernd („Qualitätsproduktion“) und werden nicht nur ex post geprüft
(„Qualitätskontrolle“).
Die erläuterte Qualitätssicherung konnte auf Geschäfts- und Prozessebene CC
BAI-begleitend eingebunden werden. Auf der Applikationsebene fand Qualitätssi-
cherung im Sinne einer „Zwischen-Kontrolle“ statt. D.h. der bisherige Stand der
Modellierung auf Applikationsebene wird an Hand des Vorgehens zur Qualitätssi-
cherung überprüft. Auf der Grundlage dieser Ergebnisse kann in einem nachgela-
gerten Schritt das Modell angepasst werden.
5.1. Anwendung auf Geschäftsebene
Ziel auf Geschäftsebene war es, mittels einer klassifikatorischen Beschreibung die
Geschäftskonzeption bzw. -charakteristik der Rolle des Service Integrators zu
beschreiben bzw. unterschiedliche Geschäftstypen für den Service Integrator zu
konzipieren und abzubilden. Auf Basis eines zu entwickelnden Beschreibungsmo-
dells sollte dann eine Typologisierung von Geschäftskonzepten erarbeitet werden.
Dabei stand die Darstellung der Organisation aus einer rein zustandsorientierten
Betrachtung im Vordergrund [vgl. Heinrich 2000, S. 3-6].
Um die Qualität des zu entwickelnden Modells zur Typologisierung von Ge-
schäftskonzepten prüfen zu können, wurden als Kriterien die allgemeinen Grunds-
ätze ordnungsmässiger Modellierung (GoM), wie in den vorangegangen Kapiteln
ausgeführt, angewendet. Im Sinne einer Spezialisierung dieser GoM wurden von
Heinrich unter anderem folgende, zusätzliche Anforderungen in die Qualitätssi-
cherung mit einbezogen [vgl. Heinrich 2000, S. 7,8]:
• Kriterium der Kommunizierbarkeit (K5): Die im Modell dargestellten Inhalt
müssen leicht verständlich und zugänglich sein. Diese Kriterium kann aus
dem „Grundsatz der Spracheignung“ (vgl. Kapitel 3.2.) der GoM abgeleitet
werden.
• Kriterium der Redundanzfreiheit bzw. Minimalität (K6): In Anlehnung an das
Kriterium der „Minimalität“ der GoM (Konstruktionsadäquanz, vgl. Kapitel
3.1.) soll die Beachtung dieses Kriteriums die mehrfache Darstellung gleicher
Informationen - also Redundanzen - zu vermeiden helfen.

• Kriterium der Rollenunabhängigkeit (K7): Neben der Rolle des Service In-
tegrators soll der Modellansatz auch auf die anderen Rollen des Visionsmo-
dells2 übertragbar sein.
Die nachfolgenden Ausführungen dienen dazu, nach Identifikation der Zielgruppe
(Nutzer) und des Nutzen des Modells (Verwendungszweck), die Ziel- und Quali-
tätskonformität des Lösungsansatzes darzustellen und zu prüfen.
5.1.1. Verwendungszweck und Nutzerkreis
„Die Ausgestaltung und Prüfung der Qualität eines Modells unter der Prämisse
einer subjektbezogenen Konstruktion muss primär anhand der dem Modell zu-
grunde gelegten Verwendungszwecke (und dem definierten Adressatenkreis)
erfolgen.“ [Heinrich 2000, S. 63].
Abbildung 4 zeigt grob drei Verwendungszwecke des Geschäftsmodells und die
zugehörigen Nutzer auf, welche von Heinrich identifiziert werden konnten [vgl.
Heinrich 2000, S. 64].
Verwendungszweck Nutzerkreis
Beschreibung der
Geschäftskonzeption eines
spezifischen Unternehmens
Wissenschaftlich
Wissenschaftlich
interessierter
interessierter
Adressatenkreis
Adressatenkreis
Basis für differenzierte
Gestaltung der
Kundenbeziehung
Mitarbeiter im Bereich
Mitarbeiter im Bereich
Organisation/Informatik
Organisation/Informatik
Führungsebenen der
Führungsebenen der
Fachbereiche (z.B.
Fachbereiche (z.B.
Vertrieb)
Vertrieb)
Grundlage für Typologisierung
von Kreditinstituten im Bereich
Privatkunden
Abbildung 4: Verwendungszweck und Nutzerkreis für das Geschäftsmodell
Ein Zweck des Geschäftsmodells ist es, eine Basis für eine differenzierte Gestal-
tung der Kundenbeziehung zur Verfügung zu stellen. Der Adressatenkreis für
diesen Zweck schliesst sowohl die Führungsebenen der Fachbereiche als auch den
wissenschaftlich interessierten (betriebswirtschaftlichen) Adressatenkreis mit ein.
(Zweck 1).
Des weiteren soll mittels des Geschäftsmodells eine konsistente Beschreibung und
die Möglichkeit zur Diskussion der Geschäftskonzeption gegeben werden. Dieser
2 Zum Visionsmodell vgl. [Leist/Winter 2000, S. 153-156].

Verwendungszweck fokussiert zusätzlich noch die Mitarbeiter im Bereich Organi-
sation/Informatik. (Zweck 2).
Lediglich für den wissenschaftlich interessierten Adressatenkreis ist die Möglich-
keit zur Typologisierung von Kreditinstituten im Bereich Privatkunden mit Hilfe
des Geschäftsmodells angedacht. (Zweck 3).
Im Anschluss an die Definition des Nutzerkreises und des Verwendungszweckes
des Modells lassen sich die Ziele der Qualitätssicherung ausformulieren und prio-
risieren.
5.1.2. Ziele der Qualitätssicherung auf Geschäftsebene
Die unter den Kapiteln 3.1. bis 3.6. dargestellten Ziele fanden vollständig Einfluss
in das Vorgehen zur Erarbeitung des Geschäftsmodells. Nachfolgend sollen nur
einige davon dargestellt werden [vgl. Heinrich 2000, S. 65-69].
Hinsichtlich dem Ziel der Konstruktionsadäquanz war zum einen Konsens über
den Problembereich und zum anderen Konsens über die Modellkonstruktion her-
beizuführen. Bezüglich der Definition des Problembereichs bedeutete dies, dass
die Fragen nach Möglichkeiten der Darstellung der Geschäftskonzeption und
Fragen nach der Beschaffung und Transformierung der benötigten Informationen
hinreichend zu beantworten waren. Im Sinne einer Qualitätssicherung waren hier
Determinanten für den Problembereich zu fordern, welche mit den Beteiligten
abgestimmt sein sollten. Die Erreichung dieses Ziels wurde an Hand des Kriteri-
ums der Problembestimmung und des Problemverständnisses (K1) gemessen. Die
Massnahmen zur Zielerreichung werden in Kapitel 5.1.3. für die einzelnen Quali-
tätskriterien erörtert. Der Konsens hinsichtlich der Modellkonstruktion propagierte
ein Modell aufgebaut in eine endogene (Innensicht) und exogene (Aussensicht)
Perspektive unter Verwendung der Informationsobjekte „Dimension“, „Bezie-
hung“ und „Ausprägung“ der einzelnen Dimensionen. Abbildung 5 gibt ein Bei-
spiel für die exogene Darstellung.

Zeit Standardisierung Produktpalette Preis bzw. Kosten Risiko
Zeit Bequemlichkeit Wertschöpfung bzw. Kosten Kompetenz & Quali tät Flexibilität Image
Wert bzw. Volumen Transaktion Zeit Performance
Preispolitik Fixbetrag/Leistung
niedrig-konstant niedrig-aufs trebend mittel-konstant m ittel-aufstrebend hoch sehr hoch
komplex dissonanzmindernd habituelles erle bnisorientiertes
Grundorientierung
Grundsatz der
Leistungskombination
produkt-
orientiert
Kernprodukte
und -leistungen
Traditionell Convenience Exklusiv Fachkundig Gesinnungs-
betonend
Marken-
konzeption
Leistungsangebot
Kunden-SB Passiver-s emipersönlicher Kontakt Passiver-persönlicher Kontakt Bankaktiver Kontakt
Land/
Region Schweiz
Stationärer Vertrieb
produktbündel-
orientiert
problem-
lösungorientiert
ereignis-
orientiert
Preiswert Modern &
Innovativ
Mobiler Vertrieb Elektronischer Vertrieb
Betreuung/Beschwerdemanagement Beratung Bedienung/Verkauf Information
Deutschland Frankreich Italien Rest. Euro-Inland Grossbritannien Rest. Euro -Ausland
Konservativ Materiell Hedonistisch Postmateriell Postmodern
Abnehmergruppe
Kaufverhalten
Potential
Genereller Fixbetrag
Vertriebsweg
Erfolgsfaktoren
Serviceleistung
Art des Vertriebs-
kontakts (zweiseitig)
Rentabilität Flexibilität Image
Erfolgsfaktoren
Finanzieren Anlage & Sparen Wert etransfer Vorsorgen Versichern Zusatzleistungen Recht & Steuern
Dimensionen Ausprägungen
Zeit Standardisierung Produktpalette Preis bzw. Kosten Risiko
Zeit Bequemlichkeit Wertschöpfung bzw. Kosten Kompetenz & Quali tät Flexibilität Image
Wert bzw. Volumen Transaktion Zeit Performance
Preispolitik Fixbetrag/Leistung
niedrig-konstant niedrig-aufs trebend mittel-konstant m ittel-aufstrebend hoch sehr hoch
komplex dissonanzmindernd habituelles erle bnisorientiertes
Grundorientierung
Grundsatz der
Leistungskombination
produkt-
orientiert
Kernprodukte
und -leistungen
Traditionell Convenience Exklusiv Fachkundig Gesinnungs-
betonend
Marken-
konzeption
Leistungsangebot
Kunden-SB Passiver-s emipersönlicher Kontakt Passiver-persönlicher Kontakt Bankaktiver Kontakt
Land/
Region Schweiz
Stationärer Vertrieb
produktbündel-
orientiert
problem-
lösungorientiert
ereignis-
orientiert
Preiswert Modern &
Innovativ
Mobiler Vertrieb Elektronischer Vertrieb
Betreuung/Beschwerdemanagement Beratung Bedienung/Verkauf Information
Deutschland Frankreich Italien Rest. Euro-Inland Grossbritannien Rest. Euro -Ausland
Konservativ Materiell Hedonistisch Postmateriell Postmodern
Abnehmergruppe
Kaufverhalten
Potential
Genereller Fixbetrag
Vertriebsweg
Erfolgsfaktoren
Serviceleistung
Art des Vertriebs-
kontakts (zweiseitig)
Rentabilität Flexibilität Image
Erfolgsfaktoren
Finanzieren Anlage & Sparen Wert etransfer Vorsorgen Versichern Zusatzleistungen Recht & Steuern
Dimensionen Ausprägungen
Abbildung 5: Exogene Perspektive des Geschäftsmodells (in Anlehnung an [Heinrich 2000,
S. 59]
Die Dimension „Land/Region“ kann demnach die Ausprägungen „Schweiz“,
„Deutschland“, „Frankreich“, „Italien“ usw. beinhalten. Im obigen Beispiel ist der
Finanzdienstleister nur in Deutschland tätig (ausgefülltes Feld). Hinsichtlich Qua-
litätssicherungsaspekten war zu fordern, dass die zu verwendenden Informations-
objekte (Dimension, Beziehung, Ausprägung) in der Lage sind, den Problem- und
Untersuchungsbereich wiederzugeben. Diese Bedingung wurde als Kriterium der
Problemrepräsentation (K2) bezeichnet, für dessen Erreichung ebenfalls Mass-
nahmen definiert wurden. Die Einhaltung des Kriteriums der Redundanzfreiheit
(K6) sollte bezüglich des Ziels „Konstruktionsadäquanz“ der Forderung nach einer
Minimalität des Modellsystems nachkommen.
Das Ziel der Sprachadäquanz war unter anderem mit Blick auf die Spracheig-
nung zu qualifizieren. D.h. der Bezug zwischen dem Problem und dem Metamo-
dell des verwendeten Modellsystems soll adäquat abbildbar werden. Als Beschrei-
bungssprache wurde ein Notation verwendet, welche vertikal die Entitäten in
Form der Dimensionen des Geschäftsmodells wiedergibt und horizontal deren
Ausprägungen in Quaderform anordnet (vgl. Abbildung 5). Unter dem Aspekt der
Qualitätssicherung war vor allem die Adäquanz der Notation des Quadermodells
speziell für den Verwendungszweck 2 (Beschreibung und Diskussion der Ge-
schäftskonzeption; vgl. Kapitel 5.1.1.) zu fordern. Gemessen werden sollte der

Erfolg der zu diesem Ziel (Spracheignung) führenden Massnahmen am Kriterium
der semantischen Mächtigkeit(K3) und dem Kriterium der Kommunizierbarkeit
(K5).
Ein weiteres Ziel, welches mit der Qualitätssicherung verfolgt wird, ist das der
Klarheit. Das Modellsystem soll bezogen auf den Nutzerkreis anschaulich und vor
allem eindeutig sein. Um dieser Forderung gerecht zu werden, sollte beispielswei-
se die Layoutgestaltung eine rasche Aufnahme und Wahrnehmung der Modellin-
halte ermöglichen. Des weiteren sollten zur Steigerung der Akzeptanz die Inhalte
des Modellsystems bei der praktischen Nutzung eingeschränkt werden können im
Sinne einer Filterung für unterschiedliche Nutzerkreise. Diese beiden Forderungen
konnten unter dem Kriterium der Kommunizierbarkeit (K5) vereint werden.
Im Sinne der Wirtschaftlichkeit des Modells wurde Flexibilität und Anpassungs-
fähigkeit im Hinblick auf eine Weiterführung des Modells gefordert. Kriterien
hierfür waren das Kriterium der Modellrobustheit (K4) und das Kriterium der
Rollenunabhängigkeit (K7).
5.1.3. Massnahmen zur Erreichung der Ziele
Nachdem bisher die Ziele der Qualitätssicherung und Qualitätskriterien zur Um-
setzung der Ziele auf Geschäftsebene dargestellt wurden, soll nun auf die Mass-
nahmen zur Erreichung dieser Ziele bzw. Befriedigung der oben genannten Krite-
rien näher eingegangen werden [vgl. Heinrich 2000, S. 69-80].
Dem Kriterium der Problembestimmung und des Problemverständnisses (K1)
wurde in einem ersten Schritt durch die Detaillierung der fokussierten Problem-
stellung in einzelne Problemfelder genüge getan. In einem zweiten Schritt wurde
dann der Schwerpunkt lediglich auf bestimmte Aspekte der Problemstellung ge-
legt. Ausserdem fand eine inhaltliche Eingrenzung der Problemdomäne auf den
Bereich des Privatkundengeschäfts statt. Zudem wurde speziell die Rolle des Ser-
vice Integrators betrachtet, ein weiterer Schritt hin zur Umsetzung des Qualitäts-
kriteriums der Problembestimmung.
Eine Massnahme zur Erfüllung des Kriteriums der Problemrepräsentation (K2)
war die Konzentration auf die wesentlichen Dimensionen der Modelldarstellung.
Somit konnten den Problemen der Informationsvielfalt und Informationsrelevanz,
welche bei der Modellkonstruktion anfallen, begegnet werden. Mittels eines Fra-
gebogens zur Interpretation der Geschäftskonzeption wurden die Informationen
als Vorleistung zur Modellerstellung verdichtet und eine Auswahl der wesentli-
chen Dimensionen konnte stattfinden. Dem Problem der Informationseindeutigkeit
konnte mit Hilfe der semiformalen Darstellung der Geschäftsmodellinhalte im
Quadermodell und der Erstellung einer terminologischen Grundlage (Glossar)
entgegen gewirkt werden.
Beim Kriterium der Redundanzfreiheit (K6) stand der Aspekt der Vermeidung der
mehrfachen Speicherung von Informationsobjekten im Vordergrund, was primär

auf die Dimensionen des Modells abzielte. „Durch die Verwendung von Interroga-
tivpronomen, die es erlauben, die unterschiedlichen Eigenschaften des betrachte-
ten Systems (…) zu untersuchen, wird sichergestellt, dass keine bzw. nur geringe
Überschneidungen in die Modellrepräsentation eingehen“ [Heinrich 2000, S. 77].
Dies äusserte sich darin, dass die Wahl einer bestimmten Dimensionsausprägung
die Ausprägung einer anderen Dimension nicht determiniert oder in hohem Masse
beschränkt hätte.
Hinsichtlich des Kriteriums der semantischen Mächtigkeit (K3) wurde bei der
Darstellung zwar keine komplexe und mächtige Notation verwendet, sondern eher
Wert auf Verständlichkeit der Darstellung gelegt - welche durch das Quadermo-
dell erreicht wurde - aber dennoch genügte die semantische Mächtigkeit der ver-
wendeten Notation, die beabsichtigte Zielsetzung (unkomplizierte und anschauli-
che Darstellung des Geschäftsmodells) zu erreichen.
Das Kriterium der Kommunizierbarkeit (K5) des Modells konnte teilweise durch
die grafische Darstellung des Modells in Quaderform befriedigt werden. Diese
Darstellung wurde eigens für diesen Qualitätsaspekt eingeführt und entwickelt
[Heinrich 2000, S. 74]. Zudem blieben bei den Modellinhalten die Beziehungen
zwischen den Dimensionen aus Gründen der Komplexitätsreduktion unberück-
sichtigt. In der Layoutgestaltung wurde ausserdem darauf geachtet, einfache Sym-
bole (Quader) zu verwenden, um im Sinne der Klarheit ein schnell zugängliches
Modell zu erstellen. Eine weitere Massnahme zur Verbesserung der Kommuni-
zierbarkeit des Modells war die Erstellung eines Glossars, welches die wesentli-
chen Begrifflichkeiten ausformuliert und fixiert hat.
Die Kriterien der Modellrobustheit und der Rollenunabhängigkeit (K7) konnten
ebenfalls durch die verwendete Notation bzw. Darstellungsweise der Geschäfts-
konzeption eingehalten werden. Beim Kriterium der Modellrobustheit (K4) stehen
vor allem die Aspekte Wirtschaftlichkeit und Vergleichbarkeit im Vordergrund.
Bei der Wirtschaftlichkeit ist an die Minimierung des Aufwands bei einer Erweite-
rung des zugrunde gelegten Problembereichs (bspw. andere Branche im Fokus) zu
denken. Durch Erweiterung der Dimensionen und deren Ausprägungen ist dies
zumindest in der extensionalen Darstellungsweise erreichbar. Vergleichbarkeit ist
hier im Sinne eines Referenzcharakters für überbetriebliche Vergleiche des Mo-
dells zu verstehen. Um die überbetriebliche Vergleichbarkeit des Modells zu er-
reichen, wurden mittels Konsens (unter den Partnerunternehmen) über die Dimen-
sionsausprägungen die unternehmensspezifischen Modifikationen minimiert und
somit der Referenzcharakter des Modells gefestigt. Eine Modellrobustheit bezüg-
lich des Kriteriums der Rollenunabhängigkeit (K7) zu erreichen, konnte im Rah-
men der Arbeiten bisher noch nicht nachgewiesen werden.
Zusammenfassend gibt Abbildung 6 nochmals die Zusammenhänge zwischen den
Qualitätszielen (Kapitel 3.1. bis 3.6.), den Qualitätskriterien und den Massnahmen
zur Erreichung der Ziele auf Geschäftsebene wieder.

Qualitätsziele Qualitätskriterien
Sprach-
adäquanz
Konstruktions-
adäquanz
Kriterium der Problembestimmung
und des Problemverständnisses (K1)
Klarheit
Massnahmen
Wirtschaftlich-
keit
Kriterium der Problemrepräsentation
(K2)
Kriterium der Redundanzfreiheit (K6)
Kriterium der semantischen
Mächtigkeit (K3)
Kriterium der Kommunizierbarkeit
(K5)
Kriterium der Kommunizierbarkeit
(K5)
Kriterium der Modellrobustheit (K4)
Kriterium der Rollenunabhängigkeit
(K7)
Zerlegung der Problemstellung in Problemfelder;
Schwerpunkt auf Privatkundengeschäft und Service
Integrator
Wesentliche Dimensionen der Modelldarstellung
mittels Fragebogen identifizieren; Darstellung im
Quadermodell
Verwendung von Interrogationspronomen;
Unabhängigkeit (schwache Abhängigkeit) der
Dimensionen voneinander
Unkomplizierte und übersichtliche Darstellung mittels
Notation im Quadermodell
Layoutgestaltung in Quadern; Erstellung eines
Glossars zur Standardisierung der Begrifflichkeiten
Layoutgestaltung in Quadern; Erstellung eines
Glossars zur Standardisierung der Begrifflichkeiten
Leichte Erweiterbarkeit der Dimension und deren
Ausprägungen im Quadermodell; Minimierung
unternehmensspezifischer Modifikationen
Abbildung 6: Zusammenhang zwischen den Qualitätszielen und Massnahmen auf Ge-
schäftsebene
5.2. Anwendung auf Prozessebene
Ebenfalls wie auf Geschäftsebene, so wurde auch auf Prozessebene das Konzept
zur Qualitätssicherung (in abgewandelter Form) angewendet. Gemäss dem bereits
dargestellten Vorgehen wurden so in den Workshops des CC BAI Verwendungs-
zweck und Nutzerkreis des Prozessmodells, Ziele, welche mit der Qualitätssiche-
rung verfolgt werden sollen und Konventionen bzw. Massnahmen zur Erreichung
dieser Ziele erarbeitet.
5.2.1. Verwendungszweck und Nutzerkreis
Zusammen mit den Partnerunternehmen wurden der Verwendungszwecke und der
Nutzerkreise für das Referenzprozessmodell des CC BAI erarbeitet. In einem
ersten Arbeitsschritt wurden unter anderem folgende Verwendungszwecke aufge-
führt:
• Erkennen von Abdeckungslücken/ Doppelbelegungen in der Applikationsland-
schaft

• Kommunikationsbasis/ Orientierungshilfe
• Ausgangsbasis zur Individualisierung
• Benchmarking (Controlling)
• Kooperationen
• Prozessmanagement
• Abbildung von Kernprozessen
• Schwachstellenanalyse
• SOLL-Definition von Prozessen
• Prozessführung
• Gesamtübersicht/ Abgrenzung
• Visualisierung
• Verständnis für Prozesse
• Reuse (Architekturebene)
• Zeitlicher Feedback (Kennzahlen)
Diese einzelnen Verwendungszwecke wurden dann in einem zweiten Schritt auf
die nachfolgend dargestellten Komplexe verdichtet (Abbildung 7).
Verwendungszweck Nutzerkreis
Schulungszweck
(soll Verständnis über den generellen Ablauf z.B.
bei neuen Mitarbeiter wecken) „Laie“
„Experte“
Kommunikationsbasis
(dient zur Abgrenzung/ Schnittstellendefinition
zwischen kundigen Akteuren auch unterschiedlicher
Unternehmen)
Analysezweck
(Anwendungsfälle sind hierbei die Verbindung zur
Anwendungslandschaft, das Benchmarkingbzw. die
Gestaltung und Einordnung neuer Abläufe)
„Kundiger Laie“
Abbildung 7: Verwendungszweck und Nutzerkreis von Referenzprozessmodellen
Unter anderem wurden die im ersten Schritt erarbeiteten Zwecke „Verständnis für
Prozesse“, „Abbildung von Kernprozessen“ und „Soll-Definition von Prozessen“
wurden unter dem Oberbegriff Schulungszweck zusammengefasst. Die Zwecke
„Kommunikationsbasis/Orientierungshilfe“, „Gesamtübersicht/Abgrenzung“ und
„Visualisierung/Verständnis“ wurden unter dem Verwendungszweck Kommunika-

tionsbasis subsummiert. Der Analysezweck wurde als Oberbegriff für die Zwecke
„Prozessmanagement“, „Schwachstellenanalyse“ und „Zeitlichem Feedback“
definiert.
Für den Zweck der Schulung lässt sich die Methodenkompetenz der Anwender als
gering bis mittel charakterisieren („Laie“). Dem gegenüber verwenden geschultere
Nutzer („Kundiger Laie“) das Referenzprozessmodell als Kommunikationsbasis
beispielsweise zur Abgrenzung der eigenen Aktivitäten zu unternehmensfremden
bzw. ausgelagerten Abläufen. Die höchste Kompetenz wird für den Zweck der
Analyse vorausgesetzt („Experte“), d.h. hier soll einerseits mittels des Modells
der Zusammenhang mit der Anwendungslandschaft verdeutlicht (z.B. Identifikati-
on des zukünftigen Handlungsbedarfs für den Einsatz von Applikationen) sowie
andererseits die vorhandenen Prozesse neu gestaltet bzw. verbessert werden.
5.2.2. Ziele der Qualitätssicherung auf Prozessebene
Hintergrund dieser Festlegungen ist die zielorientierte Ausrichtung der Prozess-
modellkonstruktion an den gerade genannten Zwecken und Nutzerkreisen. Dies
bedeutet, die Qualität des Modells ist in erster Linie an der Erfüllung der sich
daraus ergebenden Anforderungen zu messen. Dem zufolge wurden im weiteren
Vorgehen für einen einzelnen Zweck Modelle definiert und letztlich zusammenge-
führt (Kompromiss/Konsens). Danach waren auf dieser Basis die bereits existie-
renden Ziele der Qualitätssicherung weiter zu detaillieren und vor allem zu priori-
sieren. In einem letzten Schritt sollte dann der vorhandene Massnahmenkatalog
ergänzt und eingeführt werden, d.h. innerhalb des generellen Vorgehens zur Mo-
dellerstellung waren die Qualitätssicherungsaktivitäten zu berücksichtigen wie
auch Kriterien zur Bewertung der Ergebnisse (Modelle) zu definieren und zu prü-
fen.
Für das weitere Vorgehen wurden dann die Ziele priorisiert und der Verwen-
dungszweck und der Nutzerkreis des Referenzmodells des CC BAI festgelegt.
Ziele Verwendungszweck
Schulungszweck
Kommunikations -
basis
Analysezweck
-
adäquanz
Sprach-
adäquanz
Wirtschaftlichkeit
Klarheit
Nutzerkreis
„Experte“
„Laie“
„Kundiger Laie“
Vergleichbarkeit
Systematischer
Aufbau
Ziele Verwendungszweck
Schulungszweck
Kommunikations -
basis
Analysezweck
Konstruktions-
adäquanz
Sprach-
adäquanz
Wirtschaftlichkeit
Klarheit
Nutzerkreis
„Experte“
„Laie“
„Kundiger Laie“
Vergleichbarkeit
Systematischer
Aufbau

Abbildung 8: Ziele, Verwendungszweck und Nutzerkreis des CC BAI Referenzprozessmo-
dells
Das Referenzmodell sollte nach den Massstäben der Konstruktionsadäquanz,
Sprachadäquanz, Wirtschaftlichkeit und dem Aspekt der Klarheit konstruiert wer-
den (Abbildung 9). Auf einen systematischen Aufbau und die Vergleichbarkeit
des Modells wurde kein Schwerpunkt gelegt. Als Verwendungszweck für das
Referenzprozessmodell wurde der Schulungszweck gewählt und damit der Nut-
zerkreis auf den Laien bzw. kundigen Laien beschränkt. Dieser Verwendungs-
zweck und Nutzerkreis wurde in der Praxis der Partnerunternehmen am häufigsten
angetroffen und daher favorisiert.
Konstruktions*
adäquan z
Sprach*
adäquan z
W irtschaftlichkeit
Konsens8über8Problemdefinition
Konsens8über8Modelldarstellung
Sprachrichtigkeit
!Konsistenz
!Vollständigkeit
Spracheignung
!Semantische8Mächtigkeit
!Verständlichkeit8der8Sprache
!Formalisierung8der8Sprache
Konsensfindung
Sprachverständnis* u.8anw end ung
Übersetzbarkeit
Klarheit Eindeutigkeit8der8Hierarchisierung
Verständlichkeit8des8Layouts
Filterung
Qualität8von8Modellen
GoM
(Z ielklassen)
Zielunterklassen8und8Ziele
Abbildung 9: Ziele der Qualitätssicherung im CC BAI (Quelle: [Schütte 1998, S. 136],
Abbildung abgeändert)
5.2.3. Massnahmen zur Erreichung der Ziele
Um dem Ziel der Konstruktionsadäquanz nahe zu kommen, wurde zum einen ein
Konsens über die Modelldarstellung und zum anderen ein Konsens über die Prob-
lemdefinition gefunden. Hinsichtlich der Modelldarstellung einigte man sich auf
die Verwendung von lediglich vier Informationstypen und vier Darstellungsebe-

nen. Rechteckige Kästchen auf Ebene 1 wurden zur Darstellung der Kernprozesse
gewählt. Pfeile von Wertschöpfungskettendiagrammen stellen auf Ebene 2 und 3
die Detaillierung der Kernprozesse in Form von Teilprozessen dar. Auf Ebene 4
wurde dann mittels EPK’s modelliert, wobei sich die Informationsobjekte hier auf
Funktionen (rechteckige Kästchen mit abgerundeten Kanten) und Ereignisse (Rau-
ten) beschränkten, welche über Kanten und Konnektoren verbunden sind.
Ebene 1
Ebene 1
Ebene 3
Ebene 3
Ebene 4
Ebene 4
Funktionen
Ereignisse
Teil-
prozesse
Kern-
prozesse
Ebene 2
Ebene 2
Funktion
Ereignis
Ereignis Ereignis
Funktion
Ereignis
Informationstypen Darstellungsebenen
Abbildung 10: Modelldarstellung im CC BAI
Konsens über die Problemdefinition bestand hinsichtlich der Tatsache, dass ein
(Vertriebs-)Prozessmodell für den Finanzdienstleister des Informationszeitalters
(Service Integrator) zum Zwecke der Schulung für einen Laien bzw. kundigen
Laien erstellt werden sollte.
Die Zielklasse Sprachadäquanz war an ihren Zielunterklassen (vgl. Abbildung 9)
Spracheignung und Sprachrichtigkeit zu messen. Hinsichtlich der Spracheignung
wurden auf der ersten Ebene des CC BAI Referenzprozessmodells die Hauptpro-
zesse in Form von Rechtecken aufgeführt. Bezeichnend bei den Hauptprozessen
ist, dass diese keine Ablaufreihenfolge widerspiegeln, sondern lediglich die Kern-
prozesse abbilden. Erst mit Verwendung der Wertschöpfungsketten-Pfeile werden
auf Ebene 2 und 3 Abläufe von links nach rechts abgebildet. Die Darstellung in
EPK als anerkannte „Sprache“ war nicht zu diskutieren. Die Sprachrichtigkeit
ergab sich hier aus den Tool-Vorgaben (ARIS).
Hinsichtlich dem Ziel der Wirtschaftlichkeit sollte geprüft werden, ob hinsichtlich
der Pflege und Weiterentwicklung des Modells die Kosten im Verhältnis zum
Schulungsnutzen stehen würden. Eine Kostenaufstellung bzw. –rechnung wurde
an dieser Stelle jedoch nicht vorgenommen.

Das Ziel der Klarheit wird repräsentiert durch eine eindeutige Hierarchisierung
und der Verständlichkeit des Layouts. Die Hierarchisierung des Modells ist durch
die Einteilung in vier Ebenen ersichtlich. Dabei wurde darauf geachtet, dass bei-
spielsweise auf den Ebenen 2 und 3 nicht mehr als sieben Teilprozesse dargestellt
werden aus Gründen der Übersichtlichkeit und der Einfachheit zu Schulungszwe-
cken für den gewählten Nutzerkreis. Die Layoutgestaltung auf Ebene 4 ergibt sich
aus den Tool-Vorgaben von ARIS-Toolset, auf den restlichen Ebenen darüber
wurde von links nach rechts modelliert, ausser auf Ebene 1, da diese Ebene keine
Abläufe beinhaltet.
Mit Einhaltung bzw. Durchführung dieser Massnahmen sollte sichergestellt wer-
den, dass die Ziele der Qualitätssicherung im CC BAI bezüglich des Referenzpro-
zessmodells zum Zwecke der Schulung von (kundigen) Laien erreicht werden.
Andere Massnahmen hätten beispielsweise abgeleitet werden müssen, wenn man
den Analysezweck des Referenzmodells propagiert hätte und damit den Nutzer-
kreis auf Experten beschränkt hätte. Für Zwecke der Analyse hätte das Modell
eventuell mehr als nur 4 Ebenen aufweisen müssen, umfangreichere Informations-
objekte wären zu wählen gewesen (z.B. zusätzliche Modellierung von Organisati-
onseinheiten, Dokumenten, Informationsträgern usw.) und Kenngrössen für die
Prozessabläufe wären festzulegen gewesen. Grundsätzlich ist vor Beginn jeglicher
Modellierungsprojekte zu eruieren, welcher Zweck damit verfolgt werden soll,
wer mit der Modellierung angesprochen werden soll und wie unter Berücksichti-
gung dieses Wissens dann schlussendlich modelliert werden soll.
5.3. Anwendung auf Applikationsebene
Auf der Applikationsebene fand die im CC BAI angewandte Qualitätssicherung
zur Modellbildung wie bereits oben erwähnt als „Zwischen-Kontrolle“ statt. Dazu
wurden nach dem erläuterten qualitätssichernden Vorgehen ebenfalls zunächst der
Nutzerkreis und der Verwendungszweck des Modell’s auf der Applikationsebene
mit dem Namen „PIT-Modell“ beschrieben, um anschliessend die Ziele der Quali-
tätssicherung bzw. Qualitätskriterien auszuformulieren. Die Zielerreichung sollte
durch Einhaltung definierter Massnahmen bzw. Konventionen gewährleistet wer-
den.
Die im Nutzerkreis vertretenen Rollen sind seitens des Business Entscheidungs-
träger, Prozessmodellierer und Fachvertreter der Geschäfts- und der Prozessebene,
seitens der IT die Entscheidungsträger der Applikationsebene, Fachvertreter der
IT-Architektur und Anwendungsentwickler. An der Schnittstelle von Business und
IT sind als Rollen die Vertreter und Verantwortlichen des „Reuse“-Managements
dem Nutzerkreis zuzuordnen. Dieser enge Nutzerkreis besteht vornehmlich aus
Experten. Zum erweiterten Nutzerkreis gehören (kundige) Laien und Interessen-
ten, die sich über neue Konzeptionen des Business Engineering und über beste-
hende Interdependenzen zwischen Prozess- und Applikationsebene informieren

wollen.3 Die Verwendungszwecke des PIT-Modells für den engen Nutzerkreis
sind vornehmlich:
• Konzeption und Bildung moderner Anwendungslandschaften im Informati-
onszeitalter.
• Schaffung von Transparenz an der Schnittstelle von Business und IT mittels
einer methodischen Referenzierung von Prozess- und IT-Bausteinen.
• Nachweis der Interdependenzen zwischen der Prozess- und Applikationsebe-
ne (Analyse- und Kommunikationszweck).
• Etablierung des „Reuse“ / Förderung von Componentware.
• Ermöglichung einer Abschätzung der Auswirkungen bei Prozessänderungen
auf die Applikationsebene und vice versa.
• Verwendung eines Referenzmodells.
Dem erweiterten Nutzerkreis sind folgende Zwecke zuzuordnen:
• Bereitstellung einer Knowledge-Base (Anwendungs- und Schulungszweck).
• Übersicht über Prozessabläufe und der damit verbundenen IT-Unterstützung.
Im folgenden wird eine Übersicht über Bestandteile des PIT-Modell gegeben, um
eine Zuordnung der „Zwischen-Kontrolle“ vornehmen zu können:
1. Vision einer zukünftigen Anwendungslandschaft.
2. Vorgehensmodell4 zur Verknüpfung von Prozess- und IT-Bausteinen (PITen).
3. Vorgehensmodell zur Bildung von „situativen und adaptiven“ Prozessketten
aus PIT’s, (Kupplung von PIT’s zu Prozessketten und damit zur Bildung von
„virtuellen Applikationen“).
4. Anforderungsprofil an die Systemarchitektur.
5. Erstellen eines Prototyps an einem ausgesuchten Anwendungsfall.
Für die qualitätssichernde „Zwischen-Kontrolle“ wird Punkt 2, das Vorgehensmo-
dell zur Verknüpfung von Prozess- und IT-Bausteinen (PITen), betrachtet. Für
dieses Vorgehensmodell wären in einem weiteren Schritt diejenigen Ziele zu defi-
nieren, welche mit der Qualitätssicherung zu verfolgen sind. Beispielsweise wäre
daran zu denken, im Sinne der Konstruktionsadäquanz das Problemfeld des „PI-
Ten“ detailliert und in Konsens mit den Beteiligten abzugrenzen. Im Sinne der
Wirtschaftlichkeit wäre zu beachten, dass das PIT-Modell in einer derartigen Wei-
se zu konstruieren ist, dass es z.B. branchenübergreifend einsetzbar bzw. abwan-
3 Vergleiche hierzu [Choinowski 2001] in diesem Buch.
4 Zur Vorgehensmethodik des PITen vgl. [Choinowski 2001] in diesem Buch.

delbar ist. Im Sinne der Klarheit wäre das Kriterium Layoutgestaltung des Mo-
dells näher zu betrachten.
In einem letzten Schritt sind dann die Massnahmen abzuleiten, welche die Errei-
chung der gesetzten Ziele gewährleisten können. So müssten beispielsweise hin-
sichtlich dem Ziel Konstruktionsadäquanz sowohl die nötigen Granularitätsebenen
der Prozessteilschritte als auch die Möglichkeit der Komponentenbildung vorge-
geben werden. Es ist zu fixieren, inwieweit minimale Einheiten von Prozessschrit-
ten sinnvoll mit Applikationseinheiten zu verbinden sind. Bezüglich des Quali-
tätskriteriums Klarheit ist hinsichtlich Layoutgestaltung zu beachten, dass Regeln
und Vorgaben definiert werden bezüglich derer das Modell im Bezug auf den
Verwendungszweck und den Nutzerkreis abzubilden ist.
Ein Vergleich dieser, aufgrund der Vorgehensweise im Sinne der Qualitätssiche-
rung, erarbeiteten Massnahmen mit den bisher getroffenen Massnahmen und Kon-
ventionen kann Hinweise darauf geben, inwieweit das bisherige Vorgehen die
Qualität des PIT-Modells unterstützt.
6. Zusammenfassung und Ausblick
Der vorliegende Beitrag hat aufgezeigt, welche Kriterien zur Modellkonstruktion
wie bei dem Aufbau der Modelle des CC BAI berücksichtigt wurden. Mit Hilfe
der zur Qualitätssicherung ergriffenen Massnahmen sowie der nutzer- und zweck-
gerechten Bewertung der Maßnahmen auf Ebenen der Informationsarchitektur
konnte eine „qualitative Abstützung“ der Modellkonstruktion gewährleistet wer-
den.
Bei der Anwendung der Qualitätssicherung wurde oft ein pragmatischer Weg (vor
allem auf der Prozess- und Applikationsebene) in Abstimmung mit den Partnerun-
ternehmen gewählt, so dass für die weiteren Entwicklungen auf der „Geschäfts-
ebene“ sowie den nachgelagerten Ebenen noch wissenschaftliche Fundierungsver-
suche erforderlich sind. Des weiteren wurde im CC BAI die Qualitätssicherung
lediglich im Hinblick auf die Entwicklung der einzelnen Modelle - auf den einzel-
nen Ebenen - angewandt, der Übgang zwischen den Ebenen wurde nicht näher
betrachtet. Auch dieser Aspekt ist im Sinne des systematischen Aufbaus der Mo-
delle im Rahmen der Gesamtarchitektur noch näher zu betrachten, um auch eine
über alle Ebenen hinweg hohe Qualität der Architektur erlangen zu können.

Literaturverzeichnis
[Batini et al. 1992]
Batini, C.; Ceri, S.; Navathe, S. B.: Conceptual Database Design. An Entity-
Relationship-Approach. Redwood City et al. 1992.
[Becker/Kugeler/Rosemann 2001] Becker, J.; Kugeler, M.; Rosemann, M.: Prozessma-
nagement. 3. Aufl., Berlin et al. 2001.
[Heinrich 2000]
Heinrich, B.: Dimensionen zur Beschreibung eines Geschäftsmodells für Kreditinstitute
im Bereich Privatkunden, Arbeitsbericht BE HSG/CC BAI/01, St. Gallen 2000
[Moody/Shanks 1994]
Moody, D. L.; Shanks, G.: What Makes a Good Data Model? Evaluating the Quality of
Entity Relationship Models. In: Entity-Relationship Approach - ER `94. Business Mod-
elling and Re-Engineering. 13th International Conference on the Entity-Relationship
Approach. Proceedings. Hrsg.: P. Loucopoulos. Berlin et al.1994, S. 94-111.
[Moody/Shanks 1998]
Moody, D. L.; Shanks, G.: What Makes a Good Data Model? A Framework for Evalu-
ating and Improving the Quality of Entity Relationship Models. Australian Computer
Journal (1998). Preprint.
[Leist/Winter 2000]
Leist, S., Winter, R.: Finanzdienstleistungen im Informationszeitalter – Vision, Refe-
renzmodell und Transformation, in: Belz, C., Bieger, T. (Hrsg.): Dienstleistungskompe-
tenz und innovative Geschäftsmodelle, THEXIS, St. Gallen 2000
[Rosemann/Schütte 1999]
Rosemann, M., Schütte, R.: Multiperspektivische Referenzmodellierung. In: Referenz-
modellierung – State-of-the-Art und Entwicklungsperspektiven. Heidelberg 1999, S.
22-44.
[Schütte 1998]
Schütte, R.: Grundsätze ordnungsmässiger Referenzmodellierung, Gabler, Wiesbaden
1998.