SAP 2027 visto desde Marruecos: una fecha de decisión antes que una fecha de migración.

Todo el mundo conoce el plazo. SAP ha anunciado el fin del mantenimiento estándar de ECC para finales de 2027, con una extensión de pago posible más allá para quienes la elijan. Sobre el papel, queda tiempo. En la práctica, una transformación del núcleo de gestión se define, se arbitra, se contractualiza y luego se ejecuta, y cada una de esas etapas se cuenta en trimestres. Quienes razonan en términos de fecha de fin de mantenimiento ya llevan retraso. Quienes razonan en términos de fecha de lanzamiento de su programa conservan el control del calendario, del presupuesto y de la elección de sus socios.

Por qué 2027 se lee de otra manera desde Casablanca.

Las empresas marroquíes y africanas comparten con las europeas la misma limitación técnica. No comparten ni el mismo punto de partida ni el mismo entorno. Tres diferencias pesan en la decisión.

• Paisajes a menudo más jóvenes, pero más heterogéneos. Muchos sistemas ECC de la región se desplegaron por olas, filial tras filial, a veces por integradores sucesivos. El resultado es un núcleo menos antiguo que en Europa, pero menos armonizado: varios modelos de procesos conviven bajo un mismo logotipo.
• Exigencias locales que no se negocian. Fiscalidad y facturación electrónica en evolución, plan contable, obligaciones declarativas, protección de los datos personales, particularidades de la nómina o de las aduanas según los países: un programa que las trata al final del recorrido las paga muy caras.
• Un mercado de competencias más estrecho. A medida que se acerca el plazo, los perfiles S/4HANA escasean en todas partes. En la región, donde la cantera es más pequeña, los rezagados negociarán su programa en las peores condiciones de disponibilidad.

Estas diferencias no hacen la decisión más difícil. La hacen más urgente, y más local: un escenario copiado de un grupo europeo sin pasarlo por el filtro de su realidad es un escenario que fracasará en el primer obstáculo regulatorio.

Tres escenarios, ninguna doctrina.

El debate público suele oponer la conversión «rápida y sin riesgo» a la nueva implementación «ambiciosa pero interminable». El terreno es menos tajante. Existen tres familias de trayectorias, y la buena elección se deduce de su situación actual, no de una convicción de fabricante o de integrador.

La conversión

Convertir el sistema existente preserva el histórico, los procesos y los desarrollos. Es su fuerza, y su límite. Conviene a las empresas cuyo núcleo ECC se ha mantenido sano: procesos armonizados, desarrollos específicos controlados, datos limpios. Convertir un sistema desordenado equivale a mudar las cajas sin abrirlas: el desorden llega intacto a la nueva casa, donde cuesta más caro mantenerlo.

La nueva implementación

Partir de un sistema nuevo permite adoptar el estándar S/4HANA, purgar años de desarrollos específicos y reconstruir los procesos sobre una base limpia. Es el camino más transformador y, por tanto, el más exigente: supone que la empresa acepte cambiar sus maneras de hacer tanto como su herramienta. Para los grupos de la región que quieren por fin unificar sus filiales en un modelo común, suele ser la ocasión que no hay que dejar pasar. A condición de no llevar un greenfield como una conversión disfrazada, donde cada desviación respecto al pasado se renegocia línea a línea.

La transición selectiva

Entre ambas, los enfoques selectivos permiten cribar: conservar el histórico y los procesos que tienen valor, rehacer el resto. Para los grupos multipaís con paisajes heterogéneos, donde no existe una respuesta única, es con frecuencia la vía pertinente. Es también la más exigente en arquitectura, y la que menos perdona la improvisación.

El escenario no se elige en un catálogo. Se deduce de un diagnóstico honesto de sus procesos, de sus desarrollos específicos, de sus datos y de su capacidad de absorción.

RISE, cloud público: leer las ofertas con los ojos del comprador.

La cuestión del objetivo se acompaña hoy de una cuestión de oferta comercial. RISE with SAP agrupa licencia, infraestructura y servicios en una suscripción, en cloud privado. El cloud público, con GROW, impone el estándar y un ritmo de actualizaciones dictado por el fabricante. Estas ofertas no son ni buenas ni malas en sí mismas; convienen a perfiles de empresa diferentes.

Visto desde la región, tres puntos merecen una atención particular. La localización de los datos, primero: ¿dónde están alojados sus datos, bajo qué jurisdicción, y qué dice la regulación de su país y de sus sectores regulados? La conectividad, después: un núcleo de gestión en el cloud supone enlaces de red cuya calidad y redundancia no se suponen, se verifican. El modelo económico, por último: la suscripción alisa el gasto, pero lo compromete a largo plazo y en divisa. Un director financiero debe poder comparar los escenarios en coste total a varios años, no según el precio del primero.

Nuestra posición: el cloud público es una excelente respuesta para una entidad que acepta el estándar y quiere ir rápido, una filial nueva por ejemplo. El cloud privado sigue siendo la vía natural de los paisajes complejos. Lo que cuenta no es la palabra «cloud», es la disciplina de arquitectura que la acompaña: un núcleo limpio, extensiones al lado del estándar y no dentro, para que el nuevo sistema no reproduzca la deriva del antiguo.

Las exigencias locales, en cabeza y no en anexo.

Vemos demasiados programas en los que la conformidad local llega al final del diseño, como un lote aparte confiado a los equipos del país. Es lo contrario lo que hay que hacer. El plan de cuentas, las obligaciones fiscales y declarativas, la facturación electrónica cuando se impone, la protección de los datos personales, la gestión de las divisas y de los flujos intragrupo deben fijarse desde la definición del alcance, país por país, porque condicionan el modelo de datos y el reparto de las olas.

Para un grupo marroquí que opera en África Occidental o Central, esto significa algo concreto: el modelo común debe diseñarse para absorber las diferencias locales sin transformar cada una en un desarrollo específico. Es un trabajo de arquitectura funcional, y ahí es donde la presencia de equipos que conocen esos contextos marca la diferencia entre un despliegue que se extiende y un despliegue que se atasca.

Decidir en pocas semanas, no en varios trimestres.

Nuestra convicción es simple: la primera etapa no es ni una licitación ni una elección de herramienta. Es una definición del alcance corta y decisiva, que entrega tres cosas a la dirección general.

• Un estado de situación sin complacencia del sistema existente: procesos, desarrollos específicos, datos, costes, riesgos, obligaciones locales. Un diagnóstico que extrae consecuencias, en lugar de un inventario más.
• Escenarios realmente comparados, en coste total y en beneficios esperados, con sus condiciones de éxito explícitas. Un escenario sin condiciones de éxito es un argumentario comercial.
• Una hoja de ruta por olas, secuenciada según las dependencias, la capacidad de absorción de los equipos y los plazos regulatorios de cada país, donde cada etapa entrega valor intermedio.

Esta definición del alcance cambia la relación de fuerzas. La empresa que sabe lo que quiere, en qué orden y en qué condiciones, elige a sus socios en lugar de padecerlos. Y ahí es donde la obligación se convierte en oportunidad: el plazo ofrece lo que ningún programa obtiene fácilmente, la alineación de toda la empresa, sede y filiales, en una misma fecha. Sería una lástima hacer de ello solo una migración técnica.

Una última cosa, que tiene que ver con nuestra manera de trabajar: quienes definen el alcance deben ser quienes entregan. Un escenario recomendado por un equipo que nunca asumirá su realización es un escenario sin responsable. Preferimos comprometer nuestro nombre en ambos.

Lo que hay que recordar

2027 es una fecha de decisión. Esperar la extensión del mantenimiento sin trayectoria es dejar que el mercado, las competencias y el calendario decidan en su lugar.

El escenario

Conversión, nueva implementación o transición selectiva: la elección se deduce de un diagnóstico de sus procesos, de sus desarrollos específicos, de sus datos y de su capacidad de absorción, nunca de una doctrina.

Lo local, primero

Exigencias fiscales, regulatorias y de datos de cada país en cabeza de la definición del alcance, no en anexo. El modelo común debe absorber las diferencias sin transformarlas en desarrollos específicos.

El primer paso

Una definición del alcance de pocas semanas: estado de situación, escenarios comparados, hoja de ruta por olas. Y después una decisión al nivel de la dirección general.

Para ir más lejos: nuestra oferta SAP S/4HANA, nuestro enfoque desde la definición del alcance hasta la realización, y nuestro punto de vista sobre la data foundation, que se construye la mayoría de las veces en el mismo movimiento.