Conocimientos sobre proyectos SAP bajo demanda: el potencial de la IA para los entornos SAP

Alemania se enfrenta a una pérdida considerable de conocimientos técnicos. Según los cálculos de la Oficina Federal de Estadística, para 2040 unos 13 millones de personas en edad de trabajar habrán superado la edad legal de jubilación. Esto equivale al 30 % de la población activa actual. Con ello se perderá también un bagaje de conocimientos y experiencia acumulado a lo largo de décadas. Deloitte ya habla de un „éxodo del conocimiento“.

Según una encuesta propia, el 92 % de las empresas encuestadas no recopila ni documenta de forma sistemática los conocimientos de sus empleados que están a punto de jubilarse. Por ello, los conocimientos críticos suelen permanecer en las mentes de expertos concretos, en lugar de estar almacenados en los sistemas. Gartner también observa una creciente „brecha de conocimientos especializados“ debido a las jubilaciones y a los cambios tecnológicos, y recomienda a las empresas que organicen urgentemente la transferencia de conocimientos como un proceso continuo.

Esto también resulta crítico para muchos entornos SAP desarrollados a lo largo de los años, ya que, en este caso también, gran parte de los conocimientos técnicos reside en las mentes de desarrolladores y consultores experimentados. Por lo general, este problema se aborda con una amplia documentación y con personal de respaldo, pero la dificultad radica en el acceso a la información: tener que abrirse paso primero a través de una montaña de documentos solo para comprender un pequeño programa no solo es laborioso, sino que también requiere mucho tiempo y supone un elevado coste. La IA generativa ofrece ahora la posibilidad no solo de documentar parte de este conocimiento empírico, sino también de ponerlo a disposición de forma inmediata en el proceso de desarrollo.

El conocimiento tiene varios niveles

En el desarrollo de software basado en IA en el entorno SAP, se entrelazan tres niveles:

Conocimientos generales del modelo de IA: Un modelo de lenguaje conoce los lenguajes de programación, las arquitecturas de software típicas y muchos métodos de desarrollo habituales. Es capaz de generar, explicar o verificar código y conoce numerosos procedimientos documentados públicamente. Sin embargo, este conocimiento es de carácter general. En un primer momento, el modelo no sabe qué software utiliza una empresa concreta, ni cómo se organizan allí los procesos, ni cómo se han adaptado las aplicaciones de forma individualizada.

Conocimientos específicos de SAP: A esto se suma el conocimiento del universo SAP. Por ello, SAP complementa la IA generativa con información y funciones propias, por ejemplo, en Joule for Developers. De este modo, la IA puede tener en cuenta las reglas de desarrollo específicas de SAP o, en el caso de una transformación a S/4, analizar y adaptar los desarrollos propios existentes. Así pues, esta capa conoce las reglas técnicas y las particularidades de SAP, pero aún no conoce las particularidades de una instalación concreta de SAP en la empresa de un cliente.

Conocimiento de los clientes y de los proyectos: Esta tercera capa surge únicamente en cada empresa. Incluye definiciones propias, ampliaciones individuales, interfaces, estándares de desarrollo y decisiones que se tomaron en proyectos anteriores. También forma parte de ello la cuestión de por qué un proceso concreto se implementó exactamente así hace años. Ni SAP ni un nuevo modelo de lenguaje más potente pueden conocer automáticamente este conocimiento, ya que proviene del historial concreto del cliente y del proyecto.

El tercer nivel reviste especial importancia para los usuarios de SAP. Mientras que SAP proporciona los fundamentos tecnológicos y funcionales generales, las empresas de consultoría como Abat amplían esta base con el conocimiento sobre cómo está configurado concretamente el entorno SAP de cada cliente.

Conocimientos sobre el proyecto en formato legible por máquina

La empresa de servicios de SAP Abat ha desarrollado un enfoque propio para ello, en el que gran parte de los conocimientos de los desarrolladores y consultores se almacena en un formato legible por máquina. Esto se lleva a cabo mediante dos niveles de conocimiento: el primero consiste en las denominadas «habilidades». Se trata de archivos Markdown en los que los desarrolladores describen reglas y experiencias de tal manera que el Development Assistant pueda tenerlas en cuenta automáticamente. Esto incluye tanto conocimientos técnicos de desarrollo como el comportamiento de la IA: si falta información, el asistente debe preguntar, en lugar de inventarse una respuesta supuestamente plausible. Los conocimientos que antes se difundían a través de cursos de formación, wikis o la transmisión personal, ahora se incorporan directamente al desarrollo. A su vez, los nuevos conocimientos adquiridos en los proyectos se incorporan a las «skills».

El segundo nivel es una base de datos de incrustación o de vectores gestionada por la propia Abat. En ella se puede almacenar un conocimiento más amplio sobre la empresa y los clientes: documentación, términos, particularidades específicas de los proyectos o información sobre cómo se desarrollan concretamente determinados procesos. Esta base de datos puede conectarse a distintos modelos de lenguaje. De este modo se establece una separación de importancia estratégica: los conocimientos sobre desarrollo y clientes acumulados a lo largo de muchos años —es decir, uno de los activos más importantes de la empresa— siguen permaneciendo en la empresa. No obstante, es posible participar en el desarrollo tecnológico de la IA, ya que el modelo de lenguaje subyacente se puede sustituir en cualquier momento.

Directrices de desarrollo

Este enfoque resulta especialmente evidente en el caso de las normas específicas de SAP. Abat, por ejemplo, recoge competencias para el desarrollo de RAP, Clean Core o la programación compatible con HANA. A ello se suman sus propios estándares sobre modularidad, interfaces o facilidad de mantenimiento. De este modo, cambia la función de esta información.

Una especificación de «Clean Core» ya no se limita a un documento de arquitectura que el desarrollador debe conocer. Puede incorporarse directamente en la generación de código como una guía legible por máquina. En las conversiones a S/4, las reglas pueden tener en cuenta, por ejemplo, qué construcciones ABAP antiguas plantean problemas en HANA. SAP también sigue avanzando en esta dirección. La hoja de ruta prevé, entre otras cosas, el apoyo de la inteligencia artificial en los hallazgos de ATC relevantes para Clean Core, así como funciones de agente para ABAP.

Esto resulta especialmente interesante para los usuarios de SAP, ya que los nuevos desarrollos casi siempre se basan en ampliaciones existentes y reglas específicas del cliente. Cuanto más de esto esté disponible en formato legible por máquina, menos dependerá la calidad de los conocimientos específicos del desarrollador.

Sin embargo, el conocimiento legible por máquina no es automáticamente conocimiento correcto. También en este caso se aplica el principio de „si entra basura, sale basura“. Es posible que una documentación obsoleta se interprete erróneamente en alguna ocasión. En cambio, una regla legible por máquina que contenga errores se aplicará de nuevo cada vez que se presente una tarea que se ajuste a ella y puede acarrear graves consecuencias.

Por el contrario, también es necesario ampliar continuamente el nivel de conocimientos. En Abat, los desarrolladores prueban primero las novedades antes de que se conviertan en una norma general. Solo cuando una idea se ha probado exhaustivamente y ha sido aprobada por el „gatekeeper“ responsable, se lleva a cabo la implantación centralizada. Por lo tanto, cuanto más se automatiza el desarrollo, más importantes resultan unas responsabilidades y competencias claras en materia de mantenimiento y autorización.

Transición al problema del conocimiento

Para los directores de sistemas de información (CIO) de los usuarios de SAP, la ventaja radica sobre todo en la continuidad. Cuando se incorporan nuevos desarrolladores a un proyecto, tienen acceso inmediato a parte de ese conocimiento del proyecto a través del Development Assistant. A esto se suma una diferencia con respecto a la transferencia de conocimientos clásica: el conocimiento legible por máquina se puede reproducir. Si se mejora una regla o se corrige un error en la base de conocimientos, el cambio queda disponible para todas las instancias que trabajan con ella. Por el contrario, un nuevo empleado debe pasar primero por un proceso de incorporación y formación. Precisamente en los grandes proyectos de SAP con equipos cambiantes, esta capacidad de replicación puede suponer una ventaja considerable.

Pero no solo las personas amplían los conocimientos sobre una instalación concreta de SAP, sino también el propio entorno de desarrollo. Esto facilita los traspasos, reduce la dependencia de expertos concretos y hace que una parte de los conocimientos del proyecto, que hasta ahora dependían de personas concretas, esté disponible de forma permanente.

Prueba de resistencia en el sistema SAP

Un proyecto reciente de Abat demuestra lo relevante que puede llegar a ser esto. El punto de partida es un entorno SAP ya existente con una gran cantidad de código que el nuevo equipo no ha escrito por sí mismo; es decir, una situación que forma parte del día a día de muchos usuarios de SAP. En el primero de los siete paquetes de trabajo, el esfuerzo necesario fue más de un 50 % inferior a la estimación inicial.

Mientras trabaja, el asistente de desarrollo va adquiriendo cada vez más información sobre el sistema existente y, con ello, amplía sus propios conocimientos. Más tarde, se detectó un error en dicho sistema. A raíz de ello, el asistente indicó al desarrollador por dónde debía empezar, y el error se pudo solucionar rápidamente.

El conocimiento como activo estratégico

A medida que aumenta el uso de la IA, el contexto cobra cada vez más importancia, junto con el modelo. Para los directores de sistemas de información (CIO), la gestión estratégica del conocimiento cobra mayor relevancia: el conocimiento empírico debe registrarse y mantenerse de tal forma que siga estando disponible incluso tras cambios de personal o transiciones de proveedores. Para los usuarios de SAP, esto supone un nuevo activo. No solo cuenta el código, sino también la representación legible por máquina de por qué los procesos, el código y la arquitectura tienen el aspecto que tienen. Un entorno SAP consolidado se convierte en una memoria legible por máquina. De cara al futuro, este enfoque va mucho más allá de la programación. Abat está experimentando actualmente con la integración de especificaciones, decisiones, actas y glosarios. De este modo, los nuevos miembros del equipo podrían familiarizarse con el desarrollo del proyecto hasta el momento planteando preguntas específicas, en lugar de tener que leer grandes cantidades de documentación histórica.

Al directorio de socios: