从流程日志找研发审批的等待点

这个场景能帮你做什么

工程变更或物料审批慢，可能卡在等待、返工或实际处理。WorkBuddy 可以利用已导出的事件日志整理路径、耗时与偏差，为流程负责人提供证据。

开始前需要准备什么

提供流程日志，至少有案例编号、活动、开始和结束时间；可补处理人、部门、状态。另提供标准流程、时区、工作日历、事件含义及统计范围。

具体怎么做

第一步：检查日志可用性

按案例核对事件、时间、时区和顺序，列缺时间、重复、负时长、未关闭案例。开始与结束含义不明时先确认。

第二步：区分处理与等待

按已确认事件定义计算活动处理时长和节点间等待。自然时长与工作时长分开，跨夜或假日不能自动算人员低效。

第三步：比较路径与例外

整理常见路径、退回、重复和绕行，对照标准流程。偏离可能有合理例外，需保留条件，不自动认定违规。

第四步：提出核实与改进问题

按证据列高等待节点、案例分布与可能原因，关联缺资料、资源或规则等待核事项。不能用平均耗时直接评价个人。

用一条串行案例区分处理与等待

以下是教学日志，均为同一天、同一时区 UTC+8；已确认 start_time 表示节点开始处理，end_time 表示节点结束处理，三个节点串行且没有退回。这里先算自然时长，不推定整段时间都在持续人工操作。

case_id	activity	start_time	end_time
示例 E-01	资料检查	10 月 14 日 09:00	10 月 14 日 09:20
示例 E-01	技术审批	10 月 14 日 10:00	10 月 14 日 10:30
示例 E-01	归档	10 月 14 日 11:00	10 月 14 日 11:10

对同一案例按实际串行顺序处理：活动处理区间＝本节点 end_time－start_time，因此三段分别为 20、30、10 分钟，合计 60 分钟。节点间等待＝下一节点 start_time－本节点 end_time，分别为 40、30 分钟，合计 70 分钟。本例从首节点开始到末节点结束共 130 分钟＝60＋70。由于没有案例提交时间，不能计算首节点开始前的等待；没有更细事件，也不能把处理区间当作净人工工时。

输出可以写：“E-01 从资料检查结束到技术审批开始等待 40 分钟，是本例最长节点间等待；原因尚需核实。”不能直接写“审批人拖延 40 分钟”。工作时长须另提供班次、午休和节假日日历，并只累计相应区间与工作窗口的交集；没有日历时只报告自然时长。

可以直接交给 WorkBuddy 的完整要求

分析附件导出流程日志，先检查案例ID、活动、时间、时区、状态及未关闭案例。
按已确认定义分别计算处理/等待和自然/工作时长，保留公式与异常。
整理路径变体、退回和标准流程偏差，给案例证据及待核解释，不把偏差直接定违规、不用耗时给人员排名。
输出等待点和核实清单，不宣称接入实时流程挖掘平台。

完成后会得到什么

一份带案例证据的节点耗时与路径表，以及流程负责人需要核实的等待原因。

结果应该怎么检查

手工还原几条案例，复算关键时长，核对假日、并行节点和未结案例是否恰当处理。检查均值是否掩盖不同路径。

遇到这些情况怎么处理

日志只有提交时间时不能推断实际处理时长。未关闭案例单列已等待时间，不混入已结耗时。退回重开时保留每次活动实例和轮次，先按实际顺序分别计算，不把同名节点覆盖合并。并行分支不能按日志行顺序相减；应按已确认的依赖关系计算分支等待，汇合节点的就绪时点采用其必需前置完成时点。若企业规则尚未明确，就单列这些案例，不套用串行公式。

哪些必须人工决定

流程负责人确认事件含义、例外和改进，相关部门核实原因。AI 计算与归纳，不自动归责或改变审批权限。