古老虾的信息化博客

      配置管理(Configuration Management，CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。

      配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。其最终目标是实现软件产品的完整性、一致性、可控性，使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。

      早在七十年代初期加利福利亚大学的Leon Presser教授就撰写了一篇论文，提出控制变更和配置的概念，之后在1975年，他成立了一家名为SoftTool的公司，开发了自己的配置管理工具：CCC，这也是最早的配置管理工具之一。之后，随着软件开发规模的逐渐增大，越来越多的公司和团队意识到了软件配置管理的重要性，而相应的软件配置管理工具也如雨后春笋一般，纷纷涌现，比较有代表性的有：Marc Rochkind的SCCS(Source Code Control System)和Walter Tichy的RCS(Revision Control System)，这两种工具对日后的配置管理工具的发展做出了重大的贡献，目前绝大多数广泛使用的配置管理工具基本上都是基于这两者的设计思想和体系架构。

一、配置管理在软件开发过程和项目管理过程中的作用

      随着软件系统的日益复杂化和用户需求、软件更新的频繁化，配置管理逐渐成为软件生命周期中的重要控制过程，在软件开发过程中扮演着越来越来重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面，同时对软件开过程的宏观管理，即项目管理，也有重要的支持作用。良好的配置管理能使软件开发过程有更好的可预测性，使软件系统具有可重复性，使用户和主管部门用软件质量和开发小组有更强的信心。

      软件配置管理的最终目标是管理软件产品。由于软件产品是在用户不断变化的需求驱动下不断变化，为了保证对产品有效地进行控制和追踪，配置管理过程不能仅仅对静态的、成形的产品进行管理，而必须对动态的、成长的产品进行管理。由此可见，配置管理同软件开发过程紧密相关。配置管理必须紧扣软件开发过程的各个环节：管理用户所提出的需求，监控其实施，确保用户需求最终落实到产品的各个版本中去，并在产品发行和用户支持等方面提供帮助，响应用户新的需求，推动新的开发周期。通过配置管理过程的控制，用户对软件产品的需求如同普通产品的订单一样，遵循一个严格的流程，经过一条受控的生产流水线，最后形成产品，发售给相应用户。从另一个角度看，在产品开发的不同阶段通常有不同的任务，由不同的角色担当，各个角色职责明确，泾渭分明，但同时又前后衔接，相互协调。

      好的配置管理过程有助于规范各个角色的行为，同时又为角色之间的任务传递提供无缝的接合，使整个开发团队象一个交响乐队一样和谐而又错杂地行进。正因为配置管理过程直接连接产品开发过程、开发人员和最终产品，这些都是项目主管人员所关注的重点，因此配置管理系统在软件项目管理中也起着重要。配置管理过程演化出的控制、报告功能可帮助项目经理更好地了解项目的进度、开发人员的负荷、工作效率和产品质量状况、交付日期等信息。同时配置管理过程所规范的工作流程和明确的分工有利于管理者应付开发人员流动的困境，使新的成员可以快速实现任务交接，尽量减少因人员流动而造成的损失。

二、配置管理的功能

      配置管理系统应该具备以下主要功能：

并行开发支持：因开发和维护的原因，要求能够实现开发人员同时在同一个软件模块上工作，同时对同一个代码部分作不同的修改，即使是跨地域分布的开发团队也能互不干扰，协同工作，而又不失去控制；
修订版管理：跟踪每一个变更的创造者、时间和原因，从而加快问题和缺陷的确定 ；
版本控制：能够简单、明确地重现软件系统的任何一个历史版本 ；
产品发布管理：管理、计划软件的变更，与软件的发布计划、预先定制好的生命周期或相关的质量过程保持一致；项目经理能够随时清晰地了解项目的状态 ；
建立管理：基于软件存储库的版本控制功能，实现建立（build）过程自动化 ；
过程控制：贯彻实施开发规范，包括访问权限控制、开发规则的实施等 ；
变更请求管理：跟踪、管理开发过程中出现的缺陷（Defect）、功能增强请求（RFE）或任务（Task），加强沟通和协作，能够随时了解变更的状态 ；
代码共享：提供良好的存储和访问机制，开发人员可以共享各自的开发资源 ；

三、配置管理的流程

图1 配置管理流程图

1、制定配置管理计划

      配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划。

2、配置库管理
      配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库，例如清楚垃圾文件、备份配置库等。

3、版本控制
      在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比老版本“好”，所以不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
      配置项的状态有三种：“草稿”、“正式发布”和“正在修改”，本规程制定了配置项状态变迁与版本号的规则。

4、变更控制
      在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。
      修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制规则执行即可。
      当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据“申请－审批－执行变更－再评审－结束”的规则执行。

5、配置审计
      为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，质量保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动，是质量保证人员的工作职责之一。

四、配置管理的实施

      实施配置管理系统，一般的步骤和需要考虑的问题如下：

      规划、调整网络开发环境

      一个规划良好的开发环境，是实施配置管理系统的前提。在此阶段我们要对配置管理系统做出规划，主要考虑以下问题：

     * 网络的带宽、拓扑结构
      *服务器的选择、命名规范
      *存储区的定位
      *开发人员及组的命名规约等

      设计配置管理库

      根据项目开发的要求，设计开发资源的存储模式，良好的存储模式有利于减轻管理上的负担，增强配置管理库的访问性能，同时便于控制访问权限，保护软件资产。

      定义配置管理系统的角色

      在此阶段，我们需要确定与配置管理相关的所有角色，包括他们的相应的活动。在开发过程中，一个开发人员可能兼任多种角色，但一项任务在同一时刻只能由一个角色来执行。

      一般配置管理中的角色主要包括：

       项目经理：项目经理在配置管理方面的职责是依靠配置管理员、系统管理员和系统体系结构设计人员的帮助，制定项目的组织结构和配置管理策略。这些工作包括：定制开发子系统，定制访问控制，制定常用策略，制定集成里程碑，以及进行系统集成；

      配置管理员：配置管理员的职责是根据项目经理制定的开发组织结构和策略，实施、维护配置管理的环境。其主要职责如下：创建配置管理库，对存储库进行日常备份和恢复，维护配置管理环境，及管理配置管理相关的用户；
      软件开发人员：软件开发人员依据项目的开发和配置管理策略，创建、修改和测试开发工件；
      集成人员：对软件进行归并，形成相应的基线或发布版本 ；
      QA人员：需要对软件配置管理有较深的认识，其主要工作是跟踪当前项目的状态，测试，报告错误，并验证其修复结果；

      制定配置管理流程

      这是配置管理实施的一个重要阶段，其主要目的是根据项目开发的需要，制定相应的配置管理流程，以更好地支持开发，主要活动包括：

      定制并行开发策略：合理的并行开发策略应该具有以下特点：协调项目的复杂性和需求，统一创建分支类型和元数据，为开发过程中的变更集成制定有效的规范，适时反映开发过程中方法和需求的变化
发布版本管理：软件开发过程中的一个关键活动是提取工件的相关版本，以形成软件系统的阶段版本或发布版本，我们一般将其称为稳定基线。一个稳定基线代表新开发活动的开始，而一系列定制良好的活动之后又会产生一个新的稳定基线。有效地利用此项功能，在项目开发过程中可以自始至终管理、跟踪工件版本间的关联。

      相关人员的培训

     一般来讲，实施配置管理系统，相关人员需要接受以下培训：

      管理员培训：针对配置管理员，主要学习配置管理工具管理相关内容
      开发人员培训：针对开发人员，主要学习配置管理工具与开发相关的常用操作
      管理流程培训：针对全体人员，目的是了解配置管理策略和流程，以及如何与开发管理、项目管理相结合

五、配置管理经验谈

      围绕配置管理,世界一些致力于软件工程研究的公司在深入理解ISO 9000的基础上, 推出了各种符合ISO 9000配置管理标准的工具软件,如INTERSOLV公司的PVCS,Rational公司的Clear Case等。这些配置管理工具面向软件规范化、工程化、自动化的需要,帮助开发团队提高科学管理水平,从而提高工程效率,降低工程成本。现以PVCS为例,结合我们的实际经验,谈谈我们实施配置管理的益处:

1. 节约费用

      (1) 缩短开发周期

      利用PVCS的Version Manager对程序资源进行版本管理和跟踪,建立公司的代码知识库,保存开发过程中每一过程版本,这样大大提高了代码的重用率,还便于同时维护多个版本和进行新版本的开发,防止系统崩溃,最大限度地共享代码。同时项目管理人员可以通过Version Manager查看项目开发日志,测试人员可以根据开发日志和不同版本对软件进行测试,工程人员可以从Version Manager上得到不同的运行版本,并且Version Manager 可以安装在Web Server供外地施工人员存取最新版本,无需开发人员亲临现场。

      利用Tracker组建开发团体之间的问题跟踪及消息通迅,通过其Notify模块与电子邮件结合起来大大加强了开发团体之间的沟通,Reporter模块可对发现的问题进行整理、以报表方式分类报出,作为开发的指导。

      以上为PVCS的两个主要模块,科学地应用可以大大提高开发效率,避免了代码覆盖、沟通不够、开发无序的混乱局面,如果利用了公司原有的知识库,则更能提高工作效率,缩短开发周期。

      (2) 减少施工费用

      利用PVCS进行软件配置管理后,建立开发管理规范,把版本管理档案挂接在公司内部的Web服务器上,内部直接通过Netscape访问Version Manager,工程人员通过远程进入内部网,获取所需的最新版本。开发人员无需下现场,现场工程人员通过对方系统管理员收集反馈意见,书面提交到公司内部开发组项目经理,开发组内部讨论决定是否修改,并作出书面答复。这样做,可以同时响应多个项目点,防止开发人员分配到各个项目点、分散力量、人员不够的毛病,同时节约大量的旅差费用。

2. 有利于知识库的建立

      (1) 代码对象库

      软件代码是软件开发人员脑力劳动的结晶,也是软件公司的宝贵财富,长期开发过程中形成的各种代码对象就像一个个零件坯一样,是快速生成系统的组成部分。长期的一个事实是:一旦某个开发人员离开工作岗位,其原来所作的代码便基本成为垃圾,无人过问。究其原因,就是没有专门对各人的有用对象进行管理,把其使用范围扩大到公司一级,进行规范化,加以说明和普及。Version Manager为对象管理提供了一个平台和仓库,有利于建立公司级的代码对象库。

      (2) 业务及经验库

      通过PVCS Version Manager的注释及Tracker,可形成完整的开发日志及问题集合,以文字方式伴随开发的整个过程,不依某个人的转移而消失,有利于公司积累业务经验,无论对版本整改或版本升级,都具有重要的指导作用。

3. 规范管理

      (1) 量化工作量考核

      传统的开发管理中,工作量一直是难以估量的指标,靠开发人员自已把握,随意性相当大;靠管理人员把握,主观性又太强。采用PVCS管理后,开发人员每天下班前对修改的文件 Check In,其中记述当天修改细节描述,这些描述可以作为工作量的衡量指标。

      (2) 规范测试

      采用PVCS以后,测试有了实实在在的工作,测试工作人员根据每天的修改细节描述对每一天的工作做具体的测试,对测试人员也具有可考核性,这样环环相扣,大大减少了其工作的随意性。

      (3) 加强协调与沟通

      采用PVCS后,通过Version Manager文档共享及其特定锁机制、Tracker与电子邮件的集成,大大加强了项目成员之间的沟通,做到有问题及时发现、及时修改、及时通知,但又不额外增加很多的工作量。

六、配置管理的精髓

具体来讲，配置管理包含如下内容：

􀂾 标识：识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。
􀂾 控制：通过一定的机制控制对配置项的修改
􀂾 状态报告：记录并报告配置项以及元数据的状态。
􀂾 配置审计：确认产品的完整性并维护配置项间的一致性。

从上面的描述，我们知道，配置管理的基本单位是配置项。
从“哲学”意义上讲，它记录配置项的三个方面：
􀂾 从哪里来？此项可归结为WWW的问题，（Who）谁创建的？（When）什么时间创建的？（Why）为什么创建此配置项？
􀂾 当前在哪里？此项纪录配置项当前的存储位置以及状态。
􀂾 将到哪里去？通过配置控制来把配置项“组装”到正确的版本中去。

      配置项可以是大粒度的，也可以是小粒度的。如果跟踪个别需求，那么不必要把整个需求规格说明文档定义为一个配置项，可以把每个需求定义为配置项；如果把软件开发工具也放入配置管理系统，那么把配置项定义为文件级就不合适了，只需要跟踪开发工具的版本，即把整个配置工具定义为一个配置项就足够了。

      简而言之，配置项可以是文件级粒度的，也可以使文件版本级粒度的。当然，粒度越小管理的成本越高，但是配置的精度也就越高。

      一个完整的SCM系统要具有三个核心功能：版本控制、变更控制、配置控制以及两个支持功能：状态统计和配置审计。

      版本控制

      版本，亦称配置标识，是指某一特定对象的具体实例的潜在存在。这里的某一特定对象是指版本维护工具管理的软件组成单元，一般是指源文件；具体实例则是指软件开发人员从软件库中恢复出来的某软件组成单元的具有一定内容和属性的一个真实拷贝。例如，对源文件的每一次修改都生成一个新版本。

      版本控制就是对在软件开发过程中所创建的配置对象的不同版本进行管理，保证任何时候都能取到正确的版本以及版本的组合。

      当前，这方面典型的工具有如VSS和CVS。

      变更控制

      变更控制是通过对变更请求（Change Request，简称CR）进行分类、追踪和管理的过程来实现的。

      变更的起源有两种：功能变更和缺陷修补（Bug-Fix）。功能变更是为了增加或者删除某些功能。缺陷修补则是对已存在的缺陷进行修补。

      对变更进行控制的机构称为变更控制委员会（Change Control Board，简称CCB）。变更控制委员会要定期召开会议，对近期所产生的变更请求进行分析、整理，并做出决定。而且要遵循一定的变更机制。

      下面是一个典型的变更机制：

      我们可以随着变更过程的推进，提升配置项的状态。 这方面的工具有Bugzilla。
 

      配置控制

      配置控制使用户能够通过对适当版本的选择来组成特定属性（配置）的软件系统，这种灵活的“组装”策略使得配置管理系统象搭积木似的使用已有的积木（版本）组装成各种各样、不同功能的模型。
软件产品的每个版本都是一组配置项（源代码、文档、数据）的集合。配置控制就是要保证每个配置的完整性和精确性。

      举个例子来说，我们要发布软件的32.6版本，那么我们就要把源代码、文档、数据中所有这个应该包含到这个版本中的正确配置项检出。

      在开发过程中，我们在不同阶段要建立各种基线。基线的建立是配置控制功能的典型应用。所以说，基线是具有里程碑意义的一个配置。

      一般的商业软件配置管理工具都具有配置控制的功能，只是灵活性和精确性有差别。

      状态报告
状态报告要回答所谓4W的问题：
What：发生了什么事？
Who：谁做的此事？
When：此事是什么时候发生的？
Why：为什么做此事？
状态报告还要能够报告所有配置项以及变更请求的状态。

      配置审计

      配置审计要审查整个配置管理过程是否符合规范，配置项是否与需求一致，记录正确，配置的组成是否具有一致性等等。

      由于现在软件行业越来越重视质量，许多项目专门成立质量保证部门专门来进行配置审计。所以现在也可以说，配置审计是一个SQA（软件质量保证）活动。

      配置管理的商业模型

      配置管理的实施包括两部分：工具和规范。

     在软件开发过程自动化的今天，没有工具的支持而实施配置完整的配置管理是不能想象的。因此选择一个符合公司或项目的工具至关重要。在配置管理系统中，我们可归纳出四种模型。当前商业工具一般采用其中一种或几种模型。

      我们通过对商业模型的理解可以帮助我们了解某种工具是否适合我们公司或项目。

      CICO模型

      CICO模型主要关注的是单个文件的版本控制。图显示了一个支持CICO模型的CM系统的工作过程。用户利用库和文件系统来进行工作。文件被版本化并存储到库中，新版本的产生是由库工具控制的。然而， 文件在库中不是可以直接存取的，用户必须去检出（即Check Out）一个文件的版本到工作空间中以便读取它的内容。更改后的文件可以被检入库中（即Check in）,产生文件的一个新版本。
此模型的代表工具是SCCS和CVS。

      组织模型

      组织模型由CICO模型自然导出，建立于构件版本图的基础之上，同时依赖于存储库和工作空间的概念，可以通过对构件加锁进行并发控制。组织模型的重点是在CM系统支撑下加强了对创建配置、对有关的历史信息的管理和使用他们作为工作环境的支持。

      组织模型中的配置由系统模型和版本选择规则组成。系统模型列出了组成系统的所有的构件。版本选择规则指出了组成配置的每一个构件选择版本。选择规则用于系统模型，选择构件版本，即绑定一构件到某一版本。这个模型的操作方式是：开发员根据模型的构件定义整个系统，并在每一步骤中给每个构件选择合适的版本。版本操作的工作方式如图所示。

      CM支持主要关心的是维护系统和其构件的版本历史，并选择符合一致性配置的构件版本。只有在所选构件的版本与所选其它构件版本一致时才认为一个配置版本。
此模型的代表工具是CCC。

      长事务模型

      长事务模型主要支持包括一系列原子变更的全系统演变和由团队开发员对系统变更的协调。开发员主要操作配置而非单独的构件。事务提交的结果是新配置版本，一系列连续的变更结果生成一系列的配置版本，称为开发路径。
在长事务模型中，开发员主要的工作对象时配置，开发员首先选择系统配置版本，接下来把关注重点放在系统结构上。构件的版本由配置隐式决定。长事务由两个概念组成：工作空间和并发控制方案。工作空间来源于存储库或一个封闭工作空间中的一个固定配置。工作空间由工作配置和一系列已保存的配置组成。工作配置代表构件和系统结构能够被动态更改的配置。提供通过工作空间进行的透明库访问、将高效的库存储技术应用于工作空间和管理派生构件的版本。

此模型的代表系统是NSE。

      变更集模型

结束语

      主要集中于对系统配置的逻辑变更的支持。在这个模型中引入的变更集表示组成逻辑变更的对不同构件修改的集合，它是创建变更的活动完成后对逻辑变更的记录。支持这个模型的CM系统用户可以直接操作变更集。在变更集模型中，配置可描述为由基线和一组变更集组成。

      变更传播给其它配置可通过包含各自变更集来进行。开发员使用不同的集成策略将逻辑变更集包含到一个新的系统发行中。这样的好处非常明显，例如，我们现在维护10个不同版本的产品，现在要对所有的版本修改一个缺陷（Bug）。如果相同的工具简单的重复10次显然是不可接受的。而通过变更集把这个逻辑变更从一个版本自由的传到另外一个版本。

      开发员可跟踪逻辑变更和确定这些变更是否属于特定配置。这种配置管理的方法，因为其将重点放于逻辑变更上，所以被称作面向变更的配置管理。它不同于现在的其他3种CM模型，因为其它3种CM模型使用的面向版本的方法把重点放在构件和配置版本上。

      在单一构件的情况下，变更集是两个文件版本之间区别的集合，通常指的是增量内容。对配置来说，变更集就是两个配置版本之间区别的集合。这组区别就是两个配置版本间的修改构件增量集合，即变更构件集的增量。

      面向变更的观点不同于面向版本的观点。这有两点不同，一是逻辑变更的显式表示允许对与单个构件和配置有关的变更集进行跟踪。二是引用单个变更集并有选择地将它们纳入配置管理中的这种能力提供了对系统演化管理的支持，这种演化是基于将逻辑变更传播到维护的系统配置进行的。
此模型的代表工具是UCM和SABLIME。

结束语

      配置管理本身无论从理论和实践都在不断丰富和发展。例如，配置管理应用于“知识库”的管理就产生了“内容管理”这一新的领域。配置管理提供的状态报告和数据统计也为软件度量提供了决策依据。配置管理为项目管理提供了各种监控项目进展的视角，为项目经理确切掌握项目进程提供了保证。配置管理也为开发人员提供了一个协作的平台，在此平台上，大家能够更有效率的交流和协作。可以说，配置管理是软件开发的基石！
      配置管理近年来在中国得到了极大的认可，可以毫不夸张的说，没有配置管理，就谈不上软件开发，就谈不上软件质量，就谈不上软件业的发展。随着软件业规模的扩大，配置管理的实施不是要不要的问题，而是什么时间、如何实施的问题了。

企业现场案例：

郑  伟，45岁，S集团副总裁，分管人事、信息、财务，此次项目的负责人；
欧阳雪，35岁，S集团营销总监，此次项目总监；

钟  剑，33岁，S集团信息中心实施部经理，此次项目经理；

许建国，38岁，S集团浙江分公司总经理，此次项目浙江分公司负责人；

王新水，32岁，S集团浙江分公司杭州办事处经理，此次项目杭州办事处负责人；

徐筱芳，27岁，S集团浙江分公司杭州办事处文员，此次项目杭州办事处协调员。

  “什么？只给我两周不到的时间？”刚刚休完探亲假，还没来得及休整的钟剑被急匆匆地叫回了总部，听到这个他们准备了了两年的移动商务的项目要上马，他不知道是喜还是忧。“是的，总裁昨天已经成立了项目委员会，销售、市场、人事的负责人都是项目组的成员，并由总裁亲自指挥。要求8月16日30个分公司的各1个办事处上线！”郑伟（S集团副总裁，分管人事、信息、财务，此次项目的负责人）高兴地对钟剑说。

  “可是郑总，您知道，项目组需要时间成立，我们需要与软件供应商、运营商谈判，还有硬件设备采购，系统搭建、安装、调试、修改，需要进行各地基础数据的收集、整理、导入，还有……”

  “不要和我说这些，这不是你一直想上的项目吗？我已经帮你把所有需要参与的各层领导拉进项目组了，接下来就看你这个项目经理怎么施展啦……”

听了郑总一番话，钟剑没有再做任何的辩解，在集团工作了这么久了，他怎会不深知公司的做事风格呢？“好的，我尽力吧，这就回去准备。”

着手移动商务项目

S集团是国内一家大型的食品集团企业，总部设在上海，在全国拥有30个分公司，250个办事处，而员工总人数更是多达20000余人，其中终端销售人员超过14000人，年营业额接近60亿。2003年，S集团正式成立由直属集团总裁领导的信息中心，总人数45人 。

作为这样一家大型的集团分销型企业，对多个分公司的统一管理和渠道终端的掌控成了重中之重。为了能够更有效地进行市场分析和预测、更好地管控终端销售人员的销售行为，S集团在2004年底就开始尝试移动终端技术在终端数据采集中的应用，并在2005年进行了两轮技术可行性和业务可行性的测试运行，并着手加快该项目在集团的推行。这不，项目说开始就开始了。项目的主要目标就是规范销售行为的管理，通过使用手机为数据收集和定位的载体，管理销售人员的行为以及采集终端数据。

基础数据采集遇困难

8月11日，下午1点。“钟经理，我们发下去的数据采集到目前为止只有一半的办事处文员回复了，这样下去时间来不及了。”负责收集数据的小王急匆匆地跑进钟剑的办公室，气喘吁吁的说。“赶紧让销售部门去催促，让他们务必把事情落实到责任人身上。另外，现在的数据倒入问题软件公司有没有解决呢？”钟剑问道。“已经解决了，他们将负责数导入，但需要给他们一些时间。”

8月17日，上午10点。 徐筱芳提出了新问题：目前，收集上来的数据中，除了杭州办事处外，还有新疆办事处和哈尔滨办事处的数据。可是现在系统内的数据都乱了。经过检查发现，原因是在期初进行数据准备时，文员没有按照标准准备数据，导致数据混乱。

8月18日，下午3点。项目组紧急召开会议。在会议中，项目组决定重新整理数据，要求各办事处严格按照项目组标准模板和要求组织数据；并按照进度计划调整上线时间，将上线时间调整至9月1日。

经过这样的一个过程，项目如期得以下发落实，9月1日，系统如期在试点办事处上线，各办事处的数据不再混乱。

统计报表混乱，问题层出不穷

9月15日，发现统计报表分析与日常手工报表发生严重不符，经仔细检查，发现问题是：上线前销售渠道分类没有统一的严格规定，虽然在组织数据时销售管理部出了一套标准的销售分类，但由于各办的理解相同，导致数据分类错误。30个办事处，28万家终端店头的数据被错误地分类融合在一起，这个乱真是理不清。

9月20日，在这样的情况下，钟剑和销售管理部一起，重新整理了一套标准，并进行了详细地分析和论证。并将项目进展的情况上报给总裁、副总裁，总裁决定在22日的销售会议上由钟剑来汇报这件事。

    9月22日，在全国销售会议上，钟剑针对目前项目的进展以及面临的困难进行汇报，全项目组在总裁的指示下，重新整理数据，严格按照新的标准来做，并由销售管理部和信息中心严格把关；同时，决定10月9日第三次上线，各办事处需严格按照项目组的数据提交时间来做。

9月30日，收到25个办事处的数据，但都存在问题。

10月6日，数据已经按标准整理完毕，电话通知所有总部项目成员和30个办事处文员，7日全体加班，对数据进行检查测试。

10月7日，晚9点。数据检查和测试工作还在紧张地继续，只完成了一半还不到，眼看着第三次上线时间再次临近，钟剑又一次陷入了困境。

全力以赴，再次冲刺

10月8日，周日，下午1点。“不推迟项目启动时间，我请咎辞去项目经理，您请更有能力的人去做！”钟剑高举着手臂无可奈何地对郑伟说。

“不要太激动嘛！有事好好商量，目前出现的问题又没有说是你的问题。”郑伟眼睛看着欧阳雪。

“我不同意！已经第三次推迟了，我无法向销售分公司交待！” 欧阳雪强硬地说。

钟剑：“责任由我来承担！我们的系统从8月15日到现在，存在的问题很多，原因各位也清楚。正是因为已经推迟了三次，所以这一次的上线只能成功不能失败。我们的系统是按周进行运作的，整个国庆黄金周，30个试点办事处的文员都在加班加点地工作，每次数据的提交都要3轮的返复才能完成，国庆7天的假期仅我累计加班超过100个小时。但至今仍有5家没有将最后一版数据。而提交完整的数据导入系统后，还需要有两轮的数据关系建立，这些数据关系的建立只能由手工在系统中操作。”

欧阳雪听到钟剑这样说，也缓和了语气：“那可不推迟一天？”

“不行！我们的针对业务员的运作是以周为周期的，明天是周一，推迟一天就是周二了，这样会对系统的运作带来很大的问题。所以，第一次操作我建立还是由周一开始。既然是推迟，一天也是推，一周也是推，那我们将上线的时间推迟一周到10月16日吧？！”钟剑抓住这个机会建议道。

“那……请郑总来决策吧！”欧阳雪顺手一推把难题交给了郑伟。

“行！不过16日是最后的期限，到了这个期限还不行，钟剑你不提出辞职，我也会提请总裁的。”

钟剑果断地说：“行！没问题，这次是按我的标准的方法进行操作的，没问题。不过，需要欧阳理解，这种项目是销售管理全员的项目，需要各级销售组织重视并真正地进入到项目状态。”

欧阳雪看了钟剑一眼，对许建国和王新水说：“两位经理，钟经理的话你们听到了，希望你们积极配合。”

许建国说：“没问题，人事经理、行政助理我已经通知了，她们随时听候指挥。”

王新水说：“徐筱芳一直就在项目状态，会议前已经和钟经理沟通过，回去后我会让销售主管也参与进来。这次项目是为我们终端管理服务的，我们当然会全力以赴。”

2006年10月8日，周日下午两点四十五分，钟剑开完项目小组会议，宣布项目时间推迟一周，然后给各地的销售文员发了封Email：

“……（原因分析）

“综上所述，为了保证项目的实施质量，经请示相关领导，决定将此次新旧系统的切换时间向后推迟一周，即10月9日改为10月16日。具体安排如下：

“…… 

“发出这样的邮件通知，于我是很痛苦的决定：一个决定了的事情随意变更是我所痛恨的，相信没有人会希望如此。但我们都必须面对现实，我不能让为这个项目战斗了两个多月的各位同事再增加压力了。作为这个项目的负责人，我希望一起努力的结果是成功。在国庆长假里，仅我个人为数据的整理和准备花去了100个小时的时间，也就是说加班了11天多。当然我知道不只是我一个人在孤军奋战，还有各位办事处的文员和项目组其他同事们。

“回想这七天，一天一道催命的邮件让大家没有过好‘黄金周’，甚至在中秋之夜仍旧限时要求大家提交数据，为此我感到很惭愧，同时也感到欣慰。

“对于今天上午已经组织人力开始做拜访计划的SH大区、WN大区、GM大区、XJ大区，以及其他为此项目而努力的所有机构及人员表示感谢！有了我们共同的努力，胜利不会遥远。

“谢谢！谢谢！……”

合上笔记本，钟剑终于松口气，两个月来高度紧张的情绪，终于有个回笼的时间。一幕一幕不觉得浮现：

2006年10月31日，项目第三次上线终于获得成功，跟踪两周后基本无大的问题。钟剑踏上新的征程，这半个月里他总结了近三个月的项目问题，整理了一套更完善的项目实施方案，这次他将在一周内去7个分公司为其他没上线的办事处做准备工作。

报喜鸟集团周宏钧点评企业现场案例

       S集团的移动商务项目可谓一波三折，其结局是戏剧性的，最终以2006年10月31日，项目第三次上线获得成功而告终。之所以叫“一波三折”，主要是因为项目的上线日期一拖再拖。回顾项目历程，值得总结的地方还是比较多的，笔者认为问题集中体现在IT规划、项目计划、启动会、数据准备、风险管理、沟通管理和变更控制管理等方面。S集团移动商务项目实际上浓缩了信息化项目的普遍问题，特别是有关数据整理的反复，反映了国内企业基础管理的薄弱，具有典型意义。笔者从2005年开始担任项目经理实施SAP ERP项目，采取ASAP加速实施方法，经历项目准备、蓝图规划、系统实现、系统准备和系统上线等项目阶段，也有过类似的经历，借此机会总结经验教训，分享给大家。S集团移动项目本身存在很多亮点，如最终项目实现上线目标等，本文不做重点阐述，本文仅仅针对存在的一些问题，谈自己的看法。当然，也仅仅是一家之词，不见得妥帖。

       首先，S集团明显缺乏IT战略规划，移动商务项目准备时间达到2年之久，而项目的上马启动会议竟然是在项目经理不在场的情况下召开的，由此可见，该项目的整体生命周期是有其随意性的，反应了S集团IT规划的缺失。项目启动会议对于项目是非常重要的，其核心在于对项目经理的授权，明确项目高层次目标和项目可动用资源等。钟剑经理在项目运作当中多次推迟项目上线时间，数据提交的反反复复、项目经理身体力行进行项目加班加点等细节，从侧面反应项目经理对资源的掌控还是不够的，这也是启动会议没有到位的结果之一。

       其次，S集团移动商务项目的项目计划制定不合理。从案例看来，项目上线的日期出现多次调整，分别是8月16日、9月1日、10月9日和10月16日，按照项目结果，显然项目进度是拖延了，但从根本原因分析看来，S集团移动商务项目总体计划是非常主观的，如项目启动会议定下来的“要求在8月16日30个分公司的各个办事处上线”目标，显然是值得推敲的。从项目管理角度看来，没有看到项目管理计划及其分计划（如范围管理计划、进度管理计划、成本管理计划、人力资源管理计划、沟通管理计划、风险管理计划和采购管理计划）。作为项目经理面对不可实现目标，虽然提出了项目进度方面的意见，但在郑总的一番“训斥”下，“钟剑没有再做任何辩解”，这种“委曲求全”以保项目上马的案例国内比比皆是，实际上反应了项目经理钟剑本身对项目计划方面经验的缺失。作为项目经理是为实现项目目标负责的，既然明知不可行的目标，为何要勉强为之呢？从整个案例看来，项目缺乏一个数据管理计划，数据管理计划包括数据在项目周期内是如何被管理的，也包括静态数据、动态数据的格式、收集要求、职责分工、进度要求、数据质量等方面。笔者实施的SAP ERP同样面临着数据的难题，除了总部的基础数据（大小物料、BOM、供应商主数据、客户主数据，物料数据因为行业特性，初始化达到上亿条记录，可见工作量的巨大），还有全国600家门店的静态数据和动态数据，特别是动态数据，涉及到数据的一致性，需要同老管理系统核对比较，困难可想而知。笔者在项目的中期，也就是“系统实现”阶段，在SAP后台配置的同时就召开数据整理启动会议，安排各项工作任务，且采取了有效的策略，如静态数据提前收集、核对进入系统，动态数据多层次、多岗位的核查等。在整个过程中，值得一提的是IT要发挥主导作用，因为数据处理是一件很细致、很烦琐、工作量很大的事�