La Gestión de Servicios de IT (ITSM) suele parecer sencilla en la teoría: se definen los procesos, se eligen las herramientas adecuadas, se alinea con un marco como ITIL, y listo. Pero cuando llega el momento de llevar todo a la práctica, aparecen las complicaciones. Según nuestra experiencia en la implementación de este enfoque en diversas escalas, la mayoría de las organizaciones se encuentran con los mismos puntos de fricción, algunos esperados y otros no.
Por eso, describimos los ocho desafíos comunes en ITSM. Y, lo que es más importante, mostramos cómo superarlos de forma tal que resulte beneficioso tanto para el equipo como para el negocio; y no quede simplemente en un enunciado hipotético.
Así que repasemos esos obstáculos.
Los 8 problemas comunes en la implementación de ITSM y las formas de superarlos
Algunos de los problemas comunes en la implementación de ITSM surgen al principio del proceso, mientras que otros despuntan una vez que el sistema ya está operativo. En ambos casos, tienden a reflejar las diferencias entre cómo se utiliza la plataforma y cómo deberían funcionar las mejores prácticas de la Gestión de Servicios de IT.
El reconocimiento de esos obstáculos desde el comienzo facilita su corrección antes de que las soluciones se tornen más difíciles.
1. Funciones y responsabilidades poco claras
Incluso cuando los procesos se encuentran bien documentados, es habitual que los equipos se atasquen o las tareas queden desatendidas por cuestiones de propiedad, porque nadie sabe con certeza quién es el responsable de cada trabajo. Peor aún, varias personas asumen que otras se están encargando de ello.
Esto suele ocurrir cuando las funciones están definidas de forma imprecisa o las responsabilidades cambian, pero no se comunican adecuadamente. Por ejemplo, los escalamientos de los incidentes pueden estancarse si el service desk no sabe qué grupo del nivel dos debe tomarlo o si no existe una matriz RACI clara para la aprobación de los cambios.
En uno de nuestros seminarios web, el Director de Relaciones Comerciales, Jyoti Chopra, señaló cómo la falta de comunicación abierta y las relaciones débiles suelen provocar estos fallos. Si los individuos no abordan las tensiones o no comparten la información de manera transparente, el proceso quedará trunco.
En consecuencia, los equipos tienen que hablar abiertamente, resolver los conflictos y contar con conexiones transparentes.
Además, cada servicio, procedimiento y tarea requiere una persona designada, así como roles que hay que revisar ante cualquier modificación en la estructura de la organización.
Un simple Procedimiento Operativo Estándar interno del service desk o una etiqueta de propiedad dentro de la herramienta de ITSM constituyen grandes elementos de ayuda.
2. Deficiente categorización y enrutamiento de las solicitudes
Si los tickets llegan a la fila equivocada, se estanca el proceso. Y si el catálogo de servicios es demasiado amplio, técnico o mal estructurado, los usuarios finales no sabrán dónde enviar sus solicitudes.
Los service desks donde la mayoría de los tickets se notifican como genéricos del tipo “problema informático” conllevan clasificaciones más lentas, cargas de trabajo desequilibradas y métricas poco fiables.
Un buen punto de partida para resolver este inconveniente es simplificar los formularios de peticiones y utilizar la lógica condicional para guiar a las personas a través de las entradas correctas.
Las reglas de automatización representan otro componente orientado a asignar las solicitudes en función de la categoría o las palabras clave. De este modo, se reducirá el esfuerzo manual y mejorará el enrutamiento inicial.
3. Uso inconsistente de la plataforma de ITSM
Aun con una herramienta adecuada, si las personas la utilizan de forma inconsistente o la ignoran por completo el proceso resultará fallido. Lo mismo sucede cuando un equipo prefiere el uso de canales paralelos, como Slack o el correo electrónico, en vez de la plataforma específica. En cualquier caso se crean puntos ciegos, además de que los reportes resultan inútiles.
Las soluciones de ITSM solo generan valor cuando operan como centro neurálgico, lo cual no significa la imposición de reglas estrictas sin flexibilidad, sino el establecimiento de expectativas y las propuestas de formación.
Otro consejo es crear hábitos de ejecución de forma gradual, integrando la herramienta a los flujos de trabajo diarios del servicio; y destacando cómo beneficia directamente al usuario, ya sea mediante tiempos de respuesta más rápidos, menos cambios de contexto o una comunicación más clara.
Lectura recomendada
Leer artículo
9 ideas para la automatización de procesos que agilizarán el soporte de IT
4. Defectuosa Gestión del Conocimiento
Cuando los equipos dependen de los saberes orales, todo se dificulta. Esto se hace más evidente durante la incorporación, los traspasos o la rotación de personal, momentos en que desaparece el contexto valioso y los profesionales pierden tiempo redescubriendo soluciones que ya se conocían.
Además, si la organización dispone de una base de conocimiento, pero la documentación está desactualizada, es compleja la búsqueda o no se encuentra bien mantenida, entonces termina por ignorarse.
Teniendo en cuenta que la Gestión del Conocimiento debe ser una parte viva del proceso de ITSM, no una idea de último momento, incentiva a los agentes a registrar inmediatamente los problemas resueltos, programa un tiempo para revisar y actualizar los artículos, realiza un seguimiento de los saberes que se están utilizando e identifica los gaps basándote en los temas repetidos de los tickets.
5. Falta de alineación con el negocio
Otro de los desafíos comunes en ITSM es su falta de coordinación con el negocio. Por caso, los equipos de servicio suelen centrarse en los SLAs, el volumen de tickets y los tiempos de resolución como indicadores válidos, pero no siempre reflejan aquello que necesita la empresa.
Así, el cumplimiento de los objetivos de los SLAs puede ser óptimo. Sin embargo, los usuarios finales seguirán frustrados si los problemas clave no se priorizan de forma correcta.
Para mantener la coherencia, entonces, involucra a las partes interesadas del negocio en las conversaciones sobre prioridades, definiciones de servicios y criterios de éxito. No te limites a informar sobre el rendimiento; conecta los puntos con el impacto en la empresa.
Eso significa, por caso, mostrar cómo el tiempo de inactividad afectó a los ingresos o si la automatización de una solicitud redujo los lapsos de espera para el onboarding.
6. Gestión del Cambio reactiva
La Gestión del Cambio tiende a formalizarse con el tiempo. Lo constatamos cuando los equipos abordan las transformaciones de manera informal o retroactiva. Pero a medida que los sistemas crecen y se involucran más profesionales, los riesgos se multiplican: una actualización mal comunicada puede provocar una interrupción del servicio que afecte a docenas de usuarios.
Para evitarlo, la Gestión del Cambio debe introducirse lo antes posible y ampliarse gradualmente. Eso no significa que sea necesario celebrar reuniones completas del CAB desde el primer día: empieza con un proceso sencillo para revisar, documentar y programar las transformaciones en un sistema compartido. A partir de ahí, añade flujos de aprobación, evaluaciones de impacto o plantillas de modificaciones estándar a medida que evolucione tu entorno.
7. Soluciones temporales sin un abordaje de las causas subyacentes
Si bien la Gestión de Incidentes y Problemas presentan fines diferentes, a menudo se abordan de la misma manera. Como resultado, las soluciones temporales se registran como finales y nunca se llegan a las causas verdaderas.
Cuando existe presión para resolver los tickets rápidamente, es fácil confundir ambos conceptos. Sin embargo, la estabilidad a largo plazo depende de identificar patrones y tratar las causas subyacentes. Si el mismo incidente se repite, es probable que haya un problema que requiera un análisis, no otra solución provisional.
Una buena práctica es definir un umbral a partir del cual un conjunto de incidentes desencadena una investigación del problema. Incluso un informe básico de aquellos recurrentes revelará dónde se requiere más atención.
Lectura recomendada
Leer artículo
Ticket de incidente vs. ticket de problema: ¿cuál es la diferencia?
8. Reportes demasiado superficiales o complejos
Los reportes suelen caer en alguno de los dos extremos: son métricas básicas con escasa información o paneles sobrecargados que nadie lee. Ambos casos conducen al mismo resultado: decisiones basadas en datos incompletos o malinterpretados.
Entonces hay que preguntarse: “¿Quién lee el informe y qué necesita obtener de él?” Un agente, por caso, desea conocer las tendencias del tamaño de la fila. A un gerente le interesa más el incumplimiento de los SLAs y la antigüedad de los trabajos pendientes. Y los ejecutivos suelen requerir resúmenes con contexto empresarial.
En conclusión, crea reportes con diferentes vistas para los diversos públicos y revísalas periódicamente. A su vez, vincula dichos informes a las acciones: Qué significan los números y las sugerencias de acciones a concretar a futuro.
Conclusión
Incluso con las herramientas y los marcos de trabajo adecuados, la implementación de la Gestión de Servicio de IT resulta compleja. De hecho, los desafíos comunes en ITSM abordados en este artículo no provienen de asuntos técnicos, sino de la falta de alineación entre las personas, los procesos y las prioridades. La buena noticia es que estos obstáculos se pueden solucionar.
Con responsabilidades claras, prácticas coherentes y un enfoque en los resultados, la Gestión de Servicios de IT comenzará a aportar un valor real.
Y recuerda que la ITSM no se trata de cerrar tickets, sino de mejorar las prestaciones.
