徐立

摘要：变更对于信息系统项目的影响不言而喻。该文从项目管理的角度出发，分析了变更的产生原因、变更对项目的主要影响、预防和减少变更的常见措施，并重点论述了变更发生时如何按照控制流程来对其进行控制。最后，以某铁路疗养院管理信息系统项目来举例说明项目变更控制的过程和结果。

关键词：信息系统；项目；变更；控制

中图分类号：TP311 文献标识码：A 文章编号：1009-3044(2012)36-8681-04

随着信息技术的发展，信息系统在越来越多的领域得到了广泛应用。于是，各种信息系统项目发展迅速，铁路多元经营领域也不例外。比如，笔者所在企业已经进行过多个信息系统项目（包括铁路多经企业办公信息系统、集经企业办公信息系统、疗养院管理信息系统等）的建设实施。

由于往往是在复杂的自然和社会环境中进行，因此，信息系统项目经常受到各种外部和内部因素的影响。而在此之中，变更往往是最常见、同时也是最令人头疼的，有时甚至能直接导致项目的失败。因此，做好变更的控制，最大程度上减少变更带来的影响，无疑是保证项目顺利完成最重要条件之一。

1 变更的产生原因

1.1 用户方引起变更

最常见的就是因为用户产生了新的想法和需求，以及认为原有的需求有遗漏等原因而引起变更。比如用户提出：“我还想增加这种功能”、“这个业务流程我有新的想法”、“这个地方我想改成这样”、“这里原来没有考虑到要补上”，等等。

1.2 实施方引起变更

在多数情况下属于必要之举，比如因为技术开发人员在开发过程中发现错误和缺陷、部分功能难以实现等原因而引起变更；不过，在个别时候也有画蛇添足的现象，比如某个技术开发人员认为某种功能加到系统上会很新颖、有卖点，结果自行添加，造成项目镀金。

1.3 其他原因引起变更

比如因为国家相关政策的改变（当项目涉及政府部门时尤为明显）、出现了新的技术和方法、计算机硬件软件平台发生了改变等原因而引起变更。

1.4 小结

对于信息系统项目而言，大多数的变更往往都是用户方所引起的。此类变更不仅发生的概率最大，而且所带来的工作量往往也是最大，特别是在项目后期时尤为明显。因此，做好对于用户方的变更控制，无疑是项目管理工作的重中之重。

2 变更对项目的主要影响

2.1 对项目本身的影响

变更通常意味着需要增加或调整系统的功能，因此很容易超出原先设定的项目范围。这样，项目的人力、物力及资金的投入显然会加大，从而增加成本。同时，随着工作量的加大，很可能直接影响项目的进度，使其难以按照原有计划来完成。另外，变更可能导致系统需求链的某些环节脱节，从而引起一些较难察觉的错误，这无疑会影响项目质量。

2.2 对项目干系人的影响

一方面，变更可能引起实施方和用户之间的分歧，特别是当变更没有被及时恰当地处理时，将直接影响双方的信任关系，最常见的就是用户对项目失去了耐心和信心。另一方面，变更同样也可能引起实施方团队成员之间的分歧，甚至导致团队内部矛盾升级，进而影响整个团队的合作。

2.3 小结

当一个信息系统项目不能控制好变更时，那么很可能发生以下这种情况：不管实施方做得多好多完美，用户却似乎永远不满意。用户总是提出新的需求，要求实施方在原有基础上来完成。于是，项目不断地发生变更，有时甚至还在同一个地方反复修改。就这样，项目往往做了很久，却感觉总是做不完，就像一个无底洞一样。而与此同时，项目范围蔓延、成本超支、进度延误、质量不满足要求等问题接踵而来，更槽糕的是，实施方团队成员士气低落、失去信心，用户也失去了耐心。最后，项目轻则以超支、延误等代价勉强结束，重则实在做不下去而彻底失败。

3 预防和减少变更的常见措施

变更是信息系统项目一个突出的、也是普遍的特点，可以说是很难避免的。对此，虽然我们难以完全避免变更，但是，却可以通过各种有效措施来预防和减少变更的发生。常见的措施主要有：

3.1 做好需求分析

需求分析目的是理解用户的需求，就信息系统的功能和用户达成一致。因此，需求分析人员要和用户（特别是用户方关键项目干系人）充分沟通，获取对方的具体需求和想法，以及可能存在的问题。这时，要注意挖掘隐性需求，可以通过引导、原型等方法让用户在前期充分暴露自己的想法。而有的时候，可能用户的业务模式不一定适合于计算机处理，这时，就需要以业务咨询的角色向用户提出可行的建议，使其能最大程度上地使用好信息系统。还有，对于用户需求的理解要及时进行反馈，以保证双方达成共识，保证需求的准确获取。最后，形成的需求规格说明书要做到全面、描述准确，能将用户的想法提炼成可实现的功能。值得注意的是，当需求评审正式通过（用户参与并确认）之后，如果用户再提出新的需求，那就都属于变更的范围，必须严格按照变更控制流程来进行控制。

3.2 强化合同管理

合同作为明确双方权利和义务的协议，在签订时必须仔细谨慎，千万不可草率。通常，技术开发人员应及时参与项目合同的签订过程，并与销售人员共同明确项目的目标和范围，以防止销售人员向用户做出过度承诺。同时，在合同内容上必须重视相关条款的描述。比如，合同必须对项目开发的范围、交付产品的功能，以及验收标准和步骤、后续维护等有着清晰的说明描述，特别是对于项目变更的控制范围与流程等要做出明确规定。合同条款要尽可能细化，并确保双方对条款的理解达成一致。

3.3 事前预测

在项目评估阶段，如果能对项目可能出现的变更进行充分预测，那么，就可以事先采取措施来预防变更的发生，或是变更发生时就能变被动应对为主动控制，并及时做出适当的响应。因此，实施方项目负责人应及时了解项目及用户背景，从用户需求、产品设备供应商、技术升级更新等方面入手，对项目可能出现的变更进行预测。同时，还可以咨询请教有关专家，以及参阅其他类似项目的相关文档资料，集思广益多方面的意见和经验。这对于预测项目的变更是很有帮助的。

3.4 重视文档建设

文档是项目过程中不可或缺的资料，具有提高开发效率、保证项目质量、明晰责任、沟通与桥梁等作用。特别是，文档还可作为历史档案，有助于将来的类似项目的实施，并形成组织过程资产以提升项目实施方的整体技术能力。因此，关于项目变更的起因、处理过程、结果，以及经验教训等要及时总结整理并归档，以便为今后的类似项目提供参考。同时，在编制文档时必须严格按照相关标准，确保文档符合针对性、清晰性、完整性、灵活性、精确性、及时性、可追溯性等要求，防止流于形式。

3.5 加强培训

首先要加强对项目团队成员，尤其是需求分析人员的培训，增强其信息系统项目及行业的背景知识，提高其专业技术水平、团队协作能力、责任感，以及与用户的沟通能力、服务意识等。同时，也要加强对用户的培训。在项目开始时就要对用户进行宣传和培训，改善其技术水平和思想观念，使其了解并明白变更实施的难度和可能给项目带来的影响，从而理解严格变更控制的重要意义。

3.6 其他措施

包括做好和用户的沟通，促成双方保持良好的合作关系；及时向用户提供项目绩效报告，让其对阶段成果进行确认；重视项目的质量管理，做好质量保证与质量控制等，这些措施都有助于预防和减少变更的发生。

4 变更发生时严格按照控制流程来进行控制

不允许信息系统项目有任何变更，这是很难做到、不太现实的。变更往往无可避免，也无从逃避。但是，变更难以避免绝不意味着系统可以随意修改。事实上，对于任何变更，都必须按规定严格加以控制。

4.1 建立变更控制委员会

可以根据项目的规模大小、工作需要等来建立不同级别的变更控制委员会。一般来说，其成员包括用户方项目负责人（代表），实施方项目负责人、配置管理人员、质量保证人员等，如果有可能的话，最好加入双方高层领导。变更控制委员会的主要职责是对变更进行受理、评估、决策，以及监督已批准变更的实施。

4.2 明确变更控制流程

当变更难以避免，特别是用户方要求变更时，必须严格按照控制流程来进行控制。通常，变更控制流程包括了变更的申请、评估、决策、实施、验证、沟通存档等环节。

1）变更申请。首先，无论用户要求何种变更，都必须采用变更申请书的方式来进行申请，否则一律不予受理。变更申请书须详细写明本次变更的申请原因、具体内容、申请时间、申请人等相关信息，并需要申请人签字及盖章。其次，要明确双方各自的变更授权人员。即用户的变更申请必须通过授权的人员来提出，而实施方同样也只有授权的人员才能受理，并进行初审，之后才能提交给变更控制委员会。值得注意的是，双方各自的授权人员原则上都控制在一人，否则很容易出现反复申请以及互相推卸责任的现象。一般来说，只有双方的项目负责人（代表）才能获得授权，担当双方的“变更接口人”。

2）变更评估。任何变更都有代价，归结起来，主要包括对项目的范围（工作量加大）、成本（人力、物力、资金的投入）、进度（原计划和约定完成时间延后）、质量（引起各种错误）等方面的影响。通常，由变更控制委员会召开相应的评估会议，对变更的影响范围、严重程度、经济和技术可行性进行系统分析，以及对项目的进度、成本重新进行核算，形成评估报告。然后，在技术上可行的前提下，必须要让用户了解并确认是否接受变更的代价。毕竟，现实中大多数用户对于信息系统项目的开发实施难度可以说是基本没有概念。在很多时候，用户总有类似于“不就是加了一点功能么”、“这只是一个小的修改而已”之类的观念。而事实上，有很多看起来工作量不大的变更，实际上却需要技术开发人员花费相当长的时间去完成，尤其是涉及系统核心功能模块的修改更是如此。所以，必须让用户充分了解变更对项目的影响，并确认是否接受其代价。否则，即使实施方花费再多的心血，用户也难以理解和认可。

3）变更决策。根据变更评估报告，以及用户是否接受变更代价的结果，由变更控制委员会来进行决策。如果决策批准变更（技术上可行且用户接受变更代价），则双方签订变更确认书，明确变更内容及代价，由双方项目负责人（代表）签字盖章，作为合同的附件存档。相反地，如果决策不予变更（技术上不可行或者用户无法接受变更代价），则本次变更申请被否决。这时要摆事实讲道理，尽量争取能得到用户的理解。不过，有时可能会遇到用户确实非常希望实施变更，或是用户认为代价过高而希望有所降低等情况，那么，此时就需要双方进一步沟通协商，尽量讨论出一个可行的方案。比如，在不影响项目正常进行的前提下，采取部分实施、延迟实施等方案，尽可能不影响双方的合作关系。但是，不管是采取何种方案，都同样必须严格按照变更控制流程来执行。

4）变更实施。变更控制委员会批准变更之后，将变更的信息通知所有相关人员。然后，实施方技术开发人员根据变更控制委员会给予的权限，并在其的指导和监督下来实现被批准的变更。也就是说，变更必须由管理者指定的工作人员在受控状态下实施，以确保变更可以追溯和控制。

5）变更验证。变更实施后必须经过验证。首先，由实施方进行内部验证。考虑到变更可能会导致相关模块产生错误或缺陷，因此，在验证时通常要对这些可能受到影响的模块逐一进行回归测试，以确保在不影响原有模块的前提下变更已经正确地实施。内部验证完成并经过项目负责人审核之后，再递交给用户验证，以确认变更是否达到了目的、结果是否与预期相符、是否满足了更新的需求等。用户经过验证并认可之后，必须让其书面确认验证结果。

6）沟通存档。最后，由于变更还可能引起各项目干系人工作之间的不一致，因此，需要将变更内容及时通知可能受到影响的人员，并说明哪些模块可能受到影响，以及发现问题后的反馈方式。同时，有关变更的文档资料必须予以妥善整理并归档。值得注意的是，即使用户的变更申请在决策时被否决，其相关初始文档也同样必须保存。

4.3 关于其他变更

以上所提的主要是针对用户方的变更控制。事实上，对于少数由实施方以及其他原因引起的变更，同样也必须严格按照类似流程来进行控制（对于修复错误和缺陷等的变更则通常要根据项目的质量标准来决策）。在这里，特别要注意防止项目镀金的现象。毕竟，技术开发人员认为很新颖、很有卖点的功能用户不一定会认可和接受。这种画蛇添足的行为对项目而言不仅基本不会带来什么益处，反而可能导致始料未及的副作用，得不偿失。

4.4 严格配置管理

实施方应指定专门的配置管理人员，将文档、代码、数据等作为配置项，按相关规定统一标识，纳入配置库进行管理。在变更的过程中，要及时对配置项进行检查、更新、评审和记录，以保证配置项始终是最新的、完整的、具有版本的。可以利用相关配置管理工具（比如Visual SourceSafe），以便于对配置项进行安全改动和跟踪检查。

4.5 检查和审计

通过以上的控制流程，基本可以有效地把变更置于控制之下。但是，不管是再多再好的流程，如果在执行时仅仅走走形式、做做样子，那显然将变得毫无意义。因此，在项目过程中要适时对变更控制的执行情况进行检查和审计，一旦发现存在违反规定的现象，必须及时予以严肃处理和纠正。要彻底防止变更控制流于形式而成为摆设。

5 信息系统项目的变更控制实例

这里，以笔者曾经参与过的某铁路疗养院管理信息系统项目为例。根据项目合同及需求规格说明书等内容，该系统主要包括了客房管理、餐饮管理、娱乐管理、会议管理、仓库管理、营销管理、人事管理、综合管理等子系统。考虑到系统涉及院方接待、餐饮、会务、财务、人事等多个科室部门，而每个科室部门都有提出变更的可能，这无疑将会给项目带来巨大风险。所以，做好对于院方的变更控制，显然是项目变更控制的重点。

对此，我们制订了项目变更控制计划，明确目标。首先，在项目部内部达成一致，禁止一切项目镀金行为。其次，和院方约定：成立变更控制委员会，由院方副院长（挂名）、设备科长（院方代表），我方副总（挂名）、项目经理、技术组长、配置管理员等人员组成。同时，规范变更控制流程，即院方任何科室部门及人员要提出变更，都必须首先告知院方代表。由院方代表负责汇总并进行内部审核，之后如确实需要变更，则统一以院方的名义出具变更申请书（申请人为院方代表），提交给我方项目经理。变更申请书须写明本次变更的申请原因、具体内容、申请时间等信息，并需要院方代表签字并加盖疗养院公章。待我方项目经理初审之后，再提交给变更控制委员会进行评估（评估内容主要包括变更实施的技术难度、对项目进度和成本的影响等）。最后，根据评估报告，以及院方是否接受变更代价的结果，来决策是否允许变更。

事实上，在项目过程中院方提交了不少变更申请。对于某些申请，比如增加预付款管理、更改收费结算报表格式、调整系统界面等，在经过评估之后表明变更实施的技术难度较小，对项目的影响也较小。于是，在院方书面确认（院方代表签字并加盖公章）接受变更的代价以后，予以实施。在完成之后，双方及时验证变更的成果，签字盖章并存档；相反地，对于某些申请，比如增加客户体检档案入库管理（和体检仪器对接，并自动从中读取数据入库）、增加LED显示屏管理（集成原有的LED屏显示控制软件）等，在经过评估之后表明，不仅变更实施的技术难度很大，而且很可能需要体检仪器、LED屏等设备供应商的配合支持。一旦实施变更，很可能会严重拖延整个项目进度，加大成本。并且，院方也认为变更代价过高而难以接受。显然地，这些变更申请最后都被否决。

另外，为了保持双方良好的合作关系，对于那些被否决的变更申请，我方会根据实际情况进行分析，如果有可能的话，通过其他方式来满足院方的需求。比如，对于增加客户体检档案入库管理的变更申请，院方原先的要求是和体检仪器对接，并自动从中读取数据入库。对此，我方提出了以下建议：即当前我方先根据院方提供的体检表格格式，在系统中增加体检管理子系统，并在其中实现手工输入体检数据的功能。至于和体检仪器对接，并自动从中读取数据入库的功能则暂时不予实施。如果将来院方确实有需要，则双方再另行协商并签订补充合同，作为项目二期来实现。这样，既保证了院方相关需求的基本功能可以尽快实现，又大大降低了变更实施的风险，并最终得到了院方的认可（事实上，经过一段时间的使用后，院方最后打消了自动读取数据入库的想法）。当然，此方案实施时仍然严格按照变更控制流程来执行。

同时，项目部也严格按照配置管理的要求，当实施变更时，确保其所导致的文档、代码等的变化始终在一个可以追溯和控制的状态下进行。而对于那些最后被否决的变更申请，其相关初始文档都一并存档。最后，由项目经理负责对项目变更控制的执行情况进行定期审查，如存在违规及不足之处则及时进行处理和改进，防止形式主义。

最终，项目顺利地完成，通过验收并正式交付使用。特别地，在项目最后清算时，所有经过院方书面确认的变更申请书、确认书、验证报告等相关文档资料作为变更的直接证据，都成为了事后追加项目费用的最重要依据。可以说，项目基本达到了变更控制的目标。另外，记录项目变更的起因、处理过程、结果等的文档资料作为宝贵的历史档案，同样为以后的类似项目提供了极有价值的参考资料。

6 结束语

综上所述，变更会对信息系统项目的范围、成本、进度、质量等产生诸多影响。可以说，能否真正地做好变更的控制，将直接影响到项目的成败。鉴于变更控制的重要性，我们必须高度重视，做到理论与实际相结合，尽可能先采取有效措施来预防和减少变更。特别地，在变更发生时严格按照控制流程，切实做好对于项目变更的申请、评估、决策、实施、验证、沟通存档等环节，从而最大程度上减少变更带来的影响。

参考文献：

[1] 张友生,刘现军. 信息系统项目管理师案例分析指南[M].北京:清华大学出版社,2009.

[2] 郭树行. 信息系统项目管理基础教程[M]. 北京:电子工业出版社,2011.

[3] 张友生, 吴旭东. 信息系统项目管理[M]. 北京:清华大学出版社,2012.