La petición suele llegar en una sola línea de un informe para la junta directiva: desarrollar un modelo de madurez para nuestros aliados. Alguien de la secretaría abre una hoja de cálculo, escribe cinco encabezados, de Básico a Excelente, y empieza a rellenar las celdas. Semanas después, en la reunión de miembros, nadie habla de gobernanza ni de competencias digitales. Hablan de si un miembro es «bueno» o «muy bueno», y de quién lo ha decidido.
Rara vez el problema es el esfuerzo; el problema es el orden de las decisiones. Esta guía explica cómo crear un modelo de madurez para una red de aliados en ocho pasos, desde el propósito hasta su primera revisión, e incluye una plantilla gratuita de cuatro páginas, un ejemplo cumplimentado para una federación ficticia y los errores que yo evitaría.
Qué es un modelo de madurez y de dónde surgió la idea
En noviembre de 1986, el Software Engineering Institute de Carnegie Mellon University empezó a desarrollar un marco de madurez de procesos, a raíz de una petición para ofrecer al Gobierno federal de Estados Unidos una forma de evaluar la capacidad de sus contratistas de software. En 1993 se convirtió en el Capability Maturity Model for Software, cuyos cinco niveles de madurez, en palabras del propio SEI, «definen una escala ordinal» [1].
La estructura se ha mantenido: una secuencia de niveles que describe una trayectoria de desarrollo prevista, deseada o típica, en etapas diferenciadas [2]. Cada nivel indica qué debe cumplirse para alcanzarlo, de modo que una evaluación sitúa a una organización en esa trayectoria y muestra el siguiente paso. En 2005 ya existían más de 150 modelos de madurez, en campos que iban desde los servicios de TI hasta la gestión del conocimiento [3]. Sin embargo, cuando Becker, Knackstedt y Pöppelbuß analizaron 51 de ellos, solo nueve documentaban detalladamente su proceso de diseño [2]. Lo que sigue es el método de esa investigación, adaptado para los equipos que diseñan programas.
Cómo crear un modelo de madurez en ocho pasos
Los pasos siguen las fases que de Bruin, Rosemann, Freeze y Kulkarni propusieron para desarrollar cualquier modelo de madurez: alcance, diseño, elaboración, prueba, implantación y mantenimiento [3]. Cada decisión condiciona la siguiente, y el proyecto piloto te llevará a reescribir los descriptores al menos una vez.
1. Decide para qué sirve el modelo
Antes de definir ningún nivel, anota qué decisiones orientará el modelo. La investigación distingue tres usos [3][4]: un modelo descriptivo muestra dónde se encuentra hoy cada aliado; uno prescriptivo también indica qué hacer a continuación; y uno comparativo compara aliados o regiones, para lo que hacen falta muchas evaluaciones y criterios muy estables. La mayoría de las redes de aliados necesitan los dos primeros.
En la misma página, responde quién lo cumplimentará (el aliado por su cuenta, contigo o con tu confirmación), con qué frecuencia y para qué nunca se utilizará. Por mi experiencia, esta última aclaración ayuda más a obtener respuestas sinceras que cualquier instrucción. Si los miembros sospechan que el modelo decidirá su pertenencia a la red o la concesión de una subvención, se puntuarán alto y el modelo describirá una red que no existe.
2. Elige las dimensiones
Las dimensiones son los temas que abarca el modelo: gobernanza, finanzas, competencias digitales, protección y participación juvenil. Procura que sean pocas, para limitar la complejidad, y que sean independientes (los dos modelos de de Bruin y sus colegas tenían seis y cuatro componentes principales). Además, deben ser mutuamente excluyentes y colectivamente exhaustivas [3]: ninguna evidencia debe contar dos veces y no debe faltar nada que requiera el propósito del modelo. Yo intento ceñirme a entre cuatro y siete, divididas en dos o tres subdimensiones cuando un tema es amplio.
Antes de escribir el tuyo, averigua qué modelos existen: comparar el nuevo modelo con los ya existentes es el primer requisito que Becker y sus colegas establecieron para crear uno [2]. Para el fortalecimiento de capacidades, los siete elementos de la matriz de McKinsey de 2001 para Venture Philanthropy Partners son un buen punto de partida [5], al igual que los seis ámbitos de nuestra guía de evaluación de la capacidad de los aliados.
3. Elige cuatro o cinco niveles
El CMM utiliza cinco niveles [1]; la matriz de McKinsey, cuatro [5]. El número importa menos que el requisito que señalan de Bruin y sus colegas: etapas diferenciadas y bien definidas, con una progresión lógica y una etiqueta breve que indique la intención de cada una [3].
| Cuatro niveles | Cinco niveles | |
|---|---|---|
| Etiquetas habituales | Exploración, Desarrollo, Integración, Liderazgo | Inicial, Repetible, Definido, Gestionado, Optimizado (los del CMM) [1] |
| Cuándo encaja | Cuando puedes demostrar cuatro estados diferenciados, desde los primeros pasos hasta liderar a otras organizaciones | Cuando puedes demostrar la diferencia entre hacerlo bien y mejorarlo de forma sistemática |
| Ten en cuenta | Que dos estados distintos acaben comprimidos en un nivel en el que los aliados se queden durante años | Que nadie alcance el nivel superior y que quienes evalúan no puedan distinguir los niveles intermedios |
Mi regla viene de la investigación operativa: un nivel solo merece estar ahí si puedes describirlo con evidencias y distinguirlo de los niveles contiguos. Cuenta los estados que realmente puedes observar en tu red y detente ahí. El número también puede aumentar: Becker y sus colegas empezaron su modelo de rendimiento de TI con cuatro etapas y, tras entrevistar a responsables de TI, pasaron a seis, de «inexistente» a «optimizado», para diferenciar los casos de menor nivel [2]. Y redacta el nivel más bajo como un punto de partida, no como un veredicto: «Exploración» abre una conversación; «Deficiente» la cierra.
4. Describe cada nivel como un estado observable
Aquí es donde fallan la mayoría de los modelos. Un descriptor es el texto de una celda de la matriz. Pöppelbuß y Röglinger incluyen entre los principios de diseño de un modelo de madurez útil los criterios verificables intersubjetivamente: descripciones lo bastante precisas y claras como para distinguir un nivel del siguiente [4]. Dicho de forma sencilla: dos personas que observen al mismo aliado deberían elegir la misma celda.
| Descriptor impreciso | Descriptor observable | Evidencia |
|---|---|---|
| Buena protección de datos | Hay una persona responsable de los datos; las normas de consentimiento y conservación están por escrito y se aplican | Política de datos, formulario de consentimiento, norma de conservación |
| Liderazgo digital sólido | La junta directiva ha aprobado un plan digital con presupuesto y una persona responsable | Actas de la junta, presupuesto |
| Informes adecuados | Una segunda persona verifica los indicadores clave y los informes se entregan a tiempo | Hoja de indicadores, los dos últimos informes |
| Implicación de jóvenes en internet | Los jóvenes crean contenidos conjuntamente y se mide el alcance cada trimestre | Calendario de contenidos, cifras trimestrales de alcance |
Tres hábitos te ayudarán:
- Nombra algo que puedas ver o tocar: un documento, una rutina, un cargo, una cifra. Evita «bueno», «sólido», «adecuado» y «eficaz».
- Cambia una sola cosa en cada paso. Si el nivel 3 añade a la vez un presupuesto, una persona responsable y una revisión anual, un aliado que cumpla dos de los tres requisitos no tendrá dónde encajar.
- Haz que los niveles sean acumulativos. Cada etapa debe incluir lo que exigen las etapas anteriores [3]. Una prueba que aprendí en mis tiempos de investigación operativa: imagina un aliado que cumpla el nivel 3, pero no el nivel 2. Si puedes imaginarlo, el orden es incorrecto o esa celda pertenece a otra dimensión.
5. Define las evidencias para cada nivel
Para cada celda, indica qué la demostraría: una política, un acta, un informe o una cifra. Pide pocas evidencias en los niveles inferiores y más en los superiores, donde las afirmaciones son más ambiciosas, e indica quién las aporta y quién las confirma. No pidas nunca evidencias que nadie vaya a leer: cada documento le quita al aliado tiempo que podría dedicar a su trabajo.
6. Valida el modelo con los aliados
Presenta el borrador a las personas que tendrán que convivir con él. De Bruin y sus colegas utilizaron la técnica Delphi y grupos focales para crear y revisar sus modelos [3]; McKinsey probó su matriz con casi una docena de directores ejecutivos de organizaciones sin ánimo de lucro [5]; y la versión 1.1 del CMM surgió de los comentarios recogidos en un taller sobre la versión 1.0, al que asistieron unos 200 profesionales del software [1]. Para una red de aliados, empieza con un taller de dos horas en el que participen entre ocho y diez aliados diversos. Pregunta: ¿Os reconocéis? ¿Es vuestro lenguaje? ¿Qué falta? ¿Hay algo que resulte humillante?
7. Haz una prueba piloto y calibra
Aplica el modelo en condiciones reales con entre tres y cinco aliados. De Bruin y sus colegas insisten en comprobar la validez y fiabilidad del instrumento, para que los resultados sean precisos y reproducibles [3]. En la práctica: dos personas evalúan al mismo aliado por separado y cada desacuerdo señala un descriptor que hay que reescribir. Si todos los aliados del piloto quedan en el nivel 2, tus niveles no permiten diferenciarlos; si nadie puede imaginarse llegando al nivel 4, es una lista de deseos. Una escala que coloca a todos en la misma categoría no aporta información.
8. Gestiona los cambios y vuelve a evaluar
Becker y sus colegas señalan que todos los modelos de madurez envejecen a medida que cambian las circunstancias, la tecnología y el conocimiento, y que las modificaciones necesarias deben incorporarse en una nueva versión del modelo [2]. Trátalo como una norma: asigna un número de versión, establece una única ventana anual para los cambios, lleva un registro de qué ha cambiado y por qué, y no hagas modificaciones durante una ronda de evaluación. Cuando la versión 1.1 cambie una celda, explica cómo se trasladan las posiciones de la versión 1.0, para que ningún aliado baje de nivel porque hayas reformulado una frase. Después, vuelve a evaluar cada 6 a 12 meses. En nuestra guía de evaluación de la capacidad de los aliados encontrarás cómo organizar esas rondas y por qué nunca debes promediar los niveles para obtener una puntuación única.
Plantilla para el modelo de madurez de aliados (descarga gratuita)
La plantilla convierte los ocho pasos en cuatro páginas A4: propósito y alcance; dimensiones y niveles; la matriz de descriptores, con una prueba de descriptores y notas de calibración; y el plan de evidencias, el plan de validación y el registro de versiones.
Descarga la plantilla para crear un modelo de madurez (PDF, 4 páginas). Imprímela para un taller de diseño o copia las secciones.
¿Todo listo para convertir la matriz en un programa en el que puedan trabajar los aliados? En Advancer.World, tus dimensiones se convierten en temas, tus niveles en etapas y cada descriptor en una celda, con solicitudes de evidencias en los pasos entre niveles. Cada aliado ve dónde se encuentra. Gratis para empezar.
Ejemplo: el itinerario de madurez digital de los miembros de una federación
Esta es la plantilla cumplimentada para Meridian Youth Federation, una federación ficticia formada por 26 organizaciones miembro nacionales.
Descarga el ejemplo cumplimentado (PDF, 4 páginas). Merece la pena copiar cuatro decisiones:
- El propósito excluye algo. El modelo ayuda a decidir quién recibe primero asesoramiento entre pares y qué financia el fondo de apoyo digital; nunca se utiliza para determinar la pertenencia a la federación ni para elaborar clasificaciones.
- Cuatro niveles, después de probar cinco. Nadie pudo demostrar que hubiera una diferencia entre los dos niveles intermedios del primer borrador, así que se eliminó el quinto nivel.
- Seis ámbitos en tres temas. Un miembro puede tener un nivel de Liderazgo en la participación en línea y de Exploración en la protección de datos. Ese perfil es lo que la federación necesita ver.
- El proyecto piloto cambió las palabras. Dos evaluadores interpretaron «publica con regularidad» como semanalmente y como mensualmente, así que el nivel 2 de participación en línea pasó a ser «un calendario de contenidos con canales para cada público».
Errores habituales al crear un modelo de madurez
- Definir los niveles antes que el propósito. Sin una decisión que orientar, el modelo acaba convertido en una clasificación, y los aliados lo tratan como tal.
- Confundir el cuestionario con el modelo. El SEI se encontró con este problema con su propio cuestionario de madurez de 1987, que a menudo se confundía con el modelo en sí [1]. El modelo es la trayectoria; el cuestionario, una forma de medirla.
- Usar adjetivos en vez de estados observables. Cada evaluador interpreta «adecuado» de forma distinta.
- Incluir demasiadas dimensiones. Cuarenta indicadores dan lugar a un modelo que nadie termina.
- Diseñarlo para los aliados en vez de con ellos. Un nivel 1 redactado como una lista de carencias enseña a los aliados a ocultarlas.
- Cambiarlo a mitad de una ronda. Modificar un descriptor hace que esta ronda deje de ser comparable con la anterior.
Crear tu modelo de madurez en Advancer.World
Advancer.World nació de la transformación digital de programas en organizaciones como UNICEF y Airbus, y uno de sus programas tiene la estructura de un modelo de madurez: las etapas son tus niveles, los temas y subtemas, tus dimensiones, y cada celda contiene un descriptor.
Los pasos entre celdas incluyen lo que necesita un aliado para avanzar: solicitudes para subir documentos como evidencia, encuestas, iniciativas y solicitudes de firma electrónica. En cada programa decides cómo avanzan los aliados: mediante una autoevaluación, automáticamente al completar el paso anterior o solo cuando lo confirma tu equipo. Tu equipo puede editar el diseño conjuntamente y en tiempo real. Los aliados ven dónde están y qué les exige el siguiente nivel, en cualquiera de los 22 idiomas, y nunca ven los datos de otros aliados. Las instantáneas diarias conservan el historial, para que los informes muestren cómo ha avanzado la red entre rondas.
Preguntas frecuentes
¿Cuántos niveles debe tener un modelo de madurez?
Cuatro o cinco en la mayoría de las redes de Aliados. Lo importante es que cada nivel sea distinto, esté bien definido y constituya un paso lógico respecto al anterior [3]. Si quienes evalúan no pueden distinguir dos niveles durante la prueba piloto, fusiónalos.
¿Cuánto se tarda en crear un modelo de madurez?
Calcula entre dos y tres meses para una primera versión: unas semanas para definir el propósito, las dimensiones y los niveles; unas cuantas más para los descriptores y las evidencias; y después, el taller con los Aliados y una prueba piloto. Los atajos acaban dando lugar a una segunda versión para la que nadie había previsto presupuesto.
¿Podemos adaptar un modelo de madurez existente en lugar de crear uno?
A menudo, sí, y es lo primero que deberías valorar [2]. Comprueba la licencia, conserva la estructura si encaja con tu propósito y redacta de nuevo los descriptores con el lenguaje de tu red.
¿Puede un Aliado estar en distintos niveles según la dimensión?
Sí, y normalmente es así; ese perfil es el resultado más útil del modelo. Lo que un Aliado no debería hacer es saltarse niveles dentro de una misma dimensión, una cuestión que los autores del CMM señalaron en relación con sus propios niveles [1].
Empieza por el propósito, no por los niveles
Si te quedas con una sola idea de esta guía, que sea el orden. Escribe el propósito en una página, acuerda su contenido con algunos Aliados y solo entonces abre la matriz. Un modelo creado de este modo tarda más en ponerse en marcha y mucho menos en defenderse.
Crea tu modelo de madurez una sola vez y aplícalo con todos tus Aliados. Diseña la matriz con tu equipo, invita a tus Aliados y descubre en qué punto se encuentra cada uno, ronda tras ronda. Gratis para empezar.
Referencias
- Mark C. Paulk, Bill Curtis, Mary Beth Chrissis y Charles V. Weber, Software Engineering Institute, Carnegie Mellon University, «Capability Maturity Model for Software, Version 1.1» (CMU/SEI-93-TR-024), febrero de 1993, https://www.sei.cmu.edu/library/capability-maturity-model-for-software-version-11/ (consultado en octubre de 2026).
- Jörg Becker, Ralf Knackstedt y Jens Pöppelbuß, «Developing Maturity Models for IT Management: A Procedure Model and its Application», Business & Information Systems Engineering, 1(3), 2009, pp. 213-222, https://doi.org/10.1007/s12599-009-0044-5 (consultado en octubre de 2026).
- Tonia de Bruin, Michael Rosemann, Ronald Freeze y Uday Kulkarni, «Understanding the Main Phases of Developing a Maturity Assessment Model», 16.ª Conferencia Australasiana sobre Sistemas de Información (ACIS), Sídney, 2005, https://aisel.aisnet.org/acis2005/109 (consultado en octubre de 2026).
- Jens Pöppelbuß y Maximilian Röglinger, «What Makes a Useful Maturity Model? A Framework of General Design Principles for Maturity Models and its Demonstration in Business Process Management», actas de la 19.ª Conferencia Europea sobre Sistemas de Información (ECIS 2011), junio de 2011, https://aisel.aisnet.org/ecis2011/28/ (consultado en octubre de 2026).
- McKinsey & Company para Venture Philanthropy Partners, «Effective Capacity Building in Nonprofit Organizations», 2001, https://www.bridgespan.org/getmedia/ef1ff943-173b-48ec-843a-b5ce85c6c807/effective-capacity-building-VPP.pdf (consultado en octubre de 2026).
© 2026 Mourinho Solutions. Todos los derechos reservados.
