2021 年到 2024 年之间，我以外部顾问的身份参与过 11 个跨境电商 ERP 实施项目，其中 6 个项目的规模在年 GMV 5000 万到 3 亿之间。这 6 个项目里，只有 2 个在合同约定的上线时间之后 6 个月，一线运营真的把系统当成了日常工作台；另外 4 个，上线半年后运营还在用 Excel 排备货、财务还在手工对平台结算单。
更有意思的是失败与成功之间最明显的分水岭：不是系统选得好不好，而是这家公司有没有人因为系统里的数据质量被扣过钱。那两个用得起来的项目，都在上线前把数据质量写进了运营和财务的月度考核；那 4 个用不起来的项目，考核表上关于 ERP 只有一行字，"项目按计划上线"。
这篇文章要讲的，就是这一行字为什么是 ERP 实施最大的坑，以及"把系统实施纳入绩效考核"到底该怎么设计。我会先给结论，再拆误区，然后给出一个可以照着改的框架、五个能落地的指标口径、一套周月季节奏，最后讲清楚不同业务模式下该做什么取舍。
如果只让我说一句话，那就是：ERP 落地的成败，取决于有没有人为数据负责，而不取决于软件有什么功能。这句话听上去像常识，但我在项目里见到的大多数动作，都和这个结论相反。
第一个结论：ERP 项目失败的第一归因，通常不在软件功能。主数据不干净、流程没固化、没人对数据质量负责，这三件事排在功能缺失前面。我在 6 个项目的复盘里统计过归因分布，功能不满足导致的失败只占很小一部分。
第二个结论："上线（Go-Live）"和"落地"是两件事，中间隔着 3 到 6 个月的回退高发期。这段时间里，如果没有任何组织侧的强制力，一线会自然退回 Excel，因为 Excel 更快、更自由、不需要为别人负责。
第三个结论：绩效考核是让系统"从工具变成机制"的那根杠杆。前三层（战略、流程、数据）决定了系统能不能跑，第四层决定了它有没有人愿意让它跑。
经常有人问：既然考核最重要，为什么不先做考核？因为考核只是一根杠杆，杠杆需要一个支点。如果流程没定义清楚、主数据没治理干净，考核考出来的只会是错误的数据，一线会为了指标去调整操作方式，而不是调整业务结果。
所以顺序是：先定业务模式对应的系统边界，再把规则写成流程，再把流程依赖的主数据统一，最后才用考核把前三层锁住。这个顺序不能倒，倒了就会出现"指标很漂亮、业务没改善"的假象。
我不打算在文章里比较各家的功能清单和报价，这类内容已经很多了。这篇文章写给三种人：正在或刚刚完成 ERP 上线、但一线不愿用、数据不可信的运营负责人；需要向老板解释"为什么上了系统还是乱"的中层；以及正在谈实施合同、想提前把验收条件写清楚的项目负责人。
很多讨论把跨境电商 ERP 当成"国内电商 ERP 加个多语言"，这是一个很要命的简化。我做过国内电商的系统对接，也做过跨境，两者的复杂度不在一个量级上，而复杂度的差直接变成了实施难度的差。
第一是多平台。国内电商主要围绕少数几个平台转，跨境通常同时铺十几个平台和区域站点，每个平台的订单字段、退款规则、促销计算方式都不一样。每接一个平台，就多一套字段映射和一套异常处理逻辑。
第二是多店铺多主体。同一批货可能由不同主体、不同店铺销售，涉及不同的税务登记和资金回流路径。系统里的"主体"维度一旦设计错，后面所有报表的统计口径都会错。
第三是多币种。这不只是汇率换算的问题，还涉及记账本位币、结算币种、采购币种三者之间的差异，以及汇兑损益的归集时点。
第四是多仓形态。FBA 仓、第三方海外仓、自建海外仓、国内中转仓、在途库存同时存在，一个 SKU 的可用库存要跨五种状态计算。库存口径如果没有统一，盘点差异率这个指标本身就是假的。
第五是结算周期差异。不同平台的结算周期从 7 天到 45 天不等，还有预留金和争议款。应收对账的时点不统一，现金流预测就没法做。
跨境 ERP 的数据链路可以简化为三段：主数据 → 交易流 → 资金流。每一段都有一个典型的断点，而这三个断点都不是技术问题。
第一个断点在主数据。SKU 编码重复、供应商信息不完整、仓库与仓位定义混乱，是几乎所有项目上线后第一个月最密集的报错来源。这类问题技术上一改就好，难的是没人愿意承认是自己当初录错的。
第二个断点在交易流。采购下单、入库确认、调拨、备货计划、订单出库、退货入库，每个动作都要有人在系统里"确认"一次。如果确认这个动作对操作者只有成本没有收益，他一定会跳过。
第三个断点在资金流。平台结算单、支付通道流水、采购付款、物流费用，四份数据来源不同、时点不同、格式不同。这个断点最难，因为它天然跨越运营、财务、供应链三个部门。
我见过 IT 负责人独自扛 ERP 项目的案例，最后的结果基本都是：系统功能全部配置正确，流程文档写得漂漂亮亮，一线使用率长期低于三成。原因不复杂，IT 能改配置，改不了别人的工作习惯和奖金结构。复杂度越高，跨部门协调越多，就越需要一个有业务权的人来推动，而不是一个技术负责人。
下面这四个误区，我在项目里几乎每一次都会遇到，而且它们往往是叠加出现的。
上线是一个技术事件，落地是一个组织事件。上线当天系统能跑通订单流程，不代表半年后运营还愿意在里面录单据。我见过太多项目在验收会上宣布成功，然后在三个月后悄悄回到 Excel。
判断标准其实很简单：上线后第 90 天，运营查库存的时候第一个打开的是系统还是 Excel？如果是 Excel，项目其实还没落地。
这是本文的核心批判对象。进度型考核的问题在于，它考核的是一个一次性的、可被表演的动作，而不是一个持续的、必须真实反映业务的状态。
一旦进度成为唯一考核项，理性的一线会做什么？他会把单据补录到系统里把节点做漂亮，同时保留 Excel 作为真实工作台。这不是态度问题，是激励设计的必然结果。
数据质量问题很少是"录入的人"的错。数据质量是流程设计的产物：如果一个字段上游没有校验，下游没有用途，那它必然会被糊弄过去。
正确的做法是把数据质量的归属拆开：主数据由商品或供应链负责，单据及时率由仓配或运营负责，对账差异率由财务和运营共担。让某一个部门单独背全部责任，结果就是所有人都学会把问题推给那个部门。
培训解决的是"不会用"，解决不了"不想用"。如果系统里的操作对操作者本人没有收益，培训次数和实际使用率基本无关。
我在一个项目里做过对照：同样两轮培训，A 组运营的考核里有库存差异率，B 组没有。一个月后 A 组的系统单据完整度是 96%，B 组是 61%。培训内容完全相同，差别只在考核表上那一行。
我习惯把这套框架讲成四层。前三层是条件，第四层是杠杆。缺了前三层，第四层会把错误的事情放大；缺了第四层，前三层会在三个月内自然崩解。
铺货模式、精品自营、分销代发，这三种模式对 ERP 的能力诉求差异很大。铺货模式的核心是 SKU 数量和刊登效率，系统重点在批量处理和平台对接；精品自营的核心是备货准确率和库存周转，重点在预测和供应链协同；分销代发的核心是订单流转和结算清分。
先定模式，再定流程，最后才定系统配置。顺序错了，就会出现系统里配置了一堆用不上的功能，而真正需要的能力没做。
这一步的工作是把"老员工知道怎么做"变成"系统规定必须这么做"。采购下单要不要审批、入库差异超过多少要建异常单、调拨是仓库发起还是运营发起、退款走平台还是走系统，每一个决策都要落到具体的系统动作和责任人上。
我通常建议客户做一件事：把每个关键流程画成一张只有三个要素的图，触发条件、系统动作、责任人。凡是三个要素里缺一个的，说明这个流程还没定义清楚。
主数据包括 SKU、供应商、仓库与仓位、币种与汇率、税率、物流渠道。这些东西的共同点是：一旦错误，会污染所有下游报表，而且越晚发现修复成本越高。
我的建议是在功能上线前做一次主数据专项清理，明确每个字段的唯一责任人。这件事不性感，但它决定了后面所有指标能不能被信任。
前三层做完，系统具备了"能用"的条件；第四层决定它"被用"。这一层的核心设计不是考核多少分，而是回答一个问题：谁因为系统里的数据质量好或坏而受益或受损？
如果这个问题没有清晰的答案，前面三层做得再漂亮，都会在三个月内被 Excel 冲垮。
缺战略层，症状是系统配置和业务模式不匹配，一线觉得系统"不懂业务"。缺流程层，症状是同一件事不同人操作方式不同，报表口径天天打架。
缺数据层，症状是库存差异率、对账差异率长期高位，管理层逐渐不信任系统数据。缺组织与激励层，症状是系统里数据完整但没人看，一线两套账并行。
这一节是全文的核心。我想把"进度型 KPI 会逼出假数据"这个机制讲透，因为很多人只是隐约觉得不对，但没有把因果链说清楚。
当考核项是"本月完成 XX 笔单据系统录入"时，操作者的最优解不是每天录，而是月末集中把单据补进去。补录的单据在系统里存在，但它已经失去了业务意义，采购决策不可能依赖月后才录入的入库数据。
当考核项是"库存准确率不低于 X%"时，一线有两个选择：把实际库位核准，或者把账面数字调平。调整单比核对实物便宜得多。于是你会发现系统里的库存差异率很漂亮，但仓库里真的找不着货。
最隐蔽的一种。系统里该录的录，该点确认的点确认，但同时保留一套 Excel 做真实决策。表面上系统使用率 100%，实际上管理层看到的仍然是二手数据。
这三种副作用会形成一个自我强化的循环：数据质量差 → 管理层不用系统报表 → 一线觉得系统没用 → 更不愿意认真录 → 数据质量更差。
打破这个循环的着力点不在系统，在于让"数据质量"这件事有人利益相关。只要有一个人的奖金和系统里的某个结果指标直接挂钩，循环就有了反向的力。
结果型指标和动作型指标的区别在于：动作型指标考核"你做了什么"，结果型指标考核"业务结果是什么样"。前者可以被表演，后者很难。
举例：考核"每周完成一次库存盘点"是动作型，考核"库存差异率低于某阈值且差异原因在 48 小时内闭环"是结果型。结果型指标的天然好处是，它只能用真实业务动作来改善。
但这里有个前提：结果型指标的计算口径必须固定下来，并且数据来源只能是系统。如果指标可以从 Excel 里算出来，考核就失去了把业务拉进系统的力量。
我推荐从五个指标开始，不要贪多。每个指标都要写清三件事：归谁负责、多久看一次、异常时怎么处理。缺任何一件，指标都会变成挂墙上的数字。
口径是账面库存与实物盘点的差异数量（或金额）除以总库存数量（或金额），按仓库、按平台在库分别统计。一定要分维度看，合并成一个大数会掩盖问题。
归属上，海外仓和 FBA 由仓配负责人背，国内中转仓由仓储主管背。查看频率建议周看趋势、月度复盘。异常处理上，差异率超过企业内部基线时，必须在 48 小时内提交差异原因归集，而不是只提交调整单。
分两段统计：下单到出库的时长，以及异常单从标记到关闭的时长。第二段往往被忽略，但它才是真正反映流程健康度的指标。
归属上由运营负责人承担，因为订单能否及时出库通常取决于备货和库存可见性，而不只取决于仓库操作速度。
指入库、调拨、退货等单据在业务发生后 X 小时内完成系统录入的比例。这个指标是专门用来对付"月末补录"的。
我的建议是把时限设得足够短，比如 24 小时，让补录在物理上不可能凑出好看的月度数字。归属上由仓配和运营共同承担。
平台结算单金额与系统应收金额的差异，除以结算总额。这个指标最好由财务主责、运营配合，因为差异往往来自退款、促销、平台扣费的处理方式，两端都要认。
主数据的字段完整率和关键字段的准确率。这是唯一一个"前置型"指标，它不反映业务结果，但决定了其他四个指标是否可信。
下面是我在项目里常用的指标定义结构，写成配置形式是方便直接落进取数逻辑，避免口径在部门之间来回扯皮。
metric: inventory_variance_rate
name: 库存差异率
definition: 盘点差异数量绝对值 / 期间平均库存数量
grain: 仓库 × 平台在库 × 周
owner: 海外仓由仓配负责人，国内仓由仓储主管
source: ERP 库存台账 + 盘点单（不接受 Excel 来源）
threshold: 由财务与运营共同设定基线，逐季收紧
alert: 超基线 48 小时内提交差异原因归集，禁止仅提交调整单
review: 周看趋势，月度复盘，季度重设基线
这一点经常被忽略。很多人把系统落地的责任全部压在自己团队身上，却忘了一件事：实施方的交付质量，直接决定了内部团队有没有条件把系统用起来。
建议把项目拆成需求确认、方案配置、UAT 测试、上线切换、稳定期五个阶段，每个阶段列出明确的交付物。关键是交付物要可检验，而不是"完成培训"这类无法验证的表述。
可检验的交付物举例：字段映射表、接口异常处理清单、主数据模板、月结操作手册、稳定期问题台账。没有交付物的阶段，不能付阶段款。
问题要分级。影响订单流转和月结的问题，响应与解决时限要单独约定；配置咨询类问题可以宽松。没有分级，所有问题都会被当成"紧急"，SLA 就没意义了。
这一点我认为比前两点更重要。实施方离开之后，企业内部必须有一个人能看懂配置逻辑、能判断一个需求该不该提、能自己改简单规则。如果有这个角色，系统的长期可用性会好很多；如果没有，每一次小改动都要重新找人，成本高且慢。
所以在合同里，我通常建议把"培养出至少一名通过内部认证的系统运营"写成一个可验收的条款。
指标定完之后会遇到一个实际问题：数据分散在 ERP、平台后台、广告后台、财务系统里，靠人工拉表既慢又容易被质疑。我在一个项目里见过比较有效的做法，是把考核口径做成一套固定看板，让指标自己说话。这个项目用的是数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys），我把它作为一个可对照的做法讲，不作为唯一方案。
如果指标要靠人工每月导表计算，会出现两个后果：一是周期太长，一线看不到反馈，激励失效；二是口径容易变，每次算出来数字不一样，管理层就不信了。
看板的价值不在于好看，而在于把口径固定下来，让考核有稳定的事实基础。这也是为什么我在讲考核之前先讲框架，没有前三层的口径统一，看板做出来也是错的。
这个项目的数据源包括 ERP 的库存与单据台账、多个平台的订单与结算数据、广告投放数据、以及财务的应收数据。数跨境的作用是把这些来源接进来，用统一的 SKU 和主体维度对齐，避免同一个 SKU 在不同系统里叫不同名字。
库存差异率、单据及时率、异常单关闭时长、对账差异率、主数据完整率，各自做成按周更新的看板，并直接标注责任部门。看板上线之后最明显的变化不是数据变好，而是讨论会从"我觉得"变成"看第 37 周那一行"。
原来库存差异是月末盘点后才知道，追责也只能追到"这个月不太好"。改成按周更新后，差异一旦超过基线就会触发提醒，责任人当周就能处理。这个变化对一线的影响比考核本身更大。
这个项目在建立看板前，月度复盘会平均耗时 3.5 小时，主要是争论数字对不对；看板上线后，同样的复盘会平均 1.2 小时，且争议从"数字准不准"转向"异常怎么处理"。
库存差异率从 2.6% 降到 0.9%，异常单据平均关闭时长从 22 小时降到 7 小时。这些数字来自项目内部复盘，样本是单个项目，我更看重的是方向而不是具体数值。
指标设计好了，如果只挂在墙上，一个月后就会失效。考核真正起作用的地方是节奏，而不是分值。下面这三个节奏是我在项目里稳定用下来的。
会议时长控制在 30 分钟以内，参会人只包括异常相关的责任人和负责人。议程固定为三件事：本周超基线的指标有哪些、原因归集是什么、下周谁来处理。
关键约束是不做汇报表演。如果会上有人开始念"我们这周做了多少工作"，这个会就该结束了。周会的唯一产出是异常处理清单和责任人。
月度要做两件事：一是把五个指标的实际值和基线做对比，二是明确这个结果和奖金、晋升的关系。这个关系不需要很激烈，但必须真实存在。
我的经验是，哪怕挂钩的金额很小，只要它是真的，效果就比"高度重视"强十倍。因为一线能分辨什么是口号，什么是真的会影响自己收入的东西。
业务在变，指标必须跟着变。新开了一个平台、新建了一个海外仓、换了结算方式，考核口径都要重新审视。我见过不少企业用两年前的指标考核现在的业务，结果是一线为了达成指标做出明显不合理的动作。
季度复盘还要做一件事：检查有没有出现"为了指标而失真"的迹象。库存调整单突然增多、单据集中在某个时点录入、差异原因归集里全是"其他"，这些都是信号。
框架讲完了，但每家企业起点不同。下面按四种典型情况给出建议，你可以直接对号入座。
这个时候最重要的事不是比功能，而是先把自己未来要考核的五个指标写出来，然后拿这五个指标去问供应商：这些指标在你的系统里怎么取数、口径是什么、能不能按仓库和平台拆分。
如果供应商答不上来，说明这个系统在设计时没有考虑经营视角，后面你会花大量时间在系统外补数据。同时，把实施方的验收条款往第五节讲的方向去谈，尤其是知识转移那一项。
这个阶段最有价值的动作是做一次主数据专项清理，并把每个字段的责任人定下来。同时把关键流程画成"触发条件，系统动作，责任人"的三要素图，缺要素的流程先补齐再上线。
考核方案要在这时候定，而不是上线后再定。上线后定考核，一线会觉得是在针对他们；上线前定考核，它是项目设计的一部分，接受度高得多。
这是最典型也最难处理的情况。我的建议是先做一次诊断，不要直接改系统。诊断要回答：一线用 Excel 的真实原因是什么？是系统操作太慢、是数据不准、还是考核没挂钩？
我在项目里做过统计，操作太慢和功能不足加起来只占三分之一左右，更多是因为"系统里的数据不是我的工作依据"。如果是这个原因，改系统没用，改考核才有用。
这种情况需要一次比较硬的动作。我的建议是设一个明确的切换截止日，在此之前允许并行，之后系统数据成为唯一对外口径，Excel 只能作为分析工具而不能作为数据来源。
同时要准备好兜底：切换期内必然出现数据问题，需要有一个专门的响应机制，否则一线会用"系统不准"作为回到 Excel 的理由。
框架是通用的，取舍是个案的。这一节我讲四种常见取舍，以及我的判断依据。
铺货模式的 SKU 数量大、单品生命周期短，考核重点应该放在单据及时率和刊登到出单的转化效率上，库存差异率的重要性相对低一些，因为单品库存金额小。
精品模式的单品库存金额大，一次备货失误可能就是几十万的资金占用，这时候库存差异率和备货准确率的权重必须提高。用同一套考核表套两种模式，一定会有人做出错误动作。
单主体的公司，对账差异率可以主要由财务背。多主体的公司，收入确认和资金回流路径复杂，对账差异往往来自主体之间的调拨和结算，必须让运营和财务共担，否则财务会长期背一个自己控制不了的指标。
全用平台仓（如 FBA）的企业，库存实物在平台手里，自己只能看账面，库存差异率的可控性很低。这类企业应该把考核重点从库存差异率转向"账面库存健康度"，比如长期滞销库存占比、库存周转天数。
自建海外仓的企业，实物在自己手里，库存差异率是完全可以被管理的指标，权重可以提高。
如果资源确实有限，我的优先级建议是：数据层 > 组织与激励层 > 流程层 > 战略层。这个顺序看起来反直觉，但逻辑是：主数据是其他一切的基础，花不了太多钱但收益最持久；组织与激励层几乎不花钱，只需要管理层下定决心。
流程梳理和战略规划往往需要外部咨询资源，成本较高，可以在前两层见效之后再投入。
很多企业会考虑招一个"系统运营"岗位。我的判断是：如果内部现有的人能承担这个职责，优先内部培养，因为这个人必须懂业务细节，外部招聘的学习成本很高。但如果一年内换了三个人都做不好，说明问题在职责设计而不是人的能力，那就该考虑外部协助了。
写到这里，我想把最核心的判断再说一遍：ERP 落地的终点不是系统上线，而是数据有人信、有人管、有人为它负责。
软件不会自己创造管理。它只是把责任关系变成可被观测的数据。当库存差异率挂在一个人的月度考核上，这个人才会去仓库核实物而不是调账面；当单据及时率被逐日统计，月末集中补录就没有了空间。这些变化和系统功能无关，和激励设计有关。
反过来也成立：如果系统里的数据谁都不需要负责，那它迟早会变成一份昂贵的电子台账。一线不是不愿意用系统，是不愿意为一个自己不用承担后果的东西付出额外工时。
下一步我的建议是，别急着动系统，先花一周时间做三件事。第一，把你们现在真正在用的五个考核指标写下来，看看有几个的数据来源是系统；第二，找出"谁因为数据质量被扣过钱"这个问题的答案，如果答案是没有人，那这就是你要改的地方；第三，选一个指标，从下周开始按周更新，把异常处理时限明确到人。
一周之后你会发现，真正卡住 ERP 落地的从来不是功能，而是那行一直没写进考核表的字。先把它补上。
我在公司负责ERP落地，老板让我出一套考核办法，我第一反应就是写“6月底完成上线、模块覆盖率达到100%”。结果那两个月单据全是月末集中补录，账面上线了，实际业务根本没跟着走。我就在想，考核是不是一开始方向就定错了？
考结果型数据指标，不考动作和进度。
可落地的口径控制在五个以内：库存差异率（账面与实物，分仓、分平台看）、订单履约时效（下单到出库、异常单处理时长）、单据及时率（入库、调拨、退货单据在业务发生时录入的时效，按小时或工作日计）、对账差异率（平台结算单与系统应收的差额）、主数据完整率与准确率（SKU、供应商、仓库、币种、税率）。
每个指标必须写清三件事：归谁负责、多久看一次、异常时走什么处理路径。基线不要照搬别人的百分比，由财务和运营共同设定初始基线，再按季度逐季收紧；考核动作型指标（录了多少单、培训出席率）只会催生补录和走过场。
我们团队二十多人，ERP上了快半年，运营还是习惯导Excel对库存，月末财务照样手工核账，我跟他们说了很多次都没用。后来我发现，不是他们懒，是系统里的数跟实际对不上，谁都不敢拿它做决策。
根因不是执行力，是没人对数据质量负责。第一步先把系统的“唯一账”地位写进制度：凡是涉及库存、应收、提成计算的数据，一律只认系统口径，Excel只能作为临时分析副本，不能作为结算依据。第二步设一个数据责任人角色，注意不要放在IT，通常由供应链或财务的骨干兼任，职责是盯异常、追原因、定整改期限。
第三步开每周异常数据复盘会，只看异常单，不做汇报表演，每条异常落到具体的人和日期。判断依据很简单：如果同一笔库存差异连续两周没有人认领，说明是责任没分到位，不是系统能力不够，这时候继续加功能只会让问题更隐蔽。
老板隔三差五问我系统用得怎么样，我每次都说已经上线了，但说这话的时候心里其实没底。合同签了、钱付了、培训也做了，可运营和财务的实际动作跟以前差不多。我特别想知道，有没有一个能拿出来说话的判断标准。
把上线和落地分开看。上线是Go-Live，落地要看上线后3到6个月的稳定期，这个周期可以在合同里约定。三个判断信号：第一，系统数据能和实物、平台账单对上，库存差异率和对账差异率稳定在你设定的基线区间内，而不是忽高忽低；
第二，关键单据是在业务发生的当时录入的，不是月底集中补，这个可以直接查系统里单据创建时间的分布，集中在月末最后两天就是危险信号；第三，管理层开会用的是系统看板，而不是运营临时导出的表格。
三条都成立才算落地，任何一条长期不成立，都属于假上线，表面有数据，但没有决策价值，管理层不用，一线就更不会用，会形成越不用越不准的负循环。
我们当初买系统的时候，销售承诺得特别好，说随叫随到。结果款付了大半以后，提个问题要等好几天，配置改动还要另外报价。下次再签合同，我想留点能约束对方的手段，但不知道具体该写什么。
要考核，而且必须在合同里体现，核心是三个抓手。第一是里程碑验收：把需求确认、系统配置、UAT、上线、稳定期拆成节点，每个节点列出明确的交付物清单，验收通过才支付对应款项，尾款留到稳定期结束再结。
第二是服务响应SLA：把问题分级，比如阻断类、影响类、咨询类，分别约定响应时限和解决时限，并写明超时的处理方式。第三是知识转移：要求实施方培养出内部能独立完成日常配置和取数的角色，交付操作文档和培训记录，而不是把所有调整都捏在自己手里。
判断依据是：如果一个服务商只愿意承诺功能上线，不愿意对稳定期指标作任何承诺，那基本说明他自己对这套系统在你业务场景里能不能跑起来也没把握。不要在合同里买“服务态度”，要买可验收的结果。
读者评论
把ERP落地归因到考核杠杆这一点很扎心。我们公司上线一年，运营还在用Excel排备货，考核表上确实只有'按计划上线'一行字。问题不在系统功能，在于没人对数据质量负责，补录单据成了应付验收的表演。
跨境ERP的复杂度分析比较到位，多平台、多币种、多仓形态确实让库存口径很难统一。但样本只有6个项目，结论说'考核口径决定一线核对还是掩盖'，力度偏强，更像经验判断而非统计结论。
四层框架的顺序值得参考，先定业务模式边界再写流程，最后用考核锁住。不过把考核放到第四层容易被误读成'先别考核'，实际推进中主数据治理和考核往往得同步启动，否则前三个月就退回Excel了。