成為解決方案型買方
本文是「從馬西斯」集合的一部分。 其中說明潛在軟體購買者如何套用容易瞭解的商務分析方法，讓與軟體廠商的互動更有效率。 它會逐步引導您整個過程，透過有效判斷軟體解決方案需要解決的各種問題，建立一套軟體評估準則。
若要查看更多文章，請參閱 白皮書。
身為解決方案購買者
軟體購買通常會以功能、廣告行銷活動或朋友的建議清單為基礎。 本文說明潛在軟體購買者如何套用容易瞭解的商務分析方法，讓與軟體廠商的互動更有效率。
它確實不像以前一樣。 讓軟體在企業設定中運作甚至不再稱為安裝。 現在，實作或部署一詞更能描述啟動和執行新套件所需的專案。
越來越多的軟體廠商正在談論他們銷售的解決方案，這並不想知道。 當我們考慮部署 Microsoft Project Server 或 Microsoft CRM 等企業系統時，我們必須先思考將涉及的不同技術層級，甚至在我們達到此需求之前，我們必須考慮對整體業務的影響。
當然，要銷售的解決方案是解決方案銷售。 如果您已完全遵循此動作，您知道地球上幾乎所有以中大型組織為目標的高技術組織，都致力於將自己重新建立為解決方案銷售交付者。 Microsoft 當然在這些組織中。 Microsoft 在過去幾年中廣泛致力於建立解決方案銷售，作為其現場銷售和實作力的指導原則。
那麼，什麼是解決方案銷售人員？ 的確，他們仍然是銷售人員。 不過，解決方案銷售人員的目的不只是移動一盒軟體，還是為了建置可協助用戶端改善其情況的專案。
到目前為止聽起來很棒;銷售人員的 Nirvana 都想要改善您的生活量。 但這的確會帶來挑戰，而解決該挑戰是您作為潛在客戶可以參與的一項挑戰。
將焦點放在問題
大多數解決方案銷售人員在進入市場時所面臨的挑戰，是我們對於解決方案外觀的先知。 我們正習慣著重于軟體的功能和功能，當我們與軟體銷售人員交談時，交談幾乎無可避免直接導致：「您的軟體可以這麼做嗎？ 您的軟體可以這麼做嗎？」有經驗的軟體銷售人員，以及那些被移至解決方案銷售位置的類型，經常用來銷售函式和功能，他們經常忘記詢問最基本的問題：「問題為何？」
現在這聽起來可能有點難過，但如果您想過最近幾個與軟體銷售人員的交談，您可能會對這個問題很少出現感到意外。 Microsoft 及其合作夥伴等廠商每年都會收到許多提案要求。 多年來我已看過數百個函式，其中一個幾乎一律存在的是廠商預期要填入的長方格函式。 這個大型試算表通常是回復用戶端的核心。
很少出現的是每個函式將解決的商務需求描述。 在先前產品中熟悉的功能，或是我們已在某處獲得提升，因此我們已獲得真正的專業領域，以專注于我們最初對此新產品感興趣的內容，這非常容易。 這在企業設定中尤其如此，因為在企業設定中，會對所要尋求的解決方案類型進行大量輸入。 傳送要求要求，要求人員列出他們想要在新的軟體系統中使用的所有功能，比談論其特定商務需求更為容易。
如果您開始認為您可能遺漏了一些明顯的問題，您並不單獨。 此條件在軟體產業中非常普遍，因此，一個稱為商務分析師的新顧問類別已顯現。 這些人員經過訓練，能夠從商務需求與軟體功能建立連線。 讓我們花幾分鐘的時間來瞭解如何在企業層級軟體評估中套用基本概念，以商務分析師套用這些概念的方式。
識別商務需求
首先要考慮的是企業需要什麼，讓您一開始就尋找新的軟體系統。 我們自己的組織通常會洽詢公司實作企業專案管理軟體。 當我以顧問身分抵達組織時，在討論是否要購買軟體之前，我就會詢問組織目前如何進行專案管理。
當他們完成回答時，我一律會詢問這個後續問題：「該方法是否適用于您？」令人驚奇的是，用戶端通常會回答它。 對我而言，實作交談必須就此處停止。 「如果沒有任何問題」，我解釋「我無法制作解決方案！」此答案通常會讓人員暫停。 「為什麼我們呼叫了？」我會問。 答案可能會有很大的差異，人們環顧會議室併發現有數個必須協調的議程，而我們的交談還不到五分鐘！
因此，詢問「我們的業務需求是什麼？」是很好的起點。 幾乎一律有一個整體目標可回答這個問題，這是一個一開始就快速啟動計畫的目標。
進行視覺練習
接下來，您必須深入瞭解這對於軟體功能的意義。 當我們將 Microsoft Project Server 之類的企業專案管理軟體實作到組織時，我們一律會從一個視覺練習開始，其中包含負責評估軟體的關鍵人員，以及負責贊助此練習的資深管理人員。 只與技術人員一起進行此練習並不夠，因為本練習的目標是要將商務目標與技術功能連線。
以下是有效的做法：將重要人員放入具有大白板的會議室。 將白板分成 4 欄：從最右側資料行的標題開始。 將其稱為「商務決策」。
在正確的資料行中，您將列出您希望使用您要考慮的新系統來制定的商務決策。 當我們使用用戶端來執行這項操作時，第一件事就是列出許多功能，因此您必須確定重要的答案是商務決策。 例如，參與者可能會立即說出「我需要所有資源及其工作負載的清單」。當然，這可能成立，但您需要瞭解的是，他們會在該清單中做出哪些商務決策。
商務決策的一些範例可能是：
在特定部門中雇用或引發
對專案進行執行或不執行決策
一旦您有一份不錯的商務決策清單，請暫停。 現在是檢閱商務決策清單並找出最高優先順序決策的好時機。 您可能想要詢問自己這個問題：如果您只能取得其中一個商務決策的答案，這會為組織帶來最大價值？ 在此程式中，挑選前三個決策一律最簡單。
如果您已完成此作業，您已完成比大部分尋求企業專案管理軟體的組織還多的作業。 能夠為系統廠商提供最重要商務決策的優先順序清單，是整個程式的一大步。 當您可以告訴系統廠商您需要做出哪些商務決策時，他們能夠超越討論簡單功能，來討論如何讓組織更有效率。
接下來，查看每個決策，然後詢問：「若要做出商務決策，您需要哪份報表？」在查看一或多個報表之後，幾乎都會做出每個決策。 將第三欄標示為「報表」。針對前三個決策中的每一個，列出該資料行中對應決策所需的報告。
例如，我們可能會說，若要判斷是否要雇用或引發特定部門的人員，我們需要依部門顯示資源容量規劃資料的報告。 這包括預期工作負載的向前預測、預期的資源可用性和排程。 如果您是中型企業，現金流量可能也是一個問題。 例如，您可能需要額外的人員，但找不到要雇用的現金。 現金流量報告會包含預估收入，以及具有執行中餘額的貨幣外流。
如果我們針對每個已識別為優先順序的決策填入 [報表] 資料行，我們所需的圖形就會開始變得清晰。 完成之後，您就會從預期的系統取得所需的實體輸出清單。
再次暫停這裡，以瞭解組織中是否有您已識別出正在使用的類型報告。 這類報表可能會存在，但格式很多，而且可能具有不完整的資料，或需要太多心力來產生它們。 如果您發現已在組織中運作的報表格式，您可以將這些格式新增至系統需求清單。 現在您可以提供更多資訊給系統廠商。
現在已識別出重要報表，我們可以移至產生這些報告所需的系統元素。 將標題 「Analysis」 新增至圖表的第 2 欄。 針對每個報表，識別產生報表所需的分析或演算法。 例如，針對資源容量規劃報告，我們可能需要專案管理系統的重要路徑排程和資源撫平分析。
這些分析通常會由廠商根據各包含的各項功能進行行銷。 (是，逐一銷售功能仍能正常運作！) 您需要判斷的功能最少，可提供您需要的報表，然後再做出或改善您已識別的商務決策。 您可能會對滿足實際商務需求所需的功能有何基本性感到意外。 對於某些報表，完全不需要分析或計算;報表只需要簡單匯總，即可直接從新系統的資料產生。
最後，我們來到圖表中的第一個資料行。 識別出所需的分析之後，您可以移至判斷需要哪些資料元素來饋送分析。
將標題 「Input」 新增至圖表的第 1 欄。
在我們一直在使用的範例中，我們可能需要一份完整的工作清單，以供部門工作中隱含的每個專案使用。 這很可能是組織中的每個專案。 我們也需要每個資源可用性的完整設定檔，以及在每個工作上定義的工作負載，如此一來，當工作在排程分析中移動時，工作負載就會在資源撫平分析中移動。 此外，還記得我們如何從在特定部門中雇用或引發決策開始？ 我們也必須能夠依部門識別資源。
我們可以像這樣從右邊的輸出移至左邊的輸入，直到我們識別出新企業系統中所需的一切為止。
評估風險
完成此練習之後，最好回到每個輸入，並判斷這些資料元素的可用性。 如我們經常發現，其中有些專案甚至不存在。 例如，某些組織不會維護完整的資源可用性清單。 您可能也會發現並非每個專案都有資源載入排程，顯示該專案所產生的資源負載。 在許多組織中，特定類型的專案不會放入任何類型的系統中。 緊急工作、技術支援工作或定期維護工作是一些常見的範例。
如果您無法存取傳遞商業價值所需的基本資料，您必須將系統的該元素視為高風險。 例如，如果我們發現可以識別 80% 組織專案資源載入的排程，我們是否可以合理地預期改善業務決策來增加或減少員工？ 答案可能是「否」。為什麼？ 因為可能 20% 的專案不在系統中，可能代表特定部門 80% 的工作負載。 如果您沒有所有資料，就永遠不會知道最終報表是否正確。
當然，有一些方法可以解決這類問題。 其中一個方法是隔離組織這些層面的所有商務程式，您無法在其中存取資料元素。 專案可能不在系統中的部門也不會列出其資源。 這不能只在每個案例中完成;您必須逐一查看，以瞭解這些商務程式和商務決策對您的實作有何風險。 此時，重新設定您希望改善之最終商務決策的優先順序並不常見。 您可能會有一個非常理想的決策，但結果卻是非常高風險，因此不值得在部署的早期階段中追求。
記錄您已完成的動作
當您進行這種會議時，請指派一個寫入者，指派其作業會在整個程式中記錄筆記和批註的人員。 將特定商務決策列為高或低優先順序的原因，或如果您沒有要參考的好記事，將會快速忘記某些被視為高風險的原因。
請務必記錄：
您在白板上撰寫的內容
參與此程式的人員
誰擁有每個最終商務決策
如果您此時感到不知所措，請不要擔心。 這整個練習可以非常快速地完成，即使在最大的組織中也一樣。 能夠在一天或兩天內完成整個程式並不常見。 成功的關鍵在於在會議室中取得正確的管理層級。 此外，這種類型的會議最適合由組織外部的人員協助，但不會以他們一直以來的方式進行動作。
知識是強大的
如果您正在查看企業專案管理系統—事實上，在任何類型的企業系統上—完成此練習可在您與軟體系統廠商互動時提供極大的能力。 您可以立即區分對您而言重要的系統元素，以及不重要的專案。 軟體廠商可以提供您想要進行的報告和決策清單。
您可能會對廠商傳回的一些回應感到意外。 釋出以不同于逐功能的方式回應，也就是嘗試將平方函式納入四捨五入的需求中，更好的廠商將能夠示範如何使用其系統來因應業務挑戰，以獲得最佳優勢。
以下是進行此練習的最大優點：您已建立現成的評估準則。 現在，在概念證明階段，您可以立即專注于系統是否提供改善您必須進行之商務決策所需的資訊。
關於作者
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) 。