Problemática
Nuestra empresa cuenta con un sistema deficiente para la solicitud de hardware y software internamente.
Anteriormente lo que se hacía era mandar un correo electrónico solicitando el producto. El correo necesitaba contener toda la información que se pudiera de dicho articulo solicitado. Muchas veces en esos correos no se proporcionaba la información suficiente o la información era errónea, por tanto no se podía saber con exactitud que era lo que se estaba solicitando. Esto generaba trafico de ida y vuelta entre los usuarios y el departamento en cuestión.
En ocasiones, se asignaba esta solicitud a un equipo que no era el encargado de proporcional dicho articulo.
Una vez que el encargado recibía la solicitud, se procesaba, ya sea mandándolo directamente al usuario (hardware), o ver si se necesitaba tener acceso a su computadora para instalarlo (software).
Esto realmente causaba mucha confusión y retraso, el hecho de que no se especificara que era exactamente lo que se quería y quien iba a ser el encargado de trabajar con esa solicitud.
OK, tenemos que mejorar, ¿Qué tenemos que mejorar?
El objetivo del proyecto es que, mediante la herramienta de ServiceNow se pueda crear una forma a la cual tengan acceso todos los usuarios determinados para poder ingresar una solicitud.
Dicha forma solicitaría exactamente la información necesaria para determinar que es lo que realmente se necesita y por medio de la selección, pueda redirigirse de manera automática al equipo asignado.
La creación de una forma lo suficientemente inteligente para determinar (dependiendo de la información proporcionada o las selecciones hechas) a que grupo de soporte se tiene que enviar la solicitud, asegurarnos que este grupo tenga toda la información que se necesite, esto evitaría regresar con el usuario y solicitar información faltante.
Desarrollo
Lo primero que necesitábamos saber era quienes eran los usuarios que tendrían acceso a dicha herramienta (ServiceNow) ya que no todos podían levantar una solicitud. Esto para ir delimitando desde el inicio el posible grupo de soporte que nos ayudaría para resolver este problema. Es decir, sabemos que un usuario de cierta locación solo podría tener soporte por los grupos locales de la zona, esto no descarta automáticamente a los demás grupos de soporte.
En un principio se propuso la idea de crear una catalogo en el menú principal donde podría ver el usuario todos los productos que podría adquirir. Dichos artículos serian organizados dependiendo de la categoría a la cual pertenecían (telefonía, accesorios, equipo de cómputo, diferentes tipos de software, etc.), pero el hecho de tener un catálogo de artículos de forma individual solo haría la búsqueda lenta y muy complicada, esto teniendo en cuenta que tenemos un alto numero de elementos que se puedan solicitar.
En base en nuestra experiencia decidimos sugerir que se creara una forma única, dinámica, donde dependiendo de las respuestas o selecciones del usuario, se mostraban campos adicionales para proveer de información necesaria. Esta manera de manejar las formas con opciones nos ayuda a llevar de la mano al usuario para saber lo que necesita realmente y no darle un menú de cosas que tal vez no necesite.
Dentro de la forma habría campos en los que el solicitante proporcionara información especifica del producto a solicitar, los cuales el solicitante tendría que llenarlos de manera obligatoria (la forma no puede ser enviada si no tenemos esta información). A su vez, se integrarían imágenes de cada uno de los productos para que no hubiera confusión alguna de cual era el que había sido solicitado.
Seguido de esto, se definió cual era el equipo encargado de resolver las solicitudes. Tuvimos que ponernos en contacto con el encargado del proyecto para que pudiéramos definir quienes eran los grupos de soporte dependiente la locación, el articulo e inclusive el tipo de usuario que estaba solicitando (empleado, proveedor, cliente).
También, se tuvo que tocar el tema de las aprobaciones. En algunos casos, ciertos productos no podían ser otorgados de manera directa. Tendrían que pasar por una serie de aprobaciones. Se tuvieron que definir cuales serian los productos que necesitarían aprobación y quienes serían los aprobadores. En algunas ocasiones se podría tener más de un aprobador.
Este fue uno de los puntos clave para la correcta implantación de la solución ya que la herramienta da la libertad de poner el numero de aprobadores que fueran necesarios, más sin embargo lo que se requiere en estos casos es una guía para estandarizar las aprobaciones de una manera más adecuada; no queríamos caer en el vicio de agregar aprobadores a todos los casos, esto solo ocasionaría el desgaste por parte de los usuarios, si no solicitar aprobaciones a los elementos que realmente tengan un impacto monetario a la organización, gastos que no estuvieran planeados, o que estuvieran fuera de presupuesto, por lo tanto se llegó a un esquema donde dependiendo la selección del producto y sus características se podría solicitar un aprobador dinámico que seleccionara el nivel especifico de aprobación, ya sea un supervisor, gerente o director.
Por último, se hicieron notificaciones personalizadas. Se tuvieron que crear 3 tipos de notificaciones:
- Notificaciones de usuario, para reportar cual era el estatus de la solicitud.
- En dado caso de que fuera necesario, se tiene que mandar una solicitud al aprobador designado.
- Notificación para el grupo, al cual se le asignara la tarea de resolver la solicitud del usuario.
- Agregamos notificaciones a la aplicación móvil para que el usuario que tuviera la aplicación instalada en su móvil pudiera tener una notificación en la misma (push notification).
Para cada uno de los grupos que atenderían las solicitudes. Había grupos que estaban asignados a 2 categorías diferentes, para lo cual necesitaban notificaciones personalizadas para poder distinguir que tipo de producto era el que se solicitaba. También, dichas notificaciones serian enviadas al usuario para reportar cual es el estatus de su solicitud.
¿Qué salió mal durante el desarrollo?
Como cada proyecto, siempre lo más complicado es tomar los requerimientos, definir los grupos de soporte, saber que artículos se pueden ofrecer, que información necesita cada grupo para poder dar el servicio y sobre todo establecer los tiempos de entrega de cada uno de ellos.
Aquí se lleva una labor de instrucción para que los involucrados en el proyecto tuvieran la noción de saber qué es lo que se necesita y que se va a obtener.
Debido a que la empresa tiene presencia en diferentes partes del mundo, las formas deberían de estar en diferentes idiomas, dependiendo de la región donde se encuentre el usuario o podría ser cambiado de manera manual. Los idiomas ofrecidos eran el español, ingles y portugués. Contábamos con personal que nos ayudaría a hacer las traducciones de todos y cada uno de los artículos, así como su descripción. Esto nos llevo tiempo ya que teníamos que coordinar a cada uno de los traductores para que se estuvieran haciendo simultáneamente.
El veredicto
La empresa comenzó a ahorrar en tiempo y en efectivo; los tiempos de respuesta para las requisiciones de este tipo eran los mismos siempre, esto ayudo a los gerentes y supervisores a administrar mejor el tiempo efectivo de sus colaboradores, ya que no tenia que esperar sin saber cuando se obtendría el producto, ahora podían programar sus tiempos de entrega para sus proyectos.
Otro de los factores de éxito es el ahorro en licencias de software ya que por medio de la herramienta se pudo llevar el control de las licencias que se dan y se retiran, muchas de las licencias que se retiraban (por la salida de algún empleado, por ejemplo) tenía validez, y nunca se realizaban, simplemente se compraban licencias nuevas para los empleados nuevos, este gasto innecesario se corrigió con el manejo de licencias de software.
Para saber más sobre este caso de éxito no dudes en contactarnos y con gusto resolveremos tus dudas o comentarios.
