Pues resulta que me he hecho arquitecto. ¿De esos que construyen casas?
No, de esos no. ¿De los que ven ceros y unos y entran en Matrix?
Bueno, no exactamente.
Me he hecho arquitecto de SAP Customer Experience.
¿Qué es ser arquitecto SAP Customer Experience?
Un arquitecto SAP Customer Experience es un experto en las funcionalidades clave que aportan las soluciones SAP CX que, como vimos en el artículo SAP Customer Experience (CX) son las siguientes:
Entonces ¿es un consultor experto en todas esas soluciones?
No, eso sería imposible. Ser experto en todo sería como ser un monje sabio en lo alto de una montaña… pero con acceso a SAP Launchpad y al Business Accelerator Hub. Improbable.
Tienes a tú disposición 3 dudas sobre CX. A partir de la cuarta tienes que abrir un caso en SAP for Me
Ser arquitecto SAP Customer Experience no significa saber hacer campañas automatizadas en Emarsys, modelar perfiles y audienciasen Customer Data Platform, configurar flujos de registro y consentimientos en Customer Data Cloud, construir catálogos y promociones en Commerce Cloud ni dominar los workflows y procesos guiados de Sales & Service Cloud v2.
Significa entender cómo todas estas soluciones encajan entre sí —y con el resto del ecosistema SAP (y no SAP)— para diseñar experiencias de cliente conectadas, consistentes y escalables. Y, cada vez más, saber cómo aplicar inteligencia artificial a los procesos CX con herramientas como el CX AI Toolkit, SAP Joule o Machine Learning para optimizar decisiones, recomendar productos o predecir el comportamiento del cliente.
La arquitectura general de SAP CX y sus componentes clave
Como estos componentes se interrelacionan entre si para dar solución a flujos completos
Las integraciones con SAP S/4HANA y otras soluciones
Las capacidades de extensibilidad con SAP BTP
Los aspectos clave de seguridad, gobernanza y diseño
Las buenas prácticas para definir una estrategia CX moderna
En otras palabras, no certifica que sepas implementarlo todo… pero sí que sabes cómo se debería hacer.
¿Es difícil?
Bueno, no es una certificación para empezar desde cero, eso seguro. Necesitas amplia experiencia previa en al menos una o dos soluciones SAP CX, entender el lenguaje técnico y funcional de SAP, y sobre todo, pensar en términos de arquitectura: ¿qué solución usar? ¿cómo encaja con lo que ya tiene el cliente? ¿qué impacto tiene a largo plazo?
Mi consejo: no la prepares como un examen más. Estúdiala como si fueras a construir una propuesta real para un cliente exigente.
¿Y ahora qué?
Ahora toca seguir aprendiendo. Ser arquitecto no es una meta, es un camino. Un camino en el que SAP actualiza versiones cada tres meses, lanza nuevas capacidades en BTP, y redefine constantemente cómo deberíamos diseñar experiencias de cliente.
¿Mi próximo paso? Aplicar todo esto en proyectos reales y seguir ayudando a empresas a dar ese salto hacia un Customer Experience conectado, inteligente… y humano.
Este webinar está pensado para responsables de TI, líderes de transformación digital y decisores que:
Ya tienen un CRM (Salesforce, Dynamics, SAP CRM OnPremise, SAP C4C…) y se plantean dar el salto a una solución moderna, robusta y preparada para el futuro.
Quieren entender por qué SAP Sales & Service Cloud v2 es la apuesta estratégica de SAP, con un roadmap claro y actualizaciones trimestrales.
Buscan una solución cloud-native, extensible mediante SAP BTP, y diseñada desde el inicio para integrarse de forma nativa con SAP S/4HANA y otras soluciones SAP.
Necesitan potenciar la experiencia de cliente (CX) en ventas y servicio, con herramientas como Pipeline Manager, Forecast Tracker, Deal Intelligence y Customer Insights.
Quieren incorporar inteligencia artificial (IA generativa, recomendaciones, automatización) sin depender de desarrollos complejos.
Están evaluando cómo afrontar una migración ordenada desde su CRM actual, minimizando el riesgo y maximizando el retorno de la inversión.
¿Y si eres consultor o desarrollador SAP CX?
Si estás aprendiendo SAP Sales & Service Cloud v2 en profundidad, te recomiendo seguir mejor mi blog. Este webinar está más centrado en visión estratégica, casos de uso y beneficios empresariales que en detalle funcional o técnico.
¿Por qué deberías conectarte?
Verás cómo SAP plantea la evolución natural del CRM con una solución centrada en la experiencia del usuario y la automatización inteligente.
Hablaremos de migraciones desde otros CRMs, con aceleradores y ayudas y cómo abordar el cambio con éxito.
Y, por supuesto, podrás hacer tus preguntas en directo.
Has escuchado el término, incluso alguna vez has puesto cara de póker asintiendo para que no se note que no sabes lo que es un Data Lake, ni para qué sirve. Puede que lo uses y sepas qué es, pero incluso si ya lo usas, siempre viene bien entenderlo desde la base.
Cuidado que en los Data Lake también hay monstruos del lago y suelen ser creados
¿Qué es un Data Lake?
Un Data Lake es un repositorio centralizado que permite almacenar datos en su formato original, sin necesidad de estructurarlos previamente. A diferencia de un Data Warehouse, que requiere transformar los datos antes de almacenarlos (ETL), el Data Lake sigue un enfoque de ‘esquema en lectura’ (Schema-on-Read), lo que significa que los datos se estructuran únicamente al momento de ser consultados, permitiendo analizarlos en el momento que se necesiten y de la forma que requiera cada caso de uso.
Es como guardar todos los ingredientes en una despensa tal cual vienen del mercado, para cocinarlos solo cuando sabes qué receta vas a preparar, en lugar de pre-cocinarlos todos de antemano. Esto da muchísima flexibilidad para adaptarse a cualquier «receta analítica» que se requiera en el futuro.
Diferencias entre Data Lake y Data Warehouse
Mientras que un Data Warehouse almacena datos procesados y estructurados (Schema-on-Write) para responder a preguntas específicas del negocio, un Data Lake conserva los datos en su forma original, permitiendo una exploración más amplia y flexible. Esta diferencia se traduce en una mayor capacidad para descubrir patrones y obtener insights no previstos inicialmente.
Pesadilla en la cocina
Características principales de un Data Lake
Bueno, vayamos por partes, ya sabemos, nivel teórico, lo que es un Data Lake, ahora toca ver qué características principales tiene.
Flexibilidad en el almacenamiento: Capacidad para almacenar datos de diversas fuentes y formatos, como registros de aplicaciones, datos de sensores IoT, imágenes, videos, etc.
Escalabilidad: Diseñados para manejar petabytes de información, adaptándose al crecimiento exponencial de los datos en las organizaciones.
Esquema en lectura: Los datos se estructuran al momento de ser consultados, lo que permite una mayor agilidad en la incorporación de nuevas fuentes de información.
Soporte para análisis avanzados: Facilitan la aplicación de técnicas de análisis de datos, aprendizaje automático y generación de informes en tiempo real.
Beneficios y Desafíos al implementar un Data Lake
Como toda solución tiene una serie de beneficios pero también una serie de desafíos o problemas potenciales. Muchos son evidentes, vamos a verlos.
Beneficios y riesgos asociados
Centralización de datos: Elimina los silos de información al consolidar datos de múltiples fuentes en un solo lugar.
Riesgo asociado: Pero cuidado que el objetivo no es tirar tu basura en el Data Lake y esperar a que «se haga la magia’. Si tus datos son basura, habrás creado un cubo de basura.
Reducción de costos: Al aprovechar tecnologías de almacenamiento de bajo costo, como las soluciones en la nube, se optimiza la inversión en infraestructura con modelos de pago como el pay-as-you-go (pago por uso)
Riesgo asociado: si basas todo tu análisis de datos en un Data Lake alojado en «La Nube™» y no controlas ese crecimiento, tendrás dependencia excesiva con el proveedor de soluciones en la Nube y tus costos pueden ampliar. Además existe un riesgo alto de Data Egress Cost (costo que cobran los proveedores de la nube por sacar datos desde su plataforma hacia otro sistema, servicio externo o Red).
Agilidad en el análisis: Permite a los científicos de datos y analistas acceder rápidamente a grandes volúmenes de información para realizar estudios y modelos predictivos.
Soporte para innovación: Facilita la experimentación con nuevos enfoques analíticos y el desarrollo de soluciones basadas en inteligencia artificial.
Desafíos y consideraciones
A nivel de desafíos a enfrentar tenemos:
Gobernanza de datos: Es esencial establecer políticas claras para la gestión, calidad y seguridad de los datos almacenados. Quién puede acceder a qué datos. La falta de control sobre accesos y calidad puede convertir el valor del dato en un riesgo operativo o legal.
Riesgo de «Data Swamp«: Sin una adecuada organización y catalogación, un Data Lake puede convertirse en un pantano (Swamp), en un repositorio desordenado y difícil de utilizar.
Voy a tirar mierda al lago a ver si se convierte en informes analíticos buenos
Integración con sistemas existentes: Es importante asegurar la compatibilidad y comunicación efectiva entre el Data Lake y otras plataformas de la organización.
Data Lakes en el ecosistema SAP
Obviamente, en este tema SAP no es ajeno y también ofrece soluciones que integran la funcionalidad de Data Lakes.
SAP HANA Cloud Data Lake
Permite almacenar y procesar grandes volúmenes de datos de diversas fuentes, tanto de SAP como de terceros. Esta integración facilita la realización de análisis avanzados y el desarrollo de aplicaciones inteligentes dentro del entorno SAP.
SAP Business Data Cloud
Además, en el último «SAP Unleashed» SAP anunció una revolución, SAP Business Data Cloud, donde recibir, adoptando funcionalidades propias de un Data Lake, pero con enfoque de productos de datos empresariales, datos estructurados o no estructurados de sistemas SAP o externos y desde ahí generar los «Data Products» correspondientes a conceptos de negocio. De esto ya hablaremos porque es una solución estratégica de SAP que vamos a ver en todo lo que hagamos de aquí a un tiempo.
Conclusión
Los Data Lakes representan una evolución en la gestión de datos empresariales, ofreciendo una plataforma flexible y escalable para almacenar y analizar información diversa. Pero no está exenta de desafíos y problemas, no vale tirar basura a un Data Lake.
Al adoptar correctamente esta tecnología, las organizaciones pueden mejorar su capacidad de análisis, fomentar la innovación y tomar decisiones más informadas basadas en datos. Y en el futuro presente de la Inteligencia Artificial podemos hacer beber a la IA de los datos del Data Lake para sacar conclusiones, tomar decisiones o analizar datos.
La Inteligencia Artificial se va a empachar de datos
Bueno, el título es bastante descriptivo, y no voy a repetir lo que ya puse como resumen en la cotraportada:
El debugging es una de las herramientas más importantes en cualquier tecnología de desarrollo de software, sin la cual el proceso de desarrollo sería como navegar en la oscuridad sin una linterna, ya que los errores serían difíciles de identificar y corregir. Domina el arte del debugging en SAP con esta guía práctica y detallada.
Este libro, pensado tanto para desarrolladores como para consultores funcionales, te ofrece los conocimientos y las técnicas imprescindibles para entender, analizar y resolver problemas en los sistemas SAP. A través de ejemplos claros y explicaciones paso a paso, aprenderás a enfrentarte a cualquier incidencia con seguridad y eficacia.
Esta guía presenta:
Las herramientas esenciales de debugging disponibles en SAP.
Estrategias prácticas para identificar y corregir errores en programas ABAP.
Casos reales y ejemplos que te ayudarán a aplicar los conocimientos.
Consejos y buenas prácticas para optimizar tu rendimiento en la resolución de incidencias.
¿Por qué?
Pues bueno, en principio porque podía hacerlo, por reto personal y satisfacción. No me va a proporcionar ningún tipo de rédito económico (a no ser que lo compréis masivamente y sea el nuevo Ken Follet). Lo que sí proporciona es imagen profesional que yo cuido mucho.
Voy tachando cosas de la lista:
Tener tres hijos
Plantar un árbol
Escribir un libro
Trabajar en una Big four
Trabajar en un cliente y ver a las consultoras llegar mientras afilo el cuchillo
Después de haber visto las opciones e información que ofrecen los Dumps en el sistema, y aprender a entenderlos en la entrada «Errores en SAP – DUMPs«, vamos a ver los distintos logs en el sistema que podemos consultar.
¿Por donde empiezo?
Y otra cosa no, pero SAP guarda todo tipo de logs durante el uso y ejecución de procesos. Además de la ST22 de gestión de DUMPs que ya vimos en la entrada anterior.
SM21 – System Log
Registra eventos importantes del sistema, como errores, advertencias, e información de diagnóstico. Es utilizado, principalmente, por los administradores de sistema para monitorizar y solucionar problemas relacionados con el rendimiento y la estabilidad del sistema SAP.
En SAP S4/HANA CRM, muy a mi pesar, mucha de la gestión de errores se pasa a esta transacción. Yo la odio un poco por eso, me parece una marcha atrás más que una evolución.
Precioso ¿no? ¡No!
SLG1 – Application Log
Registra mensajes específicos de la aplicación, que pueden ser generados por programas ABAP personalizados y estándar. Puede ser un poco complicado de entender, porque hay mucha información que, a priori, no vas a entender o no te va a interesar. Pero a veces si buscas por fechas/usuario consigues pistas para saber lo que está pasando.
La búsqueda también puede acotarse por Objeto y Objeto Inferior lo cual acota mucho, pero claro tienes que saber el error de qué objeto y subobjeto es.
En general es un log que suelo usar cuando lo habitual (mensajes directos de aplicación, Dumps) no me dicen nada.
ST01 – Trace de Sistema
El Trace de Sistema (ST01) se utiliza para monitorear y grabar llamadas al sistema, incluyendo acceso a archivos, RFC, y verificaciones de autorización. Es una herramienta vital para los administradores de seguridad y consultores técnicos para diagnosticar problemas de autorización y rendimiento, permitiéndoles identificar exactamente dónde y por qué fallan las transacciones.
Cuidado con este log, porque tenemos que activarlo, y podemos romper algo si lo dejamos activo (nunca en producción claro) y nos olvidamos, porque el log se sigue generando y al final algo se llena en algún sitio. Lo mejor es acotar, mediante el botón Filtros generales, el log a un usuario concreto, y además acordarse de quitar el Trace con el botón Trace OFF
Las sesiones de trace guardadas las tendremos disponibles dándole al botón «Evaluación», donde podremos acotar incluso sobre los resultados.
SMICM – HTTP Log
En la transacción SMICM accederemos al monitor del ICM (Internet Communication Manager) del sistema.
Este monitor es muy de Basis, pero dentro de él tenemos un log que podemos usar para identificar problemas. Para acceder a este log tenemos que darle, en el menú superior a:
Nos aparecerá un listado de mensajes complejo de este estilo.
Este log registra todas las solicitudes HTTP(S) hacia y desde el sistema SAP, incluyendo servicios web y Fiori. Puedo prometer y prometo, que dentro de todo esto yo he sacado oro de errores imposibles de sacar con el resto de herramientas. Servicios Web o comunicaciones HTTP si dan error nos pueden dar pistas. ¿Error de visibilidad entre máquinas? ¿Firewalls? ¿Certificados caducados? ¿hostnames erróneos?. Como antes he dicho, la intuición cuenta mucho en esto, pero que no sea porque no conocemos las herramientas.
ST11 – Ficheros de Log de Errores
You know where you are? You‘re in the jungle, baby. You‘re gonna die
La transacción ST11 en SAP permite a los administradores y desarrolladores acceder y revisar los ficheros de log del sistema para detectar y solucionar errores. Estos ficheros contienen información detallada sobre los errores del sistema, la ejecución de procesos, y eventos significativos que pueden afectar el rendimiento y la estabilidad del sistema. Ahora bien, esta por ver la vez en la que yo encuentre algo dentro de aquí, porque esto es la jungla.
SM37 – Job Log
Esta transacción es muy importante, proporciona detalles sobre la ejecución de procesos (jobs) en background, incluyendo Fecha/hora de Inicio, Estado, Duración, Retraso y log detallado.
Esta transacción da para un artículo en sí mismo junto con la SM36 y la ejecución en fondo de procesos, quizás lo haga, pero lo que hay que saber aquí es ver el detalle de los errores de aquellos jobs que están con error. Para ver el log detallado de un job en fondo erróneo tenemos que seleccionarlo y pulsar el botón Log job.
Por poner un ejemplo veríamos un detalle como el siguiente:
Donde vemos ya mensajes durante la ejecución, y vemos la clase de mensaje, el número de mensaje y el tipo. Así como los mensajes en orden de ejecución. Con la clase de mensaje y el numero de mensaje podemos buscar el error tal y como vimos en el artículo:
Si tienes Servicios SOAP publicados o consumes Servicios SOAP de otros sistemas y quieres ver los mensajes de entrada/salida y los errores de comunicación, debes usar la transacción SRTUTIL. Si no sabes lo que es un servicio web mírate la entrada
En la transacción SRTUTIL podremos ver el log de entrada/salida de los servicios web llamados por el usuario sobre el que levantemos la traza. Los logs SOAP son específicos para las interacciones a través de servicios web SOAP. Estos logs registran las solicitudes y respuestas de servicios web, incluyendo errores y la información de diagnóstico relevante.
Para activar la traza de SOAP en la SRTUTIL hay que seguir los siguientes pasos:
Si alguna vez publicas o consumes algún servicio SOAP, esta transacción la vas a tener que usar intensamente. En este artículo no vamos a explicar pormenorizadamente cómo usar esta transacción.
SU56 – Análisis Autorizaciones del Usuario
Otra de las fundamentales es la transacción SU56 que saca un trace de las autorizaciones por las que ha pasado un usuario durante el último proceso, ya sean autorizaciones válidas (verde) o autorizaciones faltantes (rojo).
Es muy importante cuando queremos modelar los perfiles de autorización en el sistema para que unos usuarios puedan ver ciertos datos/negocio/procesos o no.
Por defecto, al entrar, veremos nuestro log de autorizaciones. Pero podemos cambiar al log de autorizaciones de otro usuario cualquiera con el siguiente botón.
Report RSUSR200 de usuarios
Tenemos también a nuestra disposición el report RSUSR200 para visualizar la lista de usuarios del sistema, tipo de usuario, su estado, ultimo acceso, fecha de validez, etc.
En conclusión
Esto es un ejemplo de lo que veo más útil, seguro que me dejo muchas importantes, si es así lo ampliaré. Lo que me dejo seguro es Logs y Trazas sobre OData, pero eso irá en su correspondiente artículo de la serie OData y SAP Gateway.
Jorge Ocampos 