Casos de uso de IA — Módulo 3: el baseline
Tercer módulo de la Metodología de casos de uso: medir contra qué se comparará todo. Para el arquetipo A, cómo medir el proceso actual (costo por transacción, tasa de error, tiempo de ciclo) sin caer en las trampas del autoreporte; para el arquetipo B, cómo construir un contrafactual honesto cuando no hay nada que medir. Sin baseline no hay ROI — solo esperanza.
☰ Índice del contenido
Salimos del módulo 2 con candidatas calificadas. La tentación ahora es obvia: construir un prototipo. Resiste. El paso 4 de la metodología existe porque los pilotos que no muestran impacto comparten casi siempre una misma omisión: nunca midieron el punto de partida, así que cuando alguien preguntó “¿funcionó?”, no había contra qué responder. El baseline (línea base: el estado medido del mundo antes de tu intervención) suele ser el paso más barato de toda la metodología — típicamente días de trabajo, aunque a veces exige instrumentar el proceso — y el que más casos salva o mata con justicia.
Y aquí los dos arquetipos divergen de verdad por primera vez. En el arquetipo A el baseline se mide: el proceso existe, ocurre miles de veces al mes, deja rastros. En el arquetipo B el baseline se construye: no hay proceso, así que hay que estimar honestamente qué pasa en el mundo donde no haces nada. Son habilidades distintas y este módulo enseña las dos.
La tesis del módulo
El ROI de un caso de uso vale exactamente lo que vale su baseline. Un ahorro contra un proceso que nadie midió es un número inventado con decimales; un ingreso proyectado sin contrafactual es una fantasía con formato de planilla. Medir el baseline cuesta días; no medirlo cuesta descubrir en producción que no hay forma de demostrar que el sistema sirvió.
Arquetipo A: medir el proceso actual
El baseline del arquetipo A son cuatro números. Ni más — no necesitas un estudio de consultoría — ni menos:
| Número | Qué es | Cómo se obtiene |
|---|---|---|
| Volumen | Unidades procesadas por mes | Logs del sistema, conteo de bandeja |
| Tiempo por unidad | Minutos de trabajo humano por unidad | Muestreo observado (no autoreporte) |
| Costo por unidad | Tiempo × costo por hora cargado | Tiempo × (sueldo + cargas) / horas |
| Tasa de error | % de unidades mal procesadas | Auditoría de muestra aleatoria |
Con eso se deriva la cifra que gobierna el resto del curso: el costo por transacción del statu quo. Un quinto número — el tiempo de ciclo (cuánto espera la unidad de punta a punta, no cuánto se trabaja en ella) — importa cuando el valor incluye velocidad: una cotización que tarda 3 días no tarda 3 días de trabajo, tarda 20 minutos de trabajo y 3 días de cola.
Las tres trampas de la medición
- El autoreporte. “¿Cuánto tardas por correo?” produce respuestas sistemáticamente infladas o desinfladas según lo que la persona crea que harás con el dato (¿me van a automatizar? → tardo muchísimo; ¿me van a evaluar? → tardo poquísimo). La alternativa barata: muestreo observado — toma unidades al azar (30 es un piso exploratorio, no una garantía estadística; si los tiempos varían mucho, o hay tipos de tarea muy distintos, mide más y por tipo) y mide de verdad. Y elige bien el estadístico: para la carga total usa la media (o la media ponderada por tipo de tarea), porque el total es volumen × media — los correos monstruosos de 40 minutos existen y también se pagan. La mediana y los percentiles sirven para otra cosa: describir el correo típico y el nivel de servicio.
- El día equivocado. Medir la semana de cierre de trimestre infla el baseline; medir enero lo desinfla. Muestrea al menos dos semanas normales separadas.
- El proceso Frankenstein. El proceso “oficial” del manual y el proceso real difieren siempre. Mide el real: sigue a la unidad de trabajo, no al diagrama. Si el correo pasa por una planilla intermedia que nadie documentó, esa planilla es parte del costo.
El caso A, medido
Triaje de correos, muestreo de dos semanas: 12.000 correos/mes, atendidos por seis personas. Media de 4 minutos por correo (leer, clasificar, derivar o responder plantilla; la mediana es menor, ~3 minutos, porque unos pocos correos largos estiran la cola). Costo por hora cargado del equipo: 12 (moneda ilustrativa — la mecánica es lo que importa). Auditoría de 200 correos: 7% mal derivados (rebotan y se reprocesan, +6 min).
BASELINE CASO A (statu quo, por mes)
12.000 correos × 4 min = 800 horas
reproceso: 840 × 6 min = 84 horas
─────────────────────────────────────────────
total = 884 horas
costo: 884 h × 12/h = 10.608/mes
costo por correo = 0,88
tasa de error = 7%
tiempo de ciclo (mediana) = 5,5 horas
Chequeo de capacidad, que todo baseline debe pasar: 884 horas al mes son ~5,5 jornadas completas (a ~160 horas por persona), consistente con un equipo de seis que además atiende otras tareas menores. Si el equipo medido no alcanza a cubrir las horas calculadas, algo está mal: el tiempo, el volumen o la dotación.
Esos cinco números son la vara. Cualquier propuesta de IA se medirá contra 0,88 por correo, 7% de error y 5,5 horas de ciclo — no contra cero, no contra una intuición.
Arquetipo B: construir el contrafactual
El contrafactual (counterfactual: qué pasaría en el mundo donde no construyes nada) es el baseline de lo que no existe. No se mide — se arma con piezas medibles más supuestos explícitos. La estructura tiene tres partes:
- El universo direccionable. ¿Cuántas unidades podrían pasar por el flujo nuevo? Esto sí se mide: cuántos clientes medianos existen, cuántas llamadas quedan sin analizar, cuántas consultas llegan fuera de horario. Es la parte firme del contrafactual.
- La tasa de captura. ¿Qué fracción del universo usará de verdad el flujo? Esta es la parte blanda — y donde los casos B mienten. La regla: usa un rango con tres escenarios (pesimista / central / optimista) y ancla el central en el comparable más cercano que tengas (adopción de la última herramienta interna, tasa de respuesta de la última campaña), no en el deseo.
- El valor por unidad capturada. ¿Cuánto vale cada unidad que el flujo captura? Margen de una cotización ganada, costo de un problema detectado a tiempo. Medible a partir de datos históricos del negocio.
Cuidado: el contrafactual también debe descontar lo que habría pasado sin el sistema. Si el 10% de los clientes medianos ya compraba por otros canales, el cotizador no “genera” esas ventas — las redistribuye. El ingreso del caso es el incremental, no el total que toca el sistema. Este descuento es la diferencia entre un caso B honesto y uno que se desmorona en la primera revisión de finanzas.
El caso B, construido
Cotizador asistido: 800 clientes medianos activos que hoy no se cotizan (universo, medido en el CRM). Tasa de conversión histórica de cotizaciones enviadas a clientes comparables: 18% (medida). Margen medio por venta mediana: 900 (medido). La pieza blanda — cuántos de esos 800 pedirán cotización al año si el costo de cotizar baja de 3 días a minutos:
CONTRAFACTUAL CASO B (por año)
universo direccionable = 800 clientes
cotizaciones solicitadas/año:
pesimista 10% → 80
central 25% → 200
optimista 45% → 360
conversión histórica = 18%
margen por venta = 900
margen incremental (central):
200 × 18% × 900 = 32.400/año
rango: 12.960 — 58.320
Dos precisiones de etiqueta. Es margen, no ingreso por ventas: 900 es el margen por venta, no el precio. Y es incremental solo porque el universo ya excluye a los clientes que hoy se cotizan; si alguno de esos 800 habría comprado igual por otro canal, esa parte se descuenta (y se vigila en producción como canibalización, módulo 8).
Nota la asimetría con el caso A: allá el baseline tenía cinco números medidos; acá tiene dos medidos, uno histórico y uno supuesto con rango. Esa asimetría es estructural del arquetipo B y no se arregla — se declara. El módulo 7 la retoma con el análisis de sensibilidad.
Artefacto: la ficha de baseline
# Ficha de baseline — [caso] · Arquetipo [A/B]
## Números medidos
| Métrica | Valor | Fuente | Fecha de medición |
|---|---|---|---|
| | | | |
## Supuestos (solo arquetipo B, o huecos del A)
| Supuesto | Central | Rango | Anclado en |
|---|---|---|---|
| | | | |
## Cómo se remedirá
[El mismo método, para comparar peras con peras después
del despliegue: mismo muestreo, misma auditoría, misma
ventana. Si el baseline se midió con la media de un
muestreo observado, el "después" también.]
La última sección es la que nadie escribe y todos lamentan: si mides el baseline con muestreo observado y el resultado post-despliegue con autoreporte, la comparación es basura aunque ambos números sean “verdad”.
Errores comunes
- Saltarse el baseline porque “es obvio que hoy es caro”. Lo obvio no se puede restar. Sin el 0,88 por correo, el ahorro del sistema es una frase, no un número.
- Medir con autoreporte. Preguntar cuánto se tarda produce el número que la persona quiere que tengas. Muestreo observado, media para la carga total, dos semanas normales.
- Contrafactual sin descuento. Contar como incremental todo lo que toca el sistema nuevo, incluyendo lo que habría ocurrido igual. El caso B se sostiene sobre el delta, no sobre el total.
- Un solo escenario en la parte blanda. Una tasa de adopción puntual (“captaremos el 30%”) es indefendible. Tres escenarios con el central anclado en un comparable real, siempre.
- Baseline medido, remedición improvisada. Si el antes y el después no usan el mismo método, la mejora medida puede ser puro artefacto de medición. La ficha exige declarar el método de remedición por adelantado.
- Dejar que el dueño del proceso mida su propio baseline sin auditoría. No por mala fe: por las mismas trampas de autoreporte, ahora a escala de área. Acompaña la medición.
La frase para llevarse
“En el arquetipo A, el baseline se mide siguiendo a la unidad de trabajo, no al organigrama; en el B, se construye con universo medido, captura en rango y descuento de lo que habría pasado igual. En ambos: si no puedes decir contra qué compararás, todavía no tienes un caso — tienes una corazonada.”
Qué viene
Módulo 4: la economía de la IA. Ya sabemos cuánto cuesta el mundo sin el sistema; ahora, cuánto costaría el sistema. Y aquí la IA rompe la intuición del software clásico: el costo marginal no es cero. Tokens que se pagan por uso, agentes que multiplican llamadas, humanos en el circuito que cuestan más que el modelo, cachés y batch que cambian la cuenta. Vamos a calcular el costo por tarea del caso A con precios reales de modelos — y a entender por qué la fila más cara de la tabla casi nunca es la inferencia.
Material relacionado
Preguntas sobre este curso
Regístrate gratis para hacer preguntas y guardar tu progreso.
✉ Entérate de lo nuevo
Recibe un aviso cuando publique nuevos cursos, workshops o investigaciones. Sin spam.