- 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.
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.
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.
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.
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. Preferimos dicirche ao principio “isto é máis complexo do que parece” que “isto non funciona como esperabas” 6 meses despois.