El ecommerce envía los pedidos al ERP. La conexión está activa, las peticiones reciben respuesta y los registros aparecen en el sistema de destino. Si se revisa únicamente la parte técnica, la integración funciona.
Sin embargo, antes de que el pedido pueda procesarse, una persona descarga un Excel, comprueba las referencias de producto, corrige algunos códigos, compara los importes y escribe a otro departamento cuando encuentra una dirección incompleta. Después vuelve al ERP, modifica los datos y marca manualmente el pedido para que continúe.
Cuando algo falla, la incidencia se resuelve por correo. Si el mismo pedido entra dos veces, alguien elimina el duplicado. Si no aparece en el ERP, se consulta el ecommerce, la pasarela de pago y una hoja compartida hasta descubrir en qué punto se perdió. Al final del día, el proceso sale adelante porque varias personas conocen sus excepciones y saben cómo compensar lo que la integración no resuelve.
Desde el punto de vista del negocio, esa integración no ha automatizado el proceso. Ha automatizado el tramo más visible y ha dejado el resto de la operación sostenida por comprobaciones manuales, conocimiento informal y correcciones difíciles de medir.
Una integración no puede evaluarse únicamente preguntando si transmite datos. Hay que comprobar si el proceso completo termina correctamente, si los errores se detectan, si las excepciones tienen un tratamiento definido y si la empresa puede saber qué ha ocurrido sin reconstruir cada operación.
Éxito técnico y éxito operativo no significan lo mismo
El éxito técnico responde a preguntas necesarias: ¿puede el ecommerce conectarse con el ERP?, ¿se autentican ambos sistemas?, ¿se envía la información con el formato esperado?, ¿responde la API?, ¿se crea el registro de destino?
El éxito operativo plantea preguntas diferentes: ¿puede el pedido continuar sin intervención innecesaria?, ¿los datos que llegan sirven para facturar, preparar el envío o prestar el servicio?, ¿se detectan los errores antes de afectar al cliente?, ¿puede el equipo resolver una excepción sin alterar otros registros?, ¿coinciden finalmente ambos sistemas?
Una integración puede superar todas las pruebas técnicas y fallar en estas preguntas. El pedido llega al ERP, pero con una referencia que no existe. El cliente paga correctamente, pero el estado del pago no se actualiza. El stock se descuenta en un sistema y no en otro. El registro se crea, aunque le falta un dato necesario para que el siguiente departamento trabaje.
En estos casos, el intercambio técnico se ha completado, pero el resultado de negocio no. La integración ha movido información y también ha trasladado el problema al siguiente punto del proceso.
El proceso real suele ser más largo que la conexión entre dos herramientas
Cuando se plantea una integración, es habitual describirla como una línea entre dos sistemas: ecommerce y ERP, CRM y facturación, formulario y plataforma comercial. Esa representación ayuda a entender la arquitectura, pero resulta insuficiente para diseñar la operación.
Un pedido, por ejemplo, puede empezar en el ecommerce y pasar por la pasarela de pago, la validación fiscal, el ERP, la gestión de stock, la preparación logística, la facturación, las comunicaciones al cliente y la analítica. También puede activar procesos distintos según el país, el tipo de producto, la forma de pago o la disponibilidad.
Entre esos pasos aparecen decisiones y excepciones que una flecha en un diagrama no muestra. ¿Qué ocurre si el pago se autoriza, pero el ERP no acepta el pedido? ¿Qué sistema conserva la referencia principal? ¿Puede volver a enviarse sin cobrar ni reservar stock dos veces? ¿Quién decide si un dato incompleto debe detener el proceso o puede corregirse después?
Diseñar la integración requiere seguir el proceso desde su evento inicial hasta el resultado que la empresa necesita. El objetivo no es lograr que dos aplicaciones hablen entre sí. Es conseguir que la operación avance de forma fiable entre todos los sistemas, decisiones y equipos implicados.
La intervención humana no siempre es el problema
No todos los procesos deben funcionar sin participación humana. Hay pedidos que requieren una revisión comercial, operaciones que necesitan aprobación o excepciones que no conviene resolver automáticamente. La intervención aporta valor cuando implica criterio, responsabilidad o una decisión que el sistema no debería tomar por sí solo.
El problema aparece cuando una persona actúa como traductora permanente entre herramientas. Copia datos, corrige formatos, comprueba que dos cifras coinciden o recuerda qué hacer con cada tipo de error. Su participación no existe porque el negocio necesite una decisión, sino porque la integración no conserva suficiente contexto o no gestiona las condiciones reales del proceso.
Conviene separar tres tipos de intervención:
- Decisiones necesarias: revisiones, aprobaciones o valoraciones que requieren criterio humano.
- Excepciones controladas: casos poco frecuentes que el sistema identifica, registra y dirige a la persona responsable con la información necesaria.
- Trabajo compensatorio: tareas repetidas que el equipo realiza para corregir, completar o verificar lo que la integración debería haber gestionado.
Eliminar toda intervención humana puede ser un objetivo equivocado. Reducir el trabajo compensatorio y hacer visibles las excepciones suele ser mucho más útil.
La trazabilidad debe permitir seguir cada operación
Cuando un cliente pregunta por un pedido que no aparece, la empresa debería poder localizarlo mediante un identificador común y conocer su recorrido. Qué sistema lo recibió, qué datos se enviaron, qué respuesta devolvió el destino, qué transformaciones se aplicaron y en qué estado se encuentra.
Un registro técnico que indica «error 400» puede ayudar a una persona desarrolladora, pero no siempre permite a operaciones saber qué pedido está afectado o qué debe hacer. Del mismo modo, guardar únicamente el mensaje «pedido enviado correctamente» no demuestra que el proceso posterior haya terminado.
La trazabilidad útil conecta la información técnica con la realidad operativa. Debe permitir responder, al menos, a estas preguntas:
- ¿Qué operación concreta estamos siguiendo?
- ¿En qué sistema se originó y qué identificadores tiene en los demás?
- ¿Qué pasos se han completado y cuál está pendiente?
- ¿Qué datos se enviaron y qué respuesta se recibió?
- ¿Se produjo un error, un reintento o una intervención manual?
- ¿Quién es responsable de la siguiente acción?
Sin esa conexión, investigar una incidencia obliga a consultar varias plataformas, buscar correos y comparar datos a mano. La empresa termina utilizando tiempo operativo para reconstruir una historia que el sistema debería conservar.
Los errores forman parte del diseño de una integración
Una integración fiable no se diseña suponiendo que todos los sistemas responderán siempre a tiempo y que todos los datos serán válidos. Las API pueden dejar de estar disponibles, las credenciales caducan, un proveedor modifica una condición, un campo obligatorio llega vacío o una respuesta tarda más de lo previsto.
La cuestión relevante es qué sucede después. El sistema puede reintentar la operación, dejarla en una cola, detener el proceso, avisar a una persona o aplicar una alternativa controlada. La decisión depende del tipo de error y del impacto que tendría repetir o abandonar la acción.
No debe tratarse igual un fallo temporal de conexión que una referencia de producto inexistente. El primero quizá pueda resolverse con un reintento automático. El segundo necesita corregir un dato maestro o decidir cómo debe mapearse el producto. Repetirlo cien veces no va a convertir la referencia en válida y solo añadirá ruido.
También hay errores que no detienen técnicamente la integración. Un pedido puede crearse con un importe incorrecto, asignarse al cliente equivocado o quedar preparado para envío sin que el stock se haya reservado. Estos fallos son más peligrosos porque el proceso parece haber terminado.
Por eso las validaciones deben comprobar el significado de la operación además de su transmisión. Una respuesta correcta de la API confirma que el sistema ha aceptado una petición. No confirma por sí sola que el resultado sea coherente con el negocio.
Reintentar una operación puede crear duplicados
Cuando una petición no recibe respuesta, el sistema de origen puede desconocer si el destino llegó a procesarla. Si vuelve a enviarla, existe la posibilidad de crear dos pedidos, emitir dos facturas, reservar dos veces el stock o iniciar dos entregas.
Resolverlo exige diseñar la operación para que pueda reconocerse aunque se repita. El sistema de destino necesita identificar que ya recibió esa solicitud o aplicar una regla que impida ejecutar dos veces la misma acción. También conviene registrar los reintentos para distinguir una recuperación automática de un nuevo evento real.
Los duplicados no siempre son idénticos. Una persona puede corregir un dato y volver a enviar el pedido, generando dos registros ligeramente diferentes que el sistema ya no relaciona. O un proceso manual puede introducir en el ERP una operación que horas después vuelve a llegar por la integración.
Por eso no basta con buscar registros iguales. Hay que definir qué hace única a una operación, qué sistema genera su identificador y cómo se coordinan las correcciones manuales con los reintentos automáticos.
La reconciliación comprueba que ambos lados siguen contando la misma historia
Aunque cada transmisión parezca funcionar, con el tiempo pueden aparecer diferencias entre sistemas. Pedidos presentes en el ecommerce que no llegaron al ERP, pagos confirmados que continúan pendientes, devoluciones procesadas en un lado y abiertas en el otro, o cambios de stock que nunca se propagaron.
La reconciliación compara periódicamente los resultados que deberían coincidir. No se limita a esperar una alerta, sino que comprueba de forma activa que las operaciones completadas en un sistema tienen su equivalente correcto en los demás.
Puede realizarse en tiempo real, mediante revisiones programadas o combinando ambos enfoques. Lo importante es definir qué se compara, con qué frecuencia, qué diferencias son aceptables y quién debe resolver las que requieren intervención.
Una integración sin reconciliación puede acumular errores silenciosos durante semanas. El equipo los descubre cuando un cliente reclama, cuando contabilidad cierra el periodo o cuando el stock físico deja de coincidir con el disponible. Para entonces, investigar el origen resulta más costoso porque hay muchas más operaciones que revisar.
Los datos maestros suelen concentrar una parte importante del problema
En muchos proyectos, el fallo no está en el mecanismo de conexión, sino en la falta de acuerdo sobre los datos. El ecommerce utiliza una referencia, el ERP otra y el almacén conoce el producto por una tercera. Los nombres de clientes varían, las direcciones no siguen el mismo formato y cada sistema aplica reglas distintas a impuestos, descuentos o estados.
La solución provisional suele ser una tabla de equivalencias en Excel. Puede resultar útil durante una migración o una fase controlada, pero se convierte en un riesgo cuando nadie sabe quién debe actualizarla, qué versión es válida o qué ocurre si aparece una referencia nueva.
Antes de automatizar el intercambio, hay que decidir qué sistema es la fuente de verdad para cada dato, cómo se crean las nuevas entidades, quién aprueba los cambios y cómo se distribuyen al resto de las herramientas. También hay que definir qué hacer con la información histórica o incompleta.
Una integración no corrige por sí sola la calidad del dato. Si conecta sistemas con criterios contradictorios, puede distribuir esas contradicciones con mayor rapidez.
Cada excepción necesita un responsable operativo
Una alerta sin responsable solo traslada el problema. Puede existir un registro detallado, un correo automático y un panel lleno de incidencias, pero si nadie sabe quién debe revisar cada tipo de error, el proceso continúa dependiendo de que alguien lo descubra por casualidad.
El ownership operativo consiste en asignar responsabilidad sobre el resultado. Para cada tramo crítico debe estar claro quién vigila el proceso, quién actúa ante una excepción, cuándo debe escalarse y quién puede decidir sobre los datos o las reglas del negocio.
La responsabilidad no tiene que recaer siempre en tecnología. Un error de conexión puede requerir una actuación técnica, mientras que una referencia desconocida puede corresponder a catálogo y una condición fiscal a administración. El sistema debe llevar cada excepción al equipo capaz de resolverla y proporcionar el contexto necesario.
También conviene diferenciar quién resuelve una incidencia concreta de quién decide que el mismo problema no debería repetirse. Si el equipo corrige manualmente veinte veces la misma excepción sin que nadie revise su causa, la operación sigue funcionando a costa de normalizar el fallo.
Qué conviene medir para saber si la integración funciona de verdad
Contar peticiones correctas y fallidas ofrece una visión parcial. Una integración puede registrar un porcentaje elevado de respuestas correctas y, aun así, generar mucho trabajo manual o errores posteriores.
Para evaluar su impacto operativo, conviene observar indicadores como:
- Operaciones que completan el proceso sin intervención.
- Excepciones por tipo, sistema y causa.
- Tiempo que permanece cada operación en estado pendiente.
- Reintentos realizados y resultado final.
- Duplicados detectados o eliminados manualmente.
- Diferencias encontradas durante la reconciliación.
- Horas dedicadas a comprobar, corregir o volver a introducir datos.
- Incidencias descubiertas por una alerta frente a las comunicadas por un cliente o usuario.
Estas métricas permiten distinguir un problema ocasional de una debilidad estructural. También ayudan a priorizar mejoras: quizá no sea necesario reconstruir toda la integración, pero sí corregir un mapeo, añadir trazabilidad, controlar los reintentos o asignar un responsable a una excepción recurrente.
Cómo revisar una integración que aparentemente funciona
La revisión debe seguir operaciones reales de principio a fin. Conviene seleccionar casos normales, excepciones conocidas y situaciones en las que uno de los sistemas no responda como se espera. Después hay que observar qué ocurre sin completar mentalmente los huecos con «esto normalmente lo resuelve alguien».
Un análisis inicial puede organizarse alrededor de seis áreas:
- Recorrido completo: desde el evento que inicia el proceso hasta el resultado que necesita el negocio.
- Trazabilidad: identificadores, estados, registros y capacidad para reconstruir cada operación.
- Gestión de errores: clasificación, reintentos, alertas, escalado y recuperación.
- Consistencia: duplicidades, reconciliación y correspondencia entre datos maestros.
- Intervención humana: tareas manuales, motivo por el que existen y conocimiento necesario para realizarlas.
- Responsabilidad: personas o equipos que supervisan, corrigen y mejoran el proceso.
El objetivo de esta revisión es identificar dónde se desplaza el riesgo. A veces estará en una conexión frágil. Otras veces aparecerá en una hoja de cálculo que se ha convertido en una pieza del sistema sin ser tratada como tal, en una bandeja de entrada utilizada como cola de incidencias o en una persona que reconcilia todos los días información que debería coincidir.
Una buena integración reduce trabajo y también incertidumbre
La automatización aporta valor cuando permite que el proceso avance, deja constancia de lo ocurrido y dirige las excepciones hacia una resolución clara. La empresa puede saber qué está funcionando, qué está pendiente y qué necesita atención sin revisar manualmente cada operación.
Eso no significa construir una arquitectura desproporcionada ni eliminar cualquier hoja de cálculo. Significa diseñar de acuerdo con la importancia del proceso y hacer visibles las dependencias que hoy sostiene el equipo de forma informal.
En Pibeca diseñamos e implementamos integraciones y automatizaciones de sistemas críticos teniendo en cuenta el proceso completo, los datos, las excepciones y la operación posterior. En proyectos como nuestra integración de Salesforce para ventas y servicio técnico, la trazabilidad entre áreas y sistemas forma parte de la solución desde su arquitectura.
Si tu integración transmite datos, pero el equipo sigue descargando archivos, corrigiendo registros o investigando pedidos uno a uno, podemos revisar dónde se está desplazando el trabajo y el riesgo.
La pregunta útil no es únicamente si la integración está activa. Es si la operación puede confiar en ella sin necesitar que varias personas vigilen constantemente lo que ocurre entre los sistemas.
Preguntas frecuentes sobre integraciones de sistemas
¿Cómo puede una integración funcionar técnicamente y fallar en la operación?
Puede enviar y recibir datos según lo previsto, pero producir información incompleta, duplicada o difícil de utilizar en el siguiente paso. También puede depender de correcciones manuales que no aparecen en las métricas técnicas. Para evaluar su funcionamiento hay que revisar el resultado completo del proceso y el trabajo que continúa realizando el equipo.
¿Es un problema que una integración necesite intervención humana?
No necesariamente. Algunas operaciones requieren aprobación, criterio o revisión. El problema aparece cuando la persona se limita a copiar información, corregir formatos, comparar sistemas o compensar errores repetidos. La intervención debería aportar una decisión o resolver una excepción identificada, no actuar como conexión permanente entre herramientas.
¿Qué diferencia hay entre monitorización y reconciliación?
La monitorización observa el funcionamiento del sistema y genera señales ante errores, tiempos de respuesta o estados anómalos. La reconciliación compara los resultados entre sistemas para comprobar que ambos contienen operaciones coherentes. Una integración puede no generar errores técnicos y, aun así, necesitar reconciliación para detectar pedidos, pagos o cambios que no coinciden.
¿Cómo se evitan los pedidos o registros duplicados?
Hay que definir un identificador estable para cada operación y diseñar las acciones para reconocer solicitudes ya procesadas. También se deben coordinar los reintentos automáticos con las correcciones manuales. Buscar registros exactamente iguales no siempre es suficiente, porque una misma operación puede volver a enviarse con pequeñas modificaciones.
¿Qué debe ocurrir cuando uno de los sistemas no está disponible?
Depende del proceso y del tipo de operación. Puede ser adecuado reintentar, conservar la solicitud en una cola, detener temporalmente el flujo o avisar a una persona. La decisión debe impedir la pérdida de información y evitar que la misma acción se ejecute varias veces cuando el sistema vuelva a estar disponible.
¿Hace falta reconstruir una integración que genera demasiado trabajo manual?
No siempre. Primero conviene localizar la causa del trabajo: falta de trazabilidad, datos maestros inconsistentes, excepciones sin tratar, reintentos mal diseñados o responsabilidades poco claras. Algunas integraciones mejoran añadiendo controles y corrigiendo puntos concretos; otras necesitan una revisión más profunda de su arquitectura y del proceso que intentan sostener.
