搶在收費代碼前面

本文是「從馬西斯」集合的一部分。 其中描述為專案管理系統或時程表系統定義組織費用代碼結構的最佳做法。

若要下載本文的 Word 版本，請參閱按費用代碼預先充電。

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

搶在收費代碼前面

我通常會被要求協助組織為其專案管理系統或時程表系統定義其收費程式代碼結構。 雖然每個組織都是不同的，而不同的需求會導致不同類型的費用，但多年來我們發現有一些常見的做法是通用的。

詢問較少，而不是更多

沒有人喜歡按兩下，因此您所建立的收費程式代碼結構越複雜，人們製作精確報告的可能性就越低。 例如，假設我在長一般清單中列出 10,000 個收費碼可供選擇。 您可能必須捲動一小時，檢查下拉式清單中每個可能的專案，才能找到這個特定時程表或專案更新的正確選擇。 然後，您必須捲動清單的其餘部分，以確保找不到一些不只是更精確的專案。

我們不要大為之意。 沒有人會這麼做。 他們會取得第一個看似相當接近的專案，並加以選擇。 若失敗，所有時數最終都會收取 「999：Miscellaneous」 費用。

因此，讓您的清單變得簡單。 在理想的情況下，它應該完全不需要捲動，但應該會顯示在單一畫面上，或是按兩下即可。 這表示您最多只能從 20-30 個可能的選項中選擇。 在此情況下，較少是更多。

如果管理決定取得更多詳細數據，請提醒他們，比起更詳細且精確度較低，最好取得更精確且較少的詳細數據。

請勿詢問您已經知道的事項

我看過許多收費程式代碼結構，其中每個部門或每個專案都有相同的收費碼。 然而，如果人們已經被要求選擇專案，而我們正在執行會議專案，例如，我知道明細項目必須是「此專案上的會議」，那麼為何要以多個會議專案來收取費用清單？ 相同的邏輯與部門相同。 如果我們有屬於每個部門的員工清單，則我們已經知道他們在哪個部門。 為何要使用「銷售部門會議」、「技術部門會議」和「行銷部門會議」來收取費用清單。 只要製作一個稱為「會議」的項目，我們就可以從員工的部門和他們對於會議用途的專案推算。

解決以獲得更佳的解決方式

為您的專案和時程表挑選適當的解析度層級是常見的挑戰。 請思考您想要使用下列條件來管理專案層級：1) 數據的價值必須比收集數據的時間還要高，因此，如果您在一天當中花費一整天的報告，您實際上會如何完成任何工作？ 2) 在您已準備好進行決策的層級上工作。3) 輸入越複雜，您就越不可能取得精確的數據。 4) 可能的話，讓每個人都以相同層級的解決方式工作，這樣您就不會在 10 分鐘長的工作中管理一個群組，而在 3 天的工作中管理另一個群組。 對許多人而言，能夠報告指定一天的 3-5 行詳細數據是許多詳細數據。

設定數據的條件

有些人會讓終端使用者一再回答相同的問題。 例如，我們已看到具有 「R&D」數據行的系統，這表示此費用是或不符合 R&D 稅額的資格。 但我們應該能夠將資格與工作本身產生關聯，而不是將每一個人的時程表每一行產生關聯。 此外，如果某些用戶認為它符合資格，而某些用戶認為不符合資格，該怎麼辦？ 這個可能的案例也會在範例中播放，例如「R&D 的設計資格」和「R&D 的設計不符合資格」。 這會將費用代碼數目加倍，不傳回值。 只要讓 R&D 中的人員將每個下拉式清單值標示為符合資格，您就不需要持續要求終端使用者每周嘗試找出該值。

層次

更好的專案和時程表系統可讓您以階層方式顯示數據。 如果您沒有選擇，但要有許多可能的選擇，則建置階層可以讓許多數據更容易產生。 假設每個層級最多有 5-10 個專案可供選擇。 而且不要想要建立數十個層級。 建立 3-4 層級階層應該能夠涵蓋大部分的選項。 畢竟，4 層系統中每個層級 10 個專案是 10,000 個可能的費用。 您的專案是否比那更複雜？

顯示較少

您為使用者提供的問題和選擇越少，就越好。 如果您在背景中可以回答任何問題，請嘗試不要在時程表上詢問使用者。 目標不是盡可能收集最多數據，而要盡可能收集最精確的圖片，而且如果您將使用者與數據、問題和選項隔離在一起，對他們沒有任何影響，您將能更進一步。

您將如何處理該數據？

中間管理類型通常會告訴我，它們需要比我建議的「更詳細」，而且我的回應一律相同：「您該怎麼處理？」收集以工作為基礎的時程表數據的目的是要做出更佳的商務決策，因此我經常會詢問這些中間經理，他們無法做出哪些商務決策，因為他們認為如果他們有更多詳細數據，他們會更擅長。 當您開始以這種方式查看資訊時，您發現可能需要較少的資訊。 找出會議、傳輸中或額外負荷工作所花費的總時數，可能就足以找出每項工作是什麼。

深入鑽研... 但只有在您必須

當您開始進行時程表分析以找出您的時數全部都在何處時，您必須找出一些不相稱的結果。 當您發現不預期的超高時數百分比時數，請深入鑽研。 但不要太深。 為該費用再新增一層詳細數據，並提供數周的時間來查看您取得的數據。 其選擇是將單一收費代碼，例如「會議」，擴展成50個新的收費代碼，其中包含可能發生的每種可能會議類型。 請嘗試抗拒這種抗拒，改為將該 1 個收費碼變更為 5 或 6。 如果您未取得詳細數據，或仍有不相稱的結果，請深入探討。

保留乾淨房屋

收費清單有增加大小但永不減少的趨勢。 定期檢閱並消除 Bloat 是不錯的做法。 如果您這樣做，您更可能繼續取得更精確的資訊，並能夠識別您正在失去時間的區域。

總結

無論是針對專案排程或時程表系統收費程式代碼管理，都可以在可計算數據的有效系統，或定義太多且精確度不足的系統之間產生差異。 當您設計費用程式代碼結構時，建議您從較少開始，而不是更多。 如果稍後需要新增更多詳細數據，比復原更多詳細數據並讓不知所負的使用者更容易。

關於作者

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