即使通信中断也能运行的系统所提出的问题
“即使通信中断也能运转！数字化让避难所接待发生如此变化！？”这条新闻引发了热议。内容是关于在灾害时，将避难所接待数字化，并推进即使离线也能运行系统的实证实验。
乍一看，这只是一个防灾DX的案例。然而，从经营×IT的角度来看，这里浓缩了许多企业面临的根本性问题。
那就是“实战环境中不停机的IT”未被设计的问题。许多企业只考虑日常业务效率来引入系统。但真正有价值的，是在发生故障时也能持续运行的IT基础设施。
将平时与灾时分开思考的危险性
这次避难所系统的特点在于，即使通信中断也能独立运行。不依赖云端，通过本地数据库完成接待。这给经营带来了极其重要的启示。
许多企业采取“平时用云端，灾时用备份”的双层IT战略。但这种想法本身就危险。因为灾害会突然降临，系统切换未必能顺利进行。
实际上，某中型制造业的IT负责人这样说道：“即使制定了BCP（业务连续性计划），当系统实际无法使用时，恢复步骤只停留在纸质文档上。没有信心在关键时刻能操作起来。”
这是将IT仅视为“管理IT”的典型例子。如果经营层将其作为“事业IT”，设计成与销售额和客户应对直接相关的系统在实战中不停机，这个问题本可以避免。
经营者应思考的“离线优先”设计理念
避难所接待的案例表明，需要改变系统设计理念本身。
具体来说，经营者应把握以下三个要点。
1. 不要将系统可用性分为“平时”和“故障时”来评估
许多企业将系统运行率评估为“99.9%”。然而，剩下的0.1%故障时刻，恰恰会对客户应对和运营造成致命影响。
经营者应要求系统具备包括故障时在内的“全规格可用性”。具体来说，请考虑将即使离线也能运行主要功能的“离线优先”设计理念，作为SaaS选型的条件之一。
2. 将备份设计为“目的”而非“手段”
许多企业只将数据备份视为“备份了就安心”。但真正需要的是“能从备份中恢复”，并且恢复步骤不能依赖特定个人。
例如，某大型零售连锁店，在POS系统宕机时，收银员手写单据，日后手动输入系统。这是系统宕机时“运营”未被设计的典型例子。经营者需要将系统宕机时的“业务流程”也纳入IT投资效果的评估中。
3. 作为经营IT确保“可再现性”
不仅是灾害时，在日常故障（服务器宕机、网络故障、网络攻击）中，为了不让业务停止，“可再现性”不可或缺。
可再现性是指不依赖特定负责人，任何人都能按相同步骤持续业务的状态。这正是经营IT的核心。正如避难所接待的数字化摆脱了“纸质台账”，让任何人都能同样完成接待，企业的核心业务也应追求在故障时“无论谁做都能得到相同结果”的状态。
具体案例：某物流企业的“实战设想”失败
过去，有一家物流企业更新了仓库管理系统（WMS）。这家企业引入了云端WMS，实现了成本削减和实时库存管理。然而，引入半年后，因数据中心故障导致系统停止运行12小时。
在此期间，仓库内的拣货作业全部停止。出货延迟，导致被客户索赔巨额损失。这家企业的经营者在引入系统时，完全没有考虑“故障时的替代方案”。
这个案例告诉我们，IT投资的判断标准必须包含“故障时的业务连续性”。不仅要看工具的功能和价格，还应将“离线时能否运行”“故障时是否准备了替代流程”作为评估轴。
经营者现在应立即执行的3个行动
那么，经营者具体应该做什么呢？建议以下三点。
1. 盘点核心系统的“故障时运营手册”
不要只交给IT部门，经营者应亲自定量评估“系统宕机时，对销售额和客户应对有多大影响”。在此基础上，定义恢复时间目标（RTO：目标恢复时间）以及在此期间实施的替代业务流程。
2. 在SaaS选型评估项目中加入“离线功能”
引入新SaaS时，务必向供应商确认“通信中断时，哪些功能可用”。销售人员会宣称“99.9%的可用性”，但询问剩下的0.1%会发生什么，是经营者的职责。
3. 强化作为“经营IT”的可再现性
将只有特定负责人知道的系统设置和运营规则文档化、标准化。这不仅在灾害时有效，也能防止因负责人离职或调动导致的业务停滞。具体来说，可引入Notion或Confluence等知识管理工具，创建任何人都能访问的状态。
总结：IT的最大价值在于“不停机”
避难所接待的数字化表明，IT在成为“便利工具”之前，必须首先是“不停机的工具”——这是一个理所当然却容易被忽视的事实。
经营者在判断IT投资时，往往容易关注“业务效率能提升百分之几”“成本能削减多少”。但真正应该问的是“如果那个系统宕机了，公司会怎样”。
无法回答这个问题的IT投资，不过是实战中无法发挥作用的“装饰性IT”。为了在灾害时、故障时也能持续为客户提供价值，经营层需要直接设计“实战设想”，并将其融入IT中。
你公司的IT，真的是“不停机”的设计吗？
评论