¿Tu gestión de gastos sigue dependiendo de procesos manuales entre
sistemas?

Con SAP Power Connector by GROUPmee conectas Captio y SAP de
forma nativa para que la información fluya automáticamente, sin
duplicidades ni integraciones complejas.

Digitaliza la gestión de los gastos de empleado, automatiza la
contabilización y mejora la visibilidad financiera en tiempo real, todo
desde tu entorno SAP

Los IDocs son una de esas tecnologías en SAP que todo el mundo ha utilizado en algún momento, pero cuyo origen y evolución pocas veces se analizan con detalle. Se han convertido en algo tan habitual dentro del ecosistema que muchas veces se perciben como una pieza más del sistema, cuando en realidad su creación responde a una necesidad muy concreta en un contexto tecnológico completamente distinto al actual.

Para entenderlos, hay que remontarse a finales de los años 80 y principios de los 90. En ese momento, las empresas empezaban a necesitar intercambiar información entre sistemas, pero no existían los estándares actuales. No había APIs REST, ni arquitecturas desacopladas, ni plataformas de integración modernas. Cada sistema tenía su propia forma de estructurar la información, lo que hacía que las integraciones fueran complejas, costosas y poco escalables. SAP necesitaba una solución que permitiera estructurar y estandarizar el intercambio de datos, tanto entre sistemas SAP como con sistemas externos.

En ese contexto nacen los IDocs (Intermediate Documents). Su objetivo era definir un formato estructurado, independiente del sistema, capaz de representar distintos tipos de mensajes de negocio como pedidos, facturas o movimientos logísticos. Este enfoque permitía desacoplar la lógica de negocio de la forma en la que se transmitía la información, algo especialmente avanzado para la época. Los IDocs se integraron dentro de la arquitectura ALE (Application Link Enabling), que permitía la distribución de datos entre distintos sistemas de forma controlada y consistente.

Sin embargo, el verdadero impacto de los IDocs no se limita a la parte técnica. A medida que SAP se extendía en grandes organizaciones, surgió la necesidad de comunicarse con agentes externos como proveedores, clientes, bancos o administraciones públicas. Aquí entra en juego el concepto de EDI (Electronic Data Interchange), que ya existía como estándar para el intercambio electrónico de documentos entre empresas. El problema era evidente: SAP utilizaba IDocs, mientras que el mundo exterior utilizaba formatos como EDIFACT, ANSI X12 o distintos esquemas XML.

Esa diferencia de “idiomas” generó una necesidad clara: traducir la información entre SAP y el resto del ecosistema. Y es precisamente en ese punto donde aparece un modelo de negocio muy relevante. Empresas como EDICOM se especializaron en actuar como intermediarios, transformando los IDocs en formatos EDI comprensibles para terceros, y viceversa. Este servicio no solo resolvía un problema técnico, sino que permitía a las empresas externalizar la complejidad de sus integraciones.

Con el tiempo, este tipo de compañías no solo se consolidaron, sino que dieron lugar a todo un ecosistema de proveedores especializados en integración B2B. Empresas como Seeburger, OpenText, SPS Commerce o IBM Sterling han desarrollado soluciones que permiten gestionar estas conversiones de forma robusta, escalable y conforme a los estándares de cada industria. En muchos casos, estas plataformas no solo traducen mensajes, sino que gestionan flujos completos de integración, validaciones, monitorización y cumplimiento normativo.

Lo interesante de todo esto es que los IDocs no fueron diseñados con la intención de crear un mercado alrededor, sino como una solución técnica interna para SAP. Sin embargo, al establecer un formato propio de comunicación, se generó de forma indirecta una dependencia de mecanismos de traducción cuando se interactuaba con sistemas externos. Esa necesidad dio lugar a un modelo de negocio sostenido durante décadas.

A pesar de ello, los IDocs siguen desempeñando un papel fundamental. Existen miles de sistemas SAP en funcionamiento que dependen de ellos para procesos críticos y su robustez y fiabilidad hacen que no vayan a desaparecer en el corto plazo. Más que una sustitución directa, lo que se está produciendo es una evolución en su papel dentro de la arquitectura. Cada vez es más habitual que los IDocs se utilicen como mecanismo interno dentro de SAP, mientras que las integraciones externas se exponen mediante APIs o servicios modernos.

SAP ha anunciado recientemente que su infraestructura cloud ha obtenido la certificación IT-Grundschutz en Alemania, un estándar bastante exigente en materia de seguridad de la información. A simple vista puede parecer una noticia más dentro del mundo cloud, pero si te paras a analizarla, tiene bastante más peso de lo que parece.

Para poner contexto, IT-Grundschutz es un marco definido por el BSI, el organismo alemán de referencia en ciberseguridad. No es una certificación cualquiera. Está especialmente orientada a garantizar niveles muy altos de protección en entornos donde la seguridad es crítica, como administraciones públicas o grandes corporaciones con requisitos estrictos.

El hecho de que SAP haya conseguido esta certificación para sus centros de datos en Alemania no es solo un tema técnico. Es también un movimiento estratégico bastante claro. Alemania, y en general Europa, lleva tiempo poniendo el foco en la soberanía del dato, la privacidad y el cumplimiento normativo. En ese contexto, muchas empresas siguen siendo reticentes a mover sus sistemas críticos al cloud, especialmente cuando hablamos de datos sensibles.

Aquí es donde SAP intenta posicionarse.

Con este tipo de certificaciones, no solo está diciendo “mi cloud es seguro”, sino que está intentando demostrar que su infraestructura cumple con los estándares más exigentes a nivel regulatorio. Es una forma de reducir una de las principales barreras que todavía existen para muchas compañías: la desconfianza hacia el cloud en entornos críticos.

Y esto conecta directamente con todo lo que está empujando SAP en los últimos años: RISE, GROW, S/4HANA Cloud… toda su estrategia pasa por mover a los clientes hacia modelos cloud. Pero para que eso ocurra, no basta con ofrecer tecnología. Hace falta generar confianza.

Desde ese punto de vista, esta certificación no es solo un logro técnico, es una pieza más dentro de ese cambio de modelo.

También es interesante verlo desde la perspectiva del mercado. Muchos clientes, especialmente en sectores regulados como banca, sector público o industria, necesitan garantías muy concretas antes de dar el paso. Este tipo de certificaciones pueden ser el factor que desbloquee decisiones que llevaban tiempo paralizadas.

Ahora bien, esto tampoco cambia una realidad importante.

Aunque SAP refuerce su posicionamiento en seguridad, el debate sobre cloud no desaparece. Siguen existiendo dudas sobre costes, control, dependencia del proveedor o adaptación de procesos. Es decir, la certificación ayuda… pero no resuelve todas las preguntas.

Lo que sí deja claro es hacia dónde va SAP.

Cada vez está invirtiendo más en convertir su infraestructura cloud en una opción viable incluso para los entornos más exigentes. Y eso es clave, porque si quiere que el cloud sea el modelo dominante, necesita convencer precisamente a esos clientes que hoy todavía dudan.

En el fondo, esta noticia no va solo de seguridad.

Va de algo más importante: de cómo SAP está intentando eliminar una de las últimas barreras que quedan para que muchas empresas den el salto definitivo al cloud.

Y viendo este tipo de movimientos, parece bastante claro que esa transición no es opcional… es el camino que SAP está marcando.

Esta semana SAP SE ha seguido mostrando una tendencia bastante alineada con lo que viene haciendo en los últimos meses: una compañía cada vez más percibida por el mercado como un jugador fuerte en cloud y no solo como un proveedor tradicional de software empresarial.

Uno de los puntos clave que sigue influyendo en su comportamiento en bolsa es su transición hacia ingresos recurrentes. Todo lo relacionado con cloud, especialmente RISE y GROW, sigue siendo uno de los principales drivers que los inversores están observando. Cuanto más crecen esos ingresos, más confianza genera SAP en el mercado.

Además, SAP sigue beneficiándose del contexto general del sector tecnológico. Aunque no tiene el “hype” de otras compañías más orientadas a consumo o IA pura, sí está bien posicionada en el ámbito empresarial, especialmente en automatización, procesos y gestión de datos. Esto hace que tenga un perfil más estable dentro del sector.

También es importante tener en cuenta que el mercado sigue muy pendiente de los resultados y de la ejecución de esa transición. SAP está en un punto en el que ya no se le mide solo por lo que es hoy, sino por lo que puede llegar a ser como empresa cloud. Y eso genera una mezcla interesante: por un lado, expectativas altas; por otro, cierta exigencia en cada resultado que presenta.

En cuanto al comportamiento general, se sigue viendo cierta sensibilidad a factores macroeconómicos, especialmente todo lo relacionado con tipos de interés y expectativas de crecimiento. Como muchas empresas tecnológicas, SAP reacciona bastante a este tipo de noticias.

Si tengo que dar una opinión honesta sobre el futuro de los IDocs en SAP, no creo que estemos ante una tecnología que vaya a desaparecer. Más bien al contrario. Los IDocs han demostrado durante décadas que son una solución extremadamente robusta para integraciones y eso en entornos empresariales tiene un valor enorme. No es casualidad que sigan utilizándose en miles de sistemas productivos a día de hoy.

De hecho, si algo caracteriza a los IDocs es su fiabilidad y su trazabilidad. Pocas cosas en SAP ofrecen la capacidad de seguimiento que tienen las transacciones clásicas como WE02 o WE05. Poder ver el estado de un mensaje, su contenido, los errores, los reintentos… todo en un mismo sitio, es algo que en muchos escenarios modernos no es tan evidente. Y eso, cuando estás en un proyecto real con problemas de integración, marca una diferencia importante.

Ahora bien, que no vayan a desaparecer no significa que vayan a seguir siendo la opción principal en el futuro. El contexto tecnológico ha cambiado mucho. Cada vez más empresas están adoptando modelos de integración basados en APIs REST, arquitecturas desacopladas y comunicación en tiempo real. Y SAP, con su apuesta por BTP e Integration Suite, está claramente alineándose con ese enfoque.

Aquí es donde aparece una situación interesante. SAP no está eliminando los IDocs, sino que los está integrando dentro de su nuevo ecosistema. El hecho de que sigan existiendo en Integration Suite o que puedan utilizarse en entornos cloud indica que siguen siendo una pieza relevante dentro de la arquitectura. Esto plantea una pregunta que cada vez es más habitual en proyectos: ¿los IDocs encajan dentro del concepto de clean core o son parte del modelo legacy que hay que evitar?

La respuesta no es del todo sencilla. Por un lado, los IDocs forman parte del estándar de SAP, están soportados y siguen evolucionando dentro del ecosistema. Pero por otro, las nuevas arquitecturas promueven el uso de APIs, eventos y servicios más desacoplados. Es decir, los IDocs no desaparecen, pero tampoco son el centro de la estrategia futura.

Esto lleva a otra duda muy práctica que aparece en muchos proyectos. Cuando se plantea una nueva integración, ¿qué tiene más sentido? ¿Reutilizar un IDoc existente o diseñar una API REST desde cero con su propio modelo de datos?

Sobre el papel, la API REST parece la opción más moderna. Está alineada con las arquitecturas actuales, es más flexible y encaja mejor con el concepto de clean core. Sin embargo, cuando se analiza en detalle, muchas veces el trabajo que hay detrás es muy similar al de un IDoc. Hay que definir estructuras, mapear campos, gestionar errores, controlar estados… en definitiva, resolver los mismos problemas que los IDocs llevan resolviendo años.

Además, hay un factor que muchas veces se pasa por alto: el ecosistema externo. Aunque una empresa decida exponer APIs, eso no significa que sus clientes o proveedores estén preparados para consumirlas directamente. En muchos casos siguen utilizando estándares EDI o formatos específicos, lo que implica que seguirá siendo necesario un intermediario o una capa de transformación. Es decir, el problema de fondo no desaparece, simplemente cambia la tecnología que se utiliza para resolverlo.

Por eso, la decisión entre IDoc o API no es tanto una cuestión técnica como de contexto. Depende del cliente, de sus sistemas, de sus partners, del tipo de integración y del grado de madurez tecnológica. En algunos casos tendrá sentido seguir utilizando IDocs por su estabilidad y estandarización. En otros, será más lógico apostar por APIs y arquitecturas más modernas.

Lo que sí parece claro es la tendencia a medio y largo plazo. Probablemente veremos una reducción progresiva del uso de IDocs en nuevas integraciones externas, donde las APIs y los eventos irán ganando protagonismo. Sin embargo, dentro del core de SAP seguirán teniendo un papel importante durante muchos años, como mecanismo interno y como base de muchas integraciones existentes.

En definitiva, los IDocs no van a morir, pero sí van a cambiar su rol. Pasarán de ser el protagonista principal de las integraciones a convertirse en una pieza más dentro de un ecosistema más amplio y moderno. Y aunque muchos consultores han tenido sus momentos de lucha con ellos, también es cierto que cuando funcionan correctamente son una herramienta muy potente y difícil de sustituir completamente.

Por eso, más que hablar de desaparición, tiene más sentido hablar de evolución. SAP no suele eliminar tecnologías de forma radical, sino que las integra dentro de nuevos modelos. Y los IDocs, por todo lo que representan y por todo lo que aún soportan, probablemente seguirán formando parte del paisaje SAP durante bastante tiempo.

El sistema va lento. Los usuarios llaman. Todos miran al BASIS. ¿Por dónde empiezas?

La mayoría abre SM50 ( el monitor de work processes del servidor local ) y se queda ahí. Error. SM66 es la versión global: muestra todos los work processes de todos los servidores de aplicación a la vez, sin tener que entrar instancia por instancia. En un golpe de vista ves qué usuario, qué programa y qué proceso está consumiendo recursos en todo el landscape.

Lo que hay que buscar en SM66 en un momento de crisis: work processes en estado PRIV ( han consumido toda la memoria extendida y están bloqueando al resto ) y procesos en estado Running con un tiempo de ejecución anormalmente alto que no avanzan.

Una vez identificado el proceso sospechoso, el segundo paso es ST03N el Workload Monitor. Aquí están las reglas de oro: si el tiempo de base de datos supera el 40% del tiempo de respuesta, el problema está en SQL. Si el roll wait time supera 200ms, el problema está en RFC. Si el load time supera 50ms, el buffer de programas es demasiado pequeño. Cada síntoma tiene su diagnóstico y ST03N te da el mapa.

Hay algo que suele pasar cuando trabajas con IDocs desde la parte funcional: muchas veces se perciben como algo muy técnico, casi como si fueran “territorio ABAP”. Y en parte es normal, porque la estructura puede parecer compleja al principio. Pero si te paras a mirarlos con calma, en realidad tienen bastante lógica.

Un IDoc no deja de ser una representación del proceso de negocio. La cabecera te dice qué documento estás tratando, las posiciones qué se está moviendo, los datos organizativos cómo se procesa y los partners quién interviene. Cuando empiezas a verlo así, deja de ser un bloque de datos difícil de interpretar y empieza a tener sentido dentro del flujo.

Esto ayuda mucho cuando hay que analizar un error o revisar un comportamiento. En lugar de ver simplemente que “algo no cuadra”, puedes empezar a identificar puntos concretos: un dato que viene diferente a lo esperado, un partner que no corresponde, una condición que no encaja con el proceso definido… pequeños detalles que muchas veces explican todo.

Un truco muy útil es trabajar siempre con un IDoc correcto como referencia. Comparar uno que funciona bien con otro que no lo hace suele dar mucha información en poco tiempo. A veces la diferencia está en un campo muy concreto, y verlo así ayuda a entender mejor qué está pasando.

También es importante no quedarse solo en el propio IDoc. Entender de dónde viene, qué sistema lo genera y qué espera el sistema receptor aporta mucho contexto. Porque en muchas ocasiones el IDoc refleja lo que ha pasado antes, más que ser el origen del problema.

Cuando empiezas a trabajar con esta visión, cambia bastante la forma de analizar. Dejas de ver el IDoc como algo puramente técnico y empiezas a verlo como parte del proceso. Y ahí es donde realmente se le saca partido desde la parte funcional.

Hay funciones en SAP que pasan bastante desapercibidas… hasta que un día las necesitas y te salvan la vida.

Una de ellas es BAPI_USER_GET_DETAIL (muchas veces la recordamos como “la BAPI para sacar datos de usuario”… aunque el nombre nunca nos lo aprendamos del todo 😅).

Esta BAPI sirve, básicamente, para obtener toda la información relevante de un usuario en SAP.

Y cuando digo “toda”, es bastante completa.

Permite recuperar datos como:

Es decir, es una forma estándar y limpia de consultar cómo está definido un usuario en el sistema sin tener que ir navegando por varias tablas o transacciones.

Y aquí está una de las claves importantes.

En lugar de hacer SELECTs directos sobre tablas como USR02, AGR_USERS o similares, esta BAPI ya te da la información estructurada y controlada. Esto no solo es más limpio, sino que además es la forma recomendada por SAP para acceder a este tipo de datos.

En proyectos reales esto se usa más de lo que parece.

Por ejemplo:

cuando necesitas validar permisos
cuando quieres mostrar información de usuario en un desarrollo
cuando haces integraciones con sistemas externos
o incluso para auditorías y revisiones de accesos

También es bastante útil cuando estás desarrollando herramientas internas o reportes que necesitan saber quién tiene qué dentro del sistema.

Otro punto interesante es que, al ser una BAPI estándar, se puede utilizar fácilmente en distintos contextos:

Lo que la hace bastante versátil.

Eso sí, como siempre en SAP, hay que tener en cuenta autorizaciones. No todos los usuarios pueden acceder a toda la información de otros usuarios, así que dependiendo del contexto puede haber limitaciones.

En resumen, es una de esas funciones que no usas todos los días… pero cuando la necesitas, agradeces que exista.

De hecho, es de las típicas que cuando la descubres piensas:
“vale, esto me habría ahorrado tiempo hace unos meses” 😄

Si llevamos este punto al terreno del liderazgo, hay algo que encaja perfectamente con todo lo que hemos comentado: en SAP, muchas decisiones técnicas son en realidad decisiones de criterio… y de equipo.

Existe una máxima bastante clara dentro del ecosistema SAP: cuanto más estándar, mejor. Y los IDocs son un buen ejemplo de ello. Son una solución probada, conocida, documentada y con un comportamiento muy estable.

No generan incertidumbre y permiten a cualquier equipo SAP entender rápidamente qué está pasando.

Pero lo interesante no es solo la tecnología en sí, sino lo que implica elegirla.

Cuando un líder técnico decide utilizar un IDoc estándar, no está simplemente eligiendo una forma de integración. Está tomando una decisión que afecta directamente al equipo: reduce la complejidad, facilita el mantenimiento, acelera la entrega y evita problemas futuros. En muchos casos, eso tiene más valor que apostar por una solución más moderna pero menos controlada.

Aquí es donde entra el verdadero rol del liderazgo.

Porque en muchos equipos aparece una tendencia bastante común: asociar lo moderno con lo mejor. APIs, eventos, arquitecturas cloud… todo eso es importante y necesario, pero no siempre es la mejor opción en todos los contextos.

Un buen líder tiene que saber cuándo aplicar cada cosa.

Tiene que ser capaz de decir: “en este caso, lo estándar es suficiente y es la mejor decisión”. Y también, en otros casos, empujar hacia soluciones más modernas cuando realmente aportan valor.

Esto no va de elegir entre IDocs o APIs como si fueran bandos opuestos.

Va de tener el criterio suficiente para entender el contexto: el cliente, el equipo, el tipo de integración, el ecosistema externo y la evolución futura del sistema.

Y aquí aparece otro punto clave en la gestión de equipos: evitar la sobreingeniería.

Muchas veces, en nombre de la modernización, los equipos tienden a complicar soluciones que podrían resolverse de forma mucho más simple. Esto no solo afecta a la arquitectura, sino también al propio equipo, que acaba trabajando en soluciones más difíciles de mantener, entender y evolucionar.

Ni quedarse anclado en “siempre lo hemos hecho así”, ni caer en “todo tiene que ser nuevo”.

En consultoría SAP esto se ve muy claro.
Los proyectos no se recuerdan por los días tranquilos, sino por los momentos en los que algo falla, hay presión o toca tomar decisiones rápidas.

Es ahí donde realmente se ve el nivel de un consultor… y también de un equipo.

Y hasta aquí el boletín de esta semana.

Hoy nos hemos metido en un clásico de SAP que todos conocemos… aunque algunos prefieran no recordarlo: los IDocs.

Porque al final, más allá de segmentos, WE02 y mensajes en rojo, los IDocs son mucho más que una tecnología antigua. Son una de esas piezas que llevan años funcionando en silencio… mientras todo lo demás cambia a su alrededor.

Lo curioso es que, aunque hablemos de APIs, cloud y arquitecturas modernas, ahí siguen. Firmes. Resistiendo. Como ese desarrollo estándar que nadie se atreve a tocar porque “funciona”.

Gracias por dedicar unos minutos a leerlo y por seguir formando parte de esta comunidad, donde no solo hablamos de SAP… sino también de esas cosas que todos usamos, todos criticamos… y que al final todos seguimos necesitando 😄

La semana que viene volveremos con más experiencias reales, algún tema interesante y seguro que otra reflexión de esas que te hacen pensar “esto me ha pasado a mí”.

Nos leemos en el próximo boletín.

Un abrazo 👋