Los Programas de Aliados rara vez fallan con 10 Aliados. Con 10, el coordinador conoce por su nombre al director de cada Aliado, basta una llamada para saber cómo van y el informe anual se prepara en una tarde. Los problemas aparecen de camino a los 200, cuando ese mismo coordinador empieza cada lunes con una bandeja de entrada llena de respuestas sobre el estado de los Aliados, un marco que existe en tres versiones y un informe para la junta directiva que llevará semanas.
No ocurre nada dramático. El Programa cruza una serie de umbrales y los hábitos que funcionaban con 10 Aliados dejan de funcionar uno tras otro. Así se amplía un Programa de Aliados sin sufrir ese deterioro gradual: los siete puntos de ruptura en el orden en que suelen aparecer, por qué falla cada uno a esa escala y cómo resolverlo, primero con buenas prácticas y después con herramientas. Además, una lista de comprobación de una página para evaluar la preparación de vuestro equipo.
Por qué los Programas de Aliados fallan por etapas: el coordinador se convierte en el cuello de botella
Antes de dedicarme a la transformación digital, enseñé investigación operativa en la Universidad de Oporto: las matemáticas de las colas, los cuellos de botella y la capacidad. Desde esa perspectiva, estas etapas tienen sentido.
En la mayoría de los Programas, casi todas las solicitudes pasan por una o dos personas: el coordinador que responde preguntas, revisa documentos, pide actualizaciones de estado y elabora Informes. En términos de teoría de colas, el coordinador es el servidor y cada solicitud es una llegada.
La ley de Little establece que el número medio de elementos en un sistema es igual a su tasa de llegada multiplicada por el tiempo medio que pasa cada uno en él [1]. La pila de solicitudes pendientes en la bandeja de entrada del coordinador no se debe a una falta de disciplina; es el resultado de multiplicar las llegadas por el tiempo de espera.
Un segundo resultado es menos intuitivo. En la cola más sencilla con un único servidor, el tiempo medio que pasa una solicitud en el sistema es su tiempo de tramitación dividido entre uno menos la utilización del servidor [2]. Con una ocupación del 50%, una solicitud tarda en completarse el doble de su tiempo de tramitación; al 80%, cinco veces más; al 95%, veinte. La espera no crece de forma lineal con la carga de trabajo. Se dispara a medida que se llena la semana.
Un ejemplo con supuestos que deberíais sustituir por los vuestros: un coordinador dispone de 20 horas semanales para atender solicitudes de Aliados y cada Aliado envía una solicitud a la semana que requiere 20 minutos de tramitación.
- 10 Aliados: algo más de 3 horas a la semana. El coordinador tiene una ocupación del 17% y las solicitudes apenas esperan.
- 50 Aliados: casi 17 horas. Una ocupación del 83%, y la solicitud media tarda en completarse seis veces su tiempo de tramitación.
- 60 Aliados: las 20 horas completas. La cola nunca se estabiliza; sigue creciendo.
El coordinador no se ha vuelto más lento; lo que ha cambiado son los números. Esos mismos números marcan el orden de las soluciones, como en cualquier línea de producción: primero reducir las llegadas (los Aliados encuentran respuestas sin preguntar), después acortar la tramitación (todas las solicitudes con el mismo formato y en el mismo lugar) y solo entonces incorporar más personas. Contratar, por sí solo, únicamente desplaza el límite: con los mismos supuestos, dos coordinadores lo alcanzan con 120 Aliados.
Los siete puntos de ruptura, en el orden en que suelen aparecer
1. El seguimiento del estado se hace por correo electrónico (a partir de unos 15 Aliados)
Síntoma. Cada mes, alguien envía un correo a cada Aliado para preguntar cómo va, insiste a quienes se retrasan y copia las respuestas en una hoja de cálculo. Cuando llega la última respuesta, la primera ya está desactualizada.
Por qué falla a esta escala. Una ronda de consultas de estado no genera más que llegadas: un mensaje enviado y una respuesta recibida por Aliado, más los recordatorios. Con 15 Aliados, lleva una tarde. Con 200 Aliados y una ronda mensual, son 2.400 solicitudes al año antes del primer recordatorio.
La solución. Dejad de preguntar por el estado; hacedlo visible. Acordad con los Aliados qué significa progresar en términos observables (una etapa alcanzada, una tarea completada, un documento aceptado), para que el estado se derive del propio trabajo.
2. El marco existe en varias versiones (a partir de unos 25)
Síntoma. El marco es un PDF de hace dos años, un archivo de Word actualizado y una diapositiva de un taller que alguien mejoró. Los Aliados que se incorporaron en años distintos trabajan con definiciones diferentes de una misma etapa.
Por qué falla a esta escala. Con 10 Aliados, un cambio se anuncia en una reunión y todo el mundo se entera. Con 25, los cambios viajan como archivos adjuntos y cada copia abre una versión distinta.
La solución. Una persona responsable, una única versión vigente, un registro de cambios y una fecha de entrada en vigor de cada cambio.
3. La incorporación depende de una sola persona (a partir de unos 40)
Síntoma. La persona que diseñó el Programa incorpora a los nuevos Aliados mediante una larga llamada. Cuando esa persona está de permiso, las incorporaciones se detienen; cuando se marcha, la memoria del Programa se va con ella.
Por qué falla a esta escala. La incorporación es una solicitud con un tiempo de tramitación largo, y los Programas suelen incorporar Aliados por grupos. Quince Aliados nuevos en el mismo mes acaban en la misma agenda.
La solución. Documentad la incorporación: un breve paquete de bienvenida, los tres primeros pasos y a quién preguntar cada cosa. Así, la primera llamada puede centrarse en el Aliado, no en el Programa.
4. Las evidencias están dispersas entre bandejas de entrada (a partir de unos 60)
Síntoma. Las políticas, auditorías, listas de formación y fotografías llegan como archivos adjuntos a la persona que el Aliado conoce mejor. Antes de una auditoría o de la visita de un donante, el equipo pasa días buscando en los buzones de correo.
Por qué falla a esta escala. Las evidencias crecen al multiplicar los Aliados por los requisitos, y llegan a bandejas de entrada personales que los compañeros no pueden consultar. Tened en cuenta también la carga al otro lado: un estudio de ICVA de 2016 sobre las condiciones impuestas por los donantes a las ONG humanitarias detectó una media de 36 plazos de presentación de Informes por país y año, y evaluaciones de capacidad de los Aliados que podían superar las 100 preguntas y llegar hasta los 91 anexos [3]. Vuestros Aliados soportan una versión de esa carga para vosotros.
La solución. Pedid cada evidencia una sola vez, con una fecha límite y vinculada al requisito que acredita. Solicitad únicamente lo que alguien vaya a leer.
5. Elaborar Informes lleva semanas (a partir de unos 90)
Síntoma. El informe anual empieza con un correo que pide cifras a cada Aliado, continúa con semanas de combinación de archivos y termina con un gráfico cuyo origen nadie puede rastrear.
Por qué falla a esta escala. A este tamaño, elaborar Informes es una tarea de ensamblaje: si los datos no se han recogido con una estructura común durante el año, alguien la construye al final, a mano. El mismo estudio de ICVA describe una ONG internacional que calculó que podría ahorrar 11.000 horas de elaboración de Informes financieros si sus nueve mayores donantes acordaran unas definiciones de costes y aceptaran la misma plantilla financiera [3]. En el Grand Bargain de 2016, los donantes y las organizaciones de ayuda se comprometieron a reducir las duplicidades y los costes de gestión, y a simplificar la presentación de Informes: menos volumen, terminología común, requisitos básicos y una estructura de informe común [4].
La solución. Elegid unos pocos KPIs antes de que empiece el año, definidlos del mismo modo para todos los Aliados y recopiladlos a medida que se realiza el trabajo. El informe pasa a ser una extracción de datos y las semanas se dedican a leerlo.
6. Los Aliados no saben qué se espera de ellos o no pueden trabajar en su idioma (a partir de unos 120)
Síntoma. Se repiten las mismas preguntas: qué necesitamos para la siguiente etapa, qué plantilla hay que usar, para cuándo. Los Aliados de algunos países responden tarde o no responden, y eso se interpreta como falta de implicación.
Por qué falla a esta escala. A estas alturas, el Programa cruza fronteras, pero las expectativas siguen expresándose en un solo idioma. Los autores de un artículo de Humanitarian Exchange de 2021 señalaron que las directrices globales y las herramientas técnicas suelen estar disponibles solo en los idiomas oficiales de la ONU, y que las reuniones de coordinación en idiomas internacionales agravan el problema [5]. A menudo, el silencio es un problema de idioma, no de motivación.
La solución. Describid cada etapa con términos sencillos y observables y traducidla junto con sus plantillas. Cada pregunta que responde la página es una solicitud que nunca llega a la cola.
7. Permisos y protección de datos (a partir de unos 160)
Síntoma. Cientos de personas tienen acceso a la carpeta compartida, nadie tiene claro quién puede ver la evaluación de cada Aliado y el delegado de protección de datos plantea preguntas que nadie sabe responder.
Por qué falla a esta escala. Con 10 Aliados, una carpeta compartida resulta práctica. Con 200, supone un riesgo: los registros de los Aliados contienen datos personales y evaluaciones sensibles, y los accesos concedidos manualmente rara vez se retiran. Las orientaciones de la Comisión Europea sobre la protección de datos por defecto indican que los datos personales deben ser accesibles «solo a un número limitado de personas, en función de la necesidad de conocerlos» [6].
La solución. Definid los roles antes de que se incorpore el siguiente grupo: quién puede ver y modificar cada cosa en vuestro equipo, y la norma de que cada Aliado solo vea sus propios datos. Revisad los accesos cuando alguien se incorpore o se marche.
Qué debe hacer una herramienta en cada punto de ruptura
Las buenas prácticas van primero: una herramienta que automatiza un proceso que no funciona solo hace que falle más deprisa. Después, esto es lo que la gestión de Aliados a gran escala exige a una herramienta:
| Punto de ruptura | Primero, la práctica | Qué debe hacer una herramienta |
|---|---|---|
| Seguimiento del estado por correo electrónico | Hacer que el estado se derive del propio trabajo | Permitir que los Aliados registren sus avances donde trabajan y mostraros la situación de cada uno sin tener que preguntar |
| Marco en varias versiones | Una persona responsable, una versión y un registro de cambios | Mantener un único marco para todos los Aliados, editado de forma colaborativa, con cambios que lleguen a todos a la vez |
| Incorporación dependiente de una persona | Un paquete de bienvenida por escrito | Mostrar a cada nuevo Aliado, desde su primer inicio de sesión, dónde se encuentra y qué requiere su siguiente paso |
| Evidencias perdidas en bandejas de entrada | Una sola solicitud por cada evidencia | Vincular cada archivo cargado al paso que acredita y mostrar qué falta en el conjunto de los Aliados |
| Elaboración de Informes que lleva semanas | Unos pocos KPIs, definidos de antemano | Mantener los KPIs de cada Aliado con su historial y generar Informes a partir de esos datos |
| Expectativas poco claras, un solo idioma | Descripciones sencillas de las etapas, traducidas | Mostrar a cada Aliado su situación y su siguiente paso en su propio idioma |
| Permisos y protección de datos | Roles definidos antes del siguiente grupo | Aplicar los roles, limitar a cada Aliado a sus propios datos, admitir el inicio de sesión de vuestra organización e indicar dónde se almacenan los archivos |
Una lista de comprobación de una página para evaluar la preparación para crecer
La lista convierte los siete puntos de ruptura en 21 afirmaciones e incluye los cálculos de carga del coordinador, con espacio para vuestras propias cifras. Revisadla con vuestro equipo antes de que se incorpore el siguiente grupo de Aliados y empezad por la primera sección que tenga dos o más casillas sin marcar.
Descargad la lista para evaluar la preparación para crecer (PDF, 1 página). Imprimidla para una reunión de equipo.
¿Ya habéis superado el segundo punto de ruptura? En Advancer.World, cada Aliado trabaja con una única versión de vuestro Programa, ve su propia situación y los requisitos de la siguiente etapa en su idioma, y envía las evidencias al paso que les corresponde. Vuestro equipo ve dónde se encuentra cada Aliado en lugar de tener que preguntar. Empezar es gratis.
Gestión de Aliados a gran escala en Advancer.World
Advancer.World nació de la transformación digital de Programas en organizaciones como UNICEF y Airbus. Un Programa es una única cuadrícula que se diseña una sola vez: las etapas en un eje, los temas y subtemas en el otro, y cada celda describe cómo es esa etapa para ese tema. Varias personas de vuestro equipo pueden diseñarlo al mismo tiempo y todos los Aliados trabajan con la misma versión.
Los pasos entre celdas contienen el trabajo: iniciativas, cuestionarios, solicitudes de carga de documentos y solicitudes de firma electrónica. En cada Programa elegís cómo avanzan los Aliados: mediante autoevaluación, automáticamente al completar el paso anterior o cuando vuestro equipo lo confirma. Los Aliados reciben una invitación por correo electrónico y ven su propia situación y los requisitos de la siguiente etapa en cualquiera de los 22 idiomas, incluidos árabe, urdu, suajili y hausa. Nunca ven los datos de otros Aliados, y ni los Aliados ni sus integrantes pagan nunca.
Los KPIs se registran por Aliado y las instantáneas diarias conservan el historial, de modo que los Informes de Excel y los Informes de Word redactados por IA con gráficos se generan a partir de los datos recogidos durante el año. Vuestra organización puede iniciar sesión con Microsoft Entra ID, los archivos se almacenan en la UE y, en los planes Gold y Enterprise, un asistente de IA puede consultar la situación de vuestros Aliados a través del servidor MCP. Si aún no conocéis MCP, empezad por qué es Model Context Protocol.
Preguntas frecuentes
¿Cuántos Aliados puede gestionar un coordinador?
No hay una proporción fija. Multiplicad el número de Aliados por las solicitudes que envía cada uno a la semana y por los minutos que requiere cada solicitud; después, dividid el resultado entre los minutos de los que realmente dispone vuestro coordinador para trabajar con los Aliados. Esa es la utilización. Al 80%, la solicitud media ya tarda en completarse cinco veces su tiempo de tramitación.
¿Cuándo deberíamos dejar de gestionar un Programa de Aliados con hojas de cálculo y correo electrónico?
Cuando aparezcan al mismo tiempo dos de los cuatro primeros puntos de ruptura, o antes de que se incorpore el siguiente grupo de Aliados, lo que ocurra primero. Si necesitáis ayuda para trasladar los datos existentes, Mourinho Solutions ofrece asistencia para la migración.
¿Una plataforma supondrá más trabajo para nuestros Aliados?
Debería reducirlo. Un Aliado que responde a correos sobre su estado, envía archivos adjuntos a tres personas y rellena una plantilla distinta para cada financiador ya está haciendo ese trabajo; un espacio compartido solo cambia dónde se realiza. Pedid a dos o tres Aliados que lo prueben primero.
Cómo ampliar un programa de aliados sin que deje de funcionar
No hace falta resolver los siete problemas a la vez. Identifique el primer punto crítico que su programa ya haya superado, resuélvalo y calcule la carga de trabajo del coordinador antes de que se incorpore el siguiente grupo. Un programa que crece bien no tiene un coordinador que haga heroicidades. Tiene un coordinador cuya semana no está saturada. Si necesita una segunda opinión sobre el propio diseño del programa, dispone de nuestro servicio de consultoría de programas.
Gestione 10 o 200 aliados con la misma estructura. Diseñe su programa una sola vez, invite a sus aliados y mantenga las evidencias, los KPIs y el historial en un solo lugar, en vez de en su bandeja de entrada. Empiece gratis.
Referencias
- John D. C. Little, «La ley de Little vista en su 50.º aniversario», Operations Research 59(3), pp. 536–549, mayo–junio de 2011, https://doi.org/10.1287/opre.1110.0940 (consultado en octubre de 2026).
- Richard C. Larson y Amedeo R. Odoni, «Investigación de operaciones urbanas», Prentice-Hall, 1981, sección 4.6.1, «Un operador, un número infinito de líneas», https://web.mit.edu/urban_or_book/www/book/chapter4/4.6.1.html (consultado en octubre de 2026).
- Consejo Internacional de Organizaciones Voluntarias (ICVA), «Menos papeleo, más ayuda: elaboración de informes, evaluación de la capacidad de los aliados y auditoría», actualizado en septiembre de 2016, https://alnap.org/help-library/resources/less-paper-more-aid-reporting-partner-capacity-assessment-and-audit/ (consultado en octubre de 2026).
- «El Gran Pacto: un compromiso compartido para atender mejor a las personas necesitadas», Estambul, 23 de mayo de 2016, https://gblocalisation.ifrc.org/wp-content/uploads/2018/06/grand_bargain_final_22_may_final-2_0.pdf (consultado en octubre de 2026).
- Mia Marzotto, Kemal Alp Taylan, Fatuma Ibrahim, Marian Ellen Hodgkin, Paul Martin Lukusa Mbwebwa y Charles Abugo, «“¿Cómo podemos contribuir si no podemos participar?” La accesibilidad de las directrices humanitarias para las organizaciones locales y nacionales», Humanitarian Exchange 79, Humanitarian Practice Network, 25 de mayo de 2021, https://odihpn.org/en/publication/how-can-we-contribute-if-we-cant-participate-the-accessibility-of-humanitarian-guidance-to-local-and-national-organisations/ (consultado en octubre de 2026).
- Comisión Europea, «Obligaciones: protección de datos desde el diseño y por defecto», https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/obligations/what-does-data-protection-design-and-default-mean_en (consultado en octubre de 2026).
© 2026 Mourinho Solutions. Todos los derechos reservados.
