我理解的CMMI过程改进
我理解的CMMI过程改进
我理解的CMMI
前言
10年来我一直在做信息系统集成开发和管理工作，我对ISO,CMMI之类的标准的理解很简单，我不知道那些字母背后的意思，不知道他们的来源。我只是看到有用的就拿来应用，不合适的我就根据自己需要修改，不合用的我看都不看。公司做ISO,CMM，在我看到的就是一些文档模板，它们对我的工作具有一定的指导意义，尤其在我开始进行项目管理时。当然我还看到公司为ISO9000的评审准备资料，所谓准备，有很多书面资料是临时补上的，我就仿冒过多个客户的笔迹在自己的项目文档上签字。
然后CMM在这个IT业似乎很有市场，很多公司都在过级。很多咨询公司都在围绕着这些做事，看来是一个不错的方向。
来到公司,公司正好启动CMM项目，不对，同事告诉我是CMMI，两者不同，具体怎么不同，我后来才知道的。想想自己多年的实际工作经验，理论上却没什么条条道道的，也应该提升一下。于是就积极加入了，当时还想，在新领导的带领下，在咨询公司的引导下，我应该可以得到高人指点，自身水平得到提升。
现在已经半年过去，CMMI的迷雾自己也不知看穿了多少,我觉得自己并没有得到高人指点，但自己却有一些深痛的理解了。
概述
CMMI，Capability Maturity Model Integration 集成的能力成熟度模型，这是检验一个产品开发，尤其是软件开发公司的能力水平的一个尺度，是一种能力检测模型。发展到现在，CMMI还被认为是一个过程改进模型，大家可以按照这个模型，按照这个模型要求的方面去改进、提升自己的开发能力。
CMMI有一种前提思想，就是过程决定质量，这种思想是经验总结所得，不能说过程唯一决定质量，但过程绝对在很大程度上决定了质量。这种实践所得的经验，应该是不容置疑的。因此CMMI是围绕过程来做文章的。
我理解，CMMI作为能力的检查或衡量模型，是非常简单有效的，作为过程改进模型，其原意其实也是可行的，不错的，但实际在改进模型中，恐怕不是每个企业都能达到其效果
的，似乎更多的企业，包括咨询公司都是形而上学的在应用模型。而SEI的指导书 《Guidenlines for process integration and product improvement》也对模型在改进中的真正作用，或者如何让该模型起作用没有提及。
我认为自己对模型在过程改进中的地位和作用已经小有所察，在此，共享一下自己的理解。
我想从产品开发中存在问题的分析，来说明CMMI作为能力检测模型和合理性、有效性，同时也来看一下如果直接套用CMMI，存在的缺陷和问题。然后针对这些缺陷和问题来看看如何让CMMI在过程改进中正确的发挥作用。
方便起见，说明一下，CMMI模型是应用在产品开发、尤其适用于软件开发领域的，以下观点描述都是在该领域内的。
问题状态分析
要看一个公司产品的质量，就要看公司的产品开发过程中存在的问题，问题多了，产品质量就不可能有很好的保证。
一个公司产品开发水平要提高，就要改进产品开发过程中存在的问题，问题解决了，产品质量自然能有保证了。
一般来说，成功的公司有很多的相似点，不成功的公司，问题确实五花八门的，所谓家家有本难念的经，但问题也还是有一些共同属性。
产品开发的问题，犹如人的病，病有外科、内科、精神科，有皮外伤，也有病入膏肓。产品开发的问题也会有不同的层次，不同的原因，不同的部位。图一的双三角模型从问题产生的原因、层次对问题的状态做了示意。
执行层的问题管理层的问题战略层的问题关键目标的问题产品质量问题、产品成本高、开发进度赶不上老员工少、新员工技术水平低项目经理项目管理差人力资源管理问题技术资产管理问题综合项目管理问题企业文化产品战略市场战略明确唯一图一：产品开发问题层次的双三角模型
企业的问题，我们直接看到的提到的，经常是执行层面的问题，比如产品质量差、产品成本高、开发进度滞后，为什么这样，大家反馈项目都是新员工，水平不行，项目经理不会管理，等等。
这些大家时时看到的问题，有些可能就是执行项目的管理水平、技术水平不行引起的，但如果公司大部分产品开发项目都是这样的，问题就不仅仅是执行人员的执行力问题了，而是公司的人力资源管理有问题，或者是公司没有做好技术积累，但也很有可能市场太大，扩张太大，人员一下跟不上，那还有综合项目管理的问题，哪些产品是重点，公司要保证产品质量，必须对项目有所选择。
但这些管理层的问题，有时候是中层管理人员去改进就可以解决的，但很多时候，公司的中层管理人员也无所适从，他们也不知道哪些项目可以放弃，哪些不能放弃，因为没有判断的标准，这其实就是公司的产品战略、市场战略是否明确的问题了，所以有些问题是缺乏战略管理引起的。
战略管理的问题应该可以解决了吧，但有时公司的管理层为制订怎样的战略发愁，有时候，一个战略执行半年一年，发现战略错误了。为什么，定战略的时候没有和公司的目标保持一致，或者公司的目标不明确、不一致。很多人觉得，公司目标好说，俩字，赚钱，其实并不那么简单，对于一些企业是，但有些，不是，或者在特定的阶段不是。
我把问题分成了四个层次，即执行层、管理层、战略层、目标层。用词不一定妥贴，但就是这个意思。
问题越到上层，问题的量就越多。
我把问题分成两个域，小三角内为A区域，A区域问题是下一个层次的问题引发的，大三角的其余部分为B区域，B域的问题是本层次的原因引起的。
区域B的问题可以头痛医头，脚痛医脚得以解决，一般解决的难度不大。
区域A的问题就必须标本兼职，才能得到根治。
如果在执行层没什么问题，那么可以判断整个产品开发都没有什么严重的问题。因为如果有，一定在执行层上会表现。
CMMI模型分析
好了，看完了问题，我们来看看CMMI模型，CMMI作为治病的方法，是怎么治的，都有哪些方子。
表一：CMMI过程域
五级：持续改进
组织创新和实施(OID)
因果分析和解决方案(CAR)
四级：定量管理
组织过程绩效(OPP)
定量项目管理QPM
三级：已定义
组织过程核心(OPF)
组织过程定义(OPD)组织培训(OT)
集成供应商管理(ISM)
风险管理(RSKM)
集成项目管理(IPM)
集成团队(IT)
需求开发(RD)
技术解决方案(TS)
产品集成(PI)
验证(VER)
确认(VAL)
决策分析和解决方案(DAR)
集成组织环境(OEI)
二级：已管理
项目计划(PP)
项目监督和控制(PMC)供应商协议管理(SAM)
需求管理(REQM)
配置管理(CM)
过程和产品质量保证(PPQA)
度量和分析(M&A)
过程管理
项目管理
工程
支持功能
表一列出了CMMI模型的25个过程域(PA)，这些过程域告诉你，如果要很好的完成一个产品开发，你需要：
明确你如果要做一个产品开发，你首先要理解你要做的事，就是要做好需求开发(RD)，又由于产品的需求经常会变，所以你要做好需求管理(REQM)；
你知道你要做什么事了，做这个事其实是一个项目，你要考虑如何管理，才能保质保量的实现需求，所以你需要做好项目计划(PP)，根据计划做好项目监督和控制(PMC)，项目如果需要采购，要做好供应商管理(SAM)，项目都会有风险，所以要做好风险管理(RSKM)，如果产品是集成产品，需要多个部门，甚至多个公司合作，就要做好集成团队管理(IT)、做好集成项目管理(IPM)、做好集成供应商的管理(ISM)。如果可能，做到精细化管理就更好，这就是怎样做好定量项目管理(QPM)。
你知道要做什么了，你也知道怎么去管理了，你还需要有一定的环境支持，需要做好集成组织环境(OEI)，你需要做好配置管理(CM)，免得版本出错，工作中难免有遗漏、有人会不按规范做事，你需要做过程和产品质量保证(PPQA)，产品开发中碰到问题，如何进行决
策分析和解决方案(DAR)。
现在万事具备，你要考虑的是怎么做你的产品，就是怎么实现这些需求，你需要做好技术解决方案(TS)，也就是产品的设计和实现，如果是集成产品，你要考虑怎样产品集成(PI)，做出来后你需要知道实现的是否和设计的相一致，是否能满足需求，所以必须做好验证(VER)和确认(VAL)。
一个产品开发做好了，但公司一定不会仅仅是一个产品，会要做很多产品，要进行经验总结、吸取经验教训，进行改进提高，因此你需要在做产品开发的同时做好度量和分析(M&A)，以了解公司产品开发的效率或其它信息，为其它产品计划做依据。公司需要考虑公司哪些方面需要改进，组织过程核心(OPF)，怎样改进，组织过程定义(OPD)，过程出来后，人员水平也要提高，要考虑如何进行组织培训(OT)。
公司要做得更好，需要经常评估公司的过程是否合理，组织过程绩效(OPP)，不合理就需要创新改进，那么如何组织创新和实施(OID)。
好了，CMMI25个方子都说了。
在CMMI模型里，有两种表现方式，一种就是表一所示的，分级别，你想达到那个级别的，你就要按该级别要求的过程域去定义自己的过程，也就是按那几个方子自己去抓药。
还有一种表现形式是连续型的，你不需要对照级别，根据自己存在的问题，有哪方面的问题就用那个方子自己去配药。
简单有效的检测模型
从CMMI模型提供的过程域可以看出，这些方子重点是针对产品开发执行层面的问题的。
所谓CMMI认证，就是要看公司在这25个方面都有没有做到，如果能做到，那公司的产品开发就已经走上了一种持续改进的良性循环状态，可以应对产品竞争。如果企业能做到表一中已管理级对应的7个方面，则说明产品开发走向了有序化，具备基础的管理能力了。三级、四级也是同理的。
CMMI认证是通过检查企业执行层面的问题来判断产品开发的能力成熟度，从问题双三角模型来看，执行层是整个产品开发能力的表现，执行层达到的水平，实际上反应了前面各个层次的能力水平。
所以CMMI作为能力成熟度的检测模型，应该说是简单有效的，就向中医看人是否生病，忘、闻、问、切就知道了，如果一个人没有病症，他的身体就是健康的。
改进模型的误区
前面知道CMMI的过程域是在执行层的，而问题常常是分布在各个层次的，直接按照CMMI模型去建立过程，能解决图一双三角模型中执行层的B区域的问题，而对A区域的问题，就显然是治标不治本了。
并且非常不幸的事，很多公司执行层的问题A区域占了大头。
于是CMMI过程推进变得非常痛苦，也有领导非常重视的，某些过程推行不下去，就强制执行，采用不执行就有各种处罚。这就象吃止疼片，好了一时，药效一过，原来怎么疼还怎么疼，甚至更厉害。处罚毕竟是不长久的，有些事情可以通过奖励或处罚来促进习惯的养成，但根本上的问题，绝非处罚或奖励可以解决。
于是有很多公司CMMI做成了形式。
如何在改进中使用CMMI模型
那怎样走才能让CMMI不成为形式？我想应该把CMMI模型作为发现问题入口和解决问题的验证出口。
作为改进入口：如果一个过程在公司无法执行，那一定有更深层次的原因在，我们需要层层挖掘，找出问题的症结所在。然后我们可以针对问题采取措施去做改变。
作为验证出口：我们做了一系列改变后，改变带来的效果是改进了，还是没什么效果甚至有负面作用，就看这个过程能不能顺利执行，如果不行，则说明没达到改进的目标，如果过程执行顺利了，表明采取的措施是有效的。
因此CMMI过程改进的思路应该是：
1：分析当前的管理状态，评估自己所处的管理水平，确定自己的改进目标。这个改进目标可以是实现某几个过程，也可以是按过级的方式，确定自己的管理要达到二级、三级、四级或是五级。
2：如果资源足够，可以同时推进各个过程，如果资源不够，则应该定出优先级，确定在公司应该先去实现哪方面的过程。
比如一个小公司C1，原来就几个人，是作坊式的，现在业务发展起来，人多了，产品开发项目也多了，技术上暂时没什么大问题，但人多后、沟通就无法充分，资料就容易错乱、丢失等等，那么首先要建立合理的管理，就应该先抓项目管理类过程，建立良好的管理机制。
又比如一个公司C2，原来的管理已经比较有序，但开发效率跟不上市场，那其产品设计实现上应该优化，在CMMI模型里，要重点抓技术解决方案过程。
3：在执行上一步时，有些过程你顺利的推进了，但有些过程无法执行下去。推不下去的过程就是涉及了区域A的问题。这就要究其问题的根源了。
比如上面第二个公司C2, 可能很难落实技术解决方案过程，因为赶紧度，文档不完成、测试的时间没有了，那再究其原因，可能是技术资产建设没有，重复开发，效率低，那就要去推进公司的技术资产建设工作；也可能是员工离职太多，新员工上手慢，那就要考虑人力资源管理，如何留住人才，如何培训新人；还有可能是公司承接的业务超出了公司开发人员所能承受的，就应该好好规划公司的目标，确定实现该目标应具备的资源，或者补充资源，或者减少业务量以确保稳定发展。
4：找对问题后再群策群落寻找合适的解决措施，这个措施需要产品开发的管理人员来商定，因为他们熟悉业务，知道问题的突破口。然后去执行，去改变，这个过程可能是很漫长的。
5：在对问题采取措施后，继续推行过程。如果不行就回到第三步。
对应不同的公司，如果按CMMI的级别进行认证，能通过认证的时间差异是非常大的，其实事先无法做出具体的计划。
首先各个公司存在的问题状态是不同的，如果公司的问题都仅仅是执行层的问题，我想
很快能得到改观。
即使两个公司存在类似的问题，那么公司最后采取什么措施来解决，采取这个措施时的执行力水平，主要影响了问题解决的时间。
总结
最后来总结一下我的理解：
第一：CMMI模型是个简单有效的产品开发能力成熟度检测模型；
第二：利用CMMI模型进行过程改进，应该是利用该模型来发现问题，验证问题是否得到解决。
第三：CMMI改进如果只考虑过程的制订、过程的培训实施，那是很难真正成功的。CMMI改进真正要考虑的是各种问题的症结得到彻底的清除，而后，面对新的问题能走上持续改进的道路。
第四：CMMI改进真正的难度在于发现问题的关键，并解决问题。而这部分工作必须是产品开发的管理者来主导。
第五：CMMI改进的历程对每个公司来说不可能是相同的，CMMI认证的时间不能简单的类比，不能说别的公司花几个月通过认证，我们计划在多久时间内通过认证。
我理解的CMMI
前言
10年来我一直在做信息系统集成开发和管理工作，我对ISO,CMMI之类的标准的理解很简单，我不知道那些字母背后的意思，不知道他们的来源。我只是看到有用的就拿来应用，不合适的我就根据自己需要修改，不合用的我看都不看。公司做ISO,CMM，在我看到的就是一些文档模板，它们对我的工作具有一定的指导意义，尤其在我开始进行项目管理时。当然我还看到公司为ISO9000的评审准备资料，所谓准备，有很多书面资料是临时补上的，我就仿冒过多个客户的笔迹在自己的项目文档上签字。
然后CMM在这个IT业似乎很有市场，很多公司都在过级。很多咨询公司都在围绕着这些做事，看来是一个不错的方向。
来到公司,公司正好启动CMM项目，不对，同事告诉我是CMMI，两者不同，具体怎么不同，我后来才知道的。想想自己多年的实际工作经验，理论上却没什么条条道道的，也应该提升一下。于是就积极加入了，当时还想，在新领导的带领下，在咨询公司的引导下，我应该可以得到高人指点，自身水平得到提升。
现在已经半年过去，CMMI的迷雾自己也不知看穿了多少,我觉得自己并没有得到高人指点，但自己却有一些深痛的理解了。
概述
CMMI，Capability Maturity Model Integration 集成的能力成熟度模型，这是检验一个产品开发，尤其是软件开发公司的能力水平的一个尺度，是一种能力检测模型。发展到现在，CMMI还被认为是一个过程改进模型，大家可以按照这个模型，按照这个模型要求的方面去改进、提升自己的开发能力。
CMMI有一种前提思想，就是过程决定质量，这种思想是经验总结所得，不能说过程唯一决定质量，但过程绝对在很大程度上决定了质量。这种实践所得的经验，应该是不容置疑的。因此CMMI是围绕过程来做文章的。
我理解，CMMI作为能力的检查或衡量模型，是非常简单有效的，作为过程改进模型，其原意其实也是可行的，不错的，但实际在改进模型中，恐怕不是每个企业都能达到其效果
的，似乎更多的企业，包括咨询公司都是形而上学的在应用模型。而SEI的指导书 《Guidenlines for process integration and product improvement》也对模型在改进中的真正作用，或者如何让该模型起作用没有提及。
我认为自己对模型在过程改进中的地位和作用已经小有所察，在此，共享一下自己的理解。
我想从产品开发中存在问题的分析，来说明CMMI作为能力检测模型和合理性、有效性，同时也来看一下如果直接套用CMMI，存在的缺陷和问题。然后针对这些缺陷和问题来看看如何让CMMI在过程改进中正确的发挥作用。
方便起见，说明一下，CMMI模型是应用在产品开发、尤其适用于软件开发领域的，以下观点描述都是在该领域内的。
问题状态分析
要看一个公司产品的质量，就要看公司的产品开发过程中存在的问题，问题多了，产品质量就不可能有很好的保证。
一个公司产品开发水平要提高，就要改进产品开发过程中存在的问题，问题解决了，产品质量自然能有保证了。
一般来说，成功的公司有很多的相似点，不成功的公司，问题确实五花八门的，所谓家家有本难念的经，但问题也还是有一些共同属性。
产品开发的问题，犹如人的病，病有外科、内科、精神科，有皮外伤，也有病入膏肓。产品开发的问题也会有不同的层次，不同的原因，不同的部位。图一的双三角模型从问题产生的原因、层次对问题的状态做了示意。
执行层的问题管理层的问题战略层的问题关键目标的问题产品质量问题、产品成本高、开发进度赶不上老员工少、新员工技术水平低项目经理项目管理差人力资源管理问题技术资产管理问题综合项目管理问题企业文化产品战略市场战略明确唯一图一：产品开发问题层次的双三角模型
企业的问题，我们直接看到的提到的，经常是执行层面的问题，比如产品质量差、产品成本高、开发进度滞后，为什么这样，大家反馈项目都是新员工，水平不行，项目经理不会管理，等等。
这些大家时时看到的问题，有些可能就是执行项目的管理水平、技术水平不行引起的，但如果公司大部分产品开发项目都是这样的，问题就不仅仅是执行人员的执行力问题了，而是公司的人力资源管理有问题，或者是公司没有做好技术积累，但也很有可能市场太大，扩张太大，人员一下跟不上，那还有综合项目管理的问题，哪些产品是重点，公司要保证产品质量，必须对项目有所选择。
但这些管理层的问题，有时候是中层管理人员去改进就可以解决的，但很多时候，公司的中层管理人员也无所适从，他们也不知道哪些项目可以放弃，哪些不能放弃，因为没有判断的标准，这其实就是公司的产品战略、市场战略是否明确的问题了，所以有些问题是缺乏战略管理引起的。
战略管理的问题应该可以解决了吧，但有时公司的管理层为制订怎样的战略发愁，有时候，一个战略执行半年一年，发现战略错误了。为什么，定战略的时候没有和公司的目标保持一致，或者公司的目标不明确、不一致。很多人觉得，公司目标好说，俩字，赚钱，其实并不那么简单，对于一些企业是，但有些，不是，或者在特定的阶段不是。
我把问题分成了四个层次，即执行层、管理层、战略层、目标层。用词不一定妥贴，但就是这个意思。
问题越到上层，问题的量就越多。
我把问题分成两个域，小三角内为A区域，A区域问题是下一个层次的问题引发的，大三角的其余部分为B区域，B域的问题是本层次的原因引起的。
区域B的问题可以头痛医头，脚痛医脚得以解决，一般解决的难度不大。
区域A的问题就必须标本兼职，才能得到根治。
如果在执行层没什么问题，那么可以判断整个产品开发都没有什么严重的问题。因为如果有，一定在执行层上会表现。
CMMI模型分析
好了，看完了问题，我们来看看CMMI模型，CMMI作为治病的方法，是怎么治的，都有哪些方子。
表一：CMMI过程域
五级：持续改进
组织创新和实施(OID)
因果分析和解决方案(CAR)
四级：定量管理
组织过程绩效(OPP)
定量项目管理QPM
三级：已定义
组织过程核心(OPF)
组织过程定义(OPD)组织培训(OT)
集成供应商管理(ISM)
风险管理(RSKM)
集成项目管理(IPM)
集成团队(IT)
需求开发(RD)
技术解决方案(TS)
产品集成(PI)
验证(VER)
确认(VAL)
决策分析和解决方案(DAR)
集成组织环境(OEI)
二级：已管理
项目计划(PP)
项目监督和控制(PMC)供应商协议管理(SAM)
需求管理(REQM)
配置管理(CM)
过程和产品质量保证(PPQA)
度量和分析(M&A)
过程管理
项目管理
工程
支持功能
表一列出了CMMI模型的25个过程域(PA)，这些过程域告诉你，如果要很好的完成一个产品开发，你需要：
明确你如果要做一个产品开发，你首先要理解你要做的事，就是要做好需求开发(RD)，又由于产品的需求经常会变，所以你要做好需求管理(REQM)；
你知道你要做什么事了，做这个事其实是一个项目，你要考虑如何管理，才能保质保量的实现需求，所以你需要做好项目计划(PP)，根据计划做好项目监督和控制(PMC)，项目如果需要采购，要做好供应商管理(SAM)，项目都会有风险，所以要做好风险管理(RSKM)，如果产品是集成产品，需要多个部门，甚至多个公司合作，就要做好集成团队管理(IT)、做好集成项目管理(IPM)、做好集成供应商的管理(ISM)。如果可能，做到精细化管理就更好，这就是怎样做好定量项目管理(QPM)。
你知道要做什么了，你也知道怎么去管理了，你还需要有一定的环境支持，需要做好集成组织环境(OEI)，你需要做好配置管理(CM)，免得版本出错，工作中难免有遗漏、有人会不按规范做事，你需要做过程和产品质量保证(PPQA)，产品开发中碰到问题，如何进行决
策分析和解决方案(DAR)。
现在万事具备，你要考虑的是怎么做你的产品，就是怎么实现这些需求，你需要做好技术解决方案(TS)，也就是产品的设计和实现，如果是集成产品，你要考虑怎样产品集成(PI)，做出来后你需要知道实现的是否和设计的相一致，是否能满足需求，所以必须做好验证(VER)和确认(VAL)。
一个产品开发做好了，但公司一定不会仅仅是一个产品，会要做很多产品，要进行经验总结、吸取经验教训，进行改进提高，因此你需要在做产品开发的同时做好度量和分析(M&A)，以了解公司产品开发的效率或其它信息，为其它产品计划做依据。公司需要考虑公司哪些方面需要改进，组织过程核心(OPF)，怎样改进，组织过程定义(OPD)，过程出来后，人员水平也要提高，要考虑如何进行组织培训(OT)。
公司要做得更好，需要经常评估公司的过程是否合理，组织过程绩效(OPP)，不合理就需要创新改进，那么如何组织创新和实施(OID)。
好了，CMMI25个方子都说了。
在CMMI模型里，有两种表现方式，一种就是表一所示的，分级别，你想达到那个级别的，你就要按该级别要求的过程域去定义自己的过程，也就是按那几个方子自己去抓药。
还有一种表现形式是连续型的，你不需要对照级别，根据自己存在的问题，有哪方面的问题就用那个方子自己去配药。
简单有效的检测模型
从CMMI模型提供的过程域可以看出，这些方子重点是针对产品开发执行层面的问题的。
所谓CMMI认证，就是要看公司在这25个方面都有没有做到，如果能做到，那公司的产品开发就已经走上了一种持续改进的良性循环状态，可以应对产品竞争。如果企业能做到表一中已管理级对应的7个方面，则说明产品开发走向了有序化，具备基础的管理能力了。三级、四级也是同理的。
CMMI认证是通过检查企业执行层面的问题来判断产品开发的能力成熟度，从问题双三角模型来看，执行层是整个产品开发能力的表现，执行层达到的水平，实际上反应了前面各个层次的能力水平。
所以CMMI作为能力成熟度的检测模型，应该说是简单有效的，就向中医看人是否生病，忘、闻、问、切就知道了，如果一个人没有病症，他的身体就是健康的。
改进模型的误区
前面知道CMMI的过程域是在执行层的，而问题常常是分布在各个层次的，直接按照CMMI模型去建立过程，能解决图一双三角模型中执行层的B区域的问题，而对A区域的问题，就显然是治标不治本了。
并且非常不幸的事，很多公司执行层的问题A区域占了大头。
于是CMMI过程推进变得非常痛苦，也有领导非常重视的，某些过程推行不下去，就强制执行，采用不执行就有各种处罚。这就象吃止疼片，好了一时，药效一过，原来怎么疼还怎么疼，甚至更厉害。处罚毕竟是不长久的，有些事情可以通过奖励或处罚来促进习惯的养成，但根本上的问题，绝非处罚或奖励可以解决。
于是有很多公司CMMI做成了形式。
如何在改进中使用CMMI模型
那怎样走才能让CMMI不成为形式？我想应该把CMMI模型作为发现问题入口和解决问题的验证出口。
作为改进入口：如果一个过程在公司无法执行，那一定有更深层次的原因在，我们需要层层挖掘，找出问题的症结所在。然后我们可以针对问题采取措施去做改变。
作为验证出口：我们做了一系列改变后，改变带来的效果是改进了，还是没什么效果甚至有负面作用，就看这个过程能不能顺利执行，如果不行，则说明没达到改进的目标，如果过程执行顺利了，表明采取的措施是有效的。
因此CMMI过程改进的思路应该是：
1：分析当前的管理状态，评估自己所处的管理水平，确定自己的改进目标。这个改进目标可以是实现某几个过程，也可以是按过级的方式，确定自己的管理要达到二级、三级、四级或是五级。
2：如果资源足够，可以同时推进各个过程，如果资源不够，则应该定出优先级，确定在公司应该先去实现哪方面的过程。
比如一个小公司C1，原来就几个人，是作坊式的，现在业务发展起来，人多了，产品开发项目也多了，技术上暂时没什么大问题，但人多后、沟通就无法充分，资料就容易错乱、丢失等等，那么首先要建立合理的管理，就应该先抓项目管理类过程，建立良好的管理机制。
又比如一个公司C2，原来的管理已经比较有序，但开发效率跟不上市场，那其产品设计实现上应该优化，在CMMI模型里，要重点抓技术解决方案过程。
3：在执行上一步时，有些过程你顺利的推进了，但有些过程无法执行下去。推不下去的过程就是涉及了区域A的问题。这就要究其问题的根源了。
比如上面第二个公司C2, 可能很难落实技术解决方案过程，因为赶紧度，文档不完成、测试的时间没有了，那再究其原因，可能是技术资产建设没有，重复开发，效率低，那就要去推进公司的技术资产建设工作；也可能是员工离职太多，新员工上手慢，那就要考虑人力资源管理，如何留住人才，如何培训新人；还有可能是公司承接的业务超出了公司开发人员所能承受的，就应该好好规划公司的目标，确定实现该目标应具备的资源，或者补充资源，或者减少业务量以确保稳定发展。
4：找对问题后再群策群落寻找合适的解决措施，这个措施需要产品开发的管理人员来商定，因为他们熟悉业务，知道问题的突破口。然后去执行，去改变，这个过程可能是很漫长的。
5：在对问题采取措施后，继续推行过程。如果不行就回到第三步。
对应不同的公司，如果按CMMI的级别进行认证，能通过认证的时间差异是非常大的，其实事先无法做出具体的计划。
首先各个公司存在的问题状态是不同的，如果公司的问题都仅仅是执行层的问题，我想
很快能得到改观。
即使两个公司存在类似的问题，那么公司最后采取什么措施来解决，采取这个措施时的执行力水平，主要影响了问题解决的时间。
总结
最后来总结一下我的理解：
第一：CMMI模型是个简单有效的产品开发能力成熟度检测模型；
第二：利用CMMI模型进行过程改进，应该是利用该模型来发现问题，验证问题是否得到解决。
第三：CMMI改进如果只考虑过程的制订、过程的培训实施，那是很难真正成功的。CMMI改进真正要考虑的是各种问题的症结得到彻底的清除，而后，面对新的问题能走上持续改进的道路。
第四：CMMI改进真正的难度在于发现问题的关键，并解决问题。而这部分工作必须是产品开发的管理者来主导。
第五：CMMI改进的历程对每个公司来说不可能是相同的，CMMI认证的时间不能简单的类比，不能说别的公司花几个月通过认证，我们计划在多久时间内通过认证。