《保持联合运行宣言》一书(Keep the Joint Running Manifesto)的第7条原则称，在你具有战略性之前，你得先具备能力。

IT的流程和实践要指导IT人员如何完成工作，有没有能力就体现在这里。

现在的问题是，作为 CIO，你需要将个人注意力集中在哪些IT流程和实践。

答案始于这条基本原则：管理者本人发起的变革项目永远不要超过三个。超过这个数字，你就会失去专注力，因此失去领导力。

那么CIO应该选择哪三个流程呢?

不要关注IT运营

很显然，最有可能组织管理流程改进计划的是著名的ITIL 框架，但这是个错误。

并不是说采用ITIL框架是个错误。这是一套完美的框架，经历了几十年已经成熟了。

而是说ITIL专注于IT运营。只有出现岔子时，IT运营才有人关注。作为CIO，你会希望系统运行正常时也有人关注。

因此，如果你的IT部门需要改进可用性管理、容量管理、性能管理、基础设施生命周期管理、系统管理，尤其是变更管理等方面，要确保你有合适的人来负责IT运营，并且明确表示：你将通过唯一的、重要的IT运营指标：Invisibility Index(隐形指数)来衡量其是否成功--也就是说，没人关注IT运营时，你必须关注它，责无旁贷。

作为CIO，你应该认识到：虽然IT运营至关重要，但它根本不具有战略性，如果IT运营没做好，你不可能具有战略性。

要把IT运营委派出去，并确保受委派的那个经理拥有所需的全部工具和支持。

流程优先级第1：求助台

如果IT的声誉不是很好，改进求助台应该是你的首要任务。

不幸的是，求助台在IT部门并不受待见，原因是IT部门与公司其他部门成功整合的一个关键因素是业务/IT关系的质量。

IT部门与公司其他部门之间的关系取决于求助台。因此，如果你听到求助台被讥讽为"毫无帮助的求助台";或者如果业务部门的同事问你：为什么直到有人打电话通知求助台，IT部门才知道系统宕机;或者如果你听到求助台的工作人员相互讲述可笑的用户故事;或者有人打电话向求助台寻求快速简单的方法，而求助台只给了对方故障单号，而不是立即给出对方需要的10秒钟答复--只要求助台出现某种不妙的迹象，你的注意力就要放在改进求助台上。

你需要业务部门的支持，才能使IT部门的其余人员大放异彩，而这种支持离不开求助台。

流程优先级第2：应用软件支持

规则 1：如果你的应用软件支持团队仍然执迷于瀑布方法，你还等什么?让他们立即开始转向敏捷方法，并亲自监管敏捷采用策略及执行。

规则2：敏捷不仅仅是Scrum。要为IT部门实际从事的工作选择正确的敏捷变体，而不是因为"每个人都在使用Scrum"就选择Scrum。

规则3：大多数采用敏捷变体的目的在于管理应用软件开发。大多数IT部门都是"尽量购买，没办法时才自建。"如果你是这种情况，请忽略Scrum。如果相反，让你的应用软件团队采用CRP(会议室模拟)或非常相似的ATDD(验收测试驱动开发)。

规则4：大多数敏捷变体专注于将软件作为产品来交付。大多数企业需要IT进行协作，以实现预期的业务变化。你可以改动采用的任何敏捷变体，以确保它取得你预期的效果。

流程优先级第 3：IT架构管理

如果IT架构本身的质量差强人意，这个迹象当然表明IT架构管理实践失灵了。

另外还有哪些迹象表明你的IT架构管理实践需要帮助?

"我们无法判断自己的架构有多好"这是一个很常见的令人惊讶和沮丧的迹象。所以，"我们不知道自己有什么架构"这种迹象也就司空见惯了。

那么还有什么迹象?IT部门还没有：

• 发布和宣传指导其他一切的一系列架构原则(至多十几个原则)。除了数量不宜过多外，原则还必须用通俗易懂的用语来编写。
• 发布和宣传一系列标准，这些标准植根于原则，遵循有据可查的实践来保持最新，并定期更新--每季度更新一次就很合理。
• 将生命周期管理确立为标准实践，将其整合到IT规划和预算编制中。
• 围绕架构原则和标准制定一项云战略，并认识到云是一种架构，不是存储和处理环境。

这并不意味着如果IT架构没有这些缺陷，这条实践就安然无恙。

IT架构实践及其与业务整合的相似实践--企业架构实践一起，始终面临从增加和维护价值变成官僚主义泥潭的风险。

捎带提一下，这种风险不是架构所独有的。任何获准审评其他团队创造性工作的部门都面临同样的风险。

一流的架构需要摈弃官僚主义的观念。它还需要资金，因为在项目中，与交付拥有令人满意的功能和特性的应用软件相比，交付拥有令人满意的功能和特性，并且遵守架构标准的应用软件需要更高的成本。

由于发起项目的普通主管不太可能愿意支付差价，交付或修改应用软件功能的项目将需要架构补贴来弥补差价。

IT架构管理部门必须想方设法获得健康良好的架构，同时尽量少用强制执行作为主要手段。该部门还必须说服高层领导，让对方相信良好的架构是公司明智的投入。由于这两个至关重要的问题，我们很难不得出这样的结论：即使在最好的情况下，CIO也应该亲自监管IT架构团队。

但信息安全方面怎么办呢?

当下，与IT有关的业务威胁越来越多地来自有组织的犯罪团伙和政府撑腰的不法分子，入侵造成的潜在破坏早就从"严重"变成"巨大"，因此信息安全必须成为IT部门的首要任务之一。但是与IT运营相似，信息安全的有效性由其自己的隐形指数来衡量。

只是结果更糟糕，因为信息安全要有效，势必有侵扰性，因此某种程度的不讨人喜欢的可见性会随地域而变化。。

还有一点：如果信息安全没有与高质量的IT架构紧紧联系在一起，那就是有漏洞的信息安全。

因此，将信息安全纳入你的IT架构实践，作为CIO你还可以密切关注信息安全，而不是让信息安全进一步分散你的注意力。

解决IT创新(又叫"数字化")

看看创新的商机出现在哪里，你将会发现信息技术即便不是No 1，也肯定名列前三。

作为CIO，你在这方面的选择要么是负责IT创新，要么是接受高层管理团队增添一名CDO(首席数字官)的想法。

而这无异于声明你的能力不足。而且，这会将IT领导层一分为二，CDO成为了提议者，而你成为了反对者。因此，"CIO"到头来变成了你即将退休的声明(Career Is Over-- 职业生涯到头了)。

可不要这样。

你应该将IT创新也融入到IT架构实践中。此举不仅让创新在组织中有一席之地，使其不会分散你的注意力，还将创新的责任，与将IT创新整合到IT架构其余部分的长期需求放在同一个地方。毕竟，你不希望IT创新成为未来的自动化孤岛。

如何处理"DIY IT"?

DIY IT(自己动手的IT)又叫"影子 IT"、"不受管束的IT"和"停止IT，你让我很头痛!!!!"，这是众多CIO竭尽全力想要杜绝的问题。

这就如同克努特国王命令潮水不要进到屋子里一样。

不管怎样，与其说DIY IT会带来问题，不如说它会带来机会，因为它大幅提升了公司的IT能力，同时却没有增加IT支出，或至少没有增加可见的IT支出。

总体来说，DIY IT的弊端是可以避免的。通常，需要IT部门在技术咨询方面提供一点支持，就能确保遵守IT的架构标准;相应地，IT架构职能部门获得所需的文档，可防止DIY IT成为影子IT。

这使得支持DIY IT成为可以轻松融入IT架构功能的另一个IT 实践。

结语

IT部门要有能力，就必须使用精心设计、定义，以及记录下来的流程和实践来完成工作。CIO要负责所有这些，但实际上他无法亲自指导超过三个流程的转型。

在大多数IT部门，最需要CIO个人领导力的三个流程领域是求助台、应用软件支持和IT架构管理。做好这三方面，IT就会成功，而且是明显的成功。

其前提是IT运营也大放异彩，这就是为什么颇为矛盾的是，CIO应该确保委派这项重任。如果你不这么做，就没有足够的精力来完善这三大流程。