CMM与CMMI究竟有何不同？五大维度对比与落地指南

年前接手了一个做ERP的项目，项目方为了投标，拿了一份CMMI的文件包过来让我帮忙把关。我扫了一眼目录，发现里面还挂着一堆"需求管理、软件项目计划、软件项目跟踪和监督"这些旧框架——这不是CMMI的文件，这是老一代CMM（Capability 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：把多套模型"集成"在一起的能力评估体系

CMMI（Capability Maturity Model Integration，能力成熟度模型集成）就是CMM的进化版。SEI在吸纳CMM多年实践经验的基础上，把系统工程师能力成熟度模型（SECM）、集成产品开发能力成熟度模型（IPD-CMM）和软件CMM整合到一套框架里，2002年前后发布了CMMI-SE/SW等系列。后来又在版本迭代中不断融合供应商管理、硬件开发、服务领域，逐渐形成了我们现在熟知的CMMI模型。

相比CMM，CMMI最大的关键词是"Integration（集成）"。它不再只说软件过程，而是覆盖整个产品开发链条：从需求开发、技术方案、产品集成到验证确认，再到组织过程改进、量化管理、供应商协议管理等等。它试图回答一个问题：一个组织做产品（不管产品里包含多少软件、硬件、系统）的过程能力，能不能像CMM评估软件那样被衡量、被改进？

顺便说一嘴，CMMI后来已经独立于SEI运营，由CMMI研究所负责，再后来归到ISACA旗下持续迭代。2018年发布了CMMI 2.0，2021年后整个模型体系和评估规则又有明显变化。所以现在谈CMMI，不能还停留在十几年前v1.3的思维里，但要真正理解它，又必须从CMM和CMMI v1.3的对比开始。这就引出了我们下面要展开的差别。

2. 五大维度拆解CMM与CMMI的核心差别

2.1 适用域：软件单行道 vs 多学科立交桥

这是最本质的一个差别。CMM名字里有"Software"，CMMI名字里有"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个PA

CMM的五个等级下面安排了18个关键过程域（KPA）。比如成熟度2级下有需求管理、软件项目计划、软件项目跟踪和监督、软件分包管理、软件质量保证、软件配置管理6个KPA；3级下有组织过程焦点、组织过程定义、培训大纲、集成软件管理、软件产品工程、组间协调、同行评审7个KPA；4级下有量化过程管理、软件质量管理2个KPA；5级下有缺陷预防、技术变更管理、过程变更管理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 SCAMPI

CMM时代，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 五个等级逐级对照表

为了让大家看差异更直观，下面这张表是我从评估实操角度整理的对照关系。注意，这不是简单的一一映射，只是说"大致对应"。

等级方面，可以大致这样对应：

• 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 常见问题速查

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这种轻量方式先看看家底。别急着排评估日期，也别急着写一大堆文档。把真实项目的真实数据摆到桌面上，你会发现差距在哪、该补什么，心里很快就清楚了。这条路我自己走过不止一遍，投入产出比远比你想象中高。