Beruflich Dokumente
Kultur Dokumente
ADDISON-WESLEY
An imprint of Pearson Education
München • Boston • San Francisco • Harlow, England
Don Mills, Ontario • Sydney • Mexico City • Madrid • Amsterdam
Die Deutsche Bibliothek – CIP-Einheitsaufnahme
Umwelthinweis:
Dieses Produkt wurde auf chlorfrei gebleichtem Papier gedruckt.
Die Einschrumpffolie – zum Schutz vor Verschmutzung – ist aus
umweltverträglichem und recyclingfähigem PE-Material.
10 9 8 7 6 5 4 3 2 1
03 02 01 00
ISBN 3-8273-1445-3
Inhaltsverzeichnis
Vorwort 11
Einleitung 15
Welche Themenkomplexe umfasst dieses Buch? 15
Wie ist das Buch aufgebaut? 18
Zeichenerklärung 20
Das durchgängige Übungsbeispiel 20
A Anhang 631
A.1 Zusammenfassung der Ergebnisse der Gestaltung 631
A.2 Ausblick und Randthemen 637
A.3 Schluss 641
B Anhang 645
B.1 Beispiel für Stellenbeschreibungen 645
Lösungen 652
B.2 Lösungen ausgewählter Übungen Kapitel 1 652
B.3 Lösungen ausgewählter Übungen Kapitel 4 653
B.4 Lösungen ausgewählter Übungen Kapitel 5 656
B.5 Lösungen ausgewählter Übungen Kapitel 6 657
B.6 Lösungen ausgewählter Übungen Kapitel 7 657
Literaturverzeichnis 662
B.7 Monographien 662
B.8 Zeitschriften 676
B.9 Schwerpunkthefte der Zeitschriften 677
B.10 DWH-Studien 678
B.11 Abbildungsverzeichnis 680
Index 681
11
VORWORT
Vorwort
Das Data Warehouse
»Data Warehouse«, »Data Mart«, »Information Warehouse«, »Data Mining«,
OLAP, ROLAP, MOLAP – allesamt sind Modeworte, die zu den Lieblingsthemen
der Marktforscher gehören. Data Warehouse hat als Beratungsprodukt den Auf-
stieg in die erste Liga des Consulting geschafft und gehört zu den Pflichtthe-
men der EDV-Abteilungsleiter. Es ist sogar zu einem Kapitel in der Wirtschafts-
informatik-Vorlesung der Hochschulen avanciert. Wenn sich so viele Parteien
einig sind, dann liegt dies entweder an der Suggestivkraft der Begriffe oder es
liegt an der tatsächlichen Leistungsfähigkeit der dahinter stehenden Konzepte
und Produkte. Immer dort, wo das Interesse der Kunden groß ist, wächst auch
der Einfallsreichtum der Werbespezialisten. Plötzlich und fast aus dem Nichts
heraus entstehen neue Produkte, um die sich schnell Erfolgsgeschichten ran-
ken, und schneller als man wünscht befindet man sich auf einem Tummelplatz
der Schönmalerei. Es ist ein Anliegen dieses Buches, so viel Transparenz in das
Thema Data Warehouse zu bringen, dass man vor den Versprechungen der
Hochglanzprospekte gefeit ist und bei Entscheidungen kühlen Kopf behalten
kann.
Das »Data Warehouse« wird von Herstellern häufig heruntergespielt nach dem
Motto: »Kaufen Sie meinen OLAP-Server, meine Consultants bauen Ihren Mul-
tiwürfel in zwei Wochen auf und Sie haben ein unternehmensweites Data Ware-
house.« Um es vorwegzunehmen: Ein Data Warehouse ist kein Produkt, das
schnell über den Ladentisch geht, sondern ein höchst komplexes Vorhaben.
Dieses Vorhaben umfasst unter anderem
✔ die Beschaffung von Softwareprodukten
✔ die Beschaffung neuer Hardware
✔ die Eigenentwicklung von Software
✔ das Customizing von Softwarekomponenten
✔ die Anwendung von Methoden der Systemanalyse
✔ Anpassungen der Organisationsstruktur (zum Beispiel wird eine Reihe
neuer Spezialisten und eine Stelle namens Data Warehouse Spezialist
nötig)
und sogar Änderungen in der Geisteshaltung konventioneller EDV. Ohne
bereits eine Definition vorwegzunehmen, sei gleich am Anfang das diesem
Buch zugrunde liegende Verständnis des Begriffs »Data Warehouse« dargelegt.
12 Vorwort
Ein Data Warehouse wird hier als ein mit allen operativen Daten eines Unter-
nehmens arbeitendes, integrierendes System aus Softwarekomponenten auf-
gefasst, das mittels einer Hardware-Infrastruktur betrieben wird. Ein Data
Warehouse durchläuft einen Lifecyle aus Initiierung, Projektierung, Konzep-
tion, Spezifikation, Beschaffung, Realisierung, Implementierung, Betrieb und
Abbau. Ein Data Warehouse reiht sich somit in die Gruppe der beratungsinten-
siven Produkte ein.
Das Thema Qualifizierung
Eine neue Qualifikationssituation erfordert eine neue Ausbildungskonzeption.
Viel stärker als in früheren Berufszeiten muss die Qualifikation der Mitarbeiter
ein mit dem Ausüben des Berufes verzahnter und kontinuierlicher Prozess sein.
Der Schwerpunkt für eine neue Qualifkationskonzeption liegt daher nicht
mehr in der reinen Wissensvermittlung und dem Abfragen durch Übungen.
Neue Ausbildungskonzeptionen konzentrieren sich auf das Durchspielen der
Praxis, das Üben von Entscheidungssituationen, die Vermittlung von Hilfestel-
lungen bei der Zielefindung, angepasst an die Praxissituation und auf die
Bereitstellung der Mittel, die nötig sind, um diese Ziele erreichen zu können.
Das Buch hat sich daher die Aufgabe gestellt, einen diesen neuen Lernanforde-
rungen entsprechenden Qualifizierungsansatz für eine neue Berufsgruppe, die
Data Warehouse Spezialisten, darzustellen. Diese sind im Einzelnen der Data
Warehouse Konzeptionist, der Data Warehouse Consultant, der Data Ware-
house Manager, der Data Warehouse Administrator, der Data Warehouse Trainer
und der Data Warehouse Projektleiter.
Die Konzeption des Buches
Das Ziel dieses Buches ist die Vermittlung des Grundwissens zu dieser moder-
nen Berufsgruppe aus der Welt der Informationstechnologie in Form eines
autodidaktischen Seminars. Das vorliegende Buch kann daher in einem Inten-
sivseminar von etwa fünf Tagen an exemplarischen Entscheidungssituationen
eines Beispielprojekts durchgespielt werden. Der Aufbau folgt einer Gliederung
in Lernstufen.
Das Buch soll nach dem Durcharbeiten nicht in einem Schrank abgelegt wer-
den, sondern auch im Berufsalltag verwendbar sein. Es ist Ausbildungshilfe und
Nachschlagewerk für die Praxis. Es dient dem Data Warehouse Spezialisten
dazu, eine vorliegende Projektsituation zu identifizieren und das entsprechende
Hilfsmittel im Buch zu finden. Dieses Hilfsmittel kann z.B. eine Tabelle mit
durchdachter Struktur, eine Checkliste mit Einträgen, eine Übersichtsgrafik
oder ein Symbolevorrat zur Visualisierung sein. Das Buch ist damit viel mehr
methodische Hilfe als Lehrmittel.
Projekte sind immer einmalig. Kunden, Projektteam, Ort, Mittel und nicht
zuletzt die Aufgabenstellung sind immer unterschiedlich. Kein Projekt ist von
Beginn an klar definiert, auch wenn es sehr große Ähnlichkeit mit bereits abge-
wickelten Projekten haben sollte. Jedes Projekt ist ein kontinuierliches Dazu-
lernen, ein umfassender Lernvorgang. Jede neue Erkenntnis kann zu einer
Vorwort 13
die meinen »Seminarexperimenten« mit Skepsis, aber auch mit Geduld und
Ausdauer gefolgt sind; die viel konstruktive Kritik eingebracht haben und am
Ende zu lebhaften und informations- und erkenntnisintensiven Seminarwo-
chen beigetragen haben. So wünsche ich dem Leser, dass er mit ähnlicher Leb-
haftigkeit, der nötigen Gelöstheit und einem Quäntchen Vergnügen an seine
Weiterbildung herangehen kann. Mit Freude erarbeitet, wird das Lernergebnis
besser ausfallen.
Besonderer Dank gilt meinen ehemaligen Arbeitskollegen der Integrata
Deutschland, Thomas Gueffroy, Manfred Richter und unserem Mitstreiter auf
dem Weg zu einer modernen Unternehmensinformatik, Dr. Frank Müller-Dahl,
ehemals DEG, Köln. Mit ihnen wurde so manches an nützlichen Projekthilfs-
mitteln für DWH entwickelt. Dank gilt auch Franz Bauer von der Integrata
Österreich und Robert Neundlinger, früher AI Informatics, jetzt MicroStrategy,
für die intensive Kritik. Bedanken möchte ich mich auch bei den im Text
genannten Firmen für die Überlassung von Informationsmaterial. Ich danke
Hannes Kriegbaum, früher Computer Associates Austria, jetzt Brokat, für den
tiefen Einblick in das Systemmanagement komplexer EDV-Systeme und mei-
nen jetzigen Projektkollegen der AI Informatics für die Verifizierung einiger
Verfahrensschritte. Hervorheben möchte ich Virginia Stanger für Korrektu-
rarbeiten. Dem Lektor Herrn Christian Schneider und der Projektleitung Frau
Anna Plenk danke ich für die gute Beratung und Nachsicht bezüglich ausge-
fallener Gestaltungswünsche. Ganz besonderer Dank gebührt Frau Dr. Ingrid
Mikosch, Integrata Training, ohne deren fürsorgliche Betreuung und unendli-
che Geduld dieses Buch bestimmt nicht entstanden wäre.
Für Verbesserungsvorschläge und positive wie negative Kritik
(mailto: Reinhard.Hoehn@wien.ilf.com) bedanke ich mich bereits im voraus.
Reinhard Höhn, Perchtoldsdorf, Wien, März 2000
Vorwort 15
Einleitung
Ein Buch soll dem Leser etwas vermitteln. Jedes Buch folgt dabei einem
bestimmten Stil, einer gewissen Methodik. Im Folgenden wird kurz dargestellt,
wie diese Vermittlung in diesem Buch arrangiert ist.
✔ Welche Aufgaben sind für den Aufbau, den Betrieb und den Abbau eines
Data Warehouse abzuwickeln? Mit welchen Hilfsmittel können diese Aufga-
ben unterstützt werden?
✔ Welche Rollen sind für den Betrieb eines Data Warehouse erforderlich? Wel-
che Schulungen sind zum Aufbau der Rollen für ein Data Warehouse ratsam?
Das Vorgehensmodell zum Aufbau eines Data Warehouse (Kapitel 7)
Ein Vorhaben wie ein Data Warehouse aufzubauen ist sehr komplex und erfor-
dert eine Menge gut durchdachter Schritte. Die richtige Reihenfolge dieser
Schritte und die Hilfsmittel, die dieses Vorgehen vereinfachen, werden in einem
Vorgehensmodell festgehalten.
✔ Wie wird ein Software- und Hardwarevorhaben »Data Warehouse« abgewi-
ckelt, bzw. wie geht man am besten methodisch vor?
✔ Wozu dienen Softwaremodelle und wie ist ein Softwaremodell aufgebaut?
✔ Wie sieht speziell ein Data Warehouse Vorgehensmodell aus? Welche Ergeb-
nisse produzieren die Vorgehensphasen?
✔ Wie werden betriebswirtschaftliche Modelle entworfen? Welche Methoden
stehen bei der Modellierung eines Data Warehouse zur Verfügung?
Die Projektierung und der Betrieb eines Data Warehouse (Kapitel 8)
Mit der Projektierung wird das erarbeitete Wissen logisch in eine abwickelbare
Reihenfolge gebracht und mit Anforderungen an Ressourcen beurteilt. Es wird
Stellung bezogen, mit welchen Arbeitsmitteln, von welchem Personal, in wel-
cher Zeit die Aktivitäten für ein Data Warehouse umgesetzt werden können.
✔ Welche Phasen hat ein Data Warehouse Projekt? In welchen Schritten und
Meilensteinen wird ein Data Warehouse Projekt abgewickelt?
✔ Wie ist ein DWH-Projekt zu terminieren und zu budgetieren?
✔ Wie kann kann ein DWH-Projekt verfolgt werden?
Produktspektrum des Data Warehouse (Kapitel 9)
Wenn die Gestaltungsentscheidungen getroffen sind, hat man einen Wunsch-
zettel, dessen Umsetzung zur Realität ansteht. Mit diesen »Idealvorstellungen«
ist nun der Markt nach DWH-Produkten, die diese Anforderungen erfüllen, zu
untersuchen.
✔ Welche Tools unterstützen die Entwicklung eines Data Warehouse? Welche
Methoden sind als Tools realisiert? Wie wird eine dem Vorhaben angemes-
sene Toolauswahl evaluiert?
✔ Welche Produkte gibt es auf dem Markt und wie kann man diese beurteilen?
Wie sieht der Beschaffungsvorgang aus?
✔ Mit welchen Informationsquellen kann man die zukünftigen Bewegungen
im Data Warehouse Umfeld effizient verfolgen?
Vorwort 17
Orientierung Produkttypus
Interessen
Betriebsfunktion
Architektur
Software
Hardware
Organisation
Methoden, Ergebnisse
Projektierung A u f g a b e n , Te r m i n e
Personal, Qualifikation
Budget
Produkte Markt
Evaluation
Erneuerung, Abbau
Die Literaturliste
Kein Buch ist erschöpfend in allen Fragestellungen und deshalb ist je nach
Interesse vertiefende Literatur vonnöten. Einige Bücher unterliegen allerdings
einer solchen Zitierfreude, dass man sich fragen muss, ob ein Menschenleben
überhaupt ausreicht, um die genannten Quellen alle zu beschaffen. Sorgfältiges
Lesen allein reicht nicht aus. Hier wurde Mut gefasst, dem Trend nach immer
umfassenderen Literaturlisten nicht zu folgen, und statt dessen eine effiziente
Auswahl an kompetenten Titeln aus der unüberschaubaren Vielfalt der Veröf-
fentlichungen zu treffen. Weniger ist hier mehr. Diese kleine Literaturliste ist
dafür kommentiert und erlaubt eine schnelle Beurteilung, welches Buch für
den augenblicklichen Zweck am besten geeignet ist.
18 Vorwort
!!
"#$
%&
'(
(')*%
+
+,
$
-
(')*,
$
.
Über alle Etappen der Aufbereitung eines Themas werden, wenn nützlich, Defi-
nitionen eingesetzt. Definitionen dienen der Präzisierung der Begriffe und
durch die Verwendung präziser Begriffe werden Zuordnungen und Einordnung
in Bekanntes erleichtert und Missverständnisse reduziert. Mit Definitionen
werden Sachverhalte vergleichbar gemacht.
20 Vorwort
Zeichenerklärung
Gegenüber dem allgemeinen Text sollen bestimmte Aussagen zur besseren Ori-
entierung optisch hervorgehoben werden. Hierfür werden die folgenden Sym-
bole verwendet.
Das jeweils angestrebte Lernziel wird durch ein aufgeschlagenes Buch symboli-
siert:
Lernziel
Die bei einer Problemlösung abzuwickelnden Verfahrensschritte sind mit dem
folgenden Symbol gekennzeichnet:
❖ Verfahrensschritt
Ein wichtiger Begriff wird mittels einer Erklärung, einer Definition, präzisiert,
die durch eine schattierte Box hervorgehoben ist.
Für einen Literaturhinweis wird als Symbol der Aktendeckel verwendet.
Literaturhinweis
Auf einen Gestaltungshinweis wird durch eine Pfeilspitze aufmerksam
gemacht.
➢ Gestaltungshinweis
Eine wichtige Feststellung wird mit einem fetten Pfeil symbolisiert.
➡ Feststellung
Einige wenige Texte werden als Exkurs durch halbfetten Schriftsatz und Ein-
rahmung gekennzeichnet. Diese Informationen können auch zu einem späte-
ren Zeitpunkt gelesen werden.
Effizienz der Stromerzeugung zu erhöhen. Mit der Liberalisierung hat sich das
geändert und die Zukunft wird einen verstärkten Wettbewerb um Kunden auch
mit ausländischen Mitbewerbern bringen. Es ist bereits Direktbestellung von
Strom möglich. In Skandinavien sind sogar schon Strombörsen, die einem
Abnehmer erlauben, ganz gezielt einen Strom mit einer definierten Qualität
von einem von ihm bestimmbaren Hersteller zu einem bestimmten Tagespreis
zu beziehen, in die Praxis umgesetzt. Der Strompreis hängt maßgeblich von
der Effizienz der Produktion ab. Die Effizienz kann durch Verkürzung von Pro-
duktionsstillständen und Verringerung der Instandhaltungskosten erreicht
werden. Da die Instandhaltungskosten einen beträchtlichen Anteil an den Kos-
ten des Kraftwerksbetriebes betragen, sind diese von besonderem Interesse.
Eine technische Anlage wie ein Kraftwerk ist der Dynamik eines ständigen
Wandels ausgesetzt, die Instandhaltung ist deshalb ein permanenter Optimie-
rungsprozess. Zur Optimierung müssen Kenntnisse zum Verhalten der Anlagen
gesammelt werden. Zeiterscheinungen müssen anhand der gesammelten Werte
frühzeitig und voraussehend erkannt werden. Hier ist ein aussichtsreicher
Anwendungsbereich für Data Warehouse Funktionen.
Durch die Öffnung des Energiemarktes und die neuen Vertriebsformen, wie
Bestellung an der Tankstelle und über Internet, wird die Data Warehouse
Thematik auch für die Energieversorger für Marketingfragen interessant.
23
KAPITEL 1
1 Orientierung zum Thema Data Warehouse
Wenn man beschließt, sich mit einem neuen Thema zu befassen, dann mangelt
es noch an einer ausgereiften konkreten und vollständigen Vorstellung zu des-
sen Inhalten. Der erste Schritt soll daher das Ausleuchten des Themenumfelds
und das Feststellen der Beweggründe, sich mit dem Thema zu befassen, sein.
Anschließend wird eine Entscheidung getroffen, wie intensiv das Thema bear-
beitet werden soll. Dies mündet in die Definition einer Zielsetzung. Beschäftigt
man sich beruflich mit der Thematik, sind noch die Interessen des Arbeitgebers
von Bedeutung. Diese Fragen werden in drei Schritten abgearbeitet:
✔ Wie präsentiert sich das Thema Data Warehouse der Öffentlichkeit und um
welchen Gegenstand geht es bei diesem Thema grundsätzlich?
✔ Wie sind die Tendenzen aus dem Kontext der Data Warehouse Märkte und
wie werden diese das Thema zukünftig verändern?
✔ Welches sind die persönlichen Ziele und welches sind diejenigen Ziele, die
für den Auftraggeber erreicht werden sollen?
Das Kapitel ist entsprechend dieser Schritte gegliedert, wie in der folgenden
Abbildung »Kapitelübersicht« dargestellt ist.
$
%
!" #
&
#
Lernziel
Das Ziel des ersten Abschnitts ist die Orientierung im Umfeld des Themas und
die Einordnung des Themas in den eigenen Erfahrungsraum. Dies dient der
Vorbereitung für die Feststellung und Einordnung der persönlichen Situation
und der Unternehmenssituation, der Definition der Ziele und der Vorbereitung
des Data Warehouse Projekts.
Die Lernziele des zweiten Abschnitts konzentrieren sich auf die Orientierung
im Markt, die Einschätzung von technischen Tendenzen und die Frage, welche
Informationsquellen dabei hilfreich sein können.
Die Lernziele dieses Abschnitts bestehen außerdem aus der Befähigung, die
eigenen Ziele zu erkennen und diese klar darstellen zu können. Sie bestehen des
weiteren in der Ermittlung der Unternehmensziele und der Erkenntnis, dass die
Ziele des Unternehmens verfolgt werden müssen und nach außen zu vertreten
sind. Als Lernziel soll auch das Bewusstsein geweckt werden, dass Zielkonflikte
projektgefährdend sind und vor Projektbeginn aufgelöst werden müssen.
Nicht zuletzt geht es um die Erkenntnis, dass nicht jedes beliebige Ziel erreich-
bar ist und die Erreichbarkeit wesentlich von der eigenen Startqualifikation wie
auch von der Disposition des Unternehmens abhängt.
Lernziele
Kategorisierung des Themas Data Warehouse
Abgrenzung
Typisierung
von Data Warehouse gegen andere ähnliche Produkte,
Abgrenzung
Warehouse
des Marktsegmentes und der Konsumenten eines Data
Mit welcher Kategorie von Gegenständen, Handlungen oder Ideen muss man
sich auseinandersetzen, um ein Data Warehouse aufzubauen? Handelt es sich
um etwas Reales, aus Einzelteilen Zusammenbaubares? In diesem Fall braucht
man im Prinzip nur die einzelnen Bausteine zu beschaffen und die Konzentra-
tion der Arbeit kann auf den Zusammenbau gelegt werden. Oder handelt es sich
eher um etwas Ideelles? Dann kann die Beschäftigung mit dem Thema besten-
Kapitel 1 • Orientierung zum Thema Data Warehouse 27
Definition: Kategorien-Check
Der Kategorien-Check ist eine nach Abstraktionsgrad geordnete Liste von
Kategorien von Beschäftigungsgegenständen oder Denkkategorien mit Kri-
terien zur Beurteilung der Zugehörigkeit eines Sachverhalts zu den einzel-
nen Kategorien.
28 Kapitel 1 • Orientierung zum Thema Data Warehouse
Die Methode der Kategorisierung besteht nun einfach in der Auswertung des
eigenen Informationsumfelds bezüglich der Anzeichen des Themas und der
Zuordnung anhand der Kriterien. Wie oben schon erwähnt, sind die Anzeichen
in den Medien, in Schaufenstern von Geschäften, in Büchern und auch in
Gesprächen und auf Informationsabenden zu finden. Die Anzeichen der Spalte
»Präsentation« der Kategorienskala sind mit den »Entdeckungen« zu verglei-
chen. Es kann selbstverständlich jedes Thema mehrere Erscheinungsbilder in
den Medien haben und damit auch mehreren Kategorien genügen. Das fol-
gende Verfahren ist zu empfehlen:
Verfahren: Kategorien-Check
❖ Definition des Problems: Zu welcher Kategorie gehört ein Data Ware-
house?
❖ Auswahl der Medien (Internet, Bibliotheken, Zeitschriften, Berater...)
❖ Sammlung der Aussagen in den Medien
❖ Prüfung der Aussagen mittels Kategorienkriterium in der Kategorien-
skala
Kategorienliste
Dem Kategorien-Check liegt eine Kategorienliste zugrunde. Diese ist eine
Tabelle zur Einordnung eines Themas mittels einer geordneten Liste von Kate-
gorien und einiger unvollständiger, aber hinreichend vieler Kriterien zu den
Kategorien. Die Liste ist in dem Sinn geordnet, dass die Kategorien von oben
nach unten gelesen realer, anfassbarer werden. Der Abstraktionsgrad der Kate-
gorien dieser Liste ist also von oben nach unten abnehmend. Die Liste ist eine
Kategorienskala (siehe Tabelle 1.1).
Eine weitere Vertiefung des Themas Kategorisierung ist nicht erforderlich. Es
geht hier nur um den Nutzen für die folgenden Erörterungen und zu diesem
Zweck genügt eine erste Annäherung. Die Kategorienliste ist auch nicht allge-
meingültig, sondern bereits auf den Erfahrungsbereich der EDV zugeschnitten,
mit dem wir uns ja hier beschäftigen wollen.
✔ Kategorie Phänomen
Data Warehousing
✔ Kategorie Arbeitsprogramm
Data Warehouse Kooperationen, Standardisierungsgremium für Data
Warehouse, Data Warehouse Council
✔ Kategorie Methodik
Data Warehouse Vorgehensmodell, Methode ... des Data Warehousing
✔ Kategorie Prinzip
Data Warehousing Prinzip
✔ Kategorie Konzept
Data Warehouse Konzept, DWH-Richtlinien der ...
✔ Kategorie Organisationsform
Data Warehouse Spezialist, Data Warehouse Programmierer, Abteilung
für Data Warehouse Entwicklung
✔ Kategorie Technologie
Data Warehouse Herstellungsverfahren, ... zu kombinierende Rohpro-
dukte..., Data Warehouse Einbaukomponenten in ...
✔ Kategorie Software
Data Warehouse Programm
✔ Kategorie Softwaresystem
Data Warehouse Module, Data Mining Modul, Data Warehouse Kompo-
nente
✔ Kategorie Rechnersystem
Data Warehouse Rechner, Data Warehouse Server, Zugriffsperformance
✔ Kategorie Netzwerk
Data Warehouse Netzwerk, Data Warehouse Protokollschicht
✔ Kategorie EDV-Architektur
Data Warehouse Architektur, Data Warehouse Komponenten,
Kombination
✔ Kategorie EDV-Infrastruktur
Data Warehouse System
Man sieht, dass das Thema Data Warehouse viele Facetten hat. Es lässt sich
nicht einfach einer Kategorie zuordnen.
1.1.2 Produkttypisierung
Problemstellung und Motivation
Steht die Kategorie fest, kann man sich mit den Arten der Gegenstände der
Kategorie auseinandersetzen. Da sich die Kategorie des Data Warehouse aus
den Zeitungsartikeln als etwas Handfestes wie ein System aus Hardware und
Software zu erkennen gegeben hat, als ein Etwas, das sogar auf Märkten gehan-
delt wird, bietet sich als weitere Eingrenzung die Feststellung des Produkt-
Kapitel 1 • Orientierung zum Thema Data Warehouse 31
typus an. Wäre als Kategorie »Phänomen« festgestellt worden, wäre das natür-
lich nicht möglich gewesen und die weitere Arbeit am Thema eher abstrakt und
visionär geblieben.
Die kategorielle Einordnung ist bewusstseinsprägend für die gesamte Projekt-
zeit. Die Vorstellung eines Projektmanagers, eines zukünftigen Data Warehouse
Spezialisten und auch des IT-Vorstandes, ein komplexes System aus Software,
Hardware und Organisationsstrukturen zu entwerfen, führt zu ernsthafteren
Diskussionen als zum Beispiel bei Projekten, deren Ziel eine Studie ist. Studien
sind eher geistige Spielwiesen zur Generierung von Ideen und zur Findung von
Maßnahmen und Vorhaben. Ein Data Warehouse zu bauen ist bereits eine von
einem Vorstand veranlasste Maßnahme.
Die Erkenntnis des Produkttypus ist auch insofern nützlich, als sie bereits eine
Fokussierung der Aktivitäten auf ein Marktsegment und damit ein besseres
Haushalten mit den einzusetzenden Ressourcen ermöglicht. Aber auch die
organisatorische Zuständigkeit ist damit erkannt. Es ist klar, ob sich die Abtei-
lung Anwendungsentwicklung, das Rechenzentrum oder die Fachabteilung um
die Thematik kümmern muss. Bei der Fülle der heute gebotenen Informations-
möglichkeiten und den in immer kürzeren Zeitspannen zu erreichenden Pro-
jektzielen ist es nötig, schnell zum Punkt zu kommen.
Eine kleine Auswahl bekannter verwandter Systemtypen, bzw. der sie bezeich-
nenden Begriffe aus dem historischen Umfeld der Data Warehouse Systeme,
mag belegen, dass es der Mühe wert ist, etwas genauer abzugrenzen, was unter
dem Begriff Data Warehouse System zu verstehen ist.
✔ Management-Informationssysteme
✔ Decision Supporting Systems
✔ Executive Information Systems
✔ Knowledge Databases
✔ Frühwarnsystem
✔ Electronic Shopping System
Alle genannten Systeme lassen schon vom Namen her auf die Verfügbarkeit von
Informationen schließen. Das heißt, dass die Informationen nicht durch diese
Systeme durchgeschleust und umgewandelt werden oder zum Beispiel bei einer
Maschine einen Vorgang auslösen, sondern dass sie zum Aufruf, zur Verwen-
dung vorgehalten werden. Für das Lagern von Informationen sind heute Daten-
haltungssysteme zuständig. Die Verwandtschaft bzw. Ähnlichkeit der aufge-
zählten Systeme besteht also mindestens darin, dass sie datenbankbasiert sind.
Zum Verständnis: Es gibt auch Systeme ohne Schwerpunkt auf einer Basis-
Datenbank wie Produktionssteuerungssysteme, Prozesssteuerungssysteme. Es
gibt Systeme ohne Basisdatenbank wie zum Beispiel Kommunikationssysteme
32 Kapitel 1 • Orientierung zum Thema Data Warehouse
DBMS Database Management System System zur Definition von Datenstrukturen und
DBMS Datenbankmanagementsystem Verwaltung von Daten und deren Zugriffen
WFMS Workflow Management System System zur aktiven Steuerung der Aktivitäten
arbeitsteiliger Prozesse
Data Mart Data Mart Ein auf einen Nutzerkreis, wie zum Beispiel
eine Abteilung, eingeschränktes Data Ware-
house
Für die Durchführung einmaliger Vorhaben wird in der Regel keine dauerhafte
Organisation, sondern eine temporäre Organisation eingerichtet. Es ist also ein
relativ umfangreiches Projekt zu definieren.
➡ Der Aufbau eines DWH ist ein solcher einmaliger und länger dauernder Vor-
gang
– über mehrere Monate,
– mit Beteiligung mehrerer Personen unterschiedlicher Qualifikation aus
unterschiedlichen Abteilungen,
– die vorübergehend und wiederholt und zu unterschiedlichen Zeitpunkten
mit wechselnder Kapazität zusammenzuführen sind,
– ohne die Linienzuordnung aufzuheben,
– um einmalig verwendbare Ergebnisse zu produzieren.
Es muss daher eine neben der bestehenden Organisation funktionsfähige, tem-
poräre Teamorganisation mit eigenen Weisungswegen und Berichtswegen ein-
gerichtet werden. Eine bewährte Möglichkeit ist die Projektorganisation. Da die
Projektmitglieder zweifach unterstellt sind, nämlich dem Projektleiter und
dem Abteilungsleiter, und dies übersichtlich in einer Matrix dargestellt werden
kann, spricht man auch von einer Matrixorganisation.
Eine Projektorganisation ist die Basis für die Abwicklung von Projektaufgaben.
Für die Gestaltung der Projektorganisation muss daher Klarheit über die Auf-
gabenpakete, die Projektstruktur, gewonnen werden. Die Aufgaben der Projekt-
struktur werden zu zeitlich zusammengehörigen und gemeinsam abzuwickeln-
den Paketen gebündelt. Die Zeitabschnitte eines Aufgabenpakets werden
Phasen genannt.
Definition: Projektphase
Ein Projekt wird zur Überprüfung der Erreichbarkeit der gesetzten Ziele und
einer Bestimmung der nächsten Ziele in Arbeitsschritte mit einem definier-
ten Ergebnis zerlegt. Diese Arbeitsschritte heißen Projektphasen.
38 Kapitel 1 • Orientierung zum Thema Data Warehouse
Exkurs: Projektaufbau
Umfangreiche Projekte werden erfahrungsgemäß in überschaubare Schritte
eingeteilt und abgewickelt. Diese Schritte werden Projektphasen genannt. Es
gibt keine Faustregel, ab welcher Projektgröße (oder aufgrund welches ande-
ren Kriteriums) die Phasenstruktur erforderlich wäre. Daher gibt es Pro-
jekte, die Phasen noch weiter detaillieren, und andere Projekte, die kom-
plette Phasen überspringen. Die Abwicklung der Projektphasen besteht aus
der Erzeugung definierter Phasenergebnisse. Die Struktur des Phasenergeb-
nisses, also gewissermaßen seine Definition oder auch seine Spezifikation,
heißt Ergebnistyp.
Dem Projekt geht die Orientierung bezüglich der Aufgabenstellung, die
Suche nach Interessenten an den zukünftigen Ergebnissen und die Suche
nach Geldgebern, die Akquisition, die strategische Vorbereitung, die Defini-
tion unternehmerischer Ziele, Budget und Zeitrahmen, die Bestimmung
eines Vorstandssponsors bzw. die Zuordnung des Themas zu einem Vor-
standsressort und die Ernennung eines Projektverantwortlichen voraus.
Diese Vorphase heißt Projektinitiation. Ist das Projekt initiiert, bilden sich
die Projektphasen analog dem Ablauf einer Problemlösung.
Zuerst steht die Einordnung der Sache, Definition der Projektziele und eine
Grobbudgetierung und Rahmenterminierung, die sogenannte Projektierung
an.
Nach der Projektierung sind die fachlichen Inhalte und Ergebnisse zu akqui-
rieren und in einer verabredeten Form zu fixieren. Diese Phase besteht aus
der notwendigen Ist-Erhebung und Analyse bzw. der Interpretation der der-
zeitigen Situation. Ist man mit der Situation zufrieden oder stellt sich her-
aus, dass das Projekt zu keiner besseren Lösung führt, oder ist sogar die
Machbarkeit in Frage gestellt, wird das Projekt beendet. Diese Phase heißt
gewöhnlich Statusanalyse oder Ist-Erhebung. Werden sogar noch die Anfor-
derungen der Interessenten, wie bei einer Software zum Beispiel die Anwen-
derwünsche, miterhoben, spricht man auch von einer Anforderungsanalyse.
Kapitel 1 • Orientierung zum Thema Data Warehouse 39
Ist man mit dem augenblicklichen Zustand nicht zufrieden und ist die Mach-
barkeit ausreichend begründet, werden die Lösungsmöglichkeiten ermittelt.
Die Lösungsmöglichkeiten werden gegeneinander abgewogen, Vor- und
Nachteile festgestellt und die Entscheidung für eine Lösungsvariante gefällt.
Diese Variante wird gemäß den Anforderungen in einer ersten Annäherung
formuliert. Das Ergebnis ist in einer noch für Entscheider und Anwender
verständlichen Sprache und Symbolik gehalten, um deren Einverständnis für
die nächste Phase einholen zu können. Das Ergebnis ist eine fachliche Wis-
sensdarstellung, nicht zu verwechseln mit den fachlichen Anforderungen.
Diese Phase wird Konzeption oder Fachkonzeption, manchmal unglückli-
cherweise auch Grobkonzeption genannt.
Die Konzeption ist zwar noch in einer für Entscheider und Anwender ver-
ständlichen Sprache gehalten, aber für die Umsetzung ist diese Sprachart zu
ungenau. Der nächste Schritt besteht daher in der Präzisierung, z.B. in der
Formulierung klarer Handlungsanweisungen für Programmierer, Hersteller
oder Beschaffer. Je nachdem, ob beschafft wird, programmiert wird oder nur
Anpassungsarbeiten an einem gekauften Produkt zu leisten sind, ist die Ver-
wendung einer speziellen »Terminologie« erforderlich, die auch aus For-
meln, Strukturgrafiken oder Tabellen bestehen kann. Diese Phase wird Spe-
zifikation, Design oder Entwurf, manchmal unglücklicherweise auch
Feinkonzeption genannt.
Die Umsetzung der Spezifikation umfasst das Codieren in einer Program-
miersprache, das Testen in einer Laborumgebung, die Installation und das
Testen in der Betriebsumgebung. Diese Phase wird Realisation genannt.
Manchmal wird die Implementierung getrennt von der Realisation als eigene
Phase genannt, wenn zum Beispiel ein Probebetrieb durchgeführt wird.
Sind alle Tests abgeschlossen, die Entscheider zufrieden mit der Überein-
stimmung zwischen Konzeption und Lösung, die Anwender über Ergonomie
und Nutzen im Bilde, wird das System für den Betrieb freigegeben. Der
Betrieb umfasst wie bei einer gewöhnlichen Maschine Wartungsarbeiten,
Ausbesserung kleiner Fehler, Erneuerung und Austausch, aber auch die
Anwenderbetreuung und die Kontaktpflege zu den Herstellern. Diese Phase
wird Betrieb genannt.
Besteht keine ausreichende Nutzungsnachfrage mehr, wird der Betrieb ein-
gestellt und die Systeme werden abgebaut. Der Abbau umfasst die Migration
der Daten auf andere Systeme, die Destallation der Programme, das Abmon-
tieren der Hardware und den Weiterverkauf oder die Verschrottung. Diese
Phase wird Abbau genannt.
abhängen. Ein wichtiger Schritt im DWH-Projekt ist daher die Definition des
zu gestaltenden Gegenstandes, seiner Bestandteile, seiner Architektur. Ist die
Architektur klar, werden zu ihrer Herstellung Methoden überlegt.
Mit dem Vorgehensmodell wird sich später ein ganzes Kapitel (7) auseinander-
setzen; die Ergebnisse sollen hier nicht vorweggenommen werden, da sie ein
tieferes Verständnis darüber voraussetzen, woraus ein Data Warehouse besteht.
Beispiel
Die Kategorie des Vorhabens ist eine erste Annäherung an die noch zu treffen-
den Gestaltungsentscheidungen.
Beispiel: Produkttyp
Für das Instandhaltungsprojekt steht fest, dass für die gewünschten Erkennt-
nisse die gesamte Datenbasis, die zu einer kompletten Instandhaltungslösung
gebraucht wird, erforderlich ist. Auf dieser Datenbasis werden die Planung,
Kalkulation, Genehmigung, Durchführung, Verfolgung und Auswertung wie
auch die Ermittlung neuer Instandhaltungsstrategien, z.B. durch intelligente
Schadensauswertungen und Ausfallprognosen, operieren.
Spezielle Fragen, die mit dem System beantwortet werden sollen, sind:
✔ Welche Komponenten werden am häufigsten defekt?
✔ In welchen Anlagenteilen entstehen die meisten Reparaturen?
✔ Welche Komponenten werden unter welchen Umständen schneller
defekt?
✔ Kann für den ganzen Kraftwerkspark eine verteilte Ersatzteilhaltung
realisiert werden, ohne die Reparaturzeit zu verlängern?
✔ Welche Umwelteinflüsse spielen für den Bauteileausfall eine Rolle?
Kapitel 1 • Orientierung zum Thema Data Warehouse 41
Gestaltungsentscheidungen
Die bisher getroffenen Entscheidungen sind im Sinne eines Projektfortschritts
in der folgenden Tabelle »Entscheidungschart InDaWa Abgrenzung« festgehal-
ten. Diese Projektfortschrittsskala oder auch das Entscheidungschart, hat zu
diesem Zeitpunkt drei Ergebnisse aufzuweisen: die Kategorieeinordnung, den
Produkttyp und den Organisationstyp.
42 Kapitel 1 • Orientierung zum Thema Data Warehouse
ORIENTIERUNG
Abgrenzung
Markttendenzen
...
Zielsetzung
...
ARCHITEKTUR
...
VORGEHENSMODELL
...
PROJEKTIERUNG
...
BETRIEB
...
Es ist einfach abzuleiten, dass die Qualität eines Data Warehouse und der Fort-
schritt des Aufbaus von der Zulieferung von Produkten abhängig ist und damit
den Schwankungen der Märkte unterworfen ist. Der »Skalenstrich« Marktten-
denzen deutet an, dass hier ein Ergebnis zu erarbeiten ist. Auch die Erkenntnis,
wie weitergearbeitet werden muss, ist ein Projektfortschritt, der sich als neuer
Eintrag in der Projektfortschrittsskala zeigt.
Ebenso ist klar, dass ein Data Warehouse in eine bestehende Organisation ein-
gepasst werden muss und dass der Erfolg der Umsetzung von den Vorstellungen
und Widerständen der betroffenen Mitarbeiter aller Führungsebenen abhängt.
Ein Data Warehouse kann nur dann erfolgreich sein, wenn die Unternehmens-
ziele unterstützt werden und die persönlichen Ziele der Beteiligten berücksich-
tigt werden. Für die Projektfortschrittsskala bedeutet dies einen Eintrag »Ziel-
setzung«.
Es wurde festgestellt, dass ein Data Warehouse aufzubauen ein komplexes Vorha-
ben ist, das der Steuerung durch ein Vorgehensmodell mit definierten Zwischen-
ergebnissen und methodischen Hilfen bedarf. Das Vorgehensmodell ist von den
zu produzierenden Komponenten des Data Warehouse Systems abhängig.
Es wurde auch festgestellt, dass die Organisationsform »Projekt« erforderlich
ist. Ein Projekt muss mit Zielen, Terminen, Leistungen, Teilnehmern, Arbeits-
mitteln definiert werden. Für die Fortschrittsskala ergibt dies damit einen Ein-
trag »Projektierung«.
Damit sind die nächsten Projektetappen in Sicht.
Kapitel 1 • Orientierung zum Thema Data Warehouse 43
1.2.1 Informationsfindung
Problemstellung und Motivation
Ob man will oder nicht, man wird täglich pausenlos mit Informationen kon-
frontiert. Der Radiowecker mit neuesten Nachrichten, die Plakate, die Schlag-
zeilen der Tageszeitung, Verkehrssignale, die Gespräche mit Arbeitskollegen,
die Mail-Listen – man kann sich der Informationsflut kaum entziehen. Und es
bereitet Mühe, aus dieser großen Menge an Informationen diejenigen herausfil-
tern, die für die Arbeit benötigt werden. Man muss seinen Informationshaus-
halt organisieren, um effizienter zu den Informationen zu kommen, die wirk-
lich relevant sind.
➡ Informationen müssen selektiert werden.
Informationen können von einem Informationsmarkt bezogen werden, z.B.
durch ein Zeitungsabonnement oder über einen Fernsehanschluss. Diese Infor-
mationen haben einen Preis, sie müssen gekauft werden. Mit Informationen
wird gehandelt. Informationen sind eine begehrte Ware, wie die Abbildung
»Nutzung des Internets« unterstreichen soll (siehe Abbildung 1.4).
➡ Informationen sind eine Ware.
44 Kapitel 1 • Orientierung zum Thema Data Warehouse
Informationen haben eine Qualität wie reale Produkte. Sie können wider-
sprüchlich oder sogar völlig falsch sein. Sie können unsinnig und nichtssagend
sein, wie zum Beispiel die Aussage aus einem Buch zur Trainingslehre: »Taktik
sind taktische Situationen«. Sie können überfrachtet sein, wie in Pleonasmen
wie »weißer Schimmel«. Informationen können gehaltlos sein, wie zum Bei-
spiel die Aneinanderreihungen der allseits bekannten »Phrasendreschma-
schine«. Informationen können permanent und aufdringlich wiederholt wer-
den, wie zum Beispiel in Werbespots.
➡ Informationen haben einen Inhalt mit einem Wahrheitsgehalt und einem
Neuigkeitsgrad.
Kapitel 1 • Orientierung zum Thema Data Warehouse 45
Bis zum Mittelalter waren die Möglichkeiten der Weitergabe von Informationen
noch weitgehend begrenzt: Neben der mündlichen Mitteilung gab es z.B. akus-
tische Signale, Symbole oder handschriftliche Aufzeichnungen. Als dann im
Jahr 1450 der Buchdruck erfunden wurde, war erstmals die Massenauflage von
Informationen und damit ein höherer Verbreitungsgrad möglich, der noch
dazu wesentlich schneller erreicht wurde. Wie die folgende Grafik »Historische
Entwicklung der Medien« noch einmal unterstreicht, haben sich seitdem die
Träger der Information, die Aufbewahrungsmöglichkeiten, der Zugriff bzw. die
Zulieferung in rasender Geschwindigkeit weiterentwickelt. Die Technik hinter
den Datenträgern und der Zulieferung der Information wird durch neue techni-
sche Erfindungen auch weiterhin rasant fortschreiten.
➡ Informationen sind mittels Medien zu einem Transportgut geworden.
Auf eine gute Informationsbasis ist größte Sorgfalt zu legen. Ein Unternehmen,
das auf Informationssorgfalt keinen Wert legt, braucht auch kein Data Ware-
house. Ein Unternehmen, das auf Informiertsein Wert legt, muss das Informie-
ren organisieren. Eine hohe Form der Informationsorganisation ist die Infor-
mationsproduktion des Data Warehouse.
Gestaltungsraum und Lösungswege
Das hier diskutierte Gestaltungsobjekt betrifft also die Organisation des Infor-
miertseins, die Auswahl der Informationsquellen, die Bezugsform und den Pro-
zess der Auswertung. Hierzu gehört die Beantwortung der folgenden Fragen:
➢ Wo sind Informationen zu finden?
➢ Auf welchen Trägern bzw. Trägersystemen soll meine Information geliefert
werden?
➢ Welche Informationen sind zuverlässig? Welche Güte haben die Informatio-
nen? Wie aktuell sind die Informationen? Sind die Informationen handhab-
bar aufbereitet?
➢ In welchem Rhythmus muss ich meine Informationsrecherchen wiederho-
len?
➢ Wie sind die Informationen auszuwerten? Wie soll mit den Informationen
umgegangen werden? Wer soll die Informationen aufbereiten?
Es gibt noch eine Reihe weiterer Gestaltungsfragen im Umgang mit dem Roh-
stoff Information:
➢ Wer muss zu welchem Zeitpunkt welche Informationen zugeliefert bekom-
men?
➢ Wie präzise muss die Information sein?
➢ Was ist zu tun, wenn die Information nicht rechtzeitig vorliegt?
➢ Welchen Nutzen bietet die Information und zu welchem Preis muss ich sie
erwerben?
➢ Wie lange dauert die Nachbearbearbeitung und Aufbereitung der Informa-
tion?
➢ Unterliegt die Information der Hol- oder Bringschuld?
Verfahren: Informationsplanung
❖ Definition des Informationsproblems »Zu welchem Problem ist zu
recherchieren?«, und Definition der Schlagworte zur Suche mit Check-
liste Schlagworte Data Warehouse
❖ Auswahl der Informationsquellentypen mit Checkliste Medientypen und
Checkliste ausgewählte Zeitschriften
❖ Auswahl der speziellen Lieferanten mit einer Checkliste Zeitungen, einer
Checkliste Beratungsunternehmen und einem Literaturverzeichnis
❖ Entscheidung über Kontinuität, Frequenz und Bearbeiter der Auswertun-
gen im Informationsplan
Checkliste Medientypen
Mit Hilfe der Schlagworte wird in Informationsquellen oder Medien nach Infor-
mationen gesucht. Das setzt allerdings eine Entscheidung voraus, welche
Medien man auswerten möchte. Die Auswahl der Typen von Quellen ist über-
sichtlich in der Checkliste Medientypen dargestellt.
Kapitel 1 • Orientierung zum Thema Data Warehouse 49
Seminar Workshop a
Audiokassette Verlag a
Plakat Plakatwände u
Register Handelsregister
Zu einem Eintrag in die Checkliste führt die Beantwortung der folgenden Fra-
gen:
✔ Ist Data Warehouse Thema in Anzeigen der Hersteller und EDV-Zeitschrif-
ten? Ist Data Warehouse auch schon als Sonderteil der Zeitschrift xxx
behandelt worden? Hat die Zeitschrift die Artikel auch auf elektronischen
Medien zur Verfügung?
✔ Was sagen die Marktbeobachter? Für welche Marktbeobachter sollte man
sich interessieren? Wie äußern sie ihre Erkenntnisse und wie stark sind ihre
Erkenntnisse belastbar?
50 Kapitel 1 • Orientierung zum Thema Data Warehouse
Man sollte auch nach sogenannten »White Papers« fragen, in denen wesentlich
tiefer auf technische Details eingegangen wird. Die eigentliche Absicht der White
Papers ist, eine Zukunft der eigenen Produkte und Technologien zu entwerfen.
Der bekannteste deutschsprachige Katalog für Software ist der ISIS-Report. Der
am meisten verbreitete Katalog über Unternehmen und Unternehmensbeteili-
gungen ist das Hoppenstedt Unternehmensverzeichnis.
52 Kapitel 1 • Orientierung zum Thema Data Warehouse
Informationsplan
Nach der Entscheidung, welche Informationsquellentypen eingesetzt werden
sollen (wer zum Beispiel keinen Internetanschluss hat, kann sich nicht auf
Internetrecherchen beziehen), muss aus dem Angebot der Verlage, Hersteller,
Berater usw. eine konkrete Auswahl von Lieferanten ausgewählt werden.
Weiterhin ist zu unterscheiden, ob gezielt Information zu einem Problem
gesucht werden soll, oder ob regelmäßig der Überblick über die Neuerungen
eines Fachgebiets behalten werden soll. Der erste Fall ist eine gezielte Informa-
tionsrecherche. Im zweiten Fall handelt es sich um ein kontinuierliches Markt-
Monitoring, bestehend aus der Beobachtung des Marktes, der Marktteilnehmer,
der Konkurrenz, der Lieferanten, der Produzenten, der Institutionen und deren
Veröffentlichungen.
Ein nicht unerhebliches Problem bei der Auswertung der Informationen ist die
zunehmende Frühankündigung von Produkten. Mittlerweile ist die Produktan-
kündigung zum taktischen Instrument gegen den Mitbewerb geworden. Der
Unterschied zwischen der Verkündung des Erscheinungsdatums und dem tat-
sächlichen Erscheinen des Produkts ist oft groß und mitunter gibt es gar kein
Produkt. Es ist anzuraten, nach Messepräsentationen das besagte neuangekün-
digte Produkt probeweise zu bestellen. Ist es nicht wie versprochen lieferbar,
sollte man die Zusammenarbeit mit diesem Hersteller meiden. Unter Verspre-
chungen und falschen Erwartungen wird man über den gesamten Lebenszyklus
des Produkts leiden.
Informationssammlung und -aufbereitung ist aufwendig und ein Ressourcen-
problem und bedarf damit sorgfältiger Planung. In welchem Rhythmus muss
ich meine Informationsrecherchen wiederholen, zu welchem Termin muss die
benötigte Information verfügbar sein? Beschaffe ich die Informationen selbst
oder schalte ich einen Informationsbroker ein, der zwar teuer ist, aber doch viel
schneller das begehrte Objekt Information aufspürt?
Als Methode für das Marktmonitoring wie auch für die gezielte Informationsre-
cherche dient ein Informationsplan mit
✔ Nennung der Quellen (z.B. mit den Kürzeln der Lieferantenlisten)
✔ der beabsichtigten Auswertung (k – kontinuierlich, e – einmalig)
✔ Namen der auswertenden Bearbeiter
✔ Termin des Berichtens
Checkliste Beratungsunternehmen
Einige Informationsquellen können nur mit Hilfe kompetenter Berater ausge-
wertet werden. Die Charakteristik der Checkliste Beratungsunternehmen ist ein
Schnappschuss, ein Anhaltspunkt für eine Auswahl, da die Unternehmen ihr
Leistungsspektrum ständig den Forderungen des Marktes anpassen und auf
Anfrage sogar individuell und einmalig einen bestimmten Leistungstyp anbie-
54 Kapitel 1 • Orientierung zum Thema Data Warehouse
ten. Ein Kreuz in der Liste bedeutet, dass sich das Beratungsunternehmen durch
eine Publikation in dieser Sache geoutet hat. Die Auswahl wurde auf die ersten
zehn Unternehmen der sogenannten »Lünendonk-Liste 1998« eingeschränkt
(siehe Tabelle 1.7).
Firma Charakteristik A B C P K T S L M E
IDC Marktanalyst
Plaut-Gruppe IT-Consulting
debis Systemintegrator
Datev eG Systemintegrator
1.2.2 Trendanalyse
Problemstellung und Motivation
Der Markt ist bezüglich Produkttypen und Herstellern unüberschaubar groß
geworden und entzieht sich für Endkäufer der unmittelbaren Beobachtung.
Was ein Endkäufer vom Markt sieht, ist unvollständig und erklärungsbedürftig.
Kapitel 1 • Orientierung zum Thema Data Warehouse 55
Die Verpackung der Produkte wird immer verlockender, die Versprechen des
Vertriebs sind beharrlich. Das erste Problem, das es für den Data Warehouse
Manager zu lösen gilt, ist also die Objektivierung der Sichtweise. Die Aufgabe
dieses Projektschritts besteht damit aus der Festlegung
✔ der Quellenrecherche
✔ der Informationsbeschaffung
✔ der Informationsaufbereitung
✔ der Informationsauswertung
Das Data Warehouse besteht aus vielen unterschiedlichen technologischen
Komponenten. Die Komplexität der Komponentenstruktur zwingt dazu, die
Marktentwicklung der einzelnen Komponenten zu verfolgen. Es ist per se nicht
vorauszusehen, welche technologische Entwicklung in die Data Warehouse
Produkte einzieht bzw. welche Auswirkungen sie auf die technologische Ent-
wicklung von Data Warehouse hat. Daher ist es vorteilhaft, um Überraschungen
zu vermeiden, ein umfassendes Technologiemonitoring aufzubauen und perio-
disch die Relevanz der Strömungen für das Unternehmens-Data-Warehouse zu
hinterfragen.
Die Zukunft des Themas Data Warehouse ist leider nicht die Zukunft eines ein-
zelnen Produkts. Wie man im nächsten Kapitel sehen wird, sind im Data Ware-
house mehrere Produkttypen integriert und die Trends jedes dieser Produktty-
pen beeinflussen Erfolg und Misserfolg von Data Warehouse Projekten.
Solche Trendsituationen gab es zum Beispiel 1983, als das erste relationale
Datenbankmanagementsystem (Oracle) herauskam, 1989, als das erste Daten-
bankmanagementsystem (INGRES) einen Datenbank-Client mit grafischer
Bedienungsoberfäche auslieferte (unter OSF-Motif) und 1992, als der erste
Datenbank-Client mit grafischem, teilweise objektorientiertem 4GL Userinter-
face unter MS-Windows herauskam. Die Verkaufszahlen belegten, dass die
Unternehmen bereits gestartete Projekte nicht stoppten und auf die neue Tech-
nologie neu ausrichteten. Die Folge davon war, dass Standardsoftwarehersteller
Applikationen sogar dann noch mit zeichenorientierten Clients herausbrach-
ten, als die grafischen Oberflächen schon etabliert waren. Sehr viele Unterneh-
men haben demzufolge heute noch veraltete Technologien im Einsatz.
Die Informationsquellen-Recherche wurde im vorigen Kapitel behandelt. Man
hat nun eine Fülle von Informationen auszuwerten, bedient sich eines erfahre-
nen Beraters oder macht sich selbst an die Arbeit. Die Informationsaufberei-
tung besteht jetzt aus der Interpretation der Glaubwürdigkeit der Aussagen, der
Nachvollziehbarkeit der Schlüsse und der Belegbarkeit der Grundlagen. Man
wird hierbei mehrere Quellen nebeneinander legen, deren Erkenntnisse und
Empfehlungen vergleichen und sich eine eigene Meinung bilden, die dann
Grundlage für weitere Entscheidungen wird.
56 Kapitel 1 • Orientierung zum Thema Data Warehouse
Verfahren: Trendanalyse
❖ Bestimmung der relevanten Trendthemen
❖ Auswahl der Informationsquellen nach den Anforderungen an Aktualität,
Kontinuität, Qualität,
❖ Herstellen der Trendkarten einzelner Trends
❖ Zusammenführen der Trendkarten im Trendprofil
Die Trendschätzung
Die vom Management zu treffenden Entscheidungen zielen auf Maßnahmen
mit zukünftigen Wirkungen, basieren aber zwangsläufig auf den Erkenntnissen
aus Vergangenheit und Gegenwart. Die Methodenklasse der Extrapolation der
Erfahrungen auf die Zukunft ist die Trendschätzung. Die zukünftigen Auswir-
kungen der Maßnahmen sind in gleichem Maße von externen Tendenzen und
Trends wie von internem Bedarf abhängig. Der Erfolg der getroffenen Maßnah-
men hängt deshalb stark von der Genauigkeit der Einschätzung der Trends der
Unternehmensumwelt ab. Das sind aus der Sicht der EDV die innovativen Infor-
matiktechnologien und ihre Durchsetzung als Produkte auf dem Markt.
Voraussetzung für die Einschätzung von Trends ist
✔ Klassifizierung von Systemarten
✔ Klassifizierung von Schlüsseltechnologien
✔ eine Klassifizierung von Trends
✔ eine Darstellung der gegenseitigen Beeinflussung der Trends
✔ ein Katalog mit Umweltsignalen für die Einschätzung der Bewegung jedes
Trends
✔ Kategorisierung des Trends für das Betätigungsfeld des Unternehmens
Trendkarte
Die Methodenklasse Trendschätzung soll hier durch einen effizienten Vertreter,
die Trendkarte, repräsentiert werden. Das Ziel der Analyse der Technologie-
trends ist die Einschätzung der für die Erfüllung der Unternehmensaufgaben
relevanten Trends zur Stützung der Entscheidung, für welche Trends in wel-
chem Umfang (Aktivitäten, Budgets) die Zukunft der DV geöffnet werden sollte.
58 Kapitel 1 • Orientierung zum Thema Data Warehouse
Trendprofil
Die einzelnen Trendkarten sollten noch einmal übersichtlich in einem Trend-
profil zusammengefasst werden. Im folgenden Muster Trendprofil allgemeine
Technologien werden nur so viele technologische Felder aufgezählt werden, wie
sie aus Zeitschriften und Lehrbüchern zur Informatik bekannt sind und mit
den bisherigen Kenntnissen einen Einfluss auf die Technologie von Data Ware-
house vermuten lassen. Die genaue Bestückung des Trendprofils ist erst mit
dem Wissen der folgenden Kapitel, die sich mit den Architekturkomponenten
befassen, möglich.
60 Kapitel 1 • Orientierung zum Thema Data Warehouse
Maßnahme
Technologie Relevanz Trend
für DWH
Werkstoffe Keramik ohne
Erinnernde Metalle
Kristalline Gele
Makroformmoleküle
Workgrouping auswerten
Strategische Allianzen
Für die Beurteilung der Durchsetzungsfähigkeit eines vermuteten Trends ist
die Betrachtung der strategischen Allianzen ein gutes Hilfsmittel. Die Faustfor-
mel lautet:
➡ Wenn sich die großen Hersteller, die Key Player, einig sind, wird sich der
Trend in Form eines umfassenden Produktspektrums etablieren.
Kapitel 1 • Orientierung zum Thema Data Warehouse 61
Diese Einigkeit drückt sich zum Beispiel in der Zusammenarbeit und noch
deutlicher in der Neugründung von Standardisierungsgremien aus. Dies ist
noch keine Garantie für die Akzeptanz des Nachfragemarktes. Oft genug sind
diese Gremien auch genauso schnell wieder ohne Produkte von der Bildfläche
des EDV-Marktes verschwunden, wie sie aufgetaucht sind, wie zum Beispiel das
von IBM getriebene Projekt »Talligent«. Deshalb ist abzuwarten, bis die Mehr-
zahl der Mitbewerber mit Produkten aufwartet.
Schwieriger ist die Beurteilung konkurrierender Allianzen. Die Einschätzung
von Trends auf der Basis von gegenseitigen Wechselwirkungen ist äußerst auf-
wendig und Sache der Marktanalysten. Die Ergebnisse sollten in Form von Markt-
studien beschafft werden. Zur Analyse der Allianzsituation dient eine Bezie-
hungsmatrix der Kooperationen, was hier aber nicht weiter vertieft werden soll.
Schwierig ist ebenfalls die Beurteilung der Auswirkung eines sich durchsetzen-
den Trends auf andere Trends. So hat zum Beispiel der Bedarf nach grafischen
Oberflächen auch die Nachfrage nach Objektorientierung beflügelt. Für Analy-
sen dieser Art können sogenannte »Wirkungsgefüge« dargestellt werden. Der
Aufwand hierfür rechtfertigt das Ergebnis jedoch nicht.
Für IT-Trends sind lesenswert:
Hanker, Strategische Bedeutung
König, Informationstechnologie
Für IT-Trendanalysen sind nicht nur die IT-Trends zu beachten, sondern auch
politische und gesellschaftliche Strömungen, zu lesen in:
Kennedy, 21. Jahrhundert
Auch für das Data Warehouse des Beispielprojekts ist erst die Komponenten-
struktur herauszuarbeiten, bevor die relevanten Trends zur Beobachtung
ausgewählt werden können. Mit dem derzeitigen Wissensstand ist allerdings
schon eine erste Annäherung möglich, die im »vorläufigen« Trendprofil her-
ausgearbeitet ist.
Bear-
K Medium Bearbeitung Termin beiter
1 CT monatliche Auswertung mit Vortrag in Abteilungsbesprechung 1. Montag Müller
im Monat
5 IM, IS, WI Auswertung der methodologischen Aufsätze für die Integration bis Jahres- Müller
in ein bestehendes Vorgehensmodell ende
6 Instandhaltg. Auswertung der Aufsätze für Software zum Instandhaltungs- laufend Müller
mi management 2monatlich
Gestaltungsentscheidungen
Zusammengefasst ergeben sich die folgenden (hellgrau hinterlegten), das Pro-
jekt oder das Data Warehouse gestaltenden Entscheidungen. Für die Beobach-
tung der Markttendenzen werden kontinuierlich Informationsquellen ausge-
wertet und Trendcharts und Trendprofile erarbeitet. Die Projektvorbereitung
soll zunächst mit der Feststellung der persönlichen Zielsetzung starten, um sie
dann mit der Unternehmenszielsetzung zu vergleichen.
ORIENTIERUNG
Abgrenzung
Markttendenzen
Trends Verfolgung mit Trendchart und hohe Relevanz bezüglich Revision von
Technologiekarte Entscheidungen
Zielsetzung
Persönliche Zielsetzung
Unternehmenszielsetzung
ARCHITEKTUR
...
Verfahren: Qualifikationsstatus
❖ Auswahl eines Kenntnisfeldes und Zuordnung des bisherigen Tätigkeits-
feldes bzw. der Projektphase (Planung, Betrieb, Training) zu einem oder
mehreren Spalten mit Hilfe des Musters persönliches Kenntnisprofil
❖ Feststellen des »Ausprägungsgrades« durch Eintrag des Beschäftigungs-
levels
(K – Kenntnis, L – Leitung, M – Mitarbeit, D – Durchführung)
❖ Eintragung der Rolle
(P – Projektleitung, A – Analytiker, B – Berater...)
und der Branche
(F – Finanzdienstleister, I – Industrie, L – Landwirtschaft, H – Handel, Ö
– Öffentlicher Dienst)
Kenntnisprofil
Eine geeignete Methode zur Feststellung des persönlichen Startpunkts ist das
Kenntnisprofil. Ein Kenntnisprofil ist eine Matrix mit einer sortierten Liste von
Kenntnisfeldern (z.B. Sachthemen) und einem Maßstab für die Beschäfti-
gungstiefe der Kenntnis und deren Ausprägungsgrad. Hierfür ist das Muster
persönliches Kenntnisprofil entwickelt worden.
Für die Beschäftigungstiefe ist einmal die Phase des Projekts oder des Betriebs
ein Hinweis. Die fachliche Tiefe ist z.B. in der Konzeptionsphase stärker als in
der Planungsphase. Die Zuordnung der Tätigkeiten ist nicht immer ganz ein-
deutig möglich, deshalb sei eine kleine Zuordnungshilfe durch die folgende
Auflistung beigestellt.
✔ Unter Weiterbildung werden Lehrgänge, Zeitschriftenbezug, Teilnahme an
Arbeitskreisen, Mitgliedschaften subsumiert.
✔ Unter Strategische IT-Planung werden das Erstellen von Strategiepapieren,
DV-Rahmenplänen, Verwaltung eines IT-Projekteportfolios, Erstellung von
Vorstandsvorlagen subsumiert.
✔ Unter Projektierung werden Projektantrag, Planung, Budgetierung,
Beschaffung, Organisation subsumiert.
✔ Zur Konzeption gehört der fachliche Entwurf, die Erhebung des Informati-
ons- und Systembedarfes, Ist-Analyse und Wissensakquisition.
Kapitel 1 • Orientierung zum Thema Data Warehouse 67
Kenntnisprofil
Ausprägungsgrad
keine
Weiterbildung
Strategische Planung
Projektierung
Konzeption
Spezifikation
Realisation
Implementierung
Betrieb, Administration
Training
Service
Will man nicht planlos umherirren, ist persönliche Zielsetzung gefordert. Wer
ein Data Warehouse managen will, muss auch geplant vorgehen. Nur mit Pla-
nung ist das komplexe Gebilde auf überschaubare Handlungseinheiten und
Arbeitsschritte zu reduzieren. Planung setzt Zielsetzung voraus. Das Objekt der
Gestaltung ist zunächst einmal die persönliche Zielsetzung.
Zielsetzung beginnt oft mit einer kleinen Notiz auf einem Notizblock nach
einem Gespräch, während einer Geschäftsbesprechung, als spontane Idee oder
auf einem Spaziergang. Zielsetzungen werden aus Vorstellungen gewonnen,
von Gesprächspartnern übernommen oder auch angelesen. Zielfindung ist ein
kreativer Prozess.
Es empfiehlt sich, die gefundenen Projektziele schriftlich festzuhalten; das ent-
lastet das Erinnerungsvermögen und macht die Ziele für andere besser nach-
vollziehbar. Um auch später noch zu wissen, wie die Ziele zustande gekommen
sind, sollte neben dem Ziel noch eine Begründung mit aufgeführt werden. Der
Gestaltungvorgang umfasst also neben der Zielfindung auch die Zieledokumen-
tation.
Die Ziele müssen erreichbar sein. Zum Prozess der Zielsetzung gehört damit
auch die Umsetzbarkeitsprüfung. Die Umsetzbarkeit hängt vom Startpunkt ab.
Für den Projekterfolg kann es zwei Hindernisse geben. Einmal kann der man-
gelnde Reifegrad des Unternehmens zu Fehlentscheidungen und Projekt-
hemmnissen führen. Der Reifegrad des Unternehmens ist eine nur sehr schwer
messbare Eigenschaft. Zum anderen kann die Konfliktsituation zwischen per-
sönlicher Zielsetzung und Zielsetzung der Unternehmung zum Stillstand des
Projekts führen.
Ziele einer Zieleliste können schon in sich logisch widersprüchlich sein, sich
gegenseitig ausschließen, im Konflikt zueinander stehen. Die Zieleliste bedarf
dann einer Aufhebung der im Konflikt stehenden Ziele, einer Zielkonfliktberei-
nigung.
Zusammengefasst müssen Ziele folgende Eigenschaften erfüllen:
✔ Definiertheit, Nachvollziehbarkeit, Dokumentiertheit
✔ Verfolgbarkeit, Überprüfbarkeit, Messbarkeit
✔ Widerspruchsfreiheit
✔ Konfliktfreiheit
✔ Erreichbarkeit
✔ Umsetzbarkeit
Der Gestaltungsvorgang der Zielsetzung umfasst daher mit dem vorher Gesag-
ten die Arbeitsschritte
➢ Findung von Zielen
➢ Definition der Zielsetzung
➢ Bereinigung der Zielkonflikte
➢ Dokumentation der vereinbarten Ziele
Problemlösung: Regeln und Hilfsmittel
Das Verfahren
Die Zielsetzung wird also in zwei Schritten erreicht. Zunächst wird die allge-
meine persönliche Zieleliste aufgestellt und im zweiten Schritt wird ein beson-
deres Ziel, das Qualifikationsziel, detailliert herausgearbeitet. Der Projekterfolg
ist ganz erheblich von der Qualifikation der Mitarbeiter und deren Lernbe-
reitschft abhängig. Deshalb wird dem Ziel »Höherqualifizierung« besondere
Aufmerksamkeit gewidmet.
Nagel, Brauchlin verwiesen.
Nagel, 200 Strategien
Brauchlin, Problemlösung
72 Kapitel 1 • Orientierung zum Thema Data Warehouse
8 Übung in Präsentationen
Mittel und Methode zur Festlegung und laufenden Überprüfung des Fort-
schritts nach jedem Seminarabschnitt ist die persönliche Zieleliste. Die Ziele
müssen aber auch überprüfbar formuliert werden. Nicht überprüfbar ist z.B.
Wissensgewinn, bessere Orientierung oder verbesserter Überblick aufgrund der
zu großen Allgemeinheit der Formulierung. Für die Prüfung der Wider-
spruchsfreiheit hilft nur logisches Denkvermögen.
Qualifikationsziel
Die Erreichbarkeit der Qualifikationsziele hängt, wie bereits dargestellt, auch
vom persönlichen Kenntnisstand ab. Dieser Ausgangszustand, die augenblickli-
che Qualifikation, der Wissenstand wurde im Kenntnisprofil dargestellt.
Für die Auseinandersetzung mit einem neuen Gegenstand muss zunächst ein
entsprechendes Wissen aufgebaut werden. Dies muss als persönliche Ziel-
Kapitel 1 • Orientierung zum Thema Data Warehouse 73
setzung zur Qualifikation als zweite Kurve in dem bereits für den Qualifikati-
onsstatus verwendeten Kenntnisprofil festgehalten werden. So kann zum Bei-
spiel ein Ziel darin bestehen, dass im Kenntnisprofil zu einem Eintrag »keine
Kenntnis« bezüglich Zeile »Data Warehouse » ein Eintrag »Projektierung«
gesellt wird. Neben diesem Ziel, das z.B. Jahresziel sein kann, kann dann noch
eine weitere Kurve mit der Kennzeichnung »Konzeption« oder sogar »Betrieb«
als Fernziel eingetragen werden. Das Kenntnisprofil kann für die drei Kurven
✔ der Qualifikationsstatus als Qualifikations-Ist-Kurve
✔ das Qualifikationssoll als Qualifikationszielkurve
✔ das Jahresqualifikationsziel in einer Jahresqualifikationszielkurve
verwendet werden.
Mittels der Zielkurve kann der Abstand zur Statuskurve, das Kenntnisprofil,
gemessen werden. Die Differenzen entsprechen dem Ausbildungs- und Praxis-
bedarf.
Neben den Zielen des Unternehmens und der zuständigen Abteilungen hat das
Projekt selbst auch Ziele, die Projektziele. Die Projektziele sind den Unterneh-
menszielen untergeordnet. Sie müssen mit den Unternehmenszielen harmo-
nieren. Sie sind eine Verfeinerung der Unternehmensziele und als solche wie-
der Unternehmensziele. Sie müssen vom Projektleiter in das Projektteam
kommuniziert werden.
Das Beispiel »Unternehmenszielsetzung: Zieldreieck der Integrata-Gruppe«
stellt einen Interessen-Tripol in den Mittelpunkt der Unternehmenszielsetzung.
Die Zielsetzung des Unternehmens richtet sich aus
✔ auf die Zufriedenheit der Kunden mit den Leistungen des Unternehmens
✔ auf die Versorgung der Mitarbeiter als soziale Aufgabe des Unternehmens
✔ auf die Erfüllung der Vorstellung der Gesellschafter zur wirtschaftlichen
Zielsetzung
Kapitel 1 • Orientierung zum Thema Data Warehouse 75
Die Projektziele sind den privaten Zielen übergeordnet. Sie müssen mit den
privaten Zielen der Projektteilnehmer harmonieren. Der Gestaltungsraum defi-
niert sich hierbei in der Wahl der Mittel zur Überprüfung der Konfliktfreiheit.
➢ Feststellung der Zielkonflikte der beteiligten Organisationseinheiten und
Personen
Checkliste Firmenziele
Die Firmenziele entdeckt man unter anderem im Jahresbericht der Firma, in
Aushängen am schwarzen Brett, in Pressemitteilungen, in Vorträgen der
Geschäftsführung, in einem Firmenkodex, in der Unternehmenspolitik. Dies
weist auf die bereits behandelte Problematik der Informationsfindung hin und
wird nicht weiter erörtert.
Bleibt noch zu definieren, mit welcher Methode die aus den Informationsquel-
len abgeleiteten Ziele zu dokumentieren sind. Der hier vorgestellte Vorschlag
ist die Checkliste Firmenziele, die die Projektziele bereits umfasst. Zur Orien-
tierung wurden einige aus der Praxis bekannte Ziele eingetragen, die es im rea-
len Projekt noch einmal zu prüfen, zu kürzen und auch zu ergänzen gilt (siehe
Tabelle 1.16).
Zieleharmoniematrix
Für die kritische Prüfung der Harmonie zwischen Firmenzielen und Privatzie-
len ist hier eine Zieleharmoniematrix ausgewählt worden, da ja jedes Privatziel
gegen jedes Firmenziel diskutiert werden muss. Die Anwendung ist einfach, es
ist jedes Feld der Matrix mit einem Urteilskennzeichen entsprechend der eige-
nen Einschätzung zu versehen (siehe Tabelle 1.17).
Kapitel 1 • Orientierung zum Thema Data Warehouse 77
4 Technologieeinstieg
6 Know-how-Aufbau Know-how-Profil
7 Entwicklung Data-Warehouse-Produkt
Privatziele
Unternehmenziele 1 2 3 4 5 6 7 8 9 10 11
Kostenreduktion für Prozess xxx
Verkürzung der Servicezeiten für xxx
Kundenanalyse
Technologieeinstieg
Erfahrungen sammeln durch Pilotprojekt
Know-how-Aufbau
Entwicklung Data Warehouse Produkt
Verbesserung Kundenauskünfte
Bereinigung Produktefeld
Bei großen Projekten ist das Risiko, aufgrund einer Zieldisharmonie in Schief-
lage zu geraten, groß. Die Einschätzung sollte deshalb von der Projektleitung
durchgeführt werden. Ebenso ist die Beurteilung der Startqualifikation eine
Aufgabe der Projektleitung.
Jeder Angestellte einer Firma hat private Ziele. Diese Ziele müssen nicht immer
die Ziele der Firma sein. Doch die Firmenziele sollen Vorrang haben. Ein desin-
teressierter oder überforderter Data Warehouse Projektleiter wird das Projekt
»Aufbau eines unternehmensweiten Data Warehouse« nicht realisieren kön-
nen. Sollten Firmenziele und eigene Zielsetzung absolut nicht zusammenpas-
sen, kann das nur die Zuteilung der Aufgabe zugunsten einer anderen Person
bedeuten. Ein kritischer Erfolgsfaktor ist damit die Verträglichkeit der privaten
Ziele mit den Firmenzielen.
➡ KEF: Harmonie zwischen privaten Zielen und Projektzielen
➡ KEF: Qualifikationslevel und Lernbereitschaft
Hier sei noch einmal verdeutlicht, dass es Widerstände zu besänftigen gilt, dass
die »Neinsager« positiv überzeugt werden müssen, dass Projekterfolge bekannt
werden müssen. Hierfür ist eine Kommunikationsplattform und die Erlaubnis,
diese für das Projekt einsetzen zu dürfen, erforderlich. Solche Kommunikati-
onsmöglichkeiten sind zum Beispiel Artikel in der Hauszeitschrift, schwarzes
Brett, Mailings, Intranetseite, interne Präsentationen für zukünftige Anwender
und für die Führungsbene.
➡ KEF: Kommunikationsmöglichkeit der Projektergebnisse
Ein DWH kann nur das auswerten, was in Datenbeständen verfügbar ist.
Abschottung von Datenbeständen, schlecht gepflegte, unvollständige Daten-
sammlungen kann das beste DWH nicht ausgleichen.
➡ KEF: Datenqualität
Know-how-Level, Kultur und Bereitschaft, neue Projekte durchzuführen, sind
Nährboden oder Risiken. Nur wenn beide Faktoren
✔ Zielsetzung ist sinnvoll
✔ Startposition ist aussichtsreich
zusammenpassen, kann man von der Durchführbarkeit eines Vorhabens ausge-
hen.
In einem Data Warehouse ist fachliches Wissen abgebildet. Dieses Wissen muss
allerdings erst in den Fachabteilungen ermittelt werden. Die Fachleute müssen
motiviert werden, ihr Wissen preiszugeben und dokumentieren zu lassen. Das
ist nicht immer einfach, da dieses Wissen ihren Arbeitsplatz sichert. Wenn diese
Fachleute ihr Wissen in einem EDV-System verwirklicht sehen, werden sie
Ängste entwickeln, ihre Arbeitsleistung messbar zu machen und ersetzbar zu
sein. Sie bangen um ihre Existenzgrundlage, ihren Arbeitsplatz. Der Data
Warehouse Manager muss sich also in die Lage seiner Interviewpartner ver-
setzen können und sie zur Mitarbeit motivieren können. Dies sind sehr hohe
Ansprüche an die kommunikativen Fähigkeiten und die soziale Kompetenz.
✔ Systemanalyse: Kommunikation, Sozialkompetenz, Präsentation, Statu-
serhebung, Wissensakquisition, Fachkonzeption
Das Ergebnis eines Data Warehouse ist ein aus Hardware- und Softwarekom-
ponenten zusammengesetztes System, das über eine IT-Infrastruktur, wie
zum Beispiel öffentliche Netze oder Firmennetze, kommuniziert. Die Soft-
warekomponenten werden entsprechend der Fachkonzeption definiert und
gekauft oder selbst entwickelt. Kaufentscheidungen erfordern eine Marktbe-
trachtung auf der Basis einer Kriterienliste. Selbst bei einem Kauf werden
noch Anpassungsarbeiten erforderlich sein. Anpassungsarbeiten, Eigenent-
wicklung wie auch die Beschaffungskriterien müssen in einer Spezifikation
von Hardware und Software fixiert werden. Der Data Warehouse Manager
muss daher Kenntnisse über das Arbeitsfeld des Systemingenieurs besitzen.
✔ Systemengineering: Spezifikation von Hardware- und Softwarekompo-
nenten, Netzkenntnisse, Beschaffung, Evaluation, Schnittstellendefinition
Die spezifizierten Komponenten werden programmiert oder beschafft. Die
selbstentwickelten Programme müssen unter Ausschluss der Öffentlichkeit
getestet, korrigiert und wie auch die gekauften Programme in die bestehende
EDV integriert werden. Der Anwender wird eine Testphase mit Verbesserungs-
vorschlägen begleiten. Es ist nicht wünschenswert, einem Data Warehouse
Manager bei der Vielfalt seiner Anforderungen auch noch Programmierarbei-
ten (C, C++, 4GL, SQL, ...) abzuverlangen. Er muss allerdings selbst das Data
Warehouse anwenden können, und dazu gehören die Enduser-Programmier-
arbeiten mit einer Makrosprache bzw. mit programmierfreien Tools.
✔ Realisierung: Customizing, Reporterstellung, Datennavigation
Das fertige System wird dann für den Betrieb freigegeben und Wartungsar-
beiten und Auskunftsdienste stehen an. In dieser Phase muss der Data Ware-
house Manager den Systembetrieb, die Anrufung der Herstellerservices und
die Anwenderbetreuung beherrschen.
✔ Betrieb: Systemadministration, Helpdesk, Datenbankadministration,
Hardwareservice, Tuning
Die Rolle eines Data Warehouse Spezialisten ist also eine Vereinigung mehrerer
Rollen. Wie tief das Wissen, wie gut die Fertigkeit im Umgang mit diesen Rollen
sein muss, ist von Unternehmen zu Unternehmen, von Projekt zu Projekt ver-
schieden. Genauer wird dies in Kapitel 6 »Organisation« behandelt.
Kapitel 1 • Orientierung zum Thema Data Warehouse 83
Beispiel
Für das Beispielprojekt ist die Zielsetzung des Unternehmens – es handelt sich
um ein Stromversorgungsunternehmen mit mehreren Kraftwerken – von
Bedeutung. Der Betreiber beabsichtigt, einen Auftrag für ein umfassendes Aus-
wertungssystem von Instandhaltungsdaten zu vergeben. Jedes Kraftwerk ist ein
betriebswirtschaftliches Unternehmen, das heißt, es muss unter dem optimalen
Einsatz von Ressourcen einen Output, in diesem Falle Strom, erzeugen. Durch
technologische Neuerungen in Bauteilen, Komponenten, durch Qualifizierung
von Mitarbeitern, Verbesserung von Arbeitsprozessen, Verkürzung von Still-
standszeiten kann der Ressourceneinsatz ständig optimiert werden. Hierzu ist
allerdings eine größere Transparenz der Produktionsfaktoren des Gesamtsys-
tems erforderlich. Ein großer Kostenfaktor davon ist die Instandhaltung.
Als kritische Erfolgsfaktoren sieht man die Dauer des Projekts an.
Die Datensammlung ist vollständig und detailliert. Personelle Interessen-
konflikte sind nicht zu befürchten. Die Budgetierung des Projekts ist unge-
fährdet, da alle Verbesserungen unmittelbare Kosteneinsparungen bei
Instandhaltungskosten haben. Ein Vorstandsmitglied ist nicht erforderlich,
das Sponsoring übernimmt der Instandhaltungsleiter.
Zu diesem Zeitpunkt ist der gesamte Umfang des Projekts noch nicht bekannt
und deshalb kann noch kein einigermaßen stabiler Projektumfang definiert
werden. Aber der Wille kann mit der Zieldefinition dargestellt werden. Die Ziel-
definition ist die Voraussetzung für ein Commitment der Entscheidungsebene:
»Jawohl, wir sehen diese Ziele genauso, hätten aber gerne noch diese und jene
Korrektur und stellen dafür erst einmal ein Budget von xxx Euro zur Verfü-
gung.«
Die Hauptzielsetzung ist, ein »Projekt zum Aufbau und Betrieb eines Data
Warehouse« abzuwickeln. Um die Möglichkeit des Abbrechens überhaupt zu
bekommen, wird ein Projekt in Abschnitte eingeteilt, die Phasen genannt wer-
den, wie bereits im Exkurs »Projektphasen« dargestellt wurde.
Beispiel: Projektphasen
Der »Rahmenplan des Projekts«, der noch keine für ein Data Warehouse spe-
zifischen Schritte enthält, soll die allseits bewährten Projektstrukturen aus
Individualentwicklung, Standardsoftwareprojekten und Infrastrukturvorha-
ben aufnehmen. Im Einzelnen sind dies also die im Exkurs »Projektphasen«
aufgezählten Phasen:
✔ Projektinitiation und Projektierung
✔ Anforderungsanalyse
✔ Konzeption
✔ Spezifikation
✔ Realisierung
✔ Betrieb
Es gibt derzeit im Kraftwerksunternehmen kein Vorgehensmodells für die
Softwareentwicklung. Deshalb muss mit dem Projektstart eine Ausarbeitung
der Phaseninhalte im Rahmen eines schlanken »Vorgehensmodells« durch-
geführt werden.
✔ Vorgehensmodell
Der Gegenstand des Vorgehensmodells wird mit den Architekturentschei-
dungen des Data Warehouse bestimmt. Das bedeutet für die Projektfort-
schrittsskala, dass vor dem Schritt »Vorgehensmodell« ein Schritt »Architek-
turabgrenzung« erfolgen muss.
Kapitel 1 • Orientierung zum Thema Data Warehouse 85
✔ Architektur
Vor diesen Strukturfestlegungen wird das eigentliche Data Warehouse Pro-
jekt mit den bekannten Aufgaben von Softwareprojekten projektiert.
Gestaltungsentscheidungen
Mit diesen Festlegungen sind zwar keine Gestaltungsentscheidungen getroffen
worden, aber die weiteren Projektschritte definiert, und diese können als wei-
tere Skaleneinträge des Projektfortschritts festgehalten werden.
Alle Entscheidungen der noch folgenden Kapitel zum Beispielprojekt InDaWa
werden weiterhin musterhaft in dem vorgestellten Entscheidungschart
»Gestaltungsentscheidungen und Projektfortschritt InDaWa« festgehalten. Das
Entscheidungschart ist eine Checkliste mit Gestaltungsaspekten, der zugehöri-
gen Entscheidung und einer Begründung dieser Entscheidung. Mit Hilfe des
Entscheidungscharts bleiben die Entscheidungen langfristig nachvollziehbar
und können bei Veränderungen von Rahmenbedingungen gezielt auf weiteren
Bestand geprüft werden. Die Verwendung einer solchen Entscheidungsdoku-
mentation ist jedem Projekt anzuraten.
ORIENTIERUNG
Abgrenzung
Markttendenzen
Zielsetzung
1.4 Übungen
Übung 1.1: Stellenbeschreibung
Leiten Sie aus der folgenden Stellenanzeige ab, zu welcher Kategorie der
Beschäftigungsgegenstand »Data Warehouse« nach Meinung des Inserenten
gehört und welchen Produkttyp er darin sieht.
86 Kapitel 1 • Orientierung zum Thema Data Warehouse
MIS
OLAPS
DSS
XPS
Data Warehouse
EIS
Kategorie
Komplexes Mensch-
Maschine-EDV-System
DB-basiertes Informations-
system
Umweltausschnitt
IT-Markt
Umfeldausschnitt
Unternehmenszielsetzung
Personenziele
Kritische Erfolgsfaktoren
Der dritte Schritt endlich ließ die Zielsetzung formulieren. Die Zielsetzung ist
vom Status, also der augenblicklichen Situation von Unternehmen und von den
Umwelttendenzen abhängig. Der Erfolg ist von den Fähigkeiten und vom Wil-
len des Projektleiters abhängig. Die Zielsetzung betrifft den Umfeldausschnitt
aus Unternehmen und Personen. Die Erreichung der Zielsetzung hängt von
sogenannten kritischen Erfolgsfaktoren (KEF) ab.
Aus den bisherigen Erkenntnissen konnte bereits ein einigermaßen genaues
Qualifikationsbild vom Data Warehouse Manager und ein, wenn auch nicht tief-
gehendes, Qualifikationsbild für andere Data Warehouse Spezialisten gezeich-
net werden.
91
KAPITEL 2
2 Was ist eine Architektur eines
Informationssystems?
Überblick
Zunächst wird der Begriff »Architektur« vorgestellt. Danach wird die Frage
nach der Nützlichkeit des Denkens in Architekturen gestellt. Dies wird einmal
für die EDV allgemein und danach für das Data Warehouse im Speziellen
durchgeführt.
Architekturen von Informationssystemen
IT-Systeme sind komplexe Mensch-Maschine-Systeme. Es wird gezeigt, dass
Architekturkonzepte ein nützliches Mittel zur Strukturierung solcher komplexer
Systeme bzw. zur Gewinnung eines besseren Überblickes über bestehende Sys-
teme sind. Es wird weiter gezeigt, dass das Denken in Architekturen die Thematik
von IT-Systemen kategorisieren lässt. Dies bedeutet, dass alle IT-Systeme, und
damit auch DWH, weitgehend schrittweise durch Bearbeitung der IT-Kategorien
analysiert und auch aufgebaut werden können. Diese Kategorien oder Architek-
tursichten sind Betriebswirtschaft, Software, Hardware und Organisation.
Die erste dieser wesentlichen IT-Kategorien, in der Reihenfolge der Analyse, ist
zunächst die Kategorie, die den Zweck des IT-Systems bestimmt. Für betriebs-
wirtschaftliche Anwendungen ist dies die Definition der betriebswirtschaftli-
chen Aufgabenstellung. Dieser Begriff wird hier sehr allgemein verwendet, also
übergreifend auch für die Aufgaben Prozesssteuerung und Signalgebung. DWH
wird in der Literatur eher auf die Beantwortung von Fragen aus dem Control-
ling oder Marketing fokussiert. Die Nützlichkeit von DWH wird an ihrem Bei-
trag zur Verbesserung von Unternehmensprozessen gemessen. Die Gesamtheit
der betriebswirtschaftlichen Funktionen ist die betriebswirtschaftliche Struk-
tur oder betriebswirtschaftliche Architektur des DWH.
Die betriebswirtschaftliche Aufgabenstellung wird durch Funktionen von Pro-
grammen unterstützt und mitunter vollkommen ersetzt. Man denke etwa an
den Versand eines Serienbriefes durch eMails anstelle des Postweges. Die
betriebswirtschaftliche Aufgabenstellung schränkt das Feld der Möglichkeiten
auf bestimmte Programmtypen und bestimmte Softwaretechnologien ein. Für
jeden Anwendertyp ist eine andere Softwaretechnologie geeignet. So kann z.B.
einer Führungskraft nicht zugemutet werden, mit einer Programmiersprache
eine Datenbankabfrage durchzuführen. Ein Anwender der Führungsebene
sollte die Möglichkeit bekommen, mit einer Fachsprache auf Daten zugreifen
zu können. Die betriebswirtschaftliche Aufgabenstellung gibt die Bedingungen
für die Software-Architektur vor.
92 Kapitel 2 • Was ist eine Architektur eines Informationssystems?
Software wird auf einem Rechnersystem ausgeführt, das im einfachsten Fall ein
isolierter Rechner in einem Gehäuse und im komplexen Fall ein weltweit ver-
netztes System mehrerer Rechner ist. Die Softwaretypen stellen wiederum
besondere Anforderungen an die Hardware und die Betriebssysteme dieser
Rechnersysteme. Wenn also die IT-Kategorie der Softwaretypen festgelegt ist,
kann die IT-Kategorie Hardware aus den noch frei bleibenden Möglichkeiten
bestimmt werden. Die Gesamtheit der Hardwarekomponenten und ihrer Ver-
netzung ist die Hardware-Architektur.
Als letzte Kategorie ist die Organisation, die zum Betreiben des komplexen Sys-
tems DWH erforderlich ist, herauszufinden. Die Rechner müssen beschafft, die
Software installiert, die Anwender geschult werden. Bei allem Fortschritt in der
Automatisierung ist der Mensch doch noch nicht ersetzbar und für die Durch-
führung dieser Tätigkeiten sind Handlungen von Menschen zu koordinieren.
Dazu müssen Kompetenzen eingeräumt und Know-how aufgebaut werden. Es
ist zu organisieren und Organisationsstruktur zu schaffen.
Die Architektur des DWH-Systems besteht damit aus Komponenten, Modulen,
Baugruppen, Einheiten der vier IT-Kategorien
✔ Betriebswirtschaftliche Komponenten
✔ Softwarekomponenten
✔ Hardwarekomponenten
✔ Organisationsstruktur
Der Aufbau der Kapitel zur Architektur
Die Architekturen werden demzufolge nach einer allgemeinen Darstellung der
Bedeutung von Architekturen in vier Schritten entwickelt. Die folgende Abbil-
dung gibt einen Überblick über die Gliederung der Kapitel zur Architektur von
DWH-Systemen, die (in Kapitel 2-6) dieser IT-kategorialen Betrachtungsweise
folgt.
Abbildung 2.1: Gliederung der Kapitel zur Architektur von Data Warehouse Systemen
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 93
Die weitere Aufgabe des Kapitels »Architekturen« ist die Aufschlüsselung dieser
vier IT-Kategorien in Systeme, Teilsysteme, Komponenten und Module. Das
Ziel ist ja der Aufbau eines DWH. Ein DWH gibt es nicht »von der Stange« zu
kaufen, sondern es muss aus »Einzelteilen« zusammengesetzt werden. Einige
dieser Einzelteile können gekauft, andere müssen als Einzelstück entwickelt
werden. Das Ziel der weiteren Zerlegung ist damit abgesteckt: Die Betrachtung
der IT-Kategorien muss so weit detailliert werden, dass am Ende Einheiten in
der Größe definierter erwerbbarer Marktprodukte oder spezifizierbarer Einzel-
fertigungen vorliegen. Dieses Vorgehen stellt einen Mikrozyklus innerhalb des
Makrozyklus dar.
Lernziel
Das Lernziel dieses Abschnitts ist damit die Erschließung des Architekturbe-
griffes und die Anwendung des Denkens in Architekturen auf die Ausgestaltung
der Data Warehouse Lösungen.
Lernziele
Erkennen und Bedeutung des Architekturbegriffes
Kennenlernen
Systems
der Schichten der Architektur eines komplexen EDV-
✔ Der prozessuale Ansatz fragt: »In welcher Folge passiert etwas oder in
welcher Reihenfolge laufen Aktionen oder Aktivitäten des untersuchten Sys-
tems ab?«. Das Ergebnis dieser Sichtweise ist eine Ablaufdarstellung.
✔ Der strukturale Ansatz fragt danach, woraus das System besteht. Er fragt
nach den Bestandteilen des Systems und wie diese Bestandteile zusammen-
gehören. Das Ergebnis ist eine Komponentenliste oder ein Strukturdia-
gramm, eine Architektur.
✔ Der datenorientierte Ansatz fragt nach den zu verarbeitenden Daten. Das
Ergebnis dieser Sichtweise ist eine Datensammlung oder sogar ein Daten-
modell.
Diese Liste ist nicht vollständig. Es gibt auch noch andere Ansätze, wie zum
Beispiel der Input-Output-Ansatz, der die Unterschiede zwischen eingehenden
und herauskommenden Daten oder Stoffen untersucht. Der Input-Output-
Ansatz verfolgt dies mit dem Ziel herauszufinden, was diese Unterschiede
bewirkt hat, oder anders gesagt, was im System ist und wie es die Daten verar-
beitet.
Es gibt auch Ansätze, die nicht nach den »gegenständlichen Eigenschaften« des
Untersuchungsgegenstandes (Funktion, Struktur, Prozess, Information) geglie-
dert sind, sondern nach der Perspektive der Vorgehensweise wie Bottom-Up,
Top-Down, Inside-Out, Outside-In. Beim Top-Down-Prinzip wird von der
Gesamtsicht zu immer feineren Details vorgangen. Beim Bottom-Up-Prinzip
wird von den Details eines Systems der Gesamtzusammenhang erarbeitet. Das
Outside-In-Prinzip startet mit der Sicht von »außen« auf das System und
nähert sich dem inneren Aufbau über die von außen sichtbaren Bestandteile
und Reaktionen. Beim Inside-Out-Prinzip, nimmt man sich der Reihe nach die
inneren Bestandteile des Systems vor, geht zu den Schnittstellen zur Außen-
welt und betrachtet dann die Systemumgebung und deren Aufbau.
Es gibt einzelne Typologien für die Systemanalyse, aber es ist leider keine voll-
ständige Klassifikation von Ansätzen zu einer Analyse von Systemen und einer
entsprechenden Ableitung für DV-Systeme bekannt. Es ist auch nicht bekannt,
ob es eine solche vollständige Typisierung geben kann, oder ob es unendlich
viele Möglichkeiten gibt. Man muss sich aus bekannten Ansätzen den der Situa-
tion entsprechend geeignetsten Ansatz auswählen.
Hier kann nicht weiter auf das Thema Systemanalyse eingegangen werden. Wer
sich intensiv mit dem Thema Systemanalyse oder der übergreifenden Thematik
der allgemeinen Problemlösung auseinandersetzen möchte, dem sei empfoh-
len:
Daenzer, Systems Engineering
Brauchlin, Problemlösung
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 95
Schritt 1 Daten und Informationen Feststellung aller Prozesse Feststellung der Funktionen
Schritt 2 Aufnahme der Funktionen Ableitung der Gesamt- Ermittlung der von den Funk-
struktur tionen verarbeiteten Daten
Schritt 3 Bündelung der Funktionen zu Feststellung der Funktionen Feststellung der Koppelung
Modulen und einer Gesamt- von Funktionen zu Prozessen
struktur
Schritt 4 Prozesse über alle Teile der Feststellung der von den Funk- Zusammenführung von Funk-
Struktur tionen verarbeiteten Daten tionen zu Funktionsgruppen
und Strukturen
2.2.1 Übersicht
Die Welt ist zu komplex, um sie als Ganzes begreifen oder gar als Ganzes gestal-
ten zu können. Aber man möchte ja nicht die ganze Welt, sondern nur einen
interessanten Ausschnitt der Welt verstehen und davon wiederum nur einen
kleineren Ausschnitt gestalten. Bezüglich des Themas DWH ist dieser Weltaus-
schnitt ein komplexes EDV-System eines Unternehmens. Den »Rest der Welt«
darf man nicht völlig außer Acht lassen. Ganz ohne Betrachtung der Umwelt ist
keine EDV-Systemgestaltung möglich. Das EDV-System und besonders ein
Informationssystem muss ja mit der Umwelt im Datenaustausch stehen.
Der zu gestaltende Weltausschnitt wird in handhabbare, begreifbare Teile zer-
legt, die man nacheinander analysiert. Um das zerlegte Etwas wieder zu einem
Ganzen zusammenfügen zu können, merkt man sich, wie die Teile zusammen-
gehören. Die einzelnen Scheiben und der Bauplan ihres Zusammenfügens zu
einem Ganzen ist eine Architektur. Die Betrachtung eines Gegenstandes als
Architektur ist ein Mittel, ein komplexes unüberschaubares Gebilde in kleinere,
behandelbare Teile zu zerlegen, ein Mittel der Komplexitätsreduktion.
Der Architekturbegriff ist als Mittel der Komplexitätsreduktion in allen Wissen-
schaftsbereichen verwendbar und keineswegs eine Spezialität der EDV. In der
Biologie spricht man z.B. vom Aufbau oder der »Architektur« einer Zelle, in der
Medizin von der Anatomie oder »Architektur« des menschlichen Gehirns. Am
gebräuchlichsten jedoch ist der Architekturbegriff im Baubereich, ob man nun
von der Architektur eines Hauses oder einer technischen Großanlage, von Gar-
ten- oder von Landschaftsarchitektur, von Außen- oder von Innenarchitektur
spricht.
Auch in abstrakteren Bereichen lässt sich der Architekturbegriff anwenden.
Zum Beispiel kann in der Betriebswirtschaft von der Architektur eines Kon-
zerns die Rede sein. In der Politik wird von der Architektur eines Staates, in der
Rechtswissenschaft von der Architektur von Verträgen gesprochen.
Immer dient die Verwendung des Architekturbegriffs zur Beschreibung der
Gestalt und Funktion eines komplexen Gegenstandes anhand seiner Bestand-
teile und seines Zusammenbaus. Die Teile werden aufgezählt und in einer Liste
geführt, die nach einer bestimmten Systematik erstellt ist. Für den Zusammen-
bau dient ein Bauplan.
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 97
Definition: Architektur
Eine Architektur ist die Gesamtheit von definierten einzelnen Elementen
und die Beschreibung ihrer Zusammensetzung zu einer Struktur. Die
Beschreibung der Zusammensetzung der Architektur ist der Bauplan.
0 Kraftwerk
Die folgenden beiden Abbildungen zeigen die Zerlegung der Beispiele 1 und 2.
Das Schema des Kennzeichnungssystems KKS ist im Kapitel 7 dargestellt, da es
dort zur Definition von Datenverdichtungsstufen dient. Das Beispiel belegt:
Architekturen sind Strukturen mit Funktionen. D.h. die Elemente der Archi-
tektur erfüllen eine Aufgabe oder Funktion.
Das KKS ist hier nicht nur wegen seiner konsequent strukturierten hierarchi-
schen Zerlegung und damit einer vollständigen Systematik aller Bestandteile
einer komplexen Kraftwerksanlage interessant. Die Hierarchie dient analog der
Gliederung einer Organisation nach Bereichen, Abteilungen und Stellen als
Vorlage zur Akkumulation von Zahlenwerten. Und das ist, wie noch gezeigt
wird, eine der Aufgaben eines DWH.
Als nächstes soll auf die Granularität und die Stufen der Zerlegung der Archi-
tekturen, die Architekturebenen, eingegangen werden.
Der Blickwinkel, der ein Anlagenaggregat erfassen soll, umfasst die Gesamtan-
lage nicht mehr. Die Konstruktionszeichnung des Pumpenaggregates füllt ein
Zeichnungsblatt vollständig aus. Das Zeichnungsblatt der Gesamtanlage ist in
einem Maßstab gezeichnet, der die Pumpe nur als Punkt erscheinen lässt. Je
nach Detailierungsstufe konzentriert sich der Blick auf einen anderen Aspekt
der Struktur. Je nach Zielsetzung der Betrachtung ist eine mehr oder weniger
detaillierte Stufe der Betrachtung erforderlich. Um die Architektur als Gesam-
tes zu erfassen, sind mehrere Zerlegungsstufen zu analysieren.
Nicht nur der Blickwinkel verändert sich. Je nach Blickwinkel müssen auch
andere Darstellungs- und Analysemethoden herangezogen werden, um das
Wesentliche transparent werden zu lassen. Diesen Methoden ist das Kapitel 7
»Vorgehensmodell« gewidmet.
Die Architektur ist also von der Nähe der Betrachtung, der Feinheit, der Granu-
larität der Auflösung abhängig. Architekturen setzen sich aus feineren Archi-
tekturen zusammen. Diese Architekturzerlegung in immer detailliertere Teile
soll nun auf EDV-Systeme angewandt werden.
Ein WAN besteht aus den Strecken der Kommunikationsnetze der Länder.
Diese sind aufgrund völlig unterschiedlicher Historien technologisch und
rechtlich stark unterschiedlich und mühsam zu integrieren. Die WAN-Strecken
der Landesnetze und Interkontinentalstrecken sind über Kopplungskompo-
nenten, wie z.B. Router und Sendestationen, verbunden.
Die Landesnetze können privat (z.B. Firmenlandesnetze) und öffentlich (z.B.
das Postnetz) sein. Die Landesnetze setzen sich aus den Überlandnetzen und
Haus- oder Firmengeländenetzen, den Local Area Networks, kurz LAN, zusam-
men. Die LANs sind in Segmente unterteilt, die für sich wieder kleinere LANs
darstellen. Die LAN-Segmente sind mit aktiven und passiven Komponenten wie
Bridges, Router, Switches, Hubs miteinander verbunden.
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 101
Abbildung 2.5: Architektur des Datenbank Managementsystems CA-Ingres
tem läuft. Es wird nicht der Bau eines Rechners sein. Der Gestaltungsfrage
nähert man sich damit durch Beantwortung der Fragen:
✔ Welche Architekturebenen sind für ein Data Warehouse zu gestalten?
✔ Wie ist ein optimaler Weg durch diese Architekturebenen zu finden?
Aus den Zerlegungsschritten der Architektur sind über alle Beipiele hinweg je
nach Zerlegungstiefe verschieden große Granulate entstanden. Es ist daher ein
Sprachgebrauch nützlich, der unabhängig vom zu zerlegenden Objekt die Zer-
legungsstufe kennzeichnet. Für die weitere Gestaltungsthematik werden die
Begriffe der folgenden Abbildung »Namen der Zerlegungsstufen« verwendet.
Am Ende dieses Weges soll man alle für ein DWH wichtigen Gestaltungsent-
scheidungen zur Architektur getroffen haben. Im folgenden Abschnitt sollen
diese Architekturkategorien ermittelt werden.
Diese Gestaltung ist übrigens, so wie sie hier für ein DWH vorgeschlagen wird,
genauso für klassische Datenbankanwendungen einsetzbar wie für Data
Warehouses.
!
#
Neben den eigentlichen Daten werden noch Modelle zur Interpretation der
Daten aufbewahrt. Die Daten des DWH werden auf logische Zusammenhänge
und Wechselwirkungen untersucht und dem Benutzer in Form hypothetischer
Erkenntnisse, wie zum Beispiel Prognosen für zukünftige Marktentwicklungen,
dargeboten. Hierfür sind in einem DWH besondere Analysewerkzeuge inte-
griert. Die zweite wesentliche Eigenschaft eines DWH sind die Auswertungs-
funktionen der Daten und Modelle.
Da die gesuchten Erkenntnisse oft sehr komplex sind, sind Visualisierungshil-
fen und eine große Bandbreite unterschiedlicher Darstellungsmittel erforder-
lich. Die DWH enthalten dazu Tools zur Präsentation von Modellen und Daten
wie Tabellen, Grafiken, multidimensionale Matrizen, Landkarten, Beziehungs-
netze. Die dritte wesentliche Eigenschaft eines DWH ist also die Darstellung
komplexer Datenstrukturen.
106 Kapitel 2 • Was ist eine Architektur eines Informationssystems?
Die Eigenschaften des Data Warehouse seien noch einmal abgrenzend zusam-
mengefasst. Eine genaue Definition kann erst später im Kapitel 4 »Software-
komponenten« gegeben werden.
Das Diagramm kann zu diesem Zeitpunkt der Betrachtung nur eine erste Über-
sicht, eine Orientierungshilfe für den Durchlauf durch den Gestaltungsraum
sein. Die leeren Kästchen symbolisieren weitere hierarchische Zerlegungsstu-
fen. Die einzelnen Untergliederungen werden in den folgenden Kapiteln suk-
zessive erarbeitet und mit Entscheidungsalternativen gefüllt. Wenn die leeren
Kästchen mit Entscheidungsalternativen gefüllt sind, handelt es sich um den
Gestaltungsraum der DWH-Lösung.
Restriktionen der Gestaltungsentscheidung
Die Reihenfolge ist nicht in jeder Unternehmenssituation gleich. Restriktionen
durch bereits im Vorfeld oder auch außerhalb der DWH-Thematik getroffene
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 111
Mit dieser Folge von Schritten steht der Gang des Projekts zum Aufbau des
DWH im Groben fest. Die genauere Ausdifferenzierung der einzelnen IT-
Kategorien erfolgt in den folgenden Kapiteln.
Die Abhängigkeit noch nicht getroffener Entscheidungen von bereits getroffe-
nen Entscheidungen wird im folgenden Kapitel beispielhaft gezeigt.
Abhängigkeit der Komponentenentscheidungen
Die Komponentenentscheidungen gehorchen wechselseitigen Einschränkun-
gen. Das heißt, hat man sich bezüglich einer Komponente entschieden, dann
sind für die anderen Komponenten nicht mehr alle Möglichkeiten vorhanden.
Dies soll an einem Beispiel dargestellt werden.
Es soll eine Situation skizziert werden, aus der abgeleitet werden kann und
wird, welche Schritte übersprungen werden können, weil eine Unternehmens-
situation zu Restriktionen führt.
Beispiel: Beschaffungsentscheidung
Ein Unternehmen, das vor kurzer Zeit auf ein neues Datenbanksystem umge-
stellt hat, hat sich mit großer Wahrscheinlichkeit ein relationales Daten-
bank-Managementsystem beschafft. Die relationale Datenbank wird dann
entweder in einem Pilotprojekt für einen neuen Applikationsbereich aufge-
baut oder für die Ablösung alter Applikationen auf der Basis einer hierarchi-
schen Datenbank eingerichtet. In den meisten Fällen ist mit der Entschei-
dung, eine relationale Datenbank einzusetzen, die Folgeentscheidung, von
den bestehenden hierarchischen Datenbanken und File-Systemen in die rela-
tionale Welt zu migrieren, getroffen worden.
Wenn man neu entwickeln will, wird man dies mit neuen Werkzeugen
machen wollen. Also mit Objektorientierung, SQL-Abfragen, grafischen
Oberflächen, Programmiersprache der vierten Generation. Der Zugriff auf
die Daten der relationalen Datenbank erfordert Programme mit der Abfrage-
sprache SQL, was bedeutet, dass die Applikationen neu entwickelt werden
müssen.
Da die meisten relationalen Datenbanken in Client/Server-Technologie und
sogar mit objektorientierten Bedieneroberflächen hergestellt sind, zieht
diese Entscheidung eine Hardwarerestriktion nach sich: Es werden ein oder
mehrere zusätzliche Rechner für den Client-Teil benötigt. Objektorientie-
rung setzt immer anstelle eines Terminals einen Client-Rechner voraus.
Bezüglich des Server-Rechners bleibt noch die Freiheit, den vorhandenen
Host zu nutzen oder einen neuen Server für den Betrieb der relationalen
Datenbank zusätzlich zu installieren. Da die alten Terminal/Host-Anwendun-
gen noch eine ganze Weile betrieben werden müssen, heißt dies, dass auf
dem Client eine Terminalemulation installiert werden muss.
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 113
Für die Data Warehouse Lösung bedeutet dies wiederum: Die Datenhaltung
des DWH muss Schnittstellen zum beschafften relationalen Datenbankpro-
dukt und zur Hostdatenhaltung bekommen. Die Client-Komponenten des
DWH müssen auf den Client-Rechnern der Datenbank-Clients installiert
werden können.
Für die Methodik ist die Entity-Relationship-Modellierung unumgänglich.
Bei großen Datenmodellen sollte die Tabelle des Textverarbeitungsprogram-
mes und die Bleistiftzeichnung dem Einsatz eines CASE-Tools oder eines
Datenmodell-Entwurfstools weichen.
Noch einmal übersichtlich zusammengefasst ergibt sich folgendes Argumen-
tationsschema, aus dem die Restriktionen hervorgehen. Aus den Restriktio-
nen ergibt sich der folgende Entscheidungsdurchlauf.
Entscheidung: Beschaffung relationales Datenbank-Managementsystem
➥ Migration von File-Systemen und hierarchischen Datenbanken
➥ Einsatz von 4GL oder OO-Technologien grafische Oberflächen
➥ Migration von Terminal/Host-Applikationen zu Client/Server-
Applikationen
➥ Installation von Client-Stationen
➥ Verwendung des Host als Server
➥ Terminalemulation alter Anwendungen auf grafischem Client
➥ DWH-Komponente mit Zugriff auf relationale Datenbank
➥ Client-Hardware für DWH möglichst wie Datenbank-Client
➥ Methodik: Entity Relationship Modellierung
➥ Einsatz von CASE-Tools
Die Einrückung der Pfeile zeigt die Abhängigkeit einer Entscheidung von
der in der vorangehenden Zeile getroffenen Entscheidung an.
Ein DWH ist also ein komplexes System, das teilweise durch Zukauf und teil-
weise durch Eigenentwicklung von Bestandteilen oder Komponenten aufge-
baut werden muss. Aus der Erfahrung mit anderen Informationssystemen
wurde festgestellt, dass sich die Bestandteile in vier wesentliche Kategorien
gruppieren lassen. Die Gestaltungsfrage lautet damit: »Welche Komponenten
sind zu gestalten?« und »In welcher Reihenfolge ist diese Gestaltung zu durch-
laufen?«
Die Gestaltungsaufgabe, ein DWH zu strukturieren, besteht also zunächst aus
den Schritten zur Bestimmung der IT-Kategorien:
➢ Bestimmung der betriebswirtschaftlichen Funktionen
➢ Festlegung der Softwaretechnologie und Auswahl der Softwaretools
➢ Auswahl der optimalen Hardware und Netzinfrastruktur
➢ Entwurf einer Organisationsstruktur
Alle Schritte werden von unterstützenden Methoden und Werkzeugen beglei-
tet. Die Auswahl dieser Methoden und der als Tools realisierten Methoden
gehört zur Gestaltungsaufgabe. Als Tool sollten dabei auch schon elektronische
Formulare, Formatvorlagen, Mustertexte und Tabellen mit Hilfswerten akzep-
tiert werden.
➢ Bestimmung oder Entwicklung der zu verwendenden Methoden
➢ Auswahl oder Eigenentwicklung der Tools zu den bestimmten Methoden
Diese Liste enthält nur konzeptionelle bzw. spezifizierende Aktivitäten. Mit der
Konzeption bzw. Spezifikation eines DWH ist noch kein Stück Software instal-
liert, keine Person eingestellt oder ausgebildet und noch kein Rechner aufge-
baut. Auf die Konzeption und Spezifizierung folgt also noch die Umsetzung.
Diese kann aus Beschaffung von Produkten und zugekauften Leistungen beste-
hen oder auch aus Eigenleistungen. Die Umsetzung folgt genau in umgekehr-
ter Reihenfolge wie die Konzeption. Zur Beschaffung ist Organisation erforder-
lich, für die Installation von Software muss Hardware aufgebaut sein, für die
Entwicklung von betriebswirtschaftlichen Programmen sind Software-
Entwicklungswerkzeuge zu installieren.
➢ Implementierung einer Organisationsstruktur
➢ Evaluation, Beschaffung und Installation der optimalen Hardware und
Netzinfrastruktur
➢ Evaluation, Kauf und Installation der Softwarekomponenten und
Softwaretools
➢ Programmierung oder Kauf und Integration der betriebswirtschaftlichen
Funktionen
Die Produktelandschaft wandelt sich heute so schnell, dass man bei der
Beschaffung bereits auch die Abschaffung in Betracht ziehen muss. Dies ist
umso wichtiger geworden, als die Bestimmungen zum Schutz der Umwelt
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 115
Der erste Schritt ist durch die Feststellung der zu gestaltenden Kategorien –
betriebswirtschaftliche Funktionen, Softwarekomponenten, Hardwarekompo-
116 Kapitel 2 • Was ist eine Architektur eines Informationssystems?
Als Hilfsmittel der Problemlösung ist zunächst eine Übersicht über die Katego-
rien und die ihnen zugeordneten, zu bestimmenden Komponenten erforderlich.
Die verschiedenen Komponenten können nicht unabhängig voneinander
gewählt werden, da die Wahl der einen Komponente die Auswahlmöglichkeiten
der anderen Komponenten wesentlich einschränken kann. Es wurde bereits die
gegenseitige Bedingungsfolge festgestellt. Aber nicht jede Komponente hat
Einfluss auf die Wahl der anderen Komponenten. Deshalb lässt sich ein linearer
Weg durch das Netz der Komponentenbeziehungen finden.
Die Struktur des Weges ist bis zur Komponentenebene bereits im Text im Dia-
gramm »Struktur des Gestaltungsweges des Data Warehouse« dargestellt
(Abbildung 2.9).
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 117
Einen anderen Ansatz zur Gestaltung von Data Warehouse Systemen zeigt:
Gill, Computing Guide
Darstellungen zum Gesamtzusammenhang von Architekturkomponenten bei
betriebswirtschaftlichen Aufgabenstellungen, Rechnern, Software und Organi-
sation findet man in:
Hansen, Wirtschaftsinformatik
Beispiel
Der nächste Schritt im Beispielprojekt ist also die Erfassung der Restriktionen,
um den Gestaltungsspielraum abzugrenzen.
Beispiel: Gestaltungsrestriktionen
Bezüglich des Beispielprojekts sind folgende Restriktionen, im Rahmen
derer alle Gestaltungsentscheidungen getroffen werden müssen, festgestellt
worden:
✔ IT-Kategorie: Betriebswirtschaftliche Aufgaben
Daten der Instandhaltung der Kraftwerksanlagen sollen ohne Prozessda-
ten, Analysen zur Optimierung der Ersatzteilvorhaltung, Reduktion der
Reparaturzeiten zu verschiedenen Ereignissen und Ausfallsprognosen
verfügbar gemacht werden.
Instandhaltung
✔ IT-Kategorie: Softwaretechnologie
Der Einstieg in eine neue Technologie mit Zukunft ist willkommen, soll
aber ausgereift sein, kein Experimentierfeld der Hersteller sein und die
Möglichkeit der Migration bieten, ohne viel Eigenentwicklung zu indu-
zieren. Die Daten sollen regional transparent verteilbar sein. Zugriff auf
kürzlich eingeführte relationale Datenbank muss möglich sein, Replika-
tion ist täglich erforderlich.
Replikative Schnittstelle zu relationaler Datenbank
Prototyping und Öffnung für Objektorientierung Client-seitig
✔ IT-Kategorie: Hardwaretechnologie
Da die Last der Anwendungen noch völlig unklar ist, soll die Hardware
erweiterbar, also skalierbar sein. Die bestehenden Hostnetze sollen nicht
verwendet werden.
Replikative Schnittstelle zu relationaler Datenbank
✔ IT-Kategorie: Organisation
Das Projektteam soll den Betrieb begleiten, das Betriebsteam soll im Pro-
jekt qualifiziert werden. Die Erkenntnisse von vielen Kraftwerken sollen
in das Projekt einfließen und umgekehrt sollen alle Kraftwerke die Pro-
jektergebnisse nutzen können.
Einsatz eines Lenkungsausschusses mit Vertretern
der einzelnen Kraftwerke
Abwicklung als Projekt mit Aufbau der Mitglieder für Betrieb
der Applikation
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 119
Gestaltungsentscheidungen
Diese Erkenntnisse sind wohlgemerkt nur die Restriktionen für die in den
nächsten Kapiteln folgenden DWH-Gestaltungsentscheidungen des Instandhal-
tungssystems.
Entscheidung/
Gestaltungsaspekt Erkenntnis Begründung
ORIENTIERUNG
...
ARCHITEKTUR
2.6 Übungen
Übung 2.1: Architektur
Schildern Sie, was Sie unter dem Begriff »Architektur« verstehen, und zählen
Sie die Architekturkategorien von Informationssystemen auf.
Übung 2.2: Architektur-Zooming
Zählen Sie die im Bild des Architektur-Zooming vorgestellten Zerlegungsebe-
nen auf und ordnen Sie diese den IT-Kategorien in der Übersicht der Gestal-
tungsentscheidungen zu.
Übung 2.3: relationales Datenbank-Managementsystem
Erklären Sie die Besonderheiten eines relationalen Datenbank-Management-
systems und zählen Sie wichtige Komponenten dieses Informationssystems auf.
Übung 2.4: Makrozyklus, Mikrozyklus
Erläutern Sie, was bezüglich des Gestaltungsdurchlaufes in einem Makrozyklus
und was bezüglich des Gestaltungsdurchlaufes in einem Mikrozyklus erklärt
wurde.
120 Kapitel 2 • Was ist eine Architektur eines Informationssystems?
2.7 Zusammenfassung
In diesem Kapitel wurde gezeigt, dass ein DWH eine Architektur hat, die aus IT-
Komponenten zusammengesetzt ist und die Gestaltung eines DWH über die
Gestaltung einzelner IT-Kategorien erreicht wird.
Es wurde auch gezeigt, dass die Entscheidungen nicht unabhängig voneinander
getroffen werden können, sondern dass eine Gestaltungsentscheidung in der
Regel die Gestaltungsmöglichkeiten anderer Kategorien einschränkt.
Außerdem wurde deutlich, dass es einen günstigen Weg durch die zu treffenden
Gestaltungsentscheidungen gibt und dass dieser Weg Abkürzungen erfährt,
wenn außerhalb des DWH-Projekts bereits Entscheidungen umgesetzt wurden.
Dieser Weg muss in Mesozyklen an den konkreten Objekten der IT-Kategorien
durchlaufen werden. Deshalb wurde angekündigt, dass mit der Bestimmung
der IT-Kategorien die Gestaltungsarbeit noch nicht beendet ist und dass jede
der Kategorien auf verschiedene noch darzustellende Weise in Komponenten,
Module, Funktionsgruppen zerlegt werden muss. Es ist aber klar geworden,
dass sich die Zerlegung an dem orientieren muss, was der Markt der EDV-
Produkte zu bieten hat.
Es ist auch klar geworden, dass eventuell dieser Markt keine in aller Vollstän-
digkeit befriedigenden Lösungen liefern kann und dann eventuell Eigenent-
wicklung betrieben werden muss.
Eigenentwicklung macht ein Vorgehen nach einem definierten Modell mit
Methoden erforderlich, sowie einige die Methoden per EDV-Applikation unter-
stützende Tools. Die Methoden können jedoch erst dann ausgewählt oder selbst
entwickelt werden, wenn das zu gestaltende Objekt klar ist. Deshalb wird das
Thema Vorgehensmodell im Anschluss an die Gestaltungsentscheidungen der
Architektur behandelt.
In den folgenden Kapiteln wird das Schema der Struktur der Gestaltungsent-
scheidungen schrittweise zu einem Gestaltungsraum verfeinert.
121
KAPITEL 3
3 Welche betriebswirtschaftlichen Komponenten
hat ein DWH?
Einleitung
Unternehmen wickeln zur Erreichung definierter Ziele Prozesse ab. Solche
Prozesse sind z.B. Umsatzgenerierung, Erwirtschaftung von Gewinnen, Erzeu-
gung von Gütern und Schaffung von Werten. Geschäftsprozesse sind in Arbeits-
schritte unterteilt, zu denen Ressourcen wie Sachmittel, Personal und Roh-
stoffe beigestellt werden. Die Arbeitsschritte sind teils manuelle, teils
automatisierte Handlungen und zum Teil Softwareprozesse.
Software ist im Versenden elektronischer Dokumente schneller als Papierpost.
Sie arbeitet präzise, ermüdungslos und verschleißfrei. Mit Software kopierte
Daten sind von einer Fehlerfreiheit, die eine handschriftliche Übertragung
nicht erreichen kann. Daten sind schneller übertragbar als Briefe durch Post-
versand oder Rohrpost. Sie stehen einem Empfänger zur Weiterverarbeitung
zur Verfügung, während der Inhalt von Papierdokumenten erst wieder in Pro-
gramme übernommen werden muss, soll er noch einmal bearbeitet werden.
Software hat die Fähigkeit, Fehler zu finden und Verbesserungsvorschläge zu
machen, wie z.B. die Rechtschreibhilfe eines Textverarbeitungsprogrammes.
Software soll Aktivitäten und Unternehmensprozesse unterstützen. Sie soll ein
guter Ersatz für manuelle Handlungen sein.
Die Software übernimmt betriebswirtschaftliche Aufgaben von den Aufgaben-
trägern. Deren Handlung ist auf einen Tastendruck zum Starten der Pro-
gramme reduziert. Die Software übernimmt auf der Basis ihrer Hardwareplatt-
form den Auftrag und arbeitet diesen ihrer Funktionalität entsprechend ab. Der
Folge der Durchführung manueller Aktivitäten entspricht der Ablauf einer
Folge von Funktionen. Dies ist in der Abbildung »Die Entsprechung von manu-
ellem Ablauf und Programmablauf« verdeutlicht (siehe Abbildung 3.1).
Zur Erstellung oder Auswahl einer Software ist es daher erforderlich, einen
Überblick über die betriebswirtschaftlichen Aufgaben zu gewinnen, also über
die Aktivitäten oder Handlungen, die von der Software übernommen werden
sollen. Dies ist eine funktionale Sicht auf das Unternehmen.
Die Erledigung dieser Aufgaben geschieht in einer logisch zwingenden Reihen-
folge. Das heißt, die Funktionen müssen auch in der Software in einer
bestimmten Reihenfolge abgewickelt werden. Um eine betriebswirtschaftliche
Aufgabe zu definieren, sind Informationen über Aktivitäten, deren Aufeinander-
folge und die bei ihrer Durchführung verwendeten Informationen erforderlich.
122 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?
Zu den Aktivitäten sind die Handlungsträger, die mit der Durchführung Beauf-
tragten, zu nennen. Dies ist eine prozessuale Sicht auf das Unternehmen.
Handlungsträger benötigen Hinweise, wo ihre Aufgaben mit welchen Werkzeu-
gen in welcher Reihenfolge und unter welchen Bedingungen ausgeführt wer-
den sollen. Sie benötigen Informationen. Für die Software, die diese Aufgaben
ersatzweise abwickeln soll, sind diese Informationen die zu verarbeitenden
Daten. Dies ist eine informationelle Sicht auf das Unternehmen.
Software ist also automatisierte Handlung und Funktionen sind automatisierte
Aktivitäten. Daten sind automatisiert verwaltete Informationen. Automatisie-
rung durch Software hat jedoch Grenzen. Dies sind zum einen ökonomische
Grenzen. Automatisierung ist teuer und amortisiert sich erst bei genügend
häufigen Wiederholungen. Zum anderen hat Automatisierung intellektuelle
Grenzen. Nicht jeder Sachverhalt ist prinzipiell so zu durchdringen, dass man
genaue Programmbeschreibungen gewinnen könnte.
Die wenigsten Aufgaben sind komplett an EDV-Systeme zu übertragen. Der
Fortschritt wird zwar das Spektrum der Funktionen ständig erweitern, es wird
aber immer ein Rest manueller, von einem Menschen auszuführender Tätigkei-
ten übrigbleiben. Eine betriebswirtschaftliche Anwendung und damit auch ein
DWH ist demnach ein Mensch-Maschine-System, ein System im menschliche
Aktivitäten und Programmfunktionen ineinandergreifen.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 123
Kauft man die »Software von der Stange«, Standardsoftware genannt, hat man
bereits eine vorgefertigte Reihenfolge, eine begrenzte, genau definierte Infor-
mationsmenge und festgelegte Funktionen. Die Standardsoftware ist herge-
stellt worden für eine ganze Klasse von Unternehmungen, ohne die Abläufe des
individuellen Unternehmens wirklich genau zu treffen. Das Unternehmen muss
seine Arbeitsprozesse nach dem Kauf anpassen oder die Software muss ange-
passt werden. Ein Ausweg hieraus ist die totale Eigenentwicklung. Weil man
hierbei nur für seine eigenen individuellen Bedürfnisse entwickelt, wird sie im
Gegensatz zur fertigen Software Individualsoftware genannt. Eine Individual-
entwicklung kann maßgeschneidert auf die Prozesse des Unternehmens abge-
stimmt werden. Das ist allerdings teurer und erfordert eine längere Zeit bis zur
Implementierung. Innerhalb dieser beiden Pole, der vorgefertigten Standard-
software und der frei zu programmierenden Individualsoftware, gibt es Zwi-
schenlösungen, wie anpassbare Standardsoftware und Fertigbauweise mit Ein-
zelkomponenten.
Für den DWH-Spezialisten ist nun wichtig zu bestimmen, welche betriebswirt-
schaftlichen Aufgaben das DWH umfassen muss, d.h. welche betriebswirt-
schaftlichen Funktionen abgedeckt werden müssen, welche betriebswirtschaft-
liche Architektur abgebildet werden muss. Daraus kann die am besten
geeignete Softwaretechnologie abgeleitet werden.
Kapitelüberblick
Betriebswirtschaftliche Programme sind Softwarekomponenten, in denen
betriebswirtschaftliches Fachwissen nach Struktur, Ablauf und Informationsge-
halt abgebildet ist. Die Bedeutung der betriebswirtschaftlichen Komponenten
der Software wird in drei Schritten − Funktionen, Branchen, Hierarchieebene −
herausgearbeitet.
Es ist ein Unterschied, ob sich ein Konzernchef, ein Bereichsleiter oder ein
Buchhalter die Daten der Kostenrechnung ansieht. Jeder dieser Benutzer benö-
tigt einen anderen Verdichtungsgrad und eine seiner Bedienung entsprechende
Ergonomie. Die Softwarefunktionalität ist deshalb auch von der Hierarchiee-
bene des Benutzers abhängig.
Die Unternehmen aller Branchen haben eine Mindestmenge gleicher Funktio-
nen, die alle erfüllen müssen, um ein Unternehmen führen zu können, z.B.
eine Kostenrechnung. Aber für jede Branche sind diese Grundfunktionen in
einer anderen Ausführung vorhanden. Deshalb kommen spezielle, nur für die
relevante Branche erforderliche, betriebswirtschaftliche Funktionen zum
Funktionsbedarf hinzu. Die Kostenrechnung einer Bank oder die eines Han-
delsunternehmens enthält z.B. keine Fertigungskosten wie die Kostenrech-
nung eines Industriebetriebs.
In diesem Kapitel wird die Thematik der betriebswirtschaftlichen Funktionen
als programmtechnische Entsprechung der betriebswirtschaftlichen Aufgaben
und deren Branchenbezug dargestellt. Die softwaretechnische Sicht folgt im
nächsten Kapitel.
Lernziel
Die Lernziele fokussieren zunächst die betriebswirtschaftlichen Funktionen
und die Umsetzung durch mittels Software automatisierte Funktionen und ihre
Zusammenführung zu betriebswirtschaftlichen Modulen und Softwarekompo-
nenten. Weitere Lernziele konzentrieren sich auf die Bedeutung der branchen-
spezifischen Unterschiede der betriebswirtschaftlichen Funktionen und auf die
speziell durch die hierarchiebezogenen Aufgaben im Unternehmen definierten
Anforderungen an die Funktionalität.
Lernziele
Verstehen, was eine betriebswirtschaftliche Komponente der Software ist
Überblick über die betriebswirtschaftlichen Komponenten einer Soft-
ware gewinnen
Wissen was ein Referenzmodell ist
Entscheiden
werden soll
können, ob Individual- oder Standardsoftware eingesetzt
10 11 12 13 14
155
368 271
Kunden- 14 Plan der Brutto- 1325
1366
17 stamm- 571 leistungserlöse 392
739
daten
255 576 825
256 1379 244
575
406
408
810 396
1348 Plan der Zah- 838 Plan der 396
568 lungsausgänge 260 574
19 1396 Kreditaufnahme
1389 860
272 808
10 11 12 13 14
Das Modell kann als Bauplan verwendet werden. Der Bauplan kann für einen
Programmierer als Vorlage zur Herstellung einer betriebswirtschaftlichen Soft-
ware dienen. Er kann auch als Vorlage oder Kriterienliste zur Auswahl für eine
zu beschaffende Standardsoftware dienen. Der Katalog ist eine Auswahl-Check-
liste für die Prüfung einer Standardsoftware auf die gewünschte Funktionalität.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 127
Modellierung
Man sieht, dass die angeführten Modelle eine gewisse Ähnlichkeit aufweisen
und eine Nachbildung betriebswirtschaftlicher Strukturen oder Architekturen
verfolgen. Für diese Nachbildung wird eine Symbolik eingesetzt. Alle Modelle
verwenden in ihrer Symbolik einen auf einen kleinen Umfang begrenzten Satz
von Symbolen. Die Symbole stehen für betriebswirtschaftliche Funktionalität,
Daten, EDV-Komponenten und Sachmittel. Die Symbole sind über Beziehungs-
linien verbunden und stellen so Bezüge dieser Objekte zueinander her. Bei den
repräsentierten EDV-Komponenten und Sachmitteln handelt es sich um Aus-
drucke, Tabellen, Programme.
Man kann auch erkennen, dass verschiedene Autoren bei ihrer Darstellung zu
verschiedenen Symbolen greifen. Von den Möglichkeiten dieser Darstellungen,
ihrer Symbolik und den Regeln der Umsetzung eines realen Sachverhalts in
eine Darstellung, vom Modellieren, handelt Kapitel 7 »Das Vorgehensmodell
für Data Warehouse Systeme«.
Die hier besprochenen Modelle haben die Absicht, einen betriebswirtschaftli-
chen Zustand oder eine betriebswirtschaftliche Struktur zu dokumentieren,
nachvollziehbar zu machen und zu kommunizieren. Gute Modelle enthalten
für viele Unternehmen interessantes Know-how und dienen so der Wiederver-
wendbarkeit und dem Know-how-Transfer. Sie dienen als Referenzmodelle.
Die Referenzmodelle geben eine Zielvorgabe für den betriebswirtschaftlichen
Umfang der zukünftigen Applikationen. Sie dienen als Bauplan oder als Evalua-
tionsgrundlage für einen Softwareeinkauf. Sie definieren noch nicht das DWH,
aber sie definieren die Basis, aus denen das DWH seine Daten bezieht. Was im
Basissystem nicht vorhanden ist, kann von einem DWH nicht geholt werden.
Soll ein DWH betriebswirtschaftliche Funktionen umfassen, die nicht vorhan-
den sind, müssen diese zunächst auf operativer Ebene eingeführt werden.
In einem Unternehmen mit einer bestehenden EDV ist bereits vieles in Ver-
zeichnissen und Dokumentationen vorhanden, so dass ein DWH-Spezialist die
für ihn relevanten Modelle nicht vollkommen neu erstellen oder beziehen
muss.
Terminologie
In einem Modell werden Sachverhalte beschrieben. Die Beschreibungen der
Sachverhalte bedienen sich einer Sprache, genauer einer Terminologie. Je grö-
ßer ein Unternehmen ist, um so vielfältiger ist die Interpretation von Fachbe-
griffen. Ist das Unternehmen aus Fusionen und Zukäufen entstanden, ist sogar
eine Mehrdeutigkeit der Begriffe zu erwarten. Der DWH-Spezialist muss dafür
sorgen, dass auf den Masken der DWH-Applikationen eine einheitliche und
weitgehend akzeptierte Sprache realisiert wird. Die in einem Unternehmen
uneinheitlich praktizierten Fachbegriffe lassen den DWH-Spezialisten nicht auf
Anhieb erkennen, ob es sich um unterschiedliche oder gleiche Dinge handelt.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 131
Beispiel: Umsatzaggregation:
Es liegt die folgende lückenhafte Tabelle mit Umsatzwerten zu einzelnen
Monaten eines Jahres vor.
Umsätze
100 200 300 ??? ??? 200 300 300 ??? ??? 200 300
in TDM
Monate 1 2 3 4 5 6 7 8 9 10 11 12
Die angebotenen Daten können auch unglaubwürdig sein, so dass man lieber
auf möglicherweise falsche Daten verzichtet.
Welches sind nun die vom DWH-Spezialist zu lösenden Gestaltungsfragen zur
betriebswirtschaftlichen Funktionalität und der Zuordnung zu Branchen?
❖ Entscheidung über die Schließung der Lücken mit Daten und Vorschlag
zur Beschaffung der fehlenden Daten
❖ Entscheidung über die Schließung der Lücken mittels Algorithmus und
Definition zur Beschaffung oder Entwicklung des Algorithmus
❖ Einheitliche Terminologie schaffen
❖ Funktionale Charakterisierung des Unternehmens mittels Funktionen-
listen und Schalenmodell
❖ Auswahl eines geeigneten Referenzmodells
Für einen umfassenden Überblick über die Funktionen eines Unternehmens ist
nützlich:
Wöhe, Betriebswirtschaftslehre
Referenzmodelle
Seit sich Standardsoftware wider alle Individualitätsbestrebungen der Unter-
nehmen etabliert hat, haben sich auch Referenzmodelle durchgesetzt. Refe-
renzmodelle nehmen für sich in Anspruch, die grundsätzlichen Strukturfragen
gut gelöst zu haben und somit für einen großen Kreis von Anwendern einsetz-
bar zu sein. Wer sich nicht mit der Technologie der Standardsysteme zufrieden
geben will, kann ein Referenzmodell kaufen und es auf seine Bedürfnisse
zuschneiden oder mit anderen Werkzeugen programmieren.
3.2 Branchen
Problemstellung und Motivation
Welche Gestaltungsfragen zur betriebswirtschaftlichen Funktionalität bezüg-
lich der Zuordnung zu Branchen hat der DWH-Spezialist nun zu lösen?
Je nach Branche wird eine Aufgabe etwas anders abgewickelt. Eine Kostenerfas-
sung z.B. hat in der Industrie mit Positionen zu rechnen, die für eine Kosten-
rechnung einer Bank nicht anfallen. Eine Bank hat z.B. keine Rohmaterialver-
arbeitung, keine Montage, keine Konstruktionsabteilung. Andererseits hat ein
Industriebetrieb keine Funktion für das Bankenclearing für internationalen
Zahlungsverkehr implementiert. Es genügt demnach nicht, ein auf der Kosten-
rechnung des Unternehmens basierendes DWH-Modul zu fordern. Vielmehr ist
jede Funktionsgruppe auf Branchenspezifität zu prüfen. Einige Funktionen
werden in der allgemeinen Form völlig ausreichend spezifiziert sein, andere
sind gegebenenfalls der Branche entsprechend näher zu bestimmen.
Statistiken
Für die Gliederung von Branchen gibt es im Detail ausgearbeitet Klassifizierun-
gen. Der volkswirtschaftliche Markt ist von statistischen Bundesämtern und
Marktforschungsinstituten auf unterschiedliche Weise in Branchen eingeteilt,
immer mit dem Ziel, die komplexe Struktur zu analysieren, Tendenzen in Pro-
duktion und Verteilung von Waren und Dienstleistungen zu entdecken.
Mit Branchenschlüsseln werden Märkte identifiziert und abgegrenzt. Will sich
ein Unternehmen mit anderen Unternehmen vergleichen, so wählt es Unter-
nehmen der gleichen Branche. Will das Unternehmen die Mitbewerber analy-
sieren, wird es seine Untersuchungen auf die in einem Marktsegment wirken-
den Unternehmen einschränken. Der Nutzen für das DWH ist, dass die
»Fremddaten« schneller einbezogen werden können als es eigene Erhebungen
ermöglichen könnten. Die verfügbaren Fremddaten sind zudem in erheblich
größerem Umfang vorhanden als die eigene Kapazität zu eruieren erlaubt.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 139
Eine erste Gliederungsstufe der Branchen der Betriebe ist die Gliederung nach
Wirtschaftsbereichen, wie sie die statistischen Ämter der Länder verwenden.
Nummer Wirtschaftsbereich
3. Verarbeitendes Gewerbe
4. Baugewerbe
5. Großhandel
6. Handelvermittlung
7. Einzelhandel
8. Verkehr/Nachrichtenübermittlung
9. Kreditinstitute/Versicherungen
Neben der Gliederung der Betriebe nach Wirtschaftbereichen gibt es noch die
Gliederung nach Sachleistungen bzw. nach Dienstleistungen. Die Gliederung
der Betriebe gehört zum Thema der Betriebstypologie, für deren Vertiefung auf
Wöhe, Einführung in die allgemeine Betriebswirtschaftslehre
verwiesen werden soll.
Branchenklassifikationen
Zur Einordnung der Branchen gibt es verschiedene Branchenklassifikationen.
Ein Beispiel für eine Branchenklassifikation ist, wie bereits erwähnt, die NACE
für die europäischen Behörden für Wirtschaftsstatistiken. Die Struktur der
NACE wird von den einzelnen Ländern unterschiedlich verfeinert. So heißt z.B.
die von österreichischen Behörden eingesetzte Branchengliederung für Statis-
tiken ÖNACE. Die Gliederung der ÖNACE ist in der folgenden Tabelle »Bran-
chengliederung nach ÖNACE« dargestellt (siehe Tabelle 3.4).
Weitere Systematiken sind beschrieben in:
Lippe, Wirtschaftsstatistik
Die Branchengliederung kann nicht nur für die eigene Einordnung interessant
sein, sie ist als Wertebereich in einer Datenbank nützlich, wenn das Unterneh-
men Daten zu mehreren Marktsegmenten erfassen muss.
Mit Hilfe der Branchengliederung ist eine gezielte Auswahl von externen
Datenquellen für die Befüllung des DWH mit Informationen möglich. Eine aus-
gezeichnete Übersicht über solche Informationsquellen aus dem Internet ist
dargestellt in:
Wirtschaftsinformatik, Heft 5, 1999, 41. Jahrgang
142 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?
g g
t g hnun t g hnun
nit un nit un
s ch bteil ez eic s ch bteil ez eic
Ab A B Ab A B
14 Gewinnung von Steinen und Erden DH Herstellung von Gummi- und Kunst-
stoffwaren
D Sachgütererzeugung
25 Herstellung von Gummi- und Kunststoff-
DA Herstellung von Nahrungs- und waren
Genussmitteln und Getränken,
Tabakverarbeitung DI Herstellung und Bearbeitung von
Glas, Herstellung von Waren aus
15 Herstellung von Nahrungs- und Genuss- Steinen und Erden
mitteln und Getränken
26 Herstellung und Bearbeitung von Glas,
16 Tabakverarbeitung Herstellung von Waren aus Steinen
und Erden
DB Herstellung von Textilien, Textilwaren
und Bekleidung DJ Metallerzeugung und -bearbeitung,
Herstellung von Metallerzeugnissen
17 Herstellung von Textilien, Textilwaren
ohne Bekleidung 27 Metallerzeugung und -bearbeitung
g g
t g hnun t g hnun
nit un nit un
s ch bteil ez eic s ch bteil ez eic
Ab A B Ab A B
g g
t g hnun t g hnun
nit un nit un
s ch bteil ez eic s ch bteil ez eic
Ab A B Ab A B
3.3 Hierarchieebenen
Problemstellung und Motivation
Managementebenen
Im Gegensatz zu den aus der Sicht der Vertriebsabteilungen der Hersteller ver-
blühten Executive Information Systems ist ein DWH nicht nur für die Executi-
ves sondern für mehrere Managementebenen geeignet. Eine bewährte und in
vielen Standardwerken der Fachliteratur vertretene Einteilung der Manage-
mentebenen ist die folgende in
✔ Strategisches Management
✔ Taktisches Management
✔ Operatives Management
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 145
Aufsichtsrat
Konzernvorstand
Bereichsleitung
Abteilungsleiter
Projektleiter
Projektmitarbeiter
Operative Mitarbeiter
Aber er muss die Zahlen der seiner Region zugehörigen Bezirke ansehen kön-
nen. Weitergehend soll er nach Auswahl eines Bezirkes die dort zugeordneten
Kunden sehen, aber nicht die Kunden anderer Regionen. Bezüglich der Pro-
jekte sind für ihn alle Informationen interessant, die seine Projekte und die
Projekte mit Auswirkungen auf seine Projekte (z.B. Terminabhängigkeiten)
betreffen.
Regionale Gliederung
Die regionale Gliederung ist ein Aspekt der funktionalen Anforderung »Ver-
dichtungsebenen« an das DWH. Die Daten des DWH werden in der Kompo-
nente »OLAP-System« in einem sogenannten »multidimensionalen Würfel«
organisiert. Die Gliederungsmatrix gibt die Struktur und Dimensionen des
Würfels an. Die Hierarchie-Gliederungsmatrix wird bei der Implementierung
des DWH als Benutzerprofil für die Zugriffsberechtigungen auf die Daten dieses
Würfels verwendet.
Gestaltungs- und Lösungsmöglichkeiten
Was hat nun der DWH-Spezialist bezüglich der hierarchischen Gliederung von
Unternehmen in seiner Gestaltung zu berücksichtigen?
Es ist nicht per se klar, welche Führungsebene zum Nutzerkreis des DWH
gehören soll. Für die einzelnen Führungspositionen muss die zunächst nur
vage vorhandene Vorstellung von den Möglichkeiten eines DWH konkretisiert
werden. Es müssen deren Verantwortungsbereiche einschließlich der zu ihrer
Führung erforderlichen Informationen festgestellt werden. Die Veranwortungs-
bereiche können dabei produktbezogen definiert sein, sie können regional und
über alle Produkte gelten, sie können über mehrere Produkte und Regionen
und auch für mehrere Projekte gelten.
Die Gestaltungsaufgabe lautet damit wie folgt:
➢ Feststellung, welche Regionen zu ihrem Verantwortungsbereich gehören
➢ Feststellung, welche Führungsebenen am DWH beteiligt sind
148 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?
ORGANISATION
Unternehmensgruppe
Unternehmen
Division
Hauptabteilung
Abteilung
Gruppe
Person
PRODUKT
Wirtschaftszweig
Branchengruppe
Branchenklasse
Produktgruppe
Marke
Artikel
Erzeugnis
Bauteil
Material
REGIONEN
Erdteil
Ländergruppe
Land
Bundesland
Region
Bezirk
Stadt
Stadtteil
Straße
Haus
ANLAGEN
Werk
Gesamtanlage
Funktion
Aggregat
Betriebsmittel
Bauteil
VORHABEN
Projekt
Subprojekt
Teilprojekt
Aufgabe
Aktion
PERIODEN
Jahrzehnt
Jahrestriade
Jahr
Halbjahr
Quartal
Monat
Woche
Tag
Stunde
Der Eintrag »0« bedeutet die Gesamtsumme bezüglich der Dimension. Die
Zahlen der Spalten »Stufe« geben die Stufe entsprechend der einzelnen Gliede-
rungen, wie sie oben angegeben wurden, an. Die erste Zahl ist dabei die höchste
Verdichtungsebene und die zweite Zahl gibt die feinste interessierende Detail-
lierung an.
Die erste Spalte zeigt die Hierarchieebene des Benutzers in der Unternehmens-
organisation an. Die zweite Spalte bezeichnet die Position des Benutzers.
Beispiel
Das folgende Beispiel setzt auf der in Kapitel 1 getroffenen Entscheidung »ein
Data Warehouse für Schadensanalysen zur Optimierung der Instandhaltung
von Kraftwerken, Projekt InDaWa« zu implementieren, auf.
Schlosser -- -- --
Die operative Ebene (Schlosser) wird das System nicht einsetzen, sondern
die Erkenntnisse per Instandhaltungsauftrag umsetzen. Der Leiter der
Instandhaltung sowie der Leiter der Leittechnik sehen alle BW-Funktionen,
alle Kraftwerke des Landes und alle Anlagenteile-Ebenen. Die Geschäftsfüh-
rung des Versorgungsunternehmens wird nur die bundesweiten Erkennt-
nisse über alle Kraftwerke kennen. Projekte gibt es in diesem Zusammen-
hang keine. Die Spalte Produkte wurde durch Anlagenteile ersetzt.
Gestaltungsentscheidungen
Die herausgearbeiteten Gestaltungsentscheidungen des Projekts InDaWa sind
die Entscheidungen zum betriebswirtschaftlichen Umfang. Es sind dies die hie-
rarchischen Gliederungen, die später für die Verdichtung der Daten benötigt
werden, der betriebswirtschaftliche Umfang und die Branchenspezifität. Die
Ergebnisse werden in der folgenden Tabelle festgehalten.
Entscheidung/
Gestaltungsaspekt Erkenntnis Begründung
ARCHITEKTUR
Betriebswirtschafts-
komponenten
Fachkomponenten Instandhaltung Auftragsdefinition
Anlagenteile Ereignisdefinition
Materialwirtschaft Vorratsminimierung
Lagerhaltung Zustellungsoptimierung
Arbeitsplanung Auslastungsoptimierung
Ereignisverwaltung Ereignisanalyse
Schadensdaten Schadensanalysen
Personal Personaleinsatzplanung
3.5 Übungen
Übung 3.1: Betriebswirtschaftlicher Gestaltungsprozess
Durchlaufen Sie den Gestaltungsprozess mit den Ihrem Unternehmen eigenen
Angaben für ein ausgewähltes Fachgebiet oder einen Funktionsbereich.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 157
Systemtyp
Kaufmännische
Funktionen 2. Schritt
Systemkompo-
nente
Kostenrechnung
3. Schritt
Systemmodul
Kostenarten-
rechnung 4. Schritt
Funktionen
Kostenrahmenplan
Übersicht Kostenart
elementare Kosten-
positionen
Im ersten Schritt des ersten Entscheidungsganges wird auf der Ebene des
Systemtyps der betriebswirtschaftliche Funktionsrahmen (kaufmännisch,
technisch, bürotechnisch ...) abgegrenzt. Im obigen Beispiel wurde der System-
typ »kaufmännische Funktionen« ausgewählt.
Ist der Funktionsrahmen z.B. als »kaufmännische Funktionen« abgegrenzt,
kann dieser im zweiten Schritt weiter auf der Ebene der Komponenten detail-
liert werden. Zum Beispiel könnte die zum Systemtyp »kaufmännische Funkti-
onen« gehörige Komponente »Kostenrechnung« relevant sein.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 159
Funktionen
Industriekostenrahmen
Übersicht Kostenarten
Kostenbuchungen der
Fertigung
Deshalb ist es erforderlich, nach dem vierten Schritt des ersten Entscheidungs-
ganges, also nach der Bestimmung der betriebswirtschaftlichen Funktionen,
deren charakteristische Ausprägung für die Branche in einem zweiten Ent-
scheidungsgang »Branchenzuordnung« festzustellen. Die funktionalen Anfor-
derungen bezüglich des Beispiels Kostenartenrechnung umfassen daher unter
anderem Industriekostenrahmen, Übersicht Kostenarten und Kostenbuchun-
gen der Fertigung. Hierbei wurde die Branchenspezifität auf den vierten Schritt
des ersten Entscheidungslaufes angewendet.
Die Branchenzuordnung kann sich schon auf den ersten Schritt des ersten Ent-
scheidungsganges auswirken. Deshalb ist zu empfehlen, den zweiten Entschei-
dungsgang schon beim ersten Schritt einzusetzen, also nicht erst bei dem
Schritt »Funktionen«.
Dritter Entscheidungsgang
In einem dritten Entscheidungsgang müssen die ebenenbedingten Anforde-
rungen, die Anforderungen der Nutzerebene, an die betriebswirtschaftliche
Funktionalität gefunden werden. So ist es z.B. für die Funktion »Kostendarstel-
lung« umso unwichtiger, die Details auf untersten Kostenebenen zu kennen, je
höher der Benutzer in der Hierarchie des Unternehmens positioniert ist.
160 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?
Funktionen
Kostenrahmenplan
Übersicht Kostenarten
verdichtete Kostenpositionen
!
()
*
" !
+ !
!
!
2
!
&
1!
.!
!
"# $
"
0
!
-
1!
+
"
! " %
$
!
!
$
"!
% '
!
/
%
&' % $!
%
!
32
$!
!
$!
%
+ 1'
,
- #
. $
/!
+!
0!
$
)))))))
KAPITEL 4
4 Welche Softwarekomponenten sind für ein
DWH einzusetzen?
Einleitung
Alles bisher Gesagte war noch so allgemein, dass es nicht nur für Data Ware-
house, sondern ganz allgemein für alle komplexen Datenbankanwendungen
gültig ist. Jetzt stellt sich die Frage, welches denn die Besonderheiten sind, mit
denen sich ein DWH von anderen komplexen EDV-Systemen unterscheidet.
Einen Unterschied konnte man bisher erkennen: Basissysteme sind für sich
alleine anwendbar. Ein DWH baut auf Basissystemen auf, bezieht von Basissys-
temen Daten. DWH sind damit nur so gut wie die Daten der Basissysteme. Das
heißt aber auch, das DWH muss Funktionen bieten, die Basissysteme nicht
bieten können.
Neben den Softwarekomponenten mit betriebswirtschaftlichen Aufgaben gibt
es Software, die zum Umgang mit den Daten unabhängig von ihrer betriebs-
wirtschaftlichen Bedeutung nützlich ist. Diese Software enthält Funktionen,
die Daten wie Werkstücke suchen, bereitstellen, bearbeiten und weitergeben
lassen. Wegen dieses Werkzeugcharakters nennt man diese Art von Software
Tools. Ein DWH unterscheidet sich durch seine Ausstattung an solchen Tools
von den Basissystemen. Ein Kapitel ist deshalb diesen Tools oder Komponenten
des DWH gewidmet.
Die besonders wichtigen speziellen DWH-Systeme Online Analytical Proces-
sing System (OLAP) und Knowledge Discovery on Databases System (KDD)
werden in Unterkapiteln ausführlicher dargestellt.
Ein DWH-System enthält Funktionen zur Findung, Verwaltung, Transforma-
tion, Auswertung und Präsentation von Daten, die andere Datenbankanwen-
dungen nicht bieten. Diesem Gesichtspunkt der Funktionalität der DWH ist ein
Abschnitt dieses Kapitels gewidmet. Einige besondere Funktionen, die auf die
Abbildung komplexer Zusammenhänge in umfangreichen Datenmengen fokus-
sieren, sind ausführlich beschrieben.
Die DWH-Komponenten können auf verschiedene Weise hergestellt werden.
Sie können von einem Hersteller als Fertigprodukt und Standardlösung oder
von vielen verschiedenen Herstellern als kombinierbare und zusammenbau-
bare Einzelstücke geliefert oder als auszuprogrammierende Individuallösung
gekauft werden. Die Komponenten können fachspezifisch ausgeprägt und für
Verteilungszwecke in unterschiedlich große Einzelkomponenten, lauffähig für
unterschiedliche Rechnertypen, zerlegt sein. Deshalb wird diesem als Techno-
logietypus bezeichneten Aspekt ebenfalls ein Abschnitt gewidmet.
164 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?
!
Lernziel
Die Lernziele, die hier angestrebt werden, sind das Verständnis dieser Software-
komponenten, der Funktionalität aus der Sicht der drei Nutzerebenen und der
Bedeutung für die unterschiedlichen Aufgaben im Unternehmen.
Lernziele
Erklären können, was ein Data Warehouse ist, und welche dem DWH
ähnliche Systeme es gibt
Überblick gewinnen über die Komponenten, aus denen ein DWH besteht
Verstehen des Aufbaus eines DWH-Referenzmodells
Verstehen der funktionalen Prinzipien der DWH-Komponenten
Spezifikation auf Komponentenebene beherrschen
Überblick gewinnen über DWH-Tools und deren Eigenschaften
Vor- und Nachteile der softwaretechnischen Fertigungstypen beurteilen
können
Kennen des Funktionsumfanges eines Data Warehouse
Kennen des Aufbaus eines OLAP-Systems
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 165
Kennen des Aufbaus eines Knowledge-Discovery-Systems
Definieren der zwölf Codd'schen OLAP-Regeln
Unterscheiden zwischen OLAP und OLTP
tionssystem der Position »Chef«, zeigt
Bullinger, Data Warehouse
Das Modell von Bullinger ist ein Vorschlag zur Lösung der Frage »Wie muss ein
System aufgebaut sein, das ein Chef des Unternehmens, bzw. ein Mitarbeiter
der obersten Führungsebene, benötigt?«. Dieses Modell umfasst neben den
DWH-Komponenten auch Officekomponenten und Kommunikationskompo-
nenten und ist damit ein integratives Modell.
Bei diesem Modell ist der Tatsache, dass der Position entsprechend eventuell
verschiedene Benutzertypen mit dem System arbeiten müssen, besonders
Rechnung getragen. Diese Fähigkeit liefert eine Komponente, die Benutzermo-
delle verwaltet: das »mentale Managermodell«. Benutzermodelle umfassen
dabei zum Beispiel Ausschnitte aus der Gesamtfunktionalität, Zugriff auf ausge-
wählte Komponenten, relevante Ausschnitte aus dem Datenpool, Erlaubnispro-
file und persönliche Einstellungen von Menüleisten und Oberflächen (siehe
Abbildung 4.3).
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 167
#$ !"
%
Abbildung 4.3: Komponenten der Softwarearchitektur eines Chefinformationssystems
Das Assistentenmodell enthält viele Funktionen, die für ein DWH System
unentbehrlich, aber nicht speziell auf das DWH ausgerichtet sind.
Data Warehouse Ansatz
Jeder der vorgestellten Ansätze liefert einen wichtigen Beitrag für DWH-Lösun-
gen. Die verschiedenen hier vorgestellten Modelle werden nun zu einem Kon-
zept, dem DWH-Referenzmodell, zusammengeführt. Einige der vorgestellten
Modelle umfassen Office-Funktionen und Kommunikationsfunktionen, andere
Modelle wiederum nicht. Einige der Modelle enthalten Fachmodelle, andere
sind fachneutral ausgestattet. Man sieht auch, dass einige Modelle die Datenba-
sis umfassen und andere die Datenbasis mit den Grunddaten ausschließen. Man
kann aber auch die Gemeinsamkeiten dieser Modelle erkennen: Alle Systeme
haben Entscheidungsunterstützung, die auf verschiedene Benutzertypen und
besonders die Benutzer der Führungsebenen zugeschnitten ist.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 169
Man kann also einen Data Warehouse Ansatz im engeren Sinne und einen Data
Warehouse Ansatz im weiteren Sinne feststellen.
Definition
Das Data Warehouse im engeren Sinn umfasst die Replikation vorhandener
Daten in einem DWH-Server mit Auswertungs- und Darstellungswerkzeu-
gen.
Das Data Warehouse im weiteren Sinn umfasst den gesamten Datenhaushalt
der Unternehmung, verdichtet, repliziert, unverdichtet, in elektronischen
Dokumenten vorliegend genauso wie in Files und Datenbanken, die Ergono-
mie-Funktionen ebenso umfassend wie die Auswertungs-, Analyse- und
Betriebswirtschaftsfunktionen.
Der umfassende Ansatz des DWH im weiteren Sinnn ist für die Evaluation von
neuen Produkten nützlicher, da er alle in Frage kommenden Kriterien umfasst
und dies, anders als bei Kriterienlisten anderer datenbank-basierter Informati-
onssysteme, aus der Sicht des DWH.
4.1.1 DWH-Referenzmodell
Allgemeines
Das DWH-Referenzmodell ist eine gute Vorlage für die Auswahl der Software-
komponenten des DWH. Zur Erklärung seien die Komponenten kurz und über-
sichtlich in der Folge von oben nach unten aus der Sicht des Benutzers vom
Desktop aus beschrieben.
Nicht jede Komponente ist für jedes Problem gleich gut geeignet, und nicht
jede Komponente wird gebraucht. Deshalb bieten die Hersteller Komponenten-
auswahl und Kombination an, mit der Möglichkeit, bei einer Änderung der
Anforderungen das DWH mit weiteren Komponenten nachzurüsten. Zu bestim-
men ist dabei, welche der Komponenten für eine bestimmte Problemstellung
am geeignetsten ist, und ob die Auswahl der Komponenten kombinierbar ist.
Die Gestaltungsaufgabe ist gelöst, wenn die Aufzählung der den erhobenen
Anwenderbedarf abdeckenden Module bzw. Komponenten vollständig ist.
Einige der genannten Komponenten finden nicht nur als Komponenten in
einem kompletten DWH-System Verwendung. Sie sind auch als zentrale Kompo-
nenten in verwandten kleineren Informations-Systemen enthalten, die vor dem
umfangreicheren und integrierenden DWH-Konzept bereits bekannt waren. Sol-
che Systeme sind zum Beispiel OLAP-System Executive Information System,
Knowledge Discovery System und Decision Supporting System. Soweit die Kom-
ponenten dieser Systeme noch nicht integriert sind, lässt sich vermuten, dass
deren Integration im Zuge der Zeit noch stattfinden wird, da die Hersteller die-
selben sind. Das hier vorgestellte »Referenzmodell für Data Warehouses« kommt
dem umfassenden Data Warehouse Ansatz, dem DWH im weiteren Sinne, nach,
indem es die sinnverwandten Komponenten mit aufnimmt.
170 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?
!" ' ,.#$
)"
! + !"
"-
"+
,
,,#
" "
*
%
%
!
* * * * (% * * *
Das hier vorgestellte »Referenzmodell für Data Warehouses« ist eine aus den
Aufsätzen von
H.-D. Goffmann und von M. Tresch sowie M. Rys aus HMD, Seite 13 und
Seite 60,
weiterentwickelte Auffassung.
Im DWH-Referenzmodell sind alle möglichen Komponententypen zusammen
mit ihren Beziehungen zu den Nachbarkomponenten enthalten. So wird das
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 171
auch enthalten in:
von Hummeltenberg, in Martin, Data Warehousing, Seite 62
Kurz, Data Warehousing
Muksch u.a., Data Warehousing
Das OLAP-System
Das Konzept des Online Analytical Processing, kurz OLAP, ist von den Kon-
zeptionisten des Relationalen Modells aus der Erkenntnis mit entwickelt wor-
den, dass die hervorragenden Konsistenzmechanismen der relationalen Daten-
banken große Nachteile bei der multidimensionalen und der konsolidierenden
Bearbeitung von Daten verursachen. So darf z.B. in relationalen Datenbanken
keine Hierarchie mit akkumulierten Werten definiert werden, weil dies zu
schlecht kontrollierbaren Redundanzen führt. Besonders die Konsolidierung
entlang eines eine Hierarchie durchlaufenden Pfades ist eine für das Control-
ling von Unternehmen wichtige Funktion. Die Konsolidierung ist darüber hin-
aus entlang verschiedener Dimensionen erforderlich. Die Entscheidung, wel-
cher Konsolidierungspfad gerade gebraucht wird, also entlang welcher
Dimension die Konsolidierung durchgeführt wird, und ob an einer bestimmten
Aggregationsstufe die Dimension gewechselt werden muss, ist von dem augen-
blicklich zu bearbeitenden Problem abhängig. Sie muss daher flexibel vom
Desktop aus, im Augenblick des Gebrauchs, abzurufen sein. Die Richtung des
Durchlaufens der Aggregationspfade muss sowohl in Richtung Verdichtung wie
auch in Richtung Auflösung möglich sein, d.h. von den unverdichteten zu agg-
regierten Größen und von den aggregierten zu den detaillierte Größen.
Das OLAP-Konzept wurde von E.F.Codd, dem Erfinder der relationalen Daten-
banken, zusammen mit S.B.Codd in die folgenden zwölf Anforderungen, die
zwölf Codd'schen Regeln des Online Analytical Processing, gekleidet.
Nummer Forderung
2 Transparenz
3 Zugriffsmöglichkeit
4 Konsistente Berichterstellung
5 Client/Server-Architektur
6 Generische Dimensionalität
8 Mehrbenutzerunterstützung
10 Intuitive Datenverarbeitung
11 Flexible Berichterstellung
Tabelle 4.1: Die zwölf Codd'schen Regeln des Online Analytical Processing
180 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?
Multidimensionalität
Die Multidimensionalität ist eine Eigenschaft, die besonders häufig in Frage-
stellungen des Unternehmens anzutreffen ist. So ist zum Beispiel der Umsatz
eine Größe, die produktbezogen, regionsbezogen und zeitbezogen zugeordnet
werden muss, wie die Frage »In welchem Zeitraum wurden mit welchem Pro-
dukt in welcher Region Umsätze in welcher Höhe gemacht?«, zeigt. Die Forde-
rung der Multidimensionalität bedeutet, dass mehrere unterschiedlich dimen-
sionierte Datenwürfel angelegt werden können. Die Berechnungen können
innerhalb einer Dimension (intradimensional) oder auch über mehrere Dimen-
sionen hinweg (interdimensional) definiert und durchgeführt werden. Die
Sicht auf die Dimensionen der Würfel ist wahlweise interaktiv auswählbar.
Die Darstellungsart sollte der Multidimensionalität gerecht werden, das heißt
wenigstens die dritte Dimension einbeziehen.
Transparenz
Mit Transparenz ist von Codd&Codd eine Eigenschaft definiert worden, die dem
Benutzer die Herkunft der Daten, die Lokation des eingesetzten Tools und die
Koppelung des Tools an die gesamte Anwendung »transparent« werden lässt.
Anders ausgedrückt ist Transparenz die Eigenschaft des Systems, dem Benutzer
die Eingabe der exakten Systemdefinition der Datenquellen zu ersparen, also
die Möglichkeit, die Quelle per »Klick« auszuwählen.
Die Transparenzforderung betrifft die Offenheit der Systemkomponenten für
die Anbindung weiterer Softwarekomponenten. Dies bedeutet z.B., dass bei
einem Wechsel des Server-Produkts die Client-Seite, so wie sie konfigurierte
wurde, weiter betrieben werden kann, eben nur auf einem anderen Server. Dies
wiederum bedingt eine Middleware, das heißt eine Softwareschicht, welche die
Verbindung zwischen den Client-Tools und den Server-Tools herstellt.
Zugriffsmöglichkeit
Unter Zugriffsmöglichkeit formuliert Codd&Codd die Forderung, in einem
analytischen Modell agieren zu können, ohne dabei die Originaldaten direkt
ansprechen zu müssen.
Da die Originaldaten in verschiedenen Quellen gespeichert sind, müssten vom
OLAP-Benutzer verschiedene Zugriffssprachen, Datenbankschemata, Formatie-
rungen und Systemeinstiege beherrscht werden. Er müsste die lokale Position
jeder Datenquelle kennen und ansprechen und zu jedem System eine eigene
Zugriffserlaubnis erhalten. Die einzelnen Datenmengen müssten manuell
zusammengeführt werden. Der Benutzer soll statt dessen mit nur einer
Zugriffsart auf eine Struktur und mit nur einer Sprache auskommen. Dafür ist
ein eigenes Datenbankschema, ein Data Dictionary, erforderlich. Da die Daten
nicht unbedingt relational, sondern vielmehr in einer multidimensionalen und
hierarchischen Struktur benötigt werden, ist zudem noch eine Modellkompo-
nente erforderlich.
Der Transport der Daten aus den ursprünglichen Quellen in die Datenbank des
OLAP-Servers wird mit sogenannten Middlewarekomponenten abgewickelt.
Konsistente Berichterstellung
Mit konsistenter Berichterstellung ist das performante Verhalten bei der
Erstellung von Berichten aus großen Datenmengen, langen Hierarchien, brei-
ten Hierarchien und vielen Dimensionen gemeint. Die Forderung nach Konsis-
tenz ist begrifflich etwas missglückt, da hierunter bereits in der Datenbank-
technologie die Stimmigkeit der zueinander in Beziehung stehenden
Datensätze von Datenbanken verstanden wird und die Bedeutung des Wortes
wenig mit dem Zusammenhang zu tun hat, der von Codd&Codd angesprochen
wird. Die Navigation in einem Multiwürfel muss auch bei hoher Komplexität
komfortabel bleiben. Hier wäre der Begriff »performante Berichterstellung«
passender, zumal die Konsistenzproblematik nicht auf der Berichtsebene, son-
dern auf der Datenhaltungsebene sichergestellt wird.
182 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?
Client/Server-Architektur
Die technischen Eigenschaften Client/Server-Architektur sind in der Welt der
relationalen Datenbanken üblich, wie z.B. die Aufteilung der Prozesse auf einen
Server und einen Client.
Der Aufbau der Softwaresysteme mittels Client/Server-Architekturen hat sich
durchgesetzt. Dass OLAP-Systeme in Client/Server-Architekturen aufgebaut
werden, ist dennoch nicht selbstverständlich, da die Daten meistens in Termi-
nal-Host-Systemen vorliegen. Das Prinzip der C/S-Architektur erlaubt es, koo-
perierende Programme auf verschiedenen Rechnern, z.B. einem Server-Rech-
ner und einem Client-Rechner, ablaufen zu lassen. Das Client-Programm holt
sich bei Bedarf vom Server Daten und Rechenleistung. Der Server kann dann
als starker Datenbankserver für die Haltung großer Datenmengen ausgelegt
und an einem festen Ort platziert werden. Die Programme zur Analyse der
Daten können lokal entfernt vom Server auf Client-Rechnern installiert werden
und je nach Bedarf mit dem relevanten Datenausschnitt versorgt werden.
Das Thema der Client/Server-Architekturen wird in Kapitel 5 »Die Hardware
Architektur von Data Warehouse Systemen« noch vertieft.
Generische Dimensionalität
Auf den Dimensionen des Multiwürfels sind bestimmte nützliche Funktionen
definiert. Die generische Dimensionalität fordert, allgemeingültige, also über
alle Dimensionen gültige Funktionen zu definieren, ohne dabei jede einzelne
Dimension zu nennen. Anders ausgedrückt soll die für eine Dimension defi-
nierte Funktion auf alle anderen Dimensionen generisch ausgeweitet werden.
Dünn besiedelte Matrizen
Ein Multiwürfel setzt sich aus Elementarwürfeln zusammen. Jeder Elementar-
würfel hat Platz für eine gewisse Datenmenge. Die Multiwürfel werden naturge-
mäß nicht in an allen Bereichen in der gleichen Dichte mit Daten bestückt sein,
sondern es wird Leerplätze geben. Je nach der Lage dieser dünnbesiedelten Stel-
len werden jeweils andere Zugriffe performanter sein, als dies bei homogen und
stark besetzten Matrizen der Fall ist. Es muss möglich sein, die Performance-
unterstützenden Zugriffstechniken besonders bei dünnbesetzten Matrizen
dynamisch und flexibel dieser Datenbesiedelungssituation anzupassen.
Multi-User-Betrieb
Die technischen Eigenschaften des Multi-User-Betriebs sind in der Welt der
relationalen Datenbanken üblich. Dateien der OLAP-Server werden von mehre-
ren Benutzern angefragt. Der konkurrente Zugriff vieler Benutzer muss mit
Sperr- und Freigabe- und Roll-Back-Mechanismen die Konsistenz der Daten
erhalten, bzw. bei einem Absturz des Rechnersystems auf einen konsistenten
früheren Zustand zurückführen.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 183
Kreuzdimensionale Operationen
Die Arbeit mit multidimensionalen Würfeln bringt die Notwendigkeit einer
wesentlichen Erweiterung mit sich, nämlich Berechnungen, die innerhalb der
Werte einer Dimension stattfinden. Daten unterschiedlicher Herkunft, regio-
nal, serverlogisch, datenbanktypisch, sollen trotz verschiedener Formate in die
Berechnung einbezogen werden können. So können z.B. die Daten einer
Dimension aus verschiedenen Regionen von verschiedenen Datenhaltungssys-
temen kommen. Bei diesen kreuzdimensionalen Operationen sollen die Zahlen
in allen Aggregationsebenen ohne direkte Angabe von Additionsvorschriften
automatisch aggregiert werden.
Intuitive Datenbearbeitung
Bei der intuitiven Datenbearbeitung sollen die Daten mit den der Fachsprache
des Anwenders entnommenen Bezeichnungen gefunden werden können, ohne
den Anwender mit einer Programmiersprache und den internen Bezeichnun-
gen zu konfrontieren. Von einem Standort aus sollen, ohne lange Menühierar-
chien des Systems durchlaufen zu müssen, die Daten, die in einem Zusammen-
hang stehen, direkt angesprochen werden können. Die Dimensionen sollen frei
wechselbar sein. Die Verdichtungsebenen sollen durch einfache Bedienungsele-
mente aufgelöst oder zusammengefasst werden können.
Für diese intuitive Datenbearbeitung sind besondere Navigationsfunktionen
(Drill Down, Drill Across, Roll Up, Drill In) erforderlich und eine übersichtliche
synoptische Darstellung mehrerer Dimensionen. Eine solche für eine effiziente
Navigation die Mehrdimensionalität verdeutlichende Orientierungshilfe zeigt
die folgende Abbildung »Raumvisualisierung«.
Flexible Berichterstellung
Die flexible Berichterstellung erfordert es, dass zusammengehörige Daten in
Berichten nebeneinander platziert werden können. Spalten und Zeilen müssen
ihrer Aggregation entsprechend in mehrere Aggregationskomponenten aufge-
spalten werden können. Die Spalten müssen je nach Bedarf frei verschiebbar,
hervorhebbar und auch unsichtbar gemacht werden können.
Für die flexible Berichterstellung sind Zugriffswerkzeuge, Montage- und Anpas-
sungstools für Berichtsteile erforderlich (Spaltenkonfigurator, Formelfelder,
Hyperlinks, wertdynamische Feldpräsentationen).
Unbegrenzte Aggregationsebenen
Es ist zwar keine grenzenlose Anzahl von Dimensionen und auch keine gren-
zenlose Anzahl von Aggregationsebenen für die Erfassung unternehmensspezi-
fischer Fragestellungen erforderlich, aber die Dimensionalität sollte praktisch
nicht beschränkt werden. Die Forderung unbegrenzte Aggregationsebenen
bedeutet nicht die Möglichkeit, unendlich viele Ebenen zu verarbeiten, was gar
nicht möglich ist, sondern nicht an die praktisch sinnvollen Grenzen zu stoßen.
184 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?
Die Leistung der Systeme ist heute auf ca. 20 Dimensionen und weit mehr tiefe
Aggregationen ausgelegt. Hier wäre auch der Begriff »ausreichende Aggregati-
onsebenen« besser angebracht als derjenige der unbegrenzten Aggregationse-
benen.
Integrität
Was bei allen bisher genannten Codd'schen Forderungen stillschweigend vor-
ausgesetzt, also nicht explizit gefordert wird, ist die Integrität der Daten. Dies
ist umso verwunderlicher, als doch gerade die Integrität der Daten die heraus-
ragende Leistung des Entity Relationship Modells von E.F.Codd ist, und zwar so
erfolgreich, dass sie sich zu einer Königsdisziplin des Software Engineering
entwickelt hat.
Die Integrität der Daten ist auf der Ebene der Quellen so gut wie es das entspre-
chende Datenverwaltungssystem zulässt, und hier sind die relationalen Daten-
banken führend. Es werden auch andere Quellen gebraucht, deren Verwal-
tungsmechanismen nicht soviel zur Integrität beitragen können. Die meisten
Hersteller haben dies erkannt und legen deshalb dem Datenwürfel zunächst
eine relationale Datenbank zugrunde, die dazu zwingt, zunächst einmal alle
Daten, egal welcher Herkunft, in einen integren Zustand zu überführen. Die
Integrität hängt allerdings auch von der sorgfältigen Modellierung ab.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 185
Im folgenden Abschnitt soll noch ein weiteres Beispiel eines kompletten, eigen-
ständigen Subsystems des Data Warehouse, das Knowledge Discovery System,
vorgestellt werden.
✔ Evaluation
✔ Visualisierung
Datenauswahl und Sammlung
Aus der großen Menge der erreichbaren Daten sind zunächst diejenigen her-
auszufinden, die für das zu lösende Problem relevant sind. Diese Daten werden
aus dem Data Warehouse heraus in eine problemrelevante Sammlung kopiert,
um nicht in der erheblich größeren Menge des DWH arbeiten zu müssen.
Klärung und Vorbereitung
Nach der Auswahl steht ein immer noch großer Umfang an Daten zur Verfü-
gung, der noch auf Qualität oder Güte geprüft werden muss. Die Gütebeurtei-
lung umfasst unter anderem die Darstellungsform, Lückenhaftigkeit, Aktualität
und Widerspruchsfreiheit. Dies ist wichtig, um nicht durch eine mangelnde
Datenqualität bereits Beurteilungsfehler zu induzieren.
Transformation und Reduktion
Die Daten entstammen in der Regel verschiedenen Quellen und sind daher in
unterschiedlichen Formaten vorhanden. Die Formate werden in ein einheitli-
ches Format transformiert. Dazu gehört zum Beispiel auch die Aufspaltung von
nicht-atomaren Attributen in kleinste ansprechbare, über alle Daten homogene
Einheiten, in sogenannte Datenelemente. Daten, die nicht der Qualität entspre-
chen, die sogenannten »schlechten« Daten, werden ersetzt oder eliminiert. Die
Datenmenge wird auf die relevante und zuverlässige Datenmenge reduziert. Die
nicht schließbaren Lücken werden identifiziert und zu Vorgaben für die Aus-
wertungsalgorithmen kondensiert.
! "
Datenquellen
Die Suche nach den Komponenten startet mit der Frage nach den Datenquellen,
da alle weiteren Komponenten sich auf die Behandlung der Daten aus diesen
Quellen ausrichten. Für die Auswahl weiterer Komponenten ist daher wichtig,
✔ welche Datentypen (Text, Zahlen, Bitmaps, Strukturgrafike ...) zu verarbei-
ten sind
(Bilddaten müssen z.B. anders verarbeitet werden als Zahlenkolonnen)
✔ welche Datenträger die Daten konservieren
(Papierdokumente müssen eventuell für eine Textrecherche eingescannt
werden)
✔ welche Inhalte die Daten verkörpern
(exakte Zahlen, logische Regeln, verbale Beschreibungen erfordern ver-
schiedene Interpretations- und Auswertungsformen)
✔ welche Güte die Daten im Sinne von Vollständigkeit, Aktualität, Genauig-
keit, Widerspruchsfreiheit bieten
❖ Auswahl der für das DWH relevanten Komponenten aus dem DWH-
Referenzmodell oder mit Hilfe der DWH-Komponentenliste
Feststellen der Monitore für die ausgewählten Datenquellen
Feststellen der Extraktoren für die ausgewählten Datenquellen
Definition der Integratoren der Datenauszüge
Definition der Modell-Definitions- und Verwaltungskomponenten
❖ Festlegen des Datenhaltungs- und Datenbankmanagementsystems
Festlegung des Archivierungssystems
❖ Festlegung der Komponenten zur Interpretation der Daten
❖ Festlegung der Ergonomiekomponenten
Ableitung der Ergonomie-Anforderungen
Feststellung der Präsentationskomponenten
DWH-Komponentenliste
Für die Evaluation und Beschaffung ist die Auflistung der DWH-Komponenten
erforderlich. Das folgende Muster einer DWK-Komponentenliste dient als
Checkliste für die Zusammenstellung des Bedarfs.
Empfehlenswert ist neben der Bestimmung der Komponenten noch die Einord-
nung nach deren Bedeutungsgraden bezüglich der Lösung der gestellten Aufgabe
nicht erforderlich > nützlich > unbedingt nötig,
nach den Möglichkeiten für die Kostengestaltung
nicht beschaffen > eventuell beschaffen > unbedingt beschaffen
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 193
4.2.1 Übersicht
Bei verschiedenen Herstellern sind die gleichen Komponenten mit unter-
schiedlicher Funktionalität ausgestattet. Andererseits können verschiedene
Komponenten teilweise gleiche Funktionen umfassen. Deshalb ist unabhängig
von der Komponentenbetrachtung eine Funktionsbetrachtung erforderlich.
Die Menge aller DWH-Funktionen ist selbst wieder so umfangreich, dass sich
eine gruppierende Übersicht bewährt. Die folgenden, sich nicht unbedingt
gegenseitig ausschließenden Funktionsgruppen können unterschieden werden:
✔ Editieren
✔ Benutzerführung
194 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?
✔ Fachfunktionen
✔ Funktionenerstellung
✔ Data Mining
✔ Schnittstellen
✔ Reporting
✔ Navigation
Die Funktionen werden im Folgenden überblicksartig aufgelistet. Die speziel-
len DWH-Funktionen sind in den folgenden Abschnitten detaillierter darge-
stellt.
Editierfunktionen
Editierfunktionen sind Funktionen, mit denen Dateninhalte und ihre Darstel-
lung bearbeitet werden. Die Inhaltsbearbeitung besteht aus den Grundfunktio-
nen »Eingeben neuer Daten«, »Löschen vorhandener Daten«, »Kopieren von
Daten«, »unveränderndes Lesen«, »teilweise Verändern«. Editierfunktionen
werden in einem Programm namens Editor zusammengefasst.
✔ Elementarfunktionen
Eingabe, Löschen, Kopieren, Ansehen, Korrigieren (Update)
✔ Bearbeitungsfunktionen
Umordnen, Einordnen,
Mustersuche, Austauschen
✔ Bearbeitungshinweisfunktionen
Verbergen, Sichern vor Veränderung
Einbetten von Verweisen (Hypertext-Links)
Funktionen zur Benutzerführung
Funktionen werden auf der Benutzeroberfläche durch Symbole (Menüpunkt,
Feld, Button, Icon, Liste) präsentiert und durch eine Benutzerinteraktion oder
eine Eingabe (Drücken der Enter-Taste, Dateneintrag, Mausklick) ausgelöst. Mit
einigen Funktionen soll der Benutzer seine Programme auf eine ihm angemes-
sene Arbeitsweise anpassen können. Das betrifft z.B. die Anordnung der Bedie-
nelemenete auf dem Bildschirm oder die Präsentation der Dokumente auf dem
Bildschirm. Diese Funktionen nennt man Benutzerführungsfunktionen.
✔ Hilfeführung
Suchindex
Online-Handbuch mit ausführlicher Anleitung zur Bedienung der Pro-
gramme
Lernprogramm mit interaktiven Hinweisen bei vermutlichen Eingabefehlern
✔ Customizer
Bestückung der Menüs mit Befehlen
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 195
Schnittstellenfunktionen
Schnittstellenfunktionen sind erforderlich, um zwischen verschiedenen Pro-
grammen auf einem Gerät oder zwischen verschiedenen Geräten Daten auszu-
tauschen. Der Ausdruck eines Dokuments auf einem Drucker benötigt ein
Schnittstellenprogramm (Druckertreiber). Der Zugriff auf eine Datenbank
benötigt einen Datenbanktreiber. Ist die Datenbank auf einem anderen Rechner
installiert als das anfragende Programm, ist ein Transport der Daten durch ein
Netz abzuwickeln. Der Transport von Daten durch ein Netzwerk benötigt Pro-
gramme, welche die Daten für den Transport transformieren, das Ziel adressie-
ren, mit Sichereitsinformationen bestücken und Verbindungsunterbrechungen
egalisieren.
✔ Gerätetreiber
Drucker, Scanner, Lesestift, Barcode-Leser, Plotter, Fax
Telefonmodem, ISDN-Modem, LAN-Modem, GSM-Modem
✔ Importfunktionen
z.B. von Spreadsheet-Tabellen, Texten, Adressen, Grafiken in ein Textverar-
beitungsprogramm
✔ Exportfunktionen
in andere eventuell lokal entfernte Dokumentensysteme
✔ Softwaretreiber
für Datenbankzugriff mit ODBC, SQL, CICS u.a.
für den Aufruf entfernter Funktionen wie RPC, RFC
Crosscompiler
Navigationsfunktionen
Die Navigationsfunktionen helfen, die Orte zu finden, an denen die gewünschte
Information liegt, sich dort hin zu bewegen und die gesuchten Files aufzuru-
fen, d.h. ihre Präsentation auf einem Monitor zu starten.
✔ Navigator
zur Orientierung in der Ablagestruktur von Dokumenten und Files
✔ Drill Down Funktion
die Betrachtung detaillierterer Stufen einer hierarchisch verdichteten
Datensammlung
✔ Drill Across
die Betrachtung der Daten auf den Stufen gleichen Detaillierungsgrades
einer hierarchisch verdichteten Datensammlung
Reportingfunktionen
Die Reportingfunktionen dienen zur Darstellung von Informationen und deren
Zusammenstellung zu einem Bericht. Einige dieser Funktionen der Darstel-
lung von komplexen Sachzusammenhängen sind speziell für das DWH interes-
sant.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 197
✔ Allgemeine Reportfunktionen
Seitenlayout: Schriftkopf, Fußzeile, Ränder, Spalteneinteilung,
Rahmen, Schattierungen, Zeichenarten, Schriftgrößen,
Montage von Texten, Grafiken, Tabellen aus unterschiedlichen Quellen
✔ Grafikfunktionen
Businessgrafiken: Balkendiagramm, Punktediagramm, Portfoliomatrix,
Trendkurve, Kreissegmentdarstellung, Mengenflusszweige, Punktewolke,
Datenspinne
alternative Grafiken und automatische Grafiken zur Darstellung von Zah-
lenmengen
Sondersymbole und Beispielgrafiken
✔ Data Warehouse Reporting
Exception Reporting: Auslösen von Signalen, Nachrichten und Berichten
bei besonderen, sich in Daten repräsentierenden Veränderungen
Schwellenwertanzeige zur automatischen Hervorhebung der von einem
vordefinierten Zustand abweichenden Werte
Die Reportingfunktionen stellen die Grenzen der Darstellbarkeit komplexer
Zusammenhänge dar. Einfache Zusammenhänge sind schon aus Listen und
Businessgrafiken zu erkennen. Schwieriger ist es, aus verschiedenen Einzeldar-
stellungen Beziehungen zwischen den dargestellten Größen entdecken zu kön-
nen. Ein Beispiel, das einen Maßstab für die Leistungsfähigkeit des Reportings
setzt, zeigt die folgende Abbildung.
✔ Berechtigungsmanager
Zuteilung von Berechtigungsprofilen für den Zugriff auf einzelne Daten,
Tabellen, Datensätze, Spalten, Funktionen, Masken und Rechner
Data Mining Funktionen
Die speziellen Funktionen von Data Warehouse Komponenten dienen der
Suche von Daten, dem Aufspüren von Datenorten und Dateninhalten, dem
Interpretieren von Daten, dem Auswählen, Nachbearbeiten, Zusammenstellen
und Präsentieren von Daten. Diese Funktionen kann man typische DWH-
Funktionen nennen.
✔ Hypothesengenerator
Erzeugung einer formulierten Aussage auf Basis der Überprüfung der Vari-
ablen einer Datenmenge und aller Datenpaare
✔ Hypothesenvalidierer
Überprüfung einer auf Variablen der Datenmenge formulierten Aussage
durch Prüfen aller Datenpaare der Datenmenge
✔ Entscheidungsbaum-Generator
Darstellung einer Entscheidungssituation mit ihren mehrstufigen Möglich-
keiten und den Wahrscheinlichkeiten der Entscheidungsmöglichkeiten auf
allen Stufen
200 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?
✔ Clusterfinder
Analyse von Wertepaaren auf ihre Zugehörigkeit zu einer Gruppe über ihre
Nähe
✔ Regel-Editor
Formulierung von logischen Aussagen über Variablen einer Datenmenge
mittels logischer Operatoren (wenn – dann, nicht, und, oder, für alle,
wenigstens einer) und Umsetzung in Datenbankabfragen
✔ Neuronales Netz – Konfigurator
Konfiguration eines Systems von Recheneinheiten (Unterprogrammen), die
aus Ergebnisvergleichen und Vergleich von Grundgrößen auf Gesetzmäßig-
keiten zur Erzielung bester Ergebnisse schließen
✔ Simulator
Berechnung des Verlaufes definierter Größen aus der Veränderung der
Werte anderer Größen und deren Darstellung als Grafik
✔ Animator
Präsentation der Veränderung von Werten diverser Grundgrößen als beweg-
tes symbolisiertes Bild
✔ Optimierer
Variation einer Grundsituation in Richtung eines optimalen Ergebnisses
Lineare Optimierung
Genetische Optimierung mit Hilfe genetischer Algorithmen
Für ein intensiveres Studium der statistisch orientierten Methoden des Data
Mining ist zu empfehlen:
Bewry u.a., Data Mining
Es ist auch möglich, in einer Portfoliomatrix ein Produkt mit seinen Positionen
aus der Vergangenheit darzustellen. Auf der Synopse der historischen Positio-
nen des Produkts kann eine Prognose für die nächste Position abgeleitet wer-
den.
Für jedes der vier Felder gibt es eine Handlungsempfehlung bezüglich der wei-
teren Ausrichtung des Produkts:
✔ Feld 1: wenig relativer Marktanteil, hohe Wachstumschance > investie-
ren oder nicht investieren, wenn klar ist, dass keine Marktposi-
tion erzielt werden kann
✔ Feld 2: hoher relativer Marktanteil, hohe Wachstumschance > investie-
ren für den Ausbau der Position
✔ Feld 3: hoher relativer Marktanteil, niedrige Wachstumschance > kein
weiterer Ausbau, sondern Umsätze kassieren und Ausstieg vorbe-
reiten
✔ Feld 4: wenig relativer Marktanteil, niedrige Wachstumschance > Abzug
aller Investitionen
Es ist ebenfalls möglich, statt einer Einteilung in zwei mal zwei Felder eine
Neun-Felder Matrix einzuteilen. Bei mehr als neun Feldern wird die Matrix und
alle daraus abgeleiteten Handlungsempfehlungen unübersichtlich.
Zusammenfassend lässt sich sagen:
➡ Die Funktion Portfoliomatrix positioniert ein oder mehrere Produkte mit
einem oder mehreren historischen Positionen entsprechend der Wachstum-
schancen und des relativen Marktanteils in einer Vier-Felder-Matrix, symbo-
lisiert durch eine Kreisfläche, deren Durchmesser im Verhältnis der
Umsätze stehen.
ABC-Analyse
Die ABC-Analyse ist zum Zwecke der schnellen Klassifizierung der für den
Betriebserfolg wichtigen Kunden erfunden worden. Ziel ist dabei, die Kunden
nach ihrem Umsatz in drei Gruppen einzuteilen: die »Großkunden«, mit denen
nahezu der gesamte Umsatz gemacht wird, die Mittelgroßkunden, mit denen
noch ein guter Zusatzumsatz erreicht wird, und die Kleinkunden mit kleinen
Umsätzen.
Beispielsweise könnte die ABC-Gruppierung wie folgt eingeteilt werden:
✔ A-Kunden: Gruppe der umsatzstärksten Unternehmen, die bis 80% des
Gesamtumsatzes tragen
✔ B-Kunden: Gruppe, die zwischen 80% und 95% bewirken
✔ C-Kunden: Restgruppe, welche die letzten 5% des Umsatzes bewegen
Die ABC-Analyse kann generell auch für Kumulationsbetrachtungen mit ande-
ren Größen als Umsätzen eingesetzt werden, wie z.B. Mengen von Bestellun-
gen, Servicenachfragen im Call Center oder Umfang von Garantiefällen aus Auf-
trägen.
In der Abbildung ist die ABC-Kurve dargestellt, die auf der x-Achse (% der Kun-
den) die Kunden der Höhe ihres Umsatzes nach von links nach rechts aufreiht.
Auf der y-Achse sind die summierten Umsätze in % bis zu der x-Prozentsumme
angetragen. Man kann ablesen, dass mit ca. 36% aller Kunden schon 80% des
Umsatzes erreicht wird. Um 95% des Umsatzes zu erwirtschaften (ca.72% der
Kunden), müssen weitere 36% Kunden betreut werden. Für die letzten 5% des
Umsatzes sind noch einmal 28% der Kunden zu verwalten.
Diese Gruppeneinteilung ist für gezielte Marketingmaßnahmen interessant.
Um Kunden der A-Gruppe zu halten, darf und sollte man in mehr Marketing-
maßnahmen investieren als für die C-Kunden.
Zusammenfassend lässt sich sagen:
➡ Die Funktion ABC-Analyse reiht Objekte entlang der x-Achse nach der
Größe eines Messwertes, kumuliert diese Messwerte entsprechend der Grö-
ßenreihung und trägt die kumulierten Werte an der y-Achse zu der zugehö-
rigen Position des Objekts auf der x-Achse an.
Das Beispiel der folgenden Abbildung ist aus der Zeitschrift Office, Heft 6, 1997
entnommen.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 203
Entscheidungsbaum
Der Entscheidungsbaum ist aus dem Bedarf entstanden, komplexe Gesamtent-
scheidungen über Teilentscheidungen zu lösen.
In der Abbildung ist ein Entscheidungsbaum mit drei Stufen dargestellt. Das
Entscheidungsproblem »A« lässt sich in zwei Einzelentscheidungen »B« und
»C« zerlegen. Beiden Möglichkeiten lässt sich eine Erfolgswahrscheinlichkeit
von 0,3 bzw. 0,7 oder 30% bzw. 70% zuordnen. Die Zwischen- oder Teilentschei-
dungen »B« und »C« sind im Beispiel in weitere Teilentscheidungen zerlegbar.
Für »B« ist diese Zerlegung in die Teilentscheidungen »D« und »E« zweiter
Stufe möglich. Die Teilentscheidung »D« ist noch in zwei weitere Teilentschei-
dungen der dritten und letzten Stufe möglich. Im Beispiel führt die Zerlegung
zu elf möglichen Entscheidungen des Problems »A«. Jede der Entscheidungen
E1 bis E11 hat eine Bewertung, wie z.B. eine Erfolgswahrscheinlichkeit.
Die Erfolgswahrscheinlichkeit w(E) der Entscheidung E ist das Produkt aller
Erfolgswahrscheinlichkeiten des Weges von der Wurzel des Entscheidungsbau-
mes bis zum betreffenden Entscheidungsblatt. Für die Entscheidungen E1 und
E2 ist dies
w1(E1) = w(AB) · w(BD) · w(DE1) = 0,3 · 0,2 · 0,1 = 0,006
w(E2) = w(AB) · w(BD) · w(DE1) = 0,3 · 0,2 · 0,9 = 0,036
Zu jeder neuen Entscheidungsstufe führt ein Entscheidungskriterium bzw.
eine Entscheidung. Die Kriterien können unter Umständen in der Reihenfolge
der Entscheidungszerlegung vertauscht werden.
204 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?
Abbildung 4.14: Beispiel eines Entscheidungsbaumes
Cluster
Die Clusteranalyse wurde entwickelt, um aus einer Punktemenge Gruppen von
nahe beieinander liegenden Punkten zu entdecken.
In der Ebene kann man diese Gruppen von Punkten in der Regel mit bloßem
Auge erkennen. In einer Datenbank sind diese Gruppen nicht sichtbar und bei
besonders großen Mengen von Datenpaaren sind der Leistungsfähigkeit des
Auges Grenzen gesetzt. Hinzu kommt, dass das Auge nur zwischen eng beisam-
men und weiter entfernt unterscheiden kann, aber keine Messwerte ausgibt
und damit subjektiv wahrnimmt. Für eine objektive Messung ist ein Maßstab
zur Abstandsmessung, ein Abstandsmaß, erforderlich.
Alle bekannten Punkte werden in einer x-y-Ebene mit maßstäblichen Skalen
eingetragen. Ein Programm berechnet die Abstände aller Punkte zueinander
und gruppiert einem Maximalwert eines Abstandes entsprechend alle Punkte-
paare, deren Abstand kleiner als der Maximalwert ist. Die Punktegruppen hei-
ßen Cluster. Ein Punkt gehört immer zu genau einem oder gar keinem Cluster.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 205
Trendkurve
Die Trendkurve macht die Annahme, dass die Punkte einer zu analysierenden
Datei Messwerte einer mathematischen Funktion sind, die ungenau gemessen
wurde. Dies ist z.B. in der Physik durch Umgebungsbedingungen, abgenutzte
Messwerkzeuge und Ablesefehler der Fall. Mit der Trendanalyse versucht man
nun, diese eigentliche Kurve zu rekonstruieren. Die Punkte streuen um die
gesuchte Trendkurve.
Ziel der Trendanalyse ist, diese Kurve nicht nur für die vorliegenden Punkte
herauszufinden, sondern auch für nicht gemessene Werte außerhalb der
Punktmenge. Die Trendkurve wird außerhalb der Punktemenge fortgesetzt.
Zusammenfassend lässt sich sagen:
➡ Die Funktion Trendermittlung berechnet aus Punkten in einem n-dimensi-
onalen Raum eine geschätzte Kurve mit der geringsten Abstandssumme zu
den Punkten und berechnet Werte, die außerhalb der Punktemenge liegen,
entsprechend der Fortsetzung der Kurve Trendkurve genannt.
Multiwürfel
Die Datendarstellung als Multiwürfel ist aus dem Bedürfnis entstanden, die
Datenfelder zu multidimensionalen Parametern übersichtlicher darzustellen.
Mit der Multidimensionalität ist gemeint, dass der Wert oder Inhalt eines
Datenfeldes von den Werten einer festen Anzahl anderer verschiedener Daten-
felder, den Dimensionen, abhängt.
Ein vielzitiertes Beispiel ist der Umsatz, das abhängige Datenfeld eines dreidi-
mensionalen Multiwürfels; der Inhalt des Datenfeldes ist die Umsatzzahl, z.B.
in DM. Die drei Würfel-Dimensionen sind die Datenfelder »Produkt«,
»Region«, »Zeit«. Die im Würfel dargestellte Aussage ist dann von dem Muster:
✔ eine spezielle Umsatzzahl ist der Umsatz in DM
zu einem bestimmten Produkt
in einer bestimmten Region
in einem bestimmten Zeitabschnitt
Die Werte der Dimensionen sind entlang der Würfelkanten zu lesen, also zum
Beispiel sind die Werte der Dimension »Zeit« die Monate und die Werte der
Dimension »Produkte« die Namen der einzelnen Produkte.
Die Einheit einer Dimension kann zu Akkumulationseinheiten zusammenge-
fasst werden. Zum Beispiel kann zur Dimension »Zeit« die Einheit »Monate«
und die Einheit »Jahre« angeführt werden.
Je feiner die Einheit gewählt wurde, umso mehr Verdichtungsebenen oder
Akkumulationsstufen sind möglich. Eine feinere Zeiteinheit könnte z.B. »Tage«
sein, und die Akkumulationsstufen in der Reihenfolge ihrer Verdichtung könnte
dann sein: »Wochen«, »Monate«, »Quartale«, »Jahre«, »Gesamtzeitraum«.
Multiwürfel können im relationalen Datenmodell aus einer zentralen Tabelle
und sternförmig damit in Relation stehenden Tabellen (eine pro Dimension)
dargestellt werden. Deshalb wird oft von Star-Schema gesprochen.
Bei mehr als zwei Dimensionen kann man den Blick auf den Würfel verändern.
Im Beispiel kann man z.B. aus der Sicht eines ausgewählten Produkts die
Matrix (zweidimensionaler Würfel) der Umsätze der Regionen entsprechend
den Zeiteinheiten sehen. Die Sicht kann auf verschiedene Akkumulationsebe-
nen eingestellt werden. So kann die Matrix die Umsätze der Monate oder der
Wochen oder der Jahre ausweisen.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 207
Verfahren: DWH-Funktionen
❖ Festlegung der allgemeinen funktionalen Anforderungen mit Hilfe der
DWH-Funktionenliste
❖ Festlegung der ergonomischen Funktionen
Feststellung der zu versorgenden Managementebenen
(wenn nicht bereits im Schritt betriebswirtschaftliche Anwendung
geschehen)
Ableitung der Ergonomie-Funktionen
Festlegung der Ergonomiekomponenten
❖ Festlegung der spezifischen Funktionen
entsprechend der ausgewählten Komponenten
❖ Spezifikation der Anpassungsfähigkeit der Funktionalität
Festlegung der Entwicklungsfunktionen
❖ Spezifikation der Funktionen, die in Eigenentwicklung hergestellt
werden müssen
Die zu lösende Gestaltungsfrage lautet also: Mit welcher Funktionalität soll ein
DWH ausgestattet sein und wie kann man die Konsequenzen des Fehlens der
einzelnen Funktionen einschätzen.
DWH-Funktionenliste
Das Mittel zur Definition der Funktionalität ist eine DWH-Funktionenliste, die
aus Literaturstudium, Evaluationsstudien und Produktvergleichen selbst ange-
fertigt werden kann. Oftmals sind in einer Fachzeitschrift taugliche Listen ver-
öffentlicht. Meistens sind dort allerdings die Konsequenzen fehlender Funktio-
nen nicht dargestellt.
Die veröffentlichten Listen bergen die Gefahr in sich, dass die für das eigene
Unternehmen relevanten Teile dort eine untergeordnete Rolle spielen, da sie
meistens aus verwandten, aber leider nicht identischen Projekten stammen und
nur begrenzt verwendbar sind. Hier kann die Beauftragung eines Beratungsun-
ternehmens, das eine auf die spezielle Situation des Unternehmens bezogene
aktuelle Funktionenliste zusammenstellt, weiterhelfen. Die Konsequenzen
mangelnder Funktionskenntnis sind erheblich. Sie sind entweder mit Leis-
tungseinschränkung oder mit Mehraufwand, weiterem Zukauf und Terminbe-
lastung verbunden. Die Feststellung der interessanten Funktionen sollte in
einer sinnvollen Reihenfolge abgewickelt werden.
Neben den Betrachtungen zu speziellen für das DWH nützlichen Funktionen
gibt es übergreifende Kriterien, allgemeine Anforderungen, die von der speziel-
len Funktionalität des DWH unabhängig sind.
210 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?
Je mehr Programme einem User zur Verfügung stehen, umso mehr Benutzer-
führungen muss der Benutzer beherrschen. Die Gefahr, Programm A mit der
gerade intensiv betriebenen Benutzerführung von Programm B versehentlich
zu bedienen, kann unbeabsichtigte Reaktionen von Programm B auslösen. Die
Bedienungselemente der Programme unterschiedlicher Hersteller haben eine
unterschiedliche Präsentation oder Symbolik auf dem Bildschirm. Der Anwen-
der wird dadurch, je heterogener die Produktelandschaft ist, mit einem erhöh-
ten Lernpensum und mit ständigem Umorientieren bei wechselnder Nutzung
der Programme konfrontiert. Das macht seine Arbeit ineffizient.
➡ Die allgemeinen Funktionen und ihre Präsentation sollten über eine
Anwendung oder noch besser über alle im Unternehmen eingesetzten
Anwendungen einheitlich sein.
Jede Überfunktionalisierung steigert die Fehlerhäufigkeit und die Nachfragen
der User zur Klärung der Frage, ob man die Funktion vielleicht doch irgendwie
gebrauchen könnte. Damit steigen die Aufwendungen für die Administration
und Betreuung.
➡ Reduktion der Gesamtfunktionalität auf das in der Bedarfsanalyse für jeden
Benutzertyp erhobene Minimum an Funktionalität
Als Einstieg in die systematische Zusammenstellung der DWH-Funktionalität
sei hier eine Liste vorgestellt (siehe Tabelle 4.5).
Die Funktionen haben nicht alle die gleiche Wichtigkeit und müssen deshalb
auf ihre Notwendigkeit beurteilt werden. Es sind drei Kategorien ausreichend:
✔ Muss-Funktionen, ausschließende Kriterien; Produkte die diese Kriterien
nicht erfüllen oder diese Funktionen nicht besitzen werden ausgeschlossen
✔ Soll-Funktionen; ein Fehlen dieser Funktionen hat Konsequenzen für Ter-
mine, Aufwände und Qualität
✔ Kann-Funktionen; wünschenswerte Funktionen, die nur leichte Einbußen
für den Nutzer bedeuten
Die Liste der funktionalen Anforderungen wird in der Evaluation verwendet. In
mittelfristiger Zukunft wird die Liste als Bestellliste für Funktionsbausteine
dienen können. Durch die Vielzahl der eingesetzten Werkzeuge ist zu beachten,
dass sich die Funktionalität der einzelnen Komponenten überschneidet. Die
Mehrfachabdeckung gleicher Funktionen soll unbedingt minimiert werden.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 211
SQL-Generator Lernprogramm
Schnittstellenfunktionen 4GL-Compiler
Gerätetreiber Datenbankschemagenerator
Importfunktion Datenbankschemadesigner
Exportfunktion Editierfunktionen
Formular-Formatierer Navigator
Sensitivitätsanalysen
ABC-Analyse Modellverwaltung
DWH-Funktionen
Neuronales Netz
Fuzzy-set-Analyse
Optimierungsrechnung
Hypothesengenerator
Entscheidungsbaum-
analyse
Sie dienen zum Zeichnen von Programm- und Datenbankstrukturen bis zur
Erzeugung von Programm-„Stücklisten«. Einige können sogar Programmkom-
ponenten und Datenbanken generieren. Die eigentliche Programmierarbeit
wird immer häufiger durch immer leistungsfähigere Generatoren ersetzt.
Eine Zwischenvariante zwischen absoluter Eigenentwicklung und Standard-
software ist Zukauf und Eigenentwicklung von Bausteinen und deren Montage
in ein neu zugekauftes Framework, bzw. in eine zugekaufte Mutterapplikation,
die Komponentenmontage. Diese setzt voraus, dass man ein standardisiertes
Framework hat. Man weiß heute noch nicht, welche Produkte von Frameworks
sich langfristig durchsetzen werden. Auf alle Fälle kann man in den Medien ein
verstärktes Interesse am Zusammenbau von Software aus Komponenten durch
die anwendenden Unternehmen ausmachen.
Die Entscheidungsmöglichkeiten der Softwarefertigungstypen sind:
✔ Beschaffung von fertigprogrammierter Standardsoftware (technische Soft-
ware, kaufmännische Software), wenn alle gewünschten Eigenschaften zur
Zufriedenheit der Anwender abgedeckt sind
✔ Officetools, wenn die Aufgaben nicht vorherbestimmbar sind und nur für
einige ausgewählte Anwender anfallen, so dass umfassende Individual-Pro-
grammierung zu teuer ist
✔ Vorgefertigte Softwarebausteine, Komponenten, Programmmuster, Frame-
works
✔ Entwicklungswerkzeuge für die Individualentwicklung, wenn wesentliche
der geforderten Eigenschaften nicht enthalten sind
✔ Reine Individualprogrammierung mit Programmiersprachen früher Gene-
rationen
Mit der Entscheidung für den Fertigungstyp ist die Entscheidung über die
Anpassungsfähigkeiten des Softwarepakets getroffen:
✔ Ausprogrammierte, starre Standardsoftware, wenn kein eigenes Personal
für Anpassungsarbeiten aufgebaut und unterhalten werden soll und wenn
die Arbeit einem weithin bewährten Industriestandard zugeführt werden
soll
✔ Parametrisierte und konfigurierbare Standardsoftware
✔ Komponentenzukauf, wenn ein gutes Framework vorhanden ist und die
Komponenten die erforderlichen Eigenschaften abdecken
✔ Dynamische Selbstkonfiguration
Jeder Fertigungstyp hat eine andere Benutzerführung und andere Freiheits-
grade in der weiteren Ausgestaltung und der Starrheit der Anwendung. So
erlauben zum Beispiel Workflowsysteme, die Veränderung der Reihenfolge der
Benutzerschritte ohne Programmierung zu verändern. Kalkulationstabellen-
214 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?
✔ Festigkeitsberechnung, Finit-Elemente-Berechnung
Beispiele für kaufmännische Standardsysteme sind:
✔ Kostenrechnung und Finanzbuchhaltung
✔ Personalverwaltung
✔ Materialverwaltung
Beispiele für geographische Systeme sind:
✔ Wetterkarten
✔ Geographische Orientierungssysteme
✔ Routenplaner
Beispiele für Prozesssteuerungssysteme zur Steuerung von Industrieprozes-
sen sind:
✔ Verkehrsleitsysteme
✔ Hausleitsysteme
✔ Leitstände von Energieversorgungsanlagen
✔ Produktionsstraßensteuerung
Beispiele für übergreifende Systeme sind:
✔ Archivierung
✔ Kommunikation, Fax, Mailing
Bleibt noch anzumerken, dass diese Liste der fachlichen Technologietypen
nicht vollständig ist und durch Neuentwicklungen des Marktes ständig erwei-
tert wird.
Verteilungstypus
Die Verteilungstypen einer Software unterscheiden sich durch ihre Auftren-
nung in Komponenten, die auf verschiedenen Rechnern betrieben werden kön-
nen. Für diese Auftrennung wurden die drei Ebenen Präsentationsschicht,
Applikationsschicht, Datenhaltungsschicht definiert. Auf den jeweiligen Archi-
tekturschichten sind wieder verschiedene Softwaretechnologien einsetzbar und
kombinierbar.
Diese Schichten können selbst wieder zerteilt und die Bestandteile weiter ver-
teilt werden. Dies ist im »Exkurs Client/Server-Architekturen« am Ende von
Kapitel 5 »Hardware« ausführlich dargestellt. Die Möglichkeiten des Zusam-
menspiels dieser Teilung führt zu den folgenden Verteilungsarchitekturen:
✔ Host-Terminal
✔ Entfernte Präsentation
216 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?
Objektorientiert Regelbasierte DB
Regelbasiert Deduktive DB
Fuzzy Fuzzy DB
✔ Client-Server
✔ Remote Zugriff
✔ Mobiles System
✔ Peer to peer
✔ Multi Tier System
Diese Aufzählung ist nur als Orientierung und zur Verdeutlichung der Vielfäl-
tigkeit der Möglichkeiten gedacht. Vollständige Klassifikationen mit Begrün-
dungen sind vereinzelt in verschiedenen Büchern zu der jeweiligen Thematik
zu finden, z.B. für das Thema Verteilung in
Mühlhäuser, Software Engineering
Programmiersprachen und deren Klassifikation in
Sammet, Programming Languages
Ghezzi, Jazayeri, Programmiersprachen
Datenbanken, deren Klassifikation und Technologie in
Vossen, Datenmodelle
Aus der Sicht der Verteilungstechnologien von Software sind folgende Schich-
tenkombinationen wesentlich:
✔ Hostbasierte Applikation mit hierarchischer Datenbank und zeichenorien-
tierter Oberfläche und Terminal
✔ Client/Server-Architektur mit relationaler Datenbank und grafischen Ober-
flächenobjekten
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 217
Technologietypus
Wesentliche Bedingung für die Entscheidungsfreiheit ist der Markt. Was nüt-
zen die besten Vorsätze, wenn der Markt nicht die nötigen Produkte hierfür
anbietet? Die Entscheidung des Software-Technologietypus hängt in erster
Linie ab
✔ von der Bereitschaft des Unternehmens, neue Wege in der Hardwaretechno-
logie einzuschlagen, bzw. von der Beharrlichkeit, sich auf die altbewährten
Technologien zu verlassen:
⇒ Beibehalten alter Host/Terminal-Systeme oder
⇒ Ablösen durch moderne Client/Server-Architekturen
✔ von der Berücksichtigung vorhandener Softwaresysteme: Teile eines DWH
sind bereits auf vorhandenen Technologien realisiert
⇒ Beibehalten der Host/Terminal-Systeme oder
⇒ Integration des Host als Server-Komponente
✔ von der Bereitschaft, in die modernste Technologie zu wechseln
⇒ Vollständige objektorientierte Anwendungen eventuell mit verteilten
Objekten
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 219
Präsentation
Applktn DB
Applikation
Datenbank
Für die Entscheidung des Fertigungstyps ist die Ebene und Position des Benut-
zers von Bedeutung. Je höher die Ebene des Benutzers in der Hierarchie des
Unternehmens, desto mehr Selbsterklärung der Software ist erforderlich und
umso einfacher muss die Nutzerführung sein. Dies leistet Standardsoftware mit
festprogrammierten Dialogen besser als parametrisierbare Software und Indivi-
dualsoftware, welche der Benutzer erst im Laufe langer, intensiver Nutzung zu
beherrschen lernt.
Für die Entscheidung über die Fertigungstypen ist auch die Wettbewerbsrele-
vanz maßgebend. Systeme, die einen Wettbewerbsvorsprung erzielen sollen,
können nicht von der Stange gekauft werden.
Wenn die Komponenten und das Architekturprinzip bzw. der Technologietyp
feststehen, kann man den Markt auf die Angebote zu den benötigten Kompo-
nenten betrachten und mittels ausführlicher Funktionenlisten die Angebote
beurteilen. Für die konkrete Produktauswahl muss eine Evaluationsstudie
erstellt werden, die auf die funktionalen Unterschiede der Produkte eingeht.
Die Gestaltungsfrage der Evaluationsstudie kann zwar erst nach Beantwortung
der Frage der Funktionalität und nach Beantwortung der Frage nach der
Methodik behandelt werden, man kann aber jetzt schon feststellen, dass keines
der Angebote einzelner Hersteller die Bedarfe vollständig abdeckt. Man wird
deshalb die Frage nach einer Kombination der Produkte mehrerer Hersteller
stellen.
Komponentenliste mit Technologietypisierung
Das Ergebnis der Technologietypenbestimmung ist in einer Liste festzuhalten.
Da zu jeder Komponente die Technologietypen-Entscheidung getroffen werden
muss, ist der Ausgangspunkt dieser Liste die Komponentenliste. Die folgende
Liste »Komponentenliste mit Technologietypisierung« ist ein Beispiel für die
Einordnung der Komponenten als Softwaretyp. Für die Nachvollziehbarkeit
durch Dritte sollte die Entscheidungsbegründung festgehalten werden. Viele
Unternehmen akzeptieren die Entscheidung »Standardsoftware« sehr schnell,
wollen aber auf Grund der hohen Kosten und des hohen Erfolgsrisikos eine
Eigenentwicklung gut begründet haben.
Der nächste Problemlösungsschritt des DWH-Gestalters besteht in der Aufzäh-
lung der Funktionen der einzelnen Komponenten des zukünftigen DWH. Die
Funktionen sind zum Teil allgemeiner Natur, also auch für Programme, die
keine DWH-Komponenten sind, von Bedeutung, wie zum Beispiel grafische
Oberflächen und zum Teil spezielle Funktionen des DWH. Beide Funktions-
gruppen müssen definiert werden. Im folgenden Kapitel werden die software-
technischen Funktionen des Data Warehouse betrachtet.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 221
Legende:
S – Standard, P – Parametrisiert, E – Enduser -Tools, K – Komponenten, I – Individualentwicklung
T – Technisches System, K – Kaufmännisches System, P – Prozesssteuerungssystem, G – Geographisches System, I – Integratiossystem,
T – Terminal, R – Remote Präsentation, A – Remote Access, P – Peer to Peer, C – Client/Server, M – Mobil
Beispiel
Der Fachtyp ist nicht schwer zu bestimmen, ein Instandhaltungssystem hat
sowohl
✔ einen kaufmännischen Teil im Verwaltungssystem der Arbeitsaufträge und
Kostenabrechnung der Instandhaltungsarbeiten
✔ einen technischen Teil mit der Stücklistenzerlegung aller Bauteile, der
topologischen Anlagenteilstruktur, den Konstruktionszeichnungen (CAD)
der Anlagenteile
✔ einen Prozessteil mit dem zeitlichen Produktionsverlauf des Kraftwerks
Da es sich um die Zusammenführung von Daten aus verschiedenen Kraftwer-
ken handelt, muss auf verschiedene Datenbanken und verschieden Systeme
zugegriffen werden können.
222 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?
GIU
OLAP RDB
OLAP,Miner
MRDB
Nach der Abgrenzung der Technologien wird nun die Komponentensicht mit
funktionaler Sicht kombiniert, um zu einem Komponentenbild zu kommen.
Das mit Hilfe des DWH-Referenzmodells abgeleitete InDaWa-Architekturdia-
gramm ist als Lösung im Anhang dargestellt.
Gestaltungsentscheidungen
Zusammengefasst ergeben sich damit die folgenden Gestaltungsentscheidun-
gen für das Beispiel Data Warehouse eines Kraftwerkparkes.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 225
ORIENTIERUNG
ARCHITEKTUR
Betriebswirtschaftskomponenten
...
Softwarekomponenten
Hardwarekomponenten
...
Organisationskomponenten
...
VORGEHENSMODELL
4.5 Übungen
Übung (mit Lösung) 4.1: Beurteilungskriterien OLAP-Produkte
Entwerfen Sie eine systematische Liste von Funktionen mit Beurteilungskrite-
rien zur Produkt-Präsentation eines Herstellers für OLAP-Produkte.
Erster Entscheidungsgang
Zunächst wird im ersten Schritt des ersten Entscheidungsganges auf der
Ebene des Systemtyps der Anwendungstyp abgegrenzt. Das ist mit der Wahl,
ein DWH zu konstruieren, bereits geschehen. Ist der Anwendungstyp definiert,
kann auf der Ebene der Komponenten weiter detailliert werden. Zum Beispiel
könnte die zum Systemtyp DWH gehörige Komponente »Data Mining Tools«
interessant sein.
Im zweiten Schritt des ersten Entscheidungsganges sind die Systemkompo-
nenten zu definieren, die durch die unterschiedlichen Aufgaben der Anwende-
rebene bedingt sind. So ist z.B. für die Aufgabe »Finden von Zusammenhän-
gen« die Komponente Data Mining nötig.
Je nach gewählter Komponente unterscheiden sich die zu Modulen oder Funk-
tionen gruppierten Funktionen. Diese werden im dritten Schritt des ersten
Entscheidungsganges gefunden. Zuerst sind die allgemeinen über das gesamte
DWH homogenen Funktionen zu definieren. Danach sind die für die Kompo-
nente typischen Funktionen festzulegen. Für die Komponente Data Mining ist
das z.B. die Funktionalität der Funktionengruppe zur Hypothesenbildung.
Der vierte Schritt des ersten Entscheidungsganges ist erforderlich, um nach
der Bestimmung der Module die Funktionen festzustellen.
Der Durchlauf durch die Gestaltungsentscheidungen des ersten Entschei-
dungsganges wird am Beispiel des Entscheidungswegs Technologietyp in der
folgenden Darstellung deutlich:
Systemtyp
Anwendungstyp:
DWH
Fertigungstyp:
Standardsoftware 2. Schritt
Systemkompo-
nente
DWH-Komponenten
Data Mining 3. Schritt
Systemmodul
Funktionengruppen
der DWH-Kompo-
nenten 4. Schritt
Funktionen
Funktionen
Zweiter Entscheidungsgang
Nach der Festlegung der Komponentenstruktur und der Ermittlung ihrer
Funktionen im Einzelnen wird im zweiten Entscheidungsgang eine Entschei-
dung über den Fertigungstyp getroffen. Das heißt, es wird festgestellt, ob das
System mit den gewünschten Komponenten als Produkt beschafft werden
kann, ob eine Eigenentwicklung erforderlich ist oder ob die gewünschte Funk-
tionalität dem Nutzer als Office-Makro zur Selbsterstellung zugemutet werden
kann.
Dritter Entscheidungsgang
Im dritten Entscheidungsgang wird der Fachtyp festgelegt. Die verschiedenen
Fachtypen sind mit unterschiedlichen Architekturen und Technologien reali-
siert und unterschiedlich in Komponenten zerlegt. Für die verschiedenen
Komponenten wurden unterschiedliche Technologien entwickelt. Eine geogra-
hische Datenbank eines geographischen Systems ist z.B. anders organisiert als
die relationale Datenbank eines kaufmännischen Systems oder eine technische
Datenbank einer technischen Applikation. Mit diesen verschiedenen Technolo-
gien muss ein DWH kooperieren können.
Vierter Entscheidungsgang
Im vierten Entscheidungsgang wird der Verteilungstyp festgelegt. Der Vertei-
lungstyp gibt die Verteilung der einzelnen Komponenten über die Hardwarear-
chitektur an. Dabei können alle Komponenten auf einem Rechner installiert
sein. Es können auch einzelne Komponenten in mehreren Schichten zerlegt
und auf verschiedenen Rechnern platziert sein. Dies ist zum Beispiel für mobile
Lösungen erforderlich.
Die Entscheidungsgänge zwei bis vier wurden im Text als »Technologietypen«-
Entscheidung parallel abgehandelt.
Die verschiedenen Systemtypen-Elemente sind unterschiedlich tief zu detaillie-
ren. Dies liegt im Ermessen des DWH-Spezialisten. Diese unterschiedlichen
Detaillierungsgrade bringt die Grafik »Entscheidungsgang Data Warehouse
Gestaltung« durch die unterschiedliche Aufteilung der Boxen zum Ausdruck.
Die Grafik gibt nicht in allen Detaillierungsstufen eine vollständige Klassifika-
tion, sondern sie beschränkt sich der Übersichtlichkeit und der Erkenntnis des
Zerlegungsprinzips zuliebe auf die wichtigsten Unterteilungen (siehe Abbil-
dung 4.20).
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 229
%" "
&
#
.*
, )
)
&- "
"$
1 $$
%
!
(
!
( 2&1
( 3&1 # &-4 6
%
4
#
!
4+
! "
%-4
&
-
--
)
*
$
"+
,
-
$
.!
(
! )
6
4
5(
)
!
5
!
(
"
,$ %
( $"
KAPITEL 5
5 Welche Hardwarekomponenten und
Netzinfrastrukturen sind für den Betrieb eines
DWH erforderlich?
Einleitung
Das DWH bezieht Daten von vorhandenen Systemen und gibt diese weiter an
andere Systeme. Ein DWH ist aus Softwaresicht ein Softwaresystem, das mit
bereits vorhandenen, auf verschiedenen Rechnern liegenden Softwaresystemen
kooperiert und auf ihren Leistungen aufbaut. Ein DWH umfasst selbst eine
Reihe von kooperierenden Programmen, d.h. ein Softwaresystem. Programme
benötigen mindestens einen oder mehrere Computer, um ablaufen oder betrie-
ben werden zu können. Die Softwaresysteme, mit denen das DWH kooperiert,
laufen überwiegend auf anderen Computern als das DWH selbst. Zwischen die-
sen Systemen findet Kommunikation statt. Um kommunizieren zu können,
müssen diese Systeme verbunden sein. DWH-Systeme operieren auf Hardware-
systemen.
Das bedeutet, dass zur Gestaltung eines DWH verschiedene Hardwareaspekte in
die Entscheidungen einzubeziehen sind. Diese Hardwareaspekte betreffen den
oder die Computer, auf denen das DWH-System ablaufen bzw. ausgeführt wer-
den soll und auf denen Basisdaten verwaltet werden. Diese Computer sind die
Arbeitsplatzrechner der Benutzer und die Systeme mit den Basisdaten, die Ser-
ver. Mit Typ und Bauart des Rechners ist auch das Betriebssystem festzulegen.
Da verschiedene Rechner miteinander kooperieren müssen, muss auch das
Medium zwischen den Rechnern, die Verbindung zwischen diesen Rechnern, in
die Betrachtung mit einbezogen werden. Dieses Medium ist das Lokale Netz-
werk oder in englischer Sprache das Local Area Network, kurz LAN. Wenn man
bedenkt, dass in großen Unternehmen die Basisdaten über Kontinente verteilt
sind, muss sogar die Kommunikationsverbindung zwischen diesen Ländern,
das Wide Area Network, kurz WAN, einbezogen werden.
Durch die enorme Leistungsfähigkeit der LAN/WAN-Technologien entstehen
viele Möglichkeiten, die Rechner weltweit zu verteilen und die Komponen-
tentechnologie der Software bietet weitere Möglichkeiten, die Softwareteile auf
diesen Rechnern zu verteilen. Das Allokationsproblem ist zu lösen. Im Zusam-
menhang mit dem Allokationsproblem ist die Client/Server-Architektur mit
Technologien zur Kooperation verteilter Softwarekomponenten von Bedeu-
tung.
Hardwarekomponenten und Netzinfrastrukturen
232 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
!"
Lernziel
Der DWH-Spezialist gestaltet die Hardwareausstattung des DWH nicht selbst,
das machen der Netzwerkspezialist und der Rechnerspezialist. Die Lernziele des
Kapitels umspannen deshalb das Wissen, das erforderlich ist, um die Hardware-
anforderungen für den Hardwarespezialisten zu formulieren. Der DWH-Spezia-
list muss dazu die Grundbegriffe von Rechnernetzen beherrschen.
Lernziele:
Definition der Anforderungen an das für ein DWH erforderliche WAN
Komponenten
Vorgabe der Anforderungen an die für ein DWH erforderlichen LAN-
tungsproblem von Konzeption und Beschaffung zu lösen. Dies ist aber nicht die
Aufgabe der DWH-Spezialisten, sondern der Netzwerkspezialisten.
Aus der Sicht der Betriebsart gibt es demnach zwei wesentliche Leitungstypen:
✔ Direktverbindung oder Standleitung mit dauerhaft zur Verfügung stehen-
der Verbindung (Festverbindung) in einer verabredeten Kapazität und Qua-
lität
✔ Frame Relay, ursprünglich virtuelle Festverbindungen von Lokalen Netzen,
neuerdings auch mit Wählverbindung in einer verabredeten Kapazität
Für die Übertragung der Informationen stehen unterschiedliche Medien zur
Verfügung. Das können z.B. folgende von einem die erforderliche Infrastruktur
und die Wegerechte besitzenden Vermieter zur Verfügung gestellten WAN-
Leitungen sein
✔ Glasfaserkabel
✔ Kupferkabel
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 235
solche Dienste auf der Basis einer bestehende Infrastruktur angeboten werden,
wird von einer sogenannten Mehrwertleistung gesprochen. Provider bieten also
Mehrwertdienstleistungen und Leitungsnutzung an.
WAN-Komponenten
Ein WAN beginnt bei der Ankoppelung der LANs und der Haustelefonanlage
oder auch einer Hausvideoanlage an ein überregionales Leitungssystem wie
z.B. das Postnetz. Diese Ankoppelung des LAN an ein WAN wird über Geräte,
sogenannte Router hergestellt. Router gehören zu den sogenannten aktiven
Komponenten. Vom Router fließen die Informationen in die eigentliche Verbin-
dungsstrecke; diese besteht aus terrestrischen Kabeln, die zu Sendern und von
da über Funkstrecken zu Funkempfängern führen; von dort werden die Infor-
mationen wieder in terrestrische Kabel eingespeist. Die Router können selbst
beschafft und installiert werden, oder sie können vom Provider installiert und
mit der Leistungsnutzung mit vermietet werden.
Lasten und Kapazität
Die Leitungsmiete ist umso teurer, je größer die bestellte Leitungskapazität,
also der pro Zeit erforderliche Datendurchfluss der Leitung ist. Ziel ist deshalb,
die Leitungen zwischen den Standorten gerade so groß zu wählen, dass die Ant-
wortzeiten durch die Benutzerzugriffe für die Anwendungen der erforderlichen
Arbeitsergonomie entsprechen.
Die durch die Leitungen transportierten Datenmengen hängen von den Daten-
typen und den Dokumentenarten ab. Reine Zahlensammlungen benötigen
weniger Kapazität als Textdokumente, Textdokumente benötigen weniger als
Spreadsheets, diese wiederum weniger als Grafiken, Grafiken weniger als CAD-
Zeichnungen und diese weniger als Videosequenzen.
Zahlenliste < Textseite < Kalkulationssheet < Businessgrafik
< CAD-Zeichnung < Videosequenz
Die Leitungskapazität und die Datenübertragungsrate werden als Datendurch-
satz pro Zeiteinheit gemessen. Wobei der Datendurchsatz in der kleinsten
Dateneinheit »Bit« und die Zeiteinheit in Sekunden gemessen wird:
Leitungskapazität = Datendurchsatz/Zeit [Bit/Sekunden]
Die vermutete anfallende Last wird berechnet aus der durchschnittlichen paral-
lelen Zugriffsanzahl der Benutzer, der Benutzerzahl, der Größe der Dokumente
und der Anzahl der pro Zugriff zu transportierenden Dokumente. Als Annähe-
rungswert ist folgende Formel nützlich:
Leitungslast = durchschnittliche Zugriffsanzahl pro Benutzer in der Sekunde ·
Benutzerzahl · Gleichzeitigkeitsfaktor des Zugriffs · Dokumen-
tenanzahl pro Zugriff · durchschnittliche Dokumentengröße
[Bit/Sekunden]
Alternativ zur Einheit »Bit« wird oft auch die Einheit Byte = 8 Bit zur Angabe
von Zeichenmengen verwendet.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 237
Beispiel
In der folgenden Abbildung ist ein Beispiel für ein WAN, das WAN der deut-
schen Fluggesellschaft Lufthansa, mit Kapazitätsangaben dargestellt. Man
sieht, dass die Lufthansa mehrere Standorte unterhält und diese in den deut-
schen Großstädten angesiedelt sind. Die Standorte beherbergen mehrere
Typen wie Büro, Hauptverwaltung, Flugstation, Buchungszentrum, die
innerhalb eines Standorts teilweise ebenfalls durch WAN-Strecken verbun-
den sind.
Bezüglich der Kapazitätsangaben im Diagramm bedeutet z.B. 2M eine Kapa-
zität von 2Megabit (2·10 6) Bit Informationen und 64 k eine Kapazität von
64· 1.000 Bit.
238 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
!"
&
#'
#' $#
#
) #
$'
"#
)
&
+
,
#
! $ $
%
) #
#
$
!!
!
#
+
-#
+
(&
#
*
#
&
$
$
"
#
gien und Technologien umrissen. Es ist nicht die Aufgabe des DWH-Spezialis-
ten, ein Kommunikationsnetz zu entwerfen. Er muss wissen, dass die Kompo-
nenten des DWH über ein Kommunikationsnetz in Verbindung stehen und
Daten austauschen. Diese Kommunikationswege sind für die Performance, für
die Verfügbarkeit und überhaupt für die Erreichbarkeit von Datenquellen maß-
gebend. Eine Datenquelle, zu der keine Netzverbindung besteht, kann nicht
angefragt werden. Der DWH-Spezialist muss so viel von einem Kommunikati-
onsnetz verstehen, dass er mit dem Netzspezialisten besprechen kann, was
gebraucht wird.
Die Anforderungen, die der DWH-Spezialist dem Netzspezialisten übergeben
muss, sind Lastanforderungen, Lokationen der Benutzer und Lokationen der
Datenquellen. Hinzu kommt noch eine gewisse Bedeutung der Verfügbarkeit
aus der Sicht der Benutzer. Die lokale Verteilung der Benutzer ist meistens vor-
gegeben, da ein Unternehmen, das ein DWH betreiben will, sicherlich schon
andere Datenbankanwendungen betreibt, sonst hätte das DWH keine Rohdaten.
➢ Feststellung der Datenquellen nach Lokation, Rechnertyp, Betreiber der
Datenquellen
Es muss nicht an jedem Ort der Welt, an dem das Unternehmen tätig ist, der
gesamte Umfang der DWH-Daten zur Verfügung stehen. Für die einge-
schränkte Sicht auf das DWH hat man die Möglichkeit, Ausschnitte aus dem
Gesamtvolumen herauszugreifen und lokal zu verteilen. So genügt es zum Bei-
spiel einer amerikanischen Niederlassung, einen DWH-Ausschnitt der amerika-
nischen Daten lokal vorzuhalten. Damit ist die Verteilbarkeit eines DWH auf
verschiedene lokationsnahe Server angesprochen. Die Gestaltungsentschei-
dung des DWH-Spezialisten besteht damit in der Platzierung der DWH-Server
im komplexen Netz des Unternehmens und in den Verbindungen zur Daten
liefernden Außenwelt.
➢ Bestimmung der Anwender mit Hilfe der Systemverzeichnisse mit
Lokation, vorhandene Netze
➢ Berechnen der Datenflüsse
➢ Festlegen der Serverlokationen
➢ Information einholen zur Feststellung der Netzprovider durch Netzplaner
➢ Erstellung eines Netz-Schaubildes
Der Wandel der Anforderungen bringt eine weitere Gestaltungsaufgabe mit
sich: die Einschätzung der Zukunft bezüglich steigender Belastungen der
Netze. Dies kann durch umfangreichere Applikationen oder durch vergrößerte
Benutzerzahlen kommen. Der DWH-Spezialist muss also seine DWH-Anforde-
rungen so formulieren, dass die Netzplaner bei der Auswahl und Konfiguration
ihrer Komponenten Skalierungsmöglichkeiten berücksichtigen können.
240 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
Die kursiven Schritte sind nicht vom DWH-Spezialisten, sondern vom Netz-
werkspezialisten auszuführen.
Netzschema
Das Ergebnis der Gestaltungstätigkeit sollte ein mit der Unterstützung der
Hardware- und Netzspezialisten gefertigtes Netzschema der vom DWH betrof-
fenen Komponenten sein. Die Unterstützung ist hierbei bezüglich Symbolik
und Nomenklatur und Werkzeuge zur Darstellung zu erwarten. Das Netzschau-
bild ist für die Schulung der DWH-Anwender äußerst nützlich. Das Verständnis
des Gesamtsystems erleichtert dem Anwender die Orientierung und die Kom-
munikation mit dem Servicepersonal.
Skalierungsschema
Kein DWH-Spezialist kann exakt voraussagen, wie groß der DWH-Server sein
muss, um den augenblicklichen Anforderungen an Kapazität und Performance
zu genügen. Erfahrungsgemäß steigt die Nachfrage kurz nach der Einfüh-
rungsphase mit der Akzeptanz der Pilotanwender und der Intensität des inter-
nen Marketing. Ist das DWH eine Weile in Betrieb, werden erst die Nützlichkeit
und die vielen Verwendungsmöglichkeiten erkannt, und die wachsende Anwen-
dergemeinde macht den Ausbau des Systems nötig. Zur Bemessung sind dem-
nach nur grobe Schätzungen möglich über
✔ augenblickliche Anwenderzahl
✔ Wachstumserkenntnisse zur Anwenderzahl aus der Vergangenheit bei
Einführung neuer Anwendungen
✔ augenblickliche Datennachfrage durch das Netz
✔ Wachstumserkenntnisse zur Datennachfrage aus der Vergangenheit bei
Einführung neuer Anwendungen
✔ Zuwachsraten des Datenverkehrs über das Netz aus den Geschäftsabsichten
des Unternehmens, z.B. neue Niederlassungen zu gründen, alte Niederlas-
sungen auszubauen
Diese sind jedoch sehr nützlich. Auf alle Fälle muss eine Skalierungsplanung
Netz mit Hilfe eines Skalierungsschemas erstellt werden.
242 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
Lokation Lokation
Applikation Benutzer Datenquelle Anwenderzahl Datenvolumen Zugriffsfrequenz
Applikation x 1
2
3
4
Applikation y 1
2
3
4
Applikation z 1
2
3
Applikation 1
2
3
Applikation 1
2
3
Applikation 1
2
3
Datenflussmatrix
Für die Erfassung der Leitungslasten ist die sogenannte Datenflussmatrix
nützlich. In der Datenflussmatrix werden die Quellen und Ziele des Datenflus-
ses, die Lokationen, mit den wesentlichen Datenarten, Mengen und speziellen
Qualitäten zu Sicherheit, Verfügbarkeit und Performance dargestellt.
Es muss darauf geachtet werden, dass die Anforderungen nicht notwendiger-
weise symmetrisch sind. D.h. der Datenfluss zwischen zwei Lokationen kann in
beiden Richtungen unterschiedliche Mengen und unterschiedliche Qualitäten
haben.
Senke
Lokation 1 nach 2
Datenmenge
Lokation 1 Sicherheit
Antwortzeit
Verfügbarkeit
Lokation 2 nach 1
Datenmenge
Lokation 2 Sicherheit
Antwortzeit
Verfügbarkeit
Lokation 3 nach 1
Datenmenge
Lokation 3
Sicherheit
Antwortzeit
Verfügbarkeit
Lokation 4 nach 1
Datenmenge
Lokation 4
Sicherheit
Antwortzeit
Verfügbarkeit
Providercheckliste
Der Netzspezialist wird entscheiden, ob die aktiven Komponenten zusammen
mit den Leitungen gemietet oder getrennt beschafft werden. Der Netzspezialist
wird auch die Provider-Auswahl auf einem Preis-Leistungsvergleich basierend
auswählen und die Leitungen bestellen. Der DWH-Spezialist hingegen ist für
die Terminanforderung, also die Angabe des Zeitpunkts der Leitungsverfügbar-
keit, verantwortlich.
Die Providerauswahl kann mit dem in Kapitel 9 »Produktevaluation« darge-
stellten Evaluationsverfahren durchgeführt werden. Das dort für Softwarekom-
ponenten dreistufig empfohlene Auswahlverfahren kann hier auf zwei Stufen
reduziert werden.
Für die Vertiefung des Themas »WAN« sei empfohlen:
Tanenbaum, Computernetzwerke
Badach, Unternehmensnetze
Siegmund, Netze
Definition
Ein Local Area Network, kurz LAN, ist die hauseigene oder lokal Gebäude
verbindende Kommunikationsverbindung samt ihrer Hardwaretechnologie,
Verbindungskomponenten einschließlich Softwarefunktionen.
Ein LAN ist aufgebaut aus einer Verkabelung bzw. einer Sendestrecke für elek-
tromagnetische Wellen oder auch Infrarot-Strahlung und Komponenten, die
einzelne LANs und das WAN miteinander verbinden. Auf die Komponenten wird
weiter unten eingegangen. Die Schnittstellen der Endgeräte wie z.B. Modems
für den Anschluss an die Telefonleitung, werden üblicherweise nicht mehr zum
LAN sondern zum Endgerät gezählt.
244 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
Ebenso wie bei WANs gibt es auch bei LANs unterschiedliche logische Verarbei-
tungen und daraus resultierende Verarbeitungstechnolgien bezüglich Software
und Hardware. Verschiedenen LAN-Arten aus logischer Sicht sind
✔ Ethernet
✔ Token Ring
✔ ISDN-Hausnetz
✔ GSM
✔ Telefonhausnetz
✔ Fernsehkabelnetz
✔ ATM
Die verschiedenen Übertragungsmedien oder Leitungsarten der LANs aus
physischer Sicht sind
✔ Funk wie Richtfunk, Satellitenfunk
✔ Infrarotstrahlen
✔ Glasfaserkabel
✔ Telefonkabel
✔ Fernsehkabel
✔ Ultraschall
✔ Lichtwellenleiter
Komponenten des LAN und Protokolle
Die Verbindung einzelner LANs und die Verbindung von LANs mit WANs wird
über spezielle Komponenten hergestellt. Mittels sogenannter LAN-Komponen-
ten werden verschiedene LANs miteinander verbunden oder große LANs in
kleinere LANs segmentiert. Um diese unterschiedlich beschaffenen LANs ver-
binden zu können, müssen diese Komponenten »Intelligenz« in Form von Pro-
zessoren und die darauf ausführbaren Programme besitzen.
Die Arbeitsweise der LAN-Komponenten kann man besser verstehen, wenn man
das Protokoll-Prinzip kennt. Im Laufe der letzten Jahrzehnte haben sich die
Hersteller bemüht, unter der Überschrift »Offene Systeme« ihre unterschiedli-
chen Produkte so auszustatten, dass sie zu komplexen Systemen verschiedener
Hersteller kombiniert werden können. Hierzu muss das eine System von sei-
nem Nachbarsystem so viel verstehen, dass es seine Daten aufnehmen, weiter-
verarbeiten und zurückzugeben kann. Das heißt, die Hersteller mussten Details
ihrer Datenverarbeitung und Konstruktionsprinzipien offenlegen, und es muss-
ten Vereinbarungen getroffen werden, die beim Bau der herstellereigenen Sys-
teme zukünftig einzuhalten sind. Diese Vereinbarungen sind in sogenannten
Standardisierungsspezifikationen festgelegt worden. Das Zusammenpassen der
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 245
' )
( ' -#- ,
)* +
% -
'
!"#!$
,-
.
-
&
(
%, "!
'
28
6 :
$!#$
7
.
(& !0 1
8
88
, !
!0 1
- % & 8
9 -
! % 8 87 % &
9 87 %
- 8
!0
- -%
!0 % * ) )
./
! %
./
-, 23
4 )5 3)4 )6
Das Durchlaufen der Information durch die verschiedenen Geräte und Kabel
erfordert mehrere Transformationen und Konvertierungen, entsprechend der
Datendarstellung und der physikalischen Zustände in diesen verschiedenen
Medien. Im Glasfaserkabel sind z.B. die Daten als Lichtimpulse dargestellt, im
Hauptspeicher eines Rechners als Transistorzustände, auf einer Richtfunkstre-
cke sind es elektromagnetische Wellen und im Kupferkabel Stromimpulse.
Aber auch in den Programmen und im Betriebssystem sind intern und vom
Benutzer nicht bemerkbar unterschiedliche Datendarstellungen vorhanden.
Auf einer 3,5-Zoll-Diskette sind die Daten in einer anderen Struktur als auf
einer CD abgelegt. Die unterschiedlichen Datenbanken organisieren ihre Daten
in verschiedenen Strukturen. Wenn man nun eine Information auf den Weg
durch diese Systeme schickt, muss man den Informationen diese Strukturin-
246 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
#
#
$
$
%
%
&
&
'
'
"
"
!
!
!
"
✔ Router übertragen auf den drei untersten Ebenen der OSI-Schichten, auf
der Vermittlungsschicht, der Sicherungsschicht und der Bitübertragungs-
schicht.
✔ Gateways übertragen auf den obersten Ebenen der OSI-Schichten, auf der
Applikationsebene, der Vermittlungs-, der Sicherungs- und auf der Bitüber-
tragungsschicht.
Die folgende Abbildung gibt einen Eindruck von verschiedenen Bauformen und
Größen von Routern.
Neben den aktiven und passiven Netzkomponenten für das Packen und Entpa-
cken der Protokolle gibt es Komponenten für andere Aufgaben, wie physikali-
sches Verbinden verschiedener Medien, das Aufteilen einer Verbindung zwi-
schen verschiedenen Geräten oder das direkte Anbinden eines Gerätes an ein
Netz:
✔ Multiplexer sind für die Mehrfachnutzung von Leitungen durch verschie-
dene Geräte unterschiedlichen Typs, z.B. Video – PC, oder gleiche Geräte.
✔ Medienkonverter sind z.B. für die Anbindung von Lichtwellenleitern an
Kupferkabel.
✔ Modems sind für den Anschluss eines PCs oder Notebooks an ein Telefon-
netz.
Die folgende Grafik gibt ein Beispiel dafür, wie die Netzkomponenten in ein
Netz integriert sind. Dabei symbolisieren die Zylinder mit den vier Pfeilen Rou-
248 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
ter und die Kästen mit kreuzenden Linien symbolisieren Switches. Die folgende
Abbildung 5.7 stellt einen Switchpanel dar. Der Switchpanel ist ein zentrales
Element eines strukturierten Lan. Er besteht aus mehreren Switches und Ste-
ckerleisten uber die die LAN-Teilnehmer miteinander verbunden werden.
LAN-Server
Je nach Auffassung betrachtet man manchmal auch die sogenannten LAN-Ser-
ver noch als Netzkomponenten. Die LAN-Server haben die Aufgabe, den Betrieb
des LANs zu steuern, ähnlich wie das Betriebssystem eines Arbeitsplatz-PCs das
Betreiben dieses PCs ermöglicht. Hierzu gehört zum Beispiel die Verwaltung
von gemeinsamen Dateien, die Verwaltung der Drucker, die für alle zugänglich
sein sollen, kurz alle Ressourcen, die eben allen LAN-Mitgliedern zur Verfü-
gung stehen sollen.
Ebenso darf man auch spezielle, vielen Benutzern zur Verfügung stehende End-
geräte wie LAN-Drucker und Plotter noch zum LAN zählen.
Der LAN-Begriff im erweiterten Sinne umfasst noch alle Endgeräte, also auch
die Arbeitsplatz-PCs. Eine deutliche Grenze wird hier erst zu den mobilen Gerä-
ten gezogen, die als nicht mehr zum LAN zugehörig zählen. Den Endgeräten
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 249
!$%
"
!
()* &
! !
! )%
$
#
$
$
"## "##
&'
!
!
%&
Die kursiven Schritte sind nicht vom DWH-Spezialisten, sondern vom Netz-
werkspezialisten auszuführen.
DWH-Referenznetzschema
Neben der Lokation soll der DWH-Spezialist in der Netzgrafik die Rechnervor-
aussetzungen wie Rechnertyp und Betriebssystem, angeben, da diese für die
Fähigkeiten des LAN wichtig sind. Für die externen Informationsquellen die ja
über das WAN erreicht werden, ist das Betriebssystem und der Zielrechner
unerheblich. Die Zugängigkeit wird vom Provider sichergestellt. Die Bestim-
mung der Rechner wird im folgenden Kapitel behandelt.
Das Hausnetz großer Unternehmen ist in mehrere LANs unterteilt. Oftmals
sind diese LANs dem zentralen Rechner des jeweiligen LANs entsprechend ver-
schieden, so dass mehrere LAN-Arten miteinander gekoppelt werden müssen.
Die Bearbeitung der Netzproblematik durch den DWH-Manager beginnt mit dem
Formulieren der Informationswege vom DWH-Benutzer zu den Servern der Roh-
daten bzw. den ursprünglichen Informationsquellen. Die Platzierung der DWH-
Server ist zu diesem Zeitpunkt noch völlig offen. Hierfür ist ein Schema mit Fel-
dern, in die Angaben zu LANs, Server und Arbeitsplatzrechner mit Lokation, Typ,
Anzahl eingetragen werden können, dienlich. Dies ist ein DWH-Referenznetz-
schema mit allen möglichen, für die DWH-Gestaltungsentscheidung zu beach-
tenden LANs ohne die passiven und aktiven Netzkomponenten wie z.B. Router,
Switches, Hubs. Mitunter ist es nützlich, Angaben zu WANs einzubeziehen.
Die Manager des Corporate Network oder die Netzwerkplaner machen aus die-
sem Referenzschema mittels Grafikprogrammen mit speziellen Symbolebiblio-
theken ein professionelles Netzschema mit vorgefertigten und fest definierten
Symbolen für alle Komponenten, identifizierenden Kennzeichnungen und
Kapazitätsangaben.
Aus der genannten Profizeichnung kann der DWH-Spezialist ein anschauliche-
res, von den für den DWH-Benutzer unwesentlichen Details befreites Bild,
zeichnen. Unwesentlich für den DWH-Benutzer sind z.B. Angaben zur Koppe-
lung oder technischen Ausführung der WAN und LAN.
252 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
!
)
" &" /0 # )
# '(# 11
# % #
# $
$
*+#, 2 #
- -
(
( .
/0.
#
!" " 11
(
3/34
#
$
)##( .,)
70# '& ') ')
+634 50# 20#
11
11
*++6
$ ! -
%
&
Checkliste Server-Allokation
Die Platzierung oder Allokation der DWH-Server hängt von den Verfügbar-
keitsanforderungen und von den Wartungsaufgaben ab. Je näher der DWH-Ser-
ver beim Anwender ist, umso höher ist die Verfügbarkeit und umso besser ist
die Performance. Die Verfügbarkeit ist höher, da weniger Zwischenkomponen-
ten und Leitungen ausfallen können. Die Performance ist besser, weil weniger
Verarbeitungsschritte zwischen dem Anwender und dem Server liegen.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 253
Die Verfügbarkeit hängt auch von der Pflege der Geräte ab. Das bedeutet, je
näher der Service angesiedelt ist, umso schneller ist die Reaktion auf Betriebs-
probleme möglich. Zentraler Service ist kostengünstiger, da die Ressourcen
besser verteilt werden können. Wenn allerdings ein zentraler Service lokal ein-
gesetzt werden muss, dann sind Reisezeit und Reisekosten zu teuer.
Die Data Warehouse Anwender sind in der Regel international verteilt, so dass
es aus Sicht der Servernähe immer entfernte und damit benachteiligte Teilneh-
mer gibt. Für diese muss dann eine Ausfalllösung geschaffen werden. Die Allo-
kation des oder der DWH-Server ist ein Optimierungsproblem. Das heißt, es
gibt keine eindeutige Lösung. Das wichtigere Kriterium ist allerdings das Per-
sonalproblem. Wichtige Fragen hierzu sind:
✔ Bietet der lokale Arbeitsmarkt ausreichend qualifiziertes Personal?
✔ Ist dessen Verfügbarkeit und Zuverlässigkeit gewährleistet?
✔ Ist das Gehaltsniveau vertretbar?
✔ Sind eventuell Versetzungen und Versendungen von Zentralpersonal mög-
lich?
✔ Sind lokale Servicepartner zu engagieren?
Die Kriterien für die lokale Zuordnung, die Allokation, sind in der folgenden
Checkliste Server-Allokation zusammengefasst.
Servicebereitschaft Software
Qualifikation Partner
Zuverlässigkeit Personal
Verfügbarkeit
Sicherheit
Mobilität
5.2.1 Rechnertypen
Es gibt keine Lösung, die für alle Applikationen gleich gut und besser als
andere Lösungen ist. Für jede Applikation ist eine andere Rechnerkonfiguration
optimal. Die Optimalität ist die preiswerteste Alternative bei vorgegebenen
Leistungsmindestgrenzen. Die Rechnerentscheidung erfordert bereits so viel
Fachwissen, dass die Kompetenz des DWH-Spezialisten überfordert ist. Die Lei-
tung des Rechenzentrums wird die Entscheidungen anhand einer Charakteris-
tik der Rechnertypen und der Standards des Unternehmens treffen:
✔ nach Betriebssystem, um die Lauffähigkeit der clientseitigen Softwaremo-
dule und die Programmierbarkeit zu beurteilen
✔ nach wesentlichen Leistungsdaten, wie Massenspeicherplatz, Hauptspei-
cherplatz, Taktrate und parallel einsetzbaren Prozessoren, um die Erfüllung
der Anforderungen der Software nach Performance und Kapazität zu beur-
teilen
✔ nach Display-Auflösung zur Beurteilung der Lesbarkeit von großen Reports
und Farbigkeit für die Interpretation von Grafiken
✔ nach Mobilität zur Beurteilung von Gewicht, Größe, Transportierbarkeit im
Flugzeug
✔ nach Netzanbindungsfähigkeit bzw Replikationsfähigkeit zum Datenaus-
tausch mit dem DWH-Server.
Im Folgenden wird bezüglich dieser Kriterien kurz auf die einzelnen Rechner-
typen und ihre unterschiedliche Funktionalität eingegangen.
Taschenrechner, Kalkulatoren, Organizer
Taschenrechner, Kalkulatoren und Organizer sind für einen einzelnen, priva-
ten Anwender für die Einzelkalkulation, einfache Programmroutinen, Verwal-
tung kleiner Dateien und die Adressverwaltung konzipiert. So lassen sich zum
Beispiel auch DWH-Programme realisieren, wie das in Kapitel 7 »Vorgehens-
modell« dargestellte ROI-Schema von Dupont. Diese kleinen Programme kön-
nen auch Matrizenberechnungen ausführen, Businessgrafiken wie Balkendia-
gramme und Verlaufskurven anzeigen und sogar kleine Dateien verarbeiten.
Die Darstellung ist aufgrund zu kleiner Displays unübersichtlich, wird aber in
Zukunft in Bezug auf Lichtstärke, Kontrast und Auflösung erheblich besser
werden. Organizer sind für den Datenaustausch mit PCs vorbereitet, können
über ein Netz mit Hilfe eines Modems Daten versenden und sogar Terminals
emulieren. Für DWH ist allerdings die Anzeige zu klein und die Funktionalität
zu gering. Diese Rechnerkategorie wird deshalb nicht einbezogen. Trotzdem
sollte man die kontinuierlich wachsende Funktionalität im Auge behalten.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 255
Beispiel: PC-Racks
Im folgenden Beispiel sind im linken Rack 13 Einschübe mit je vier Pentium
CPUs und einem Server-Einschub mit acht Pentium CPUs möglich. Das
mittlere Rack umfasst neben einem Monitor und einem RAID-System neun
Einschübe für vier CPU-PCs. Das rechte Rack enthält acht Steckplätze für
Einschübe mit vier CPUs und Plätze für ein RAID-System und für eine
Stromausfallversorgungseinheit USV und einen Monitor.
Zur Orientierung bezüglich der Größe der Geräte in der Abbildung: Die
Breite eines Gerätes ist ca. 60 cm, die Höhe ca. 2 m. Die lauffähigen Betriebs-
systeme sind NT, UNIX, DEC-VMS.
Mikrorechner, Minirechner
Die nächstgrößere Kategorie bilden die Mikrorechner mit einer Belastungs-
tragfähigkeit von etwa 100 Anwendern. Minirechner sind leistungsfähiger als
Mikrorechner und haben eine Belastungstragfähigkeit von etwa 1.000 Usern.
Die ehemals deutliche Grenze zwischen Minirechner und Mikrorechner ist de
facto verschwunden. Minirechner werden teilweise mit proprietären Betriebs-
systemen geführt und teilweise mit firmenspezifischen UNIX-Derivaten. Mit
»firmenspezifisch« ist hierbei gemeint, nicht ganz so proprietär aber doch mit
firmenspezifischen Eigenheiten, was die Firmen auch in der Bezeichnung aus-
drücken:
✔ DEC ULTRIX
✔ HP HP-UX
✔ IBM AIX
Bei besonderen Anforderungen an Rechenleistung, Schnelligkeit des Speicher-
zugriffes und simultane Verarbeitung großer Datenmengen wird der parallele
Einsatz mehrerer Prozessoren interessant. Dies ist besonders im Bereich der
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 259
Zur Orientierung bezüglich der Größe der Geräte in der Abbildung sei die
Höhe eines Gerätes mit ca. 150 cm genannt.
Supercomputer
Supercomputer sind die leistungsfähigsten Rechner. Supercomputer sind fest
installiert und in der Mobilitätsskala das unbeweglichste aller Computersys-
teme. Sie sind mehr als alle anderen Systeme an klimatisierte, staubfreie Räume
gebunden. Supercomputer werden mit einem proprietären Betriebssystem
geführt. Für Supercomputer sind keine DWH-Komponenten entwickelt worden.
Beispiel Supercomputer
Als Beispiel für einen sehr jungen Supercomputer soll die T3E-1200E von
Cray Research dienen. Die 1200E ist ein massiv paralleler Rechner mit bis zu
2048 Prozessoren, die je eine Taktrate von 600 MHz haben. Ein Engpass ist
der Datentransfer zwischen den Prozessoren. Bei der 1200E erledigt das ein
Router-Chip mit 42 Gbit/s. Der Preis für ein 1200E Rechnersystem liegt in
der Größenordnung von 20 Mio. DM.
Seit einigen Jahren werden zu den Supercomputern nicht mehr nur die in
einem zusammenhängenden Gehäuse eingebauten Rechnergebilde gezählt. Es
werden auch die Rechnerverbunde als Supercomputer angesehen, wie das wei-
ter vorne erwähnte Rechnercluster.
Chip-Card-Rechner
Der Vollständigkeit zuliebe sei noch ein Blick auf einen neueren Rechnertyp
geworfen, dessen Bedeutung mangels geeigneter Software für DWH derzeit
noch nicht groß ist, in Zukunft aber steigen wird.
Mittlerweile sind Chip-Card-Rechner, Rechner von der Größe einer Scheck-
karte, erhältlich. Diese benötigen allerdings ein zusätzliches Eingabegerät und
haben dann doch wieder die Größe eines Palmtops. Einen kompletten Rechner
in Größe einer PCMCIA-Karte gibt es derzeit noch nicht: Zur Bedienung sind
ebenfalls wie bei der Chip-Card noch externe Einheiten erforderlich, wie Tasta-
tur, Mikrofon, PC. So ist es auch nur möglich, einzelne und kurze Datensätze
anzuzeigen, wie Adressen und Kurznotizen, was für DWH-Funktionen nicht
ausreicht.
Bedeutung für DWH-Anwendungen:
➡ Chip-Card-Rechner werden aus Kostengründen nicht für DWH eingesetzt.
Fuzzy-Logic-System, Künstliche Neuronale Netze
Immer häufiger ist von Fuzzy-Logic-Systemen und Künstlichen Neuronalen
Netzen, kurz KNN, die Rede. Ob hierzu Rechnertypen auf dem großen Markt
der Datenbankanwendungen platziert werden, bleibt noch abzusehen. Es gibt
Prototypen, die eher für Erfahrungszwecke eingesetzt werden. Die Konzepte
des Rechnens mit Fuzzy-Sets wie auch mit Prinzipien der Neuronalen Netze
werden derzeit in Rechnern mittels Programmen simuliert. Über die Nützlich-
keit gibt es noch zu wenige überzeugende Erfahrungsberichte von Anwendern,
um sie in die Rechnerauswahl miteinzubeziehen. In der Softwareauswahl sind
sie als funktionale Module interessant.
Bedeutung für DWH-Anwendungen:
➡ Fuzzy-Logic-System und Künstliche Neuronale Netze (KNN) sind für DWH-
Analysen nicht tauglich, sie sind noch viel zu teuer und serverseitig und
clientseitig noch ohne komfortable DWH-Softwareausstattung.
Prozessrechner
Prozessrechner sind nicht für die Langzeitspeicherung von Daten konzipiert
und damit auch nicht für Datenbankanwendungen. Ihre Aufgabe ist die zeitver-
lustfreie Steuerung oder auch Echtzeit-Steuerung von Produktionsprozessen.
Bedeutung für DWH-Anwendungen:
➡ Prozessrechner sind für DWH-Anwendungen ungeeignet, zu teuer und
ohne entsprechende Standardsoftware.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 263
Datenbankmaschine
Nicht unerwähnt bleiben soll ein Rechnertyp, der speziell für die Verarbeitung
von Datenbankfunktionen konzipiert und auch in Einzelexemplaren gebaut
wurde, die Datenbankmaschine. Das Problem hierbei ist die Verfügbarkeit von
Anwendungen und das sehr tiefgehende und daher sporadisch verfügbare Spe-
zialwissen über Administration und Programmierung. Für Datenbankmaschi-
nen sind keine DWH-Komponenten entwickelt worden. Es sind außerdem welt-
weit Datenbankmaschinen eher in Forschungslabors als in Herstellerkatalogen
zu finden. Trotzdem wäre ein extra für die strukturierte Datenhaltung speziali-
sierter Rechnertyp mit entsprechend ergonomischer Datenbanksoftware sehr
nützlich und äußerst performant.
Bedeutung für DWH-Anwendungen:
➡ Datenbankmaschinen können derzeit aus Kostengründen nicht für DWH
eingesetzt werden.
Net-Computer
Auf der Client-Seite hat sich vor einiger Zeit mit großem Wirbel ein neues Kon-
zept mit einer geringen Auswahl von Produkten (soft wie hard) namens Net-
Computer (auch Network-Computer) bemerkbar gemacht. Der Net-Computer,
der oft der Produktgruppe intelligentes Terminal zugeordnet wird, ist ein End-
gerät ohne eigene Mengen-Datenhaltung, aber mit Prozessor und Hauptspei-
cher. Alle Programme laufen auf dem Netserver bis auf die Präsentation der
Programmelemente, die mittels dem auf dem Net-Computer installierten
Browser betrieben werden. Da die Net-Computer keinen deutlichen Preisvorteil
brachten, haben sie sich nicht durchsetzen können. Die über NC betreibbare
Programmvielfalt ist gering, und das Betreiben eines EXCEL-Sheet auf einem
entfernten Server bereitete z.B. der Anwenderschar Unbehagen. Für das Betrei-
ben von DWH-Frontends ist der Net-Computer ungeeignet, wenn die Daten
lokal weiterverwendet werden sollen.
Bedeutung für DWH-Anwendungen:
➡ Net-Computer werden nicht für DWH eingesetzt, da bisher zu wenig Soft-
ware am Markt vorhanden ist und die flexiblen Client-Berechnungen auf-
grund mangelnder Prozessor-Intelligenz auf den NC-Server ausgelagert
werden müssten. Mobiles Rechnen ist damit gar nicht möglich.
Virtuelles Computer-Netz
Aus der Gruppe der Rechnerverbunde kommt ebenfalls ein neues Konzept, das
weltweit verteilte Computer bei Bedarf für eine bestimmte Aufgabe zu einem
großen temporären virtuellen Computer-Netz koordiniert. Die Rechnerleistung
steht nach der Einbindung in den Verbund wie in einem Multiprozessorsystem
oder einem Parallelrechner zur Verfügung. Die Koordination der verschiedenen
Rechner, das ist zuerst die Aufgabenverteilung, wird bis zur Lösung dieser Auf-
gabe aufrechterhalten und danach aufgelöst und abgemeldet. Die einzelnen
264 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
Rechner stehen dann einem anderen virtuellen Netz zur Verfügung. Für die
Koordination ist ein neues Betriebssystem erforderlich. Ein Betriebssystem, das
diese Koordination leisten soll, ist bei der Firma Sun derzeit im Entwurfssta-
dium. Es ist offensichtlich, dass die Kommunikationszeit zwischen diesen
Rechnern der eigentliche Leistungsengpass ist.
Bedeutung für DWH-Anwendungen:
➡ Virtuelle Computer-Netze sind noch im Anfangsstadium ihrer Entwicklung
und können daher nur mit Risiko und unter großem Aufwand für DWH ein-
gesetzt werden.
5.2.2 Aufrüstung
Neben der einmal getroffenen Gestaltungsentscheidung ist im Laufe der
Betriebszeit die Anpassung an aktuelle Bedarfe erforderlich. Den größten Ein-
fluss auf die Veränderung haben technologische Neuerungen und veränderte
Leistungsanforderungen. Für die Hardwareausstattung bedeutet dies zweierlei:
Erstens muss die Gestaltungsentscheidung die spätere Anpassbarkeit berück-
sichtigen und zweitens ist die Anpassung bei Bedarf zu gestalten. Ein Beispiel
für die Aufrüstungsmöglichkeiten eines PCs sei hier stellvertretend für die Pro-
blematik angeführt:
✔ Prozessor-Overdrive zur Steigerung der Taktrate und Ergänzung mit
zusätzlichen Leistungen
✔ Einbau von stärkeren Grafikkarten oder Erweiterung des Grafikspeichers
✔ Einbau von Video-Tunerkarten
✔ Austausch von alten CD-ROM-Laufwerken gegen schnellere CD-ROM-Lauf-
werke oder DVD-Laufwerke
✔ Aufrüstung des Hauptspeichers mit zusätzlichen Speicher-Chips.
Die folgende Tabelle zeigt in Grundzügen die Entscheidungssituation und die
daraus resultierende Aufrüstungsstrategie nach einem Katalog der Firma Digi-
tal Equipment Corporation (DEC).
Die Aufrüstung von Großrechnern und Minirechnern kann z.B. durch soge-
nannte Board-Upgrades
✔ Bestückung der Hauptplatine mit weiteren Prozessoren
✔ Zusätzliche Platinen
✔ Austausch der alten Platinen gegen Platinen mit Vektorprozessoren
oder durch
✔ Cabinet Austausch
✔ Clusterbildung mehrerer Rechner
✔ Applikationsauslagerung an weitere Rechner
erfolgen.
Die folgende Grafik der Aufrüstungspfade eines etwas älteren Modelles von
DEC, die VAX 6000/200 soll die Vielfältigkeit der Skalierung belegen.
5.2.3 Rechnerauswahl
Problemstellung und Motivation
Bezüglich der Hardware liegt der Sachverhalt der Entscheidungskompetenz
gänzlich anders als bei Gestaltungsentscheidungen zur Software. Das Ziel der
Softwarebestimmung bestand aus der Make-or-Buy-Entscheidung, auf der Basis
der Spezifizierung der Anforderungen und aus einer Eigenentwicklung von
nicht erwerblichen Softwarekomponenten. Das Ziel der Rechnerbestimmung
besteht nicht darin, einen Rechner zu entwerfen und zu bauen und all seine
aufwändigen Entwicklungsschritte zu durchlaufen, sondern darin, den optima-
len Rechner zu beschaffen. Die Aufmerksamkeit liegt auf der Evaluation des
Marktangebots im Unterschied zu den bereits besprochenen, zu konfigurieren-
den Softwareteilen. Software, die dem gewünschten Leistungsumfang nicht
entspricht, muss selbst entwickelt werden. Im Gegensatz dazu kann eine Rech-
nerkonfiguration nur aus dem Marktangebot zusammengestellt werden.
Es stellt sich die Frage, welche Rechnerkonfiguration optimal für das
gewünschte DWH ist. Das erste Problem einer Rechnerkonfiguration ist, dass
eigentlich der Hersteller der Software wissen müsste, welche Rechnerleistung
für den Betrieb seiner Software erforderlich ist, diese aber nicht öffentlich
bekannt gibt. Schließlich hat er ja bereits bei der Programmierung und
anschließenden Tests entsprechende Erfahrungen gesammelt. Aber da er Haf-
tungsansprüche bei falschen Ratschlägen fürchtet, gibt er keine verbindlichen
Auskünfte oder macht nur sehr vage Andeutungen. Einige Hardwarehersteller
helfen dem Anwender durch eine umfangreiche, strukturierte Befragung, die
sie in einer eigenen Erfahrungsdatenbank auswerten lassen. Bei IBM ist ein sol-
cher Fragenkatalog für die Konfiguration eines SAP-Servers z.B. ca 30 DIN-A-
4-Seiten lang. Viele Fragen dieses Kataloges sind nicht aus dem Stegreif zu
beantworten und erfordern viel Aufwand für die Bearbeitung. Deswegen und
wegen der kontinuierlich wachsenden Anforderung ist der sicherste Weg der
Weg der Skalierung des Systems. Man fängt klein, aber ausbaubar an und ska-
liert den Erfahrungen entsprechend.
Rechnertypenübersicht
Das zu lösende Problem heißt: Für welchen Arbeitsplatz und für welche Server-
Dienste ist welche Rechnerkonfiguration optimal? Der DWH-Spezialist wird die
Rechnerauswahl nicht alleine treffen. Er benötigt lediglich für die Wahrung sei-
nes Überblicks eine grobe Charakteristik der Rechnertypen mit
✔ Betriebssystem, um die Lauffähigkeit der clientseitigen Softwaremodule
und die Programmierbarkeit zu beurteilen
✔ wesentlichen Leistungsdaten wie Massenspeicherplatz, Hauptspeicherplatz,
Taktrate, um die Erfüllung der Anforderungen der Software nach Perfor-
mance und Kapazität zu beurteilen
✔ Display-Auflösung zur Beurteilung der Lesbarkeit von großen Reports und
Farbigkeit für die Interpretation von Grafiken
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 269
Prozessorfestlegung
Statt die Auswahl bei einem Rechnersystem oder einer Bauart zu starten, kann
man auch zunächst den Prozessortyp festlegen. Die Leistungsfähigkeit von Pro-
zessoren wird regelmäßig gemessen, ihre Entwicklungsfähigkeit in der Zukunft
ausgeleuchtet und Empfehlungen veröffentlicht. Für den DWH-Spezialisten ist
interessant, dass das UNIX für RISC-Prozessoren entwickelt wurde und die
Microsoft-Betriebssysteme Windows NT, Windows 95 und Windows 98 für
CISC-Prozessoren. Eine Prozessorentscheidung ist damit großenteils auch eine
Betriebssystementscheidung.
Rechnerevaluation
Stehen mehrere Alternativen zur Wahl, kann das in Kapitel 9 »Produktevalua-
tion« vorgestellte Evaluationsverfahren angewendet werden. Kriterien für die
Beschreibung der Anwendersituation sind damit die Kriterien für die Rechnere-
valuation.
✔ Einzusetzendes Client-Softwareprodukt
✔ Größe der zu bewegenden Datenmengen, Größe der anzuzeigenden Reports
✔ Offlinefähigkeit, also Fähigkeit, unabhängig vom Netz betrieben werden zu
können und Daten nach Bedarf nachzutanken
Skalierung und Wachstum
Die Auslegung der Rechner deckt im ersten Planungsschritt nur die Anforde-
rungen des augenblicklichen Bedarfs ab. Als spezielle DWH-Kriterien für die
Auswahl der DWH-Server-Rechner dienen neben den üblichen, für alle Soft-
waresysteme gültigen Kriterien, zusätzliche Kriterien für die Belastung des
Systems:
✔ Bedarf der Datenmengen
✔ Anzahl der online zugreifenden User
✔ Gewünschte Antwortzeiten
✔ Kompatibilität der Betriebssysteme.
Der Bedarf wandelt sich im Laufe der Zeit, z.B. durch neue Aufgaben des Unter-
nehmens, Veränderungen der Märkte, organisatorische Umstrukturierungen.
Jede dieser Veränderungen hat Auswirkungen auf den Bedarf der Nutzer des
DWH und muss sich in Anpassungen der Konfiguration des DWH niederschla-
gen. Für den DWH-Spezialisten erwächst hieraus die Aufgabe, bereits in der
Konfiguration der Systeme die Flexibilität zu berücksichtigen. Er muss sich als
Prognostiker betätigen und die Zukunft der Bedarfe vorhersagen. Diese
Zukunft umfasst Wachstumsschätzungen der bestehenden Applikationen aus
✔ funktionaler Sicht: Welche Funktionen könnten zukünftig noch benötigt
werden?
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 271
✔ der Sicht der Datenmengen: Wie wird der Umfang der Datenmengen
zukünftig wachsen?
✔ der Sicht der Informationen: Ist zukünftig mit dem Bedarf an neuen Infor-
mationen, Informationsstrukturen, Informationsquellen, Informationsar-
ten zu rechnen?
Über das beste Zusammenspiel von DWH-Software und Rechnerarchitektur
werden die Softwarehersteller bestimmte Empfehlungen abgeben, die nur im
Test bestätigt werden können. Da hierzu nie eine verlässliche Vorausberech-
nung stattfinden kann, ist unbedingt auf die Skalierbarkeit des Rechnersystems
zu achten. Optimieren lässt sich noch der Administrations- und Qualifikations-
aufwand, indem man neben den bestehenden Betriebssystemen keine neuen
einführt.
Eine allgemeine Faustregel zur Bemessung der Server gibt es nicht. Anstelle
einer Faustregel sollen die Praxisbeispiele Anhaltspunkte für die eigene Konfi-
guration liefern. Es folgen einige Beispiele von Rechnerentscheidungen und zu
bewältigenden Datenmengen, die von der Gartner Group bekannt gemacht
wurden.
Die Wahl des richtigen Rechners kann auch aus der Sicht der Betriebssysteme
getroffen werden. Das heißt, zuerst wird das Betriebssystem bestimmt und
dann die Wahl des Rechners getroffen.
Für tiefere Einblicke in Rechnertypen und Rechnerarchitekturen sind interes-
sant:
Hansen, Wirtschaftsinformatik
Tanenbaum, Computerarchitektur
Bei einigen Großrechnern ist auch die Umschaltung des Betriebes von einem
Betriebssystem auf ein zweites Betriebssystem möglich. Damit sind dann
andere Programme betriebsfähig gestellt. Ob dies bei laufendem Betrieb mög-
lich ist, hängt auch von der Anzahl der Prozessoren ab.
Welche der Möglichkeiten auch immer gewählt wird, mit der Auswahl der
Rechner sind die Möglichkeiten der Betriebssystemauswahl eingeschränkt wor-
den. Dies motiviert die Frage, ob nicht zuerst die Entscheidung für ein oder
mehrere Betriebssysteme getroffen werden sollte, um daraus erst die Entschei-
dung für den passenden Rechner abzuleiten. Die hier zu lösende Gestaltungs-
aufgabe hätte demnach die Frage nach dem richtigen Betriebssystem, vor der
Frage nach dem richtigen Rechner stellen können. Für die Fragestellung »Auf-
bau eines DWH« ist allerdings weniger die Funktionalität eines Betriebssystems
maßgebend als vielmehr die Leistungsfähigkeit von Rechnern. Ein leistungs-
schwacher Rechnertyp mit einem guten Betriebsystem ist für den Anwender
aus Performancegründen ineffizient.
Ausgewählte Eigenschaften des Betriebssystems
Alle Betriebssysteme haben eine Mindestausstattung an Funktionen. Diese die-
nen zur Erkennung der Hardware, zur Installation von Software, zur Einstel-
lung von Rechnerverhaltensweisen, zu Speichermanagement und Datensiche-
rung, Ein- und Ausgabesteuerung, Abwicklung der Verarbeitungsprozesse,
Verwaltung der Dateien zu Programmen und Daten, Erteilung von Zugriffsbe-
rechtigungen und Anbindung an externe Rechner- und Rechnernetze. Wesent-
liche Kriterien zur Auswahl sind:
Robustheit Wesentlich für die Verfügbarkeit der Applikationen
und das schnelle Aufspüren von Fehlern ist die
Betriebsstabilität des Betriebssystems, die Robust-
heit. Hierzu gehört die weitestgehende Absturzfrei-
heit, die Einschränkung von Abstürzen auf ein
verursachendes Programm unter Erhaltung des
Betriebes aller anderen Programme (z.B. bei
Windows 95 nicht gegeben) und die Selbstreini-
gung bei Abstürzen von Datei-Fragmenten und
Zuordnungen.
Multitaskingfähigkeit Wenn mehrere Benutzer auf einem Rechner arbei-
ten, dann sollte es auch möglich sein, dies mit ver-
schiedenen Programmen zu erlauben. Der Betrieb
mehrerer Programme zur gleichen Zeit kann auch
für mindestens einen Anwender erlaubt werden. In
beiden Fällen spricht man von Multitaskingfähig-
keit. Wenn die Tasks des Betriebssystems von ver-
schiedenen Benutzern, von verschiedenen Rech-
nern bestellt werden können, spricht man von der
Multiuserfähigkeit eines Betriebssystem. Dies
274 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
enthalten. Aber man kann die Funktionalität erweitern, indem man sogenannte
Utilities installiert. Solche Utilities umfassen z.B.
✔ das Dateimanagement mit Suchen verlorengegangener Dateien, Wiederher-
stellen versehentlich gelöschter Dateien, Löschen nichtgebrauchter Dateif-
ragmente
✔ die Hardwarediagnose mit Aufdecken von physikalischen Fehlern, funktio-
nalen Einschränkungen;
die Leistungsfähigkeit wird am Umfang der unterstützten Hardwarepalette
gemessen
✔ das Systemmanagement mit Monitoring angeschlossener Hardwarekompo-
nenten, Meldung von angesprochenen, aber nicht erreichbaren Komponen-
ten;
die Leistungsfähigkeit wird am Umfang der unterstützten Hard- und Soft-
warekomponenten gemessen
✔ die Datensicherung mit planmäßiger automatischer Auslagerung und
Archivierung oder Replikation
✔ Systemoptimierung, Tuning und Parametereinstellung, Komprimierung
und Dekomprimierung
Die meisten Utilities-Funktionen sind, unabhängig von der eingesetzten Soft-
ware und Hardware, für alle Systeme nützlich. Es gibt allerdings auch Utilities,
die nur auf bestimmte Hardwareprodukte und auf bestimmte Softwareprodukte
wirken. Mit dem Aufbau eines Data Warehouse und der Beschaffung damit ver-
bundener neuer Software- und Hardwareprodukte werden auch weitere Utili-
ties benötigt.
Kriterienliste Betriebssystem
In der folgenden Tabelle sind die Kriterien der Betriebssysteme mit einigen aus-
gewählten charakterisierenden Eigenschaften in der Reihenfolge steigender
Leistungsfähigkeit dargestellt.
Kriterium Charakteristik
Kriteriensynopse Betriebssysteme
Besteht Entscheidungsfreiheit in der Wahl des Betriebssystems,
✔ ist kein Rechner- oder Betriebssystemstandard festgestellt,
✔ sind die bereits getroffenen Entscheidung für bestimmte DWH-Komponen-
ten nicht bindend
✔ und auch das Standardbetriebssystem des Unternehmens nicht zwingend.
Besteht Entscheidungsfreiheit für ein Betriebssystem, werden die oben darge-
stellten Kriterien der Reihe nach analysiert. Ein Unternehmen, das alle Frei-
heitsgrade in der Auswahl offen lässt, benötigt eine Gegenüberstellung der zum
Teil im Konflikt zueinander stehenden Leistungsmerkmale der verschiedenen
Betriebssysteme, eine Kriteriensynopse Betriebssysteme. Eine solche Synopse
ist als Hilfsmittel im Folgenden dargestellt.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 281
g
tät fan
rm ce eit nali um
it g o t rk g ng
e i n s f a n i t ä a i o n s f n
a tu
u sth tius rieb o rm l lel l i er
b
r n at
k tio -Um brei
b l t r f r a a e n r
Typ Ro Mu Be Pe Pa Sk Int Fu SW Ve
Personals
Organizer
W-CE
Pilot
Casio
PDA
W-CE
Psion
Sharp
Arbeitsplatz
PC, Notebook
W95/98
W2000
NT
MacOS
OS/2
NEXT
LINUX
WS
NT
LINUX
UNIX
Server
WS
NT
UNIX
Minirechner
VMS
MPE
UNIX
Großrechner
MVS
MPE
Speicherung, Aufbewahrung
Zur Speicherung von Daten ist so ziemlich alles, was die Natur bietet, von Inte-
resse für die Technologen – vom künstlichen chemischen Molekül zum Biomo-
lekül, von Atomen bis zu Hologrammen und zu Halbleitern. Die Aufzeichnung
einer Videokamera kann z.B. magnetisch auf Videoband, elektrisch in einem
Speicherchip oder optisch auf CD festgehalten werden.
Beispiele für Speichermedien sind in der folgenden Checkliste Speichermedien
aufgeführt.
Ausgabe
Ausgabegeräte sind so vielfältig wie die Sinnesausstattung der Menschen. Kom-
plizierte Strichzeichnungen, wie Konstruktionspläne von Architekten und
Ingenieuren, werden auf Papierrollen von Plottern gezeichnet. Videosequenzen
können mit dem Licht der Beamer oder LCD-Overhead-Aufsatz auf Leinwand
projiziert werden.
Die Möglichkeiten der peripheren Komponenten sind vielfältig und bedürfen
einer sorgfältigen Wahl, die nicht zuletzt auch das Kriterium Kosten berück-
sichtigen muss. Die Auswahl dieser Komponenten ist nicht die Aufgabe des
DWH-Spezialisten, aber eine Gestaltungsaufgabe für einen kompletten DWH-
Arbeitsplatz. Deshalb wird das Thema nur der Vollständigkeit halber, und als
Gelegenheit zur Anregung der Zusammenarbeit der IT-Beschaffer und Nutzer-
services mit dem DWH-Spezialisten, gestreift. Beispiele für Ausgabegeräte sind
in der folgenden Checkliste Ausgabegeräte aufgeführt.
Schnittstellen
Im Rechner selbst findet der Transport der Daten über Adress- und Datenbusse
statt. Der Transport an Außeneinheiten geht über Schnittstellen des Rechners,
Schnittstellen der Außengeräte und ein verbindendes Transportmedium. Bei-
spiele für Schnittstellen sind in der folgenden Checkliste Schnittstellen aufge-
führt.
Einige Peripheriekomponenten sind so teuer, dass sie sich erst bei Benutzung
durch einen größeren Anwenderkreis amortisieren. Es ist also die Entschei-
dung zu treffen, ob mobil oder stationär am Arbeitsplatz, stationär an der Loka-
tion oder entfernt zugegriffen werden muss. Daneben ist zu beachten, daß die
Einsatzorte erhöhte Flexibilität der Ausrüstung der Mitarbeiter eines Unterneh-
mens fordern. Der Arbeitsplatz ist nicht mehr uneingeschränkt als stationär
einzuordnen. Die Frage, ob mobiler oder stationärer Einsatz erforderlich ist, ist
zu beantworten.
➢ Kriterien zur Beurteilung der Lokation und Mobilität der Peripherie
Rechner 2 Typ
stationär stationär stationär stationär
Output
Drucker Typ
mobil mobil/stationär
Fax mobil
Projektor
Lautsprecher
Input
Tableau
Video
Mikrofon
Scanner
Barcodeleser
Speicher
CD-R
PCMCIA
$
(
0
$
#
% '
(
0
&$
&
0
%$
(!!()
"
(!!() 0333 456 "
%$
" %$
+
/!+
! " #
! " # $!% &
$!% & $!% (
&'
$!% $
$!% 75,
&'
!
.,,'.,,
,(-%
Hinblick auf die Standorte der Benutzer, den Personalmarkt und die Nähe der
Implemetierung der Funktionen ausgewählt worden.
Es ist zu unterscheiden, ob eine Softwarekomponente vielen Benutzern oder
nur einem einzigen Benutzer Dienste zur Verfügung stellen muss.
Die Nutzung kann dauerhaft zur Verfügung stehen oder bei Bedarf angefordert
werden. Es gibt Anmeldungszähler zur Lizenzüberwachung, welche die Lizen-
zenüberprüfung nicht auf die Zahl der gemeldeten Benutzer bezieht, sondern
auf die Zahl der gleichzeitig arbeitenden Benutzer. Nutzung von Lizenzen kos-
tet Geld, ebenso kostet ein auf Grund starker Nutzungsannahmen leistungsfä-
hig ausgebauter Rechner mehr Geld als ein leistungsschwach bestückter Rech-
ner. Die bereitgestellte Verfügbarkeit muss daher in vernünftigem Verhältnis
zur Nutzung stehen.
Folgende Nutzungsvarianten sind zu unterscheiden
✔ nach der Nutzungsdauer: kontinuierlich, periodisch, fallweise, spontan
✔ nach dem Nutzungsort: entfernt, am Ort
✔ nach der Zeiteinteilung: alleinberechtigt, gruppenberechtigt,
Zeitfenster-berechtigt
✔ nach dem Besitzverhältnis: gemietete Lizenz, gekaufte Lizenz,
Eigentum
Verteilung
Um die einzelnen Komponenten einer Software gemäß der Anwendernachfrage
besser positionieren zu können, wurde die Client/Server-Architektur entwi-
ckelt. Die Client/Server-Architektur teilt die Programme in einen Teil, der auf
dem Endgerät des Benutzers abläuft und einen Teil, der auf einem allen Usern
zugänglichen Server abläuft. Dies bedeutet eine Entlastung des Servers, da ja
einige Berechnungen oder Programmausführungen vom Server auf das Endge-
rät abgegeben werden können. Es wäre zum Beispiel nicht möglich bzw. nicht
sinnvoll, die grafischen Benutzeroberflächen aller Benutzer auf einem zentra-
len Rechner verarbeiten zu lassen, um das Ergebnis auf einem Terminal anzu-
zeigen. Jede neue Bewegung eines grafischen Elementes, wie z.B. Mausklick auf
einen Button, würde eine erneute entfernte Berechnung erfordern. Neben der
Rechenlast der Server ist deshalb noch die Kommunikationslast der Leitungen
ein Grund, den Datenverkehr zu minimieren, und dies geschieht eben auch
durch die Möglichkeit, die Masken direkt auf dem Endgerät zu erzeugen, anstatt
sie als grafische Präsentation zu versenden. Mit dem Prinzip der Client/Server-
Architektur, Programme in verteilbare Komponenten aufzusplitten, ist dann als
Fortsetzung der Idee der zweistufigen Verteilung noch die Idee zur mehrstufi-
gen Verteilung verwirklicht worden. Die Verteilbarkeit ermöglicht eine auf die
Programmkomponente gezielt ausgerichtete Rechnerkonfiguration.
Ein weiterer Aspekt der Verteilung ist die effiziente Kooperation der DWH-
Komponenten mit Standardprogrammen des Arbeitsplatzrechners. Mit anderen
290 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
Die Softwarekonfiguration des Arbeitsplatzes des DWH ist also die Definition
der Bestückung der Rechner der Benutzer mit einem voll funktionsfähigen
System von zusammenarbeitenden Softwarekomponenten.
freiheit der Verteilung, aber er bringt auch den Zwang mit sich, die Verteilung
bestimmen zu müssen.
➢ Bestimmung der Softwarekomponenten auf Server und Clients
Problemlösung: Regeln und Hilfsmittel
Das Verfahren
Die Methodik zur Ausstattung der Arbeitsplätze ist prinzipiell von der DWH-
Problematik unabhängig, sie ist für alle Software-Allokationen gleichermaßen
einsetzbar. Die Server-Softwarekomponenten des DWH sind selbstverständlich
auf den DWH-Servern zu installieren und damit bereits durch die Aufstellung
der Server alloziert. Dies war durch die Feststellung der Länderaktivitäten des
Unternehmens bereits begründet worden. Damit ist nur die Ausstattung der
Arbeitsplätze zu bestimmen. Die folgende Vorgehensweise ist für die Ermitt-
lung der Software-Allokation zu empfehlen.
Verfahren: Software-Allokation
❖ Feststellung der Lokation der Datenquellen und der Server-Verteilung
mit Hilfe des Netzdiagramms
❖ Bestimmung der Lokation der Anwender
❖ Kriterien zur Beurteilung der Lokationen der Software, (Client oder Ser-
ver, Serverzuordnung)
❖ Kategorisierung der Arbeitsplätze
❖ Bestimmung der Softwareausstattung der Clients
Name Typ
PC, W95 Ort
Sekretariat
!! #
"
'(' #$%&'
Exkurs Client/Server-Architektur
Der Grundgedanke der Client/Server-Architektur ist die Aufspaltung eines
Programmes in zwei oder mehrere Teile, die auf verschiedenen Rechnern,
einem Client-Rechner und einem oder mehreren Server-Rechnern laufen
können. Wie groß diese Teile sind, welchen funktionalen Umfang sie haben,
bleibt dabei den Vorstellungen der Programmierer überlassen. Die Gestal-
tungsfreiheit ist durch die Fähigkeiten der verwendeten Rechner begrenzt.
Durch die Aufteilbarkeit können auch die Fähigkeiten mehrerer Rechner
genutzt werden. In Summe sind bei den C/S-Architekturen die Rechnerfä-
higkeiten variantenreicher konfigurierbar. So kann z.B. die rechenintensive
Verarbeitung grafischer Benutzungsoberflächen auf einen eigens für einen
Benutzer zuständigen Rechner gelegt werden. Ein einzelner Rechner wäre
mit der Grafikverarbeitung aller Benutzer eines Multiuserbetriebes aus-
sichtslos überfordert. Die grafische Oberfläche kann auf einem PC oder
einem X-Terminal ausgeführt werden. Andererseits wäre ein PC damit über-
fordert, eine große Datenbank im Multiuserbetrieb mit angemessenem
Antwortzeitverhalten zu betreiben.
294 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
#$ &'
* , - +
)
*
Für die Platzierung von Programmen haben sich seit der Entwicklung von
Client/Server-Produkten einige Empfehlungen bewährt:
✔ große Datenbanken mit Multiuserzugriff auf einen speziellen, skalierbaren
Server legen
✔ Grafikverarbeitung der Oberfläche auf das Endgerät PC oder X-Terminal
✔ hochspezialisierte Programme mit komplizierten Berechnungen auf einen
weiteren Server
✔ Kommunikationsdienste wie Mails auf einen speziellen Mailserver
✔ Internetseiten auf einen speziellen Web-Server
✔ Archivierung auf einen speziellen Archivierungs-Server
Die Verständigung der Rechner und ihre Kooperation muss über Hilfspro-
gramme gesteuert werden. Das Zusammenspiel zwischen Client- und Server-
programmen basiert auf einem Unterprogramm zum Aufruf entfernter, also
auf anderen Rechnern liegender Programme, dem Remote-Procedure Call,
kurz RPC, wie in der folgenden Grafik dargestellt ist.
Client-Rechner Server-Rechner
Anwend.- Komm.- Komm.- Server- Server-
Client-Stub
Programm Kompon. Kompon. Stub Programm
Prozedur-
aufruf Aufruf-
kodierung Aufruf- Aufruf-
übertragung empfang Aufruf-
dekodierng Prozedur-
aufruf
Warten
Abarbeitg
Ergebnis-
Ergebnis- rückgabe
Ergebnis- Ergebnis- kodierng
Ergebnis- empfang übertragung
Ergebnis- dekodierng
rückgabe
Beispiel
Welche Anforderungen sind nun an eine Hardware für ein Instandhaltungs-
DWH eines Energieversorgers zu stellen, der den im vorangehenden Kapitel
»Softwarekomponenten« festgestellten Software-Komponentenbedarf einset-
zen möchte? Mit einer kurzen Betrachtung kann eine Kapazitätsschätzung
angestellt werden.
Beispiel: Mengenermittlung
Mengen
Die Schadensanalysen eines Kraftwerkes umfassen die gesamten Komponen-
ten, Bauteile, Materialien und Betriebsmittel der Produktionsanlage. Eine
Schadensanalyse umfasst daher die Daten aller Bauteile des Kraftwerks. Schä-
den sind abhängig vom Zusammenspiel der Komponenten im Produktions-
prozess. Eine Schadensanalyse umfasst daher auch die Daten der Einbauorte,
die sogenannte Anlagentopologie. Schäden haben eine Vorgeschichte, Schä-
den machen sich durch Störgeräusche, Verformung, Temperaturwechsel,
Stoffaustritt, Output-Schwankungen und Signale bemerkbar.
298 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
Auf der Basis der Mengenschätzungen werden unter Berücksichtigung der Rah-
menbedingungen, wie z.B. vorhandene Rechnertypen und Einkaufseinschrän-
kungen, die Hardwarekomponenten bestimmt.
Beispiel: Hardwarebestimmung
Rechner
In den technischen Bereichen haben sich Rechner der VAX-Familie von DEC
mit dem Betriebssystem VMS und UNIX-Rechner diverser Hersteller durch-
gesetzt. Es gilt die Devise, nur wenn ausdrücklich zu erkennen ist, dass die
vorhanden Rechner nicht einsetzbar sind, ist nach einem neuen Hersteller
zu suchen. Dann soll aber immer noch UNIX das bevorzugte Betriebssystem
sein. Auf alle Fälle ist klein zu beginnen, bei Offenhaltung der Möglichkeit
eines sukzessiven Ausbaus.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 299
Gestaltungsentscheidungen
Wie in den vorhergehenden Kapiteln werden auch hier die Entscheidungen, die
im Musterprojekt »DWH für Energieversorger, InDaWa« getroffen wurden, im
Überblick zusammengestellt.
Entscheidung/
Gestaltungsaspekt Erkenntnis Begründung
ORIENTIERUNG
ARCHITEKTUR
Betriebswirtschaftskomponenten
...
Softwarekomponenten
Hardwarekomponenten
...
WAN Keine Erweiterung erforderlich Keine Daten von außen
Peripherie
Organisationskomponenten
...
VORGEHENSMODELL
5.8 Übungen
Übung 5.1: Hardware-Architekturkomponenten
Zählen Sie auf, welche Hardware-Architekturkomponenten aus Ihrer Sicht und
mit Ihrer Erfahrung für die Arbeitsplätze
✔ Bereichsleiter Marketing
✔ Aufsichtsratsmitglied
✔ Weltweiter Produktmanager für eine Produktgruppe
✔ Weltweiter Einkäufer für die Bauteile von Robotern
✔ Zentrale Buchhalterin für Debitoren
zum Betrieb von DWH-Komponenten erforderlich sein könnten.
Übung 5.2: WAN- und LAN-Komponenten
Zählen Sie die Komponenten eines WAN und LAN umfassenden Unternehmens-
netzes auf und schildern Sie die Aufgabe der Komponenten anhand eines
gedachten Durchlaufs der Informationen einer Datenbankanfrage.
Übung 5.3: Rechnertypen
Geben Sie die für ein DWH interessanten Rechnertypen mit ihren wesentlichen
Eigenschaften an.
Übung 5.4: Skalierungsfälle
Welche Skalierungsfälle können für ein DWH auftreten und mit welchen Ska-
lierungsmöglichkeiten kann man das DWH-System anpassen?
Übung 5.5: Arbeitsplatzausstattungsschema
Stellen Sie schematisch die Hardwarekomponenten und die Netzintegration
einer DWH-Arbeitsplatzausstattung dar.
Übung 5.6: Transaktion
Beschreiben Sie den Ablauf einer Transaktion in einer zweistufigen Client/Ser-
ver-Architektur. Wie heißt die grundlegende Prozedur, die hierfür verwendet
wird?
Übung 5.7: Client/Server-Technologie
Welche Gestaltungsfreiheiten sind mit der Client/Server-Technologie gegeben?
Übung 5.8: Client/Server-Applikation
Zeigen Sie die Trennstellen einer Client/Server-Applikation auf. Nehmen Sie ein
Ihnen bekanntes Beispiel für eine Applikation und schildern Sie, auf welche
Rechnertypen Sie welchen Programmteil implementieren würden.
302 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
Das WAN bestimmt nicht die Rechnerentscheidung und auch nicht die LAN-
Entscheidung. Deshalb kann die WAN-Entscheidung auch zuletzt getroffen
werden.
Zweiter Entscheidungsgang
Das Rechnersystem ist, je komplizierter sein Aufbau, also je umfangreicher die
Anzahl der kooperierenden Komponenten ist, mit einer Infrastruktur zu ver-
binden, mit einem Lokalen Netzwerk. Die Bestimmung der Netzwerke ist hier
als zweiter Entscheidungsgang dargestellt. Im ersten Schritt des zweiten Ent-
scheidungsganges wird die Verkabelungsart bestimmt.
Im zweiten Schritt des zweiten Entscheidungsganges werden der LAN-Tech-
nologie und LAN-Topologie entsprechend die Komponenten im LAN bestimmt.
Der zweite Entscheidungsgang kann auch nach der Bestimmung des Rechner-
systems durchgeführt werden. Wenn das Lokale Netz schon existiert, sind
lediglich Erweiterungen oder Umstrukturierungen zu überlegen. Es wird aller-
dings beim Neuaufbau nicht das LAN den Rechnertyp bestimmen, sondern die
LAN-Entscheidung entsprechend der Rechnerentscheidung getroffen werden.
Dritter Entscheidungsgang
Im dritten Entscheidungsgang wird zunächst auf der Ebene des Systemtyps im
ersten Schritt des dritten Entscheidungsgangs das Rechnersystem bestimmt.
Da das DWH-System aus mehreren Rechnern besteht, sind dies mehrere Rech-
ner, je nach Bedarf und Funktion im Gesamtsystem und je nach Benutzerrolle.
Weiter kann auf der Ebene der Systemkomponenten im zweiten Schritt des
dritten Entscheidungsgang der Rechneraufbau detailliert werden. Zum Bei-
spiel könnte die zum Systemtyp »Rechnersystem« gehörige Systemkompo-
nente »Workstation« relevant sein.
Die Leistungsfähigkeit von Workstations unterscheidet sich in der Leistungsfä-
higkeit ihrer einzelnen Bauteile oder Systemmodule, die im dritten Schritt des
dritten Entscheidungsgangs bestimmt wird. Deshalb ist es interessant, die
Alternativen, z.B. der möglichen »Motherboards«, zu betrachten. Das Herz-
stück eines Motherboard ist der Prozessor. In der Regel ist es ausreichend, sich
dann auf der Ebene der Funktionen unter einem bestimmten Prozessortyp, z.B.
einem RISC-Prozessor, für eine Leistungsklasse, z.B. mit der Taktrate 300 MHz,
zu entscheiden.
Der beispielhafte Durchlauf durch die Gestaltungsentscheidungen des dritten Ent-
scheidungslaufes ist wie folgt:
304 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen
Systemtyp
Rechnersystem
2. Schritt
Systemkompo-
nente
Workstation
3. Schritt
Systemmodul
Motherboard
4. Schritt
Funktionen
Prozessortyp RISC
Vierter Entscheidungsgang
Im vierten Entscheidungsgang ist die Peripherie des Rechnersystems zu defi-
nieren. Diese hängt von der Umgebung ab, in der das Rechnersystem arbeiten
soll. Das Ergebnis ist die Definition der Eingabegeräte, Ausgabegeräte, der Spei-
chersysteme und einiger Hilfssysteme wie z.B. Stromversorgung, Sicherheits-
systeme, Feuerschutz. Neben der Spezifikation der Peripheriegeräte muss auch
der Aufstellungsort bestimmt werden. Der Aufstellungsort ist von der Qualifika-
tion der Anwender, klimatischen Bedingungen und Medien, auf denen die
Informationen geliefert werden, abhängig.
Die verschiedenen Gestaltungsobjekte der Systemtypen sind unterschiedlich
tief zu detaillieren. Dies liegt im Ermessen des DWH-Spezialisten. Diese unter-
schiedlichen Detaillierungsgrade bringt die Grafik »Entscheidungsgang Data
Warehouse Gestaltung« durch die unterschiedliche Aufteilung der Boxen zum
Ausdruck. Die Grafik gibt nicht in allen Detaillierungsstufen eine vollständige
Klassifikation, sondern sie beschränkt sich der Übersichtlichkeit und der
Erkenntnis des Zerlegungsprinzips zuliebe auf die wichtigsten Unterteilungen.
Mit diesen Gestaltungsentscheidungen sind noch keine Produktentscheidun-
gen getroffen, sondern nur Kriterien für die Produktsuche geschaffen. Damit
ist also der beispielhafte Durchlauf durch die Gestaltungsentscheidungen wie
folgt (siehe Abbildung 5.22).
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 305
&'" "
"&, "%
(" 1+1
*&
&"%
* & "%
% -"
) 8
-7%
.1
%
+ "%
' & """%
(
-"%
- &"%
-&&
%
-#
&& -&&
$ $ &
"! "&
$! %
&
&
$
))
)
!" )
*&& '
))
&$ ("
"&&
) "
+"
! ,
" !
#
) ))
&6 /0
(
&- 1/0
"4(&&4
&"&
"
&-
&
$$
'
&&
2
($
KAPITEL 6
6 Welche Organisationsstruktur muss für ein Data
Warehouse System implementiert werden?
Übersicht
Ein DWH besteht aus betriebswirtschaftlichen Funktionen, aus der Software,
die diese betriebswirtschaftlichen Funktionen automatisiert ausführt, und aus
der Hardware, auf der die Software von Betriebssystemen gesteuert zur Ausfüh-
rung kommt. Die Automatisierung kann nicht umfassend sein. Sie muss durch
manuelle Handlungen, durch Entscheidungen und Veranlassungen und durch
Umsetzungen in Gang gebracht und in Gang gehalten werden. Das Zusammen-
spiel der betriebswirtschaftlichen Abläufe ist eine Kombination aus manuellen
und automatisierten Aktivitäten. Dieses Zusammenspiel ist zu organisieren.
Eine DWH-Organisation agiert in einem internen Umfeld des Unternehmens.
Nicht das gesamte Unternehmen und auch nicht das gesamte Umfeld wirken
auf das DWH ein, sondern nur ein Ausschnitt. Das Unternehmensumfeld des
DWH besteht aus den mit dem DWH zusammenarbeitenden Systemen. Die
Organisationsgestaltung des DWH ist vom jeweiligen Umfeld – der unterneh-
mensinternen Organisation – abhängig.
Auch das Unternehmen ist von einer Umwelt umgeben; das ist ein bestimmter
Ausschnitt aus der Welt, der mit dem Unternehmen in Kontakt steht und
gewisse Einflüsse auf es ausübt. Um diese Einflüsse mit in die Gestaltung einbe-
ziehen zu können, ist der relevante Umweltausschnitt festzustellen.
In der folgenden Abbildung ist die Einbettungsbeziehung von Welt, relevanter
Umwelt, Umfeld und DWH dargestellt.
Der Aufbau des Kapitels Organisation ist dementsprechend in die drei Teile
Umwelt, Umfeld und Organisation aufgeteilt. Die drei Teile werden in den fol-
genden Kapiteln von außen nach innen bearbeitet. Diese Vorgehensweise
erklärt sich durch die »Enthalten-sein-Beziehung«:
➡ Die Umwelt enthält das Umfeld des Unternehmens,
➡ das Umfeld des Unternehmens enthält das Umfeld des DWH,
➡ das Umfeld des DWH enthält die Organisation des DWH komplett.
Zuerst wird betrachtet, was unter der Umwelt des DWH zu verstehen ist, und es
werden Mittel zur Analyse vorgestellt. Im zweiten Schritt wird die Betrachtung
in Richtung Innenwelt oder Umfeld fortgesetzt, um dann die Organisation des
DWH zu entwerfen.
Wer sich tiefer als hier dargestellt in die Organisationstheorie einarbeiten will,
dem sei empfohlen:
Bleicher, Organisation
Wittlage, Unternehmensorganisation
Wittlage, Fallstudien
Wittlage, Methoden
Lernziel
Die Lernziele bestehen darin, eine verbesserte Sicht auf die »Außenwelt« des
Unternehmens zu schaffen, Erkenntnisse aus dieser Außensicht zu gewinnen
und ihre Bedeutung für das DWH zu beurteilen.
Ebenso gilt es, eine verbesserte Sicht auf die »Innenwelt« des Unternehmens zu
schaffen, Erkenntnisse aus dieser Innensicht zu gewinnen und ihre Bedeutung
für das DWH zu beurteilen.
Als Lernziel ergibt sich auch, dass der DWH-Spezialist so viel Know-how erwer-
ben muss, dass er alle Komponenten der Organisation eines DWH erkennt, fest-
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 309
Lernziele
Verstehen der Bedeutung der Umwelteinflüsse
Erkennen des relevanten Umweltausschnitts
Aufnehmen der Umwelteinflüsse in die Gestaltung des DWH
Verstehen der Bedeutung der Umfeldsysteme und der Umfeldorganisation
Erkennen des relevanten Umfeldausschnitts
Aufnehmen der Berührungspunkte des Umfeldes in die Gestaltung des DWH
Kennen der Komponenten einer Organisationsstruktur
Anwenden der Methodik zur Lösung von Organisationsgestaltungsfragen
Feststellen der nötigen Befugnisse und Kompetenzen
Definition der Berichtswege und Berichtsformen für den Betrieb des DWH
Definition der Aufgaben des DWH-Betriebspersonals
Bestimmung der für den DWH-Betrieb erforderlichen Rollen und Stellen
Beschreibung der Organisationsstruktur eines DWH-Betriebs
Beschreibung der Prozesse für den Betrieb des DWH
6.1 Welcher Umweltausschnitt ist für den Entwurf eines DWH
relevant?
Problemstellung und Motivation
Das Unternehmen, das ein DWH betreibt, ist in eine Umgebung, eine Unterneh-
mensumwelt integriert. Diese Unternehmensumwelt ist immer vorhanden, ob
das DWH aufgebaut wird oder nicht. Die Umwelt kann durch das Unternehmen
beeinflusst werden. Es können z.B. Partnerschaften geschlossen werden für die
Zusammenarbeit bei der Produktion oder dem Absatz von Produkten. Unter-
nehmen arbeiten in Arbeitsgemeinschaften, um Standards zu schaffen, die sie
bei der Konstruktion ihrer Produkte berücksichtigen. Unternehmen arbeiten
über Verbände mit politischen Einrichtungen zusammen, um Gesetzesbildun-
gen möglichst unternehmerfreundlich zu beeinflussen.
Ein Unternehmen steht im kontinuierlichen Austausch mit seiner Umwelt. Es
wird von seiner Umwelt beeinflusst. Alle Veränderungen der Umwelt verändern
auch die Einwirkungen auf das Unternehmen. Ein Unternehmen muss sich die-
sen Veränderungen aussetzen, es muss diese Veränderungen und deren mögli-
che Auswirkungen erkennen und analysieren. Das Ergebnis der Analyse müssen
310 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System
Definition: Unternehmensumwelt
Die Unternehmensumwelt sind alle Systeme, Institutionen, Konstellationen
und Organisationsstrukturen, die durch ihren Informationsaustausch, ihre
Prozesse und ihre Funktionen auf das Unternehmen einwirken.
Auflagen und politische Zielsetzungen ändern sich im Lauf der Zeit, was immer
wieder zu neuen Gesetzen und Auflagen führt. Den Unternehmen wird in sol-
chen Fällen in der Regel ein Umstellungszeitraum eingeräumt, der zur
Umstrukturierung ausreichen muss. Beispiele hierzu sind der Beschluss der EG
zur europaweiten Einführung des EURO als Zahlungsmittel, der geplante
Abbau von Kernkraftwerken, die Öffnung der Strommärkte und die Privatisie-
rung der Telekommunikation.
Ein Unternehmen bezieht Güter, Vorprodukte und Dienstleitungen von ande-
ren Unternehmen. Prozesse, die andere Unternehmen besser, preiswerter, qua-
litativ hochwertiger und schneller abwickeln können, werden ausgelagert und
die Ergebnisse bzw. Produkte dieser Prozesse eingekauft. Das Unternehmen,
das ein DWH aufbauen möchte, steht in prozessualem Austausch mit der
Umgebung.
Funktionen des Unternehmens können an Verbände delegiert werden und in
politische Aufträge gekleidet werden. Das Unternehmen, das ein DWH aufbauen
möchte, steht in funktionalem Austausch mit der Umgebung.
Diese Umgebung besteht z.B. aus konkreten organisierten Gesellschaften wie
anderen Unternehmen, Institutionen, Parteien, Verbänden, Staaten und unor-
ganisierten Gesellschaften wie Interessengruppen. In der Umgebung manifes-
tieren sich technologische Tendenzen, politische Ereignisse und Strömungen,
gesellschaftliche Veränderungen und Naturkatastrophen.
Einige wichtige ausgewählte Umweltbeziehungen sind deshalb:
✔ Informationsaustausch, Auflagen, Gesetze
✔ Güteraustausch, Warenlieferungen, Versorgung, Personalbewegung
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 311
✔ Prozessteilung, Arbeitsteilung
✔ Zahlungsfluss
✔ Funktionsdelegation
Auch wenn Umgebungseinflüsse gar nicht oder nur geringfügig beeinflusst
werden können, sind sie doch in ihrer Auswirkung von erheblicher Bedeutung.
Nahezu alle Umweltbeziehungen mit Austauschprozessen sind von Informati-
onsfluss begleitet.
Um frühzeitig über Umweltursachen und deren Wirkungen informiert zu sein,
sind sogenannte »Frühwarnsysteme« entwickelt worden. Ein Frühwarnsystem
soll schon so lange vor Eintreten des schwerwiegenden Ereignisses dieses
Ereignis ankündigen, dass eine Vorbereitung auf die Auswirkungen möglich ist.
Umweltsysteme
Für die Auswahl relevanter Umweltsysteme können Typologien dienen. Einmal
ist eine Typologie der Unternehmen und Institutionen interessant, da andere
Unternehmen Bestandteil der Umwelt sind. Nützlich ist auch eine Klassifika-
tion der Fachgebiete, da jedes Fachgebiet in Wissenschaft und Forschung
Ergebnisse hervorbringt, die wieder zu neuen Tendenzen in Gesellschaft und
Technik führen. Hierzu dient die folgende Checkliste Umweltsysteme.
Bereich Systeme
Austauschtyp Austauschobjekte
Wirkungsbeziehungen
Zur Darstellung der Wirkungsbeziehungen der Umweltsysteme kann das Kon-
textdiagramm Umweltsysteme angewendet werden. Das Kontextdiagramm
wird in Kapitel 7 »Das Vorgehensmodell für Data Warehouse Systeme« vorge-
stellt. Liegt der Schwerpunkt der Darstellung auf den Wirkungsbeziehungen,
kann das Wirkungsdiagramm nach Vester
Vester, Ballungsgebiete
oder ein Petrinetz verwendet werden:
Reisig, Systementwurf
Definition: Unternehmensumfeld
Das Unternehmensumfeld sind alle Systeme und Organisationsstrukturen
des Unternehmens mit ihrer Innenwirkung, ihrem gegenseitigen Informati-
onsaustausch, den zwischen ihnen ablaufenden Prozessen und ihren Funk-
tionen.
ten zur Kommunikation. Das können Programme sein, das können Hardware-
schnittstellen sein, und es sind immer auch organisatorische Strukturen.
➢ Feststellung der Umfeldsysteme
➢ Auswahl der für die Konzeption des DWH relevanten Umfeldsysteme
➢ Ermittlung der funktionalen, informationellen, prozessualen, materiellen
Wechselwirkungen des Umfeldes auf das angestrebte DWH
Bereich Anlagen
Produktionstechnik Transportanlagen
Austauschtyp Austauschobjekte
Kontextdiagramm Umfeldsysteme
Die Umfeldsysteme werden in einem Kontextdiagramm, dem Kontextdiagramm
Umfeldsysteme, grafisch dargestellt. Das Kontextdiagramm Umfeldsysteme
muss nahtlos in das zuvor ermittelte Kontextdiagramm Umweltsysteme einge-
passt werden können. Das bedeutet, dass die Austauschbeziehungen zwischen
Umwelt und Unternehmen, die als relevant für das DWH ausgemacht wurden,
sich zu Austauschbeziehungen zwischen Umfeld und DWH fortsetzen müssen.
Das Kontextdiagramm wird in Kapitel 7 »Vorgehensmodell« vorgestellt.
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 317
Im Folgenden wird nun die speziell für die drei Lebensabschnitte des DWH –
Aufbau, Betrieb und Abbau – erforderliche Organisation ermittelt, bzw. werden
die in der Praxis zu lösenden Aufgaben dargestellt.
Sinnzusammenhang der Organisation
Organisation steht in einem bestimmten Sinnzusammenhang mit den Aufga-
ben eines Unternehmens. Ein Betrieb wird durch eine Zweckaufgabe begrün-
det, d.h. er verfolgt nach seiner Gründung einen Betriebszweck. Dieser Zweck
ist in Zielen formuliert. Alles, was ein Betrieb macht, ist zielgerichtet, d.h. es
dient der Erreichung seiner Ziele, unabhängig davon, ob diese Ziele tatsächlich
erreicht werden, oder ob sie sich im Laufe der Betriebstätigkeit verändern.
!
Der Betrieb verfolgt die Erreichung der Ziele unter Einsatz der ihm zur Verfü-
gung stehenden Mittel. Diese Mittel können als zu kombinierende Faktoren
eines Produktionsprozesses im allgemeinsten Sinne (also auch Ideenproduk-
tion) in Sachmittel, Finanzmittel und Personen gruppiert werden.
Sachmittel sind z.B. Rohstoffe, Informationen, Räume, Energiepotential, Ver-
sorgungssysteme, Menschen, Maschinen, Werkzeuge. Ohne Sachmitteleinsatz
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 319
bleibt die Tätigkeit rein geistiger Natur. Schon die Dokumentation von Ideen
erfordert Sachmittel. Sachmittel können bzw. müssen erworben werden, und
für die Bezahlung sind Finanzmittel erforderlich. Ohne Finanzmittel können
Sachmittel nicht beschafft werden. Beschaffung und Einsatz von Sachmitteln,
auch die Transaktion von Finanzmitteln zur Beschaffung, werden von Perso-
nen durchgeführt.
Für alle Aktivitäten sind also Handlungsträger erforderlich. In den meisten Fäl-
len sind das Personen, es können aber auch Automaten und Maschinen sein.
Automaten können ursprünglich manuelle Tätigkeiten automatisch ausführen.
Automaten und Maschinen müssen allerdings wiederum von Personen entwor-
fen, konstruiert, gebaut und bedient werden. Ein Unternehmen erfordert eine
Organisation, um das Zusammenwirken seiner Sachmittel, Finanzmittel und
Personen zu koordinieren. Dieses Zusammenführen der Ressourcen und ihr
Zusammenwirken wird mit dem Begriff Faktorkombination bezeichnet.
Organisationsstruktur
Eine Organisation besteht aus Struktur und Prozessen. Organisationsstruktu-
ren sind ein Potential für Prozesse. Organisationsstrukturen sind ganz allge-
mein eine verfügbare Infrastruktur der Elemente der Unternehmung, die
zusammen auf eine Menge von Grundsubstanzen und Objekte wie Rohstoffe,
Information, Räume, Energiepotential, Versorgungssysteme, Menschen,
Maschinen und Werkzeuge wirken sollen mit dem Ziel, über den kombinierten
Einsatz ein Erzeugnis hervorzubringen. Eine Organisationsstruktur ist damit
eine sinnvolle Ordnung dieser wirkenden und bewirkten Elemente.
Beispiele für Elemente einer Organisationsstruktur sind der Aufbau einer tech-
nischen Anlage, wie im Kapitel »Die Architektur von Data Warehouse Syste-
men« dargestellt, eine Lagerordnung von Ersatzteilen, die hierarchische Glie-
derung der Organisation, die Anordnung der Zufahrtswege zum Unternehmen.
Eine Organisationsstruktur wirkt allerdings noch nicht von selbst. Die Struk-
turelemente müssen bewegt, in Gang gesetzt, in eine Wirkungsfolge gebracht
werden. Diese Wirkungsfolge ist ein Prozess. Ein Prozess ist die zeitliche
320 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System
Was nach der Aktivität passieren soll, ist noch zu klären mit der Nennung der
Nachfolgeaktivität. Der Anstoß zur Ausübung der Aktivität kann die Zuliefe-
rung aus der Vorgängeraktivität oder ein anderes Signal sein. Mit der Verknüp-
fung von Aktivität, Vorgänger, Nachfolger und auslösender Bedingung ist der
Prozess definiert.
Definition: Organisationsobjekt
Ein Organisationsobjekt oder Verrichtungsobjekt ist das Objekt, an dem pri-
märe organisatorische Handlungen ausgeübt werden.
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 323
Organisatorische Aufgaben
Die Aufgabenstellung definiert, was mit dem Organisationsobjekt getan werden
muss oder was das Ergebnis der Aktivität sein soll und unter welchen Bedin-
gungen die Aktivität ausgeführt werden soll. Die Tätigkeit an dem Objekt ist
durch eine Handlung, einen Vorgang, eine Reihenfolge von Schritten beschrie-
ben. Eine organisatorische Aufgabe lässt sich also folgendermaßen formulie-
ren: »Am Objekt X ist Y vorzunehmen.« Eine organisatorische Aufgabe kann
auch teleologisch formuliert sein und die Handlung unerwähnt lassen: »Objekt
Y ist zu Objekt Z umzuformen.« Die Bedingungen sind sehr verschiedenartig.
Sie können sein:
✔ Fallregelungen wie: »Wenn Ereignis E passiert ist Aktivität X vorzuneh-
men.«
✔ Anweisungen wie: »Person P sagt, Aktivität X muss vorgenommen werden.«
✔ Terminvorgaben wie: »Bis zum Datum D muss Aktivität X ausgeführt sein.«
✔ Mengenregelung wie: »Aktivität ausführen, bis Menge Z hergestellt ist.«
Je genauer eine organisatorische Aufgabe formuliert ist, umso exakter kann sie
ausgeführt werden. Aber je exakter die organisatorische Aufgaben formuliert
ist, umso weniger Spielraum hat der Handelnde. Eine Abweichung von der Vor-
gabe ist aber bei unvorhergesehenen Vorkommnissen, die die Bedingungen ver-
ändern, unbedingt erforderlich.
Methoden, Technologie, Verfahren
Mit der Methode wird beschrieben, wie die Aufgabe erfüllt werden soll, wenn
alternative Handlungsfolgen möglich sind. Eine Methode beschreibt eine emp-
fohlene Herangehensweise, eine Zergliederung einer komplexen Handlung in
kleinere Handlungseinheiten. Eine Methode ist selbst eine Sammlung »kleiner«
organisatorischer Aufgaben, die, zu einer Abfolge geordnet, über Zwischen-
schritte zur Erfüllung der Aufgabe an einem Objekt führt. Diese »kleinen Aufga-
ben« können aus der »großen Aufgabe«, der organisatorischen Aufgabe an dem
Objekt, durch Zerlegen des Objekts in kleine, handhabungsfreundliche Teile,
entstehen. Für eine Methode ist die Reihenfolge der Handlungen wesentlich.
Definition: Methode
Eine Methode ist eine abgestimmte Reihenfolge von Detailhandlungen, um
eine organisatorische Aufgabe auszuüben.
324 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System
Oft wird neben dem Begriff der Methode der Begriff der Technologie synonym
verwendet. Hier soll unter Methode die abstrakte Schilderung der einzelnen
detaillierten Handlungen verstanden werden und unter Technologie der techni-
sche Produkttyp, von dem die technischen Mittel des Einsatzes sind. Eine
Methode zur Trennung des Verrichtungsobjekts Stahlstange ist zum Beispiel
Schneiden. Die Technologie kann ein Schneidbrenner oder ein Laserstrahl sein.
Definition: Technologie
Eine Technologie ist der technische Produkttyp, zu dem die technischen Mit-
tel des Einsatzes gehören.
Oft wird neben dem Begriff der Methode der Begriff des Verfahrens synonym ver-
wendet. Hier soll unter Verfahren die Folge der organisatorischen Handlungen
nach den Regeln einer Methode zusammen mit ihren Technologien und mit Hilfe
von Werkzeugen an einem oder mehreren Verrichtungsobjekten verstanden wer-
den. Ein Verfahren ist z.B. die Beförderung der Stahlstange bis zur Trennma-
schine, die Trennung des Verrichtungsobjekts Stahlstange mittels der Technolo-
gie Laserstrahl und die anschließende Kühlung der Schnittflächen mit Öl.
Definition: Verfahren
Ein Verfahren ist die abgestimmte Folge des Einsatzes von Methoden nach
Regeln und mit Hilfe von technischen Mittel, den Werkzeugen, an einem
oder mehreren Verrichtungsobjekten.
Definition: Aufgabenträger
Ein Aufgabenträger ist eine Person oder eine Maschine, die eine organisato-
rische Aufgabe ausüben soll.
Kein Mensch der Welt kann alle Aufgaben alleine durchführen, und auch im
Gefüge eines Unternehmens und sogar bei dem, gemessen am Gesamtunter-
nehmen kleinen, Aufgabenbereich DWH fallen so viele Aufgaben an, dass Aufga-
benteilung erforderlich ist. Aufgabenteilung und Aufgabenbündelung auf Auf-
gabenträger führt zu Rollen. Jeder Aufgabenträger, ob Person oder Maschine,
kann mit einer Rolle völlig ausgelastet und zufrieden sein, oder aber mehrere
Rollen ausüben.
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 325
Rollen können von internen wie auch von externen Aufgabenträgern einge-
nommen werden. Besonders für den Einsatz vorübergehender Kapazitätslasten
lohnt es nicht, dauerhafte Stellen oder Rollen einzurichten. Jobs auf Zeit sind
in Deutschland eher die Ausnahme, was die Alternative des zeitlich und kosten-
technisch begrenzten Einsatzes externen Personals attraktiv macht.
Definition: Rolle
Eine Rolle ist die Zuordnung einer organisatorischen Aufgabe zu einer Per-
son oder einer Maschine, die diese Aufgabe ausüben soll.
Eine Stelle ist einem Aufgabenträger zugeordnet. Eine Stelle ist in ein Gefüge
von Weisungsrechten integriert. Eine Stelle mit Weisungsrecht ist ein Vorge-
setzter von Weisungsempfängern. Zu einer Stelle gehört eine Aufgabenstellung.
Nicht jeder Aufgabenträger muss ein Mensch sein. Aufgaben können in Pro-
grammen realisiert werden und von Maschinen ausgeführt werden. Eine Stelle
kann mehrere Rollen ausüben. So kann z.B. ein Buchhalter auch Betriebsrats-
vorsitzender, Projektleiter für die Einführung der neuen Währung »EURO« und
Mentor für die Integration neuer Mitarbeiter in den Bereich Rechnungswesen
sein.
Definition: Stelle
Eine Stelle ist die Zusammenfassung aller organisatorischen Aufgaben zu
einem Aufgabengebiet genau einer Person.
Organisationsstruktur
Der Begriff »Organisationsstruktur« wird oft synonym mit dem Begriff Organi-
sationshierarchie gebraucht, weil dies die am weitesten verbreitete Struktur der
Weisungsbefugnisse in Unternehmen ist. Die Hierarchie ist nicht die einzige
Struktur einer Organisation und deshalb ist der Begriff »Organisationshierar-
chie« im Sinne der Bedeutung der »Hierarchie« nicht allgemein genug. Besser
ist daher der Begriff Organisationsstruktur.
Die Struktur kann sich im Laufe der Lebenszeit des organisierten Unterneh-
mens wandeln. Die moderne Zeit erfordert schnelle Anpassung der Organisati-
onsstruktur an äußere Bedingungen. Die Organisationsstruktur unterliegt
daher einer laufenden Veränderung. Die Anforderungen aus der Umwelt der
Unternehmen ändern sich so schnell, dass die erfolgreichsten Unternehmen
diejenigen sind, die ihre Organisationsstruktur am schnellsten anpassen kön-
nen. Der Höhepunkt der Anpassungsfähigkeit hat sich in den sogenannten »vir-
tuellen Unternehmen« gefunden, die sich, immer auf eine neue Aufgabenstel-
lung ausgerichtet, neu bilden und nach der Abwicklung der Aufgabe wieder
auflösen.
326 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System
Definition: Organisationsstruktur
Eine Organisationsstruktur ist die Zusammenfassung aller Stellen mit ihren
Verbindungen entsprechend ihrer Berichtswege und Beauftragung.
Definition: Kompetenz
Kompetenz ist die Erlaubnis zur Ausübung einer organisatorischen Aufgabe.
Ein Projektleiter DWH muss zum Beispiel mit der Kompetenz der Projektüber-
wachung ausgestattet werden. Hierzu gehören die Befugnisse
✔ Einladung zu Besprechungen
✔ Bestellung von Besprechungsräumen
✔ Bedarfsanforderung von Equipment
✔ Abzeichnung der Aufwandsberichte der Mitarbeiter
✔ Berichten an Vorgesetzte in Lenkungsausschüssen
✔ Erteilung von Terminvorgaben
✔ Zuweisung von Aufgaben an Projektmitarbeiter
Qualifikation
Zur Ausübung der Aufgaben einer Stelle oder Rolle ist Befähigung in Form von
Wissen, Erfahrungen zu Vorkommnissen und Risiken, Kenntnisse von Metho-
den, Sachkenntnis über die zu bearbeitenden Objekte und Fertigkeit in der
Anwendung von Sachmitteln erforderlich. Eine Stelle benötigt zur Erfüllung
ihrer Aufgaben eine angemessene Qualifikation. Angemessen bedeutet, dass
weder eine schlechtere Qualifikation (Unterqualifikation) noch eine bessere
Qualifikation (Überqualifikation) geeignet sind.
Definition: Qualifikation
Qualifikation ist die Befähigung zur Ausübung einer organisatorischen Auf-
gabe.
Sachmittel
Das Wissen des Aufgabenträgers über den Zustand des Verrichtungsobjekts ist
nicht immer aktuell. Die an einem Verrichtungsobjekt auszuübende Tätigkeit
erfordert Informationen. Die Fähigkeiten des Menschen als Handlungsträger
sind physisch und physikalisch begrenzt. Solche Grenzen sind z.B. Muskelkraft,
Fingergröße, Temperaturresistenz, Schnelligkeit, Sehvermögen, Ausdauer. Die
an einem Verrichtungsobjekt auszuübende Tätigkeit erfordert Hilfsmittel. Die
Ausübung einer Aufgabe macht also den Einsatz von Sachmitteln erforderlich.
Sachmittel sind
✔ Werkzeuge
✔ Rohstoffe
✔ Arbeitsmaterial
✔ Energieversorgung
✔ Transportmittel
✔ Halbprodukte
✔ Maschinen
✔ Informationen
✔ Anleitungen
✔ Signalflüsse
Die zu bearbeitenden Objekte sind selbst wieder als Sachmittel für andere orga-
nisatorische Aufgaben einsetzbar. So kann die organisatorische Aufgabe z.B. die
Herstellung von Werkzeugen sein. Mit den Sachmitteln und an den Sachmit-
teln werden die Aktivitäten ausgeübt.
Definition: Sachmittel
Sachmittel sind alle Hilfsmittel, die zur Ausübung einer organisatorischen
Aufgabe eingesetzt werden sollen.
"
!
#
$
!!
Ein gutes Beispiel für einen Prozess ist das Berichtswesen. Berichte werden
erstellt, indem der Inhalt der Berichte recherchiert und in einer freien Form
oder mittels Standardformularen und Musterberichten festgehalten wird. Der
Inhalt der Berichte wird abgestimmt. Berichte werden verteilt an eine vorher
verabredete Interessenten- oder Betroffenenliste. Der Inhalt der Berichte dient
der Überprüfung getroffener Entscheidung und der Unterstützung neuer zu
treffender Entscheidungen.
Die Ablauforganisation selbst eines kleinen Unternehmens ist bereits so kom-
plex, dass man sich mittels grafischer Darstellungen eine Übersicht verschafft.
Für diese Darstellungen bedient man sich standardisierter Symbole, die zu Dia-
grammen zusammengesetzt werden. Die Darstellung der Ablauforganisation ist
eine Methode und daher Bestandteil eines Vorgehensmodells. Die Methode Dar-
stellung der Ablauforganisation wird daher in Kapitel 7 »Das Vorgehensmodell
für Data Warehouse Systeme« besprochen.
Veränderungen an einem Prozess haben unmittelbare Auswirkungen auf
andere Prozesse. Auf die Schnittstellen von Prozessen ist deshalb besonderes
Augenmerk zu legen. Die Schnittstellenproblematik bleibt oft unbehandelt,
weil die Zuständigkeitsfrage ungeklärt ist. Die entscheidende Frage ist: »Ist der
Empfänger verpflichtet, sich Information zu holen (Holschuld) oder ist der
Sender verpflichtet Information zu bringen (Bringschuld)«.
➡ Da das Einrichten eines DWH Veränderungen von organisierten Prozessen
bewirkt, muss der DWH-Spezialist eine koordinierende Rolle zwischen den
Prozessen und deren Interessenten einnehmen.
Auslöser
Ein Auslöser eines Prozesses ist ein Startsignal für einen Automatismus oder
das Aktivieren eines Willens zu einer Handlung. Ein Auslöser kann eine ein-
zelne Handlung auslösen oder eine ganze Kette aufeinanderfolgender Handlun-
gen. Im zweiten Fall ist der Auslöser der Start für einen Prozess. Beispiel für
einen Auslöser kann die Anordnung einer Behörde, der Anruf eines Kunden, ein
Temperaturgrenzwert, eine Naturkatastrophe oder eine Zeitungsnachricht sein.
Definition: Prozessauslöser
Ein Prozessauslöser startet einen Prozess mit einer Aufgabe aus der Folge
von Aufgaben, Handlungen, Aktivitäten, Funktionen.
Input
Ein Prozess verarbeitet oder bearbeitet die Verrichtungsobjekte. Das zu verar-
beitende Gut ist entweder bereits im Prozess vorhanden oder wird dem Prozess
zugeliefert. In einen Prozess eingehende Objekte sind ein Prozess-Input. Auch
die Sachmittel müssen dem Prozess als Input beigestellt werden. Sachmittel
können bei der Einwirkung auf das Verrichtungsobjekt ebenfalls verändert wer-
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 331
Definition: Input
Ein Input in einen Prozess ist das Verrichtungsobjekt, an dem die Aufgabe,
Handlung, Aktivität, Funktion ausgeübt werden soll, oder ein Sachmittel,
mit dessen Hilfe die Aufgabe, Handlung, Aktivität, Funktion ausgeübt wer-
den soll.
Definition: Output
Ein Output aus einem Prozess ist das Verrichtungsobjekt, an dem die Auf-
gabe, Handlung, Aktivität, Funktion ausgeübt wurde, oder ein Sachmittel,
mit dessen Hilfe die Aufgabe, Handlung, Aktivität, Funktion ausgeübt wurde.
Was aus der Sicht des liefernden Prozesses ein Output ist, ist aus der Sicht des
empfangenden Prozesses ein Input. Prozesse sind über Input-Output-Bezie-
hungen vernetzt.
Zu einem Output kann auch einen Auslöser gehören, also neben dem Bereitste-
hen des Outputs zur Abgabe auch ein Signal, dass der Produktionsprozess neue
Rohstoffe aufnehmen kann.
onsbildung für das DWH muss im Zusammenhang mit den Aufbauschritten des
DWH durchgeführt werden.
Eine Ausnahme hiervon ist die Organisation der Bewältigung von Risikositua-
tionen. Das Eintreten des riskanten Ereignisses ist nicht vorhersehbar. Riskante
Situationen erfordern promptes Reagieren. Deshalb muss die Organisation der
Risikoaktivitäten vorbereitet sein. Sie kann nicht erst dann mit dem Aufbau der
Organisation zur Risikobewältigung anfangen, wenn die Risikosituation ein-
tritt. Folglich ist eine optimale Risikoorganisation bereitzuhalten.
Als Problemlösungsmittel für den Entwurf der Organisation dient ein allgemei-
nes, nicht nur für DWH gültiges Verfahren der Organisationsgestaltung, also
eine Richtlinie, in welcher Reihenfolge welche gestalterische Maßnahme
durchgeführt wird. Das folgende Verfahren ist zum Gestalten der Organisation
für ein DWH zu empfehlen:
Verfahren: Organisationsgestaltung
❖ Bestimmung der Prozesse mit Checkliste der prozessualen organisatori-
schen W's
Feststellung der erforderlichen prozessualen Regelungen
Definition der Teilnehmer und Träger der Prozesse
Definition der Zulieferer, Status und Ergebnisse der Prozesse
Festlegung des Berichtswesens, Qualitätssicherung
❖ Organisationsstruktur mit Checkliste der strukturalen organisatorischen
W's
Definition der Aufgaben
Zuweisung der Aufgaben zu Rollen
Kapazitätsbedarf der Aufgaben feststellen
Bündelung der Rollen mit zugehörigen Aufgaben zu Stellen
Einordnung der Stellen in die Hierarchie des Unternehmens
Definition der Befugnisse
Bestimmung der Sach- und Arbeitsmittel
❖ Staffing mit Rollen/Stellen-Schema
Ermittlung der erforderlichen Qualifikation
Allokation der Personalressourcen
Zukauf von temporären externen Ressourcen
Planung der Schulung
Checkliste Organisationsgestaltung
Zur Bestimmung der Organisationssituation dienen die im Kapitel vorgestell-
ten organisatorischen W's. Dabei sollte mit der Sammlung der interessieren-
den Prozesse gestartet werden. Die Prozesse sind aufzulisten und zu identifizie-
ren durch eine Bezeichnung und eine eindeutige Kennzeichnung aus
Nummern und/oder Buchstaben. Jeder Prozess sollte dann durch die Beantwor-
334 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System
tung der drei Prozessfragen beschrieben werden. Zudem müssen die einzelnen
Aktivitäten jedes Prozesses durch Beantwortung der Strukturfragen beschrie-
ben werden. Auch die Aktivitäten innerhalb des Prozesses sind zu identifizieren.
Ein Prozess wird demnach nach dem Schema der Checkliste Organisationssi-
tuation beschrieben.
Identifizierungsnummer Zu Prozess:
Prozess Bezeichnung Aktivität Aktivitätsbezeichnung
Wonach Woran
Wovor Was
Worauf Wie
Wer
Womit
Wozu
Weswegen
Wodurch
Wann
Wo
Rollen/Stellen-Schema
Als Hilfsmittel zur Definition von Rollen und deren Zusammenfassung zu Stel-
len dient das Rollen/Stellen-Schema. Im ersten Schritt sind die Rollen zu sam-
meln und anhand der Aufgaben oder der Qualifikation zu beschreiben. Ist die
Rollenliste vollständig, sind die von einer Rolle auszuübenden Aufgaben auf
ihren Zeitbedarf zu beurteilen. Füllt die Aufgabenstellung einer Rolle die für
eine Stelle vereinbarte Arbeitszeit nicht aus, kann die Stelle weitere Rollen aus-
üben. Für diese weiteren Rollen kommen solche in Frage, die in der Nähe der
Qualifikation der bereits der Stelle zugeordneten Rollen liegen. Die Qualifikati-
onen und Kenntnisse sollten sich in einer homogenen Weise ergänzen.
'!
$%&
!
) "
#
*
(
"(
Management DWH-System
Die Leitung eines DWH-Projekts wird nach Beendigung des Projekts nicht
mehr benötigt. Die bei der Durchführung des Projekts entstandene Kenntnis
vom System, seinen Eigenheiten und seinem Verhalten in der Testsituation ist
für das Management des Gesamt-DWH, das DWH-Management, ungeheuer
nützlich, wenn nicht sogar unverzichtbar, und sollte daher in Form der Stelle
DWH-Manager fixiert werden.
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 337
Eine andere wesentliche Aufgabe ist die permanente Beobachtung des Leis-
tungsverhaltens des Systems, der Performance. Das Performance-Auditing ist
eine Querschnittstätigkeit und dient der Ermittlung von Schwachpunkten des
Gesamtsystems, die sich auf die Antwortzeit und Verfügbarkeit auswirken. Bei
erkannter Ursache wird ein Maßnahmenplan erarbeitet und dessen Umsetzung
eingeleitet.
Die Unterschiedlichkeit der Komponenten erfordert im Wesentlichen verschie-
dene, sich nicht überschneidende Qualifikationen, je nach eingesetzter Soft-
ware und Hardware wie Applikations-Server-Auditing, Applikations-Auditing
und Customizing betriebswirtschaftlicher Standardsoftware, Datenbank-Audi-
ting, Datenbank-Server-Auditing. Jede Qualifikation umfasst sowohl alle spezi-
fischen Tools, das zugehörige Betriebssystem einschließlich der Utilities sowie
die Systemadministration der Applikationskomponente. Darüber hinaus ist
diese Qualifikation mit der speziellen Konfiguration der Kunden detailliert ver-
traut und bezüglich des Zusammenwirkens aller Systemkomponenten über-
blicksartig informiert. Ein Bündel von Kenntnissen, das keine Stelle alleine in
sich vereinen kann.
Die Aufgaben der DWH-Systemadministration sind:
✔ Konfiguration und Skalierung der Rechner-Hardware und der Betriebssys-
teme, Installation der Server-Komponenten
✔ Aufrechthalten der Betriebsverfügbarkeit von Rechnern und Netzen für die
Entwickler und Benutzer
✔ Datensicherung aller Ergebnisse
✔ Applikations-Server-Auditing
✔ Applikations-Auditing und Customizing betriebswirtschaftlicher Standard-
software
✔ Datenbank-Auditing
✔ Datenbank-Server-Auditing
Der Systemadministrator berichtet sowohl an den EDV-Leiter, dem der Betrieb
der Rechner unterstellt ist, als auch an den DWH-Manager.
PC- Betreuung
Die PC-Betreuung ist bereits vor der Installation eines DWH vorhanden, die
DWH-User werden bereits betreut, die Betreuung umfasst jedoch noch nicht
die DWH-Komponenten der Clients. Die PC-Betreuung ist daher für die neuen
Komponenten zu qualifizieren, der Leistungsumfang in den Serviceverträgen
entsprechend um die DWH-Komponenten der Clients zu erweitern.
Die neuen Aufgaben der bereits bestehenden PC-Unterstützung sind:
✔ Überwachung von Lieferung und Installation, Abnahme der DWH-Client-
Komponenten und ihrer Updates
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 339
Lage und die Zuständigkeit des Herstellers zügig transparent machen, um die
richtige Stelle mit weiteren Maßnahmen zu beauftragen. Hierfür ist bei großen
DWH-Systemen eine Person extra abzustellen, die Kenntnis von der gesamten
Infrastruktur und allen eingesetzten Softwareprodukten hat, und die das kom-
plexe Zusammenspiel der entsprechenden Stellen koordiniert. Dies ist der
DWH-Case-Management. Die Koordination wird bis zur Lösung der Situation
aufrechterhalten. Diese Rolle oder Stelle, je nach Größe des Gesamtsystems, ist
ein Case-Manager DWH-Probleme.
Die Aufgaben des DWH-Case-Managements sind:
✔ als unmittelbarer Ansprechpartner des Kunden zur Verfügung zu stehen
✔ Problembeschreibung mit Weitergabe an die entsprechenden System- und
Toolspezialisten
✔ Koordination der Applikations-Auditoren und Netz-Systemmanager
Der DWH-Case-Manager sollte dem DWH-Manager unterstellt sein. Wenn das
Unternehmen klein ist, kann jedoch eine Person beide Rollen ausüben.
Systemadministration LAN-WAN
Die Systemadministration LAN-WAN ist im Unternehmen bereits vorhanden
und höchstens kapazitativ anzupassen. Die Dokumentation, die Berichtssche-
mata wie die Systemdateien, müssen entsprechend den neu eingeführten DWH-
Applikationen und Rechnerpositionen und -konfigurationen und der Änderung
der Benutzererlaubnisse nachgeführt werden.
Die Aufgaben der Systemadministration LAN-WAN sind
✔ Nachführung der Konfigurationseinträge
✔ Netz-Auditing, WAN, LAN, LAN-Server
Die Systemadministration LAN-WAN bleibt weiterhin in die bestehenden Unter-
stellungsverhältnisse eingegliedert.
DWH-Hardwaremontage
Nach den Erfahrungen mit der Anfangsausstattung wird relativ schnell eine
Skalierung der Hardware erforderlich werden. Skalierungsmaßnahmen sind
zum Beispiel Kartentausch mit stärkeren Prozessoren, Speichererweiterungen,
Einrichtung von weiteren Knoten in einem Rack. Die Aufgabenstellung der
DWH-Hardwaremontage umfasst also auch im Betrieb die Lieferung und
Bereitstellung des Hardware-Equipments, und zwar für Erweiterungen, Aus-
tausch und Reparaturen bei Defekten. Die Montagearbeiten müssen jetzt mit
dem Betrieb koordiniert werden. Das bedeutet, sie müssen möglichst ohne Ver-
fügbarkeitseinschränkungen durchgeführt werden. Die Hardwarearbeiten müs-
sen ebenfalls abgenommen werden. Nach der Abnahme ist die Bereitstellung
für den Betrieb erreicht.
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 341
!
%( & &
'
( & &
%
+
& &
++,
& &
%(!+-
+*. ! & &
$
%+* / & &
0
1&
+
+ & &
#
!#
!
% & &
% & &
& &
% & &
!
% & &
% & &
Großunter
Kleinfirma Mittelstand
nehmen
Geschäftsführung GF GF
GF
GF
Informatik- IM
management
IM IM IM
DM
DWH-Management DM DM DM
Fachbetreuung FB FB
FB
FB SA
Systemanalyse SA SA
SA
PR
Programmierung PR PR
AD PR
AD
Administration AD AD
Für lokale Belange ist die lokale DWH-Sitzung mit regionalen Systemanalyti-
kern, Administratoren und Fachbetreuern eingerichtet. Der lokale DWH-Spre-
cher berichtet in die DWH-Managementsitzung.
Für den Betrieb des DWH kann man die Einrichtung folgender Besprechungs-
kreise empfehlen:
✔ DWH-Managementsitzung mit regionalen Sprechern, Systemanalytikern
oder Administratoren
halbjährlich
✔ Lokale DWH-Sitzung mit regionalen Systemanalytikern, Administratoren
und Fachbetreuern
zweiwöchentlich
Die Rollen für den Betrieb sind nicht per se vorhanden, sie müssen zunächst
definiert, vorbereitet, ausgewählt und aufgebaut werden.
Schon im Lebensabschnitt »Aufbau« werden die Rollen für den Betrieb vorbe-
reitet. Die Gestaltungsaufgabe »Rollen für den Betrieb« ist deshalb bereits aus
der Projektsicht zu lösen, diese muss die Lösung der Gestaltungsaufgabe
»Betrieb« einbeziehen bzw. unterstützen. Der Administrator hat seine Arbeit
schon mit dem Aufbau, also schon während des Projekts, aufgenommen. Sys-
temanalyse ist immer wieder erforderlich, wenn neue Anwenderanforderungen
erhoben werden müssen. Optimal ist deshalb der Einsatz von Systemanalyti-
kern, die bereits bei der Entstehung des DWH, also im DWH- Projekt, mitge-
wirkt haben.
344 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System
Auch die Rollen des Betriebes folgen einer sinnvollen Reihenfolge ihrer Ein-
richtung bzw. Übernahme aus den Rollen des Aufbauprojekts. Dies soll die fol-
gende Abbildung noch einmal belegen.
Großunter
Kleinfirma Mittelstand
nehmen
Geschäftsführung GF GF
GF
GF
Informatik- IM
management
IM IM IM
DM
DWH-Management DM DM DM
Fachbetreuung FB FB
FB
FB SA
Systemanalyse SA SA
SA
PR
Programmierung PR PR
AD PR
AD
Administration AD AD
Rollenwechsel
Dem Rollenwechsel oder Rollenübergang gebührt im Anschluss der Darstel-
lung aller Rollen noch einmal besondere Beachtung. Um das Verständnis für
den Rollenübergang während des Lebenszyklus eines DWH zu stützen und die
Gestaltungsentscheidung in Richtung Rollenwechsel zu fördern, ist ein Rollen-
wechselmuster in der folgenden Tabelle dargestellt. Der Inhalt der Tabelle ist
nur als Vorschlag zu verstehen und der unternehmensspezifischen Situation
entsprechend anzupassen.
Im Anschluss an die Tabelle »Rollenwechsel« folgt als bereits bekannte Gestal-
tungshilfe wieder die Verfahrensübersicht.
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 345
Lebensab-
schnitt
Aufbau Betrieb Abbau
Rollen
Rolle Aufbau-Projektleitung DWH-Manager Abbau-Projektleitung
Aufgaben Berichtwesen, Koordination Berichten Berichten, Koordination
Konzeptionsrahmen Technologieentscheidung
Beschaffungsentscheidung Anpassungsentscheidung Abschaffungsentscheidung
Staffing Staffing Staffing
Know-how-Sicherung Know-how-Sicherung Know-how-Sicherung
Rolle Case-Management
Aufgaben Case-Koordination
ring entdeckten Produkte müssen auf ihre Nützlichkeit beurteilt werden. Hier-
für ist eine Kriterienliste erforderlich. Für Marktmonitoring und Zusammen-
stellen der Kriterienliste sind je nach Produkt
✔ der DWH-Systemanalytiker für Entwurfswerkzeuge
✔ der DWH-Programmierer für Entwicklungswerkzeuge
✔ der DWH-Administrator für Systemmanagementwerkzeuge und Hardware-
komponenten
zuständig.
Bei Interesse wird eine Produktpräsentation und ein Test arrangiert. Bei positi-
vem Ergebnis wird ein Änderungsprojekt definiert und budgetiert. Die Ent-
scheidung einer Umorientierung trifft der DWH-Manager.
Für Releasewechsel ist ein Änderungszyklus einzurichten. Der Änderungszyk-
lus läuft, bezüglich Aufwand und Terminierung, im Prinzip genau wie die Neu-
entwicklung ab, nur in einem anderen Maßstab.
Prozess: Benutzerbetreuung und Aufrechterhaltung der Systemverfügbarkeit
Zur Sicherstellung der Verfügbarkeit gehört auch die ständige Verbesserung
und Pflege des Systems. Hierzu müssen alle Komponenten wie Einzelgeräte
und Software der Benutzer von PC-Betreuern gepflegt werden. Die Benutzerbe-
treuung der DWH-Systeme ist lediglich in die bereits vorhandene Benutzerbe-
treuung zu integrieren und erfordert keine besonderen DWH-spezifischen pro-
zeduralen Änderungen.
Die Benutzerbetreuung umfasst dabei eher die Endgeräte wie Drucker, Scanner
und PCs, und die Systemverfügbarkeit wird eher von den Systemadministrato-
ren und LAN-WAN-Spezialisten beobachtet und sichergestellt. Die Systemadmi-
nistration beobachtet aktiv und kontinuierlich, also ohne eine Nachfrage durch
Benutzer.
Für die Nachfragen von Benutzern ist in der Regel ein Call- Center oder ein
Helpdesk eingerichtet. Dieser nimmt die Benutzernachfragen und auch die
Beschwerden entgegen, klassifiziert sie und leitet sie an die zuständige Unter-
stützungsgruppe, LAN, WAN, Task Force für schnelle Vorort-Einsätze, PC-Sup-
port oder Fachbetreuer weiter. Entweder ist die Klassifizierung richtig erkannt,
dann werden die benachrichtigten Spezialisten das Problem lösen, oder der
beauftragte Spezialist stellt fest, dass ein anderer Spezialist zuständig ist. In die-
sem Fall gibt er die Beauftragung an den Helpdesk zurück. Der Helpdesk teilt
dann den richtigen Spezialisten ein. Nach Behebung der Störung melden die
Spezialisten die Beendigung ihrer Arbeit und der Helpdesk schließt den Call.
Können die Spezialisten des Supports das Problem nicht lösen, werden die Her-
steller oder externe Supportunternehmen beauftragt.
Die Vorfälle, Einsätze und Erkenntnisse des Supports werden in Datenbanken
protokolliert. Aus den Protokollen werden statistische Auswertungen gewonnen.
Diese statistischen Auswertungen werden auf Verbesserungsmöglichkeiten wie
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 347
Stellenspezifische DWH-Anforderungen
Für die Darstellung der stellenspezifischen DWH-Anforderungen ist eine Über-
sicht interessant, die Liste stellenspezifische DWH-Anforderungen Betrieb
(Tabelle 6.10), in der speziell auf das DWH bezogene Aufgaben der Rollen auf-
geführt sind, auch wenn sie keine reinen DWH-Rollen sind.
Ein DWH zu bauen ist eine umfassende Entscheidung, die Hardware, Soft-
ware, betriebswirtschaftliche Funktionen und Organisationsstruktur bewegt.
Mit einem DWH wird eine Zwischenschicht in die bestehende IT-Struktur
eingebaut mit neuen Funktionen und neuen Möglichkeiten der Erkenntnis-
gewinnung. Ein DWH zu bauen ist eine IT-Strategiemaßnahme.
Die Abbildung 6.11 zeigt die Integration des IT-Managements in das Unter-
nehmensmanagement. Sie zeigt auch, dass der Managementzyklus (Füh-
rungsprozess) des Unternehmens sich im Managementzyklus der IT wider-
spiegelt. Und die Abbildung zeigt, dass die IT-Gestaltungsentscheidungen
aus der IT-Strategie resultieren und im Anschluss an diese Gestaltungsent-
scheidungen die Umsetzung folgt. Aus der Unternehmensstrategie folgt ein
Unternehmensplan, der Vorgaben für die Planung der IT macht.
Der Unternehmensplan enthält Budgets, Ecktermine und Leistungsziele.
Das bedeutet, die Umsetzung der IT-Strategie ist entsprechend der Unter-
nehmensplanung zu terminieren. Sie muss sich im Kostenrahmen bewegen
und die Erreichung der Leistungsziele unterstützen. Die Umsetzung wird in
einem IT-Plan fixiert, der wiederum die Basis für ein IT-Controlling ist.
Neben dieser soeben dargestellten vertikalen Logik von Entscheidungs-
Abstimmungen steht noch eine horizontale Logik von Entscheidungs-
Abstimmungen. So greift die Umsetzung der IT-Planung z.B. durch Verlegen
von Kabeln, Aufstellen von PCs, Durchführung von Trainingsmaßnahmen
massiv in den Arbeitsablauf des Unternehmens ein. Die betroffenen Bereiche
sind zu informieren, und die Störung ihres Arbeitsrhythmuses ist unbedingt
zu minimieren, um die Produktion und die Erwirtschaftung des geplanten
Umsatzes nicht zu gefährden.
Umgekehrt muss die IT-Organisation den Umsetzungsmaßnahmen der pro-
duktiven Bereiche unmittelbar mit IT-Maßnahmen folgen, um deren Pro-
duktionsprozess schnellstmöglich zu unterstützen. Auch hier sind bei Hand-
lungsverzug des IT-Bereiches Umsatzeinbußen die Folge.
Ganz analog muss die IT-Strategie mit den Einzelstrategien der Bereiche,
z.B. Produktion, Controlling, Marketing, abgestimmt werden.
Die IT-Planung muss mit der Planung der Bereiche abgestimmt werden. Die
Gestaltungsprämissen der IT müssen mit den Anforderungen aus den Gestal-
tungsentscheidungen der Bereiche optimal zusammenpassen.
Letztendlich fügt sich das IT-Controlling in ein Berichtssystem aller Berei-
che ein. Das Controlling der IT liefert die Berichtsdaten im gleichen Zyklus
mit den gleichen Formatvorlagen wie das Controlling der Bereiche Marke-
ting, Produktion, Verwaltung.
352 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System
IT-Gestaltungs
Führungsprozess
kategorien
Anwendung Unternehmensplan
Ableitung Anforderung
Informatik-
Management
Software IT-Strategie des
Technologie Unternehmens
Ableitung
Ableitung
Gestaltung einer
IT-Lösung =IT-Plan
Hardtware
Technologie
Ableitung
Organisation Ableitung
Controlling der
Ableitung IT-Umsetzung
Methoden
Ableitung
Korrekturmaßnahmen
der IT-Gestaltung
Abschluß IT-Aufbau
= meßb. Ziel-Beitrag
An jedem Standort ist ein Server für die Verarbeitung von Instandhaltungs-
arbeiten installiert. Jeder Standort hat aus rechtlichen Gründen die Autorität
über seine Prozess- und Instandhaltungsdaten, aber jeder Standort stellt für
Auswertungen der Hauptverwaltung ein Replikat aller Instandhaltungsdaten
zur Verfügung. Folgende interne Rollen sind erforderlich:
✔ Schadensanalytiker mit Schadensbearbeitung. Für die Systemanalyse der
Schadensthematik und die Systemadministration von lokalen InDaWa-
Installationen werden die Schadensanalytiker speziell ausgebildet.
Prozesse
Berichtswesen: Die Ergebnisse der Schadensanalysen werden in den beste-
henden internen Standard-Jahresbetriebsreport der Kraftwerke aufgenom-
men mit folgenden Punkten: Schadensstatistik und Ursachenstatistik, Aus-
wertungen und Empfehlungen zu konstruktiven Verbesserungen,
Früherkennung, Lieferantenqualität, verbesserte Betriebsabläufe.
Analyseprozess: Der Ablauf der Analyse der Instandhaltungsdaten für Scha-
denserfassung, Klassifizierung, Aufbereitung und Versand, Beurteilung der
rückgegebenen Ergebnisse der Gesamtanalyse aller Kraftwerke auf die Ver-
wendbarkeit für das eigene Kraftwerk.
Anwenderbetreuung: Die Arbeitsplatzservicierung der InDaWa-Anwender
wird vom bestehenden Service-Team aufgenommen, die entsprechenden
Agenden werden erweitert.
Besprechungskreise
Der bestehende Besprechungskreis wird um das Thema Schadensanalyse
erweitert.
!"
Gestaltungsentscheidung
Im Folgenden sind wie in den vorgehenden Kapiteln auch, die Entscheidungen
zur Organisation, die im Musterprojekt »DWH für Energieversorger« getroffen
wurden, noch einmal im Überblick zusammengestellt.
ORIENTIERUNG
ARCHITEKTUR
Hardwarekomponenten
Organisationskomponenten
VORGEHENSMODELL
6.7 Übungen
Übung 6.1: Umwelt und Umfeld
Definieren Sie die Begriffe »Umwelt« und »Umfeld«.
Übung 6.2: Umweltdiagramm
Entwerfen Sie ein Umweltdiagramm Ihres Unternehmens.
Übung 6.3: Umfelddiagramm
Entwerfen Sie ein Umfelddiagramm Ihres geplanten DWH. Passen Sie das
Umfelddiagramm in das Umweltdiagramm der vorigen Übung ein und korrigie-
ren Sie fehlende und nicht übereinstimmende Austauschbeziehungen.
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 357
IT-Kategorie
Organisationsform
Systemtyp
Umfeld
Systemkompo-
nente
Organisations-
einheiten
Systemmodul
Rollen
Stellen
Funktionen
Kompetenzen
System-
IT-Kategorien System-Typen Module Funktionen
Komponenten
Ableitung
Strukturen Organisationstyp
temporär
Welche Lenkungsaus
Umfeld kontinuierlich
Fachabteilg
Organisations Strukturen periodisch
Projektteam
form Prozesse Quality Circle
mobil/stationär
Orga.Einheiten lokal/global
ARGE
Regelungen Coach
Infrastruktur Outsourcing Organisations-
Techn.Anlagen Konsortium faktoren
Tätigkeit
Aufgabenträger
Techn. Anlagen Objekt Aktivitätenart
Produktionsanlage Ausführungsort Information
Haustechnik Hilfsmittel Entscheidung
Verkehrsanlage Zeit Durchführung
Bedingungen Beauftragung........
Auslöser Planung
DWH-System Orga.Einheiten Führung
Infrastruktur Beschaffung
Ableitung Organisatsstruktr Teilgesellschaft Beistellung
Ressourcnsystm Niederlassung Rolle/Stelle Entwicklung
Bereich Produktion
Abteilung Projektleitung Lagerung
Gruppe Teilprojektleitung Lieferung
Stelle Projektassistenz
Projekt DWHAdministratn
DWH-Programmirg
Systemanalyse Rollenabgrenzung
Benutzung Rollenaufgaben
PC-Betreuung Kompetenz
Ressourcen- Vostandsponsorng Berichtsweg
Komponenten Case-Management Eingliederung
Vorprodukt Standort
Rohstoff
Betriebsmittel
Welche Werkzeug Ressourcen
Methoden Regelungen
Vorprodukt
Maschinen
Rohstoff
Ableitung Räume
Betriebsmittel
Informationen
Werkzeug
Energie
Welche Personal
Regelungen
Tools Maschinen
Räume
Informationen
Neue Phase
Spezifikationssphase der Data Energie
Warehouse Komponenten Personal
KAPITEL 7
7 Das Vorgehensmodell zum Aufbau von DWH-
Systemen
Überblick
Im Grunde genommen war alles, was in den vorherigen Kapiteln erarbeitet
wurde, methodisch. Es wurden nicht wirklich Rechner bestellt oder Software
ausgewählt. Es wurde vielmehr nach der richtigen Vorgehensweise bei der
Abwicklung der Schritte gesucht: von der Orientierung über die Auswahl von
Möglichkeiten und interessanten Lösungen bis hin zur Entscheidungsfindung.
Bisher ging es um die Frage, wie die Architektur der Hardware, Software oder
Organisation günstigerweise bestimmt wird. Es wurden Hilfsmittel und Beispiele
zur Durchführung dieser Bestimmung gegeben. Es wurde gesagt, wie die ersten
Schritte zum Aufbau eines DWH, die Definition erarbeitet wird. Dabei wurde in
einer Reihenfolge vorgegangen, die zwar Abweichungen und Alternativen zuließ,
aber doch immer einer inneren Logik folgte. Die Mittel, d.h. die Methoden, waren
bisher für die Findung von Entscheidungen sehr einfach. Sie beruhten auf Listen,
Tabellen, Matrizen, Gliederungen und Aufzählungen. Das liegt daran, dass meis-
tens nur eine Auswahl aus bekannten Tatsachen zu treffen ist.
Jetzt sind wir an einem Punkt angelangt, an dem nicht mehr nur noch ausge-
wählt werden kann, sondern komplexe Sachverhalte aufgelöst und wieder kom-
biniert, kurz entworfen werden müssen. Der Zeitpunkt ist gekommen, komple-
xere Zusammenhänge des Unternehmens abbilden zu müssen. Das Ergebnis
der Abbildung ist ein Modell. Wir betreten damit den abstrakten Bereich der
Modellierungsmethodik. Einen noch abstrakteren Schritt stellt die Zusammen-
stellung der Methoden zur Modellierung zu einem Modellierungsmodell dar.
Dieser nun anstehende Schritt ist wieder ein Gestaltungsprozess, nämlich der
Entwurf eines Methodenbündels, oder besser einer sinnvollen Methodenfolge,
die zu einem Modellierungsmodell kombiniert werden kann. Eine solche
Methodenfolge nennt man Vorgehensmodell.
Die Modellierung einer DWH-Lösung ist so umfangreich, dass sie in Phasen
abgewickelt wird. Am Ende einer Phase kann ein Ergebnis überprüft werden
und für weitere Entscheidungen und Ausräumung von Unsicherheiten dienen.
Es wird ausführlich auf jede einzelne Phase und ihre Ergebnisse eingegangen.
Ein Vorgehensmodell gibt an, in welcher Reihenfolge welche Schritte zum Ziel
eines Vorhabens durchlaufen werden müssen und welche Maßnahmen zu
ergreifen sind, um diese Schritte machen zu können. So ist zum Beispiel
Arbeitsmaterial erforderlich oder Informationen sind zu beschaffen, es muss
eine Personalakquisition und Personaleinstellung erfolgen. Das bestehende
362 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
Personal bedarf einer intensiven Ausbildung, um sich mit der neuen Wissens-
materie auseinandersetzen zu können.
Dementsprechend ist das Kapitel aufgebaut, wie die folgende Abbildung zeigt.
! !"
$
!
!
&
#!
%
!
&
Das Kapitel erklärt zunächst, was modellieren ist und was Vorgehensmodelle
sind. Im Anschluss daran wird ein umfassendes Vorgehensmodell aus bewähr-
ten Methoden für DWH-Vorhaben vorgestellt. Aus dem gesamten Methoden-
spektrum des DWH-Vorgehensmodells wird auf einen Ausschnitt, das Software-
entwicklungs-Vorgehensmodell (SWE-Vorgehensmodell), näher eingegangen.
Einige der Schritte im SWE-Vorgehensmodell sind schwierig und müssen
genauer besprochen werden. Dies sind die Erstellung eines Datenmodells, einer
Dialogstruktur, eines Funktionsbaumes, eines Kennzahlenschemas und eines
Aggregationsschemas. Ihnen wird jeweils ein Abschnitt gewidmet.
Lernziel
Ein fundamentales Gestaltungsobjekt ist das Vorgehensmodell des gesamten
DWH-Projektes mit seinen Phasen und Ergebnissen und sein Ausbau mittels
Methoden und Werkzeugen zu einem Verfahren. Den Schwerpunkt bildet das
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 363
Lernziel
Definieren der Begriffe Modell, Vorgehensmodell, Methode, Phasen
Darstellen
ten
eines Vorgehensmodells für die Abwicklung von DWH-Projek-
Nennung
Vorhaben
der Phasen mit ihren Ergebnissen zu einem komplexen DWH-
7.1.1 Modellierung
Modelle werden vorsorglich gebildet. Das heißt, wenn der sofortige Einstieg in
die Wirklichkeit zu teuer werden könnte, versucht man zuerst, an einem
Modell so viel Erfahrung zu sammeln, dass die Realisierung zielgerichtet und in
die richtige Richtung betrieben werden kann.
Die grundlegenden Eigenschaften von Modellen sind nach der Modelltheorie
von Stachowiak:
✔ Das Abbildungsmerkmal: Modellen liegt ein Original zugrunde, es gibt
einen Bezug zu einem Original, das Original wird vom Modell repräsentiert.
✔ Das Verkürzungsmerkmal: Ein Modell ist nie das Original selbst, sondern es
entsteht durch gedachtes Weglassen von Eigenschaften und Bestandteilen
aus dem Original. Ein Modell ist somit weniger als das Original.
✔ Das Pragmatikmerkmal: Ein Modell erfüllt einen Zweck, es wird angewen-
det oder verwendet, es wird für eine spezielle Verwendung und für Personen
zur Verwendung hergestellt.
Zum vertieften Studium einer wissenschaftlichen Darstellung des Modellierens
sei empfohlen:
Stachowiak, Allgemeine Modelltheorie
Der Modellierungsvorgang dient der Vereinfachung. Die Vereinfachung darf
aber nur das Unwesentliche ausschließen. Das für die weiteren Arbeiten
Wesentliche muss erhalten bleiben. Deshalb muss die Reduktion der Wirklich-
keit auf das Modell kontrolliert stattfinden. Der Modellierungsvorgang bzw. die
Regeln, nach denen das Modell erstellt wird, muss beschrieben werden. Die
Beschreibung ermöglicht die Überprüfbarkeit der Modellierung. Die Prüfung
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 365
stellt fest, ob das Ergebnis ein Modell ist, das das Objekt repräsentiert, oder ob
vielleicht objektfremde Eigenschaften dazugekommen sind.
➡ Die Modellierung eines Sachverhaltes oder eines Gegenstandes muss festge-
legte Regeln einhalten und die Regeln müssen kommunizierbar sein, d.h.
von vielen Modellierern verstanden werden können.
Die Beschreibung des Modellierungsweges ist auch ein Modell, und zwar ein
Modell zur Erstellung von Modellen. Ein Modell, das zur Erstellung von Model-
len genutzt wird, ist ein Metamodell.
Vorgehensmodell
Die Möglichkeit des Modellierens ist nicht auf reale Objekte eingeschränkt.
Modelliert werden können auch abstraktere Wesensheiten wie eine Planung
oder ein Vorgehen. Für die Modellierung eines Vorgehens werden alle Schritte
des umfassenden Vorgehens festgelegt, um ein Simulieren, ein geistiges Durch-
spielen oder auch nur ein Kommunizieren zu ermöglichen. Solch ein in einem
Modell festgehaltenes, modelliertes Vorgehen ist ein Vorgehensmodell, im
Gegensatz zum realen Vorgehen.
Mit einem Vorgehensmodell werden die zu durchlaufenden Phasen bestimmt
und festgelegt, was in einer Phase erzeugt werden soll. Die Definition der
Erzeugnisse und der Struktur ihrer Dokumentation nennt man Ergebnistypen.
Die den Ergebnistypen entsprechenden Ergebnisse kann man auf unterschied-
liche Weise darstellen. Für die Darstellung eines Ergebnisses gibt es Darstel-
lungsmethoden.
Die Ergebnisse der Anwendung einer ausgewählten Methode kann man auf
unterschiedliche Weise mit Software automatisieren. Zur Unterstützung der
automatisierten Erzeugung eines Phasenergebnisses können Tools eingesetzt
werden.
Das Vorgehensmodell richtet die Handlungen der Projektbeteiligten aus. Mit
dem Vorgehensmodell wird vereinbart, die gleichen Methoden und die gleichen
Werkzeuge für die gleichen Aufgaben einzusetzen. Selbst wenn die Werkzeuge
gleich sind, kann noch immer die Struktur der abgelegten Information unter-
schiedlich sein. Um die Ergebnisse zu einer Struktur zusammenführen zu kön-
nen, wird eine einheitliche Ergebnisstruktur verabredet.
366 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
Definition: Vorgehensmodell
Ein Vorgehensmodell ist eine Anleitung zur Abwicklung eines Vorhabens. In
einem Vorgehensmodell werden die Ergebnisse festgelegt (Ergebnistypen),
die Struktur der Ergebnisse und die Werkzeuge zur Dokumentation der
Ergebnisse oder zur automatischen Erzeugung von Teilen von Ergebnissen.
Der DWH-Spezialist kommt leider nicht immer mit Methoden der EDV-Ent-
wicklung aus: Er muss seine Daten aus einem bestehenden IT-Netz beziehen
und damit die dort gepflegte Sprache lernen.
Mit Hilfe oder unter Anleitung eines Vorgehensmodells werden weitere Modelle
geschaffen. Zum Beispiel ist die Beschreibung oder Spezifikation einer Software
ein Modell der angestrebten Software.
Das Vorhaben ist zu komplex, um es ohne Zwischenbetrachtungen und Über-
prüfung der Entscheidungen abzuwickeln. Das Ergebnis einer Einteilung eines
komplexen Projektes in kleinere, überschaubare Einheiten nennt man Phasen.
Phasen sind eine Zusammenstellung von definierten Ergebnissen oder Produk-
ten, die einen gewissen Abschluss einer Arbeit darstellen können. Am Ende
einer Phase steht die Überprüfung der Ergebnisse auf Übereinstimmung mit
den Vorgaben. Phasen werden also gebildet, um nicht erst am Ende eines Pro-
jektes vor vollendeten und mitunter unangenehmen Tatsachen zu stehen. Die
Überprüfung am Ende einer Phase dient dazu, den richtigen Kurs festzustellen,
oder bei neuen Erkenntnissen einen neuen Kurs zu definieren. Phasen sind
also auch eine Wissenskonsolidierung und Überprüfung.
Methoden dienen
✔ zur schnelleren Problemlösung
✔ zur Visualisierung, zur Verdeutlichung, Hervorhebung besonderer Merk-
male
✔ zur Kontrolle der Einhaltung von logischen Regeln, z.B. der Konsistenz,
Freihaltung von Widersprüchen, Aufdeckung von Lücken
✔ zur Reduktion komplexer Gebilde auf leichter zu handhabende Teilgebilde
Für ein und denselben Anwendungsbereich können oftmals mehrere Methoden
erforderlich werden. Für die Datenmodellierung z.B. können
✔ hierarchisches Modell
✔ relationales Modell
✔ objektorientriertes Modell
✔ vernetztes Modell
verwendet werden. Wenn die bestehenden Datenhaltungssysteme diese ver-
schiedenen Technologien verwendet haben, müssen die genannten Methoden
für die Formulierung eines Migrations- oder Replikationsabbildes angewendet
werden.
Genaugenommen handelt es sich bei der Aufzählung um Methodenklassen. Die
Methoden der einzelnen Klassen unterscheiden sich nicht mehr im Prinzip der
Abbildung und nicht im Abbildungsgegenstand. Zu jeder Methodik gehört eine
Symbolik. Die Methoden einer Klasse unterscheiden sich in der Symbolik und
im Umfang dessen, was vom Abbildungsgegenstand noch mit abgebildet wird.
7.1.2 DWH-Vorgehensmodell
Übersicht zum DWH-Vorgehensmodell
Ein DWH-Spezialist muss sich in dem Sinne mit Vorgehensmodellen auseinan-
dersetzen, dass er entweder ein bestehendes Modell lernt und anwendet oder
auf die Belange anpasst. Die folgenden Schritte ergeben, zu Phasen zusammen-
gefasst und in die richtige Reihenfolge gebracht, ein DWH-Vorgehensmodell.
Der Kern eines DWH ist ein aus mehreren Komponenten bestehendes Soft-
waresystem. Einige Komponenten können gekauft werden, andere Komponen-
ten wird der Markt nicht bieten. Sie müssen selbst entwickelt, d.h. entworfen
und programmiert werden. Wegen dieser hohen Bedeutung der Softwarekom-
ponenten muss der DWH-Spezialist Software spezifizieren können. Dazu hilft
ihm ein Softwareentwicklungsmodell. Im DWH-Vorgehensmodell ist deshalb
ein Softwareentwicklungs-Vorgehensmodell integriert.
368 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
1
!
'
!
#
!
3*"
(
)
+
*
+& /
''
7-
'(
8
)
%
3
/
3
5
6
0 6
$
# # "
#$ '0
0
"
+
3
1
"
%8"
"# # %#"
' %
&
.
0 2
3
! # 1
"
"#
#
+
$
./0 / "
'
,
-+
*
+ +
./0 /0 %
*
+
"
*
+!
"
*
+
!
03
Die Ovale stellen die Phasen dar, in die das gesamte DWH-Vorhaben eingeteilt
werden kann.
Die Vierecke stellen die Ergebnisse, die in den Phasen zu produzieren sind, dar.
Nicht jedes DWH-Vorhaben muss alle Phasen durchlaufen. Der Umfang des
Durchlaufs hängt von der Größe des Vorhabens und von den vorausgegangenen
Aktivitäten ab. So kann z.B. eine IT-Strategie schon völlig unabhängig vom
DWH-Vorhaben erarbeitet worden sein. Der Einstieg in den Phasendurchlauf
ist durch die Sterne, die Ereignisse, angedeutet. Am auslösenden Ereignis kann
man nicht nur die Startphase erkennen, man bekommt damit auch eine Vor-
stellung davon, was bereits an Vorarbeiten im Unternehmen entstanden sein
könnte. Deshalb handelt es sich um ein Vorgehensmodell.
➡ Abhängig von der »Einstiegsphase« in das DWH-Vorhaben müssen die zu
berücksichtigenden Konzepte und Ergebnisse anderer Phasen recherchiert
werden.
Ein Vorgehensmodell, das um die Hilfsmittel zur Sicherstellung der Methoden
erweitert wird, ist ein Verfahren.
Statusanalyse, Unternehmensanalyse, Umweltanalyse
Bevor sich ein Unternehmen strategisch ausrichtet, muss es Kenntnis gewin-
nen von seinen eigenen Fähigkeiten und dem Wettbewerb, dem es sich mit sei-
nen eigenen Fähigkeiten stellen will. Hierzu ist demnach eine Innenbetrach-
tung, die Unternehmensanalyse, und eine Außenbetrachtung, die
Umweltanalyse, vonnöten.
Die Innenbetrachtung des Unternehmens, die Betrachtung der Fähigkeiten,
kann mittels einer sogenannten »Stärken-Schwächen-Analyse« systematisch
durchgeführt werden. Diese Analyse wird von ausgewählten Mitarbeitern des
Unternehmens unter externer Moderation durchgeführt. Die einzelnen ausge-
machten Stärken und Schwächen werden nach einem Maßstab und abge-
stimmt unter allen Mitarbeitern in Relation zueinander bewertet. Die Bewer-
tung wird in einem Stärken-Schwächen-Profil dargestellt.
Die Außenbetrachtung des Unternehmens, die Betrachtung des Wettbewerbs,
kann mittels einer sogenannten »Risiken-Chancen-Analyse« systematisch
durchgeführt werden. Diese Analyse wird ebenfalls von den ausgewählten Mit-
arbeitern des Unternehmens unter externer Moderation durchgeführt. Die ein-
zelnen ausgemachten Risiken und Chancen werden nach einem Maßstab, abge-
stimmt unter allen Mitarbeitern, in Relation zueinander bewertet. Die
Bewertung wird in einem Risiken-Chancen-Profil dargestellt.
Eine kritische Analyse des Unternehmens und seiner Umwelt zeigt die Möglich-
keiten, die diese Fähigkeiten im Umfeld des Wettbewerbs bieten. Die Analyse
zeigt aber auch die Gefahren, die abzuwenden sind. Diese Möglichkeiten und
die Gefahren fordern Maßnahmen, die in einer Strategie ausformuliert werden.
370 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
!
Informatik-Strategiekonzeption
Die Unternehmens-Informatik (IT), die gesamte Infrastruktur und Organisa-
tion der EDV-Anlagen, erfüllt einen Beitrag zur Erreichung der Zielsetzung und
zur Durchsetzung der Strategien des Unternehmens. Deshalb muss sich die
Unternehmensstrategie in der IT-Strategiekonzeption fortsetzen. Die IT-Stra-
tegie richtet sich an der Unternehmensstrategie aus. Das DWH als Bestandteil
der Unternehmens-Informatik soll ebenfalls einen Beitrag zur Zielsetzung des
Unternehmens leisten. Für die zielgerechte Gestaltung des DWH muss deshalb
die Zielsetzung einbezogen werden. Die Gestaltung des DWH richtet sich an der
IT-Strategie und an der betriebswirtschaftlichen Unternehmensstrategie aus.
Die Zielsetzung eines Unternehmens und die IT-Strategie müssen vor Beginn
eines DWH-Vorhabens bekannt sein.
Die IT-Strategie muss sich wie die Unternehmensstrategie an äußeren, aus der
DWH-Umwelt kommenden Tendenzen ausrichten. Dies sind z.B. Technologie-
strömungen, neue Forschungsergebnisse und neu entwickelte Produktlinien
und Produktgenerationen.
Die Erzeugnisse der Phase Informatik-Strategiekonzeption sind:
✔ IT-Trendstudie für die Einschätzung der technologischen Trends und Pro-
dukttrends
✔ IT-Strategiestudie für die Unterstützung der unternehmerischen Zielset-
zung durch entsprechende IT-Infrastrukturen
Projektierung
In der IT-Strategie wurden zur Unternehmenszielsetzung beitragsrelevante IT-
Systeme und Konfigurationen erkannt. Am Bedarf an Systemen muss die Leis-
tung der vorhandenen Systeme gemessen werden. Sind die Systeme nicht mehr
bedarfsdeckend, ist die Ableitung eines Projekteportfolios von Projekten zur
Erneuerung der Systeme erforderlich. Die Projekte stehen in einem logischen,
zeitlichen und finanziellen Zusammenhang, der in einer Projektplanung oder
Projektierung sichtbar gemacht wird. Sowohl die Kapazität als auch die Kosten
werden die Anzahl auf die sofort bzw. gleichzeitig durchführbaren Projekte
reduzieren. Es wird dabei mit den Projekten gestartet, die mit geringsten Kos-
ten den höchsten Nutzen bringen, sogenannte A-Projekte. Als terminlich
zweitrangig werden die B-Projekte eingeordnet. Die sogenannten C-Projekte
verschwinden meistens wieder aus dem Portfolio, da das Unternehmen mit der
Abwicklung der A- und B-Projekte meistens so lange ausgelastet ist, dass die C-
Projekte von der Entstehung neuer A-Projekte verdrängt werden.
klein A A B
mittel A B C
hoch B C C
Konzeption
Die Konzeption ist die Beschreibung der Anforderungen des Anwenders an eine
Lösung für eine seiner betriebswirtschaftlichen Aufgabenstellungen in seiner
Fachsprache. Die Darstellung ist mit den Ausdrucksmitteln des Fachanwenders
formuliert, also verbal, mit Formeln, mit Ablaufschaubildern und Formularen.
Um von einem Programmierer realisiert werden zu können, bedarf es noch
einer Umsetzung in eine DV-Sprache. Welche Sprache das ist, hängt von der
grundsätzlichen Modellklasse ab.
Der DWH-Spezialist muss zunächst den für sein DWH relevanten Wertaus-
schnitt definieren. Er muss bewusst erfassen, welche Umweltsysteme das DWH
beeinflussen und welche Umfeldbedingungen den Rahmen für seine Gestaltun-
gen liefern.
Steht dieser Kontext fest, sind die zu unterstützenden Unternehmensprozesse
neu zu definieren, oder, soweit diese bereits bestehen, zu erfassen. Der DWH-
Spezialist muss Prozessdiagramme erstellen. Aus diesen Prozessen und deren
Aktivitäten werden Funktionen für die EDV-Systeme im Allgemeinen und für
das DWH im Speziellen abgeleitet.
Vollständig erfasste Prozesse enthalten auch die Informationen, die das DWH
managen soll. Die Informationen sind z.T. in Datenbanken vorhanden. Hier
muss der DWH-Spezialist bestehende Datenbankschemata benennen können.
Die Ergebnisse der Konzeption sind:
✔ Abgrenzung des Themenfeldes durch eine Kontextdefinition des Unterneh-
mens in der Umwelt und den Kontext des DWH-Systems im Umfeld
✔ Prozessuale Anforderungen mittels der Darstellung der Geschäftsfelder,
Organisationsstruktur, Aufgabenbeschreibungen, Stellenpläne, Abläufe und
Formularwege
✔ Informative Anforderungen mittels der Nennung von Informationsträgern
wie Formulare, Datenbanken (Struktur und Inhalte), Richtlinien, Vorschrif-
ten
✔ Funktionale Anforderungen an Software und Hardware
✔ Hardware- und Infrastrukturanforderungen wie zu verarbeitende Mengen,
Verbindungen und Zugriffe, Lokationsverteilungen
Entwurf
In der Phase Entwurf sind keine betriebswirtschaftlichen Entwürfe zu erstel-
len, sie bezieht sich nur auf IT-Aufgaben. Die betriebswirtschaftlichen Entwürfe
müssen bereits vor der Konzeption der DWH-Lösung feststehen. Sie sind die
Fortsetzung der Unternehmensstrategie. Die betriebswirtschaftliche Entwurfs-
arbeit ist nicht die Aufgabe der DWH-Spezialisten.
374 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
Die Modellierung mit relationalen Modellen hat ihre Stärken im Entwurf red-
undanzfreier Rohdaten. Das DWH hat die Funktion, auf deren Fundament diese
Rohdatenverdichtungen und -zusammenhänge zu definieren. Eine Besonder-
heit der DWH-Applikationen sind die Datenverdichtungen. Hierfür sind spezi-
elle Diagramme für die Aggregation von Rohdaten und die Kennzahlenermitt-
lung zu entwerfen.
Da Daten und Funktionen aus verschiedenen Systemen verknüpft und aufein-
ander abgebildet werden müssen, gewinnt das Thema Metamodellierung an
Bedeutung. Das betrifft die Daten selbst, ihre Struktur, ihren Strukturtyp und
ihre Lokation, also den Standort der Rechner der Datenbanken.
Um die Daten einem Metamodell entsprechend auf einem Rechner zu hinterle-
gen, ist ein Migrationsplan erforderlich. Ein Migrationsplan muss zum Beispiel
die Datenstrukturen der verschiedenen Datenquellen, die in unterschiedlichen
Modellstrukturen organisiert sind, vereinen.
Zum Inhalt des DWH-Entwurfes gehören deshalb auch:
✔ Aggregationsdiagramme, Sternschemata und Multiwürfel, Snowflake-Dia-
gramme
✔ Kennzahlenschemata
✔ Datenmetamodelle
✔ Migrationsplan
Für die weitere Beschäftigung mit dem Thema DWH-Entwurf aus Software-
sicht ist zu empfehlen:
Inmon, Building
Kimball, Toolkit
Realisierung
Die Phase Realisierung ist die Umsetzung der Lösung bis zur Implementie-
rungsreife auf einer Betriebsplattform aus Hardwareumgebung, Betriebssystem
und Netz. Hierzu ist die Herstellung und Beschaffung der Software, die
Beschaffung der Hardware und die Vorbereitung der Organisation durch Aus-
bildung und Personalbeschaffung zu rechnen.
Die Software wird mittels Programmierwerkzeugen, die erst evaluiert und dann
beschafft werden müssen, hergestellt. Die Herstellung wird in zwei Schritten
vollzogen: Programmierung und Zusammenführung der wiederverwendbaren
Komponenten und Produktion der eigentlichen Applikation.
Vor der Anwendungsrealisierung sind die wiederverwendbaren Komponenten,
das sind in erster Linie die Komponenten, die für die Programmsteuerung zur
Konsistenzhaltung, die Sicherungsorganisation, die Pflege und Konfiguration
wichtig sind, zu erzeugen. Im Einzelnen handelt es sich hierbei z.B. um:
376 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
Implementierung
Die Implementierung ist die Integration der fertiggestellten DWH-Lösung in
das EDV-System. Das heißt im Einzelnen:
✔ die Anbindung der beschafften und der selbst programmierten Software
über die Schnittstellen an die vorhandene Software,
✔ die Aufstellung der Hardware vor Ort und Verbindung der neuen Hardware
mit der bestehenden Hardware über Netze und Verkabelung,
✔ die Integration des neuen Personals und der neuen organisatorischen
Abläufe in die bestehende und bereits ablaufende Organisation.
Das Hauptproblem hierbei ist die unterbrechungsfreie Integration und die stö-
rungsfreie Durchführung. Das heißt, die Einbettung in das bestehende und lau-
fende System soll, ohne dessen Ablauf zu stören, zu unterbrechen oder
schlimmstenfalls sogar lahmzulegen, durchgeführt werden. Integration oder
Implementierung wird deshalb vorher getestet und schrittweise kontrolliert
durchgeführt. Die besten Zeiträume hierfür sind die betriebsarmen Nachtzeiten
und die Wochenenden.
Die Integration findet in den zwei Organisationbereichen »Unternehmensorga-
nisation« und »Systemorganisation« statt. Die Integration in die Unterneh-
mensorganisation erfordert
✔ Umstellung der betriebswirtschaftlichen Arbeitsabläufe
✔ Strukturintegration der für die DWH-Nutzung qualifizierten Anwender
✔ Veränderung der Datensicherheitslage bezüglich des Anwenderzugriffs
✔ Änderung unternehmensorganisatorischer Richtlinien
Die Integration in die Systemorganisation erfordert
✔ Portierung auf Betriebsumgebung, Betriebssystemwechsel, Bedienerober-
flächenwechsel
✔ Prozedurale Anbindung
✔ Datenmigration
✔ Änderung EDV-betriebsorganisatorischer Richtlinien
✔ Integration der für den DWH-Betrieb qualifizierten Betreuer und Administ-
ratoren
Die Ergebnisse der Phase Implementierung sind:
✔ installierte Hardwaresysteme und Netzanbindungen
✔ lauffähige, ausgetestete, auf dem Hardwaresystem installierte Softwarekom-
ponenten mit neuen Daten und Zugriffen auf bestehende Datenpools
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 379
Metamodell
Genau wie ein System, ob Software oder Hardware, zum besseren Verständnis
beschrieben werden muss, ist auch ein Vorgehensmodell zu beschreiben. Eine
Form der Beschreibung eines Vorgehensmodells ist das Metamodell. Ein Meta-
modell wird gewöhnlich aus der datenorientierten Sicht, also als Datenmodell
dargestellt, um die strukturierte Ablage der Ergebnisse in einer Datenbank zu
ermöglichen. Liegt einem CASE-Tool eine relationale Datenbank zugrunde, ist
das Metamodell das Datenbankschema des CASE-Tools.
Wo in der Vergangenheit dem relationalen Modell zur Beschreibung von Meta-
modellen der Vorzug gegeben wurde, erfreuen sich neuerdings Objektmodelle
zunehmender Beliebtheit. Hier soll der einfacheren Lesbarkeit halber und den
relationalen Datenbanken zuliebe ein Blick auf ein vereinfachtes Metamodell
für das hier vorgestellte Verfahrens- und Vorgehensmodell geworfen werden.
Das Diagramm ist, wie noch in der Beschreibung der Aktivität »Informations-
objekte-Modellierung« in der Phase »Konzeption« erklärt wird, eine Darstel-
lung von Kern-Datenbanktabellen mit ihren Verbindungen über Schlüssel-
werte.
Ein vereinfachtes Kernmodell der Informationsobjekte des DWH-Gestaltungs-
verfahrens zeigt die folgende Abbildung »Kernmodell DWH-Gestaltungsverfah-
ren«.
Das Kernmodell hilft bei der Definition des Vorgehensmodells. Man liest die
Grafik von oben: Zuerst wird das Projekt definiert und danach die Aufteilung in
Teilprojekte. Zu den Teilprojekten werden die Ergebnisse festgelegt. Ausgehend
von den Ergebnissen werden die Methoden definiert, mit denen die Ergebnisse
zu erzeugen sind. Zu den Methoden werden die Tools festgelegt, mit denen die
Ergebnisse zu erzeugen bzw. zu dokumentieren sind.
Make or Buy
Natürlich hat auch hier der Markt wieder einiges zu bieten, so dass man es sich
doch wieder einfach machen kann, indem man lediglich aus angebotenen
Methoden auswählt. Die Make-or-Buy-Frage ist zu lösen. Man muss Methoden
nicht immer neu entwerfen. Man kann fertige Methoden auswählen und als
Softwarelösung kaufen. Doch ist auch das kompliziert, da sich die Methoden
gegenseitig Daten zuliefern müssen, um ein sinnvolles Zusammenspiel zu
gewährleisten und keine Lücken zu lassen. Man kann sogar fertige Modelle, die
nahezu komplett sind, auswählen und als Softwarelösung kaufen, doch muss
man ihren Einsatz sehr wohl verstehen.
Aus der Erkenntnis dieser Ereignisse heraus und durch das Wissen über ihre
Ergebnisse und ihre Konsequenzen kann der DWH-Spezialist die Auswirkun-
gen bzw. die Voraussetzungen und das Nutzungspotential für sein DWH-Projekt
einschätzen und entsprechende Nutzungsmaßnahmen planen.
In den relevanten Bereichen des Unternehmens und auch zwischen den Berei-
chen werden die zu unterstützenden betriebswirtschaftlichen Prozesse ausge-
macht und in Ablaufdiagrammen, auch Prozessdiagramme genannt, aufge-
zeichnet. Zu jedem Prozess werden die Aktivitäten auf ihre Unterstützbarkeit
durch DV untersucht. Diese Aktivitäten sind die potentiellen Kandidaten für
Softwarefunktionen, also für die Automatisierung.
Der in den Fachaufgaben zu bewältigende Informationsumfang wird aus den
Dokumenten und Formularen ermittelt, die bei der ablauforganisatorischen
Analyse recherchiert wurden.
Gemäß den als DV-unterstützbar bewerteten Aktivitäten werden Funktionen
des betreuenden Systems benannt. Diese Funktionen werden dann mittels
eines Funktionenbaums geordnet, ergänzt, auf wiederholtes Vorkommen hin
untersucht und im Wiederholungsfall ausgelassen. Damit ist der fachliche
Funktionsumfang des Systems festgestellt. Speziell für DWH-Anwendungen
werden die Funktionen zu der Darstellung von Zahlenmaterial als Kennzahlen-
schemata und als Aggregationsdiagramme sowie die Navigation in diesen
Datenmengen in den Funktionsumfang aufgenommen.
Die Informationen werden in Objekttypen (Informationengruppen, Tabellen)
zerlegt und eventuell normalisiert, bis ein Datenmodell mit einer gut verwalt-
baren Feinheit vorliegt. Aus den Ursprungsdaten des Datenmodells werden spe-
ziell für DWH-Anwendungen Datenverdichtungen in Form von Aggregations-
digrammen abgeleitet. Für die Erzeugung von Zahlenverknüpfungen werden
Kennzahlendiagramme für die Weiterverarbeitung abgeleitet.
Mit Hilfe einer Dialogstruktur werden die Objekttypen der Informationen zu
Masken organisiert bzw. zusammengestellt. Die Daten des Datenmodells wer-
den gemäß den ermittelten Formularen zu Masken zusammengestellt. Den
Masken des Programmsystems wird die Funktionalität gemäß der Analyse der
Aktivitäten zugeordnet. Dann werden die Masken gemäß der Aktivitätenfolge
aus der ablauforganisatorischen Analyse zu Maskenfolgen, sogenannten Dialo-
gen, zusammengestellt. Ein Dialog ist dann eine Funktionenfolge aus Funktio-
nen des Funktionenbaums, entsprechend der Aktivitätenfolge der Ablaufana-
lyse.
An dieser Stelle der Entwicklung ist ein Prototyping des zukünftigen Program-
mes, also die Generierung von Masken mit Inhalten und Aufruffolgen sinnvoll,
da der minimale Maskeninhalt zu diesem Zeitpunkt vorliegt.
Zusammengefasst ergeben sich folgende Entwicklungsschritte und Entwick-
lungsprodukte im Laufe der Konzeption und des Entwurfes der DWH-Software:
✔ Fachlicher äußerer Kontext, fachlicher innerer Kontext und Einbettung in
die Unternehmensumgebung nach Systemen, Software und Institutionen
Ergebnis: Kontextdiagramm
✔ Fachliche Aufteilung des zukünftigen Softwaresystems
Ergebnis: Moduldiagramm
390 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
Da die Aktivitäten auf Daten ausgerichtet waren, ist dieser Bezug auch für die
Funktionen da. Funktionen verarbeiten Daten. Die Daten und Funktionen wer-
den in einem dialogorientierten Programm in Form von Masken realisiert. Die
Daten werden durch Felder repräsentiert, die Funktionen durch Maskenmenüs
und Tastatureingaben.
Die Abfolge der Funktionen muss dem logischen Arbeitsablauf entsprechen, so
wie er durch die Prozesse dargestellt wurde. Die Aktivitätenfolgen gehen dem-
nach in Funktionenfolgen und im Falle der Dialogprogramme in Maskenfolgen
und Feldfolgen innerhalb einer Maske über.
Datenmodellierung
Aggregations- und Kennzahlenmodellierung
Funktionsmodell
Objektmodell
Dialogmodellierung
❖ Feststellen des Unternehmenspotentials an Vorgehensmodellen, Metho-
den, Tools
❖ Entscheidung über den Einsatz von Tools speziell für
CASE-Tools
grafische Ergänzungstools
Textdokumentgeneratoren
Testgeneratoren
❖ Evaluation bekannter Vorgehensmodelle und Beurteilung ihrer Anwend-
barkeit in der Firma
❖ Schätzung des Aufwandes für Anpassungsarbeiten bzw. Neuentwicklung
eines Vorgehensmodells
❖ Einsatz des Vorgehensmodells nach Feststellen des Einstiegszeitpunktes
varianten zu einer »großen« integrierten Lösung ebenfalls vollzogen ist. Das ist
z.B. beim Organisationskonzept der Fall, wenn die DWH-Aufgaben zu DWH-
Rollen und die DWH-Rollen zu DWH-Stellen zusammengeführt werden und die
DWH-Stellen in das Unternehmensstellensystem integriert sind.
Die Beschreibung eines Konzeptes ist in der Fachsprache des Anwenders
erstellt. Sie ist überwiegend verbal, mit Formeln oder auch mit Ablaufschaubil-
dern und Formularen ergänzt. Das DWH-Konzept erfordert eine Umsetzung in
eine DV-Sprache, um von Programmierern, Organisatoren und Hardwareliefe-
ranten umgesetzt werden zu können. Welche Sprache das ist, hängt grundsätz-
lich vom Gestaltungsobjekt ab. Die Hardware wird anders beschrieben als die
Software.
Die Kontextanalyse
Die Kontextanalyse sucht nach den Außenbindungen des DWH. Diese Bindun-
gen können einmal im Unternehmen selbst und auch außerhalb des Unterneh-
mens gefunden werden. Die Kontextanalyse wird demnach in zwei Kontexten
vollzogen:
✔ Umweltkontext des Unternehmens
✔ Umfeldkontext des DWH im Unternehmen
Das Ergebnis der Kontextanalyse sind zwei Diagramme mit Systemen, Instituti-
onen, Maschinen oder Einflussfeldern auf das Betreiben eines DWH:
✔ Umweltblockdiagramm oder Umweltkontextdiagramm
✔ Umfeldkontextdiagramm
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 395
Für die Darstellung des Kontextes sind die folgenden Symbole nötig:
✔ System-Boxen für die Institutionen und Systeme
✔ System-Abgrenzungspolygone zur Aus- bzw. Eingrenzung der relevanten
externen Institutionen und Umweltsysteme gegen die internen Umfeldsys-
teme und diese gegen bestehende Softwaresysteme
✔ System-Beziehungslinien, wenn die zwischen den Institutionen und Syste-
men bestehenden Wechselwirkungen dargestellt werden sollen
Bei besonders komplizierten Sachverhalten empfiehlt es sich, die Blöcke im
Kontextdiagramm weiter zu zerlegen. Das Ergebnis ist eine hierarchische Glie-
derung von Kontextdiagrammen. Da nicht in jeder Ebene der Gliederung alle
Einheiten interessant sind, kann man auf unterster Ebene der Zerlegung eine
Zusammenstellung ausschließlich der relevanten Einheiten darstellen.
Die Kontextelemente sind die Basis für die prozessuale Analyse. Die Prozesse
laufen zwischen den ausgewählten Einheiten (Systeme) des Kontextes ab. Die
innerhalb der ausgegrenzten Systeme des Kontextes ablaufenden Prozesse sind
nicht weiter zu betrachten.
396 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
&''
#
!
"# $%
!
Die Businessprozessanalyse
Bevor die Businessprozessanalyse durchgeführt werden kann, müssen die
Unternehmensbereiche ausgemacht werden, die von den interessierenden Pro-
zessen betroffen sind. Die Prozessanalyse startet also mit einer Bereichsabgren-
zung.
Nach der Bereichsabgrenzung werden zunächst die komplett innerhalb der
Bereiche liegenden Prozesse definiert, die zu untersuchen sind. Danach werden
die zwischen den Bereichen des Unternehmen wirkenden Prozesse erfasst und
danach die teilweise außerhalb des Unternehmens ablaufenden Prozesse. Dabei
werden auch die Schnittstellen zu den nicht betrachteten Prozessen definiert.
Beispiel: Kraftwerksbereiche
Die Bereiche des Kraftwerksbetriebs sind
✔ Produktion: verantwortlich für die Stromerzeugung
✔ Instandhaltung: verantwortlich für die Erhaltung der Systeme und der
Betriebsfähigkeit
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 397
Abbildung 7.9: Bereiche des Kraftwerksunternehmens
398 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
Beispiel: Schadensanalyseprozess
Der Schadensanalyseprozess ist in den Gesamtprozess der Stromerzeugung
und den Instandhaltungsprozess integriert.
Ausgelöst wird ein Schaden durch einfachen Verschleiß, Schlechtlieferung,
Dauerbelastung oder Lastwechsel. Der Schaden wird durch örtliche Bege-
hung oder durch Anzeige von Messinstrumenten erkannt.
Der Prozess einer Schadensanalyse beginnt mit der Erfassung des Schadens
durch Besichtigung vor Ort. Ist der Schaden aus der Ortssicht erfasst, wird er
mit anderen Informationen aus dem System ergänzt.
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 399
$
%
&
!
" "
& #
#
#
Informationsbedarfsanalyse
Informationen sind, wie in Kapitel 6 »Organisation« dargestellt, Produktions-
faktoren. Es gibt Produktionsschritte, die nur mit Zulieferung von Informatio-
nen durchgeführt werden können. Zur Ausübung von Aktivitäten sind Informa-
tionen erforderlich, z.B. ein Startsignal oder eine Ausführungsanweisung mit
einer Schrittefolge. Einige Aktivitäten betreffen direkt die Verarbeitung von
Informationen zu anderen Informationen, wie z.B. die Addition von Zahlen.
Die Informationen können auch direkt, d.h. losgelöst von ihrer funktionalen
Verwendung, erhoben werden. Die Informationsbedarfsanalyse ist die Erhe-
bung und Beurteilung der informationellen Anforderungen an das DWH-Soft-
waresystem.
Die Informationen werden über Informationsobjekte erfasst. Informationsob-
jekte sind Träger von Informationen und Informationsgruppen, wie Tabellen,
Formulare, Berichte, Listen, Bilder, Fotografien, Tonaufzeichnungen, Video-
filme.
Die Informationsobjekte können in ihrer Beziehung zueinander analysiert wer-
den. Eine Beziehung ist z.B. gegeben, wenn das eine Informationsobjekt sich
aus anderen Informationen oder Teilen von ihnen zusammensetzt. Informati-
onsobjekte können sinnvoll gruppiert werden, z.B. nach einem Sachbezug.
Informationen können auch hierarchisch strukturiert werden. Ein Beispiel
hierfür ist die Beziehung des Enthaltenseins.
Das Informationsobjektemodell ist eine grafische Darstellung von Informati-
onsobjekten wie Tabellen, Sheets, Dokumente, Signalgeber zusammen mit den
Strukturen der dort dargestellten Informationen.
Das Berichteschema ist eine grafische Darstellung von Berichten und Doku-
menten zusammen mit den Strukturen der dort enthaltenen Informationen
und Verbindungslinien zur Darstellung der Informationsbeziehungen der
Berichte.
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 401
!
Instandhaltungsempfehlungen
✔ Instandhaltungsauftrag
Instandhaltungsanweisung an Personal mit Material, Qualifikation, Vorberei-
tungsmaßnahmen, Hilfsmittel
✔ Expertisen
Instandhaltungsmaßnahmen an Systemen, Vorratsmengen, Materialgüte,
Lieferantengüte
Die hier abgeleiteten und aufgelisteten Informationen sind ein Ausschnitt
aus dem Informationsbedarf für eine Schadensanalyse.
"
*#
"
%&#
%#
#
, *
- $# '''
"
)
%&# )
%#
. %
#
,
Aus der Informationsbedarfsanalyse, d.h. aus der Analyse, die den Bedarf an
Informationen für die Durchführung von Aktivitäten ermittelt, werden auch
Funktionsbedarfe gewonnen. Deshalb kann die Informationsbedarfsanalyse
auch vor der Funktionsbedarfsanalyse durchgeführt werden.
Die Funktionsbedarfsanalyse
Die Aufgaben und die Teilaufgaben, welche durch die geplante Software durch-
geführt werden sollen, sind die Funktionen der Software. Damit müssen die
Funktionen der Software mit den Aktivitäten der Prozesse abgestimmt werden.
Hier gibt es folgende Beziehungen:
✔ Eine Funktion ist schon eine Aktion als eine Position in einem Prozess
✔ Eine Funktion ist Teil einer Aktion
✔ Eine Funktion umfasst mehrere Aktivitäten, vielleicht sogar einen komplet-
ten Ablauf
In allen drei Fällen wird die Funktion aus den Aktivitäten der Prozesse in der
Funktionsbedarfsanalyse zu einem Funktionsbedarf abgeleitet. Der Bedarf wird
in vier Stufen konzipiert. Zunächst wird festgestellt, welcher Funktionsbedarf
besteht. Der Bedarf wird mit der bereits vorhandenen Funktionsversorgung
verglichen. Die Differenz zwischen Bedarf und Versorgung wird dann als funk-
tionale Versorgungslücke, die zu schließen die Aufgabe des DWH-Spezialisten
ist, festgestellt. Der letzte Schritt besteht in der Erstellung des funktionalen
Konzepts. In der Zusammenfassung ergibt das folgende Schritte:
✔ Funktionsbedarf ➯ Funktionsversorgung ➯ Versorgungslücke ➯ Konzept-
vorgaben
Zur Ermittlung der Funktionen gibt es drei Wege:
✔ Direkte Aufnahme von erforderlichen Funktionen
✔ Ermittlung der Daten und Ableitung der Funktionen als Operationen auf
den Daten
✔ Erhebung der Prozesse und Ableitung der Funktionen aus den Aktivitäten
Das Ergebnis der Ermittlung des Funktionsbedarfs ist die Funktionenliste mit
einer Funktionsbeschreibung. Die Funktionenliste ist im ersten Arbeitsgang
unstrukturiert und wird in mehreren Arbeitsgängen in eine hierarchisch
gegliederte Struktur aus Unterfunktionen und Funktionsgruppen geordnet.
Dies ergibt als grafische Darstellung die Form eines Funktionsbaumes.
Das folgende Beispiel stellt die Funktionsliste und die folgende Abbildung den
Funktionsbaum der Schadensanalyse dar.
#
"
#
&
'
Das DWH-Softwarekonzept
Das DWH-Softwarekonzept umfasst alle technologischen Anforderungen,
Architekturanforderungen und Produktvorgaben an die Software. Dazu gehö-
ren z.B. die Vorgaben,
✔ auf welchen Betriebssystemen oder auf welcher Hardware die Software ein-
gesetzt werden soll,
✔ welche Form der Client-Server-Verteilung gewählt wird,
✔ welcher Programmiersprache der Vorzug gegeben wird,
✔ ob eine Standardlösung anstelle einer Eigenentwicklung bevorzugt wird,
✔ welche Produkte für die Entwicklung eingesetzt werden müssen.
Die Fragen zur Software-Architektur wurden als »Architekturbestandteil« in
Kapitel 4 »Softwarekomponenten« ausführlich dargestellt. Das Softwarekon-
zept ist die Zusammenfassung der Ergebnisse der dort behandelten Fragestel-
lungen. Das Softwarekonzept ist allerdings nicht nur eine Ergebnisdarstellung,
sondern ebenfalls eine nachvollziehbare Darstellung der Ergebnisfindung. D.h.
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 407
Definition: Softwarekonzept
Das Softwarekonzept ist die Zusammenstellung der Anforderungen an die
Software-Architektur und die Architektur der Softwareentwicklungstools
zusammen mit einer Lösungsbeschreibung aus der Sicht der Fachanwender.
Das DWH-Hardwarekonzept
Das DWH-Hardwarekonzept umfasst alle technologischen Anforderungen,
Architekturanforderungen und Produktvorgaben an die Hardware. Dazu gehö-
ren z.B. die Vorgaben,
✔ welche Betriebssysteme auf welchen Rechnertypen eingesetzt werden sol-
len,
✔ wie die Rechner weltweit verteilt sind und welche Anbindungen an öffentli-
che Netze mit welchen Diensten erforderlich sind,
✔ welche peripheren Komponenten auf dem Arbeitsplatz und im LAN erfor-
derlich sind und wie die Rechner in das LAN eingebunden werden sollen.
Die DWH-Hardwarekonzeption ist von der Softwarekonzeption abhängig, da die
Software auf der Hardware betrieben werden soll und die Softwareanforderun-
gen von der Hardware unterstützt werden müssen. Wenn z.B. die Bedienung
über eine grafische Oberfläche gefordert ist, ist der Einsatz eines zeichenorien-
tierten Terminals nicht möglich. Die Hardwarekonzeption ist auch von der
bestehenden Hardwarelandschaft und von den Aus- oder Umbaukonzepten
abhängig. Die DWH-Hardware soll ja integrativ in der gesamten IT-Landschaft
betrieben werden können.
408 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
Definition: Hardwarekonzept
Das Hardwarekonzept ist die Zusammenstellung der Anforderungen an die
Hardwarearchitektur und der Produktanforderungen zusammen mit einer
Lösungsbeschreibung aus der Sicht der Fachanwender.
Das DWH-Organisationskonzept
Das DWH-Organisationskonzept umfasst alle organisatorischen Anforderun-
gen für den Aufbau, den Betrieb und auch den Abbau der DWH-Lösung ein-
schließlich Hardware, Software und betriebswirtschaftlicher Aufgaben. Das
umfasst z.B. die Vorgaben,
✔ welche Stellen für die Nutzung, den Betrieb, das Management und die Nut-
zerunterstützung eingerichtet werden sollen,
✔ welche Aufgaben zu bewältigen sind und welche Qualifikationen dafür auf-
gebaut oder beschafft werden sollen,
✔ in welchen Besprechungskreisen der Fortschritt und die Weiterentwicklung
des DWH gesteuert werden soll.
Die DWH-Organisationskonzeption soll den Aufbau, den Betrieb und auch den
Abbau der DWH-Lösung mit allen Hardwarekomponenten und allen Software-
komponenten sicherstellen. Sie ist von den Ergebnissen der DWH-Hardware-
konzeption und von der DWH-Softwarekonzeption abhängig, da für Betrieb
und Aufbau der Komponenten die entsprechenden Qualifikationen erforderlich
sind.
Definition: Organisationskonzept
Das Organisationskonzept ist die Zusammenstellung der Anforderungen an
die Organisationsarchitektur zusammen mit einer Lösungsbeschreibung aus
der Sicht der Fachanwender.
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 409
Definition
Das DWH-Konzept ist die Zusammenstellung der Anforderungen aus der
Sicht der Fachanwender mit den Konsequenzen für die Software-, Hardware-
und Organisationsarchitektur.
Das DWH-Konzept ist die Basis für eine Auftragsvergabe. Anhand des DWH-
Konzepts kann ein Auftragnehmer den Umfang der zu leistenden Arbeiten grob
abschätzen und mit einer entsprechenden Kalkulation ein Angebot abgeben.
Das DWH-Konzept ist nach der Auftragsvergabe eine Verpflichtung des Auftrag-
nehmers. Deshalb ist das DWH-Konzept auch ein Pflichtenheft, und zwar ein
Pflichtenheft für den Entwurf. Eine seriöse Schätzung der über den Entwurf
hinausgehenden Aufwände für die Realisierung ist nicht ohne weitere konzepti-
onsüberschreitende Annahmen möglich. Die Realisierung kann erst auf der
Basis eines Entwurfes einigermaßen exakt geschätzt werden.
Checkliste DWH-Konzept
Ein großer Umfang einer DWH-Konzeption bedeutet immer auch viel Aufwand
und hohe Kosten. Hier ist das richtige Maß zu finden zwischen Kosten und
412 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
Nutzen. Der Umfang des DWH-Konzepts ist von der Größe des Projekts, von
den bestehenden Richtlinien und Vorgehensmodellen und deren Einhaltungs-
verpflichtung und von dem für das DWH-Vorhaben vereinbarten Vorgehensmo-
dell abhängig.
Zur Festlegung des Detaillierungsgrades sind nur Faustregeln möglich. Bei
kleinen Projekten kann man prototypisch vorgehen. Das heißt, man kann
zunächst grobe Annahmen machen, um dann bei Feststellen von Mängeln im
Prototyp oder im Design die fehlenden Informationen durch Rückschritt in die
bereits abgewickelte Konzeptionsphase nachzuführen. Bei großen Projekten
mit vielen Mitarbeitern und hohem Integrationsgrad in die bestehende Infra-
struktur ist eine exakte, eindeutige Definition aller Anforderungen erforderlich,
da die »späten« Änderungsaufwände die Konzeptionsaufwände bei weitem
übertreffen würden.
Für die Inhalte der einzelnen Konzepte sind in den vorangegangenen Abschnit-
ten Ergebnisse aufgezählt worden. Für die Darstellung der einzelnen Ergeb-
nisse sind Beispiele aufgeführt.
Die Ergebnisse der einzelnen Konzeptionen werden in einem Dokument
zusammengefasst. Als Beispiel für die Gliederung und als Anleitung für die
Erarbeitung eines geschlossenen DWH-Konzepts dient die folgende Checkliste
DWH-Konzept.
Checkliste DWH-Konzept
Abgrenzung
✔ Definition, Abgrenzung des Themenfeldes, Ziel des Konzepts, Adressaten
✔ Situation vor Projektbeginn
✔ Partner: Standorte, Ländersituation, Sprachen, Betroffene und beteiligte
Firmen
✔ Komponenten: WAN, LAN, Verkabelung, Host, Client, PCs, WSs, Verbin-
dungen, Drucker-Typen, Scanner, Karten, Monitore
✔ Umfang: Telefon, Mobilfunk, Funk, Satelliten, Bildtelefon, Videokonfe-
renz, DATEX, Telex
✔ Anwendungen: CAD, FMS, R/2-Betrieb, R/3-Betrieb, Individual-DB-
Anwendungen, Archivierung, Basissoftware, Utilities, User-Tools
✔ Organisation: Struktur, Regelungen, Prozesse, Verbunde, Personal, Quali-
fikationen, Kapazität, Mengen, Lasten
✔ Betriebserfahrung: Massendateneingaben, Realzeit, Transaktionsbetrieb,
Wartung, Outsourcing
Tabelle 7.3: Checkliste DWH-Konzept
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 413
Umsetzungsorganisation
✔ Organisationsstruktur: Rollen, Stellen, Organisationsstruktur, Kompe-
tenzen, Befugnisse
✔ Ablauforganisation: Prozesse, Richtlinien, Berichtswesen
✔ Qualifikation: Schulungen, Aufgabenstellung, erforderliches Know-how
Umsetzungsplanung
✔ Planungsgrößen: Mengen, Dokumentenvolumen, Dauer, Aufwand, Mittel,
Userzahlen, Entfernungen
✔ Plan: Aktivitäten, Ressourcen, Termine, Dauer, Vorgänger, Nachfolger,
Aktionsträger (Stelle, Organisationseinheit, Funktion)
✔ Risiken: Frühwarnsignale, Konsequenzen, Gegenmaßnahmen
Tabelle 7.3: Checkliste DWH-Konzept
Definition: Funktionsbaum
Der Funktionsbaum ist eine grafische Darstellung einer gliederungshomo-
genen, widerspruchsfreien, vollständigen und eindeutig definierten Funktio-
nalität eines Programmes.
Produktions-
Schaden Anlagenteil Umweltsituation
situation
Neueingabe Neueingabe Suchen Anlagenteil Suchen Umwelt- Suchen Produktions-
Schaden situation situation
Kopieren für Kopieren Schaden Kopieren Anlagenteil Kopieren Umwelt- Kopieren Produk-
Neuanlage situation tionssituation
Produktions-
Schaden Anlagenteil Umweltsituation
situation
Schaden Schäden zu einem Schäden zu einer Schäden zu einer
Anlagenteil Umweltsituation Produktionssituation
Anlagenteil Anlagenteile zu
einem Schaden
Aus einer anderen Perspektive heraus ist eine weitere Verfeinerung des Funkti-
onsbegriffes möglich. Wenn man zum »Woran«, also dem Zielobjekt der Funk-
tion, noch das Startobjekt »Von wo aus« berücksichtigt, dann erhält man eine
Funktion »Suchen einer Information in Objekttyp A zu einer bekannten Infor-
mation in Objekttyp B«.
Diese Startbetrachtung ist für die Gruppe »Neuanlegen von Datensätzen« im
Sinne von Informationsergänzungen über zwei Tabellen und für die Gruppe
»Bearbeiten« ganz analog gültig.
Für diese Klassifikation wurde von der Möglichkeit verschiedener Wege zwi-
schen Starttabelle und Zieltabelle kein Gebrauch gemacht. Es wurde hier
außerdem vorausgesetzt, dass zu jedem Objekttyp maximal eine Funktion reali-
siert wird. Die Start-Ziel-Betrachtungsweise lässt sich nicht deckungsgleich auf
die Gruppe »Auswertungsfunktion« übertragen. Die Auswertungsfunktion
kann durch mehrere gruppierte Strukturen definiert werden.
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 419
Die Matrix aller Paare, die Pfadematrix, erlaubt einen überschaubaren, voll-
ständigen Überblick aller möglichen Wege im Gegensatz zur grafischen Dar-
stellung, die schon bei vier Objekttypen unüberschaubar ist.
Im Beispiel sind auch die Funktionen, die mit Hilfe der Pfadematrix gewonnen
wurden, im Funktionsbaum aufgeführt.
420 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
' ,
#
$
%#
)
%#
* *
%#
)
%#
+
$
%#
+
$
,
,
*
-
-
.
',
Die Datenmodellierung
Das Datenmodell ist ein Bild des Datenbankschemas. Je nach Datenbanktyp
gibt es ein anderes Datenbankschema und eine andere Darstellung des Daten-
modells. Die gebräuchlichsten Datenbanktypen sind
✔ hierarchische Datenbank
✔ netzorientierte Datenbank
✔ relationale Datenbank
✔ objektorientierte Datenbank
Hier kann nur kurz auf die relationale Datenmodellierung eingegangen wer-
den. Eine vollständige Darstellung nimmt den Umfang eines eigenen Buches
an. Es wird daher verwiesen auf:
Vetter, Aufbau betrieblicher Informationssysteme
Wiborny, Datenmodellierung, CASE-Mangement
Es gibt nach Notation und semantischem Umfang verschiedene relationale
Datenmodelle. Die hier besprochene Darstellung ist das Entity Relationship
Modell, kurz ERM, nach Chen. Im Folgenden wird nur auf das ERM Bezug
genommen.
Das relationale Datenmodell wird aus dem Informationsmodell durch Definie-
ren, Vervollständigen, Normalisierung und Denormalisierung gewonnen.
Die exakte Definition der Informationsgruppen der Informationsobjekte
umfasst eine definitorische Beschreibung mit erklärten Begriffen und eine Auf-
zählung aller Eigenschaften jeder einzelnen Informationsgruppe. Eine Infor-
mationsgruppe kann dann als Datensatz dargestellt werden, wobei die Eigen-
schaften die Datenfelder oder Datenelemente sind. Ein Datensatz einer
Informationsgruppe besteht dann aus mehreren Datenelementen, auch Attri-
bute genannt. Zu jeder Informationsgruppe gibt es mehrere Individuen, die alle
durch die gleiche Datenstruktur, den Datensatz mit seinen Attributen beschrie-
ben werden können. Ein Attribut, das Schlüsselattribut, identifiziert den
Datensatz oder das Informationsobjekt der Gruppe. Ein Schlüsselattribut ist
zum eindeutigen Ansprechen und Wiederauffinden des Datensatzes in der
Datenbank erforderlich. Die Datenstruktur des Informationsobjekts kann in
einer Datenbank als Tabelle angelegt werden, in welche die Datensätze dieser
Struktur und dieser Bedeutung eingegeben werden können.
Beispiel: Normalisierung
Ein Beispiel für eine solche Informationsgruppe ist die Schadensbeschrei-
bung. Die Struktur der Schadensbeschreibung sind die Attribute, mit denen
der Schaden näher beschrieben wird:
✔ Schadensnummer
422 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
Schadens-
Schadensobjekt
nummer
123456 Aa1
123456 Ab1
123456 Ac1
123456 Ad1
123457 Bc1
123457 Bg1
123458 Be2
123458 Bf2
Objekt-
Schadensobjekt
nummer
Aa1 Pumpe der Speisewasseranlage xxxxy des Kraftwerks 1
Ab1 Leitung der Speisewasseranlage xxxxy des Kraftwerks 1
Ac1 Motor der Speisewasseranlage xxxxy des Kraftwerks 1
Ad1 Ventil der Speisewasseranlage xxxxy des Kraftwerks 1
Bc1 Motor des Rolltors yvyxcf des Kraftwerks 1
Bg1 Kette des Rolltors yvyxcf des Kraftwerks 1
Be2 Behälter der Löschwasseranlage des Kraftwerks 2
Bf2 Flansch der Löschwasseranlage des Kraftwerks 2
Die Daten sind jetzt elementar dargestellt und einzeln ansprechbar. Sie müs-
sen nicht aus einem komplexeren Feld als Teilinformation ausgewählt werden.
Das Ergebnis der Normalisierung ist ein relationales Datenmodell aus Tabellen
oder Relationen oder Entitätstypen, mit Tabellenspalten oder Attributtypen
sowie Verbindungen der Tabellen über Schlüsselwerte, sogenannte Relation-
shiptypen. Dabei entsteht ein Zuordnungsverhältnis von Datensätzen zweier
verbundener Tabellen, sogenannter Kardinalitäten.
Definition: Datenmodell
Das Datenmodell ist eine grafische Darstellung der Tabellen einer Daten-
bank, der Verbindungen der Tabellen durch Schlüssel und der Kardinalität
der zugeordneten Datensätze. Die Tabellen können mit und ohne Spaltenna-
men aufgeführt werden.
#
Einen Einblick in die Tabelle Wartungskatalog gibt ein Report der Tabelle wie in
der folgenden Abbildung dargestellt (siehe Abbildung 7.17).
Das Entity Relationship Modell besteht aus Symbolen für
✔ Tabellen oder Entitätstypen der Datenbank (Rechteck)
✔ Auflistung der Spalten oder Attributtypen im Entitätstypensymbol oder ver-
bunden mit dem Entitätstypensymbol in einem eigenen Symbol (Kreis).
Unter den Attributen werden diejenigen hervorgehoben, die Datensätze
identifizieren können und die Referenzen zu anderen Tabellen bilden kön-
nen, sogenannte Schlüssel
✔ Beziehungen oder Relationshiptypen zwischen den Entitätstypen
✔ Kardinalitäten oder Zuordnungsverhältnis von Datensätzen zweier verbun-
dener Tabellen.
Durch die Zerlegung von Sachverhalten in viele Tabellen werden die Zugriffe
für einen vollständigen Datensatz länger und Datenmodelle unübersichtlicher.
Die Renormalisierung, also das Zusammenführen von einzelnen Tabellen zu
einer Tabelle mit redundanten Daten, ist erforderlich, um die Performance zu
verbessern.
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 425
Der Vorteil der Ansätze mit Normalisierungsregeln beruht auf der guten Kon-
trolle über Integrität und Redundanz der Datensätze. Beide Eigenschaften sind
auch im klassischen hierarchischen Datenmodell möglich, dies allerdings zum
Preis des erhöhten Kodieraufwandes, was die Überschaubarkeit und die Vermit-
telbarkeit erschwert.
426 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
Für die Formulierung der Anfragen an die Tabellen dient eine weitere Grafik,
das Zugriffspfademodell. Es weist Startpunkte von Anfragen an Tabellen aus,
zusammen mit der Fortsetzung der Anfragen, basierend auf dem Ergebnis der
vorhergehenden Frage.
Die Ergebnisse der Teilphase Datenmodellierung sind
✔ Datenmodell, Entity Relationship Modell, Datenbankregeln
✔ Zugriffsmodell
steht. Die folgende Abbildung aus
Anahory, Data Warehouse
verdeutlicht die Bezeichnung (siehe Abbildung 7.19). Die eigentlichen Daten,
die Fakten, sind in der zentralen Tabelle »Verkaufstransaktionen« des »Sterns«
enthalten. Die Fakten sind definiert durch die Dimensionen, die Star-Dimensio-
nen. Die Dimensionen sind selbst wieder durch mehrere in verschiedenen Tabel-
len verwaltete Eigenschaften, die Snowflake-Dimensionen«, zu beschreiben.
Eine sehr differenzierte und leistungsfähige, aber auch unbequeme Notation
zur Darstellung von Aggregationen und multidimensionalen Modellen ist die
Methode ADAPT. ADAPT ist die Kurzform von »Applikation Design for Analyti-
cal Processing Technologies«. Näheres hierzu ist zu finden in:
Chamoni, Informationssysteme
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 427
,
.
,
.
,
+
,
+
'
,
+
.
,
,
+
.
/
-
,
.
-
,
-
!
"""
Geschäfts-
Abteilung
einheit
Verkaufs-
transaktionen
Oster-
Woche SSV verkauf
Monat
+
&
&
)
+ +
+
)
&
!
"
+
+
)
!
"
'
Die Dialogmodellierung
Der Funktionsbaum ist eine nach Ordnungskriterien sortierte Funktionsliste,
eine nach Ober- und Unterbegriffen hierarchisch zusammengestellte Struktur.
Funktionen können als Programm, Teilprogramm oder Programmabschnitt,
Programmzeile realisiert werden. Diese Programmbestandteile müssen in einer
definierten Reihenfolge ablaufen. Die Funktionen können ohne Eingriff von
außen ablaufen oder in Wechselwirkung mit Aktivitäten eines Benutzers stehen.
Die als Ablauf definierte Funktionsfolge mit Benutzeraktivitäten ist ein Dialog.
Die Möglichkeiten eines Dialoges des Benutzers mit dem Programm werden
mittels einer Dialogstruktur dargestellt. Alternative Begriffe sind Maskense-
quenzdiagramm, Maskenfolgenschema. In einer Dialogstruktur sind alle Mas-
ken eines Programmes symbolisch dargestellt. Es ist dargestellt, wie diese Mas-
ken miteinander verbunden sind und wie ein Sprung von einer Maske zu einer
Folgemaske ausgelöst werden kann.
Definition: Dialogstruktur
Die Dialogstruktur ist ein Netzgraph, dessen Knoten Masken repräsentieren
und dessen Kanten die Möglichkeit, von einer Maske aus eine Folgemaske
aufrufen zu können, repräsentieren.
430 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
Mittels einer Dialogstruktur kann ein Anwender den Arbeitsgang seiner Aufga-
ben gedanklich durchspielen und den zukünftigen Softwaredialog überprüfen.
Man kann auch von einer manuellen Simulation sprechen. Der Dialog ist ja Vor-
lage oder Bauplan des zukünftigen Programmdurchlaufs durch den Anwender.
In der folgenden Abbildung »Dialogstruktur der Schadensbeschreibung« wird
ein Beispiel für eine Dialogstruktur dargestellt. Die Masken sind hier sehr kom-
fortabel gestaltet, was den Anwendern eine bessere Vorstellung von der zukünf-
tigen Software ermöglicht.
nität zu erreichen, wird ein Regelwerk zur Gestaltung der Masken und der Dia-
loge erarbeitet und verabschiedet. Alle Entwickler werden verpflichtet, diese
Regeln einzuhalten, und die Einhaltung wird bei der Abnahme überprüft. Ein
solches Regelwerk heißt Style Guide.
Der Vorteil der Homogenität liegt in der besseren Ergonomie für den Anwender
und in der besseren Wartbarkeit für die Entwickler.
Die Produkte der Dialogmodellierung sind
✔ Maskenaufbau und -inhalt mit Plausibilitätsregeln
✔ Dialogstrukturen oder Maskensequenzdiagramme und Definition
✔ Transaction Control Structure, Struktogramme, Programmflussdia-
gramme, Klassenmodelle
✔ Style Guide
Programmstrukturierung
Neben den dialogorientierten Programmen gibt es Programme oder Prozedu-
ren, die ohne Benutzereingriff ablaufen. Die Programmstrukturierung kann
mit den gleichen Methoden wie die Strukturierung des Mikrodialogs durchge-
führt werden. Zu den genannten Methoden wie Programmflussdiagrammen,
Jackson Diagrammen, Struktogrammen und Klassenmodellen kommt die Ent-
scheidungstabellentechnik hinzu, die besonders für die Auflösung komplizier-
ter Fallunterscheidungen geeignet ist. Hierzu sei verwiesen auf
Erbesdobler, Entscheidungstabellentechnik
Die grafische Darstellung von Programmstrukturen hat in der Dialogprogram-
mierung an Bedeutung verloren, da die Programmkomponenten klein gewor-
den sind, so dass Überschaubarkeit auch bei der Darstellung in einer Program-
miersprache gegeben ist. Die Thematik der Programmstrukturierung wird hier
nicht weiter vertieft, da sie für die DWH-Thematik wenig Bedeutung hat.
Auch die Programmstrukturierung sollte der Homogenität der Programme
zuliebe über verschiedene Entwickler nach festen Regeln zu Strukturierung,
Namensgebung und Kommentierung durchgeführt werden. Für diese Regeln
sind Programmierrichtlinien geeignete Instrumente.
Die Produkte der Programmstrukturierung sind
✔ Transaction Control Structure, Struktogramme, Programmflussdia-
gramme, Klassenmodelle
✔ Programmierrichtlinien mit Nomenklaturen
Hardwarespezifikation
Für die in der Realisationsphase abzuwickelnde Hardwarebeschaffung sind die
konzeptionellen Angaben des DWH-Konzepts so weit zu detaillieren, dass kon-
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 435
Organisationsspezifikation
Organisationsspezifikation wird aus den Organisationsanforderungen des
DWH-Konzepts abgeleitet.
Im Organisationskonzept sind alle Anforderungen bezüglich der organisatori-
schen Fragestellungen dargestellt. Für die Umsetzung zu Organisationsmaß-
nahmen, also zur Vorbereitung der Realisationsphase, sind zwei Themen zu
spezifizieren:
✔ Stellenbeschreibungen für die Durchführung von Personalbeschaffungs-
maßnahmen
✔ Schulungsspezifikation für die Durchführung von Qualifikationsmaßnah-
men
Die Stellenbeschreibungen umfassen die Aufgabenstellung, die Aufgaben im
Einzelnen, die Verantwortung und Befugnisse, die Teilnahme an Besprechungs-
kreisen und die Eingliederung in die Organisation.
Die Schulungsspezifikation beschreibt die einzelnen Schulungen mit Inhalt,
Lerntiefe und Lernmittel.
Prozessdiagramme Stellenbeschreibungen
Organigramm
Aufgabenliste
Aufgabenliste Schulungsspezifikation
Die Organisation des DWH ist damit hinreichend für die Realisation definiert.
436 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
Definition: DWH-Entwurf
Der DWH-Entwurf ist die Zusammenstellung der Programmiervorgaben aus
der Sicht des Systemanalytikers, formuliert nach Regeln der Entwurfsme-
thoden.
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 437
wurfs sind mit den Ergebnissen des DWH-Konzepts eng verbunden. Den Mas-
ken des Dialogs entsprechen z.B. Funktionen. Die Ergebnisse des DWH-Ent-
wurfes sind ebenfalls miteinander verknüpft. Den Tabellen entsprechen die
Funktionen zur Verarbeitung der Tabelleninhalte. Die Tabellen sind den Masken
zugeordnet, indem auf den Masken die Felder für die Tabelleneingaben platziert
sind. Diese Zuordnungen sind komplex und müssen auf Regelstimmigkeit kon-
trolliert werden. Für die teilweise automatisierte Konsistenz- und Integritäts-
sicherung sind CASE-Tools entwickelt worden. Die Kontrolle der Modell-Kon-
sistenz mittels CASE-Tool-Einsatz ist umso wichtiger, je komplexer das DWH
ist. Folgende Vorgehensweise in der Erstellung des DWH-Entwurfes ist zu emp-
fehlen:
CASE-Tool-Einsatz
Die Transparenz und Aussagekraft einer Grafik hängt wesentlich von der Wahl
der Symbolik ab. Zur Beurteilung der Symbolik dienen die Beispielgrafiken im
Text als Anhaltspunkt. Viele CASE-Tools stellen mehrere Symbolbibliotheken
zur Wahl. Kein CASE-Tool bietet eine vollständige Symbolauswahl und eine
vollständige Methodenkette über alle Phasen des DWH-Vorgehensmodells an.
Die Produktwahl ist bezüglich der Vervollständigung durch manuelle Grafikbi-
bliotheken zu optimieren.
Hardwarespezifikation
Die Gestaltungsmöglichkeiten sind bereits in Kapitel 6 »Hardware« beschrie-
ben worden. Die Spezifikation erfordert Produktkenntnisse über alle Hardware-
komponenten, welche die Qualifikation des DWH-Spezialisten überschreiten.
Der DWH-Spezialist muss nur einen Eindruck gewinnen, was die Spezifikation
einer Komponente umfasst. Dies geben die Angaben der folgenden Checkliste
wieder.
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 441
Organisationsspezifikation
Für Stellenbeschreibungen sind im Anhang ausführliche Beispiele angegeben.
Beispiel
Das Beispiel gliedert sich entsprechend der zwei Phasen »Konzeption« und
»Entwurf« in zwei Schritte: Erstellung des DWH-Konzeptes und Erstellung des
DWH-Entwurfes. Beide Schritte zusammengenommen bilden einen Ausschnitt
aus dem Vorgehensmodell.
Damit ist der Umfang und die Tiefe des DWH-Konzeptes für InDaWa abgesteckt.
Der Schwerpunkt des Entwurfes liegt in der Softwarespezifikation.
Gestaltungsentscheidung
Im Folgenden sind, wie in den vorausgehenden Kapiteln auch, die Entschei-
dungen zum Vorgehensmodell, die im Musterprojekt »InDaWa« getroffen wur-
den, noch einmal im Überblick zusammengestellt.
ORIENTIERUNG
VORGEHENSMODELL
DWH-Vorgehensmodell
Softwareentwicklungsmodell
ab Kontextermittlung
für relationale Datenbank Grunddaten sind relational
ohne Produktfestlegung keine Produktkenntnis, Evaluation erforderlich
für Dialogprogramm Steuerung im Benutzerdialog gewünscht
für Indiviualentwicklung kein Standard aus Fachzeitschriften bekannt
für grafische Oberflächen Bedienung unter MS-Windows
DWH-Konzept
DWH-Entwurf
PROJEKTIERUNG
7.6 Übungen
Übung 7.1: Prozessanalyse
Entwerfen Sie den Prozess eines DWH-Sprachenlexikons mit Beschreibung
und Prozessdiagramm.
Übung 7.2: Grundbegriffe 1
Erklären Sie die Begriffe Vorgehensmodell, Methode, Phasen, Teilphasen, Tools
und stellen Sie diese Begriffe zueinander in Beziehung.
Übung 7.3: Grundbegriffe 2
Grenzen Sie die Zielsetzung des DWH-Entwurfes gegen das DWH-Konzept und
das DWH-Konzept gegen das Fachkonzept ab.
Übung 7.4: Grundbegriffe 3
Definieren Sie die Begriffe Funktionsliste, Prozessdiagramm, Organigramm,
Kontextdiagramm, Informationsobjekteschema.
Übung 7.5: DWH-Konzept
Entwerfen Sie das Inhaltsverzeichnis eines DWH-Konzeptes und nennen Sie
die Methoden zur Erstellung einzelner Ergebnistypen.
Übung 7.6: Definitionen 4
Definieren Sie die Begriffe Funktionsbaum, Funktionsmatrix, Datenmodell,
Dialogstruktur, Aggregationsmodell, Kennzahlenschema.
Übung 7.7: DWH-Entwurf
Wie ist ein DWH-Entwurf aufgebaut und worin besteht der Unterschied zu
einem Fachkonzept? Entwerfen Sie das Inhaltsverzeichnis eines DWH-Ent-
wurfs und nennen Sie die Methoden zur Erstellung einzelner Ergebnistypen.
Übung 7.8: Funktionsbaum
Beschreiben Sie die Ableitung eines Funktionsbaumes aus einem Prozessmo-
dell und die Ableitung aus einem Datenmodell.
Übung (mit Lösung) 7.9: Datenmodell
Entwerfen Sie das Datenmodell für ein zweisprachiges Lexikon, das sich auf ein
mehrsprachiges Lexikon erweitern lässt, mit je einer extra Tabelle pro Sprache.
Versuchen Sie hierfür zwei Varianten auszuführen.
Übung 7.10: Funktionsmatrix
Leiten Sie aus dem Datenmodell für ein zweisprachiges Lexikon, das sich auf
ein mehrsprachiges Lexikon erweitern lässt, mögliche Zugriffswege und Anfra-
gen ab. Stellen Sie diese im Datenmodell dar und leiten Sie daraus eine Funkti-
onsmatrix ab.
Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen 445
7.7 Zusammenfassung
Wenn die Gestaltungsläufe zur Architektur vollzogen sind, steht das »Was« fest.
Im nächsten Gestaltungslauf wird nun das »Wie« und »Womit« festgestellt.
Dieser Gestaltungslauf besteht aus pro Phase je einem Gestaltungsgang. Der
methodische Schwerpunkt für die DWH-Gestaltung liegt in der Softwarent-
wicklung.
Im ersten Schritt des ersten Gestaltungsganges musste eine Entscheidung
über das Vorgehen nach einem Vorgehensmodell und bei positiver Entscheidung
über dessen Umfang getroffen werden. Diese Entscheidung ist abhängig von
bestehenden Vorgehensmodellen des Unternehmens, vom Einstiegszeitpunkt in
das DWH-Vorhaben und von der Kenntnis öffentlicher Vorgehensmodelle. Im
Beispiel ist als Startzeitpunkt die Konzeption der DWH-Lösung dargestellt.
Im ersten Schritt des ersten Gestaltungsganges ist der Umfang der Phase Kon-
zeption festzulegen. Im Beispiel ist bezüglich der Softwarekonzeption die
Eigenentwicklung der Softwarelösung mit relationaler DB-Technik und Client/
Server-Architektur dargestellt.
Im zweiten Schritt des ersten Gestaltungsganges ist die Methodik der Phase
Konzeption festzulegen. Im Beispiel wurde bezüglich der Softwarekonzeption
das Kontextdiagramm, die Funktionsliste und das Prozessdiagramm und die
Formularliste gewählt.
446 Kapitel 7 • Das Vorgehensmodell zum Aufbau von DWH-Systemen
Im dritten Schritt des ersten Gestaltungsganges sind die Tools zur Unterstüt-
zung der methodischen Arbeitsweise und zur Dokumentation der Phase Kon-
zeption festzulegen. Im Beispiel wurde bezüglich der Darstellung des Kontext-
diagrammes das Grafiktool Visio, bezüglich der Darstellung des
Funktionsbaumes und bezüglich der Darstellung der Prozessdiagramme das
CASE-Tool Systems Architect und bezüglich der Formularliste MS-ACCESS
gewählt.
Damit ist also der beispielhafte Durchlauf durch die Gestaltungsentscheidun-
gen für die Entscheidung Eigenentwicklung von Software wie folgt:
1. Schritt
Phasen
ab Konzeption
für Fachinhalte
für Softwaretechno-
logie
für Hardware
für Organisation 2. Schritt
Konzept
Eigenentwicklung der
Softwarelösung mit
relationaler DB-
Technik und Client/
Server-Architektur 3. Schritt
Methoden
Kontextdiagramm
Prozessdiagramm
Funktionsliste
Formularsammlung 4. Schritt
Tools
Visio
Systems Architect
Systems Architect
MS-Access
Entwurf
Im zweiten Gestaltungsgang sind der Umfang der Phase Entwurf, die einzuset-
zenden Methoden, ihre Symbolik und die Dokumentationstools festzulegen.
Analog dazu werden in weiteren Gestaltungsgängen die anderen Phasen wie
Realisierung, Implementierung und Betrieb entworfen.
Steht das Vorgehensmodell fest, ist in vier Arbeitsgängen der Reihe nach zu
definieren, welche Fachinhalte abgedeckt werden sollen, mit welcher Software-
technologie das geschehen soll, auf welcher Hardware diese Software betrieben
werden soll und welche Organisation für Aufbau und Betrieb erforderlich ist.
447
KAPITEL 8
8 Projektierung und Betrieb eines Data
Warehouse Systems
Überblick
Ein DWH-Projekt ist hochkomplex. Zur Beherrschung eines DWH-Projekts ist
deshalb eine Strukturierung des umfangreichen Aufgabenpakets in kleine,
überschaubare Aktivitäten und die Planung ihrer Bearbeitung, eine Projektie-
rung, erforderlich. Zur Erledigung dieser Aufgabenpakete sind Sachmittel und
Personal termingerecht einzusetzen. Personal- und Sachmitteleinsatz verursa-
chen Kosten, die in einem Budget formuliert und als Finanzierung zur Verfü-
gung gestellt werden müssen. Es wird deshalb zunächst dargestellt, was die
Projektierung beabsichtigt und was ihr Ergebnis ist.
Danach werden zu allen Projektierungsaufgaben effiziente Hilfsmittel vorge-
stellt und gezeigt, wie mit ihrer Hilfe ein Projekt handhabbar wird. Diese Mittel
bauen auf einem fundamentalen Mittel, der Leistungsleitlinie, auf. Die Leis-
tungsleitline ist ein Verzeichnis aller Arbeitsschritte und ihrer Ergebnisse.
Im nächsten Schritt wird die zur Abwicklung eines Projekts erforderliche Orga-
nisation mit Strukturen, Aufgaben, Rollen, Stellen und Prozessen vorgestellt.
Es gehört zu den Aktivitäten eines Projekts, auch die organisatorischen Voraus-
setzungen mitzugestalten.
Daran anknüpfend wird im Rahmen der Umsetzung kurz auf die Problematik
der Beschaffungen zu einem DWH-Vorhaben eingegangen. Konkrete Hinweise
zu den Software- und Hardwareprodukten finden Sie in Kapitel 9 »Die Produk-
tevaluation von Data Warehouse Systemen«.
Zum Schluss des Kapitels wird dargestellt, mit welchen Mitteln die einmal
erstellte Projektierung kontinuierlich an der aktuellen Situation gemessen
werden kann.
Die folgende Abbildung zeigt den Gang des Kapitels.
448 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
Lernziel
Das Ziel dieses Kapitels ist, eine Übersicht über die Projektierungsaufgaben und
die Möglichkeiten, in einem komplexen Projekt mittels Projektierung eine
Kontrolle der Abwicklung zu erreichen, zu vermitteln. Aufbauend auf den vor-
gestellten Projektaktivitäten und den zu ihrer Durchführung erforderlichen
Mitteln, ist das Budget zur Beschaffung festzustellen. Weitere Lernziele erge-
ben sich daraus, dass der DWH-Spezialist alle Komponenten der Organisation
eines DWH erkennen und im Projekt aufbauen muss. Dazu kommt, dass er, auf-
bauend auf den Erkenntnissen zur Projektierung und den vorgestellten Mitteln,
die Beschaffung und die Verfolgung des Projekts beherrschen muss. Die Lern-
ziele dieses Kapitels sind dementsprechend:
Lernziele
Kennen der Projektierungsaufgaben
Verstehen
folge
der Bedeutung der Leistungserbringung und der Leistungsab-
Kennen
tivitäten
des Zusammenhanges der Budgetpositionen mit den Projektak-
Genau genommen steht erst nach der Definition des Bedarfes und nach Treffen
aller Gestaltungsentscheidungen fest, wie die Projektschritte heißen. Ein
Ergebnis der Gestaltungsfrage ist z.B. die Entscheidung, ob eine Eigenentwick-
lung erforderlich ist oder eine Anwendung von der Stange gekauft werden
kann. In beiden Fällen ist eine Evaluation von Produkten erforderlich. Aber nur
bei der Entscheidung für eine Individualentwicklung ist eine Spezifikation bzw.
ein detaillierter Entwurf mit z.B. einem Datenmodell erforderlich. Lautet die
Entscheidung dagegen »Zukauf von Standardsoftware«, fällt als Projektaufgabe
ein Customizing-Schritt an.
Ein fertiges DWH gibt es nicht zu kaufen. Ein Data Warehouse sind verschie-
dene Softwarekomponenten, die von Personen bedient auf einer Hardware-
Infrastruktur betriebswirtschaftliche Funktionen ausführen. Einige dieser Soft-
warefunktionen müssen mit einer Reihe von Werkzeugen effizient und schnell
mit wenigen Programmierkenntnissen für die Unternehmensaufgabe maßge-
schneidert entwickelt werden. Solche DWH-typischen Applikationen sind z.B.
spezielle Reports mit bestimmtem Layout. Hierfür ist bei modernen Werkzeu-
gen keine Programmiersprache erforderlich. Der Report wird gezeichnet und
ein Programmgenerator erzeugt im Hintergrund ein Report-Programm. DWH-
Funktionen sind damit zu spezifizieren und werden auch realisiert, ohne auf
der Ebene der Programmiersprachen der dritten Generation arbeiten zu müs-
sen. Für ein DWH sind Eigenentwicklungen erforderlich.
Die Umsetzung der Anforderungen zu einer Gesamtlösung, besonders die Pro-
duktion von Eigenentwicklungen, kann nur mit Personal- und Know-how-Ein-
satz bewältigt werden. Das Abstellen des Personals aus dem Personalstamm des
Unternehmens, die Bereitstellung der Ressourcen und die Durchführung eines
Projekts, d.h. die Abfolge der Arbeitsschritte, müssen sorgfältig geplant werden.
Zu den reinen DWH-Fachaufgaben gehört noch eine Gruppe von Aufgaben, die
viel zu wenig berücksichtigt wird: die Unternehmenskommunikation. Es ist
enorm wichtig, im Unternehmen genügend Informationen über das DWH-Vor-
haben, das Projektziel und den Projektfortschritt zu verbreiten. Dafür ist ein
internes Marketing erforderlich. Es muss den nicht involvierten Anwendern
und auch den Entscheidern eine Nützlichkeit und Nutzbarkeit vermitteln. Das
steigert die Akzeptanz, erleichtert den Zugang zum Unternehmens-Know-how,
erweitert den Anwenderkreis und führt indirekt zu einer besseren Rentabilität.
Letzlich kann auch externes Marketing nützlich sein und ein Vertrieb z.B. von
erworbenem Know-how oder Zwischenprodukten wie Datenmodellen zusätzli-
che Umsatzquellen erschließen.
Die Projektierung umfasst alle Projektphasen des Aufbaus des DWH. Der
Betrieb selbst ist nicht mehr Gegenstand des Projektierens, wohl aber die Vor-
bereitung des Betriebs, also die Überführung des Projekts in den ordnungsge-
mäßen Betrieb.
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 451
%
# &
'
()
,
%
,
+
,
'
Die Statusanalyse
Ein Projekt entsteht oftmals spontan aus einer internen Idee. Projektideen kön-
nen aber auch gezielt und systematisch aus den Unternehmensaufgaben abgelei-
tet werden. Besonders ein DWH hat ja die Aufgabe, die Unternehmensaufgaben
zu unterstützen, die Unternehmenssituation transparent zu machen und die
soliden Grundlagen für Managemententscheidungen zu liefern. Vor dem DWH-
Projekt sollte deshalb die Statusanalyse des Unternehmens stehen. Es sollte
festgestellt sein, was das Unternehmen zukünftig vorhat und welche Unterstüt-
zung in Form guter und effizienter Informationen dazu erforderlich sind.
Projektidee, Projektinitiierung und Projektakquisition
Aus der Idee wird nach einigen Gesprächen mit Kollegen der Umriss der Vor-
stellungen – in unserem Falle der Umriss dessen, was ein DWH werden soll –
immer schärfer. Wenn sich die Auffassungen zu einer klaren Vorstellung, einer
Projektidee, konkretisiert haben, gehen Vetriebsexperten zu Kunden und ver-
suchen, das Interesse an einer Angebotslegung zu wecken. Es ist auch denkbar,
dass Kunden von sich aus den Wunsch äußern: »Könnt ihr nicht ein DWH für
452 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
uns errichten, ihr habt doch auch...«. DWH entstehen in der Regel aus der
Erkenntnis, dass die Reportingwerkzeuge der Standardsoftware nicht die
gewünschte Flexibilität und auch nicht die Intelligenz der DWH-Produkte
haben.
Ist die Projektdee geboren, die Vorstellung so konkret geworden, dass ein
Umfang, eine erforderliche Leistung und die damit verbundenen Kosten deut-
lich werden, kann man im eigenen Unternehmen nach Befürwortern eines
DWH suchen. Eine interne Projektakquisition bei Abteilungsbesprechungen
wird gestartet.
Ist die Akquisition erfolgreich und stößt die Projektidee auf Interesse, wird das
Projekt ausformuliert und sein Start von einem Projektmentor initiiert – das
ist die sogenannte Projektinitiierung. DWH-Projekte werden in der Regel
extern von Kunden mit Standardsoftware und intern von Kollegen aus Abtei-
lungen, die mit Analysen von Unternehmens- und Marktdaten beschäftigt sind,
z.B. aus dem Marketing oder dem Controlling, initiiert.
Der Projektantrag
Ein DWH-Projekt startet mit einem Projektantrag. Wer einen Projektantrag
zur Erstellung eines DWH formulieren will, muss bereits sehr viel über DWH
wissen. Er muss die Komplexität abschätzen können, und er muss wissen, dass
zum Aufbau eines DWH sowohl Hardware- als auch Softwareprobleme zu lösen
sind. Er muss bereits einen ersten Überblick über organisatorische Bedingun-
gen haben. Mit diesem Wissen kann er erst definieren,
✔ wie das Projekt genannt werden soll
✔ was das Ziel des DWH-Projekts sein soll
✔ welchen Nutzen aus dem DWH oder dem Projekt gezogen werden soll
✔ mit welchen Kosten zu rechnen ist
✔ ob das Projekt auf anderen Projekten aufsetzen kann, ob es als Pilotversuch
gestartet werden soll
✔ wer die Projektteilnehmer sein müssen
✔ in welchem Zeitraum welche Ergebnisse zu erreichen sind
Der Projektantrag enthält damit eine klare Definition des Projekts. Die Projekt-
definition kann enthalten:
✔ Ausführliche Projektbezeichnung
✔ Projektname
✔ Projektkurzzeichen
✔ Darstellung des Projektumfanges
✔ nach zu erreichenden Zielen
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 453
✔ einzusetzenden Erkenntnissen
✔ Terminrahmen und Abhängigkeiten der Ecktermine zu anderen Projekten
Der Projektantrag wird später im Abschnitt »Projektverfolgung« dieses Kapitels
als Element in einem geschlossenen Projektberichtswesen behandelt.
Angebotsausschreibung, Projektauftrag, Leistungsverzeichnis
Der Projektantrag wird von den Entscheidungsträgern begutachtet, eventuell
korrigiert und genehmigt. Das DWH-Projekt kann dann starten und mit inter-
nen Ressourcen als rein internes Projekt, als internes Projekt mit Zukauf von
Leistungen oder als Partnerschaftsprojekt mit anderen Unternehmen abgewi-
ckelt werden oder vollständig an ein Partnerunternehmen als externer Auftrag
vergeben werden.
Je nach Größe des Projekts muss nach neuen EU-Richtlinien eine streng regle-
mentierte öffentliche Ausschreibung stattfinden. Auf der Basis eines genehmig-
ten Antrages werden Angebote eingeholt. Die Angebotsausschreibung muss
inhaltlich und vom Umfang her mit dem Projektantrag übereinstimmen.
Die verschiedenen Angebote werden ausgewertet. Im Falle einer öffentlichen
Ausschreibung ist die Angebotsauswertung den Bietern bekanntzugeben. Das
beste Angebot führt bei Übereinkunft von Preisvorstellung und Gegenleistung
zu einem Auftrag.
Der externe Auftrag enthält ein gegenüber dem Projektantrag meistens etwas
detaillierteres Verzeichnis von Leistungen, das Leistungsverzeichnis. Das
detaillierte Verzeichnis des Angebots ist Basis für die bereits besprochene Lei-
stungsleitlinie des DWH-Projekts. Der interne Auftrag ist in der Regel eine
formlose Bestätigung des Projektantrages. Detaillierte Aufträge sind auch bei
interner Abwicklung ein gutes Mittel, die ausführenden Organisationseinhei-
ten, z.B. Kompetenzzentren, an die Leistungen zu binden. Diese Leistungsbin-
dung ist auch die Basis für die interne Leistungsverrechnung. Das Leistungs-
verzeichnis ist der Maßstab für die Beurteilung des Projektfortschritts.
Projektplanung und Projektierung
Ein DWH-Projekt ist so umfangreich und komplex, dass eine Planung des Pro-
jekts durchgeführt werden muss. Mit der Projektplanung versucht man, sich
auf das, was im Laufe des Projekts geschehen kann, vorzubereiten. Die Projekt-
planung des DWH basiert auf den Festlegungen im Projektantrag, sie setzt die
Rahmenbedingungen des Projektantrags fort und differenziert diese. Die Aufga-
ben der Projektplanung sind:
✔ Feststellung der vorgegebenen Ecktermine
✔ Aufzählung der Projektaktivitäten mit Hauptaufgaben, Teilaufgaben, even-
tuell Aufteilung des GesamtProjekts in Teilprojekte
✔ Verteilung der Aufgaben innerhalb der Projekttermine bzw. Einteilung der
Zeitabstände zwischen den vorgegebenen Eckterminen; Feststellung der
Abhängigkeiten zwischen den Aktivitäten
454 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
!
"
Ziel der Projektplanung ist die Abschätzung von Planwerten und ihre Zusam-
menstellung zu Plänen. Aus dem Personal-Ressourcenbedarf und der Aufgaben-
struktur der Projekte kann ein Projektorganigramm abgeleitet werden. Aus
dem Personaleinsatz kann entsprechend der Dauer der Projektaktivitäten und
dem Sachmitteleinsatz ein Projektbudget ermittelt werden. Der Abschluss der
Projektplanung ist mit der Fertigstellung der Projektergebnisse erreicht. Die
Projektplanungsergebnisse sind:
✔ Projektstrukturplan: Aufgabenstruktur des Projekts
✔ Terminplan
✔ Ressourceneinsatzplan
✔ Projektorganigramm
✔ Projektbudgetplan
Ergänzend hierzu können noch ausgewählte Aufgaben zu begleitenden Aufga-
benpaketen zusammengefasst werden:
✔ Qualitätssicherungsplan
✔ Projektfortschrittskontrolle
Der Qualitätssicherungsplan definiert eine zu erreichende Qualität und die
Maßnahmen, die zur Überprüfung der Qualität und zur Sicherstellung einer
vereinbarten Qualität durchgeführt werden müssen. Der Qualitätssicherungs-
plan orientiert sich dabei an den Projektergebnissen. Die Qualitätssicherung
sollte bereits mit dem ersten Projektergebnis, den Projektplänen, einsetzen. Die
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 455
Definition
Die Zusammenfassung aller Planungsarbeiten des Projekts ist die Projektie-
rung. Das Ergebnis der Projektierung sind Projektstrukturplan, Terminplan,
Projektorganigramm, Projektbudgetplan, Ressourcen-Einsatzplan.
➢ Ableitung der Termine aus den Schätzungen für Aufwand bzw. Dauer der
Abwicklung der Aktivitäten
Für die Bearbeitung einer Aktivität ist eine Befähigung in Form einer Qualifika-
tion, z.B. eine spezielle Ausbildung oder Erfahrungen aus anderen Projekten,
erforderlich. Zur Projektierung gehört auch die Benennung der Qualifikationen
zu den Aktivitäten, und wenn das Personalaufgebot feststeht, kann sogar schon
der Name der Projektmitarbeiter eingesetzt werden.
➢ Zuordnung der Mitarbeiternamen bzw. der Qualifikationen zu den Aktivitäten
Am Ende ist noch der Bedarf der Sachmittel festzustellen. Dazu gehören zu
allererst die Räumlichkeiten, in denen das Projekt abgewickelt wird, aber auch
Präsentationsmittel, Entwicklungswerkzeuge und Verbrauchsmaterial.
➢ Aufstellung des Sachmittel- und Raumbedarfs des Projekts
Projekte kosten Geld und kein Projekt hat beliebige Geldmittel zur Verfügung.
Das vorkalkulierte Projektbudget kann sogar zu der Erkenntnis führen, dass
der Nutzen nicht im vernünftigen Verhältnis zum Aufwand steht und dass das
Projekt deshalb nicht durchführbar ist. Aus den ermittelten Personalressour-
cen- und Sachmittelbedarfen muss daher ein Projektbudget abgeleitet werden.
➢ Ableitung des Projektbudgets
Die Beschaffung ist entsprechend der internen Richtlinien darzustellen und
mit Begründungen zu untermauern. Für den Beschaffungsvorgang ist neben
dem zu beschaffenden Objekt, das in der Evaluation aus den Marktangeboten
und Varianten ausgewählt wird, keine Gestaltungsfreiheit gegeben. Die Bestim-
mung des Beschaffungszeitpunkts und des Beschaffungsumfangs liegen noch
im Gestaltungsrahmen des DWH-Spezialisten, die Beschaffung selbst gehört
nicht mehr zu seinen Aufgaben.
Projektdefinition
Die Projektdefinition ist Teil des Projektantrags und enthält die Zielsetzung
und die Abgrenzung zu nicht erwünschten Zielen. Der Projektantrag weist eine
Skizze des Projekts mit Leistungen und Eckterminen aus, und er führt betei-
ligte interne und externe Partner an.
Beispiel: DWH-Projektdefinition
Projektname: Instandhaltungs Data Warehouse für Schadensanalysen
Kurzzeichen InDaWa
Definition In dem zu entwickelnden Data Warehouse werden alle
international und in verschiedenen Datenbanken anfallen-
den, kundenbezogenen Daten wie Verträge, Produkte, Kon-
ditionen, Kaufverhalten, Kunden-Feedback, zusammenge-
führt und ausgewertet mit dem Ziel, neue gewünschte
Produkteigenschaften, bessere Absatzkanäle und neue Mar-
ketingkonzepte zu entwickeln.
Zeitrahmen Das DWH soll in maximal einem Jahr erste Auswertungen
liefern und in einem weiteren halben Jahr fertiggestellt sein.
Checkliste Projektantrag
Der Projektantrag weist einen Budgetbedarf aus. Im Projektantrag wird dem
DWH-Projekt erstmals ein offizieller Name, eine Definition und ein Kurzname
verliehen. Der Projektantrag muss so viele Informationen enthalten, dass auf
der Basis einer Kosten/Nutzen-Relation eine Entscheidung getroffen werden
kann. Jedes Unternehmen hat allgemeine Formvorlagen für Projektanträge,
deshalb sei hier auf einen Formvorschlag verzichtet und statt dessen eine
Checkliste der im Projektantrag enthaltenen Informationen angegeben.
Checkliste Projektantrag
✔ Projektdefinition: Ausführliche Projektbezeichnung, Projektname, Pro-
jektkurzzeichen
Tabelle 8.1: Checkliste Projektantrag
458 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
Für die weiteren Schritte werden im Folgenden Mittel und Methoden vorge-
schlagen. Dem über diese Darstellung hinausgehend an allgemeinen Ausfüh-
rungen zum Projektmanagement interessierten Leser sei empfohlen:
Schelle u.a., Projekte erfolgreich managen
Burghardt, Projektmanagement
Definition: Projektstrukturplan
Der Projektstrukturplan ist die hierarchisch gegliederte Aufgaben- oder
Aktivitätensammlung des Projekts.
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 459
$
#
%$$
(
% !
!#
#$ $) "
-.
/ ,#
%
*
+
&'
0
'
Wie aus den Strukturelementen eine Projektaufgabe formuliert wird, soll das
folgende Beispiel vermitteln.
Demnach ist der Projektstrukturplan das Sammeln und Ordnen der zu erledi-
genden Projektaufgaben mit Hilfe einer Dimensionen- und Kriterienliste. Ein
Beispiel für einen Projektstrukturplan folgt weiter unten unter »Problemlö-
sung«. Es ist zu beachten, dass nicht jede Kombination der Dimensions- oder
Strukturelemente zu einer sinnvollen Projektaufgabe führt.
460 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
Abbildung 8.5: Bestandteile der Leistungsleitlinie
Projektstrukturplan
Für den Projektstrukturplan sind mehrere Dimensionen zu verarbeiten. Die
Reihenfolge der Dimensionen beim Aufbau der Gliederungsebenen ist frei
wählbar und je nach Situation ist eine andere Reihenfolge nützlicher. Zur bes-
seren Einschätzung dieser Strukturformen sind in der folgenden Abbildung für
das gleiche Beispiel drei Gliederungen nebeneinander dargestellt.
! "
! "
! "
! "
! "
! "
Leistungsleitlinie
Als grundlegendes Hilfsmittel
✔ für die Möglichkeiten von Leistungen im Projekt
✔ für die Verpflichtung, die Leistungen in Abhängigkeit vom Projekttyp zu
erbringen
✔ für die Beteiligung der Rollen
ist im Folgenden eine ausführliche, alle Projektphasen umfassende DWH-Leis-
tungsleitlinie, die Leistungsleitlinie für DWH-Vorhaben, dargestellt. Der Über-
sichtlichkeit zuliebe und weil kein abgrenzbar definiertes Ergebnis entsteht, wer-
den die Sekundärleistungen nicht mit in die Leitlinie aufgenommen – mit
Ausnahme der Erstellung des Projekthandbuchs und des Qualitätssicherungsplans.
Da die Leistungsleitlinie ein fundamentales Instrument für die Abwicklung von
DWH-Vorhaben ist, wird hier ein ausführliches Beispiel angeführt.
8.1.3 Terminplanung
Problemstellung und Motivation
Ein Projekt erzeugt Ergebnisse. Die Projektergebnisse werden für andere
betriebswirtschaftliche Prozesse oder für weitere Projektergebnisse als Zwi-
schenprodukt im Verlauf des Projekts benötigt. So ist z.B. die Erfassung von
Prozessen die Grundlage oder das Zwischenprodukt für die Realisierung von
Dialogen. Die Projektergebnisse sind damit Produktionsfaktoren. Als solche
erfordern sie eine termingerechte Beistellung zu den betriebswirtschaftliche
Prozessen oder den Projektprozessen, die durch eine Terminsteuerung sicher-
gestellt werden soll.
Im Extremfall können Projektergebnisse später entstehen als ihr Verwendbar-
keitszeitpunkt erfordert. Ist diese Situation frühzeitig erkannt und nicht mehr
zu ändern, muss das Projekt eingestellt werden. Diese Terminkonflikte zu
erkennen ist ein Ziel der Terminplanung. Bei einem unlösbaren Terminkonflikt
dient die Terminplanung als Abbruchargument.
Der Terminplan eines DWH-Projekts muss die in den vorausgegangenen Kapi-
teln erarbeiteten Gestaltungsschritte enthalten. Es ist ja Aufgabe des DWH-Pro-
jekts, alle Gestaltungsfragen zu klären.
Nach der Entscheidungsfindung ist die entsprechende Umsetzung durchzufüh-
ren, bis das fertige DWH in Betrieb genommen ist. Zu den zu terminierenden
Aufgaben gehört demnach auch die Beschaffung der Produkte, die den getroffe-
nen Gestaltungsentscheidungen genügen.
Sind zum Gestaltungsergebnis keine Produkte erhältlich, müssen die Kompo-
nenten in Eigenentwicklung erzeugt werden. Zu den Leistungen gehört dann
auch die Beschaffung der für die Entwicklung der Systemkomponenten erfor-
derlichen Sachmittel und die Beschaffung von Know-how und Personal.
Strukturierung des Terminplanes
Das DWH besteht aus mehreren Softwaremodulen, die auf verschiedenen Rech-
nern eingesetzt werden. Ein DWH kann auch über verschiedene Lokationen
verteilt sein und es kann unterschiedliche Fachmodule umfassen. Die Auftei-
lung des Terminplanes in kleine Einheiten, die Terminplanstruktur, kann des-
halb auf verschiedene Arten erfolgen:
✔ Fachmodule (Personal, Material, Produktion, Marketing, ...)
✔ Produkte (Produkt x, Produkt y, ...)
✔ Lokationen (Europa, Amerika, Asien, ...)
✔ Software-Architektur-Komponenten (DWH-Server, Data Mining, Archivie-
rung, OLAP, ...)
✔ Phasen (Strategie, Projektierung, Konzeption, Entwurf, Realisierung,
Betrieb)
468 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
Teminplanung
Der Terminplan startet mit der Eintragung der Ecktermine aus dem Projektan-
trag. Innerhalb der Zeitspannen zwischen den Eckterminen müssen die Aktivi-
täten des Projektstrukturplanes der Leistungsleitlinie abgearbeitet werden. Die
Zeitspannen werden in terminierte Positionen aufgespalten. Für die Aufstel-
lung dieser Positionen des Terminplanes dient demnach die aus dem Projekt-
strukturplan abgeleitete fundamentale Leistungsleitlinie. Diese beinhaltet
bereits eine lineare Aktivitätenfolge, ohne jedoch das Parallelisierungspotential
auszuschöpfen und ohne Abhängigkeiten der einzelnen Aktivitäten.
Die Ecktermine sollten vor Projektbeginn durch Befragen der Führungsebene
noch einmal überprüft werden auf:
✔ Vollständigkeit
✔ Aktualität
Einen großen Nutzen stellen die Terminpläne vergangener Projekte dar.
Als grundsätzliches Terminplan-Strukturierungsprinzip wird empfohlen:
1. Entwurf der kompletten Abwicklung zu einer extremen Lokation und einem
Fachmodul bezüglich aller Softwarekomponenten. Aus dieser Planung wird
man Erkenntnisse gewinnen, die man für alle weiteren Planungen nützlich
einsetzen kann.
2. Planung der Hardwarekomponenten und der Organisation für die gleiche
Lokation und das gleiche Modul
3. Planung der weiteren Module der Lokation
4. Planung einer weiteren extremen Lokation
5. Planung aller Lokationen zu einem Modul
6. Fortsetzung der Planung aller Lokationen zu allen Modulen
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 471
Für die darauf folgende Terminplanung mit Ressourcen gibt es zwei Wege:
✔ Die Termine stehen fest und der Ressourceneinsatz muss zur Einhaltung
dieser Termine gestaltet werden.
✔ Die Ressourcen stehen fest und die Endtermine sind aus dem Ressourcen-
einsatz zu ermitteln.
Schätzung der Aktivitätendauer
Die einzelnen Leistungen des DWH-Projekts müssen bezüglich ihrer Ausfüh-
rungsdauer geschätzt werden. Hierfür gibt es mengenbezogene Anhaltspunkte
wie:
✔ Anzahl der zu führenden Interviews
✔ Anzahl von Lokationen
✔ Umfang zu erstellender Textdokumente
✔ Anzahl zu erstellender Programmmodule
✔ geschätzte zu erstellende Programmzeilenzahl
✔ Anzahl der Programmfunktionen
✔ Anzahl der Datenbanktabellen
Zu jedem dieser »Leistungsobjekte« liegen in den Unternehmen Erfahrungs-
werte aus bereits abgewickelten Projekten zur Dauer oder zu den Kosten ihrer
Erstellung vor.
Terminrisiken
Zur Behandlung des Terminrisikos »Technologiewechsel« ist zu empfehlen:
1. Erstellung der Struktur eines Trendprofils mit allen relevanten DWH-Tech-
nologien (siehe Kapitel 1 »Orientierung zum Thema Data Warehouse«)
2. Trendbeobachtung, Erstellen von einzelnen Trendcharts (siehe ebenfalls
Kapitel 1) und Rückfluss in das Trendprofil
3. Beurteilung und Prognose neuer Technologien auf Ablösungszeitpunkt
alter Technologien
4. Austausch bzw. Neuspezifikation, wenn Projekt mit Konzeption fertig und
auch wenn Entwurf begonnen ist
5. Kostenvergleich der Realisierung mit alter Technologie gegen die Realisie-
rung mit neuer Technologie plus Entwurf zur neuen Technologie
6. Nach Realisierung des Projekts Ausrichtung der Schnittstellen auf Anbin-
dung neuer Technologien
Gegen das Terminrisiko »Personalausfall« ist die Doppelbesetzung der Teams
mit wechselseitiger Qualitätssicherung und Vertretungsausübung bei Urlauben
einzuplanen. Schutz gegen den Abzug von Personal bietet nur die Zusage einer
Prioritäteneinordnung des Vorstands gegenüber andern Vorhaben. Bei niedri-
ger Priorität sollte Ersatz definiert, zugesagt und budgetiert werden.
Gegen das Terminrisiko »Managementwechsel« ist kein Kraut gewachsen.
8.1.4 Personalressourcen
Problemstellung und Motivation
Die Rollenbesetzung im Projekt ist Erfolgsfaktor für alle Projektergebnisse.
Projektergebnisse werden von Personen mit Qualifikationen erzielt. Die gute
Qualität der Ergebnisse ist nur mit gut qualifiziertem Personal erreichbar. Die
zu erzeugenden Projektergebnisse sind in der Leistungsleitlinie festgelegt.
Qualifikationen
Die Qualifikationen müssen entsprechend den in der Leistungsleitlinie ausge-
wiesenen Aufgaben eingesetzt werden. Bei neuen Projekten ist diese in der
Regel erst aufzubauen. Die Aufgabe des DWH-Projektleiters ist dann, nach Qua-
lifikationen Ausschau zu halten, die schnell und sicher auf die Anforderungen
erweitert werden können.
Für die Durchführung eines DWH-Projekts sind gegenüber anderen DV-Projek-
ten besondere Qualifikationen erforderlich:
✔ Administration des DWH-Servers
✔ Administration des DWH-Archivs
474 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
Definition: Personaleinsatzplan
Ein Personaleinsatzplan ist die tabellarische Darstellung der in einem Pro-
jekt, einem Vorhaben oder für dauerhafte Unternehmensaufgaben eingesetz-
ten Personen mit Einsatzzeiten, die entlang einer Zeitachse in einer Zeit-
größe wie Stunden oder Tage notiert sind.
SCHULUNGEN
ls
N ien en e ls oo
LA -D typ tem oo gst
A tw eth ati en are
e
W d er f re
A e s s n
ik k w
ar
M l - e t
B in E den nen
en
D un rv -So wa
S H-M pl an oft
D S-S ien ho lle
D -K ns ge ft
tw
ch he na ha
t
M n m m
nt
ec b t ic
e r ft
W p n S
W e t- w
dm ar o o
D H-A te ce-
Fa g e a t s c
P H-S rve So
R rie tra tw
ne
om te
b
et is n
po
W a fi
r tm ir
-K s
D -D Of
Vo j e k sw
N r
ro b
P rie
B ht
H
ec
et
of
ROLLE/STELLE
C
R
Vorstandssponsor
Projektleitung
Teilprojektleitung
Projektassistent
Fachanwender
Systemanalyse
Systemingenieur
Programmierung
Systemadministration
8.1.5 Sachmittelplanung
Problemstellung und Motivation
Projektsachmittel sind Produktionsfaktoren. Sie unterstützen die Produktion
von Projektergebnissen und ermöglichen diese sogar erst. Die Bestimmung der
Sachmittel ist erst mit der Definition der Aufgaben möglich. Ob ein Entwurfs-
werkzeug für relationale Datenbanken benötigt wird, ist z.B. erst klar, wenn der
Einsatz relationaler Datenbanken entschieden ist.
Für die Abwicklung eines Projekts sind geeignete Sachmittel unterschiedlichs-
ter Art erforderlich. Das beginnt mit dem Ort, an dem das Projektteam sitzt, und
den Räumen, in denen die Projektarbeit durchgeführt wird. Zu den Räumen
zählt die Büroausstattung mit der Infrastrukturanbindung einschließlich der
Telekommunikationsmittel wie Telefon, ISDN-Anschluss, Stromnetz und
Anschluss an das bestehende lokale Netzwerk. Die Sachmittel umfassen auch
Rechner, Werkzeuge, Software, Ersatzteile, Kleinmaterial und Präsentations-
mittel. Die Sachmittel können zu folgenden Gruppen zusammengefasst werden:
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 477
✔ Funktionsmodellierer
✔ Datenmodellierer
✔ Dialogmodellierer
✔ Aggregationsdiagramme
✔ Datenquellendiagramme
Für die Aufstellung von Termin- und Personaleinsatzplänen sind Projektma-
nagementprogramme unverzichtbar.
✔ Projektmanagementprogramm
✔ Netzplanungsprogramm
✔ Schichtplanungsprogramm
Zur Zusammenstellung einzelner Arbeitsergebnisse sind Groupworking-Tools
nützlich.
Programmierwerkzeuge
Für die Erzeugung von Programmen und Datenbanken sind Generatoren nütz-
lich. Generatoren können von einer in der Umgangssprache oder in einer Fach-
sprache nach bestimmten vorgegebenen Regeln formulierten Vorschrift ein
Programm generieren. Sie können auch aus der grafischen Darstellung einer
Datenbankbeschreibung die Datenbank erzeugen. Generatoren können außer-
dem aus einer bestehenden Datenbank Masken für den Benutzerdialog mit Ein-
gaben in die Datenbank erzeugen.
✔ Datenbankschemagenerator
✔ Codegeneratoren
✔ Testfallgeneratoren
480 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
✔ Formatkonvertierer
✔ Cross-Compiler
✔ Maskengenerator
✔ Dialogsimulatoren
Zu den Tools gehören auch die in Kapitel 4 »Softwarekomponenten« genannten
Programmierwerkzeuge, die für die Erstellung der DWH-Programme einge-
setzt werden:
✔ 3GL-Compiler
✔ 4GL-Precompiler
✔ Datenbankmanagementsystem
✔ Data Miner
✔ Reportingtools
✔ Middleware
✔ DWH-Server
Präsentationsmittel, Moderationsmittel
Die Projektergebnisse müssen regelmäßig und auch ad hoc allen Projektteil-
nehmern vorgestellt werden. Die Unternehmensöffentlichkeit ist schon sehr
früh mit dem Projekt vertraut zu machen. Internes Marketing für die beabsich-
tigten Verbesserungen erleichtert die Projektarbeit wesentlich. Projektergeb-
nisse müssen kommuniziert und für die Kommunikation mit unterschiedlich
ausgebildeten Fachkräften aufbereitet werden. Projektergebnisse müssen prä-
sentiert und zur Diskussion gestellt werden. Hierzu dienen Präsentationsmittel
und Moderationsmittel.
✔ Moderationskoffer
✔ Flipchart
✔ Pinwand
✔ Overheadprojektor
✔ Videobeamer
Informations- und Informationsverwaltungsmittel
Ebenfalls für die Produktion erforderliche Sachmittel sind Informationen,
Tipps, wie etwas am besten durchgeführt wird, was man mit welchem Werkzeug
wie machen sollte. Informationen sind in Form von Know-how-Trägern und in
Form von Schulungen beschaffbar; dann sind sie als Personalressourcen zu pla-
nen. Informationen sind auch in Form von Studien und Büchern beschaffbar;
in diesem Falle sind sie den Sachmitteln zuzuordnen. Solche Sachmittel sind
alle Arten von Literatur und Papierunterlagen, wie die Projektbibliothek mit
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 481
Raumbelegungspläne
Raumbelegungspläne sind im Unternehmen vorhanden. Es sind Matrizen, die
aus einer vertikalen Raumliste und einer horizontalen Zeitachse in Tagen beste-
hen. Diese Matrix eignet sich jedoch kaum für die Mehrfachbelegung von Räu-
men an einem einzelnen Tag. Eine Variante, die das erlaubt, ist eine Acht-Stun-
den-Matrix pro Raum. Die vertikale Skala ist dann die Stundenleiste.
Für die Gestaltung und Ausstattung der Büroräume sind Raumpläne und
Raumausstattungspläne mit einer Symbolik für Büromöbel das geeignete Mit-
tel. Die Pläne sollten vom Facilitymanager bzw. vom Vermieter zur Verfügung
gestellt werden.
Sachmitteleinsatzpläne
Für die Erstellung der Sachmitteleinsatzpläne kann die folgende Liste Check-
liste Sachmittel für DWH-Projekte verwendet werden.
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 483
Gruppe
Mittel Raum Ausstattung Anzahl
Räume
Besprechungszimmer groß 15 Personen
Besprechungszimmer klein 4 Personen
Büroräume
Entwicklerraum
Server-Raum
Tools
Mindmapping
Entwurfswerkzeuge Daten-, Dialog-, Funktionsmodelle
Visualisierungssoftware
Aggregationsdiagramme
Datenquellendiagramme
Projektmanagementprogramm Netzplanung, Schichtplanung
Officeprogramme
Officeprogramm für Workgroups
Zentrales Terminverwaltungsprogramm
Dokumentenmanagementprogramm Workflow
Archivierungssystem
Mailingsystem
Entwicklungssysteme
Datenbankschema-Generator
Code-Generatoren
Testfallgeneratoren Workflow
Formatkonvertierer
Cross-Compiler
Protyper Maskengenerator, Dialogsimulator
3GL-Compiler
4GL-Precompiler
Datenbankmanagementsystem
Data Miner
Reportingtools
Middleware
DWH-Server
Präsentationswerkzeuge
Moderationskoffer
Flipchart
Pinwand
Overheadprojektor
Videobeamer
8.1.6 Budgetierung
Problemstellung und Motivation
Kein Projekt kommt ohne ein Budget aus, denn jedes Projekt kostet Geld. Es
muss Personal aus dem Unternehmen für die Abwicklung der Projektaufgaben
freigestellt werden. Das Personal bezieht Gehälter. Personalkosten werden mit
einem internen Verrechnungssatz auf die Projektkosten verrechnet.
Projekte sollen Ergebnisse erzeugen, die es ermöglichen, andere Prozesse des
Unternehmens effizienter abzuwickeln. Das bedeutet, dass die Kosten für die
Erreichung einer Effizienzsteigerung nicht höher sein sollen als die Kostener-
sparnis durch die bessere Effizienz. Der Nutzen muss die Kosten übersteigen.
Transparenz in die Kosten-Nutzen-Lage kommt durch eine genaue Kostenanalyse
des zukünftigen Projekts. Die Kosten werden zu einem Budget zusammengefasst.
Erst die klare Darstellung des Budgets erlaubt eine Genehmigung des Projekts.
484 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
Aufwand
Mit den Entscheidungen für den betriebswirtschaftlich-funktionalen Umfang
der Software kann erstmals grob die Dauer der Herstellung, der sogenannte
Aufwand, kalkuliert werden. Das ist z.B. die Arbeitsdauer, mit der
✔ die Software entworfen und programmiert wird
✔ das Projekt geleitet wird
✔ die Beschaffungen durchgeführt werden
✔ die Hardware aufgebaut wird
Der Begriff »Aufwand« wird oft synonym als Zeiteinheit, in Minuten, Stunden,
Tagen oder Wochen formuliert. Die Wahl der Zeiteinheit hängt von der Projekt-
dauer und von der Art der Tätigkeiten ab. Ein besonders langes Projekt, z.B. ein
DWH-Vorhaben über mehrere Jahre, kann nicht in Minuten geschätzt werden,
hier wird im Projektantrag mit Monaten, in der ersten Aufwandsschätzung mit
Wochen und in der Verfolgung mit einer Stundenaufschreibung gearbeitet.
Andererseits sind außerhalb von DWH-Projekten auch Sekundenmessungen
üblich, z.B. bei Akkordarbeiten in Werkstätten.
Der Begriff »Aufwand« wird oft auch und synchron als Kosteneinheit formu-
liert. Ist der Aufwand als Kosten dargestellt, werden die Stunden oder die Tage
der Leistung der Personen mit einem internen Tages- bzw. Stundensatz ent-
sprechend der Qualifikation der Person bewertet.
Definition: Aufwand
Der Aufwand einer Aktivität ist die in einer Zeiteinheit gemessene Arbeits-
zeit zur Erledigung der Aktivität oder die mit Kostensätzen bewertete
Arbeitszeit.
Leistungsverrechnung
Das Budget muss unter Umständen auf Firmenteile, wie z.B. Niederlassungen
oder Profitcenter, umgelegt werden können; das ist die sogenannte Leistungs-
verrechnung. Hierfür ist eine verursachungsgerechte Darstellung der Budget-
positionen wichtig. Das bedeutet, es muss deutlich werden, welche Investitio-
nen und welche Aufwände für welche Firmeneinheit erbracht wurden. Für die
allen zugute kommenden Investitionen und Aufwände, wie z.B. ein zentraler
Server, muss ein Umrechnungspreis gefunden werden. Der Umrechnungs-
schlüssel kann z.B. die Nutzerzahl, Nutzungsdauer, der Funktionsumfang oder
die Datenmenge sein.
Ein Budget muss zur Nachvollziehbarkeit für die Verrechnung transparent
sein. Die Transparenz wird erreicht durch eine genügend feine Detaillierung
der Budgetpositionen.
486 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
Budgetschema
Die Struktur des Schemas der Budgetprüfung muss deckungsgleich mit dem
Detail-Budgetschema sein. Als Hilfsmittel ist ein Beispiel für ein Budgetschema
dargestellt. In dieser Budgetdarstellung ist die Verteilung
✔ auf Länder
✔ nach Aufwänden (Schulungen, Softwareentwicklung, Projektmanagement)
✔ nach Investitionen (Hardware, Software)
durchgeführt worden (siehe Abbildung 8.12).
Erfahrungsdatenbank
Für die Aufwandsschätzung sind Erfahrungswerte nützlich. Bei einem Unter-
nehmen mit vielen Projekten kann eine Erfahrungsdatenbank selbst aufgebaut
werden. Erfahrungswerte können auch auf Konferenzen zu ähnlichen Projek-
ten erfragt werden. Das Problem hierbei liegt in der Vergleichbarkeit der Pro-
jekte. Um Analogieberechnungen anstellen zu können, sind die Projekterfah-
rungen vergleichbar zu machen. Das folgende Beispiel aus einem realisierten
Projekt soll verdeutlichen, wie die Erfahrungen formuliert sein können.
(
!$%&'
(
!$%
(
(
(
Im Folgenden wird nun zunächst die für den ersten Lebensabschnitt des DWH,
den Aufbau, erforderliche Organisationsstruktur ermittelt, um darauf aufbau-
end die Projektprozesse zu definieren.
8.2.1 Aufgaben, Rollen, Stellen und Organisationsstruktur für den Aufbau des DWH
Problemstellung und Motivation
Bevor es ein DWH gibt, muss festgestellt werden, wie das Organisationsobjekt
DWH beschaffen ist, welche Architektur es bekommen soll, welche Eigenschaf-
ten es haben soll, welche Bedürfnisse der Anwender es erfüllen soll. Es handelt
sich ja bei einem DWH um ein System für Softwareanwender. Diese angestrebte
Beschaffenheit ist in den vorausgegangenen Schritten der Gestaltungsentschei-
dungen zur betriebswirtschaftlichen Funktion, zur Softwaretechnologie und
zur Hardware geschehen. Zur Erreichung dieser Beschaffenheit eines DWH ist
eine Organisationsstruktur erforderlich, die den Aufbau des DWH bewirkt oder
als Träger der Organisationsprozesse dienen kann. Diese Organisationsstruktur
ist bestimmt, wenn, wie im vorhergehenden Kapitel erläutert, Aufgaben, Stel-
len, Rollen, Kompetenzen, Qualifikationen definiert sind.
DWH-Vorstandssponsoring
Kein Projekt kann ohne die Rückendeckung aus der obersten Führungsetage
effizient abgewickelt werden. Gibt ein Vorstand öffentlich sein Interesse am
Gelingen des Projekts zu erkennen, werden alle anderen Führungskräfte Koo-
perationsbereitschaft signalisieren. Sie ist besonders für DWH-Projekte nötig,
da diese bereichs- und abteilungs- und sogar firmenübergreifend auf Know-
how und auf Ressourcen zugreifen müssen.
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 491
Schema relationaler Datenbanken wird z.B. mit der Methode Entity Relation-
ship Modell spezifiziert. Für die Systemanalyse sind Hilfsmittel zur Beschrei-
bung und grafischen Darstellung der Ergebnisse der Erhebungen erforderlich.
Die Entwurfsarbeiten können durch Entwurfswerkzeuge unterstützt werden.
Sie müssen, wenn noch kein Unternehmensstandard existiert, aus den Markt-
angeboten ausgewählt und beschafft werden. Die Rolle »Systemanalytiker für
DWH« muss den Einsatz von Entwurfswerkzeugen beherrschen.
Da die Entwurfsmethoden für DWH die Entwurfsmethoden für Daten-
bankapplikationen einschließen, sind DWH-Systemanalytiker auch für Applika-
tionen außerhalb des DWH einsetzbar. Eine Grundkapazität für die Systemana-
lyse ist dauerhaft erforderlich, was die Einrichtung wenigstens einer Stelle
sinnvoll macht. Die Rolle »Systemanalyse« wird für große Unternehmen durch
mehrere Stellen mit unterschiedlichen Spezialisierungen fixiert werden. In
Kleinunternehmen wird die Rolle der Systemanalyse meistens vom Hauspro-
grammierer wahrgenommen.
Die Aufgaben der DWH-Systemanalyse sind:
✔ Ist-Erhebung durch Dokumentenrecherche, Datenbankauswertungen und
Interview
✔ Fachliche Konzeption von DWH-Applikationen
✔ Spezifikation DWH-Applikationen
✔ Fachliche Betreuung der Anwender
✔ Einsatz von Entwurfswerkzeugen
✔ Moderation von Expertensitzungen
✔ Präsentation von Ergebnissen
Der Systemanalytiker ist für die Dauer des DWH-Projekts dem Projektleiter
unterstellt.
DWH-Programmierung
Die vom Systemanalytiker spezifizierten Programme werden vom Programmie-
rer mittels einer Programmiersprache, die Bestandteil einer Softwareentwick-
lungsumgebung ist, zu einem lauffähigen Programm ausprogrammiert. Das
Programm wird in der Entwicklungsumgebung getestet und in die Produkti-
onsumgebung implementiert.
Einige Softwarekomponenten sind fertig entwickelt vom Markt zu beschaffen
und bestenfalls mit Einstellungen auf die individuellen Bedürfnisse anzupas-
sen. Das Customizing sowie das Evaluieren und Installieren von Schnittstellen
ist Aufgabe des DWH-Programmierers. Der DWH-Programmierer sorgt für die
Bereitstellung und die Migration der Daten.
Das Know-how der Programmierer muss bei der Evaluation der Programmier-
werkzeuge und eventuell sogar zur Beschaffung der Systeme der DWH-Applika-
494 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
tionen einbezogen werden. In Kleinfirmen nimmt oft eine Person die beiden
Rollen »Systemanalyse« und »Programmierung« wahr. DWH-Projekte sind
jedoch so umfangreich und so vielfältig in den eingesetzten Programmtypen,
Methoden und Produkten, dass eine Rollentrennung unumgänglich ist. Da in
einem DWH auf Programmebene ständig Anpassungen vorzunehmen sind, ist
die Einrichtung einer Stelle DWH-Programmierung angemessen.
Die Aufgaben des DWH-Programmierers sind:
✔ Evaluation der Softwarekomponenten der Entwicklungsumgebung
✔ Umsetzung der Spezifikationen zu lauffähigen Programmen
✔ Programmierung von Schnittstellen
✔ Customizing von Standardsoftware
✔ Konzeption von Teststrategien und Generierung von Testfällen
✔ Durchführung von Labortests
✔ Implementierung von Produktionsumgebungen
Der DWH-Programmierer berichtet für die Dauer des Projekts an den Projekt-
leiter. Er sollte von anderen Programmieraufgaben für die Dauer des Aufbaus
des DWH befreit werden.
Administration DWH-Entwicklungssysteme
Die Aufgabenstellung der »Administration DWH-Entwicklungssysteme«
umfasst die Sicherstellung des Betriebes der kontinuierlichen Entwicklung der
DWH-Anwendungen über das Gesamtnetz. Den Anforderungen an die Qualifi-
kation entsprechend, besonders wegen der Hardwarelastigkeit der Kenntnisse,
ist die Rolle der »Administration« von den Rollen »Systemanalyse« und »Pro-
grammierung« zu trennen. In der Projektphase wird nur die Entwicklungsum-
gebung zu betreuen sein. In der Betriebsphase steht die Betreuung aller DWH-
Systeme an. Je nach Umfang des Systems – die Spanne reicht von einem klei-
nen OLAP-Server bis zu einem System aus weltweit verteilten, gekoppelten
Rechnern für DWH, Datamarts, OLAP, Archivierung – ist die Rolle »DWH-
Administrator« durch eine bis mehrere Stellen zu besetzen. Eventuell ist dies
schon in der Projektphase nötig, auch um hier eine Vertretungskapazität
sicherzustellen.
Die Aufgaben der DWH-Systemadministration sind:
✔ Evaluation und Auswahl der Rechner für die Aufbauphase (Entwicklungs-
umgebung) sowie später für die Betriebsphase
✔ Konfiguration der Rechnerhardware, Betriebssysteme
✔ Installation der Server-Komponenten des DWH
✔ Installation der Client-Komponenten des DWH
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 495
! ! !
# #
$
#
#
"
#
#
$ # # #
#
!
"#
#
" #
%
!
!
" #
" #
#
" #
!
" # # #
" #
" #
Großunter
Kleinfirma Mittelstand
nehmen
Vorstandssponsoring VS VS
GF
Bereichsleitung BL GF BL
BL
Betriebsrat BR PL BR BR
Projektleitung PL PL
PL
TPL TPL
Fachbetreuung BE BE
BE
BE SA
Systemanalyse SA SA
SA
PR
Programmierung PR PR
AD PR
AD
Administration AD AD
Abbildung 8.15: DWH- Besprechungskreise Aufbauprojekt
Personal für ein »fremdes Projekt« freiwillig ab. Der Projektleiter muss sich
hier mit guten Argumenten, die auch Vorteile für die Vorgesetzten des freizuge-
benden Personals aufzeigen, wappnen. Hier kann auch der Sponsor hilfreich
sein; manchmal ist er sogar der letzte Ausweg zur Freigabe des Personals.
Rollen und Stellenanforderungen
Für die Lösung der Frage nach den Rollen und Stellen und auch nach der Orga-
nisationsstruktur kann man aus den Erfahrungen im eigenen Hause schöpfen.
Das DWH ist ja nicht das erste System, welches das Haus betreibt, und deshalb
sind schon Aufgabenbeschreibungen und Rollendefinitionen aus dem Betrieb
der vorhandenen Software bekannt.
Als Gestaltungshilfe kann hier eine Liste stellenspezifischer DWH-Anforde-
rungen beigestellt werden. Die Anforderungen gelten in ähnlicher Ausprägung
auch für die Lebensabschnitte Betrieb und Abbau des DWH
Checkliste: Stellenbeschreibung
Die Form und der Aufbau der im Unternehmen bereits vorhandenen Stellenbe-
schreibungen und die Stellenausschreibungen in den Zeitschriften können als
Muster verwendet werden. DWH-Projekte sind, wie man bereits erkennen
konnte, ehrgeizige Projekte, die man nur mit dem Blick auf das gesamte Unter-
nehmen erfolgreich durchführen kann. Das dadurch bedingte große Spektrum
zu lösender Aufgaben von Betriebswirtschaftskenntnissen bis zur Hardware,
von alten bestehenden IT-Lösungen wie von neuen Technologien, erfordert
daher viel stärker als in der traditionellen Anwendungsentwicklung Personal
mit Weitblick und breit gefächertem IT-Know-how. Diese Herausforderung,
aber auch die Anforderung, sollte in der Stellenbeschreibung zum Ausdruck
kommen.
Obwohl einige Rollen, wie z.B Projektleitung, keine Stellen sind, wird die Per-
sonalsuche üblicherweise als Stellenausschreibung kundgetan. Zur Unterstüt-
zung sei deshalb eine Checkliste Stellenbeschreibung aufgeführt. Ausformu-
lierte Stellenbeschreibungen sind im Anhang aufgeführt.
Checkliste Stellenbeschreibung
STELLENBESCHREIBUNG FÜR Titel:
Positionsbeschreibung
Gültigkeit: Dauer, Ort, Module, Systeme, Phase
Ziel der Projektleitungsarbeit
Qualität, Termine, Kosten, Umsätze, Partnerschaften, Werbung, Führung
Grundsatz
Politik, Kulturen, Projektsprache, Führung
Stellvertretung
Stellvetretername, Einsatz, Übergabe
Aufgaben
Ergebnisse, Berichte, Evaluation, Beschaffung, Qualifikationsaufbau, Realisierung, Auf-
sicht, Organisation, Beratung, Training, Entwurf, Konzeption, Programmierung
Verantwortung
Personal, Budget, Termine, Leistungen, Qualität, Ansehen, Know-how-Sicherung
Eingliederung
Berichtsweg, Linieneingliederung
Befugnisse
Tabelle 8.5: Checkliste Stellenbeschreibung
504 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
Entwicklungsprozess
Die Entwicklung des DWH durchläuft einen mit den Interessenten und Auf-
traggebern verabredeten Turnus aus »Bestellen – Erzeugen – Testen – Abneh-
men – Dokumentieren«. Der Entwicklungsprozess ist im Rahmen des Prozes-
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 505
"
!
# $
!
des Projekts müssen mit dem Vorgehensmodell und der daraus resultierenden
Leistungsleitline synchronisiert werden.
Da das DWH-Projekt über einen längeren Zeitraum von mehreren Monaten
abgewickelt wird, ist eine kontinuierliche Analyse der Situation erforderlich.
Für die Analyse dient der Projektbericht, der mit monatlicher Aktualität ver-
fasst werden sollte. Für die Kostenverfolgung ist über die Einrichtung neuer
Kostenstellen, Kostenarten und Kostenträger (eventuell sogar Kostenprozesse)
zu entscheiden. Der Projektmanagementprozess des DWH startet mit der
Abgrenzung der Projektziele nach Leistungen und Ergebnissen, der Setzung
der Ecktermine und der groben Berechnung der Aufwände zur Erreichung der
Ergebnisse. Zu gestalten sind demnach:
➢ Definition des Projekts, der Projektziele und Ergebnisse, des Aufwandsrah-
mens
➢ Definition des Muster-Projektberichts
➢ Einrichtung von Kostenstellen, Kostenarten und Kostenträger
➢ Kontinuierliche Erfassung der Berichtsgrößen des Projekts: Ergebnisse,
Aufwände, Termine
Bei besonders langen, über mehrere Jahre dauernden Projekten, ist eine Jah-
resrevision zu empfehlen. Diese Revision überprüft die Ausgangsprämissen,
unter denen das Projekt gestartet wurde, und stellt sie der Unternehmens- und
Umweltsituation erneut gegenüber, um die Notwendigkeit von Kurskorrektu-
ren festzustellen. Bei besonders schnellebigem Umfeld ist sogar ein halbjährli-
cher Statusbericht erforderlich. Das Ergebnis der Jahresrevision ist ein Status-
bericht.
➢ Definition des Muster-Jahresstatusberichts
➢ Erstellung des Jahresstatusberichts
Es sind die Projektprozesse in die bestehende Organisation (Struktur wie auch
Prozesse) zu implementieren.
➢ Implementierung der Projektprozesse
Ebenso ist die Prüfung der Ergebnisse, die beim Durchlaufen einer Methoden-
kette entstehen, also die Prozesse der Qualitätssicherung, entsprechend dem
verabredeten Vorgehensmodell organisiert. Dieser Prozess und der Prozess der
Softwareentwicklung ist in Kapitel 7 »Das Vorgehensmodell für Data Ware-
house Systeme« besprochen.
Die Gestaltungsaufgabe bezüglich des Qualifizierungsprozesses besteht in der
Feststellung des vorhandenen Know-hows der einzelnen Teammitglieder, auch
des Vorstands, der Formulierung der Qualifizierungsziele und der Darstellung
des Weges vom Ist zum Soll:
510 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
Der Entwicklungsprozess
Der zentale Prozess des DWH-Vorhabens, der Entwicklungsprozess ist in Kapi-
tel 7 »Das Vorgehensmodell für Data Warehouse Systeme« beschrieben und
wird in einer Entwicklungsrichtlinie festgehalten. Je nach Projektgröße enthält
diese Entwicklungsrichtlinie Programmbausteine, Nomenklaturen, Testverfah-
ren und ähnliches.
Projektberichtswesen
Das Projektberichtswesen muss auf das Vorgehensmodell zur Entwicklung des
DWH abgestimmt sein. Das Vorgehensmodell definiert ja die zu erzeugenden
Projektergebnisse in den einzelnen Projektetappen und das Projektberichtswe-
sen berichtet über die Fortschritte in der Erstellung dieser Projektergebnisse.
Der Aufbau eines Projektberichts und aller anderen Verfolgungsmittel ist im
vorangegangenen Text vorgestellt.
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 511
Checkliste Projekthandbuch
Ist die Personalstruktur des Projekts geklärt, müssen die Projektverwaltungs-
mittel hergestellt und die Projektgrundinformationen zusammengestellt wer-
den. Am besten eignet sich eine eigens für das Projekt erstellte Organisations-
richtlinie, ein Projekthandbuch. Als Hilfsmittel ist im Folgenden ein
Musteraufbau Projekthandbuch dargestellt. Ein Projekthandbuch, das nur
wenige Änderungen durchläuft, sich also auf einen für das Projekt statischen
Teil beschränkt, umfasst folgende Informationen:
✔ Dokumentationsrichtlinie
✔ Projektbudgetierung
✔ Terminierung
✔ Organisationsstruktur
✔ Vorgeschriebene Arbeitsmittel
Checkliste Projekthandbuch
Projekthandbuch
Projektdefinition
Name, Kurzname für Projektdokumente, Directory-Namen
Projektziele
messbare Kriterien, die ein Erreichen überprüfen lassen
Aufgaben
Grobstruktur, in Phasen und Teilphasen, mit Eckterminen und Ergebnissen
Organisation
Struktur, Teilprojekte, Mitglieder,
Prozeduren und Genehmigungsverfahren, Abnahmen, mitgeltende Richtlinien
Hilfsmittel
Werkzeuge, Formatvorlagen, Informationsmittel
Tabelle 8.6: Checkliste Projekthandbuch
Projektrichtlinien
Das Projekt unterliegt mit zunehmender Erkenntnis einem gewissen Wandel,
der dazu zwingt, das Projekthandbuch von Zeit zu Zeit zu aktualisieren. Die
Aktualisierungen können durch Ausgliedern der sich schnell verändernden
Teile als ergänzende Projektrichtlinien minimiert werden. Das bedeutet umge-
kehrt, dass alle schnell veränderlichen Informationen aus dem Projekthand-
buch ausgegliedert werden sollten, um häufige Auflagen zu vermeiden.
512 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
Qualitätssicherung
Die Qualitätssicherung besteht in der Überprüfung der einzelnen Projektergeb-
nisse bezüglich der Qualität, Form und Inhalte. Die prinzipiellen Vorgaben, die
Integration in die QS des Unternehmens und die Abwicklung können dem
Organisationshandbuch des Unternehmens entnommen werden. Die allgemei-
nen Vorgaben werden danach auf die in der Leistungsleitlinie definierten Pro-
jektetappenergebnisse umgelegt. Die Leistungsleitlinie schreibt die Verwen-
dung der Methoden und Tools entsprechend den Leistungspositionen vor.
Beschaffungsprozess
Die prinzipiellen Vorgaben des DWH-Beschaffungsprozesses, die Integration
in die Beschaffung des Unternehmens und die Abwicklung können dem Organi-
sationshandbuch des Unternehmens entnommen werden.
Qualifizierungsprozess
Der DWH-Qualifizierungsprozess besteht aus Statuserhebung, Anforderungs-
definition und Konzeption der Qualifizierung. Die Statuserhebung zur Qualifi-
kation der Teammitarbeiter wurde schon in Kapitel 1 »Orientierung« vorge-
stellt. Die Qualifikationsanforderungen sind in den »Listen stellenspezifischer
Anforderungen« im Abschnitt »Aufgaben, Rollen, Stellen...« dieses Kapitels
und in Kapitel 6 »Organisation« dargestellt.
Die Differenz zwischen Qualifikationsanforderungen und Qualifikationsstatus
wird durch Schulungen und Know-how-Erwerb in der praktischen Projektar-
beit erreicht. Die Schulungen sind umfangreich und müssen in einem Schu-
lungskonzept geplant werden. Bei der Planung ist zu beachten, dass genügend
Zeit zur Festigung des Wissens und der Fertigkeiten im Projekt bleibt.
➡ Als Faustwert kann gelten, dass für eine Y Tage umfassende Schulung eine
Zeit von wenigstens zehn mal Y Tage an Projektarbeit zur Festigung des
erworbenen Wissens eingeräumt werden muss.
Projektsoziologie
Implementierung von Organisation ist ein soziologischer Prozess, der von Inte-
ressen gesteuert wird, der auf Zuneigung und Abneigung stößt, der Ängste her-
vorruft, die bis hin zur Existenzbedrohung verstanden werden müssen. Zur
Implementierung von Organisation können daher keine Systematik und kein
Schema, keine vorproduzierten Muster, keine Daten und Richtgrößen angebo-
ten werden. Es kann nur der Appell an das Projektteam gerichtet werden, die
Augen offen zu halten, alle Meinungsströmungen intensiv wahrzunehmen und
mit vollem Ernst und Aufgeschlossenheit den Anwendern und ihren Problemen
gegenüber zu stehen. Die intensivste Gegenwehr wird vor der Projektierung
mobilisiert. Ist das Projekt erst einmal gestartet, lehnen sich die Gegner zurück
und beobachten aus sicherer Entfernung, was alles schief geht, und schmieden
Pläne, welchen Nutzen sie aus den Schieflagen ziehen können.
➡ Der DWH-Projektleiter muss firmenpolitisches Feingefühl besitzen.
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 513
8.3.1 Beschaffung
Problemstellung und Motivation
Die Beschaffung startet mit der Bedarfserhebung. Alle Beschaffungsmaßnah-
men dienen der Erzeugung von Ergebnissen und sind damit Produktionsfakto-
ren, wie in dem Modell, das bereits in den Kapiteln 2 bis 6 zu den Architektur-
entscheidungen dargestellt wurde. Die Verantwortlickeit des DWH-Spezialisten
endet in der Regel bei der Beschaffung der Sachmittel. Das bedeutet, für die
Beschaffung von Finanzmitteln ist er nicht mehr zuständig.
Auf die Erfassung des Bedarfes folgt die Auswahl unter den angebotenen Pro-
dukten nach Qualität, Preis und Lieferzeit. Die Bestellung wird formuliert, zur
Genehmigung eingereicht und an den Lieferanten gegeben. Nach der Bedarfs-
formulierung sind Beschaffungsentscheidungen zu treffen. Die Beschaffungs-
514 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
eingesetzt werden sollen und mit welchen Methoden Ergebnisse erarbeitet wer-
den. Die Personalbeschaffung muss daher in der frühen Phase des Projekts
noch mit ungenauen Anforderungen arbeiten.
Ein weiteres Problem der Qualifikationsbeistellung zum Projekt ist die Reprä-
sentanz der Interessen der Niederlassungen. Bei internationalen Projekten
sollte jedes Land durch einen Länderrepräsentanten vertreten sein. Dieser
Repräsentant muss die Spezialitäten der Anforderungen seiner Niederlassung
gegenüber den anderen Niederlassungen kennen und darstellen können, sonst
können länderspezifische Anforderungen nicht realisiert werden.
Sonderfall: Informationsbeschaffung
Die Informationsbeschaffung wurde bereits ausführlich im Zusammenhang
mit der Trendbestimmung dargestellt. Es wurde erwähnt, dass der Informati-
onsbedarf auch mit geschickter Personalbeschaffung gedeckt werden kann.
Dies ist zwar der teuerste Weg, aber auch der effizienteste. Gutes Personal hat
Know-how im Aufbau von DWH-Systemen oder in der Systemanalyse zur Erfas-
sung der Requirements oder im Umgang mit DWH-ähnlichen Realisierungs-
werkzeugen.
Gibt es auf dem IT-Markt keine Know-how-Träger für das DWH, muss entweder
das Know-how erarbeitet, also mit einem langwierigem Trial and Error entwi-
ckelt oder per Beratung eingekauft werden. Der effizientere Weg ist der Zukauf
von Beratern. Auch wenn Beratung teuer ist (Tageshonorare beratender Spezia-
listen bewegen sich zwischen 1.000 und 5.000 DM), so ist der Know-how-Trans-
fer über vorübergehende organisatorische Integration beschleunigend. Gut
beratene Projekt sind erheblich schneller auf Erfolgskurs.
Zur Beschaffung gehört auch die Auswahl der Schulungen für das Projektper-
sonal. Schulungsbedarf besteht bezüglich der Installation und Administration
aller DWH-Module, der Anwendung der Entwurfswerkzeuge und der Entwurfs-
methodik und bezüglich Projektführung und Moderation sowie zur Präsenta-
tion von Ergebnissen.
Daneben sollte der Produktmarkt der DWH kontinuierlich in der Literatur ver-
folgt werden. Es ist schon oft vorgekommen, dass Projekte, die mit der ver-
meintlich aktuellen Technologie gestartet sind, von neuen Entwicklungen
überholt wurden. Wenn man nicht permanent beurteilt, was der Markt an Neu-
erscheinungen bietet, riskiert man, dass man zum Abschluss des Projekts mit
veralteter und teurer Technologie dasteht.
Verfahren: DWH-Beschaffungen
❖ Bestimmung des Beschaffungszeitpunkts der Sachmittel
❖ Auswahl der Sachmittel aus dem Marktangebot
❖ Implementieren, Installieren, Aufstellen der Sachmittel
❖ Bestimmung des Beschaffungszeitpunkts von Personal
❖ Einstellungsgespräche bei externem Personal
❖ Verfügbarkeitsgespräche und Qualifikationseinschätzung bei internem
Personal
❖ Bestimmung des Beschaffungszeitpunkts und der Einsatzdauer von Bera-
tern
❖ Auswahl der Berater
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 517
Beschaffungslisten
Die Hilfsmittel für die Bestückung des Projekts mit Personal sind im Wesentli-
chen Anforderungsprofile in Form von Stellenbeschreibungen oder Qualifikati-
onsprofilen. Ein Beispiel hierfür ist im vorangegangenen Kapitel zur Projektor-
ganisation für den Projektleiter aufgeführt. Als Orientierung können auch die
Listen der stellenspezifischen Anforderungen dienen, die im Abschnitt »Aufga-
ben, Rollen, Stellen...« dieses Kapitels sowie in Kapitel 6 »Organisation« und in
Kapitel 10 »Betrieb« angegeben sind. Für den Personalbedarf und die Terminpla-
nung der Personalverfügbarkeit ist der im obigen Abschnitt »Personalressour-
cen« dieses Kapitels besprochene Einsatzplan ein maßgebliches Hilfsmittel.
Als Hilfsmittel für die Bestückung der Projekträume des DWH-Projekts mit
Sachmitteln dient die Checkliste Sachmittel, die im vorigen Kapitel eingeführt
wurde. Diese Liste der einzusetzenden Sachmittel ist Basis für die Beschaf-
fungsbugets.
Besondere Sachmittel sind die Architekturkomponenen. Für diese ist es viel
schwieriger, die richtigen Produkte zu den bereits in den Kapiteln zur Hard-
ware- und Software-Architektur getroffenen Gestaltungsentscheidungen aus-
zuwählen. Hierfür sind in Kapitel 9 »Produktevaluation« ein »Evaluationsver-
fahren« und einige Produktbeschreibungen dargestellt.
8.3.2 Projektverfolgung
Problemstellung und Motivation
Projekte die geplant wurden, werden je nach der Gesamtdauer des Projekts in
regelmäßigen Zeitabständen überprüft. Das Ergebnis der Überprüfung soll eine
Anwort auf folgende Fragen geben:
✔ Verläuft das Projekt wie geplant?
✔ Gibt es Abweichungen im Verlauf?
✔ Liegen Gründe für die Abweichungen vor?
✔ Ist mit weiteren Abweichungen zu rechnen?
Die Erkenntnisse werden zusammengefasst und für weitere Planungen ausge-
wertet. Für die Darstellung dieses Projektgeschehens wird ein Projektberichts-
wesen aufgebaut.
Über jede Phase und über jedes Ergebnis eines Projekts muss eine Überprüfung
der Planwerte, ein Projektcontrolling von Leistung, Qualität, Kosten, Terminen
und Know-how-Aufbau erfolgen. Das Ergebnis des Controllings wird nachvoll-
ziehbar dokumentiert. Hierfür muss ein Projektberichtswesen eingerichtet
werden.
518 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
Je nach Größe des Projekts wird das Berichtswesen für einzelne Teilprojekte
implementiert. In diesem Fall müssen die Einzelergebnisse zu einem Projekt-
gesamtergebnis konsolidiert werden. Die Aufspaltung eines Projekts in Teilpro-
jekte kann sich auch nach Start oder sogar nach Abschluss der Pilotprojekte
herausstellen.
Projektantrag
Die Projektverfolgung beginnt mit der Überprüfung des Projektantrags. Ein
Projekt kostet Geld. Deshalb unterliegt das Projekt einem internen Genehmi-
gungsverfahren durch die Linie der Budgetverantwortlichen. Die Informatio-
nen des Projektantrags müssen auf Plausibilität und Rentabiltät überprüft wer-
den. Die Begründungen für eine Budgetentscheidung müssen nachvollziehbar
sein. Entscheidungskriterium ist die Kosten-Nutzen-Relation der Projektergeb-
nisse, also die Aussage, dass der Nutzen der Ergebnisse die Kosten des Projekts
rechtfertigt. Schlechte Projektdefinitionen, fehlerhafte Kalkulationen und
unzureichende Zielsetzungen lassen sich auch bei bester Projektführung nicht
wieder einholen.
Abbruchkriterien
Projekten, deren Erfolg ungewiss ist, gibt man ein oder mehrere Abbruchkrite-
rien mit. Wenn zum Beispiel innerhalb eines vorgegebenen Zeitraums ein Pro-
jekterfolg zu nicht erkennen ist, kann man auf eine Budgetüberschreitung
schließen. Budgetüberschreitung bedeutet eine Schieflage im Kosten-Nutzen-
Verhältnis, was meistens bei der Startentscheidung des Projekts der wesentli-
che Aspekt ist.
Während das Projekt abgewickelt wird, verändert sich sowohl die Umwelt als
auch das Projektumfeld. Im Projektumfeld kann sich z.B. die Unternehmens-
zielsetzung verändern. Besonders langfristige Projekte sind durch Umstruktu-
rierungsmaßnahmen und Diversifikationen sowie Veränderungen der Markto-
rientierung gefährdet. Die Beschaffungsmärkte entwickeln sich weiter. Neue
Technologien schlagen sich in besseren Produkten mit mehr Funktionalität
nieder. Neue Produkte können so gut sein, dass man das Projekt neu ausrichten
muss.
Abbruchkriterien sind:
✔ Kostenentwicklung ist zu hoch
✔ Risiken können nicht abgefangen werden
✔ Projektziele sind nicht in vollem Umfang zu erreichen
✔ Know-how kann nicht gesichert werden
✔ Nutzen der Projektziele wird im Laufe des Projekts durch Entwicklungen in
der Umwelt obsolet
✔ Mit einer Neuausrichtung der Zielsetzung des Unternehmens gehen die
ursprünglichen Projektziele nicht mehr konform
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 519
Projektcontroller
Der Projektcontroller muss zu einem objektiven Urteil kommen können. Dazu
ist die Betrachtung aus einer kritischen Distanz vonnöten. Der Projektcontrol-
ler muss allerdings umgekehrt sehr viel vom Projekt verstehen, um Termin-
konflikte und Budgetüberschreitungsgefahren aufdecken zu können. Dieses
Verständnis des DWH-Vorhabens ist wiederum nur bei einigermaßen intensiver
Mitarbeit möglich. Dieser Konflikt ist nicht zu umgehen.
Muster Projektstatusbericht
Das Ergebnis der Projektprüfung wird vom Projektcontrolling in einem Prüf-
bericht oder in einer Projektbeurteilung verfasst. Als Hilfsmittel ist im Folgen-
den ein Muster Projektstatusbericht angeführt.
522 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
Muster Projektstatusbericht
Projekt: Teilprojekt:Autor:Ort, Datum:
Projektziele
Das Projekt wurde am xxx gestartet mit den Zielen
Durchführung von ....., Unterstützung von ....., Überarbeitung von ....., Planung von .....,
Qualifizierung von .....
Projektverlauf
.... wurde nicht im Rahmen des Projekts ..... durchgeführt.
Der Bericht zur ..... ist abgeschlossen.
Die Planung .....
Die Schulungen wurden ..... durchgeführt.
Projektbudget
Die Position ..... wird nicht verwendet.
Vom Projektbudget wurde .....
Ein Budgetrisiko liegt in ..... Dem Risiko wird durch ..... begegnet.
Das Gesamtbudget wird aus heutiger Sicht um ..... unterschritten. Die Unterschreitung ..... ist
Terminlage
Der Bericht wurde..... mit einer Verzögerung von drei Wochen fertiggestellt.
Die Erstellung der ..... startet mit einer Verspätung von .....
Ein Terminrisiko liegt in ..... Dem Risiko wird durch ..... begegnet.
Der Gesamtterminplan mit Projektende ..... ist aus heutiger Sicht ungefährdet.
Nächste Schritte
Die ..... ist gestartet.
Das ..... ist zu entscheiden und bis ..... zu beschaffen.
Aktivitätsliste
Nr Aktivität Art Termin Träger
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
Erklärung zur Aktivitätsliste: b – begonnen, e – erledigt, a – aufgehoben
Anlagen
Aufwandsreport
Terminplan
Änderungen zur Projektrichtlinie
Tabelle 8.7: Muster Projektstatusbericht
Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems 523
Aufwandserfassungssheet
Die Aufwandserfassung basiert auf den Leistungspositionen der Leistungsleitli-
nie. Das Arbeitsmittel Leistungsleitlinie wurde weiter vorne schon vorgestellt.
Die Aufwände werden in einer Aufwandsübersicht gruppiert. Für das Mittel
Aufwandserfassungssheet ist im Folgenden ein Muster angeführt.
z.B. mit der Fernüberwachung von Geräten verbunden. Sie ersparen allerdings
später oftmals teure Flugreisen.
Für die Kostendarstellung des DWH-Projekts ist ein DWH-Kontenplan einzu-
richten. Hierzu ein Vorschlag.
Die Struktur des Schemas der Budgetprüfung muss deckungsgleich mit dem
Detailbudgetschema sein. Für den Aufbau des Controllingschemas zur Projekt-
prüfung wird deshalb hier die Verdichtung der einzelnen Geräte zu einer Posi-
tion »Hardwarebeschaffung«, aller Services zu einer Position »Service«, der
Lizenzen zu einer Position »Softwarebeschaffung« und der Aufwände der einzel-
nen Leistungen zu einer Position »Aufwandsphasensummen« vorgeschlagen.
Know-how-Sicherung
Jedes Projekt entwickelt Expertenwissen, das für andere Projekte nützlich ist.
Aus jedem Projekt sollen Lehren gezogen und nachvollziehbar und zugänglich
verfasst werden. Dazu bietet sich die strukturierte Erfassung des Know-hows in
einer Datenbank oder einem Expertensystem für Software- oder IT-Projekte an.
Zu diesem Expertenwissen zählt unbedingt die Auswertung der Projektkalkula-
tionen.
Beispiel
Die Projektierung beginnt mit der Projektdefinition. Diese ist in diesem Kapitel
für InDaWa formuliert. Im folgenden Beispiel wird nur die Leistungsleitlinie
des Instandhaltungsprojekts dargestellt. Auf die Darstellung der anderen
Berichtsformen, Projektantrag, Terminplan, Budgetplan, Projektstrukturplan,
Einsatzplan und Sachmitteleinsatzplan wird aus Platzgründen verzichtet. Die
spezielle Leistungsleitlinie des Projekts InDaWa kann aus der allgemeinen, als
Muster im Unterkapitel »Projektierung« angegebenen Leistungsleitlinie abge-
leitet werden.
Beispiel: Leistungsleitlinie
Vor dem Projekt InDaWa ist ein komplexes Instandhaltungsprojekt durchge-
führt worden. Aus diesem sind alle Ist-Erhebungen verwendbar und besonders
die Datenquellen und die Instandhaltungsprozesse spezifiziert. Die Formatvor-
lagen sind verwendbar und können leicht auf das Projekt angepasst werden.
Neu ist alles, was DWH-Tools, DWH-Methoden und die Hardware zum DWH
betrifft. Die Schadensexperten sind mit allgemeinen Methoden der Software-
entwicklung aus dem Vorprojekt vertraut und benötigen hierfür keine weitere
Ausbildung, müssen allerdings alle DWH-Spezialitäten neu hinzulernen.
Dies schlägt sich wie folgt in der Leistungsleitlinie nieder (siehe Abbildung
8.19).
Gestaltungsentscheidung
Die Gestaltungsentscheidungen sind durch das Vorprojekt vorbelastet oder,
positiv formuliert, entlastet in dem Sinne, dass viele Ergebnisse verwendet wer-
den können. Das InDaWa kann sozusagen als Fortsetzungsprojekt gesehen wer-
den (siehe Tabelle 8.9).
526 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
Entscheidung/
Gestaltungsaspekt Erkenntnis Begründung
VORGEHENSMODELL
Projektierung
Terminplanung Ecktermin ist die jährliche Erkenntnisse bzw. noch erforderliche Mes-
Revision im Juli sungen sollen mit in die nächste Revision
einfließen
Sachmittel Sachmitteleinsatzplan ist nicht Es gibt keine Konkurrenz in der Nutzung der
erforderlich Räume und Sachmittel
PRODUKTE
...
8.5 Übungen
Übung 8.1: Projektphasen DWH-Vorhaben
Nennen Sie die üblichen Projektphasen in der Reihenfolge ihrer Abwicklung
für die Erstellung eines DWH.
Übung 8.2: Leistungsleitlinie des DWH-Vorhabens
Beantworten Sie die folgenden Fragen: Was ist eine Projektleistungsleitlinie?
Wie ist ein Terminplan aufgebaut? Was ist eine Projektrollenmatrix?
Übung 8.3: DWH-Aktivitäten
Was sind typische Aktivitäten für den Aufbau eines DWH?
Übung 8.4: Terminverknüpfungen
Welche Terminverknüpfungen zwischen je zwei Aktivitäten erkennen Sie, wenn
Sie folgende Zeitpunkte einer Aktivität berücksichtigen: Aktivitätsstart, Aktivi-
528 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
8.6 Zusammenfassung
In diesem Kapitel wurde eine Strukturierung von DWH-Projekten besprochen,
aufbauend auf den vom Unternehmen gesetzten Zielstellungen und Gestal-
tungsentscheidungen:
✔ Welche betriebswirtschaftlichen Funktionen werden für die Erreichung der
unternehmerischen Ziele benötigt?
✔ Welche Software ist erforderlich?
✔ Welche Hardware wird dafür eingesetzt?
✔ Welche Organisation muss welche Fähigkeiten wie einsetzen?
Die Strukturierung des DWH-Projekts wurde mittels Einteilung in Phasen und
Teilphasen erreicht. Jede Phase bzw. Teilphase ist mit einer Fülle von Aufgaben,
den sogenannten Leistungen, zu durchlaufen. Die Leistungen führen zu Phase-
nergebnissen. Wenn alle Phasenergebnisse erzeugt und anerkannt sind, kann
die Phase als abgeschlossen angesehen werden und die neue Phase kann starten.
Die Leistungen müssen terminiert werden, um den Zeitverlauf des Projekts zu
prognostizieren. Die Projektergebnisse müssen zu den vom Betrieb des Unter-
nehmens bestimmten Zeitpunkten bereitgestellt werden. Sind die Projekter-
gebnisse zu spät erzeugt, kann das Projekt seinen Sinn verlieren, da die Ergeb-
nisse bzw. Erkenntnisse keine Verwendung mehr finden können.
Für die Einhaltung der Termine ist die rechtzeitige Beistellung von Sachmit-
teln und von qualifiziertem Personal in ausreichender Kapazität wesentlich.
Für die Steuerung der Personaleinsätze und der Sachmitteleinsätze wurden die
Hilfsmittel Personaleinsatzplan und Sachmitteleinsatzplan vorgestellt.
Ein Projekt kostet Geld. Jedes eingesetzte Sachmittel, jeder Informationszu-
kauf, jeder Personaleinsatz kosten das Unternehmen Geld. Um einen Eindruck
von den Projektkosten zu gewinnen, wurde ein Projektbudget ermittelt. Die
Höhe des Budgets kann ein Grund für den Abbruch des Projekts sein. Wenn das
Budget höher ist als der Mehrwert, der mit den Projektergebnissen erzielt wer-
den kann, ist das Projekt als unwirtschaftliches Vorhaben einzustellen.
Die geplanten Termine, Leistungen und Kosten werden kontinuierlich über-
prüft und ihre Abweichungen von der Planung an dem zu erzielenden Nutzen
gemessen. Die Überprüfung wird in Projektstatusberichten fixiert. Die Auswer-
530 Kapitel 8 • Projektierung und Betrieb eines Data Warehouse Systems
KAPITEL 9
9 Data Warehouse Produkte
Überblick
Zu diesem Zeitpunkt der Projektabwicklung sind die Gestaltungsfragen alle
geklärt, die Methodik der Entwurfsarbeiten und der Aktivitäten zu den diversen
Problemlösungen sind festgestellt und die Arbeiten sind projektiert. Nun müs-
sen die Absichten mit Produkten konkretisiert werden. Es gibt nun drei wesent-
liche Fragen zu beantworten:
✔ Was ist der relevante Markt für die Auswahl von DWH-Produkten, wie lässt
sich der Markt effizient eingrenzen?
✔ Welche Produkte bietet der ausgewählte Markt und welche Technologien
sind in den Produkten verwirklicht?
✔ Wenn der Markt abgegrenzt ist, wie findet man aus den gebotenen Alternati-
ven das für die eigenen Belange optimale Produkt?
Die Klärung dieser Fragen erfordert Informationsbeschaffung. Über Informati-
onsmittel wurde bereits allgemein in Kapitel 1 »Orientierung« berichtet. Dort
dienten Informationsmittel zur Meinungsbildung und zur Einordnung des
Themas DWH. Jetzt ist wieder Information einzuholen, um die interessanten
Produkte im Markt aufzuspüren und zu beurteilen.
Das wichtigste Mittel sind Produktanalysen und Marktstudien. Um Studien zu
verstehen und für die eigene Situation interpretieren zu können, ist schon viel
Know-how erforderlich. Ist das Know-how noch nicht vorhanden, muss Bera-
tung eingeholt werden. Die Produktanalyse verlagert sich dann zu einer Ana-
lyse des Beratungsmarktes.
Das Kapitel startet deshalb mit einem kurzen Einblick in den DWH-Markt. Der
Aufbau des Kapitels ist wie im folgendem Diagramm dargestellt.
Um einen Eindruck vom Markt der DWH-Produkte zu erhalten, wird eine Liste
der bekanntesten Produkte zusammen mit ihren wichtigsten Eigenschaften
und den Herstellernamen vorgestellt.
Um über das vielfältige Produktangebot Übersicht zu gewinnen und aus den
vielen Eigenschaften diejenigen herauszufiltern, die für die Aufgabenstellung
wichtig sind, wird ein Evaluationsverfahren vorgestellt.
Neben dem allgemeinen Evaluationsverfahren gibt es Verfahren, die das Ziel
haben, den Nutzen von Alternativen zu bestimmen. Ein besonders weit verbrei-
tetes Verfahren ist die Nutzwertanalyse von Zangemeister. Da die meisten Ver-
fahren vereinfachte Ableitungen davon sind, wird ihr ein besonderes Kapitel
gewidmet.
Einige Hersteller haben keine speziellen DWH-Produkte im Angebot und stel-
len statt dessen DWH-Konzepte vor, in die ihre Produkte als Komponenten
integriert sind. So hat z.B. Hewlett Packard, der Rechner- und Peripherieher-
steller, ein Partnerprogramm ausgewählter DWH-Softwarehersteller um sich
gereiht und verkauft die Integrationslösung als integriertes Konzept. Auf diese
Integrationslösungen wird nicht vertieft eingegangen. Es ist aber lohnenswert,
auf einige dieser Herstellerkonzepte näher einzugehen.
Die vollständige wissenschaftliche Herleitung der Nutzwertanalyse ist zu finden
in:
Zangemeister, Nutzwertanalyse
Lernziel
Die Lernziele fokussieren zunächst die Orientierung in einem komplexen EDV-
Markt, die Eingrenzung des für eine DWH-Lösung relevanten Marktes und die
Sondierung der Hersteller und Produkte. Das Ziel dieses Kapitels ist es, auch
ein Evaluationsverfahren kennenzulernen, das es erlaubt, die große Menge der
auf dem Markt angebotenen Produkte schnell auf eine kleine Anzahl interes-
santer Produkte einzuschränken. Dieses Evaluationsverfahren umfasst die
Nutzwertanalyse mit Vorbereitung, den Aufbau der dazu erforderlichen Tabel-
len und Kriterien sowie die Bestimmung des Anwendungsbereiches und die
organisatorische Umsetzung. Die Lernziele sind außerdem auf die Erkenntnis
der Vielfalt der Herstelleransätze ausgerichtet. Sie zielen auf die Fähigkeit ab,
die Architekturkonzepte für eine Produktevaluation einordnen zu können.
Lernziele
Feststellen, wie der EDV-Markt präsentiert wird
Eingrenzen des für die DWH-Lösung relevanten Marktausschnitts
Kennen der Bedeutung der Evaluation
Anwendung des Evaluationsverfahrens
Kapitel 9 • Data Warehouse Produkte 533
Sekundärinformanten
Neben den primären Lieferanten, den Informationserzeugern, gibt es die
Sekundärlieferanten, welche die Primärinformationen einholen und auf ihren
Wahrheitsgehalt überprüfen. Solche Sekundärinformanten sind z.B.:
✔ Unternehmen, die durch die Anwendung in Projekten Erkenntnisse gesam-
melt und veröffentlicht haben
✔ Berater und Schulungsunternehmen
✔ Universitäten und Forschungsanstalten
✔ Redaktionen von Medien wie Zeitschriften, Internetseiten, Fernsehsendun-
gen
Tertiärinformanten
Es gibt auch noch Tertiärinformanten, das sind diejenigen, die über die Sekun-
därinformation berichten. Dazu gehören zum Beispiel Berater, die über die
Beraterszene informieren, Analytiker die Studienvergleiche vornehmen, quali-
fizierende wie nichtqualifizierende systematische Suchdienste und Informati-
onsbroker.
Marktaufteilung
Der Begriff des Marktes einer Produktgruppe umfasst auch die Marktanteile,
welche die Hersteller mit ihren Produkten einnehmen. Das DWH-Produktum-
feld im weiteren Sinne ist so umfangreich, dass eine Marktanteildarstellung
Kapitel 9 • Data Warehouse Produkte 535
Marketingevents
Da Marketingevents wie Messen, Ausstellungen und Produktpräsentationen
von Herstellern z.B. auf sogenannten Road-Shows (Präsentationsrundreisen) in
Zeitschriften angekündigt werden, ist auf alle Fälle intensives Zeitschriftenstu-
dium zu empfehlen. In Kapitel 1 »Orientierung« ist eine Liste ausgewählter
relevanter Zeitschriften vorgestellt. Man kann auch die bekannten Hersteller
direkt ansprechen, da mittlerweile jeder große Rechnerhersteller und alle
Datenbankhersteller DWH-Produkte in ihr Angebot aufgenommen haben.
Muster-Produkteliste zu DWH-Software
Zum Start können Produktelisten, wie der folgende »Marktüberblick der DWH-
Produkte«, als Hilfsmittel dienen. Die Liste wurde aus verschiedenen Ausgaben von
IX, c't, Client-Server-Computing, Jahrgang 1999
Computerwoche, Jahrgang 1999
Wirtschaftsinformatik, Jahrgänge 1998 und 1999
zusammengestellt. Obwohl sich die Produktszenerie sehr schnell verändert,
schneller als Erscheinungsfolgen von Büchern möglich sind, wurde die Tabelle
»Muster-Produkteliste zu DWH-Software« entwickelt. Sie dient zum einen als
Schnappschuss des Marktes 1999, um einen ersten Eindruck vom engeren
DWH-Software-Produktfeld zu gewinnen, und zum anderen für Übungszwecke.
Kapitel 9 • Data Warehouse Produkte 537
Heraus-
Hersteller Produkt Typ Datenhaltungs- Betriebs- Betriebs-
gabe
bzw. systeme system system
Lieferant Client Server
WindowsNT
SQL-Server
Akquisition
Windows95
Windows98
Erzeugung
Verteilung
CA-Ingres
Teradata
Informix
Adabas
BS2000
Sybase
AS/400
Oracle
OS/2
OS/2
Unix
Unix
MVS
DB2
Mac
NT
Andyne, jetzt Comp.Ass. PaBLO k.A. x x x x x x x x x x
Arbor Software Essbase 93 x x x x x x x x x x x x x x x x x x
Bissantz Delta Miner 97 x x x x x x x x x x
Brio Technology Brio Query 96 x x x x x x x x x x x
Business Objects Business Objects 90 x x x x x x x x x x x x x x x x x x x x
Computer Associates CA-LDM k.A. x x x x x x x x
GQL k.A. x x x x x x x x x x x x x
PaBLO k.A. x x x x x x x x x x
Cognos Impromptu 90 x x x x x x x x x x x x x
PowerPlay 90 x x x x x x x x x x x x x
Comshare Commander Decision 96 x x x x x x x
Hewlett Packard Intelligent Warehouse 91 x x x x x x x x x x x
Hyperion Hyperion OLAP 96 x x x x x
IBM Visual Warehouse 95 x x x x x x x x x x x x x x x
Intelligent Miner 96 x x x x x x x x x x x
Data Joiner 94 x x x x x x x x x x x
Informix Informix-MetaCube 95 x x x x x x
Intersolv Data Direct Explorer 92 x x x x x x x x x x
Data Direct Smart Data 96 x x x x x x x x x x x x
Information Advantage Decision Suite x x x x x x x x x x x
Information Builders Focus Six f. Windows 90 x x x x x x x x x x x x x x x x x x x x
EDA/SQL 90 x x x x x x x x x x x x x x x x x x x x x
Logic Works Universal Directory 97 x x x x x x x x x x x x x x x x x
Model Mart 96 x x x x x x x x x x x x x x x x x x x
Microsoft Plato 99 x x x x x x x
OLAP-Server 99 x x x x x
MicroStrategy DSS-Agent 89 x x x x x x x x x x x x x x x
DSS-Server 89 x x x x x x x x x x x x x x x x x x x x x
NCR Database Query Manager 95 x x x x x x
Knowledge Discov. Workb. 97 x x x x x x x x x x x x
Management Discovery Tool 97 x x x x x x x x
Retail Access Model 95 x x x x x x x x x
TeraCube x x x x x x x
TeraMiner x x x x x x x x
FastLoad,... x x x x x x x x
Oracle Financial Analyser 91 x x x x x x x x x x x x x
Sales Analyser 91 x x x x x x x x x x x x x x x
Express Web Agent 96 x x x x x x x x x x
Express Analyser 95 x x x x x x x x x x x x x
Express Objects 95 x x x x x x x x x x x x x
Discoverer 89 x x x x x x x x x x x x x x x x x x x
Darwin 89 x x x x x x x x x x x x x x x x x x
Pilot Software Pilot Decision x x x x x x x x x x x
Platinum Data Shopper 94 x x x x x x x x x x x x
Info Hub 93 x x x x x x x x x x
Info Pumb 93 x x x x x x x x x x x x x
Info Refiner 91 x x x x x x x
Forest Trees 90 x x x x x x x x x x x
Info Reports 95 x x x x x x x x x x x x x x x
Info Beacon 93 x x x x x x x x x x x x x
Prism Solution Prism Warehouse Executive 92 x x x x x x x x x x x x x x x
SAS SAS System 76 x x x x x x x
SAP R/3-EIS 92 x x x x x x x x x x x x x x x x x x
inSight 99 x x x x x x x x x x x x x x x
Seagate Holos 86 x x x x x x x x x x x x x
Silicon Graphics MineSet 96 x x x x x x x x x x x x
Sterling Vision Builder 80 x x x x x x x
Vision Inform/-Journey 90 x x x x x x x x x x x x x x
Clear 91 x x x x x x x x
Systemfabr. Warehouser's Workbench 97 x x x x x x x x x x x x x x x x x x
BrioQuery Enterprise 93 x x x x x x x x x x x x x x x x x x x x
Brio.Wev. Warehouse 96 x x x x x x x x x x x x x x x x
Sybase Sybase Enterprise Connect 87 x x x x x x x x x x x x x x x
Info Maker 91 x x x x x x x x x x x x x
ben. Aber Zeit ist kostbar und viele langfristige Tests kann sich ein schnell agie-
rendes Unternehmen aus Kosten- und Termingründen nicht leisten. Teststel-
lungen müssen deshalb auf ein Minimum reduziert werden. Daher ist die
Vorauswahl mit entsprechender Sorgfalt zu treffen.
Die Auswahl ist immer mit Bewertungskriterien durchzuführen, deshalb
spricht man von einer Evaluation.
Definition: Evaluation
Eine Evaluation ist eine Vorgehensweise mit einem Bewertungsmaßstab aus
einem oder mehreren Bewertungskriterien mit einer Wertgröße. Das Vorge-
hen ermittelt aus einer definierten Anzahl von Möglichkeiten diejenigen mit
dem größten Wert für einen definierten Zweck.
Definition: Kriterienfilter
Ein Kriterienfilter ist eine Sammlung von Kriterien, um aus einer Menge
von Gegenständen eine Auswahl zu treffen. Eine Kriterienfilterkaskade ist
eine hintereinander angewendete Folge von Kriterienfiltern zur stufenwei-
sen Einschränkung einer Menge von Gegenständen auf eine Teilmenge.
Eine nützliche Variante für eine Filterkaskade ist die dreistufige Einschränkung
des Auswahlfeldes:
✔ Erste Stufe strategische Eigenschaften
✔ Zweite Stufe taktische Eigenschaften
✔ Dritte Stufe technische Eigenschaften
Kapitel 9 • Data Warehouse Produkte 541
Welche Kriterien als taktisch und welche Kriterien als strategisch einzustufen
sind, ist von Unternehmen zu Unternehmen verschieden. Was bei dem einen
Unternehmen als taktisch eingestuft wird, ist für ein anderes Unternehmen von
strategischer Bedeutung.
Es gibt keine für alle Komponenten des DWH gleich gut geeignete Auswahl an
Kriterien. Auf der strategischen Ebene sind Kriterien für alle Komponenten
gleichermaßen gültig. Die Übereinstimmung der Kriterien für verschiedene
Komponenten nimmt von den strategischen Kriterien über die taktischen Kri-
terien zu den technischen Kriterien hin ab.
Strategische Kriterien
Die strategischen Kriterien sind auf Langfristigkeit ausgerichtet. Die Erfüllung
eines strategischen Kriteriums bedeutet eine gewisse Beständigkeit. Strategi-
sche Kriterien sind weitreichend, sie setzen systemübergreifende Bedingungen
fest. Mit der Formulierung von strategischen Kriterien sollen grundsätzliche
Eigenschaften festgelegt werden.
gisches Kriterium für die Werkzeugwahl ist dann die freie und effiziente Wei-
terentwickelbarkeit der Entwicklungsumgebung. Als technisches Kriterium
ergibt sich daraus:
✔ erweiterbare Toolbox
Der Umgang mit strategischen Kriterien soll anhande des Kriteriums »Integra-
tion« am Beispiel der Technologie von DWH-Entwicklungswerkzeugen für Cli-
ent/Server-Lösungen und seiner Fortsetzung in evaluierbare technische Krite-
rien dargestellt werden.
Taktische Kriterien
Auf der zweiten Ebene der Filterkaskade werden die taktischen Anforderungen
festgelegt und die durch den Filter der strategischen Kriterien verbleibende
Produktemenge beurteilt.
Als taktische Kriterien können die herstellerbezogenen Eigenschaften festge-
stellt werden. Dazu gehört die Lizenz- und Preispolitik des Herstellers und sei-
ner Partner. Kein Produkt steht für sich alleine im Markt, deshalb ist das
Zusammenspiel der Partnerhersteller und Zulieferer und die Güte ihrer Pro-
dukte ein wichtiges Kriterium.
Die Herstellereigenschaften sind als strategisch einzusetzen, wenn sie für stra-
tegische Ziele des Unternehmens genutzt werden. Das ist z.B. bei Kooperation
544 Kapitel 9 • Data Warehouse Produkte
mit neuen, auf DWH aufbauenden Produkten und bei der Kooperation in der
Bearbeitung eines Marktes der Fall.
Aus den taktischen Kriterien sind ebenfalls technische Kriterien ableitbar, sie
sind aber auch direkt für die Evaluation einsetzbar.
Technische Kriterien
Auf der dritten Ebene der Filterkaskade werden die technischen Anforderungen
festgelegt und die durch den Filter der taktischen Kriterien verbleibende Pro-
duktemenge beurteilt.
Die technischen Kriterien sind für den Umgang mit dem Softwaremodul maß-
gebend. Sie ermöglichen Handlungen oder verhindern diese. Technische Krite-
rien legen die Funktionalität der Software fest. Die Ausstattung mit Funktiona-
lität ist für die Entwicklungsarbeiten, Administrationsarbeiten, für den
Umgang der Benutzer mit dem System und auch für den Fachinhalt verant-
wortlich.
Es gibt eine Reihe von mit DB2 zusammenarbeitenden Tools, die nur bei
Bedarf beschafft werden sollen.
✔ Expertensystemshells: Als Expertensysteme (XPS) werden Anwendungen
bezeichnet, die mit Hilfe einer Wissensbasis und darauf zugreifender
Interferenzmechanismen das Problemlösungsverhalten von Experten
eines bestimmten Fachgebiets simulieren. Da Expertensysteme zur
Abwicklung der Mensch/Maschine-Interaktion eine Dialogkomponente
(Benutzerschnittstelle) benötigen, verfügen einige XPS-Entwicklungs-
umgebungen auch über entsprechende Oberflächen-Entwurfswerk-
zeuge. Das für die DWH-Applikation erforderliche Regelwissen ist in
Modellkomponenten enthalten. XPS werden höchstens ergänzend und
frühestens nach einer Erfahrungszeit benötigt und deshalb nicht mit in
die Evaluation aufgenommen.
✔ Enduser-Tools: Zur Gruppe der Enduser-Tools zählen die im Rahmen der
individuellen Datenverarbeitung von den Sachbearbeitern eingesetzten
PC-Anwendungen. Der primäre Verwendungszweck dieser Systeme orien-
tiert sich an typischen Standard-Aufgabenstellungen (wie beispielsweise
Tabellenkalkulation); zusätzlich werden jedoch häufig auch Masken-Ent-
wurfswerkzeuge und Schnittstellen zu anderen Softwareprodukten mitge-
liefert. Die Entwicklungswerkzeuge sind Makrosprachen, Makrorecorder
und fertige Programmkomponenten. Die Enduser-Tools werden parallel
z.B. zur Erstellung einer Dokumentation und für individuelle Kleinlösun-
gen eingesetzt, aber nicht prinzipiell als Entwicklungswerkzeuge.
Das Beispiel konzentriert sich auf ein DB-unabhängiges, objektorientiertes
4GL-Toolset, auf der Basis von C++ mit integrierbaren SQL-, ODBC- und
APPC-Komponenten.
In dieser Argumentation wurden auch die ausschließenden Argumente inte-
griert, um nach einer Zeit des Einsatzes nicht allein auf die Ergebnisse der
Argumentation angewiesen zu sein.
Die in die engere Auswahl aufgenommenen Tools werden im Beispiel in der fol-
genden Tabelle unter Verwendung der in den Schritten 2 und 3 definierten
anwendungstechnischen, infrastrukturellen und organisatorischen Rahmenbe-
dingungen miteinander verglichen. Daraus resultiert eine Feststellung der ent-
scheidungsrelevanten und evaluierbaren Produkteigenschaften.
Produkt
Eigenschaft AAA BBB CCC
Strategische Eigenschaften
Entwicklungsumgebung BS: NT ja ja ja
Netzprotokoll TCP/IP ja ja ja
Taktische Eigenschaften
Preis Run-Time-Lizenz entfällt wg. Erstellung von muss individuell ermittelt muss individuell ermittelt
Smalltalk-Code werden werden
Technische Eigenschaften
C++ -Schnittstelle ja ja ja
User-defined Structures eingeschränkt (Daten- - -
objekt vererben)
Besonderheiten integriertes Analyse- und integriertes Analysetool geeignet für stark hetero-
Designtool auf Basis der gene Zielumgebungen
OMT-Methode
Tabelle 9.3: Beispiel der Synopse der Filterstufenergebnisse an den Produkten der letzten Auswahlstufe
548 Kapitel 9 • Data Warehouse Produkte
Filterkaskade
Es empfiehlt sich prinzipiell, eine dreistufige Filterkaskade aus den folgenden
Kriteriengruppen aufzubauen:
✔ Strategische Kriterien
✔ Taktische Kriterien
✔ Technische Kriterien
Ein höhere Anzahl von Stufen macht das Verfahren aufwendiger und eine nied-
rigere Anzahl von Stufen führt zu einer zu hohen Anzahl auszuwertender Pro-
duktalternativen.
Tabelle der strategischen Kriterien zu DWH-Softwarekomponenten
Die strategischen Kriterien sind Musskriterien. Produkte, welche die strategi-
schen Kriterien nicht erfüllen, werden von der weiteren Betrachtung ausge-
schlossen. Beispiel für strategische Kriterien sind:
✔ Architektur und Technologietypen
✔ Plattformen und Integration in bestehende Lösungen
✔ Marktpartnerschaften
Für die Auswahl soll die folgende Tabelle der strategischen Kriterien eine Ori-
entierungshilfe sein (siehe Tabelle 9.4).
Integrationsschaubild
Die Beurteilung der Integrierbarkeit ist höchst komplex aufgrund der vielen
bereits im Unternehmen vorhandenen und der weiteren durch das DWH hinzu-
kommenden Komponenten. Ein nützliches Hilfsmittel zur Veranschaulichung
der Integrationssituation ist das Integrationsschaubild. Es ist eine Übersicht
der Produkte der Softwareklassen »Client-Betriebssystem, Netzwerk/Proto-
kolle, Server-Betriebssystem und Datenhaltung«. Die Rubrik »Entwicklungs-
werkzeuge« gibt einen Überblick über die wichtigsten Repräsentanten verschie-
dener Werkzeugklassen, deren weiße Hervorhebung die grundsätzliche
Vereinbarkeit mit den Anforderungen und Rahmenbedingungen der aktuellen
Projektsituation kennzeichnet.
550 Kapitel 9 • Data Warehouse Produkte
Integrierbarkeit:
Neue Anwendungen müssen mit bestehenden - Migrierbarkeit, Portabilität, Plattformreichweite
Anwendungen Daten austauschen, funktional, - Interoperabilität, Offenheit, Kompatibilität
prozessual und ergonomisch eingebettet sein. Der - Internationalität
fachliche Gehalt muss in Stil, Grundverständnis, - Fachintegration: Fachfunktionen, Prozesse,
Begriffswelt übereinstimmen. Die nationalen Eigen- Informationen, Reportaufbau
heiten müssen stimmen. - Dialoghomogenität, Maskenbild
Allianzfähigkeit:
Die Individualentwicklung kann auf der Basis eines - Vertriebspartnerschaft, Kanäle des Herstellers
Marktprodukts zu einem Produkt weiterentwickelt - Entwicklungspartnerschaft
werden. Zur Fortsetzungsentwicklung und - Allianzform, Kooperationsform
Platzierung auf dem Markt ist die Kooperation mit - Marktbedarf
dem Hersteller des Basisprodukts wichtig.
Unternehmenskultur:
Die Organisation der Systeme muss mit der - Motivierbarkeitspotential
Organisation des Unternehmens verträglich sein. - Imageförderung
Die Erreichung der strategischen Ziele des - Mitbewerberlevel
Unternehmens muss verbessert werden können.
Innovativität:
Die Architektur und Technologie der Systeme kann - Zukunftspotential, Chanceneinschätzung
traditionell etabliert sein, sie kann state-of-the-art - Risikopotential
sein oder völliges Neuland eröffnen.
Skalierbarkeit:
Der stetige Ausbau mit neuen Modulen muss durch - Modularität
Anschaffung, Partitionierung und Selbstentwicklung - Ressourcenverteilbarkeit
möglich sein. - Größenvarianten, Plattformvarianten
Wird die Suche auf die Menge der aus der Sicht der Unternehmenssituation
anforderungskonformen Werkzeuge eingeschränkt, verbleiben zum Beispiel die
in der nachfolgenden Übersicht weiß unterlegten Produkte (siehe Abbildung
9.4).
Tabelle der taktischen Kriterien zu DWH-Softwarekomponenten
Die taktischen Kriterien sind Sollkriterien. Produkte, welche die taktischen
Kriterien nicht erfüllen, erfordern einen hohen Aufwand im Zusammenspiel
mit anderen Produkten. Mittels taktischer Kriterien können Gruppen von tech-
nischen Kriterien festgelegt werden. Beispiel für taktische Kriterien sind:
✔ Hersteller und Dienstleistungsangebot
✔ Aktualität der Releases
✔ Technologie und Methodenbasis
✔ Präsenz im Land der Entwicklungsarbeiten
✔ Referenzkunden und Marktposition
Für die Auswahl soll die folgende Tabelle der taktischen Kriterien eine Orien-
tierungshilfe sein.
Kapitel 9 • Data Warehouse Produkte 551
Transparenz:
Die Innenarchitektur der Produkte muss für - Formatbeschreibungen, Systemkataloge
Anbindungsfragen an Fremdprodukte und Eigen- Architekturgrafiken, Protokolle, Datenmodelle
entwicklung offengelegt sein. Die Kooperationen - Thema der Herstellerschulungen
und Abhängigkeiten müssen bekannt sein. - Third-Party-Listen, Kooperations-Commitments
Stabilität:
Das Produkt muss den Reifungsprozess abge- - Versionsnummer, Update-Rhythmus
schlossen haben, die Technologie muss bewährt sein. - Einhaltung von Ankündigungen
Performance:
Module müssen problemlos umplatziert und getunt - Ergonomie, Anwenderzufriedenheit
werden können. Installation und Releasewechsel - Lernbarkeit, Einarbeitungszeit
sollen ohne große Eingriffe in die bestehenden - Zeitverhalten, Parameter zur Verhaltens-
Architekturen abgewickelt werden können. Das anpassung, Parallelverarbeitung
Arbeiten mit dem Produkt muss reibungslos und - Ressourcenverteilung, ortsnahe Verarbeitung
weitgehend selbst erklärend sein. - Fehlertoleranz
Marktpräsenz:
Die Hersteller der ausgewählten Werkzeuge und - Marktposition, Umsatzentwicklung, Unter-
Technologien müssen eine sichere Marktposition nehmenshistorie
haben, sodass Langlebigkeit und kontinuierliche - Technologiestatus, Innovationstendenzen,
Weiterentwicklung der Produkte und Support öffentliche Diskussion
garantiert sind. Die Corporate Culture und die - White Papers, Strategiebekanntgaben
externe Präsenz in Wissenschaft, Forschung und - Hochschulkooperation, Forschungsprogramme
Öffentlichkeit muss die Innovativkraft und Zukunfts-
orientierung der Produkte anzeigen.
Know-how Allokation:
Das zur Entwicklung und Produktion erforderliche - Trainingsangebote
Know-how muss durch Personalmarkt, externe - Hotline Support
Berater und ausreichende Schulungs- und - Stellenmarkt
Betreuungskapazität des Lieferanten abgedeckt - Beratermarkt
bzw. aufgebaut werden können. - Hochschulvorlesungen
Technische Kriterien
Die technische Kriterien sind Kannkriterien. Die technischen Eigenschaften
des Produkts erhöhen die Einsatzfähigkeit und bieten bessere, komfortablere
Funktionalität, können aber auch ohne die eine oder andere Eigenschaft gut
genutzt werden. Beispiel für technische Kriterien sind:
✔ Ergonomiefunktionen
✔ Fachliche Einzelfunktionalität
✔ Programmiersprache von Tools
✔ Laufzeitprogrammerzeugung: Compiler, Assembler, Interpreter, Precompi-
ler, Generator
Die technischen Kriterien müssen mittels Produktpräsentationen und Teststel-
lungen überprüft werden. Für die Gruppe Einzelfunktionalität aus der Reihe
der technischen Kriterien sind in Kapitel 4 »Softwarekomponenten« Kompo-
nenten und kommentierte Funktionenlisten aufgeführt.
Kapitel 9 • Data Warehouse Produkte 553
((
%&'(
!"
%&'(
(
#
#
#
'(
(
%#&
'( '(
!'&
&
!
"# #
Entscheidungsalternativen
Zuerst müssen die nach ihrem Nutzen zu beurteilenden Entscheidungsalternati-
ven definiert werden. Für eine neu zu realisierende Anwendung könnte z.B. das
Problem der optimalen Architekturkombination aus einer bestehenden und der
noch zu implementierenden Architektur zu lösen sein. Da ein DWH-System aus
mehreren Anwendungen besteht und diese über unterschiedliche Architekturen
realisiert sein können, ist eine Entscheidung zur Systemarchitektur zu finden.
Ein Teil der DWH-Systemarchitektur ist die Hardware-Architektur. DWH-Hard-
ware-Architektur wird von der DWH-Software-Architektur bestimmt. Die
DWH-Software ist eine Kombination von Architekturvarianten der verschiede-
nen Softwarekomponenten. Für die Systemarchitektur des DWH aus Software-
sicht können z.B. grundsätzlich die drei typischen Architekturen OLAP, DSS
und Data-Miner der Nutzenbeurteilung unterzogen werden.
Nutzenkategorien
Als nächster Schritt ist die Aufstellung der für Anwendungsarchitekturen rele-
vanten Nutzenkategorien erforderlich. Da die Kriterien alle Lebensphasen der
Software berücksichtigen sollten, um die Vorteile einer ausgewählten Umge-
bung für die Produktion nicht mit Nachteilen bei der Entwicklung und War-
tung zu erkaufen, bietet sich als erstes Ordnungskriterium die Einteilung in
Lebensphasen an. Es genügt, bezüglich der Lebensphasen die drei Kategorien
✔ Entwicklung
✔ Betrieb
✔ Wartung
Kapitel 9 • Data Warehouse Produkte 557
%#
'
$
##
%
#
&#'
#
'
%
!
"#
"$
Gewichtungsfaktor
Da die Beurteilungskriterien in ihrem Beitrag zum Nutzen unterschiedlich
wichtig sind, werden sie mit einem Gewichtungsfaktor unterschiedlich gewich-
tet.
Auf jeder Ebene der Kriteriengliederung (Zielebaum) muss eine Gewichtung
durchgeführt werden, so dass jeweils die Gewichte in einer Ebene unter einem
Gliederungspunkt in Relation stehen (relative Gewichte). Die Gewichtung wird
dann ebenenweise normiert. Die Gewichtungswerte sind relativ zu ihrem Ober-
begriff normiert. Alle Faktoren zusammengenommen sind so normiert, dass sie
ihren Anteil zum Gesamtnutzen von 100% anzeigen.
Das folgende Beispiel listet die hierarchische Gliederung der »Nutzenfaktoren
für die Architekturauswahl« mit Gewichtung innerhalb der Nutzenfaktoren-
gruppe und mit Gewichtung der Nutzenuntergruppe zu anderen Nutzenunter-
gruppen und der Gewichtung der Nutzengruppen zueinander auf (z.B. Nutzen-
gruppe »Betrieb« hat das relative Gewicht 5). Die Gewichtung resultiert aus
einem Maßstab, der in der letzten Zeile benannt ist.
1. ENTWICKLUNG 2
1.1 Entwicklungsmethodik Leistung 0.2 Modernität
Beherrschbarkeit der Entwicklungsproblematik über Know-how-Verfügbarkeit
Methoden, Personalverfügbarkeit für den Einsatz der
Methoden
2. BETRIEB 5
2.1 Funktionalität 0.3
2.1.1 Prozessabdeckung Abdeckungsgrad 0.05 Funktionszahl
Die Programme sollen vormals manuelle Prozessan- Flexibilität
teile und Aktivitäten durch Programmfunktionen
übernehmen.
3. WARTUNG 3
3.1 Wartbarkeit Releasewechsel 0.5 Modularität
Ersetzen alter Komponenten durch neue, schnelle Komponententausch Parametrisierung
Fehlerbeseitigung, Releasewechsel ohne großen Funktionserweiterung
Parameteranpassungsaufwand Fehlerbehebung
Zielwertskala
Für jeden einzelnen Nutzenfaktor letzter Zerlegungsstufe ist die Erstellung
einer Zielwertskala mit einem Maßstab erforderlich. Zum Beispiel sind in der
Abbildung »Nutzwertematrix für DV-Systeme« die Zielwerte des Kriteriums
»Performance« für das Maß »Antwortzeit« und die Zielwertklassen <2sec, 2-
6sec, 6-10sec, >10sec mit den Werten 8,4,6,2 auf der Zielwerteskala dargestellt.
Die Skaleneinteilung zu einem Nutzenfaktor ist projektabhängig, d.h. die Nutz-
wert-Zuordnungstabelle muss für jedes Projekt erneut aufgestellt werden.
Die Zielwertskalen werden günstigerweise zu einer Nutzwertematrix zusam-
mengefasst, um die relative Gewichtung untereinander auszubalancieren.
560 Kapitel 9 • Data Warehouse Produkte
Nutzenkategorien Nutzwerte
Nutzenfaktoren 0 1 2 3 4 5 6 7 8 9 10
Entwicklung
Methodik unvollständig vollständig vollständig, integriert
Betrieb
Funktionalität
Prozessabdeckung 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Integrierbarkeit
Protabilität
Datenbank neue DBTools erforderlich muß portiert kann migriert alle DBTools vorhanden
werden werden
Programme neues BS erforderlich Entwicklung muß portiert werden alle BS vorhanden
Masken neue Oberfläche erforderl. Masken müssen portiert werden alle Oberflächen vorhanden
Interoperabilität
Daten Eigen Third P integriert
Verfügbarkeit
Performance >10sec 6-10sec 2-6sec <2sec
Ausfallsicherheit 1/Woch 3/Mon 2/Mon 1/Mon 9/Jahr 6/Jahr 5/Jahr 3/Jahr 2/Jahr 1/Jahr
Produktstabilität
Marktpräsenz Nischenspieler Kopierer Hauptmitbewerber Führer
Unternehmenskonkordanz
Strategie konträr anpassbar verträglich nahtlos
Wartung
Wartbarkeit extern manuell teilw. automatisiert automatisiert
Transparenz
Datenstruktur ohne teilw. Param völlig
Bewertung
Die ausgewählten Architekturalternativen werden mittels der Zielwerteskala
der Bewertung unterzogen, indem jede Architektur den geschätzten oder
gemessenen Skalenwert zu jedem Nutzenfaktor zugeordnet bekommt. Die Dis-
kussion kann zum Beispiel ergeben, dass die ausgewählte Anwendung als
Cooperative Processing Lösung mit PC und Host stark mit Grafikverarbeitung
zu kämpfen hat und über lange Netzstrecken auf eine fein zerlegte relationale
Datenbank zugreifen muss, was zu einer Antwortzeit >10sec führt.
Die nicht messbaren Nutzenfaktoren, wie zum Beispiel »Bedienungskomfort«,
werden über einen Abstimmungsprozess der Beteiligten eingeschätzt.
Gesamtgewichtung
Der unterschiedlichen Bedeutung der Nutzenfaktoren wird durch Multiplika-
tion mit dem bereits oben genannten Gewichtungsfaktor Rechnung getragen.
Die Zusammenfassung der Einzelbewertungen zu einer Gesamtgewichtung
schließt das Verfahren ab. Das Ergebnis ist ein Zahlenwert für jede Architektur-
variante, die Nutzwerte der Entscheidungsalternativen.
Hierbei kann sich in den vorhergehenden Schritten durchaus herausgestellt
haben, dass ein Gesamtergebnis über alle Phasen, also eine Optimal-Architek-
tur für Entwicklung und Betrieb nicht möglich ist, das Gesamtergebnis also aus
der Empfehlung zweier Architekturbeschaffungen besteht.
Als Beispiel wurde weiter unten in der Tabelle »Nutzenbewertung für DV-Archi-
tekturen« ein Anwendungssystem realistisch für die Host-Terminal-Architek-
tur, für die PC-Server-Architektur und mit fiktiven Maximalwerten bewertet
dargestellt (siehe Abbildung 9.8).
Für jedes weitere zu beurteilende Projekt kann die NWA durch neue Gewich-
tung, Skalierung und Skalenwerteinordnung wiederverwendet werden.
Nutzenfaktorennetze
Nutzenfaktoren sind in der Regel vernetzt und stehen in einem Ursache-
Wirkungs-Verhältnis. Die Nutzwertanalyse zeigt nicht die eventuell vorhandene
gegenseitige Abhängigkeit von Nutzenfaktoren. Diese Abhängigkeit kann durch
die vorgezogene Entwicklung von Nutzenfaktorennetzen oder Nutzeffekt-
netzen offengelegt und bei der Nutzwertbestimmung berücksichtigt werden.
Beispiele für Nutzennetze sind zu finden in
Anselstetter, Betriebswirtschaftliche Nutzeffekte
562 Kapitel 9 • Data Warehouse Produkte
zenkriterien zu finden, die bewertet werden. Für die Nutzenkriterien ist je Kri-
terium eine Skala zu erarbeiten, wie groß ihr Nutzenbeitrag unter welchen
Ausprägungen ist.
➢ Erarbeitung der Nutzenfaktoren
➢ Erarbeitung der Nutzenkriterien
➢ Findung der Bewertungsskala und der Nutzenbeiträge der Skaleneinheiten
Da die Ergebnisse gemeinsam umzusetzen sind, müssen sie auch von einem
betroffenen Kreis als gemeinsames Ergebnis getragen werden. Damit ist auch
die Problematik der Organisation der Nutzenermittlung und die Entschei-
dungsfrage, wann eine Nutzenfindung eingesetzt werden soll, zu lösen.
➢ Entscheidung der Organisationsform und der Teilnehmer der Nutzenana-
lyse
+,
&
',,
$
! " %
#$ # $
( )
) ")
Die Schicht »Teradata Data Acquisition and Integration« hat die Werkzeuge
✔ FastLoad, MultiLoad, TPump, FastExport für die Unterstützung, Prüfung
und Steuerung von Daten-Download von Großrechnern.
Die Schicht »Teradata Data Management« hat die Werkzeuge
✔ Teradata Interface für die Verbindung verschiedener Fremdprodukte, z.B.
den OBDC- und JDBC-Zugriff auf Datenbanken verschiedener Hersteller
✔ Teradata System Management Tools für die Administration, das Monitoring
und Systemmanagement der Datenbanken
✔ Teradata Meta Data Services zur Definition von Metadaten über verschie-
dene Applikationen und auch Softwarekomponenten
✔ Teradata Privacy für die Einrichtung und Verwaltung der Zugriffsrechte und
die individuelle Konfiguration der Nutzung
Der Hersteller Teradata ist auf die Herstellung eigener Software und Hardware-
systeme spezialisiert, die speziell für DWH eingesetzt werden.
-
* .
%
!
" # $
"
%&"
$
"
'#()* " +
"
0
%
" *&
/
" ,
$
!
"
#$
%&'('
)
!
+
Ein anderer Weg, in der Auswahl der Produkte zu einer grundsätzlichen Ent-
scheidung zu kommen, ist der Blick auf das Architekturkonzept.
➢ Beurteilen der Architekturkonzepte der Hersteller
Verfahren DWH-Konzeptauswahl
❖ Einordnung der Herstellerkategorie mit Hilfe der Herstellerkriterienliste
zu DWH-Softwarekomponenten
❖ Beurteilung der Architekturkonzepte der Hersteller mit Hilfe der Check-
liste Herstellerkategorien
Herstellerkriterienliste zu DWH-Softwarekomponenten
Die Beurteilung der Hersteller umfasst Historie, Beteiligungen und Marktseg-
mente und soll über
✔ die dauerhafte Verfügbarkeit auf dem Markt,
✔ die auf der Standardisierungsverwendung beruhenden Integrationsfähigkei-
ten und
580 Kapitel 9 • Data Warehouse Produkte
Eigenschaft Konsequenz
Kooperationen: Hardwareabhängigkeit
Partnerschaften Offenheit von Schnittstellen und
White Paper Integrationsfähigkeit für Fremd-
Vertriebskanäle produkte
Abhängigkeit von Fremdprodukten
Dienstleistung
Beratung
Wartungsservice
Training
Vermietung
Checkliste Herstellerkategorien
Für die Beurteilung der Herstellerkategorie dient die folgende Checkliste Her-
stellerkategorien. Sie ist eine Orientierungshilfe, die den Blick auf die aus der
Philosophie des Herstellers entstehenden Produkteigenschaften lenken kann.
Branchenkonzern Erfahrung über sehr große interne Projekte RWE-MIT, DEBIS, MBP,
DWH-Lösungen entwickelt, aber selten vermarktet EDS, McDonaldDouglas,
Teilweise eigene Produkte vermarktet VW-GEDAS
Teilweise Kooperation mit HW-und SSW-Herstellern
zum Projektieren kompletter Lösungen
Unternehmensberater DWH-Lösungen für Kunden und für eigenen Bedarf Diebold, Anderson, Arthur
entwickelt D. Little, Roland Berger,
Teilweise eigene Produkte vermarktet DATEV, PLAUT, GMO,
Teilweise Kooperation mit HW-und SSW-Herstellern AGIPLAN, KPMG,
zum Projektieren kompletter Lösungen Coopers&Lyprand
IT-Berater DWH-Lösungen für Kunden und für eigenen Bedarf INTEGRATA, PSI, SEMA-
entwickelt Group, pdv, Softlab, CSC-
Teilweise eigene Produkte vermarktet Ploenzke, DV-ORG,
Teilweise Kooperation mit HW-und SSW-Herstellern Experteam, Systema,
zum Projektieren kompletter Lösungen ALLDATA, IDS,
SWE-Unternehmen Ergänzung oder Erweiterung der eigenen Tools wie MS, Lotus, TM1, MIS,
Spreadsheets
Integrierbare Makro- oder Business-Objekte für DWH
Keine Erfahrung in der Steuerung großer Projekte
SSW-Hersteller Liefern DWH-Bausteine als Dach auf Standard- SAP, KHK, DATEV,
software als Basis ORACLE, PLAUT, BAAN,
Keine Beratungsleistung über eigene Systeme hinaus CA, People Soft
Bausteine in der Schublade
Beispiel
Zunächst soll eine Filterkaskade aufgebaut werden. Vom Nutzen einer DWH-
Lösung ist man überzeugt. Eine Entscheidungsfrage nach dem Architekturtyp
– OLAP, DSS, KMS – und dessen Nutzenanalyse tritt nicht auf. Es soll zunächst
die multidimensionale Analyse und die Analyse mit einfachen statistischen Mit-
teln implementiert werden. Bei neuen Erkenntnissen will man entscheiden, ob
ein Data Mining mit intelligenteren Werkzeugen angemessen ist.
Beispiel: Filterkaskade
Erster Filter: strategische Kriterien
Für die Gesamtheit der grundsätzlich in Betracht kommenden Werkzeuge
sind folgende strategische Kriterien zu erfüllen:
✔ Integration in den Teil der bestehenden Software- und Hardwareland-
schaft, der für die Zukunft beibehalten wird
✔ Offenheit für die Anbindung von Werkzeugen anderer Hersteller
✔ Skalierbarkeit und Ausbaubarkeit, den neuen Erkenntnissen und Anfor-
derungen entsprechend
Zweiter Filter: taktische Kriterien
Als taktische Bedingungen hat man nur die Herstelleranforderungen einge-
stuft. Ergonomie, so glaubt man, ist mit der Entscheidung für Microsoft
sichergestellt. Für neue Applikationen ist gegenüber den bereits im Unter-
nehmen etablierten Office-Produkten von Microsoft keine neue Symbolik
und kein neues Programmverhalten zu erlernen.
Man glaubt, bei Herstellern, die sich nur mit dem Thema DWH auseinander-
setzen, durch die Erfolgsabhängigkeit von einem Produkt eine bessere Kon-
zentration auf die DWH-Funktionen zu finden. Man möchte bewusst keinen
Hardwarehersteller und keinen Datenbankhersteller als Lieferanten für
DWH-Module. Man glaubt auch, dass hier eine optimale Offenheit der Pro-
duktpalette zur Unternehmensphilosophie gehört.
Kapitel 9 • Data Warehouse Produkte 583
Der Hersteller soll über den deutschen Markt hinaus in den wichtigsten Län-
dern vertreten sein, da man einen weitgefächerten Erfahrungsraum als Vor-
aussetzung für stabile Produkte für wichtig hält. Für die Dauerhaftigkeit und
die kontinuierliche Weiterentwicklung der Produkte sieht man die Heraus-
gabe eines »White Paper« an und eine feste Marktposition.
Zusammengefasst ergibt dies:
✔ Reiner DWH-Hersteller
✔ MS-Partnerschaft
✔ Beraterstamm in BRD
✔ White Paper mit Entwicklungszielen
✔ Marktposition unter den ersten zehn der reinen DWH-Hersteller
Dritter Filter: Produktumfeld der Toolauswahl
In einem dritten Auswahlschritt werden die Produkte mit GUI, 4GL, RDB-
Basis eingegrenzt, da diese nach Einschätzung der Projektleitung für die
vorliegende Aufgabenstellung das höchste Problemlösungspotential aufwei-
sen. Von einer 4GL verspricht man sich eine effizientere Erstellung neuer
Applikationen.
Man möchte allerdings nicht von einer herstellereigenen, proprietären Pro-
grammiersprache abhängig sein. Die 4GL muss das DCOM-Modell von
Microsoft erfüllen, mit Toolbar ausgestattet sein und einen Precompiler nach
C besitzen. Es soll außerdem möglich sein, in der sich immer stärker ver-
breitenden Framework-Technologie zu arbeiten und diese um das Einhängen
von Microsoft-Komponenten auszubauen.
Zusammen mit den strategischen Bedingungen lässt sich der Markt auf Pro-
dukte einschränken, die die folgenden technischen Bedingungen erfüllen:
✔ Auf Client-Seite Microsoft Windows NT-lauffähig
✔ Selbst erstellte Masken müssen als MS Windows GUI generierbar sein und
mit Hilfe einer Toolbox aufgebaut werden können
✔ Den Datenbankzugriff auf Ingres gestatten
✔ Middleware: SQL auf Windows-NT, über TCP/IP auf Server unter UNIX
alternativ für kleine Ad-hoc-Anfragen mit Zugriff ODBC auf Ingres
✔ Basistechnologie ist objektorientierte 4GL
✔ DCOM-Technologie
Mit typischen DWH-Funktionen wird die Menge der anforderungskonformen
Werkzeuge weiter eingeschränkt. Für die Auswahl ist entscheidend, ob die
Funktionen helfen können, die Daten zum Verhalten der Bauteile im Kraft-
werksbetrieb zu gruppieren, zu sortieren und zu prognostizieren. Wichtig ist
ebenfalls die Darstellung der Ergebnisse in gemischten Reports aus Textbau-
steinen, Grafiken und Tabellen.
584 Kapitel 9 • Data Warehouse Produkte
NT-Client
UNIX-Server
OO-4GL
GUI-Generator
Framework
DCOM
Reiner DWH-Hersteller ODBC- Zugriff
Offenheit Beraterstamm in BRD SQL-Zugriff
Das Ergebnis der Analyse und die Aufzählung der ausgesonderten Produkte in
der Anwendung der Filterstufen soll aus Neutralitätsgründen hier nicht ange-
führt werden.
Gestaltungsentscheidung
Die herausgearbeiteten Gestaltungsentscheidungen des Projekts InDaWa sind
die Entscheidungen zur Evaluation der Produkte.
Kapitel 9 • Data Warehouse Produkte 585
PROJEKTIERUNG
PRODUKTAUSWAHL
Evaluation
Evaluationsverfahren Dreistufig
Strategische Kriterien
Offenheit Ausbaubarkeit durch Produkte
verschiedener Hersteller
Integration In bestehende Produktumgebung
Skalierbarkeit Keine Kenntnis des zukünftigen Bedarfs
Taktische Kriterien
Reiner DWH-Hersteller Interessenkonzentration
Beraterstamm in BRD Know-how-Transfer
MS-Partnerschaft Ergonomie, Standards
Marktposition Sicherheit in der Langlebigkeit
White Paper Weiterentwicklung
Langjährige Präsenz Stabilität des Produkts
Technische Kriterien
Multiwürfel Problemparameter sind unabhängige
Dimensionen
Reportgenerator Keine Standards definierbar
SQL, ODBC Ingres-Zugriff
Framework, DCOM Programmiereffizienz
Entscheidungsbaum Für schrittweise Einschränkungen und
Fallunterscheidungen
….. Cluster Für Datenhäufungen
BETRIEB
9.6 Übungen
Übung 9.1: Abwicklung der Evaluation
Wie wird eine Evaluation abgewickelt? Schildern Sie den Ablauf mit den Ergeb-
nissen der einzelnen Schritte und den erforderlichen Mitteln.
Übung 9.2: Strategische Kriterien zur Softwareauswahl
Benennen Sie die wesentlichen strategischen Kriterien zur Auswahl einer Stan-
dardsoftware. Achten Sie darauf, eine hohe Effizienz des Auswahlverfahrens zu
erreichen.
Übung 9.3: Taktische Kriterien zur Softwareauswahl
Benennen Sie die wesentlichen taktischen Kriterien zur Auswahl einer Stan-
dardsoftware. Achten Sie darauf, eine hohe Effizienz des Auswahlverfahrens zu
erreichen.
Übung 9.4: Technische Kriterien zur Softwareauswahl
Benennen Sie die wesentlichen technischen Kriterien zur Auswahl einer Stan-
dardsoftware.
586 Kapitel 9 • Data Warehouse Produkte
Kriterien Stufe 1
Kriterien Stufe 2
Kriterien Stufe 3
9.7 Zusammenfassung
Zunächst wurde eine Übersicht über den Markt erstellt. Der Markt wurde mit
einer Größenordnung von 50 bis 100 Produkten als überschaubar erkannt.
Trotzdem war es erforderlich, in einem für alle Betroffenen nachvollziehbaren
Verfahren festzustellen, welches die für die Unternehmenszwecke geeigneten
Produkte sind.
Kapitel 9 • Data Warehouse Produkte 587
KAPITEL 10
10 Betrieb und Abbau eines Data Warehouse
Systems
Nach Abschluss des DWH-Projekts wird das DWH dem Betrieb übergeben oder
für den Betrieb freigegeben. Äußeres Zeichen für den Projektabschluss ist die
Abnahme aller Ergebnisse des Projekts oder die Bestätigung, dass alle Funktio-
nen den Bedarfen entsprechend eingerichtet sind. Hierzu gehört auch, dass die
Organisationsstruktur für den Betrieb des DWH implementiert ist.
Der Betrieb hat die Aufgabe, die Verfügbarkeit und die Nutzungsqualität der
implementierten Lösungen aufrechtzuerhalten. Allgemeine Empfehlungen für
den Betrieb des DWH betreffen Implementierung von Fakttabellen und Dimen-
sionstabellen, Partionierung von Datenmengen, Einrichtung von Metadaten,
Anwendung der Verwaltungswerkzeuge, Verfügbarkeitskonfiguration, Kapazi-
tätsberechnung und Dimensionierung. Hierzu soll auf ein ebenfalls in diesem
Verlag erschienenes Buch verwiesen werden, das die Betriebsthematik des DWH
vertieft darstellt:
Anahory, Data Warehouse
Auf die Betriebsaufgaben eines DWH wird nur kurz eingegangen, da konkrete
Hinweise zu den Softwaretypen und zur Hardware sehr produktgebunden und
herstellerabhängig sind. Auf produktspezifische Betriebsempfehlungen muss
hier verzichtet werden.
Betriebsaufgaben können an externe Unterstützungsleistungen übergeben wer-
den. Diese werden dann in sogenannten Service Levels definiert. Es wird ein
knapper, für den DWH-Spezialisten ausreichender Einblick in den Aufbau von
Service Levels gegeben.
Betriebsaufgaben können zudem von Tools unterstützt werden. Die Verschie-
denheit der Systemmanagementaufgaben bringt es mit sich, dass nicht alle Auf-
gaben mit einem Tool erledigt werden können. Es ist daher eine Toolkombina-
tion zusammenzustellen. Über die Funktionalität dieser Tools und ihre
Kombination zu einem Systemmanagement-System wird ein Überblick gege-
ben.
Nach einer langen Betriebsphase ist so nach und nach ein Nachlassen der
Anfragehäufigkeit zu beobachten. Das kann z.B. daran liegen, dass die Daten
unergiebig sind, oder dass die Technologie der Dateninterpretation und Daten-
recherche noch nicht genügend ausgereift war, um die gewünschten Erkennt-
nisse zu liefern. Der Betrieb wird also eingestellt und das DWH abgebaut. Für
das DWH wurde Hardware aufgebaut, Software installiert, Organisationsstruk-
turen wurden implementiert. Mit der Software wurden Daten beschafft und
590 Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems
erzeugt. Für den Abbau des DWH muss genaue Kenntnis über alle Komponen-
ten des DWH eingeholt werden. Über die verschiedenen Komponenten ist ein
Urteil zur Weiterverwendung bzw. zur Destallation zu fällen.
Der Abbau ist umso komplexer, je komplexer das DWH war. Es empfiehlt sich
auf alle Fälle, den Abbau zu planen und wie ein Projekt abzuwickeln.
Die folgende Abbildung »Übersicht über das Kapitel Betrieb und Abbau« stellt
den diesen Entscheidungsaufgaben entsprechenden Kapitelaufbau dar.
Lernziel
Die Lernziele fokussieren zunächst die Betriebsorganisation, die Aufgaben für
den Betrieb und die Hilfsmittel. Dabei wird die Sicht auf die für einen DWH-
Spezialisten im Rahmen einer etablierten EDV-Organisation erforderliche Inte-
gration eingeschränkt. Die zweite Gruppe der Lernziele ist dem Abbau eines
bestehenden DWH gewidmet.
Lernziele
Erkennen der Betriebsaufgaben des DWH-Systems, also der DWH-Hard-
ware, des DWH-Personals und der DWH-Anwendungen
Feststellen,
werden muss
dass ein DWH-Betrieb in den gesamten IT-Betrieb integriert
Erhaltung
Erhaltung ist erforderlich, um Verschleißerscheinungen entgegenzuwirken
und zu beheben, um die Leistungen des Systems beibehalten zu können. Erhal-
tung heißt Verfügbarkeit der Funktionalität, Performance und Ergonomie
Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems 593
Definition: Erhaltung
Erhaltung ist der Ersatz defekter oder als ausfallgefährdend prognostizierter
Komponenten und Bauteile und die Pflege zum Verlängern der Haltbarkeit.
Erneuerung
Durch die Erneuerung wird mit dem technischen Fortschritt und dem Wandel
der Umwelt Schritt gehalten. Neue Technologien schlagen sich in besseren,
funktionsreicheren, stabileren und performanteren Produkten nieder. Die
neuen Produkte werden oft als neue Releases alter Produkte angeboten und
machen einen Austausch leicht.
Um das Gesamtsystem des DWH technologisch stimmig, konsistent und homo-
gen zu halten, ist eine definierte, eindeutige, kombinierte Erneuerungs- und
Erhaltungsstrategie zu verfolgen. Erneuerung und Erhaltung ist Aufgabe des
DWH-Betriebs.
Erneuerung bedeutet:
✔ defekte Teile auszutauschen
✔ fehlende Funktionalität zu ergänzen
✔ neuere, bessere Lösungen zu integrieren
✔ auf neue Technologien zu migrieren
✔ neue Updates und Releases zu implementieren
Definition: Erneuerung
Erneuerung ist der Ersatz alter Komponenten gegen neu entwickelte Kom-
ponenten.
594 Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems
Inbetriebnahme
Sind alle Betriebsvorbereitungen getroffen, muss das DWH mit »Inhalt«, sprich
mit Daten, gefüllt werden, es folgt die sogenannte Erstdatenerfassung. Diese
Daten können nicht in beliebiger Reihenfolge eingespielt werden, da sie aufein-
ander aufbauen, sich gegenseitig referenzieren und sich einige Daten aus ande-
ren berechnen. Mit den installierten Tools werden dann die Ausschnitte aus
dem Datenuniversum, das sind die Datenbanken des Unternehmens und die
externen Quellen, in der DWH-Datenbank zusammengeführt.
Der Betrieb beginnt mit einer Grundeinstellung der Parameter der Ressourcen.
Im Laufe des Betriebs werden diese Einstellungen an die laufenden Anforderun-
gen angepasst oder optimiert. Diese Anpassungen sind vom Benutzerverhalten
abhängig. Um die nötigen Betriebserfahrungen zu sammeln, muss der Betrieb
entsprechend beobachtet werden. Hierzu werden, wie noch dargestellt wird,
Systemmanagementtools eingesetzt.
Neben der Verfügbarkeit ist das Antwort-Zeit-Verhalten, die Performance, ein
wichtiges Betriebsqualitätskriterium. Die Möglichkeit der Performance-Aktivi-
täten, das Performance-Tuning, ist von den speziellen Hardware- und Soft-
wareprodukten des DWH-Grundsystems abhängig. Das nötige Wissen hierzu ist
produktspezifisch und wird in den Herstellerlehrgängen vermittelt.
Benutzerunterstützung
Ist das DWH in Betrieb, so kann davon ausgegangen werden, dass die Service-
mannschaft, der Helpdesk und die Benutzerbetreuer der bereits etablierten IT-
Systeme nicht auf den DWH-Betrieb vorbereitet sind. Der Helpdesk bzw. das
Call Center wird noch nicht einmal wissen, ob das aufgetretene Problem, das
ein Benutzer meldet, ein DWH-Problem ist. Zu einer effizienten und zielsiche-
ren Bestimmung der Fehlerquellen ist der Helpdesk zu qualifizieren.
Der Helpdesk ist nicht das einzige Mittel zur Lösung der Benutzungsprobleme
des DWH. Je besser die DWH-Anwender im Umgang mit dem DWH qualifiziert
werden, umso mehr Situationen können sie selbst beherrschen und umso
schneller sind sie wieder betriebsbereit. Es sollte deshalb eine sorgfältig ausgear-
beitete Selbsthilfestrategie in Form eines Selbsthilfemanuals vermittelt werden.
Betriebsrichtlinien
Die Betriebsaufgaben des DWH müssen abgestimmt und koordiniert werden.
Hierfür sind Betriebsregelungen oder Betriebsrichtlinien zu definieren. Die
typischen Betriebsregelungen, die zur Ausübung dieser Aufgaben gehören,
sind:
✔ Installations- und Update Management-Richtlinien
✔ Backup- und Restore-Richtlinien
✔ Sicherheitsrichtlinien mit Benutzerrechteverwaltung und Raumzutrittsü-
berwachung
Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems 595
✔ Druckerrichtlinien
✔ Netzwerkrichtlinien
✔ Service Level Agreement
✔ Dokumentationsrichtlinien
✔ Richtlinie für den Bericht zum EDV-Betrieb
✔ Qualifizierungs- und Ausbildungsrichtlinien
✔ Notfall- und Katastrophenmaßnahmenplan
Die Betriebsrichtlinien des DWH weichen nur unwesentlich von den im Unter-
nehmen etablierten Betriebsrichtlinien der gesamten EDV ab und müssen sich
in diese integrieren.
Diese Richtlinien haben den Charakter von Organisationsanweisungen und
sind in der Regel zu einem Betriebshandbuch zusammengestellt.
Verfahren: DWH-Betrieb
▼ Bewertung der Gestaltungsentscheidungen mit Betriebsgesichtspunkten
▼ Abstimmung mit Betriebspersonal
▼ Beschaffung, Prüfung Inbetriebnahme durch Betriebspersonal
▼ Erweiterung der Betriebshandbücher um DWH-Komponenten mit Hilfe der Check-
liste Betriebsaufgaben des DWH
▼ Abnahme der Betriebsregelungen und Konfigurationen durch das Rechenzentrum
▼ Tuning, Dateneinspielung, Datensicherung, Ressourcenfreigabe
▼ Integration des DWH-Betriebs in die Tagesaufgaben der Rechenzentren
▼ Freigabe der Nutzung
▼ Definition der Erneuerungsstrategie
Checkliste Betriebsaufgaben
Für die Einschätzung und Planung der Betriebsaufgaben dient die folgende
»Checkliste Betriebsaufgaben«. Die Betriebsaufgaben wurden zusammenge-
stellt aus dem eingangs erwähnten Buch:
Anahory, Data Warehouse
Betriebsaufgaben DWH
Datenbankmanagement
✔ Implementierung von Fakttabellen und Dimensionstabellen
✔ Partionierung von Datenmengen
✔ Einrichtung von Metadaten
Konfigurationsmanagement
Tabelle 10.1: Checkliste Betriebsaufgaben des DWH
Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems 597
Checkliste Betriebshandbuch
Das folgende Beispiel zeigt den Aufbau eines allgemeinen Betriebshandbuches
anhand einer Checkliste, das auch für DWH-Zwecke eingesetzt werden kann.
Einleitung
Ziel, Zweck, Gültigkeit
Betrieb
Tabelle 10.2: Checkliste zum Aufbau des Betriebshandbuchs
598 Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems
Callabwicklung
✔ Calleröffnung und Erfassung
✔ Callbearbeitung und Weiterleitung: Form, Adressat
✔ Callabschluss: Bedingung, Aktivitäten
✔ Callauswertung: Ziele, Inhalte, Folgerungen, Darstellungsform
Eskalationsrichtlinien
✔ Inhalt der Eskalationsrichtlinie: Übersicht, Aufbau
✔ Ziel der Eskalationsrichtlinie
✔ Eskalationskreis: Teilnehmer und ihre Rollen
✔ Eskalationsstufen: Auslöser, Behandlung, Ergebnis, Eskalationsprozess-
darstellung
Serviceumfang
Lokationen
✔ Netzschaubild: Namen, Adressen, Kennzeichnungen
Leistungsarten
✔ Laufende Wartung: Ersatzteillieferung, Reparaturen, Vorsorge
✔ Betrieb: Verfügbarkeit, Ergonomie, Performance, Konsistenz
✔ Task Force: Anlässe, Bestellung, Qualifikation, Reaktionszeit, Vorberei-
tung
✔ Benutzerbetreuung: Helpdesk, Ortsanweisung, Installationsbegleitung,
Einführung
Leistungsumfang
✔ Komponentenliste
✔ Lokationen: Liste, Beschreibung, nationale Besonderheiten
✔ Reaktionszeiten
✔ Organisation: Strukturen, Prozesse, Sachmittel
Beschaffung und Integration
Beschaffungsabwicklung: Zuständigkeiten, Formen und Vorlagen
✔ HW-Beschaffung und Integration
✔ SW-Beschaffung und Integration
✔ Beschaffung Netzverbindungen
✔ Beschaffung Personal, Aufbau Qualifikation
✔ Beschaffung Sachmittel
Tabelle 10.2: Checkliste zum Aufbau des Betriebshandbuchs
Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems 599
10.1.2 Systemmanagement-Tools
Problemstellung und Motivation
Von Umfang, Komplexität und Funktionalität der eingesetzten DWH-Module
hängt die Kapazität und die Qualifikation der Betriebsorganisation ab. Je mehr
600 Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems
✔ Event Management
✔ Helpdesk/Problem Management und Call Center
Zu einigen Funktionen liefern die Hersteller der Hardware- und auch der Soft-
warekomponente die maßgeschneiderten Tools mit. Andere Hersteller überlas-
sen das Feld des Systemmanagements sogenannten neutralen Produkten, die in
der Lage sind, den Betrieb mehrerer verschiedener Produkte zu unterstützen.
Eine interessante Übersicht über die Konfiguration einer Systemmanagement-
Ausstattung ist die in der folgenden Abbildung dargestellten, von der Meta
Group publizierten Auffassung. Einige dieser Tooltypen werden im Folgenden
auszugsweise kurz skizziert.
!
%
%
$
' !
&
! !
"
(
#
$
%&
Workload Management/Scheduling
Mit dem Workload Management/Scheduling wird die Lastverwaltung durchge-
führt. Die Lastverwaltung entscheidet über die Effizienz des Betriebes und
bestimmt Terminierung, Arbeitsvorbereitung, Schätzung des Ressourcenbe-
darfs und das Kapazitätsmanagement.
Die Funktionen des Workload Management/Scheduling sind:
✔ Vollständige Kalenderintegration mit Berücksichtigung des Arbeitsplans
✔ Vorgänger/Nachfolger-Beziehungen für die Gewährleistung von Job-Abhän-
gigkeiten
602 Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems
Der Nutzen des Security Managements liegt in der Steigerung der Produktivität
der Administratoren durch eine regelbasierte, aufgabenbezogene und platt-
formübergreifende Verwaltung mit einheitlicher Benutzeroberfläche. Zudem
ist Investitionsschutz gegeben, durch Integration vorhandener Security-Daten
aus dem Betriebssystem direkt bzw. über APIs und SDK und durch stufenwei-
sen (skalierbaren) Einsatz der Security über regelbasierte Lösung, neben Risi-
kominimierung bei der Implementierung.
Storage Management/Disaster Recovery
Das Speichermanagement oder Storage Management überträgt Daten von teu-
ren Speichermedien auf preiswertere Träger. Das Disaster Recovery dient der
Fehlererkennung, der Fehlersuche und der Fehlerbehebung.
Die Funktionen des Storage Management/Disaster Recovery sind:
✔ Schutz der Datenressourcen vor Überschreiben oder Fehlern bei Flexibilität
bezüglich der standortbezogenen Anforderungen
✔ Automatische Backups ohne Eingriffen durch den Operator
✔ Schnelle Katalogwiederherstellung
✔ Schwellenwert-Archivierung für die Verfügbarkeit der Medien
✔ Komprimierung von Backup-Dateien zur Senkung der Netzauslastung
✔ Einziger gemeinsamer Katalog zum Dateistatus
✔ Arbeitsband-Poolmanagement zur Auflistung aller verfügbaren Arbeitsbän-
der
Der Nutzen des Storage Management/Disaster Recovery liegt in der Steigerung
der Produktivität in der Administration durch flexible, plattformübergreifende
Backup-Methoden wie volle und inkrementelle Sicherung und durch stetigen
Zugriff auf ausgelagerte Daten, z.B. mittels integriertem Tape Managment. Es
ist die Reduzierung des Hardwarebedarfs durch hierarchische Backup-Metho-
den und Einbezug des Archives in die täglichen DV-Abläufe zu erwarten. Zudem
liegt eine Risikominimierung durch integriertes Datensicherungskonzept für
den Prozess Backup/Archivierung – Scheduling – Problem Management –
Berichtswesen – Recovery vor.
Print/Output Management
Das Print/Output Management ermöglicht die Automatisierung und Optimie-
rung der Erstellung, Zusammenstellung, Verteilung und Verfolgung von
Reports.
Die Funktionen des Print/Output Managements sind:
✔ Auswahl von Report-Seiten
✔ Verteilung von Seiten an Email
604 Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems
ten Tools für seinen Bedarf ausreichend sind. Eventuell müssen die bestehen-
den Tools für den Betrieb der DWH-Komponenten erweitert werden. Die
Erweiterung wird vom Systemmanagement-Personal durchgeführt.
➢ Definition der Anforderungen
➢ Evaluation der von den DWH-Herstellern angebotenen Systemmanage-
ment-Tools
➢ Unterstützung des Rechenzentrums bei der Evaluation der »lückenschlie-
ßenden« Systemmanagement-Tools
➢ Spezifizierung der Personalanforderungen für das DWH-Systemmanage-
ment
➢ Integration des DWH-Systemmanagements in die Tools des Rechenzent-
rums
Verfahren: DWH-Systemmanagement
❖ Anforderungen an ein Toolset für DWH-Systemmanagement und Monito-
ring mit Hilfe des SMS-Toolausstattungsschemas
❖ Prüfen der DWH-Herstellerprodukte zum Systemmanagement gemein-
sam mit dem Rechenzentrumsbetrieb
❖ Abstimmung mit Betriebspersonal, Beschaffung, Prüfung, Inbetrieb-
nahme durch Betriebspersonal
❖ Integration von DWH-Monitoring und Systemmanagement in die Tools
des Rechenzentrums
Kompo- Drucker
Client Netz Server Applikation
nenten Speicher
Management- UNICENTER UNICENTER
konsole TIVOLI TIVOLI
OpenView OpenView
Patrol Patrol
Open Master
UNICENTER UNICENTER
Workload Patrol TIVOLI
Patrol
Helpdesk Remedy
Call Center Paradigm
Paragreen
Kann der Helpdesk den Fehler nicht per Fernanleitung beheben, gibt er die
Fehlerbeschreibung an den Herstellerservice oder die Task Force weiter. Die
Task Force wird den Fehler vor Ort beheben.
Für komplexere Fälle, wie Fehler, die aus dem Zusammenspiel unterschiedli-
cher Komponenten von verschiedenen Herstellern kommen, ist ein Case-Mana-
ger erforderlich. Ein Case-Manager koordiniert die Experten der Hersteller und
die eigenen Administratoren, bis die Behebung des Fehlers gemeldet wird.
✔ betriebswirtschaftliche Funktionen
✔ Softwarekomponenten, Daten, Datenstrukturen
✔ Hardwarekomponenten
✔ Organisationsstrukturen, Personal und Sachmittel, wie z.B. Räume
Besonders wichtig ist zunächst die Information aller Benutzer über die Absicht
der Außerbetriebnahme. Hier sollte unbedingt eine Rückantwort mit einer Ein-
verständniserklärung nach Terminvorgabe eingefordert werden, um sicherzu-
gehen, dass keine Störungen verursacht werden.
Ein anderes Problem birgt die Datensicherung. Auch Daten können in Mehr-
fachverwendung durch weitere Programme stehen, das ist zum Beispiel bei
Wertebereichen der Fall. Aber auch wenn an bestimmten Programmen kein
Interesse mehr bestehen sollte, so können doch die von den Programmen
erzeugten Daten noch benötigt werden. Besonders wichtig ist zu beachten, dass
das Löschen von Daten auch die Vernichtung von Datenstrukturen umfassen
kann. Datenstrukturen sind einst in der Entwurfsphase mit viel Aufwand ent-
standen und stellen ein weiterverwendbares Know-how-Potential dar.
Sind die Programme und Daten gelöscht, kann die Hardware stillgelegt, das
heißt von Strom und Medien freigeschaltet und abgebaut werden. Je nach
Größe der Rechner ist hier ein Spezialunternehmen mit Spezialwerkzeugen für
Demontage und Transport zu beauftragen oder die Geräte sind mit dem Fir-
menschrott abzutransportieren. Es empfiehlt sich, mit dem Abbauunterneh-
men eine Begehung der Räume durchzuführen und sich die Voraussetzungen
für eine reibungslose Demontage nennen zu lassen. Der Schwerpunkt der Akti-
vitäten liegt in der Koordination der Fremdunternehmen.
Alte Geräte können nicht komplett verschrottet werden. Sie müssen zerlegt
werden und die Bauteile und Baugruppen müssen nach Umweltbelastungsklas-
sen sortiert und getrennt entsorgt werden. Da es sich um Elektronikschrott
handelt, sind Umweltschutzauflagen zu berücksichtigen. Mitunter sind trotz
schnell veralternder Technologie auch öffentliche Einrichtungen wie Schulen,
Heime oder Kindergärten noch dankbare Abnehmer. Hier ist die Lizenzfrage zu
klären und streng genommen ist aus Datenschutzgründen eine Abnahme der
gelöschten Datenträger erforderlich.
Die genannten Aufgaben sind keine Spezialfälle für das DWH, sondern allge-
meingültig für die IT-Organisation und dürfen deshalb als organisatorisch imp-
lementiert angenommen werden. Allerdings führt das DWH zu einer kapazita-
tiv höheren Anforderung beim Abbau und auch bei Umzügen. Das bestehende
IT-System wurde ja um die DWH-Maschinen erweitert.
Rollenwechsel zum Abbau
Wie schon dargestellt wurde, werden im Lebensabschnitt »Aufbau« die Rollen
für den Lebensabschnitt »Betrieb« vorbereitet. Analoges gilt für den Lebensab-
schnitt »Abbau«, dessen Rollenqualifizierung im Lebensabschnitt »Betrieb«
616 Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems
"
#
!
!
!
!
# !
!
!
"#
!
!
$
!
!
!
!
!
!
!
Großunter
Kleinfirma Mittelstand
nehmen
Geschäftsführung GF GF
GF
GF
Informatik- IM
management
IM IM IM
PL
Projektleitung PL PL PL
Fachbetreuung FB FB
FB
FB SA
Systemanalyse SA SA
SA
PR
Programmierung PR PR
AD PR
AD
Administration AD AD
Besprechungskreise
Die geschilderten Rollen stehen, wie schon im Kapitel 6 »Organisation« erklärt,
in Weisungsverhältnissen zueinander. Entsprechend dieser bis zur Aufhebung
gültigen Weisungsverhältnisse ist eine Organisationsstruktur definiert. Im
Rahmen der Organisationsstruktur werden fallweise Besprechungen zum Fort-
schritt des Abbaus, zu Risiken und zur Entscheidungsfindung abgehalten. Da
die Zusammensetzung bis auf Ausnahmen gleich ist, spricht man von Bespre-
chungskreisen des Abbaus.
In der Projektleitungssitzung Abbau werden alle regionalen DWH-Abbauaktivi-
täten besprochen. Die Sprecher, Systemanalytiker oder Administratoren tragen
den Stand der Aktivitäten vor und stimmen die Schnittstellen zwischen den
Projekten ab. Die projektübergreifenden Regelungen, wie z.B. Programmier-
richtlinien, Projektberichtswesen, Abstimmungen zum Vorgehensmodell, wer-
den wie im Aufbauprojekt verwendet. Die Projektleitungssitzung wird fallweise
Projektleiter paralleler Projekte einladen.
Der Besprechungskreis DWH-Abbau berichtet an den Besprechungskreis IT-
Management. Der Besprechungskreis IT-Management berichtet an die üblichen
etablierten Besprechungskreise. Die Sitzungstermine der Projektleitungssit-
zung DWH-Abbau müssen so koordiniert werden, dass in die anderen Bespre-
chungskreise Einwände noch vor der Umsetzung paralleler Projekte einge-
bracht werden können.
Je komplexer die Struktur der bestehenden Besprechungskreise ist, umso
schwieriger ist die Integration der DWH-Besprechungskreise, die ja zudem
noch mit den Terminen des Tagesgeschäfts abgestimmt werden müssen. Es
Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems 621
kann ein K.o.-Kriterium des DWH-Projekts sein, dass die Terminelastizität des
Unternehmens bereits zu angespannt ist. Hier ist sorgfältige Prüfung und Ter-
minpriorisierung schon in der Anfangsphase des Projekts und eventuell das
Engagement des Vorstandsponsors nötig.
Für den Abbau des DWH kann man die Einrichtung folgender Besprechungs-
kreise empfehlen:
✔ Projektleitungssitzung DWH-Abbau mit regionalen Sprechern, einmal
monatlich, auch per Videokonferenz möglich
✔ Lokale Projektsitzung mit Systemanalytikern oder Administratoren, zwei-
wöchentlich
! &
! '
")
")
")
+ )
&'
$
($
(
Abbildung 10.7: DWH- Besprechungskreise Abbauprojekt
Genau genommen findet in diesem Lebensabschnitt nicht nur der Aufbau der
für den Abbau des DWH erforderlichen Rollen statt, sondern auch deren Abbau.
Denn nach dem Abbau des DWH ist keine DWH-Tätigkeit mehr zu erfüllen und
damit auch keine Rollenbesetzung mehr erforderlich.
Der Abbau wird wieder wie ein Projekt abgewickelt; deshalb muss ein Projekt-
leiter Abbau ernannt werden. Der Projektleiter orientiert sich, welche Know-
how-Träger des »alten« DWH-Systems eingesetzt werden können, und ver-
sucht, diese in der benötigten Kapazität für den Abbau freizustellen.
$
,
")
-,
$
Outplacement-Prozedere
Nach dem Löschen der Programme sind die Systemanalytiker, die Fachbe-
treuer, die Programmierer und die Administratoren für andere Programmier-
aufgaben frei. Die PC-Betreuer werden zwar weiterhin benötigt, aber die Anzahl
der zu betreuenden Anwender hat sich verringert. Es ist zu prüfen, ob hier-
durch Kapazitäten frei werden.
Besonderes Interesse wird der Betriebsrat schon in der Vorbereitung des
Abbaus für den Umgang mit dem Personal zeigen. Er wird bei Freisetzungen
auf einem Sozial- oder Outplacement-Prozedere bestehen.
Serviceanpassung
Die abgeschlossenen Service Levels müssen um die nicht mehr existenten
Applikationen reduziert werden. Services sind zu kündigen. Aus den Anwender-
verzeichnissen sind die Rechte und Zuständigkeiten entsprechend zu kürzen.
Projektrichtlinie
Eine spezielle Projektrichtlinie für den Abbau ist nicht erforderlich. Ein DWH-
Abbauprojekt ist vom Volumen her wesentlich kleiner und von der Terminlage
her wesentlich kürzer als ein Aufbauprojekt. Es sind weniger Personen zu koor-
dinieren, weniger Aktivitäten abzuwickeln und ein wesentlich kleineres Budget
zu kontrollieren. Es sind in stärkerem Maße Auflagen des Umweltschutzes zu
realisieren, da beim Abbau zu entsorgender Elektronikschrott anfällt.
Der Bericht zu den Abbauaktivitäten, wie Terminlage, Stand der Arbeiten und
Kosten, kann in die Standardagenden der bestehenden Besprechungen aufge-
nommen werden.
Rollenliste DWH-Abbau
Auch für den Abbau ist ganz analog zum Aufbau des DWH eine Rollenbestim-
mung und die Benennung der Personen erforderlich. Für die Rollenbestim-
mung für den Abbau ist folgende Rollenliste DWH-Abbau nützlich, die struk-
turgleich mit der Rollenliste Betrieb ist und sich an deren Inhalte anbindet:
Personal Outplacement
Wiederverwendbarkeitsbeurteilung
Andere Hilfsmittel, wie ein Beispiel einer Organisationsstruktur für den Abbau,
eine Struktur der Besprechungskreise während des Abbaus, sind im Text schon
vorgestellt worden.
626 Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems
Beispiel
Im Laufe der langen Betriebszeit von Kraftwerken (30 Jahre) entsteht so viel
Betriebswissen, dass kontinuierlich ausgewertete Daten nach und nach zu einer
Sättigung der Erkenntnisse führen. Die Kosten der Datenerfassung und Ver-
wertung erreichen mit dem geringer werdenden neuen Nutzen einen Umkehr-
punkt im Kosten-Nutzen-Verhältnis. Die neuen Erkenntnisse liefern nicht
mehr die große Kostenreduktion durch neue Instandhaltungsmaßnahmen. Die
Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems 627
Betriebszeit des DWH findet dann ihr Ende, weil bereits so viele Daten erzeugt
wurden, wie für die wesentlichen Erkenntnisse erforderlich war. Es steht der
Abbau an.
Gestaltungsentscheidung
Für den Betrieb wurde das Personal definiert, die Entscheidungen für Services
und Tools zum Systemmanagement gefunden.
Die Gestaltungsentscheidungen umfassen also beim Abbau die Personalrück-
gliederung, die Hardwareverschrottung und die Softwarelöschung.
628 Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems
PRODUKTE
BETRIEB, ABBAU
Wenig Spezialwissen
10.4 Übungen
Übung 10.1: Betriebsaufgaben
Welche Aufgaben sind für den Betrieb eines DWH abzuwickeln?
Übung 10.2: Service Level
Was ist ein Service Level Agreement und wie ist ein Service Level Agreement
aufgebaut? Beschreiben Sie den in einem SLA hinterlegten Leistungsumfang.
Übung 10.3: Projektphasen
Nennen Sie die üblichen Projektphasen in der Reihenfolge ihrer Abwicklung
für die Erstellung eines DWH.
Kapitel 10 • Betrieb und Abbau eines Data Warehouse Systems 629
10.5 Zusammenfassung
In diesem Kapitel wurden die Betriebsaufgaben des DWH gestreift. Hervorgeho-
ben wurde dabei der Service zur Erhaltung der Verfügbarkeit und der Qualität
der Rechenleistung.
Es wurde das Mittel des »Service Level Agreement« zur Vereinbarung der Servi-
celeistungen und als Möglichkeit, Leistungen extern zu vergeben, vorgestellt.
Des weiteren wurde gezeigt, dass die Betriebsstrukturen auch für die Außerbe-
triebnahme des DWH wichtig sind.
631
ANHANG A
A Anhang
Orientierung
Vor den Gestaltungsentscheidungen wurde in Kapitel 1 »Orientierung« erarbei-
tet, worum es beim Thema DWH geht. Es wurde die Frage erörtert, wie das
eigentliche Gestaltungsobjekt DWH, das man aufbauen und betreiben möchte,
in die eigene Erfahrungswelt einzuordnen ist. Es wurde geklärt, wie das Gestal-
tungsobjekt genannt wird. Das Gestaltungsthema wurde abgegrenzt gegen
andere, ähnliche Gestaltungsthemen aus dem Bereich der datenbankorientier-
ten Informationssysteme. Es wurde eine Zielformulierung erarbeitet und nach
Zielkonflikten gefragt, z.B. danach, warum das fertig gestaltete Objekt so viel
Aufwand rechtfertigt.
Komponentenzerlegung und Architekturgestaltung
Es wurde festgestellt, dass das DWH-System das Softwareabbild von betriebs-
wirtschaftlichem Know-how und Betriebsfunktionen ist. Es wurde weiter fest-
gestellt, dass es nicht nur ein Softwaresystem ist, sondern nur im Verbund mit
einer Konfiguration von Hardwarekomponenten betriebsfähig ist. Der Betrieb
erforderte eine Aufgabenregelung, eine Organisation. Zusammengenommen
wurde erkannt, dass das DWH durch vier IT-Kategorien festzulegen ist, durch
Softwaretechnologie, Hardwaresysteme, Organisation und betriebswirtschaftli-
Anhang A • Anhang 633
che Aufgaben. Als Mittel, in diese Komplexität des Systems eine Ordnung zu
bringen, die das Gestaltungsproblem handhabbar macht, wurde der Architek-
turbegriff entdeckt. Mittels dieses Begriffs konnte eine Gestaltungsmethodik
auf alle IT-Kategorien angewendet werden.
Betriebswirtschaftliche Architektur
Der Gestaltungsweg wurde mit der betriebswirtschaftlichen Architektur gestar-
tet. Das DWH hilft, Unternehmensziele zu erreichen. Ein DWH kann manuelle
Funktionen des Geschäftsbetriebes des Unternehmens ersetzen. Es erfüllt
betriebswirtschaftliche Funktionen. Das DWH ist ein Teil des Betriebsgesche-
hens und damit ein Stück Organisation. Das DWH realisiert eine betriebswirt-
schaftliche Architektur.
Software-Architektur
Die betriebswirtschaftlichen Funktionen werden mittels Softwarefunktionen
automatisiert. Für die Darstellung in Softwarefunktionen sind mehrere Tech-
nologien möglich. Ein DWH ist so komplex, dass sogar mehrere Technologien
zum Einsatz kommen. Es wurde herausgefunden, dass die grundsätzlichen
Komponentengruppen, aus denen ein DWH zusammengesetzt ist, die Basisda-
tenbanken unterschiedlicher Strukturen, die DWH-Datenbank mit Archivie-
rung und Metadatenbank, die Desktop-Tools für Präsentationen und Auswer-
tungen und die Middleware-Tools für die Verbindung der unterschiedlichen
Technologien sind. Die Bestandteile des DWH bilden eine Software-Architektur.
Hardware-Architektur
Für den Betrieb von Software muss eine Hardwareplattform verfügbar sein. Es
wurde festgestellt, dass kein DWH-Anwender ernsthaft erwägt, die Rechner-
hardware selbst bauen zu wollen. Deshalb ist auch kein Rechnerentwurf erfor-
derlich. Rechner werden nur spezifiziert und, meistens der Empfehlung der
Softwarehersteller für die Konfiguration folgend, beschafft. Dem Rechnerher-
steller stehen Konfigurationsalgorithmen zur Verfügung, deren Grundwerte im
Interview erhoben werden. Die Rechner sind über lokale und überregionale Lei-
tungen und Netze verbunden.
Der DWH-Anwender wird die Personalkapazität, LANs und WANs zu installie-
ren, nicht vorhalten. Dennoch, einen Entwurf von LAN und WAN, bzw. die Defi-
nition der Anforderungen, muss er sich leisten. Für den Aufbau des LAN muss
er artikulieren, was er benötigt. Er muss sein LAN und WAN spezifizieren, und
damit muss er auch eine Methode zur LAN-Spezifizierung beherrschen. Der
Spezifizierung entsprechend wird die Installation der LAN- und WAN-Kompo-
nenten bestellt. Die dafür geeigneten Methoden sind im Vorgehensmodell inte-
griert worden.
Organisationsarchitektur
Das DWH muss von Spezialisten aufgebaut und betrieben werden. Für den letz-
ten Bestandteil der IT-Kategorie, die »IT-Organisation«, wurde deshalb die
634 Anhang A • Anhang
Frage geklärt, von wem das DWH in welcher Reihenfolge mit welchen Kompe-
tenzen aufgebaut wird und welche Aufgaben dabei zu erledigen sind. Es ist die
Frage nach der Aufbau- und nach der Ablauforganisation gelöst worden.
Methoden und Vorgehensmodell
Das Vorhaben DWH soll seinen Beitrag zur Unternehmenszielsetzung nachwei-
sen können. Für diesen Nachweis wurde festgestellt, dass aus Umwelteinbet-
tung, Umfeldsystemen und Strategien Anforderungen abzuleiten und aus der
Sicht des Benutzers in einer Konzeption zu beschreiben sind. Die Benutzer for-
mulieren diese Anforderungen, die betriebswirtschaftliche Funktionen, Soft-
wareergonomie, Hardwareeigenschaften und Organisationsanforderungen
umfassen, in ihrer Fach- und Umgangssprache.
Es muss allerdings mit wesentlich mehr Detailtiefe, als sie die Konzeption lie-
fern konnte, definiert werden, was hergestellt werden soll. Die Detailtiefe muss
deshalb so weit getrieben werden, dass sie einem Programmierer als Hand-
lungsanleitung dienen kann. Das Ergebnis dieser Detaillierung wurde eine Spe-
zifikation, die Phase wurde hier Entwurf genannt. Je nach Programmiertech-
nik, Programmiersprache und Datenhaltungstechnik ist eine andere
Spezifikation erforderlich.
Auf die Ermittlung des »Was« als Ergebnis der Gestaltungsentscheidungen
folgt dann die Ermittlung des »Wie«, d.h. der Methodik, der Vorgehensweise
und der Hilfsmittel. Erst wenn dieses »Wie« entschieden ist, kann die Projektie-
rung fertiggestellt werden. Es ist für den Projektablauf und die Terminierung
von entscheidender Bedeutung, ob eine Datenstruktur als Text beschrieben,
gleich über das Datenbankmanagementsystem definiert oder in einer Entwurfs-
phase grafisch dargestellt wird. Jede der Vorgehensweisen beansprucht andere
Aufwände und andere Tools und hat je nach Größe des Projekts mitunter ver-
heerende Konsequenzen. Es mussten schon Projekte abgebrochen werden, weil
mit der Wahl der falschen Methoden der Überblick nicht transparenter, sondern
undurchschaubarer wurde.
Die Hilfsmittel zur Formulierung des Entwurfs sind Methoden. Da ein Entwurf
aus mehreren verschiedenen, aufeinander aufbauenden Teilen besteht, kom-
men mehrere Methoden zum Einsatz. Die Reihenfolge der Anwendung dieser
Methoden, also das Vorgehen bei der Anwendung der Methoden auf den Spezifi-
kationsgegenstand, wird mittels eines Vorgehensmodells geregelt.
Auch bei Buy-Entscheidungen sollte die Vorbereitung des Beschaffens metho-
disch geleitet sein und damit ihren Platz im Vorgehensmodell finden. Zusam-
mengefasst ließ sich sagen, dass sich die Wahl der Methoden am Gestaltungsob-
jekt orientieren muss. Je nach Gestaltungsobjekt ist eine andere Methode
effizienter einsetzbar.
Projektierung
Am Ende des Durchlaufs der Gestaltungsentscheidungen und nach der Festle-
gung eines Vorgehensmodells ist die Projektstruktur durch die aufzubauenden
Anhang A • Anhang 635
$
'/
.:*
%
8
#
(
! *+
"
#
'8''
!
'
sind wertlos, erst wenn die Daten neue Sachverhalte liefern, werden sie zu
Informationen. Die Daten werden um Hinweise, Erklärungen, Verwendungsre-
geln und Expertisen ergänzt und zu Erkenntnissen aufgewertet. Wissen in Köp-
fen, Systemen und Dokumentationen ist zu wertvoll, um nicht zu erreicht wer-
den und erhalten bleiben zu können. Es Bedarf der Verwaltung oder eines
Wissensmanagements.
Die Daten eines Unternehmens bilden einen Unternehmenszustand ab. Dazu
gehört auch der aktuelle Know-how-Status des Unternehmens. In den Daten
des Unternehmens ist ein Know-how-Profil verborgen. Das Wissen sind Regeln,
Aussagen und Folgerungen zu den Informationen im Kontext des Unterneh-
mens. Zusammen mit dem Wissen um die Bedeutung der in den Daten mani-
festierten Informationen ist das Data Warehouse ein Knowledge Warehouse.
➡ In Zukunft werden in allen Bereichen der Softwaretechnologie und auch in
DWH-Architekturen Elemente des Wissensmanagements integriert werden.
Das Data Warehouse wird sich zu einem Knowlegde Warehouse weiterent-
wickeln.
Das Thema Wissensmanagement und die Behandlung von Daten als Wissen
und Gegenstand des Handelns ist dargestellt in:
Petkoff, Wissensmanagement
In der folgenden Abbildung werden die Kompomenten des Knowledge Ware-
house dargestellt.
Wissens- Wissens-
zielsetzung bewertung
Wissens- Wissens-
identifikation bewahrung
Wissens- Wissens-
Wissenserwerb
archivierung nutzung
Wissens- Wissens-
entwicklung verteilung
Wissens-
administration
640 Anhang A • Anhang
Produktion
Archivierung Technische
Konstruktion
Dokumentation Berechnung
Personal Kosten
Organisation
PDM Finanzen
Marketing
Abbildung A.3: Integration der technischen und kaufmännischen Systeme durch PDM
In früheren Zeiten der Datenverarbeitung wurden DWH in erster Linie für die
Analyse kaufmännischer Daten eingesetzt. Heute werden die Analysen bereits
auf nichtmonetäre Sachverhalte, wie z.B. Kundenverhalten im Handel und Vor-
lieben bei Produktanalysen einbezogen. In Zukunft wird die Analyse sich auf
den Produktionsprozess ausweiten und damit technische Systeme integrieren.
➡ Zukünftig wird es eine stärkere Integration von technischen und kaufmän-
nischen Daten im DWH geben.
Die Thematik DWH und Produktdatenmanagement ist in der Literatur derzeit
nicht als Monographie vertreten.
A.3 Schluss
Die Gestaltungsfragen sind behandelt, d.h. die Lösung ist konzipiert. Es sind
auch die Fragen für die Umsetzung besprochen und die Umsetzung ist konzi-
piert, d.h. projektiert. Die Aufgabenträger sind bestimmt.
Jetzt kommt der Tag der Wahrheit. Ein guter Konzeptionist muss noch nicht
der optimale Umsetzer sein. Umsetzen heißt, sich mit den Widerständen anders
Interessierter auseinandersetzen zu müssen. Umsetzen bedeutet, diese Interes-
sen – und wenn sich mehrere Meinungsträger zusammentun diese Interessen-
strömungen – frühzeitig zu erkennen. Die Erkenntnis ist unbequem. Der Pro-
jektleiter wie der Sponsor müssen sich mit dem Interessenstrom
auseinandersetzen.
642 Anhang A • Anhang
ANHANG B
B Anhang
Aufgaben
Projektbezogen
✔ Initiieren, Strukturieren und Prüfen von Organisationsanalysen
✔ Initiieren, Strukturieren und Prüfen von DWH-Konzeptionen
✔ Initiieren, Strukturieren und Prüfen von DWH-Entwürfen
✔ Initiieren, Strukturieren und Prüfen von Wirtschaftlichkeitsanalysen
✔ Initiieren, Strukturieren und Prüfen von Projektplänen
✔ Budgetierung des Gesamtprojekts
✔ Initiieren, Strukturieren und Prüfen von Produktevaluationen
✔ Beratung der Konzernführungsebene
✔ Erstellung von Stellenanzeigen und Inseraten
✔ Mitführung von Einstellungsgesprächen für DWH-Personal
✔ Mitarbeit bei der Erstellung von Arbeitsanweisungen für DWH-Personal
✔ Anwesenheit und Mitarbeit bei EDV-Revisionen und Datenschutzprüfungen
✔ Erstellung des Projekthandbuches für DWH-Projekte
✔ Soziologische und politische Vorbereitung des DWH-Projekts
✔ Kundenberatung bei DWH-Lösungen
✔ Einführung von Methoden und Verfahren für DWH-Projekte
✔ Abnahme und Freigabe von DWH-Produkt- und Entwicklungsimplementa-
tionen
✔ Ausbildung von Key-Usern und Managern im Gebrauch des DWH
✔ Pflegen der Lieferbeziehungen bezüglich der eingesetzten DWH-Produkte
✔ Pflegen der Beziehungen zu DWH-Instituten
✔ Sicherstellung der ordnungsgemäßen Protokollführung in allen Projektbe-
reichen
✔ Prüfung der Projektkosten und Abrechnung der Projektleistungen
✔ Sicherung der Projektdokumentation und Know-how-Sicherung
Projektübergreifend
✔ Rückführung von Projekterkenntnissen in allgemeine Richtlinien
✔ Mitarbeit bei der Gestaltung von Produkten mit DWH-Bezug
✔ Mitarbeit bei der Produktkalkulation und Marketingkonzepten
Anhang B • Anhang 647
Eingliederung
Überordnung
✔ Projektmanager DWH
✔ Abteilungsleitung am Anstellungsort
Unterstellung
✔ Alle DWH-Teammitglieder international indirekt
Vertretung
✔ Durch benannten stellvertretenden Teilprojektleiter
Aufgaben
Projektbezogen
✔ Mitarbeit und Koordination von Organisationsanalysen der Lokation xxx
✔ Mitarbeit und Koordination von DWH-Konzeptionen der Lokation xxx
✔ Mitarbeit und Koordination von DWH-Entwürfen der Lokation xxx
✔ Mitarbeit bei Wirtschaftlichkeitsanalysen der Lokation xxx
✔ Mitarbeit und Koordination von Projektplänen der Lokation xxx
✔ Budgetierung des Teilprojekts der Lokation xxx
✔ Mitarbeit bei Produktevaluationen
✔ Beratung der Abteilungsebene der Lokation xxx
✔ Anwesenheit bei Einstellungsgesprächen für DWH-Personal der Lokation
xxx
✔ Mitarbeit bei der Erstellung von Arbeitsanweisungen für DWH-Personal
✔ Mitarbeit bei EDV-Revisionen und Datenschutzprüfungen der Lokation xxx
✔ Kundenberatung bei DWH-Lösungen der Lokation xxx
✔ Einführung von Methoden und Verfahren für DWH-Projekte im Teilprojekt
der Lokation xxx
✔ Mitarbeit bei der Abnahme von DWH-Implementationen der Lokation xxx
✔ Ausbildung von Key-Usern und lokalen Managern im Gebrauch des DWH
✔ Pflegen der Lieferbeziehungen bezüglich der eingesetzten DWH-Produkte
✔ Sicherstellung der ordnungsgemäßen Protokollführung in der Lokation xxx
✔ Prüfung der Projektkosten und Abrechnung der Projektleistungen der
Lokation xxx
Anhang B • Anhang 649
Eingliederung
Überordnung
✔ Teilprojektleiter DWH
✔ Abteilungsleitung am Anstellungsort
Unterstellung
✔ keine
Vertretung
✔ keine
Aufgaben
Projektbezogen
✔ Ausarbeitung von Organisationsanalysen der Lokation xxx
✔ Ausarbeitung von DWH-Konzeptionen der Lokation xxx
speziell: Infrastrukturanforderungen, Fachkonzepte
✔ Ausarbeitung von DWH-Entwürfen der Lokation xxx
✔ Ausarbeitung von Wirtschaftlichkeitsanalysen der Lokation xxx
speziell: Investitionsplan, Nutzwertanalyse, Zahlungsreihen, Kostenumle-
gung
✔ Mitarbeit bei Projektplänen der Lokation xxx
speziell: Terminbalkenplan, Einsatzplan, Netzplan
✔ Mitarbeit bei Budgetpositionen des Teilprojekts der Lokation xxx
✔ Durchführung von Produktevaluationen und Teststellungen
speziell: DWH-Client-Tools yyy, DWH-Serverkomponenten zzz, Betriebssys-
tem zzz, Middleware zzz
✔ Beratung der Teilprojektleitung der Lokation xxx
✔ Auskunft bei EDV-Revisionen und Datenschutzprüfungen der Lokation xxx
✔ Benutzerbetreuung bei DWH-Lösungen der Lokation xxx
✔ Einsatz von Methoden und Verfahren für DWH-Projekte im Teilprojekt der
Lokation xxx
speziell: Datenmodell, Dialogmodell, Aggregationsdiagramm, Funktions-
baum, Objektmodell, Kontextdiagramm
✔ Mitarbeit bei der Abnahme von DWH-Implementationen der Lokation xxx
✔ Ausbildung von Key-Usern im Gebrauch des DWH
✔ Pflegen der Lieferbeziehungen bezüglich der eingesetzten DWH-Produkte
✔ Sicherstellung der ordnungsgemäßen Protokollführung in der Lokation xxx
Anhang B • Anhang 651
Lösungen
Es sind nur für diejenigen Aufgaben Lösungen angegeben, die nicht bereits
durch den Text direkt beantwortet sind. Dies sind z.B. Lösungen zu den Fragen
nach Definitionen. Es sind auch nicht Lösungen zu Gestaltungsfragen aufge-
nommen, da diese von der aktuellen Situation des Unternehmens abhängen.
Lösung:
Trendkarte: Executive Information Systems
Trend:
Der Markt der Decision Support Systems und der Executive Information Systems
ist in den Markt für Data Warehouse Systeme übergegangen. Dort tauchen sowohl die glei-
chen Hersteller als auch die gleichen Produkte nur unter anderem Namen auf, werden aber um
neue Funktionen aus KI und Neuronalen Netzen ergänzt. Der Einsatz eines DSS bzw. eines EIS
neben einer Entwicklungsumgebung ist gleichbedeutend mit dem Einsatz eines weiteren Ent-
wicklungswerkzeuges und einer weiteren replikativ zu betreibenden Datenbank. Der Aufwand
Anhang B • Lösungen 653
Anpassung an Firmensprache
!( % -#$
'(
! * !(
(,
(*
#
( (
"
"
!
Entscheidungsgang Datenbankkomponenten
System- Teil-
IT-Kategorien System-Typen
Komponenten komponenten
Produkte
Funktionalität
Welche
Anwendung Objektorientierg
Parallelisierung
Multimedial
Ableitung Fuzzy
Frame/4Gl/Rule
Integration DBMS- Simulation
Welche
Komponente
Software
Technologie Standardgrad Queryoptimizer DB2
Replikator Oracle
Anwendngstyp DB-Applikation Ruler Informix
Schema-Manager Sybase
DB-Anwendng Konfigurator
DBMS CENTURA
Expertensystm TransaktionMonitr..
GUIMS Ingres
KIS/KNN/FUZS
Applikationsmgr Progress
HTMLAnwendg
Middleware AdabasD
USERTool/Grp
EIS/DSS/OLAP RDB
CAD/CIM/CAM ACCESS
Anim,Simul,VR
Funktionalität
flach
hierarchisch
vernetzt
relational
deduktiv
objektortrt
technisch
geologisch
Welche
Hardware
Technologie GUIMS-
Komponente
MS-Wind
Terminalemulator OSF-Motiv
Ableitung Verteiler Mac
User-Agent
Usermodellmangr
...
Applikations-
Komponente
4GL-Precompiler
SQL-Precompiler
Framework
3GL-Compiler
....
IDAPI
OLAP
Middleware- API
Komponente CAPI
DDL-Transformtr APPN
NetzprotklTreiber ODBS
OS-Utility OLE
Navigator HTTP
....
-) -)+,,!.
$%
/
)
+
$
%(
) '%%1$
!
"# !0#
$%
222 3,45
%) ( &
- %) (
&
+,+ '%
) ' (
%
%
*) (
!"
#$
6
5
3# & $ () )'%%
!
"#
$%
&
Abbildung B.6: Aggregation
Literaturverzeichnis
Der Betrieb ist von Produkt zu Produkt verschieden und dementsprechend nur
in produktbezogenen Quellen mit der nötigen Tiefe zu behandeln. Hier muss in
erster Linie auf die Handbücher der Produkte verwiesen werden, die in der
Regel von den Herstellern geliefert werden. Ausnahmen bilden die weitverbrei-
teten Produkte, zu denen auch von neutralen Autoren Bücher geschrieben wer-
den. Es sei je ein Beispiel für ein betriebsbezogenes allgemeines Buch und ein
produktbezogenes Buch von einem neutralen Autor angegeben.
B.7 Monographien
Anahory S., Murray D., Data Warehouse, 1997, Bonn
Das Buch ist auf seinen ca. 400 Seiten ein zusammengefasster Praxisbericht
einiger DWH-Projekte mit einer Sammlung nützlicher Tips und einer für die
Projektplanung einsetzbaren Aktivitätenliste mit Aufwandschätzungen. Nützli-
che Erfahrungen sind in die Empfehlungen zur Organisation von Datenstruk-
turen wie Partionierungsstrategie, Einrichtung des Datenbankschemas, Aufbau
von Aggregationen eingeflossen. Plausible Beispiele helfen, die nur schwer in
allgemeine Regeln fassbaren Themen Performance, Hardwarekonfiguration
und Betriebsaufgaben zu durchdringen. Für Bestellungen bei Herstellern sind
im nächsten Kapitel die Adressen der im Buch erwähnten Hersteller angeführt.
Anselstetter, R., Betriebswirtschaftliche Nutzeffekte der Datenverarbeitung,
1984, Berlin, Heidelberg
Eine ca. 250 Seiten lange Abhandlung über Kostenarten und die Wirkung von
Nutzenarten auf die Kostenstrukturen der Unternehmung. Sehr ausführliches
Literaturverzeichnis zu den bis zum Erscheidungsdatum veröffentlichten Stu-
dien über Kosten und Nutzenfaktoren.
Badach, A., Integrierte Unternehmensnetze, 1997, Heidelberg
Umfassende, sehr detaillierte Darstellung der LAN- und WAN-Thematik für
Experten. Sehr aufwendige grafische Darstellungen vom Zusammenspiel der
Ebenen der Kommunikationsprotokolle.
Balzert, H., Lehrbuch der Software-Technik: Software-Entwicklung, 1996,
Heidelberg
Umfassendste deutschsprachige Darstellung (zwei Bände, ca. 2000 Seiten!) zum
Thema Software Engineering. Neues Buchkonzept mit interessantem Layout,
viele Grafiken, zweifarbig, alle Grafiken als CD-ROM erwerbbar. Band 1, Soft-
ware-Entwicklung, ist nach Phasen aufgebaut: Planung, Definition, Entwurf,
Implementierung, Abnahme und Einführung, Wartung und Pflege.
Anhang B • Literaturverzeichnis 663
Henze, R.), welche die Ableitung einer systematischen Einteilung der Thematik
Problemlösung etwas aus dem Auge verloren hat.
Bröhl, A.-P., Dröschel, W., Das V-Modell, München, Wien 1997
Ein im Auftrag des Bundesministeriums des Innern erarbeitetes Modell für die
Abwicklung von IT-Vorhaben zur Anwendung bei Auftragsvergaben, zur Ver-
tragsgestaltung und zur Festlegung von Dokumentationsvorschriften. Auf ca.
800 Seiten wird systematisch über eine Phasenaufteilung von IT-Projekten der
Ablauf aller Phasen mit Eingangsinformationen, Tätigkeiten innerhalb der Pha-
sen, Ausgangsinformationen und Rollenzuordnungen dargestellt. Neben dem
reinen Phasendurchlauf werden die begleitenden Aktivitäten zum Projektma-
nagement und zur Qualitätssicherung in sogenannten Submodellen beschrie-
ben. Das dort beschriebene Modell, das V-Modell genannt wird, ist eine Vorgabe
für die Entwicklung eigener Modelle und damit ein Metamodell für IT-Vorge-
hensmodelle. Das V-Modell ist ein nützlicher Fundus und eine ausgezeichnete
Basis für die Strukturierung eines eigenen Vorgehensmodells für die ISO-900x-
Zertifizierung.
Brosius, G., Microsoft OLAP Services, 1999, Bonn
Das ca. 390 Seiten starke Buch behandelt die Themen multidimensionale Kon-
zepte und grundlegende Fachbegriffe zu OLAP, Entwurf einer OLAP-Datenba-
sis, Implementierungsfragen und Installation, sowie Clientwerkzeuge für
Abfrage und Reporting. Das Buch ist in Zusammenarbeit mit Microsoft entstan-
den, was einen gewissen Tiefgang begründet.
Boehm, B. W., Wirtschaftliche Softwareproduktion, 1986, Wiesbaden
Ein schon etwas in die Jahre gekommenes, aber immer noch gern zitiertes
Buch, wenn es um die Berechnung von Entwicklungsaufwänden geht. Mit 670
Seiten das umfassendste Buch dieser Art, das aber leider nur auf die konventio-
nelle 3GL-Programmierung eingeht. Enthält trotzdem wertvolle Erfahrungs-
werte zu den Aufwänden der Softwarentwicklung zu allen Phasen.
Bullinger, H.-J.; Koll, P., Niemeier, J., Führungsinformationssysteme – Ergeb-
nisse einer Anwender- und Marktstudie, 1993, IAO, Stuttgart
Mit einer Einführung in die Thematik, Fallbeispielen und 15 umfangreichen
Produkte-Synopsen und 45 Herstellern, ausgezeichnete Grafiken und guter
Text von hohem didaktischen Wert, gutes Literaturverzeichnis. Leider nach
1993 keine Neuauflage.
Burghardt, M., Projektmanagement – Leitfaden für die Planung und Steue-
rung von Entwicklungsprojekten, 1988, München
Immer noch das nicht von Seitenzahl, sondern von Inhalt und Anzahl der
besprochenen Methoden und Hilfsmittel umfangreichste Handbuch für den
Praktiker, geliedert nach den Projektphasen Definition, Planung, Kontrolle
(Durchführung), Abschluss, Unterstützung (Begleitung).
Anhang B • Literaturverzeichnis 665
Gluchowski, P., Gabriel, R., Chamoni, P., Management Support Systeme, 1997,
Heidelberg
Das ca. 380 Seiten starke Buch leitet die Anforderung für eine Struktur von
Management Support Systemen aus der Analyse des Managementprozesses ab.
Auf dieser grundlegenden Anforderung werden aus Phasensicht das Systemum-
feld, die Strukturbestandteile, die Gestaltung und die Nutzung betrachtet.
Jeweils ein weiteres Kapitel ist jeder der »speziellen Ausprägungen« von MSS,
den Management Informationssystemen, den Decision Support Systemen, den
Executive Information Systemen, den Executive Support Systemen gewidmet.
Das Buch schließt ab mit den Einsatzmöglichkeiten und einer Wirtschaftlich-
keitsbetrachtung.
Grochla, E., u.a., Integrierte Gesamtmodelle der Datenverarbeitung – Ent-
wicklung und Anwendung des Kölner Integrationsmodells, 1974, München
Auf ca. 400 Seiten wird der erste veröffentlichte Bauplan eines MIS im Sinne
eines geschlossenen vollständigen integrierten Systems, für alle betriebswirt-
schaftlichen Belange, vorgestellt.
Grochla E., Szyperski H., Hrsg., Management-Informationssysteme – Eine
Herausforderung an Forschung und Entwicklung, 1971, Wiesbaden
Mit 890 Seiten eines der umfangreichsten deutschsprachigen Bücher, das je
zum Thema Managementinformationssysteme erschienen ist, aus der Zeit, in
der der Begriff »Management Informationssystem« entstanden ist. Ein
Schnappschuss der Aktivitäten namhafter Forscher, auf einem vom Bundesmi-
nisterium für Bildung und Wissenschaft unterstützten zweitägigen Symposium
im Juli 1970 auf Einladung der Uni Köln aufgenommen. Inhalt: Grundlegende
Problemstellungen, Gestaltungs- und Implementierungsprobleme, Modelle
und Methoden, Auswirkungen auf Organisationsstrukturen, Benutzerpro-
bleme. Unbedingt empfehlenswert!
Hanker, J., Die Strategische Bedeutung der Informatik für Organisationen,
1990, Stuttgart
Stellt auf ca. 550 Seiten über die Grundlagen der Wirtschaftstheorie die Bedeu-
tung der Informatik für die Volkswirtschaft und daraus abgeleitet für das ein-
zelne Unternehmen dar und begründet damit eine Ausrichtung des strategi-
schen Informatikmanagements.
Hansen, R., Wirtschaftsinformatik 1: Grundlagen betrieblicher Informations-
verarbeitung, 1998, Stuttgart
Schneidet als Gesamtdarstellung alle Gebiete der Unternehmens-EDV an. Ent-
hält einige nützliche Typologien und Charakteristiken zu Software und Hard-
ware. Liefert definitorische Abgrenzungen, leistet sich sogar Fotografien. Ist als
Taschenbuchformat gut für unterwegs trotz des Umfangs von mehr als 1000
Seiten. Didaktisch gut aufgebaut. Enthält Lernziele und eine umfassende Auf-
gabensammlung in einem extra Band. Ein Muss!
668 Anhang B • Literaturverzeichnis
stellung im Büchermarkt hat das Buch derzeit zum Thema Web-enabled DWH.
Zum Ausklang des Buches wird auf die Nutzenpotentiale des e-Business einge-
gangen. Das Buch gehört in die Grundausstattung jedes DWH-Spezialisten.
Liebelt, W., Sulzberger, M., Grundlagen der Ablauforganisation, Schriftenreihe
»Der Organisator«, Band 9, 1989, Gießen
Auf ca. 270 Seiten werden zur Ablauforganisation dargestellt: Grundbegriffe,
Gestaltungsinhalte, Ziele, Modelle, Organisationstechniken (z.B Entscheidung-
stabellen), Managementtechniken (z.B. Netzplan).
Liebig, M., Entscheiden, 1993, Frankfurt am Main
Auf ca. 370 Seiten werden Methoden und Verfahren zur Bearbeitung von Pro-
blemen und kreativen Lösungsfindung, im Team und im Alleingang, anwendbar
und anhand anschaulicher Grafiken sehr praktisch dargestellt.
Lippe, von der, P. M., Wirtschaftsstatistik, 5. Auflage, Stuttgart 1996
Das Buch ist eine umfassende (ca. 500 Seiten) Darstellung zum Thema der amt-
lichen Statistiken zum Zwecke der Volkswirtschaftlichen Gesamtrechnung. Das
Buch ist dann äußerst nützlich, wenn das DWH Daten aus amtlichen Statisti-
ken mit einbeziehen soll. Es geht detailliert auf die Erstellung und Erhebung
von Statistiken zu Bevölkerung, Erwerb, Unternehmen, produzierendem
Gewerbe, Geld und Kredite, Preise, Einkommen und Verbrauch sowie Außen-
handel ein.
Macharzina, K., Unternehmensführung, das internationale Mannagementwis-
sen: Konzepte – Methoden – Praxis, Wiesbaden 1993
Auf rund 900 Seiten wird ein vollständiger Einblick in die Aufgabenstellung der
Unternehmensführung geleistet. Die Thematik behandelt in Folge Theorien der
Unternehmensführung, Unternehmensverfassung, Unternehmensziele, Unter-
nehmensgrundsätze, Unternehmenskultur, Strategieformulierung, Control-
ling, Organisation, Personalführung, Informationsmanagement. Die Aussagen
aller Kapitel werden von ausführlichen Beispielen unterstützt. Mit dem Buch
kann die Zielsetzung, Aufgabenfindung und Aufgabenstellung von Unterneh-
men besser verstanden werden.
Nagel, K., 200 Strategien, Prinzipien und Systeme für den persönlichen und
unternehmerischen Erfolg, 1995, Landsberg
Umfangreiche Sammlung von Methoden und Hilfsmitteln für das weitge-
spannte Feld von persönlicher Arbeitsstrukturierung, Führungsaufgaben, Stra-
tegiedefinition, Kreativität, Kundenumgang, Trendfaktoren, Motivation. Leider
unsystematisch und nur grob sortiert, ohne Typisierung der Methoden, ohne
didaktische Unterstützung. Für den Praktiker schnell und ohne Theorielasten
einsetzbar, aber auch ohne große Begründung und ohne Vor- und Nachteilsab-
wägung. Trotzdem eine Fundgrube.
Anhang B • Literaturverzeichnis 671
Österle, H., Riehm, R., Vogler, P., Hrsg., Middleware, 1996, Wiesbaden
Das einzige Buch derzeit, welches das Thema Middleware systematisch und
modern darstellt. Mit ca. 260 Seiten kann das Thema leider nicht erschöpfend
dargestellt werden, aber was der DWH-Spezialist zur Problemstellung und zur
Evaluation wissen muss, ist enthalten. Ausgangspunkt ist eine Klassifikation.
Mit einer Produktübersicht und einer Methodik zur Evaluation von Middlewa-
reprodukten schließt das Buch eine Lücke der Lehrbuchlitaratur.
Petkoff, P., Wissensmanagement, 1998, Bonn
Mit ca. 500 Seiten sehr detaillierte, zunächst theoretisch fundierende, dann
praktisch angewendete Darstellung. Das theoretische Fundament wird gelegt
mit der Erfassung des Status zum Thema Wissen, Expertisen, Modellierung und
Wissensmanagement. Dem Erschließen von Wissen wird sich mittels des Ver-
fahrens der Problemlösung aus kybernetischer Sicht genähert und durch die
Sicht eines fundamentalen soziologischen Begriffes, des »Handelns«. Mit diesen
Vorbereitungen wird die Methodologie »ACCORD«, bestehend aus den drei
Komponenten Metamodell, Vorgehensmodell und Agentennetze, abgeleitet. Die
Methodologie wird anschließend auf den SAP R/3 Business Agenten angewen-
det. Das Buch leitet jedes Hauptkapitel mit einem historischen Überblick ein. Es
hat an vielen Stellen philosophischen Tiefgang und ist daher eher für den Lieb-
haber als für den Praktiker im Projekt geeignet, aber hochinteressant.
Scheer, A., Wirtschaftinformatik, 1998, Berlin
Der Begriff Wirtschaftsinformatik ist etwas zu weit gegriffen, da nicht die
gesamte WI, z.B. keine Hardware und keine Software im Allgemeinen, erörtert
werden, sondern »nur« industriebetriebswirtschaftliche Datenbankapplikatio-
nen. Im Untertitel steht »Referenzmodell für industrielle Geschäftsprozesse«.
Diese werden in einer nie dagewesenen Detaillierung und systematischen Kon-
sequenz auf ca. 1000 Seiten aus den drei Perspektiven Funktionalität, Daten,
Prozesse so ausführlich diskutiert, dass sie als Referenzmodell weithin Inter-
esse finden. Scheer ist ein Muss für alle, die betriebswirtschaftliche Applikatio-
nen entwerfen. Zum Lehrband gibt es einen Arbeitsband mit Aufgaben und
Lösungen. Scheer wendet bei der Erstellung seines Buches die von ihm entwi-
ckelte Methodik, bzw. das Vorgehensmodell »ARIS« an. Das Literaturzitat wird
im Kapitel »Vorgehensmodell« gegeben.
Silverstone, L., Inmon, W.H., Graziano, K., Data Model Ressource Book, 1997,
New York
Eine ca. 400 Seiten lange Sammlung von Referenz-Datenmodellen zu Personal,
Marketing, Produktion und Rechnungswesen aus der Praxis mit einem, wie die
Autoren meinen, allgemeinen Verwendbarkeitswert. Als Anregung und zum
schnellen Einstieg allemal interessant, aber wer schon einmal die Erfahrung
machen durfte, Firmen-Know-how in ein Datenmodell umzusetzen, weiß es
besser: Alle Datenstrukturen müssen von Anfang durchdiskutiert werden.
672 Anhang B • Literaturverzeichnis
Schelle H., Reschke H., Schnopp R., Schub A., Hrsg., Projekte erfolgreich
managen, 1994, Köln
Ca. 2000 Seiten starke, sehr kompetente Loseblattsammlung der Gesellschaft
für Projektmanagement. Gegliedert in Grundlagen, Zielsysteme, Ressourcen,
Verfahrenssysteme, Institutionensysteme, Software, Anwendungsbeispiele,
Qualifizierung. Die Einzeldarstellungen sind großenteils sehr ausführlich.
Schütte, R., Grundsätze ordnungsmäßiger Referenzmodellierung, 1998, Wies-
baden
Das Thema Referenzmodellierung ist in der Literatur unterversorgt. Eine syste-
matische Erschließung in einer Monographie ist bislang im deutschsprachigen
Raum, bis auf das aus einer Dissertation heraus entstandene Buch von Schütte,
nicht erschienen. Schütte nähert sich dem Thema über die Systemmodellie-
rung und die Forderung nach einer »ordnungsgemäßen« Modellierung in Ana-
logie zur ordnungsgemäßen Buchführung. Darauf aufbauend wird ein Vorge-
hensmodell zur Erstellung und Anwendung von Referenzmodellen entworfen.
Singh, S., Data Warehousing, 1998, New Jersey
Das Buch versteht sich auf ca. 300 Seiten als schneller Themeneinstieg und Pla-
nungshilfe. Es bietet Entscheidungsalternativen und viele Praxisbeispiele für
den kundigen Kenner von Datenbanken und Client/Server-Architekturen.
Schmidt, G., Methoden und Techniken der Organisation, Schriftenreihe »Der
Organisator«, Band 1, 1983, Gießen
Ein sehr umfangreiches Werk zur Organisation ist die Schriftenreihe »Der
Organisator«, das aus mehr als zehn aufeinander abgestimmten Einzelbänden
zu jeweils ca. 300 Seiten besteht. Aus diesen zehn Bänden ist der erste eine Ein-
führung in die Praktik des Organisierens. Die Themen, die auf den ca. 330 Sei-
ten von Band 1 im Einzelnen detailliert werden, sind Organisationsanlässe,
Organisationsmethode und Vorgehensmodell, Erhebung, Aufgabenanalyse, Auf-
baudarstellung, Ablaufdarstellung, Techniken der kritischen Würdigung, Syn-
thesetechniken, Bewertung und Präsentation.
Schmidt, G., Grundlagen der Aufbauorganisation, Schriftenreihe »Der Orga-
nisator«, Band 5, 1989, Gießen
Auf ca. 290 Seiten werden zur Aufbauorganisation dargestellt: Grundbegriffe,
Ziele und Prinzipien, Stellen, Informationssystem, Kommunikationssystem,
Sachmittelsystem, Leitungssystem, Führungssystem und Methoden.
Siegmund G., Technik der Netze, 1999, Heidelberg
Ein mit 1050 Seiten umfangreiches, das Thema »Kommunikationsnetze« voll-
ständig abdeckendes Buch. Mit über 1000 Tabellen und Grafiken bewunderns-
wert sorgfältig ausgestattet und äußerst nützlich. Da sowohl die physikali-
schen, die physischen, wie auch die logischen Bezüge didaktisch gut dargestellt
sind, ist das Buch für den »Netzanfänger« geschrieben, EDV-Experte sollte er
aber sein.
674 Anhang B • Literaturverzeichnis
und eignet sich daher auch zum Selbststudium. Zu »Wöhe« gibt es einen
umfangreichen Arbeitsband.
Yourdon, E., Constantine L.L., Structured Design, Fundamentals of a Disci-
pline of Computer Programme and Systems Design, Englewood Cliffs, 1979
Ein mit ca. 480 Seiten sehr detailliertes, mit ausführlichen Beispielen und Dis-
kussion aller möglichen Fälle umfangreiches Buch einiger der einflussreichs-
ten Softwaremethodiker aller Zeiten. Ein Standardwerk von der Mitte der 70er,
bis tief in die 80er hinein, für die Programmierung kaufmännischer Pro-
gramme.
Zangemeister, C., Nutzwertanalyse in der Systemtechnik, 1970, Köln
Eine auf ca. 370 Seiten sehr ausführliche und wissenschaftlich abgeleitete Dar-
stellung einer Bewertungsmethode von Alternativen nach Nutzwerten. Eine als
Buch veröffentlichte Dissertation mit »viel Mathematik«, entsprechend unbe-
quem zu lesen.
B.8 Zeitschriften
Im Folgenden sind die im Text erwähnten Zeitschriften mit dem Namen und
Niederlassungsort ihres Verlags aufgelistet.
Verlag moderne Industrie AG
Instandhaltung
Landsberg
Heise Verlag
iX
Hannover
Heise Verlag
c't
Hannover
Herausgeber: Gesellschaft für Informatik e.V., Springer Verlag
Informatik Spektrum
Berlin, Heidelberg
Herausgeber: Fachbereich 2 Softwaretechnologie und Informationssysteme der
Gesellschaft für Informatik e.V., Springer Verlag
Informatik Forschung und Entwicklung
Berlin, Heidelberg
Verlag Vieweg
Wirtschaftsinformatik
Wiesbaden
Anhang B • Literaturverzeichnis 677
HMD, Praxis und Theorie der Wirtschaftsinformatik, Heft 195, Data Ware-
house, Mai 1997
Die DIN A5 großen, ca. 140 Seiten starken HMD-Hefte widmen sich in ihren
sechs Ausgaben pro Jahr in fünf bis acht Aufsätzen jeweils einem modernen
Schwerpunktthema. Dabei wird immer eine systematische Darstellung des The-
menkomplexes weiteren Theoriebeiträgen, die in Praxisberichten konkretisiert
werden, vorangestellt. In diesem Heft sind mehrere Ansätze zu Referenzmodel-
len interessant.
SOUG-Special, SOUG Newsletter, Data Warehouse, DWH, 1/2000
Die SOUG ist die sehr rührige Schweizer Oracle User-Group mit einem aufwen-
digen, regelmäßig erscheinenden, ca. 60 Seiten starken Newsletter. In unregel-
mäßiger Folge wird ein Special herausgegeben zu einem Thema, das gleichzei-
tig als Informationsveranstaltung organisiert wird. Das Special 1/2000 enthält
neben interessanten Beiträgen zu den Architekturen von SAS, SAP (lesenswert
für Entscheider und Projektleiter), eine ausführliche Darstellung der Themen
»Materialized Views«, »Aggregationsfunktionen« und »Dimensionen und Hier-
archien« am Beispiel Oracle8i (lesenswert für Programmierer).
Wirtschaftsinformatik, Heft 6, Dezember 1998, 40. Jahrgang, Wiesbaden
Das Heft hat zum Schwerpunktthema »Management-Support-Systeme«, unter
anderem mit folgenden ausführlichen (ca. 10 Seiten) Beiträgen:
✔ Die fachliche Konzeption von Führungsinformationssystemen
✔ Die grafische Notation für die semantische Modellierung multidimensiona-
ler Datenstrukturen
✔ Konzept zur Datenintegration für Management-Support-Systeme auf der
Basis uniformer Datenstrukturen
✔ Temporale Daten in Management-Support-Systemen
678 Anhang B • Literaturverzeichnis
B.10 DWH-Studien
Bloor Research Group, Data Warehouse Tools, leider von 1985, englisch
Ausführliche Darstellung des weltweiten Marktes der Data Mining Werkzeuge.
Der besondere Wert liegt in der kompetenten Darstellung der Architekturen der
Werkzeuge, in der Beschreibung der Hersteller mit Folgerungen aus Historie
für den Charakter und die Weiterentwicklung der Produkte. Alle Werkzeuge
werden einer detaillierten Funktionalitätsbetrachtung unterzogen, gefolgt von
einer Synopse aller Eigenschaften.
Bloor Research Group, EIS Tools in the Data Warehouse
Ergänzend zur Studie »Data Warehouse Tools«. Eine ausführliche Darstellung
der Produkte für Zugriff, Weiterverarbeitung und Reporting der Client-Seite.
Der besondere Wert liegt in der kompetenten Diskussion der Architekturen der
Werkzeuge und deren Konsequenzen. Die Hersteller werden auch ausführlich
analysiert, um Folgerungen für die Weiterentwicklung der Produkte zu ziehen.
Alle Werkzeuge werden einer detaillierten Funktionalitätsbetrachtung unterzo-
gen und bei fehlender Funktionalität die Nachteile für den Entwickler beurteilt.
Die behandelten Werkzeugkategorien sind Ad Hoc Query-Tools, EIS-Entwick-
lungsumgebungen, Modellierungs- und Analysetools und Spezialwerkzeuge.
Business Intelligence, The Olap Report, Succeding with On-Line Analytical
Processing, Volume 1, 1998, englisch
Dieser Report betrachtet OLAP-Anwendungen, Technologien und Produkte. Im
einzelnen werden behandelt: die OLAP Technologien in Bezug zu anderen IT-
Systemen, Design von OLAP-Modellen und Datenbanken, Antwortzeiten bei
OLAP-Systemen, Führen von OLAP-Projekten. Analysiert werden Produkte mit
abteilungsübergreifenden Funktionen.
Business Intelligence, The Olap Report, Succeeding with On-Line Analytical
Processing, Volume 2, 1998, englisch
Der Report hilft bei der Auswahl des passenden OLAP-Produkts. Er beinhaltet
die 25 häufigsten Anwenderanforderungen sowie maßgeschneiderte Produkte,
Verkaufsmerkmale und Preisvergleiche, deckt aber auch Stärken und Schwä-
chen eines jeden Produkts auf. Fallstudien führender Unternehmen berichten,
wie sie diese OLAP-Systeme einsetzen. Unter anderem werden die Themen Pro-
Anhang B • Literaturverzeichnis 679
B.11 Abbildungsverzeichnis
Abbildung 4.7: Raumvisualisierung
© by Winterheller Software GmbH, Graz
aus is report 1/2000 Seite 18, Abb. s19–20, Autor Prof Winterheller
Die Advanced Business Intelligence (ABI) ist das Kernstück der Controlling- und
Budgetierungssoftware Professional Planner‘ von WINTERHELLER software
Abbildung 4.10 Beispiel synoptischer Report, und Abbildung 4.11 Maske Ent-
scheidungsbaum
© by Software & Support Verlag GmbH, Frankfurt aus Der Entwickler 6/99,
s14, Abb. 4-7, Autor Grob, Bensberg
IBM, Intelligent Miner, www.software.ibm.com
Abbildung 4.12: Beispiel einer Portfoliomatrix, und Abbildung 4.13: Beispiel
Kumulationsdiagramm einer ABC-Analyse
© by redmond’s technologie publishing, Unterschleißheim aus Microsoft Office
Journal 6-97, Praxis: ABC-Analyse, Portfolioanalyse
Abbildung 5.12: Beispiel für PC-Racks mit zwei Gehäusen
© by Firma Hewlett Packard, aus HP-info 1999
Abbildung 5.15 T3E-1200E von Cray Research
© by Firma Cray Research
Produktankündigung 1999
Abbildung 5.14: Beispiel Minirechner: VAX 6000
und Abbildung 5.16: Aufrüstungsmöglichkeiten der VAX 6000/200
© by Firma Digital Equipment Corporation, heute Compaque, aus DEC-Pro-
duktkatalog, 1994 und DEC Kundenzeitschrift DEC-Blatt Jahrgang 1991
681
INDEX
In den Index sind nur die Seiten aufgenommen, auf denen die Begiffe definiert oder erklärt
oder in einen wichtigen Zusammenhang gestellt sind. Die Begriffe können auch an anderen
Stellen vorkommen, werden aber dort nicht erklärt.
! Anforderungsanalyse 38
3GL Programmeditor 195 Angebote 453
3GL-Toolsets 545 Animator 200
4GL Programmeditor 195 Anpassungsaufgaben 592
Anstoß 322
A Anwenderorientierung 32
Abbau 39, 317, 379, 614 Anwendungsleitfaden Nutzwertanalyse 565
Abbildungsmerkmal 364 Applikationsebene 247
Abbruchkriterien 518 A-Projekte 372
ABC-Analyse 198, 202 Arbeitskapazität 514
Ablaufdiagramm 349, 389 Arbeitsplatzrechner 256
Abläufe 329 Architektur 95, 96, 97
Ablauforganisation 347 Architektur-Zooming 99
Abnahme des Abbaus 622 Archivsystem 175
Abrechnung 463 ARIS 128
Abstandsmaß 204 Assistenten 167
ADAPT 426 Attribute 421
Administration DWH 617 Attributtyp 423, 424
Administration DWH-Entwicklungssysteme Aufbau 317
494 Aufgabenstellung 323
Administrationsfunktionen 198 Aufgabenträger 324, 513
Adressbuch 52 Aufrufbeziehungen 431
Agenten 171 Auftrag 453
Agents 600 Aufwand 485
Aggregat 97 Aufwandserfassungssheet 523
Aggregationen 426 Ausführungspflicht 464
Aggregationsdigramm 389 Ausgabegeräte 284
Aggregationsschema 426 ausschließliches Vorgehensmodell 384
Aggregator 172 Ausschreibung 453, 506
aktive Komponente 100, 236 Auswahlmaske für Suchkriterien 432
Aktivität 320, 389, 399
Aktivitätendauer 471 B
Aktivitäten-Verknüpfungen 468 Batchbetrieb 274
allgemeine Reportfunktionen 197 Baud 237
Alternativ-Terminpläne 469 Baugruppe 101
682 Index
Phasenergebnis 38 Projektinitiation 38
Plato 567 Projektinitiierung 452
Portfolioanalyse 56 Projektjahresbericht 505
Portfoliomatrix 200 Projektleiter 489
Pragmatikmerkmal 364 Projektleitung DWH-Abbau 616
Präsentationsmittel 480 Projektleitungssitzung 498
primäre Absicht 322 Projektleitungssitzung Abbau 620
Primärinformanten 533 Projektmanagement 81, 462
Primärleistung 462 Projektmanagementprogramme 476, 479
Print/Output-Management 603 Projektmentor 452
Problem-Management 606 Projektmisserfolg 69
Problemorientierung 32 Projektorganisation 326
Produktbeschreibung 50 Projektphase 37, 38, 450
Produktdatenmanagement 640 Projektplanung 372, 453
Produktdatenmanagementsystem 637 Projektplanungsergebnisse 454
Produktelisten 536 Projektprozesse 489
Produktgliederungssystematik 149 Projektrichtlinien 505, 511
Produktinformation 50 Projektrollen 317
Produktionsanlagen 314 Projektsachmittel 463, 476
Produktionsfaktor 46 Projektsoziologie 512
Produkttypen-Charakterisierung 36 Projektstatusbericht 505, 519
Produkttypen-Chart 34 Projektstruktur 37, 151
Produkttypisierung 34 Projektstrukturplan 458, 465
Produkttypus 31 Projektteam 489
Programmgenerator 195 Projektziel 74, 449
Programmierwerkzeuge 480 Protokolle 246
Programmkomponentenauswahl 432 Prototyping 389
Programmstartbild 432 Provider 235
Programmstrukturierung 434 Prozess 319, 329, 389
Projekt 37, 449 Ausbau und Verbesserung des DWH 345
Projektakquisition 452 Benutzerbetreuung und Aufrechterhal-
Projektantrag 452, 457, 506, 518 tung der Systemverfügbarkeit 346
Projektassistenz Abbau 616 Prozessauslöser 330
Projektaudit 513 Prozessbegrenzer 399
Projektberichtswesen 510, 517 Prozessdiagramm 389
Projektbeurteilung 521 Prozesselemente der Organisationssituation
Projektcontroller 521 332
Projektcontrolling 517 Prozessfragen 321
Projektdefinition 452 Prozess-Input 330
Projekteportfolio 372 Prozessmonitor 177
Projektfortschrittsskala 41 Prozess-Output 331
Projektgröße 463 Prozessrechner 262
Projekthandbuch 511 Prozesssteuerungsprogramm 214
Projektidee 451 Prozesssteuerungssysteme 215
Projektierung 38, 66, 372, 447, 449, 455 prozessuale Sicht 122
Index 691
Bei Fragen zu diesem Thema wenden Sie sich bitte an: info@pearson.de
Zusatzdaten
Möglicherweise liegt dem gedruckten Buch eine CD-ROM mit Zusatzdaten bei. Die
Zurverfügungstellung dieser Daten auf unseren Websites ist eine freiwillige Leistung
des Verlags. Der Rechtsweg ist ausgeschlossen.
Hinweis
Dieses und viele weitere eBooks können Sie rund um die Uhr
und legal auf unserer Website
http://www.informit.de
herunterladen