¿El mejor Software de Service Desk?

Una de las preguntas más frecuentes que nuestros clientes nos hacen es: ¿Cuál es el mejor Software de Service Desk en el mercado? Siempre les respondemos lo mismo: Depende de tu organización.

En una ocasión particular, un nuevo cliente nos contactó solicitando apoyo. Tenía 7 meses tratando de implementar un Software de Service Desk para 3 procesos: Incident, Request y Problem. Contactó a varios proveedores y solicitó cotizaciones. Después comparó los materiales de marketing de cada herramienta, preparó una tabla comparativa y la revisó con su líder. Combinando la tabla comparativa y los presupuestos, tomaron una decisión.

El proveedor/distribuidor de la herramienta en México para una empresa Americana, procedió a hacer su parte del trabajo: instalar la herramienta y compartir la documentación. Una vez concretada la compra empezaron las preguntas: ¿Cómo puedo usarla con mi sistema de monitoreo? ¿Cómo puedo cambiar las tipificaciones del servicio? ¿Cómo puedo configurar notificaciones adicionales? Afortunadamente el proveedor contaba con planes de consultoría sobre la herramienta. Desafortunadamente para nuestro cliente, eso no fue contemplado en el presupuesto original y no pudo asegurar fondos para concretar esfuerzos de consultoría adicional.

Las siguientes semanas (posteriormente me contó) fueron algunas de las más estresantes de su vida: Áreas operativas de la empresa demandaban ver los beneficios que se promovieron al anunciar la compra de la herramienta, números estadísticos descuadrados, falta de seguimiento a los servicios de usuarios… Un caos absoluto y en el centro: el departamento de TI.

Nuestro cliente no entendía el por qué las cosas pudieron salir mal. Después de todo compró una herramienta líder en el mercado de acuerdo a publicaciones de la industria y no era nada barata. Durante 3 meses intentó resolver el problema por su cuenta hasta que decidió buscar ayuda externa.

Al final, su iniciativa pudo sobrevivir y la organización pudo tolerar casi 1 año de retraso. Sin embargo, la reputación del departamento de TI nunca fue la misma.

Antes de comprar

El mercado ha provocado que existan numerosas soluciones para las necesidades de gestión de servicios de TI en las organizaciones, tantas que frecuentemente el proceso de selección cae en lo abrumador. Una decisión puede ser la diferencia entre potencializar iniciativas de implementación de mejores prácticas y el perder todo el impulso y confianza por parte del negocio.

El enfoque y los esfuerzos deben ir orientados hacia el proceso de selección, si lo hacemos correctamente, el riesgo de cometer un error se reduce considerablemente. Un proceso desordenado o ausente nos pone en riesgo de caer en tácticas de marketing que pudieran favorecer a otros intereses que no son los de la organización misma.

Lo mejor es que antes de si quiera voltear a ver qué hay en el mercado, realicemos una auto evaluación para asegurarnos de que los procesos que queremos soportar con la herramienta tengan las siguientes características:

• Están alineados con la estrategia organizacional
• Satisfacen a una o varias necesidades (no siempre es obvio)
• Son medibles de una manera relevante
• Son sujetos a revisiones periódicas
• Están documentados

Aún si se pretende adquirir una herramienta para implementar un proceso, debemos de ser capaces de diseñarlo antes de que la herramienta sea un factor. Es importante recordar que la herramienta no es un proceso como tal, sólo es una manera de llevar a cabo un proceso de una manera más eficiente. Si el proceso es propenso a errores, sólo vamos a cometer más errores por minuto.

Algo que frecuentemente olvidamos es que los Software de Service Desk existen para apoyar procesos y no de otra forma. Nuestra preocupación principal debe ser el encontrar una herramienta que se adapte lo mejor posible a la visión, cultura y procesos de la organización. Un error común en la selección de Software de Service Desk es el buscar que el proceso se adapte a lo que la herramienta más popular del momento ofrece.

Una de las cosas más importantes a considerar al emprender la búsqueda es asegurarnos de que tenemos una visión clara de qué estamos buscando y para qué. Deberíamos de ser capaces de articular esta visión claramente y nunca perderla de vista.

Desarrollo Interno vs Off The Shelf

La primera pregunta que nos debemos responder a la hora de realizar un ejercicio de selección de Software de Service Desk es: ¿Quiero y puedo desarrollar la herramienta internamente o me conviene más comprar una ya existente?

Sin temor a equivocarme, puedo decir que para la absoluta mayoría de los casos, comprar un producto completo es la mejor opción para la mayoría de las organizaciones. El desarrollo interno debería estar limitado a casos muy específicos como que la herramienta sea parte de una estrategia del negocio o que no hay ningún producto en el mercado que pueda satisfacer las necesidades más importantes de la organización. Recordemos que en el centro de la filosofía de Service Management está la idea de que buscamos evitarle a la organización costos y riesgos innecesarios.

En la mayoría de las situaciones, las organizaciones tienen usos muy particulares para un Software de Service Desk, y el desarrollar uno internamente representa varias implicaciones importantes:

• El costo es probablemente más alto (dependiendo de la funcionalidad deseada)
• El expertise necesario para desarrollar una herramienta (técnicamente y funcionalmente hablando) no es común, ni barato
• En la mayoría de los casos el ROI será negativo
• La inversión debe ser continua para mantenimiento y evitar obsolescencia
• Distrae la atención de la organización, posiblemente descuidando aspectos más críticos

La amplia variedad de ofertas en el mercado nos asegura que hay una herramienta adecuada para un alto porcentaje de organizaciones interesadas, por lo que es suficiente con que los recursos de la organización se enfoquen en un proceso adecuado de selección.

Definición de requisitos

Definir los requerimientos que un Software de Service Desk debe satisfacer es, en mi opinión, uno de los pasos más importantes del proceso de selección. La cantidad de recursos financieros, humanos y de tiempo que invirtamos en este paso impactarán directamente nuestra decisión final y, consecuentemente, el éxito de nuestro ejercicio de selección.

Mi recomendación es que en primer lugar tracemos una lista de todas las cosas que queremos que la herramienta haga. A estas alturas, no nos debe preocupar qué tan importante es el requerimiento o si existe una herramienta en el mercado que la satisfaga.

Esta lista debe desarrollarse de manera inclusiva con la participación de todos los roles que pudieran hacer uso de la herramienta o tienen un interés en ella. Todos los requerimientos se deben publicar en un documento que llamaremos SoR (Statement of Requirements) y compartirlo con todos los participantes.

Una vez que contemos con esta lista, la debemos organizar de acuerdo a prioridades en un formato conocido como MoSCoW, el cual nos ayudará a definir la importancia de cada funcionalidad de la herramienta para tener claras las necesidades durante todo el proceso.

El análisis MoSCoW consiste en categorizar los requerimientos de funcionalidad en las siguientes secciones:

Must: Los requerimientos de esta categoría deben estar cubiertos no importando qué. Por ejemplo:

• Debe funcionar en la nube
• Debe incluir un portal de auto ayuda para usuarios

Should: En esta sección documentaremos todos los requerimientos que deberían estar cubiertos pero no son indispensables. Por ejemplo:

• Debería ser posible comprar licenciamiento permanente
• Debería incluir una póliza de consultoría para su implementación

Could: En esta categoría incluiremos todas las funcionalidades que podrían estar cubiertas, siempre y cuando no interfieran con nada más. Por ejemplo:

• Que soporte otros procesos además de los deseados actualmente
• Que se integre con Active Directory

Won’t: Aquí enlistaremos todas las funcionalidades que no estarán cubiertas en este ejercicio, pero que tal vez pudieran ser consideradas en el futuro. Por ejemplo:

• Que se integre con otras herramientas
• Que cuente con certificaciones

Estrictamente hablando, nuestro objetivo sería conseguir una herramienta que cumpla con todos los requisitos catalogados como Must. Sin embargo, el empeñarnos en cubrir el 100% de los requerimientos podría ser una receta para el fracaso. Para la mayoría de las situaciones, una herramienta que cumpla con el 80% de los requerimientos catalogados como Must debe ser suficiente. En caso de que no exista ninguna en el mercado, la mejor opción usualmente es la que más funcionalidades en Must tenga.

Conclusión

Con estas breves consideraciones, seguramente podremos tomar una mejor decisión respecto a la selección de herramientas de mejores prácticas. El incluir a todos los interesados y documentar los requerimientos con una metodología mitigará profundamente el riesgo de tomar una decisión equivocada o gastar de más.

¿Requieres de un software adaptable a tu empresa?

Con Openser obtienes el mejor costo-beneficio, configurable para cualquier área de servicio

[mk_fancy_title tag_name=»h2″ style=»false» color=»#dd3333″ size=»24″ font_weight=»inhert» margin_top=»0″ margin_bottom=»30″ font_family=»none» align=»center»] [/mk_fancy_title][mk_button dimension=»three» size=»large» outline_skin=»dark» outline_active_color=»#fff» outline_hover_color=»#333333″ bg_color=»#18af0e» text_color=»light» url=»https://www.openser.com/» target=»_blank» align=»center» fullwidth=»false» margin_top=»0″ margin_bottom=»30″]Descubre Openser
[/mk_button][mk_padding_divider size=»20″][vc_column_text disable_pattern=»true» align=»left» margin_bottom=»10″] [/vc_column_text]