Horario de los médicos del Código

Es sobre todo el contenido empresarial proporcionado lo que ha hecho y sigue haciendo que el software estándar de SAP sea tan deseable para los clientes de SAP. Pero también es la posibilidad de cambiar el software SAP.

Y cambiarlo de la forma en que las necesidades individuales del negocio y los procesos (propiedad intelectual, o PI para abreviar) requieran para su mapeo en el software.

Puede tratarse de pequeños cambios o mejoras del programa, como añadir un número de teléfono a un informe.

Sin embargo, también puede tratarse de componentes funcionales prácticamente nuevos o escritos por desarrolladores para apoyar o gestionar procesos empresariales específicos de la empresa, a veces muy granulares y diferenciadores de la competencia, como una solución de gestión de piezas de recambio de gran alcance o una aplicación industrial para el control de calidad.

Código personalizado

En los últimos 20 años, se ha generado un inmenso volumen del denominado código personalizado basado en métodos de lógica de programación en o por clientes de SAP de todo el mundo.

Este código de programa, incluidas las reglas o lógicas almacenadas, da vida en última instancia a las muchísimas transacciones SAP responsables del funcionamiento del software SAP en una empresa.

Dicho código personalizado se creó principalmente mediante programación Abap (codificación Abap). Abap es un lenguaje de programación (o, en el caso de Abap Workbench, un entorno de desarrollo) que permite tanto la programación no estructurada como la estructurada y la orientada a objetos.

Prácticamente a diario se sigue añadiendo nuevo código personalizado. No son infrecuentes diez millones de líneas de código, pero también el doble en el caso de una sola empresa.

El número de desarrolladores de aplicaciones SAP es ciertamente elevado. Las empresas emplean a veces a cientos de desarrolladores de programas SAP. E incluso en una empresa mediana, una división de desarrolladores de aplicaciones puede estar formada por un equipo de 15 o 20 programadores SAP.

Incluso un pequeño vistazo en profundidad a un sistema SAP o al código fuente SAP de una empresa presenta prácticamente de inmediato el código personalizado generado.

Esto puede implicar tres tipos de transacciones diferentes. Por un lado, las denominadas transacciones z y, por otro, las transacciones y.

Además, hay programas que incluyen transacciones con su propio espacio de nombres (en lugar de z o y), normalmente con el nombre de una empresa, que por cierto tienen que registrarse o iniciar sesión en SAP.

Prueba en Hana

La necesidad del cliente de poder utilizar precisamente este o aquel código personalizado a largo plazo es obvia. También en el mundo SAP on Hana; cuando se utiliza S/4 Hana, Suite on Hana (SoH), BW on Hana o el nuevo BW/4 Hana.

Para ello, es necesario analizar dicho código personalizado junto con las reglas del programa utilizadas o almacenadas, prepararlo para el nuevo mundo de la base de datos (BD) Hana, en pocas palabras, transferirlo mediante una conversión y probarlo.

Para ello, SAP proporciona las denominadas reglas de cumplimiento de código Hana (información al respecto, por ejemplo, en las notas SAP 1912445, 2251947) junto con instrucciones con listas de comprobación.

Este tipo de necesidad terapéutica tiene su origen en el cambio de arquitectura de la base de datos que SAP ha realizado con Hana. En pocas palabras, el procesamiento de código de Hana según un procesamiento de tablas de BD orientado a columnas que incluye reglas funciona técnicamente de forma diferente que con una BD Any-DB (DB2, Microsoft, Oracle) con orientación fila/columna que incluye índices, es decir, sin preclasificación durante las llamadas/el procesamiento.

Esta situación debe tenerse en cuenta mediante adiciones de programación o asignaciones que deben insertarse. En este caso, hay "cosas que hay que hacer", ya que, de lo contrario, un sistema sencillamente no funcionará en la nueva arquitectura.

También es importante tener en cuenta que, para beneficiarse del alcance o las ventajas de Hana, también deben aplicarse diversas mejoras en el código fuente.

Como esas optimizaciones apenas pueden hacerse manualmente, o son muy, muy difíciles de hacer, resulta casi imposible hacerlas manualmente.

Entre ellas se incluyen, por ejemplo: la optimización de construcciones de código fuente adicionales para aprovechar las ventajas de la base de datos Hana; la optimización del rendimiento, por ejemplo mediante reglas push-down; o bien: que partes de la funcionalidad empresarial se ejecuten o ejecuten en el nivel de la base de datos (filtrado, ordenación, etc.), y no en la capa de la aplicación.

Sin embargo, que el código personalizado existente (transacciones z e y, así como transacciones con su propio espacio de nombres) se comporte como se desea en el lado Hana después de una conversión depende siempre de varias circunstancias.

A veces se requieren análisis muy profundos del código fuente para aplicar con éxito la terapia de código.

Porque: sólo en el código fuente está la verdad de los hechos.

Y: Cualquiera que comience un despliegue on-Hana sin terapia de código corre el riesgo de que los programas tengan errores después de cambiar a un sistema on-Hana como S/4.

En pocas palabras: Las partes del programa en un sistema SAP on Hana basadas en código personalizado dejan de funcionar como de costumbre aquí y allá, con efectos negativos a veces sorprendentes para la empresa.

Según la experiencia actual, el cambio o conversión necesarios de una línea de código lleva unos diez minutos a un experto en código/desarrollador SAP.

El número de cambios en las líneas de código necesarios en el contexto de una conversión/migración depende, por supuesto, de cada caso.

Pueden ser 20, 200 o incluso 20.000 cambios. Por regla general, se trata de un trabajo de cambio masivo. Lo que lógicamente requiere un uso correspondiente de recursos, tiempo y costes.

Para los cambios importantes, entran en acción las fábricas de código o las unidades de programación deslocalizadas.

Para estos trabajos de modificación, la automatización mediante software tiene naturalmente sentido. Y no sólo para minimizar el tiempo necesario o los costes, sino también para garantizar una alta calidad constante y la correspondiente fiabilidad del proceso.

Automatización

Además, se pueden realizar optimizaciones mediante la automatización.

Lo ideal es que una herramienta de conversión de este tipo ofrezca una funcionalidad de análisis correspondiente con la que se puedan estimar con precisión los esfuerzos/hitos.

También debe poder trabajar junto con las herramientas proporcionadas por SAP, como Code Inspector o SQL Monitor, y complementarlas o ampliarlas.

Con el Inspector de código, por ejemplo, es posible comprobar los objetos del repositorio SAP. Y lo hace según diversos criterios. Por ejemplo, en relación con el rendimiento, la sintaxis, la seguridad o el cumplimiento de las convenciones de nomenclatura.

La herramienta también permite buscar palabras Abap (los llamados tokens). A continuación, el Inspector de código proporciona mensajes de error o advertencias o los enumera.

Se trata de una herramienta genérica que puede adaptarse fácilmente a circunstancias específicas.

Además, una herramienta de conversión debe basarse en algún tipo de metamodelo que permita encontrar cada línea de código sin lagunas, leerla, examinarla y cambiar automáticamente el código de acuerdo con los requisitos. De modo que, al final del día, pueda utilizarse un código sin errores para su uso en on-hana.

Según la experiencia de corporaciones internacionales, así como de medianas empresas, el uso de la sofisticada y muy potente herramienta para SAP Custom-Code permite realizar incluso grandes conversiones on-Hana en un periodo de una a dos semanas como máximo, incluyendo pruebas de integración técnica y listas para su aceptación por parte de los usuarios finales.

Por regla general, los usuarios finales no prueban completamente la funcionalidad después de una conversión. La práctica demuestra que los clientes se concentran en los procesos empresariales básicos.

Si hay tasas de error, se sitúan en el rango por mil. Si hay errores sistemáticos, se tienen en cuenta en el metamodelo.

A continuación, las líneas de código afectadas pueden volver a generarse rápidamente mediante la automatización y se corrige el error.

Además, la herramienta ofrece funciones con las que se puede optimizar el código. Esto se extiende a analizar si un código personalizado puede transferirse al estándar de SAP o, como ya se ha explicado, si un código existente puede minimizarse o reubicarse (de la capa de aplicación a la capa de BD) para mejorar un sistema Hana en términos de rendimiento.

Según la experiencia, en los sistemas SAP hay código latente que no se utiliza y que -tras examinarlo- puede eliminarse. Este código existente no utilizado puede representar hasta el 60% del total del código existente en un sistema.

Esta circunstancia puede denominarse "deuda técnica". Esta deuda técnica se ha acumulado en su mayor parte a lo largo del tiempo debido a un desarrollo ineficiente o a la generación de código personalizado en numerosos clientes de SAP, y sigue aumentando.

En el transcurso de una conversión on-hana, haría bien en reducirlos sistemáticamente.