AiDOPWarehouse/doc/_bid_ch4.py

# -*- coding: utf-8 -*-
"""附件五 技术方案 第 4 章 智能诊断与分析方案（3 分）。

对应评分要素：针对智能诊断模型设计、业务闭环自动化策略、数据分析建模的技术方案；
现场提供智能诊断 Demo 的优先。
"""

BLOCKS_CH4 = [
    ("p", "本章给出智能诊断模型设计、业务闭环自动化策略与数据分析建模三方面的技术方案，"
          "并在末节说明现场智能诊断演示的安排。"
          "本章所述诊断引擎、闭环机制与指标模型均已在平台中建成并运行，"
          "可在评审现场按采购人指定的业务场景实机演示。"),

    ("h2", "4.1　总体思路"),
    ("h3", "4.1.1　诊断要回答的三个问题"),
    ("p", "制造企业的运营诊断，本质上要回答三个递进的问题："
          "指标为什么没达成、问题出在哪个环节、应该由谁做什么。"
          "多数信息系统只能回答第一个问题的一半——"
          "把指标算出来、把红黄绿标出来，"
          "至于原因在哪、谁该负责，仍然依靠会议上的追问和经验判断。"),
    ("p", "本平台的诊断能力围绕这三个问题设计："
          "第一层用规则模型把确定性问题识别出来并给出触发依据；"
          "第二层用统计模型发现尚未越过阈值但走势值得关注的隐性问题；"
          "第三层用知识模型沿根因树与业务链路定位原因，"
          "并从措施库匹配建议措施与责任岗位。"
          "三层结论合并输出为一份可执行的诊断结果，"
          "而不是一句「该指标未达标」。"),
    ("h3", "4.1.2　可解释性是硬约束"),
    ("p", "平台把可解释性作为诊断模型的硬性约束："
          "任何诊断结论都必须能回答依据什么数据、经过什么判断、结论是什么，"
          "并且可以逐层下钻到明细单据。"
          "不采用无法解释的黑盒判定作为管理决策依据。"),
    ("p", "这一约束不是技术上的保守，而是落地的必要条件。"
          "制造企业的运营改善需要跨部门执行，"
          "一个不能说清依据的结论无法说服被指出问题的部门，"
          "最终会被搁置。"
          "反过来，只要结论的依据是清楚的、数据是可查的，"
          "即使判断偶有偏差，业务部门也能在复核中修正，"
          "系统的公信力反而在使用中逐步建立。"),
    ("h3", "4.1.3　规则与阈值全部可配"),
    ("p", "诊断规则、判定阈值、下钻维度、根因树结构、措施库与责任矩阵"
          "全部以配置形式存在，由实施人员或采购人的运营管理员在系统中维护。"
          "新增一类诊断场景不需要修改代码，"
          "这既是平台可在不同企业间复用的基础，"
          "也使采购人在业务规则调整后能够自主跟进，"
          "不必每次都提交变更需求。"),

    ("h2", "4.2　智能诊断模型设计"),
    ("h3", "4.2.1　三层模型结构"),
    ("p", "诊断模型分规则层、统计层与知识层三层，"
          "分别承担确定性问题识别、隐性异常发现与根因措施推荐，"
          "结构如下图。"),
    ("fig", ("fig_diag_model", "智能诊断模型三层设计")),
    ("h3", "4.2.2　规则模型"),
    ("p", "规则模型处理判定标准明确的问题，包含五类规则。"
          "阈值规则判断指标是否低于目标值；"
          "时效规则判断业务节点是否滞后，按滞后 10% 与 30% 两档触发预警与变更流程；"
          "齐套规则判断工单物料是否存在缺料且无在途补充；"
          "一致性规则判断账实是否相符、单据是否平衡；"
          "组合规则支持多条件的与或非组合，应对复杂判定场景。"),
    ("p", "规则模型的输出包含触发依据：命中了哪条规则、"
          "涉及的指标当前值与目标值、超出幅度、涉及的具体单据。"
          "业务人员看到预警后可以直接复核，"
          "不会出现说不清为什么报警的情况——"
          "这是规则模型相对统计模型的主要优势，"
          "因此平台把确定性问题优先交给规则层处理。"),
    ("h3", "4.2.3　统计模型"),
    ("p", "统计模型处理尚未越过阈值但值得关注的情况，包含五种方法："
          "趋势突变检测通过移动均值偏离识别走势拐点；"
          "同环比异常在修正季节性因素后判断同比环比波动是否异常；"
          "离群点识别用箱线图与 Z 分数定位异常样本；"
          "相关性分析发现指标之间的联动关系；"
          "分布漂移检测判断数据结构是否发生了变化。"),
    ("p", "统计模型的输出定位为「提示」而非「结论」，"
          "附带统计依据与置信度，交由业务判断。"
          "这样定位的原因是统计方法对数据量与稳定性有要求，"
          "在制造企业的实际数据条件下容易产生误报；"
          "把它作为提示而不是判定，"
          "既发挥了发现隐性问题的价值，"
          "也避免了误报累积损害系统公信力。"),
    ("h3", "4.2.4　知识模型"),
    ("p", "知识模型承担从问题到原因、从原因到措施的推理，包含五个组成部分。"
          "根因树把每类问题按可能原因分层展开，形成结构化的排查路径；"
          "链路回溯沿订单链定位断点所在的具体环节；"
          "历史案例匹配检索相似问题及其处置方式；"
          "措施库维护原因、措施与责任岗位的对应关系；"
          "效果反馈把措施的实际有效性积累回系统。"),
    ("p", "效果反馈是知识模型能够持续改进的关键。"
          "每次改善任务关闭时，系统记录采取的措施与验证结果；"
          "同类问题再次出现时，"
          "历史上有效的措施排在推荐列表前面，无效的措施权重下调。"
          "系统因此随使用逐步贴合企业的实际情况，"
          "而不是长期停留在实施时配置的初始状态。"),
    ("h3", "4.2.5　诊断场景清单"),
    ("p", "本项目规划的诊断场景如下表，覆盖交付、生产、供应、质量、库存五个方面。"
          "各场景的规则与阈值在实施阶段与采购人逐项确认后配置。"),
    ("table", ("智能诊断场景清单",
               ["诊断场景", "触发方式", "根因下钻维度", "输出与责任岗位"],
               [["订单交付延期风险", "节点滞后规则 + 时效模型",
                 "客户、产品、延误环节、责任部门",
                 "延期风险清单与预计影响交期，指派计划员"],
                ["订单齐套不足", "齐套规则实时触发",
                 "工单、物料、供应商、欠料原因",
                 "欠料清单与预计到货，指派采购员"],
                ["生产计划未达成", "日批指标 + 趋势模型",
                 "产线、班次、工序、停机原因",
                 "未达成原因分布，指派车间主任"],
                ["瓶颈工序识别", "产能负荷统计模型",
                 "工作中心、工序、时段",
                 "瓶颈工序与负荷曲线，指派工艺工程师"],
                ["供应商交付异常", "交期比对规则",
                 "供应商、物料品类、交付环节",
                 "供应商交付表现排名，指派采购员"],
                ["来料质量异常", "合格率阈值 + 离群识别",
                 "供应商、物料、检验项目、批次",
                 "不合格分布与批次追溯，指派 IQC 主管"],
                ["过程质量波动", "过程合格率趋势模型",
                 "产线、工序、检验项目、班次",
                 "波动趋势与关联工序，指派质量工程师"],
                ["库存周转异常", "周转率阈值 + 分布漂移",
                 "物料类别、库位、账龄",
                 "呆滞料清单与占用金额，指派物控员"],
                ["库存账实不符", "一致性规则 + 盘点差异",
                 "物料、库位、批次、差异方向",
                 "差异清单与追溯线索，指派仓管主管"],
                ["设备与模具风险", "寿命阈值 + 故障统计",
                 "设备、模具、产线、故障类型",
                 "保养与更换提示，指派设备管理员"]],
               [2.2, 2.6, 3.0, 3.6], ["l", "l", "l", "l"])),

    ("h2", "4.3　业务闭环自动化策略"),
    ("h3", "4.3.1　六步闭环与自动化动作"),
    ("p", "业务闭环由触发、定级、派单、处置、验证、关闭六步组成，"
          "每一步都有对应的自动化动作，全程由系统驱动。"),
    ("fig", ("fig_auto_closedloop", "业务闭环自动化策略")),
    ("p", "系统自动完成的动作包括：按配置规则对异常定级；"
          "按责任矩阵指派责任人与协办人；"
          "推送企业微信或钉钉通知并附带处理链接；"
          "处置完成后自动复测相关指标并判定验证结果。"
          "需要人工完成的只有填报原因与措施、上传证据、"
          "以及验证环节的现场确认，"
          "其余流转均不依赖人工推动。"),
    ("h3", "4.3.2　强制约束设计"),
    ("p", "闭环机制设置了三项强制约束。"
          "第一，未通过验证不得关闭：验证不通过的异常自动退回处置环节，"
          "系统不提供跳过验证直接关闭的操作。"
          "第二，超时自动升级：紧急异常 1 小时、重要异常 4 小时、"
          "一般异常 24 小时未响应，自动通知上级；"
          "超时两级仍未处置则进入管理层看板。"
          "第三，闭环质量本身被考核：异常发现数、响应及时率、闭环率、"
          "平均闭环时长与问题复发率作为管理指标统计，"
          "纳入部门运营评价。"),
    ("p", "这三项约束合起来解决的是同一个问题——"
          "改善措施执行不到底。"
          "制造企业并不缺少发现问题的能力，"
          "缺的是让每个问题都走完整个闭环的机制。"
          "把「谁在什么时候必须做什么」写进系统而不是写进制度文件，"
          "改善工作才能从依赖个人推动转为依赖机制运转。"),
    ("h3", "4.3.3　责任矩阵与时限配置"),
    ("p", "责任矩阵定义每类异常在每个环节的责任岗位、协办岗位与升级对象，"
          "与响应时限一并配置，如下表。"
          "本表为平台默认配置，实施阶段按采购人的组织结构与管理要求调整。"),
    ("table", ("异常分级、责任与时限配置",
               ["异常等级", "判定情形", "首次响应时限", "闭环时限", "升级路径"],
               [["紧急", "影响客户交付或导致停线，无替代方案",
                 "≤ 1 小时", "≤ 24 小时", "责任人 → 部门负责人 → 分管领导"],
                ["重要", "影响部门级业务指标，短期有替代方案",
                 "≤ 4 小时", "≤ 3 个工作日", "责任人 → 部门负责人"],
                ["一般", "影响局部作业效率，不影响交付",
                 "≤ 24 小时", "≤ 5 个工作日", "责任人 → 班组长"]],
               [1.6, 3.4, 2.0, 1.8, 4.0], ["c", "l", "c", "c", "l"])),
    ("h3", "4.3.4　改善成果固化"),
    ("p", "闭环的最后一步是固化。"
          "验证通过的改善措施若涉及流程或标准的变更，"
          "在系统中转化为对应的配置调整——"
          "例如修订检验规范、调整评审周期、更新货源清单份额、"
          "补充异常规则或调整阈值。"
          "同时把本次案例写入措施库，供同类问题参考。"),
    ("p", "这一步的意义在于避免同一个问题反复出现。"
          "如果改善只停留在个案处置，"
          "问题会随人员变动而重新发生；"
          "只有把改善成果固化为系统中的规则与标准，"
          "才真正形成了组织能力的积累。"
          "平台统计的问题复发率指标，"
          "衡量的正是固化工作是否到位。"),

    ("h2", "4.4　数据分析建模"),
    ("h3", "4.4.1　指标体系与维度模型"),
    ("p", "数据分析建模包含两部分：纵向的指标体系与横向的维度模型。"
          "指标体系分四级，从战略层的结果指标逐层支撑到明细层的单据证据；"
          "维度模型采用星型结构，时间、组织、客户、物料、供应商等维度统一定义、"
          "全部指标共用，避免各看板口径不一。"),
    ("fig", ("fig_metric_model", "数据分析建模：指标体系与维度模型")),
    ("h3", "4.4.2　指标卡片"),
    ("p", "每个指标在系统中都有一张指标卡片，"
          "写明业务定义、计算公式、数据来源、统计口径、"
          "计算频次、单位、目标值与责任岗位，并可在看板上直接查看。"
          "指标口径在项目实施的口径确认环节由采购人逐项签署确认，"
          "作为后续验收与考核的共同基准。"),
    ("p", "把口径确认作为一个正式环节而不是隐含假设，"
          "是数据类项目成败的分水岭。"
          "多数指标争议并非源于计算错误，"
          "而是源于双方对「及时」「合格」「齐套」的定义理解不同。"
          "在实施前把这些定义逐条写清并签署，"
          "上线后就不会陷入反复讨论「这个数怎么算的」。"),
    ("h3", "4.4.3　核心指标清单"),
    ("p", "本项目规划的核心指标如下表，"
          "按采购需求涉及的运营维度组织。"
          "各指标的具体口径与目标值在实施阶段确认。"),
    ("table", ("核心运营指标清单",
               ["维度", "核心指标", "计算口径要点", "责任岗位"],
               [["交付", "订单交付及时率",
                 "实际交付日期不晚于承诺交期的订单数占比", "计划部门"],
                ["交付", "订单准时齐套率",
                 "上线前完成齐套的工单数占比", "物控部门"],
                ["交付", "订单评审及时率",
                 "在评审周期内完成评审的订单占比", "销售内勤"],
                ["生产", "生产计划完成率",
                 "实际完工数量占日计划数量的比例", "车间"],
                ["生产", "设备利用率",
                 "设备实际运行工时占可用工时的比例", "设备管理"],
                ["生产", "工序流转及时率",
                 "按标准工时完成工序流转的比例", "工段"],
                ["供应", "供应商交付及时率",
                 "按承诺交期到货的采购行项占比", "采购部门"],
                ["供应", "采购订单执行率",
                 "已交付数量占订单数量的比例", "采购部门"],
                ["质量", "来料检验合格率",
                 "IQC 合格批次占检验批次的比例", "质量部门"],
                ["质量", "过程检验合格率",
                 "IPQC 合格批次占检验批次的比例", "质量部门"],
                ["质量", "成品一次合格率",
                 "FQC 首次检验即合格的批次占比", "质量部门"],
                ["库存", "库存周转率",
                 "期间出库金额与平均库存金额之比", "物控部门"],
                ["库存", "库存准确率",
                 "盘点无差异项占盘点项的比例", "仓储部门"],
                ["运营", "异常闭环率",
                 "已验证关闭的异常占已发现异常的比例", "运营管理"],
                ["运营", "问题复发率",
                 "关闭后再次发生的同类问题占比", "运营管理"]],
               [1.3, 2.7, 5.4, 1.9], ["c", "l", "l", "l"])),
    ("h3", "4.4.4　ChatBI 与自助分析"),
    ("p", "ChatBI 提供自然语言取数能力，"
          "业务人员用日常语言提问即可获得数据结果与图表，"
          "例如询问某个客户上月的交付及时率、"
          "或某条产线本周的计划完成情况。"
          "ChatBI 的取数不绕过指标体系："
          "问题经语义解析后映射到已定义的指标与维度，"
          "从同一套指标结果表取数，"
          "因此 ChatBI 给出的数值与看板完全一致。"),
    ("p", "这一设计避免了自助分析工具常见的问题——"
          "使用者用不同的过滤条件和聚合方式各自算出一个数，"
          "最终谁的数都对不上。"
          "把自然语言入口约束在统一的指标语义层之上，"
          "既保留了灵活提问的便利，也保住了口径一致。"),

    ("h2", "4.5　现场智能诊断演示安排"),
    ("p", "评分要素明确「现场提供智能诊断 Demo 的优先」。"
          "我方可在评审现场提供智能诊断的实机演示，"
          "演示环境为已部署运行的平台实例，"
          "演示数据为制造业真实业务结构的样例数据，"
          "非静态截图或视频录像。"),
    ("table", ("现场演示内容安排",
               ["演示环节", "演示内容", "预计时长"],
               [["运营总览", "九宫格智慧运营看板一屏总览，红黄绿状态判读", "3 分钟"],
                ["指标下钻", "从 L1 结果指标逐级下钻至 L4 明细单据证据", "5 分钟"],
                ["诊断触发", "指定一条交付延期或缺料场景，实时触发诊断", "5 分钟"],
                ["根因定位", "按维度下钻与链路回溯定位问题环节", "5 分钟"],
                ["闭环处置", "生成改善任务、指派责任人、推送通知", "4 分钟"],
                ["验证关闭", "复测指标、验证判定、案例归档", "3 分钟"],
                ["自助分析", "ChatBI 自然语言提问取数与图表生成", "3 分钟"],
                ["异常大屏", "交付、生产、供应三类异常大屏效果", "2 分钟"]],
               [2.0, 6.6, 2.0], ["l", "l", "c"])),
    ("p", "演示可由评审小组现场指定业务场景与筛选条件，"
          "以验证系统的真实响应能力而非预设脚本。"
          "若评审安排不便进行现场演示，"
          "我方可提供远程演示或按采购人指定时间到现场专项演示，"
          "并在演示后提交演示记录。"),
]