IT服务(运维)管理实施的几个要点--第二章 人员和组织架构

子曰“没有合适的人”

在流程化的管理模式下,最容易步入的一个误区是按流程设计一个“理想的”组织架构,然后对应于这个架构对人员进行评估、培养,甚至是更换。我见过很多试图采用这种方式,希望能把IT服务质量一步提高到位的客户。实践证明,凡是这么做的企业,往往要面临一个时间非常长(有的时候是几年)的动荡时期,而且往往最终结果并不尽如人意。原因很简单,适应一个企业的人,首先是适应这个企业的文化。有什么样的企业文化就有什么样的人,反之通过观察企业的一部分员工(样本数量足够大)就可以对这个企业的文化有一定的了解。

所以,核心问题不是“没有合适的人”,而是怎么把现有的人,以及未来注定要适应这个企业文化的新人,给“用合适”。从这个角度来说,调整组织架构不是一个粗糙的过程,而是需要认真规划,在规划的过程中,要参考企业当前现状,以及IT服务部门能承受的组织动荡程度。

在这里,可以根据常见的不同组织形态举几个例子:

组织形态一:纯技术型组织,一个或多个小的团队,每个团队不超过10人。每个团队由技术权威担任该团队的负责人。团队内部和团队之间用天然的技术实现过程和天然的技术责任分界来实现某种天然的流程。

这种组织结构在调整的过程中,经常面临如下几个难点:

  1. 技术人员对管理流程不屑一顾,认为管理流程是画蛇添足。
  2. 如果不是技术权威担任管理人员,很容易遭到技术人员的反感甚至对抗。
  3. 技术人员习惯于使用自己熟悉的技术,在探索学习新技术时,要么过于大胆(比如直接将未经完整测试的新技术用于生产环境),要么故步自封。
  4. 技术人员容易混淆因未严格执行流程而引发的问题和技术不到位而引发的问题。从而影响IT服务质量的持续改进提高。
  5. 因为某些产品和技术掌握在特定的人手中,因此造就了一些“特殊员工”,从而为组织结构调整造成巨大困难。

如果不想组织结构调整引发大范围的人员流动,针对这种纯技术组织,比较好的方式是引入一个“助理”团队。这些“助理”,分散在每个技术团队当中,但是又归属一个相对独立的“流程经理”进行管理。这些“助理”主要完成IT服务中关于管理流程的部分。

这个“助理”团队引入时,不会受到技术团队很大的抵触,大多数时候是受欢迎的。因为,这些人不会直接“干涉”他们的日常工作,更多的是进行记录和传递信息(技术人员很少喜欢进行记录和传递信息之类的工作)。但随着日常工作的开展,聪明的技术人员会发现,他们的很多工作是这些“助理”从“领导”处转来的,而且“助理”还有权力评价并向上级汇报自己的工作。于是,技术人员逐渐体会到,在一个按照流程进行管理的组织中,遵循流程的重要性。这种方式可以实现一种相对平滑的由技术型组织到流程型组织的转换。

组织形态二:按系统分类的垂直型组织。在ITIL盛行之前,比较典型的划分运维团队的做法是将几个关联性比较强的系统划分给一个小组进行管理。粗糙一点的,在这个小组当中配备少数几个“全能”的工程师(同时是操作系统管理员或DBA出身),然后让工程师与开发团队、第三方软硬件维保工程师一起“搞定”所有的问题。细致一点的,在这个小组中配备系统工程师、DBA、应用运维工程师,甚至是网络工程师和中间件工程师,从而希望该小组能快速的处理大多数问题。

按系统分类的垂直型组织,主要的问题是在系统量比较多的时候,在各个系统组之间进行沟通,相对比较复杂。因为,各个系统组之间不了解对方系统的情况,一旦发生问题,很难找到问题根源;通过临时性措施(例如:重启)解决问题后,后续分析和追踪问题也很困难。

尽管垂直型组织有上述问题,但是根据经验来看,如果数据中心比较小(重要系统在10个以下),而且运维服务质量要求不太高的情况下,采用垂直型组织(需要配备合理的流程),有利于节省成本,并减少大多数故障处理时间。

如果需要把垂直型组织改进为ITIL描述的,按同类技术分组+流程的矩阵型组织,主要的问题是人员重新分组,以及接受新的系统的知识所带来的压力。特别在很多企业,因为应用系统来源广泛而复杂,许多系统之间的差异很大,甚至对于常用的第三方产品软件的使用也千差万别,所以同类技术分组并不是一件容易的事情。

做这种巨大的组织结构调整,事先需要对技术人员进行深入培训,让他们了解日后需要管理的那些系统,掌握其中的窍门。根据经验,从系统分组转为技术分组,从最容易到最难依此是是监控岗、网络岗、安全岗、操作系统管理员岗、数据库岗、中间件岗、应用运维岗。实际上,如果应用运维做的比较深入的话(例如:可以修改因程序缺陷导致的数据错误,甚至是修改程序BUG),那么应用运维岗是很难转为技术分组的,或者即便转为技术分组,实际上也在其中分成几个不同的小组,每个小组各管几个应用。

做如此复杂的调整一定要有负责流程的组,有两种解决方案,分别针对较大的数据中心和较小的数据中心。针对较大的数据中心,往往需要设立一个服务台,该部门负责日常流程的执行和跟踪,例如:服务请求、事件、变更和问题处理流程;另外,还需要设立一个流程管理岗或部门,用于对流程本身进行回顾和改进。在较小的数据中心,往往把上述两种职责统一到服务台,这样服务台即负责流程执行,又负责流程改进。

 

需要特别提示的是,有的时候因为一些“其他”原因,导致有一些“特殊”员工不好安排。常见的做法是安排这些员工负责安全或担任流程经理。这个方式是不太可取的,因为安全岗对于整个数据中心的安全运维,起到非常关键的作用,这个岗位用人不当,一旦出现安全事故,悔之晚矣。而流程经理是数据中心运维服务质量改进提高的关键,尸位素餐将导致数据中心整体效率的低下,甚至员工缺乏主动性。根据经验来看,“特殊”员工本身一般是有主动提高自己的意向的,但是被放在一个自身能力不足以承担职责的岗位上时,只能依靠“特殊性”在组织中混日子。我一般会建议,安排这些“特殊”员工到具体技术岗位,甚至可以担任某些技术组的管理岗。这样在有其他技术人员辅助的前提下,出问题,或者出大问题的概率会比较低,风险可控。

 

转载于:https://www.cnblogs.com/xulong-itsm/p/8184642.html

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值