选型时最该问供应商的三个问题

2025 年，一家工贸一体的公司要为海外四个国家的门店选系统。招标表填得满满当当：销售、库存、售后、报表，一项不落，得分最高的供应商中标。上线半年，问题在第二个国家爆发——报价单里的税费是错的，因为当地的税制口径和第一个国家不一样；请供应商改一次口径，对方回复：要动表结构，报价六个月。公司这才发现，招标时他们问的是「有没有这个功能」，从没问过「这个功能换到别的国家，还行不行」。这是一次典型的选型事故，把它复盘一遍，比读十份选型指南有用。

复盘一：事故不是发生在第二个国家，是发生在招标那天

把事故按时间倒推，真正的分水岭在招标那天。

招标阶段，评估维度是功能对照表：谁的功能打勾多，谁的分就高。这套方法默认了一个前提——业务是静态的。可出海业务恰恰是动态的：今年在一个国家，明年可能三个；今年的税制，明年就调。

上线阶段，第一个国家勉强跑通，因为那是最熟悉的场景。到了第二个国家，才发现每一处「不一样」都要重新开发：税制、单证、语言、币种、仓库口径。

所以事故的根因，不在第二个国家的团队不配合，在招标阶段没人把「换国家」设成考题。事故不是一个点，是一条从招标那天起就埋下的线。

复盘二：为什么功能清单会骗人

功能清单衡量的是「有没有」，出海真正要回答的是「变不变」——而当下的规则，变得比多数人预想得快。

巴西这边，自 2026 年 7 月 1 日起恢复 CKD 与半散件的零关税配额，超配额部分按 35%/14% 分档征税，且规定 2027 年 1 月起 CKD、SKD 税率统一到 35%——同一套卖车逻辑，税制口径一年之内容易调整。

泰国这边，EV3.5 政策要求 2026 年进口与本地生产比例达到 1:2、2027 年升至 1:3，进口电芯计入本地化采购率的比例自 2026 年 7 月 1 日起归零——合规口径在半年内改了两三次。

欧盟这边，2026 年 3 月通过的 (EU) 2026/699 授权条例，修订 (EU) 2018/858 附件十，把维修与保养信息（RMI）开放范围扩到 ADAS、动力电池诊断与软件版本，并要求逐步通过 API 提供与 VIN 相关信息包——开放口径在扩，字段自然要跟着扩。澳大利亚那边，ACCC 在 2026 年 9 月披露三家车企调整了按 MVIS 开放维修信息的方案，日费率的出现，说明「开放多少、按什么价格」也在被监管一点点校准。

规则在动，功能清单却是静态的。一份「当时打勾最多」的表，恰恰可能是未来改动成本最高的那一个。

复盘三：事故的代价，往往被算少了

选型事故最容易被低估的，是它的次生代价。

第一笔是返工：第二个国家上线失败后，之前培训过的人要重新学，之前录的数据要重新对。第二笔是信任：业务部门一旦认定「系统不好用」，后面再推任何新模块都会先被质疑。第三笔最贵——机会成本。半年时间本可以用来开第二个国家的门店，却耗在了「系统改不动」上。

这里还有一笔隐性账：选型失误会拖慢整个团队对「数字化」的信心。第一次没选好，第二次再推系统时，业务部门会说「上次不也这样」。这种信任成本，往往比返工更贵，也更难弥补。

所以选型不是一次采购，它决定了未来两三年里，企业「响应变化」的速度上限。

选型比的不是功能多少，是换国家要不要重做。

复盘四：三个该问的问题

这份评估表，该补上三问。

第一问，税制口径。问：税费能不能按 VIN 摊到单台？当地税制变了，口径谁来改、多久能改？——巴西的 CKD/SKD 分档、泰国的本地化比例、欧盟的 RMI 开放，都会落到这一个口径上。

第二问，扩展方式。问：加一个字段、改一次口径，要不要动数据库表结构？是配置就能上线，还是要排开发档期？——扩展字段解决的就是这件事：加字段不改表，配置即用。

第三问，多国复制成本。问：换一个国家接入，要多少人、多少时间？是加一个区域包，还是重做一遍？——这一问最容易被跳过，却最决定总成本。

三问里，第二、第三问的答案，往往比「有没有这个功能」更能预测一年后的处境。

复盘五：如果重来一次，招标表该怎么改

如果这家公司重来一次，招标表该怎么写？把三问落到表上，大概是这个样子。

原来的表，是一栏一栏的「有 / 无」：有没有销售管理、有没有库存、有没有售后。新的表，应该换成一组「怎么变」的问题：当地税制调整时，分摊口径多快能跟上？加一个字段，是配置还是开发？换一个国家，是加包还是重做？每一个问题后面，跟一个可验证的答案——最好让供应商当场演示一遍，而不是口头承诺。

关键的区别在于：功能表问的是「今天能不能用」，新表问的是「明天变了还稳不稳」。选型选的是未来两三年的适应力，不是今天的打勾数。

复盘六：三个问题，也是三份「验收标准」

把三问往前推一步，它其实就是三份可以写进合同的验收标准。

税制口径那一问，验收标准是：给一个当地税制调整的场景，系统里调整口径需要多久、由谁完成，能不能在规定时间内出结果。扩展方式那一问，验收标准是：现场加一个字段，从提出到可用，是半小时还是三个月。多国复制那一问，验收标准是：接入一个新国家，列出需要的人力、时间与清单，看它是「加一个包」还是「重做一遍」。

把问题变成可验收的标准，好处是：承诺能被检验。口头说「我们支持多国」，和「接入新国家只需新增一个区域包、不改主干代码」，是两件分量完全不同的事。

复盘结论：算数·海辕 是怎么回答这三问的

把三问放进算数·海辕，答案是这样。

税制口径：按 VIN 做税费分摊，单车成本卡落到每一台车；口径随当地税制调整，不靠临时改代码。

扩展方式：数据字典管共有口径，扩展字段管差异，加字段不改表结构，配置完即可用。

多国复制：换国家只加一个区域包——巴西是 pack_br，墨西哥是 pack_mx，菲律宾是 pack_ph；许可证、报关单证、语言、币种、税制、仓库口径都在包里。业务代码不认识国家，只认识包。汽车出口 · 外贸流程 · 当地税务 · 海外 4S 店管理，四块各自成模块，接起来是一条链；换国家换的是链上那一环的口径，不是整条链。

复盘七：一句话记住这次事故

这次事故，可以用一句话记住：不是选了一个功能少的系统，是选了一个「改不动的」系统。

功能少，可以慢慢加；改不动，就是天花板。出海业务最不缺的就是变化——税制在变、单证在变、合规要求也在变。系统能不能跟上这些变化，比它今天能打多少勾重要得多。所以下次选型，别急着看功能表，先问那三个问题。

复盘之外：谁先别做正式选型比对

不是所有团队都要走到这一步。

只有一国一条线、短期不打算进第二个国家的团队，先别做多国复制的比对——把当前这条线跑通更要紧。把系统当 Excel 替代、只解决单机记账的团队，先别急着比较「多国复制」这类能力，它解决不了当下最痛的那件事。

还有一类团队也先别急着选：需求都还没跑通过一遍的。连自己一天到底要下几张单、走几道签，都还没数清楚，先去把这条线手工跑顺——需求没成型，再好的系统也接不住。

还有一个常被忽略的评估角度：看这家供应商自己「怎么改自己」。问一句「你们最近一次因为客户政策变化而调整产品，用了多久、改了什么」，答案比任何功能演示都真实——一个改得动的团队，才做得出改得动的系统。

说到底，选型事故的成本，从来不写在采购合同上，而写在接下来两三年的每一次「改不动」里。功能可以补，架构难改；今天就多问三个问题，比明年再返工划算得多。

选型比的不是功能多少，是换国家要不要重做。先问对这三个问题，再谈选谁。

相关页面：产品矩阵、区域与海外交付、案例与演示、资源与洞察；如需按自己的链路逐项核对，可 联系我们。

说明：本文为〈算数·海辕〉实务观察，用于说明出海业务链路与系统能力，不含真实客户数据与虚构经营数字；所列税率、门槛与认证要求以目的国当期法规为准，数据来源见文末。