CMMI-DEV与CMMI-SVC真的能够高度融合？

　　市场竞争日趋激烈，企业如何改进自身运维服务，加强行业竞争优势。这对企业及咨询公司提出了新的要求。在当前我国CMMI咨询公司基本上只能提供CMMI-DEV服务，而无法提供CMMI-SVC服务的大背景下，睿泰集团率先翻译CMMI-SVC中文版，并卓效开展在该领域的系统建设。已为国内多家企业提供了CMMI-DEV与CMMI-SVC模型融合咨询、培训服务，帮助企业打造产品研发核心竞争力、实现运维服务水平的持续提升。

　　相信许多咨询公司都会存有这样的疑问：DEV与SVC同出SEI，且二者有共性PA 13个，是否能合二为一成为一套完整的过程改进体系呢?对此，部分同行有这样的观点，DEV是针对研发业务，而SVC是针对服务提供，二者显然无法融合;另外一些同行则认为，两者有共性PA13个，这就为融合提供了可行的基础。

　　我们暂且将视线从观点的对与错转移，通过前不久刚为杭州某电力行业客户完成的一项CMMI-DEV与CMMI-SVC融合咨询项目这一视角，重新认识DEV与SVC之间的关系。

　　举个例子，项目策划(PP)这个过程域存在于DEV和SVC中，是两者的共性PA，只不过后者更名为工作策划(WP)，此处可以表扬一下SEI，至少知道针对“服务”来讲，按“项目”模式来运作是有欠稳妥的。但针对某些桌面端运维项目，其服务提供确实是按“项目制”来提供的，这个很显然和IDC业务有区别。但很庆幸，睿泰的这个客户主营业务是ERP软件的二次开发、部署及服务，由于他们提供了一条龙服务，因此非常关注为客户提供的ERP整体解决方案，而这项方案涵盖从需求、开发、部署、运维的整体过程。可能有些朋友已经划清楚了界限，软件部署之前执行DEV，部署之后执行SVC不就清楚了么?但是这儿有一个问题就是软件研发本身也是一种服务，而从另外一个角度来看，服务提供本身也是一种产品，也是需要研发的!

　　睿泰与客户就两者的区别及联系进行了多轮交流，目的就是为了搞清楚两者的界限，因为按照正常的逻辑，任何一个过程改进体系总归是一个范围的，没有搞清楚范围就往下面走很显然会走弯路甚至陷入绝境，事实证明将时间投入其中并不明智，实际上我们脑袋里(包括读者您)早就有答案，因为两者互相离不开对方，继续钻研这个问题只会使您“走火入魔”!

　　以下内容为此次项目过程中提取浓缩的三项要点：

　　1、以服务为大框架，换言之，以业务驱动研发。业务来自于客户，客户的需求本身就是服务请求，这就是一个“与”门，自然而然线就连起来了;

　　2、融合时，不用太在意DEV与SVC本身。按正常的逻辑去梳理业务，很自然的就会发现，两者不谋而合;

　　3、部分小细节是需要关注的。应如何设置服务目录、定义服务级别。

　　总而言之，睿泰的成长与客户的价值驱动是分不开的，正如我们研发CMMI-DEV与CMMI-SVC模型的融合一样，是希望帮助企业实现软件研发和运维服务的有效结合，建立更加适用于企业的流程体系，使企业更有针对性的实施内部过程改进，达成企业最终的商业目标。