noticias / Newsletter

La nueva organización del soporte

Albert Cervera i Areny

La nueva organización del soporte

Hola,

la verdad es que todavía me lo estoy pensando pero probablemente la próxima semana haré un vídeo para enseñarte lo fácil y rápido de utilizar es el sistema de vídeo-tutoriales que hemos creado. Te explicaré con detalle por qué es innovador, complejo técnicamente y sobre todo por qué ha merecido la pena hacerlo.

Esta semana, como te dije, me gustaría explicarte cómo y porqué hemos reorganizado el soporte que ofrecemos a nuestros clientes.

Los orígenes

Cuando empezamos a dar forma al departamento de soporte, hace más años de los que quisiera, lo hicimos estableciendo la posición independiente del departamento de consultoría. La idea era tener a alguien que se dedicara única y exclusivamente al soporte telefónico y del correo electrónico.

Después de que varias personas pasaran por la posición nos dimos cuenta de que no funcionaba.

Cierto que nosotros proveemos un ERP base (estándar, podríamos llamarlo) con más de 600 módulos disponibles pero también es cierto que nuestra vocación es la capacidad de adaptarlo a las necesidades de cada cliente. Esto significa que no podemos tener un departamento de soporte clásico donde das una serie de instrucciones que dicen "si te preguntan A, respondes B, si te preguntan X, respondes Y, etc".

La instalación de cada cliente es diferente y las necesidades de nuestros clientes son demasiado diversas y complejas como para procedimentarlas todas.

Cierto también que con la plataforma de e-learning queremos hacerlo en parte pero ha sido muy complejo de construir debido a la necesidad de poder actualizar las versiones e igualmente no podremos documentarlo absolutamente todo (por el ritmo de cambio y variación por cliente).

En realidad, nos dimos cuenta, las habilidades que necesitamos en el departamento de soporte son las mismas que en el departamento de consultoría.

¿Qué hacíamos hasta ahora?

Durante unos años y al mismo tiempo que crecía el departamento de consultoría pasamos este trabajo a este equipo. Esto hizo que la calidad del soporte mejorara porque la persona que recibía y respondía a las preguntas tenía experiencia en proyectos de implantación completos. Estaba acostumbrada a entender los proyectos en su totalidad y tenía habilidades para entender y hacerse entender.

Sabíamos que poner a una persona con las cualidades de consultoría a llevar exclusivamente el soporte no funcionaría porque podía quemarse fácilmente y además, con el tiempo, podría perder las habilidades que le habían llevado a ser válida por la posición.

El no estar en contacto con la implantación de nuevos proyectos provocaría dejar de entender, o perder agilidad, con determinadas áreas del programa, especialmente a medida que cambiarían con nuevas versiones, afectando a la calidad del servicio y al crecimiento profesional de la persona que lo llevara.

Así que era necesario algún sistema rotatorio y optamos por una rotación más o menos diaria. De hecho, las propias personas del equipo se iban organizando los días de la semana que eran más o menos fijos pero con flexibilidad para poder atender a las reuniones y obligaciones con los clientes.

En cuanto a las incidencias a pasar a segundo nivel (a un programador), una persona fuera del equipo las iba asignando y repartiendo a los diferentes miembros del equipo de desarrollo según cargas.

Todo el mundo se había adaptado a esta forma de trabajar que se daba como consolidada. Nadie acababa de hablar de sus problemas porque estaba demasiado interiorizada. Pero claramente era el elefante en la habitación.

¿Y ahora qué?

Desde la primera semana de septiembre hemos creado un equipo compuesto por un consultor y un desarrollador que se cuidan del departamento de Mantenimiento de servicio y producto o MSP. Este equipo es rotativo. Cada 3 meses cambiará de personas aunque continuará estando compuesto por una persona que atiende a las peticiones, responde las que son dudas o aclaraciones, filtra las que requieren intervención de programación y otra persona a segundo nivel resolviendo las incidencias técnicas.

Dado que previsiblemente la atención al soporte es una tarea que en muchas ocasiones no ocupa la jornada entera, hemos añadido como responsabilidad al equipo el trabajo del paso a nuevas versiones así como la mejora de las herramientas de uso interno, con este orden de prioridades.

Ya era bastante evidente sobre el papel que esta nueva organización era mejor, pero ha quedado confirmado ya en las primeras 5 semanas de funcionamiento tanto por los que están en el equipo como los que no.

¿Y por qué?

Con un equipo dedicado a mantenimiento de servicio y producto durante 3 meses:

  • Es más fácil detectar incidencias similares y resolverlas porque quienes las gestiona son las mismas personas.
  • Mejora el tiempo de respuesta porque la prioridad del equipo está más clara. Tenemos dedicados más recursos que antes al soporte, pero el tiempo sobrante se dedica a tareas que también son importantes pero no urgentes. Combinar soporte con tareas de consultoría o desarrollos de clientes sí que hacía entrar en conflicto tareas que podían ser prioritarias pero de distintas naturalezas. Además, que las prioridades sean claras reduce el estrés de los implicados.
  • Son más claros los recursos dedicados a mantenimiento por un lado y los dedicados a proyectos por otro. Creemos que a pesar de la dificultad, nos permitirá planificar algo mejor.
  • La comunicación interna es mucho más fluida. Las dos personas del equipo se coordinan a diario (si lo necesitan) y no hay una persona dedicada a planificación y seguimiento de estas tareas porque lo hace el propio equipo.
  • Desde la dirección podemos realizar un mejor seguimiento de la calidad del servicio porque sólo hay dos personas responsables de que sea un éxito.
  • Los clientes pueden realizar un mejor seguimiento de los asuntos que pasan por soporte, especialmente importante cuando aparecen varios días temas que están relacionados. Todos preferimos hablar siempre con la misma persona.
  • La rotación permite que tanto consultores como programadores puedan ser responsables del mantenimiento del producto y servicio, entendiendo las dificultades que viven nuestros clientes. Al mismo tiempo, pasan también meses realizando las tareas de consultoría y programación necesarias para ejecutar proyectos. De esta forma tenemos profesionales completos capaces de entender todas las fases de los proyectos y tomar mejores decisiones en soporte gracias a los conocimientos de consultoría y mejores decisiones a consultoría gracias al feedback recibido durante las épocas de soporte.
  • Durante las épocas en las que no están en el equipo de MSP también ven reducido el estrés y también mejora el servicio porque tienen muchas menos interrupciones en el día a día.
  • Elimina la necesidad de una reunión semanal de planificación de las rotaciones.

No hay nada gratuito y todas estas ventajas vienen también con inconvenientes.

Algo que hemos hecho desde el primer día en NaN-tic es que el cliente tenía un consultor asignado, su principal interlocutor para cuestiones de proyecto. El hecho de aplicar esta rotación no permite que el consultor tenga clientes asignados durante el período en el que está en el equipo de MSP, así que el cliente pierde su referente.

Aunque esto es un problema, creemos que podemos solucionarlo e incluso podemos convertirlo en ventajas a largo plazo:

  • En el momento de realizar la rotación asignaremos los proyectos que estaba llevando el consultor que entra en el equipo de MSP al consultor saliente (u otro, en su caso). Esto se comunicará a los clientes.
  • Además, se realizará una reunión interna de traspaso, entendemos que hay algunos proyectos que tienen más dificultades y más detalles a traspasar. Creemos que ésta es una oportunidad de mejora ya que el hecho de que se tenga que traspasar con cierta frecuencia (quizás una vez al año, dos máximo) también hará que mejoremos la documentación para agilizar el proceso. Lógicamente este traspaso no tendrá coste alguno para el cliente.
  • Todo ello hará que la información esté mejor registrada y difundida, así que una baja laboral en NaN-tic no implica la pérdida de conocimiento del proyecto. Esto es algo que ya ocurría en buena parte con los procesos actuales pero ese cambio lo refinará y será una garantía adicional.

Si tienes cualquier duda sobre cómo lo estamos abordando, no dudes en preguntármelo.

Aparte de que ya se está empezando a notar la mejora del servicio, de cara a final de trimestre, cuando ya hayamos consolidado el funcionamiento del equipo, compartiré contigo la evolución de los KPI de tiempo de respuesta y resolución de tickets.

¡Salud y buen fin de semana!