论系统集成项目中的变更管理的重要性 2012年2月25日 唐元龙 摘要：文章论述了系统集成特点、变更管理的重要性等内容 关键词：系统集成 变更管理 目前国内大大小小的系统集成公司很多，。可是这些公司有的是昙花一现，有的却是经久不衰，成为系统集成行业的领头羊，而真正能做的好的没有多少。究其原因，对系统集成的工程管理认识不够，特别是对项目中的变更管理缺乏工程管理经验与方法，工程管理不规范是其主要原因。 系统集成工程项目实施中的变更管理对每个具体的项目而言，各不相同，千变万化，对一个新的项目经理，往往是千头万序，顾此失彼，而项目的周期短，工作量大，时间紧迫，等明白过来，此时已悔之晚矣。 在项目的变更过程中，常会听到客户这样的抱怨：“只是要改一个系统参数，很简单的事情，非要做一堆分析，还要经过领导审批，太麻烦了。或是为了提高工作效率，对要变更的内容进行分析和审批，但不进行记录，行不行？”而在项目管理体系建立起来之后，实施过程中会出现工作人员为“省时省力”而略过变更管理的关键步骤，或是自作主张进行了变更，或是对变更前的计划分析敷衍了事，使得越来越多的变更不可控，甚至出现由于变更没有做好分析、评估以及充分准备而带来重大故障的情况。 一、系统集成的特点 1.属典型的跨学科，多领域，多厂商合作 一般需要多种学科的配合，牵涉到多个领域，多个厂商，如监控系统，需要计算机、传感器、电力电子技术等，又如GPS系统，需要地理信息技术、电子技术、无线射频技术等。而这些设备又牵涉到多个厂家。 2、具有创造性 由于项目的不同特点和需求，每一个系统集成工程都和其他工程不一样，可以说每个系统集成工程都是独一无二的，因此 二、项目的变更管 1、变更管理的概念 项目变更是指在信息系统项目的实施过程中，由于项目环境或者其他原因对项目产品的功能、性能、构架、技术指标、集成方法、项目的范围基准、进度基准和成本基准等方面做出的改变。 变更管理的实质，是根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足客户等相关干系人的需求，提升项目价值。 2、项目变更产生的原因 由于项目逐渐完善的基本特性，意味着早期的共识随着项目的进行，对项目不断深入的理解，在项目实施过程发生变化是不可避免的。由于项目很少会保质保量地交付，因而变更控制必不可少。 变更可能是产品范围，即对交付物的需求发生的变化，也可能是项目范围或项目的资源、进度等执行过程发生的变化。 变更的常见原因如下： （1）产品范围（成果）定义的过失或者疏忽。 （2）项目范围（工作）定义的过失或者疏忽。 （3）增值变更。 （4）应对风险的紧急计划或者回避计划。 （5）项目执行过程与项目基准要求不一致带来的被动调整。 （6）外部事件。 不管是那种变更原因，既然变更是不可避免的，那么我们就必须对项目中的变更进行必要的管理。而对项目的变更必然会影响到项目的目标。 3、变更的流程 (1)提出与接受变更申请。 变更提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式， 但在评估前应以书面形式提出。 (2)对变更的初审。 变更初审的目的如下。 ①对变更提出方施加影响，确认变更的必要性，确保变更是有价值的。 ②格式校验，完整性较验，确保评估所需信息准备充分。 ③在干系人间就提出供评估的变更信息达成共识。 ④变更初审的常见方式为变更申请文档的审核流转。 (3)变更方案论证。 变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则 将变更请求由技术要求转化为资源需求，以供CCB决策。常见的方案内容包括技术评 估和经济评估，前者评估需求如何转化为成果，后者评估价值和风险。 (4)项目变更控制委员会审查。 审查过程，是项目所有者据变更申请及评估方案，决定是否批准变更。评审过程常 包括客户、相关领域的专业人士等。审查通常是文档会签形式，重大的变更审查可以包 括正式会议形式。 审查过程应注意分工，项目投资人虽有最终的决策权，但通常在专业技术上并非强 项。所以应当在评审过程中将专业评审、经济评审分开，对涉及项目目标和交付成果的 变更，客户的意见应放在核心位置。 (5)发出变更通知并开始实施。 评审通过，意味着项目基准的调整，同时确保变更方案中的资源需求及时到位。 项目基准的调整，包括项目目标的确认、最终成果、工作内容和资源、进度计划的 调整。需要强调的是，变更通知后，不只是包括实施项目基准的调整，更要明确项目的 交付日期、成果对相关干系人的影响。如变更造成交付期的调整，应在变更 确认时发布， 而非在交付前公布。 (6)变更实施的监控。 要监控的，除了调整过的项目基准中所涉及变更的内容外，还应当对项目的整体基 准是否反映项目实施情况负责。通过监控行动，确保项目的整体实施工作是受控的。 变更实施的过程监控，通常由项日经理负责项目基准的监控。管理委员会监控变更 明确的主要成果、进度里程碑等，可以委托监理单位承担监控职责。 (7)变更效果的评估。 变更评估可以从以下几个方面进行。 首要的评估依据，是项目基准。 还需结合变更的初衷来看，变更所要达到的目的是否已达成。 评估变更方案中的技术论证、经济论证内容与实施过程的差距并推进解决。 (8)判断发生变更后的项目是否已纳入正常轨道。 项目基准调整后，需要确认的是相应的资源配置和人员是否及时到位，更需多加关 注。之后对项目的整体监控应按新的项目基准进行。涉及变更的项目范围及进度，在变 更后的紧邻监控中，应更多地关注，当确认新的项目基准已经生效则按正常的项目实施 流程进行。 三、变更管理的重要性 变更管理的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。对于软件开发项目来说，发生变更的环节比较多，因此变更控制显得格外重要。 IT项目中引起变更的因素有两个：一是来自外部的变更要求，如客户要 求修改工作范围和需求等；二是开发过程内部的变更要求，如为解决测试中发现的一些错误而修改源码甚至设计。比较而言，最难处理的是来自外部的需求变更，因为IT项目需求变更的概率大，引发的工作量也大（特别是到项目的后期）。 变更控制不能仅在过程中靠流程控制，有效的方法是在事前明确定义。事前控制的一种方法是在项目开始前明确定义，否则“变化”也无从谈起。工作范围（以前章节谈过）；另一种方法是评审，特别是对需求进行评审，这往往是项目成败的关键。需求评审的目的不仅是“确认”，更重要的是找出不正确的地方并进行修改，使其尽量接近“真实”需求。另外，需求通过正式评审后应作为重要基线，从此之后即开始对需求变更进行控制。 虽然可以事前定义好变更控制流程，但在各种压力下真正“控制”起来其实非常困难。下面给大家分析一个变更失控的项目案例： 王先生刚出任项目经理，并承接了一个中型软件项目。上任时公司高层再三叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。王先生动员大家加班，保持了项目的正常进度，客户相当满意。 但需求变更却越来越多。为了节省时间，客户的业务人员不再向王先生申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快王先生就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。 而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。 随后发生的事情让王先生更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。王先生知道如果发表意见可能会得罪其中一 方，于是保持了沉默。最终客户决定调整所有界面，王先生只好立刻动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问王先生：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”王先生委屈极了，疑惑自己到底错在哪里了。 从上面的案例中可以看到各种变更失控的现象和造成的后果，王先生主要犯了几个错误： （1） 没有明确的授权 事先应该明确客户方有权提出变更申请的人员和实施方有权受理变更的人员，并要控制双方人数。这样做才可以对变更有整体的控制。绝不能进行“私下交易”，而没有人能完整地知道到底改了些什么。另外，授权双方接口人的好处是可以屏蔽客户内部的矛盾，如果只有一个接口人，内部尚未达成一致时变更是无法提出来的。从实际经验看，授权可以显著减少变更，特别是那些因内部看法不同而导致的反复变更。 （2） 对变更没有进行必要的审核 并不是所有的变更都要修改，也不是所有变更都要立刻修改，审核的目的就是为了决定是否需要修改和什么时候修改。比如案例中提到的界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改要严格审核把关，否则会引起全局问题，案例中提到的“擅自修改核心模块”造成的事故就是因为没有审核而造成的。 （3） 对变更的影响没有评估 变更都是有代价的，应该评估一下变更的代价和对项目的影响，要让客户了解变更的后果，并与客户一起做判断。案例中客户最后的质问正是因为没有事前告诉客户变更的影响造成的。如果客户不知道你为变更付出的代价，对你的辛苦便难以体会。案例中客户刚开始对王先生加班处理变更相当满意，但只是对工作态度满意，后期当变更引发一系列问题时客户并没有感谢王先生的苦劳。 （4） 应该让客户确认是否接受变更的代价 在评估代价并且与客户讨论的过程中，可以请客户一起做判断：“我可以修改，但您能接受后果吗？”。案例中如果王先生评估了修改界面的工作量并 请客户确认，则有三种可能：客户预先接受延期这一后果，也就不会再质问王先生了；如果客户认为代价太大，则王先生就不必修改了；如果认为可以缩短延期时间，则王先生至少争取到了与客户协商的机会，让客户知道为此项目组需要付出加班的代价，吃个“明亏”。 上述步骤完成后，要等客户确认变更再组织实施变更的相关工作。变更要按配置管理（读者可以查阅相关的资料）的规定执行，确保所有交付物的一致性和完整性。同时，对所有的变更要跟踪和验证，确保都按要求完成了。 最后，要特别提醒的是：要在项目开始就对项目组和客户进行宣传和培训，让所有成员都理解变更控制的重要意义；在项目过程中要对变更控制的执行情况进行审计，发现违反规定的事件要严肃处理，否则过程很快就会失效。 综上所述，变更控制的目的是管理变化。变更控制对项目成败有重要影响，事前要明确定义，事中要严格执行。实施变更之前有四个重要控制点：授权、审核、评估和确认；在实施过程要进行跟踪和验证，确保变更被正确执行。 参考文献： 系统集成项目管理工程师教程 论计算机信息系统集成项目中的变更管理 作者简介： 唐元龙，安徽世腾信息技术有限责任公司系统集成部经理、总工程师，曾多次担当过大型项目项目经理。 本文来源：https://www.wddqw.com/doc/c2cacc27bdd5b9f3f90f76c66137ee06eff94ea6.html