EPM：集中式或分散式？

  • 文章

本文是「從馬西斯」集合的一部分。 其中說明組織在決定實作專案管理系統時，需要如何瞭解他們嘗試解決的問題。 有時候部署集中式專案管理系統可能不是最佳答案。

若要下載本文的 Word 版本，請參閱 EPM 集中式或分散式？。

若要查看更多文章，請參閱 白皮書。

EPM - 集中式或分散式？

自從 1980 年代初次進入專案管理產業以來，我一直都是企業專案管理的傳播者。 您會認為，我一律會在集中式專案管理方面投票，但情況並非總是如此。 讓我們討論一下企業專案管理的意義。

EPM 對不同的人可能代表許多不同的東西。 我已在此欄的其他文章中討論過 EPM 部署的焦點如何成為一個組織的檔管理，以及下一個組織的整合式排程。 不過，企業專案管理的核心是人們必須在專案管理練習中彼此互動的概念。 這表示專案經理和/或專案管理小組無法完全獨立運作。 但這是否表示達成此「互動」的唯一方法是擁有集中式專案排程系統？ 不一定。 對於某些組織而言，專案管理挑戰可能是無法產生摘要的全企業專案管理報告，因為專案全都是以特定方式管理。 在此情況下，EPM 可能只要在所有專案管理人員之間共用專案標準即可達成。 最好是透過範本、訓練教材、檔和報表標準的中央集區來達成，每個人都可以使用這些標準。 也許簡單的 SharePoint 網站就已足夠。

對於某些組織而言，專案管理挑戰可能是不正確個人排程，因為資源之間沒有關于其工作內容及其下一個焦點的通訊。 在此情況下，可藉由改善小組和小組間的通訊來達成 EPM。 這些工具可以像共用行事曆、立即訊息或共用入口網站一樣簡單，使用者可在其中列出其優先順序。

在某些組織中，專案管理挑戰只是在程式設計開發專案上取得進度。 如果是這種情況，則已經存在於像是 Visual Studio Team Services 等產品中的工具可能已足夠。 在程式設計專案中，通常會發現許多工作幾乎可以任何順序完成，因此嚴重路徑排程的嚴謹可能甚至不適合，視正在完成的開發類型而定。

我還記得在幾年前與某家航空公司的維護部門合作。 員工可以在每個月開始時選擇自己的排程，而且如果這不是協調 (通常) 的情況，則可以抵達 管理班次，只找出沒有人在工作。 他們的專案管理挑戰不是「工作何時完成？」，其內容是「是否有人開始工作？」在此情況下，EPM 是透過實作班次排程工具來達成。

即使我們將 EPM 挑戰焦點放在專案排程上，部署集中式專案管理系統是唯一或最佳的答案，這並不明顯。 值得詢問專案管理人員之間需要有哪些互動。 如果他們必須定期共同作業以解決資源衝突、查看組織中的其他優先順序，或查看某個專案的進度會如何影響另一個專案，則查看 Project Server 之類的工具非常合理，但通常我最後會與甚至未詢問自己這個問題的組織互動。

在某些組織中，我們發現少量的排程器和大量的資源。 即使在規模良好的組織中，這也可以是結構，視產業和正在完成的專案類型而定。 很久以前，我與組織一起發現，他們已為 EPM 挑戰挑選了正確的解決方案。 他們要求我表達解決方案，但和往常一樣，我要求他們先表達其專案管理問題。

當他們在白板上完成環境的描述時，甚至對他們來說，他們選擇的解決方案無法解決其問題也很明顯。

在此情況下，問題在於缺少大型轉包商集區所回報的專案進度。 用戶端判斷他們真正需要做的是對其轉包商施加時間和計費類型的時程表。 不建議使用計畫目錄。 他們表示：「我們永遠無法將它放入轉包商合約中。 幸運的是，財務部門的成員已存在。 「您知道」，該人員回復：「要求他們填入我們選擇時程表的子句已經在轉包商合約中。」問題已解決。

在開始進行解決方案之前逐步解說問題的想法是經常在這裡討論的一個想法，但卻是很難採用的。 邏輯思考會指出判斷自動化解決方案的順序為：

  1. 識別問題

  2. 定義解決方案

  3. 決定是否要 (，如果是，如何) 自動化解決方案

網站、影片和其他地方的自動化解決方案示範讓我們忘記這一點。 當然，除非有某種問題，否則我們不會尋找解決方案，但自動化解決方案的外觀和音效非常吸引人，因此我們最終會這麼做：

  1. 選擇自動化解決方案

  2. 在部署解決方案時發生問題

  3. 藉由定義自動化工具如何套用至解決方案來解決該問題

  4. 嘗試記住原始問題為何

新問題會在一段時間內變成部署解決方案，然後在上層管理的某位人員詢問原始問題何時能解決，而每個人都會很意外地互相查看之後，再用數周、數個月或甚至幾年的時間來部署解決方案。 很容易忘記。

多年來，我建議使用各種可能的自動化解決方案。 不過，Project Server 當然是其中一個選項，但我也建議使用 Microsoft Project Pro 和 SharePoint Server 的組合。 我建議使用 Excel 和 Outlook 的組合。 我建議搭配 Project 使用協力廠商時程表。

我甚至曾經建議使用大白板。 誠實。 組織是我多年來一直與之一起完成業務的工作。 相關人員是房地產角色，且必須在房地產中續約長期租用。 當我詢問問題出在哪裡時，這顯然就是排程問題。 該人員已錯過一些重要的期限，並確定企業專案管理工具會修正問題。 組織已要求將報告散發給數位主管，因此不會錯過未來的期限。 「有多少使用者？」我問過。 「Just me，」他回復了。 「一次有多少個專案？」我問「七或八」，他回答。 「以及您為每個專案管理多少個期限里程碑：「這非常複雜。 每個期限都有大約六個期限。他告訴我。

我已清楚知道，我們不應該為這個不佳的夥伴安裝大型集中式 EPM 系統。

「為什麼不只是在您的隔間中放置大白板，並針對不同的里程碑使用一些彩色標記？」我問過。 「您可以使用藍色作為第一個，綠色表示第二個，紅色用於最後一個，依此類推。」

他擷取了概念的大量筆記。 我離開公司，知道當天我並未銷售任何服務或產品，但我讓人員感到無法部署他所抱歉的系統。 在住家途中，我的電話在汽車裡響鈴。 他就是 「您可以解釋白板的不同色彩嗎？」他問。

在設計解決方案之前，以及選擇如何自動化之前，找出您嘗試解決的問題，不只是節省成本。 它可節省花費大量時間處理組織元素，而這些元素一開始就沒有需要解決的問題。

當您嘗試解決的問題可以透過集中式企業專案管理軟體獲得最佳解決時，則不會有任何其他動作，但您透過表達問題所獲得的焦點甚至會有所説明。 您的部署小組可以建立成功計量，讓專案在問題解決時宣告成功。 要集中或分散？ 企業專案管理可以使用其中一個來達成。

關於作者

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) 。