Un despliegue que funciona a la perfección en una sede y se desmorona en la quinta casi nunca es un problema de tecnología: es un problema de gobernanza que la primera sede era demasiado pequeña para exponer. Los despliegues tecnológicos multisede fracasan con menos frecuencia por la tecnología en sí que por las decisiones que nadie tomó sobre cuánto puede diferir la sede cinco de la sede uno.
Por qué la primera sede siempre parece un éxito
La sede piloto recibe más atención, acceso más directo a las personas que diseñaron el despliegue y mayor tolerancia a la improvisación cuando algo no encaja. Nada de eso escala. Un plan de despliegue validado únicamente contra una sede piloto queda validado exactamente contra las condiciones que no se repetirán en cuanto el mismo equipo esté gestionando cuatro sedes en paralelo en lugar de una sola con atención total.
La pregunta de variación que introduce cada sede
Cada sede adicional trae variación real: distinta antigüedad del edificio y del cableado, distinta capacidad de TI local, distintas relaciones con proveedores ya establecidas, distinta conectividad regional. Un plan de despliegue necesita una respuesta explícita, decidida antes de que comience la segunda sede, sobre cuánta desviación local del estándar es aceptable y quién tiene la autoridad para aprobarla. Sin esa respuesta, la desviación ocurre de todos modos, solo que de manera informal y sin documentar, y para la sexta sede nadie puede decir qué está realmente implementado y dónde.
Derechos de decisión: quién puede aprobar una excepción local
El modo de falla específico es que un gerente de sede o un instalador externo tome una decisión local que suena razonable —un modelo distinto de punto de acceso por un problema de suministro, una segmentación de red modificada porque el cableado del edificio no coincidía con el estándar— sin que nadie con visibilidad sobre todo el despliegue la apruebe. Cada decisión individual puede ser defendible. El conjunto, sin documentar, es un entorno que nadie puede soportar ni proteger de manera consistente.
Qué debe estandarizarse y qué puede flexibilizarse
Un modelo de gobernanza que funciona traza esa línea explícitamente antes de que comience el despliegue: la postura de seguridad, las convenciones de nomenclatura y documentación, y la arquitectura de red central no son negociables en ninguna sede. La selección de proveedores dentro de una lista aprobada, la ubicación física de los puntos de acceso adaptada al edificio real y las rutas de escalamiento de soporte local sí pueden flexibilizarse. Las sedes fracasan cuando esa línea nunca se traza y todo termina resolviéndose con un “lo que funcione” sede por sede.
El mecanismo de seguimiento que realmente detecta la desviación
La desviación solo es visible si algo compara realmente las sedes contra el estándar con una cadencia definida, en lugar de confiar en que el plan de despliegue se siguió al pie de la letra. Un proceso de gobernanza multisede real incluye un registro documentado de as-built por sede, verificado contra el estándar en intervalos definidos —no solo en la puesta en marcha— porque la desviación se acumula silenciosamente entre la fecha de implementación y la próxima vez que alguien la revisa de cerca.
La conclusión práctica
Antes de que comience el segundo despliegue, hay que definir qué es fijo, quién aprueba una excepción y cómo se detecta la desviación después de la puesta en marcha, no solo cómo se ejecuta la puesta en marcha en sí. La práctica de Liderazgo de Programas y Proyectos de TekFidelity trata la gobernanza de despliegues multisede como una disciplina distinta de la ejecución de proyectos de una sola sede, y Ingeniería de Infraestructura y Redes Inalámbricas es donde se define el estándar técnico en sí antes de que tenga que sostenerse en cinco edificios en lugar de uno.