SYSTEM OK | ACTION CONTRACTS 247 DOMAINS 35 DEMO ENVIRONMENT 无需申请 | 服务热线 18926139835
首页/产品/跑得顺
五柱 ⑤ · 跑得顺 · 规划中 · 项目交付

流程受阻环节无从判断

一笔申购历时两个月,逐级询问均得到"在走流程"的答复。该答复之所以无从反驳,是因为无任何数据能够说明其停留环节与停留时长。 本项能力监控端到端流程各环节的时效与人效——平均、最大、最小时长,堵点与断点,超期预警。 该项数据横跨全部五个阶段,不隶属于任何单一阶段。

能力状态:规划中 / 项目交付。本项能力当前以项目交付方式提供,不在标准版本内。本条仍予列示,是因为它是该流程不可回避的一环——而非因其现已具备开箱即用的条件。

1条
蓝图本期实现监控的端到端流程:资产申购 → 验收立卡
3个
每个环节需采集的三个时长口径:平均 · 最大 · 最小
3张
及时率与完成率报表:验收及时率及超期 · 工单完成及时率 · 计量计划完成率
先有打点,方有诊断
缺少停留时长,则堵点无从识别
01本项能力的问题

流程的迟缓环节无从定位

这一部分内容来源明确:源自蓝图对现有流程的描述,也源自每一家已上线业务系统的集团企业的共同经验。

01

流程只有状态,没有时长

"在审批中"是一个状态,而非一段时间。系统通常能够说明单据当前所处环节,但无法说明其在该环节已停留多久。缺少停留时长,平均 / 最大 / 最小时长即无从计算——这是本项能力全部问题的根源。

02

时效链在系统之间中断

申购在 SRM、审批在 OA、立卡在 EAM、财务在 ERP。蓝图 EAM.TB.020 的流程描述里,"通过接口将 OA 请购单推送至 EAM""固定资产编码回写资产卡片"这些动作本身即跨越多个系统——一条流程分为四段,各系统仅掌握本段的停留时长。

03

平均值最易失真

一笔申购历时两个月,而平均时长可能仅二十余天。平均值会将滞留两周的个案稀释,把"某几个节点偶尔严重超期"摊平为一个看似正常的数值。需要查明的是最大时长出现在哪一环节、归属于哪个角色。

04

及时率是事后总结,而非当期预警

验收及时率、工单完成及时率、计量计划完成率这类报表,若仅在月底出具一次,"超期"便始终是超期发生之后才被呈现的结果。责任人也只有在收到通报时才知晓自身已超期。

02本项能力的内容

把流程从"状态"转化为"时长"

本项能力的清单看似最"轻",但它是其余四项能力能否被验证的前提条件。下列每一项均对应蓝图已写明的做法或报表。

01

端到端时效打点

做法是对流程的每一个环节记录进入与离开时间戳,据此得到环节停留时长。蓝图对流程监控的实现方法表述明确:从流程涉及到的 IT 系统获取单据和数据,再做统计、分析与展现。

此项工作不完成,后续所有统计均无分母——因此它是本项能力的首要内容,而非最后一项。

02

平均 / 最大 / 最小三类时长

三个口径并列查看:平均反映整体趋势,最大反映个案与堵点,最小反映环节是否流于形式(例如点检秒过)。

这三个口径是蓝图流程监控中心的原文设定,非本方另增的指标。

03

堵点与断点诊断

堵点是最长停留所在的环节,可定位到具体角色与具体单据;断点是应触发而始终未触发的节点。

断点比堵点更为隐蔽:它不产生耗时,使流程静默停留——例如终验、质保验收这类"到了时间该发起"的动作。

04

超期阈值与自动预警

本方的路线是将"超期"由月末结论转为在途提醒:超过阈值的单据推送至责任人与流程 owner,而非等待人工查阅报表。

预警的价值不在于催办,而在于使"受阻"这一情况在发生的当期即有记录责任人。

05

人效与处理量

将同一环节不同人员的处理时长与处理量并列查看。蓝图里对应人员工时及效率统计报表,维修侧还包含平均响应时长、平均维修时长、维修返工率这类统计。

"流程慢"能否落到具体角色与工作量上,决定该结论是否沦为一次无实效的整改。

06

及时率与完成率口径

三张既有报表分别对应三条线:验收及时率及超期统计报表(立卡)、工单完成及时率统计报表(运维)、计量计划完成率统计报表(合规)。

这三张报表在蓝图中本就存在。本方不打算为这一页再造指标。

关键洞察 · 「跑得顺」是其余四项能力的前置条件

若流程各环节没有时效打点,则无法统计平均 / 最大 / 最小时长,也就无从诊断堵点。而决策层恰恰需要用"流程是不是快了"来判断该系统的投入是否值得。换言之:看得见、调得动、买得准、算得清这四项能力说明的是"能够做什么",唯有本项能力回答"实施之后是否有所改善"。这是官方渠道可以阐述、同业普遍未曾涉及的一层。

03决策层看什么

本项能力对应哪些报表与指标

流程健康度是少数几项"上线前后可以拿同一套口径对比"的指标。下列每一行均可在蓝图的报表目录中找到对应名称。

表 1 · 「跑得顺」对应的决策层口径。报表名来自 EAM 项目一期蓝图(2024-06);蓝图标注流程监控本期只实现"资产申购到验收立卡"这一条流程。
决策问题可用报表 / 指标说明
流程是不是快了 流程监控中心(各环节平均时长 · 最大时长 · 最小时长)+ 人员工时及效率统计报表 上线前后用同一套口径对比,这是"这套系统到底有没有用"唯一的客观证据
验收这一环卡不卡 验收及时率及超期统计报表 申购到立卡的最后一公里;超期往往发生在资料与协调环节,而非审批环节本身
维修工单及时不及时 工单完成及时率统计报表 + 平均响应时长 · 平均维修时长 · 维修返工率 故障响应与闭环的时效口径,与委外、备件到货的时间可拼合为完整链条
计量计划有没有漏 计量计划完成率统计报表 合规线的完成率口径:计划是否排定、是否执行——这两项须分别查看
谁在处理、处理了多少 人员工时及效率统计报表 将"流程慢"从主观印象落实到具体角色与工作量上
为什么本项能力决定了其他四项能力能否被验证

多数资产系统上线之后无法回答一个问题:流程比以前快了吗。这一问题的证据来源唯有时效数据。因此流程监控属于该流程的度量方式,而非报表体系中多出的一张——它也是将"资产管理做得好不好"从主观评价转变为可比较数据的那一步。

04上下游衔接

本项能力横跨四个阶段,并非某一阶段的专属流程

它没有独立的业务动作,其输入来自其他阶段产生的单据与时间戳,其输出是其他阶段改进的依据。这正是它容易被忽略的原因。

上游输入

② 取得与立卡的节点与单据:申购 → 审批 → 采购 → 收货 → 验收 → 立卡。取得与立卡这一阶段的流程,同样是蓝图本期唯一纳入监控的流程。

OA / SRM / ERP 的单据时间戳:跨系统的时间点是本项能力的输入来源。蓝图对流程监控实现方法的表述为"从流程涉及到的 IT 系统获取涉及到的单据和数据"。

③ 使用与运维的计划与执行记录:工单、委外、计量计划的排期与完成时间,构成及时率与完成率三张报表的口径来源。

下游输出

④ 变动与流转的移交、借用、归还同样需要按时效打点,否则"这台资产在谁那里待了多久"这一问题仍然无法回答。

与「看得见」互补:资产全景管理的是状态,本项能力管理的是时间。两者结合方能回答"这台设备为什么三个月没动"。

给决策层的回答:该系统上线之后以何为依据说明其有效——这是流程时效数据承担的唯一任务。

概括而言:其余四项能力回答「能做什么」,本项能力回答「实施之后是否有所改善」。

05标准依据

本项能力对应 ISO 55001:2024 的哪几条

流程监控在标准中的位置比其表面更为重要:策划与控制、绩效评价、保障,三处均需使用可度量的过程数据。

表 2 · 条款对照。条款号以 ISO 55001:2024(第 2 版)为准,逐条可回原文核对。
条款标准要求(摘要)2024 变化本项能力对应的做法
§8.1 运行策划与控制,含生命周期管理:明确七个生命周期过程 修订 端到端流程定义 + 各环节时效打点:所谓"控制",首先需要有可观察、可度量的点
§6 / §9 策划 · 绩效评价:目标、监控、测量与分析 调整 平均 / 最大 / 最小时长、及时率与完成率是可测量的绩效口径;超期预警对应"监控"这一动作
ISO 55000:2024
保障
保障(Assurance)列为资产管理三项产出之一:应提供更好的组织监督与问责 产出新增 时效数据是"过程可被监督与问责"的证据,而非依赖汇报与说明
ISO/TS 55010 财务与非财务职能对齐 2024 流程时效与成本节奏互为依据:超期往往伴随工期与费用的偏差

ISO 55000 系列为本方的方法论依据,并非认证。 认证的对象是组织,而非软件——任何声称「某系统通过 ISO 55001 认证」的表述,均与 ISO 55001 所界定的认证对象不符。 完整标准对齐说明 →

06延伸阅读

进一步参阅

本项能力当前可达到的程度

「跑得顺」依赖跨系统的单据时间与产品侧的最终确认,当前以项目交付方式提供,不在标准版本内; 蓝图标注本期只实现"资产申购到验收立卡"这一条流程的监控。 与其观看演示,不如先行完成一项工作:将贵方当前最需要厘清的那条流程绘制出来,核查每一个环节是否留下时间戳—— 此项工作完成之后,本项能力能否落地即有明确结论。

执行层
先行厘清流程环节
决策层
先行查阅六项问题中的"流程顺不顺"