Der Grundsatz "Organisation geht vor Technik" wird nach Ansicht von Werner Hain* nirgendwo in der Informationstechnologie so wenig eingehalten wie bei der RZ-Automation. Der Autor kritisiert die mangelhafte Integration verfügbarer Produkte, moniert das Fehlen verbindlicher Standards und beklagt zudem, daß die Benutzer noch allzu häufig mit völlig antiquierten Bildschirmoberflächen auskommen müssen.
*Werner Hain ist Abteilungsdirektor DV bei der Bausparkasse Wüstenrot in Ludwigsburg.
Richtlinien zum Einsatz von RZ-Automation
1. RZ-Automation ist keine abgeschlossene Einmal-Aufgabe, sondern ein andauernder Prozeß der Verbesserung, der Vereinfachung und der Suche nach optimalen Lösungen.
2. RZ-Automation ist keine Antwort auf eine technische Fragestellung, sondern die organisatorische Vereinfachung bestehender Abläufe mit dem Ziel der Einsparung von Kosten.
3. RZ-Automation schafft Standards, Standards verbessern die Qualität, und eine gesteigerte Qualität führt zur Erhöhung der Produktivität des Rechenzentrums.
4. RZ-Automation ist immer nur als Bestandteil einer integrativen Lösung im Dienst der Service-Ziele zu sehen.
5. RZ-Automation ersetzt keinen Mitarbeiter. Da die Mehrzahl der Mitarbeiter ganz normale Menschen mit vielen Stärken und Schwächen sind, muß die RZ-Automation ihr Augenmerk darauf richten, die Folgen bestehender Schwächen zu minimieren.
6. RZ-Automation darf keine produktspezifischen Bedienungskenntnisse erfordern, sondern nur aufgabenorientiertes Wissen.
Empfehlungen und Wünsche
1. Viele der auf dem Markt angebotenen Lösungen sind nicht Bestandteil eines durchgängigen Gesamtkonzepts zur RZ-Automation. Es handelt sich um Insellösungen, denen die Integration zu anderen Aufgabengebieten oder zur bestehenden Anwendungswelt fehlt. Die Folgen: Adaptions- und Schnittstellenprobleme.
2. Die Bildschirmoberflächen sind manchmal noch antiquiert. Eine dem State of the Art entsprechende Präsentationsgrafik fehlt vollständig. Die Folge ist ein hoher Aufwand für die Bedienung dieser Werkzeuge und für die Schulung.
3. Die Tools decken in der Regel Teile des Operating ab, also Aufgaben zur Steuerung und Bedienung von Ressourcen, Subsystemen und Systemen. Eine Unterstützung von Querschnittsaufgaben, zum Beispiel dem Problem- oder dem Konfigurations-Management, fehlt oftmals. So gut wie gar nicht wird Führungsinformation für das RZ-Management bereitgestellt.
4. Die Werbestrategie der Hersteller ist fast ausschließlich produktorientiert und kaum lösungsbezogen. Die kundenspezifischen Rahmenbedingungen und Probleme werden nicht oder nur unzureichend berücksichtigt. Ebenso gibt es nach der Implementierungsphase kaum noch Betreuung und Unterstützung.
5. Bei RZ-Automationslösungen werden teilweise die anstehenden organisatorischen Rahmenbedingungen vernachlässigt. Häufig dominieren technische Aspekte.
6. Es fehlt nach wie vor ein verbindlicher und durchgängiger Standard für Automationsprodukte. Wer verschiedene Tools des selben Herstellers einsetzt, verfügt noch längst nicht über eine einheitliche Architektur.
7. Der Nachweis der Wirtschaftlichkeit unterbleibt vielfach. Sofern im Vorfeld einer Installation überhaupt Einsparungen errechnet werden, sind diese oft gar nicht oder nur teilweise zu realisieren.
Benutzer kleiner MVS-Installationen
müssen für RZ-Automation vergleichsweise tief in die Tasche greifen. Je großer die IBM-Rechnerumgebung, desto geringer wird der Aufwand für entsprechende Automationsprodukte.
Obwohl es sich heute kein Rechenzentrum und kein Datenverarbeitungsbetrieb mehr leisten kann, Überlegungen zur Automation (und damit natürlich zur Wirtschaftlichkeit) zu vernachlässigen oder auch nur aufzuschieben, ist der Markt in den letzten Jahren doch deutlich ruhiger geworden. Nach stürmischen Entwicklungen und nach einer Welle der Begeisterung ist eine gewisse Ernüchterung, mancherorts sogar Enttäuschung über die Möglichkeiten der RZ-Automation eingekehrt.
Als Indiz dafür sei auf die Behandlung dieses Themas in Fachzirkeln oder in Fachpublikationen hingewiesen, wo heute andere Themen die Schlagzeilen bestimmen. Trotzdem sind die Prämissen der 80er und 90er Jahre unverändert gültig: Der RZ-Automation wird ein entscheidender Beitrag zur Erhöhung der Wirtschaftlichkeit und der DV-Effizienz abverlangt.
Vieles deutet darauf hin, daß sich das Angebot auf der Herstellerseite nicht im gleichen Maße wandelt wie die Anforderungen und Bedürfnisse der Anwender. In diesem Beitrag sollen aus Anwendersicht Wünsche, Forderungen und Empfehlungen für die Weiterentwicklung an die Hersteller gerichtet werden. Dabei möchte ich meine Hoffnung zum Ausdruck bringen, daß RZ-Automation als fortwährender Prozeß der Verbesserung, Vereinfachung und Kostensenkung auch zukünftig ihren Markt haben wird.
Der Einsatz der RZ-Automations-Tools wird in vielen Fällen durch die vorhandenen technischen Möglichkeiten bestimmt und orientiert sich weniger an den zu lösenden Aufgaben. Manche DV-Verantwortlichen, vor allem aber viele Hersteller bringen zwar ein großes Expertenwissen über die einzusetzenden Tools mit, schenken aber den eigentlichen Problemen und Zielen zuwenig Aufmerksamkeit.
Bewältigung zunehmender Komplexität der Systeme
So wird häufig übersehen, daß sich mit dem gewandelten Umfeld und den gestiegenen Herausforderungen innerhalb des Rechenzentrums natürlich auch die Ansätze der Automation und deren Ziele entscheidend verändert haben. Die monolithischen Host-orientierten Informationsstrukturen mit riesigen Batch-Produktionen und zentralen Online-Anwendungen haben sich zu Multi-Site-Lokationen mit Client-Server-Architekturen und heterogenen Netzwerken weiterentwickelt. Die zur Verfügung gestellten Services müssen sieben Tage in der Woche rund um die Uhr verfügbar sein - der Nutzer erwartet nun einmal die Informatikleistung "aus der Steckdose". Damit gesellt sich zu traditionellen Zielen der RZ-Automation, beispielsweise die Reduzierung des Head-counts oder die Unattended Operations, noch ein Bündel weiterer Anforderungen. Diese zielen sowohl auf eine Ausweitung des Service in Qualität und Quantität als auch auf die Bewältigung einer zunehmenden operationalen Komplexität der Systeme.
Die Hersteller aber nehmen auf das Erreichen dieser Ziele oft keinen Bezug - die vorhandene RZ-Realität bleibt vielerorts schlichtweg unberücksichtigt. Die Konsequenz daraus ist daß durch eine RZ-Automation weder Erwartungen definiert noch Gewinne prognostiziert werden können. In der Regel nehmen die Anbieter eine Extremhaltung ein: Entweder vernachlässigen sie die Wirtschaftlichkeit, oder sie stellen sie überzeichnet dar.
Eine nutzenorientierte Betrachtungsweise, die über reine Kostenüberlegungen hinausgeht und sich an den Zielen des Rechenzentrums orientiert, ist leider allzu selten.
Vor der Einführung eines Produkts beschränkt sich die Argumentation für die erhöhte Wirtschaftlichkeit in der Regel auf den Hinweis, daß die Personalanforderungen zurückgehen. In der Praxis werden dann aber meistens nur Personalkosten durch Sachkosten ersetzt. Möglich ist auch, daß die erwartete Personaleinsparung gar nicht erst eintritt, weil die freizusetzenden Mitarbeiter anderweitig nicht verwendbar sind oder nicht weiterqualifiziert werden können.
Bei einer Vielzahl von Automationsaufgaben stellt die Auswahl und Installation der richtigen Technik nur einen Teil des zu lösenden Problems dar. Äußerst wichtig ist auch die Vorbereitung des organisatorischen Umfelds und die Einbettung der Werkzeuge in die Ablaufstruktur des Rechenzentrums.
So sind die Chancen einer erfolgreichen RZ-Automation für das Konsol-Management verschwindend gering, wenn beispielsweise keine serviceorientierten Vorgaben für die Steuerung der Systeme und Netzwerke existieren. Oft werden auch heute noch die Entscheidungen wie eh und je ad hoc an der Konsole getroffen.
Problematisch ist auch, wenn die zu durchlaufenden Eskalationsstufen nicht definiert oder deren Teilnehmer nicht mit klaren Befugnissen und Verantwortlichkeiten ausgestattet sind. Sind diese Probleme nicht gelöst, so wird jeder Einsatz eines Tools unweigerlich zum Mißerfolg führen und damit zu einem wirtschaftlichen Fiasko beitragen.
Trotzdem reden die Anbieter nur ungern von Vorleistungen für eine Installation. So wie auf dem Gebiet der RZ-Automation wird vermutlich in keinem anderen Fall der Grundsatz "Organisation vor Technik" vernachlässigt.
Die Funktionalität der Einzelprodukte kann, soweit es die Steuerung und das Management von Ressourcen, Subsystemen und Systemen betrifft, im großen und ganzen als zufriedenstellend bezeichnet werden. Dabei ist nicht zu übersehen, daß gerade bei der Unterstützung von Querschnittsaufgaben, beispielsweise das Problem-, Change- oder Konfigurations-Management oder bei Management-Informationssystemen doch ein großer Nachholbedarf besteht.
Aufmerksamkeit ist hinsichtlich der verstärkten Konzentrationsbemühungen auf der Anwenderseite angebracht, die sicherlich das Verschwinden des einen oder anderen Produkts vom Markt mit sich bringen werden. Andererseits sind überlappende Funktionalitäten der verschiedensten Produkte zu beachten, weil immer mehr Hersteller dazu tendieren, mit sogenannten Systemfamilien ein möglichst komplettes Angebot mit sehr großem Funktionsumfang anzubieten. Damit verschlechtert sich die Position einzelner Tools für bestimmte Aufgabenbereiche.
Zudem fällt die mangelhafte funktionale Integration einzelner Tools immer mehr ins Gewicht. Obwohl der eine oder andere Hersteller dieses Problem zumindest im Bereich seiner eigenen Produkte erkannt hat, fehlen bisher Regeln und Vorgaben (eine Architektur also), die von allen Herstellern akzeptiert werden. Damit könnte aber eine Integrationsbasis für viele Produkte entstehen.
Bereits in dem WhitePaper "The Final Report of the Automated Operations Task Force" hat die IBM-Benutzervereinigung Share im August 1987 beklagt, daß "die vorhandenen Produkte kein Bestandteil irgendeiner offenen Architektur zur Unterstützung der RZ-Automation" seien. Die sich aus einer verfügbaren technischen Plattform ergebende Standardisierung des Angebots wäre für Hersteller und Anwender erstrebenswert und nützlich.
Es ist unverständlich, daß der Vorteil der Standardisierung zwar erkannt, aber eben aus "egoistischen" Motiven nur zögerlich in die Tat umgesetzt wird. Viele Beispiele aus der Industrialisierung oder auch der Eintritt der IBM in den PC-Markt in den 80er Jahren zeigen, daß sich eine Standardisierung oft außerordentlich belegend auf den Markt auswirken kann.
Insbesondere für kleine und kleinste Unternehmen dürften sich durch die Adaption von Standards vielversprechende Geschäftsfelder eröffnen. Wichtig innerhalb eines Standardisierungsprozesses ist seine offene Gestaltung - er sollte von allen Beteiligten beeinflußbar sein. In diesem Zusammenhang möchte ich auf einige positive Ansätze hinweisen. Dazu zählen
- das Systemview-Konzept von IBM,
- die Bemühungen der OSF, die in einem "Request for Technology" unter der Bezeichnung Distributed Management Environment (DME) erste Empfehlungen abgibt, und
- die ISO-Standards "Common Management Interface Services (CMIS)" und "System Management Interface Protocols" (SMIP).
Der erste Schritt auf dem Weg zu einer solchen funktionalen Integration ist die Bereitstellung von genormten Schnittstellen, über die die Produkte miteinander kommunizieren können. Aber auch Vereinheitlichung und Verbesserung von Benutzeroberflächen und die Bereitstellung einer gemeinsamen Datenbasis, eventuell unter Benutzung eines wohldefinierten Datenmodells, zählen zu den relevanten technischen Anforderungen.
Die Zusammenfassung der verschiedensten Anwendungen auf einer Workstation - der Einsatz der "non-programmable Terminals" dürfte nur noch in einem begrenzten Zeitraum sinnvoll sein - und das Design einer grafischen Benutzeroberfläche werden die leichte Anwendbarkeit des Automatisierungswerkzeuges gewährleisten. Damit wird der kommando- und bedienungsorientierte Skill des Bedieners immer mehr in den Hintergrund rücken und - endlich - das anwendungsbezogene Wissen die Bedeutung erhalten, die ihm zusteht.
Aber die angebotenen Produkte müssen nicht nur auf der technischen Seite eine Innovation erfahren. Auch die Art und Weise der Vermarktung, die Vorgehensweise bei der Implementierung, die organisatorische Unterstützung und die begleitenden Schulungsmaßnahmen sollten das reine Produktangebot zu einer kompletten Lösung abrunden. Ähnlich wie der Möbelhändler von einst heute Innenarchitektur entwirft, werden die Anbieter ihre RZ-Automations-Tools nicht mehr als Produkt, sondern im Rahmen einer auf den Kunden zugeschnittenen Lösung anbieten.
Soll ein Automationsproblem gelöst werden, so dürfen nicht länger allein Hardware und Software im Mittelpunkt stehen. Alternativ oder komplementär müssen organisatorische Ansätze für Einsparungspotentiale sorgen, zum Beispiel das Einbeziehen von Fremdleistungen oder Outsourcing, die Zusammenfassung oder Konsolidierung diverser Dienstleistungen.
Aber auch die Dokumentation, die Beschreibung der Automationsorganisation und die Verabschiedung von Automationsrichtlinien werden ein höheres Gewicht erhalten. Die Sicherheit der Automation und die Nachprüfbarkeit unter Revisionsgesichtspunkten dürften eine immer größere Rolle spielen. Die Übergabe und die Übernahme von Verfahren und Verfahrensbestandteilen haben heute in vielen Rechenzentren einen hohen Grad an Sicherheit und Perfektion erreicht. Trotzdem ist es fast überall die Regel, daß Systemprogrammierer oder zuweilen sogar Operatoren in die Lage versetzt werden, an den wichtigsten Stellen der Informationssysteme Abläufe "zu basteln". Entsprechende Kontrollmechanismen fehlen dabei fast immer.
Zusammenfassend läßt sich feststellen, daß der Markt an RZ-Tools einem erheblichen Wandel unterzogen sein wird. Neben technischen Aspekten und der Adaption von Architekturen wird besonders die Bereitstellung von qualifizierter Beratung seitens der Hersteller not wendig sein.
Nur wenn dieses geschieht, kann die RZ-Automation zu einem wirklichen Management-Thema werden und damit diejenige Unterstützung erfahren, die der Wichtigkeit des Themas
angemessen ist.