每个 ERP 项目都会走到定顺序的那一刻。原则既难反驳也同样难以相信。顺序搞错要付多少，以及这个主张到底压在哪三个数上？
顺序搞错要付多少钱？
只需要预计的定制数量，以及上线会推迟几个月。其余是三个假设 — 把三个都设为零，两条路的花费就一样，本该如此。
假设 — 点开可逐项查看和修改
做出来
以后要背的
推迟掉的价值
这是估算，不是承诺。整个论证都压在三个假设上：返工比例、自己消失的需求比例，以及推迟的月数。把三个都设为零，差额就归零 — 如果你相信在自己公司这三个都是零，那么顺序确实无所谓。
每一个 ERP 项目都会走到必须定顺序的那一刻：先把标准系统推上线， 还是先围着每个部门深度定制，然后才上线？
答案通常以原则的形式被说出来 —— 先把标准这根脊梁立起来，各部门的改进放在后面。 可原则既难反驳，也同样难以相信。本文把它换成钱： 顺序搞错要付多少，以及这个主张到底压在哪三个数上？
1. "从第一天就深度定制"的三个陷阱
当项目组试图把旧习惯照搬到新软件上、以此讨好每一个部门时：
把混乱自动化了。 如果底下的流程没有标准化，物料主数据里还留着重复，记账规则还含糊， 那么深度定制只是用技术把一个错的流程电子化。新系统只会更快、更大规模地产出错误。
破坏数据完整性。 为销售量身定制的功能，可以让销售快得飞起，同时悄悄跳过一条记账约束、 打断财务的单据流、或者把可用库存搞乱。在一个部门做局部最优，通常会在别处造出一个堵点。 这正是第一篇所说的数据分散 —— 只不过这里是公司自己制造的。
技术债。 上线前赶出来的几百行定制，把系统变成一床补丁被。升不了级，维护成本往上走， 而冒出来的故障都是安静的那一种。
2. 三层模型
本节由编辑依据原始资料陈述的原则写成 —— 原文在提出三层之前就停住了。 这是一种诠释，不是作者本人的话。
三层必须按顺序做完，因为每一层都只能立在它下面那一层上。
- 一个跑得起来的标准内核。 干净的主数据、清楚的记账规则，以及至少一张能从创建走到报表、 闭合一整个循环的单据。没有这一层，上面的一切都建在沙上。这里的目标不是"优雅"， 而是"跑得动，而且是对的"。
- 把做事的方式标准化。 每一类信息只有一个入口，没有在流程外面跑的表格， 命名和分类只有一种说法。很少有人喜欢这一层，因为它碰的是习惯； 但决定第三层要花多少钱的，正是这一层。
- 部门级的改进。 现在可以定制了 —— 但要按本站的标准：先测，再改，分波推进， 每一波都带着自己的测量。本站此前的三篇都是第三层的例子，而且没有一篇能在第一层没跑起来时成立。
这个顺序最有意思的地方不是技术上的： 被称作"非要不可"的需求里，有相当一部分会在标准内核跑了几个月之后自己消失。 不是因为谁在争论里赢了，而是因为真实的活开始在真实的系统里流动之后， 用户自己发现当初要的东西已经不需要了。先定制，就意味着连那些一起付钱。
3. 把它算成数
两条路的差别落在四笔上，而且只有"先定制"那条路要付：
返工掉的那部分 = 需求数 × 每项定制成本 × 在没标准化的底子上的返工比例
一次次升级背过去的 = 多余的定制 × 每次升级成本 × 每年升级次数 × 年数
推迟掉的价值 = 每月运营收益 × 上线推迟的月数
第四笔最常被忘掉，因为它从不出现在任何一张发票上。但五个月不上线， 就是企业整整五个月什么也没拿到，同时还在给项目组付钱。
而这里需要诚实： 整个论证压在三个数上 —— 返工比例、自己消失的比例，以及推迟的月数。 把三个都设成零，两条路花的钱一模一样。上面的试算允许你这么做。 如果在你的公司里这三个真的都是零，那么顺序就不再是个钱的问题，本文也不适用于你。
4. 真正的答案：两件事同时做
把这件事框成"先标准还是先定制"，是问题问错了，而且错得很费钱。 实际上最便宜的路是 把标准内核立起来，同时只为少数几个业务上起决定作用的环节做深度定制 —— 少数几个，而且是真的起决定作用。
理由是人的行为而不是技术：少了人们赖以过日子的那一个环节，系统就不会被用。 没人会大声反对；他们只是安静地重新打开那张旧表格。 于是公司照单全付了一套系统，却还在用旧工具运转 —— 一笔出现在任何发票上的损失，却真实存在、而且可测。
什么样的环节算"业务上起决定作用"
三个标记，而且三个都要满足：
- 它长在钱或货每天必经的路上，而不是长在月末的报表上。
- 没有它，用户有绕路可走 —— 而且那条绕路比用系统更便宜。
- 配置解决不了 ——意思是配置已经试过了，没够着。
任何一条不满足的需求，都属于第三层，都可以等。大多数"非要不可"的需求过不了这个测试 —— 这恰恰就是为什么其中相当一部分会在几个月后消失。
实践中这个数目很小：是几个，不是几十个。 如果你的"起决定作用"清单排到了二十项， 那它几乎肯定没被筛过，你正在换个名字往"全部先定制"回走。
三条路，并排测
上面的试算把三条路放在同一个观察期上比。按默认假设，两件事同时做那条路最便宜 —— 但真正刺眼的地方在于，它只以很小的差距赢过"只上标准"， 却以巨大的差距赢过"先把定制全做完"。换句话说： 在"只上标准"和"同时做"之间选错，是个小错；选"先把定制全做完"，才是贵的那个。
还有诚实的部分：如果跳过那几个决定性环节什么也不损失 —— 把损失的收益比例设为零 —— 那么只上标准就比同时做更便宜，本该如此。 早做那几件事的全部理由，都压在"人会绕开缺了它们的系统"这个事实上。 如果这在你的公司里不成立，那就别早做。
5. 这个顺序什么时候是错的
任何原则都有它不成立的地带，而把那个地带点出来，是让原则变得可信的唯一办法：
- 当标准内核根本跑不动核心业务时。 在某些行业，少了某一条特定流程，系统连一张有效单据都开不出来。 那时这条流程属于第一层 —— 它是地基，不是定制。
- 当法律约束不允许用近似版本运转时。 开票、税务、受监管行业：没有"差不多对"的版本能上线。
- 当定制比争论更便宜时。 一个小而清楚的改动，不碰总账，却能整块拿掉一个部门的抵触 —— 就直接做。 本站此前的三篇都属于这一类。
顺序不是纪律问题，也不是架构正确与否的问题。它是钱的问题： 搞错了，你要为那些提需求的人日后自己不想要的定制付钱， 还要为那些谁也没拿到任何东西的月份付钱。
这里的数字是示意，并非取自任何客户的系统或项目。请在上面的试算里换成你自己的数字。