Qué es la ingeniería de datos

El desorden de datos no aparece en un tablero, aparece en una reunión

El síntoma casi nunca se ve en un reporte, se ve en una reunión. Tres áreas presentan tres cifras distintas de ventas del mismo mes, cada una segura de la suya, y la conversación se va media hora en discutir cuál número es el bueno en lugar de decidir qué hacer con él. Debajo de esa escena hay un problema que casi nadie nombra a tiempo: los datos de la empresa existen, pero viven partidos en el ERP, en el sistema de facturación, en diez hojas de cálculo y en la bandeja de correo de la persona que “lleva ese reporte”. Nadie los junta con un criterio único, así que cada quien arma su propia versión de la verdad.

La mayoría de empresas cree que tiene datos porque tiene sistemas. Es distinto. Tener sistemas es tener información atrapada en compartimentos que no se hablan entre sí. Tener datos utilizables es que esa información esté reunida, limpia, con el mismo criterio de qué significa cada campo, y disponible cuando alguien la necesita para decidir. La distancia entre lo uno y lo otro es, exactamente, el trabajo de la ingeniería de datos. Y es la deuda que estalla el día que la empresa intenta su primer proyecto serio de analítica o de IA y descubre que no puede alimentarlo con nada confiable.

Qué es la ingeniería de datos en criterio de negocio, no de ingeniería

La ingeniería de datos es, en criterio de negocio, el trabajo de plomería de tu empresa. No es el análisis que sale en el tablero ni el modelo de IA que responde preguntas: es todo lo que pasa antes para que esos dos puedan existir. Recolecta la información de cada fuente, la limpia de errores y duplicados, la mueve al lugar donde se va a usar y la organiza con un criterio común. Como toda buena plomería, es invisible cuando funciona y es la explicación de todo cuando algo falla.

El nombre suena a área de tecnología y por eso dirección tiende a delegarlo y olvidarlo. Es un error de encuadre. La ingeniería de datos decide, en la práctica, si tus reportes son confiables, si tu equipo pierde días cuadrando cifras a mano y si puedes o no intentar un proyecto de IA sin que se caiga en la primera semana. No es un gasto técnico: es la base sobre la que se apoya cualquier decisión que digas tomar “con datos”. Cuando esa base no existe, lo que tomas son decisiones con opiniones disfrazadas de números.

Los cuatro trabajos que hace, en orden y sin saltarse peldaños

Conviene verla como una escalera de cuatro peldaños, en orden, porque saltarse uno rompe los que siguen. Cada peldaño parece una tarea técnica, pero en el fondo es una decisión de negocio sobre qué información va a poder usar tu empresa y en qué puede confiar.

La escalera, peldaño por peldaño

• Recolectar: traer la información desde donde nace (ventas, facturación, soporte, la web, sensores) hasta un punto común. Aquí se decide qué fuentes entran y cuáles se ignoran, y esa decisión ya condiciona qué preguntas vas a poder responder después.
• Limpiar: corregir lo que llega mal. Fechas en tres formatos, nombres de clientes escritos de cinco maneras, montos con y sin impuesto, registros duplicados. Sin este paso, cualquier suma posterior está equivocada desde el origen y nadie lo nota hasta que el número no cuadra en la reunión.
• Mover y transformar: llevar el dato al destino donde se usa y darle la forma que ese uso necesita. El mismo pedido se ve distinto para el reporte de finanzas que para el modelo que predice quiebre de stock, y alguien tiene que preparar cada versión de manera repetible, no a mano cada mes.
• Organizar y mantener: definir dónde vive cada cosa, qué significa cada campo, quién puede verlo y cómo se actualiza solo cuando entra información nueva. Este es el peldaño que convierte un esfuerzo puntual en una fuente viva, y el que casi todos abandonan apenas se apaga el primer entusiasmo.

Lo importante para dirección no es memorizar los cuatro pasos, es entender dos cosas: que son secuenciales y que son permanentes. No es un proyecto que se hace una vez y queda listo. Es un proceso que corre todos los días, porque cada día entra información nueva que puede volver a ensuciar lo que ya estaba ordenado. Tratarlo como un evento y no como un proceso es la raíz de la mitad de los fracasos.

Por qué esto va antes que cualquier proyecto de inteligencia artificial

Hay una frase vieja en el mundo de los datos que resume todo el asunto: si entra basura, sale basura. Un modelo de IA, por avanzado que sea, no arregla datos malos. Los hereda. Aprende de lo que le das, y si lo que le das está incompleto, desactualizado o mal etiquetado, el modelo va a repetir esos defectos con una seguridad que los vuelve peores, porque ahora vienen envueltos en apariencia de precisión técnica.

Por eso, cuando una empresa me dice que quiere “hacer un proyecto de IA”, la primera pregunta no es qué modelo, es qué datos. En la mayoría de los casos, el proyecto de IA que imaginan es en realidad un proyecto de ingeniería de datos que todavía no hicieron. No es una mala noticia: es la diferencia entre gastar en un piloto que va a fallar y construir la base que hace que ese piloto, y los diez siguientes, funcionen. El orden correcto siempre es el mismo: primero el dolor concreto, después el proceso que lo genera, después los datos que ese proceso produce, y recién al final la herramienta que los explota.

Lo que la empresa necesita decidir antes de invertir

Montar una función de ingeniería de datos no arranca comprando tecnología. Arranca con decisiones de orden interno que ninguna herramienta toma por ti. Esto es lo que reviso con una empresa antes de recomendar cualquier inversión, y ninguno de estos puntos es un software:

• Fuentes identificadas y con dueño: saber de dónde sale cada dato importante y quién responde por él. Si nadie sabe cuál sistema tiene la cifra oficial de ventas, ese es el primer problema a resolver, y no lo resuelve una plataforma.
• Un diccionario mínimo de qué significa cada cosa: que “cliente activo” quiera decir lo mismo en marketing que en finanzas. Sin ese acuerdo, cada área seguirá contando distinto aunque compartan la misma base de datos.
• Un caso de uso que duela y sea medible: un reporte que hoy toma dos días armar a mano, una decisión que se retrasa por falta de dato confiable. No “ordenar todos los datos de la empresa”, que es la forma más segura de no terminar nunca.
• Reglas de acceso y privacidad claras: qué dato es sensible, quién puede verlo y qué exige la ley sobre datos personales de tus clientes. Esto se define antes de mover información, no después de una filtración.
• Alguien responsable del proceso, no solo del proyecto: la ingeniería de datos no termina el día de la entrega. Necesita un dueño que responda por que las fuentes sigan actualizadas y por que el flujo no se rompa en silencio.

Cuando estas decisiones están tomadas, la herramienta llega después, y casi siempre llega más barata y más pequeña de lo que la empresa temía. El costo real de la ingeniería de datos nunca estuvo en la licencia del software: estuvo en el trabajo de poner de acuerdo a las áreas sobre qué es verdad y quién responde por ella.

Los errores que hunden estos proyectos, y son siempre los mismos

Los errores que hunden estos proyectos se repiten tanto que ya son predecibles. Los mismos cuatro, en empresas de todo tamaño:

• Comprar la herramienta antes de tener el problema claro. Se elige una plataforma de datos cara porque un proveedor la recomendó, y termina siendo un almacén ordenado que nadie usa para decidir nada. La tecnología llega a una pregunta que nunca se formuló.
• Tratarlo como proyecto y no como proceso. Se ordena todo una vez, se celebra, y seis meses después el flujo se ensució de nuevo porque nadie quedó a cargo de mantenerlo. El orden de los datos es como el aseo de la oficina: no se hace una sola vez y para siempre.
• Querer ordenarlo todo de golpe. El intento de limpiar el archivo completo de la empresa antes de entregar valor consume el presupuesto y la paciencia de dirección antes de mostrar un resultado. Se ordena por caso de uso, no por completitud.
• Dejarlo entero en manos de tecnología sin criterio de negocio. Si quien mueve los datos no entiende qué decisión se va a tomar con ellos, va a preparar información técnicamente correcta e inútil para el negocio. La ingeniería de datos sin contexto de negocio produce reportes limpios que a nadie le sirven.

Ninguno de estos errores es técnico en su raíz. Todos son fallas de encuadre: confundir la herramienta con el problema, el evento con el proceso, y el dato limpio con la decisión que se supone que debía habilitar.

Qué NO es y qué no resuelve la ingeniería de datos

Como es un término de moda, se le cargan expectativas que no le corresponden. Conviene separar lo que hace de lo que no, antes de firmar un presupuesto sobre supuestos equivocados:

• No es análisis ni ciencia de datos. La ingeniería prepara y entrega el dato confiable; el análisis y los modelos vienen después y son otro trabajo. Confundirlos hace que se contrate al perfil equivocado para el problema real.
• No genera información que la empresa nunca capturó. Si jamás registraste por qué se van tus clientes, ningún flujo de datos lo va a inventar. Ordena lo que existe, no rellena lo que falta.
• No es lo mismo que tener un tablero bonito. Un dashboard puede verse impecable y estar alimentado por datos sucios. La confianza no está en el gráfico, está en la tubería que lo llena.
• No reemplaza la decisión de negocio. Te da información fiable y a tiempo. Qué hacer con ella sigue siendo trabajo de una persona con criterio y responsabilidad, y eso no se automatiza.
• No es un lujo de empresa grande. Una empresa mediana que cuadra cifras a mano cada mes ya está pagando el costo de no tenerla, solo que en horas de su equipo en lugar de en una factura de software.

Aclarar esto al inicio cuesta alguna reunión incómoda, pero evita el reclamo del mes cuatro, cuando alguien esperaba un análisis o una decisión automática y lo que se entregó, correctamente, fue una fuente de datos confiable sobre la que todavía hay que pensar.

Cuándo conviene invertir y cuándo conviene esperar

No es una decisión de tamaño de empresa ni de moda. Es una decisión sobre cuánto te está costando hoy no confiar en tus datos, y sobre si existe un caso concreto que lo justifique ahora.

Señales de que ya conviene invertir

• Tu equipo pierde días cuadrando cifras a mano en cada cierre, y ese tiempo es medible en dinero.
• Dos áreas dan números distintos de lo mismo y las decisiones se frenan mientras se discute cuál es el bueno.
• Quieres intentar un proyecto de analítica o de IA y ya sospechas que los datos no están listos para alimentarlo.
• La información crítica vive en hojas de cálculo personales que se rompen o se pierden cuando esa persona no está.
• El volumen o la cantidad de fuentes ya superó lo que alguien puede juntar a mano sin equivocarse.

Señales de que conviene ordenar el problema antes

• Nadie puede nombrar todavía qué decisión concreta mejoraría con datos confiables, más allá de “tener todo ordenado”.
• El objetivo declarado es comprar una plataforma, no resolver un dolor. La herramienta se eligió antes que el problema.
• No hay nadie dispuesto a quedar como dueño del proceso una vez que termine la implementación.
• El caso real es un solo reporte estable y acotado que una hoja de cálculo bien hecha todavía resuelve sin infraestructura nueva.

La ingeniería de datos es el punto de llegada de una conversación de negocio

Por eso la ingeniería de datos no es el punto de partida de una conversación de tecnología, es el punto de llegada de una conversación de negocio. Primero el dolor que cuesta dinero, después el proceso que lo produce, después los datos que ese proceso deja, y recién al final la herramienta que los ordena y los explota. Cuando el orden es ese, la ingeniería de datos deja de parecer un gasto técnico y se ve por lo que es: la base sobre la que se sostiene cada decisión que tu empresa dice tomar con datos, y el requisito silencioso de cualquier proyecto de IA que aspire a durar más que la demo.