Diplomarbeit. Konzeption und prototypische Implementierung eines Steuerungscockpits im Kontext des Managements von Unternehmensarchitektur

Größe: px
Ab Seite anzeigen:

Download "Diplomarbeit. Konzeption und prototypische Implementierung eines Steuerungscockpits im Kontext des Managements von Unternehmensarchitektur"

Transkript

1 Diplomarbeit Konzeption und prototypische Implementierung eines Steuerungscockpits im Kontext des Managements von Unternehmensarchitektur Andreas Feldschmid Hochschule Rosenheim Fakultät für Informatik Wintersemester 2008/2009 Erstprüfer: Prof. Dr. Gerd Beneken Zweitprüfer: Prof. Dr. Reiner Hüttl

2

3 Selbstständigkeitserklärung Erklärung Hiermit versichere ich, dass ich diese Diplomarbeit selbstständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. Andreas Feldschmid Rosenheim, den 02. April 2009

4

5 Kurzfassung In großen Unternehmen wird eine Vielzahl von Technologien, Anwendungen und Hardwareplattformen eingesetzt. Diese Strukturen sind meist historisch gewachsen und nicht aufeinander abgestimmt. Das Unternehmensarchitekturmanagement wirkt diesem Problem entgegen, indem es das Zusammenspiel der Anwendungen steuert und die IT auf die betrieblichen Prozesse abstimmt. Obwohl das grundsätzliche Vorgehen des Unternehmensarchitekturmanagements bereits durch Frameworks, Best Practices und Tools unterstützt wird, fehlt es an praktisch einsetzbaren Steuerungswerkzeugen. So beruhen wichtige Entscheidungen im Bereich der Unternehmensarchitekturentwicklung oft nur auf dem eigenen Bauchgefühl, subjektiv gewählten Kriterien und langjähriger Erfahrung. Eine Prüfung, ob das Unternehmensarchitekturmanagement qualitativ hochwertig durchgeführt wird und ob tatsächlich die gewünschten Ziele erreicht werden, findet meist gar nicht statt. Diese Diplomarbeit untersucht, wie man Kennzahlen sinnvoll zur Steuerung der Unternehmensarchitekturentwicklung einsetzen kann und was dabei zu beachten ist. Es wird ein Konzept zur Konstruktion von Kennzahlen vorgestellt und es werden konkrete Richtlinien zur grafischen Darstellung der Kennzahlen formuliert. Die erarbeiteten Ansätze werden anhand eines Beispiel-Steuerungscockpits sowie einer prototypischen Implementierung umgesetzt. Unternehmensarchitekten und IT-Verantwortliche können basierend auf den hier vorgestellten Konzepten und Richtlinien ein individuell auf ihre Bedürfnisse zugeschnittenes Steuerungscockpit entwerfen, welches sie mit soliden Informationen dabei unterstützt, die Entwicklung der Unternehmensarchitektur zu steuern. Schlagworte: EAM, Unternehmensarchitekturmanagement, IT-Bebauungsmanagement, iteraplan, Controlling, Business Intelligence, Kennzahlen, Dashboard

6

7 Inhaltsverzeichnis 1 Einleitung Steuerungscockpit für das Unternehmensarchitekturmanagement Aufbau der Arbeit Unternehmensarchitekturmanagement Begriffsdefinitionen IT-Governance IT-Strategie Unternehmensarchitektur Unternehmensarchitekturmanagement IT-Bebauungsmanagement Best Practices Architekturmodell Planungsstufen der Bebauung Granularität und Ausrichtung Aufbau und Nutzung Nutzen IT-Controlling Grundlagen Warum IT-Controlling? Einordnung im allgemeinen Controlling Ebenen des Controllings Kennzahlen Begriffsdefinitionen Anforderungen an Kennzahlensysteme Dokumentation von Kennzahlen Kennzahlensysteme in der Literatur Controlling-Regelkreis Visualisierung von Kennzahlen Steuerungscockpit Darstellungsformen Gestaltungsregeln Steuerung der Unternehmensarchitektur Zusammenspiel Unternehmensarchitekturmanagement und Controlling Nutzer und Sichten Steuerungsebenen und -aufgaben i

8 Inhaltsverzeichnis 4.4 Entwicklung eines Kennzahlensystems Grundsätzliches Vorgehen Prozess der Entwicklung IT-Bebauungsmanagement mit iteraplan Vorstellung iteraplan Datenmodell Vorgegebenes Datenmodell Erweiterung durch Merkmale Sichten- und Rollenkonzept Auswertungsmöglichkeiten Tabellarische Auswertungen Grafische Auswertungen Controlling mit iteraplan Vorhandene Controllingansätze Handlungsbedarf Konzeption eines Steuerungscockpits Anforderungsanalyse Identifikation potenzieller Nutzer Funktionale Anforderungen Einflussfaktoren Qualitätsanforderungen Identifikation von Datenquellen Beispielkennzahlen für das IT-Bebauungsmanagement mit iteraplan Ziele der Kennzahlen Kennzahlensammlung Kennzahlensystem für Informationssystem-Bebauungsplaner Prototypische Implementierung eines Steuerungscockpits Einschränkungen und Zielsetzung Datenextraktion aus iteraplan Ausgangssituation Anforderungen Vorstellung BI-Exporter Problematik der bisherigen Lösung Identifikation und Bewertung von Lösungsalternativen Auswahl und Umsetzung einer Lösung Erstellung der Kennzahlen Beschreibung der umgesetzten Kennzahlen Erhebung der Kennzahlen Visualisierung der Kennzahlen Verwendete Werkzeuge Übersicht über das Steuerungscockpit ii

9 Inhaltsverzeichnis 8 Zusammenfassung und Ausblick Zusammenfassung Ausblick Abkürzungsverzeichnis 103 Abbildungsverzeichnis 105 Tabellenverzeichnis 107 Literaturverzeichnis 109 Anhang 115 iii

10 iv

11 1 Einleitung Die Informationstechnik (IT) beeinflusst immer mehr betriebliche Prozesse. Nicht nur Banken, Versicherungen oder Telekommunikationsunternehmen handeln nur noch mit Informationen, sondern auch produzierende Betriebe sind immer stärker mit der IT verflochten. Die Anwendungslandschaften wachsen stetig. Durch Individuallösungen, die teilweise unter starkem Zeitdruck entstehen, entwickeln sich Anwendungslandschaften heterogen. Das Resultat sind überflüssige oder redundante Anwendungen. Gerade bei großen Unternehmen fällt es schwer einen Überblick über die verwendeten Informationssysteme, Technologien und die eingesetzte Hardware zu behalten. Die Lösung dieses Problems wird durch Firmenzusammenschlüsse und dynamische Geschäftsprozesse zusätzlich erschwert. Die Folge ist eine IT, welche die Geschäftsprozesse nur noch unzureichend unterstützt und unter abnehmender Kosteneffizienz und Wartbarkeit leidet. In den letzten Jahren entstand ein neues Vorgehen, um dieser Entwicklung entgegen zu wirken. Das Management der Unternehmensarchitektur im Bereich der IT hat die Aufgabe, Transparenz zu schaffen und den Einsatz der IT stärker auf die Geschäftsziele auszurichten. Der Entschluss Unternehmensarchitekturmanagement (UAM) 1 zu betreiben, reicht aber noch nicht aus. Zwar existieren Frameworks, Best Practices und Tools, die das grundsätzliche Vorgehen unterstützen, wichtige Entscheidungen im Bereich der Architekturentwicklung beruhen trotzdem noch oft auf rein subjektiv gewählten Kriterien und langjähriger Erfahrung. Laut einer 2008 durchgeführten Umfrage 2 von Accenture [Acc08], beruhen 40% der wichtigen Entscheidungen in Unternehmen lediglich auf dem Bauchgefühl der Entscheidungsträger. Um diese Situation zu verbessern, versucht das IT-Controlling diese Entscheidungen zu unterstützen, indem es Transparenz durch die Sammlung und Verarbeitung von Informationen schafft (vgl. [MLBS09]). 1.1 Steuerungscockpit für das Unternehmensarchitekturmanagement Die Aufgabe dieser Diplomarbeit ist es, zu untersuchen, wie die Entwicklung der Unternehmensarchitektur gesteuert werden kann. Für die Steuerung sollen Methoden aus dem Controlling auf das Unternehmensarchitekturmanagement angewandt werden. Es sind Daten zu identifizieren, die sich für diese Steuerung eignen. Dazu muss zunächst festgelegt werden, was die Ziele des Unternehmensarchitekturmana- 1 Im Englischen: Enterprise Architecture Management (EAM). Da die englische Abkürzung weitaus gebräuchlicher ist als UAM, wird sie im weiteren Verlauf der Arbeit bevorzugt verwendet Teilnehmer aus Unternehmen mit einem Betriebseinkommen größer 500 Millionen Dollar 1

12 1 Einleitung gements sind. Es ist zu identifizieren, welche Benutzer überhaupt ein Steuerungswerkzeug benötigen und welche Steuerungsgrößen für sie relevant sind. Darauf aufbauend ist ein Kennzahlensystem für die Steuerung zu erstellen und sinnvoll grafisch umzusetzen. Ein besonderes Augenmerk gilt den verwendeten Visualisierungen, da diese ausschlaggebend für die schnelle Erfassung von Zusammenhängen sind. Anschließend sollen in einer prototypischen Implementierung Daten aus dem EAM-Tool iteraplan 3 in Form eines Steuerungscockpits visualisiert werden. Das Steuerungscockpit soll Führungskräfte dabei unterstützen, Entscheidungen zu treffen. 1.2 Aufbau der Arbeit Kapitel 2 Kapitel 3 Kapitel 4 Kapitel 5 Kapitel 6 Kapitel 7 Kapitel 8 Zunächst werden die Grundlagen des Unternehmensarchitekturmanagements sowie angrenzender Aufgaben erläutert. Vor allem die Definition der Begriffe ist äußerst wichtig, da viele Begriffe in diesem Bereich synonym verwendet werden oder noch nicht klar abgegrenzt sind. Anschließend werden die Grundlagen des IT-Controllings vorgestellt, wobei der Fokus auf Kennzahlen liegt. Der Begriff des Steuerungscockpits wird eingeführt und es wird erläutert, welche Visualisierungen sich für die Darstellung von Kennzahlen in einem Steuerungscockpit eignen und welche Regeln dabei beachtet werden müssen. Nach diesem theoretischen und allgemeinen Teil erfolgt die konkrete Verbindung zwischen Unternehmensarchitekturmanagement und Controlling. Es wird identifiziert, wer am Unternehmensarchitekturmanagement beteiligt ist und ein Steuerungswerkzeug benötigt und welche Steuerungsgrößen von Interesse sind. Zudem wird ein Prozess zur Konstruktion von hochwertigen Kennzahlen vorgestellt. Am Beispiel des EAM-Tools iteraplan wird veranschaulicht, wie Unternehmensarchitekturmanagement in der Praxis betrieben wird. Es wird analysiert, welche Möglichkeiten zum Controlling bereits in iteraplan vorhanden sind, wo Handlungsbedarf besteht und welche Position das Steuerungscockpit dabei einnimmt. In diesem Kapitel werden Anforderungen an ein Steuerungscockpit für das Unternehmensarchitekturmanagement erhoben. Anschließend wird ein auf COBIT basierender Kennzahlenkatalog erstellt, sowie ein konkretes Kennzahlensystem entworfen. Zur Validierung der Konzepte wird ein Prototyp eines Steuerungscockpits auf Basis der Daten aus iteraplan implementiert. Dazu werden zunächst die Daten aus iteraplan exportiert und anschließend Kennzahlen erhoben und dargestellt. Dabei gilt der Fokus vor allem der sinnvollen grafischen Umsetzung der Kennzahlen. Abschließend erfolgt eine Zusammenfassung der wichtigsten Ergebnisse, sowie ein Ausblick auf weitere Entwicklungen und eine produktive Umsetzung. 3 iteraplan ist das von iteratec entwickelte Werkzeug zur Durchführung des Unternehmensarchitekturmanagements und als Open-Source-Edition unter verfügbar. 2

13 2 Unternehmensarchitekturmanagement Die Grundsteine für das Management von Unternehmensarchitektur wurden zwar schon 1987 unter anderem von Zachman [Zac87] gelegt, der praktische Einsatz im großen Stil erfolgt aber erst seit kurzem. Daher erfolgt in diesem Kapitel eine kurze Einführung in das Thema Unternehmensarchitekturmanagement. Zunächst wird der Begriff des Unternehmensarchitekturmanagements sowie weitere Begriffe aus diesem Umfeld definiert. Das gewählte Vorgehen ist hierbei Top-Down, das heißt es wird zunächst die IT-Governance und IT-Strategie, welche im Aufgabenbereich des Unternehmensvorstands liegen definiert und dann weiter nach unten, bis zum IT-Bebauungsmanagement vorgedrungen. Anschließend werden Best Practices für das Unternehmensarchitekturmanagement vorgestellt. Abschließend wird zusammengefasst, welcher Nutzen mit dem Unternehmensarchitekturmanagement erreicht werden kann. Für eine ausführliche Behandlung der Themen wird [Kel07], [Nie05], [Der06] sowie [Han09] empfohlen. 2.1 Begriffsdefinitionen Im Bereich des EAM findet sich eine Vielzahl von Begriffen, die noch nicht einheitlich definiert sind. Daher wird hier erläutert, was unter den einzelnen Begriffen im weiteren Verlauf dieser Arbeit zu verstehen ist IT-Governance Definition: IT-Governance Die Steuerung der IT-Funktion (IT-Governance) liegt in der Verantwortung der Vorstandsebene. Sie ist ein wesentlicher Teil der Unternehmenssteuerung. Sie gliedert sich auf in die Führungsaufgaben, die Gestaltung der organisatorischen Strukturen und der Prozesse, die sicherstellen, dass die IT-Funktion einer Organisation die Strategien der Organisation optimal unterstützt. Quelle: Deutsche Übersetzung übernommen aus [Kel07, S. 19]. Originalquelle: [ITGI03] Das IT-Governance-Modell des IT Governance Institute (ITGI) definiert eine Liste von Aufgaben, welche sicherstellen sollen, dass die IT die Strategie der Organisation optimal unterstützt. Nach Keller [Kel07, S. 20] sind dies: 3

14 2 Unternehmensarchitekturmanagement IT-Strategie IT-Architektur IT-Controlling IT-Betrieb IT-Programm-Management IT-Human-Resources-Management IT-Risikomanagement Im Rahmen dieser Arbeit besonders interessant sind die Aufgaben IT-Strategie und IT- Controlling IT-Strategie Auch wenn die Mehrzahl der Unternehmen von sich behaupten, eine ausgefeilte Strategie entwickelt zu haben, um ihre Ziele zu erreichen, ist dies laut Gartner [Gar02] noch nicht der Fall. Begründen lässt sich diese Diskrepanz in der unterschiedlichen Auffassung, was eine Strategie überhaupt ist. Eine Trivialstrategie wie Verkauf von Waschmaschinen gilt nicht als echte Strategie, da sie im Grunde selbstverständlich ist und die Nichtbefolgung dieser Strategie sofort zum Ruin des Unternehmens führen würde (vgl. [Kel07]). Was ist eine Strategie... Die klassische Definition aus dem Militär besagt etwa: Definition: Strategie Die Strategie [...] muss [...] ein Ziel setzen [...], d.h., sie entwirft den Kriegsplan, und an dieses Ziel knüpft sie die Reihe der Handlungen an, welche zu demselben führen sollen. Quelle: [Cla03] Wichtige Bestandteile einer Strategie sind ein klares Ziel und die Eingrenzung der möglichen Handlungen um dieses zu erreichen. Sie enthält aber keine unmittelbare Handlungsvorgabe oder konkrete Ressourcenplanung. Der Prozess der Strategieformulierung ist sehr umfangreich und muss aktiv von der Unternehmensleitung unterstützt werden (vgl. [HS07, S. 24ff]). Eine Strategie sollte sorgfältig formuliert werden und möglichst langfristige Ziele enthalten, damit sie eine gewisse Zeit lang konstant bleibt und umgesetzt werden kann. Trotzdem ist eine Strategie nicht in Stein gemeißelt. Wenn die aktuelle Strategie nicht umgesetzt werden kann, muss sie angepasst werden. Spätestens wenn alle Ziele der Strategie erreicht wurden muss sie erweitert oder durch eine neue Strategie abgelöst werden. 4

15 2.1 Begriffsdefinitionen... und was eine IT-Strategie? Die IT-Strategie ist ein Teil der Unternehmensstrategie. Ihr Ziel ist es, die Geschäftsprozesse, welche der Unternehmensstrategie dienen sollen, mit Hilfe der IT zu verwirklichen. Besitzt das Unternehmen eine Unternehmensstrategie, kann aus dieser eine IT-Strategie abgeleitet werden. 1 Ein mögliches Vorgehen zur Erarbeitung einer IT-Strategie zeigt Abbildung 2.1. Die strategischen Absichten, welche sich aus der Unternehmensstrategie ergeben, werden mit Business- und IT-Grundsätzen abgeglichen und mit Richtlinien aus dem IT- Governance abgestimmt. strategische Absichten Business- Grundsätze IT- Grundsätze IT- Governance IT- Strategie Abbildung 2.1: Strategieprozess angelehnt an Wolfgang Keller [Kel07, S. 77] Unternehmensarchitektur Für den Begriff Unternehmensarchitektur existiert derzeit keine einheitlich anerkannte Definition. In der Literatur findet sich eine Vielzahl verschiedener Definitionen, die teilweise erhebliche Unterschiede aufweisen. 2 Nach [ISO00] kann man grundsätzlich zwischen zwei Architekturtypen unterscheiden: Typ-1-Architekturen befassen sich mit der Beschreibung der Unternehmensarchitektur zu einem bestimmten Zeitpunkt. Typ-2-Architekturen legen den Schwerpunkt auf den Prozess zur Weiterentwicklung der Unternehmensarchitektur (beispielsweise die Architekturdefinition in [IEE00]). Im Rahmen dieser Diplomarbeit wird für den Begriff (Unternehmens-) Architektur die Definition nach ISO [ISO00] übernommen: Architektur ist die Beschreibung (ein Modell) der grundsätzlichen Anordnung und Beziehung der einzelnen Teile eines Systems (dabei kann dieses System real vorhanden oder lediglich geplant sein). Die strategische Planung, Entwicklung und Umsetzung einer Architektur findet sich in dieser Arbeit im Begriff des (Unternehmens-) Architekturmanagements wieder. 1 Hinweise zur Erstellung einer IT-Strategie, was diese genau enthalten sollte und Tipps zu möglicherweise auftretenden Problemen findet man in [Kel07, S. 75ff]. 2 Eine sehr ausführliche Betrachtung des Begriffs Unternehmensarchitektur findet sich bei [Lei07]. 5

16 2 Unternehmensarchitekturmanagement Eine sehr prägnante Definition des Begriffs Unternehmensarchitektur, wie er in dieser Arbeit verwendet wird, findet sich bei Wikipedia: Definition: Unternehmensarchitektur Die Unternehmensarchitektur (Enterprise Architecture) im Rahmen der IT beschreibt das Zusammenspiel von Elementen der Informationstechnologie und der geschäftlichen Tätigkeit im Unternehmen. Sie unterscheidet sich von Begriffen wie Informationsarchitektur oder Softwarearchitektur durch den gesamthaften Blick auf die Rolle der Informationstechnologie im Unternehmen. Oft geht damit auch ein höherer Abstraktionsgrad einher. Quelle: (aufgerufen am ) Der Begriff der Unternehmensarchitektur steht zwar in engem Zusammenhang mit der IT, beschränkt sich aber nicht nur auf diese. Die Unternehmensarchitektur bezieht sich auf sämtliche Bausteine, aus denen ein Unternehmen aufgebaut ist, sowie deren Beziehungen untereinander. Nach Niemann [Nie05] kann man zwischen drei wesentlichen Architekturschichten unterscheiden (siehe Abbildung 2.2). Ziele und Strategien Geschäftsarchitektur Anforderungen und Rahmenbedingungen Geschäftsprozesse und Geschäftsobjekte Anwendungsarchitektur Anwendungssysteme Technische Komponenten Daten Subsysteme Anwendungskomponenten Systemarchitektur Plattformen Support Level Infrastrukturkomponenten Abbildung 2.2: Architekturpyramide angelehnt an [Nie05, S. 17] 6

17 2.1 Begriffsdefinitionen Unternehmensarchitekturmanagement Jedes Unternehmen hat eine Architektur, so wie auch jedes Gebäude eine Architektur besitzt. Meist ist die Unternehmensarchitektur historisch gewachsen und somit weit vom optimalen Zustand entfernt. Viele kleine Änderungen, Kompromisse unter Zeitdruck und Insellösungen schaffen eine heterogene Landschaft von Prozessen, verwendeter Software und Technologien. Ab einer gewissen Unternehmensgröße geht zudem der Überblick über die IT-Systeme verloren. Herauszufinden, welche Systeme noch aktiv genutzt werden, welche von anderen Anwendungen zwingend benötigt werden und welche überflüssig sind, ist bei mehreren tausend aktiven IT-Systemen nicht mehr ohne weiteres möglich. Man benötigt daher ein Werkzeug, um eine Architektur erarbeiten, dokumentieren und vor allem umsetzen und weiterentwickeln zu können. Da Unternehmen einem ständigen Änderungsprozess unterworfen sind, reicht es nicht die Architektur ein einziges Mal zu planen und zu dokumentieren. Es muss ein kontinuierliches Management der Unternehmensarchitektur eingeführt werden, welches verantwortlich für die Planung, Entwicklung, Nutzung und Pflege der Unternehmensarchitektur ist (vgl. [Nie05, S. 23]). Das Unternehmensarchitekturmanagement setzt die Vorhaben aus der (IT-)Strategie in konkrete Maßnahmen um, und baut so eine Brücke zwischen den strategischen Anforderungen aus der Geschäftswelt und deren Umsetzung in der IT. Dieser Vorgang erfolgt iterativ über mehrere Jahre hinweg. Dabei plant das EAM eine schrittweise Annäherung an die Zielarchitektur, leitet notwendige Maßnahmen ein und verändert gegebenenfalls auch das Ziel selbst (vgl. [Han09], [Kel07]). Der Umfang, in dem Unternehmensarchitekturmanagement betrieben werden sollte, ist abhängig von Faktoren wie der Größe des Unternehmens, des zur Verfügung stehenden Budgets, der Organisationsstruktur und vor allem auch vom Umfang der Fragestellungen, die beantwortet werden sollen. Ab wann es sich für ein Unternehmen lohnt EAM zu betreiben, kann nicht genau bestimmt werden. Noch vor kurzem wurde EAM vor allem von Großunternehmen genutzt, welche Milliardenumsätze und IT-Budgets ab einem hohen zweistelligen Millionen-Euro-Bereich besitzen. Es ist aber davon auszugehen, dass die EAM-Methoden mittel- bis langfristig auch im Mittelstand Einzug halten werden (vgl. [Kel07, S. 9]). Im Gegensatz zur Planung und Entwicklung von Gebäuden (dem Bauingenieurwesen) ist das Unternehmensarchitekturmanagement keine methodisch strikt organisierte Disziplin. In welcher Form das EAM in der Praxis umgesetzt wird ist nicht einheitlich definiert. Es existieren zwar Frameworks 3 zur Umsetzung des EAM, diese sind aber so allgemein gefasst, dass sie auf unterschiedlichste Weise umgesetzt werden können (vgl. [Lei07]). 3 Beispielsweise das Zachman Framework (http://www.zifa.com) oder TOGAF (http://www.opengroup. org/togaf). 7

18 2 Unternehmensarchitekturmanagement IT-Bebauungsmanagement Das IT-Bebauungsmanagement ist das zentrale Werkzeug, mit dem das Unternehmensarchitekturmanagement umgesetzt wird. Der Schwerpunkt liegt dabei in der Informationssystem-Architektur (siehe Abbildung 2.3 auf Seite 9). Ein Informationssystem (IS) auch Applikation, Anwendung oder kurz System genannt ist ein sinnvolles Ganzes, welches der Anwender als technische und fachliche Einheit begreift (vgl. [Sie06]). Definition: IT-Bebauungsmanagement Das IT-Bebauungsmanagement dokumentiert und gestaltet die IS-Landschaft im Zusammenspiel mit der fachlichen, technischen und Betriebsinfrastruktur- Bebauung sowie dem Projektportfolio. Die IS-Landschaft besteht im Wesentlichen aus den Informationssystemen, deren Daten und Schnittstellen. Quelle: [Han09, S. 109f] Eine Bebauung ist als eine Instanziierung der Unternehmensarchitektur anzusehen. Sie füllt die durch die Architektur vorgegebenen Strukturen (vgl. [Han09, S.305]). Ziel des IT-Bebauungsmanagements ist es, ein Instrument für die Analyse, Planung und Steuerung der Applikationslandschaft bereit zu stellen. Das IT-Bebauungsmanagement unterstützt die Beherrschung der Komplexität der Anwendungslandschaft und ermöglicht eine effektive und effiziente Steuerung der IT (vgl. [ite09]). Die wesentliche Aufgabe des IT-Bebauungsmanagements ist es, die Ist-Situation der Informationssysteme zu dokumentieren und darauf basierend die Weiterentwicklung der IS-Bebauung zu planen. Die Informationssysteme setzen dabei auf technische Bausteine auf und werden auf die Betriebsinfrastruktur verteilt (siehe Abbildung 2.3). Die fachlichen Prozesse, technischen Bausteine und die Betriebsinfrastruktur werden aus der Sicht des IT-Bebauungsmanagements als gegeben angesehen und nicht aktiv modelliert, sondern lediglich dokumentiert und mit den Informationssystemen in Verbindung gesetzt. Die Modellierung dieser Bausteine erfolgt in den darauf spezialisierten Werkzeugen (zum Beispiel Prozessmodellierung mit ARIS). 2.2 Best Practices Wie bereits erwähnt, existieren einige Frameworks zur Umsetzung des EAM. Diese unterscheiden sich beispielsweise im Detaillierungsgrad und der Tiefe der zu erledigenden Aufgaben sowie in der Art und Weise der Unterstützung der verschiedenen Bereiche des Enterprise Architecture Management [Lei07]. Um ein praktisches Steuerungswerkzeug für das EAM zu erstellen, ist es aber notwendig, die grundsätzlichen Bestandteile sowie ein Vorgehen zur Umsetzung des EAM festzulegen. In diesem Abschnitt wird daher ein Architekturmodell sowie ein Vorgehen für Aufbau und Nutzung des EAM vorgestellt, welche sich in der Praxis bewährt haben (vgl. [Han09], [Nie05]). 8

19 2.2 Best Practices Architekturmodell Um die Zuständigkeiten klar abzugrenzen und die Übersichtlichkeit zu wahren, hat es sich bewährt die Unternehmensarchitektur in mehrere Architekturebenen aufzugliedern. Hier wird das Architekturmodell aus [Han09] vorgestellt (siehe Abbildung 2.3). Fachliche Architektur Geschäftsprozesse Informationssystem-Architektur Informationssysteme Schnittstellen Informationsfluss Technische Architektur Funktionen Produkte Geschäftseinheiten Geschäftsobjekte Betriebsinfrastruktur- Architektur Technische Bausteine (Blueprint) Infrastrukturelemente IT-Strategie Unternehmensstrategie Abbildung 2.3: Aufbau der Unternehmensarchitektur aus [Han09, S. 67] Der Aufbau orientiert sich stark am geläufigen Modell aus der Literatur, auch wenn die Bezeichnungen etwas abweichen (vgl. Architekturpyramide bei [Kel07, S. 22], [Nie05, S. 17], [Der06, S. 6]). Die Begriffe, die [Nie05] in seiner Architekturpyramide (siehe S. 6) verwendet, werden nachfolgend in Klammern angegeben. Die fachliche Architektur (Geschäftsarchitektur) beschäftigt sich mit der Umsetzung von Geschäftsprozessen durch fachliche Funktionen, welche mit Geschäftsobjekten arbeiten, sowie deren Zugehörigkeit zu Geschäftseinheiten und Produkten. Die Informationssystem-Architektur (Anwendungsarchitektur) plant die zur Umsetzung der Geschäftsprozesse nötigen IS und deren Schnittstellen. Die IS-Architektur verbindet somit die fachlichen Geschäftsprozesse mit den Bausteinen der technischen Architektur. 9

20 2 Unternehmensarchitekturmanagement Die technische Architektur (Systemarchitektur) legt fest, welche technischen Bausteine zur Umsetzung der IS zur Verfügung stehen. Technische Bausteine sind z.b. Datenbanksysteme, Programmiersprachen, Architektur-Muster, Frameworks, Tools oder im Unternehmen etablierte Referenzarchitekturen. Die Betriebsinfrastruktur-Architektur (Infrastrukturarchitektur) befasst sich mit der physikalischen Umsetzung, also der Verteilung der Software auf Server oder dem Einsatz in mehreren Niederlassungen Planungsstufen der Bebauung Das Architekturmodell wird nicht nur für die Dokumentation der aktuellen Bebauung, sondern auch für eine Planung der weiteren Entwicklung benutzt. Nach Hanschke [Han09] können die Bebauungen sowohl den aktuellen als auch den zukünftigen Zustand und die Umsetzungsstufen dokumentieren [, wodurch] sich [die] wesentlichen Bestandteile des aktuellen bzw. zukünftigen Geschäftsmodells des Unternehmens in ihrem Zusammenspiel beschreiben [lassen]. Geschäftsanforderungen Soll-Bebauung = Vision der Ziel- Bebauung... Plan i = Soll Plan + 1 Plan Projekte und Wartungsmaßnahmen zur Umsetzung der Plan-Bebauung IT-Strategie Ist- Bebauung Zeit Abbildung 2.4: Ist-, Plan- und Soll-Bebauung aus [Han09, S. 89] Es kann zwischen Ist-, Plan- und Soll-Bebauung unterschieden werden (siehe Abbildung 2.4). Die Ist-Bebauung dokumentiert den aktuellen Zustand der IT-Landschaft. Nach [Han09] beschreibt eine Plan-Bebauung einen Schritt auf dem Weg von der Ist-Bebauung zur Soll-Bebauung bzw. einen Schritt zwischen zwei Plan-Bebauungen. Die Soll-Bebauung stellt eine optimale Bebauung dar, in der die Business- und IT-Ziele vollständig umgesetzt sind. 10

21 2.2 Best Practices Granularität und Ausrichtung Wie bereits erwähnt, kann EAM in unterschiedlichem Umfang umgesetzt werden. Je nach Fragestellungen, die beantwortet werden sollen, muss entschieden werden, in welcher Granularität und zeitlichen Dimension die Dokumentation und Planung durchgeführt werden soll. abstrakt Ausrichtung strategisch Zielgebiet operativ detailliert Granularität Abbildung 2.5: Ausrichtung und Granularität angelehnt an [Nie05, S. 38]. Fein oder grob? Ein wichtiger Punkt ist die Granularität der erstellten Modelle. Mag es zunächst verlockend erscheinen, möglichst detaillierte Auflistungen zu erstellen und möglichst viele Informationen zu sammeln, stellt sich später heraus, dass der Pflegeaufwand damit viel zu hoch wird. So sind Software-Schichten oder detaillierte Prozessabläufe in einer EAM-Sicht fehl am Platz (vgl. [Nie05, S.216ff]). Wie detailliert die Architektur letztlich entworfen wird ist sicherlich eine individuelle Entscheidung. Dabei sollte aber bedacht werden, dass es oft besser ist, grobe aber dafür aktuelle und konsistente Daten zu besitzen, als detaillierte Daten, die nicht mehr zutreffend sind. Plan-Architekturen sollten generell gröber modelliert werden als die Ist-Architektur. Die Soll-Architektur, welche die optimale Architektur darstellt, kann nur sehr grob dargestellt werden. Auch das EAM unterliegt dem Wirtschaftlichkeitsgebot, der Nutzen muss höher sein als der (Pflege-)Aufwand. 11

22 2 Unternehmensarchitekturmanagement Strategisch oder operativ? Ebenso wie beim Detaillierungsgrad muss auch bei der Ausrichtung abgewägt werden. Orientiert sich die Unternehmensarchitektur stark am derzeitigen (operativen) Stand der Architektur, sind geplante Änderungen schlecht sichtbar. Setzt man den Fokus dagegen auf die strategische Planung, fehlt der Bezug zur aktuellen Lage Aufbau und Nutzung Um das Unternehmensarchitekturmanagement aufzubauen und zu nutzen, empfiehlt es sich, den sogenannten Unternehmensarchitektur-Zyklus zu durchlaufen (siehe Abbildung 2.6). Document Analyze Act Check Plan Abbildung 2.6: Unternehmensarchitektur-Zyklus angelehnt an [Nie05, S. 38]. Zunächst wird mit der Dokumentation der Ist-Situation begonnen (Document). Dazu wird ein Modell dieser Architektur erstellt, umgesetzt und befüllt. Diese gesammelten Informationen werden anschließend analysiert (Analyze). Aufgrund des bei der Analyse identifizierten Handlungsbedarfs lassen sich Szenarien erstellen und auswerten, und schließlich ein Plan zum weiteren Vorgehen entwickeln (Plan). Nachdem die geplanten Änderungen der Architektur ganz oder teilweise umgesetzt wurden (Act), wird die Dokumentation auf den neusten Stand gebracht. Der Zyklus wird nun wieder von vorne durchlaufen. Bei jedem dieser Schritte sollten die Ergebnisse auf ihre Qualität überprüft werden (Check). Dies bedeutet auch, dass verifiziert werden muss, ob die durchgeführten Maßnahmen zu den gewünschten Zielen geführt haben. Auch dieser Prozess sollte möglichst automatisiert werden, indem Kennzahlen definiert und überwacht werden. 12

23 2.3 Nutzen 2.3 Nutzen Nachdem man den Begriff Unternehmensarchitekturmanagement nun einordnen kann, wird hier kurz darauf eingegangen, welchen Nutzen es für Unternehmen bietet. Überblick schaffen Unternehmensarchitekturmanagement verschafft den einzelnen Zielgruppen einen Überblick über den aktuellen und den geplanten Stand der Architektur. EAM trägt auch dazu bei, unter den Mitarbeitern ein gemeinsames Verständnis für den Aufbau des Unternehmens zu verbreiten und eine einheitliche Begriffswelt im Unternehmen zu etablieren. So kann ein aktuelles Inventar aller aktiven Informationssysteme und deren Beziehungen beispielsweise als Einsteig für ein Security-Audit dienen. Optimierung der bestehenden Landschaft Für die Entwicklung neuer Systeme wird viel geplant (Portfolioplanungen, Projektplanungen, etc). Für die Optimierung der bestehenden Landschaft wird aber sehr wenig oder kein Aufwand betrieben. Nach [Nie05, S. 126] wäre es sinnvoll, eine Analyse der Schwachstellen, eine Planung von Wartungs-, Optimierungs- und Erneuerungsmaßnahmen aus fachlicher und technischer Sicht gleichermaßen gesteuert einzuführen. Die Transformation der Strategie in die Wirklichkeit sollte nicht nur für den (kleinen) Teil der Neuprojekte, sondern auch für den (größeren) Teil der laufenden Wartung und Pflege umgesetzt werden. Das EAM analysiert die bestehende Landschaft und identifiziert Bereiche der IT, welche die aktuellen oder geplanten Geschäftsprozesse unzureichend unterstützen. Neben dieser Ausrichtung der IT auf die Anforderungen der Geschäftswelt wird auch das Zusammenspiel der IT-Systeme untereinander verbessert. Planung der zukünftigen Landschaft Eine dokumentierte Unternehmensarchitektur schafft die Basis für die Planung zukünftiger Architekturprojekte. Dabei kann es sich zum Beispiel um eine Konsolidierung der bestehenden Landschaft, die Vorbereitung auf neue Geschäftsanforderungen oder eine veränderte Unternehmens- oder IT-Strategie handeln. Gegebenenfalls kann es auch mehrere gültige Plan-Bebauungen geben, die nicht aufeinander aufbauen, sondern einem einzigen Zeitpunkt zugeordnet sind. Diese sogenannten Planungsszenarien stellen alternative Lösungsmöglichkeiten für eine Annäherung an die Soll-Bebauung dar und können miteinander verglichen und bezüglich ihrer Umsetzung bewertet werden (vgl. [Han09, S. 89]). 13

24 2 Unternehmensarchitekturmanagement Fragen beantworten Der Nutzen einer Unternehmensarchitektur sollte sich darin bemerkbar machen, dass ehemals offene Fragen nun beantwortet werden können. Konkrete Fragestellungen sind beispielsweise (angelehnt an [Nie05] und [Han09]): Gibt es Lücken in der IT-Unterstützung von Geschäftsprozessen? Gibt es redundante Anwendungen? Wie viele verschiedene Technologien werden für ähnliche Aufgaben eingesetzt? Ist diese Vielfalt gerechtfertigt? Werden bereits erprobte Lösungen für ein Problem wiederverwendet? Wie stark sind die Informationssysteme untereinander gekoppelt und wie wirkt sich das auf die Unterstützung der Geschäftsprozesse aus? Werden die durchgeführten Projekte anhand ihres Kosten/Nutzen-Verhältnisses und ihrem Beitrag zur Unternehmensstrategie ausgewählt? Unternehmensarchitekturmanagement vollständig nutzen Die Prozesse des EAM einzuführen, die Unternehmensarchitektur zu dokumentieren und weiterzuentwickeln ist mit einigem Aufwand verbunden. Damit sich dieser lohnt, muss sichergestellt werden, dass die dabei erzeugten Informationen tatsächlich in vollem Umfang für Analysen und Planungen genutzt werden (vgl. [Nie05, S. 127]). Dazu ist es notwendig, das Unternehmensarchitekturmanagement um die Methoden des Controllings zu erweitern und damit sicherzustellen, dass die gesammelten Informationen in bestmöglicher Weise analysiert werden. Im nächsten Kapitel erfolgt daher eine Einführung in das IT-Controlling, wobei besonders auf Kennzahlen und deren Visualisierung eingegangen wird. 14

25 3 IT-Controlling In diesem Kapitel erfolgt eine Einführung in das Thema IT-Controlling. Dabei werden die Grundlagen des Controllings erläutert, Vorschläge zum Aufbau eines Kennzahlensystems betrachtet und der Controlling-Regelkreis eingeführt. Es wird ein Vorgehen erarbeitet, mit dem zielorientierte Kennzahlen entwickelt werden können. Abschließend wird auf die Visualisierung von Kennzahlen eingegangen. Dazu wird der Begriff des Steuerungscockpits eingeführt und es werden Gestaltungsregeln für die Darstellung von Kennzahlen vorgestellt. 3.1 Grundlagen Der Begriff Controlling stammt aus dem Englischen und bedeutet steuern, regeln oder lenken. Die Aufgabe des Controllings ist es, die Geschäftsleitung und andere Führungskräfte so mit Informationen bzw. Steuerungssystemen zu versorgen, dass sie potenzielle Ziele identifizieren, fundierte Entscheidungen treffen und das weitere Vorgehen planen können. Um diese Aufgabe zu erfüllen, müssen die Leistungen des Unternehmens gemessen und ausgewertet, sowie Prognosen erstellt werden. Vor allem muss viel kommuniziert werden. Es ist ausdrücklich zu betonen, dass die Verantwortung für die Zielerreichung und damit die tatsächlichen Entscheidungen immer Aufgabe des Managements bleiben. Das Controlling übernimmt lediglich die Rolle eines Lotsen, Navigators oder Beraters und stellt dem Management die benötigten Daten und Werkzeuge zur Verfügung (vgl. [Küt05]). In engem Zusammenhang mit Controlling findet sich in den letzten Jahren auch immer wieder das sogenannte Business-Intelligence (BI). Der Begriff BI wurde um 1990 von Howard Dresner geprägt. 1 Er definierte BI damals als a set of concepts and methodologies to improve decision making in business through use of facts and fact-based systems (vgl. [Wel08]). Business Intelligence wurde von Dresner stets als Sammelbegriff angesehen. Nach Dresner sind etwa query, reporting, analytics, data mining, statistical tools, analytics [and] dashboards Bestandteile von BI (vgl. [Hen07]). Ziel ist es, Erkenntnisse zu gewinnen, welche bessere operative oder strategische Entscheidungen in Hinsicht auf die Unternehmensziele ermöglichen (vgl. [Kie08]). Im Bereich der IT versteht man unter BI die Sammlung, Analyse und Auswertung von Daten in elektronischer Form mittels Softwaresystemen. 2 Im weiteren Verlauf dieser Arbeit wird der Begriff Business-Intelligence für Informationssysteme zur Unterstützung des Controllings benutzt, während der Begriff (IT)-Controlling für das allgemeine Konzept steht. 1 Die erste Erwähnung von Business Intelligence fand bereits 1958 statt (vgl. [Luh58]) 2 Beispielsweise durch Data Warehousing, Data Mining, Online Analytical Processing (OLAP) und Analytical Applications (vgl. [SDM05]). 15

26 3 IT-Controlling Warum IT-Controlling? Nach Kütz [Küt05, S. 15ff] steht das Topmanagement ständig vor vielfältigen Fragestellungen und Entscheidungen. Einige exemplarische Fragen sind etwa: Welche Services werden von den Fachabteilungen gefordert, welche sollen realisiert werden? Welche Projekte sollen durchgeführt / priorisiert werden? Wie viel Ressourcen werden einem Projekt zugeordnet? Gibt es veraltete Systeme in der IT-Landschaft? Welche Service Level Agreements (SLAs) sind definiert, wie gut werden diese eingehalten? Wie wirtschaftlich arbeitet die IT-Organisation im Vergleich zu anderen Unternehmen (Benchmarking)? Welche Leistungen werden selbst erstellt, welche kauft man von Dienstleistern zu ( Make or Buy )? Welche Risiken geht man mit einer Entscheidung ein (Risikomanagment)? Welche Kosten verursacht ein bestimmter Service (Leistungsverrechnung)? Doch auf welcher Basis beantwortet man diese Fragen und trifft Entscheidungen? Sicherlich spielt die Erfahrung eine äußerst wichtige Rolle. Doch zusätzlich möchte man kurzfristige Entwicklungen und aktuelle Daten mit in die Entscheidung einfließen lassen. Die Aufgabe des (IT-)Controllings ist es, diesen Informationsbedarf zu decken. Nach [IGC02] können die zentralen Aufgaben von Controllern wie folgt beschrieben werden: Controller sorgen für Strategie-, Ergebnis-, Finanz- und Prozesstransparenz und tragen somit zu höherer Wirtschaftlichkeit bei Controller koordinieren Teilziele und Teilpläne ganzheitlich und organisieren unternehmensübergreifend das zukunftsorientierte Berichtswesen. Controller moderieren und gestalten den Management-Prozess der Zielfindung, der Planung und der Steuerung so, dass jeder Entscheidungsträger zielorientiert handeln kann. Controller leisten den dazu erforderlichen Service der betriebswirtschaftlichen Datenund Informationsversorgung. Controller gestalten und pflegen die Controllingsysteme. 16

27 3.1 Grundlagen Einordnung im allgemeinen Controlling Nach Kütz [Küt05, S. 3] ist das IT-Controlling ein Fachcontrolling für die IT, welches innerhalb des allgemeinen Controllings oder bei entsprechend hoher Bedeutung und Komplexität der IT eigenständig betrieben wird. In beiden Fällen sollte es auf bewährte Ansätze des allgemeinen Controllings aufsetzen, damit es leicht integriert werden kann. Um seiner Zielgruppe, dem Topmanagement, den Zugang zur IT zu erleichtern, müssen etablierte Begriffe und Denkmuster verwendet werden. Nur so ist es möglich, eine Verbindung zwischen technischer und kaufmännischer Sicht herzustellen und die IT vom Kosten- in einen Leistungsfaktor zu überführen (vgl. [KM07, S. 6]) Ebenen des Controllings Wie die Beispiele auf Seite 16 schon gezeigt haben, beziehen sich die Fragestellungen, die das Controlling beantworten soll, auf ein breites zeitliches und inhaltliches Spektrum. In der Literatur wird daher zwischen operativem und strategischem Controlling unterschieden (vgl. [Hor06, S. 234], [Küt05, S. 47ff], [Tie05, S. 3], [GM06]). Operatives Controlling Beim operativen Controlling besteht die Aufgabe darin, ein System kurzfristig in einen Zielzustand zu überführen. Für diesen Zielzustand werden Sollwerte definiert, welche konstant bleiben, bis sie erreicht werden. Die Steuerung erfolgt über die Abweichung der aktuellen Istwerte von den festgelegten Sollwerten. Die Istwerte werden aus einem Kennzahlensystem gewonnen. Der Fokus beim operativen Controlling liegt auf den Faktoren Kosten, Zeit und Qualität. Strategisches Controlling Das strategische Controlling ist hingegen auf eine langfristige Planung ausgerichtet. Nach [Küt07] muss der Zielzustand des zu steuernden Systems als variabel angesehen werden. Der Sollzustand ist somit nicht fest definiert, sondern wird durch die aus der Analyse der Kennzahlen gewonnenen Erkenntnisse beeinflusst. Das strategische Controlling identifiziert mögliche Zielsetzungen und leitet aus dem aktuellen Zustand Zielerreichungsstrategien ab. Oft findet man auch die folgende Abgrenzung der beiden Controllingebenen: 3 strategisches Controlling = die richtigen Dinge tun operatives Controlling = die Dinge richtig tun In der Praxis gelingt es nicht immer eine Controllingaufgabe eindeutig dem operativen oder strategischen Controlling zuzuordnen. Auch strategisches Controlling muss operativ umgesetzt werden. Nach [Küt05, S. 52] sind die Grenzen dabei fließend. 3 Angelehnt an den bekannten Vergleich Effektivität / Effizienz von Peter F. Drucker [Dru06] 17

28 3 IT-Controlling 3.2 Kennzahlen Not everything that counts can be counted, and not everything that can be counted counts. (Albert Einstein) Wie soll man steuern, was man nicht messen kann? Wie soll man den Kurs bestimmen oder korrigieren, wenn man den Standpunkt gar nicht kennt, fragt Niemann [Nie05, S. 204] und folgert, dass das IT-Controlling zwingend auf Kennzahlen angewiesen ist. Kennzahlen (oft auch als Key Performance Indicators (KPIs) bezeichnet) beschreiben den Istzustand und stellen Abweichungen zum Sollzustand dar. In diesem Abschnitt wird zunächst allgemein definiert, was eine Kennzahl bzw. ein Kennzahlensystem ist, welche grundlegenden Anforderungen Kennzahlen erfüllen müssen und wie man Kennzahlen dokumentiert. Anschließend werden zwei Einsatzmöglichkeiten von Kennzahlen vorgestellt Begriffsdefinitionen Kennzahlen Definition: Kennzahl Eine Kennzahl ist eine Maßzahl, die zur Quantifizierung dient, und der eine Vorschrift zur quantitativen reproduzierbaren Messung einer Größe oder eines Zustandes oder Vorgangs zugrunde liegt. Quelle: (aufgerufen am ) Eine Kennzahl stellt einen Sachverhalt der Realität komprimiert als Zahl dar. Bei dieser Art der Abbildung wird die Realität bewusst vereinfacht (vgl. [Rei95, S. 19], [Hor06, S. 543]). Beispielsweise könnte man eine Kennzahl erheben, welche die Höhe eines Quaders beschreibt. Wird der Quader bearbeitet, ändert sich vielleicht seine Höhe und damit die Kennzahl. Die Kennzahl sagt aber nichts darüber aus, wie sich die Breite, Farbe oder Temperatur des Quaders geändert hat. Dieses Beispiel zeigt, dass Kennzahlen die Realität stark vereinfachen und daher mit den späteren Nutzern abgestimmt werden muss, welche Attribute sich in der Kennzahl wiederfinden sollen. Laut der Definition sollte die Messung quantitativ und reproduzierbar sein, in der Praxis findet man aber auch Kennzahlen, die durch subjektive Einschätzung erhoben werden, wenn eine objektive Messung nicht möglich ist. Kennzahlen sollen es ermöglichen, Eigenschaften von Gegenständen und Sachverhalten besser bewertbar und vergleichbar zu machen. Damit eine Kennzahl dieses Ziel erfüllt, müssen einige Voraussetzungen erfüllt werden (siehe Abschnitt 3.2.2). 18

29 3.2 Kennzahlen Kennzahlenarten Ein Beispiel für eine Kennzahl ist die Anzahl der Zeichen dieser Arbeit. Dabei muss genau definiert werden, welche Zeichen gezählt werden (z.b. Buchstaben, Satzzeichen, aber keine Leerzeichen). Eine solche Kennzahl bezeichnet man als elementare Kennzahl. Setzt man mehrere dieser Kennzahlen in Relation zueinander, erhält man eine abgeleitete oder auch zusammengesetzte Kennzahl. Beispielsweise wäre die durchschnittliche Anzahl der Zeichen pro Seite eine abgeleitete Kennzahl, welche sich aus dem Quotienten der Gesamtanzahl der Zeichen und der Gesamtanzahl der Seiten ergibt. Betrachtet man eine Kennzahl zu diskreten Zeitpunkten, erhält man eine zeitpunktorientierte Kennzahl. Betrachtet man den Verlauf der Kennzahl über einen gewissen Zeitraum hinweg, erhält man eine zeitraumorientierte Kennzahl (vgl. [Küt05, S. 181f]). Kennzahlensysteme Definition: Kennzahlensystem Ein Kennzahlensystem ist eine geordnete Gesamtheit von Kennzahlen, die in einer Beziehung zueinander stehen und so als Gesamtheit über einen Sachverhalt vollständig informieren. Quelle: [Hor06, S. 549] Da Kennzahlen auf komplexe Systeme angewandt werden, ist eine einzelne Kennzahl nicht besonders aussagekräftig. Um ein System ausreichend zu beschreiben, fasst man daher mehrere Kennzahlen zu einem abgestimmten, auf ein gemeinsames Ziel ausgerichtetes Kennzahlensystem zusammen (vgl. [Rei95, S. 23]). Kennzahlen können nach verschiedenen Kriterien zu Kennzahlensystemen gruppiert werden. Nach welchen Kriterien man Kennzahlen gruppiert, hängt davon ab wozu sie später benutzt werden sollen. Für allgemeine Berichte eignet sich die Gruppierung nach Perspektiven, für Steuerungswerkzeuge zur täglichen Arbeit bietet sich eine Gruppierung nach Nutzern und Zielen an. Einige Kriterien, nach denen man Kennzahlen gruppieren kann sind (angelehnt an [Pro04]): Nutzergruppen : Die Kennzahlen werden nach ihren Nutzern gruppiert. Beispielsweise CEO, CIO, Projektleiter, Architekt. Zielsetzung : Ein übergeordnetes strategisches Ziel wird in Teilziele aufgeteilt und die Kennzahlen nach ihrer Zugehörigkeit zu den Zielen gruppiert. Kennzahlenzusammensetzung : Bietet sich gerade im Finanzbereich an. Beispielsweise die gebräuchliche ROI-Kennzahl (Return on Investment) setzt sich aus mehreren Unterkennzahlen zusammen. 19

30 3 IT-Controlling Aktualisierungsrate : Einteilungen sind beispielsweise jährlich, quartalsweise, monatlich, wöchentlich, täglich oder stündlich. Perspektive : Gruppierung zu Finanz-, Kunden-, Prozess-, Lieferanten-, Mitarbeiter- und Innovationskennzahlen, analog der Perspektiven der BSC. Organisationsstruktur : Kennzahlen werden den einzelnen Bereichen des Unternehmens zugeordnet (Unternehmensführung, Marketing, Produktion, Vertrieb) Anforderungen an Kennzahlensysteme Kennzahlen sind ein zweischneidiges Schwert. Sie können großen Nutzen bringen oder wenn sie falsch eingesetzt werden lediglich Zeit- und Geldverschwendung sein, die Bürokratie erhöhen und somit dem Unternehmen schaden (vgl. [Pau04], [IL04]). Kennzahlen sollten nicht nur der Kennzahlen willen oder aus einer Unternehmensforderung heraus erhoben werden. Hinter einer Kennzahl sollte immer ein Ziel stehen, dessen Erreichung man misst. Zum Finden geeigneter Kennzahlen empfiehlt sich beispielsweise das Goal Question Metric -Vorgehen (GQM), siehe [BCR94]. Um sicherzustellen, dass die entworfenen Kennzahlensysteme einen qualitativen Mindeststandard erfüllen und ihre Verwendung einen Nutzen hat, sollte man Anforderungen definieren, auf welche jedes Kennzahlensystem geprüft werden kann. Einige der grundlegendsten Anforderungen sind hierbei (angelehnt an [Küt07], [Pau04], [IL04], [Pro04]): Überschaubarkeit: Das Kennzahlensystem darf weder zu umfangreich, noch zu komplex sein, damit die Kennzahlen noch interpretierbar sind. Nach Kütz haben erfolgreiche Kennzahlensysteme nicht mehr als 15 bis 25 Kennzahlen (vgl. [Küt05, S.181]). Empfindlichkeit: Änderungen des Systems, die für den Nutzer bedeutsam sind, müssen aus dem Kennzahlensystem ablesbar sein. Aktualität: Die Kennzahlenwerte müssen hinreichend aktuell sein. Zuständigkeit: Es sollte festgelegt werden, wer für die Modellierung und Wartung des Kennzahlensystems zuständig ist und wer die Kennzahlen bezüglich ihrer Aktualität, Qualität und ihrer Verwendung überwacht. Pflegeverantwortung: Falls die Daten zur Kennzahlenerhebung manuell gepflegt werden müssen, muss festgelegt werden, wer dafür zuständig ist, welche Pflegefrequenz eingehalten werden muss und welche Qualitätskriterien zu beachten sind. Steuerungshilfe: Der Kennzahlennutzer muss erkennen, wie groß die Abweichung des Istzustandes vom Idealzustand ist und wann es ratsam oder zwingend nötig ist, Steuerungsmaßnahmen zu ergreifen, um das System auf Kurs zu halten. Stellgröße: Es empfiehlt sich, zusammen mit jeder Kennzahl auch Stellgrößen zu definieren, mit deren Hilfe es möglich ist das Steuerungsobjekt gezielt zu beeinflussen. Der Kennzahlennutzer muss wissen, welche Steuerungsmaßnahmen er einsetzen muss, also wie er das System beeinflussen muss, um es auf Kurs zu halten. 20

31 3.2 Kennzahlen Dokumentation von Kennzahlen Um die wesentlichen Merkmale einer Kennzahl nicht aus den Augen zu verlieren und die Kennzahlen hinreichend zu dokumentieren, empfiehlt es sich, einen Kennzahlensteckbrief zu entwerfen. Dieser Steckbrief sollte für jede aktiv genutzte Kennzahl ausgefüllt werden. Kennzahlen, die von Nutzern gefordert, aber (noch) nicht umgesetzt werden, sollten gegebenenfalls in einer vereinfachten Form dokumentiert werden. Tabelle 3.1: Kennzahlensteckbrief nach Kütz (angelehnt an [Küt07, S.47]) Beschreibung Datenermittlung Datenaufbereitung Name Datenquellen Berechnungsweg Beschreibung Messverfahren Verantwortlicher Nutzergruppen Messfrequenz Zielwert Verantwortlicher Sollwerte Toleranzwerte Eskalationsregeln Gültigkeit Verantwortlicher Präsentation Verschiedenes Darstellung... Aggregationsstufen Archivierung Verantwortlicher Ebenso sollte ein Kennzahlensystem als Ganzes dokumentiert werden. Tabelle 3.2: Kennzahlensystemsteckbrief nach Kütz (angelehnt an [Küt07, S.49]) Beschreibung Name Zugehörige Kennzahlen Beschreibung und Abgrenzung des Steuerungsobjekts Systemverantwortlicher Steuerungsaufgabe Unterstützung der Analyse Beschreibung Wirkungsketten Ziel-, Soll-, und Toleranzwerte Abhängigkeiten und Wechselwirkungen Nutzergruppen Erfahrungen Eskalationsregeln Präsentation Die in Kapitel 7 erarbeiteten Kennzahlen bzw. das Kennzahlensystem wurden mit diesen Steckbriefen dokumentiert. 21

32 3 IT-Controlling Kennzahlensysteme in der Literatur In diesem Abschnitt wird anhand von zwei Beispielen vorgestellt, welche Konzepte und Vorschläge für den Aufbau eines Kennzahlensystems in der Literatur zu finden sind. Die Balanced Scorecard liefert dabei ein Vorgehen, um ein ausgewogenes Kennzahlensystem zu erstellen. COBIT hingegen enthält bereits eine Sammlung von Kennzahlen, die zur Steuerung von Prozessen im Bereich der IT-Goverance einsetzbar ist. Balanced Scorecard Die Balanced Scorecard (BSC) ist ein 1990 von Kaplan und Norton entwickeltes Managementsystem zur Gestaltung der Planungs-, Steuerungs- und Kontrollprozesse einer Organisation. Wie der Name schon vermuten lässt, legt die BSC Wert auf eine möglichst ausgewogene Darstellung der Unternehmensleistung. Während Unternehmen traditionell nur über Finanzkennzahlen gesteuert wurden, bezieht die BSC auch andere Perspektiven mit ein. Daraus ergeben sich verschiedene Sichten auf das Unternehmen (vgl. [KN97, S.2]). Meist sind dies: Finanzorientierte Sicht Kundenorientierte Sicht Prozessorientierte Sicht Innovationsorientierte Sicht Jede dieser Sichten enthält mehrere Ziele, die durch Ursache- und Wirkungsbeziehungen verbunden sein sollten. Nach [KN97, S.28ff] sollte das Kennzahlensystem [...] die Beziehungen (Hypothesen) zwischen Zielen (und Kennzahlen) aus den verschiedenen Perspektiven deutlich machen, damit sie gesteuert und bewertet werden können. Die Beziehungen zwischen den Zielen finden sich in der Strategie. Die vordefinierten Sichten sind aber nicht als harte Vorgabe zu sehen. Nach [KN97, S.33] sollte [man] bedenken, daß die Scorecard als Schablone und nicht als Zwangsjacke gedacht ist. Für manche Unternehmen ist es sinnvoll eine weitere Sicht, wie etwa eine Investoren-Sicht, zu definieren. Ein wichtiger Aspekt der BSC ist es, das Kennzahlensystem mit der Unternehmensstrategie zu verknüpfen. Nach Kaplan und Norton sollten die Kennzahlen auf der BSC zur Formulierung und Kommunikation der Unternehmensstrategie, sowie zur Ausrichtung persönlicher, abteilungsübergreifender und unternehmensbezogener Aktivitäten auf ein gemeinsames Ziel verwendet werden. Die BSC sollte viel mehr als Kommunikations-, Informationsund Lernsystem, und nicht als Kontrollsystem verwendet werden (vgl. [KN97, S. 24]). Die BSC liefert ein allgemeines Vorgehen, um ein auf die individuellen Ziele zugeschnittenes und ausgewogenes Kennzahlensystem zu konstruieren. Für den praktischen Einsatz müssen angepasste Sichten und Kennzahlen definiert werden. 22

33 3.2 Kennzahlen COBIT Control Objectives for Information and Related Technology (COBIT) [ITGI07] ist ein frei erhältliches Referenzmodell für IT-Governance, welches 1994 von der Information Systems Audit and Control Association (ISACA) entwickelt wurde wurde die Weiterentwicklung an das IT Governance Institute (ITGI), einer von der ISACA unabhängige Einrichtung, übergeben. COBIT basiert auf über 40 IT-Standards, Frameworks und Best Practices. Ursprünglich war es ein Werkzeug zur Auditierung von IT-Systemen, mittlerweile hat es sich aber zu einem Modell zur Steuerung der gesamten IT entwickelt (vgl. [Gol06]). Nach einer 2008 vom ITGI in Auftrag gegebenen Umfrage 4 [ITGI08] ist COBIT bei 51% der befragten Unternehmen bekannt (Umfrage 2005: 27%). Von diesen Unternehmen setzten 32% COBIT in ihrem Unternehmen ein. Insgesamt gesehen wird COBIT von 14% der befragten Unternehmen als IT-Governance Framework eingesetzt. Damit teilt es sich den dritten Platz mit ISO 9000 und selbst entwickelten Frameworks. Mit 24% ist ITIL/ISO2000 das meist eingesetzte Framework, obwohl ITIL hauptsächlich die Servicequalität betrifft und kein IT-Governance Framework im engeren Sinn ist (vgl. [ITGI08, S. 36f]). COBIT beruht auf einem Prozessmodell mit 34 Prozessen, die in vier Domänen unterteilt sind: Planung und Organisation Akquisition und Realisierung Betrieb und Support Monitoring Für jeden der 34 Prozesse ist ein Reifegrad-Modell (Maturity Model) definiert, welches den Reifegrad eines Prozesses von non-existent bis optimised einstuft. Diese Idee basiert auf dem Capability Maturity Model (CMM) des Software Engineering Institutes und wurde für COBIT angepasst. Durch das Reifegrad-Modell soll eine schrittweise Erhöhung der Leistungsfähigkeit des jeweiligen Prozesses erreicht werden. Weiterhin kann ein Vergleich der Unternehmensleistung mit Mitbewerbern (Benchmarking) stattfinden (vgl. [ITGI07]). Zu jedem Prozess sind außerdem mehrere Ziele (Goals) auf verschiedenen Ebenen definiert. Zu den einzelnen Zielen sind wiederum Kennzahlen definiert. Dabei unterscheidet COBIT 4.1 zwischen: Outcome Measures (früher Key Goal Indicators), mit denen gemessen wird, ob ein Ziel erreicht wurde. Diese Kennzahlen können erst nach Erreichen eines Ziels erhoben werden. Performance Indicators (früher Key Performance Indicators) welche messen, ob ein Ziel erreicht werden kann. Diese Kennzahlen können erhoben werden, bevor das Ziel erreicht wurde. 4 etwa 750 Teilnehmer aus 23 Ländern, 56% der befragten Unternehmen mit mehr als 1000 Mitarbeiter 23

34 3 IT-Controlling Da die Ziele aufeinander aufbauen, sind die Outcome Measures eines Ziels zugleich Performance Indicators für das übergeordnete Ziel (siehe Abbildung 3.1). Business Goal IT Goal Process Goal Activity Goal Maintain enterprise reputation and leadership. Ensure that IT services can resist and recover from attacks. Detect and resolve unauthorised access. Understand security requirements, vulnerabilities and threats. Drive Drive Drive Number of incidents causing public embarrassment Number of actual IT incidents with business Impact Number of actual incidents because of unauthorised access Frequency of review of the type of security events to be monitored Outcome Measure Outcome Measure Outcome Measure Outcome Measure Abbildung 3.1: Zusammenhang der Goals, Outcome Measures bzw. Performance Indicators in COBIT. Angelehnt an [ITGI07]. Die Outcome Measures sind Performance Indicators für die übergeordneten Goals. Auch bei COBIT enthalten viele Kennzahlen eine subjektive Bewertung. Einige Kennzahlen sind somit nur sehr schwer umsetzbar. In der Praxis sollen nicht sämtliche vorgeschlagenen Kennzahlen tatsächlich erhoben werden, sondern die Kennzahlensystematik wird durch Selektion und Erweiterung an die jeweiligen Bedürfnisse angepasst. Die in COBIT definierten Kennzahlen bewerten in erster Linie die Prozessqualität. Zur Steuerung des Unternehmensarchitekturmanagements reicht dies aber nicht aus. Es bedarf zusätzlicher individueller Kennzahlen, um die Erreichung der strategischen Ziele des EAM zu messen. In Kapitel 6 wird gezeigt, welche Kennzahlen aus COBIT sich für die Steuerung der Unternehmensarchitektur eigenen. 24

35 3.3 Controlling-Regelkreis 3.3 Controlling-Regelkreis Um IT-Controlling praktisch umzusetzen, empfiehlt es sich, einen Controlling-Regelkreis aufzubauen. Nachdem festgelegt wurde, welches System (z.b. Projekte, Prozesse oder ganze Organisationen) gesteuert werden soll und wer dafür verantwortlich ist, wird zunächst der aktuelle Istzustand und der Sollzustand beschrieben. Je nach Zielsetzung müssen geeignete Kennzahlen definiert werden, deren Aufgabe es ist, die Zielerreichung anhand des Vergleichs der Ist- und Sollwerte zu messen. Nun kann periodisch der Zustand des Systems ermittelt und mit den Sollwerten verglichen werden. Je nach Abweichung der Ist- von den Sollwerten werden geeignete Maßnahmen ergriffen, um das System in die gewünschte Richtung zu lenken (vgl. [Küt07, S. 2]). Beim strategischen Controlling können die Maßnahmen auch darin bestehen, den Zielzustand neu zu definieren und somit die Sollwerte anzupassen. Gegebenenfalls muss dabei auch das Kennzahlensystem selbst verändert werden (siehe Abbildung 3.2). Sollwerte Kennzahlensystem Analyse Maßnahmen Istwerte Controllingobjekt Abbildung 3.2: Controlling-Regelkreis nach Martin Kütz; aus [Küt07, S. 7]. Die gestrichelten Linien veranschaulichen das strategische Controlling. 25

36 3 IT-Controlling 3.4 Visualisierung von Kennzahlen Ein gut entworfenes Kennzahlensystem bietet die Basis für eine zielgerichtete Steuerung. Trotzdem sollte man sich mit reinen Zahlen noch nicht zufrieden geben. Nach Colin Ware [War04] formen Augen und das visuelle System eine massiv parallele Verarbeitungseinheit, welche die größte Quelle der menschlichen Wahrnehmung darstellt. Das menschliche Wahrnehmungssystem kann äußerst gut mit Mustern umgehen. Folglich ist es uns möglich, Informationen, die grafisch dargestellt werden, um ein Vielfaches schneller und besser zu erfassen als reine Zahlen. Jan Feb Mar Apr May Jun Jul 14,3 15,1 15,7 17,3 23,1 19,3 22,7 7,3 14,1 8,9 10,2 15,8 17, , Jan Feb Mar Apr May Jun Jul Abbildung 3.3: Zahlen und deren Visualisierung Abbildung 3.3 zeigt den Verlauf zweier Kennzahlen als Tabelle sowie als Liniendiagramm. Welche dieser beiden Darstellungen besser geeignet ist, hängt davon ab, welche Informationen man aus den Daten auslesen möchte. Wenn der historische Verlauf der beiden Kennzahlen im Vergleich von Interesse ist, so eignet sich die grafische Darstellung sehr gut. Ist dagegen nur ein Stichtagswert relevant, würde sich eine einzige Zahl besser eignen. Die exakten Zahlenwerte lassen sich besser in der Tabelle ablesen, dafür ist der Verlauf und Vergleich aufwändiger Steuerungscockpit Der Begriff Steuerungscockpit, auch bekannt als Dashboard, Management- oder Kennzahlen-Cockpit, beschreibt ein System zur Informationsaufbereitung. Es stellt die wichtigsten Informationen aus Datensammlungen auf einen Blick komprimiert bereit, ermöglicht Prognosen und erlaubt es, fundierte Entscheidungen zu treffen (vgl. [Few06, S. 34]). Ein Dashboard ist ein Werkzeug des Controllings, welches verteilte Informationen für die Endbenutzer aufbereitet. Im Gegensatz zu Reports, welche typischerweise im Halbjahresoder sogar Jahresrhythmus erstellt werden und detaillierte Daten aus einem Bereich auf vie- 26

37 3.4 Visualisierung von Kennzahlen len Seiten darstellen, ist ein Dashboard für die tägliche Arbeit konzipiert und aggregiert die wichtigsten Informationen aus unterschiedlichen Bereichen auf einer einzigen Bildschirmseite. Die Idee der Dashboards ist nicht neu. Bereits um 1980 wurden sogenannte Executive Information Systems (EIS) (Führungsinformationssysteme) entwickelt, deren Ziel es war, Finanzkennzahlen in einer einfachen Benutzeroberfläche darzustellen, die selbst die Geschäftsführung verstand. Es sollte ein Steuerungswerkzeug entworfen werden, welches analog zum Armaturenbrett eines Autos die Steuerung des Unternehmens ermöglichte. Die Umsetzung scheiterte jedoch an der damaligen Technik, die es nicht erlaubte, die benötigten Daten vollständig und zuverlässig aus unterschiedlichen Systemen zusammenzuführen. Mittlerweile ist mit Data Warehousing, OLAP und seit kurzem Business-Intelligence die nötige Technik, und dank Managementsystemen wie der BSC auch das nötige Paradigma vorhanden, um Kennzahlen aus allen Unternehmensbereichen zu sammeln und auszuwerten (vgl. [Few06, S. 6ff]). Kategorisierung von Dashboards Wie der Begriff Cockpit (angelehnt an Flugzeug-Cockpit) bzw. Dashboard (Armaturenbrett eines Fahrzeugs) nahelegt, bestehen selbige aus einer abgestimmten Kombination von Darstellungen. Über diese Gemeinsamkeit hinaus, kann man nach [Few06] verschiedene Dashboard-Typen anhand der von ihnen adressierten Aufgaben unterscheiden: Operative Dashboards stellen detaillierte und aktuelle Daten aus einem einzigen Bereich dar. Sie überwachen kontinuierlich den Status (bzw. die Einhaltung von Toleranzwerten) und melden einen auftretenden Handlungsbedarf zeitnah an den Benutzer. Ein Beispiel wäre ein Dashboard, das Statistiken eines Webservers darstellt (aktuelle Datentransferrate, CPU-Auslastung, Zustand der Festplatten) und bei Überlastung des Netzwerks oder dem Ausfall einer Festplatte einen Alarm auslöst. Analytische Dashboards beziehen historische Daten mit ein. Im Gegensatz zu operativen Dashboards, basieren sie auf einer statischen Datenbasis, die periodisch neu befüllt wird. Sie stellen Daten aus verschiedenen Bereichen dar und unterstützen so die Analyse von Zusammenhängen. Ein Beispiel wäre ein Dashboard für einen Internetshop, welches die Entwicklung der Seitenaufrufe, Anzahl der registrierten Kunden, Anzahl der verkauften Produkte und die für den Shop geschaltete Bannerwerbung über einen Zeitraum von mehreren Monaten darstellt und so die Analyse des Zusammenhangs zwischen Werbemaßnahmen und deren Wirksamkeit ermöglicht. Strategische Dashboards stellen stark aggregierte Kennzahlen aus unterschiedlichen Bereichen dar und vermitteln so einen Überblick für langfristige strategische Entscheidungen. Sie basieren ebenfalls auf einer statischen Datenbasis. Ein Beispiel wäre ein Dashboard für den Vertrieb, welches Verkaufszahlen verschiedener Produkte, den Marktanteil des Unternehmens und die Umsatzentwicklung der jeweils letzten zwölf Monate darstellt. 27

38 3 IT-Controlling Der Begriff Steuerungscockpit, wie er in dieser Arbeit verwendet wird, soll für analytische/strategische Dashboards stehen, die historische Daten aus unterschiedlichen Bereichen zusammenfassen und sinnvoll visualisieren. Ein für das Steuerungscockpit geeignetes Kennzahlensystem enthält verschiedene Sichten auf das zu steuernde System (entsprechend der Balanced Scorecard, siehe Abschnitt 3.2.4) Darstellungsformen Das Potenzial eines Steuerungscockpits liegt darin, Kennzahlen aus unterschiedlichen Bereichen kompakt darzustellen und somit mögliche Zusammenhänge erkennbar zu machen. Daher muss der Qualität der verwendeten Darstellungen besonders viel Aufmerksamkeit gewidmet werden. Zur Visualisierung werden oft Darstellungen aus dem alltäglichen Leben verwendet. Meist findet man Tachometer oder Ampeln, welche beispielsweise den aktuellen Gesundheitszustand eines Systems repräsentieren. Gerade Tachometer, mit denen man Dashboards klassischerweise auch assoziiert, sind allerdings schlecht für die Visualisierung von Informationen geeignet (vgl. [Few06, S. 53f]). Nachfolgend werden die gängigsten Darstellungsformen sowie deren Stärken und Schwächen vorgestellt. Tachometer In Abbildung 3.4 ist ein typisches Tachometer abgebildet, wie es in vielen Dashboards zu finden ist. Abbildung 3.4: Tachometer eines Dashboards (Quelle: SAP BusinessObjects) 28

39 3.4 Visualisierung von Kennzahlen Folgende Informationen kann man aus der Grafik ablesen: Es handelt sich um den Personalbestand (Headcount). Der aktuelle Wert beträgt 84,9%. Der gelb eingefärbte Zeiger weist vermutlich darauf hin, dass dieser Wert mittelmäßig zu bewerten ist. Er sagt aber nichts darüber aus, wie gut oder schlecht dieser Wert zu bewerten ist. Anhand dieser Grafik können die drei größten Probleme in Verbindung mit Tachometern veranschaulicht werden: Tachometer zeigen nur Istwerte. Es ist nicht möglich mit Tachometern den Verlauf einer Kennzahl darzustellen. Tachometer sind wie auch Kreisdiagramme schlecht dafür geeignet, eine Größe grafisch darzustellen. Dies liegt daran, dass Menschen Flächen und Winkel nicht sehr präzise vergleichen können. Eine Bessere Lösung sind Balkendiagramme, bei welchen eine gerade Skala verwendet wird und somit Längen verglichen werden. Tachometer verschwenden viel Platz um einen einzigen Zahlenwert abzubilden. In Abbildung 3.5 ist die gleiche Information um ein vielfaches kompakter dargestellt. Headcount: 84,9% Abbildung 3.5: Information des Tachometers kompakt dargestellt Ein weiteres Problem, welches speziell auf das Tachometer in Abbildung 3.4 zutrifft, betrifft die Einteilung der Skala. In Zusammenhang mit Prozentwerten ist die 100%-Marke von besonderem Interesse, schließlich bezieht sich jeder Prozentwert per Definition auf das Ganze. Das Tachometer hilft uns in diesem Fall nicht einen Bezug zu den 100% herzustellen. Selbst der Versuch die 100%-Marke durch Rechnung zu ermitteln schlägt fehl. Die 100%-Marke liegt wahllos zwischen den angezeigten Hilfsstrichen (von denen jeder für 3.75% steht). Dieses Tachometer verwirrt mehr, als es zur Veranschaulichung der Kennzahl beiträgt. Eine bessere Verwendung von Tachometern ist in Abbildung 3.6 dargestellt. Hier ist deutlich zu erkennen, dass die Einnahmen (Revenue) weit im grünen Bereich liegen, also die Erwartungen sogar übertroffen wurden. Zudem hat die Skala eine Bedeutung: jeder lange Strich steht für 1.000$. 29

40 3 IT-Controlling Abbildung 3.6: Verbessertes Tachometer (Quelle: SAP BusinessObjects) Die Darstellung lässt sich aber noch weiter optimieren. So lässt sich der verwendete Platz reduzieren, indem man statt dem kreisförmigen Tachometer einen sogenannten Bullet Graph 5 einsetzt, wie es Stephen Few [Few06, S. 125ff] vorschlägt (siehe Abbildung 3.7). Zusätzlich kann ein Vergleichswert angezeigt werden. Revenue (U.S. $ in thousands) Hintergrundfarben zeigen Qualitätsintervalle (schlecht, mittelmäßig, gut) 9, Balken der den Ist-/ Kennzahlenwert anzeigt Vergleichs-/ Zielwert quantitative Skala Abbildung 3.7: Bullet-Graph angelehnt an [Few06, S. 126]) Ampeln Ampeldarstellungen in Dashboards werden dazu verwendet, den Wert einer Kennzahl zu bewerten. Dazu werden zu einer Kennzahl Intervalle definiert, in denen die Ampel grün, gelb oder rot anzeigt. Zeigt die Ampel gelb oder gar rot an, liegt die Kennzahl außerhalb der Toleranzgrenze und es besteht an dieser Stelle ein Handlungsbedarf. Stellt man Ampeln wie in Abbildung 3.8 dar, ergeben sich die gleichen Probleme wie bei Tachometern: viel Platz wird für wenig Information verschwendet. Sinnvoller ist es, wie schon in Abbildung 3.5 gezeigt, die Darstellung auf den wesentlichen Inhalt die Ampelfarbe zu reduzieren. 5 Eine ausführliche Spezifikation und Dokumentation des Bullet-Graph findet man bei [Few08a]. 30

41 3.4 Visualisierung von Kennzahlen Qualität Betriebskosten Gesundheitszustand Abbildung 3.8: Dekorative Ampeldarstellungen Ampeldarstellungen werden auch dazu verwendet, den Status von mehreren Kennzahlen zusammenzufassen. Wie in Abbildung 3.9 dargestellt, muss man entscheiden, wie die oberste Ampelfarbe definiert wird. Eine Möglichkeit wäre es, den Durchschnittswert der Kennzahlen zu berechnen und die oberste Ampel auf diesen Durchschnittswert zu beziehen. Für das Beispiel in Abbildung 3.9 hieße dies, dass die oberste Ampel orange oder grün anzeigen würde. Dieses Vorgehen widerspricht aber dem Grundgedanken der Ampeln. Eine rote Ampel signalisiert immer einen akuten Handlungsbedarf und muss daher nach oben durchgereicht werden. Nur so wird der Nutzer der nur die oberste Ampelfarbe sieht darauf aufmerksam, dass er handeln muss. Gesundheitszustand? Kosten Nutzerzufriedenheit Ausfallzeit Auslastung Abbildung 3.9: Zusammenfassen von Ampeln Sparklines Tachometer und Ampeln zeigen nur den aktuellen Wert einer Kennzahl an (zeitpunktorientierte Kennzahlen). Meist ist aber auch der zeitliche Verlauf einer Kennzahl von großem Interesse (zeitraumorientierte Kennzahlen). Er bietet einen Kontext für den aktuellen Kennzahlenwert und ermöglicht Entwicklungen nachzuvollziehen und Prognosen zu erstellen. In Abbildung 3.10 ist eine einfache Version einer Sparkline dargestellt. Die Sparkline wurde mit einer Ampeldarstellung kombiniert, welche den aktuellen Status bewertet. 31

42 3 IT-Controlling Okt 08 Feb Ausfälle / Monat Abbildung 3.10: Sparkline nach Tufte Sparklines wurden von Edward R. Tufte entwickelt (vgl. [Tuf06]). Tufte beschreibt Sparklines als intense, simple, word-sized graphics. Im Gegensatz zu einem klassischen Liniendiagramm fehlen bei Sparklines die Achsen und Skalen. Es ist daher nicht möglich zu einem gewählten Zeitpunkt den passenden Wert abzulesen. Dies ist aber auch nicht nötig, denn der Zweck von Sparklines ist es lediglich, einen schnellen Eindruck der Kennzahlenentwicklung zu vermitteln, der die Bedeutung des aktuellen Werts anreichert. Klassische Darstellungsformen Auch klassische Darstellungsformen wie Kreis-, Balken- und Liniendiagramme eignen sich für die Darstellung von Kennzahlen in Dashboards. Der einzige Anwendungsfall für Kreisdiagramme ist die Darstellung von Verteilungen. Ein Kreisdiagramm setzt immer voraus, dass es sich um Teile eines Ganzen handelt. Der Kreis muss insgesamt immer 100% ergeben. Nach [Few06, S.151] sollte man Kreisdiagramme aber generell vermeiden, da sie schwieriger zu lesen sind als Balkendiagramme (siehe hierzu Abbildung 3.11). Abbildung 3.11: Darstellung von Daten mittels Kreis und Balkendiagramm aus [Few08b] Balkendiagramme heben durch ihre Darstellung die Größe der einzelnen Werte hervor und ermöglichen es, ausgewählte Werte individuell miteinander zu vergleichen, indem die Höhe der Balken verglichen wird. Liniendiagramme dagegen, heben die gesamtheitliche Form der Werte hervor. Durch die Verbindung der einzelnen Werte, wird der Zusammenhang zwischen einem Wert und seinem Vorgänger und Nachfolger veranschaulicht. Liniendiagramme dürfen daher nur verwendet werden, wenn dieser Zusammenhang auch tatsächlich besteht. 32

43 3.4 Visualisierung von Kennzahlen Dies ist nur bei Intervallskalen der Fall. Intervallskalen sind in gleich große Abschnitte aufgeteilte Zahlenbereiche, die eine natürliche Reihenfolge besitzen. Die meist genutzten Intervallskalen sind Zeiträume (Januar, Februar, März; Q1, Q2, Q3, Q4; 2007, 2008, 2009). Abbildung 3.12 zeigt auf der linken Seite den Kostenverlauf über sieben Jahre (Intervallskala). Auf der rechten Seite wurden Kosten zu Geschäftsbereichen zugeordnet (Ordinalskala). Das Liniendiagramm suggeriert hier einen Zusammenhang der Kosten, die sich von A über B über C nach D entwickeln müssten. Da dieser Zusammenhang aber nicht vorhanden ist, ist diese Darstellung irreführend. Ein Balkendiagramm wäre hier passender. 25 Kosten in Kosten je Geschäftsbereich in A B C D Abbildung 3.12: Richtiger und falscher Einsatz von Liniendiagrammen Gestaltungsregeln Selbst wenn man auf Tachometer, Ampeln und andere rein dekorative Elemente wie glänzende Metalloberflächen verzichtet, gibt es noch einige weitere Regeln zur Erstellung hochwertiger Visualisierungen zu beachten. In [Tuf01] stellt Edward R. Tufte sein Konzept des data-ink ratio (Verhältnis von Daten zu Tinte) vor. Dies besagt, das die in einer Grafik verwendete Tinte zu einem großen Teil Daten darstellen sollte. Daten-Tinte ist der wesentliche Anteil der Grafik, welcher sich ändert, wenn die zugrundeliegenden Daten verändert werden. Das data-ink ratio ist somit Daten-T inte Gesamte T inte der Grafik Nach Tufte sollte man versuchen das data-ink ratio zu erhöhen, solange dies sinnvoll ist. Viele weitere Gestaltungsregeln basieren auf diesem Konzept. Anhand der folgenden Überarbeitung eines Diagramms werden die wichtigsten Regeln der Gestaltung kurz Stichpunktartig aufgezählt. Die Grafiken stammen von Rolf Hichert [Hic07a]. In Abbildung 3.13 ist ein Diagramm zu sehen, wie man es aus den gängigen Tabellenkalkulationsprogrammen kennt. Dargestellt werden 3D-Balkendiagramme, welche die Entwicklung des Nettoumsatzes zweier Geschäftsstellen veranschaulichen. 33

44 3 IT-Controlling Geschäftsbereich Food Nettoumsatz Belgien (Mio. ) Geschäftsbereich Food Nettoumsatz Schweiz (Mio. ) Mio EUR ,23 19,91 Mio EUR 18, ,51 9, , (P) 0 10,36 7, (P) Abbildung 3.13: Standard Excel Diagramm mit 3D-Effekt aus [Hic07a] Im ersten Überarbeitungsschritt wurden die unnötigen Dekorationen entfernt. Die dritte Dimension der Balken, die keinerlei Information beinhaltete, wurde entfernt und die verwendeten Farben wurden auf das wesentliche reduziert. Auf Dekorationen wie den eingefärbten Hintergrund, eingerahmte Textfelder und schattierte Flächen wurde ebenfalls verzichtet. Da die Zahlenwerte an den Balken direkt angezeigt werden, sind die Hilfslinien der Y-Achse ebenfalls überflüssig. Das Ergebnis ist in Abbildung 3.14 zu sehen. Geschäftsbereich Food Nettoumsatz Belgien (Mio. ) Geschäftsbereich Food Nettoumsatz Schweiz (Mio. ) Mio EUR Mio EUR 20 19,23 19, ,51 18, ,92 10, , , (P) (P) Abbildung 3.14: Diagramm ohne Dekoration aus [Hic07a] Auch in dem überarbeiteten Diagramm in Abbildung 3.14 findet sich noch überflüssige Tinte. Redundante Beschriftungen können zusammengefasst werden. Die Beschriftung der Diagramme unterscheidet sich lediglich durch den Namen des Standorts. Der Standortname wird beibehalten, die restlichen Informationen zentral und einmalig angezeigt. Die Y-Achse und deren Beschriftung kann ebenfalls entfernt werden, da aus der Beschreibung hervorgeht um welche Größe es sich handelt und die Balkenhöhe direkt angegeben wird. Die Farben der Balken hatten keine eigene Bedeutung, die Abgrenzung der beiden Diagramme ist durch die räumliche Anordnung bereits leicht möglich, daher kann auf diese Einfärbung ebenfalls verzichtet werden. Die X-Achse wurde zusätzlich eingefärbt, um zu veranschaulichen, ob die dargestellten Daten sich auf historische Werte oder Prognosen beziehen. Ob die Umsatzzahlen auf zwei, eine oder keine Nachkommastelle gerundet werden muss individuell entschieden werden. Da mit der Grafik aber generell ein eher grober Überblick über die Entwicklung des Umsatzes gegeben werden soll, ist es durchaus sinnvoll die Werte auf ganze Zahlen zu runden. Das Ergebnis des fertig verbesserten Diagramms ist in Abbildung 3.15 dargestellt. 34

45 3.4 Visualisierung von Kennzahlen GB Food Nettoumsatz in Mio. Euro Belgien Schweiz BUD Abbildung 3.15: Verbessertes DiagrammÖsterreich aus [Hic07a] Der Informationsgehalt ist (bis auf die gerundeten Zahlen) identisch mit Abbildung Die klare Struktur der Darstellung ermöglicht es dem Betrachter, die enthaltene Information leicht abzulesen, ohne dabei durch Dekorationen vom eigentlichen Inhalt abzulenken. In [Hic07b] 6 finden sich noch viele weitere konkrete Tipps für die Erstellung von Berichten, Präsentationen und Dashboards. 6 Weiteres Material findet man unter 35

46 36

47 4 Steuerung der Unternehmensarchitektur Unternehmensarchitektur muss nicht nur definiert und geplant, sondern vor allem auch gelebt, gesteuert und umgesetzt werden. Dazu bedarf es definierter Prozesse und Werkzeuge, die eine professionelle Steuerung der Unternehmensarchitektur ermöglichen. Verbreitete Methoden zur Steuerung sind die Erhebung und Auswertung von Kennzahlen (vgl. [Nie05, S. 197ff], [Lan08], [Han09, S. 277ff]). In diesem Kapitel wird gezeigt wie das Unternehmensarchitekturmanagement und das Controlling zusammenarbeiten, welche Nutzer involviert sind und welche Aufgaben typischerweise zu steuern sind. Anschließend wird ein Prozess zur Konstruktion von Kennzahlen vorgestellt. 4.1 Zusammenspiel Unternehmensarchitekturmanagement und Controlling Ein Ziel des EAM ist es, das Business-Alignment der IT zu erhöhen. Die IT soll an den Geschäftsanforderungen ausgerichtet werden. Nach [Lan08] kann man sich diesem Ziel aus zwei Richtungen nähern: Das bereits im Unternehmen bestehende Controlling wird auf die IT ausgeweitet und definiert Kennzahlen, um den aktuellen Beitrag der IT zu messen und zu steuern. Man beginnt aus einer betriebswirtschaftlichen Perspektive. Das EAM wird größtenteils aus der IT-Abteilung heraus initiiert (vgl. [MLBEon]), um Transparenz zu schaffen, die Rolle der IT im Unternehmen herauszuarbeiten und das Zusammenspiel zwischen IT und Geschäftsanforderungen zu fördern. Um dieses Ziel möglichst effizient zu erreichen, sollte man beide Ansätze kombinieren. Dabei ist darauf zu achten, dass man nicht unabhängig von zwei Seiten bohrt, ohne sich in der Mitte zu treffen. Die Fachabteilung für Unternehmens-Controlling und die Verantwortlichen des EAM müssen ihre Ziele kommunizieren, und sich gegenseitig mit ihrem Fachwissen unterstützen. Einordnung des IT-Bebauungsmanagements innerhalb des IT-Controllings Das IT-Bebauungsmanagement und das IT-Controlling sollten eng zusammenarbeiten. Ihr gemeinsames Ziel muss es sein, die IT-Strategie in die IS-Bebauung umzusetzen. Das strategische IT-Controlling benötigt Informationen zum Istzustand der Informationssystembebauung, welche im IT-Bebauungsmanagement zu finden sind. Mit Hilfe der Werk- 37

48 4 Steuerung der Unternehmensarchitektur zeuge des Controllings werden diese Informationen analysiert und anhand der Ziele aus der IT-Strategie ein Sollzustand erstellt. Auch der Sollzustand wird innerhalb des IT-Bebauungsmanagements modelliert. Da der Sollzustand sehr langfristig ausgelegt und eher schemenhaft ist, werden Planzustände definiert, die sich dem Sollzustand schrittweise annähern. Dieser gesamte Vorgang findet nicht nur einmal, sondern kontinuierlich statt. Falls es die Umstände erfordern, definiert das strategische Controlling die Ziele und die Strategie neu. Beim operativen Controlling hingegen, ist das Ziel und die Art der Umsetzung bereits fest definiert (in Form eines konkreten Planzustandes, der zeitnah erreicht werden kann). Das operative Controlling steuert die Umsetzung, indem es Messungen vornimmt und gegebenenfalls Maßnahmen vorschlägt, um das Ziel optimal zu erreichen (siehe Abbildung 4.1). Für eine Abgrenzung zwischen operativem und strategischem Controlling siehe auch Abschnitt IT-Strategie beeinflusst gibt Ziele vor ändert Operatives IT-Contolling basiert auf Strategisches IT-Contolling analysiert plant IS-IST IS-PLAN IS-PLAN IS-SOLL steuert geplante Zustände IT-Bebauungsmanagement Informationssystem-Architektur Unternehmensarchitektur strategisch operativ Abbildung 4.1: Zusammenspiel von IT-Controlling und IT-Bebauungsmanagement 38

49 4.2 Nutzer und Sichten 4.2 Nutzer und Sichten Nach [Han09, S. 295] kann man zwischen drei wesentlichen Sichten auf das strategische Management der IT-Landschaft unterscheiden: Sicht der Unternehmensführung Sicht der Fachbereiche Sicht der IT Diese grundsätzlichen Sichten lassen sich weiter auf einzelne Rollen und deren konkrete Zielsetzungen aufteilen (siehe Abbildung 4.2). Um eine effektive Steuerung sicherzustellen, muss für jede Rolle identifiziert werden, welche Steuerungsaufgaben vorhanden sind und anschließend ein maßgeschneidertes Steuerungswerkzeug erstellt werden. Unternehmensarchitekturmanagement Unternehmensführung CEO Fachbereichs- Vorstand Stratege IT CIO IS-Bebauungsplaner Fachbereichs- Verantwortlicher Fachbereich IT-Architekt IS- Verantwortlicher Fachlicher Bebauungsplaner Sicht Rolle Abbildung 4.2: Sichten und exemplarische Rollen im Bereich der Steuerung der Unternehmensarchitektur 39

50 4 Steuerung der Unternehmensarchitektur 4.3 Steuerungsebenen und -aufgaben Für eine fundierte Steuerung der Unternehmensarchitektur muss nach [Han09] die operative, strategische und fachliche Ebene einbezogen werden (siehe Abbildung 4.3). Nur so ist es möglich, einen Überblick über der Gesamtsituation zu erlangen. fachliche Steuerung strategische IT-Steuerung operative IT-Steuerung Abbildung 4.3: Steuerungs-Ebenen aus [Han09, S. 280] Je nach Steuerungsaufgabe werden Informationen aus unterschiedlichen Ebenen benötigt. Mögliche Steuerungsaufgaben sind nach [MLBS09] und [Han09] unter anderem: Überwachen der Auswirkungen, die sich aus Änderungen an der Applikationslandschaft ergeben Entscheidungshilfe bei der Auswahl von alternativen Lösungen Definition von Zielen und Bewertung der Zielerreichung IT-Kostensteuerung Identifikation von Bereichen, die unterstützende Maßnahmen wie Reviews benötigen operative IT-Steuerung Kosten SLA-Erfüllung 40

51 4.4 Entwicklung eines Kennzahlensystems strategische IT-Steuerung Kosten Nutzen Strategie- und Wertbeitrag Gesundheitszustand Standardkonformität Die hier genannten Aufgaben stellen nur einen Ausschnitt der insgesamt möglichen Aufgaben dar. Für die Steuerung dieser Aufgaben werden angepasste Kennzahlen benötigt. Die einzelnen Kennzahlen werden zu einem abgestimmten Kennzahlensystem zusammengefasst, welches in komprimierter Weise über den gesamten Bereich der Steuerungsaufgabe informiert. Im nachfolgenden Abschnitt wird ein Prozess zur Entwicklung von Kennzahlen vorgestellt. 4.4 Entwicklung eines Kennzahlensystems Zur Erstellung eines Kennzahlensystems gehört vor allem, mit den Nutzern zu klären, welche Kennzahlen zur Steuerung erforderlich sind und welche Kennzahlen die Nutzer bei ihren Aufgaben wirksam unterstützen. Dieser Klärungsaufwand ist laut Kütz erheblich und wird in der Praxis meist unterschätzt (vgl. [Küt07, S. 46]). In der Praxis bleiben Kennzahlensysteme zudem nicht konstant, sondern unterliegen ständig neuen Anforderungen und müssen daher kontinuierlich weiterentwickelt werden (vgl. [KM07, S. 26]). In diesem Abschnitt wird zunächst das grundsätzliche Vorgehen und ein möglicher Prozess zur Entwicklung geeigneter Kennzahlen beschrieben. Zur Übersicht über den Entwicklungsprozess siehe auch Abbildung 4.5 auf Seite Grundsätzliches Vorgehen Bei der Erstellung eines Kennzahlensystems kann grundsätzlich auf zwei Arten vorgegangen werden: Bottom-Up Top-Down Beim Bottom-Up-Ansatz wird untersucht, auf welche vorhandenen Daten des Unternehmens bereits leicht zugegriffen werden kann (z.b. aus ERP-, CRM-, CMDB-Systemen, etc.). Diese Daten werden dann in Kennzahlen gegossen und zu einem Kennzahlensystem zusammengefasst. Auf diesem Wege erhält man relativ schnell operative Kennzahlen, es besteht aber die Gefahr, dass die erfassten Messgrößen und die dadurch beantworteten Fragen nicht die sind, die vom Management zur Steuerung benötigt werden (vgl. [Com08]). 41

52 4 Steuerung der Unternehmensarchitektur Beim Top-Down-Ansatz sind die Anforderungen der Nutzer und die Festlegung der aus der Strategie abgeleiteten Ziele der Startpunkt. Davon ausgehend werden geeignete Kennzahlen konstruiert. Die Identifikation der Datenquellen ist hier einer der späteren Schritte. Gegebenenfalls müssen auch neue Daten erhoben und zukünftig gepflegt werden, um den Informationsbedarf der Nutzer zu decken. Dabei ist zu beachten, dass das Kennzahlensystem insgesamt wirtschaftlich bleibt. Der Nutzen muss höher sein, als der zur Erhebung der Kennzahlen benötigte Aufwand (siehe auch Abbildung 6.1 auf Seite 63 zur Kategorisierung der Daten). Daher findet auch beim Top-Down-Ansatz eine Phase statt, in der die bereits im Unternehmen befindlichen Daten inventarisiert werden. Bei der Konstruktion der Kennzahlen wird dann auf diesen Kennzahlen-Katalog zurückgegriffen. In der Literatur wird empfohlen, bei der Konstruktion von strategischen Kennzahlen Top- Down vorzugehen (vgl. [Küt07], [BCR94], [IL04]). Auch bei den gebräuchlichen Managementsysteme wie der BSC oder der COBIT-Kennzahlensystematik stehen an erster Stelle die Ziele, und damit die Strategie. Basierend auf der Strategie wird die Frage gestellt: Woran lässt sich messen, ob wir auf dem richtigen Weg sind, die strategischen Ziele zu erreichen? Aus diesen Messgrößen, und nur daraus ergeben sich dann die entsprechenden Kennzahlen (vgl. [Pau04]). Die Entscheidung Top-Down vorzugehen, muss nicht nur einmal zu Beginn getroffen werden, sondern es muss ständig überprüft werden, ob man sich noch auf dem richtigen Kurs befindet, die Kennzahlen einem höheren Ziel dienen und man nicht dazu übergegangen ist einen Zahlenfriedhof zu erschaffen Prozess der Entwicklung Kennzahlen, die allgemein gebräuchlich sind, gibt es nur selten. Dies liegt daran, dass die zugrundeliegenden Daten vom jeweiligen Unternehmen und dessen Prozessen abhängen. In der Literatur findet man zum einen fertige Kennzahlensysteme (z.b. in COBIT), welche aber noch an die individuellen Anforderungen angepasst und erweitert werden müssen, und zum anderen Konzepte und Vorschläge zur Erstellung und zum Aufbau eines Kennzahlensystems (z.b. die BSC). Detaillierte Hinweise zur Entwicklung von Kennzahlen findet man bei [Küt07, S. 41ff]. Wie bereits im vorigen Abschnitt erläutert, sollte man möglichst Top-Down vorgehen. Dazu ist es hilfreich, wenn man sich die Frage stellt: Welche Ziele sollen erreicht werden und wie kann die Zielerreichung durch Kennzahlen gesteuert werden?. Welche Ziele sollen erreicht werden? Um herauszufinden, welche Ziele im Bereich des Unternehmensarchitekturmanagements erreicht werden sollen, ist einiges an Vorarbeit nötig. Zunächst muss eine Unternehmensstrategie erarbeitet werden, aus der dann eine IT-Strategie abgeleitet wird. Parallel dazu lässt sich bereits mit der Dokumentation der Ist-Architektur beginnen. Anschließend wird die Ist-Architektur anhand der IT-Strategie analysiert. Nun lassen sich konkrete Ziele in Form von Plan-Zuständen modellieren. 42

53 4.4 Entwicklung eines Kennzahlensystems Im Bereich des IT-Bebauungsmanagements finden sich verschiedene Ziele. Einerseits ist es ein Ziel, das IT-Bebauungsmanagement selbst zu etablieren. Im IT-Bebauungsmanagement finden sich dann konkrete Ziele in Form von Plan- Zuständen, die mittels Architekturprojekten erreicht werden sollen. Konkrete Ziele sind hier die Bebauung zu konsolidieren, die Anzahl der verwendeten Technologien zu reduzieren oder die Betriebskosten der Infrastruktur zu senken. Ein weiteres Ziel ist es, die Auswirkungen einer Änderung der IT-Bebauung einschätzen und später nachvollziehen zu können. Das übergeordnete Ziel des IT-Bebauungsmanagements ist es, die Ziele aus der IT- Strategie umzusetzen. Detailliertere Ziele sind je nach Unternehmen und Nutzergruppe sehr unterschiedlich. Betrachten wir zur Veranschaulichung ein konkretes Beispiel: Die Geschäftsführung formuliert das strategische Ziel, die Kundenzufriedenheit auf 80% zu erhöhen. Dieses Ziel wird wiederum in konkretere Unterziele aufgeteilt. Zum Beispiel wird festgestellt, dass die Kunden hauptsächlich mit dem Callcenter unzufrieden sind. Die veraltete Kundenmanagementsoftware des Callcenters, die nachweislich zu langen Wartezeiten der Kunden führt und aufgrund der veralteten Programmiersprache nur noch schlecht weiterentwickelt und gewartet werden kann, soll daher durch eine neues System ersetzt werden. Für dieses Vorhaben wird der IT-Vorstand als Verantwortlicher festgelegt. Nach einer Analyse der Ist-Situation wird vom Bebauungsplaner die Ablösung des Altsystems und die Einführung des neuen Systems geplant. Da das Unternehmen sich auch das Ziel gesetzt hat, die Anzahl der verwendeten Technologien zu reduzieren, wird festgelegt, dass die neue Software auf Standard-Bausteine aufsetzen soll (Programmiersprache X, Datenbank Y, Schnittstellen mittels Z). Es wäre zusätzlich wünschenswert, wenn die Betriebskosten des neuen Systems unter den Betriebskosten des Altsystems liegen. Folgt man dem Vorschlag der Balanced Scorecard, so entwickelt man ein Kausalmodell mit Zielen, die sich gegenseitig beeinflussen oder direkt voneinander abhängen (siehe dazu Abbildung 4.4 auf Seite 44). Man sollte aber verhindern simple Zusammenhänge wie Die Kundenzufriedenheit zu steigern erhöht den Umsatz einfach zu übernehmen, da es viele Situationen gibt, in denen diese Zusammenhänge nicht zutreffen. Vielmehr sollten durchdachte Hypothesen erstellt und anschließend überprüft werden (vgl. [IL04]). Wie kann die Zielerreichung durch Kennzahlen gesteuert werden? Um die Erreichung dieser Ziele zu steuern, werden geeignete Kennzahlen erstellt. Kennzahlen lassen sich leider nicht analytisch ableiten sondern müssen mühevoll konstruiert werden (vgl. [Küt07, S. 52]). Da die Nutzer des Steuerungscockpits und damit der Kennzahlen wahrscheinlich nicht damit vertraut sind, wie man gute Kennzahlen entwirft aber sehr wohl wissen welche Informationen sie zum Steuern ihres Systems benötigen, setzt die Konstruktion von Kennzahlen eine enge Zusammenarbeit zwischen Nutzern und dem (IT-)Controlling voraus. 43

54 4 Steuerung der Unternehmensarchitektur Business Goal Kundenzufriedenheit auf 80% erhöhen IT Goal Kundenzufriedenheit im Bereich Callcenter erhöhen zusätzliche Internetservices Process Goal Kundenmanagement-System verbessern und erneuern Infrastruktur-HW erneuern Activity Goal Mitarbeiterschulungen Entwicklung neues Kundenmanagement- System Datenbanküberlastungen vermeiden Abbildung 4.4: Beispielhaftes Kausalmodell In unserem Beispiel bestehen aus der Sicht des IT-Vorstands einige Ziele. Als übergeordnetes Ziel soll die Kundenzufriedenheit erhöht werden. Etwas konkreter soll die Zufriedenheit mit dem Callcenter verbessert werden. Als Maßnahme dafür soll die Kundenmanagementsoftware erneuert werden. Nehmen wir an, dass die Kundenzufriedenheit halbjährlich durch Umfragen ermittelt und dann als Kennzahl ins Unternehmenscontrolling weitergeleitet wird. Die Zielerreichung kann mit dieser Kennzahl zwar gemessen, aber nicht gesteuert werden. Die Kundenzufriedenheit-Kennzahl zeigt lediglich an, ob das Ziel erreicht wurde (Nach COBIT wäre diese Kennzahl ein Outcome Measure). Was besser gesteuert werden kann, sind die Maßnahmen, die zur Erreichung dieses Ziels führen sollen. Man arbeitet sich nach unten vor. In unserem Beispiel wäre dies unter anderem die Ablösung der Kundenmanagement-Software des Callcenters. Um diese Zielerreichung zu messen, werden konkrete Kennzahlen formuliert. Dabei kann man zwischen zwei Arten unterscheiden. Einerseits gibt es operative Kennzahlen, die anzeigen wie weit die Umsetzung des neuen Systems fortgeschritten ist (Projektfortschrittsgrad). Andererseits sollte man strategische Kennzahlen definieren, welche überprüfen, ob die kausalen Zusammenhänge der Ziele tatsächlich real existieren. Für unser konkretes Beispiel heißt das, dass man überwacht, ob die Verbesserung der Kundenmanagement- Software tatsächlich die Zufriedenheit der Kunden mit dem Callcenter erhöht. 44

55 4.4 Entwicklung eines Kennzahlensystems Der IT-Vorstand fordert beispielsweise folgende Kennzahlen: Fertigstellungsgrad Neusystem, Tests, Datenmigration, etc. Anzahl offener Anforderungen/Bugs im Tracker der Softwareentwickler Betriebskosten Wartungskosten Gesundheitszustand Kundenzufriedenheit mit dem Callcenter Anteil an verwendeten Technologien, die nicht zum Firmenstandard gehören Anteil von Anfragen, die sich durch Überlastung des Netzwerks / Datenbankservers verzögern In COBIT wären diese Kennzahlen Performance Indicators für das übergeordnete Ziel. Kennzahlen wie Betriebskosten, Wartungskosten, etc. sollten schon möglichst früh auf das Altsystem angewandt werden, um einen realistischen Verlauf und Vergleich mit dem Neusystem zu ermöglichen (Wartungskosten für Alt-/Neusystem werden im Migrationszeitraum extreme Werte annehmen). Die geforderten Kennzahlen, sind speziell auf die Fragestellungen des IT-Vorstands ausgerichtet. Zusätzlich berücksichtigen sie ein spezielles Informationssystem über einen gewissen Zeitraum. Doch auch hier gilt es, sich auf die wichtigsten Kennzahlen zu beschränken und so das Kennzahlensystem möglichst überschaubar zu halten. Umsetzung der Kennzahlen in ein Kennzahlensystem Der Tacho darf nicht teurer werden als der Motor! (Klaus D. Niemann; [Nie05, S. 210]) In unserem Beispiel besteht die Forderung nach sehr speziellen Kennzahlen. Für andere Nutzergruppen sind andere Ziele von Interesse und daher werden von ihnen auch andere Kennzahlen gefordert. Der Chief Executive Officer (CEO), der sich einen Überblick über die Kundenzufriedenheit bezogen auf das gesamte Unternehmen machen will, wird sich mit den spezialisierten Kennzahlen aus unserem Beispiel nicht zufrieden geben. Einige Kennzahlen findet man aber bei fast allen Nutzergruppen. Sämtliche Kennzahlen, die von den Nutzern gefordert werden, sollten dokumentiert werden (z.b. mittels Kennzahlensteckbriefen vgl. Abschnitt 3.2.3). Die Aufgabe der Controlling-Abteilung ist es, zu prüfen, ob und wie die geforderten Kennzahlen umgesetzt werden können. Dazu wird kalkuliert, welche Kosten die Erhebung der Kennzahlen verursacht und ob der gewonnene Nutzen diese Kosten rechtfertigt. Manche Kennzahlen können aus bereits im Controlling vorhandenen Daten erstellt werden. Andere Daten müssten erst extrahiert und übertragen werden. Je nach Quellsystem 45

56 4 Steuerung der Unternehmensarchitektur kann dies sehr aufwändig sein. Ist das Bugticket-System beispielsweise noch nicht mit dem Controlling verbunden, so wird es wahrscheinlich nicht wegen einer einzigen Kennzahl, die nur für einen speziellen Nutzer interessant ist, mit großem Aufwand angebunden werden. Trotzdem sollte diese Anforderung dokumentiert werden (z.b. in Form eines gekürzten Kennzahlensteckbriefs). Fordern anschließend weitere Nutzer Kennzahlen an, die Daten aus dem Bugticket-System verwenden, so kann erneut kalkuliert werden, ob die Anbindung wirtschaftlich umsetzbar ist. Wie viele Nutzer eine Kennzahl anfordern, sagt aber noch nichts darüber aus, ob diese Kennzahl tatsächlich einen Nutzen bringt. Der Vergleich von Erhebungsaufwand und Nutzen muss daher für jede Kennzahl durchgeführt werden. Eine weitere Aufgabe bei der Erstellung eines Kennzahlensystems besteht darin, die Kennzahlen unternehmensweit zu normieren und somit zu verhindern, dass Äpfel mit Birnen verglichen werden. Eine Kennzahl, die Gesamtkosten von System A misst, sollte ebenso aufgebaut sein wie eine Kennzahl, welche Gesamtkosten von System B misst. Nur dann ist ein späterer Vergleich oder eine Kumulierung der Kennzahlen sinnvoll. Der Kennzahlenverantwortliche muss auch sicherstellen, dass das entstehende Kennzahlensystem inhaltlich vollständig, in sich stimmig und ausgeglichen ist. Es ist auch darauf zu achten, dass nicht nur einseitige Kennzahlen aus einem Bereich, sondern möglichst mehrere Sichten auf die Steuerungsaufgabe betrachtet werden (analog zum Konzept der Balanced Scorecard). Generell soll verhindert werden, dass Kennzahlen den Nutzern vom Controlling aufgedrückt werden, die Fachkenntnis und Erfahrung der Controlling-Abteilung soll aber durchaus in die Kennzahlensysteme einfließen. 46

57 4.4 Entwicklung eines Kennzahlensystems Strategie definieren, IT- Strategie ableiten Bestandsaufnahme der Unternehmensarchitekur CEO/CIO Bebauungsplaner IT-Strategie Ist-Zustand der Unternehmensarch. Vorbedingungen konkrete Ziele ableiten und dokumentieren Dokumentation der Ziele CIO Kennzahlen formulieren, welche die Zielerreichung messen Kennzahlen repräsentativer Nutzer Kennzahlenverantwortlicher Kennzahlen zu einem Kennzahlensystem zusammenfassen und umsetzen Kennzahlensteckbriefe abgelehnte Kennzahlen Kennzahlensystem Konstruktion Kennzahlensys. Dokumentation neue Anforderungen an das Kennzahlensystem Kennzahlen weiterverwenden Endnutzer Steuerungscockpit Berichte Nutzung Legende: Prozess Ergebnis, Daten, Produkt Dokumentation, Text Akteur Abbildung 4.5: Prozess der Entwicklung eines Kennzahlensystems im Überblick 47

58 48

59 5 IT-Bebauungsmanagement mit iteraplan Nachdem in den letzten drei Kapiteln die theoretischen Grundlagen erklärt wurden, wird nun ein Werkzeug vorgestellt, mit dem das IT-Bebauungsmanagement in der Praxis umgesetzt werden kann. Im weiteren Verlauf dieser Arbeit werden Daten aus diesem Werkzeug weiterverarbeitet. 5.1 Vorstellung iteraplan iteraplan ist das von iteratec entwickelte Werkzeug zur Durchführung des IT-Bebauungsmanagements. Es ist als Java-EE-Webapplikation mit Spring und Hibernate realisiert und ermöglicht so eine standortunabhängige Bedienung. iteraplan kann als Open-Source- Community-Edition bezogen werden. Es existiert auch eine erweiterte Enterprise-Edition, welche eine Beratung und Wartung durch iteratec beinhaltet. 1 Diese Arbeit bezieht sich auf die aktuelle Version iteraplan Nachfolgende Aussagen stützen sich auf das iteraplan- Anwenderhandbuch (vgl. [ite09]). Document EAM-Modell Analyze Mutliprojektmanagement Act Check Plan Auswertungen Abbildung 5.1: Abdeckung des Unternehmensarchitekturzyklus durch iteraplan 1 für weitere Informationen siehe 49

60 5 IT-Bebauungsmanagement mit iteraplan iteraplan unterstützt die Prozesse des Unternehmensarchitekturzyklus (siehe Abbildung 5.1). Durch das vorgefertigte Datenmodell in iteraplan, welches mit individuellen Merkmalen erweitert werden kann, lässt sich eine an die eigenen Bedürfnisse angepasste Dokumentation der Architektur erstellen. Die Analyse dieser Ist-Architektur erfolgt in iteraplan durch verschiedene Auswertungsmöglichkeiten. Auch das Erstellen von Plan- und Soll-Architekturen wird von iteraplan direkt unterstützt. Die praktische Umsetzung der Maßnahmen erfolgt nicht in iteraplan selbst, sondern wird durch bewährte Werkzeuge des Projektmanagements abgewickelt. Eine Qualitätskontrolle über das IT-Bebauungsmanagement selbst lässt sich teilweise durch die Abfragemöglichkeiten in iteraplan realisieren. 5.2 Datenmodell Da im weiteren Verlauf der Arbeit auf die Daten aus iteraplan zugegriffen wird, wird hier kurz erklärt, wie das logische Datenmodell von iteraplan aufgebaut ist Vorgegebenes Datenmodell Das Datenmodell basiert auf dem bereits vorgestellten Architekturmodell (siehe Abbildung 5.2). Fachliche Architektur Geschäftsprozesse Informationssystem-Architektur Informationssysteme Schnittstellen Informationsfluss Technische Architektur Funktionen Produkte Geschäftseinheiten Geschäftsobjekte Betriebsinfrastruktur- Architektur Technische Bausteine (Blueprint) Infrastrukturelemente IT-Strategie Unternehmensstrategie Abbildung 5.2: Aufbau der Unternehmensarchitektur aus [Han09, S. 67] 50

61 5.2 Datenmodell Das Datenmodell besteht aus einer Vielzahl von Bebauungselementen, wie etwa Geschäftsprozess, Informationssystem, oder Infrastrukturelement. Diese Bebauungselemente werden in drei Ebenen aufgeteilt. Die oberste Ebene beschreibt die fachliche Bebauung. Hier werden Geschäftsprozesse modelliert, welche durch die IT umgesetzt oder unterstützt werden sollen. Die zweite Ebene beschreibt die Informationssystem-Bebauung. Dort werden die IS und deren Beziehungen modelliert. Die unterste Ebene ist in technische Bebauung und Betriebsinfrastruktur-Bebauung aufgeteilt. Die technische Bebauung beschreibt, aus welchen technischen Bausteinen die IS bestehen. Damit sind hier etwa Programmiersprachen, Frameworks, Webserver oder Datenbanksysteme gemeint. Die Betriebsinfrastruktur-Bebauung enthält die Hardwaresysteme, auf welche die IS verteilt werden. Die Projektebene erstreckt sich über alle drei vorhergehenden Ebenen, da ein Projekt Komponenten aus jeder dieser Ebenen enthalten kann. Abbildung 5.3: Logisches Datenmodell von iteraplan aus [ite09] 51

62 5 IT-Bebauungsmanagement mit iteraplan Erweiterung durch Merkmale Jedes Bebauungselement hat grundlegende Eigenschaften, wie etwa einen Namen und eine Beschreibung. Darüber hinaus erlaubt es iteraplan, alle Bebauungselemente zusätzlich mit eigenen Merkmalen zu versehen. Dem Anwender wird so ermöglicht, schnell auf Veränderungen der Modellierungsanforderungen zu reagieren. Merkmale sind in iteraplan stets zu Merkmalsgruppen zusammengefasst. Jedes Merkmal ist genau einer Merkmalsgruppe zugeordnet. Es ist standardmäßig bereits eine Merkmalsgruppe Strategische Steuerungsgrößen definiert, welche aus folgenden Merkmalen besteht: Strategiebeitrag und Wertbeitrag Allgemeine Kosten und Betriebskosten Gesundheitszustand Das flexible Merkmalsystem ist gut dazu geeignet, den Bebauungselementen Daten zuzuordnen, welche für die Erhebung von Kennzahlen notwendig sind. In Kapitel 6 und 7 wird dies anhand einer Kennzahlensammlung auf der Basis von COBIT gezeigt. 5.3 Sichten- und Rollenkonzept iteraplan enthält ein Sichten- und Rollenkonzept, mit dem sich Rechte für verschiedene Benutzergruppen festlegen lassen. Somit lassen sich unterschiedliche Sichten auf die Bebauungsplanung erstellen. Folgende Berechtigungstypen werden unterschieden: Funktionale Berechtigungen, mit denen einzelne Menüpunkte ein- oder ausgeblendet werden können. Hat eine Rolle z.b. die funktionale Berechtigung Menüpunkt Produkte, so ist für Anwender mit dieser Rolle der Menüeintrag Produkte sichtbar. Typspezifische Pflegeberechtigung legen fest, wer welche Bebauungselemente erstellen, ändern und löschen darf. Lese- und Pflegeberechtigung für Merkmalsgruppen legen fest, wer die Merkmale einer Merkmalsgruppe lesen und pflegen darf. Für Anwender, deren Rolle keine Leseberechtigung besitzt, ist das Merkmal nicht sichtbar. Es ist möglich, iteraplan durch die Erstellung von Sichten und Rollen verschiedenen Nutzern optimal zugänglich zu machen. Der Informationssystem-Verantwortliche hat beispielsweise die Aufgabe, die aktuellen Statusdaten seines Informationssystems zu pflegen. Durch eine angepasste Sicht an diese Rolle muss der IS-Verantwortliche sich nicht durch eine Vielzahl von Bebauungselemten und Funktionen arbeiten, sondern erhält eine vereinfachte Sicht, mit der er seine Aufgabe effizient durchführen kann. Durch die Einschränkung des Zugriffs auf Merkmale, kann sichergestellt werden, dass interne Daten oder Finanzwerte nur dem gewünschten Nutzerkreis zugänglich sind. 52

63 5.4 Auswertungsmöglichkeiten 5.4 Auswertungsmöglichkeiten Das IT-Bebauungsmanagement trägt dazu bei, Transparenz über die Ist-, Plan- und Sollbebauung des Unternehmens zu schaffen. Um dies zu unterstützen, stellt iteraplan tabellarische sowie grafische Auswertungen bereit Tabellarische Auswertungen iteraplan erlaubt eine sehr detailliert konfigurierbare Abfrage der Bebauungsdaten mit Hilfe von tabellarischen Auswertungen. Die Bebauungselemente lassen sich anhand ihrer Eigenschaften und Merkmale filtern. Zusätzlich lassen sich durch sogenannte Abfrageerweiterungen Eigenschaften von verknüpften Bebauungselementen mit einbeziehen. So lässt sich beispielsweise eine Abfrage erstellen, welche alle Informationssysteme enthält, die derzeit produktiv sind, und gleichzeitig über eine Schnittstelle mit einem Informationssystem verbunden sind, dessen Status Außer Betrieb ist (siehe Abbildung 5.4). Die Ergebnisse der Abfrage werden standardmäßig in der iteraplan-oberfläche als Tabelle angezeigt. Die Ausgabe lässt sich aber auch als Excel- oder CSV-Datei zur Weiterbearbeitung exportieren Grafische Auswertungen Neben den tabellarischen Auswertungen bietet iteraplan auch grafische Auswertungen zur Visualisierung der Bebauungsdaten an. Die Grafiken werden im Microsoft Visio Format erzeugt und können somit auch leicht weiterverarbeitet werden. Es stehen vier verschiedene Grafiktypen zur Verfügung: Die Informationsfluss-Grafik stellt die vorhandenen Informationssysteme, deren Schnittstellen und die darüber übertragenen Geschäftsobjekte dar. Die Bebauungsplan-Grafik ist in zwei Dimensionen aufgeteilt. Standardmäßig wird dargestellt, welche IS bei welchen Geschäftsprozessen (X-Achse) von welchen Geschäftseinheiten (Y-Achse) eingesetzt werden. Die Portfolio-Grafik stellt Bebauungselemente in einem Koordinatensystem als Kreise dar. Dieser Grafiktyp wird anschließend noch näher erläutert. Die Masterplan-Grafik veranschaulicht die Produktivzeiträume und Statusinformationen von Informationssystemen, Projekten oder technischen Bausteinen auf einer Zeitachse. Zu jeder grafischen Auswertung lassen sich eine Vielzahl von Einstellungen vornehmen und einmal definierte Auswertungen können zur späteren Verwendung gespeichert werden. 53

64 5 IT-Bebauungsmanagement mit iteraplan Tabellarische Auswertungen Informationssysteme Technische Bausteine Schnittstellen Infrastrukturelemente Projekte Geschäftseinheiten Produkte Geschäftsprozesse Fachliche Funktionen Geschäftsobjekte Architekturdomänen Informationssystemdomänen Fachliche Domänen Eigenschaften der gesuchten Informationssysteme Status: Ist Plan Soll Außer Betrieb Produktiv: von bis Eigenschaften der über Schnittstellen verbundenen Informationssysteme Keine Zuordnungen Status: Ist Plan Soll Außer Betrieb Produktiv: von bis Abfrageergebnisse nachbearbeiten Ausgabe: Ergebnisse: 6 Name und Version Beschreibung von bis Status CRM # 3.1 Haupt-Kundendatenbank Ist DMS # 1.9 Output-Management Paperwork Ist Dokumenten-Management und Output-Management: Dokumentengenerierung, Massendruck, PDF-Erstellung, Fax- und -Service, Online-Banking # 2.3 Online-Banking-System Ist Spartensystem # 2.0 : C-Loans-Mgr # 1.4 Abbildung von Firmenkrediten für Großfinanzierung und ähnlichen Darlehen Ist Spartensystem # 2.0 : Loans-Mgr # 1.6 Abbildung von Privat- und Konsumentenkrediten und anderen Darlehen Ist Spartensystem RB # 1.5 : Kredit-Sys RB # 2.6Abbildung von Firmen-, Privat-, Konsumentenkrediten und anderen Darlehen der Regionalbank Ist iteratec GmbH 2008 Build ID: Community Edition Build-v2.1.0-r8543 ( ) Abbildung 5.4: Beispiel für Abfrage von IST-Informationssystemen, die am produktiv sind und über eine Schnittstelle mit einem IS verbunden sind, welches Außer Betrieb ist. Portfolio-Grafik Hier wird detaillierter auf die Portfolio-Grafik eingegangen, da diese sich besonders gut eignet, um strategische Steuerungsgrößen darzustellen. Die Portfolio-Grafik stellt Bebauungselemente in einem zweidimensionalen, kartesischen Koordinatensystem dar. Dabei werden bis zu vier Merkmale dargestellt: Merkmal über die Positionierung in horizontaler Richtung (X-Achse). Merkmal über die Positionierung in vertikaler Richtung (Y-Achse). Merkmal über die Kreisgröße (Größe). Merkmal über die Kreisfarbe (Farbe). Bei der Erstellung der Grafik kann zunächst ausgewählt werden, welcher Typ von Bebauungselementen angezeigt werden soll (IS, Geschäftsprozesse, Projekte, etc.). Anschließend 54

65 5.4 Auswertungsmöglichkeiten kann die Ergebnismenge anhand eines Filters weiter eingeschränkt werden (analog zu Abbildung 5.4). Nachdem festgelegt wurde, welche Merkmale auf der X-/Y-Achse aufgetragen werden und welche die Größe und Farbe bestimmen, kann die Grafik generiert werden. Eine Beispielgrafik ist in Abbildung 5.5 zu sehen. In diesem Beispiel werden die derzeit aktiven Informationssysteme abgebildet. Je weiter rechts ein System auftaucht, desto höher ist sein Strategiebeitrag, je weiter oben es platziert ist, desto höher sein Wertbeitrag. Die Farbe repräsentiert den Gesundheitszustand, die Größe des Kreises stellt die Systemgröße dar. Auf diese Weise lässt sich ein schneller Überblick der wichtigsten Merkmale aller Informationssysteme gewinnen. 10,00 Konto- Sys RB # 3.1 Deposits -Mgr # 3.2 Wertpapier- System # 1.2 Zahlung sverkehr # r12 Zahlung sverkehr RB # 2.0 Zahlung sverkehr # r13 Loans- Mgr # 1.4 Loans- Mgr # 1.6 Online- Banking # 2.3 7,50 Call- Center # 3.2 5,00 Wertbeitrag Scan- Engine # 5.1 2,50 LDAP # 2.3 Personal # 4.5 SAP # R/3 i7 : SAP MM # x.x SAP # R/3 i7 : SAP CO # x.x Meldewe sen # 3.0 Personal # 4.5b Bonität # 1.1 SAP # R/3 i7 : SAP FI # x.x Drucker # 3r1 Intranet # 2.0 CRM # 3.1 Risk Manager # 1.0 Treasury # 1.0 CRM PB # 2.6 Customer RB # 3.1 Customer RB # 3.2 DWH # 2.3 Biz-CRM # 2.6 MIS # 1.2 0,00 0,00 2,50 5,00 7,50 10,00 Strategiebeitrag Abbildung 5.5: Beispiel für eine Portfolio-Grafik 55

66 5 IT-Bebauungsmanagement mit iteraplan 5.5 Controlling mit iteraplan Wie bereits in Kapitel 2 festgestellt wurde, ist es essenziell die Unternehmensarchitektur zu managen und ihre Umsetzung aktiv zu steuern. Dazu bedient man sich bewährter Verfahren aus dem Controlling Vorhandene Controllingansätze Dank des Sichten- und Rollenkonzepts und dem flexiblen Merkmalsystem lassen sich für das Controlling relevante Daten direkt in iteraplan pflegen. COBIT definiert beispielsweise eine große Anzahl von Kennzahlen, sagt aber nichts darüber aus, wie diese erhoben, verwaltet und gepflegt werden sollen. In iteraplan findet sich der geeignete Ort, Kennzahlen abzulegen, welche mit Bebauungselementen in Zusammenhang stehen. In Kapitel 6 und 7 wird gezeigt, welche Kennzahlen aus COBIT in iteraplan durch Merkmale umsetzbar sind. Mit den tabellarischen Auswertungen ist es möglich, die Informationen des Bebauungsmanagements zu filtern. Damit lassen sich spezifische Fragestellungen schnell beantworten. Beispielsweise könnte der Bebauungsplaner sich dafür interessieren, welche Informationssysteme einen niedrigen Strategiebeitrag und zugleich hohe Anforderungen an fachliches Wissen besitzen. Zusätzlich ist es mit der Portfoliografik möglich, beliebige Bebauungselemente zusammen mit deren spezifischen Eigenschaften und Merkmalen darzustellen. Mit Hilfe dieser Ausgaben ermöglicht iteraplan bereits eine grundlegende Form des Controllings Handlungsbedarf Diese Abfragemöglichkeiten genügen für sporadische Auswertungen und Konsistenzchecks der Ist-Daten. Für eine kontinuierliche Überwachung der Werte, einen Vergleich mit historischen Daten und als Grundlage für Prognosen, wie es im Controlling angedacht ist, sind sie aber nicht optimal geeignet. Meist besteht in großen Unternehmen bereits ein (IT-)Controlling, welches standardmäßig ein Data-Warehouse (DWH) in Verbindung mit einem BI-Tool verwendet. Bei der Erstellung eines DWH gilt der Grundsatz des Single Source of Truth, welcher besagt, dass alle relevanten Daten an einer zentralen Stelle gespeichert werden sollten (vgl. [LC04]). Dabei wird eine bewusste Redundanz geschaffen, indem Daten aus Quellsystemen in das DWH geladen werden. Die Weiterverarbeitung erfolgt dann nur noch auf diesen Daten. Ein Vorteil dieses Verfahrens ist, dass die Daten beim Übernehmen in das DWH transformiert und bereinigt werden können, ohne dabei das Quellsystem zu beeinflussen. Auch die Aufgabe der Historisierung wird damit von den Quellsystemen ins DWH verlagert. Eine systemübergreifende Analyse und die Korrelation von Daten aus unterschiedlichen Systemen wird erst durch ein DWH praktikabel. 56

67 5.5 Controlling mit iteraplan Würde man iteraplan völlig eigenständig also parallel zum bestehenden Controlling betreiben, würde ein hoher Mehraufwand entstehen. Die Ergebnisse der Auswertungen müssten manuell übertragen, und grafische Ausgaben kopiert und in das vorhandene Controlling integriert werden. Auch in die Gegenrichtung stößt man auf Probleme. Daten und Kennzahlen die bereits im DWH erfasst sind, müssten manuell nach iteraplan übertragen werden, wenn man sie in Bezug zu Bebauungsdaten setzen will. Generell sind Fachbereichssysteme und Insellösungen im Controlling nicht mehr zeitgemäß (vgl. [Com07]). Es besteht die Anforderung, die Bebauungsdaten aus iteraplan in das vorhandene Controlling zu integrieren. Praktisch heißt das, dass die Daten aus iteraplan periodisch ausgelesen und in das DWH eingespielt werden. Somit können sie für Berichte, Analysen und Visualisierungen herangezogen werden. Im weiteren Verlauf dieser Arbeit wird ein Steuerungscockpit konzipiert, welches komprimierte Daten aus iteraplan visualisiert und seinen Nutzern somit wertvolle Informationen zur Unternehmenssteuerung zur Verfügung stellt. Betrachtet man den Unternehmensarchitekturzyklus, so liegt die Aufgabe des Steuerungscockpits darin, die Qualität des IT- Bebauungsmanagements selbst sicherzustellen, sowie zu validieren, dass das IT-Bebauungsmanagement richtig eingesetzt wird und sich positiv auf das Unternehmen auswirkt (siehe Abbildung 5.6). Document EAM-Modell Analyze Multiprojektmanagement Act Check Plan Steuerungscockpit Auswertungen Abbildung 5.6: Einordnung des Steuerungscockpits im Unternehmensarchitekturzyklus 57

68 58

69 6 Konzeption eines Steuerungscockpits In diesem Kapitel wird ein exemplarisches Steuerungscockpit für das IT-Bebauungsmanagement mit iteraplan konzipiert. Dafür werden zunächst die Anforderungen für diese spezielle Art von Steuerungscockpit aufgenommen und potenzielle Datenquellen identifiziert. Anschließend werden die Ziele der Kennzahlen dokumentiert und auf Basis von COBIT ein Kennzahlenkatalog erstellt. Für die Rolle des Informationssystem-Bebauungsplaners wird abschließend ein Kennzahlensystem erstellt. 6.1 Anforderungsanalyse Steuerungscockpits lassen sich für verschiedene Zwecke einsetzen. Ein Cockpit, welches die Produktion von Waren an einem Fließband überwacht, müsste seine Anzeigen eigenständig im Minutenrhythmus aktualisieren und bei einem Fehler, der zum Stillstehen des Fließbands führt, ein Warnsignal ausgeben. Das Steuerungscockpit, welches im Laufe dieser Arbeit erstellt wird, legt seinen Fokus auf das IT-Bebauungsmanagement. Hier werden zunächst die Anforderungen an dieses Steuerungscockpit identifiziert Identifikation potenzieller Nutzer Welche Anforderungen das Steuerungscockpit erfüllen muss, hängt im Wesentlichen davon ab, wer es später benutzt. Neben der Aufteilung der Nutzer nach ihrer Sicht auf das EAM (siehe Abschnitt 4.2), lässt sich auch eine Gruppierung der Nutzer anhand ihrer Beteiligung am EAM bzw. am IT-Bebauungsmanagement erstellen. Nach Hanschke [Han09, S. 99ff] kann man dabei grundsätzlich zwischen Nutznießern, Bebauungsplanern und Datenlieferanten unterscheiden: Nutznießer Zur Gruppe der Nutznießer gehören unter anderem CEO, Chief Information Officer (CIO), Unternehmensarchitekt und Projektleiter. Nutznießer profitieren durch das EAM, indem sie die dort gesammelten Informationen auswerten und so einen Überblick über den aktuellen Status erhalten, Handlungsbedarf und Optimierungspotenziale identifizieren oder strategische Planungen erstellen. Der Unternehmensarchitekt hat die Aufgabe eine Unternehmensarchitektur zu entwerfen, in der die Geschäftsprozesse optimal mit IS unterstützt werden. Für ihn ist es wichtig, 59

70 6 Konzeption eines Steuerungscockpits die IT-Strategie umzusetzen. Ihn interessiert unter anderem, wie weit dieser Prozess schon abgeschlossen ist, also welche IS die Geschäftsstrategie wie gut unterstützten und wie sich dies mit dem Erreichen der nächsten Plan-Bebauung ändert. Das Topmanagement (CEO, CIO, etc.) befasst sich nicht im Detail mit der Umsetzung der Unternehmensarchitektur. Es ist an einer Zusammenfassung der Ereignisse und deren Auswirkungen interessiert. Auf dieser Ebene spielt auch die Entwicklung der Kosten (Entwicklungskosten, Betriebskosten, etc.) eine wichtige Rolle. Außerdem interessiert das Topmanagement, wie gut die von ihnen definierte Strategie im Unternehmen angenommen und umgesetzt wird. Weiterhin muss kontrolliert werden, ob die Umsetzung der Strategie zu den gewünschten Effekten führt oder ob eine Neuformulierung notwendig ist. Bebauungsplaner Bebauungsplaner sind verantwortlich für die Dokumentation und Analyse sowie die strategische Planung und Steuerung der Gesamtbebauung. Bebauungsplaner entwerfen Plan- Bebauungen und leiten deren Umsetzung in Form von Projekten ein. Um diese Aufgabe zu erfüllen, benötigen sie aktuelle Informationen zur Ist-Bebauung. Sie müssen wissen, welche Informationssysteme derzeit aktiv sind, welche Geschäftsprozesse diese unterstützen, wie stark sie voneinander abhängen, auf welche technischen Bausteine sie aufsetzen und auf welcher Infrastruktur sie betrieben werden. Zusätzlich möchten Bebauungsplaner wissen, wie weit die Erreichung einer Plan-Bebauung bereits fortgeschritten ist. Bebauungsplaner fordern Daten zur Ist-Bebauung von den Datenlieferanten ein, konsolidieren diese und erstellen Prognosen. Somit können sie die Fragestellungen der Nutznießer beantworten und die zukünftige Bebauung gestalten. Datenlieferanten Zur Gruppe der Datenlieferanten zählt man IS-Verantwortliche, Projektleiter und Infrastruktur-Architekten. Ihre Aufgabe ist es, Detaildaten zu ihrem jeweiligen Bebauungselement bereitzustellen. Datenlieferanten sollten selbst auch einen Nutzen von der Pflege der Bebauungsdaten haben. Beispielsweise dienen die Bebauungsdaten von Informationssystemen als Informationsquelle für neue Projekte oder für die Planung von Wartungsmaßnahmen (vgl. [Han09, S. 103]). Projektleiter haben die Aufgabe, die Detaildaten ihres Bebauungselements zu erheben und aktuell zu halten. Sie sind daran interessiert, welche Daten gepflegt werden müssen und ob es im IT-Bebauungsmanagement veraltete Daten zu ihren Projekten gibt. Vor allem möchten sie aber ihr aktuelles Projekt rechtzeitig und erfolgreich abschließen. Für sie ist wichtig zu erfahren, welche strategischen Ziele durch ihre Projekte umgesetzt werden sollen, also woran der Erfolg ihrer Projekte gemessen wird und wie gut sie dieses Ziel erreichen werden. Da ein Projekt meist Schnittstellen zu bestehenden Systemen oder anderen Projekten besitzt, möchten sie auch über deren Status informiert werden. 60

71 6.1 Anforderungsanalyse Funktionale Anforderungen Aus den individuellen Anforderungen der einzelnen Nutzer ergeben sich einige grundlegende funktionale Anforderungen an ein Steuerungscockpit für das IT-Bebauungsmanagement. Je nach Nutzer und konkreter Steuerungsaufgabe müssen diese noch um weitere individuelle Anforderungen ergänzt und genauer detailliert werden. Darstellungsform Das Ziel des Steuerungscockpits ist es, Informationen auf einen Blick darzustellen und somit Zusammenhänge erkennbar zu machen. Streng genommen bedeutet das, dass nur eine Bildschirmseite verwendet werden darf: kein Blättern, kein Scrollen, keine wichtige Informationen in Tooltips. Diese Forderung ist durchaus berechtigt, da unser Kurzzeitgedächtnis nur eine sehr begrenzte Kapazität hat. Muss man sich durch mehrere Bildschirmseiten blättern, werden Zusammenhänge nicht erkannt (vgl. [Few06, S. 50]). Außerdem ist die Darstellung der Informationen ausschlaggebend für das Verständnis und die Erfassungsgeschwindigkeit. Prinzipiell ließen sich sämtliche Informationen eines typischen Steuerungscockpits in textueller Form mittels Tabellen darstellen, dabei würden aber Änderungen oder ein akuter Handlungsbedarf nicht deutlich sichtbar. Es müssen also grafische Darstellungen verwendet werden. Dabei muss bewusst mit Anordnung, Farben und Formen umgegangen werden, um eine möglichst hohe Aussagekraft zu erreichen (siehe dazu auch Abschnitt 3.4.2). Anpassbare Sichten Wie bereits festgestellt, haben die einzelnen Nutzer unterschiedliche Anforderungen an ein Steuerungscockpit. Informationen die für den Bebauungsplaner wichtig sind, können für den CEO zu detailliert oder schlicht unerheblich sein. Daher muss es möglich sein, die Darstellung zumindest für jede Nutzergruppe individuell anzupassen. Das bedeutet nicht nur die Änderung der Darstellungsform (Diagramm statt Tabelle), sondern auch die Änderung des angezeigten Inhalts muss einfach möglich sein. Je nach Nutzer kann es auch erwünscht sein, dass die Darstellung vom Nutzer selbst erstellt oder verändert werden kann. Drill-Down Drill-Down ist ein Begriff aus dem OLAP-Umfeld, der ein Navigationsverfahren beschreibt. Dabei wird eingeschränkt, welche Datensätze angezeigt werden, gleichzeitig aber deren Detaillierungsgrad erhöht. Ein dynamischer Drill-Down ermöglicht es, Kennzahlen genauer zu betrachten. Da im Steuerungscockpit stark aggregierte Daten angezeigt werden, besteht der Wunsch, die Zusammensetzung dieser Daten nachvollziehen zu können. Wird im Steuerungscockpit 61

72 6 Konzeption eines Steuerungscockpits beispielsweise nur der Gesamtumsatz angezeigt, könnte dieser im Drill-Down nach Geschäftsstellen aufgeteilt werden. Die primäre Aufgabe des Steuerungscockpits ist es, die Aufmerksamkeit des Nutzers auf wichtige Bereiche zu lenken oder einen Handlungsbedarf aufzuzeigen. Drill-Down geht einen Schritt weiter und zeigt nicht nur grob auf, wo ein Handlungsbedarf besteht sondern gibt auch erste Hinweise darauf, was genau verändert werden muss. Nach Few (vgl. [Few06, S. 99]) ist Drill-Down aber keine primäre Anforderung an ein Steuerungscockpit. Wenn ein Steuerungscockpit die Möglichkeit bietet, leicht an weitergehende Informationen zu gelangen, ist dies durchaus wünschenswert, die Hauptaufgabe besteht aber weiterhin darin, einen ganzheitlichen Blick auf die wichtigsten Kennzahlen zu vermitteln. Was man in jedem Fall berücksichtigen sollte, ist die Zusammensetzung der Darstellungen und der Kennzahlen zu dokumentieren, damit ein Drill-Down zumindest manuell möglich ist. Daten aus unterschiedlichen Quellen vergleichen Das Steuerungscockpit, welches hier entworfen wird, legt seinen Fokus auf Daten des IT- Bebauungsmanagements. Dadurch kann beispielsweise verfolgt werden, wie viele Informationssysteme eine veraltete Technologie einsetzen. Diese Information für sich ist schon sehr wertvoll. Der wahre Nutzen eines Steuerungscockpits entfaltet sich aber erst, wenn eine Korrelation zu anderen Unternehmensdaten hergestellt werden kann. Beispielsweise wäre es interessant zu analysieren, wie sich die Netzwerkauslastung, die Anzahl der Tickets oder die Prozessdurchlaufdauer ändert, nachdem ein neues Informationssystem eingeführt wurde. Eine exemplarische Identifikation der zu berücksichtigenden Datenquellen wird in Abschnitt 6.2 durchgeführt. Aktualität der Kennzahlen Da ein Steuerungscockpit genutzt wird, um kritische Entscheidungen zu treffen, ist es äußerst wichtig, möglichst aktuelle Kennzahlen zu verwenden. Dazu ist es nötig, die Aggregation der Daten und die Bildung der Kennzahlen zu automatisieren. Natürlich können die Kennzahlen trotzdem nur so aktuell sein, wie die ihnen zugrundeliegenden Daten. Dabei muss man unterscheiden, um welche Art von Daten es sich handelt. Der Fertigstellungsgrad eines Projekts oder die Mitarbeiterzufriedenheit ändern sich zwar ständig, dies aber nur in sehr geringem Umfang. Da diese Daten zusätzlich eher subjektiv sind, und daher manuell erhoben werden müssen, ist es schon aus rein wirtschaftlichen Gründen nicht sinnvoll sie täglich zu aktualisieren. Andere Daten, wie etwa die Besucheranzahl einer Website lassen sich einfacher erfassen. Aber auch hier ist es nicht immer optimal den aktuellsten Stand im Steuerungscockpit anzuzeigen. Meist sind hier kumulierte Daten aussagekräftiger. Tagesaktuelle Daten oder sogar Echtzeitdaten werden nur sehr selten, von speziellen Nutzern benötigt. Für das Steuerungscockpit, das hier entwickelt werden soll, sind vor allem strategische Daten von Interesse, welche im Wochen- oder Monatsrhythmus aktualisiert werden. 62

73 6.1 Anforderungsanalyse Die benötigten Daten lassen sich nach ihrem Erhebungsaufwand und der Änderungsrate, die von Interesse ist, klassifizieren (siehe Abbildung 6.1). Erhebungsaufwand automatisch halbautomatisch manuell schwer zu erheben / unwirtschaftlich Webseitenaufrufe, Netzwerktraffic, Serverauslastung Risikoeinschätzungen Anzahl Tickets, Callcenteranrufe, Bugs Strategieausrichtung Projektfertigstellung Mitarbeiter-/ Kundenzufriedenheit Jahresumsatz Echtzeit Tag Woche Monat Jahr Gewichtete Änderungsrate strategisch operativ Abbildung 6.1: Kategorisierung von Daten anhand ihrer Änderungsrate und ihrem Erhebungsaufwand. Wie aktuell die angezeigten Daten sind, ist unterschiedlich. Man muss aber immer beachten, dass der Benutzer stets erkennen kann, zu welchem Zeitpunkt die Daten zugeordnet sind. Die Kennzahl Fertigstellungsgrad von Projekt B sagt nichts aus, wenn nicht zu erkennen ist, ob die zugrundeliegenden Daten vor einer Woche oder vor zwei Monaten ausgelesen wurden. Historisierung Die Forderung nach einer Historisierung der Daten erfolgt aus zwei unterschiedlichen Gründen. Einerseits beinhalten Kennzahlen oft Vergleiche mit historischen Daten (Umsatz dieses Monats im Vergleich zum Umsatz des letzten Monats). Diese Kennzahlen könnte man zwar etwas umformen und die Vergleichswerte fest definieren (Umsatz des aktuellen Monats wird 63

74 6 Konzeption eines Steuerungscockpits immer mit Umsatz Januar 2005 verglichen), dadurch würde der manuelle Pflegeaufwand aber erhöht werden und gleichzeitig die gewünschte Aussagekraft und Dynamik verloren gehen. Historisierung ermöglicht es also erst, zeitraumorientierte Kennzahlen zu nutzen. (vgl. Kennzahlenarten auf Seite 19). Andererseits wird eine Historisierung gefordert, um Entscheidungen begründen und nachträglich belegen zu können. Durch eine Historisierung ist es möglich, getroffene Entscheidungen nachzuvollziehen und somit sein eigenes Handeln rückwirkend zu analysieren und zu bewerten Einflussfaktoren Neben den rein funktionalen Anforderungen bestehen noch eine Reihe weiterer Einflussfaktoren, die bei der Konzeption des Steuerungscockpits beachtet werden müssen. Der dominierende Aspekt ist hierbei die Integration des Steuerungscockpits in das bereits bestehende Controlling-Umfeld. Datenbankanbindung Da davon ausgegangen wird, dass bereits ein Controlling mitsamt DWH existiert, ist der reibungslose Zugriff auf die Daten im DWH eine grundlegende Voraussetzung. Optimaler Weise greift das Steuerungscockpit lediglich auf Daten aus dem DWH zu. Daher muss es dem DWH möglich sein, die Daten aus den Quellsystemen zu extrahieren. iteraplan benutzt standardmäßig eine MySQL Datenbank, kann aber auch mit anderen Datenbanksystemen verwendet werden. Es ist somit eine Anforderung an das Data-Warehouse-System beispielsweise durch den Einsatz eines ETL-Werkzeugs (Extract, Transform, Load 1 ) Daten aus iteraplan in den internen Datenbestand zu übernehmen und zu historisieren. Integration in das BI-Umfeld Weiterhin ist darauf zu achten, wie gut sich das Steuerungscockpit in das bestehende BI- Umfeld integriert. Es kann durchaus wünschenswert sein, Snapshots des Steuerungscockpits in Berichte zu integrieren oder bereits bestehende Kennzahlen auch für das Steuerungscockpit zu nutzen. Je stärker das Steuerungscockpit integriert ist, desto weniger Aufwand entsteht dadurch. Meist bieten Hersteller von BI-Werkzeugen eine Komplettlösung für das gesamte Controlling an, welche neben Berichten, Auswertungen und Scorecards auch ein Steuerungscockpit vorsieht. 1 Ein im DWH-Umfeld gebräuchliches Verfahren mit dem Daten aus einer Datenquelle durch Extraktion, Transformation und anschließendes Laden in eine Datenbank, migriert werden (vgl. [Bau04] 64

75 6.1 Anforderungsanalyse Kosten In engem Zusammenhang mit der Integration steht auch die Frage nach den anfallenden Kosten. Anschaffungs- und Lizenzkosten der Software, mit der das Steuerungscockpit realisiert wird, sind nur ein Teil der anfallenden Kosten. Ein weitaus größerer Teil entsteht durch die Einführung und Wartung des gesamten Prozesses, der sich hinter dem Steuerungscockpit verbirgt Qualitätsanforderungen Damit das Steuerungscockpit akzeptiert wird, breiten Anklang findet und möglichst wirtschaftlich arbeitet, müssen neben den funktionalen Anforderungen auch Qualitätsanforderungen erfüllt werden. Was sind mögliche Qualitätsanforderungen? Nach ISO 9126 kann man zwischen sechs verschiedenen Qualitätsmerkmalen unterscheiden (vgl. z.b. [Bal98, S. 258]). Die folgende Auflistung enthält die Qualitätsmerkmale, sowie deren Bedeutung für das Steuerungscockpit und dessen Hintergrundprozesse. Funktionalität : Die funktionalen Anforderungen werden in angemessener Weise erfüllt. Zuverlässigkeit : Das Steuerungscockpit ist während der Arbeitszeit verfügbar. Es ist robust gegenüber fehlerhafter Benutzung und lässt sich nach einem Softwarefehler je nach Schwere innerhalb von wenigen Stunden wiederherstellen. Die Konfiguration und die Einstellungen werden persistiert und können gesichert werden, so dass ein Backup auf ein externes Medium erfolgen kann. Benutzbarkeit : Der Aufwand, der zur Bedienung erforderlich ist, ist zu minimieren. Verständlichkeit ist hierbei ein wesentlicher Faktor. Die Darstellungen der Kennzahlen und das Konzept im Hintergrund müssen für den Benutzer verständlich und nachvollziehbar sein. Da die Benutzer aus den unterschiedlichsten Bereichen stammen, sollen keine technischen Vorkenntnisse zur Benutzung des Steuerungscockpits nötig sein. Auch die Erhebung der Kennzahlen muss in einem wirtschaftlich durchführbaren Rahmen erfolgen. Effizienz : Das Arbeiten mit dem Steuerungscockpit muss effizient möglich sein. Das heißt, die Startzeit des Programms sowie die Darstellung der Visualisierungen muss ohne längere Wartezeiten erfolgen. Je nach Unternehmensgröße und geplantem Einsatzumfang, müssen mehrere Benutzer gleichzeitig auf das Steuerungscockpit zugreifen können, ohne merkliche Leistungseinbrüche wahrzunehmen. Änderbarkeit : Der Aufwand für vorhersehbare Korrekturen, Verbesserungen oder Anpassungen soll minimiert werden. Es muss leicht möglich sein, die Darstellungsformen zu ändern oder das Steuerungscockpit um neue Kennzahlen zu erweitern. 65

76 6 Konzeption eines Steuerungscockpits Übertragbarkeit : Eignung der Software in eine andere organisatorische Umgebung, Hardwareoder Software-Umgebung übertragen zu werden. Das Steuerungscockpit sollte von jedem Rechner im Unternehmen aus benutzbar sein. Zudem sollten Ergebnisse des Steuerungscockpits auch an anderen Stellen im Controlling weiterverwendet werden können. 6.2 Identifikation von Datenquellen Die Identifikation von relevanten Daten aus Fremdsystemen ist ein wesentlicher Bestandteil der Konzeption eines Steuerungscockpits. Da die eingesetzten Datenverarbeitungssysteme sich in jedem Unternehmen unterscheiden und selbst Standardsoftware auf unterschiedliche Weise verwendet wird, kann hier nur eine beispielhafte Identifikation durchgeführt werden. Welche Daten sind für ein Steuerungscockpit für das IT-Bebauungsmanagement hauptsächlich relevant? Zunächst sind natürlich die Daten aus dem IT-Bebauungsmanagement selbst zu betrachten. Hierzu zählen die gesamten Bebauungsdaten (Informationssysteme, technische Bausteine, Infrastruktur, Prozesse, etc. und insbesondere deren Merkmale) in den Ausprägungen Ist, Plan und Soll. Die Ist-Daten stellen den aktuellen Zustand der Bebauung dar. Die Plan-Daten sind die taktischen Ziele die es zu erreichen gilt und die Soll-Daten legen die langfristige strategische Richtung fest. Dabei ist zu beachten, dass die Ist-Daten in iteraplan nicht tagesaktuell sind, sondern nur periodisch, etwa im Monatsrhythmus erneuert werden. Oft ist diese Granularität explizit gewünscht und gerade für strategische Ziele reichen monatsaktuelle Daten aus. Mit dem Steuerungscockpit soll es aber auch möglich sein, die Erreichung von zeitnahen Zwischenzielen und Planzuständen aktiv zu steuern und die Zielerreichung zu validieren. Dazu benötigt man zusätzliche aktuelle Daten aus den Produktivsystemen. Um die relevanten Daten zu konkretisieren, ist in Abbildung 6.2 dargestellt, welche Merkmale typischerweise in iteraplan für Informationssysteme gepflegt werden (für andere Bebauungselemente sind ggf. andere Merkmale vorhanden). Diese Merkmale sind keine allgemeingültige Vorgabe. Durch das flexible Merkmalsystem können einem Bebauungselement beliebige Merkmale zugeordnet werden (siehe Abschnitt 5.2.2). Dieses Beispiel soll lediglich zeigen, welche verschiedenen Arten von Daten typischerweise gepflegt werden. 66

77 6.2 Identifikation von Datenquellen Abbildung 6.2: Typische Merkmale eines Informationssystems in iteraplan. Wo finden sich die passenden aktuellen Daten? Die in Abbildung 6.2 dargestellten Merkmale seien Plan-Daten. Es gilt die Ist-Daten möglichst automatisiert zu erheben, um sie im Steuerungscockpit anzuzeigen und somit den Erreichungsgrad des Plan-Zustands zu visualisieren. Denkbar wäre eine Zuordnung zwischen Merkmalen und Datenquellen, wie sie beispielhaft in Tabelle 6.1 ausgeführt wurde. Tabelle 6.1: Zuordnung Merkmale eines Informationssystems in iteraplan und deren mögliche Datenquellen Merkmal Datenquellen Komplexität Schätzung, evtl. Code-Metriken (Metrics, PMD etc.) Programmiersprache aus Dokumentation, manuelle Erfassung Systemgröße Schätzung, Code-Metriken (LOC, Modulanzahl etc.) Verantwortung aus Dokumentation, manuelle Erfassung Wartungsaktivität Ticketsystem (Trac), Projektverwaltung Betriebskosten CMDB Gesundheitszustand Bugtracker (Bugzilla, Trac) Kosten Buchhaltung Strategiebeitrag manuelle Schätzung Wertbeitrag manuelle Schätzung Eigenleistung... Projektverwaltung In Abbildung 6.3 wird dargestellt, welche Daten aus welchen Geschäftsebenen für ein Steuerungscockpit relevant sind. Die Daten liegen dabei nicht immer digital in Form einer Datenbank vor. Ebenso denkbar ist, dass Daten aus Textdokumenten, Spreadsheets oder proprietären Speicherformaten extrahiert und in das DWH integriert werden müssen. 67

78 6 Konzeption eines Steuerungscockpits Steuerungscockpit Darstellung Kundendaten Managementebene Personaldaten Kennzahlen ø Ausfälle / Monat ø TTR Betriebskosten # veraltete TB Buchhaltung Logistik Finanzen Prozessebene Babauungsmanagement Prozessdokumentation Callcenter Prozessmodellierung Kundenumfragen Mitarbeiterumfragen DWH iteraplan Bebauungsdaten Betriebsebene Prozesse, IS, Infrastruktur, etc. strategische Steuerungsgrößen eigene Merkmale CMDB Bugtracker Trafficlog Ist-Daten Plan-Daten Soll-Daten Betriebskosten SLAs Abbildung 6.3: Datenquellen, die für ein Steuerungscockpit im Umfeld des Managements von Unternehmensarchitektur von Interesse sind Diese Daten in das DWH zu integrieren ist ein erheblicher Aufwand. Allein für die Nutzung in einem Steuerungscockpit ist der Aufwand meist nicht vertretbar. Hier zeigt sich deutlich, dass ein Steuerungscockpit ein zusätzliches nützliches Werkzeug des Controllings ist, dabei aber darauf angewiesen ist, dass bereits ein gut durchdachtes und automatisiertes Controlling inklusive DWH und weiterer BI-Methoden im Unternehmen etabliert ist. 68

79 6.3 Beispielkennzahlen für das IT-Bebauungsmanagement mit iteraplan 6.3 Beispielkennzahlen für das IT-Bebauungsmanagement mit iteraplan Da der Aufbau eines kompletten Data-Warehouse und die Integration verschiedener Fremdsysteme den Rahmen dieser Diplomarbeit überschreiten würde, liegt der Fokus der hier konstruierten Kennzahlen hauptsächlich auf Daten, die bereits in iteraplan vorhanden sind Ziele der Kennzahlen Die Zielsetzung der hier erstellten Kennzahlen liegt darin, das IT-Bebauungsmanagement mit iteraplan zu steuern. Es wird gemessen, wie intensiv iteraplan zur Dokumentation und Planung der Unternehmensarchitektur verwendet wird, ob diese Dokumentation qualitativ hochwertig ist, ob die erstellte (Plan-)Bebauung selbst hochwertig ist und soweit möglich ob die gesetzten strategischen Ziele erreicht werden. Die Nutzergruppen, die davon am meisten profitieren, sind Bebauungsplaner und Unternehmensarchitekten. Ihnen soll es möglich sein, Handlungsbedarf und Entwicklungen im IT-Bebauungsmanagement zu erkennen und darauf zu reagieren. Folgende konkrete Ziele wurden angenommen: Vollständige und aktuelle Dokumentation der Ist-Bebauung mittels iteraplan. Modellierung der Plan- und Soll-Bebauung mittels iteraplan. Ablösung veralteter Technologien. Neue IS sollen möglichst nur richtlinienkonforme technische Bausteine einsetzen. Ablösung veralteter Infrastruktur. Konsolidierung der im Betrieb befindlichen IS. Wenn möglich senken der Betriebskosten, Wartungskosten Kennzahlensammlung Die Datenquelle für die hier erstellten Kennzahlen ist iteraplan. In iteraplan können den Bebauungselementen Merkmale zugeordnet werden, welche die Datenbasis für die hier erstellten Kennzahlen bilden. Ein Merkmal, das besonders häufig für die Berechnung der Kennzahlen verwendet wird, ist die Richtlinienkonformität. Das Merkmal Richtlinienkonformität gibt an, wie hoch die Konformität des Bebauungselements in Bezug auf Architektur-/Technologiestandards und Richtlinien ist. Es kann Werte zwischen 0 und 100% annehmen. In iteraplan ist das Merkmal den technischen Bausteinen zugeordnet. Da die Informationssysteme auf technische Bausteine aufsetzen, ist auch ihnen indirekt eine Richtlinienkonformität zugeordnet. Welche weiteren Merkmale den Bebauungselementen zugeordnet sind, zeigt Abbildung A1 im Anhang. 69

80 6 Konzeption eines Steuerungscockpits Als Basis für die hier erstellte Kennzahlensammlung wurden Kennzahlen aus COBIT 4.1 ([ITGI07]; siehe auch Abschnitt 3.2.4) verwendet. Da COBIT ein Framework für IT-Governance ist, wurden nur Kennzahlen übernommen, die im Bereich des Bebauungsmanagements anwendbar sind und deren Daten sich in iteraplan wiederfinden. Diese stammen aus den ersten beiden Abschnitten Plan and Organise und Acquire and Implement. Die zwei weiteren Abschnitte Deliver and Support und Monitor and Evaluate sind zu operativ für das IT-Bebauungsmanagement. Zusätzlich wurden eigene Kennzahlen entworfen. Die folgenden Auflistungen bilden kein Kennzahlensystem, sondern eine Sammlung von einzelnen Kennzahlen, die nach ihrem Verwendungszweck gruppiert wurden. Diese Liste ist nicht vollständig und soll lediglich zur Inspiration beim Finden eigener Kennzahlen dienen. Um die Kennzahlen produktiv zur Steuerung zu verwenden, müssen die richtigen Kennzahlen für das jeweilige Ziel ausgewählt werden und an die Rahmenbedingungen und den jeweiligen Nutzer angepasst werden. Im nachfolgenden Kapitel wird dies prototypisch durchgeführt. Darüber hinaus ist es sinnvoll, die strategischen Kennzahlen aus dem IT- Bebauungsmanagement mit operativen Kennzahlen aus anderen Systemen in Beziehung zu setzen. In den Auflistungen werden Kennzahlen wie folgt nummeriert. Der erste Teil entspricht dem COBIT-Prozess (PO, AI). Der zweite Teil der Nummer gibt an, um welche Art von Ziel es sich in COBIT handelt (A = Aktivitätsziel, P = Prozessziel, IT = IT-Ziel). Sind die Kennzahlen keinem COBIT-Ziel zugeordnet, findet sich dort ein X. Eigene Kennzahlen werden gesondert nummeriert. Folgende Abkürzungen werden in den Tabellen verwendet: IS: Informationssystem TB: Technische Bausteine wie beispielsweise das verwendete Betriebssystem, Datenbanksysteme, Programmiersprachen, Architektur-Muster, Frameworks, Tools oder im Unternehmen etablierte Referenzarchitekturen, die zur Implementierung eines Informationssystems verwendet werden. BBE: Bebauungselemente wie beispielsweise Informationssysteme, Infrastrukturkomponenten oder technische Bausteine. 70

81 6.3 Beispielkennzahlen für das IT-Bebauungsmanagement mit iteraplan Plan and Organise Der Abschnitt Plan and Organise in COBIT deckt Strategie und Taktik ab und identifiziert, wie die IT am besten zur Erreichung der Unternehmensziele beitragen kann. Es wird geprüft, ob IT und Unternehmen aufeinander ausgerichtet sind, ob das Unternehmen die IT-Ressourcen optimal nutzt und ob die Qualität der IT-Systeme ausreichend für die Anforderungen des Geschäftsbetriebs sind. Dieser Abschnitt weist die meisten Bezüge zum IT-Bebauungsmanagement auf. Im Prozess PO1 (Definiere einen strategischen IT-Plan) wird überprüft, wie gut der strategische IT-Plan IT und Business vereint und ob der Plan Anklang findet und umgesetzt wird. Tabelle 6.2: PO1: Strategischen IT-Plan definieren Cobit Nr. Beschreibung Entsprechung Berechnungsweg PO1.P-1 % der IT-Ziele des % der geplanten Bebauungselemente, die Strategiebeitrag PLAN-BBE mit strategischen IT- > 8 / Plans, die den strategischen Unterneh- haben Strategiebeitrag > 8 PLAN-BBE mensplan unterstützen PO1.P-3 % von IT-Projekten im % IT-Projekte im IT- Projekte, die Bezug zu PLAN-IS IT-Projektportfolio, Projektportfolio, die haben / Projekte die direkt auf den ein PLAN-IS umsetzen taktischen IT-Plan im IT-Projektportfolio zurückverfolgt werden gesamt können 71

82 6 Konzeption eines Steuerungscockpits Im Prozess PO2 (Definiere die Informationsarchitektur) schlägt COBIT vor, ein Data Dictionary einzuführen, um Transparenz zu schaffen. Dabei soll identifiziert werden, welche Informationen im Unternehmen in welcher Art vorhanden sind, mit welchen Anwendungen sie zusammenhängen und für welche Geschäftsprozesse sie relevant sind. In dieser Detaillierung wird im IT-Bebauungsmanagement nicht modelliert, trotzdem lassen sich einige Parallelen finden. Tabelle 6.3: PO2: Informationsarchitektur definieren Cobit Nr. Beschreibung Entsprechung Berechnungsweg PO2.A-1 Häufigkeit der Updates Wie intensiv das der geänderten des Modells für EAM-Werkzeug einge- BBE in der letzten Unternehmensinformationesetzt wird Periode PO2.A-2 fehlende Verantwortlichkeit Wie viele BBE haben Merkmal Verantwort- lichkeit nicht gesetzt? PO2.P-1 % der Applikationen, % IST-IS, deren TB welche nicht den Informationsarchitekturen durchschnittlich eine Richtlinienkonformität entsprechen unter 50% besitzen PO2.X-1 Anzahl an Fehlern bei Wie viele Fehler treten Konsistenzchecks beim Ausführen aller Konsistenzchecks auf? PO2.X-2 Anzahl IST-IS Anzahl der IST-IS, die erfasst sind PO2.X-3 Anzahl PLAN-IS Anzahl der PLAN-IS, die erfasst sind PO2.X-4 Anzahl SOLL-IS Anzahl der SOLL-IS, die erfasst sind PO2.X-5 Anzahl IST-IS in IS- Anzahl der IST-IS, die Domäne X der IS-Domäne X zugeordnet sind PO2.X-6 Ausstehende Konsolidierungen PO2.X-7 Anzahl umgesetzter PLAN-IS Anzahl der PLAN-IS, die zwei oder mehr Vorgänger haben Anzahl neuer IST-IS, die zuvor PLAN-IS waren BBE ohne gesetzte Verantwortlichkeit IST-IS deren ØTB- Richtlinienkonformität < 50% ist / IST-IS Fehler der einzelnen Konsistenzchecks IST-IS PLAN-IS SOLL-IS IST-IS in IS- Domäne X PLAN-IS mit >= 2 Vorgängern neue IST-IS, die zuvor PLAN-IS waren 72

83 6.3 Beispielkennzahlen für das IT-Bebauungsmanagement mit iteraplan Der Prozess PO3 (Bestimme die technologische Richtung) fordert die Erstellung eines technologischen Infrastrukturplans und die Einrichtung eines Architekturgremiums, das klare und realistische Erwartungen darüber erzeugt und steuert, was die (Informations-) Technologie durch Produkte, Services und Betriebsmechanismen anbieten kann. Im IT- Bebauungsmanagement betrifft dies die technischen Bausteine, sowie die Infrastruktur. Tabelle 6.4: PO3: Bestimme die technologische Richtung Cobit Nr. Beschreibung Entsprechung Berechnungsweg PO3.A3 Häufigkeit der Reviews Wie oft wird PLAN- Änderungen der / Aktualisierungen des Infrastruktur aktualisiert? PLAN-Infrastruktur technologischen Infrastrukturplans letzte Periode PO3.P-1 % der Nichteinhaltung % IST-TB deren IST-TB mit Richtlinienkonformität < der technologischen Richtlinienkonformität Standards < 50% ist 50% / TB PO3.X-1 Richtlinienkonforme Anzahl an TB, die eine TB mit Richtlinien- TB hohe Richtlinienkonformität > 90% konformität aufweisen PO3.X-2 PO3.X-3 PO3.X-4 ØRichtlinienkonformität eines IS ØRichtlinienkonformität IS: IST ØRichtlinienkonformität IS: PLAN PO3.IT1 Anzahl und Art der Abweichungen vom technologischen Infrastrukturplan Wie richtlinienkonform die TB eines IS durchschnittlich sind wie richtlinienkonform die IST-IS durchschnittlich sind wie richtlinienkonform die PLAN-IS durchschnittlich sind % IST-IS deren Infrastruktur durchschnittlich eine Richtlinienkonformität unter 50% besitzen Richtlinienkonformität verwendeter TB / verwendete TB Richtlinienkonformität der IST-IS / IST-IS Richtlinienkonformität der PLAN-IS / PLAN-IS IST-IS mit ØInfrastruktur- Richtlinienkonformität < 50% / IST-IS 73

84 6 Konzeption eines Steuerungscockpits Acquire and Implement Dieser Abschnitt aus COBIT prüft, ob die eingesetzten IT-Lösungen die IT-Strategie umsetzen und in die Geschäftsprozesse integriert werden. Die definierten Prozesse sind meist wieder sehr operativ und detailliert. Im Bereich des IT-Bebauungsmanagements ist lediglich AI3 (Beschaffe und warte technologische Infrastruktur) relevant. Dieser Prozess konzentriert sich auf die Qualität und Aktualität der verwendeten technischen Infrastruktur. Tabelle 6.5: AI3: Beschaffe und warte technologische Infrastruktur Cobit Nr. Beschreibung Entsprechung Berechnungsweg AI3.P-1 % der nicht mit % Infrastrukturelemente, die Richtlinienmente mit Richtlini- Infrastrukturele- der definierten IT- Architektur und den konformität unter 50% enkonformität < 50% Technologiestandards besitzen / Infrastrukturelemente abgestimmten Plattformen AI3.P-2 Anzahl der Technologieplattformen nach Technische Bausteine miersprache; Anzahl IST- IST-TB Program- IST- Funkion im gesamten nach Funktion TB DB; IST-TB AI3.IT-1 Unternehmen Anzahl der von bald veralteter Infrastruktur unterstützten kritischen Geschäftsprozesse kritische Geschäftsprozesse die mit veralteter Infrastruktur umgesetzt werden Webserver kritischer GP, deren verwendete IS auf Infrastrukturelemente mit Richtlinienkonformität < 50% aufsetzen Eigene Kennzahlen Zusätzlich zu den durch COBIT inspirierten Kennzahlen, wurden einige Kennzahlen speziell für das IT-Bebauungsmanagement katalogisiert. Um einzuschätzen, wie aussagekräftig die Informationen des IT-Bebauungsmanagements sind, ist es hilfreich, die Qualität der Dokumentation zu verfolgen. Es soll hierdurch nicht erzwungen werden die Dokumentation ständig zu aktualisieren, trotzdem ist es hilfreich zu wissen, ob das Modell der Unternehmensarchitektur sehr aktuell oder inzwischen stark veraltet ist. 74

85 6.3 Beispielkennzahlen für das IT-Bebauungsmanagement mit iteraplan Tabelle 6.6: DQ: Dokumentationsqualität Nr. Beschreibung Entsprechung Berechnungsweg DQ1 Dokumentationsgrad Wie vollständig BBE X gesetze Merkmale BBE X dokumentiert ist (welche Merkmale ausgefüllt > Y Zeichen) / +1(wenn Beschreibung sind, Beschreibung lang zugeordneter Merkmale genug) +1 DQ2 ØDokumentationsgrad Wie vollständig die Dokumentationsgrad BBE durchschnittlich jedes einzelnen BBE / dokumentiert sind BBE gesamt DQ3 alte IST-Dokumentation Anzahl IST-BBE, die IST-BBE mit Änderungsdatum > 6 Monate seit mehr als 6 Monaten nicht aktualisiert wurden DQ4 alte PLAN- Dokumentation DQ5 alte SOLL- Dokumentation Anzahl PLAN-BBE, die seit mehr als 6 Monaten nicht aktualisiert wurden Anzahl SOLL-BBE, die seit mehr als 6 Monaten nicht aktualisiert wurden PLAN-BBE mit Änderungsdatum > 6 Monate SOLL-BBE mit Änderungsdatum > 6 Monate Besonders bei der Einführung des IT-Bebauungsmanagements ist es wichtig, die dazugehörigen Methoden im Unternehmen zu etablieren. Folgende Kennzahlen geben einen Hinweis darauf, in welchem Umfang iteraplan für welche Aufgaben benutzt wird. Tabelle 6.7: NV: Nutzungsverhalten Nr. Beschreibung Entsprechung Berechnungsweg NV1 Aktivität allgemein wie aktiv das EAM- unabhängiger Logins; Suchanfragen; Werkzeug allgemein genutzt wird Auswertungen; geänderte BBE NV2 Änderungsrate; Lebendigkeit: Istbebauung NV3 Änderungsrate; Lebendigkeit: Planbebauung NV4 Änderungsrate; Lebendigkeit: Sollbebauung wie aktiv das EAM- Werkzeug genutzt wird, um IST-Bebauung zu pflegen wie aktiv das EAM- Werkzeug genutzt wird, um PLAN-Bebauung zu modellieren wie aktiv das EAM- Werkzeug genutzt wird, um SOLL-Bebauung zu modellieren ( geänderte IST-BBE + neuer IST-BBE) / IST-BBE gesamt ( geänderte PLAN- BBE + neuer PLAN- BBE) / PLAN-BBE gesamt ( geänderte SOLL- BBE + neuer SOLL- BBE) / SOLL-BBE gesamt 75

86 6 Konzeption eines Steuerungscockpits In iteraplan können den Bebauungselementen auch Kosten zugeordnet werden. Der aktuelle Stand sowie die Entwicklung dieser Kosten sind die Grundlage für strategische Entscheidungen. Eine andere Möglichkeit wäre es, geplante Kosten in iteraplan mit operativen Lizenzkosten, Entwicklungskosten sowie Projektkosten zu vergleichen. Tabelle 6.8: KO: Kosten Nr. Beschreibung Entsprechung Berechnungsweg KO1 Kosten BBE X Kosten, die für BBE X Kosten des BBE X derzeit anfallen KO2 Kosten IS-Domäne X Kosten, die für IS- Kosten BBE in IS- Domäne X derzeit Domäne X anfallen KO3 Betriebskostenanteil IS Anteil der Betriebskosten Betriebskosten IS X / X IS X bezogen auf Gesamt-Betriebskosten Betriebskosten aller IS KO4 Kosten Geschäftsprozess X Kosten, die Geschäftsprozess X verursacht Kosten des Geschäftsprozess X Durch das IT-Bebauungsmanagement soll sich die Qualität der Bebauung erhöhen. Viele Merkmale einer qualitativ hochwertigen Bebauung finden sich bereits in den COBIT- Kennzahlen wieder. Zusätzlich dazu können folgende Kennzahlen nützlich sein. Tabelle 6.9: QdB: Qualität der Bebauung Nr. Beschreibung Entsprechung Berechnungsweg QdB1 manuelle Schnittstellen Anzahl Schnittstellen, die Automationsgrad manuell besitzen ell QdB2 schlechter Gesundheitszustand QdB3 ØKommunikationskomplexität QdB4 ØStrategiebeitrag der Informationssysteme Anzahl BBE, die Gesundheitszustand schlecht besitzen, gewichtet nach Größe des BBE Schnittstellen zwischen IS (Logische, nicht technische Schnittstellen) wie hoch der Strategiebeitrag der IS durchschnittlich ist Schnittstellen mit Automationsgrad manu- (BBE mit Gesundheitszustand schlecht * BBE Größe) Schnittstellen / IS mit >0 Schnitstellen Strategiebeitrag der einzelnen IS / IS 76

87 6.3 Beispielkennzahlen für das IT-Bebauungsmanagement mit iteraplan Welche Ziele mit dem IT-Bebauungsmanagement erreicht werden sollen ist unterschiedlich. Allgemein strebt man ein besseres Business-Alignment der IT an. Dies macht sich unter anderem in gesteigerter Zufriedenheit in den Fachbereichen oder einer schnelleren Umsetzung von neuen Anforderungen bemerkbar. Tabelle 6.10: VdZ: Validierung der Zielerreichung Nr. Beschreibung Entsprechung Berechnungsweg VdZ1 Nutzer- / Kundenzufriedenheit Kundenzufriedenheit Extern, durch Befragun- mit IS X mit IT-Unterstütztung gen durch IS X VdZ2 Agilität der IT bezüglich Dauer zwischen Erhebung Extern, aus Ticketsys- neuen Anforderungen einer neuen fachtem lichen Anforderung und deren Umsetzung VdZ3 Komplexität reale IST-Komplexität Extern, FunctionPoints; zyklomatische Komplexität; VdZ4 Outsourcinganteil Anteil an IS die von externen IS von externen Dienstleistern be- Dienstleistern VdZ5 Risikobewertung eines Geschäftsprozesses bezüglich seiner IS trieben werden Durchschnittliche Risikobewertung der IS, auf welche der Geschäftsprozess angewiesen ist Risikobewertung der IS, die dem GP zugeordnet sind / IS die dem GP zugeordnet sind Kennzahlensystem für Informationssystem-Bebauungsplaner Um ein Kennzahlensystem zu erstellen, muss die spätere Nutzergruppe und ihre konkreten Ziele bekannt sein (siehe Kapitel 4.4). Hier wird ein Kennzahlensystem für die Gruppe der IS-Bebauungsplaner entworfen. Nach [Han09, S. 101] sind IS-Bebauungsplaner für die Dokumentation und Analyse sowie die strategische Planung und Steuerung der aktuellen und zukünftigen Informationssystem- Bebauung zuständig. Sie managen die Bebauung im Überblick. Bebauungsplaner sorgen dafür, dass Detaildaten aus unterschiedlichen Quellen in hinreichender Qualität, Vollständigkeit und Aktualität sowie in der gleichen Granularität vorliegen. Darauf basierend liefern Bebauungsplaner Antworten auf die Fragen der Nutznießer und gestalten die zukünftige Bebauung. Die IS-Bebauungsplaner benötigen Kennzahlen, die sie bei den folgenden Aufgaben unterstützen (siehe dazu auch Abbildung 6.4). 77

88 6 Konzeption eines Steuerungscockpits 1. Document: Dokumentation der aktuellen IS in hinreichender Qualität und Vollständigkeit. 2. Analyze: Analysieren der aktuellen IS-Bebauung, beantworten von Fragestellungen der Nutznießer. Basierend auf der aktuellen IS-Bebauung werden neue Pläne und Projekte für die Optimierung der IS-Bebauung erstellt. 3. Plan: Planung von zukünftigen Bebauungen. Überprüfen der Qualität dieser Bebauungen. 4. Check: Überprüfen, ob die geplanten Maßnahmen umgesetzt wurden und zu den gewünschten Zielen geführt haben Document Analyze Act Check 2. Plan 3. Abbildung 6.4: Steuerungsbereiche des IS-Bebauungsplaners Zur Unterstützung dieser Aufgaben wurde ein Kennzahlensystem für IS-Bebauungsplaner erstellt (siehe Tabelle 6.11). Dabei wurde versucht eine ausgewogene Sicht auf die Aufgaben des IS-Bebauungsplaners zu erzeugen. In der Praxis muss dies in enger Zusammenarbeit mit den späteren Nutzern erarbeitet werden, damit genau die Kennzahlen erhoben werden, die tatsächlich für die Steuerung nötig sind. Im nächsten Kapitel werden Kennzahlen aus diesem Kennzahlensystem in einem prototypischen Steuerungscockpit für IS-Bebauungsplaner umgesetzt. Dazu werden einige Kennzahlen detaillierter in Form von Kennzahlensteckbriefen beschrieben. 78

89 6.3 Beispielkennzahlen für das IT-Bebauungsmanagement mit iteraplan Tabelle 6.11: Kennzahlensystem für IS-Bebauungsplaner Nr. Beschreibung Entsprechung Berechnungsweg 1. Document: Qualität und Vollständigkeit PO2.A-1 Häufigkeit der Updates des Modells für Unternehmensinformationen Wie intensiv das EAM-Werkzeug eingesetzt wird PO2.A-2 fehlende Verantwortlichkeit Wie viele BBE haben Merkmal Verantwortlichkeit nicht gesetzt? DQ2 ØDokumentationsgrad Wie vollständig die BBE durchschnittlich dokumentiert sind DQ3 alte IST-Dokumentation Anzahl IST-BBE, die seit mehr als 6 Monaten nicht aktualisiert wurden 2. Analyze: Qualität der Bebauung QdB1 manuelle Schnittstellen Anzahl Schnittstellen, die Automationsgrad manuell besitzen PO3.P-1 % der Nichteinhaltung der technologischen % IST-TB deren Richtlinienkonformität Standards < 50% ist PO3.X-3 ØRichtlinienkonformität IS: IST wie richtlinienkonform die IST-IS durchschnittlich sind 3. Plan: Qualität der Planung PO1.P-3 % von IT-Projekten im IT- Projektportfolio, die direkt auf den taktischen IT-Plan zurückverfolgt werden können % IT-Projekte im IT-Projektportfolio, die ein PLAN-IS umsetzen PO2.X-3 Anzahl PLAN-IS Anzahl der PLAN-IS, die erfasst sind PO3.X-4 ØRichtlinienkonformität IS: PLAN wie richtlinienkonform die PLAN-IS durchschnittlich sind 4. Check: Erreichung der Ziele VdZ1 Nutzer- / Kundenzufriedenheit mit IS X Kundenzufriedenheit mit IT- VdZ2 Agilität der IT bezüglich neuen Anforderungen VdZ5 Risikobewertung eines Geschäftsprozesses bezüglich seiner IS Unterstütztung durch IS X Dauer zwischen Erhebung einer neuen fachlichen Anforderung und deren Umsetzung Durchschnittliche Risikobewertung der IS, auf welche der Geschäftsprozess angewiesen ist der geänderten BBE in der letzten Periode BBE ohne gesetzte Verantwortlichkeit Dokumentationsgrad jedes einzelnen BBE / BBE gesamt IST-BBE mit Änderungsdatum > 6 Monate Schnittstellen mit Automationsgrad manuell IST-TB mit Richtlinienkonformität < 50% / TB Richtlinienkonformität der IST-IS / IST-IS Projekte, die Bezug zu PLAN- IS haben / Projekte im IT- Projektportfolio gesamt PLAN-IS Richtlinienkonformität der PLAN-IS / PLAN-IS Extern, durch Befragungen Extern, aus Ticketsystem Risikobewertung der IS, die dem GP zugeordnet sind / IS die dem GP zugeordnet sind 79

90 80

91 7 Prototypische Implementierung eines Steuerungscockpits Zur Validierung der erarbeiteten Konzepte wurde eine prototypische Implementierung eines Steuerungscockpits durchgeführt, die in diesem Kapitel beschrieben wird. Zunächst wird auf die Einschränkungen der prototypischen Implementierung eingegangen. Anschließend wird die Umsetzung der Datenextraktion aus iteraplan beschrieben. Auf Basis dieser extrahierten Daten werden dann einige Kennzahlen erhoben. Abschließend wird gezeigt, wie diese Kennzahlen in Form eines Steuerungscockpits visualisiert wurden. 7.1 Einschränkungen und Zielsetzung Da ein Steuerungscockpit für das Unternehmensarchitekturmanagement Kennzahlen aus unterschiedlichen Bereichen (entsprechend den Sichten der BSC) anzeigen soll, reicht es nicht aus, nur Bebauungsdaten zu verwerten. Je nach Nutzer und Zielsetzung werden Kennzahlen benötigt, die beispielsweise aus Finanzdaten, Kundenbefragungen oder operativen Daten bestehen (siehe Abbildung 6.3 auf Seite 68). Nach [Bau04] bilden Data-Warehouse- Systeme [...] eine effiziente Infrastruktur zur Informationsbereitstellung und weisen deutliche Vorteile gegenüber herkömmlichen Methoden der verteilten Informationssammlung und -aufbereitung auf. Data-Warehouse-Systeme sind das geeignete Instrument, um eine Datenbasis zu errichten, auf deren Grundlage Entscheidungsträger mit Informationen aus allen Unternehmensbereichen versorgt werden können. Im Rahmen der prototypischen Implementierung stand kein bereits aufgesetztes Data- Warehouse zur Verfügung. Auch die Möglichkeit ein neues Data-Warehouse aufzusetzen wurde verworfen, da der Aufwand des Aufbaus und der Population mit fiktiven Daten den Umfang dieser Diplomarbeit überschreiten würde. Die Zielsetzung dieser prototypischen Implementierung besteht zunächst darin, Daten aus dem EAM-Werkzeug iteraplan zu extrahieren. 1 Mit Daten sind hierbei Bebauungselemente und deren Merkmale gemeint. Das flexible Merkmalsystem in iteraplan erlaubt es, für die Kennzahlen nötige Daten als Merkmale der Bebauungselemente abzubilden (siehe auch Abschnitt 5.2.2). Weiterhin werden Kennzahlen erhoben und unter Verwendung der in Abschnitt vorgestellten Darstellungsformen und Gestaltungsregeln visualisiert. 1 Dies kann als Vorstufe eines ETL-Prozesses angesehen werden, der für die angedachte produktive Nutzung in Verbindung mit einem DWH ebenfalls benötigt wird. 81

92 7 Prototypische Implementierung eines Steuerungscockpits 7.2 Datenextraktion aus iteraplan Die Bebauungsdaten müssen aus iteraplan extrahiert werden, um sie für das Controlling zugänglich zu machen. In diesem Abschnitt wird darauf eingegangen, warum dies notwendig ist und was man dabei beachten muss Ausgangssituation Das objekt-relationale Mapping (ORM) und die Datenbankabfragen werden in iteraplan mit Hilfe des Hibernate-Frameworks [Hib08a] realisiert. Die einzelnen Java-Klassen werden durch das Hibernate-Mapping einer Tabelle in der Datenbank zugeordnet (siehe Abbildung 7.1). Hibernate unterstützt verschiedene Verfahren, um Klassenhierarchien zu persistieren. Das in iteraplan verwendete Verfahren ordnet jeder Klasse eine eigene Tabelle zu. Die Verknüpfungen zwischen den Klassen erfolgt durch eine zusätzliche Tabelle. Dies entspricht dem Normalisierungs-Grundsatz und vermeidet unnötige Redundanzen in der Datenbank. Andererseits entsteht durch dieses Vorgehen eine Vielzahl an Tabellen. In der aktuellen iteraplan Version 2.2 werden 64 Tabellen erstellt, davon über 20 Tabellen die lediglich Verknüpfungen darstellen. Abbildung 7.1: Einsatz von Hibernate in iteraplan Das physikalische Datenmodell von iteraplan eins zu eins für die Extraktion von Kennzahlen, Analysen oder die Integration in ein Data-Warehouse zu übernehmen, ist technisch möglich, aber nicht unbedingt praktikabel. Da dort Hibernate als objekt-relationaler Mapper fehlt, müssten die Beziehungen zwischen den Tabellen in jeder SQL-Abfrage explizit 82

93 7.2 Datenextraktion aus iteraplan angegeben werden. Bei der relationalen Speicherung in DWHs vereinfacht man das Schema daher gegebenenfalls und nimmt Redundanzen in Kauf, um die SQL-Abfragen performant und einfach zu halten (vgl. Star-Schema [Bau04]) Anforderungen Für die Extraktion der Daten (Bebauungsdaten und deren Merkmale) aus iteraplan wurden für diese prototypische Implementierung folgende Anforderungen definiert: Tabelle 7.1: Anforderungen Datenexport Anforderung Beschreibung Datenexport Die Daten aus iteraplan müssen sich in eine eigene Datenbank exportieren lassen. Schema-Vereinfachung Das Datenbankschema der exportierten Daten muss sich für Analysen und die Erhebung von Kennzahlen eignen. Bereinigung / Transformation Die Daten müssen beim Export syntaktisch bereinigt werden können (Hinsichtlich des Datenformats; beispielsweise von "Mittel"nach "2") Zeitliche Zuordnung Die exportierten Daten müssen dem Zeitpunkt des Exports zugeordnet werden. Ein Zeitpunkt ist dabei durch ein Datum (Jahr, Monat, Tag) definiert. Mehrere Exporte an einem Tag sind nicht vorgesehen. anpassbare Zeitliche Zuordnung Der Zeitpunkt, dem die exportierten Daten zugeordnet werden, muss in der Benutzeroberfläche konfigurierbar sein. Historisierung Daten, die zu unterschiedlichen Zeitpunkten exportiert wurden, müssen einfach miteinander vergleichbar sein, um zeitraumorientierte Kennzahlen zu ermöglichen Vorstellung BI-Exporter Im Verlauf der Entwicklung von iteraplan wurde bereits der so genannte BI-Exporter erstellt. Der BI-Exporter ist ein Java-Programm, welches die Daten einer iteraplan Installation in vereinfachter und reduzierter Form in eine neue Datenbank exportiert. Dabei bedeutet : Vereinfacht: Das Zielschema weist eine einfachere Struktur auf. Die Anzahl der Tabellen und Relationen wird reduziert, indem das Schema denormalisiert wird (siehe Abbildung 7.2). Die Redundanzen, die dabei auftreten, werden zugunsten der leichteren Auswertbarkeit in Kauf genommen. 83

94 7 Prototypische Implementierung eines Steuerungscockpits Reduziert: Das Zielschema enthält nur Teilbereiche des Gesamtschemas. Beispielsweise werden Hierarchiebeziehungen zwischen Bebauungselementen gleichen Typs entfernt. iteraplan Schema Exportiertes Schema * BuildingBlockType * 1 BuildingBlock 1 * AttributeValue Assignment * BI-Exporter Informationssysteme ID Name Description Attribute1 Value Attribute2 Value Attribute3 Value 1 * Relationen IS_ID TB_ID 1 Abbildung 7.2: Vereinfachung des Datenbankschemas durch den BI-Exporter (Übersicht) Die technische Umsetzung des BI-Exporters basiert auf Hibernate und den Hibernate-Tools [Hib08b]. Hibernate übernimmt das Laden der Daten aus der iteraplan Datenbank unter Verwendung des iteraplan Hibernate-Mappings und stellt diese als Plain Old Java Objects (POJOs) dar. Der BI-Exporter erstellt anhand dieser POJOS ein vereinfachtes Hibernate- Mapping für den Export. Anhand dieses Mappings wird von den Hibernate-Tools das Datenbankschema erzeugt. Anschließend können Vereinfachungen oder Filterungen auf Objektebene durchgeführt werden. Die Objekte werden dann mit JDBC-Statements in das erzeugte Schema persistiert (siehe Abbildung 7.3). BI-Exporter Vereinfachung / Filterung (optional) Export.hbm.xml Datenbankschema erstellen Extraktion «library» Hibernate-Tools.jar Datenbankschema iteraplan Datenbank «library» Hibernate.jar POJOs Laden Export-Daten iteraplan.hbm.xml JDBC-Statements Abbildung 7.3: Funktionsweise des BI-Exporters Problematik der bisherigen Lösung Der BI-Exporter exportiert den aktuellen Stand der Bebauung in eine für Analysezwecke geeignete Form. Wird zu einem späteren Zeitpunkt ein weiterer Export durchgeführt, werden die alten Daten überschrieben. Die exportierten Daten werden nicht historisiert. Auch 84

95 7.2 Datenextraktion aus iteraplan kann nicht nachvollzogen werden, zu welchem Zeitpunkt ein Export erstellt wurde. Für die Darstellung von zeitpunkt- und zeitraumorientierten Kennzahlen im Steuerungscockpit sind aber historische Daten nötig. Folgender Handlungsbedarf besteht also: Den exportierten Daten muss ein Zeitpunkt zugeordnet werden Zu verschiedenen Zeitpunkten exportierte Daten müssen miteinander vergleichbar sein Identifikation und Bewertung von Lösungsalternativen In diesem Abschnitt werden Lösungsmöglichkeiten für die offenen Anforderungen vorgestellt und deren Vor- und Nachteile bewertet. Multiple Schemas Im BI-Exporter kann der Name des Datenbankschemas konfiguriert werden, in welche der Export erfolgen soll. Man kann bei jedem Export einen eindeutigen Namen vergeben, indem das aktuelle Datum in den Namen eingefügt wird. Beispielsweise für einen Export, der am 01. März 2009 stattgefunden hat: biexport_09_03_01. Vorteile: Bei dieser Lösung muss der BI-Exporter nicht verändert werden. Die Zuordnung des Exports zu einem Zeitpunkt und die Historisierung der Exporte wird durch den Namen des Schemas erreicht. Nachteile: Vor jedem Export muss ein leeres Datenbankschema mit dem jeweiligen Namen angelegt werden. Bei der Auswertung der Daten muss für jeden Zeitpunkt, den man zur Berechnung der Kennzahlen mit einbezieht, ein eigenes Schema angesprochen werden, was sehr aufwändig ist. Zudem besteht dieser Aufwand nicht nur einmalig, sondern vor und nach jedem Exportvorgang. Zeitstempel Um die exportierten Daten einem Zeitpunkt zuzuordnen, kann an jeden Datensatz ein Feld angefügt werden, welches den aktuellen Zeitpunkt enthält. Da für den Zeitpunkt ein Datum ausreichend ist, kann in jeder Tabelle eine zusätzliche Spalte vom Datentyp Date angefügt und beim Exportieren befüllt werden. Jeder Datensatz ist dann einem eindeutigen Zeitpunkt zugeordnet. Vorteile: Alle exportierten Daten befinden sich in einem Datenbankschema. Beim Exportieren ist kein weiterer Aufwand nötig. Welchem Zeitpunkt der Export zugeordnet werden soll, wird im BI-Exporter festgelegt. Nachteile: Der BI-Exporter muss so modifiziert werden, dass die exportierten Daten einem Zeitpunkt zugeordnet sind. Dies sollte mit relativ geringem Aufwand realisierbar sein. 85

96 7 Prototypische Implementierung eines Steuerungscockpits Hibernate Envers Hibernate Envers [Hib08c] ist seit Ende 2008 ein Core Module von Hibernate. Bisher gibt es aber keine als Stabil veröffentlichte Version von Hibernate, die Envers enthält. Envers bietet eine einfache Möglichkeit Entitäten zu versionieren, welche mit Hibernate verwaltet werden. Dazu wird lediglich die an die Java-Klasse angefügt. Envers erzeugt für diese Klasse eine eigene Tabelle mit Suffix _AUD, in der die historischen Daten abgelegt werden. Nach jeder erfolgreichen Transaktion auf die zu versionierenden Entitäten, erzeugt Envers ähnlich einem Versionskontrollsystem eine neue Revision. Ein Vorteil von Envers ist, dass es den Umgang mit den derzeit aktuellen Daten nicht beeinflusst. Diese werden weiterhin mit Hibernate gespeichert und geladen. Envers versioniert nicht nur einfache Datentypen wie Zeichenfolgen, Zahlen oder Datumswerte, sondern auch die Beziehungen zwischen einzelnen Entitäten. Daher ist es mit dem Envers-Java-Interface möglich, Abfragen zu formulieren, die den Datenstand zu einer gewählten Revision bzw. einem gewählten Datum widerspiegeln. Variante 1: Um Hibernate Envers im BI-Exporter zu nutzen, müsste dessen Architektur stark verändert werden. Derzeit werden die POJOs, die mit Hibernate aus der iteraplan Datenbank geladen werden, von Hibernate gelöst und im BI-Exporter vereinfacht und gefiltert. Zum Speichern der Daten werden JDBC-Statements verwendet. Um Envers überhaupt einzusetzen, müsste das Speichern der Daten in die Exportdatenbank ebenfalls mit Hibernate realisiert werden. Vorteile: Historisierung erfolgt automatisch durch Hibernate Envers. Nachteile: Der BI-Exporter muss stark angepasst werden. Der Zeitpunkt einer Revision muss zusätzlich manuell in die Datenbank eingefügt werden. Bei SQL-Abfragen muss der aktuelle Stand manuell mit den historisierten Versionen verknüpft werden. Variante 2: Ein anderer Ansatz ist es, Hibernate Envers bereits in iteraplan selbst einzusetzen. Somit wird jede Änderung in iteraplan versioniert. Durch Envers ist es dann möglich, Exporte rückwirkend auf einer bestimmten Version durchzuführen. Es ist allerdings fraglich, ob Envers mit dem umfangreichen Datenmodell von iteraplan zurechtkommt und wie stark die Performance der Datenbankzugriffe durch die Versionierung der Daten und Beziehungen leidet. Vorteile: Historisierung erfolgt automatisch durch Hibernate Envers. Datenexport kann auch rückwirkend durchgeführt werden. Nachteile: Der BI-Exporter ist trotzdem nötig, da das Datenschema vereinfacht werden soll. Zusätzlich muss der BI-Exporter für die Zusammenarbeit mit Envers angepasst werden. Envers verdoppelt die Anzahl der Tabellen, die Schemavereinfachung beim Export wird nochmals aufwändiger. 86

97 7.2 Datenextraktion aus iteraplan Auswahl und Umsetzung einer Lösung In Zusammenarbeit mit einem Experten von iteratec wurden die Lösungsmöglichkeiten besprochen und eine Möglichkeit für die Umsetzung ausgewählt. Die ausschlaggebenden Gründe für die getroffene Entscheidung werden hier nochmals kurz erläutert. Die Verwendung eines eigenen Datenbankschemas für jeden Exportzeitpunkt ist sehr aufwändig. Würde man diese Form der Datenhistorisierung direkt als Datenquelle für das Steuerungscockpit nutzen, so müsste man beispielsweise für ein Liniendiagramm, das die Entwicklung einer Kennzahl in den letzten zwölf Monaten zeigt, Verbindungen zu zwölf Datenbankschemas aufbauen. Die Verwendung von Hibernate Envers wäre zwar eine interessante Lösungsmöglichkeit, dazu würde aber eine komplette Änderung der Architektur des BI-Exporters nötig sein. Es ist aber weiter zu verfolgen, ob Hibernate Envers auf der Ebene von iteraplan für eine Historisierung der Bebauungsdaten einsetzbar ist. Es wurde daher die Entscheidung getroffen, die Lösungsmöglichkeit mit Zeitstempel umzusetzen. Der Grund hierfür ist, dass die Änderungen am BI-Exporter sehr überschaubar sind. Die Architektur muss nicht verändert werden. Weiterhin liegen die exportierten Daten bei dieser Lösung in einer Form vor, die sich gut für die Verwendung mit einem Steuerungscockpit eignet. Der Aufwand für die Erhebung von Kennzahlen ist hier geringer als bei den anderen beiden Lösungsmöglichkeiten. Umsetzung Die Umsetzung besteht aus zwei Teilschritten. Zunächst muss das erstellte Schema verändert werden. Jede Tabelle soll eine zusätzliche Spalte exporttime enthalten. Dazu wird die Java-Methode angepasst, welche das Hibernate-Mapping für den Export erstellt. Das neue Mapping enthält für jede Klasse ein Hibernate-Property mit Namen exporttime vom Typ date. Listing 7.1: Ausschnitt aus dem Hibernate-Mapping für den Export < c l a s s name=" Informationsystemrelease" t a b l e=" Informationsystemrelease"> <i d name="id" column="id" type=" integer"> <g e n e r a t o r c l a s s="native" /> </ id> <property name="name" type="string" /> <property name="exporttime" type="date" /> [... ] </ c l a s s> 87

98 7 Prototypische Implementierung eines Steuerungscockpits Die Hibernate-Tools erstellen Anhand dieses Mappings das Schema der Exportdatenbank (siehe dazu auch Abbildung 7.3 auf Seite 84). Für jedes exportierte Bebauungselement wird eine Tabelle erstellt, in der neben den Spalten für den Namen, die Beschreibung und die zugeordneten Merkmale, nun auch eine Spalte exporttime vorhanden ist. Der zweite Schritt der Umsetzung besteht darin, beim Export der Daten in das Schema die Spalte exporttime mit dem ausgewählten Datum zu befüllen. Dazu wird das Datum, welches als java.util.date vorliegt (auswählbar über die Oberfläche) mit Hilfe eines java.text.simpledateformat formatiert. Listing 7.2: Formatierung des Datums in eine lesbare Form SimpleDateFormat dateformatter = new SimpleDateFormat ( " yyyy.mm.dd" ) ; // Date wird s p ä t e r per GUI mit JdateChooser ausgewählt Date date = new Date ( ) ; // e x p o r t t i m e i s t " " f ü r 10. März 2009 S t r i n g exporttime = dateformatter. format ( date ) ; Vor dem Export der Daten wird geprüft, ob zu dem ausgewählten Datum bereits ein Export stattgefunden hat. Wenn dies der Fall ist, wird der Export abgebrochen. Falls zu dem Datum noch kein Export vorliegt, werden die Daten mit JDBC-Statements in die Datenbank übertragen. Die exportierten Daten liegen somit in der gewünschten denormalisierten Form vor und sind einem bestimmten Datum zugeordnet (siehe Abbildung 7.4 sowie Abbildung A1 im Anhang). Auf dieser Basis können nun Kennzahlen erstellt werden. Welche Kennzahlen in dieser prototypischen Implementierung erstellt wurden und wie sie dargestellt werden, wird in den folgenden Abschnitten beschrieben. Abbildung 7.4: Ausschnitt der Export-Datenbank des BI-Exporters 88

99 7.3 Erstellung der Kennzahlen 7.3 Erstellung der Kennzahlen In diesem Abschnitt werden zunächst einige der umgesetzten Kennzahlen detailliert in Form von Kennzahlensteckbriefen beschrieben. Anschließend wird an einigen Beispielen beschrieben, wie die Kennzahlen aus den exportierten Daten erhoben werden Beschreibung der umgesetzten Kennzahlen Die umgesetzten Kennzahlen sind an das Kennzahlensystem für den IS-Bebauungsplaner angelehnt, welches in Abschnitt definiert wurde. Dort wurden die Kennzahlen nur grob umschrieben, daher erfolgt hier eine detailliertere Dokumentation einiger Kennzahlen in Form von Kennzahlensteckbriefen. Der Kennzahlensteckbrief wird nur soweit ausgefüllt, wie es für diese prototypische Implementierung sinnvoll ist. Beispielsweise ist die Quelle der Daten immer iteraplan und die Messfrequenz stets monatlich. Diese redundanten Eigenschaften werden daher nicht in jedem Steckbrief explizit angegeben. Für eine praktische Nutzung sollte aber der ursprüngliche und vollständige Kennzahlensteckbrief verwendet werden (siehe Seite 21). Beschreibung Name: Beschreibung: Toleranzwerte: Zielwert: Eskalationsregeln: Datenaufbereitung Berechnungsweg: Präsentation Darstellung: Aggregationsstufen: Archivierung: Tabelle 7.2: Fehlende Verantwortlichkeit Fehlende Verantwortlichkeit Bebauungselemente, bei denen das Merkmal Verantwortlichkeit nicht gesetzt ist. schlecht: über 50% der Bebauungselemente fehlt das Merkmal Verantwortlichkeit. mäßig: 20-50% gut: weniger als 20% Nahezu 0%; fallend Bei Erhöhung des Wertes über 60% ist die Verantwortlichkeit bei den Datenlieferanten explizit anzufordern, gegebenenfalls muss sie zunächst festgelegt werden. Bebauungselemente ohne gesetzte Verantwortlichkeit zeitlicher Verlauf; aktueller Stand mit Toleranzwerten Für alle Bebauungselemente oder nur für Informationssysteme, Technische Bausteine, Schnittstellen oder Infrastruktur ja 89

100 7 Prototypische Implementierung eines Steuerungscockpits Tabelle 7.3: Durchschnittlicher Dokumentationsgrad Beschreibung Name: Ø Dokumentationsgrad Beschreibung: Wie vollständig die Bebauungselemente im Durchschnitt dokumentiert sind. Toleranzwerte: schlecht: unter 50% Zielwert: Eskalationsregeln: Datenaufbereitung Berechnungsweg: Präsentation Darstellung: Aggregationsstufen: Archivierung: mäßig: 50-80% gut: über 80% 70%; steigend unter 50%: Datenlieferanten ansprechen unter 40%: Eskalation an EAM-Verantwortlichen Dokumentationsgrad jedes einzelnen BBE / BBE gesamt Dokumentationsgrad eines BBE ist dabei: ausgefülltemerkmale zugeordnetemerkmale aktueller Stand mit Toleranzwerten; Vergleich zum Vormonat Für alle Bebauungselemente oder nur für Informationssysteme, Technische Bausteine, Schnittstellen oder Infrastruktur ja Tabelle 7.4: Nichteinhaltung technologische Standards Beschreibung Name: % Nichteinhaltung technologischer Standards Beschreibung: % IST-Technische Bausteine, deren Richtlinienkonformität < 50% ist. Toleranzwerte: - Zielwert: möglichst niedrig; sinkend Eskalationsregeln: - Datenaufbereitung Berechnungsweg: Technische Bausteine mit Richtlinienkonformität < 50% / Technische Bausteine Präsentation Darstellung: Aggregationsstufen: Archivierung: zeitlicher Verlauf; Vergleich zum Vormonat Für alle Technischen Bausteine oder nur für IST oder PLAN Technische Bausteine ja 90

101 7.3 Erstellung der Kennzahlen Tabelle 7.5: Richtlinienkonformität Informationssysteme Beschreibung Name: ØRichtlinienkonformität der Informationssysteme Beschreibung: Durchschnittlicher Wert Richtlinienkonformität der Technischen Bausteine, die den Informationssystemen zugeordnet sind. Toleranzwerte: schlecht: unter 50% Zielwert: Eskalationsregeln: Datenaufbereitung Berechnungsweg: mäßig: 50-75% gut: über 75% 70%; steigend ØRichtlinienkonformität der geplanten IS sollte über 60% liegen. Richtlinienkonformität der Informationssysteme / Informationssysteme dabei ist Richlinienkonformität eines Informationssystems RKI: RKI = m i=n RKT B i ZT B Präsentation Darstellung: Aggregationsstufen: Archivierung: mit ZT B = dem IS zugeordnete Technische Bausteine n..m und RKT B = Richtlinienkonformität des Technischen Bausteins zeitlicher Verlauf; aktueller Stand mit Toleranzwerten Für alle Informationssysteme oder nur für IST- oder PLAN-IS. ja Tabelle 7.6: Manuelle Schnittstellen Beschreibung Name: Manuelle Schnittstellen Beschreibung: Anzahl der Schnittstellen, die Automationsgrad manuell besitzen. Toleranzwerte: - Zielwert: möglichst wenig, nur Vertretbar, wenn keine Automatisierung möglich ist; sinkend Eskalationsregeln: - Datenaufbereitung Berechnungsweg: Schnittstellen mit Automationsgrad manuell Präsentation Darstellung: zeitlicher Verlauf; Vergleich zum Vormonat Aggregationsstufen: Für alle Schnittstellen oder nur für Schnittstellen zwischen IST-IS oder nur für Schnittstellen die mit PLAN-IS verbunden sind Archivierung: ja 91

102 7 Prototypische Implementierung eines Steuerungscockpits Erhebung der Kennzahlen Die definierten Kennzahlen sollen aus den exportierten Daten erstellt werden. Grundsätzlich kann die Berechnung der Kennzahlen direkt in der Datenbank, im Programm des Endbenutzers (wie etwa Dashboard-, Report-, oder OLAP-Software) oder in einem eigenständigen Programm zur Kennzahlenberechnung erfolgen. Möglichkeiten der Kennzahlenberechnung Mit Hilfe eines Views lassen sich in der Datenbank Abfragen auf die Daten speichern. Einfache Kennzahlen lassen sich in Form von Views berechnen. Beispielsweise zeigt folgende SQL-Abfrage zu jedem Zeitpunkt, an dem ein Export erfolgte, die Anzahl der zu dieser Zeit gepflegten Informationssysteme an. Listing 7.3: Erstellung von Kennzahlen mittels Views SELECT exporttime, COUNT( ) AS GESAMTANZAHL_IS_ISTPLANSOLL FROM i n f o r m a t i o n s y s t e m r e l e a s e i s r GROUP BY i s r. exporttime ; Diese Abfrage kann in einem View Anz_IS_istplansoll gespeichert werden. Fortan lässt sich mit folgender Datenbankabfrage das gleiche Ergebnis erzielen. Listing 7.4: Aufruf des Views SELECT FROM Anz_IS_istplansoll ; Die Logik der Kennzahlenberechnung muss nicht mehr in jeder Abfrage (die z.b. aus dem Visualisierungstool erfolgt) mitgesendet werden. Zudem stehen Views mehreren Benutzern zur Verfügung, die Kennzahlen lassen sich für mehrere Endanwendungen (Dashboard, Reports, etc.) zentral definieren. Moderne Datenbanksysteme enthalten die wichtigsten mathematischen Funktionen (SUM, COUNT, AVG, MAX, MIN,... ). Trotzdem stößt man bei komplexen Berechnungen und Verknüpfung vieler Tabellen an eine Grenze, ab der die verwendeten SQL-Abfragen nicht mehr vernünftig lesbar sind. Eine Alternative zu der Kennzahlenberechnung mit SQL- Abfragen ist die Berechnung in der Endanwendung selbst. Gängigen BI-Tools bieten die Möglichkeit Datenbestände zu importieren, um diese weiter zu verarbeiten und darauf basierende Kennzahlen zu definieren und zu erheben. Der Datenimport erfolgt meist durch SQL-Abfragen an ODBC-Datenquellen 2. Hierdurch kann eine erste Auswahl und Filterung vorgenommen werden (Beispielsweise lassen sich die Informationssysteme durch ihre Spalte status in Ist- Plan- und Soll-Informationssysteme aufteilen). Die weitere Berechnung erfolgt dann im BI-Tool selbst. Eine weitere Möglichkeit wäre es, die Kennzahlen nicht im selben Tool, welches zur Anzeige verwendet wird zu berechnen, sondern ein eigenes Programm zur Berechnung der Kennzahlen zu verwenden. Auf die Daten wird weiterhin mittels SQL-Abfragen zugegriffen. Die 2 Open Database Connectivity (ODBC) ist eine standardisierte Schnittstelle für den Datenbankzugriff 92

103 7.3 Erstellung der Kennzahlen Berechnung der Kennzahlen erfolgt aber in einer höheren Programmiersprache. Die Kennzahlen werden anschließend in eine geeignete Datenbank exportiert. Der Vorteil dabei ist, dass komplexe Berechnungen nicht mit SQL, sondern einer höheren Programmiersprache durchgeführt werden und die Kennzahlen zentral definiert sind. Der Aufwand ist dabei aber höher als bei den anderen Lösungen. Umsetzung Für diese prototypische Implementierung wurde der erste und zweite Ansatz kombiniert. Es wurden Views erzeugt, welche eine erste Auswahl und Filterung vornehmen. Die Kennzahlen werden durch die SQL-Abfragen beim Import der Daten in das Steuerungscockpit, sowie im Steuerungscockpit selbst erzeugt. Folgendes View enthält beispielsweise nur Informationssysteme, die zum Zeitpunkt des Exports den Status Ist zugeordnet hatten. Listing 7.5: View mit IST-IS CREATE VIEW IST_IS AS SELECT FROM i n f o r m a t i o n s y s t e m r e l e a s e i s r WHERE i s r. s t a t u s = "typeofstatus_current" ; Die Kennzahl Ø Dokumentationsgrad der IS wird nicht mit Hilfe eines Views, sondern teilweise mit SQL-Abfragen und teilweise im Steuerungscockpit selbst berechnet. Die Kennzahl ist definiert als: Ø Dokumentationsgrad der IS = ausgefüllte Merkmale zugeordnete M erkmale Da für andere Kennzahlen bereits die Anzahl der fehlenden Merkmale erhoben wird, ist es sinnvoll die Formel umzuformen: Ø Dokumentationsgrad der IS = zugeordnete Merkmale fehlendemerkmale zugeordnete M erkmale Das Steuerungscockpit definiert SQL-Abfragen, die zu jedem Export-Zeitpunkt ermitteln, wie viele Informationssysteme ein bestimmtes Merkmal nicht ausgefüllt haben. Beispielsweise gibt folgende SQL-Abfrage die Anzahl der Informationssysteme zurück, bei denen das Merkmal Verantwortlichkeit nicht ausgefüllt ist. Listing 7.6: Anzahl Informationssysteme mit fehlender Verantwortlichkeit SELECT COUNT( ) as f e h l e n d e _ V e r a n t w o r t l i c h k e i t FROM i n f o r m a t i o n s y s t e m r e l e a s e i s r WHERE i s r. V e r a n t w o r t l i c h k e i t IS NULL GROUP BY i s r. exporttime ; 93

104 7 Prototypische Implementierung eines Steuerungscockpits Die weitere Berechnung wird im Steuerungscockpit durchgeführt. Die Anzahl der zum jeweiligen Zeitpunkt gepflegten Informationssysteme wird mit der Anzahl der Merkmale jedes Informationssystems multipliziert. Daraus ergibt sich die Anzahl der gesamt zugeordneten Merkmale: zugeordnete Merkmale = Anzahl IS Merkmale eines IS Die Anzahl k der fehlenden Merkmale vom Typ i (i 1..n) ergibt summiert die gesamte Anzahl der fehlenden Merkmale: fehlende Merkmale = n i=1 k i Der Ø Dokumentationsgrad der IS kann nun für jeden Export-Zeitpunkt errechnet und anschließend grafisch dargestellt werden. 7.4 Visualisierung der Kennzahlen Ein wesentlicher Bestandteil des Steuerungscockpits ist die grafische Darstellung der Kennzahlen. Es wurde Wert darauf gelegt, keine vorgefertigten Standard-Diagramme oder zu detailverliebte Ampel- oder Tachometer-Darstellungen zu verwenden. Das Ziel war es, die in den Kennzahlen enthaltene Information möglichst klar und einfach zu kommunizieren Verwendete Werkzeuge Für diese prototypische Implementierung wird zur Darstellung der Kennzahlen Excel 2003 verwendet. Zwar ist Excel nicht speziell für die Darstellung von Dashboards ausgelegt, durch die enthaltenen Diagramme und die Möglichkeit Excel durch Add-Ins zu erweitern, kann es aber auch für diesen Bereich eingesetzt werden. Nach einer Studie 3 des Instituts für Business Intelligence [IBI08] verwenden 82% der befragten mittelständischen Unternehmen Excel für die Unternehmenssteuerung und das Controlling (vgl. auch [CIO09]). In größeren Unternehmen, für welche ein Steuerungscockpit im Bereich des Unternehmensarchitekturmanagements gedacht ist, werden dedizierte BI- Werkzeuge eingesetzt. Laut einer Studie 4 von Gartner [Gar09] führen Business Intelligence Anwendungen das vierte Jahr in Folge die Liste der Top-Technologien der befragten CIOs an. Für große Unternehmen ist eine rein Excel-basierte Lösung nicht denkbar, da Anforderungen wie Multi-User-Fähigkeit, Anbindung verschiedener Datenquellen und vor allem Teilnehmer; 56% aus kleinen Unternehmen (<50m EUR); 31% aus mittelgroßen Unternehmen (50m bis 1.000m EUR) 4 1,500 CIOs weltweit 94

105 7.4 Visualisierung der Kennzahlen die Integration in das bestehende BI-Umfeld von Excel ohne Zusatzprodukte nicht hinreichend erfüllt werden. Um das Kennzahlensystem in dieser prototypischen Implementierung sinnvoll darzustellen, ist Excel aber gut geeignet. Import der Daten in Excel Mit Excel ist es möglich, externe Daten in die Arbeitsmappe zu importieren. Dazu wird eine ODBC-Datenquelle angelegt, welche auf die Exportdatenbank verweist. ODBC dient als Abstraktionsschicht zwischen Excel und der verwendeten Datenbank (siehe Abbildung 7.5). In Excel werden SQL-Abfragen auf die ODBC-Datenquelle ausgeführt. Die Ergebnismengen werden in Tabellenform ausgegeben. Excel erlaubt es, sämtliche externe Datenquellen mit einem Befehl zu aktualisieren. Dabei werden Berechnungen, die sich auf den Bereich der externen Daten beziehen, neu durchgeführt. Die Visualisierungen passen sich daher automatisch den neu importierten Daten an. Excel Exportdatenbank ODBC-Datenquelle SQL-Abfrage wird an ODBC-Datenquelle geschickt Ergebnis wird als Excel-Tabelle ausgegeben Darstellungen werden automatisch aktualisiert Abbildung 7.5: Import der Daten in Excel Sparklines for Excel Die nachfolgenden Visualisierungen wurden mit Hilfe der Sparklines for Excel [Rim09] umgesetzt. Sparklines for Excel ist ein Open-Source-Projekt von Fabrice Rimlinger, welches Excel 2003 und 2007 mit User Defined Functions (UDFs) 5 erweitert, mit welchen unter anderem Sparklines und Bullet-Graphs (siehe Abschnitt 3.4.2) erzeugt werden können. Um eine Sparkline in Excel darzustellen, könnte man ein Standard-Liniendiagramm erstellen und dieses weiter bearbeiten. Die Achsen (X und Y), Gitternetz-Hilfslinien, die Legende und der schattierte Hintergrund müssen entfernt werden. Übrig bleibt nur noch der Linienverlauf selbst. Das Diagramm muss dann noch verkleinert und ausgerichtet werden. Auch komplexere Darstellungen wie etwa ein Bullet-Graph lassen sich mit einigen Excel-Tricks umsetzen (vgl. [Kyd08]). Generell ist es aber sehr aufwändig, für ein Dashboard geeignete Darstellungen mit reinen Excel-Diagrammen zu entwerfen. 5 Benutzerdefinierte Funktionen 95

106 7 Prototypische Implementierung eines Steuerungscockpits Sparklines for Excel wählt einen anderen Ansatz, um Darstellungen zu erzeugen. Dabei werden keine Excel-Diagramme verwendet, sondern einzelne Grafiken (Linien, Rechtecke, Textfelder, etc.) zusammengesetzt und in die ausgewählte Tabellenzelle eingefügt. Die Grafiken werden dabei an die Größe der Zelle angepasst. Wenn die Arbeitsmappe neu berechnet wird, werden sämtliche Grafiken gelöscht und unter Berücksichtigung der aktuellen Werte neu gezeichnet. Die einzelnen Darstellungstypen sind als User Defined Functions in VBA programmiert und können wie die Standardfunktionen (wie SUMME, ANZAHL, MAX, etc.) benutzt werden, indem sie in einer Tabellenzelle mit vorangestelltem = und den jeweiligen Parametern aufgerufen werden. Für das komfortable Erstellen der Darstellungen ist auch eine Toolbar mit den angebotenen Chart-Typen und eine Benutzeroberfläche für die Eingabe der Parameter und Datenbereiche vorhanden (siehe Abbildung 7.6). Abbildung 7.6: Liniendiagramm mit Sparklines for Excel Übersicht über das Steuerungscockpit In diesem Abschnitt wird kurz auf die verwendeten Darstellungsformen eingegangen und erläutert, warum sie in dieser Form eingesetzt wurden. Anschließend wird der Aufbau des Steuerungscockpits erklärt. Absolute Kennzahlen wie etwa Anzahl geplanter IS wurden als Sparkline dargestellt. Der Wert des aktuellen Monats und die Differenz zum Vormonat werden als Text angezeigt (siehe Abbildung 7.7 Hier wird nochmals deutlich, dass sich Sparklines nicht dafür eignen den detaillierten Verlauf einer Kennzahl zu visualisieren. Aufgrund der fehlenden Koordinatenachsen und Skalen ist es nicht möglich einen historischen Wert genau abzulesen. Das ist hier aber auch nicht nötig, da die Darstellung lediglich die ungefähre Entwicklung der Kennzahl darstellen soll. Jan 08 - Mai 08 Mai 08 zum Vormonat Anzahl geplanter IS: Abbildung 7.7: Sparkline der geplanten Informationssysteme 96

Strategisches IT-Management mit dem COBIT Framework. Markus Gronerad, Scheer Management 1.8.2014

Strategisches IT-Management mit dem COBIT Framework. Markus Gronerad, Scheer Management 1.8.2014 Strategisches IT-Management mit dem COBIT Framework Markus Gronerad, Scheer Management 1.8.2014 Was ist strategisches IT-Management? IT-Management Das (operative) IT-Management dient der Planung, Beschaffung,

Mehr

Enterprise Architecture Management (EAM)

Enterprise Architecture Management (EAM) your IT in line with your Business Enterprise Architecture Management (EAM) Unternehmensziele im Mittelpunkt der Informationstechnologie 2015 SYRACOM AG Part of Consileon Group Motivation für EAM In vielen

Mehr

COBIT. Proseminar IT Kennzahlen und Softwaremetriken 19.07.2010 Erik Muttersbach

COBIT. Proseminar IT Kennzahlen und Softwaremetriken 19.07.2010 Erik Muttersbach COBIT Proseminar IT Kennzahlen und Softwaremetriken 19.07.2010 Erik Muttersbach Gliederung Motivation Komponenten des Frameworks Control Objectives Goals Prozesse Messen in CobiT Maturity Models Outcome

Mehr

EAM einfach und effektiv

EAM einfach und effektiv EAM einfach und effektiv Enterprise Architecture Management (EAM) kann wesentlich zur Gestaltung und Umsetzung von Unternehmenszielen beitragen. Dies gelingt in der Praxis aber selten. Viele EAM-Initiativen

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

www.competence-site.de Seite 1

www.competence-site.de Seite 1 Virtual Roundtable zu Enterprise Architecture Management (EAM): Ziele und Einsatzperspektiven für Enterprise Architektur-Management in IT-Organisationen Name: Prof. Dr. Robert Winter Funktion/Bereich:

Mehr

(Thema) Realisierung eines kennzahlenbasierten Steuerungskonzepts für das Change Management. Bachelorarbeit

(Thema) Realisierung eines kennzahlenbasierten Steuerungskonzepts für das Change Management. Bachelorarbeit (Thema) Realisierung eines kennzahlenbasierten Steuerungskonzepts für das Change Management Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5 Das Management von Informations- Systemen im Wandel Die Informations-Technologie (IT) war lange Zeit ausschließlich ein Hilfsmittel, um Arbeitsabläufe zu vereinfachen und Personal einzusparen. Sie hat

Mehr

your IT in line with your Business Geschäftsprozessmanagement (GPM)

your IT in line with your Business Geschäftsprozessmanagement (GPM) your IT in line with your Business Geschäftsprozessmanagement (GPM) Transparenz schaffen und Unternehmensziele effizient erreichen Transparente Prozesse für mehr Entscheidungssicherheit Konsequente Ausrichtung

Mehr

Kapitel 2 Unternehmensarchitektur I

Kapitel 2 Unternehmensarchitektur I Kapitel 2 Unternehmensarchitektur I Software Architecture, Quality, and Testing FS 2015 Prof. Dr. Jana Köhler jana.koehler@hslu.ch Gesamtüberblick I. Unternehmensarchitektur - Enterprise Architecture (EA)

Mehr

your IT in line with your Business Architekturgestützte Business- und IT- Planung

your IT in line with your Business Architekturgestützte Business- und IT- Planung your IT in line with your Business Architekturgestützte Business- und IT- Planung Grundstein für die erfolgreiche IT-Governance Ausrichtung der IT an Unternehmenszielen und -prozessen Effektive, effiziente

Mehr

EAM Ein IT-Tool? MID Insight 2013. Torsten Müller, KPMG Gerhard Rempp, MID. Nürnberg, 12. November 2013

EAM Ein IT-Tool? MID Insight 2013. Torsten Müller, KPMG Gerhard Rempp, MID. Nürnberg, 12. November 2013 EAM Ein IT-Tool? MID Insight 2013 Torsten Müller, KPMG Gerhard Rempp, MID Nürnberg, 12. November 2013 ! Wo wird EA eingesetzt? Welchen Beitrag leistet EA dabei? Was kann EAM noch? Ist EAM nur ein IT-Tool?

Mehr

Social Media trifft Business

Social Media trifft Business Social Media trifft Business Intelligence Social Media Analysis als Teil der Unternehmenssteuerung Tiemo Winterkamp, VP Global Marketing Agenda Social Media trifft Business Intelligence Business Intelligence

Mehr

ITSM-Health Check: die Versicherung Ihres IT Service Management. Christian Köhler, Service Manager, Stuttgart, 03.07.2014

ITSM-Health Check: die Versicherung Ihres IT Service Management. Christian Köhler, Service Manager, Stuttgart, 03.07.2014 : die Versicherung Ihres IT Service Management Christian Köhler, Service Manager, Stuttgart, 03.07.2014 Referent Christian Köhler AMS-EIM Service Manager Geschäftsstelle München Seit 2001 bei CENIT AG

Mehr

1 Einleitung 1. 2 Entwicklung und Bedeutung von COBIT 7

1 Einleitung 1. 2 Entwicklung und Bedeutung von COBIT 7 vii 1 Einleitung 1 Teil I COBIT verstehen 5 2 Entwicklung und Bedeutung von COBIT 7 2.1 ISACA und das IT Governance Institute....................... 7 2.2 Entstehung von COBIT, Val IT und Risk IT....................

Mehr

Enterprise Architecture Management für Krankenhäuser. Transparenz über die Abhängigkeiten von Business und IT

Enterprise Architecture Management für Krankenhäuser. Transparenz über die Abhängigkeiten von Business und IT Enterprise Architecture Management für Krankenhäuser Transparenz über die Abhängigkeiten von Business und IT HERAUSFORDERUNG Gestiegener Wettbewerbsdruck, höhere Differenzierung im Markt, die konsequente

Mehr

iteratec Business Breakfast Optimierung von Applikationslandschaften

iteratec Business Breakfast Optimierung von Applikationslandschaften iteratec Business Breakfast Optimierung von Applikationslandschaften Best Practice Erfahrungen Lothar Weber Zürich, 11.06.2014 Agenda Optimierung von Applikationslandschaften 8:00 8:05 Begrüssung 8:05

Mehr

Vortrag zum Thema E C G - 1 - Das CobiT Referenzmodell für das Steuern von IT-Prozessen. - Das CobiT Referenzmodell für das Steuern von IT-Prozessen -

Vortrag zum Thema E C G - 1 - Das CobiT Referenzmodell für das Steuern von IT-Prozessen. - Das CobiT Referenzmodell für das Steuern von IT-Prozessen - Vortrag zum Thema - Das CobiT Referenzmodell für das Steuern von IT-Prozessen - auf der Veranstaltung: - Wertorientierte IT-Steuerung durch gelebte IT-Governance Vorbereitet für: IIR Deutschland GmbH Vorbereitet

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

BPM im Kontext von Unternehmensarchitekturen. Konstantin Gress

BPM im Kontext von Unternehmensarchitekturen. Konstantin Gress BPM im Kontext von Unternehmensarchitekturen Konstantin Gress Agenda 1 Worum geht s BPM, EA und SOA im Überblick 2 Link zwischen EA und BPM 3 Link zwischen SOA und BPM 4 Wie spielt das zusammen? 5 Q&A

Mehr

Your Landscape in Shape. Quo Vadis Business Architecture? - Ergebnisse eines Benchmarkings in 2014 - Fachkonferenz Facharchitektur in Versicherungen

Your Landscape in Shape. Quo Vadis Business Architecture? - Ergebnisse eines Benchmarkings in 2014 - Fachkonferenz Facharchitektur in Versicherungen Your Landscape in Shape Scape Enterprise Architecture Office and Consulting Dr. Daniel Simon Quo Vadis Business Architecture? - Ergebnisse eines Benchmarkings in 2014 - Fachkonferenz Facharchitektur in

Mehr

EAM: Enterprise Architecture Management. InnovationTrust Consulting GmbH

EAM: Enterprise Architecture Management. InnovationTrust Consulting GmbH EAM: Enterprise Architecture Management Vorgehensmodell InnovationTrust Consulting GmbH Inhalt 1. Ausgangssituation / Zielsetzung 2. Prozess und Modellierung (Szenarien) 3. Projektvorschlag / -vorgehen

Mehr

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/)

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Enterprise Continuum Wiederverwendung von Unternehmensarchitekturen Modul

Mehr

Agenda ITIL v3 Framework

Agenda ITIL v3 Framework Agenda ITIL v3 Framework Overview & Allgemeines ITIL Service Lifecycle Service Strategies Service Design Service Transition Service Operation Continual Service Improvement ITIL V3 Continual Service Improvement

Mehr

Strategie und Self Service BI im Unternehmen. Gegensätze miteinander kombinieren

Strategie und Self Service BI im Unternehmen. Gegensätze miteinander kombinieren Strategie und Self Service BI im Unternehmen Gegensätze miteinander kombinieren Claas Planitzer Düsseldorf Juni 2015 Agenda 5. Herausforderungen 1. Idealbild 2. Realität 3. Self Service 4. BI. Was ist

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

ckc Finance Club EAM Master Planning

ckc Finance Club EAM Master Planning ckc Finance Club EAM Master Planning 22. Februar 2007 Peter Barth-Nicolini, alfabet AG Agenda Vorstellung alfabet AG Herausforderung Business & IT Alignment Überblick: Strategische IT Planung mit planningit

Mehr

Alles richtig machen Prozessorientierung hilft Ziele zu erreichen und schafft Vertrauen

Alles richtig machen Prozessorientierung hilft Ziele zu erreichen und schafft Vertrauen Information zum Thema Prozess Der Erfolg eines Unternehmens die Durchsetzung seiner Produkte und Dienstleistungen auf dem Markt, effiziente interne Abläufe, eine gesunde wirtschaftliche Situation hängt

Mehr

SNB IT-Architekturprinzipien

SNB IT-Architekturprinzipien SNB IT-Architekturprinzipien EAM Community April 2015 D. Voser Aus dem Auftrag an die SNB IT-Architektur: «Sicherstellung der nachvollziehbaren, langfristigen Ausrichtung der IT-Unterstützung auf die Anforderungen

Mehr

IT-Governance. Standards und ihr optimaler Einsatz bei der. Implementierung von IT-Governance

IT-Governance. Standards und ihr optimaler Einsatz bei der. Implementierung von IT-Governance IT-Governance Standards und ihr optimaler Einsatz bei der Implementierung von IT-Governance Stand Mai 2009 Disclaimer Die Inhalte der folgenden Seiten wurden von Severn mit größter Sorgfalt angefertigt.

Mehr

Balanced Scorecard Strategien umsetzen. CP-BSC ist ein Modul der Corporate Planning Suite.

Balanced Scorecard Strategien umsetzen. CP-BSC ist ein Modul der Corporate Planning Suite. Balanced Scorecard Strategien umsetzen CP-BSC ist ein Modul der Corporate Planning Suite. UnternehMenSSteUerUng Mit ViSiOn UnD StrAtegie Strategien umsetzen. Jedes Unternehmen hat strategische Ziele und

Mehr

Vorwort zur zweiten Auflage...V. Vorwort zur ersten Auflage... VIII

Vorwort zur zweiten Auflage...V. Vorwort zur ersten Auflage... VIII Vorwort zur zweiten Auflage...V Vorwort zur ersten Auflage... VIII 1 Management Support Systeme und Business Intelligence Anwendungssysteme zur Unterstützung von Managementaufgaben...1 1.1 Computergestützte

Mehr

IT-Steuerung mit Kennzahlen

IT-Steuerung mit Kennzahlen Proseminar IT-Kennzahlen und Softwaremetriken Sommersemester 2010 IT-Steuerung mit Kennzahlen von Daniel Zollo am 07.06.2010 1 Gliederung 1. Definitionen und Relevanz des Themas 2. Inhalt 2.1. Objekte

Mehr

ERP / IT Strategieleitfaden Vorgehensmodell zur Entwicklung einer ERP / IT-Strategie

ERP / IT Strategieleitfaden Vorgehensmodell zur Entwicklung einer ERP / IT-Strategie ERP / IT Strategieleitfaden Vorgehensmodell zur Entwicklung einer ERP / IT-Strategie Johannes Schwab, MBA Warum strategische IT-Planung? - Zitat Das Internet ist die Technologie, die am nachhaltigsten

Mehr

Master-Thesis (m/w) für unseren Standort Stuttgart

Master-Thesis (m/w) für unseren Standort Stuttgart Master-Thesis (m/w) für unseren Standort Abschlussarbeit im Bereich Business Process Management (BPM) Effizienzsteigerung von Enterprise Architecture Management durch Einsatz von Kennzahlen Braincourt

Mehr

IT-Prüfung nach dem COBIT- Ansatz. Erfahrungen des oö. Landesrechnungshofes

IT-Prüfung nach dem COBIT- Ansatz. Erfahrungen des oö. Landesrechnungshofes IT-Prüfung nach dem COBIT- Ansatz Erfahrungen des oö. Landesrechnungshofes Oö. Landesrechnungshof Landesrechnungshof ist zuständig für die Prüfung von IT-Organisationen des Landes und von Beteiligungsunternehmen

Mehr

Systemen. Stand der Umsetzung von BSC-Systemen. 3/4 der Unternehmen setzen Balanced Scorecard als neues Instrument der Unternehmensführung ein.

Systemen. Stand der Umsetzung von BSC-Systemen. 3/4 der Unternehmen setzen Balanced Scorecard als neues Instrument der Unternehmensführung ein. Stand der Umsetzung von BSC-Systemen Systemen BSC eingeführt keine Überarbeitung 11% kein Interesse 26% BSC eingeführt Überarbeitung geplant 5% BSC geplant 58% n = 141 3/4 der Unternehmen setzen Balanced

Mehr

EAM einfach und effektiv

EAM einfach und effektiv 72 Foto: Frank van den Bergh/istock.com Enterprise Architecture (EAM) kann wesentlich zur Gestaltung und Umsetzung von Unternehmenszielen beitragen. Dies gelingt in der Praxis aber selten. Viele EAM-Initiativen

Mehr

Internationaler Controller Verein. Gründungssitzung der Projektgruppe Business Intelligence Stuttgart, 26.01.2006

Internationaler Controller Verein. Gründungssitzung der Projektgruppe Business Intelligence Stuttgart, 26.01.2006 Internationaler Controller Verein Gründungssitzung der Projektgruppe Business Intelligence Stuttgart, 26.01.2006 Agenda 10.00 Begrüßung 10.00 Rolle des Controllers im Umfeld Business Intelligence (A. Seufert)

Mehr

Ein Managementtool, welches durch Kombination der monetären und nicht monetären Faktoren hilft, die Strategie umzusetzen

Ein Managementtool, welches durch Kombination der monetären und nicht monetären Faktoren hilft, die Strategie umzusetzen Ein Managementtool, welches durch Kombination der monetären und nicht monetären Faktoren hilft, die Strategie umzusetzen Die Idee Vorgehensweise & Implementierung Ziele definieren Ursache Wirkungskette

Mehr

ITIL & TOGAF die Doppelspitze für IT Governance

ITIL & TOGAF die Doppelspitze für IT Governance 1 ITIL Day 2014 ITIL & TOGAF die Doppelspitze für IT Governance Referenten: Arif Chughtai, Matthias Gessenay 2 Referenten Arif Chughtai mail@arifchughtai.org www.arifchughtai.org Matthias Gessenay matthias.gessenay@corporatesoftware.ch

Mehr

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

Mehr

SAP BW + Microsoft Excel Viel genutzt, oft unterschätzt

SAP BW + Microsoft Excel Viel genutzt, oft unterschätzt Corporate Performance Management SAP BW + Microsoft Excel Viel genutzt, oft unterschätzt Martin Krejci, Manager CPM Matthias Schmidt, BI Consultant Kristian Rümmelin, Senior BI Consultant Braincourt GmbH

Mehr

2. Umfrage zum Stand von Green IT im deutschsprachigen Raum 2010

2. Umfrage zum Stand von Green IT im deutschsprachigen Raum 2010 2. Umfrage zum Stand von Green IT im deutschsprachigen Raum 2010 Prof. Dr. Andreas Gadatsch Andreas.Gadatsch@Hochschule-.de www.wis.fh-brs.de/gadatsch in: Schriftenreihe des Fachbereiches Wirtschaftswissenschaft

Mehr

Inge Hanschke. Enterprise Architecture Management - einfach und effektiv. Ein praktischer Leitfaden für die Einführung von EAM ISBN: 978-3-446-42694-8

Inge Hanschke. Enterprise Architecture Management - einfach und effektiv. Ein praktischer Leitfaden für die Einführung von EAM ISBN: 978-3-446-42694-8 Inge Hanschke Enterprise Architecture Management - einfach und effektiv Ein praktischer Leitfaden für die Einführung von EAM ISBN: 978-3-446-42694-8 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42694-8

Mehr

Planung, Ziele, Kennzahlenmanagement

Planung, Ziele, Kennzahlenmanagement DGQ-Regionet Nordwest 13.11.2008 Planung, Ziele, Kennzahlenmanagement Guido Kuper Qualitätsmanagement Wilhelm Karmann GmbH 1 Wozu benötigt man Kennzahlen? Zur Beruhigung Zur Orientierung Zur Analyse der

Mehr

Inhaltsverzeichnis. 1 Einleitung 1. 2 Einführung und Grundlagen 7

Inhaltsverzeichnis. 1 Einleitung 1. 2 Einführung und Grundlagen 7 xv 1 Einleitung 1 2 Einführung und Grundlagen 7 2.1 Die neue Rolle der IT...................................... 7 2.2 Trends und Treiber........................................ 8 2.2.1 Wertbeitrag von

Mehr

GRC Governance Risk & Compliance

GRC Governance Risk & Compliance GRC Governance Risk & Compliance Ansätze zur Unternehmenssteuerung aus Sicht der Wirtschaftsprüfung 27. März 2012 WP StB Heinz-Georg Kämpchen RWGV GRC 27. März 2012 WP StB Heinz-Georg Kämpchen Inhalt.

Mehr

Raber+Märcker Business Intelligence Lösungen und Leistungen

Raber+Märcker Business Intelligence Lösungen und Leistungen Business Intelligence Raber+Märcker Business Intelligence Lösungen und Leistungen www.raber-maercker.de 2 LEISTUNGEN Business Intelligence Beratungsleistung Die Raber+Märcker Business Intelligence Beratungsleistung

Mehr

Swiss Marketing Leadership Studie 2015. Man agement Summary

Swiss Marketing Leadership Studie 2015. Man agement Summary 3 Man agement Summary Marketing ändert sich fundamental und sollte in modernen Unternehmen eine steuernde Funktion in Richtung Kunden- und Marktorientierung einnehmen. Vor diesem Hintergrund entschied

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

A) Initialisierungsphase

A) Initialisierungsphase Einleitung Die folgenden Seiten beschreiben in Kurzform die mit jedem Schritt verbundenen Aufgaben, die beim ersten Durchlauf zu bearbeiten sind. Zu Beginn eines ISIS12-Projekts legen das Unternehmen und

Mehr

Bachelor/Master-Thesis (für den Standort Stuttgart) Treiberbasierte Planung

Bachelor/Master-Thesis (für den Standort Stuttgart) Treiberbasierte Planung Bachelor/Master-Thesis (für den Standort Stuttgart) Treiberbasierte Planung Hochschulstudium (Wirtschaftsinformatik oder ein vergleichbarer Studiengang) Fachliche und technische Kenntnisse im Bereich Business

Mehr

IT-Strategie der zentralen Leistungserbringer der UZH 2014-2016

IT-Strategie der zentralen Leistungserbringer der UZH 2014-2016 Universität Zürich Prorektorat Rechts- und Künstlergasse 15 CH-8001 Zürich Telefon +41 44 634 57 44 www.rww.uzh.ch IT-Strategie der zentralen Leistungserbringer der UZH 2014-2016 Version vom 6. Juni 2014

Mehr

Erfolgreiche Unternehmensführung durch den Einsatz von Corporate Performance Management

Erfolgreiche Unternehmensführung durch den Einsatz von Corporate Performance Management Andrei Buhrymenka Erfolgreiche Unternehmensführung durch den Einsatz von Corporate Performance Management Für Unternehmen mit Business Intelligence Diplomica Verlag Andrei Buhrymenka Erfolgreiche Unternehmensführung

Mehr

Governance, Risk & Compliance für den Mittelstand

Governance, Risk & Compliance für den Mittelstand Governance, Risk & Compliance für den Mittelstand Die Bedeutung von Steuerungs- und Kontrollsystemen nimmt auch für Unternehmen aus dem Mittelstand ständig zu. Der Aufwand für eine effiziente und effektive

Mehr

E-Interview mit Frau Hanschke

E-Interview mit Frau Hanschke E-Interview mit Frau Hanschke Titel des E-Interviews: Name: Funktion/Bereich: Organisation: iteraplan das Open-Source- Werkzeug für Enterprise Architecture Management Inge Hanschke Geschäftsführerin iteratec

Mehr

IT-Controlling in der Sparkasse Hildesheim

IT-Controlling in der Sparkasse Hildesheim 1 IT-Controlling in der der Steuerungsregelkreislauf für IT-Entwicklung und -Betrieb Auf Basis der IT-Strategie mit den dort definierten Zielen wurde das IT-Controlling eingeführt und ist verbindliche

Mehr

Enterprise Architecture Management. Stephan Schneider

Enterprise Architecture Management. Stephan Schneider Enterprise Architecture Management in der Praxis Stephan Schneider Enterprise Architecture Management in der Praxis Stephan Schneider 1 Agenda 1. Einführung & Grundlagen 2. EAM Tools 3. Fallstudie SEB

Mehr

SOA Governance Konzepte und Best Practices

SOA Governance Konzepte und Best Practices SOA Governance Konzepte und Best Practices Gerd Schneider Senior Director SOA Marketing Software AG 2/27/2007 Agenda Überblick SOA Governance Warum SOA Governance? Kundenbeispiel SAS Airlines Technische

Mehr

Führungsinformationen in Echtzeit: Erfolgsfaktoren bei der Einführung einer Balanced Scorecard (BSC)

Führungsinformationen in Echtzeit: Erfolgsfaktoren bei der Einführung einer Balanced Scorecard (BSC) Führungsinformationen in Echtzeit: Erfolgsfaktoren bei der Einführung einer Balanced Scorecard (BSC) M. Kalinowski Michael.Kalinowski@ebcot.de www.ebcot.de Hannover, 15. März 2005 1 Die Strategieumsetzung

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

Mehr

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor auf Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP. Ralf Ackermann Daimler AG, ITM MBC Powertrain

Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP. Ralf Ackermann Daimler AG, ITM MBC Powertrain Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP Ralf Ackermann Daimler AG, ITM MBC Powertrain Agenda Ausgangslage EAM Tool-Landschaft bei Daimler planningit

Mehr

Was NetWeaver wirklich bietet

Was NetWeaver wirklich bietet Was NetWeaver wirklich bietet Erschienen in der Computerwoche 03/2007 Von Dr. Carl Winter, REALTECH AG Welche SAP Produkt-Versionen und SAP Releases gehören und passen zusammen. Welche sind die aktuellen

Mehr

Progress of Enterprise Architecture Management 2008. Eine Studie über den Fortschritt im integrierten Management von Geschäfts- und IT-Architektur

Progress of Enterprise Architecture Management 2008. Eine Studie über den Fortschritt im integrierten Management von Geschäfts- und IT-Architektur Progress of Enterprise Architecture Management 2008 Eine Studie über den Fortschritt im integrierten Management von Geschäfts- und IT-Architektur Der EAM Think Tank ist eine gemeinsame Initiative der Ardour

Mehr

Optimales Outsourcing als strategische Aufgabe

Optimales Outsourcing als strategische Aufgabe IT-Beratung für Logistik und Optimales Outsourcing als strategische Aufgabe Agenda IT Sourcing: Anspruch und Wirklichkeit Ausgangslage und Zielsetzung b Logo Sourcing Scope-Workshop Das Logo Broker-Modell:

Mehr

IT-Projektportfoliomanagement im Spannungsfeld zwischen Geschäftsbedürfnis und Architekturplanung

IT-Projektportfoliomanagement im Spannungsfeld zwischen Geschäftsbedürfnis und Architekturplanung IT-Projektportfoliomanagement im Spannungsfeld zwischen Geschäftsbedürfnis und Architekturplanung Stephan Hofstetter, Hans-Jakob Gfeller, BAT 02.11.2012 Agenda 1 Die Informatik der SBB 2 Zielsetzung und

Mehr

Operative Exzellenz in der Konsumgüterindustrie Ganzheitliche und GuV wirksame Optimierung der Unternehmensprozesse

Operative Exzellenz in der Konsumgüterindustrie Ganzheitliche und GuV wirksame Optimierung der Unternehmensprozesse Operative Exzellenz in der Konsumgüterindustrie Ganzheitliche und GuV wirksame Optimierung der Unternehmensprozesse Jochen Jahraus, Partner KPS Consulting Competence Center Konsumgüter Seite Operative

Mehr

Kennzahlen zur Unterstützung strategischer Entwicklungsprozesse am Beispiel der Lenne-Werkstatt

Kennzahlen zur Unterstützung strategischer Entwicklungsprozesse am Beispiel der Lenne-Werkstatt Kennzahlen zur Unterstützung strategischer Entwicklungsprozesse am Beispiel der Lenne-Werkstatt Netzwerktagung für Controllerinnen und Controller sowie Führungskräfte aus den Bereichen SGB VIII und XII

Mehr

ITPS ITpreneurship Synergien im IT-Management unter wirtschaftlichen Aspekten

ITPS ITpreneurship Synergien im IT-Management unter wirtschaftlichen Aspekten ITPS ITpreneurship Synergien im IT-Management unter wirtschaftlichen Aspekten 1 ITpreneurship Beratungsangebot für eine unternehmerisch-wirtschaftliche IT-Optimierung In fast allen Unternehmen hat die

Mehr

Grundlagen der Projektarbeit

Grundlagen der Projektarbeit Lerninhalte ❶ ❷ ❸ ❹ ❺ ❻ Ziele und Aufgaben des s Beteiligte des s Aufstellung der IS-Architektur (Überblick) Projektplanung Projektentwicklung Projektorganisation Lerninhalte L1 i Ziele und Aufgaben des

Mehr

Design for Six Sigma umsetzen POCKET POWER

Design for Six Sigma umsetzen POCKET POWER Design for Six Sigma umsetzen POCKET POWER 3 Inhalt 1 Einleitung 5 2 Methoden und Werkzeuge 9 2.1 Define 9 2.2 Measure 16 2.3 Analyze 24 2.4 Design 34 2.5 Verify 47 3 Der Einsatz in Systemprojekten 52

Mehr

MASTERTHESIS ABSCHLUSSVORTRAG. Kristina Hamann

MASTERTHESIS ABSCHLUSSVORTRAG. Kristina Hamann MASTERTHESIS ABSCHLUSSVORTRAG Kristina Hamann Eckdaten Thema Bearbeiter Betreuer Kooperationspartner Beginn Abgabe Ein Vorgehensmodell zur kooperativen Analyse einer Unternehmensarchitektur im Kontext

Mehr

Business Intelligence was macht Unternehmen intelligent? White Paper

Business Intelligence was macht Unternehmen intelligent? White Paper Business Intelligence was macht Unternehmen intelligent? White Paper Autor: Jens Blank Juli 2012 Wassermann AG Westendstraße 195 80686 München www.wassermann.de Zusammenfassung Über traditionelle Ansätze

Mehr

Wir bringen Transparenz in das DRG-System. Kennzahlen-Reporting und Planung mit SAP BW für Krankenhäuser

Wir bringen Transparenz in das DRG-System. Kennzahlen-Reporting und Planung mit SAP BW für Krankenhäuser Wir bringen Transparenz in das DRG-System Ist Ihr BW-System bereit für die Analyse diagnosebezogener Fallgruppen? Die Lösung Kennzahlen-Reporting und Planung mit SAP BW für Krankenhäuser Was verbirgt sich

Mehr

Strategische Unternehmenssteuerung immer in Richtung Erfolg

Strategische Unternehmenssteuerung immer in Richtung Erfolg Strategische Unternehmenssteuerung immer in Richtung Erfolg CP-Strategy ist ein Modul der Corporate Planning Suite. STRATEGISCHE UNTERNEHMENSSTEUERUNG Immer in Richtung Erfolg. Erfolgreiche Unternehmen

Mehr

Controlling von Direktbanken

Controlling von Direktbanken Controlling von Direktbanken mit der Balanced Scorecard Dissertation zur Erlangung des wirtschaftswissenschaftlichen Doktorgrades des Fachbereichs Wirtschaftswissenschaften der Universität Göttingen vorgelegt

Mehr

Optimieren von Requirements Management & Engineering

Optimieren von Requirements Management & Engineering Xpert.press Optimieren von Requirements Management & Engineering Mit dem HOOD Capability Model Bearbeitet von Colin Hood, Rupert Wiebel 1. Auflage 2005. Buch. xii, 245 S. Hardcover ISBN 978 3 540 21178

Mehr

Geschäftsprozessmanagement. Prof. Dr. Knut Hinkelmann

Geschäftsprozessmanagement. Prof. Dr. Knut Hinkelmann Geschäftsprozessmanagement Geschäftsprozesse im Kontext Alter, Steven: Information Systems The Foundation of E-Business, 4. Auflage, Prentice Hall, New Jersey, 2002 2 Drei Gesichtspunkte auf das Unternehmen

Mehr

Mit strategischem Marketing profitabel wachsen und die Wettbewerbsfähigkeit sichern

Mit strategischem Marketing profitabel wachsen und die Wettbewerbsfähigkeit sichern Mit strategischem Marketing profitabel wachsen und die Wettbewerbsfähigkeit sichern Strategisches Marketing? Nein danke das brauchen wir nicht! Wir arbeiten schon mit guten Werbeagenturen zusammen! So,

Mehr

Anwenderforum E-Government QuickCheck:ITIL 18.02.2010/Berlin

Anwenderforum E-Government QuickCheck:ITIL 18.02.2010/Berlin Anwenderforum E-Government QuickCheck:ITIL 18.02.2010/Berlin INFORA GmbH Martin Krause Cicerostraße 21 10709 Berlin Tel.: 030 893658-0 Fax: 030 89093326 Mail: info@infora.de www.infora.de Agenda Die Ausgangssituation

Mehr

The Need for Speed. CeBIT 2011. Dr. Wolfgang Martin Analyst, ibond Partner und Ventana Research Advisor

The Need for Speed. CeBIT 2011. Dr. Wolfgang Martin Analyst, ibond Partner und Ventana Research Advisor The Need for Speed CeBIT 2011 Dr. Wolfgang Martin Analyst, ibond Partner und Ventana Research Advisor The Need for Speed Industrialisierung, Agilität und Compliance die Rolle von Performance Management

Mehr

Controlling im Mittelstand

Controlling im Mittelstand Controlling im Mittelstand Mag. Johann Madreiter nachhaltigmehrwert e.u. Unternehmensberatung und Training 2 Controlling im Mittelstand Controlling im Mittelstand und Kleinunternehmen? Ein auf die Unternehmensgröße

Mehr

Agile BI mit Agile BI Modeler & Agile Scorecard

Agile BI mit Agile BI Modeler & Agile Scorecard Agile BI mit Agile BI Modeler & Agile Scorecard Business Intelligence - so einfach wie möglich - so komplex wie nö7g Jon Nedelmann Darmstadt, 26.10.2012 Agile BI Tools Agile BI Modeler Ist eine Web- Anwendung

Mehr

IKS KURZ-CHECK. Die KARER CONSULTING Analyse für Ihr Internes Kontrollsystem

IKS KURZ-CHECK. Die KARER CONSULTING Analyse für Ihr Internes Kontrollsystem IKS KURZ-CHECK Die KARER CONSULTING Analyse für Ihr Internes Kontrollsystem Ausgangssituation Mit der am 1. Januar 2008 in Kraft getretenen Revision des Schweizer Obligationsrechtes (insb. Art. 728a, 728b,

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 378 Umsetzung ausgewählter Supply-Chain-Operations-Reference-Metriken durch das

Mehr

Dr.Siegmund Priglinger. 23.03.2007 spriglinger@informatica.com

Dr.Siegmund Priglinger. 23.03.2007 spriglinger@informatica.com Vernetzung geschäftsrelevanter Informationen Dr.Siegmund Priglinger 23.03.2007 spriglinger@informatica.com 1 Agenda 2 Die Herausforderung Der Markt verbindet diese fragmenierten Daten Geschäftssicht M&A

Mehr

ENTERPRISE PERFORMANCE MANAGEMENT FÜR EPM. Sie.

ENTERPRISE PERFORMANCE MANAGEMENT FÜR EPM. Sie. ENTERPRISE PERFORMANCE MANAGEMENT FÜR EPM Sie. WIE SIEHT DIE PERFORMANCE IHRES UNTERNEHMENS AUS? ZIELE MUSS MAN MESSEN KÖNNEN Ihre Mitarbeitenden bilden nicht nur einen grossen Kostenblock in Ihrer Aufwandsrechnung,

Mehr

Ergebnisorientiertes Informationsmanagement als Basis für eine effektive Unternehmenssteuerung

Ergebnisorientiertes Informationsmanagement als Basis für eine effektive Unternehmenssteuerung Ergebnisorientiertes Informationsmanagement als Basis für eine effektive Unternehmenssteuerung Matthias Fellersmann / Geschäftsführer Mail: fellersmann@pst.de PST Software & Consulting GmbH Seit 1980 auf

Mehr

Analytics, Big Data, Multi-Touch Attribution und Content Marketing E-Business 2014

Analytics, Big Data, Multi-Touch Attribution und Content Marketing E-Business 2014 Analytics, Big Data, Multi-Touch Attribution und Content Marketing E-Business 2014 Andreas Berth, CEO B2 Performance Group Inhalt B2 Performance das Unternehmen Ausgangslage Problem Lösung Umsetzung Key

Mehr

Mit Business Analytics zur ergebnis- und wirkungsorientierten. Copyright 2010, SAS Institute Inc. All rights reserved.

Mit Business Analytics zur ergebnis- und wirkungsorientierten. Copyright 2010, SAS Institute Inc. All rights reserved. Mit Business Analytics zur ergebnis- und wirkungsorientierten Steuerung Herausforderungen 1. Finanzkrise 2. Demografischer Wandel 3. Innovationsfähigkeit der öffentlichen Verwaltung 4. Leistungsorientierung

Mehr

SOA Starter Kit Einführungsstrategien und Einstiegspunkte

SOA Starter Kit Einführungsstrategien und Einstiegspunkte SOA Starter Kit Einführungsstrategien und Einstiegspunkte Benjamin Brunner Berater OPITZ CONSULTING Bad Homburg GmbH SOA Starter Kit Seite 1 Agenda Wer sollte eine SOA nutzen? Welche Ziele kann eine SOA

Mehr

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

Mehr

Bringen Sie Ihr Unternehmen innovativ voran. Mit klaren Lösungen und integrierter Unternehmenssteuerung.

Bringen Sie Ihr Unternehmen innovativ voran. Mit klaren Lösungen und integrierter Unternehmenssteuerung. Bringen Sie Ihr Unternehmen innovativ voran. Mit klaren Lösungen und integrierter Unternehmenssteuerung. Kennen Sie die wahren Werte Ihres Unternehmens? Im Finanzwesen und dem Controlling Ihres Unternehmens

Mehr

Führung und. Personalmanagement

Führung und. Personalmanagement Führung und Controlling Handelsfachwirt/in IHK Dozent: Klaus Imhof Dozent: Klaus Imhof Folie 1 Gliederung 1. Führungsgrundsätze und Führungsmethoden, 2. Personalpolitik, 3. Psychologische Grundlagen zur

Mehr

Intelligente Unternehmens- und Prozesssteuerung durch CPM

Intelligente Unternehmens- und Prozesssteuerung durch CPM Intelligente Unternehmens- und Prozesssteuerung durch CPM 5. IIR Forum BI, Mainz, Sept. 2006 Dr. Wolfgang Martin Analyst, ibond Partner, Ventana Research Advisor und Research Advisor am Institut für Business

Mehr

PQM- Prozessorientiertes Qualitätsmanagement

PQM- Prozessorientiertes Qualitätsmanagement Karl Werner Wagner (Hrsg.) PQM- Prozessorientiertes Qualitätsmanagement Leitfaden zur Umsetzung der ISO 9001:2000 Neu: Prozesse steuern mit der Balanced Scorecard 2., vollständig überarbeitete und erweiterte

Mehr

FHH meets economy. Tobias Klug Dipl.-Wirt.-Inf. (FH), Alumnus FH Hannover. Hannover, 21. Januar 2010. 21. Januar 2010 bit GmbH

FHH meets economy. Tobias Klug Dipl.-Wirt.-Inf. (FH), Alumnus FH Hannover. Hannover, 21. Januar 2010. 21. Januar 2010 bit GmbH FHH meets economy BI Projektmanagement bei QlikView Projekten Tobias Klug Dipl.-Wirt.-Inf. (FH), Alumnus FH Hannover Hannover, 21. Januar 2010 21. Januar 2010 Agenda Über die bit GmbH Über QlikTech und

Mehr