引言
业务驱动型IT（为加速业务增长而引入的IT系统或SaaS）旨在提升一线生产力、把握市场机遇。然而，正如第三章所见，它也可能导致人手短缺、积累技术债务、引发工具泛滥和知识孤岛，最终可能导致业务与经营的脱节。本文将围绕“谁、在何时、应该叫停业务驱动型IT”这一问题进行梳理，其核心并非追究个人或部门的责任，而是审视决策结构本身。
一线无法叫停
启动业务驱动型IT的总是业务一线。在需要立即出成果、客户响应不能停、不愿落后于竞争对手的情况下，一线几乎不可能做出“先暂停一下”或“重新设计”的判断。对他们而言，叫停的决定近乎于放弃业务。
IT部门也无权叫停
IT部门能意识到技术风险、运维瓶颈和未来的债务。然而，在多数情况下，他们缺乏叫停业务的权限，无法做出投资决策，也无需承担最终责任，因此往往只能停留在风险提示、改进建议或制定指导方针的层面。IT部门无法叫停，并非能力不足，而是角色设计的问题。
BizOps同样无法叫停
BizOps（业务运营）的职能是连接业务与IT、加速决策、吸收混乱。然而，BizOps并非决策的替代者，也非最终决策者，因此无法做出叫停的决定。如果BizOps叫停，业务可能停滞，组织陷入混乱，其自身反而会面临问责。
供应商不在叫停之位
外部供应商的立场是按要求交付产品、在合同范围内履行职责。他们并非承接业务战略、组织设计或长期经营决策的主体。期待供应商做出叫停判断，本身就是对责任归属的误解。
唯有“管理层”能够叫停
基于以上梳理，结论只有一个：能够叫停业务驱动型IT的，只有管理层。因为，无论是决定放缓增长速度、牺牲短期成果，还是投入时间进行设计，这些决策都需要以承担整个业务的风险为代价。能够承接这种权衡的，唯有管理层。
“叫停”并非终止
这里所说的“叫停”，并非中止IT引入或压制一线行动。它指的是“切换阶段”、“更新目标函数”、“分离角色”这类设计层面的刹车行为。
叫停决策为何未能做出
许多企业的管理层未能做出叫停决策，原因很明确：因为业务在增长、数字在向好、问题尚未浮出水面，于是“还没到需要叫停的地步”、“下一阶段再考虑吧”这样的判断被一再重复。然而，叫停的最佳时机，恰恰只存在于问题尚小之时。
管理层本应做出何种判断
管理层本应事先明确以下三点：
- 实验期截止于何时？
- 从何时起切换至基础架构？
- 由谁来宣布这次切换？
叫停决策具有一种特性：等问题发生后再做就为时已晚，它只能在成功推进的过程中做出。
第三章结论
业务驱动型IT的失败，并非因为没有叫停。问题在于，本应由某人承担的“叫停”决策，无人接手。下一章，我们将以此结构为前提，探讨为何信息系统部门会被困于“防御型IT”之中，并将视角从业务层转向运营层。
评论