海外汽车
准入认证管理
以模型，理清复杂。
当多品牌、多市场与多角色交织，设计如何从理解业务走向创造价值？一次以 UML 建模与 DDD 思维驱动的企业级产品设计实践。
01 / BUSINESS02 / MODEL03 / EXPERIENCE集团海外汽车准入认证数字化平台
业务建模 / 信息架构 / 交互设计
如何把专业的线下流程，转化为高效的线上协作？
让汽车走向海外，先让协作走到一起。
多个品牌，一套共同的认证业务语言。
汽车进入海外市场前，需要通过当地国家或地区的法规准入认证。认证团队要依据集团市场进入计划，识别法规、收集技术参数、形成申报资料，再跟踪认证与证书。
原有工作分散在文档、邮件和电话中。不同品牌重复识别法规，信息难以复用；资料收集与进度跟踪依赖人工，也缺少可沉淀、可追溯的标准流程。
项目范围：法规管理、参数收集、申报管理、认证计划、证书与经验管理。
规划覆盖范围
年度计划支撑能力
业务规划中的预计节省投入
以上为原稿 2025—2026 业务规划目标，并非上线后实测结果。
共性流程里，存在品牌差异。
动力类型、投放市场、文件和证书格式各不相同。设计需要提炼通用能力，也要让差异得到合理表达。
同一系统，面向不同语言与租户。
国内外工程师共同使用系统。多语言需要预留扩展空间，多租户需要明确基础数据与权限边界。
从业务线上化，走向设计价值。
把线下表格搬到屏幕上只是起点。我把设计目标分成三个递进的层次，让业务完整性、操作体验与长期创新形成同一条路径。
业务线上化
利用自动化、协同操作与过程留痕，承接真实业务流程，减少重复劳动。
流程更高效
识别冗余步骤与操作瓶颈，通过清晰反馈、适当引导和约束，改善完整任务体验。
持续创造价值
沉淀可复用的业务组件，探索 Agent 与工作流服务的可能性，并以 ROI 评估投入。
智能体与工作流服务为探索方向。
同一条链路，三种工作视角。
线下文档难以支持多人协同，在线文档又难以承载专业业务规则。围绕三类核心角色，分别梳理职责、操作目标和协作边界。
认证工程师
CERTIFICATION ENGINEER维护市场法规与版本，创建车型认证项目，分配任务并组织审批、会签及发布。
UPL / 负责人
TEAM COORDINATOR接收认证工程师的任务，二次分配给责任工程师，审核填报内容并补充方案说明。
责任工程师
RESPONSIBLE ENGINEER按照分配任务提供产品认证技术资料，填报参数、上传附件，完成认证方案定义。
先建立模型，再让界面生长。
梳理业务流程
明确谁在什么阶段完成什么动作，以及跨角色的交接与审批。
选择业务实体
从业务描述中提取名词，筛选直接关联系统需求的核心对象。
建立领域模型
识别归属、引用与多对多关系，让信息结构有业务依据。
01 / 把线下协作，展开为业务泳道
以某车型在某市场收集认证资料为例，追踪任务从法规维护到证书归档的完整流转。
认证工程师
UPL / 负责人
责任工程师
项目负责人 / 三方系统
阅读方式：各列按角色展示动作；任务经 UPL 与责任工程师流转后，由认证工程师发起会签，再进入项目审批、文件递交与证书生成。
02 / 从业务名词，找到稳定对象
03 / 从实体关系，推导系统架构
模型的意义，在于让关系能够推导出产品结构。先用 ER 图说明实体之间的关联，再将稳定对象映射为导航入口，最后把业务动作组织到对应模块中。
实体之间，如何关联？
市场与法规为一对多，法规与参数为多对多；车型认证项目通过市场、法规建立业务上下文，再关联文件与认证证书。
对象，如何成为导航？
从实体抽取稳定的管理入口：法规管理、申报管理、认证文件管理和认证证书管理。导航回答“去哪里找”，避免按零散功能堆叠页面。
模块，如何承接业务动作？
在对应入口中组织关联参数、项目定义、任务分配、填报、会签、文件生成与证书上传等能力。业务架构回答“在这里完成什么”。
对象定义建立共同语言，关系模型决定信息组织，业务动作形成可执行的系统能力。
设计的价值，发生在方案改变的地方。
不同品牌带来不同流程与诉求。先把品牌差异转化为可配置的产品能力，再与产品、业务共同评审原型与信息架构，让设计参与结构和流程的决策。
“我们需要的功能，
和其他品牌不一样。”
动力类型、投放市场、交付格式各有不同，部分用户还来自海外。共同平台要覆盖共性，也要容纳必要的差异。
把差异放进规则，
把共性沉淀为体验。
产品经理将业务差异转化为数据和功能方案；设计师继续补足类型识别、信息表达与操作体验，并与开发一起验证大量数据下的性能。
汽车动力类型不同，对应法规和参数不同。
基础数据按动力类型划分，关联对应法规。
在基础数据界面提供明显的类型标识，降低识别成本。
每款车需要进入的国家或地区不同。
与业务一起维护全量地区、法规及参数，支持不同阶段的上市申报。
与开发共同验证大量数据下的性能，保障查找与操作体验。
不同品牌生成的文件和证书格式存在差异。
依据动力类型内置不同的文件模板。
生成文件时用清晰的视觉标识区分模板，帮助识别交付内容。
在三个关键决策中，继续推敲方案。
结合业务沟通内容检查产品原型与 PRD，必要时调整信息架构和交互路径；新方案与产品、业务评审通过后，再进入开发。
先理清关系，再组织信息。
一个市场包含多项法规，一项法规关联多个参数，同一个参数也能被多项法规引用。
国家、法规、参数的混合表达掩盖了两层强关联关系。拆成市场—法规与法规—参数两张表，让归属与复用分别清楚，也为后续功能与数据结构建立依据。
解决数据根因，减少补救功能。
不同租户的责任部门并不相同。与其在任务分配时反复批量修改，不如在基础数据层面明确租户边界。
批量修改是在下游补救数据不适用的问题。原稿记录：按租户初始化基础数据后，分配任务时修改责任部门的概率降低，业务未再提出批量修改诉求。
让附件与配置，在同一位置对应。
每款车的不同配置都要填报参数，部分参数还需附件佐证。把上传入口放回对应单元格，减少弹窗与二次识别。
把入口放回各配置的对应位置，消除弹窗里的二次匹配，减少操作步骤；同时保留配置间的横向比较，方便快速定位需要填报或上传的内容。
把模型，转化为可操作的体验。
一张工作界面，承接完整任务。
- 参数与附件一体填报
依据基础数据配置，在同一参数位置支持文本与附件。 - 人员选择更明确
补充部门等识别信息，降低重名人员的选择歧义。 - 任务过程可追溯
记录处理人、时间与驳回理由，便于跟进和留档。 - 审批保留修正能力
UPL 审批时可再次修改内容，匹配真实工作职责。
查询条件，适应每个人的工作习惯。
把高频查询沉淀为可复用组件。从条件显隐到默认值，再到查询组，让复杂列表逐步拥有个性化的工作视图。
把常用条件放在前面
支持按个人习惯调整条件顺序、控制显示与隐藏。减少不必要的展开，给列表内容留出更多空间。
打开列表，就进入工作状态
为时间、人员等条件设置默认值，每次进入列表即可按默认条件查询，减少重复输入。
在不同工作视图间快速切换
保存多组常用查询条件，在一级页面切换查询组，适应同一用户在不同任务场景中的检索需求。
从规则到界面，形成统一的工作体验。
保留业务差异，统一操作语言。
基础数据区分动力类型，内置市场、法规与参数；不同文件模板使用清晰标识。将模型落到法规、参数、项目、任务与证书的真实界面中，兼顾多品牌的共性与差异。
界面素材来自原 Figma 设计稿，展示设计方案，不代表全部功能已上线。
让设计价值，回到真实使用中验证。
系统运行一个月后，邀请来自 3 个品牌的 10 位用户参与问卷，检验产品是否容易使用、是否帮助用户完成工作，并记录可复用组件的沉淀。
易用度
产品是否容易上手与使用
帮助度
引导是否清晰，能否帮助完成任务
可复用业务组件
封装具有复用价值的设计模式
数据来自原稿的上线问卷与组件记录。原稿未注明评分满分；调研样本为 10 人，结果用于阶段性体验验证。
线上化的终点，不是另一张 Excel。
理解线下工作的本质，
再发挥线上系统真正的优势。
规则交给系统
自动完成重复、规则化的任务，让人员把精力留给判断与协作。
协作留下痕迹
让多人操作、实时更新、审批记录在同一业务上下文中发生。
数据成为资产
沉淀结构化数据，为后续分析、复用和业务决策提供支撑。
结果 / 回到业务目标
围绕多租户、多语言完成方案设计，并持续改善产品流程和体验；问卷为阶段性使用效果提供反馈。
成长 / 用模型思考
将面向对象的方法运用到信息架构与业务架构中；在跨品牌沟通中识别共性，也为必要差异留下空间。
偏差 / 把价值分阶段交付
受开发排期与资源限制，部分设计功能需要后续排期。后续应更早对齐交付优先级与验收范围，让设计投入与可交付价值保持一致。