Provecto
← Volver al blog

Casos edge en automatización: qué son y por qué importan

Pila de papeles y una hoja aparte en una bandeja de cartón sobre una mesa de oficina: casos edge en automatización

Los casos edge en automatización son esas situaciones raras que nadie había previsto al construir una herramienta, y son las que deciden si esa herramienta es de fiar o no.

Imagina una empresa que recibe facturas de proveedores distintos, cada uno con su propia plantilla. Aun así, una herramienta puede identificar quién emite cada una casi siempre sin fallar: busca un NIF, un CIF, una forma jurídica como "SL" o "SA". Esos datos tienen formatos tan fijos que da igual cómo esté maquetada la factura. Cientos de facturas, cero problemas.

Hasta que un día llega una que no encaja: un escaneo tan borroso que el CIF es ilegible, o una empresa con una forma jurídica rarísima que nadie había visto antes. Eso es un caso edge: no es lo habitual, es la excepción. Pasa poco, pero pasa.

Por qué aparecen siempre

Los casos edge no aparecen porque alguien haya construido mal algo. Aparecen porque la realidad de una empresa tiene más variaciones de las que caben en la cabeza de una persona en un solo momento.

Cuando una tarea la hace una persona a mano, estos casos casi no se notan. Ve la factura rara, piensa un segundo y sigue. Ni se entera de que acaba de resolver una excepción.

Cuando esa misma tarea se automatiza, cada una de esas pequeñas decisiones que antes eran automáticas para la persona hay que dejarlas explícitas para la máquina. Y es imposible anticiparlas todas antes de que ocurran.

El error de intentar cubrirlo todo

Hay una tentación clásica: añadir una condición nueva a la herramienta cada vez que aparece un caso nuevo, hasta que "lo cubra todo".

El problema es que "todo" no tiene fin. Cada regla que se añade para resolver un caso raro puede chocar con otra regla, o generar un caso raro distinto. La herramienta se vuelve más grande, más frágil y más difícil de entender, sin llegar nunca a estar realmente terminada.

Y mientras tanto, los casos que sí encajaban bien siguen funcionando solos, sin que nadie tenga que tocarlos. Es decir, se está complicando todo el sistema para resolver un puñado de excepciones.

Lo que sí funciona: separar, no adivinar

La alternativa no es intentar que la máquina lo resuelva todo. Es que sepa reconocer cuándo algo no encaja y lo aparte para que lo vea una persona. En la práctica, eso significa construir la herramienta con dos caminos desde el principio:

  1. El camino normal: los casos que siguen el patrón esperado se procesan solos, de principio a fin.
  2. El camino de excepción: los casos que no encajan se detectan, se apartan y quedan listos, con toda la información a mano, para que alguien los revise en segundos. No se pierden y no rompen el proceso.

Esto no es una carencia de la herramienta, es diseño responsable. Una automatización que finge que no existen los casos raros es la que un día falla en silencio, mete un dato mal y nadie se entera hasta que ya es tarde.

Volviendo a las facturas: la herramienta identifica al proveedor sola en la gran mayoría de los casos. Y cuando llega esa factura rara, no la fuerza ni la adivina. La aparta con todo preparado para que alguien la revise en diez segundos, en vez de dejar que un dato mal leído se cuele en la contabilidad sin que nadie se dé cuenta.

Es la misma idea que adelantamos en nuestro artículo sobre automatizar el método y no el proceso: la máquina aplica las reglas que se conocen y las dudas pasan a una persona.

Cómo detectar los casos edge antes de construir

La mayoría se pueden descubrir antes de escribir una sola línea de código, simplemente haciendo las preguntas adecuadas a quien hoy hace la tarea a mano:

  1. ¿Qué pasa cuando falta un dato? Un campo vacío, un documento incompleto, un archivo que no llega.
  2. ¿Qué pasa cuando hay dos coincidencias? Dos clientes con el mismo nombre, dos reservas parecidas, dos facturas casi idénticas.
  3. ¿Qué pasa cuando el formato cambia? Un proveedor que renueva su plantilla, un documento escaneado en lugar de digital.
  4. ¿Cuál fue la última vez que algo salió raro? Quien hace la tarea a diario suele recordar al instante las excepciones que más guerra dan.

Esas conversaciones valen más que cualquier especificación. Las excepciones no están en un documento, están en la experiencia de las personas que llevan años resolviéndolas sin darse cuenta.

Y no hace falta cubrirlas todas de antemano. Basta con que la herramienta sepa que existen y tenga un sitio donde dejarlas. Las que se repitan con frecuencia se pueden convertir después en reglas nuevas.

Por qué esto nos importa al construir

Cuando nos sentamos con una empresa a ver cómo trabaja de verdad, no miramos solo el proceso cuando todo va bien. Preguntamos qué pasa cuando algo no encaja, porque esas respuestas definen si una herramienta va a aguantar el día a día o va a dar problemas al primer mes.

No prometemos una herramienta que lo resuelva todo sola. Prometemos una que haga bien lo que se puede automatizar y que avise con claridad cuando algo necesita a una persona, en vez de esconder el problema o romperse por sorpresa.

¿Tienes una tarea que casi siempre sigue el mismo patrón, pero de vez en cuando aparece un caso raro que lo desbarata todo? En un diagnóstico corto y sin compromiso vemos si merece la pena automatizarla y cómo dejar las excepciones listas para decidir en segundos.

Cuéntanos tu tarea →

Más artículos