2023年我参与过一个亚马逊+TikTok Shop卖家的ERP上线复盘。项目做了四个月，预算六十多万，功能清单上的采购、订单、库存、财务模块全部"上线"了。但上线三个月后，仓库主管还在用Excel对库存，运营每天早上手动从后台导订单，财务月底关账仍要五个人对七天。老板问了一句让我记到现在的话：功能都买了，为什么还是用不起来？
后来我们把问题拆开看，发现根因不在功能，而在没人定义过"推进到什么程度算改造成功"。整个项目只有一张上线日历，没有一张指标看板。这几乎是跨境电商ERP改造里最普遍、也最贵的一个盲区。
这篇文章想讲清楚一件事：跨境ERP改造的推进单位不是功能模块，而是指标。功能是交付物，指标才是进度条和验收标准。下面我会把三层指标体系、六个实施阶段的退出标准、不同业务模式下的取舍，以及以数跨境为例的落地观察，完整拆开讲。
先把结论摆出来。跨境电商ERP改造失败，绝大多数不是技术问题，而是"管理颗粒度错位"，用功能清单管理一个本质上是流程重构的项目。
功能清单是二维的：有哪些模块、做到什么程度。但跨境ERP改造是四维的：数据要打通、流程要重排、人要换习惯、收益要能证明。二维工具管不了四维问题。
第一种是"准时上线型失败"。项目按甘特图准时交付，验收单签了字，但订单抓取成功率只有七成多，剩下三成靠人工补。项目组解散，业务侧开始骂系统。
第二种是"功能齐全型失败"。采购、库存、履约、财务模块都在，但每个模块的数据口径不一致。SKU在采购系统叫一个名，在库存系统叫另一个名，财务对不上账。
第三种是"部门孤岛型失败"。IT部门认为交付完成，运营部门认为系统不好用，仓库认为增加了工作量。三方都有道理，因为从头到尾没有共同的验收语言。
这三种失败的共同点是：项目有交付物，但没有可量化的推进证据。一旦出现争议，只能靠嗓门大小决定结论。
跨境ERP的改造范围天然容易膨胀。一个"打通库存"的需求，往下拆会牵出多平台库存映射、海外仓同步频率、在途库存口径、预售占用逻辑、退货回补时点等一连串子问题。
如果没有指标约束，每一个子问题都会被当成"再开发一点"处理。需求变更率会持续走高，工期持续后延，最后压缩的一定是测试和数据治理时间，而这两块恰恰是跨境ERP最容易翻车的地方。
指标的作用不是考核，而是给"做到哪算够"提供一个可争论、可复盘的基准。没有基准，范围就永远收不住。
我一般把跨境ERP改造的指标分成三层：项目推进层、系统健康层、业务收益层。三层分别回答"项目在不在轨道上""系统能不能用""改造值不值"。
三层缺一不可，而且必须按顺序建立。项目推进层先立，系统健康层跟上，业务收益层在上线后逐步显影。
国内电商ERP的经验，直接搬到跨境场景往往会失效。原因不是功能不够，而是跨境链路上多了几个国内没有的变量。
铺货型卖家SKU动辄几十万，核心矛盾是上架效率和库存准确性；精品型卖家SKU少但单量大，核心矛盾是履约时效和成本核算；独立站卖家更关心支付对账和归因；平台店群卖家最痛的是多店铺订单聚合和绩效分摊。
这四类模式对ERP的要求差异极大。用同一套验收标准去衡量，必然会有一方的核心诉求被牺牲。指标必须跟着业务模式走，这是跨境电商ERP改造和国内ERP改造最大的区别。
我调研过的一些ERP产品文档把"数据采集"作为功能模块说明，讲的是操作入口和采集点位。但在实际项目里，数据采集从来不是一个模块问题，而是口径治理问题。
同一个订单，平台后台的"下单时间"、ERP里的"订单创建时间"、物流系统的"揽收时间"，三个时间戳口径不同。如果不在蓝图阶段就定义清楚，后期的履约时效指标全是废的。
一个中等规模跨境卖家，同时对接的平台可能有五到八个，物流渠道十几个，海外仓三到五个。每个接口都有超时、限流、字段变更、异常重试的问题。
接口问题不会一次性暴露，而是在大促、平台改版、物流商系统升级时集中爆发。所以要提前把接口失败率、重试成功率、数据延迟时长做成常驻监控指标，而不是出事了再查。
跨境ERP改造最容易扯皮的三件事：谁负责主数据、谁负责异常订单、谁负责对账差异。这三件事如果没在项目章程里写明责任人和升级路径，最后都会变成"系统问题"。
我的判断是：凡是无法指定唯一责任人的指标，都不要放进看板。放进去只会稀释注意力，还会制造新的扯皮点。
下面六个误区，我在不同项目里反复见到。它们不是认知问题，而是组织惯性。
很多团队的做法是先比选产品，签完合同再想怎么衡量效果。这个顺序一旦固定，指标体系就会变成"给已选产品做适配"，而不是"为业务目标做设计"。
正确的顺序是：先明确业务目标，再翻译成指标，再判断哪些指标需要系统能力支撑，最后才是选型。选型是结果，不是起点。
"上线"在技术上是部署完成，在业务上只是一个开始。真实的价值曲线通常在上线后三到六个月才会显影。
如果项目奖金和结项评审都挂在上线节点，团队自然会把资源全部投向"准时上线"，而压缩数据治理和用户培训，这两块恰恰决定了上线后的实际使用率。
我见过一张有六十七个指标的实施看板。结果是没有一个人每周真的看完。指标的价值在于被使用，不在于被定义。
我的建议是：项目期常驻指标控制在十二个以内，分三层各三到四个。其余指标进入专项分析，不进周报。
IT负责系统，业务负责使用，这个分工听起来合理，实际会出大问题。因为大量指标的定义权在业务侧：什么叫"订单处理完成"、什么叫"库存准确"、什么叫"对账无差异"。
IT定义不了这些口径。如果业务不参与定义，最后只能由IT拍脑袋，业务再用"不符合实际"否定整套系统。
主数据治理是最不出彩、也最不能省的工作。SKU编码规则、仓库编码、客户编码、币种和汇率口径，这些在蓝图阶段定不下来，实施阶段就会不断返工。
我的经验是：主数据治理进度应该单列为一条项目主线，而不是挂在某个模块下的子任务。它有自己的里程碑和验收标准。
行业报告里的"库存周转提升30%""订单处理效率翻倍"，是别人在别人的业务结构下取得的。直接拿来当自己的目标值，最后只会得到一个无法解释的差距。
正确做法是先测自己的基线，再设目标。基线可以是过去三个月的均值，也可以是小范围试点的实测值，但必须是自己测出来的。
指标体系不是指标列表。它必须包含定义、口径、目标值、数据源和责任人五要素，缺一个就会在执行阶段失效。
（1）定义：这个指标到底在说什么。例如"订单抓取成功率"要明确是"平台已生成订单中被ERP成功拉取的比例"，还是"ERP拉取成功的订单中字段完整的比例"。
（2）口径：计算方式、统计周期、剔除规则。例如是否剔除已取消订单、是否包含测试单、跨币种如何折算。
（3）目标值：分基础值和挑战值。基础值是必须达到的底线，挑战值是优化方向。
（4）数据源：指标从哪个系统、哪张表、哪个字段取数。没有明确数据源的指标，等于不可验证。
（5）责任人：唯一责任人，不是"某部门"。责任人负责解释异常、推动改进。
项目推进层解决的是"项目在不在轨道上"。我常用的指标有：范围冻结率、需求变更率、关键用户参与率、缺陷关闭率、UAT场景通过率、培训覆盖率、切换成功率。
这一层的目标值通常与项目计划绑定，属于过程性指标。它的价值在于早期预警，而不是事后考核。一旦发现变更率连续两周超标，就要立即触发范围复审。
健康层是跨境ERP最容易被忽略的一层。它监控的是系统的实际可用性，而不是功能是否存在。
核心指标包括：订单抓取成功率、库存同步延迟、SKU主数据完整率、接口任务失败率、对账差异率、平均异常处理时长。
这些指标的特别之处在于，它们会直接决定业务侧是否愿意用系统。订单抓取成功率掉到95%以下，运营就会开始手工兜底，一旦形成手工习惯，系统就很难再回到主路径。
收益层指标包括：订单处理人效、库存周转天数、缺货率、履约时效、错发漏发率、财务关账周期、资金占用。
这一层必须建立归因边界。市场增长、季节性波动、汇率变化都会影响这些指标，不能全部归功于ERP。我的做法是在项目立项时就记录基线值，并在复盘中明确列出非ERP影响因素。
指标没有出口就是死数据。每个指标都要有预警线、黄灯线、红灯线和对应的升级路径。
绿灯不需要动作，黄灯需要在周会上说明原因和计划，红灯需要当天升级到项目决策人。这套机制的价值在于把讨论从"系统好不好用"转到"哪个指标出了什么问题、谁来解决"。
我通常建议项目期常驻十二个指标：推进层四个、健康层四个、收益层四个。等系统稳定运行三个月后，可以再增加专项指标。
优先级排序的逻辑是：先看健康层里有没有红灯，有红灯先解决；健康层全绿再看推进层；推进层达标才讨论收益层。顺序反了，就会出现业务天天催收益、技术天天补数据的两头空转。
下面这部分，我用数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）作为观察对象，说明指标体系在不同阶段具体怎么落。
需要先说明：数跨境是跨境电商数据与经营分析方向的工具，我把它放进这套框架里，是因为它的能力形态天然贴近"用指标驱动经营决策"这件事。下面的观察包含我参与项目的脱敏经验，涉及具体数值的部分标注为示意数据。
跨境ERP改造的一个典型断层是：ERP负责流程执行，但经营层需要的是跨平台、跨店铺、跨币种的汇总指标。这两者之间往往缺一层数据整合与呈现。
传统做法是让IT定期导数据做报表，周期长、口径乱、无法追责。更合理的做法是让ERP承担执行数据和主数据，让分析层承担指标汇总和归因。
数跨境这类工具的价值就在这里：它把"指标口径"从每个人的Excel里搬到统一的数据模型里，让同一个指标在全公司只有一个算法。
在订单采集阶段，最该被盯住的三个指标是：订单抓取成功率、字段完整率、SKU映射准确率。
在我参与的一个多平台项目里，上线首周订单抓取成功率为91.3%，主要失败原因是两个平台的时间字段格式不同，导致部分订单被判为重复。加入去重规则后，第二周升到97.8%，第三周稳定在99.2%。
SKU映射准确率是另一个关键数字。这个项目初始为88%，意味着每100个SKU有12个对应错误或未对应。经过编码规则统一和映射表重建，两周后升到99.5%。这个0.5%的缺口不是技术问题，而是商品部和采购部的编码习惯问题。
库存同步延迟是跨境场景最容易被低估的指标。多平台同时销售同一批库存时，延迟超过几分钟就可能造成超卖。
我观察到的规律是：库存同步延迟的瓶颈通常不在接口速度，而在库存口径的定义。平台可用库存、本地可用库存、海外仓可用库存、在途库存、预售占用库存，如果定义不清，同步就无从谈起。
履约阶段的核心指标是发货及时率和错发漏发率。这两个指标在ERP上线初期往往会短暂恶化，因为员工在适应新流程。管理层要有心理预期，不能看到第一周数据下滑就否定改造方向。
对账差异率是检验ERP改造是否真正成功的关键指标。它同时依赖订单数据、支付数据、退款数据、汇率数据和物流成本数据。
我见过的最典型情况是：订单和收款能对上，但退款和平台佣金对不上。原因往往是退款数据晚到，而ERP按日结账，导致跨期差异累积。
解决办法不是加大人力，而是把对账周期从按日改为按结算周期，并在指标上增加"未结算差异挂账天数"。这个指标一旦超过预设阈值，就必须启动人工核查。
把数跨境放进这套框架，我的判断是：它承担的是指标层的统一口径和跨平台聚合，而不是替代ERP执行流程。
ERP负责"事情做完"，分析工具负责"事情做得好不好"。两者分工清晰，才不会出现ERP被要求做BI、BI被迫补执行数据的情况。
在我的经验里，这种分工带来两个直接好处。第一，指标口径不再依赖个别人的Excel模板，人员流动不会带走算法。第二，跨平台、跨店铺的横向对比成为常规动作，而不是每次临时拉数。
必须强调三点边界。第一，上面的数值来自单项目脱敏记录，样本极小，不能推断为行业基准。第二，不同业务模式的收敛周期差异很大，铺货型SKU多，主数据治理周期通常更长。第三，任何工具都无法替代口径定义这项管理工作。
工具能把指标算准，但决定不了指标该不该这么算。这是我一直坚持的判断。
下面按阶段给出目标、关键指标和退出标准。每个阶段的退出标准必须在前一阶段结束前确认，不能边做边定。
这个阶段要完成三件事：确认业务目标、翻译成业务收益层指标、测出基线值。同时要冻结项目范围和责任人清单。
关键指标：目标指标基线覆盖率、关键干系人确认率、项目章程签署完成率。退出标准是所有收益层指标都有基线值和责任人。
蓝图阶段的核心产出不是流程图，而是数据口径说明和主数据规则。流程可以按标准模板走，但口径必须逐条确认。
关键指标：主数据规则确认率、口径文档覆盖率、接口清单确认率。退出标准是主数据规则和接口清单全部签字确认。
这个阶段最容易失控，因为需求变更会集中出现。要把变更走正式流程，并持续监控变更率。
关键指标：需求变更率、接口联调通过率、缺陷关闭率、主数据完整率。退出标准是接口联调通过率超过95%，主数据完整率超过98%。
UAT必须用真实业务场景和真实数据量测试。用小样本测试通过，不能说明系统可用。
关键指标：UAT场景通过率、严重缺陷数、数据迁移准确率、培训覆盖率。退出标准是无严重缺陷未关闭，数据迁移准确率超过99.5%。
切换阶段要准备回滚方案，并明确回滚触发条件。回滚不是失败，而是风险控制的必要手段。
关键指标：切换成功率、回滚次数、首周异常单量、首周订单抓取成功率。退出标准是首周订单抓取成功率超过98%，异常单量在可承接范围内。
上线后一到三个月是价值显影期。这个阶段要按周看健康层、按月看收益层，并做正式复盘。
关键指标：健康层红灯次数、收益层指标达成率、用户活跃率、异常闭环时长。退出标准是连续两个月健康层无持续红灯，收益层至少两项指标达成基础值。
指标体系不能照抄。业务模式、组织规模、技术能力不同，指标权重必须调整。
铺货型的核心矛盾是SKU数量和管理效率，指标权重要向主数据完整率、批量刊登成功率、库存准确率倾斜。收益层可以重点看单SKU运营成本。
精品型的核心矛盾是履约时效和成本核算，指标权重要向发货及时率、库存周转天数、单品毛利准确率倾斜。
平台店群的关键是订单聚合和多店铺绩效分摊，重点指标是多店铺订单抓取成功率、店铺级利润归集准确率。
独立站的关键是支付对账和流量归因，重点指标是支付成功率、退款率、渠道获客成本准确性。
有海外仓的复杂度显著更高，重点是海外仓库存同步延迟、调拨准确率、尾程履约成本。无海外仓的卖家则应更关注头程成本和物流时效波动。
自研团队的优势是口径可以完全自定义，劣势是维护成本高、迭代慢。采购SaaS的优势是上线快，劣势是口径受产品限制。
取舍的关键在于：哪些指标是你的核心竞争力，哪些只是行业通用要求。核心竞争力相关的指标，值得自研或定制；通用指标的差异，不值得投入过多资源。
| 业务场景 | 优先级最高的指标 | 可以后置的指标 | 主要原因 |
|---|---|---|---|
| 铺货型、SKU十万级 | SKU主数据完整率、批量刊登成功率 | 单品毛利准确率 | SKU数量决定管理效率是主要矛盾 |
| 精品型、客单价高 | 发货及时率、库存周转天数 | 批量刊登成功率 | 履约体验直接影响复购和平台权重 |
| 平台店群、多店铺 | 多店铺订单抓取成功率、店铺级利润归集 | 海外仓调拨准确率 | 订单聚合和绩效分摊是主要痛点 |
| 独立站为主 | 支付成功率、渠道获客成本准确性 | 批量刊登成功率 | 支付与归因决定投放效率 |
| 多海外仓布局 | 库存同步延迟、尾程履约成本 | 单品毛利准确率 | 库存协同是跨国链路的核心风险点 |
最后给一个可直接复用的模板结构。核心原则是：一页纸、十二个指标、三层分布、每周更新。
每个指标占一行，包含八个字段。字段少了无法追责，字段多了没人填。
指标卡字段结构
=========================
指标名称 ：订单抓取成功率
所属层级 ：系统健康层
指标定义 ：平台已生成订单中被ERP成功抓取并入库的比例
计算口径 ：成功抓取订单数 / 平台订单总数（剔除测试单）
目标值 ：基础 98% / 挑战 99.5%
数据源 ：ERP订单表 order_header / 平台API回传日志
责任人 ：订单系统负责人
监控频率 ：每日
预警线 ：黄灯 97% / 红灯 95%
这八个字段是底线。如果某个指标填不出"数据源"和"责任人"，说明它还不具备进看板的条件。
周会只看推进层和健康层，时长控制在四十分钟内。议题只有三个：红黄灯指标原因、本周动作、需要升级的事项。
月会看收益层和数据治理进展，重点是对比基线、解释偏差、判断是否需要调整目标。月会不讨论单个异常工单，那是周会的范围。
红灯指标必须当天有责任人认领，三天内给出原因分析，两周内给出改进结果或明确的延期说明。这三个时间点是硬约束，不能协商。
我见过很多项目把"分析原因"拖成一个月，最后问题自然消失，但不是被解决了，而是被业务用人工兜底绕过去了。被绕过去的问题，会以更高的成本在半年后重新出现。
需要，但可以精简。小项目可以只保留六个指标：两个推进层、两个健康层、两个收益层。三层结构不能省，因为它保证了"过程、可用、价值"三个维度都被覆盖。
先测基线，再定目标。没有基线的情况下，我建议用"基线值 + 可解释的改进幅度"来定，而不是直接套行业数字。改进幅度要能说清楚靠什么动作实现。
通常不是意愿问题，而是指标和他们无关。解决办法是把指标和他们已有的考核项挂钩，或者减少他们需要手工填报的字段。指标如果依赖人工填报，注定不可持续。
我的观察是：效率类指标通常一到两个月开始改善，库存类两到三个月，财务类三到六个月。如果六个月后收益层仍无改善，需要重新审视是口径问题、执行问题还是产品能力问题。
统一的第一步不是技术对接，而是列出每个平台的口径差异清单，然后逐项决定以谁为准、如何换算、无法换算的如何标注。这个清单本身就是项目的重要交付物。
当你的指标需要跨三个以上平台、五个以上店铺做汇总，且需要固定周期输出时，引入数据分析层是合理的。像数跨境这类工具解决的是口径统一和聚合效率问题，前提是你已经想清楚要算什么。
回到开头那个项目。后来我们做了一件事：把上线验收标准从"功能清单全部交付"改成"十二个指标全部达标"。范围争议立刻减少，因为争论从"功能够不够"变成了"指标到没到"。
我的核心判断是：跨境电商ERP改造的重点，不是把功能清单搬上线，而是用一套从项目推进、系统健康到业务收益的指标体系，把实施过程变成可管理、可验收、可复盘的项目。
功能决定系统能做什么，指标决定改造有没有价值。这两件事必须同时被管理。
如果你正准备启动或正在推进跨境ERP改造，我建议下一步做三件事。第一，选出三个北极星指标，必须包含一个健康层指标。第二，测出当前基线值，哪怕是手工统计的。第三，建立周报机制，跑满四周再评估。
四周之后你会得到一样东西：一场基于数据的讨论，而不是基于立场的争论。这本身就是改造成功的第一步。
我们公司准备上一套跨境ERP，我负责整理考核指标，结果运营、财务、IT各交了一份清单，加起来一百多条，周会上根本念不完。我心里很虚：指标少了怕漏，指标多了又没人看。到底该按什么逻辑砍到能落地的数量？
按三层来收，总量控制在12到15条以内。第一层是项目推进层，管的是这次改造能不能按时按质交付，留4条左右，比如范围冻结率、关键用户出席率、需求变更率、UAT缺陷关闭率。第二层是系统健康层，管的是系统能不能用得住，留4条左右，比如订单抓取成功率、库存同步延迟、主数据完整率、对账差异率。
第三层是业务收益层，管的是改造到底值不值，留4条左右，比如订单到发货平均时长、库存周转天数、缺货率、财务关账周期。每一层里只设一个北极星：项目层选范围冻结率，健康层选订单抓取成功率，收益层按你的模式选，铺货型选订单处理人效，精品型选库存周转天数。
判断一条指标该不该上墙，只用问三个问题：数据从哪个系统哪张表来、谁是第一责任人、多久看一次。这三问答不上来的，一律先不放，等有答案了再补。指标不是越全越专业，能被人记住并且每周真的去追的，才算数。
我们这套跨境ERP已经做了四个月，每次周会项目经理都说下周就能完成，结果一周推一周，运营那边已经开始不耐烦了。我不懂技术，只能看甘特图，可甘特图上的日期看起来一直很正常。有没有什么信号是能提前看出要出问题的？
别盯里程碑日期，里程碑是可以被不断顺延的，要盯领先指标。我一般看四个：一是需求冻结后的变更率，蓝图确认之后再提的新需求占总需求的比例，超过15%说明范围在失控，必须走变更评审并重新评估工期；二是关键用户出席率，业务负责人如果连续两次缺席评审会，基本可以判断这个模块上线后会没人用；
三是UAT缺陷关闭率，P1级缺陷关闭率低于90%就不批准上线，这条要写进退出标准，不能靠会议气氛决定；四是数据迁移准确率，主数据完整率低于98%、试迁移对账差异率高于0.5%，就不要排上线窗口。
操作上建议做一张红黄绿灯表，每周五更新，绿灯正常、黄灯需要项目经理给出补救动作和责任人、红灯直接升级到业务负责人和老板层面，升级路径要提前写好而不是临时找人。判断依据很简单：日期是滞后的结果指标，上面这四个是能提前两到四周预警的过程指标。如果你只能看一张表，就看变更率和P1缺陷关闭率这两条。
去年年底跨境ERP上线，老板问我这套系统到底带来了什么，我说订单处理快了不少、库存也准了，他接着问快了多少、准到什么程度，我就答不上来了。现在又要做新一轮改造预算，我特别怕再被问一次。到底该怎么把效果说清楚？
关键是上线前就要把基线建好，而不是上线后回头找数据。具体做法是：上线前四到八周，把你要考核的那几条业务指标按固定口径取一次数，形成一份基线快照，连同口径定义一起存档，比如订单到发货平均时长按什么时间戳相减、是否剔除预售单和缺货单、统计哪个店铺范围。
基线锁定后，上线后按完全相同的口径再取数，做同比而不是凭印象对比。建议锁五条：订单处理时长或人均处理单量、库存周转天数、缺货率、错发漏发率、财务关账周期。
归因上一定要划边界，大促、汇率、人员增减、平台流量变化都会影响这些数字，所以复盘时要把非系统因素单独列出来，只把可以追溯到流程改变的增量算作改造收益。我一般建议按季度做一次复盘，而不是上线一个月就下结论，因为流程磨合和数据清洗本身需要时间。
如果基线确实没建，那就退一步，用改造前后的流程动作数量做替代证据，比如原来一张订单要人工改三次状态，现在零次，这种可数的动作变化比百分比更经得起追问。
系统上线后我最头疼的就是数据问题：平台后台明明有两千单，ERP里只抓到一千九百多单；库存也是，海外仓显示还有货，ERP里显示为零。IT给我看接口日志说成功率99.9%，运营却说数据根本不能用。这两边到底谁说得对，我该怎么验收？
两边都没说错，是口径不同：接口成功率只说明请求发出去了、对方返回了200，不代表业务数据是完整的。验收要分三层看。
第一层是抓取完整性，订单抓取成功率等于ERP内当日订单数除以平台后台当日订单数，按店铺、按日统计，低于99.5%就要查是哪个店铺、哪个时间段丢的，常见原因是授权过期、限流重试没做、时区切分错位。
第二层是同步时效，库存同步延迟看P95而不是平均值，因为平均值会被大量正常数据掩盖，P95超过15分钟就说明有批次任务在排队，铺货型多店铺场景尤其容易出这个问题。
第三层是账实一致性，对账差异率等于差异金额除以总金额，日维度超过0.1%就必须当天定位原因，通常集中在退款、部分发货、平台佣金和汇兑这几类。
验收方法上，不要只用接口测试用例跑一遍，要用大促级别的模拟单量压一次，同时建一个异常单据池，把抓取失败、同步超时、对账不平的单据全部落库，每天有人认领、有人关单。这样IT看的是健康度，运营看的是可用性，两边的语言才能对上。
读者评论
这个案例太真实了，很多ERP上线就是功能签收完就散伙。订单抓取成功率、库存同步延迟这些健康层指标不建，业务只能继续手工兜底，系统永远成不了主路径。
三层指标按顺序建立有道理，但业务收益层在立项期就建基线很难。很多公司连过去三个月订单处理人效都拿不出干净数据，最后目标值只能拍脑袋。
跨境多平台的时间戳口径问题说到点子上了。下单、创建、揽收三个时间不一致，履约时效指标就是废的。这类数据治理必须放蓝图阶段，不能等UAT再补。
IT独角戏那段深有体会。什么叫订单处理完成、什么叫库存准确，业务不参与定义，验收时一定扯皮。指标责任人必须唯一，写到某个岗位而不是某个部门。