El concepto de public cloud no es una moda pasajera. Este modelo permite olvidarse para siempre de los dolores de cabeza vinculados al hardware, ganar confianza sin perder el control total sobre el landscape SAP operando en AWS, Microsoft Azure o Google Cloud Platform, y reducir costes y aumentar la flexibilidad, adaptada a las nuevas tecnologías SAP. Vamos a ofrecer algunas pautas que es conveniente seguir en este proceso, basadas en nuestra experiencia.
Cuando hablamos de cloud públicas, los tres candidatos más importantes cuentan con presencia global y son tecnológicamente muy avanzados: disponen de servicios SaaS punteros, sistemas de monetización precisa, economías de escala, están certificados para SAP/HANA, cuentan con dashboards de aplicación unificados, están ajustados al RGPD, poseen centros de datos de alta seguridad, protección del dato y control de accesos multicapa, ofrecen redundancia multirregión y zona, potencia de cálculo on demand, descuentos en los pagos upfront con commitment a 1-3 años, así como despliegues casi instantáneos.
En definitiva, la elección de cualquiera de las tres opciones será acertada. Quizás, tener ya servicios en alguno de ellos (correo corporativo o file storage), podría acercar más a uno u otro aunque, simplemente, otra opción es disfrutar de los tres combinando los servicios según cada caso.
Por dónde empezamos
“Lo mejor es enemigo de lo bueno”. La solución adecuada pasa por encontrar el camino óptimo y estratégico, que se adapte a las necesidades de cada momento. Para ello, en cada caso hay que realizar el business case y encajar las piezas del puzle entre las diferentes nubes (privada, pública, SaaS o híbrida) en función del hardware propietario, del renting, el mantenimiento técnico y funcional, y las licencias de las que se dispone.
Migrar todo el landscape de SAP al public cloud de una tacada no tiene por qué ser un requisito. En ocasiones, quizás se requieran sistemas industriales ubicados on-premise o tal vez sea necesario decomisionar algunos sistemas en favor de un SaaS, como sucede con C4S, C4C, SAC o SSFF, entre muchos otros. Otra alternativa es obtener lo mejor de diferentes mundos: tener SAP ERP en una nube pública, la gestión del talento en Success Factors, el reporting en Cloud for Analytics y el sistema de formulación secreta —en caso de la industria farmacéutica— en on-premise. Aun así, esta fotografía puede ir variando en función de las circunstancias y de la confianza que otorgue cada solución.
De hecho, es posible empezar por sistemas no críticos y de bajo coste de mantenimiento, coger confianza con el proceso de migración y operación posterior, y planificar con detalle —y en convergencia con los proyectos evolutivos y correctivos de negocio— para migrar cada sistema o bloques de sistemas en diferentes períodos.
Migrar todo el landscape de SAP a cloud de una tacada no tiene por qué ser un requisito
Pasos que se han de seguir
Lo primero que hay que hacer es analizar la situación actual (AS-IS) para conocer dónde estamos y el estado en cuanto a mantenimiento, evolución y soporte. A partir de ahí, hay que definir conjuntamente una foto de hacia dónde queremos llegar (TO-BE), que sea factible en esfuerzo, tiempo, coste y riesgo, siempre según las necesidades de Negocio.
Es posible que solo sea necesario hacer una migración técnica para solventar problemas de obsolescencia de hardware, o quizá se desea obtener un boost de rendimiento para todos los departamentos funcionales involucrados con una migración a SAP HANA. Quizás dicha migración implique un cambio de release que obligue a ajustar y validar los circuitos funcionales y procesos de negocio de Finanzas, Logística, HCM, Public Sector, CRM, MDM y ABAP… O quizás se requieran aceleradores que permitan mover sistemas en el AS-IS hacia un TO-BE en near zero downtime para, por ejemplo, sistemas del sector hospitalario.
Es importante escoger la opción óptima para cada caso, aportando valor a Negocio y ponderando directamente, y proporcionalmente, los factores de esfuerzo, tiempo y coste factores que habrán de estar inversamente vinculados al riesgo.
Retos más importantes
Hay varios requisitos para poner en marcha esta adopción de la nube pública que van a permitir salvar diversos retos cuya existencia hemos constatado a partir de nuestra experiencia.
- Partnership & experience. Es importante disponer de acuerdos con AWS, Azure o GCP certificado, como proveedor e integrador de confianza.
- Fast short calendar onboarding. Las migraciones a cloud no pueden eternizarse provocando colisiones con otros proyectos en marcha, deben establecerse calendarios de migración rápidos, sólidos y factibles.
- Zero impact & noise strategy. Acordar la estrategia de migración, que no debe impactar en los proyectos en curso ni generar ruido entre los distintos departamentos funcionales. Hay que ganarse a los stakeholders con la venta interna. La elaboración y ejecución del plan de pruebas es vital para minimizar los riesgos en el GoLive!.
- SaaS certified tools. Los aceleradores certificados por SAP, como por ejemplo Panaya para el impact analysis, o Automated Testing, SAP Solution Manager o SNP T-Bone para transformaciones complejas near zero downtime, o herramientas automatizadas de ahorro de costes en cloud, pueden ser el quick win necesario para la migración.
- International OaaS customer support. Además de migrar a cloud los sistemas, sin pérdida de control, estos deben ser operados en la nube (operation as a service) atendiendo a particularidades como la existencia de servicios near-shore u offshore,
lo que hará aconsejable contar con un OaaS a nivel internacional con mantenimiento 24×7×365 y SLA que cubran el servicio de IM y AM en todas sus dimensiones. - One shoot low investment & cloud cost advisor. La IaaS implica economías de escala y monetización exhaustiva, que debe obtenerse en el business case partiendo del AS-IS fijando el escenario TO-BE. La migración simple 1:1 no es la óptima en todos los casos. Una optimización de recursos en el TO-BE, quizás mediante SAP HANA Multitenant (MDC), puede proporcionar un ahorro de costes importante. Los pagos upfront con sistemas convertibles y los costes vinculados mes a mes son claves al inicio y durante el proyecto.
- Methodology like a factory. Una cosa es migrar cuatro servidores y otra muy distinta es migrar cuarenta. Se debe industrializar el proceso, migrar like a factory, habiendo obtenido una metodología de migración y revisión de métricas y KPI en operación.
- Broadband scope advice. Es posible aprovechar la migración para adaptar la nueva foto TO-BE al roadmap oficial de SAP. Quizás, dejar el TO-BE en public cloud, al igual que el AS-IS, no aporte valor y sea mejor combinarlo con una conversión a Unicode o una migración heterogénea a HANA que acerque un poco más al S4 antes del 2025 como movimiento estratégico, o quedarse simplemente en HANA como movimiento táctico.
El verdadero valor en la migración técnica
La optimización del escenario TO-BE, proporcionado a su vez por la estrategia de transformación, es la que permitirá disponer de un contexto —en el aplicativo SAP y en la capa de base de datos—escalable, flexible y, sobre todo, con un ahorro en costes de infraestructura (IaaS) y en operación (OaaS). Es importante que la arquitectura SAP HANA en cloud pública esté certificada y soporte el crecimiento orgánico e inorgánico. Este es el verdadero valor que puede aportar un partner certificado y con experiencia: una arquitectura HANA multitenant para escalar todo el landscape SAP agrupado de manera lógica, por potencia de procesamiento y volumetría de base de datos en instancias virtuales certificadas.
Finalmente, el calendario de migración global, ordenado por bloques de migración en GoLives! combinados según criticidad de aplicativos. Al inicio, las soluciones analíticas son las preferidas teniendo en cuenta el ROI que se consigue en velocidad de reporting al terminar la migración. Las transaccionales, como el ERP de negocio, se dejan más bien para el final, cuando ya se cuente con experiencia con los sistemas migrados.
