如何为合作伙伴网络构建成熟度模型

成熟度模型是一项设计工作,而不是写作工作。本文介绍从明确目的到推出 1.0 版的八个步骤,提供免费的四页模板、虚构联盟的填写示例,以及需要避免的错误。

董事会文件中经常会出现这样一行要求:为我们的合作伙伴开发一个成熟度模型。秘书处有人打开电子表格,输入五个标题,从“基础”到“优秀”,然后开始填写单元格。几周后,在成员大会上,大家讨论的不是治理或数字技能,而是某个成员算“好”还是“很好”,以及是谁做出的判断。

问题通常不在于投入的精力,而在于决策的先后顺序。本指南将介绍如何分八步为合作伙伴网络构建成熟度模型,从明确用途到首次修订,并附有免费的四页模板、虚构联盟的填写示例,以及我建议避免的错误。

什么是成熟度模型?它的理念从何而来?

1986年11月,卡内基梅隆大学软件工程研究所开始开发一套流程成熟度框架,以回应一项请求:为美国联邦政府提供一种评估软件承包商能力的方法。到1993年,该框架发展为软件能力成熟度模型(Capability Maturity Model for Software);按SEI自己的说法,其五个成熟度级别“定义了一个序数量表”[1]。

这种模型的基本形式一直延续至今:以离散阶段描述预期的、期望的或典型的发展路径[2]。每个级别都说明达到该级别需要具备哪些条件,因此评估可以确定组织在发展路径上的位置,并显示下一步该怎么走。到2005年,IT服务、知识管理等领域已经出现了150多个成熟度模型[3];然而,Becker、Knackstedt和Pöppelbuß在审视其中51个模型时发现,只有9个详细记录了其设计过程[2]。下文将介绍这项研究中的方法,并将其转化为适用于项目团队的做法。

构建成熟度模型的八个步骤

这些步骤遵循 de Bruin、Rosemann、Freeze 和 Kulkarni 为开发各类成熟度模型提出的阶段:确定范围、设计、填充内容、测试、部署和维护[3]。每项决策都会限制下一步的选择,而试点至少会让你回头修改一次描述。

构建成熟度模型的八个步骤示意图:明确目的和用途、确定维度、设定级别、编写描述、确定证据、与合作伙伴验证、开展试点和校准、治理与重新评估;每一步均标注所属开发阶段
八个步骤,以及各自所属的开发阶段。

1. 明确模型的用途

在设定任何级别之前,先写下模型将为哪些决策提供依据。研究将用途分为三类[3][4]:描述型模型展示每个合作伙伴当前所处的位置;规范型模型还会指出下一步该做什么;比较型模型则对合作伙伴或地区进行基准比较,这需要大量评估和非常稳定的标准。大多数合作伙伴网络需要前两种用途。

同一页上还要回答:由谁填写(合作伙伴独立填写、与你们共同填写,还是由你们确认)、多久填写一次,以及模型绝不会用于什么目的。根据我的经验,最后这一项比任何填写说明都更能促使人们诚实作答。如果成员怀疑模型会决定其成员资格或资助,就会给自己打高分,最终模型描绘的将是一个并不存在的网络。

2. 选择维度

维度是模型涵盖的主题,例如治理、财务、数字技能、保护和青年参与。维度要少,才能控制复杂度并保持相互独立(de Bruin及其同事的两个模型分别使用了六个和四个主要组成部分);同时,还要做到彼此互斥、合在一起涵盖完整[3]:任何证据都不应被重复计算,而模型用途所需的内容也不能遗漏。我倾向于设置四到七个维度;如果某个主题范围较广,则将其拆分为两到三个子维度。

着手撰写自己的模型前,先看看现有模型:Becker及其同事将与现有模型进行比较列为开发新模型的首要要求[2]。在能力建设方面,McKinsey于2001年为Venture Philanthropy Partners制定的框架包含七个要素,是一个不错的起点[5];我们的合作伙伴能力评估指南中的六个领域也值得参考。

3. 选择四个或五个级别

CMM采用五个级别[1];McKinsey框架则采用四个[5]。级别数量没有那么重要,关键是满足 de Bruin 及其同事提出的要求:各阶段应有明确区分和清晰定义,进阶逻辑合理,并以简短标签体现其目标[3]。

选择四个还是五个级别?
  四个级别 五个级别
典型标签 探索、建设、融入、引领 初始、可重复、已定义、受管理、持续优化(CMM的级别)[1]
适用情况 你能用证据区分从迈出第一步到引领他人的四种状态 你能用证据区分“做得好”和“系统性改进”
需要注意 两种不同状态被塞进同一级别,导致合作伙伴在这一层停留多年 没有人能达到最高级别,或者评估者无法区分中间级别

我的规则来自运筹学研究:只有当某个级别能够用证据描述,并且能够与相邻级别区分开来时,它才值得保留。数一数网络中实际能够观察到的状态,然后就此打住。级别数量也可以增加:Becker及其同事最初为IT绩效模型设置了四个阶段;在采访IT经理后,他们将其扩展为六个阶段,从“完全不存在”到“已优化”,以区分能力较弱的情况[2]。还要把最低级别写成起点,而不是判决:“探索”开启对话,“不合格”则会终结对话。

4. 将每个级别写成可观察的状态

大多数模型都在这一步出了问题。描述项是网格中一个单元格里的文字。Pöppelbuß和Röglinger将可由不同人独立验证的标准列为实用成熟度模型的设计原则之一:描述要足够精确、清晰,能够区分相邻级别[4]。简单来说:两个人观察同一个合作伙伴时,应该选中同一个单元格。

从形容词转向可观察状态(以下示例来自下文的虚构联盟)
含糊的描述 可观察的描述 证据
数据保护良好 指定了数据负责人;书面制定并落实了同意和数据保留规则 数据政策、同意书、数据保留规则
数字化领导力强 董事会批准了数字化计划,并为其制定预算、指定负责人 董事会会议纪要、预算
报告充分 关键指标由第二人核查,并按时报告 指标表、最近两份报告
在线吸引青年参与 青年共同创作内容,并每季度衡量触达人数 内容日历、季度触达数据

以下三条习惯会有所帮助:

  • 写出看得见或摸得着的事物:文件、惯例、角色或数字。禁用“良好”“强”“充分”和“有效”等词。
  • 每个级别只改变一项内容。如果3级同时新增预算、负责人和年度审查,那么只满足其中两项的合作伙伴就无处可归。
  • 让级别逐级递进。每个阶段都应包含其下级阶段的要求[3]。我在运筹学研究中常用的一种测试方法是:试着想象某个合作伙伴符合3级要求,却不符合2级要求。如果想得到这样的情形,说明顺序有误,或者该单元格属于另一个维度。

5. 为每个级别定义证据

为每个单元格写明可以用什么来证明:政策、会议纪要、报告或数据。较低级别的证据要求应简单一些;级别越高,主张越大,证据要求也可以相应提高。还要写清楚由谁提供证据、由谁确认。不要索要没人会看的证据:每份文件都会占用合作伙伴的时间,而这些时间本可以用于实际工作。

6. 与合作伙伴验证模型

把草案交给将来要使用它的人看。de Bruin及其同事使用德尔菲法和焦点小组来开发和检验模型[3];McKinsey让近十位非营利组织执行主任测试其框架[5];CMM 1.1版则是在一场约有200名软件专业人士参加、讨论1.0版的研讨会收集反馈后推出的[1]。对于合作伙伴网络,可以先邀请八到十家情况各异的合作伙伴参加一场两小时的工作坊。提出以下问题:你们能在模型中看到自己的情况吗?这是你们熟悉的表达方式吗?还缺少什么?有没有让人感到羞辱的地方?

7. 开展试点并校准

选取三到五家合作伙伴,实际运行模型。de Bruin及其同事强调,要检验工具的效度和信度,确保结果准确且可重复[3]。实际做法是:让两个人独立评估同一家合作伙伴;每一处意见不一致,都说明有一条描述需要改写。如果试点中的合作伙伴都落在2级,说明级别缺乏区分度;如果没人能想象如何达到4级,那它就只是一份愿望清单。一把把所有人都归进同一格的尺子,毫无信息价值。

8. 管理变更并重新评估

Becker及其同事指出,随着环境、技术和知识不断变化,所有成熟度模型都会过时;所需的变更应纳入新版本[2]。把模型当作一项标准来管理:设置版本号,每年安排一个变更窗口,记录变更内容及原因,并且不要在一轮评估中途修改。1.1版修改某个单元格时,要说明1.0版中的级别如何对应,避免合作伙伴仅仅因为你改写了一句话就被降级。之后每6至12个月重新评估一次。关于如何开展这些评估,以及为什么绝不能把各维度的级别平均成一个分数,请参阅我们的合作伙伴能力评估指南。

合作伙伴成熟度模型模板(免费下载)

这份模板将八个步骤整理为四张A4页面:目的与范围;维度与级别;描述网格,附带描述测试和校准备注;以及证据计划、验证计划和版本记录。

空白成熟度模型构建模板第1页:模型详情、方法的八个步骤、模型用途,以及关于模型目的的五个问题
模板第1页:先明确模型的用途,再编写任何级别。

下载成熟度模型构建模板(PDF,共4页)。打印出来用于设计工作坊,也可以复制其中的各个部分。

准备好把网格转变为合作伙伴可以参与的项目了吗?在 Advancer.World 中,维度对应主题,级别对应阶段,每条描述对应一个单元格,级别之间的步骤则可提出证据要求。每位合作伙伴都能看到自己的进展。免费开始使用。

立即注册

示例:联盟的“成员数字成熟度路径”

以下是为虚构联盟 Meridian Youth Federation 填写的模板示例。该联盟由26个国家级成员组织组成。

已填写的示例第3页:六个数字成熟度领域,按四个级别描述,从探索到引领,并附有描述测试和试点校准备注
示例第3页(虚构联盟):描述网格、测试,以及试点带来的改动。

下载已填写的示例(PDF,共4页)。以下四个做法值得借鉴:

  • 明确说明模型不用于什么目的。模型用于确定谁先获得同伴辅导,以及数字支持基金资助哪些项目;绝不用于决定成员资格或对成员排名。
  • 尝试过五级后,最终选用四级。没人能用证据区分初稿中的两个中间级别,因此删去了第五级。
  • 三个主题下设六个领域。某个成员可以在在线参与方面达到“引领”级别,在数据保护方面处于“探索”级别;联盟需要看到的正是这种能力概况。
  • 试点改变了措辞。两位评估者对“定期发布”理解不同,一位认为是每周,另一位认为是每月。因此,在线参与2级改为“为不同受众设置相应渠道的内容日历”。

构建成熟度模型时常见的错误

  1. 先写级别,后想目的。没有明确需要支持的决策,模型就会逐渐变成排名,合作伙伴也会把它当作排名。
  2. 把问卷误当成模型。SEI曾在1987年推出自己的成熟度问卷,许多人却常常把问卷本身当成了模型[1]。模型是发展路径;问卷只是衡量路径的一种方式。
  3. 用形容词代替可观察的状态。每位评估者对“充分”的理解都不同。
  4. 维度过多。40项指标会让模型变得没人能完成。
  5. 为合作伙伴设计,而不是与合作伙伴共同设计。如果1级写成一连串失败表现,合作伙伴就会学着隐瞒问题。
  6. 在评估过程中途修改。只要修改一条描述,本轮结果就无法与上一轮直接比较。

在 Advancer.World 中构建成熟度模型

Advancer.World 源于 UNICEF、空中客车等组织的项目数字化转型实践;在平台上,一个项目的结构与成熟度模型相同:阶段对应级别,主题和子主题对应维度,每个单元格都包含一条描述。

Advancer.World 项目设计:成员数字成熟度路径,包含从探索到引领的四个阶段,涵盖战略、运营和人员
示例模型在 Advancer.World 中的项目形式(示例数据,虚构联盟):三个主题下设六个领域,共四个阶段。

单元格之间的步骤会列出合作伙伴提升级别所需完成的事项:上传证据文件、填写调查问卷、参与计划活动,以及提交电子签名。你可以按项目选择合作伙伴的晋级方式:自我评估、完成前一步后自动晋级,或者仅在团队确认后晋级。团队成员可以实时协同编辑设计。合作伙伴可以使用22种语言查看自己的进展和下一级要求,但无法看到其他合作伙伴的数据。每日快照会保留历史记录,因此报告可以显示网络在不同评估轮次之间的变化。

常见问题

成熟度模型应设置多少个级别?

对于大多数合作伙伴网络,设置四到五个级别即可。关键是每个级别都应有所区别、定义清晰,并且相较于下一级别构成合乎逻辑的进阶步骤 [3]。如果评估人员在试点中无法区分两个级别,就将它们合并。

构建成熟度模型需要多长时间?

初版计划用两到三个月:先用几周确定目的、维度和级别,再用几周制定描述和证据要求,之后举办合作伙伴研讨会并开展试点。走捷径的后果往往是不得不推出无人为其预留预算的第二版。

我们能否改编现有的成熟度模型,而不是从头构建?

通常可以,而且你们应先考虑这种做法 [2]。检查许可条款;如果结构符合你们的目的,就保留结构,并用你们网络所使用的语言重写描述。

合作伙伴在不同维度上可以处于不同级别吗?

可以,而且通常确实如此;这种成熟度画像正是模型最有用的输出。合作伙伴不应在同一个维度内跳过级别,CMM 的作者在讨论他们自己的级别时也指出了这一点 [1]。

从明确目的开始,而不是从设置级别开始

如果你只从本指南中记住一件事,那就记住这个顺序。用一页纸写明目的,与几位合作伙伴达成共识,然后再打开评估表。按这种方式构建模型,启动需要更长时间,但之后为其合理性辩护所需的时间会少得多。

一次构建成熟度模型,并将其用于每一位合作伙伴。 与团队一起设计评估表,邀请合作伙伴参与,并在一轮又一轮的评估中了解他们各自的进展。免费开始。

立即注册

参考文献

  1. Mark C. Paulk、Bill Curtis、Mary Beth Chrissis 和 Charles V. Weber,卡内基梅隆大学软件工程研究所,《软件能力成熟度模型,1.1 版》(CMU/SEI-93-TR-024),1993 年 2 月,https://www.sei.cmu.edu/library/capability-maturity-model-for-software-version-11/(访问于 2026 年 10 月)。
  2. Jörg Becker、Ralf Knackstedt 和 Jens Pöppelbuß,《开发 IT 管理成熟度模型:流程模型及其应用》,《商业与信息系统工程》,1(3),2009 年,第 213-222 页,https://doi.org/10.1007/s12599-009-0044-5(访问于 2026 年 10 月)。
  3. Tonia de Bruin、Michael Rosemann、Ronald Freeze 和 Uday Kulkarni,《理解成熟度评估模型开发的主要阶段》,第 16 届澳大利亚信息系统会议(ACIS),悉尼,2005 年,https://aisel.aisnet.org/acis2005/109(访问于 2026 年 10 月)。
  4. Jens Pöppelbuß 和 Maximilian Röglinger,《什么样的成熟度模型才有用?成熟度模型通用设计原则框架及其在业务流程管理中的应用》,第 19 届欧洲信息系统会议论文集(ECIS 2011),2011 年 6 月,https://aisel.aisnet.org/ecis2011/28/(访问于 2026 年 10 月)。
  5. McKinsey & Company 为 Venture Philanthropy Partners 撰写,《非营利组织的有效能力建设》,2001 年,https://www.bridgespan.org/getmedia/ef1ff943-173b-48ec-843a-b5ce85c6c807/effective-capacity-building-VPP.pdf(访问于 2026 年 10 月)。

© 2026 Mourinho Solutions。保留所有权利。

← 返回博客