尧图网页设计 
简介这份资料是埃森哲企业架构流程优化方法论培训课件共110页PPT面向企业流程管理者、流程优化项目成员、咨询顾问及管理类学习者用于系统理解从职能管理向流程管理转型的路径与方法。内容围绕业务流程优化BPR展开涵盖流程与流程体系的基本概念、分级架构一级流程地图到四级流程图、职能管理与流程管理的差异对比、价值管理与精益思想在流程优化中的应用、标准化与需求源头管理等主题并介绍了IDEF0、ARIS等主流流程建模标准与常用模型类型可作为流程梳理与优化的方法论参考。资源包为1个pptx文件约4.91MB结构完整、图示丰富便于直接用于内部培训或自学研读。目前已有54人学习下载。读者可从中获取流程优化的原则、设计方法、关键思考问题及完整培训框架用于指导企业流程再造与标准化落地实践。1. 一份 110 页方法论 PPT 落地时的三个断点手上有一份 110 页的企业架构流程优化方法论 PPT是很常见的场景ADM 循环图、四域视图、流程分层、成熟度雷达外加一张采购到付款的端到端示意。框架完整合上之后却没人说得清动自己公司的采购流程该从哪一步开始。断点通常有三个现状只来自访谈纪要“审批太慢”拿不出可复现的数字TO-BE 画在 Visio 里落到工作流配置只剩“加一个审批节点”上线后没有验证口径成败靠业务方“感觉快了点”。下面把埃森哲这类方法论中最常被引用的几块内容拆成一条可执行链路用分层把 AS-IS 变成可采集的对象用系统事件日志重建流程并量化瓶颈用 ESIA 做 TO-BE 改造并把审批规则写进代码最后用一致性检查和分位数指标验收。面向企业架构师、流程管理岗以及正在做采购与供应链数字化的开发和产品。2. 企业架构四域视图与流程分层把 AS-IS 变成可采集的对象2.1 TOGAF 四域和流程 L0-L5 的对齐关系企业架构的方法论里TOGAF ADM 的 B、C、D 三个阶段分别产出业务架构、信息系统架构、技术架构而流程管理侧习惯把流程拆成 L0 到 L5 六个层级。这两套语言如果不先对齐会出现一个典型症状业务架构图上写着“采购到付款”工作流配置里却只有十几个审批节点中间三层是空的。对齐的核心判据是“这一层的对象能不能被系统采到”。L0 到 L2 靠访谈、制度文件和流程域清单就能说清属于业务架构范畴L3 以下必须从系统里取数因为人描述的活动顺序和数据里跑出来的活动顺序经常不一致。流程层级典型粒度对应 EA 视图采集方式常见载体L0 价值链采购到付款业务架构年度访谈战略地图L1 流程域寻源、订单、供应商管理业务架构半年访谈流程域清单L2 流程组采购申请与审批业务架构季度访谈 文档BPMN 高阶图L3 流程采购申请审批应用架构月度取数工作流配置L4 活动预算校验、三单匹配应用架构按需取数系统操作日志L5 任务字段录入、附件上传技术架构实时埋点数据库事件表我一般会把这张表贴在项目启动会的墙上因为后面所有争论——比如“这个流程到底算 L2 还是 L3”——本质都是“它能不能被采到数”的争论而不是术语争论。2.2 流程清单模板的六个必填字段流程清单是后面所有分析的索引缺字段的清单等于没有。字段不在于多而在于每个字段都能被后续步骤消费。字段说明来源缺失后果流程编号L 层级 序号如 L3-P2P-04手工维护无法与日志做映射触发事件什么动作启动流程制度文件找不到流程起点输入 / 输出物单据、数据对象访谈 系统无法定义 case 主键责任岗单一责任人不是部门组织架构瓶颈归因失效支撑系统承载该流程的应用应用架构盘点找不到日志表关键指标周期、返工率、直通率业务 历史数据改造成效无法验证其中“支撑系统”这一栏最容易被敷衍成“ERP”。实际做的时候要精确到模块和表比如采购申请走 SRM 的 PR 模块、收货走 WMS 的入库单、发票校验走财务共享系统的三单匹配引擎。没有这一层精确度第 3 章的取数就无从下手。2.3 用 BPMN 2.0 描述一条采购到付款主流程流程清单解决“有哪些流程”BPMN 解决“流程长什么样”。不要用图片用可解析的 XML这样后续才能和日志做对比。!-- 采购到付款 L2 流程的精简 BPMN 片段 -- process idP2P name采购到付款 startEvent idstart name需求提出/ !-- 采购申请人工任务落在 SRM 系统 -- userTask idpr name提交采购申请/ !-- 排他网关按金额分流规则版本需记录 -- exclusiveGateway idgw_amount name金额判定/ userTask idapprove_mgr name部门经理审批/ userTask idapprove_cpo name采购负责人审批/ userTask idpo name创建采购订单/ userTask idgr name收货确认/ !-- 三单匹配作为自动任务不对应人工节点 -- serviceTask idmatch name三单匹配/ endEvent idend name付款完成/ sequenceFlow idf1 sourceRefstart targetRefpr/ sequenceFlow idf2 sourceRefpr targetRefgw_amount/ sequenceFlow idf3 sourceRefgw_amount targetRefapprove_mgr conditionExpression${amount lt; 50000}/conditionExpression /sequenceFlow sequenceFlow idf4 sourceRefgw_amount targetRefapprove_cpo conditionExpression${amount gt; 50000}/conditionExpression /sequenceFlow sequenceFlow idf5 sourceRefapprove_mgr targetRefpo/ sequenceFlow idf6 sourceRefapprove_cpo targetRefpo/ sequenceFlow idf7 sourceRefpo targetRefgr/ sequenceFlow idf8 sourceRefgr targetRefmatch/ sequenceFlow idf9 sourceRefmatch targetRefend/ /process几个容易写错的地方。exclusiveGateway的条件表达式里的金额阈值必须和第 4 章规则引擎里的阈值是同一个常量来源否则模型和实现对不上serviceTask表示自动节点它对应日志里“系统自动触发”的那类事件画成userTask会导致后面一致性检查时凭空多出一批“没人处理”的缺勤节点网关分流的条件顺序在 BPMN 里是从上往下匹配写反了会把大额单据直接放到经理审批。流程清单加上 BPMNAS-IS 的静态部分就齐了。但它描述的仍然是“应该怎么走”真实执行里有多少旁路、多少返工、卡在哪个节点多久只能从日志里读。3. 用流程挖掘把 AS-IS 从访谈描述变成可量化事件日志3.1 从业务系统抽取事件日志的三个必备列流程挖掘的输入是一张事件日志表最小结构是三列case_id、activity、timestamp。听起来简单实际取数时踩坑最多。-- 从采购单据状态变更表抽取事件日志 SELECT d.doc_no AS case_id, -- 流程实例主键一张采购申请或采购订单 s.status_code AS activity, -- 用状态码不用中文名便于跨版本对齐 s.change_time AS timestamp, -- 必须精确到秒不能只存日期 s.operator_id AS resource, -- 用于按岗位下钻瓶颈 s.operator_dept AS dept, d.supplier_code AS supplier, d.amount AS amount FROM doc_status_log s JOIN purchase_doc d ON d.doc_id s.doc_id WHERE s.change_time 2024-01-01 AND s.change_time 2024-07-01 AND d.doc_type PR -- 只取采购申请避免混入订单和发票 ORDER BY case_id, timestamp;case_id 的选择决定了分析粒度。按采购申请编号聚合得到的是“申请到付款”的全周期按采购订单编号聚合周期会短一截因为寻源和申请阶段被切掉了。这两个口径不能混用报告里必须写清楚。activity 用状态码而不是中文名是因为系统改版后中文名会变状态码一般不动跨年份对比才能成立。timestamp 如果系统只存到天需要从审计表里补时分秒否则所有等待时长都会退化成 0 或 24 小时的整数倍瓶颈分析直接失效。3.2 用 pm4py 跑通从日志到流程模型的最小命令拿到 CSV 之后用 pm4py 做三件事发现流程、统计变体、看节点停留时间。import pandas as pd import pm4py # 1) 读取上一步导出的日志 df pd.read_csv(p2p_event_log.csv, parse_dates[timestamp]) # 2) 统一列名到 pm4py 约定 df pm4py.format_dataframe( df, case_idcase_id, activity_keyactivity, timestamp_keytimestamp, ) # 3) 发现直接跟随图DFG只统计活动之间的前后关系 dfg, start_activities, end_activities pm4py.discover_dfg(df) print(起始活动分布:, start_activities) # 4) 变体排行定位旁路与返工路径 variants pm4py.get_variants(df) for path, count in sorted(variants.items(), keylambda x: -x[1])[:10]: print(count, -, | .join(path)) # 5) 节点停留时间找出等待最久的环节 from pm4py.statistics.sojourn_time.log import get as soj_time st soj_time.apply(df, parameters{soj_time.Parameters.AGGREGATION_MEASURE: median}) for act, sec in sorted(st.items(), keylambda x: -x[1])[:5]: print(f{act}: 中位停留 {sec/3600:.1f} 小时)format_dataframe会把时间列统一成 datetime 并补齐 pm4py 需要的内部列如果不做这一步后面所有统计都会报类型错误。discover_dfg统计的是直接跟随关系它不识别并发块——如果日志里两条活动的时间戳交错DFG 会把两个方向的边都画出来这时候要看变体而不是看边。变体排行是最有信息量的一步如果某条带“退回重提”的变体占了 30%说明返工是常态而不是例外改造重点就不该放在砍审批节点上。3.3 决定诊断结论的五个参数参数常用取值作用调大或调小的后果变体覆盖率覆盖 80% 实例的最小变体集合划定 AS-IS 模型范围取值过高会把长尾噪声当主流程并发判定窗口两活动时间差 同活动中位处理时长的 20%判断是否并发窗口过大误判并发窗口过小把并发当顺序返工识别规则同一 case 内同一活动重复出现统计返工次数只按相邻重复算会漏掉间隔型返工时长分位P50 / P90 / P95定位瓶颈只看均值会被少数超长实例掩盖下钻维度组织 / 岗位 / 供应商 / 品类归因维度过细导致单格样本不足结论不可信一个实操建议诊断报告里同时放 P50 和 P95 两条曲线。P50 反映典型体验P95 反映最差的那 5% 单据而后者往往才是业务方天天在抱怨的对象。很多流程优化项目把均值压下去了P95 没动业务感受自然也不动。4. 采购流程优化的 TO-BE 改造ESIA 四步法与审批规则引擎4.1 ESIA 四个动作在采购场景里的落点TO-BE 设计最怕变成“重画一遍 BPMN 图”。ESIA 的价值在于每个动作都要挂上一个可测指标否则就是 PPT 优化。手法采购场景例子判据指标主要风险清除 Eliminate去掉重复审批、纸质回签、无预算校验的补单审批节点数、纸质单据占比合规要求被一并清掉简化 Simplify三级审批压成两级申请表单字段从 42 减到 18单均填写耗时、退回率字段删过头导致后续对账缺数据整合 Integrate供应商主数据统一到 MDM收货与发票三单匹配自动化主数据重复率、匹配自动化率主数据 Owner 不明确整合停在方案自动化 Automate阈值内自动放行、发票 OCR 加三单匹配直通率、人工干预次数阈值定得过松异常单据被自动放过四个动作的优先级不是固定的。我一般先做“清除”因为清掉一个环节的成本远低于自动化一个环节只有清不掉的才考虑简化简化不掉的才整合最后才是自动化。反过来做等于给一个本该消失的流程买了套自动化工具。4.2 把审批路由从人治搬进规则引擎采购流程优化里最容易被反复讨论的是审批链因为它直接决定单据走多久。把它从工作流配置的硬编码搬进一个显式的规则函数改造成本会低很多。from dataclasses import dataclass dataclass class PurchaseRequest: amount: float # 含税金额单位元 category: str # 采购品类如 IT硬件、MRO supplier_level: str # 供应商分级 A/B/C budget_remain: float # 该成本中心剩余预算 is_capex: bool # 是否资本性支出 # 审批矩阵金额区间 - 基础审批链区间左闭右开 RULES [ (0, 5_000, [BUYER]), (5_000, 50_000, [BUYER, DEPT_MGR]), (50_000, 300_000, [BUYER, DEPT_MGR, CPO]), (300_000, float(inf), [BUYER, DEPT_MGR, CPO, CFO]), ] def route(req: PurchaseRequest) - list[str]: # 1) 命中基础审批链 chain next(c for lo, hi, c in RULES if lo req.amount hi) # 2) 预算不足或 C 级供应商强制加签财务 if req.budget_remain req.amount or req.supplier_level C: chain chain [FINANCE] # 3) 资本性支出必须过投资委员会 if req.is_capex: chain chain [IC] return chain print(route(PurchaseRequest(120_000, IT硬件, B, 500_000, False))) # 输出[BUYER, DEPT_MGR, CPO]这段代码有三个刻意的设计。审批链用列表而不是字符串拼接是为了后续能统计“每个审批人出现频次”反过来评估组织层级的负担加签条件写成独立判断而不是塞进 RULES 表因为金额是连续变量、加签是离散条件混在一起以后没法做规则版本对比函数保持纯计算、不查数据库这样可以直接拿历史单据批量回放用离线方式估出改造后的平均审批节点数。4.3 阈值定标与灰度回滚规则写出来只是开始阈值定在哪里才是真问题。常用的定标依据是历史数据分位数而不是拍脑袋。参数初始建议值定标依据回滚触发条件自动放行金额上限5 万元历史单据金额 P70连续两周异常放行率 2%三单匹配容差金额 ±1%数量 ±0供应商发票质量分布匹配失败率 10%预算加签触发线预算占用 90%超预算单据占比加签量翻倍且无异常单据灰度范围按事业部或品类分批组织复杂度单个批次直通率下降超 5 个百分点灰度这一步别省。把新规则先在一两个品类上跑一个月用同一套日志口径对比改造前后的变体分布比上线后开复盘会有效得多。回滚条件必须提前写死在监控里而不是出事后再开会决定要不要退。5. 用一致性检查验证改造效果三个可复现的度量技巧5.1 一致性检查TO-BE 模型和真实日志差多少改造上线后把第 2 章画的 TO-BE 模型和第 3 章的日志做一次对齐看模型和现实差多远。import pm4py from pm4py.algo.conformance.tokenreplay import algorithm as token_replay # 用改造后的日志重新发现 Petri 网并做令牌重放 net, im, fm pm4py.discover_petri_net_inductive(df_new) result token_replay.apply(df_new, net, im, fm) # 平均拟合度越接近 1 说明模型越贴合真实执行 fitness sum(r[trace_fitness] for r in result) / len(result) print(平均拟合度:, round(fitness, 3)) # 统计未被模型覆盖的活动通常是旁路和手工补录 unfit {} for r in result: for t in r.get(unfit_transitions, []): unfit[t] unfit.get(t, 0) 1 print(sorted(unfit.items(), keylambda x: -x[1])[:5])拟合度高于 0.95说明 TO-BE 基本落进了系统低于 0.8通常是两种情况之一规则没同步到工作流配置或者存在大量线下补录。unfit_transitions的排行比拟合度本身更有用它直接指出哪些活动是模型里没有、但现实里在跑的。5.2 用 P95 而不是均值衡量流程周期指标口径采集方式参考阈值采购周期 P95申请创建到订单下达日志时间差较基线下降 20%直通率无需人工干预的实例占比自动节点覆盖率逐月递增返工率含重复活动的实例占比变体分析较基线减半审批节点均值单实例平均审批人次规则引擎回放不超过 2.5四个指标里返工率最能反映改造是否触及根因。审批节点砍了但返工率没降往往说明退回的原因是资料不全或预算不清而不是审批层级太多。5.3 一个具体技巧把返工率算成带重复前缀的变体占比最后留一个我常用的口径。单纯数“同一活动出现几次”会把正常的并行处理也算成返工更稳的做法是看变体序列里是否存在“活动 A 之后再次出现活动 A 的前驱”——也就是回退边。def rework_ratio(variants): variants: {活动序列元组: 实例数}返回带回退边的实例占比 total sum(variants.values()) rework 0 for path, cnt in variants.items(): seen {} for i, act in enumerate(path): if act in seen and seen[act] i - 1: # 非相邻重复才算回退 rework cnt break seen[act] i return round(rework / total, 3)这个比率按月出图再和审批规则版本号对齐到同一张时间轴上哪一次阈值调整真正带来了返工下降一眼就能定位到那次变更。本文还有配套的精品资源点击获取 企业架构流程优化：从流程挖掘到规则引擎与一致性检查
简介这份资料是埃森哲企业架构流程优化方法论培训课件共110页PPT面向企业流程管理者、流程优化项目成员、咨询顾问及管理类学习者用于系统理解从职能管理向流程管理转型的路径与方法。内容围绕业务流程优化BPR展开涵盖流程与流程体系的基本概念、分级架构一级流程地图到四级流程图、职能管理与流程管理的差异对比、价值管理与精益思想在流程优化中的应用、标准化与需求源头管理等主题并介绍了IDEF0、ARIS等主流流程建模标准与常用模型类型可作为流程梳理与优化的方法论参考。资源包为1个pptx文件约4.91MB结构完整、图示丰富便于直接用于内部培训或自学研读。目前已有54人学习下载。读者可从中获取流程优化的原则、设计方法、关键思考问题及完整培训框架用于指导企业流程再造与标准化落地实践。1. 一份 110 页方法论 PPT 落地时的三个断点手上有一份 110 页的企业架构流程优化方法论 PPT是很常见的场景ADM 循环图、四域视图、流程分层、成熟度雷达外加一张采购到付款的端到端示意。框架完整合上之后却没人说得清动自己公司的采购流程该从哪一步开始。断点通常有三个现状只来自访谈纪要“审批太慢”拿不出可复现的数字TO-BE 画在 Visio 里落到工作流配置只剩“加一个审批节点”上线后没有验证口径成败靠业务方“感觉快了点”。下面把埃森哲这类方法论中最常被引用的几块内容拆成一条可执行链路用分层把 AS-IS 变成可采集的对象用系统事件日志重建流程并量化瓶颈用 ESIA 做 TO-BE 改造并把审批规则写进代码最后用一致性检查和分位数指标验收。面向企业架构师、流程管理岗以及正在做采购与供应链数字化的开发和产品。2. 企业架构四域视图与流程分层把 AS-IS 变成可采集的对象2.1 TOGAF 四域和流程 L0-L5 的对齐关系企业架构的方法论里TOGAF ADM 的 B、C、D 三个阶段分别产出业务架构、信息系统架构、技术架构而流程管理侧习惯把流程拆成 L0 到 L5 六个层级。这两套语言如果不先对齐会出现一个典型症状业务架构图上写着“采购到付款”工作流配置里却只有十几个审批节点中间三层是空的。对齐的核心判据是“这一层的对象能不能被系统采到”。L0 到 L2 靠访谈、制度文件和流程域清单就能说清属于业务架构范畴L3 以下必须从系统里取数因为人描述的活动顺序和数据里跑出来的活动顺序经常不一致。流程层级典型粒度对应 EA 视图采集方式常见载体L0 价值链采购到付款业务架构年度访谈战略地图L1 流程域寻源、订单、供应商管理业务架构半年访谈流程域清单L2 流程组采购申请与审批业务架构季度访谈 文档BPMN 高阶图L3 流程采购申请审批应用架构月度取数工作流配置L4 活动预算校验、三单匹配应用架构按需取数系统操作日志L5 任务字段录入、附件上传技术架构实时埋点数据库事件表我一般会把这张表贴在项目启动会的墙上因为后面所有争论——比如“这个流程到底算 L2 还是 L3”——本质都是“它能不能被采到数”的争论而不是术语争论。2.2 流程清单模板的六个必填字段流程清单是后面所有分析的索引缺字段的清单等于没有。字段不在于多而在于每个字段都能被后续步骤消费。字段说明来源缺失后果流程编号L 层级 序号如 L3-P2P-04手工维护无法与日志做映射触发事件什么动作启动流程制度文件找不到流程起点输入 / 输出物单据、数据对象访谈 系统无法定义 case 主键责任岗单一责任人不是部门组织架构瓶颈归因失效支撑系统承载该流程的应用应用架构盘点找不到日志表关键指标周期、返工率、直通率业务 历史数据改造成效无法验证其中“支撑系统”这一栏最容易被敷衍成“ERP”。实际做的时候要精确到模块和表比如采购申请走 SRM 的 PR 模块、收货走 WMS 的入库单、发票校验走财务共享系统的三单匹配引擎。没有这一层精确度第 3 章的取数就无从下手。2.3 用 BPMN 2.0 描述一条采购到付款主流程流程清单解决“有哪些流程”BPMN 解决“流程长什么样”。不要用图片用可解析的 XML这样后续才能和日志做对比。!-- 采购到付款 L2 流程的精简 BPMN 片段 -- process idP2P name采购到付款 startEvent idstart name需求提出/ !-- 采购申请人工任务落在 SRM 系统 -- userTask idpr name提交采购申请/ !-- 排他网关按金额分流规则版本需记录 -- exclusiveGateway idgw_amount name金额判定/ userTask idapprove_mgr name部门经理审批/ userTask idapprove_cpo name采购负责人审批/ userTask idpo name创建采购订单/ userTask idgr name收货确认/ !-- 三单匹配作为自动任务不对应人工节点 -- serviceTask idmatch name三单匹配/ endEvent idend name付款完成/ sequenceFlow idf1 sourceRefstart targetRefpr/ sequenceFlow idf2 sourceRefpr targetRefgw_amount/ sequenceFlow idf3 sourceRefgw_amount targetRefapprove_mgr conditionExpression${amount lt; 50000}/conditionExpression /sequenceFlow sequenceFlow idf4 sourceRefgw_amount targetRefapprove_cpo conditionExpression${amount gt; 50000}/conditionExpression /sequenceFlow sequenceFlow idf5 sourceRefapprove_mgr targetRefpo/ sequenceFlow idf6 sourceRefapprove_cpo targetRefpo/ sequenceFlow idf7 sourceRefpo targetRefgr/ sequenceFlow idf8 sourceRefgr targetRefmatch/ sequenceFlow idf9 sourceRefmatch targetRefend/ /process几个容易写错的地方。exclusiveGateway的条件表达式里的金额阈值必须和第 4 章规则引擎里的阈值是同一个常量来源否则模型和实现对不上serviceTask表示自动节点它对应日志里“系统自动触发”的那类事件画成userTask会导致后面一致性检查时凭空多出一批“没人处理”的缺勤节点网关分流的条件顺序在 BPMN 里是从上往下匹配写反了会把大额单据直接放到经理审批。流程清单加上 BPMNAS-IS 的静态部分就齐了。但它描述的仍然是“应该怎么走”真实执行里有多少旁路、多少返工、卡在哪个节点多久只能从日志里读。3. 用流程挖掘把 AS-IS 从访谈描述变成可量化事件日志3.1 从业务系统抽取事件日志的三个必备列流程挖掘的输入是一张事件日志表最小结构是三列case_id、activity、timestamp。听起来简单实际取数时踩坑最多。-- 从采购单据状态变更表抽取事件日志 SELECT d.doc_no AS case_id, -- 流程实例主键一张采购申请或采购订单 s.status_code AS activity, -- 用状态码不用中文名便于跨版本对齐 s.change_time AS timestamp, -- 必须精确到秒不能只存日期 s.operator_id AS resource, -- 用于按岗位下钻瓶颈 s.operator_dept AS dept, d.supplier_code AS supplier, d.amount AS amount FROM doc_status_log s JOIN purchase_doc d ON d.doc_id s.doc_id WHERE s.change_time 2024-01-01 AND s.change_time 2024-07-01 AND d.doc_type PR -- 只取采购申请避免混入订单和发票 ORDER BY case_id, timestamp;case_id 的选择决定了分析粒度。按采购申请编号聚合得到的是“申请到付款”的全周期按采购订单编号聚合周期会短一截因为寻源和申请阶段被切掉了。这两个口径不能混用报告里必须写清楚。activity 用状态码而不是中文名是因为系统改版后中文名会变状态码一般不动跨年份对比才能成立。timestamp 如果系统只存到天需要从审计表里补时分秒否则所有等待时长都会退化成 0 或 24 小时的整数倍瓶颈分析直接失效。3.2 用 pm4py 跑通从日志到流程模型的最小命令拿到 CSV 之后用 pm4py 做三件事发现流程、统计变体、看节点停留时间。import pandas as pd import pm4py # 1) 读取上一步导出的日志 df pd.read_csv(p2p_event_log.csv, parse_dates[timestamp]) # 2) 统一列名到 pm4py 约定 df pm4py.format_dataframe( df, case_idcase_id, activity_keyactivity, timestamp_keytimestamp, ) # 3) 发现直接跟随图DFG只统计活动之间的前后关系 dfg, start_activities, end_activities pm4py.discover_dfg(df) print(起始活动分布:, start_activities) # 4) 变体排行定位旁路与返工路径 variants pm4py.get_variants(df) for path, count in sorted(variants.items(), keylambda x: -x[1])[:10]: print(count, -, | .join(path)) # 5) 节点停留时间找出等待最久的环节 from pm4py.statistics.sojourn_time.log import get as soj_time st soj_time.apply(df, parameters{soj_time.Parameters.AGGREGATION_MEASURE: median}) for act, sec in sorted(st.items(), keylambda x: -x[1])[:5]: print(f{act}: 中位停留 {sec/3600:.1f} 小时)format_dataframe会把时间列统一成 datetime 并补齐 pm4py 需要的内部列如果不做这一步后面所有统计都会报类型错误。discover_dfg统计的是直接跟随关系它不识别并发块——如果日志里两条活动的时间戳交错DFG 会把两个方向的边都画出来这时候要看变体而不是看边。变体排行是最有信息量的一步如果某条带“退回重提”的变体占了 30%说明返工是常态而不是例外改造重点就不该放在砍审批节点上。3.3 决定诊断结论的五个参数参数常用取值作用调大或调小的后果变体覆盖率覆盖 80% 实例的最小变体集合划定 AS-IS 模型范围取值过高会把长尾噪声当主流程并发判定窗口两活动时间差 同活动中位处理时长的 20%判断是否并发窗口过大误判并发窗口过小把并发当顺序返工识别规则同一 case 内同一活动重复出现统计返工次数只按相邻重复算会漏掉间隔型返工时长分位P50 / P90 / P95定位瓶颈只看均值会被少数超长实例掩盖下钻维度组织 / 岗位 / 供应商 / 品类归因维度过细导致单格样本不足结论不可信一个实操建议诊断报告里同时放 P50 和 P95 两条曲线。P50 反映典型体验P95 反映最差的那 5% 单据而后者往往才是业务方天天在抱怨的对象。很多流程优化项目把均值压下去了P95 没动业务感受自然也不动。4. 采购流程优化的 TO-BE 改造ESIA 四步法与审批规则引擎4.1 ESIA 四个动作在采购场景里的落点TO-BE 设计最怕变成“重画一遍 BPMN 图”。ESIA 的价值在于每个动作都要挂上一个可测指标否则就是 PPT 优化。手法采购场景例子判据指标主要风险清除 Eliminate去掉重复审批、纸质回签、无预算校验的补单审批节点数、纸质单据占比合规要求被一并清掉简化 Simplify三级审批压成两级申请表单字段从 42 减到 18单均填写耗时、退回率字段删过头导致后续对账缺数据整合 Integrate供应商主数据统一到 MDM收货与发票三单匹配自动化主数据重复率、匹配自动化率主数据 Owner 不明确整合停在方案自动化 Automate阈值内自动放行、发票 OCR 加三单匹配直通率、人工干预次数阈值定得过松异常单据被自动放过四个动作的优先级不是固定的。我一般先做“清除”因为清掉一个环节的成本远低于自动化一个环节只有清不掉的才考虑简化简化不掉的才整合最后才是自动化。反过来做等于给一个本该消失的流程买了套自动化工具。4.2 把审批路由从人治搬进规则引擎采购流程优化里最容易被反复讨论的是审批链因为它直接决定单据走多久。把它从工作流配置的硬编码搬进一个显式的规则函数改造成本会低很多。from dataclasses import dataclass dataclass class PurchaseRequest: amount: float # 含税金额单位元 category: str # 采购品类如 IT硬件、MRO supplier_level: str # 供应商分级 A/B/C budget_remain: float # 该成本中心剩余预算 is_capex: bool # 是否资本性支出 # 审批矩阵金额区间 - 基础审批链区间左闭右开 RULES [ (0, 5_000, [BUYER]), (5_000, 50_000, [BUYER, DEPT_MGR]), (50_000, 300_000, [BUYER, DEPT_MGR, CPO]), (300_000, float(inf), [BUYER, DEPT_MGR, CPO, CFO]), ] def route(req: PurchaseRequest) - list[str]: # 1) 命中基础审批链 chain next(c for lo, hi, c in RULES if lo req.amount hi) # 2) 预算不足或 C 级供应商强制加签财务 if req.budget_remain req.amount or req.supplier_level C: chain chain [FINANCE] # 3) 资本性支出必须过投资委员会 if req.is_capex: chain chain [IC] return chain print(route(PurchaseRequest(120_000, IT硬件, B, 500_000, False))) # 输出[BUYER, DEPT_MGR, CPO]这段代码有三个刻意的设计。审批链用列表而不是字符串拼接是为了后续能统计“每个审批人出现频次”反过来评估组织层级的负担加签条件写成独立判断而不是塞进 RULES 表因为金额是连续变量、加签是离散条件混在一起以后没法做规则版本对比函数保持纯计算、不查数据库这样可以直接拿历史单据批量回放用离线方式估出改造后的平均审批节点数。4.3 阈值定标与灰度回滚规则写出来只是开始阈值定在哪里才是真问题。常用的定标依据是历史数据分位数而不是拍脑袋。参数初始建议值定标依据回滚触发条件自动放行金额上限5 万元历史单据金额 P70连续两周异常放行率 2%三单匹配容差金额 ±1%数量 ±0供应商发票质量分布匹配失败率 10%预算加签触发线预算占用 90%超预算单据占比加签量翻倍且无异常单据灰度范围按事业部或品类分批组织复杂度单个批次直通率下降超 5 个百分点灰度这一步别省。把新规则先在一两个品类上跑一个月用同一套日志口径对比改造前后的变体分布比上线后开复盘会有效得多。回滚条件必须提前写死在监控里而不是出事后再开会决定要不要退。5. 用一致性检查验证改造效果三个可复现的度量技巧5.1 一致性检查TO-BE 模型和真实日志差多少改造上线后把第 2 章画的 TO-BE 模型和第 3 章的日志做一次对齐看模型和现实差多远。import pm4py from pm4py.algo.conformance.tokenreplay import algorithm as token_replay # 用改造后的日志重新发现 Petri 网并做令牌重放 net, im, fm pm4py.discover_petri_net_inductive(df_new) result token_replay.apply(df_new, net, im, fm) # 平均拟合度越接近 1 说明模型越贴合真实执行 fitness sum(r[trace_fitness] for r in result) / len(result) print(平均拟合度:, round(fitness, 3)) # 统计未被模型覆盖的活动通常是旁路和手工补录 unfit {} for r in result: for t in r.get(unfit_transitions, []): unfit[t] unfit.get(t, 0) 1 print(sorted(unfit.items(), keylambda x: -x[1])[:5])拟合度高于 0.95说明 TO-BE 基本落进了系统低于 0.8通常是两种情况之一规则没同步到工作流配置或者存在大量线下补录。unfit_transitions的排行比拟合度本身更有用它直接指出哪些活动是模型里没有、但现实里在跑的。5.2 用 P95 而不是均值衡量流程周期指标口径采集方式参考阈值采购周期 P95申请创建到订单下达日志时间差较基线下降 20%直通率无需人工干预的实例占比自动节点覆盖率逐月递增返工率含重复活动的实例占比变体分析较基线减半审批节点均值单实例平均审批人次规则引擎回放不超过 2.5四个指标里返工率最能反映改造是否触及根因。审批节点砍了但返工率没降往往说明退回的原因是资料不全或预算不清而不是审批层级太多。5.3 一个具体技巧把返工率算成带重复前缀的变体占比最后留一个我常用的口径。单纯数“同一活动出现几次”会把正常的并行处理也算成返工更稳的做法是看变体序列里是否存在“活动 A 之后再次出现活动 A 的前驱”——也就是回退边。def rework_ratio(variants): variants: {活动序列元组: 实例数}返回带回退边的实例占比 total sum(variants.values()) rework 0 for path, cnt in variants.items(): seen {} for i, act in enumerate(path): if act in seen and seen[act] i - 1: # 非相邻重复才算回退 rework cnt break seen[act] i return round(rework / total, 3)这个比率按月出图再和审批规则版本号对齐到同一张时间轴上哪一次阈值调整真正带来了返工下降一眼就能定位到那次变更。本文还有配套的精品资源点击获取