Construyendo un bot con SAP Conversational AI

Como comenté hace unos meses, SAP Conversational AI es el nuevo nombre de Recast.AI, tras su compra por SAP.

Hoy vamos a ver cómo nos podemos dar de alta en el servicio y crear un bot de una manera muy sencilla.

Lo primero que tendréis que hacer es daros de alta en SAP Conversational AI, algo que seguro que sabéis hacer solos, a pesar del captcha y siempre que no (o sí) seáis un robot… 😉

Una vez que tenemos nuestra cuenta creada, estamos en disposición de crear nuestro primer bot.

Para ello, rellenaremos la información necesaria, como vemos en el siguiente vídeo:

Una vez creado el bit toca entrenarle, es decir, enseñarle a entender nuestras necesidades y esto se hace mediante el uso de intenciones y entidades.

Lo de las intenciones es algo parecido a lo que hacía Gila con Jack El Destripador, no es necesario decir las cosas textuales, sino que el sistema es capaz de detectar la intención de algo… 😉

Y las entidades son elementos que enriquecen nuestras intenciones.

Por ejemplo, en la frase “quiero comprar entradas de cine para mañana”, “ComprarEntradas” sería la intención y “cine” y “mañana” serían entidades.

Como hemos elegido un bot predefinido de greetings, hay ciertas intents que ya están predefinidas, cada una de ellas con sus expresiones asociadas en el idioma elegido.

Evidentemente, se pueden añadir nuevas expresiones y es recomendable que sean un mínimo de 30 y más de 50 si es posible, aunque esto no dejan de ser recomendaciones.

En este caso concreto, aparte de las intenciones @goodbye y @greetings, vamos a añadir una nueva (@chiste), reutilizando una existente y la probamos:

Nuestras intenciones pueden tener asociadas entidades, vamos a ver en este ejemplo, como al teclear “Adiós Antonio, hasta mañana”, el sistema es capaz de detectar 2 entidades (#datetime y #person) asociadas a la intención @goodbye.

Podemos crear también nuestras propias entidades, aunque hay cierta entidades que ya proporciona automáticamente el sistema, que son las denominadas gold entities. Aquí podéis ver un listado sobre las actuales: Gold Entities List

Una vez que hemos entrenado el bot, ahora toca construir nuestras skills.

¿Qué es una skill? Básicamente, un bloque de conversación (más o menos complejo), que tiene un propósito claro y nos lleva a conseguir un objetivo. Por ejemplo, que yo salude a mi bot y él me responda. Para ello, nos podemos valer de “disparadores” (triggers), requerimientos y acciones, como vemos en el siguiente vídeo:

Por supuesto, también te puedes crear tu propia skill, como veremos en el siguiente video. Las skills pueden ser de 3 tipos: business, floating y fallback.

Las 2 primeras son muy similares, una más centrada en el objeto concreto del bot (business) y la otra más genérica (floating) y por último tendré siempre una (y sólo una) fallback que se activará, si no se activa ninguna de las otras.

Y llegados a este punto y vista la “calidad” de los (no) chistes, ha llegado el momento de parar… mañana sigo 😉

¡Que la fuerza os acompañe!

Rumbo a la empresa inteligente

Hace unos meses me planteaba qué pintaba el tema de Design Thinking dentro de SAP Leonardo y terminamos viendo que podía tener sentido, a la hora de abordar los proyectos en nuestro camino hacia la empresa inteligente.

Ya sabéis, lo de los 3 pilares: suite inteligente, plataforma digital y tecnologías inteligentes.

Bien, pues para llegar ahí, una de las primeras cosas que tenemos que cambiar es la forma de afrontar los retos que se nos vienen por delante. No podemos seguir lanzando RFPs infumables y rellenando BBPs que nadie se lee, salvo cuando llega el momento de pelearse por los cambios de alcance… 😉

Toca trabajar de otra forma más ágil (que no Agile) y productiva y aquí es donde entran en juego algunas de las herramientas que se utilizan en Design Thinking, para conocer mejor los problemas de mis clientes y ofrecerles las mejores soluciones.

Estas serían las fases típicas de un proyecto de innovación: primero nos centramos en fijar e identificar el problema y después empezamos a probar y entregar soluciones al mismo.

Todo esto nos lo cuentan en el curso de openSAP: Design-Led Approach for the Intelligent Enterprise

En dicho curso podéis ver un ejemplo basado en una compañía de alimentación, en el que se analiza desde distintos puntos de vista cómo mejorar el rendimiento de la misma.

  •  Los clientes quieren poder consumir los productos que les gustan y muchas veces se encuentran que no están disponibles.
  • Los repartidores necesitan mejorar el proceso de recogida de productos en el almacén, así como la distribución en los distintos clientes

  • Al CIO, “sorprendentemente”, lo que le preocupan son los números y con la aplicación de tecnologías inteligentes (IoT, Machine Learning y análisis predictivo) podríamos encontrar una solución a sus problemas, así como a los de repartidores y clientes

  • En este punto llega el momento de especificar claramente el problema y empezar a pensar en posibles soluciones.

Lo demás, ya lo miráis vosotros, ¿no? 😉

Ah, que todos estos dibujitos os deberían ser familiares, si leísteis la entrada “¿Piedra, papel o tijera?”, que escribí hace año y medio.

¿Alguien lo ha utilizado alguna vez? Personalmente, sólo en formato PPT, nunca fui bueno en los “trabajos manuales”… 😉

Por cierto, esto mismo que se ve en el curso de openSAP se imparte en el curso presencial DLD100 – Design-Led Development – Getting Started with SAP Leonardo Methodology, con la “pequeña diferencia” del precio y de que en este caso puedes interactuar directamente con tus compañeros y el instructor.

Eso sí, que no os lleve a engaños el título, no se ve ningún producto de SAP Leonardo, se ve la metodología, tal y como indica en el título y se específica en el índice.

Es un curso más de “lápiz y papel”, aunque también utilizamos BUILD, por ejemplo. Y post-its, por supuesto… 😉

¿Quién ha hecho esta mierda de programa?

Si eres desarrollador, es probable que más de una vez se te haya venido esa frase a la cabeza al revisar el código de un programa. Y es también muy posible que ese “quién” fueras tú mismo… 15 años antes 😉

Que no siempre tiene porqué ser así, que hay gente que hace las cosas muy bien desde el minuto 1, pero aunque fuera así, me cuesta creer que ahora mismo alguien haría igual las cosas que hace 15 años, sobre todo teniendo en cuenta lo que ha avanzado la tecnología en este tiempo.

Sí, ya conozco la máxima de “si funciona, no lo toques”, pero es que si trabajas con SAP puede que las cosas dejen de funcionar en breve… ya sabéis, HANA, S/4HANA y esas cositas.

“¿¿¿Cómo??? ¿Pero es que las cosas no funcionan directamente más rápido por poner HANA?”.

Claro, claro que sí… es todo automático. Tú metes el “CD de HANA”, le das a “siguiente” unas cuantas veces y está todo listo.

A ver, si hace 20 años tú ya tuviste en cuenta que pasado un tiempo te iban a decir justo lo contrario (“mete caña a la base de datos, que la aplicación sea ligera”) de lo que te estaban diciendo en ese momento (“no leas mucho de la base de datos, mete caña en la aplicación”), puede que no tengas que revisar mucho… o si lo tienes todo estándar… porque, por supuesto, las buenas prácticas las has aplicado desde siempre, ¿no?

Si, por un casual, no tuviste en cuenta eso y tienes algún “zeta”, o no siempre has sido muy cuidadoso con las buenas prácticas, quizás sea el momento de que revises tu código ABAP.

No esperes al último momento y empieza con esa tarea, ya que obtendrás beneficios inmediatos (optimización del código existente, eliminación de programas obsoletos…) y te preparará mejor para lo que está por llegar, porque sí o sí, vas a pasar a S/4HANA… ¡y lo sabes!

Hace unos meses ya escribí una entrada sobre esto: Revisión de código para migrar a S/4HANA

¿Por qué lo recuerdo ahora? Pues porque es otra de las cosas para las que vas a necesitar las ABAP Development Tools (ADT), de las que os hablaba ayer, es para poder corregir automáticamente muchos de los errores de tu código.

¿Y esto cómo se hace? Pues, por resumir:

  1. Cargas la Simplication Database. Que es una lista que contiene las verificaciones a realizar.
  2. Lanzas el ABAP Test Cockpit (ATC). Una herramienta que busca esas verificaciones en tu código.
  3. Ejecutas la SPDD y la SPAU. Estas son viejas conocidas, ¿no?
  4. Vuelves a lanzar el ABAP Test Cockpit (ATC). Ahora en el sistema destino.
  5. Corriges el código con las ABAP Development Tools (ADT). Hay una perspectiva especial para leer los resultados del ATC.

¿Demasiado resumido? Tenéis todo el detalle aquí: Custom Code Migration Guide for SAP S/4HANA 1809

Venga, que aún estamos a tiempo de hacer bien las cosas y evitar que dentro de 15 años, cuando nos encontremos con nuestro código, vuelva a aparecer en nuestra mente la misma pregunta… 😉

ABAP Development Tools (ADT): ¿qué es esto?

Si eres un desarrollador ABAP y te preguntas esto: tienes un problema.

Vale que sigas haciendo tus cositas con la SE80 (incluso con la SE38), pero al menos tienes qué saber qué es esto de las ABAP Development Tools (ADT).

¿Por qué? Pues entre otras cosas porque puede que en poco tiempo todo lo que tengas que hacer por ahí, como ahora mismo tienes que hacer, sí o sí, lo de los Core Data Services (CDS), por ejemplo.

Y si no sabes lo qué es eso de los CDS, el problema que tienes es muy gordo 😉

Una pista: Core Data Services: ¿esto qué es?

Una vez solventados tus problemas, sigamos leyendo…

Las ABAP Development Tools (ADT), eso que a ti te aparece tan nuevo, aparecieron en al año 2012, y no dejan de ser una serie de componentes que se le añaden a Eclipse, para poder trabajar en ABAP desde ese entorno.

Si no sabes lo que es Eclipse, me rindo… 😉

El caso es que Eclipse hasta hace unos meses iba sacando una nueva versión cada año y SAP iba adaptando las ADT a cada una de esas versiones, al poco tiempo.

Muchas veces no era necesario actualizar, pero sí recomendable. Además, solía haber unos meses de decalaje entre que aparecía la nueva versión de Eclipse y la correspondiente de las ADT.

Los nombre de las versiones de Eclipse tenían que ver con temas “espaciales” (Mars, Neon, Oxygen, Photon…) pero desde septiembre del año pasado ha cambiado la nomenclatura y ahora son mucho mas sosas (aunque más útiles), del tipo AAAA-MM, es decir, 2018-09, 2018-12, etc…

Aquí os dejo el enlace a la última: Eclipse IDE 2019-03

De todas formas, no suele ser conveniente estar a la última, sino a la penúltima, por lo que os comentaba del tiempo de decalaje. Por ejemplo, a día de hoy, aún no están disponibles las ADT para esa versión, como podéis ver en SAP Development Tools.

Aparte de la nomenclatura, ha cambiado la frecuencia y ahora habrá actualizaciones trimestrales, con lo que el ritmo de actualización de las ADT se tiene que adaptar a esto.

¿Y es imprescindible seguir este ciclo de actualizaciones? Imprescindible, imprescindible, no… sobre todo, si me paso el día haciendo batch-inputs y ALVs… si uso CDS y AMDPs empieza a ser recomendable… y si tengo pensado hacer algo en ABAP en Cloud, entonces sí, entonces será imprescindible, ya que el servidor ABAP en Cloud será actualizado de manera automática (cosas de la nube) y necesitaremos la versión adecuada de las ADT para poder trabajar contra él.

Y, al igual que anteriormente, podremos trabajar siempre con 2 versiones anteriores, lo que pasa es que antes ese tiempo era de 2 años y ahora el tiempo se reduce a 6 meses; se supone que para poder tener ciclos de innovación más cortos, aunque alguno puede argumentar que es para volvernos más locos de lo que estamos… 😉

PD.- Información extraída de este artículo: Important changes to the ABAP Development Tools (ADT) release cycle

¿Quo Vadis, SAP?

Hace justo un mes escribí un artículo sobre SAP y la pérdida de talento, a raíz de las salidas de Thomas Jung y Rich Heilman, en el que planteaba la posibilidad de que Björn Goerke abandonara también la compañía, como finalmente ha ocurrido.

Por cierto, aquí os dejo su mensaje de despedida, todo un ejemplo: It’s official now – I’m moving on. It was a blast!

Dos meses antes había salido Bernd Leukert, miembro del comité de dirección, y hace una semana fue Robert Enslin, responsable máximo de la unidad cloud (SuccessFactor, Ariba, Concur, Fieldglass, hybris, Qualtrics) quien anunció su salida.

Evidentemente, no conozco a ninguno de ellos personalmente y tengo clarísimo que no hay nadie imprescindible (si tú crees que lo eres, háztelo mirar), como tampoco tengo elementos de juicio para valorar si estas salidas son acertadas o no.

Lo que sí son es sorprendentes, tanto las de la gente con “menos peso”, como pudieran ser Thomas y Rich, como la de los 3 pesos pesados. Desde fuera, parecía que estas personas estaban muy alineadas con la nueva línea de SAP (cloud, HANA, open innovation), pero es evidente que algo se nos escapa… 😉

Aquí os dejo algún artículo donde dan su opinión al respecto:

En cualquier caso, habrá que estar atento a los próximos movimientos, para ver si esto supone algún tipo de cambio en la estrategia general de la compañía… ¡a ver si ahora nos vamos a bajar de la nube! 😉

No creo que sea así, imagino que sus sucesores seguirán en la misma línea y que esto habrá sido simplemente un “cambio de cromos”, aunque sigo teniendo mis dudas sobre si en estos tiempos te puedes permitir una fuga de talentos de tal magnitud.

De todas formas, habrá que ver qué nos cuentan en el próximo SAPPHIRE NOW  de mayo en Orlando.

A mí lo que realmente me preocupa es quién va a continuar la saga de ciencia ficción de Björn Goerke en el próximo SAP Teched.

Lo mismo ahora nos cuentan una de romanos… 😉

SuccessFactors Q1 2019 Release Highlights

Como cada trimestre, SuccessFactors liberó hace unas semanas su paquete de novedades, donde podemos encontrar cosas como estas:

  • Core HR: una mayor integración con entre Employee Central y S/4HANA Cloud nos permite cargar el maestro de bancos automáticamente y no tener que mantenerlo en ambos sistemas (sí, amigos, antes era así); mejoras en la gestión de beneficios y en el Employee Service Center…

  • Recruiting: ahora podemos tener un “sitio de carreras” interno, al igual que lo teníamos hasta ahora con los candidatos internos. Además, podemos publicar directamente nuestras ofertas de empleo en nuestra página de Facebook corporativa.

  • Entorno colaborativo: mejoras en el módulo Presentations y en SAP Jam pudiendo, por ejemplo, editar directamente documentos de Microsoft Office.

Hay alguna cosa más, así que aquí os dejo donde ver más información:

Vamos, que ya estamos en el 2º trimestre… ¡y esto no para! 😉

SAP SuccessFactors Employee Central Payroll: ¿qué es esto?

SAP SuccessFactors Employee Central Payroll es un componente de SuccessFactors que calcula la nómina sobre un sistema SAP HCM on premise.

No es una nómina en la nube entendida como tal, como puede ser CloudPay.

No es lo mismo que SAP SuccessFactors Employee Central, que sería donde reside la información que vamos a utilizar para calcular la nómina.

Es una solución que soporta más de 42 localizaciones y lo que me permite es mantener la información necesaria desde SuccessFactors para que pueda ser utilizada por el motor de nómina, que es quien realiza los cálculos.

La clave de todo esto está en la integración, en tener claro qué hago en un lado y qué hago en otro. Básicamente, el esquema debería ser así:

  • SAP SuccessFactors Employee Central: aquí gestiono todos los datos maestros y de tiempos de mis empleados, algunos relevantes para la nómina como absentismos o pluses.
  • SAP SuccessFactors Employee Central Payroll: replica la información que le proporciona SAP SuccessFactors Employee Central, la traduce a información entendible por SAP HCM on premise (infotipos y esas cosas raras), realiza los cálculos correspondientes y envía la información relevante a otros sistemas (contabilidad, analíticas, el mismo Employee Central).
  • SAP HCM on premise: aquí es donde se realizan realmente los cálculos, con el motor de nómina de siempre.

La información de los datos de absentimos y pluses de tiempos debemos configurarla en SAP SuccessFactors Employee Central (EC) y el proceso de replicación será en el encargado de actualizar la información en SAP SuccessFactors Employee Central Payroll (ECP) con la frecuencia que determinemos para grabar la información en los infotipos 2001 y 2010 correspondientes.

¿Esto quiere decir que toda la información de tiempos la tengo que llevar en SuccessFactors? Yo no he dicho hecho, lo que sí digo es que tienes que decidir dónde la mantienes y tener claro el mecanismo de integración.

Personalmente, para un cliente que tenga la nómina en SAP y una gestión de tiempos complicada, no veo justificación para plantearse ir a SuccessFactors Employee Central Payroll, ni siquiera a SuccessFactors Employee Central, a no ser que tenga claro que renuncia a parte de su funcionalidad.

En lo que es la nómina, al final, el motor es el mismo, pero la gestión de tiempos de SuccessFactors, a día de hoy, creo que no tiene la misma capacidad que tiene la que conocemos. Si bien es cierto, que muchas veces con lo que ofrece SuccessFactors muchos de los clientes tendrían más que suficiente y que no vendría mal que muchos se replantearan sus procesos.

También es cierto que si necesitamos algo más completo, podemos utilizar Kronos, pero no nos liemos, que hoy estaba hablando de nómina 😉

Lo que tiene que quedar claro cuando voy a un escenario así es que el dato maestro está en SAP SuccessFactors Employee Central (EC) y no empecéis con que una cosa la mantengo en un lado y otra en otro porque luego vienen los líos.

Para el usuario final sólo existiría SAP SuccessFactors Employee Central (EC) y lo que haya por debajo le da igual. No debería ver nunca un infotipo, sólo “pantallitas” de SuccessFactors, nada de infotipos.

Aquí os dejo un enlace al documento del que he sacado esta información, que fue algo que se presentó en el SuccessConnect del año pasado en Berlín: SAP SuccessFactors Employee Central Payroll

Puede que haya información más actualizada, pero creo que este es un buen punto de partida para poder evaluar hacia dónde quiero llevar mi nómina… 😉