风险升级机制已经建立，风险却没有按时升级，通常说明问题出在机制的执行环节，而非规则本身。排查时先确认哪些风险该升未升、超时多久，再依次核对触发条件是否可判定、责任人是否有顾虑或权限不足、升级请求在交接与通知的哪一步断掉，最后按卡点处置并用真实案例验证恢复。
要点总览（TL;DR）
- 排查从症状界定开始：抽取近一个周期应升级的风险样本，记录登记、达到条件、实际升级、接收确认四个时间点，区分“未触发升级”与“触发后未执行”。
- 规则层先查触发条件能否落到字段、阈值口径是否统一、关键字段是否留空、规则版本是否同步，这四类问题会直接导致风险判不出来。
- 规则清晰仍不升级，转向责任人访谈，确认是否存在升级顾虑、权限不足、信息不对称和“先自己扛”的默认做法。
- 链路断点集中在发起、审批、通知、接收四个环节，跨团队跨层级交接处和单一通知渠道是最常见的断点位置。
- 处置按卡点类型分开执行，动手前备份台账与规则配置；修复后用一条新风险做端到端回放，设定观察期统计按时升级率并纳入定期复盘。
先界定症状：哪些风险该升未升、超时多久
“没按时升级”是一个笼统描述，直接进入原因分析容易各说各话。第一步是把症状转成可核对的事实清单，确定排查范围，后续所有原因假设都围绕这份清单展开。
先区分两类症状。“未触发升级”指风险已经达到升级条件，但系统或流程没有产生升级动作；“触发后未执行”指升级请求已经发出，但审批、通知或接收环节没有完成。两类症状指向的原因不同，混在一起统计会让排查失焦。
抽取近一个周期内应升级的风险样本，逐条记录四个时间点：风险登记时间、达到升级条件的时间、升级请求实际发出的时间、升级被接收确认的时间。四个时间点之间的差值，就是超时时长。样本量不必大，覆盖不同等级、不同责任团队、不同登记渠道即可。
“按时”的口径要在排查前统一。按日历日计算、按工作日计算、按评审节点计算，三种口径得出的超时结论可能完全不同。机制文件里写了哪种口径，就以哪种为准；文件没写清楚的，先作为规则缺陷记录下来。
已发生阻塞的事项属于项目问题管理范围，不纳入本次风险升级排查。把这类事项剔除后，剩下的样本才是升级机制真正需要解释的对象。
| 风险编号 | 风险等级 | 登记时间 | 达到升级条件时间 | 升级实际发生时间 | 超时时长 | 症状类型 |
|---|---|---|---|---|---|---|
| 示例：R-012 | 高 | 3月2日 | 3月6日 | 3月11日 | 5个工作日 | 触发后未执行 |
| 示例：R-018 | 中 | 3月4日 | 3月9日 | 未发生 | — | 未触发升级 |
这张清单的完成标志是：每条样本都能回答“该不该升、什么时候该升、实际升没升、差了多少”。做不到这四点的样本，说明登记字段本身缺失，这本身就是一条待查线索。
逐项核对触发条件：规则是否可判定、阈值是否被绕过
拿到样本清单后，先查规则这一关。规则设计缺陷的典型表现是：条件写得像原则，执行时靠人解读，解读结果因人而异。这类问题在机制文档里看不出来，只有拿真实风险逐条对照才会暴露。
核对触发条件是否写成可量化字段。概率、影响程度、涉及金额、延期天数、受影响范围，这些能落到字段上的条件，系统或流程才能稳定判定；写成“影响较大”“存在一定风险”的条件，只能靠责任人主观判断，漏判几乎是必然结果。
核对阈值口径是否统一。常见情况是项目分级标准、部门风险管理办法、升级机制文件各有一套阈值，同一风险在不同口径下等级不同。排查时把三套口径并排列出，找出冲突项，冲突项对应的风险就是高风险漏升样本。
核对登记字段是否留空。触发规则依赖的字段如果在风险登记时没有填写，规则无法判定，风险就会停在原地。统计样本中关键字段的填写率，能直接看出这是不是主要原因。
核对规则版本是否同步。规则调整后，如果只在部分项目更新，旧版本仍在运行的项目会继续按旧阈值判定。排查时确认每个项目当前生效的规则版本，版本不一致的项目单独列出。
| 核对项 | 判定标准 | 问题表现 | 结论 |
|---|---|---|---|
| 触发条件形式 | 可落到字段与数值 | 依赖主观描述 | 规则缺陷 |
| 阈值口径 | 各文件一致 | 多套标准并存 | 规则缺陷 |
| 关键字段填写 | 登记时必填 | 大量留空 | 执行偏差或字段设计问题 |
| 规则版本 | 全项目统一 | 新旧版本混用 | 发布管理问题 |
这一节的产出是可判定性核对表和问题项列表。核对完成后应能明确回答：漏升样本中有多少条是规则本身判不出来，有多少条是规则能判但字段缺失，有多少条是版本不一致。三类问题的处置方式不同，不能合并处理。
访谈责任人：顾虑、权限与信息不对称
规则核对只能解释“判不出来”的部分。规则清晰、字段完整，风险仍然没有升级，就要转向责任人。访谈的目的不是追责，而是找出规则之外的人为卡点，解释为什么明知该升却没有升。
访谈围绕四个问题展开。第一，责任人是否担心升级被理解为能力不足或越级汇报。如果组织里存在“升级等于告状”的隐含评价，责任人会倾向自己消化风险。第二，责任人是否具备升级所需的权限或审批入口，有些流程要求先提交申请再由上级发起升级，入口本身就把人挡在门外。第三，责任人是否清楚升级后由谁接手、会带来什么后果，信息不对称会让人选择观望。第四，团队是否存在“先自己扛一扛”的默认做法，机制文件里没有写明升级是义务而非选项。
访谈对象应覆盖样本清单中每条超时风险的责任人，以及其直接上级。同一卡点在多个访谈中重复出现，才可作为共性原因；只出现一次的说法，先作为个案记录，避免以偏概全。
访谈结果按卡点类型归类：顾虑类、权限类、信息类、文化类。归类后与规则核对结果对照，能看出漏升样本中人为因素占多大比例。这个比例决定了后续处置的重点是改规则还是改机制文件与授权。
检查交接与通知链路：升级动作在哪一步断掉
规则可判定、责任人也有意愿，升级仍未按时发生，问题就在链路。升级动作由发起、审批、通知、接收四个环节组成，任何一环没有明确责任人和时限，请求就会停在那里。
逐环节检查。发起环节确认谁有权发起、通过什么入口发起；审批环节确认审批人、审批时限以及审批人不在时的替代人；通知环节确认通知渠道和通知对象；接收环节确认谁负责确认接收并开始处理。每个环节都要能回答“谁做、多久内做完、没做完谁发现”。
重点看跨团队和跨层级的交接处。风险从项目团队升到部门、从部门升到项目群，每跨一层都可能出现无人认领的空档。排查时把样本中涉及跨层级的风险单独抽出，核对每一层的接收记录是否存在。
通知渠道单一也是常见断点。只在一个群里发消息、只发一封邮件，接收人不在群、邮件未读，升级就等于没有发生。检查样本中通知发出后是否有接收确认记录，没有确认记录的通知应视为未送达。
最后确认升级后状态是否回写到风险记录。状态不回写，就无法判断升级是否完成，也无法统计按时升级率。回写缺失本身就是链路缺陷，需要在处置阶段补上。
这一节的产出是链路断点定位图或环节检查表，每个断点标注所属环节、涉及样本和缺失的责任人或时限。
按排查结果处置：修复规则、补权限、加超时提醒
处置动作按卡点类型分开执行，避免用一套措施覆盖所有问题。动手前先备份现有风险台账与规则配置，保留历史记录，防止规则调整覆盖已有风险的判定结果。备份完成是处置的前置条件。
规则类问题的处置：把触发条件改写为可量化字段，明确每个字段的取值范围和判定逻辑；统一阈值口径，以一份文件为准，其余文件引用该口径；规则变更后按项目清单逐一确认生效版本，旧版本停用。规则修改后先用历史样本回测，确认原本该升的风险在新规则下能被判定出来，再正式启用。
人为类问题的处置：在机制文件中写明升级是责任人的义务，同时写明不升级的后果和按机制升级后的保护条款，消除“升级等于能力不足”的顾虑；补齐升级所需的权限和审批入口，减少不必要的层级前置；对升级后的接手人和处理流程做一次说明，降低信息不对称。
链路类问题的处置：为发起、审批、通知、接收每个环节设定时限和责任人，配置超时提醒；通知渠道至少保留两个，并要求接收确认；升级状态回写到风险记录，形成可追溯的闭环。
处置的停止点是：当样本清单中的超时风险都能对应到已定位的卡点，且每个卡点都有明确的责任人和完成时点时，处置阶段结束，进入验证。仍有无法归类的超时样本，说明排查不完整，应回到症状清单补充样本，而不是继续加措施。
验证恢复与防复发：用真实案例回放确认生效
处置完成不等于机制恢复。验证要回答两个问题：新发生的风险能否按时升级，以及同类卡点会不会再次出现。
选取一条新登记的风险做端到端回放，核对触发判定、升级发起、审批、通知、接收确认、状态回写各时间点是否符合设定时限。回放应覆盖至少一条跨团队或跨层级的风险，因为交接处是最容易复发的位置。回放记录作为验证证据留存。
设定观察期，统计应升级风险的按时升级率是否回到目标值。观察期长度与风险的暴露周期匹配，短周期项目可以按周统计，长周期项目按评审节点统计。统计口径沿用排查阶段确定的“按时”定义，避免前后口径不一致导致结论失真。
把超时未升级纳入定期复盘议题，每次复盘检查三项：本期是否有超时样本、超时卡点是否属于已知类型、已知卡点的处置动作是否仍然有效。三项中任一项出现异常，触发复发预警。
明确复发后的上报路径。同类卡点再次出现时，由复盘主持人直接上报至机制负责人，重新走一遍症状界定与原因核对，不重复使用上次的处置结论。复发预防检查项与验证记录一并归档，作为下一轮机制评审的输入。
在风险登记、触发判定、升级通知与状态回写这几个环节，ONES 的项目管理与流程自动化模块可以承载相应的工作项与规则配置，多维度数据统计也可用于观察按时升级率的变化；具体配置方式以实际部署和套餐能力为准。机制能否按时运转，最终取决于规则是否可判定、责任是否清晰、链路是否闭环，工具承担的是把这些条件固定下来并留下可核对的记录。
常见问题
风险已经达到升级条件，但系统没有产生升级动作，应该先查什么？
先查触发条件能否被判定。核对三件事：触发条件是否写成了可量化字段，比如概率、影响程度、涉及金额、延期天数；风险登记时这些字段是否填写完整；当前项目生效的规则版本是否与最新版本一致。三项中任何一项不满足，规则都无法稳定判定，风险会停在原地。字段填写率可以直接从样本清单统计，规则版本则要逐项目确认。
责任人承认该升级却没有升，访谈时应该问哪些问题？
访谈围绕四个方向：责任人是否担心升级被理解为能力不足或越级汇报；是否具备升级所需的权限或审批入口；是否清楚升级后由谁接手、会带来什么后果；团队是否存在“先自己扛一扛”的默认做法。访谈对象覆盖超时风险的责任人及其直接上级，同一说法在多个访谈中重复出现才作为共性原因，只出现一次的先按个案记录。
升级请求已经发出，但接收方说没收到，这类断点怎么定位？
把升级动作拆成发起、审批、通知、接收四个环节，逐环节核对“谁做、多久内做完、没做完谁发现”。接收方说没收到，重点查通知渠道和接收确认：是否只在一个群里发消息或只发一封邮件，通知发出后是否有接收确认记录。没有确认记录的通知应视为未送达。跨团队跨层级的风险单独抽出，核对每一层的接收记录是否存在。
修改升级规则时，如何避免影响已经在跟踪的风险？
动手前先备份现有风险台账与规则配置，保留历史记录。规则修改后先用历史样本回测，确认原本该升的风险在新规则下能被判定出来，再正式启用；规则变更后按项目清单逐一确认生效版本，旧版本停用。阈值口径统一时以一份文件为准，其余文件引用该口径，避免多套标准并存。
修复后多久可以判断升级机制已经恢复？
处置完成不等于恢复，需要两步验证。先选一条新登记的风险做端到端回放，核对触发判定、升级发起、审批、通知、接收确认、状态回写各时间点是否符合设定时限，回放至少覆盖一条跨团队或跨层级的风险。再设定观察期统计按时升级率，观察期长度与风险暴露周期匹配，短周期项目按周统计，长周期项目按评审节点统计，统计口径沿用排查阶段确定的“按时”定义。
