Schindler AG arbeitet mit Standardsoftware

Höhere RZ-Belastung macht Leistungsverrechnung nötig

30.11.1990

Trotz Dezentralisierung stehen die Rechenzentren heute unter Druck. Komplexe Anwendungen mit hohen Performance-Ansprüchen führen zu ständig höheren Ressourcen-Belastungen. Ausbau des Rechenzentrums (RZ) und steigende Kosten lassen nach Einschätzung von Roland Schürmann die Einführung einer Leistungsverrechnung für Rechenzentren notwendig erscheinen.

Wegen der aufkommenden Verteilung der Verarbeitung (Distributed Processing) wird ein Überblick über die Verteilung der Kosten aber immer schwieriger. Am Beispiel des internationalen Industriekonzerns Schindler soll im folgenden gezeigt werden, wie eine RZ-Leistungsverrechnung aufgebaut und eingeführt werden kann.

Das Unternehmen Schindler mit dem Hauptsitz in Luzern ist im Aufzugs- und Rolltreppengeschäft tätig und fakturierte 1989 einen Umsatz von 3,5 Milliarden Schweizer Franken. Es beschäftigt mehr als 30 000 Mitarbeiter und ist weltweit mit eigenen Tochtergesellschaften auf dem Markt tätig.

Dementsprechend dezentral ist auch die Informatik organisiert, wobei die kommerzielle Informatik am Hauptsitz nebst lokalen Aufgaben auch die internationale Informatik-Koordination übernimmt. Die Informatik ist rechtlich selbständig und als Profit Center organisiert; sie erbringt aber nur Leistungen für den internen Gebrauch (also kein Angebot an Schindler-externe Kunden).

Operatives Kernstück der Informatik ist das RZ mit einem IBM-Rechner 3090-20J unter dem Betriebssystem MVS/ESA. Die Tool-Umgebung ist ebenfalls IBM-orientiert: CICS, DB2 und Application System (AS) sind im Einsatz. Bislang wurden die RZ-Ressourcen pauschaliert mit den internen Kunden verrechnet; der jeweilige Konsum wurde dabei nicht detailliert ausgewiesen.

Diese Lösung war weder kostentransparent noch verursachergerecht. Darüber hinaus fehlten Kennzahlen und Trendberechnungen über den RZ-Verbrauch, so daß die Planung und Budgetierung eher intuitiv und auf der Basis von Mutmaßungen erfolgte.

Aufgrund dieser unbefriedigenden Ausgangslage wurde von der Geschäftsleitung der INF beschlossen, eine Leistungsverrechnung der RZ-Ressourcen gemäß folgender Zielsetzungen aufzubauen:

- Kostentransparenz,

- Verursacherprinzip,

- Verbesserung der Planung und Budgetierung,

- höhere Effizienz der RZ-Benutzung.

Darauf aufbauend wurde ein Pflichtenheft erstellt, das neben den oben genannten Zielsetzungen folgende Anforderungen beinhaltete:

- Standardreport: detaillierter Kostenausweis auf der Stufe Anwender-Kostenstelle, Leistungsarten (CPU, I/Os etc.) und Applikationsgebiete (SAP, Batch-Produktiv etc.); - Führungsinformations-Reporting: Stand der Verrechnung, Ist-Soll-Diskrepanzen, Ausreißer-Analyse;

- Kompatibilität mit den Host-Tools und den installierten Meß-Werkzeugen (SMF, Omegamon, SAP-Accounting) der Informatik;

- keine Beeinträchtigung des operativen Systembetriebes.

Grundsätzlich wurde eine Paketlösung mit der Möglichkeit, unternehmensspezifische Ergänzungen vorzunehmen, angestrebt. Dies entspricht der Informatik-Strategie von Schindler, wann immer möglich Standardsoftware zur Problemlösung einzusetzen. Dabei sind wir auf die Leistungsverrechnungs-Software der USU GmbH im deutschen Möglingen gestoßen. Diese Paketlösung regelt maskengesteuert die Übernahme, Abrechnung und Auswertung der Account-Daten auf der Grundlage eines relationalen Datenbank-Management-Systems (DB2 respektive SQL/DS).

Nachdem sichergestellt war, daß die Software in der Schindler-Umgebung läuft, wurde ein gemeinsames Projektteam aus Mitarbeitern des Softwarehauses und der Schindler AG unter Leitung der Informatikabteilung gegründet. Das Ziel dieser Gruppe bestand darin, vom vorhandenen Know-how gegenseitig zu profitieren und gemeinsam eine effiziente und effektive Einführung sicherzustellen.

Bei der Realisierung hat das Projektteam folgende Punkte nacheinander bearbeitet:

1. Verrechnungsmodell: Durchführung einer DV-Kostenrechnung zur Erarbeitung von differenzierten Verrechnungspreisen auf einer Ist-Vollkosten-Basis.

2. Daten-Input: Analyse der Datenstruktur der Meß-Tools und Aufbau der Schnittstellen für die Übernahme der Meßdaten.

3. Stammdaten: Aufnahme und Eingabe der Kostenstellen, Budgetwerte, Leistungsnehmer (Jobnummern, User-IDs, Terminal-IDs).

4. Unternehmensspezifisches Reporting: Ausweis der relativen Konsumationen (Gewichtung der effektiven Werte mit dem Anteil am Budget).

5. Verbesserung der Performance: DB2-Tuning, Datenstraffung, Anpassungen der Standardsoftware (andere Plazierung des "Commit Work").

6. Produktionsübergabe: Dokumentation und Ausbildung der Systembetreuer.

Heute besitzt die Informatik ein RZ-Verrechnungssystem, das operativ eingesetzt wird. Sein detailliertes Reporting sorgt für die angestrebte Kostentransparenz. Von Anwender wie Informatikseite werden die ausgewiesenen Zahlen akzeptiert und als Basis für die Planung und Budgetierung verwendet. Die Performance des Verrechnungssystems ist zufriedenstellend und beeinträchtigt keineswegs den operativen RZ-Betrieb.

Der Betriebskostensatz beträgt (gemessen am Gesamtumsatz des RZ) zwei Prozent und liegt damit innerhalb der akzeptablen Bandbreite. Nach Erfahrungen anderer Anwender sollte der Betriebskostensatz nicht höher als drei Prozent sein. Eine Abweichung der angestrebten Ziele muß für folgende zwei Bereiche festgestellt werden:

1. Verursacherprinzip: Entgegen den ursprünglichen Zielsetzungen werden die Leistungen heute gemäß Budget fix verrechnet. Immerhin bauen die Budgets auf den effektiv konsumierten Werten des Vorjahres auf, so daß das Verursacherprinzip mit einem Jahr Rückstand zur Anwendung kommt.

2. Höhere Effizienz: Die Anwender sind nicht in der Lage, die ausgewiesenen Zahlen korrekt und sinnvoll zu interpretieren. Sie neigen vielmehr dazu, das Zahlenmaterial anzuzweifeln oder aber die falschen Schlüsse daraus zu ziehen (PC-Lösung anstelle der "teuren" Host-Lösung für Massendaten-Anwendungen!). Dies hat zur Folge, daß die Zahlen nur bis auf die Stufe der Abteilungsleiter ausgewiesen werden können.

Im Laufe des operativen Betriebes haben sich folgende zwei Problembereiche ergeben, denen anfangs kaum Beachtung geschenkt wurden, die aber Bedeutung bekommen haben und auch für andere Firmen relevant werden können. Erstens kann der Verbrauch des Online-Bereiches mit Meßinstrumenten bisweilen nur Ungenau bestimmt werden. Dies hat beim Unternehmszweig Informatik zwei Gründe:

- Die User-IDs sind nicht über alle Anwendungsgebiete sauber durchgezogen, so daß für die Identifikation der Transaktionen auf die Terminal-IDs zurückgegriffen werden muß. Diese können aber für Batch-Transaktionen (beispielsweise eine Verbuchung im SAP) nicht mehr zurückverfolgt werden, so daß ein signifikanter Anteil nicht mehr identifizierbar ist und via Umrechnungsfaktoren proportional aufgeteilt werden muß.

- Infolge der Eigenheiten von MVS-CICS kann ein einzelnes Online-Meßinstrument nie alle Ressourcenbelastungen vollständig aufnehmen; die fehlenden Werte müssen ebenfalls via Umrechnungsfaktoren proportional umgelegt werden. Die Diskrepanz zwischen Ist- und Soll-Werten erreicht bisweilen so eklatante Ausmaße, daß die Aussagekraft der Leistungsverrechnung tangiert wird. Der Erfahrungsaustausch mit anderen Unternehmen hat gezeigt, daß dies kein Einzelfall ist.

Der zweite Problembereich liegt in der Pflege der Stammdaten. Die Dynamik, die heute vom Markt ausgeht, erfaßt naturgemäß auch die Organisation und die Mitarbeiter eines Unternehmens. Die Folge davon sind Umorganisationen, Standortwechsel und eine hohe Mitarbeiterfluktuation. Davon sind sowohl die Stammdaten einer Leistungsverrechnung als auch Kostenstellen und Terminal-IDs betroffen.

So kann beispielsweise trotz Bereitstellung der entsprechenden Manpower die Anzahl falscher oder fehlender Terminal-IDs langfristig nicht auf einen marginalen Prozentsatz gesenkt werden. Der Grund ist wohl im fehlendem Wissen und Interesse der Anwender sowie in der nie zu vermeidenden Bürokratie zu suchen.

Unsere Informatikabteilung hat insofern die Konsequenzen aus den offenen Punkten gezogen, als sie versucht, möglichst schnell auf einen flächendeckenden Einsatz von User-IDs als Identifikationsnummer umzustellen (etwa durch Einführung von RACF). Dies sollte ihr ermöglichen, die Anzahl der identifizierbaren Transaktionen zu erhöhen und gleichzeitig die Fehlerrate bei den Stammdaten zu senken (User-IDs wechseln weniger häufig als Terminal-IDs).

Zusammengefaßt läßt sich sagen, daß es Sinn macht, für RZs eine Leistungsverrechnung mit detailliertem Ausweis der konsumierten Ressourcen aufzubauen und verursacherorientiert zu belasten. Hilfreich ist dabei, eine Standardsoftware zu wählen, die eine operativ einsetzbare Plattform mit modernen Tools und flexibler Erweiterungsmöglichkeit anbietet.

* Dr. Roland Schürmann ist bei der Schindler Informatik AG, Epigon/Schweiz, für den Bereich Datenarchitekturen zuständig.