CIO在优化方面犯了什么错误

CIOAge
如果CIO可以靠一种手段谋生,那一定非流程优化莫属。它对于IT很好地发挥自己的作用至关重要,而且IT所做的很多工作也是为了帮助业务管理者优化他们的流程。

作为CIO,你所做的很多事情都是设计东西,与此同时,你并没有监督其他设计东西的人,或者,不确定每个人设计的东西是否正按照应有的方式组合在一起。

无论设计什么,都有一些通用的规则来管理好的设计。其中,最著名的可能是伟大的建筑师路易斯·沙利文(Louis Sullivan)的格言:形式服从功能。鲜为人知但同样重要的是W. Edwards Deming所说的:要优化整体,我们必须同时对其组成部分进行次优化。

无论设计的是什么——小工具、软件、组织还是流程——这一点都很重要。这也是理解为什么这么多CIO在优化方面犯错的关键。

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

如果CIO可以靠一种手段谋生,那一定非流程优化莫属。它对于IT很好地发挥自己的作用至关重要,而且IT所做的很多工作也是为了帮助业务管理者优化他们的流程。

IT内部和外部的流程优化人员拥有丰富的框架和方法可供使用。精益(Lean)是最受欢迎的,所以让我们用它来说明这一点。

“精益”思想对流程优化世界做出的最重要但最不被认可的贡献可能是“流程不是从一个框(box)流到下个框再到下个框的任务集合”。

相反地,它是从队列到队列再到队列的任务。这两者的差异可能看起来很微妙,但这正是优化整体与优化整体的各个部分产生不同结果的原因之一。了解这种差异是掌握流程优化的关键。

想象一下,你正在管理一个需要新服务器才能继续进行的项目,假设目前IT还没有完全“云化”并且仍然拥有服务器和数据中心。你按照流程向IT请求队列提交请求。

稍微简化一下,遵循的框到框(box-to-box)视图如下所示:

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

但是该流程的框到框视图是错误的。实际流程看起来更像下图:

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

实际的分析比这更复杂。通常情况下,会有一步最终成为瓶颈:工作在其队列中堆积,而其他队列却清闲无事。

这种情况是真实存在的,而不仅仅是理论。就在几年前,一个客户经历了比上述更长的流程瓶颈,导致项目延迟数月,起因是他们的团队等待安装经过批准的服务器。

其实,这个过程原本并不需要耗费如此多的时间。但负责采购、网络管理、软件安装、质量保证和部署的经理都组织了部门的工作,以最大限度地提高员工利用率和吞吐量。结果就是,他们(作为部分)以牺牲每个项目的整体为代价来优化自身。

消除外部因素

DevOps拥护者将立即认可并接受的解决方案是将IT基础架构分析师纳入核心项目团队,更重要的是,将基础架构任务包括在每个项目的工作计划中,例如设置服务器、根据何时需要他们的工作产品来分配开始日期和截止日期。通过这种更改,服务器构建将成为项目计划的一部分,而非项目管理者无法控制的外部因素。

作为交换,CIO必须接受,如果项目要在预算范围内按时交付结果,IT组织的员工利用率目标不会也不应该接近100%。(专业提示:花一些时间研究 Eliyahu Goldratt 的关键链项目管理方法,以便更深入地了解这一点。)

目标管理(MBO)的崩溃

优化/次优化问题不仅仅适用于流程设计。以目标管理(MBO)为例。

过去,目标管理 (MBO) 是一种流行的理论,关于如何通过充分利用组织中的每一位管理者来充分利用组织。它的致命缺陷在于未能认识到以牺牲整体为代价来优化部分的不可避免且意想不到的后果。

顾名思义,它的工作方式是公司的高管会为每位管理者分配一个或多个目标。由于目标极度清晰明确,管理者们开始以偏执的热情去完成它们,完全不理会组织中任何其他管理者为实现自身目标而提出的需求。

现代组织因无法协作而遭受的“孤岛思维”正是MBO时代的遗留产物。

沦为服务台“接单员”

正如有人曾经说过的那样——或者实际上就像每个管理者在谈到这个话题时所说的那样——没有完美的组织结构图。Deming的优化/次优化原则是组织结构图缺陷的关键因素。

以经典的服务台及其在IT组织设计中的位置为例。考虑到接听每个报告事件和记录它所花费的时间,以及尝试解决它所花费的时间,服务台想要达到其初始响应服务水平最简单的方法就是在初始响应期间尽可能少做,尽可能快地处理每个事件。这使得服务台分析师可以自由地接听下一个电话,并且不会陷入无法解决问题的困境。更好的方法是,通过将问题导向至具有更多专业知识的部门,与服务台分析师试图自行解决问题相比,事件将得到更快的解决。

可悲的是,这种方法也使得服务台分析师永远无法学会如何处理类似的问题。虽然它降低了服务台的成本,但这样做的代价是分散了高价值人才对当前优先事项的注意力,从整体价值的角度来看,这些优先事项可能更重要。

优化服务台最终成为了一种不受约束的成本和责任转移的实践。事件管理的总成本与服务台自身成本的降低成正比。

要优化整体,你必须对部分进行次优化。这种指导建议听起来可能并不具体和务实,但不要被其深奥的表象吓得望而却步。简单地说,如果你想要最好的结果,请确保参与交付这些结果的每个人都知道他们应该怎么做。此外,告诉他们,没有人会因合作实现这些目标而受到惩罚。

责任编辑:姜华 来源: 企业网D1Net
相关推荐

2023-07-14 07:05:27

优化首席信息官IT

2022-09-28 08:40:52

CIO工具软件

2020-07-01 07:38:38

SQL数据库程序员

2010-05-24 09:11:13

Facebook隐私政策

2022-03-29 06:48:59

CIO环境可持续性IT领导者

2016-10-18 10:55:03

java调试问题

2019-11-07 21:17:07

数字化转型公司

2023-08-01 10:41:27

分派IT工作CIO

2021-06-11 09:33:33

索引SQL语句

2020-03-09 16:43:06

脚本语言浏览器JavaScript

2022-12-07 11:16:32

2024-01-19 15:17:51

2013-07-09 13:52:31

程序员Android

2021-08-05 09:00:15

区块链数字货币加密货币

2018-11-21 09:38:52

企业云计算优化

2021-12-09 22:22:57

物联网私有云数据

2016-03-17 16:57:39

SaaSSaaS公司指标

2020-11-02 12:47:56

性能优化

2014-11-18 11:02:56

2021-12-15 10:47:30

物联网私有云公有云

51CTO技术栈公众号