AiDOPWarehouse/doc/_bid_ch1_b.py

# -*- coding: utf-8 -*-
"""附件五 技术方案 第 1 章 项目需求理解及综合分析：1.7～1.9。

1.7 逐场景配已建成模块的实际流程图，1.8 给出八张总体设计蓝图。
"""

BLOCKS_B = [
    # ============================================================ 1.7
    ("h2", "1.7　制造业业务场景理解"),
    ("p", "评分细则要求投标人对制造业运营场景有详尽理解，涵盖产销、制造、供应、采购、"
          "物料仓储、生产执行、成品仓等核心业务场景，以及智能诊断场景、闭环管理逻辑与"
          "数据分析需求。本节按上述场景逐一说明我方的业务理解，"
          "并以我方已建成模块的实际业务流程图佐证——所有流程图均来自我方已交付的"
          "模块蓝图设计方案，而非为投标临时绘制的示意图。"),

    ("h3", "1.7.1　产销协同场景"),
    ("p", "产销协同是 OTD 主线的起点，其业务本质是在客户交期诉求与工厂实际能力之间"
          "达成一个可兑现的承诺，并对这个承诺的执行过程持续跟踪。场景的主线是"
          "销售订单接收、订单评审与交期评估、工单下达、交期确认、发货计划与 ASN 发货；"
          "支撑流程包括产品设计管理、合同评审管理与需求明细核验；"
          "变更管理作为主线的旁路，处理评审后的交期调整。"),
    ("fig", ("s1_otd_mainline", "S1 产销协同总体业务流程（含支撑流程与数据中台链路）")),
    ("p", "我方对本场景的关键理解有三点。其一，订单评审必须同时看到产能负荷与物料库存，"
          "只看其中之一都会导致承诺失真；其二，交付跟踪要落到节点而不是订单整体，"
          "只有节点级的时效标准才能支撑滞后 10% 与 30% 的分级预警；"
          "其三，变更管理必须是标准流程而非例外处理，交期变更要走审批、要与客户协商、"
          "要回写订单状态，否则交付数据会与实际脱节，OTD 交付率也就失去了考核意义。"),
    ("p", "在交付跟踪的操作层面，业务人员从交付列表筛选查询进入订单详情后，"
          "可按订单信息、评审与变更、物料需求、入库发运追踪等页签逐层查看，"
          "把一张订单在全链路上的状态收敛到同一个界面。"),
    ("fig", ("s1_order_delivery", "S1 订单交付跟踪操作流程")),

    ("h3", "1.7.2　制造协同场景"),
    ("p", "制造协同承接产销协同下达的工单，解决“什么时候、在哪条线、按什么顺序做”的问题。"
          "主线流程为 S1 工单下达、生产排程（工序加优先级）、物料需求同步（MRP 确认）、"
          "可执行日计划下达产线，最终交由 MES 执行，并通过进度看板回收完工与领料情况。"
          "排程与日计划的可用产能约束来自基础数据管理，包括产线工作日历（班次定义）、"
          "休息时间管理（产线停休）、节假日管理（休假与调班）与加班管理（延长工时）。"),
    ("fig", ("s2_plan_to_exec", "S2 制造协同总体业务流程（排程到执行）")),
    ("p", "我方理解本场景的难点不在排程算法本身，而在产能日历的准确性。"
          "中小企业的班次、调班、加班变动频繁，如果这些基础数据不进系统，"
          "再精细的排程也只是纸面计划。因此我方把工作日历、停休、节假日与加班"
          "作为独立的基础数据域来建设，作为排程与日计划的前置输入。"),

    ("h3", "1.7.3　供应协同场景"),
    ("p", "供应协同解决“要什么料、什么时候要、缺多少”的问题，包含物料计划、采购管理与"
          "协同看板三个业务域。物料计划域从工单、库存、在途数据同步开始，"
          "经 MRP 净需求计算后发布物料需求并跟踪交货计划，交货异常单独记录；"
          "采购管理域根据物料类型自动合并生成要货令、采购订单或委外加工订单，"
          "工单下达时自动生成工序外协订单；"
          "看板域提供四维 KPI 卡片与趋势、工单齐套看板、MDP 运行监控与策略模拟分析。"),
    ("fig", ("s3_domains", "S3 供应协同总体业务流程（物料计划 · 采购管理 · 协同看板三域）")),
    ("p", "齐套是本场景中管理层最关心的指标。我方的做法是把齐套分析做成从数据同步、"
          "MRP 齐套计算、多字段齐套信息展示、欠料定位与供应商维度分析到缺料预警与"
          "策略建议输出的完整链路，让缺料不仅能被发现，还能定位到具体物料与供应商。"),
    ("fig", ("s3_shortage", "S3 齐套分析与缺料预警流程")),

    ("h3", "1.7.4　采购执行场景"),
    ("p", "采购执行是供应协同的下游，重点在于把供应商纳入协同链路。交货执行域覆盖"
          "物料交货计划发布、供应商交货计划发布、供应商交期回复、供应商生成发货单"
          "以及在途与在检入库跟踪；退货闭环域覆盖 IQC 来料检验、不合格判定"
          "（退货／让步／挑选）、退货单创建与退货出库；"
          "看板域提供采购执行看板与供应商欠料看板，并支持导出报告。"),
    ("fig", ("s4_domains", "S4 采购执行总体业务流程（交货执行 · 退货闭环 · 执行看板三域）")),
    ("p", "我方理解供应商交付率这一指标的公信力取决于数据来源。"
          "如果交付时间靠采购员事后补录，排名就会失真。因此本场景的设计要点是"
          "让供应商在门户上自行回复交期、生成发货单，交货数据在发生时即被记录，"
          "退货单数据反过来又作为供应商绩效评估的输入，形成双向约束。"),

    ("h3", "1.7.5　物料仓储场景"),
    ("p", "物料仓储场景的核心诉求是掌握物料的入库、检验与库存状态，"
          "为齐套与生产提供准确的库存基数。采购需求明确本模块以对接 ERP 获取数据为主"
          "（第 36、37 条），因此我方在此场景采用贴源只读的集成策略："
          "从源系统定时或手动抽取物料仓储单据、库存流水与检验申请，"
          "写入贴源层后转换标准层完成类型过滤与字段解码，"
          "再按工厂作用域与单据类型过滤后提供只读查询，"
          "同时汇总为 KPI 明细层、计算 L1 指标并写入指标日表，支撑看板逐层下钻。"),
    ("p", "本场景的业务价值集中在两点。一是为齐套分析提供准确的库存基数——"
          "S3 的 MRP 净需求计算要扣减现有库存与在途量，而库存数字如果滞后于实际，"
          "净需求就会算多或算少，前者造成积压、后者造成停线，"
          "因此物料仓储数据的同步时效直接决定了齐套分析的可信度。"
          "二是为质量追溯保留来料端的起点——来料检验结果与物料批次在此环节建立关联，"
          "后续 S6 工序报工与 S7 成品序列号的追溯链条都以此为源头。"
          "此外，平台还需支持对接 ERP 导入质检检验规范作为质检要求规则，"
          "使检验标准与检验执行在同一套口径下运行。"),
    ("fig", ("s5_lifecycle", "S5 物料仓储贴源同步与只读消费生命周期")),
    ("p", "这一策略的关键约束是只读、不回写源库。中小企业的 ERP 通常是生产运行的"
          "核心系统，任何写入都可能影响其业务一致性。"
          "我方在集成设计上严格区分入站采集与出站回写两条通道，"
          "出站回写只走经过采购人确认的 Outbox 事务表与接口，绝不直接操作源库表，"
          "这是保证既有系统安全的基本前提。"),

    ("h3", "1.7.6　生产执行场景"),
    ("p", "生产执行场景在贴源同步的基础上增加了平台侧的检验流转。"
          "源系统提供过程检验单、设备台账、模具工装台账与工单制造数据，"
          "经贴源同步与标准层转换后，一路提供过程检验单、设备、模具工具的只读查询与明细，"
          "并在平台上完成 IPQC 检验流转——检验员按白名单录入检验结果，"
          "提交主管审核，审核不通过则退回重录，通过后流程完成、状态写入扩展表；"
          "另一路汇总为 KPI 明细层，计算 L1 指标写入指标日表，支撑生产执行看板下钻。"),
    ("p", "生产执行是 OTD 主线上数据产生最密集的环节，也是设备综合效率 OEE 与"
          "工序不合格率两项核心指标的数据来源。我方理解 OEE 的计算难点不在公式，"
          "而在时间与产量口径的一致性——计划停机与非计划停机如何区分、"
          "换型时间是否计入负荷时间、返工产量是否计入合格产量，"
          "这些口径必须在实施阶段与采购人逐项确认并固化到指标定义中，"
          "否则不同车间算出的 OEE 无法横向比较，指标也就失去了管理意义。"
          "安灯异常在本场景中同样重要：操作工通过安灯系统填报故障后，"
          "平台需在 15 分钟内完成推送并进入 S8 异常处理闭环，"
          "使停机时间同时成为异常管理的输入与 OEE 扣减的依据。"),
    ("fig", ("s6_ipqc", "S6 生产执行贴源同步与 IPQC 检验流转")),
    ("p", "此处“状态入扩展表、不改源单据状态列”的设计值得特别说明："
          "平台承载了源系统没有的审核流转能力，但把流转结果记录在自己的扩展表中，"
          "既满足了业务闭环需要，又避免了对源单据的侵入式修改。"
          "这一模式同样适用于安灯异常处理与设备 OEE 统计场景。"),

    ("h3", "1.7.7　成品仓储场景"),
    ("p", "成品仓储场景覆盖生产入库单、销售发货通知、FQC 检验单与订单发货数据，"
          "同样采用贴源只读加平台侧消费的模式：贴源同步后转换标准层，"
          "按单据类型与工厂作用域过滤，提供入库单、发货通知、FQC 的只读查询与明细，"
          "同时汇总为 KPI 明细宽表（含跨库只读）并计算 L1 指标，支撑成品仓储看板下钻。"),
    ("p", "成品仓储是 OTD 主线的终点，也是 OTD 交付率这一核心指标的取数环节。"
          "我方理解交付率的统计口径需要在实施阶段明确三件事：以发货日期还是签收日期"
          "作为实际交付时间、交期变更后以原始承诺交期还是变更后交期作为考核基准、"
          "部分交付的订单如何计入分子分母。这三个口径直接决定了交付率数值的高低，"
          "必须由采购人确认后固化，才能保证指标在不同期间与不同产品线之间可比。"
          "本场景同时承担成品唯一标识职责，成品包装上的唯一序列号标签"
          "既是出库发运的凭据，也是售后扫码溯源的入口。"),
    ("p", "本场景还需与 S1 产销协同形成闭合。成品入库完成或交付日期到期时，"
          "S1 生成销售发货通知单并对接 ERP（第 24 条），发货执行结果又回流到本场景的"
          "销售出库与发货数据中，最终决定订单在交付跟踪链路上的终态。"
          "这条回路一旦断开，就会出现货已发出但订单仍显示在途的典型数据不一致问题，"
          "因此我方在设计上要求发货通知与出库执行必须通过统一的单据编号关联，"
          "并由平台定时核对两侧状态、对超时未回写的记录主动告警。"),
    ("fig", ("s7_lifecycle", "S7 成品仓储贴源同步与只读消费生命周期")),
    ("p", "本场景还承担售后追溯职责。采购需求要求成品序列号可追溯至原材料批次号、"
          "生产操作工号与检验员（第 45 条），这意味着追溯链条要跨越 S5 来料批次、"
          "S6 工序报工与检验、S7 成品入库三个环节。"
          "我方的实现方式是在 DWD 明细宽表中以成品序列号为主键，"
          "关联工单号、物料批次号、工序报工记录与三检记录，"
          "使扫码即可一次性拉出完整追溯链，而不需要在多个系统间人工比对。"),

    ("h3", "1.7.8　智能诊断场景"),
    ("p", "智能诊断是本项目区别于常规信息化系统的核心场景，也是评分细则单独点名的内容。"
          "采购需求要求以销售订单为主线串联需求预测、采购计划、来料入库、车间生产、"
          "半成品流转、成品入库、发货配送全部业务节点，自动识别断点、滞后、损耗、"
          "供需失衡、库存积压、交付延期、产能浪费、物流低效等异常，"
          "并依托多维度关联算法完成根因溯源（第 63～65 条）。"),
    ("p", "我方对诊断逻辑的理解分为四步。第一步是链路完整性判定：任一节点缺失前序单据、"
          "状态未流转或时间倒挂，即判定为链路断点。第二步是异常识别，"
          "按实时类与周期类分别处理——物料缺料、生产停滞、发货延迟等实时类问题"
          "识别延迟控制在 3 分钟以内，库存积压、供需失衡、产能利用率等周期类问题"
          "每日定时执行分析（第 66 条）。第三步是根因溯源，"
          "按订单、物料、供应商、产线、仓库、时间段、人员 7 个维度逐级下钻（第 67 条），"
          "每条结论都保留可回溯到订单主线或指标编码的证据快照。"
          "第四步是输出诊断报告与可落地的改善策略建议，并直接生成改善任务。"
          "完整的诊断架构详见 1.8.6 节。"),

    ("h3", "1.7.9　闭环管理逻辑"),
    ("p", "采购需求要求搭建问题建档、整改派单、过程跟踪、效果量化复盘、优化经验固化的"
          "一体化闭环流程，并自动对比改善前后各环节经营指标（第 68、69 条）。"
          "我方将其理解为一条刚性的 PDCA 链条：任何一次异常都必须走完"
          "发现、定级、诊断、建档、派单、执行、验证、固化八个环节，"
          "未经验证通过的改善单不得关闭。"),
    ("p", "闭环能否真正落地，取决于四条刚性约束：改善单必须关联诊断问题或指标编码，"
          "保证端到端可追溯；派单复用平台既有审批流，不另建孤立的任务系统；"
          "效果验证必须保留基线值、目标值与验证结论；"
          "验证未通过的改善单自动退回继续改善。"
          "复盘通过后，有效措施沉淀为标准化管控规则并回写 S0 运营建模，"
          "使一次改善的经验成为后续所有订单的默认约束。闭环逻辑图详见 1.8.8 节。"),

    ("h3", "1.7.10　数据分析需求"),
    ("p", "数据分析需求的实质是让不同层级的人在同一套数据口径下看到自己需要的粒度。"
          "管理层需要一屏总览，部门需要本部门的执行细节，业务人员需要能自己查、自己钻。"
          "我方按管理层大屏、部门看板、指标下钻、明细证据、诊断改善五级贯通设计，"
          "其中管理层大屏采用九宫格布局对应 S1～S9 九个业务段，"
          "每格展示模块核心 KPI 与红黄绿状态，点击任一格进入对应部门看板或模块详情看板。"),
    ("p", "自助分析的操作路径为：进入模块看板、查看 L1 核心 KPI 卡片、"
          "按客户或产品等维度筛选过滤、沿 L2 至 L4 逐级下钻、"
          "最终落到趋势图表与明细单据。"),
    ("fig", ("s1_kanban", "看板指标下钻与自助分析操作路径（以 S1 产销协同为例）")),
    ("p", "此外，ChatBI 为不熟悉看板操作的业务人员提供自然语言问数入口，"
          "按意图理解、匹配业务规则、生成 SQL、查询数据、生成解释的流程返回答案"
          "（第 70 条）。我方强调 ChatBI 必须建立在数据中台的指标层与业务规则之上，"
          "而不是对业务库的自由查询，否则同一个问题在不同时间会得到不同口径的答案。"),

    # ============================================================ 1.8
    # 九张总体蓝图信息密度高，整节改用横排页，保证打印后图内文字可辨认
    ("landscape", None),
    ("h2", "1.8　总体设计蓝图"),
    ("p", "基于前述对项目背景、应用环境、体系结构、功能需求、性能要求、实施要求"
          "与业务场景的理解，我方输出本项目的总体设计蓝图，"
          "包括业务蓝图、主数据蓝图、应用架构、数据架构、技术架构、集成接口架构、"
          "智能诊断架构、看板与下钻结构、闭环管理逻辑共九张图，"
          "覆盖从业务到数据、从架构到运行的完整设计视角。"),

    ("h3", "1.8.1　OTD 端到端总体业务蓝图"),
    ("p", "总体业务蓝图以销售订单为主线，自上而下分为五个层次："
          "S0 运营建模作为基座提供主数据与流程标准；"
          "OTD 业务主线覆盖从销售订单接收到销售发货交付客户的十二个关键节点，"
          "并叠加节点滞后自动预警与交付变更管理；"
          "S8 全流程异常监控横向贯穿业务主线；"
          "S9 完成运营绩效指标测量、看板呈现、问题诊断、改善闭环与 ChatBI 问数；"
          "底层由数据中台与系统集成层提供数据采集、治理与出站回写支撑。"),
    ("p", "这张蓝图回答了本项目最根本的一个问题：一张销售订单从进入企业到交付客户，"
          "在系统里究竟走过哪些节点、每个节点由谁负责、状态如何流转、数据落在哪一层。"
          "采购需求第 17 条要求绘制 OTD 全流程蓝图，明确各节点的输入、输出、"
          "责任部门与岗位、操作时效标准，形成可视化价值流，本图即为该要求的直接响应，"
          "并在实施阶段进一步细化为逐节点的 SOP 文件（第 18 条）。"),
    ("p", "蓝图的层次划分体现了我方对本项目建设逻辑的理解。S0 之所以置于最上方作为基座，"
          "是因为主数据与流程标准不先统一，下游所有环节的数据都无法对齐；"
          "S8 之所以横向贯穿而非串联在主线中，是因为异常可能发生在任何节点，"
          "监控必须是横切能力而不是某一段的功能；"
          "S9 之所以独立成层，是因为指标测量、诊断与改善作用于整条主线，"
          "其输入来自各段业务、其输出又回流为对各段业务的约束；"
          "而数据中台与系统集成之所以置于最底层，是因为上述所有能力都依赖"
          "一条干净、完整、及时的数据链路，这也是本项目投入产出比最高的基础工程。"),
    ("figfull", ("fig_otd_blueprint",
                 "Ai-DOP 制造业数据智能运营平台 OTD 端到端总体业务蓝图")),

    ("h3", "1.8.2　主数据蓝图"),
    ("p", "主数据是全平台的数据基准。S0 基础主数据分为质量、仓储、制造、供应、销售五大主数据域，"
          "数据来源包括人工录入、外部系统同步与源平台迁移，"
          "并由平台组织与数据字典提供统一的字典与作用域定义。"
          "五大主数据域向下游 S1～S9 各业务模块统一供数，"
          "实现采购需求第 13 条要求的“一处修改、全系统同步”。"),
    ("fig", ("s0_master_dataflow", "S0 基础主数据数据流与下游业务消费关系")),

    ("h3", "1.8.3　应用架构"),
    ("p", "应用架构按接入与展现、业务应用、领域服务、数据服务、集成适配五层划分，"
          "并以安全体系与运维体系两条纵向支撑贯穿全部层次。"
          "领域服务层的设置是本架构的关键：把订单与交付、计划与排程、采购与供应、"
          "质量与追溯、指标与诊断等可复用能力从各业务模块中抽离出来统一沉淀，"
          "既避免了模块间重复建设，也使新增业务场景能够快速组装上线，"
          "是支撑“标准化、可复制产品包”的结构性保障。"),
    ("p", "分层的另一层意义在于变更隔离。企业上线后最频繁的变化来自两端："
          "上端是业务口径与展示需求的调整，下端是源系统版本升级或接口变更。"
          "五层划分把这两类变化分别锁在接入展现层与集成适配层内，"
          "中间的领域服务层与数据服务层保持稳定，"
          "从而使一次源系统升级不会波及看板，一次看板改版也不会触及业务逻辑，"
          "这对于运维力量薄弱的中小企业尤为重要。"),
    ("p", "图中纵向的安全体系与运维体系贯穿全部五层，对应采购需求第 83 条"
          "“高安全性”与“易运维性”两项设计原则。安全体系覆盖数据、应用、网络、审计四个维度，"
          "运维体系覆盖监控、日志、备份、扩容四类能力，"
          "二者不是附加模块而是各层在设计时即须满足的横向约束。"
          "底部的外部业务系统一行标明了平台的集成边界，"
          "并通过工业互联网平台的 OAuth2.0 单点登录实现员工一次登录即可访问 Ai-DOP"
          "（第 55 条）。"),
    ("p", "需要说明的是，业务应用层中的运营诊断与改善闭环两项没有归入 S0～S9 任一模块，"
          "而是与十个业务段并列。这是因为诊断与改善的作用对象是整条订单主线，"
          "其数据输入来自各段业务、其输出的管控规则又回流为对各段业务的约束，"
          "若把它们塞进 S9 之下，容易被理解为看板的附属功能，"
          "从而在实施时被简化为几张分析报表，这与采购需求第 63～69 条"
          "所要求的“端到端诊断＋闭环改善”相去甚远。"),
    ("p", "领域服务层中的五组业务能力与五项平台能力，是我方在既有项目中已经沉淀并复用的资产，"
          "而不是为本项目临时划分的概念。正是因为这些能力已经产品化，"
          "本项目才有条件在采购需求第 100 条规定的工期内完成 S0～S9 全模块交付——"
          "实施工作的重心可以从编码转向主数据落地、集成通道配置与指标口径确认，"
          "这一点在 1.6.6 节的工期分析中已作说明。"),
    ("figfull", ("fig_application", "Ai-DOP 平台应用架构")),

    ("h3", "1.8.4　数据架构"),
    ("p", "数据架构围绕数据中台的“采、存、治、用”组织。采集侧接入 ERP、MES、QMS、"
          "SRM、WMS、CRM、TMS、OA 与 IoT 等多源系统；"
          "存储与治理侧按 STG 贴源、STD 标准、DWD 明细宽表、DWS 指标四层建模，"
          "并配套 MDM 主数据管理与元数据、血缘、质量稽核规则；"
          "消费侧支撑九宫格看板、部门看板与自助下钻、运营问题诊断、改善闭环与效果验证、"
          "ChatBI 智能报表、S8 异常预警与 AI 智能体，"
          "同时通过 Outbox 出站回写将业务结果送回 ERP、MES 等系统。"),
    ("fig", ("fig_data", "数据架构：数据中台「采—存—治—用」")),

    ("h3", "1.8.5　技术架构"),
    ("p", "技术架构采用主流开源技术栈与容器化部署，自上而下分为客户端、接入层、应用层、"
          "数据层、运行与部署、监控安全运维六个层次。"
          "前端采用 Vue 3 与 TypeScript，后端采用 .NET 8 与 Admin.NET 分层架构，"
          "数据访问通过 SqlSugar 实现多库适配，"
          "缓存、会话与分布式锁由 Redis 承担，业务库与数据中台库物理分离，"
          "整体部署基于 Docker 容器化并支持开发、测试、UAT、生产多环境隔离。"),
    ("fig", ("fig_tech", "Ai-DOP 平台技术架构")),

    ("h3", "1.8.6　系统集成与接口架构"),
    ("p", "集成架构自左至右分为源系统、集成通道、统一数据底座与上层应用四段。"
          "集成通道提供数据库直连、HTTP-API、WebService、FTP 文件、MQ 消息、"
          "物联网网关六种接入方式，支持定时与实时两种同步模式，"
          "并通过可视化通道配置完成数据源、实体映射与调度策略的定义，"
          "使新增一套第三方系统的配置在 4 小时内完成；"
          "清洗与标准化环节自动执行字段标准化、空值过滤、异常值标记与编码统一；"
          "监控与容错环节提供同步日志、异常告警、断点续传与重试去重。"
          "出站方向通过 mdp_outbox 出站事务表经 API 推送回写至 ERP／MES 并做回执核对。"),
    ("fig", ("fig_integration", "系统集成与接口架构")),

    ("h3", "1.8.7　智能诊断与分析架构"),
    ("p", "智能诊断架构分为五个部分：端到端数据链路以销售订单为主线串联八个业务节点"
          "并识别链路断点；异常识别按规则与模型覆盖断点、滞后、损耗、供需失衡、"
          "库存积压、交付延期、产能浪费、物流低效八类问题，"
          "并区分实时类与周期类分别处理；根因溯源支持订单、物料、供应商、产线、仓库、"
          "时间段、人员 7 个维度下钻并配合多维关联算法；"
          "诊断输出与改善闭环完成从诊断报告、改善建议、问题建档、整改派单到效果复盘的串联；"
          "底层由统一数据抽取、指标计算引擎、阈值与规则库、AI 智能体集群与 ChatBI 提供支撑。"),
    ("fig", ("fig_diagnosis", "智能诊断与分析架构")),

    ("h3", "1.8.8　九宫格智慧运营看板与指标下钻结构"),
    ("p", "看板结构分为三部分：管理层大屏采用九宫格布局，对应 S1 至 S9 九个业务段，"
          "每格展示模块名称、核心 KPI 与红黄绿状态；"
          "部门看板按角色与数据权限分发，生产部、采购部、质量部各自呈现本部门关注指标；"
          "指标下钻按 L1 模块级核心 KPI、L2 维度分解指标、L3 过程与工序级指标、"
          "L4 单据与批次明细四级组织，并可由 L4 直接进入运营问题诊断，"
          "形成从总览到明细再到诊断的完整通路。"),
    ("fig", ("fig_kanban", "九宫格智慧运营看板与指标下钻结构")),

    ("h3", "1.8.9　闭环管理逻辑"),
    ("p", "闭环管理逻辑图给出异常从发现到固化的八个环节及其刚性约束，"
          "并在固化环节回流至监控环节，形成螺旋上升的持续改善循环。"
          "该逻辑同时也是采购需求第 6 条所要求的企业“体检”体系的运行机制——"
          "体检不止于出报告，而要以改善单的闭环率与平均闭环时长作为体检有效性的度量。"),
    ("fig", ("fig_closedloop", "异常发现 → 诊断 → 改善 → 验证 闭环管理逻辑")),

    # ============================================================ 1.9
    ("portrait", None),
    ("h2", "1.9　需求理解与采购需求对照"),
    ("p", "为便于评审核对，现将询比文件第五章采购需求的全部 100 条条目按业务主题归并，"
          "与本章各节逐一对应如下。逐条实质性应答见响应文件第六章"
          "“技术响应文件·技术要求的汇总应答”。"),
    ("table", (
        "采购需求条目与本章章节对照",
        ["采购需求条目", "需求主题", "本章对应章节"],
        [
            ["第 1～8 条", "项目背景、五项建设目标与两项核心目标", "1.1.1、1.1.3"],
            ["第 9～20 条", "S0 运营建模：主数据规范、物料统一编码、工艺主数据、"
                          "数据导入与实时同步、单据与流程标准化", "1.4.1、1.8.2"],
            ["第 21～25 条", "S1 产销协同：订单评审、交付承诺与全流程跟踪、预警与交付变更、"
                           "订单发货、优先级规则", "1.4.2、1.7.1"],
            ["第 26～29、32、33 条", "S2 制造协同：主生产计划、产能平衡、工单执行监控、"
                                 "排程工具、移动端", "1.4.3、1.7.2"],
            ["第 30、31 条", "S3 供应协同：MRP 净需求计算、供应商交付率排名",
             "1.4.4、1.7.3"],
            ["第 34 条", "S4 采购执行：采购计划发布与供应商门户", "1.4.5、1.7.4"],
            ["第 35～37 条", "S5 物料仓储：来料检验、库存操作与质检规则", "1.4.6、1.7.5"],
            ["第 38～41 条", "S6 生产执行：过程检验、工序汇报、安灯异常、设备 OEE",
             "1.4.7、1.7.6"],
            ["第 42～46 条", "S7 成品仓储：成品检验、入库、出库、售后追溯、唯一标识",
             "1.4.8、1.7.7"],
            ["第 47～52 条", "S8 全流程异常监控：异常类型、提报、分级响应、处理闭环、"
                           "AI 智能体", "1.4.9、1.7.9"],
            ["第 53～55 条", "系统对接、无缝集成与单点登录", "1.2.2、1.4.10、1.8.6"],
            ["第 56 条", "数据治理与数据中台", "1.2.3、1.8.4"],
            ["第 57～62 条", "九宫格智慧运营看板、KPI 定义与自动计算、偏差分析、"
                           "部门看板、自助分析与下钻", "1.4.10、1.7.10、1.8.8"],
            ["第 63～67 条", "运营问题诊断：端到端链路、异常自动识别、根因溯源、"
                           "时效指标、7 维下钻", "1.7.8、1.8.7"],
            ["第 68、69 条", "运营问题改善闭环与效果量化复盘", "1.7.9、1.8.9"],
            ["第 70 条", "ChatBI 智能报表", "1.4.10、1.7.10"],
            ["第 71～78 条", "系统集成：接入方式、兼容版本、可扩展性、同步时效、"
                           "传输容错、数据清洗", "1.4.11、1.8.6"],
            ["第 79～82 条", "移动端：生产执行、仓储物流、质量管理、协同决策",
             "1.2.1、1.4.12"],
            ["第 83 条", "技术总体要求与五项设计原则", "1.3.1"],
            ["第 84～89 条", "性能要求：可用性、响应时间、接口性能、并发容量、"
                           "数据同步与批处理、业务时效", "1.2.4、1.5"],
            ["第 90、91 条", "项目团队与交付物", "1.6.1、1.6.2"],
            ["第 92～94 条", "功能、性能与文档验收标准", "1.6.3"],
            ["第 95 条", "分层分系统培训", "1.6.4"],
            ["第 96～98 条", "售后服务、质保期与服务内容", "1.6.5"],
            ["第 99、100 条", "服务期限、服务地点、质量要求与开发进度", "1.6.6"],
        ],
        [2.0, 5.6, 2.4],
        ["c", "l", "c"])),
]