¿En tu equipo las conversaciones se dispersan entre emails, chats y
reuniones?

En GROUPmee, conectamos Asana para sincronizar proyectos, tareas y
actualizaciones directamente con tus grupos de trabajo, para que
nadie pierda información, los cambios se entiendan al momento y las
decisiones se tomen más rápido.

Índice del boletín

• Dato curioso

• Ultimas noticias

• Información en bolsa

• Mi opinión

• Tip ABAP( Técnico )

• SAP Funcional

• Función de la Semana

• Frase del Día

• Gracias por leer

🔍 Dato Curioso

En muchos proyectos SAP ocurre algo muy llamativo: las personas que mejor conocen el proceso de negocio no siempre son las que mejor se adaptan al sistema. De hecho, es bastante habitual que los llamados key users (expertos en producción, logística, finanzas o en lo que sea) se muevan con absoluta soltura en el proceso real, pero se bloqueen cuando tienen que trabajar dentro de SAP.

No es falta de capacidad ni de interés. Es que conocer el proceso no significa conocer cómo ese proceso se traduce dentro de un sistema tan estructurado. SAP obliga a seguir una secuencia, a respetar datos maestros, estados, validaciones y dependencias que no siempre existen en el día a día operativo.

Esto lo he visto muchas veces y, de hecho, lo he vivido de cerca con amigos y conocidos: personas brillantes en planta, en almacén o en logística, capaces de detectar un problema en segundos… y que, sin embargo, se pierden cuando tienen que ejecutar ese mismo proceso en SAP. El sistema no les falla, simplemente les exige pensar el proceso de otra forma.

Ahí es donde empiezan muchos de los problemas que tratamos en este boletín. El sistema cumple con lo que se ha diseñado, pero el uso diario se vuelve errático porque la lógica de negocio antigua sigue mandando. No por mala fe, sino porque nadie les enseñó realmente a pensar el proceso desde la lógica del sistema.

Por eso, en muchos proyectos, el mayor riesgo no está en la parametrización ni en el desarrollo, sino en asumir que saber hacer el trabajo equivale a saber hacerlo en SAP. Y no siempre es así.

No se trata de señalar culpables, sino de entender que un proyecto no termina cuando el sistema funciona, sino cuando las personas lo usan como se diseñó. Porque cuando eso no ocurre, el sistema cumple… pero el uso diario lo pone en jaque.

📰 Ultimas noticias

Por qué la IA específica del cliente supera a la IA genérica

En los últimos meses se habla mucho de inteligencia artificial, pero no toda la IA sirve para lo mismo. SAP lo deja claro en una idea muy concreta: la IA realmente útil para las empresas no es la genérica, sino la que entiende el contexto del cliente.

La diferencia es clave. La IA genérica es buena para responder preguntas abiertas, generar textos o ayudar de forma transversal. Pero cuando hablamos de procesos empresariales —finanzas, logística, compras, producción o recursos humanos— el valor no está en “saber mucho”, sino en saber exactamente cómo funciona tu negocio.

Uno de los grandes puntos que destaca SAP es que la IA específica del cliente trabaja sobre datos reales y estructurados, no sobre información genérica de internet. Esto significa que las decisiones, recomendaciones y automatizaciones se basan en datos maestros, históricos de la empresa, reglas de negocio y procesos reales. Y eso cambia completamente el resultado.

Otro aspecto fundamental es la confianza. En entornos empresariales no basta con que la IA acierte “más o menos”. Tiene que ser explicable, trazable y segura. Cuando la IA está integrada en el sistema y conoce el proceso de principio a fin, es mucho más fácil entender por qué propone algo, qué datos ha utilizado y qué impacto tendrá esa decisión.

SAP también insiste en algo muy importante: la IA no debería ser un elemento externo que “opina”, sino una parte integrada del flujo de trabajo. Cuando la IA está incrustada en los procesos, puede actuar en el momento adecuado: alertar antes de un problema, sugerir una acción correcta o evitar errores antes de que ocurran. No se trata de usar IA por moda, sino de usarla donde realmente aporta valor.

Además, la IA específica del cliente evoluciona con la empresa. A medida que los procesos cambian, los datos crecen y el negocio madura, la IA aprende dentro de ese contexto. No aplica reglas genéricas, sino que se adapta a la realidad de cada organización, algo especialmente crítico en empresas con procesos complejos o altamente regulados.

En definitiva, el mensaje es claro: la IA que marca la diferencia en la empresa no es la más llamativa, sino la más contextualizada. La que entiende el negocio, respeta los procesos y ayuda a tomar mejores decisiones sin romper el equilibrio operativo. No es una revolución ruidosa, es una mejora silenciosa… pero muy poderosa.

Una vez más, la clave no está en la tecnología en sí, sino en cómo y dónde se aplica. Y en el mundo empresarial, el contexto lo es todo.

💹 Información en Bolsa

SAP sufre la mayor caída de su acción en años por preocupaciones sobre su negocio en la nube

SAP SE vivió recientemente una jornada complicada en los mercados financieros, con su acción cayendo hasta un 15–17 % en un solo día, la mayor caída registrada desde 2020 tras una actualización de previsiones de crecimiento en su negocio cloud que no cumplió con las expectativas de algunos analistas e inversores.

La compañía pronosticó un crecimiento de ingresos en la nube para 2026 de entre 23 % y 25 %, ligeramente por debajo de lo que muchos mercados esperaban tras años de impulso fuerte en este segmento. Aunque los ingresos globales, incluidos los de nube, siguen creciendo y la empresa mantiene una base sólida de clientes y contratos en cartera, la reacción del mercado refleja la intensa presión que enfrentan las grandes tecnológicas para acelerar sus tasas de crecimiento, especialmente en servicios cloud y herramientas impulsadas por IA.

El CEO Christian Klein ha subrayado que SAP está enfocada en su estrategia a largo plazo, integrando IA en sus soluciones y consolidando su presencia en la nube, tolerando las fluctuaciones del mercado y centrando inversiones en tecnologías emergentes y en su expansión global.

🚀 Mi opinión

Hay una situación que se repite más de lo que nos gustaría en proyectos SAP: el sistema hace exactamente lo que tiene que hacer… pero aun así todo empieza a torcerse. Y no porque SAP falle, sino porque las expectativas del usuario y la lógica del sistema nunca llegaron a alinearse del todo.

Muchas veces el usuario final o el negocio pide unas especificaciones que, desde su punto de vista, funcionan perfectamente. Y tiene sentido: conoce su día a día, su módulo, su proceso y lo que necesita para sacar el trabajo adelante. El problema aparece cuando ese conocimiento no va acompañado de una comprensión real de cómo funciona ese proceso dentro de SAP, no dentro de su empresa, sino dentro del sistema como tal.

Aquí se da una situación muy común: personas que venían de un sistema anterior —o de procesos manuales muy asentados— y esperan que SAP se adapte lo máximo posible a eso que ya conocían. No porque quieran complicar nada, sino porque es su zona de confort. El riesgo está en que SAP no es una versión mejorada del sistema X. Tiene una lógica distinta, una secuencia clara y unas reglas que no siempre coinciden con lo que se hacía antes.

Ahí es donde entra el papel del consultor. No para replicar el pasado, sino para mejorar el proceso y el flujo, siempre que el estándar lo permita. Y muchas veces lo permite, aunque sea de una forma diferente a como el usuario lo hacía manualmente. El problema es que muchos usuarios no saben realmente de SAP; saben de cómo funciona su empresa. Y eso, sin una buena explicación, acaba siendo una fuente constante de fricción.

Cuando esa diferencia no se gestiona bien, empiezan los “sabotajes” involuntarios. No por mala fe, sino por desconocimiento. El sistema empieza a usarse esperando un comportamiento que nunca se acordó, o que nunca fue posible, y cualquier desviación se percibe como un error.

Las pruebas juegan aquí un papel clave. No basta con pedirle al usuario que pruebe. Hay que explicarle primero cómo funciona el proceso estándar en SAP, y después cómo va a funcionar el proceso adaptado, si es que hay adaptación. Y todo eso tiene que quedar claro y por escrito: qué se dijo, qué se acordó y qué se ha pagado. Porque si no, llegan los clásicos “ya que estamos…”, “esto no era así”, “yo entendí otra cosa” o “esto no funciona como esperaba”.

El problema no es que el usuario pregunte o dude. El problema es no haber dejado cerrada la nueva lógica de negocio, ni haber comprobado que realmente se ha entendido la diferencia entre lo antiguo y lo nuevo. SAP no falla por no parecerse al sistema anterior; falla cuando se le exige comportarse como algo que nunca fue.

Por eso, en muchos proyectos, el conflicto no está en la parametrización ni en el desarrollo, sino en no haber asegurado que todos hablaban el mismo idioma. Cuando eso no ocurre, el sistema cumple… pero el uso diario lo acaba poniendo contra las cuerdas.

🧠 Tip ABAP

Durante años, en ABAP hemos resuelto decisiones simples con cadenas de IF…ELSEIF…ELSE que funcionan, sí… pero que hacen el código más largo, más ruidoso y menos expresivo.

Forma “clásica” (la de toda la vida)

IF lv_status = 'A'.
  lv_text = 'Activo'.
ELSEIF lv_status = 'B'.
  lv_text = 'Bloqueado'.
ELSE.
  lv_text = 'Desconocido'.
ENDIF.

Nada incorrecto. Pero cuando estas decisiones se repiten mucho, el código empieza a crecer más de lo necesario.

Forma moderna con COND #( )

lv_text = COND string(
  WHEN lv_status = 'A' THEN 'Activo'
  WHEN lv_status = 'B' THEN 'Bloqueado'
  ELSE 'Desconocido'
).

En una sola expresión:

• asignas el valor

• haces la evaluación

• y dejas clara la intención del código

¿Por qué merece la pena usar COND?

COND #( ) no es solo “más moderno”, es más legible cuando:

• el resultado es una única variable

• hay varias condiciones simples

• no necesitas lógica compleja dentro de cada rama

Además:

• reduce líneas de código

• evita variables intermedias

• y hace que el código se lea casi como una frase

Regla práctica

Si solo estás asignando un valor según una condición, COND #( ) suele ser mejor opción que un IF completo.

Si necesitas lógica compleja, llamadas a métodos o efectos colaterales, entonces el IF sigue siendo tu amigo. No se trata de reemplazar todo, sino de usar la herramienta adecuada.

🧩 SAP Funcional

SAP SD: Incompletion Log en pedidos de ventas

En SAP SD existe una funcionalidad estándar muy potente para evitar errores aguas abajo en el proceso comercial: el Incompletion Log. Su objetivo es sencillo pero crítico: detectar y controlar documentos incompletos antes de que sigan avanzando.

El Incompletion Log permite definir qué campos son obligatorios en un pedido de ventas (o en otros documentos comerciales) y decidir qué ocurre si esos campos no están informados. SAP no bloquea por defecto, sino que avisa y controla, dejando claro al usuario qué falta y por qué el documento no puede continuar.

SPRO > SAP Reference IMG > Sales & distribution > Basic functions > Log of Incompletion items > Define Incompletion procedures.

Desde esta configuración puedes:

• definir procedimientos de incompletitud

• indicar campos obligatorios a nivel de cabecera, posición o reparto

• asignar estos procedimientos a tipos de documento de ventas

Ejemplo práctico

Un usuario crea un pedido de ventas sin informar correctamente:

• condiciones de precio

• fecha de entrega

• datos logísticos clave

El pedido se guarda, pero SAP lo marca como incompleto.
Mientras el Incompletion Log no esté resuelto:

• el documento no puede avanzar a entrega

• no se puede facturar

• el usuario ve claramente qué campo falta

Esto evita que los errores aparezcan tarde, cuando ya hay impacto en logística o finanzas.

Error habitual en proyectos

No activar el Incompletion Log “para no molestar al usuario”.
El resultado suele ser:

• pedidos que avanzan mal

• errores en facturación

• reprocesos manuales

• y la sensación de que el sistema falla

Cuando en realidad faltaban controles básicos.

Regla práctica

Si un dato es crítico para el proceso de ventas, debe validarse lo antes posible.
El Incompletion Log no está para bloquear, sino para proteger el proceso y al propio usuario.

🔎 Función de la Semana

HR_READ_INFOTYPE

HR_READ_INFOTYPE es una función estándar de SAP HCM que permite leer datos de infotypes de empleados de forma controlada y respetando la lógica de fechas, validez y autorizaciones de Recursos Humanos.

Es la forma correcta y recomendada de acceder a datos de personal, en lugar de hacer SELECTs directos sobre tablas PA*.

¿Qué problema resuelve?

En HR, los datos:

• tienen validez temporal

• pueden cambiar con el tiempo

• están protegidos por autorizaciones

• y no siempre se deben leer directamente de base de datos

Esta función se encarga de todo eso por ti.

Ejemplo típico de uso

Leer el infotype 0008 (Datos salariales) de un empleado:

CALL FUNCTION 'HR_READ_INFOTYPE'
         EXPORTING
*          TCLAS                 = 'A'
           pernr                 = wa_repdata-staff_id "PERNR- Personnel number
           infty                 = '0002'  "Info type
*          BEGDA                 = '18000101' "Begin date
*          ENDDA                 = '99991231' " End date
*          BYPASS_BUFFER         = ' '
*          LEGACY_MODE           = ' '
*        IMPORTING
*          SUBRC                 = 
         tables
           infty_tab             =  p0002
        EXCEPTIONS
          INFTY_NOT_FOUND       = 1
          OTHERS                = 2.

El resultado devuelve los registros válidos del período indicado, ya filtrados correctamente.

¿Cuándo usarla?

• Lectura de datos de empleados (dirección, puesto, salario, centro, etc.)

• Informes de RRHH

• Integraciones con sistemas externos

• Validaciones funcionales en procesos HR

💬 Frase del Día

La derrota no es el final de nada, es información. Todos fallamos, todos tomamos malas decisiones y todos tenemos proyectos que no salen como esperábamos. Lo importante no es evitar la caída a toda costa, sino qué aprendes de ella y cómo ajustas el rumbo después. En el trabajo, como en la vida, avanzar no significa no caer nunca, sino saber levantarte con más criterio que antes.

🙌 Gracias por leer

Y hasta aquí llega el boletín de hoy.

Si has llegado hasta el final, enhorabuena: oficialmente ya puedes decir que no has saboteado el sistema… al menos hoy 😄.

Gracias por estar ahí una semana más, por leer, reflexionar y, sobre todo, por seguir dando sentido a esta pequeña gran comunidad de consultores que saben que SAP no falla solo… a veces lo empujamos un poco.

Nos leemos el martes que viene, con más historias reales, menos teoría y alguna que otra verdad incómoda.

Un abrazo y ¡hasta el martes que viene!