CIO要学会为项目制订应急计划

　　犯错无可避免，失败则不然;你可以弥补错误，但无法弥补失败。这是著名项目管理大师Jerry Madden退休后留下的项目管理至理名言。这也是笔者管理信息化项目的行为准则。作为一个合格的CIO，应该学会为那些高风险的计划或是任务准备应急预案和备选方案。在信息化项目管理中出现的任何问题都可以及时解决，所以CIO的应急方案一定要准备的很充分、很使用。如果CIO做不到这一点，那么CIO就可以换人了。下面可是有很多人在虎视眈眈的盯着你这个位置。CIO如果不能够为项目制订合理的、充分的应急计划，那么CIO很有可能位置不保。

　　那么CIO该如何在制作项目应急计划的时候，该注意些什么呢?笔者对此有以下几个建议，可供大家参考。

　　一、应急计划应该先取得别人的认同。

　　如企业实施某个信息化项目，需要对无聊定义编码原则。CIO把这个任务交给了研发部门经理负责，让他们在三天之内制订出一个物料编码原则。此时CIO就需要考虑，如果他们在三天之内交不出成果来，该怎么办呢?此时，笔者认为CIO应该先根据自己以前的工作经验结合公司的实际产品，预先想好一套编码规则。然后先跟总经理或者其他有这方面专业特长的人讨论一下。特别是这套编码规则的应急方案要得到总经等高层管理人员的认同。如果研发部门在三天之内拿出了一套合理的、大家都认可的编码规则，那么CIO准备的这套编码原则也就没有用的。但是如果他们没有在规定时间内提交编码规则，则CIO就可以拿出这个应急的编码原则，要求各个部门按照这个编码原则来执行。这主要是为了保障项目的进度。如果项目因为这个部门没有及时完成相关的工作而耽搁下来的话，对于企业的损失会比较大。

　　为此，应急方案应该预先得到管理者的认同。只有如此，在真的需要启动应急计划的时候，才可以切实的运作起来。如果没有他们的支持，那么这个应急计划即时很合理，但是如果其他员工由于种种原因不买账的话，这个应急计划就如同一纸空文，没有多少实际的价值。故笔者在日常工作中，制定完应急计划后，总会找人去确认这个方案的合理性。然后会找总经理等高层领导进行确认。如可以先做好企业内部联络书，让他们签字画押。然后等到需要遇到这个应急方案的时候，就可以马上拿出来用了。

　　二、应急方案贵在精，而不在多。

　　对于应急方案来说，贵在精而不在多。如以上这个编码原则这个方案来说，CIO不用准备多种编码原则。CIO只需要考虑企业的物料性质、产品种类、系统支持等因素，然后设计出一套到两套质量高的编码原则即可。也就是说，CIO不能够以为这个方案只是用来应急的，是否用的到还是另外一回事情。就忽视了应急方案的质量了。

　　首先应急方案精体现在符合企业的实际情况。就拿物料编码规则来说，不同企业物料性质、物料种类、物料数量不同，编码原则也肯定不同。为此CIO在编制编码原则应急方案的时候，可以参考其他公司的编码原则，特别是同行业的编码规则。但是不能够照搬全抄。在编码原则应急方案编制中，要能够结合企业自身的特点。如物料比较多，则可以对产品进行大中小类的划分等等。也就是说，在制定应急计划之前，CIO有必要先去考察一下企业当前的情况。只有了解企业实际情况时，CIO才能够对症下药，制定出合理的应急方案。应急方案绝不是照抄其他企业的方案。

　　其次，应急方案不用太多，一般一个即可。如果CIO实在没有把握的话，那么也可以设置两个应急方案。通常情况下，最多不要超过两个。因为有时候人就比较犯贱。当有的选择的时候，他们就会比较，就会挑三拣四。一会儿说这个不好，一会儿说那个不好。最后可能多个应急方案都会被他们推翻。相反，如果应急方案只有一个的话，他们没有挑了，那么他们就会被动的接受。所以应急方案本来就是为了应急用的，不用给企业员工太多的选择。选择多了，反而用户会犹豫不决。故应急方案贵在于精，而不在于多。CIO在准备应急计划的时候，通常情况下一个已足矣。

　　第三，应急方案应该随着实际情况而变更。当CIO制定好应急方案后，仍然要关注项目的进度。然后随着项目的进度而调整应急计划的内容。如就以这个编码原则为例。CIO在制定编码原则的应急计划之后，并不是说他可以高枕无忧了，反正他们如果按时没有完成任务的话，就可以按照这个应急计划来。就放弃对项目的追踪了。与此相反，CIO应该追踪这个编码原则制定的过程。因为在这个过程中，大家会相互讨论该如何制定编码原则;通过观点的碰撞，用户会提出一些编码原则制订中常见的错误，应该避免的误区等等。CIO通过追踪编码原则制订的过程，也可以了解这些信息。如此的话，CIO就可以看看自己的应急方案有没有这些明显的错误。如果有的话，要及时的调整过来。只有如此，这个应急方案才会逐渐完善起来。才会达到精的要求。

　　三、应急方案也需要细化。

　　在项目管理中，给员工分配工作时要细化。如要让每个员工拿到他们的任务时都知道自己该干些什么。而在做应急方案时也需要细化。至少要跟某项工作或者某个任务对应。太过于笼统的应急方案，就如同很大的任务一样，缺乏实际的可行性。

　　如某个CIO做过一个应急方案，内容是如果在两个星期之内没有整理好产品基本资料，就导入以前手工的基本资料?这个应急方案看起来很不错，但是内容却很空，缺乏执行的可能性。一方面，在数据库中存储数据，强调的是规范化。而手工填写的基本资料，及时采用了Excel等办公软件，其数据的规划化要求远远达不到数据库所规定的要求。如有些数据数据库规定是必须填写的，但是以前的资料可能有些数据漏填。这种情况下，这个数据是无法导入到信息化管理软件中的。再如数据库中会对重复记录进行控制，如产品信息不能够重复等等。但是在以前的信息库中，由于没有对此进行强制控制，而都是靠手工管理。故难免会存在一些重复的记录。把这些记录导入到信息化管理系统中，没有多少实际的利益。二是基础资料的整理包括好几部分内容，需要对现有的基本资料进行比较大的调整。如需要编制编码规则等等。故这么大的一个应急方案可执行性太差。

　　为此要把应急方案也细化。如在产品基本资料整理这一块，CIO可能会把这项工作分解为物料编码编制、产品信息格式定义、产品基本信息整理、产品基本信息核对、产品信息导入、系统核对等几个任务，然后交由对应的员工去完成。那么在制定应急计划的时候，也需要这么细分。如对于产品信息格式的定义，如果在规定的时间内员工不能给出一个大家认可的格式，那么就可以采用系统默认的格式等等。如在产品信息导入的过程中，如果不能够通过导入工具导入系统的话，那么CIO就需要设计一个应急方案，即员工手工录入系统的方案。此时最好先安排好人员分工、系统配置等等。如果真的无法成批导入系统，那么只好员工手工输入了。为了提高输入的效率，CIO先要为员工配置好系统。那么当需要手工输入的时候，员工可以马上着手做。而不是CIO先给他们安装系统再输入。反正信息化管理系统迟早要安装的，那么还不如先给他们装好，以备后面的不时之需。

　　所以说，笔者认为CIO在制定应急方案的时候，也要细分。要让员工一看到这个方案就知道该如何处理。只有细分的应急方案，其执行性才能够得到保障。不过细分的应急方案也可能会导致工作量的增加。为此，这个细分也要掌握一个度。

　　为此笔者认为，要根据任务的重要性来选择细分的级别。如上面这个产品基本信息这项工作，他非常的重要。三分系统、七分实施、十二分数据。可见基本数据的整理对于信息化项目的重要性。为此数据对于项目的成败具有非常关键的作用。故对于这项工作的应急方案一定要细化。而相对于一些不怎么重要的内容或者CIO有自信不怎么会出现意外情况的内容，则可以粗略一点。如对于数据的备份，如果CIO处于对自己专业知识的自信，那么针对这个作业的应急方案，CIO可以点到为止，甚至不做都可以。