Desafíos en la Limpieza de Datos en Comercio Exterior
Hace unos meses recibimos un reto que, en el papel, parecía sencillo: tomar datos de aduanas de siete países latinoamericanos, limpiarlos y organizarlos para que una multinacional de consumo masivo pudiera entender qué estaba pasando con sus insumos en la región. Construir una ETL. Automatizarla. Entregar.La realidad fue muy distinta. Lo que encontramos en el camino nos obligó a replantear la solución técnica, a cuestionar supuestos sobre la infraestructura en la nube y, sobre todo, a entender algo fundamental: cuando los datos son ingresados por personas, el verdadero reto no es tecnológico, es humano.
La tarea de limpiar y organizar datos de comercio exterior puede parecer sencilla, pero cuando se enfrenta a la realidad de múltiples países y cero estándares, se convierte en un desafío significativo. Este fue el reto que enfrentó Arcetec, al trabajar con datos aduaneros de siete países latinoamericanos para permitir que una multinacional de consumo masivo tomara mejores decisiones de compra.
El reto: siete países, seis productos, datos heterogéneos
Nuestro cliente necesitaba visibilidad sobre el comportamiento de importación y exportación de seis productos clave. La información existía en los registros aduaneros de cada país, pero cada nación tenía su propia estructura de datos, sus propios campos y sus propias reglas de reporte.
El mayor desafío estaba en los campos de texto libre. Las descripciones aduaneras son escritas por personas, con abreviaturas, errores de digitación y formatos que varían de un operador a otro. A veces la información relevante no estaba en un solo campo, sino dispersa en descripciones complementarias que había que concatenar para encontrar patrones útiles.
Y había una complejidad adicional: los cálculos necesarios y las columnas de salida cambiaban según el producto y el país. No estábamos construyendo un pipeline único, sino un sistema capaz de adaptarse a múltiples esquemas de entrada y salida simultáneamente.
Primer reto: desplegar en la nube
El plan original era desplegar la solución en Google Cloud Platform. Parecía la decisión lógica: escalable, robusta, automatizable. Pero dos factores nos frenaron rápidamente.
Primero, las restricciones del entorno del cliente limitaban las herramientas disponibles dentro de GCP. No teníamos libertad total para elegir servicios, lo que reducía nuestras opciones de arquitectura. Segundo, habíamos desarrollado con una muestra pequeña de datos, y cuando procesamos el histórico completo, la infraestructura se quedó corta.
Esta es una lección que vemos repetirse en muchos proyectos: la muestra de desarrollo no siempre revela los problemas de escala. Y descubrirlo tarde tiene un costo alto en tiempo y en expectativas.
Segundo reto: datos de entrada y salida variables
Lo que no se anticipaba, pese a que desde la propuesta comercial se contemplaba que los datos de entrada tendrían formatos distintos, cuando entramos a realizar el levantamiento y el Discovery, encontramos que los esquemas de salida también variaban. Es decir, no solo teníamos datos de entrada con esquemas diferentes por país, sino que tendríamos esquemas de salida con cálculos específicos por producto, lo que sumó una capa de complejidad importante.
En la práctica esto significaba que un mismo pipeline no servía para todos los casos. Cada combinación de país y producto podía generar un esquema de salida distinto, con columnas adicionales, cálculos específicos y reglas de validación propias. Diseñar una solución rígida habría implicado reescribir lógica cada vez que un nuevo escenario apareciera, algo insostenible en un proceso que debía ejecutarse automáticamente cada mes.
Tercer reto: información clave atrapada en campos de texto abierto
La información más importante para la categorización y los cálculos no se encontraba en campos estructurados. Estaba dentro de descripciones aduaneras redactadas por personas, y en muchos casos repartida entre más de un campo de texto libre.
Para ilustrarlo: una descripción podía decir "RLL PPL HIG BL 40M X30 DBL HJ" y de ahí el sistema debía deducir producto, color, metraje, cantidad de unidades por paquete y tipo de hoja. Pero el siguiente registro del mismo producto podía estar escrito de forma completamente diferente, con otras abreviaturas o con la información repartida entre el campo de descripción principal y un campo complementario que había que concatenar.
Este es el punto donde la influencia humana en el ingreso de datos se hace más evidente. No existe un estándar real entre operadores aduaneros de distintos países ni, muchas veces, entre operadores del mismo país. Cada persona escribe a su manera, abrevía como le parece y en ocasiones omite información que para el análisis resulta crítica. Cualquier regla de extracción que diseñáramos tenía que contemplar esa variabilidad como la norma, no como la excepción.
El giro: cuando el plan de contingencia supera al plan original
Frente a las limitaciones en GCP, el equipo había diseñado en paralelo un sistema de información alterno, pensado inicialmente solo para validar los volúmenes de datos históricos. Era una herramienta de soporte, no la solución principal.
Sin embargo, conforme lo fuimos perfeccionando, este sistema demostró capacidades que la solución en la nube no ofrecía: permitía que el usuario de negocio configurara parámetros directamente dentro de la herramienta para ajustar las reglas de transformación sin depender del equipo técnico para cada cambio. Además, incorporó visualización en dashboards, algo que el alcance original no contemplaba.
Tomar la decisión de pivotar no fue sencillo. Significó reevaluar alcance, tiempos y expectativas con el cliente. Pero el resultado fue una solución más completa, más autónoma para el usuario final y, en definitiva, superior a lo que habíamos concebido originalmente.
Lo que este proyecto nos enseñó
Probar con volúmenes reales desde el inicio.
Desarrollar con muestras pequeñas es eficiente, pero las pruebas de estrés con datos históricos completos deben hacerse temprano en el proyecto. Esto evita sorpresas de infraestructura que pueden retrasar semanas y erosionar la confianza del cliente.
Cuando hay influencia humana en los datos, la variabilidad es la norma.
Las reglas de extracción y transformación no pueden asumir consistencia en campos de texto libre. Invertir tiempo en entender cómo las personas escriben, abrevian y omiten información es tan importante como diseñar la arquitectura técnica.
Diseñar para la flexibilidad, no para un solo escenario.
Cuando los esquemas de entrada y salida varían por país y por producto, una solución monolítica se rompe al primer cambio de estructura. La modularidad no es un lujo, es una necesidad.
El Discovery es sagrado.
Lo que se asume en la propuesta comercial no siempre refleja lo que se encuentra al explorar los datos reales. El levantamiento detallado evita compromisos que luego son difíciles de cumplir.
Empoderar al usuario de negocio transforma el resultado.
Darle al equipo de negocio la capacidad de configurar parámetros y ajustar reglas dentro de la herramienta redujo cuellos de botella, mejoró la calidad del dato final y generó apropiación de la solución por parte del cliente.
Reflexión final
Detrás de cada dato hay una decisión humana: alguien que escribió una descripción en una aduana, alguien que eligió un formato, alguien que abrevía de una forma particular. La tecnología que construimos tiene que ser lo suficientemente inteligente para entender esa variabilidad, no para ignorarla.
En Arcetec seguimos trabajando con empresas que enfrentan este tipo de retos: convertir datos dispersos y desordenados en información clara que impulse decisiones. Si tu organización está lidiando con datos de múltiples fuentes, múltiples países o múltiples formatos, nos encantaría conversar.
¿Tienes un reto con tus datos?
Ayudamos a empresas a convertir datos dispersos en información accionable.
Hablemos de tu proyecto