選擇企業軟體的挑戰
本文是「從馬西斯」集合的一部分。 其中說明企業系統實作需要如何調整併發展成成功。
若要下載本文的Word版本，請參閱選取企業軟體的挑戰。
若要查看更多文章，請參閱 白皮書。
選取企業軟體的挑戰
它一直都會在這裡發生。 用戶端會傳送「提案要求」 (RFP) 至辦公室，並指示您在數天或一周內完成回應，並將它傳回，讓我們的企業系統考慮購買。 RSP 看起來幾乎都一樣。 通常會有簡短的概觀、您需要做什麼才能考慮回應的指示，包括需要如何格式化，以及何時傳迴響應等等。接著，有一長串的功能是必要的，還有一些額外的問題需要撰寫解答。
RFP 的挑戰在於它們不適合選取企業軟體，而遵循 RFP 程式時所發生的狀況並不保證組織有最佳決策。 RFP 是由購買社群所設計，以獲得最佳價格的最佳商品，但仍能達到最佳效果。 當供應專案可比較時，決策制定程式可以將焦點放在最佳價格，其中只有一或兩個額外的變數 (例如) 要爭用的出貨日期。 當可能的解決方案屬於與企業軟體) 相同的一般類別，但並非完全可比較 (，則購買者必須考慮的變數數目會很大，而且 RFP 程式不會為選取範圍增加價值。 大部分的公司如何選取企業軟體 讓我們從查看企業軟體的任何廠商或解決方案提供者中一直發生的程式開始。 我將討論企業專案管理軟體或企業時程表軟體，如我公司所提供，但幾乎所有企業系統選取的範例都相同。
大部分公司如何選取企業軟體
讓我們從查看企業軟體的任何廠商或解決方案提供者中一直發生的程式開始。 我將討論企業專案管理軟體或企業時程表軟體，如我公司所提供，但幾乎所有企業系統選取的範例都相同。
在大部分的組織中，尋找企業軟體的期待來自于一些問題。 或許問題是由現場人員所呈現。 或許問題是由資深管理人員所識別。 不過，此方案必須取得資深管理人員的支援。 即使是最漸進的組織，對將影響整個企業的系統進行選取也十分強大。 因此，資深經理決定「我們需要這種企業系統」。
典型的企業軟體選取程式如下所示：
管理指出我們需要新的企業系統
已選取專案經理
向所有相關部門提出要求
將所有要求合併成一個大型試算表
將需求方格傳送給許多廠商
取得許多回應
簡短清單
觀看示範
洽談
取得管理接受
讓管理決定其他事項
選取工作的專案經理是自願的。 他或她會執行我們所做的一切 —移至網際網路、載入搜尋引擎，然後輸入「EPM 軟體」 (或任何需要的企業系統) 。 立即傳回 50 萬次點擊。 也許心力的專案經理會流覽前十幾個系統，以瞭解在繼續之前可以使用哪種系統。 很明顯地，沒有人有時間流覽 50 萬或更多點擊，以查看最後一個叫用是否為組織的理想系統。
專案經理現在不由這個新的企業系統實作所影響的人員組成選取委員會。 委員會中的某些人員可能來自一開始識別組織需求的現場人員。 其他可能不行。 此選取委員會中可能會有一些人員對要選取的系統類型有不同的興趣。
不出覺的專案經理現在會請求委員會的每位成員輪詢其代表群組，瞭解其在新企業系統中的需求。 每個委員會代表如何執行這項操作？ 首先，並非每個人都會投入相同的心力，但對於執行其作業的人員，他們會要求員工提交他們覺得重要的功能清單。 然後，他們也會點擊網際網路，並流覽一些廠商網站。 他們可以從這些網站的摺頁冊中看到的功能複製並貼上，因為每個網站都會提供他們新的想法，讓他們知道可以對新系統提出哪些類型的要求。
現在，委員會已重新編譯，而且每個委員會成員的長試算表會與其他成員合併成一個大型試算表。 需求的超試算表已分類，但有一些挑戰。 委員會的所有不同需求中的第一項現在會變得更明顯，因為從各種觀點要求功能。 不同部門中可能有委員會成員，但也位於不同的國家/地區或甚至是不同的部門。 幾乎一律會有一個要求與相同清單中的另一個要求發生衝突 (例如，系統應該非常簡單，而且沒有太多提示，而且系統應該非常有彈性，每個使用者) 都有大量的選項。
最後，廠商會看到的合併試算表已完成。 它有數百個功能要求，而且每一個功能要求的廠商應該會說「是」、「否」或「有些心力是」。 加權系統也可能會附加，以指出這項功能是「必須擁有」、「重要到有」或「美化為有」。
RFP 幾乎已準備就緒。 有一些簡單的問題，通常是關於選取範圍的技術架構，而且根據有多少人已輪詢這些需求，架構要求可能同樣衝突 (例如，系統必須將所有資料集中儲存在SQL Server資料庫 ¬和 ¬ 系統必須允許任何資料儲存在使用者的電腦本機) 。
實際上，到目前為止聽起來不錯，您不認為嗎？ 畢竟，我們要回復一堆廠商回應，顯示誰可以傳遞我們需要的所有功能。 實際上，到目前為止聽起來不錯，您不認為嗎？ 畢竟，我們要回復一堆廠商回應，顯示誰可以傳遞我們需要的所有功能。
但到目前為止，我所述的內容實際上有一個基本問題：當我們針對商品而非企業系統使用 RFP 程式時，不會發生問題。 這就是：企業系統是某種問題的解決方案。 但到目前為止，我們尚未就此問題進行任何說明。 這是一個常見的情況，因此技術產業會以正常且可接受的方式接受它。
為何選取該方式的企業軟體無法運作
購買者數十年來一直使用此方法，但沒有人對此提出疑問，但企業軟體企業中的人員知道選取企業軟體的傳統 RFP 方法有根本問題。
首先，只是因為您有很長的功能清單，不一定表示您更接近解決商務問題。 事實上，如果您甚至尚未清楚說明您嘗試解決的特定商務問題，您可能會讓事情變得更複雜，最後更糟，而不是更好。 RFP 程式的設計目的是要購買大量產品。 當我們有同質產品，例如鞋子、鞋子或油料時，以這種方式購買這些專案可能會產生最低成本的積存，以及可能供應商的最佳選擇。 對類似商品之 RFP 的回應，讓比較可能的供應商變得非常簡單。 當混合中每個產品的變數與企業軟體) 一樣是無限 (時，RFP 的回應也會有無限數目的變數，而進程會產生幾乎沒有價值的結果。
當我們使用 RFP 方法來選取企業系統時，RFP 看起來大致相同。 這是因為它們都是為了回應同一個異物而建立的。 專案經理會要求一份「您在此企業系統中需要的專案」的清單，而大多數中間經理唯一必須回應該要求的詞彙是功能清單。 因此，對 RSP 的回應看起來都一樣。 它們是系統中所有可用功能的檢查清單，或是系統中需要一些心力的一部分。
對於選取小組來說，最常見的是，他們會收到許多 RSP 回應，他們會在數百頁中四分五入，而且當它們完成時，他們感覺不會比起開始時更接近解決方案。 這對購買者而言非常令人挫折，他們投入大量心力來建立應該為提案的公平要求，以及評估答案，卻卻發現練習是要進行攔截的。
比起這一切，更糟的是，有經驗的企業銷售人員知道程式會產生令人挫折的結果，而且從他們聽到 RFP 建立的那一刻起即正在工作。 它們無法處理 RFP 回應。 這不相關。 相反地，他們會在管理結構中使用兩或三層以上的層級，尋找已啟動 RFP 的原始類別。 他們會尋找負責表達一些商務挑戰的資深主管，並設定移動中的滾輪，讓購買者和其他中間管理人員最終能夠建立 RFP 並將它傳送給廠商。
當 RFP 回應最終沒有清楚解答購買程式中幾乎永遠不會表達的商務問題時，企業銷售人員便已準備好採取行動，讓資深主管完全略過此程式，並根據自己與資深企業銷售人員的個人關係來選取系統。
如果您認為這聽起來很美化，則表示您不正確。 事實上，在執行層級透過個人關係選取軟體時，比透過 RFP 程式購買更適合使用軟體。
但概念證明或試驗呢？
因此，當我們將傳統購買程式套用至企業軟體的購買時，我們知道傳統購買程式是有缺陷的。 如果是這種情況，我們該如何選擇企業軟體，例如企業專案管理系統？ 熱門的方法是使用概念證明或試驗階段方法。
這兩個字詞通常會以同義方式使用，因此讓我們先討論什麼是概念證明或試驗部署。
概念證明。 在概念證明中，潛在組織會以有限的方式部署企業軟體，以證明它可以完成技術挑戰，而解決方案克服該挑戰的能力有一些問題。 例如，資料磁片區。 「我們擔心產品可能無法處理與每個專案一樣多的工作。 我們希望您隨附軟體、採用兩個或三個每個具有 500 個工作的範例專案，並示範如何將這些工作載入軟體，以及軟體仍然可以使用其中的這個磁片區來執行其基本功能。」
試驗階段。 試驗階段是企業軟體的安裝，但範圍有限。 試驗部署可能是針對使用者子集;例如，1000 人中只有 10 人會完整使用軟體四周。 或者，可能是功能的子區段或資料量的子集;例如，只會載入 500 個專案中的 10 個。
如何使用概念證明或試驗階段？ 經常遇到的問題是如何套用試驗階段或概念證明。 當潛在組織呼叫 並要求我們提出概念證明提案，而且也可以識別需要證明的技術概念時，這是相當罕見的情況。 「您希望證明什麼，以及我們該如何測量我們已證明？」我們提出要求。
最常見的是，中間管理人員已識別出一項企業軟體，希望能讓他們在組織中更輕鬆地生活。 資深管理完全不涉及，而仲介管理人員甚至尚未清楚說明他們嘗試克服的商務挑戰。 如果解決方案剛好在建築物中，希望下次管理人員在路由中四處走動時，他們會「不小心」看到解決方案運作中，並立即給予他們企業部署的抱負。 若要借用電影《星星》中的片語，請說：「如果我們建置的話，它們將會出現。」
它很少成功。 企業軟體的問題在於我們需要資深管理層的介入，才能成功部署。 這是資深管理人員，將會是來自此企業系統之報表和分析的「用戶端」。 這是資深管理層，需要個人投資，以允許員工在設計、設定及訓練企業軟體時所需的時間。 這是資深管理層，必須接受或甚至協助重新設計屬於任何企業系統部署一部分的商務程式。 如果沒有資深管理層不只提供其抱負，也不提供其隱含支援和直接協助，概念證明將不會有説明。
試驗階段也是如此。 如果公司尚未透過使用企業軟體，從最高層級致力於解決某些商務問題，則導入試驗階段並不具生產力。
這並不是說部署的試驗階段沒有位置。 它們確實在成功部署中具有重要位置。 該位置緊接在購買決策完成且企業系統設計完成之後。 現在，試驗階段是測試企業系統設計的絕佳位置，並針對一般部署進行微調。
當試驗階段完成，希望看到軟體運作時會導致管理選取它，那麼我們有不正確試驗，而且在選取程式中將不會進一步進行。
組織應如何選取企業軟體？
企業系統每天都由中型到大型組織購買，雖然 RFP 方法可能不是最有效的方法，但有數種方法可以選取非常有效的企業軟體。 以下是建立您自己有效企業選取程式的一些秘訣。
表達問題。 首先和最重要的一點是清楚說明問題。 這表示必須涉及資深管理，而要表達的問題是商務問題，因此應該以商務術語表達。 有一個不錯的問題是：「我們現在無法做出什麼商務決策，或者我們只能在非常困難時做出哪些業務決策，而可能因為此企業系統解決方案的部署而造成困難？」
使用此企業系統可能會有一系列您想要解決的商務挑戰。
為廠商提供一些建立解決方案的緯度。 一旦清楚說明商務問題，請連絡可能的廠商，並確定協助處理常式的資深管理層存取權是透明的。 當管理從頭開始是程式的一部分時，與資深管理的「秘密」廠商會議就變得不可能。 讓廠商瞭解問題，並為他們提供一些解答的緯度。 您可能會在說明這些商務挑戰如何影響您時，進一步瞭解貴組織，而當您不嘗試向潛在廠商描述解決方案時，您一定會看到更多可能問題的解決方案。
當您與可能的解決方案提供者交談時，請確定他們瞭解它們必須同時討論技術和商務程式挑戰。 從未有對組織流程沒有一些影響的企業系統解決方案。 如果解決方案提供者無法協助處理常式會如何受到影響，則您只會查看解決方案的一部分。
去見一些人。 當您前往幾個可能的解決方案提供者時，請要求與其一些現有的用戶端交談。 更棒的是，查看廠商是否會讓您造訪其一些現有的用戶端。 良好的解決方案提供者通常會有用戶端，這些用戶端在自己的部署中已成功，且他們有足夠的興趣，足以滿足潛在客戶端。
您在使用可能解決方案的有經驗的客戶時，會從幾個小時內深入瞭解，而不是從閱讀 RFP 回應或查看廠商銷售示範中學到的知識。 當您要求廠商提供可能的用戶端參考和網站流覽時，您可能會認為符合的理想公司會與您的公司完全一樣。 情況不一定如此。
與其他產業中相關或稍微類似于您的公司，通常非常有價值。 您也可以從比您大或小的組織學習很多。 請更加強調組織在解決方案上擁有多少體驗，而不是他們使用的版本，或者它們的大小確切，還是您所在的產業。
如果您很樂於造訪現有的用戶端，請記住它不是廠商。 尊重、尊重和感謝。 帶上小型的饋送，或許是公司標誌的促銷材料，通常很值得感謝。 當您在組織中或在電話上與參考交談時，一些可能的問題可能包括：
您使用哪一個程式來選取此解決方案而非其他解決方案？
此解決方案對您的商務程式有何影響？
部署最具挑戰性的層面為何？
到目前為止，最有價值的投資報酬率為何？
您如何看到解決方案從這裡發展？
不要只預期得到滿意的答案。
完全無法提供參考的廠商，必須比擁有一些滿意用戶端的廠商更具懷疑性。
最後，當您進行選擇時，請分階段部署。 您可以在本欄中找到關於如何在階段式與巨量模式中部署的其他文章。 這可降低任何企業系統部署所涉及的風險，並協助隨著系統演進而微調部署程式。
請記住，任何企業系統部署都是動態程式。 這不是一次性決策，且結果會逐月永久抵達。 最成功的企業部署會從選取專案開始，其中包含關鍵人員，這些人員將參與從管理中最資深到領域中最具戰術性的部署程式，並在階段後分階段繼續進行系統的演進。
有效的企業系統選取只是程式的第一個階段。
關於作者
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) 。