El 80% de los problemas de un CDE son de estructura

Cuando un entorno común de datos empieza a doler, las quejas siempre suenan a software. No encuentro nada. No tengo permiso para esta carpeta. Cada equipo nombra los archivos a su manera. El buscador no sirve. Y como suenan a software, la reacción natural es buscar otro software: otra plataforma, otro módulo, otra migración.

Después de configurar un CDE en Forma para un programa de infraestructura aeroportuaria a gran escala, mi diagnóstico es otro: el 80% de esos problemas no son del software. Son de la estructura que nadie se sentó a diseñar antes de arrancar.

Tres decisiones que resuelven la mayoría

Carpetas diseñadas antes de crear la primera. La estructura de un CDE debe reflejar cómo fluye la información del proyecto: qué se produce, quién lo revisa, hacia dónde se publica. Cuando la estructura copia el organigrama de la empresa, cada departamento arma su rincón, los duplicados florecen y encontrar el plano vigente se vuelve un acto de fe. La estructura correcta se diseña en papel, se discute con los equipos y solo entonces se crea en la plataforma.

Permisos por herencia, no carpeta por carpeta. Cada permiso asignado a mano es una inconsistencia futura esperando su momento. La herencia hace el trabajo pesado: defines el acceso en el nivel correcto del árbol y las carpetas hijas lo reciben solas. Cuando alguien pide una excepción, la pregunta no es cómo asignarla, sino por qué la estructura la está pidiendo. Muchas veces la excepción es el síntoma de una carpeta mal ubicada.

Módulos activados por rol. Activar todo para todos parece generoso y es la forma más rápida de matar la adopción. Un usuario que entra y ve ocho módulos que no le corresponden concluye que la plataforma es complicada y vuelve al correo. Cada rol debe ver lo que usa: el que revisa, revisión; el que publica, publicación. La adopción crece cuando la pantalla de cada quien se parece a su trabajo.

Diseñar antes de repartir accesos

Nada de esto requiere comprar nada. Requiere algo más escaso: sentarse a diseñar antes de repartir accesos, exactamente el paso que se salta cuando hay prisa por arrancar el proyecto. La prisa es comprensible, pero el costo es alto: una estructura mal parida no se corrige sola, se degrada. Cada semana que pasa hay más archivos dentro, más costumbres formadas y más resistencia al reordenamiento.

Hay una cuarta práctica que multiplica a las otras tres: probar la estructura antes de imponerla. En el programa aeroportuario, ningún cambio estructural llegaba directo a producción: se montaba en un hub de pruebas, se validaba con casos reales y solo entonces se replicaba a la plantilla de producción. La estructura también es un producto, y como todo producto, mejora cuando tiene un lugar seguro donde equivocarse.

Por eso, cuando un CDE se siente como un enemigo, mi primera revisión no es de configuración avanzada. Es estructural: cómo están las carpetas, cómo se heredan los permisos, qué ve cada rol. Ahí vive el 80% del dolor, y también el 80% del remedio.