Audiencia Objetivo:

Este blog es relevante para clientes y consultores que están implementando SuccessFactors para un cliente global donde están planeando implementar la solución en varias fases y tienen una configuración de paisaje compleja.

Caso de Uso:

Tenemos un cliente global que está planeando implementar módulos de SuccessFactors en su organización pero desea implementarlos por fases por países o regiones en su organización. Este es un requisito común cuando se trata de clientes globales grandes que tienden a poner en marcha la solución comenzando por países pequeños donde tienen una base de usuarios reducida, se sienten seguros con la solución que satisface sus requisitos y luego la implementan en otros países donde tienen una base de usuarios sustancial. También puede darse el caso de que deseen implementar la solución por módulos y regiones, puede haber múltiples combinaciones en cómo los clientes desean implementar la solución basada en los módulos de SF y las regiones donde hacen negocios.

Cuando los clientes adquieren SuccessFactors generalmente obtienen 3 instancias dependiendo de su contrato. Se les proporciona 1 instancia de Producción y 2 instancias de Prueba/Desarrollo, un total de 3 instancias. Necesitamos entender que SuccessFactors tiene dos tipos de entornos donde estas instancias pueden ser provistas, son Entorno de Producción y Entorno de Vista Previa. La diferencia entre estos dos entornos es que el entorno de Vista Previa siempre recibirá la actualización semestral aproximadamente 4 semanas antes que el entorno de Producción. Esto se hace para que los clientes puedan probar las nuevas funciones y ajustarse a cualquier característica que afecte su implementación antes de que la nueva versión llegue a su entorno de producción.

En una implementación grande, generalmente 3 instancias pueden no ser suficientes durante la fase de implementación, y hemos visto que los clientes tienden a adquirir instancias adicionales por una tarifa durante la implementación por múltiples razones. A continuación, discutiré un caso de estudio donde un cliente podría haber adquirido 2 o más instancias adicionales además de las 3 existentes. Dado que el entorno de vista previa está un mes por delante cada medio año, hay 2 meses en un año en los que los dos entornos, Producción y Vista Previa, no están en la misma versión, por lo que recomendamos no programar actualizaciones durante estos 2 meses del año, también puede darse una situación en la que no se pueda mover la configuración durante este período. Por lo tanto, se recomienda mantener las instancias de desarrollo y prueba en el entorno de Producción durante la fase de implementación. Lo primero sería crear un diagrama de inventario que muestre cuántas instancias tiene el cliente y qué módulos tiene cada una de estas instancias.

Inventario de Instancias:

Es bueno tener un diagrama de inventario de instancias para que el equipo del proyecto sepa qué instancias hay y para qué se utilizan. El equipo del proyecto puede mantener más información en el diagrama según su requerimiento.

Inventario de Instancias

Módulos Implementados en cada Instancia:

Módulos Implementados en cada Instancia

Tener al menos una instancia en el entorno de Vista Previa para poder probar las nuevas funciones en cuanto se lanzan durante las actualizaciones trimestrales. Paralelamente, el cliente puede optar por tener su instancia de Desarrollo en Vista Previa para desarrollarla en la última versión. Puede programar una actualización desde una instancia de Prueba cuando ambas instancias estén en la misma versión.

Puede considerarse una instancia que se utiliza como instancia maestra/dorada durante la implementación que solo tiene configuración y datos de prueba, esto puede usarse para actualizaciones cuando se necesite establecer una instancia con una línea base de configuraciones. Por ejemplo, si algunos módulos ya se han implementado y se están agregando otros módulos al entorno de producción existente.

Los ejemplos anteriores son para fines de discusión, el cliente/el socio de implementación puede usar esto como una guía para crear un diagrama de paisaje y flujo de configuración/datos entre instancias para que en cualquier momento sepan qué está implementado en cada instancia y cómo se mueve la configuración a producción cuando se desarrolla/configura. A continuación se muestra un ejemplo de mi experiencia de implementación de cómo configuramos el diagrama de flujo de configuración.

Diagrama de Flujo de Configuración: