|
|
[这个贴子最后由danelchen在 2002/08/18 00:01am 编辑]
监理：项目保护神
——医保项目监理经验谈
国研科技公司 黄林发生
摘自《计算机世界》
由于信息化项目建设存在着诸多的风险，因此信息化建设项目的成功率一直比较低。造成信息化建设项目失败的原因很多，其中最主要的原因之一就是目前尚缺乏对整个信息化建设项目进行全程监督控制的监理机制。固而，在信息化项目中引入监理机制已成为业界的共识。
我们通过为某市医疗保险信息系统提供监理服务而成功切入了IT监理业务领城。这个案例中的医保系统是某市的基本医疗保险系统，由该市负责信息化建设的主管部门牵头(简称客户方)，该市劳动和社会保障局为用户方．承建方以总包方式建设该项目，负责从方案设计、系统建设到后期运营维护全过程。
由于这是一个前期已有相当基础的信息系统，而且已正在运行，具体业务也正在开展。通过一段时间的工作，我们总结了以下11条经验：
1 仔细地分析各方的处境
所谓知己知彼，百战不殆．我们根据从各力搜集到的信息，对客户方，用户方和承建方在现阶段的处境进行了分析，认为客户方由于前期工作中介入太深，有必要通过我们的工作来减轻客户方在日常事务力面的工作压力．用户方则由于被不恰当地定位，加之缺乏具体利益和手段，从而使命感不很强烈；参与人虽想法不一致，内部意见不统一；而且往往由于政策目标与系统目标不一致，人为地造成系统建设障碍．承建方则在系统建设初期没有把用户方作为用户来看待，系统建设周期大短，系统建设的总体方案还没有来得及设计，系统就匆匆忙忙地上线了．总承包方对开发商管理不到位，相互之间缺乏信任感，与开发商有定位和利益冲突，种种原因使得系统建设中的配合工作发生问题．在仔细分析了各方的处境后，我们开始对症下药．井继续搜集资料来印证和修正我们的判断，以指导我们的监理行动。
2．明确监理方职责
在进入监理之前，首先应明确监理力职责，进行明确定位．根据对各方处境的把握，我们将自己定位为客户方的助手，辅助客户方来对项目进行控制和管理，主要包括；发现并预警问题，推动问题的解决。
主要职责包括：
(1)协助客户方与承建方更详细完整地定义业务需求；
(2)确保项目的整体解决方秦具备先进性，经济实用性，成熟性、可靠性，安全性，可管理性和可扩展性；
(3)对项目实施的各个阶段进行有效的监督和控制，确保项目各个阶段及整体的质量和进度目标．
(4)在项目建设的过程中，对业务需求定义，相关汀技术及项目管理等多千方面提供有价值的建议，
3．确立监理策略
在对内外部形势有了基本判断，明确了监理方职责后，我们就监理策略进行了探讨．究竟是浅层介入还是深层介入，在项目之初就确定下来了，但两者并不矛盾。在具体到各个阶段时，可能在某个时期会浅层介入，在某个时期又要深层介入．根据这个项目的特点，我们确定了以下策略：
(1) 争取获得客户方的强有力支持。(2)取得各方信任特别是用户方信任．(3)进入策略上，我们在开始阶段采取低姿态，以解决实际问题为目标，以积累监理经验，逐步树立监理权威。(4)“抓大放小”．(5)主要实行过程跟踪和里程碑控制。(6)技术和项目管理同时监理．逐步改善项目管理．
4，建立监理机制和监理机构
有了明确的监理职责定位后．根据确定的监理策略，我们有针对性地着手建立了一套与该项目相适应的监理机制。这套监理机制的框架主要包括监理计划，机构设置、活动类型、报告和文档规范，会议机制，变更控制、问题管理机制，质量审核和验收、沟通机制等内容。同时，分层次建立了对等的监理机构，从而有利十定义清楚的项目管理接口和建立规范的工作机制，以避免信息流的混乱，并定义每一层的职责和主要的活动．例如每周的监理例会都有管理层参加，推动各方建立与监理工作配合的机构。
5．确立问题跟踪和解决机制
问题管理是监理机制中十分重要的内容．对于通过各种渠道了解到的情况，都要进行及时的跟踪，建立相应的跟踪表格及时填写，并建立跟踪机制及时更新内容，这样就能在开监理例会时有根有据．这些跟踪表格和跟踪机制对于及时掌握系统建设的动态和业务需求变更的情况十分有帮助．跟踪表格作为问题记录，一般包括问题编号，问题名字，提出者，提出时间，优先级，希望解决时间，问题描述等等，这些问题可能有开发方面的问题，有项目方面的问题，有业务力面的问题，所以跟踪机制要求对问题进行分析，划分优先级、分配和跟踪，我们首先对严重影响系统建设、应用的问题进行跟踪，对优先级高的问题进行重点督促解决．
6.从大量日常函件中搜索承建方的计划
原则上，监理的项目计划制定依赖于承建方的计划，但由于承建方计划的模糊性，我们只好从大量日常函件中搜索承建方计划，每周制定监理的详细计划-制定监理中计划时，只列出主要工作和完成的时间段，而不是确切日期；规定周期性工作计划。
7．一个相互配合的团队
在工作中，我们团队的核心成员对于项目进行过程中具体遇到的问题各自分工负责。同时，大家秉承合作的原则，进行充分交流。比如，每星期四是监理方工作最繁忙的时候，这一天需要为周五的例会准备素材，往往都要工作到很晚，项目组成员需要各自分工、相互配合，才能把资料准备充分．这些工作和资料准备主要包括：
(1)确定监理例会的以题．在确定议题之前要与用户方和承建方进行沟通，就其中的议题进行商讨。因为有些议题并不适合在会议上提出，或者，即使要提出，也应让各干系方有所准备．
(2)发布监理例会通知和监理议程．
(3)催促承建方提供监理会议讨沦稿．讨论稿主要介绍本周的工程进展情况，提出需要协调的重大事务供监理会议讨论．
(4)提交整套的监理会议资料，包括监理例会议程，监理会议讨论樯，其他重大事项等．
8．深入基层了解情况
我们每周，都要深入系统建设各方的第一线，搜集资料，以作为监理例会的准备．这些来自第一线的资料，既有用户方的，也有承建方的。其实，这些问题也能通过故障单的形式传达到相应的部门，如由用户方负责的，传达到用户方的相应部门；由承建方负责的技术问题则传到相应部门或其分包商解决．但通过监理例会来讨论的问题，更有助于推动该问题的解决．同时在这里必须高度重视，监理例会上提出的应是具有代表性的问题，由于时间紧，如果不注意这方面，将会导致某方甚至各方的抵触，从而损害监理方的权威性。
9.充分听取意见．在会前协调各方立场
我们通过深入分析系统建没的各个环节，发现系统建设至今就有关任务下达方面还没有形成相应的规范。由于没有相应的流程来约束，用户方往往在制定政策和下达任务时，报本不考虑什理的系统开发周期问题，政策下来就意味着承建方要在系统中实现．使得承建方工作十分被动．而由于没有构建好任务下达流程，承建方对于用户方提出的需求，往往并不认真考虑系统是否能实现的问题，也很少从系统建设角度来考虑流程优化，不向用户方提出相应建议．使得系统实现的是用户方现有业务流程的复制，没有进行优化．
为了促进系统建设的健康发展，我们认为，有必要从源头抓住问题的症结．为此，我们在充分考虑了作为政策制定部门特殊性的情况下，提出了任务下达流程供各方进行讨论．但是在具体讨论时，由干涉及到各自责任问题，用户方和承建方立场分歧很大．为此，我们又在会后与用户方和承建方进行了充分沟通，最终说服了双方，使得流程得以顺利发布。
10.与用户方和承建方人员充分沟通
系统建设的执行者是各个岗位的经办人员，这也是许多真实信息的基本来源渠道．我们在工作中，特别住重与具体工作人员进行充分沟通，通过他们来了解项目进展情况．但是，应注意的是，通过这些渠道了解到的情况，只是有助于辅助我们进行情况分析，并不是所有信息都适合在监理会议上公开的．
11. 在内部和外部建立有效的沟通机制
建立有效的沟通机制是确保项目监理成功的关键，沟通分为内部沟通和外部沟通两部分．
首先，在进行监理的过程中，我们的内部沟通活动主要包括；
(1)文档管理。这是内部沟通管理中的核心。
(2)填写每周工作计划(个人和项目组)，每天个人活动列表。
(3)每人每天应该填写一份工作日志，并将填写完毕的文件用电子邮件发给每个小组成员。
(4)至少每两天讨论一次(早上或者晚上)，对工作进行回顾．
(5)每周对项目状态评估一次，并写入周报中．
(6)及时填写问题和待定议题记录．
其次，外部沟通也是至关重要的内容．外部沟通的关键是确定固定的交流渠道和报告制度，其次是分层次的交流．
(L)从交流渠道上主要包括
●定期拜访。我们一般每周定期固定与客户方汇报交流．每周定期拜访用户方及其经办机构每周固定与承建力的项目经理交流—次。
●监理会议。每周召开一次监理例会，各方就本周的系统建设进展情况进行介绍，对需要协调的事务在例会上进行探讨．
●专题会议。系统建设过程中出现的一些较重大事项，需要动员各方力量来配合解决的事务，主要通过专题会以来实现。
●非正式交流。有时，我们会与各方的具体经办人员以非正式进行交流，作现场了解。
(2)三个交流层次的渠道：
●决策层由部门(或公司)领导出而，与各方领导面谈，对项目重大方向性问题、合作关系问题等进行探讨。
●管理层：日常重大事情，计划、方案，项日管理等方面的事务一般由管理层来解决，这是非常关键的交流，是确保项目成功的重要环节。
●技术层：具体讨论拉术性和操作性问题．
(3)相关的报告；
●周报．每周—期，根据承律方和用户方的相关资料，对—周来系统建设的工作进展情况断回顾和总结，我们利用周报向各方就有关问题提出监理建议。
●月报．对叶月来系统建设的情况进行全面回顾和总结。
●项目状态报告。对系统建设的状恋进行跟踪总结，予以提示预警。
●其他专题报告。针对系统建设过程中遇到的一些专题性事务，通过调研，综合各方观点后，出具专题报告，提出监理方的观点．
总之，要确保项目监理工作的顺利开展，就必须在正确的监理指导思想，综合平衡各方利益，本着公平、公正，公开的原则，本着对项目负责，对系统负责的态度开展工作．
|
|
发表于 2002-8-17 23:59:23