はじめに
在第二章中,我们分别审视了以增长速度为最优先的IT、未设计可复现性的经营决策,以及仅以稳定性为评价标准的IT组织。本文将探讨它们在某个时间点同时成立、且无法回头的瞬间,即“IT目标函数分裂的瞬间”。
目的関数とは何か
目标函数定义了“为了优化什么而存在”。在经营中,它决定了什么被视为成功、什么可以被牺牲、哪些指标应被优先考虑。IT原本也应拥有一个清晰统一的目标函数。
分裂は一度に起きたわけではない
IT的目标函数并非在某一天突然分裂。在增长阶段,速度被优先选择;在扩张阶段,可复现性被搁置;在运维阶段,只剩下稳定性。每个阶段在当时都是合理的判断。问题在于,阶段变化后,目标函数却未随之更新。
同じ「IT」が別のものになった
如果目标函数长期不更新,IT便会分裂为以下几种形态:
- 业务IT:以最大化增长速度为使命。
- 运营IT:以最大化稳定性和效率为使命。
- 整合IT:无人认领的使命。
它们虽存在于同一家企业内部,却已成为解决不同优化问题的独立存在。
分裂した目的関数は、互いを破壊する
以优化速度为己任的IT会牺牲稳定性,以优化稳定性为己任的IT则会抗拒变化。由于缺乏可复现性设计,两者无法有效连接。结果便是,业务部门视IT为绊脚石,IT部门视业务为鲁莽之举,形成对立结构。
経営は「選ばなかった」
关键并非经营层选错了目标函数,而是他们最大的决策在于“没有做出选择”。何时应优先速度?哪个阶段应转向可复现性?稳定性何时应成为主角?在未明确这些问题的前提下,他们试图同时满足所有要求。
分裂が固定化された理由
目标函数的分裂最终会嵌入组织结构。业务部门以速度为评价标准,IT组织以稳定性为评价标准,而可复现性则无人问津。于是,分裂不再是个体意识问题,而成为组织的前提条件。
なぜ統合は後からできなかったのか
分裂后的目标函数极难在事后整合。因为评价指标不同、时间轴不同、成功经验也不同。各方都曾基于自身逻辑进行过“正确”的优化。整合需要有人决定“舍弃什么”、“优先什么”,而这只能是经营层才能做出的决策。
目的関数の分裂は、失敗ではなく警告
纵观至此,目标函数的分裂看似一种失败。但其本质,是向经营层发出的一个警示:提示其应在何时将IT置于主体地位,应在哪个阶段做出整合决策。正是忽视了这个警示,才导致分裂演变为慢性顽疾。
第II章の結論
IT的问题,不在于技术、人员或组织。其根源在于,经营层从未就“应优化什么”做出过选择。下一章,我们将从业务层面,审视这个分裂的目标函数如何在业务推进现场失控狂奔。


评论