Inhalt und Aufbau eines Kapazitätsmanagement (KM)-Systems gehören langsam zum Standardwissen von DV-Managern und sind inzwischen auch mehrfach detailliert geschildert worden (siehe zum Beispiel CW Nr. 44 vom 1. November 1985. Seite 23). Im folgenden soll nun dargestellt werden, was bei der Einbettung eines solchen Systems in die Unternehmensumgebung zu beachten ist.

Dabei ist zuallererst das "Wie" einer Einführung wesentlich, denn es ist selbstverständlich, daß jedes die DV benutzende Unternehmen seine eigenen, speziellen institutionalisierenden Regel und Verfahren zur Planung und Steuerung eines DV-Betriebs hat, die eine spontane Implementierung umfassender neuer Methoden a priori vereiteln.

Zu dieser rein objektiven Schwierigkeit für den Kapazitätsplaner gesellt sich dann noch der mehr emotionale Widerstand von Management, Anwendungsentwicklung und Systemprogrammierung hinzu, die mit Begriffen wie "nice to have, but we have no time to do it", "Jumbo-Projekt", "chronisch unterbesetzt" oder "aktuelle Tagesproblematik ist wichtiger" ihre Mitarbeit im voraus aufkündigen.

Soll dennoch versucht werden, die Herausforderung KM anzugehen, zum Beispiel weil der Quotient aus Istkosten und Plankosten regelmäßig viel größer als eins ist, die Antwortzeiten davonlaufen oder die Frage nach den aktuell installierten Systemen von niemandem mehr hinreichend genau beantwortet werden kann, so bietet sich die Einführung in Form des folgenden Stufenkonzepts an:

1. Stufe:

Bewertung der vorhandenen Systeme, Methoden und Vorgänge in der DV-Planung und Durchführung zur detaillierten, unternehmensbezogenen Beschreibung eines abgestuften Konzepts für KM.

Die sich daran anschließenden Stufen sind natürlich abhängig von den in der ersten Stufe analysierten unternehmensspezifischen Besonderheiten, so daß die hier beschriebenen Abschnitte entweder wegfallen (weil schon implementiert), verkürzt (weil Ansätze vorhanden sind) oder zusammengefaßt (etwa wegen organisatorischer Gegebenheiten) werden können.

2. Stufe:

Vervollständigung der Überwachung von installierten DV-Anlagen und Netzen in Richtung auf ein Gesamtberichtswesen für Management und Rechenzentrum.

Aufgaben:

- Eliminierung ungeeigneter Meßwerkzeuge,

- Installation optimal passender Meßwerkzeuge,

- Periodische Zusammenführung der Meßdaten zu Berichten für

a) Management (Eigenschaften: hoher Komprimierungsgrad, globale Aussagen, leichte Lesbarkeit (Grafiken), aussagekräftige Begriffe wie zum Beispiel Anzahl Buchungen, Anzahl Geschäftsvorfälle, nicht: Anzahl IMS-Transaktionen,

b) Rechenzentrum (Eigenschaften: hoher Detaillierungsgrad, systemspezifische Aussagen, DV-technische Begriffe).

3. Stufe:

Aufbau einer Topologie-Datenbank (Konfigurations-DB) mit Einführung einer Systematik zur Sicherstellung der Aktualität.

Aufgaben:

- Auswahl eines geeigneten Datenbanksystems; zu bevorzugen sind relationale Systeme mit benutzerfreundlichen Abfragesprachen,

- Festlegung der Inhalte (Konfigurationsdaten, Installationsdaten, vertragliche Daten),

- Einführung einer Update-Systematik mit Festlegung von Verantwortlichkeiten.

4. Stufe:

Einführung von Modellierungsmethoden für die Lastvorhersage installierter und geplanter Anwendungen, frühzeitige Engpaßanalyse sowie realistische Kostenabschätzungen von neuen Anwendungen.

Aufgaben:

- Auswahl geeigneter analytischer und Simultationsmodelle

- Dokumentation der Modellierungsabläufe,

- Einbindung von Modellierungen in den Planungsablauf.

- Einführung von Engpaßsuchstrategien.

5. Stufe:

Vollständige Einführung von Service-Level-Vereinbarungen für existierende und geplante Anwendungen.

Aufgaben:

- Ist-Analyse und Messung der bestehenden Anwendungen,

- Antwortzeitvorhersage für geplante Anwendungen,

- Festlegung der Service-Anforderungen für alle Anwendungen,

- Festlegung der organisatorischen Richtlinien zur Kontrolle der Service-Vereinbarungen.

6. Stufe

Aufbau von kalkulatorischen Erfolgsrechnungen für EDV bezogenen auf die Unternehmensziele. Einbettung der Ergebnisse in die gesamtbetrieblichen Finanzprozesse.

Aufgaben:

- Abgleich der realistischen Projektkosten mit den zu erwartenden Erlösen zur Bestimmung der Amortisationsfrist eines Projekts,

- Einbindung von DV-Komponenten in die betriebliche Investitionsrechnung, unter anderem Bestimmung der Werte Return of Investment (Kapitalertragszahl), Interest rate of return, etc.

Folgende Rahmenbedingungen sind bei der Durchführung des Stufenkonzepts gültig:

- Im ersten Schritt sind die folgenden Stufen mit ihrem jeweiligen Aufwand zur Realisierung konkret zu beschreiben.

- Nach jeder Stufe muß ein Ausstieg so gewährleistet sein, daß das Erreichte nicht gefährdet wird, das heißt jede Stufe in sich abgeschlossen ist.

Unter Beachtung dieser Rahmenbedingungen wird aus dem Kapazitätsmanagement weder ein "Jumbo-Projekt" noch ein unpraktikables Regelwerk.

Konsequenzen beim Betrieb

Nach der Beschreibung des "Wie" stellt sich die Frage nach dem "Wo" und "mit welchen Konsequenzen" führe ich ein KM-System ein, fast von selbst.

Der Keim eines KM-Systems liegt sicherlich im Rechenzentrum das ja schon seit Jahren Erfahrung im Umgang mit Meßwerkzeugen hat und diese für Überwachung, Tuning und Berichte einsetzt. Dabei kommt es den Benutzern im Rechenzentrum allerdings weniger auf Vollständigkeit und Verknüpfbarkeit zur Erlangung einer Gesamtsicht auf Anwendungsebene, sondern mehr auf eine detaillierte Systemsicht zum Handling der DV-Anlage an.

Diese Systemsicht wird durch die Einführung von Rechnermodellierungen (vergleiche 4. Stufe) wesentlich transparenter, weil die Auswirkungen von Konfigurationsveränderungen, Lastveränderungen und ähnlichem durch den Dialogteil des Modellierungssystems direkt berichtet werden.

Auf der anderen Seite bedingt die Aktualitätsforderung der Topologie-Datenbank, daß Systemgenerierungen und Installationsdaten mit der Realität übereinzustimmen haben. Folglich erfährt die Arbeit der Systemprogrammierung eine gewisse Disziplinierung. Dabei kommt die Disziplinierung auf Dauer dem Betroffenen selbst zugute, da ihm mit der Topologie-DB ein leistungsfähiges System zur Erstellung aktueller Konfigurationen zur Verfügung steht, die ihm das oft stundenlang suchen nach dem, was zur Zeit installiert oder geplant ist, abnimmt.

Ein anderer von KM betroffener Bereich ist die Anwendungsentwicklung oder -programmierung. Durch die Möglichkeit zur Modellierung geplanter Systeme wird dem Anwendungsentwickler ein System in die Hand gegeben, mit dem er seine noch nicht codierten Module durch Eingabe gewisser Eckdaten schon im voraus auf Effizienz prüfen kann. So erübrigen sich in der Testphase beispielsweise Umprogrammierungen aus Performancegründen.

Darüber hinaus gelingt durch das Modellieren geplanter Systeme und deren Einbettung in das Rechnermodell erstmalig eine Projektkostenabschätzung die die zu erwartenden Benutzungskosten mit einbezieht.

Damit kommen wir automatisch zum dritten betroffenen Bereich, der DV-Planung. Dort kann die Ressourcenplanung aufgrund des Wissens über die von neuen und modifizierten Anwendungen verursachten Lastzuwächse exakte Planungen hinsichtlich der benötigten Hardware und Software durchführen. Selbst Anwendungen auf neuen Systemen zum Beispiel relationalen Datenbanken, lassen sich unter Zuhilfenahme eines kleinen Tests modellieren und mit diesen Eckdaten, Lastabschätzungen vornehmen.

Den stärksten Einfluß auf den Betriebsablauf übt sicherlich die Einführung von Service-Vereinbarungen für alle Anwendungen zwischen den Anwendern und der DV aus. Dabei kommt es wesentlich auf Vollständigkeit und Kontrolle dieser Vereinbarungen an, so daß diese Maßnahme erst nach Einführung eines kompletten Berichtswesens (wegen der vollständigen Meßdatenerfassung) und von Modellierungstechniken (wegen der Erfassung geplanter Anwendungen erfolgen, da ja diese erst die Voraussetzungen dafür liefern.

Service-Vereinbarungen mit Alibifunktion

Jedes Unternehmen, das Service-Vereinbarungen sozusagen auf der grünen Wiese, und das heißt ohne die notwendigen Kontrollmechanismen einführt, benutzt sie ausschließlich als Alibifunktion dem Management gegenüber. Wem nützt denn die Vereinbarung, daß die CICS-Transaktion XYZ123 in 90 Prozent aller Fälle eine Antwortzeit von weniger als drei Sekunden hat, wenn weder eine Gesamtantwortzeit (Host- und Netzanlaufzeit) gemessen oder abgeschätzt und regelmäßig kontrolliert wird?

Dabei stellt ein echtes Service-Management überhaupt erst die Grundlage für den Betrieb von DV-Anlagen auf, nämlich dann, wenn für jede Anwendung eine Vereinbarung hinsichtlich

- Verfügbarkeit,

- Antwortzeit (bei Dialoganwendungen) und

- Durchlaufzeit (bei Batchanwendungen)

getroffen wird.

Das impliziert folgende Aufgaben für die Betroffenen:

1. Vereinbarung in puncto bestehender Anwendungen

Vorherige Messungen durch RZ, Absprache mit Entwicklern, Planungsabteilung und Anwendern,

2. Vereinbarung in puncto neuer Anwendungen

Modellierung durch Entwickler, Kopplung mit Rechnermodell durch Planungsabteilung oder RZ,

3. Kontrolle

Regelmäßige Messungen durch RZ und periodische Informationsweitergabe über ein komplettes Berichtswesen.

Bei der Kontrolle bietet sich das sogenannte Ampelprinzip an, also die Definition von Grün-, Gelb- und Rotphasen. Die Grünphase ist natürlich das Merkmal für reibungslosen Betrieb mit noch vorhandenen Puffern, bei Gelb sind die Puffer verschwunden und in der Rotphase werden die Service-Vereinbarungen schon systematisch verletzt. Diese Rotphase sollte nach Einführung eines KM-Systems, vorausgesetzt man hat die Einführung sorgfältig und vollständig durchgeführt, verschwunden sein.

Konsequenzen für das DV-Management

"Kapazitätsmanagement ist in erster Linie ein Problem des Managements und nicht ein Problem der Kapazitäten", schreibt E. Pietschner in der COMPUTERWOCHE vom 30. 5. 86 unter dem Titel "Gute Antwortzeit ist teuer - schlechte sehr teuer" und verdeutlicht damit, wo der Schwerpunkt bei der Entscheidung Für und Wider KM liegen soll.

Tatsächlich hat ein KM-System auch gravierende Folgen für die Arbeitsweise des DV-Managements, bedeutet seine Einführung doch die weitgehende Substitution des Managements by Objectives durch das Management by Systems.

Das sollte näher erläutert werden. Man unterscheidet bei den heutigen Führungstechniken (siehe zum Beispiel Schierenbeck: Grundzüge der Betriebswirtschaftslehre, 8. Auflage, R. Oldenbourg Verlag, München - Wien 1986, Seite 128) im wesentlichen vier "Management by"-Konzepte:

MbE: Management by Exception

- Führung durch Abweichungskontrolle und Eingriff im Ausnahmefall

Mbd: Management by Delegation

- Führung durch Aufgabendelegation

MbO: Management by Objectives

- Führung durch Zielvereinbarung

MbS: Management by Systems

- Führung durch Systemsteuerung beziehungsweise Führung mit Delegation und weitestgehender Selbstregelung auf der Grundlage computergestützter Informations- und Steuerungssysteme.

Die Reihenfolge von MbE zu MbS ist im wesentlichen dadurch charakterisiert, daß der Entscheidungsspielraum der nachgeordneten Organisationseinheiten immer größer wird, bis schließlich bei MbS ein Teil der Kompetenzen sogar einem computergestützten System übergeben wird.

Folglich sind die Eigenschaften eines KM-Systems, gesamtbetrieblich gesehen, identisch mit denen jedes MbS, als da sind: (siehe wiederum Schierenbeck, a.a.O., Seite 125)

- heute nur "reale Utopie", zeigt aber die Entwicklungsrichtung,

- so wird im Prinzip die zukünftige Unternehmensführung aussehen, wobei MbE, MbD und MbO hierin integriert sind,

- psychologische Widerstände (sind) zu erwarten: Wollen Manager tatsächlich solche Systeme oder werden sie ihnen von Systemplanern oder EDV-Herstellern "aufgezwängt"?

Offensichtlich ist es also eine Zeitfrage, bis derartige, in sich geschlossene Planungs- und Steuerungssysteme "einführbar" werden und dem Stand der Führungstechniken entsprechen.

Daß das KM-System heute schon realisierbar ist, spielt bei der Frage der Einführung eine eher untergeordnete Rolle. Primär bei dieser Entscheidung ist das Kriterium, ob das DV-Management auch die Fähigkeit besitzt, einen Teil seiner Kompetenzen abzugeben oder nicht. Diese Entscheidung wird ihm aber von keinem heute bekannten System abgenommen.