Anleitungen für die Erstellung von Dashboards: Whitepaper

Dieses Whitepaper ist Teil unserer Sammlung "Aus der Praxis". Hierin werden einige häufiger auftretende Probleme beschrieben, auf die Sie ggf. stoßen, wenn Sie in Ihrer EPM-Umgebung Dashboards verwenden möchten. Darüber hinaus wird erörtert, dass ein professionell aussehendes Dashboard dazu führen kann, dass die Benutzer die Qualität der Daten nicht mehr prüfen, z. B. "Stammdaten" und aktualisierte Daten. Es befasst sich damit, dass Daten für Dashboards ein Genehmigungsverfahren durchlaufen sollten, um die hohe Qualität und Vollständigkeit der Daten sicherzustellen. Es werden einige Techniken genannt, mit denen verhindert werden kann, dass Personen Daten verfälschen, die sich unter ihrer Kontrolle befinden und somit die Daten, die im Dashboard angezeigt werden, zu falschen Schlüssen führen. Zum Schluss werden noch einige grundlegende Regeln aufgeführt, die Sie beim Erstellen von Dashboards für EPM berücksichtigen sollten.

Die Word-Version dieses Whitepapers finden Sie unter Anleitungen für die Erstellung von Dashboards.

Weitere Whitepapers finden Sie unter "Aus der Praxis" – Whitepapers.

Anleitungen für die Erstellung von Dashboards

Es lässt sich nicht verleugnen, dass Dashboards zurzeit voll im Trend liegen. Ganz gleich, ob es sich um eine Balkendiagramm, ein Histogramm, ein Kreisdiagramm oder eine Warnung in Form einer Ampel handelt: Die Führungsetage scheint den sofortigen Reaktionen eines Dashboards geradezu verfallen zu sein.

Business Intelligence Center-Website in SharePoint Server 2010

Und in Anbetracht des immer stärker werdenden Drucks auf unsere Unternehmenskultur, Ergebnisse schneller und immer schneller bereitzustellen, ist nicht zu erwarten, dass die Nachfrage nach Dashboards in Kürze abflauen wird.

Jede Projektmanagementsoftware ist ein idealer Kandidat für diese Art der Anzeige, da Projektmanagementdaten optimal für die Darstellung in Dashboards geeignet sind. Wenn wir uns anschauen, welche Arten von Daten für Dashboards benötigt werden, finden wir unterschiedliche Qualitäten:

  • Sind die Daten in einer Weise gruppiert, die angezeigt werden kann und verständlich ist?

  • Sind die Daten aktuell?

  • Gibt es irgendwelche Genehmigungs- oder Überprüfungsverfahren für die Daten?

  • Gibt es numerische Daten oder Datum/Uhrzeit-Daten, die dabei helfen können, Abweichungen zu erkennen?

Das sind genau die Daten, die wir in den Projektmanagementdaten aus einem Enterprise Project Management-System (EPM) wie Microsoft Project Server finden.

Daher ist es kaum überraschend, dass die meisten EPM-Systeme und auch Project Server über Funktionen zum Erstellen von Dashboards verfügen. Im Falle von Microsoft Project Server stammen diese Funktionen von SharePoint Server im Business Intelligence Center. Diese Art von System kann SQL-basierte Daten lesen und eine unglaubliche Vielzahl von grafischen Anzeigen generieren. Und genau wie bei einem Kind gibt es nichts, das Manager mehr lieben als ein glänzendes neues Spielzeug. Das Verlangen der Geschäftsleitung nach sofortigem Feedback aus Projekten kann so stark sein, dass viele Projektmanagementbüros sich gezwungen sehen, die Ansichten zu erstellen, noch bevor die zugrunde liegenden Daten bereit sind.

"Können Sie uns ein EPM-Dashboard erstellen?", wurde ich einst von einem leitenden IT-Manager gefragt, während ich mich in seinen Büros befand, um beim Entwurf der EPM-Umgebung zu helfen.

"Klar", antwortete ich.

"Könnten Sie das bis Freitag fertig haben?", fragte der Manager zu meinem Erstaunen.

"Hm, sicher", antwortete ich. "Nun, nicht diesen Freitag. Aber an irgendeinem zukünftigen Freitag."

Irgendwie fand er meinen Humor nicht komisch.

Der Mann war nur wirklich nicht blöd, aber dies zeigt den Druck, unter dem solche Leute stehen, wenn es darum geht, Tools für die schnelle Entscheidungsfindung voranzubringen.

Dashboards sind visuell so überzeugend, dass wir häufig vergessen, dass sie nur dazu da sind, etwas darzustellen, was in der Anzeige generiert wird. Bevor Sie sich also aufmachen, um zu erkunden, wie man ein Dashboard erstellt, und bevor Sie zu viel Zeit für die Auswahl von Farbpaletten oder die Farbe Ihrer Symbole aufwenden, sollten Sie sich mit einigen häufig auftretenden Problemen im Dashboardbereich befassen.

Das "Zauberer von Oz"-Syndrom

Erinnern Sie sich an die Szene im "Zauberer von Oz", als schließlich der Vorhang zurückgezogen wird und man sieht, dass es da nur einen ganz normalen Typen gibt, der an den Hebeln zieht und die Wählscheiben dreht, um diese ganze beeindruckende "Magie" zu erzeugen?

Reporting Services-Scorecard mit angezeigtem Projektstatus

Schöne Anzeigen, die von Menschenhand gesteuert werden, sind bei Dashboards weit verbreitet. Ein guter Teil der Arbeit wird für das Design und für die Präsentation aufgewendet, wozu auch tolle Grafiken, tolle Symbole, beeindruckende Farben und sogar Animationen und Soundeffekte gehören. Das Problem ist jedoch, dass niemand einen Pfad zwischen den Daten und dem Dashboard nachzeichnet, und so muss sich jemand hinsetzen und manuell vorgeben, welcher Indikator welche Farbe haben soll.

Wenn wir uns ein vorhandenes Dashboard zum ersten Mal anschauen, lohnt es sich immer, sich die Rohdaten anzeigen zu lassen. "Was bedeutet das hier, und können Sie mir zeigen, von was dieser Indikator gesteuert wird?", ist eine wichtige Frage. Führen Sie ein Mini-Audit für einige wenige Indikatoren durch, und verfolgen Sie sie zurück zu den zugrunde liegenden Daten.

Das Gleiche gilt beim Entwurf eines Dashboards. Für jeden Indikator muss es einen Pfad zurück zur Quelle geben, und optimal ist, wenn der dann auch noch dokumentiert ist. Wenn das Dashboard von einer Tabelle gesteuert wird, die Robert gerade mit seiner Meinung zum Projekt ausfüllt, sorgen Sie dafür, dass er Ihnen das sagt. Das geht dann schneller.

Alles messen

"Wenn wir es messen können, setzen wir es in das Dashboard" – das scheint das Mantra einiger Dashboard-Designer zu sein.

Scorecard mit Anzeige des Status für mehrere Projekte

Es ist einfach, sich in der Technologie der Dashboarderstellung zu verlieren, und auch der Adrenalinspiegel steigt instinktiv, wenn Sie Daten finden, die messbar und verständlich zu sein scheinen und Sie daraus einen Indikator machen können. Plötzlich haben Sie anstelle der langweiligen alten Kostenlisten ein rot gefülltes Thermometer oder Tachometer, das sich in den roten Bereich dreht, oder Pfeile in unterschiedlichen Farben. Das hört sich doch lustig an, oder? Versuchen Sie es mal eine halbe Stunde lang in Excel mit der neuen Funktion für bedingte Formatierungen von Excel 2010 (oder Excel 2013).

Probleme entstehen, wenn die Person, die ein Dashboard für die Geschäftsführung erstellen soll, sich so sehr von der Möglichkeit, einen Indikator zu erstellen, einnehmen lässt, dass sie sich nicht mehr fragt, ob dieser Indikator überhaupt sinnvoll ist. Die Frage lautet nicht immer, wie es geht, sondern manchmal auch, ob es überhaupt sinnvoll ist.

Wenn sich irgendwann einmal so viele visuell stimulierende Indikatoren auf der Seite befinden, dass sie wie das Armaturenbrett eines Space Shuttles aussieht, wissen Sie, dass Sie entweder wie ein Astronaut eine jahrelange Schulung benötigen oder sich das Leben einfacher machen müssen.

Hier eine Grundregel, die für weniger Anzeigen spricht: Für jeden Indikator muss es eine potenzielle Aktion geben, wirklich für jeden. Wenn Sie also einen Ampelindikator sehen und dieser rot ist, dann muss es eine geeignete Maßnahme geben, die in dem Fall von einer anderen Person in die Wege geleitet wird. Das kann so einfach sein wie: "Wenn die rote Lampe leuchtet, muss ein Projektmanager dem Leiter der PMO-Abteilung einen detaillierten Bericht vorlegen". Ganz gleich, um welche Aktion es sich handelt, es muss eine geben.

Unausgereifte Pläne

Sie würden keinen Kuchen essen, der nur mit der Hälfte der Zutaten zubereitet wurde, besonders dann nicht, wenn Sie nicht wissen, welche Hälfte fehlt. Auf ein Dashboard bezogen bedeutet das: Wie können Sie wissen, dass alle Daten vorhanden sind?

Statusindikatoren für mehrere Projektmetriken (Kosten, Status, Qualität, Ressource und Zeitplan)

Schauen wir uns beispielsweise mal einen Bericht zur Ressourcenkapazität an. Die Ressourcenampel steht auf Rot für die IT (die ist es doch immer, oder?). Nun möchte sich das Management näher mit dem Problem befassen, und wenn sie ins Detail gehen, ist die Antwort offensichtlich. Der Indikator muss rot sein, weil in der IT zu viele Mitarbeiter beschäftigt sind.

Histogramm mit Anzeige eines Vergleichs zwischen Projekten und Organisationskapazität

Das erste Histogramm zeigt das Problem. Die rote Linie gibt die Kapazität der Organisation an. Die gestapelten Histogramme zeigen die kombinierten Anforderungen; in der Darstellung wurden die Anforderungen aller Projekte addiert. Wenn wir dem Management dieses Dashboard präsentieren, würde die Entscheidung sofort und ganz offensichtlich lauten, dass die IT demnächst entweder wesentlich mehr Arbeit zu erledigen hat oder die Anzahl der Mitarbeiter reduziert werden muss.

OK, aber jetzt mal einen Moment innehalten. Kurz bevor der Plan zur Verringerung der Mitarbeiteranzahl in Kraft tritt, hat irgendjemand die glorreiche Idee, mal zu prüfen, ob in der Dashboardansicht alle Projekte angezeigt werden.

Angepasstes Histogramm mit Projektstatus, der die Personalverringerung berücksichtigt

Und siehe da, es werden nicht alle Projekte angezeigt.

Es gibt Projekte, die in der Legende angezeigt werden, im Histogramm werden jedoch keine Ergebnisse für diese Projekte angezeigt. Wo befinden sich diese Ergebnisse? Vielleicht wurden diese Projekte noch nicht veröffentlicht. Vielleicht muss der gesamte Projektumfang noch ermittelt werden. Vielleicht wurde der Ressourcenbedarf nicht auf der geeigneten Ebene definiert. Bei der Überprüfung der Daten sehen wir in einem zweiten Histogramm, dass es tatsächlich mehr Arbeit als Leute gibt und dass wir darüber nachdenken sollten, weiteres Personal einzustellen, Arbeiten an Subunternehmer auszulagern oder einige Projekte aufzuschieben, d. h., die Entscheidung würde komplett gegenteilig wie die ausfallen, die auf Basis einer Teilmenge der Daten getroffen worden wäre.

Das Problem besteht nicht im Entwurf des Dashboards, und es liegt auch nicht an der Qualität der Daten. In diesem Fall ist die mangelnde Vollständigkeit der Daten das Problem. Anhand dieses Beispiels sehen Sie das Problem mit eigenen Augen, aber stellen Sie sich eine Projektumgebung mit Hunderten oder gar Tausenden von Projekten oder Unterprojekten im gleichen Dataset vor.

Wird eine Entscheidung auf Basis einer Teilmenge der Daten getroffen, ergibt sich oft eine unsachgemäße Fehlentscheidung. Wird eine Entscheidung getroffen, bei der der Entscheidungsträger noch nicht einmal weiß, dass die Daten unvollständig sind, ist das bestenfalls eine Entmündigung.

Wir können dieses Problem mit einer Überprüfung der Daten in einer Art Genehmigungsverfahren oder vielleicht mit einer Kombination aus Überprüfung und datenbankbasiertem Indikator lösen, der anzeigt, dass wir derzeit nun eine Teilansicht unserer Daten anzeigen.

Mindesthaltbarkeitsdatum

Wenn es Ihnen wie mir geht, greifen Sie in den Kühlschrank und schnappen sich den Käse, den Sie als Erstes greifen können, aber sollte man nicht das "Mindesthaltbarkeitsdatum" überprüfen? Und wo wir uns schon mit dem Thema Quelldaten befassen, aus denen sich das wunderschöne Bild Ihres Dashboards zusammensetzt: Haben Sie eine Ahnung, wie alt die Daten sind, die hier dargestellt werden?

Es ist nicht ungewöhnlich, dass sich im Zuge eines Audits der Dashboarddaten herausstellt, dass die Daten schon ziemlich lange nicht mehr aktualisiert worden sind. Häufig ist es ein aufmerksamer Manager, der diesen Umstand in einer Revisionsbesprechung zu Sprache bringt. Das ist so ein Typ, der nicht nur seine Notizen von der letzten Besprechung mitbringt, sondern auch Kopien von allen Handzetteln gemacht hat, die beim letzten Mal ausgeteilt wurden, und sein erfahrendes Auge schweift über die alten Handzettel und die neuen Handzettel und vergleicht die Daten.

Identische Indikatoren bedeuten, dass sich entweder nichts geändert hat (in den meisten Projektumgebungen unwahrscheinlich), oder dass die Daten nicht aktualisiert worden sind (in vielen Organisation wesentlich wahrscheinlicher). Für Leute aus der Finanzabteilung, für die die Ergebnisse ihrer Tabellen häufig den Unterschied zwischen Leben und Sterben bedeuten, oder bei einer umfangreichen Tabellensammlung, die aus zahlreichen Nebenbüchern besteht, ist ein solcher Fehler nicht unüblich. Projektmanagern und Leuten, die sich die Projektdaten einfach nur anschauen, fallen solche Fehler nur auf, wenn sie dediziert danach suchen.

Gestapeltes Balkendiagramm mit angezeigten Kosteninformationen für ein Jahr für verschiedene Abteilungen

Im schlechtesten Fall wurden einige Daten aktualisiert und sind auf dem neuesten Stand, wohingegen andere Daten überhaupt nicht aktualisiert wurden. So wurde der Prospektivplan vielleicht für die Hälfte der Projekte aktualisiert, und die Ist-Werte der letzten Periode wurden für die Projekte veröffentlicht, aber für die andere Hälfte der Projekte gibt es weder veröffentlichte Ist-Werte, noch wurde der Plan aktualisiert. Wenn Entscheidungen auf Basis der Dashboardansicht oder der zugrunde liegenden Daten getroffen werden sollen, sollte irgendwo angegeben werden, wie aktuell die Daten sind.

Diese Art von Problem kann auch mit ein paar grundlegenden Kontrollmechanismen gelöst werden, die auf dem Dashboard angezeigt werden. So können Sie mit einem einfachen Test beispielsweise Folgendes sicherstellen:

  1. Alle Arbeitszeittabellen wurden für die angezeigte Periode gesammelt, und

  2. die Gesamtstundenanzahl aus den Arbeitszeittabellen entspricht im Wesentlichen der angezeigten Anzahl Gesamtstunden.

Datenherkunft

Je schöner die Anzeige ist, desto unwahrscheinlicher ist es, dass wir fragen: "Wo kommen die Daten her und wie zuverlässig sind sie?" Das hat etwas mit der Ordentlichkeit zu tun, die zählt, wenn wir Daten in einer professionell aussehenden grafischen Anzeige darstellen. Diejenigen, die Daten aus einer Datenbank extrahieren, haben häufig eine gewisse Distanz zu dem Ort, von dem die Daten stammen. Ein Grafikdesigner finden ein paar nützlich aussehende Felder und Möglichkeiten, hieraus Indikatoren zu berechnen. Er muss sich nicht fragen, ob diese Felder über ein genehmigtes Verfahren gefüllt werden, ob es bei der Berechnung eine Art Aufsicht gibt oder ob die Daten von den Personen, die sie eingeben, als "nicht der Unternehmensqualität entsprechend" angesehen werden.

Möglicherweise arbeiten wir an einem Softwareentwicklungsprojekt und einer Liste offenstehender und neu hinzugefügter Softwarebugs, und es gibt eine lange SharePoint-Liste mit Problemen, die von der Qualitätssicherung erstellt wurde, da der Veröffentlichungstermin der Software näher rückt. Diese Art Liste kann ein wichtiger Indikator dafür sein, inwieweit die Software bereit für die Veröffentlichung ist. Wenn die gleiche Liste jedoch von vielen unterschiedlichen Gruppen verwendet wurde, um Ideen für neue Funktionen und Erweiterungsanfragen zu erhalten, entsteht durch die einfache Zählung der Probleme ein ungeeigneter Indikator, da die Liste mit Daten "vermüllt" wurde, die für einen anderen Zweck verwendet wurden.

Daten, die in einem Indikator in einem Dashboard angezeigt werden, müssen einen bestimmten Prozess und eine Qualitätsprüfung durchlaufen.

Sehen wir das gesamte Bild?

Lassen Sie uns noch einmal auf die Ampelanzeige im Dashboard zurückkommen, und schauen wir uns noch einmal die Zeile "IT" an.

Projektmetriken (Kosten, Status, Qualität, Ressource und Zeitplan) für IT-Abteilung

Stellen wir uns vor, bei "IT" gibt es rote Leuchten für die Indikatoren "Zeitplan" und "Kosten" für ein spezielles, schon mehrere Jahre laufendes Projekt, denn es ist Juni, und beide Indikatoren zeigen, dass es eine negative Abweichung von mehr als 20 % gibt.

Der Leiter der Finanzabteilung hat sich die detaillierten Ergebnisse bereits angesehen, und er ist ziemlich verärgert. Die Ist-Werte Januar-Juni zeigen, worum es geht:

(In 1.000 €)

Jan

Feb

März

April

Mai

Juni

Budget

80

100

120

120

120

120

Ist

100

120

140

140

140

140

Abweichung

20

20

20

20

20

20

Kumulierte Abweichung

20

40

60

80

100

120

Bis jetzt ist das Projekt schon 120.000 € über Budget, und es ist erst zur Hälfte abgeschlossen! Bei diesem Tempo, so der Leiter der Finanzabteilung, kostet das Projekt 18 % mehr als das ursprüngliche Budget von 1,3 Mio. €, und vielleicht könne man die Verluste minimieren und das Projekt einstellen.

Wenn wir uns das Projekt jedoch im Detail betrachten, sieht das Bild ganz anders aus. Der prognostizierte Zeitplan und die Kosten bis zum Ende des Projekts sehen folgendermaßen aus:

(In 1000 €)

Jan

Feb

März

April

Mai

Juni

Juli

Aug

Sep

Okt

Nov

Dez

SUMME

Budget

80

100

120

120

120

120

120

120

120

120

100

80

1.320

Ist

100

120

140

140

140

140

120

100

80

40

0

0

1.120

Abweichung

20

20

20

20

20

20

0

(20)

(40)

(80)

(100)

(80)

(200)

Kumulierte Abweichung

20

40

60

80

100

120

120

100

60

(20)

(120)

(200)

Damit sehen wir das Gesamtbild. Das Projekt läuft schneller als erwartet. Tatsächlich wird es schon Mitte Oktober anstatt im Dezember abgeschlossen, und es wird 200.000 € weniger kosten als im Budget vorgesehen.

Das ist das Problem mit einfachen Dashboards und deren Interpretation. Das Dashboard an sich war vollkommen korrekt, aber der Grund, warum "Rot" angezeigt wurde, war ein positiver und kein negativer.

Dashboardindikatoren müssen Manager warnen, dass Maßnahmen ergriffen werden müssen und wo sie nachschauen sollen, sie sollten den Manager jedoch auch mit detaillierteren Daten versorgen, die das Gesamtbild zeigen.

Spieler im Überfluss

So, nun wissen Sie ansatzweise, was Sie tun können um sicherzustellen, dass das Management aufgrund Ihrer Dashboards keine übereilten Entscheidungen trifft, und das ist schon mal ein großer Schritt. Sie sollten sich jedoch der Tatsache bewusst sein, dass dashboardartige Anzeigen, sobald sie verfügbar sind, Leute dazu verleiten werden, sie zu ihrem eigenen Vorteil zu nutzen. Es ist vollkommen verständlich, dass Leute, sofern möglich, den Prozess unterlaufen, indem sie die von ihnen kontrollierten Daten verfälschen, damit sie nicht allzu schlecht aussehen.

Sie können nicht verhindern, dass Leute diesen Versuch unternehmen, es gibt jedoch einige Techniken, mit denen Sie ihnen das Handwerk legen können.

Ändern Sie den Prozess

Sie können es schwierig gestalten, den Prozess zu unterlaufen, indem Sie ihn immer wieder ändern; versuchen Sie, denjenigen immer einen Schritt voraus zu sein, die meinen, sie hätten den Prozess durchschaut. Jeder, der sich mit Suchmaschinen und der Optimierung von Suchmaschinen auskennt, kennt den Trick, aber die Herausforderung besteht in dem enormen Arbeitsaufwand, den es bedeutet, den Prozess immer wieder zu ändern und alle im Hinblick auf die Änderungen zu schulen.

Kein Zuckerbrot, nur Peitsche

Eine weitere Option besteht darin, diejenigen zu disziplinieren, die Sie erwischt haben. Das ist natürlich eine harte Nuss. Leute, die rundheraus lügen, wenn es um ihre Daten geht, sollten natürlich die Konsequenzen tragen, aber diejenigen zu bestrafen, die einfach nur eine Lücke im Prozess gefunden haben, ist normalerweise schlecht für die Motivation.

Gegenseitige Kontrolle

Dies ist in der Regel das beste Werkzeug gegen Spielernaturen. Wenn Sie Daten aus unterschiedlichen Quellen haben, die mit anderen Daten abgeglichen werden müssen, wird es für andere Personen außerordentlich schwierig, nur die von ihnen kontrollierten Daten zu ändern und das Dashboard zu ihren Gunsten zu manipulieren. Natürlich ist es nicht immer möglich, solche Möglichkeiten zur gegenseitigen Kontrolle in den Daten zu finden, daher ist Vorsicht immer besser als Nachsicht.

Einige Grundregeln

Lassen Sie uns das vorstehend Gesagte kurz zusammenfassen. Die Erstellung von leistungsfähig aussehenden Dashboards ist technisch gesehen nicht schwierig, es gibt jedoch einige Grundregeln, die Sie in den Dashboardentwurf und den Projektmanagementprozess einbringen können, um sicherzustellen, dass die Entscheidungen, die auf Basis dieser Dashboards getroffen werden, fundiert und effektiv sind.

Hier eine Zusammenfassung der grundlegenden Konzepte, die vorstehend besprochen wurden:

Indikatoren müssen sich auf die Quelldaten zurückverfolgen lassen

Stellen Sie sicher, dass es sich bei den Indikatoren nicht nur um manuell eingegebene Optionen oder die "Gefühle" einer Person handelt, sondern dass sie tatsächlich für etwas Reales in den Detaildaten Ihrer Umgebung stehen.

Für jeden Indikator muss es eine Aktion geben

Für jeden Indikator muss es eine Aktion geben, für wirklich jeden! Ganz gleich, um welche Aktion es sich handelt, es muss eine geben. Das trägt wahrscheinlich auch dazu bei, die Anzahl der Indikatoren auf einen angemessenen Umfang zu beschränken.

Die Daten müssen vollständig sein, oder das Gegenteil muss angeben werden

Stellen Sie sicher, dass schon in der Anzeige eindeutig angegeben wird, ob die Daten vollständig oder unvollständig sind, um so unsachgemäße Entscheidungen zu verhindern, die aufgrund eines unvollständigen Bilds getroffen werden.

Die Anzeige muss Hinweise auf ihre Aktualität enthalten

Wenn es möglich ist, einige Daten zu aktualisieren und andere nicht, muss das Aktualisierungsdatum der Daten im Dashboard in einer Weise angezeigt werden, die unsachgemäße Entscheidungen basierend auf alten oder einer Kombination aus alten und neuen Daten verhindert.

Überprüfen Sie fortlaufend die Datenqualität

Dashboards sollten einer regelmäßigen Überprüfung der Daten unterzogen werden, aus denen sich die Indikatoren zusammensetzen, und es sollten regelmäßige Updates erfolgen, um zu verhindern, dass Leute den Entscheidungsfindungsprozess verfälschen. Einige Organisation implementieren einen regelmäßigen Auditprozess, bei dem die wichtigsten Indikatoren überprüft und die Daten vom Ergebnis auf die Quelldaten zurückverfolgt werden und bei dem die Formeln und die Datenqualität überprüft werden, um sicherzustellen, dass nicht geändert wurde. Das können Sie natürlich nicht immer tun, aber eine regelmäßige Überprüfung dessen, was diese netten Ampeln dazu bringt, in Grün, Rot oder Gelb zu leuchten, ist sicherlich ratsam.

Viel Spaß mit Ihren Dashboards!

Referenzmaterial

Wenn Sie mehr über die Erstellung von Dashboards mit Microsoft Project Server wissen möchten, empfehle ich Ihnen, einige der großartigen Artikel in TechNet zu lesen:

Informationen zum Autor

Chris Vandersluis ist der Präsident und Gründer von HMS Software, einem im kanadischen Montreal ansässigen Microsoft Certified Partner. Er hat einen Abschluss in Wirtschaftswissenschaften von der McGill University und mehr als 30 Jahre Erfahrung in der Automatisierung von Projektsteuerungssystemen. Er ist ein langjähriges Mitglied des PMI (Project Management Institute) und hat geholfen, die Ortsverbände der Microsoft Project-Benutzergruppen (MPUG) in Montreal, Toronto und Quebec zu gründen.   Vandersluis hat Beiträge in Fortune, Heavy Construction News, im Magazin "Computing Canada" und im PMNetwork von PMI veröffentlicht. Darüber hinaus verfasst er regelmäßig die Leitartikel für Project Times. Er unterrichtet Projektmanagement für Fortgeschrittene an der McGill University und hält häufig Vorträge auf Veranstaltungen der Project Management Association in Nordamerika und weltweit. HMS Software ist der Herausgeber von TimeControl, einem projektorientierten Zeiterfassungssystem, und seit 1995 ein Microsoft Project Solution Partner.

Sie können Chris Vandersluis per E-Mail kontaktieren: chris.vandersluis@hms.ca

Wenn Sie weitere EPM-bezogene Artikel von Chris Vandersluis lesen möchten, besuchen Sie die EPM Guidance-Website von HMS (http://www.epmguidance.com/?page_id=39).

Teilen Facebook Facebook Twitter Twitter E-Mail E-Mail

War diese Information hilfreich?

Sehr gut. Noch anderes Feedback?

Was können wir verbessern?

Vielen Dank für Ihr Feedback!

×