入行前三年，有一个ERP项目经验，回想起来还是印象深刻。之所以深刻，不是因为它的美丽，而是因为它的痛苦。

———— / BEGIN / ————

我的职业流程有三个关键阶段。第一阶段是做大企业的数字化项目，主要关注供应链解决方案。这里要分享的项目经验，也就是那个阶段要经历的事情。

初生牛犊不怕虎，这句话很有道理。

刚进入这个行业的前两年，我以为自己学到了很多这个行业的知识和技能，所以有一种年轻人无所畏惧，觉得做什么项目都不容易。现在回想起来，只能感叹自己还是太年轻了。

正是因为当时的盲目自信，我被现实狠狠打了一顿。这是一个热门的数字项目，对应的企业是一家上市公司。中国40多个城市有近1000家直营店，整体规模相当大。

整个项目背景是当时O2O电子商务(即Online在线商店Offline在线消费)发展迅速，需要打通品牌下的所有门店和加盟商，实现在线电子商务平台和采购、生产、销售、仓储、财务的一体化管理。

从本质上讲，这是两件事:电子商务平台和ERP，当时被广泛称为ERP项目。虽然是ERP项目，但并不纯粹。这是因为这家公司实际上已经推出了一套ERP，使用了用友U8，那么为什么要推出一个新的ERP项目呢？这是由于他们行业的特殊性和电子商务平台的需求，U8中的材料、组织结构等信息已经不能满足这些新的商业场景。

再加上之前花了很多人力物力去上U8，企业主也不想完全抛弃这套东西，所以建议保留U8的财务会计功能，重新搭建电商平台、主数据、采购、生产、销售、仓储等财务模块之外的系统。

因此，从系统层面分析，涉及到电子商务平台与主数据、仓储和销售模块的对接。原始凭证和库存核算在整个生产、供销过程中与用户U8对接。

说到这里，你听大了吗？当时也是这样。团队中的许多人不愿意接受这个清单。最后，这个项目落在了我和另外两个老大哥手里，其余的开发实施者都是项目经理领导的。然后我们三个小团队也有自己的分工。其中一个老大哥和我负责业务调研、分析和解决方案，另一个做详细的设计文档输出，对接开发实施团队。

于是一个草台团队建立起来了。我还记得第一天去客户现场的场景。有三个业务负责人和我们对接，一个负责电子商务，两个负责ERP。电商负责人的态度是创新，不破不立。ERP负责人提倡小步慢走，或者躺着不动。

所以当时会议室里充满了火药的味道。那时候我不知道怎么化解这样的矛盾，这也为以后的工作埋下了艰难的种子。

记得第一天在业务现场调研的时候，感受到了电商业务负责人和ERP负责人之间强烈的火药味。于是我们开始了单独行动的策略，周一周三谈电商业务，周二周四谈ERP，真的避免了他们之间的纠纷。

一个月后，我们对整个项目的范围和边界进行了7788的调查。最初的计划是将电子商务平台和ERP一起上线，以避免后期计划变化导致的在线问题。但是电商平台负责人不知道有没有KPI压力，要求三个月内上线电商平台。双方高层领导经过多轮沟通失败，卑微的乙方只能调整重心，先实施电商平台建设。

这里有一些故事，讲述了一个令人印象深刻的细节。一些读者可能知道，在电子商务平台上，有SPU和SKU的商品管理概念。例如，如果一辆车是白色和黑色的，那么在电子商务系统中，它通常只维护一个商品代码，然后有两个规格属性。然而，在ERP中，这种情况通常维护两种材料代码，以便于拆解成本核算和生产计划。

当时我也和客户沟通了后续可能带来的风险，但是客户不听劝告，所以一定要按照电商的标准去做。只是为了满足用户前端可以在同一个产品下选择不同的属性。时间紧，任务重，不能想那么多，只好按照甲方的意思去做。幸运的是，在过去的两个月里，一个电子商务平台V1.0，融入了很多甲方的想法。.0版上线了。

接下来的重点是ERP。正如我前面所说，ERP负责人和电子商务负责人在调查的第一天就有分歧。对于ERP材料主数据的维护，ERP负责人坚决根据属性单独维护材料，长期规划只维护ERP中的材料主数据，其他系统从ERP中获取数据。原因是这样的，我们无法反驳，但是当时做电商平台的时候，电商负责人可以坚持维护一个SPU，这是矛盾的。

如果没有办法改变双方的想法，那么我们只能改变方向，用技术改变空间和系统。以ERP维护材料为最小SKU，然后在电商平台进行二次包装操作，相当于聚合成SPU产品，呈现多种属性。

当时这场风暴是用技术解决的，但是不管真的合理不合理，都是个问号。在接下来的一两个月里，这些问题继续来回沟通、妥协和修改。项目组可以用水深火热来形容，大家都很累。

终于ERP V1.0.0版本计划在一个月底上线，这是另一场硬仗。之所以选择月底，是因为ERP需要在上线前制作初始财务数据。这时，埋在我们面前的雷声开始爆炸，电子商务平台在ERP上线之前就开始了销售业务。此外，上述商品和材料之间的复杂关系使得这些数据的销售成本核算极其困难。最后，经过线上线下数据的清理和分析，我们花了两天时间计算出一个相似的值，以结束这个关键的里程碑。

伴随着电子商务和ERP V1.0.0版本上线后，我和前面提到的两位老大哥退出了这个项目组，算是脱离了苦海。现在回想起来，真的是一言难尽，只能说当时给了我一个很辛苦的教训。

这个项目的整个过程给了我太多的经验和教训。如果一些方法和环节得到适当的控制，进度可能会更顺利，更不用说有多顺利，但也不会那么痛苦。

总而言之，大概有几个方面。

首先是项目入场环节。当时开门见山，直接开始了研究工作。不知道方向不对，努力白费，跑得快也是徒劳。最大的错误是甲方的关键关系人还没有确定，也叫最高领导。它需要能够平衡电子商务负责人和ERP负责人之间的利益和冲突，发挥关键决策权。

这样就可以避免两个负责人之间的意见冲突完全由乙方团队平衡的问题，被双方牵着走，简直是吃力不讨好。最后双方各持己见，系统只能两边迁就，乱搞。

这种迁就导致了下一个问题，那就是失去了原则。反复向甲方妥协，扭曲了注重标准化、结构化、系统化的数字软件工具。这件事教会了我坚持原则。做正确的事情很难，但困难不是我不做正确事情的原因。

如果ERP不仅仅是为了面子工程，那么在这么大的项目中，摆事实讲道理是非常重要的。因为企业要做管理咨询，无非是长期生病而不自知或自知，无法自治。当医生看、听、问、切开处方时，患者很难治愈他认为正确的药物，而不是按照处方煎药。医生是坚持原则的人。

有了解决方案之后，但是在实施过程中，反复修改，这也是当时面临的另一个大问题。众所周知，尤其是软件系统的建设，调整过程和结构是多么痛苦，就像炒番茄蛋，吃青椒蛋。

关于如何解决这个问题，是德勤公司后来与四大会计师事务所之一合作的500强企业ERP项目中找到的答案，然后详细分享我在这个项目中的故事。在这里，我们只谈谈如何处理这个项目的变更方案。

当时项目上划分了几个关键里程碑，包括项目调研、蓝图设计、详细设计、项目实施、验收培训等。双方审核后，每个环节产生的交付物都需要企业的关键用户和最高领导签字盖章确认。只有在下一步工作实施清楚后，这样做的目的才能从过程中控制甲方变更方案的风险。

最终是多系统交互，当时数据流动处于混乱状态，导致系统建设甚至后续甲方运维工作都非常不方便。