En este artículo
Si dos sistemas exigen registrar el mismo hecho y luego discrepan, aclare primero qué evento captura cada uno, qué dato tiene autoridad y quién resuelve excepciones. Una compra puede mejorar la integración, pero no decide por sí sola si «entregado» significa despacho o recepción, ni quién aprueba una corrección. Mapee un caso de principio a fin, pruebe una regla de conciliación y observe si reduce discrepancias sin crear otra copia. Después podrá comparar cambio de proceso, integración y software nuevo con requisitos concretos. Este artículo se ocupa de la decisión organizacional sobre doble captura; una persona frente a dos registros incompatibles necesita una respuesta más inmediata para el caso que tiene hoy.
Una tercera pantalla puede heredar los dos conflictos
En una escena ficticia, una empresa registra solicitudes de equipo en una herramienta de atención y en una hoja de inventario. El área usuaria se queja de que el informe de entregas cambia según quién lo prepara. La dirección propone comprar una plataforma «que sea fuente única de verdad». En una revisión breve aparecen dos definiciones: atención marca «entregado» cuando pasa el paquete a transporte; inventario lo marca cuando recibe el acuse de la persona destinataria. Las pantallas no siempre discrepan por error; a veces cuentan eventos distintos con el mismo nombre.
La plataforma propuesta podría juntar ambos valores, pero alguien tendrá que decidir qué muestra como entrega confirmada. Si sólo sincroniza campos homónimos, quizá copie un despacho como recepción. Si obliga a las personas a capturar además en una tercera pantalla mientras se mantienen las dos anteriores, añadirá otra oportunidad de diferencia. Ninguna de esas conclusiones prueba que comprar tecnología sea mala idea. Demuestran que el requisito de compra todavía no está formulado.
El marco de calidad de datos del gobierno británico recomienda tratar problemas de calidad en su origen y no quedarse en soluciones temporales. Se dirige al sector público británico; no impone un proceso a esta empresa. Como analogía, obliga a mirar por qué se contradicen los registros antes de elegir el mecanismo que hará circular el dato más rápido. Automatizar una ambigüedad también puede hacerla más difícil de detectar.
El artículo publicado sobre costos del retrabajo antes de comprar una herramienta ayuda a valorar tiempo, esperas y carga de correcciones en términos generales. Aquí la decisión es más estrecha: reconciliar un hecho duplicado, asignar autoridad a sus campos y especificar qué tendría que hacer una solución tecnológica si al final se necesita.
Dibuje un caso completo, no un mapa de logos
Elija un caso reciente cuya discrepancia haya afectado un informe o una decisión. Trace cuándo se creó la solicitud, quién capturó el despacho, quién confirmó recepción, qué dato se copió, en qué corte y dónde apareció la diferencia. Incluya a las personas que realizan la captura, porque conocen pasos que el diagrama oficial quizá omite. No necesita exportar bases completas para entender un recorrido; puede usar identificadores autorizados y ejemplos anonimizados.
En el caso ficticio, atención recibe «enviado al transporte» el martes, inventario conserva «pendiente de acuse» el miércoles y un tablero interpreta ambos como «entregado». El error principal puede estar en la etiqueta del tablero. En otro caso, el acuse ya existe y nadie actualizó inventario; ahí podría fallar un paso de captura. En un tercero, la sincronización copia el valor antes de que esté completo. Una sola corrección técnica no resuelve por igual esos tres problemas.
Anote para cada dato su evento, fuente, responsable, hora del hecho, hora de captura y usos posteriores. La diferencia entre hora de evento y de sincronización evita concluir que el último archivo representa el último hecho. Registre además qué regla de negocio valida el dato. Una entrega confirmada quizá exige un acuse; un despacho quizá exige otra evidencia. Sin esa definición, el equipo discutirá qué pantalla se ve más moderna en lugar de qué hecho quiere conocer.
Pruebe el mapa con otra persona de la operación. Pídale que encuentre el punto donde nace el dato y que explique qué ocurriría si se corrige una recepción del día anterior. Si no puede hacerlo sin llamar a quien armó el tablero, falta documentación de flujo. El mapa debe ser lo bastante simple para orientar una decisión y lo bastante preciso para identificar dónde se puede introducir o reproducir la discrepancia.
Asigne autoridad por campo y uso, no por prestigio del sistema
La empresa puede necesitar varias fuentes autorizadas. Atención podría regir el estado de despacho; inventario, la recepción física; finanzas, el pago. Una plataforma puede presentar esos datos juntos sin convertirse en dueña de todos. Declare para cada campo qué significa, quién aprueba su definición, dónde se captura el hecho original y cómo se corrigen vistas derivadas. «El sistema A manda» es demasiado amplio si A copia identificadores o decisiones de B.
El modelo de propiedad de datos del gobierno británico distingue a quien responde por significado, calidad y decisiones sobre el dato de quienes administran su operación cotidiana. Es un modelo gubernamental británico, no un requisito privado universal. La distinción ayuda a no confundir permiso de edición con autoridad de definición. El equipo de TI puede implementar un flujo, pero no decidir por sí solo qué evento cuenta como recepción para una evaluación de servicio.
Nombre una persona o función para resolver diferencias entre fuentes, y otra para ejecutar correcciones según ese criterio. Si hay desacuerdo sobre el significado, la autoridad de dato debe decidir con quienes usan el resultado. Si el problema es una falla técnica, la persona custodio del sistema puede repararla con una regla aprobada. Si ambas cosas se mezclan, nadie sabrá a quién escalar. El objetivo no es crear puestos nuevos, sino hacer visibles facultades que ya afectan decisiones.
Publique una ficha breve de los campos críticos: nombre, definición, fuente de origen, consumidores, corte, regla de sincronización, excepción y dueño. Cuando un tablero agregue datos, debe indicar cuál versión y criterio usó. Un glosario enorme no compensa que «entregado» siga teniendo dos significados en la reunión donde se asignan recursos. Empiece por el dato que causa decisiones equivocadas y amplíe después según la evidencia.
Clasifique las discrepancias antes de elegir una cura
No todas las diferencias merecen la misma intervención. Una demora prevista de sincronización requiere mostrar corte y quizá esperar; una definición distinta requiere renombrar campos o vistas; un registro omitido requiere corregir con evidencia; una asociación equivocada de identidades requiere revisar cómo se empatan casos. Si se mezclan en el total «errores de datos», la organización puede comprar una herramienta que resuelva sólo una clase y dejar intactas las demás.
Tome una muestra acotada de discrepancias recientes y clasifíquelas con quienes capturan y consumen los datos. No publique porcentajes representativos si la muestra se eligió por conveniencia o sólo incluye incidentes reportados. Basta identificar patrones repetidos, consecuencias y dudas que quedan abiertas. Por ejemplo, si varios casos son diferencias esperadas durante un cierre, la solución quizá sea etiquetar estados y hora. Si son omisiones de captura, hace falta rediseñar el paso y su control.
El marco británico de calidad de datos entiende calidad según el uso y pide comunicar sus límites a quienes la consumen. En el informe de la empresa ficticia, no toda discrepancia afecta la misma decisión. Una diferencia de horas puede ser tolerable para planear rutas mañana y grave para afirmar hoy que una persona recibió equipo. La prioridad debe seguir el efecto de una lectura errónea, no sólo el número de filas que no coinciden.
Evite buscar culpables con una lista de excepciones. Una persona puede haber seguido correctamente el procedimiento que le dieron y producido un valor incompatible con otra definición. Pregunte qué información tenía al capturar, qué validación existía y qué haría alguien nuevo en la misma situación. Si la respuesta depende de recordar una excepción oral, el proceso necesita mejorar. Esa mirada no exonera errores concretos; permite separar corrección puntual de defecto de diseño.
Construya una ruta de conciliación para el trabajo de hoy
Antes de seleccionar tecnología, resuelva cómo actuar cuando dos registros se contradicen. La ruta mínima puede indicar: quién detecta y reporta, qué evidencia se consulta, quién decide el valor autorizado para ese uso, quién corrige la fuente, cómo se actualizan copias y a quién se avisa si el dato ya influyó en un informe. La secuencia debe caber en una página y poder usarse sin una reunión extraordinaria por cada caso.
La guía Worklife sobre dos registros contradictorios muestra la experiencia de quien recibe «actualiza ambos» sin saber cuál manda. Su nota de caso puede iniciar la conciliación; no debe obligarla a aprobar una regla de empresa. El proceso organizacional debería devolver una decisión clara: qué representa cada campo, quién editará, cuándo se reflejará y qué se informará mientras tanto. Si nadie puede responder, esa es una carencia de gobierno de datos que una nueva interfaz no suplirá sola.
Conserve trazabilidad proporcionada. Una incidencia puede guardar identificador de caso, campos y cortes, motivo confirmado, autorización y fecha de cierre. Los comprobantes sensibles deben quedar en su sistema autorizado, no copiados en un tablero abierto de incidencias. La revisión posterior necesita saber si el problema reapareció tras la corrección; no necesita crear un tercer expediente de cada persona. Distinguir referencia de duplicación es parte del diseño.
Haga una prueba con casos nuevos y antiguos. Si sólo se corrige hacia adelante, informe qué reportes históricos conservan la definición anterior. Si se modifica el pasado, registre qué valores cambiaron y qué decisión podría haber usado el dato viejo. Un flujo que «arregla» la pantalla presente pero no explica el efecto en informes descargados da una sensación falsa de cierre. El dueño del reporte debe decidir cómo comunicar una versión nueva.
Pruebe qué ocurre si dos áreas corrigen el mismo caso casi al mismo tiempo. Una persona podría actualizar inventario mientras otra cambia atención con una copia antigua; la siguiente sincronización tendría que elegir sin conocer el motivo. Defina quién inicia la corrección, cómo se señala «en revisión» y qué comprobación cierra la incidencia. El equipo técnico debe verificar cómo se comportan los sistemas actuales antes de prometer que el último cambio ganará. Un flujo seguro evita que la conciliación produzca una contradicción nueva.
La cola de excepciones necesita capacidad y fecha de respuesta. Si sólo se agregan casos pendientes a una lista que nadie revisa, el proceso será más visible pero no más confiable. Decida qué diferencias pueden esperar al cierre diario y cuáles bloquean una decisión inmediata; asigne un respaldo si la persona responsable se ausenta. Revise algunos casos cerrados para comprobar que la corrección llegó a los consumidores previstos. Esa revisión puede revelar un problema que la pantalla principal ya no muestra.
Descarte primero las alternativas de proceso de bajo alcance
A veces basta cambiar dónde nace un campo, dejar de copiar uno innecesario o mostrar dos etapas distintas en el tablero. Otra mejora puede ser definir un corte de sincronización y una cola de excepciones con responsable. Estas opciones no siempre son baratas ni simples; pueden exigir cambios de acceso, capacitación y soporte técnico. Pero sus requisitos son más claros después de trazar el caso que después de comparar catálogos de productos.
Pruebe un cambio pequeño en un segmento autorizado: por ejemplo, que una sede deje de volver a escribir la fecha de despacho si ya llega de atención, mientras conserva la confirmación de recepción como hecho propio. Compare si disminuyen las discrepancias y si el dato sigue sirviendo a los equipos. Si el cambio causa nuevas esperas o elimina un control legítimo, deténgalo y revise la hipótesis. No suprima una segunda captura sólo porque parece duplicada: puede representar una verificación diferente.
Si los sistemas existentes admiten una integración controlada, tecnología puede intervenir sin una compra nueva. El equipo técnico necesitará definiciones de campos, reglas de acceso, manejo de fallas y pruebas de lo que ocurre cuando un dato llega tarde o se corrige. Si no existe capacidad para mantener esa integración, la alternativa tampoco debe aprobarse por entusiasmo. La decisión compara formas de sostener el proceso, no sólo precio inicial ni cantidad de pantallas.
La Oficina de Rendición de Cuentas del gobierno estadounidense, GAO advierte en una guía de inversión pública en TI que un sistema nuevo puede automatizar procesos obsoletos e ineficientes. La guía se refiere a agencias federales estadounidenses; no dicta una prohibición de compra aquí. Da una pregunta útil: si se instala la herramienta mañana sin cambiar definiciones, responsables o correcciones, ¿qué conducta improductiva funcionará ahora a mayor velocidad?
Si la compra sigue en pie, escriba una prueba de aceptación real
Una solicitud a proveedores no debería decir sólo «queremos una fuente única de verdad». Defina qué campo nace dónde, qué eventos y estados deben seguir separados, cómo se actualizan consumidores, quién aprueba correcciones, qué ocurre cuando una integración falla y qué historial puede consultarse. Pida demostrar esos recorridos con datos ficticios que incluyan una recepción tardía y un caso contradictorio. Una presentación bonita del tablero no verifica que el proceso sea correcto.
Incluya necesidades de uso y protección. ¿Quién puede ver cada tipo de dato? ¿Quién puede corregir? ¿Cómo se audita un cambio? ¿Qué pasa si una sede no tiene conexión durante un turno? ¿Se puede exportar una nota de corte junto al informe? Las respuestas dependen del contexto real de la empresa. No prometa que una herramienta cumplirá por defecto con permisos o controles que nadie especificó. Los equipos responsables de seguridad y privacidad deben revisar el diseño que les corresponda.
La guía tecnológica del servicio público británico indica que la comprensión de usuarios, integraciones y estructura del sistema evoluciona al desarrollar un servicio. Su ámbito es gobierno digital británico. Para esta decisión, recuerda que la compra debe partir de necesidades observadas y dejar espacio a cambios, no congelar una arquitectura a partir de un eslogan. Si el proceso aún no distingue despacho de recepción, el catálogo de funciones llegará antes que el requisito verdadero.
Acuerde aceptación por casos, no por una promesa de ahorro universal. «Cuando atención registra despacho, el tablero lo muestra sin marcar recepción; cuando llega acuse, inventario confirma; si falta, se ve pendiente con responsable». Añada un caso de corrección retroactiva y otro de identidad ambigua. Si el proveedor no puede demostrar el flujo con el alcance y los permisos requeridos, la decisión de compra debe reflejar ese límite. Si sí puede, aún falta planear migración, operación y quién mantendrá las definiciones.
Mida si la reconciliación mejora, sin inflar un ROI genérico
Antes de cambiar el proceso, registre cuántos casos necesitan aclaración manual, cuánto tardan en obtener una versión autorizada y qué decisiones se suspenden o corrigen por la discrepancia. Defina universo y periodo; una semana de cierre puede diferir de una normal. Observe también si las personas crearon hojas paralelas para sortear el problema. No las trate sólo como resistencia: pueden señalar que la fuente oficial no responde a una necesidad concreta.
Después de una prueba, mida el mismo flujo. Tal vez hay menos divergencias, pero aumentó el tiempo de confirmación porque todas pasan por una sola persona. Tal vez la captura se simplificó y la calidad del informe mejoró. Una cifra aislada de «horas ahorradas» no describe si el dato correcto llega a tiempo para la decisión. Este artículo no reemplaza el análisis más amplio de costos de retrabajo antes de invertir en otra herramienta; usa medidas para verificar si una ruta de conciliación concreta funciona.
Defina un umbral de revisión, no una promesa de perfección. Algunos registros diferirán durante una sincronización prevista. La meta puede ser que esas diferencias se etiqueten correctamente y que ninguna se presente como entrega confirmada antes del acuse. Una mejora que vuelve visible un conflicto antes oculto puede aumentar al principio el número de incidencias registradas; interprete ese cambio junto con el tiempo de resolución y el efecto en decisiones.
Si una solución falla, no responsabilice de inmediato a quien captura. Revise si los campos siguen ambiguos, si se respetó la regla de fuente, si la cola de excepciones tiene dueño y si los usuarios recibieron información suficiente. Un problema puede requerir entrenamiento, ajuste de proceso o capacidad técnica; no todos se resuelven con el mismo producto. Documente qué hipótesis se probó y qué evidencia la sostuvo o la contradijo.
Un contraejemplo: una herramienta nueva puede ser necesaria
Imagine que la empresa aclaró definiciones y autoridad, eliminó capturas redundantes y probó una conciliación manual con casos reales. Aun así, los sistemas existentes no pueden transmitir correcciones con un historial accesible ni sostener el volumen necesario sin duplicar trabajo. Una compra o construcción nueva puede estar justificada. Ahora el equipo sabe qué evento debe viajar, qué excepción se mostrará y cómo evaluará la solución. La tecnología responde a un requisito observado, no a la esperanza de que decida el proceso.
El caso contrario también es posible: la plataforma actual puede mostrar ambos estados si se configura con etiquetas correctas y se cambia quién registra la recepción. Comprar otra herramienta añadiría migración, permisos y mantenimiento sin resolver una falta técnica demostrada. La decisión puede ser «no comprar todavía» con fecha de revisión, y no una negativa definitiva a modernizar. Lo importante es explicar qué evidencia cambiaría esa conclusión.
Si dirección necesita escoger entre propuestas, separe requisitos obligatorios de preferencias. Resolver una corrección autorizada y conservar su historia puede ser obligatorio para el uso previsto; un diseño visual específico quizá sea negociable. No haga que la cantidad de funciones reemplace una prueba del flujo más difícil. El proveedor, el equipo interno y los usuarios deben mirar el mismo caso ficticio y acordar qué resultado cuenta como correcto antes de aprobar la entrega.
Un diagnóstico de doble captura no certifica todos los registros de la organización. Empiece por un flujo crítico y sus consumidores, conserve límites de muestra y anote las preguntas que requieren otra revisión. Si aparecen datos de salud, nómina o seguridad, incorpore a responsables competentes antes de integrar o compartir. La calidad de datos se evalúa en relación con el uso y las consecuencias; una plantilla universal de «sistema rector» sería tan engañosa como una compra universal.
Cierre la reunión con una decisión comprobable
La próxima reunión puede terminar con cuatro acuerdos: campo y evento que se estudiarán primero, persona con autoridad para definirlo, ruta de conciliación de casos abiertos y prueba corta para distinguir cambio de proceso de necesidad técnica. Añada fecha y criterio de revisión. Si todavía no se sabe qué sistema origina la diferencia, asigne esa investigación; no apruebe una compra a partir de dos pantallas discordantes sin un mapa del flujo.
En la escena ficticia, el acuerdo podría ser: «Inventario confirma recepción física; atención registra despacho. Durante dos cierres, el tablero mostrará ambos estados y una cola de acuses pendientes. Operaciones resolverá excepciones con evidencia; TI revisará si la integración existente puede transportar correcciones. Luego decidiremos si falta capacidad que justifique otra herramienta». No es una solución universal. Es una decisión suficientemente concreta para observar qué mejora y qué sigue fallando.
Si el piloto confirma que la duplicación era necesaria para dos controles distintos, manténgala con nombres y responsabilidades claros. Si demuestra que una captura es repetición sin valor, retírela con un plan de transición. Si descubre una limitación técnica real, compre o construya con requisitos probados. En todos los caminos, alguien debe seguir respondiendo por el significado y la corrección del dato. La plataforma puede transportar una decisión de negocio; no puede reemplazarla.
Elija hoy un campo que se captura dos veces y dibuje un caso desde el hecho original hasta el informe. Cuando una persona necesita resolver la contradicción inmediata, comparta la guía Worklife sobre cuál de dos registros actualizar. Para una evaluación económica más amplia de la compra, lea el artículo distinto sobre costos de retrabajo.
Que esta lectura no se quede como una pestaña abierta.
Enviamos ideas prácticas sobre psicología organizacional aplicada, liderazgo, clima, confianza, burnout y decisiones de talento. Si esta lectura sobre liderazgo y equipos te sirvió, el newsletter te ayuda a convertir interés en criterio de trabajo.
Sin ruido motivacional. Sin promesas mágicas. Solo lectura organizacional para RH, líderes y dirección.
Conceptos ligados a esta lectura.
Definiciones rápidas para aterrizar esta conversación en lenguaje de Recursos Humanos, psicología organizacional y desarrollo organizacional.
Contenido editorial institucional basado en psicología organizacional aplicada, desarrollo de liderazgo y experiencia práctica en Recursos Humanos.