Unified Project View - Konzept eines Dashboards mit einer konsistenten Gesamtsicht auf den Projektstatus für Offshore IT Projekte

Inhaltsverzeichnis

II. Abbildungsverzeichnisv

III. Tabellenverzeichnis

IV. Abkürzungsverzeichnis

V. Abstractix

1. Einführung
1.1 Motivation und Problemdarstellung
1.2 Ausgangspunkt - Capgemini, Projekt start
1.3 Aufbau und Inhalt der Bachelorthesis

2. Theoretische Grundlagen des Vorgehensmodells der Unified Project View (UPV)
2.1 Definition der UPV
2.2 Wissenschaftlicher Forschungsstand
2.2.1 Forschungsstand zur Problemstellung der Bachelorthesis
2.2.2 Forschungsstand zu PM-Methoden für Offshore IT-Projekte
2.2.3 Forschungsstand zu Dashboards für Offshore IT-Projekte
2.3 Theoretische Grundlagen der UPV
2.3.1 Theoretischer Aufbau von Dashboards
2.3.2 Benutzeroberfläche von Dashboards
2.3.3 Erfolgssymptome von Dashboards
2.3.4 Organisatorische Voraussetzungen zur Einführung von Dashboards
2.3.5 Eight-Step Change Management Modell nach Kotter

3. Empirische Untersuchungen zur UPV
3.1 Einführung in die empirische Sozialforschung
3.2 Darstellung der Fragebogenstudie
3.2.1 Methodik von Online-Befragungen
3.2.2 Begründung für die Wahl der Erhebungsmethode
3.2.3 Aufbau des Fragebogens
3.2.4 Forschungsfragen und Hypothesen
3.2.5 Ergebnisse der Forschungsfragen und Hypothesen
3.2.6 Ergebnisse der Fragebogenstudie
3.3 Darstellung der Experteninterviews
3.3.1 Methodik von leitfadengestützten Experteninterviews
3.3.2 Begründung für die Wahl der Erhebungsmethode
3.3.3 Aufbau des Interviewleitfadens
3.3.4 Ergebnisse der Forschungsfragen
3.3.5 Ergebnisse der Experteninterviews
3.4 Ergebnisvergleich der empirischen Untersuchungen

4. Konzeption des Vorgehensmodells der UPV
4.1 Anforderungen eines UPV Dashboards
4.1.1 Organisatorische Voraussetzungen eines UPV Dashboards
4.1.2 Qualitätsanforderungen eines UPV Dashboards
4.2 Aufbau eines UPV Dashboards
4.2.1 Benutzer und Aufgaben eines UPV Dashboards
4.2.2 Identifikation der Datenquellen
4.2.3 Identifikation von Kennzahlen
4.2.4 Allgemeines zum Aufbau eines UPV Dashboards
4.2.5 Aufbau eines UPV Dashboards
4.2.6 Aufbau eines Team Dashboards
4.2.7 UPV/Team Dashboard in der Test- und Betriebsphase
4.3 Einführung eines UPV Dashboards
4.3.1 Bewusstsein für die Dringlichkeit schaffen
4.3.2 Eine Führungskoalition aufbauen
4.3.3 Vision und Strategien entwickeln
4.3.4 Die Vision des Wandels kommunizieren
4.3.5 Empowerment (Befähigung) auf breiter Basis
4.3.6 Kurzfristige Ziele ins Auge fassen
4.3.7 Erfolge konsolidieren und weitere Veränderungen ableiten
4.3.8 Neue Ansätze in der Kultur verankern
4.4 Vorstellung des Vorgehensmodells der UPV

5. Fazit und Ausblick

VI. Begriffsdefinitionenxi

VII. Anhang
VII.1 Fragebogenstudie
VII.1.1 Ablauf der Fragebogenstudie
VII.1.2 Deskriptive Darstellung der Fragebogenstudie
VII.1.3 Auswertung der Fragebogenstudie
VII.1.4 Kritischer Rückblick auf den Verlauf der Fragebogenstudie
VII.2 Experteninterviews
VII.2.1 Darstellung der inhaltlichen Strukturierungl
VII.2.2 Anwendung der inhaltlichen Strukturierungl
VII.3 Notwendige Kontrollelemente je Projektstatusbereichl
VII.4 Anforderungskriterien eines UPV Dashboards
VII.5 UPV Dashboard
VII.6 Team Dashboard
VII.7 Schritte zur Einführung eines UPV Dashboards
VII.8 Vorgehensmodell der UPV

VIII. Literaturverzeichnis

II. Abbildungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

III. Tabellenverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

IV. Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

V. Abstract

„Zu Beginn eines Offshore-Projekts geht die Produktivität erst einmal um 20 Prozent zurück” (vgl. Computerwoche.de, 2003), sagt Wolfgang Franklin, Vorstandsvorsitzender des Chief Information Officer (CIO) Forum Deutschland, Österreich, Schweiz. Vor diesem Hintergrund ist das Offshoring unternehmensinterner IT Services auch gleichzeitig als eine Herausforderung für das Projektteam anzusehen. Der weitere Overhead entsteht dabei durch die geografische Distanz, die Sprache und die Arbeitsweise der Offshore Partner. Dies kann dazu führen, dass das Projektteam den Blick für das Wesentliche verliert. Den Überblick über alle wichtigen Bereiche des Projekts zu behalten, ist damit ein zentrales Ziel für den Erfolg des Projekts. Wenn z.B. der Projektstatus nicht ausreichend im Projektteam kommuniziert wird, kann dies zu Reibungsverlusten führen. Unterstützung soll das konzeptionelle Vorgehensmodell der „Unified Project View“ (UPV) bringen.

Ziel der Bachelorthesis ist es, anhand des Individualsoftware Projekts start, ein Vorgehensmodell zur Umsetzung einer „Unified Project View“ zu entwickeln. Die Unified Project View soll eine für alle Projektbeteiligte konsistente Gesamtsicht auf den Projektstatus darstellen - das „Unified Project View Dashboard“. Hierdurch wird zum einen sichergestellt, dass das Projektteam sich über den aktuellen Informationsstand informieren kann. Zum anderen können hierdurch vorgegebenen Zielvorstellungen verfolgt und Probleme im Projekt rechtzeitig erkannt werden.

Auf der Grundlage von empirischen Untersuchungen werden die relevanten Projektstatusbereiche identifiziert. Die Ergebnisse werden daraufhin durch Experteninterviews verifiziert, um anschließend einen möglichst umfassenden Überblick, über die notwendigen Projektstatusbereiche geben zu können. Weitere Grundlagen bilden die Projektmanagement Theorien „Project Management Book of Knowledge“ (PMBoK), „effizientes Projektmanagement“ (ePM) sowie Methoden zur Projektfortschrittsanalyse. Die praktischen Erfahrungen des deutschen und indischen Projektteams werden ebenfalls genutzt, um potenzielle

Probleme bei der Umsetzung der Unified Project View aufzuzeigen. Aus den festgestellten Problemen werden anschließend mögliche Lösungsansätze definiert. Das Ergebnis der Ausarbeitung beschreibt ein Konzept für ein Vorgehensmodell der Unified Project View. Das Konzept enthält Handlungsempfehlungen für die Entwicklung eines Unified Project View Dashboards und erläutert dessen Einführung in Offshore IT-Projekten. Aufgrund des beschränkten Zeitrahmens der Bachelorthesis wird von einer praktischen Umsetzung eines Unified Project View Dashboards abgesehen. Stattdessen wird eine beispielhafte Implementierung erläutert.

1. Einführung

1.1 Motivation und Problemdarstellung

In den letzten Jahren hat die Offshore (vgl. VI.8) Softwareentwicklung immer mehr an Bedeutung gewonnen und wird vor allem aus Gründen reduzierter Kosten durchgeführt. (vgl. Allweyer, T. et al. 2004, S. 8) Laut Farrell haben 40% der 500 größten Unternehmen in Westeuropa schon ihre IT ins Ausland verlagert. (vgl. Farrell, D., 2011, S. 5) Weitere Gründe für eine Verlagerung der IT sind die flexible Personalplanung, die hohe Qualität der Software und die Verringerung der Zeit bis zur Marktreife von Software. (vgl. Mozcadlo, R., 2011, S. 4)

Gemäß einer Umfragestudie von Moczadlo wird das Scheitern von IT Offshore Projekten auf ein ineffizientes Projektmanagement (PM) (vgl. VI.12) zurückgeführt. (vgl. Moczadlo, R., 2011, S. 14) PM kann daher als relevanter Faktor für den Erfolg eines Projekts bezeichnet werden. (vgl. Aichele, C., 2006, S. 285) Ein Projekt wird grundsätzlich als erfolgreich gewertet, wenn mindestens das Ergebnis, die Termin- und die Budgettreue erreicht werden. (vgl. VI. 11) Somit hängt der Erfolg nicht nur von der Arbeit des Projektteams ab, sondern auch von der kompetenten Kontrolle und Steuerung der PMs.

Gerade bei Offshore Projekten stellt die Projektkontrolle eine besondere Herausforderung dar. (vgl. Jenny, B., 2009, S. 272) Die Kontrolle muss u.a. über den Zeitplan, über das Budget und über das Produkt behalten werden. (vgl. VI.12) Dies sind nur ein paar Beispiele für Bereiche, die kontrolliert werden müssen, um Entscheidungen im Projekt treffen zu können. Die Qualität der Entscheidung hängt aber von den Informationen ab, die das Projektteam erhält. Der Informationsbestand ist jedoch meist größer, als es die Zeit zulässt diese zu verarbeiten und zu analysieren. (vgl. Grasl, O. et al. 2004, S. 74) Die besondere Aufgabe besteht also darin, alle relevanten Informationen zu vereinen, um den Zustand des Projektes kenntlich zu machen. Mit diesen Erkenntnissen können dann anschließend Entscheidungen getroffen werden. Eine Gesamtsicht auf den Projektstatus (vgl. VI. 13) ist demzufolge ein geeignetes Hilfsmittel, um das

Problem der hohen Informationsmenge zu lösen. Hierbei stellt sich jedoch die Frage, wie der Aufbau dieser Gesamtsicht aussieht und welche Bestandteile sie enthält. Diese Frage soll durch das Vorgehensmodell der „Unified Project View“ (UPV) beantwortet werden.

1.2 Ausgangspunkt - Capgemini, Projekt start

Capgemini ist das französische Management und IT-Beratungsunternehmen, das seinen Hauptsitz in Paris hat und in 40 Ländern operiert. Gegründet wurde das Unternehmen 1967 von Serge Kampf. Für Capgemini arbeiten ca. 112.000 Mitarbeiter, davon 7.982 in Zentraleuropa. Im Geschäftsjahr 2010 betrug der weltweite Umsatz des Unternehmens 8,7 Mrd. Euro. (vgl. Capgemini, 2011a) Das Projekt „Automotive Supply“ wurde von Daimler Chrysler am 01.01.2002 aufgesetzt und verfolgt das Ziel, die IT-Landschaft für die Beschaffungslogistik der deutschen Mercedes PKW-Werke neu zu gestalten. 2005 wurde das Projekt start begonnen, um das Anlauf- und Änderungsmanagement mit Individualsoftware (vgl. VI.6) umzusetzen. Das Projekt start wird nach dem Rightshore (vgl. VI.15) Modell entwickelt. Hierbei verteilt sich das Projektteam auf die Unternehmensstandorte in Deutschland (Stuttgart, München) und Indien (Mumbai). (vgl. Capgemini, 2011g)

1.3 Aufbau und Inhalt der Bachelorthesis

Kapitel 2

Dieses Kapitel setzt sich zunächst mit dem wissenschaftlichen Forschungsstand des Bachelorthesis Themas auseinander. Im Anschluss daran wurden mittels Literaturrecherche, die theoretischen Grundlagen für die UPV gelegt. Sie dienen im weiteren Verlauf der Arbeit, um das Vorgehensmodell der UPV zu entwickeln.

Kapitel 3

Zur Untersuchung der notwendigen Bestandteile, die eine Gesamtsicht auf den Projektstatus geben, werden in diesem Kapitel die empirischen Studien vorgestellt. Dabei wird zuerst auf das Forschungsdesign der Studien (Fragebogen, leitfadengestütztes Experteninterview) eingegangen. Anschließend werden die Ergebnisse dargestellt, analysiert und in Bezug auf die Problemstellung der Bachelorthesis interpretiert. Im letzten Teil erfolgt eine Gegenüberstellung der Ergebnisse beider Untersuchungen.

Kapitel 4

Aus den Ergebnissen der empirischen Untersuchungen und den theoretischen Grundlagen wird in diesem Kapitel das Vorgehensmodell der UPV entwickelt. Hierbei wird insbesondere auf die Anforderungen der Gesamtsicht (UPV Dashboard) sowie dessen Aufbau eingegangen. Die Gesamtsicht wird beispielhaft dargestellt und mit Grafiken konkretisiert. Im Anschluss wird die Einführung eines UPV Dashboards vom Change Management (Veränderungsmanagement) Modells von Kotter abgeleitet. Der letzte Teil dieses Kapitels stellt, auf der Grundlage der vorherigen Abschnitte, das Vorgehensmodell der UPV vor.

Kapitel 5

Das fünfte Kapitel fasst die wichtigen Erkenntnisse der Bachelorthesis in Bezug auf die Problemstellung zusammen und gibt einen Ausblick auf zukünftige Forschungen.

2. Theoretische Grundlagen des Vorgehensmodells der Unified Project View (UPV)

Dieses Kapitel behandelt die theoretischen Grundlagen, die im weiteren Verlauf der Arbeit auf das Vorgehensmodell der UPV angewendet werden. Zunächst wird die UPV definiert und dessen Bedeutung abgegrenzt. Anschließend wird der wissenschaftliche Forschungsstand zum Thema und zur Problemstellung der Bachelorthesis ermittelt. Der letzte Abschnitt dieses Kapitels betrachtet in Bezug auf die UPV die Themenkomplexe „Dashboard“ (vgl. VI.3) und „Change Management“ (vgl. VI.2).

2.1 Definition der UPV

Die Grundidee der „UPV“ ist, eine für alle Projektbeteiligten konsistente Gesamtsicht auf den Projektstatus zu ermöglichen. Der Begriff „UPV“ wird in dieser Arbeit auch synonym für das UPV Vorgehensmodell benutzt. Das Vorgehensmodell beschreibt, wie die Gesamtsicht entwickelt und anschließend in einem Projekt eingeführt wird. Die UPV enthält in diesem Zusammenhang auch das UPV Dashboard. Es stellt das Konzept der Gesamtsicht auf den Projektstatus dar. Im Folgenden werden das „UPV Vorgehensmodell“ und das „UPV Dashboard“ genauer definiert.

UPV Vorgehensmodell

Die „UPV“ als Vorgehensmodell erläutert die Anforderungen, um ein UPV Dashboard in ein Projekt einzusetzen. Das Vorgehensmodell beschreibt zudem, wie ein UPV Dashboard entwickelt wird. Mit Hilfe des Change Management Modells von Kotter werden die Einführungsschritte eines UPV Dashboards definiert.

UPV Dashboard

Das „UPV Dashboard“ stellt die Umsetzung des Vorgehensmodells der UPV dar. Es ist als PM-Werkzeug zu verstehen, in dem die notwendigen Bereiche eines Projektstatus abgebildet werden. Die notwendigen Projektstatusbereiche für ein UPV Dashboard wurden aufgrund von empirischen Untersuchungen ermittelt. Eine weitere Basis für ein UPV Dashboard wird u.a. durch Theorien zur Dashboard Implementierung und zum Dashboard Design gelegt. Das Ergebnis stellt ein „Grundgerüst“ für ein UPV Dashboard dar, das für andere Offshore IT- Projekte angepasst und eingesetzt werden kann.

Das primäre Ziel eines UPV Dashboards ist, eine „konsistente“ und „transparente“ Gesamtsicht auf den Projektstatus für alle Projektbeteiligten zu erhalten. Die Konsistenz wird durch den schlüssigen Aufbau und die Zusammensetzung, der einzelnen Bestandteile eines UPV Dashboards gegeben. Die Transparenz beschreibt, dass ein UPV Dashboard für den Benutzer nachvollziehbar ist. Diese Gesamtsicht enthält daher nur die nötigsten und wichtigsten Bestandteile, die von allen Projektbeteiligten verstanden werden. Damit soll das bestehende Problem gelöst werden, eine Übersicht über den Projektstatus zu bekommen. Die Grundlage für die Auswahl der Bestandteile eines UPV Dashboards wird durch die Sicht der Projektbeteiligten gelegt. Daher auch der Begriff „Unified“ (vereinheitlicht). Die unterschiedlichen Sichten der Offshore Projektbeteiligten auf den Projektstatus werden im UPV Dashboard zusammengefasst und vereinigt. Wichtig hierfür ist die Betrachtung verschiedener Kulturen. Die Erkenntnisse über Gemeinsamkeiten und Unterschiede der Kulturen können im Anschluss zu einer gemeinsamen Sicht vereint werden. Bei der UPV wurde insbesondere der Fokus auf die indische und die deutsche Sicht der Projektbeteiligten gelegt.

Ein weiterer Bestandteil der UPV ist das „Team Dashboard”. Das Team Dashboard besitzt die gleichen Ziele wie ein UPV Dashboard, bezieht sich jedoch auf die Gesamtsicht eines einzelnen Projektteams.

Abgrenzung der UPV

Um falsche Vorstellungen über die UPV zu vermeiden, wird hier eine Abgrenzung vorgenommen. Die UPV ist nicht als vollständige Lösung, Prototyp oder als Werkzeug zu verstehen, das sofort in ein Projekt eingesetzt werden kann. Sie ist ein „Leitfaden“, um ein UPV Dashboard in einem Projekt entwickeln und einzusetzen zu können. Die UPV beschreibt daher ein „Konstrukt”, das aus Basiselementen besteht und durch weitere Elemente erweitert werden kann. Weiterhin kann die UPV in Verbindung mit PM-Methodiken wie z.B. ]„effizientes Projektmanagement” (ePM) genutzt werden. Sie bezieht sich demnach nicht auf eine bestimmte PM-Methodik. Die UPV beschreibt zudem Beispiele, wie ein UPV Dashboard benutzt werden kann. Die beschriebenen Anwendungsfälle stellen nur einen Ausschnitt der Nutzungsmöglichkeiten dar. Weitere Arten ein UPV Dashboard zu benutzen sind denkbar und beschränken sich nicht auf die aufgeführten Beispiele.

2.2 Wissenschaftlicher Forschungsstand

Dieser Abschnitt behandelt den wissenschaftlichen Stand zur Entwicklung einer Gesamtsicht auf den Projektstatus von Offshore IT-Projekten, mit Fokus auf Indien und Deutschland. Dabei wird ein Überblick über existierende Lösungen für die Problemstellung bzw. ähnliche Problemstellungen gegeben. Eine Analyse stellt die Mängel der Lösungen dar und begründet, weswegen die Lösungen nicht für die Problemstellung der Bachelorthesis in Frage kommen.

2.2.1 Forschungsstand zur Problemstellung der Bachelorthesis

Durch die Literaturrecherche konnten keine wissenschaftlichen Arbeiten oder Publikationen gefunden werden, die sich genau auf die Problemstellung der Bachelorthesis beziehen. Es existieren jedoch Abschlussarbeiten, die Konzepte zur Projektkontrolle durch Dashboards im Unternehmen beschreiben. (Sank, B., 1998; Grell, R., 2001; Mollazadeh, A., 2009) Diese Konzepte sind speziell auf interne Projekte im Unternehmen zugeschnitten. Sie bieten daher Lösungen an, um den Status eines Projekts festzustellen, aber keine, die sich auf Offshore Projekte beziehen. Zudem fällt auf, dass in letzten Jahren nur wenige Arbeiten zu diesem Thema verfasst wurden.

Bei der Praxis von IT Offshoring (vgl. VI.8) herrscht dagegen kein Mangel an Studien oder Erkenntnissen. (Gadatsch, A., 2006; Wasim, A., 2007; Scisly, L., 2010; Moczadlo, R., 2011; Grimme, K., 2011) Die Wissenschaft konzentriert sich dabei mehr auf die Realisierung und die Erfolgsfaktoren von Offshore Projekten. Es ist anzumerken, dass keine Studien zu essentiellen Projektstatusbereichen für Offshore IT-Projekte ermittelt werden konnte.

In der Literatur finden sich Vorgehensweisen zur Entwicklung und Einführung von „Dashboards“, die eine Gesamtsicht auf den Projektstatus ermöglichen. (Eckerson, W. W., 2006; Malik, S., 2005) Dabei werden Erläuterungen zum allgemeinen Aufbau von Dashboards und zur Ermittlung von Kennzahlen für das Dashboard gegeben. Die Beschreibungen fixieren sich aber nicht auf einen bestimmten Projekttypen oder ein bestimmtes Umfeld, in dem ein Projekt durchgeführt wird. Weiterhin gibt es eine Vielzahl an PM-Werken, die sich auch mit dem Thema „Projektstatus“ auseinandersetzen. Dazu gehören u.a. „IT Offshore realisieren“ (Gadatsch, A., 2006), „Project Management Book of Knowledge“ (Project Management Institute, Inc (PMI), 2008) sowie „Projektmanagement - Zertifizierung nach IPMA(3.0)“ (Geiger I. K., Pifko C., 2009). Die Projektstatusbereiche werden zwar erläutert, aber es wird nicht auf deren Notwendigkeit für Offshore IT-Projekte eingegangen.

2.2.2 Forschungsstand zu PM-Methoden für Offshore IT-Projekte

Da die Literaturrecherche nur wenig zum wissenschaftlichen Stand beiträgt, musste ein anderer Weg gewählt werden. An dieser Stelle wird daher der Blick auf bestehende PM-Methoden gerichtet. Hiermit werden mögliche Vorgehensmodelle untersucht, die der UPV ähnlich sind.

DELIVER Unified Project Management (UPM)

DELIVER UPM ist eine PM-Methode, in der Aktivitäten zur erfolgreichen Planung und Steuerung von Projekten definiert werden. Die Methode basiert auf Erfahrungen von Capgemini und auf dem Project Management Institute (PMI) Standard „PMBoK“. DELIVER UPM eignet sich sowohl für große als auch für kleine Projekte sowie Projekte mit Onshore und Offshore Teams. (vgl. Capgemini, 2011b)

Die Methodik besitzt in Bezug auf die Projektsteuerung ein Projekt Dashboard. Die Informationen zum Aufbau dieses Projekt Dashboards sind jedoch kurz und allgemein gehalten. D.h., DELIVER UPM definiert nur zwei Schritte, um das Projekt Dashboard aufzusetzen. Dabei werden keine Details für mögliche Kennzahlen oder Kontrollelemente eines Dashboards gegeben. Die erste beschriebene Aktivität ist, die zu messenden Kennzahlen aus der Sicht von Capgemini und der Sicht des Kunden zu identifizieren. Die Aktivität definiert zudem, dass der Engagement Manager (EM) diese Aufgabe auszuführen hat. (vgl. Capgemini, 2011c) Die zweite Aktivität enthält nur die Information, dass der EM das Projekt Dashboard aufsetzen soll. Er hat zudem die Aufgabe, den Prozess zur Speicherung und Sammlung der Kennzahlen zu dokumentieren. (vgl. Capgemini, 2011d)

In der PM-Methode werden nur wenige Details zum Vorgehen und zum Aufbau eines Projekt Dashboards gegeben. Welche Projektstatusbereiche abgebildet werden sollen, lässt sich in DELIVER UPM nicht feststellen. Diese PM-Methode stellt damit einen unzureichenden Ansatz, um das Problem der Bachelorthesis zu lösen.

Effizientes Projektmanagement (ePM)

ePM ist eine weitere PM-Methode, die auf dem PMI Standard PMBoK basiert. Sie enthält Verfahrensweisen für die Planung und Steuerung von Projekten über alle Phasen. (vgl. Kronberg, A., 2007, S. 10 ff)

Gegenüber DELIVER UPM beschreibt ePM kein Werkzeug, um den Projektstatus darzustellen. Stattdessen werden in ePM Methoden erläutert, mit dem der Fortschritt des Projekts gemessen werden kann. Hierzu gehören u.a. die Restaufwandsschätzung und das Earned Value Management (vgl. VI.4). (vgl. Kronberg, A., 2007, S. 90 - 97) ePM gibt daher weder erforderliche Projektstatusbereiche vor, noch eine Anleitung, wie eine Gesamtsicht auf den Projektstaus entworfen werden kann. Diese PM-Methode bietet daher keine ausreichenden Informationen zur Problemlösung der Bachelorthesis. Sie gibt jedoch einen Überblick über die Möglichkeiten, um den Projektfortschritt zu messen.

2.2.3 Forschungsstand zu Dashboards für Offshore IT-Projekte

Im Folgenden werden aktuelle Dashboard Implementierungen, die u.a. für Offshore Projekte konzipiert wurden, auf die Problemstellung der Bachelorthesis untersucht. Im Anschluss daran werden die Projektstatusbereiche der Dashboard Beispiele tabellarisch zusammengefasst. Dies ermöglicht einen ersten Eindruck über deren Wichtigkeit zu bekommen.

Accelerated Delivery Platform’s Agile Dashboard

Das „Accelerated Delivery Platform’s (ADP) Agile Dashboard“ ist ein frei verfügbares Werkzeug, mit dem Projekte gesteuert und kontrolliert werden können. (vgl. Accelerateddeliveryplatform.com, 2011) Diese Art von Dashboard wird meist in Projekten mit verteilten Projektteams eingesetzt. Unter „verteilten Projektteams“ versteht man beispielsweise Projektteams in Offshore Szenarien. (vgl. Hoogendoorn, S., 2011) Das Dashboard ist speziell auf Softwareentwicklungsprojekte ausgelegt, die agile Methoden (Abrahamsson, P. et al. 2002) anwenden. Der Aufbau eines Dashboards enthält unterschiedliche Sichten, mit denen Projekte, Projektteams, Arbeitspakete und Komponenten von Arbeitspaketen verwaltet werden können. Der Projektfortschritt wird durch ein Burndown-Chart (vgl. VI. 1) und den Status einzelner Arbeitspakete vermittelt. (vgl. Hoogendoorn, S., 2011)

Die Vorteile des Dashboards sind, dass es speziell für Offshore IT-Projekt entwickelt wurde und sich besonders für agile Projekte eignet. Der Projektfortschritt wird übersichtlich dargestellt und bezieht sich auf den Entwicklungsfortschritt. (vgl. Hoogendoorn, S., 2011) Weitere Kennzahlen werden in dieser Lösung jedoch nicht aufgeführt und bieten daher nur eine eingeschränkte Sicht auf den Status eines Projekts. Außerdem ist das Dashboard nur für Softwareentwicklungsprojekte brauchbar, in denen agile Methoden angewendet werden. Dies ist gegenüber dem UPV Dashboard, welches nicht auf ein bestimmtes Softwareentwicklungsmodell ausgerichtet ist, als eine Schwäche anzusehen. Aus diesen Gründen kann dieses Dashboard keine Antwort zur Problemstellung geben.

Microsoft Sharepoint

„Microsoft Sharepoint“ ist eine Business Plattform, die die Zusammenarbeit in einem Unternehmen oder in Projektteams unterstützt. (vgl. Microsoft, 2011a) Es bietet u.a. die Möglichkeit Dashboards zu erstellen, die an den Benutzer angepasst sind:

- „My Dashboard“ ist ein Dashboard, das ein Überblick über die Aufgaben des Benutzers gibt.
- Das „Project Dashboard“ und das „Progress Dashboard“ beschreiben den eigenen Fortschritt sowie den Fortschritt des Projektteams.
- Das „Quality Dashboard“ gibt Auskunft über die Qualität des Projekts.
- Im „Test Dashboard“ werden Informationen über den Testfortschritt und Testfälle gegeben.
- Aus dem „Bugs Dashboard“ werden der Fortschritt der Fehlerbehebung und relevante Kennzahlen der Bugs visualisiert.
- Im „Build Dashboard“ kann der Qualitätsstatus (vgl. VI. 14) verschiedener Softwareversionen überprüft werden.

(vgl. Microsoft, 2011b)

Innerhalb der Dashboards werden Dashboard Elemente vorgegeben, die den Status je nach Typ eines Dashboards beschreiben. Im „Project Dashboard“ werden beispielsweise Burndown-Charts, wichtige Termine oder Arbeitskomponenten angezeigt. (vgl. Microsoft, 2011b) Damit werden außer dem Entwicklungsfortschritt keine anderen Bereiche eines Projektstatus erkennbar. Weiterhin sind die Dashboards in verschiedene Bereiche getrennt. Der Nutzer muss daher selbst entscheiden, welche Projektbereiche er kontrollieren möchte. Daher bietet diese Lösung keinen Ansatz für die vorliegende Problematik.

Global Software Management von ITC Software

„Global Software Management“ (Itcsoftware.com, 2011) von ITC Software ist ein kostenpflichtiges Dashboard, um Offshore Softwareentwicklungsprojekte zu steuern. Es richtet sich an Führungskräfte oder Stakeholder (vgl. VI.16), welche die Performance ihrer Projekte kontrollieren wollen. Die Performance der Kennzahlen wird im Dashboard durch Ampeldarstellungen vermittelt. Zu diesen Kennzahlen gehören u.a. die Kostenvarianz (vgl. VI.4), die Zeitplanvarianz (vgl. VI.4) sowie die Qualität eines Projektes. Das Dashboard ermöglicht ebenfalls eine Sicht auf den Status einzelner Projekte. Hierbei können verschiedene Bereiche verwaltet werden, wie z.B. PM, Ressourcen Management oder Test Management. (vgl. Itcsoftware.com, 2011)

Diese Lösung bietet eine Sicht auf unterschiedliche Bereiche eines Projektstatus, aber keine, die eine Gesamtsicht beschreibt. Folglich lässt sich der Status eines Projekts nicht direkt vom Dashboard ablesen. Stattdessen fordert es den Benutzer dazu auf, sich über mehrere Sichten zu informieren. Weiterhin wird in diesem Dashboard nicht deutlich, welche Projektstatusbereiche wirklich erforderlich sind. Das Dashboard dient damit mehr dem PM, um einzelne Bereiche eines Projekts zu steuern, als den Projektstatus für das Projektteam verständlich darzustellen. Dieses Werkzeug bietet damit keine Antwort zum Problem der Bachelorthesis.

Projekt start Status Dashboard

Diese Implementierung wird derzeit im Offshore IT-Projekt start genutzt, um den Status des Projekts zu erkennen. Es dient zudem als Grundlage für projektinterne Statusmeetings zwischen Onshore und Offshore PMs. Das Dashboard ist in vier Bereiche aufgeteilt (Betriebsstatus, Entwicklungsfortschritt, Qualitätsstatus, Finanzstatus). Der Status der einzelnen Bereiche wird jeweils durch weitere Elemente beschrieben. Hierzu gehören z.B. Design, Implementierung oder Meilensteine. Im Dashboard werden Ampeln eingesetzt, um den Status interpretieren zu können. (vgl. Capgemini, 2011e) Diese Darstellung besitzt den Vorteil, dass der Zustand der einzelnen Bereiche auf einfache Weise vermittelt wird. Jedoch lässt sich der Gesamtprojektstatus nicht feststellen. Das Dashboard eignet sich daher mehr für den Entwicklungsstatus und löst demzufolge nur ansatzweise die Problemstellung.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 2.1 Vergleich der Projektstatusbereiche von Dashboards

Aus Tabelle 2.1 und der Analyse der einzelnen Dashboards erkennt man, dass keine genauen Vorgaben für obligatorische Projektstatusbereiche gemacht werden. Die Mehrheit der Implementierungen gibt dem Benutzer die Freiheit, das Dashboard selbstständig zu entwickeln. Bestimmte Projektstatusbereiche stehen je nach Implementierung zur Verfügung. Diese lassen aber keinen Rückschluss auf die Erforderlichkeit von Projektstatus-Elementen in Offshore IT-Projekten zu. Sie stellen demzufolge für die Problemstellung der Bachelorthesis keinen ausreichenden Lösungsansatz. Diese Erkenntnis ist auch das Fazit der vorliegenden Ermittlung des wissenschaftlichen Forschungsstands. Deshalb soll mit dieser Arbeit eine geeignete Lösung geschaffen werden.

2.3 Theoretische Grundlagen der UPV

Dieser Abschnitt stellt die theoretischen Grundlagen vor, um das Konzept der UPV entwickeln zu können. Dabei wird zunächst die Basis für den Aufbau von Dashboards gelegt. Im Anschluss daran wird das Change Management Modell von Kotter erläutert, um hieraus den Einführungsprozess eines UPV Dashboards entwerfen zu können. Um sich ausführlich mit diesen Themen auseinanderzusetzen, wird als Literatur (Eckerson, W. W., 2006), (Few S., 2006) sowie (Kotter, J. P., 1996) empfohlen

2.3.1 Theoretischer Aufbau von Dashboards

Der Ursprung von „Dashboards“ (vgl. VI.3) geht zurück auf die „Executive Information Systems“ (EIS). EIS wurden in den 80er-Jahren von Führungskräften entwickelt, um die finanzielle Situation ihres Unternehmens darzustellen. (vgl. Few S., 2006, S. 6) In der IT wird dieser Begriff synonym für eine Benutzeroberfläche verwendet, die Informationen in einer übersichtlichen und verständlichen Weise darstellt. (vgl. SearchCIO.com, 2011b) Die theoretischen Konzepte zum Aufbau eines Dashboards werden im Folgenden untersucht. Dabei wird in diesem Unterabschnitt ein Überblick über die unterschiedlichen Typen und Merkmale eines Dashboards gegeben.

2.3.1.1 Drei Anwendungen von Dashboards

Eckerson charakterisiert Dashboards als Anwendungen, die drei Anwendungsmöglichkeiten bereitstellen. Er bezeichnet die Anwendungsmöglichkeiten als „Three Applications“ (drei Anwendungen):

1. Monitoring application (Kontrollanwendung). Es ermöglicht dem Benutzer auf einen Blick, die kritischen Informationen in Form von Graphen, Tabellen oder Symbolen zu erkennen.
2. Analyse application (Analyseandwendung). Es ermöglicht dem Benutzer, Daten auf verschiedenen Dimensionen zu analysieren, um hierdurch auf die Ursache des Problems zu stoßen.
3. Management application (Managementanwendung). Es ermöglicht den Managern ihr Unternehmen zu steuern. Darüber hinaus erhalten sie auch Feedback, zu einer Reihe von kritischen Aktivitäten in den Unternehmensbereichen.

(vgl. Eckerson, W. W., 2006, S. XIII)

2.3.1.2 Drei Typen von Dashboards

Die unterschiedlichen Dashboard Typen sind nicht für jede Projektrolle geeignet.

Je nach Anwendungsfall, wie von Eckerson durch die „drei Anwendungen“ (vgl. 2.3.1.1) beschrieben, lassen sich drei Dashboard Typen unterscheiden. (vgl. Eckerson, W. W., 2006, S. XIII)

1. Operationelles Dashboard. Das operationelle Dashboard zeigt Informationen zu den laufenden Prozessen im Projekt an. Oftmals werden hierfür Echtzeitdaten benutzt, die jede Minute, jede Stunde oder jeden Tag aktualisiert werden. Der Benutzer kann zudem durch Warnmeldungen in der Anzeige, auf problematische Kennzahlen im Dashboard aufmerksam gemacht werden. Verbessernde Maßnahmen können somit innerhalb kürzester Zeit getroffen werden. (vgl. Few S., 2006, S. 42) Das „Monitoring“ steht, gegenüber der „Analyse“ und dem „Management“, bei dieser Kategorie von Dashboard im Vordergrund. (vgl. IBM, 2009, S. 4) Few charakterisiert das Design und den Aufbau von operationellen Dashboards als simpel, dynamisch und von sofortiger Natur. Wenn beispielsweise eine Maschine ausfällt, wird dies in einem operationellen Dashboard sofort deutlich gemacht. (vgl. Few S., 2006, S. 42)

2. Taktisches Dashboard. Taktische Dashboards geben eine übergeordnete Sicht auf das Projekt oder einen Unternehmensbereich wieder. Sie zeigen z.B. Tabellen und Grafiken für die Verantwortungsbereiche an, um Trends und Probleme darzustellen. Der Schwerpunkt von taktischen Dashboards liegt in der Analyse. (vgl. IBM, 2009, S. 4) Im Unterschied zum operationellen Dashboard ist die Ansicht laut Few eine Momentaufnahme, die nur in größeren Intervallen aktualisiert wird. Einen weiteren Unterschied sieht Few in der Möglichkeit, mit den Daten zu interagieren und beschreibt dies als „drilling down into underlying details“ (das Bohren in unterliegende Details). (vgl. Few S., 2006, S. 41) Dadurch gibt das Dashboard nicht nur einen Hinweis auf ein Problem. Es bietet zudem die Funktion über einen „drill-down“ (auf den Grund gehen), auf eine tiefere Ebene eines Dashboards zu gelangen. Damit kann die Ursache des Problems gefunden werden. Praktisch bedeutet dies, dass man über eine Verlinkung im Dashboard auf Dokumente mit einer höheren Detailtiefe zugreift. (vgl. Few S., 2006, S. 41)

3. Strategisches Dashboard. Strategische Dashboards sind auch bekannt unter dem Namen „Executive Dashboards“. Sie liefern einen schnellen Überblick, um Managern bei ihren strategischen Entscheidungen zu unterstützen. Der Aufbau ist simpel und enthält nur die nötigsten Informationen. Daher sind strategische gegenüber taktischen Dashboards weniger dazu geeignet, um mit den unterliegenden Daten zu interagieren. Sie dienen vielmehr dazu, um z.B. wöchentlich oder monatlich den aktuellen Zustand festzustellen. (vgl. Few S., 2006, S. 41) Strategische Dashboards stehen auf einer höheren Ebene als taktische Dashboards. Sie überwachen die Ausführung von strategischen Unternehmenszielen und Kennzahlen im „top-down“ (von oben nach unten) Prinzip. Diese Art von Dashboards wird daher für das Management genutzt und unterstützt Methoden, wie beispielsweise Balanced Scorecard (Kaplan, R. S., Norton, D. P., 1996). (vgl. IBM, 2009, S. 4)

2.3.1.3 Drei Schichten von Dashboards

Ein weiteres Merkmal von Dashboards erkennt Eckerson in den drei Schichten bzw. Sichten auf die Information:

1. Zusammenfassende grafische Ansicht
2. Multidimensionale Ansicht
3. Detail-/Operationelle Ansicht

Dies sind die drei Möglichkeiten, welche die Mehrheit der Benutzeranforderungen erfüllen. Das Vorgehen bei der Benutzung von Dashboards beginnt in der zusammenfassend grafischen Ansicht. Hierbei werden Hauptkennzahlen auf ungewöhnliche Werte analysiert. Weitere Informationen werden über die multidimensionale Ansicht genauer betrachtet, um versteckte Probleme zu entdecken. Im letzten Schritt wird über die Detail-Ansicht die genaue Ursache des Problems festgestellt. (vgl. Eckerson, W. W., 2006, S. XIII)

2.3.1.4 Dashboard Kennzahlen

Die richtige Wahl der Dashboard Kennzahlen zur Messung des Projektfortschritts ist entscheidend für die Erreichung der Projektziele. Um diese Kennzahlen zu finden, ist eine Strategie nötig, welche Ziele, Werte und Visionen definiert. (vgl. Eckerson, W. W., 2006, S. 71)

Man unterscheidet bei Kennzahlen zwischen „Leading Indicators“ (Frühindikatoren) und „Lagging Indicators“ (Spätindikatoren). Leading Indicators messen Aktivitäten, die ausschlaggebend für die zukünftige Performance sind. Eckerson beschreibt sie als „mächtige Kennzahlen”, die sich jedoch schwer definieren lassen. Dieser Typ von Indikator misst die Schlüsselelemente, die „Unternehmenswert” schaffen. Zudem lassen sich aus Leading Indicators zukünftige Ergebnisse ablesen. Dies ermöglicht Managern, bevorstehende Ereignisse in der Gegenwart zu beeinflussen. (vgl. Eckerson, W. W., 2006, S. 199f). Lagging Indicators messen das Ergebnis vergangener Aktivitäten, wie beispielsweise finanzielle Messgrößen. Sie sind daher gegenüber Leading Indicators einfacher festzulegen. (vgl. Eckerson, W. W., 2006, S. 199)

Eines der Hauptcharakteristika von Kennzahlen ist, dass man aus ihnen Handlungen ableiten kann, wenn sich ein Trend nach unten bzw. nach oben entwickelt. Die situationsverbessernden Handlungen sollten den Benutzern von Kennzahlen bekannt sein, da ansonsten die Kennzahlenmessung keinen Mehrwert schafft. (vgl. Eckerson, W. W., 2006, S. 200f)

Eckerson beschreibt 12 Charakteristika von effektiven Kennzahlen:

1. Aligned (abgestimmt). Kennzahlen sind mit den Unternehmensstrategien und -Zielen abgestimmt.

2. Owned (besitzend). Jede Kennzahl hat ein Individuum oder eine Gruppe auf Unternehmensseite, die dafür die Verantwortung trägt.
3. Predictive (vorhersagbar). Kennzahlen müssen Unternehmenswert erzeugen und sind demzufolge „Leading Indicators“, für eine von der Organisation gewünschte Performance.
4. Actionable (wirkungsvoll). Kennzahlen werden mit relevanten Daten versorgt, damit der Benutzer in das Geschehen eingreifen kann, um die Performance zu verbessern.
5. Few in number (wenig). Kennzahlen sollten sich an Aktivitäten mit einer hohen Priorität oder einem hohen Unternehmenswert orientieren, anstatt sich auf viele kleinere Themen zu konzentrieren.
6. Easy to understand (einfach zu verstehen). Kennzahlen sollten klar und einfach verständlich sein und nicht auf Basis von komplexen Werten bestehen. Der Benutzer muss wissen, wie er die Kennzahlen beeinflussen kann.
7. Balanced and linked (ausgewogen und verknüpft). Kennzahlen sollten sich gegenseitig unterstützen und nicht gegensätzlich sein.
8. Trigger changes (lösen Veränderung aus). Das Messen von Kennzahlen sollte in einer Organisation eine Kettenreaktion positiver Änderungen verursachen.
9. Standardized (standardisiert). Kennzahlen basieren auf standardisierten Definitionen, Regeln und Berechnungen, wodurch sie über alle Dashboards in der Organisation genutzt werden können.
10. Context driven (kontextgetrieben). Kennzahlen setzten die Performance durch Ziele und Schwellen in einen Kontext. Der Benutzer kann die Performance z.B. über einen festgelegten Zeitraum verfolgen.
11. Reinforced with incentives (durch Anreize verstärkt). Anreize können für die Organisation geschaffen werden, um einen bestimmten Wert einer Kennzahl zu erreichen. Die Anreize sollten jedoch nur bei stabilen Kennzahlen bestehen.
12. Relevant (Relevanz). Kennzahlen verlieren über die Zeit stetig an Wirkung und müssen daher periodisch überprüft und angepasst werden. (vgl. Eckerson, W. W., 2006, S. 201)

2.3.2 Benutzeroberfläche von Dashboards

In diesem Unterabschnitt werden verschiedene Dashboard Typen und Merkmale beschrieben, um im Verlauf der Arbeit ein UPV Dashboard entwickeln zu können. Der Fokus liegt hier bei der Benutzeroberfläche eines Dashboards. Hierzu werden Hinweise zum visuellen Aufbau gegeben und an geeigneten Beispielen erläutert. Der erste Eindruck ist entscheidend dafür, ob ein Dashboard langfristig benutzt wird. Daher sollten nach Eckerson Zeit und Kraft bei der Konzeption eines Dashboards aufgewendet werden. Jedes Design Element eines Dashboards muss durchdacht sein und eine Aufgabe in der Darstellung erfüllen. Unnötige Bilder, Farben oder Formen sind von der Benutzeroberfläche zu entfernen, wenn sie keine weitere Information vermitteln. Sie wirken als Ablenkung und sind daher überflüssig für das Dashboard. (vgl. Eckerson , 2006, S.225) 2.3.2.1 Darstellung von Dashboards

Eine der Hauptanforderungen eines Dashboards ist es, relevante Informationen auf eine Seite zu bekommen. Benutzer müssen damit nicht über mehrere Seiten gehen, um sich zu informieren. Die Information muss auf einen Blick sichtbar und gleichzeitig übersichtlich aufgebaut sein. Hierbei stellt sich die Frage, welche Informationen dargestellt werden sollen. (vgl. Few, S., 2006, S. 50)

Im ersten Schritt muss die Priorität der Informationen definiert werden und die Reihenfolge, in der die Information angezeigt wird. Dabei hat es sich laut Eckerson bewährt, Informationen mit hoher Priorität weiter oben anzuzeigen und Informationen mit niedrigerer Priorität unterhalb darzustellen. Drei bis sieben Kennzahlen sind laut Aussage von Experten optimal für die Anzeige. Der Inhalt der Grundinformation sollte in abgekürzter Form vorliegen, um diesen in Form einer Kennzahl darzustellen. Dies wird i.d.R. durch grafische Elemente erreicht und ermöglicht, Platz auf der Benutzeroberfläche eines Dashboards zu sparen. Beim Design der grafischen Elemente muss die Frage gestellt werden, ob das Element die benötigten Informationen enthält und so wenig Platz wie möglich verbraucht. Weiterhin sollten die ausgewählten grafischen Elemente für die dargestellte Information geeignet sein, um Metrik, Kontext und Status aufzeigen. Laut Eckerson nehmen grafische Elemente, wie Thermometer oder Drehzahlmesser viel Platz ein und sind daher nicht effektiv. (vgl. Eckerson, W. W., 2006, S. 226f)

2.3.2.2 Kontexttypen von Dashboards

Das Hauptziel von Dashboard Elementen ist es, dem Benutzer den Kontext auf einfache Weise zu vermitteln. (vgl. Eckerson, W. W., 2006, S. 228) Dabei sind drei Aspekte Bestandteil eines Kontextes:

1. Performance Status. Dies beschreibt, ob die Performance in dem gewählten Maß positiv oder negativ ist. Die Performance wird in verschiedene Bereiche eingeteilt, so dass jeder Bereich seine eigene Farbe

oder sein eigenes Symbol besitzt. Ein Beispiel hierfür wäre die Performance eines Teams bezüglich der Fehlerbehebung:

- „Sehr hoch“ (blau): > 90%
- „Hoch“ (grün): 70% bis 90%
- „Normal“ (gelb): 50% bis 60%
- „Niedrig“ (rot): < 50%

2. Performance Trend. Dies beschreibt den Trend von der Vorperiode zur

aktuellen Periode. Der Trend für „hoch“, „tief“ oder „gleich“ sollte klar definiert sein. Pfeile oder Plus-/Minus-Symbole sind hier Darstellungsmöglichkeiten, die für einen Trend benutzt werden können. Eine weitere Alternative, die von Hewlett Packard genutzt wird, ist den Trend Pfeil farblich zu kennzeichnen. Hierdurch werden Status und Trend in einem Symbol verdeutlicht.

3. Performance Varianz. Dies beschreibt die Abweichung zu einer

festgelegten Größe. Die Darstellung kann über Text in einem Graphen erfolgen.

(vgl. Eckerson, W. W., 2006, S. 228 - 230)

2.3.2.3 Positionierung in Dashboards

Die Positionierung gibt den Elementen im Dashboard eine weitere Bedeutung. Beispielsweise wird Elementen im Quadranten links oben oder in der Mitte eine besondere Aufmerksamkeit geschenkt. Eine weitere Möglichkeit ist Elemente zu gruppieren. Bei Vergleichen zwischen zwei Werten sollten diese in kurzer Distanz zueinander aufgebaut werden. (vgl. Eckerson, W. W., 2006, S. 231)

2.3.2.4 Navigation in Dashboards

Das Navigieren, welches auch als „Drill“ (Bohren) bezeichnet wird, stellt im Dashboard die Möglichkeit, auf die Grunddaten zuzugreifen. Eines der Hauptprobleme ist, dass Benutzer durch die Navigation die Übersicht verlieren und nicht mehr den Weg zurück finden. Daher ist laut Eckerson ein Dashboard so zu konzipieren, dass auch ein „12-jähriger“ sich darin zurechtfindet. Eine Variante der Navigation ist der „One-Click Drill“, bei dem über einen Links-Klick detailliertere Informationen angezeigt werden. Die Navigation kann auch über vorgegebene Wege bzw. „Drill Paths“ geschehen. Eine dynamische Karte sollte ebenfalls angezeigt werden, damit der Benutzer erkennt, wo er sich befindet. (vgl. Eckerson, W. W., 2006, S. 234 ff)

2.3.2.5 Symbole und Elemente in Dashboards

Die Information, die in einem Dashboard angezeigt wird, soll für den Benutzer klar und verständlich sein. Daher muss der Qualität, der darzustellenden Dashboard Elemente, eine hohe Aufmerksamkeit gewidmet werden. (vgl. Few, S., 2006, S. 64) Die Information wird über bekannte Darstellungsformen, wie Graphen oder Ampeln visualisiert. Nachfolgend werden häufig genutzte Symbole und Elemente kurz vorgestellt.

Ampel

Ampeln (vgl. Abb. 2.1) sollten nach dem Prinzip „weniger ist mehr“ benutzt werden. D.h., eine Ampel wird nur dann angezeigt, wenn Handlungsbedarf besteht. Dies verdeutlicht dem Benutzer, dass, wenn das Symbol nicht angezeigt wird, keine weitere Analyse notwendig ist. Eine platzsparende Alternative zur Ampel stellt das zirkuläre Lichtsymbol dar. (vgl. Eckerson, W. W., 2006, S. 227f)

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1 Ampel

Sparkline

Sparklines (vgl. Abb. 2.2) geben einen Überblick über den Trend, ohne eine quantitative Skala zu benutzen. Sie werden vor allem dann eingesetzt, wenn man eine High-Level-Perspektive auf den Verlauf einer Performance Kennzahl haben möchte. (vgl. Eckerson, W. W., 2006, S. 232)

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.2 Sparkline

Bullet-Graph

Ein Bullet-Graph (vgl. Abb. 2.3) ist ein einziger Balken, der die Performance durch seine Farbintensität darstellt. Dieser Balken besitzt zudem eine weitere Linie, die das Performance Ziel anzeigt. Der Vorteil dieses grafischen Elements bewirkt geringen Platzverbrauch und gute Lesbarkeit. (vgl. Eckerson, W. W., 2006, S. 232) Ein Bullet-Graph eignet sich, um eine Kennzahl darzustellen, die mit einer quantitativen Skala verglichen werden soll. Die quantitative Skala kann dabei als Nominal-, Ordinal-, oder Intervalskala visualisiert werden. (vgl. Few S., 2006, S. 125 f) Abb. 2.3 zeigt eine Intervalskala für die Einnahmen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.3 Bullet-Graph

Die klassischen Darstellungsformen finden auch in Dashboards Anwendung, um eine bestimmte Information zu vermitteln. Abb. 2.4 zeigt eine Verteilung in einem Kreisdiagramm an. Diese Kreisdiagramme geben Teile eines „Gesamten“ wieder. Sie können jedoch als Balkendiagramme verständlicher visualisiert werden. Laut Few sind Balkendiagramme einfacher zu lesen und daher zu bevorzugen. Die Balken heben dabei einzelne Werte hervor, wodurch die Balkenlänge verschiedener Werte vergleichbar wird. (vgl. Few, S., 2006, S. 134)

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.4 Kreis- und Balkendiagramm

[...]