Empieza por lo que el sistema permite
Ante un programa antiguo, evalúa primero qué vías de acceso admite, de mejor a peor: una API documentada, una exportación programada de datos, informes generados a horas fijas o, como último recurso, la lectura de su pantalla. Algunos sistemas no admiten ninguna vía viable. El orden importa: cada nivel que bajas añade fragilidad.
Antes de diseñar nada, responde con hechos: ¿tiene API y quién autoriza su uso? ¿Qué exportaciones admite y con qué frecuencia? ¿Hay documentación o una persona que lo conozca? Sin estas respuestas, cualquier propuesta es una apuesta.
API frente a exportación frente a pantalla
La API es la vía sólida: acceso definido, permisos por operación y errores claros. Si tu sistema la tiene, úsala. La exportación (CSV, Excel, carpeta compartida) es honesta y suficiente para muchos casos: un agente o una automatización consulta la copia actualizada sin tocar el sistema original.
La automatización por pantalla (abrir el programa y simular clics) puede ser frágil: los cambios visuales pueden romperla y es difícil de auditar. Antes de plantearla hay que revisar licencias, autorizaciones y modos de fallo con la persona responsable. Solo se plantea como último recurso, con sus riesgos explicados y una persona supervisando.
- API autorizada: conexión directa, permisos y errores claros
- Exportación programada: copia actualizada sin tocar el original
- Informes a horas fijas: suficiente cuando el dato no es urgente
- Pantalla: último recurso, frágil y siempre supervisado
Permisos limitados por fases
Conecta por fases y con el menor permiso posible. Primera fase: solo lectura (consultar stock, buscar clientes, leer estados). Segunda fase: preparar acciones que una persona confirma. Solo después, y si el registro lo justifica, ejecutar acciones acotadas de bajo riesgo.
Cada fase necesita su propio periodo de observación: qué se consultó, qué falló y qué se escaló. Sin registro no hay mejora posible, y sin fases no sabes qué rompió qué.
La validación humana no se negocia
Los datos heredados suelen tener duplicados, formatos mezclados y campos con significados distintos según quién los introdujo. Ningún agente debería actuar sobre ellos sin validaciones: completitud, rangos razonables y avisos ante lo inesperado.
Define desde el diseño qué requiere aprobación humana: importes, bajas, comunicaciones a clientes y cualquier cambio irreversible. Lo que el sistema mueve solo debe ser reversible y quedar registrado.
Cuándo no conectar
Hay sistemas que no admiten conexión fiable: sin API, sin exportación ordenada y con pantallas inestables. En ese caso, la recomendación honesta es no invertir en la conexión y buscar alternativas: convivencia ordenada, migración parcial de datos o sustitución del módulo concreto.
Si una propuesta promete conectar cualquier sistema sin haberlo evaluado, pide la evaluación por escrito antes de firmar nada.