Jira Service Management (JSM) es una herramienta de software que ayuda a las organizaciones a brindar un servicio de soporte efectivo y mantener un flujo de trabajo funcional mientras esté bien implementada, y los equipos sigan las políticas de uso de forma adecuada. El reto llega cuando las organizaciones deciden ampliar la oferta de servicios, y con ello, el soporte, y los SLAs. En esta publicación te contaremos sobre una solución que te ayudará a controlar los tiempos de respuesta de tu equipo de soporte en JSM Data Center, de cara a los distintos tipos de clientes.
En la medida que se expande la oferta de soporte de los distintos servicios, como consecuencia, se crean más centros de ayuda para las distintas unidades de negocio, tanto de forma interna como externa, este reto viene acompañado de un centenar de detalles que hay que cubrir cuidadosamente, para evitar problemas en el cumplimiento de las regulaciones que hayamos establecido de cara a los clientes, sobre todo a los externos.
Por esta misma razón, es importante establecer, administrar y mantener controlados los acuerdos de nivel de servicio (a eso nos referimos al hablar de SLAs), y son necesarios para brindar un servicio de alta calidad a tus empleados, clientes u otras organizaciones. Por eso, vamos a mostearte como puedes obtener lo mejor de este protocolo:
SLA es un acrónimo de la frase en inglés "Service Level Agreement" que traducido es acuerdo a nivel de servicio, y desde el punto de vista de un proveedor de servicios, consiste en un lenguaje sencillo entre el proveedor y el cliente (ya sea interno o externo) que define los servicios que el primero brindará, y determina la capacidad y tiempo de respuesta que se puede esperar y cómo se realizará la medición de este desempeño.
Los SLAs definen los términos acordados sobre los servicios que se proveen, e incluye aspectos como el tiempo de actividad y la capacidad de respuesta del soporte. Por ejemplo, Atlassian promete a sus clientes del plan Cloud Enterprise un tiempo de actividad del servicio del 99,95% y una respuesta del soporte disponible las 24 horas del día, y los 7 días a la semana.
Este tipo de acuerdo formaliza las expectativas del servicio, y establece los términos estándar al momento del incumplimiento de los requisitos.
Ya hemos establecido que los SLA son un acuerdo fundamental entre el equipo de TI, o el de soporte y los clientes internos o externos, y es importante para generar confianza. Gestiona las expectativas de los clientes y permiten que el equipo sepa qué problemas hay que resolver. Una vez implementados los SLAs, existe un entendimiento mutuo de las expectativas del servicio, además beneficia al equipo de TI y soporte fortaleciendo la relación con los clientes, formalizando la comunicación y mejorando la productividad y la moral.
Establecer los SLAs suena simple, sin embargo, en la práctica, los equipos de soporte y de TI a menudo se encuentran con uno o más desafíos importantes, como los que te mencionaremos a continuación:
Como hemos comentado, tanto el establecimiento de los SLAs como la generación de los informes pueden parecer arbitrarios, y para asegurarnos que estamos midiendo las cosas de forma correcta y que estamos cumpliendo con las expectativas del resto de áreas dentro de la empresa respecto al trabajo de soporte y el impacto que esto tiene en el negocio, la recomendación general es la de monitorizar los SLAs con regularidad, y eso puede ser posible siguiendo los siguientes consejos:
Una vez aprobada tu propuesta con los nuevos SLAs, como hemos mencionado antes, ha llegado el momento de establecer políticas que te permitan realizar un mejor seguimiento y control de los SLAs de tu equipo de soporte:
En ciertas organizaciones, especialmente en las más grandes, es posible que ya existan cientos de SLAs en un Jira Service Management (JSM), y cada uno con un grado de complejidad variable, además es común que a pesar de tener una complejidad variable todos están todos regidos por los mismos tiempos de respuesta, para solventar esta situación, es importante tener en cuenta muchos factores:
Por ejemplo, al modificar la configuración de un SLA, las obligaciones contractuales del servicio podrían estar en riesgo de incumplimiento sin nosotros saberlo o estar conscientes de ello: Si el cambio se realiza de forma incorrecta y en segundo plano, el primer SLA podría entrar en conflicto con otro ya existente. Lo que implica que ambos comenzarán a fallar en toda la organización, y eso no es bueno, para el momento en el que identifique el problema y se logre rastrear lo que ha salido mal, el daño, de cara a los clientes ya estará hecho, y esto deteriorará la confianza.
Dependiendo de la gravedad incurrida y el tipo de las infracciones, tu organización podría ser responsable por una falta grave de cara a un cliente externo, sobre todo si se han violado los términos y condiciones en la prestación del servicio, y esto podría llegar a otras instancias. Es un caso distinto si esto ocurre internamente y tus propios empleados no reciben respuestas de manera oportuna.
Debes tener en cuenta que en la medida que tu organización crece, la cartera de servicios crecerá, y como consecuencia, también crecerá el servicio de soporte a esos servicios; en esta situación, los SLAs tienden a proliferar también, y esto significa una complejidad mayor para el administrador del Jira Service Management ya que esto implica que será más difícil identificar qué cambio de configuración de SLA es el que está presentando problemas, en el caso de ser así.
La semana pasada te contamos un poco sobre las auditorías avanzadas, una función disponible para las herramientas en el Data Center de Atlassian, y teniéndolas disponible en tu Jira Service Management representaría una solución enorme ante el dilema del crecimiento empresarial vs el aumento de los SLAs.
Esta es una característica y solución que resulta atractiva para los Administradores de Jira, ya que les permite acceder a un registro de auditoría integral que enumera cada uno de los cambios en la instancia de JSM.
Vamos a poner el caso en el que se sospeche que se ha cambiado un SLA por error, para verificar esta modificación, se puede buscar en el registro que provee la auditoría avanzada, donde se pueden revisar todos los eventos relacionados con el SLA en cuestión, allí podremos ver qué componente del SLA se cambió, quién hizo el cambio y cuándo, eventualmente, con esta información lograremos identificar el origen del problema de forma rápida y solventarlo antes de incurrir en incumplimientos o en degenerar la relación con clientes externos. Esta información también nos evitará deshacer la configuración y con recalcular el o los SLAs afectados será suficiente. Tan sencillo como modificar el SLA en cuestión o eliminarlo y crear uno nuevo navegando a "SLA" desde la configuración de proyecto.
Analizar tus registros de auditoría de forma diaria o semanal requiere mucho tiempo y es insostenible en la medida que tu organización vaya creciendo, y con las auditorías avanzadas en tu Jira Service Management Data Center, puedes ahorrar mucho tiempo, ganar mayor productividad y evitar incumplimientos que probablemente te generará otros inconvenientes, por eso, y de forma más específica, las auditorías avanzadas en tu Jira Service Management Data Center te permitirán:
La ventaja principal de las auditorías avanzadas del Data Center de Atlassian, es que una vez configuradas, puedes tener la tranquilidad de saber que estarás al tanto de forma prácticamente inmediata y podrás resolver el problema rápidamente en lugar de tardar semanas en detectarlo.
Como ves, los SLAs son una parte esencial en la labor de ofrecer servicios de soporte, bien sea a nivel externo, o interno de una organización, y realizar un seguimiento muy cercano de los cambios que se puedan producir en ellos es de suma importancia, ya que, a falta de eso, se puede incurrir en un incumplimiento que degenere en falta de confianza de los clientes, o incluso en faltas legales. Para evitar esta situación, las auditorías avanzadas del Data Center de Atlassian, prácticamente hace este trabajo por ti, al menos el de informarte a tiempo.