Pregúntale a un analista por qué el informe de variación mensual lleva tanto tiempo y la mayoría señalará al mismo culpable: nadie en el equipo sabe programar. La solución suena obvia. Aprendes Python, aprendes SQL o esperas a que un ingeniero de datos se libere. Pero esas soluciones nunca parecen solucionar el problema principal. El informe lleva días porque los pasos para convertir una exportación del libro mayor en un informe de variaciones finalizado no están documentados en ningún lugar, salvo en la memoria de un analista, una carpeta llena de hojas de cálculo y un conjunto de fórmulas VLOOKUP que se vuelven a crear desde cero en cada ciclo. Nadie documentó el proceso de una manera que una máquina pudiera repetirlo, y eso no tiene nada que ver con saber programar.
Esta es la brecha que atrapa a muchos analistas sénior. Ya sabes SQL lo suficientemente bien como para extraer lo que necesitas. Ya sabes Excel lo suficientemente bien como para darle forma. Lo que no tienes es una forma de guardar ese trabajo como un proceso en lugar de una tarea puntual. Por lo tanto, terminas reconstruyéndolo todos los meses, en cada cierre y en cada ciclo de generación de informes, y el costo no deja de acumularse.
El código no define un pipeline
Un pipeline de datos es un conjunto repetible de pasos: extraer datos, limpiarlos, darles forma y enviarlos a algún lugar útil. Lo que lo convierte en un pipeline es que esos pasos se ejecutan de la misma manera cada vez, sin que alguien rehaga manualmente cada uno a mano. El código es una forma de capturar esa lógica. Un lienzo visual y sin código es otra. Que se utilice un script o no es irrelevante. Lo que importa es si la lógica se captura una vez, en una forma en que el equipo pueda volver a ejecutarla, auditarla y transferirla. Una reconstrucción de tres días en Excel y una ejecución automatizada de dos minutos pueden procesar exactamente los mismos datos mediante las mismas transformaciones. La única diferencia es dónde reside la lógica.
El método: crear un pipeline sin escribir un script
Los pasos a continuación ofrecen un proceso de muestra, independiente de cualquier herramienta en particular. Son las mismas cinco acciones, independientemente de que el pipeline termine creado mediante un script o en un lienzo visual.
Paso 1: conectarse directamente a donde residen los datos
En lugar de pedirle a alguien de contabilidad que exporte el libro mayor a un archivo CSV y lo envíe por correo electrónico, conéctate directamente a la fuente (base de datos, unidad compartida o ubicación de almacenamiento en la nube), de modo que la misma conexión se ejecute en cada ciclo sin necesidad de intervención humana. Una herramienta Datos de entrada, por ejemplo, permite configurar una sola vez una conexión a un tipo de archivo, una base de datos o un patrón comodín que coincida con “todos los archivos que comiencen con la convención de nomenclatura de este mes” y reutilizar esa conexión de forma indefinida.
Paso 2: capturar la lógica de limpieza una vez
Los analistas pasan la mayor parte del tiempo eliminando espacios en blanco de los códigos de cuenta, estandarizando el formato de las monedas y decidiendo qué hacer con una celda en blanco frente a un cero real, todo de forma manual. Un paso de limpieza de datos convierte esas decisiones en una configuración que se establece una sola vez para gestionar valores nulos, estandarizar mayúsculas y minúsculas, y mucho más, de modo que nadie tenga que realizar estos pasos de memoria en cada cierre.
Paso 3: estandarizar la estructura antes de que pase a la siguiente etapa
Los sistemas de origen cambian nombres de campos, agregan columnas o cambian un tipo de dato sin previo aviso. Gestionar explícitamente la selección y asignación de tipos de las columnas y permitir que un paso ajuste automáticamente el tamaño de los campos para adaptarlos a los datos son acciones que evitan que un pipeline se interrumpa unos meses después, en lugar de asumir que el archivo de entrada siempre tendrá el mismo formato.
Paso 4: programarlo para que nadie tenga que recordar ejecutarlo
Un pipeline que todavía requiere que alguien lo abra y haga clic en “ejecutar” todos los meses está organizado, pero no automatizado. La programación convierte el proceso en algo que se ejecuta por sí solo, con la cadencia que establezcas.
Paso 5: gestionarlo y monitorearlo como infraestructura, no como un archivo personal
Una vez que el pipeline se ejecuta por sí solo, debe dejar de ser el archivo de una sola persona. Eso significa que se almacena en un lugar donde el equipo pueda encontrarlo, cuenta con un historial visible de cambios y alguien que no sea su creador original puede abrirlo y entender lo que hace cada paso. Esto es lo que convierte el flujo de trabajo de una sola persona en algo en lo que el equipo puede confiar, independientemente de quién esté ausente.
Puntos de falla comunes una vez que el proceso está en funcionamiento
El error más común proviene de asumir que “sin código” significa “no se requiere pensar”. Considera la deriva del esquema, que ocurre cuando alguien modifica el nombre de una columna en una etapa anterior y un pipeline diseñado para esperar el nombre antiguo se interrumpe o descarta el campo. La coincidencia de archivos mediante comodines puede seleccionar el archivo equivocado si las exportaciones de dos meses comparten un patrón de nomenclatura. Y un pipeline que se crea una vez y nunca se vuelve a revisar puede seguir ejecutando la lógica incorrecta indefinidamente, ya que nada obliga a volver a revisarlo, como sí sucede con un proceso manual cuando alguien se da cuenta de que algo no está bien.
Otro tipo de falla que es fácil pasar por alto es el éxito silencioso. Un pipeline programado que se ejecuta a tiempo, pero procesa un archivo vacío o uno parcial, reportará una tarea completada sin errores, y nadie mira dos veces una marca de verificación verde. Incorporar al propio pipeline un paso básico de recuento de filas o comprobación de valores nulos, de modo que señale un resultado inusualmente pequeño en lugar de finalizar sin más, es una medida de protección económica que la mayoría de los procesos manuales obtienen de forma natural, ya que una persona que realiza el trabajo manualmente suele notar que algo no está bien en un archivo antes de terminar.
Esto coincide con un cambio más amplio que los analistas de la industria han estado siguiendo. A medida que las arquitecturas de pipelines reemplazan cada vez más los trabajos de ETL estáticos y de una sola ejecución, la calidad de los datos deja de depender de una única limpieza y pasa a ser un proceso continuo y adaptable. El pipeline sigue funcionando a medida que los propios datos de origen siguen cambiando.
Un pipeline terminado frente a un proceso que se reconstruye todos los meses
Tomemos el informe de variaciones mencionado con anterioridad. Reconstruido manualmente, depende de que un analista recuerde que una entidad de servicios compartidos siempre registra su eliminación intercompañía con un día de retraso debido a una diferencia de zona horaria con la oficina regional a través de la cual presenta sus informes, una solución alternativa que solo existe en la memoria de ese analista. Capturado como un pipeline, ese ajuste se convierte en un paso documentado que cualquier miembro del equipo puede consultar, cuestionar y mejorar. El informe que antes tardaba días en reconstruirse ahora tarda minutos en ejecutarse. El beneficio más duradero es que la lógica de negocio permanece incluso cuando la persona que la creó ya no está, y eso es lo que permite que un controlador se sienta cómodo aprobando cifras generadas, en parte, mediante automatización.
Puestos uno al lado del otro, la diferencia va mucho más allá de la velocidad. Se trata de si el proceso puede mantenerse cuando alguien se ausenta por enfermedad, cambia de puesto o simplemente olvida un paso varios ciclos más adelante:
| Dimensión | Se reconstruye cada mes | Se captura como pipeline |
|---|---|---|
| Tiempo por ciclo | De horas a días, se rehace desde cero cada vez | Minutos, se ejecuta según una programación |
| Consistencia | Depende de quién lo reconstruya y de lo que recuerde incluir | Mismos pasos, mismo orden, en cada ejecución |
| Auditabilidad | La lógica reside en la cabeza de una sola persona y en un stack de fórmulas | La lógica es una secuencia visible y documentada que cualquiera puede abrir |
| Transferencia | Engorroso; un analista nuevo comienza desde cero, con una hoja en blanco | Sencillo; cualquier miembro del equipo puede consultar los pasos |
El código sigue siendo la mejor opción en algunos casos específicos
Nada de esto significa que un pipeline basado en código sea la opción incorrecta; simplemente depende de lo que el pipeline necesite hacer. Un enfoque visual y sin código es adecuado para el tipo de procesos con los que trabajan la mayoría de los analistas, como uniones, filtros, limpieza, agregación y ejecuciones programadas con un número manejable de fuentes. Python, dbt o un pipeline mantenido por ingenieros de datos son opciones más adecuadas cuando la lógica implica cálculos recursivos complejos, procesamiento distribuido a gran escala o cuando el equipo necesita las mismas prácticas de control de versiones basadas en git y revisión de código que utiliza el resto de la organización de ingeniería. La pregunta honesta suele ser qué tan compleja es la transformación y quién más en el equipo necesita mantenerla, no una preferencia fija por un enfoque sobre el otro.
Diseñar el caso interno para un pipeline gobernado
Anticipa el nivel de inversión y preocupación de TI, y prepárate para ello. La cobertura sobre el desarrollo liderado por ciudadanos señala que los usuarios empresariales están creando y escalando sus propios flujos de trabajo más rápido de lo que los departamentos de TI pueden introducir la gobernanza y la supervisión de la integración, y que un enfoque no intervencionista crea un riesgo real una vez que esos flujos de trabajo necesitan escalarse o conectarse a otros sistemas. Es exactamente por eso que las preguntas sobre el control de versiones y el acceso en el quinto paso son tan cruciales a medida que un pipeline pasa de ser un atajo personal a algo de lo que depende la empresa.
Conseguir la aprobación de un pipeline requiere satisfacer a múltiples stakeholders. TI quiere saber quién puede acceder a las credenciales de conexión, si existe un historial de versiones y cómo se revisa el flujo de trabajo antes de que acceda a datos de producción, las mismas preguntas que harían sobre cualquier proceso que lea datos de un sistema de producción de forma programada. Los líderes de Finanzas u Operaciones se preocupan más por la consistencia. Quieren saber si este pipeline puede producir el mismo resultado de la misma manera todos los meses y si alguien que no sea su creador puede explicar cómo funciona. Para convencer a ambos públicos, enfoca el argumento en la auditabilidad y la consistencia, no solo en el tiempo ahorrado. Un controlador financiero que da el visto bueno a cifras automatizadas quiere saber que el proceso es confiable antes de preocuparse por cuántas horas ahorró.
Comenzar con un solo pipeline, no con un programa
El error que cometen los equipos es intentar automatizar todo de una vez, lo que normalmente hace que el proyecto se estanque antes de que se implemente nada. Elige el informe recurrente que más tiempo lleve reconstruir manualmente en cada ciclo. Haz que funcione de manera confiable, muestra al equipo qué cambió y deja que ese primer resultado hable por sí mismo, sentando las bases para el siguiente. Un pipeline que gestione de manera confiable un solo informe vale más que una hoja de ruta para automatizar diez.
Si quieres probar el enfoque en tu propio informe recurrente, puedes iniciar una prueba gratuita de Alteryx One y construirlo con tus propios datos.