Deuda técnica en SAP: 5 señales de que conviene evaluar el entorno antes de seguir modificándolo

Un entorno SAP puede seguir funcionando todos los días y, al mismo tiempo, volverse cada vez más difícil de modificar.

Un desarrollo que resolvió una necesidad hace años continúa activo. Una interfaz depende de componentes que pocos conocen. Un cambio aparentemente pequeño requiere más pruebas. Una actualización genera dudas sobre qué podría dejar de funcionar.

Ninguna de estas situaciones demuestra por sí sola que el sistema tenga un problema grave. Pero juntas pueden indicar que se está acumulando deuda técnica.

En entornos ERP, la deuda técnica no se limita al código. También puede aparecer en la arquitectura, las integraciones, las pruebas, la documentación y las dependencias creadas alrededor del sistema (Nadipelli, 2023).

La pregunta no debería ser únicamente si SAP funciona hoy.

También conviene preguntarse:

¿qué tan fácil, seguro y predecible será cambiarlo mañana?

¿Qué significa deuda técnica en SAP?

La deuda técnica aparece cuando decisiones que resolvieron una necesidad en determinado momento generan obligaciones futuras de mantenimiento. Una personalización puede haber sido completamente válida cuando se construyó.

El problema aparece cuando, con el tiempo, esa solución:

• depende de componentes antiguos;
• ya no está suficientemente documentada;
• duplica funcionalidad disponible en el estándar;
• dificulta upgrades;
• requiere pruebas adicionales cada vez que cambia el entorno;
• o continúa activa aunque el negocio ya no la necesite.

Nadipelli (2023) señala que en entornos ERP la deuda técnica puede abarcar código, arquitectura, testing, documentación y dependencias organizacionales. Por eso, tener custom code no significa automáticamente tener deuda técnica.

La deuda aparece cuando mantener esa decisión empieza a generar más complejidad, riesgo o esfuerzo del que aporta valor.

Señal 1. Cada cambio requiere más análisis y pruebas

Un cambio que antes parecía sencillo empieza a involucrar varias validaciones.

Hay que revisar qué desarrollos toca, qué integraciones dependen de ellos, qué usuarios podrían verse afectados y qué otros componentes podrían cambiar su comportamiento. Este incremento de esfuerzo puede ser una señal de que las dependencias del sistema han crecido.

La literatura sobre Clean Core relaciona las modificaciones extensas y las dependencias internas con un mayor esfuerzo de testing y remediación durante cambios y actualizaciones (Nadipelli, 2023).

La pregunta útil no es:

“¿por qué el equipo tarda tanto?”

Sino:

“¿qué dependencias debe comprobar el equipo antes de poder realizar el cambio con seguridad?”

Señal 2. Existen desarrollos o interfaces cuyo impacto ya no está claro

Un desarrollo puede estar funcionando correctamente y aun así representar un riesgo si nadie puede explicar con claridad: qué proceso soporta, qué sistemas consume, quién lo utiliza, qué objetos modifica o qué ocurriría si dejara de funcionar.

El problema no es únicamente documental. Sin esa visibilidad es más difícil evaluar el impacto de un cambio.

Las personalizaciones heredadas pueden depender de objetos obsoletos, interfaces no documentadas o lógica duplicada, complicando mantenimiento y evolución del entorno (Nadipelli, 2023).

En estos casos, antes de modificar conviene reconstruir el mapa de dependencias.

Señal 3. Actualizar SAP o incorporar una nueva integración genera demasiada incertidumbre

Una actualización debería requerir planificación. Pero existe una diferencia entre planificar y no saber qué podría romperse. Cuando cada upgrade obliga a revisar una gran cantidad de personalizaciones, interfaces y dependencias, parte del esfuerzo deja de estar en la nueva funcionalidad y pasa a comprobar que el entorno histórico continúe funcionando.

Nadipelli (2023) relaciona una personalización extensa con mayores necesidades de pruebas, remediación y riesgo durante transformaciones hacia SAP S/4HANA.

Asuri (2021) identifica un patrón similar en entornos SAP altamente personalizados: las integraciones complejas y modificaciones acumuladas pueden incrementar esfuerzo de mantenimiento, complejidad de implementación y dificultad para modernizar.

El problema, por tanto, no es actualizar. Es no conocer con suficiente certeza el impacto de actualizar.

Señal 4. Siguen activos desarrollos cuyo valor actual nadie ha vuelto a evaluar

Un desarrollo puede haber sido importante hace cinco o diez años. Eso no significa que continúe siendo necesario hoy. El proceso pudo cambiar.

SAP estándar pudo incorporar una funcionalidad equivalente. El área que lo utilizaba pudo adoptar otra solución. O puede existir una nueva arquitectura que permita resolver la necesidad con menos dependencia.

Mantener todo “porque funciona” también tiene un costo. Nadipelli (2023) propone evaluar las personalizaciones heredadas según su valor actual, uso, condición técnica, acoplamiento arquitectónico e impacto sobre futuras actualizaciones.

Esto permite separar aquello que sigue siendo estratégico de lo que simplemente se conserva por inercia.

Señal 5. El conocimiento para cambiar una parte de SAP depende de muy pocas personas

Una organización puede tener documentación técnica y aun así depender fuertemente de quienes conocen la historia detrás de determinadas decisiones.

• ¿Por qué se construyó este desarrollo?
• ¿Por qué esta interfaz funciona de esta manera?
• ¿Qué excepción buscaba resolver?
• ¿Qué proceso se afectaría si se modifica?
• Cuando esas respuestas dependen únicamente de conocimiento individual, el riesgo no está solo en la tecnología.

También existe una dependencia organizacional. La deuda técnica ERP puede extenderse precisamente a documentación y dependencias organizacionales, no únicamente al código (Nadipelli, 2023).

Cinco señales no equivalen a cinco diagnósticos

Señal observada	Qué conviene investigar
Cada cambio necesita más pruebas	Dependencias y acoplamiento
Nadie conoce completamente un desarrollo	Documentación y ownership
Un upgrade genera mucha incertidumbre	Custom code e interfaces
Existen desarrollos antiguos poco utilizados	Valor actual y redundancia
Solo algunas personas pueden modificar ciertas áreas	Transferencia de conocimiento y dependencia

Estas señales son puntos de partida. No prueban por sí mismas que SAP esté mal diseñado. Tampoco significan que sea necesario eliminar todos los desarrollos.

El objetivo es identificar dónde existe mayor exposición antes de que una necesidad urgente obligue a intervenir sin suficiente información.

No toda personalización es deuda técnica

Las empresas tienen procesos que pueden justificar una diferencia respecto del estándar. Una regulación, una capacidad crítica o una característica que realmente diferencia la operación pueden requerir extensiones específicas.

Clean Core no significa que SAP deba permanecer completamente estándar. El principio es más bien que las desviaciones sean deliberadas, justificadas y gobernables.

Nadipelli (2023) plantea que la estandarización debe ser el punto de partida, mientras que las desviaciones deberían justificarse por valor estratégico, regulatorio u operativo.

La pregunta correcta no es:

“¿Tenemos personalizaciones?”

Sino:

“¿Seguimos entendiendo por qué existen y cuánto cuesta mantenerlas?”

Qué debería revisar un Assessment de deuda técnica

Un diagnóstico no debería empezar eliminando desarrollos.

Primero debería identificar y clasificar.

Conviene revisar al menos:

• Valor actual. ¿El desarrollo sigue resolviendo una necesidad real?
• Uso. ¿Quién lo utiliza y con qué frecuencia?
• Dependencias. ¿Qué procesos, interfaces u objetos dependen de él?
• Condición técnica. ¿Utiliza componentes soportados y mantenibles?
• Impacto futuro. ¿Qué ocurre durante upgrades, integraciones o cambios?
• Documentación y ownership. ¿Está claro quién debe mantenerlo?

A partir de esta evaluación pueden priorizarse decisiones.

Algunas soluciones deberán mantenerse. Otras podrán documentarse mejor. Algunas necesitarán modernización. Y otras quizá ya no deberían existir.

Clean Core no elimina automáticamente la deuda técnica

Mover un desarrollo fuera del core tampoco resuelve el problema por sí solo.

Una arquitectura distribuida puede volver a generar complejidad si aparecen servicios sin documentación, integraciones fragmentadas o extensiones sin gobierno.

Nadipelli (2023) advierte que incluso extensiones sobre SAP BTP pueden crear nuevas obligaciones de integración, seguridad y mantenimiento cuando no existe gobierno adecuado.

Por eso Clean Core debe entenderse como una disciplina continua, no como una limpieza que se realiza una sola vez.

Identificar antes de reaccionar

La deuda técnica rara vez aparece como una alerta explícita. Normalmente se manifiesta en pequeños aumentos de complejidad: más pruebas, más dependencia, más incertidumbre y mayor dificultad para explicar cómo afectará un cambio al resto del entorno.

La respuesta tampoco debería ser reconstruir todo. El primer paso es identificar dónde está concentrado el riesgo y priorizar.

La deuda técnica se gestiona mejor cuando todavía permite decidir qué corregir, modernizar, documentar o retirar, no cuando una incidencia obliga a actuar.

¿Qué partes de tu entorno SAP están acumulando mayor riesgo?

En Altamira Technology realizamos Assessment TI para analizar procesos, aplicaciones, integraciones y dependencias antes de definir cambios tecnológicos. El objetivo es identificar qué componentes necesitan atención y priorizar las acciones según su impacto operativo.

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