年前接手了一个做ERP的项目项目方为了投标拿了一份CMMI的文件包过来让我帮忙把关。我扫了一眼目录发现里面还挂着一堆需求管理、软件项目计划、软件项目跟踪和监督这些旧框架——这不是CMMI的文件这是老一代CMMCapability Maturity Model的东西。对方项目经理还很认真地问我CMMI和CMM不就是改了个名字吗这个问题我遇到过不下十次。很多做软件、做实业的同行把这两个词混为一谈在投标文件、质量体系文件里随便替换着用。实际上它们虽然在血缘上是父子关系但无论是适用范围、结构设计、过程域数量还是评估方式差别都不小。这篇内容我打算花点篇幅把两者掰开揉碎了讲清楚从一个做过程改进、做过多次评估的从业者角度说说它们到底差在哪、现在企业该怎么用。如果你正准备导入CMMI、要参加招标答辩或者手上还留着CMM时代的旧文档这篇值得认真看。1. 先分清两张身份证CMM和CMMI各自是什么1.1 CMM纯粹围绕软件过程的成熟度模型CMM最早诞生于上世纪80年代末90年代初由美国卡内基梅隆大学的软件工程研究所SEI提出。当时软件行业有个很痛的问题项目能不能成功几乎完全取决于个别牛人换个人结果就天差地别。为了让软件开发过程变得可预测、可重复、可改进SEI设计了一套评估软件过程成熟度的模型CMM v1.1在1991年正式发布。CMM的核心假设很简单产品的质量根植于生产它的过程。只要过程成熟度高产出就稳定。它用五个成熟度等级来衡量软件组织的过程能力等级从1到5逐级上升每个等级下有若干关键过程域KPA。企业通过满足这些KPA的目标证明自己达到了对应的成熟度。在CMM时代这套逻辑很接地气也确实在军工、航天和大型IT企业里大量应用积累了不少最佳实践。但它的视野聚焦在软件两个字上。那时候做系统工程的人、做硬件的人、做采购的人都不在这套模型范围内。随着产业发展问题很快暴露出来很多组织不只是写软件它们同时做系统集成、硬件开发、甚至带供应链。一个公司里软件部门用CMM系统工程部门又用另一套模型评估各搞各的成本极高产出却互相打架。1.2 CMMI把多套模型集成在一起的能力评估体系CMMICapability Maturity Model Integration能力成熟度模型集成就是CMM的进化版。SEI在吸纳CMM多年实践经验的基础上把系统工程师能力成熟度模型SECM、集成产品开发能力成熟度模型IPD-CMM和软件CMM整合到一套框架里2002年前后发布了CMMI-SE/SW等系列。后来又在版本迭代中不断融合供应商管理、硬件开发、服务领域逐渐形成了我们现在熟知的CMMI模型。相比CMMCMMI最大的关键词是Integration集成。它不再只说软件过程而是覆盖整个产品开发链条从需求开发、技术方案、产品集成到验证确认再到组织过程改进、量化管理、供应商协议管理等等。它试图回答一个问题一个组织做产品不管产品里包含多少软件、硬件、系统的过程能力能不能像CMM评估软件那样被衡量、被改进顺便说一嘴CMMI后来已经独立于SEI运营由CMMI研究所负责再后来归到ISACA旗下持续迭代。2018年发布了CMMI 2.02021年后整个模型体系和评估规则又有明显变化。所以现在谈CMMI不能还停留在十几年前v1.3的思维里但要真正理解它又必须从CMM和CMMI v1.3的对比开始。这就引出了我们下面要展开的差别。2. 五大维度拆解CMM与CMMI的核心差别2.1 适用域软件单行道 vs 多学科立交桥这是最本质的一个差别。CMM名字里有SoftwareCMMI名字里有Integration。CMM关心的是一段代码、一个软件项目的开发过程CMMI关心的是一个产品从概念到交付全链条的过程能力。举个例子。一家做轨道交通控制系统的公司项目交付物里既有嵌入式软件、有硬件板卡、有机械结构还有大量对外采购的子系统集成工作。你拿CMM去评估很多环节根本对不上——硬件设计过程在CMM里没有对应的关键过程域采购和供应商协同也不在CMM的射程里。但CMMI可以它有供应商协议管理有技术解决方案、产品集成、确认验证这些工程类过程域能从全系统视角去审视过程成熟度。所以现在还有人在纠结我要用CMM还是CMMI——基本不用纠结。如果你是纯软件项目CMMI完全覆盖CMM的内容如果你是软硬件混合、系统级交付、带外包带供应链的组织CMMI是唯一合理的选择。CMM已经是过时的单学科模型CMMI才是跨学科、集成化的框架。2.2 结构阶段式一种走法 vs 阶段式和连续式两条路CMM只有一种视图——阶段式Staged。企业按成熟度等级1到5逐级往上爬每个等级要满足固定的KPA要求像一个阶梯一级一级往上走不能跳级。比如你想达到第3级必须先把第2级的所有KPA目标都实现。这种设计简单直接也很符合评估等级的商业需求招标方说需要CMMI 3级你亮出ML3评估结果就行。CMMI则多了一个选择——连续式Continuous。连续式不再用成熟度等级做唯一度量而是把每个过程域单独拿出来评分等级用能力度0到3来衡量0为不完全1为已执行2为已管理3为已定义。你可以只挑最痛的过程域先行改进比如只做验证和确认这两个过程域其他先不管。改进路径完全跟着业务痛点走不必为了凑等级把所有过程域都推一遍。我经常打一个比方阶段式像开车上高速必须一个出口一个出口地走顺序固定连续式像逛商场你想先去哪个店都行不用按楼层顺序。企业如果是为了投标、为了对外声明等级肯定走阶段式如果是内部过程改进、资源有限、想聚焦短板连续式更实用。这也是CMMI比CMM灵活得多的一个重要体现。2.3 过程域18个KPA vs 22个PACMM的五个等级下面安排了18个关键过程域KPA。比如成熟度2级下有需求管理、软件项目计划、软件项目跟踪和监督、软件分包管理、软件质量保证、软件配置管理6个KPA3级下有组织过程焦点、组织过程定义、培训大纲、集成软件管理、软件产品工程、组间协调、同行评审7个KPA4级下有量化过程管理、软件质量管理2个KPA5级下有缺陷预防、技术变更管理、过程变更管理3个KPA。CMMI阶段式模型以应用最广的CMMI-DEV v1.3为例则定义了22个过程域PA。虽然从数量上看只多了4个但内部的构成变化很大。第2级有需求管理、项目策划、项目监控与控制、供应商协议管理、度量与分析、过程和产品质量保证、配置管理7个PA第3级有需求开发、技术解决方案、产品集成、验证、确认、组织过程焦点、组织过程定义、组织培训、集成项目管理、风险管理、决策分析和解决方案11个PA第4级有组织过程性能、量化项目管理2个PA第5级有组织绩效管理、原因分析和解决方案2个PA。核心要点是CMMI新增的几个过程域恰恰是CMM时代最薄弱的地方。比如度量与分析独立成域要求组织把测量数据当成管理输入供应商协议管理让外包和采购环节有了正式的过程要求风险管理把风险分析提到和需求、计划同等重要的位置。这些改动加起来让CMMI比CMM更贴近现代工程管理的完整图谱。2.4 等级定义名字接近但内涵已经拉开从五级结构看CMMI阶段式的5个等级名字和CMM非常像初始级、已管理级可重复级、已定义级、量化管理级已管理级、优化级。很多人因此觉得换个马甲但内涵已经差异很大。举个例子CMM的第2级叫可重复级核心是让成功的做法可以被重复关注点在项目级里的计划、跟踪、QA等基础管理。CMMI的第2级叫已管理级但它不只是能重复还要求每个过程有明确目标、有测量、有监控、有纠正措施并且把度量与分析、供应商协议管理都放进来了。这就不是一个简单的名称替换而是把心中有数变成了显性要求。再往上看CMM的第4级和第5级要求量化过程管理、软件质量管理、缺陷预防等但很多描述停留在要有度量的层面。CMMI的第4级则要求建立组织过程性能基线、用统计方法理解子过程的性能第5级要求组织绩效管理和原因分析与解决方案——更强调用数据驱动系统性改进而不只是技能层面的质量活动。可以说CMM是流程有没有、大家守不守规矩的评估CMMI是流程是否可控、能否量化、能否持续变好的评估。2.5 评估机制CMM的旧评估体系 vs SCAMPICMM时代SEI的评估做法是CBA-IPI基于CMM的内部过程改进评估和SCE软件能力评估等主要目的是内部诊断和评价供应商能力。这部分机制比较早期评估严谨性、一致性和后续跟进机制远不如CMMI成熟。到2000年代SEI逐步用CMMI取代CMM后CMM评估基本退出历史舞台。CMMI则建立了统一的评估标准——SCAMPI标准CMMI评估方法分成A、B、C三类。SCAMPI A是正式的强度评估能够生成成熟度等级评级需要授权主任评估师Lead Appraiser带队执行结果会被官方公示SCAMPI B和C属于非正式评估适合内部诊断、过程改进前的摸底不能用来对外宣贯等级。此外CMMI评估结果还有明确的有效期通常3年到期后需要重新评估。这在商业上有一个实际影响企业说我们通过了CMMI 3级评估时这句话是有一个官方可查、有期限的标记的CMM时代没有这么标准化的公示体系。3. 等级对照、能力扩展与迁移指南3.1 五个等级逐级对照表为了让大家看差异更直观下面这张表是我从评估实操角度整理的对照关系。注意这不是简单的一一映射只是说大致对应。维度CMMCMMI全称Capability Maturity ModelCapability Maturity Model Integration首版发布1991年v1.12002年左右CMMI-SE/SW正式版覆盖领域软件工程过程软件系统工程硬件采购产品集成服务等表示法仅阶段式阶段式连续式过程域数量18个KPA22个PAv1.3阶段式等级设置成熟度1-5阶段式成熟度1-5连续式能力度0-3工程视角围绕软件产品工程覆盖需求开发、技术方案、产品集成、验证确认全链条评估方法CBA-IPI、SCE等SCAMPI A/B/C市场状态已被淘汰SEI不再受理CMM评估当前主流国际评估体系CMMI 2.0等级方面可以大致这样对应CMM 1级初始 ≈ CMMI ML1初始CMM 2级可重复 ≈ CMMI ML2已管理但CMMI新增了度量分析和供应商管理要求CMM 3级已定义 ≈ CMMI ML3已定义但CMMI工程类过程域显著扩展CMM 4级已管理 ≈ CMMI ML4量化管理CMMI对统计管理要求更强CMM 5级优化 ≈ CMMI ML5优化CMMI新增组织绩效管理、原因分析与解决方案3.2 CMMI比CMM多出来的新武器站在过程改进角度CMMI在CMM基础上最大的增量是几个从前几乎没有独立地位的过程域。我挑几个重点讲一是度量与分析MA。CMM里不是没有度量但它散落在各个KPA里没有形成系统性要求。CMMI把度量与分析单独拎出来要求组织识别度量目标、定义度量指标、收集和分析数据。这一步看着简单实际操作中最能体现一个组织的管理成熟度。二是供应商协议管理SAM。CMM里的软件分包管理只管软件外包而CMMI的供应商协议管理覆盖所有外部采购和分包对供应商选择、协议建立、执行监督、接收和移交都有明确实践。做系统集成的公司应该深有体会外包环节的失控往往是项目失败的致命伤。三是风险管理RSKM。CMM里没有独立的风险管理要求CMMI把它提升为一个专门的过程域要求准备风险管理策略、识别风险、分析风险、制定缓解措施、执行缓解计划。很多企业评估时在风险管理上拿到的发现项数量经常排在前列因为真正把风险做进日常管理的团队太少。四是决策分析和解决方案DAR。这个域负责建立正式的决策过程特别是对备选方案进行结构化评估。比如技术选型、工具选型、设备选型都需要按准则评分而不是拍脑袋。CMM时代基本没有这个意识CMMI往前推了一大步。五是原因分析和解决方案CAR、组织绩效管理OPM。这两个域把改进从解决几个缺陷提升到从根因上防错、从组织层面提升绩效的高度。CMM的缺陷预防还在但CMMI把根因分析的纪律性和组织级绩效改进的闭环拉得更严。3.3 从CMM迁移到CMMI的三项必修课如果你的企业早年是按CMM体系做过程的现在想换成CMMI这不是把文件名替换一遍就行的。按我见过的大量迁移案例有三件事必须做扎实。第一件按CMMI过程域重新梳理过程体系。CMM的18个KPA对应的是旧流程很多实践描述以软件为中心迁移时要逐个对照CMMI 22个PA重新裁剪。特别是新增的度量与分析、风险管理、决策分析和解决方案、供应商协议管理要从零开始建流程。多数企业会在这一步发现自己的项目管理过程其实很薄缺的不是文档模板而是测量数据从哪来、风险谁跟进、采购怎么评审这些真实运转的机制。第二件建立量化管理的组织基础设施。如果你的目标是CMMI ML4以上那么必须提前建设组织过程性能基线收集历史项目数据定义关键质量属性和过程性能指标。这个工作在CMM时代不是硬性要求很多企业的实际做法是上了3级就好导致数据和统计基础一片空白。想上ML4至少要有两年的过程数据积累这不是评估前三个月能突击出来的。第三件把组织级改进机制运转起来。CMMI的ML5不是多贴两个文档就叫改进而是要有一个真实运作的改进团队能从项目一线收集问题、分析共性根因、试点方案、推广最佳实践、衡量改进了多少。这套机制比CMM时代的缺陷预防要求更重它要求组织级的绩效数据和项目级的执行数据形成闭环。4. 落地实操导入CMMI时最容易被忽视的细节4.1 到底该选阶段式还是连续式这是个非常现实的决策问题我几乎在每个辅导企业里都会被问到。我的建议很简单如果导入CMMI的主要动力来自外部——招投标要求、客户门槛、行业资质上传——那就走阶段式目标明确地盯着成熟度等级去准备因为甲方写的是具备CMMI3级资质。如果导入CMMI的动力来自内部——想提升研发效率、想改善交付质量、想减少返工——那连续式更合适先选两三个最痛的过程域做深做透比如先做项目监控与控制、验证、原因分析和解决方案不要一上来就想着攒一套ML3的大而全体系。还有一点阶段式的评估和连续式的评估在投入成本上差距很大。阶段式ML3评估通常要覆盖大部分过程域访谈对象多、证据材料多、评估周期长连续式只针对选定过程域范围小、成本低、见效快。如果你的组织只有二三十人我强烈建议从连续式起步先把项目管理基本盘做稳再逐步扩展。4.2 评估过程是怎么进行的SCAMPI A评估虽然是正式的但它的核心不是考试而是验证证据。评估过程大致分这么几步第一步是确定评估范围。评估组织会和企业一起划定评估组织单元——哪些部门、哪些项目纳入本次评估还要划定模型范围——哪些过程域纳入。比如ML3评估通常要覆盖成熟度2级和3级所有PA而组织单元和项目的选择直接影响代表性。第二步是准备证据。评估组会要求企业提供三类证据文档证据流程文件、项目计划、会议纪要、评审报告等、工具证据项目管理工具、代码库、缺陷跟踪系统等实际操作记录、访谈证据高管访谈、项目经理访谈、工程师访谈、QA访谈等。注意这三类证据必须相互印证光有文档没有被执行或者访谈里说的和系统里留存的记录对不上都会被开发现项。第三步是正式评估。评估组按SCAMPI方法对证据进行核验逐条对照实践判定满足程度通常会开出一份发现项列表和最终评级报告。通过后评级结果会由主任评估师提交官方平台公示有效期3年。第四步是后续改进。SCAMPI A评估不只是一张纸评估组会提出改进建议企业需要针对发现项制定改进计划。很多企业拿到评级后把改进文档束之高阁这是很可惜的因为3年后重新评估时老问题往往还会再出现。4.3 我给企业的四点实操建议第一别把评估准备做成补材料工程。我见过太多团队在评估前一两个月疯狂补会议纪要、补评审记录、补风险跟踪表。结果是系统里的数据时间线千疮百孔访谈时项目经理想不起来自己提交的风险列表是什么。更好的做法是把过程改进融入到日常项目中评估只是对已有工作的核验。第二访谈对象不能只培训项目经理。SCAMPI A访谈通常会抽查多个角色工程师、测试、配置管理员、QA都可能单独约谈。只给管理层对口径技术层一问三不知这种评估基本上是等着被开重大发现项。第三裁剪Tailoring要体现真实情况。CMMI允许组织根据自己的业务特点对实践做裁剪但裁剪后必须保留过程域的目标和核心实践并且要能解释为什么裁剪。很多人把裁剪当成删要求的借口结果过程体系看起来精简了实际上连基本管理动作都漏了。第四选择主任评估师要谨慎。好的主任评估师不只是给结果他会通过评估过程的提问和验证帮你发现体系里的真实短板。选评估师至少要看两点一是对你们所处行业有没有理解二是愿不愿意在评估前给你做一轮摸底诊断。能把摸底诊断做透的评估师正式评估时基本不会有大意外。5. 常见问题与避坑实录5.1 常见问题速查问题回答CMMI是CMM的升级版吗可以这么说但更准确的说法是替代者和整合者。CMMI不仅升级了CMM还把多套模型合成了一套。CMM现在还有用吗官方层面SEI早就停止受理CMM评估市场招投标里也几乎不见CMM。企业内部作为历史参考可以对外没有意义。CMMI是认证还是评估正式说法是Appraisal评估不是Certification认证。SCAMPI A评估结果由官方平台公示。CMMI评估结果有有效期吗常规是3年。到期后需要重新评估才能继续宣称达标等级。小团队适合上CMMI吗可以做但建议用连续式并且限制过程域范围不要硬冲阶段式ML3容易变成文档游戏。CMMI和ISO 9001什么关系CMMI是面向产品和工程的过程成熟度模型ISO 9001是通用质量管理体系。两者互补很多企业同时框架合并使用。CMMI 2.0和v1.3要用哪个新导建体系直接用2.0按2.0的实践域重新理解模型老企业升级到2.0需要重新培训和评估但不必推倒重来。5.2 我踩过的坑和替别人填过的坑先说一个最常见的坑拿CMM老文档改个标题当CMMI材料。我们曾经辅导过一家外包公司客户要求CMMI 3级他们把十年前做CMM 3级的一大套文档直接改了封面。结果评估时评审员随意抽查发现里面还在写软件分包管理而不是供应商协议管理还在用软件产品工程而没有技术解决方案和产品集成的结构。当场被开了一个大发现项差点连累整个评估进度。这就是不理解CMM和CMMI差别最典型的后果。第二个坑只重视文档不重视过程数据的真实性。ML3以下还能靠体系文件撑一撑到ML4及以上量化数据编都编不出来。我见过一个企业声称量化项目管理做得很好但项目系统里根本没有历史数据可查只有评估前补出来的一张Excel表。这种材料在SCAMPI A核查阶段特别容易被击穿——评审员会拿项目立项时间和数据表里的数字逐项核对一旦时间对不上整个评估的可信度都受影响。第三个坑裁剪过度把过程域剪成摆设。有家做嵌入式设备的公司认为自己是小团队把决策分析和解决方案整个删掉了。评审员问他们平时怎么做芯片选型项目经理说我们内部讨论一下就定了。这种回答在评估里等于主动暴露短板——不是不能裁剪但要保留记录决策准则和评估过程的证据。裁剪正确与否直接决定评估结果质量。第四个坑对外宣传时用词不严谨。很多公司官网上写着通过CMMI3级认证严格来说这个说法是错的。CMMI没有认证只有评估。虽然大家日常口语都不较真但在投标文件、客户尽调材料中用词不规范会被专业客户挑刺反而显得不专业。正确的说法是通过CMMI 3级评估SCAMPI A。6. 写在最后的个人体会做过程改进这些年我越来越觉得CMM和CMMI最本质的差别不在数量、不在术语而在思考方式的代差CMM追求的是这件事有没有按流程做CMMI追问的是这个流程能不能稳定地产出好结果、能不能被数据证明、能不能持续改进。从那家ERP公司的CMM旧模板到现在各种标书里清一色的CMMI 3级要求模型在变底层规律没变——过程能力终归要落实到每一个项目的真实运转里。如果你正准备启动CMMI相关的工作哪怕只是先做内部摸底我建议从对照表里选三个最薄弱的过程域做一次小范围诊断用SCAMPI C/B这种轻量方式先看看家底。别急着排评估日期也别急着写一大堆文档。把真实项目的真实数据摆到桌面上你会发现差距在哪、该补什么心里很快就清楚了。这条路我自己走过不止一遍投入产出比远比你想象中高。