Lo que la automatización puede unir, y lo que no
Automatizar es un disparador, un dato y un destino. Casi todos los proyectos fallan no por la lógica, sino porque uno de los sistemas involucrados no tiene una entrada o una salida decente.
Alguien en tu oficina recibe un pedido por WhatsApp, copia el nombre del cliente en un Excel, abre el sistema de contabilidad y escribe el mismo nombre otra vez, y después manda la confirmación a mano. Son cuatro minutos por pedido y un tipeo de distancia de una factura con el RNC equivocado. Multiplica por cincuenta pedidos a la semana y tienes un día completo de trabajo dedicado a volver a digitar datos que ya llegaron en formato digital la primera vez.
Ese es el problema que resuelve la automatización, y conviene ser preciso con la palabra. Una automatización son tres cosas: un disparador (entra un pedido, se envía un formulario, llega una fecha), una transformación (extraer los campos, normalizar el teléfono, identificar al cliente) y un destino (escribir una fila, llamar a un endpoint, enviar un mensaje). Nada más. Si alguien te vende "automatización" y no puede nombrarte esas tres partes para tu caso concreto, te está vendiendo un diagrama.
Lo que sí se puede unir
Lo que decide casi nunca es la complejidad de tu proceso. Es si cada sistema del camino tiene una puerta: una API documentada, un webhook, una exportación programada o, como mínimo, una base de datos que sea tuya. Si ambos extremos tienen puerta, el trabajo es plomería y sale barato. Si a uno le falta, el precio se triplica y la confiabilidad baja, sin importar quién lo construya.
Lo que se conecta limpio, según lo que vemos:
- Cualquier SaaS con API REST y llaves que tú controles, incluyendo la mayoría de herramientas modernas de contabilidad, CRM y facturación
- WhatsApp por la Cloud API oficial, porque los mensajes entrantes llegan como webhooks con un ID estable
- Todo lo que tú mismo hospedas, donde en el peor caso queda un usuario de solo lectura sobre la base de datos
- Correo, si el formato lo genera una máquina y es consistente, y nunca si lo redacta una persona a mano libre
- Archivos depositados en S3, Drive o SFTP, poco vistosos y extremadamente confiables
Fíjate en lo que tienen en común. Cada uno te da un identificador estable y una forma de saber si un registro ya fue procesado. Sin eso no puedes reintentar con seguridad, y una automatización que no puede reintentar con seguridad es una automatización que tarde o temprano duplica una factura.
Dónde se rompe
Los bloqueos habituales son aburridos y no son problemas de creatividad técnica. Los sistemas viejos en RD muchas veces no exponen absolutamente nada: el proveedor vende el software y trata los datos como suyos. Los portales de gobierno y de los bancos piden login, captcha y con frecuencia un OTP al celular, así que ningún proceso desatendido pasa por ahí de forma honesta. Y un PDF no es un dato. Un modelo de IA lee bien una factura en PDF, pero "bien" significa que acierta casi siempre, y casi siempre es un problema de ingeniería distinto a siempre.
El otro modo de falla es la identidad. Unir dos sistemas implica decidir que la María Rodríguez de uno es la misma María Rodríguez del otro. Si ninguno guarda cédula, RNC o teléfono normalizado, esa decisión es una adivinanza, y la automatización va a fusionar dos clientes o partir uno en tres. Eso se arregla con higiene de datos antes de escribir código, y saltárselo es la razón por la que las integraciones se apagan calladas al mes.
Si un proceso necesita que una persona mire algo y lo juzgue, automatiza todo alrededor del juicio y deja el juicio quieto. Automatizar una decisión a medias es peor que no automatizarla.
Cómo distinguir una implementación real de un demo
Un demo corre una vez, con una entrada limpia y alguien mirando. Producción corre tres mil veces con entradas que nadie previó, a las 2am, cuando la API de destino está caída. La diferencia entre las dos no está en la lógica interesante. Está en la maquinaria poco vistosa que la rodea, y esa maquinaria se puede auditar sin leer una línea de código.
Pide ver estas cinco cosas antes de dar el trabajo por recibido:
- Un log de ejecuciones: cada corrida con su entrada, su salida y su resultado, consultable por varios meses
- Idempotencia: prueba de que disparar dos veces lo mismo no crea dos registros
- Reintentos con backoff y un lugar donde esperan los ítems que fallaron en firme, para que un humano los revise
- Una alerta que le llegue a una persona cuando sube la tasa de error, no un dashboard que nadie abre
- Credenciales en tus cuentas y bajo tu facturación, para que la automatización sobreviva a un cambio de proveedor
La lección más barata es que la falla tiene que ser ruidosa. La automatización más simple de este sitio es un formulario de contacto que postea a un script PHP y despacha a un buzón; si ese buzón no existiera, el formulario igual diría gracias y el mensaje no llegaría a ningún lado. Esa es la forma de casi toda integración rota que nos han pedido arreglar. No es que no hiciera nada. Es que no hacía nada en silencio.
Así que el alcance honesto de un proyecto de automatización es: mapear las puertas primero, arreglar los identificadores segundo, escribir la lógica tercero, y gastar una parte real del presupuesto en observarla. Un flujo que le ahorra cuatro minutos por pedido a una persona se paga rápido. Un flujo que pierde en silencio un pedido de cada cincuenta cuesta más que el proceso manual que vino a sustituir.