La decisión de Lidl de detener la implementación de SAP Hana por el aumento de los costes puede ser una primera señal de los problemas que implicará la actualización a S/4 Hana.
Aunque se ha revelado muy poco sobre los motivos por los que Lidl ha decidido desechar SAP, lo que se desprende de los informes sobre el proyecto del minorista es que lo desconectó debido al aumento de los costes.
Cuando Computer Weekly empezó a ver fracasos de proyectos SAP a finales de la década de los 90, el coste de la implementación fue uno de los factores que contribuyeron. El problema era que SAP se vendía como un conjunto de procesos empresariales preempaquetados, que encapsulaban los procesos empresariales de algunas de las empresas más grandes del mundo, pero a menudo éstos no coincidían con la forma en que las empresas que intentaban implementar SAP veían sus procesos empresariales. Esto significaba que a menudo era necesario personalizarlos.
Dos décadas después, los expertos están de acuerdo en que se debe evitar personalizar SAP porque el coste y la complejidad aumentarán rápidamente. Esto es tan cierto hoy en día para las empresas que se embarcan en una implementación de SAP S/4 Hana como lo fue cuando implementaron SAP R/3 en la década de 1990.
En 2025, SAP terminará oficialmente el soporte para ECC6, el componente central de recursos empresariales (ERP) de su producto. Desde la perspectiva de SAP, esto da a las empresas menos de seis años para implementar S/4 Hana.
Las empresas que ejecutan sistemas SAP implementados en las últimas dos décadas tienen que tomar una decisión difícil sobre cómo su código personalizado SAP existente debe ser redesarrollado para S/4 Hana.
Hay un debate en curso sobre cómo los sistemas existentes pueden ser reelaborados para S/4 Hana, pero el consenso general es que S/4 Hana significa implementar un sistema completamente ERP.
Identificar los procesos de negocio existentes
Como tal, las empresas necesitan averiguar cuáles son sus procesos de negocio existentes, cuánto está codificado en SAP, cuánto de la personalización en la implementación original es ahora parte de S/4 Hana estándar, y si es realmente un imperativo de negocio implementar el antiguo código personalizado en la plataforma. Esto es especialmente cierto si un proceso de negocio que se codificó hace dos décadas ya no se utiliza, o se ha adaptado pero el código personalizado no se ha actualizado.
Según el whitepaper Optimising business processes for success del analista IDC: «Los procesos mal coordinados que no se ajustan a las necesidades del negocio y que socavan los sistemas de producción cuando se despliegan no son simplemente costosos: pueden obstaculizar el posicionamiento corporativo eficaz y la capacidad de respuesta a las presiones competitivas y las demandas globales que cambian rápidamente.»
En el libro blanco, IDC recomendó establecer estrategias que abarquen el cambio cultural, las estructuras organizativas (aprovechando los centros de excelencia existentes, las oficinas de gestión de proyectos o programas, o los DevOps -o formándolos-), los procesos para la calidad de los procesos de negocio, y la evaluación y adopción de soluciones de automatización adecuadas para ayudar a crear aplicaciones relevantes, adaptables y centradas en el negocio.
Cumplir con las demandas del negocio
Según la consultora SAP Panaya, para obtener el máximo valor de una inversión en SAP S/4 Hana, el departamento de TI tendrá que cumplir con las demandas del negocio lo más rápido posible sin interrumpirlo. Con varios caminos de proyecto a tomar – migración, implementación, greenfield, etc – los equipos de TI se embarcan en proyectos de 12 a 18 meses, escribió la compañía en un reciente whitepaper.
La actualización técnica para SAP S/4 Hana puede ser tan rápida como tres meses. Sin embargo, para cumplir con los nuevos estándares de SAP S/4 Hana, Panaya dijo que los nueve a 15 meses restantes deben centrarse en los cambios de los procesos de negocio, la personalización y la garantía de calidad.
De hecho, SAP S/4 Hana introduce muchos cambios en áreas como la tecnología, los procesos de negocio y las interfaces de usuario. Según Panaya, estos cambios afectarán tanto a la forma de trabajar de los equipos de TI como a la forma de personalizar el sistema SAP.
A medida que cambian los modelos operativos y los procesos de TI, Panaya advirtió que las solicitudes de cambio, los requisitos y los procesos de gestión de pruebas y lanzamientos podrían suponer una transición difícil para las TI de las empresas.
«Para muchas organizaciones, la implementación de estos cambios en un modo de entrega en cascada llevará demasiado tiempo, lo que afectará al ROI de la solución . Estos cambios tendrán que ser implementados de forma incremental, entregando diferentes solicitudes de cambio en cada ciclo utilizando DevOps y entrega continua», señala el whitepaper de Panaya.
Asumir la responsabilidad
Stuart Browne, director general de la consultora independiente SAP Resulting, dijo que un problema común que encuentra es que las empresas a menudo asumen erróneamente que es el integrador de sistemas el que tiene la responsabilidad de conseguir la implementación del ERP correctamente, cuando en última instancia es responsabilidad del cliente.
Browne dijo que uno de los desafíos técnicos para las empresas es que S/4Hana aún no está completo. «Es un producto inacabado y no simplifica la suite de productos SAP. Adoptar S/4 Hana ahora sí simplifica algunas funcionalidades, pero no todas»
Como todavía es un trabajo en progreso, Browne dijo que faltaban herramientas y personas con las habilidades adecuadas para implementar S/4 Hana. Esto se agrava por el hecho de que las personas que entienden la implementación del ERP SAP ECC6 existente y tienen 20 años de experiencia con él se dirigen hacia la jubilación.
«Hay una fuerza de trabajo envejecida y acomodada que se acerca a la jubilación. Todos tienden a tener entre 40 y 50 años». Dijo que la gente más joven generalmente está haciendo «cosas más frías» en lugar de implementar SAP, y hay una inflación salarial del 8% en la India, lo que significa que la subcontratación de las habilidades de SAP es costosa.
Diferir la actualización
Rimini es una de las empresas que ha construido un negocio en torno al apoyo a los sistemas SAP más antiguos. La idea detrás de tomar un contrato de mantenimiento de terceros es que permite a la empresa reducir su cuota de mantenimiento continuo mientras retrasa la migración al producto más nuevo, en este caso SAP S/4 Hana.
Hari Candadai, vicepresidente del grupo de marketing y estrategia de productos en Rimini Street, dijo que era «muy revelador» que Lidl tuviera que reevaluar y personalizar tantos procesos para hacer que el nuevo sistema SAP funcionara para su negocio.
«La clave es que todos los clientes empresariales que se planteen un cambio importante de plataforma SAP, incluida una posible reimplantación a S/4 Hana desde su sistema SAP actual, deben entender que es todo menos sencillo», dijo Candadai. «Si se equivoca, afectará gravemente a su cuenta de resultados. La verdadera pregunta es: ‘¿Cuál era el supuesto ROI en el lugar para considerar siquiera arrancar y reemplazar sus sistemas de registro de back office?»
Dado que el soporte para ECC6 continuará hasta 2025, las empresas no necesariamente tienen que comprar en S/4 Hana ahora mismo, especialmente si sienten que aún no es un producto completo.
Seis años es mucho tiempo, y dado que SAP S/4 Hana se considera una implementación importante, Browne dijo que había una oportunidad para que las empresas reevaluaran cómo debería funcionar el ERP principal dentro de la empresa y estudiaran la viabilidad de implementar alternativas como NetSuite o Microsoft Dynamics.
También está la cuestión de qué arquitectura de TI se necesitará en 2025 para apoyar lo que la empresa espera hacer en ese momento. Por ejemplo, aunque S/4 Hana proporciona interfaces de programación de aplicaciones (API), Browne afirmó que éstas eran demasiado restrictivas, especialmente si la empresa quiere abrir sus interfaces de programación de aplicaciones y participar en una economía de API, en la que las empresas realizan transacciones utilizando un enfoque nativo de la nube basado en microservicios ligeros.
Y si bien es cierto que SAP se vendió en el pasado como una forma de encapsular procesos empresariales de primera clase, las empresas tradicionales corren el riesgo de verse alteradas porque un ERP inventado en la década de 1990 no está a la altura de las innovadoras cadenas de suministro del siglo XXI.