Cómo comprobar una mejora del flujo de información: 7 pasos con evidencias, pruebas e indicadores
Por Oscar Caita | Sistemas de Información Gerencial | Ingeniería Industrial
Introducción: ¿cómo saber si una mejora realmente funciona?
Imagine una empresa que decide invertir en un nuevo sistema de información para mejorar sus operaciones. Después de varias semanas de trabajo presenta un tablero de indicadores moderno, formularios digitales y gráficos que muestran los resultados de sus procesos.
A primera vista, todo parece indicar que la empresa ha mejorado.
Pero surgen algunas preguntas:
- ¿La información que aparece en el tablero es correcta?
- ¿Podemos comprobar quién registró cada dato y cuándo lo hizo?
- ¿Los indicadores reflejan lo que realmente ocurre en la operación?
- ¿El nuevo sistema permite tomar decisiones que antes no podían tomarse?
- ¿Cómo sabemos que los resultados obtenidos se deben a la mejora implementada?
Estas preguntas revelan un problema frecuente en las organizaciones: confundir la implementación de una solución tecnológica con la comprobación de una mejora real.
Un sistema puede funcionar técnicamente y, aun así, presentar información incompleta, desactualizada o imposible de verificar.
En ingeniería industrial y sistemas de información gerencial, una mejora debe sustentarse en hechos observables, requisitos definidos, pruebas documentadas e indicadores capaces de demostrar los cambios alcanzados.
A lo largo de este artículo aprenderemos cómo hacerlo utilizando un ejemplo de devolución de libros en una biblioteca, que posteriormente llevaremos a un Centro de Distribución (CEDI) para comprender su aplicación industrial.
El propósito es que puedas utilizar esta metodología para evaluar propuestas de mejora en empresas, instituciones educativas, procesos productivos, operaciones logísticas y sistemas de información.
1. ¿Qué significa mejorar el flujo de información?
El flujo de información es el recorrido que siguen los datos desde que se generan o capturan hasta que son procesados, almacenados, comunicados y utilizados para tomar decisiones.
Este recorrido puede involucrar personas, documentos, formularios, sistemas informáticos, equipos y procedimientos.
Por ejemplo, cuando un cliente realiza un pedido, se generan datos relacionados con su identificación, el producto solicitado, la cantidad, la fecha de entrega y las condiciones comerciales.
Esa información puede pasar por ventas, inventarios, producción, logística y facturación.
Si durante el recorrido se pierde una referencia, aparece una inconsistencia o un área trabaja con una versión diferente, la decisión posterior puede resultar equivocada.
1.1. Datos, información y decisiones: ¿son lo mismo?
No. Aunque están relacionados, representan conceptos distintos.
Dato: es una representación de un hecho o atributo que puede registrarse y procesarse.
Ejemplo: 10:35 a. m.
Este dato, por sí solo, no explica qué ocurrió.
Información: surge cuando los datos se organizan e interpretan dentro de un contexto.
Ejemplo: «El pedido 1058 fue recibido en el almacén a las 10:35 a. m.».
Ahora conocemos el evento al que pertenece la hora registrada.
Evidencia: es la información o registro pertinente que permite sustentar una afirmación o verificar el cumplimiento de una condición.
Ejemplo: un comprobante de recepción asociado al pedido 1058, con identificación del receptor, fecha y registro de validación.
Decisión: es la determinación que toma una persona o sistema utilizando la información disponible.
Ejemplo: autorizar el ingreso del pedido al inventario después de comprobar la recepción.
La relación puede representarse así:
Dato → contexto → información → evidencia verificable → decisión fundamentada.
No todos los datos constituyen evidencia suficiente. La calidad de la decisión depende tanto de la información disponible como de la confiabilidad de su origen.
1.2. ¿Cuándo se considera mejorado un flujo de información?
Un flujo de información puede considerarse mejorado cuando, frente a una situación inicial comparable, produce cambios favorables verificables en aspectos como:
- Exactitud: los datos representan correctamente los hechos que deben describir.
- Integridad o completitud: están presentes los datos necesarios para el propósito definido.
- Oportunidad: la información está disponible dentro del tiempo requerido.
- Trazabilidad: es posible reconstruir el origen, recorrido y modificaciones relevantes de la información.
- Accesibilidad controlada: las personas autorizadas pueden consultar la información cuando la necesitan.
- Consistencia: no aparecen contradicciones injustificadas entre registros relacionados.
No todas las organizaciones necesitan mejorar simultáneamente estos aspectos. La selección depende del problema diagnosticado.
Por ejemplo, una empresa puede disponer de datos correctos, pero recibirlos demasiado tarde para programar la producción. En ese caso, mejorar la oportunidad puede ser más importante que crear nuevos informes.
1.3. El papel de los Sistemas de Información Gerencial
Los Sistemas de Información Gerencial (SIG) permiten organizar y presentar información útil para apoyar la planificación, el control y las decisiones administrativas.
Sin embargo, un SIG no corrige automáticamente las deficiencias de los datos que recibe.
Si el sistema recibe una hora de entrega equivocada, puede calcular con gran precisión matemática un indicador basado en un registro incorrecto.
Esta situación demuestra un principio fundamental:
La precisión del cálculo no garantiza la confiabilidad de la información utilizada.
Por eso, antes de automatizar un proceso es necesario comprender cómo se generan, validan y utilizan sus datos.
2. Primer paso: identificar el problema mediante evidencias
Toda propuesta de mejora debe comenzar con un problema suficientemente documentado.
No es recomendable iniciar seleccionando un software, diseñando un tablero o proponiendo una automatización si todavía no está claro qué situación necesita corregirse.
2.1. Caso de estudio: devolución de libros en una biblioteca
Consideremos una biblioteca universitaria que registra los préstamos y devoluciones de sus libros.
Cuando un estudiante devuelve un libro, el sistema modifica su estado de «prestado» a «devuelto».
Sin embargo, durante una revisión se descubre que algunos registros no conservan información suficiente para determinar quién recibió el libro ni cuál fue el soporte de la devolución.
El registro muestra que el libro fue devuelto, pero no permite reconstruir completamente el evento.
¿Cuál es el problema?
El problema no consiste necesariamente en que se hayan perdido libros.
Tampoco significa que los estudiantes o funcionarios hayan incumplido sus responsabilidades.
El hallazgo comprobable es que ciertos registros carecen de trazabilidad suficiente para verificar la recepción conforme al procedimiento establecido.
Esta precisión resulta fundamental.
Si afirmamos que el libro se perdió sin tener evidencia, estaríamos convirtiendo una sospecha en una conclusión.
2.2. Diferencia entre evidencia, hallazgo, inferencia y supuesto
| Concepto | Significado | Ejemplo |
|---|---|---|
| Evidencia | Registro u observación que sustenta una afirmación | El sistema muestra una devolución sin identificar al receptor |
| Hallazgo | Situación identificada mediante criterios y evidencias | El registro carece de un dato exigido por el procedimiento |
| Inferencia | Conclusión razonada obtenida de la evidencia | La ausencia del receptor dificulta reconstruir la devolución |
| Supuesto | Condición aceptada provisionalmente sin comprobación suficiente | Se considera que todos los libros fueron recibidos correctamente |
Una inferencia puede ser razonable sin estar definitivamente demostrada.
Por ejemplo, encontrar registros incompletos permite inferir que existe un riesgo para la trazabilidad. No demuestra automáticamente que el inventario físico esté equivocado.
2.3. Cómo redactar correctamente un hallazgo
Una buena formulación debe indicar el criterio que debería cumplirse, la condición observada, la evidencia y el posible efecto.
Ejemplo:
Criterio: cada devolución debe contar con identificación del préstamo, fecha, hora y responsable de recepción.
Condición encontrada: algunos registros no contienen el responsable de recepción.
Evidencia: revisión de los registros seleccionados y sus campos disponibles.
Efecto potencial: dificultad para verificar posteriormente quién recibió el material.
Si todavía se desconoce por qué faltan los datos, debe indicarse que la causa está pendiente de investigación.
Esto evita atribuir el problema precipitadamente a una persona, un procedimiento o una tecnología.
3. Segundo paso: representar el flujo actual y el flujo mejorado
Después de comprender el hallazgo, necesitamos identificar dónde se origina la deficiencia.
Una herramienta útil consiste en representar el proceso antes y después de la mejora propuesta.
3.1. ¿Qué significa AS-IS?
AS-IS es una expresión utilizada para describir cómo funciona realmente un proceso en su situación actual.
Este mapa debe construirse mediante observaciones, entrevistas, revisión de registros y análisis del procedimiento existente.
En la biblioteca, el flujo actual podría describirse así:
- El usuario entrega físicamente el libro.
- Un funcionario recibe el material.
- Se modifica manualmente el estado del préstamo.
- El sistema conserva el nuevo estado.
- No siempre queda asociado el responsable ni el soporte de recepción.
El punto crítico aparece entre la recepción física y la confirmación documental del evento.
Aunque el libro haya sido recibido, la información registrada no siempre permite comprobarlo posteriormente.
3.2. ¿Qué significa TO-BE?
TO-BE describe cómo debería funcionar el proceso después de incorporar las mejoras propuestas.
Para la biblioteca:
- Se identifica el préstamo activo.
- Se verifica el material recibido.
- Se registra el responsable de la recepción.
- Se conserva la fecha y hora del evento.
- Se asocia una referencia verificable al soporte.
- Se comprueba que los campos obligatorios y las autorizaciones cumplen los requisitos.
- Se confirma la devolución o se remite a revisión cuando falta información.
Es importante comprender que el TO-BE todavía constituye una propuesta.
Dibujar el proceso mejorado no demuestra que ya esté funcionando ni que haya producido mejores resultados.
Para afirmarlo, necesitaremos comprobar los requisitos, realizar pruebas y medir resultados reales.
3.3. Comparación entre ambos escenarios
| Elemento | Flujo actual | Flujo propuesto |
|---|---|---|
| Identificación del préstamo | Existe | Se verifica antes de confirmar |
| Receptor | Puede faltar | Registro obligatorio |
| Hora de recepción | Puede faltar | Captura y validación |
| Soporte | Sin vínculo verificable | Asociado mediante identificador |
| Confirmación | Puede quedar incompleta | Sujeta a criterios definidos |
| Auditoría | Reconstrucción limitada | Consulta del historial relacionado |
La mejora no consiste simplemente en incorporar más campos. Cada dato debe responder a una necesidad real de control, trazabilidad o decisión.
4. Tercer paso: convertir los hallazgos en requisitos verificables
Identificar correctamente el problema no es suficiente.
Necesitamos traducirlo en condiciones específicas que permitan diseñar y posteriormente evaluar una solución.
Estas condiciones se denominan requisitos.
4.1. ¿Qué es un requisito verificable?
Es una condición que debe satisfacer una solución y cuyo cumplimiento puede comprobarse mediante una prueba, inspección, análisis o medición.
Comparemos dos formulaciones:
Requisito impreciso:
«El sistema debe mejorar el control de las devoluciones».
¿Cuánto debe mejorar? ¿Qué significa controlar? ¿Cómo se comprobará?
No tenemos una respuesta objetiva.
Requisito verificable:
«El sistema debe impedir la confirmación de una devolución cuando no exista una referencia válida al préstamo y al soporte requerido».
Esta formulación permite diseñar una prueba concreta.
4.2. Requisitos funcionales y no funcionales
Los requisitos funcionales describen qué debe hacer una solución.
Ejemplos:
- Asociar cada devolución a un préstamo existente.
- Registrar fecha, hora y responsable.
- Consultar el historial de un libro.
- Impedir la confirmación cuando falta evidencia obligatoria.
Los requisitos no funcionales describen condiciones de calidad, seguridad, desempeño u operación.
Ejemplos:
- Restringir la confirmación a usuarios autorizados.
- Conservar un historial de modificaciones.
- Proteger los datos personales.
- Presentar información comprensible para los usuarios.
Ambos tipos son importantes.
Una solución podría registrar correctamente las devoluciones y, al mismo tiempo, permitir que cualquier persona modifique sus datos. En tal caso, cumpliría determinadas funciones, pero presentaría una deficiencia de control.
4.3. Matriz de trazabilidad de requisitos
Una matriz de trazabilidad relaciona cada problema con los requisitos definidos, sus pruebas y las evidencias correspondientes.
| Hallazgo | Requisito | Prueba | Resultado esperado |
|---|---|---|---|
| Falta identificación del receptor | RF-01: registrar responsable | Intentar confirmar sin responsable | Confirmación bloqueada |
| No existe vínculo con el soporte | RF-02: asociar soporte válido | Confirmar sin referencia | Confirmación rechazada |
| Falta control de permisos | RNF-01: restringir autorización | Usuario sin permiso intenta confirmar | No cambia el estado |
| No se reconstruyen modificaciones | RNF-02: conservar historial | Modificar un registro autorizado | Cambio documentado |
Las siglas RF y RNF significan requisito funcional y requisito no funcional, respectivamente.
La utilidad de la matriz consiste en poder responder cuatro preguntas:
¿Qué problema queremos resolver? ¿Qué condición debe cumplir la solución? ¿Cómo vamos a probarla? ¿Qué evidencia demuestra el resultado de la prueba?
Cuando estas relaciones son claras, la propuesta es mucho más fácil de evaluar y defender técnicamente.
5. Cuarto paso: diseñar pruebas que permitan comprobar los requisitos
Una vez definidos los requisitos, el siguiente paso consiste en diseñar pruebas.
Aquí debemos diferenciar dos conceptos fundamentales: verificación y validación.
5.1. ¿Cuál es la diferencia entre verificar y validar?
Verificar consiste en comprobar que una solución cumple las especificaciones establecidas.
Pregunta orientadora: ¿construimos correctamente lo que especificamos?
Validar consiste en comprobar que la solución responde a las necesidades de las personas o de la organización.
Pregunta orientadora: ¿estamos resolviendo el problema que realmente importa?
Ejemplo:
El sistema bloquea correctamente una devolución sin soporte. La prueba técnica permite verificar el requisito.
Sin embargo, los funcionarios explican que algunas devoluciones legítimas se reciben durante contingencias en las que el soporte digital no está disponible.
Esto indica que debemos validar el procedimiento excepcional y analizar cómo manejarlo sin perder trazabilidad.
Una solución puede cumplir sus requisitos técnicos y, aun así, no responder adecuadamente a todas las necesidades operativas.
5.2. Pruebas positivas y negativas
En la biblioteca debemos probar situaciones normales y situaciones problemáticas.
Prueba positiva:
Un funcionario autorizado registra una devolución con identificador de préstamo, receptor, hora y soporte válido.
Resultado esperado: el sistema permite confirmar y conserva la información relacionada.
Prueba negativa:
Se intenta confirmar una devolución sin soporte obligatorio.
Resultado esperado: el sistema impide la confirmación y muestra qué condición falta.
Prueba de autorización:
Un usuario sin permiso intenta confirmar la devolución.
Resultado esperado: el sistema rechaza la operación y no modifica el estado previo.
5.3. Cómo documentar una prueba
| Campo | Ejemplo |
|---|---|
| Código | PR-01 |
| Requisito | RF-02 |
| Condición inicial | Préstamo activo |
| Datos de entrada | Devolución sin soporte |
| Acción | Seleccionar «Confirmar devolución» |
| Resultado esperado | Operación bloqueada |
| Resultado observado | Se diligencia durante la ejecución |
| Estado | Pendiente / aprobada / fallida |
| Evidencia | Registro de prueba o captura autorizada |
No debe confundirse el resultado esperado con el observado.
Si todavía no hemos realizado la prueba, no podemos afirmar que haya sido exitosa.
La prueba se considera aprobada cuando su ejecución proporciona evidencia suficiente de que el comportamiento observado satisface el criterio establecido.
6. Quinto paso: construir indicadores con datos confiables
Los indicadores permiten resumir aspectos del desempeño de un proceso.
No obstante, un porcentaje aislado puede resultar engañoso cuando desconocemos cómo se calculó.
Por esa razón, cada indicador debe tener una definición clara, variables identificadas, población de referencia, unidad de medida y reglas para tratar los datos faltantes.
6.1. Indicador de oportunidad de registro
Supongamos que la biblioteca establece, para un ejercicio académico, que cada devolución debe registrarse en un plazo máximo de 60 minutos después de su llegada.
Este plazo es una condición hipotética del ejemplo, no una regla general para bibliotecas.
Definamos primero el tiempo de registro:
Tᵢ = tᵣ − tₗ
Donde:
- (T_i): tiempo de registro de la devolución (i), en minutos.
- (t_{r,i}): hora de registro de la devolución (i).
- (t_{l,i}): hora de llegada de la devolución (i).
Cuando ambas horas están disponibles y son válidas, podemos determinar si el registro cumple el límite establecido.
El indicador se expresa:
Oportunidad (%) = (Nc / Ne) × 100
Donde:
- (O): oportunidad entre registros evaluables, expresada en porcentaje.
- (N_c): cantidad de registros evaluables que cumplen el plazo.
- (N_e): cantidad total de registros evaluables.
- (100): factor para expresar la proporción como porcentaje.
6.2. Indicador de cobertura de datos
Antes de interpretar el desempeño debemos preguntar cuántos registros tienen información suficiente para evaluarse.
La cobertura de datos se calcula:
Cobertura (%) = (Ne / Nt) × 100
Donde:
- (C): cobertura de datos, en porcentaje.
- (N_e): registros que cumplen las condiciones de evaluación.
- (N_t): total de registros incluidos en el periodo.
- (100): factor de conversión a porcentaje.
Estos indicadores no responden la misma pregunta.
La oportunidad mide el cumplimiento entre los registros que podemos evaluar.
La cobertura mide qué proporción del total puede evaluarse.
Por eso deben presentarse conjuntamente.
7. Sexto paso: resolver el caso práctico completo de la biblioteca
Regresemos al caso del boceto inicial.
Durante una jornada se registraron ocho devoluciones. En seis se dispone de la hora de llegada y de registro; cuatro de esos seis casos cumplen el plazo establecido.
Para hacer completamente visible la operación, construiremos un conjunto de datos académicos coherente con estos resultados.
Condiciones del ejemplo:
- Total de devoluciones: 8.
- Plazo máximo propuesto: 60 minutos.
- Devoluciones con información suficiente: 6.
- Devoluciones evaluables que cumplen el plazo: 4.
- Devoluciones sin hora de registro: 2.
7.1. Tabla de datos
| Devolución | Hora llegada | Hora registro | Tiempo (min) | Evaluación |
|---|---|---|---|---|
| D01 | 08:10 | 08:40 | 30 | Cumple |
| D02 | 09:25 | 10:05 | 40 | Cumple |
| D03 | 10:15 | 11:00 | 45 | Cumple |
| D04 | 11:40 | 13:20 | 100 | No cumple |
| D05 | 12:05 | Sin dato | — | No evaluable |
| D06 | 13:10 | 13:50 | 40 | Cumple |
| D07 | 14:20 | Sin dato | — | No evaluable |
| D08 | 15:05 | 16:30 | 85 | No cumple |
7.2. Calcular el tiempo de cada devolución
Tomemos D04.
La devolución llegó a las 11:40 y se registró a las 13:20.
Entre las 11:40 y las 12:40 transcurren 60 minutos.
Entre las 12:40 y las 13:20 transcurren otros 40 minutos.
Por lo tanto:
T_{D04}=60+40=100\text{ minutos}
Como el límite propuesto es de 60 minutos, la devolución D04 no cumple.
Ahora examinemos D02.
Llegó a las 09:25 y se registró a las 10:05.
[
T_{D02}=40\text{ minutos}
]
Este registro sí cumple.
Realizamos el mismo procedimiento con las demás devoluciones evaluables.
7.3. Calcular la oportunidad
Identificamos los registros que cumplen:
D01, D02, D03 y D06.
Por tanto:
N_c=4
Identificamos todos los evaluables:
D01, D02, D03, D04, D06 y D08.
Entonces:
N_e=6
Sustituimos:
[
O=\frac{4}{6}\times100
]
[
\boxed{O=66,67%}
]
Interpretación correcta: de las seis devoluciones para las cuales fue posible calcular el tiempo de registro, aproximadamente el 66,67 % cumplió el límite propuesto de 60 minutos.
No significa que el 66,67 % de todas las devoluciones cumpliera el plazo.
Tampoco mide la satisfacción de los usuarios ni demuestra por sí solo que el proceso haya mejorado.
Solo describe el comportamiento de los casos evaluables durante esa jornada.
7.4. Calcular la cobertura
Sabemos que:
[
N_e=6
]
[
N_t=8
]
Sustituimos:
[
C=\frac{6}{8}\times100
]
[
\boxed{C=75%}
]
Interpretación: el 75 % de las devoluciones de la jornada dispone de la información necesaria para calcular su tiempo de registro.
Por lo tanto, el 25 % restante carece de datos suficientes bajo los criterios establecidos.
7.5. ¿Por qué debemos presentar ambos indicadores?
Porque cada uno revela una situación distinta.
| Indicador | Resultado | Qué demuestra |
|---|---|---|
| Oportunidad entre evaluables | 66,67 % | Cuatro de seis casos medibles cumplieron el plazo |
| Cobertura de datos | 75 % | Seis de ocho casos tienen información suficiente |
| Registros no evaluables | 25 % | Dos de ocho requieren completar o investigar datos |
Si presentamos únicamente el 66,67 %, el lector podría interpretar que conocemos el comportamiento de todas las devoluciones.
Pero no es así.
Existen dos casos cuyo cumplimiento desconocemos.
No corresponde considerarlos oportunos ni tardíos sin definir y justificar una regla diferente.
7.6. ¿Qué ocurre si todos los registros tienen datos faltantes?
Si ningún registro puede evaluarse:
[
N_e=0
]
La fórmula de oportunidad tendría denominador cero.
No debemos informar una oportunidad del 0 %, porque ese valor significaría que se evaluaron casos y ninguno cumplió.
Lo correcto sería mostrar:
Oportunidad: no calculable. No existen registros evaluables en el periodo.
La cobertura, si hubo registros totales, sí puede calcularse y sería 0 %.
Esta diferencia evita interpretar la ausencia de información como incumplimiento operativo demostrado.
7.7. ¿Qué decisión debería tomar la biblioteca?
No sería suficiente concluir que la oportunidad es del 66,67 %.
La biblioteca debería investigar los dos registros no evaluables, revisar los dos incumplimientos y establecer si el proceso necesita cambios en sus procedimientos de recepción, captura o validación.
Posteriormente podría realizar un nuevo periodo de medición.
Solo entonces comenzaríamos a disponer de evidencia para evaluar el desempeño después de una intervención.
8. Séptimo paso: diseñar un prototipo y comprobar la mejora
Hasta ahora hemos diagnosticado el problema, definido requisitos, diseñado pruebas y construido indicadores.
El siguiente desafío consiste en permitir que las personas utilicen la información correctamente.
Para ello podemos construir un prototipo.
8.1. ¿Qué es un prototipo?
Es una representación preliminar de una solución que permite explorar su funcionamiento, comunicar una propuesta o evaluar determinadas características antes de implementarla completamente.
Un prototipo no tiene que ser un sistema informático sofisticado.
Puede consistir en una hoja de cálculo, un formulario, un tablero esquemático o una maqueta navegable.
Lo importante es que permita evaluar las decisiones y tareas para las que fue diseñado.
8.2. Prototipo de tablero para la biblioteca
Un primer tablero podría mostrar:
| Elemento | Valor presentado |
|---|---|
| Periodo | Jornada analizada |
| Total de devoluciones | 8 |
| Registros evaluables | 6 |
| Registros oportunos | 4 |
| Oportunidad entre evaluables | 66,67 % |
| Cobertura de datos | 75 % |
| Devoluciones sin información suficiente | D05 y D07 |
| Devoluciones que exceden el plazo | D04 y D08 |
El tablero debe permitir consultar el detalle que respalda cada resultado.
Por ejemplo, cuando alguien selecciona «Registros no evaluables», debería encontrar D05 y D07 y comprobar qué información falta.
Este diseño convierte el indicador en una herramienta para actuar y no solamente en una cifra para presentar.
8.3. ¿Cómo probar la utilidad del prototipo?
Podemos pedir a un funcionario que realice una tarea específica:
«Identifique las devoluciones que necesitan revisión y explique qué soporte solicitaría para resolver cada caso».
Durante la prueba observamos si el usuario:
- Localiza el indicador correcto.
- Interpreta adecuadamente su significado.
- Identifica las excepciones.
- Reconoce qué datos necesita revisar.
- Puede explicar la decisión con base en la información visible.
Si el usuario interpreta el 66,67 % como una calificación general de satisfacción, el tablero no está comunicando correctamente el alcance de la medida.
En ese caso, conviene modificar su etiqueta, mostrar el numerador y denominador o incorporar una explicación contextual.
8.4. ¿Un prototipo aprobado demuestra que el proceso mejoró?
No necesariamente.
Una prueba del prototipo puede demostrar que la solución permite realizar determinadas tareas, cumple ciertos requisitos o resulta comprensible para sus usuarios.
Para afirmar que el proceso real mejoró, debemos implementar el cambio, medir el desempeño y comparar los resultados bajo condiciones razonablemente equivalentes.
9. Cómo demostrar que una mejora produjo resultados
Esta etapa es decisiva.
Una organización puede ejecutar todas las pruebas de un sistema y, aun así, desconocer si su desempeño operativo realmente cambió.
Para evaluar la mejora necesitamos una línea base y una medición posterior.
9.1. ¿Qué es la línea base?
Es una referencia del desempeño inicial del proceso antes de realizar la intervención.
En nuestro ejemplo, los resultados de una jornada permiten ilustrar una medición inicial, pero no necesariamente constituyen una línea base representativa.
Para establecerla adecuadamente convendría revisar más jornadas, diferentes turnos y condiciones de operación.
9.2. Ejemplo de comparación antes y después
Supongamos que, después de implementar un control de registro y validación, se analizan dos periodos con 100 devoluciones cada uno.
Los siguientes datos son completamente hipotéticos y sirven para explicar el método de comparación.
| Indicador | Antes | Después |
|---|---|---|
| Total de devoluciones | 100 | 100 |
| Registros evaluables | 75 | 96 |
| Registros que cumplen el plazo | 50 | 88 |
| Cobertura | 75 % | 96 % |
| Oportunidad entre evaluables | 66,67 % | 91,67 % |
Para calcular la oportunidad posterior:
[
O_{\text{después}}=\frac{88}{96}\times100
]
[
O_{\text{después}}=91,67%
]
La diferencia en puntos porcentuales es:
[
\Delta O=O_{\text{después}}-O_{\text{antes}}
]
[
\Delta O=91,67-66,67
]
[
\boxed{\Delta O=25,00\text{ puntos porcentuales}}
]
Esto indica un incremento de 25 puntos porcentuales en la oportunidad entre registros evaluables.
La cobertura también cambia:
[
\Delta C=96-75
]
[
\boxed{\Delta C=21\text{ puntos porcentuales}}
]
La organización registra una mayor proporción de casos con información suficiente y una mayor proporción de cumplimiento entre los casos evaluables.
9.3. ¿Podemos afirmar que la solución causó la mejora?
Todavía debemos ser cuidadosos.
La diferencia observada es compatible con una mejora, pero no demuestra por sí sola que la solución implementada haya sido su única causa.
Debemos analizar factores como:
- Diferencias en el volumen y complejidad de las devoluciones.
- Cambios de personal o capacitación.
- Modificaciones en los horarios.
- Problemas técnicos en alguno de los periodos.
- Cambios en los criterios de medición.
- Condiciones extraordinarias que afectaran el servicio.
También debemos comprobar que las horas se hayan registrado con el mismo significado y bajo la misma regla de evaluación.
Si los periodos no son comparables, el aumento del indicador podría tener explicaciones diferentes.
En evaluaciones más rigurosas pueden utilizarse mediciones repetidas, análisis de tendencias, grupos de comparación o diseños experimentales y cuasiexperimentales cuando sean viables.
La conclusión debe ser proporcional a la evidencia disponible.
No es lo mismo observar mejores resultados después de un cambio que demostrar rigurosamente cuánto de ese resultado fue causado por el cambio.
10. Aplicación en ingeniería industrial: trazabilidad de un CEDI
Ahora traslademos la metodología a un Centro de Distribución, conocido como CEDI.
En una operación logística, los productos pasan por recepción, verificación, almacenamiento, preparación y despacho.
En cada etapa se producen movimientos físicos y movimientos de información.
Aunque ambos están relacionados, no son idénticos.
10.1. Movimiento físico y movimiento informacional
Supongamos que un operario traslada una caja desde la zona de recepción hasta una ubicación de almacenamiento.
Movimiento físico: la caja cambia de ubicación.
Movimiento informacional: el sistema registra que la caja fue trasladada, por quién, cuándo y hacia dónde.
Puede ocurrir que la caja se encuentre físicamente en la ubicación correcta, pero que el sistema todavía muestre su posición anterior.
En ese caso tenemos una discrepancia entre la operación y su representación informacional.
Esta diferencia puede provocar búsquedas innecesarias, errores en el picking, retrasos y decisiones equivocadas sobre disponibilidad de inventario.
10.2. Caso de transferencia de custodia
Un operario entrega una unidad logística a otro responsable.
El procedimiento establece que la transferencia debe quedar documentada.
Sin embargo, algunos movimientos muestran únicamente el estado «transferido», sin identificar al receptor.
Aplicamos la metodología:
Hallazgo: existen transferencias sin identificación verificable del receptor.
Requisito: cada transferencia confirmada debe asociar unidad logística, ubicación, fecha, hora y receptor autorizado.
Prueba: intentar confirmar una transferencia sin receptor.
Resultado esperado: la confirmación se bloquea y la transferencia conserva un estado pendiente de revisión.
Evidencia: registro del evento, identificación de la unidad logística, usuario autorizado y referencia de confirmación.
Decisión: aceptar la transferencia, solicitar aclaración o investigar una incidencia.
10.3. Indicador de trazabilidad
Podríamos definir:
[
IT=\frac{N_{tv}}{N_{tt}}\times100
]
Donde:
- (IT): índice de trazabilidad documental, en porcentaje.
- (N_{tv}): número de transferencias que cumplen todos los criterios de trazabilidad definidos.
- (N_{tt}): total de transferencias del periodo.
Supongamos 250 transferencias, de las cuales 230 contienen los registros exigidos.
[
IT=\frac{230}{250}\times100
]
[
\boxed{IT=92%}
]
Interpretación: el 92 % de las transferencias cuenta con los elementos documentales necesarios según el criterio definido.
Esto no demuestra automáticamente que el 92 % de los movimientos físicos haya sido ejecutado correctamente.
Para comprobar la concordancia entre los registros y el inventario físico se necesitaría una verificación adicional.
10.4. ¿Por qué importa a la ingeniería industrial?
Porque la información influye directamente en la coordinación de operaciones, la gestión de inventarios, el control de procesos y la utilización de recursos.
Un dato faltante puede generar actividades que no agregan valor, como volver a revisar mercancía, llamar a otro responsable, buscar documentos o repetir registros.
Mejorar el flujo de información contribuye potencialmente a reducir estas actividades, pero sus efectos deben medirse y no darse por supuestos.
11. Responsabilidades, controles y viabilidad de la mejora
Una solución sostenible requiere establecer responsabilidades.
No basta con tener un sistema capaz de registrar datos si nadie sabe quién debe capturarlos, validarlos o corregirlos.
11.1. Roles para gobernar la información
| Rol | Responsabilidad |
|---|---|
| Responsable del proceso | Definir qué información necesita la operación |
| Registrador | Capturar los datos en el momento correspondiente |
| Validador | Verificar las condiciones exigidas |
| Custodio de información | Administrar conservación, acceso y protección |
| Analista | Evaluar indicadores y excepciones |
| Tomador de decisiones | Utilizar los resultados y autorizar acciones |
Estos roles pueden distribuirse entre distintas personas según el tamaño y naturaleza de la organización.
11.2. Controles preventivos, detectivos y correctivos
Los controles pueden clasificarse según el momento en que actúan.
Preventivo: procura impedir que ocurra un error.
Ejemplo: impedir confirmar una devolución sin el identificador obligatorio.
Detectivo: permite identificar un error o situación anómala.
Ejemplo: generar un reporte diario de registros incompletos.
Correctivo: permite atender una situación ya detectada y reducir sus consecuencias.
Ejemplo: aplicar un procedimiento autorizado para completar un registro mediante evidencia adicional, conservando el historial del cambio.
Cada control debe estar asociado a un responsable, una evidencia y un criterio de seguimiento.
11.3. ¿Siempre necesitamos un sistema nuevo?
No.
Una mejora inicial puede consistir en definir un identificador único, estandarizar un formulario, reorganizar responsabilidades o conservar un historial de cambios.
Si la solución puede implementarse mediante procedimientos y herramientas existentes, conviene evaluar esa alternativa antes de realizar inversiones más complejas.
La tecnología debe responder a una necesidad de información identificada, no convertirse en el punto de partida obligatorio.
11.4. Uso responsable de inteligencia artificial
La inteligencia artificial puede apoyar el análisis de requisitos, la revisión de formularios, la identificación de inconsistencias y la propuesta de indicadores.
Sin embargo, sus respuestas no constituyen evidencia operativa por sí mismas.
Si una herramienta de IA indica que el proceso mejoró, esa afirmación debe confrontarse con registros y mediciones autorizadas.
También deben protegerse los datos personales, la información empresarial confidencial y los permisos de acceso.
En un proceso de mejora, el criterio profesional consiste en poder explicar de dónde provienen los datos, cómo se verificaron y por qué sustentan una conclusión.
12. Errores frecuentes al comprobar mejoras del flujo de información
Error 1. Confundir una propuesta con una mejora demostrada
Dibujar un proceso nuevo o presentar una maqueta no demuestra que la operación haya mejorado.
Cómo evitarlo: separar claramente diseño, pruebas, implementación y medición posterior.
Error 2. Utilizar indicadores sin explicar su denominador
Presentar un 90 % sin especificar sobre qué población se calculó puede generar conclusiones equivocadas.
Cómo evitarlo: acompañar el porcentaje con numerador, denominador, periodo y reglas de cálculo.
Error 3. Ocultar registros sin información
Excluir los registros incompletos sin declararlo produce una imagen parcial de la operación.
Cómo evitarlo: calcular y mostrar también la cobertura de datos.
Error 4. Confundir ausencia de evidencia con demostración de incumplimiento
Si falta el comprobante de recepción, no necesariamente significa que el libro nunca fue recibido.
Cómo evitarlo: distinguir los hechos observados de las hipótesis que todavía necesitan investigación.
Error 5. Diseñar controles sin considerar al usuario
Una regla puede resultar técnicamente correcta y crear dificultades durante contingencias operativas.
Cómo evitarlo: validar los requisitos con quienes ejecutan y supervisan el proceso.
Error 6. Comparar periodos que utilizan diferentes criterios
Un indicador puede aumentar simplemente porque cambiamos la forma de contar los registros.
Cómo evitarlo: documentar las definiciones y procurar condiciones comparables.
Error 7. Confundir correlación temporal con causalidad
El desempeño mejora después de implementar una herramienta, pero también pudieron intervenir otros factores.
Cómo evitarlo: identificar explicaciones alternativas y seleccionar un método de evaluación adecuado.
13. Preguntas frecuentes
¿Cómo se comprueba una mejora del flujo de información?
Se identifica el problema mediante evidencias, se documenta el proceso actual, se establecen requisitos verificables, se realizan pruebas y se comparan indicadores antes y después de la intervención.
¿Cuál es la diferencia entre mejorar los datos y mejorar el flujo de información?
Mejorar los datos significa elevar atributos como exactitud, completitud y consistencia. Mejorar el flujo implica intervenir también la forma en que esos datos se capturan, procesan, transfieren, consultan y utilizan.
Ambas mejoras pueden estar relacionadas, pero no son equivalentes.
¿Qué indicadores permiten evaluar un flujo de información?
Dependen del propósito del proceso. Pueden utilizarse oportunidad, cobertura, trazabilidad, integridad de registros, consistencia, tiempo de respuesta y proporción de incidencias resueltas.
¿Un tablero de indicadores demuestra que una empresa ha mejorado?
No necesariamente. Un tablero muestra información y resultados calculados. Para demostrar mejora es necesario comprobar la calidad de los datos, la comparabilidad de las mediciones y el comportamiento real del proceso.
¿Qué diferencia existe entre validar y verificar?
Verificar consiste en comprobar el cumplimiento de especificaciones. Validar consiste en comprobar que la solución satisface las necesidades de sus usuarios y partes interesadas.
¿Se puede mejorar un proceso sin comprar software?
Sí. La estandarización de procedimientos, la definición de responsabilidades, los controles y la calidad de los registros pueden aportar mejoras sin requerir una plataforma nueva.
¿Qué ocurre si faltan datos para calcular un indicador?
Primero debe determinarse cuáles registros son evaluables. Los faltantes deben identificarse y tratarse conforme a reglas documentadas. Si el denominador es cero, el indicador no debe calcularse mediante una división inválida.
14. Conclusiones: mejorar significa poder demostrarlo
Una propuesta de mejora del flujo de información adquiere valor cuando permite resolver un problema identificado y cuando sus resultados pueden examinarse mediante evidencia suficiente.
En este artículo vimos que los registros de un proceso no siempre permiten reconstruir lo ocurrido. Un estado marcado como «completado» puede resultar insuficiente si no conocemos quién realizó la actividad, cuándo ocurrió y qué evidencia la respalda.
También aprendimos que un requisito debe poder comprobarse, que una prueba técnica no equivale automáticamente a una mejora operativa y que los indicadores deben presentar tanto los resultados como sus limitaciones.
El ejemplo de la biblioteca permitió comprender por qué una oportunidad del 66,67 % debe interpretarse junto con una cobertura del 75 %.
Al trasladar la misma metodología a un Centro de Distribución, observamos que la trazabilidad informacional puede ser tan importante para el control como el movimiento físico de la mercancía.
La lección para estudiantes, profesionales, empresarios y consultores es clara:
No debemos preguntarnos únicamente si una solución funciona. Debemos preguntarnos qué problema resuelve, qué evidencia tenemos de su funcionamiento y qué resultados comprobables produce.
Esa diferencia permite avanzar de las propuestas atractivas a una gestión verdaderamente sustentada en información.
15. Aplicación profesional: de los datos a mejores decisiones
Si una empresa enfrenta diferencias entre inventario físico y sistema, registros duplicados, documentos sin trazabilidad o indicadores que no explican sus resultados, conviene realizar primero un diagnóstico del flujo de información.
Ese diagnóstico debe identificar las decisiones críticas, las fuentes de datos, los responsables, las deficiencias de calidad y los controles necesarios.
Desde la ingeniería industrial, la gestión de procesos y los Sistemas de Información Gerencial es posible integrar estas dimensiones para formular soluciones proporcionadas a las necesidades reales de cada organización.
Antes de invertir en una nueva plataforma, identifica qué decisión empresarial necesita una evidencia que hoy no puede reconstruirse.
En oscarcaita.com encontrarás contenidos y herramientas sobre ingeniería industrial, productividad, sistemas de información, procesos y mejora continua para fortalecer tu capacidad de análisis y decisión.
Oscar Caita
Ingeniería | Gestión | Productividad | Mejora continua
oscarcaita.com
Referencias bibliográficas
Dumas, M., La Rosa, M., Mendling, J., & Reijers, H. A. (2018). Fundamentals of business process management (2nd ed.). Springer. https://doi.org/10.1007/978-3-662-56509-4
International Requirements Engineering Board. (s. f.). CPRE online glossary. https://cpre.ireb.org/en/downloads-and-resources/glossary
Performance Analysis Community. (2017, 5 de diciembre). How to set performance metrics for your service. GOV.UK. https://www.gov.uk/service-manual/measuring-success/how-to-set-performance-metrics-for-your-service
Performance Analysis Community. (2016). Using performance data to improve your service: An introduction. GOV.UK. https://www.gov.uk/service-manual/measuring-success/using-data-to-improve-your-service-an-introduction
