已阶段性完成
一体化车辆配置器（OTD）
这是什么
把销售选配和工程能造的单车 BOM 做成同一套规则，支撑高定订单往下走。
当时卡在哪
销售能选出来一辆车，工程解不成可造的单车 BOM。两边各有一套配置说法，订单往下走就会卡在「能选不能造」——交期无法承诺，库存和产销也对不上。
做了什么
- 建设多端销售配置体验与订单入口，按场景定义选配流程、约束与交易相关链路，支撑高定下单。
- 搭建选配内容与配置主数据能力：动态配置/菜单/素材，销售↔工程映射与规则，保证配置可运营、可解算。
- 与研发 PMS 定制化 BOM、排产等环节协同，打通「配置串 → 订单 BOM → 排产/制造」验证路径，服务 OTD C→M。
流程与架构示意
图示与文案整合简历职责与路特斯 OTD/高定业务验证材料中的可公开业务结构；已去掉联调账号级细节、未完成项与敏感系统清单堆砌，不展示内部界面截图。
OTD 验证三大流
来自路特斯 OTD/高定验证材料：一件大事是 C→M；验证按订单流、资金流、实物流推进。配置器重点落在订单流与 BOM 准确性。
按路特斯 OTD/高定验证材料中的能力域整理：营销侧配置与订单 ↔ 车辆研发侧 BOM ↔ 排产/制造；已省略内部系统堆叠与联调细节。
结果
一个配置能走到订单 BOM 和排产验证；能卖的和能造的是同一辆车。
- 形成可支撑高定 / OTD 的销售配置与配置数据产品能力，服务自由选配与交付节奏。
- 在订单流验证中，对齐销售配置/订单与 BOM 生成、排产之间的关键口径与接口。
- 拉通销售—研发—制造对「同一辆车」的配置与物料表达，降低可售不可造风险。
和研发怎么对齐
和研发对齐时按销售 / 研发 / 生产三域说话：配置器落在销售配置真相与工程配置数据的交界，BOM 解算是应用层规则，制造执行在集成边界之外。
当时的判断： 能选不能造，是两边说的不是一回事
附录
带领 5 位产品推进一体化配置器与相关配置数据能力；在 OTD / 高定验证语境下，覆盖多端销售配置体验、选配内容与主数据，以及定制化 / 单车 BOM 生成所依赖的配置与规则定义，统筹内外部资源推动全球配置器按期上线。
我负责的边界
- 多端销售配置体验：官网 / APP / 小程序等触点的选配流程、约束反馈与下单链路（国内与海外销售配置能力同属 OTD 销售域）。
- 选配内容与配置主数据：动态配置、菜单与素材；销售配置与工程配置映射、物料与规则，服务「可售→可造」。
- 定制化 / 单车 BOM 相关能力协同：配置族与特性、装置结构与滤镜、订单 BOM 生成所需的配置与规则定义（与研发 PMS / 排产侧协同验证）。
- 支撑 OTD「一件大事」：C→M 订单到交付全链路中，销售配置与配置数据真相的产品化建设。
明确不负责
- 工厂侧排产规则细节、MES 过点执行、TMS/WMS 实物流执行等制造执行系统内部能力（属 OTD 协同验证范围，非配置器产品主体）。
- 支付渠道对接与资金日清等资金域专项（OTD 三大流验证中的资金流，独立验证）。
协作方式
- 产品：带领 5 位产品共同推进配置器与配置数据能力。
- 业务与研发：与业务共创整车配置 / BOM 解算逻辑；与 PMS 定制化 BOM、排产（JIS）等环节做订单 BOM 生成与贯通验证。
- OTD 专项：在订单流 / 资金流 / 实物流三大流验证中，对齐销售配置、订单与 BOM 相关接口与口径。
需求分析过程
对照能核对的行业做法展开；标出发现项，没确认的内部细节不编。
1. 业务目标与「一件大事」拆解
OTD 目标是 C→M（订单到交付）全链路。路特斯高定语境下，策略围绕客户满意与降低成本，拆成自由选配、缩短交期、降低库存、平衡产销四题；产品需求必须同时服务「能选」与「能按时造出来」。
- 自由选配不是前端功能清单，而是批量化生产与交付可运行的前提。
- 交期与库存目标倒逼：选装预测、订单节奏、配置/BOM 准确性必须可管理。
2. 干系人地图：销售 / 研发 / 生产三大领域
OTD 是跨销售、生产、研发的端到端流程。需求分析按领域拆接口：销售域（配置器、订单中心、预测）、研发域（配置管理、EBOM/MBOM/规则）、生产域（排产、制造执行、物流）。配置器产品处于销售配置真相与研发配置数据的交界。
- C 端与门店/海外触点都是订单入口，需要统一配置口径与订单字段。
- 研发侧提供零件主数据、工程规则等；排产侧消费订单与订单 BOM。
3. 问题清单转化为需求主题
验证前的关键担心直接变成需求主题：客户能否完整选配？选配后订单如何管理与传输？高度定制下订单/预测 BOM 如何准确生成？订单如何排产？如何拆到零件采购与工厂接收？——配置器与 BOM 准确性是其中的枢纽。
- 需求主题 A：高定选配完整性与约束（含特殊配置场景）。
- 需求主题 B：订单创建后的跨系统传输与状态一致。
- 需求主题 C：基于配置串生成完整单车 / 订单 BOM，并进入排产验证。
4. 需求分层：体验 / 订单 / 配置主数据 / BOM / 对接验证
体验层：多端选配与下单；订单层：订单中心与国内/海外订单协同；主数据层：销售↔工程配置、特性库与规则；BOM 层：定制化 BOM / 订单 BOM 生成；对接层：与排产、制造 ERP 等做订单流验证。资金流、实物流并行专项，不与配置器主体混为一谈。
- 架构上常见拆分：营销平台（销售配置器/订单中心）↔ 车辆研发平台（配置与 BOM）↔ 排产/制造执行。
- 验收强调贯通：例如订单下发 → 生成订单 BOM → 排产成功，而不只是页面可用。
5. 验收口径：三大流中的订单流枢纽
OTD 验证按订单流、资金流、实物流推进。与配置器强相关的是订单流：销售配置/订单创建后，能否驱动 BOM 生成与排产；单车 BOM 专项验证「选配后能准确生成完整单车 BOM」。
- 订单流验收关注：订单字段（如配置串等）在域间一致、BOM 生成成功、进入排产。
- 单车 BOM 验证需要研发 EBOM/MBOM、基地物料/技术、平台与 IT 等多角色协同。
可核对信息
- 业务目标对齐：自由选配、缩短交期、降低库存、平衡产销（OTD 策略四大课题）。
- 覆盖多端销售配置触点（含 APP / 小程序 / 官网等），支撑国内与海外订单入口协同。
- 配置数据能力从 0 到 1：销售/工程配置、物料与规则，服务单车 / 订单 BOM 生成验证。
- OTD 验证主线：C→M 全链路中的订单流贯通（销售配置/订单 → 排产 → 制造），并协同资金流、实物流专项。
分层怎么说（不写选型）
- 访问层：管理后台或门户，按角色做权限与菜单，而不是一套界面打天下。
- 应用层：按业务域拆模块（主数据、流程、规则、单据），先定域边界再谈服务怎么拆。
- 数据层：主数据与业务单据分开，加上审计与日志，保证可追溯、可对账。
- 集成层：对接已有 ERP / MES / 生产或交易系统，而不是重写现场控制或核心账务。
独立部署时怎么估资源
销售配置、订单、配置主数据若拆成可独立部署的服务，用下面的方法估量级；核数内存由研发按压测定，不在此编造。
- 无状态应用：按管理端人数与峰值并发估实例，可水平扩；先问「同时在用的人」而不是先问机器型号。
- 数据库：按单据量、查询是否拖垮写入来决定要不要读写分离或把报表拆出去。
- 文件与日志：附件、导出、审计不宜和业务库绑死，独立存储更利于容量与合规。
- 一个可独立部署的中等管理模块，通常是「应用实例 + 库 + 必要中间件」；主路径模块和边缘模块的容量差一档。具体核数内存由研发按压测定，产品给出可用性、权限、审计和量级。