¿Cuántos programas Z tiene tu sistema SAP? ¿Y cuántos de ellos podría alguien de tu equipo explicar — en detalle y sin dudar — ahora mismo?
Si la respuesta honesta es “no estoy seguro” o “solo María sabe eso”, acabas de identificar uno de los riesgos técnicos más infravalorados en cualquier organización que trabaja con SAP ECC o S/4HANA.
Las empresas invierten millones en implementar SAP. Documentan procesos estándar, mapean flujos de negocio, forman a los usuarios finales. Pero hay un rincón en casi todos los sistemas SAP donde la lógica crítica se esconde a plena vista: el “mundo Z”. Cientos o miles de objetos desarrollados a medida que nadie se molestó en documentar, pero de los que todos dependen y que — tarde o temprano — se convierten en el cuello de botella de cualquier migración, escalado de soporte o proyecto de modernización.
Según investigaciones de ASUG, un sistema SAP ECC promedio contiene más de 30.000 extensiones personalizadas. Y entre el 40% y el 70% de ese código nunca se utiliza. Las organizaciones que pagan por mantenerlo a menudo ni siquiera saben que existe.
Este artículo trata sobre por qué tener un inventario completo de los objetos no estándar en SAP no es solo una tarea técnica de mantenimiento — es una decisión estratégica. Y por qué cuanto más tiempo esperes, más costará.
El “mundo Z”: el rincón de SAP que todos usan y nadie documenta
En SAP, los objetos con prefijo Z o Y — o aquellos que pertenecen a un namespace personalizado como /COMPANY/ — son desarrollos propios: código que no proviene de SAP AG, sino que ha sido creado o encargado por tu organización para cubrir las brechas entre el estándar y tu realidad operativa.
Y siempre hay brechas.
Ninguna implementación de SAP cubre el 100% de los procesos reales de una empresa. Las industrias tienen sus propias reglas. Las operaciones tienen matices que ningún proveedor de software puede anticipar. Por eso, con los años, los sistemas SAP en producción acumulan:
- Programas Z: informes, interfaces, procesos de ejecución masiva, integraciones con sistemas externos.
- Módulos de función y clases personalizados: lógica de negocio reutilizable desarrollada internamente.
- Enhancements implementados y BAdIs: modificaciones sutiles al comportamiento estándar de SAP.
- Tablas Z, estructuras y elementos de datos: para almacenar información que SAP no soporta de forma nativa.
- SmartForms, SAPscripts y Adobe Forms personalizados: documentos impresos como pedidos de compra, etiquetas o facturas.
- Transacciones personalizadas, menús de usuario y objetos de autorización: toda la capa de acceso construida a medida.
En una empresa mediana con varios años trabajando con SAP en producción, esto puede representar cientos o miles de objetos. Las grandes empresas o aquellas con una larga trayectoria en SAP superan habitualmente los 5.000 o incluso 10.000 objetos no estándar activos.
El problema no es que existan. El problema es que casi nunca están documentados.
Se crean para resolver un problema específico. Funcionan. Se olvidan. Un año después, alguien los modifica para resolver otro problema. Y así sigue acumulándose código — hasta que nadie sabe exactamente qué hace cada uno, de qué depende o si realmente sigue siendo necesario.
El riesgo real: cuando el conocimiento reside en las personas, no en los sistemas
Existe un concepto en ingeniería de software llamado “factor autobús”: ¿cuántas personas de tu equipo tendrían que ser atropelladas por un autobús para que el conocimiento crítico del sistema desapareciera?
En la mayoría de los entornos SAP, ese número es uno. O dos.
Está el consultor ABAP que lleva diez años en el proyecto y “conoce el sistema”. Sabe que el programa ZFACT_EXPORT_DEL tiene una excepción especial para clientes del Grupo X. Sabe que la interfaz del SGA no utiliza la BAPI estándar — utiliza un módulo de función personalizado que alguien escribió en 2011 porque la BAPI tenía un error. Sabe por qué existe una tabla Z con 400.000 registros que nadie depura.
Cuando se va — y eventualmente lo hará — ese conocimiento se va con él.
Lo que queda es un ticket de soporte que tarda tres días en resolverse porque el equipo actual tiene que leer un programa de 2.000 líneas sin comentarios, línea por línea, para entender qué está fallando. O un proyecto de migración que se retrasa meses porque nadie puede decir con certeza qué objetos Z están activos, cuáles están obsoletos y cuáles son críticos para el negocio.
La investigación de ASUG encontró que el 45% de las organizaciones afirma que su código personalizado más valioso se implementó hace seis años o más — lo que significa que las personas que lo desarrollaron probablemente ya se han marchado. Mientras tanto, el 29% de las empresas considera que mantener personal con conocimiento es un gran desafío, y el 33% tiene dificultades para encontrar el talento necesario para mantener y mejorar sus desarrollos personalizados.
La propia documentación de SAP sobre Custom Code Migration lo expresa claramente: “El código fue implementado hace muchos años, a menudo se extiende a lo largo de múltiples páginas, tiene muy poca o ninguna documentación y el autor del código ya no está disponible para consultas”.
Eso no es una limitación técnica. Es amnesia institucional — y es uno de los costes silenciosos más caros en el IT empresarial.
Clean Core en SAP S/4HANA: sin mapa no hay ruta
Si estás trabajando con SAP ECC o planificando una migración a S/4HANA, casi con total seguridad has oído hablar de Clean Core. Ya no es una recomendación — en SAP Sapphire 2024, la dirección de SAP dejó claro que Clean Core es esencialmente obligatorio para cualquier estrategia ERP moderna.
SAP define Clean Core como mantener el entorno de S/4HANA lo más cercano posible al estándar, con todas las extensiones construidas externamente mediante frameworks aprobados — principalmente SAP Business Technology Platform (BTP) y ABAP Cloud. El principio rector es que cualquier personalización debe desacoplarse del core para que las actualizaciones sean estables, los procesos se mantengan ágiles y la innovación pueda adoptarse sin fricción.
En agosto de 2025, SAP formalizó esto en una clasificación de madurez de cuatro niveles para el código personalizado:
- Nivel A (Totalmente conforme): utiliza únicamente interfaces SAP públicas y estables. Es el estándar de referencia para todo nuevo desarrollo.
- Nivel B (Conforme): cumple con los criterios del Nivel A, pero también utiliza APIs clásicas (BAPIs, IDocs, RFCs). Generalmente es compatible con actualizaciones.
- Nivel C (Parcialmente conforme): accede a objetos internos de SAP. Conlleva riesgo en las actualizaciones. Debe estar incluido en un plan de remediación documentado.
- Nivel D (No conforme): utiliza patrones explícitamente prohibidos — modificaciones directas, acceso de escritura a tablas SAP, enhancements implícitos. Debe eliminarse.
El ABAP Test Cockpit (ATC) automatiza esta clasificación y, en S/4HANA 2025, las comprobaciones de Clean Core se incorporan de forma nativa. La política impuesta es inequívoca: no se permite nuevo código de nivel D; todo el código de nivel C debe tener un plan de refactorización.
Aquí está el problema: para clasificar tu código personalizado, primero necesitas saber que existe.
No puedes remediar lo que no has inventariado. No puedes priorizar qué refactorizar, qué mover a BTP, qué eliminar y qué mantener — si no tienes un mapa completo y preciso de tu ecosistema Z.
Las organizaciones que llegan a proyectos de migración a S/4HANA sin ese mapa se enfrentan a consecuencias previsibles. Un estudio de 2025 de Horváth Partners sobre 200 empresas encontró que el 60% de los proyectos S/4HANA superaron el presupuesto y solo el 8% completó la transformación a tiempo. El principal culpable, identificado de forma consistente en múltiples estudios independientes: el código personalizado no documentado ni gestionado.
El código personalizado no suele ser el enemigo. La falta de visibilidad sobre él sí lo es.
Por qué un inventario manual nunca es suficiente
El enfoque típico es el siguiente: una reunión de inicio de proyecto, una hoja de cálculo compartida en SharePoint, un correo al equipo ABAP pidiéndoles que “documenten sus programas”, unas semanas de aportaciones poco consistentes y un archivo que nadie actualiza después del go-live.
Falla por razones previsibles:
Primero, no es exhaustivo. Los equipos documentan los programas que recuerdan o utilizan con más frecuencia. La “larga cola” de objetos — integraciones heredadas, informes puntuales que nunca se desmantelaron, implementaciones de enhancements de hace tres consultores — nunca llega a la hoja de cálculo.
Segundo, se queda obsoleto inmediatamente. Los sistemas SAP no son estáticos. Se crean nuevos objetos, los existentes se modifican, algunos se abandonan. Un inventario manual en un momento puntual queda desactualizado en cuestión de semanas.
Tercero, no captura dependencias. Saber que existe ZREPORT_ORDERS no es lo mismo que saber que llama al módulo de función ZFUNC_PRICING, que lee la tabla ZCUST_MARGINS, que es actualizada por un job batch que se ejecuta cada noche. La documentación manual casi nunca captura este grafo de dependencias.
Cuarto, no sirve para IA. A medida que las organizaciones avanzan hacia soporte y desarrollo asistidos por IA, el formato de la documentación importa. Un documento en Word en texto libre que describe lo que un programa “más o menos hace” no es útil para un agente de IA que necesita conocimiento estructurado, indexado y vectorizado para razonar con precisión sobre el código.
La brecha entre “tenemos algo documentado” y “tenemos visibilidad real” es enorme — y costosa.
Clean Core comienza antes de la migración: el coste oculto del código Z no gestionado
La realidad financiera del código personalizado no gestionado es contundente.
La investigación de ASUG encontró que las empresas gastan una media de 815.857 dólares al año para mantener su código personalizado SAP más valioso. Para el 37% de las organizaciones, esto representa hasta el 50% del gasto anual en IT. Y el soporte del código personalizado, en toda la base de clientes, puede añadir un 33% adicional sobre los costes estándar de mantenimiento SAP — antes de que se abra una sola solicitud de mejora.
Cuando comienza la migración, los costes se aceleran. Los servicios de implementación — incluyendo análisis de código personalizado, remediación y adaptación — representan entre el 40% y el 60% del coste total de una migración a S/4HANA (Tachyon Technologies). Panaya estima que el trabajo relacionado con código personalizado supone aproximadamente el 40% del esfuerzo de migración. Y el 43% de las organizaciones en un benchmark de SAPinsider de 2025 citan la remediación del código personalizado como su principal obstáculo en la migración.
Estas cifras no son motivo de pánico. Son motivo de preparación. Las organizaciones que gestionan eficazmente los costes de migración son aquellas que comenzaron con un inventario completo y actualizado — sabiendo exactamente qué tenían, qué seguía en uso y qué podía retirarse antes de que el reloj de la migración empezara a correr.
De hecho, un caso de estudio de SAP Community documentó una empresa que retiró casi el 10% de su código personalizado antes de la migración simplemente identificando objetos no utilizados mediante análisis de uso — objetos que, de no haberse identificado primero, se habrían trasladado, analizado, adaptado y probado con un coste significativo.
“Joule conoce SAP. No conoce tu SAP.”
En este punto, surge una pregunta razonable: ¿no pueden las propias herramientas de IA de SAP encargarse de esto?
SAP Joule es realmente impresionante. SAP ha desarrollado un modelo de lenguaje de gran tamaño específico, entrenado con 250 millones de líneas de código ABAP y 30 millones de líneas de código CDS, además de una extensa documentación técnica de SAP. Puede generar código, explicar programas, escribir tests unitarios, sugerir adaptaciones a S/4HANA y navegar por el desarrollo en ABAP Cloud — todo dentro del IDE.
Pero hay un límite arquitectónico que Joule no puede superar: no tiene ningún conocimiento del código Z/Y específico de tu empresa.
SAP es claro al respecto: los datos de los clientes nunca se utilizan para el entrenamiento ni se comparten con terceros. El LLM de ABAP se ha entrenado con el código estándar de SAP — no con los módulos de función personalizados que tu equipo desarrolló en 2009, ni con las tablas Z que contienen tus excepciones de precios, ni con las implementaciones de enhancements que modifican el comportamiento estándar de compras de formas que solo dos consultores entienden.
Joule puede analizar un objeto personalizado específico cuando un desarrollador lo selecciona manualmente en el IDE y solicita una explicación. Pero eso es una interacción a nivel de objeto individual — no proporciona a Joule una visión sistémica de tu ecosistema personalizado. No puede decirte de forma proactiva qué transacciones Z se están utilizando activamente. No puede mapear las dependencias entre tus objetos personalizados. No puede explicar por qué se construyó una personalización específica o qué lógica de negocio codifica, a menos que esa lógica esté documentada en comentarios del código (lo cual casi nunca ocurre).
Como señala el partner de SAP Arvato Systems: “En el caso de soluciones estándar, SAP Joule está disponible con solo pulsar un botón. Para desarrollos personalizados, en cambio, proporcionar el asistente de IA puede resultar bastante complicado”.
Esto no es una crítica a Joule — es una realidad estructural. Las herramientas de IA de propósito general y basadas en código estándar son potentes dentro de su ámbito. No pueden sustituir una base de conocimiento construida a partir de tu código específico.
Joule conoce SAP mejor que cualquier herramienta hasta ahora. No conoce tu SAP. Esa distinción es enormemente importante.
SiDOC: del caos a un mapa completo de tu código personalizado SAP — en menos de 10 días
Este es el problema que SiDOC, desarrollado por Innova Apps, fue diseñado para resolver.
SiDOC es una solución en tres pasos que inventaría, documenta y activa automáticamente el conocimiento contenido en tu código personalizado SAP — transformando tu ecosistema Z de un problema en un activo de conocimiento consultable y preparado para IA.
Paso 1 — Extraer: inventario completo en ~15 minutos
Un programa ABAP (entregado como un transporte estándar de SAP) se instala en el sistema del cliente y extrae automáticamente todos los objetos no estándar: programas, módulos de función, clases, tablas, estructuras, elementos de datos, dominios, tipos de tabla, transacciones, enhancements, SmartForms, ayudas de búsqueda y objetos de autorización. Genera archivos de salida estandarizados que contienen el código fuente, metadatos y una lista completa de objetos. Los filtros por paquete, fecha y tipo de objeto permiten a los equipos delimitar la extracción con precisión.
El resultado no es solo una lista — es un mapa estructurado y completo de todo lo que existe en tu ecosistema Z, generado automáticamente y libre de sesgos por omisión humana.
Paso 2 — Documentar: documentación generada por IA diseñada para humanos y máquinas
Una capa de procesamiento impulsada por IA consume los objetos extraídos y genera documentación estructurada en Markdown para cada uno: propósito, entradas, salidas, lógica de procesamiento paso a paso, dependencias y requisitos de autorización. Los objetos de front-end (JavaScript, TypeScript, UIS, Fiori) también se documentan si existen.
De forma crítica, esta documentación no está pensada para archivarse sin más. Está diseñada para la inteligencia. La capa de documentación aplica prácticas que hacen que la recuperación mediante IA sea precisa y fiable:
- Indexación y mapeo: referenciación cruzada de objetos, dependencias y contextos de negocio para que las consultas devuelvan resultados relevantes y conectados — no fragmentos aislados.
- Precisión mediante “chunking”: división de la documentación en fragmentos semánticamente coherentes que pueden recuperarse con precisión sin perder el contexto.
- Embeddings y vectorización: estructuración de la base de conocimiento para búsqueda semántica, de modo que las consultas en lenguaje natural devuelvan respuestas precisas y fundamentadas.
Para un paquete ABAP con aproximadamente 1.000 objetos ABAP, todo este proceso se ejecuta automáticamente en 1 hora. No se requiere consultor. Sin esfuerzo manual.
Paso 3 — Inteligencia RAG: haz preguntas y obtén respuestas sobre tu propio código
La base de conocimiento documentada se conecta a un agente de IA que entiende tu entorno SAP específico — el que tu equipo realmente ha construido, no una aproximación genérica. Este agente puede:
- Dar soporte a los equipos ABAP: cuando se reporta un bug, el agente identifica qué programas y módulos de función están implicados, explica la lógica y propone la causa raíz probable — sin que el consultor tenga que pasar horas leyendo código heredado que nunca ha visto.
- Generar especificaciones técnicas: para nuevas solicitudes de desarrollo, el agente produce especificaciones que siguen tus estándares de codificación existentes, reutilizan la lógica documentada cuando es posible y detectan conflictos con funcionalidades existentes.
- Acelerar nuevos desarrollos: al mostrar objetos existentes relevantes, el agente evita que los desarrolladores reinventen lógica que ya existe — un problema sorprendentemente común y costoso en entornos SAP grandes.
- Responder preguntas de negocio sobre el código: perfiles como responsables de IT, consultores funcionales y project managers pueden preguntar en lenguaje natural qué hace una transacción Z concreta, qué tablas utiliza y qué reglas de negocio aplica — sin necesidad de abrir el editor ABAP.
La función delta garantiza que la base de conocimiento se mantenga actualizada: cuando los objetos se modifican, solo se reprocesan los componentes cambiados. Tu documentación no se convierte en una foto fija que envejece hasta quedar obsoleta — se mantiene viva.
El impacto estratégico: tres dimensiones de valor
Los beneficios de un inventario completo de código personalizado preparado para IA se acumulan en tres dimensiones que importan a diferentes stakeholders.
Para CIOs y líderes de IT: preparación para Clean Core con datos reales
En lugar de entrar en una conversación de planificación de migración a S/4HANA con estimaciones y suposiciones, tu equipo llega con un mapa completo y clasificado del ecosistema Z. Cada objeto identificado. Los patrones de uso analizados. La clasificación A-D aplicada. El alcance de la remediación cuantificado. Las estimaciones de presupuesto se basan en recuentos reales de objetos. Las discusiones de alcance se basan en complejidad real, no en porcentajes aproximados. Y la hoja de ruta de Clean Core — qué refactorizar, qué mover a BTP, qué retirar — se basa en datos, no en conjeturas.
Para equipos ABAP y soporte: dejar de pagar por “arqueología”
Cada hora que un consultor ABAP dedica a hacer ingeniería inversa sobre código heredado que nunca ha visto es una hora que no se dedica a resolver el problema de negocio. Con SiDOC, ese conocimiento ya está disponible. Esto no sustituye la experiencia ABAP. La potencia. Un equipo de tres consultores con SiDOC opera de forma más eficiente que un equipo de cinco sin él, porque el conocimiento institucional que antes residía en la cabeza de un consultor que se marchaba ahora es accesible para todos.
Para equipos de proyecto: planificación de migraciones sin sorpresas
Nada descarrila un proyecto de migración más rápido que descubrir complejidad no documentada en mitad del proceso. SiDOC elimina esa categoría de sorpresas. Para cuando comienza el proyecto de migración, cada objeto Z es conocido, está documentado y clasificado. El trabajo se dimensiona con precisión desde el primer día.
De caja negra a activo estratégico: una forma diferente de pensar sobre el código personalizado
Existe un instinto persistente en las organizaciones SAP de tratar el código personalizado como un pasivo — “deuda técnica” — que debe minimizarse, ocultarse o eventualmente eliminarse. Ese enfoque pasa por alto algo importante.
Tu ecosistema Z existe porque tus procesos de negocio son realmente diferentes del estándar de SAP. Esas personalizaciones recogen años de aprendizaje operativo: excepciones, reglas, integraciones y casos límite que hacen que tu sistema funcione para tu negocio. En muchos casos, representan auténticas ventajas competitivas en los procesos.
El problema nunca fue la personalización. El problema fue la falta de visibilidad.
Un ecosistema de código personalizado documentado, inventariado e indexado con IA no es un pasivo. Es un activo — uno que puede gobernarse, mantenerse, evolucionarse y aprovecharse. La misma lógica que hoy hace que tu código Z sea difícil de gestionar lo hace valioso una vez se entiende.
El objetivo no es eliminar el mundo Z. El objetivo es dejar de temerle.
Puedes tenerlo en menos de 10 días
Una última cosa que merece decirse claramente:
La brecha entre “no sabemos qué hay en nuestro sistema SAP” y “tenemos una base de conocimiento completa, preparada para IA, de cada objeto personalizado” no es un proyecto de seis meses. No es un gran engagement de consultoría. No requiere un equipo de proyecto dedicado ni una larga fase de requisitos.
Con SiDOC, la extracción se ejecuta en un par de horas. La capa de documentación con IA se completa en 3–4 horas. El agente RAG está operativo desde el primer día. Para la mayoría de las organizaciones, todo el proceso — desde cero visibilidad hasta un inventario completo y consultable — lleva menos de 10 días desde la instalación hasta el uso activo.
La inversión es una fracción de lo que la mayoría de los equipos gastan en una sola semana de horas de soporte ABAP intentando entender código heredado que debería haberse documentado hace años.
Tu sistema SAP ha estado acumulando conocimiento personalizado durante años. Es hora de hacer que ese conocimiento trabaje para ti.
¿Te interesa ver qué encontraría SiDOC en tu sistema SAP? Reserva una conversación con el equipo de Innova Apps — sin compromiso, sin necesidad de configuración previa.
Sobre Innova Apps
Innova Apps se especializa en desarrollar aplicaciones que optimizan los procesos de la cadena de suministro para empresas que utilizan SAP ECC y SAP S/4HANA. “Tus procesos SAP, más fáciles.”
