Cuando reducir los tiempos de entrega un 90% no parece suficiente

netzima

Hacia el final de los proyectos de implantación es habitual que recibamos emails reclamando que rebajemos aún más el tiempo del proceso de segmentación para las estructuras transferidas.

“Cuando recibes un correo pidiendo que rebajes aún más los tiempos de entrega sabes que el proyecto ya ha tenido éxito.”

En el punto en el que no se cuestiona la viabilidad del proyecto, sino si la entrega es suficientemente rápida, o podría serlo más, sabemos que estamos tratando los últimos matices. ¡La tarea de implantación de icaria ya es exitosa!

Nuestra experiencia implantando icaria TDM para reducir los tiempos de entrega

En nuestra experiencia, la implantación de una estrategia de segmentación dentro de la organización suele realizarse por primera vez con icaria

No obstante, encontramos que algunas organizaciones han llevado a cabo proyectos in-house muy específicos para cada aplicación de subsetting. Estas ya conocen las dificultades y retos de la segmentación. Y anticipan beneficios como la reducción del tamaño de los entornos, la repetición de movimientos o la entrega de estructuras aisladas, sin afectar al resto.

Dada la complejidad y costes de lo anterior, no es extraño encontrar otras estrategias alternativas más sencillas, a modo de ejemplo:

  • Scripts que ejecutan, principalmente, querys sobre las bases de datos implicadas para crear estructuras relativamente sencillas.
  • Automatismos para replicar las llamadas a los servicios de creación de recursos replicando funcionalmente los aplicativos del cliente.
  • Creación manual del recurso, completamente a mano.

De todas estas estrategias, quizá la última es de las más habituales. En cualquier caso, es común encontrar una combinación de todas ellas.

A pesar de esto, una vez entra en la organización la segmentación de datos con herramientas como icaria TDM, las dificultades y limitaciones anteriores se olvidan con facilidad. Lo que queda presente es la posibilidad de mover estructuras de forma ágil, con menor dependencia entre equipos, más cercanas a los datos reales y con menor tasa de error con respecto al tipo de petición solicitado.

Tiempos de entrega esperados 

En este punto, se comienza a cuestionar la velocidad del proceso de segmentación. Pero, ¿qué tiempos pueden esperarse?

En términos relativos, según los datos que hemos recabado, los tiempos son un 90% inferiores a los procesos previos, de media. Hablamos, en la mayoría de movimientos, de minutos, sino segundos. Solo en el caso de estructuras extremadamente complejas y grandes el movimiento puede trasladarse a algunas decenas de minutos, estos movimientos mueven cientos de miles de registros que se expanden ampliamente a lo largo del árbol de segmentación.

¿Y si vemos algunos ejemplos reales de cómo reducir los tiempos de entrega?

reducir los tiempos de entrega

De varios días a decenas de minutos

Estructuras que replicarlas en los entornos de prueba requerían de varios días, ahora se transfieren en cuestión de minutos, con máximos registrados de unos 90 minutos para los casos más extremos. Además, en este ejemplo, ahora se reduce el tamaño del movimiento con respecto a la solución anterior al permitir filtrar la estructura moviendo únicamente los datos de interés. Todo ello configurable por el peticionario para elegir qué estrategia le conviene en cada momento.

mover miles de estructuras

Miles de estructuras en unos pocos minutos

Movimiento del conjunto cliente, cuenta y otros datos bancarios, del orden de las 50.000 estructuras, en tiempos inferiores a los 30 minutos. Anteriormente este movimiento no era directamente replicable; requería la réplica y posterior segmentación de toda la base de datos, con todas las implicaciones negativas que esto tiene.

mover una suborganización

Moviendo una suborganización completa en cuestión de días

Movimiento de todos los clientes de una suborganización, magnitudes aproximadas de 5 millones de clientes, en unas 96 horas. Todo ello al tiempo que el entorno permanece disponible para otras pruebas. Permitiendo también el movimiento repetitivo de lotes de clientes para aquellas pruebas que fallan.

Reducir un 90% el tiempo de procesamiento no es suficiente

Volviendo a la cuestión inicial, llega un punto en el que todos los retos anteriores se han olvidado, se olvida la complejidad del proceso o la cantidad de registros que se inspeccionan por movimiento.

“La transferencia de un cliente puede afectar a más de 20.000 registros. Han de inspeccionarse de manera ordenada y tratarse meticulosamente. En estos órdenes de magnitud, el proceso difícilmente podrá ser de unos pocos segundos.”

Y a pesar de lo anterior se reclama una mayor eficiencia. Es comprensible, una vez la estrategia de segmentación entra en juego los equipos de desarrollo y pruebas suelen pensar en nuevas formas de explotar, usar y probar esta información, la exigencia se incrementa.

En la segunda parte de este post os contaremos a nivel técnico cómo afrontamos esta cuestión para la que, en muchas ocasiones, lo más sencillo desde nuestra perspectiva sería que mejorasen el rendimiento de las bases de datos involucradas en el proceso de transferencia.

Si quieres reducir tiempos y mejorar la calidad de tus pruebas, solicita ahora una demo en este enlace.

 

También te puede interesar:

¿Cómo automatizar TDM para ganar en agilidad y calidad?

Los datos de tus exclientes no son tus datos.

¿Cómo aplicar la disociación de datos en entornos de prueba?

Compartir:

Compartir en facebook
Compartir en twitter
Compartir en pinterest
Compartir en linkedin