CIO切忌做“大厨师”

　　笔者有机会接触一些企业管理者，在跟他们交谈的时候笔者发现一个很不好的现象。就是很多企业的CIO都是“大厨师”。当这个大厨师走了的时候，企业损失的不仅仅是一个CIO而已，随之失去的还有这个经验。当这个CIO或者其他信息化关键技术人员离开了之后，企业的信息化管理就很难推进下去。虽然一些企业管理者或者CIO也知道“大厨师”的危害，但是苦于没有好的良策。笔者在平时工作中也是非常反对大厨师的做法。在日常工作中也采取了一些措施，来防止大厨师现象产生。笔者下面的这些方法可能对大家有所帮助，有需要的读者可以参考借鉴一下。

　　一、扩大信息化管理软件的关键用户。

　　对于CIO来说，企业内部的大厨师有很多，其中信息化管理软件的关键用户就是其中之一。因为像CRM、ERP等类似的综合型管理软件，当某个模块的关键用户离职后，在短时间内很难有人能够接替。往往需要一个月到三个月的长时间培训后，其他员工才能够成为这个系统的关键用户。而企业在信息化项目初始培训的时候，一方面出于“小班化教育”的需要，另一方面也没为了减少信息化项目实施对企业正常生产经营的影响，为此不会抽调很多多员工进行项目的培训。故在项目初期，软件的关键用户往往每个模块只有一个人而已。如此这个人就成为了信息化管理软件中的“大厨师”。等到这个大厨师离开了企业之后，企业就很可能会失去这个招牌菜;或则其他人来烧这个菜的话，口味也会不地道，受到客户的挑剔。那该如何消除这种关键用户带来的负面影响呢?

　　笔者以前也为这个问题苦恼过，不过现在还好已经克服了这个难题。笔者是通过两个手段来处理这个问题的。首先，由于项目初始化培训的时候，确实抽不出多余的人来进行信息化项目的培训，否则的话会对现有的生成经营造成很大的影响。为此在项目刚开始培训的过程中笔者也只能够保证每个模块一个人参加培训。不过在这个培训的过程中，笔者是非常重视收集相关的资料，为后续笔者对其他员工进行培训准备材料。如笔者会向实施顾问索要他对企业进行培训的PPT文档;在培训过程中，对大家的一些疑问与争论也会一一的纪录下来，这些都是笔者以后培养新的关键用户的很好素材。其次这笔宝贵资料收集完毕之后，笔者在等到上线后就会马上落实对其他用户进行培训，争取每个模块或者部门多培养出几个关键用户出来。如此即使有某个关键用户离职了，那么也马上有人能够顶替上来，而不会对因为某个大厨师的离职而导致无人来做这个招牌菜。

　　笔者在关键用户培养中，采取的是上岗证的做法。即通过一定的培训然后对员工进行考核，考核通过后员工就可以取得一本上岗证。如笔者在复杂CRM项目的时候，就大概花了一年的时间让全部CRM相关的操作人员都取得了上岗证。如此虽然这次经济危机企业不得不降薪裁员，企业为此流失了不少的“大厨师”。但是由于笔者前期准备充分，对这个信息化项目基本上没有带来多大的负面影响，CRM等信息化管理软件仍然能够正常运转。所以，笔者建议各大企业的CIO们，在平时一定要注意扩大信息化管理软件的关键用户。至少信息化管理软件的每个模块(每个招牌菜)都要有两个以上的关键用户(大厨)。如此当某个大厨走人的话，这个招牌菜才能够不失传，信息化管理软件才能够不受其影响。

　　二、人可以走，请把经验留下。

　　为什么一个大厨的离去，会对一家企业产生这么大的影响着?笔者认为，这主要是因位其离职，带走的不光光是一个人而已;还有其工作以来经验下来的经验。如CIO下面可能有一个网络管理员，其复杂维护文件服务器、交换机、路由器等网络设备。其离职后CIO要招一个技术过硬的网络管理员不是什么难事。困难的是其如何才能够马上上手来管理这些设备?如何把这个适应期尽量缩短?如何避免在这个交接过程中出现重大的失误?这些是非常困难的。因为这些内容往往跟网络管理员的技术没多大关系，而主要跟以前网络管理员的经验有关。为此CIO如果留不住这个人的话，那就要把其以前网络管理的经验留下。有了这些经验性的东西，那么以后就可以帮助新的管理员进行顺利过程过渡。

　　不过笔者觉得部分CIO在这方面存在着一些误区。他们以为在网络管理员准备离职的时候，在进行这个经验的交接就可以了。而不需要未雨绸缪，在平时的时候就注重这个经验的积累。就笔者个人而言，这个想法是常错误的。当企业一个员工在离职的时候，很少有人会把自己以前的工作经验共享出来。他们不搞一些破坏已经不错了，你还要他们共享经验，那真的很难。为此笔者都是在平时的时候就注意手下技术人员经验的积累，免得到时候手忙脚乱。

　　如就拿上面笔者说到的的维护文件服务器的网络管理员来说，笔者自认为在这方面做的还过得去。笔者在企业中设计了一份工作联络单。当有员工(包括网络管理员)提出某个需要之后，如需要在工业设计与销售部门之间设置一个相互可以访问与修改权限的文件夹(通常情况下每个部门只对自己部门或者自己小组的文件夹具有读写权限)，那么网络管理员在完成这项工作之后，还必须在工作联络单后面附上详细的解决方案。笔者只有看到这个方案后才承认他顺利完成了这项任务。如果其没有解决方案，即使其任务完成的最漂亮，其在考核的时候仍然不能够加分。而有了这份解决方案，那么即使以后这个网络管理员离职了，新的网络管理员也可以凭借这份资料迅速掌握文件服务器的部署情况。而可以避免因为不熟悉文件服务器的现有设置而给企业用户造成损失。在这个解决方案中，笔者要求包括四大部分的内容。一是用户的需求描述。这主要是为了当以后用户有类似的需求时，新的的“厨师”可以进行借鉴。二是具体的解决方案。笔者要求网络管理员把具体的实现过程要一五一十的在解决方案中体现出来，最好能够配合截图等说明。笔者对他们的要求是，至少要让笔者能够对照这些步骤也能够一一的实现。三是后续的测试方案。笔者认为需求实现后的测试是非常重要的。它可以反映出需求实现过程中欠缺考虑的地方或者需求中的漏洞。即使这些缺陷或者漏洞因为技术的限制暂时难以克服，那么这也会跟后续的维护提个醒。免得后面换了个负责人而不知道这个情况而造成不必要的损失。有了这些经验性的资料，即使以后这个网络管理员大厨走了之后，笔者也不用怎么担心。因为在短时间之内就有人可以凭着这些资料顺利完成过渡。从而可以把这个大厨流失的阵痛期缩短至最短时间。

　　不过CIO在做这件事情的时候，一定要注意技巧。不能够让下面的技术人员感觉到你是在过河拆桥，你是在剥削他们的经验。如果他们感觉到你这个Cio是有意在防备他们，那么即使他们按照你的要求写解决方案，也难免他们不在其中做手脚。就好像郭靖给西毒欧阳峰些九阴真经那样，中间把关键的点漏掉了或者把顺序颠倒了。那时这份资料反而会给其它员工带来误解。为此笔者建议，CIO在做这项工作的时候一定要注意技巧。如不能够在公司准备裁员的时候让员工补这些工作。如此的话，傻子都能够猜得到企业可能要拿他开刀了。如此他会真心给你准备这些解决方案吗?故在做这方面工作的时候，CIO最好从项目一开始就落实下去。而不是等到你对这个员工不满的时候，再要求他去做。否则的话，就会给这个员工造成一种错误的暗示，想你要赶他走一样。

　　笔者最后总结一句，大厨走了并不可怕。可怕的是后继无人;可怕的是其人走了，经验也带走了。企业管理中，这方面的例子已经举不胜举。为此CIO应该学会未雨绸缪，从一开始就最好最坏的打算。只有如此到事情真的发生时，才能够不手忙脚乱，才能够顺利过渡，才能够降低损失。