客户质量数据建模会议纪要：从文件保管到智能查询闭环
会议主题：客户“质量”相关数据建模与恒田大脑应用路径
参与方：FDE、品质负责人/王主管、过彦名等
纪要整理：CIO小田
整理时间：2026-06-17
资料口径：基于会议摘要整理；涉及客户文件、质量手册、内部系统数据等敏感内容，本页只发布管理摘要，不展开客户原文、价格、合同或未授权明细。
一、核心结论
本次会议确认：客户质量要求已经具备进入“企业大脑”建模的业务基础，但需要先把质量数据的来源、层级、责任人和使用场景厘清。
当前客户品质基准、质量手册等文件由品质负责人统一接收和保管，部分基础质量要求已录入环思系统“客户基准”版面，供内部查询。实际执行中，一线人员仍存在理解不清、重复咨询、跨部门查找效率低的问题。
会议达成的方向是：以客户质量要求为核心，结合文件解析和业务系统数据读取，建设客户质量智能查询能力，让业务、品质、生产等相关人员能按“客户—产品—质量要求—适用场景”快速获得可执行答案。
二、为什么要做：当前管理痛点
| 事项 | 当前情况 | 业务影响 |
|---|---|---|
| 客户质量文件保管 | 客户品质基准、质量手册等由专人集中保管 | 资料可信度较高，但依赖人工解释和传递 |
| 系统录入 | 基础要求已录入环思系统“客户基准” | 可查，但对一线理解、关联和问答支持不足 |
| 员工咨询 | 员工经常因文件理解不清反复咨询 | 增加品质负责人沟通成本，影响响应效率 |
| 客户差异 | 不同客户对质量关注点不同，规范程度也不同 | 若没有结构化管理，容易出现执行偏差 |
| 产品层级 | 每个客户文件下可能有多个产品条目 | 需要按客户和产品维度精准匹配质量标准 |
管理判断：这不是单纯的“资料存放”问题，而是客户质量要求能否被一线准确理解、快速调用、持续更新的问题。若不处理，后续在订单评审、生产执行、品质检验和客户沟通中都可能出现重复确认或标准适用不一致。
三、目标能力
本项目建议先围绕三个能力落地：
-
查得到
按客户、产品、质量条款、流程节点等维度快速查到对应质量要求。 -
看得懂
把客户质量文件中的专业表述转成内部可执行口径，减少员工反复询问。 -
用得准
当某个产品缺少专属质量标准时，系统能提示可参考的同客户相似产品标准，并标注“需业务/品质确认”，避免自动替代造成风险。
四、实现路径
阶段 1：确认核心业务维度
先由品质负责人和业务侧共同确定 20 个以内核心建模维度，避免一开始建得过大、过散。建议首批维度包括：
- 客户名称/客户类型
- 产品类别/产品条目
- 质量基准文件名称
- 质量手册/技术文件类型
- 关键质量要求
- 检验标准
- 尺寸/外观/色差/包装等关注项
- 适用流程节点
- 适用订单或产品范围
- 是否已有环思系统记录
- 是否为客户专属要求
- 是否可参考相似产品标准
- 责任部门
- 资料负责人
- 生效时间/更新时间
- 来源文件
- 确认状态
- 风险等级
- 待补充事项
- 后续复核人
首批维度控制在 20 个以内，是为了让系统先服务真实业务查询，而不是做一套难维护的大而全目录。
阶段 2：打通数据输入路径
数据来源分两类处理：
| 数据来源 | 输入方式 | 责任重点 |
|---|---|---|
| 客户质量文件、质量手册、品质基准 | 通过云盘上传，由后台解析 | 确保文件版本、客户归属、产品归属准确 |
| 环思系统/ERP 中的客户基准数据 | 由 IT 协调系统读取或导出 | 确保字段口径清楚，避免重复和错配 |
会议中已提到可通过云盘拖拽上传文件，IT 侧由钱工协助技术对接。后续关键不是单纯上传文件，而是上传后必须能识别：这是哪个客户、哪个产品、哪类质量要求、由谁确认、是否已生效。
阶段 3：形成客户—产品—质量要求知识网络
企业大脑后台需要把文件和系统数据组织成可查询的业务关系：
客户 → 产品 → 质量要求 → 检验/执行场景 → 来源文件 → 责任人/确认状态
同时保留替代参考逻辑：
某客户某产品缺少标准 → 查找同客户相似产品标准 → 标注“参考适用” → 由品质负责人确认
这一步的核心价值是：系统不只是存文件，而是把文件转成可追溯、可问答、可复核的质量知识。
阶段 4：试点验证
建议先选择少量客户和产品做试点，不直接全量铺开。
试点验证问题：
- 一线能否用自然语言问到正确答案？
- 回答是否能指出来源文件和适用产品？
- 缺标准时，是否能提示参考标准和确认责任人？
- 品质负责人是否认可系统理解口径？
- 是否减少重复咨询和人工解释？
五、产生价值
1. 对订单交付
客户质量要求能更早进入订单评审和生产准备环节，减少因标准理解不一致导致的返工、等待确认和交期风险。
2. 对品质管理
质量文件从“专人保管、人工解释”升级为“可查询、可追溯、可复核”的知识资产，有利于统一执行口径。
3. 对一线效率
员工可以直接查询客户质量要求、适用产品和执行注意点，减少重复询问品质负责人的次数。
4. 对管理复盘
后续可以统计哪些客户、哪些产品、哪些质量条款被频繁查询或经常缺失，从而反向推动资料补齐和流程优化。
5. 对企业大脑建设
本场景是恒田大脑从“资料检索”走向“业务判断辅助”的关键试点。质量数据一旦建模成功，可复制到订单、工艺、仓储、采购等更多业务场景。
六、风险与控制措施
| 风险 | 风险等级 | 控制措施 |
|---|---|---|
| 客户质量文件保密性高 | 高 | 只授权必要人员访问；不公开客户原文；上传、解析、查询过程需受控 |
| 文件版本混乱 | 高 | 每份文件必须记录客户、产品、版本、生效时间和负责人 |
| AI 理解偏差 | 高 | 关键质量要求必须由品质负责人复核，不允许系统自动替代最终质量判断 |
| 数据口径不统一 | 中 | 先确认 20 个以内核心维度，再扩展 |
| 系统对接延迟 | 中 | 先用云盘文件解析试点，同时推进环思/ERP 数据对接 |
| 相似产品标准误用 | 高 | 参考适用必须明确标注，未经确认不得作为正式执行标准 |
七、责任分工建议
| 角色 | 责任 |
|---|---|
| 过彦名 | 牵头协调后续会议，推动项目进入实施准备 |
| 品质负责人/王主管 | 提供客户质量文件管理逻辑、质量条款业务解释、确认建模维度 |
| 钱工/IT | 确认云盘上传、系统数据读取和后台对接方式 |
| FDE/企业大脑团队 | 将业务逻辑转成可查询、可追溯的质量知识模型 |
| CIO小田 | 负责会议纪要、wiki 沉淀、信息口径整理和后续资料闭环 |
八、下一步动作
-
召开三方实施会议
建议时间：会议中初步提到次日 8:30–9:00 区间。
参会建议：过彦名、品质负责人/王主管、钱工、FDE/企业大脑团队。 -
确认首批 20 个以内建模维度
由品质负责人先提供实际业务逻辑，企业大脑团队整理成建模清单。 -
选择试点客户和产品
建议先选 2–3 个客户、每个客户 1–3 个产品条目，验证查询效果。 -
确认数据输入方式
云盘文件上传先跑通；环思/ERP 数据对接由 IT 评估路径和权限。 -
建立复核机制
AI 输出的关键质量答案必须带来源和确认状态；未确认内容不得直接作为正式质量判定。
九、管理结论
本次会议已经形成清晰方向：客户质量数据建模应从“文件集中保管”升级为“客户—产品—质量要求”的智能知识网络。短期重点不是一次性做全量系统，而是选定核心维度、跑通数据输入、完成小范围试点，并用真实业务问题验证是否能减少重复咨询、提升质量要求查询效率和降低执行偏差。
建议由过彦名继续牵头，尽快组织品质负责人、钱工和企业大脑团队进入实施方案确认。