科研情报信息系统项目风险管理的识别和来源

张 磊

(七台河市科学技术情报研究所，黑龙江 七台河 154600)

科技信息系统项目主体必须了解和掌握信息系统项目风险的来源、属性等，并对其实施有效管理。风险管理是科技信息系统项目管理的一部分，目的是保证项目总目标的实现，是使信息系统项目避开不利条件、减少损失、取得预期结果、实现项目目标的有效方法。

1 情报科技信息系统项目的特点

1.1 系统复杂、产品众多

随着高速上网的兴起，信息商务系统、政务系统都逐步向高度集成化方向发展，一个系统往往和多个系统互联形成一个统一的整体。在每个信息系统的开发过程中，都产生了大量的情报科技文档、源代码和交流信息，这些都是情报科技信息系统项目开发实施过程中的产品，数量众多，类别多样。

1.2 地域分布广泛

现在的世界已经是一个全国乃至全球协作的大生产，同样，在情报科技信息系统的运行过程中也是由多个企业和地区组织进行协作，经常是项目团队分布在多个地方。

1.3 参加人员众多

情报科技信息系统的工作量越来越大，参与者越来越多，信息交流的机会更多，花在开发工作上的时间也就相应减少，这样就使得人越多，效率越低，而效率越低，需要的人工就越多。这也是现代情报科技信息系统项目管理需要解决的一大问题。

2 情报科技信息系统项目风险的识别

风险识别是从整个项目全局的角度考虑，同制订风险管理计划过程类似，包括企业环境、组织过程资产库、项目范围陈述、项目管理计划。这几部分描述了最基本的项目风险，是风险识别的依据。此外，风险识别还需要预先在风险管理计划中定义，包括风险识别的时间表、人员安排，等等。因此，风险管理计划也是风险识别的输入之一。

由于在风险转化为问题后，风险并未完全消失，必须根据项目中的已知问题导出风险，以得到精确的风险定义。项目中的问题会体现在项目的中间产品或最终产品中，可以从复审项目的中间产品和最终产品中发现许多问题。复审的方式包括评审、检查和审计，复审的对象包括项目文档和程序。例如，通过对项目计划进行复审可以了解到项目计划的质量和项目经理的管理能力，而对源程序进行复审可以获得开发团队对开发规范的理解和执行情况。对于复审的结果需要追本溯源，查出导致问题出现的原因，不能仅停留在表面上，这样才能发掘出项目中真正存在的风险。但这种方法获得的风险列表并不是全面的，复审并不能发现全部的问题，项目中还有未暴露出的风险，在条件适当时也可能转化为问题，会给整个系统带来风险。而通过分析的方法可在更广的范围内识别风险。通过分析进行风险识别重在信息的收集和深入的思考，除了其他要素外，在分析过程中还可以采用“头脑风暴法”等方法去多收集与同项目直接或间接相关的情报信息，并深入分析这些信息后面隐藏的内容。

在情报科技信息系统项目管理中，充分借鉴已有经验和吸取教训对每一个项目经理而言都非常重要。项目风险库可以帮助到组织的每一个项目。风险库中包含了不少项目的风险管理文档，包括风险列表、风险跟踪举证，等等，通过这些文档可以描述出一个项目完整的风险状况。这些已经完成项目中的风险可能存在于某个角落，经常会影响现在的项目。特别是在同一个组织内，项目的过程、团队情况、行业背景都比较类似，不确定因素大致相同。在此种条件下，风险库可以更有效地帮助识别风险。在进行风险识别时，项目经理可获取类似项目中被识别出的风险，并考虑这些风险是否会在当前项目中发生，对于可能发生的风险则加入风险列表，如果认为不会发生，就必须周全考虑各方面的问题。通过这种方法能更迅速地识别出项目中的风险。

虽然风险识别过程中的风险列表在列表中，但描述的还不精确，缺少很多必要的属性，但至少已经迈出了第一步。如果说风险管理计划是让风险管理变得有据可依，那么风险识别就是让风险管理有的放矢。

3 情报科技信息系统项目的主要风险来源

3.1 需求风险

需求风险几乎出现在每个软件项目中，而且多数会转变成为问题。导致需求风险的原因是多方面的，首先，情报信息系统项目组成员并不都是业务领域的专家，对业务的理解存在偏差。业务领域的工作人员很多时候并不特别清楚他们想要的东西，软件需求从来源开始就不明确。即使他们是业务领域的专家，在与信息系统项目组人员沟通时也存在一定问题。由业务领域的专家进行表述，不同的项目组成员会产生不同的理解。由于方法和技术也存在一定问题，在需求阶段会出现各种各样的错误。

3.2 技术风险

技术风险也是信息系统项目中常见的风险。信息系统项目是技术型的项目，会使用到各种各样的技术方法，不恰当的方法选择和技术应用会对项目带来不良影响。

3.3 团队风险

往往在项目启动后才组建团队，团队中缺乏凝聚力。项目组成员主要从事技术工作，沟通能力欠缺，无法确定的团队聚合能力成为了项目的风险之一。

3.4 预算风险

项目预算是项目经理必须考虑的事情，紧张的预算会对项目经理的决策造成影响，例如，可能会选用低廉的工具，等等，这些决策都可能会对后面的工作造成影响。预算是否充足？能否及时到位？一旦发生问题或项目延期时是否仍然能够保证相对充足的预算？这都是必须预先考虑到的。

3.5 范围风险

范围风险同需求风险非常类似，但又有一些区别。需求风险是需求变动的风险，是由需求缺陷造成的。而范围风险是范围扩大的风险，其原因是多方面的，可能是需求调研时漏掉了某些功能，范围变动的风险一旦出现，将会对项目造成巨大影响。范围风险往往发生在项目的后期，此时开发工作已经基本完成，系统设计可能完全不支持要增加的功能。经过定性的风险分析通常能得到更新的风险列表，这时，列表中的风险和刚刚识别的时候相比清晰很多，此时可制订风险应对措施。相对于定性分析而言，风险定量分析更难操作。在分析方法不恰当或缺少相应模型的条件下，风险的定量分析不但不能带来更多有价值的信息，反而会在分析过程中占用一定的人力、物力。所以，一般进行风险的定性分析都是在对风险有了相对清晰地认识后再进行定量分析，要分析风险对项目产生的负面和正面影响，并制订相应的策略。量化分析着重于整个系统的风险情况而不是单个风险。在风险跟踪的过程中，需要按照最新的情况对风险定量分析的结果进行更新，以保证定量分析的精确性。当定量风险分析不断重复时，会发现一种趋势，即需要采取更多还是更少的风险管理措施。定量风险分析的结果是对风险响应计划的输入。消极的风险防范策略是常用的策略，其目的是降低风险出现的概率或减轻因风险带来的损失，如避免、转移和减轻等策略。