Capítulo 10 de 11 8 secciones 5 min

Qué le pides a tu empresa y cómo lo presentas sin que te digan que no

El proyecto no se cae en la parte técnica. Se cae en la reunión donde se decide, y eso sí lo puedes preparar.

Preséntalo como un problema que ya cuesta tiempo o plata hoy, no como una tecnología. Ponle un número al dolor actual, propón algo pequeño y acotado en vez de una transformación, di cómo se va a medir y cuándo se sabrá si funcionó, y deja escrito qué pasa si no funciona. Nadie aprueba IA: se aprueban problemas concretos con salida clara 🎯

La reunión donde se cae todo

Te va a pasar esto: entiendes el tema, ves clarísimo dónde ayudaría, lo propones y te dicen "interesante, lo vemos más adelante". Y más adelante no llega.

No fue porque no te entendieran. Fue porque presentaste una tecnología y en esa mesa se aprueban problemas 🙂

Empieza por el dolor, no por la solución

Esta es la única regla que de verdad cambia el resultado.

Todo lo que empieza con "deberíamos usar IA para..." se lee como un gasto en algo nuevo. Todo lo que empieza con "esto nos está costando X..." se lee como recuperar algo que ya estamos perdiendo. Son la misma propuesta y no se deciden igual.

Lo que se postergaLo que se aprueba
"Deberíamos implementar IA en atención al cliente" "Recibimos unos 300 reclamos al mes y cada uno tarda dos días en llegar al área correcta. Eso son cuatro días de reloj antes de que alguien lo atienda."
"La IA puede ayudarnos con las facturas" "Dos personas dedican tres días al mes a pasar facturas al sistema a mano. Son seis días de trabajo que no es trabajo."

Fíjate que en la columna de la derecha ni siquiera aparece la palabra IA. Aparece después, cuando ya todos están de acuerdo en que el problema existe 🎯

Ponle un número, aunque sea aproximado

No hace falta un estudio. Hace falta un número que puedas defender.

"Dos personas, tres días al mes" es un número. "Nos toma mucho tiempo" no lo es. La diferencia es que el primero se puede comparar con el costo de arreglarlo y el segundo no se puede comparar con nada.

Y si no sabes el número, esa es tu primera tarea y es gratis: pregúntale a quien lo hace. Nadie va a poner plata para arreglar algo que no está medido, y con razón.

Pide algo chiquito, no una transformación

Una transformación digital es cara, larga y da miedo. Un piloto acotado es barato, corto y se puede parar.

Lo que se aprueba tiene esta forma: un proceso, un área, un plazo corto, y un criterio escrito de qué contaría como que funcionó.

Y esto es importante y casi nadie lo hace: di qué pasa si no funciona. "Si a los dos meses no bajamos el tiempo a la mitad, lo paramos." Suena a que le estás quitando fuerza a tu propia propuesta y es exactamente al revés: le quita el miedo a quien decide, porque le enseñas la puerta de salida 🚪

Las cinco preguntas para un proveedor

Si van a contratar a alguien de fuera, estas cinco separan a quien sabe de quien vende. Son las seis de la portada, aterrizadas a una cotización:

  1. ¿Qué datos míos necesitas y de cuándo tienen que ser? Si no pregunta por tus datos antes de cotizar, está cotizando a ciegas.
  2. ¿Cómo vamos a medir si funcionó, y quién lo mide? Que el criterio quede escrito antes, no después.
  3. ¿Qué pasa cuando se equivoca? ¿Quién revisa y con qué frecuencia? Si la respuesta es que no se equivoca, ahí terminó.
  4. ¿A dónde van nuestros datos y quién los guarda? Lo del capítulo 7, que en Perú además tiene ley.
  5. ¿Qué tiene que poner mi equipo y cuántas horas? Si dice que ninguna, no hizo esto antes.

Ninguna es técnica. Las cinco las puedes hacer tú sin saber programar, y con las cinco vas a saber más de esa propuesta que la mayoría de la gente en la mesa 🙂

Y si lo que falta es que el equipo entienda

Hay una situación muy común y conviene nombrarla, porque tiene una salida distinta.

A veces el problema no es que falte un proyecto. Es que en el área nadie entiende lo suficiente como para saber qué pedir, y entonces cualquier propuesta que llegue de fuera se acepta o se rechaza por corazonada. Ahí un piloto no arregla nada, porque el criterio para evaluarlo tampoco existe.

Cuando ese es el caso, lo que hace falta primero es que el equipo tenga el mismo mapa que acabas de tener tú leyendo esto, y aplicado a lo que ustedes hacen. Eso no se resuelve mandando a una persona a un curso: se resuelve con el equipo completo y con los casos de ustedes sobre la mesa.

Si tu caso es ese, la capacitación in company se arma exactamente así, según el equipo y lo que quieren resolver. Y si prefieres conversarlo antes de decidir nada, esa conversación es gratis y sin compromiso 🐣

Lo que te llevas

  • Se aprueban problemas, no tecnologías. Empieza por el dolor.
  • Ponle un número al dolor de hoy, aunque sea aproximado.
  • Pide un piloto chiquito con criterio escrito, no una transformación.
  • Di qué pasa si no funciona. Le quita el miedo a quien decide.
  • Cinco preguntas al proveedor, ninguna técnica, todas incómodas para quien no hizo la tarea.

Comprueba que se entendió

Comprueba que lo tienes

Vas a proponer tu primer proyecto de IA en la empresa. ¿Cómo conviene plantearlo?

  • Un problema concreto que ya cuesta plata o tiempo hoy, con un número medible al lado
  • Una presentación sobre cómo la IA va a transformar el sector
  • Un pedido de presupuesto para explorar opciones con un proveedor
  • Una lista de todo lo que la IA podría hacer en la empresa

Y ya está. Nos queda el último, que es corto y es para ti: por dónde sigues 🐥

¿Tienes alguna duda o consulta?