type
status
date
slug
summary
tags
category
icon
password
Property
Jul 28, 2022 02:21 AM
作者Joe Peppard
设立单独的 IT 部恰恰会阻碍创新能力和敏捷性，也不利于企业向数字化转型。图片来源：MICHAEL PARKIN
没有人是一座孤岛。IT 部门（即信息技术部）也不例外。
尽管它们通常肩负着使命，要在企业上下引领创新，推动数字化转型，但 IT 部门的主管，即首席信息官 (CTO) 时常沦为 “孤岛” 的管理者。只需看看任何一家公司组织架构，你大概率会看到 IT 部就像是一个长方形的盒子，不仅管理层级自成一套，预算也是单独的。
但令人沮丧的事实是，IT 部的存在恰恰会阻碍企业的创新力和敏捷性，还会降低企业对用户的关注度，也不利于数字化转型。
之所以如此，是因为 IT 部服务的是过去那个时代，它已无法适应如今这个 “数字化先行” 的世界。我们总爱抱怨 IT 部——觉得 IT 部的员工和领导活在自己的世界里，对企业需求反应迟钝。其实我们不该有这样的抱怨。问题不在于 IT 部的员工或是领导，而是设立 IT 部的想法就不对，这导致 IT 部注定会失败。
让人欣慰的是，眼下有一小批先行者正在抛弃 IT 部。它们的作法也为那些蠢蠢欲动的企业提供了样本。
“电脑部”
要明白事情为何会发展到这一步，首先要回顾一下 IT 部的诞生原因。它最初被称为 “电脑部”，有着严格的后台职能，其任务就是确保组织中的电脑能够正常运行。
在业务和技术各自为政的年代，这种做法行得通。如今，尽管 IT 部或许有了一些炫酷时髦的新名字（“全球数字解决方案”，有人这么叫吗？），但如果还是把具有必备相关知识和技能、能够管理 IT 的所有员工都集中到一个部门，这种想法就过时了。将 IT 决策和活动交给一个无论是表象还是实质都与所谓的核心业务相去甚远的部门，这种做法无异于酝酿灾难。
毕竟，技术不再是可有可无的选项，也不再是某种特别的东西；它是保持竞争力的必需品。新冠疫情的出现只会强化一个事实：没有技术的支撑，大多数组织都无法生存。它与员工的工作深度融合，它是商业模式的核心促成者，是用户体验的重要驱动者。
问题起源于我眼中的 “合伙参与模式”，当一个独立的 IT 部被提升到“业务” 合伙人的位置时，自然会形成这样的模式。虽然乍听上去十分光鲜——谁不想被视为合伙人呢？——但这种模式将 IT 看成是孤岛上的供应商，受命构建 IT 解决方案，同时向 “陆地” 提供服务。然而这不可避免地意味着，衡量 IT 部的指标通常与业务好坏无关。
试想你是制造业务的负责人。你的职责十分明确：如果销售团队交给你一份订单，你应该结合自己的产能，看看是否有能力完成这份订单。如果不能，你可以思考一下如何调整才能满足订单需求。向客户承诺的交付日期延迟了？这是物流同事的问题。生产线上出现了劣质产品？这是你需要解决的问题。
有些企业正在构建分布于整个组织的技术知识和技能网络。图片来源：MICHAEL PARKIN
这种逻辑存在于企业的各个领域。它可能并不完美，但却很有效。只有 IT 部是例外。如果你去问大多数企业的 IT 部，问一问企业对他们的衡量标准，答案几乎都与 “投入” 有关——他们花了多少钱、有多少系统没有崩溃，或是有多少项目是按时完成并且没有超预算的。但几乎没有一个答案提到 IT 部为企业的 “产出” 做出了哪些贡献。
换言之，IT 部在预算范围内按时完成各项要求——这也是合伙模式真正的设计初衷——与企业成功根本就是两回事。企业从技术中获得的价值并不来源于它所拥有的东西。成功并不是打造和管理 IT 系统。
将技术人员配备到每个部门可以加快决策速度，共享对工作的主人翁意识，同时各部门无需再与 IT 部交接，因此不会减缓工作进度。图片来源：MICHAEL PARKIN
未来不可测
合伙模式还会假定，企业中的各个部门可以提前好几个月确定它们到底需要 IT 部提供何种帮助。制定传统年度预算过程中的种种要求更是强化了这一假设。若想争取拨款，必须详细阐明自身部门的需求，同时还要对项目的持续时间和项目成本作出预估。但这一流程的前提是，所有需求都可以提前确定，而且在项目完工前，一切都不会变化。
在如今这个日新月异的数字化世界中，事情不是这样运转的。
试想一个以客户为中心的营销部门必须在 9 月或 10 月提交一份资金申请，以便其需求被纳入 IT 部明年的日程规划。但现实情况是，营销部门——或是任何一个部门——根本不知道自己到时候需要哪些东西，尤其是需要哪些技术手段来辅助他们与客户互动或是打造数字产品。这是因为客户本身在六个月、12 个月或是 18 个月之前也不清楚自己需要什么，他们也不知道一项新的产品功能是否能解决需要完成的任务。
当然你也可以说，你希望 IT 部到时的行动更迅速，更灵活。但是把 IT 部置于一座孤岛上，这几乎是不可能。
最后，你需要考虑 IT 部门员工的思维模式。大部分 IT 员工不是因为喜欢制造业、保险业或是银行业才从事这一行的，他们选择 IT 是因为他们热爱科技业。这种情况下，设立单独的 IT 部只会强化这种思维模式，加剧文化鸿沟。技术是技术，业务是业务。但这种看法完全错了：今天，业务即技术，技术即业务。
先行的公司
所幸，还有更好选择。有几家我合作过的企业，它们正在撤掉 IT 部，转而让 IT 人员融入每一个业务部门。这些企业的领导团队从 IT 部的设计初衷出发，努力实现 IT 部的价值，而不仅仅是让它专注于管理 IT 系统那么简单。尽管这种转变刚开始似乎不易察觉，但它却代表着一种深刻的变化。正如一位首席信息官曾告诉我：“三到五年内，每一个人都会成为 IT 人。”
当然，如果你有自己的数据中心、本地服务器和软件，你将需要专业人士来替你维护这些硬件和软件。这也是组建 IT 部的最初目的。但随着云计算和其他科技创新发展，实地配置硬件或软件已不再必需。
此外，如今我们编写软件的方式也发生了根本性变化。比如，有了低代码 / 无代码软件开发平台，员工可以通过拖拽、拼凑应用程序组件来做开发，无需编程技能即可做出移动端或网页端应用程序。如此一来，传统 IT 部的这项职能也失去了必要性。
我想到一家我曾经合作过的仅面向移动端的欧洲数字银行，该公司首席信息官说过这样一句话：没有 IT 部意味着你永远不需要用到 “业务” 这个词。
他说，“业务部门与 IT 部门的严重割裂是我们极力想要避免的，我们不想出现这种情形，也不想任其发展。”
这家银行在搭建组织架构的过程中，按照商业银行、支付、市场等不同工作任务将员工组织起来，通过这种方式将技术方面的专业人士融入每一个业务领域。企业领导不妨问自己一个简单的问题：我们如何利用技术能力才能实现我们的特定目标？一旦有了答案，他们就拥有了自由度，可以选择最适合自己的方式来运用技术。
这种 “享受自治” 与“承担责任”的结合让员工有了强烈的主人翁意识，同时也有了动力。团队掌握了他们所需要的资源，尽管有时这会导致裁员，但银行已对此做好准备。人们不再需要 IT 部来批准自己的需求。
设立边界
不过值得注意的是，这并不意味着在涉及技术问题时，员工可以随心所欲。在技术问题上去中心化的同时，也需要一些集中管理。上述数字银行就设立了 “边界”——每名员工必须使用同样的安全协议和软件编程语言，构建数字产品和解决方案时，必须遵循规定的架构规划。但在这些“边界” 内，他们可以自由发挥，施展任何必要的手段来完成任务。
一家采取类似做法的能源企业的首席运营官曾告诉我：这么做的目的是要 “在一个框架内营造出自由的空间”，为员工准备好画布和颜料，至于他们要画什么以及怎么画，就让他们自己来决定。
上述数字银行、能源企业以及为数不多的其他企业已经意识到，如果设立单独的 IT 部，要想拥有客户所需的敏捷性、速度和灵活性，几乎是不可能的。它不利于企业充分发挥所有员工的潜能，还迫使不同工作任务之间产生相互竞争，在员工中间也容易引发内斗。除此之外，出现这种结果的可能性也变得更大：当大家终于敲定解决方案时，他们当初想要解决的问题已不复存在。
上面提到的这些企业认为，最成功的组织需要的其实是一种分布式网络，其储备着大量技术知识和专业技能。这些企业正将技术人员部署到每个部门——在每个部门，甚至在一个部门的每个团队里配备两种人才：一种是懂业务的人，一种是懂技术的人。此举融合了内部团队之间的工作关系，有利于加快决策速度，增加透明度，并共享主人翁意识。同时各部门无需再与 IT 部交接，因此不会减缓工作进度。
将所有这些付诸实施并非易事。面对一个去中心化的新世界，不同团队的需求每个月都会变化，这种状况下，企业必须想明白如何分配和部署 IT 资源。何况，如果改变现状，会牵扯到很多既得利益。高管层需要承认，他们自己往往也是问题的一部分，而且涉及数字世界时，很多高管其实并不知道自己在哪些方面有盲区。
一旦他们意识到这点，今后该怎么做就变得一目了然，那便是企业需要 IT。但几乎可以肯定的是，它们不需要一个 IT 部门。
（注：本文作者 Joe Peppard 是麻省理工大学斯隆管理学院首席研究员。）