Ingeniería de datos: el trabajo invisible que sostiene todo lo demás

La ingeniería de datos es la parte del trabajo que nadie enseña en la presentación de resultados. Nadie proyecta en pantalla el proceso que cada noche recoge los pedidos del ERP, corrige las fechas mal grabadas y deja la tabla lista a las seis de la mañana. Se proyecta el cuadro de mando. Pero cuando el cuadro de mando falla —y falla— el problema casi nunca está en el gráfico: está en la tubería que lo alimenta. Esta guía va de esa tubería, de cuándo hace falta construirla en serio y de cómo se hace sin abrir un proyecto de dos años.

Lo escribimos porque es la conversación que más repetimos. Una empresa nos llama para un modelo predictivo o un cuadro de mando y, a la tercera pregunta, aparece el mismo cuello de botella: los datos existen, pero están repartidos en seis sistemas, nadie los cruza de forma repetible y cada informe se monta a mano. Ahí no falta un científico de datos. Falta ingeniería de datos.

¿Qué es la ingeniería de datos y en qué se diferencia del BI?

La ingeniería de datos es el conjunto de procesos que mueven un dato desde donde nace hasta donde se usa, de forma automática, repetible y verificable. Extraerlo del sistema origen, limpiarlo, darle una estructura estable, cargarlo en un sitio consultable y avisar cuando algo se rompe.

La diferencia con el BI es de capa, no de importancia:

• Ingeniería de datos responde a «¿existe la tabla, está completa y está al día?».
• BI y analítica responden a «¿qué nos dice esta tabla y qué decidimos con ella?».

Si el BI es el grifo, la ingeniería de datos es la instalación de fontanería de todo el edificio. Cuando funciona, es invisible. Cuando no funciona, todo el mundo culpa al grifo. Por eso en muchas empresas se acumulan licencias de herramientas de visualización y cero inversión en lo que hay debajo: lo de abajo no se ve, no se demuestra en una demo y no entusiasma en un comité.

Tampoco hay que confundirla con la ciencia de datos. El científico de datos construye modelos; el ingeniero de datos construye el suministro que esos modelos consumen todos los días. Un modelo que funciona en un portátil con un Excel exportado a mano no está en producción: es una maqueta. Lo tratamos con detalle en machine learning en producción.

El 80% de lo que la gente llama «proyecto de IA» es, en realidad, un proyecto de ingeniería de datos con un modelo pequeño al final.

¿Qué señales indican que tu empresa necesita ingeniería de datos?

No hace falta un diagnóstico caro. Estas señales se reconocen en una reunión:

• Alguien dedica días al mes a montar el mismo informe. Descarga, pega en Excel, cruza con un BUSCARV, revisa a ojo. Si eso pasa cada mes, ya estás pagando ingeniería de datos, solo que a mano y sin control de versiones.
• Dos áreas presentan cifras distintas de lo mismo. Es el síntoma clásico: no hay una tabla oficial, hay seis extracciones con criterios distintos. El origen suele ser de definición, no técnico, y se ataca con gobierno del dato.
• El cuadro de mando lleva días desactualizado y nadie se ha enterado. Sin monitorización, un proceso que falla en silencio es peor que no tener proceso: la gente decide con datos viejos creyendo que son de ayer.
• Un cambio en el ERP rompe tres informes. Si nadie sabe qué depende de qué, cada actualización del sistema origen es una ruleta.
• Los datos históricos no se pueden reconstruir. El sistema operativo sobrescribe el estado actual; si no has guardado la foto de cada día, la serie histórica que necesita cualquier previsión no existe.
• El proveedor de IA pide «un CSV limpio» y nadie sabe quién lo genera. Señal definitiva.

Con dos de estas seis, el siguiente euro rinde más en la tubería que en la herramienta de visualización.

¿Qué hace exactamente un ingeniero de datos?

Menos glamour y más oficio del que se imagina. El día a día se reparte en cinco bloques:

Ingesta. Conectar con los sistemas origen: ERP, CRM, plataforma de comercio electrónico, ficheros que envía un proveedor, APIs de terceros. Aquí la dificultad rara vez es técnica; es conseguir credenciales, permisos y una ventana horaria en la que el ERP no esté cerrando el día.

Modelado. Convertir tablas operativas —pensadas para que la aplicación funcione rápido— en tablas analíticas, pensadas para que una pregunta de negocio se responda en una consulta. Aquí se decide qué es un «cliente», qué es un «pedido válido» y cómo se tratan las devoluciones. Son decisiones de negocio disfrazadas de decisiones técnicas.

Calidad y pruebas. Reglas automáticas que se ejecutan en cada carga: la clave primaria no se repite, el importe no es negativo, el número de filas de hoy no cae un 90% respecto a ayer. Sin esto, los errores se descubren en un comité de dirección.

Orquestación. Decidir qué proceso se ejecuta, en qué orden, con qué dependencias, qué pasa si uno falla y a quién se avisa. Un proceso que falla y no avisa es un proceso que miente.

Documentación y linaje. Saber de dónde sale cada campo y qué informes dependen de él. Es lo primero que se abandona y lo primero que se echa de menos cuando el ingeniero que lo montó cambia de empresa.

¿Cómo es una arquitectura de datos razonable para una empresa mediana?

No hace falta la arquitectura de una tecnológica de mil personas. Hace falta la más simple que aguante tres años. Esta es la referencia que proponemos casi siempre, por capas:

| Capa | Qué hace | Señal de que la necesitas ya | |---|---|---| | Ingesta | Copia periódica de los sistemas origen, sin transformar | Alguien exporta a mano cada semana | | Almacén / bruto | Guarda el dato tal cual llegó, con fecha de carga | No puedes reconstruir qué decía el sistema hace un mes | | Transformación | Limpieza y modelo analítico versionado en código | Las reglas de negocio viven dentro de fórmulas de Excel | | Servicio | Tablas finales que consumen BI, informes y modelos | Cada informe recalcula su propia versión de la verdad | | Observabilidad | Alertas de fallo, frescura y volumen | Te enteras de los fallos por un comercial enfadado |

Dos matices importantes. Primero: la capa de bruto no es opcional. Guardar el dato tal como llegó es lo que te permite recalcular el pasado cuando descubres un error de criterio, y ocupa mucho menos de lo que la gente teme. Segundo: la transformación tiene que vivir en código versionado, no en la interfaz de una herramienta. Si la lógica está atrapada en clics dentro de un producto, migrar de producto cuesta el doble y revisar qué cambió alguien el martes es imposible.

Sobre el orden en que se construye: primero la fuente de verdad de UN dominio —ventas, normalmente— y después se extiende. Hacerlo todo a la vez es la receta del proyecto que muere en la fase de análisis. Lo desarrollamos en estrategia de datos.

¿Cuánto cuesta y conviene tenerlo dentro o fuera?

El coste real se reparte en tres partidas y casi nadie presupuesta la tercera:

• Construcción. Montar la ingesta y el modelo de un dominio: semanas, no meses, si el alcance está acotado.
• Infraestructura. Almacenamiento y cómputo. Para volúmenes de empresa mediana suele ser la partida más pequeña, y la que más miedo da por desconocimiento.
• Mantenimiento. El sistema origen cambia, el negocio añade una línea, aparece una filial. Presupuesta mantenimiento desde el día uno o tendrás una tubería que se degrada sola.

Sobre internalizar o externalizar, nuestro criterio honesto:

| Situación | Recomendación | |---|---| | Primer proyecto, sin perfil de datos en plantilla | Externo para construir, con compromiso de traspaso y documentación | | Ya hay alguien técnico que lo mantiene a ratos | Externo para el diseño, interno para la operación diaria | | Los datos son el producto o el núcleo del negocio | Interno, sin discusión | | Necesidad puntual de un informe | Ni una cosa ni otra: no montes una plataforma para un informe |

La pregunta que hay que hacerle a cualquier proveedor —nosotros incluidos— es: «cuando terminéis, ¿quién puede tocar esto sin vosotros?». Si la respuesta implica una dependencia permanente, el precio real es más alto que el del presupuesto. Ese criterio y otros nueve están en cómo elegir consultora de IA.

¿Cómo se empieza sin abrir un proyecto de dos años?

Con un alcance ridículamente pequeño y una fecha corta. La secuencia que funciona:

1. Elige una decisión, no un sistema. «Saber cada lunes qué márgenes dejó la semana por línea de producto» es un alcance. «Integrar el ERP» no lo es. 2. Mapea hacia atrás desde esa decisión. Qué campos hacen falta, en qué sistema viven, con qué frecuencia cambian y quién manda sobre su definición. 3. Monta la tubería solo para esos campos. Ingesta, bruto, transformación, tabla final. Sin ambición de cubrir el resto todavía. 4. Añade tres pruebas de calidad y una alerta. Unicidad, rango y frescura. Con una alerta a un canal donde alguien la vea. 5. Enchufa el cuadro de mando al final. No al principio. El cuadro de mando es el consumidor, no el proyecto. 6. Apaga el informe manual. Si el proceso antiguo sigue vivo, no has terminado: has añadido trabajo.

En seis a ocho semanas eso está en producción y ya se nota. Y lo más valioso no es el resultado, es lo que aprendes por el camino sobre el estado real de tus sistemas, que suele ser distinto de lo que dice el inventario oficial.

Preguntas frecuentes

¿Necesito un almacén de datos si solo tengo un ERP?

Si todo el dato relevante vive en un único sistema y sus informes te bastan, no. El almacén se justifica cuando hay que cruzar fuentes, guardar histórico que el operativo sobrescribe o quitar carga de consultas pesadas al sistema que usa la operación cada día.

¿Puedo hacer ingeniería de datos con las herramientas que ya tengo?

A menudo sí, al menos para empezar. Muchas empresas tienen ya una base de datos infrautilizada y un orquestador disponible. Lo que casi nunca sirve es sostener la lógica en macros de Excel: no se versiona, no se prueba y depende de que un portátil concreto esté encendido.

¿Cuánto tarda en verse el retorno?

El retorno inmediato es tiempo recuperado: las horas que alguien dedicaba a montar el informe a mano. Eso se mide en la primera o segunda semana tras el corte. El retorno de las decisiones mejores tarda más y es más difícil de atribuir, pero el primero solo ya suele pagar la construcción.

¿Hace falta ingeniería de datos antes de hacer IA?

Para una prueba aislada, no. Para poner IA en producción, sí: un modelo necesita datos frescos y con la misma forma todos los días, y eso es exactamente lo que produce una tubería bien montada. El argumento completo está en primero los datos, después la IA.

Si al leer las señales has reconocido tres o cuatro de las de tu casa, el siguiente paso no es elegir tecnología: es acotar una decisión concreta y ver qué falta para alimentarla. Eso es lo que hacemos en la auditoría —dos semanas, sistemas reales, mapa de lo que hay y de lo que falta— y si prefieres contarlo antes en una conversación sin compromiso, hablemos.