IT-Governance - Gesamt
Melanie Rainer hat die wirtschaftliche Ausbildung in der HBLA für wirtschaftliche Berufe als Grundlage für das Studium der Angewandten Betriebswirtschaftslehre in Klagenfurt genutzt. Sie verbrachte ein Semester an der University of Northern Iowa und zwei Jahre bei Daimler AG im Bereich KAIZEN®/KVP-Kontinuierlicher Verbesserungsprozess. Nach den ersten Erfahrungen als Projektleiterin bei MANOVA NetBusiness Solutions und hier speziell mit Themen wie Benchmarking, Marktforschung und Kundezufriedenheit in der Seilbahnbranche und Hotellerie wechselte sie in die Welt der Financial Services zur Allianz Elementar Versicherung in die Betriebsorganisation. Sie leitete interne und externe Projekte und agierte als Business Analyst für Prozessoptimierungen. Berufsbegleitend absolvierte sie den Bachelor Wirtschaftsinformatik an der FernFH. Bei PwC ist Melanie Rainer seit 2011 tätig und ist verantwortlich für IT-Audits, Interne Revisionen und Projekte im FS Bereich. Weitere Projekte wie z.B. Umsetzung eines operativen IT-Controllings, Softwaredokumentationsprojekte, Prozess-modellierung, Portfolio- und Programmmanagement sind Teil ihrer Projektliste als IT-Beraterin. Derzeit ist sie zertifizierte Projektmanagerin (IPMA Level C), CFSA-Certified Financial Services Auditor, ITIL Foundation v3 und als Schadensach-bearbeiterin zertifiziert.
Thomas Neuroth-Pfeiffer konnte bereits während seines Studiums der Wirtschaftsinformatik an der Universität Wien in allen relevanten Bereichen des operativen IT Betriebs der Österreich Werbung praktische Erfahrungen sammeln. Es folgten mehrere Jahre der Koordination und Leitung von Softwareentwicklungsprojekten, wobei die prozessorientierte Anforderungsanalyse im Vordergrund stand. Während seiner fast dreijährigen Beschäftigung bei der BOC Unternehmensberatung GmbH beriet er als Senior Consultant zahlreiche Unternehmen bei der Einführung von Geschäftsprozess-, IT-Architektur- und IT-Service Management, bevor er bei ACP IT Solutions GmbH die interne IT der Unternehmensgruppe stellvertretend führte und mehr als drei Jahre für IT-Service Management (ITSM) verantwortlich war. Derzeit ist der zertifizierte ITIL Service Manager V2, ITIL Expert V3, CISA und CISM als Enterprise Architect bei Microsoft Österreich tätig.
Martin Latzenhofer hat nach einer HTL-Ausbildung für EDV und Organisation und dem Studium der Wirtschaftsinformatik auf der Universität Wien mehrere Jahre IT Security Management bei max.mobil (später T-Mobile Austria) mitgestaltet und neben Prozessthemen mit Sicherheitsbezug – wie Identity Management, Business Continuity Management und Outsourcingsteuerung – auch beim Aufbau des formalen Internen Kontrollsystems (IKS) gemäß Sarbanes Oxley im Bereich IT mitgewirkt. Danach war er bei KPMG Austria im Bereich Information Risk Management/IT Advisory beschäftigt und hat als Prüfer oder Berater IKS-Projekte, SAS70-Prüfungen, IT-Aspekte bei Jahresabschlussprüfungen, Prozessberatungen bei namhaften österreichischen IT-Dienstleistern und Großunternehmen begleitet. Anschließend war er bei ACP IT Solutions in Wien für IT Service Management und später für Audit, Controls und Processes des Bereichs Solution Sales verantwortlich. Nach seiner Tätigkeit als Berater und Trainer für IT-Service-Management beim Team von ITSM Partner übernahm er die Leitung der Abteilung IT & Organisation bei MyPlace SelfStorage. Mittlerweile arbeitet er als wissenschaftlicher Mitarbeiter bei der Universität Wien, Forschungsgruppe Multimedia Information Systems an seiner Doktorarbeit. Neben seinen hauptberuflichen Tätigkeiten und dem Erwerb von Qualifikationen wie CISA, CISM, CRISC, ITIL Service Manager V2 und ITIL Expert V3 war er seit 2003 auch als externer Lektor für die Universität Wien und später auch als Vortragender bei der Akademie Interne Revision und seit Anbeginn bei der Fern-FH Wien tätig.
Christian Focke hat nach der HTL für elektrische Nachrichtentechnik und Elektronik Christian Focke das Studium der Technischen Physik an der Technischen Universität Wien absolviert. Während seines Studiums war er als selbstständiger EDV-Instruktor für die Kundenschule der IBM Österreich tätig, danach arbeitete er zunächst als Vertragsassistent und später als Universitätsassistent an der Technischen Universität Wien. Nach einiger Zeit verließ er dann den Bereich Forschung und Lehre und übernahm die Leitung des Zentralen Informatikdienstes an der Universität für angewandte Kunst Wien. Später wechselte er in die Privatwirtschaft und wurde Gruppenleiter System Integration Centre im Bereich IT Production bei max.mobil. (später T-Mobile Austria). Im Zuge eines Outsourcing-Deals wurde er danach zum Security Officer der Service Line IT Operations bei T-Systems Austria bestellt. Im Anschluss daran arbeitete er einige Jahre bei KPMG Austria im Geschäftsbereich IT Advisory, zuletzt als Manager, von wo ihn die BAWAG P.S.K. als Prozessmanager und Projektmanager in die Abteilung IT Business Relationship Management abwarb, später dann ebenso ITSM Partner Consulting, für welche er dann als Senior Consultant und Trainer tätig war. Derzeit ist er selbstständig als Auditor, Consultant und Trainer tätig. Seine Qualifikationen sind CISA, CISM, MCTS (Software Asset Management), CISSP, ISO 9001 Auditor, ISO/IEC 27001 Auditor, ITIL V3 Expert (davor ITIL V2 Service Manager), PRINCE2 Practitioner und COBIT 5 Approved Trainer.
Definition und Abgrenzung von IT-Governance
Ziele der Lektion
- Grundlegendes Verständnis für IT-Governance
- Verstehen der Abgrenzung zwischen IT-Governance und IT-Management
Der internationale Standard ISO/IEC 38500:2008 definiert IT-Governance wie folgt [ISO08]:
1.6.3 Corporate governance of IT
The system by which the current and future use of IT is directed and controlled.
Corporate governance of IT involves evaluating and directing the use of IT to support the organization and monitoring this use to achieve plans. It includes the strategy and policies for using IT within an organization.
Der Evaluate-Direct-Monitor-Zyklus bildet das zentrale Element von IT-Governance nach ISO/IEC 38500:
Darauf aufbauend definiert das internationale Framework COBIT 5 in der deutschen Fassung IT-Governance wie folgt [COB12]:
Governance
Governance stellt sicher, dass die Anforderungen, Rahmenbedingungen und Möglichkeiten der Anspruchsgruppen evaluiert werden, um ausgewogene und vereinbarte Unternehmensziele zu bestimmen, die es zu erreichen gilt. Sie gibt die Richtung durch die Festlegung von Prioritäten und das Fällen von Entscheidungen vor und überwacht die Leistung und Regeleinhaltung gegen vereinbarte Vorgaben und Ziele.
Die Gesamtführung liegt in den meisten Unternehmen in der Zuständigkeit der Geschäftsleitung, die wiederum der Führung des Vorsitzenden unterliegt.
COBIT 5 unterteilt in weiterer Folge die zu IT-Governance gehörenden Aktivitäten in die folgenden 5 Prozesse auf [COB12]:
EDM01 Sicherstellen der Einrichtung und Pflege des Governance-Rahmenwerks
EDM02 Sicherstellen der Bereitstellung von Mehrwert
EDM03 Sicherstellen der Risiko-Optimierung
EDM04 Sicherstellen der Ressourcen-Optimierung
EDM05 Sicherstellen der Transparenz gegenüber Anspruchsgruppen
COBIT 5 grenzt IT-Governance in diesem Zusammenhang deutlich von IT-Management ab [COB12]:
Management
Management plant, erstellt, betreibt und überwacht Aktivitäten – im Rahmen der von der Governance vorgegebenen Richtung –, um die Unternehmensziele zu erreichen.
Das Management liegt in den meisten Unternehmen in der Zuständigkeit der Geschäftsführung, die einem Geschäftsführer oder CEO obliegt.
COBIT 5 unterteilt die zu IT-Management gehörenden Aktivitäten in weitere, insgesamt 28 Prozesse, zusammengefasst in die 4 Management-Domänen [COB12]:
Anpassen, Planen und Organisieren, APO (Align, Plan, Organise)
Aufbauen, Beschaffen und Implementieren, BAI (Build, Acquire, Implement)
Bereitstellen, Betreiben und Unterstützen, DSS (Deliver, Service, Support)
Überwachen, Evaluieren und Beurteilen, MEA (Monitor, Evaluate, Assess)
auf die in der Lehrveranstaltung “IM411 Management von IT-Prozessen“ detaillierter eingegangen wird. Alle anderen Aspekte – nicht prozessbezogenen – von COBIT 5 werden in der Lehrveranstaltung “IM534 IT-Frameworks und Methoden“ näher betrachtet.
Der Planen-Aufbauen-Ausführen-Überwachen-Zyklus (Plan-Build-Run-Monitor Cycle) bildet den Kernbereich von IT-Management nach COBIT 5:
Nach COBIT 5 gibt es also drei wesentliche Schnittstellen zwischen IT-Governance und IT-Management:
- Evaluieren – IT-Management meldet an IT-Governance zurück, ob, wie und wann IT die Geschäftsanforderungen erfüllen könnte
- Richtung vorgeben – IT-Management plant den Einsatz der IT-Ressourcen im Rahmen der von IT-Governance vorgegebenen Richtung
- Überwachen – IT-Management misst laufend die Aktivitäten innerhalb IT und liefert dadurch Daten für die Überwachung durch IT-Governance
Wertbeitrag von IT
IT-Abteilungen sehen sich verstärkt mit der Frage konfrontiert, welchen Beitrag die IT für ein Gesamtunternehmen leisten kann. Vor allem in Zeiten, in welchen Kosteneinsparungen ganz oben auf der Agenda von Besprechungen zwischen Chief Financial Officer (CFO) und Chief Information Officer (CIO) stehen, nimmt diese Frage einen immer höheren Stellenwert ein.
Die Antworten auf diese Frage fallen, je nach Verständnis des Begriffs „IT“ und Erfahrungen mit Technologien und deren Einsatz, unterschiedlich aus. Das Verständnis der „IT“ reicht von einer rein technischen bis hin zu einer service- und produktorientierten Sichtweise. Die Frage nach dem Beitrag der IT lässt sich also nicht pauschal beantworten.
Wichtiger als die Frage, ob sich IT rechnet, ist vielmehr, wie man die IT am besten einsetzen kann, damit sie einen Beitrag zum Unternehmenserfolg liefert [EBR03].
Entscheidend ist also das Management des Einsatzes der Technologien, um einerseits den effektiven und effizienten Einsatz von IT-Technologien sicherzustellen und andererseits zu gewährleisten, dass diese im Einklang mit der Unternehmensstrategie und den daraus abgeleiteten Unternehmenszielen genutzt werden. Diese Forderung wird als IT Business Alignment bezeichnet.
Darüber hinaus muss beim Einsatz von Technologien die Einhaltung sämtlicher gesetzlicher und regulatorischer Vorgaben berücksichtigt und sichergestellt werden. Die Konformität der IT mit Regeln und gesetzlichen Vorgaben wird als IT Compliance bezeichnet.
IT Business Alignment und IT Compliance für sich allein genommen können aber zu keinem Wettbewerbsvorteil für ein Unternehmen führen. Es ist vielmehr die Kombination aus beiden, die aus der IT einen Erfolgsfaktor für das Gesamtunternehmen machen kann.
Diese Kombination kann als IT-Governance bezeichnet und als Faktor zur Herstellung und Sicherung des Wertbeitrags der IT gesehen werden.
IT Business Alignment
Ziele des IT Business Alignment sind ein optimierter Abgleich zwischen Unternehmens- und IT-Strategie, eine optimierte Unterstützung der Geschäftsprozesse und eine effektive und effiziente Nutzung der IT-Ressourcen. Die Aufgaben des IT Business Alignments liegen in einer Abstimmung der IT-Strategie, Organisation, den Prozessen und der Technologie mit jenen der Fachbereiche, damit sowohl IT als auch das Business gemeinsam an der Erreichung der Unternehmensziele arbeiten können. Bei diesem Abgleich handelt es sich allerdings um eine wechselseitige Beziehung zwischen Business und IT in der Form, dass sich die IT mit dem Business abstimmt und umgekehrt, was unter Umständen zu Anpassungen auf beiden Seiten führt [BGJ09].
Unterschiedliche Auffassung herrscht darüber, ob Alignment als Prozess oder Zustand angesehen werden kann [BGJ09, WJG06]. In Zeiten sich rasch ändernder Märkte und Bedürfnisse müssen sich auch Unternehmen rasch und flexibel an geänderte Marktsituationen anpassen. Das führt zu einem ständig wiederkehrenden Abgleich zwischen IT und Business, was IT Business Alignment zu einer Daueraufgabe werden lässt. Unter diesem Blickwinkel kann IT Business Alignment als Prozess betrachtet werden, welcher im Unternehmen etabliert werden kann.
Um die Ziele des IT Business Alignment zu erreichen, gilt es, eine Reihe an Aspekten und Herausforderungen zu beachten.
Um IT Business Alignment einzuführen, zu etablieren und nachhaltig im Unternehmen zu festigen, können Referenzmodelle und Standards eine breite Unterstützung liefern. Referenzmodelle werden auf Basis von Praxiserfahrungen entwickelt. Ein Referenzmodell besteht 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.
So widmen sich beispielsweise die „Best Practices“ von ITIL (IT Infrastructure Library) und der Standard ISO 20000 dem Thema IT Service Management, CobiT (Control Objectives for Information and Related Technology) kann als Modell für IT -Governance und zur Sicherstellung der Einhaltung gesetzlicher Anforderungen positioniert werden, CMMI (Capability Maturity Model Integration) hat seinen Fokus auf der Serviceerbringung und Systementwicklung und Prince2 bietet ein Referenzmodell für prozessorientiertes Projektmanagement.
Wiederholungsaufgaben
- Beschreiben Sie kurz, woraus sich IT-Governance zusammen setzt und warum die Einführung von IT-Governance für ein Unternehmen wichtig ist.
Lösungen
Beschreiben Sie kurz, woraus sich IT-Governance zusammen setzt und warum die Einführung von IT-Governance für ein Unternehmen wichtig ist.
IT-Governance ist die Kombination von IT Business Alignment und IT-Compliance. IT Business Alignment soll den effektiven und effizienten Einsatz von IT-Technologien sicherzustellen und gewährleisten, dass diese im Einklang mit der Unternehmensstrategie und den daraus abgeleiteten Unternehmenszielen genutzt werden. Mit der IT-Compliance wird sichergestellt, dass der Einsatz von Technologien in Einklang mit relevanten gesetzlichen und regulatorischen Vorgaben erfolgt. Mit der Einführung von IT-Governance soll ein Wertbeitrag der IT für das Gesamtunternehmen hergestellt und nachhaltig gesichert werden. Ziel der IT-Governance ist es, aus der IT einen Erfolgsfaktor für das Unternehmen zu machen.
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
Vision, Mission, Ziele
Das zentrale Element beim Aufsetzen eines Managements für eine Organisationseinheit ist die grundlegende Zielsetzung. Den Mitarbeiter*innen der Organisationseinheit muss klar werden, wofür ihre Organisationseinheit steht, welche Vision sie verfolgt (was?) und wie sie diese umsetzen möchte und 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 Mitarbeiter*innen 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*innen 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 Finanzchef*innen die „eigentlichen“ Geschäftsführer*innen. 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*innen, 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 Kund*innen 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.
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].
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
- Was ist CSI, welche Zielsetzung wird damit verfolgt und wie ist es strukturiert?
Lösungen
Was ist CSI, welche Zielsetzung wird damit verfolgt und wie ist es strukturiert?
Im Teil Continual Service Improvement (CSI) aus ITIL v3 wird der kontinuierliche Verbesserungsprozess als Verbindung von Strategie mit der Unternehmensvision bis zur konkreten Messung über ein Stufenmodell (Abb. 2.1) beschrieben. Die Gewinnung von Informationen im Rahmen der Messung bildet ein zentrales Element für den Sieben-Schritte-Verbesserungsprozess für CSI (Abb. 2.2). 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.
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 Kund*innen, 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.
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*der IT-Leiter*in, die IT im Unternehmen zu positionieren. Als erster Indikator kann die Einbindung des*der IT-Leiter*in in die Geschäftsleitung herangezogen werden. Fehlt dem CIO das „C“, muss davon ausgegangen werden, dass IT-Belange nur über den verantwortlichen Geschäftsleiter*innen 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*e Techniker*in zu finden ist, eher Betriebswirt*innen. 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 technologischer Aspekte unter einem*einer Geschäftsbereichsleiter*in, der*die auch kraft seiner theoretischen Grundlage (als Techniker*in!) auch in der Lage ist, seinen*ihren Bereich durchgehend zu verstehen und die Sache bei den oftmals technisch nicht ausreichend versierten Geschäftsbereichsleiterkolleg*innen zu vertreten.
IT als Dienstleister – „run the business“
In der beruflichen Praxis haben die Autor*innen 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) Kund*innen gesehen, wobei das Paradigma der „internen Kund*innen“ 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-Mitarbeiter*innen 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*innen 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 Outsourcing-Partnerschaften 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*innen 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 Mitarbeiter*innen 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-Mitarbeiter*innen 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 Marktbegleiter*innen 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 Neukund*innen 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*die Anwender*in Vertrauen in die Technologie gefasst hat, wird er*sie 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
- Beschreiben Sie kurz die Komponenten des IT Business Alignment und stellen Sie die Zusammenhänge (grafisch) dar.
Lösungen
Beschreiben Sie kurz die Komponenten des IT Business Alignment und stellen Sie die Zusammenhänge (grafisch) dar.
IT Business Alignment setzt sich aus IT Service Management und IT-Architektur-Management zusammen. IT Service Management umfasst 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. Graphische Darstellung siehe Seite 18.
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 zusammen. 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*innen(-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?
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 widerspiegelt. 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 Kund*innen beschrieben werden. Servicekataloge sind häufig in IT-Services, Servicemodule und Serviceelemente gegliedert. Durch diese Gliederung können den Kund*innen klar abgrenzbare Leistungsbeschreibungen angeboten werden, deren Leistungsumfang, Qualität und Menge und somit auch der Preis auf Servicemodulebene durch den*die Kund*in beeinflusst werden kann.
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.
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.
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 und 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:
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].
Beispielhafte Referenz-Prozessmodelle
| Softwareentwicklung | * ISO/IEC 12207 (Information technology - Software lifecycle processes)
|
|---|---|
| IT Service Management |
|
| IT Security Management |
|
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*die Empfänger*in 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 Anwender*innen 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]:
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 Kennzahlenkatalogen 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, Kund*innen, Lieferant*innen 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 erstellten 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 Adressat*innen (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,
- 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 Kund*innen auf die IT ab (bspw. Zufriedenheit der Anwender*innen 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 |
|
|
| Kundenperspektive |
|
|
| Prozessperspektive |
|
|
| Lern- und Entwicklungsperspektive |
|
|
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 Mitarbeiter*innen 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 Teilnehmer*innen 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*die 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*innen 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 Vergleichspartner*innen. 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.
Der Vergleichshorizont gibt an, ob die Vergleichspartner*innen 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 Teilnehmer*innen 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*innen erfordert, um die identifizierten „Good- und Best-Practices“ für den eigenen Bereich zu übernehmen [TIE09, S421ff].
Wiederholungsaufgaben
- Welche Reifegrade gibt es und was sagen diese grob über den Prozess aus?
- Was sind Referenzmodelle und wie können diese bei der Einführung von IT-Governance unterstützen?
- Welche Problemfelder entstehen allgemein durch Aufstellen einer Messmetrik?
- Welche Blickwinkel werden im Rahmen einer BSC betrachtet und wie werden diese durch Messung mit Daten befüllt?
- 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:
- Konsequenzen von vorangegangenen Entscheidungen auswerten
- Richtungsweisungen für Zielerreichungsaktivitäten setzen
- Messergebnisse für eine Rechtfertigung für angeordnete Aktivitäten anwenden
- 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
- Finanzen
- Kund*innen
- Prozesse
- Mitarbeiter*innen (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.
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
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*innen, 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*innen 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*innen 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*innen 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*innen weiterhin die Systeme betreuen – oder Hosting – wenn es um zusätzliche Dienstleistungen geht, 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*die Nutzer*in von Cloud Computing kann selbst den Zeitpunkt bestimmen, wann er*sie ein Cloud Service benützen will, und er*sie 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 Nutzer*innen gemeinsam benutzt; es ist für den*die einzelne*n Nutzer*in nicht transparent, welcher Teil der Ressourcen für ihn*sie verwendet wird
- Rapid elasticity: die Gesamtmenge der eingesetzten Ressourcen kann schnell an steigende oder sinkende Gesamtanforderungen aller Nutzer*innen zusammen angepasst werden
- Measured Service: die Nutzung der Ressourcen durch den*die einzelne*n Nutzer*in 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*die Nutzer*in 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*die Nutzer*in 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*die Nutzer*in ist selbst nur mehr für die eventuelle Konfiguration der Anwendungssoftware für seine*ihre individuellen Zwecke verantwortlich
und vier Deployment-Modelle:
- Private Cloud: die Ressourcen stehen im Eigentum eines Unternehmens oder Konzerns und werden nur von Nutzer*innen 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*jeder 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*die Kund*in 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.
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 Kund*innen und Dienstleister aufweisen, also etwa Change Management. Die Abläufe und jeweiligen Verantwortungen müssen wohldefiniert sein, um ein reibungsloses Zusammenwirken der beiden Partner*innen 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*der Kund*in ist erforderlich, um den Dienstleister in eine Richtung zu bewegen, die den Geschäftszielen des*der Kund*in 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*innen 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, jene*n Anbieter*in herauszufinden, der*die am besten zum*zur Kund*in passt („Business Partner Compliance“). Am Ende der Ausschreibung, bei der auch aktiv Teilnehmer*innen 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 Anbieter*innen 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*die Anbieter*in den*die Kund*in 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*der ausgewählten Anbieter*in einen Vertrag auszuarbeiten, der die Anforderungen des*der Kund*in bestmöglich erfüllt (insbesondere auch dessen*deren 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 bestehenden 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*innen genannt und Eskalationsmechanismen geregelt werden. Auch muss ein sogenanntes Unit Cost Pricing etabliert werden, dass es dem*der Kunden*in in Zukunft erlaubt, einzelne Servicepakete zu kalkulieren und zu erwerben, z.B. Preis eines IT-Arbeitsplatzes. Nicht nur die Prozesse, auch die Unternehmenswerte, die ihre*n Besitzer*in 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 Kund*innen. Nach einer ersten vorliegenden Version beginnen die Vertragsverhandlungen, bei denen die Partner*innen 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*innen, 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*innen, der Ü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*der Kund*in 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 Partner*innen thematisiert und beseitigt werden.
Transformation Phase
Spätestens dann, wenn für den*die Kund*in der Normalbetrieb startet, beginnt für den*die Anbieter*in die Transformation Phase. In der Regel verspricht der*die Anbieter*in dem*der Kund*in, ihm*ihr dieselbe – oder sogar eine bessere – Servicequalität zu einem niedrigeren Preis zu liefern. Das ist aber nur dann möglich, wenn der*die Anbieter*in die Leistungserbringung verändert, indem er*sie die bis dahin für die Leistungserbringung für den*die eine*n Kund*in dedizierten Teams, Wartungsverträge, technische Ressourcen etc. (also ein Dedicated Service Center) mit den für die Leistungserbringung für die Gesamtheit seiner*ihrer Kund*innen geteilten Teams, Wartungsverträgen und technischen Ressourcen (also ein Shared Service Center) konsolidiert und damit jene Economies Of Scale ausnützt, die ihm*ihr selbst offen stehen, seine*n*ihre*n Kund*in aber in der Regel nicht offen stehen würden. Dieser Transformationsprozess sollte im Idealfall so ablaufen, dass kein*e Kund*in davon etwas bemerkt.
Auflösung
Falls später ein Insourcing oder der Wechsel des*der Anbieter*in 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*der Anbieter*in 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*der Kund*in 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 Kund*innen zu harmonisieren und zu skalieren. Jede Ausnahme bedeutet für ihn Aufwand und zusätzliche Kosten, er wird zunehmend dem Minimierungsprinzip folgen. Der*die Kund*in wiederum sieht sich als der*die wichtigste Partner*in seines Dienstleisters und will möglichst individuell fokussierte Services, die genau seinen*ihren 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*innen“. In der Praxis zeigt sich, dass sich natürlich etwas ändert – ja, ändern muss, da der vorherige Zustand für den*die Kund*in ja unbefriedigend war – und der Vertrag das Um und Auf des Zusammenlebens darstellt. Dabei lässt sich auch der Unmut der Mitarbeiter*innen erklären, Outsourcingdeals uneingeschränkt zu folgen. Outsourcing wurde auch als Instrument für Stellenabbau angewendet, viele überbundene Mitarbeiter*innen 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*die Kund*in 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 von dem*der Kund*in von höherer Stelle abverlangt. Daher ist das vertraglich gesicherte Auditrecht eine wesentliche Komponente für die Outsourcingsteuerung.
Der*die Kund*in ist angehalten, die Services des Dienstleisters auf Basis seiner*ihrer 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*die Kund*in 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 Kund*innen 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*der Kund*in 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*die Kund*inQualitätseinbußen entstehen, da die Services ja nicht mehr zu hundert Prozent auf seine*ihre 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*die Kund*in 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*die Kund*in neue Technologien ohne größeren Aufwand nutzen und sich auf sein*ihr Kerngeschäft konzentrieren.
Wiederholungsaufgaben
- Welche Schritte sind bei der Durchführung eines Outsourcings zu durchlaufen?
Lösungen
Welche Schritte sind bei der Durchführung eines Outsourcings zu durchlaufen?
Ist-Analyse, Ausschreibung, Due Diligence, Anbieterentscheidung, Vertragsausarbeitung, Vertragsverhandlungen, Transition Phase, Normalbetrieb, Auflösung.
IT Service Management
Ziele der Lektion
Kennenlernen von etablierten IT-Service-Management-Konzepten
Verständnis für die Prozesse in IT Service Management
-
Grundsätzliches Konzept
Unter IT Services können geschäftsprozessunterstützende IT-Funktionen, die sich den Nutzern meist als geschlossene Anwendungen präsentieren, verstanden werden. Die Nutzer*innen müssen dabei durch die IT Services, wann immer sie es benötigen, bei ihrer Zielerreichung unterstützt werden.
Das bedeutet, dass ein IT Service dem*der Nutzer*in nur dann einen bestimmten Wert oder Nutzen liefern kann, wenn das IT Service sowohl zweckdienlich (WAS bekommt der*die Kund*in?), als auch zur richtigen Zeit und in der richtigen Qualität verfügbar (WIE bekommt der*die Kund*in die Leistung?) ist.
Ein IT Service kann dann als zweckdienlich (Utility) angesehen werden, wenn das IT Service durch die angebotenen Funktionalitäten die Leistungsfähigkeit oder die Flexibilität des*der Nutzer*in erhöht.
Damit das IT Service dem*der Nutzer*in in einer angemessenen Qualität (Warranty) zur Verfügung gestellt werden kann, müssen Verfügbarkeitszeiten, ausreichende Kapazitäten, Wiederherstellungsmaßnahmen im Katastrophenfall und hinreichende Sicherheit gewährleistet werden.
Wesentlich ist das Verhältnis zwischen der Zweckdienlichkeit und angebotener Qualität.
Hier muss ein vernünftiges Gleichgewicht gefunden werden. Ein IT Service, das jederzeit leistungsstark angeboten wird, für den*die Nutzer*in allerdings keinen Zweck hat, ist für den*die Nutzer*in genauso wertlos, wie ein IT Service, das zwar alle Anforderungen des*der Nutzer*in abdeckt, jedoch nur außerhalb der Geschäftszeiten verfügbar ist.
Die Aufgaben des IT Service Managements umfassen somit die Planung, Entwicklung, Überwachung und Steuerung von IT Services über ihren kompletten Lebenszyklus mit dem Ziel, die Geschäftsprozesse des Unternehmens effektiv und effizient zu unterstützen. Darüber hinaus sollen die IT Services den Kund*innen zu angemessenen und marktüblichen Preisen angeboten werden.
Für ein erfolgreiches IT Service Management müssen bei der Optimierung der Erbringung der IT Services immer drei zentrale Zielgrößen im Auge behalten und dabei auf die richtige Balance zwischen den folgenden drei Größen geachtet werden:
- Servicequalität
- Zeit
- Kosten
Dieses Dreieck kann durchgängig für die Planung, die Steuerung und die Kontrolle der IT-Service-Management-Prozesse herangezogen werden. Ändert sich eine der Größen z.B. durch externe Einflussfaktoren, so kann das positive, aber auch negative Auswirkungen auf die anderen Größen haben [ETI05].
Beispielsweise kann die Qualität eines neuen IT Services gesteigert werden, indem mehr Zeit in die Entwicklung investiert wird. Dies hat aber zwangsläufig auch einen Anstieg der Entwicklungskosten zur Folge. Wird andererseits zu viel Augenmerk auf die Reduktion von Kosten gelegt, kann sich das gegebenenfalls negativ auf die Qualität der bereitgestellten IT Services auswirken.
Eine termingerechte Bereitstellung der gewünschten IT Services gehört zu den zentralen Zielen des IT Service Managements, wobei hier aber auch auf die gelieferte Qualität und die entstehenden Kosten zu achten ist. Um das zu ermöglichen, legt das IT Service Management Funktionen und Prozesse für die Strategie, den Entwurf, die Entwicklung, den Betrieb und die stetige Verbesserung von IT Services fest. Innerhalb des IT Service Managements sehen sich die beteiligten Personen, sowohl Lieferant*innen als auch Konsument*innen von IT Services, mit einer Reihe von Herausforderungen konfrontiert.
So sind die Ergebnisse (Outputs) von Serviceprozessen immateriell und nicht „greifbar“. Eine Messung, Validierung der Prozessleistung und Steuerung gestaltet sich daher als schwierig. Die Nachfrage nach IT Services und deren Umfang hängt sehr stark von den Anforderungen der Kund*innen hinsichtlich deren Nutzer*innen, Prozessen, Anwendungen etc. ab. Der direkte Kontakt zwischen Servicelieferant*in und Servicekonsument*in lässt kaum Platz für Toleranzbereiche bei Beeinträchtigungen. Kund*innen wollen sichergehen, dass IT Services immer zur Verfügung stehen.
IT Services können allerdings nicht „auf Vorrat“ produziert werden, was direkten Einfluss auf das Management von Bedarfen und Verfügbarkeiten hat.Es wurden viele Methoden, Modelle und Werkzeuge für die Unterstützung von IT Service Management entwickelt, wobei sich lediglich ein Ansatz flächendeckend etablieren konnte. Das „Best-Practice“-Regelwerk ITIL wurde Ende der Achtzigerjahre von der britischen Regierung initiiert, um den effektiven und effizienten Einsatz von IT-Mitteln sicherzustellen und konnte sich als De-facto-Standard durchsetzen.
ITIL bietet ein generisches Rahmenwerk für die zu implementierenden IT-Prozesse. Ziele, Aktivitäten, Inputs und Outputs der verschiedenen Teilprozesse innerhalb der IT-Organisation werden zwar beschrieben, die konkrete Ausgestaltung der Prozesse bleibt den Unternehmen jedoch selbst überlassen. ITIL in der Version 3 besteht im Wesentlichen aus fünf Teilen, in welchen jeweils empfohlene Prozesse und Vorgehensmodelle für die Phasen des Lebenszyklus von IT Services vorgestellt und beschrieben werden.
Ziele des IT Service Managements
Die Zielsetzung im IT Service Management liegt darin, dem Business die benötigten IT Services zum richtigen Zeitpunkt, in einer angemessenen und vereinbarten Qualität und zu marktfähigen Preisen bereitzustellen.
Für das Unternehmen bedeutet das eine optimale Unterstützung seiner Geschäftsprozesse und die Steigerung der Produktivität der Nutzer*innen. Im besten Fall sollen neue Geschäftsbereiche ermöglicht werden und ein Wertbeitrag von der IT für das Unternehmen geliefert werden.
Aus Sicht der IT werden hauptsächlich IT Services bereitgestellt, für die es auch einen Bedarf und eine Nachfrage gibt. Auf IT- und Business-Seite besteht Klarheit über die Qualität, mit der die IT Services bereitgestellt werden müssen. Die Prozesse für die Bereitstellung und Betreuung der IT Services werden definiert, was zu klaren Verantwortungen und einer effizienteren Bearbeitung von Änderungen und Störungen von IT Services führt. Durch einen kontinuierlichen Verbesserungsprozess werden die IT Services und die IT Serviceprozesse stetig an die Unternehmensbedürfnisse angepasst. Für die IT bedeutet das ein gesteigertes Ansehen sowie Reduktion von Kosten innerhalb der IT. Die IT soll sich somit von einem Cost Center zu einem Business Enabler wandeln.
Service Level Management
Die wahrscheinlich am weitest verbreitete Methode für das Messen von IT ist der Einsatz eines strukturierten Service Level Managements. Nicht zuletzt aufgrund der immer stärkeren Dienstleistungsorientierung und dem gestiegenen Outsourcinggrad von IT kommt dem Service Level Management eine zentrale Bedeutung zu. Es liegt auf der Hand, dass bei einer ausgelagerten IT an eine andere Organisationseinheit oder sogar einem anderen Unternehmen grundsätzliche Auffassungsunterschiede sowohl in strategischer, taktischer, aber auch operativer Hinsicht entstehen. Ein anderes Unternehmen verfolgt andere Ziele, richtet sich anders aus und versucht, die Aktivitäten anders zu skalieren als eine interne IT, die sich voll und ganz auf das eigentliche Kerngeschäft des Unternehmens ausrichten kann. In den schlimmsten Management-Auffassungen widergespiegelt kann es sogar sein, dass IT nur als notwendiges Übel gesehen wird und ausschließlich „zu funktionieren hat“. IT-Dienstleister wenden in der Regel das Minimalprinzip an, sie wollen einen möglichst hohen Output mit dem geringsten Aufwand und das auch skaliert über alle Kund*innen. Ein Dienstleistungsnehmen will größtmögliche Qualität und vollste Ausrichtung auf seine Ansprüche. Dieser offensichtliche Diskrepanz kann nur mit guten konkreten bilateralen Vereinbarungen – den Service Level Agreements (SLA) – begegnet werden.
Vertragsformen (Rechtliche Grundlagen)
Service Level Management ist wohl eine ganz eigene Disziplin, es bildet ein Herzstück des IT Service Managements, da es die zentrale Kommunikationsschnittstelle mit dem*der Kund*in und damit die schriftliche Grundlage der Kunden-Dienstleister-Beziehung darstellt. Es stellt sicher, dass alle IT-Service-Management-Prozesse, interne Vereinbarungen mit Organisationseinheiten desselben Unternehmens – Operational Level Agreements (OLA) – und Underpinning Contracts (UC) mit externen Sublieferant*innen für die Erbringung der gesetzten Service-Ziele und damit die Einhaltung der Service Level Agreements (SLA) gegenüber dem*der Kund*in des IT-Dienstleisters angemessen definiert wurden. Die SLAs definieren Qualität und Menge der zu erbringenden definierten Dienstleistung über einen vereinbarten Zeitraum und bestimmen die finanziellen Zahlungen an den Dienstleister für die Serviceerbringung. Neue Kundenanforderungen an Aspekte des IT-Services – Service Level Requirements (SLR) – werden formuliert und dabei versucht, die Geschäftsziele mit den IT-Service-Zielen in Einklang zu bringen und die Erwartungen auf ein realistisches Maß zu bringen. Der Service-Dienstleister kann dadurch auch die Erwartungen des*der Kund*in in gewisser Weise steuern, sodass es ihm möglich ist, möglichst standardisierte Services anzubieten, die er mit den eingesetzten Mitteln skalieren kann. Oft weiß der*die Kund*in nicht definitiv, was er*sie möchte und muss ein gemeinsames Verständnis mit seinem*ihrem Dienstleister erst erarbeiten. Das daraufhin vereinbarte SLA steht sozusagen für den Kompromiss, was der Dienstleister erbringen und der*die Servicenehmer*in akzeptieren kann, sodass diese*r seine Geschäftsziele erreichen kann. Zusätzlich werden im Rahmen des Service-Level-Management-Prozesses operative Aktivitäten subsumiert, also die Vereinbarungen verhandelt, abgeschlossen, überwacht, berichtet, auditiert und ständig verbessert [NIT08, Seite 56][WAL06, Seite 10f].
Service Level Management setzt zusammenfassend, also mit SLAs, ein Instrument ein, mit dem die Leistung einer IT-Organisation gemessen werden kann. Es umfasst einen Zyklus aus Planung, Koordination, Abfassung, Vereinbarung, Leistungsmessung, Berichtswesen und Entwicklung von Verbesserungen, um die IT-Service-Qualität sicherzustellen und ständig weiterzuentwickeln. Es stellt die schriftlich definierte Kundenbeziehung zum Service-Dienstleister dar [TSD06, Seite 29].
Service-Katalog-Gestaltung
Viele Unternehmen haben allerdings schon bei Schaffung einer ersten Voraussetzung für ein funktionierendes Service Level Management – dem Erstellen eines Service-Katalogs – durchaus Schwierigkeiten. Um die Services überhaupt messen zu können, muss man die Services zuerst benennen und überhaupt definieren, was unter einem Service verstanden wird. Viele setzen ein IT Service mit einem IT-System gleich. In vielen Fällen setzen sich die Services aus anderen Services (oder Servicebausteinen) zusammen, z.B. wird das Netzwerk-Service für viele andere Services eine Basisgrundlage darstellen. Das mag trivial klingen, in einem gewachsenen Umfeld ist diese strukturierte Sicht allerdings nicht eingängig. Das heißt also, dass man sich als IT-Organisation Gedanken zu seinen Services aus Kundensicht (die End-to-End-Sicht) machen und diese in einem Servicekatalog zusammenfassen soll. Diese Services bestehen wiederum aus einzelnen Komponenten oder Bausteinen, die sich mitunter für verschiedene Services wiederholen und zusammenspielen. Das kann beliebig granularer werden, eine dreiteilige Abstufung in Service, Servicemodul und Service-Element erscheint sinnvoll, um eine praktikable Abstufung der Servicebausteine zu erhalten [RBK08].
Die Servicebausteine des Service Katalogs werden einzeln soweit wie möglich für die drei Abstufungen beschrieben und enthalten
- Kataloginformationen zur Einordnung in die Gesamtstruktur, Gültigkeit und Verantwortlichkeiten;
- Leistungsbeschreibung, welche das Service hinreichend spezifizieren soll, indem das angestrebte Service-Ergebnis, verwendete Servicebausteine, Service-Level-Parameter wie Beschreibung, Ausprägung, Mengenangaben, Pakete, Messmethoden und -zeitpunkte niedergeschrieben und damit definiert werden;
- organisatorische Regelungen wie Eskalationsverfahren, Fragen des Change Managements und des Supports (Erreichbarkeit, Reaktions- und Lösungszeiten in Bezug auf Incidents), Reporting und Preis-, Pönale- und Verrechnungsfragen, aber auch das Thema regelmäßige Service Level Reviews und Serviceverbesserung.
Durch die aufgestellte hierarchische Struktur kann der Service-Dienstleister feststellen, ob und mit welchen Servicebausteinen er die Kundendienstleistung erbringen möchte und ob das unter den gegebenen Voraussetzungen (Ressourcen, Aufwand, Kosten) auch theoretisch möglich ist. Es gibt andere Strukturvorschläge, die zwischen Rahmen-SLA auf Unternehmensebene, Standard-SLA auf Kundengruppenebene und Individual-SLA auf einzelne Kund*innen und/oder Services unterscheiden. Man muss für die jeweilige Situation die bestmögliche Struktur wählen. Allen Strukturmöglichkeiten gemein ist jedenfalls, dass eine konsistente Gestaltung des Servicekatalogs unabdingbar ist [RBK08][NIT08, Seite 56ff][TSD06, Seite 38f].
Wird der Service-Katalog dann noch um die vorgelagerte Service Pipeline erweitert, spricht man insgesamt laut ITIL vom Service-Portfolio. Die Service Pipeline behandelt die Frage, wie Services von der Marktidee über das Design entwickelt und in einen laufenden Betrieb überführt werden. Aus dem Service-Katalog herausfallende Services werden schließlich noch stillgelegt, wodurch der Service Life Cycle nach ITIL abgeschlossen wird. Salopp formuliert, behandelt die Service Pipeline das Change Management des Services [ISD07, Seite 73ff].
Service Levels
Auf Basis dieser Definitionen ist es nun möglich, eigene Kundenpakete zu schnüren und die Leistung zu beschreiben (Service Levels) und damit quantitativ und qualitativ mit dem*der Kund*in zu vereinbaren, also ein SLA abzuschließen. In den Service Levels fließen sozusagen die gegenseitigen Erwartungen ein. Zusätzlich bekommt der Service-Dienstleister ein konkretes Bild seines erforderlichen internen Aufwands für die Erbringung des Services und kann also eine Leistungsverrechnung innerhalb seiner Organisation auf Basis des Service Level Managements etablieren. Um messbare Größen zu haben, müssen in den SLAs Aspekte wie z.B. Verfügbarkeit pro Zeitperiode, Supportzeiten mit Behandlungsverfahren, Festlegen der erforderlichen Informationen bei Neuimplementierungen oder Zielzeiten usw. konkret in Zahlenwerten festgelegt werden. Diese Ziele sollen realistisch, erreichbar und wirtschaftlich formuliert sein. Es kann dadurch die Serviceerbringung – und darauf bezieht sich der hier dargestellte Aspekt des Messens hauptsächlich – regelmäßig überwacht, berichtet und dadurch ständig geprüft werden, ob die zuvor vereinbarten Service Level Agreements in der untersuchten Zeitperiode auch tatsächlich eingehalten wurden.
Das operative Service Level Monitoring kann unter Beteiligung des*der Kunden*in in Echtzeit über eine Kundenplattform erfolgen oder wird über ein z.B. monatliches Reporting durch den Dienstleister gewährleistet. Auch hier muss zuvor in der Leistungsbeschreibung genau definiert werden, was wie und wie oft überprüft werden soll und welche Zielwerte gesetzt werden. Durch die Charakteristik der Services, wenn sie aus vielen Bausteinen zusammengesetzt sind, besteht eine hohe Anforderung des Monitorings aus Kundensicht, also ein End-to-End-Monitoring. Zusätzlich muss im Bedarfsfall schnell eruiert werden können, welcher Baustein die gesetzten Toleranzlevels überschreitet und somit den SLA gefährdet. Spezielle komplexe Monitoring-Tools mit Drill-Down-Funktionalität können dabei unterstützen. Das Monitoring muss also sozusagen die abgestimmte Wahrnehmung des Service-Dienstleisters und des*der Kund*in repräsentieren, was in vielen Fällen keine leichte Aufgabe ist. Auch punktuelle Audits (Service Reviews) und Kundenzufriedenheitsanalysen mit dadurch initiierten Verbesserungsmaßnahmen – Service Improvement Programs (SIP) – sollen die qualitative Serviceerbringung unterstützen und weiterentwickeln. Damit werden die „weichen“ Aspekte der Kundenbefindlichkeit abgedeckt. Um auch einen Anreiz für die ständige Weiterentwicklung der Servicequalität zu schaffen, sollten z.B. jährliche Service Level Reviews im SLA festgelegt sein [TSD06, Seite 43f].
Werden Abweichungen festgestellt, muss es Instrumente geben, wie diese behandelt werden. In der Regel gibt es Service Management Runden zwischen Dienstleister und Kund*innen, wo technische und kommerzielle Aspekte bei Bedarf diskutiert und Lösungen vereinbart werden, die Partnerbeziehung und Kommunikation gepflegt und der Ausblick auf kommende Ereignisse – etwa geplante Serviceausfälle zwecks Durchführung von Wartungsarbeiten – besprochen werden.
Sowohl der Servicedienstleister als auch der*die Servicenehmer*in tun gut daran, die Leistungserbringung anhand der Messgrößen regelmäßig zu kontrollieren. Das heißt, beide Organisationen müssen sich den operativen Aktivitäten ausgiebig widmen, regelmäßig Daten überwachen und erheben, SLA-Einhaltung feststellen, in Berichte oder Key Performance Indicators (KPI) zusammenfassen und SLA-Verletzungen behandeln und Verbesserungen initiieren und durchführen. Ein gewisser bürokratischer Aufwand ist somit unumgänglich, soll das Service Level Management ja nichts weniger leisten als die üblicherweise mehr oder weniger divergierenden Ziele der Organisationseinheiten oder Unternehmen soweit im Zaum zu halten, sodass die Service-Erbringung insgesamt qualitativ hochwertig und für die Geschäftszielunterstützung des*der Kund*in optimal erfolgt. Dies ist eine Schlüsselfunktion für das Service Level Management, das auch als ein kompliziertes Bausteinsystem identifiziert werden kann. Es versucht, gegenseitige Abhängigkeiten von einzelnen Servicebausteinen zu identifizieren und die Konsistenz zueinander sicherzustellen, um – schließlich – den*die Kund*in in seinen Geschäftszielen optimal mit IT-Services zu unterstützen. Es übersetzt Kundenerwartungen in für die IT verarbeitbare Messgrößen und bildet die begleitenden Prozesse dazu ab (Plan, Build, Run). Dieses System ist ständig Änderungen und Adaptierungsbedarf unterworfen, womit sich der Service Level Manager als Koordinationsstelle zwischen Endkunden und internen Organisationseinheiten bei entsprechender Organisationsgröße durchaus einer hohen Auslastung konfrontiert sieht. Wird die Kunden-Servicedienstleister-Beziehung nicht solcherart restriktiv festgelegt – bleiben also genügend Freiräume und Interpretationsspielraum – ist man sehr oft mit Eskalationen, Klärungen, Diskussionen und Subvereinbarungen konfrontiert. Eine ideale Beziehung zwischen den beiden Interessensparteien wird wohl nicht möglich sein, denn in der Praxis ist es nur eine Frage des Ausmaßes, wieviel Energie man in die Interpretation der Vereinbarungen stecken muss. Aus Praxissicht trifft daher die Daumenregel zu: Je dürftiger die Vereinbarung ist, desto mehr Aufwand muss für die tägliche Koordination von Eskalationsfällen eigesetzt werden.
Wiederholungsaufgaben
- Beschreiben Sie jene zwei Aspekte, die bei der kundenorientierten Bereitstellung von IT Services aus Sicht der IT beachtet werden müssen?
- Welche Unterschiede bestehen zwischen SLA, OLA, UC?
- Sie wollen einen SLA mit ihrem Dienstleister abschließen. Wie gehen Sie prinzipiell vor?
Lösungen
In welcher Situation ist für Sie als Unternehmen eine SAS 70-/ISA 402-/ ISAE3402-Prüfung interessant?
Wenn Sie ein (IT-) Dienstleister sind, dessen Kund*in Teile von Prozessen und Kontrollen an Sie ausgelagert haben und diese Kund*innen die Effektivität des internen Kontrollsystems formal und regelmäßig nachweisen muss (z.B. aufgrund SOX oder „Euro-SOX“) und das auch die an Sie ausgelagerten Themen betrifft, ist für Sie so eine Prüfung interessant. Auch ist eine SAS 70 Prüfung sinnvoll, wenn Sie einer Institution oder Aufsichtsbehörde das Funktionieren des IKS bescheinigen müssen. Einerseits müssen Sie nicht jedem*jeder Kund*in dies einzeln nachweisen und haben nur einmal innerhalb einer festgelegten Zeitperiode Prüfer*innen zu betreuen (Aufwand!). Dabei ist der Inhalt eines SAS 70-Berichtes nicht auf die IT beschränkt.
Beschreiben Sie jene zwei Aspekte, die bei der kundenorientierten Bereitstellung von IT Services aus Sicht der IT beachtet werden müssen?
Ein IT Service kann einem*einer Nutzer*in nur dann einen bestimmten Wert oder Nutzen liefern, wenn das IT Service sowohl zweckdienlich (WAS bekommt der*die Kund*in?), als auch zur richtigen Zeit und in der richtigen Qualität verfügbar (WIE bekommt der*die Kund*in die Leistung?) ist. Ein IT Service ist zweckdienlich (Utility), wenn das IT Service durch die angebotenen Funktionalitäten die Leistungsfähigkeit oder die Flexibilität des*der Nutzer*in erhöht. Ein IT Service muss dem*der Nutzer*in aber auch in einer angemessenen Qualität (Warranty) zur Verfügung gestellt werden.
Welche Unterschiede bestehen zwischen SLA, OLA, UC?
Service Level Agreements (SLA) regeln das Außenverhältnis zwischen Kund*innenund Dienstleister, Operational Level Agreements (OLA) regeln das Innenverhältnis von Organisationseinheiten des Dienstleisters bei der Erbringung von aus mehreren Servicebausteinen zusammengesetzten Services. Underpinning Contracts (UC) stellen die Verträge mit externen Subdienstleistern aus Sicht des Dienstleisters dar.
Sie wollen einen SLA mit ihrem Dienstleister abschließen. Wie gehen Sie prinzipiell vor?
Der*die Kund*in formuliert seine*ihre Anforderung in einem SLR. Zuerst müssen aus dem Servicekatalog das erforderliche Service und seine Servicebausteine ausgewählt werden. Darin ist bereits eine Leistungsbeschreibung enthalten, die Auskunft gibt, ob der SLR prinzipiell unter den gegebenen Voraussetzungen (Ressourcen, Aufwand, Kosten) durch einen angebotenen Service Level (ein „geschnürtes“ Kundenpaket) abgedeckt werden kann. Abweichungen müssen mit dem*der Kund*in im Zuge der Verhandlung diskutiert und gegebenenfalls das resultierende SLA adaptiert werden, sodass beide Seiten (Kund*in und Dienstleister) ihre Erwartungen in dieser schriftlichen Vereinbarung („agreement“) wiederfinden. Im SLA werden auch v.a. Leistungsüberprüfung/Messung, Reporting, zeitliche und kommerzielle Regelungen festgehalten. Zusätzlich muss der einzelne SLA in die Gesamtstruktur der bestehenden SLAs eingefügt werden (Unternehmens-, Kundengruppen-, Individual-SLA).
IT Audit
Ziele der Lektion
- Kennenlernen und Verstehen des Konzepts eines Internen Kontrollsystems (IKS)
- Diskussion von IT-Prüfungsansätzen, Methoden und Grundlagen für Audits
- Vorstellen verschiedener Prüfungsvarianten
- Verständnisbildung für die Herangehensweise von IT-Auditor*innen
Immer und jederzeit ist es möglich, Teilbereiche von Prozessen nach Aufstellung von entsprechenden Prüfungszielen zu auditieren. Anhand eines Prüfprogrammes kann man dann strukturiert Einzelthemen mit verschiedenen Prüfungsmethoden betrachten. Diese können sein: Befragung, Beobachtung, nochmalige Durchführung, Durchsicht und Beurteilung anhand von Stichproben, kontrollorientierte Prüfung, Walkthrough, technische Prüfscripts bei Einsatz von IT-Systemen oder ähnliches. Für die Entwicklung eines Prüfprogrammes ist naturgemäß die Definition eines unabhängigen Sollzustandes erforderlich, wofür ein Framework herangezogen werden kann.
Die Prüfungserkenntnisse können nach Abschluss der Prüfung strukturiert erfasst und zum Beispiel nach resultierendem Risiko kategorisiert und dargestellt werden. Allerdings ist ein Audit keine klassische Messmethode, da die gewonnenen Erkenntnisse nicht wirklich zueinander in Beziehung gesetzt und quantifiziert werden. Dennoch ist es eine valide und bei Setzen von substanziellen Prüfungshandlungen sogar eine sehr aussagekräftige Methode für eine Prozess-Bestandsaufnahme respektive für eine Verifikation von gesetzten Prozessmanagement-Maßnahmen – allerdings eine im Hinblick auf den Aspekt Messung – unstrukturierte Art, da eine objektivierte Skala für die Einteilung fehlt. Weiters ist die Risikoeinschätzung sehr personen- und erfahrungsabhängig.
Vorgaben, was man zum Beispiel bei einer IT-Prüfung auditieren muss, finden sich in länderspezifischen Regelungen wie in Österreich z.B. die Fachgutachten KFS/DV1 „Die Ordnungsmäßigkeit von EDV-Buchführungen“ aus 1998 und KFS/DV2 „Abschlussprüfung bei Einsatz von Informationstechnik“ aus 2004 des Fachsenates für Datenverarbeitung des Instituts für Betriebswirtschaft, Steuerrecht und Organisation der Kammer der Wirtschaftstreuhänder*innen [KWT09]. Daraus haben sich natürlich bei den Wirtschaftsprüfungsgesellschaften unternehmenseigene Vorgaben entwickelt. In Deutschland existieren ähnliche Vorgaben als Regelungen des Instituts der Wirtschaftsprüfer*innen (IDW) Stellungnahmen zur Rechnungslegung (RS), Fachgutachten zur Prüfung der IT (FAIT) 1, 2 und 3 [IDW09].
Internes Kontrollsystem
Ein internes Kontrollsystem ist ein System aus verschiedenen Maßnahmen, die sicherstellen, dass die Abläufe richtig und effizient entsprechend der Unternehmensstrategie funktionieren. Es ist zumeist eine Kombination aus einer schriftlich formulierten Vorgabe (Richtlinien, Arbeitsanweisungen, Handbücher etc.) und daraus abgeleiteten Kontrollen und Abläufe (z.B. Formulare, Prüfungsschritte, Berichterstattung etc.). Es gibt unter Umständen auch eine gesetzliche Verpflichtung von Unternehmen, ein funktionierendes Internes Kontrollsystem nachzuweisen. Dieser Nachweis wird z.B. im Rahmen der Jahresabschlussprüfung durch Wirtschaftsprüfer*innen aufgrund internationaler Prüfungsstandards, wie z.B. IDW PS 260, ISA 315 oder ISA 330, gefordert. Das Interne Kontrollsystem beinhaltet dabei Regelungen zur Steuerung (internes Steuerungssystem), Regelung zur Überwachung der Einhaltung dieser Regelungen (internes Überwachungssystem) und die Integration dieser Regelungen in die Prozesse des Unternehmens (organisatorische Sicherungsmaßnahmen, Kontrollen).
Die Interne Revision spielt dabei eine bedeutende Rolle. Sie sorgt unter anderem dafür, dass das Interne Kontrollsystem definiert, überwacht und laufend verbessert wird. Die Interne Revision übernimmt auch die Aufgabe, die definierten Kontrollen als prozessunabhängige Überwachung zu überwachen und zu bewerten. Nichtsdestotrotz ist es letztendlich die Verantwortung der Geschäftsführung, für ein funktionierendes IKS zu sorgen [FRG07, S73ff].
Arten von IT- und Sicherheits-Audits
Es gibt verschiedene Anlassfälle, warum und ob es zu einer Prüfung des IT-Bereiches bzw. des implementierten ISMS kommen kann. Beispielsweise ist die Interne Revision interessiert daran, das Interne Kontrollsystem in der IT auf ihre Funktionsfähigkeit hin zu prüfen, um dem Vorstand zu berichten. Andererseits ist im Rahmen der Wirtschaftsprüfung die Prüfung der IT-Prozesse und -Systeme, die vom Jahresabschluss direkt oder indirekt betroffen sind, ein Bestandteil. Ein weiterer Anlassfall kann eine zukünftige Merger-and-Acquisition-Option ein Grund für eine Prüfung in Form einer IT Due Diligence sein. Auch eine vom Unternehmen selbst initiierte Prüfung kann ein durch externe Spezialisten durchgeführtes IT Audit oder Sicherheitsaudit zur Überprüfung und Monitoring der Performance der eingeführten Sicherheitsmaßnahmen begründen.
IT Due Diligence
Eine IT Due Diligence hat die Aufgabe, die IT als Untersuchungsobjekt sorgfältig zu analysieren, zu prüfen und zu bewerten. Dies geschieht in der Absicht, den Wert der IT und deren Wertbeitrag zum Unternehmensgeschäft einzuschätzen. Das Ziel ist es, einen quantifizierbaren Wert zu beziffern, um den Kaufpreis des Unternehmens zu verhandeln. In den offiziellen Due-Diligence-Prüfungen hat die explizite Prüfung von IT und Informationssystemen einen untergeordneten Stellenwert. Dies liegt u.a. auch daran, dass für die Verhandlungen harte Zahlen und Fakten benötigt werden und weiche Faktoren, zu denen auch der Wertbeitrag und Einfluss der IT gehört, vernachlässigt werden. Folgende Schwerpunkte können ein Teil einer IT Due Diligence sein [PUTZ11, S39ff]:
- Positionierung und Geschäftsintegration der IT
Eine starke IT (hoher Integrationsgrad in die Geschäftsprozesse und Einbindung in Entscheidungsprozesse) kann eine Integration positiv beeinflussen und die Zusammenführung von mehreren Unternehmen beeinflussen.
IT-Governance
Es ist für den*die Käufer*in wichtig, zu wissen, wie die Entscheidungsprozesse in der IT sind, wenn diese beispielsweise geändert werden sollen.
IT-Strategie
Ist eine klare IT-Strategie vorhanden, ist diese hinsichtlich der Eignung zur zukünftigen Geschäftsstrategie bewertbar. Ist keine IT-Strategie vorhanden, muss erhoben werden, nach welchen Grundsätzen die IT bisher gesteuert wurde. Dies wirft dann auch ein Licht auf das bisherige Managementpersonal in der IT.
IT-Organisation und Geschäftsmodell
Im Fokus ist die Organisation der Leistungserbringung für die Fachabteilungen/Geschäftseinheiten und deren Steuerung und Bewertung durch z.B. Service Levels.
Management- und Personalressourcen
Die Beurteilungen der fachlichen und persönlichen Kompetenzen des IT-Managements und Schlüsselpersonals können mehr oder weniger Auswirkungen auf die Veränderungen im Personalstand haben.
Prozessleistung
Der Reifegrad der Prozesse im Unternehmen bestimmt die Anforderungen an die IT. Ist der Reifegrad hoch, ist auch die IT gefordert, die Prozesse optimal zu unterstützen. Dann ist die IT beispielsweise auch gerüstet, Prozesse hohen Reifegrades des Zielunternehmens zu unterstützen.
Rechtliche Rahmenbedingungen und Risikomanagement
Dabei werden die IT-Dienstleistungsverträge, Lizenz- und Softwarerechte, Nutzungsrechte von Infrastruktur sowie Mitarbeiterverträge geprüft und mit den Verträgen und der IT-Strategie des Zielunternehmens abgeglichen. Dabei kann es z.B. auch zu Optimierungspotenzial kommen. Auch Risiken (technisch, organisatorisch, rechtlich und personell) werden bewertet.
IT-Standards und Infrastruktur
Die bestehende Architektur, Infrastruktur und eingesetzten Technologien werden den Zukunftsplänen gegenübergestellt. So kann beispielsweise auch die Notwendigkeit der Ablöse des bestehenden ERP-Systems und damit hoher Investitionsbedarf erkannt werden und die Kaufentscheidung beeinflussen. Auch die bestehende Sicherheitsarchitektur steht im Fokus, da beispielsweise sicherheitsrelevante Lücken, wie ein Verstoß gegen die Datenschutzbestimmungen eine Wertminderung darstellt und ebenfalls Mitteleinsatz erfordert.
IT-Zufriedenheit der Geschäftseinheiten
Die Zufriedenheit der internen Kund*innen der IT (Benutzer*innen) kann zuverlässige Aussagen über die Performance des Bereichs liefern.
IT Audit im Rahmen der Wirtschaftsprüfung
Die Anlassfälle sind sehr verschieden und können dazu führen, Teilbereiche von Prozessen nach Aufstellung von entsprechenden Prüfungszielen zu auditieren. Anhand eines Prüfprogrammes kann man dann strukturiert Einzelthemen mit verschiedenen Prüfungsmethoden betrachten. Diese können sein: Befragung, Beobachtung, nochmalige Durchführung, Durchsicht und Beurteilung anhand von Stichproben, kontrollorientierte Prüfung, Walkthrough, technische Prüfscripts bei Einsatz von IT-Systemen oder ähnliches. Für die Entwicklung eines Prüfprogrammes ist naturgemäß die Definition eines unabhängigen Sollzustandes erforderlich, wofür ein Framework herangezogen werden kann.
Die Prüfungserkenntnisse können nach Abschluss der Prüfung strukturiert erfasst und zum Beispiel nach resultierendem Risiko kategorisiert und dargestellt werden. Allerdings ist ein Audit keine klassische Messmethode, da die gewonnenen Erkenntnisse nicht wirklich zueinander in Beziehung gesetzt und quantifiziert werden. Dennoch ist es eine valide und bei Setzen von substanziellen Prüfungshandlungen sogar eine sehr aussagekräftige Methode für eine Prozess-Bestandsaufnahme respektive für eine Verifikation von gesetzten Prozessmanagement-Maßnahmen – allerdings eine im Hinblick auf den Aspekt Messung – unstrukturierte Art, da eine objektivierte Skala für die Einteilung fehlt. Weiters ist die Risikoeinschätzung sehr personen- und erfahrungsabhängig.
Vorgaben, was man zum Beispiel bei einer IT-Prüfung auditieren muss, finden sich in länderspezifischen Regelungen wie in Österreich z.B. die Fachgutachten KFS/DV1 „Die Ordnungsmäßigkeit von EDV-Buchführungen“ aus 1998 und KFS/DV2 „Abschlussprüfung bei Einsatz von Informationstechnik“ aus 2004 des Fachsenates für Datenverarbeitung des Instituts für Betriebswirtschaft, Steuerrecht und Organisation der Kammer der Wirtschaftstreuhänder*innen [KW11]. Daraus haben sich natürlich bei den Wirtschaftsprüfungsgesellschaften unternehmenseigene Vorgaben entwickelt. In Deutschland existieren ähnliche Vorgaben als Regelungen des Instituts der Wirtschaftsprüfer*innen (IDW) Stellungnahmen zur Rechnungslegung (RS), Fachgutachten zur Prüfung der IT (FAIT) 1, 2 und 3 [IDW09].
Assurance Audits bei IT-Dienstleistern
Bei der Wirtschaftsprüfung geht es darum, die Ordnungsmäßigkeit der Finanzberichtserstattung zu überprüfen und extern zu bestätigen. Im Falle einer IT-gestützten Buchhaltung ist es dabei erforderlich, auch deren Ordnungsmäßigkeit zu überprüfen. Wenn das geprüfte Unternehmen nun beispielsweise den IT-Betrieb der Buchhaltungssysteme an einen IT-Dienstleister auslagert, dann ist es auch erforderlich, die Ordnungsmäßigkeit dieses IT-Betriebs zu überprüfen. IT-Dienstleister, die Buchhaltungssysteme für mehrere Kund*innen betreiben, könnten auf diese Art von unterschiedlichen Wirtschaftsprüfer*innen ihrer Kund*innen zu unterschiedlichen Zeitpunkten überprüft werden. Um den dadurch entstehenden hohen Aufwänden vorzubeugen, gibt es für Dienstleister ganz allgemein (also nicht nur für IT-Dienstleister) die Möglichkeit, durch eine*n Wirtschaftsprüfer*in ein Assurance Audit durchführen zu lassen und sich von diesem die Ordnungsmäßigkeit der erbrachten Dienstleistungen (z.B. IT-Betrieb, aber auch Software-Entwicklung, -Test etc.) für alle Kund*innen extern bestätigen zu lassen. Die Prüfungen durch die Wirtschaftsprüfer*innen der einzelnen Kund*innen können dann entfallen, wenn (1) die Buchhaltungssysteme des*der jeweiligen Kund*in im Umfang des Assurance Audits enthalten waren und (2) das Ergebnis des Assurance Audits war, dass die Ordnungsmäßigkeit gegeben ist. Die für ein derartige Assurance Audits maßgeblichen Standards sind:
- SSAE 16 (USA) [SSA11]
- ISAE 3402 (international) [ISA11]
- IWP/PE 14 (Österreich) [PE12]
Die drei genannten Standards sind – abgesehen von den unterschiedlichen Geltungsbereichen – im Wesentlichen inhaltsgleich; sie unterscheiden sich vielmehr rein auf deren regionales Anwendungsgebiet.
Sonderprüfungen
Diese dienen dazu, die Ordnungsmäßigkeit einzelner Prozesse, Systeme oder Produkte zu überprüfen und extern zu bestätigen. Auditkriterien können dabei Gesetze, Regulative, Normen, Branchenstandards oder Organisations-interne Standards sein.
Prüfungsmethoden
Bei jedem Audit müssen zunächst der Auditgegenstand (das zu überprüfende Objekt wie z.B. eine Organisationseinheit, ein System oder ein Prozess) und die Auditkriterien (z.B. Gesetze, Regulative, Normen, Branchenstandards oder Organisations-interne Standards) festgelegt werden (ITAF 1201) [ITA14].
Risikoansatz
Nach Festlegung des Auditgegenstands und der Auditkriterien muss der*die Auditor*in beurteilen, in welchen Teilbereichen des Auditgegenstands das höchste Risiko besteht, dass die Auditkriterien nicht erfüllt werden, und das Ergebnis dieser Risikoeinschätzung bei seiner*ihrer Auditplanung dahingehend berücksichtigen, dass er *sie den Schwerpunkt seiner*ihrer Prüfungshandlungen in jenen Bereichen setzt, wo er*sie das höchste Risiko ermittelt hat (ITAF 1202) [ITA14].
Prüfungshandlungen
Dem*der Auditor*in stehen unterschiedliche Arten von Prüfungshandlungen zur Auswahl (ITAF 1203) [ITA14]:
- Befragung: der*die Auditor*in befragt Mitarbeiter*innen über die von ihnen durchgeführten Aktivitäten, die von ihnen betreuten Systeme etc.; in der Praxis wird bei jedem Audit eine Befragung durchgeführt, da der*die Auditor*in zumeist auf die Auskunft sachkundiger Mitarbeiter*innen angewiesen ist, um den Auditgegenstand korrekt beurteilen zu können
- Beobachtung: der*die Auditor*in beobachtet Mitarbeiter*innen bei den von ihnen durchgeführten Aktivitäten, ohne ihnen dabei Fragen zu stellen; da die reine Beobachtung für die betroffenen Mitarbeiter*innen in der Regel eine unangenehme Situation darstellt, wird die reine Beobachtung in der Praxis nur selten durchgeführt
- Wiederdurchführung: der*die Auditor*in wiederholt die Aktivitäten eines*einer Mitarbeiter*in oder eines Systems unter strenger Einhaltung aller Vorschriften und vergleicht, ob er*sie zu demselben Arbeitsergebnis gekommen ist wie der*die Mitarbeiter*in oder das System; da die Wiederdurchführung in der Regel eine sehr aufwändige Prüfungshandlung darstellt, wird sie insbesondere in Bereichen mit besonders hohem Risiko angewendet
- Einsichtnahme: der*die Auditor*in nimmt Einsicht in Aufzeichnungen über Aktivitäten von Mitarbeiter*innen oder in Systeme vor; in der Praxis wird bei jedem Audit parallel zur Befragung auch eine Einsichtnahme durchgeführt
Generell ist zu sagen, dass zu jeder geprüften Stichprobe zwei unterschiedliche Prüfungshandlungen (z.B. Befragung und Einsichtnahme, aber nicht Befragung und Befragung) durchgeführt werden sollten.
Stichproben
Bei der Entnahme von Stichproben muss der*die Auditor*in zunächst die Grundgesamtheit korrekt identifizieren und danach eine ausreichend große und gleichmäßig verteilte Stichprobe entnehmen; bei der gleichmäßigen Verteilung sollte der*die Auditor*in die Kriterien Zeitpunkt, betroffene Personen und/oder Organisationseinheiten, betroffene Systeme, Arten von Geschäftsfällen etc. berücksichtigen. Manche Prüfungsstandards machen ganz konkrete Vorschriften bezüglich der Entnahme von Stichproben (ITAF 1203) [ITA14].
IT Security Audit
IT Security Audits können grundsätzlich manuell oder unter Einsatz von Software Tools durchgeführt werden.
Tools
Software Tools können einerseits auf den auditierten Systemen selbst eingesetzt werden; in diesem Fall ist darauf zu achten, dass die auditierten Systeme durch die Audit Tools nicht verändert und auch in ihrer normalen betrieblichen Funktion nicht beeinträchtigt werden.
Alternativ können Daten aus den auditierten Systemen exportiert und in anderen Systemen mit Software Tools analysiert werden.
Weiters können Software Tools eingesetzt werden, um Verbindungen zu den auditierten Systemen aufzubauen und/oder den Aufbau von Verbindungen zu den untersuchten Systemen lediglich versuchen – beides mit dem Ziel, das Verhalten der auditierten Systeme zu beobachten.
Anbieter*innen
Software Tools können einerseits von den Hersteller*innen von Betriebssystemen, Datenbanken und Anwendungen selbst zur Verfügung gestellt werden, teilweise als Open Source verfügbar sein (z.B. Aircrack-ng, John the Ripper, Nessus, Nmap, Ophcrack, Wireshark) oder von auf die Herstellung von auf Audit Software spezialisierten Unternehmen bezogen werden (z.B. ACL, IDEA).
Wiederholungsaufgaben
- In welcher Situation ist für Sie als Unternehmen eine SAS 70-/ISA 402-/ ISAE3402-Prüfung interessant?
Lösungen
In welcher Situation ist für Sie als Unternehmen eine SAS 70-/ISA 402-/ ISAE3402-Prüfung interessant?
Wenn Sie ein (IT-) Dienstleister sind, dessenKund*innen Teile von Prozessen und Kontrollen an Sie ausgelagert haben und diese Kund*in die Effektivität des internen Kontrollsystems formal und regelmäßig nachweisen muss (z.B. aufgrund SOX oder „Euro-SOX“) und das auch die an Sie ausgelagerten Themen betrifft, ist für Sie so eine Prüfung interessant. Auch ist eine SAS 70 Prüfung sinnvoll, wenn Sie einer Institution oder Aufsichtsbehörde das Funktionieren des IKS bescheinigen müssen. Einerseits müssen Sie nicht jedem*jeder Kund*in dies einzeln nachweisen und haben nur einmal innerhalb einer festgelegten Zeitperiode Prüfer*innen zu betreuen (Aufwand!). Dabei ist der Inhalt eines SAS 70-Berichtes nicht auf die IT beschränkt.
Herausforderungen in der Praxis
Ziele der Lektion
- Erkennen der Bedeutung des kontinuierlichen Verbesserungsprozesses
- Diskussion über mögliche Problemstellungen im Zusammenhang mit IT-Governance
Es gibt mannigfaltige Stolpersteine bei versuchten Optimierungsmaßnahmen der IT-Governance. In vielen Fällen fehlt ein strukturell gut durchdachter Top-Down-Ansatz, der aus Zeit- und Kostengründen mitunter nicht verfolgt wird. Ganz wichtig bei solchen Verbesserungsmaßnahmen ist das Schaffen von Quick Wins, um die für die Mitarbeiter*innen in der Regel schwer greifbare IT-Governance positiv erlebbar zu machen und um Zeit zu gewinnen, echte strukturelle Anpassungen vornehmen zu können. Ein wesentlicher Schlüsselfaktor sind die Stimmungen und die Gruppendynamik, die während einer Umstellungsphase – sei es eine geschäftsprozess-, IT-Prozess oder tool-bezogene Maßnahme. Generell müssen bei der Einführung von IT-Governance die vier Dimensionen Processes (Prozesse), People (Mitarbeiter*innen), Products (Anwendungen, IT-Tools) und Partners (Lieferant*innen) betrachtet werden.
In jeder dieser vier Dimensionen lauert das Potential für Konflikte und Schwierigkeiten bei der Einführung von IT-Governance.
People
Die Einführung eines IT-Tools für spezielle Aufgaben löst bei den Mitarbeiter*innen sehr oft Unbehagen aus. Oft kommen auch neue Konzepte durch das neue IT Tool zur Anwendung, die eine große Umstellung der Arbeit nach sich ziehen.
Typischerweise steigt die Arbeitszufriedenheit mit einem neu einzuführenden Tool kurzfristig an – je mehr Erwartungen in das neue Tool zur Lösung aktueller Probleme gesetzt werden, desto mehr – dann holt die Realität die Erwartungen ein und drückt die Arbeitszufriedenheit in den negativen Bereich. Erste Kinderkrankheiten technischer Natur, erste Sonderfälle bei der Abbildung der Geschäftsfälle, aber auch vermehrte Kritik des User Handlings machen sich bemerkbar. Ist das Tool oder die Software-Entwicklung hier zusätzlich noch mit Fehlern behaftet – im schlimmsten Fall werden Zielsetzungen nicht erreicht – kann sich die Arbeitszufriedenheitskurve nur schwer erholen. Im Normalfall wird diese aber mit der Zeit positiv und pendelt sich auf einem höheren Niveau als zu Zeiten des Vorgängertools ein. Man kann sagen, dass sich diese Entwicklung nach Einführung eines neuen IT-Tools prinzipiell so gestaltet – je wichtiger das Tool für den Geschäftsprozess ist, desto heftiger fallen die Höhen und Tiefen aus. Die Zahlenangaben in obiger Grafik haben nur die Bedeutung, die Zufriedenheit (positiver Zahlenbereich) und Unzufriedenheit (negativer Zahlenbereich) zu repräsentieren, die Phasenbezeichnungen sind frei gewählt.
Bei IT-Governance-Projekten kommt den beteiligten Akteur*innen entscheidende Bedeutung zu. Erfahrungsgemäß schwingt bei vielen Projekten, wo es darum geht, Vorgaben, Maßnahmen, Aktivitäten, Kontrollen in die Organisation zu bringen und zudem viele Personen zu involvieren sind, die Gefahr des Scheiterns mit. Nicht zuletzt aufgrund der erzeugten Dynamik in der Stimmungslage kommt bei solchen Projekten die Management Awareness und dem Projektmarketing eine wichtige Rolle zu. Nachdem das Top Management symbolisch wichtige Zeichen setzt, indem der Chief Execution Officer (CEO) das Projekt auf Veranstaltungen erwähnt, auf seine berichtspflichtigen Mitarbeiter*innen einwirkt und ausdrückt, dass ihm das Thema wichtig ist, kann das Projektmarketing durch gezielte Information die breite Masse des Unternehmens informieren. Darauf aufbauend muss die Projektleitung eine „Koalition der Willigen“ suchen, wodurch dessen*deren unmittelbare Kolleg*innen positiv mit den IT-Governance-Projekten in Berührung kommen. Die Gegner*innen und Unkenrufer*innen wird es in einer Organisation immer geben, jedoch erzeugt man mit der Zeit eine gewisse Gruppendynamik und eine positive Stimmung, derer diese sich nicht erwehren werden können. Wenn die Gegner*innen in der Unterzahl sind, kippt die allgemeine Atmosphäre gegen sie und die allgemein positiven Maßnahmen werden auch so erlebt und die Verbesserungen können dabei lukriert werden. Im Gegensatz dazu können fachlich als eindeutig notwendig erachtete und gute IT-Governance-Projekte scheitern, wenn Unkenrufer*innen und Gegner*innen einerseits in einer schwer vermeidbaren organisatorischen Position sind oder wenn diese es schaffen, das gesamte Projekt atmosphärisch bei den Kolleg*innen zu diskreditieren.
Processes
Als erster Ansatzpunkt für eine kritische Würdigung fungiert der Geschäftsprozess. Wenn dieser bereits vor Varianten und Ausnahmen strotzt, deren Aktivitäten noch durch mehrere Akteur*innen oder Rollen durchgeführt und verschiedene Medien – also IT-Tools – angewendet werden, dann leidet die Transparenz. Weder ist eine effiziente Überwachung der Geschäftsfälle noch ein durchgängiges Reporting in so einem Fall möglich. In den meisten Fällen ist so ein Prozess nicht wirklich reproduzierbar und durch die Abhängigkeit von einzelnen wissenden Key-Player*innen für ein Unternehmen auch recht gefährlich. Hohe Durchlaufzeiten sind dabei garantiert. Symptomatisch ist dabei auch, dass Informationen nicht wirklich geordnet erfasst, verändert und strukturiert abgelegt werden. Alles passiert ad hoc, mitunter werden dieselben Kontrolltätigkeiten durch verschiedene Personen unterschiedlich in verschiedenen Phasen des Prozesses durchgeführt. In so einem Fall ist dringender Handlungsbedarf für ein Business Process Reengineering gegeben. Der Boden ist in so einer Situation gut aufbereitet, denn schon jede kleine Maßnahme, die eine reale Verbesserung für die beteiligten Akteur*innen bringt, wird mit hoher Wahrscheinlichkeit positiv aufgenommen. Vorweg stellt sich hier das Problem, wo man beginnt.
Ein Geschäftsprozess muss klar definiert und eindeutig an den strategischen Zielen ausgerichtet sein, wobei vor allem der Kundenbedarf – oder allgemeiner formuliert: der Bedarf der Stakeholder – berücksichtigt werden muss. Die Verantwortlichkeiten für die Durchführung der einzelnen Prozessschritte sollen genau festgelegt werden. Die Anzahl der involvierten Rollen und Akteur*innen soll so groß wie nötig und so klein wie möglich sein, insbesondere bei einem einzelnen Prozessschritt. Dabei kann ein*e Akteur*in auch mehrere Rollen bekleiden. Ganz wesentlich ist es zudem, den Informationsbedarf pro Prozessschritt zu ermitteln, diese zentral zusammenzuführen und verwertbar zu machen. Die Weitergabe der Information soll dabei tunlichst optimiert werden. Dabei setzt IT-Governance nicht nur bei dem zuletzt erwähnten Informationsbedarf an, wo dies ja offensichtlich erscheint, sondern bei allen zuvor erwähnten Aspekten. IT kann bei jeder Einflussgröße in den Geschäftsprozess eingreifen, aber auch im schlimmsten Fall ein Hemmschuh sein, also dann, wenn durch den Einsatz der IT die Abarbeitung der Geschäftsfälle erschwert und dadurch die Durchlaufzeit oder der Aufwandseinsatz erhöht wird.
Products
Eine große Gefahr einer grundsätzlichen Themenverfehlung geht dann aus, wenn IT-Prozesse ausschließlich um die bereits vorhandenen IT-Tools entworfen und implementiert werden. Da in so einem Anwendungsfall nicht mehr das ursprünglich formulierte strategische Ziel angepeilt wird, beschränkt man sich hier auf die bereits bestehende IT-Unterstützung und nimmt diese als unverrückbar an. Allerdings kann bei einer nicht effizienten IT-Unterstützung der Geschäftsprozesse kein Erfolg durch Business Process Reengineering erzielt werden, weil die Mankos der fehlenden IT-Unterstützung des Geschäftsprozesses ja bestehen bleiben. Es ist daher essentiell, sich bei der Geschäftsprozessmodellierung unbedingt auf die strategischen Ziele des Prozesses zu konzentrieren und die Aktivitäten technologie-unabhängig zu formulieren. Erst in einem zweiten Schritt sollte man die Effektivität und Effizienz der aktuell angewendeten IT-Unterstützung hinterfragen.
Die Information und deren Wandlung innerhalb des Geschäftsprozesses ist ein kritischer Erfolgsfaktor. Es ist wichtig zu hinterfragen, wann welche Information von wem in welcher Form benötigt wird. Die eingesetzten IT-Tools sollten diese Fragestellungen soweit wie möglich unterstützen. In einem Szenario, wo unkoordiniert Informationen erzeugt, verändert, an verschiedenen Orten oder – technisch gesehen – Datenbanken abgelegt werden, stellt die Informationsweitergabe den*die Prozess-Manager*in vor große Probleme. Es entstehen meist auch verschiedene Datenbasen, die sich ziemlich sicher auseinander entwickeln. Im Falle von Kundenstämmen kann das zum Beispiel fatal sein.
Ein anderes mögliches Phänomen ist, dass theoretische Konzepte mit einer bestimmten Zielsetzung für den internen Bedarf und für ein anderes Ziel abgewandelt und dadurch das eigentlich ursprüngliche Konzept desavouiert oder zumindest negativ beeinflusst werden. Dies ist zum Beispiel der Fall, wenn Standardapplikationen angeschafft, diese aber so intensiv für eigene Zwecke adaptiert werden, sodass die ursprüngliche Zielsetzung nicht erreicht wird. Salopp formuliert bedeutet das, dass ein IT Tool falsch eingesetzt wird oder es „ver-customized“ wird. Das kann zwar mitunter funktionieren, allerdings nur bei immensem Entwicklungs- und Adaptierungsaufwand. Schon allein die Tatsache, dass das theoretische Konzept abgewandelt wird, legt nahe, dass an den Grundfesten manipuliert wird und gute Chancen bestehen, sich große Probleme in Entwicklung und Betrieb einzuhandeln. Beispielsweise laufen individuell entwickelte Applikationen immer Gefahr, nicht mehr upgrade-fähig zu sein. Bei einer IT-Investition in ein Tool sollte daher immer die ursprüngliche Zielsetzung kritisch hinterfragt werden, um sicherzustellen, dass die theoretischen Konzepte auch zur jeweiligen Unternehmenssituation passen.
Es kann auch eine Situation entstehen, wo einem an sich funktionierenden Tool ständig geringe Adaptierungen und vermeintlich kleine Verbesserungen widerfahren. Dadurch kann es passieren, dass ständig „Pflasterlösungen“ für kurzfristige Anforderungen entwickelt werden, die aber in Summe zu kurz greifen, um die IT-Governance konzeptuell zu verbessern. Auch hier ist es ratsam, das dahinter stehende Konzept kritisch zu hinterfragen und Lösungen zu suchen, die generisch formuliert und möglichst flexibel anwendbar sind. Anders ausgedrückt gibt es Lösungen für konkrete Problemstellungen, die – falls zu konkret formuliert – nicht ausreichend allgemein das Problem lösen und somit für andere Spezialfälle wiederum nicht anwendbar sind. Für diese Spezialfälle müssen dann ebenso Lösungen entwickelt werden usw. Allerdings wurden eventuell schon zwei Lösungswege für ein- und dasselbe Problem formuliert und implementiert. Die Chance ist groß, dass es noch eine dritte Gruppe von Spezialfällen gibt. Ohne das grundsätzliche Problem ausreichend generisch zu formulieren, wird sich das Problem dadurch nicht nachhaltig lösen lassen. Zusätzlich erfordert die Toolimplementierung eine Auseinandersetzung mit den grundlegenden Konzepten, andernfalls wird ein Problem individuell gelöst, obwohl bereits eine anders angewendete Lösung für ein ähnliches Problem existiert.
Die klassische Aussage „A fool with a tool is still a fool“ unterstreicht plakativ den Fakt, dass ein oft angepriesenes IT Tool für eine Aufgabenstellung organisatorischen Charakters in den meisten Fällen wenig bis gar keine positiven Effekte hat. Mitunter wird vor dem eigentlichen Problem kapituliert und mit Statements á la „Mit dem Tool können wir das dann sehr leicht elektronisch abbilden“ die Erwartungshaltung nach oben geschraubt. Wenn das Problem selbst gar nicht bei der IT-Unterstützung liegt, kann eine Adaptierung der IT-Unterstützung des Geschäftsprozesses hier gar keine Linderung bieten. Ähnliches gilt für das Upgrade von bestehenden Applikationen oder Systemen auf eine neue Version mit neuen Funktionen und Möglichkeiten. Hart formuliert: Auch Papier und Bleistift ist ein Tool und in vielen Fällen kein schlechtes. Der Prozess dahinter bildet für das Tool das Fundament, und dieser muss durchdacht und konsistent genug für den nachfolgenden Aufbau sein.
Partners
Bei Projekten, bei denen eine Optimierung der internen Abläufe einer IT verfolgt wird, müssen auch Lieferantenbeziehungen berücksichtigt werden. Wird beispielsweise Software von einem Lieferanten bezogen, so muss im Sinne eines geordneten Change Managements großes Augenmerk auf Schnittstellen zwischen den internen Abläufen und den Prozessen des Lieferanten gelegt werden. Oftmals wird den Lieferanten zu viel Spielraum gelassen um eine vermeintliche Flexibilität zu erhalten. Die Angst, mit einem zu großen Bürokratismus nicht rasch genug auf Änderungswünsche reagieren zu können, verleitet Projekt- oder sogar IT-Leiter dazu, Fremdfirmen einen zu großen Einfluss auf das interne Änderungswesen nehmen zu lassen. Unternehmensfremden Softwareentwicklern wird dabei beispielsweise erlaubt, Änderungen der Software direkt, ohne Tests auf produktiven Anwendungsservern, durchzuführen. Die Wahrscheinlichkeit ist sehr hoch, dass es dabei zu Fehlern und damit massiven Auswirkungen auf den Betrieb der Anwendung kommt. Als Folge kann es sogar zu einem kompletten Stillstand eines Geschäftsprozesses und damit finanziellen Verlusten des Unternehmens kommen. Als anderes Beispiel kann angeführt werden, dass bei der Umsetzung von Änderungswünschen die konzeptuelle Verantwortung oft an die Entwicklungsfirma „abgetreten“ wird. Bei der konzeptuellen Verantwortung kommt es darauf an, die technische Umsetzung der fachlichen Anforderungen zu überwachen und in Hinblick auf spätere Erweiterbarkeit zu steuern. Wenn die Kontrolle der konzeptuellen Umsetzung fehlt, kann eine künftige Erweiterung oder der Umstieg auf eine neue Technologie stark beeinträchtigt oder im schlimmsten Fall unmöglich gemacht werden. Bei der Auswahl neuer Partner sollte immer darauf geachtet werden, ob die Lieferantenfirmen selbst IT Service Management etabliert haben. Das Einfordern einer Dokumentation des Change Management Prozesses und seiner Schnittstellen des Lieferanten sollte einer der ersten Schritte bei der Auswahl eines neuen Partners sein. Aufschluss darüber, ob eine Partnerfirma strukturiert arbeitet, liefert auch die Art und Weise, wie Projekte geplant, dokumentiert und abgewickelt werden.
Die Prozessreife der Partnerfirmen kann direkten Einfluss auf den Erfolg der Einführung von IT-Governance in einem Unternehmen haben. Noch so gut gestaltete IT Service Management Prozesse des eigenen Unternehmens werden ineffektiv und können kostenintensiv werden, wenn die Schnittstellen zu den Prozessen der Partnerunternehmen nicht richtig definiert oder nicht bekannt sind.
Wiederholungsaufgaben
- Nennen und beschreiben Sie kurz die vier Dimensionen, die bei der Einführung von IT-Governance beachtet werden müssen.
- Welche Anforderungen werden an die Definition und Ermittlung eines Geschäftsprozesses gestellt?
- Welche Gefahren für einen Geschäftsprozess können bei der Unterstützung durch IT-Tools auftreten?
- Was ist für den Erfolg von IT-Governance-Projekten in Hinblick auf beteiligte Personen und Akteur*innen zu beachten?
- Welche Rolle spielen Lieferantenfirmen bei IT-Governance-Projekten und was ist bei der Prozessgestaltung in Hinblick auf Partnerfirmen zu beachten?
Lösungen
Nennen und beschreiben Sie kurz die vier Dimensionen, die bei der Einführung von IT Business Alignment beachtet werden müssen.
Processes, Products, People, Partners
In der Dimension „Processes“ werden Geschäftsprozesse, deren Ermittlung und Definition behandelt. Die zweite Dimension „Products“ behandelt Softwarewerkzeuge (IT-Tools) zur Unterstützung der Geschäftsprozesse. In der Dimension „People“ werden die betroffenen Mitarbeiter*innen betrachtet. Die Dimension „Partners“ zielt auf Lieferant*innen und andere Partnerunternehmen ab.
Welche Anforderungen werden an die Definition und Ermittlung eines Geschäftsprozesses gestellt?
Ein Geschäftsprozess muss klar definiert und eindeutig an den strategischen Zielen ausgerichtet sein, wobei vor allem der Bedarf der Stakeholder berücksichtigt werden muss. Die Verantwortlichkeiten für die Durchführung der einzelnen Prozessschritte sollen genau festgelegt werden, wobei die Anzahl der involvierten Rollen und Akteur*innen so groß wie nötig und so klein wie möglich sein sollte. Ganz wesentlich ist es zudem, den Informationsbedarf pro Prozessschritt zu ermitteln, diese zentral zusammenzuführen und verwertbar zu machen.
Welche Gefahren für einen Geschäftsprozess können bei der Unterstützung durch IT-Tools auftreten?
Generell sollte der Ansatz verfolgt werden, das IT-Tool an den zu unterstützenden Prozess anzupassen und nicht umgekehrt. Das gilt vor allem bei standardisierter Software „von der Stange“. Werden Geschäftsprozesse „verbogen“, um ein bestimmtes Tool verwenden zu können, können diese Prozesse ineffizient und kostenintensiv werden. Darüber hinaus kann die Anpassung des Prozesses an das Softwarewerkzeug in eine Inflexibilität gegenüber Kundenbedürfnissen resultieren.
Was ist für den Erfolg von IT-Governance-Projekten in Hinblick auf beteiligte Personen und Akteur*innen zu beachten?
Bei vielen Projekten, die eine Änderung der Organisation bewirken, kommt der Akzeptanz der beteiligten Akteure für die durchzuführenden Maßnahmen eine große Bedeutung zu. Aufgrund der erzeugten Dynamik in der Stimmungslage kommen bei solchen Projekten der Management Awareness und dem Projektmarketing eine wichtige Rolle zu. Das Top Management sollte symbolisch wichtige Zeichen setzen, beispielsweise indem das Projekt durch den CEO auf Veranstaltungen erwähnt wird und ausgedrückt wird, dass das Thema von entsprechender Wichtigkeit ist. Darauf aufbauend muss die Projektleitung eine „Koalition der Willigen“ suchen, wodurch deren unmittelbare Kolleg*innen positiv mit den IT-Business-Alignment-Projekten in Berührung kommen. Gegner*innen und Unkenrufer*innen können aufgrund der entstehenden Gruppendynamik und positiven Grundstimmung zu einer konstruktiven Mitarbeit im Projekt bewegt werden. Es ist wichtig, alle nötigen Wissensträger*innen von Beginn an in das Projekt einzubinden und konstruktive Kritik zuzulassen, um zu vermeiden, dass nicht beachtete Akteur*innen das gesamte Projekt atmosphärisch bei den Kolleg*innen diskreditieren.
Welche Rolle spielen Lieferantenfirmen bei IT-Governance-Projekten und was ist bei der Prozessgestaltung in Hinblick auf Partnerfirmen zu beachten?
Die Schnittstellen zwischen unternehmensinternen Abläufen und den Prozessen des Lieferanten- oder Partnerfirmen stellen einen Erfolgsfaktor für IT-Governance-Projekten dar.
Noch so gut gestaltete IT-Service-Management-Prozesse des eigenen Unternehmens werden ineffektiv und können kostenintensiv werden, wenn die Schnittstellen zu den Prozessen der Partnerunternehmen nicht richtig definiert oder nicht bekannt sind. Bei der Auswahl neuer Partner*innen sollte daher immer darauf geachtet werden, ob die Lieferantenfirmen selbst IT Service Management etabliert haben. Das Einfordern einer Dokumentation des Change Management Prozesses und seiner Schnittstellen des*der Lieferant*in sollte einer der ersten Schritte bei der Auswahl eines*einer neuen Partner*in sein. Aufschluss darüber, ob eine Partnerfirma strukturiert arbeitet, liefert auch die Art und Weise, wie Projekte geplant, dokumentiert und abgewickelt werden.
Literaturverzeichnis
[BGJ09] Markus Böhm, Matthias Goeken, Wolfgang Johannsen, Compliance und Alignment: Vorgabenkonformität und Strategieabgleich als Erfolgsfaktoren für eine wettbewerbsfähige IT, in HMD Praxis der Wirtschaftsinformatik Heft 269 10/2009, dpunkt.verlag
[CAM94] Robert C. Camp, Benchmarking, Hanser, 1994
[COB12] COBIT 5 – Rahmenwerk für Governance und Management der Unternehmens-IT, ISACA, www.isaca.org, 2012
[EBR03] Erik Brynjolfsson, The IT Productivity GAP, in Optimize magazine Issue 21 07/2003
[ETI05] Ernst Tiemeyer, IT Servicemanagement kompakt, 2005, Spektrum Akademischer Verlag
[FRG07] Martin Fröhlich, Kurt Glasner (Hrsg.): IT-Governance, Leitfaden für eine praxisgerechte Implementierung, Gabler, Wiesbaden 2007.
[ISD07] Office of Government Commerce OCG, ITIL Service Design, The Stationery Office (TSO), 2007
[ISI07] Office of Government Commerce OCG, ITIL Continual Service Improvement, The Stationery Office (TSO), 2007
[ISO08] ISO/IEC 38500 – Corporate governance of information technology, ISO/IEC, www.iso.org, www.iec.org, 2008
[ISS07] Office of Government Commerce OCG, ITIL Service Strategy, The Stationery Office (TSO), 2007
[ITA14] ITAF – A Professional Practices Framework for IS Audit/ Assurance, 3rd Edition, ISACA, www.isaca.org, 2014
[NIS11] NIST SP 800-145 – The NIST Definition of Cloud Computing, NIST, www.nist.gov, 2011
[NIT08] Janin Nitsche, IT Service Management gemäß ITIL V3 – Foundation Level, herausgegeben von der COC AG, Herdt-Verlag für Bildungsmedien, 21.4.2008
[PUTZ11] Raimund Putzinger: IT für Manager, Was Sie über wirksames IT-Management wissen müssen, facultas Wien, 2011
[RBK08] Simone Rudolph, Tilo Böhmann, Helmut Krcmar, Struktur von IT-Servicekatalogen: Ein praxisorientierter Gestaltungsvorschlag für die Dokumentation des IT Leistungsangebots, Technische Universität München, Multikonferenz Wirtschaftsinformatik, MKWI 2008, München, 26.2.2008 - 28.2.2008, Proceedings 2008
[SCS08] Hermann J. Schmelzer, Wolfgang Sesselmann, Geschäftsprozessmanagement in der Praxis, Kunden zufrieden stellen, Produktivität steigern, Wert erhöhen, Carl Hanser Verlag, 2008
[STR05] Outsourcing, Susanne Strahringer (Hrsg.): Praxis der Wirtschaftsinformatik, HMD Heft 245, dpunkt.verlag, Oktober 2005 – hier Auszug aus dem Beitrag: Lars Schwarze, Peter P. Müller: IT-Outsourcing – Erfahrung, Status und zukünftige Herausforderungen (Seite 6-17)
[TIE05] IT-Controlling kompakt, Ernst Tiemeyer, 1.Auflage 2005, Spektrum Akademischer Verlag
[TIE09] Handbuch IT-Management Konzepte, Methoden, Lösungen und Arbeitshilfen für die Praxis, Ernst Tiemeyer (Hrsg.), 3.Auflage 2009, Carl Hanser Verlag
[TSD06] Office of Government Commerce OCG, ITIL Service Delivery, The Stationery Office (TSO), 2006
[WAL06] René Walther, Service Level Agreements, Ein methodischer Baustein im Dienstleistungscontrolling, Verlag Dr. Müller VDM, 2006
Internetquellen
[CMM09] http://www.sei.cmu.edu/cmmi/
[COB07] http://www.isaca.org/template.cfm?Section=COBIT6
[HOC10] http://www.adhoc-beratung.ch/PDF_Files/Benchmarking.pdf
[IDW09] http://www.idw.de/idw/portal/d302224/index.jsp
[ISA11] http://www.ifac.org/sites/default/files/downloads/b014-2010-iaasb-handbook-isae-3402.pdf
[KW11] Kammer der Wirtschaftstreuhänder, Ordnungsmäßigkeit von IT-Buchführungen, 23.3.2011, Abruf am 04.04.2014
http://www.kwt.or.at/de/PortalData/2/Resources/downloads/downloadcenter/52-KFS-DV1.pdf[KWT09] http://www.kwt.or.at/desktopdefault.aspx/tabid-85/
[PE12] http://www.kwt.or.at/en/PortalData/2/Resources/downloads/downloadcenter/GS-PE14.pdf
[SSA11] http://www.aicpa.org/Research/Standards/AuditAttest/DownloadableDocuments/AT-00801.pdf
Literatur zum vertiefenden Verständnis
[AIR08] Martin Latzenhofer, Internes Kontrollsystem in der IT - Anforderungen, Standards, Gestaltung, Praxisaspekte, Seminarunterlage für die Akademie Interne Revision/ISACA Austrian Chapter, Akademie Interne Revision, 2009
[BIE04] Ganzheitliches Informationsmanagement 1. Band Grundlagen, Jörg Biethahn,et.al., 6. Auflage 2004, Oldenbourg Verlag
[BOC09] BOC Management Office White Paper: IT-Strategie: Lösungsansätze im Spannungsfeld zwischen Kostendruck und Anforderungen des Business - Nachhaltiges Architekturmanagement mit ADOit, BOC Gruppe 2009
[BPM09] Guide to the Business Process Management Common Body of Knowledge (BPM CBOK®, Version 2.0, Association of Business Process Management Professionals (ABPMP), 2009
[CIS10] Information Systems Audit and Control Association (ISACA), Certified Information Security Manager (CISM), Review Manual 2010, 2010
[COB07] IT Governance Institute, CobiT 4.1 – Framework, Control Objectives, Management Guidelines, Maturity Models, IT Governance Institute, 2007
[CSI01] Computer Security Institute 2001, in Information Security Management Handbook, Seite 346, http://www.gocsi.com
[DIR10] Herbert Dirnberger, Tabellarische Zusammenfassung der in der Lehrveranstaltung IT Business Alignment im Sommersemester 2010 vorgestellten Frameworks, 19.4.2010
[GAD06] Masterkurs IT-Controlling, Andreas Gadatsch, Elmar Mayer, 3. Auflage 2006, Friedr. Vieweg & Sohn Verlag
[HES14] Jimmy Heschl, COBIT 5 – Ein Überblick, Vortragsfolien im Rahmen der Audit Competence 2014, Wien
[ISM03] Harold F. Tipton, Micki Krause: Information Security Management Handbook, Volume 4,Auerbach Publications, 2003
[ISM14] Dieter Burgartz / Ralf Röhring (Hrsg.): Information Security Management, Praxishandbuch für Aufbau, Zertifizierung und Betrieb, Loseblattsammlung, TÜV Verlag, Köln, 41. Akt. Lieferung, 2014.
[ISO07] Office of Government Commerce OCG, ITIL Service Operation, The Stationery Office (TSO), 2007
[ISO09] ISO 27xxx – Chancen, Grenzen, Erfahrungen in der Praxis, Präsentation für den ISACA Trend Talk, 28. April 2009
[IST07] Office of Government Commerce OCG, ITIL Service Transition, The Stationery Office (TSO), 2007
[LFL10] Martin Latzenhofer, Christian Focke, Robert Lamprecht, IT-IKS – aber richtig!, Linde, 2011 [derzeit in Vorbereitung]
[MDU06] Michael Durst, Kennzahlengestütztes Management von IT-Architekturen, in HMD Praxis der Wirtschaftsinformatik Heft 250 08/2006, dpunkt.verlag
[MKD08] Michael Klotz, Dietrich-W. Dorn, IT-Compliance - Begriff, Umfang und relevante Regelwerke, in HMD Praxis der Wirtschaftsinformatik Heft 263 10/2008, dpunkt.verlag
[PMA08] PM Baseline, Version 3.0, Projektmanagement Austria, August 2008
[Req10] Pohl Klaus/ Rupp Chris,Basiswissen Requirements Engineering, Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level, dpunkt Verlag, 2010, 3. Auflage
[RIS09] IT Governance Institute, The RiskIT Framework, Principles, Process Details, Management Guidelines, Maturity Models, IT Governance Institute, 2009
[RST09] Jimmy Heschl, RiskIT – Das neue Framework der ITGI, Präsentation für den ISACA Trend Talk, 5. November 2009
[SSA08] Stefan Sackmann, Automatisierung von Compliance, in HMD Praxis der Wirtschaftsinformatik Heft 263 10/2008, dpunkt.verlag
[TSS05] Office of Government Commerce OCG, ITIL Service Support, The Stationery Office (TSO), 2005
[VAL08] IT Governance Institute, Enterprise Value: Governance of IT Investments, The Val IT Framework 2.0, IT Governance Institute, 2008
[WJG06] Wolfgang Johannsen, Matthias Goeken, IT-Governance - neue Aufgaben des IT-Managements, in HMD Praxis der Wirtschaftsinformatik Heft 250 08/2006, dpunkt.verlag
Internetquellen zum vertiefenden Verständnis
[BOC09] http://www.boc-group.com/documents/news/Whitepaper_Architekturmanagement_ mit_ADOit.pdf
[BSI10] https://www.bsi.bund.de/cln_165/ContentBSI/grundschutz/kataloge/m/m02/ m02011.html, Auszug aus M 2.11 Regelung des Passwortgebrauchs, Abruf 13.07.2010
[CO13] COSO, Internal Control — Integrated Framework, Executive Summary, May 2013, Abruf am 29.1.2014 http://www.coso.org/documents/990025P_Executive_Summary_final_may20_e.pdf
[CO92] COSO I - Darstellung, Abruf am 07.04.2014
http://www.enisa.europa.eu/act/rm/cr/business-process-integration/files/ir_cube.jpg[COS85] http://www.coso.org/
[COS92] http://www.enisa.europa.eu/act/rm/cr/business-process-integration/files/ir_cube.jpg
[COT09] http://www.isaca.org/cobit/
[CW14] Markus Gaulke, COBIT 5 - Hilfestellung für die IT-Compliance?, 09.01.2014, Computerwoche, Abruf am 29.1.2014
http://www.computerwoche.de/a/cobit-5-hilfestellung-fuer-die-it-compliance,2550273[EBR03] http://ebusiness.mit.edu/erik/optimize/pr_roi.html
[ER04] COSO II - Darstellung, Abruf am 07.04.2014
http://upload.wikimedia.org/wikipedia/commons/5/5c/Coso.gif[ERM04] http://upload.wikimedia.org/wikipedia/commons/5/5c/Coso.gif
[HAG10] http://www.ibu.uni-karlsruhe.de/rd_download/Organisation1.pdf , Auszug aus Lind-städt, Hagen: „Organisation“, Scholz, C. (Hrsg.), Vahlens Großes Personallexikon, 1. Aufl. München 2009, Abruf 13.09.2010
[INT10] http://www.intrinsische-mitarbeitermotivation.de/, Intrinsische Mitarbeitermotivation, Abruf 15.09.2010
[IS12] ISACA, COBIT 5 Introduction, 28.2.2012, Abruf am 29.1.2014 http://www.isaca.org/COBIT/Documents/An-Introduction.pdf
[ISE11] http://isae3402.com/
[ISO14] Frei verfügbare ISO /IEC Standards, Abruf am 29.3.2014 http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
[ITL07] http://www.itil.org/
[JS14] Jusline Österreich, § 190 UGB Führung der Bücher, Abruf am 04.04.2014 http://www.jusline.at/190_F%C3%BChrung_der_B%C3%BCcher_UGB.html
[KP13] COSO I – Überarbeitetes Rahmenwerk für Interne Kontrollsysteme, KPMG, Audit Committee News, Ausgabe 43/Q4 2013 , Abruf am 29.1.2014 http://www.kpmg.com/CH/de/auditcommittee/newsletter/Documents/pub-20130916-ac-news-43-article-04-de.pdf
[KPG09] http://www.kpmg.at/de/topics/5104_DEU_HTML.php
[KPM09] http://www.kpmg.at/de/files/URAEG_Folder_final.pdf
[NZ08] Wir lebten in einer Frivolitätsepoche, Ein Gespräch mit dem Philosophen Peter Sloterdijk über die Finanzmarktkrise, Neue Zürcher Zeitung, 29.11.2008, Abruf 07.02.2009
http://www.nzz.ch/nachrichten/kultur/aktuell/wir_lebten_in_einer_frivolitaetsepoche_1.1326434.html[POP04] www.bw.fh-deggendorf.de/kurse/infoman/zusatz/imws04-05.doc, Skript zur Vorle-sung Informationsmanagement WS2004/2005, Prof. Dr. Dr. Popp, FH-Deggendorf, Abruf 14.9.2010
[RSK09] http://www.isaca.org/riskit/
[SAS70] http://www.sas70.com/index2.htm
[SOX02] http://www.sox-online.com/
[URÄ08] http://www.parlament.gv.at/PG/DE/XXIII/BNR/BNR_00218/pmh.shtml
[VAL09] http://www.isaca.org/valit/
Allgemein wurde die Wikipedia-Bibliothek http://www.wikipedia.com/ in englischer und deutscher Variante für Querchecks und sprachlicher Abstimmung herangezogen (Stichwort war dabei in der Regel die jeweilige Kapitelüberschrift).
- ↑ Total Cost of Ownership
-
