El lunes 14 y el martes 15 de Septiembre estuve en las oficinas de SAP en Madrid, en un workshop que llaman From Zero to Hero y que dedican a SAP Enterprise Service Management (ESM), y que resulta que no fue una sesión aislada sino una parada más de una gira que SAP está llevando por varias ciudades, lo cual ya dice algo sobre cuánto están apostando por posicionar este producto. La sesión fue intensa y, para variar, bastante práctica, que es justo lo que suelo echar en falta en este tipo de formaciones, donde a veces se pasa más tiempo mirando diapositivas que tocando el sistema. Aquí el primer día arrancó con teoría por la mañana pero a partir del mediodía ya estábamos metidos en un tenant real, y el segundo día fue prácticamente entero de configuración.
Abrió Carlos Martín, CX Innovation Principal y Business Architect en SAP Spain/EMEA, con la estrategia de IA de Business Suite y una demo de Joule Work como asistente conversacional, el punto desde el que se invocan los agentes especializados. A partir de ahí tomaron el relevo Bich Huyen Dang y Luca Hurst, que llevaron el resto del primer día y prácticamente todo el segundo, entre funcionalidad, arquitectura, integraciones y los ejercicios hands-on que le dieron a la sesión ese punto práctico que comentaba. También estuvieron, en distintos momentos, Carlos Pinto, solution advisor de Sales & Service Cloud V2, y Sebastián Ramos, el partner manager de SAP en España, que fue quien organizó todo esto para el ecosistema de partners CX del país.
Mi primera reacción, mientras iban pasando pantallas, fue de déjà vu total. Esto es Service Cloud V2, pensé, el mismo Agent Desktop, el mismo motor de casos, la misma base tecnológica que ya tengo certificada y que conozco de sobra. Ese déjà vu se hizo más fuerte todavía el segundo día, cuando entramos en funcionalidades de extensibilidad que son puro terreno conocido para mí, determinaciones, validaciones, external hooks, autoflows, todo eso lo tengo trabajado de sobra en varios proyectos de SSC V2. Reconozco que en esos tramos me desconecté un poco, no por falta de interés hacia ESM sino porque ya lo dominaba de memoria. No le quito valor por eso, para quien llega al workshop sin ese bagaje previo es contenido que sienta una base sólida, y tiene todo el sentido que una sesión pensada para «zero to hero» lo cubra. Pero con esa primera impresión, entre el Agent Desktop reconocible y la extensibilidad de toda la vida, podría haberme ido de ahí pensando que ESM no es más que un renombramiento comercial, otra etiqueta puesta encima de algo que ya existía. No es así, aunque entiendo perfectamente por qué uno puede llegar a esa conclusión si se queda solo con la superficie, así que merece la pena explicar con calma por qué no lo es.
Lo que realmente cambia
Que ESM esté construido sobre Service Cloud V2 es cierto, eso no lo voy a discutir. Pero ESM amplía ese núcleo con capacidades orientadas específicamente al Enterprise Service Management, entre ellas Self-Service, Forms, Integration Scenarios y Business Documents, recogidas en el Feature Scope y la documentación oficial de la solución. El cambio de fondo, en cualquier caso, es de alcance más que funcional: Service Cloud V2 está pensado para el cliente externo, y ESM abre ese mismo motor a cualquier «cliente interno», un empleado, un proveedor, alguien con una petición para HR, Finance o Procurement, enganchado directamente con S/4HANA y SuccessFactors.
Y aquí llegamos a lo que a mí particularmente me sorprendió, y lo digo con la honestidad de reconocer que no lo tenía nada claro antes del workshop: yo daba por hecho que esa capacidad de subir un documento y que la IA te lo lea, lo extraiga y lo cuelgue como anexo del caso, formaba parte de la licencia normal de Service. Pues no. Business Documents y Forms son funcionalidad exclusiva de ESM, así que si tienes Sales & Service Cloud V2 sin más, sencillamente no la tienes, por muy avanzado que tengas el resto del sistema.
Dos ejemplos concretos, y la letra pequeña que hay detrás
El workshop aterrizó todo esto con dos flujos de finanzas que ayudan a verlo con claridad.
El primero es el Payment Advice Process, donde llega un email, se abre un caso automáticamente, la IA extrae y categoriza los datos del documento adjunto (nosotros probamos con una factura de muestra pensada exactamente para ese ejercicio de extracción), se contabiliza el aviso de pago en S/4HANA Cloud y se cierra el caso. El segundo es el Accrual Posting, donde un empleado entra por SAP Workzone en modo autoservicio, rellena un formulario, el sistema categoriza y extrae la información, se contabiliza la provisión correspondiente y se actualiza el caso.
Después del workshop me puse a revisar la documentación oficial de integración, y el nivel de detalle que encontré confirma y a la vez afina bastante lo que vimos en directo. El escenario real que SAP documenta para S/4HANA Cloud Public Edition es de gestión de disputas: llega un email a un buzón compartido con una reclamación sobre una factura, ESM crea el caso solo, la IA extrae el número de factura, el importe y el motivo, el sistema va a buscar la partida abierta correspondiente en S/4HANA, el agente revisa los datos extraídos y crea la disputa con un solo clic. Es prácticamente el mismo patrón que vimos en vivo, ahora con nombre y apellido en la documentación técnica.
Y hay un matiz que no conviene pasar por alto: esa capacidad de extracción con IA, que SAP llama Business Information Extraction, requiere una licencia aparte de SAP AI Units. No viene incluida por el simple hecho de tener ESM.
Lo que comparten los dos flujos, más allá de ese matiz, es el patrón de fondo, no el resultado concreto. ESM se encarga de absorber buena parte del trabajo no estructurado, leer, clasificar, extraer, y de convertirlo en contexto accionable antes de ejecutar el proceso de negocio en el sistema de registro. S/4HANA sigue siendo la verdad contable de siempre. ESM es la capa que organiza qué hacer con todo lo que llega desordenado.
Mi lectura
Si me preguntas dónde está el verdadero poder de ESM, no está en la tecnología, está en la conexión. La tecnología ya la conocía de sobra de Service Cloud V2. Lo que realmente cambia el juego es enganchar ese mismo motor de casos con SuccessFactors por el lado del empleado y con S/4HANA por el lado del proceso financiero, y eso es lo que convierte una herramienta pensada para atención al cliente en columna vertebral de servicio para toda la empresa, no solo para el departamento que mira hacia fuera.
Y ahí es donde me queda la duda honesta, la misma que me llevo de casi todo lo que SAP viene empaquetando últimamente bajo la etiqueta de «AI-First«: cuánto de esto es genuinamente nuevo, y cuánto es reorganizar comercialmente capacidades que ya existían, envueltas en una etiqueta más vendible y con alguna licencia adicional que aparece cuando empiezas a bajar a la letra pequeña. No tengo esa respuesta cerrada todavía, ni pretendo tenerla. Lo que sí tengo claro, después de dos días viéndolo funcionar en un tenant real y de haber revisado con calma la documentación técnica al volver, es que la pregunta merece hacerse con datos delante, no con la campaña de marketing por delante.
Este artículo se queda en la crónica de esos dos días. La pregunta de fondo, qué es realmente SAP ESM y qué resuelve para una empresa más allá de la experiencia de la sala, merece su propio espacio, así que ya estoy preparando una segunda pieza dedicada solo a eso, apoyada en este workshop, en la documentación oficial que fui revisando después, y en nuestro sistema de demo además de los propios sistemas de demo de SAP (SDE 2.0), para poder mostrarlo con ejemplos reales y no solo en abstracto.
Jorge Ocampos 