Noticias

Estrategias para evitar fallos de integración de datos SAP

Ethan Jewett

Abundan las maneras en que pueden fallar los proyectos de integración de datos SAP, tal como lo han descubierto muchas empresas.

Tomemos el ejemplo de una empresa que está moviendo los datos de facturación de un sistema de ERP a un sistema de presentación de informes de inteligencia empresarial (BI), para realizar análisis sobre las facturas pendientes y la rentabilidad de acuerdo con el cliente y el producto. Tal vez se cargan demasiados datos, lo que duplica los valores de algunas facturas. Durante el proceso de prueba, la empresa encuentra que las cancelaciones no se están manejando correctamente. O tal vez ha descubierto que una pieza del rompecabezas de la rentabilidad, como lo son las comisiones de ventas, no aparece en el cuadro y que para completar el análisis los datos necesitan ser cargados desde un sistema separado.

Aunque es poco probable que una empresa detecte todos estos problemas tras una sola extracción y el informe del proyecto, cada uno de ellos podría ser un problema en los proyectos de integración de software. A veces parece que todo lo que puede salir mal, saldrá efectivamente mal, así que ¿por qué correr riesgos con estrategias de prueba inadecuadas?

Los proyectos de integración de datos SAP, especialmente en el almacenamiento de datos o BI, plantean diferentes desafíos cuando se trata de la estrategia de prueba más allá del tradicional desarrollo de la aplicación. Por ejemplo, las aplicaciones generalmente abarcan sistemas muy diferentes, haciendo que las herramientas de las pruebas tradicionales resulten inadecuadas.

Además, los proyectos de integración a menudo se conceptualizan de manera diferente a la de los programas tradicionales. El diseño se define en términos de ejemplos de registros de datos y campos, en lugar de hacerlo con una lógica específica de “si / entonces”.

Esto puede provocar dificultades en la aplicación de las metodologías tradicionales de prueba. Mientras que los conceptos de prueba utilizados para los programas tradicionales son casi siempre útiles en proyectos de integración, a menudo necesitamos volver a trabajarlos.

Incluso en un entorno todo SAP, donde se ha mitigado el problema de la expansión de sistemas heterogéneos, la integración puede seguir siendo un desafío. En un entorno heterogéneo, la prueba de integración de datos SAP se vuelve aún más problemática debido a la falta de herramientas de prueba y las diferentes arquitecturas de sistema. Me referiré a algunas estrategias y experiencias para hacerle pensar sobre cómo probar sus proyectos de integración.

Cobertura de la prueba en proyectos de integración de datos SAP

La cobertura de la prueba es una medición que identifica el porcentaje del proceso o del código de negocio que las pruebas controlan. La falta de la cobertura de la prueba puede causar problemas que se detectarán tarde en el proceso de desarrollo, o no se detectarán en absoluto. Una cobertura de la prueba completa significa identificar todos los tipos de transacciones que se tienen que transferir a través del código de integración y las pruebas de escritura para ellos. Esto asegura que hay casos de prueba para todos los tipos de transacciones.

Me tocó trabajar en un proyecto de integración de datos SAP para un cliente global, en la integración de los datos de un gran número de sistemas ERP, dentro un almacén de datos único. Mi equipo trabajó con los propietarios del sistema para encontrar maneras de probar los puntos de integración.

Durante el proyecto, la compañía introdujo un nuevo proceso de cierre del ejercicio financiero, junto con tipos de transacciones nuevas. Pero nuestro equipo no identificó el nuevo proceso como un caso de prueba, ya que se introdujo a finales del proyecto y fallaron los canales cruzados de comunicación del equipo. Las pruebas que diseñamos detectaron errores en otros procesos, pero el proceso de fin de año sin probar introdujo un error mayor de integración que consiguió pasar las pruebas de aceptación, porque nuestro código de integración no fue diseñado para manejar los nuevos tipos de transacciones.

Idealmente, cada tipo de transacción que fluye a través del código de integración estará cubierto por pruebas. Estos tipos de registros pueden ser entradas del libro mayor de facturas, devoluciones y asientos manuales. Cada tipo de publicación puede requerir una lógica diferente en el código de integración, por lo que la falta de cobertura de la prueba significa que los errores pueden deslizarse a través de ella. Las pruebas cubren los tipos de transacciones azules (facturas) y celestes (devoluciones), pero las transacciones de color gris (asientos manuales) no han sido probadas.

Para evitar estos problemas, debe identificar el tipo de transacciones que se moverán a través del código de integración y desarrollar las pruebas para cubrir todos los tipos que se esperan. A continuación, compruebe regularmente con las personas responsables de la integración de datos para asegurarse de que no se introduce ninguna transacción nueva o inesperada.

Dos estrategias de pruebas para la integración de software SAP

Frecuentemente los desarrolladores primero generan aplicaciones usando un pequeño subconjunto representativo de datos y luego ejecutan el escenario de integración con un conjunto completo de datos. A veces la lógica de integración parece funcionar bien en un subconjunto de datos, pero se ralentiza enormemente o nunca termina de ejecutarse cuando se utiliza con el conjunto completo.

Yo utilizo dos estrategias para evitar este problema:

  • Probar con conjuntos de datos realistas y de tamaño completo. Si tal conjunto de datos no estuviera disponible, tendrá que fabricarlo teniendo en cuenta la cuestión de la cobertura.
  • Analizar todos los requisitos temprano y con frecuencia. Esto es especialmente importante con los requisitos menos tangibles, tales como el rendimiento y la usabilidad.

Al probar integraciones, algunos evaluadores ven el resultado final del procesamiento de millones de registros y separan este resultado utilizando una serie de detalles clave como la empresa, el periodo de tiempo, la cuenta, el producto o el cliente. Si todas las dimensiones caen dentro de un umbral predefinido del valor esperado por ejemplo 1 % o 0,1 % entonces está todo bien.

Otros evaluadores observan los registros individuales que saben que son importantes y solo verifican si esos registros son correctos.

Considero a estas dos estrategias como probar “en grande” y “en pequeño”. Al “probar en grande” se observan los valores agregados a través de todas las transacciones y se verifica que estén dentro de un margen aceptable después de que el proyecto de integración de software se haya ejecutado. Al “probar en pequeño” se comparan los valores en los registros individuales antes y después de que el registro pase a través del código de integración, para asegurar que el resultado sea el esperado.

Me pareció que era suficiente con seguir estas dos estrategias por separado, hasta que en un momento al comienzo de mi carrera trabajé con alguien que las combinaba. Mi equipo notó que con las pruebas “en grande” aparecían problemas importantes que no habíamos anticipado “en pequeño”.

Mi colega identificó pequeños problemas en el sistema de prueba en un nivel alto, y luego examinó los datos a fondo hasta que encontró detalladas razones para cada discrepancia. Como resultado, a menudo encontramos problemas con la lógica de integración de negocio implementada en el sistema de prueba. Al final del proyecto, estas minuciosas sesiones de profundización en los números dieron lugar a mejoras significativas en la calidad del sistema.

Equilibrio de riesgo y recompensa

Al incorporar diferentes tácticas de pruebas también se hace necesario un equilibrio entre riesgo y recompensa. Diferentes organizaciones y situaciones exigen diferentes tolerancias de riesgo. Es importante la sensibilidad a las variables que controlan la función del riesgo, en el momento de desarrollar una estrategia de pruebas.

Un equipo de proyecto no puede probarlo todo. Los evaluadores necesitan encontrar un equilibrio entre el deseo de ofrecer una aplicación perfecta, y el presupuesto, los plazos y la capacidad del equipo para reaccionar ante los problemas. Centrarse en las áreas que son fundamentales para valorar la aplicación o las más difíciles de solucionar. La idea es ofrecer el mayor valor posible y darle al equipo la oportunidad de corregir más tarde los problemas descubiertos en el proyecto.

En una reciente actualización del software de datos de almacenamiento, surgió entre las diferentes personas involucradas en el proyecto el debate sobre el equilibrio entre riesgo y beneficio. En base a limitaciones de tiempo, las capacidades del equipo y el apoyo por parte del proveedor, el equipo adoptó una agresiva línea de tiempo. Este enfoque implicó un mayor riesgo porque había menos tiempo para probar y solucionar problemas.

El equipo desarrolló una estrategia de ensayo enfocada a las funciones centrales que el equipo no podría detectar si no era en vivo. Como resultado, el equipo identificó muchos problemas y los encaró al principio del proyecto. Aunque surgieron más inconvenientes en las áreas relativamente sin probar a poco tiempo de la entrega, el equipo manejó estos problemas y entregó una actualización mucho más rápida de lo que previamente había sido cumplida.


Unirse a la conversación Comenta

Compartir
Comentas

    Resultados

    Contribuye a la conversacion

    Todos los campos son obligatorios. Los comentarios aparecerán en la parte inferior del artículo