El plan de evidencia del piloto ya fijó baseline, métricas líderes y retrasadas, y umbrales go/no-go a 30 días. Aun así, el día 30 llega y el comité improvisa: faltan capturas semanales, el baseline “se actualizó” sin traza y nadie puede armar el decision pack en 48 horas. Este artículo es el complemento operativo de ese plan: la bitácora de evidencia —un ritual semanal corto que convierte el marco del día 0 en registro continuo hasta la decisión.
Para equipos mid-market en México que ya tienen charter y criterios falsificables, y necesitan que la evidencia no dependa de la memoria del sponsor ni de un folder suelto en Drive.
Del plan de evidencia a la bitácora semanal
El plan responde qué se medirá y con qué umbral se decide. La bitácora responde qué se registró cada semana, quién lo firmó y qué anomalía obligó a intervenir. Sin bitácora, el go/no-go se vuelve narrativa; con bitácora, se vuelve expediente.
Tres reglas para que no se diluya:
- Una fuente de verdad (hoja, ticket o wiki versionada). No “versión del área” vs “versión del partner”.
- Cierre semanal en 30–45 minutos, no un reporte de 20 slides. Si tarda más, sobran campos.
- Dueño nombrado por campo: proceso, datos, modelo/controles y sponsor. Cargos genéricos no firman.
La bitácora no reescribe el plan de evidencia ni el one-pager: los consume. Tampoco sustituye el scorecard semanal de P&L; lo alimenta con hechos del piloto.
Campos que registrar cada semana
Use un bloque fijo. Si un campo no se puede llenar, eso ya es señal: o el instrumento de medición falló, o el alcance se movió sin gobernanza.
1. Identificación y ventana
Semana del piloto (S1–S4/S5), fechas de inicio/fin, versión del one-pager y del plan de evidencia. Sin esto, mezclan corridas y el baseline pierde validez.
2. Volumen y cobertura
Casos procesados (sombra o producción controlada), % del segmento in-scope cubierto y exclusiones justificadas. Si el volumen cae sin explicación, el go/no-go del día 30 no es comparable al baseline.
3. Métricas líderes (leading)
Las mismas del plan: precisión en holdout o sombra, tasa de override, latencia de cola de excepciones, completitud de campos críticos. Capture valor de la semana, delta vs semana previa y vs baseline. Un número sin delta no sirve para intervenir a tiempo.
4. Métricas retrasadas (lagging) disponibles
Solo las que ya existen en el horizonte del piloto (ciclo, reclamos, rework, costo por caso). Si aún no maduran, registre “N/D + fecha esperada”; no invente proxies ad hoc cada viernes.
5. Incidentes y excepciones
Conteo por clase (datos, modelo, proceso, riesgo), top 3 causas y si cerraron o siguen abiertas. Amárrelo a la cola de excepciones y al cierre del loop: excepción resuelta sin aprendizaje no entra como mejora.
6. Cambios de alcance, datos o modelo
¿Se movió el in/out? ¿Cambió el feed? ¿Hubo redeploy? Cada cambio debe citar fecha, dueño y si invalidó parcial o total la comparabilidad con baseline. El plan de evidencia ya advirtió esto; la bitácora lo hace auditable.
7. Semáforo vs umbrales go/no-go
Para cada umbral del plan: verde / amarillo / rojo + una frase de causa. Amarillo dos semanas seguidas sin plan de corrección es rojo disfrazado.
8. Acciones de la semana siguiente
Máximo cinco. Dueño, fecha y métrica que deben mover. Si la lista crece, priorice: la bitácora no es backlog de producto.
Dueños y ritual de cierre (45 minutos)
RACI mínimo de la bitácora:
- Dueño de proceso (R): llena volumen, excepciones de negocio y acciones.
- Dueño de datos (R): valida cobertura, completitud y cambios de feed.
- Responsable de modelo/controles (R): leading metrics, overrides, redeploys.
- Sponsor (A): valida semáforo y desbloquea si hay rojo en umbral crítico.
Agenda sugerida: 10 min lectura del bloque numérico, 15 min excepciones y cambios, 10 min semáforo vs umbrales, 10 min acciones. Congelar el archivo al cerrar (timestamp + versión). Sin freeze, el decision pack del día 30 se arma con números “movidos”.
Plantilla mínima de bitácora (copia y adapta)
Una fila por semana basta. Columnas recomendadas:
- Semana / fechas / versión charter
- Volumen & cobertura %
- Leading #1, #2, #3 (valor, Δ semana, Δ baseline)
- Lagging disponibles
- Incidentes abiertos / cerrados
- Cambios que afectan baseline (sí/no + nota)
- Semáforo por umbral go/no-go
- Acciones (dueño, fecha)
- Firmas (proceso, datos, modelo, sponsor)
Ejemplo hipotético mid-market (triaje L1, semana 2): volumen 1 240 tickets web retail (82% del in-scope); precisión sombra 91% (baseline 88%, umbral go 90%); override 7% (techo 10%, amarillo la semana previa en 9%); un cambio de mapeo de canal documentado el martes sin invalidar holdout; acciones: reforzar regla de mayoreo mal etiquetado (Ops, viernes).
Red flags a mitad del piloto
Intervenga antes del día 30 si aparece cualquiera de estas señales:
- Bitácora vacía o “se llenará el viernes” dos semanas seguidas: no hay operación de evidencia; pause el relato de avance.
- Baseline reescrito sin change log: el go/no-go pierde validez; vuelva al plan de evidencia y reaplique umbrales o reinicie reloj con transparencia al sponsor.
- Leading en rojo y lagging “aún no” eterno: o el horizonte del piloto es irreal, o están midiendo vanity. Ajuste alcance o instrumentación, no el discurso.
- Cambios de modelo/datos sin congelar métricas: comparan peras con manzanas; marque la semana como no comparable.
- Cola de excepciones creciendo sin cierre del loop: el HITL se volvió depósito; active el ritual de aprendizaje antes de pedir go.
- Sponsor ausente del semáforo: el día 30 será teatro. Escalone una revisión corta en S2 y S3.
Cómo armar el decision pack para el go/no-go
Setenta y dos horas antes de la reunión, el dueño de proceso ensambla un paquete corto a partir de la bitácora —no un deck nuevo:
- One-pager vigente (alcance y umbrales sin reescribir).
- Plan de evidencia con baseline original y definición de métricas.
- Serie semanal (tabla o gráfica simple) de leading/lagging y semáforos.
- Log de cambios que afectaron comparabilidad.
- Top excepciones y aprendizajes cerrados (cierre del loop).
- Recomendación: go / no-go / go condicionado, con la evidencia que la sostiene y los riesgos residuales.
En la reunión: 20 minutos de hechos, 20 de decisión, 10 de next steps. Si alguien pide “una demo más”, recuerde el contrato: el piloto se juzga por umbrales, no por narrativa. Un go condicionado exige dueño, fecha y métrica; no es un “sí emocional”.
Disciplina hasta el día 30 sin improvisar
El plan de evidencia define el tribunal. La bitácora semanal llena el expediente. Con campos fijos, dueños, semáforo vs umbrales y un decision pack armado desde el registro —no desde la memoria—, el go/no-go deja de ser una sorpresa de calendario.
En Next Wave AI acompañamos a equipos en México a operar pilotos con evidencia: del one-pager y el plan de baseline/umbrales a la bitácora semanal y el decision pack. Si quiere instalar este ritual en su piloto actual, escríbanos a contacto@nextWaveAI.AI o llame al +52 (33) 3126 6969.
Add comment