论信息系统项目的风险管理

论信息系统项目的风险管理

摘要：2006年6月，我参加了某国有银行黑龙江省分行城市综合网调帐系统的设计开发工作，并由领导委派担任项目组负责人。我行城综网业务系统经过了几年的运行与发展，现在已经覆盖了一级分行的各种业务种类及由其衍生的金融创新产品，后台业务数据库越来越庞大，业务量增长迅猛，各种帐务数据的调整业务量也在增加。所以迫切需要一种方便迅速的维护调帐系统来适应当前业务系统的发展需要。本文结合作者的经验就项目的风险管理作了详实的论述；并就项目实施过程中采取的措施、方法作了介绍。最后，列举了该项目风险管理的一些不足与展望。

正文：某国有银行黑龙江省分行城综网业务系统经过几年的运行与发展，现在已经覆盖全行的各种业务种类，后台业务数据库越来越庞大，业务量增长迅猛，各种帐务数据的调整业务量也在增加，所以迫切需要一种方便迅速的维护调帐系统来适应当前业务系统的发展需要。鉴于以上业务需求的实际情况,省行科技处决定立项开发城综网调帐系统。本人受领导委派担任项目组负责人,全面负责该项目的开发与管理。

调帐业务系统建设的主要目标如下:

(1)建立统一模式的黑龙江省分行城综网调帐系统，使城综网维护调帐业务实现分布处理，各地市行

的帐务由各地市自己调整，提高处理的响应时间；

(2)充分发挥网络的优势，在实现基本调帐业务功能的同时，可以实现知识管理、信息发布、业务经

验论坛，提高企业的服务效果；

(3)将调帐系统做成一个维护管理综合平台，以便更好的为各部门服务。

根据我行城综网业务系统运行的具体需要，结合计算机技术的发展，我们计划采用Browse/Server 方式来构建调帐业务系统。Web服务器采用Windows IIS,应用服务器采用TongWeb,安全认证中心采用TongSec。由于我行已经有了十分完善的计算机网络和运行环境，因此调帐业务系统应该在我行已有的网络环境上进行构建。

除了利用SSL和java自身的安全控制外，为了实现更高的安全级别，我们采用建立认证中心的方式来实现整个调帐系统的安全，可以采用TongSec来实现。这样设计的优点：开发系统的工作量小，充分利用现有的业务系统，将来系统升级方便，系统移植性好。

在科技处领导的悉心关怀和业务部门的鼎力支持下,经过项目组同志们的艰苦努力,该项目从2006年6月启动,至2006年12月正式通过科技处组织的验收.并在2个月的试运行期间,顺利通过了年终结转的考验,至今,仍稳定运行。

项目风险管理包括进行风险管理计划编制、对项目风险进行识别、分析和应对的过程。项目风险管理主要包括以下过程：风险管理计划编制、风险识别、定性风险分析、定量风险分析、风险应对计划编制、风险监控。项目风险管理是项目管理的一部分，目的是保证项目总目标的实现。

在这个项目过程当中，我们对项目风险进行识别、分析，全过程跟踪风险，针对主要风险进行了应对，主要的应对措施有加强变更控制、合理配置人员、权衡质量和进度找最佳平衡点、加强测试，目的是保证实现计划的功能并按时投入运行。

一. 项目全过程有效管理和控制风险因素.

在本系统的开发过程中,科技处提供了风险管理计划的模板和风险事件列表模板．列出所有可能与每一个风险因素有关的问题。我们从需求变更、人员管理、过程、成本、进度、质量、领导支持程度、系统运行的基础等方面共识别34项风险，并分别制定了风险应对措施。综合考虑这些风险发生的概率及影响程度，对这些风险进行优先级排序。为了让项目组在各个阶段保持良好的风险意识，我尝试采用了“十大风险事项跟踪”，把项目中各主要风险事项按照排序张贴在公告栏上．其他的风险放在监视列表中以备继续监视。每周的项目会议都讨论前10个主要风险，并依据实施阶段绩效分析、财务报表等各方面信息，对残余的风险进行重新排序，随时应对风险的出现和变化。由于当时有部分未明晰的需求包括：查询统计部分需求、客户方面可能提出的新需求．另外还有需求和范围界定不清、计划不充分、用户参与不足、缺乏领导支持、技术问题等为我们项目计划阶段主要风险事件．事实表明，这种做法效果是非常明显的．特别是业务部门方面，我定期把风险事件列表Email给业务部门的项目需求提供者．为了能尽快落实未明晰的需求部分，我与业务部门经理们进行过多次面对面的沟通。与之尽快达成悬留部分需求的共识．需求问题很快得到解决．项目组整体信心十足，积极性和责任感增加．科技处领导方面对项目组也表现出特别的关心，特别是，曹处长开始频繁出现在项目组的每周进度评审会议上，他们也开始担心因为对项目支持不够而导致项目的失败。

二．重视需求变化的客观性，加强配置管理，控制变更。

我们采用了软件工程方法，使用渐增式的增量模型，注重满足用户需求和需求的变化。虽然在项目立项之初，省行科技部面向所有业务部门组织了需求征集活动，并形成了《需求说明书》，但由于业务调整的不断变化，造成调账系统的需求变化频繁。根据这个情况，为保证软件满足应用需要，我们规定：在整个项目的开发过程中，凡是业务部门提出的、经调查情况属实的、经技术可行性论证可行的，全部予以响应。同时，采取措施避免需求的反复和无意义、不合理的变更。对较大的变更和比较关键的变更，要经各方联席会议论证通过，参与人员签字负责，并由提出变更的单位加盖公章确认。对于不合理或技术上不可行没有通过的需求变更，要提出替代的解决办法，并与业务单位协商，达成一致意见后予以解决。

我们由项目经理、业务代表、质量控制人员、配置管理人员组成变更控制委员会（CCB），按照提出变更、审查变更、批准（否决）变更、实施变更、验证变更、记录变更及原因的程序严格控制配置项变更，使项目的混乱减到最小，使错误达到最少。另外，我们也深刻体会到：只有和变更控制进行配合，将变更的原因和变更的结果（配置项的某一版本）联系在一起，才能以变更为主线，将所有版本变为“有理由的”，才能形成基线，真正发挥变更控制和版本管理的作用，保证项目的质量。

三、合理配置人员，通过对人员的控制，达到对质量的控制。

通过对角色的质量控制，达到对软件质量的控制。我们制定了各组的规范及各类人员的职责，作为控制的标准。对项目组人员进行规划配置，合理分工，明确责任，保证项目各阶段、各方面的工作能够按计划完成。我们在项目组中配置了以下人员：技术组长一名，负责技术难题攻关，组间沟通协调；需求人员5名，负责将用户需求转换成项目内的功能需求和非功能需求，编制项目需求规格说明书，针对每个迭代集成版本与用户交流获取需求的细化；设计人员5名，根据需求规格说明书，进行