Fehler im Kennzahlen-Management

Chaos in den Kennzahlen

04.03.2013
Von Rainer  Tesche
Kennzahlensysteme sind ein probates Mittel zur Kosten-Nutzen-Analyse in der IT. Leider machen Unternehmen bei der Anwendung gravierende Fehler.

Strategische Kennzahlensysteme haben die Eigenschaft, strategische Ausprägungen einer Organisation zu erfassen. Und in der Tat ist das Topmanagement weniger an der genauen Verfügbarkeit seiner Windows-Server im Monatsverlauf interessiert als vielmehr an konkreten strategischen Daten. Allerdings hat der theoretische Ansatz von oben herab (Top-down), wie er häufig über die oder in Anlehnung an die Balanced Scorecard verwirklicht wird, den Nachteil, dass er die tatsächliche Ausgestaltung der Organisation nicht oder nur unzureichend abbildet. Mit gravierenden Folgen: Viele Unternehmen haben es versucht, die meisten haben es bereut.

1. Out of the Box ist trügerisch

Mit Kennzahlen soll eine Organisation gesteuert werden. Das kann nur funktionieren, wenn die Kennzahlen charakteristische Merkmale einer Organisation erfassen. Eine Kennzahl zur "Produktivität der Windows-Administratoren" ist kaum sinnvoll, wenn das Unternehmen keine saubere Trennung der Ressourcenerfassung zwischen Windows- und Linux-Administratoren vornimmt. Besser wäre hier die übergreifende "Produktivität für Intel-Server" oder die "Produktivität für Midrange-Server". Kennzahlen "Out of the Box" sind zweifellos verlockend, und sie kommen überraschend häufig vor. Das starre Korsett mit standardisierten Messpunkten kann jedoch zu einer unreflektierten Sichtweise und Einschätzung führen. Kosten und Leistungen müssen auf Grundlage der bestehenden Struktur gemessen werden.

2. Irreführende Schätzungen

Der Top-down-Ansatz wird scheitern, wenn das Unternehmen die hierfür vorgesehenen Kennzahlen nicht vernünftig bilden kann. Sind die Basisdaten in der geforderten Form nicht vorhanden, müssen sie entweder geschätzt oder über eine mühsame Implementierung beschafft werden. Das Ergebnis ist entweder ungenau oder aufwendig zu bilden, so dass der Nutzen auf der Strecke bleibt.

Sind etwa die Zahlen für den SAN-Speicher gefragt? Manche Anwender haben Speicherschränke, in denen Mainframe-, SAN- und NAS-Storage steckt. Wenn der Anwender den Kostenanteil für den SAN-Speicher nicht genau zuordnen kann, ist eine Kennzahl für den gesamten Storage sinnvoller. Diese lässt sich leicht ermitteln und regelmäßig berichten.

3. Unscharfe Kennzahlen

Häufig kalkulieren Unternehmen mit fragwürdigen Werten, weil sie die benötigten Werte nicht messen können. So lässt sich die Zahl der Hardwaretypen im Windows-Umfeld nur schwer bestimmen, wenn die Geräte in unterschiedlichen Abteilungen eingesetzt werden und kein umfassendes Asset-Management existiert. Der Einfachheit halber wird dann die Kennzahl der unterschiedlichen Windows-Versionen herangezogen, weil diese durch die Softwarelizenzierung bekannt ist. Jedoch ist diese Zahl ein schwächerer Komplexitätstreiber als die Hardwaretypen, weshalb das Abbild der Organisation unscharf wird.

4. Top-Level-Informationen ohne Basis

Foto: mirpic, Fotolia.com

Wenn das Projekt vom Vorstand angestoßen wurde, müssen die angeforderten Zahlen geliefert werden. Durch die Verwendung grober Schätzwerte sind Drilldowns zu den tatsächlichen operativen Kennzahlen kaum möglich: Die Ursache-Wirkungs-Kette ist nicht belastbar. Schaltet eine Top-Level-Kennzahl auf Rot, erwartet das Management, dass der Grund hierfür bekannt ist oder zumindest schnell gefunden wird. Deshalb sind die richtigen Basisinformationen viel wichtiger für die Steuerung der Organisation als die Top-Level-Informationen. Ohne die passende Grundlage hängen die Top-Level-Kennzahlen in der Luft.

5. Verwirrende Komplexität

Kennzahlen berechnen sich nicht automatisch aus komplizierten Formeln. So ist beispielsweise die Zahl der Windows-Server eine reguläre Leistungskennzahl, die zudem für das Asset-Management benötigt wird. Auch bei umfassenden Kennzahlensystemen ist Komplexität kein Grundpfeiler des Erfolgs. Unternehmen müssen die richtige Balance finden zwischen einer realistisch machbaren Vorgehensweise und dem, was einen Leistungs-, Kosten-, Komplexitäts- oder Risikotreiber genau repräsentiert.

Derartige Systeme wirken selbstschärfend - man merkt schnell, wo die Organisation verfeinert werden muss, weil sie nicht rund läuft. Ein pragmatischer Ansatz, der auf der Realität aufsetzt, ist hier sinnvoller als der holistische Ansatz, der häufig von außen in das Unternehmen getragen wird. Es zählen vor allem kleine Schritte ohne großen Projektaufwand, beispielsweise auf Grundlage einer ABC-Analyse. Wo die meisten Ressourcen verbraucht werden, sollte die Feinabstimmung in der Regel zuerst ansetzen.

6. Fehlerhafte Umsetzung

Vor der Entwicklung eines Kennzahlensystems steht die Definition, welche Aspekte der IT konkret gesteuert werden sollen. Jeder IT-Verantwortliche hat seine eigene Philosophie und setzt andere Prioritäten: Einer bevorzugt Prozesse und ITIL, ein anderer plädiert für Services und Servicekataloge, der Dritte schließlich bleibt bei klassischen Funktionen wie der Anwendungsentwicklung und der Infrastruktur. Entsprechend müssen die Kennzahlen angeordnet werden.

Die Menge der Kennzahlen ist nicht zwangsläufig ein Treiber für die Komplexität des Systems. Entscheidend ist vielmehr, dass die benötigten Daten automatisiert erhoben werden. Zudem müssen Verantwortliche abgrenzen, was mit jeder Kennzahl gemeint ist: Zählt der neue Server bereits nach dem Auspacken oder erst, wenn er im Asset-Management verbucht wurde? Wie gelangt die Kennzahl ohne Aufwand in die Tabellenkalkulation oder Datenbank? Auch müssen Kennzahlen regelmäßig überprüft und angepasst werden. Die Welt dreht sich weiter, und Kennzahlen sollen die Welt der Organisation möglichst genau repräsentieren.

7. Falsche Schlüsse

"Normale" Kennzahlen haben einen kleinen Haken: Sie zeigen zumeist nur an, ob die Arbeit richtig gemacht wird - und nicht, ob die richtige Arbeit gemacht wird. So weist etwa Organisation A ein sehr gutes Kostenniveau bei ihren Unix-Servern auf, während Organisation B nur eine unterdurchschnittliche Performance bei ihren Mainframes zeigt.

Vergleicht man hingegen die Kosten für den einzelnen Bausparvertrag oder für das einzelne Depot bei beiden Organisationen, kann das Preis-Leistungs-Verhältnis schon ganz anders aussehen. Aus der Perspektive des Topmanagements stellt sich vielleicht die Leistung des relativ schlechten Mainframe-Bereichs besser dar als die Leistung der relativ guten Unix-Abteilung. An den geschäftlichen Stückkosten zeigt sich der Unterschied von Effektivität und Effizienz.

Fazit

Manager nutzen Kennzahlensysteme nur, wenn sie einen persönlichen Nutzen dadurch haben. So können Kennzahlen die eigene Leistung darstellen - in diesem Fall werden sie sogar gerne eingesetzt. Sind jedoch die Zahlen zu grob und nur mühsam zu beschaffen, wird das System nicht lange in Bewegung bleiben. Es schaltet in den Leerlauf, und niemand berichtet dem Topmanagement, dass dessen Vorgabe nicht zur Organisation passt. Dies bindet unnötige Ressourcen.

Ein pragmatischer Ansatz, der sich an der tatsächlich zu steuernden Organisation orientiert und schrittweise verbessert wird, ist sinnvoller als das Top-down-Modell. Nach vielen gescheiterten Projekten und einer scheinbar hohen Einstiegshürde bei der Einführung lässt sich daher leider nur die Bilanz ziehen: Insgesamt wird in der IT zu wenig über Kennzahlen gesteuert. (pg)