lunes, 11 de junio de 2018

¿Scrum en servicio al cliente?

Scrum es aplicable a todos los ámbitos donde haya incertidumbre y donde haya que realizar mucho aprendizaje. Uno de estos ámbitos está en servicio al cliente, en el equipo que define los procesos de relación de la compañía con sus clientes. Si queremos dar la mejor experiencia a nuestros clientes hemos de ser conscientes de que vivimos en un mundo en constante cambio, y que la forma en la nos relacionamos e interactuamos con ellos debe de adaptarse constantemente a través procesos en mejora continua. Scrum a través de sus sprints permite construir los procesos de relación con el cliente de forma incremental y adaptativa.
Call centers con buena experiencia de cliente se basan en procesos en continua adaptación - cortesía de Pixabay
A principios de año inicié el acompañamiento en Scrum de un gran equipo de equipos de procesos, cuyo objetivo es mejorar la experiencia de los clientes, solucionando elementos deficientes y haciendo evolucionar los procesos de forma continua. La primera actividad que hicimos fue explicitar los valores que deberían de subyacer en el equipo y escribieron su propio Manifiesto Ágil de Servicio al Cliente, el resultado fue espectacular y encarriló al equipo a ser verdaderamente centrados en el cliente.

Una pila de producto de procesos consiste en elementos que hagan evolucionar el proceso, estos elementos pueden consistir en deficiencias y mejoras. Los elementos más grandes de la pila son los problemas que hay detrás de deficiencias y mejoras, son puntos de relación donde a nuestros clientes les "duele" o no les es agradable pasar, se los conoce como "pain points". La estructura de tipos de elementos de la pila propuesta es la siguiente:
Historias de usuario que tratan pain points del proceso de facturas
Las historias de usuario de servicio al cliente se centran en la relación con los clientes, son historias más emocionales, similares a las de marketing.

Una historia de mejora puede tratar de cambiar el texto de una comunicación a nuestro cliente y mejorar la difusión del mensaje del 30% al 70% por ejemplo.

Una historia que trata de resolver una deficiencia puede ser mejorar la claridad y transparencia en la apertura de la incidencia, como por ejemplo informar al cliente del numero de incidencia.

En una pila de procesos hay más historias exploratorias que en una pila de un producto de software, dado que sus elementos influyen directamente en la relación con los clientes, es clave validar toda idea e iniciativa de forma rápida antes de implementarla. De la misma manera los criterios de aceptación son más bien criterios de éxito, hay que encontrar el proceso idóneo para gran parte de nuestros clientes, es imposible que lo vaya a ser para todos, quizá 3 de cada 4 sea un objetivo excelente y factible.

Equipo de procesos ante su pila de producto
Los equipos dedicados a los sprints de procesos son similares a los equipos de TI, son multifucionales y autoorganizados. En lugar de Propietario de Producto tienen un Propietario del Proceso y los perfiles de especialistas incluyen especialistas en todas las áreas necesarias para implementar procesos de principio a fin.

Entre estos especialistas puede haber expertos en los procesos existentes, frontliners que son comerciales y profesionales de los call centers para proporcionar feedback de primera mano sobre el funcionamiento de las mejoras de procesos, su facilidad de uso y el propio feedback de los clientes, y dado que probablemente la mitad de procesos pasen por modificaciones en las aplicaciones de software, alguien de TI para realizar una evaluación preliminar de posibles soluciones técnicas e impactos en sistemas.

Mi experiencia con estos equipos no constructores de software ha sido sorprendente, son menos binarios que los equipos de TI y la consolidación de Scrum en su forma de trabajar ocurre muy rápidamente, suelen decir que Scrum es una forma natural de trabajar.

Un miembro de un equipo de procesos me dijo que deberían de hacer sprints de una semana, ya que de esta forma el ciclo de feedback del cliente seria más corto y podrían encontrar las mejoras en los procesos de forma más rápida... ¡en servicio al cliente habían interiorizado los valores y prácticas de Scrum!

2 comentarios:

  1. Iba a saltarte al cuello al leer el título, pero al leerlo he cambiado de idea. Veo que el Scrum no está enfocado a la operación, si no a la propia función. Es decir, ¿Cómo podemos mejorar?.
    Porque intentar gestionar una operación con Scrum me parece un error.
    Tal y como lo planteas, un aplauso!

    ResponderEliminar
    Respuestas
    1. Si, cuando en enero me dijeron que primero formaría y luego acompañaría a los equipos de servicio al cliente no sabía si tenia sentido. Luego entendí que se trataba de mejora de procesos, aún sigo con ellos y me esto ha abierto Scrum y Agile a las posibilidades fuera de TI.

      Un abrazo, gracias por escribir,

      Alex

      Eliminar