先给结论：效率提升是规划动作的结果，不是上线的副产品
我把这些年做过的 ERP 项目复盘成一句话：效率提升不是系统上线之后自然发生的，它是规划阶段被设计进流程、数据和验收标准里的结果。如果你在上线当天才开始想“效率怎么提升”，那这件事基本已经晚了。
这句话不是方法论口号，是我用几次翻车换来的。2023 年下半年我参与过一个家居园艺卖家的 ERP 上线复盘，团队 60 人，亚马逊、eBay、独立站、TikTok Shop 四个渠道 11 个店铺，SKU 大约 4200 个。ERP 选型花了 5 个月，实施用了 4 个月。上线第 90 天，老板给我看数据：订单处理平均时长从 4.2 小时涨到 5.1 小时，库存准确率从 86% 掉到 81%，财务月结从 9 个工作日变成 11 个。
他的原话是：“系统比以前卡得还死，人反而多了两个。”问题不在 ERP，在于他们把 ERP 当成一次 IT 交付，而不是一次业务重构。系统被装上了，但流程、主数据、角色分工和验收标准没有跟着动。
所以我给的判断分三句：
我观察下来，绝大多数卖家的系统演进会走三段路，而且几乎不可跳过。
第一段是工具割裂期。订单靠平台后台加 Excel，库存在一张共享表格里，采购用聊天记录，财务用另一套表格。这个阶段人少、SKU 少、单量低，靠人的记忆和加班能撑住。典型特征是“每个人手里都有一份自己的真相”。
第二段是工具堆叠期。订单上了打单工具，库存上了进销存，财务上了记账软件，客服上了工单系统。单量涨到每天几千单，每个环节都有工具，但环节之间靠人工搬运。这个阶段最常见的岗位是“数据对接专员”，每天的工作就是把 A 系统的导出文件整理成 B 系统能导入的格式。
第三段是 ERP 整合期。业务开始要求一个订单在全链路上有唯一状态，一套库存、一套成本、一套账。ERP 在这个阶段进场，它要的不是替换某个工具，而是替换掉环节之间的人工搬运。
风险恰恰集中在第二段到第三段的跨越上。因为这时候企业已经积累了大量历史数据和各自的“土办法”，而 ERP 天生要求标准化。
根据我参与和复盘的 20 多个项目样本（含 8 个完整上线项目，以下数据为样本推演，非行业统计），从工具堆叠期跨到 ERP 整合期的项目，出现明显延期或上线后效率倒退的比例大约在 55% 到 65% 之间。
而在这部分问题项目里，因为“软件功能不够”导致失败的不到两成，剩下八成的问题出在三个地方：主数据不统一、接口没有打通、验收标准缺失。这三件事全都在系统之外。
我印象最深的一个细节是在那家家居园艺公司。上线前他们有三个系统在建仓库编码：ERP 用“US-WEST-01”，打单工具用“美西1仓”，财务表格里写的是“LA 仓”。上线后第一批 300 个订单的库存扣减错了 47 个，仓库按错误拣货单发了 12 单错货，客诉在两周后集中爆发。这不是软件缺陷，是规划阶段没人把编码规则定下来。
判断信号非常明显：选型阶段讨论的是功能清单和报价，没人画过一张端到端的订单流程图。
后果是实施顾问只能按“标准最佳实践”配置，而你的业务里那些真正特殊的环节，比如多平台订单合并发货、预售定金拆分、赠品不占库存，全都没有被提前识别。等到上线后发现不对，只能走定制或改流程，成本翻倍。
纠正动作：在选型前，先把“接单，审单，配货，发货，回传，对账”这条主流程画出来，标出每个节点的系统、角色和时效要求。这张图是选型问卷，也是后续验收的底稿。
我见过一个卖家为了“完全贴合现有流程”，在 ERP 上做了 27 处定制。结果是每次产品版本升级都要重新适配，升级窗口一拖再拖，最终锁死在一个两年前的版本上。
定制本身没错，错在把“现有流程”当成不可动摇的前提。很多时候那个流程本身就该改。
一个实用的判断标准：如果某个定制只服务一个平台、一个店铺或一个岗位的便利，先别做；如果它服务的是所有渠道共用的结算规则或税务口径，可以考虑做。
很多团队把数据迁移理解成“导出再导入”。实际上历史数据里混着测试订单、重复 SKU、已停用的供应商、口径不一致的成本字段。不清洗直接搬，等于把过去几年的混乱一次性固化进新系统。
我的做法是：迁移前先做一次数据体检，输出三张清单，必须迁、清洗后迁、坚决不迁。成本字段和期初库存属于必须精确的，历史营销订单属于可以不迁的。
这是最隐蔽的误区。项目由 IT 或数字化负责人牵头，业务部门在需求调研时派个人参加两次会，然后等到上线时才被拉进来看结果。业务不参与定义，就不会认可新流程，上线后会用各种方式绕开系统。
正确的结构是双负责人制：业务负责人对流程和指标负责，IT 负责人对数据、接口和权限负责，两人共同在验收单上签字。
我见过太多项目的结项报告写的是“系统已部署，功能已交付，用户已培训”。这三句话没有一个字提到效率。上线后三个月，没人知道到底改善了多少，也就没人推动优化。
纠正动作是把结项报告改成指标报告：每个目标指标给出基线值、目标值、实测值和差距原因。差距原因比达标更值钱，因为它指出了下一轮迭代的方向。
我把规划阶段的核心工作定义成一次翻译：把老板嘴里的业务目标，翻译成系统里可以被执行和被度量的东西。这个过程分五层，缺一层就会断链。
大部分项目只做了第 1 层和第 2 层，第 3、4、5 层被默认交给实施方。这就是断链发生的位置。
“订单处理时长”这五个字，在运营、仓库和财务嘴里是三个不同的东西。有人说从付款开始算，有人说从抓单成功开始算，有人说要剔除预售。
口径不统一，指标就没有验收价值。所以我要求每个指标都写成一份口径卡，明确起点终点、统计范围、排除项、数据来源和责任人。
# 效率指标口径卡（示例，可直接作为实施验收附件）
指标名: 订单处理平均时长
起点: 平台订单抓取成功时间戳
终点: ERP 生成可发货状态时间戳
统计范围: 全部在售店铺，标准订单
排除项: 预售订单、缺货挂起订单、人工标记异常订单
统计周期: 自然周
基线值: 4.2 小时（上线前 90 天均值）
目标值: ≤ 2.5 小时
数据来源: ERP 订单状态日志 + 平台后台时间戳
责任人: 运营负责人（业务）+ 实施顾问（系统）
验收时点: 上线后第 30 / 60 / 90 天
下面这段是库存准确率的口径计算逻辑，我通常直接交给数据分析同事作为校验脚本的起点：
-- 库存准确率：系统账面可售库存 vs 仓库实盘可售数量 -- 统计口径：按 SKU × 仓库聚合，每周抽盘 10% SKU SELECT COUNT(CASE WHEN ABS(wms.qty - erp.qty) <= 2 THEN 1 END) * 100.0 / COUNT(*) AS inventory_accuracy_pct FROM wms_snapshot wms JOIN erp_snapshot erp ON wms.sku_code = erp.sku_code AND wms.warehouse_code = erp.warehouse_code WHERE wms.snapshot_date = CURRENT_DATE;
注意这里的容差是 2 件。如果你按零容差算，几乎没有仓库能达标；容差多少取决于品类单价和拣货方式，这个值必须由业务定，不能由系统默认。
只有结果指标会导致团队只看结果不看过程，只有过程指标会导致局部优化损害全局。我通常设三层：
护栏指标是很多团队会漏掉的部分。我曾经见过一个项目把人均日处理单量做上去了 35%，代价是发货错误率从 0.4% 涨到 1.7%，退货和赔付成本远超人力节省。
风险：SKU、仓库、供应商、客户、币种五个主数据在多个系统间不一致，是所有数据错乱的源头。它不会在上线当天暴露，通常在上线后第二到第三周集中爆发。
动作：上线前完成一次主数据收敛，输出唯一编码表和映射关系表。重点确认三件事，SKU 是否含平台差异、仓库编码是否含物流商差异、客户是自然人还是公司主体。
验收：用 100 个历史订单做全链路回溯测试，从平台订单到 ERP 出库再到财务凭证，逐笔核对 SKU、数量、金额三个字段是否完全一致。
我一般会要求映射表在实施启动会之前就冻结。冻结之后再改编码，成本不是线性增长，是阶跃式的。
风险：接口只做了一半，订单能抓进来，但发货状态回传不了，物流轨迹同步不了，导致某些环节仍然人工搬运。
动作：把接口按“必须自动化、可半自动、允许人工”三档分类，并写清每一档的理由。比如平台订单抓取必须自动化；异常订单的改址处理允许人工；对账差异的调整可半自动。
验收：统计接口抓单成功率、状态回传延迟中位数、人工干预订单占比三个数据，连续观察 7 天。
判断接口是否合格，我的标准很朴素：如果某个环节每天还需要有人打开平台后台复制粘贴，这个接口就不算完成。
风险：新系统的权限沿用了旧系统的习惯，导致一个岗位承担了不该承担的审批，流程被拉长。
动作：按“谁产生数据、谁审核数据、谁使用数据”三个问题重排角色。特别是运营、采购、仓库、财务、客服之间的边界，要比旧系统更清晰，而不是更复杂。
验收：统计单个订单的平均审批节点数。如果上线后节点数比上线前多，直接判为不合格，回去重新配置。
风险：一次性全量切换，问题集中爆发且没有退路。或者并行期过长，两套数据打架，团队疲于应付。
动作：选择 1 到 2 个店铺或 1 个仓库作为试点，跑通一个完整月结周期后再推广。并行期建议控制在 2 到 4 周，用明确的切换标准结束并行。
验收：试点范围内连续两周无 P0 级问题，关键指标达到目标值的 80% 以上，即可推广。
我的经验判断：分阶段上线的收益远大于完全一次性切换，但前提是试点范围要选“有代表性但不是最复杂”的对象。选最复杂的对象做试点，会把项目拖死；选最简单的，什么也验证不出来。
风险：培训做成了功能演示，学员知道按钮在哪，但不知道异常怎么处理。上线后遇到异常就退回旧方法。
动作：培训内容按角色拆开，每个角色只学自己会用到的那部分。同时输出异常处理 SOP，明确“什么情况下停下来找谁”。
验收：随机抽取 5 名关键用户，各自独立完成一次完整流程操作，并准确说出自己环节的三个常见异常及处理方式。
我通常会把 SOP 做成一张 A4 纸的流程图贴在工位上，比放进知识库有用得多。
ERP 擅长执行和记录，但它做效率验证有两个天然短板。第一，它的报表结构是按流程设计的，不是按分析问题设计的，想做一个跨渠道的成本时效对比往往要提需求排期。第二，ERP 的数据视角是“单据视角”，而效率验证需要的是“时间序列视角”。
这就出现了一个断层：流程在 ERP 里跑，但效率结论需要另一层工具来产出。我在项目里通常会用一层数据平台来补位，其中一个常用选择是数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）。
环节一：上线前的基线盘点。上线之前必须知道“现在到底多快、多准、多贵”，否则上线后的对比没有参照。数跨境可以把多平台、多店铺的订单数据拉到统一口径，算出订单处理时长分布、各仓库发货时效、单均履约成本这些基线值。我用它做的第一件事通常就是输出一张“上线前效率基线卡”，作为验收附件。
环节二：上线中的数据校验。迁移和接口调试阶段，最需要的是对账能力。把 ERP 的订单流水和平台后台订单做逐日比对，找出缺失、重复和金额不符的记录。我通常会对齐三个维度：订单号维度、SKU 数量维度、金额维度。三个维度都对得上，才认为数据迁移合格。
环节三：上线后的效率看板。把前三节讲的指标做成一个持续更新的看板，按周展示。看板的价值不在于好看，而在于它可以定期把“效率有没有真的提升”这件事摊在桌面上，让业务和 IT 一起面对差距。
需要强调的是，数跨境这类工具解决的是“数据和验证”层的问题，它不能替代 ERP 的流程执行。两者是分工关系：ERP 负责把事做对，数据平台负责证明事情确实被做对了。规划阶段就要把这两层的边界划清楚，否则会出现“上了 ERP 又觉得数据不够用，再上一套工具，最后还是没人看”的情况。
回到前面那家家居园艺公司。第二次复盘时，我们用数据平台重新拉了三个月的订单时间戳，发现问题集中在两个环节：一是审单环节有 38% 的订单被二次人工复核，二是海外仓出库状态回传延迟中位数达到 6.5 小时。
第一个问题的解法不是加人，而是把二次复核的触发条件从“全部订单”收窄到“金额超阈值或地址异常”的订单，审单时长立刻从 51 分钟降到 14 分钟。第二个问题属于接口问题，需要和海外仓服务商重新协商回传频率。
这两个发现都不是从 ERP 的标准报表里直接看出来的，是从原始时间戳数据里拆出来的。这也是为什么我坚持在规划阶段就预留数据层的位置。
这 30 天的重点不是效率，是稳定。目标只有三个：主流程能跑通、数据基本准确、关键用户会用。
要看的指标包括：订单抓单成功率、出库单生成成功率、财务凭证生成成功率、关键用户独立操作完成率。任何一个低于 95%，都不要急着推进推广，先解决问题。
这期间最常见的坑是着急全员推广。我一般会明确要求：试点范围内连续两周无 P0 问题，才允许扩大范围。
到第 60 天，订单处理时长、库存准确率、发货错误率、对账周期这四项应该出现可测量的改善。如果 60 天还没有变化，通常说明流程配置有问题，或者用户仍在绕开系统。
这个阶段我建议每周开一次 30 分钟的指标复盘会，只看四个问题：哪个指标没动、为什么没动、谁负责、下周做什么。不要开成汇报会。
到第 90 天，重点从指标改善转向机制固化。需要产出三样东西：
如果没有这三样东西，系统会在第 120 天左右开始退化。退化不是系统坏了，是人慢慢回到了最省力的做法。
这个阶段的团队通常在 20 人以内，SKU 在 1000 个上下。核心矛盾是数据口径混乱，不是系统能力不足。
我的建议是：先用轻量方式把订单、库存、财务三个口径统一起来，用数据平台做一张最基础的效率看板，把问题看清楚。等单量涨到现有工具确实撑不住的时候再上 ERP，这时候你对流程的理解会扎实得多。
这个阶段最不该做的事，是花大钱上一个功能齐全但用不起来的大系统。
这个阶段的团队通常在 20 到 80 人，SKU 在 1000 到 8000 之间，多平台多店铺成为常态。人工搬运的成本开始显著，流程标准化的收益开始放大。
建议按本文的 12 周路线图推进，重点是主数据治理和接口打通这两件事不能省。试点范围建议选一个中等复杂度且业务成熟的店铺。
这个阶段要特别警惕“边跑边改”。上线期间最好不要同时做品类大扩张或渠道大扩张，两件事叠加会互相拖累。
这个阶段的复杂度已经不适合整体切换。建议按模块分批：先订单与库存，再采购与物流，最后财务与结算。每批之间有明确的验收节点。
同时要建立内部的项目管理机制。我会建议用某项目管理平台把需求、缺陷、变更、验收统一在一个流程里，避免靠聊天记录推进。重点是让业务方能看到自己提的需求现在到哪一步了。
这个阶段单独设一个“流程与数据”岗位是值得的，它比多招两个运营更能提升整体效率。
这个规模的企业，ERP 项目已经不是一次工具升级，而是组织能力建设。建议先做 4 到 6 周的规划期，产出业务蓝图、数据标准、集成架构和验收体系，再启动实施。
同时要建立长期的指标运营机制，效率看板进入月度经营会，指标负责人进入考核。
标准化的收益是可预测、可度量、可复制；灵活性带来的是应对特殊场景的能力。我的判断线是：高频动作必须标准化，低频且高价值的动作允许保留人工。把 5% 的特殊订单做成定制流程，会让 95% 的标准流程变慢。
一次性切换的优点是数据干净、没有并行期干扰，缺点是风险集中。分阶段上线的优点是可回退，缺点是并行期数据容易打架、周期拉长。
我的经验是：渠道数超过 3 个、仓库数超过 2 个的项目，优先分阶段；业务窗口期紧张、需要在旺季前完成的，考虑一次性切换但必须准备完整的回退方案。
定制开发解决的是“现在”，改流程解决的是“以后”。我的判断标准前文说过，补充一条：如果这个定制在一年后你希望能删掉，那就不要做。很多定制模块最后都成了没人敢动的历史包袱。
全量迁移的好处是历史可追溯，坏处是清洗成本高、垃圾数据永久留存。我的建议是：交易类数据按需迁移，通常保留最近 12 到 24 个月；主数据必须全迁且必须清洗；营销类历史数据可以不迁。
这两者短期确实有冲突，但长期是同向的。当短期冲突出现时，我的判断是优先保质量，因为质量问题的修复成本通常远高于效率收益。
护栏指标在这个取舍里起决定作用。如果发货错误率或库存准确率越过警戒线，无论效率指标多好看，都应该停下来重新配置。
自建的优势是贴合度高，劣势是维护成本高、人员依赖强。对绝大多数跨境卖家来说，我倾向于在验证阶段用现成数据平台，把精力放在业务理解和指标设计上；等数据需求稳定、团队有余力时再考虑自建。
下面这张表是我在多个项目里反复调整后的版本。它不是一个必须照搬的标准，而是一个可以按企业规模、渠道数量和资源情况增减的骨架。
| 阶段 | 周期 | 核心目标 | 关键交付物 | 验收方式 |
|---|---|---|---|---|
| 业务蓝图 | 第 1，2 周 | 画清端到端流程，锁定业务目标 | 主流程图、目标清单、角色清单 | 业务与 IT 双负责人签字确认 |
| 数据与选型 | 第 3，4 周 | 完成主数据收敛，确定系统方案 | 唯一编码表、映射表、选型报告 | 100 笔历史订单回溯通过 |
| 配置与集成 | 第 5，8 周 | 流程配置、接口打通、权限设置 | 接口清单、权限矩阵、测试用例 | 抓单成功率与回传延迟达标 |
| 试点运行 | 第 9，10 周 | 试点范围跑通完整业务周期 | 试点问题清单、异常处理 SOP | 连续两周无 P0 问题 |
| 推广切换 | 第 11 周 | 全量推广，旧系统退出 | 切换方案、回退预案、培训记录 | 关键用户独立操作完成率 ≥95% |
| 验收复盘 | 第 12 周 | 指标验收与机制固化 | 指标报告、效率看板、迭代清单 | 目标指标达到基线改善目标 |
需要提醒的是，第 9 到 10 周的试点阶段最容易被压缩。很多团队为了赶进度把试点从两周压成三天，结果问题全部推迟到全量推广时爆发，反而多花了一个月。
我做了这些年项目，最深的体会是：ERP 项目真正难的部分，从来不是软件配置，而是把业务上模糊的期待变成系统里精确的规则。这个翻译过程做得好，系统上线自然带来效率；做得不好，再贵的系统也只是把混乱搬到了一个更贵的地方。
如果你现在正准备启动 ERP，或者已经上线但效率没动，我建议先不要急着换系统或加功能。回到三件事上：你的核心流程是什么、你的效率指标是什么、谁对这些指标负责。这三件事清楚了，系统实施与效率提升之间的衔接自然就通了。
如果你想先从数据侧入手，看看当前多平台订单和库存的真实效率基线，可以从数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）开始做一次基线盘点。不是为了买工具，而是为了在规划阶段就知道自己现在站在哪里，这比任何选型报告都更能决定项目最终的效果。
我是一家做亚马逊加独立站的卖家，团队二十多人，最近老板催着上线 ERP，几家服务商也在推方案，我担心选完系统才发现流程对不上，返工更贵。到底该先做哪一步，又怎么判断这个顺序没走错？
先把要解决的业务问题写成可验收的效率指标，再带着这份指标去选系统，但不必等流程全部梳理完才接触服务商。可行做法是用两周做一轮业务蓝图：列出当前最痛的三个场景，比如多店铺订单靠人工汇总、海外仓库存对不上、平台结算与财务对账拖一周以上，把每个场景的现状耗时、涉及角色、数据来源写成一页基线表。
带着基线表去见服务商，重点看它在你这些场景里是标准功能覆盖还是需要定制，定制项超过三成就要警惕后续维护成本。判断顺序对不对的标准很简单：你能不能说清上线后哪个指标从多少变到多少、由谁取数、在哪张报表看。说不出来，说明还在选软件而不是做规划。
紧急替换旧系统时选型和梳理可以并行，但指标定义这一步不能省，否则实施阶段一定会变成功能堆砌。
我之前上过一套系统，服务商口头承诺能提效一半，结果上线后谁也说不清到底提没提。财务说对账还是慢，运营说订单处理没变快，最后不了了之。这次重新做规划，我想把指标写进合同和验收，但不知道怎么定义才不会被绕过去。
指标定不住，多数时候是口径问题而不是系统问题。建议只选五个能被运营、仓储、财务同时认账的指标，并逐条写清计算口径、数据来源、基线值、目标值和责任人。订单处理时长统一按平台订单抓取成功到仓库出库扫描的时间差，剔除缺货挂起和客户改址；
库存准确率按 SKU 加仓库维度做循环盘点，差异数量除以盘点总量，每周抽盘并公布结果；发货错误率按错发、漏发、错贴面单的订单数除以总发货单量，来源用物流商回传的异常数据；对账周期按平台结算单下载到财务确认入账的自然日天数；人均单量必须注明是否含临时工和加班时长，否则数字好看但说明不了问题。
验收时以系统里同一张报表为准，不接受手工另算。目标值建议分达标值和理想值两档，别把承诺写死成单一百分比，也要约定口径变更时的重新基线流程，否则项目中途一改规则，前期数据就全废了。
我们有三四十家店铺、两个海外仓和一个国内仓，服务商建议一次性切换，说分阶段要维护两套流程、反而拖长周期。但我们上次换系统出过发货事故，老板心有余悸，我也拿不准节奏该怎么定。
以衔接效率为导向，多数成长型卖家更适合按业务单元试点加并行切换，而不是按模块全量铺开。做法是先选一个店铺组加一个仓库做试点，试点范围要能覆盖至少三条核心链路，比如平台抓单到发货出库、采购入库到库位上架、平台结算到财务入账，跑满两到四个完整结算周期再决定是否扩围。
并行期建议控制在两到四周，并设一个硬性切断条件，例如连续两周库存差异率低于约定阈值、发货错误率不高于试点前水平、关键岗位能独立完成日结，三条同时满足才停用旧流程，否则让旧系统继续兜底。一次性切换并非绝对不能做，前提是流程标准、历史数据干净、定制项少并且有专人驻场支持；
如果主数据还没统一、接口还在反复调，一次性上线会把风险压在切换周集中爆发，返工代价远高于并行期的额外人力。分阶段确实会拉长周期、增加双系统维护成本，所以要在立项时就把这笔成本写进资源预算，而不是中途被迫延期时再来解释。
我们上线快三个月了，系统里数据是有了，但我发现运营还在用表格核对库存，仓库遇到异常还是直接微信群里喊，感觉系统成了个记账工具。我该怎么判断效率到底有没有提升，又该怎么把流程真正固化下来？
上线只是起点，验证要按 30、60、90 天三个节点看不同内容。30 天看跑通和准确：关键单据有没有断流，主数据有没有重复或错码，关键用户能不能独立完成日常操作和日结，这个阶段先别急着要效率数字。
60 天看趋势：把前面定的五个指标按周拉出来对比基线，重点看改善是否稳定，单周大幅波动通常说明口径或数据源还有问题，先修口径再谈提效。90 天看机制：有没有固定看板、周复盘和问题闭环清单，每条问题有责任人和关闭日期，迭代清单按月滚动。
防止退回旧习惯的关键是掐掉并行的退路，旧表格要么冻结只读，要么明确只保留哪几列作为过渡并设定停用日期；异常处理必须走系统流程或工单，群里口头协调的结果要当天补录回系统，否则数据和库存永远对不上。再把指标接进岗位周目标和考核，让运营和仓库知道数字有人看，习惯才会真正改变。
如果 90 天后仍有两个以上指标没有稳定改善，优先回头查主数据口径和接口集成，而不是继续加功能。
读者评论
文章里那个库存准确率从86%掉到81%的案例太真实了，我们公司去年上ERP也是类似情况，仓库编码三个系统各叫各的，上线后拣货错了一堆，根本问题确实不在软件。
五层翻译模型这个说法挺到位，大部分项目确实只做到流程层，数据、角色和指标都丢给实施方了，结果就是系统上线了但没人对效率负责。
我比较认同定制那个判断标准，只服务单个店铺便利的定制先别做。我们之前做了十几处定制，后来版本升级直接卡死，维护成本比开发还高。
口径卡这个做法很实用，一个订单处理时长在运营和仓库嘴里完全不同，不把起点终点定义清楚，验收的时候肯定扯皮，这个可以直接抄来用。
文章说上线是效率验证的起点不是终点，这点很多人做不到。我们公司上线后没有30/60/90天复盘，半年后大家又悄悄用回Excel了。