Retirar un producto del mercado no es una rareza de SAP con ByDesign: es el deporte nacional de la industria tecnológica. Y hay una prueba buenísima de ello. Existe una web, killedbygoogle.com, mantenida por la comunidad, que lleva la cuenta de todos los productos y servicios que Google ha matado. A día de hoy, el marcador va por 308: 215 servicios, 69 apps y 24 productos de hardware. Un cementerio entero, con su lápida para cada difunto, desde Google Reader hasta Stadia.

Piénsalo un segundo. Un producto tan querido como Google Reader se anunció muerto en 2013 y provocó un cabreo monumental. Stadia, la consola en la nube, apagó sus servidores en 2023 a los pocos años de nacer. Y así 308 veces. Hay estudios que calculan que Google ha discontinuado más de la mitad de los productos que ha lanzado.

¿Y por qué me hace gracia esto en el número de hoy? Porque demuestra que retirar productos es lo normal, no la excepción. La diferencia está en el cómo. Google, al menos, te pone una fecha, cierra el chiringuito y lo entierra con honores (y con web conmemorativa incluida). SAP, en cambio, tiende a hacerlo en voz baja: ni funeral, ni fecha, solo un “ya no se vende” y a esperar.

Si alguien montara un “Killed by SAP”, seguro que ByDesign no estaría solo. El problema es que, sin fecha de entierro oficial, no sabríamos ni qué poner en la lápida

Momento interesante para mirar la cotización, porque esto se publica casi en vísperas del gran día. SAP cotizaba el 20 de octubre alrededor de los 200,98 € en pre-mercado, con una subida suave del +0,57% respecto al cierre de Xetra del día 19 (199,84 €). La acción ha recuperado un buen trozo de terreno y vuelve a coquetear con la barrera psicológica de los 200.

Y el motivo del nerviosismo tiene fecha: mañana, 21 de octubre, SAP presenta los resultados del Q3 2026. Todo lo que ha pasado estas últimas semanas (subidas suaves, acción acercándose a los 200) es el mercado posicionándose antes del examen. A partir de mañana sabremos si el optimismo tenía fundamento.

Y optimismo hay, al menos entre los analistas, que llevan semanas subiendo objetivos: TD Cowen lo ha llevado a 250 $, Barclays a 243 $, BMO a 235 $ y Wells Fargo le asigna 220 €. Todos por encima de la cotización actual. Para el contexto habitual, la acción sigue razonablemente por debajo de su máximo de las últimas 52 semanas (que rondó los 244 €), así que hay recorrido teórico si los números acompañan.

Traducido al idioma del consultor: el mercado llega a los resultados con ganas y con la cartera abierta. Si SAP cumple mañana, la cosa puede ponerse bonita. Si decepciona, ya sabemos cómo reacciona esto. El 21 por la noche salimos de dudas.

La historia de SAP Business ByDesign es, posiblemente, la mejor lección de humildad que ha tenido SAP con las pymes. Y casi nadie la recuerda entera.

Cuando SAP lo presentó en septiembre de 2007 (con el nombre en clave “A1S”), la ambición era descomunal, iba a ser el ERP cloud que conquistara el mercado de las medianas empresas, y el objetivo público era alcanzar 10.000 clientes para 2010. Era la gran apuesta SaaS de SAP cuando “la nube” todavía sonaba a cosa rara.

¿El resultado? En 2010, según los analistas que citaba el Wall Street Journal, ByDesign tenía alrededor de 100 clientes. Cien. No diez mil. Problemas de rendimiento, de coste (133 € por usuario y mes) y de interfaz lo tuvieron clavado en el suelo durante años. El propio responsable de SAP reconoció que “no había tenido el éxito esperado”. En 2013 SAP recortó la inversión en el producto y el runrún de que estaba muerto empezó a sonar con fuerza.

Y aquí viene lo bueno, 19 años después, ByDesign por fin ronda esos 10.000 clientes que se le prometieron al mercado en 2007. Ha tardado casi dos décadas en llegar a la meta que se puso para tres años.

¿Y qué hace SAP justo ahora que lo ha conseguido? Lo retira de la lista de precios. El 20 de abril de 2026 dejó de venderse a clientes nuevos.

O sea: tardó 19 años en cumplir su objetivo, y el premio por conseguirlo fue la jubilación anticipada. Hay metas que es mejor no alcanzar nunca.

Vamos a los hechos, que esto hay que contarlo con cuidado. Desde el 20 de abril de 2026, SAP ya no vende ByDesign a clientes nuevos. Lo ha sacado de la lista de precios. Pero (y esto es importante) no ha anunciado una fecha de fin de mantenimiento. Oficialmente el producto sigue soportado, y el grupo de usuarios DSAG habla de soporte garantizado al menos hasta 2032. Así que si eres cliente de ByDesign hoy, no te van a apagar el sistema mañana.

Entonces, ¿dónde está el drama? En que un producto que ya no se vende y que lleva años sin desarrollo real está muerto, aunque siga respirando. Es una muerte en diferido. Y para un cliente, estar en un producto así es la peor de las situaciones: no te obligan a moverte, pero cada año que pasa el sistema está más viejo, hay menos partners que lo toquen, y la presión para migrar deja de ser una decisión estratégica para convertirse en una urgencia. El limbo tiene fecha de caducidad, solo que no te la dicen.

Y aquí está la brecha de verdad, la que me parece más grave.

ByDesign ocupaba un hueco muy concreto y muy difícil de rellenar, las filiales de grandes grupos en escenarios de dos niveles (la matriz con su S/4HANA gordo, y las filiales con algo más ligero), las pymes de proyectos y servicios, las empresas multi-sociedad que necesitaban algo cloud pero flexible. ¿Qué ofrece SAP como recambio? Básicamente S/4HANA Cloud Public Edition, empaquetado como GROW with SAP.

Y no es lo mismo. No porque sea peor producto, sino porque es otra filosofía. S/4HANA Cloud Public es lo que en inglés llaman “opinionated”: espera que te adaptes tú a sus procesos estándar, no al revés. Poca personalización, best practices y a correr. Que para muchos proyectos está bien, ojo. Pero el cliente que eligió ByDesign precisamente porque le daba flexibilidad se va a encontrar con que todos sus apaños, sus adaptaciones y su forma particular de trabajar no se trasladan. No es un upgrade. Es una mudanza a una casa con las paredes ya puestas.

¿Y el que es demasiado pequeño para eso? SAP le señala Business One, que es un producto honesto pero con techo, en cuanto creces en internacionalización o complejidad, se queda corto. Así que tienes un hueco por arriba y un hueco por abajo, y en medio un montón de empresas mirando el catálogo de SAP sin encontrar su talla.

Esto es un problema de confianza más que de tecnología. Cuando un fabricante retira el producto que le vendió a un segmento entero y lo empuja hacia algo más rígido y, normalmente, más caro, lo que transmite es un mensaje incómodo, “tu caso de uso ya no me interesa tanto”. Y los clientes lo captan. No es casualidad que Odoo, NetSuite y Microsoft estén frotándose las manos y posicionándose como “la alternativa para el mid-market”. Cuando dejas un hueco así, alguien lo ocupa. Y esta vez no tiene por qué ser SAP.

Que quede claro que entiendo la lógica de negocio. Mantener cuatro ERPs distintos es caro, y consolidar todo en la plataforma HANA tiene su sentido estratégico. No critico que SAP ordene su catálogo. Critico cómo deja a la gente en el camino, sin una fecha clara, sin un recambio equivalente, y con un “tranquilo, que hay soporte hasta 2032” que suena menos a promesa y más a sala de espera.

Mi consejo para quien esté en ByDesign, no migres por pánico, pero no te duermas. El limbo es cómodo hasta que deja de serlo, y suele dejar de serlo justo cuando menos te conviene.

Situación universal: tienes dos timestamps y necesitas saber cuánto tiempo ha pasado entre uno y otro. O sumarle media hora a un timestamp. Y lo que ves en medio código heredado es un festival de restar la fecha por un lado, la hora por otro, convertir a segundos a mano, y rezar para que no haya un cambio de día, de mes o (Dios no lo quiera) de año por medio. Para todo eso existe la clase CL_ABAP_TSTMP, que hace la aritmética de timestamps bien y sin dramas.

Lo primero, capturar el momento actual con la sentencia moderna:

subtract( ) te devuelve la diferencia en segundos entre los dos timestamps, manejando por dentro todos los saltos de día, mes y año que a mano son un infierno. ¿Quieres sumar o restar tiempo a un timestamp? Tienes add( ) y subtractsecs( ) para moverte en el eje temporal sin tener que reconstruir la fecha tú mismo.

¿Para qué sirve en la vida real? Para medir cuánto tarda un proceso (performance), para calcular SLAs (“cuántas horas han pasado desde que entró el aviso”), para logs con duración, para controlar ventanas de tiempo en interfaces… cualquier cosa donde el “cuánto tiempo ha pasado” tenga que ser exacto.

ACLARACIÓN: CL_ABAP_TSTMP trabaja con timestamps (tipos TIMESTAMP y TIMESTAMPL, el largo con decimales de segundo). Si lo que tienes son campos de fecha y hora sueltos (DATS y TIMS por separado), primero los combinas en un timestamp y luego operas. No mezcles churras con merinas, que ahí es donde la gente se hace la picha un lío con los husos horarios.

Como hoy hablamos de grupos y filiales, vamos con el concepto que más se atasca en cualquier proyecto con varias sociedades: la facturación intercompañía (cross-company). Y es de los que incluso funcionales de SD con experiencia explican con la boca pequeña.

El escenario: una sociedad del grupo (la que recibe el pedido del cliente final) vende, pero la mercancía sale de una planta que pertenece a OTRA sociedad del grupo. Resultado: dos facturas distintas. Una externa, al cliente final, que hace la sociedad vendedora. Y otra interna, de la sociedad que entrega a la sociedad que vendió. Esa factura interna es la intercompañía, y en S/4HANA usa el tipo de factura IV.

El mecanismo clave que todo el mundo olvida: para que exista la factura interna, la sociedad entregante necesita tener dado de alta como cliente interno (payer) a la organización de ventas de la sociedad vendedora. Es un interlocutor comercial (business partner) con rol de cliente FI y de ventas. Sin ese cliente interno, el sistema sencillamente no puede generar la factura intercompañía. Fin. No hay workaround elegante.

Y la otra pieza es el precio. La condición PI01 va estadística en la factura al cliente final (representa el coste para la sociedad vendedora, y alimenta CO-PA), mientras que IV01 es la que lleva el precio real de la factura interna y referencia a PI01. Si no configuras PI01 en el esquema de cálculo, la factura intercompañía sale con precio cero, y entonces empieza el circo de “¿por qué la filial alemana le factura 0 € a la española?”.

El error clásico: montar todo el flujo de entrega y olvidarse del cliente interno o de la condición PI01. Todo parece funcionar hasta que llegas a la VF04 con el flag de intercompañía marcado y descubres que, o no sale la factura, o sale a cero. Y ese descuadre entre sociedades es justo el que luego vuelve loco al de FI en el cierre.

Escena habitual: tienes que montar la autenticación Basic de una API REST, o meter un adjunto dentro de un JSON, o guardar un fichero en un campo de texto. Todo eso necesita Base64. Y lo que pasa en el 90% de los proyectos es que alguien se trae una rutina de internet, la pega en un include con nombre dudoso, y ahí se queda para la eternidad. No hace falta. SAP tiene la clase CL_HTTP_UTILITY desde hace años, y hace exactamente eso.

Lo básico, codificar y decodificar Base64:

Y no solo Base64. La misma clase te resuelve el otro clásico que todo el mundo reinventa: el escapado de URLs y de HTML, con métodos como escape_url( ) y unescape_url( ). Cuando montas una llamada HTTP con parámetros que llevan espacios, acentos o caracteres raros, esto es lo que evita que la URL se rompa por el camino.

¿Dónde lo usas de verdad? En cabeceras de autenticación (el Basic Auth es literalmente “usuario:contraseña” en Base64), en el intercambio de adjuntos por API, en integraciones con sistemas externos, en tokens… cualquier sitio donde los datos tengan que viajar como texto plano seguro.

Lo importante para los que estáis en ABAP Cloud / S/4HANA moderno: CL_HTTP_UTILITY tiene parte no liberada, así que la alternativa released es CL_WEB_HTTP_UTILITY, con los mismos encode_base64( ) y decode_base64( ) como métodos estáticos. Misma idea, versión apta para el Clean Core.

Si lideras una cuenta o asesoras a un cliente que está en ByDesign (o en cualquier producto en esta situación de limbo), te vas a encontrar con una conversación incómoda. Y la vas a llevar mal si caes en cualquiera de los dos extremos fáciles.

El primer extremo es el vendedor del miedo: “tu ERP está muerto, hay que migrar ya, firma aquí”. Es mentira y se nota. El cliente tiene soporte durante años, no hay un apagón inminente, y si le metes prisa con un argumento falso, pierdes la credibilidad para cuando de verdad haya que moverse. El segundo extremo es el avestruz: “mientras funcione, no lo toques”. También es un error, porque el coste de no hacer nada aquí es real, solo que llega tarde y disfrazado.

El trabajo de quien asesora bien es sostener las dos verdades a la vez: no hay urgencia hoy, pero hay una cuenta atrás silenciosa. Y traducir eso en un plan, no en una venta.

En concreto, hay tres cosas que puedes hacer esta misma semana con un cliente en esta situación. La primera es separar el “cuándo” del “qué”. El cuándo puede esperar (tienes margen hasta bien entrada la próxima década), pero el qué conviene empezar a estudiarlo ya: a dónde migrarías, qué de lo que tienes hoy se traslada y qué no, cuánto te costaría. Un assessment no es una migración. Es información para decidir con cabeza cuando toque.

La segunda es poner números al coste de esperar, porque es el que nadie ve. Cada año que pasa hay menos partners que conocen el producto, el equipo que lo mantiene envejece, y la ventana de “migrar con calma” se estrecha. Según el benchmark de SAPinsider de 2025, casi la mitad de las migraciones ERP se pasan del presupuesto previsto. Eso no pasa por mala suerte: pasa por llegar tarde y tener que correr. Quien planifica con tres años de margen negocia; quien llega con la soga al cuello, paga lo que le pidan.

La tercera, y la más importante, es ser honesto sobre la brecha. Si el recambio que SAP ofrece no encaja bien con el caso del cliente (porque necesita flexibilidad que S/4HANA Cloud Public no le va a dar, por ejemplo), dilo. Aunque eso signifique poner sobre la mesa que quizá la mejor opción para ese cliente concreto esté fuera del catálogo que tú vendes. Eso es lo que separa a un asesor de un comercial. Y el cliente, a largo plazo, se queda con el asesor.

El coste de no hacer nada no es que el sistema se apague. Es llegar a 2030 con un ERP sin partners, sin margen de negociación y con una migración de urgencia sobre la mesa. Todo por no haber dedicado dos semanas a un assessment en 2026.

El error no es que SAP retire un producto (eso pasa y seguirá pasando), el error sería que un cliente, o nosotros como consultores, siguiéramos planificando el futuro como si el catálogo de hace cinco años fuera a durar para siempre. La lógica de ayer es cómoda porque ya la conoces. Pero en SAP, como en casi todo, lo que ayer era la apuesta estrella hoy puede estar fuera de la lista de precios

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.