todos los artículos
automatización · 5 min de lectura
Una estrategia práctica para integrar los sistemas de tu empresa
Priorizá integraciones entre sistemas con un mapa de dependencias, responsables con nombre, un piloto acotado y criterios medibles de aceptación y reversión.
Una empresa de diez a cincuenta personas suele funcionar con muchas aplicaciones separadas: contabilidad, un CRM, una mesa de ayuda, una herramienta de proyectos, una carpeta compartida, sueldos, una tienda o un sistema de reservas. Cada una funciona bien por su cuenta. El costo aparece entre ellas: copiar y pegar, facturas que se vuelven a tipear y planillas para cuadrar un sistema contra otro.
La tentación es conectar todo de una vez. Este artículo propone lo contrario: elegir qué integración armar primero, quién es su responsable, cómo probarla en chico y cómo deshacerla si sale mal.
Paso 1: dibujá un mapa de dependencias
Hacé una lista de todos los sistemas y, para cada uno, anotá qué datos manda y qué datos necesita recibir. Después dibujá las flechas. Alcanza con una foto de un pizarrón o una planilla simple. Ayudan dos columnas por flecha: "cómo se mueve hoy" (exportación manual, correo, volver a tipear) y "con qué frecuencia".
Buscás tres cosas:
- Centros: sistemas con muchas flechas que entran y salen, en general el CRM o la herramienta contable. Cualquier cambio ahí repercute en todos lados, así que piden más cuidado.
- Puentes manuales: flechas donde una persona mueve datos a mano de forma periódica. Esos son tus candidatos.
- Orden oculto: algunos flujos dependen de otros. No podés sincronizar facturas con contabilidad de forma confiable hasta que los registros de clientes coincidan entre el CRM y la herramienta contable.
Ese último punto define la secuencia. Si dos sistemas no se ponen de acuerdo sobre quién es un cliente, primero resolvé la identidad. (Si eso te pasa con herramientas de atención al cliente, nuestra guía sobre cómo conectar CRM, soporte y sistemas de opiniones de clientes explica en detalle la coincidencia de registros, el consentimiento y la retención).
Paso 2: puntuá a los candidatos
Para cada puente manual, respondé cinco preguntas con estimaciones aproximadas y honestas. No necesitás cifras precisas; necesitás un orden.
| Pregunta | Por qué importa |
|---|---|
| ¿Con qué frecuencia pasa y cuánto tarda cada vez? | Frecuencia por esfuerzo es el costo real de no hacer nada |
| ¿Qué sale mal cuando se hace a mano? | Los errores en facturación o sueldos pesan más que los errores en una lista de lectura |
| ¿Frena otro trabajo u otras integraciones? | Lo que se resuelve antes en la cadena abarata lo que viene después |
| ¿Los dos sistemas tienen una API usable o un conector nativo? | Sin eso, el desarrollo se vuelve más lento y más frágil |
| ¿Quién sería responsable después del lanzamiento? | Sin responsable, se va a romper sin que nadie se entere |
Elegí la integración con alta frecuencia, un costo real de error, un camino técnico limpio y un responsable dispuesto. Muchas veces no es la más vistosa.
Paso 3: nombrá a los responsables antes de construir nada
Toda integración necesita dos personas con nombre:
- Un responsable de negocio, que define qué es un resultado correcto, aprueba los cambios y da el visto bueno al piloto. En general es la persona cuyo equipo hace hoy el trabajo manual.
- Un responsable técnico, que guarda las credenciales, lee las alertas de error y puede pausar el flujo. En una empresa chica puede ser la misma persona, o alguien externo que arma la integración con un plan de traspaso.
Anotá qué sistema es dueño de cada campo compartido. Si tanto el CRM como la herramienta contable pueden editar una dirección de facturación, decidí cuál manda. Una sincronización en dos sentidos sin una regla pisa datos buenos.
Paso 4: estimá el costo completo
El desarrollo es solo una parte. Antes de comprometerte, hacé una lista de:
- Tiempo de desarrollo, interno o externo.
- Uso de la plataforma. Las herramientas de automatización miden el uso en unidades distintas, así que un diseño barato en una puede salir caro en otra. Zapier cuenta una tarea por cada paso de acción que se ejecuta con éxito; su centro de ayuda dice que los disparadores y los pasos de filtro no consumen tareas. Make cuenta operaciones y cobra en créditos; su centro de ayuda dice que un disparador cuenta una vez por cada revisión, y que cada módulo de acción cuenta una vez por cada paquete de datos que procesa. Preguntá cómo se cuenta un disparador por consulta periódica cuando no encuentra nada nuevo. La página de precios de n8n define una ejecución como una sola corrida de un flujo completo, sin importar cuántos pasos tenga. Calculá tu volumen esperado contra las páginas de planes vigentes en lugar de adivinar.
- Acceso a conectores y API. Algunas aplicaciones solo ofrecen API en ciertos planes. Revisalo antes de diseñar.
- Mantenimiento. Las aplicaciones cambian campos, los tokens vencen y hay límites de uso. Reservá un poco de tiempo por mes para que alguien revise el registro de errores.
- Costo de salida. Si la herramienta te queda chica, ¿qué tan difícil es llevar la lógica a otro lado?
Paso 5: corré un piloto acotado
Limitá el piloto por tres lados: alcance, datos y tiempo.
- Alcance: un flujo, en un solo sentido. Por ejemplo, las facturas nuevas pagadas en la tienda crean registros de venta en contabilidad. Ni reintegros, ni modificaciones, ni datos históricos.
- Datos: un subconjunto que puedas revisar a mano, como una línea de productos, una región o los primeros cincuenta registros.
- Tiempo: de dos a cuatro semanas suele alcanzar para ver un ciclo completo de facturación o de informes. Elegí una duración que cubra al menos uno.
Durante el piloto, mantené en paralelo el proceso manual de siempre, así podés comparar los resultados registro por registro.
Paso 6: escribí los criterios de aceptación y de reversión antes del lanzamiento
Acordalos por escrito con el responsable de negocio antes de que arranque el piloto, no después de ver los resultados.
Los criterios de aceptación son controles que una persona puede verificar, por ejemplo:
- Cada registro del sistema de origen aparece en el de destino, con totales que coinciden, para el período del piloto.
- No se creó ningún registro duplicado.
- Cada falla generó una alerta que una persona con nombre vio dentro de un día hábil.
- Volver a procesar un registro fallido no crea una segunda copia.
Los criterios de reversión dicen cuándo frenás y cómo:
- Disparadores. Por ejemplo: cualquier monto equivocado en contabilidad, o más fallas por semana de las que el equipo puede arreglar a mano.
- Cómo pausar. Quién apaga el flujo y dónde. Escribí los pasos exactos.
- Cómo limpiar. Una lista de los registros creados por la integración (etiquetalos o guardá sus ID) para poder encontrarlos y revertirlos.
- Plan alternativo. El proceso manual sigue documentado y en condiciones de usarse hasta que la integración pase la aceptación.
Si no podés describir cómo deshacerla, la integración no está lista para encenderse.
Paso 7: salí en producción por etapas y después elegí la próxima
Después de la aceptación, ampliá el alcance de a un paso: más registros, después un segundo sentido, después las modificaciones. Dejá las alertas encendidas. Tras más o menos un mes funcionando estable, retirá el proceso manual en paralelo y volvé al mapa de dependencias para elegir la próxima integración. Cada una que terminás suele abaratar la siguiente, porque la identidad y los responsables ya están resueltos.
Dónde entra automotif
Elegir, probar y entregar integraciones como estas es lo que cubre nuestro desarrollo de automatizaciones: trabajamos en tus propias cuentas de n8n, Make o Zapier, escribimos con vos los criterios de aceptación y de reversión, y le dejamos documentación al responsable. Si querés repasar tus propios sistemas, reservá una llamada gratis de 30 a 60 minutos.