Módulos por rol: activar todo para todos mata la adopción

Hay una decisión de configuración que parece un detalle menor y define el destino de un entorno común de datos: qué módulos ve cada rol. La tentación es activarlo todo para todos. Parece generoso, parece flexible, parece que le das a cada usuario el máximo de posibilidades. En la práctica es la forma más rápida de matar la adopción.

Lo vi de cerca configurando Forma para un programa de infraestructura aeroportuaria a gran escala. El patrón se repite en cualquier proyecto: un usuario entra por primera vez a la plataforma, ve ocho módulos de los cuales le corresponden dos, no sabe por dónde empezar, concluye que la herramienta es complicada y vuelve al correo electrónico. La plataforma no falló por falta de funciones. Falló por exceso de funciones visibles.

La matriz que se diseña antes de invitar a nadie

La alternativa es aburrida y funciona: una matriz de rol por módulo, diseñada antes de invitar al primer usuario. El ejercicio es simple de describir y exigente de hacer bien. Se listan los roles reales del proyecto, no los cargos del organigrama: quién revisa planos, quién gestiona costes, quién coordina modelos, quién solo necesita consultar documentos. Se listan los módulos disponibles. Y se marca, celda por celda, qué necesita cada rol para hacer su trabajo. Todo lo demás queda apagado.

El que revisa planos ve revisión, no costes. El que gestiona contratos y órdenes de cambio ve el módulo de costes, no la coordinación de modelos. El que solo consulta ve documentos y nada más. Cada pantalla se parece al trabajo de quien la mira, y esa familiaridad es la que hace que la gente vuelva mañana.

Cada módulo de más es ruido

La idea de fondo es que cada módulo de más no es generosidad: es ruido. Y el ruido se paga en la única métrica que de verdad importa en un CDE, que es la adopción. Una plataforma perfectamente configurada que la gente no usa es un fracaso caro: se pagó la licencia, se pagó la implementación y la información del proyecto sigue viajando por correo.

Hay además un beneficio de gobernanza que se subestima. Cuando cada rol ve solo lo suyo, los errores bajan: nadie aprueba lo que no debía aprobar ni edita lo que no debía tocar, porque la opción ni siquiera aparece en su pantalla. El permiso más robusto es el módulo que nunca se activó.

La matriz también se versiona

Una advertencia de la práctica: la matriz no es un documento que se hace una vez y se enmarca. Los proyectos cambian, aparecen roles nuevos y módulos que no hacían falta empiezan a hacer falta. En el programa aeroportuario, ningún cambio de configuración llegaba directo a producción: se probaba primero en un hub de pruebas, se validaba con casos reales y solo entonces se replicaba a la plantilla de producción. La matriz de módulos siguió el mismo circuito, porque es parte de la estructura, y la estructura se gobierna igual que el contenido.

Si tu CDE tiene más módulos encendidos que usuarios contentos, la revisión que necesitas no es de software. Es de diseño. Y empieza por una tabla de roles y módulos que cabe en una sola hoja.