Hersteller kommerzieller DV-Systeme sprechen nicht selten von 99prozentiger Systemverfügbarkeit. Diese Aussagen werden wie Fahnen vorangetragen und als Verkaufsargument eingesetzt. In der Praxis sind jedoch allzuoft Programmabstürze, Emulations- und Wiederholungsläufe, Fehlbedienungen sowie Pannen in der Arbeitsvorbereitung mit den wirklichen Produktivleistungen gut vermischt und mit Hilfe von Accounting-Programmen "gerecht" auf die Benutzer-Kostenstellen verteilt. Anstelle von Nutzungsgrad-Optimierung kann - zur Freude der Hersteller - noch immer mehr Hardware eingesetzt werden.

Hier stellt sich die Frage, ob es sich nur um ein semantisches Problem zwischen Hersteller und Benutzer über die Begriffe System- oder Anwender-Verfügbarkeit handelt oder ob die eigentlich interessante Anwender-Verfügbarkeit bewußt salopp vernachlässigt wird. In Prozeßrechner-Anwendungen bemüht man sich keineswegs, die eingesetzten Steuer-Rechner maximal auszulasten, Im Gegenteil: Zur Sicherstellung eines störungsfreien Prozeßablaufs sollte der Steuerrechner wenige, ja möglichst nur eine Aufgabe betreuen. Verfügbarkeit versteht sich hier als ein hehres Gut der Betriebsbereitschaft.

Auslastung ist Trumpf

Ganz anders in der kommerziellen DV: Die Abwicklung möglichst vieler, unterschiedlicher Aufgaben auf dem Universalrechner ist Trumpf. Hohe Auslastung der "Produktionsmaschine" DV ist hier Voraussetzung für Wirtschaftlichkeit: Verfügbarkeit dient diesem Zweck. Um etwaigen Mißverständnissen vorzubeugen: Die Ausführungen dieses Artikels beziehen sich primär auf Mainframe-Einsatz .

Die Komponenten, die das Nutzverhalten eines kommerziellen DV-Systems bestimmen, sind in ihrer "Substanz" und in ihrem Fehlverhalten höchst heterogen. Zu unterscheiden sind mindestens:

- Hardware und Betriebssystemsoftware

- die jeweilige Konfiguration der installierten Hardware

- betriebssystemnahe Software Modularprogramme und Standard-Software

- Individual-Software

- die auf die Anwendung abgestimmte Dateikonfiguration

- Batch- und Datensicherungsprogramme

- die Vorschriften zur Arbeitsvorbereitung (AV) und Betriebsablaufsicherung

- das eingesetzte Operating-Personal.

Erst eine sorgfältige Analyse der Einzelverfügbarkeit erlaubt verbindliche Aussagen über die anwendungsrelevante Gesamt-Verfügbarkeit.

Für die in der Praxis konstatierte Verfügbarkeit bilden das Logbuch und die Accounting-Listen die Grundlage. Beginn und Ende von Produktivzeiten und Ausfallzeiten ergeben die Verfügbarkeit (VF) für den nutzrelevanten Zeitraum:

VF = Summe der Produktivzeiten/Summe der benötigten Zeiten

Der letztere Wert ist die Summe aus den produktiv verfügbaren und den ungeplanten zur Reparatur verwendeten Ausfallzeiten. Die Zeiten außerhalb des Schichtbetriebes, die etwa zur vorbeugenden Anlagenwartung benötigt werden, zählen dabei nicht zu den Ausfällen. (Die enge Verwandtschaft der hier empirisch erfaßten Zeitgrößen zu den statistischen Größen MTBF und MTTR ist nicht zu übersehen.)

Logbuch als Grundlage

Bemerkenswerterweise liegen die so ermittelten VF-Werte meistens weit unter denen der von den Herstellern offiziell propagierten System-Verfügbarkeit. Der von der Praxis ernüchterte User betrachtet die ihm zugesagten Werte als eine Art von Zahlen-Feuerwerk.

Die klassische Ausfall-Statistik pflegt nur die totalen Ausfälle von Hardware und Betriebssystem-Software zu verzeichnen. Fehlfunktionen in diesen Bereichen ziehen meistens einen Ausfall des Gesamtsystems nach sich.

Es gibt jedoch auch andere, weniger spektakuläre Ausfallzeiten: Eine Bankenanwendung, die, zum Beispiel durch die systemnahe DB- oder TP-Software verschuldet, zehn Minuten lang nicht in der Lage ist, Auskunft über Kontostände zu erteilen, gilt zwar de facto als nicht "zusammengebrochen", der Kunde vor dem Bankschalter wird sie trotzdem eine gewisse Zeitspanne lang als ausgefallen betrachten.

Was in die klassisch ermittelten Verfügbarkeitswerte offensichtlich nicht eingeht, ist das Ausmaß, in welchem die sogenannten Produktiv-Zeiten tatsächlich Nutzen erbringen konnten. Reine Zeitmessungen ohne Bewertung bringen wenig taugliche Ergebnisse. Ein vorbeugend gewartetes, interaktives und nur wenig eingesetztes Computersystem dürfte eine enorm hohe - weil ungefährdete - Systemverfügbarkeit aufweisen: nämlich so gut wie 100 Prozent! Solche Fragen nach Leistungsbewertung und die dazugehörigen Verbesserungsansätze reichen weit in das komplexe Gebiet der Tuning- und Rekonfigurationsmaßnahmen hinein.

Ein letztes Beispiel aus dem Bereich "AV und Operating": Was bedeutet es für die anwendungsrelevante Verfügbarkeit eines DV-Systems, wenn die beiden einzigen Operateure plötzlich kündigen und durch ein neues Team ersetzt werden müssen? Da dadurch entstehende Beeinträchtigung des Produktivbetriebes ist nicht leicht zu erkennen.

Die erforderlichen Daten liegen zwar meistens in den Accounting-Listen vor. Aber wer überprüft schon konsequent, wie viele Jobs vom neuen Operating-Team wegen Fehlern im Arbeitslauf abgebrochen und anschließend wiederholt werden mußten? Auch das sind zweifelsfrei nichtregistrierte "Times to Repair".

Verfügbarkeit gewichten

Hat sich der Blick einmal dafür geschärft, daß der übliche Verfügbarkeitsbegriff nur bedingt tauglich ist, so kann der Anwender - je nach angestrebter Sicherheit oder wirtschaftlicher Nutzbarkeit - die Teilverfügbarkeiten gewichten und nach ökonomischen Gesichtspunkten zu verbessern suchen.

Unerläßlich ist ein kritischer Vergleich des in der AV geplanten Ablaufs und Volumens in Relation zu den durch Betriebsablaufsicherung ausgewiesenen tatsächlichen Ablaufs. Bei der Beeinträchtigung der wirtschaftlich relevanten Anwender-Verfügbarkeit dominieren in der Regel die vom Anwender beeinflußbaren Faktoren:

- Fehler/Mängel der Individual-Software

- Konfigurations-Schwächen

- Arbeitsvorbereitung

- Operating.

Die Ursachen für Mängel und Fehler der Individual-Software liegen meistens in unvollständigen oder mißverständlichen Spezifikationen, vorschnell verabschiedeten Designs, Flüchtigkeiten in der Implementierung sowie unzureichenden Tests und Dokumentations-Schwächen.

Für "Alt-Programme" - mitunter der Löwenanteil der Individual-Lösungen - wurde die Chance zur Vermeidung von Fehlern und Mängeln oft schon vor zehn oder mehr Jahren verpaßt. Zudem könnten die inzwischen erfolgten Änderungen zur Intransparenz, ja Schwächen dieser Software geführt haben. Mit diesen muß man im allgemeinen aus Kostengründen "leben". Partielle Verbesserungen, zum Beispiel Erweiterung der Plausibilitätsprüfung von Operator-Eingaben, können jedoch kostengünstig realisiert werden, sofern die Programmlogik hierdurch nicht unmittelbar betroffen ist.

Engineering hilft

Wesentlich günstiger ist die Situation bei der Erstellung von neuer Individual-Software. Die Methoden des modernen Software-Engineering bieten eine nicht zu unterschätzende Hilfe. Wiederanlaufverfahren, Entflechtung von divergenten Funktionen oder Diagnosehilfsmittel werden von diesen Verfahren jedoch im allgemeinen nur unzureichend berücksichtigt und müssen sorgfältig beachtet werden.

Einen eigenen Problemkreis bilden Konfigurations-Schwächen (Hardware, Dateien, Software). Die vom User "frei" gewählte Konfiguration kann nach relativ kurzer Nutzungszeit bereits überlastet oder unausgelastet sein. Die durchaus vom Benutzer zu vertretenden Schwachen, wie etwa die unzweckmäßige Verteilung von Systemdateien, Datenbanken und Sicherungsdateien oder eine ineffiziente Lastverteilung auf die Kanäle, können zu gravierender Beeinträchtigung der Anwenderverfügbarkeit führen.

Betrachten wir schließlich die zuletzt genannten Problemkreise, nämlich Arbeitsvorbereitung, Betriebsablaufsicherung und Operating, so bieten sie dem User die vermutlich wirkungsvollsten Möglichkeiten zur Optimierung der Anwenderverfügbarkeit an:

- Effizientere Ausbildung des für die Funktionen AV und Operating/ Betriebsablaufsicherung verantwortlichen Personals

- Intensivierung der Kommunikation zwischen Operating, AV und Programmentwicklung

- Aktualisierung der Operator-Anweisungen

- Perfektionierung der Betriebsablaufsicherung.

Einzelne Maßnahmen der Optimierung werden allerdings nur erfolgreich sein, wenn sie abteilungsübergreifend als Gesamtmaßnahmen strategisch geplant und ihre Ausführung vom DV-Chef überwacht, gemessen und bewertet werden können.

Resümiert man die hier skizzierten Aspekte der "Anwender-Verfügbarkeit", so kann man festhalten:

- die in der Praxis konstatierte "Anwender-Verfügbarkeit" liegt in der Regel wesentlich niedriger als die "System-Verfügbarkeit"

- die vom Hersteller vielgepriesene "Systemverfügbarkeit" ist leider nur eine - wenn auch nicht unwichtige - Komponente der Anwender-Verfügbarkeit

- die wirtschaftlich relevante Anwender-Verfügbarkeit ist auch vom User weitgehend positiv beeinflußbar

- Optimierung der Anwender-Verfügbarkeit - als Gesamtmaßnahme bewertet, strategisch geplant und koordiniert - wird den Nutzungsgrad deutlich erhöhen.

*Ladislaus Kovats und Peter Werth sind Geschäftsführer der Explora GmbH, Institut für Industrieberatung und Marktforschung.