从质量台账到分析应用：制作、发布与月度维护

这份应用的使用目标可以这样描述：“给质量周会使用，分析八月份已完成检验的装配批次，查看主要缺陷、涉及产品和需要回查的批次；能够按产品筛选，并打开对应台账记录。”质量负责人据此选择优先讨论的问题，班组长据此找到本班需要核实的记录。用途具体以后，页面应展示什么、完成后怎样检查就有了依据。

接下来明确统计对象。一行如果代表一次检验，同一批次复检两次就会出现多行；按记录数统计缺陷与按批次数统计不合格，回答的是不同问题。这里应约定复检怎样计数、未完成检验是否进入统计，以及空结果表示待录入还是没有缺陷。暂时无法解释的记录可以单独列为待核实，避免把未知情况混入比例。

按照已经确定的范围建立资料库，加入当前有效的检验标准和一个完整月份的台账。CSV 或 Excel 都可以使用。表格中的批次编号、产品编号、检验日期、结果和数量应有各自的字段，另附说明解释单位与状态。合并单元格或仅用颜色表示结果，会使一个批次到底发生了什么难以辨认。

如果标准、检验结果和异常记录分散在不同表中，相同批次和产品应使用一致编号。例如同一产品在两份表里有不同简称，用名称连接就可能漏掉记录；编号能够减少这种歧义。上传前抽查几条熟悉记录，上传后打开检查表头和内容。需要数字员工检索标准原文时，再查看索引是否完成。

把材料交给源宜后，可以先在对话中要求它说明读到了哪些日期、哪些字段，以及准备怎样计算不合格率。对本例而言，方案应回答两件事：页面如何从缺陷分布引导到具体批次，汇总如何处理复检、未完成检验和缺失结果。这样，制作前讨论的是业务含义，页面生成后才有明确的核对对象。

资料不完整时，应改变问题的回答范围。只有检验结果、没有调查记录，可以列出主要缺陷和待回查批次，但不能认定根因；缺少受检数量时，可以比较缺陷记录的分布，却不能据此计算产品不合格率。把这些差别写入页面说明，用户才能判断一张图支持哪种讨论，还缺什么资料才能继续。

生成后打开预览，先选择一个熟悉批次，把页面中的产品、日期、数量和结果与台账逐项对照。再筛选到该产品，查看明细中是否只有应当包含的记录，数量和比例是否使用同一批记录。最后清除筛选，回到整月范围。这个顺序能把单条记录错误、筛选错误与计算错误分开，修改时也更容易描述问题。

比例还应选一个小范围手工算一遍。例如复检记录可以保留在明细中，批次总数是否只计一次则应按前面约定执行。若结果不符，可以在对话中指出“这个批次的复检被重复计入总数”，并附对应记录，再查看调整后的页面。反馈指向具体记录和规则，后续修改才有可判断的结果。

预览符合约定后，通过产物卡的“存入资料库”保存到对应主题。对于按月分析，一份已经核对的 CSV 或 Excel 能明确保留当月采用的数据范围；在“数据源管理”中选择对应文件，并使用“八月装配检验记录”等名称，后续就能辨认绑定了哪个月份、哪批记录。来源名称还应与页面的日期说明一致。

如果业务资料保存在 PostgreSQL 数据库中，并希望按约定范围查询，可以由负责数据的同事配置经过授权的只读连接。只读意味着这里查询数据，不修改生产记录；可访问的表、字段和时间范围仍应围绕当前分析限定。连接密码保留在当前设备，换设备查询时需要重新配置，不应把密码放进对话、资料或页面说明。文件与数据库的选择取决于数据怎样交付和维护，不影响前面已经约定的业务定义。

应用保存后，请一位有访问权限的同事从资料库打开团队版本。检查的不只是能否打开，还包括标题、统计月份和一条熟悉记录是否与交接说明一致。如果同事看到的是另一个月份，即使制作设备上的预览正确，这次周会仍可能引用不同范围的数字。

下图借用制造案例说明查看位置：这是源宜 0.7.4 中真实生成的应用，使用制造示例数据，并非本文质量台账的结果。顶部“已发布”和数据源数量说明资料库中的应用状态；下方的日期、指标和明细说明页面实际展示的范围。两处信息应一起看，数据源已经刷新不能单独证明页面数字已经更新。

后续更改页面，需要回到创建该应用的设备完成调整，核对后执行“发布更新”。若这次修改了复检计数，交接说明应指出哪些历史比较受影响，以及从哪次会议开始采用新方法。同事知道变化原因后，才能解释新旧版本的差异。

到了下个月，先把新记录的日期、字段和数量与原有资料对照。数据源刷新用于检查和取得绑定源的最新内容；页面是否随之重算，取决于应用如何使用这些内容。生成时把数据保存在 HTML 网页中的应用，仍会保留那次生成时的数字，刷新绑定源并不会自动替换它们。

对于这类固定数据页面，要用新资料重新生成或调整应用，抽查新月份的批次和对应汇总，再发布更新。若刷新失败，应查看提示和数据时间，暂时明确说明当前仍使用上次记录。每次会议前由一位维护人完成这项检查，比只看刷新状态更能说明团队手中的分析是否已经覆盖本月业务。