En España la norma es clarísima: entre empresas, el plazo máximo de pago es de 60 días. Punto. Sobre el papel.

En la práctica, según el último estudio de la Plataforma Multisectorial contra la Morosidad (PMcM) (con datos de 2025), el periodo medio de pago del sector privado está en 67 días, y el 85% de las grandes empresas incumple los plazos legales. Las grandes, sí: las que tienen departamento financiero, procesos de aprobación de facturas con más firmas que una hipoteca y sistemas pensados precisamente para pagar a tiempo.

Y como un problema nunca viene solo, está el otro agujero de cualquier proyecto con un cliente complicado: el alcance que crece sin control. Según el Pulse of the Profession de PMI, el 52% de los proyectos sufre “scope creep” (cambios de alcance no controlados), cuando cinco años antes era el 43%. Más de la mitad de los proyectos acaba haciendo más de lo que se firmó.

Junta las dos cosas y tienes la tormenta perfecta para cualquier partner: cada vez más trabajo que no estaba en la estimación, y cada vez más días para cobrar el que sí estaba. Y mientras tanto, la consultora pagando nóminas como si nada.

Curioso, ¿verdad? La ley de los 60 días existe. Lo que pasa es que hay quien la lee como una recomendación.

Semana de las que alegran al accionista. El lunes 9 de noviembre, JPMorgan subió la recomendación de SAP de “neutral” a “sobreponderar” y, de paso, disparó su precio objetivo de 175 € a 275 €. Cien euros de golpe. Ni un cambio de alcance a mitad de proyecto es tan generoso.

El mercado lo celebró: tras cerrar el viernes 6 en Xetra a 210,75 €, la acción abrió el lunes en torno a los 214,53 € (+1,79% en preapertura) y por la tarde rondaba los 212,48 €. Una semana antes, el día 3, estaba en 206 €, así que la tendencia de estos días ha sido claramente al alza, con el empujón extra del acuerdo de nube soberana con Defensa de Países Bajos.

¿El argumento de JPMorgan? Que la IA empresarial está pasando de los pilotos a la producción, y eso aumenta la demanda de sistemas centrales integrados como los de SAP. Señala como palancas Business Data Cloud, BTP, Signavio y el Knowledge Graph, y además ha subido sus estimaciones de beneficio para 2026 a 2028 por más confianza en los márgenes.

Para el contexto: el mínimo de las últimas 52 semanas sigue en 127,50 €, y la acción continúa por debajo de los máximos que marcó este año. El próximo gran examen serán los resultados anuales, previstos para finales de enero.

Después de un boletín entero hablando de clientes que no se organizan, os traigo justo lo contrario. El Ministerio de Defensa de Países Bajos ha firmado un acuerdo estratégico con SAP (anunciado el 4 de noviembre) para montar un entorno de SAP Sovereign Cloud dentro del propio país, diseñado alrededor de sus requisitos de seguridad y soberanía.

El reparto de papeles está muy bien atado: SAP desarrolla y gestiona el entorno (mantenimiento, actualizaciones y buena parte de la operación), pero el ministerio conserva el control sobre cómo se tratan sus sistemas y datos críticos. Y no lo pone todo en la misma cesta: esta nube es una pieza más de una estrategia multicloud, junto a nube privada y entornos para información clasificada. El objetivo declarado es depender menos de un solo proveedor y poder recuperar servicios críticos tras una caída o un ciberataque. Estará operativo el 1 de enero de 2028.

Lo interesante para nosotros es el concepto. La soberanía del dato ya no va solo de dónde están guardados los datos, sino de quién puede acceder a los sistemas y quién los opera. En Europa este tema está cada vez más encima de la mesa, y para SAP es una referencia de peso en un sector muy sensible que otros organismos pueden copiar. Para el consultor, significa más proyectos de sector público, más arquitecturas multicloud y más conversaciones sobre seguridad desde el día uno.

Lo que no aparece en el comunicado: ni el valor del contrato ni lo que supondrá en ingresos para SAP. Y otra cosa que me ha llamado la atención: un cliente que define desde el principio qué controla él, qué opera el proveedor y cómo se recupera si algo falla. Ojalá todos los proyectos arrancaran con las cosas así de claras.

¿Te ha tocado ya algún proyecto donde la soberanía del dato fuera un requisito de verdad y no una casilla del pliego?

He tenido la suerte de trabajar con clientes magníficos. De esos dados a trabajar, que escuchan, que proponen mejoras y con los que da GUSTO sentarse. Y no lo digo porque nuestro servicio fuera caro o barato, sino porque cuando estás a gusto con alguien, desde el lado del partner eres más flexible, desde el lado del cliente también, y eso hace que el proyecto salga como tiene que salir. Hay una frase que para mí es una pequeña medalla: cuando el cliente te dice “vente un día por la fábrica y te enseñamos lo que hacemos”. Si te quieren enseñar su casa, es que has hecho bien tu trabajo.

Pero también está el otro lado. Y este boletín va de ese lado.

(Aviso a navegantes: hoy hablo de clientes. Si queréis que hable del lado oscuro de las consultoras, que también lo tiene, decídmelo y preparo un boletín solo para eso.)

Hay clientes complicados y clientes MUY complicados. Hoy toca hablar de los segundos. Esos que a todo dicen que no, que ponen pegas desde el minuto uno, y que, en un proyecto que ya es difícil por plazos, circunstancias y personal, todavía te lo complican más porque ellos mismos no se organizan. Seguro que te suena alguno:

No todos son fáciles de llevar, eso ya lo sabemos. Pero muchas veces, con unos pequeños detalles, es bastante más fácil salir vivo.

Con los accesos, lo que funciona es dejarlo definido antes de arrancar: si se trabaja con usuarios nominales o genéricos, cuántos hay, y que no se empiece hasta que TODOS (funcionales, programadores y responsables) tengan acceso a las mismas herramientas. Aunque luego no se usen, siempre viene bien que más de una persona tenga acceso a todo. Y pedir manuales de acceso a las plataformas y para las configuraciones; si no los tienen, los hacemos nosotros. Pero no se empieza hasta que esté todo listo, avisándoles, claro: si tardan un mes, el proyecto se retrasa un mes. (Lo sé, la teoría suena muy fácil y la práctica es otra cosa, pero dejarlo claro desde el principio ya es media batalla.)

Con la comunicación, un canal para las reuniones y otro para las incidencias pre y post go-live. Y ya. Aquí se va muchísimo tiempo y dinero en incidencias de proceso no definidas: al principio todo va bien, pero el “te lo dije el otro día” y el “te mandé un Teams ayer” me los sé de memoria. Lo mejor es apuntarlo todo y que sea el partner quien identifique, con criterio, qué es una incidencia y qué es una mejora. Para eso está la estimación, con el alcance definido sección por sección: con ella delante se decide en dos minutos. Para mí este es el gran agujero de muchos proyectos. Las mejoras no contempladas aparecen siempre en mayor o menor medida, y una bolsa de horas suele ser la forma más sana de gestionarlas.

En los KTs y las UATs, el control lo tenemos que llevar nosotros. Al principio del proyecto se decide quién hace las UATs. Si las hace el partner, se montan varias sesiones por flujo con el cliente para cubrir todas las casuísticas y caminos del alcance, dejando preparadas las pruebas para que el cliente las ejecute (y eso se cobra, aunque no lo parezca). Si las hace el cliente, es su responsabilidad, y nosotros nos ocupamos de que nuestras pruebas internas y el desarrollo estén terminados y funcionando. Los KTs sí los damos siempre nosotros, y ahí salen las dudas de flujo y las preguntas raras, así que hay que llevarlos muy preparados y muy atados.

Con las reuniones, lo normal durante el desarrollo es una semanal o cada quince días para ver avances y mejoras. Si todo va bien, con eso sobra. Cerca del go-live sí habrá semanas intensas (martes, miércoles y viernes, por ejemplo) para KTs, UATs y demás, y es lógico. Pero ojo: esas reuniones son para cerrar el proyecto, y a esas alturas deberían salir pocas dudas.

Luego está algo que me parece un error muy común: dejarnos guiar siempre por lo que el cliente cree que es mejor. Si yo soy el ABAP y mi trabajo como profesional es decirte que para este proyecto es mejor un servicio API REST que otra RFC, me tendrás que creer. Ya sé que tienes muchas RFCs funcionando de maravilla, pero la API es más moderna y tiene mejor recorrido a futuro. Muchas veces nos callamos por no discutir y no crear malentendidos, y no debería ser así. Y no va solo de ABAP: en un blueprint hay muchas formas de montar un flujo, y si como partner crees que la mejor opción es el camino B, dilo, debátelo, y que después se decida a más alto nivel.

Y por último, la pasta. Aquí poco os puedo decir más allá de esto: si podéis, trabajad por hitos para que el pago vaya por partes, aunque al principio cueste más montarlo (que tienen un SAP, se pueden hacer contratos marco, contratos de servicio y de todo tipo, jajaja). Lo que tengo claro es que si después de un tiempo las facturas siguen dando problemas (que si no está aprobada, que si falta un campo) y van varios intentos sin que llegue, hay que levantar la mano, reunirse con el cliente y dejar las cosas claras. Porque a una consultora muchas veces le pagan a 60 o 90 días: está adelantando el sueldo de sus consultores durante tres meses. Y si cuando llega el momento de cobrar resulta que “había un campo mal relleno” y toca esperar otros 60 o 90 días, a más de uno se le cae el pelo o le salen canas. Así que sí: lo sano es decir “vale, cuando se nos pague, seguimos”.

Pero bueno, todo esto es mi humilde opinión. La de un simple consultor que ha hablado con mucha gente, que ha visto de todo, que se ha pegado con todo, y que cada día se pega un poquito más. Espero que os sirva.

¿Cuál de estos clientes te ha tocado? ¿Y cuál te quitó más horas de sueño?

Si abres casi cualquier sistema S/4HANA te vas a encontrar cientos de CDS escritas así: @AbapCatalog.sqlViewName arriba y define view debajo. Son las CDS basadas en DDIC, la primera generación. Funcionan, pero SAP ya las ha relevado: las CDS View Entities (define view entity) llegaron con ABAP 7.55 y, desde 7.56, las funcionalidades nuevas solo salen para View Entities. Es decir, cada CDS antigua que mantienes es una CDS que se queda fuera de todo lo que viene.

La diferencia de fondo: la CDS antigua genera dos objetos con nombres distintos (la fuente DDL y una vista SQL en el diccionario), mientras que la View Entity es un único objeto con un único nombre. Menos piezas, menos líos de nombres y adiós a esa vista SQL “fantasma” que alguien acaba leyendo desde un report.

El cambio en el código parece pequeño:

Fuera el sqlViewName, se añade entity, y los parámetros pasan de :p_fecha a $parameters.p_fecha. Pero ojo, porque SAP lo deja claro: las View Entities son incompatibles por diseño con las antiguas. No se admite SELECT *, el mandante pasa a gestionarse de forma implícita (con $session.client), las anotaciones de buffering o @ClientDependent desaparecen, y hay reglas que pueden cambiar el comportamiento. Por eso la migración nunca es automática: la decide el desarrollador.

Para hacerlo con cabeza tienes herramientas. El report RUTDDLS_MIGRATION_CANDIDATES analiza qué vistas se pueden migrar y qué las bloquea. Desde 7.56, el report RUTDDLSV2MIGRATION hace la conversión con un modo simulación. Y en S/4HANA 2023 (y en la nube desde la 2302) tienes el asistente de ADT: botón derecho sobre la CDS, “Migrate to CDS View Entity”, primero Simulate y después Migrate.

Cuando una empresa contrata servicios externos (una consultora, por ejemplo), lo normal es que lo haga con un pedido de servicios. Pero antes de poder registrar la factura del proveedor, alguien del cliente tiene que confirmar que el servicio se ha prestado. Eso se hace con la hoja de entrada de servicios: en el modelo clásico, con la transacción ML81N; en S/4HANA con lean services, con la app Fiori Manage Service Entry Sheets - Lean Services (la ML81N no sirve para lean services). En esa app, por cierto, el campo con el nombre de la hoja, que recoge el número de documento del proveedor, es obligatorio.

La hoja hace el papel de la entrada de mercancía para los servicios. Y aquí está la clave: con la verificación de facturas basada en entrada (GR-based IV), que es lo habitual en pedidos de servicios, no se puede facturar lo que no se ha recibido. Traducido: si nadie ha registrado y aceptado la hoja, la factura no se puede contabilizar, por muy correcta que sea. De hecho, para facturar un pedido de servicios sin hoja hay que desactivar expresamente la entrada y la verificación basada en ella.

El error clásico es que el partner manda la factura y se olvida, mientras en el cliente nadie acepta la hoja: el responsable que pidió el servicio está de vacaciones, la hoja no cuadra en importe con la factura o nadie sabe que le toca a él. Resultado: factura parada, el contador de los 60 o 90 días vuelve a cero y en la consultora empiezan a salir canas.

La recomendación: al arrancar el proyecto, pregunta cómo es el circuito de compras de servicios del cliente. Quién crea la hoja, quién la acepta, qué referencia tiene que llevar y cuánto tarda la aprobación. Y alinea tus hitos de facturación con ese circuito: factura lo aceptado, no lo trabajado. Te ahorrarás muchos correos de “¿cómo va lo mío?”.

Con un cliente complicado, tener pruebas de lo que hizo tu desarrollo vale oro. Cuando te dicen “la interfaz falló el martes” o “eso no lo procesó”, lo mejor es poder abrir un log y enseñar qué pasó, cuándo y con qué datos. Y la mayoría de desarrollos Z guardan sus mensajes en una tabla propia o directamente no guardan nada. SAP tiene desde hace muchísimo un sistema de log estándar para eso: el log de aplicación, que se consulta en la SLG1.

El objeto y el subobjeto (ZINTERFACES / PEDIDOS en el ejemplo) se crean antes en la SLG0. Y el truco que más se agradece es el extnumber: si pones ahí el número de pedido, de factura o de lo que sea, en la SLG1 puedes buscar el log directamente por ese número. Cuando el cliente te diga “el pedido 4711 no se procesó”, lo abres en diez segundos.

Cuando hablamos de clientes complicados solemos pensar en el proyecto: retrasos, alcance, facturas. Pero hay un coste que casi nunca se apunta en ninguna parte, y es el desgaste de las personas que tratan con ese cliente cada día. El consultor que recibe mensajes a las nueve de la noche, el que sale de cada demo con la sensación de que su trabajo no vale nada, el que lleva tres semanas sin un día tranquilo. Ese desgaste no aparece en ningún informe de avance, pero acaba pasando factura.

Si lideras un equipo, tu papel con un cliente así es hacer de escudo. Que las broncas, las escaladas y las presiones lleguen a ti, y que tu equipo pueda dedicarse a trabajar. No se trata de esconderles lo que pasa, sino de que no sean ellos los que se comen el golpe uno a uno.

Hay varias cosas concretas que puedes hacer esta misma semana. La primera, hablar a solas con la persona que más trato tiene con ese cliente y preguntarle, sin rodeos, cómo lo está llevando. Te sorprendería cuánta gente está quemada y no lo dice por no parecer débil. La segunda, escalar a tu propio responsable antes de que explote, y hacerlo con datos: horas dedicadas a cosas fuera de alcance, días perdidos esperando accesos, reuniones por semana. Tu responsable no puede defender al equipo de algo que no conoce. La tercera, reconocer el trabajo dentro de casa, porque el cliente no lo va a hacer. Si en cada sesión solo salen pegas, alguien tiene que decirle al equipo que lo que han construido está bien hecho. Y la cuarta, si ves a alguien al límite, rótalo aunque te complique la planificación. Un consultor quemado acaba yéndose, y no siempre solo del proyecto.

Lo difícil es que todo esto choca con la tentación de “aguantar hasta el go-live”, porque siempre parece que queda poco. Pero el coste de no hacer nada es muy real: gente buena que pierde las ganas, rotación justo cuando más falta hace, y un proyecto que acaba saliendo, sí, pero dejándose por el camino a las personas que lo sacaron adelante.

Que un cliente diga que no a una solución no siempre es mala fe: muchas veces es que nadie le ha enseñado bien por qué el camino B es mejor. Ese es nuestro trabajo como partner, explicarlo, enseñarlo y defenderlo con argumentos, no tragar con todo por no discutir. Y si después de enseñárselo sigue diciendo que no… bueno, para eso están las actas.

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.