摘要：作为首席信息官，所做的很多事情都是设计东西，而那时不会监督其他设计东西的人电。或者，当不确定每个人设计的东西是否按照应有的方式组合在一起时。

    优化工作经常违反一个基本原则：要优化整体，必须对部分进行次优化。
　　
　　作为首席信息官，所做的很多事情都是设计东西，而那时不会监督其他设计东西的人电。或者，当不确定每个人设计的东西是否按照应有的方式组合在一起时。
　　
　　无论设计的是什么，无论是小工具、软件、组织还是流程，这都很重要。这是理解为什么这么多首席信息官优化错误的关键。
　　
　　从队列到队列：隐藏的进程瓶颈
　　
　　如果首席信息官可以靠一个技巧谋生，那么流程优化很可能就是这样。它对于IT很好地发挥自己的作用至关重要，而且IT所做的很多工作也是为了帮助业务经理优化他们的流程。
　　
　　IT内部和外部的流程优化人员拥有丰富的框架和方法可供使用。精益是最受欢迎的，所以让我们用它来说明这一点。
　　
　　精益思想对流程优化世界做出的最重要但最不被认可的贡献可能是流程不是从一个盒子流到下一个盒子再到下一个盒子的任务的集合。
　　
　　相反，它们是从队列到队列再到队列的任务。差异可能看起来很微妙，但这是优化整体提供与优化整体部分不同的结果的原因之一。这听起来像是学术呼哈或IT公案，但了解这种差异是掌握流程优化的关键。
　　
　　想象一下，正在管理一个需要新服务器才能继续进行的项目，假设目前IT还没有完全云化并且仍然拥有服务器和数据中心。按照程序向IT请求队列提交请求。
　　
　　这是一个简单的流程。负责每个步骤的团队很久以前就优化了处理其职责的程序。总工作量和流程周期时间是相同的——对于这个假设的例子，大约是8小时，或者项目计划中的一天。
　　
　　流程中的每个步骤都作为先进先出(FIFO)队列进行管理。只有当请求流经队列并弹出以进行处理时，团队才会处理请求。总工作量与盒对盒视图中估计的相同。但是周期时间包括工作时间和排队时间——对于这个模型化的流程，大约五天。
　　
　　实际的分析比这更复杂。通常，一步最终会成为瓶颈。工作在其队列中堆积起来，而其他队列干涸，由接收来自多个来源的请求的所有队列抵消。但这不会改变原理，只会改变模拟的复杂性。
　　
　　这是真实的，而不仅仅是理论。就在几年前，一个客户的队列大小比上面描述的要长得多，因为他们的团队等待安装他们所依赖的经批准的服务器，因此经历了数月的项目延迟，即使典型的服务器不需要更多比上面描述的更努力获取、配置和安装。
　　
　　根本原因？负责采购、网络管理、软件安装、质量保证和部署的经理都组织了部门的工作，以最大限度地提高员工利用率和吞吐量。
　　
　　消除外部性
　　
　　DevOps拥护者将立即认可并接受的解决方案是将IT基础架构分析师纳入核心项目团队，更重要的是，将基础架构任务包括在每个项目的工作计划中设置服务器、分配开始日期和截止日期日期取决于何时需要他们的工作产品。
　　
　　通过这种更改，服务器构建成为项目计划的一部分，而不是项目经理无法控制的外部因素。
　　
　　作为交换，首席信息官必须接受，如果项目要在预算范围内按时交付结果，IT组织的其他成员将不得不在工作管理上有所松懈。员工利用率目标不会也不应该接近100%。（专业提示：花一些时间研究EliyahuGoldratt的关键链项目管理方法，以便更深入地了解这一点。）
　　
　　MBO的崩溃
　　
　　优化/次优化问题不仅仅适用于流程设计。以管理层薪酬为例。
　　
　　过去，目标管理(MBO)是一种流行的理论，即如何通过充分利用组织中的每一位经理来充分利用组织。它的致命缺陷还在于未能认识到以牺牲整体为代价来优化部分的不可避免但意想不到的后果。
　　
　　企业的高管为每位经理分配了一个或多个目标。经理们，由于他们应该完成的任务更加清晰，他们开始以偏执的热情去完成它，不受组织中任何其他经理为实现自己的目标所需要的干扰而分心。
　　
　　现代组织因无法协作而遭受其居民所谓的“孤岛思维”之苦，这是MBO时代的遗迹。
　　
　　无奈地帮助服务台
　　
　　正如有人曾经说过的那样，或者实际上就像每个经理在谈到这个话题时所说的那样，没有完美的组织结构图。戴明的优化/次优化原则是导致组织结构图缺陷的关键因素。
　　
　　以经典的帮助台及其在IT组织设计中的位置为例。它为第一次最终用户联系和帮助台的初始响应之间的延迟设置了服务级别目标；也是解决最终用户问题所需时间的目标。在某个地方，还有一个目标是最小化每次事件的成本。
　　
　　考虑到处理每个报告的事件包括记录它所花费的时间，以及尝试解决它所花费的时间或通过将其交给不同的IT团队来摆脱它所花费的时间。
　　
　　帮助台达到其初始响应服务水平的最简单方法是在初始响应期间尽可能少做，尽可能快地处理每个事件。这使帮助台分析师可以自由地接听下一个电话，并且不会陷入试图解决他们没有能力处理的问题的困境。更好的是，通过将问题导向具有更多专业知识的部门，与帮助台分析师试图自行解决问题相比，事件将得到更快的解决。
　　
　　可悲的是，这种方法还确保帮助台分析师在未来永远不会学习如何处理类似的问题。虽然它还降低了服务台的成本，但这样做的代价是分散了高价人才对当前优先事项的注意力，从整体价值的角度来看，这些优先事项可能更重要。
　　
　　优化服务台最终成为一种不受约束的成本和责任转移的练习。事件管理的总成本与服务台自身成本的降低成正比。
　　
　　要优化整体，必须对部分进行次优化。这个指导听起来可能并不具体和务实，但不要让它深奥的暗示让人望而却步。如果想要最好的结果，请确保参与交付这些结果的每个人都知道他们应该是什么。
　　
　　编辑：Harris