Por Oscar Caita | Sistemas de información gerencial 

Un reporte puede mostrar cifras correctas y dejar al responsable sin saber qué debe revisar. Sucede cuando los datos no conservan la evidencia de una operación, los indicadores mezclan poblaciones distintas o la pantalla oculta las excepciones. Para resolverlo, conviene definir primero la decisión que se necesita tomar y luego diseñar la información que la hace posible. 

Los requisitos de información especifican qué información necesita una persona para realizar una tarea o tomar una decisión, con qué detalle, en qué momento y bajo qué condiciones de calidad y acceso. Al diseñar un sistema, esas necesidades se traducen en comportamientos verificables, reglas y condiciones de operación. 

En este artículo recorreremos siete pasos con una biblioteca como caso de trabajo. El método también puede aplicarse al seguimiento de pedidos, mantenimiento, inventarios o solicitudes de servicio. El propósito es que puedas formular una propuesta comprobable antes de invertir en desarrollo. 

Para ubicar este trabajo dentro de la gestión organizacional, puedes consultar también la explicación de los sistemas de información gerencial. 

Nota sobre el ejemplo: la biblioteca, los registros, las metas y las pruebas son simulados con fines educativos. Los ocho préstamos y las cinco devoluciones pertenecen a un diagnóstico previo a los controles propuestos. No representan resultados reales de una institución ni demuestran una mejora implementada. 

1. Identificar el problema con evidencia 

La situación inicial es sencilla: el registro de la biblioteca indica que un ejemplar fue devuelto, pero el responsable no logra encontrar una constancia de recepción asociada al préstamo. El dato «devuelto» existe; lo que falta es la posibilidad de comprobar quién recibió el material y con qué soporte. 

El hallazgo debe describir una condición observable. «El sistema es malo» expresa una valoración demasiado amplia. «La devolución D03 figura registrada y no tiene una referencia de recepción válida» señala un caso que se puede revisar. 

Para comprenderlo, consulta al personal de circulación, observa cómo recibe los libros y contrasta sus explicaciones con registros y comprobantes. Una entrevista ayuda a conocer el trabajo; la revisión documental permite comprobar qué quedó registrado. Si las versiones no coinciden, conserva la discrepancia como una pregunta pendiente. 

Elemento	Ejemplo en la biblioteca
Evidencia observada	D03 está registrada como devuelta y no tiene soporte válido localizable.
Riesgo por investigar	Aceptar una devolución sin poder reconstruir la recepción del ejemplar.
Hipótesis de causa	El procedimiento podría permitir cerrar sin verificar el soporte.
Comprobación pendiente	Observar el cierre y revisar permisos, validaciones y archivos disponibles.

La falta de soporte no demuestra por sí sola que el libro se perdió o que una persona incumplió. Esa distinción evita diseñar controles sobre una causa que todavía no se ha confirmado. 

2. Precisar quién necesita información y para qué 

La necesidad del responsable de circulación es comprobar la recepción del ejemplar antes de confirmar la devolución. Para hacerlo necesita identificar el préstamo, conocer el ejemplar recibido, reconocer al receptor y localizar la evidencia correspondiente. 

«Necesitamos una aplicación» adelanta una alternativa tecnológica. La necesidad puede atenderse inicialmente con un procedimiento y un registro controlado, o requerir un sistema más completo si el volumen, la simultaneidad y los riesgos lo justifican. 

Una forma de aclararla es completar esta frase: «La persona que desempeña [rol] necesita conocer [información], en [momento], para decidir [acción]». 

En el caso: «El responsable de circulación necesita consultar el préstamo abierto y la constancia de recepción al recibir el ejemplar, para decidir si puede confirmar la devolución o debe dejarla pendiente de revisión». 

Rol	Información necesaria	Decisión que permite
Auxiliar de circulación	Préstamo, ejemplar y soporte de recepción	Preparar el registro y señalar datos faltantes.
Responsable autorizado	Evidencia válida y correspondencia con el préstamo	Confirmar la devolución o solicitar corrección.
Coordinador	Indicadores, registros excluidos y casos pendientes	Investigar causas y asignar acciones de mejora.

Cada acceso debe responder a la función del rol. Un tablero de coordinación puede mostrar resultados agregados y reservar los detalles personales para quienes los necesitan en su trabajo. 

3. Redactar requisitos que se puedan comprobar 

Un requisito útil describe una capacidad o condición concreta de la solución. Para los requisitos funcionales puede utilizarse esta estructura: el sistema debe + acción observable + objeto + condición aplicable. 

Por ejemplo: «Al confirmar una devolución, el sistema debe vincularla con un préstamo abierto y conservar la fecha y hora de recepción, el identificador del receptor y la referencia del soporte validado». 

La redacción debe permitir una prueba. Expresiones como «rápido», «amigable» o «seguro» requieren condiciones que indiquen cómo se evaluarán. La ingeniería de requisitos distingue comportamientos funcionales, requisitos de calidad y restricciones; conviene documentarlos de manera que cada uno pueda revisarse por separado (IREB, s. f.). 

Diferencias entre necesidad, requisito y regla de negocio 

Tipo	Qué expresa	Ejemplo propuesto
Necesidad de información	Lo que el usuario requiere conocer para actuar	Saber si existe evidencia suficiente para aceptar la devolución.
Requisito funcional RF01	Un comportamiento que debe ofrecer el sistema	Asociar la devolución con el préstamo abierto y el soporte validado.
Regla de negocio RN01	Una política que gobierna el proceso	Solo el responsable de circulación autorizado puede confirmar la devolución.
Requisito funcional RF02	El mecanismo que aplica esa política	Verificar el permiso y rechazar la confirmación cuando el usuario no esté autorizado.
Requisito de calidad RC01	Un nivel medible de desempeño	Mostrar el detalle de un préstamo en máximo 2 segundos en al menos el 95 % de las consultas, bajo el escenario de carga acordado.
Restricción de solución RS01	Un límite impuesto al diseño	Utilizar el servicio institucional de autenticación, si su uso es obligatorio para el proyecto.

El tiempo de 2 segundos es una condición ilustrativa. Para aceptar RC01 hay que acordar además el volumen de datos, los usuarios concurrentes, la red, el punto de medición y la muestra de consultas. Sin ese escenario, los resultados de dos pruebas podrían ser incomparables. 

Una política de acceso puede generar varios requisitos. Conviene separar la autorización, la verificación del soporte y el registro de cambios para localizar con precisión qué funciona y qué debe corregirse. 

Delimitar el alcance y priorizar 

Antes de construir, distingue lo indispensable para operar de lo que puede esperar. En este ejemplo, vincular préstamo y devolución, validar la recepción y conservar trazabilidad tiene prioridad sobre personalizar colores o añadir gráficos decorativos. 

Registra la prioridad, la razón, el responsable de aprobarla y las dependencias. Un tablero de devoluciones con soporte depende de que exista una definición de soporte válido y de que el dato se capture. Desarrollar el gráfico primero dejaría pendiente el fundamento del indicador. 

4. Definir criterios de aceptación y pruebas 

Los criterios de aceptación establecen las condiciones que debe cumplir un resultado para ser aceptado. Una prueba de aceptación ejecuta un escenario y contrasta lo observado con esas condiciones (IREB, s. f.). 

Para RF01, la biblioteca debe acordar qué entiende por soporte válido. En este caso simulado, es una constancia con identificador único, asociada al préstamo y al ejemplar recibido, con fecha y hora de recepción y receptor identificado. La persona autorizada verifica su correspondencia antes de confirmar. Puede ser una evidencia electrónica; no se exige una fotografía o un documento impreso por defecto. 

El sistema debe poder conservar un registro provisional como «pendiente de validación» cuando falta evidencia. Ese estado permite investigar sin presentar una recepción incompleta como devolución confirmada. 

Prueba	Condición y acción	Resultado esperado
PA01	Usuario autorizado intenta confirmar sin soporte	Bloquea la confirmación, indica qué falta y conserva el caso pendiente.
PA02	Usuario autorizado aporta soporte válido del préstamo abierto	Confirma una sola devolución y conserva sus vínculos, receptor y marcas de tiempo.
PA03	Se escribe «pendiente» en lugar de una referencia verificable	Rechaza ese valor como soporte válido.
PA04	Usuario sin permiso intenta confirmar	Rechaza la acción y conserva el estado anterior.
PA05	Se presenta un soporte correspondiente a otro préstamo	Rechaza la asociación incorrecta.
PA06	Se reenvía la misma confirmación o se hace doble clic	Evita crear una segunda devolución del mismo préstamo.

Para cada ejecución registra la versión probada, los datos usados, el resultado observado, la evidencia y quién revisó. Una captura del mensaje puede ayudar a documentar la prueba; no sustituye la comprobación de que el estado y las relaciones quedaron correctamente guardados. 

La maqueta permite discutir estas reglas. Comprobar que los permisos se aplican o que el doble clic no duplica registros requiere una implementación ejecutable. 

5. Organizar los datos sin perder la relación entre operaciones 

Un mismo ejemplar puede prestarse muchas veces. Su código identifica el objeto físico, pero cada operación necesita un identificador propio. Si el ejemplar E014 se presta en dos momentos diferentes, P001 y P009 son dos préstamos legítimos del mismo ejemplar. 

Para simplificar, el modelo de este artículo supone un ejemplar por préstamo y una única devolución completa por préstamo. Un préstamo abierto todavía no tiene devolución; uno cerrado correctamente tiene una. Si la biblioteca presta varios ejemplares en una sola transacción o admite devoluciones parciales, deberá incorporar el detalle correspondiente y revisar estas relaciones. 

Registro	Identificador principal	Datos mínimos del ejemplo
Ejemplar	ID_ejemplar	Código del ejemplar y referencia bibliográfica.
Préstamo	ID_prestamo	ID_ejemplar, usuario, fecha y hora del préstamo, vencimiento y fecha y hora del registro.
Devolución	ID_devolucion	ID_prestamo, fecha y hora de recepción, receptor, referencia de soporte y estado de validación.

La clave primaria identifica de manera única cada fila. La clave foránea referencia un registro de otra tabla: en Devolución, ID_prestamo señala a qué préstamo corresponde. Estas restricciones ayudan a evitar relaciones inexistentes (PostgreSQL Global Development Group, s. f.). 

Una clave foránea por sí sola no impide que dos devoluciones apunten al mismo préstamo. Bajo la regla de una sola devolución completa, también se necesita impedir la repetición de ID_prestamo en Devolución. Esto muestra por qué el modelo de datos debe expresar las reglas acordadas y no limitarse a dibujar tablas. 

Conservar las marcas de tiempo y los cambios 

La hora del préstamo indica cuándo ocurrió la entrega del ejemplar. La hora del registro indica cuándo esa operación quedó incorporada al sistema. Ambas deben conservarse si se quiere medir demora de carga. Usar una sola hora para los dos hechos impediría distinguir un registro oportuno de uno tardío. 

Los cambios relevantes deben permitir reconstruir el valor anterior, el nuevo valor, la persona que modificó, el momento y el motivo. También se deben acordar responsables de corrección y permisos de consulta. Tener identificadores no garantiza que los datos sean ciertos ni reemplaza la verificación de la recepción. 

La relación entre registros, transformaciones y evidencias se amplía en el artículo sobre ciclo de vida de la información y trazabilidad de datos. 

6. Construir indicadores con denominadores claros 

Un indicador debe responder a una pregunta de gestión. Las guías de GOV.UK recomiendan definir el propósito del servicio y seleccionar medidas que permitan evaluar su desempeño; también aconsejan combinar métricas con otras formas de comprender lo que ocurre (Performance analysis community, 2017; Government Digital Service, s. f.). 

En la biblioteca analizaremos dos preguntas: ¿los préstamos se registran dentro del tiempo acordado? ¿las devoluciones registradas tienen evidencia válida? Son preguntas distintas y requieren poblaciones diferentes. 

Indicador 1 Registro oportuno de préstamos 

El periodo simulado es del 5 al 9 de octubre de 2026. Se evalúan los préstamos ocurridos en ese intervalo que, al momento del corte, tienen ambas marcas de tiempo válidas. El plazo propuesto es de máximo 10 minutos entre el préstamo y su registro, incluido el minuto 10. 

Préstamo	Demora de registro en minutos	Clasificación con plazo de 10 minutos
P001	4	Oportuno
P002	6	Oportuno
P003	9	Oportuno
P004	10	Oportuno
P005	7	Oportuno
P006	8	Oportuno
P007	12	Tardío
P008	18	Tardío

Fórmula en texto: Registro oportuno (%) = (Número de préstamos registrados dentro del plazo ÷ Total de préstamos evaluables del periodo) × 100. 

El numerador cuenta los seis préstamos cuya demora es de 10 minutos o menos. El denominador cuenta los ocho préstamos evaluables del mismo periodo. El factor 100 convierte la proporción en porcentaje. 

Sustitución: Registro oportuno = (6 ÷ 8) × 100 = 75 %. 

El resultado significa que 75 de cada 100 préstamos evaluables serían oportunos si se conservara esa proporción. En la muestra observada fueron seis de ocho. No significa que el 75 % de los usuarios esté satisfecho ni que el 75 % de los libros se haya devuelto. 

Si se propone una meta de 90 %, la brecha es: 

Brecha = Meta − Resultado = 90 % − 75 % = 15 puntos porcentuales. 

La diferencia entre ambos porcentajes se expresa en puntos porcentuales. Una variación relativa sería otro cálculo y respondería a otra pregunta. 

Con solo ocho casos, cada préstamo representa 12,5 puntos porcentuales. Siete oportunos darían 87,5 %; para alcanzar al menos 90 % con esa misma cantidad de casos se necesitarían ocho oportunos, equivalentes al 100 %. Por eso el tablero debe mostrar también el tamaño de la muestra. 

La acción es revisar P007 y P008: contrastar sus horas y preguntar qué ocurrió. La demora podría relacionarse con disponibilidad del sistema, carga de atención o captura diferida; los datos presentados todavía no permiten escoger una causa. 

Indicador 2 Devoluciones registradas con soporte válido 

En el mismo periodo se identifican cinco devoluciones históricas registradas: D01, D02, D03, D04 y D05. Cuatro tienen soporte válido. D03 no lo tiene y queda identificada para regularización. 

Fórmula en texto: Devoluciones con soporte válido (%) = (Número de devoluciones registradas con soporte válido ÷ Total de devoluciones registradas del periodo) × 100. 

Sustitución: Devoluciones con soporte válido = (4 ÷ 5) × 100 = 80 %. 

El numerador son las cuatro devoluciones cuyo soporte cumple la regla acordada. El denominador incluye las cinco registradas, también la que no tiene soporte. Excluir esa devolución del denominador ocultaría precisamente la falla que se busca medir. 

Este indicador evalúa la evidencia de las devoluciones registradas. No permite saber cuántas recepciones físicas nunca se registraron: para eso haría falta contrastar otra fuente, como un registro independiente de recepción. 

La meta ilustrativa es 100 %. El responsable debe investigar D03 y recuperar o validar la evidencia disponible. Corregir el registro no autoriza a inventar un comprobante ni a alterar las horas históricas. 

La existencia de D03 corresponde al diagnóstico anterior a la solución. Tras implementar el bloqueo, conviene seguir revisando registros heredados, importaciones y posibles excepciones autorizadas; además, comprobar que el nuevo control funciona. 

Demora de registro y exceso sobre el plazo 

Para P007, el préstamo ocurrió a las 10:00 y se registró a las 10:12 del mismo día. 

Demora de registro = Fecha y hora del registro − Fecha y hora del préstamo. 

Demora de P007 = 10:12 − 10:00 = 12 minutos. 

Exceso sobre el plazo = Máximo entre 0 y (Demora de registro − Plazo permitido). 

Exceso de P007 = Máximo entre 0 y (12 − 10) = 2 minutos. 

El máximo con cero evita presentar excesos negativos cuando el registro es oportuno. Para calcular intervalos que cruzan medianoche se utilizan fecha y hora completas. Una demora negativa debe investigarse como inconsistencia; no debe clasificarse automáticamente como registro oportuno. 

Estos 12 minutos miden demora de carga. Para medir cuánto esperó una persona por el servicio se necesitarían otros eventos, por ejemplo, llegada e inicio de atención o solicitud y entrega del ejemplar. 

Ficha mínima para interpretar los indicadores 

Campo	Registro oportuno	Devoluciones con soporte
Pregunta	¿Se registran a tiempo los préstamos?	¿Las devoluciones registradas tienen evidencia válida?
Fuente	Préstamos y sus marcas de tiempo	Devoluciones y soportes verificados
Periodo y corte	Hechos del 5 al 9 de octubre de 2026; corte al cierre del día 9	Recepciones del mismo periodo; corte al cierre del día 9
Numerador	6 préstamos dentro de 10 minutos	4 devoluciones con soporte válido
Denominador	8 préstamos evaluables	5 devoluciones registradas
Resultado y meta ilustrativa	75 % frente a 90 %	80 % frente a 100 %
Responsable de revisión	Coordinador de circulación	Responsable autorizado de circulación
Frecuencia propuesta	Revisar casos diariamente y consolidar por semana	Revisar casos diariamente y consolidar por semana
Acción inicial	Investigar P007 y P008	Regularizar D03 con evidencia verificable

Antes de comparar semanas hay que conservar las mismas definiciones de periodo, corte, elegibilidad y plazo. También debe mostrarse la última actualización del dato. Si se incorporan operaciones después del corte, conserva la versión del resultado o identifica la revisión. 

Datos faltantes y ausencia de actividad 

Si en otro periodo hay diez préstamos, pero dos carecen de hora del hecho, solo ocho pueden evaluarse temporalmente. Si seis de esos ocho son oportunos, se informa «75 % entre los ocho evaluables; dos sin evaluar por datos faltantes». La cobertura de evaluación sería (8 ÷ 10) × 100 = 80 %. Ambos porcentajes deben verse juntos para evitar una lectura incompleta. 

Si el periodo no tiene devoluciones, el denominador es cero. El resultado se muestra como «sin casos», acompañado de 0 devoluciones. No corresponde reemplazarlo por 0 % o 100 %. Si existen devoluciones pero falta revisar sus soportes, se informa ese trabajo pendiente; no se presenta como ausencia de actividad. 

Para profundizar en la revisión del dato antes de usarlo, consulta la guía de calidad de datos y controles verificables. 

7. Diseñar el prototipo y probarlo con una tarea realista 

El prototipo es una representación que permite explorar y revisar la solución antes de completarla. Puede comenzar con papel o una pantalla estática. Los prototipos de baja fidelidad facilitan probar ideas cuando todavía es sencillo cambiarlas (Gordon, 2021). 

El tablero de la biblioteca debe permitir pasar del resultado agregado al caso que requiere atención. Por eso necesita mostrar periodo, fecha de actualización, numerador, denominador, meta y registros excluidos, además de las excepciones correspondientes. 

Cómo comprobar si la pantalla ayuda a decidir 

En una prueba, plantea al responsable esta tarea: «Al cierre de la semana, identifica qué registros requieren revisión y explica qué comprobarías antes de corregirlos». Evita instrucciones como «haz clic en el botón de pendientes», porque revelarían el camino y dificultarían observar si la interfaz se entiende por sí misma. Los escenarios de usabilidad deben representar tareas realistas sin indicar cómo resolverlas (McCloskey, 2014). 

Observa si la persona encuentra P007, P008 y D03, distingue los dos indicadores y explica qué evidencia necesita. Registra dónde se confunde, si requiere ayuda y qué etiquetas interpreta incorrectamente. 

Aspecto de la prueba	Qué observar	Posible ajuste si falla
Comprensión del 75 %	Reconoce que se refiere a seis de ocho préstamos	Mostrar el conteo junto al porcentaje y precisar la etiqueta.
Localización de excepciones	Encuentra los dos préstamos tardíos	Hacer visible la lista y el vínculo al detalle.
Interpretación del soporte	Identifica D03 y busca evidencia de recepción	Separar estado operativo y estado de validación.
Reconocimiento del alcance	Entiende que los datos son simulados	Mantener visible la identificación de la maqueta.

Una tarea completada con ayuda no equivale a completarla de forma autónoma. Conserva esa distinción en el registro de la prueba. Si se cambia el diseño, repite las tareas afectadas para comprobar si la dificultad persiste. 

Probar la maqueta aporta evidencia sobre comprensión y navegación. Para demostrar una mejora operativa hacen falta una solución implementada, datos comparables y seguimiento, teniendo en cuenta otros cambios del servicio. 

Matriz para revisar la propuesta completa 

Esta matriz permite comprobar que lo diseñado responde al problema original y que existe una forma de verificarlo. 

Problema observado	Requisito o control propuesto	Datos e indicador	Prueba o revisión
D03 carece de soporte válido	RF01 exige vincular y validar evidencia antes de confirmar	ID_prestamo y soporte; 4 de 5 devoluciones con evidencia	PA01, PA02, PA03 y PA05; revisión de D03.
P007 y P008 se registraron tarde	Conservar hora del hecho y del registro; mostrar excepciones	Ambas marcas de tiempo; 6 de 8 préstamos oportunos	Comprobar cálculo y localizar ambos préstamos en el prototipo.
Riesgo de confirmación sin autorización	RN01 y RF02 limitan quién puede confirmar	Usuario, rol y trazas de la operación	PA04 con usuario sin permiso.
Riesgo de doble confirmación	Impedir una segunda devolución del mismo préstamo	ID_prestamo único en Devolución bajo este alcance	PA06 y revisión de registros guardados.

Errores frecuentes al formular la solución 

Elegir la herramienta antes de comprender la decisión. Un formulario puede digitalizar una ambigüedad y hacerla más rápida de repetir. Primero define qué debe comprobarse y quién puede actuar. 

Confundir campo diligenciado con evidencia válida. El texto «pendiente» llena una casilla, pero no prueba la recepción. La regla debe evaluar la correspondencia del soporte con la operación. 

Mostrar porcentajes sin conteos. Un 100 % con un solo caso y un 100 % con mil casos describen tamaños de población diferentes. Mostrar numerador y denominador ayuda a juzgar el resultado. 

Asignar metas por apariencia. El 90 % y el 100 % de este ejemplo son propuestas didácticas. En una organización se acuerdan según riesgo, compromisos de servicio, capacidad y línea base; una referencia educativa no los convierte en estándares universales. 

Confiar en el color para comunicar. Acompaña las señales con etiquetas como «tardío» o «sin soporte válido». Así el estado puede comprenderse sin depender exclusivamente del color. 

Tratar una buena prueba de maqueta como éxito operativo. La comprensión de la pantalla y la mejora del servicio son resultados diferentes y requieren evidencias distintas. 

Lista de comprobación antes de implementar 

• El problema está descrito con evidencia y las hipótesis pendientes están identificadas. 

• Cada necesidad señala un rol, información y decisión. 

• Los requisitos tienen criterios de aceptación y una prioridad justificada. 

• Los identificadores y relaciones respetan las reglas del proceso. 

• Los indicadores tienen fuente, periodo, corte, fórmula, unidad y responsable. 

• Se explican los datos faltantes y los denominadores iguales a cero. 

• El prototipo muestra excepciones y se ha probado con tareas realistas. 

• Existe un responsable de aprobar cambios y verificar resultados después de implementar. 

Aplicación en tu organización 

Elige una decisión que hoy cueste tomar por falta de información. Documenta un caso verificable, redacta el requisito correspondiente y define cómo comprobarías su cumplimiento. Después construye un prototipo pequeño que permita revisar esa decisión con quien realmente realiza el trabajo. 

Si necesitas acompañamiento para revisar tus reportes, definir indicadores o estructurar los requisitos de una solución de información, puedes consultar las opciones de asesoría en oscarcaita.com. El primer paso es precisar el proceso y la decisión que deseas mejorar. 

Referencias 

Gordon, K. (2021, 19 de diciembre). Paper prototyping: A cutout kit. Nielsen Norman Group. https://www.nngroup.com/articles/paper-prototyping-cutout-kit/ 

Government Digital Service. (s. f.). Measuring the success of your service. GOV.UK. https://www.gov.uk/service-manual/measuring-success/measuring-the-success-of-your-service 

International Requirements Engineering Board. (s. f.). CPRE online glossary. Recuperado el 15 de octubre de 2026, de https://cpre.ireb.org/en/downloads-and-resources/glossary 

McCloskey, M. (2014, 12 de enero). Turn user goals into task scenarios for usability testing. Nielsen Norman Group. https://www.nngroup.com/articles/task-scenarios-usability-testing/ 

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 

PostgreSQL Global Development Group. (s. f.). Constraints. PostgreSQL documentation. Recuperado el 15 de octubre de 2026, de https://www.postgresql.org/docs/current/ddl-constraints.html