IT-Governance - Controlling

IT-Controlling

Ziele der Lektion

• Kennenlernen der Eingliederungsmöglichkeiten und Aufgaben des IT-Controllings
• Kennenlernen von Methoden und Instrumenten des IT-Controllings

Ebenso, wie sich das Verständnis der Rolle der IT im Unternehmen gewandelt hat, hat sich auch die Sichtweise auf das Controlling der IT verändert. Früher standen meist ausschließlich die von der IT verursachten Kosten im Mittelpunkt der Betrachtungen (reines Cost-Center). Mittlerweile liegt der Fokus des IT-Controllings auf der Darstellung von Leistungen, dem Wertbeitrag und dem Nutzen von IT im Unternehmen. Diese Sichtweise auf das IT-Controlling führt zu einer wirtschaftlichen Betrachtung der Ressource Information. IT-Controlling umfasst die kosten- und nutzenorientierte Steuerung und Verrechnung von Infrastruktur, Systemen, des Anwendungsportfolios und abgeschlossener Projekte, sowie die Planung und Überwachung von Projekten und Produkten im Bereich der IT. IT-Controlling soll neben der Effizienz und Effektivität der IT auch die Qualität, Funktionalität und Termintreue der Informationsverarbeitung sicherstellen. Das IT-Controlling hat dabei aber nicht nur eine Überwachungsfunktion, sondern auch eine Koordinationsfunktion für das gesamte Informationsmanagement.

IT-Controlling und IT-Management arbeiten eng zusammenarbeiten. Das IT-Controlling unterstützt das IT-Management beispielsweise bei der Entscheidungsfindung, Informationsaufbereitung und -bereitstellung und bei Koordinationsprozessen [TIE09, 400ff].

IT-Controlling als Führungsinstrument

Für die Planung und Steuerung von den in der IT anfallenden Aufgaben und Aktivitäten sind angestimmte Informations- und Kommunikationstätigkeiten nötig. Dafür müssen die IT-Verantwortlichen mit entsprechenden Instrumenten versorgt werden. Zunächst gilt es festzulegen, welche Informationen benötigt werden. Schließlich sind Informationen die Basis für jedes Führungshandeln, was selbstverständlich auch für den IT-Bereich gilt. Informationen bzw. das Informationswesen müssen dabei gewisse Anforderungen erfüllen. Informationen müssen einen hohen Aussagegehalt aufweisen, genau und eindeutig sein. Die Informationen müssen zeitgerecht und vollständig bereitgestellt werden. Eine leichte Zugänglichkeit, unmittelbare Verfügbarkeit und sichere Speicherung mit entsprechenden Zugangsbeschränkungen muss gewährleistet sein. Die Informationen müssen sinnvoll verdichtet sein bzw. verdichtet werden können und attraktiv dargestellt werden.

Die benötigten Informationen werden in der Regel mittels Kennzahlen ermittelt und in Kennzahlensystemen, die an die Unternehmensanforderungen ausgerichtet werden, der IT-Leitung oder dem CIO zur Verfügung gestellt. Kennzahlen und Kennzahlensysteme ermöglichen die strukturierte Erfassung, Analyse und transparente Darstellung von IT-Kosten und IT-Leistungen, was wiederum die Grundlage für adäquate Entscheidungen im IT-Bereich bildet.

Entscheidungsträger*innen benötigen zur zielgerechten Steuerung der IT-Aktivitäten in regelmäßigen Abständen geeignete Informationen. Nicht alle Empfänger*innen benötigen jedoch dieselben Informationen im selben Detaillierungsgrad. Für eine geeignete Berichterstattung muss Berichterstatter*in und Berichtempfänger*in, der Inhalt, die Form und der Zeitpunkt der Berichterstattung festgelegt werden. Damit wird gewährleistet, dass spezielle Zielgruppen mit spezifisch angepassten Berichten zu bestimmten Zeiten versorgt werden [TIE09, S378ff].

Kennzahlen und Reporting können somit als ein wesentliches Werkzeug zur Führung von IT-Abteilungen gesehen werden.

Organisatorische Einbindung des IT-Controllings

Die Einbindung des IT-Controllings hängt maßgeblich von der Form und Situation der Art und Weise, wie IT-Entscheidungen im Unternehmen getroffen werden, ab. Abhängig vom Ort, an dem die Entscheidung getroffen wird und den zugrunde liegenden Strukturen können sechs Entscheidungstypen unterschieden werden [TIE09, S403].

• Geschäftsmonarchie: Hier werden Entscheidungen durch die Geschäftsleitung getroffen.
• IT-Monarchie: Die Entscheidungen erfolgen durch den*die IT-Leiter*in oder eine Gruppe von IT-Verantwortlichen.
• Föderalismus: Bei diesem Typ werden die Entscheidungen durch Mitglieder des mittleren Managements aller operativen Geschäftsbereiche und durch den*die IT-Leiter*in gemeinsam getroffen.
• IT-Duopol: Hier treffen der*die IT-Leiter*in und Mitglieder der Geschäftsleitung die Entscheidungen.
• Feudalismus: Die Fachbereiche treffen jeweils selbständig die Entscheidungen
• Anarchie: Die Entscheidungen finden durch Nutzer(-gruppen) statt.

Je nach der Entscheidungssituation und Entscheidungstyp im Unternehmen ergeben sich verschiedene Fragestellungen für die organisatorische Einbindung des IT-Controllings [TIE09, S403].

• Welcher Abteilung soll das IT-Controlling organisatorisch zugeordnet werden?
• Soll eine eigenständige Abteilung für das IT-Controlling eingerichtet werden?
• Wie soll diese Abteilung personell besetzt werden?
• Wo soll die Abteilung des IT-Controllings im Unternehmen eingegliedert werden?
• Wie sollen die Aufgaben des IT-Controllings aufgegliedert werden?

Varianten der organisatorischen Eingliederung des IT-Controllings nach [TIE09, S404]

Nachdem das IT-Controlling wesentliche Unterstützungsfunktionen für das IT-Management zur Verfügung stellt, sollte es auch organisatorisch in der Nähe des IT-Managements angesiedelt werden.

Beim IT-Controlling sollte unterschieden werden, ob es sich um ein Controlling der IT-Leistungsverwendung oder Controlling der IT-Leistungsbereitstellung handelt. Da die IT-Leistungsverwendung in der Regel in den Fachbereichen stattfindet, sollte das Controlling der IT-Leistungsverwendung direkt in den Fachbereichen stattfinden. Das Controlling der IT-Leistungsbereitstellung sollte dagegen in der IT-Organisation stattfinden.

Da das IT-Controlling nun an mehreren Stellen erfolgt, besteht die Gefahr, dass die gleichen Aufgaben an unterschiedlichen Stellen erledigt werden müssen und dadurch unnötig Ressourcen verwendet werden. Bei stark verteilten Organisationen sollte daher überlegt werden, die einzelnen IT-Controllings zu einer zentralen Abteilung zusammenzufassen, um dadurch Synergieeffekte nutzen zu können und den Koordinationsaufwand gering zu halten.

Die Entscheidung, ob eine eigenständige Abteilung für das IT-Controlling eingeführt werden soll, hängt von der strategischen Bedeutung der IT, der Art der Leistungserbringung, vom Umfang und der Häufigkeit der IT-Nutzung und von der Unternehmensgröße ab. Wenn eine eigenständige Abteilung für IT-Controlling eingeführt werden soll, muss die Eingliederung der Abteilung in die Unternehmenshierarchie festgelegt werden. Üblicherweise wird das IT-Controlling in diesem Fall dem CFO (Chief Financal Officer) unterstellt.

Wenn das IT-Controlling als Querschnittsfunktion zur Unterstützung des unternehmensweiten Informationsmanagements aufgefasst wird, müssen Schnittstellen zu den Fachbereichen und der Controlling-Abteilung, sowie Entscheidungsbefugnisse für den Bereich des IT-Controllings festgelegt werden. Das IT-Controlling kann in diesem Fall als Stabstelle, Parallelorganisation oder Kombination in die Unternehmenshierarchie integriert werden [TIE09, S403ff].

Aufgaben des IT-Controllings

Grundsätzlich kann zwischen dem strategischen und dem operativen IT-Controlling unterschieden werden.

Das strategische IT-Controlling stellt den Abgleich der IT-Strategie mit den Unternehmenszielen in den Mittelpunkt. Damit soll die Effektivität der IT sichergestellt werden. Im Vordergrund der Betrachtungen stehen Wirtschaftlichkeit und die Versorgung des Unternehmens mit geeigneten Informationen.

Die Aufgaben im strategischen IT-Controlling umfassen die Festlegung geeigneter Maßnahmen und Projekte in der IT, die zu einer optimalen Zielerreichung führen. Damit soll die Entwicklung der IT-Strategie, deren wesentlicher Bestandteil die langfristige Ausrichtung der IT an den Geschäftsprozessen ist, unterstützt werden. Das strategische IT-Controlling liefert den Entscheidungsträger*innen somit auch Basisinformationen für die Weiterentwicklung der IT-Architektur. Durch das strategische IT-Controlling kann ein geeignetes IT-Projekt- und IT-Service Portfolio hinsichtlich der strategischen Relevanz und Effektivität sichergestellt werden [TIE09, S405ff].

Das operative IT-Controlling beschäftigt sich mit der effektiven Entwicklung von IT-Lösungen, einem reibungslosen IT-Betrieb, sowie mit der Weiterentwicklung und Wartung von Informationssystemen.

Die Aufgaben des operativen IT-Controllings umfassen Portfolio-, Projekt-, Produkt- und Infrastruktur-Controlling. Darüber hinaus wird ein Berichtswesen zur Steuerung und Kontrolle des Informationsmanagements benötigt, um die Entscheidungsfindung für das Management zu unterstützen. Das Portfolio-Controlling dient der Unterstützung bei der strategischen Planung von IT-Projekten mittels Planungsverfahren und Planungsinstrumenten. Die Beurteilung und Auswahl von künftigen, geplanten oder bereits existierenden Projekten soll erleichtert und die Transparenz bei laufenden Projekten verbessert werden. Das Projekt-Controlling soll das Projektmanagement bei der Durchführung von IT-Projekten unterstützen. Zu den Teilaufgaben gehören Projektplanung, -steuerung, -kontrolle und Analysen der Wirtschaftlichkeit. Das Produkt-Controlling soll die effektive und effiziente Nutzung eines fertiggestellten Produkts über den gesamten Produktlebenszyklus hinweg koordinieren und die Qualität und Funktionalität sicherstellen. Aufgabe des Infrastruktur-Controllings ist die Steuerung der Verfügbarkeit und die Weiterentwicklung einer geeigneten IT-Infrastruktur als Plattform für die Produkte der IT. Teilaufgaben sind dabei die Planung der IT-Infrastruktur, Unterstützung bei der Umsetzung und die Verrechnung der angefallenen Kosten [TIE09, S407ff].

Methoden und Instrumente im IT-Controlling

IT-Leistungsverrechnung

In einer modernen IT ist die Darstellung der IT-Kosten und der IT-Leistungen unumgänglich, was sich auch im Fokus des IT-Controllings wiederspiegelt. In der Praxis gewinnt die verursachungsgerechte Umrechnung der IT-Kosten auf Kostenstellen bzw. Kostenträger immer mehr an Bedeutung. Kostenstellen sind die Orte, an denen die Kosten entstehen (z.B. Betrieb, Entwicklungsabteilung, Service-Desk etc.), wohingegen Kostenträger angeben, wozu die Kosten entstanden sind (z.B. bestimmtes IT-Service, IT-Produkt etc.). Durch die Einführung einer (internen) IT-Leistungsverrechnung, sollen die in der IT durch die Bereitstellung von Leistungen anfallenden Kosten an die leistungskonsumierenden Fachbereiche bzw. Kund*innen verrechnet werden.

Es existieren einige Vorteile, die durch die Einführung der IT-Leistungsverrechnung erwartet werden können. Sowohl für Anwender*innen als auch für den IT-Bereich selbst wird die Transparenz der IT-Kosten und IT-Leistungen höher. Basisdaten für aktives IT-Kostenmanagement können zur Verfügung gestellt werden. Dadurch kann eine systematische Planung, Kontrolle und Steuerung der IT-Kosten erfolgen. Das Kostenbewusstsein innerhalb des IT-Bereichs, aber auch innerhalb der Fachbereiche wird gesteigert. Basisdaten für ein Benchmarking der internen IT-Leistungen im Vergleich zu externen Dienstleister*innen können bereitgestellt werden und somit Unterstützung bei Outsourcing-Entscheidungen geben [TIE05, S40f].

Leistungsverrechnung durch Umlageverfahren

Ein Umlageverfahren kann rasch und unkompliziert umgesetzt werden. Beim Umlageverfahren werden die IT-Kosten über passende Bezugsgrößen (z.B. Anzahl der Workstation, Anzahl der Mitarbeiter*innen, Anzahl der Lizenzen etc.) pauschal verteilt. Eine verursachungsgerechte Verrechnung der IT-Kosten ist durch dieses Verfahren allerdings nur sehr bedingt gegeben.

Direkte Leistungsverrechnung

Bei der direkten Leistungsverrechnung sollen nur die wirklich in Anspruch genommenen Leistungen (Leistungsarten) verrechnet werden. Für diese Leistungsarten werden Messgrößen und Tarife festgelegt. Beispiele sind dazu Anzahl gedruckter Seiten, Dauer für Programmierleistungen, in Anspruch genommene Rechenleistung etc. Bei diesem Verfahren können Kosten verursachungsgerecht und transparent verrechnet werden. Nachteil bei dieser Methode ist jedoch, dass sich Unwirtschaftlichkeit in der IT direkt auf die Tarife, nämlich erhöhend, auswirkt.

Produktorientierte (serviceorientierte) Leistungsverrechnung

Basis der produktorientierten Leistungsverrechnung sind die von der IT zur Verfügung gestellten IT-Produkte oder IT-Services. Dazu müssen die angebotenen Leistungen oder IT-Services in einem Servicekatalog für die Kunden beschrieben werden. Servicekataloge sind häufig in IT-Services, Servicemodule und Serviceelemente gegliedert. Durch diese Gliederung können den Kunden klar abgrenzbare Leistungsbeschreibungen angeboten werden, deren Leistungsumfang, Qualität und Menge und somit auch der Preis auf Servicemodulebene durch den Kunden beeinflusst werden kann.

Gliederungsebenen zur Strukturierung des Serviceangebots [nach TIE09, S430]

Die Servicemodule bieten somit Wahlmöglichkeiten in Bezug auf die angebotene Leistung. Die Serviceelemente beschreiben Pakete von IT-Ressourcen oder Teilservices des IT-Bereichs, die zur technischen Umsetzung der angebotenen IT-Leistung (Servicemodule) benötigt werden.

Beispiel Servicegestaltung E-Mail [nach TIE09, S430]

Prozessreifegrad-Modelle

Bei Prozessreifegrad-Modellen wird mittels Stufen das Niveau eines Prozesses bestimmt.

Zwei gängige Modelle sind

• CMMI (Capability Maturity Model Integrated)
• ISO IEC 15504, SPICE (Software Process Improvement and Capabiltiy Determination)

In den beiden Modellen CMMI und SPICE werden sechs, aufeinander aufbauende Stufen (Reifegrade) definiert.

Reifegrade nach CMMI und SPICE [eigene Darstellung]

Capability Level 0: Incomplete Process

Der Prozess ist nicht implementiert oder verfehlt seinen Zweck. Folgen sind unvollständige oder fehlerhafte Ergebnisse, Termin- und Kostenüberschreitungen.

Capability Level 1: Performed Process

Der Prozess ist implementiert und erfüllt im Großen und Ganzen seinen Zweck. Es kommt zu brauchbaren Ergebnissen mit einer einigermaßen akzeptablen Kosten-Nutzen-Relation. Allerdings ist die erfolgreiche Abwicklung stark von den handelnden Personen und von günstigen Rahmenbedingungen abhängig.

Capability Level 2: Managed Process

Prozesse auf Stufe 2 sind geplant und beschrieben. Es wurden Ziele für die Prozessdurchführung definiert und der Prozess wird überwacht und gesteuert.

Capability Level 3: Established (Defined) Process

Auf Basis der Erfahrungen mit Prozessen der Stufe 2 wurden unternehmensweite Standardprozesse definiert. Spezielle Prozessausprägungen werden von diesen Standardprozessen abgeleitet. In dieser Stufe können Prozessmessungen durchgeführt werden.

Capability Level 4: Predictable (Quantitatively Managed) Process

Messungen der Standardprozesse liefern Erkenntnisse über die Leistung des Prozesses. Auf Basis dieser Erkenntnisse können die Prozesse gesteuert werden. Prozessziele können über Kennzahlen vorgegeben werden und die Zielerreichung kann wiederum anhand von Kennzahlen gemessen und bewertet werden.

Capability Level 5: Optimizing Process

Auf dieser Ebene ist ein systematischer Regelkreis zur Prozessverbesserung möglich: Mit Messungen des Prozesses werden Schwachstellen dokumentiert. Analysen decken diese Schwächen auf. Die Ursachen der Schwachstellen werden untersucht und eliminiert und damit die Prozesse systematisch verbessert. Der Erfolg kann durch die Kennzahlen gemessen werden [TIE09, S465ff].

Reifegradmodelle

Der Reifegrad eines Prozesses gibt darüber Auskunft, wie sehr dieser entwickelt und optimiert ist, mit Fehlläufen und sich ändernden Rahmenbedingungen umgeht. Reifegradmodelle gibt es viele; gemein ist allen Modellen die Einteilung von Geschäftsprozessen nach definierten Kriterien, um sie objektiv miteinander anhand dieser Kriterien, welche die Skaleneinteilung bestimmen, vergleichen zu können. Der Reifegrad liefert somit auch eine Aussage zur Effizienz und Effektivität des Geschäftsprozesses. Jedenfalls stehen hier die Bewertung der aktuellen Entwicklungsstufe und die evolutionäre schrittweise Entwicklung der Prozessreife im Vordergrund.

Den Klassiker der Reifegradmodelle bildet jene Reifegradeinteilung des CMMI-Modells, wobei das Akronym für Capability Maturity Model Integration (CMMI) steht. Entstanden ist CMMI aus der Software-Entwicklung. Im Jahre 1991 veröffentlichte das Software Engineering Institute (SEI), eine Universitätsorganisation der Carnegie Mellon University in Pittsburgh, die dem US-Verteidigungsministerium unterstand, ein System zur Bewertung der Reifegrade von Software-Prozessen unter dem Namen Capability Maturity Model (CMM). Im Jahre 2002 änderte man im Zuge einer Weiterentwicklung den Namen offiziell auf CMMI und in den Folgejahren kamen spezifische CMMI-Modelle für Organisationen, die sich mit der Entwicklung von Software oder Hardware (CMMI for Development, CMMI-DEV), mit Einkauf von Software oder Hardware (CMMI for Acquisition, CMMI-ACQ) oder für Servicedienstleistungen (CMMI for Services, CMMI-SVC) beschäftigen, heraus [CMM09].

Das gesamte CMMI-Modell beinhaltet eigentlich mehr Aspekte als die Reifegradeinteilung. Es gibt einen Überblick über themenspezifische bewährte Praxisumsetzungen, versucht die Stärken und Schwächen möglichst objektiv zu beurteilen und hat dabei die nachhaltige Verbesserung von Prozessen in einer Organisation zum Ziel. Auch ist dabei nicht nur die Dokumentation der Prozesse alleine, sondern auch deren tatsächliche Implementierung relevant, also ob der Prozess in der Praxis tatsächlich gelebt wird. Das Reifegradmodell aus CMMI gilt jedoch mittlerweile als eine anerkannte Methode für die Messung der Prozessreife, auf die sich diese Ausführungen beschränken.

Das CMMI-Reifegradmodell beschreibt fünf Evolutionsstufen:

• 1 – Initial: Es bestehen in der Grundstufe keine Anforderungen.
• 2 – Managed: Eine Vorgehensweise kann für andere ähnliche Aufgaben wiederholt werden.
• 3 – Defined: Ein Standardprozess wird angewandt und eine kontinuierliche Prozessverbesserung existiert.
• 4 – Quantitatively Managed: Eine Prozesskontrolle wird durchgeführt.
• 5 – Optimizing: Die Vorgehensweise wird durch Prozesskontrolle verbessert.

Diese grundlegende Einteilung in diese Stufen existiert in Abwandlungen auch in anderen Publikationen, etwa Software Process Improvement and Capability Evaluation/Determination (SPICE), ISO 9004, allgemein im Geschäftsprozessmanagement, in unternehmensspezifischen Varianten von Reifegradmodellen etwa bei IBM oder Siemens, oder eben z.B. in CobiT:

Reifegradmodell, Variante aus CobiT [COB07, Seite 18]

CobiT – immer mit dem Fokus auf interne Kontrollen – führt hier noch eine Stufe 0 ein, die ausdrückt, dass überhaupt kein Prozess vorhanden ist. Die Stufe 1 repräsentiert ja schon zumindest ein Bewusstsein über eine gewisse Vorgehensweise, wenn sie auch ad hoc ist. In dieser Abbildung wird auch visualisiert, welchen Reifegrad das beurteilte Unternehmen im Hinblick auf diesen Prozess momentan aufweist, wo der Branchendurchschnitt steht und welcher Zielreifegrad angepeilt wird.

Da es nicht wirklich sinnvoll ist, einen Reifegrad für einen Prozess an sich global zu bestimmen, bedient man sich daher verschiedener Attribute, die einzeln bewertet werden. Für die grundlegende Aussagekräftigkeit bei allen Reifegradmodellen kommt der Auswahl der zu bewertenden Attribute eine entscheidende Bedeutung zu. Diese ist – je nach angewendeter Variante des Reifegradmodells – unterschiedlich und auf die Zielsetzung der ausgewählten Methode zugeschnitten. Die definierten Attribute, nach denen der Reifegrad in der Folge ermittelt wird, lauten in CobiT [COB07, Seite 20]:

• Bewusstsein und Kommunikation
• Richtlinien, Standards und Verfahren
• Werkzeuge und Automatisierung
• Fähigkeiten und Erfahrung
• Zuständigkeit und Verantwortlichkeit
• Zielsetzung und Messung

Diese Prozessattribute können nun gewichtet oder anderweitig zueinander in Beziehung gesetzt werden, wenngleich die pauschale Aussage „ein Prozess hat einen Reifegrad von Stufe 3“ kritisch hinterfragt werden muss. Demgegenüber steht der Wunsch nach einer plakativen Aussage.

Der Begriff Reifegrad bezieht sich auf die Prozess-Fähigkeit („Reife“) und lässt keinen Schluss auf die Prozess-Performance zu. Dies ist die Aufgabe von Key Performance Indicators (KPI). Das heißt also, dass ein Prozess mit dem Reifegrad 4 keine Aussage darüber liefert, wie rasch er durchlaufen wird. Es ist auch nicht gesagt, dass für jeden Prozess die Stufe 5 erreicht werden muss. Vielmehr muss die Organisation den für sie adäquaten Prozessreifegrad anstreben, abhängig von Geschäftszielen, Umgebungsfaktoren und Branchenaspekten [COB07, Seite 20].

Zusammengefasst stellen Reifegradmodelle eine generische Möglichkeit der Bewertung von Entwicklungsstufen von Prozessen im Unternehmen dar. Sie definieren Anforderungen, legen eine Skala zu Vergleichszwecken – sowohl Soll zu Ist als auch innerhalb einer Branche – fest und bieten somit eine Unterstützung für Gap-Analyse und Entwicklung von Verbesserungsmaßnahmen, um den Reifegrad eines Prozesses oder eines Prozessattributes zu heben.

Referenz-Prozessmodelle

Referenz-Prozessmodelle definieren im Allgemeinen eine einheitliche Begriffswelt und eine Reihe von Prozessgebieten oder Prozessen für ein bestimmtes Anwendungsgebiet. Jedes Prozessgebiet oder Prozess wird meist durch eine Reihe von Elementen beschrieben, wie beispielsweise Zweck, Inputs, Ergebnisse, Rollen und eine Reihe an in der Praxis erprobten Praktiken (Best-Practices). Referenz-Prozessmodelle definieren Prozessanforderungen in Hinblick auf die Best-Practice-Sammlung und sind oftmals die Grundlage für Zertifizierungen [TIE09, S469].

Softwareentwicklung	* ISO/IEC 12207 (Information technology - Software lifecycle processes) CMMI (Capability Maturity Model Integrated) RUP (Rational Unified Process) MSF (Microsoft Solution Framework Process)
IT-Service Management	ITIL (Infrastructure Library) ISO/IEC 20000 (ISO Standard für IT-Service Management) CobiT (Control Objectives for IT)
IT-Security Management	ISO/IEC 27001 (Information technology – Security techniques) Das deutsche Grundschutzhandbuch Das IT-Sicherheitshandbuch des Bundes (Österreich)

Tab. 4.1: Beispielhafte Referenz-Prozessmodelle

IT-Kennzahlensysteme

Mit IT-Kennzahlen können Informationen für das IT-Management und das IT-Controlling bereitgestellt werden. Mit IT-Kennzahlen können Ist- und Soll-Zustände abgebildet werden. So lässt sich beispielsweise die Leistungsfähigkeit der IT-Systeme, die Betreuung von IT-Anwendungen, die Durchführung von IT-Projekten oder der Einsatz von Ressourcen mit Kennzahlen beschreiben. Mittels IT-Kennzahlen können IT-Bereiche und die von ihnen erbrachten Leistungen beurteilt werden.

IT-Kennzahlen können in absoluten Zahlen, wie beispielsweise Einzelzahlen, Summen, Differenzen, Mittelwert und Verhältniszahlen, wie z.B. Beziehungszahlen, Gliederungszahlen, Indexzahlen unterteilt werden [TIE05, S133f].

Absolute IT Kennzahlen sind beispielsweise

• Anzahl Server (Gesamtzahl)
• Anzahl erfolgreicher Changes (Gesamtzahl)
• Antwortzeit eines IT-Systems (Gesamtzahl)
• Durchschnittliche Ausfallszeit eines Services (Mittelwert)

Verhältnis-Kennzahlen für die IT sind beispielsweise

• Anteil IT-Kosten/Gesamtkosten (Gliederungszahl: Anteile gleicher Bezugsgrößen)
• Anteil IT-Kosten/Umsatz (Beziehungszahl: Anteile unterschiedlicher Bezugsgrößen)
• Entwicklung des IT-Budgets in den letzten 5 Jahren (Indexzahl)

Kennzahlen sollten bestimmte Eigenschaften erfüllen:

• Zweckneigung: Informationsbedarf und bereitgestellte Information müssen übereinstimmen
• Genauigkeit: Die Information muss zuverlässig, vollständig und genau sein
• Aktualität: Der Zeitraum zwischen Messung und Bereitstellung sollte möglichst gering sein
• Kosten-Nutzen-Relation: Der Einsatz der Kennzahl darf nicht mehr Kosten verursachen, als ihr Wert für das Unternehmen ausmacht
• Einfachheit und Nachvollziehbarkeit: Es muss nachvollziehbar und zurück verfolgbar sein, wie die Kennzahl zustande gekommen ist. Der Empfänger muss die Kennzahl interpretieren können

Ein Kennzahlensystem wird durch eine Gruppe von Kennzahlen gebildet, die den Zustand eines Systems entsprechend darstellen soll. Ein Kennzahlensystem wird zur Steuerung und Überwachung dieses abgebildeten Systems genutzt. Um die Steuerung zu ermöglichen, müssen im Kennzahlensystem neben den aktuellen Zuständen auch Zielzustände und die tolerierbaren Diskrepanzen zwischen IST und SOLL beschrieben werden. Zu beachten ist dabei, dass zu jedem Zeitpunkt der aktuelle Zustand des abgebildeten Systems adäquat beschrieben ist, anhand des Kennzahlensystems der Sollzustand des Systems beschreibbar ist, und dass der Grad der Abweichung zwischen Ist- und Sollzustand erkennbar ist.

Beim Aufbau eines Kennzahlensystems muss auf die Anzahl der integrierten Kennzahlen geachtet werden. Einerseits bedeutet eine große Anzahl an Kennzahlen einen hohen Aufwand für Wartung und Betrieb des Systems. Andererseits geht eine Erhöhung der Anzahl der Kennzahlen nicht unbedingt mit dem Nutzenzuwachs bei den Anwendern des Systems einher, eher das Gegenteil ist der Fall [TIE09, S417f].

Für den Aufbau und die Implementierung eines Kennzahlensystems für den IT-Bereich kann folgende Vorgehensweise gewählt werden [TIE05, S135f]:

Phasen für Aufbau und Implementierung eines Kennzahlensystems [eigene Darstellung]

Planung: In dieser Phase werden die Zielvorgaben festgelegt und Erfolgsgrößen bestimmt.

Sammlung der benötigten Kennzahlen: Ausgehend von möglichen Kennzahlen (z.B. in vorgeschlagenen Kennzahlenkataloge wie in ITIL) werden in Abgleich mit den definierten Anforderungen jene Kennzahlen ausgewählt, die mit vertretbaren Aufwand erhoben werden können und dabei den größten Nutzen aufweisen.

Systematisierung, Strukturierung und Priorisierung der Kennzahlen: Die ausgewählten Kennzahlen sollten nach bestimmten Kriterien strukturiert und gegliedert werden. Die Gliederung kann beispielsweise nach Zeitebenen (Tages-, Monats-, Quartalskennzahlen usw.), nach Sichten (Leistung, Aufwand, Qualität usw.) oder entlang der Wertschöpfungskette (Prozesse, Produkte, Kunden, Lieferanten usw.) erfolgen. Durch die Strukturierung und Gliederung der Kennzahlen kann sich auch eine Priorisierung ergeben.

Definition und Interpretation der Kennzahlen: In dieser Phase werden die Kennzahlen exakt definiert und erfasst. In weiterer Folge werden die Kennzahlen interpretiert und für die weitere Nutzung im Controlling bestätigt.

Festlegen der Methoden und Werkzeuge: Hier werden die Methode zur Sammlung und Auswertung der Daten, sowie geeignete Softwarewerkzeuge bestimmt und ausgewählt.

Implementierung des softwaregestützten Kennzahlensystems: Bei der Implementierung sind bestehende Anwendungen des IT-Controllings und deren Eignung für die Implementierung des erstellen Kennzahlensystems zu berücksichtigen.

Für die Nutzung der Ergebnisse der Kennzahlendefinition ist ein fundiertes Berichtswesen eine wesentliche Voraussetzung. Das Berichtwesen muss dabei die unterschiedlichen Adressaten (Geschäftsleitung, IT-Leitung, Controlling usw.) der Berichte sowie deren unterschiedlichen Informationsbedarfe (Detaillierungsgrad, unterschiedliche Verdichtungsstufen etc.) berücksichtigen. Die Form der Berichte muss deshalb hinsichtlich Zielgruppe, Inhalt und Zeitpunkt der Berichterstattung angepasst werden [TIE09, S421].

Balanced Scorecard (BSC)

Die Balanced Scorecard (BSC) wurde 1997 von Robert S. Kaplan und David P. Norton in Harvard entwickelt und publiziert. Es definiert eine überschaubare Anzahl von strategischen Geschäftszielen – in der Literatur wird das Formulieren von zwei bis zu fünf Zielen empfohlen. Diese werden durch Messgrößen – sogenannte Key Performance Indicators (KPI) – ausgedrückt, für die Zielwerte und in weiterer Folge Maßnahmen festgelegt werden können. Die KPIs münden dann in ein gesamtheitliches Kennzahlensystem („scorecard“) [SCS08, Seite 260ff]:

Die definierten KPIs bilden strategische Ziele ab und machen sie messbar. Durch die verschiedenen Perspektiven soll das Management ein ausgewogenes („balanced“) Bild aller relevanten Unternehmensaspekte bekommen und somit verhindert werden, dass man sich rein an den klassischen finanziellen Aspekten orientiert. Um komplexere Unternehmensstrukturen abbilden zu können, wird top down eine Hierarchie von Balanced Scorecards definiert, die logisch miteinander in Beziehung stehen. Dadurch können auf jeder Unternehmensebene – also ausgehend vom Unternehmen, Geschäftsbereiche, Geschäftseinheiten, Geschäftsprozesse – BSCs definiert werden, die sich an den strategischen Zielen der jeweils höheren Geschäftsebene orientieren. Die Messergebnisse werden dann nach oben hin aggregiert und tragen jeweils ihren Teil zur Erreichung der strategischen Ziele auf Unternehmensebene bei [SCS08, Seite 262].

Durch einen laufenden Prozess, der die aktuellen Maßzahlen erhebt und mit dem gesetzten Sollwert vergleicht, ist die strategische Zielerreichung quantifizierbar. Es ist dadurch möglich, bei einer unerwünschten Entwicklung frühzeitig Korrekturmaßnahmen zu setzen, um die strategischen Ziele schlussendlich zu erreichen. Die Balanced Scorecard ist ein allgemeines Konzept, das als IT Balanced Scorecard angewendet werden kann, wenn es sich rein auf IT-Prozesse beschränkt.

Durch die Auswahl einer überschaubaren Anzahl von KPIs wird die Komplexität reduziert und auch nicht-monetäre Ziele miteinbezogen. Außerdem werden durch die logische Verbindung der Geschäftsebenen Wirkungszusammenhänge zwischen den Zielen transparenter. Jedoch ist es erforderlich, die Grundannahmen für die KPI-Definitionen regelmäßig zu hinterfragen, denn die Gefahr ist absolut evident, dass hier das blinde Ausrichten nach Maßzahlen zu einer ausschließlich KPI-getriebenen Vorgehensweise führt, die sich weniger an Prozessqualität, sondern mehr an der Erfüllung der in Zahlen ausgedrückten Ziele orientiert. Dies kann zu einer oberflächlichen und damit substanzlosen Betrachtung der Kennzahlen führen oder manipulative Energie insofern freisetzen, indem versucht wird, die Darstellungsarten für einzelne Geschäftsebenen zu optimieren, was dem Prinzip der Ausgewogenheit der Balanced Scorecard offensichtlich widerspricht. Die Gefahr ist hier umso größer, wenn einzelne Mitarbeiterziele oder -bonifikationen daran geknüpft sind. Außerdem kann die Setzung von falschen oder unrealistischen Zielen mit einer BSC nicht verhindert werden.

Die Balanced Scorecard (BSC) kann als zentrale Methode bei der Festlegung von Zielen gesehen werden. Die BSC ist ein Kennzahlensystem, das nicht nur finanzwirtschaftliche Kennzahlen betrachtet, sondern auch qualitative Einflussgrößen, wie beispielsweise Qualität oder Zufriedenheit berücksichtigt. Die BSC erfasst Kennzahlen aus unterschiedlichen Dimensionen, die als Perspektive bezeichnet werden und über Ursache-Wirkungszusammenhänge miteinander verbunden werden.

Im Prinzip besteht eine BSC aus den folgenden vier Perspektiven,

Vier Perspektiven einer BSC [eigene Darstellung]

• Finanzwirtschaftliche Perspektive: versucht neben den Kosten- und Budgetzielen der IT die Frage nach dem Strategiebeitrag der IT abzudecken (bspw. Kosteneffizienz der IT, ROI zur Bemessung des Beitrags von IT- Projekten)
• Kundenperspektive: deckt die Wahrnehmung der internen und ggf. auch externen Kunden auf die IT ab (bspw. Zufriedenheit der Anwender mit den Leistungen des IT-Services oder der Entwicklung)
• Prozessperspektive: nimmt die IT-Prozesse mit maßgeblichem Verbesserungspotenzial in den Fokus (bspw. Produktivitätskennzahlen des Betriebs oder der Entwicklung, Grad der Standardisierung von Infrastruktur oder Anwendungslandschaft)
• Lern- und Entwicklungsperspektive: dient zur Beantwortung der Frage, welche Voraussetzungen in der IT geschaffen werden müssen, um zukünftige Herausforderungen bzw. Anforderungen bedienen zu können (bspw. Mitarbeiterkompetenz, wiederverwendbare technologische Basis, Partnerschaft zwischen IT und funktionalem Management, Reifegrad der Applikationslandschaft)

die jedoch nach Bedarf und Anwendungsfall verringert, erweitert oder umbenannt werden können. Wichtig für den Einsatz einer BSC sind die gewissenhafte Ausarbeitung der Ursache-Wirkungszusammenhänge und deren Hinterlegung mit eindeutigen Kennzahlen.

IT-Balanced Scorecard

Ausgehend von der IT-Strategie werden für jede Perspektive operative Ziele ermittelt und entsprechende Kennzahlen festgelegt. Aus den IT-Zielen (z.B. Kosten- oder Leistungsziele) und der IT-Strategie werden für die einzelnen Perspektiven die Erfolgsfaktoren (z.B. Prozessqualität, Mitarbeitermotivation, Kundenzufriedenheit etc.) definiert, die sich wesentlich auf die Zielerreichung auswirken. Die Ursache-Wirkungszusammenhänge müssen dabei korrekt abgebildet sein. Für jeden Erfolgsfaktor werden korrespondierende Kennzahlen bestimmt, die eine Überwachung und Steuerung des betreffenden Erfolgsfaktors ermöglichen. Schließlich werden die Erfolgsfaktoren mit Sollwerten hinterlegt und Verantwortlichkeiten, sowie Maßnahmen bei Nichterreichung festgelegt [TIE09, S416f].

Perspektive	Fragestellung	Kennzahlen
Finanzperspektive	Welchen Beitrag leistet die IT zum Unternehmenserfolg? Wie lässt sich der IT-Wartungsaufwand reduzieren?	Budgetentwicklung IT-Kosten / Mitarbeiter Wartungskostenanteil Investitionsaufwand Vergleich Ist-/Soll-Budget TCO je Arbeitsplatz
Kundenperspektive	Wie lässt sich die Kundenzufriedenheit steigern? Wie beurteilen Anwender die IT-Leistungen	Nutzungsgrad Service-Zufriedenheit Anzahl der SLA-Überschreitungen
Prozessperspektive	Wie lassen sich IT-Prozesse beschleunigen? Wie kann die Qualität der IT-Prozesse gesteigert werden?	Anzahl der Supportanfragen pro Monat Dauer der Störungsbehebung Durchschnittliche Bearbeitungszeit von Changes
Lern- und Entwicklungsperspektive	Über welche Potenziale verfügen die IT-Experten im Unternehmen? Wie lässt sich die Kompetenz der Mitarbeiter verbessern?	IT-Mitarbeiterquote Anzahl der Verbesserungsvorschläge Interesse an Weiterbildung Fluktuationsquote

Tab. 4.2: Perspektiven, Fragen und Kennzahlen in einer IT-BSC nach [TIE05, S145f]

Durch die Einführung einer IT Balanced Scorecard soll eine Reihe an Zielen verfolgt werden. Es soll eine ganzheitliche Diskussions- und Kommunikationsplattform für alle Zielgruppen entwickelt werden. Das kann dadurch erreicht werden, indem das Management die IT-BSC als einzig gültige Diskussion- und Kommunikationsplattform bestimmt. Mit der IT-BSC soll ein konsistentes Führungsinstrument zur Klärung der IT-Strategie geschaffen werden. Das kann durch die zweckmäßige Aufteilung der IT-BSC in Perspektiven und strategische Themen erreicht werden. Die Perspektiven ergeben einen Bezugsrahmen, um alle relevanten strategischen Fragestellungen thematisch zu positionieren und im Rahmen der IT-Strategieentwicklung zu klären. Durch die IT-BSC soll ein ausgewogenes IT-Kennzahlensystem zur Operationalisierung der IT-Strategie aufgebaut werden. Durch Einführung einer IT-BSC soll die Umsetzung strategischer Maßnahmen im IT-Bereich unterstützt werden, indem eine konsequente Überwachung der eingeleiteten Maßnahmen im IT-Bereich ermöglicht wird. Die IT-BSC soll die Transparenz und Performance-Orientierung erhöhen. Transparenz kann durch Vereinbarung und Messung von Zielvorgaben gewährleistet werden. Eine Performance-Orientierung wird dann erreicht, wenn die IT-Ziele in die Zielvereinbarung zwischen dem Management, den Vorgesetzten und den einzelnen Mitarbeitern einfließen. Durch die Einführung der IT-BSC soll auch ein einheitliches Planungs- und Reportinginstrument für den IT-Bereich aufgebaut werden.

Benchmarking

Es ist für ein Unternehmen durchaus interessant zu erfahren, wie es z.B. im Vergleich mit anderen Unternehmen oder Organisationseinheiten dasteht. Daher ist ein sogenanntes Benchmarking ein probates Mittel, eine Standortbestimmung durchzuführen, um daraus Maßnahmen ableiten und sich punktuell in den schwachen Bereichen zu verbessern und die Stärken weiterzuentwickeln. Die Anfänge gehen bis in das Jahr 1979 zurück, als das Unternehmen Xerox unter der Leitung von Robert C. Camp sich aufgrund der zunehmenden Konkurrenz aus dem asiatischen Raum mit strukturierten Wettbewerbsvergleichen beschäftigte. Nach ihm ist Benchmarking die Suche nach den besten Industriepraktiken, die zu Spitzenleistungen führen [CAM94 nach HOC10, Seite 3].

Benchmarking kann aber verschiedene Ausprägungen aufweisen [HOC10]:

• internes Benchmarking vergleicht z.B. dieselbe Funktion in verschiedenen Filialen desselben Unternehmens miteinander;
• branchenspezifisches Benchmarking (Wettbewerbs-Benchmarking) untersucht die Performance von Bereichen von Unternehmen, die im selben Marktsegment tätig sind;
• funktionales Benchmarking stellt dieselbe Funktion von unterschiedlichen Unternehmen zum Vergleich;
• allgemeines oder generisches Benchmarking stellt völlig unverwandte Unternehmen mit unterschiedlichen Funktionen gegenüber, wobei Prozesse und Methoden die Basis für den Vergleich darstellen.
• etc.

Benchmarking ist an sich ein Zielerreichungsprozess, wobei Benchmarks Methoden und Verfahren beschreiben, gesetzte konkret quantifizierbare Zielvorgaben zu erreichen. Im Rahmen eines Zehn-Schritte-Prozesses werden die Phasen Planung, Analyse, Integration, Aktion und Reife durchlaufen [HOC10, Seite 6].

Vor allem die erforderlichen Informationen in der Planungsphase zu bekommen, ist für ein einzelnes Unternehmen, das sich insbesondere in einer Marktsituation mit seinen Marktbegleitern befindet (also mit den Konkurrenten, mit denen es sich ja vergleichen möchte), de facto unmöglich. Es muss ein unabhängiger Mittler – in der Regel ein Beratungsunternehmen – engagiert werden, der dies bei den Teilnehmern jeweils – und das ist essentiell – nach der gleichen Methodik mit der gleichen Zielsetzung durchführt. Andere Fragen betreffen den Umfang und die Genauigkeit der Daten, prinzipielle Vergleichbarkeit, Informationsquellen und Kosten der Informationsbeschaffung oder Zeitaufwand, mit denen man sich auseinandersetzen muss. Ähnlich wie bei der KPI-Ermittlung müssen die Messgrößen und Ermittlungsmethoden definiert werden, um einen fairen Vergleich zu ermöglichen.

Des weiteren muss eine kritische Anzahl an Unternehmen an diesem Projekt teilnehmen, um sinnvolle Ergebnisse zu liefern. Damit gehen natürlich Fragen der Verrechnung, Datenschutz und konkreten Nutzen für die einzelnen teilnehmenden Organisationen einher. Der Mittler muss die Ergebnisse auch soweit anonymisieren, dass es für die jeweils anderen unmöglich ist, auf den ursprünglichen Informationsgeber zu schließen, weil das ja für diesen einen Nachteil am Markt bedeuten kann. Die Ergebnisse können neben dem eigentlichen Ergebniswert und dem resultierenden Ranking sowie die Festlegung eines unabhängigen Sollwertes (z.B. Branchendurchschnitt, Mittelwert o.ä.) auch die Identifikation von Optimierungspotentialen für die einzelnen Teilnehmer sein, für die dann in weiterer Folge Handlungsempfehlungen entwickelt und gegebenenfalls umgesetzt, kontrolliert und deren Effekt gemessen werden können.

Ein häufiger Ansatzpunkt für einen Benchmarkvergleich sind die IT-Kosten. Die Kostenarten sollten allgemein gewählt werden, sodass eine Standardisierung über die Unternehmensgrenzen hinweg möglich ist, also z.B. interne und externe Personalkosten, Kosten für Hardware, Software, Infrastrukturdienste etc.

Ein Nachteil des Benchmarkings ist wohl die starke Orientierung auf leicht zu quantifizierende Messgrößen, wie etwa die Kosten. Qualitative Aspekte, wie z.B. Kundenzufriedenheit, Service- oder Supportqualität lassen sich nur schwer in über Unternehmensgrenzen hinweg gültige Vergleiche ausdrücken. Zusätzlich ist es schwer, Unternehmen für eine Teilnahme an einem Benchmark zu gewinnen, da ja unternehmensinterne Information abgefragt wird. Zentrales Element ist die Schaffung von Vergleichbarkeit, was nicht immer einfach ist. Dennoch bietet es eine ausgesprochen gute Standortbestimmung, bei deren weiteren Bearbeitung sich eine Organisation sehr gut weiterentwickeln kann.

IT-Benchmarking

Bestandteil des IT-Controllings ist der Leistungsvergleich der IT mit unternehmensinternen oder –externen Vergleichspartnern. Beim Benchmarking wird der IT-Bereich der eigenen Organisation mit den „Besten“ IT-Bereichen anderer Organisationen der gleichen oder einer anderen Branche verglichen. Die Identifizierung von Schwachstellen im eigenen IT-Bereich und die Übernahme von „Good und Best-Practices“ sind die Ziele des Benchmarkings.

Das Benchmarking kann auf verschiedenen Ebenen und mit unterschiedlichen Zielsetzungen erfolgen.

Formen des Benchmarkings [nach TIE09, S422]

Der Vergleichshorizont gibt an, ob die Vergleichspartner aus dem eigenen (intern) oder anderen (extern) Unternehmen und aus der gleichen Branche (konkurrenzbezogen) oder unabhängig der eigenen Branche (Funktional) stammen. Als Untersuchungsgegenstände können beispielsweise Kosten, Produkte, Prozesse aber auch Strategien herangezogen werden. Das Ziel des Benchmarkings kann einerseits die Leistungsmessung reiner Zahlenwerte (quantitativ) oder das Erlernen bzw. Übernehmen erfolgreicher Praktiken (qualitativ) sein.

Beim Benchmarking muss gewährleistet sein, dass die Vergleichsobjekte (Kennzahlen) von allen Teilnehmern gleich definiert und erfasst werden. Allerdings erweist sich Definition und Erfassung von ebendiesen vergleichbaren Messgrößen über verschiedene Unternehmen und Branchen hinweg in der Praxis als schwierig.

Wesentlich ist auch, dass Benchmarking nicht als einmalige Sache angesehen werden sollte, sondern ein langfristiges Engagement der beteiligten Vergleichspartner erfordert, um die identifizierten „Good und Best-Practices“ für den eigenen Bereich zu übernehmen [TIE09, S421ff].

Wiederholungsaufgaben

1. Welche Reifegrade gibt es und was sagen diese grob über den Prozess aus?
2. Was sind Referenzmodelle und wie können diese bei der Einführung von IT-Governance unterstützen?
3. Welche Problemfelder entstehen allgemein durch Aufstellen einer Messmetrik?
4. Welche Blickwinkel werden im Rahmen einer BSC betrachtet und wie werden diese durch Messung mit Daten befüllt?
5. Sie wollen ein Benchmarking im Unternehmen durchführen. Mit welchen Problemen werden Sie dabei wahrscheinlich konfrontiert?

Lösungen

Welche Reifegrade gibt es und was sagen diese grob über den Prozess aus?

Das CMMI-Reifegradmodell hat fünf Reifegrade:

• 1 – Initial: Es bestehen in der Grundstufe keine Anforderungen.

• 2 – Managed: Eine Vorgehensweise kann für andere ähnliche Aufgaben wiederholt werden.

• 3 – Defined: Ein Standardprozess wird angewandt und eine kontinuierliche Prozessverbesserung existiert.

• 4 – Quantitatively Managed: Eine Prozesskontrolle wird durchgeführt.

• 5 – Optimizing: Die Vorgehensweise wird durch Prozesskontrolle verbessert.

Was sind Referenzmodelle und wie können diese bei der Einführung von IT-Governance unterstützen?

Referenzmodelle werden auf Basis von Praxiserfahrungen entwickelt und bestehen aus einer konsolidierten Sammlung von Prozessen, Regeln und Organisationsstrukturen, die in der Praxis erfolgreich etabliert und breit akzeptiert sind. Ein Referenzmodell legt im allgemeinen seinen Schwerpunkt auf einen bestimmten Aspekt und soll durch die dokumentierten, praxiserprobten Vorgehen eine Art Anleitung oder Leitfaden bei der Etablierung von IT-Governance in einem Unternehmen liefern.

Welche Problemfelder entstehen allgemein durch Aufstellen einer Messmetrik?

Überwachung und Messung beruhen auf vier Gründen:

1. Konsequenzen von vorangegangenen Entscheidungen auswerten
2. Richtungsweisungen für Zielerreichungsaktivitäten setzen
3. Messergebnisse für eine Rechtfertigung für angeordnete Aktivitäten anwenden
4. Rechtzeitiges Einwirken auf die bisherigen Aktivitäten mit Korrekturmaßnahmen

Es stellt sich dabei natürlich die Frage, wie die erforderlichen Maßzahlen definiert und wie sie gemessen werden, was die Ergebnisse aussagen (und was nicht) und welche Konsequenzen diese haben können. Der Zusammenhang Definition-Messung-Ergebnis-Interpretation sowie der Konnex zu der grundlegenden qualitativen Aussage muss dabei ständig kritisch hinterfragt werden:

• Warum wird überwacht und gemessen?

• Wann soll die Überwachung und Messung beendet werden?

• Werden die gewonnenen Daten wirklich benötigt?

• Werden Überwachung und Messung weiterhin benötigt?

Welche Blickwinkel werden im Rahmen einer BSC betrachtet und wie werden diese mit Messdaten befüllt?

Es werden strategische Geschäftsziele definiert, welche die Basis für die Definition von ein oder mehreren Key Performance Indicators (KPI) pro Geschäftsziel als Messgrößen bilden. Für diese KPIs werden Zielwerte formuliert, die dann mit den tatsächlich gemessenen Werten verglichen werden können. Dieses Kennzahlensystem („scorecard“) soll durch die berücksichtigten Perspektiven

1. Finanzen
2. Kunden
3. Prozesse
4. Mitarbeiter (Ressourcen, Innovation und Wachstum)

ein ausgewogenes Bild („balanced“) ergeben.

Sie wollen ein Benchmarking im Unternehmen durchführen. Mit welchen Problemen werden Sie dabei wahrscheinlich konfrontiert?

Informationsquellen, Umfang und Genauigkeit der Daten, Vergleichbarkeit, und Kosten der Informationsbeschaffung, Zeitaufwand, Definition von Messgrößen und Ermittlungsmethoden, allgemein die Übersetzung qualitativer Aspekte in quantitative Werte. Insbesondere bei Branchenvergleichen kommen Fragen der Informationsakquirierung, Datenschutz, Verrechnung und Nutzen für die teilnehmenden Unternehmen hinzu.