¿Qué hacer con los desarrollos heredados en SAP? Cómo decidir qué conservar, retirar, reemplazar o refactorizar

Un desarrollo SAP puede llevar años funcionando correctamente y aun así merecer una revisión. No porque sea antiguo.

Sino porque el proceso cambió, la arquitectura evolucionó, apareció funcionalidad estándar equivalente o mantenerlo empieza a requerir más esfuerzo del que aporta al negocio.

El error sería asumir que existen solo dos opciones:

mantener todo o eliminar todo.

La evaluación de desarrollos heredados necesita una decisión más granular.

Nadipelli (2023) propone analizar las personalizaciones existentes y clasificarlas según su valor actual y riesgo de ciclo de vida para decidir si conviene mantenerlas, retirarlas, reemplazarlas, refactorizarlas o externalizarlas.

Un desarrollo heredado no es automáticamente un problema

Muchas personalizaciones fueron creadas porque el negocio realmente las necesitaba. Pueden soportar procesos críticos, regulaciones, integraciones o capacidades que el estándar no resolvía de manera suficiente.

El tiempo no convierte automáticamente ese desarrollo en deuda técnica.

La pregunta es otra:

¿sigue siendo la mejor forma de resolver esa necesidad hoy?

SAP y su ecosistema han evolucionado. También lo hicieron las necesidades de las empresas. Por eso una solución que tenía sentido cuando se construyó debería poder volver a justificarse años después.

Antes de decidir, hay que entender qué hace

No conviene empezar por revisar líneas de código.

Primero hay que entender el propósito.

• ¿Para qué se creó?
• ¿Qué problema resolvía?
• ¿Quién lo utiliza hoy?
• ¿Qué proceso depende de él?
• ¿Qué sistemas intercambian información con ese desarrollo?
• ¿Qué ocurriría si desapareciera?

Nadipelli (2023) propone que las personalizaciones heredadas se evalúen considerando, entre otros elementos, el valor de negocio, el uso, la condición técnica, el acoplamiento arquitectónico y el impacto en los upgrades.

Esto evita tomar una decisión exclusivamente tecnológica sobre algo que puede seguir siendo importante para la operación.

Opción 1. Conservar

Un desarrollo puede permanecer en pie cuando continúa aportando valor y su arquitectura sigue siendo sostenible.

Mantener puede tener sentido si: el proceso es crítico, la funcionalidad continúa diferenciando al negocio, el desarrollo está técnicamente estable, las dependencias son conocidas y su mantenimiento resulta justificable.

Conservar no significa olvidarse de él. También implica mantener documentación, ownership, testing y seguimiento de sus dependencias.

Nadipelli (2023) plantea que la retención debería reservarse especialmente para personalizaciones operacionalmente críticas, técnicamente estables y económicamente justificables.

Opción 2. Retirar

Hay desarrollos que siguen dentro del sistema simplemente porque nadie ha decidido eliminarlos. Pueden haber dejado de utilizarse. Pueden resolver un proceso que ya no existe. O pueden haber sido sustituidos por otra funcionalidad mientras la versión antigua continúa técnicamente activa.

En esos casos, mantener el desarrollo añade superficie de soporte, documentación y pruebas sin aportar un beneficio equivalente. La retirada resulta especialmente apropiada para desarrollos no utilizados o redundantes (Nadipelli, 2023). Pero tampoco debería eliminarse algo únicamente porque parece inactivo. Primero hay que confirmar dependencias.

Opción 3. Reemplazar por funcionalidad estándar

Un desarrollo pudo haber sido necesario porque SAP estándar no resolvía una necesidad en el momento en que fue implementado.

Años después, la situación puede ser distinta. Si el estándar actual cubre adecuadamente el proceso, mantener una personalización paralela puede seguir generando una dependencia que ya no es necesaria.

Nadipelli (2023) recomienda evaluar reemplazo cuando la funcionalidad estándar puede producir resultados comparables.

Esto no significa adoptar el estándar automáticamente. Hay que comprobar primero que cubra los requerimientos reales del negocio.

Opción 4. Refactorizar

Hay desarrollos cuya lógica sigue siendo valiosa, pero cuya implementación ya no resulta sostenible. Por ejemplo, pueden depender de objetos antiguos, interfaces no soportadas o estructuras altamente acopladas al core.

En esos casos, la necesidad de negocio continúa existiendo. Lo que debe cambiar es la forma técnica de resolverla. Refactorizar busca conservar el valor funcional mientras se reduce parte de la dependencia o fragilidad técnica.

Nadipelli (2023) plantea esta opción precisamente cuando la lógica diferenciada continúa aportando valor pero depende de objetos obsoletos o interfaces no soportadas.

Opción 5. Externalizar cuando realmente tiene sentido

Algunas capacidades pueden ejecutarse fuera del core mediante extensiones side-by-side.

SAP BTP, APIs liberadas y otros mecanismos permiten separar determinados ciclos de innovación del ciclo transaccional del ERP. Pero externalizar tampoco debe convertirse en la respuesta automática.

Una arquitectura distribuida introduce nuevas necesidades: integración, monitoreo, seguridad, documentación y ownership.

Por eso, Nadipelli (2023) señala que las extensiones side-by-side tienen mayor sentido cuando ventajas como despliegue independiente, escalabilidad, servicios cloud o integración con otros sistemas justifican el overhead adicional.

Mover complejidad fuera de SAP no significa necesariamente eliminarla.

Una matriz para evaluar cada desarrollo

Situación actual	Decisión que conviene evaluar
Ya no se utiliza	Retirar
Duplica funcionalidad estándar	Reemplazar
Sigue siendo crítico y estable	Mantener
La lógica aporta valor, pero la tecnología quedó obsoleta	Refactorizar
Necesita evolucionar independientemente del ERP	Evaluar externalización
Nadie puede explicar sus dependencias	Analizar antes de decidir
Tiene muchas integraciones punto a punto	Revisar arquitectura e interfaces

La matriz no sustituye una evaluación técnica y funcional. Su objetivo es evitar una decisión única para todo el custom code.

El valor del negocio debe ir primero

Una revisión de desarrollos puede convertirse fácilmente en un inventario puramente técnico.

• Programa.
• Objeto.
• Interfaz.
• Transporte.
• Responsable.

Pero esa información necesita cruzarse con negocio.

Un desarrollo con mucha complejidad técnica puede seguir siendo crítico. Otro técnicamente sencillo puede no aportar ningún valor. Por eso conviene revisar conjuntamente:

criticidad + uso + valor + condición técnica + dependencia + riesgo futuro.

Asuri (2021) destaca precisamente que la modernización debería partir de una evaluación de sistemas legacy, integraciones, gobierno y madurez de procesos antes de ejecutar cambios.

No conviene trasladar automáticamente todo a SAP BTP

Clean Core ha aumentado el interés por separar determinadas extensiones del core. Pero una aplicación sobre BTP mal gobernada también puede generar deuda técnica.

Puede aparecer lógica duplicada. Servicios sin documentación. Flujos de integración fragmentados. Dependencias difíciles de observar. La arquitectura limpia no depende únicamente de dónde se ejecuta el código. Depende también de cómo se gobierna durante su ciclo de vida.

Nadipelli (2023) advierte que externalizar sin gobierno puede trasladar la deuda desde el ERP hacia otras capas de integración y extensión.

El objetivo de Clean Core no es tener cero desarrollos

Un core limpio no significa una empresa sin particularidades. Significa evitar modificaciones innecesarias y utilizar mecanismos más controlados cuando una extensión realmente está justificada.

Esto requiere tomar decisiones de manera explícita:

• ¿debe permanecer dentro del core?
• ¿puede resolverse con estándar?
• ¿conviene una extensión controlada?
• ¿debería vivir fuera del ERP?
• ¿todavía necesitamos esa funcionalidad?

La fuente de Clean Core utilizada para este análisis plantea precisamente decisiones sistemáticas sobre qué capacidades deben permanecer, refactorizarse, retirarse, reemplazarse o externalizarse.

Antes de modernizar, construye el inventario

Una empresa que quiere reducir deuda técnica necesita saber primero qué tiene.

Un inventario útil debería permitir identificar: qué hace cada desarrollo, quién lo utiliza, qué proceso soporta, qué interfaces utiliza, qué documentación existe, qué objetos toca y qué impacto tendría modificarlo.

Después puede asignarse prioridad. No todos los desarrollos necesitan intervención simultánea. El objetivo es encontrar cuáles combinan alto impacto de negocio con alto riesgo técnico. Ahí suele estar la prioridad.

De conservar por costumbre a decidir con evidencia

El problema de un landscape SAP antiguo no es simplemente que tenga muchos desarrollos. El problema aparece cuando la empresa ya no puede explicar cuáles siguen siendo necesarios, cuáles generan riesgo y cuáles podrían simplificarse.

Una evaluación estructurada transforma una conversación como:

“no toquemos eso porque siempre ha estado ahí”

en:

“sabemos qué valor aporta, qué dependencias tiene y por qué decidimos mantenerlo o cambiarlo”.

Ese es un paso importante para reducir incertidumbre antes de futuros proyectos, upgrades o integraciones.

¿Sabes cuáles desarrollos SAP todavía justifican su complejidad?

En Altamira Technology realizamos Assessment TI para revisar aplicaciones, desarrollos, integraciones y dependencias antes de definir una ruta de optimización. El objetivo no es retirar personalizaciones indiscriminadamente, sino identificar qué conviene mantener, modernizar, sustituir o priorizar según su impacto real.

Referencias

Asuri, R. (2021). Advancing enterprise digital transformation by modernizing SAP Supplier Relationship Management through Clean Core architecture for SAP S/4HANA transition readiness and business process excellence. International Journal of Recent Advances in Science and Technology, 8(4), 1–20. https://doi.org/10.30750/ijarst.0804124

Nadipelli, P. R. (2023). Clean Core architecture: The foundation for sustainable SAP S/4HANA transformations. Journal of Artificial Intelligence, Machine Learning and Data Science, 6(1), 3517–3524. https://doi.org/10.51219/JAIMLD/purnachander-rao-nadipelli/692