Lecciones aprendidas en la primera implantación de S4 HANA Public Cloud en España

El proyecto comenzó en septiembre de 2017 con el cierre de contratos y licencias, lo que nos permitió disponer de la conexión con el sistema Starter dos semanas más tarde, tiempo que empleamos en la preparación del proyecto y generación del equipo de trabajo. La concepción tradicional de layout de tres capas, desarrollo, calidad y producción desaparece, y queda sustituido por un sistema de calidad que hace las veces de sistema de desarrollo, un sistema de producción y un sistema de sandbox que es el Starter. Para que se pueda optar a disponer de cada uno de ellos hace falta ir superando los QC (hitos de proyecto en los que es necesario proporcionar determinada información a SAP) acordes a la definición de la metodología a partir de los cuales SAP genera cada uno de los entornos necesarios para el proyecto. Es importante tener en cuenta que SAP tan solo permite tener dos sistemas activos simultáneamente, por lo que la recepción del sistema de producción significa la desconexión del sistema Starter.

Para preparar al equipo de proyecto realizamos una serie de sesiones de formación y de intercambio de conocimientos con nuestro equipo de implantación de UK que disponía de experiencia previa en la implementación interna de Birchman, las cuales resultaron ser muy útiles para poder encarar el proyecto con éxito, dado que permitieron gestionar de manera eficiente situaciones que ya se habían encarado anteriormente. Igualmente permitió profundizar en la metodología de proyecto, ya que acorde a la nueva filosofía de implementación, SAP ha desarrollado una metodología específica denominada Actívate para poder ejecutar este tipo de proyectos.

Desarrollar una metodología específica tiene mucho sentido, ya que se trata de un producto diferente y por lo tanto implica un tratamiento distinto y específico a lo largo de su ciclo de vida. Este hecho es uno de los factores a tener más en cuenta ya que no es posible encarar uno de estos proyectos pensando que se trata de un proyecto normal de HANA S4 como sería una instalación on prem, solo que instalada en nube. La concepción, funcionalidad y planteamiento del proyecto es diferente, y eso es algo que debe tenerse en cuenta incluso desde el propio proceso de venta.

El equipo de proyecto se creó con perfiles mixtos, con consultores expertos en SAP en implantaciones tradicionales de R3 y S4 on prem, pero complementados con otros perfiles con menos experiencia. A la hora de evaluar el rendimiento del equipo se ha puesto de manifiesto que la mayor contribución de los perfiles senior se ha realizado en temas relacionados con el conocimiento del proceso de negocio o con la experiencia adquirida en la gestión del cambio más que con el conocimiento del producto en sí, lo cual, dada la naturaleza del producto, tiene mucho sentido. La conclusión evidente es que el perfil de consultor para un producto cloud como HANA es diferente del perfil necesario para un proyecto tradicional, mucho más orientado a la gestión del cambio y al acompañamiento del cliente en el proceso de transformación empresarial.

La primera tarea del proyecto, una vez conseguido el acceso al sistema fue la de generar los usuarios de proyecto. Esto se hace ahora mediante la utilización de un servicio Cloud denominado SAP Cloud Platform Identity. Este servicio está relacionado con las características de seguridad de la plataforma, utilizando single sign on mediante el estándar abierto SAML 2.0, que puede ser integrado con un directorio activo ya previamente existente. También tiene posibilidad de integración mediante APIs. Sirve para integrar las aplicaciones del ecosistema S4 HANA Cloud, como Hybris o Sucess factors y por supuesto s4HANA. Al ser un código abierto permite también la integración con aplicaciones de terceros o con redes sociales. La seguridad de acceso es una de las características esenciales de un producto en cloud, y ha sido resuelta en nuestra opinión de forma muy satisfactoria por SAP.

Una de las novedades del producto y también de la metodología de implantación es que la fase tradicional de diseño desaparece como tal y queda sustituida por la tarea denominada ‘Fit to standard’. En esta fase se presentan los procesos tal y como están concebidos en el sistema a los usuarios y se detectan los posibles GAPS que pudieran existir. Estos GAPS deben ser cubiertos mediante el concepto de extensibilidad en el sistema.

SAP ha dividido la extensibilidad en dos categorías: La extensibilidad in-App que se realiza dentro del propio sistema y la extensibilidad Side to side, que necesita de la plataforma SCP para poder desarrollarla. En nuestro caso, el grado de cobertura de procesos estándar ha sido prácticamente del 100 por 100, por lo que tan solo han sido necesario un uso menor de las capacidades de extensibilidad.

Durante la fase de Fit to Standard también se define la configuración a realizar mediante la utilización de procesos preparametrizados que son públicos y que pueden consultarse libremente en https://rapid.sap.com/bp/# . Estos procesos incluyen tanto la definición del proceso y el flujo del mismo como los scripts de test, por lo que pueden ser utilizados por consultores no excesivamente expertos en la herramienta, pero si con conocimiento del flujo de negocio correspondiente.

Una vez definida las necesidades de adaptación, el sistema de configuración es guiado, lo que permite un desarrollo mucho más rápido, y se divide en dos niveles: la parametrización básica, que es realizada directamente por los consultores y la parametrización experta, que realiza SAP a partir de formularios en Excel que rellena el equipo de proyecto.

Toda la ejecución de pruebas está también preparametrizada, permitiendo que sean los mismos usuarios finales, con soporte de los consultores quienes realicen de forma casi autónoma las UAT.

Finalmente, las cargas de datos se realizan utilizando una herramienta de carga diseñada a tal efecto y embebida en la solución, a partir de formatos de carga establecidos, lo que permite comenzar desde el principio del proyecto con las tareas de limpieza de datos.

En conclusión, las lecciones aprendidas tras esta primera implementación por nuestra parte son:

Ø La implantación de S4 HANA Cloud difiere profundamente de los proyectos de implementación tradicionales, ya desde el propio proceso comercial, por lo que es necesario entender la nueva filosofía desde el principio

Ø Cobra mucha mayor relevancia la gestión del cambio y el acompañamiento de los usuarios y equipo de proyecto a lo largo de la implementación. Todo el proceso de cambio que normalmente se realiza a lo largo de un proyecto de implantación que puede llegar a tardar un año, debe realizarse en tan solo las 15 o 20 semanas que dura la implementación típica de un proyecto cloud

Ø Es imprescindible mantener los procesos estándar de negocio: Es necesario comprender la tarea “Fit to Standard” en detalle, que es la base de la nueva filosofía.

Ø Una relación fluida con SAP es clave para el éxito del proyecto, así como una gestión diligente de las comunicaciones, dado tanto el tráfico tanto de solicitudes como de incidencia que se produce a lo largo de toda la implementación

Ø A nivel operativo, es crítico que la información facilitada a SAP en cada uno de los hitos del proyecto este comprobada y validada.

En Birchman esperamos que esta sea la primera de una serie de implantaciones exitosas en nuestro afán de ayudar a las empresas en sus procesos de Transformación Digital.