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

日期: 2010-08-30 来源:TechTarget中国 英文

  犯错无可避免,失败则不然;你可以弥补错误,但无法弥补失败。这是著名项目管理大师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可以点到为止,甚至不做都可以。


我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。