IT监理目标控制过程中的问题管理研究

作者：

欢迎访问e展厅 展厅 3 管理咨询与服务展厅 企业文化, 战略管理, 生产管理/工业工程, 营销管理, 知识管理, ... 对于信息系统项目目标采用动态控制是监理工作的基本方法之一。依照信息化工程监理规范，监理工作的顺利开展取决于建立一整套完备的监理机制，包括监理机构、监理活动基本流程、文档管理规范、沟通机制、问题管理机制等等。 信息系统项目建设一般分为六个阶段，即：项目准备阶段、总体设计阶段、设计开发阶段、实施阶段、验收阶段和运行维护阶段。根据不同项目的特点和具体情况，监理介入有早有晚，可能是全过程监理，也可能只针对某一个或某几个阶段实施监理。 大型信息系统项目周期可长达两年、三年，甚至更长。周期越长说明项目越复杂，建设过程中可能出的问题越多。尤其对于一些“先天不足”的项目(建设过程中并没有完全遵照信息系统建设的基本客观规律)，不可避免地会随着项目建设的推进，暴露出越来越多的各种问题。 在这一类型项目的监理中，毫无疑问，问题分析、管理和解决机制扮演着重要角色，因为整个项目建设就是在不断地发现问题、解决问题的过程中一步一步走向最终目标。监理方必须及时了解问题、跟踪问题的发展和解决进程，并有义务向系统各方通报现状和提出监理方观点。 监理价值也正是在发现问题、预警风险、促进解决问题的过程中得到充分体现。本文即是充分运用了问题管理的概念和方法,力图特定项目建立起特定的、有可操作性的问题管理机制。以下通过对发现问题、分析问题、处理问题等几个方面的分析探讨问题管理机制。 1.问题定义 并不是所有人反应的问题都是真正的问题，监理方必须做出一系列判断。是不是问题？是暂时的问题还是长久的？有多严重？比如在我们监理过的某个政府信息化项目中，由于更换了开发商而新开发了一套软件，新软件替换旧软件上线后不久，用户方主管部门反应软件操作不方便导致咨询电话不断，甚至某些用户产生怨言。这算不算问题？通常在软件重大版本更新很可能发生使用习惯问题，更何况案例中的软件开发商也更换了。因此，用户的某些不理解和应用习惯未必意味着开发商的设计问题。 问题定义：“问题”是项目建设过程中出现的会对系统产生不利影响的故障、变化、和风险的总称。 2.发现问题 监理方和承建方、用户方都应该建立规范、稳定的沟通渠道。对于某些特殊的项目监理方的客户和信息系统的用户可能不是同一个单位，即系统的投资方和用户方不一致，在这种情况下监理方需要建立和三方的沟通渠道。沟通渠道的完备为及时发现问题打下了基础，一般来说，问题会通过以下几种方式反应出来： 用户方通过已建立的沟通渠道直接向监理方反应系统问题； 承建方通过已建立的沟通渠道直接向监理方反应用户方出现的业务问题、流程问题、管理问题等； 客户方通过已建立的沟通渠道直接向监理方反应系统建设问题； 在监理会议上各方都可能反应系统建设问题； 用户方向承建方提交系统运行故障单，承建方再抄送监理方； 监理方在工作中主动发现问题。 3.分析问题 对于信息化工程建设中出现的问题，往往是公说公有理、婆说婆有理。大型信息化工程，特别是涉及若干个不同部门的工程，扯皮推委现象是造成工程延期的重要原因之一。因此“监理”应运而生。人们常说成功的项目七分考管理，监理工作也是如此，技术层面的问题和分歧往往更容易解决。作为项目建设第三方，监理方既要保持公正、公平、公开的立场，又要建立和维持各方之间友好、一致的工作氛围。因此，监理方除了从技术角度为项目把关，还要充分发挥管理艺术，这样才能协调处理好项目建设各方的关系，更有效率地解决问题，推动项目的进展。 在项目建设中，对于各方反应的问题监理方首先必须做出判断。做出判断后才可以对问题立项，跟踪问题的发展和解决进程。那么是不是我们对待所有问题都一概而论呢？答案显然是否定的。问题的轻重缓急、问题提出方的态度、问题对系统影响的大小等因素都决定了监理方需要对问题分类处理，采取不同的监理策略区别对待。也只有如此才能面向项目，以达到最大限度地减少分歧、提高整体工作效率、体现监理价值。 通常的监理项目中的问题可分为四类，如下图： 根据上图，很显然，A类问题最有可能体现监理方价值。这类问题往往涉及到多方关系协调，因为只涉及到一方的问题大多可以通过该方的内部工作解决。如果问题涉及到多方，只能靠协调解决。这种时候最常见的消极情况是互不配合、只关注和自己有关的环节，扯皮、推卸责任。此时监理的一项重要作用得以发挥，即组织协调。例如，在我们监理的某个投资巨大的电子政务项目中出现了一个问题。 由于相关的业务流程复杂，环节多，涉及到的单位多，协调困难，谁都不认为自己有问题，甚至出了问题都不知道该向谁反应，结果导致系统的最终服务对象—老百姓的利益受损。僵持了一段时间后，监理方意识到了问题的严重性。经过大量调研，发现在流程中若干环节相对问题集中，而且这几个环节都由一个单位(甲)负责，于是提出问题解决方案，包括详细的处理流程。 两个层次，第一层次是：出了问题将直接向甲单位反应，该单位负责协调相关各方解决问题；第二层次是：成立问题协调小组，成员包括各单位领导，若有甲单位协调解决不了的问题向协调小组汇报，由协调小组协调解决。解决问题的机制建立后，对最终用户来说有了反应问题的场所，各方责任清楚，提高了解决问题的效率，和政府的办事效率，老百姓的利益得到了保障。后来事实证明只有少数问题反应到了协调小组。在这个问题上，监理作用得到充分发挥。 B类问题既然其他各方可以把它解决好，那么此时如果监理方再试图推动的话，会让其他各方感到多余，甚至更糟的话可能会有干涉对方内部工作的嫌疑。比如在某项目中，用户方反应承建方对系统故障排查和服务相应的速度太慢，在这个问题上，承建方没有异议。事实上，问题的存在是由于他们的其他工作太忙而没有顾得上及时解决。因此，对于这个问题上，监理方在态度上立场鲜明，支持用户方的态度。 C类问题同A类一样也有可能体现监理价值，但不同的是，其他各方没有意识到问题的严重性，甚至根本没有注意到问题的存在，这种情况下监理方必须立场鲜明地站出来，并指出问题的隐患，这是监理的职责所在。例如在某项目中，由于用户方的需求改动频繁，而且往往没有给承建方流出合理的时间，造成承建方疲于应付新需求变动而缺少时间完善系统。 此时监理方注意到这个问题是由于缺少规范的需求管理造成的，于是我们拟订出管理制度文件并最终促成各方签署。在监理方多次阐明利害关系之后，各方均认识到需求管理流程被规范后会提高系统建设总体效率，对谁都有好处。 有很多问题在我们初步调研后即发现它们不影响大局，或者向“问题定义”一节中提到的操作适应性等问题，这些问题各方都不关注，也确实不重要，甚至过了一段时间问题的提出者都把这件事忘了。这就是图中表示的D类问题，这类问题自然不用花费很多精力。 4.问题跟踪 根据问题分类原则确定了监理方策略后，监理方需要跟踪问题发展状况和解决进程。我们的问题跟踪机制总的思路是：建立《问题列表》，所有问题按某一特定的顺序排列，比如提出的时间。每个问题需包括问题编号、提出时间、提出人、描述、重要性级别、解决方案、解决方案批准人、要求解决时间、目前状态等信息。而对于某一具体问题，我们建立《XX问题跟踪表》，目的是记录问题发生、发展、解决整个过程中与问题有关的活动、讨论、决议和监理方观点。 表中应该包括问题编号、活动类型、活动日期、决议、监理方观点等信息。这样做可以为将来撰写问题报告打好基础。《XX问题跟踪表》和《问题列表》通过两个表中某些共同项目建立映射关系，比如问题编号或问题描述，如果是电子文件可以考虑建立超级链接。当然，由问题的重要程度不同，并不是每个具体问题都有必要建立问题跟踪表。 4.1问题跟踪流程(如下图所示) 4.2流程说明 根据《问题跟踪表》的内容，每周定期更新《问题列表》的“当前状态”； 如有新问题产生，问题列表将即时更新，并即时产生该问题的《问题跟踪表》； 跟踪一般分为两条线路，即承建方和用户方，因为每个问题都可能涉及到系统和业务两个方面； 每个问题一般由两个人共同跟踪，分别负责承建方和用户方两条线，其中一个是该问题的负责人； 针对重点问题跟踪所获得的全部信息都及时按时间顺序记录在一个确定的问题跟踪表中。《问题跟踪表》和《问题列表》通过两个表中某些共同项目建立映射关系，比如问题编号或问题描述，如果是电子文件可以考虑建立超级链接。； 由问题负责人即时更新《问题跟踪表》，并且每周三下午确定时间更新《问题列表》中的相应问题项目； 5.问题报告 问题报告是在问题的某一阶段监理方对该问题认识的总结，可以是在问题发现阶段、问题解决阶段，也可以在问题解决后。问题报告的对象是监理方的客户，在客户的授权下可以抄送给项目其他相关各方。因此问题报告是监理方客户了解项目进展的重要渠道。 报告的内容应包括对问题的描述，即问题的发生和发展过程，信息来源于《问题跟踪表》，还应包括监理方对问题的分析和监理方建议。 问题报告是监理方客户了解项目进展的重要渠道，监理方应尽量多报告。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (9/5/2006)