Aprendizajes de automatizar una empresa: lo que aprendimos con la nuestra

Semana 2 — lecciones en carne propia

Hay una pregunta que aparece en casi toda primera conversación con un dueño de empresa: "¿ustedes esto ya lo hicieron?". Es una buena pregunta, y es la única honesta. Los aprendizajes de automatizar una empresa no se consiguen leyendo sobre automatización ni armando un taller. Se consiguen cuando la operación que se rompe es la propia, cuando el proceso que falla lo firmaste tú y no hay a quién pasarle la factura.

En DÉCIMA decidimos que la primera empresa donde íbamos a aplicar el modelo fuera la nuestra. No como demostración comercial, sino como condición de trabajo: si no éramos capaces de hacer que la IA ejecutara nuestra propia operación, no teníamos por qué proponérselo a nadie más. Este texto es lo que salió de ahí, incluido lo que salió mal.

Usar IA y operar con IA no son la misma cosa

Casi todas las empresas que conocemos ya usan IA. Alguien del equipo redacta correos con un asistente, alguien resume una junta, alguien genera una imagen para una presentación. Eso es uso individual: la herramienta acelera a una persona, y cuando esa persona no está, el trabajo no ocurre.

Operar con IA es otra cosa. Significa que hay trabajo que sucede sin que nadie lo inicie a mano, que se ejecuta con la misma calidad el martes que el domingo, y que deja rastro de lo que hizo. La diferencia no es de herramientas, es de arquitectura. Una empresa puede tener a todo su equipo usando IA todos los días y seguir teniendo exactamente la misma capacidad operativa del año pasado.

Ese fue el primer corte de realidad. Cuando empezamos a revisar nuestra propia operación con esa lupa, descubrimos que teníamos mucho uso de IA y muy poca ejecución de IA. Estábamos en la misma situación que el mercado al que le queríamos vender.

Primer aprendizaje: el cuello de botella nunca fue la tecnología

La expectativa era que la parte difícil iba a ser técnica. No lo fue. La parte difícil fue describir con precisión qué hace una persona cuando hace su trabajo.

Tomemos algo aparentemente simple: generar un texto para el blog. Descrito en una junta, es una tarea de un renglón. Descrito para que se ejecute sin supervisión, aparecen veinte decisiones que nadie había escrito nunca: de dónde sale el tema, quién decidió que ese tema va antes que otro, qué se puede afirmar y qué no, qué pasa si dos procesos toman el mismo tema al mismo tiempo, quién revisa, qué se hace si la revisión no pasa, dónde queda el material rechazado.

Ninguna de esas decisiones estaba documentada. Vivían en la cabeza de alguien. Y ese es el patrón que después encontramos en prácticamente todas las operaciones que revisamos: el conocimiento que sostiene el proceso no está en el proceso, está en las personas que lo ejecutan. Automatizar obliga a sacarlo de ahí, y ese ejercicio duele antes de servir.

Vale la pena decirlo sin adornos: buena parte del trabajo de automatizar una empresa no es trabajo de IA. Es trabajo de claridad operativa. La IA solo hace visible lo que ya estaba desordenado.

Segundo aprendizaje: automatizar un proceso roto lo rompe más rápido

Hay una tentación fuerte cuando el proceso ya está descrito: automatizarlo tal cual está. Es la vía rápida y es la vía equivocada.

Un proceso manual malo tiene un amortiguador natural: la persona que lo ejecuta. Cuando algo no cuadra, se detiene, pregunta, corrige sobre la marcha. Ese criterio humano estaba tapando el defecto sin que nadie lo notara. Cuando ese mismo proceso se ejecuta solo, el amortiguador desaparece y el defecto sale a la superficie multiplicado por la frecuencia con la que ahora corre.

Nos pasó. Dimos por bueno un flujo que en la práctica dependía de que alguien revisara un paso intermedio "por si acaso". Sin esa revisión, el flujo no fallaba de forma ruidosa —eso habría sido fácil de detectar—, fallaba de forma silenciosa: entregaba resultados plausibles pero mal fundados. Ese es el peor modo de falla posible, porque se descubre tarde.

De ahí salió una regla que hoy aplicamos antes de tocar nada: primero se arregla el proceso, después se automatiza. Si el proceso no se sostiene en manos de una persona con criterio, no se va a sostener solo.

Tercer aprendizaje: el humano no sale del proceso, cambia de lugar

La versión de la IA que circula en el mercado promete quitar personas. Nuestra experiencia con la propia operación apunta a lo contrario, y no por razones sentimentales sino por diseño.

Cuando la ejecución se automatiza, el trabajo humano no desaparece: se concentra. Deja de estar repartido a lo largo de todo el proceso y se acumula en dos puntos concretos: la definición de qué se va a hacer y la aprobación de lo que se hizo. Ambos puntos requieren criterio, contexto y responsabilidad. Ninguno de los dos se delega.

En nuestra operación de contenido, por ejemplo, un agente toma el tema de un calendario editorial vivo, otro redacta el material, otro lo revisa contra las reglas de la marca. Nada de eso se publica sin que una persona lo apruebe. No porque el sistema no pueda publicar solo —técnicamente puede—, sino porque la responsabilidad de lo que la empresa dice en público no es delegable a un proceso.

Eso es lo que queremos decir cuando decimos que las personas imaginan y la IA ejecuta. No es una frase de venta. Es la descripción literal de cómo quedó repartido el trabajo cuando terminamos de reorganizarlo: las personas deciden el qué y el si, el sistema se encarga del cómo y del cuándo.

Cuarto aprendizaje: lo que no se documenta no se puede volver a usar

El error más caro de los primeros meses fue tratar cada automatización como un proyecto terminado. Se construía, funcionaba, se pasaba a la siguiente. Semanas después, cuando algo se rompía, nadie se acordaba de por qué se había tomado tal decisión.

Cambiar eso costó poco y rindió mucho. Cada pieza que construimos hoy queda escrita: qué hace, qué no debe hacer, con qué reglas opera, qué pasa cuando falla, quién la aprueba. No es burocracia. Es lo que convierte un proceso automatizado en un activo en lugar de un truco que solo su autor entiende.

Y tiene una consecuencia comercial directa: lo que se construye una vez con criterio se vuelve a montar más rápido y más barato la segunda vez. Ese es el modelo con el que trabajamos con clientes hoy, y lo aprendimos porque primero nos costó caro no hacerlo en casa.

Quinto aprendizaje: la resistencia no viene de donde uno espera

Dábamos por hecho que la fricción iba a ser el miedo a ser reemplazado. No fue eso, o al menos no principalmente.

La fricción real vino de otro lado: de que automatizar una tarea obliga a hacer explícito un criterio que hasta entonces cada quien aplicaba a su manera. Mientras el proceso es manual, dos personas pueden resolver el mismo caso distinto y ninguna de las dos está equivocada; hay margen, hay estilo, hay costumbre. Cuando el proceso se escribe para que se ejecute solo, hay que elegir una de las dos formas y decir en voz alta por qué. Esa conversación, que suena administrativa, es en realidad una discusión sobre cómo debe trabajar la empresa. Y esas discusiones se venían posponiendo desde hacía años.

Lo mismo aplica al otro extremo. Un proceso automatizado deja rastro de todo lo que hace, y ese rastro también revela cuánto trabajo se estaba haciendo dos veces, cuánto se estaba haciendo sin que nadie lo pidiera y cuánto simplemente no se estaba haciendo. No todo el mundo quiere esa visibilidad al principio.

La lección práctica es sencilla: conviene tratar la automatización como un cambio de acuerdos operativos, no como una instalación. Quien vaya a trabajar con el proceso tiene que estar en la conversación donde se define, no enterarse cuando ya corre.

Los aprendizajes de automatizar una empresa que no salen en los talleres

Si tuviéramos que resumir en qué se parecen todos estos aprendizajes de automatizar una empresa, sería en esto: ninguno es un problema de IA.

El primero es un problema de documentación. El segundo, de diseño de proceso. El tercero, de gobierno y responsabilidad. El cuarto, de disciplina. El quinto, de acuerdos entre personas. La parte propiamente tecnológica —conectar las piezas, hacer que corran, que se recuperen de un error— es la que menos tiempo consumió y la que menos discusión generó.

Por eso desconfiamos del contenido que presenta la adopción de IA como una decisión de herramienta. La pregunta no es cuál usar. La pregunta es qué parte de tu operación está lo suficientemente clara como para que algo la ejecute sin ti. En la mayoría de las empresas —incluida la nuestra al arrancar— la respuesta honesta es: menos de lo que uno creería.

Hay un último aprendizaje que no cabe como sección aparte pero conviene decir: la adopción por capas funciona y la adopción de golpe no. Cada vez que intentamos automatizar un bloque grande de operación de una sola vez, el resultado fue una pieza frágil que nadie entendía. Cada vez que empezamos por una tarea acotada, con un criterio de éxito claro y un punto de aprobación humano, la pieza aguantó y se pudo ampliar después.

Cómo empezar sin volar tu operación

Si esto te resuena y quieres avanzar por tu cuenta, hay cuatro cosas que puedes hacer esta semana sin contratar a nadie.

Elige una tarea, no un área. "Automatizar ventas" no es un punto de partida, es un deseo. "Que el seguimiento a una cotización sin respuesta salga solo a las 48 horas" sí lo es. La tarea tiene que ser lo bastante chica como para describirla completa en una página.

Escríbela como si se la fueras a explicar a alguien que entra mañana. Incluye las excepciones. Sobre todo las excepciones: ahí es donde vive el criterio que hoy nadie escribió y que es exactamente lo que hace fallar a los pilotos.

Define quién aprueba y en qué punto. Antes de automatizar nada, decide dónde queda el humano. Si la respuesta es "en ningún lado", el proceso probablemente no está listo para salir de manos de una persona.

Mide algo desde el primer día. No hace falta un tablero. Hace falta saber, antes de empezar, qué número debería moverse y cuál es su valor hoy. Sin eso, en tres meses vas a tener una automatización que nadie sabe si sirvió.

Ese ejercicio, hecho con honestidad, ya te da más claridad que la mayoría de los diagnósticos que se venden en el mercado. Y si al hacerlo descubres que no puedes describir la tarea sin ambigüedad, eso también es un resultado: acabas de encontrar dónde está tu verdadero cuello de botella. [LINK_INTERNO]

Dónde queda el diagnóstico en todo esto

La razón por la que insistimos tanto en este tema es que aplicamos el modelo primero en casa y sabemos lo que cuesta. Un consultor que habla de IA sin correrla en su propia operación está trabajando con teoría. Nosotros preferimos que nuestra empresa sea el primer caso y que el argumento se sostenga solo, sin datos prestados ni promesas.

Nada de lo anterior requiere reestructurar una empresa ni cambiar su plantilla. Requiere claridad sobre qué se hace, en qué orden y con qué criterio. La automatización viene después, y viene fácil cuando esa parte está resuelta.

Si quieres tener una lectura ordenada de en qué punto está tu operación antes de mover nada, el diagnóstico LeanAI recorre los mismos ejes con los que revisamos la nuestra y te devuelve dónde estás parado. Es gratuito y es el lugar por donde nosotros empezaríamos.