Desde que existen los ciclos de mejora continua e innovación (PHVA, DMAIC, DMADV, 8D, etc.), y sus reencarnaciones más recientes tipo Agile, han existido las implementaciones piloto.
Hay que probar en pequeño antes de hacer una gran implementación de miles y recontra-miles de dólares con contratos, licencias, infraestructura, maquinaria, personal, y qué terrible darse cuenta de que no era lo que esperábamos.
Dos ejemplos rápidos. Cuando era estudiante de la Universidad de Massachusetts, Lowell, recuerdo que nos avisaron que un viernes apagaban el sistema de registro viejo, y el lunes siguiente arrancaba el nuevo. Fue un desastre, el nuevo no encontraba los cursos ganados o matriculados, la gente llegaba a las clases que creía que tenía y los profesores a las clases que creían que tenían que dar. A la semana siguiente estábamos otra vez con el sistema legacy, y la verdad hasta donde me acuerdo me gradué con el software viejo todavía en funcionamiento. El otro ejemplo me lleva a mis años de ingeniero de calidad. Para la eliminación de un problema de empaque se me ocurrió hacer unos dispositivos para evitar los errores de cuenta. Hice unos “mamotretos” con madera de balsa, cinta y algo de cartón de presentación. A las operarias les encantaron los dispositivos de cuenta y pudimos hacerlos ya en versión seria, profesional y bien terminada. Siempre me ha encantado hacer ese tipo de pruebas con papel, cartulina, balsa, y hasta Legos, en aquel momento no sabía que ya tenían un nombre formal “prototipos sucios”.
El sentido de la prueba piloto
El sentido de la prueba piloto es observar su utilidad para las personas que finalmente la van a utilizar. Puede ser ver al cliente usando una interfase gráfica, cómo llena un formulario, o también ver si un empleado de proceso o de oficina entiende una mejora que se está proponiendo. Una maqueta, una interfaz con gráficos todavía crudos, una prueba manual o “en chiquitico” nos van a enseñar en montón antes de seguir adelante con más pasos, inversiones, contrataciones, etc.
La esencia de la prueba piloto
El plan: Primero tenga un propósito, luego tenga un plan. Es vital tener muy claro qué es lo que quiere lograr. ¿Puede describir su visión en una forma fácil de comunicar? Puede usar historias, metáforas y representaciones visuales para dar a entender su mensaje. Los PXSianos siempre recomendamos usar una buena declaración del problema como la que presentamos en este blog.
El piloto: Empiece con pasos pequeños. Las pequeñas victorias nos encantan. Divida su gran visión en objetivos más pequeños alcanzables en un corto plazo. Hacer “una cosa” es más importante que “hacer la cosa.” Nunca se bloquee buscando LA solución, lo que importa es tener UNA solución.
Verifique y sobre todo aprenda: Entienda cómo responde el sistema, el entorno completo, no solo el espacio de la prueba piloto. Determine con anterioridad sus fuentes de retroalimentación ¿quién o quiénes le van a decir cómo salió el piloto? Experimente con personas, departamentos, líneas de producción, oficinas que estén dispuestos a sufrir las consecuencias de sus ideas y que les encantará dar sus impresiones, preferiblemente sin reventarle la cara.
Actúe: Actuar rápido refuerza los ciclos de retroalimentación. Cada vez que lo haga la siguiente vez actuará más rápido. Rectifique antes de estandarizar. Entienda cuando hacer pequeñas mejoras y cuando implementar en grande.
El Plan del Plan (la planeación de su prueba piloto)
Use el poder de iteración de los ciclos como PHVA. Diseñe el PHVA de su implementación piloto como parte de su PHVA papá (o mamá). Algunos consejos para seguir (*):
- Determine las responsabilidades de la implementación piloto.
- Determine el tiempo de entrega de los resultados de la implementación piloto.
- Prepare un plan de comunicación para los afectados en la implementación piloto.
- Prepare la documentación necesaria (mínima por favor) para completar la prueba.
- Reúna a todas las partes interesadas y explique los roles de cada uno.
- Prepare un método para recopilar datos.
- Estudie los resultados de la implementación piloto.
* NOTA: Tomado de nuestra lista de verificación de pruebas piloto de StatSolver.
Sobrepóngase a los problemas iniciales de implementación
Nadie dijo que los pilotos van a salir exentos de errores y fallas. Por el contrario, ese es el espíritu de las implementaciones en pequeño, poder sobreponerse lo más rápido posible a los problemas. La figura 2 hace un cruce entre el modelo del ciclo de éxito de Ray Dalio en su libro Principles con un toque de ciclo PHVA. Sobreponerse a los problemas pasará cuando los abordemos con lógica y razonamiento muy acorde con Seis Sigma, A3, sprint de Agile y otras modalidades de trabajo precisamente diseñadas para resolver problemas.
Ya lo sabe, dé el primer paso, haga la primera prueba, por supuesto que la idea es que todo salga bien, pero si no es así, falle y aprenda. Cada piloto exitoso lo llevará más cerca de la gran meta. Ah, y sepa también que la gran meta seguirá moviéndose hacia otra todavía más grande y ambiciosa.
E!
Edwin Garro
Referencia de fotografías
Foto 1 “Arduino light sensor test” by LenP17 is licensed under CC BY-NC-SA 2.0
Foto 2 “Lego Gripper Rotating a ‘Bottle'” by dluders is licensed under CC BY-SA 2.0
