前面在这篇《一个IT人的，ERP学习之路》文章中，讲过我的职业过程有三个关键阶段，第一个阶段就是做大型企业的数字化项目，主要侧重供应链方面的解决方案。这里要分享的项目经历，也就是在那个阶段中所经历的事儿。

初生牛犊不怕虎，这句话讲得非常有道理。刚入行的头两年，我自认为学习了这个行业的很多知识和技能，所以有一种年轻人的无所畏惧，觉得什么项目做起来那不都是手到擒来。现在回想起来，只能感叹还是太年轻了。

正是由于那时的盲目自信，被现实狠狠地打脸。那是一个烫手的数字化项目，对应企业是一家上市公司，在全国40余座城市中有近1000家直营门店，整体体量还算是挺大。

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

从本质讲这是电商平台和ERP两件事儿，当时就广义的称之为ERP项目。虽说是ERP项目，但是它又不纯粹。这是由于这家企业其实已经上了一套ERP，用的是用友U8这个产品，那么为啥又要新起一个ERP项目，这是由于它们这个行业的特殊性，和电商平台的诉求，导致U8中的物料、组织架构等信息已经无法满足这些新的业务场景。

再加上之前为了上U8，花费了不少的人力物力，企业的老板们不想要完全摒弃这一套东西，于是就提议要保留U8的财务核算功能，重新去打造财务模块之外的电商平台、主数据、采购、生产、销售和仓储的系统。

所以从系统层面来分析，就涉及到电商平台与主数据、仓储、销售模块对接。整个产供销过程中产生的原始凭证和存货核算再与用友U8对接。

讲到这里，是不是头都听大了。当时也是这个情况，团队中很多人都不愿意去接这个单子，最后这个项目落到了我和另外两位老大哥的手上，其余开发实施人员由项目经理领导。那我们三人小团队也各有分工，其中一位老大哥和我负责业务调研、分析和出解决方案，另一位则做详细设计文档输出，对接开发实施团队。

于是一个草台班子就搭建起来了，我还记得第一天去客户现场的场景，和我们对接的业务负责人有三位，一位负责电商，两位负责ERP。电商负责人的态度是推陈出新，不破不立。ERP负责人则主张小步慢走，或卧倒不动。

所以当时在会议室就充满了浓烈的火药味儿，那时的我哪知道如何化解这样的矛盾，这也为后面的工作推进埋下了艰难的种子。

因为第一天在业务现场调研，就感受到了电商业务负责人和ERP负责人之间浓烈的火药味儿。于是我们后面就展开了分头行动的策略，周一周三聊电商业务，周二周四聊ERP，如此一来，确实避开了他们之间的争执。

一个月下来，我们把整个项目的范围和边界调研的七七八八，原本计划是电商平台和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项目中找到了答案，后面再去详细分享我在这个项目中的故事。这里只聊一下这个项目是如何处理方案变更问题的。

当时，在项目上划分了几个关键里程碑，就有项目调研、蓝图设计、详细设计、项目实施、验收培训这几大环节。在每一个环节产生的交付物经过双方评审后，均需要企业的关键用户和一把手签字盖章确认。只有落实清楚再开展下一步工作，这样做的目的就从流程上控制了甲方变更方案的风险。

最后就是多系统交互，当时的数据流向呈现混乱状态，导致系统建设乃至后续甲方运维工作都很不便利。这让我明白系统搭建之初，对系统上下游的界定、系统的优先级层次、数据结构、传导方式等的提前确定有多重要，为后续实施阶段起到关键避坑作用。

以上就是感悟最深的几个点，故事就分享到这里。

【转】https://mp.weixin.qq.com/s/1hI5INxwNUEHdYOR0mj5Mw