El impuesto invisible de copiar datos entre sistemas

En 60 segundos: Cada vez que una persona vuelve a escribir un cliente, pedido, pago o despacho en otro sistema, la empresa paga en tiempo, correcciones, espera y pérdida de trazabilidad. Para medir ese impuesto, seguí un dato desde su origen hasta el reporte final y contá cada captura, transformación, excepción y demora. Calculá el coste con volumen y tiempos observados, sin usar porcentajes de ahorro ajenos. Después elegí el mecanismo más pequeño que resuelva la causa: sincronización para campos estables, eventos para cambios que disparan trabajo, automatización de escritorio para una interfaz heredada y limpieza para inconsistencias ya creadas. El primer piloto debe mover un solo objeto entre dos sistemas, en una dirección, con cola de excepciones y log.

En un proceso administrativo es fácil confundir movimiento con avance. Ventas registra un pedido, almacén copia los datos para preparar el despacho, cobranzas vuelve a escribir el saldo, contabilidad transforma una exportación y gerencia arma el reporte en Excel. Teams queda como historial informal de aclaraciones.

Cada paso puede parecer breve. Juntos forman un coste operativo que rara vez aparece en una partida contable. Podemos llamarlo impuesto de recaptura: el trabajo necesario para volver a ingresar, convertir, comprobar y reconciliar un dato que ya existía.

Qué incluye el impuesto de recaptura

El cálculo comienza con el tiempo de tecleo y añade:

• la búsqueda del registro correcto y la conversión de formatos;
• la revisión de campos obligatorios antes de continuar;
• la corrección de duplicados, importes, fechas o direcciones;
• la espera mientras otra persona confirma qué versión es válida;
• la reconstrucción de quién cambió el dato y por qué;
• el trabajo atrasado cuando un pedido, cobro o reporte queda detenido.

La pérdida de trazabilidad merece una línea propia. Si una cifra cambia entre un mensaje de Teams, una hoja de Excel y el sistema contable, puede resultar imposible saber cuál era el valor aprobado en cada momento. Además del tiempo dedicado a copiar, la empresa pierde capacidad para explicar una decisión y recuperar el proceso después de un error.

Seguí un dato de punta a punta

Elegí un objeto concreto, como un pedido aprobado, y reconstruí su recorrido con registros reales. No empieces por el diagrama ideal del procedimiento. Observá qué hace el equipo hoy.

Etapa	Dato que entra	Trabajo manual	Dato que sale	Evidencia que conviene guardar
Venta	Cliente, productos, cantidades, precio y dirección	Completar campos y confirmar condiciones	Pedido aprobado	ID de oportunidad, versión y aprobador
Pedido	Datos comerciales aprobados	Recapturar códigos y adaptar formato	Orden en el sistema operativo	ID de origen y de destino
Pago	Factura, vencimiento y referencia bancaria	Buscar el documento y aplicar el cobro	Saldo actualizado	ID de transacción y responsable
Despacho	Orden liberada y dirección	Volver a validar dirección, stock y transportista	Envío preparado	Hora, estado y número de guía
Reporte	Estados de ventas, cobro y despacho	Exportar, convertir, unir y corregir	Hoja o informe gerencial	Fecha de corte, fuentes y filtros

Para cada transición, anotá dónde se origina el dato, quién lo modifica, qué identificador conserva y qué regla decide que puede avanzar. Registrá también el canal de excepción. Un mensaje en Teams puede resolver el caso de hoy, pero no sustituye un estado trazable si la decisión nunca vuelve al sistema correspondiente.

El mapa suele revelar dos problemas distintos. En uno, el mismo dato válido se copia porque los sistemas no se comunican. En el otro, nadie ha definido qué sistema manda o qué significa el campo. El primer caso puede resolverse con integración. El segundo necesita una decisión de datos antes de automatizar.

Una calculadora con tus propios datos

Medí un periodo representativo y completá esta tabla. Si todavía no conocés un valor, marcalo como supuesto. No lo reemplaces con un benchmark externo.

Variable	Cómo obtenerla	Tipo
V = casos por periodo	Conteo de pedidos, pagos o registros que atraviesan el paso	Dato observado
M = minutos de recaptura por caso	Cronometraje de una muestra, incluyendo búsqueda y validación	Dato observado
R = proporción de casos corregidos	Casos que requieren corrección ÷ casos observados	Dato observado
C = minutos por corrección	Tiempo desde que se detecta el error hasta que queda resuelto	Dato observado
H = coste interno por hora	Coste que la empresa decida usar para ese rol	Dato interno o supuesto documentado
D = casos demorados por el traspaso	Casos cuya espera puede atribuirse a esta transición	Dato observado
K = coste por caso demorado	Penalidad, trabajo adicional o coste financiero demostrable	Dato interno; usá 0 si no puede sostenerse

La estimación para el periodo es:

horas de recaptura = (V × M) ÷ 60
horas de corrección = (V × R × C) ÷ 60
coste operativo = (horas de recaptura + horas de corrección) × H
coste de demora = D × K
impuesto de recaptura estimado = coste operativo + coste de demora

Presentá el resultado como un rango si los tiempos varían mucho. Mantené tres categorías visibles:

• Hechos: conteos, tiempos y errores extraídos del periodo observado.
• Supuestos: coste por hora, estacionalidad o una atribución todavía no validada.
• Pendiente de medir: demoras sin causa registrada, correcciones hechas fuera del sistema o casos resueltos por chat.

Esta separación evita que una estimación se convierta en una promesa de ahorro. La integración también tendrá coste de construcción, licencias, soporte y atención de excepciones. La decisión compara el coste actual con el coste total de operar la solución, además del riesgo que reduce.

Qué solución corresponde a cada causa

Enfoque	Usalo cuando	Qué tenés que definir	Límite principal
Sincronización	Dos sistemas necesitan compartir un campo estable o una referencia	Sistema dueño, dirección, frecuencia y regla de conflicto	Una sincronización bidireccional mal definida crea versiones enfrentadas
Integración por eventos	Un cambio confirmado debe iniciar trabajo en otro sistema	Evento, esquema, identificador, reintentos y cola de errores	La consistencia puede ser eventual y exige observabilidad
Automatización de escritorio	La aplicación heredada no ofrece una API o conector viable	Máquina, sesión, selectores, credenciales y recuperación	Los cambios de interfaz pueden romper el flujo
Limpieza posterior	Ya existen duplicados, formatos incompatibles o datos incompletos	Regla de coincidencia, revisión humana y fuente que conserva el resultado	Corrige el inventario de errores, pero no elimina la causa que los genera

La documentación de Microsoft muestra dos capas útiles para esta decisión. Un conector personalizado envuelve una API REST o SOAP y expone acciones y disparadores consistentes. Los flujos de escritorio pueden interactuar con aplicaciones heredadas mediante elementos de interfaz, imágenes o coordenadas. La guía de resolución de fallos desatendidos documenta que los selectores pueden verse afectados por actualizaciones de la aplicación o cambios de interfaz. El equipo todavía debe evaluar permisos, licencias y soporte de su entorno.

Para flujos que reaccionan a un pedido aprobado, un pago aplicado o un despacho confirmado, la arquitectura orientada a eventos de Azure describe productores, consumidores y canales de eventos. La misma guía advierte sobre consistencia eventual, entrega, orden y manejo de errores. Un evento reduce la espera por lotes; no elimina la necesidad de reconciliar estados.

La automatización de escritorio puede ser una transición razonable para una aplicación sin API. Tratala como una integración operada: necesita alertas, una cuenta controlada y pruebas después de cambios de pantalla. Si la interfaz permite exportar pero el equipo debe convertir el archivo cada día, revisá primero si un conector, una importación estable o una API evita esa dependencia.

Los datos maestros van primero

Supongamos que ventas identifica a un cliente por email, el sistema operativo usa un código interno y contabilidad tiene dos fichas con nombres parecidos. Una automatización rápida puede copiar el pedido con mayor velocidad y crear el duplicado antes de que alguien lo vea.

Antes de sincronizar clientes, productos, monedas o direcciones, definí:

• el sistema dueño de cada atributo;
• el identificador estable que viaja entre sistemas;
• quién resuelve una coincidencia dudosa;
• qué cambios requieren aprobación;
• cómo se conserva el valor anterior y la causa del cambio.

La documentación de Microsoft sobre detección y combinación de duplicados en Dataverse confirma que la entrada manual y las importaciones pueden introducir registros repetidos. Las reglas ayudan a encontrarlos, pero las coincidencias y fusiones sensibles necesitan criterios acordados. Automatizar antes de acordarlos amplifica una inconsistencia existente.

Cuándo añadir un agente

Una integración mueve datos definidos. Un agente resulta útil cuando el paso incluye información no estructurada o una decisión que una persona debe revisar: leer una nota de Teams, extraer una referencia de un comprobante, explicar por qué un caso cayó en la cola o preparar el resumen gerencial.

El agente no debería decidir qué saldo es oficial ni aplicar un pago a partir de una inferencia. Puede proponer una coincidencia, reunir evidencia y redactar el siguiente paso. Las reglas deterministas validan importes, IDs, estados permitidos y permisos antes de cualquier escritura.

Si el objetivo es responder preguntas de dirección a partir de ventas y cobranzas, el diseño del asistente gerencial conectado al ERP muestra cómo separar fuentes, recomendaciones y acciones. Para decidir entre conectores, automatización de escritorio y código, consultá la guía de Power Automate frente a desarrollo a medida.

Un piloto que se pueda auditar

Empezá con el objeto pedido aprobado, desde el sistema comercial hacia el sistema operativo. Una sola dirección evita que dos aplicaciones compitan por el mismo campo.

1. El sistema comercial publica o expone pedidos que cumplen una condición de aprobación documentada.
2. La integración valida ID de cliente, líneas, cantidades, moneda y dirección.
3. Si todos los campos son válidos, crea el pedido una vez y guarda ambos identificadores.
4. Si falta un dato o hay una coincidencia dudosa, envía el caso a una cola de excepciones con responsable y motivo.
5. El log registra ID de correlación, origen, destino, versión, hora, resultado y actor técnico.
6. Una conciliación compara los pedidos aprobados con los creados y detecta omisiones o duplicados.

Durante el piloto, medí cobertura, tiempo manual restante, correcciones, antigüedad de la cola y casos demorados. Probá reintentos, eventos repetidos, datos incompletos y caída del destino. Solo después compará el impuesto de recaptura observado con el coste de operar la integración y decidí si conviene ampliar el alcance.