售后问题闭环系统 · 建设规格书
面向研发工程师的落地文档 —— 表单清单、状态机、角色权限、自动化规则、技术建议与分期验收
这份文档要解决的问题
售后问题目前用多维表管理，但多维表没有状态机、没有签批、没有派生字段——而这三样恰恰是整套闭环规则的载体。所以本系统的第一目标不是"把表搬上网"，而是把规则固化成系统行为：状态只能被推着走，关闭必须凭落地物，超时必然有人被通知。
01三条铁律
下面三条是整个系统的地基。研发如果在这三条上做妥协，后面所有功能都会失效。请把它们写成接口层的硬校验，不给绕过入口。
铁律一：主单状态由落地物派生，不允许手工修改
售后问题单（主表）的"状态"字段是一个计算字段，由它下面挂的落地物状态算出来。任何人（包括管理员）都不能直接改它。
反例后果：如果状态能手改，就会出现"4D 已回标、ECN 没启动、主单状态被改成已完成"——这正是我们要杜绝的假闭环。
反例后果：如果状态能手改，就会出现"4D 已回标、ECN 没启动、主单状态被改成已完成"——这正是我们要杜绝的假闭环。
铁律二：关闭只认落地物编号
主单关闭时必须回填一个落地物编号，且该落地物自身状态必须是"已签批/已完成"。系统不认口头、认不符状态、认没有编号的关闭。
各出口的落地物：质量＝4D 报告；技术变更类＝ECN；技术优化类＝TIP；客户需求＝PCR 确认＋下单；服务过程＝售后工单＋客户确认。EQCT 预研和应急措施单永远不能关闭主单。
各出口的落地物：质量＝4D 报告；技术变更类＝ECN；技术优化类＝TIP；客户需求＝PCR 确认＋下单；服务过程＝售后工单＋客户确认。EQCT 预研和应急措施单永远不能关闭主单。
铁律三：只能有一个 HUB
全系统只有一个 HUB：我的待办中心。所有提醒、预警、升级都汇聚到这里，不允许出现第二个"看板首页"或"消息中心"。多中心等于没有中心——每个中心都会有人不看。
HUB 不是页面，是规则引擎 + 一张任务表。任何角色打开系统，第一屏就是这个。
HUB 不是页面，是规则引擎 + 一张任务表。任何角色打开系统，第一屏就是这个。
02角色与权限矩阵
2.1 关键岗位（8 个）
| 岗位 | 核心职责 | 在本系统里的动作 |
|---|---|---|
| 售后文员 | 建单、定级、登记 | 受理建单并当场判紧急度；按日批量转单据派单；降级时只执行登记不参与判断；维护客户与设备档案 |
| 售后经理 | 归口、派工、降级签字、闭环确认 | P0 快速归口；召开紧急会议；提交应急措施单；派工；降级唯一签字人；主单关闭第一签 |
| 售后工程师 | 现场处理与验证 | 接工单、现场执行、按判据验证、回填工时与备件成本、触发新问题单 |
| 技术（研发） | 技术出口的落地物 | EQCT 预研（不能关闭）、ECN、TIP；必须先锁定影响面清点再评审；担任 ECN 整改负责人——汇总锁定影响面四数、组织售后第二签 |
| 质量 | 质量出口的落地物 + 裁定 | 4D 报告（根因/纠正/预防/横展）+ 关闭签批；质量与技术争议的终裁 |
| 销售 | 客户需求出口 | PCR 提报与客户确认；催客户回签；客户投诉与商务处理 |
| 整改跟单员（计划部·兼职） | 物料到料 + 排产插单 | ECN 请购与到料跟踪、在制排产插单；每日更新到料状态 |
| 台账管理员（质量部） | 只亮灯，不催办 | 看全局逾期与停滞；导出月度数据。禁止给他派单权，否则会变成第二个踢皮球的 |
"只亮灯、不催办"是刻意设计：一旦让台账管理员去催业务，他就会变成责任不清的第二人。
2.2 权限矩阵
✓ 可操作 ○ 只读 — 无权限
| 动作 | 文员 | 经理 | 工程师 | 技术 | 质量 | 销售 | 跟单员 | 台账 |
|---|---|---|---|---|---|---|---|---|
| 建单 / 登记 | ✓ | ✓ | ○ | — | — | ○ | — | — |
| 升档（改紧急度往高） | ✓ | ✓ | ✓ | 申请 | 申请 | 申请 | — | — |
| 降档（改紧急度往低） | — | ✓ 唯一签字人 | — | — | — | — | — | — |
| 出口归口 | — | ✓ | — | — | — | — | — | — |
| 提交应急措施单（P0） | — | ✓ | — | — | — | — | — | — |
| 派工 | 登记 | ✓ | — | — | — | — | — | — |
| 执行售后工单 | — | ○ | ✓ | — | — | — | — | — |
| 提交 / 签批 4D | — | ○ | — | — | ✓ | — | — | — |
| 提交 EQCT 预研 | — | ○ | — | ✓ | ○ | — | — | — |
| 提交 / 批准 ECN | — | ○ | — | ✓ | ○会签 | — | ○ | — |
| 提交 / 处置 TIP | — | ○ | — | ✓ | ○ | — | — | — |
| 提报 / 确认 PCR | — | ○ | — | 评估 | — | ✓ | — | — |
| 关闭主单 | — | ✓ 第一签 | — | — | — | — | — | — |
| 催办 / 改挂起 | 登记 | ✓ | — | — | — | ○ | — | — |
| 查看全部单 | ✓ | ✓ | 本人 | 技术口 | 质量口 | 本人 | 涉料单 | ✓ |
升档宽松、降档严格 —— 这是刻意的不对称
升档任何人可提、文员即可定（求速度，误判成本远低于漏判成本）；降档只有售后经理能签（求稳）。
同时用一条机制兜底：关闭时限按出口分两档——一般出口 T0 + 15 净工作日、技术变更出口 T0 + 30 净工作日（净＝挂起段顺延）——不随紧急度变化。报高等级换得来更快的响应，换不来更长的工期——等级注水的动机从根上被消除。
同时用一条机制兜底：关闭时限按出口分两档——一般出口 T0 + 15 净工作日、技术变更出口 T0 + 30 净工作日（净＝挂起段顺延）——不随紧急度变化。报高等级换得来更快的响应，换不来更长的工期——等级注水的动机从根上被消除。
03表单清单
共 11 个表单（13 张物理表，S11 含 3 张主数据），分五类：主表 1 落地物 5 过程文件 3 HUB 1 基础数据 3。落地物与过程文件的分界就是铁律二。
| 编号 | 表名 | 类别 | 作用 / 与主单关系 |
|---|---|---|---|
| S1 | 售后问题单（主表） | 主表 | 一台设备一个问题 = 一行。全部规则的载体 |
| S2 | 应急措施单 | 过程 | 只能促成降级，永远不能关闭主单。P0 专属 |
| S3 | 4D 报告 | 落地物 | 质量出口的关闭凭据。含根因/纠正/预防/横展四段 |
| S4 | EQCT 预研单 | 过程 | 技术变更类的前置研究。不是落地物，不能关闭 |
| S5 | ECN 变更单 | 落地物 | 技术变更类的关闭凭据。带影响面/物料/在役整改跟踪 |
| S6 | TIP 改进单 | 落地物 | 技术优化类的关闭凭据 |
| S7 | PCR 客户需求单 | 落地物 | 客户需求出口的关闭凭据 |
| S8 | 售后工单 | 落地物 | 服务过程出口的关闭凭据；也是现场动作载体 |
| S9 | 配件申请单 | 过程 | 服务过程中的备件流程；用途标记支撑整改专用料防挪用（A10）。规格见 3.3 |
| S10 | 任务中心（HUB） | HUB | 由规则引擎自动生成，不允许手工建 |
| S11 | 基础数据（3 张） | 主数据 | 设备档案 / 客户档案 / 组织与字典 |
3.1 S1 售后问题单（主表 · 34 字段）
来源标注：人工 = 手填 自动 = 系统写入 派生 = 计算得出，不可编辑
| # | 字段 | 类型 | 必填 | 来源 | 填写岗位 | 规则 / 说明 |
|---|---|---|---|---|---|---|
| 1 | 问题单号 | 文本 | 是 | 自动 | — | SF-YYYYMM-####，提交时生成 |
| 2 | 报修来源 | 单选 | 是 | 人工 | 文员/工程师 | 客户来电 / 微信 / 现场 / 内部 |
| 3 | 发现时刻 T0 | 日期时间 | 是 | 自动 | — | 提交时自动写入，全系统唯一时间基准，不许手填 |
| 4 | 客户名称 | 关联 | 是 | 人工 | 文员 | 关联 S11 客户档案 |
| 5 | 设备编号 | 关联 | 是 | 人工/带出 | 文员 | 关联 S11 设备档案；带出厂日期、机型、配置 |
| 6 | 故障描述 | 多行文本 | 是 | 人工 | 文员/工程师 | 必填，≥20 字 |
| 7 | 影响程度 | 单选 | 是 | 人工 | 文员 | 停机 / 停线 / 降效 / 不影响 —— 定级依据 |
| 8 | 紧急度 P | 单选 | 是 | 人工 | 文员 | P0/P1/P2；判不准按高不就按低，先报经理 |
| 9 | 紧急度变更历史 | 关联记录 | 是 | 自动 | — | 每次变更写一行：原值、新值、操作人、时刻、理由 |
| 10 | 降级签字人 | 人员 | 条件 | 自动 | — | 降档时记录经理姓名与时刻 |
| 11 | 出口归属 | 单选 | 是 | 人工 | 经理 | 质量 / 技术-变更 / 技术-优化 / 客户需求 / 服务过程 / 客户问题 |
| 12 | 归口时刻 | 日期时间 | 是 | 自动 | — | P0 需 30 分钟内完成 |
| 13 | 责任人 Owner | 人员 | 是 | 人工 | 经理 | 跟到底的那一个姓名。无姓名 = 单子未启动 |
| 14 | 落地物类型 | 单选 | 是 | 派生 | — | 由出口归属自动决定（S3/S5/S6/S7/S8） |
| 15 | 当前落地物编号 | 关联 | — | 自动 | — | 指向五张落地物表（S3/S5/S6/S7/S8）之一，允许多个（返工场景）；S2/S4/S9 非落地物，不得入此栏 |
| 16 | 主单状态 | 单选 | 是 | 派生 | 禁止手填 | 铁律一：由落地物状态算出，接口层锁死 |
| 17 | 当前卡在哪一步 | 文本 | 是 | 派生 | — | 看板必备列。例"等 ECN 批准" |
| 18 | 计时状态 | 单选 | 是 | 自动/人工 | 文员 | 计时中 / 已挂起 |
| 19 | 挂起原因 | 单选 | 条件 | 人工 | 经理 | 客户待回签 / 待报价 / 待供应商 / 观察期 |
| 20 | 挂起累计天数 | 数字 | — | 自动 | — | 超上限自动升级（见规则 A7） |
| 21 | 应关闭日 | 日期 | 是 | 派生 | — | T0 + 15 净工作日（技术变更出口 30），挂起段顺延，三档统一不随 P 变化 |
| 22 | 落地物应启动日 | 日期 | 是 | 派生 | — | 降级日或派单日 + 5 工作日 |
| 23 | 剩余时限 | 数字 | — | 派生 | — | 应关闭日（挂起顺延后）− 今天，负值即逾期 |
| 24 | 关闭时刻 | 日期时间 | — | 自动 | — | 关闭时写入 |
| 25 | 复发标记 | 单选 | — | 自动/人工 | 文员 | 关闭 + 90 天提醒时判定 |
| 26 | 关联工单 | 关联 | — | 自动 | — | 1 主单对多工单 |
| 27 | 同类重复计数 | 数字 | — | 派生 | — | 设备编号＋现象关键词出现 ≥2 次自动标记 |
| 28 | 累计工时 | 数字 | — | 自动 | — | 由工单汇总。证明售后价值的硬数据 |
| 29 | 累计备件成本 | 金额 | — | 自动 | — | 同上 |
| 30 | 备注 | 多行文本 | — | 人工 | — | — |
| 31 | 创建人 | 人员 | 是 | 自动 | — | 提交时写入（通常为文员） |
| 32 | 创建时刻 | 日期时间 | 是 | 自动 | — | 与 T0 同刻生成 |
| 33 | 最后操作人 | 人员 | — | 自动 | — | 最近一次有效动作执行人，配合审计日志（第 10 节） |
| 34 | 最后操作时刻 | 日期时间 | — | 自动 | — | 同上 |
共 34 个字段。研发注意：字段 16、17、21、22、23、27 均为派生字段，接口层禁止写入；31–34 由系统自动维护。
3.2 落地物表（关闭凭据，5 张）
S3 · 4D 报告（质量出口落地物）· 16 字段
报告单号｜关联问题单（硬关联，必填）｜缺陷描述｜根因分析（必填）｜纠正措施（必填）｜预防措施（必填）｜横向展开范围（必填）｜涉及机型/批次/供应商｜纠正措施责任人｜验证方式｜验证结果｜引用的 ECN 编号｜横向展开完成标志｜编制人｜编制时刻｜关闭签批人 + 签批时刻
字段 12「引用的 ECN 编号」是关键设计
若 4D 的纠正措施指向设计变更（改图纸、改程序、改 BOM），必须引用一个 ECN 编号。否则会出现"质量单关了、设计还没改"。引用后，ECN 关闭时自动回写 4D 编号，两者互为闭环。
S5 · ECN 变更单（技术变更类落地物）· 22 字段
ECN 单号｜关联问题单｜关联 EQCT 编号（条件必填）｜变更摘要｜变更原因｜影响面：切换点（按批次/序列号/日期，必填）｜影响面：应改新机台数｜应改在制台数｜应改在役台数｜旧料处置方式｜物料清单（子表：应需/到货/缺口）｜在役设备逐台子表（设备编号×状态×旧件回收）｜在制与库存批次子表｜变更前/变更后版本号｜旧版回收标志｜验证判据｜客户观察期｜论证结论｜回标售后问题单号｜审批会签｜批准时刻｜实施完成时刻
影响面四个数是全表的心脏
应改新机 / 应改在制 / 应改在役 + 旧料处置。这四个数必须在评审前锁定，且分属四方提供：技术给 BOM 差异、售后给在役台数与序列号、计划给在制数、采购仓储给旧料与到料周期。由ECN 整改负责人（技术岗，见 2.1）汇总锁定。
最常见的翻车：技术按估价请购（买 10 套的料），核完发现要改 30 台，二次请购再等一轮。影响面没锁定就不许下单，是硬规则不是建议。
最常见的翻车：技术按估价请购（买 10 套的料），核完发现要改 30 台，二次请购再等一轮。影响面没锁定就不许下单，是硬规则不是建议。
S6 · TIP 改进单（技术优化类落地物）· 10 字段
TIP 单号｜关联问题单｜优化建议描述｜不改设计的理由（必填）｜后续观察方式（必填）｜处置结论（采纳 / 不采纳 / 待定，必填）｜不采纳理由｜责任人｜执行确认｜签批
"不改设计的理由"是必填项，这是防漏洞的关键
TIP 只服务技术问题的优化类，范围天然受限；但如果不要求写"为什么不用 ECN"，优化类会被当成"改设计太麻烦"的逃逸口。写清楚理由，横向对比时一眼就能看出该不该走 ECN。
S7 · PCR 客户需求单（客户需求出口落地物）· 13 字段
PCR 单号｜关联问题单｜子型：PCR-A（免费）/ PCR-B（收费）｜客户需求描述｜技术方案｜技术方案价格评估｜销售报价｜客户确认标志与时刻｜是否涉批量下单｜下单单号｜交付标志｜商务裁定（销售负责人＋质量经理双签）｜备注
S8 · 售后工单（服务过程出口落地物 + 现场动作）· 25 字段
派工区 10：工单号｜关联问题单号（硬关联）｜设备编号（带出）｜紧急度 P（带出）｜承诺到场时间（由 P 推出：P0 4 小时 / P1 1 工作日 / P2 3 工作日，V0.2 默认值见待确认 #6）｜服务类型｜建议携带备件（按同机型＋同现象历史消耗自动提示）｜是否需停机配合｜派单人｜派工时刻
执行区 9：到场时刻｜实际现象｜处理动作｜更换备件清单（子表）｜遗留问题｜现场照片｜客户签字｜路途工时＋现场工时｜误工反馈
完成区 6：完成时刻｜服务结果（临时恢复待根治 / 已恢复 / 未解决）｜是否触发新问题单｜满意度｜备件成本｜关联出口编号
「建议携带备件」治白跑，「现场发现新问题」治漏报
前者跑三个月自然长出"故障—备件"对照表；后者保证工程师在现场发现的新问题不会因为"这趟不算"而消失。两者都是把隐性成本显性化。
3.3 过程文件表（不能关闭主单，3 张）
| 表名 | 关键字段 | 系统硬约束 |
|---|---|---|
| S2 应急措施单 仅 P0 | 单号｜关联问题单｜归口出口｜临时措施描述｜资源调度记录（调了谁、什么设备、什么备件）｜到场安排｜验证判据｜验证结论｜提出人＝售后经理｜支持降级：是/否｜转正式落地物期限 | ① 不能关闭主单 ② 仅紧急度为 P0 时可创建 ③ "转落地物期限"必填，默认降级日 +5 工作日 |
| S4 EQCT 预研单 | 单号｜关联问题单｜预研目标｜现状分析｜结论：是否转 ECN｜论证意见｜责任人｜转 ECN 期限 | ① 不能关闭主单 ② 结论页必填"是否转 ECN＋责任人＋期限"，只写"继续研究"不予放行 ③ 只能通向 ECN，不通向 TIP |
| S9 配件申请单 | 单号｜关联问题单｜关联工单｜备件清单（子表：件号/名称/数量/用途）｜用途标记（常规售后 / 整改专用）｜旧件回收标志｜申请人（工程师）｜审批（经理）｜转请购单号｜到货与发放登记 | ① 不能关闭主单 ② 用途标记为「整改专用」的行项独立核算，是 A10 防挪用报警的数据源 ③ 关联 ECN 的申请须待 A9 影响面锁定后方可转请购 |
3.4 S10 任务中心（HUB）与 S11 基础数据
| 表 | 结构 | 约束 |
|---|---|---|
| S10 任务中心 | 任务 ID｜来源单号｜来源落地物｜任务类型（12 类）｜接收人｜生成时刻｜到期时刻｜挂起顺延｜完成时刻｜状态（待办/逾期/挂起/完成/已忽略） | 只由规则引擎生成，不允许手工创建。同一人同一时刻只出现一条同类任务（去重） |
| S11-1 设备档案 | 设备编号｜客户｜机型｜出厂日期｜配置版本｜当前程序版本｜累计工单数｜累计工时｜是否在役 | 在役设备序列号清单只能出自这里——ECN 影响面清点的唯一来源 |
| S11-2 客户档案 | 客户名称｜联系人｜电话｜服务等级｜历史问题数｜历史投诉数 | — |
| S11-3 组织与字典 | 部门/岗位/人员｜出口字典｜状态字典｜影响程度字典｜挂起原因字典｜工作日历 | 工作日历必须配，"工作日"算法全系统只认这一份 |
04主单状态机
7 个状态，全部由落地物状态派生。不允许新增状态，每个状态必须有明确的进入条件。
| 状态 | 进入条件（派生规则） | 停留超时阈值 | 超时通知 |
|---|---|---|---|
| 待派单 | 主单已创建且未指定责任人 | P0 1 小时 / P1 2 小时 / P2 4 小时 | 文员 + 经理 |
| 待归口 | 已定级未选出口归属 | P0 30 分钟 / P1 4 小时 / P2 1 工作日 | 经理 |
| 待启动落地物 | 已归口且落地物未创建 | 5 工作日 | 责任人 + 经理（最易空转的一格） |
| 落地物执行中 | 落地物存在且未到签批态 | 按落地物类型，见第 5 节 | 责任人 + 跟单员 |
| 待验证 | 落地物已提交，等待验证判据成立 | 3 工作日 | 责任工程师 + 经理 |
| 待关闭 | 落地物已签批，等待主单关闭 | 2 工作日 | 经理 |
| 已关闭 | 回填落地物编号且已签批 | — | — |
"待启动落地物"是整套系统最容易空转的一格
现实中最常见的空转不是技术卡住，而是"批准了没人立项"——4D 签了但没人排 ECN，ECN 批了但没人请购。所以这一格的超时通知必须同时给责任人和经理，且在月度会上单独过一遍停留时长。
05落地物状态机与时限
| 落地物 | 状态序列 | 出口确定→签批 | 关闭主单的必要条件 |
|---|---|---|---|
| 4D 报告 | 编制中 → 根因确认 → 纠正/预防确认 → 横展确认 → 待验证 → 已签批 | 10 工作日 | 四段全部非空 + 关闭签批；若纠正措施涉设计变更，须引用 ECN 编号 |
| ECN | 草稿 → 影响面锁定 → 评审中 → 已批准 → 请购中 → 到料 → 实施中 → 已回标 → 已论证 → 已关闭 | 批准 10 工作日 论证后 3 工作日 | 七项硬校验全绿（见第 9 节）+ 旧版回收记录 + 在役整改逐台完成 |
| TIP | 草稿 → 待处置 → 已采纳/不采纳/待定 → 执行确认 → 已签批 | 3 工作日 | "不改设计理由"＋"后续观察方式"＋处置结论＋签批 |
| PCR | 草稿 → 技术方案评估 → 报价 → 客户确认 → 已下单 → 已交付 → 已闭环 | 报价 5 工作日 下单交付按商务 | 客户确认标志 + 下单单号 + 交付标志 |
| 售后工单 | 待派工 → 已派工 → 已到场 → 处理中 → 待客户签字 → 已完成 | 5 工作日 | 客户签字 + 服务结果已选 + 关联出口编号已填 |
EQCT 与应急措施单不在这张表里 —— 因为它们不是落地物
EQCT 是研究，研究完设计还没改；应急措施是临时让现场跑起来，问题还在。两者都能推动单子前进，但都不能关闭。系统层面：这两张表不提供"关闭主单"按钮，且不出现在铁律二的校验白名单里。
06HUB 设计
HUB 回答一个问题：我现在该干什么？不是"有哪些单"。所有角色共用同一个 HUB，只是看到的任务不同。
6.1 HUB 的 12 类任务
| # | 任务类型 | 接收人 | 触发条件 |
|---|---|---|---|
| 1 | 待定级 | 文员 | 新单创建且未填紧急度 |
| 2 | P0 待归口 | 经理 | P0 单创建后 30 分钟未选出口 |
| 3 | 待派工 | 经理 | 归口完成未指定责任人 |
| 4 | 待启动落地物 | 责任人 | 落地物应启动日到期仍未创建 |
| 5 | 待评审 / 待签批 | 对应岗位 | 落地物进入待审状态满 2 工作日 |
| 6 | 请购未下单 | 跟单员 | ECN 批准后 2 工作日未生成请购 |
| 7 | 物料缺口 | 跟单员 + 经理 | 到货数量 < 应需数量（每日扫，唯一每日变化的数据） |
| 8 | 外部挂起到期 | 销售 / 采购 | 挂起累计超上限 |
| 9 | 待验证 | 责任工程师 | 落地物已提交满 3 工作日未确认 |
| 10 | 待降级签字 | 经理 | P0 已验证通过且满降级时限 |
| 11 | 待关闭 | 经理 | 落地物已签批满 2 工作日未关单 |
| 12 | 复发窗口到期 | 文员 | 关闭 +90 天 |
粗体为该类型的第一接收人。挂起期间：任务本身继续计时，催办动作照常生成——只挂"等"，不挂"催"。
07自动化规则清单
这是本系统"值钱"的部分。研发请把下表逐条实现为定时任务或事件监听，不要依赖人工巡查。
| 编号 | 规则 | 频率 | 动作 |
|---|---|---|---|
| A1 | 主单状态派生 | 实时 | 落地物状态变化时重算主单状态与「当前卡在哪一步」，不接受任何手工赋值 |
| A2 | 应关闭日计算 | 实时 | = T0 + 15 净工作日（技术变更出口 30；按工厂日历，挂起段顺延），三档统一，不随 P 变化 |
| A3 | 落地物应启动日 | 实时 | P0：降级日 + 5 工作日；P1/P2：派单日 + 5 工作日 |
| A4 | 三级逾期预警 | 每 15 分钟 | ① 节点停留超时 → 标黄；② 落地物未启动 → 标橙；③ 超应关闭日 → 标红并 @责任人+经理；④ 应关闭日前 2 工作日发临近提醒（口径与第 8 节通知矩阵一致） |
| A5 | 降级超时 | 每日 09:00 | P0 满 1 天 / P1 满 3 天仍为紧急档 → 标红并推送给经理本人 |
| A6 | 挂起免逾期但不免催办 | 实时 | 挂起期间暂停逾期计时、应关闭日顺延（净工作日口径），但对应催办任务继续生成——只挂「等」，不挂「催」 |
| A7 | 挂起超限升级 | 每日 | 客户回签上限 P0 2 天/P1 5 天/P2 10 天；报价 7 天→强制销售介入；供应商无合同 ≤15 天→采购升级；客户观察期 ≤30 天，到期自动解除挂起并提醒（默认值，与待确认 #5 一致） |
| A8 | 重复问题识别 | 每日 | 设备编号＋现象关键词命中 ≥2 → 自动标记并提示可能升级处理 |
| A9 | 影响面锁定闸门 | 实时 | ECN 未锁定四个基准数（应改新机/在制/在役/旧料）时，禁止生成请购单 |
| A10 | 整改专用料防挪用 | 每日 | 在役整改专用料标记独立，被生产挪用即报警给经理 |
| A11 | 在役逐台跟踪 | 每日 | 应改在役台数 vs 已改台数，缺口逐台列出 @跟单员 |
| A12 | 重复识别防复发 | 每日 | 同类问题在 90 天内第 2 次出现 → 自动升级提醒 |
| A13 | 4D ↔ ECN 互锁 | 实时 | 4D 纠正措施涉设计变更时强制填 ECN 编号；ECN 关闭时自动回写 4D 编号；4D 引发的 ECN 以关联 4D 为前置研究凭据，不强制 EQCT（S5 关联 EQCT 为条件必填） |
| A14 | 复发提醒 | 每日 09:00 | 关闭 +90 天生成复查任务，判定是否复发 |
| A15 | 分级健康度 | 每周一 | P0/P1 占比 > 20% 即推送"分级失效"警告给总经理 |
08通知矩阵
优先级：P0 标红立即推送 / P1 标橙每日汇总 / P2 进日报不打扰
| 事件 | 优先级 | 推送对象 |
|---|---|---|
| P0 单创建 | 立即 | 售后经理 + 文员 |
| P0 已验证通过待降级 | 立即 | 售后经理（单签降级） |
| 节点停留超时 | 当日 | 责任人 |
| 落地物未启动 | 当日 | 责任人 + 经理 |
| 应关闭日临近（≤2 天） | 当日 | 责任人 + 经理 |
| 已超应关闭日 | 立即 | 责任人 + 经理 + 台账 |
| 物料缺口 | 立即 | 跟单员 + 经理 |
| 挂起超上限 | 当日 | 销售 / 采购 |
| 复发窗口到期 | 周报 | 文员 |
| 分级失效警告 | 周报 | 总经理 |
8.1 固定节拍（这部分不用系统也能做，但系统里要有对应视图）
| 会议 / 报表 | 频率 | 主持 | 内容 |
|---|---|---|---|
| 派单日清 | 每日 10 分钟 | 售后经理 | 新单分派、未派单清理、P0/P1 升级确认、进度看板过一遍 |
| 安装进度周会 | 每周 30 分钟 | 售后经理 + 计划 | 逾期节点、阻塞问题单、下周到场计划（安装进度数据出自项目台账，本系统外，会上仅同步涉售后阻塞项） |
| 停滞单周览 | 每周 5 分钟 | 总经理 | 只看停滞看板一屏，不问"进展如何"，只问"卡了几天、谁来解锁" |
| 月度复盘 | 每月 60 分钟 | 总经理 | 类别分布、重复问题 Top3、误判率、P0/P1 占比、各节点平均停留时长 |
月度复盘必须看"各节点平均停留时长"
这是判断体系是否空转的唯一依据。如果所有单的"方案已批准 → 实施中"都停 5 天以上，说明批准环节只是签字、没人排期——这时候再谈考核指标都没用。
8.2 度量指标（只留五个）
P0/P1 响应达标率 · 服务闭环周期 · 根治闭环率 · 重复问题率 · 备件一次带齐率
其中 根治闭环率＝主单中以 ECN/TIP 关闭的比例。这个数低，说明大部分问题只做了应急、没做根治。备件一次带齐率＝按「建议携带备件」到场且未因缺件返程的工单占比（数据源 S8；V0.2 替换原「安装节点按期率」——该指标在本系统无数据源）。
09关闭硬校验
研发请把这五条写成接口层的强校验，不满足直接拒绝保存，并返回明确原因。
9.1 主单关闭校验（通用）
① 至少关联一个落地物编号；② 该落地物状态＝已签批/已完成；③ 客户侧不再复现（技术出口为现场观察期通过）；④ 关闭人＝售后经理；⑤ 若曾为 P0，必须有降级签字记录。
9.2 ECN 关闭七项硬校验（最严的一组）
| # | 校验项 | 为什么必须有 |
|---|---|---|
| 1 | 图纸＋程序＋BOM 三版受控发布，旧版回收有记录 | 否则下一批又装错，直接导致复发 |
| 2 | 到货数量 ≥ 应需数量 | 最隐蔽的坑：在役整改专用料被新机生产挪用 |
| 3 | 在役整改专用料未被挪用 | 新机在厂里看得见，在役机在客户那儿看不见 |
| 4 | 在制应改台数 100% 处置完，逐台签字 | "用完为止"必须有到期批次 |
| 5 | 在役应改台数 100% 整改完，旧件回收销毁有记录 | 在役整改最容易烂尾——新机不发达就没人管 |
| 6 | 论证三项通过：实物符合性＋功能验证＋客户观察期，且有量化判据 | 否则论证就是签字仪式 |
| 7 | 横向展开完成 + 回写售后问题单 | ECN 关闭 ≠ 售后问题关闭，还差售后第二签 |
最后一条必须单独强调
ECN 关闭 ≠ 售后问题单关闭。ECN 关完只完成"第一签"，售后问题单还要等客户侧不再复现，由ECN 整改负责人（技术岗）组织售后第二签。不写这条，就还是那句老话："ECN 验证通过了，客户那边还在闹"。
10技术架构建议
| 能力 | 要求 | 可选实现 |
|---|---|---|
| 表单引擎 | 自定义字段、主子表、字段级权限、字段级只读锁 | 低代码平台（氚云/钉钉宜搭/明道云）或自研 |
| 状态机 | 显式状态定义 + 转移条件 + 非法转移拦截。派生字段必须由引擎生成 | 自研轻量状态机（约 300 行） |
| 规则引擎 | 定时扫描（≥15 分钟）+ 事件触发；必须幂等、可重跑、补跑历史 | XXL-Job / Quartz + 规则表 |
| 消息网关 | 企业微信应用消息，支持卡片跳转 HUB 单条任务 | 企业微信 API |
| 附件与版本 | 4D／ECN 必须版本受控：发布新版自动把旧版置为"已回收待确认" | 对象存储 + 版本表 |
| 工作日历 | 全系统"工作日"只认一份，支持法定节假日与调休 | 日历表 + 缓存 |
| 主子表性能 | ECN 在役设备子表可能上千行，需分页与批量导入 | — |
| 审计日志 | 所有降档、挂起、关闭、签批动作留痕不可删 | 操作日志表 |
为什么不建议继续用多维表
多维表能做字段和视图，做不了三件事：① 状态机（状态字段只能人工填，派生做不到）；② 签批与权限到字段（谁该改哪个字段管不了）；③ 定时规则引擎（预警只能靠人工巡查）。这三条正是本系统的核心价值，所以从多维表迁出是必要的，不是折腾。
11数据迁移
| # | 动作 | 验收标准 |
|---|---|---|
| 1 | 建 S11 设备档案，导入全部在役设备序列号 | 100% 有客户名、机型、出厂日期——这是 ECN 影响面清点的唯一来源，缺了这个整套根治链断一半 |
| 2 | 历史售后问题一次性补录进 S1 | 近 12 个月未关闭的问题 100% 有名有姓（责任人、设备、现状） |
| 3 | 历史工单补录（可选） | 仅补近 6 个月，用于建立"故障—备件"对照表初始值 |
| 4 | 双轨运行 4 周 | 多维表与新系统并行，差异清单每日核对，4 周后停用多维表 |
12分期实施与验收
一期（第 1–6 周）· 先把骨架立起来
| 交付 | 范围 | 验收标准（可测） |
|---|---|---|
| S1 主表 + 状态机 | 34 字段、7 状态、派生字段接口层加锁 | 尝试手工修改"主单状态"被系统拒绝；改落地物状态主单状态自动跟随 |
| S8 售后工单 | 25 字段、派工区自动带出 60% 字段 | 工程师建单时只需填执行区 9 个字段 |
| 角色权限 | 8 岗位、字段级只读锁 | 文员改不了"出口归属"；非经理点不到降档按钮 |
| 关闭校验 | 9.1 五条通用校验 | 无落地物编号时点关闭 → 报错并说明原因 |
| S11 设备/客户档案 | 导入全部在役设备 | 能按设备编号查出全部历史问题单 |
二期（第 7–12 周）· 补上五个落地物与规则引擎
| 交付 | 范围 | 验收标准（可测） |
|---|---|---|
| S3–S7 五张表（EQCT 为过程单） | 4D／EQCT／ECN／TIP／PCR | 五类出口各跑通 1 张真实单，关闭校验全绿 |
| 规则引擎 A1–A7 | 状态派生、三级预警、降级超时、挂起规则 | 造一条逾期数据，15 分钟内收到企业微信推送 |
| S10 HUB 待办中心 | 12 类任务、按人聚合 | 每个岗位登录后第一屏是 HUB；无第二个首页 |
| P0 快通道 | 快速归口、应急措施单、降级签字 | P0 单从创建到降级全程 ≤1 天，留痕完整 |
三期（第 13–20 周）· ECN 涉物落地与度量
| 交付 | 范围 | 验收标准（可测） |
|---|---|---|
| ECN 三态跟踪 | 文件态／物料态／实物态分列 + 影响面四数锁定 | 未锁定四数时生成请购按钮不可点 |
| 在役逐台子表 | 设备序列号 × 状态 × 旧件回收 | 能回答"改了 27 台还是 30 台" |
| 规则 A8–A15 | 重复识别、复发提醒、分级健康度 | 月度自动产出五项指标 |
| 看板与节拍 | 停滞看板、月度复盘报表 | 总经理只看一屏就能说出最卡的三张单 |
13V1 明确不做
写下来是为了防范围膨胀。以下都不在 V1：
· 客户自助报修门户（先走企业微信报修 + 人工建单）
· 财务/成本核算对接（工时与备件成本先只做记录）
· 与 PLM／ERP 双向集成（V1 用手工导入导出）
· 移动端 App（企业微信应用 + H5 卡片足够）
· 智能推荐备件（先积累"故障—备件"数据，一期只做历史提示）
· 九类出口全开（V1 只上文中确认的六类）
· 客户自助报修门户（先走企业微信报修 + 人工建单）
· 财务/成本核算对接（工时与备件成本先只做记录）
· 与 PLM／ERP 双向集成（V1 用手工导入导出）
· 移动端 App（企业微信应用 + H5 卡片足够）
· 智能推荐备件（先积累"故障—备件"数据，一期只做历史提示）
· 九类出口全开（V1 只上文中确认的六类）
14待确认清单
这几项尚未确定，影响设计，请产品侧拍板后再开工：
| # | 问题 | 影响范围 |
|---|---|---|
| 1 | 标准档时限锚点：从"发现时刻"还是从"派单时刻"起算？ 建议从派单时起算，否则与"按日归口批处理"冲突 | S10 任务到期逻辑、A3 规则 |
| 2 | "客户问题"出口（投诉/赔偿/服务态度）的关闭凭据是什么？ 当前口径下它不落 ECN 也不落 TIP，会关不掉 | S1 出口字典、第 9 节校验 |
| 3 | P0 判定清单：停机／停线／安全／批量／客户升级，各自的具体判据 | S1 字段 7、8 的下拉选项与培训材料 |
| 4 | 降级后的落地物应启动日是否统一 5 工作日？ 建议统一，简单可执行 | A3 规则 |
| 5 | ECN 论证的客户观察期默认天数（建议 30 天）与回标责任人是技术还是质量 | S5 状态机 |
| 6 | 到场 SLA 默认值（V0.2 新拟）：P0 4 小时 / P1 1 工作日 / P2 3 工作日；跨区域/偏远现场如何折算 | S8 承诺到场时间、到场超时预警 |
| 7 | 应关闭日出口分档（V0.2 新拟）：一般出口 T0 + 15 净工作日 / 技术变更出口 T0 + 30 净工作日，按第 5 节各阶段时限加总倒推，是否成立 | A2、字段 21、三级预警与月度指标口径 |
15V0.2 修订记录
V0.1 → V0.2 共 16 处修订：勘误 8 设计修订 7（需产品拍板） 新增默认值 1。设计修订已写入正文并加入第 14 节待确认清单，拍板后生效。
| # | 类别 | 位置 | 修订内容（原因） |
|---|---|---|---|
| 1 | 勘误 | 3.1 | S1 字段数矛盾（标题 34 / 表体 30）→ 补字段 31–34（创建人、创建时刻、最后操作人、最后操作时刻），全文统一 34；一期验收同步改 34 |
| 2 | 勘误 | 字段 20 | 挂起超限原引用 A9（影响面锁定闸门）→ 改为 A7 |
| 3 | 勘误 | 第 3 节 | 表数口径：过程文件 2 → 3（S2/S4/S9）；总数 11 个表单、13 张物理表 |
| 4 | 勘误 | 3.3 | 补 S9 配件申请单规格（原仅总表一行，无字段、无约束） |
| 5 | 勘误 | 字段 15 | 落地物指向范围「S3~S8」→「S3/S5/S6/S7/S8」（S4 非落地物） |
| 6 | 勘误 | S7 | PCR 字段数 14 → 13（实数） |
| 7 | 勘误 | 图 1 | 待派单标注「T0+15 分钟」→「P0 1h / P1 2h / P2 4h」，以第 4 节超时表为准 |
| 8 | 勘误 | 12 节二期 | 「S3~S7 五张落地物表」→「S3–S7 五张表（EQCT 为过程单）」 |
| 9 | 设计修订 | 2.2 / 字段 21 / A2 | 应关闭日改净工作日口径并按出口分档：一般出口 T0 + 15、技术变更出口 T0 + 30，挂起顺延，仍不随紧急度变化。原因：原统一 T0 + 10 下，4D 链自身即需 15 工作日、ECN 净链 18 起，数学上无法按期，只会制造常态红牌（入待确认 #7） |
| 10 | 设计修订 | A4 | 删「P0/P1 分别提前 6/14 天预警」——提前量不小于时限本身，建单当天即报警；改为「应关闭日前 2 工作日临近提醒」，与第 8 节通知矩阵统一 |
| 11 | 设计修订 | A6 / A7 | 挂起明示顺延应关闭日（净口径）；A7 补客户观察期上限 30 天，到期自动解除挂起（与待确认 #5 默认值一致） |
| 12 | 设计修订 | S5 / A13 | EQCT 改条件必填：技术变更出口必填，4D 引发的设计变更以关联 4D 为前置——打通质量出口经 4D 转 ECN 的路径（原路径无 EQCT 产生机制） |
| 13 | 设计修订 | 2.1 / S5 / 9.2 | 「整改负责人」统一为「ECN 整改负责人（技术岗）」，并在 2.1 技术岗动作中定义（原角色不在 8 岗位内） |
| 14 | 设计修订 | 2.2 | 权限矩阵：台账管理员取消「建单」权限，与其「只亮灯、不催办」定位一致 |
| 15 | 设计修订 | 8.1 / 8.2 | 「安装节点按期率」在本系统无数据源，替换为「备件一次带齐率」（数据源 S8）；安装进度周会标注数据来自项目台账（系统外）——否则与三期「自动产出五项指标」矛盾 |
| 16 | 默认值 | S8 | 补到场 SLA：P0 4 小时 / P1 1 工作日 / P2 3 工作日（原仅写「由 P 推出」无数值；入待确认 #6） |