International Technical Support Organization IBM - IBM Redbooks

International Technical Support Organization
IBM Unternehmensberatung GmbH, Hamburg
Systems Management Design
Ein Überblick für Führungskräfte
Februar 1996
SG24-4687-00

IBML
International Technical Support Organization
IBM Unternehmensberatung GmbH, Hamburg
Systems Management Design
Ein Überblick für Führungskräfte
Februar 1996
SG24-4687-00

Hinweis
Bevor Sie die folgenden Produktinformationen benutzen, lesen Sie bitte die Hinweise im Abschnitt „Spezielle
Anmerkungen“ auf Seite xi.
Erste Ausgabe (Februar 1996)
Diese Ausgabe beschäftigt sich mit den Strategien und Techniken des Systems Management Design. Das Buch ist
ein Kompendium verschiedener ITSO Dokumente und wurde speziell für Führungskräfte entwickelt.
Diese Publikation kann über Ihren IBM Beauftragten oder Ihre zuständige IBM Niederlassung angefordert werden.
Das Dokument ist bei der unten angegebenen Adresse nicht vorrätig.
Anfragen oder Kommentare richten Sie bitte direkt an:
IBM Deutschland Entwicklung GmbH
International Technical Support Organization
Abt. 3222, Gebäude 71032-02
Postfach 1380
71032 Böblingen, Deutschland
An den eingesandten Kommentaren und Verbesserungsvorschlägen räumt der Einsender IBM ein einfaches
Nutzungs- und Verbreitungsrecht ein; eine Verpflichtung der IBM zu Nutzung und Verbreitung besteht nicht.
© Copyright International Business Machines Corporation 1996. Alle Rechte vorbehalten.

Zusammenfassung
Die strategische Ausrichtung der Informationsverarbeitung auf die Geschäftsziele
des Unternehmens wird immer wichtiger und häufig zu einem wesentlichen
Wettbewerbsfaktor. Innerhalb der Informationsverarbeitung spielt neben der
Anwendungsentwicklung und der Kommunikationsvernetzung das Systems
Management eine bedeutende Rolle.
Das ITSO hat dazu ein umfangreiches Dokument (Information Systems
Management - Design Guidelines and Strategy - A Practical Approach)
veröffentlicht, welches sich an Berater für Informationsverarbeitung, Designer
und Systemplaner wendet. Das vorliegende Dokument soll einen Überblick über
das Systems Management Design und die Methode geben, die dafür von der
IBM Unternehmensberatung GmbH in Deutschland und weltweit von der IBM
Consulting Group eingesetzt wird.
Dieses Dokument wendet sich vor allem an Führungskräfte im Bereich
Informationsverarbeitung. Untermauert werden die theoretischen Überlegungen
durch drei Referenzbeispiele aus der Praxis.
(81 Seiten)
© Copyright IBM Corp. 1996 iii

iv Systems Management Design - Ein Überblick

Vorwort
Die strategische Ausrichtung der Informationsverarbeitung auf die Geschäftsziele
des Unternehmens entwickelt sich immer mehr zu einem kritischen Erfolgsfaktor
im Wettbewerb. Das Systems Management (SM) verteilter unternehmensweiter
oder gar -übergreifender Hardware, Software, Daten und Funktionen wächst
dabei zu einem Thema heran, das enger mit den Geschäftsstrategien verbunden
werden muß. Dies ist aber nicht durch eine einmalige Aktion zu erledigen,
sondern wird aufgrund der kontinuierlichen Veränderungen im Markt und in der
Informationstechnologie (IT) selbst zur permanenten Aufgabe. Sie läßt sich nur
dadurch vereinfachen, daß eine kontinuierliche Weiterentwicklung von
vornherein als Kriterium für die IT-Infrastruktur vorgegeben wird - Design for
Change.
Vor diesem Hintergrund ist zu verstehen, daß dem Designvorgang für die
Infrastruktur und hier besonders für das Systems Management eine immer
stärkere Bedeutung zukommt.
Die IBM Consulting Group hat für das Design von SM-Lösungen eine bereits
vielfach in der Praxis erprobte Methode „System Management Framework Design
(SMFD)″ entwickelt. Dabei wird die SM-Architektur von den Geschäftszielen
abgeleitet, die Prozeßsicht ist der Projektauswahl übergeordnet. Dadurch ist
auch längerfristig ein weitreichender Investitionsschutz gegeben.
Häufig wird der Fehler gemacht, SM-Projekte mit der Auswahl von Produkten
und deren Installation zu beginnen, ehe ein Anforderungskatalog und ein
sorgfältiges Ablaufdesign erarbeitet wurden. Diese Vorgehensweise führt häufig
in die Sackgasse.
In dem vorliegenden Dokument sind drei Beispiele aus der Praxis beschrieben.
Sie unterstreichen die von der IBM Unternehmensberatung GmbH empfohlene
Vorgehensweise, zunächst die Prinzipien für den Design-Prozeß des Systems
Management aus den Geschäftszielen abzuleiten, dann das Design mit der
Methode SMDF systematisch zu erarbeiten und dessen Ergebnisse in
Implementierungsprojekten umzusetzen.
Dabei bietet sich die IBM Unternehmensberatung GmbH als Ihr kompetenter
Partner an, der die Methodik und die Erfahrung aus vielen erfolgreichen
Projekten mit in Ihre Aufgabenstellung einbringt.
Februar 1996
Joachim Langmack
IBM Unternehmensberatung GmbH
Hamburg und Ehningen
© Copyright IBM Corp. 1996 v

vi Systems Management Design - Ein Überblick

Inhaltsverzeichnis
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Spezielle Anmerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Angaben zum Aufbau dieses Dokuments . . . . . . . . . . . . . . . . . . . . . xiii
Veröffentlichungen zu diesem Thema . . . . . . . . . . . . . . . . . . . . . . . xiii
Veröffentlichungen der International Technical Support Organization . . . . xiv
Redbooks des ITSO im World Wide Web (WWW) . . . . . . . . . . . . . . . . . . xv
Das Projekt-Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Kapitel 1. Strategische Ausrichtung von Systems Management . . . . . . . . . 1
1.1 Systems Management ist kein Selbstzweck, sondern muß sich an den
Geschäftszielen orientieren • . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Systems Management - Diener zweier Herren: Zur Effizienzsteigerung in
der Zentrale und zum Nutzen der Benutzer (Eine Definition) . . . . . . . . . 4
1.3 Systems Management Design - Nichts dem Zufall überlassen
(Notwendigkeit für strukturiertes Vorgehen) . . . . . . . . . . . . . . . . . . . . 6
1.4 Systems Management Framework Design: Eine Methode liefert
umsetzbare Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Orientierung des Designs am IT-Prozeß-Modell . . . . . . . . . . . . . . . 12
1.6 Systems Management Design erhält seinen Wert erst durch die
Implementierung (SM-Projekte) . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.7 Der Design-Prozeß: Wie geht man vor? . . . . . . . . . . . . . . . . . . . . 17
Kapitel 2. Design Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 Design Beispiel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1 Einführung in die Kundensituation . . . . . . . . . . . . . . . . . . . . . 19
2.1.2 SM-Umgebung und ihre Anforderungen . . . . . . . . . . . . . . . . . . 20
2.1.3 Auswahl der SM-Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.4 Duchführung des Designs . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.5 Designergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.6 Gegenwärtiger Status und Ausblick auf die Zukunft . . . . . . . . . . 27
2.2 Design Beispiel 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1 Einführung in die Kundensituation . . . . . . . . . . . . . . . . . . . . . 28
2.2.2 Die zu verwaltende Umgebung und ihre Eigenschaften . . . . . . . . 29
2.2.3 Auswahl der SM-Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.4 Durchführung des Designs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.5 Designergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.6 Gegenwärtiger Status und Ausblick auf die Zukunft . . . . . . . . . . 32
2.3 Design Beispiel 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.1 Einführung in die Kundensituation . . . . . . . . . . . . . . . . . . . . . 33
2.3.2 Durchführung des Designs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.3 Die Implementierungs-Phase . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3.4 Erfahrungen und Probleme . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.3.5 Gegenwärtiger Status und Ausblick auf die Zukunft . . . . . . . . . . 41
Kapitel 3. Was Führungskräfte über Systems Management Design wissen
sollten! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
© Copyright IBM Corp. 1996 vii

viii Systems Management Design - Ein Überblick
3.1 SMFD-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Phase 1 - Grundprinzipien und Richtlinien . . . . . . . . . . . . . . . . . . . 44
3.3 Phase 2 - Funktionen und Dienstleister . . . . . . . . . . . . . . . . . . . . . 46
3.4 Phase 3 - Komponenten-Management . . . . . . . . . . . . . . . . . . . . . 47
3.5 Phase 4 - Framework-Definition . . . . . . . . . . . . . . . . . . . . . . . . . 48
Kapitel 4. Wie können Führungskräfte das Systems Management Design
beeinflussen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 Allgemeine Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Kategorien von SM-Prinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Kapitel 5. SM-Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1 Umfang und Detailbehandlung der SM-Umgebung . . . . . . . . . . . . . . 55
5.2 Definition von Elementgruppen mit gleichen Management-Eigenschaften 57
5.3 Management-Eigenschaften der Elemente . . . . . . . . . . . . . . . . . . . 60
Kapitel 6. Systems Management-Prozesse . . . . . . . . . . . . . . . . . . . . . 65
6.1 Prozeßorientierung oder Ressourcenorientierung . . . . . . . . . . . . . . 65
6.2 Auswahl der SM-Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3 Bewertung der bereits existierenden Prozesse . . . . . . . . . . . . . . . . 66
6.4 Prozeßprioritäten bei der Implementierung . . . . . . . . . . . . . . . . . . 67
6.4.1 Analyse basierend auf der Beziehung zu Management-Eigenschaften 68
6.4.2 Analyse des Zieles eines SM-Prozesses . . . . . . . . . . . . . . . . . 68
6.4.3 Analyse des Nutzens einer Anwendung . . . . . . . . . . . . . . . . . . 68
6.4.4 Analyse der wechselseitigen Abhängigkeiten zwischen Prozessen . 68
6.4.5 Analyse basierend auf der Durchführbarkeit eines Prozesses . . . . 70
6.4.6 Analyse auf der Grundlage eines konkreten Falles . . . . . . . . . . . 70
Kapitel 7. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.1 Geschäftliche Strategien und Anwendungen . . . . . . . . . . . . . . . . . 71
7.2 IT-Strategien und -Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . 74
7.3 Auswirkungen auf das Systems Management Design . . . . . . . . . . . . 76
Abkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Abbildungsverzeichnis
1. Abstimmung zwischen Geschäfts- und IT-Strategien . . . . . . . . . . . . 2
2. Die Welt des Systems Management . . . . . . . . . . . . . . . . . . . . . . 6
3. Systems Management und IBM Open Blueprint . . . . . . . . . . . . . . . 7
4. Beispiel für SM-Projektkosten . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Die acht Prozeßgruppen des IT-Prozeß-Modells . . . . . . . . . . . . . . . 13
6. SM-Projektstufen und IBM „Servicekette″ . . . . . . . . . . . . . . . . . . 16
7. LIT - SM-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. LIT - Ergebnisse der Umfrage zu Prozeßprioritäten . . . . . . . . . . . . . 22
9. LIT - Prozeßdefinition der Änderungsverwaltung . . . . . . . . . . . . . . 25
10. LIT - Aufgaben-Beschreibungen in Management-Domänen für die
Änderungsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. OFD Hannover - Vorhandene IT-Infrastruktur . . . . . . . . . . . . . . . . 33
12. OFD Hannover - Geplante Infrastruktur . . . . . . . . . . . . . . . . . . . . 34
13. Die zwölf SM-Prozeßgruppen der OFD . . . . . . . . . . . . . . . . . . . . 36
14. OFD Hannover - Beispiel für Prozeß/Element-Matrix und Interviewbogen 37
15. OFD Hannover - Eine konsolidierte Matrix . . . . . . . . . . . . . . . . . . 38
16. OFD Hannover - Systems Management Support Organisation . . . . . . 39
17. OFD Hannover - Systems Management Infrastruktur: Topologie . . . . . 40
18. Die SMFD-Konzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
19. Die erste Phase eines Systems Management Design-Projektes . . . . . 45
20. Matrix Elemente/Prozesse - Anforderungen an Funktionen und
Dienstleister . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
21. Erweiterte Matrix Elemente/Prozesse zur Definition von
Lösungs-„Domains″ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
22. Definition von Prinzipien für Systems Management als
Management-Aufgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
23. Notwendigkeit einer klaren Definition der Management-Umgebung . . . 56
24. Elementgruppen aus unterschiedlichen Blickwinkeln . . . . . . . . . . . . 58
25. Management-Eigenschaften bestimmen die SM-Anforderungen . . . . . 60
26. Prozeßorientiertes Systems Management . . . . . . . . . . . . . . . . . . 65
27. Analyse der Abhängigkeiten zwischen SM-Prozessen . . . . . . . . . . . 69
© Copyright IBM Corp. 1996 ix

x Systems Management Design - Ein Überblick

Spezielle Anmerkungen
Diese Publikation soll dem IS-Management einen Überblick über Systems
Management Design und den damit verbundenen Problemen geben. Die hierin
enthaltenen Informationen sind nicht als Spezifikation von Programmschnittstellen
für gegebenenfalls erwähnte Produkte zu werten. Eine Liste der
offiziellen Produktdokumentationen kann im Teil „Publications″ der
entsprechenden Programmankündigung gefunden werden.
Hinweise auf IBM Produkte, Programme bzw. Dienstleistungen in dieser
Publikation bedeuten nicht notwendigerweise, daß diese von IBM auch in allen
Ländern angeboten werden. Ebenso bedeutet ein solcher Hinweis nicht, daß nur
Produkte der IBM (einschließlich Programmen und Dienstleistungen) verwendet
werden können. Jedes funktional gleichwertige Produkt, das keine IBM Rechte
verletzt, kann statt dessen verwendet werden.
Alle Informationen in dieser Publikation wurden in Verbindung mit den jeweils
aufgeführten Hard- bzw. Software-Produkten ermittelt; ihre Anwendbarkeit
basiert auf dieser spezifizierten Umgebung.
Zu Themen, welche in dieser Publikation behandelt werden, besitzt die IBM
gegebenenfalls Patente bzw. sind Patentanträge anhängig; Lizenzansprüche auf
irgendwelche Patente können aufgrund dieser Veröffentlichung nicht abgeleitet
werden. Anfragen bezüglich Lizenzen können schriftlich an folgende Adresse
gerichtet werden: IBM Director of Licensing, IBM Corporation, 500 Columbus
Avenue, Thornwood, NY 10594, USA.
Die in dieser Publikation enthaltenen Informationen unterlagen keiner formellen
technischen Prüfung durch die IBM und werden auf dieser Basis weitergegeben;
sie sind nicht Bestandteil der Programm-Spezifikationen. Die IBM übernimmt
keine Verantwortung für deren Richtig- bzw. Vollständigkeit. Die Verwendung
dieser Informationen bzw. die Implementierung beschriebener Techniken liegt in
der Verantwortung des Kunden und erfordert dessen Fähigkeit, deren Einsatz für
eine gegebene Situation zu beurteilen und entsprechend anzuwenden.
Einzelkomponenten mögen durch die IBM für spezielle Situationen geprüft
worden sein; daraus läßt sich jedoch keine identische Funktionalität in anderen
Umgebungen ableiten. Kunden, die obige Techniken auf ihre eigene Umgebung
anpassen, tun dies auf eigene Verantwortung.
Informationen zu nicht-IBM Produkten (Vendor-Produkte) in diesem Dokument
basieren auf den vom jeweiligen Anbieter zur Verfügung gestellten
Informationen.
© Copyright IBM Corp. 1996 xi

xii Systems Management Design - Ein Überblick
Die folgenden Begriffe sind Warenzeichen der International Business Machines
Corporation in den Vereinigten Staaten und/oder anderen Ländern:
AIX AIX/6000
AS/400 IBM
MVS Open Blueprint
OS/2 RS/6000
S/390 System/390
SystemView WebExplorer
Die folgenden Begriffe sind Warenzeichen anderer Gesellschaften:
DOS Microsoft Corporation
Excel Microsoft Corporation
HP Hewlett-Packard Company
Intel Intel Corporation
PC Direct Ziff Communications Company (used by
IBM Corporation under license)
UNIX X/Open Company Ltd. (registered
trademark)
X/Open X/Open Company Ltd.
Windows Microsoft Corporation
Andere Warenzeichen sind Warenzeichen ihrer entsprechenden Gesellschaften.

Einführung
Angaben zum Aufbau dieses Dokuments
Die Kapitel 1 bis 4 wenden sich an das Management der
Informationsverarbeitung. Diese Kapitel bieten einen Überblick über den
Systems Management Design-Prozeß und enthalten Beispiele aus der Praxis.
• Kapitel 1, „Strategische Ausrichtung von Systems Management“ beschäftigt
sich mit der strategischen Ausrichtung von Systems Management auf das
jeweilige Unternehmen.
• In Kapitel 2, „Design Beispiele“ werden Beispiele aus der Praxis
beschrieben.
• Kapitel 3, „Was Führungskräfte über Systems Management Design wissen
sollten!“ gibt einen Überblick über die Methode des Systems Management
Framework Design (SMFD), die von der IBM Unternehmensberatung GmbH
in Deutschland und weltweit von der IBM Consulting Group eingesetzt wird.
• In Kapitel 4, „Wie können Führungskräfte das Systems Management Design
beeinflussen?“ wird erörtert, wie Manager auf das Systems Management
Design Einfluß nehmen können.
• Kapitel 5, „SM-Umgebung“ und Kapitel 6, „Systems Management-Prozesse“
befassen sich eingehender mit der Management-Umgebung und den zu ihr
gehörenden Elementen, sowie mit den entsprechenden SM-Prozessen, die
auf diese Elemente anzuwenden sind.
• Gegenstand von Kapitel 7, „Ausblick“ sind technologische und
wirtschaftliche Trends, welche Einfluß auf das Management von
Informationssystemen haben.
Für einen kurzen Überblick wird die Lektüre der Kapitel 1 bis 4 und 7 empfohlen.
Veröffentlichungen zu diesem Thema
Die im folgenden Abschnitt aufgeführten Veröffentlichungen werden als
besonders geeignet erachtet, um die Kenntnisse zu den in diesem Dokument
behandelten Themen zu vertiefen.
• Transforming the enterprise: The alignment of business and information
technology strategies (J.N. Luftman, P.R. Lewis, S.H. Oldach, IBM Systems
Journal Vol. 32, No. 1/93)
• A Management System for the Information Business, Volume 1 - Management
Overview, IBM Form GE20-0662
• A Management System for the Information Business, Volume 2 - The
Information Systems Service Mission, IBM Form GE20-0749
• A Management System for the Information Business, Volume 3 - The
Information Systems Development Mission, IBM Form GE20-0750
• A Management System for the Information Business, Volume 4 - Managing
Information Systems Resources, IBM Form GE20-0751
• Open Blueprint: Technical Overview, IBM Form GC23-3808
• IBM Security Architecture - A Model for Securing Information Systems
(Broschüre), IBM Form SC28-8135
© Copyright IBM Corp. 1996 xiii

• IBM Security Architecture - A Model for Securing Information Systems
(Prospekt), IBM Form G221-3528
Veröffentlichungen der International Technical Support Organization
xiv Systems Management Design - Ein Überblick
• The Library for Systems Solutions, SM Reference, Introduction to Managing
Open Systems, IBM Form GG24-4113
• The Library for Systems Solutions, SM Reference for Managed System/390,
IBM Form GG24-4114
• The Library for Systems Solutions, SM Reference for Managed AIX/6000
Systems, IBM Form GG24-4115
• The Library for Systems Solutions, SM Reference for Managed Personal
Systems, IBM Form GG24-4116
• The Library for Systems Solutions, SM Reference for Managed AS/400
Systems, IBM Form GG24-4117
• Disaster Recovery Library Design Concepts, IBM Form GG24-4211
Eine vollständige Liste der als „Redbooks″ bekannten Veröffentlichungen der
International Technical Support Organization, zusammen mit einer
Kurzbeschreibung der einzelnen Werke, ist zu finden in:
International Technical Support Organization Bibliography of Redbooks, IBM
Form GG24-3070
Um einen Katalog der Redbooks des ITSO zu erhalten, können VNET-Benutzer
folgendes eingeben:
TOOLS SENDTO WTSCPOK TOOLS REDBOOKS GET REDBOOKS CATALOG
Eine Auflistung aller, nach einzelnen Kategorien sortierter Redbooks ist auch in
MKTTOOLS unter ITSOPUB LISTALLX zu finden. Dieses Paket wird einmal im
Monat aktualisiert.
Wie Sie Redbooks des ITSO bestellen können
IBM Mitarbeiter in den U.S.A. können ITSO-Bücher und CD-ROMs mit
PUBORDER bestellen. Kunden in den U.S.A. können unter der
Telefonnummer 1-800-879-2755 oder der Faxnummer 1-800-445-9269 bestellen.
Visa und Master Card werden akzeptiert. Außerhalb der U.S.A. können sich
Kunden an ihre örtliche IBM Niederlassung wenden.
Kunden können gedruckte ITSO-Bücher einzeln bestellen oder in individuell
zusammengestellten Sätzen (sogenannten GBOFs), die sich auf die
Funktionen beziehen, die im einzelnen Fall jeweils von Interesse sind. IBM
Kunden und Mitarbeiter können ITSO-Bücher auch als CD-ROM-Sammlungen
bestellen, die Redbooks zu einer Vielzahl von Produkten enthalten.

Redbooks des ITSO im World Wide Web (WWW)
Das Projekt-Team
Internet-Benutzer finden Informationen zu Redbooks auf der ITSO World Wide
Web-Hauptseite. Um auf die ITSO Web-Seiten zuzugreifen, richten Sie Ihren Web
Browser (z.B. WebExplorer aus dem OS/2 3.0 Warp BonusPak) auf folgende
Zeile:
http://www.redbooks.ibm.com/redbooks
Auch IBM Mitarbeiter haben Zugriff auf LIST3820s zu den Redbooks. Richten Sie
Ihren Web Browser auf die IBM Redbooks-Hauptseite:
http://w3.itsc.pok.ibm.com/redbooks/redbooks.html
Verantwortlich für das Projekt-Design und -Management:
Varoozh Harikian
International Technical Support Organization, Raleigh Center
Die Autoren:
Brian Blust
IBM Consulting Group
Mike Campbell
IBM Deutschland
Ralph Foley
IBM Canada
Gisbert Krüsemann
IBM Deutschland
Gernot Wichmann
IBM Deutschland
Janos Wieland
IBM Deutschland
Dank für Rat und Unterstützung an:
Hubertus Eggen
IBM Deutschland
John Helmbock
IBM Consulting Group
sowie den drei Kunden, die in diesem Buch ihr Beispiel als Referenz zur
Verfügung stellten.
Einführung xv

xvi Systems Management Design - Ein Überblick

Kapitel 1. Strategische Ausrichtung von Systems Management
Dieses Kapitel gibt eine Einführung, warum Systems Management (SM) heute
eine äußerst wichtige Aufgabe in einem sich stark wandelnden Umfeld der
Unternehmen ist. Es wird aufgezeigt, warum ein strukturierter Ansatz für das
Design der SM-Infrastruktur so wichtig ist.
Der wirkungsvolle Einsatz von Informationsverarbeitung wird sehr stark durch
Systems Management bestimmt. Die Flexibilität der Informationsverarbeitung in
ihrer Anpassung an geschäftliche Veränderungen, die Produktivität der Benutzer,
die Verfügbarkeit der notwendigen Services der
Informationstechnologie (IT) - um nur einige Beispiele zu nennen - werden
sehr stark durch effizientes Systems Management bestimmt.
Das vorliegende Kapitel stellt die Beziehungen zwischen Geschäftsstrategie,
IT-Strategie, Organisations-Infrastruktur und IT-Infrastruktur dar. Es wird auf das
Management der IT-Infrastruktur eingegangen, Systems Management definiert,
sowie die Notwendigkeit für das Design von Systems Management begründet. In
einem kurzen Überblick über die IBM Designmethode für System Management
(SMFD) wird auf die Ergebnisse, die diese Methode liefert, eingegangen. Ein
wesentliches Merkmal dieser Methode besteht darin, daß sie ein Design liefert,
welches in der Praxis implementierbar ist. Daher wird der Aspekt der
Umsetzung in der Praxis im Abschnitt 1.6 besonders betrachtet. Dieses Kapitel
dient gleichzeitig als Einführung in die Gesamtthematik der Bedeutung von
Systems Management für die Unternehmen und in die dafür eingesetzte
Designmethode.
Dieses Kapitel ist auch als Überblick für das Management von
Informationssystemen (IS) in den Unternehmen gedacht.
1.1 Systems Management ist kein Selbstzweck, sondern muß sich an den
Geschäftszielen orientieren •
Die strategische Ausrichtung der Informationsverarbeitung auf die Geschäftsziele
des Unternehmens wird verstärkt zu einem kritischen Erfolgsfaktor.
Wettbewerbsfähig im Markt kann ein Unternehmen nur dann sein und bleiben,
wenn es seine Abläufe strikt an Kunden und Geschäftszielen ausrichtet,
wertorientiert strukturiert und organisiert. Die sich dabei ergebenden Prozesse
müssen optimal durch Informationstechnologie unterstützt werden.
Dies ist keine einmalige Aktion, sondern wegen der kontinuierlichen
Veränderungen im Markt und der mit hohem Tempo fortschreitenden nutzbaren
Informationstechnik eine permanente Aufgabe. Diese Aufgabe wird dadurch
vereinfacht, daß der Entwurf von Anfang an auf eine kontinuierliche
Weiterentwicklung ausgerichtet wird („Design for Change″).
1 Dieses Kapitel gibt Aussagen wieder aus: „Transforming the enterprise: The alignment of business and information technology
strategies″ (J.N.Luftman, P.R. Lewis, S.H. Oldach - IBM Systems Journal Vol. 32, No. 1/93)
© Copyright IBM Corp. 1996 1

Abbildung 1. Abstimmung zwischen Geschäfts- und IT-Strategien
2 Systems Management Design - Ein Überblick
Vier Felder sind Grundlage für die strategische Ausrichtung und stehen in
Beziehung zueinander:
Mit starkem externen Einfluß sind dies das Geschäftsfeld, in dem sich das
Unternehmen bewegt und die Informationstechnik, die hilft, Geschäftsfelder zu
erschließen und auszudehnen. Organisation/Administration und IT-Infrastruktur
sind die internen Gestaltungsbereiche.
Eine strategische Anpassung muß zwischen externen und internen Faktoren
erfolgen, eine funktionale Integration zwischen Organisations- und
IT-Infrastruktur (= Operationale Integration). Die Geschwindigkeit und
Kontinuität dieser Anpassung differenziert den Wettbewerb.
Aufgrund der in der Graphik dargestellten Felder (Geschäftsstrategie,
IT-Strategie, Organisations-Infrastruktur, IT-Infrastruktur) gibt es vier Modelle für
jeweils unterschiedliche strategische Perspektiven:
• IT-Strategie als Wettbewerbsfaktor (Competitive Potential)
In diesem Modell steht die IT-Strategie mit dem Einsatz neuer Technologien
im Vordergrund und beeinflußt oder schafft neue Geschäftsfelder. Das
bedeutet für das Management des Unternehmens, Informationsverarbeitung
kreativ und innovativ zu nutzen. Beispiel: Kreditkarteninhabern werden
erweiterte Services angeboten wie Mietwagen- plus Hotelbuchung.
• IT-Strategie als kritischer Erfolgsfaktor für die Umsetzung der Geschäftsziele
(Technology potential)
Hier geht es darum, definierte Geschäftsziele optimal mit der
Informationstechnologie zu unterstützen. So kann z.B. im

Versicherungsbereich das Ziel „time to market″ durch optimale
Software-Verteilung neuester Versicherungsanwendungen auf den
Agentenarbeitsplatz erreicht werden. Dies ist also ein „Top down″-Ansatz,
ausgehend von der Geschäftstrategie.
• IT-Strategie als „Service-Lieferant″ im Unternehmen (Service level)
Bei diesem Modell steht die Fähigkeit des Bereiches
Informationsverarbeitung im Vordergrund, optimale IS-Services an die
Benutzer im Unternehmen auszuliefern. Reaktionsgeschwindigkeit und
Produktivität der Benutzer haben einen hohen Stellenwert. Daher sind hier
z.B. Maßnahmen zur Verfügbarkeit der Services oder zur
Benutzerunterstützung von großer Bedeutung.
• Nutzung der IT-Infrastruktur zur Umsetzung der Geschäftsziele (Strategy
execution)
Dies ist das zur Zeit das am meisten in der Praxis eingesetzte Modell,
ebenfalls ein „Top down″-Ansatz. Die Geschäftsziele sind vorgegeben und
damit der „Treiber″ für die Organisations- und IT-Infrastruktur, die von der
Geschäftsstrategie ausgehend bestmöglich zu gestalten sind. Damit entsteht
ein Rahmenwerk für die Unternehmensorganisation und die IT-Infrastruktur,
in dem unternehmensweite Projekte umgesetzt werden. Hier spielt die
IT-Strategie weniger eine innovative als vielmehr eine „unterstützende″
Rolle.
Diese Modelle setzen jeweils unterschiedliche Gewichte für die Nutzung der
IT-Infrastruktur im Unternehmen. Daher muß jedes Unternehmen entscheiden,
welches Modell im konkreten Fall das Geeignete ist. Alle Modelle haben aber
gemeinsam, daß die strategisch an die Geschäftsziele ausgerichtete
IT-Infrastruktur ein entscheidender Erfolgsfaktor für das Unternehmen ist.
Die internen Umsetzungsschwierigkeiten hinsichtlich der IT-Infrastruktur mit
ihren wesentlichen Komponenten wie Anwendungsentwicklungsumgebung,
Kommunikationsvernetzung oder Systems Management werden häufig
unterschätzt.
Besonders dramatisch haben sich die Anforderungen an das Systems
Management in den letzten Jahren erweitert. Durch die verteilte Verarbeitung ist
ein großer Bedarf entstanden, alle Benutzer, den erfahrenen und „ermächtigten″
sowie den technisch nicht interessierten, in Systemangelegenheiten zu
unterstützen. Es gilt also, eine Systemunterstützung bereitzustellen, die
Veränderungen in Abläufen, Organisation und Anwendungen auf einfache Weise
erlaubt, und dem Benutzer stets ohne Einschränkung und unnötigen Aufwand
unterstützt.
Damit wird das Design der SM-Umgebung entscheidend dafür, was
Informationsverarbeitung in einem Unternehmen zu leisten vermag.
Kapitel 1. Strategische Ausrichtung von Systems Management 3

1.2 Systems Management - Diener zweier Herren: Zur Effizienzsteigerung in
der Zentrale und zum Nutzen der Benutzer (Eine Definition)
Die Aufgabenstellung von Information Systems Management innerhalb der
IT-Infrastruktur hat sich mit der Entwicklung der Informationsverarbeitung
evolutionär verändert. Stand in den 70er- und 80er-Jahren die zentrale
Informationsverarbeitung mit großen Datenbanken, auf die mit nicht-intelligenten
Endgeräten zugegriffen wurde, im Vordergrund, so sind die 90er-Jahre durch
Client/Server-Anwendungen geprägt.
Aufgabe von Systems Management war daher in der Vergangenheit, mit
höchster Priorität die Verfügbarkeit der zentralen Systeme sicherzustellen ( die
Benutzer waren von diesen total abhängig) und höchste Automation der
IS-Abläufe zu erreichen.
Typische Aufgabenfelder für Systems Management waren:
• Verfügbarkeit
• System-Automation
• Optimierung von Batchabläufen
• Vorsorgemaßnahmen für Notfälle
• Informationssicherung
• Problem- und Change-Management
•
Systems Management diente in erster Linie der Effizienzsteigerung in der
Zentrale.
Ein Paradigmenwechsel von Systems Management vollzog sich mit dem Einsatz
von intelligenten Workstations, den PCs. Diese erfordern eine Ausrichtung von
Systems Management auf den Benutzer. Disziplinen wie:
• Softwareverteilung
• Benutzerunterstützung
• Lizenzverwaltung
• LAN- und Netzmanagement
• Druckservice
•
entscheiden nun darüber, wie produktiv ein Benutzer seine Aufgaben bewältigen
kann. Heute orientiert sich das Systems Management in erster Linie am Nutzen
für den Benutzer, ohne jedoch auf die Effizienz der Zentrale zu verzichten.
Systems Management ist daher Diener zweier Herren.
Definition
4 Systems Management Design - Ein Überblick
Systems Management besteht aus einer Reihe von Prozessen, welche dafür
sorgen, daß geeignete IS-Services dem Benutzer und der Zentrale zur Verfügung
stehen. Diese Prozesse übernehmen Aufgaben wie Definieren, Lösen und
Managen von Problemen, Betreiben von Netzwerken und heterogenen
Systemen, Verteilen und Managen von Software und Daten, Steuern des
Betriebes vom Endgerät bis zum zentralen Rechner, Planen und Steuern der
Performance, Verwalten der Bestandsdaten und Planen der zukünftigen
Kapazität von Systemen.

Komponenten der im allgemeinen heterogenen IS-Umgebungen, auf die
SM-Prozesse angewandt werden, sind:
• Zentrale Systeme
• Abteilungsrechner
• PCs und Workstations
• Speichermedien, sowie
• Protokolle und Komponenten von LANs, WANs oder öffentlichen Netzwerken.
SM-Prozesse beantworten Fragen wie:
• Wie werden Client/Server-Anwendungen unterstützt?
• Welche IT-Ressourcen sind beim Benutzer installiert und wo?
• Wie wird neue Software installiert?
• Wie werden Probleme auf der Benutzerseite gelöst?
• Sind Backup-Prozeduren installiert, um die Wiederherstellung von
Anwendungen und Daten nach einem Systemausfall zu gewährleisten?
• Welche Sicherheitsmaßnahmen sind für Systeme und Daten im Einsatz?
• Welche Benutzerunterstützung ist vorhanden?
Viele Unternehmen haben bereits in der Vergangenheit stark in SM-Projekte,
insbesondere im Bereich des Rechenzentrums, investiert. Damit wurden z.B.
Rechnerverfügbarkeiten zwischen 99% und 100% erreicht.
Die Komplexität der verteilten Verarbeitung aber wurde gemeinhin unterschätzt.
Erst jetzt wird bemerkt, wie wichtig Systems Management in einer
Client/Server-Umgebung ist, und welche Kosten damit verbunden sind.
Viele Analysen von Beratungsunternehmen zeigen in die gleiche Richtung.
• Gartner Group: Nur 17% der gesamten Kosten für Workstations/PCs über
fünf Jahre hinweg sind der Hard- und Software zuzurechnen, 83% sind
Personalkosten. Wenn dafür nicht geeignete Managementverfahren
eingesetzt werden, werden sich die Kosten bis 1997 verdreifachen.
• Nolan und Norton Studie: PC-Benutzer verbringen bis zu 50% ihrer Zeit
damit, anderen zu helfen.
• Forrester Research, Inc.: Fünf Hauptgebiete bedürfen einer schnellen
Lösung:
1. Bestandsmanagement
2. Softwareverteilung
3. Performance-Überwachung und -Verbesserung
4. PC/Client Problemunterstützung, und
5. Backup/Wiederherstellung von Daten und Programmen.
Daraus resultiert die Notwendigkeit einer effektiven IT-Strategie, um die
SM-Prozesse sowohl für die Zentrale als auch für die Benutzer so zu
implementieren, daß
• Kosten reduziert werden,
• die Produktivität der Benutzer gesteigert wird, und
• neue Geschäftsfelder für das Unternehmen erschlossen werden können.
Kapitel 1. Strategische Ausrichtung von Systems Management 5

Abbildung 2. Die Welt des Systems Management
1.3 Systems Management Design - Nichts dem Zufall überlassen
(Notwendigkeit für strukturiertes Vorgehen)
Es wurde bereits aufgezeigt, wie sich die Informationsverarbeitung und damit
auch das Systems Management von zentralen zu verteilten Strukturen verändert
hat. Um diese Veränderungen zu beherrschen bedarf es einer speziellen
Architektur.
Diese muß sich daran orientieren, den Einsatz von Informationstechnologie
optimal zu unterstützen. Eine SM-Architektur muß daher die folgenden Kriterien
beachten:
• Kostengünstige Implementierung und kostengünstiger Betrieb
• Unterstützung von unterschiedlichen Implementierungs-Szenarien
• Einfache Handhabung
• Integration über alle Systemplattformen
• Investitionsschutz
6 Systems Management Design - Ein Überblick
• Offen für neue Technologien und Standards
IBM hat nun mit „SystemView″ und „Open Blueprint″ Rahmenwerke geschaffen,
die diese Kriterien erfüllen.

Die SystemView-Struktur
Die meisten Kundenumgebungen werden heute nicht nur durch einen einzigen
Lieferanten bestimmt. Dem Bedarf an Integration und Interoperabilität kommt
daher entscheidende Bedeutung zu. Das Management einer derart heterogenen
Umgebung erfordert daher die Einführung gewisser Ordnungsprinzipien. Daß
diese Anforderungen allgemein anerkannt werden, ist klar zu erkennen und
äußert sich in einer steigenden Nachfrage nach Interoperabilität; diese wird
durch offene, lieferantenneutrale Standards erreicht.
Das Management heterogener Umgebungen erfordert die SystemView-Struktur,
um einerseits bereits existierende Management-Protokolle, wie z.B. Simple
Network Management Protocol (SNMP), andererseits neue Technologien, wie
verteilte Anwendungen in objektorientierter Programmierung basierend auf
Object Management Group (OMG) und X/Open Systems Management Services
(XSMS) zu unterstützen.
Die strategische Ausrichtung von SystemView für Open Blueprint basiert auf
einer verteilten, objektorientierten Technologie und wird mit wachsender Reife
dieser Technologie in die Abläufe einbezogen werden. Objektorientierte
Verfahren sind sehr gut für SM-Anwendungen geeignet, da die Geschäftslogik
und die dazugehörigen Daten in den Objekten enthalten sind. Objektorientiertes
Design wurde im Rahmen von SNMP und CMIP extensiv genutzt; voll verteilbare,
objektorientierte Anwendungen sind jedoch relativ neu. Die SystemView-Struktur
muß sowohl prozedurale als auch objektorientierte Anwendungen
berücksichtigen, um heterogene Umgebungen des Kunden unterstützen zu
können.
Abbildung 3. Systems Management und IBM Open Blueprint
Kapitel 1. Strategische Ausrichtung von Systems Management 7

Elemente der SystemView-Struktur
8 Systems Management Design - Ein Überblick
Viele Kunden und Lieferanten sind mit den SystemView-Prinzipien (Automation,
Integration und Offenheit) sowie den Konzepten von Endbenutzer-, Anwendungsund
Datendimension vertraut.
• Integrierte „Presentation Services″ (Endbenutzerdimension EUD)
Die Endbenutzerschnittstelle für SystemView ist unter Nutzung der Open
Blueprint Benutzerschnittstellen des Presentation Managers von OS/2 oder
OSF/Motif implementiert. Hinzugefügt werden noch objektorientierte
Verbesserungen zur Graphik- und Multimediaunterstützung.
• Integrierte Multivendor-Lösungen (Anwendungsdimension)
Lösungen für integrierte Multivendor-Anwendungen werden durch offene
Schnittstellen ermöglicht, die gemäß der Definition durch Blueprint
Ressourcenmanager sowohl prozedural, als auch objektorientiert sein
können. SystemView unterstützt die Integration von Anwendungen aus der
Perspektive konsistenter Benutzerinteraktionen, gemeinsamer
Management-Funktionen und gemeinsamer Management-Informationen.
Prozeßabläufe, entsprechend den Geschäftsprozessen, nutzen „Workflow″
Ressourcenmanager, um den Personalbedarf bei der Bereitstellung
integrierter SM-Lösungen weiter zu reduzieren.
IBM hat SM-Funktionen in sechs verschiedenen Disziplinen definiert. Diese
sind:
1. Business Management
2. Change Management
3. Configuration Management
4. Operations Management
5. Performance Management, und
6. Problem Management
• Gemeinsames Objektdatenmodell (Datendimension)
Mit einem gemeinsamen Objektdatenmodell für die Ressourcen können alle
SM-Anwendungen auf eine einzige Darstellung der Ressourcen zugreifen,
wodurch die Integration gefördert und die Anzahl unerwünschter
Mehrfach-Speicherungen verringert wird.
SystemView-Datenobjekte werden gegenwärtig gemäß der Richtlinien für die
Definition verwalteter Objekte (GDMO Standard) modelliert. IBM weitet seine
gemeinsamen Modellierungsaktivitäten aus, um dem Open Blueprint Object
Services Standard (basierend auf OMG IDL) gerecht zu werden, und zwar
sowohl für Anwendungsobjekte, als auch für Objekte der „Managed
Resources″.
• Heterogene „Managed Resources″
Durch Agenten werden „Managed Systems″ in die Lage versetzt, entweder
lokale oder entfernte Management-Funktionen auszuführen. „Managed
Resources″ versorgen den Agenten mit Informationen, der seinerseits diese
Informationen dem „Managing System″ zur Verfügung stellt.
Soweit einige grundsätzliche Betrachtungen zu der SystemView-Struktur und
dem Open Blueprint. Architekturen geben die Richtung an für
kundenindividuelles Design und bilden damit die Basis für die nachfolgende
Umsetzung in einer konkreten Umgebung.

Abbildung 4. Beispiel für SM-Projektkosten
Je komplexer nun die Umgebung ist, desto notwendiger ist eine strukturierte
Vorgehensweise zum Design von SM-Lösungen. Schnell geschaffene
Insellösungen blockieren häufig eine notwendige spätere Integration. Produkte
decken selten bereits in ihren ersten Versionen alle Anforderungen ab.
So wie man ein Haus nicht ohne einen Bauplan baut, so sollte man auch
SM-Lösungen nicht ohne strukturiertes Design implementieren. Zu oft haben
sogenannte „Praktiker″ SM-Projekte aufgesetzt, die sich später als
Einbahnstraßen oder gar „Investitionsleichen″ herausgestellt haben. Der Druck
aktueller Problemstellungen führt oft zu voreiligen Implementierungen. In jeden
Fall muß daher zunächst ein Anforderungskatalog oder Pflichtenheft erstellt
werden. Daran schließt sich das strukturierte Design bis hin zur Produktauswahl
an. Das Design orientiert sich an einigen grundsätzlichen Vorgaben, wie
Erhaltung und Ausbau der Flexibilität der Geschäftsprozesse, Begrenzung des
Risikos, leichte Handhabbarkeit von Lösungen oder Teillösungen,
Herstellerunabhängigkeit, Verbindung „Any to Any″, jederzeit umfassender
Zugriff zu Daten, und so weiter.
Auf den Design-Prozeß wird noch in einem der nachfolgenden Abschnitte
eingegangen. An dieser Stelle wurde die Notwendigkeit für ein strukturiertes
Vorgehen begründet. Die Kosten des Design-Prozesses in SM-Projekten liegen
zwischen 3% bis 8% der Gesamtprojektkosten, die laufende Design-Anpassung
ungefähr zwischen 2% und 4% der Betriebskosten. Dies spiegelt sich auch in
dem nachfolgenden Beispiel eines konkreten Projektes wieder:
Kapitel 1. Strategische Ausrichtung von Systems Management 9

Die Zeitdauer für das Design hängt ebenfalls von der Komplexität der Lösung ab.
Erfahrungswerte liegen zwischen zwei bis sechs Monaten.
Fazit: Das Design von SM-Lösungen darf nicht dem Zufall überlassen bleiben.
Strukturiertes Vorgehen ist unbedingt notwendig. Zeit- und Kostenrahmen
sind im Verhältnis zum Nutzen und zum Gesamtprojekt eher als gering
einzustufen.
1.4 Systems Management Framework Design: Eine Methode liefert umsetzbare
Ergebnisse
In seiner Positionierung ist Systems Management Design (SMD) angesiedelt
zwischen Architekturdefinition einerseits und konkreter Implementierung
anderseits, also zwischen einem allgemeingültigen, längerfristig angelegtem
Rahmenwerk und seiner konkreten, auf die heutige Situation angepaßten
Umsetzung.
Aus dieser Positionierung ergibt sich, daß die konkreten Designergebnisse den
Nutzen einer jeden Designmethode bestimmen müssen. Die IBM setzt für diese
Aufgabe die von der IBM Consulting Group entwickelte und in der Praxis
erprobte Methode „Systems Management Framework Design (SMFD)″ ein. Mit
dieser Methode werden die Detailkenntnisse der Untersuchung auf einer
höheren Ebene zusammengefaßt. Prozeßschritte mit gleichartigen
Management-Funktionen und Service-Anforderungen werden zu
Prozeß-„Domains″ gruppiert und Lösungs-„Domains″ gebildet, die mit gleichen
Werkzeugen bedient werden können. Daraus entsteht das Design der
IT-Infrastruktur.
Die Ergebnisse im Einzelnen sind:
SM-Modell und -Organisationsstruktur
10 Systems Management Design - Ein Überblick
Wir unterscheiden hier zwischen vier Topologie-Modellen: zentrales Systems
Management, verteiltes Systems Management, LAN-Management und
unternehmensweites, hierarchisches Systems Management.
Beispiel für eine unternehmensweite, hierarchische Topologie auf zwei Ebenen:
in diesem Beispiel wurde festgelegt, daß die Zentrale z.B. verantwortlich ist für
Konfigurations- und Change-Management, für Bestands-Management mit
Leistungsverrechnung und Sicherheits-Management. Zentral unterstützt werden
Problemverfolgung und „End-to-End″Performance. Lokale
Management-Funktionen werden geographisch vor Ort plaziert und sind in
diesem Beispiel Benutzerunterstützung, Operations Management und Teile des
Problem Managements.
In der Organisationsstruktur wurde festgelegt, daß in der Zentrale ein
SM-Kontrollzentrum eingerichtet wird und Systemadministratoren dezentral
plaziert werden. In der zentralen Funktion wird das Fachwissen konzentriert,
liegt die Verantwortung für die Erfüllung der Service Level Vereinbarungen, und
erfolgt die Lizenzkontrolle und Software-Verteilung. Die Zentrale etabliert auch
Schnittstellen zu Service-Anbietern außerhalb des Unternehmens.
Die lokalen Administratoren benötigen in diesem Beispiel nur IT-Basiswissen.
Sie sind in erster Linie zuständig für Durchführung von Backup- und

Recovery-Funktionen, die Problemerfassung vor Ort und eine erste
Benutzerunterstützung.
Service-Pakete
Im Systems Management Design werden auch die anzubietenden Service-Pakete
definiert. Das können z.B. sein: LAN-Monitoring, Performanceüberwachung,
HOST- und WAN-Management, oder Management der administrativen Topologie.
SM-Prozesse
Das Design liefert hier die Prioritäten und die Beschreibungen der Prozesse,
sowie die Festlegung der Prozeß-Verantwortlichkeiten. Wer sind die
Service-Anbieter, wer die Empfänger? Wie sieht das Mengengerüst aus (z.B. 30
Probleme pro Tag, 200 Anrufe in der Benutzerunterstützung pro Tag usw.)?
Design-Spezifikationen
Hier geht es um Festlegung der Plattformen mit Definition der Anforderungen an
Funktionalität, Leistungsdaten, Standards und zukünftigen Anforderungen.
Produktanforderungen mit Funktionalität und Leistungskriterien werden
beschrieben, Interfaces zwischen Produktion und anderen Anwendungen werden
festgelegt.
Topologie-Diagramm je Prozessorgruppe
Im Design werden Topologie-Diagramme je Prozessorgruppe erarbeitet, z.B. für
die Netzwerksteuerung oder die Software-Verteilung.
Service Level Vereinbarungen
Service Level Vereinbarungen bilden die Vereinbarung des IS-Bereiches nach
außen, z.B. zu den Fachbereichen. Im Einzelnen werden beschrieben:
• Kundenservice (z.B. Service-Zeiten, Service-Umfang)
• Service-Leistungsrahmen (z.B. Systemverfügbarkeit, Änderungsdienst,
Software-Pakete)
• Betriebsstandards (z.B. anwendungsbezogene Vereinbarungen)
• Vorsorge im Katastrophenfall.
Implementierungsplan
Hier geht es darum, das Design in konkrete SM-Projekte zu überführen. Dazu ist
es erforderlich, eine genaue Positionierung der Projekte und deren
Projektorganisation festzulegen. Des weiteren liefert der Implementierungsplan
eine Zeitplanung und Projektaufwände für Personal, Ausbildung und Produkte.
Aufwandschätzung für den Betrieb
Für die Umsetzung von SM-Projekten ist es wichtig, die laufenden
Betriebskosten von vornherein zu kennen. Daher werden die Hardware-,
Software, Wartungs- und Personalkosten je Service untersucht.
Kapitel 1. Strategische Ausrichtung von Systems Management 11

Zusammenfassung
Mit Hilfe der SMFD-Methode wird die IT-Infrastruktur entwickelt, in deren
Rahmen sich die SM-Projekte bewegen. Die SM-Architektur wird von den
Geschäftszielen abgeleitet, die Prozeßsicht ist der Produktauswahl übergeordnet.
Dadurch ist - auch längerfristig - ein Investitionsschutz gegeben. Es entsteht ein
Anforderungskatalog, mit dem nun am Markt verfügbare Produkte
bedarfsgerecht ausgewählt werden können.
1.5 Orientierung des Designs am IT-Prozeß-Modell
Seit jeher legt IBM großen Wert auf Prozeßorientierung um ein effizientes
Systems Management zu erreichen. Das führte in den 80er Jahren zur Definition
der „Informations System Management Architektur (ISMA)″ und zu Beginn der
90er Jahre zur Festlegung der SystemView-Disziplinen.
Diese Arbeiten wurden evolutionär weiterentwickelt und finden ihren
Niederschlag heute in dem „IT-Prozeß-Modell (ITPM)″.
Das IT-Prozeß-Modell stellt eine umfassende Prozeßbeschreibung für alle
wichtigen IT-Prozesse zur Verfügung. Abb. 5 auf Seite 13 zeigt die acht acht
Prozeßgruppen dieses Modells.
• IT-Management als Beitrag zum Geschäftserfolg (Manage IT Business Value)
• Informationstechnologie zur Befriedigung von Kundenbedürfnissen (Satisfy
Customer Relationships)
12 Systems Management Design - Ein Überblick
• Umsetzen von Lösungen (Realize Solutions)
• Einsetzen und Erschließen von Lösungen Deploy Solutions)
• Bereitstellen von operationalen Diensten (Deliver Operational Services)
• Management von IT-Inventar und -Infrastruktur (Manage IT Assets and
Infrastructure)
• Unterstützung von IS-Services und -Lösungen (Support IT Services and
Solutions)
• Definition eines unternehmensweiten IT-Management-Systems. (Provide
Enterprise IT Management System)

Abbildung 5. Die acht Prozeßgruppen des IT-Prozeß-Modells
Die dabei verfolgten wichtigsten Ziele sind:
Kundenorientierung
Der Hauptfokus liegt auf dem Kunden. Es muß sichergestellt werden, daß der
IT-Einsatz zum Geschäftserfolg beiträgt und hohe Kundenzufriedenheit erlangt
wird. Wie gut diese Zielsetzung erreicht wird, differenziert die Unternehmen.
Umsetzen von Lösungen umfaßt die notwendigen Aktivitäten, um Hardware,
Software, Prozesse und Daten entsprechend den Kundenanforderungen
zusammenzuführen. Für diese Prozeßgruppe ist die Anwendungsentwicklung
besonders wichtig.
Alle Aktionen zur „Umsetzung von Lösungen″ stehen auf dem Prüfstand der
Kundenakzeptanz. Andere Prozeßgruppen zu diesem Ziel sind Einsetzen und
Erschließen von Lösungen und Bereitstellung von operationalen Diensten.
.Laufende Unterstützung des Service
Viele „traditionelle″ SM-Aktivitäten (z.B. Performance- oder
Konfigurationsmanagement) zählen zu diesem Bereich.
Ein zentrales Management-Rahmenwerk
Hier wird die Beziehung zwischen ITPM und SMFD deutlich. Das
IT-Prozeß-Modell bildet eine hervorragende Basis für die Prozeß-Analyse,
welche selbst Teil von SMFD ist. SMFD nutzt die Prozeß-Beschreibungen für
Design, Entwicklung und Betrieb der IT-Infrastruktur, die sich aus ITPM ergeben.
Kapitel 1. Strategische Ausrichtung von Systems Management 13

In der folgenden Tabelle wird gezeigt, wo im IT-Prozeß-Modell einige wichtige
SM-Bereiche angesprochen werden.
Tabelle 1. Beziehung zwischen SM-Aufgabe und IT-Prozeßgruppe
Gestellte Aufgabe Zugehörige Prozeßgruppe
Application Development Realize Solutions
Asset Management Manage IT Assets and Infrastructure
Availability Management Support IT Service and Solutions
Backup Management Support IT Service and Solutions
Business Recovery Support IT Service and Solutions
Capacity Management Support IT Service and Solutions
Change Management Deploy Solutions
Configuration Management Support IT Service and Solutions
Contract Management (Supplier) Manage IT Assets and Infrastructure
Contract Management (Customer) Manage IT Assets and Infrastructure
Disaster Recovery Support IT Service and Solutions
Facilities Management Support IT Service and Solutions
Help Desk Satisfy Customer Relationships
Inventory Management Manage IT Assets and Infrastructure
Operations Management Deliver Operational Services
Performance Management Support IT Services and Solutions
Pricing Manage IT Assets and Infrastructure
Problem Management Support IT Services and Solutions
Procurement Manage IT Assets and Infrastructure
Recovery Management Support IT Service and Solutions
Security Management Manage IT Assets and Infrastructure
Service Level Management Satisfy Customer Relationshps
Software Distribution Deploy Solutions
Supplier Management Manage IT Assets and Infrastructure
Die IBM Unternehmensberatung GmbH nutzt das IT-Prozeß-Modell, um
Management-Prozesse zu planen und zu entwerfen. Die IBM Berater verfügen
über weitergehende Detailbeschreibungen und entsprechende Werkzeuge und
Hilfsmittel. Dabei sind die aufgezeigten 8 Prozeßgruppen in dem
IT-Prozeß-Modell auf 41 Prozesse und 176 Subprozesse verfeinert.
Das IT-Prozeß-Modell hat sich bereits in der Praxis bei
Geschäfts-Prozeß-Modellierungen, bei Outsourcing-Aufträgen und bei der
Umsetzung von Client/Server-Lösungen bewährt.
1.6 Systems Management Design erhält seinen Wert erst durch die
Implementierung (SM-Projekte)
14 Systems Management Design - Ein Überblick
In Kapitel 2, „Design Beispiele“ auf Seite 19 werden einige konkrete Projekte,
bei denen SMFD erfolgreich eingesetzt wurde, näher beschrieben. Dies sind:

LIT Landesamt für Informationstechnik der Stadt Berlin. Hier wurde ein
komplettes Systems Management Design für die gesamte
Informationsverarbeitung der Stadt Berlin mit einem sehr
heterogenen UNIX-Umfeld und z.Zt. über 10.000 Workstations
durchgeführt.
Unternehmen der Telekommunikation in USA Das zweite Kundenbeispiel betrifft
ein Unternehmen für Telekommunikation in den USA. Die
Herausforderung bei diesem Kunden bestand darin, die stark zentral
orientierte Informationsverarbeitung (6 große S/390 Rechenzentren)
auf ein verteiltes Umfeld mit mehr als 5.000 UNIX-Servern und über
40.000 PCs in mehr als 1.000 Lokationen vorzubereiten. Mit SMFD
sollten die IT-Prozesse, Organisation, Datenhaltung und Werkzeuge
für ein verteiltes Client/Server-Umfeld modelliert werden.
Finanzbehörde in Deutschland Die Oberfinanzdirektion Hannover (OFD) ist
zuständig für die Planung und den Betrieb des DV-Netzes der
niedersächsischen Finanzverwaltungen. Sie versorgt rund 9.000
Mitarbeiter in 68 Finanzämtern mit Hardware, Software und
Anwendungen zur Automation der steuerfachlichen und
organisatorischen Verfahrensabläufe. Dazu betreibt die OFD seit
langem ein verteiltes DV-Netz auf der Basis von zentralen
IBM-Systemen und SNI 8860-Abteilungssystemen mit
Bildschirmarbeitsplätzen in jedem Finanzamt. Dieses Konzept mußte
auf die neuen, erweiterten Anforderungen umgestellt werden. Es
wurde eine offene, auf Standards basierende Client/Server-
Infrastruktur mit 350 UNIX-Servern unter AIX und 9.000 Intel-PCs
aufgebaut. Damit mußte auch das Design für das Systems
Management dieser Infrastruktur neu entwickelt werden.
Hier soll auf diese Beispiele nicht näher eingegangen sondern auf das
nachfolgende Kapitel verwiesen werden. Eines aber zeigen diese Beispiele sehr
deutlich: Erfolgreich sein kann nur, wer ein geeignetes Projektmanagement
einsetzt.
Eine Umfrage unter 150 IS-Managern (Computerworld March 20, 1995, Seite 81)
zeigt, daß nur wenige Projekte im vorgegebenen Zeit- und Kostenrahmen
abgewickelt wurden:
• 50% der untersuchten Projekte überzogen die Kosten bis 190% und deckten
weniger als 70% der geforderten Funktionalität ab.
• 25% der Projekte scheiterten, weil sich die Zielsetzung verändert hatte.
• 25% waren erfolgreich. Kosten- und Zeitrahmen wurden eingehalten,
Kundenerwartungen wurden befriedigt.
Alice LaPlante (Computerworld March 20, 1995, Seite 81 ff.) beschreibt die sieben
Grundregeln für erfolgreiches Projektmanagement, die auch für SM-Projekte
gelten.
1. Solange die Kunden oder Benutzer an der Definition des
Anforderungskatalogs beteiligt sind, ist gewährleistet, daß ein Design
entsteht, welches die Auftraggeber abnehmen und einsetzen werden.
2. Die Zielsetzung eines Projektes muß klar definiert sein.
3. Jede Abweichung von der ursprünglichen Zielsetzung ist ein Zeichen dafür,
daß das Projekt aus der Kontrolle gerät.
Kapitel 1. Strategische Ausrichtung von Systems Management 15

16 Systems Management Design - Ein Überblick
4. Die Hauptaufgabe eines Review Board ist es, neue Anforderungen außerhalb
der Zielsetzung des ursprünglichen Projektes zu managen.
5. Regelmäßige Information an das Senior Management stellt sicher, daß es
das Projekt versteht und unterstützt.
6. Zeit- und Kostenplan müssen fortgeschrieben werden. Es besteht jedoch
keine Notwendigkeit, das Management zu früh bei potentiellen
Abweichungen zu warnen.
7. Je umfangreicher ein Projekt ist, desto mehr Probleme werden auftreten.
Fazit: Das beste Systems Management Design kann nicht umgesetzt werden,
wenn nicht ein geeignetes und zielgerichtetes Projektmanagement
vorhanden ist. Dazu gehört ein Auftraggeber im entsprechenden
Management Level des Unternehmens sowie ein Review Board, welches
regelmäßig die Fortschritte des Projektes kontrolliert.
Neben dem geeigneten Projektmanagement sollte in der Implementierungsphase
eine Architekturbegleitung von dem für das Design verantwortlichen Fachmann
gegeben sein. Nur damit ist die Durchgängigkeit vom Design bis zur
Implementierung gewährleistet.
Die IBM hat daher eine „Servicekette″ definiert, um sicherzustellen, daß alle
Phasen eines Projektes ihren Stellenwert im Gesamtzusammenspiel finden.
Abbildung 6. SM-Projektstufen und IBM „Servicekette″
Diese „Servicekette″ zeigt sehr deutlich, daß das Design erst seinen Wert durch
die Implementierung und schließlich durch die Nutzung und den Betrieb erhält.

1.7 Der Design-Prozeß: Wie geht man vor?
In diesem Abschnitt soll kurz darauf eingegangen werden, wie der
Design-Prozeß strukturiert ist und wie sich daraus der Aufbau der nachfolgenden
Kapitel ergibt.
Dieses Dokument besteht aus zwei Teilen:
Teil 1
Der erste Teil wendet sich an den Leser, der einen Überblick gewinnen will, z.B.
Führungskräfte in der IT-Organisation des Unternehmens, aber auch Architekten,
Designer und Berater.
Neben dieser Einführung enthält der Teil 1 die Beschreibung der
Design-Methode in Kapitel 3, „Was Führungskräfte über Systems Management
Design wissen sollten!“, Referenzbeispiele in Kapitel 2, „Design Beispiele“,
sowie Hinweise über die Rolle der Führungskräfte und ihre Einflußmöglichkeiten
auf den Design-Prozeß in Kapitel 4, „Wie können Führungskräfte das Systems
Management Design beeinflussen?“ und einen Ausblick über in der Zukunft sich
abzeichnende Veränderungen in Kapitel 7, „Ausblick“.
Einige Bemerkungen noch zu diesem Kapitel: der Nutzen von Systems
Management Design ergibt sich erst durch die Umsetzung des Designs in der
Praxis. Daher sind in diesem Buch drei konkrete Beispiele beschrieben. In
diesen und vielen anderen hat sich SMFD als Methode bewährt.
Informationstechnologien aber auch das geschäftliche Umfeld sind ständigen
Änderungen unterworfen. Systems Management Design muß daher so ausgelegt
sein, daß es flexibel auf diese Veränderungen reagieren kann. Dazu ist Näheres
in Kapitel 7, „Ausblick“ nachzulesen.
Teil 2
Dieser Teil geht an einigen Stellen mehr in die Tiefe und wendet sich daher
mehr an Experten, wie Designer, Architekten und Berater.
Kapitel 5, „SM-Umgebung“ gibt eine Beschreibung über die „Managed
Elements″ (HW-Komponenten, SW, usw.) und zeigt, wie diese in Gruppen mit
ähnlichen Ausprägungen als Input für das Design zusammengefaßt werden
können.
Kapitel 6, „Systems Management-Prozesse“ gibt einen Überblick über die
SM-Prozesse („Business-, Change-, Configuration-, Operation-, Performance-,
Problem-Management″). Die Fragestellung ist, welche Prozesse müssen in der
konkreten Situation verbessert werden, um die Anwendungen, aber auch
notwendige Systemveränderungen optimal zu unterstützen.
Kapitel 1. Strategische Ausrichtung von Systems Management 17

Abschließende Anmerkungen
18 Systems Management Design - Ein Überblick
Diese Einführung (Kapitel 1, „Strategische Ausrichtung von Systems
Management“) soll abgeschlossen werden mit der Frage:Welche Verantwortung
hat das IT-Management in diesem Design-Prozeß?
Das IT-Management ist der Sponsor für das Design-Projekt. Es definiert die Ziele
und ist Teil eines Review Boards, welches regelmäßig den Projektfortschritt
verfolgt und bei Abweichungen von den Zielen Entscheidungen trifft. Das
Management ist außerdem verantwortlich für die Zuordnung von Experten und
Ressourcen für das SMFD-Projekt. Wegen der Neutralität, der Erfahrung im
Einsatz der Methode und dem Vorteil, weniger „betriebsblind″ zu sein, sollten
externe Berater bei einem solchen Projekt hinzugezogen werden.

Kapitel 2. Design Beispiele
2.1 Design Beispiel 1
Das erste Beispiel beschreibt das Systems Management Design (SMD) für die
Informationsverarbeitung der Stadtverwaltungen im Land Berlin. Diese Aufgabe
wurde im Herbst 1993 von dem Landesamt für Informationstechnik (LIT) der Stadt
Berlin an die IBM vergeben.
Ziel der Berliner Stadtverwaltung ist es, durch verstärkten Einsatz von
Informationstechnologie (IT) die Verwaltungsaufgaben effektiver und bürgernäher
zu gestalten. Rahmenbedingungen dabei sind die Abkehr von proprietären
Lösungen und die Orientierung an offenen Systemen, d.h. Einsatz von
dezentralisierten, UNIX-basierenden Rechnersystemen. Allerdings sind in den
einzelnen Stadtverwaltungen und Behörden qualitativ und quantitativ die
Voraussetzungen für die Betreuung der UNIX-Systeme in der Regel nicht
gegeben. Daraus resultiert die Überlegung, daß es wirtschaftlicher sein kann,
eine zentrale Systembetreuung aufzubauen, die über ein Berliner
Verwaltungsnetz (MAN = Metropolitan Area Network = flächendeckendes
Glasfasernetz im Land Berlin) auf die dezentralen Systeme zugreifen und diese
so verwalten kann.
Im Rahmen des Systems Management Framework Designs (SMFD) entstand
dabei die Definition der Aufgaben des Systems Management (SM), die zentral
von einem Service- und Administrationszentrum (SAZ) bereitzustellen sind.
Diese Zentrale stellt damit die allgemeine Infrastruktur zum Betrieb der
verteilten Systeme in den Außenlokationen zur Verfügung. Dabei werden die
dezentral - an verschiedenen Berliner Behördenstandorten - installierten
Rechnersysteme und -netze durch zentrale Administrations-, Support- und
Management-Funktionen unterstützt. Da in einer solchen Umgebung nicht alle
Dienste zentral angeboten werden können, wird ein gemischtes
zentrales/dezentrales Modell angestrebt.
Zentral führt eine Zusammenfassung von gleichartigen Funktionen zu
Einsparungs- und Synergie-Effekten, z.B. durch bessere Automatisierbarkeit
aufgrund höheren Arbeitsvolumens. Anderseits können dezentral kleinere,
überschaubare Einheiten eine wesentlich höhere Flexibilität bieten.
Daraus ergibt sich die Aufgabe, das Systems Management Design für ein
heterogenes Client/Server-Umfeld zu gestalten. Wichtiges Kriterium dabei ist, die
sofortige Umsetzung im Auge zu behalten.
2.1.1 Einführung in die Kundensituation
Die Regierung (der Senat) des Landes Berlin steht durch die Wiedervereinigung
und durch die Zielsetzung, bis zum Jahr 2000 wieder deutscher Regierungssitz
zu werden, vor großen Herausforderungen in sehr vielen öffentlichen Bereichen.
Das gilt ganz besonders für die Verwaltung und die Informationsverarbeitung.
Dabei hat das Land Berlin die Vision einer modernen Stadtverwaltung, die
aufgrund einer herausragenden Infrastruktur neue Industrien, Kulturzentren und
unterschiedlichste Institutionen anzieht. Ein Baustein dieser Infrastruktur ist z.B.
das Metropolitan Area Network (MAN).
© Copyright IBM Corp. 1996 19

Die Informationsverarbeitung ist wesentlicher Erfolgsfaktor bei der Ausrichtung
des Landes Berlin auf die Zukunft. Die Verwaltung soll bürgernah und effektiv
gestaltet werden, die Informationsverarbeitung muß daran wesentlichen Anteil
haben.
Bereits im einleitenden Abschnitt wurde auf die Herausforderungen der
Informationsverarbeitung im Land Berlin eingegangen. In Berlin ist die
Einführung einer Reihe von großen Fachverfahren geplant. Beispielhaft seien
genannt das „Automatisierte Haushaltswesen (AHW)″, die „Integrierte
Personalverwaltung (IPV)″, das „Fachübergreifende Informationssystem (FIS)″
bei der Senatsverwaltung für Stadtentwicklung und Umweltschutz sowie das
„Berliner Automatisierte Sozialhilfeverfahren (BASIS)″.
Die entstehenden Systeme müssen sich in eine allgemeine Infrastruktur
einordnen und auf einer zukunftssicheren Technologie beruhen.
Das Land Berlin gab im Februar 1993 an die „Frauenhofer Einrichtung für
Software- und Systemtechnik″ (FHG) eine Studie in Auftrag. Die Aufgabe der
Studie war die Analyse der Anforderungen an ein zukünftiges Konzept für die
Informationsverarbeitung im Land Berlin (MINZE-Studie).
Auf Basis dieser Studie erfolgte eine Ausschreibung für Design und Realisierung
dieses Konzepts. IBM gewann die Ausschreibung. Phase 1 des Gesamtprojektes
SA2/LA2 war das Design der IT-Infrastruktur, welches von der IBM
Unternehmensberatung GmbH gemeinsam mit dem IBM Open System Center
Nord durchgeführt wurde.
Die Infrastruktur sollte für mehr als 100 Verwaltungslokationen mit heute ca.
10.000 Datenstationen ausgelegt werden, die jedoch im Jahr 2000 auf über 50.000
Datenstationen anwachsen. Die Systemplattformen sind unterschiedliche
UNIX-Systeme. Dabei wurde folgender Zeitrahmen vorgegeben:
Mai 1994 Start des Projektes
November 1994 Start der Produktion in Pilotlokationen
1995/96 Aufnahme der Produktion in allen Lokationen
2.1.2 SM-Umgebung und ihre Anforderungen
20 Systems Management Design - Ein Überblick
In der Einleitung wurde bereits hervorgehoben, daß sich das LIT Berlin aufgrund
eines Senatsbeschlusses für offene, UNIX-basierende Systeme entschieden
hatte.

Abbildung 7. LIT - SM-Struktur
Als günstigste Lösung ergibt sich eine Verteilung der
Systemverwaltungs-Aufgaben zwischen einer Zentrale (SAZ) mit drei
hochverfügbaren RS/6000-Systemen unter AIX, die globale Aufgaben abdecken
und standortspezifischen Administrationen (LAZ = Lokales
Administrationszentrum), die im wesentlichen das Massengeschäft und den First
Level Support durchführen. Lokal ist jeweils ein System RS/6000 unter AIX als
SM-Server im Einsatz. Endgeräte sind:
• ASCII-Datenstationen (V.24-Anschluß)
• Datenstationen unter UNIX (HP/UX 9.0, SINIX 5.4, IRIX 4.0, SOLARIS 2.3,
OSF/1)
• PCs unter MS-DOS, Windows 3.1, OS/2
• Drucker/Plotter
2.1.3 Auswahl der SM-Prozesse
Auf der Netzseite sind ISDN, LAN, MAN im Einsatz mit Repeatern, Bridges,
Routern, Kopplern und Transceivern.
In diesem Netz müssen die Service-Rechner, Endgeräte und das Netz selbst
gesteuert und verwaltet werden. Die dazu ausgewählten SM-Prozesse werden
im nachfolgenden Abschnitt beschrieben.
Die SM-Anforderungen für das LIT wurden durch Analyse der drei wichtigsten
geschäftlichen Anwendungen, sowie durch Befragung der Repräsentanten der
Benutzergruppe zu den Prioritäten der erforderlichen Funktionen bestimmt. Die
Ergebnisse dieser Arbeitsschritte werden in Abb. 8 auf Seite 22 dargestellt.
Kapitel 2. Design Beispiele 21

Abbildung 8. LIT - Ergebnisse der Umfrage zu Prozeßprioritäten
Die aufgeführten Management-Aufgaben stimmen nicht exakt mit den durch ISO
oder IBM SystemView definierten SM-Disziplinen überein. Die gewählten Termini
wurden benutzt, da sie für die Benutzergruppe anschaulicher und verständlicher
waren.
Aufgrund der begrenzten vorhandenen Ressourcen war es nicht möglich, bereits
während des ersten Schrittes des Projektes alle Aufgaben zu implementieren.
Auf der Grundlage der Prioritätenliste definierte das Projekt-Team die fünf
SM-Prozesse, mit denen begonnen werden sollte:
• Sicherheitsverwaltung, Benutzererkennung und Zugriffssteuerung
Die meisten Daten zu Anwendungsprozessen sind personenbezogen. Das
deutsche Recht stellt hohe Anforderungen an die Sicherheitskontrolle für
Systeme, in denen derartige Daten verarbeitet werden.
• Configuration Management
22 Systems Management Design - Ein Überblick
Bestandteile eines zentralisierten Configuration Managements sind der
Aufbau eines Konfigurationsdatenbestandes in der Zentrale und die
kontrollierte Verteilung dieser Konfigurationsdaten. Die extrem verteilte
Umgebung erfordert automatisierte Lösungen für das Configuration
Management unter besonderer Berücksichtigung der Verteilung von
Änderungen.

• Verteilung von Software und Daten
Es wurde eine transparente Verteilung von Daten, Anwendungen und
Systemsoftware von der Zentrale auf Server und Arbeitsplatzrechner
gefordert. Die meisten Anwendungen können der Gruppe der selbst
erstellten Anwendungen zugeordnet werden. Der Bildung von
Anwendungspaketen kam daher entscheidende Bedeutung zu.
• Ressourcenverwaltung
Die sehr verteilte und heterogene Umgebung erfordert zentralisierte
Verwaltungsressourcen, um die Verfügbarkeit der vielfältigen Netz- und
Systemelemente zu gewährleisten.
• Problem Management
2.1.4 Duchführung des Designs
Der Mangel an SM-Kenntnissen vor Ort macht die Einrichtung einer
effektiven Fehlerbehandlung unverzichtbar. Die wichtigsten in diesem
Zusammenhang zu nennenden Anforderungen sind die automatische
Entdeckung nicht korrekt arbeitender Funktionen und die Fehlerbehebung.
Die anderen sechs Disziplinen wurden dem zweiten Arbeitsschritt zugeordnet,
der ebenfalls bereits abgeschlossen ist. Diese Disziplinen sind:
• Allgemeine Verwaltungsfunktionen
• Verfügbarkeits-Management
• Kapazitäts-Management
• Bestands-Management
• Erstellung von Sicherungskopien
• Wiederherstellung von Daten
Die Gesamtleitung des Projektes lag in den Händen einer Management-Gruppe,
die eingerichtet wurde, um Client/Server-Anwendungen und ähnliche Projekte zu
steuern. Diese Gruppe ist in Abständen von etwa drei Monaten
zusammengetroffen, und hatte Entscheidungen zu wichtigen Themen und
finanziellen Aspekten der Projekte, wie z.B. dem Infrastruktur-Design zu treffen.
Das Projekt „SA2/LA2″ folgte den Arbeitsschritten der SMFD-Designmethode, mit
der Ausnahme, daß Phase 2 und Phase 3 gemeinsam durchgeführt wurden. Der
Kunde, FHG und IBM stellten für alle Phasen des Projektes das erforderliche
Personal zur Verfügung.
Die Projektschritte:
• Prinzipien
Die Prinzipien für das Projekt wurden auf der Grundlage der MINZE-Studie
festgelegt. Die essentiellen Anweisungen dieser Studie wurden durch vom
LIT ausgearbeitete Anweisungen ergänzt.
• Funktionen und „Managed Elements″
Die Definition der Details der Prozesse wurde durch Arbeitsgruppen
vorgenommen. Dabei wurde für jede SM-Disziplin eine eigene Arbeitsgruppe
eingerichtet.
• Prozeß-Modell
Die Ergebnisse der ersten beiden Arbeitsschritte führten zur Definition der
Prozeß-Modelle. Für jede Management-Disziplin wurden die
Kapitel 2. Design Beispiele 23

2.1.5 Designergebnisse
Management-Domänen bestimmt. Das nachstehende Muster veranschaulicht
die Definition von Management-Domänen für die Fehlerverwaltung:
PM1 Verarbeitung hardwarebezogener Fehler
PM2 Verarbeitung softwarebezogener Fehler
Management-Domänen für den Softwarevertrieb sind:
DM1 Definition und Erstellung von Software und Datenpaketen
DM2 Verteilung, überwachte Installation und, falls erforderlich,
Zurückziehung von Paketen
Die im Rahmen der einzelnen Management-Domänen auszuführenden
Prozeßschritte wurden bis ins kleinste Detail definiert. Zudem wurden die
Schnittstellen zwischen den verschiedenen Management-Disziplinen
bestimmt.
• Infrastruktur
Der letzte Arbeitsschritt des Design-Projektes bestand in der Definition der
SM-Infrastruktur und der Bereitstellung aller Ergebnisse des
Design-Prozesses.
Das LIT-Projekt war erfolgreich, weil:
• Das Management von Anfang bis Ende am Design-Prozeß beteiligt war
• Eine gute Mischung persönlicher Fertigkeiten und Wissen dem Projekt zur
Verfügung stand (LIT, ISST, und IBM)
• Die nötige Kontinuität während Design und Implementierung der erarbeiteten
Infrastruktur durch die MINZE-Studie gewährleistet wurde.
Zu den im Rahmen dieses Design-Projektes zu erbringenden Leistungen zählten
eine zusammenfassende Darstellung der Management-Aufgaben und eine
detaillierte Dokumentation zur Infrastruktur. Unmittelbar nach Abschluß des
Design-Prozesses wurde beim LIT eine Pilotinstallation durchgeführt, um die
Designergebnisse zu bestätigen und während der Implementierungsphase als
Probebühne zu dienen. Die im Rahmen des Projektes zu erbringenden
Leistungen umfaßten:
• Definition von Dienstleistungen
• Prozeß-Modelle
• Aufgaben-Beschreibung
24 Systems Management Design - Ein Überblick
2.1.5.1 Definition von Dienstleistungen
Die Definition der zu erbringenden Dienstleistungen basiert auf den
Management-Anforderungen, die bereits unter 2.1.3, „Auswahl der SM-Prozesse“
erörtert wurden. Die Spezifikationen zu Dienstleistungen auf dem Gebiet der
Sicherheitsverwaltung werden hier als Beispiel für die Definition von
Dienstleistungen herangezogen.
Das Service- und Administrationszentrum (SAZ) ist für Prozesse der
Sicherheitsverwaltung und entsprechende Hilfsprogramme verantwortlich.
Dadurch ist gewährleistet, daß bei der Entwicklung neuer Anwendungen ein
hoher Sicherheitsstandard (Sicherheitsstufe B2 gemäß Orange Book/DoD)
garantiert ist und die Daten in der Fertigungsumgebung geschützt werden
können.

Die Sicherheitsverwaltung basiert auf OSF/DCE-Strukturen und -Komponenten
(Open Software Foundation/Distributed Computing Environment) in Verbindung
mit der DCE-Struktur. Es werden folgende Funktionen bereitgestellt:
• Identifikationsüberprüfung
Bevor Benutzer im System oder im Netz Zugriff auf Ressourcen erhalten,
muß ihre Identität bestätigt werden.
• Berechtigung
Zugriffsberechtigungen von Benutzern und Anwendungen müssen definiert
und bestätigt werden.
• Protokollierung
Jeder Zugriff auf Systeme, Netze und Daten muß protokolliert werden
• Datenverschlüsselung
Während einer Übertragung von Daten ist ein Schlüssel zu benutzen, der nur
für eine einzige Übertragung Gültigkeit hat.
• Kennwörter dürfen in keinem Fall durch das Netz übertragen werden.
2.1.5.2 Prozeß-Modelle
Am Anfang des Design-Projektes wurden detaillierte Prozeßdefinitionen
erarbeitet, die während des gesamten Design-Prozesses genutzt wurden, um die
benötigten Funktionen, Fertigkeiten und Hilfsprogramme zu bestimmen.
Abbildung Abb. 9 zeigt das Prozeß-Modell für Softwareverteilung in einer der
Management-Domänen.
Abbildung 9. LIT - Prozeßdefinition der Änderungsverwaltung
Kapitel 2. Design Beispiele 25

26 Systems Management Design - Ein Überblick
Für die einzelnen Prozeßschritte wurden die entsprechenden Aufgaben und
Verantwortungsbereiche bestimmt. Die folgende Beschreibung bezieht sich auf
den Schrittzeitplan für diesen Prozeß.
Um einen Zeitplan für den Vertrieb eines Pakets aufstellen zu können, muß der
Anfordernde die Namen der Zielsysteme und den Zeitpunkt für Installation und
Aktivierung des Pakets angeben.
Im SAZ überprüft der Administrator den Inhalt der Pakete und wählt das Medium
für deren Verteilung (Netz, Band oder CD) unter Berücksichtigung der
Zielsysteme, der Netzverbindungen und der jeweiligen Datenmenge.
Abschließend wird die Bestellung an das Verteilungsprogramm übergeben.

2.1.5.3 Aufgaben-Beschreibungen
Abbildung 10. LIT - Aufgaben-Beschreibungen in Management-Domänen für die Änderungsverwaltung
Durch die MINZE-Studie wurden den lokalen Verwaltungsgruppen bereits ihre
jeweiligen Rollen zugewiesen. Diese Rollendefinitionen wurden während des
Design-Prozesses erweitert und abschließend bearbeitet. Ergebnis dieser
Bemühungen sind Aufgaben-Beschreibungen für die Administratoren der
einzelnen Management-Domänen. Die Aufgaben-Beschreibung für eine Person,
die in der Benutzerunterstützung für lokale Anwendungen tätig ist, wird in
Abb. 10 beispielhaft dargestellt. Auf der Grundlage dieser Aufgaben-
Beschreibung können die von der entsprechenden Person zu erfüllenden
Anforderungen leicht bestimmt werden.
2.1.6 Gegenwärtiger Status und Ausblick auf die Zukunft
Das LIT nutzt die neue Infrastruktur seit Jahresende 1994 in Form einer ersten
Client/Server-Anwendung. Die Migration der Anwendungen ist hierbei ein
ständig fortschreitender Prozeß. Durch das Importieren von Anwendungen in die
neue Umgebung werden sie Bestandteil der neuen Infrastruktur. Im Sommer
1995 fand diese Migration an 15 Lokationen mit etwa 2.000 Netzknoten statt.
Auf der Grundlage der Erfahrungen mit der Pilotumgebung und der
gegenwärtigen Produktionsumgebung werden unter Verwendung der
entwickelten und implementierten Infrastruktur mehr Anwendungen und Netze
integriert, als ursprünglich beabsichtigt war. Der zuvor erwartete Umfang des
Netzes und des verwalteten Systems wird daher überschritten werden.
Kapitel 2. Design Beispiele 27

2.2 Design Beispiel 2
Für die Implementierung der Infrastruktur wurde eine Zeitspanne von vier Jahren
veranschlagt. Zum jetzigen Zeitpunkt sind anderthalb Jahre vergangen und es
wird erwartet, daß der Zeitplan eingehalten werden kann. Nur die Integration
zusätzlicher Anwendungen und Netze könnte noch zu einer Überschreitung der
ursprünglich geschätzten Implementierungsdauer führen.
Die hierbei entstandene beispielhafte Struktur ist für die Stadt Berlin zu einem
äußerst wertvollen Betriebsvermögen geworden. Die jetzt etablierte
Verwaltungsinfrastruktur versetzt die Stadt in die Lage, diese Infrastruktur Dritten
außerhalb der örtlichen Verwaltung im Rahmen eines kostengünstigen Service
anzubieten.
Das vorliegende Beispiel beschreibt das Projekt eines amerikanischen
Unternehmens im Bereich der Telekommunikation. Aus Gründen der
Vertraulichkeit möchte der Kunde nicht namentlich genannt werden. Inhalt des
Projekts ist die Umgestaltung der IT-Benutzerunterstützung von einer streng
zentralisierten Verarbeitungsumgebung (sechs größere S/390-Rechenzentren) zu
einer erweiterten Umgebung, zu der 5.000 UNIX-Server und 40.000 PCs an mehr
als 1.000 Standorten gehören werden. Die ursprüngliche
Client/Server-Anwendungsumgebung bestand aus 3.000 PCs an 300 lokalen
Standorten von denen aus auf Daten und Anwendungen auf 100 UNIX-Servern an
50 lokalen Standorten zugegriffen werden konnte.
Die Aufgabe von IBM bestand darin, eine Organisation für die
IT-Benutzerunterstützung zu entwerfen, die eine verteilte Umgebung so effektiv
und effizient unterstützen kann, wie es der Endbenutzer bisher von der
zentralisierten Großrechnerumgebung gewohnt war.
Als Ergebnis erhielt der Kunde ein detailliertes Design der Prozesse zur
Benutzerunterstützung, der entsprechenden Hilfsprogramme, sowie zum
Personal, das benötigt wird, um die verteilte Datenverarbeitungsumgebung von
einer zentralen Stelle aus zu betreiben. Zusammen mit einem Einführungsplan
für die ursprüngliche Client/Server-Anwendung, mußte das Design auch so
gestaltet werden, daß neun zusätzliche, verteilte Datenverarbeitungsprojekte
integriert werden konnten, deren Implementierung für die Jahre 1995 und 1996
geplant ist.
2.2.1 Einführung in die Kundensituation
28 Systems Management Design - Ein Überblick
Die US-Telekommunikationsindustrie bewegt sich mit großer Geschwindigkeit auf
eine zweite Deregulierungswelle zu. Die erste Deregulierungswelle in den frühen
achtziger Jahren öffnete die Märkte für Ferngespräche sowie überregionale und
internationale Telekommunikation dem Wettbewerb und verteilte die lokalen
Telekommunikationsdienstleistungen auf sieben regionale
Betreibergesellschaften. Im Zuge des technologischen Fortschritts (drahtlose
Kommunikation, Satellitenverbindungen, Kabelfernsehen, etc.) bietet sich jetzt
die Chance, lokale Telekommunikationsdienstleistungen dem freien Wettbewerb
zu öffnen. Um sich auf neue Wettbewerber und neue Chancen vorzubereiten,
sehen die regionalen Betreibergesellschaften einer dramatischen Umgestaltung
ihrer Unternehmensstrukturen entgegen.
Während der letzten 3 Jahre hat der Kunde fast 1 Milliarde US-Dollar investiert,
um die Informationstechnologie darauf auszurichten, die neu definierten

Strategien der einzelnen Abteilungen des Unternehmens unterstützen zu
können. Nach 2 Jahren der betrieblichen Umgestaltung, der Neuausrichtung der
IT-Strategie und der IT-Anwendungsentwicklung, plant der Kunde, 10 neue
verteilte Anwendungen in den Produktionsablauf einzubinden, die für den
geschäftlichen Erfolg von entscheidender Bedeutung sind. Insgesamt werden die
10 Projekte zu verteilten Anwendungen die Firma des Kunden von der heutigen
S/390-Basis zu einer dreigeteilten Client/Server-Architektur führen, die sich auf
200 entfernte Standorte verteilt. Das vorhandene Personal zur
IT-Benutzerunterstützung trägt jetzt die Verantwortung dafür, die Unterstützung
der neuen Umgebung auf dem hohen Niveau zu halten, das in der bisherigen
Umgebung gegeben war. Wichtigstes Ergebnis einer internen Überprüfung der
Fähigkeit des Kunden zur Benutzerunterstützung war die Feststellung des
Bedarfs für eine Neubewertung, Neugestaltung und Umstrukturierung von
Fertigkeiten, Prozessen und Hilfsprogrammen für die verteilte
Datenverarbeitungsumgebung.
Die ursprüngliche Anordnung, für deren Betreuung IBM Consulting engagiert
wurde, bestand aus 3.000 PC-Workstations, die auf 300 Standorte verteilt waren,
mit WAN-Anschluß für einen von 50 Regionalstandorten. Ein typischer
Regionalstandort wird über 6 UNIX-Server verfügen, von denen 4
X-Stationsleistungen für die PC-Workstations bieten werden und die
verbleibenden 2 als Anwendungs- und Datenbank-Server dienen werden.
Gemäß der bisherigen Planung werden diesem Erstprojekt neun weitere Projekte
vergleichbaren Umfangs folgen. Zum Jahresende 1996 wird der Kunde zusätzlich
zu den bereits existierenden 6 S/390-Großrechnerstandorten über mehr als
40.000 PC-Workstations, 2.000 Novell-LAN-Server und 5.000 UNIX-Server
verfügen.
2.2.2 Die zu verwaltende Umgebung und ihre Eigenschaften
Unter Einsatz der vorstehend beschriebenen Technologie, bestand die zu
„ managende″ Umgebung des Kunden aus Endbenutzern, die PCs auf
Windows-Basis nutzten, wobei eine X-Stationsemulation zum Einsatz kam, um
auf diverse graphische UNIX-Anwendungen an einem entfernten Standort
zugreifen zu können. Die für die Anwendungen benötigten Daten sind auf
UNIX-Datenbank-Servern gespeichert, die sich am gleichen Standort wie die
UNIX-Anwendungen befinden.
Die zu „managende″ Umgebung dieses Kunden weist einige Besonderheiten auf.
• Das WAN wird von einer separaten Unternehmensabteilung des Kunden
verwaltet und wurde im Rahmen unserer Studie als „Black Box″ betrachtet.
Dadurch kann das WAN als Service definiert und verwaltet werden, der von
einem firmenfremden Lieferanten bereitgestellt wird.
• Zum gegenwärtigen Zeitpunkt ist die verteilte Umgebung nicht an ein
zentrales System angeschlossen, wie es in Zukunft der Fall sein wird. Bei
Einrichtung des zentralen Systems wird der Kunde die Grenzen der zu
verwaltenden Umgebung erweitern müssen, um dieses zentrale System in
den Produktionsablauf zu integrieren. Das zentrale System erfordert eine
Überprüfung der Verfahren zur Datensicherung und Datenwiederherstellung,
sowie des „End-to-End″ Performance Managements.
Kapitel 2. Design Beispiele 29

2.2.3 Auswahl der SM-Prozesse
Da es das vordringlichste Ziel des Kunden ist, die Benutzerunterstützung für die
verteilte Umgebung von einem zentralen System aus zu leisten, haben der
Kunde und IBM Consulting die Prozesse ermittelt, denen entscheidende
Bedeutung für die Erreichung dieses Ziels zukommt. Diesen Prozessen wurde
höchste Priorität verliehen:
• Management von Kundenanfragen
• Problem Management
• Change Management
2.2.4 Durchführung des Designs
30 Systems Management Design - Ein Überblick
• Operations Management (Datensicherung / -wiederherstellung,
Softwareverteilung)
• Performance- und Kapazitätsmanagement
• Management der Datensicherheit
Es wurde ein detaillierter Projektplan entworfen, um die vier Phasen der
SMFD-Methode zu ergänzen. Es wurden SMFD-Aufgaben aufgelistet, jeder
Aufgabe eine geschätzte Anzahl an Arbeitstagen zugeordnet, und einzelne
Teammitglieder gemäß ihrer individuellen Fertigkeiten und ihrer Verfügbarkeit
mit der Ausführung spezifischer Aufgaben betraut.
In dem Projekt war es von größter Bedeutung, Fortschritte zu überwachen und
Problembereiche frühzeitig zu erkennen. Der Projektplan wurde im
Hauptarbeitsraum des Teams ausgehängt und es wurde den einzelnen
Teammitgliedern ein separater Bericht mit ihren jeweiligen
Verantwortungsbereichen übergeben. Mit der SMFD-Methode, die so strukturiert
ist, daß sie die parallele Durchführung voneinander unabhängiger
Arbeitsvorgänge ermöglicht, wurden wichtige Eckdaten festgesetzt, um zu
bestimmen, zu welchem Zeitpunkt die unabhängigen Aufgaben
zusammengeführt werden müssen. Dadurch wurde der Projektleiter in die Lage
versetzt, den Fortschritt des Gesamtprojektes in regelmäßigen Zeitabständen
(normalerweise alle 10 Kalendertage) anhand von Prüfpunkten zu überwachen.
Die SMFD-Methode ermöglicht es, von einer großen Zahl von Experten für
einzelne Themenbereiche Informationen einzuholen. Wir haben die Erfahrung
gemacht, daß es ratsam ist, die Experten des Kunden 2-3 Wochen im voraus zu
informieren, um ihnen die Zeit zu geben, sich auf unsere SMFD-Interviews
vorzubereiten. Der Projektplan war das Werkzeug, das benutzt wurde, um die
Ressourcen von IBM und denen des Kunden zu koordinieren, und somit die
Sammlung der richtigen Informationen zum richtigen Zeitpunkt zu gewährleisten.
Der Erfolg des Projektes wurde durch fünf IBM „Berater″ mit unterschiedlichen
Wissensschwerpunkten sichergestellt.
Die Tatsache, daß das Team sich auf einen erfahrenen SMFD-Mentor stützen
konnte, war von entscheidender Bedeutung.

Projekt Manager
• Allgemeine Managementfähigkeiten und -erfahrungen beim Kunden
• Fähigkeiten im Bereich Projektmanagement
SMFD / Systems Management Mentor
• SMFD-Erfahrung
• Erfahrung im Design von SM-Prozessen
• Erfahrung mit SM-Hilfsmitteln und -Technologie
Prozeß- / Organisations-Consultant
• Fachwissen auf dem Gebiet von Geschäftsprozeß-Modellen, Vorgängen und
Bewertungsverfahren
• Fachwissen auf den Gebieten Organisationsstruktur Größenordnungen
• Fachwissen zu Rollen und Verantwortungsbereichen von Mitarbeitern im
Rahmen des Systems Management
Technischer / Hilfsmittel-Consultant
• Erfahrung im Bereich der Auswahl von Hilfsmitteln und Hilfsprogrammen zur
System- und Netzwerkverwaltung
• Allgemeine Kenntnisse aus dem Bereich der Informationstechnologie
Auf Wunsch unseres Kunden bestand unser SMFD-Designteam aus 3-5
Vertretern der IBM Consulting Group und 2-3 Mitarbeitern des Kunden. Das
gemischte Team trug dazu bei, daß der Kunde die zur Umsetzung der
Ergebnisse und Empfehlungen der Studie erforderlichen Fähigkeiten mit offenen
Armen aufnahm und akzeptierte. Vom Kunden gestellte Teammitglieder haben
normalerweise Verbindungen und Kontakte innerhalb ihres Unternehmens, was
besonders von Vorteil ist, wenn es gilt, die gefundene Lösung an den Mann zu
bringen.
Aus diesem Projekt ergaben sich folgende Erkenntnisse:
• Rechtzeitige Abstimmung mit dem Sponsor. Erzielen einer frühzeitigen
Einigung über Umfang und Format der zu erbringenden Leistungen; ein
offenes Ohr haben für Beiträge und Ratschläge dazu, wie Informationen im
Unternehmen des jeweiligen Kunden präsentiert werden sollten.
• Man darf nicht aus den Augen verlieren, daß ein SMFD nur umgesetzt
werden kann, wenn der Kunde das Design versteht und in der Lage ist,
Ressourcen zu dessen Umsetzung bereitzustellen und die vorhandene Basis
zu erhalten und weiter auszubauen.
• Alle Aufgaben, die auf Arbeiten in einer frühen Phase des Projektes
basieren, sollten frühzeitiger als bisher überarbeitet werden. Alle danach
geleisteten Arbeiten müssen ebenfalls überprüft und überarbeitet werden. Je
weiter fortgeschritten der SMFD-Prozeß ist, desto umfangreicher und
kostspieliger sind die erforderlichen Nacharbeiten. Die Schlußfolgerung
daraus ist, daß die Arbeiten abgeschlossen sein müssen, bevor die nächste
SMFD-Aufgabe in Angriff genommen wird.
Kapitel 2. Design Beispiele 31

2.2.5 Designergebnisse
Die entscheidenden SMFD-Eckdaten, die, nachdem sie einmal festgelegt wurden,
so wenig wie möglich verändert werden sollten, sind:
• Die Prinzipien: So früh wie möglich sammeln, dokumentieren und
zusammenfassen
• Die Auswahl der selektierten Prozesse
• Umfang und Definition der Systemumgebung
Das Vorhandensein von Referenzbeispielen kann eine große Hilfe dabei sein,
anschaulich zu machen, wie die Details einer SMFD-Studie dokumentiert und
vermittelt werden können. Wir haben festgestellt, daß Referenzen für die
einzelnen Phasen sehr gut dazu eingesetzt werden können, die Aufmerksamkeit
des Teams auf die zu erreichenden Ziele zu konzentrieren. Wie schon bei
anderen SMFD-Aufträgen, sind die Arbeitsergebnisse dieses Auftrags über die
IBM Consulting Group abrufbar.
2.2.6 Gegenwärtiger Status und Ausblick auf die Zukunft
Dadurch, daß Mitarbeiter des Kunden als Vollzeitmitglieder in das
SMFD-Designteam integriert waren, verfügt der Kunde jetzt über eine Reihe von
eigenen Mitarbeitern, die das SMFD-Design in seiner Gesamtheit verstehen,
anwenden und umsetzen können. Bis heute sind zwei der Mitarbeiter des
Kunden, die in dem SMFD-Designteam mitwirkten, befördert worden, um in
Zukunft eine führende Rolle bei der strategischen Ausrichtung der
Kundenorganisation auszufüllen. Außerdem hat der Kunde der IBM Consulting
Group einen Anschlußauftrag für die Implementierung des Designs erteilt.
Zukünftige Aktivitäten
32 Systems Management Design - Ein Überblick
Eine große Stärke der SMFD-Struktur liegt in der Möglichkeit, das ursprüngliche
Design zu erweitern, um zusätzliche Prozeß- und Systemelemente zu
integrieren. Damit ist dieses Projekt keine „Einmalaktion″, sondern kann an neue
Gegebenheiten angepaßt werden.

2.3 Design Beispiel 3
Die Oberfinanzdirektion Hannover ist zuständig für die Planung und den Betrieb
des DV-Netzes der niedersächsischen Finanzverwaltung. Sie versorgt rund 9.000
Mitarbeiter in 68 Finanzämtern mit Hardware, Software und Anwendungen zur
Automation der steuerfachlichen und organisatorischen Verfahrensabläufe. Dazu
betreibt die OFD seit mehr als einem Jahrzehnt ein Verteiltes DV-Netz (VDV I)
auf der Basis von zentralen IBM-Hostrechnern und SNI 8860-Abteilungssystemen
mit Bildschirmarbeitsplätzen in jedem Finanzamt.
Abbildung 11. OFD Hannover - Vorhandene IT-Infrastruktur
2.3.1 Einführung in die Kundensituation
In den Jahren 1991-92 erkannte die OFD, daß die existierende DV-Infrastruktur
den steigenden Anforderungen der Finanzverwaltung nicht mehr gerecht werden
würde. Die Ausstattung jedes Arbeitsplatzes mit einem Bildschirm bzw. PC, die
Integration von Textverarbeitung und anderen Büroanwendungen, die Nutzung
komfortabler graphischer Benutzeroberflächen: all dies ließ sich mit der
installierten Hardware nicht mehr bewerkstelligen, die einerseits ihre
Leistungsgrenze erreicht hatte und andererseits - aufgrund ihrer proprietären
Natur - für den Einsatz in einem PC-LAN-Verbund nur sehr begrenzt geeignet
ist.
Kapitel 2. Design Beispiele 33

Abbildung 12. OFD Hannover - Geplante Infrastruktur
34 Systems Management Design - Ein Überblick
Ein modernisiertes Konzept für verteilte Datenverarbeitung (VDV II) mußte her.
Um die Voraussetzungen für eine integrierte Vorgangsbearbeitung für jeden
Arbeitsplatz zu schaffen sowie langfristig eine Zusammenarbeit mit den
Finanzverwaltungen anderer Bundesländer (wie sie mittlerweile im
Bundesprojekt FISCUS1 skizziert worden war) zu ermöglichen, entschloß sich die
OFD für eine Ablösung der dezentralen Systeme zugunsten einer offenen,
standardbasierenden Client/Server-Infrastruktur. UNIX-Server, UNIX-Arbeitsplatz-
Computer (APCs) und TCP/IP-basierende Netzwerkdienste sollten die Basis für
eine flexible, erweiterbare (und vor allen Dingen herstellerunabhängige)
zukünftige DV-Lösung bilden.
In mehreren Phasen wurden die Netzwerkkomponenten, die Server und die
APCs ausgeschrieben und an verschiedene Anbieter vergeben:
• Siemens erhielt den Auftrag, ein Multiprotokollnetz (WAN/LAN) auf der Basis
von CISCO-Routern und Synoptics-Hubs zu installieren
• IBM erhielt den Zuschlag für 350 AIX-Server
• SNI konnte sich mit seinem APC-Angebot durchsetzen und erhielt den
Auftrag für 9.000 INTEL-PCs mit SUN-Solaris Betriebssystem.
Die Firma Partner-Consult, die OFD auch schon in der Planungs- und
Ausschreibungsphase unterstützt und beraten hatte, wurde gleichzeitig mit der
Portierung der existierenden Anwendungen beauftragt.
Schließlich wurden auch die Anforderungen an ein effektives Systems
Management der zukünftigen Infrastruktur untersucht. In verschiedenen
Arbeitsgruppen wurden die Themen Netzwerkstruktur, Systemarchitektur und
-komponenten, Bestandsführung und Problem Management, Sicherheit sowie
Software-Verteilung bearbeitet.

Für das VDVII Projekt der OFD war ein wesentlicher Erfolgsfaktor von Anfang an
klar: die Akzeptanz der neuen Lösung würde maßgeblich davon abhängen,
ob - bei zunächst unveränderter Arbeitsweise in den Anwendungen - die
gleichen bzw. bessere Service-Qualitäten aus Sicht der Anwender erreicht
werden könnten. Angesichts der weitestgehend unbekannten neuen
Technologien, der erheblich größeren Komplexität der neuen Infrastruktur und
der verläßlich arbeitenden VDVI-Lösung keine leichte Aufgabe!
Hauptanforderungen an das Systems Management des geplanten VDVII-Systems
mußten daher sein:
• die Minimierung des dezentralen Betreuungsaufwandes durch zentrale
Kontrolle, Steuerung und Administration aller Komponenten (Netz, System,
Anwendungen)
• eine weitestgehende Automatisierung aller Steuerungs- und
Administrationsabläufe, um den manuellen Unterstützungsbedarf
(insbesondere auch während der Installationsphase) möglichst gering zu
halten.
Systems Management umfaßt in diesem Zusammenhang alle Prozesse und
unterstützenden Werkzeuge, die notwendig sind, um geeignete
Qualitätsmerkmale (z.B. bezogen auf Verfügbarkeit, Sicherheit, Integrität,
Aktualität, usw.) für alle DV-Dienste und Ressourcen zu gewährleisten.
Neben den technischen Herausforderungen, die offene Client/Server-Systeme an
das Systems Management stellen, sind auch neue organisatorische Konzepte
gefordert, die Rollen und Zuständigkeiten von Endanwendern in den
Fachabteilungen, und Spezialisten in den zentralen DV-Abteilungen neu
definieren und festlegen. Isolierte Produktlösungen und spontane Abläufe
(Benutzer helfen sich gegenseitig!) reichen da in der Regel nicht aus - Systems
Management muß designed werden. Aber wie und nach welchen Kriterien?
Im Rahmen der Präsentation eines Lösungsvorschlages für SW-Verteilung,
Systemadministration und Datensicherungssoftware, erhielt die IBM im Mai 1994
die Gelegenheit, ihre Methodik für das Design von unternehmensweiten
SM-Lösungen vorzustellen. Anhand eines konkreten Projektbeispiels wurde
gezeigt, wie in einem Top-Down Ansatz die konsequente Umsetzung von
Benutzeranforderungen in eine implementierbare SM-Lösung erreicht werden
kann.
Die OFD entschloß sich daraufhin, in Zusammenarbeit mit der IBM ein Projekt
VDVII Systems Management zu starten. Unter besonderer Berücksichtigung
eines integrierten Ansatzes sollten zunächst folgende Aufgaben durchgeführt
werden:
• Untersuchung der Anforderungen und Prioritäten für ein unternehmensweites
SM-Konzept
• Analyse und Design der wichtigsten Managementprozesse sowie der
Schnittstellen zwischen den Prozessen
• Implementierung der wichtigsten Funktionen und Abläufe für eine
Pilotumgebung
Als Vorgehensmodell für die konzeptionelle Phase sollte dabei die IBM
SMFD-Methode zur Anwendung kommen.
Kapitel 2. Design Beispiele 35

2.3.2 Durchführung des Designs
Verantwortlich für die Organisation und Koordination waren je ein Projektleiter
auf Seiten der OFD und der IBM. Unter ihrer Leitung wurde im Verlaufe des
Projektes ein Team gebildet. Dieses bestand aus den schon aktiven
Arbeitsgruppen bei der OFD, und wurde später durch vier Mitarbeiter der IBM
sowie vier Mitarbeiter von IBM Partner-Firmen verstärkt.
Ein Steuerungsgremium, bestehend aus OFD-Referatsleitern und einem IBM
Manager, war zuständig für die Kontrolle und Abnahme der von den
Arbeitsgruppen erarbeiteten (Teil-)Ergebnisse, die in regelmäßigen Abständen
und jeweils nach Abschluß der Projektphasen einem breiten Kreis von
OFD-Mitarbeitern aus den verschiedensten Organisationsbereichen präsentiert
wurden.
Im September 1994 machte sich ein Kernteam aus OFD- und IBM-Mitarbeitern an
die Arbeit. In mehreren Workshops wurden zunächst Status und Zielsetzung des
Gesamtprojektes, Rahmenbedingungen sowie globale SM-Prinzipien
dokumentiert. Anschließend wurde das Zielsystem (d.h. die zu verwaltenden
Komponenten) festgelegt und die Gesamtheit aller SM-Aufgaben in 12
Prozeßgruppen zusammengefaßt, grob beschrieben (Abb. 13) und gemäß Ihrer
Bedeutung für das VDVII-Projekt mit Prioritäten versehen. Wesentlichen Input für
diese Phase bildeten dabei die bereits dokumentierten Ergebnisse der
verschiedenen existierenden Arbeitsgruppen sowie allgemeine Richtlinien und
Grundsätze der OFD.
Systembetrieb Steuern, Überwachen und Regeln des Gesamtsystems und seiner
Komponenten
Systemadministration Zentrales Planen, Einsetzen und Verändern von (technischen)
Konfigurationsparametern
Software-Verteilung (Zentral) Gesteuertes Verteilen und Installieren von
Anwendungs- und Systemsoftware sowie Anwendungsdaten
(Konfigurations-Dateien, ...).
Change Management Kontrolliertes Erfassen, Einplanen und Aktualisieren von
Änderungen am System
Problem Management Erfassen, Bewerten, Analysieren, Beheben und Dokumentieren von
Fehlern im System
Verfügbarkeit Festlegen und Überwachen von Randbedingungen für
Systemverfügbarkeit
Bestandsführung Erfassen und Verwalten von (technischen) Geräten nach technischen
und haushaltsrechtlichen Richtlinien und Vorgaben
Performance Management Überwachung der Leistung einzelner Systemkomponenten und
Feststellen von Engpässen
Datensicherung Sicherung und Wiederherstellung von Anwendungsdaten und speziellen
Systemdaten
Security Management Festlegen und Sicherstellen von Zugriffsrechten im Gesamtsystem
Abrechnung Bestimmen und Berichten der anteiligen Nutzung des Systems
Benutzerunterstützung Hilfefunktionen für den Anwender
Abbildung 13. Die zwölf SM-Prozeßgruppen der OFD
36 Systems Management Design - Ein Überblick

In einem Review zum Abschluß der Stufe 1 wurde auf Vorschlag des Teams
beschlossen, zunächst nur die 5 wichtigsten Prozeßgruppen (Systembetrieb,
Software-Verteilung, Systemadministration, Problem Management,
Bestandsführung) im Detail auszuarbeiten und für die Pilotinstallation zu
implementieren.
Gemäß der SMFD-Methodik wurden im nächsten Schritt die einzelnen Aktivitäten
der ausgewählten SM-Prozesse in einer Excel-Tabelle gegen die „Managed
Elements″ des Zielsystems eingetragen. Für jede Prozeß/Elementkombination
sollten anschließend die geforderte Management-Funktion und die Ausführenden
der Funktion (Menschen oder Automaten) bestimmt werden und schließlich ein
Lösungsvorschlag (wo, wann, wie und mit welchem Tool wird die Funktion
ausgeführt) erarbeitet werden.
Abbildung 14. OFD Hannover - Beispiel für Prozeß/Element-Matrix und Interviewbogen
Um diese umfangreichen Aufgaben in möglichst kurzer Zeit abarbeiten zu
können, entschied man sich, in fünf Kleinstgruppen parallel vorzugehen. Je ein
IBMer und ein bzw. zwei OFD-Mitarbeiter übernahmen die Verantwortung für den
Teil der Matrix, der ihre Prozeßgruppe beschrieb. In viel Kleinarbeit wurden die
Anforderungen und existierenden Lösungen zusammengetragen.
Notwendigerweise wurden dazu häufig die nicht zum Kernteam gehörenden
OFD-Spezialisten mit einbezogen und ihre Antworten auf Interviewbögen in
einem einheitlichen Format dokumentiert.
Kapitel 2. Design Beispiele 37

Abbildung 15. OFD Hannover - Eine konsolidierte Matrix
38 Systems Management Design - Ein Überblick
Schon während dieser Phase gelang es, die Komplexität der Matrix erheblich zu
reduzieren: unterschiedliche Matrixelemente wurden immer dann
zusammengefaßt, wenn die gleichen Anforderungen bestanden und eine
gemeinsame Lösung gefunden werden konnte. Dabei konnten sich die anfangs
aufgestellten Prinzipien und Richtlinien wiederholt bewähren, indem sie unter
verschiedenen Design-Alternativen den Weg zur richtigen Lösung wiesen.
Zum Abschluß der SMFD-Studie wurden die umfangreichen Informationen weiter
komprimiert und als Rahmenwerk für die folgenden Aktivitäten dokumentiert. Als
wesentliche Ergebnisse entstanden hierbei Prozeßablaufdiagramme,
Aufgaben-Beschreibungen für die verschiedenen Support-Organisationen, sowie
eine Beschreibung der technischen Infrastruktur für die einzelnen
SM-Funktionen.

2.3.3 Die Implementierungs-Phase
Abbildung 16. OFD Hannover - Systems Management Support Organisation
Schon während der Konzeptphase hatte ein kleines Team mit dem Aufbau eines
Testsystems begonnen, so daß eine technische Implementierung der
erarbeiteten Lösungen umgehend in Angriff genommen werden konnte. In einem
ersten Schritt sollten die Grundfunktionalitäten der ausgewählten
Standardprodukte ausgenutzt werden. Ergänzungen und Anpassungen wurden
zunächst nur dort vorgenommen, wo kritische Funktionalitäten und Schnittstellen
zwischen den Produkten nicht vorhanden waren, aber mit relativ geringem
Aufwand geschaffen werden konnten.
Eine Ausnahme zu dieser Regel bildeten nur die Bereiche
Bestandsüberwachung und Systemadministration (Configuration Management).
Hier hatte die SMFD-Studie eindeutig gezeigt, daß die am Markt erhältlichen
Standardprodukte den spezifischen Anforderungen der OFD nicht genügen
würden, so daß man sich zu Eigenentwicklungen entschloß. Ein wesentlicher
Aspekt dabei war die Notwendigkeit, ein Höchstmaß an Automation für die
Masseninstallation von Servern und APCs zu schaffen.
Aufgrund einer Verschiebung des Installationstermins für das Pilot-Finanzamt
endete die erste Implementierungs-Phase dann im Februar 1995 mit einer
Demonstration des erreichten Standes im Test- und Referenzsystem. Den
zukünftigen Administratoren und Help-Desk Mitarbeitern konnten
Beispielszenarien aus den Bereichen Systembetrieb, Software-Verteilung und
Problem Management vorgeführt werden.
Wichtige Grundfunktionen der Systemadministration waren zu diesem Zeitpunkt
ebenfalls vorhanden und wurden bereits zur Konfiguration der Testumgebung
benutzt. Allerdings war allen Beteiligten bewußt, daß noch ein erhebliches Stück
Arbeit zu leisten sein würde, um in allen Bereichen den erwünschten
Automationsgrad zu erreichen.
Kapitel 2. Design Beispiele 39

Abbildung 17. OFD Hannover - Systems Management Infrastruktur: Topologie
2.3.4 Erfahrungen und Probleme
40 Systems Management Design - Ein Überblick
Daher wurde beschlossen, in einem Folgeprojekt mit derselben Mannschaft die
Implementierung weiter voranzutreiben und den ungeplanten Aufschub der
Pilotinstallation für eine Ausweitung der Integration und Automation zu nutzen.
Hauptaugenmerk lag dabei auf dem Erstinstallationsprozeß, der eine
vollautomatische Inventarisierung und Konfiguration der APCs in den
Finanzämtern ermöglichen sollte. Als im Oktober 1995 tatsächlich der
Pilotbetrieb aufgenommen wurde, konnte dabei erstmals die prinzipielle
Funktionsfähigkeit des Prozesses vorgeführt werden. Gleichzeitig waren damit
auch in eindrucksvoller Form die Vorteile und Möglichkeiten eines integrierten
SM-Ansatzes demonstriert worden.
Die ganzheitliche, prozeßorientierte Vorgehensweise - insbesondere während
der frühen Designphase des Projektes - war für die meisten OFD-Mitarbeiter
zunächst ungewohnt und wurde teilweise mit Skepsis verfolgt. Konkrete
(Teil-)Ergebnisse der existierenden Arbeitsgruppen standen dort abstrakten
Konzepten des SMFD-Teams gegenüber, und auch die Zuständigkeiten für
bestimmte Themen schienen problematisch. Im Verlauf des Projektes ließen sich
diese Irritationen jedoch schrittweise abbauen. Insbesondere während der
Implementierungsphase konnten sich die zugrundeliegenden Prinzipien
beweisen und die SM-Infrastruktur zu einem Integrationspunkt für die meisten
VDVII-Aktivitäten werden.
Zwei wesentliche Aspekte kennzeichnen die Implementierungsphase:
• Wie schon weiter oben beschrieben erforderte die technische
Implementierung einen hohen Integrationsaufwand und erheblichen Bedarf
an Eigenentwicklungen. Die heute schon zur Verfügung stehenden
Automatismen (z.B. der Installationsprozeß) und weiteres

Automationspotential zeigen jedoch deutlich, daß sich der Aufwand gelohnt
hat.
• Der zweite Aspekt betrifft die organisatorische Seite, d.h. die Ausbildung des
Personals und die Umsetzung der SM-Prozesse. Hier wurde sehr deutlich,
daß selbst beim Einsatz exzellenter Werkzeuge letztendlich das Fachwissen
der Mitarbeiter erfolgsentscheidend ist. Dieser Punkt kann leicht unterschätzt
werden. Das Erfassen der notwendigen Skills und Durchführen von
Schulungsmaßnahmen müssen daher so frühzeitig wie möglich innerhalb
des Projektes erfolgen.
Ein generelles Problem von Client/Server-Projekten sind die vielfach berichteten
versteckten Kosten und Terminüberschreitungen. Auch das OFD-Projekt hatte
unter diesem Effekt zu leiden. Häufig sind überzogene Erwartungen schuld an
dem offensichtlichen Widerspruch zwischen Anspruch und Wirklichkeit.
Insbesondere bei strategischen Infrastruktur-Maßnahmen, wie dem VDVII-Projekt,
dürfen aber keine kurzfristigen und billigen Erfolge erwartet werden.
Mit ihrem unternehmensweiten SM-Konzept hat die OFD einen wesentlichen
Schritt für langfristige Qualitäts- und Kostenkontrolle im VDVII-Umfeld getan.
Konsequentes, projektmäßiges Vorgehen soll nun in Zukunft ein frühzeitiges
Abschätzen von Möglichkeiten und Aufwänden erlauben und auf diese Weise
dazu beitragen, mit realistischen Erwartungen an den weiteren Ausbau der
DV-Infrastruktur zu gehen.
2.3.5 Gegenwärtiger Status und Ausblick auf die Zukunft
Wie schon gesagt wurde, konnte - nach Abschluß der
Anwendungsumstellung - im Oktober 1995 der Pilotbetrieb aufgenommen
werden. Unter Ausnutzung des automatisierten Installationsprozesses wurden
zunächst drei Server und 15 APCs eingerichtet. Die Vollausstattung des
Pilot-Finanzamtes mit weiteren 200 Arbeitsplätzen, sowie die Umstellung von
zwei weiteren Finanzämtern sind noch in diesem Jahr geplant.
Parallel zu diesen Installationsaktivitäten ist die Umsetzung der SM-Prozesse in
vollem Gang. Überwachung und Steuerung der neuen Komponenten im Rahmen
des Systembetriebs, sowie die Benutzerunterstützung durch das Problem
Management müssen sich erstmals im Produktionsumfeld bewähren. Dies
geschieht zur Zeit noch unter tatkräftiger Mithilfe des SM-Designteams, da das
ohnehin knappe Personal des Finanzrechenzentrums der OFD noch Erfahrungen
im Umgang mit der neuen Infrastruktur sammeln muß. Eine umfassende
Bewertung der Projektergebnisse kann hier sicherlich erst nach der Umstellung
weiterer Finanzämtern erwartet werden.
Daß sich die prozeßorientierte, methodische Vorgehensweise bei der OFD gut
etablieren konnte, zeigen auch die Folgeprojekte:
• Die Erweiterung des Systems Management durch zusätzliche Disziplinen ist
geplant. Hierbei sollen wieder die inzwischen bekannten SMFD-Methoden
zur Anwendung kommen.
• Im August 1995 wurde ein Projekt „Software-Entwicklungs-Umgebung und
System-Architektur″ gestartet. Unterstützt durch eine Kombination weiterer
IBM Designmethoden (End-to-End Design, OO-Vorgehensmodell) sollen in
diesem Projekt die Grundlagen für eine zukünftige objektorientierte
Anwendungsentwicklung im VDVII-Umfeld geschaffen werden.
Kapitel 2. Design Beispiele 41

42 Systems Management Design - Ein Überblick
Die Ergebnisse der Projektarbeit bei der OFD Hannover zeigen, wie eine
Ausrichtung an den Geschäftsanforderungen und Anwenderbedürfnissen bei der
Einführung einer neuen DV-Infrastruktur erreicht werden kann. Ebenso wurde
deutlich, daß ein projektmäßiges Vorgehen unter Einsatz geeigneter Methoden
für den Erfolg von Client/Server-Vorhaben wie VDVII unverzichtbar ist.

Kapitel 3. Was Führungskräfte über Systems Management Design
wissen sollten!
3.1 SMFD-Struktur
Durch die Beispiele im vorhergehenden Kapitel wurden die mit dieser
Designmethode gemachten Implementierungserfahrungen anhand einiger sehr
erfolgreicher Fälle aus der Praxis dokumentiert. Die Methode des Systems
Management Framework Design (SMFD) wird in diesem Kapitel detailliert
beschrieben.
Bestandteil zeitgemäßer, informationstechnischer Lösungen ist die Verteilung
von Funktionen und/oder Daten. Die Systeme sind im Laufe der letzten zehn
Jahre immer komplexer geworden. Ein Trend, der auch weiterhin anhalten wird.
Die Verwaltung komplexer Umgebungen erfordert hochentwickelte
Verwaltungstechniken, wie in Kapitel 1, „Strategische Ausrichtung von Systems
Management“ dargestellt. Durch die Designmethode muß gewährleistet sein,
daß alle Systeme eines Unternehmens berücksichtigt werden. Es müssen
Lösungen für die erforderlichen Verwaltungsfunktionen gefunden und angeboten
werden, und zwar sowohl für jedes einzelne System als auch für die
Kombination der Systeme eines Unternehmens.
In diesem Kapitel wird die übergreifende Struktur der SMFD-Methode mit ihren
vier einzelnen Phasen dargestellt.
Die Methode besteht aus den folgenden vier Phasen und beleuchtet die
Problematik des Systems Management aus den unterschiedlichsten
Blickwinkeln:
• Phase 1 - Grundprinzipien und Richtlinien
• Phase 2 - Funktionen und Dienstleister
• Phase 3 - Komponenten-Management
• Phase 4 - Framework-Definition
© Copyright IBM Corp. 1996 43

Abbildung 18. Die SMFD-Konzeption
Ein SMFD-Projekt wird in der Regel von einer Gruppe durchgeführt, die ihre
gesamte Arbeitszeit auf die Arbeit an diesem Projekt verwendet und mit
SM-Experten des Kunden zusammenarbeitet. Für jedes Projekt gibt es einen
Sponsor oder ein Team von Sponsoren, das sich aus Führungskräften des
Kunden zusammensetzt. Diese Sponsoren beurteilen die Arbeitsergebnisse
jeder einzelnen Phase und fungieren als eine Art Steuerungsgremium (Review
Board).
Wie bereits in der Einleitung umrissen, ist es das Ziel dieser Methode, eine
SM-Lösung für eine Kombination verschiedener Systeme und letztlich für das
gesamte Unternehmen zu bieten. Dementsprechend beginnt das Design in Phase
1 mit einer unternehmensübergreifenden Sicht der Probleme und endet in Phase
4 mit einer ebensolchen. In den dazwischen liegenden Phasen 2 und 3 gilt das
Interesse den einzelnen Elementen und Management-Funktionen.
Die Anforderungen an SM-Lösungen werden in den Phasen 1 und 2 definiert.
Das tatsächliche Design erfolgt auf Elementenebene in Phase 3 und auf
Unternehmensebene in Phase 4.
3.2 Phase 1 - Grundprinzipien und Richtlinien
44 Systems Management Design - Ein Überblick
Während der ersten Phase muß beim Kunden ein grundlegendes Verständnis für
Systems Management geschaffen werden. Die Festlegung der Ziele für das
Design-Projekt, die Motivation des Kunden für die Implementierung des Designs
und die Definition der damit verknüpften Erwartungen des Kunden sind
Bestandteil dieser Phase. Der erste Schritt besteht dabei aus der Festigung
beziehungsweise Entwicklung eines Bewußtseins für die Probleme des Systems
Management.

Abbildung 19. Die erste Phase eines Systems Management Design-Projektes
Ein SMD-Projekt beginnt nicht bei Null. Die existierende Umgebung und
Organisation, bereits implementierte Lösungen und die besonderen Präferenzen
des Kunden müssen berücksichtigt werden. Diese Gegebenheiten und die in der
Zukunft einzuschlagende Richtung werden in Phase 1 als Grundprinzipien
definiert. Diese Prinzipien werden für die folgenden Phasen des
Design-Prozesses als Input genutzt. In Kapitel 4, „Wie können Führungskräfte
das Systems Management Design beeinflussen?“ werden diese Prinzipien
eingehender beschrieben.
Nachdem die Prinzipien für ein SMD-Projekt festgelegt wurden, müssen der
Umfang der zu verwaltenden Umgebung und Eigenschaften der zu verwaltenden
Elemente bestimmt werden. Eine ausführliche Diskussion dieses Schrittes erfolgt
in Kapitel 5, „SM-Umgebung“.
Systems Management besteht aus einer Vielzahl einzelner Prozesse. In dieser
frühen Phase müssen die Prozesse ausgewählt werden, die für das
Design-Projekt von besonderer Bedeutung sind. Ferner sind bereits
implementierte SM -Prozesse zu bewerten. In Kapitel 6, „Systems
Management-Prozesse“ werden die Optionen für die Prozeßauswahl und die
Prozeßbewertung diskutiert.
Das Bewußtsein für Systems Management, die Prinzipien, die Definition der zu
verwaltenden Umgebung und die Auswahl der SM-Prozesse bilden zusammen
das Arbeitsergebnis der Phase 1.
Kapitel 3. Was Führungskräfte über Systems Management Design wissen sollten! 45

3.3 Phase 2 - Funktionen und Dienstleister
Das vordringliche Ziel der Phase 2 ist die Identifizierung der erforderlichen
SM-Funktionen für jedes einzelne der zu verwaltenden Elemente. Eine
eingehende Analyse erfolgt durch die Erstellung einer Matrix für jeden der
ausgewählten SM-Prozesse. Hierbei stehen die Zeilen der Matrix für die zu
verwaltenden Elemente. Um diese Elemente zu ermitteln, müssen die zu
verwaltenden Systeme in ihre einzelnen Elemente aufgegliedert werden. In
Kapitel 5, „SM-Umgebung“ wird die Aufgliederung und Gruppierung der
Elemente erörtert. Die Spalten der Matrix stehen für die Prozeßschritte.
Bestehende Prozeßdefinitionen sollten übernommen und entsprechend
modifiziert werden, um sie der jeweiligen Kundenumgebung anzupassen.
Abbildung 20. Matrix Elemente/Prozesse - Anforderungen an Funktionen und
Dienstleister
Die Analyse erfolgt durch Beantwortung der folgenden beiden Fragen in jeder
Zelle der Matrix:
• WAS?
Die für das Element in diesem Verarbeitungsschritt auszuführende Funktion.
• WER?
46 Systems Management Design - Ein Überblick
Die Organisationseinheit, die Eigner des Verarbeitungsschrittes ist. Der
Eigner muß nicht zwangsläufig für die Durchführung des Prozeßschrittes
verantwortlich sein, aber in sehr vielen Fällen ist eine Organisationseinheit
gleichzeitig Eigner und Durchführender eines Prozeßschrittes.
Neben den funktionalen Anforderungen werden in diesem Schritt auch die
organisatorischen Verantwortlichkeiten für das Systems Management innerhalb

der Organisation des Kunden dokumentiert. Das Ausfüllen dieser Matrizes ist
einer der Hauptbestandteile des Design-Prozesses. Diese sehr detaillierte
Sammlung der erforderlichen Verwaltungsfunktionen ist die Grundvoraussetzung
für die folgenden Phasen und für die Bereitstellung einer umfassenden,
unternehmensübergreifenden Systems Management-Lösung.
3.4 Phase 3 - Komponenten-Management
In dieser Phase wird die in Phase 2 begonnene Arbeit durch Fertigstellung der in
Phase 2 benutzten Matrix fortgeführt. Die Blickrichtung bewegt sich jetzt weg von
den gestellten Anforderungen und hin zur Erörterung einer möglichen Lösung. In
jeder Zelle der Matrix sind jetzt drei weitere Fragen zu beantworten:
• WO?
Der Ort der jeweiligen Funktion. Die Funktion kann beispielsweise in einer
fernen Datenstation, beim lokalen Administrator oder im zentralen System
resident sein.
• WANN?
Die Häufigkeit mit der die Funktion ausgeführt wird.
• WIE?
Das Hilfsmittel welches benutzt wird, um die Funktion auszuführen oder um
die Durchführung des Prozeßschrittes für dieses Element zu unterstützen.
Abbildung 21. Erweiterte Matrix Elemente/Prozesse zur Definition von
Lösungs-„Domains″
Kapitel 3. Was Führungskräfte über Systems Management Design wissen sollten! 47

Nach dem Ausfüllen der Matrix besitzt der Designer eine große Menge von
Informationen über die in Phase 2 geforderten Verwaltungsfunktionen und
grundlegende Informationen über die entsprechende Lösung in Phase 3.
Während der Phasen 2 und 3 faßt der Entwickler die Matrix immer weiter
zusammen, indem er nach Möglichkeiten sucht, den Umfang der Matrix zu
reduzieren, ohne daß Informationen verlorengehen. Eine Zusammenfassung ist
dort möglich, wo verschiedene Elemente mit einer einzigen Vorgehensweise
verwaltet werden können, da die entsprechenden Antworten auf die fünf Fragen
ähnlich sind.
In Phase 3 erfolgt eine weitere Zusammenfassung, indem Zellen bestimmt
werden, auf die eine gemeinsame Lösung angewendet werden kann. Das
Ergebnis dieser Zusammenfassung ist die Definition von Lösungs-„Domains″.
Die endgültige SM-Lösung besteht hierbei aus einer Reihe von
Lösungs-„Domains″. Diese bestimmen die Funktionen, die von einer Domäne
ausgeführt werden, sowie die Abgrenzungen und Schnittstellen zu anderen
Lösungs-„Domains″. Diese sind Teil der Gesamtlösung und unterstützen jeweils
einige der geforderten Funktionen.
Nachdem Lösungs-„Domains″ bestimmt wurden, besteht der nächste Schritt
darin, die Hilfsmittel bzw. Produkte auszuwählen, die implementiert werden
müssen, um die Prozesse auszuführen, oder deren Ausführung zu unterstützen.
Die Attribute der Lösungs-„Domain″ bilden den Input. Dieser Schritt ist optional.
Einige Kunden bevorzugen möglicherweise eine vom Design-Prozeß
unabhängige Auswahl der Produkte.
Ein Design für eine Lösung, das ohne Einschätzung der damit verbundenen
Kosten erstellt wurde, wird berechtigterweise abgelehnt werden. Obwohl die
endgültige Sortierung der relevanten Parameter erst in Phase 4 erfolgt, ist es
doch angebracht, zu diesem Zeitpunkt einige entscheidende Kostenfaktoren
festzuhalten:
• Entwicklungsaufwand
• Technische Infrastruktur
• Betriebskosten
Das Ergebnis der Phase 3 besteht aus der Definition der Lösungs-„Domains″ und
einer ersten Vorkalkulation der Kosten. Mit diesem Schritt sind detaillierte
Analyse und Design abgeschlossen.
3.5 Phase 4 - Framework-Definition
48 Systems Management Design - Ein Überblick
In der letzten Phase der SMFD-Methode werden die detaillierten
Arbeitsergebnisse der Phasen 2 und 3 zusammengefaßt. Das Ergebnis dieser
Zusammenfassung wird analysiert, um zu beurteilen, ob die in Phase 1
definierten Prinzipien realisiert wurden, oder überhaupt realisierbar sind. Das
Hauptaugenmerk liegt jetzt darauf, zu ermitteln, was getan werden muß, um das
entwickelte Managementsystem zu implementieren.
In Phase 4 wird das Design-Ergebnis formalisiert und dokumentiert. Dazu
gehören die Service-Pakete, der Implementierungsplan, die
Organisationsstruktur, die SM-Prozesse, die Design-Spezifikationen und die
Einschätzung der für den Betrieb benötigten Ressourcen. Diese Ergebnisse

wurden in Kapitel 1, „Strategische Ausrichtung von Systems Management“
bereits eingehend erläutert.
Den Abschluß des Design-Projekts bildet eine Überprüfung nach Übergabe der
Ergebnisse an den Kunden.
Kapitel 3. Was Führungskräfte über Systems Management Design wissen sollten! 49

50 Systems Management Design - Ein Überblick

Kapitel 4. Wie können Führungskräfte das Systems Management
Design beeinflussen?
4.1 Allgemeine Aspekte
In Kapitel 2, „Design Beispiele“ werden einige Beispiele für erfolgreiche
Systems Management Design-Projekte angeführt und in Kapitel 3, „Was
Führungskräfte über Systems Management Design wissen sollten!“ auf Seite 43
wird ein Überblick der SMFD-Methode gegeben.
Beginnend mit diesem Kapitel erfolgt eine eingehendere Erläuterung des System
Management Design-Prozesses. Gegenstand dieses Kapitels ist die Definition
der Prinzipien des Systems Management. Dieses ist der erste Schritt des
Design-Prozesses, dessen vordringliches Ziel es ist, sicherzustellen, daß die
Ergebnisse des Design-Prozesses den Erwartungen des Kunden gerecht werden.
SM-Prinzipien definieren die Rahmenbedingungen für das Systems Management
in der Kundenorganisation. Sie legen Art und Form der SM-Infrastruktur fest und
sie bestimmen die wichtigsten Aspekte des für die bestehende IT-Infrastruktur
erforderlichen Systems Management.
Die Prinzipien werden vom Designer auf der Grundlage der von Führungskräften
des Kunden gelieferten Informationen definiert. Der Sponsor des SM-Projektes
überprüft und genehmigt diese Prinzipien. Der Designer muß sich während des
Design-Prozesses an diese Prinzipien halten. Abweichungen von den besagten
Prinzipien müssen gerechtfertigt sein und vom Sponsor genehmigt werden.
Abbildung 22. Definition von Prinzipien für Systems Management als Management-Aufgabe
© Copyright IBM Corp. 1996 51

Durch die eingehendere Diskussion der Prinzipien auf den folgenden Seiten wird
deutlich werden, daß mittels dieser Prinzipien die zur Verfügung stehenden
Möglichkeiten für das Systems Management Design insoweit eingeschränkt
werden, als bereits in einer frühen Phase der Entwicklung Art und Form der
SM-Infrastruktur beschrieben werden. Durch solche Prinzipien werden die
Freiheiten des SM-Designers eingeschränkt.
Von besonderer Bedeutung in diesem Zusammenhang ist es, einerseits genug
Prinzipien zu erarbeiten, um sicherzustellen, daß das Ergebnis des Designs den
Anforderungen des Kunden genügt, und andererseits nicht so viele Prinzipien zu
etablieren, daß die Auswahlmöglichkeiten des Designers zu sehr beschnitten
werden und er daher nicht mehr in der Lage ist, die bestmögliche Lösung zu
wählen.
4.2 Kategorien von SM-Prinzipien
Die SM-Prinzipien können eine Reihe von Aussagen in unterschiedlichen
Kategorien beinhalten, die das Systems Management betreffen. In diesem
Kapitel werden nur einige dieser Kategorien detailliert erörtert.
• SM-Philosophie
Der Sponsor eines SM-Projektes hat in sehr vielen Fällen eine allgemeine
Vorstellung von der SM-Architektur. Diese Vorstellungen basieren auf den
Zielen des jeweiligen SM-Projektes, wie zum Beispiel der Bereitstellung
einer Verwaltung für die Infrastruktur neuer Client/Server-Anwendungen oder
der Konsolidierung der bereits existierenden IT-Infrastruktur.
Typische Aussagen in dieser Kategorie sind:
− Eine zentralisierte/dezentralisierte Verwaltung soll eingerichtet werden
− Es werden Einzel- oder Mehrfach-Verwaltungsdomänen benötigt
• Organisation von IT-Service-Liefereinheiten
Zu dieser Kategorie gehörende Aussagen beschreiben in der Regel die
existierende Umgebung unter besonderer Berücksichtigung des
Investitionsschutzes und der von der Organisation verfolgten
Entwicklungsstrategie.
Beispiele:
52 Systems Management Design - Ein Überblick
− Hierarchische/dezentralisierte Struktur mit hochbefähigten Mitarbeitern
und Mitarbeiterinnen in der Zentrale/vor Ort
− Benutzer-Service in der Zentrale/vor Ort
− Fernverwaltung ist gefordert
• Verteilung von Management-Funktionen
Die Verteilung von Management-Funktionen ist von den Aussagen der
Organisation abhängig. In dieser Kategorie gegebene Aussagen stellen
einen allgemeinen Leitfaden dafür dar, welche Management-Funktionen
verteilt, und welche weiterhin zentralisiert bleiben sollten.

So kann es zum Beispiel der Wunsch eines Kunden sein, das Problem
Management für Workgroup-Anwendungen zu verteilen, das Problem
Management für das Netzwerk und für Host-Anwendungen jedoch weiterhin
zentralisiert zu belassen.
• Prioritäten bei SM-Prozessen
In sehr vielen Fällen beginnen Kunden ein SMD-Projekt mit der klaren
Vorgabe, ausgewählte SM-Prozesse zu etablieren oder zu verbessern.
Aussagen aus dieser Kategorie definieren die Ziele des Kunden.
Beispiele:
− Zur Unterstützung der wachsenden CAD-Arbeitsplatzrechnerumgebung
ist ein zentralisierter Benutzer-Service einzurichten
− Änderungen an Hard- und Software-Konfigurationen sind durch ein
Change Management zu unterstützen.
• Anforderungen an Service-Pakete und Service-Verträge
Stark serviceorientierte Kunden werden ihre Anforderungen an Systems
Management über Service-Pakete und -Stufenverträge definieren.
Service-Pakete definieren die Leistungen, die von Service-Anbietern zu
erbringen sind, um die Ausführung von Geschäftsanwendungen zu
unterstützen.
• Normen und Standards
Für die Durchführung eines SM-Projektes ist es von größter Bedeutung, den
Standpunkt des Kunden in Bezug auf Normen und Standards zu verstehen
und zu dokumentieren. Die im Rahmen des Design-Projektes zu
berücksichtigenden Normen und Standards sind zu dokumentieren.
Weitere mögliche Kategorien sind Verwaltungs-Topologien, Berücksichtigung von
Verwaltungsplattformen, Eigenschaften zukünftig oder gegenwärtig zu
verwaltender Systeme, Computersicherheit, Investitionsschutz und Standards.
Die SM-Prinzipien müssen nicht unbedingt alle aufgeführten Kategorien
abdecken. Der Designer muß anhand der zuvor in diesem Kapitel erörterten
Richtlinien die relevanten Kategorien bestimmen und die jeweiligen Prinzipien
dokumentieren.
Kapitel 4. Wie können Führungskräfte das Systems Management Design beeinflussen? 53

54 Systems Management Design - Ein Überblick

Kapitel 5. SM-Umgebung
Im vorigen Kapitel wurden die Prinzipien für ein Systems Management
Design-Projekt umrissen. Zweck dieses Kapitels ist es, das Augenmerk auf die
zu verwaltende operationale Umgebung zu richten. Design und Implementierung
der Geschäftsanwendungen bilden die „Operationale Umgebung″; sie besteht
aus Hardware, Software, Netzwerk und Organisationselementen, welche
zusammenwirken, um die Ausführung von Anwendungen zu ermöglichen. Diese
Elemente bezeichnet man als „Managed Elements″. Diese Elemente
repräsentieren den maximalen Grad der Auflösung einer operationalen
Umgebung in ihre einzelnen Bestandteile. Diese Auflösung erfolgt, um festlegen
zu können, welche Management-Funktionen auf diese Elemente angewendet
werden sollen.
Ganz am Anfang eines SMD-Projektes ist es von größter Bedeutung, die
operationale Umgebung, und insbesondere die IT-Infrastruktur, eindeutig zu
definieren. Die Definition der Management-Umgebung umfaßt:
• Definition und Eingrenzung des Umfangs der Management-Umgebung
Der erste Schritt bei der Definition der Management-Umgebung besteht in
der Definition des Umfangs dieser Umgebung. Die Fragen: „Was sollte
verwaltet werden?″ und „Was sollte nicht verwaltet werden?″ müssen
beantwortet werden.
• Einteilung der Elemente in Gruppen
Die Anzahl verschiedener Typen von Elementen und die Bandbreite der zu
verwaltenden Elemente kann sehr groß sein. Die Definition der einzelnen
Elementgruppen eröffnet die Möglichkeit, die zu verwaltenden Elemente zu
ordnen und dadurch den Design-Prozeß zu vereinfachen.
• Beschreibung der Management-Eigenschaften der Elementgruppen
Die quantitativen und qualitativen Management-Attribute der Elementgruppen
müssen bestimmt werden, um die Definition der zu verwaltenden Umgebung
zu vervollständigen.
Die Management-Eigenschaften der Elementgruppen bilden die Basis für die
nächsten Schritte des SMD-Prozesses, indem sie detaillierte und umfassende
Informationen über die Elemente und ihr Verhalten liefern. Diese Informationen
bestimmen, welche Management-Dienstleistungen erforderlich sind, sowie deren
Niveau und Qualität.
5.1 Umfang und Detailbehandlung der SM-Umgebung
Bevor die Einteilung der zu verwaltenden Elemente in Gruppen erfolgen kann,
müssen Umfang und Grenzen der Management-Umgebung bestimmt werden.
Der Terminus „Umfang″ bezeichnet die Definition der Komponenten (Systeme,
Software, Hardware, Netzwerkkomponenten, ...), aus denen die zu verwaltende
operationale Umgebung besteht, sowie die Menschen und Organisationen,
welche die bereitgestellten Management-Dienstleistungen nutzen werden.
Es muß eine Landkarte oder Topologie der operationalen Umgebung gezeichnet
werden, um das Ziel des SMD-Projektes zu veranschaulichen. Ist das nicht
möglich, müssen weitere Informationen eingeholt werden, bevor die
Design-Arbeit fortgesetzt werden kann.
© Copyright IBM Corp. 1996 55

Abbildung 23. Notwendigkeit einer klaren Definition der Management-Umgebung
56 Systems Management Design - Ein Überblick
Es gibt eine Reihe von Gründen dafür, warum es notwendig ist, zu einer klaren
Definition des Umfangs der Management-Umgebung zu kommen und schon in
einer sehr frühen Phase des SMD-Projektes eine Einigung über diese Definition
zu erzielen. Die wichtigsten Gründe und Faktoren sind:
• Es ist häufig der Fall, daß sich nicht alle Systeme einer operationalen
Umgebung unter der Kontrolle des Managements befinden, das die
Design-Arbeiten sponsort. Es ist durchaus möglich, daß substantielle
Bestandteile der Umgebung nicht zu der Management-Umgebung gehören.
• Die Topologien verteilter Systeme sind besonders komplex und es ist daher
erforderlich, die Grenzen dessen, was zu verwalten ist, klar abzustecken.
Wie diese Grenzen gezogen werden, steht in direkter oder indirekter
Beziehung zur Komplexität der benötigten SM-Lösung.
• Die vorhandenen Anwendungen sind der Schlüsselfaktor bei der Definition
der zu verwaltenden operationalen Umgebung. Es ist durchaus möglich, daß
nur eine ausgewählte Gruppe von im Einsatz befindlichen Anwendungen und
Ressourcen zu verwalten ist. Diese Gruppe von Anwendungen ist bereits in
der Anfangsphase zu bestimmen.
• Der Umfang der zu leistenden Arbeiten kann so groß und komplex sein, daß
es erforderlich ist, ihn aufzuteilen und separate Design-Unterprojekte für
separate Zielumgebungen zu definieren, um einen in Phasen unterteilten
Ansatz zur Erstellung des Gesamtdesigns zu ermöglichen.
• Der für Design und Implementierung der SM-Infrastruktur erforderliche
Arbeitsaufwand muß sich für den Kunden innerhalb der Grenzen des
Machbaren bewegen. Die Definition des Umfangs stellt einen groben
„Machbarkeitstest″ in der dafür geeigneten Phase des Design-Prozesses dar.
• Da es keine einzig mögliche und richtige Definition der Zielumgebung gibt,
ist es wichtig, daß zwischen Entwickler und Sponsor von Anfang an eine
Einigung darüber erzielt wird, was Bestandteil der zu verwaltenden
Umgebung ist und was nicht.

Die Festlegung klarer und eindeutiger Grenzen der Management-Umgebung ist
von entscheidender Bedeutung. Werden die Grenzen nicht von Anfang an
verstanden und gezogen, wird sich das Ziel während der Laufzeit des Projektes
verändern und somit nicht mehr kontrollierbar sein. Deshalb sind auch die
nachfolgenden Faktoren für die Definition der SM-Umgebung von höchster
Wichtigkeit.
Beschränkung der SM-Umgebung auf relevante Ressourcen
• Im Zeitalter des „autonomen Benutzers″ existiert eine sensible Balance
zwischen der Freiheit des Benutzers und den Kontrollmechanismen, die
nötig sind, um zu gewährleisten, daß ein Benutzer nicht unwissentlich zu
einem zerstörerischen Element wird. So kann es zum Beispiel erforderlich
werden, es den Benutzern zu gestatten, ihre eigenen Arbeitsplatzrechner zu
verwalten und gleichzeitig eine klare Grenze zwischen den
Arbeitsplatzrechnern und den von den Benutzern genutzten
Gemeinschaftsressourcen zu ziehen.
• Die Beziehung zwischen Geschäftszielen und den erforderlichen
Management-Prozessen wird in Kapitel 6, „Systems Management-Prozesse“
diskutiert. Bei Ressourcen, die in keiner direkten Beziehung zu diesen Zielen
stehen, ist die Implementierung eines hochentwickelten Verwaltungssystems
möglicherweise nicht zu rechtfertigen.
Umstände, die nur eine eingeschränkte Verwaltungskapazität zulassen
• Einige der für das Design der SM-Infrastruktur in Betracht gezogenen
Dienstleistungen werden von einigen Benutzergruppen womöglich weder
gefordert noch gewünscht.
• Auch wenn ein „Endpunkt-zu-Endpunkt″ Verwaltungsziel gesetzt wurde,
könnten einige der Komponenten innerhalb der operationalen Umgebung
nicht Bestandteil des Vorhabens sein; sie könnten z.B. ausgelagert sein.
Ausgelagerte Weitverkehrsnetze sind nicht ungewöhnlich. Es ist
möglicherweise nicht möglich, SM-Funktionen zur Überwachung dieser
Komponenten zu implementieren.
• In manchen Fällen machen physische und geographische Faktoren die
Verwaltung gewisser Komponenten der Infrastruktur undurchführbar.
5.2 Definition von Elementgruppen mit gleichen Management-Eigenschaften
Nachdem der Umfang der zu verwaltenden Umgebung bestimmt worden ist und
ihre Grenzen eindeutig gezogen sind, kann der Prozeß der Einteilung der
Umgebung in Gruppen zu verwaltender Elemente beginnen. Im Normalfall ist die
Zahl der einzelnen Elemente innerhalb der Umgebung relativ groß. So ist es
schwierig, wenn nicht gar unmöglich, eine SM-Infrastruktur um eine
unstrukturierte Ansammlung von Elementen herum aufzubauen. Der Sinn der
Definition von Elementgruppen und ihrer Bestückung mit einzelnen Elementen
liegt darin, Gruppen zu verwaltender Elemente mit gemeinsamen Eigenschaften
zu bilden. Diese Elementgruppen werden zu den Zielen, zu deren Erreichung die
ausgewählten SM-Prozesse angewendet werden.
Kapitel 5. SM-Umgebung 57

Abbildung 24. Elementgruppen aus unterschiedlichen Blickwinkeln
58 Systems Management Design - Ein Überblick
Die Unterteilung der zu verwaltenden Umgebung in Gruppen von zu
verwaltenden Elementen wird von der Sichtweise geleitet, die der Entwickler
wählt. Sichtweise steht hier für die Art und Weise, eine Ansammlung von
Elementen aus einer bestimmten Perspektive oder Position zu betrachten. Durch
diese Sichtweise entsteht eine Fokussierung, bei der die Ziele und Prioritäten
des Betrachters aus einer Ansammlung von Elementen geordnete
Elementgruppen machen.
Die Komponenten-Sichtweise ist die für IS-Fachleute vielleicht am leichtesten
verständliche. Sie repräsentiert den traditionellen informationstechnischen
Ansatz, eine operationale Infrastruktur zu beschreiben; diese Sichtweise steht für
den Blick von innen nach außen auf den Endbenutzer. Die Elemente in der
Zielumgebung werden gemäß der Funktionen, die sie bei der Datenverarbeitung
innerhalb der Infrastruktur ausüben, in Gruppen eingeteilt.
Basiskategorien, wie System- oder Computerknoten, Netzwerke und
Anwendungen, dienen als Ausgangspunkt. Diese Kategorien werden basierend
auf der organisatorischen Verantwortlichkeit und dem Eigentumsrecht noch
weiter unterteilt; eine bestimmte Gruppe innerhalb einer IS-Organisation kann
für die Verwaltung der fernen LANs verantwortlich sein, während eine andere
Organisation für die Hardware des zentralen Systems verantwortlich ist.

Beispiele für aus der Komponenten-Sichtweise definierte Elementgruppen sind:
• Hardware des zentralen Systems
− Großrechner
− Peripheriegeräte
• System-Software
− Betriebssysteme
− Middleware
• Netzwerk
− Netzwerkknoten
− Physische Übertragungseinrichtungen
Der Entwickler kann sich auch dafür entscheiden, die Elemente zu gruppieren,
indem er sich auf die Anwendungen des Kunden konzentriert und die
Anwendungs-Sichtweise benutzt. Wie die Bezeichnung bereits ausdrückt, wird
das Problem hier aus der Perspektive der Anwendungen betrachtet. Während
sich die Komponenten-Sichtweise von innen nach außen richtet, geht die
Anwendungs-Sichtweise von der Anwendung als stabilem Zentrum aus, um das
herum die Benutzer und die technische Infrastruktur angeordnet sind. Diese
Sichtweise ist häufig da anzutreffen, wo die Gruppe der Anwendungsentwickler
des Kunden großen Einfluß ausübt und wo Hilfsmittel der
Anwendungsentwicklung extensiv genutzt werden.
Bei dieser Sichtweise ist die Anwendung der Repräsentant einer homogenen,
stabilen Benutzergruppe. Die Ressourcen der IT-Infrastruktur, welche die
Anwendung unterstützen, werden bestimmt und entsprechend eingruppiert. Da
verschiedene Arten von Anwendungen den Einsatz unterschiedlicher Ressourcen
erfordern, spielen Anwendungsklassen eine wichtige Rolle bei der Definition der
Elementgruppen.
Die verteilte Client/Server-Anwendung ist ein Beispiel dafür, wie ein bestimmter
Anwendungstyp einen Satz verschiedener Elementgruppen definiert. Es gibt
Standardverfahren dafür, Client/Server-Anwendungen so zu gestalten, daß ihre
Funktionen verteilt werden können. Das gebräuchlichste Verfahren ist die
Unterteilung der Anwendung in folgende Komponenten:
• Präsentationslogik
• Unternehmensspezifische Logik
• Logik für den Zugriff auf Systemressourcen-Verwaltungen
Jede dieser logischen Komponenten erfordert den Einsatz einer Gruppe von
IT-Ressourcen; die jeweils erforderlichen Ressourcen werden für diese
Anwendungstypen als Elementgruppen definiert.
Kapitel 5. SM-Umgebung 59

Beispiele für derartige Elementgruppen sind:
• Client-Knoten
− Hardware (Arbeitsplatzrechner)
- Prozessor
- Festplatte
− Software
- Betriebssystem
- Anwendung
• Server-Knoten
− Hardware
− Software
• Netzwerk
− Adapter
− Hub
− Router
5.3 Management-Eigenschaften der Elemente
In diesem Stadium der Entwicklung ist der Umfang der Management-Umgebung
definiert worden und die zu verwaltenden Elemente wurden anhand
gemeinsamer Management-Eigenschaften in Gruppen eingeteilt. Die
Management-Eigenschaften der Elemente definieren den Input für das
SMD-Projekt, indem sie detaillierte und umfassende Informationen über die
Elemente und ihr Verhalten liefern. Diese Informationen bestimmen, welche
Management-Dienstleistungen erforderlich sind, sowie deren Niveau und
Qualität.
Abbildung 25. Management-Eigenschaften bestimmen die SM-Anforderungen
60 Systems Management Design - Ein Überblick

Die Management-Eigenschaften sind:
• Bedeutung
Die Bedeutung einzelner Elemente kann dadurch bestimmt werden, daß man
die Auswirkungen des Fehlens eines Elemente auf die Geschäftsabläufe
analysiert, die Anzahl der vom Fehlen eines Elementes betroffenen Benutzer
ermittelt, und die Anforderungen an Verfügbarkeit und Wiederherstellung
untersucht.
• Komplexität
Die Komplexität von Elementen wird bestimmt durch die Anzahl an
Funktionen, die ein Element ausführen kann, durch die Anzahl der Teile, die
ein Element umfaßt, und dadurch, wie schwierig diese Elemente
möglicherweise zu handhaben sind.
• Verteilung
Die Verwaltung von Elementen, die über verschiedene Orte, Organisationen,
Zeitzonen, oder sogar unterschiedliche Kulturen verteilt sind, kann eine
große Herausforderung darstellen.
• Größe und Volumen
Die Größe von Elementen ist ein Problem mit diversen, unterschiedlichen
Aspekten, zu denen die Anzahl der zu verwaltenden Elemente, die
verschiedenen Arten von Elementen, und ihre physische Größe zählen.
• Eigentumsrechte
Das Eigentumsrecht an Elementen ist unter verschiedenen Gesichtspunkten
zu betrachten: Wer zahlt für das Element? Wer besitzt es gegenwärtig? Wer
verwaltet es? Hierbei kann es sich jeweils um dieselbe Person und
Organisationseinheit handeln oder auch um verschiedene Personen und
Organisationseinheiten.
• Managementverhalten
Diese Eigenschaften liefern Informationen über die geforderten
Management-Funktionen und über die Qualität der erforderlichen
Management-Services.
• Abgrenzung
Die Grenzen des Managements definieren zwei Mengen von Attributen.
Einerseits die Management-Domäne, die eine Menge verwalteter Elemente
als Einheit für eine oder mehrere Mengen von Prozessen definiert. So kann
zum Beispiel eine LAN-Arbeitsgruppe eine Management-Domäne darstellen,
wenn sie als Einheit verwaltet wird, wie auch eine Menge von Host-Systemen
mit der dazugehörigen Hardware und Software eine Management-Domäne
bilden kann.
Die zweite Attributenmenge ist die Management-Tiefe. Komplexe Elemente,
wie z. B. Arbeitsplatzrechner, können bis hinunter zu einzelnen
Hardware-Teilen wie Speicherchips, Karten in Erweiterungssteckplätzen oder
Software-Elementen wie auch einzelnen Anwendungen verwaltet werden.
Bestimmte Fragenstellungen zur erforderlichen Management-Tiefe sind
hilfreich, um den exakten Umfang einer zu verwaltenden Umgebung und die
geforderten Management-Funktionen zu bestimmen.
Kapitel 5. SM-Umgebung 61

• Dynamik der Umgebung
Dynamische Umgebungsfaktoren sind eine Schlüsseleigenschaft moderner,
verteilter Umgebungen, bei denen die Anzahl der zu verwaltenden Elemente
sehr schnell zunimmt. Der Systemaufbau ist in sehr vielen Fällen
hauptsächlich auf die ursprüngliche Umgebung ausgerichtet und tendiert
dazu, die Tatsache zu vernachlässigen, daß geplante und ungeplante
Änderungen eintreten werden, die es zu verwalten gilt.
• Abhängigkeit
Diese Eigenschaft berücksichtigt die Abhängigkeit einzelner Elemente von
anderen Elementen oder Elementgruppen.
• Sicherheitsanforderungen
Die operationale Umgebung kann nur dann als sicher betrachtet werden,
wenn alle Elemente die gleiche, erwünschte und erreichbare Sicherheitsstufe
aufweisen. Sicherheitsanforderungen sind ein Gesichtspunkt, der beim
Systemaufbau oft vernachlässigt wird.
• Heterogenität
Die operationalen Umgebungen der heutigen Zeit sind heterogen, wobei der
Grad der Heterogenität einen großen Einfluß auf die Ergebnisse des
IS-Management Designs hat.
• Wissensstand und Ausbildung
Das Management von Elementen erfordert gewisse Ffähigkeiten. Die damit
verbundenen Schwierigkeiten werden bestimmt durch das geforderte
Befähigungsniveau und die Anzahl der Menschen, die erforderlich ist, um die
Elemente zu verwalten. Mit dem Management von Elementen sind zwei
Personengruppen beschäftigt: Benutzer und Systembediener. Einige
Management-Aufgaben werden von den Benutzern der Ressourcen
wahrgenommen, wie z.B. das Einschalten, die Papierzufuhr, und andere
Tätigkeiten. Komplexere Management-Aufgaben werden von
Systembedienern mit der entsprechenden Befähigung ausgeführt. Zu diesen
Aufgaben gehören beispielsweise das Management von lokalen oder
Weitverkehrsnetzen, die Steuerung der Leistung von Netzwerken und
Servern.
• Normen und Standards
Normen und Standards können das Management von Elementen erheblich
erleichtern.
• Neue Technologien
62 Systems Management Design - Ein Überblick
Das Management von Elementen, bei denen neue Technologien zum Einsatz
kommen, stellt häufig eine große Herausforderung dar, da entsprechende
Management-Methoden, Standards, und Erfahrungen noch nicht existieren.
Die Management-Eigenschaften müssen analysiert werden, um die
erforderlichen Management-Dienstleistungen zu definieren. So bestimmen zum
Beispiel die dynamischen Umgebungsfaktoren die Anforderungen an das Change
Management; die Bedeutungseigenschaften definieren die Ziele im Hinblick auf
Verfügbarkeit, Sicherung und Wiederherstellung.
Das Niveau der Management-Dienstleistungen bestimmt die Funktionalität, das
heißt, welches Element durch welche Menge von SM-Prozessen bedient wird. So
kann zum Beispiel der Prozeß Änderungen verteilen die Verteilung von

Anwendungsprogrammen an einen Arbeitsplatzrechner umfassen, aber das
Betriebssystem ausschließen.
Die Kombination der Management-Eigenschaften definiert die erforderliche Reife
des Management-Prozesses. Wurden die dynamischen Umgebungsfaktoren
beispielsweise als extrem schwierig beurteilt, oder ist die Bedeutung der
Elemente wichtig oder sogar sehr wichtig, muß die Reife der Change
Management Prozesse sehr fortgeschritten sein, um die geforderte
Dienstleistungsqualität zu erreichen.
In unterschiedlichen Umgebungen sind manche Management-Eigenschaften von
größerer Bedeutung als andere. Es ist in diesem Zusammenhang hilfreich, den
Eigenschaften vor der Beurteilung Prioritäten zuzuweisen, um Eigenschaften
hoher Priorität mehr Gewicht zu verleihen. In den meisten Fällen sind die
Prioritäten leicht zu bestimmen, wenn der Entwickler die entsprechende
Umgebung kennt.
Kapitel 5. SM-Umgebung 63

64 Systems Management Design - Ein Überblick

Kapitel 6. Systems Management-Prozesse
Nachdem die zu verwaltenden Elemente und Systeme unter Anwendung der in
vorhergehenden Kapiteln dargestellten Techniken bestimmt worden sind, besteht
der nächste Schritt bei der Schaffung eines Systems Management Designs
(SMD) darin, SM-Prozesse auszuwählen und zu bewerten. Das Ziel ist,
festzulegen, welche Prozesse geändert oder verbessert werden müssen, um die
geplanten Änderungen von IT-Anwendungen und -Systemen zu unterstützen und
diesen Verbesserungen Prioritäten zuzuordnen.
6.1 Prozeßorientierung oder Ressourcenorientierung
Die von uns im Rahmen des Systems Management vorgeschlagene,
grundsätzliche Vorgehensweise ist eher prozeßorientiert als
ressourcenorientiert. Die nachstehenden Ausführungen sind eine
Zusammenfassung dieser Vorgehensweise und ihrer Vorteile.
Abbildung 26. Prozeßorientiertes Systems Management
Führende IT-Anbieter rücken mehr und mehr von einer Verwaltungsstruktur ab,
die auf den zu verwaltenden Hardware- oder Software-Ressourcen basiert. Das
heißt, daß Anbieter von Systems Management in der Vergangenheit häufig
gemäß ihres technischen Fachwissen gruppiert waren, was in vielen Fällen zu
einer Duplizierung der Prozesse geführt hat.
Das hat zu einer Vervielfältigung der Prozesse und damit verbundenen
Effektivitätsverlusten geführt. Ist es zum Beispiel das Ziel eines Unternehmens,
sicherzustellen, daß seine operationale Umgebung sicher ist, besteht die
effektivste und umfassendste Vorgehensweise darin, den Aspekt der Sicherheit
© Copyright IBM Corp. 1996 65

6.2 Auswahl der SM-Prozesse
für alle Ressourcen gleichzeitig zu beleuchten, anstatt separate,
ressourcenspezifische Anstrengungen zu unternehmen und die
Sicherheitseinrichtungen zu untersuchen, die auf jede Ressource einzeln
angewendet werden könnten.
Die letztgenannte Vorgehensweise würde mit hoher Wahrscheinlichkeit zu einer
Situation führen, in der einzelne Teile einer Umgebung extrem sicher wären, es
aber andererseits auch Schwachpunkte gäbe. Gilt die Konzentration einer
„ Endpunkt-zu-Endpunkt″ Sicherheit, wird von Anfang an ein angemessenes
Sicherheitsniveau etabliert, was bedeutet, daß es an sicherheitsrelevanten
Stellen eines Systems wahrscheinlich keine Schwachpunkte geben wird.
Durch eine prozeßorientierte Organisation von Systems Management, kann ein
großes Potential an gesteigerter Effektivität und Effizienz erschlossen werden.
Andere potentielle Vorteile werden in Abb. 26 auf Seite 65 dargestellt.
Es ist sehr unwahrscheinlich, daß im Rahmen eines SM-Projektes alle möglichen
SM-Prozesse implementiert werden müssen oder implementiert werden können.
Manche Prozesse werden nicht benötigt oder haben eine niedrige Priorität. Die
Implementierung aller SM-Prozesse würde die Fähigkeiten der IS-Organisation
übersteigen.
Der erste Schritt besteht darin, die in Betracht kommenden Prozesse
auszuwählen. Das geschieht auf der Grundlage der Anforderungen an die
SM-Umgebung. So ist z.B. bei einer verteilten Umgebung das Change
Management ein Kandidat für diese Prozess-Auswahl.
In vielen Fällen gibt es eine vom Kunden aufgestellte Wunschliste der zu
implementierenden Prozesse. So kann beispielsweise ein zentralisierter
Benutzer-Service gefordert werden. Die tatsächlichen
Implementierungsprioritäten werden jedoch zu einem späteren Zeitpunkt
festgelegt.
6.3 Bewertung der bereits existierenden Prozesse
66 Systems Management Design - Ein Überblick
Es gibt nur selten Fälle, in denen ein Kunde mit dem Aufbau einer
IT-Infrastruktur bei Null beginnt und der SM-Designer sich nicht mit einer bereits
existierenden Umgebung befassen muß. SM-Prozesse sind normalerweise
bereits vorhanden und ihre Leistungsfähigkeit muß berücksichtigt werden. Es ist
eine Bewertung dieser vorhandenen SM-Prozesse erforderlich, um die
Implementierungsprioritäten für die ausgewählten Prozesse festzulegen.
Diese Bewertung der Prozesse muß die folgenden Aspekte der
Prozeßimplementierung umfassen:

• Das Prozeßgerüst
Für einen Prozeß müssen Ziele gesetzt werden, deren Verwirklichung
meßbar ist. Die Prozeßschritte müssen definiert, dokumentiert und
verstanden werden.
• Der Prozeß selbst und seine Schnittstellen zu anderen Prozessen
Ein Prozeß muß sowohl effektiv als auch effizient sein. Wechselnde
Anforderungen machen es erforderlich, daß ein Prozeß anpassungsfähig ist.
Es müssen effektive Schnittstellen zu anderen Prozessen eingerichtet
werden.
• Klarheit und Fähigkeit der Organisation
Rollen und Verantwortlichkeiten sind zu definieren und der gesamten
Organisation zu vermitteln. Alle beteiligten Personen müssen über die
Fähigkeit verfügen, ihre Rollen auszufüllen.
• Hilfsprogramme
Um die Durchführung von Prozessen zu veranlassen und zu unterstützen,
müssen die entsprechenden Hilfsprogramme zur Verfügung stehen. Diese
Hilfsprogramme sollten einsatzfähig, integriert und offen sein; sie sollten zu
einer maximalen Automatisierung führen.
• Meßbarkeit und Kontrolle
Effektivität und Effizienz von Prozessen können nur gewährleistet werden,
wenn sie gemessen und dokumentiert werden. Außerdem sind die Prozesse
so anzupassen und zu verbessern, daß sie den Anforderungen einer sich
verändernden Umgebung gerecht werden.
Die Ergebnisse einer sorgfältigen Prozeßbewertung bilden die grundlegenden
Daten für die Definition von Prozeßprioritäten bei der Implementierung.
6.4 Prozeßprioritäten bei der Implementierung
Während der Prozeßbewertung können Empfehlungen gesammelt worden sein.
Der nächste Schritt besteht darin, potentielle Projekte zu sichten und auf der
Grundlage der bisher gesammelten Fakten und Ergebnisse gewisse Prioritäten
für deren Implementierung zu etablieren. Auswahl und Setzung von Prioritäten
im Hinblick darauf, welcher Management-Prozeß verbessert werden muß,
gehören zu den schwierigsten Problemen des Systems Management Design.
Wie zuvor bereits festgestellt, müssen nicht alle Verwaltungssysteme höchstes
Niveau haben, um die geforderte Qualität der Verwaltung für eine bestimmte
Umgebung von Informationssystemen zu erreichen. Wie soll man also die
Prioritäten setzen, wenn Verbesserungen empfohlen werden, oder wenn
festgesetzt werden soll, welche Prozesse implementiert werden? Einfache
Antworten auf diese Fragen gibt es nicht. Hier können Befähigung, Erfahrung,
Urteilsvermögen und gesunder Menschenverstand eines SM-Beraters oder
-Entwicklers im allgemeinen nicht durch eine „Gebrauchsanleitung″ ersetzt
werden.
Die nachstehenden Analysetechniken können helfen, Empfehlungen abzugeben
und Prioritäten für die Implementierung bestimmter Prozesse zu setzen. Bei der
Festlegung von Implementierungsprioritäten können eine oder mehrere dieser
Techniken angewendet werden.
Kapitel 6. Systems Management-Prozesse 67

6.4.1 Analyse basierend auf der Beziehung zu Management-Eigenschaften
Diese Technik kommt zur Anwendung, wenn eine Analyse dieser Eigenschaften,
wie in 5.3, „Management-Eigenschaften der Elemente“ dargestellt, vorgenommen
wurde. Die gesammelten Informationen können dazu genutzt werden, auf den
wahrscheinlichen SM-Prozeß zu verweisen, der die aufgedeckten Eigenschaften
aufweist.
6.4.2 Analyse des Zieles eines SM-Prozesses
Diese Analyse kommt zur Anwendung, wenn das Ziel der von Ihnen
angestrebten SM-Prozesse festgesetzt und eine Prozeßbewertung durchgeführt
wurde, um die Fähigkeiten des Kunden im Bereich des Systems Management zu
bestimmen. Das Ergebnis der Prozeßbewertung wird mit den tatsächlich
erzielten Prozeßergebnissen verglichen. Kandidaten für eine Implementierung
sind solche Prozesse, bei denen sich das gesteckte Ziel und die vorhandenen
Fähigkeiten nicht im Gleichgewicht befinden.
6.4.3 Analyse des Nutzens einer Anwendung
Diese Analyse wird durchgeführt, wenn Sie die Anforderungen an das Systems
Management in Beziehung zu der zu unterstützenden Anwendung setzen wollen.
Befindet sich der Kunde in einer Situation, in der er die Effektivität des Systems
Management verbessern muß, um eine neue Anwendung zu unterstützen, wie
z.B. eine neue Client/Server-Anwendung, kann der mit der Implementierung
dieser Anwendung verbundene Nutzen untersucht werden. Diese Vorteile können
dann verwendet werden, die Art der erforderlichen Systems Management
Unterstützung zu bestimmen und zu gewährleisten, daß der besagte Nutzen
tatsächlich eintritt.
6.4.4 Analyse der wechselseitigen Abhängigkeiten zwischen Prozessen
68 Systems Management Design - Ein Überblick
Diese Analyse wird in jedem Fall durchgeführt.
Wie bei allen Arten von Prozessen, gibt es auch bei SM-Prozessen gewisse
Wechselbeziehungen. Diese können in vielen Fällen genutzt werden, um die
Grundvoraussetzungen zu bestimmen oder die Abhängigkeiten zwischen den
Prozessen zu ermitteln. Das folgende Diagramm stellt zwei Abhängigkeiten dar:

Abbildung 27. Analyse der Abhängigkeiten zwischen SM-Prozessen
Wie in dem Diagramm dargestellt, erfordert ein effektiver Implementierungsänderungsprozeß,
bei dem möglicherweise Software auf Hunderte verteilt
installierte Server verteilt wird, folgendes:
• Einen effektiven und effizienten Prozeß des Change Managements, um die
Etablierung von Verteilungsprioritäten zu erleichtern, die geschäftlichen und
technischen Auswirkungen zu analysieren, und einen vernünftigen Zeitplan
aufzustellen.
• Gute Planung und die Zuweisung von Verantwortungsbereichen an das
Personal (Planaufstellungsprozeß).
• Einen exakten Datenbestand über die Systemkonfiguration, um zu
gewährleisten, daß die Software an die richtigen Empfänger ausgeliefert wird
(Prozeß zur Pflege der Konfigurationsinformationen).
In ähnlicher Art und Weise wird der Benutzer-Service (Help Desk) Anrufe
erhalten, welche die Erörterung von Problemen erforderlich machen. Es muß
daher ein effektiver Prozeß des Problem Managements existieren, um diese
Probleme schnell und effektiv protokollieren und lösen zu können und somit zu
gewährleisten, daß die „Betriebsunterstützung″ wirklich wirksam ist.
Es gibt zwischen den einzelnen Prozessen auch noch andere Verbindungen, die
untersucht werden sollten, um die Prozeßprioritäten besser festlegen zu können.
Es ist offensichtlich, daß vom Kunden ausdrücklich geforderte Prozesse höchste
Priorität genießen sollten.
Kapitel 6. Systems Management-Prozesse 69

6.4.5 Analyse basierend auf der Durchführbarkeit eines Prozesses
Diese Analyse wird in jedem Fall durchgeführt.
Es können Situationen entstehen, in denen ein bestimmter Prozeß oder ein
Aspekt eines Prozesses nicht durchführbar oder unpraktisch ist. Die Umstände
jeder Situation sind einzigartig. Es ist daher unmöglich, eine Methode zur
Durchführung einer Machbarkeitsanalyse zu entwickeln.
6.4.6 Analyse auf der Grundlage eines konkreten Falles
70 Systems Management Design - Ein Überblick
Diese Form der Analyse kommt in den meisten Fällen zur Anwendung.
Kann durch einen Prozeß, oder auch nur durch einen Aspekt eines Prozesses,
ein offensichtlicher Nutzen erzielt werden, der potentiell größer ist als der, bei
der Implementierung eines anderen Prozesses zu erwartende Nutzen, ist dieser
Nutzen der Leitfaden für die Etablierung der entsprechenden Prioritäten.
Bewirkt beispielsweise die Konsolidierung verschiedener Benutzer-
Serviceeinrichtungen eine Personaleinsparung, oder die Verbesserung der den
Endbenutzern gebotenen Dienstleistungen, so kann das der beste Ansatzpunkt
für die zu leistende Arbeit sein. Bewirkt die Zentralisierung operationaler
Aktivitäten, daß auf der Benutzerseite LAN-Administratoren gar nicht mehr oder
nur noch in geringerer Zahl benötigt werden, so kann dieser Aspekt der beste
Ansatzpunkt sein. Bewirkt eine Verbesserung der Qualität des Benutzer-Services
eine Reduzierung der von den Benutzern für die Problemlösung benötigten Zeit,
wodurch sie mehr Zeit für eine sinnvolle Unterstützung der geschäftlichen
Aktivitäten ihres Unternehmens aufbringen können, so genießt möglicherweise
die Verbesserung des Benutzer-Services die höchste Priorität.

Kapitel 7. Ausblick
Wir leben in einer sich ständig verändernden informationstechnischen
Umgebung: die Software-Industrie spielt die führende Rolle bei dieser
technologischen Revolution, da gewerbliche Benutzer bestrebt sind, die
Plattformen für Anwendungen einander anzugleichen und zu optimieren, um in
einer Welt der zentralisierten, verteilten und persönlichen Systeme eine höhere
Kostenrentabilität, verbesserte Kommunikation und eine gemeinsame Nutzung
von Informationen zu erreichen. Die Entwicklung von entsprechender
Systemsoftware und Middleware wird als entscheidend für den Erfolg dieses
Prozesses angesehen.
Das explosive Wachstum auf dem Gebiet neuer, fortschrittlicher
Informationstechnologie wird die Unternehmen dazu zwingen, formalisierte
Bewertungsverfahren für Auswahl und Einsatz neuer Technologie einzuführen.
Die bedeutendsten neuen Technologien werden aus Interaktionen zwischen den
bereits existierenden Technologien entstehen, wobei das Hauptaugenmerk
darauf liegen wird, Informationsverarbeitung
anschaulicher,
übertragbarer,
variabler,
transparenter,
hilfreicher und
adaptiver
zu gestalten.
In dieser komplexen Umgebung wird das Systems Management auch in der
nahen Zukunft eine organisatorische und technische Herausforderung bleiben.
Diese Umgebungen reflektieren und schaffen komplexe organisatorische und
soziale Strukturen, die zu immer höheren Anforderungen an die
Leistungsfähigkeit von Netzen und verteilten Systemen führen werden. Die
Verwaltung dieser komplexen Strukturen wird die größte Herausforderung bei
zukünftigen verteilten Informationssystemen darstellen.
7.1 Geschäftliche Strategien und Anwendungen
Die Unternehmensstrukturen werden sich von einem hierarchischen Aufbau mit
Betonung des Funktionalen lösen. Stattdessen werden sie sich zu
Organisationsformen entwickeln, die eine geringere Zahl hierarchischer Ebenen
haben. Die besondere Betonung liegt dabei auf funktionsübergreifender
Teamarbeit.
Die Beziehungen zwischen Unternehmen werden sich auch weiterhin verändern.
Die Entwicklung wird dabei weg von Selbstgenügsamkeit und hausinternen
Lösungen und hin zu einem hochentwickelten System wechselseitiger,
weltweiter Abhängigkeiten gehen.
Die Infrastrukturen von Informationssystemen werden diesen ständigen
Veränderungen angepaßt werden müssen, um den komplexen informationellen
Beziehungen Rechnung zu tragen, die sich aus der veränderten geschäftlichen
Umgebung ergeben werden.
© Copyright IBM Corp. 1996 71

72 Systems Management Design - Ein Überblick
Einige der Veränderungen, die sich auf das Systems Management auswirken,
sollen nachstehend genannt werden:
• Die zu verwaltende Datenmenge wird immer größer
Es wird erwartet, daß sich die von einem Unternehmen gesammelte und zu
verwaltende Datenmenge erheblich vergrößern wird. Dabei werden die
wichtigsten Daten wahrscheinlich so weit wie möglich zentralisiert werden,
aber innerhalb der gesamten Unternehmensstruktur werden noch weitere
große Datenmengen existieren.
Auch die Art der Daten wird sich verändern; Form und Inhalt der Daten
werden von großer Bedeutung sein. Die Verfügbarkeit von
Informationsquellen, wie zum Beispiel Internet, wird zu einem
explosionsartigen Anstieg der Datenmengen führen. Das Internet und andere
firmenfremde Datenquellen werden die Verfügbarkeit von Marktinformationen
erhöhen. Somit werden Bewertung und Schutz dieser Daten in den nächsten
Jahren zu einer ständig wachsenden Herausforderung. Wichtige Daten
werden in einer sicheren und vertrauenswürdigen Umgebung gespeichert
werden, während weniger wichtige Daten überall verfügbar sind.
• Es entsteht die Notwendigkeit einer gemeinsamen Nutzung funktionsübergreifender
Informationen
Da sich die Anzahl der Datenquellen vervielfachen wird, und die Benutzer
wichtiger Daten über das gesamte Unternehmen verteilt sein werden,
werden überall im Unternehmen Daten existieren und verfügbar sein.
Dadurch wird es mehr und mehr von entscheidender Bedeutung sein, nicht
nur zu verstehen, was wo verfügbar ist, sondern auch Mechanismen zu
etablieren, die vorhandenen Daten effektiv verteilen und die gemeinsame
Nutzung ermöglichen.
• Der abteilungsübergreifende Zugriff auf Anwendungen wird zur Normalität
werden
Mit steigender Abhängigkeit von Daten, und einer immer weiteren
Verbreitung von Anwendungsfunktionen über das gesamte Unternehmen,
wird es mehr und mehr erforderlich sein, daß Benutzern Möglichkeiten
geboten werden, über Server oder Arbeitsplatzrechner anderer Benutzer auf
Anwendungen zuzugreifen. Das wäre eine echte Client/Server-Umgebung,
denn ein entscheidender Aspekt der Client/Server-Architektur liegt in den
Anforderungen in bezug auf multiple Anwendungen.
Das geeignete Modell besteht darin, daß eine Vielzahl von Benutzern auf
eine Vielzahl von Funktionen zugreifen kann, und sowohl Benutzer als auch
Funktionen sich einer Vielzahl von Datenbanken bedienen können. Es muß
daher eine „Viele-zu-Viele″ Beziehung zwischen Servern und Clients
unterstützt werden. Jeder Server muß in der Lage sein, mehrere Clients
gleichzeitig zu unterstützen. Jeder Client muß die Fähigkeit besitzen,
gleichzeitig mehrere Anfragen an Server zu richten. Dieses ist die komplexe
Client/Server-Welt, auf die eine IT-Infrastruktur ausgerichtet sein muß.
• Anbieter von Produkten und Dienstleistungen brauchen gezielte
Kundeninformationen (z.B. Name, Firmensitz und -geschichte)
Der führende Anbieter möchte in der Lage sein, einen Kunden für die
gesamte Palette der angebotenen Dienstleistungen als Einheit zu
identifizieren und zu behandeln. Das heißt, daß heutzutage der Kunde eines
typischen Großunternehmens nicht mehr als einzelne Person betrachtet
wird. Jede Abteilung eines Unternehmens kennt zwar den Kunden, aber eine

gemeinsame und umfassende Bewertung des Kunden, die es ermöglichen
würde, die wirklichen Bedürfnisse des Kunden aus einem breiten Spektrum
potentieller Dienstleistungen zu ermitteln, ist häufig nicht verfügbar. In vielen
Fällen kann ein Unternehmen solche Informationen nicht nutzen, um ein
Produkt aus seiner Angebotspalette gezielt zu fördern, welches zu einem
bestimmten Kunden passen würde, der aber nur von einer bestimmten
Abteilung des Unternehmens ermittelt werden kann.
• Anbieter werden Informationen zum Bestandsstatus für automatische
Nachbestellungen nutzen
Firmenübergreifender Handel wird zunehmend mit einfacheren Prozessen
und in weniger Schritten durchgeführt werden. Ein Anbieter wird einem
anderen also direkt Produkte und Dienstleistungen liefern, wobei der
Anbieter dafür verantwortlich ist, den möglichen Bedarf für seine Produkte
zu ermitteln und die Nachbestellung von Mengen zu gewährleisten, die
ausreichend sind, um den Kunden auch weiterhin angemessen beliefern zu
können.
• Kunden der relevanten Firmen brauchen umfangreiche Informationssysteme,
welche Daten bereitstellen für:
− Korrekte Rechnungsstellung für gelieferte Produkte und Dienstleistungen
− Schnelle Kontenabfrage
− Statusinformationen zu Fortschritten (Anforderungen und Bedürfnisse)
Um das obige Thema fortzuführen, kann gesagt werden, daß die klassische
Rechnungsstellung für erbrachte Dienstleistungen in vielen Fällen entfallen
wird. Der Kunde zahlt dann vielleicht nur für die Produkte eines Anbieters,
die er tatsächlich benutzt, statt in Rechnung gestellte Produkte zu erhalten,
abzustimmen und dann zu bezahlen.
Bei den Kunden steigt das Bewußtsein über die aktuelle Marktsituation.
• Die Bedeutung der Technik für ihr Geschäft nimmt zu
Die fortschrittlichsten Unternehmen sind sich bereits der Tatsache bewußt,
daß die Nutzung der Informationstechnologie einer der Schlüsselfaktoren für
das Erreichen von Wettbewerbsvorteilen mit Blick auf das Jahr 2000 ist.
• Um die geforderten Lösungen bieten zu können, sind ein oder mehrere
Partner erforderlich
Die Datenautobahn (möglicherweise Internet) wird sofortige Allianzen
zwischen diversen Anbietern von Dienstleistungen ermöglichen. Zum
Beispiel: ein Unternehmen erfindet die Produkte, geht eine Partnerschaft mit
einer örtlichen Universität ein (die durch direkte Verbindungen möglich wird),
um die Online-Weiterentwicklung von Produkten und Dienstleistungen (über
Internet) zu gewährleisten, nimmt eine Werbeagentur unter Vertrag und
kommuniziert mit Vertriebsunternehmen, und das alles über die
Datenautobahn.
Bei anderen Geschäftsvorgängen können die Partner dieser Allianz
Konkurrenten sein, sofern es sich um eine andere Gruppe von Produkten
oder Dienstleistungen handelt.
• Lösungen müssen schneller und zu geringeren Kosten erarbeitet werden
Die Herausforderung an das Systems Management liegt darin, ein
Unternehmen in die Lage zu versetzen, diese Ziele zu erreichen, ohne
unangemessen viel Zeit für die Einrichtung und effektive Nutzung neuer
Technologien aufwenden zu müssen.
Kapitel 7. Ausblick 73

7.2 IT-Strategien und -Anwendungen
74 Systems Management Design - Ein Überblick
IT-Organisationen werden sich sowohl an diverse geschäftsstrategische
Paradigmenwechsel, als auch an schnelle technologische Veränderungen
anpassen müssen und sich der Tatsache der Wiedergeburt der zentralisierten
Informationstechnologie durch den erneuten Einfluß auf die Verwaltung verteilter
Systeme, verteilter Netze und die Datenverwaltung bewußt sein. Dadurch steigt
die Belastung des IT-Anbieters im Hinblick auf Verwaltung und Betrieb von
Anwendungen, Datenspeicherung und Benutzerunterstützung innerhalb eines
Unternehmens.
Die IT-Unternehmen, die sich an die Entwicklung anpassen und
außergewöhnliche Dienstleistungen anbieten, werden in ihrer Branche eine
Spitzenstellung einnehmen. Die Unternehmen, die diesen Anpassungsprozeß
nicht vollziehen wollen oder können, werden sich dem Wettbewerb mit
Unternehmen ausgesetzt sehen, die mit ihren Produkten Weltmaßstäbe setzen
und von diesen wahrscheinlich vom Markt verdrängt werden. Viele Experten
sagen voraus, daß mehr als 95% der IS-Organisationen bis zum Jahr 2000 einige
ihrer Dienstleistungen von Dritten beschaffen werden.
Nachstehend einige Gedanken zur Rolle von mit Informationssystemen befaßten
Organisationen in einer raschen Veränderungen ausgesetzten Welt des
Geschäfts und der Informationstechnologie:
• Ständige Anpassung an neue Technologien
Der Prozeß der technologischen Änderungen und Neuerungen schreitet
immer schneller voran und ist in keiner Branche so ausgeprägt wie auf dem
Gebiet der Informationstechnologie. Keine andere Produktgruppe hat eine so
kurze Lebensdauer am Markt wie ein PC oder seine Bauteile.
Es ist daher das Gebot der Stunde, sich ständig die neueste Technologie zu
Nutzen zu machen, um nicht den Anschluß zu verlieren. Andernfalls wird
sich ein anderes Unternehmen dieser neuesten Technologie bedienen und
einen Wettbewerbsvorteil erreichen.
Die bisherige Technologie wird nicht notwendigerweise obsolet, aber die
Phantasie derjenigen, die Anwendungsbereiche für neue Technologie finden,
wird auch weiterhin neue Chancen oder Vorteile eröffnen. Dadurch werden
Unternehmen, die wettbewerbsfähig bleiben wollen, gezwungen, sich ständig
an IT-Dienstleistungen anzupassen, die von denjenigen kreiert werden,
welche die entsprechende Vorstellungskraft besitzen, Anwendungsmöglichkeiten
für existierende und neue Technologien zu finden.
• Ausrichtung der Infrastruktur auf schnell zunehmende Komplexität
Die Komplexität von Lösungen erfordert eine Infrastruktur, die dieser
Komplexität Rechnung trägt, um komplexe Lösungen umsetzen zu können,
ohne die gesamte Ausrichtung der bestehenden Infrastruktur verändern zu
müssen und somit die für Technologie getätigten Investitionen zu schützen.
• Definition einer Architektur, durch die Technologie organisiert wird
Eine Architektur, die sich auf entsprechende Strategien, Standards und die
Aufmerksamkeit des Managements stützen kann, wird das Rückgrat eines
intelligenten und beständigen Einsatzes neuer Technologie sein. Gleichzeitig
wird sie flexibel genug sein, um sich neuen Chancen und Möglichkeiten für
den Einsatz von Systemen und Netzen anzupassen. Veränderungen müssen
nicht um ihrer selbst Willen in die Praxis umgesetzt werden, sondern wegen

des damit verbundenen Nutzens. Ohne eine solche Infrastruktur, die
Durchführung von Veränderungen ohne Brüche im System gestattet, wird
solch ein Nutzen nicht tatsächlich realisiert, sondern nur vorschnell gesucht.
• Errichtung einer Infrastruktur zur sinnvollen Organisation der
Personalressourcen
Personal, Benutzer und Informationstechnologie müssen eingebunden
werden. Die Management-Perspektive von Technologie als Mittel zum Zweck
ohne Berücksichtigung der Auswirkungen auf den Benutzer erzielt
womöglich nicht den gewünschten und wahrscheinlich möglichen Effekt.
• Investition in zeitsparende Hilfsprogramme für den Endbenutzer
Das Management eines Unternehmens muß sich der Tatsache bewußt
werden, daß SM-Lösungen häufig größere Investitionen erfordern, als
ursprünglich angenommen.
• Begrenzung der Komplexität für den Endbenutzer durch Einschränkung der
Wahlmöglichkeiten
Eine Partnerschaft zwischen Benutzer und IT-Anbieter, bei der Benutzer die
geschäftliche Perspektive und der IT-Anbieter die auf gesundem
Menschenverstand beruhende technische Perspektive beisteuert, wird sich
als die erfolgreichste herausstellen. In vielen Fällen wird es die Aufgabe des
IT-Beraters sein, dem Benutzer zu vermitteln, daß eine Verringerung der
Anforderungen an die Benutzerunterstützung am besten zu erreichen ist,
indem die Anzahl oder die Vielfalt der Typen der zu verwaltenden
Komponenten beschränkt wird.
Die Informationstechnologie sollte auch den Kostenfaktor nicht aus den
Augen verlieren. Hierbei sind die Studien zu berücksichtigen, die besagen,
daß die ursprünglichen Anschaffungskosten für Hardware und Software
normalerweise weniger als 20% der während der gesamten Nutzungsdauer
auftretenden Kosten ausmachen.
• Investitionen in Mitarbeiterschulung
Derartige Investitionen werden häufig nicht eingeplant und das Ergebnis ist,
daß die Schulung durch gleichrangige Mitarbeiter vorgenommen wird, was in
vielen Fällen hohe, aber versteckte Kosten für das Unternehmen zur Folge
hat. Studien haben ergeben, daß diese Kosten enorm hoch sein können. In
einigen Unternehmen werden 20% bis 50% der Zeit von Benutzern dafür
aufgewendet, andere Benutzer in ihrem Kampf mit der Technik zu
unterstützen. Eine Möglichkeit, derartige Erfahrungen zu vermeiden, liegt in
einer angemessenen Mitarbeiterschulung.
• Planung des Übergangs zu einer parallel strukturierten Datenverarbeitung
Das zuvor bereits zusammenfassend beschriebene Client/Server-Modell
unterstreicht den Bedarf für parallele Interaktionen zwischen Clients und
Servern, um die Implementierung eines echten Client/Server-Systems zu
ermöglichen.
• „Just-in-time″ Erwerb von Computerleistung
Die Möglichkeit hierzu wird durch direkte Verbindungen zwischen Anbietern
und Benutzern geschaffen. Dieses Konzept muß insbesondere auf die
Verwaltung und den Erwerb von Softwarelizenzen angewendet werden.
Anbieter von Systems Management müssen diese Art der Verwaltung
verfügbar machen, und zwar nicht nur, um einen verbesserten Service und
Kapitel 7. Ausblick 75

verkürzte Zykluszeiten für Aufträge zu gewährleisten, sondern auch, um die
Kosten für Softwarelizenzen zu senken.
• Aufstellung eines Plans zur effektiven Verwaltung von Daten im gesamten
Unternehmen
Der beste Schutz für die wichtigsten Daten ist wahrscheinlich eine zentrale
Speicherverwaltung; es müssen jedoch Daten aller Formen und Größe
verwaltet und im gesamten Unternehmen verfügbar gehalten werden.
Die zuvor erwähnte Explosion der Datenmenge stellt diese Forderung in
Frage. Aber auch die engagiertesten Verfechter verteilter Daten erkennen
an, daß viele Einschränkungen überwunden werden müssen, bevor wichtige
Daten im gesamten Unternehmen verbreitet und sicher geschützt und
verwaltet werden können. Zweiphasige Festschreibungsverfahren und
Ähnliches sind noch nicht ausreichend auf verteilte Datenmanager
abgestimmt, um die gemeinsame Datenbenutzung in solchen verteilten
Umgebungen zu ermöglichen.
Unternehmen müssen jedoch danach streben, Daten, unabhängig davon, wo
sie sich befinden, mit höchster Sicherheit und Funktionalität zu verwalten.
• Verwaltung von Software-Mietverträgen
Die Verwaltung von Vermögenswerten, insbesondere in bezug auf Software,
ist eine der größten Herausforderungen, denen man sich zu stellen hat. Eine
solche Verwaltung ermöglicht es, Vermögenswerte aus dem Bereich der
Informationstechnologie finanztechnisch kontrolliert zu erwerben, zu
aktualisieren und auszusondern.
Es muß sichergestellt werden, daß kritische Anwendungen auf Plattformen
laufen, die für einen Katastrophenfall durch Wiederanlaufpläne abgesichert
sind.
7.3 Auswirkungen auf das Systems Management Design
76 Systems Management Design - Ein Überblick
Das Systems Management Design wird mehr und mehr zu einem integralen
Bestandteil der Auswahl und Entwicklung von Anwendungen werden.
Unternehmen werden sich der Tatsache bewußt, daß das Geheimnis für einen
erfolgreichen Einsatz einer modernen Technologie nicht in der bloßen Funktion
liegt, die sie bietet, sondern eher darin, wie sie während ihrer Lebensdauer im
Unternehmen eingesetzt und unterstützt wird.
Die Anwendung des Systems Management Design erfordert die Einhaltung
strenger Kriterien, um sich im Einklang mit der Technologie entwickeln zu
können. Das Niveau der heutzutage üblicherweise implementierten
SM-Funktionen ist relativ niedrig, wenn man es in Beziehung zu den
Anforderungen der Zukunft setzt, in der Kostendruck und die Komplexität der
Informationstechnologie einen wesentlich höheren Grad der Automatisierung,
eine breitere Implementierung der Leistungsverwaltung, eine verbesserte
Nutzung von Ressourcen, sowie die sofortige Lieferung von Software über
direkte Verbindungen zu den Lieferanten erfordern werden. Dieses sind nur
einige Beispiele für die Art der Herausforderungen, denen man sich auf dem
Gebiet der Produktfunktionen und der Implementierungsdesigns gegenübersehen
wird.

Abkürzungsverzeichnis
APC Arbeitsplatz-Computer
ATM Asynchronous Transfer Mode
CMIP Common Management
Interface Protocol
DoD Department of Defense
EUD End User Dimension
GDMO Guidelines for the Definition
of Managed Objects
IBM International Business
Machines Corporation
IS Informationssystem
IT Informationstechnologie
Information Technology
ITPM Information Technology
Process Model
ITSO International Technical
Support Organization
LAN Local Area Network
MAN Metropolitan Area Network
OMG Object Management Group
OMG IDL Object Management Group
Interface Definition Language
OO Object Orientation
OSF/DCE Open Software
Foundation/Distributed
Computing Environment
SM Systems Management
SM Systems Management Design
SMFD Systems Management
Framework Design
SNMP Simple Network Management
Protocol
SLK Service Level Kontrakt
TCP/IP Transmission Control
Protocol/Internet Protocol
TMN Telecommunication
Management Network
VPN Virtual Private Network
WAN Wide Area Network
XSMS X/Open System Management
Services
© Copyright IBM Corp. 1996 77

78 Systems Management Design - Ein Überblick

Index
A
Abkürzungen 77
Akronyme 77
Analysetechniken basierend auf
Durchführbarkeit eines Prozesses 70
Fallbeispiele 70
Management-Eigenschaften 68
Nutzen einer Anwendung 68
Wechselseitigen Prozeßabhängigkeiten 68
Ziele eines SM-Prozesses 68
Anforderungen 20
Anmerkungen, spezielle xi
Anwendungen, geschäftliche 71
Aufgaben 27
Ausblick 27, 32, 41
Auswahl der SM-Prozesse
Benutzer-Service 66
Identifizierung 66
Prioritäten 66
B
Bewertung existierender Prozesse 66
D
Design 4
Design Beispiel 1
Anforderungen 20
Aufgaben 27
Ausblick 27
Designdurchführung 23
Designergebnisse 24
Kundensituation 19
Prozeß-Modelle 25
Prozeßauswahl 21
Status 27
Umgebung 20
Design Beispiel 2
Ausblick 32
Designdurchführung 30
Designergebnisse 32
Eigenschaften 29
Kundensituation 28
Prozeßauswahl 30
Status 32
Umgebung 29
Design Beispiel 3
Ausblick 41
Designdurchführung 36
Erfahrungen 40
Implementierung 39
Kundensituation 33
Probleme 40
Design Beispiel 3 (Forts.)
Status 41
Design-Projekte 14
Design-Prozeß 12
Designdurchführung 23, 30, 36
Designergebnisse 24, 32
Details SM-Umgebung 55
E
Eigenschaften 29
Einführung xiii
Elementgruppen 57
Elementgruppen - Anwendungssichtweise
Client-Knoten 60
Netzwerk 60
Server-Knoten 60
Elementgruppen - Komponentensichtweise
Hardware Zentralsystem 59
Netzwerk 59
System-Software 59
Erfahrungen 40
G Geschäftliche Trends 71
Gruppierung der „Managed Elements″ 57
Gruppierung der Elementgruppen 57
I
Implementierung 39
Implementierungsprioritäten 67
IT-Anwendungen 74
IT-Infrastruktur 51
IT-Prozeß-Modell 12
IT-Service-Liefereinheiten 52
IT-Strategien 74
K
Kundensituation 19, 28, 33
L Lösungs-„Domains″ 48
M
Management-Funktionen 52
N
Normen 53
Normen und Standards 53
© Copyright IBM Corp. 1996 79

P Prioritäten 53
Probleme 40
Prozeß-Modelle 25
Prozeßauswahl 21, 30
Prozeßorientierung 65
R
Referenzliteratur xiii
Ressourcenorientierung 65
S Service-Pakete 48, 53
Service-Verträge 53
SM
siehe Systems Management
SM Einflußfaktoren
IT-Infrastruktur 51
SM-Infrastruktur 51
SM-Prinzipien 51
SM-Eigenschaften
Abgrenzung 61
Abhängigkeit 62
Ausbildung 62
Bedeutung 61
Dynamische Umgebungsfaktoren 62
Eigentumsrecht 61
Größe und Volumen 61
Heterogenität 62
Komplexität 61
Managementverhalten 61
Neue Technologien 62
Normen und Standards 62
Sicherheitsanforderungen 62
Verteilung 61
Wissensstand 62
SM-Eigenschaften der Elemente 60
SM-Infrastruktur 51
SM-Philosophie 52
SM-Prinzipien 51
SM-Prinzipien und Kategorien
IT-Service-Liefereinheiten 52
Management-Funktionen 52
Normen 53
Prioritäten 53
Service-Pakete 53
Service-Verträge 53
SM-Philosophie 52
Standards 53
SM-Prozesse 65
SM-Umgebung
Detailbehandlung 55
Elemente, SM-Eigenschaften 60
Elementgruppen 57
Managed Elements - Gruppierung 57
Umfang 55
80 Systems Management Design - Ein Überblick
SMD
siehe Systems Management Design
SMD Auswirkungen 76
SMDF-Struktur
Dienstleister 46
Framework-Definition 48
Funktionen 46
Grundprinzipien 44
Komponenten-Management 47
Richtlinien 44
SMFD Design 6
SMFD Framework-Definition 48
SMFD Funktionen und Dienstleister 46
SMFD Grundprinzipien und Dienstleister 44
SMFD Komponenten-Management 47
SMFD-Konzeption 44
Spezielle Anmerkungen xi
Standards 53
Status 27, 32, 41
Strategie 1
Strategien and Anwendungen
Geschäftliche Überlegungen 71
Übergreifende Anwendungen 71
Strategien, geschäftliche 71
Systems Management
Design 4
Design-Projekte 14
Design-Prozeß 12
SMDF Design 6
Strategie 1
Systems Management Design 43
Systems Management-Prozesse
Implementierungsprioritäten 67
Prozeßauswahl 66
Prozeßbewertung 66
Prozeßorientierung - Gegenüberstellung 65
T
Technische Trends 71
Trends
Allgemeine geschäftliche 71
Allgemeine technische 71
Anwendungen, geschäftliche 71
IT-Anwendungen 74
IT-Strategien 74
SMD Auswirkungen 76
Strategien, geschäftliche 71
U
Umfang SM-Umgebung
Definition 55
Hardware 55
Komplexität 56
Netzwerkkomponenten 55
Software 55
System 55
Topologie 55

Umgebung 20, 29
V Veröffentlichungen xiii
Vorwort v
Z
Zusammenfassung iii
Index 81

IBML ®
Gedruckt in U.S.A.
SG24-4687-00