远程为主，按需驻场，伙伴协同

导出时会自动带上公司、品牌与网站的页眉页脚；需要页码请在打印对话框的「更多设置」里保留浏览器的页眉和页脚。

交付方式不是商务条款的附属品，它直接决定项目周期的可预测性。同一套系统，用不同的方式交付，客户的投入与风险可以差很多。所以我们在开始前先把三个问题讲清楚。

这三个问题回答完，交付方式基本就定了。反过来，如果跳过它们直接谈排期，谈出来的日期一定是纸面上的 —— 因为周期的主要变量（口径与数据）还没有被量化。

我们提供三种交付形态，下面三条是 海辕·车 · 整车出口经销 在产品数据里对它们的原始定义。

三条定义里，「远程交付为主」是默认形态，另外两种是它的补充：驻场解决「现场流程必须当面梳理」的场景，伙伴协同解决「语言与当地税务必须由本地人参与」的场景。三者的关系是叠加而不是互斥 —— 一个客户完全可以在主体上远程、在关键节点驻场、在某个国家由伙伴协同。

需要强调的是，形态的选择与产品线的多少无关。无论客户先用一条产品线还是同时开五端，交付形态都由「现场复杂度」决定，而不是由功能数量决定。

远程交付把系统部署、数据初始化、单据模板配置与培训都放在线上完成，不占用客户现场资源。它适用于绝大多数场景，尤其是有明确的业务口径负责人、能把基础数据整理出来的客户。

远程不等于「自助」。远程交付里我方仍然承担配置与校验，客户承担事实与口径。分工大致如下。

1. 1口径对齐（远程会议）逐条确认主流程的八个环节在客户业务里的叫法与负责人，确认成本口径（哪些项进成本卡）、币种口径（记账币种与折算时点）与单据清单。这一步的输出是一份可以逐条核对的清单，而不是一份会议纪要。
2. 2基础数据准备（客户侧）整理车型与配置代码、VIN 规则、门店与仓的组织结构、渠道商与客户档案。这些是主数据的输入，无法由我方代做 —— 我们做的是给出模板与校验规则，把「哪些字段必须齐」变成清单。
3. 3配置与区域包选择卡点按客户的目标市场选择或新增区域包，配置税费科目、单据模板与认证提醒。多个市场并行时，逐个包校验，不把一个市场的口径复制给另一个市场。
4. 4并行对照新系统与原口径并行跑一段，用同一批业务在两处核对：报价单、成本卡、单据齐套校验结果。对照期不是形式，它是发现口径偏差的唯一有效方式。
5. 5培训与交接按角色做远程培训：门店、渠道、单证、财务、管理层各自需要会什么。培训材料与操作路径随系统一起交付，不依赖某个人的记忆。

远程交付的边界要说清楚：它不适合「业务口径本身还没定」的场景。如果客户内部对「哪些费用进成本卡、返利怎么算」还没有共识，远程会议只会把分歧搬到线上。这种情况下更划算的做法是先做一次口径梳理，把共识建立起来，再进入配置。口径梳理的清单基础见 单车成本卡字段清单。

驻场不是「更高级的服务」，它是一件有明确适用条件的工具。驻场能解决的只有一类问题：现场的物理流程与单据流转，必须站在现场才能看清。

驻场与远程的切换可以发生在项目中途，不需要重新开始。实际做法通常是：远程完成口径对齐与配置，把现场问题收集成清单，再按清单安排驻场 —— 这样每一次驻场都带着明确的任务，而不是去现场「看看情况」。

海外伙伴协同是我方与当地服务伙伴联合交付，覆盖语言、税务与现场支持。它的价值在于「本地人参与」这一点上 —— 有些事远程和驻场都做不了。

• 伙伴协同不改变责任主体。系统能力与交付质量仍由我方负责，伙伴协同解决的是语言与在地性，不是把责任转出去。
• 与伙伴联合交付时，同一套口径仍然只有一份。伙伴按区域包与主流程行事，不各自维护一份「本地版本」，否则差异又会从组织层面重新长出来。
• 伙伴协同按需启用。没有语言与在地需求的市场，强行引入伙伴只会增加沟通环节。

三种形态没有优劣，只有适用条件与风险分布不同。下表把最需要对比的几项放在一起。

读这张表的方式是：先看「适合什么」这一列哪一行像自己，再看「主要风险留在哪」这一列 —— 项目开始前就要为这个风险准备动作。例如选了远程交付，就要先确认口径负责人是否明确；选了伙伴协同，就要先把口径一致性写进协同方式里。

三种形态可以在同一个项目里并用，也可以随项目阶段切换。海外业务服务标品 解释了为什么这些切换不会影响已跑通的市场。

上线节奏与交付形态是两件事，但必须一起定：形态决定谁在什么时候做什么，节奏决定先做什么。我们的建议始终是从一条主线开始，而不是一次全上。下面四条来自 海辕·车 · 整车出口经销 的落地路径定义。

1. 11 · 选一条主线先跑通通常从整车出口经销或二手车出口切入，先把一条链路跑顺。
2. 22 · 接入共用底座VIN 一车一档、单车成本卡与多币种随业务线一并生效。
3. 33 · 开五端内部工作台、渠道商门户、手机端、集团大屏、品牌官网按需开通。
4. 44 · 按需加载产品线运力、海外仓、单证、汽配等按业务节奏逐步加载，不一次性推翻。

把这四步与交付形态放在一起看，关系很清楚：第一步与第二步靠远程就能完成，因为它们主要是口径确认与底座接入；第三步「开五端」与第四步「按需加载产品线」更容易在关键节点用到驻场或伙伴协同，因为五端涉及角色与现场，产品线加载涉及具体业务动线。

这样安排的直接好处是：客户可以在一条主线上先看到结果，再决定要不要继续投入。系统能力是叠加的，第一条主线跑通之后，加载后续产品线不需要重来一遍 —— 底座（海辕·核 的车辆主数据与成本引擎）已经在位。

• 「远程交付 = 客户自己搞」不成立。远程交付里我方仍然负责配置与校验，客户负责事实与口径。两边都不做，系统就跑不起来。
• 「驻场才叫重视」不成立。驻场是有适用条件的工具。没有具体现场问题时的驻场，只增加双方成本，不降低任何风险。
• 「一次全上更快」不成立。一次性推翻现有流程会把口径分歧、数据质量、人员培训三件事同时压到一个时间点，风险是三倍而不是相等。
• 「交付完就结束」不成立。新市场开包、认证到期、法规调整都需要持续动作；交付方式里包含的培训与材料，正是为了让这些持续动作不依赖原厂在场。
• 「交期可以先用日期承诺」不成立。周期的主要变量是口径与数据，这两项在调研前无法量化，所以我们在调研阶段先给顺序和范围，不先给日期。

这几条与 客观评价这件事 是同一个原则：把可核验的部分讲清楚，把不确定的部分明说，不用好听的话替代事实。

交付形态定下来之后，客户侧真正需要准备的东西只有四样。它们无法由我方代做，也不是靠驻场能解决的 —— 驻场能补齐现场信息，补不了决策与数据。

这四样与交付形态的关系很直接：它们到位时，远程交付就能覆盖绝大多数工作；缺哪一样，对应那一环就会要求把形态升级到驻场或伙伴协同。换句话说，驻场是把准备不足的代价换成现场成本。能提前准备的，最好不要用驻场去补。

要确定交付形态，我们需要知道三件事：您的角色（四类主体里的哪一类）、主要市场（对应哪些区域包）、当前最痛的一环（出口链路里的哪一段）。这三件事说清楚，形态与顺序基本就定了。角色与切入点的对照见 典型出海角色与切入点。

如果您想先看看系统本身再谈交付，可打开的演示租户 里有不用留资就能进的入口；想先核对口径，单车成本卡字段清单 与 单证齐套检查点 可以当成自查表。