儀表板說明
本文是「從馬西斯」集合的一部分。 其中描述您在決定在 EPM 環境中使用儀表板時可能會面臨的一些常見挑戰。 其中描述專業型式儀表板的美觀性有時可能會隱藏使用者查看資料品質的需求 ,例如「pedigree」和更新的資料。 其中提到儀表板的資料應該如何經過核准程式,以確保高資料品質和完整性。 它包含一些技術,可防止人員在其控制下扭曲資料,以誤報儀表板中顯示的資料。 最後,它會說明您在建立 EPM 儀表板時應考慮的一些基本規則。
若要下載本文的 Word 版本,請參閱 儀表板指示。
若要查看更多文章,請參閱 白皮書。
儀表板說明
這是無可置疑的。 儀表板全都是一大事。 無論是橫條圖、長條圖、圓形圖或交通燈警告檢視,主管似乎都對儀表板的立即回應做出回應。
隨著我們商務文化中愈來愈大的壓力,以提供更快且更快的結果,儀表板的需求可能不會很快地減去。
專案管理軟體產業是這種顯示的海報子系,因為專案管理資料非常適合儀表板。 當我們查看儀表板所需的資料類型時,我們會查看數個品質:
它是否以顯示和瞭解的方式群組在一起?
是否及時?
資料是否有一些核准或審查程式?
是否有可協助變異的數值或時間/日期資料?
這正是我們從 Microsoft Project Server 等企業專案管理 (EPM) 系統中找到的專案管理資料。
因此,包括 Project Server 在內的大部分 EPM 系統都有一些儀表板功能,這並不令人意外。 就 Microsoft 而言,這些功能是由商業智慧中心的 SharePoint Server 所提供。 這種類型的系統可以查看 SQL 型資料,並產生非常廣泛的圖形顯示器。 而且,就像小貓一樣,執行人員最喜歡的新玩具也一樣。 資深管理人員對專案立即回饋的需求可能非常嚴重,因此許多專案管理辦公室在基礎資料準備就緒之前,都需要提供顯示器的壓力。
「您可以讓我們成為 EPM 儀表板嗎?」我在辦公室協助設計其 EPM 環境時,曾由資深 IT 主管詢問我。
「確定」,我回復了。
「我們可以在星期五前擁有它嗎?」執行人員對我的意外詢問。
「Um, sure,」我回答。 「不是這個星期五。 但未來的某個星期五。」
他完全沒被我的風雲所逗樂。
這不是不合意的管理員,但卻是這類人員在進行快速決策時所承受的壓力。
儀表板在視覺上非常美化,我們經常會忘記它們應該代表產生顯示的內容。 因此,在用完以瞭解如何製作儀表板之前,以及在您開始花太多時間挑選圖示色彩的調色盤之前,讓我們先在儀表板領域中經歷一些常見的挑戰。
馬西拉的精靈
記得當小馬精靈最後拉回幕布,並只發現一般人正在拉杆並轉動撥號以產生所有令人歎目提示的「魔術」嗎?
我們一直都在儀表板中看到由人為介入所驅動的美觀顯示。 設計和簡報中會進行大量的工作,包括絕佳的圖形、絕佳的圖示、絕佳色彩,甚至是動畫和音效。 問題在於沒有人在資料與儀表板之間追蹤路徑,而結果是有人必須坐在桌面上,並手動決定要建立哪一種色彩的指標。
第一次查看現有的儀表板時,一律值得要求查看構成顯示的原始資料。 「這代表什麼意思,而且您可以向我顯示此指標的驅動來源?」是一個重要問題。 執行一些指標的迷你稽核,並將其追蹤回其元件資料。
如果您要設計儀表板,則會保留相同的原則。 針對每個指標,必須有一個回溯到某些來源的線索,而且最好是記錄在內。 如果儀表板是由 Bob 在試算表中填入有關專案的感受,只要他告訴您。 速度會更快。
測量所有專案
「如果我們可以測量它,我們會將它放在儀表板上」,似乎是一些儀表板設計工具的語法。
很容易就能掌握儀表板技術,而且當您找到一些看似可測量且可理解的資料,並從中找出指標時,會有某些視覺效果。 突然地,您已將溫度計填滿紅色或 Tachometer,反而以不同色彩反轉到紅色區域或箭號,而不是舊成本清單。 不覺得這很有趣嗎? 使用 Excel 2010 (或 Excel 2013) 的新條件式格式設定功能,在 Excel 中試用半小時。
當製作主管儀表板的人員因其能力而無法停止查看,並查看是否應進行此作業時,就會發生問題。 這不一定是「您該怎麼做?」;有時候會是「您應該這麼做嗎?」
一旦頁面上出現許多視覺效果的指標,看起來就像是太空飛行的儀表板,您就知道您需要像太空人一樣進行數年的定型,或是需要讓生活更簡單。
以下是應該讓顯示器較少的基本規則:每個指標都需要可能的動作;每一個。 因此,如果您有交通燈指示器,且其為紅色,則需要有人在發生這種情況時採取適當的動作。 這可能是簡單的「當此光線變成紅色時,專案經理必須向 PMO 的標頭顯示詳細報告」。不論動作是什麼,都必須有一個。
半生方案
您不會吃只有一半食材的巧克力,特別是當您不知道哪一半遺失時。 在儀表板上,您如何知道您擁有所有資料?
讓我們來看看資源容量報告的範例。 IT 的資源流量燈已變成紅色 (並非總是這樣?) 現在管理想要查看問題,當他們查看詳細資料時,就會看到明顯的答案。 指標必須是紅色,因為 IT 人員太多了!
第一個長條圖會顯示問題。 紅線會顯示組織的容量。 堆疊長條圖會顯示結合的需求,方法是將所有專案的需求相加在一起。 如果這是我們提供給管理的儀表板,則決定要接受更多工作,或立即減少人員配置層級是很明顯的。
是,但請稍候一下。 在人員配置層級縮減計畫生效之前,有人會檢查儀表板檢視中是否已呈現所有專案。
它們不是。
圖例中出現一些專案,但長條圖中並未顯示這些專案的結果。 結果在哪裡? 這些專案可能尚未發佈。 可能仍在決定完整的專案範圍。 可能尚未在適當的層級定義資源需求。 當資料修訂時,我們可以在第二個長條圖中看到,事實上,現在的工作比人員多,我們應該考慮雇用更多員工、新增一些合約容量,或延遲某些專案到未來;從只查看一部分資料的相同檢視而做出完全相反的決策。
問題不在於儀表板的設計;也不是資料的品質。 這是問題所在資料的完整性。 在這個明顯的範例中,我們可以用自己的眼球來查看問題,但想像一下一個專案環境,其中包含數百或甚至數千個專案,或是相同資料集中的子專案。
只對部分資料進行決策通常會導致不適當的決策。 做出決策,讓決策者甚至不知道資料不完整,最好是對他們喪失權力。
我們可以藉由在某種核准程式中檢閱資料來解決此問題,或者,透過驗證程式和資料庫型指標的組合,告知我們,我們只會查看指標的部分影像。
日期之前最佳
如果您像我一樣,您可以觸達冰箱並抓取最接近您的乳酪,但不應該檢查「最前面」的日期嗎? 雖然我們以構成儀表板上該美觀圖片的來源資料為主旨,但您對於產生該指標的資料有多舊有任何概念嗎?
稽核儀表板指標並不常見,只是發現源自指標的資料長時間未更新。 通常會在檢閱會議中挑選此功能的主管。 這種人不只會帶上一次檢閱會議的筆記,也會顯示上次提供之所有講義的複本,而他們練習的眼球會查看最後講義和新的講義,並比較資料。
相同的指標表示,在大部分專案環境中, (不可能變更) ,或資料尚未更新 (在許多組織) 中的可能性更大。 針對財務部門經常因試算表的結果而生存和死的人,或由許多子總帳所組成的大量試算表伺服器陣列,這是常見的錯誤。 專案經理和查看專案資料的人員,如果沒有嚴格小心,就較不可能攔截這類錯誤。
最糟的案例是其中一些資料已更新且為最新狀態,且部分資料完全未更新。 因此,轉寄計畫或許已在一半專案上更新,而最後一個期間的實際資料已張貼到這些專案,但另一半專案沒有張貼實際資料或更新其計畫。 如果要在儀表板檢視或其來自的結果資料上做出決策,該資料應該會顯示在某處。
這種問題也可以透過資料中的一些基本檢查和平衡來解決,然後這些檢查和平衡就可以顯示在儀表板上。 例如,簡單的測試可確保:
所有時程表都會收集到顯示的期間;和
收集的總時程表時數大致相當於顯示的總時數。
資料 pedigree
顯示器越美觀,我們就越不可能詢問「該資料來自何處,其可靠性為何?」當我們將資料放入專業型式的圖形顯示器時,會有一些關於整齊的計數。 對於從資料庫建立資料的使用者,通常可以將它們保留在該資料抵達的距離。 圖形設計工具會尋找幾個實用的欄位,以及從中計算指標的方式,而且可以輕鬆地忽略透過經過驗證的程式填入這些欄位,是否透過任何類型的監督、計算,或輸入資料的人不會將資料視為「公司品質」。
也許我們正在處理軟體發展專案,以及未處理和新增的軟體問題清單,而且 QA 部門在接近發行日期時會建立一份絕佳的 SharePoint 問題清單。 這種清單可以是軟體發行準備就緒程度的關鍵指標。 不過,如果許多不同的群組針對新功能構想和增強要求使用相同的清單,只要計算問題清單就會提供不適當的指標,因為清單已因用於不同用途的資料而變得不適當。
要在儀表板上的指標上顯示的資料必須有一些程式及其品質的一些驗證。
我們是否正在查看整張圖片?
讓我們回到該儀表板流量燈報表,然後再次查看 IT 線路。
假設 IT 在特定的年長專案上有排程和成本指標的紅燈,因為它是六月,且兩個指標都關閉超過 20%!
財務長已經看過詳細的結果,他非常難過。 1 月 - 6 月的實際顯示故事:
($,000s) | Jan | 2 月 | 三月 | 四月 | 五月 | 君 |
---|---|---|---|---|---|---|
Budget |
80 |
100 |
120 |
120 |
120 |
120 |
實際 |
100 |
120 |
140 |
140 |
140 |
140 |
方差 |
20 |
20 |
20 |
20 |
20 |
20 |
累計變異數 |
20 |
40 |
60 |
80 |
100 |
120 |
到目前為止,專案已經超出預算 120,000 美元,而且只有半部以上! CFO 表示,按照這個步調,專案的成本會比其原始的 130 萬美元預算多出 18%,或許應該減少損失並取消專案。
不過,如果我們更詳細地查看,圖片看起來會非常不同。 專案結束前的預計排程和成本如下所示:
(,000s) | Jan | 2 月 | 三月 | 四月 | 五月 | 君 | 七月 | 八月 | 九月 | Oct | 11 月 | 12 月 | Total |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Budget |
80 |
100 |
120 |
120 |
120 |
120 |
120 |
120 |
120 |
120 |
100 |
80 |
1,320 |
實際 |
100 |
120 |
140 |
140 |
140 |
140 |
120 |
100 |
80 |
40 |
0 |
0 |
1,120 |
方差 |
20 |
20 |
20 |
20 |
20 |
20 |
0 |
(20) |
(40) |
(80) |
(100) |
(80) |
(200) |
累計變異數 |
20 |
40 |
60 |
80 |
100 |
120 |
120 |
100 |
60 |
(20) |
(120) |
(200) |
現在,我們可以看到更多本文。 專案的執行速度比預期快。 事實上,它會在 10 月中完成,而不是在 12 月完成,且預計在預算下完成 $200,000 美元。
這是簡單的儀表板及其解譯方式的挑戰。 儀表板完全正確,但其為紅色的原因是好的,而不是不良的。
儀表板指標需要向主管發出需要採取動作和查看位置的警示,但也應該將該主管引導至更詳細的資料,以顯示整個情況。
玩家 galore
好了,現在您可以做幾件事來確保儀表板不會將管理誤判為不適當的決策,而這是一大步驟。 但請注意,一旦儀表板類型指標可供使用,人們就會利用這些指標來獲得自己的優勢。 完全瞭解,如果使用者可以藉由扭曲其控制下的資料,讓他們看起來不正確,就會玩遊戲程式。
不會阻止使用者嘗試遊戲程式,但有一些技術可避免這些玩家的事件:
變更程式
您可以隨時變更程式,讓遊戲程式變得困難;嘗試讓那些認為自己已瞭解程式的人保持領先。搜尋引擎優化的搜尋引擎業務中的每個人都知道這一點,但挑戰在於持續變更程式並訓練變更中的每一個人所需的大量工作。
無吋,只要
另一個選項是將攔截到遊戲的人員進行專業處理。 這是一個困難的工作。 人員誰對資料進行惡意的抱怨應該會遇到問題,但只在程式中尋找漏洞的人,通常對鬥志而言是不好的。
檢查和平衡
這通常是針對玩家最強大的工具。 如果您有來自不同來源的資料必須與其他資料進行平衡,則有人很難只操作其控制下的資料,並破壞他們偏好的儀表板程式。 當然,您不一定能夠在資料中找到這類檢查和平衡,因此,同樣一律是一個不錯的事。
一些基本規則
好的,讓我們總結一下我們所說的一些內容。 從技術上來說,建立功能強大的儀表板並不困難,但是您可以在儀表板設計和專案管理程式中實作一些基本規則,以確保從這類儀表板所制定的決策是適當且有效的。
以下是我們先前討論過的一些基本概念摘要:
指標必須追蹤回來源資料
請確定指標不只是手動輸入的意見或某人的情緒,而是實際代表您環境詳細資料中的內容。
每個指標都需要動作
每個指標都需要動作;每一個。 不論動作是什麼,都必須有一個。 這也有助於將指標數目保持在合理的層級。
資料必須已完成或未顯示
請確定顯示中的資料是完整或不完整的,因此只查看部分圖片時不會做出不適當的決策。
顯示器必須顯示其時效性
如果可以更新某些資料,但無法更新其他資料,則資料的重新整理日期必須顯示在儀表板上,以避免根據舊資料或新舊資料混合而做出不適當的決策。
以持續的方式檢查資料品質
儀表板應該定期檢閱資料,以推動指標和定期更新,以避免人員進行決策制定程式。 某些組織會實作定期稽核程式,以查看關鍵指標,並從其結果追蹤到來源資料,檢查公式和資料品質,以確定其未變更。 當然,您無法一直這麼做,但定期檢閱那些美觀的交通燈會變成綠色、紅色或黃色是狀況良好的概念。
儀表板的快樂!
參考
若要深入瞭解如何使用 Microsoft Project Server 執行儀表板,建議您閱讀 TechNet 上的幾篇絕佳文章:
Microsoft Project Server 2010 Reporting,Excel Services由 microsoft 諮詢服務 https://go.microsoft.com/fwlink/p/?LinkId=222672 () Jean-Francois LeSaux 和按下層 Haden 撰寫
建立由 Blaise Nova 要撰寫的 Microsoft Project Server 2010 儀表板,Jean-Francois LeSaux、並存取 Microsoft 諮詢服務 () https://go.microsoft.com/fwlink/p/?LinkId=222669
關於作者
Chris Vandersluis 是 Microsoft 認證合作夥伴、加拿大 HMS Software 的副總裁和建立者。 他擁有 McGill University 的經濟效益學位,以及超過 30 年的專案控制系統自動化經驗。 他長期隸屬于 Project Management Institute (PMI) ,並協助您找到 Microsoft Project Users Group (MPUG) 的多倫多、多倫多和魁北克章節。 Chris 所撰寫的發行集包括《星號》、《重度建構新聞》、《計算加拿大》雜誌和 PMI 的 PMNetwork,而他也是 Project Times 的一般常客。 他教授 McGill University 的進階專案管理,並經常在北美洲全球各地的專案管理關聯函式上進行討論。 HMS Software 是 TimeControl 專案導向的計時系統發行者,自 1995 年起一直都是 Microsoft Project Solution Partner。
您可以透過電子郵件連絡 Chris Vandersluis:: chris.vandersluis@hms.ca
如果您想要閱讀 Chris Vandersluis 的更多 EPM 相關文章,請參閱 HMS 的 EPM 指引網站 (https://www.epmguidance.com/?page_id=39) 。