Lo que un consultor funcional debería entender de ABAP Cloud

Eres consultor funcional. No escribes ABAP, y no tienes por qué. Pero cada vez que el equipo técnico te dice “eso no se puede” o “eso son tres sprints”, tomas esa frase con la misma fe con la que un cliente toma la tuya. El problema es que en un proyecto SAP moderno esa frase es correcta la mitad de las veces, y la otra mitad es una forma cómoda de cerrar una conversación. Sin un mínimo de criterio técnico, no puedes distinguir cuál es cuál.

Por qué esto te importa aunque no programes

Tu trabajo no es programar. Es traducir lo que el negocio necesita en algo que el equipo técnico pueda construir, y traducir de vuelta lo que es viable en algo que el cliente pueda aceptar. Esa traducción falla en los dos sentidos cuando no entiendes el terreno del que hablas.

Falla hacia el cliente cuando prometes algo que ABAP Cloud no permite hacer como lo hacía el ABAP clásico, por ejemplo modificar directamente una transacción estándar. Y falla hacia el equipo técnico cuando aceptas sin más una estimación inflada, o un “no se puede” que en realidad significa “no lo hemos intentado con el modelo de extensibilidad correcto”.

Hay una tercera forma en la que falla, más silenciosa. Cuando no entiendes el vocabulario básico, dejas de participar en la conversación técnica del proyecto y te conviertes en quien solo transmite mensajes entre dos partes que sí se entienden entre sí. Eso reduce tu peso en las decisiones, no porque nadie te lo quite, sino porque tú mismo te sales de la sala.

Ninguna de las tres cosas exige que sepas programar. Exige que entiendas qué es posible, qué es difícil y qué es simplemente distinto de como se hacía antes.

Lo mínimo que necesitas entender de ABAP Cloud

No necesitas el detalle de sintaxis. Necesitas cuatro ideas, y con ellas ya puedes seguir el noventa por ciento de las conversaciones técnicas de un proyecto S/4HANA actual.

Clean Core. Es la regla de que el sistema estándar de SAP no se toca. Todo lo que el cliente necesita de más se construye al lado, como extensión, nunca modificando el núcleo. Esto no es una preferencia de arquitectura, es la condición para que el cliente pueda actualizar su sistema SAP sin que sus desarrollos a medida se rompan cada vez. Cuando alguien dice “eso rompe Clean Core”, está diciendo que esa petición pone en riesgo la próxima actualización, no que sea imposible.

El modelo de extensibilidad. Toda funcionalidad nueva se construye sobre APIs que SAP libera y se compromete a mantener estables, o mediante puntos de extensión que SAP define de antemano. Si lo que pide el cliente encaja en una de esas dos vías, es viable y previsible. Si exige tocar algo que SAP no expone, no es que “no se pueda”, es que hay que buscar un camino distinto o negociar el alcance. Saber cuál de los dos casos tienes delante cambia toda la conversación con el cliente.

RAP, sin el detalle técnico. RAP es la forma en que hoy se construye un objeto de negocio nuevo en ABAP Cloud: una entidad con sus datos, sus reglas y su interfaz, todo definido de forma coherente y reutilizable en UI, en API y en informes a la vez. Lo que te interesa como funcional no es cómo se escribe, es que un objeto de negocio bien modelado con RAP se reutiliza en canales distintos sin reconstruirlo cada vez. Cuando estimas alcance, esa reutilización es la diferencia entre semanas y meses.

Las APIs liberadas. SAP publica un catálogo de APIs que se garantiza que van a seguir funcionando después de cada actualización. Cuando el equipo técnico dice “vamos por la API liberada”, está eligiendo el camino estable. Cuando dice que no hay API liberada para algo, esa carencia es un dato real de riesgo del proyecto, no una excusa, y es exactamente el tipo de cosa que debería llegar al comité de decisión con esas palabras.

Con estas cuatro ideas ya puedes hacer la pregunta que de verdad importa en una reunión de estimación: “¿esto se apoya en una extensión sobre una API liberada, o estamos tocando el núcleo?”. Esa sola pregunta separa una estimación seria de una que nadie ha verificado todavía.

Si quieres bajar estas cuatro ideas a algo más estructurado que una conversación, el curso S/4HANA Cloud: Modelo de extensibilidad Clean Core está pensado exactamente para este perfil: no enseña a programar, enseña a razonar el modelo de extensibilidad desde el rol de quien decide el alcance, no de quien escribe el código.

Un ejemplo real: la especificación que costó tres semanas de retrabajo

En un proyecto de retail que acompañamos, la especificación funcional pedía algo aparentemente simple: cuando se creaba un pedido de venta, el sistema debía calcular automáticamente un recargo si el cliente pertenecía a una categoría concreta, y escribir ese recargo directamente en la tabla del pedido antes de que continuara el proceso estándar. El equipo técnico lo estimó, lo construyó modificando el user exit correspondiente, y pasó las pruebas de aceptación sin problema.

Tres semanas después de la actualización trimestral del sistema, el recargo dejó de aplicarse en el quince por ciento de los pedidos, sin ningún error visible en pantalla. El user exit modificado dependía de un campo interno que SAP había reordenado en esa actualización, uno de los muchos detalles que un objeto no liberado no promete mantener estable. Nadie lo detectó hasta que finanzas revisó los márgenes del trimestre.

El arreglo correcto no era volver a parchear el user exit. Era modelar el recargo como una determinación dentro de un Business Object RAP para el pedido, apoyada en una API liberada para leer la categoría del cliente. Eso, construido desde el principio, habría costado prácticamente lo mismo que la primera versión. Reconstruido después del incidente, con la presión de finanzas encima, costó tres semanas y una revisión completa de otros cinco desarrollos con el mismo patrón.

La diferencia entre las dos versiones no estaba en el presupuesto ni en el equipo técnico. Estaba en si alguien, en la reunión de especificación, había preguntado si ese acceso directo a la tabla del pedido estaba liberado para ese uso.

Cómo esto te ayuda a defender al cliente

Aquí es donde el criterio técnico deja de ser cultura general y se convierte en tu herramienta de trabajo. Un consultor funcional que entiende estas cuatro ideas puede hacer tres cosas que uno que no las entiende no puede.

Puede filtrar una estimación antes de que llegue al cliente. Si una estimación de tres sprints se apoya en tocar un objeto no liberado, esa cifra no es solo alta, es frágil: sobrevivirá a la implementación pero no al primer upgrade. Señalarlo en la revisión interna, antes de comprometerlo con el cliente, es defender tanto el presupuesto como la relación.

Puede explicar un “no” sin perder autoridad. Cuando el cliente pide algo que rompe Clean Core, la respuesta “no se puede” suena a excusa. La respuesta “se puede, pero no así, porque esto pondría en riesgo la próxima actualización de tu sistema, y aquí está la alternativa que sí lo respeta” es la misma negativa, convertida en criterio profesional que el cliente puede entender y aceptar.

Y puede anticipar el riesgo real de un desarrollo antes de que se construya, no después de que se rompa. Volviendo al ejemplo anterior, esa pregunta, hecha a tiempo, no cuesta nada. Hecha después del incidente, cuesta tres semanas y la confianza del cliente en el criterio técnico de todo el equipo, funcional incluido.

Ninguna de estas tres cosas requiere que sepas escribir ABAP. Requiere que sepas hacer la pregunta correcta antes de que sea demasiado tarde para hacerla. Y si quieres profundizar en el porqué detrás de esta disciplina, no solo en el qué, el libro S/4HANA: Extensibilidad con Clean Core recorre el mismo terreno desde el key user hasta el developer, verificado en un sistema real.

Esta es, en el fondo, la guía que le daría a cualquier consultor funcional ABAP Cloud que empieza hoy en un proyecto S/4HANA: entender lo suficiente para hacer la pregunta correcta, no para escribir el código.