Un número erróneo en un informe terminado casi nunca proviene del flujo de trabajo que lo creó. Cuando un panel de control muestra un número que parece incorrecto, el reflejo es abrir el flujo de trabajo y empezar a revisar la lógica. Por lo general, la lógica se ejecutó exactamente como se diseñó; el defecto se introdujo antes, en datos que nadie revisó primero.
Los culpables comunes se repiten en todos los equipos. Un valor nulo debería haber detenido un cálculo, pero pasó en blanco. Una fila duplicada infló un recuento. Una lectura quedó fuera de un rango válido sin activar ninguna alerta. Un cambio de esquema llegó silenciosamente y cambió incluso lo que significaba una columna.
Reconstruir el flujo de trabajo después de que algo se rompe no soluciona nada. Colocar un control en el punto donde los datos ingresan al proceso sí lo hace, y ese control tiene que sostenerse para tres personas diferentes, no solo para quien lo creó.
El analista hereda cada defecto que el flujo de trabajo no detecta
Para el analista responsable del flujo de trabajo, la verificación es un hábito manual que compite con una fecha límite, y los hábitos manuales son lo primero que se omite cuando un plazo se vuelve ajustado. No hay una forma sistemática de confirmar que la entrada sea correcta antes de que el flujo de trabajo se ejecute en ella.
Dana es precisamente responsable de ese problema. Es analista del equipo de analítica de la planta en un fabricante de autopartes de primer nivel, y su flujo de trabajo semanal de rendimiento a la primera pasada incorpora las lecturas de la fuente MES de la línea de ensamblaje final al informe que la planta revisa todos los lunes por la mañana. Operaciones se basa en ese informe para decidir si una línea requiere atención antes de que comience el próximo turno, por lo que un número incorrecto no pasa desapercibido en una hoja de cálculo.
Solía revisar a simple vista los recuentos de filas y verificar puntualmente una muestra de lecturas antes de ejecutar el informe cada semana. Eso funcionaba bien cuando el volumen era bajo, cuando un puñado de lecturas podía representar a todo el turno. A medida que la línea creció a cientos de lecturas al día, la revisión puntual se redujo a un vistazo apresurado antes de una fecha límite y, luego, a confiar por completo en el feed.
Una actualización de firmware en el sensor de torque de la estación de ensamblaje final cambió lo que sucedía cuando una lectura caía por debajo de 2.4 Nm. En lugar de registrar esas lecturas como fallas, el sensor simplemente dejó de escribir una fila para ellas. Las unidades fuera de especificación nunca aparecieron en el conjunto de datos.
El cálculo de rendimiento de Dana solo registraba lecturas aprobadas. Reportó que el rendimiento de primer paso aumentaba durante tres semanas consecutivas mientras que la tasa real de rechazo de la línea aumentaba silenciosamente por debajo.
La brecha era más profunda que el sensor. Nadie había ingresado la verdadera especificación de torque, de 2.4 a 2.6 Nm, en la propia tabla de límites del MES. Solo existía en la hoja de cálculo personal de un ingeniero de calidad, por lo que incluso un conjunto de datos completo no habría tenido nada almacenado con qué compararse.
Ese es, ante todo, un problema de perfilado: verificar lo que realmente hay en los datos entrantes antes de confiar en lo que sale por el otro extremo, cotejado con un límite de especificación que se encuentre en otro lugar que no sea el archivo de una sola persona. Tiene que ejecutarse como parte de la ejecución normal del flujo de trabajo, no como una tarea manual independiente que compita con la misma presión de plazos de entrega que causó la brecha en primer lugar.
Lo que una verificación habría tenido que detectar
- Una comparación del recuento de filas frente al volumen de producción esperado del turno, para detectar lecturas faltantes de forma silenciosa, no solo las erróneas.
- Una validación de rango y umbral frente a un límite de especificación almacenado, no uno que se encuentre en el archivo de una sola persona.
- Una verificación de valores nulos o en blanco en el propio campo del sensor, ya que esta falla se mostró como una ausencia, no como un valor de error.
- Una retención del lote, no solo una nota, cuando un turno no pasa estas verificaciones, para que un mal turno no pase desapercibido en la cifra semanal.
Antes de que se envíe el próximo informe, vale la pena rastrear el último número sin explicación hasta su origen real. La mayoría de las veces, el flujo de trabajo cumplió con su tarea. El problema eran los datos que le llegaban, y nadie los verificó al entrar.
El área de TI no confiará en un flujo de trabajo que no pueda verificar
TI hace una pregunta diferente a la del analista. El analista quiere saber si los datos pasaron el control. TI quiere saber quién modificó el control, cuándo lo modificó y si ese cambio se puede demostrar después del hecho.
Esa pregunta surgió en el momento en que el equipo de Dana quiso que el control de rendimiento se ejecutara automáticamente en cada turno, en lugar de solo cuando ella se acordaba de revisarlo. La primera pregunta de TI se centró en el acceso, no en la lógica: quién más podía editar los umbrales de los límites de especificación detrás de esto y si un cambio en esos umbrales dejaría algún rastro visible.
Los equipos que evalúan cualquier plataforma para este tipo de trabajo buscan las mismas dos cosas: cambios en la lógica del flujo de trabajo que queden registrados y sean atribuibles, y un acceso controlado a quién puede editar una comprobación que se ejecuta en producción. Ninguna de las dos es opcional una vez que una comprobación deja de ser un hábito personal y se convierte en algo de lo que una planta depende en cada turno. Un flujo de trabajo que se ejecuta de forma desatendida sigue siendo código que interactúa con datos de producción, y TI lo trata de esa manera sin importar quién lo haya escrito.
La tensión es real y no se resuelve por sí sola. Los analistas quieren una verificación que sea rápida de ajustar en cuanto cambia un límite de especificación, ya que un proceso de cambio lento solo invita a las personas a eludir la verificación en lugar de actualizarla. TI quiere que cada uno de esos ajustes sea trazable, exactamente por la misma razón: un cambio sin seguimiento es indistinguible de un error hasta que alguien demuestre lo contrario.
Un flujo de trabajo que hace que los cambios sean fáciles pero invisibles no satisface a ninguna de las dos personas. Solo traslada el riesgo de una verificación que podría ser errónea a una verificación que cualquiera podría haber modificado, sin que quede ningún registro de ello.
Lo que TI necesita de una solución es específico: los cambios deben ser atribuibles y revisables, sin convertir cada ajuste en los límites de especificación en una cola de tickets que desanime a los analistas a mantener el control actualizado desde un principio. Si te equivocas en ese equilibrio en cualquier dirección, el control deja de ser confiable para alguien.
Qué revisa realmente TI antes de confiar en un flujo de trabajo
- Quién puede ver, editar o ejecutar el flujo de trabajo que contiene la verificación, no solo quién puede ver el informe resultante.
- Si un cambio en la lógica de la verificación, como un límite de especificación, se registra con quién lo hizo y cuándo.
- Si un control fallido es visible en algún lugar donde un administrador pueda verlo, no solo en el log de ejecución del propio analista.
- Cuánto tiempo se retiene ese historial de cambios y si se puede exportar para una revisión de cumplimiento.
El director de la planta no ve el control, solo el número que habría detenido
El director de la planta nunca ve la verificación, solo el número que esta habría detectado o pasado por alto. Presentar una cifra de rendimiento semanal al área corporativa significa confiar a ciegas en el flujo de trabajo que hay detrás, sin forma de saber si realmente algo verificó el número antes de que llegara a la presentación.
Eso es exactamente lo que sucedió en la planta de Dana. Tres semanas consecutivas de cifras crecientes de rendimiento a la primera pasada entraron a la revisión de la dirección antes de que la queja de un cliente por unidades defectuosas obligara a realizar una auditoría manual. La auditoría detectó la brecha del sensor después de los hechos; para entonces, la cifra reportada a los niveles superiores ya había sido incorrecta durante tres ciclos de revisión.
El patrón no se limita a una sola planta. Una encuesta de Deloitte de 2025 a 600 ejecutivos sénior de manufactura reveló que el escalamiento de las iniciativas de manufactura inteligente y de IA se ve limitado en toda la industria por la mala calidad de los datos, una gobernanza deficiente y sistemas fragmentados.
Lo que está en juego también se refleja en el nivel ejecutivo. Un estudio de 2025 del IBM Institute for Business Value reveló que el 43 % de los directores de operaciones identifica los problemas de calidad de los datos como su prioridad más importante en materia de datos, por delante de casi cualquier otra cosa que compita por su atención.
A un director de planta no le importa la mecánica de una verificación. La única pregunta que importa al entrar a una reunión de liderazgo es si la cifra que tienen delante ya fue verificada, no si el equipo puede explicar después por qué no fue así.
Un número de rendimiento incorrecto reportado hacia arriba durante tres semanas no es un problema de datos desde la perspectiva de un director de planta. Es una falla de calidad de cara al cliente y es un problema de credibilidad la próxima vez que el equipo reporte cualquier cifra. Reconstruir esa confianza toma mucho más tiempo que las tres semanas que tomó perderla.
Dónde se alinean los tres intereses, y dónde no
Los tres stakeholders se benefician de lo mismo: una validación que se ejecuta automáticamente, cada vez, sin depender de si un analista recordó revisar antes de una fecha límite. Eso es terreno común.
La diferencia está en lo que cada uno necesita ver al respecto. Hacer que una verificación sea rápida de ajustar para un analista, por ejemplo, si cambia un límite de especificación o se reemplaza un sensor, puede ir directamente en contra de la necesidad de TI de que ese mismo cambio se revise y sea atribuible. La velocidad y la trazabilidad tiran en direcciones opuestas, a menos que ambas se diseñen al mismo tiempo.
La segunda fricción se produce entre el analista y el director de la planta. Un líder quiere un número claro o un indicador claro de que algo falló, no el nivel de detalle que un analista o TI necesitan cuando una comprobación realmente se rompe. Darle a un director un log de ejecución no resuelve nada, y darle a un analista solo un indicador de aprobado o reprobado tampoco resuelve nada; cada stakeholder necesita una perspectiva diferente del mismo evento.
Esto se traduce en un requisito, no en un acuerdo negociado: la comprobación en sí debe ser idéntica para todos, automatizada y ejecutarse con la misma programación sin importar quién esté mirando. Lo que difiere es lo que cada stakeholder ve al respecto: un log de edición para TI, un indicador de aprobado o reprobado para el director y un número verificado como base para el analista.
Los problemas de calidad de datos no gestionados conllevan un costo real y cuantificado. Las organizaciones pierden al menos USD 12.9 millones al año en promedio, según una investigación de Gartner. Esa cifra se mantiene en todas las industrias precisamente porque la falla de fondo es la misma que ocurre en la planta de Dana: nadie se hace responsable de la verificación en sí, por lo que el costo de un defecto se descubre en procesos posteriores, por quienquiera que tenga el número incorrecto cuando finalmente aparece.
Vuelve a ejecutar el escenario y la misma comprobación integrada habría servido para los tres. Le habría dado a Dana el recuento de filas y la verificación de umbrales que solía hacer manualmente. Le habría dado al equipo de TI un cambio en la lógica de límites de especificación visible en otro lugar que no fuera su bandeja de entrada. Y le habría dado al director de la planta una cifra de rendimiento que ya estaba verificada en lugar de una a la espera de que alguien notara un problema.
Qué debe cumplir una solución para los tres
El requisito para los tres stakeholders es el mismo. La verificación debe estar dentro del propio flujo de trabajo, no en el hábito de una persona de acordarse de revisar, y tiene que ejecutarse con una programación que no dependa de que nadie la solicite.
Esto significa que el flujo de trabajo necesita una forma de ver, columna por columna, si los datos entrantes están completos y son válidos antes de que se utilicen, y una manera de corregir problemas comunes como valores nulos, caracteres sueltos y el uso inconsistente de mayúsculas y minúsculas como parte del mismo proceso que prepara los datos, y no como un paso manual independiente. Esa segunda parte es lo que realmente significa la limpieza de datos en la práctica: corregir los datos, no solo marcarlos.
El requisito anterior de TI era específico: un registro de quién cambió la verificación y cuándo, que pueda demostrarse después del hecho. Plataformas como Alteryx One responden a esa necesidad a través de registros de auditoría, que rastrean los cambios en la lógica del flujo de trabajo como eventos registrados, atribuibles y exportables, que se mantienen separados del resultado propio de aprobación o falla de la verificación en lugar de ser un sustituto de este.
Los equipos que aún están desarrollando esa primera capa pueden comenzar con estos recursos de preparación de datos, que explican el funcionamiento con mayor profundidad.
Ese control solo se convierte en rutina una vez que deja de esperar a que alguien lo ejecute manualmente. El mismo flujo de trabajo se puede programar para que se ejecute automáticamente en cada turno, de modo que la secuencia de perfilado y limpieza se repita por sí sola en lugar de depender de que alguien se acuerde de verificar.
Una herramienta de creación de perfiles columna por columna puede mostrar valores nulos, en blanco y fuera de rango a medida que los datos avanzan por el flujo de trabajo, lo que responde directamente al problema original del analista: ver lo que realmente hay antes de confiar en ello en los procesos posteriores.
Un paso de limpieza dedicado se encarga de las correcciones habituales, como valores nulos, espacios en blanco innecesarios y mayúsculas y minúsculas inconsistentes, como parte de ese mismo proceso en lugar de ser una tarea independiente incorporada a último momento antes de una fecha límite.
Creación del caso compartido
Presentar esto como “una nueva herramienta para la calidad de los datos” genera escrutinio presupuestario y un rechazo impreciso. El argumento más sólido se basa en la falla específica que expuso el escenario: tres semanas de un número incorrecto que llegó a la revisión del equipo de liderazgo, y la solución específica que exige: controles integrados en el flujo de trabajo y programados para ejecutarse, en lugar de depender de recordarlos.
El punto de conversación del analista debe cuantificar el modo de falla en sí, no un agregado impreciso del sector. Una verificación omitida no cuesta “calidad de datos” en abstracto. Cuesta todo un turno de unidades fabricadas con la tolerancia incorrecta antes de que alguien se dé cuenta, lo que deja reprocesos o desechos como resultado, más las horas dedicadas después a reconstruir lo que realmente sucedió en la línea.
La solicitud de TI es más pequeña de lo que parece. En lugar de pedir que se confíe plenamente en la hoja de cálculo del analista, pide ver la lógica de la verificación y su historial de cambios, una solicitud más acotada y fácil de responder que una revisión completa de la plataforma, y la que TI realmente necesita que se responda antes de dar su aprobación. Planteada de esa manera, la conversación pasa de una revisión de seguridad general a una pregunta específica y delimitada a la que TI puede decir que sí.
El argumento del líder gira en torno al riesgo, no a la iniciativa. No es un proyecto nuevo que compite por atención en el presupuesto. Es una reducción del riesgo en torno a un indicador que la planta ya reporta semanalmente a niveles superiores, que ya provocó una queja de un cliente una vez y cuyo próximo incumplimiento sería más difícil de explicar la segunda vez.
En conjunto, estos tres puntos convergen en una única petición: un cambio en la forma en que se ejecuta el flujo de trabajo de rendimiento que brinda a cada stakeholder exactamente lo que se describió en la sección anterior. TI obtiene un registro de auditoría, el analista obtiene una comprobación programada y el director obtiene una cifra verificada.
Probar ese cambio directamente es la forma más rápida de ver si resiste en una programación de producción real. La prueba gratuita de Alteryx One dura 30 días, tiempo suficiente para crear la comprobación, programarla y ver cómo detecta el próximo turno defectuoso antes de que llegue a un informe.