笔者作为电子政务项目业主方的管理人员，经过长时间的实践积累和经验总结，将电子政务项目中常见的风险和相应对策归纳如下：

一、非系统风险

所谓非系统风险，主要是指一些与项目本身无关，但又会直接影响到项目实施效果的客观因素造成的风险，其作用范围为项目全过程。充分地认识和正确地处理非系统风险经常是电子政务项目最终成功的关键。

电子政务项目中的非系统风险主要包括如下几类：

1、政策风险：中央政府或地方政府颁发了与为项目提供支持依据的条文产生全部或部分冲突的法规、文件或者为项目提供支持依据的条文失效。

出现概率：低

影响程度：小

处理建议：工期较长的项目有可能遇到此类风险，由于通常情况下要遵循地方服从中央、局部服从整体的政策原则，因此遇到政策改变时要及时报请业主部门进行决策，尽量争取将项目纳入政策允许的例外范围，特事特办。

2、领导决策风险：由于政府是层层决策机制，很难在一开始就得到高层领导的指示，而每一级领导通常都会有自己的看法，经常出现项目实施已接近完成，却被主管领导一票否决的情况。

出现概率：高

影响程度：大

处理建议：高层领导考虑的多是战略层面的问题，基层领导考虑的多是细节层面的问题，通常难以统一，想让需求一次性确定基本是不可能的。因此在做方案的时候要尽量使架构灵活，可扩充性强。软件开发尽可能采用构件或模块方式，增强重用性，最大限度适应需求频繁变更。在正式实施前多通过静态原型等手段汇报沟通，充分了解各级领导的偏好后再确定方案。另外正式实施前要多请示，阶段工作要常汇报，在让上级领导决策前要尽量说明前期已完成工作，并预先指出哪些变更会对项目产生颠覆性的影响，以免领导在未做详细了解的情况下主观表态。

3、其它部门干预风险：系统设计时未充分考虑外部因素，实施过程中受到其它强力政府部门以不符合某方面规划等理由对系统提出较大幅度的更改要求。

出现概率：高

影响程度：大

处理建议：建设前期尽量与各主管部门及所有可能涉及到的业务部门加强沟通，全面征求意见，事先取得支持，同时在技术实现上尽可能采用开放标准和可扩展的架构。

4、既得利益风险：需要多部门配合的系统可能会涉及到某个或某几个部门的既得利益，在建设和推广过程中受到阻挠。

出现概率：高

影响程度：大

处理建议：一方面要与相关部门的主管领导沟通争取得到支持，另一方面要想办法尽量减低对各部门既得利益的损伤，并与所有的既得利益者商议如何通过新系统获得新的利益均衡，必要时需要请监察局等部门进行协调或报请更高层的领导批示。

5、战略改变风险：主管部门发展战略改变，不再需要建设该系统。

出现概率：低

影响程度：大

处理建议：通常只有大的人事变动或者大的政策变化才会影响到一个部门的整体战略，因此要经常与主管部门沟通，保持与各相关部门尤其是规划部门的密切联系，确保项目目标与部门战略的长期一致性，如果无法避免战略变更，应通过多层面沟通，争取在制定新战略时优先考虑加入与项目相关的战略内容。

6、管理风险：政府部门的项目管理人员管理经验不足，对项目控制力度不够或控制过度。

出现概率：高

影响程度：大

处理建议：项目承担者需要经常与业主方项目管理者沟通，除了项目内容之外，还要包括项目管理知识等周边内容，同时要注意工作细节，有隐患时应主动提示业主，增强业主的信任度，确保业主的必要协调力度，避免业主不必要的干预。

7、进度风险：不能在预期的时间范围内完成任务。

出现概率：中

影响程度：中

处理建议：要尽量将项目切块，分清轻重缓急，通常高层领导主要关注表现层，要确保表现稳定准确，其它部分可以放在后期实现，由于需求变化的不可控性，项目超期不能结束的情况较多，因此更需要严格控制实施方的计划，强化管理，根据实际情况采取并行实施或加班等方式保证领导要求或文件规定的上线工期，将一些不可见的隐蔽工程放在上线后实施。

8、成本风险：项目投入超出预算范围。

出现概率：中

影响程度：中

处理建议：一方面要控制需求，另一方面要优化开发方式或创新管理，尽量减低人工成本。如果确因客观原因造成超预算，应与业主协商，从其它经费中协调，或追加预算。

9、法律风险：合作双方在许可权、专利、合同失效、诉讼等情况发生。

出现概率：低

影响程度：低

处理建议：很多电子政务工程在协议中会约定知识产权归甲方所有，但是政府本身又不可能通过销售已建系统盈利，因此至少应保证产权共有，双方在签定合同时应仔细审核合同条文，明确责权，本着互利和推动产业发展的原则制定条款，不宜生搬硬套。

10、不可抗力发生：自然灾害、电信故障等不可抗力发生。

出现概率：低

影响程度：高

处理建议：天灾人祸纯属意外，如果是重要系统，应尽可能建议业主设立异地容灾中心，以确保安全。

二、系统风险

所谓系统风险，指的是与项目本身相关的人或事物对项目造成的影响而产生的风险。在项目的不同阶段面临的风险是不同的。系统风险可能是由于业主的原因造成的，也有可能是由于实施方的原因造成的，不管怎样，问题都需要双方鼎力配合才能得到妥善解决。

A、初始阶段

1、目标风险：业主或实施方对项目目标不清晰，没有明确、实际的目标描述。

出现概率：低

影响程度：高

处理建议：业主和实施方要组织专题论证会，明确项目目标，并确定考核目标实现的方法。

2、范围风险：业主未明确项目范围，需求外延不断变化。

出现概率：高

影响程度：中

处理建议：由于业主通常不是专业人士，同时电子政务的很多项目都没有可参照样板，因此很容易出现项目范围不明确的情况，实施方需要帮助业主完成对项目范围的界定，并在实施过程中控制范围，超出部分建议业主分期实现。

3、沟通风险：实施方缺乏与业主沟通或业主难于沟通造成理解偏差。

出现概率：高

影响程度：中

处理建议：实施方要主动加强与业主沟通，要尝试通过会议、电子邮件、聊天工具等多种途径进行沟通。同时要学会换位思考，多从业主角度出发考虑问题。

4、业务了解风险：实施方需求分析人员同于知识缺陷，无法全面理解相关业务。

出现概率：中

影响程度：高

处理建议：实施方的需求人员要安排足够多的时间加强对与需求相关的业务了解，避免无法理解需求的真实含义。可以引入可视化辅助工具尽量使双方的表达一致。

5、需求理解风险：实施人员没有对需求仔细研究，出现误解需求或部分理解需求等情况。

出现概率：中

影响程度：中

处理建议：实施方项目管理人员应组织所有参与人员集中讨论需求，并取得一致理解，通过静态原型等方式加强相互理解。

6、可行性风险：由于时间仓促等原因，实施方案没有进行可行性研究。

出现概率：中

影响程度：高

处理建议：重要项目应请专业的机构和人员进行可行性分析，并出具相关报告。因为技术并不是万能的，一定要界定好技术实现的时间与资金等前提条件。

7、细节需求频繁变更风险：业主不断变化需求细节，积少成多，产生很多额外工作量。

出现概率：高

影响程度：中

处理建议：实施方要科学控制需求变更，通过项目组集体决策的方式确定变更，除了严重影响使用外，细节变更要批量修改，不要一事一改。

8、需求变更缺乏管理风险：业主缺少有效的需求变化管理。

出现概率：中

影响程度：中

处理建议：实施方协助业主加强对需求变更的管理，责任到人，签字确认。

9、文档管理风险：实施方缺乏有效的文档管理体系。

出现概率：高

影响程度：低

处理建议：应建立严格的文档管理制度，包含对错误的管理，建立完善的错误追踪管理系统。

10、需求变更缺乏分析风险：实施方对需求的变化缺少象原始需求一样的分析过程。

出现概率：高

影响程度：低

处理建议：实施管理者要对所有需求的变更与原始需求一样重视，要逐条进行详细分析，确定对原设计的影响，全面变更实施计划后再进行变更实施。

B、设计阶段

1、项目团队经验风险：实施方项目队伍缺乏经验，或缺乏有经验的核心技术人员。

出现概率：中

影响程度：高

处理建议：业主加强对开发团队的审核，包括团队合作、组成人员资质和经验等。

2、实施者自行变更风险：实施者根据自己的经验或考虑自身成本利益等原因在未得到业主允许的情况下私自变更需求或需求的实现方式。

出现概率：低

影响程度：中

处理建议：要明确约定实施者不得随意变更用户需求，如需变更需得到需求者认可方可实施。

3、计划风险：仓促计划，盲目制定工期，造成进度无法按计划控制。

出现概率：低

影响程度：中

处理建议：科学制定详细的开发计划，并经过共同论证后再严格实施。

4、漏项风险：由于设计人员的疏忽某个功能没有考虑进去。

出现概率：低

影响程度：中

处理建议：设计后需要多方复核，仔细对比需求说明书与设计说明书的各相关项。

C、实施阶段

1、开发环境风险：开发软件环境没有准备好或与实际环境不同，导致产品无法装载到运行环境。

出现概率：低

影响程度：低

处理建议：需要双方技术人员共同确认环境的一致性，要精确到产品的版本号及补丁情况。

2、整合风险：所实施的项目中涉及对旧有异构数据和系统的整合。

出现概率：中

影响程度：低

处理建议：在实施前应做充分调查，了解相关系统的所有技术细节，采用比较成熟和稳定的整合方案，并制定接口规范，规划时尽量减少新系统的异构。

3、布署风险：运行环境和产品开发环境差异，尤其是开发机器与服务器硬件配置差异等原因造成布署困难。

出现概率：低

影响程度：低

处理建议：尽量保证开发时使用与最终布署环境相同的硬件条件，如果布署环境硬件条件过高则应事先与厂商了解硬件相关特性，确保布署可能性。

4、设计风险：由于系统设计错误带来实施困难。

出现概率：低

影响程度：高

处理建议：系统设计方案完成后，需要业主方组织成立技术专家组共同确认设计方案，及时发现设计漏洞。

5、人员能力风险：程序员开发能力差，或程序员对开发工具不熟。

出现概率：高

影响程度：低

处理建议：所有的项目组成员要做预先业务能力审核，如遇更替人员也要进行相应的审核，确保人员具备足够的业务能力。

6、项目范围改变风险：已经开始实施后用户突然要增加或变更一些结构性的功能，需要重新考虑架构设计。

出现概率：低

影响程度：高

处理建议：架构设计尽量灵活，采用构件开发等方式增加应变能力，同时要加强前期的静态原型细度并将可能存在的问题及时提交给业主，避免实施过程中发生结构性修改。

7、项目进度改变风险：由于特殊事件或得到上级领导指示，业主方要求提前完成任务。

出现概率：低

影响程度：高

处理建议：如果进度改变不可避免，必须重新制定详细计划，并利用非工作时间加班或增加人手来缩短工期，如无论如何都无法完成需事先向需求方说明，并将项目拆分，先尽量完成表现部分保证上线要求。

8、人员变动风险：项目组成员流动比较频繁，交接不顺利或管理不到位，造成项目的进度和质量受到影响。

出现概率：中

影响程度：中

处理建议：完善文档管理制度，所有重要岗位备有相应的替换人员，同时考虑采用一些快速开发工具，尽量减少纯手写代码，严格要求注释格式，增强可读性。

9、团队配合风险：开发团队内部或多个开发团队之间沟通不够，导致程序员对系统设计的理解上有偏差。

出现概率：低

影响程度：中

处理建议：实施方各个开发团队都应有科学的管理方式，并在实施前做好相关约定，确保统一认识。

10、备份风险：没有有效的系统备份方案，遇到硬件瘫痪等严重故障后无法重建系统或造成重要数据丢失。

出现概率：低

影响程度：高

处理建议：实施者在开发系统时应及时备份并事先准备应急预案。

11、测试计划风险：没有切实可行的测试计划，导致测试的功能点不全，有些潜在的问题没参在测试阶段及时发现。

出现概率：低

影响程度：低

处理建议：业主与实施者应配合建立详细的测试计划，将技术测试和业务测试分开，责任到人，并严格按照问题修改机制操作。

12、测试人员经验风险：没有专业的测试人员或测试人员对业务不熟悉，测试经验不足。

出现概率：低

影响程度：低

处理建议：参与测试的人员应具备相关知识和经验，大的项目可以请专业的测试机构进行测评。

D、收尾阶段

1、质量风险：编码结束后总体或部分系统质量差，如速度慢，易用性差等。

出现概率：低

影响程度：高

处理建议：实施管理者要分阶段严格控制代码规范性，逐步测试，必要时引入专业分析工具定位造成质量问题的代码位置并安排修正。

2、使用者不满意风险：业主方有时并不是最终的使用者，当系统基本完成后相关使用者对系统不满意造成需求变更。

出现概率：中

影响程度：高

处理建议：业主应在项目的各阶段组织使用者参与意见，边测试边改进，不要在系统接近完成时再征求使用者的意见。

3、采购风险：由于政府采购需要一定的时间周期，当系统需要上线时必需的设备或系统软件没有按时到货。

出现概率：低

影响程度：低

处理建议：业主方要按照相关规定及时安排采购提前量，尤其是需要走公开招标流程的，必须提前足够长的时间启动招标工作。

4、产出过低风险：未达到预期的投入产出效果，包括社会影响等。

出现概率：低

影响程度：低

处理建议：通常电子政务项目缺乏必要的投入产出评估，但作为业主应该有相应的考量，除了对系统本身不断完善外，相关的商务、推广等工作也要全面配合，以获得最大收益。

E、运维风险

1、大流量风险：面向公众的服务很难评估实际访问量，过高估计会造成投资浪费，过低估计，系统将无法承受，造成访问速度慢甚至宕机。

出现概率：低

影响程度：高

处理建议：设计时要充分考虑，软件系统要支持分布式布署，并准备好足够的硬件备机，当出现过高流量时立即启用负载均衡方案、高速缓存方案等高可用解决方案。

2、系统应用安全风险：任何系统都无法保证不存在任何漏洞，尤其是通过互联网访问的系统。

出现概率：中

影响程度：中

处理建议：重要的系统可以采用限制使用者IP地址或通过数字证书认证等方式加强访问的安全性。

3、客服支持能力风险：如果是面向公众的应用系统，由于受众太多，业主方很难安排足够多的客服人员解决所有的与系统相关的咨询和建议。

出现概率：低

影响程度：低

处理建议：采用外包的方式与呼叫中心等专业机构合作，设立足够多的客服座席，配合知识库，尽量减少业主方的客服压力。

4、客服人员素质风险：由于客服人员对系统了解的程度或服务态度等问题影响运维质量。

出现概率：低

影响程度：低

处理建议：需要对客服人员进行有针对性的系统相关知训培训，并严格管理制度，杜绝态度问题。

    由于笔者经验有限，暂时只总结了这些常见的电子政务项目风险，供大家在实际工作中参考，希望各位读者批评指正。