Cómo relevar una integración antes de construirla

Pensemos en un pedido que entra por el ecommerce, se factura en el ERP y pasa al depósito. En el medio, alguien detecta que falta un dato de entrega y lo completa a mano. Si esa tarea no aparece en el relevamiento, la integración puede funcionar en las pruebas y dejar pedidos detenidos al entrar en operación.

Antes de discutir APIs y formatos, hay que seguir el recorrido del pedido y preguntar qué decisiones toman las personas que hoy intervienen. Esas respuestas definen qué debe hacer la integración y qué casos necesitan revisión humana.

Empezar por el proceso, no por la API

El primer paso es entender el recorrido completo de la operación tal como ocurre hoy, incluso si hoy es manual. Por ejemplo, para un pedido online:

• ¿Dónde se origina el pedido y qué datos tiene en ese momento?
• ¿Quién lo valida, lo factura, lo prepara y lo despacha?
• ¿En qué sistemas queda registrado cada paso?
• ¿Qué tareas hace hoy una persona que la integración va a reemplazar, y qué criterio aplica al hacerlas?

Este último punto es clave. Muchas veces una persona corrige datos, completa campos faltantes o decide casos dudosos sin que eso esté documentado en ningún lado. Si el relevamiento no lo detecta, la integración automatiza el camino feliz y deja sin resolver todo lo que antes se resolvía en silencio.

Definir quién es dueño de cada dato

Cuando dos sistemas comparten información, tiene que quedar claro cuál es la fuente de verdad de cada dato:

• Stock: ¿lo define el ERP, el sistema de depósito o el ecommerce?
• Precios y promociones: ¿se cargan en un sistema y se replican, o cada canal tiene los suyos?
• Datos de clientes: ¿quién puede modificarlos y cómo se propagan los cambios?
• Estado del pedido: ¿qué sistema informa que un pedido fue despachado o entregado?

Sin esta definición aparecen los problemas clásicos: dos sistemas que se pisan la información, cambios que se pierden porque otra sincronización los sobrescribió o diferencias de stock que nadie sabe explicar.

Mapear los datos y sus diferencias

Aunque dos sistemas manejen "el mismo" dato, rara vez lo representan igual. En el relevamiento conviene revisar:

• Identificadores: cómo se relaciona un producto, un cliente o una sucursal entre sistemas. Un SKU puede tener un código distinto en cada uno.
• Formatos y unidades: fechas, monedas, impuestos, unidades de medida, decimales.
• Campos obligatorios: qué exige el sistema destino que el origen no siempre tiene.
• Valores posibles: estados, tipos de documento, medios de pago o de envío, y cómo se traducen de un sistema a otro.

Este mapeo se convierte después en la especificación de las transformaciones y en la base para validar los datos antes de enviarlos.

Relevar reglas de negocio y escenarios alternativos

El flujo habitual no alcanza para definir la integración. También hay que decidir qué pasa cuando una operación se aparta de ese recorrido:

• Un pedido que se cancela después de facturado.
• Un producto que se vende sin stock porque la sincronización todavía no se actualizó.
• Una entrega parcial, un cambio de dirección o una devolución.
• Un cliente que no existe todavía en el sistema destino.

Para cada escenario hay que definir qué debería pasar: si la integración lo resuelve sola, si lo deja pendiente para revisión o si lo rechaza. Estas decisiones son de negocio, no técnicas, y conviene tomarlas con las áreas involucradas antes de construir.

Volúmenes, frecuencias y ventanas de tiempo

La misma integración se diseña distinto si procesa cien operaciones por día o cien por minuto. Algunas preguntas que definen la arquitectura:

• ¿Cuántas operaciones se procesan en un día normal y en un pico, como un evento de ventas o un cierre de mes?
• ¿La información tiene que viajar en tiempo real o alcanza con sincronizaciones periódicas?
• ¿Hay ventanas en las que un sistema no está disponible, como procesos nocturnos o mantenimientos?
• ¿Qué límites de uso tienen las APIs de los sistemas externos?

Con estas respuestas se decide si conviene una integración sincrónica, basada en eventos o por lotes, y si hace falta una cola intermedia para absorber picos.

Restricciones de los sistemas involucrados

No todos los sistemas ofrecen las mismas posibilidades. En el relevamiento revisamos qué mecanismos expone cada uno (APIs, webhooks, archivos, acceso a base de datos), qué documentación existe, cómo se gestionan las credenciales, si hay ambientes de prueba disponibles y quién es el interlocutor técnico de cada proveedor. Descubrir a mitad del proyecto que un sistema no tiene ambiente de pruebas, o que un cambio en su API requiere semanas de gestión, afecta directamente los plazos.

Acordar cómo se va a operar

Una integración en producción necesita responsables. Antes de construirla conviene definir:

• Quién recibe las alertas cuando algo falla y quién puede reprocesar una operación.
• Qué información necesita el equipo operativo para consultar el estado de un pedido sin depender del área técnica.
• Cómo se van a conciliar los datos entre sistemas y con qué frecuencia.

Estas definiciones son las que después se traducen en trazabilidad y monitoreo y en una estrategia de gestión de errores que tenga sentido para la operación real.

Qué debería quedar al terminar el relevamiento

1. Un diagrama del flujo de punta a punta, con los sistemas y áreas que intervienen.
2. La definición de la fuente de verdad de cada dato compartido.
3. El mapeo de campos, identificadores y valores entre sistemas.
4. La lista de escenarios alternativos con la respuesta acordada para cada uno.
5. Volúmenes esperados, frecuencias y restricciones técnicas de cada sistema.
6. Responsables de operación, alertas y reprocesamiento.

Con esta base, el equipo puede construir y probar también los casos que no siguen el recorrido habitual. Si la operación cambia, queda claro qué decisión hay que revisar y con quién.