Si crees que una auditoría de licencias es un trámite aburrido, deja que te cuente el caso que puso a temblar a todos los departamentos de compras del mundo SAP.

En 2017, la multinacional de bebidas Diageo (los de Johnnie Walker, Guinness y compañía) se llevó el susto de su vida. Habían conectado su sistema SAP con Salesforce para que comerciales y clientes pudieran gestionar pedidos. Nada raro, ¿verdad? Pues SAP interpretó que todas esas personas que tocaban datos de SAP a través de Salesforce, sin entrar directamente al sistema, también necesitaban licencia de usuario nombrado. A eso se le llama acceso indirecto (indirect access).

¿La factura que reclamó SAP? Alrededor de 54 millones de libras en licencias adicionales. Por usar un sistema que Diageo creía que ya tenía pagado.

Y lo más fuerte: el caso acabó en los tribunales de Reino Unido y, en febrero de 2017, el juez le dio la razón a SAP. El uso indirecto contaba. La sentencia mandó una onda expansiva por toda la comunidad: de repente, cualquiera que tuviera SAP conectado a una web, a una tienda online, a un CRM o a un sistema externo (o sea, prácticamente todos) se dio cuenta de que podía tener una bomba de relojería en el contrato.

SAP acabó suavizando el golpe años después con un modelo nuevo de “digital access” basado en documentos en lugar de en usuarios. Pero el mensaje ya había calado: la auditoría de licencias no es un trámite. Es el día en que el que te vendió el producto viene a revisar cuánto más le debes.

Semana de resultados, y de las que dan para hablar. Tras publicar las cifras del Q3 el día 21 (ese primer trimestre por encima de los 10.000 millones), la acción llegó a subir con ganas, en torno a un 4% en caliente por el buen dato de nube. Pero como suele pasar, el entusiasmo se moderó rápido.

A cierre de Xetra del 23 de octubre, SAP quedaba en 214,40 €, y el fin de semana cotizaba sobre los 212,93 €, con una bajada suave del -0,69%. Es decir: resultados excelentes, reacción correcta pero sin euforia. El mercado ya daba por descontada buena parte de la fiesta de la nube, y “cumplir lo esperado” no siempre basta para que la acción se dispare.

Los analistas, en cambio, siguen animados: Goldman Sachs subió su precio objetivo hasta los 258 €, bastante por encima de la cotización actual, con el argumento de siempre (el backlog de nube de 24.100 millones da visibilidad de ingresos para rato). La acción se mueve razonablemente por debajo de su máximo de las últimas 52 semanas, que rondó los 244 €, así que recorrido teórico hay.

Traducido al idioma del consultor: SAP gana más dinero que nunca, la nube tira como un tren, y aun así la acción se lo toma con calma. A veces el mercado es como ese cliente que, hagas lo que hagas en el go-live, te responde con un “bueno, está bien”.

Mientras hablamos de auditorías, SAP presentó sus resultados del tercer trimestre de 2026 (el pasado 21 de octubre) y dejó un titular redondo: por primera vez en su historia, SAP ha superado los 10.000 millones de euros de ingresos en un solo trimestre (unos 10.270 millones). El gigante de Walldorf sigue engordando.

¿De dónde viene el empuje? De la nube, como viene siendo costumbre. Los ingresos cloud crecieron un 26% interanual, y el dato que de verdad miran los analistas, la cartera de pedidos de nube (el current cloud backlog), se fue hasta los 24.100 millones de euros, un 28% más. Traducido: no es solo lo que SAP factura hoy, es todo lo que ya tiene firmado para facturar mañana. SAP incluso subió sus previsiones de nube para el año.

Y aquí está lo que esto significa para el consultor de a pie, más allá del comunicado triunfalista. Todo lo que vemos en los proyectos (el empuje incesante hacia RISE, hacia GROW, hacia S/4HANA Cloud, la presión por migrar, la jubilación de productos como ByDesign) no es casualidad ni capricho: es exactamente esta estrategia traducida a números. Cada punto de ese 26% de crecimiento cloud sale de clientes que están migrando, y de cada migración salimos trabajando nosotros. La estrategia de SAP y nuestra carga de trabajo van de la mano.

Lo que no sale en la nota de prensa es la otra cara: cuanto más crece la nube, más recurrente es el ingreso para SAP y más atado queda el cliente al modelo de suscripción. Más backlog para ellos es, muchas veces, menos margen de maniobra para el cliente. Pero eso, claro, no cabe en el titular.

¿Crees que este crecimiento de la nube se nota ya en tus proyectos, o sigues viviendo en el mundo On-Premise mientras Walldorf hace caja?

En SAP, la palabra “auditoría” no significa una sola cosa, y confundir los tipos es lo que hace que la gente le tenga un miedo difuso en lugar de un respeto concreto. Vamos a ponerle nombre y apellidos a cada una, porque a un consultor le tocan todas tarde o temprano.

La primera, y la que más miedo da, es la auditoría de licencias de la propia SAP. Una vez al año, SAP mide tu sistema (la medición del sistema, el famoso proceso de System Measurement) y comprueba si usas más de lo que pagaste: usuarios nombrados de más, motores que no tenías contratados y, sobre todo, el acceso indirecto del que hablo en el Dato Curioso. Y aquí seré directo: esto es, en parte, una herramienta comercial disfrazada de cumplimiento. No digo que SAP no tenga derecho a cobrar lo que le corresponde. Digo que la misma empresa que te vende, te mide, y del resultado de esa medición sale una conversación de ventas. Juez y parte en la misma mesa. Que cada uno saque sus conclusiones.

La segunda es la auditoría de seguridad y autorizaciones, la de la segregación de funciones (SoD). Aquí el auditor no mira cuánto pagas, mira quién puede hacer qué. Que la misma persona no pueda dar de alta un proveedor y además pagarle, por ejemplo, porque eso es la puerta abierta al fraude. En empresas cotizadas esto va ligado a normativas serias, y es trabajo recurrente y bien pagado para el consultor de seguridad y GRC.

Y la tercera es la auditoría financiera externa, la de los de traje de las grandes firmas. Esos no vienen a por SAP, vienen a por las cuentas, pero como las cuentas viven en SAP, acaban pidiéndote accesos, extracciones de datos y explicaciones de por qué tal campo está configurado así. Al consultor le toca hacer de traductor entre el sistema y la gente que firma el informe.

¿Y dónde está el negocio de todo esto, que es lo que de verdad me parece interesante? En que alrededor del miedo a la auditoría ha crecido una industria entera. Hay herramientas de gestión de activos de software (SAM) que cuestan un dineral y que existen solo para que no te pille el toro en la medición. Hay consultoras especializadas únicamente en defenderte de la auditoría de licencias, en optimizar tu posición antes de que SAP mida. Hay proyectos enteros de GRC que se venden con el argumento de “que viene el auditor”. Es decir: el miedo mueve tanto dinero como el propio producto.

Mi postura, después de ver unas cuantas: la auditoría no es el enemigo. El enemigo es llegar a ella sin haber mirado tú primero. El cliente que revisa sus propias licencias y sus propios roles una vez al año, por su cuenta, llega a la auditoría tranquilo y negocia. El que no las ha mirado nunca llega con la soga al cuello y paga lo que le pidan. La diferencia entre una cosa y otra no es suerte: es haber dedicado unas semanas al año a mirarse al espejo antes de que venga alguien a mirarte a ti.

Y para nosotros, los consultores, hay una oportunidad clarísima ahí. Entender de licencias, de acceso indirecto, de segregación de funciones, te convierte en la persona a la que el cliente llama cuando llega la carta. Y esa llamada, créeme, se paga muy bien.

¿Te ha pillado alguna vez una auditoría de SAP de cerca? ¿Fue la de licencias, la de seguridad o la de los de traje? Cuéntame cómo acabó.

Escena de todos los días en cualquier proyecto: un usuario te dice “me sale que no tengo autorización” y tú, por inercia, le pides que ejecute la SU53. El problema es que la SU53 solo te enseña el último chequeo de autorización que falló, y en cuanto el usuario hace otra cosa, esa foto se pierde. Para procesos con varios chequeos encadenados, la SU53 se queda corta y te deja adivinando. Hay una herramienta muchísimo mejor y mucha gente sigue sin usarla: la STAUTHTRACE.

STAUTHTRACE es la traza del sistema enfocada específicamente a chequeos de autorización. En lugar de la foto única de la SU53, te graba todos los AUTHORITY-CHECK que se ejecutan mientras el usuario reproduce el problema, en tiempo real, y te dice exactamente qué objeto de autorización se comprobó, con qué valores, y cuáles pasaron (RC=0) y cuáles fallaron (RC=4).

El flujo en un caso real es sencillo: activas la traza filtrando por el usuario concreto que tiene el problema (importante filtrar, que si no capturas medio sistema), le pides que reproduzca la acción que le falla, paras la traza y la evalúas. Ahí ves la secuencia completa de chequeos, y el que salió con return code 4 es tu culpable. Con eso vas al rol, añades el objeto que falta con sus valores exactos, y resuelto.

¿Por qué lo meto en el boletín de hoy? Porque esta es, literalmente, la herramienta que usas cuando preparas una auditoría de seguridad o cuando el auditor te ha dejado una lista de accesos que hay que ajustar. Entender qué objetos de autorización se chequean de verdad en cada transacción es la diferencia entre construir roles con criterio y construirlos a base de prueba y error (o peor, a base de dar SAP_ALL “temporalmente” y que se quede para siempre, que es justo lo que el auditor va a clavarte).

Si hay una cuenta que todo auditor abre nada más sentarse, es la GR/IR (la cuenta puente de recepción de mercancía / recepción de factura, la que SAP determina con la clave WRX). Y es, a la vez, una de las que peor se gestionan en la mayoría de las empresas. Vamos a entender por qué.

La GR/IR es una cuenta transitoria que vive entre logística y finanzas. Cuando haces la entrada de mercancía de un pedido (recibes el material), SAP hace un apunte: carga la cuenta de stock y abona la GR/IR. Luego, cuando llega la factura del proveedor y la contabilizas, pasa lo contrario: carga la GR/IR y abona al proveedor. Si todo cuadra (recibiste exactamente lo que te facturaron, al precio que tocaba), la GR/IR queda a cero para esa posición. Es su estado natural: entra y sale, saldo neto cero.

El problema es lo que pasa cuando no cuadra. Recibes 100 unidades pero te facturan 98. O te llega la mercancía pero la factura no aparece nunca. O hay una diferencia de precio. Cada una de esas descuadres deja un residuo en la GR/IR. Y como nadie lo vigila, esos residuos se van acumulando mes a mes, año a año, hasta que la cuenta GR/IR tiene un saldo que nadie sabe explicar. Ahí es cuando llega el auditor, ve ese saldo abultado, y pregunta: “¿y esto qué es?”. Y el silencio que sigue no suele ser agradable.

El error clásico es tratar la GR/IR como una cuenta que se gestiona sola. No se gestiona sola. Hay que analizarla y limpiarla periódicamente con la transacción MR11 (GR/IR Clearing), que precisamente sirve para regularizar esas posiciones que llevan abiertas demasiado tiempo porque la mercancía o la factura ya no van a llegar. Si no se hace MR11 con regularidad, la cuenta se convierte en un vertedero contable.

La recomendación: monta un control periódico de la antigüedad de las partidas de la GR/IR (al menos trimestral), identifica lo que lleva meses abierto sin movimiento, y aclara con logística y compras qué pasó con cada caso antes de regularizar con MR11. Es trabajo aburrido, sí. Pero es justo lo que te evita la conversación incómoda con el auditor.

Como hoy hablamos de auditorías, toca la función que es, literalmente, la pista de auditoría de SAP hecha código. Porque SAP registra los cambios de muchísimos objetos (maestros de clientes, proveedores, materiales, pedidos…) en dos tablas: CDHDR (las cabeceras: quién, cuándo, qué objeto) y CDPOS (el detalle: qué campo, valor antiguo, valor nuevo). Son los documentos de modificación, el “quién movió esto” que todo auditor pide tarde o temprano.

El error habitual es lanzarse a hacer SELECT directos contra CDHDR y CDPOS. Funciona, pero es incómodo y te obliga a conocer la estructura por dentro. SAP tiene un módulo de función pensado justo para esto: CHANGEDOCUMENT_READ_HEADERS, que te lee las cabeceras de cambios de un objeto concreto de forma limpia.

La clave está en el OBJECTCLASS: es el nombre del objeto de documento de modificación, y cada área tiene el suyo (por ejemplo KRED para proveedores, DEBI para clientes, MATERIAL para el maestro de materiales). Con la cabecera ya tienes el quién y el cuándo; si quieres el detalle campo a campo (valor antes/después), tiras luego de CHANGEDOCUMENT_READ_POSITIONS.

¿Dónde lo usas de verdad? En cualquier informe de auditoría interno (“dame todos los cambios del maestro de proveedores del último trimestre y quién los hizo”), en controles de SoD, o cuando el cliente te pide trazabilidad de quién modificó un dato sensible. En lugar de decir “eso habría que mirarlo en base de datos”, le montas un informe en media hora.

Si llevas un equipo o tienes peso en una cuenta, hay una conversación que más vale tener tú a tu ritmo que cuando llega impuesta por un correo de SAP con asunto “System Measurement”. Porque la auditoría, cuando llega de fuera, llega con fecha y con prisa. Y la prisa, en licencias, siempre la pagas tú.

El error más común que veo en los responsables no es hacer algo mal. Es no mirar nunca. El sistema lleva años funcionando, se van dando de alta usuarios, se conectan aplicaciones externas, se copian roles “temporalmente” que se quedan para siempre… y nadie hace la foto de cómo está la cosa de verdad. Hasta que alguien de fuera la hace por ti, y entonces ya no es una foto, es una factura.

Así que el tip es incómodo pero sencillo: conviértete en tu propio auditor una vez al año. Y te doy tres cosas concretas que puedes poner en marcha esta misma semana sin herramientas carísimas.

La primera: haz una revisión de usuarios. Cuántos usuarios nombrados tienes realmente activos, cuántos están asignados a un tipo de licencia que no corresponde con lo que esa persona hace de verdad, y cuántos llevan meses sin entrar y siguen consumiendo licencia. Esa limpieza, por sí sola, ya suele cambiar el número de la medición.

La segunda, la que casi nadie mira hasta que es tarde: mapea tus accesos indirectos. Haz una lista de todo lo que está conectado a tu SAP sin ser SAP (webs, CRM, tiendas online, sistemas de terceros, integraciones). Cada una de esas conexiones es un punto donde el acceso indirecto puede morder. Si no sabes cuántas tienes, no sabes tu exposición real, y el que no conoce su exposición no puede negociar nada.

La tercera: revisa la segregación de funciones en los roles críticos. No hace falta un proyecto de GRC completo para empezar. Empieza por lo evidente: quién puede crear un proveedor y además pagarle, quién puede modificar un maestro y además aprobar su uso. Esas combinaciones peligrosas son las primeras que mira cualquier auditor, y las primeras que te dejan en evidencia.

El coste de no hacer nada aquí no se ve hoy. Se ve el día que llega la carta y descubres que llevas tres años regalándole a SAP argumentos para una factura que podrías haber evitado con una revisión anual de dos semanas.

El tip, resumido: la mejor defensa ante una auditoría es haberte auditado tú primero, sin prisa y sin nadie mirándote. El espejo da pereza, pero sale mucho más barato que la sorpresa.

No hay frase que resuma mejor el espíritu de una auditoría. Todo el negocio de las auditorías en SAP se construye sobre esa idea: da igual lo que diga el contrato, lo que prometa el cliente o lo que jure el equipo, alguien va a venir a comprobarlo. Y la lección para nosotros es la misma: fíate de que tu sistema está bien de licencias y de roles… pero verifícalo tú primero, antes de que lo haga SAP por ti. Confiar está bien. Verificar sale más barato.

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

Hoy hemos hablado de algo que muchas veces vemos todos los días… pero que no siempre analizamos con calma.

Y cuanto más tiempo pasas en él, más te das cuenta de que SAP no va solo de tecnología.

Va de personas, de procesos, de negocio… y muchas veces de saber adaptarse constantemente a cómo cambia todo.

Gracias por dedicar unos minutos a leerlo y por seguir formando parte de esta pequeña comunidad donde intentamos hablar de SAP de una forma un poco más cercana y real.

La semana que viene volveremos con más historias de proyectos, algún tema interesante y seguramente otra de esas situaciones que todos hemos vivido alguna vez trabajando en este ecosistema.

Nos leemos en el próximo boletín 👋

Envíame un correo sobre un tema que quieras que salga en la newsletter a [email protected] o contesta a este email.