Convertir una idea de IA en un proceso evaluable

«Quiero automatizar los informes», «quiero un asistente para el correo» o «quiero aplicar IA a los documentos» son puntos de partida, pero todavía no describen una oportunidad. Mezclan una posible solución con un conjunto de trabajos que quizá tienen entradas, responsables y resultados diferentes.

Aquí vas a convertir una idea de ese tipo en una unidad de trabajo evaluable. No documentarás todo el departamento ni producirás un manual del proceso: reunirás únicamente el alcance y la evidencia necesarios para someter la oportunidad a las decisiones del resto del curso.

Empieza sin nombrar la solución

Durante el primer análisis, sustituye «necesitamos una IA que...» por una frase que describa trabajo observable:

Cuando ocurre un hecho concreto, una persona o un equipo recibe unas entradas, realiza una secuencia de actividades y debe producir un resultado verificable.

Esta formulación obliga a identificar qué ocurre hoy. Todavía no presupone que la respuesta deba ser un chatbot, un agente, un modelo local o una integración.

Compara estas dos descripciones:

• «Queremos usar IA para los informes mensuales».
• «Cada cierre de mes, operaciones reúne datos de tres hojas y del ERP, corrige categorías, redacta comentarios sobre desviaciones y entrega un informe revisado a dirección».

La segunda permite preguntar por frecuencia, tiempo, errores, fuentes y decisiones. La primera solo permite hablar de herramientas.

Delimita la unidad que vas a evaluar

No necesitas dibujar un modelo formal ni registrar cada detalle operativo. Basta con responder siete preguntas que separen una unidad repetible de otras actividades próximas.

1. ¿Qué lo activa?

Identifica el hecho que pone en marcha una unidad de trabajo: llega un correo, termina el mes, se carga un documento, se aprueba una venta o un cliente presenta una solicitud.

Evita disparadores ambiguos como «cuando hace falta». Si nadie puede reconocer el inicio, tampoco será posible medir cuántos casos entran ni cuánto tardan en salir.

2. ¿Dónde termina?

Define una salida observable. «Documento revisado y archivado», «solicitud asignada con plazo» o «borrador de presupuesto listo para validar» son finales comprobables. «Información procesada» no permite saber si el trabajo está completo.

3. ¿Cuál es la unidad de trabajo?

Puede ser una factura, una solicitud, un expediente, un presupuesto o un informe. Elegirla evita mezclar actividades que pertenecen a procesos distintos.

Por ejemplo, «gestionar el correo» no es una sola unidad. Un mensaje puede ser una consulta comercial, una factura, una incidencia o una comunicación interna. Quizá comparten canal de entrada, pero no resultado ni responsable.

4. ¿Quién participa?

Anota quién ejecuta, revisa, decide y recibe el resultado. Una misma persona puede desempeñar varios papeles. Lo importante es saber dónde cambia la responsabilidad y quién resuelve una excepción.

5. ¿Qué entra y qué debe salir?

Enumera entradas reales: documentos, campos, mensajes, datos del ERP, plantillas o instrucciones. Después describe la salida con el nivel de precisión necesario.

No escribas «los datos necesarios» si todavía no sabes cuáles son. Esa expresión oculta una dependencia que aparecerá más tarde.

6. ¿Qué actividades se repiten?

Recoge la secuencia habitual sin intentar diseñar aún el proceso ideal. Incluye búsquedas, copias, esperas, validaciones y correcciones. Las esperas importan porque pueden explicar más retraso que la ejecución manual.

7. ¿Qué variantes y excepciones existen?

Una variante es una forma distinta de completar el proceso. Una excepción es un caso que no puede seguir el camino previsto y necesita tratamiento específico.

No agrupes toda variación bajo «cada caso es diferente». Comprueba qué cambia: formato del documento, dato ausente, criterio comercial, idioma, cliente, cuantía o necesidad de aprobación.

Construye una línea base observable

La línea base describe cómo funciona el proceso antes de intervenir. No necesita ser perfecta, pero debe separar datos conocidos de estimaciones.

Si no existe registro, toma una muestra pequeña. Por ejemplo, revisa veinte solicitudes recientes y anota entrada, pasos, duración aproximada, excepciones y salida. No conviertas una impresión en una cifra exacta.

Ejemplo hipotético: preparación de informes

Una consultoría B2B quiere «generar informes con IA». Al describir el proceso descubre cuatro trabajos distintos:

1. Extraer datos de proyectos y facturación.
2. Normalizar nombres y categorías.
3. Calcular indicadores mediante reglas conocidas.
4. Redactar un comentario sobre desviaciones para revisión del responsable.

La idea inicial parecía una tarea de generación. La descripción revela pasos de integración, limpieza, cálculo determinista y redacción asistida. Esta separación será importante más adelante, pero todavía no decides cómo resolverlos.

La línea base registra que el proceso ocurre una vez al mes, intervienen dos personas, los datos proceden de cuatro fuentes y las correcciones más frecuentes se deben a categorías inconsistentes. Ya existe un problema evaluable.

Separa el síntoma del problema

«Tardamos mucho» es un síntoma. Para convertirlo en problema, explica dónde se consume el tiempo y qué lo provoca.

• Si el equipo copia los mismos campos entre sistemas, el problema puede ser una integración ausente.
• Si cada documento llega con un formato diferente, el problema puede ser de interpretación.
• Si nadie conoce el estado de una solicitud, el problema puede ser de trazabilidad.
• Si una decisión cambia según quién la toma, el problema puede ser una regla no acordada.

No todos estos problemas requieren IA. La función de esta lección es hacerlos visibles para que puedan evaluarse.

Cuatro errores que invalidan la unidad

• Delimitar un departamento completo o un canal, en lugar de una unidad con inicio y final.
• Elegir una herramienta antes de identificar entradas, resultado y responsable.
• Describir solo el camino ideal y dejar las excepciones fuera del alcance sin declararlo.
• Presentar estimaciones como registros o resumir con una media que oculta los casos problemáticos.

Aplicación: redacta la primera parte de tu ficha

Elige una unidad real y produce una ficha breve con:

1. Nombre operativo del proceso.
2. Hecho que lo inicia.
3. Resultado que marca su final.
4. Unidad de trabajo.
5. Participantes y responsables.
6. Entradas y fuentes actuales.
7. Salidas esperadas.
8. Secuencia habitual.
9. Tres variantes o excepciones reales.
10. Línea base con volumen, frecuencia, tiempo, retrabajo y consecuencia.

Marca cada dato como registrado, estimado o desconocido. El ejercicio está completo cuando otra persona que conozca el trabajo reconoce la unidad, sus límites y la evidencia disponible sin que tengas que explicar una solución. Los procedimientos detallados, instrucciones de ejecución y variantes sin efecto en la decisión quedan fuera.

Primera evidencia para la ficha

Después de esta lección ya puedes completar:

• proceso;
• problema;
• volumen y frecuencia;
• inputs;
• outputs;
• línea base;
• participantes;
• primeras excepciones.

La siguiente decisión no consiste en elegir tecnología. Consiste en comprobar si este proceso debe automatizarse o si primero necesita simplificarse, estabilizarse o incluso dejar de existir.