CSMM 软件能力成熟度指南

先说结论

如果你只记三句话，记这三句：

一、CSMM 和 CMMI 是"同方向、两条路"。两者都在看企业的软件开发与交付过程能力：过程有没有被定义、有没有真的在跑、有没有度量数据、有没有据此改进；两者也都需要证据支撑，不是交一份材料就能定论。差别在于归属——CMMI 是国际体系（ISACA／CMMI Institute，由授权主任评估师实施评估），CSMM 是国内体系。

二、体系独立，证书互不替代。这是实务里容易被误解的一条。关注点相近，不等于可以互相顶替；两个体系各自出各自的结论，不存在拿一张顶另一张的用法。标书要哪个，就准备哪个。

三、选哪条，主要看标书要求和客户认可度。不是看哪个"听起来高级"。政府类、国企类项目近年对 CSMM 的采用在增多，但具体怎么要求，以招标文件原文为准；客户群以涉外或外资为主时，CMMI 的通行度更高。先看标书原文，再定方向，比先做再找买主靠谱得多。

CSMM 评什么：评的是过程能力，不是文档厚度

初次接触 CSMM 的企业，常把它理解成"再写一套研发流程文件"。方向偏了。它评的是企业把软件做出来、交付出去这件事，是不是可重复、可预测、可改进——同一个团队换一个项目，还能不能做出同样的交付质量。

展开来看，评估关注的是几条主线：过程是否被定义（有没有成文的、贴合实际业务的研发与交付过程）、过程是否被执行（项目上是不是真按这套过程在跑，而不是文件归档后无人使用）、过程是否被度量（进度、质量、缺陷、工作量有没有可信的数据）、过程是否被改进（数据出来了，有没有据此调整做法并留下闭环）。具体条款如何划分、要求到什么颗粒度，以评估机构评估为准。

换个更直白的说法：评估人员想看的是"需求怎么进来、怎么拆、怎么评审、怎么测、怎么发布、出了问题怎么回溯"。这条链上任何一环只有制度没有记录，等级就上不去。因为评估看的是运行痕迹，不是承诺。

与 CMMI 的关系与区别：同方向，两条路

这是被问得很多的一组，也是在客户面前容易说错的一组。两个体系都在看软件开发与交付的过程能力，评估逻辑也相近——都要看过程定义、都要看项目证据、都要由评估人员判断。但它们是两个独立体系，归属不同、实施主体不同，证书互不替代。

谁能评、怎么评：流程比想象中朴素

CSMM 由该体系内的评估机构实施评估。选机构时看的是受理范围、评估经验是否匹配你的业务类型（产品研发、项目定制、平台类差异不小）以及目标等级，而不是看名字大小——评估结论由规则与证据共同决定，机构不替企业造能力。

和 ITSS、DCMM 的区别：三个方向，别混着说

这四套体系（ITSS、CMMI、CSMM、DCMM）经常被塞进同一张"软件企业资质清单"，导致不少人以为可以互相顶替。实际方向不同，混着讲容易在客户面前露怯。

一句话区分：CSMM／CMMI 关心"软件在交付给你之前，是怎么被做出来的"；ITSS 关心"系统交给你之后，运维得怎么样"；DCMM 关心"数据这项资产，管到什么水平"。一个面向建设阶段，一个面向运行阶段，一个面向数据治理。做集成加运维的企业，几边都可能被要求；纯研发型企业，通常只需要过程能力这一类。

延伸阅读：ITSS 信息技术服务标准指南、DCMM 数据管理能力成熟度，以及 ITSS／CMMI／DCMM／CSMM 怎么选。四套体系目标不同，先按"客户要什么"排序，再按"内部有什么基础"排序，答案通常很清楚。

关键信息

准备投标材料时，建议同时核对三份文件：招标文件原文（条款写法与等级下限）、当地当期政策（适用条件与申报窗口）、评估机构的受理要求（范围与材料清单）。三者对不上时，以招标文件原文为优先。