Una aplicación para varias empresas o sedes: qué compartir y qué separar
Una aplicación puede servir a varias sedes desde un único sistema, pero primero hay que decidir qué representa cada unidad y qué información puede compartir. Dos sucursales de la misma sociedad no plantean necesariamente el mismo problema que dos sociedades independientes, una franquicia o dos clientes de un producto de software.
Lo esencial, antes de empezar
- Empresa, sede, equipo y cliente son ámbitos diferentes y deben modelarse con intención.
- Compartir una aplicación no obliga a compartir todos los datos, pero el aislamiento debe probarse.
- Los informes consolidados necesitan definiciones comunes y permisos de detalle explícitos.
Empresa, sede y equipo no son intercambiables
En un ejemplo hipotético, un grupo tiene dos sociedades y tres centros. Una persona de compras trabaja para ambas sociedades, cada centro tiene responsables distintos y dirección quiere un informe consolidado. Si el sistema solo guarda un campo «sede», puede resultar difícil separar numeraciones, permisos o configuraciones de cada sociedad.
| Elemento | Pregunta de negocio | Ejemplo hipotético |
|---|---|---|
| Organización | ¿Quién responde por el dato? | Sociedad A o sociedad B |
| Sede | ¿Dónde ocurre la operación? | Centro norte, sur o almacén |
| Usuario | ¿En qué ámbitos trabaja? | Compras en ambas sociedades |
| Catálogo | ¿Se comparte o varía? | Material común, tarifas distintas |
| Informe | ¿Quién ve detalle y agregado? | Dirección consolida; sede ve su actividad |
Añade los cambios plausibles: abrir otro centro, separar una unidad, vender una sociedad o incorporar a una persona que trabaja en varias. No hace falta diseñar para cualquier expansión imaginable, pero sí evitar que el siguiente paso razonable obligue a duplicar la aplicación.
Compartir aplicación no obliga a mezclar toda la información
La guía de Microsoft sobre modelos de tenencia presenta un espectro: recursos compartidos, particiones y entornos separados. La elección depende del riesgo, los requisitos, el coste y la operación. No existe un único modelo correcto para todo proyecto multiempresa.
Para negocio, convierte la arquitectura en preguntas: ¿pueden las unidades compartir infraestructura si sus datos quedan aislados? ¿Existe una condición contractual que exija separación adicional? ¿Quién opera copias, actualizaciones e informes? Mayor aislamiento puede elevar el esfuerzo operativo; compartir más exige controles y pruebas sólidos.
GestioERP documenta un modelo con datos aislados y maestros compartidos. Ese patrón puede servir para formular preguntas sobre clientes, productos o cuentas comunes, pero no decide por sí solo qué información debe compartir tu organización. Contrasta cada dato con el proceso, los permisos y las obligaciones aplicables.
Un usuario global necesita límites explícitos
Una persona puede ser responsable en una sociedad y tener solo consulta en otra. Al cambiar de ámbito debería ver claramente dónde está trabajando. Las acciones delicadas —crear documentos, aprobar, exportar o configurar— deben comprobar la organización activa.
AWS distingue el aislamiento entre organizaciones de la autenticación general. Que alguien haya iniciado sesión no demuestra que pueda acceder a cualquier organización del sistema.
Documenta estos límites con la matriz de roles y permisos. Así se distinguen rol, organización y alcance de registros.
Configurar una unidad es diferente de crear otra versión
Enumera qué puede variar: marca, textos, horarios, catálogo, responsables, reglas de aprobación, numeraciones e integraciones. Después separa datos configurables de funcionalidad. Un horario por sede puede ser un ajuste; un proceso completamente distinto puede necesitar desarrollo.
La documentación de AWS sobre arquitecturas multiinquilino muestra combinaciones de recursos compartidos y separados. El inventario de reglas sigue siendo necesario: si cada unidad recibe una copia de código que evoluciona por su cuenta, actualizar una mejora común se vuelve más difícil.
| Decisión | Común | Por organización | Por sede |
|---|---|---|---|
| Catálogo base | Productos | Condiciones fiscales | Disponibilidad local |
| Identidad | Diseño del sistema | Razón social | Dirección y contacto |
| Flujo | Estados principales | Regla de aprobación | Responsable operativo |
| Integraciones | Formato interno | ERP o contabilidad | Dispositivo o almacén |
Los informes consolidados y la salida también necesitan reglas
Sumar datos exige definiciones comunes. «Trabajo cerrado» puede significar completado por un técnico en una sede y validado por administración en otra. Un gráfico agregado es engañoso si combina estados distintos. Define el indicador, su fecha de corte y el permiso para abrir el detalle.
Dirección podría ver totales globales sin que cada responsable local acceda a expedientes ajenos. Comprueba filtros, descargas y enlaces desde el agregado al registro. También define qué ocurre cuando una unidad abandona el sistema: extracción, propiedad de los datos, históricos compartidos y desactivación de usuarios.
Si la aplicación intercambia datos con CRM o ERP, acuerda qué sistema gobierna cada campo. La guía sobre integrar CRM y ERP con una fuente de verdad ayuda a evitar que la misma empresa tenga identificadores incompatibles en varios sistemas.
Pruebas de aceptación para evitar accesos cruzados
- 01
Crea ámbitos inequívocos
Usa dos organizaciones ficticias y registros con nombres claramente diferentes.
- 02
Prueba cada superficie
Comprueba listados, búsqueda, enlace directo, adjuntos, exportación e informes.
- 03
Prueba al usuario compartido
Asigna perfiles diferentes en cada organización y cambia de contexto varias veces.
- 04
Retira el acceso
Revoca una organización y comprueba una sesión abierta, enlaces guardados y descargas.
- 05
Cambia una configuración
Modifica un ajuste de sede y verifica que solo afecta al ámbito previsto.
La entrega debería incluir un esquema de organizaciones, una matriz de acceso, el inventario de configuración y las decisiones sobre datos compartidos. Son evidencias revisables; etiquetas como «multiempresa» o «aislamiento total» no bastan por sí solas.
Del mapa de unidades al alcance
Antes de pedir una estimación, dibuja las unidades, marca tres datos compartidos y tres separados e identifica a una persona que trabaja en más de un ámbito. Añade un informe global y una situación de salida. Ese ejercicio descubre gran parte de la complejidad real.
NAS Solutions desarrolla aplicaciones a medida. Este mapa permite valorar una solución multisede con reglas comprensibles. La arquitectura, el aislamiento y la operación concreta se definen según el proceso y los requisitos comprobados de cada proyecto.
Fuentes y referencias
Documentación oficial y referencias de mercado consultadas para verificar los puntos que cambian con el tiempo.
