Del laboratorio a operaciones: el traspaso que nadie planifica

La mayoría de los pilotos de laboratorio no fracasan en el laboratorio. Fracasan en los tres meses siguientes, cuando quienes los construyeron dan un paso atrás y a quienes deben gestionarlos nunca se les consultó de verdad. Un buen traspaso empieza el primer día del piloto, designa a un único responsable receptor en operaciones y transfiere cuatro cosas: la decisión, la partida presupuestaria, el conocimiento práctico y las métricas. Si falta cualquiera de ellas, el piloto vuelve discretamente al laboratorio o desaparece.

Por qué el traspaso es donde mueren los buenos pilotos

Un laboratorio se crea para ser distinto de operaciones. Va más rápido, tolera la ambigüedad, toma prestadas a personas y sortea los procesos estándar. Justamente por eso puede probar ideas nuevas. Y también por eso sus resultados rara vez encajan en la maquinaria que tiene que hacerlos funcionar.

Vijay Govindarajan y Chris Trimble describen esta tensión en The Other Side of Innovation (2010): el "motor de rendimiento" que hace funcionar el negocio de hoy está diseñado para la repetibilidad, y el trabajo de innovación necesita una alianza con él, no un muro entre ambos. Los laboratorios que tratan a operaciones como el público de una demostración final, y no como un socio desde el principio, condenan el traspaso al fracaso.

Los síntomas habituales resultan familiares:

• El piloto "funcionó", pero nadie en operaciones acordó qué significaba "funcionar".
• El equipo del laboratorio era el único que entendía cómo funcionaba.
• Había dinero para el piloto y ninguna partida en el presupuesto operativo del año siguiente.
• La persona responsable que lo recibió heredó un servicio nuevo además de sus objetivos existentes, sin que se le quitara nada.

Paso a paso: planificar el traspaso desde el primer día

1. Designar al responsable receptor antes de que empiece el piloto

Antes de dedicar una semana al piloto, hay que encontrar a la persona de operaciones que asumirá el resultado si sale bien. No un patrocinador al que le gusta la idea, sino el mando cuyo equipo lo gestionará un martes cualquiera. La pregunta es directa: "Si esto funciona, ¿lo vas a gestionar tú?". Si la respuesta es "quizá", eso ya es un hallazgo. Un piloto sin responsable receptor es un proyecto de investigación, y debe plantearse y reportarse como tal.

2. Acordar con el receptor la prueba de éxito, por escrito

Hay que dejar por escrito, con el responsable receptor, qué resultado le haría asumirlo. Conviene limitarse a dos o tres métricas que ya le importan: tiempo de ciclo, tasa de errores, coste por caso, reclamaciones. Un árbol de KPI ayuda a conectar la métrica del piloto con los objetivos por los que se evalúa al receptor. Si la prueba de éxito del laboratorio y la del receptor no coinciden, manda la del receptor.

3. Incorporar a una persona de operaciones al equipo del piloto

Una persona del equipo receptor debería trabajar en el piloto, al menos a tiempo parcial, desde el inicio. Detecta las normas, los sistemas y los hábitos que el laboratorio pasaría por alto, y se lleva el conocimiento práctico de vuelta a su equipo. Esta sola decisión hace más por el traspaso que cualquier documento.

4. Mapear el servicio futuro, no solo el piloto

Los pilotos funcionan a base de apaños: alguien del laboratorio que responde correos a mano, una hoja de cálculo en lugar de un sistema, un mando que aprueba excepciones personalmente. Antes de decidir escalar, conviene dibujar un service blueprint de cómo funcionará el servicio sin el laboratorio: cada paso visible para el usuario, cada paso interno, cada sistema y cada política de los que depende. Las brechas que aparezcan son el plan de trabajo del traspaso.

5. Hacer un premortem del propio traspaso

Se reúne al equipo del laboratorio y al equipo receptor y se pregunta: "Han pasado seis meses desde el traspaso y el servicio se ha apagado sin hacer ruido. ¿Qué ha ocurrido?". Un premortem saca a la luz los riesgos reales: un contrato con un proveedor que vence, una política que nunca se cambió, un equipo que perdió plantilla. Cada riesgo debe asignarse a alguien.

6. Redactar la matriz RACI del periodo de transición

Para cada actividad del blueprint, hay que decidir quién es responsable, quién rinde cuentas, a quién se consulta y a quién se informa: durante el piloto, durante la transición y después. Una matriz RACI para tres periodos hace visible el cambio de responsabilidad. Cada mes, el laboratorio debería rendir cuentas de menos cosas.

7. Asegurar la partida presupuestaria antes de celebrar

Un piloto financiado con el presupuesto del laboratorio no tiene futuro a menos que alguien lo traslade a un presupuesto operativo. Conviene trabajar pronto con finanzas: cuánto costará gestionarlo a escala, con cargo a qué partida y a partir de cuándo. Si el ciclo presupuestario se cierra antes de que acabe el piloto, se puede pedir una partida provisional basada en la prueba de éxito.

8. Traspasar con una lista de verificación y una fecha

Una lista de verificación de despliegue debe cubrir personas formadas, procedimientos redactados, sistemas configurados, políticas modificadas, soporte organizado y métricas en marcha. Se fija una fecha de traspaso y se anuncia con un plan de comunicación con partes interesadas, para que el personal, los clientes y la dirección sepan quién es ahora responsable del servicio.

9. Quedarse disponible y después apartarse

Se acuerda un periodo fijo, a menudo uno o dos ciclos del servicio, durante el cual el laboratorio sigue disponible para resolver dudas. Pasado ese plazo, el laboratorio deja de participar. Si el servicio no puede funcionar sin el laboratorio, es que no se traspasó.

Qué se transfiere realmente

Ayuda nombrar las cuatro cosas que deben cambiar de manos, porque los laboratorios a menudo solo transfieren una.

Hay que comprobar cada línea antes de la fecha de traspaso. Un piloto que ha transferido tres de las cuatro sigue siendo un piloto de laboratorio.

Ejemplo ilustrativo

Ilustrativo. El laboratorio de una autoridad de transporte urbano probó un nuevo proceso para gestionar las reclamaciones de accesibilidad. En el piloto, dos diseñadores del laboratorio clasificaban las reclamaciones a mano y llamaban a cada reclamante en menos de 48 horas. La satisfacción subió y el piloto se declaró un éxito.

Cuando el laboratorio presentó los resultados, la directora de atención al cliente preguntó quién iba a hacer las llamadas. Su equipo no tenía presupuesto para ello y el sistema de reclamaciones no podía marcar los casos de accesibilidad. El piloto quedó parado cinco meses.

El laboratorio volvió a empezar con la directora como responsable receptora. Una agente sénior se unió al equipo durante seis semanas. Juntos dibujaron un blueprint que sustituía la clasificación manual por una nueva categoría en el sistema existente, acordaron una devolución de llamada en 72 horas que el equipo sí podía sostener y trasladaron el coste al presupuesto del servicio para el año siguiente. El laboratorio siguió disponible durante un trimestre y después se apartó. El objetivo de 72 horas era menos llamativo que el del piloto. Pero sobrevivió.

Qué hacer y qué evitar

Qué hacer

• Designar al responsable receptor antes de que empiece el piloto.
• Dejar que el receptor defina el éxito con sus propias métricas.
• Integrar a una persona de operaciones en el equipo del piloto.
• Diseñar la versión a escala sin los apaños del laboratorio.
• Fijar una fecha en la que el laboratorio deja de participar.

Qué evitar

• Presentar a operaciones un piloto terminado como una sorpresa.
• Entregar una presentación y llamarlo transferencia.
• Medir el éxito solo con métricas del laboratorio, como "ideas probadas".
• Añadir un servicio nuevo al trabajo de un equipo sin quitarle otra cosa; aquí ayuda una lista de cosas que dejar de hacer.
• Mantener al laboratorio como responsable permanente "solo de momento".

Preguntas frecuentes

¿Cuándo debe un laboratorio traspasar un piloto a operaciones? Cuando se cumple la prueba de éxito del responsable receptor y pueden completarse las cuatro transferencias (decisión, presupuesto, conocimiento práctico y métricas). La planificación empieza al inicio del piloto; el traspaso en sí se produce cuando la versión a escala puede funcionar sin personas del laboratorio.

¿Quién debe ser responsable de una innovación después del piloto? El mando cuyo equipo la gestionará a diario, no el patrocinador ni el laboratorio. Si nadie así está dispuesto a asumirla, el piloto debe detenerse o rediseñarse, y ese es un resultado legítimo. Véase cómo detener bien un proyecto.

¿Por qué los pilotos con éxito no consiguen escalar? Normalmente porque los pilotos funcionan con apaños y con una atención prestada que no existen a escala, y porque nadie trasladó el coste de funcionamiento a un presupuesto operativo. La solución es diseñar la versión a escala durante el piloto, no después.

Hacia dónde seguir

Para tener la visión de conjunto, conviene leer qué es un laboratorio de innovación y por qué la mayoría fracasa y 5 razones por las que los laboratorios de innovación cierran en su segundo año: un laboratorio que no traspasa nada rara vez sobrevive a su segundo presupuesto. Las guías de método que sostienen la mayor parte del traspaso son el service blueprint, la matriz RACI, el premortem y la lista de verificación de despliegue.