http://www.neco.com.cn/DRNECO/20031101.HTM (因图表无法显示, 可登录本公司网站查看 )
某系统集成企业（简称A公司），在电信计费/业务支撑行业小有名气，业务开展得相当成功，但是在进一步发展的过程中，遇到了以下几个问题：
1. 公司目前在独立开发和维护多个功能大体相似，却又有相当差别的系统版本，这些版本之间的关系“剪不断，理还乱”，公司试图引用一些业界标准的系统架构，比如J2EE，试图实现部分软件重用。但是却发现情况并不能够得到多少改善。
2. 公司常年有大批的开发人员被派驻到客户方，导致了高昂的人力资源成本。这些开发人员难以管理，对公司的认同感差。
3. 公司制定了一定的项目管理规范，但是在推行过程中却不尽如人意。项目不断延期，事故不断。
4. 公司没有正规的培训体系，软件技术人员在需求，分析，设计和测试的技能不足。
鉴于现在行业软件的严峻形势，A公司要求改变这一现状，加强管理，提高效率，减少派驻在客户方的人数。A公司和小有名气的C咨询公司签订了合同，要求C帮助A公司完成这项变革。C公司的张顾问具体负责这个项目。根据自身丰富的经验，张顾问立刻意识到：
1. 这是一个管理和技术相互缠绕的问题，必须结合两方面的手段，综合进行解决。
2. A公司意识到这个问题其实不是一天两天了，以前也曾经想了很多解决方案，但是为什么这些方案会失败？查找以前这些努力的历史，将有助于问题的解决。
3. 任何一项变革，必须获得公司高层的明确和实质性的支持否则难以成功。
根据自身的经验，张顾问拟定了一个工作规划：
1. 推动客户方成立一个“行动小组”并获得高层的明确授权。
2. 在“行动小组”的主持下，了解客户方曾经进行这方面版本规范化的努力的历史以及失败的原因。
3. 和客户方共同分析A公司的电信业务系统的架构。
4. 在客户方展开访谈，了解项目管理和质量管理的现状。
5. 在了解现状的基础上，对客户的现状进行诊断，对用户高层和C公司进行报告。
“联合行动小组”很快成立起来了，小组由精干的人员组成，在张顾问的特别要求下，小组的成员不仅仅来自于管理部门，也增加了来自于项目管理部，技术开发部，和特地从现场工程部门抽调出来的人员。经过小组成员的努力，首先整理出了上一次努力失败的历史：
A公司的最近一次“产品化”努力开始于2年以前，当时A公司的想法是，抽调一批精干的技术人员，准备开发一个全新的版本以替换公司过去分布在全国不同地点的所有老板本。但是在计划执行1年之后，在毫无成果的情况下，此项目最终被取消。
张顾问认为这个项目注定是失败的，目标定得太高，相关条件不具备，他用鱼骨图分析如下：
图表 错误！未定义书签。对A公司上次失败的原因分析
接下来，行动小组对整个公司的现状进行了分析，问题还出现在“人-过程-技术”这个铁三角上，这些因素之间相互影响和制约。
图表 错误！未定义书签。A公司内部“人-过程-技术”三种因素的相互影响
同时，信息化基础的建设也不容忽视：
行动小组对原有的“缺陷跟踪流程”进行了分析，发现以前的流程没有自动化工具的支持，基本通过手工填写Word文档的模版，如果需要相关人员签字，就打印出来，然后通过转真的格式相互传递，效率极低。A公司的大量过程都是这种手工的过程，没有计算机信息系统的支持，这些过程的可执行性非常的差。
张顾问在考虑的诊断报告的时候，颇有些踌躇，对于这样的“技术-管理”相互缠绕的现状，应该用什么样的方法来解决问题？
企业的变革一般是采用“过程改进”的方法，针对企业的开发过程进行变革，现在最流行的是卡内基·梅隆大学软件工程研究所的“软件能力成熟度模型”，但是此模型偏重的是“过程”，对于“人”和“技术”考虑得还不够。但是，另外一个方面，如果仅仅从技术方面来进行变革，又缺乏相应的模型指导。
如何找到连接技术和过程之间的桥梁，张顾问考虑了以下两个模型。
行动小组决定以“架构”为核心，来协调和平衡“人-过程-技术”之间的关系。
“行动小组”对旧有的软件架构进行了检讨，并根据各方面的要求，对旧有软件架构进行了整改。
图表 错误！未定义书签。 对新的软件架构的需求
但是，仅仅有一个架构和相关定义是不够的，如果不建立一系列的相关过程规范，并且有相关的机构保证实施，还是不会奏效。
1. 为此，行动小组决定借鉴CMM模型的相关成果，建立了质量保证机构，并首先制定了架构的定义和工程师的相关指导手册，并首先进行了SCM（软件配置管理）RM（需求管理）QA（质量保证）3方面的工作，并加强了测试工作，作为企业内部的一个KPA进行改进。
2. 在实施对相关的KPA的时候，也是有针对性的，比如SCM和RM就加强了异地协同开发的方面，特别进行了自动化工具的实施。
3. 同时，A公司也加强了对开发人员和项目经理的培训宣传工作，并严肃纪律。
通过上上下下半年的努力，改革初步取得了成效：
1. 建立了顺畅的异地开发的自动化协同工具，开发人员只要登陆公司的网站就可以提交需求，系统的缺陷等等。
2. 重要模块的源代码由公司的配置服务器统一保管，而且由于架构充分做到了模块化，之间采用统一定义的标准接口，使得开发和测试都非常容易，彼此之间可以独立工作。
3. 不同的用户的“版本差别”被局限于独立的配置项中，标准化的模块可以通用，这样显著降低了开发成本。
4. 大批的开发人员回到公司工作，这样一方面节约了成本，另一方面便于对员工的管理和培训。
“行动小组”此基础上，制定了下一阶段的目标：
1. 进一步深化以CMM的过程改进工作，加强SPP/SPTO方面的工作，争取通过SW-CMM 2级评估。“特别工作小组”就成为了软件工程过程组（SEPG）的前身。
2. 引进先进技术，进一步优化现有的架构。经过“行动小组”整改的软件架构仅仅只是一个过渡，在现有成果的基础上，完全可以采用业界先进的技术来进行改进。
3. 经过改进的软件架构，就成为了进行软件工程培训的基础和标准。
张顾问的工作圆满完成。为C公司赢得了信誉。完成任务之后，他总结了以下几点心得体会：
1. 现实企业中的问题是复杂的，单纯依赖SW-CMM/CMMI这些理论框架往往是不够的，通常要按照现实情况采用综合手段进行解决。
2. 在软件过程改进中，循序渐进是必需的手段，切忌“拔苗助长”，脱离了企业现有的技术和管理水平。
3. 面对企业的现实情况，不能完全照搬CMM中的条文，而要依照实际情况，有选择地实施。
