Share via


Indicazioni per la dashboard

Questo articolo fa parte della nostra raccolta "From the Trenches". Descrive alcune delle sfide comuni che possono verificarsi quando si decide di usare i dashboard nell'ambiente EPM. In particolare, viene spiegato che un dashboard curato e dall'aspetto professionale non sia necessariamente sinonimo di qualità dei dati per gli utenti e che pertanto i dati visualizzati non siano sempre aggiornati e completi. Viene quindi illustrato il processo di approvazione dei dati destinati ai dashboard per garantirne una maggiore qualità e completezza. Sono inoltre descritte alcune tecniche per impedire agli utenti di alterare i dati sotto il proprio controllo per distorcere quelli visualizzati nel dashboard. Vengono infine suggerite alcune regole di base da tenere in considerazione durante la creazione di dashboard per EPM.

Per scaricare la versione di Word di questo articolo, vedere Indicazioni del dashboard.

Per altri articoli, vedere white paper "From the Trenches".

Indicazioni per la dashboard

Non c'è dubbio. I dashboard sono di gran moda. Che si tratti di un grafico a barre, un istogramma, un grafico a torta o una visualizzazione di avviso semaforico, i dirigenti sembrano dipendenti dalla risposta immediata di un dashboard.

Sito del Centro business intelligence in SharePoint Server 2010.

Con una pressione sempre maggiore nella nostra cultura aziendale per ottenere risultati più veloci e veloci, è probabile che la domanda di dashboard non diminuisca presto.

Il settore del software di gestione dei progetti è un poster figlio per questo tipo di visualizzazione perché i dati di gestione dei progetti sono perfetti per la dashboarding. Quando si esamina il tipo di dati necessari per i dashboard, vengono esaminate diverse qualità:

  • È raggruppato in modi che possono essere visualizzati e compresi?

  • È tempestivo?

  • Esiste un processo di approvazione o controllo per i dati?

  • Sono disponibili dati numerici o di ora/data che possono contribuire a creare scostamenti?

Questo è esattamente ciò che si trova nei dati di gestione dei progetti da un sistema Di gestione di progetti aziendali (EPM) come Microsoft Project Server.

Non sorprende quindi che la maggior parte dei sistemi EPM, tra cui Project Server, disponga di alcune funzionalità di dashboard. Nel caso di Microsoft, le funzionalità sono disponibili per gentile concessione di SharePoint Server nel Centro business intelligence. Questo tipo di sistema può esaminare i dati basati su SQL e generare una gamma incredibilmente ampia di schermi grafici. E, proprio come un gattino, non c'è niente che un dirigente ami meglio di un nuovo giocattolo lucente. Il desiderio da parte del senior management di un feedback immediato dai progetti può essere così grave che molti uffici di gestione dei progetti sono pressati a fornire la visualizzazione prima ancora che i dati sottostanti siano pronti.

"È possibile creare un dashboard EPM?" Una volta mi è stato chiesto da un dirigente IT senior mentre ero nei loro uffici per aiutare a progettare il loro ambiente EPM.

"Certo," risposi.

"Potremmo averlo entro venerdì?"

"Um, certo," rispondo. "Beh, non questo venerdì. Ma un venerdì in futuro.

Non era affatto divertito dal mio umorismo.

Non era un manager inintelligente, ma è alla base della pressione che tali persone sperimentano per consentire un processo decisionale rapido.

I dashboard sono così visivamente stimolanti, spesso dimentichiamo che dovrebbero rappresentare qualcosa che genera lo schermo. Quindi, prima di esaurirsi per scoprire come creare un dashboard e prima di iniziare a dedicare troppo tempo a scegliere tavolozze di colori di quale colore dovrebbero essere le icone, esaminiamo alcune sfide comuni nell'arena del dashboard.

Sindrome del Mago di Oz

Ricordate il Mago di Oz quando finalmente tirato indietro la tenda e trovato solo un ragazzo normale che stava tirando le leve e girando i quadranti per generare tutta l'impressionante "magia"?

Reporting Services scorecard che mostra lo stato del progetto.

I bellissimi display guidati dall'intervento umano sono sempre visualizzati nei dashboard. Una grande quantità di lavoro va nel design e presentazione, tra cui grande grafica, grandi icone, grandi colori e anche animazione ed effetti sonori. Il problema è che nessuno ha tracciato un percorso tra i dati e il dashboard e il risultato è che qualcuno deve sedersi a una scrivania e decidere manualmente quale indicatore fare quale colore.

Quando si esamina un dashboard esistente per la prima volta, vale sempre la pena chiedere di visualizzare i dati non elaborati che hanno costituito la visualizzazione. "Che cosa significa questo e puoi mostrarmi da dove viene determinato questo indicatore?" è una domanda chiave. Eseguire un mini-controllo di alcuni indicatori, tenendoli traccia dei dati dei componenti.

Lo stesso principio vale se si progetta un dashboard. Per ogni indicatore, deve essere presente un percorso di ritorno a un'origine ed è meglio se documentato. Se il dashboard è guidato da Bob che compila un foglio di calcolo con il modo in cui si sente sui progetti, è sufficiente che te lo dica. Sarà più veloce.

Misurare tutto

"Se è possibile misurarlo, lo si inserirà nel dashboard", sembra essere il mantra di alcuni progettisti di dashboard.

Scorecard che mostra lo stato per diversi progetti.

È facile rimanere coinvolti nella tecnologia del dashboarding e c'è un certo brivido viscerale quando si individuano alcuni dati che sembrano misurabili e comprensibili e si crea un indicatore da esso. Improvvisamente invece di una vecchia lista di costi noiosi, hai termometri che si riempiono di rosso o tachometer che si revving nella zona rossa o frecce in colori diversi. Non pensi che sia divertente? Provare in Excel per mezz'ora usando la nuova funzionalità Formattazione condizionale di Excel 2010 (o Excel 2013).

I problemi si verificano quando qualcuno che sta creando un dashboard esecutivo viene così coinvolto nella loro capacità di fare un indicatore che non si fermano a guardare e vedere se dovrebbero farlo a tutti. Non è sempre "come lo fai?"; a volte è "dovresti farlo?"

Una volta che ci sono così tanti indicatori visivamente stimolanti nella pagina che sembra il dashboard dello space shuttle, sai che avrai bisogno di anni di formazione come un astronauta o dovrai rendere la vita più semplice.

Ecco una regola di base che dovrebbe consentire un minor numero di visualizzazioni: ogni indicatore richiede un'azione potenziale; ognuno. Quindi, se si dispone di un indicatore di semaforo ed è rosso, allora ci deve essere un'azione appropriata che qualcuno dovrebbe prendere quando ciò accade. Potrebbe essere un semplice "Quando questa luce diventa rossa, un project manager deve mostrare un report dettagliato all'head dell'oggetto PMO". Indipendentemente da ciò che l'azione è, ci deve essere uno.

Piani a metà cottura

Non si mangia una torta che aveva solo metà degli ingredienti, soprattutto se non si sapeva quale metà erano mancanti. In un dashboard, come si sa di avere tutti i dati?

Indicatori di stato per diverse metriche del progetto (Costo, Integrità, Qualità, Risorsa e Pianificazione).

Si osserverà ora un esempio di creazione di report sulla capacità delle risorse. Il semaforo delle risorse è diventato rosso per l'IT (non è sempre così?) Ora la direzione vuole esaminare il problema e quando esaminano i dettagli, vedono la risposta ovvia. L'indicatore deve essere rosso perché è così sovraccarico di personale!

Istogramma che mostra i progetti rispetto alla capacità organizzativa.

Questo primo istogramma mostra il problema. La linea rossa mostra la capacità dell'organizzazione. Gli istogrammi in pila mostrano i requisiti combinati previsti aggiungendo i requisiti di tutti i progetti insieme. Se questo è il dashboard che presentiamo alla gestione, la decisione di accettare molto più lavoro o di ridurre immediatamente i livelli di personale sarebbe ovvia.

Ah, ma aspetta un attimo. Poco prima dell'entrata in vigore del piano di riduzione dei livelli di personale, si verifica che qualcuno verifichi se tutti i progetti sono stati rappresentati nella visualizzazione dashboard.

Istogramma modificato che mostra lo stato del progetto con la riduzione del personale presa in considerazione.

Non lo erano.

Alcuni progetti sono stati visualizzati nella legenda, ma non sono stati visualizzati risultati per questi progetti nell'istogramma. Dove sono stati i risultati? Forse questi progetti non sono stati ancora pubblicati. Forse l'ambito completo del progetto era ancora in fase di definizione. È possibile che i requisiti delle risorse non siano stati definiti al livello appropriato. Quando i dati vengono rivisti, si può notare nel secondo istogramma che in realtà ora c'è più lavoro delle persone e dovremmo prendere in considerazione l'assunzione di più personale, l'aggiunta di una certa capacità contrattuale o il ritardo di alcuni progetti in futuro; l'esatta decisione opposta che avremmo preso esaminando la stessa vista con solo una parte dei dati.

Il problema non è la progettazione del dashboard; né la qualità dei dati. È la completezza dei dati che rappresenta il problema. In questo esempio ovvio, è possibile vedere il problema con il proprio occhio, ma si immagini un ambiente di progetto con centinaia o addirittura migliaia di progetti o sottoprogetti nello stesso set di dati.

Prendere una decisione con solo una parte dei dati spesso comporterà una decisione inappropriata. Prendere una decisione in cui il decision maker non sa nemmeno che i dati sono incompleti è, nella migliore delle ipotesi, sconvolgente per loro.

È possibile risolvere questo problema con una revisione dei dati in un qualche tipo di processo di approvazione o, forse, con la combinazione di un processo di convalida e un indicatore basato su database che indica che stiamo esaminando solo un'immagine parziale dell'indicatore.

Migliore prima delle date

Se sei come me raggiungi il frigorifero e prendi il formaggio più vicino a te, ma non dovresti controllare le date "migliori prima"? Anche se siamo sull'argomento dei dati di origine che hanno costituito quella bella immagine nel dashboard, si ha qualche idea di quanto vecchi siano i dati che generano tale indicatore?

Non è raro eseguire un controllo di un indicatore del dashboard solo per scoprire che i dati che hanno origine l'indicatore non sono stati aggiornati da molto tempo. E 'spesso un dirigente forte che raccoglie questo in una riunione di revisione. Questo è il tipo di persona che porta non solo le note dell'ultima riunione di revisione, ma anche copie di tutti gli stampati che sono stati dati l'ultima volta e il loro occhio praticato guarda gli ultimi stampati e i nuovi stampati e confronta i dati.

Gli indicatori identici indicano che le cose non sono cambiate (improbabile nella maggior parte degli ambienti di progetto) o che i dati non sono stati aggiornati (molto più probabilmente in molte organizzazioni). Per coloro che in Finance spesso vivono e muoiono dai risultati del loro foglio di calcolo, o da una massiccia farm di fogli di calcolo costituita da molti libri contabili secondari, questo è un errore comune. I project manager e coloro che esaminano i dati del progetto potrebbero avere meno probabilità di rilevare tali errori senza prestare attenzione.

Grafico a barre in pila che mostra le informazioni sui costi per un anno su reparti diversi.

Lo scenario peggiore è quello in cui alcuni dati sono stati aggiornati ed è corrente e alcuni dati non sono stati aggiornati affatto. Quindi, forse il piano a termine è stato aggiornato sulla metà dei progetti e i valori effettivi per l'ultimo periodo sono stati registrati a tali progetti, ma l'altra metà dei progetti non ha registrato effettivi o il loro piano aggiornato. Se verranno prese decisioni sulla visualizzazione dashboard o sui dati risultanti da cui provengono, in che modo i dati correnti devono essere visualizzati in un punto qualsiasi.

Questo tipo di problema può anche essere risolto con alcuni controlli e saldi di base nei dati che possono quindi essere visualizzati nel dashboard. Ad esempio, un semplice test potrebbe garantire che:

  1. Tutte le schede attività sono state raccolte per il periodo visualizzato; E

  2. le ore totali della scheda attività raccolte sono approssimativamente equivalenti alle ore totali visualizzate.

Pedigree dati

Più bello è il display, meno è probabile che ci si chieda: "Da dove provengono i dati e da quanto sono affidabili?" C'è qualcosa di pulito che conta quando inseriamo i dati in un display grafico professionale. Per coloro che creano dati da un database, spesso possono essere conservati a una distanza da dove sono arrivati i dati. Un progettista grafico trova un paio di campi utili e modi per calcolare gli indicatori da essi e può facilmente trascurare di chiedere se questi campi sono popolati tramite un processo convalidato, con qualsiasi tipo di supervisione, per calcolo o se i dati non sono considerati "qualità aziendale" dalle persone che vi entrano.

Forse stiamo lavorando a un progetto di sviluppo software e a un elenco di problemi software in sospeso e appena aggiunti e c'è un ottimo elenco di problemi di SharePoint che vengono creati dal reparto di controllo di qualità come parte del software vicino a una data di rilascio. Questo tipo di elenco può essere un indicatore chiave di quanto sia pronto il software per il rilascio. Se, tuttavia, molti gruppi diversi usano lo stesso elenco per nuove idee di funzionalità e richieste di miglioramento, il solo conteggio dell'elenco di problemi fornirà un indicatore inappropriato perché l'elenco è diventato inquinato con i dati usati per uno scopo diverso.

I dati che verranno visualizzati su un indicatore in un dashboard devono avere un processo e una convalida della qualità.

Stiamo guardando l'intero quadro?

Tornare al report sul semaforo del dashboard e esaminare di nuovo la riga IT.

Metriche del progetto (costo, integrità, qualità, risorsa e pianificazione) per il reparto IT.

Si supponga che l'IT abbia luci rosse sia per la pianificazione che per gli indicatori di costo in un determinato progetto di un anno perché è giugno ed entrambi gli indicatori sono spenti di oltre il 20%!

Il Chief Financial Officer ha già esaminato i risultati dettagliati ed è abbastanza turbato. I dati effettivi di gennaio -giugno mostrano il racconto:

($,000s) Gennaio Febbraio Mar Apr Maggio Giu
Bilancio
80
100
120
120
120
120
Attuale
100
120
140
140
140
140
Varianza
20
20
20
20
20
20
Varianza cumulativa
20
40
60
80
100
120

Finora il progetto è già $120,000 oltre budget ed è solo mezzo over! A questo ritmo, afferma il CFO, il progetto costerà il 18% in più rispetto al budget originale di 1,3 milioni di dollari e forse dovrebbe tagliare le perdite e annullare il progetto.

Se si esaminano in modo più dettagliato, tuttavia, l'immagine è molto diversa. I costi pianificati e fino alla fine del progetto sono simili ai seguenti:

(,000s) Gennaio Febbraio Mar Apr Maggio Giu Lug Agosto Set Ottobre Novembre Dicembre Totale
Bilancio
80
100
120
120
120
120
120
120
120
120
100
80
1,320
Attuale
100
120
140
140
140
140
120
100
80
40
0
0
1,120
Varianza
20
20
20
20
20
20
0
(20)
(40)
(80)
(100)
(80)
(200)
Varianza cumulativa
20
40
60
80
100
120
120
100
60
(20)
(120)
(200)

Ora possiamo vedere di più della storia. Il progetto è in esecuzione più velocemente del previsto. Infatti, finirà a metà ottobre invece che a dicembre e si prevede di finire $200.000 sotto budget.

Questa è la sfida con dashboard semplici e come vengono interpretati. Il dashboard era completamente accurato, ma il motivo per cui era rosso era buono, non male.

Gli indicatori del dashboard devono avvisare i dirigenti che è necessario intraprendere un'azione e dove cercare, ma devono anche portare lo stesso dirigente ai dati più dettagliati che mostreranno l'intero quadro.

Giocatori a bizzeffe

Ok, quindi ora è possibile eseguire alcune operazioni per assicurarsi che i dashboard non ingannino la gestione a decisioni inappropriate, e questo è un passaggio enorme. Ma, si consiglia, non appena vengono resi disponibili indicatori di tipo dashboard, gli utenti li useranno a proprio vantaggio. È del tutto comprensibile che le persone giochino il processo se possono sfasando i dati sotto il loro controllo per non sembrare male.

Non è possibile impedire alle persone di provare a giocare al processo, ma esistono alcune tecniche per evitare gli eventi di questi giocatori:

Modificare il processo

È possibile rendere difficile giocare il processo modificandolo tutto il tempo; cercando di stare davanti a coloro che pensano di avere il processo capito. Tutti nel settore dei motori di ricerca di Ottimizzazione motore di ricerca conoscono questo, ma la sfida con questo è l'enorme quantità di lavoro che ci vuole per continuare a cambiare il processo e formare tutti nei cambiamenti.

Nessuna carota, solo bastone

Un'altra opzione è disciplinare coloro che hanno catturato il gioco il processo. Questa è una cosa difficile. Persone che mentono a titolo definitivo sui loro dati dovrebbe mettersi nei guai, ma punire coloro che stanno solo trovando scappatoie nel processo è in genere un male per il morale.

Controlli e saldi

Questo è in genere lo strumento più potente contro i giocatori. Se si dispone di dati provenienti da origini diverse che devono essere bilanciati con altri dati, diventa estremamente difficile per qualcuno manipolare solo i dati sotto il proprio controllo e sconfiggere il processo del dashboard a loro favore. Naturalmente non è sempre possibile trovare tali controlli e saldi all'interno dei dati, quindi la vigilanza è sempre una buona cosa.

Alcune regole di base

Ok, facciamo un riepilogo di quello che abbiamo detto. La creazione di dashboard dall'aspetto avanzato non è tecnicamente difficile, ma esistono alcune regole di base che è possibile implementare nel processo di progettazione e gestione dei progetti del dashboard che possono garantire che le decisioni che derivano da tali dashboard siano appropriate ed efficaci.

Ecco un riepilogo di alcuni dei concetti di base illustrati in precedenza:

Gli indicatori devono risalire ai dati di origine

Assicurarsi che gli indicatori non siano solo le opinioni immesse manualmente o i sentimenti di qualcuno, ma che rappresentino effettivamente qualcosa nei dati dettagliati dell'ambiente.

Ogni indicatore necessita di un'azione

Ogni indicatore ha bisogno di un'azione; ognuno. Indipendentemente da ciò che l'azione è, ci deve essere uno. Questo probabilmente aiuterà anche a mantenere il numero di indicatori a un livello ragionevole.

I dati devono essere completi o indicare che non sono

Assicurarsi che dalla visualizzazione sia chiaro che i dati sono completi o incompleti in modo che non vengano prese decisioni inappropriate mentre si esamina solo un'immagine parziale.

La visualizzazione deve mostrare le sequenze temporali

Se è possibile aggiornare alcuni dati e altri dati no, la data di aggiornamento dei dati deve essere visualizzata nel dashboard in modo da evitare decisioni inappropriate basate su dati obsoleti o su una combinazione di dati vecchi e nuovi.

Controllare la qualità dei dati in modo continuativo

Un dashboard deve avere revisioni regolari dei dati che guidano gli indicatori e gli aggiornamenti regolari per evitare che le persone giochino al processo decisionale. Alcune organizzazioni implementeranno un normale processo di controllo che esamina gli indicatori chiave e ripercorre i risultati ai dati di origine, controllando le formule e la qualità dei dati per assicurarsi che non siano cambiati. Non puoi farlo tutto il tempo, naturalmente, ma una revisione regolare di ciò che fa diventare quei semafori piuttosto verdi, rossi o gialli è un'idea sana.

Buon dashboarding!

Riferimenti

Per altre informazioni su come eseguire i dashboard con Microsoft Project Server, è consigliabile leggere alcuni ottimi articoli su TechNet:

Informazioni sull'autore

Chris Vandersluis è il presidente e fondatore di Montreal, HMS Software, un partner microsoft certificato. Ha una laurea in economia presso la McGill University e oltre 30 anni di esperienza nell'automazione dei sistemi di controllo del progetto. È un membro di lunga data del Project Management Institute (PMI) e ha contribuito a fondare i capitoli di Montreal, Toronto e Quebec del Microsoft Project Users Group (MPUG). Le pubblicazioni per le quali Chris ha scritto includono Fortune, Heavy Construction News, computing Canada magazine, e PMNetwork di PMI, ed è un giornalista regolare per Project Times. Insegna Advanced Project Management alla McGill University e spesso parla alle funzioni dell'associazione di gestione dei progetti in America del Nord e in tutto il mondo. HMS Software è l'editore del sistema timekeeping orientato al progetto TimeControl ed è partner di Microsoft Project Solution dal 1995.

Chris Vandersluis può essere contattato via e-mail all'indirizzo: chris.vandersluis@hms.ca

Per altre informazioni sugli articoli correlati a EPM di Chris Vandersluis, vedere il sito guida EPM di HMS (https://www.epmguidance.com/?page_id=39).