# Automatizacións que parecen simples pero fallan sempre

Source: https://baqueiro.es/gl/automatizacion/automatizacions-que-parecen-simples-fallan/
Published: 2026-09-23T07:36:00+00:00
Updated: 2026-09-23T07:36:00+00:00
Author: Baqueiro Desarrollo Web
Language: gl-ES
Usage: Atribución requirida: permítese a cita cunha ligazón visible de volta

---

**TL;DR**

- As automatizacións “simples” adoitan ignorar casos límite, formatos inconsistentes e cambios en sistemas externos, e por iso acaban fallando.
- O custo real dunha automatización inclúe a xestión de erros, os rexistros (logs) e o mantemento, non só o caso ideal.
- Antes de automatizar, comproba se o proceso é estable abondo e se o aforro xustifica a complexidade.

“É simple: cando chega un correo de confirmación de pedido, extraemos o número de pedido, buscámolo no ERP e actualizamos o estado na web.” Así comezou a conversa cun cliente que quería automatizar o seu fluxo de pedidos. 6 meses despois, a automatización fallara ducias de veces, cada fallo esixira intervención manual e o cliente estaba máis estresado ca antes.

O problema non era a tecnoloxía, senón que o proceso real era máis complexo do que parecía: formatos de correo inconsistentes, pedidos parciais, devolucións que usaban o mesmo tipo de correo e cambios no modelo que rompían o parser (o código que le a mensaxe e extrae os datos).

Hai patróns de automatización que vemos fallar unha e outra vez. Non son fallos técnicos, son fallos de análise do proceso.

## Patrón 1: extraer datos de correos electrónicos

A idea é atractiva: o correo electrónico é universal e parece sinxelo. A realidade é outra:

**Os correos son HTML inconsistente.** Uns chegan ben maquetados, outros con HTML caótico xerado desde Word e outros en texto plano. O teu parser ten que entendelos todos.

**Os remitentes cambian sen avisar.** O provedor cambia de ferramenta de envío e as confirmacións chegan desde outro enderezo e con outro formato. A automatización párase ata que alguén se decata.

**Corpo, anexos ou ligazóns.** Os datos poden estar no corpo, nun PDF anexo, tras unha ligazón externa ou nos tres sitios á vez, con información contraditoria.

**Casos límite humanos.** O correo de “pedido cancelado” usa o mesmo modelo que o de “pedido confirmado”, cunha soa liña distinta. O parser márcao como completado cando debería marcalo como cancelado.

**Alternativa máis robusta:** conexións directas por API entre sistemas sempre que sexa posible. Cando non o sexa, formatos estruturados (un CSV por SFTP, webhooks con JSON) antes ca correos en texto libre. Se traballas con ferramentas como Make ou Zapier, aquí explicamos [como conectar a túa web con Make/Zapier sen crear unha bomba de reloxería](https://baqueiro.es/gl/automatizacion/conectar-web-make-zapier-sen-problemas/).

## Patrón 2: sincronizar datos entre sistemas

“Quero que o CRM e o ERP teñan os mesmos clientes.” Soa razoable. A realidade:

**Formatos de datos incompatibles.** O CRM ten “nome” e “apelidos” separados; o ERP, un único campo “nome_completo”. O CRM usa “ES” para España e o ERP usa “34” ou “ESP” segundo o campo.

**Bucles de sincronización.** A actualiza un cliente e sincronízao con B. B fai un cambio automático (por exemplo, asignar un número de cliente), iso dispara unha sincronización de volta cara a A e sobrescríbese o cambio orixinal. E así sen fin.

**Conflitos de edición.** Alguén edita o mesmo cliente nos 2 sistemas entre unha sincronización e a seguinte. Que versión gaña? A máis recente non ten por que ser a correcta para o negocio.

**Sistema de referencia.** Que sistema “manda”? Se o ERP é o sistema financeiro oficial, quizais certos campos só deberían poder actualizarse desde el. Definilo esixe entender o negocio, non só a tecnoloxía.

**Solución:** un sistema de referencia claro para cada dato, campos de “última modificación” e “orixe do cambio”, e resolución manual de conflitos para os casos problemáticos. Nada de sincronizar ás cegas. Explicámolo con máis detalle en [o que gaña unha empresa cando os seus sistemas deixan de funcionar en silos](https://baqueiro.es/gl/automatizacion/silos-datos-empresa-conectar-sistemas-gl/).

## Patrón 3: automatizar de principio a fin procesos que requiren criterio

Unha empresa tiña un proceso de alta de clientes con 5 pasos: verificar a documentación, crear contas en 2 sistemas distintos, enviar un correo de benvida segundo o tipo de cliente e avisar o equipo de conta.

Automatizárono por completo. O resultado: clientes con documentación incompleta activáronse igualmente, creáronse contas en sistemas equivocados porque fallou a clasificación por tipo de cliente e os correos de benvida acabaron no spam porque ninguén comprobara a entregabilidade.

O erro foi automatizar decisións que requirían criterio humano.

**Alternativa:** automatizar os pasos mecánicos (crear contas, enviar correos) e manter un punto de aprobación humana antes da activación final. Semiautomatización en lugar de automatización total.

## Patrón 4: integrarse con APIs que “funcionan ben”

“A API do provedor está documentada e funciona.” Si, nas probas. En produción:

**Límites de uso non documentados.** A API acepta 100 chamadas por minuto nas probas. En produción, con volume real, empezas a recibir erros 429 (Too Many Requests) sen aviso previo.

**Caídas non anunciadas.** O provedor reinicia os seus servidores os domingos ás 3 da madrugada. A túa automatización falla en silencio e ninguén se decata ata o luns.

**Cambios sen versionado.** Un campo que era obrigatorio pasa a ser opcional e a túa validación falla. Ou aparece un campo novo e o teu código ignora datos importantes.

**Erros ambiguos.** A API devolve un 200 OK, pero o corpo di {“status”: “error”}. Ou devolve un 500 sen corpo.

**Solución:** rexistros detallados, reintentos con esperas crecentes (backoff exponencial), cortacircuítos ou circuit breakers (se a API falla de máis, déixase de insistir durante un tempo) e unha monitorización que avise cando os fallos superan un limiar aceptable.

## Patrón 5: facer scraping porque non hai API

O scraping (extraer datos directamente de páxinas web) é tentador cando non hai API oficial, pero é fráxil por deseño:

**O HTML cambia.** Un redeseño do sitio, un cambio nas clases CSS ou unha estrutura distinta, e o teu scraper deixa de extraer os datos correctos, a miúdo sen que ninguén se decate.

**Medidas anti-scraping.** CAPTCHAs, límites de peticións, bloqueos de IP. O scraper funciona en desenvolvemento e falla en produción cando o sitio detecta o volume.

**Condicións de uso.** Moitos sitios prohiben o scraping nas súas condicións de uso. Poden bloquearte tecnicamente e, nalgúns casos, tamén reclamarche pola vía legal.

**Datos pensados para persoas.** A páxina mostra datos formatados para lelos, non datos estruturados: “hai 2 horas” en lugar dunha data e hora exactas, “1,2 M€” en lugar de 1200000.

**Alternativa:** negociar un acceso oficial á API (aínda que haxa que pagalo), usar datos públicos estruturados se existen ou repensar se de verdade necesitas eses datos de forma automatizada.

## Patrón 6: automatizar decisións con datos incompletos

“Se o cliente non comprou en 90 días, enviarlle un correo de reactivación con desconto.” Soa lóxico. Pero:

- E se o cliente comprou na tenda física e esa compra non consta no sistema?
- E se non quere recibir comunicacións comerciais?
- E se xa recibiu 3 correos de reactivación e non abriu ningún? Seguimos insistindo?

Os datos que ves non son a realidade completa.

**Solución:** máis datos de contexto, limiares conservadores e, sempre, respectar as baixas e as preferencias de comunicación de cada cliente, que ademais é unha obriga legal.

## Como facer automatizacións que non fallen (ou que fallen ben)

Non estamos en contra da automatización: usámola constantemente, pero con precaucións.

**1. Entender o proceso antes de automatizalo.** Observar como se fai a man durante unhas semanas, identificar todos os casos límite e preguntar “que pasa se…?” ata esgotar as respostas.

**2. Deseñar para o erro, non para o caso ideal.** Nunha automatización ben feita, boa parte do código dedícase a xestionar erros, deixar rexistro e recuperarse. O caso ideal é a parte fácil.

**3. Rexistros detallados.** Cando algo falla, necesitas saber exactamente que pasou: identificadores, datas e horas, contido das chamadas ás APIs. Depurar sen logs é adiviñar, e sen documentación é aínda peor: contámolo en [o custo oculto das automatizacións mal documentadas](https://baqueiro.es/gl/automatizacion/custo-automatizacions-mal-documentadas/).

**4. Monitorización e alertas.** Configura avisos cando os fallos superen un limiar, cando falte a actividade esperada ou cando os datos parezan anómalos.

**5. Volta ao manual.** Cando a automatización falla, ten que ser fácil intervir a man sen romper nada e sen quedar nun estado intermedio con datos a medias.

**6. Comezar simple e ampliar aos poucos.** Automatizar primeiro o caso máis común, con alertas para as excepcións, e ir incorporando casos límite a medida que aparecen.

## Preguntas frecuentes

### Como sei se o meu proceso é estable abondo para automatizalo?

Se cambia cada semana, se ten moitas excepcións que se resolven a man ou se esixe criterio constantemente, probablemente non é un bo candidato. Os procesos repetitivos e ben definidos son os mellores.

### Canto custa manter unha automatización?

Como referencia orientativa, conta con entre un 10% e un 30% do custo de desenvolvemento inicial ao ano para mantemento, axustes e novos casos límite. O importante é orzamentalo desde o principio e incluílo ao [calcular o ROI real do proxecto de automatización](https://baqueiro.es/gl/codigo-que-trabaja-por-ti/calcular-roi-proxecto-automatizacion/).

### Que fago se unha automatización falla constantemente?

Avaliar de novo se paga a pena. Volver ao proceso manual é unha opción válida se a automatización xera máis traballo do que aforra.

## Conclusión

A automatización é potente, pero non máxica. As automatizacións que parecen simples a miúdo agochan unha complexidade que só aparece en produción. A clave está en anticipar esa complexidade, deseñar pensando no fallo e manter expectativas realistas.

Se estás a pensar en automatizar procesos e queres unha avaliación honesta de viabilidade e custo real, [cóntanos que queres automatizar](https://baqueiro.es/gl/contacto/). Preferimos dicirche ao principio “isto é máis complexo do que parece” que “isto non funciona como esperabas” 6 meses despois.