优化工作经常与一个基本原则相冲突：要优化整体，必须对部分进行次优化。

作为一名首席信息官，你做的很多事情都是设计东西，而这是你不监督其他设计东西的人的时候。或者，当你不能确保每个人设计的东西都符合它应该的方式时。

无论设计的是什么，都有一些通用的规则来管理好的设计。最著名的可能是伟大的建筑师路易斯·沙利文的格言，即形式遵循功能。不太为人所知，但同样重要（至少在我们的上下文中）的是W.Edwards Deming提出的一个：为了优化整体，我们必须对部分进行次优化。

无论设计的是什么，无论是小工具、软件、组织还是流程，这都很重要。这是理解为什么这么多首席信息官在优化过程中出错的关键。

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

如果首席信息官们能靠一个技巧谋生，那么流程优化很可能就是这样。这对It很好地履行自己的职责至关重要，而且它的许多工作都是为了帮助业务经理优化他们的流程。

IT内部和外部的流程优化器拥有大量的框架和方法。精益是最流行的，所以让我们用它来说明这一点。

也许精益思想对流程优化领域做出的最重要但最不被认可的贡献是，流程不是从一个盒子流向下一个盒子的任务集合。

相反，它们是从一个队列流向另一个队列的任务。这种差异似乎很微妙，但这是优化整体与优化整体的部分产生不同结果的原因之一。这听起来像是学术上的胡说八道，或是IT koan，但理解这种差异是掌握过程优化的关键。

听我说完。

假设您正在管理一个需要新服务器才能继续的项目，假设目前它还没有完全云化，仍然拥有服务器和数据中心。您按照过程向IT请求队列提交请求。

稍微简化一下，下面的框到框视图看起来像下图：

这是一个简单的流程。负责每个步骤的团队很久以前就优化了解决其职责的程序。总的工作量和过程周期时间是相同的-对于这个假设的例子，大约是8小时，或者项目进度表上的一天。

但是，这个过程的框到框视图是错误的。实际过程看起来更像下图：

过程中的每个步骤都作为先进先出（FIFO）队列进行管理。只有当请求通过队列并弹出进行处理时，团队才会处理请求。总工作量与箱到箱视图中估计的工作量相同。但是，周期时间包括工作时间和排队时间-对于这个建模过程，大约5天。

实际分析比这更复杂。通常，一个步骤会成为瓶颈；当其他队列耗尽时，工作在其队列中堆积，由接收来自多个源的请求的所有队列平衡。但这并没有改变原理，只是改变了模拟的复杂性。

这是真实的，而不仅仅是理论。就在几年前，一个客户机的队列大小比上面描述的要长得多，当他们的团队等待安装他们所依赖的经批准的服务器时，他们经历了多个月的项目延迟，尽管一个典型的服务器不需要比上面描述更多的精力来获取、配置和安装。

根本原因？负责采购、网络管理、软件安装、质量保证和部署的管理人员都组织了各自部门的工作，以最大限度地提高员工利用率和吞吐量。

他们-部分-以牺牲每个项目的整体为代价优化了自己。

消除外部性

DevOps的拥护者将立即认识到并接受的解决方案是将IT基础设施分析师纳入核心项目团队，更重要的是，将基础设施任务包括在内，例如在每个项目的工作计划中设置服务器，根据需要其工作产品的时间分配开始日期和到期日期。

随着这一变化，服务器构建成为项目进度的一部分，而不是项目经理无法控制的外部因素。

作为交换，首席信息官必须接受这样一个事实：如果项目要在预算范围内按时交付成果，IT组织的其他部门就必须允许他们的工作管理有一些松懈。员工利用率目标不会也不应该接近100%。（专业提示：投入一些时间研究Eliyahu Goldratt的关键链项目管理方法，以更深入地理解这一点。）

目标管理的崩溃

优化/次优化问题不仅仅适用于工艺设计。以管理层薪酬为例。

在过去，目标管理（MBO）是一种流行的理论，即如何通过从组织中的每一位管理者身上获得最大收益，从而从组织中获得最大收益。它的致命缺陷也是未能认识到以牺牲整体为代价优化部分的不可避免但意外的后果。

它的工作方式-失败-是一种更好的说法-顾名思义，公司的高管给每个经理分配了一个或多个目标。管理者们对他们应该完成的任务更加清晰，他们开始以一种偏执狂的热情来完成任务，不受组织中任何其他管理者实现自己目标所需的干扰。

现代组织因其居民所称的“筒仓思维”而无法合作，这是MBO时代的遗迹。

无助地帮助服务台

正如有人曾经说过的——或者实际上，几乎每一位经理都曾说过——只要一提到这个问题，就没有完美的组织结构图。Deming的优化/子优化原则是组织结构图缺陷的关键因素。

以典型的帮助台及其在组织设计中的位置为例。它为第一个终端用户联系人和服务台的初始响应之间的延迟制定了服务级别目标；也是解决最终用户问题所需时间的目标。在某种程度上，还有一个目标，就是将每次事故的成本降至最低。

计算处理每个报告的事件所花费的时间，包括记录事件的时间，以及尝试解决事件的时间或通过将事件移交给不同的it团队来处理事件的时间。

帮助台满足其初始响应服务级别的最简单方法是在初始响应期间尽可能少做，尽可能快地处理每个事件。这使服务台分析师可以自由地接听下一个电话，并避免在解决他们无法处理的问题时陷入困境。更好的是，通过将问题导向具有更多专业知识的部门，事件的解决速度将快于帮助台分析师自己解决问题的速度。

可悲的是，这种方法也确保了服务台分析师将来永远不会学习如何处理类似的问题。虽然这也降低了服务台的成本，但这样做的代价是将高价人才从他们当前的优先事项中转移出来，从整体价值的角度来看，这些优先事项可能更重要。

优化服务台最终成为无约束的成本和责任转移。事件管理的总成本随着服务台自身成本的减少而增加。

要优化整体，必须对部分进行次优化。这一指导可能听起来不具体、不实用，但不要让其深奥的含义让你望而却步。如果你想要最好的结果，请确保参与交付这些结果的每个人都知道它们应该是什么。

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

本文：https://cioctocdo.com/what-cios-get-wrong-about-optimization