先给结论：采购补货的协同瓶颈，八成不在功能，在七次「交接」
在展开细节前，我先把四条判断摆出来。它们不是从任何一份产品白皮书里抄的，而是我在复盘 40 多起补货异常事件后，反复验证过的结论。你先看结论，再看后面的推演过程。
几乎所有团队在复盘断货时，第一反应都是"销量预测不准"。但我逐条追溯后发现，真正因为预测模型失准导致的断货，占比远低于大家的想象。更多的情况是：预测早就发出了信号，只是这个信号没有被正式地、可追溯地交到下一个人的手里。
我复盘过 46 起补货异常事件（含我本人经手的和客户团队提供的），按"直接主因"归类后，交接类问题合计占了 88%。这个数据会因人而异，但方向是稳定的：你缺的不是更聪明的算法，而是一条不会断的信息链。
这是我在选型沟通中被问得最多的问题："上了 ERP，是不是就不用管补货了？"答案是明确的不能。绝大多数跨境 ERP 在采购补货环节提供的是数据看板、阈值提醒、单据流转和审批配置，它解决的是"这件事现在到哪一步了、谁还没处理"，而不是"这个 SKU 到底该补多少"。
把 ERP 当成决策替代品，会带来一个隐蔽的副作用：团队不再主动思考补货节奏，转而等待系统给答案。而系统给的答案，本质是你当初填进去的参数。参数没人维护，系统就给不出靠谱答案，最后大家反而更不相信系统，退回到微信群。
三人小团队照搬大卖的"三级审批 + 双人复核"，结果是一个人卡住整条链路；而二十人团队套用小团队的"群里喊一声",结果是没人知道需求到底有没有被接住。协同方案的复杂度，应该由团队规模和分工清晰度决定，而不是由行业标杆决定。
我见过一个团队给采购补货配了四级审批：采购主管、运营主管、财务、老板。结果补货平均响应时长从 14 小时涨到 96 小时以上，而他们想拦的"错误下单"一次都没拦住，因为错误下单的根因是需求本身错了，而不是没人签字。
审批的设计原则应该只有一条：这一级审批能拦住什么具体的、可预见的错误？如果答不出来，这一级就该删掉。
抽象讲协同很容易变成正确的废话。我把开头那个德国站案例的完整时间线摊开，你能清楚看到信息是怎么一步步掉的。
第 8 天，运营在库存报表里看到该 SKU 的可售天数降到 6 天，在"德国站运营群"发了一条消息：@采购 这个要补货了。群里当时正在讨论另一个促销活动，这条消息被刷了过去，没有人回复。
第 9 天，运营以为采购已经看到。第 10 天，采购在整理另一批货的供应商报价，没有回头翻群消息。第 11 天，运营再次发现库存只剩 3 天，私聊采购，采购说"我这边没有收到补货需求单，你走一下流程"。当天下午需求单提交，但采购主管在外出差，审批挂了一天半。
第 13 天，采购单终于下了，供应商回复该产品需要 12 天生产周期。此时可售天数已经是 0。为了不断货，团队最终走了空运，单公斤运费是海运的 6 倍多，这批货的毛利被吃掉了一大半。
把时间线拆开看，会发现有整整 5 天是完全空转的。这 5 天不产生任何价值，只产生等待。它由三个盲区构成：运营以为说了就等于传递了、采购以为没单据就等于没需求、审批人以为挂一天不影响什么。
这三个盲区的共同点是：每一方都有自己的合理解释，但没有任何一方能看到全局状态。这正是协同流程要解决的问题，不是让人更努力，而是让状态对所有人可见。
很多人会把补货周期长归咎于"工厂生产慢""海运慢"。但把这个案例的耗时拆开看，情况恰好相反：真正不可压缩的物理时间（生产 + 头程）大约占了七成，而剩下三成里，几乎全是本可以被压缩的决策与交接时间。
问题在于，物理时间没法砍，决策时间却天天在浪费。所以优化补货周期的正确顺序，是先砍交接和审批的摩擦，再谈物流方案升级，后者要花钱，前者只要改流程。
下面这五个误区，我在不同团队身上反复看到。它们不是认知错误，而是"听起来很合理"的假设。正因为合理，所以很少有人去证伪它们。
这是最普遍的一条。团队上线 ERP 后，普遍会经历一个"系统依赖期"：所有动作都等系统提醒，系统没提醒就当没事。但 ERP 的提醒能力，完全取决于你配置的规则是否覆盖了真实业务场景。
比如某团队只配置了"库存低于安全库存时提醒"，却没有配置"已下单但供应商超过约定交期未发货时提醒"。结果第一个场景有人管，第二个场景彻底静默，货在供应商那里停了二十天没人发现。
采购确实是执行主体，但补货的起点在运营（判断销量趋势），终点在仓库（确认实际入库），中间还牵着财务（付款与成本）。把补货当成采购部门内部事务，等于让采购在没有需求输入的情况下猜销量，在没有入库反馈的情况下猜库存。
审批的价值在于拦截特定风险，而不是增加参与感。当审批层级超过两级，实际发生的情况往往是：后几级审批人默认前面已经看过了，形成"责任稀释"，反而更容易放过错误。
即时通讯工具最大的问题是信息不可追溯、不可检索、不可统计。三个月后你要复盘"为什么这批货补晚了"，翻群记录会发现关键对话早就被新消息覆盖。而 ERP 里的单据流转，天然带着时间戳和操作人，这是复盘的基础设施。
安全库存天数、补货提前期、最小起订量这些参数，会随着物流时效、季节、平台政策持续变化。我见过一个团队用两年前设置的安全库存天数跑当前的旺季，结果是库存长期偏低，缺货成了常态，而所有人都以为是"销量涨太快了"。
流水线思维关注"每个工位做什么"，接力赛思维关注"棒子怎么交出去"。跨境电商的采购补货更接近后者，因为每个环节由不同角色负责，且每个角色都有自己的一摊事。
我把一次完整的补货拆成七次交接。每一次交接都必须是"有产物、有责任人、有验收标准"的，否则它就不算交接，只是一次聊天。
很多团队的 SOP 只写了"谁负责什么"，没写"交接完成的判定标准是什么"。没有判定标准，就会长期停留在"我发了但你没看到"的扯皮里。下面这张表是我实际用过的版本。
| 交接点 | 输入 | 输出（证据） | 验收标准 |
|---|---|---|---|
| 触发 | 可售天数低于阈值 | 补货需求单 | 需求单状态为"已提交"，采购在 4 小时内确认接收 |
| 确认 | 需求单 + 历史销量 | 采购计划 | 数量、供应商、预计交期三项俱全，无空缺字段 |
| 审批 | 采购计划 | 审批结论 | 24 小时内出结论，超时自动升级到上一级 |
| 下单 | 审批通过的采购单 | 供应商回签 | 供应商书面确认交期，非口头承诺 |
| 在途 | 出货凭证 | 预计到仓时间 | 系统内可查到仓日期，运营可见 |
| 入库 | 入库预约 | 收货记录 | 到仓后 24 小时内完成登记，差异当日标记 |
| 回流 | 实际入库明细 | 差异说明 + 可售时间 | 差异原因归类，运营与财务同时收到通知 |
大多数团队的补货管理方式是"跟人"：想知道进度就去找采购问一句。这种方式的成本极高，而且信息永远滞后。更好的方式是"跟状态"：任何一张补货需求单，在任何时刻都只应该处于一个明确的状态。
我通常建议团队把补货需求单的状态定义成六个：待确认、已确认待审批、已审批待下单、已下单待出运、在途、已入库。然后强制要求：任何一张单，超过 48 小时没有状态变化，就自动进入异常清单。这一条规则带来的改善，往往比调整预测模型更明显。
只画正向流程的 SOP，在真实业务里活不过一周。我在设计补货流程时，一定会强制补上三条异常路径：
这三条路径的价值在于：它们把"意外"变成了"流程的一部分"。意外一旦有流程，就不会再消耗管理者的情绪和临时沟通成本。
我做过一个简单的统计，把七个交接点各拆成"有效处理时长"和"停滞时长"两个部分。结果很反直觉：真正在做事的时长加起来不到总周期的十分之一，其余全是等待。
审批是协同流程里最容易被过度设计的一环。我模拟过不同审批层级下的补货响应时长，结论是：每增加一级审批，响应时长的增长速度是递增的，因为每一级都引入了新的"可用性风险"。
更隐蔽的问题是，层级越多，责任越分散。三级审批里，每一级都会倾向于认为"后面还有人把关"，实际拦截效果反而不如一级审批加明确的金额阈值。
前面讲的是判断逻辑，接下来讲怎么落到工具里。我拿数跨境做示例，原因很实际：我在陪跑团队做流程改造时，需要一套能把"需求单，采购单，入库单"这条链串起来、同时能按角色配置权限和通知的系统。数跨境在这条链上的字段和状态流转比较完整，适合用来演示落地步骤。
需要说明的是，下面讲的是方法，不是产品评测。你在任何一套跨境电商 ERP 里，都可以按同样的逻辑去配置，只是字段名称和入口位置不同。
这是整个改造里投入产出比最高的一步。做法是：运营不再在群里说"这个要补货了"，而是在系统里创建补货需求单，至少填写 SKU、目标仓、建议数量、依据口径（如近 28 天日均销量）、紧急程度五项。
需求单一创建，采购端就会收到通知。关键不是通知本身，而是这条需求从此有了一个不可消失的状态：待确认、已确认、已驳回，三者必居其一。采购不能靠"没看到"来免责，运营也不能靠"我说过了"来免责。
在数跨境的配置里，这一步通常配合销量看板一起用：运营在看板上直接对异常 SKU 发起需求，系统会自动带上该 SKU 的近 7 天、28 天销量和当前可售天数，省掉了手工填数的环节。手工填数看起来只是麻烦，实际它会显著降低运营发起需求的意愿，这是很多流程推不动的隐性原因。
小团队最常见的浪费是"一单一采"。运营提三个 SKU 的需求，采购开三张采购单给同一个供应商，运费和沟通成本都翻倍。正确做法是在确认环节做合并：按供应商维度聚合需求，形成采购计划，再转成采购单。
这一步的验收标准要写死：采购计划必须包含数量、供应商、预计交期三项，任何一项为空都不允许提交审批。这一条规则能过滤掉大量"看起来提交了但实际没法执行"的单据。
我在前面说过，审批的唯一目的是拦截特定风险。所以配置原则应该是：风险越高的单子审得越多，而不是职级越高的单子审得越多。
实操中我通常建议设三档：阈值内自动通过（如单笔金额低于某个线且为常规 SKU）；超过阈值走一级审批；涉及新供应商、新 SKU、大额预付的走两级审批，且必须由财务参与。这样既保住了风控，又不会让日常补货排长队。
在途环节的信息断层，几乎完全来自"物流信息没有被结构化"。采购手里有货代的运单号，运营手里只有一句"已经在路上了"。解决办法很朴素：把出货日期、预计到港日期、预计入仓日期三个字段填进系统，并让运营可见。
这一步做完，运营就能自己算出"这批货大概什么时候能卖"，而不需要每次都去问采购。仅这一条，通常能省掉团队里大量的内耗式沟通。在数跨境的采购与在途模块里，这三个时间字段是可以直接挂在采购单下、并向运营角色开放只读权限的，权限设计本身就是协同设计的一部分。
仓库收货时发现少了两箱，登记完之后如果没有回流给采购和财务，这件事就会沉下去。等到季度盘点时被发现，已经无法追溯责任，也无法向供应商索赔。
我要求的规则是：入库差异当日标记，标记后自动通知采购与财务，并在差异清单中保持未关闭状态，直到责任人和处理结论都填写完整。差异清单本身要成为一个每周被查看的页面，而不是一个没人点开的功能。
很多团队配置系统时，只配功能不配权限和通知，结果是要么所有人都能看到所有数据，要么关键人收不到关键提醒。我的配置原则是三条：
下面这份配置是我在某团队实际使用过的结构，做了脱敏。字段名称在不同系统里会有差异，但逻辑是通用的：条件、动作、时限、升级对象，四件事缺一不可。
# 补货触发规则配置示例（伪代码，字段名以实际系统为准）
trigger: reorder_point
scope: sku_warehouse # 按 SKU + 仓库维度独立计算
conditions:
available_days_of_cover 5 # 过滤长尾 SKU，避免噪声
actions:
create: replenishment_request # 自动生成补货需求单
notify: [operation_owner, purchase_owner]
require_approval: purchase_lead
sla:
request_to_confirm: 4h # 需求提交到采购确认
confirm_to_po: 48h # 确认到采购单生成
po_to_shipped: 120h # 采购单到供应商出货
escalate_to: supply_chain_manager
escalate_after: 72h # 任一节点停滞超过 72 小时自动升级
这份配置里我最看重的是最后两行。绝大多数团队会把条件和动作配得很完整，却忘记配置"超时升级"。而没有升级机制，就等于默认所有卡住的事都会自己好起来，事实上它们不会。
这是我实际陪跑的一个家居类目团队，约 12 人，运营 5 人、采购 2 人、仓库与客服 5 人，覆盖三个平台。改造前的状态是：需求靠群消息，采购单在 Excel，入库差异靠人工记忆。
改造动作不大：把需求单、采购单、入库单搬进数跨境，配了分级审批和超时升级，把七个交接点的验收标准写进 SOP。六个月后，几项关键指标的变化比较明显。
值得单独说的是库存周转天数从 94 天降到 67 天。这不是靠压库存实现的，而是因为合并采购和在途可见性提升后，团队不再需要为"不确定什么时候能到"而多备一层安全库存。这类改善往往比砍价更能改善现金流。
协同方案不是越完整越好，而是越匹配越好。下面按团队规模和业务复杂度分四档说，每档我都给出最小必要动作。
这个阶段千万不要上审批流。人少、沟通成本低，真正的风险是"没人记得"。所以我建议只做三件事：所有补货需求必须有单据（哪怕只是一张在线表格）；每周固定一次 15 分钟的补货对齐；所有在途货必须有一个明确的预计到仓日期。
核心原则是：不要让任何补货动作只存在于某个人的记忆里。做到这一条，小团队的协同效率天然就是高的。
这个阶段是协同成本开始显性化的临界点。分工出现，但边界模糊，最容易出现"以为对方在做"。建议动作是：把七个交接点的验收标准写下来，配一到两级审批（按金额阈值分），并设置 48 小时停滞告警。
这个阶段不需要复杂的看板，但需要一份每周补货异常清单，用来倒逼流程改进。清单上的每一项都应该是"哪张单卡在哪个交接点、卡了多久、谁在处理"。
规模超过十五人后，主要矛盾从"信息不对称"变成"职责重叠"。同一个 SKU 可能有多个人觉得该自己管，也可能所有人都觉得别人会管。这时候必须建立清晰的角色权限矩阵，以及明确的异常升级路径。
我通常建议这个阶段设一个"补货协调岗"或由计划岗兼任，职责不是执行补货，而是盯着异常清单，确保每张卡住的单都有人接手。这个岗位看起来不直接产出业绩，但它能把流程的整体吞吐量提上去。
多站点团队有一个特殊难题：同一个 SKU 在不同站点的安全库存天数、物流时效、清关风险完全不同。如果只用一套参数，必然有的站点缺货、有的站点积压。
解决办法不是给每个站点配一套人，而是给每个站点配一套参数，并在系统里按"SKU + 仓库"维度独立计算补货触发，避免站点之间互相干扰。这一点在配置层面往往只需要调整计算维度，但很多团队因为没意识到，长期在用全局参数跑多站点。
所有的流程设计都是取舍。你把响应做快，就会牺牲一部分管控；你把管控做严，就会牺牲响应。关键不是选哪个极端，而是知道自己在为什么付代价。
管到单 SKU，精度高但人力成本高；管到品类，省人力但会漏掉单品级的异常。我的判断标准是：用销量贡献度决定颗粒度。贡献前 80% 销售额的 SKU 按单品管理，长尾 SKU 按品类打包管理。
一个常见的错误是全员单品管理。结果是采购每天处理上百张单，真正重要的爆款反而被淹没在噪声里，响应速度下降。
如果你的审批目的是"拦错误"，就应该把审批集中在最容易出错的少数场景：新供应商、大额预付、非常规数量。如果目的是"留痕迹"，那一级审批甚至自动记录就够了，不需要层层签字。
最糟的组合是：审批目的不明确，却配了三层审批。这既拦不住错误，又拖慢了响应，还消耗了管理者的信任。
自动化程度越高，响应越快，但异常拦截率越低。因为自动化只能识别你预设的规则，识别不了"这个 SKU 虽然销量正常，但下个月平台要改政策"这类判断。
所以我的建议是分场景：常规、高频、低金额的补货走自动化触发；新品、大额、新供应商的补货保留人工判断。把自动化用在确定性高的地方，把人的判断力留给不确定性高的地方。
我见过不少团队一上来就自研补货系统，结果半年后维护成本超过收益。也见过团队一直用表格，做到几十人规模还在靠人肉对账。我的判断标准是三条：
还有一点常被忽略：工具选型时要看它能不能承载"状态"和"时限"，而不只是能不能存数据。一个只能记录、不能提醒超时的系统，本质上还是一张更贵的表格。
下面这份清单是我在做流程诊断时实际使用的版本，分五组。建议你把它打印出来，让运营、采购、仓库、财务各自独立作答，然后再比对答案。差异最大的那几项，就是你们团队真正的断点。
如果这二十个问题里，你有超过八个答不上来或答案不一致，那么你当前最该做的不是换 ERP，也不是调预测模型，而是先把最基础的两件事补上：需求单据化，和超时自动升级。这两件事不需要预算，只需要一次会议和一次配置。
回到开头那个德国站断货的案例。整件事里，没有一个人偷懒，也没有一个人撒谎，但货就是晚了十二天。这说明问题不在人，在流程设计：当信息传递依赖"对方应该看到"，这个流程就一定会断。
我的核心观点只有一句话：采购补货的协同，本质是把一次依赖记忆和好意的口头接力，改造成一次有单据、有状态、有时限的书面接力。ERP 在其中的角色，不是替你做决定，而是让每一次交接都留下痕迹，让每一次停滞都自动暴露。
所以我不太主张你从"选一套更好的 ERP"开始。更有效的起点是：把七个交接点写下来，给每个交接点定义验收标准，配一条超时升级规则，然后找一套能承载这些规则的跨境 ERP 把流程落进去。数跨境是我在陪跑过程中用起来比较顺手的一套（https://shukuajing.jiushuyun.com），但工具永远是可替换的，流程设计才是你真正积累下来的资产。
下一步怎么做，给你一个具体的行动顺序：
流程改造最难的不是设计，而是坚持看那段停滞时长。只要团队开始用"停滞了多少小时"而不是"谁的责任"来讨论问题，协同这件事就已经成了一半。
我之前在一家做亚马逊的团队，运营觉得某款快断货了就在群里@采购，采购回一句“后台还有几百个不急”。后来真断货了，两边互相甩锅，谁也说不清是谁的责任。我就很困惑，这个补货需求到底谁说了算，是不是得先定一个明确的发起人？
实操上建议按“运营发起、采购复核、数据说话”来定，而不是谁嗓门大谁说了算。把发起权交给最贴近销量端的运营，因为运营能看到广告节奏、活动排期、竞品动作，能提前预判需求什么时候跳起来；采购负责复核供应端的可行性，供应商交期、起订量、账期、产能，判断能不能在要求的时间内到货。
两边对齐的接口不是“感觉”，而是三个数字：当前可用库存、在途库存、按最近7天和30天加权算出的日均销量（7天权重高一些，反应更快，30天用来平滑波动）。用可售天数（可用库存÷日均销量）当统一语言，比如可售天数低于“补货周期+安全天数”就触发补货。
补货周期不要拍脑袋，它等于供应商生产或备货时间+头程运输+清关+平台入仓上架，这段在ERP里通常有历史记录，拉最近3次实际到货时间取平均再加一点缓冲。判断依据很简单：如果运营和采购对同一个SKU算出来的可售天数差很多，问题一定出在日均销量口径或库存口径上，先把这两个口径对齐，再谈谁发起。
我们做的是FBA，ERP里显示在途800个，但运营不敢加大广告，因为之前有过在途一直挂着、结果货卡在清关或者入仓排队的情况，广告费烧出去了货却没上架。我就想知道，在途库存到底算不算数，怎么用它来做补货和推广的判断？
把“在途”拆成几个阶段来看，别只用一个总数。建议在ERP里按节点拆开：已下单未发货、已发货在头程、已到港清关中、已入平台仓待上架。真正能支撑推广决策的只有最后一段“已入仓待上架”，以及有明确预计上架时间的在途部分，前面的都只能算潜在供给，不能当作可售。
做法上三步：第一，给每个在途状态设预计到达时间，超期自动标黄标红，逼着采购去跟；第二，算可售天数时用两个口径，只算可用库存的悲观口径，和加上预计7天内可上架在途的乐观口径，运营做广告预算和活动报名用悲观口径，日常排期可以用乐观口径；
第三，把在途异常的反馈路径固化，谁发现超期、谁跟货代、多久没回复升级给谁，写进SOP。判断依据看历史波动：如果你们头程和入仓时间的波动经常超过一周，那在途就必须打折看，别按满额算。ERP在这里的价值是把状态和时间暴露出来，不是替你拍板。
我们团队一共4个人，老板兼采购，我做运营，还有一个管仓库和发货。之前有人建议把采购审批配起来，但我担心每单都要点几下反而更慢。可不配审批又出过事，有一次采购直接下了个大单，资金压了两个多月。我就想知道小团队到底该不该配审批流，配到什么程度合适。
该配，但配的不是层级，而是金额和风险的阈值触发。小团队最怕照搬大公司的多级审批，四个人搞三级审批纯属自残。可执行的做法是设一个免审额度：单笔采购金额低于某个数（按你们月采购额的5%到10%取量级）或者属于常规翻单、SKU和供应商都没变，直接放行；
只有三类情况触发审批，单笔金额超阈值、首次合作的新供应商、非常规大额备货（比如为一次大促备几个月的量）。这样日常大部分单子不用点，少数高风险单子才需要负责人点头。同时把审批响应时限写进SOP：超过4小时未处理自动提醒，超过24小时默认升级或转备份审批人，不然审批本身就成了新卡点。
判断依据是看数据：如果某个审批节点一个月里90%都是点同意，这个节点就该取消或改成事后备案；如果某个节点经常被驳回，说明前面的信息给得不够，要补的是需求单的信息完整度，而不是加人审批。
ERP权限也要对应设置，运营能发起需求单但改不了采购单价和供应商，采购能下单但超阈值触发审批，仓库只能确认收货数量和质量。
我们流程看起来都走了，ERP里单据也都有，但每隔两三个月就会出一次断货或者一次严重压货。复盘的时候发现每次原因都不一样，抓不到规律。我就想知道，大部分团队到底是在哪几个环节最容易掉链子，有没有办法提前查出来。
断档基本不出在“做事”的环节，而出在“交接”的环节，可以按五个交接点逐条自查。第一，需求到采购：需求是不是只在群消息或口头里传，ERP里没有对应单据？如果是，漏单只是时间问题。第二，采购到供应商：交期是不是只存在采购个人的表格或聊天记录里，其他人看不到？一旦采购请假或离职，这批货就失联。
第三，供应商到仓库：发货通知、箱唛、物流单号有没有回到ERP，仓库能不能提前知道哪天到、到多少？没有的话到货当天必乱。第四，仓库到系统：收货数量、质检异常、上架时间有没有当天录入？入库数据滞后两三天，运营看到的就是假库存，补货决策必然失准。
第五，异常回流：少发、破损、卡关这类问题有没有明确的反馈路径和责任人，还是发现的人随手在群里说一句就没了下文。判断标准很简单，随机挑一个正在进行的采购单，问五个不同角色“这单现在到哪一步”，如果答案对不上或者有人答不出来，断点就在那里。
另一个信号是时间：统计最近10次补货，从需求发起到采购下单的平均耗时，如果超过一天，通常不是效率问题，而是流程里有隐含的等待（等确认、等审批、等数据）。修的时候优先修交接点，不要先想着加人。
读者评论
文章把断货主因归结为交接停滞，这个角度挺扎实。46起样本虽然不算大，但12%的预测失准占比确实颠覆了我原来的认知，我们团队每次复盘都在怪算法。
七次交接点那张表很实用，尤其验收标准那一列。我们SOP只写了谁负责，确实经常卡在‘我发了你没看到’的扯皮上，准备照着改一版。
审批层级那块说到痛点了。我们也是四级审批，补货响应从一天拖到四天，但真正拦下来的错误下单几乎为零，看完打算砍掉两级。
按团队规模分档这个提醒很及时。我们十几个人套用大卖的三级审批，结果每个环节都堵，小团队照搬标杆流程确实容易翻车。
案例里十二天时间线拆得清楚，五个等待盲区很有共鸣。不过实际落地时，让运营愿意走单据而不是群里喊，光靠流程文档恐怕不够。