La estrategia de organizaciones es una decisión del panorama

🌐 También en 28 idiomas

English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 5 de 6 del capítulo Entender los datos de la empresa, capítulo 4 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Dibuja el panorama de sistemas · Siguiente: El panorama de Steve Trucking

La pregunta que responde este módulo: ¿Una organización o varias, y dónde se ejecuta?

Cuando enseño a candidatos a CTA, les digo que la decisión más grande de un escenario llega en los primeros cinco o diez minutos: ¿con cuántas organizaciones de Salesforce estamos tratando? ¿Una gran organización? ¿Organizaciones regionales para Norteamérica, EMEA y APAC? ¿Organizaciones separadas para unidades de negocio separadas? ¿Una organización especial para un país con sus propias reglas? Y ligada directamente a ella: ¿dónde se ejecutan esas organizaciones?

No son detalles administrativos. Cambian dónde viven los datos, las integraciones, los informes, la identidad y cómo llega al sistema la gente de todo el mundo. Por eso trato la estrategia de organizaciones como una decisión del panorama, y por eso la tomo primero.

Empieza con una organización

Mi posición de partida es sencilla: empieza con una organización. No porque una organización sea siempre lo correcto, sino porque necesito una razón para agregar otra. Una organización me da un solo lugar para los datos de clientes compartidos, un solo modelo de seguridad, un solo lugar donde desplegar, un solo conjunto de integraciones, un solo lugar para los informes. Y una organización puede seguir sosteniendo distintas unidades de negocio, países, procesos, tipos de registro, aplicaciones, modelos de uso compartido y experiencias.

Así que no agrego una organización porque Europa haga las cosas un poco distinto, o una división tenga su propio proceso de ventas, o las unidades de negocio no se lleven bien. Son requisitos, no fronteras entre organizaciones. La pregunta es: ¿qué fuerza es lo bastante fuerte como para justificar otra organización?

Varias organizaciones tienen un costo

Divide una organización en tres (Norteamérica, Europa, Asia-Pacífico) y no habrás dibujado tres cajas ordenadas; habrás creado preguntas nuevas. ¿Dónde vive un cliente global? ¿Y si opera en dos regiones: dos copias, y cuál es su dueña? ¿Cómo hace alguien informes globales? ¿El ERP se integra con las tres, el almacén de datos recibe tres alimentaciones, el proveedor de identidad se conecta con las tres? ¿Desplegamos la misma funcionalidad tres veces y mantenemos alineados tres modelos de datos? Si un agente necesita una visión global de un cliente, ¿a qué organización le pregunta?

Vuelve al panorama del módulo 4. Una caja de Salesforce se convierte en tres, y hay que volver a dibujar cada flecha. Tener varias organizaciones no está mal. Nunca es gratis.

Busca fronteras reales

¿Qué puede justificar otra organización? Fronteras lo bastante reales como para dar forma a la arquitectura: residencia de datos, regulación, separación legal, modelos operativos de verdad distintos, una adquisición que todavía no ha convergido, una restricción de alojamiento regional, un gobierno muy distinto y, a veces, la escala o el aislamiento. La lista no está completa. La idea es distinguir “estos grupos son distintos” de “estos grupos necesitan una frontera de arquitectura”. El segundo listón está mucho más alto.

La geografía no es automáticamente una estrategia de organizaciones

“Operamos en 30 países, así que necesitamos 30 organizaciones”. No. La geografía importa cuando trae un requisito de arquitectura. Una empresa puede tener usuarios en todo el mundo sobre una arquitectura común. Así que no cuento países; pregunto qué viene con ellos. ¿Dónde pueden guardarse los datos? ¿Dónde pueden procesarse? ¿Hay límites para mover datos personales entre fronteras? ¿Promesas contractuales sobre la residencia? ¿Una región necesita un servicio o un alojamiento distinto de Salesforce? “Hay una oficina en Alemania” no basta por sí solo.

El alojamiento es parte del dibujo

Aquí la plataforma moderna hace el panorama más interesante. Hyperforce ejecuta Salesforce sobre infraestructura de nube pública en regiones de todo el mundo, lo que da a los clientes más opciones y control sobre dónde residen sus datos (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), en inglés). Así que cuando etiqueto una caja como “Salesforce, Europa”, esa ubicación puede importar.

Pero sé preciso. Elegir dónde vive una organización no es una promesa de que cada byte de cada servicio se quede ahí. Salesforce pide a sus clientes que revisen la documentación de confianza y cumplimiento de Hyperforce, incluidos los subencargados adicionales de los servicios que compran (misma fuente). Así que no digas “estamos en Hyperforce en el país X, así que todo se queda en el país X”. Sabe qué servicios estás usando realmente, y qué requisito estás cumpliendo. Y fíjate en lo que eliges: la región, no la nube que hay debajo. Hyperforce se ejecuta en AWS, con Google Cloud a partir de finales de 2026, y es Salesforce quien decide en qué proveedor está una organización; un cliente con una razón regulatoria documentada para evitar uno habla con su equipo de cuenta (misma fuente).

No hagas de abogado

Aquí también los arquitectos necesitan conocer su papel. Si alguien dice: “La ley de privacidad europea exige una organización separada”, no lo aceptaré a ciegas. Tampoco me nombraré abogado de la empresa para declarar que no es así. Preguntaré: ¿qué requisito concreto estamos cumpliendo? ¿Dónde se guardan los datos, dónde se procesan, la transferencia entre fronteras, quién puede acceder a ellos para dar soporte, un contrato, una política interna? Luego trabajo con privacidad, seguridad, cumplimiento y el área legal para convertir ese requisito en arquitectura. No te inventes requisitos legales, y no los ignores. Tradúcelos.

Cuando Europa tiene su propia organización

Esta es una frontera que veo en escenarios reales. Una empresa tiene una fuerte presencia en EE. UU. y una fuerte presencia en Europa: dos grandes bases de clientes, dos operaciones de ventas y de servicio, y un programa europeo de privacidad construido alrededor del RGPD (GDPR). El RGPD no dice “necesitas una organización de Salesforce separada”. Fija reglas para los datos personales, incluido cuándo pueden transferirse fuera de la UE (RGPD, capítulo V (opens in a new tab)). Pero esta empresa, junto con sus equipos de privacidad y legal, decide que los datos personales de sus clientes europeos deben vivir en una organización alojada en Europa, gestionada por su equipo europeo, bajo su gobierno europeo. Es un requisito real, y es suyo, no mío.

Ahora “una gran organización global” ya no es una preferencia. Hay una frontera en el panorama, Salesforce AMER y Salesforce EMEA, y tengo que dibujarla. Y la segunda organización nunca es solo una caja más.

Click to enlarge

Dos organizaciones, AMER y EMEA. Lo ámbar es lo que agrega la segunda organización: no una caja más, sino otra vez cada flecha.

Vuelve a recorrer las flechas

Con más de una organización, vuelve a recorrer el panorama. ¿El ERP envía productos a cada organización? ¿Cada una devuelve pedidos? ¿Dónde se mantienen los clientes como datos maestros, y pueden sus datos cruzar regiones? ¿La capa de integración es global o regional? ¿Qué proveedor de identidad inicia la sesión de qué usuarios? ¿Adónde van los datos analíticos?

Tres lugares muestran el costo más rápido:

Los informes. El director general quiere un pipeline global. En una organización, eso es un informe de Salesforce. En tres, es un problema de informes de la empresa: ¿replicar, enviar al almacén de datos, federar? ¿Qué tan actual tiene que estar, y las organizaciones definen siquiera “pipeline” de la misma manera? Dónde vive la analítica depende de dónde viven los datos, y si separas a propósito los datos operativos, tienes que diseñar cómo vuelve a juntarse el conocimiento.

Los datos maestros. Un cliente global compra en EE. UU., Alemania y Japón. Tres organizaciones, así que probablemente tres cuentas. ¿Cómo sabes que son la misma empresa? ¿Cuál es el identificador global, y quién es su dueño? Si una región cambia la dirección, ¿debería propagarse? ¿Qué atributos son globales y cuáles regionales? La estrategia de organizaciones no resuelve la identidad; cambia el problema de identidad. Eso es el capítulo 6.

La integración. Una organización: Salesforce, la capa de integración, el ERP. Tres organizaciones: tres conexiones a la capa de integración, quizá una con su propio alojamiento y su propia conectividad, algunos flujos compartidos, otros regionales, algunos datos que pueden cruzar y otros que no. Hasta la red puede cambiar: si la empresa necesita conectividad privada dedicada hacia Hyperforce (en AWS, Salesforce recomienda AWS Direct Connect; misma FAQ de Hyperforce), cada organización y cada alojamiento del dibujo es otra conexión que planificar. Dónde se ejecuta una organización puede cambiar cómo llega a ella el resto de la empresa.

Una organización o varias es una decisión que tomas ahora, al principio, en el panorama. Cómo comparten después los datos las organizaciones (Salesforce Connect entre organizaciones, integración entre ellas, Data 360) es la mecánica, y el capítulo 14, ¿Una organización o varias? (coming soon), lo cubre.

Si diseñas todo el modelo de datos y la arquitectura de integración y solo entonces oyes “por cierto, esto tienen que ser tres organizaciones”, no has hecho un pequeño ajuste. Has cambiado la arquitectura. Por eso la decisión va primero.

No dividas solo para que las cajas sean más pequeñas

Una organización grande se siente complicada: muchas unidades, objetos, usuarios, integraciones. Alguien dice: “¿No sería más limpio que cada uno tuviera su propia organización?”. El dibujo quizá quede más limpio. La empresa quizá no. Has cambiado complejidad interna por complejidad distribuida: sincronización, datos duplicados, identidad entre organizaciones, informes globales, varios procesos de lanzamiento, integraciones y automatización duplicadas, y el gobierno de todo eso. A veces sigue siendo el intercambio correcto. Pero separado no es lo mismo que simple.

Y una sola organización tampoco es gratis. El gobierno compartido importa más, los equipos pueden afectarse entre sí, las fronteras de seguridad necesitan un diseño cuidadoso, el modelo de datos tiene que servir a muchos grupos, los lanzamientos necesitan coordinación y las reglas regionales pueden restringir a todos. Así que no es “Steve dice siempre una organización”. Mi inclinación de partida es una organización; luego busco el requisito lo bastante fuerte como para sacarme de ahí.

Haz visible la decisión

Si la estrategia de organizaciones importa, no dibujes una nube genérica de Salesforce. Dibuja las organizaciones y etiquétalas (AMER, EMEA, lo que sea real), anota el requisito de alojamiento o de residencia detrás de cada una y recorre las conexiones. Otro arquitecto debería poder ver por qué existe cada frontera. Si no puedo explicar por qué hay tres cajas de Salesforce, no he terminado la decisión.

Steve Trucking tiene una organización, en EE. UU., y nada en su planteamiento pide otra. Pero ten presente este módulo para el proyecto final: una adquisición que llega con su propia organización es exactamente el tipo de frontera que pone a prueba estas preguntas.

Más allá del examen: lo que cambia la IA. Un agente puede hacer invisible para el usuario una frontera entre organizaciones. Por debajo, la arquitectura todavía tiene que decidir a qué organización o sistema puede preguntar el agente, qué datos pueden cruzar regiones y qué respuesta es la referencia. La IA puede esconder la complejidad en la experiencia; no elimina el gobierno ni la frontera.

Lo que decide aquí un arquitecto

• Si hay una razón de arquitectura genuina para más de una organización, en lugar de resolver las diferencias dentro de una.
• Dónde se ejecuta cada organización, y qué requisito de residencia, regulatorio, contractual o de negocio la pone ahí.
• Qué datos pueden cruzar las fronteras entre organizaciones y regiones, dónde son la referencia los datos maestros y cómo funciona la identidad global.
• Cómo cambian la integración, la identidad, la analítica y los informes cuando una caja de Salesforce se convierte en varias.
• Si el beneficio de la separación vale la arquitectura distribuida que crea.

Cuando leo un escenario, busco primero esta decisión: ¿una organización o varias, alojadas dónde y obligadas por qué? Responde eso, y el resto del panorama empieza a tomar forma.

Explora

• Ayuda de Salesforce, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (en inglés), consultado el 2026-10-14.
• EUR-Lex, Reglamento (UE) 2016/679, el Reglamento General de Protección de Datos (opens in a new tab), capítulo V (transferencias de datos personales a terceros países), consultado el 2026-10-14.