Categoría: Uncategorized

  • LLM en la atención al cliente con SAP: lecciones de un proyecto productivo

    Las compañías energéticas reciben cada mes miles de solicitudes de clientes, por correo y por teléfono. Muchas son casos estándar: planes de pago, aplazamientos, copias de facturas, mudanzas. Los grandes modelos de lenguaje (LLM) pueden asumir gran parte de este trabajo, pero solo si se conectan a SAP de forma segura y fiable. Estas son las lecciones de un proyecto productivo.

    Empezar con casos de negocio claros y de alto volumen

    «Usar IA en atención al cliente» no es un caso de uso. Los siguientes sí lo son, y juntos cubren gran parte de la carga diaria:

    • Planes de pago: reconocer la solicitud, comprobar las condiciones y crear el plan de pagos a plazos en SAP S/4HANA Utilities.
    • Aplazamientos: conceder un aplazamiento del vencimiento dentro de reglas definidas.
    • Copias de facturas: identificar al cliente y la factura y enviar la copia automáticamente.
    • Mudanzas: registrar los datos de alta y baja y lanzar el proceso de mudanza en SAP.

    Clasificación de correos con IA

    Cada correo entrante es clasificado por el LLM: ¿de qué caso de negocio se trata, qué cuenta contrato, qué datos faltan? Los casos claros se procesan automáticamente; los demás se derivan al equipo adecuado en SAP Customer Engagement, con un resumen precompletado y una respuesta sugerida.

    Conectar la línea de atención: Cognigy y SAP

    Los mismos casos de negocio están disponibles por teléfono. Un voicebot basado en Cognigy atiende las llamadas, identifica al cliente y ejecuta la solicitud directamente en SAP, por ejemplo el envío de una copia de factura o el registro de un aplazamiento, sin esperas.

    Arquitectura: Azure, Databricks y SAP BTP

    • Azure OpenAI proporciona el modelo de lenguaje, alojado en una región que cumple los requisitos de protección de datos.
    • Databricks se utiliza para la preparación de datos, la analítica y los pipelines de IA alrededor del modelo.
    • SAP BTP Integration Suite es la capa de integración: valida la salida del modelo, la enriquece con datos maestros, llama a las API de SAP correctas y gestiona los errores.
    • SAP S/4HANA Utilities y SAP Customer Engagement siguen siendo los sistemas de referencia para todas las transacciones.

    Importante: el LLM nunca se comunica directamente con el back end de SAP. La capa de integración mantiene SAP coherente incluso cuando el modelo se equivoca.

    Mantener a una persona en el circuito

    Los casos dudosos pasan a un agente, con la sugerencia de la IA adjunta. La proporción de casos totalmente automatizados crece paso a paso, basándose en evidencias, no en esperanzas.

    Protección de datos y autorizaciones

    • Defina dónde se ejecuta el modelo y qué datos puede ver.
    • Utilice usuarios técnicos con autorizaciones mínimas para cada llamada al sistema.
    • Registre las decisiones para que puedan rastrearse y auditarse.

    Planificar la operación desde el principio

    Una solución de IA nunca está «terminada». Los prompts, los modelos y las versiones de SAP cambian. La monitorización, un proceso de versiones mediante ChaRM o Cloud ALM y un responsable claro son imprescindibles. Siga también de cerca las ofertas propias de SAP, como SAP AI Core, Joule y el Model Context Protocol (MCP).

    Conclusión

    La IA en la atención al cliente con SAP funciona cuando se trata como un proyecto de integración y gobierno, no solo como una cuestión de modelo. Conozca nuestros servicios de IA en SAP o contáctenos.

  • Ley eléctrica suiza (Mantelerlass, LEG, vZEV) en SAP S/4HANA Utilities

    El mercado eléctrico suizo vive su mayor cambio en años. Con la Ley federal sobre un suministro eléctrico seguro basado en energías renovables (conocida como «Mantelerlass»), aprobada por los votantes suizos en junio de 2024, las comercializadoras y distribuidoras deben soportar nuevos modelos de mercado, y deben hacerlo en SAP IS-U o SAP S/4HANA Utilities.

    Qué cambia para las compañías energéticas

    • Comunidades eléctricas locales (LEG): consumidores y productores de un mismo municipio pueden compartir la electricidad producida localmente a través de la red pública, con tarifas de red reducidas.
    • Agrupaciones virtuales de autoconsumo (vZEV): más opciones de autoconsumo conjunto detrás del punto de conexión.
    • Modelos tarifarios dinámicos y nuevos, además de requisitos adicionales de medida e intercambio de datos.

    Qué significa esto en SAP

    En SAP S/4HANA Utilities estos requisitos afectan a la estructura de aparatos e instalaciones, la facturación y el diseño de tarifas, la gestión de datos energéticos (EDM), la comunicación de mercado y el front end del cliente. A los cambios funcionales se suman los técnicos: nuevas apps Fiori, nuevos roles y autorizaciones, interfaces adaptadas y un proceso limpio de transporte y puesta en marcha.

    Lecciones de la práctica

    • Las autorizaciones están en la ruta crítica. Las nuevas transacciones y apps Fiori necesitan roles, y las autorizaciones faltantes están entre los problemas más habituales en la puesta en marcha. Haga trazas pronto y pruebe con usuarios realistas.
    • Primero, la funcionalidad estándar. SAP y los partners del sector entregan cada vez más contenido regulatorio: revíselo antes de desarrollar código propio.
    • Planifique con cuidado los transportes y ChaRM. A menudo varios proyectos regulatorios se ejecutan en paralelo sobre el mismo sistema; sin coordinación, los conflictos son inevitables.
    • Involucre pronto al partner de operación para roles, transportes y copias de sistema.

    Cómo podemos ayudar

    Hemos implementado requisitos de LEG y Mantelerlass en S/4HANA Utilities, incluidos conceptos de autorización, roles Fiori, transportes y acompañamiento de la puesta en marcha. Conozca nuestros servicios de S/4HANA Utilities o contáctenos.

  • De SAP PI/PO a Integration Suite: guía práctica de migración

    SAP Process Orchestration (PI/PO) sigue soportando interfaces críticas en muchos entornos SAP. Con el fin del mantenimiento estándar de SAP PO 7.5 a finales de 2027 y un mantenimiento extendido ofrecido hasta 2030, es el momento de planificar el paso a SAP Integration Suite. Así abordamos una migración de este tipo en la práctica.

    1. Empezar con un inventario completo

    Antes de migrar nada, registre cada escenario de integración: emisor y receptor, tipos de adaptador, mappings, volúmenes de mensajes, tasas de error y responsable de negocio. En la mayoría de los entornos, una parte sorprendente de las interfaces ya no se usa o puede sustituirse por API estándar. Cada interfaz que retire es una que no tendrá que migrar.

    2. Decidir: trasladar, rediseñar o sustituir

    • Trasladar: los escenarios simples y estables a menudo pueden moverse con las herramientas de migración de SAP y pequeños ajustes.
    • Rediseñar: los mappings complejos o los procesos BPM suelen reconstruirse mejor como iFlows limpios con scripts Groovy y componentes reutilizables.
    • Sustituir: cuando SAP o el sistema socio ofrecen una API moderna, úsela en lugar de una interfaz de ficheros o IDoc.

    3. Resolver pronto la seguridad y la conectividad

    La mayoría de los retrasos no se deben a los mappings, sino a la conectividad: configuración de SAP Cloud Connector, certificados, clientes OAuth, usuarios técnicos, aperturas de firewall y claves SFTP. Planifique estos temas desde el primer día con su equipo de BASIS y su partner de hosting, especialmente en RISE with SAP, donde las responsabilidades se reparten entre usted, SAP y su operador.

    4. Establecer el gobierno de BTP

    Integration Suite forma parte de SAP BTP. Defina el modelo de cuentas y subcuentas, las convenciones de nombres, la ruta de transporte (p. ej. con SAP Cloud ALM o el Transport Management Service), la monitorización y las alertas, y quién puede desplegar qué. Sin estas reglas, la nueva plataforma se vuelve rápidamente tan desordenada como la antigua.

    5. Migrar por oleadas y en paralelo

    Agrupe las interfaces en oleadas según proceso de negocio y riesgo. Pruebe de extremo a extremo con negocio, cambie oleada a oleada y mantenga el sistema PI/PO disponible como respaldo hasta que la última oleada sea estable.

    Conclusión

    Una migración de PI/PO es una oportunidad para ordenar su entorno de integración, no solo una obligación técnica. Si desea apoyo con el inventario, la arquitectura o la implementación, contáctenos, o lea más sobre nuestros servicios de SAP BTP e Integration Suite.