我們銷售的是成果，不是工具！

我最近遇到一個有趣的運算式。 軟體銷售人員正在討論如何將整個解決方案傳遞給用戶端。 「我們不會銷售鑽研。 我們銷售漏洞。」他表示。 這是很好的比喻。 許多人 (我隨附) 已前往在電源工具部門購物的硬體存放區和視窗，同時想知道我可以想到哪些專案適合購買這個絕佳的電源工具。 但是，套用此邏輯在「自行執行」世界中與在企業軟體系統中一樣有意義。

如果您沒有問題，則不需要解決方案。

就像沒有人應該去尋找鑽研一樣，除非他們想要解決的問題是建立漏洞，除非能解決一些問題，否則沒有人可以尋找企業軟體。 現在，如果您遇到部署企業軟體會修正的問題，接下來要確保您購買的專案將提供您所需的解決方案。 這通常不只是購買軟體。

部署企業系統是一項複雜的挑戰，因此回報必須值得付出。 在現今的全球專案小組世界中，最常執行的一件事就是分割企業系統部署的極大精力。 雖然這可讓我們利用在專案方面經過高度訓練的小組來調整規模，但也具有以高風險方式忽略專案層面的風險。 這種風險會因不同小組在實體上和組織上中斷連線而更加複雜。

讓我們看看企業系統專案最常見的元素。

什麼是企業？

首先，企業代表什麼意思？ 我將採用幾乎所有人都適用的定義。 在此內容中，「企業」表示會影響整個組織運作方式的任何專案。 我會說這對任何組織都是如此。 符合企業實作資格的實作，不只是有多少使用者，而是他們的影響程度。 因此，將病毒掃描軟體從廠商 A 更新為廠商 B 可能不符合資格。 少數使用者在桌面上實作專案排程軟體可能不符合資格。 集中管理專案和使用集中式企業專案管理系統可能符合資格。

好的，如果這是企業專案，部署企業系統最常見的元素為何？ 在我們的辦公室中，最常見的體驗是部署企業時程表系統，例如我們自己的 TimeControl 或企業專案管理系統，例如 Microsoft Project Server，但這些元素幾乎適用于任何企業系統實作。

位和位元組

首先，讓我們來處理軟體的最基本建置組塊：技術架構。 現在，我們必須根據決定使用內部部署或雲端內訂用帳戶來劃分我們的想法。 我會留下選擇哪一個最適合其他一天條件的奇數，但以下是我們在每個類別中必須思考的一些基本概念。

如果我們要進行內部部署安裝，我們必須思考我們將使用哪些硬體。 記憶體和 CPU 的硬體需求為何？ 我們會使用實體伺服器或虛擬伺服器嗎？ 我們會使用專用伺服器或共用伺服器嗎？ 可能需要哪些類型的伺服器？ 我們需要應用程式伺服器、安全性伺服器、網頁伺服器嗎？ 負載平衡、災害復原和備份呢？ 我們需要冷備份或暖備份伺服器嗎？ 呼！ 但是我們還沒有完成！ 資料庫呢？ 有哪些需求？ 如何支援我們現有的安全性、應用程式和資料庫架構？ 如何支援瀏覽器、瀏覽器版本和行動裝置？ 當所有問題都獲得解答之後，我們必須處理安裝、測試和生產環境的問題，然後在系統啟動並執行之後處理系統健康情況和監視。

如果我們要進行雲端內訂用帳戶實作，我們仍有問題需要回答，但這些問題可能非常不同。 我們使用哪一個線上服務？ 我們使用專用安裝或多租使用者服務嗎？ 安全性呢？ 我們可以與自己的驗證整合嗎？ 如何使用訂用帳戶服務處理災害復原？ 資料實際位於何處？ 這是否為我們帶來法律問題？ 如何支援我們的內部瀏覽器和行動裝置？ 如何將資料取出，以及如何與內部資料庫或其他外部 SaaS 連線 (軟體即服務) 服務來整合功能？

還沒有生命嗎？ 當我們討論企業系統時，這些問題等等都已提在議程上。 如果我們將專案的這個部分移至訓練有素的技術小組，他們可能會開始將此視為整個專案的範圍，而這只是我們鑽研的建構，還不是我們需要的漏洞。

設定我！

除了讓系統運作之外，也會將該系統內的功能套用至我們的特定問題。 我看過 Project Server 部署，用戶端會在其中啟動並執行 Project Server，然後發現他們並未配置任何資金來建立工作流程、瞭解如何排定其專案組合的優先順序，或瞭解如何製作單一報表。 就像系統分析 101 回到大學時一樣，我們通常會在白板最右邊開始此部分的實作，因為我們會詢問有實際商務問題的商務人員，他們將需要哪些「輸出」。 我之前曾在其他文章中提及過這個問題，因此我在這裡並不會加以修改，但輸出最終應該是商務決策。 若要做出這些決策，我需要哪些報表、分析，以及最終的資料輸入？ 我們會從畫面右側向左工作，最後會以資料元素、分析計算，以及需要在系統中設定的匯出和報表形式，列出我們需要的所有建置組塊。 此設定練習可能需要數周或數個月的時間，視其複雜度而定。

在專案這一方面，我們需要的資源類型通常是商務分析師和系統專家的組合，雖然這些人在部署的系統功能方面可能非常熟練，但他們在技術架構中卻沒有那麼熟練。 這會讓系統兩個重要元素的已中斷連線小組相當常見。 這兩個群組的通訊越少，我們稍後就越有可能面臨挑戰。

這是一個程式

不可能部署新的企業系統，也不會影響組織的程式。 即使您放棄一個集中式企業系統並移至其競爭對手，程式也會變更。 事實上，如果您不想讓程式變更，則完全不可能沒有需要解決的問題，而此處還有另一個挑戰。 當某個人的日常工作變更時，會造成混亂。 我並不表示有一些時間。 根據我的經驗，在變更的這個時間感到挫折是一項選擇。 即使程式變更會產生更好的程式，也是如此！因此，思考程式將如何變更，並與會受到影響的人員合作，對於專案的成功至關重要。 不過，對於設計此程式變更至關重要的專家，可能是同樣會受到該變更影響的人員，因此這可能是實作的一個挑戰性層面。 通常，技術熟練且經驗豐富的促進者會與內部專家合作，以引導新系統的實作所實現的程式變更。 在我們的工作中，我們一直都會看到這項挑戰。 「但專案經理必須先核准時程表」，新的 TimeControl 用戶端告訴我們。 「這是我們的程式。」當我們說明矩陣核准可讓專案經理在更大、更有效率的程式中執行時程表核准時，我們會感到困擾;pushback。 此時，我們有其中一位最有經驗的員工與受影響的人員合作，以確保他們的顧慮會受到處理，且其是程式變更方式不可或缺的一部分。

因此，程式人員可能不是設定人員 或 技術人員，但如果我們沒有規劃此小組，我們對於安裝和設定的所有努力工作可能不會部署。 此小組也必須是規劃的一部分，並包含在其他兩個小組所做的通訊和決策中。

訓練

「那麼，我們需要訓練嗎？」很抱歉，這是最後一個常見問題。 某些訓練可能會經歷程式變更，因為該專案的一部分需要進行許多實際討論，但新系統如何以更逐步的方式運作的實際使用者指南呢？ 一次，訓練被視為軟體部署的重要元素，而用戶端預期會將總預算的 20% 放在其中。 但是，隨著軟體成本和安裝速度的變更，20% 的金額逐漸降低。 如果我們為系統每個使用者每月支付 $20 美元，我應該為每位使用者預留 $4 美元進行訓練嗎？ 我無法保證它不會太遠。 有許多線上訂用帳戶選項可用來進行訓練，但沒有任何一個選項會將您所設計的確切解決方案納入考慮。

訓練人員可能來自外部，或可能來自專案的組態或程式部分，但他們通常是專家，而不是實際執行實作工作的人員。 因此，即使您為此小組投入了資金 (，而且希望您已) ，您仍然需要確定這些人員知道他們訓練人員的系統實際設計用途。 我看過訓練人員抵達 Microsoft Project Server，並讓他們開始向使用者說明如何在產品群組分析中設定企業欄位和設定商務驅動程式，只讓使用者提供空白的星號，因為他們的企業欄位已全部設定完成，而且不會在初次推出時使用組合分析。您的訓練人員甚至知道此特定部署應該解決的問題嗎？ 它們應該。 在專案開始時考慮定型，可讓其獲得最大的成功機率。 技術、設定和程式小組可以透過其章節將重要資料放在一旁，以進行最終傳遞的訓練。 這表示請及早參與訓練小組。

推出/接受/文化特性變更

如果您正向思考並留出資源來起始這些小組，並讓所有小組都透過專案一起運作和通訊，則新系統的推出可能會比原本更順暢，但不會略過文化變更的抗拒。 在正確的時間提供重要的傳播者非常重要。 此外，這些小組成員是否會進行封裝並繼續進行下一個專案？ 當專案推出時，這些人員中將會包含許多系統知識。我在去年初對其中一個用戶端特別滿意。 IT 部門是大型財務組織。 我們向在專案初期評估軟體的關鍵技術使用者，其中一個考慮是「當您將專案包裝後，誰將會是系統管理員？」「我會這麼做的」，他會說。 他一字不成真。 他的技能和知識是透過多月部署而演進，這非常成功，而且他仍然是重要系統管理員。

總結

在如何確定您的小組在更大的目標中進行通訊和工作方面，還有一百個其他事項需要考慮，而我們只討論過一些。 希望這可讓您思考下一個企業系統部署。 您可能會在想「檔呢？」。 「技術支援呢？」

要記住的重點是：當您規劃企業系統部署時，您必須展開觀點，不僅包括安裝工作，也包含已完成解決方案的傳遞。 請確定洞的出現位置應該只有正確的大小、右側深度和直角。

關於作者

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