¡Trabajar en TI es increíble! Tenemos la oportunidad de salvar el mundo varias veces al día, jugar con tecnología nueva e interactuar con nuestros increíbles usuarios finales (o clientes). A veces, sin embargo, podemos estar tan atrapados haciendo lo que creemos mejor, cuando en realidad nos hemos desviado o nos estamos perdiendo la forma más efectiva de restaurar el servicio.
Este artículo analiza los siete pecados capitales de la gestión de servicios de TI (ITSM) y la mejor manera de evitarlos o corregirlos.
1. Hacer tu formulario de incidentes demasiado complicado
La gestión de incidentes es una capacidad que debería estar al frente de cualquier modelo de soporte de TI. Es la práctica (utilizando la nueva terminología de ITIL 4) la que trata la gestión de todos los incidentes hasta la resolución y garantiza que no se pierda, ignore ni se olvide nada.
Para nosotros, una de las reglas de oro para cualquier proceso / práctica de ITSM es "siempre facilitar a las personas el uso de tu servicio". Pero esta es la cuestión. A veces, nos sentimos tan arrastrados por las herramientas y la automatización de ITSM disponibles que nos olvidamos de hacer que la notificación de incidentes sea lo más fácil posible. Por lo tanto, nuestros clientes tienen que navegar por IVR complejos o responder veinte preguntas en un formulario web para registrar una solicitud (y los agentes de la mesa de servicio probablemente harán lo mismo). No es bueno, y genera una barrera llena de fricción para soportar.
Por lo tanto, haz que tus formularios sean tan fáciles de usar como sea posible. No solicites demasiada información; de lo contrario, tus usuarios no se involucrarán y los agentes de la mesa de servicio quizá también omitan información. Con suerte, los detalles de contacto de tus clientes se llenarán automáticamente si inician sesión en su red, por lo que solo una breve descripción, el servicio afectado y la prioridad serán suficientes.
A veces, el enfoque más simple es el mejor y da más beneficios: TI obtiene más participación y menos quejas sobre la herramienta (o el proceso de contacto con soporte técnico), y los usuarios finales pueden registrar problemas rápidamente.
2. Olvidarse de la gestión proactiva de problemas
La gestión proactiva de problemas es un aspecto que muchos olvidan. Se trata de pensar en el futuro más que en actividades reactivas: utiliza las tendencias, los pronósticos y trabaja con los equipos de soporte para descubrir qué les preocupa. Es el costado de la gestión de problemas que analiza los problemas que de otra manera podrían pasarse por alto.
Ejemplos de actividades proactivas de manejo de problemas incluyen:
- Analizar tendencias: revisar incidentes anteriores y buscar temas comunes o recurrentes.
- Elevar cambios: para evitar que los incidentes se repitan o incluso ocurran en primer lugar. Por ejemplo, reinicios de mantenimiento, instalación mensual de parches y redireccionamiento de tráfico de red.
- Trabajar con tus equipos de soporte: pregúntales cuáles son sus inquietudes, si existe alguna deuda técnica o algo en riesgo de tener un tiempo de inactividad no planificado.
3. Enviar todos los cambios al CAB
Nada frustrará a tus equipos de soporte, y a otras partes involucradas, más que enviar todos los cambios al consejo asesor de cambios (CAB). No es necesario obligar a las personas a asistir a una reunión de dos horas cuando es algo que se puede cubrir en 30 minutos o menos. Además, seamos claros, puede que las personas que necesitas que se involucren se desanimen y rechacen el cambio.
Por lo tanto, al diseñar tus capacidades de cambio, trabaja con los equipos de soporte para identificar el trabajo que realizan día tras día. ¿Es fácil, de bajo riesgo y repetible? En caso afirmativo, felicitaciones, tienes un cambio estándar. Es algo que puede ser pre-aprobado y programado según sea necesario.
Si hay una mayor visibilidad y riesgo, entonces usa la autoridad delegada para que solo las áreas afectadas tengan que aprobar el cambio. En última instancia, guarda el CAB para los cambios grandes, importantes e impactantes.
4. No tener un modelo de datos para la gestión de la configuración
El no poder modelar tus servicios de manera efectiva puede llevar a imprecisiones y cambios de alcance.
Al crear tu plan de configuración, tómate el tiempo de mapear un servicio de punta a punta para que te acostumbres al flujo de trabajo e identifiques los atributos y dependencias correctos. Tener un servicio trazado actúa como una guía para la gestión de la configuración y es una excelente manera de comunicar los beneficios y los requisitos de trabajo diarios.
5. No priorizar la gestión del conocimiento
Lo sabemos, lo sabemos... es difícil trabajar en la mesa de servicio de TI. Siempre estás en movimiento para solucionar problemas, desde restablecimientos de contraseñas hasta incidentes importantes. Pero esta es la cuestión: si no estás priorizando la gestión del conocimiento, te estás perdiendo el truco.
Al crear una cultura de conocimiento compartido, estás empoderando a tu equipo. Utiliza el principio de desplazamiento hacia la izquierda pidiéndole a tus equipos de infraestructura y aplicaciones que compartan con soporte de segundo nivel algunos consejos que pueden usar para solucionar problemas. Y haz lo mismo desde el segundo nivel hasta el primer nivel.
Esto beneficia a todos porque los agentes de la mesa de servicio obtienen capacitación adicional y conocimientos técnicos, lo que libera al soporte de tercer nivel para abordar las cosas más complicadas.
6. Omitir la X en los SLAs
Todos hemos visto un acuerdo de nivel de servicio (SLA) de tipo “sandía”: es aquel donde todo parece maduro desde la perspectiva del contrato del cliente, pero la realidad es muy diferente.
Los SLA que no reflejan la experiencia empresarial real reflejan muy poco. En el mejor de los casos, ofrecen una visión inexacta del servicio de extremo a extremo y, en el peor, dañan la relación entre TI y la empresa.
En estos días, los SLA deberían ir cada vez más hacia la experiencia del usuario. Por lo tanto, debemos cambiar el paradigma desde mediciones y métricas enfocadas internamente hacia el impacto en el negocio, de los SLA a los XLA (acuerdos de nivel de eXperiencia).
Pregúntale a tus clientes: “¿Qué aspecto tiene lo bueno?” Trabaja con tus equipos de soporte para ver si puedes obtener métricas que reflejen el nivel de rendimiento ideal. Por ejemplo, cuánto tiempo se tarda en ejecutar una transacción o en actualizar la pantalla. Al incorporar la experiencia en tus acuerdos de nivel de servicio (o XLA), en lugar de simplemente citar el tiempo de funcionamiento del servicio frente al tiempo de inactividad, puedes controlar mejor lo que necesita el negocio y luego entregarlo.
7. No interactuar con CSI
Muchas personas (y organizaciones) no realizan una mejora continua del servicio (CSI) , aunque ITIL 4 ahora lo llama mejora continua, porque piensan que es demasiado desalentador o complicado.
Pero no tiene que serlo. En lugar de sentirte abrumado, empieza de a poco. ¿Qué pequeñas cosas puedes hacer para mejorar el trabajo diario? Las cosas a observar podrían incluir:
- Revisar el historial de incidentes antiguos con el personal de la mesa de servicio para que los agentes y técnicos puedan ver la foto completa.
- Buscar más oportunidades para cambios estándar y plantillas de cambio.
- Uso de Kanban en las reuniones del CAB para tener un buen registro.
Lo que sea que decidas hacer, que sea breve y ágil. Pruébalo, observa cómo han mejorado las cosas y luego vuelve a empezar.
¿Cuáles crees que son los pecados capitales más vistos de ITSM? Por favor, haznos saber en los comentarios.
