「AI 低代码一分钟」系列 第 07 篇|阅读约 7 分钟
摘要:8D 这套方法本身没有歧义,企业掉链子的地方在传递:三封邮件之后,只有各自收件箱知道谁在等什么。本文把 D3 到 D8 映射成一条带证据门禁的流程,给出节点时限与升级规则、关单必须校验的证据项,以及能支撑重复问题比对的台账字段。
一、卡在邮件里的不只是格式问题
8D 的步骤是公开的:临时对策、原因分析、永久对策、验证、预防再发。企业在执行时掉链子的地方在传递。
质量部发出邮件,工艺部回了一版原因分析,生产部说这条对策在他们线上做不到,采购部要不要换供应商没人提起。三封邮件之后,谁在等什么、哪一步已经过了,只有各自收件箱知道。
工程变更是同一个毛病。改图纸、改库存、通知供应商各管一段,卡在哪个部门只能一个个去问。
还有两笔更贵的账:整改落没落实,关单时拿不出证据;问题重复出现时查不到上一次的原因和对策。
二、一条流程上每个节点要收什么
| 节点 | 谁填 | 必须提交 | 不提交会怎样 |
|---|---|---|---|
| 客诉受理 | 质量 | 问题描述、影响范围、临时对策 | 单子进不了分析环节 |
| 原因分析 | 工艺或生产 | 原因和判定依据 | 后续对策没有根据 |
| 对策制定 | 责任部门 | 对策、责任人、完成时间 | 无法生成跟踪任务 |
| 对策验证 | 质量 | 验证结果和证据 | 关单被系统挡住 |
| 关单归档 | 质量负责人 | 确认关闭 | 自动进台账 |
关键在每个节点除了点同意,还要填原因、对策、验证结果。点同意只需要一次鼠标,填证据才会让人真的去做这件事。
三、把节点映射成带门禁的状态流转
G 这个门禁是整条流程的落点。关单动作在服务端校验:验证结果、证据附件、验证人三者缺一不可,前端点不动不算,接口直接拒绝。
四、时限和升级要写进流程
每个节点设时限,超时提醒、再超时升级。提醒发给经手人,升级发给他的上级。没有时限的流程,节点会一直停在别人手上,而你只能去问。
时限的值按节点性质定。临时对策当天要有,原因分析按批次复杂度给几天,验证环节必须等实际生产数据出来才算完成,这一段的时限不要压得太短,否则一线会用一句"已完成"把节点推过去。
升级之后节点归谁,也要提前定。上级接手还是仍由原经手人处理,系统里要留字段记下这件事,不然复盘时找不到人。提醒的收件人同样要落到具体的人,发到部门公共邮箱和没发差不多。
CREATE TABLE d8_node (
step_code VARCHAR(8) NOT NULL, -- D1..D8
case_no VARCHAR(32) NOT NULL,
owner_user VARCHAR(64) NOT NULL, -- 落到人名,不填部门公共账号
due_at DATETIME NOT NULL,
escalated_at DATETIME, -- 升级时间
escalated_to VARCHAR(64), -- 升级后由谁处理
status VARCHAR(16) NOT NULL, -- PENDING / DONE / OVERDUE
PRIMARY KEY (case_no, step_code)
);
CREATE TABLE d8_evidence (
evidence_id BIGINT PRIMARY KEY,
case_no VARCHAR(32) NOT NULL,
step_code VARCHAR(8) NOT NULL,
kind VARCHAR(16) NOT NULL, -- PHOTO / DATA / DOC
object_key VARCHAR(256) NOT NULL,
verified_by VARCHAR(64),
verified_at DATETIME
);
escalated_to 这一列在复盘时很值钱。超时升级后如果没人接手,工单在系统里仍然挂着原责任人,这类"升级即遗忘"的情况只能靠这一列查出来。
五、台账里要存住哪几项
| 台账项 | 留着做什么 |
|---|---|
| 问题描述与判定等级 | 和新进来的问题做比对 |
| 责任部门、产品批次 | 同一批次反复出问题时能圈出来 |
| 原因分类 | 按类别统计才知道问题集中在哪 |
| 对策与验证证据 | 关单的依据,也是审核时的材料 |
| 完成时间与超期记录 | 看流程本身慢在哪 |
关单后自动进台账这一步,很多企业只存了一个"已关闭"的状态。台账里没有原因分类和批次,第二年来同样的客诉,还是查不到上次是怎么处理的,只能从头分析一遍。
-- 新客诉进来时先做一次相似检索,比翻邮件快
SELECT case_no, root_cause_type, countermeasure, verified_at
FROM d8_ledger
WHERE product_batch = :batch
OR root_cause_type = :cause_type
ORDER BY verified_at DESC
FETCH FIRST 10 ROWS ONLY;
六、同样的做法用在项目管理上
我们在一家国有整车集团的项目管理上用过这套方法。从需求、预算、立项到采购和验收,一条线串起来,节点超期自动生成任务。
超期自动生成任务这一步很重要。它把"有人去催"变成"系统去催",项目管理岗从打电话问进度里解放出来,看的是哪几个节点一直超期。
七、要不要串成一条流程
四条判断:参与部门三个以上;周期长;节点要填数据;结束要成台账。占两条就值得串。
上线检查清单
- 关单接口校验验证结果、证据、验证人三者,缺项直接拒绝
- 每个节点配置时限,超时提醒与升级的收件人写到人名
- 升级后的处理人落库,可查询"升级即遗忘"的挂单
- 临时对策当日必填,验证节点允许等待生产数据的时间窗
- 台账含原因分类与产品批次,可按批次或类别检索历史记录
- 证据附件走对象存储,附件删除留痕,不影响归档完整性
- 上线前拿最近三个月关闭的两份 8D 单试录,检查字段是否够填
说明:本文作者供职于得帆智能,文中提到的 Dolphin Code 等产品为本公司产品。内容根据项目实施经验整理,仅作行业交流,不构成采购建议;文中表结构与 SQL 均为示意。
本文阐述如何将传统邮件驱动的8D报告迁移至结构化工作流,重点实现节点证据门禁(验证结果、附件、验证人三者缺一不可)、时限控制与自动升级机制,并定义支撑问题复盘的台账字段(如原因分类、产品批次)。方案基于低代码工作流引擎构建,适用于质量管理与项目管理场景,强调状态流转可控、过程可溯、数据可比。
14

被折叠的 条评论
为什么被折叠?



