IT-Frameworks und Methoden - Strategie

IT Strategie

Ziele der Lektion

• Diskussion des Zusammenspiels der Geschäftsziele mit IT-Zielen

• Diskussion über die Überprüfung der Servicequalität

• Benennen und Einordnen von möglichen Messmethoden

• Grundsätzliche Anwendung der Messmethoden für konkrete IT-Governance Aufgaben

  1. Vision, Mission, Ziele

Das zentrale Element beim Aufsetzen eines Managements für eine Organisationseinheit ist die grundlegende Zielsetzung. Den Mitarbeitern der Organisationseinheit muss klar werden, wofür ihre Organisationseinheit steht, welche Vision sie verfolgt (was?) und wie sie diese umsetzen möchte, was sich in der Mission (wie?) ausdrückt. Die Formulierung von Zielen dient dann in weiterer Folge dazu, den aufgezeigten Weg messbar zu machen und den Fortschritt zur Verwirklichung der Vision zu erkennen. Gerade bei den operativ orientierten Mitarbeitern werden diese Themen nicht immer wertgeschätzt. Allerdings muss man erkennen, dass es langfristig von großem Vorteil ist, wenn das Management einen „roten Faden“ verfolgt. Ist dem nicht so, also z.B. wenn sich die Orientierung in viel zu kurzen Zeitabständen ständig ändert, werden die Mitarbeiter mit der Zeit nicht mehr folgen können und das „gemeinsame Am-Strang-Ziehen“ geht verlustig. Die Organisationseinheit wird dann von außen auch als konfus und orientierungslos wahrgenommen und schwächt ihre Position innerhalb des Unternehmens.

Strategieerreichung

Ein ganz wesentlicher Aspekt bei Business Alignment Projekten ist das ständige Überprüfen der gesetzten Maßnahmen und damit letztlich die Strategieerreichung. Überhaupt ist es von entscheidender Bedeutung, allgemein aussagekräftige Maßzahlen zu definieren, diese zu messen, um so die Organisation steuern zu können. Gang und gäbe ist dabei die Steuerung nach finanzwirtschaftlichen Aspekten, also die simple Gegenüberstellung von Kosten und Ertrag in verschiedenen Detailtiefen. Naturgemäß ist die Finanzwirtschaft eine Kernfunktion jedes Unternehmens, nicht selten sind Finanzchefs die „eigentlichen“ Geschäftsführer. Dennoch sollen andere – auf den ersten Blick weniger „greifbare“ – Aspekte ebenso berücksichtigt werden, um Aussagen möglichst ganzheitlich formulieren zu können. Diese können z.B. Innovationsgrad des Unternehmens, Nutzungsgrad der Skills der eingesetzten Mitarbeiter, Prozessqualität, Durchlaufzeiten von Geschäftsfällen, Kundenbindung, Kundenzufriedenheit etc. sein.

Überwachung und Messung beruhen auf vier Gründen. Zum einen sollen Konsequenzen von vorangegangenen Entscheidungen ausgewertet werden und Richtungsweisungen für Zielerreichungsaktivitäten gesetzt werden. Die Messergebnisse sollen dann sowohl für eine Rechtfertigung für angeordnete Aktivitäten dienen als auch die Möglichkeit bieten, rechtzeitig mit Korrekturmaßnahmen auf eine Änderung der bisherigen Aktivitäten einzuwirken [NIT08, Seite 130].

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.

Nicht selten bekommen Maßzahlen im Laufe ihres Einsatzes im Unternehmen eine gewisse Eigendynamik, indem die Erreichung der quantitativen Maßzahl im Vordergrund steht, aber die qualitative Aussage dahinter in den Hintergrund rückt oder gänzlich dem Blickfeld entschwindet. Einmal definiert und etabliert, wird mitunter auch eine Messung weitergeführt, obschon die Gründe für die damals eingesetzte Überwachung weggefallen sind. Simple Fragen können dabei helfen, diese Verbindung zu der eigentlichen Fragestellung aufrechtzuerhalten [NIT08, Seite 131]:

• Warum wird überwacht und gemessen?
• Wann soll die Überwachung und Messung beendet werden?
• Werden die gewonnenen Daten wirklich benötigt?
• Werden die Überwachung und Messung weiterhin benötigt?

Es gibt drei Arten, die im Unternehmen für Messgrößen herangezogen werden. Mit technischen Messgrößen sind technische Metriken gemeint, etwa Leistung, Verfügbarkeit, Erreichbarkeit. Prozess-Messgrößen orientieren sich an kritischen Erfolgsfaktoren oder an daraufhin definierten Key Performance Indicators (KPI). Service-Messgrößen betrachten die End-to-End-Kundensicht und setzen sich etwa aus mehreren Komponenten-Metriken zusammen. Sie spiegeln das Kundenerlebnis mit dem Service[NIT08, Seite 131].

Natürlich muss das erzielte Ergebnis auch hinterfragt werden. Was bedeutet es, wenn bei einer Maßzahl das Resultat 5 lautet? Wie wird das interpretiert? Und was bedeutet das Resultat 5 im Vergleich zum Resultat 10 mit einer Messung? Es müssen also Startwerte – sogenannte Baselines – für die Messung festgelegt werden, um später sinnvolle Vergleiche machen zu können. Ein Baselining kann auch sein, zuerst einmal Daten zu sammeln, auch wenn zunächst deren Integrität nicht sichergestellt ist. Sinnvoll ist folglich auch, Sollwerte zu formulieren, welches Ergebnis für diese Messung man anstrebt. Die Baselines liefern auch einen ersten Anhaltspunkt, ob das Service verbessert werden muss. Sie müssen auf allen Ebenen – strategisch, taktisch, operativ – formuliert werden [NIT08, Seite 131].

Wichtig zu erwähnen ist die Unterscheidung in quantitative und qualitative Maßzahlen. Quantitative Aussagen beziehen sich immer auf Menge, Anzahl oder Häufigkeit einer metrischen Größe. Sie können sowohl in Zahlen oder Verhältnissen ausgedrückt werden. Alle quantitativen Aussagen beziehen sich auf eine qualitative Größe, z.B. auf den qualitativen Begriff Verfügbarkeit oder Kundenzufriedenheit; oder auch, wenn ein bestimmter Wert in einem definierten Toleranz- oder Zielbereich liegt. Qualität ist somit eine Eigenschaft oder ein Zustand. Die Qualität im Sinne von Qualitätsmanagement gibt somit an, in welchem Maße ein Produkt oder Service gestellten Anforderungen entspricht. Eine quantitativ formulierte Aussage für den kritischen Erfolgsfaktor „Kostenreduktion“ kann z.B. sein: „Zehn Prozent Kostenreduzierung für Druckerentstörungen im Incident Management Prozess“. Eine qualitative Formulierung eines KPIs für den kritischen Erfolgsfaktor „Servicequalitätverbesserung“ lautet etwa „Zehn Prozent Verbesserung bei der Kundenzufriedenheitsbewertung im Incident Management in den nächsten sechs Monaten“. Im ersten Fall kann man konkret auf quantitativ messbare Werte rückführen, im zweiten ist eine qualitative Bewertung durch Kunden mithilfe eines Verfahrens erforderlich. Bei beiden Arten benötigt man den anfänglichen und den aktuellen Wert, um darauf die Informationsgewinnung stützen zu können [ISI07, Seite 62f].

Im Teil Continual Service Improvement (CSI) aus ITIL wird die Verbindung von Strategie mit der Unternehmensvision bis zur konkreten Messung über ein Stufenmodell beschrieben. Auch hier soll die schematische Darstellung der Pfeile zurück zur jeweiligen Vorstufe den Blick zurück, das Hinterfragen des inneren Zusammenhangs mit den qualitativen Hintergründen, visualisieren.

Abb. 2.1: Von der Vision zur Messung [ISI07, Seite 48]

Die Gewinnung von Informationen im Rahmen der Messung bildet ein zentrales Element für den Sieben-Schritte-Verbesserungsprozess für CSI. Durch die Interpretation der Messresultate können erst Maßnahmen entwickelt und implementiert werden, was wiederum das IT Business Alignment unterstützt und eine Wissensspirale darstellt. [ISI07, Seite 43ff].

Abb. 2.2: Sieben-Schritte-Verbesserungsprozess [ISI07, Seite 43]

Methoden

In der IT stehen durchaus einige Methoden für das Messen von IT-Prozessen zur Verfügung. Im Folgenden sollen einige davon vorgestellt und Vor- und Nachteile diskutiert werden.

In der Lektion zum Thema IT-Controlling wird die IT-Strategie dann im Zusammenhang mit dem IT-Budget betrachtet: von der Unternehmensstrategie wird eine IT-Strategie abgeleitet, dann ein Budget dafür aufgestellt (in COBIT 5 ein Teil von „Planen“) und während des Ablaufs und insbesondere am Ende des Planungszeitraums kann man dann mithilfe des IT-Controllings (in COBIT 5 ein Teil von Überwachen) messen, ob das Budget eingehalten und damit der finanzielle Aspekt der IT-Strategie erfüllt wird.

Wiederholungsaufgaben

1. Was ist CSI, welche Zielsetzung wird damit verfolgt und wie ist es strukturiert?

Die Lösungen zu den Wiederholungsaufgaben finden Sie in Anhang A.

IT Business Alignment und IT-Prozesse

Ziele der Lektion

• Erkennen der Bedeutung der IT als unterstützendes Element für die Geschäftsprozessunterstützung
• Bedeutung der allgemeinen IT Architektur für die angestrebte Geschäftsprozessunterstützung

Im IT Umfeld herrscht, durch sich rasch ändernde Bedürfnisse und Erwartungen von Kunden eine hohe Marktdynamik vor, was zum ständigen Abgleich zwischen Business- und IT-Strategien und Zielen führt. Kurze Innovationszyklen von Produkten, aber auch von IT-Technologien, bedingen eine rasche Anpassung der IT. Umstrukturierungen im Unternehmen, Outsourcing und Zukäufe von Unternehmensbereichen erfordern eine flexible IT, die auf diese Situationen rasch eingehen kann. Änderungen von gesetzlichen und regulatorischen Vorgaben können zu innerbetrieblichen Veränderungen führen, auf die die IT reagieren muss. Oftmals herrschen in den Unternehmen heterogene IT-Architekturen vor, die mitunter sehr komplex sein können und meist aufwendig zu administrieren sind. Neue Technologien zur Umsetzung von Änderungen können hohe Kosten verursachen, die vom Business getragen werden müssen.

Im IT Business Alignment geht es darum die Strategien des Unternehmens bestmöglich zu unterstützen. Dazu sollte sich die IT-Strategie aus der Unternehmensstrategie formen und als IT Prozesse in das laufende Doing überführt werden. Es ist wichtig zu verstehen, welche Aufgaben die IT-Prozesse im Unternehmen erfüllen. Dazu muss also die Strategie als Basis bekannt sein. Um IT Business Alignment im Unternehmen zu etablieren und nachhaltig zu institutionalisieren, gilt es u.a., die Herausforderungen eines effektiven und effizienten IT Service Managements, IT Architektur Managements und weiterere Hauptprozesse der IT zu meistern.

IT Service Management umfasst dabei die Planung, Entwicklung, Überwachung und Steuerung von Leistungen der IT (IT Services) mit dem Ziel, die Geschäftsprozesse des Unternehmens effizient zu unterstützen.

Als IT Architektur Management wird die zielgerichtete Planung und effiziente Weiterentwicklung der IT-Landschaft (Anwendungen, Infrastruktur) in Hinblick auf die Unternehmensstrategie und Geschäftsprozesse bezeichnet.

Abb. 3.1: Zusammenhänge IT Business Alignment [eigene Darstellung]

Für beide erwähnten Prozesse und weitere Hauptprozesse der IT (z.B.: Change Management oder Operations) widmen sich beispielsweise die „Best Practices“ von ITIL (IT Infrastructure Library) und der Standard ISO 20000 zum Thema IT Service Management sowie CobiT (Control Objectives for Information and Related Technology), der insbesondere im Rahmen von Prüfungen aber nicht nur zur Anwendung kommt. In den folgenden Kapiteln wollen wir näher auf die einzelnen IT-Prozesse eingehen.

Es geht darum, die IT-Prozesse optimal so zu gestalten, dass sie die Erreichung der Unternehmensziele bestmöglich unterstützen. Jeder IT-Prozess sollte daher nach den Regeln des Prozessmanagements einen Prozess Owner haben, eine Prozessdokumentation aufweisen und regelmäßig einem kontinuierlichen Verbesserungsprozess unterworfen sein.

Die Rolle der IT im Unternehmen

Die Rolle der IT-Abteilung innerhalb des Unternehmens kann sehr unterschiedlich sein und wird zum großen Teil dadurch determiniert, wie das Top-Management die Bedeutung der IT für das Unternehmen einschätzt. Relevant ist aber auch die Stärke des IT-Leiters, die IT im Unternehmen zu positionieren. Als erster Indikator kann die Einbindung des IT-Leiters in die Geschäftsleitung herangezogen werden. Fehlt dem CIO das „C“, muss davon ausgegangen werden, dass IT-Belange nur über den verantwortlichen Geschäftsleiter in der Geschäftsführung vertreten werden. Zumeist wird die Informationstechnologie als eines von mehreren Themen den begleitenden Unternehmensfunktionen Finanz, Controlling, Personal, Interne Dienstleistungen zugeordnet, aber auch Partnerschaften mit Einkauf und Logistik wurden bereits gesichtet. Ihnen ist gemeinsam, dass in praktisch keinem Fall hinter diesen Rollen ein Techniker zu finden ist, eher Betriebswirte. Je abhängiger ein Unternehmen von der IT ist, desto schwerer sollte die IT in der Unternehmensleitung gewichtet sein. Die mittel- und langfristigen Auswirkungen einer organisatorischen Positionierung im Unternehmensgefüge werden unterschätzt. Optimal ist die Verbindung sämtlicher technologischen Aspekte unter einem Geschäftsbereichsleiter, der auch kraft seiner theoretischen Grundlage (als Techniker!) auch in der Lage ist, seinen Bereich durchgehend zu verstehen und die Sache bei den oftmals technisch nicht ausreichend versierten Geschäftsbereichsleiterkollegen zu vertreten.

IT als Dienstleister – „run the business“

In der beruflichen Praxis haben die Autoren sehr unterschiedliche IT-Organisationen kennengelernt. Das Spektrum reicht von hochtechnisierten IT-Bereichen in Technologisparten bis hin zu vollkommen ihrer Bedeutung nicht angemessenen ressourcen-unterdotierten IT-Miniabteilungen, die sich teilweise auf Heimcomputer-Niveau bewegen. Eine der schlimmsten Aussagen ist, dass „IT funktionieren muss“. Diese Aussage impliziert, dass das bestehende Potential von Informationstechnologie für die Geschäftstätigkeit mit hoher Wahrscheinlichkeit nicht ausreichend ausgeschöpft wird. IT wird auch als Dienstleister für (interne) Kunden gesehen, wobei das Paradigma der „internen Kunden“ allein in vielen Fällen nicht zur gewünschten Serviceorientierung gereicht. Zusätzlich problematisch ist es, dass IT auch von den anderen Bereichen aufgrund der technologischen Komplexität als potemkinsches Dorf gesehen wird, weil das technische und sprachliche Verständnis auf Seiten der Nicht-IT-Mitarbeitern fehlt. Die IT als „Black Box“ mag zwar für die IT selbst eine gewisse Narrenfreiheit implizieren, führt aber zu einer Abkapselung der verbleibenden Unternehmensteile.

IT als Kostenfaktor

Verstärkt wird dieser intransparente Aspekt eventuell noch durch subjektiv teure IT-Umlagen, wo die IT-Kosten auf das restliche Unternehmen umgelegt werden und somit durch die jeweiligen anderen Manager keinen steuerbaren Kostenfaktor darstellen. Problematisch wird es dann, weil eine intensive Zusammenarbeit mit dem Fachbereich gefordert wird, ja geradezu essentiell für eine kluge Ausrichtung der IT an den Geschäftszielen ist. Natürlich wird so ein Eindruck durch Outsourcingpartnerschaften möglicherweise noch verstärkt. Aufgrund der unterstützenden Querschnittsfunktion, die IT üblicherweise im Unternehmen einnimmt, erscheint das der falsche Weg. Praktisch jeder andere Unternehmensbereich nutzt Services der IT, sei es nur den Client-PC, Email oder auch als Anwender der Kerngeschäftsapplikationen, die es de facto immer gibt. Bestes Beispiel sind ERP-Systeme oder Kundenmanagementsysteme, welche die IT als Service für das Kerngeschäft zur Verfügung stellt. IT ist allgegenwärtig, in jeder Aktivität liegt heutzutage ein Berührungspunkt mit IT. Diese Abhängigkeit ist oftmals gar nicht mehr bewusst, was sich dann in Aussagen von Mitarbeitern der Fachabteilungen widerspiegelt, wie zum Beispiel „Das rechnet SAP aus“. Es wird gar nicht mehr hinterfragt, ob SAP richtig „rechnet“ – es wird einfach vorausgesetzt. Hier liegt auch eine große Gefahr, da auf der IT-Seite in der Regel die fachspezifischen Implikationen nicht bekannt sind und demnach von IT-Mitarbeitern nicht beurteilt werden kann, ob „SAP richtig rechnet“. Hier besteht eine Diskrepanz zwischen Fachabteilung und IT, ein nicht abgestimmter Berührungspunkt, welcher nur durch intensive Zusammenarbeit der IT mit der Fachabteilung ausgefüllt werden kann.

IT als Enabler – „change the business“

IT kann aber auch ein Marktvorteil gegenüber den Marktbegleitern sein. Ein wohldurchdachtes Data Warehouse (DWH), welches Kundenstrukturen analysiert und spezifische Marktpotentiale erhebt, worauf Marketing dann gezielt aufsetzen kann, ist dafür nur ein Beispiel. Ein Kundenmanagementsystem, das bei der Anmeldung eines Mobiltelefons innerhalb weniger Minuten den Neukunden in den technischen Kernsystemen, dem ERP-System, dem Billing-System anlegt und eine Bonitätsprüfung durchführt, vermindert den Administrationsaufwand und sorgt aufgrund der hohen Automatisierung für möglichst wenig Fehlerfälle. IT kann als Business Enabler fungieren.

IT schafft aber auch neue Möglichkeiten, etwa für den Vertrieb. Onlineshops, Onlineregistrierungen, Newsletter und Kundenkommunikation via Email sind neuartige Kommunikationskanäle, denen zukünftig noch mehr Bedeutung beizumessen sein wird. Gerade durch die technologische Evolution, die in der IT in einer unvergleichlichen Geschwindigkeit vonstattengeht, schafft auch immer neue Anwendungsmöglichkeiten, wie zum Beispiel Webanwendungen. Dank kluger Smart Phone Entwicklungen oder auch zunehmender WLAN-Durchdringung des öffentlichen Raums setzt sich Mobile Computing immer mehr durch, somit wieder die Anwendungsmöglichkeiten von IT für ein Unternehmen oder eine Institution.

Neben der Mobilität ist Sicherheit das zweite große herausfordernde Thema. Je flexibler und ortsunabhängiger IT-Dienstleistungen in Anspruch genommen werden können, desto mehr Fokus muss auf Themen wie Vertraulichkeit, Integrität, Verfügbarkeit, Authentifizierungsmechanismen und User-Identifikation, Nichtabstreitbarkeit von Aktivitäten gelegt werden. Nur dann, wenn der Anwender Vertrauen in die Technologie gefasst hat, wird er diese auch nutzen. Dies hat wiederum positive Auswirkung auf die IT-Abteilung, wenn ihre Services angenommen werden, was wiederum die Integration ins Unternehmen fördert. Informationstechnologie muss in einem Unternehmen tunlichst eine proaktive innovative und technologiefördernde Rolle einnehmen, will man deren Entwicklungspotential für das Unternehmen möglichst effektiv nutzen.

Wiederholungsaufgaben

1. Beschreiben Sie kurz die Komponenten des IT Business Alignment und stellen Sie die Zusammenhänge (grafisch) dar.

Die Lösungen zu den Wiederholungsaufgaben finden Sie in Anhang A.

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 benötigen zur zielgerechten Steuerung der IT-Aktivitäten in regelmäßigen Abständen geeignete Informationen. Nicht alle Empfänger benötigen jedoch dieselben Informationen im selben Detaillierungsgrad. Für eine geeignete Berichterstattung muss Berichterstatter und Berichtempfänger, 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 IT-Leiter 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 IT-Leiter gemeinsam getroffen.
• IT-Duopol: Hier treffen der IT-Leiter 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?

Abb. 4.1: 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ägern 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].

2. Methoden und Instrumente im IT-Controlling

   1. 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. Kunden verrechnet werden.

Es existieren einige Vorteile, die durch die Einführung der IT-Leistungsverrechnung erwartet werden können. Sowohl für Anwender 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 Dienstleistern 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, 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.

Abb. 4.2: 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.

Abb. 4.3: 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.

Abb. 4.4: 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:

Abb. 4.5: 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]:

Abb. 4.6: 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,

Abb. 4.7: 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.

Abb. 4.8: 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?

Die Lösungen zu den Wiederholungsaufgaben finden Sie in Anhang A.

Outsourcing von IT-Leistungen

Ziele der Lektion

• Verständnis für die Gründe von Sourcingentscheidungen

• Benennen und Einordnen der unterschiedlichen Sourcingmodelle

• Kennenlernen der Herangehensweisen für das Management von Sourcing

• Kritische Würdigung von Outsourcing

  1. Sourcingentscheidung

Outsourcing war und ist eine gängige Organisationsform, wenn es für ein Unternehmen darum geht, einerseits Kosten zu sparen und/oder anders darzustellen, als auch – insbesondere bei Klein- und Mittelbetrieben – eine Professionalisierung von Tätigkeiten anzustreben, da nicht ausreichend Wissen im Hause vorhanden ist und auch nicht teuer aufgebaut werden möchte. In den späten 1990er-und beginnenden 2000er-Jahren wurde Outsourcing auch in der Informationstechnologie intensiv betrieben, da sich dieses abgegrenzte Fachgebiet sehr gut für Outsourcing eignet: komplexes Thema, relativ überschaubare operative Schnittstellen zu anderen Unternehmensprozessen, hoher Grad an erforderlichem Know How der Mitarbeiter, hohe Investitionskosten. Je technologieunabhängiger das Unternehmen ausgerichtet ist, desto eher ist die Informationstechnologie eine Art „Black Box“ und desto eher ist man bereit, diesen Unternehmensteil auszulagern.

Sourcingmodelle

Outsourcing selbst bezeichnet eine Auslagerung von Unternehmensteilen oder
-funktionen an Dritte. Es ist eine spezielle Form des Fremdbezugs und impliziert, dass die nun vergebenen Aufgaben und Leistungen zuvor intern erbracht wurden. Die Partnerschaft wird durch ein Vertragswerk geregelt und wird üblicherweise auf zwei bis zehn Jahre hinaus abgeschlossen. Es gibt mannigfaltige Formen des Outsourcings: Ein unternehmensinternes Outsourcing kann innerhalb eines Konzernes an andere Unternehmen erfolgen (z.B. T-Mobile lagert die IT an T-Systems aus), es erfolgt eine Ausgründung in ein eigenes Unternehmen (z.B. Gründung der iT-AUSTRIA durch Erste Bank und Bank Austria) oder aber Fremdvergabe im eigenen Betrieb (z.B. externe Mitarbeiter etwa von Unternehmen wie Sphinx). Die bekannteren Formen, die man mit dem Begriff „Outsourcing“ assoziiert, sind die klassischen Vergaben an (vielfach große) externe Fremdfirmen (z.B. Siemens oder Raiffeisen Informatik). Der Erfüllungsort kann hierbei aber variieren, er kann sowohl im eigenen Haus als auch regional oder global sein. Der Anteil der Auslagerungen ist ebenso frei wählbar.

Full Outsourcing

Man kennt das klassische Full Outsourcing, wo beispielsweise der komplette IT-Betrieb inklusive Mitarbeiter an den neuen Dienstleister überbunden wird.

Outtasking

Werden nur Teilbereiche oder Funktionen übertragen, wird dies als Outtasking bezeichnet, etwa Webdesign, Software-Entwicklung, Service Desk, Internetrecherche, Übersetzungsleistungen.

Nearshoring und Offshoring

Zumeist werden diese Aufgaben in Niedriglohnländer verlagert, je nach Entfernung wird dies als Nearshoring (z.B. Bratislava/Pressburg) oder Offshoring (z.B. Indien) bezeichnet.

Knowledge Process Outsourcing

Damit verwandt ist das Knowledge Process Outsourcing . Dabei geht es primär um Spezialwissen, etwa Rechtsberatung, Marktforschung, Design.

Managed Services

Eine andere Form ist die reine Auslagerung ohne Ortswechsel, das heißt, dass die bestehende IT durch Mitarbeiter des Dienstleisters vor Ort betreut werden. Dies nennt man Managed Services.

Housing und Hosting

Wird etwa nur die Hardware ausgelagert, weil man den Betrieb eines teuer ausgestatteten Rechenzentrums (oft in Verbindung mit einem zusätzlichen Disaster Recovery Standort) scheut, spricht man von Housing – wenn es rein um die Rechenzentrumsstandortverlagerung geht und die eigenen Mitarbeiter weiterhin die Systeme betreuen – oder Hosting – wenn zusätzliche Dienstleistungen, etwa Monitoring, Backup & Recovery, Administration oder ähnliche operative Dienstleistungen.

Application Service Providing (ASP)

Reicht die Dienstleistung bis auf die Applikationsebene, etwa den Betrieb und die Betreuung des ERP-Systems, spricht man von Application Service Providing (ASP).

Anmerkung:
Der Begriff ASP ist mittlerweile etwas außer Mode gekommen; man würde heutzutage in moderner Cloud-Diktion vom Service-Modell „Software as a Service (SaaS)“ z.B. im Deployment-Modell „Public Cloud“ sprechen (siehe Cloud Computing).

Business Process Outsourcing

Auch können einzelne Prozesse als solche im Rahmen eines Business Process Outsourcings ausgelagert werden.

Mischformen

Darüber hinaus bestehen noch zahlreiche Mischformen, die bekannte Probleme des Outsourcings zu bewältigen versuchen, etwa eine ineffektive Steuerung des Dienstleisters, fehlendes Wissen für klare Vorgaben, Auslagerung von nicht ausreichend optimierten Abläufen.

Cloud Computing

Die NIST Definition of Cloud Computing (NIST SP 800-145) [NIS11] definiert fünf essenzielle Charakteristiken von Cloud Computing:

• On-demand self-service: der Nutzer von Cloud Computing kann selbst den Zeitpunkt bestimmen, wann er ein Cloud Service benützen will, und er kann die vollautomatische Bereitstellung des Service für sich selbst auch selbst auslösen
• Broad network access: in der Regel ist ein breitbandiger Netzwerkzugang erforderlich, um Cloud Services mit einer akzeptablen Leistungsqualität benützen zu können
• Resource pooling: die für die Bereitstellung von Cloud Services erforderlichen Ressourcen werden von allen Nutzern gemeinsam benutzt; es ist für den einzelnen Nutzer nicht transparent, welcher Teil der Ressourcen für ihn verwendet wird
• Rapid elasticity: die Gesamtmenge der eingesetzten Ressourcen kann schnell an steigende oder sinkende GesamtAnforderungen aller Nutzer zusammen angepasst werden
• Measured Service: die Nutzung der Ressourcen durch den einzelnen Nutzer wird exakt gemessen und exakt verrechnet

NIST SP 800-145 definiert in weiterer Folge drei Service-Modelle:

• Infrastructure as a Service (IaaS): der Cloud Service Provider stellt Ressourcen für die Verarbeitung, Speicherung und Übertragung von Informationen sowie alle darunter liegenden Basisressourcen (Stromversorgung etc.) bereit; der Nutzer ist selbst für das Betriebssystem und die gesamte darüber liegende Software verantwortlich
• Platform as a Service (PaaS): der Cloud Service Provider stellt zusätzlich zu IaaS auch das Betriebssystem und die Basissoftware (z.B. Entwicklungsumgebung, Datenbanksoftware, Webserver und dazugehörige Werkzeuge) bereit; der Nutzer ist selbst nur für die darüber liegende Anwendungssoftware verantwortlich
• Software as a Service (SaaS): der Cloud Service Provider stellt zusätzlich zu PaaS auch die gesamte Anwendungssoftware bereit; der Nutzer ist selbst nur mehr für die eventuelle Konfiguration der Anwendungssoftware für seine individuellen Zwecke verantwortlich

und vier Deployment-Modelle:

• Private Cloud: die Ressourcen stehen im Eigentum eines Unternehmens oder Konzerns und werden nur von Nutzern innerhalb dieses einen Unternehmens oder Konzerns benützt
• Community Cloud: die Ressourcen werden von einem definierten, eingeschränkten Nutzerkreis benützt, die alle gemeinsame Interessen haben; bezüglich Eigentum, Management und Verrechnung der Ressourcen gibt es viele unterschiedliche Modelle
• Public Cloud: die Ressourcen stehen prinzipiell jedem zur Benützung zur Verfügung; bezüglich Eigentum, Management und Verrechnung der Ressourcen gibt es viele unterschiedliche Modelle
• Hybrid Cloud: eine Mischform aus den anderen drei Deployment-Modellen auf Basis einer einheitlichen Technologie, sodass im Bedarfsfall Ressourcen aus einem anderen Deployment-Modell vorübergehend mitbenützt werden können (z.B. Cloud Bursting: überlastete Private Cloud bekommt vorübergehend Ressourcen aus nicht überlasteter Community Cloud – oder umgekehrt)

Problematische Bereiche im Cloud Computing ergeben sich insbesondere aus der Charakteristik Resource Pooling (Vertraulichkeit und Integrität von Informationen; Nichtabstreitbarkeit von Transaktionen; rechtliche Einschränkungen; etc.) sowie aus der Nicht-Steuerbarkeit der vom Cloud Service Provider bereitgestellten tiefer liegenden Schichten durch den Kunden in den Prozessen Change Management und Release Management (insbesondere problematisch sind in diesem Zusammenhang Schnittstellen zwischen Cloud-Systemen und Nicht-Cloud-Systemen sowie Schnittstellen zwischen Systemen unterschiedlicher Clouds).

Insourcing

Hilft das alles nichts, muss man das Outsourcing wieder rückführen, was dann als Insourcing bezeichnet wird.

Shared Service Center (SSC)

Ein Shared Service Center (SSC) fasst als interner Dienstleister gleichartige Leistungen innerhalb eines Unternehmens oder Konzerns in einer Organisationseinheit zusammen und bildet somit den Gegensatz zum Dedicated Service Center, bei welchem genau das nicht der Fall ist.

Management von Sourcing

Als wesentliches Strukturelement beim Outsourcing sind die Schnittstellen, das Servicemanagement und die Outsourcingsteuerung zu sehen. Die Schnittstellen beziehen sich auf die Prozesse, die Schnittpunkte zwischen Kunden und Dienstleister aufweisen, also etwa Change Management. Die Abläufe und jeweiligen Verantwortungen müssen wohldefiniert sein, um ein reibungsloses Zusammenwirken der beiden Partner sicherzustellen. Es empfiehlt sich auch hier, Best-Practice-Ansätzen wie CobiT und ITIL zu folgen und anhand von diesen Prozessen die Verantwortungsübergänge festzulegen. Das Servicemanagement ist ein diesen allgemeinen Abläufen aufgesetzter Prozess, der darüber hinaus die Konflikte, Eskalationen, Weiterentwicklungen, Problemfälle aufgreift und löst. Vor allem Kostenfragen und die jeweilige Aufteilung dominieren dabei. Die Outsourcingsteuerung auf Seiten des Kunden ist erforderlich, um den Dienstleister in eine Richtung zu bewegen, die den Geschäftszielen des Kunden entspricht.

Bedingt durch den hohen Komplexitätsgrad liegt auf der Hand, dass der Vorgang des Outsourcings selbst keine einfache Sache ist. Interessanterweise werden die meisten Outsourcingdeals in relativ rascher Durchlaufzeit realisiert. Dies mag einerseits begründet sein mit einer gewissen Zwangssituation des Unternehmens, rasch Kosten einzusparen und Aktionäre kurzfristig mit Perspektiven befriedigen zu müssen. Da aber auch in vielen Fällen einige Mitarbeiter betroffen sind – etwa, wenn diese an den Dienstleister überbunden werden sollen und dadurch Unruhe in der Belegschaft ausgelöst wird – empfiehlt sich eine schnelle Vorgangsweise. Durch die für das Unternehmen neuartige Aufgabenstellung wird üblicherweise für den kompletten Akt des Outsourcings ein Beratungsunternehmen beigezogen.

Vorgehen bei Outsourcing

Zunächst muss man sich über den aktuellen Ist-Zustand im Klaren sein. Oft sind diese Informationen nicht durchgängig in der gleichen Qualität existent und müssen erstellt werden. Diese Ist-Analyse-Phase umfasst die Formulierung von Leistungsbeschreibungen, eine Grobstruktur der gewünschten Service Level Agreements (SLA), bereits im Vorfeld schon Messkriterien in Form von Key Performance Indicators (KPI). Am Ende dieser Ist-Analyse muss die Entscheidung gefällt werden, welche Teile konkret ausgelagert werden sollen. Dies mündet in die Formulierung einer Ausschreibung – oder Request for Proposal (RfP) – deren Durchführung sich auch für nicht-staatliche Unternehmen empfiehlt.

Anbieterauswahl

Das Ziel der Anbieterauswahl ist es, jenen Anbieter herauszufinden, der am besten zum Kunden passt („Business Partner Compliance“). Am Ende der Ausschreibung, bei der auch aktiv Teilnehmer eingeladen werden sollten, werden die Angebotslegungen gesichtet und zunächst eine Long List erstellt. Nach einer weiteren Runde sollte sich der Anbieterkreis weiter reduzieren, sodass eine Short List erstellt werden kann. Spätestens in dieser Phase sollten klärende Gespräche mit den potentiellen Anbietern geführt werden, um sich als Unternehmen ein genaueres Bild zu machen, als auch die Erwartungen klar auszusprechen. Eine nachfolgende Phase, die sogenannte Due Diligence, beinhaltet dann schon tiefergehende Analysen, Bewertungen, Informationen auf Basis der Unternehmensinformationen. Eine Due Diligence kann sowohl vor dem eigentlichen Kauf als auch danach erfolgen, basiert aber immer auf einer substanziellen Prüfung des Kaufobjekts (also den auszulagernden Unternehmensteilbereich). Dadurch kann der Anbieter den Kunden genauer beurteilen; Stärken, Schwächen, Risiken kennenlernen und einschätzen. So ist es möglich, das Angebot des Dienstleisters genauer zu formulieren. Am Ende der Due Diligence steht – sofern noch nicht erfolgt – eine Anbieterentscheidung.

Vertragsausarbeitung

Das Ziel der Vertragsausarbeitung ist es, mit dem ausgewählten Anbieter einen Vertrag auszuarbeiten, der die Anforderungen des Kunden bestmöglich erfüllt (insbesondere auch dessen Compliance-Anforderungen). Nach dem formalen Prozedere – also Einhaltung von Fristen, Bearbeitung von Einsprüchen – beginnt die Vertragsausarbeitung. Ein derartiges Vertragswerk kann durchaus komplex werden, es besteht aus mehreren Ebenen (Grundsatzteil, allgemeiner Teil, spezielle Themen) sowie vielen Fachkapiteln, wo mehrere Themenbereiche geregelt werden. Es empfiehlt sich bei der Vertragsgestaltung eine einheitliche Struktur anzuwenden und sich hinsichtlich der Themen an bestehende Frameworks zu orientieren (etwa ITIL, CobiT). Es müssen für jeden Aspekt Rechte und Pflichten klar definiert werden, Support- und Servicezeiten festgelegt, Informationsschnittstellen geschaffen, Ansprechpartner genannt und Eskalationsmechanismen geregelt werden. Auch muss ein sogenanntes Unit Cost Pricing etabliert werden, dass es dem Kunden in Zukunft erlaubt, einzelne Servicepakete zu kalkulieren und zu erwerben, z.B. Preis eines IT-Arbeitsplatzes. Nicht nur die Prozesse, auch die Unternehmenswerte die ihren Besitzer wechseln sollen (etwa Hardware, Gebäudeteile o.ä.) müssen eingehend identifiziert und beschrieben werden. Darüber hinaus müssen vertragsrechtliche Bestimmungen niedergeschrieben werden, die das Vertragsmanagement regeln, etwa Vertragsverletzung, Kündigung, Erweiterungen, Weiterentwicklungen, Auditrechte, Einsprüche etc. Natürlich sind die Leistungsbeschreibungen in Verbindung mit den gewählten Service Levels ebenso in den Vertrag zu integrieren, denn sie bilden als sogenannte Service Level Agreements (SLA) das Herzstück der zukünftigen Zusammenarbeit zwischen Dienstleister und Kunden. Nach einer ersten vorliegenden Version beginnen die Vertragsverhandlungen, bei denen die Partner jeden Teil gemeinsam diskutieren und Regelungen zur beiderseitigen Zufriedenheit vereinbaren – was ein durchaus zeitintensives Unterfangen sein kann. Kommt es schließlich zu einer vollständigen Einigung der beiden zukünftigen Vertragspartner, wird der Vertrag unterzeichnet.

Onboarding Prozess

Die nun folgende Transition Phase hat die Aufgabe, sämtliche Grundlagen und Strukturen für das spätere Zusammenleben zu etablieren, sodass ab einem bestimmten im Vertrag vereinbarten Datum der Normalbetrieb beginnen kann. Sie umfasst neben Übergaben von Assets, dem Transfer der Mitarbeiter, die Überbindung von Lizenzen und Verträgen auch den eventuell erforderlichen Umbau der Organisation auf beiden Seiten. Die Transition Phase wird durch das Aufsetzen einer Vielzahl von Projekten (sinnvollerweise zu einem Programm zusammengefasst) implementiert.

Normalbetrieb und Monitoring (Supplier Management)

Nach einer Eingewöhnungszeit beginnt dann der Normalbetrieb der Outsourcingpartnerschaft. Es ist ganz wesentlich, dass es eine Kommunikationsinfrastruktur in Form von Service Management Jour Fixes gibt, bei den sowohl laufende als auch zukünftige Vorhaben, Projekte, Themen besprochen werden und die Zusammenarbeit weiter intensiviert wird. Auf Seiten des Kunden sollte es eine Outsourcingsteuerungsstruktur geben, die sicherstellt, dass der Dienstleister über die Zeit das Unternehmen hinreichend in seinem Wirken unterstützt. Die zuvor vereinbarten Service Level Agreements (SLA) sollen regelmäßig möglichst objektiv gemessen und berichtet, Abweichungen zwischen den Partnern thematisiert und beseitigt werden.

Transformation Phase

Spätestens dann, wenn für den Kunden der Normalbetrieb startet, beginnt für den Anbieter die Transformation Phase. In der Regel verspricht der Anbieter dem Kunden, ihm dieselbe – oder sogar eine bessere – Servicequalität zu einem niedrigeren Preis zu liefern. Das ist aber nur dann möglich, wenn der Anbieter die Leistungserbringung verändert, indem er die bis dahin für die Leistungserbringung für den einen Kunden dedizierten Teams, Wartungsverträge, technische Ressourcen etc. (also ein Dedicated Service Center) mit den für die Leistungserbringung für die Gesamtheit seiner Kunden geteilten Teams, Wartungsverträgen und technischen Ressourcen (also ein Shared Service Center) konsolidiert und damit jene Economies Of Scale ausnützt, die ihm selbst offen stehen, seinen Kunden aber in der Regel nicht offen stehen würden. Dieser Transformationsprozess sollte im Idealfall so ablaufen, dass kein Kunde davon etwas bemerkt.

Auflösung

Falls später ein Insourcing oder der Wechsel des Anbieters erfolgt, müssen die oben beschriebenen Phasen ebenso durchlaufen werden. Es ist aber darauf zu achten, dass eine derartige Auflösung der Outsourcingpartnerschaft vertraglich geregelt sein muss. Oft schließt nach Vertragsablauf eine neue Ausschreibung an, die aufgrund der hohen Folgekosten weniger den Wechsel des Anbieters zum Ziel hat, als vielmehr eine neue Preisermittlung – ein Benchmarking.

Kritische Würdigung von Outsourcing

Outsourcing ist nicht unumstritten. Nicht zuletzt auch deswegen, weil während des größten Hypes mit Zahlen hinsichtlich der Einsparungspotentiale operiert wurde, die so nicht eingetreten sind. Etwa wurden bis zu 20 % Einsparungen bei den IT-Kosten argumentiert, allerdings oft vielfach vergessen, dass die Organisation zumindest des Kunden umgebaut werden muss. Allgemein fußen alle diese „neuen“ Probleme an der Nichteinbeziehung dieser Opportunitätskosten in die dem Outsourcing vorgelagerte Wirtschaftlichkeitsberechnung. Somit sind die enttäuschten Erwartungen erklärbar. Eine effektive Outsourcingsteuerung muss aufgebaut werden, die den Dienstleister inhaltlich und kommerziell treibt, was auf Kundenseite je nach Größe des Outsourcings Mitarbeiterressourcen bindet und eine eigene (neue) Organisationseinheit erfordert. Es liegt ganz klar auf der Hand, dass ein anderes Unternehmen auch andere Unternehmensziele verfolgt. Ein IT-Dienstleister wird danach trachten, die Aktivitäten gleichartig über die verschiedenen Kunden zu harmonisieren und zu skalieren. Jede Ausnahme bedeutet für ihn Aufwand und zusätzliche Kosten, er wird zunehmend dem Minimierungsprinzip folgen. Der Kunde wiederum sieht sich als der wichtigste Partner seines Dienstleisters und will möglichst individuell fokussierte Services, die genau seinen Bedürfnissen entsprechen. Dadurch besteht schon einmal ein inhärentes Konfliktpotential.

Bei Vertragsverhandlungen hört man mitunter sehr oft die Beschwichtigungen „Es wird sich eh nichts ändern.“ oder „Den Vertrag werden wir nur in die Schublade legen, wir sind doch Partner“. In der Praxis zeigt sich, dass sich natürlich etwas ändert – ja, ändern muss, da der vorherige Zustand für den Kunden ja unbefriedigend war – und der Vertrag das Um und Auf des Zusammenlebens darstellt. Dabei lässt sich auch der Unmut der Mitarbeiter erklären, Outsourcingdeals uneingeschränkt zu folgen. Outsourcing wurde auch als Instrument für Stellenabbau angewendet, viele überbundene Mitarbeiter wurden in den folgenden zwei Jahren sukzessive abgebaut. Alle Fehler oder Auslassungen im Vertrag bedürfen mühsamer individueller Verhandlungen, nicht zuletzt, wer die Kosten trägt. Auch trachtet der Dienstleister, den Vertrag möglichst nicht zu ändern, was aber aufgrund veränderter Rahmenbedingungen für den Kunden sehr wichtig sein kann. Zusätzlich lässt sich der Dienstleister nur ungern in die Karten schauen, wie er die Aktivitäten ausführt. In Zeiten von SOX und Internen Kontrollsystemen wird aber genau das vom Kunden von höherer Stelle abverlangt. Daher ist das vertraglich gesicherte Auditrecht eine wesentliche Komponente für die Outsourcingsteuerung.

Der Kunde ist angehalten, die Services des Dienstleisters auf Basis seiner eigenen Beobachtungen und Messungen zu bewerten. Da der Dienstleister die SLAs auch berichtet und dann möglicherweise die Erkenntnisse divergieren, besteht hier auch Konfliktpotential. Nicht zuletzt deswegen ist es empfehlenswert, die Messpunkte bereits im Zuge der SLA-Erstellung zu definieren und dabei auch die Kundensicht zu berücksichtigen, die sich ja in den meisten Fällen nicht auf Server-Response-Times, sondern auf End-to-End-Monitoring des Services bezieht. Frappant ist auch die Zunahme von Durchlaufzeiten für Aktivitäten, Abstimmungen, Projekte, weil ja die Entscheidungsstrukturen durch die Hinzuziehung des Dienstleisters verdoppelt werden. Klassisch ist in späterer Folge auch die Einholung von Alternativangeboten für einzelne Anfragen an den Dienstleister sowie dann oft die Erkenntnis der überhöhten Kosten. Da der Kunde in vielen Fällen keine Möglichkeit hat, einen anderen Dienstleister für bestimmte Tätigkeiten zu wählen, trachtet der Dienstleister selbst naturgemäß nach Gewinnmaximierung. Allerdings ist es demgegenüber nicht zulässig, einzelne Services des Dienstleisters mit jenen aus dem Einzelhandel zu vergleichen, da hier ganz andere Kostenarten einfließen.

Outsourcing bedeutet auch, dass Know How aus dem Unternehmen ausgelagert wird und man sich in ein Abhängigkeitsverhältnis begibt. Ein Unternehmen ist somit streng genommen nicht mehr autonom und muss sich auch mit den Zielen und Strategien eines anderen Unternehmens auseinandersetzen. Der schwierige Weg einer gemeinsamen Einigung muss bei so ziemlich jedem Geschäftsfall erzielt werden. Ganz klar erfordert eine Outsourcingpartnerschaft eine exorbitante Erhöhung der Kommunikation, Abstimmungen und Verhandlungen, was Zeit und Kraft beider Seiten erfordert. Dies bedeutet auch eine Zunahme der Durchlaufzeit und somit für den Kunden auch eine gewisse Schwerfälligkeit bei der Realisierung von Vorhaben, die einer Zusammenarbeit mit dem Dienstleister bedürfen. Des weiteren ist problematisch, dass vertrauliche Unternehmensdaten zwischen Dienstleister und Kunden ausgetauscht werden müssen. Wenn der IT-Dienstleister für die Administration des ERP-Systems verantwortlich zeichnet, dann ist klar, dass dieser Zugriff auf die sensibelsten Daten des Kunden hat. Dem müssen technische und organisatorische Sicherheitsmaßnahmen des Dienstleisters gegenüberstehen. Durch die vom Dienstleister angestrebte Standardisierung der Services können auch für den Kunden Qualitätseinbußen entstehen, da die Services ja nicht mehr zu hundert Prozent auf seine individuellen Bedürfnisse ausgelegt sind [STR05, S10f].

Es mangelt also nicht an Reibeflächen im Laufe der Outsourcingpartnerschaft. Mittlerweile sind viele Unternehmen von Outsourcingverhältnissen wie Near- oder Offshoring bereits abgekommen, da die Qualität der Services nicht zufriedenstellend sichergestellt werden konnte, sie es bei den in den 1990er-Jahren vielbeschworenen indischen Programmierdienstleistungen oder den globalen Servicedesks aus dem asiatischen Raum, die in naturgemäß schlechtem Deutsch unbedarften Endkunden die Handhabung von Bügeleisen erklären. Eine grundsätzliche Erkenntnis des Outsourcing und der in den letzten 15 Jahren gewonnenen Erkenntnisse ist es, dass Verantwortung nicht an Dritte ausgelagert werden kann, so intensiv und gern das auch versucht wurde. Letzen Endes steht immer der Kunde vor dem Scheinwerfer, da hilft es nichts, bei öffentlich gewordenen Incidents auf den Dienstleister zu verweisen. Ein gutes Beispiel wäre die unabsichtliche Veröffentlichung von Telekommunikationsdaten oder Datenschutzverletzungen durch den Dienstleister – betroffen und im Kreuzfeuer der Kritik ist der Telekommunikationsanbieter und nicht dessen IT-Dienstleister.

Positiv anzumerken ist aber, dass Outsourcing für einen Klein- und Mittelbetrieb ein probates Mittel sein kann, ein komplexes Thema einem professionellen Dienstleister zu überantworten. Gerade die IT benötigt teures Spezialwissen (z.B. Programmier- oder Technologiekenntnisse), ein Investitionsvolumen (z.B. für Hardware und Lizenzen) und hohe laufende Kosten für den Betrieb (z.B. Rechenzentrum, Monitoring, Support, Bereitschaft außerhalb der normalen Arbeitszeit). Durch die zunehmende Professionalisierung kann der Kunde neue Technologien ohne größeren Aufwand nutzen und sich auf sein Kerngeschäft konzentrieren.

Wiederholungsaufgaben

1. Welche Schritte sind bei der Durchführung eines Outsourcings zu durchlaufen?

Die Lösungen zu den Wiederholungsaufgaben finden Sie in Anhang A.