CIO们在流程优化上都犯了什么错误？

作为CIO，你所做的很多事情都是设计东西，这个时候你就不会去监督其他设计东西的人，或者，这个时候你就不会去确定每个人设计的东西是否按照应有的方式组合在一起。

无论设计什么，都有一些通用的规则来管理好的设计。最著名的可能就是一句来自伟大建筑师路易斯·沙利文的格言，即形式服从功能，而鲜为人知但同样重要的一句话来自爱德华兹·戴明：要优化整体，我们就必须对部分进行次优化。

无论设计什么，是小工具、软件、组织还是流程，这都很重要，而且这也就可以理解为什么这么多CIO在优化上犯了错。

从队列到队列：隐藏的进程瓶颈

如果CIO可以靠一技之长谋生的话，那也许就是流程优化了。这对IT发挥自己的作用来说至关重要，而且IT所做的很多工作也都是为了帮助业务经理优化他们的流程。

IT内部和外部的流程优化人员拥有丰富的框架和方法可以使用，其中精益（Lean）方法是最受欢迎的，所以让我们用这个方法来举例。

精益思想对于流程优化做出的最重要、但最不被认可的贡献，可能就是认为：流程不是从一个盒子流到下一个盒子、再到下一个盒子的任务集合。

相反，流程是从队列到队列、再到队列的任务，这其中的差别看起来可能是很细微的，但却是优化整体与优化整体部分导致不同的结果的原因之一。这听起来似乎很学术，或者是某种IT禅理，但了解这其中的差异就是掌握流程优化的一个关键。

想象一下，你正在管理一个项目，这个项目需要新的服务器才能继续进行下去，假设目前IT还没有完全云化并且仍然有服务器和数据中，你按照程序发送请求到IT请求队列。

稍微简化一下如下图所示：

这是一个简单的流程。负责每个步骤的团队很久以前就优化了处理其职责的程序，总工作量和流程周期时间是相同的——对于这个假设的例子来说，大约需要8小时，或者项目计划表上的一天时间。

但是用上面这种盒型图展现这个流程是错误的，实际流程看起来更像下面这个：

流程中的每个步骤都作为先进先出(FIFO)队列进行管理，只有当请求流经队列并弹出以进行处理时，团队才会处理请求。总工作量与盒型图中预估是是相同的，但是周期时间包括了工作时间和排队时间——对于这个模型化的流程来说，大约需要5天。

实际分析要比这个更复杂。通常，某一个步骤最终会变成瓶颈。队列中的工作量堆积起来，而其他队列却闲置着，被接收了来自多个来源请求的所有队列抵消。但原理是不变的，改变的只是模型的复杂性。

这是真实的，而不仅仅是理论。就在几年前，一个客户的队列大小比上面描述的还要长得多，因为他们的团队等待着上级批准他们安装所需的服务器，因此遭遇了长达数月的项目延迟，即便是一台普通的服务器，需要花费在采购、配置和安装上的精力也并不比上图描述的少。

根本原因是什么呢？负责采购、网络管理、软件安装、质量保证和部署的经理们都把他们部门工作进行了梳理，以最大限度地提高员工利用率和吞吐量。

他们优化了自己这部分，但却是以牺牲每个项目的整体为代价的。

消除外部因素

对于DevOps拥护者来说，他们能够立即认可并接受的解决方案，就是把IT基础设施分析师纳入核心项目团队，更重要的是，把基础设施任务（例如配置服务器）纳入到每个项目的工作计划表中，根据产品需要设定开始日期和截止日期。

这样改变之后，服务器构建就变成了项目计划的一个组成部分，而不是项目经理无法控制的外部因素。

作为交换，CIO必须接受，如果项目要在预算范围内按时交付的话，IT组织的其他成员在工作管理上可能会有所松懈。员工利用率目标不会也不应该接近100%。（专业提示：花一些时间研究Eliyahu Goldratt的关键链项目管理方法，可更深入地了解这一点。）

MBO的崩溃

优化/次优化的问题不仅仅适用于流程设计，以管理层薪酬为例。

过去，目标管理(MBO)是一种主流的理论，即如何通过充分利用组织中的每一位经理来充分利用整个组织，该理论的致命缺陷在于，未能认识到以牺牲整体为代价来优化部分的会导致不可避免、但意想不到的后果。

MBO的工作原理（或者说失败原理更准确）顾名思义，公司高管为每位经理分配了一个或多个目标。因为任务更加清晰了，所以他们开始以偏执的热情去完成这些目标，而不理会组织内部其他任何经理需要完成哪些目标。

现代组织因为无法相互协作而遭受所谓“孤岛思维”之苦，这就是MBO时代的余毒。

给服务台提供无效帮助

正如有人曾经说的（实际上每个经理在谈到这个话题时都会这么说），没有完美的组织结构图。戴明提出的优化/次优化原则是导致组织结构图存在缺陷的一个关键因素。

以典型的服务台和服务台在IT组织设计中所处的位置为例。服务台会针对第一次最终用户联系和服务台第一次做出响应之间的延迟设置服务级别目标，以及针对解决最终用户问题所需时间设置目标，有时候还会针对每次事件最小化成本设置一个目标。

考虑到处理每个报告的事件包括记录该事件所花费的时间，以及尝试解决事件所花费的时间，或者将其交给不同IT团队来处理事件所花费的时间。

服务台达到初始响应服务水平一个最简单的方法，就在初始响应期间尽可能少做，尽可能快地处理每个事件。这让服务台的分析员可以自由地接听下一个电话，而不会缠身于试图解决他们无法解决的问题中。或者，通过把问题导向给更专业的部门，相比服务台分析员试图自行解决来说，事件可以得到更快速的解决。

但是，这种方法却让服务台分析员永远无法学会下一次遇到类似问题该如何处理。虽然服务台的成本降低了，但代价是分散了高价人才对当前优先事项的注意力，从整体价值的角度来看，这些优先事项可能更重要。

优化服务台最终导致成本不受约束和责任转移。事件管理的总成本与服务台自身成本的降低是成正比的。

要优化整体，你就必须对部分进行次优化。这听起来可能并不具体也不务实，但你不要因此望而却步。如果你想要得到最好的结果，就要确保参与交付的每个人都知道他们应该扮演什么角色。

而且，没有人会因为合作而受到惩罚的。