编码规则——软件实施的根中之根！

一直自认为对“编码原则”，特别是“物料编码原则”知之甚多，也自以为对编码原则把控苛刻至极。甚至在许多项目和许多会议中，我都反复强调：一个ERP项目，什么都可以重来，但物料编码不能重来。并且还讲到自己不做的项目条件之一就有物料编码原则的问题。

但没有想到，有次，我差点阴沟翻船，而且还真恰恰出现在了物料编码原则上。也差点把人郁闷回到老家。简直就是老马失足的典型。

我接手那个的项目之前，曾为编码原则到客户那去过二次。一次是定编码原则，一次是确认编码原则和试编。记得当时我还跟以前的项目同事确认编码原则讨论和试编时、他没有执行我还跟他吵过一次。

我再接手时，客户BOM都编了一段时间。所以，我也没有再过问物料编码原则一事。大家开始各职其责的进行准备工作。客户做BOM，我们准备技术方案及期初。

其实，隐患就埋下了。后来，真正问题是出现在了这里。这一关没有重头再过一遍，一放行就如放水。害得自己花了一周时间来挽转局势。

接手不到一个月就到了七一，就开始上线。上线没二天，所有ERP使用部门开始沸腾了，找不到物料编码，找到了也大面积的错误。

整个现状差点失控。各部门反映：ERP中的物料叫法他们不知道是什么东西，他们的物料在ERP中找不到相应的名称、规格，所以，没办法做了；没办法做了，就做不了。做不了，ERP还有得玩吗？于是，我们不得已专门将客户以前叫法的物料编码并导入了ERP。

可是，业务部门能做了，但是，先前的物料编码与新导的物料编码就成了一物多码。业务部门要保留后导入的物料编码，但先前编码肯定不愿意，毕竟BOM的录入花了大家很长时间大量的心血。

但最后，终于靠到了应用面上；我们将上线这几天的交易记录全部删除掉，物料编码重新导入。所谓的上线危机才见到了曙光。

可刚刚见到阳光，却又阴云密布；还有一部分编码是一物多码。于是，整整一个星期，我们就开始调账，本来上线问题就多，加上人手严重不足，再添这个严重大乱，整整一周，可把我忙的人仰马翻，夜以继日。做了多年项目，我遇到过压力比这个项目大的多的项目比比皆是，但是，遇到这么累的项目，还真是第一回。可谓是郁闷至极。这个项目从技术角度上讲，不存在什么难度，但却做到这么累，真是让人直叹人为所致，需要自己好好深深反省。

讲完切肤之痛，得说下编码规则是软件实施的根中之根的原因吧。希望自己以后更严更细更谨防的对待的编码问题，可能任何自己涉及的项目，将均被列入“自己亲手做的内容”，不能让他人代劳了。

为什么开头说编码原则是实施的根中之根呢？

因为编码一旦确定和使用，再也无法变更、删除。在软件系统中，我们可以跑跑程序，能一旦使用而不能删除的，也许有，但绝对不会比一个物料要困难。原因很简单，物料编码是软件系统的最基本工作单元。它是软件系统的细胞，一旦细胞全都出问题了，组织、器官、躯体还能幸免？器官坏了，可以重新移植，但细胞都坏了，可能就不那么简单。

另外，编码是软件系统进行信息沟通的最基本语言，一旦出现问题，后面所有工作都无法展开。这就像英文中的二十六个字母、汉字中的偏旁部首；如果没有它们，我们只能做口头传说，真正“君子动嘴不动手”了。

可以说的夸张一点，物料编码好坏和质量高低决定了一个项目的好坏和质量。好的物料编码规则及编码体系，可以让软件系统和企业管理体系井井有条、一目了然、规范高效。一个不好的编码原则或编码体系，也可以让企业管理陷入一团乱麻。

再回到这个项目上来吧。

好在我们的编码原则没有出现问题，是命名规则出了问题，而问题又主要出在了新叫法与旧叫法不一致。也许在一个规范的企业里，这些可能不是什么问题，但这个客户却偏偏比较特别；所以就成了问题。

所以在有的时候、有的地方、有的环境、有的背景下，一个看似很普通很平常甚至不经意的问题，可能就会左右一段行程。这更要求自己，多一点空杯心理，更多一些谨慎，更多一些调研，更多一些预案。

那一次，一个星期整整的日夜加班加点，我们一起工作的女同事，她老公实在难以理解，竟从上海赶了过来；来的时候是晚上十点多，他硬是把我从睡梦中给电话醒了要跟我谈谈，他很困惑为什么我们就这么忙。让我无言以对。

不过，第二天，他跟我们一起加班。让我更无言以对。我们只能自嘲的说：这次，我们把一物多码的解决方案可谓演绎到了极致。估计今后谁要是再出现什么一物多码的问题，问问我们，可能是一语中的、药到病除了。

但这段痛苦的经历最好没有，至少少点才好，于自己于他人于客户，都是一大幸事。

阅读原文​