我們到了嗎？

本文是「從 Ttrenches」集合的一部分。 其中說明企業系統實作需要如何調整併發展成成功。

若要下載本文的 Word 版本，請參閱 我們是否還在那裡？。

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

我們到了嗎？

多年來，我在企業軟體的選取和部署中看到的最大陷阱之一，就是將實作視為滿足靜態用途。 這可能只是我們時間的徵兆，因為我們嘗試對世界中的所有專案進行聲音攻擊。 「它管理我們的專案」、「這是我們的時程表」或「這是我們的 ERP 系統」或「我們有 EPM 系統」，可讓我們必須持續思考企業系統可能觸及的所有業務層面。 然而，我在部署企業專案或企業時程表系統時遇到最成功的組織，卻無可避免地將它們視為「即時系統」;依設計持續演進的系統。

為什麼要將它視為靜態系統？

如果將企業系統視為動態環境有更好的成功機率，為什麼許多組織會將其企業系統視為固定的軟體？

有許多可能的原因。

或許接受企業系統，意謂著在複雜的預算環境中建立商務案例，其中只有一個機會，且只有一個機會可以取得核准系統的預算。 回到每年或每個預算週期來要求另一個階段，然後另一個階段就不可能實現。

或者，您可能繼承了系統，並做出某些承諾來達成它所要傳遞的內容，或是它已經存在一段時間，而且組織中的每個人都認為系統只提供一組商務功能清單。

或者，或許政治內部有工作，而組織中的其他地方會在沒有界限的情況下，成為系統的跳馬者。

該想法有何錯誤？

我們甚至會將軟體系統視為靜態，這十分奇特。 我們通常不會將問題視為靜態來解決。 我們與企業系統實作相關聯的問題陳述幾乎一律會不斷演進。 相依于經濟條件的變更、商務條件的變更、競爭對手的變動、人員的變更或技術架構的變更。 認為商務條件永遠不會變更的組織不太可能長時間留在業務中。 如果我們想到企業軟體，請思考解決方案的技術層面變更的速度。 在自己的 TimeControl 時程表業務中，我們已在 20 年內經歷 6 個主要的技術架構變更。 我們從 1994 年開始使用 DOS 版本，接著在 1995 年使用 Windows 版本、1997 年的用戶端/伺服器版本、1999 年以瀏覽器為基礎的版本，然後在 2010 年使用裝載于雲端內和行動裝置版本。 這只是技術架構。 由於經濟條件、競爭對手和經驗的改變，因此發生了額外的演進。 對於企業專案或企業時程表軟體發佈業務中的人員，我們接受該變更是常數。

部署企業系統並無不同的想法。 在實作 Project Server 等企業系統所需的時間內，實作它的組織會受到變更的約束。 將會有新的用戶端、新人員和離職人員。 在選擇和部署 EPM 系統所需的時間內，將會出現其他競爭產品。 我們已看到組織因為這種現象而有所不同。 由於擔心他們無法選取完美的產品，其他廠商發行另一個產品時，選取群組會暫停其工作以考慮新產品。 或者，要考慮之其中一個產品的新版本發行，讓每個人都擔心其評估不會考慮所有替代方案。 這些群組會一再重新開機。 最終決策永遠不會實現，因為組織需求和解決方案選項永遠不會停止變更。

這些組織的問題在於，一開始就讓他們尋找解決方案的商務挑戰不會消失，而且如果沒有決策，就無法解決。

那麼，如果不是靜態，該怎麼辦？

如果企業系統部署是生活環境，則有更好的成功機率。 它們應該成長、演進並適應其周圍不斷變化的條件。 而且，是的，也許在未來的某個時間點，當他們過時時，就必須淘汰它們。 這種思考方式的最重要變更是完美解決方案不是起點。 優先順序會變成選擇符合最重要需求的解決方案，但即使這些尚未完全清楚，也能夠在未來適應更複雜的需求。 其中一個最重要的選取準則會變成彈性，而不是廣泛的功能。

如何避免靜態快取？

我們可以執行一些動作，以避免停滯在靜態部署範例中。

• 在您的實作計畫中建立階段，且永遠不會用完階段。

  如果我們對企業實作採用階段式方法，我們可以專注于更簡便的第一個階段。 我們的諮詢人員會被教導識別出的不是我們所能做到的最多，而是最少的。 我們告訴他們「尋找最少的部署，部署將會產生持續的正投資報酬率」。這點的好消息是，系統的價值會更快速地開始，而且在使用系統時，即使是在更基本的層級，未來使用的需求也會變得更清楚。

• 建立允許演進的預算。

  我們在許多部署中看到的其中一項挑戰是「一次造訪一次」思考企業系統要求只能提出一次。 改為進行階段式預算，但預期前幾個階段預算相當詳細，但未來階段較少，因此無可避免地更成功。

• 挑選高度彈性的解決方案。

  我們的員工採用了彈性玩具 Mr.) 之後的「Semper Shutdownby」 (座右詞。 這是在美國軍事單位中第一次創造的文字播放，但它完全符合我們的想法。 就像 Mr. 將不會知道接下來要調整到什麼形狀，因此我們會從彈性的角度思考。 在您選擇的任何企業解決方案中，採用高彈性是成功準則。

• 當您開始運作時，請勿放棄所有實作小組。

  繼續使用重要資源。 這是極為常見的挑戰。 通常在企業部署中，組織會被繪製成指派其經驗最豐富且技術最熟練的資源，這當然有助於選取並實作系統。 不過，這些資源就是下一個重要專案所需的資源，而且可能會在系統上線且處於最關鍵關頭時，從此專案中提取資源。 事先規劃讓某些重要資源保留在實作上較長的時間，可能會產生極大的差異。

• 建立永久的系統增強小組，或許很小但技術熟練。

  組合企業系統需求的小組將探討商務程式、系統功能、與其他重要企業系統的整合等等。 讓這些人在安裝系統後放棄系統，讓未來的演進變得非常具挑戰性。 將此企業系統和其他相關系統放在長期演進的考慮中，以定期評估組織的需求和系統功能。

從實際使用量學習

• 讓您的系統提早進入生產環境。

  這在現今的世界中比 5 年前容易許多。 您可以利用雲端式安裝和遠端存取服務，讓系統快速執行。 大部分同時具有雲端和內部部署供應專案的企業系統，都有從一個發展到另一個的方法。 Project Server 確實是如此。 這也適用于我們的系統。

• 請確定有產生系統增強的意見反應迴圈。

  最好能看到可以改善的事物，而不是壞事。 有些實作小組不建議進行改進，擔心其會讓人員無法使用他們已部署的系統。 我們的經驗是，提出改進建議的人通常是企業系統的最大因素。 即使無法立即實作想法，也應該受到歡迎。 建立系統來識別和鼓勵企業系統的新構想，可讓所有人持續投資，並可帶來極大的好處。

• 不要太快放棄希望。

  有些公司會說「問題出在軟體中」，並在成功之前立即出貨。

我們到了嗎？

那麼，我們何時會到達該處？

希望永不如此。

這並不是說一路的月臺不會是暫停的好地方。 新實作企業軟體的第一個目標，例如企業專案或企業時程表系統，應該是可提供正投資報酬率的生產環境。 尋找可在圖層或階段中部署，並有足夠的彈性來成長、調整和變更的系統，而且您可能會在過程中找到比您可能在等候挑選完美目的地時還要多的生產力。

關於作者

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