Estrategia7 min de lectura
Cómo elegir qué automatizar (y qué dejar en paz)
La pregunta que más nos hacen no es si podemos automatizar algo, sino qué conviene automatizar primero. Cuatro números y dos reglas resuelven casi todos los casos.
Casi nadie llega con un proyecto definido. Llega con una sensación: «se nos va muchísimo tiempo en cosas que debería hacer una máquina». Es una buena sensación y suele ser correcta. El problema es que no se puede actuar sobre ella.
Priorizar automatización sin cifras es opinar. Y las iniciativas de tecnología fracasan más por elección que por ejecución: se automatiza el proceso que alguien pidió en lugar del que más cuesta.
Los cuatro números
Antes de discutir herramientas hacen falta cuatro datos por proceso candidato. Son los mismos cuatro, siempre, y se obtienen preguntando a quien ejecuta el proceso — no a quien lo describe.
| Número | Qué es | Por qué importa |
|---|---|---|
| Volumen | Casos por mes | Un proceso de 20 casos al mes casi nunca justifica el proyecto |
| Tiempo por caso | Minutos reales, medidos | Es el multiplicador: 3 min × 5,000 casos son 250 horas |
| Personas | Cuántas lo tocan | Un proceso repartido entre cinco áreas tiene un costo de coordinación oculto |
| Criticidad | Qué pasa si se detiene un día | Distingue una molestia de una dependencia del negocio |
El producto de los dos primeros da el costo actual. Ese número es la línea base, y sin línea base no hay forma de demostrar el cambio después. Es el error más caro de un proyecto de automatización: no saber de dónde se partió.
La primera regla: viabilidad antes que impacto
Un proceso muy costoso pero técnicamente inviable no va primero. Ordenar sólo por impacto es cómo se llega a un proyecto de seis meses que no termina.
La pregunta de viabilidad tiene tres partes: qué sistemas hay que tocar, si exponen alguna forma de conexión, y qué pasa cuando algo se sale de la norma. Las dos primeras casi siempre tienen respuesta — si no hay API, se opera la interfaz y el proceso avanza igual. La tercera es la que decide.
El umbral de excepciones
Un proceso con muchas excepciones no es candidato a automatización: es candidato a rediseño. Y la diferencia importa, porque automatizar un proceso caótico produce un sistema caótico, más rápido.
Cuando la tasa de excepciones es alta, lo que hay no es un problema de ejecución sino de definición: la regla no está acordada, y cada persona resuelve a su criterio. Eso se arregla antes, y se arregla hablando, no programando.
La segunda regla: el segundo proceso cuesta menos que el primero
Esto cambia el orden. El primer proceso de una organización paga la curva de aprendizaje: credenciales, accesos, conexiones, patrones de excepción, la forma de desplegar. A partir del segundo, todo eso se reutiliza.
Por eso el primer proceso no debería ser el más grande. Debería ser el que más rápido demuestra que el enfoque funciona, en un área donde alguien tenga interés real en que funcione. El proyecto insignia va en tercer lugar, cuando ya nadie discute si esto sirve.
Qué dejar en paz
Hay tres casos en los que recomendamos no automatizar, y decirlo cuesta un proyecto:
- El proceso está a punto de cambiar. Automatizar sobre un sistema que se va a reemplazar en seis meses es construir para tirar.
- El proceso es la excepción, no la regla. Si cada caso es distinto, lo que hay es trabajo de criterio, y el criterio no se automatiza.
- Nadie es dueño del proceso. Sin una persona que responda por el resultado, la automatización se rompe el primer día que el sistema de origen cambia y nadie se da cuenta.
El entregable del diagnóstico
Un diagnóstico serio es corto y produce una decisión, no un documento. Al final debe existir una lista ordenada de procesos con su costo actual, su viabilidad y el orden en que conviene abrirlos — en el nivel de detalle que permite empezar la semana siguiente.
Si tienes la sensación pero no los cuatro números, eso es exactamente el punto de partida de una primera conversación.
¿Aplicamos esto a un proceso tuyo?
La primera conversación es de diagnóstico. Si el proceso no conviene tocarlo, también lo decimos.