Tengo claro que el dimensionamiento de la primera línea de contacto es fundamental para que el servicio de soporte tenga unas raíces firmes y capaces de alimentar el buen funcionamiento del resto de la organización TI. Que el Centro de Atención a Usuarios no funcione adecuadamente es un factor clave de fracaso para el servicio completo, de ahí que sea tan importante realizar un buen trabajo inicial. En el post anterior comencé a explicar que procedimiento sigo para dar con el número adecuado de agentes del Service Desk, voy a terminar de contar los últimos pasos.
Tal y como os decía para llevar a cabo esta tarea utilizo una aplicación basada en las fórmulas de Erlang C y había descrito hasta el punto en el que una vez introducidos los parámetros adecuados, la herramienta estaba en disposición de especificar el número de agentes requeridos para cumplir con el Acuerdo de Nivel de Servicio establecido. El último paso y no menos importante es el de introducir en la herramienta el número de agentes por tramo horario que configurarán el servicio final. Es aquí cuando hay que comenzar a "jugar" con el dimensionamiento para llegar a la configuración final más adecuada. Una vez que la aplicación nos muestra el número de agentes requeridos por cada tramo horario, el resultado final puede variar y mucho dependiendo del sobre o infradimensionamiento que apliquemos para los distintos tramos horarios.
La herramienta que yo utilizo, permite introducir además del número de técnicos por tramo horario, los descansos de que van a disponer o las pausas para comer. Estos tiempos son importantes y si no se tienen en cuenta, el dimensionamiento no será adecuado y no se cumplirá el objetivo marcado. Una vez introducidos el número de agentes, la aplicación indica cual es el porcentaje alcanzado según los parámetros introducidos (los que señalé en el primer post). Normalmente el número de llamadas entrantes varia dependiendo de la hora del día, las horas de entrar a trabajar de los usuarios los cambios de turno o las pausas para tomar el café, suelen reflejarse de manera clara en la gráfica de llamadas entrantes por tramo horario. En los picos esta claro que el dimensionamiento será mayor y los valles suelen ser los períodos más adecuados para que los agentes del Service Desk descansen o realicen otras tareas establecidas para la primera línea de soporte.
Habitualmente se suele realizar un dimensionamiento paralelo a los datos que nos requiere la calculadora de Erlang, pero ojo, no es el método más eficiente desde mi punto de vista. Os aconsejo que "juguéis" con el número de recursos, sobre todo estableciendo un sobredimensionamiento en aquellos tramos de más volumen de llamadas entrantes y todo lo contrario en aquellos tramos de menor actividad en las llamadas.
Por último os dejo unas apreciaciones personales:
Tal y como os decía para llevar a cabo esta tarea utilizo una aplicación basada en las fórmulas de Erlang C y había descrito hasta el punto en el que una vez introducidos los parámetros adecuados, la herramienta estaba en disposición de especificar el número de agentes requeridos para cumplir con el Acuerdo de Nivel de Servicio establecido. El último paso y no menos importante es el de introducir en la herramienta el número de agentes por tramo horario que configurarán el servicio final. Es aquí cuando hay que comenzar a "jugar" con el dimensionamiento para llegar a la configuración final más adecuada. Una vez que la aplicación nos muestra el número de agentes requeridos por cada tramo horario, el resultado final puede variar y mucho dependiendo del sobre o infradimensionamiento que apliquemos para los distintos tramos horarios.
La herramienta que yo utilizo, permite introducir además del número de técnicos por tramo horario, los descansos de que van a disponer o las pausas para comer. Estos tiempos son importantes y si no se tienen en cuenta, el dimensionamiento no será adecuado y no se cumplirá el objetivo marcado. Una vez introducidos el número de agentes, la aplicación indica cual es el porcentaje alcanzado según los parámetros introducidos (los que señalé en el primer post). Normalmente el número de llamadas entrantes varia dependiendo de la hora del día, las horas de entrar a trabajar de los usuarios los cambios de turno o las pausas para tomar el café, suelen reflejarse de manera clara en la gráfica de llamadas entrantes por tramo horario. En los picos esta claro que el dimensionamiento será mayor y los valles suelen ser los períodos más adecuados para que los agentes del Service Desk descansen o realicen otras tareas establecidas para la primera línea de soporte.
Habitualmente se suele realizar un dimensionamiento paralelo a los datos que nos requiere la calculadora de Erlang, pero ojo, no es el método más eficiente desde mi punto de vista. Os aconsejo que "juguéis" con el número de recursos, sobre todo estableciendo un sobredimensionamiento en aquellos tramos de más volumen de llamadas entrantes y todo lo contrario en aquellos tramos de menor actividad en las llamadas.
Por último os dejo unas apreciaciones personales:
- El dimensionamiento del Centro de Atención a Usuarios es una tarea dinámica. Varia y mucho dependiendo del mes o por ejemplo de la fecha de puesta en producción de una nueva aplicación.
- Es muy importante que tengamos claro que la mayoría de las aplicaciones que utilizan las fórmulas de Erlang, solo tienen en cuenta los tiempos de las llamadas entrantes. Otras tareas que realiza un agente o por ejemplo el tiempo de las llamadas salientes no se tienen en cuenta.
- Este tipo de herramientas no solo se pueden utilizar para establecer un dimensionamiento futuro, también es muy recomendable utilizarlas para saber en que hemos fallado una vez que tenemos datos reales de como ha ido una jornada.
- El que un recurso a tiempo parcial se incluya en el equipo de agentes del Service Desk, puede llegar a variar de forma considerable el objetivo alcanzado.
- El tiempo medio de llamada es un dato primordial para las fórmulas de Erlang. Trabajar con los agentes para bajar este tiempo influirá y mucho en el dimensionamiento del Service Desk.
Alberto Álvarez
No hay comentarios:
Publicar un comentario