[28/02/2022] Si se hace bien, la gestión de servicios de TI (ITSM, por sus siglas en inglés) reduce los costos de gestión y de los activos de TI, aumenta la productividad y la satisfacción de los empleados, y ofrece a la dirección información sobre cómo se utilizan los recursos de TI para ayudar al negocio.
La ITSM son las políticas y procedimientos para diseñar y prestar servicios de TI a los usuarios finales. Va más allá del soporte de TI o del servicio de asistencia técnica y abarca toda la supervisión, la gestión y la resolución de problemas necesarios para mejorar constantemente los servicios de TI con el fin de satisfacer las necesidades de la empresa.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Una ITSM eficaz requiere, entre otras cosas, identificar qué componentes tecnológicos, como servidores y bases de datos, soportan qué aplicaciones, documentar adecuadamente ese conocimiento y afinar los procesos de soporte. Con el tiempo, a medida que estas relaciones y dependencias se hacen más complejas, la ITSM puede resultar excesivamente cara y centrarse demasiado en la tecnología y no en el negocio.
A continuación, se exponen algunas de las formas más comunes en que la ITSM puede ir mal y cómo evitarlas.
Queres abarcar mucho
"No hay que hacer demasiadas cosas demasiado rápido", señala Christian Hjortkjær, jefe de gestión de servicios y activos de TI del aeropuerto de Copenhague. Utilizando la plataforma ITSM de ServiceNow, "empezamos con la ITSM básica, como la gestión de incidencias y la gestión de cambios", pero limitamos su uso a plataformas como computadoras portátiles y software. Después, el aeropuerto fue ampliando poco a poco la ITSM a otros servicios, como la solicitud de tarjetas de acceso y permisos de aparcamiento. "Si hubiéramos ofrecido todos los servicios desde el principio, habríamos fracasado estrepitosamente porque requiere tiempo y recursos".
La creación de una base de conocimientos para los usuarios fue otra área en la que "hemos sido demasiado ambiciosos", anota, al no poner en marcha los procesos adecuados para actualizarla y mantenerla. Revisar las inexactitudes y la información obsoleta puede requerir tiempo y esfuerzo para corregir los problemas, agrega Hjortkjær.
"Hay que empezar por las funciones básicas y revisarlas periódicamente. Asegúrese de que éstas forman parte de la cultura de su organización de TI antes de saltar a actividades avanzadas como la IA", afirma Chris Matchett, director de investigación senior de Gartner. Documente y optimice los procesos antes de automatizarlos, sugiere. "Si el proceso está fundamentalmente roto, entonces la automatización solo puede darle el resultado equivocado una y otra vez".
Uno de los primeros pasos para Hjortkjær fue aprovechar ServiceNow para crear una fuente de datos común, comúnmente conocida como base de datos de gestión de la configuración (CMDB), "con enlaces bien documentados a las aplicaciones empresariales". El uso de la CMDB para rastrear, por ejemplo, qué servicios dependen de qué servidores ayuda al personal de TI a determinar qué interrupciones son más críticas, para empezar a recuperarlas y para notificar rápidamente a los usuarios de esas aplicaciones sobre el problema", indica.
Los clientes que utilicen el marco ITIL (Information Technology Infrastructure Library) para la gestión de servicios de TI deben asegurarse de crear un catálogo de servicios de TI y unos procesos de gestión claros y bien definidos, afirma Rubén Ávila Calvo, director de tecnología de la empresa de inspección y ensayos Applus. ITIL "implica tener una definición clara de los procesos, las funciones y las responsabilidades, en la que cada etapa esté debidamente documentada, las responsabilidades estén claras y exista un procedimiento que garantice la prestación del servicio con un SLA [acuerdo de nivel de servicio] comprometido. No hacerlo puede suponer mayores costos y un servicio de menor calidad, ya que los problemas de servicio se derivan al personal equivocado", afirma.
Cecile Blackburn, directora de servicios globales para usuarios finales de la empresa de productos químicos agrícolas Corteva, recuerda un fin de semana en el que un ticket de asistencia a un usuario fue enviado a un equipo de asistencia que no trabajaba durante el fin de semana, en lugar de al equipo que sí lo hacía. "Realmente interrumpimos el negocio debido a la dificultad de equiparar" el servicio del negocio con los componentes de TI que proporcionaban ese servicio, anota.
Descuidar el negocio
Es tentador centrarse en la "TI" de la ITSM, pero su verdadero objetivo es prestar servicios empresariales. Si no se diseña el ITSM pensando en la empresa y no se describen sus ventajas en términos empresariales, se reduce su adopción y su uso resulta más confuso para la empresa.
"Si me siento en la empresa, no me importa realmente cuántos incidentes ha tenido TI", anota Hjortkjær. "Lo único que me importa es mi aplicación, cuántas incidencias tiene mi aplicación y cómo las he resuelto". Solo puede proporcionar informes significativos al director general "si puedo vincular mis incidencias al elemento de configuración correcto, que a su vez está conectado a la aplicación empresarial correcta", y poner en contexto cómo esos servicios ayudan a mejorar las operaciones del aeropuerto.
Un reto que Corteva ha abordado utilizando ServiceNow ITSM es cómo conectar componentes de TI dispares, de modo que el propietario de la aplicación no tenga que "perseguir a los equipos de servidores, bases de datos y firewalls solo para crear una aplicación que se entregue a la empresa. Esto supone una gran pérdida de tiempo. Hay retrasos en el registro de los tickets y en la búsqueda de la solución del problema", anota Kshitij Bahadur, jefe de integración de servicios empresariales en Corteva.
Eugene Mejía, subdirector de tecnología de la ciudad de Gilbert (Arizona), y su equipo hicieron de la mejora de la experiencia de los 1.600 empleados de la ciudad, un motor empresarial clave para sus esfuerzos de ITSM. Él y el equipo de liderazgo de TI utilizan encuestas mensuales a los empleados para medir su éxito en el desarrollo de funciones, como la calidad de las interfaces web y las aplicaciones móviles para facilitar el trabajo remoto. Utilizan Cisco Unified Communications Manager y Webex Contact Center para gestionar las colas de llamadas para las solicitudes de servicio y la resolución de problemas.
Este enfoque en la experiencia de los empleados es "muy convincente" para los ejecutivos de nivel C que deben financiar la ITSM, señala el analista de Forrester, Will McKeon-White.
Falta de comunicación
Una comunicación poco clara hace mucho más difícil explicar el valor de la ITSM a la empresa, organizar adecuadamente los esfuerzos de ITSM, establecer las expectativas para su despliegue y asegurar una financiación adecuada para ello.
Hjortkjær sugiere utilizar la CMDB para asignar los componentes de TI a las aplicaciones de negocio, asignar la propiedad de esas aplicaciones tanto a los patrocinadores de TI como a los de negocio, y pedir a esos patrocinadores que expliquen el papel de cada aplicación a la empresa, así como la mejor manera de utilizarla y, eventualmente, cuándo reemplazarla.
Thomas Smith, director de telecomunicaciones y soporte informático del proveedor de servicios funerarios Service Corp. International, recomienda ser sincero con los calendarios. Uno de los mayores errores que cometimos en el pasado, y que seguimos cometiendo, es decir: "Lo haremos en tres meses. Cuatro meses después, todo el mundo sigue esperando tres meses", sostiene. Recomienda entender las deficiencias de la herramienta o los servicios ITSM, "y decir a los propietarios de los procesos de negocio `Tenemos un plan para solucionarlo'".
Calvo dice que los términos de los SLA, como los que creó utilizando la plataforma HelixITSM de BMC, pueden ayudar a establecer las expectativas y reducir la frustración de los usuarios que "piensan que todo debe resolverse lo antes posible".
Una comunicación clara también puede ayudar a los propietarios de las empresas a ponerse de acuerdo sobre el momento en que la personalización merece la pena por los futuros dolores de cabeza de mantenimiento que crea, señala McKeon-White. "Todo el mundo está tratando de satisfacer las necesidades de la organización de la manera que ellos entienden. Pero puede que no estén alineadas con cosas como los resultados de los clientes, la reducción de la gestión de riesgos, etc.", agrega.
También es necesario, señala Smith, definir específicamente lo que los usuarios necesitan en las herramientas de soporte ITSM como la plataforma Ivanti Neurons for ITSM que él utilizó. Esto puede incluir, por ejemplo, "lo que un usuario está viendo en su formulario W-9, en una interfaz de beneficios en la web, o lo que quieren decir con "la pantalla sigue fallando"", anota. Estos requisitos pueden ser difíciles de concretar porque, por ejemplo, "un miembro del personal de RRHH puede no entender la diferencia entre una incidencia y una solicitud de servicio". Consulte a los usuarios de TI y de la empresa para compartir términos y definiciones, y asegurarse de que todos entienden lo que significa cada requisito y han acordado su prioridad.
Personalizar en exceso
McKeon-White considera que el exceso de personalización es uno de los mayores retos que ve en los proyectos de ITSM. Los clientes modifican los sistemas ITSM "por lo que creen que son razones legítimas", indics. A medida que se realizan más cambios en el sistema, y los empleados que los realizaron abandonan la empresa con el tiempo, "es imposible reconstruir qué cambios se hicieron o por qué, lo que hace que el sistema ITSM sea más difícil de gestionar y actualizar.... El problema no es tanto cada función individual que se personaliza, sino cómo funcionan todas esas personalizaciones juntas", señala. Debido al número y la complejidad de las interacciones entre los componentes de una plataforma ITSM, indica, "si quiere cambiar algo no puede, porque si toca una cosa se romperá otra".
Bahadu está de acuerdo y dice que a menudo "varios equipos de TI establecen sus propias prácticas de soporte, algunas más sólidas que otras". Recomienda resistirse a la presión para implantar estos procesos como excepciones. "Un día puede darse cuenta de que tiene más excepciones de las que puede manejar, y la herramienta se ha personalizado tanto que se vuelve difícil de mantener".
"En lugar de hacer una gran personalización, queremos usar tantos flujos de trabajo fuera de la caja como podamos, y cambiar nuestros procesos y flujos de trabajo", comenta Mejía, porque los creadores de ITIL y las herramientas de ITSM "son los expertos".
Despedir y olvidar
La ITSM no puede implantarse completamente como un proyecto limitado en el tiempo", comenta Matchett. No proporcionar una gestión y formación continuas puede reducir la eficacia de ITSM, especialmente a medida que cambian los requisitos del negocio y la propia herramienta ITSM, añade.
La mayoría de las herramientas de ITSM se ofrecen como software como servicio, lo que significa que es el proveedor de software y no el cliente quien mantiene la infraestructura subyacente. Sin embargo, señala McKeon-White, los clientes deberían planificar que "una o dos personas se encarguen de la optimización continua, ya sea atendiendo a los clientes, mejorando la resistencia, reduciendo los riesgos de cambio, mejorando los procesos de gestión de incidentes, asegurándose de que todos los que ayudan a resolver el problema reciben toda la información correcta y entendiendo el estado del trabajo en curso".
Hjortkjær afirma que el ITSM requiere una formación continua de los usuarios en los nuevos procesos, especialmente cuando se pasa a plataformas más avanzadas. Éstas pueden "demostrar las funciones geniales, las funciones extravagantes, los impactos que el ITSM puede aplicar a su trabajo diario, desde los cuadros de mando hasta los informes y los accesos directos... (las) muchas formas en que puede configurar su pantalla de ITSM para ser más productivo y ayudarle en su trabajo diario".
Como ocurre con tantas iniciativas de TI, la gestión de servicios funciona mejor cuando se diseña en torno a las necesidades de la empresa, se comunican claramente sus valores, no se incurre en una deuda técnica oculta a largo plazo y se gestiona adecuadamente a lo largo del tiempo.
Basado en el artículo de Robert Scheier (CIO) y editado por CIO Perú
Puede ver también: