Implementación o despliegue en SAP: diferencias y cuándo elegir

Una implementación de SAP construye el sistema donde no existe ninguno. Un despliegue toma un sistema SAP que ya funciona en algún punto del grupo y lo extiende a un nuevo país, entidad o unidad de negocio. Casi todo el mundo da por hecho que un despliegue es solo una implementación más pequeña. Ese supuesto genera más retrabajo en estos programas que cualquier decisión técnica.

Una vez dejé que un CFO creyera que un despliegue regional de SAP sería plug-and-play. Le expliqué los riesgos, pero no insistí. Usábamos una plantilla global y él daba por hecho que cada ubicación se alinearía sin mucho esfuerzo. No fue así. Una región necesitaba un tratamiento fiscal adicional. Otra tenía campos obligatorios de datos de empleados por leyes locales. Lo que parecía un trabajo de copiar y pegar exigió personalización real.

Así que la elección cambia cómo se dotan los recursos, se presupuesta y se ejecuta el trabajo. Si se equivoca, el sistema puede salir en producción igualmente, pero no como lo había planificado.

Una implementación parte de cero. Se define el alcance, se mapean los procesos, se configura, se migran los datos y se construyen las integraciones. Se aplica cuando una organización no tiene SAP o sustituye por completo un sistema heredado.

Un despliegue reutiliza un diseño que ya funciona: procesos, configuración, estándares de datos maestros. El trabajo es la distancia entre esa plantilla y lo que necesita la nueva ubicación. Impuestos, informes legales, monedas, idiomas, integraciones locales y las personas que lo usarán.

1. 05Usuarios localesFormación adaptada al proceso local, en el idioma local
2. 04Integraciones localesBancos, presentación de impuestos y sistemas logísticos del nuevo país
3. 03Datos localesDatos de clientes, proveedores y materiales mapeados a los estándares globales
4. 02Requisitos localesImpuestos, informes legales y campos obligatorios. Solo requisitos, no preferencias
5. 01Plantilla globalProcesos, configuración y estándares de datos maestros que ya funcionan

Así se comparan los dos en la práctica:

Área	Implementación de SAP	Despliegue de SAP
Punto de partida	Sin SAP, o un sistema heredado que se sustituye	SAP ya en funcionamiento en la sede central o en otra entidad
Diseño	Diseño nuevo, fit-to-standard	Plantilla global con desviaciones locales controladas
Duración típica	De 12 a 24 meses, más en grupos grandes	De 6 a 12 meses por ubicación
Riesgo principal	Incógnitas en todos los frentes de trabajo	Localización y preparación local
Datos	Carga completa desde sistemas heredados	Datos locales mapeados a los estándares globales de datos maestros
Pruebas	Ciclo completo: unitarias, de integración, UAT, de rendimiento	Localización, interfaces locales, UAT
Gestión del cambio	Programa completo desde cero	Materiales existentes adaptados a los equipos locales

Una implementación conviene cuando:

1. La organización nunca ha usado SAP.
2. El sistema actual está fallando y hay que sustituirlo por completo.
3. Una fusión, una adquisición o un nuevo modelo operativo hacen que el diseño antiguo ya no encaje.
4. Llega por primera vez una solución sectorial, como SAP for Utilities o SAP for Public Sector.
5. Ninguna plantilla existente cubre el alcance que necesita.

Las implementaciones tardan más y cuestan más al principio. Se obtiene un diseño que se ajusta a su negocio y un equipo que entiende cada decisión que hay detrás. Las empresas que se apresuran con los requisitos acaban gastando entre un 30 y un 50 por ciento más en corregir errores después. Lo he visto repetirse una y otra vez.

Un despliegue conviene cuando SAP ya funciona bien en algún punto del grupo, los procesos centrales son estables y la plantilla es lo bastante flexible para admitir requisitos locales sin romperse. Si alguna de esas tres condiciones es dudosa, arregle la plantilla antes de desplegarla en ningún sitio.

La parte técnica suele terminar a tiempo. Los retrasos vienen de las personas y de supuestos que no se cumplen en el nuevo país.

Una plantilla impuesta a los equipos locales

Lo que funcionó bien para Norteamérica puede quedarse corto en Asia o en Oriente Medio. Las estructuras fiscales, los flujos de aprobación y las reglas de captura de datos difieren. Una vez trabajé con una empresa que dio por hecho que su plantilla europea funcionaría en Oriente Medio. Provocó retrasos, reescrituras y mucha tensión. Los procesos de negocio eran sencillamente demasiado distintos.

La solución es dar a la nueva ubicación un responsable de negocio con autoridad para tomar decisiones. Si los equipos de la sede central deciden procesos para lugares que no entienden, salen diseños que fallan al primer contacto con los usuarios locales.

Localización descubierta en las pruebas

El tratamiento de impuestos, los informes legales y los campos obligatorios de datos hay que confirmarlos antes de que empiece el diseño. Una vez apoyé a un cliente al que una simple diferencia de configuración fiscal le retrasó el go-live más de un mes. No tenía que ver con la tecnología. Nadie había validado las necesidades locales con suficiente antelación.

Datos maestros que no encajan

Los códigos de producto, los números de cliente y las clasificaciones de proveedores tienen que coincidir con los estándares globales. Los desajustes que se descubren después del go-live son caros de corregir y rompen los informes consolidados. Mapee los datos locales al modelo global durante el diseño, no en la UAT.

Formación que explica el sistema global, no el local

Los despliegues tienden a reutilizar la formación de la implementación original. Ese material explica cómo funciona el sistema en la sede central. No explica las adaptaciones locales. Los usuarios que no entienden por qué su versión es distinta improvisarán soluciones paralelas.

El marco anterior sigue siendo válido. El modelo de implantación de la plantilla cambia parte de la economía y las reglas de extensión.

En RISE with SAP (Private Edition), cada nuevo país añade usuarios a una suscripción calculada sobre equivalentes de usuario completo (FUE). Se obtiene un costo predecible y menos trabajo de infraestructura. El costo también sigue corriendo después del go-live, así que compare las opciones a lo largo de varios años, no solo el primer año.

En GROW with SAP (Public Edition), compruebe primero si SAP entrega una versión local para el país. SAP listaba versiones locales para 59 países y regiones a febrero de 2024. Para otros países, el programa de localización como autoservicio de SAP permite a los socios crear una versión local del cliente con la Configuration Localization Tool, actualmente mediante una vía para early adopters (SAP Learning). Si no se da ninguno de los dos casos, tiene un problema de alcance, no un despliegue.

El Clean Core se aplica a cada desviación local. Public Edition solo acepta extensiones a través de interfaces liberadas. En Private Edition es una decisión de gobierno, pero cada modificación local que permite es un objeto más que volver a probar en cada actualización, multiplicado por cada país. La disciplina que defiendo es sencilla: las leyes fiscales, los informes legales y los mandatos regulatorios justifican una desviación. Las preferencias locales no.

Antes de comprometer una fecha para el siguiente país, consiga un sí en cada uno de estos puntos. Cada uno tiene un responsable.

1. Responsable de negocio local (nuevo país): nombrado, con autoridad para aprobar el diseño local.
2. Asesor fiscal y legal: impuestos, informes legales y campos obligatorios de datos documentados antes de que empiece el diseño.
3. Responsable de la plantilla (sede central): lista de desviaciones propuestas, cada una marcada como requisito o preferencia.
4. Responsable de datos: datos locales de clientes, proveedores y materiales mapeados a los estándares globales.
5. Responsable de integración: sistemas locales que deben conectarse, como bancos, presentación de impuestos o logística, identificados y con alcance definido.
6. Responsable del cambio: formación adaptada al proceso local, en el idioma local, con ejemplos locales.
7. Director del programa: una ubicación cada vez, con las lecciones del último go-live incorporadas al siguiente.

Mi guía de plantilla de alcance ayuda con el punto 3, y la guía del acta de constitución del proyecto explica cómo dejar por escrito los derechos de decisión.

Una implementación greenfield en Egipto. Una empresa manufacturera regional con sede en Egipto estaba atrapada con sistemas antiguos y desconectados y mucho trabajo manual. La cadena de suministro, el seguimiento de producción y los informes financieros no se comunicaban entre sí. Implementaron SAP S/4HANA desde cero y conectaron finanzas, compras y producción en un solo sistema. Pusieron en marcha una planificación automatizada de la cadena de suministro y formaron a más de 5000 empleados en cuatro países antes del go-live. No lo apresuraron. Redujeron los costos operativos un 25 por ciento y los errores de previsión un 35 por ciento.

Un despliegue a 15 mercados. Una empresa de retail ya tenía SAP S/4HANA funcionando en la sede central y lo necesitaba en 15 mercados nuevos. Cada uno tenía normas fiscales, monedas y prácticas empresariales distintas. Partieron de una plantilla global, la ajustaron por ubicación, desplegaron por fases durante dos años en lugar de todo a la vez y crearon formación para cada región. El resultado fue una consolidación financiera más rápida, seguimiento de inventario en tiempo real en todas las tiendas y informes un 20 por ciento más precisos a nivel de grupo.

Uno consistía en construir algo que no existía. El otro, en extender algo que funcionaba. Ninguno fue plug-and-play. Si está al principio del primero, mi guía sobre cómo empezar bien una implementación de SAP es el lugar por donde empezar.

¿Cuál es la diferencia entre una implementación de SAP y un despliegue de SAP?

Una implementación construye SAP desde cero: requisitos, diseño de procesos, configuración, migración de datos, integración, pruebas y go-live. Un despliegue extiende un sistema SAP existente y su plantilla global a un nuevo país, entidad o unidad de negocio. El trabajo del despliegue es la distancia entre la plantilla y las necesidades locales: impuestos, informes legales, idioma, integraciones locales y formación.

¿Cuándo debe una empresa elegir una implementación en lugar de un despliegue?

Elija una implementación cuando no hay SAP que extender o cuando se sustituye por completo un sistema heredado. También es la mejor vía cuando el modelo de negocio ha cambiado tanto que el diseño existente ya no encaja, o cuando ninguna plantilla cubre el alcance requerido. Forzar el despliegue de la plantilla equivocada genera más retrabajo que un diseño limpio.

¿Cuánto tarda un despliegue de SAP en comparación con una implementación?

Una implementación suele tardar de 12 a 24 meses, más en grupos grandes. Un despliegue suele tardar de 6 a 12 meses por ubicación, según la localización, las integraciones y los datos. La variable más importante es lo bien validados que estuvieran los requisitos locales antes de empezar el diseño.

¿Cuáles son los mayores desafíos de un despliegue de SAP en varios países?

Aparecen cuatro una y otra vez. Plantillas impuestas a los equipos locales sin su participación. Requisitos de localización descubiertos durante las pruebas. Datos maestros que no coinciden con los estándares globales. Formación que explica el sistema global en lugar del local. La mayoría son problemas de personas y de planificación, no técnicos.

¿Es un despliegue de SAP siempre más barato que una implementación completa?

Normalmente sí, porque el diseño ya existe y está probado. El ahorro se reduce cuando un país tiene reglas fiscales o de nómina complejas, necesita varias integraciones locales o tiene datos deficientes. Con RISE with SAP, la suscripción de cada nuevo país continúa después del go-live, así que compare los costos a lo largo de varios años.

¿Cómo funciona una plantilla global en un despliegue de SAP?

La plantilla global es el diseño SAP documentado y configurado para los procesos estándar del grupo. Cada despliegue parte de ella y añade solo los cambios locales que de verdad son necesarios. Cada desviación crea una obligación de mantenimiento en cada actualización, así que gobiérnelas: los requisitos como la ley fiscal justifican una desviación, las preferencias no.