Continuando nuestra discusión sobre “los 4 pecados capitales de la Gestión de servicios” es importante que nos concentremos no solamente en reconocer nuestras lineas de pensamiento, sino también en los pasos que se pueden seguir para combinar nuestros datos e instintos con el objetivo de maximizar resultados.
Hasta ahora, con cada segmento de esta serie les hemos brindado algunas sugerencias y trucos, pero hoy les presentamos una lista mas exhaustiva de “How to's”
Aquí vamos…
Cómo: Utilizar las emociones para disparar acciones
Cuando uno esta balanceando instintos y los datos va a tener, en el mejor de los casos, una mezcla 50/50 de emoción y lógica es la clave para adoptar las emociones como disparadores de acciones lógicas. Aquí hay algunos trucos que puede comenzar a utilizar ahora mismo:
- En el área de IT, cuando ocurre una emergencia es fácil perder el foco en el pánico del momento. Obviamente la prioridad es resolver el problema que se nos presento, pero es importante asegurarse de documentar absolutamente todo lo que uno pueda en el camino (esto sera MUY util en el futuro para actividades como Gestion de problemas).
- Registrar el tiempo invertido por cada miembro del equipo que estuvo involucrado en resolver el incidente. Si el personal no esta en el habito de cargar el tiempo invertido – es crucial solucionar esto! Un registro preciso del tiempo es primordial cuando se trata de planear en el futuro todas las decisiones de ITSM. Recuerda, si no lo estas midiendo, no debes hacerlo!
- Acá es donde su documentación entra en juego. Haciendo una autopsia de estos incidentes (pero no esperes demasiado… acá esta el porque). Durante cada autopsia, hay que buscar reconocer que es lo que su equipo hizo bien, pero también donde se podría haber hecho un mejor trabajo. Encontraras que puedes aprender mas de los errores de tu equipo que de sus éxitos.
Comó: hacer reportes que identifiquen puntos debiles
Un problema común para la mayoría de los gerentes de servicio es que sus tableros y reportes enlatados raramente muestran todo el panorama. Por lo cual, uno tiene que ser creativo con sus métricas de análisis personalizadas, y de esta forma poder ayudar al que necesite tomar una decisión presentándole toda la información pertinente.
Aquí hay 3 reportes que todos los gerentes de un Service Desk deberian utilizar para diagnosticar la salud de su service desk y algunas acciones que uno puede hacer luego de estos preparándose para el futuro.
- Tiempo de resolución por tipo de solicitud
- Excavar los tipos de solicitud resueltos mas rápidos buscando conocimiento del por que.
- Se puede automatizar parte del proceso? De que otras formas puede eliminar las tareas sencillas?
- Refuerce sus FAQs, es una de las formas mas fácil de prevenir que las solicitudes mas comunes aparezcan en su sistema.
- Mire mas de cerca las solicitudes que tienen grandes tiempos de resolución. Diagnosticar y documentar las causas y cualquier elemento que traiga complicaciones en sus procesos – esta información sera utilizada en el futuro.
- Tiempo de resolución de los técnicos
- Mire atentamente, sus mejores técnicos están ocupándose de grandes cantidades de trabajo?
- Sus técnicos mas habilidosos, están mostrando tiempos de resolución que son impactados por tener asignadas los problemas mas complejos?
- Siempre habrá técnicos que tendrán problemas manteniendo el ritmo, y estos pasos lo demostrara. Se puede ofrecer entrenamiento adicional? Tal vez pueda hacer que un técnico con dificultades este en rol de aprendiz de uno de alto rendimiento. Busque por formas de cerrar la brecha!
- Problemas mas comunes
- Asegure que le esta dedicando suficientes recursos a los pedidos mas comunes.
- Deberá limpiar los tipos de problema que no estan siendo utilizados y crear mas tipos de forma padre/hijo para los que se encuentran muy presentes.
- Si tiene que dependen de la época del año (Por ejemplo, problemas con el Aire Acondicionado en verano), asegúrese de darle diferentes pesos.
(Si esta buscando por una lista mas detallada de las metricas para el manejo de incidentes, les recomendamos mirar este post)
Comó: Navegar las solicitudes internas
Una vez que uno empieza a refinar la química, va a haber una oposición del equipo, no dejes que esto te desaliente del objetivo. Si incorpora principios de la metodología Agile y promueve la auto gestión, puedes transformar la oposición en algo positivo.
El siguiente es un ejemplo de como utilizar Scrum para organizar su equipo de gerencia de servicios.
Product Owner: Esta es la persona que es simultáneamente responsable por la visión y dirección. En el caso de ITSM, seria alguien como el director de IT o el CIO. Tenga en cuenta que este rol solo puede pertenecer a una persona – no comités!
Scrum Master: Esta persona es la responsable de asistir y facilitar el trabajo a todos los involucrados. Es fácil asumir que esta persona es el líder del proyecto, pero no lo son. El Scrum Master es el engranaje que mantiene todo funcionando. Son los responsables de la visión del dueño del producto se implemente en el día a día, y a su vez están a cargo de documentar la devolución del resto del equipo y compartirla con el dueño.
Scrum Team: Imagina al Scrum Team como tus técnicos y otros encargados en la linea frontal. Estas son las personas de su organización que tienen la relación mas cercana con los usuarios finales y son la cara de la visión del Product Owner.
Si sigue el método Scrum con su equipo de manejo de servicios, así es como debería verse en acción:
Planeamiento para un Sprint:
- Comienza con Sprint de dos semanas (un periodo de tiempo fijo con objetivos determinados, por ejemplo mejorar el tiempo de resolución de incidentes críticos). Si el plazo es muy corto no hay suficiente tiempo para lograr el cambio. Si es muy largo, estas limitando la posibilidad de ser ágil.
Stand-ups diarios:
- Darle a cada uno de tus técnicos unos minutos cada día para expresar la situación actual en la linea frontal y permitirles organizarse para solucionar los inconvenientes del día.
- El Product Owner debería atender al comienzo, pero necesitan escuchar mas que hablar. Permita que el Scrum Master dirija el flujo, para eso están ahi.
- Los Scrum Masters necesitan documentar todos los puntos no emergentes - esto sera útil en el futuro.
Demonstración
- Al finalizar cada periodo de 2 semanas, permitale a los miembros de su Scrum Team demonstrar sus contribuciones individuales a la vision del Product Owner.
- El Product Owner necesita estar listo para hacer las preguntas difíciles, pero no solo por el hecho de poner a los técnicos en un una situación complicada. Para estar en el camino correcto, las preguntas deben estar orientadas hacia “Hay alguna mejor forma de hacer esto?”.
Restrospectiva
- Abiertamente discutir que salio bien, y que no. Cuando se encuentren conversando las que no salieron de acuerdo al plan, obtenga la opinión de todos los participantes sobre el por que.
- Recuerda esos puntos no emergentes? El Scrum Master necesita planteárselos al equipo para que estos puedan decidir que tan importante son. Los puntos mas importantes necesitan ser encarados en el siguiente sprint mientras los de menor prioridad pueden ser dejados de lado por el momento.
- Repita este proceso y estará bien encaminado en el manejo del balance del entre instintos ITSM y sus datos!
Comó: Crear las políticas para ITSM
Problemas que son de naturaleza potencialmente sistemática pueden poner trabas en el camino hacia los objetivos de su negocio, así que generar un conjunto de buenas políticas es lógicamente el siguiente paso. Si siguieron los pasos anteriores, van a tener una solida idea de que funciona y que no, y ya los problemas mas fáciles fueron solucionados.
Ahora es donde su capacidad para tomar decisiones entra en juego. Al menos una vez al mes necesita tener una reunión con el Product Owner, Scrum Master y los encargados de tomar decisiones importantes con objetivo de mejorar las políticas. Es tentador involucrar al Scrum Team, pero no lo haga! Necesitan dedicar toda su energía y tiempo hacia la ejecución del proyecto.
Repita la discusión de políticas cada cuatrimestre para mantenerse actualizado. Las primeras reuniones necesitaran mas participación , pero eso esta bien. A medida que el equipo ejecuta y resuelve problemas, se encontrara en una mejor posición para planear el futuro en vez de lidiar con emergencias diarias.
Conclusión
Tenemos 2 artículos mas en las series, pero vamos a continuar nuestra conversación con un Webinar en vivo en las próximas semanas. Asegúrese de compartir sus pensamientos con nosotros en las redes sociales, podríamos incluir sus sugerencias en nuestra presentación.
