Cuándo medir el resultado de un proyecto de innovación
Mides después de que la operación se estabiliza, no cuando el sistema entra en producción. Un proyecto de innovación suele empeorar antes de mejorar: el equipo reaprende el trabajo mientras el proceso se reacomoda, y los números caen en ese intervalo. Medir dentro del valle produce un veredicto sobre la transición, no sobre el proyecto.
¿Por qué el número empeora justo después de entrar en producción?
Porque la rutina vieja dejó de funcionar y la nueva todavía no es automática. En ese intervalo la operación paga dos costes a la vez: el del proceso que se está desmontando y el del proceso que aún no rinde.
En la literatura económica esto se llama curva J. La investigación del Census Bureau dirigida por Kristina McElheran, Mu-Jeung Yang, Zachary Kroff y Erik Brynjolfsson cruzó dos encuestas censales de 2017 y 2021 y encontró el patrón con evidencia causal: primero la caída, después el crecimiento. La cobertura de MIT Sloan resume la lectura de McElheran de que la tecnología no es plug-and-play y exige cambio sistémico, lo que genera fricción, sobre todo en empresas establecidas.
El estudio trata de IA industrial en fábricas. La mecánica no: vale para un cambio de ERP, una integración de sistemas o un rediseño de flujo, porque lo que produce el valle es el equipo reaprendiendo el trabajo, no la tecnología concreta que entró.
El hallazgo más útil para quien gestiona innovación es otro. En las empresas más antiguas, lo que se deteriora en el corto plazo es la gestión, no la máquina. Dejan de seguir indicadores y metas de producción durante el ajuste, y ese retroceso responde por cerca de un tercio de su pérdida de productividad. La instrumentación se afloja justo en el mes en que más la necesitas.
¿Cuál es la ventana de medición correcta?
La ventana se abre cuando la serie se estabiliza, no en una fecha del calendario. Antes de eso tienes dos poblaciones distintas de eventos mezcladas en el mismo periodo: los que pasaron por la transición y los que ya corren en el régimen nuevo.
El promedio mensual suma las dos y devuelve un número que no describe ninguna. Si la transición duró seis semanas y mides el trimestre entero, la mitad de la muestra es aprendizaje. El proyecto bueno queda mediocre en el informe. El proyecto malo queda salvable, porque la culpa cabe en el aprendizaje.
La señal de estabilidad está en la dispersión, no en el promedio. Mientras el equipo sigue aprendiendo, el mismo tipo de caso tarda tiempos muy distintos en avanzar. Cuando la diferencia entre casos parecidos deja de encogerse mes a mes, el régimen nuevo ya se formó y el promedio empieza a significar algo.
Esa meseta por sí sola no dice si el proyecto funcionó. Dice que ya puedes empezar a medir. La respuesta sobre el resultado viene del nivel en que la dispersión se estacionó, comparado con el de antes de entrar en producción.
Fíjate en el desajuste entre esa exigencia y el plazo que las empresas se dan. En la encuesta de Deloitte, hecha con 3.235 líderes de negocio y TI en 24 países, el 54% de los líderes globales espera llevar al menos el 40% de sus experimentos a la operación en tres a seis meses. Es una expectativa de escala colocada dentro del intervalo en que la curva todavía está bajando.
¿Qué necesita registrar tu sistema para separar las dos fases?
Registro por evento, con marca de tiempo. Sin eso no puedes decir en qué semana giró la curva, y sin esa fecha no existe ventana de medición, solo el cierre del mes.
En la práctica son tres cosas, y ninguna es un panel nuevo:
- Cuándo avanzó cada caso. No la fecha de conclusión, sino la hora de cada paso de etapa. Es lo que permite reconstruir la serie después, incluso de forma retroactiva.
- Por qué camino avanzó. Flujo nuevo, flujo viejo, o la excepción que alguien abrió por fuera. Si los tres entran en el mismo cubo, el resultado del flujo nuevo queda diluido por el volumen que nunca pasó por él.
- Qué versión del proceso estaba vigente. Una marca simple de régimen, actualizada cuando el proceso cambia. Sin ella, la comparación con el pasado compara cosas distintas.
Esto es una decisión de arquitectura, tomada antes de entrar en producción. Una vez cerrado el trimestre sin esos campos, no hay análisis que recupere la información: el dato nunca se grabó. Es el mismo problema que aparece en cómo la calidad de los datos evita decisiones erradas, visto desde el lado de la medición de proyecto.
Conviene separar dos asuntos que se confunden aquí. Una cosa es contra qué comparas, que es la línea de base y la atribución de la ganancia. Otra es cuándo comparas. Puedes acertar la línea de base y aun así leer el número en la semana equivocada.
Un ejemplo, y es una hipótesis
Con todas las letras: el caso de abajo está construido para ilustrar el razonamiento. Los números son ilustrativos y no salieron de ninguna medición de Yowpi.
Una distribuidora cambia la revisión manual de pedidos por un flujo con validación automática. El primer mes, el tiempo medio de liberación sube, porque el equipo revisa lo que el sistema decidió y todavía rehace parte en la hoja de cálculo antigua. El segundo, el promedio vuelve al nivel anterior y la dirección concluye que la inversión no cambió nada.
Lo que nadie miró: entre pedidos del mismo tipo, la diferencia de tiempo había caído a la mitad. Los casos simples ya pasaban directo, y los complejos concentraban la demora. Era el flujo nuevo funcionando en la parte que se propuso resolver, escondido dentro de un promedio que aún cargaba el retrabajo de la transición.
Sin la marca de tiempo por etapa y sin la marca de qué camino siguió cada pedido, esa lectura no existe. Existe solo el promedio, y el promedio dijo que el proyecto no sirvió.
Qué acordar con la dirección antes de empezar
Escribe cuatro cosas antes de la primera línea de código, en un lugar que la dirección pueda consultar después:
- Qué indicador de negocio mueve la iniciativa, elegido entre los que la dirección ya sigue.
- Cuánto se espera que dure la transición, con la fecha en que se abre la ventana de medición.
- Qué señal indica que el régimen se estabilizó, para que la fecha sea revisable con criterio y no por conveniencia.
- Cuál es la condición de parada, es decir, qué tiene que pasar para cerrar el proyecto antes de que la ventana se abra.
La última protege a las otras tres. Sin condición de parada escrita, cualquier número malo en mitad de la transición se vuelve argumento para cerrar, y cualquier proyecto sin resultado se vuelve argumento para esperar otro trimestre. Acordar el criterio antes saca las dos conversaciones de la improvisación.
Ese acuerdo también cambia la conversación sobre adopción. Un sistema poco usado en el mes dos es esperable; en el mes seis es síntoma. La diferencia está en medir el uso real después de entrar en producción, no en preguntarle al equipo si le gustó. La base de todo esto es la misma que tratamos en arquitectura de sistemas internos: 8 pasos: lo que el sistema registra decide lo que después puedes saber.
Preguntas frecuentes
No veo cómo medir el resultado. ¿Por dónde empiezo?
Por el campo, no por el panel. Elige un indicador que la dirección ya use y verifica si el sistema graba la hora de cada paso de etapa de ese proceso. Si no la graba, ese es el primer trabajo. Un panel construido sobre datos agregados mensuales no responde cuándo apareció el resultado, y es esa pregunta la que decide el veredicto.
No consigo justificar la inversión ahora. ¿Esto cambia algo?
Cambia lo que prometes. Un business case que promete ganancia en el primer trimestre entrega una caída y pierde credibilidad para la petición siguiente. Declara la transición, di cuánto debe durar y marca la fecha en que empieza la medición. Así el resultado se sostiene cuando llegue. La evidencia de la curva J respalda esa forma de presentar el caso, y viene de investigación pública, no de un proveedor.
Temo que no elimine los cuellos de botella de verdad. ¿Cómo lo sé antes?
Mira la dispersión en vez de esperar el cierre. Si el equipo ya domina el flujo y la dispersión se estacionó en el mismo nivel que antes del proyecto, el cuello de botella sigue donde estaba y solo cambió la interfaz. Esa señal aparece semanas antes de que termine el trimestre, y da tiempo de corregir el alcance mientras el proyecto sigue en ejecución.
El siguiente paso
Si tu operación hoy solo produce promedio mensual, el Diagnóstico de Arquitectura Operacional es una conversación de 30 minutos sobre lo que tus sistemas registran y lo que falta para medir un proyecto en el momento correcto: agenda cuando tenga sentido.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico