Una o varias organizaciones de Salesforce para la educación superior: lo que realmente importa

Si has pasado tiempo en un foro de Salesforce para educación superior, en un hilo de LinkedIn o en demasiadas llamadas de asesoría, te habrás encontrado con este debate: ¿tu institución debería usar una sola organización de Salesforce o varias? No faltan matrices de decisión y diagramas de referencia diseñados para ayudarte a encontrar una respuesta. El propio equipo de desarrollo de Salesforce ha escrito sobre las ventajas y desventajas desde los primeros días de la plataforma, y sigue siendo una de las preguntas más debatidas en los círculos de CRM de educación superior.

Esto es lo que ninguna de esas matrices de decisión destaca en negrita: elijas lo que elijas, la decisión en sí no determina si tu entorno de Salesforce realmente funcionará dentro de seis meses. Lo que lo determina es si alguien puede ver las diferencias entre tus entornos cuando administradores reales, consultores reales y correcciones de emergencia reales a las 2 a.m. empiezan a modificarlos.

Elige una sola organización. Elige múltiples organizaciones. Solo no elijas una opción y te desentiendas… ¡Ahí es cuando sale caro!

Argumentos a favor de una sola organización

Una sola organización compartida es la opción más sencilla de explicar a una junta directiva. Una única fuente oficial de datos implica:

• Informes unificados. Sin combinar datos de seis campus para responder "cuántos estudiantes solicitaron ingreso en este ciclo".
• Una sola capa de gobernanza. La seguridad, los estándares de flujo de trabajo y las reglas de validación se encuentran en un único lugar.
• Un alcance de auditoría más reducido. Cuando llegan los responsables de cumplimiento de FERPA o los auditores de SOC 2, hay una sola organización que mostrarles, no una docena.

Para una sola institución, o un sistema muy centralizado donde todos los campus realmente operan de la misma manera, una sola organización puede ser la decisión correcta.

Argumentos a favor de múltiples organizaciones

El modelo de múltiples organizaciones cambia esa simplicidad por autonomía. Para muchos sistemas estatales, la autonomía no es opcional: forma parte de sus bases fundacionales. Estas son algunas razones por las que los sistemas eligen esta opción:

• Autonomía por campus. El flujo de inscripción de un instituto de educación superior y el de una universidad de investigación de referencia no son iguales, ni deberían tener que serlo.
• Impacto de los fallos contenido. Una personalización defectuosa en un campus no interrumpe el procesamiento de ayuda financiera en todo el estado.
• Ritmo de lanzamientos independiente. El campus A puede publicar una corrección según su propio cronograma, sin esperar una ventana de cambios para todo el sistema.

Ninguna opción es incorrecta. Hay muchos sistemas bien gestionados en ambos lados, y por eso el debate nunca termina del todo.

Ambas opciones fallan de la misma manera

Esto es lo que omiten las matrices de decisión: una sola organización y múltiples organizaciones no resuelven problemas distintos. Cambian un tipo de fallo por otro.

El punto débil de una sola organización es que el impacto de los fallos se comparte. Una organización implica una configuración cada vez más enredada, y un cambio pensado para el flujo de trabajo del campus A puede afectar silenciosamente al del campus B, porque no hay una barrera entre ambos.

El punto débil de múltiples organizaciones es la divergencia. El aislamiento resuelve el problema del impacto compartido, pero el precio son organizaciones que evolucionan silenciosamente por separado, hasta que nadie del equipo puede explicar por qué los campus A y C reportan las cifras de inscripción de manera distinta, o por qué los conjuntos de permisos de un campus no se parecen en nada a los de otro.

La arquitectura no elimina el problema operativo. Solo determina con qué variante tendrás que convivir. En cualquier caso, necesitas poder ver lo que realmente sucede en tus entornos. De lo contrario, solo estás eligiendo entre dos formas distintas de perder el control de tu propia organización.

Lo que realmente hacen los sistemas estatales a gran escala

Si observas la arquitectura de los sistemas estatales reales, verás múltiples organizaciones constantemente. No porque cada comité de planificación elija ese modelo en abstracto, sino porque la escala lo vuelve casi inevitable.

El sistema de institutos de educación superior de Virginia utiliza una arquitectura coordinada de nodo central y nodos periféricos que conecta 19 organizaciones de Salesforce en 23 instituciones de educación superior que operan de forma independiente. El sistema de institutos de educación superior de California abarca 115 instituciones y es el más grande de su tipo en el país. A esa escala, una sola organización compartida que intenta atender los flujos de trabajo de todos los campus empieza a ceder bajo su propio peso, y los sistemas terminan adoptando alguna variante de múltiples organizaciones casi por defecto.

Para muchos equipos de TI de educación superior, este no es un debate hipotético sobre arquitectura. Es el entorno en el que ya trabajan. La verdadera pregunta no es si deben tener múltiples organizaciones, sino si alguien puede realmente llevar un registro de sus diferencias.

La verdadera lista de verificación (sin importar qué opción elijas)

Sea cual sea el rumbo de tu sistema, hazte estas tres preguntas antes de definir la arquitectura, no seis meses después:

1. Visibilidad: ¿Puedes comparar, lado a lado, las diferencias reales entre dos de tus organizaciones antes de implementar cualquier cambio?
2. Seguimiento: ¿Cada cambio se registra automáticamente o queda en un hilo de Slack y en la memoria de un administrador?
3. Una forma rápida de deshacer: Cuando una implementación salga mal, porque tarde o temprano pasará, ¿podrás revertirla con un clic o te tomará todo el fin de semana?

Los sistemas de una sola organización necesitan esto para evitar que un entorno compartido se convierta en una maraña que nadie pueda modificar con seguridad. Los sistemas de múltiples organizaciones lo necesitan para evitar que una docena de campus termine con una docena de versiones distintas y no documentadas de lo que se considera "normal". En ambos casos, la lista de verificación es la misma. Solo cambia la cantidad de entornos a los que la aplicas.

Para ver cómo se ve esto en la práctica cotidiana dentro de una sola organización, Salesforce para operaciones académicas explica en detalle la mecánica de los despliegues.

El problema del día 2: seis meses después de decidir

Este es el escenario que nunca aparece en la propuesta de arquitectura: se toma la decisión, se plasma en un diagrama dentro de una presentación, todos asienten y el proyecto termina. Un año después, la mitad de quienes estuvieron en esa reunión ya se fueron, se abre un nuevo campus regional y nadie del personal actual puede explicar por qué se definió así el estándar. El nuevo campus simplemente hace las cosas a su manera y las divergencias empiezan de nuevo.

Decidir cuántas organizaciones usar requiere una reunión. Mantenerlas sincronizadas es un trabajo permanente. Sea cual sea la arquitectura que elijas, diseña para ese trabajo, no para la reunión, porque la persona que tomó esa decisión (sí, sabemos que probablemente ya se fue a otro sistema educativo) no es quien lidia con las consecuencias en el tercer año.

Sea cual sea tu elección

Elegir una o varias organizaciones no es realmente una cuestión de estar en lo correcto o no: se trata de qué concesiones puede manejar tu sistema educativo. Lo que realmente determina si cualquiera de las dos opciones funciona es algo rutinario, poco vistoso y que rara vez tiene su propia diapositiva en la solicitud de propuestas: visibilidad de las diferencias, seguimiento automático de cambios y una forma rápida de volver atrás cuando algo falla.

Implementa eso y el debate sobre cuántas organizaciones usar deja de ser existencial. Es solo una decisión de arquitectura, no una apuesta de la que dependa la estabilidad de todo tu sistema.

Deja de tratar tu estrategia de organizaciones como una decisión que se toma una sola vez y tu proceso de sincronización como algo secundario.

Agenda una demo de 15 minutos

Preguntas frecuentes

¿Cuántas organizaciones de Salesforce debería tener un sistema universitario estatal?

No hay una única cantidad correcta. Algunos sistemas estatales usan una organización compartida con particiones por campus; otros usan un modelo de núcleo y satélites con una docena o más de organizaciones conectadas, una por campus o región. La propia guía de arquitectura de Salesforce ha evaluado este equilibrio desde los primeros días de la plataforma, y la respuesta adecuada sigue dependiendo de cuánta autonomía local necesita cada campus frente a cuánto debe mantenerse estandarizado. Más importante que la cantidad es tener visibilidad de todas las organizaciones que termines usando, para que los campus no se distancien entre sí con el tiempo sin que nadie lo note.

¿Qué es la arquitectura centralizada con organizaciones satélite de Salesforce en la educación superior?

El modelo de núcleo y satélites conecta una organización central, a menudo administrada por la oficina central del sistema educativo, con varias organizaciones satélite de los campus. Cada campus mantiene parte de su configuración local, mientras que los objetos principales, los informes y los ajustes de cumplimiento se mantienen uniformes en todo el sistema. Es común en los sistemas estatales de universidades e instituciones de educación superior de ciclo corto que buscan equilibrar la autonomía de los campus con los informes a nivel estatal, aunque, como señaló un estratega de CRM para educación superior, es un modelo al que los sistemas educativos aspiran con más frecuencia de la que logran llevarlo a la práctica.

¿Puedes pasar de una sola organización a múltiples organizaciones más adelante, o viceversa?

Sí, pero es un proyecto de migración, no un cambio de ajustes. Se parecerá más a una nueva implementación que a una actualización de configuración. Precisamente por eso vale la pena contar con herramientas de visibilidad y sincronización sin importar con qué arquitectura empieces, en lugar de tratar la decisión inicial como algo permanente o que se puede revertir sin costo.