Escribiendo nuestro artículo anterior, el cual analiza tres suposiciones erróneas sobre la gestión de servicios de TI (ITSM) y las brechas entre expectativa y realidad, nos dimos cuenta de que hay muchas más situaciones en que las personas y organizaciones fácilmente se confunden en este plano. Tal vez porque se enfrentan a acciones difíciles de ejecutar o simplemente porque no habría que ejecutarlas. Por ende, decidimos escribir dos artículos más acerca del tema, explorando en esta ocasión otros tres supuestos erróneos de ITSM.
Expectativa #4: La gestión de actualizaciones es un exceso si ya haces gestión del cambio
OK, primero lo primero. ¡La gestión del cambio (o “control del cambio” si es que estás en el mundo de ITIL 4) es increíble! Quiere decir que tienes el control de tus activos y que el trabajo planificado está siendo evaluado, aprobado y verificado de manera segura y transparente. Pero llega cierto punto en el que, si no tienes un plan para la gestión de actualizaciones, tu proceso de cambio va a tener que encargarse de todo. Se convertirá en un obstáculo, en especial si tu comité asesor de cambios (CAB) está intentando entender todo - desde detalles del software a validaciones y revisiones de código.
Y aquí es donde entra en acción la gestión de actualizaciones. Es la práctica que crea y modifica servicios y atributos disponibles para nosotros. La mayoría de las organizaciones empiezan con la gestión del cambio para la actividad del cambio estructural, por ejemplo, reinicio de servidores o mejoras en la red de conmutación. Cuando se necesitan cambios complejos en el código del software es generalmente cuando la gestión de actualizaciones pasa al frente.
Los aspectos que generalmente caen bajo el área de la gestión de actualizaciones son:
- Política de actualización – ¿Qué constituye una actualización?¿Qué tan seguido vamos a implementarlas?
- Planificación – ¿Cuál es la ventana de actualización? ¿Qué equipos técnicos tienen que estar involucrados? ¿Quiénes tienen mayor responsabilidad dentro de la organización?
- Diseño y construcción – ¿Cumple con el documento de requerimientos? ¿Tenemos a alguien en la organización que lo verifique?
- Evaluación – ¿Qué ambientes se necesitan? ¿Tenemos evaluaciones planificadas? ¿Podemos usar scripts y automatizaciones?
- Aceptación – ¿Qué criterios se tienen que cumplir para pasar las validaciones?
- Planificación de crecimiento – ¿Cómo se va a lanzar la actualización? ¿Big bang? ¿En fases? ¿Esquemas piloto?
- Revisión y cierre – ¿Qué salió bien y qué hay que evitar la próxima vez?
La gestión de actualizaciones se hace cargo de los detalles para que, cuando el lanzamiento llegue al comité asesor de cambios, todas las partes complejas y móviles ya hayan sido procesadas, aliviando la carga de la gestión del cambio para que pueda dar la aprobación final y planificar el lanzamiento de la actualización en un tiempo acordado mutuamente.
Expectativa #5: La gestión del conocimiento lleva demasiado esfuerzo
Construir una práctica de gestión del conocimiento no necesita ser complejo; de hecho, empezar a pequeña escala y de manera ágil es mejor. Empieza por los incidentes registrados con más frecuencia por área e identifica los puntos críticos. Encuentra tu “top ten” y trabaja con equipos de soporte para ver si hay alguna solución rápida o cualquier tipo de solución que se pueda aplicar en el primer punto de contacto.
Ejemplos incluyen:
- Restablecimiento de contraseña – Asegúrate de que todos conocen el estándar actual y las mejores prácticas de seguridad, y de que existan enlaces para autoservicio de ser necesarios.
- Problemas de red – ¿Todos en tu mesa de servicio saben cómo chequear la conexión de la red y reiniciarla de ser necesario?
- Email – Seamos sinceros, si no es la contraseña o “se cayó Internet”, es el email. ¿Todos saben cómo brindar soporte al cliente de correo elegido y hace tareas básicas como agregar nuevas bandejas o compartir calendarios con otros miembros del equipo?
- Impresoras – Ten una lista de impresoras locales por departamento, de modo que si alguien llama preguntando cómo imprimir, simplemente lo conectas a la impresora correcta en lugar de perder 20 minutos tratando de encontrar la más cercana a su departamento.
Expectativa #6: Solo necesitas cumplir con el SLA
Todos hemos estado en reuniones de revisión en donde el SLA siempre está cumplido, pero nadie se siente particularmente bien con el nivel de servicio prestado.
No todo se limita a prestar un servicio al pie de la letra del SLA; esto hace que las reuniones de revisión sean contenciosas, y las relaciones definitivamente importan.
Si nunca vas más allá de lo esperado por el cliente, ¿qué va a pasar en el futuro? No estamos hablando solamente de renovación de contratos. ¿Qué pasa si necesitas algo de ellos? Por ejemplo, si hay un downtime no programado y tienes una relación fuerte con el cliente, va a mostrar más tolerancia y van a poder trabajar juntos para solucionarlo.
¿Si tu relación no es sobresaliente y algo va mal? Bueno, es una historia diferente. Hemos visto pedidos de crédito por servicios, penalidades y hasta terminaciones de contrato. Mira tu valor agregado y piensa qué cosas te diferencian de la competencia. Son las cosas pequeñas las que cuentan, porque cuando haces cambios pequeños, con el tiempo se acumulan y generan una gran mejora.
¿La moraleja de la historia? Siempre da lo mejor de ti, sin importar qué dice el SLA. Suena simple, pero vas a tener una mejor reputación por tu nivel de entrega de servicio.
¿Que otra expectativa errónea de ITSM agregarías? Por favor haznos saber en los comentarios. Ya tenemos tres más en mente que incluiremos en el siguiente post.
