论系统集成项目中的变更管理的重要性

1、论系统集成项目中的变更管理的重要性2012年2月25日唐元龙摘要：文章论述了系统集成特点、变更管理的重耍性等内容关键词：系统集成变更管理目前国内大大小小的系统集成公司很多，。可是这些公司有的是昙花一 现，冇的却是经久不衰，成为系统集成行业的领头羊，而真正能做的好的没冇多 少。究其原因，对系统集成的工程管理认识不够，特别是对项目中的变更管理缺 乏工程管理经验与方法，工程管理不规范是其主要原因。系统集成工程项口实施屮的变更管理对每个具体的项口而言，各不相 同，千变力化，对一个新的项目经理，往往是千头万序，顾此失彼，而项目的周 期短，工作量大，时间紧迫，等明白过来，此时已悔之晚矣。在项目的变更过程中

2、，常会听到客户这样的抱怨：“只是要改一个系 统参数，很简单的事情，非要做一堆分析，还要经过领导审批，太麻烦了。或是 为了提高工作效率，对要变更的内容进行分析和审批，但不进行记录，行不行？- 而在项目管理休系建立起来之后，实施过程中会出现工作人员为“省时省力”而略 过变更管理的关键步骤，或是自作主张进行了变更，或是对变更前的计划分析敷 衍了事，使得越來越多的变更不可控，甚至出现由于变更没有做好分析、评估以 及充分准备而带來重人故障的情况。一、系统集成的特点1. 属典型的跨学科，多领域，多厂商合作一般需耍多种学科的配合，牵涉到多个领域，多个厂商，如监控系统, 需要计算机、传感器、电力电了技术等,又

3、如gps系统，需要地理信息技术、 屯子技术、无线射频技术等。而这些设备又牵涉到多个厂家。2、具有创造性由于项目的不同特点和需求，毎一个系统集成工程都和其他工程不一 样，可以说每个系统集成工程都是独一无二的，因此二、项目的变更管1、变更管理的概念项目变更是指在信息系统项0的实施过程中，由于项0环境或者其他原 因对项口产品的功能、性能、构架、技术指标、集成方法、项口的范围基准、进 度基准和成本基准等方面做出的改变。变更管理的实质，是根据项目推进过程屮越来越丰富的项目认知，不断调整 项目努力方向和资源配置，最大程度地满足客户等相关干系人的需求，提升项目 价值。2、项口变更产生的原因由于项目逐渐完善的

4、基本特性，意味着早期的共识随着项目的进行，对项目 不断深入的理解，在项目实施过程发生变化是不可避免的。由于项目很少会保质 保量地交付，因而变更控制必不可少。变更口j能是产品范围，即对交付物的需求发生的变化，也可能是项目范围或 项口的资源、进度等执行过程发生的变化。变更的常见原因如下：（1）产品范围（成果）定义的过失或者疏忽。（2）项目范围（工作）定义的过失或者疏忽。（3）增值变更。（4）应对风险的紧急计划或者回避计划。（5）项目执行过程与项目基准要求不一致带来的被动调整。（6）外部事件。不管是那种变更原因，既然变更是不可避免的，那么我们就必须对项冃中的 变更进行必要的管理。而对项0的变更必然会

5、影响到项目的目标。3、变更的流程（1）提出与接受变更中请。变更提岀应当及时以正式方式进行，并留下书而记录。变更的捉出可以 是齐种形式，但在评估前应以书面形式提出。（2）对变更的初审。变更初审的目的如下。 对变更提出方施加影响，确认变更的必要性，确保变更是有价值的。 格式校验，完整性较验，确保评估所需信息准备充分。 在干系人间就提出供评估的变更信息达成共识。 变更初审的常见方式为变更中请文档的审核流转。(3) 变更方案论证。变更方案的主要作用，首先是对变更请求是否可实现进行论证，如杲可 能实现，则将变更请求由技术要求转化为资源需求，以供ccb决策。常见的方案内容 包括技术评估和经济评估，前者评估

6、需求如何转化为成果，后者评估价值和风险。(4) 项冃变更控制委员会审杳。审查过程，是项目所有者据变更申请及评估方案，决定是否批准变更。 评审过程常包括客户、相关领域的专业人士等。审查通常是文档会签形式，重大的变更 审查可以包括止式会议形式。审查过程应注意分工，项廿投资人虽冇最终的决策权，但通常在专业技 术上并非强项。所以应当在评审过程中将专业评审、经济评审分开，对涉及项目目标和 交付成果的变更，客户的意见应放在核心位置。(5) 发岀变更通知并开始实施。评审通过，意味着项口基准的调整，同吋确保变更方案屮的资源需求及 时到位。项目基准的调整，包括项目目标的确认、最终成果、工作内容和资源、 进度计划

7、的调整。需要强调的是，变更通知后，不只是包括实施项目基准的调整，更要 明确项口的交付日期、成果对相关干系人的影响。如变更造成交付期的调整，应在变更确认时发布，而非在交付前公布。(6) 变更实施的监控。要监控的，除了调整过的项目基准中所涉及变更的内容外，还应当对项 目的整体基准是否反映项目实施情况负责。通过监控行动，确保项冃的整体实施工作是 受控的。变更实施的过程监控，通常由项日经理负责项口基准的监控。管理委员 会监控变更明确的主要成果、进度里程碑等，可以委托监理单位承担监控职责。(7) 变更效杲的评估。变更评估可以从以下几个方面进行。首要的评估依据，是项口基准。还需结合变更的初衷来看，变更所要

8、达到的目的是否已达成。评估变更方案屮的技术论证、经济论证内容与实施过程的差距并推进解 决。(8) 判断发生变更后的项目是否已纳入正常轨道。项口基准调整后，需要确认的是相应的资源配置和人员是否及吋到位， 更需多加关注。之后对项目的整体监控应按新的项目基准进行。涉及变更的项目范围及 进度，在变更后的紧邻监控中，应更多地关注，当确认新的项目基准已经生效则按正常 的项口实施流程进行。三、变更管理的重要性变更管理的目的并不是控制变更的发生，而是对变更进行管理，确保变更有 序进行。对于软件开发项目來说，发生变更的环节比较多，因此变更控制显得格 外重要。it项目中引起变更的因素有两个：一是来自外部的变更要求

9、，如客户要 求修改工作范围和需求等；二是开发过程内部的变更耍求，如为解决测试中发现 的一些错误而修改源码甚至设计。比较而言，最难处理的是来自外部的需求变更, 因为it项口需求变更的概率大，引发的工作量也大（特别是到项口的后期）。变更控制不能仅在过程中靠流程控制，有效的方法是在事前明确定义。 事前控制的一种方法是在项目开始前明确定义，否则“变化”也无从谈起。工作范 围（以前章节谈过）；另一种方法是评审，特别是对需求进行评审，这往往是项 目成败的关键。需求评审的目的不仅是“确认"，更重要的是找出不正确的地方并 进行修改，使其尽量接近“真实"需求。另外，需求通过正式评审后应作为重

10、要基 线，从此之后即开始对需求变更进行控制。虽然可以事前定义好变更控制流程，但在各种压力下真正“控制”起来其 实非常困难。卜面给大家分析一个变更失控的项目案例：王先生刚出任项目经理，并承接了一个中型软件项目。上任吋公司高层 再三叮咛他一定要尊重客户，充分满足客户需求。项口开始比较顺利，但进入到 后期，客户频繁的需求变更带来很多额外工作。王先生动员大家加班，保持了项 目的正常进度，客户相当满意。但需求变更却越來越多。为了节省时间，客户的业务人员不再向王先生 申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任 何记录，很多相关文档也忘记修改。很快王先生就发现：需求、设计和代码无

11、法 保持一致，甚至没有人能说清楚现在系统“到底改成什么样了雹版本管理也出现 了混乱，很多人违反配置管理规定，直接在测试环境屮修改和编译程序。但在进 度压力卜，他也只能佯装不知此事。但因频繁出现“改好的错谋又重新出现”的问 题，客户已经明确表示“失去了耐心而这述只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造 成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间 解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平覽 更糟糕的是，因为担心系统中还隐含着其他类似的错谋，客户高层对项fi的质量 也疑虑重重。随后发生的事情让王先生更加为难：客户的两个负责人对界

12、面风格的看 法不一致，并为此发生了激烈争执。王先生知道如果发表意见可能会得罪其中一 方，于是保持了沉默。最终客户决定调整所有界面，王先生只好立刻动员大家抓 紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后，客户方原来 发生争执的两人这次却非常一致，同吋气愤地质问王先生：“为什么你不早点告 诉我们要延期！早知这样才不会让你改呢！ ”王先生委用极了，疑惑自己到底错 在哪里了。从上面的案例中可以看到各种变更失控的现象和造成的后果，王先生主 要犯了几个错误：（1）没有明确的授权事先应该明确客户方有权提出变更中请的人员和实施方有权受理变更 的人员，并要控制双方人数。这样做才可以对变更冇整体的控

13、制。绝不能进行“私 下交易”，而没有人能完整地知道到底改了些什么。另外，授权双方接口人的好 处是可以屏蔽客户内部的矛盾，如果只有一个接口人，内部尚未达成一-致吋变更 是无法提出来的。从实际经验看，授权可以显著减少变更，特别是那些因内部看 法不同而导致的反复变更。（2）对变更没有进行必要的审核并不是所有的变更都耍修改，也不是所有变更都要立刻修改，审核的冃 的就是为了决定是否需要修改和什么时候修改。比如案例中提到的界面风格问 题，就可以先不修改，或者规划一下修改的吋间待到以后进行优化。另夕卜，对于 核心模块的修改要严格审核把关，否则会引起全局问题，案例中提到的“擅自修 改核心模块”造成的事故就是因

14、为没冇审核而造成的。（3）对变更的影响没有评估变更都是有代价的，应该评估一下变更的代价和对项目的影响，要让客 户了解变更的后果，并与客户一起做判断。案例屮客户最后的质问正是因为没有 事前告诉客户变更的影响造成的。如果客户不知道你为变更付出的代价，对你的 辛苦便难以体会。案例中客户刚开始对王先生加班处理变更相当满意，但只是对 工作态度满意，后期当变更引发一系列问题时客户并没有感谢王先生的苦劳。（4）应该让客户确认是否接受变更的代价在评估代价并且与客户讨论的过程屮，可以请客户一起做判断：“我可 以修改，但您能接受后果吗？案例中如果王先生评估了修改界面的工作量并 请客户确认，则有三种可能：客户预先接受延期这一后果，也就不会再质问王先 生了；如果客户认为代价太大，则王先生就不必修改了；如果认为可以缩短延期 吋间，则王先生至少争取到了与客户协商的机会，让客户知道为此项口组需要付 出加班的代价，吃个“明亏”。上述步骤完成后，要等客户确认变更再组织实施变更的相关工作。变更 要按配置管理（读者可以杳阅相关的资料）的规定执行，确保所有交付物的一致 性和完整性。同时，对所冇的变更要跟踪和验证，确保都按要求完成了。最后，要特别提醒的是：要在项口开始就对项口组和客户进行宣传和培 训，让所有成员都理解变更控制的重要意义；在项目过程中