Hay un dato que salió publicado hace apenas unos días y que cuando lo lees en frío produce una mezcla de reconocimiento y preocupación: el 55,7% de los profesionales tecnológicos declara agotamiento significativo en 2026, frente al 44,7% que lo hacía en 2025. Un salto de once puntos en un solo año.

Y lo más llamativo no es el porcentaje en sí. Es lo que hay debajo. El 42,6% de esos mismos profesionales afirma disfrutar mucho o muchísimo de su trabajo. Es decir, más de la mitad están agotados... y siguen disfrutando de lo que hacen. No es que odien su profesión. Es que el ritmo al que están trabajando se ha vuelto insostenible aunque el trabajo en sí les guste.

Eso describe perfectamente la paradoja del consultor SAP. No es que el trabajo sea malo. Es que la incapacidad de desconectarse de él, de soltar el problema cuando el día ha terminado, acaba generando un desgaste que no tiene nada que ver con si el proyecto va bien o mal.

Y los datos del contexto español añaden otro matiz incómodo: el 88% de los profesionales tecnológicos en España se mantiene conectado laboralmente durante las vacaciones. No es una anécdota. Es una epidemia silenciosa de disponibilidad permanente que la mayoría normaliza porque todos los que conoces hacen lo mismo.

Lo curioso de todo esto es que el problema no es nuevo. Pero el ritmo al que está creciendo en 2026 sí es nuevo. La IA agéntica, la presión de las migraciones, los go-lives que no esperan... el ecosistema tecnológico está pidiendo más a sus profesionales en un momento donde el depósito de muchos de ellos ya no está lleno.

Y el primer paso para resolver algo siempre es reconocerlo.

Hay un concepto que SAP lleva meses colocando en el centro de su discurso de RRHH y que esta semana aparece de nuevo en un artículo de SAP News con más contexto del habitual: el Autonomous HCM. La idea detrás es que la gestión de personas evolucione desde el reporting hacia la acción autónoma. No solo saber qué está pasando con tu plantilla, sino que el sistema identifique el problema, evalúe opciones y ejecute acciones aprobadas sin que alguien tenga que coordinarlo todo manualmente.

El artículo describe la evolución en tres etapas muy concretas. Primero la analítica de personas, que es entender qué está pasando con la plantilla hoy: skills, brechas de talento, riesgos de retención. Segundo la inteligencia de plantilla, que es decidir qué hacer con esa información: evaluar si contratar, formar internamente o reasignar. Y tercero el HCM autónomo, que es ejecutar esas decisiones conectando contratación, formación, movilidad interna y planificación de plantilla de forma coordinada.

Lo que no aparece en el comunicado pero se deduce claramente es que todo esto requiere una capa de datos maestros muy bien gobernada. SAP lo reconoce de forma implícita cuando habla de "conectar datos de plantilla, skills, talento, operaciones y negocio en una vista completa." Sin esa base de datos limpia y bien estructurada, el Autonomous HCM no tiene con qué razonar.

Y aquí está la conexión con el tema de este boletín que quizás no es obvia a primera vista: si el sistema puede analizar el agotamiento de la plantilla, identificar los perfiles en riesgo y proponer acciones antes de que se conviertan en bajas o abandonos... quizás el consultor SAP que no sabe desconectar empiece a tener un sistema que se lo diga antes de que sea demasiado tarde. Irónico que la solución venga de la misma tecnología que ha contribuido a la hiperconectividad.

Semana tranquila para SAP en bolsa después del sprint de recuperación de las últimas semanas. A 27 de agosto de 2026, la cotización de SAP en Fráncfort se sitúa en 189,88€, con un rango diario entre 181,14€ y 190,80€ y un rango de 52 semanas entre 127,50€ y 244,30€.

Las acciones han subido un 2,35% respecto a la semana anterior y un 23,59% en el último mes. La recuperación desde mínimos de 127€ sigue consolidándose aunque el ritmo se ha moderado después del sprint inicial.

Lo más interesante de esta semana viene de Morningstar, que identifica a SAP entre cinco grandes compañías europeas que cotizan con descuentos superiores al 20% frente a sus estimaciones de valor razonable. Cuando Morningstar dice que SAP cotiza con descuento significativo respecto a su valor razonable estimado, está diciendo que el mercado sigue sin pagar por ella lo que los fundamentales justifican. Eso puede interpretarse como oportunidad o como señal de que el mercado sabe algo que Morningstar no. Históricamente las dos cosas han sido ciertas en algún momento. 😄

El precio objetivo medio a 12 meses es de 207,19€, con estimación alta de 290€ y estimación baja de 160€. La próxima cita importante es el 21 de octubre con los resultados del Q3. Hasta entonces, consolidación.

⚠️ Sección puramente informativa. No constituye consejo de inversión. Soy consultor SAP, no gestor de fondos.

Voy a contaros algo que me ha costado bastante reconocer en voz alta.

Hay noches en las que me acuesto y lo último que pasa por mi cabeza antes de dormirme es la SPRO. El flujo que tengo que configurar mañana, el desarrollo que está a medias, el cliente que espera una respuesta para primera hora. No es que esté trabajando. Es que el trabajo no se ha ido aunque yo ya haya cerrado el portátil.

Y lo peor es que durante mucho tiempo pensé que era cosa de la empresa, del proyecto, del cliente exigente o de los plazos imposibles. Que si las condiciones fueran diferentes yo desconectaría sin problema. Que era una víctima de las circunstancias.

Hasta que alguien me dijo algo que me dejó sin argumentos: "Guille, ¿qué haces conectado? Deja ya que mañana no se va a acabar el mundo." Y tenía razón. Toda la razón. Porque el único responsable de estar conectado fuera de horario era yo. No el cliente. No la empresa. Yo. La empresa tiene fichajes, tiene políticas, tiene formas de evitar que trabajes de más. El que se conecta a las once de la noche porque "necesita resolver esto" no es la empresa. Soy yo.

Y eso es incómodo de aceptar porque le quita comodidad a la narrativa de que somos víctimas del sistema.

Lo que pasa de verdad es más sutil y más difícil de gestionar. El consultor SAP, especialmente el que lleva poco tiempo en esto, desarrolla una sensación de responsabilidad muy intensa sobre las cosas que tiene entre manos. No es que sea un adicto al trabajo en el sentido clásico. Es que le importa. Le importa que el go-live salga bien, le importa que el cliente esté contento, le importa no fallar al equipo. Y esa sensación de responsabilidad, que en la justa medida es lo que te hace buen profesional, en exceso es lo que no te deja dormir.

He hablado con muchos consultores sobre esto y la respuesta que más se repite es la misma: con el tiempo se te pasa. Y me lo han dicho seniors con diez, quince, veinte años en esto. Al principio yo pensaba que era una respuesta vaga, un poco de "ya verás cuando seas mayor." Pero con el tiempo he entendido lo que realmente significa.

No es que con los años te importe menos. Es que con los años aprendes a calibrar. Aprendes a distinguir lo que es urgente de verdad de lo que solo se siente urgente porque estás en medio del problema. Aprendes que un dump en producción a las seis de la tarde no necesariamente requiere que estés despierto hasta las dos de la mañana. Aprendes que el sistema va a seguir ahí mañana y que tú descansado vas a resolverlo bastante mejor que tú agotado.

¿Os ha pasado ver al senior tan tranquilo? Diciéndote "no te preocupes que esto se soluciona ya verás" con una calma que en ese momento te parece casi irresponsable. Y claro, ese senior ha visto cien problemas como ese y sabe que ninguno ha acabado con el mundo. Esa tranquilidad no es indiferencia. Es perspectiva acumulada.

El problema es que la perspectiva no se puede transferir. Tienes que vivirla tú. Y mientras la vas construyendo, lo que puedes hacer es ser consciente de cuándo el grifo está abierto sin que haga falta que lo esté.

En mi caso lo que más me cuesta no es el proyecto cuando va mal. Es el proyecto que va bien pero tiene mucho volumen. Cuando hay más cosas de las que puedo controlar al mismo tiempo y el cerebro sigue procesando después de que el cuerpo ya ha dicho basta. Eso es lo que a mí me cuesta soltar. Y no te voy a decir que lo tengo resuelto porque no sería verdad.

Lo que sí tengo más claro que hace unos años es que cuidarse a uno mismo no es una debilidad. No es falta de compromiso ni falta de profesionalidad. Es exactamente lo que te permite seguir siendo útil mañana, la semana que viene y dentro de cinco años. El consultor que se quema en dos proyectos no le sirve a nadie. El que aprende a gestionar su energía lleva décadas aportando valor.

Y no me refiero solo a las vacaciones. Me refiero a desconectar a la hora que toca, de verdad, sin el móvil cerca por si acaso, sin el portátil "solo para revisar una cosa." Me refiero a hacer tu vida sin que el flujo de configuración de mañana comparta espacio mental con la cena de hoy.

Eso, para mí, sigue siendo lo difícil. Para otros será otra cosa. Pero sé que más de uno que está leyendo esto ahora mismo se siente identificado.

¿Tú también lo has vivido? ¿Qué fue lo que te ayudó a encontrar ese equilibrio?

Durante años, cuando hablamos de mover desarrollos ABAP entre sistemas SAP, el proceso ha sido bastante conocido: desarrollamos en DEV, guardamos los cambios en una orden de transporte, la liberamos y posteriormente el transporte sigue su camino hacia QA y Producción.

Es un modelo que funciona y que forma parte del ADN de SAP. Pero mientras SAP seguía trabajando con órdenes de transporte, el resto del mundo del desarrollo de software empezó a girar cada vez más alrededor de Git: repositorios, commits, ramas, revisiones de código, pipelines e integración continua.

Y aquí aparece gCTS, Git-enabled Change and Transport System.

La idea no es sustituir CTS por Git ni hacer que mañana desaparezcan SE10, STMS y las órdenes de transporte. De hecho, SAP explica que gCTS continúa utilizando muchas de las entidades del Change and Transport System clásico. La diferencia es que los objetos ABAP, además de seguir existiendo en el sistema ABAP, pueden convertirse en archivos y almacenarse en repositorios Git para gestionar sus versiones.

Dicho de una manera mucho más sencilla: gCTS intenta conectar la forma tradicional de transportar desarrollos SAP con la forma moderna de gestionar software mediante Git.

Imaginemos un ejemplo muy habitual. Un desarrollador modifica una clase ABAP y realiza sus cambios en el sistema de desarrollo. En un escenario tradicional, esos cambios quedan registrados en una orden de transporte que posteriormente será liberada e importada en los sistemas correspondientes.

Con gCTS aparece Git en ese recorrido. SAP proporciona una aplicación Fiori desde la que se pueden clonar repositorios, hacer commit de objetos ABAP, enviar esos commits al repositorio remoto y obtener cambios desde los sistemas destino. El desarrollo sigue realizándose en el sistema ABAP utilizando las herramientas habituales, como ABAP Development Tools.

Y aquí está probablemente lo más interesante para un desarrollador ABAP.

Con el transporte tradicional puedes consultar qué órdenes se han realizado y qué objetos contienen. Con Git puedes empezar a trabajar con un historial de versiones mucho más cercano al que utilizan otros equipos de desarrollo de software.

Puedes tener un repositorio, commits y ramas, y utilizar ese repositorio como parte de procesos de integración continua. SAP contempla precisamente gCTS como una forma de aprovechar las capacidades de Git y de integrar los desarrollos ABAP en procesos de CI.

Esto abre una puerta bastante interesante: que el desarrollo ABAP deje de estar aislado del resto de prácticas DevOps de una organización.

Por ejemplo, podemos imaginar un flujo en el que un desarrollador realiza un cambio, ese cambio queda versionado en Git y posteriormente puede participar en un proceso automatizado de validación antes de llegar a otros sistemas.

La conversación deja de ser únicamente “¿qué transporte tengo que importar?” y empieza a incorporar preguntas como “¿qué versión estoy desplegando?”, “¿qué ha cambiado respecto a la anterior?” o “¿qué commit contiene este desarrollo?”.

Pero hay una aclaración importante: gCTS no significa que CTS desaparezca.

SAP mantiene los conceptos de Change and Transport System dentro de gCTS. Las herramientas de desarrollo y los cambios siguen estando vinculados al modelo de cambios de SAP, mientras que Git añade la capa de gestión de versiones y colaboración. SAP lo define precisamente como una extensión que permite utilizar Git como sistema externo de gestión de versiones para los procesos de cambio y transporte ABAP.

De hecho, gCTS tiene incluso un registro específico, el gCTS Registry, que permite asociar objetos ABAP contenidos en órdenes de cambio con repositorios Git concretos. SAP recomienda especialmente utilizar este registro para escenarios de Customizing, donde la relación entre los objetos y los repositorios puede requerir una gestión adicional.

También hay que tener en cuenta que no todos los objetos y escenarios son automáticamente compatibles. SAP mantiene restricciones sobre determinados tipos de objetos y recomienda revisar las notas y documentación correspondientes antes de plantear una implantación de gCTS.

Por eso, desde el punto de vista técnico, quizá el error sería plantearlo como “Git sustituye a los transportes SAP”.

La forma más correcta de entenderlo sería:

CTS gestiona el cambio SAP.
Git aporta versionado y colaboración.
gCTS intenta conectar ambos mundos.

Y esto puede ser especialmente interesante cuando una empresa quiere acercar sus equipos SAP y no SAP a una misma estrategia DevOps. En lugar de tener un mundo donde los desarrolladores Java, Python o Node trabajan con Git y pipelines mientras ABAP sigue completamente separado, gCTS permite incorporar parte de esa filosofía al desarrollo ABAP. SAP contempla precisamente este escenario como uno de los motivos para utilizar gCTS.

Eso sí, tampoco significa que haya que implantar gCTS porque “Git está de moda”. SAP indica que su utilización es opcional y que puede utilizarse incluso inicialmente en una parte de los proyectos o en un proyecto de prueba para comprobar si encaja con las necesidades de la organización.

Y aquí estaría mi consejo técnico: antes de implantar gCTS, no pensaría primero en Git. Pensaría primero en el proceso de desarrollo.

¿Cómo desarrollamos actualmente? ¿Tenemos varios equipos trabajando en paralelo? ¿Necesitamos versionado más granular? ¿Queremos introducir CI/CD? ¿Tenemos revisiones de código? ¿Cómo gestionamos los transportes? ¿Tenemos desarrollos distribuidos? ¿Qué parte de nuestro landscape realmente necesita esta evolución?

Si la respuesta a estas preguntas empieza a apuntar hacia una metodología DevOps más madura, entonces gCTS deja de ser simplemente “Git para ABAP” y empieza a tener bastante sentido.

Porque quizá el verdadero cambio no sea pasar de SE10 a Git.

Quizá sea pasar de pensar únicamente en transportar código a pensar también en versionar, revisar, probar y entregar software SAP.

Y ahí es donde gCTS se vuelve realmente interesante.

Hay una situación que suele generar bastante confusión, especialmente cuando trabajamos con ciclos de distribución o subreparto en CO. Ejecutas una distribución, por ejemplo una KSU5, revisas el resultado y todo parece lógico: se han repartido costes entre centros de coste y, desde el punto de vista funcional, estamos ante un movimiento interno de Controlling. Entonces alguien entra en el documento contable y pregunta: “¿Por qué SAP me ha creado también un documento FI si esto era solo CO?”

La respuesta está en la integración CO-FI.

En determinados escenarios, SAP necesita que determinados movimientos internos realizados en CO tengan también reflejo en FI. Esto ocurre especialmente cuando el movimiento cruza determinadas características organizativas, como sociedades, áreas funcionales, áreas de negocio o centros de beneficio, dependiendo de cómo esté configurada la integración. SAP denomina a este mecanismo Real-Time Integration of Controlling with Financial Accounting.

Imaginemos un caso sencillo. Tenemos un coste en un centro de coste asociado a una determinada sociedad y centro de beneficio. Ejecutamos una distribución en CO y parte de ese coste termina en otro objeto que pertenece a otra combinación relevante para FI. Para CO el movimiento tiene todo el sentido: estamos redistribuyendo costes internamente. Pero desde el punto de vista financiero, esa redistribución puede cambiar cómo quedan representadas determinadas dimensiones contables. SAP necesita entonces generar el correspondiente asiento de reconciliación para que FI y CO continúen siendo coherentes.

Por eso podemos encontrarnos con un documento FI después de ejecutar una operación como KSU5. No significa necesariamente que el coste se haya contabilizado dos veces ni que exista un error en la distribución. Puede tratarse precisamente del mecanismo que mantiene sincronizados ambos mundos.

Aquí aparece un concepto que conviene conocer bien: la cuenta de reconciliación CO-FI. Y ojo, porque no debemos confundirla con las cuentas de reconciliación de clientes o proveedores de FI. En este caso hablamos de cuentas utilizadas para representar en FI determinados movimientos procedentes de CO durante el proceso de reconciliación.

Una de las claves funcionales está en OK17, donde se realiza la determinación de cuentas utilizada para estas operaciones. SAP utiliza esta determinación cuando necesita generar el documento FI correspondiente. En el caso de los costes secundarios, por ejemplo, no existe un equivalente directo en FI como sí ocurre con los elementos de coste primarios, por lo que es necesario determinar una cuenta de compensación adecuada.

Por eso, cuando un funcional se encuentra con un mensaje del tipo “falta cuenta de reconciliación CO-FI”, antes de pedir que se cree una cuenta nueva en FI conviene hacerse una pregunta mucho más importante:

¿Por qué este movimiento CO está siendo seleccionado para la integración CO-FI?

La respuesta suele estar en la configuración de la variante de integración en FAGLCOFIIMG. En esta configuración se determina cuándo los movimientos de CO deben trasladarse en tiempo real a FI. SAP permite seleccionar los movimientos en función de determinadas características y también mediante reglas o BAdI.

Por ejemplo, si la integración está configurada para reaccionar ante cambios en sociedad, área funcional, fondo o centro de beneficio, una distribución que modifique alguna de estas características puede provocar la generación del documento FI. Es decir, el documento FI no aparece porque “KSU5 contabilice en FI”, sino porque el resultado del movimiento CO cumple las condiciones definidas para la integración CO-FI.

Este punto es especialmente importante para analizar incidencias. Si después de ejecutar una distribución aparece un documento FI inesperado, yo no empezaría mirando únicamente el documento contable. Empezaría siguiendo el recorrido funcional:

¿Qué movimiento CO se ha realizado? → ¿Qué características organizativas han cambiado? → ¿Está activa la integración CO-FI? → ¿Qué variante se está aplicando? → ¿Qué criterios hacen que el movimiento sea relevante para FI? → ¿Qué cuenta está determinada en OK17?

Con este recorrido normalmente se entiende mucho mejor por qué SAP ha generado el documento.

Además, SAP dispone de herramientas específicas para analizar estas situaciones, como FAGLCORC para la reconciliación CO-FI y distintas transacciones de worklist, logs y trace de la integración. La propia documentación de SAP identifica, entre otras, FAGLCOFIFLUP, FAGLCOFIWRKLSTDISP y las transacciones de trace de CO-FI para investigar estos procesos.

Y hay otro detalle importante si estamos trabajando con S/4HANA: no debemos aplicar automáticamente la lógica de los sistemas antiguos. SAP indica que, cuando se utiliza New General Ledger junto con la integración CO-FI en tiempo real, FI y CO permanecen reconciliados automáticamente para los escenarios cubiertos por esta integración, por lo que determinados procesos históricos de reconciliación ya no se utilizan de la misma manera.

Así que el consejo funcional sería bastante sencillo: cuando una operación de CO genera un documento FI, no asumamos inmediatamente que hay un error o una duplicidad. Primero hay que entender qué dimensión organizativa ha provocado la necesidad de reconciliación y qué configuración está determinando el comportamiento.

Porque en SAP muchas veces el documento que parece “aparecer de la nada” no está ahí por casualidad.

Está ahí porque alguien, hace unos años, marcó una casilla en el customizing.

Hay momentos en SAP en los que buscas una BAPI, un BAdI, un enhancement, una clase… y no encuentras una solución sencilla para pasar un dato de un programa a otro.

Y entonces aparece ese viejo conocido de ABAP:

Y posteriormente:

El funcionamiento es sencillo: un programa guarda información en la memoria de la sesión y otro programa puede recuperarla utilizando el mismo identificador.

Durante años fue un recurso bastante utilizado. Cuando no había una alternativa estándar clara, podía sacarte de un buen apuro.

Pero hoy hablamos de una técnica en desuso y que no debería ser nuestra primera opción para desarrollos nuevos.

¿Por qué?

Porque crea una dependencia bastante poco visible entre programas. Un programa deja un dato en memoria y otro espera encontrarlo allí. Si alguien modifica el MEMORY ID, cambia la estructura o altera el flujo de ejecución, el segundo programa puede dejar de funcionar sin que la relación entre ambos sea especialmente evidente.

Actualmente existen mecanismos mucho más adecuados para diseñar estas comunicaciones: clases, interfaces, BAdIs, enhancements, APIs y otros mecanismos de extensión dependiendo del escenario.

Ahora bien, hay una diferencia importante entre utilizarlo hoy en un desarrollo nuevo y encontrarlo dentro de un desarrollo antiguo.

Si te encuentras un EXPORT TO MEMORY ID en un sistema que lleva años funcionando, no lo elimines simplemente porque esté en desuso.

Primero descubre quién hace el IMPORT, por qué se creó y qué procesos dependen de él.

Porque todos sabemos que en SAP hay código que nadie entiende, nadie quiere tocar y, misteriosamente, lleva diez años funcionando en producción.

Y probablemente ese MEMORY ID sea precisamente uno de ellos.

Tip: en desarrollos nuevos, evita utilizarlo salvo que tengas un motivo técnico muy concreto. En desarrollos antiguos, antes de tocarlo… investiga.

Porque cuando no quedaba otra, tocaba hacerlo.

Hay un perfil en los equipos SAP que los responsables suelen ver como un activo y que en realidad es una señal de alarma: el consultor que siempre está disponible, que responde a cualquier hora, que nunca dice que no y que parece no tener límite de capacidad.

Ese perfil no es sostenible. Y como responsable, si lo estás normalizando, estás contribuyendo a un problema que tarde o temprano va a aterrizar en tu proyecto de la peor forma posible.

El agotamiento no llega de golpe. Llega acumulado, de forma invisible, hasta que un día ese consultor que siempre estaba disponible empieza a cometer errores que antes no cometía, a estar más irritable en las reuniones, a entregar con menos calidad, a perder la concentración en momentos clave. Y para entonces el daño ya está hecho.

Lo que los datos no dicen pero cualquier responsable con experiencia sabe es que las fases de mayor intensidad en proyectos SAP, los sprints previos al go-live, las semanas de corrección de incidencias críticas, los períodos de migración de datos, crean una dinámica donde trabajar de más se normaliza y hasta se celebra implícitamente. "Este equipo es una máquina" se convierte en el elogio que en realidad está premiando un patrón que nadie debería premiar.

Como responsable, tienes influencia real sobre esa dinámica aunque no tengas control total. La forma en que gestionas las urgencias, la forma en que hablas del trabajo fuera de horario, si mandas mensajes a tu equipo a las diez de la noche o si esperas a mañana... todo eso comunica algo sobre qué comportamientos son esperados y cuáles no.

Hay dos cosas concretas que marcan una diferencia enorme y que no requieren ningún proceso formal ni ninguna aprobación de RRHH.

La primera es modelar el comportamiento que quieres ver. Si tú desconectas a tu hora, si no mandas mensajes fuera de horario salvo emergencia real, si hablas abiertamente de que el descanso es parte del rendimiento y no su enemigo... tu equipo lee eso y lo interpreta como permiso para hacer lo mismo. Si tú eres el primero en conectarte a las ocho de la mañana después de haber respondido hasta las once de la noche, tu equipo lee eso también.

La segunda es hacer la pregunta que nadie hace: ¿cómo estás de verdad? No el "¿cómo va el proyecto?" de la daily. Una conversación real, de cinco minutos, donde la respuesta honesta sea bienvenida. La mayoría de las veces la señal de alarma del agotamiento lleva semanas ahí antes de que alguien la detecte, y cuando alguien pregunta de verdad suele salir a la superficie más rápido de lo esperado.

El consultor que descansa bien rinde mejor. El equipo que tiene límites razonables es más sostenible que el que va al máximo durante seis meses y luego necesita tres para recuperarse. Eso no es una opinión sobre bienestar corporativo. Es aritmética de proyecto.

Perfecta para el boletín de hoy. Y no necesita mucho comentario adicional porque básicamente describe exactamente lo que hemos estado hablando durante todo el número.

Lo gracioso es que aplicamos esta lógica constantemente en sistemas SAP: reiniciar un servicio, refrescar una conexión, limpiar caché... y luego ignoramos que la misma lógica aplica a las personas que operan esos sistemas. El portátil puede desconectarse. Tú también puedes. Y probablemente el lunes funciones mejor.

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.