选型云ERP中五个不能忽视的问题

摘要：企业在选择云系统时，尤其如此。云系统中的每个因素都与公司成长模式有关。成本蠕变成本蠕变或许是最普遍也是最容易被负责人忽略的，对云系统的产生的影响也是更为负面的。如果你选择的云服务组合是正确的，云系统的扩张就应该是顺其自然的。

一、在选择过程中忽略重要的云属性

企业在购买整合系统时要面对一系列的挑战性，除了要理解公司行为方式和原因以外，还需要有考虑到其他因素。如果忽略了某个流程或要求，那么在这个步骤没有发生问题时系统可以顺利运行，一旦出现问题就会产生负面影响。

企业在选择云 ERP 系统时，尤其如此。ERP 系统的处理流程是永久性的，活跃的处理链每一天都要不停地输入存货清单、输出 AP，还要对信息进行分析。可惜无论多小心，由于多种原因，公司在选择 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