El orden de las decisiones, de un dolor de negocio a algo que se queda funcionando
Una guía de método para empresas de 3 a 50 M€ que ya han probado alguna herramienta y no han conseguido que nada llegue a producción. Por dónde se empieza, cómo se prioriza, cómo es un piloto que sirve y qué tiene que pasar para que sobreviva.
La secuencia se repite en casi todas las empresas medianas. Alguien prueba una herramienta y le funciona. Se compra para el equipo. Durante tres semanas hay entusiasmo. Al tercer mes la usan dos personas, nadie sabe decir qué ha mejorado y la conversación se ha desplazado a la siguiente herramienta.
No es un problema de tecnología: la herramienta hacía lo que prometía. Es un problema de orden. Se empezó por la respuesta —la herramienta— sin haber escrito la pregunta —qué duele y cuánto—. Y una respuesta sin pregunta no se puede evaluar, así que no se puede defender cuando llega la primera semana ocupada.
Una tecnología cambia una tarea. Varias juntas cambian el sistema.
No es negociable y no se puede recorrer al revés. Cada paso condiciona al siguiente, y saltarse uno explica casi todos los proyectos que no llegan.
Cuatro decisiones, en este orden. Si te descubres hablando de una herramienta antes del paso 4, has vuelto al principio.
«Nos cuesta , y hoy eso son horas al mes o € al año.» Si no puedes poner la cifra, todavía no es un caso: es una molestia.
Una tarea concreta, de una persona concreta, en un proceso concreto. «Mejorar la atención al cliente» no es un caso de uso; «redactar el primer borrador de respuesta a una reclamación de garantía» sí lo es.
Dónde vive, quién lo mantiene, en qué estado está y quién puede autorizar su uso. Sin esas cuatro respuestas no se sigue.
Se elige la última, y se elige contra los tres pasos anteriores. Es la decisión más fácil de cambiar y por eso es la última: cambiarla no invalida el trabajo hecho.
En una empresa mediana el valor rara vez está donde más se habla de él. Estos cuatro sitios comparten una característica: el trabajo ya está escrito en alguna parte, así que se puede medir antes y después.
Presupuestos, escandallos, criterios de aceptación, respuestas técnicas. Cuando alguien lleva veinte años y todo pasa por él, el riesgo no es de eficiencia: es de continuidad. Recoger ese criterio en algo consultable vale por sí solo, con IA o sin ella.
Ofertas, pliegos, reclamaciones, dudas de siempre. El primer borrador es donde se va el tiempo; la revisión sigue siendo humana y debe seguir siéndolo. Aquí se mide fácil: tiempo hasta el primer borrador y número de vueltas.
Del albarán al ERP, del correo al CRM, del parte de trabajo a la hoja de horas. No es el caso más vistoso y suele ser el más rentable, porque el error que se elimina cuesta más que el minuto que se ahorra.
Contratos, facturas de proveedor, normativa, pliegos de licitación. Trabajo lento, sujeto a plazos y con consecuencias si se escapa algo. Empieza por extraer y comparar, nunca por decidir.
Puntúa cada candidato de 1 a 5 en las cinco columnas y ordena por la suma. La quinta columna es la que más pilotos ha salvado y la que casi nadie incluye.
| Criterio | Qué se pregunta | Puntúa alto si… |
|---|---|---|
| Valor | ¿Cuánto vale resolverlo, en horas o en euros al año? | La cifra del paso 1 es grande y alguien de finanzas la reconoce. |
| Medibilidad | ¿Puedes medir el antes y el después sin montar nada nuevo? | El dato ya se registra hoy, aunque sea a mano. |
| Esfuerzo | ¿Qué hace falta para tener algo funcionando en noventa días? | No requiere integrar sistemas ni migrar datos para empezar. |
| Riesgo | ¿Qué pasa si el resultado es malo y nadie lo detecta? | El error es visible, reversible y lo revisa una persona antes de salir. |
| Dueño | ¿Quién responde de que esto se use dentro de seis meses? | Tiene nombre, está dentro del proceso y le beneficia que funcione. |
La columna del dueño no es una formalidad. Un caso sin dueño interno se sostiene mientras dura el entusiasmo del proyecto y se cae exactamente cuando el proyecto termina. Si nadie de dentro quiere ser el dueño, esa es información sobre el caso, no sobre las personas.
Casi ninguna implantación se frena por el modelo. Se frenan porque el dato que hacía falta estaba en cinco sitios, con tres nombres distintos, mantenido por nadie en concreto y con una parte que no se podía usar. Estas cuatro preguntas se responden por escrito antes de mirar ninguna herramienta.
Noventa días son suficientes para saber si algo funciona y demasiado poco para que se convierta en un proyecto eterno. La fecha de final se pone el primer día, y con ella el criterio de parada.
Un caso, una persona, un número. No dos casos «ya que estamos»: el segundo caso duplica el trabajo y divide la atención justo cuando hace falta entera.
El número de hoy, medido de verdad y no estimado en una reunión: cuánto se tarda, cuántas vueltas hace, cuántos errores se cuelan. Sin línea base no hay mejora, hay opiniones.
Algo que la persona que hace ese trabajo usa de verdad en su día. Con revisión humana obligatoria y un sitio evidente donde decir «esto ha salido mal».
Las correcciones que salen del uso, no de una lista de mejoras escrita a priori. Aquí se descubre lo que el proceso hacía y nadie había contado.
El mismo número de la semana 1, medido igual. Y una de tres decisiones escritas: se extiende, se ajusta y se prorroga una vez, o se para. Parar bien es un resultado.
Un piloto que funciona no es un sistema que se queda. Estas cinco condiciones separan lo uno de lo otro, y las cinco son de organización, no de tecnología.
La quinta condición es la que más se salta y la que convierte una mejora en una dependencia. Un sistema que solo entiende quien lo montó no es un activo de la empresa: es un riesgo con buena cara.
La resistencia casi nunca es a la herramienta. Es al mensaje implícito, que la gente lee antes de que nadie lo diga: si esto hace mi trabajo, ¿para qué estoy yo? Mientras esa pregunta no tenga respuesta pública, todo lo demás es teatro. Y la respuesta tiene que ser verdad, porque se comprobará.
Formar no es un curso genérico para toda la plantilla. Es ajustar lo que cada persona necesita saber a lo que de verdad hace: quién usa el sistema, quién revisa su salida, quién decide con ella y quién responde si sale mal. Además de ser lo que funciona, es lo que pide la norma europea, y desde antes de lo que casi todo el mundo cree.
Para qué sirve, para qué no, cómo se reconoce una salida mala y qué hacer con ella. Con ejemplos de su propio trabajo, no genéricos.
Qué mirar y en qué orden, dónde suele fallar el sistema y cuál es el umbral a partir del cual se escala. La revisión sin criterio se convierte en un clic.
Qué se puede afirmar con esto y qué no, qué obligaciones aplican y de qué responde la empresa. Es la formación más corta y la que más se salta.
Dos obligaciones del Reglamento Europeo de IA afectan hoy a cualquier empresa que use estas herramientas, sea del tamaño que sea: la de alfabetización en IA de la plantilla, vigente desde febrero de 2025, y la de transparencia, que obliga a avisar cuando alguien está interactuando con una IA y a etiquetar cierto contenido sintético.
No es una capa que se añade al final. Decidir dónde entra la revisión humana, qué datos se pueden usar y qué se le dice al cliente son decisiones de diseño del caso de uso: tomarlas en el paso 2 cuesta una conversación; tomarlas después de estar en producción cuesta rehacerlo.
Guía en PDF, con la matriz de priorización y el checklist previo
La guía entera, con la matriz de priorización en blanco y el checklist de las doce preguntas previas a firmar cualquier herramienta.
Todo lo que hay en el archivo está también en esta página, abierto y sin pedir nada. El correo es para mandarte la versión que puedes imprimir y llevar a una sesión.
Listo. Aquí lo tienes.
Descargar la guía en PDFSi el archivo no se abre, guarda este enlace: seguirá funcionando.
Usamos cookies para entender y mejorar la web
Analizamos de forma agregada cómo se usa quether.com para mejorar la experiencia. Puedes aceptarlas o rechazarlas. Más detalle en nuestra política de cookies.
