业务连续性流程图：从启动预案到解除响应
业务连续性流程图：连续性阈值、是否启动业务连续性计划的决策、以业务影响分析为依据的优先级排序、应急变通方案与解除响应。
运作方式
把泳道改成你们真实的应急组织
把事件管理团队、业务部门负责人、业务连续性协调人、沟通与高管层，换成你们实际拥有的角色——危机管理团队、战略层与战术层指挥、场地负责人、韧性经理、值班高管。规模较小的组织常把业务连续性协调人并入事件管理团队的泳道；宁可删掉一条泳道，也不要让它空着无人负责。
把启动标准与启动权限写下来
打开“是否启动业务连续性计划？”，填入你们自己的判定条件：预计中断时长超过某项关键职能的恢复时间目标，或者某个场地、某家供应商的不可用超过约定期限。写明谁有权启动，写明代行人，并给出一条非工作时间的联络路径。一条需要开会才能解释清楚的启动标准，在凌晨三点是不会被用上的。
把业务影响分析挂到优先级排序这一步上
“依据业务影响分析确定关键职能的优先顺序”，其质量不会高于它背后的那份分析。按恢复时间目标的顺序列出你们的关键活动，并记录每一项依赖什么：人员、场地、系统、数据与供应商。如果某项职能的依赖关系不清楚，那正是下一次演练应当瞄准的缺口。
让变通方案具体、可核查
把“启用变通方案与人工流程”换成每一项关键职能的具名变通方案，写明它的产能上限、能维持多久，以及需要事先准备什么——纸质表单、关键数据的离线副本、一个人工审批限额。再加上系统恢复后由谁负责核对这些人工记录，因为连续性的问题通常正是在积压那里暴露出来。
确定状态检视的节奏与恢复正常的判定标准
决定“按约定间隔检视状态”多久触发一次——起初每小时一次，随着局面稳定逐步拉长——以及“是否恢复正常运营？”需要什么证据：产能已恢复、员工与场地安全、积压量已核算且有人认领。没有判定标准就宣布恢复正常，正是第二次中断的经典开端。
先演练这张图，再发布一个经审批的版本
和每一条泳道一起走一遍，把步骤改成人们实际会做的事；然后用一个与 IT 完全无关的情景做桌面推演——一处场地关闭，或一家供应商崩盘。记录演练带来的改动，把它接进“更新业务影响分析与连续性计划”，并发布这个达成一致的版本，让所有人都能看到当前生效的是哪一版。
常见问题
业务连续性与 IT 灾难恢复有什么区别？
业务连续性让业务活动在中断期间继续交付——人员、场地、供应商、客户、人工变通方案。灾难恢复恢复的是技术：系统、应用与数据，用恢复时间目标和恢复点目标来衡量。灾难恢复是支撑连续性的一项能力，而不是它的替代品。业务连续性计划也会因为完全没有技术原因的事件而启动，例如某栋建筑无法使用，或一家关键供应商崩盘；即便是在 IT 故障期间，连续性要回答的仍然是：在灾难恢复团队工作的同时，业务如何继续做生意。在这张图里，这个区别就落在“启用变通方案与人工流程”上：技术恢复发生在别处，按它自己的运行手册进行。
由谁决定启动业务连续性计划？
一个获得授权的具名角色，再加上一位负责非工作时间的代行人。在这张图里，这个决策由业务连续性协调人依据成文标准作出，高管层泳道紧接着批准应急预算与授权；许多组织则把启动权交给值班高管或危机负责人。比职务名称更重要的是：标准在事件发生前就已经写下来，并且客观到一个人在夜里也能据以判断。启动是一个有成本的业务决策，但更常见的失误是启动得太晚，把最初几个小时耗在争论上。
什么是连续性阈值，它从哪里来？
它来自业务影响分析（BIA）。对每一项关键活动，BIA 记录它可以被中断多久，后果才会变得不可接受——即最大可容忍中断时长，也称最大可接受停机时间——以及在这个上限之内的一个恢复时间目标。连续性阈值把这些数字变成一个触发条件：如果预计中断时长将超过某项关键活动的恢复时间目标，就启动计划。受监管的机构可能会有一套由外部设定的对应要求；例如英国金融服务业的运营韧性规则，就要求机构识别重要业务服务并为其设定影响容忍度。
连续性安排应当运行多久才回到正常状态？
只要恢复正常的判定标准尚未满足，就继续运行——这也是这张图采用循环、而不是假定一个固定时长的原因。“按约定间隔检视状态”与“延长连续性安排”之所以存在，是因为变通方案有保质期：人工处理产能、临时场地和各方的善意都会被消耗，而积压则一直在增长。开始时把检视节奏排密，随着局面稳定再拉长；并且把恢复正常当成一个由某个人签字的决策，而不是悄悄滑回旧习惯。
使用这份模板能让我们符合 ISO 22301 吗？
不能。ISO 22301 是业务连续性管理体系的国际标准，符合性取决于整个体系——最高管理者的承诺、业务影响分析与风险评估、成文的计划与程序、演练与测试、绩效评价与改进——而不取决于任何一张图。一张清晰、有负责人的流程图可以支撑其中若干项要求，在审核或客户问卷中也是有用的证据，但它是管理体系的一个组成部分，而不是体系合规的证明。