摘要：企業在選擇云系統時，尤其如此。云系統中的每個因素都與公司成長模式有關。成本蠕變成本蠕變或許是最普遍也是最容易被負責人忽略的，對云系統的產生的影響也是更為負面的。如果你選擇的云服務組合是正確的，云系統的擴張就應該是順其自然的。

一、在選擇過程中忽略重要的云屬性

企業在購買整合系統時要面對一系列的挑戰性，除了要理解公司行為方式和原因以外，還需要有考慮到其他因素。如果忽略了某個流程或要求，那么在這個步驟沒有發生問題時系統可以順利運行，一旦出現問題就會產生負面影響。

企業在選擇云 ERP 系統時，尤其如此。ERP 系統的處理流程是永久性的，活躍的處理鏈每一天都要不停地輸入存貨清單、輸出 AP，還要對信息進行分析?？上o論多小心，由于多種原因，公司在選擇 ERP 系統時還是會犯錯，所以在鑄成大錯之前，一定要好好思考下面這些潛在的問題。

可擴展性

要成功實施云 ERP，很大程度上需要依賴公司的數據粒度（data granularity），以及計劃實施的速度。

我們需要關心的問題很多也很有深度。云 ERP 系統中的每個因素都與公司成長模式有關。如果你購買的系統不能靈活地應對業務擴張，就很可能會影響到公司的發展。在公司的運營過程中，云 ERP 的一大優勢是其固有的可擴展性，所以在這方面你就更加不能犯一點錯誤。

速度

對于那些只使用一或兩個云 ERP 模型的小型企業來說，或許不必將數據的輸出速度視為一種挑戰。但是隨著公司的發展，他們要從接收原始數據開始，不斷地完善自己的流程鏈，因此有效信息的傳遞就會變得非常重要。但是 ERP 系統或許無法靈活應對這種迅速的發展，同樣，其也無法適應全部數據在云端和公司之間的傳遞。

復雜性

所有云 ERP 系統都非常復雜，其復雜性取決于合作客戶何時、何地、如何對信息進行傳遞和管理。如果你的公司選擇了一款很容易使用的云 ERP，隨著公司規模的逐漸擴大，系統就無法提供足夠的功能。

可靠性

企業系統的可靠性決定了其使用效果，ERP 系統尤其如此。其中的原因很簡單，ERP 系統和其操作原理可以提供很大的知識價值，公司會依靠一個或多個云 ERP 模塊為其提供信息。但是如果在云 ERP 的停工期，公司突然發現自己錯失了關鍵性信息，業務鏈就會被破壞，并且會損害必要的周期性收益，甚至造成更壞的影響。

二、無法正確計算 TCO（總體擁有成本）

在使用云 ERP 系統的過程中，無法完全理解 TCO 會影響公司的償付能力。如果一家公司不理解或不關注云 ERP 的 TCO 帶來的成本壓力，就很可能會損失一定的資金，而且到年底核算時才會發現。

云 EPR 合同條款和條件可能包括很多不夠明顯的財務成本，在企業中很容易被忽視。如果使用云 ERP，企業的管理費用也會增加，一些企業很難負擔得起每個月的費用。項目經理甚至可能會一想到云 ERP 的 TCO 所需的成本就會徹夜難眠。

直接影響

在 ERP 的所有成本中，位于成本食物鏈的頂端的 TCO 是最明顯的也最難處理的。所以一直以來，由于實在是過于明顯，TCO 通常是通過估計而非細致的計算得出的。

如果你的云項目的操作基礎是傳統 EULA（最終用戶許可協議），負責人很難去花時間仔細閱讀并完全理解一份印刷精美的云安裝協議。當產品很有效時，很多人也不會去關注系統供應商定期發布的關于增加成本的通知。也就是說，即使 TCO 每年增長四次，負責人也未必會知道。

間接影響

另一種云 ERP 的 TCO 也值得一提，即支撐和提高云 ERP 效率所需的成本，因為云 ERP 的服務協議是「統一定價」的，這些成本就經常會被忽略。

以基礎架構成本為例，很多負責人都無法準確計算出完善本地基礎架構所需的成本，如在計算 TCO 時，需要考慮到有線及無線結構的擴建、路徑的擴張以及網關矩陣。

其實這是一個很簡單的問題，要看上述那些擴張成本與 ERP 是否有關，如果有關，以上成本就應該計入到 ERP 的 TOC 中，無論是否與云平臺本身有關，企業管理者應該確保自己能夠知道企業的資金流向了哪里。

附加影響

就像間接系統成本會影響云 ERP 的 TOC 那樣，附加的技術因素也會產生相似的影響。在基礎架構內部的每個角落都會產生這種成本，包括云、SaaS 部件、企業硬件、本地化軟件或是安全或低級使用系統等中間件。同樣，如果這些項目屬于 ERP 項目，就應該被計入云 ERP 的 TOC 中。

成本蠕變（Cost Creep）

成本蠕變或許是最普遍也是最容易被負責人忽略的 TCO，對云 ERP 系統的 TCO 產生的影響也是更為負面的。原因之一是，大多數 SaaS 成本都非常微小，或許每次只需支付 1-10 美元。與那些更重要的成本比起來，這些完全不值一提，但是卻真的可能為負責人的決策造成困難。

三、忽略云 ERP 的網絡連接情況

使用本地部署系統時需要關注網絡連接和可用寬帶的問題，使用云 ERP 時當然也是如此，由于這些系統在完成工作時完全依賴外部處理，系統的每一點改進都會對 ERP 的聯網提出新的要求，所以在完善系統時，預算也應該同時提高。

發布前及上線處理

產品在發布前對寬帶的要求是較低的，而且是周期性的。在這個階段，首要目標是提高由產品整體能力決定的可依賴性，而不是 ERP 的事務處理能力。

所以 ERP 的規劃要非常謹慎，無論何時，風險管理人員都要擦亮雙眼，確保云 ERP 系統能夠持續運作。

但是一旦結束了發布前階段，企業就要準備上線了，此時強大的寬帶就變得非常重要。可惜很多 ERP 項目的負責人都忽略了這一點，所以 ERP 的上線才不那么順利，進而花費會超出預算，產生更多額外的困難。

寬帶需求預測

一旦企業系統，尤其是云 ERP 系統開始全力運作，寬帶就會變得非常重要，多數網絡連接合同提供的報價不止一種，只要流量能夠維持在一定范圍內就可以。但是企業一旦未能準確預測自己的聯網需求，超出部分的流量費用也是很巨大的，企業的支出也會因此大大超出預期。

為解決這個問題，企業可以簽訂多年的寬帶合同。首先服務供應商會為一次性支付多年費用的企業提供一定折扣。在進行協商的時候需要一次性考慮到公司幾年內需要的寬帶情況。

這些都需要對 ERP 有嚴謹的規劃，需要風險管理人員擦亮雙眼確保 ERP 系統的運作。也需要定期測量及進行操作測試，否則公司的云 ERP 聯網能力會制約 ERP 功能的發揮。

四、未能選擇恰當的服務組合

現在的云 ERP 供應商為了確保產品的發布、運營和維護都能實現較高水平，會提供各種不同等級的服務。但是就像規模問題會對 ERP 實施造成困難一樣，云 ERP 服務等級的問題也會導致收入的損失或是額外的運營成本。

要更好地理解當前的云服務等級，可以閱讀以下現在市場總體上接受的觀點。

云 ERP 服務組合的選擇

協議有以下幾個特點：商務分析、運營評定、系統購買研究及評估和端對端路線圖開發。下一步發展將包含「核心整合」組合，這類組合會更加技術性、以開發為導向，操作任務包括端對端數據繪圖、企業平臺識別、分析及遷移、運營實施、企業上線、模塊及附屬系統整合、發布前測試及 QA、支持及維護以及定期更新。

一旦開始運行云 ERP，就可以使用服務組合，主要包括供應商托管、定制化開發、BPO 分析、大數據以及移動化整合。

在每個案例中，云 ERP 的規模和復雜性在公司的成本管理和運營決策中起到了很重要的作用。如果做出了錯誤的選擇，你就需要花更多錢了。

決定如何實施服務組合

在發布階段，如果你購買了云 ERP 服務組合，就應該明白 ERP 系統的可行性就取決于你企業的情況。所以如果你經營的是一家小型商店，技術資源有限，就一定要進行事前分析，否則在之后的經營中會增加很多成本。

中級云 ERP 服務組合中，包括大部分發布前和發布后測試以及起始要素，但是組合成本與服務的深度有關。一旦系統變成熟，擁有了密集的數據，并從每日的使用過程中總結出了操作特點，系統的可擴展性和服務組合就會非常關鍵。

制定更好的計劃

長期使用 ERP 系統有利于制定更好的計劃，并從中產生更多機會，幾乎在所有案例中都是如此。計劃的最后一個階段應該涉及到企業如何有效經營。

如果你選擇的云 ERP 服務組合是正確的，云系統的擴張就應該是順其自然的。但是如果你沒有認真挑選云 ERP，那么你的成本或許會遠超出想象。

五、未能開發出修復計劃

ERP 錯誤修復系統是指在系統出現問題時運行的一系列任務。制定計劃時可以依據一些有效的基本計劃，每家企業和每個 ERP 系統的實施都是有所不同的，所以在制定計劃時需要客觀地進行思考。制定了失敗的計劃或是沒有仔細制定，都會造成收入的損失，因為你需要去思考自己究竟要做什么。

在可能發生錯誤時，需要首先做好最壞的打算，然后再采取以下措施：

確定威脅類型

確定你的 ERP 系統可能出現的較大問題是什么，比如系統完全掉線，但是產品必須要繼續運行；然后運行各種任務恢復運行，再重新加載數據。之后再運行一些從屬的功能，如發票和會計，以及其他各管理系統。

這如我所說，每家企業都是不同的，所以在你的公司最重要的或許是發票功能。在決定各功能排序時，要認真思考之后確定自己做出的決定是否正確，否則你就要浪費時間在錯誤的事情上。

建立失敗樹

這是很實用的，上文提到的那些問題，我們有必要建立一個錯誤修復樹。大體上，公司應該遵從以下步驟：

確定交流計劃

確定問題發生時應該聯系的人，列出名單

以各類資源為基礎，針對對問題的回應創建指導。

針對每個人所負責的修復領域作出說明。

針對每個方案列出特定任務清單

確保負責的經歷和員工對每個人物/領域進行檢驗，并對每個清單都達成共識。

盡可能詳細

大多數 ERP 失敗都需要一個修復過程，所以說時間就是敵人。所以上述失敗樹應該盡可能地詳細，確定一切相關過程/系統/人員，一起每個人在此任務中應該做什么。

建立實用的反饋列表

此部分是修復計劃的核心，因為系統無法在沒有人的情況下實現自我修復。在 ERP 系統處于崩潰和安全之間時，較好的辦法就是確保通知到了團隊中的每個人。如果你認為一名員工應該在列表上，就要多檢查應答列表幾次，并定期檢查列表，確保相關性和準確性。

部隊在穿越危險的海峽時相信的很多格言都非常有用，我最喜歡的一句就是「想在戰斗一樣訓練自己」，意思是說，以防萬一，你應該不斷測試自己的修復系統，從中可以取得巨大的進步并且收獲到實用的知識。

首先，對一個或更多緊急方案進行測試時，ERP 團隊面對任務清單時會變得冷靜，在真正發生問題時應對就會更加及時。

第二，就像我住在南方的子孫說得那樣，團隊需要一個能力，就是在事情發生前就忘記恐懼，在巨大的壓力下冷靜決策。

軟件開發技術群

興趣范圍包括：Java，C/C++，Python，PHP，Ruby，shell等各種語言開發經驗交流，各種框架使用，外包項目機會，學習、培訓、跳槽等交流

QQ群：26931708

Hadoop源代碼研究群

興趣范圍包括：Hadoop源代碼解讀，改進，優化，分布式系統場景定制，與Hadoop有關的各種開源項目，總之就是玩轉Hadoop

QQ群：288410967?