El Producto Mínimo Viable (MVP por sus siglas en inglés) es una técnica de diseño que forma parte del movimiento Lean Startup, popularizado por Eric Ries. Según Technopedia, el MVP es la versión más reducida de un producto que se puede liberar y tiene las siguientes características:
Provee suficiente valor como para que las personas estén interesadas en utilizarlo o comprarlo.
Demuestra suficiente beneficio futuro como para retener a los primeros en adoptarlo (early adopters).
Provee un lazo de retroalimentación para guiar su desarrollo futuro.
Siguiendo el concepto y la experiencia de usar la técnica de MVP en el mundo ágil de desarrollo de software, Jayne Gordon propone aplicarla al diseño de procesos en el documento The Agile Service Management Guide publicado por el DevOps Institute en el 2015 y que sirve de base para la certificación CASM (Certified Agile Service Manager). En este documento, Jayne Gordon establece que Agile Service Management asegura que los procesos de ITSM reflejan valores ágiles y son diseñados con el control y la estructura "apenas suficientes" como para, de forma efectiva y eficiente, entregar servicios que facilitan los resultados del cliente cuando y como sean requeridos.
El término "apenas suficiente" puede significar diferentes cosas para diferentes organizaciones, por ello, en el documento se especifica que para llegar al nivel de control y estructura requerido por cada organización de TI, es recomendable partir de un Proceso Mínimo Viable y utilizar un enfoque adaptativo que:
Implemente el proceso en incrementos pequeños y frecuentes.
Promueva lazos más cortos de retroalimentación y de información hacia adelante (feedforward) .
Establezca los incrementos futuros con base en las condiciones de negocio actuales.
Sea holístico para la construcción, maduración e integración de las actividades del proceso.
Permita a los practicantes del proceso tomar el tiempo requerido para absorber e institucionalizar nuevos comportamientos.
Permita terminar más trabajo y entregar valor más rápidamente.
De acuerdo con Jayne Gordon, el Proceso Mínimo Viable tiene las mismas características que el Producto Mínimo Viable y la idea de adaptar este concepto a los procesos de ITSM es que es mucho más fácil agregar a un proceso de forma incremental que reducirlo después de haber sido construido. El enfoque del MVP asegura que primero se diseñan e introducen los elementos claves del proceso, estableciendo así las bases para el diálogo y la retroalimentación necesarios para que los desarrollos futuros continúen brindando valor a los clientes del proceso.
En los posts anteriores he tratado el ecosistema de ITSM y algunos marcos de procesos para definir e implementar la gestión de servicios de TI. La oferta es variada, pero si consideramos que el concepto del Proceso Mínimo Viable es equivalente a definir un nivel de entrada para el proceso de ITSM entonces FitSM, que es la única fuente de buenas prácticas que cuenta con un marco de procesos simplificado y que está diseñada para proveer una gestión de servicios de nivel de entrada, podría ser útil para guiar la elaboración del Proceso Mínimo Viable (en lo sucesivo utilizo el acrónimo MVProc para referirme al Proceso Mínimo Viable). FitSM define 85 requerimientos para un sistema de gestión de servicios de TI efectivo de los cuales 16 son de aplicación general para el sistema de gestión y los 69 restantes se distribuyen entre los 14 procesos del modelo.
Tomemos al proceso gestión de la relación con el cliente (CRM) para ilustrar como FitSM puede apoyar en la creación del MVProc. El proceso CRM cuenta con los siguientes 6 requerimientos:
Se identificarán los clientes del servicio.
Para cada cliente, existirá un contacto designado como responsable de gestionar la relación con el cliente y la satisfacción del cliente.
Se establecerán mecanismos de comunicación con los clientes.
Las revisiones de los servicios con los clientes se llevarán a cabo a intervalos planeados.
Las quejas de los clientes del servicio serán gestionadas.
La satisfacción del cliente será gestionada.
Supongamos que la organización de TI decide que para dar mejor servicio al negocio requiere implementar el proceso CRM y establece que lo hará a través de un piloto con un cliente (área de negocio) que se muestra positivo hacia mejorar la relación con TI. El cliente manifiesta que para sentirse mejor atendido, necesita que TI actúe sobre sus quejas y le mantenga informado de los avances. La organización de TI decide entonces utilizar FitSM para construir su MVProc de la siguiente forma:
Se identificarán los clientes del servicio: en este caso, un solo cliente que participará en el piloto.
Para cada cliente, existirá un contacto designado como responsable de gestionar la relación con el cliente y la satisfacción del cliente: en este caso un solo contacto para el cliente del piloto.
Se establecerán mecanismos de comunicación con los clientes: la organización decide que la comunicación será por correo electrónico, teléfono y reuniones en sitio.
Las revisiones de los servicios con los clientes se llevarán a cabo a intervalos planeados: para ello se establecerá un cronograma de reuniones. La agenda de las reuniones cubrirá solamente el registro de nuevas quejas y el seguimiento a los avances en la atención de las quejas abiertas.
Las quejas de los clientes del servicio serán gestionadas: las quejas serán registradas y atendidas directamente por el gestor (contacto) asignado al cliente.
La satisfacción del cliente será gestionada: no forma parte del alcance del MVProc.
Con esto en mente, la organización puede establecer las siguientes cuatro iteraciones para liberar su MVProc:
Primera iteración: describir el MVProc y generar el diagrama del proceso.
Segunda iteración: formar al gestor de la relación con el cliente en el proceso y en técnicas básicas de comunicación y control de reuniones.
Tercera iteración: involucrar al cliente, comunicar el proceso descrito y formalizar los mecanismos de comunicación (correo electrónico, teléfono, reuniones en sitio).
Cuarta iteración: establecer el cronograma de reuniones y los mecanismos para registrar las quejas del cliente sobre el servicio.
Luego de la cuarta iteración la organización de TI decide liberar el MVProc y monitorear su operación para validar que el cliente recibe valor con el proceso, se mantiene animado e involucrado y provee la retroalimentación necesaria para que TI pueda tomar las decisiones correctas para las iteraciones subsiguientes. Dependiendo de la retroalimentación, TI podría ejecutar nuevas iteraciones para, por ejemplo: ampliar el alcance de las reuniones con el cliente, agregar nuevos mecanismos de registro de quejas (como la Mesa de Servicios o un sitio de autoservicio), ampliar la cobertura a otras unidades de negocio, fortalecer las competencias de los gestores o afinar el proceso. La dirección que tome el desarrollo del proceso, por tanto, dependerá de la retroalimentación del cliente.