Qué parte de un control se puede automatizar (y qué parte no): la guía para PyMEs

El control que “ya está automatizado”

Si tenés una PyME, seguro pasaste por esto. Instalaste un sistema, configuraste una validación, un flujo de aprobación, una alerta. Y durante un tiempo dormiste tranquilo: el control “ya está automatizado”.

Hasta que apareció el problema que el sistema no vio. Un pedido despachado a un cliente que no tenía que recibir crédito. Una orden de compra duplicada que pasó todas las validaciones. Un remito perfecto en formato, con la cantidad equivocada.

El sistema no falló. Hizo exactamente lo que le pediste. El problema es que le pediste que hiciera algo que no puede hacer: reemplazar un criterio con una regla.

En el artículo anterior sobre human in the loop hablamos del revisor decorativo: la persona que aprueba sin mirar porque el proceso está diseñado para que apruebe. Este artículo va un paso más adelante y responde la pregunta que quedó abierta: de un control, ¿qué parte se puede automatizar y qué parte no?

Un control no es una cosa: son tres

Cuando un dueño de PyME dice “acá hay un control”, casi siempre está pensando en la persona o en la pantalla. Pero un control operativo, bien mirado, tiene tres componentes distintos:

1. El criterio: contra qué se compara

Es la regla. “El pedido no puede superar el límite de crédito”. “El proveedor tiene que estar habilitado”. “El lote no sale sin certificado de análisis”.

2. La autoridad: quién puede frenar

Es la capacidad de detener el flujo y de decidir qué pasa con la excepción. No es lo mismo poder marcar un problema que poder parar la línea. Si esto no está definido, una matriz RACI es el lugar donde se resuelve.

3. El tiempo: cuándo se ejecuta

Es el momento real en que el control ocurre, y cuánto tiempo hay para hacerlo bien. Un control diseñado para “antes de despachar” que en la práctica se hace “al final del día, en tanda”, no es el mismo control.

Estas tres condiciones no se automatizan igual. Y ahí está la clave de todo.

La escala: qué tan mecanizable es cada parte

Esta distinción no salió de un manual. Salió de un intercambio en LinkedIn a partir del artículo anterior: un lector que trabaja en desarrollo de software tomó el marco de las tres condiciones y lo probó en un terreno muy distinto al de una PyME industrial, la revisión de código, con resultados que se pueden ordenar en una escala de mecanizabilidad. Lo que sigue es esa escala aplicada a la operación de cualquier empresa.

El criterio: alto grado de mecanización, con un límite preciso

Un criterio se automatiza bien cuando se puede verificar contra una estructura: un campo está completo o no, un valor está dentro de un rango o no, un documento existe o no existe, una fecha venció o no venció.

Todo eso lo hace mejor una máquina que una persona. No se cansa, no se distrae, no aprueba en tanda a las 18:40.

El límite es este: el chequeo automático garantiza completitud, no veracidad. Verifica que el certificado de análisis esté cargado. No verifica que el análisis diga lo que tiene que decir. Verifica que el remito tenga las 12 líneas. No verifica que las 12 líneas coincidan con lo que salió del depósito.

Cuando el criterio es “¿esto está bien?”, y “bien” depende del contexto, la máquina no tiene contra qué comparar.

La autoridad: se mecaniza la consecuencia, no el juicio

Acá está la idea central del artículo, y conviene decirla completa: la automatización se hace cargo de las consecuencias, no del juicio.

Un sistema puede bloquear un pedido que supera el límite de crédito. Puede impedir que se emita un remito sin orden de compra. Puede derivar automáticamente una excepción a la persona que corresponde. Todo eso es consecuencia, y se mecaniza perfecto.

Lo que no se mecaniza es la decisión sobre la excepción. Si el cliente superó el límite pero es el mejor cliente del año y pagó siempre, alguien tiene que decidir si se despacha igual. Eso es juicio: pesar información que no está en el sistema contra un riesgo que tampoco está.

El error típico es el inverso en las dos direcciones: automatizar el juicio (una regla decide la excepción, y la decide mal) o dejar en manos humanas la consecuencia (una persona tiene que “acordarse” de frenar el pedido, y no se acuerda).

El tiempo: casi no se mecaniza, y falla en silencio

Esta es la parte que menos se ve y la que más daño hace.

El tiempo de un control es el más difícil de mecanizar porque no depende del sistema sino de la capacidad real de las personas. Si el dueño tiene que revisar 380 pedidos por mes y en el diseño del proceso eso “lleva 30 segundos cada uno”, el sistema puede enviarle los 380. Lo que no puede hacer es fabricar las tres horas de atención que eso requiere.

Y cuando el tiempo no existe, el control no se cae de forma visible. Nadie avisa “no revisé”. Simplemente se aprueba más rápido, se mira menos, se firma en bloque. El control sigue figurando en el diagrama. El revisor decorativo ya nació. Es la misma lógica que hace que la dependencia del dueño sea invisible hasta que el dueño falta.

Esto tiene una consecuencia de diseño que casi nadie aplica: el nivel de control hay que elegirlo contra la capacidad real, no contra el riesgo ideal. Segmentar por riesgo (revisar en detalle solo lo que lo amerita) no es una cuestión de eficiencia. Es la única forma de que el control entre en el tiempo que efectivamente existe.

Un caso ilustrativo: aprobación de pedidos a crédito

El caso que sigue es hipotético y está construido para ilustrar el método. No corresponde a ningún cliente.

Una distribuidora de insumos industriales procesa unos 380 pedidos por mes. Cada pedido a crédito pasa por la aprobación del dueño, que es el único con autoridad para liberar despachos.

Situación inicial

• Control diseñado: el dueño revisa cada pedido antes del despacho.
• Control real: los pedidos se acumulan y el dueño los libera en tanda al final del día. Tiempo promedio de revisión por pedido: menos de 10 segundos.
• Resultado: en seis meses, 14 despachos a clientes con facturas vencidas a más de 60 días. Mora recuperable, pero con un costo financiero y de gestión de cobranza que nadie había presupuestado.

El sistema no tenía ninguna regla. Todo el control dependía de una persona que, en la práctica, no tenía el tiempo para ejercerlo. Era, además, el cuello de botella de toda la operación comercial.

Rediseño con la escala de mecanizabilidad

Criterio (mecanizado): se cargan dos reglas estructurales en el sistema. Un pedido queda bloqueado si supera el límite de crédito asignado o si el cliente tiene alguna factura vencida a más de 30 días. Son datos que el sistema ya tenía; nadie los estaba usando.

Autoridad (consecuencia mecanizada, juicio humano): el bloqueo es automático. Lo que sigue al bloqueo, no: el pedido se deriva al dueño con la información del caso a la vista (saldo, antigüedad de la deuda, historial de pago).

Tiempo (ajustado a la capacidad real): se acepta explícitamente que el dueño no va a mirar 380 pedidos. Va a mirar solo los que el sistema no puede resolver.

Resultado del primer mes

De 380 decisiones nominales a 30 decisiones reales. El tiempo total del dueño pasó de “tres horas que no existían” a dos horas que sí existen y se usan. Los despachos a clientes con mora crítica bajaron a cero en el primer trimestre, no porque el dueño se volviera más atento, sino porque dejó de tener que serlo en 350 casos que no lo necesitaban.

Cómo aplicarlo mañana: cinco pasos

1. Elegí un control que te preocupe. Uno solo. El que más veces “falló” en el último año, o el que depende de que alguien se acuerde.
2. Descomponelo en sus tres partes. Escribí en una hoja: ¿cuál es el criterio? ¿quién tiene autoridad para frenar? ¿cuándo ocurre realmente (no cuándo debería)?
3. Separá el criterio en dos columnas: estructural y de juicio. Estructural: lo que se puede verificar contra un dato que ya existe (rango, existencia, fecha, estado). De juicio: lo que requiere contexto que no está en ningún campo. Todo lo de la primera columna es candidato a automatizar hoy, sin comprar nada nuevo.
4. Mecanizá la consecuencia, no la decisión. Que el sistema bloquee, derive o avise. Que una persona decida sobre lo que quedó bloqueado, con la información del caso a la vista.
5. Medí la capacidad real y ajustá el volumen. Contá cuántas decisiones de juicio quedan por semana y cuánto tiempo hay para tomarlas. Si no entran, no subas el tiempo: bajá el volumen segmentando por riesgo. Es la única variable que podés controlar.

Si el control forma parte de un procedimiento escrito, este es el momento de actualizarlo: cómo hacerlo sin que quede en el cajón lo contamos en cómo redactar un procedimiento.

El error más común: confundir formato con verdad

La trampa más cara de la automatización de controles es esta: el sistema dice “OK” y todos leen “está bien”.

El sistema no dijo eso. Dijo que el campo estaba completo, que el archivo existía, que el valor estaba en rango. Validó forma. La veracidad, si alguien la tiene que verificar, sigue requiriendo una persona con tiempo y criterio.

Por eso el chequeo automático no reemplaza al muestreo: le sube el piso. Garantiza que el 100% de lo que pasa cumple la estructura, y libera la atención humana para lo único que no se puede verificar contra una estructura. Si eliminaste el muestreo humano porque “ya hay validación”, no automatizaste el control. Lo dejaste sin la mitad que importa.

Conclusión

Automatizar un control no es ponerle una regla a un sistema. Es decidir, parte por parte, qué le corresponde a una máquina y qué le corresponde a una persona.

La máquina se queda con el criterio estructural y con la consecuencia: lo que se compara contra un dato y lo que se ejecuta después. La persona se queda con el juicio: la excepción, el contexto, la veracidad. Y el tiempo, que es lo que casi nadie diseña, se resuelve de una sola manera: reduciendo el volumen de decisiones humanas hasta que entren en la capacidad que existe.

Los controles que fallan en las PyMEs no fallan por falta de tecnología. Fallan porque se automatizó lo que requería juicio, o se dejó en manos de una persona lo que requería una regla. Y en ambos casos, el diagrama sigue diciendo que el control está. Por eso, como en todo lo demás, conviene diseñar el proceso antes de automatizarlo.

Preguntas frecuentes

¿Qué controles conviene automatizar primero en una PyME?

Los que tienen criterio estructural y alto volumen: validaciones de completitud, límites de crédito, existencia de documentos obligatorios, vencimientos. Son los que más carga humana liberan con menos riesgo, y en general se pueden configurar con el sistema que ya tenés.

¿Automatizar un control elimina la necesidad de una persona?

No. Elimina la necesidad de que una persona revise lo que se puede verificar contra un dato. La decisión sobre las excepciones y la verificación de veracidad siguen requiriendo juicio humano. Lo que cambia es que esa persona ahora tiene tiempo para hacerlo bien.

¿Cómo sé si un control está fallando en silencio?

Medí el tiempo real de revisión por caso y comparalo con el que requiere hacerlo bien. Si un control que necesita cuatro minutos se está haciendo en diez segundos, ya falló. Otro indicador es la tasa de aprobación: un control que aprueba el 99% de lo que revisa probablemente no está revisando.

¿Por qué un chequeo automático no reemplaza al muestreo?

Porque verifica forma, no veracidad. Un sistema puede confirmar que el certificado está cargado; no puede confirmar que el certificado sea correcto. El chequeo automático sube el piso de calidad y libera al muestreo para concentrarse en lo que la máquina no puede ver.

¿Qué pasa si no tengo sistema para automatizar el criterio?

Podés aplicar la misma lógica en papel o en una planilla: separar criterio estructural de juicio, definir quién frena y cuándo, y ajustar el volumen de revisión humana a la capacidad real. La automatización acelera un control bien diseñado; no arregla uno mal diseñado.