Cada vez que una empresa chilena anuncia que va a "automatizar procesos", la primera reacción de los equipos es la misma: ¿a quién van a echar? No es paranoia. Es una lectura razonable de cómo se ha hecho esto mal, muchas veces, en muchos lugares.
Pero hay otro camino. Y no es teórico.
La Tercera publicó hace poco un reportaje sobre empresas chilenas que automatizaron sin destruir empleo. Lo que más llama la atención no es la tecnología que usaron. Es lo que hicieron antes de usarla.
El error que convierte la automatización en un problema de personas
La secuencia habitual es esta: alguien decide que hay que "digitalizar", compran un software, lo instalan sobre los procesos que ya existen, y el sistema nuevo termina compitiendo con los hábitos viejos. Nadie lo usa bien. O peor: lo usan para hacer exactamente lo mismo que antes, pero con más pasos.
Cuando eso pasa, la frustración busca un culpable. Y el culpable suele ser la persona que "no se adapta". Ahí empieza el problema real.
La tecnología no es el origen del conflicto. El origen es haber automatizado un proceso que primero había que rediseñar.
Qué hicieron diferente estas ocho empresas
Los casos del reportaje van desde una distribuidora de alimentos en la Región Metropolitana hasta una empresa de servicios logísticos en el norte. Distintos rubros, distinto tamaño. Pero con una decisión en común: antes de comprar nada, se sentaron a entender qué estaban haciendo mal.
No contrataron un consultor para que les dijera qué software usar. Mapearon sus procesos con las personas que los ejecutaban todos los días. Preguntaron dónde estaban los cuellos de botella. Identificaron qué tareas se repetían sin agregar nada. Y solo después de eso, decidieron qué tenía sentido automatizar.
El resultado no fue despidos. Fue reasignación. Las personas que antes pasaban cuatro horas al día ingresando datos a una planilla dejaron de hacerlo. Y pasaron a hacer cosas que la máquina no puede hacer: resolver excepciones, atender clientes, supervisar calidad.
El caso de la distribuidora que dejó de perder pedidos
Una empresa distribuidora de productos de consumo masivo en Santiago tenía un problema concreto: los pedidos llegaban por WhatsApp, por correo, por teléfono y a veces en papel. Alguien los consolidaba manualmente cada mañana. Los errores eran frecuentes. Los reclamos, también.
La solución obvia habría sido comprar un sistema de gestión de pedidos y reemplazar a la persona que consolidaba. No lo hicieron así.
Primero rediseñaron el proceso: definieron un único canal de entrada, establecieron un formato estándar para los pedidos y eliminaron las excepciones que nadie había cuestionado en años. Solo después automatizaron la consolidación. La persona que antes hacía ese trabajo pasó a gestionar las excepciones y a hacer seguimiento proactivo con los clientes más grandes. Los reclamos bajaron. La cartera creció.
Por qué el miedo al despido tiene una causa concreta
Cuando una empresa automatiza sin rediseñar, hay dos posibilidades: o el sistema no funciona y todo sigue igual, o el sistema sí funciona y de repente hay una persona cuya función ya no existe.
Ese segundo escenario es real. Y pasa cuando el proceso se automatiza tal como estaba, sin preguntarse primero para qué servía cada paso.
El miedo al despido no viene de la tecnología. Viene de una decisión de gestión: automatizar sin reasignar. Las empresas del reportaje hicieron lo contrario. Antes de tocar el proceso, definieron qué iban a hacer con el tiempo que iban a liberar.
Lo que separa un buen proyecto de uno que fracasa a los seis meses
Hay una señal que aparece en casi todos los proyectos de automatización que terminan mal: nadie midió el proceso antes de cambiarlo.
Si no sabes cuánto tiempo tarda una cotización en llegar al cliente, no puedes saber si el nuevo sistema mejoró algo. Si no sabes cuántos errores produce el ingreso manual de facturas, no puedes saber si el costo del software se justifica.
Las empresas que lo hicieron bien midieron primero. No con metodologías complicadas. Con preguntas simples: ¿cuánto tiempo tarda esto?, ¿cuántas veces sale mal?, ¿quién lo hace y qué más podría estar haciendo?
Esa información es la que define si tiene sentido automatizar, qué parte automatizar, y qué pasa con las personas involucradas.
El rol del equipo antes de que llegue cualquier software
En todos los casos del reportaje, el equipo estaba involucrado desde el principio. No como receptores de un cambio decidido arriba, sino como parte del diagnóstico.
Eso no es solo una decisión ética. Es una decisión práctica. Las personas que ejecutan un proceso todos los días saben cosas que no aparecen en ningún organigrama: qué pasos se hacen diferente dependiendo del cliente, qué excepciones existen que nadie documentó, qué parte del proceso funciona bien aunque parezca ineficiente.
Sin ese conocimiento, el diseño del nuevo sistema es incompleto. Y un sistema incompleto genera más trabajo manual, no menos.
Qué significa mapear un proceso antes de automatizarlo
Mapear un proceso no es dibujar un flujograma bonito para una presentación. Es entender, paso a paso, quién hace qué, cuándo, con qué información, y qué pasa cuando algo sale mal.
Eso tiene un valor inmediato, incluso antes de automatizar nada: visibiliza ineficiencias que llevan años ahí sin que nadie las haya cuestionado. En muchos casos, el solo hecho de mapear el proceso permite simplificarlo y reducir la carga del equipo sin comprar nada.
La automatización viene después. Y cuando viene sobre un proceso ya rediseñado, funciona. En Crecer Digital trabajamos exactamente así: primero entendemos el proceso completo, identificamos la causa real del problema, y solo entonces definimos qué tiene sentido cambiar y cómo.
Lo que tienen en común los ocho casos
Ninguno de los ocho casos del reportaje empezó con una licitación de software. Ninguno contrató tecnología para resolver un problema que no había entendido bien.
Todos empezaron con una conversación interna: ¿qué nos está costando más caro en tiempo, en errores o en energía del equipo? Y desde ahí construyeron una respuesta que tenía sentido para su realidad, no para la realidad de una empresa genérica de otro país.
Eso es lo que hace que estos casos sean replicables. No la tecnología específica que usaron. La secuencia de decisiones que tomaron antes de usarla.
La pregunta que vale más que cualquier demo
Antes de evaluar cualquier herramienta, hay una pregunta que las empresas del reportaje se hicieron y que la mayoría no se hace: ¿qué pasa con el tiempo que vamos a liberar?
Si no hay respuesta para esa pregunta, el proyecto de automatización va a generar resistencia interna. Las personas que sienten que su trabajo está en riesgo no colaboran con el cambio. Y sin su colaboración, el proceso nuevo nunca funciona bien.
La respuesta no tiene que ser perfecta. Pero tiene que existir antes de empezar.
Si tienes un proceso que te está costando caro en tiempo o en errores y quieres entender qué hay detrás antes de tomar cualquier decisión, conversemos. Sin presentación de ventas, sin propuesta genérica. Solo una conversación de 30 minutos para ver si tiene sentido trabajar juntos.