En esta nota
En resumen
- El orden correcto es proceso primero, herramienta después. Al revés se compran suscripciones que nadie abre.
- Un buen primer candidato cumple tres condiciones: se repite mucho, alguien puede juzgar si la salida está bien y un error sale barato.
- No hace falta programar. Hace falta poder describir la tarea con frecuencia, tiempo y responsable.
- La mitad difícil no es construir: es la adopción. Un sistema que el equipo no usa está construido, no implementado.
Hay una escena que se repite en casi toda empresa que "está implementando IA". Alguien del equipo prueba una herramienta, arma una demo que impresiona, se aprueba una suscripción para diez personas y durante dos semanas hay entusiasmo. Al mes la usan tres. A los tres meses, uno. La suscripción sigue debitándose.
El diagnóstico habitual es que faltó capacitación. Casi nunca es eso. Lo que falló fue el orden: se empezó por la herramienta en vez de empezar por el trabajo.
El orden importa más que la herramienta
Una herramienta de IA no resuelve un problema: acelera una tarea. Si esa tarea no estaba definida antes, lo que se acelera es la confusión.
Por eso la primera pregunta no es qué herramienta uso sino qué tarea repetitiva le está comiendo horas a alguien de mi equipo todas las semanas.
Esa pregunta parece obvia y casi nadie la contesta con precisión. "Perdemos tiempo en administración" no sirve. "Todos los lunes alguien dedica tres horas a pasar los pedidos que llegaron por WhatsApp a la planilla de producción" sí sirve: se puede medir, se puede mejorar y se puede saber si funcionó.
Automatizar algo mal pensado es automatizar el caos. Si no podés explicarle el sistema a un amigo en una servilleta, no se lo expliques a la máquina tampoco: vas a obtener basura prolija.
Seba Chuffer · LAB AI
Cómo elegir el primer proceso
No todos los procesos son buenos candidatos. El primero conviene que cumpla tres condiciones al mismo tiempo.
1Se repite mucho
Algo que pasa cinco veces por día vale más que algo que pasa una vez por mes, aunque lo segundo lleve más tiempo cada vez. La frecuencia es lo que hace que el ahorro se note, y también lo que permite corregir rápido: si el sistema falla, te enterás el mismo día y no dentro de un trimestre.
2Alguien puede juzgar si el resultado está bien
Este es el filtro que más candidatos elimina. Si nadie en la empresa puede mirar la salida y decir "esto está bien" o "esto está mal", no hay forma de saber si el sistema funciona. Automatizar algo que nadie puede evaluar no es eficiencia: es generar volumen sin control.
Y el criterio tiene que ser explícito. "Que esté bien redactado" no sirve. "Que incluya el plazo de entrega, el precio con IVA y el nombre correcto del contacto" sí.
3Un error no es catastrófico
Para el primer proceso conviene un lugar donde equivocarse sea barato. Redactar un borrador que después alguien revisa es un buen primer caso. Mandar automáticamente una cotización a un cliente, no.
Si no podés escribir la tarea en una frase que incluya cada cuánto pasa, cuánto tiempo lleva y quién la hace, todavía no estás listo para automatizarla. Escribir esa frase es parte del trabajo, no un trámite previo.
Los candidatos que parecen buenos y no lo son
| Tentación | Por qué falla |
|---|---|
| Lo más visible para la dirección | Se elige por impacto político y no por frecuencia. Suele ser algo que pasa poco, así que el ahorro nunca se nota. |
| Lo más difícil, "para probar de verdad" | Si el primer intento es el más complejo, el fracaso llega antes que el aprendizaje y quema el presupuesto del año. |
| Lo que ya hace bien una persona con experiencia | El estándar de comparación es altísimo y el resultado siempre parece peor. |
| Un proceso que nadie describió nunca | Automatizar algo que solo vive en la cabeza de una persona empieza por documentarlo, y ese trabajo aparece a mitad de camino sin estar presupuestado. |
La primera fila es la más común en empresas con varios niveles de decisión. La cuarta es la más común en empresas chicas, donde mucho conocimiento vive en la práctica de quien lo hace y nunca se escribió.
Recién ahora, la herramienta
Con el proceso elegido y descrito, la elección de herramienta se vuelve casi obvia, y bastante menos importante de lo que parecía. Para la mayoría de las tareas de una pyme (responder consultas repetidas, preparar borradores, clasificar lo que entra, extraer datos de documentos) hay varias opciones que sirven igual.
No hace falta programar para la mayoría de los casos. Saber programar sube el techo de lo que se puede construir, pero no es la puerta de entrada. La barrera real no es técnica: es tener claro qué se quiere que pase.
Esto cambió hace poco y todavía no terminó de asimilarse. Durante cincuenta años, para que una computadora hiciera algo había que hablarle en su idioma. Hoy entiende el nuestro, con nuestros rodeos y nuestra falta de precisión. La división entre los que saben tecnología y los que no se está corriendo hacia otro lado: entre los que saben explicar con precisión lo que necesitan y los que no.
La parte que nadie cuenta: la adopción
Construir el sistema es la mitad fácil. La otra mitad es que el equipo lo use, y ahí se cae la mayoría de los proyectos.
Un sistema que obliga a la gente a cambiar de herramienta, abrir otra pestaña o aprender una interfaz nueva compite contra la costumbre, y la costumbre gana casi siempre. Los que sobreviven son los que se meten donde el trabajo ya sucede: en el mismo WhatsApp, en la misma planilla, en el mismo correo.
Un proceso automatizado que el equipo no usa no está implementado. Está construido, que es otra cosa.
Hay una manera bastante confiable de conseguir adopción sin pelearla: elegir una tarea que al equipo le moleste de verdad. No la más estratégica ni la más vistosa. La más odiada. Cuando esa tarea desaparece, nadie tiene que empujar nada.
Cómo saber si funcionó
Antes de empezar, anotá el número de partida: cuántas horas lleva hoy, cuántos errores tiene, cuánto se tarda en responder. Sin ese número, dentro de tres meses la discusión va a ser sobre sensaciones.
Y conviene medir algo más que el tiempo ahorrado: cuántas veces alguien tuvo que corregir la salida. Si la corrección es constante, el proceso no está resuelto, está mudado de lugar.
De las cuatro etapas de un primer proyecto (describir, armar, corregir, enseñar), la que más se subestima es corregir. Todo el mundo presupuesta el armado. Casi nadie presupuesta las idas y vueltas, que en un primer proyecto son más trabajo que el armado mismo.
Qué sigue quedando en manos humanas
Vale decirlo porque ordena las expectativas de todo el proyecto. Con la ejecución cada vez más barata, tres cosas siguen siendo trabajo de personas:
- El criterio. Decidir qué sirve, qué se descarta, qué es aceptable mandarle a un cliente.
- La pregunta. Saber qué problema vale la pena resolver, que es distinto de saber resolverlo.
- El sistema. Pensar cómo se conectan las piezas antes de construir nada.
Todo lo demás (el primer borrador, la clasificación, el resumen, el código) la máquina lo hace más rápido. El trabajo pasa a ser dirigir, no ejecutar. Y dirigir mal un recurso rápido produce mucho trabajo inútil en poco tiempo.
El resumen en cuatro pasos
- Elegí un proceso, no una herramienta. Que se repita seguido, que alguien pueda juzgar el resultado y que un error salga barato.
- Escribilo con frecuencia, tiempo y responsable. Si no se puede escribir, se documenta primero.
- Construí lo mínimo que lo resuelva y ponelo donde el trabajo ya ocurre.
- Medí la corrección, no solo el ahorro. Un sistema que hay que corregir siempre no ahorró nada.
Esto es exactamente lo que hacemos en el LAB
Doce semanas en vivo donde cada participante elige los tres procesos de mayor impacto de su negocio y sale con esos sistemas funcionando. No con apuntes: con los procesos andando, y con mentores que revisan lo que construís y corrigen el rumbo antes de que el proyecto se apague solo.
Conocer el LAB AI ›Preguntas frecuentes
¿Por dónde se empieza a implementar IA en una empresa?
Por un proceso, no por una herramienta. Conviene elegir uno que se repita muchas veces por semana, que hoy consuma tiempo de alguien y cuyo resultado se pueda revisar. Si nadie puede decir si el resultado está bien o mal, no se puede automatizar con criterio.
¿Hace falta saber programar para implementar IA en un negocio?
No para la mayoría de los casos. Las tareas que más tiempo consumen en una pyme (responder consultas repetidas, preparar propuestas, clasificar lo que entra) se resuelven sin escribir código. Lo que hace falta es saber explicar paso a paso lo que se necesita.
¿Cuánto tarda en verse el resultado?
Un primer proceso funcionando toma semanas, no meses, si está bien elegido. Lo que toma tiempo no es construirlo sino que el equipo lo adopte: un sistema que nadie usa no cuenta como implementado.
¿Cuál es el error más común al empezar?
Elegir el proceso más visible para la dirección en vez del más frecuente. Un caso vistoso que ocurre una vez por mes nunca llega a mostrar ahorro, y cuando se evalúa el proyecto no hay números que defiendan seguir.
Escrito a partir de lo que vemos en las sesiones del LAB AI, el programa en vivo donde cada participante implementa IA en los procesos reales de su negocio.