Transcripción del webinario

• Introducción:

  Joseph: el presentador de este webinario es Neil Thomas, director general y vicepresidente de servicios profesionales de Service Sphere. Cuenta con una amplia experiencia en el sector de TI, soporte de TI y consultoría de ITIL. Se especializó en el catálogo de servicios y la CMDB. Neil, adelante.

  Neil: brillante, gracias Joseph. Bienvenidos todos y qué bueno tenerlos de vuelta en esta serie de webinarios; el tercero consecutivo que hemos estado haciendo. Y eso es todo sobre mí.

  Diapositiva 3: lo que hacemos... muy poco de lo que hacemos... pero mi empresa cambió de nombre hace poco a SERVICE SYMMETRY. Somos una rama de lo que era Service Sphere. Así que hacemos un montón de cosas en torno a ITIL, formación en ITIL, consultoría de formación en el instituto de mesa de servicio, enseñamos todas esas cosas buenas que tienen ahí. Así que si están interesados, pónganse en contacto conmigo. Pero lo más importante es el hecho de que todo ese buen material me ha permitido tener muchos años de experiencia dentro de la industria, especialmente en términos de ITIL como consultor, pero también como gestor de productos trabajando para un proveedor en términos de crear y desarrollar conjuntos de productos para la gestión de servicios de TI por completo, desde el incidente hasta el catálogo de servicios. Así que tengo un conocimiento amplio de cómo funcionan estas cosas, desde dentro y cómo las personas del mundo real las asumen y utilizan realmente.

  La serie de webinarios - 1:27

  Diapositiva 4: así que, sin más preámbulos, este es el tercero de la serie de ManageEngine. Realmente nos lleva directamente a través del catálogo de servicios. Hablamos sobre cómo los servicios afectan a los negocios y son utilizados por los negocios, lo que les ofrece cosas como la base de datos de gestión de la configuración, elementos de configuración, y similares. Y a continuación, por supuesto, las cosas con las que todos estamos familiarizados como incidentes, problemas y cambios. Y, a continuación, el último de la serie dentro de unas semanas será sobre cómo medir el rendimiento de la mesa de servicio.

  Así que hoy hablamos de incidentes y es muy interesante ver a muchos de ustedes hoy. Y la pregunta de "¿por qué la gente está tan interesada en los incidentes?" ha existido durante muchos años y estamos viendo que se está regresando a algunos de los fundamentos. Es muy interesante que hagamos esto porque, en mi rol de consultor, me encuentro con tantas organizaciones que lo que hacen con la gestión de incidentes es simplemente marcar la casilla y desafortunadamente lo hacen mal. A menudo se olvidan de los principios fundamentales de la gestión de incidentes. Así que ManageEngine, ya que es buena gente, pensó que sería un buen momento para volver a revisar algunas de esas cosas. Así que para los que están por ahí, tiene como fin poner al día a quienes acaban de entrar en el juego y quieren saber un poco más al respecto. Entonces, esto cubre algunos de los aspectos básicos que tenemos en torno a la gestión de incidentes.

• Temas de actualidad - 2:48

  Diapositiva 5: así que vamos a ver dónde encaja dentro de todo el marco de ITIL. No basta con hacer incidentes, porque hay muchas otras cosas que no necesariamente hay que hacer, pero desde luego hay que entender y considerar y poner la cosa en su contexto viendo un poco cómo encaja en la mesa de servicio, cómo se comparan los incidentes con las solicitudes de servicio. Otro flujo de trabajo de incidentes que examina un poco los conocimientos y cómo encajan, así como todo el asunto de los acuerdos de nivel de servicio y la vieja relación entre incidente y problema e incidente y cambio. Todo forma parte del mismo marco ITIL.

  Diapositiva 6: así que, sin más preámbulos, pasamos a una diapositiva que ya han visto varias veces, estos son los servicios que la empresa pone a disposición, que TI soporta y entrega. Son cosas que pueden encontrar en el catálogo de servicios, pero sin duda son cosas que hace la empresa, desde las ventas al marketing, pasando por el soporte en campo o la verificación de crédito en finanzas. En fin, todas las piezas, todas las funciones que una organización necesita para sobrevivir, por supuesto con el apoyo de TI y los servicios de TI. Por supuesto, esos servicios de TI a veces no funcionan como deberían, que es donde se produce todo el incidente.

  Diapositiva 7: así que echemos un vistazo a esto en contexto. Entonces, esos son servicios justo en el medio... e ITIL está ahí y la gestión de servicios de TI está ahí para dar soporte a esos servicios. Y esa es la cosa clave: la gestión de incidentes. No solo existe para hacernos sentir bien y para que vayamos a trabajar un lunes, aunque proporciona a mucha gente muchos puestos de trabajo. No, la gestión de incidentes consiste en asegurarse de que los servicios que se prestan a una organización siguen prestándose porque sin ellos la empresa no está siendo tan eficiente como debería y es probable que tenga problemas.

  Así que el usuario necesita que se le preste un servicio mediante una solicitud de servicio o el catálogo de servicios. Y si algo va mal con ese servicio, ese es el clásico trabajo de la gestión de incidentes. Es fundamental que, si algo se daña, tenemos que arreglarlo, tenemos que lograr que ese servicio vuelva a funcionar. Porque cada minuto que ese servicio está caído le está costando dinero a la empresa, tiempo, ineficacia, los competidores se están interponiendo en el camino, etc. Así que es una pieza muy vital de todo el rompecabezas, obviamente algo relacionado es la rapidez con la que esas personas... esos servicios son soportados. Sí que aquí entra toda la idea de la gestión del nivel de servicio, que hoy tocamos brevemente.

  Ahora bien, si algo sale mal de nuevo, el vínculo entre incidente y problema entra aquí. Algo sigue yendo mal entonces, obviamente, pasamos a todo el principio de gestión de problemas, y estos son los procesos, las mejores prácticas que ha sacado ITIL como parte de su marco de trabajo de la versión 3.

  Ahora bien, si sigue yendo mal, descubrimos cuál es el problema y queremos solucionarlo. Entonces, obviamente, empezamos a buscar la gestión de cambios, cambiando las cosas de una manera muy rigurosa y con un proceso definido. Para que no haya riesgo en la organización, se gestiona el riesgo fuera de ella. La cuestión es que la forma en la que proporcionamos esos cambios a la empresa tiene que ver con la gestión de liberaciones, la gestión de la configuración, cómo nos aseguramos de que todos esos servicios están ahí en el futuro, todas esas otras piezas esotéricas que obtenemos de ITIL desde la disponibilidad, la capacidad, la gestión de la continuidad del servicio y, por supuesto, por último [perdón] llegamos a la gestión de esos servicios con la cartera de servicios y la gestión financiera. Pero aquí ven que la prestación del servicio —las cosas del negocio, las cosas que hacen que el negocio funcione— es absolutamente vital, una piedra angular de ello. Por eso todo el mundo usa la gestión de incidentes, por supuesto, por el hecho de que si algo sale mal tenemos que lograr que vuelva a funcionar rápidamente.

• Gestión de incidentes - 6:40

  Diapositiva 8: así pues, pasamos a la gestión de incidentes. Así que realmente esta diapositiva recapitula justo eso de lo que he estado hablando. Todo está ahí para restablecer el servicio normal lo antes posible. Creo que ciertamente la gente de la mesa de servicio... cualquiera de ustedes que estén ahí fuera y ciertamente desde mi propio punto de vista habiendo hecho esto en mi historia... Lo clave que los usuarios quieren y por lo que se frustran es seguir con su trabajo. Ellos saben que cada minuto que no están trabajando allí es una desventaja para el negocio, que podría haber ineficiencias y, a veces, por supuesto, grandes interrupciones, con grandes problemas. Tenemos que retomar estas cosas rápidamente. Así que contar con un buen proceso de gestión de incidentes y ser capaz de gestionarlos adecuadamente es absolutamente vital. Así que supongo que una definición —al viejo estilo de ITIL— sería cualquier evento que interrumpa o pueda interrumpir uno de esos servicios de los que hemos estado hablando.

• Elementos clave - 7:34

  Diapositiva 9: así que las cosas clave... algunos hechos clave supongo sobre los incidentes... realmente un incidente podría aplicarse a casi cualquier cosa. No tiene por qué ser TI. Aquellos de ustedes que tienen mesas de servicio combinadas saben que podría ser sobre instalaciones, podría ser sobre RRHH, podría ser sobre servicios o equipos de TI. Puede abarcar toda una gama de cosas diferentes, donde el alcance y el tamaño depende realmente de ustedes. Y, por supuesto, hoy en día se pueden reportar casi por cualquier medio posible, no sólo con la gente como en mis días, donde ibas corriendo y decías "Mira tengo un problema ¿cómo puedo hacer esto?" O "Mi equipo está dañado", sino que se reportan por correo electrónico, por teléfono, por autoservicio. Ahora entramos en todo el aspecto de los medios sociales con cosas como Twitter y Facebook, algo en lo que he estado trabajando muy recientemente.

  Otra área donde las cosas han ido mal, si se quiere, es en la infraestructura. Y hay toda una pieza que ahora ha sido tallada en la versión 3 de ITIL llamada gestión de eventos, donde los eventos que están siendo detectados por un conjunto de herramientas de gestión de red automáticamente generan un incidente y casualmente también pueden cerrar automáticamente los incidentes. Pero al menos tienen visibilidad de lo que ha ocurrido. No voy a hablar mucho de eso hoy, excepto que se pueden plantear de una manera particular y, obviamente, estos son normalmente todos estos informes de incidentes registrados en la mesa de servicio para garantizar que hay alguien que está gestionando todo el proceso y averiguar lo que está pasando y todo eso produce datos. Los datos son absolutamente vitales en ITIL para poder seguir adelante y mejorar y resolver los servicios, asegurándose de que pueden mejorar las cosas.

• 9:16

  Diapositiva 10: así que ahí tenemos los elementos clave entrando un poco más en detalle detectándolos, registrándolos, clasificándolos, investigándolos, diagnosticándolos y luego resolviéndolos y luego recuperándolos y luego cerrándolos. Y en ese cierre —este tipo de proceso que ha planteado TI—, el punto aquí es que la información correcta se mantenga y se registre todo el camino y que se siga el proceso.

  Gestión de incidentes con las mejores prácticas de ITSM:

  ITIL se basa en las mejores prácticas y, en el caso de la gestión de incidentes, hay que atenerse al proceso o procesos, como veremos más adelante. Y es muy importante asegurarse de que todas las piezas diferentes se adhieren, de lo contrario las cosas empiezan a ir mal. Ciertamente, con la gestión de incidentes he visto muchos grupos en los que tienen un proceso, conjuntos de herramientas fantásticas, pero el problema es que acaban poniendo datos basura. Y, por supuesto, cuando ponen datos basura en el backend, obtienen datos basura. Entra basura, sale basura. Es necesario poder asegurarse de las personas que introducen los datos en primer lugar, que el diagnóstico es exacto, que está comprobado y que las resoluciones —una vez que llegan y responden a esos incidentes— también son correctas. Obviamente, una parte de esto, de todo el aspecto es la propiedad; poseer un incidente en particular o un grupo dentro de la mesa de servicio que posee un incidente, supervisándolo, trabajando para aprovecharlo, rastreándolo a través de los diversos grupos y comunicándolo a los diversos grupos dentro de la mesa de servicio. Y, por supuesto, el buen usuario final, que es la persona que está sentada esperando a que se restablezca el servicio. La gestión de incidentes, ITIL y la mesa de servicio no existen en beneficio propio, existen en beneficio de su organización para garantizar que los servicios se restablezcan lo antes posible.

  Proceso/flujo de trabajo de gestión de incidentes - 11:03

  Diapositiva 11: así que hay un proceso de gestión de incidentes que muestra las diferentes entradas desde la parte superior. Merece la pena repasar algunas de estas cosas aquí, sea cual sea la forma en que aparezca. Identificamos el incidente, empezamos a categorizarlo e ITIL —y, de hecho, todo el principio de la mesa de servicio—, se trata de intentar gestionar las cosas a través de la clasificación. Miramos los tipos, miramos los distintos tipos preexistentes que tenemos, para poder empezar a averiguar si se trata de hardware, software, una pieza concreta de software, una persona en particular o una hora del día o un grupo. Así que queremos empezar a entender los datos. Y, una vez que los tengamos, podemos examinarlos y utilizar el análisis de tendencias para asegurarnos de entender lo que está pasando.

  Así que usamos los datos, los categorizamos (entraremos en algunos de estos aspectos en un minuto): "¿Es una solicitud de servicio?" Si no lo es (siendo la solicitud de servicio algo que alguien quiere y no digamos lo que viene en un minuto), entonces empezamos a decir "Bien ¿cuál es la prioridad?". Por supuesto, damos prioridad según el servicio que se esté viendo afectado; "¿Se trata de un incidente mayor? (algo de lo que hablaremos dentro de un minuto); ¿O se trata de algo común y corriente?". Si es un incidente mayor, se trata de forma diferente, se hace un diagnóstico inicial y se le echa un vistazo. Ahora, "¿Es necesario escalar ese incidente? ¿Tenemos todos los datos? ¿Tenemos la capacidad y las herramientas para poder resolverlo aquí y ahora?". Si es así, nos ponemos manos a la obra. Si no, entonces se pasa a otros grupos para un escalamiento jerárquico o entre iguales. Y, por supuesto, a medida que llegamos al final del proceso, nos ocupamos de resolverlo asegurándonos de que tenemos la resolución correcta para el incidente. Luego nos ocupamos de la recuperación y de lo que hay que hacer para volver a un nivel de servicio completo. Puede ser algo más que contarle al tipo que está al otro lado cómo se ha corregido, sino también lo que tiene que hacer para volver a ponerse al día, para recuperar los datos, sea lo que sea.

  Y por último —por supuesto— hay un cierre del incidente. Realmente, deberíamos buscar en el cierre del incidente asegurarnos de que el usuario está contento con lo que ha pasado. Con mucha frecuencia veo incidentes que son cerrados por diferentes equipos. Y lo que ocurre es que lo cierran sin siquiera consultar al usuario. Hay que averiguar si el usuario está realmente contento con lo que ha pasado. Así que parte de un buen cierre es la satisfacción del cliente o bien contactar a la persona asegurándose de que se ha resuelto a su satisfacción.

• Registro del incidente - 13:40

  Diapositiva 12: así que vamos a entrar un poco más en detalle. Lo registramos, miramos estas cosas que normalmente se registran en la mesa de servicio, registramos todos los incidentes... aunque hablaremos de ello dentro de unos minutos, sobre si registramos absolutamente todos. Ahora echemos un vistazo a si cumple con el acuerdo de nivel de servicio para un servicio en particular. Así que cuando empezamos a examinar el servicio que se está viendo afectado, nos fijamos en el nivel de servicio que ya se ha acordado para asegurarnos de que vamos a tratarlo de la manera correcta. Registramos todos los datos relevantes... y esa pequeña frase de ahí que dije hace un par de minutos, es una frase muy corta, pero encierra toda una serie de problemas para mucha gente; mucha gente en las mesas de servicio no registra adecuadamente. Y lo que ocurre es que —como dije— "Si se mete basura, se saca basura". Es muy difícil volver atrás y aprender de los errores, utilizar esos incidentes para recuperarse y restaurarse de otras cosas que ocurran de naturaleza similar en el futuro.

  Así que es muy importante que la base de registro se haga correctamente. Obviamente, también existe la posibilidad de que otras personas que no estén en la mesa de servicio puedan reportar rápidamente los incidentes. Me gustaría animar a aquellos de ustedes, que aún no se han puesto en algún tipo de autoservicio sea cual sea —por correo electrónico o Internet o incluso por Facebook y Twitter—, a que realmente lo consideren como un mecanismo para obtener datos en el sistema para el registro de llamadas. Sin embargo, al hablar de los datos, significa que tenemos que considerar bastante bien lo que ha ocurrido con los datos y tal vez tengamos que analizarlos para asegurarnos de que comprendemos cuál es el verdadero problema, el verdadero incidente y ponerlo al día. Para que se ingrese en la base de datos con datos suficientes.

  Categorización del incidente - 15:30

  Diapositiva 13: luego lo categorizamos. Ahora que he mencionado de nuevo esta categorización, hay dos aspectos. Realmente estamos tratando de determinar el tipo de incidente —ya saben— por ejemplo, que el servicio de TI se ha degradado, y la cosa que se ha visto afectada. Hablamos la última vez sobre las cosas que prestan el servicio y esas cosas son activos, o como los llamamos en ITIL, elementos de configuración. Nos fijamos en los que han sido afectados. Y cuando tomamos nota del incidente, debemos entender realmente el tipo de servicio que se está viendo afectado y, de hecho, el elemento de configuración que también se ha visto afectado por el incidente. Porque ambas cosas dictarán la rapidez con la que debemos responder a él. Obviamente, debemos utilizar algún tipo de criterio de codificación estandarizado. Normalmente, estas cosas las manejan muy bien los conjuntos de herramientas, como los que tiene ManageEngine. Para que lo hagan por ustedes y sólo tengan que elegir de una lista predeterminada. Cualquiera de los conjuntos de herramientas es perfecto. ITIL clama y ha estado clamando durante mucho tiempo por buenos conjuntos de herramientas para poder ayudar a la gente a hacer estas cosas de forma más efectiva y, por supuesto, eso es lo que tenemos aquí.

  Priorización del incidente (gravedad) - 16:35

  Diapositiva 14: luego lo priorizamos. Y por supuesto, todo esto de la categorización... sobre todo, la priorización tiene que ver con el servicio. No nos limitamos a mirar un incidente y decir "Bueno, eso parece... creo que es bastante grave ¿quién está disponible? Encontraré a alguien muy agradable que lo haga". No, lo hacemos en base a una rutina establecida, un número determinado de cosas como cuán importante es ese servicio para la organización. Realmente no se puede entrar mucho en los acuerdos de nivel de servicio en este webinario, pero realmente en sí mismo es como asegurarse de los acuerdos entre TI y el negocio. Para que TI entienda lo que es importante. Así que si la empresa te dice: "El departamento financiero a final de mes es absolutamente vital, tienes que mantenerlo en marcha y son tu prioridad a final de mes", entonces ciertamente tienes que asegurarte de que las personas de finanzas son las personas más importantes y les das prioridad.

  Así que aquí tenemos una lista de ejemplo de priorización y gravedad, dicho eso. En el nivel 4, no hay impacto en el negocio ni hay pérdida de servicio. En el nivel 3, hay una pérdida menor de servicio hasta una pérdida total de servicio. Ahora bien, algunas de estas cosas son muy estándar que se obtienen de los libros de ITSM o las pueden inventar ustedes mismos y algunas de las herramientas las tienen predefinidas en ellas. Pero vale la pena simplificar estas cosas. Yo no ingresaría un montón de prioridades y gravedades. Había una organización el otro día que tenía 18 niveles diferentes de gravedad. Cuando se trata de utilizarlo en la práctica, es muy difícil de trabajar con ello. [Dije ¿17 o 16? Hmm no sé ¿brilla el sol?]. Se vuelve muy, muy esotérico en ese punto. No, los niveles de prioridad y gravedad son muy claros como los que tienen aquí —quizás de 1 a 4 o de 1 a 5—. Y luego por supuesto una vez que han hecho eso...

  Escalamiento del incidente - 18:27

  Diapositiva 15: entonces se trata de escalarlo. Y los conjuntos de herramientas les ayudan a escalar de forma muy efectiva. Porque lo que tenemos que hacer es gestionar qué ocurre con esos incidentes. Si la primera persona que se hace cargo dentro de un proceso de incidentes no puede resolverlo, no tiene el conjunto de herramientas o la experiencia, entonces obviamente tienen que escalarlo lo más rápidamente posible para asignar los recursos adecuados si es necesario. Ya sea horizontalmente, es decir, alguien dentro del mismo grupo —es decir, la misma función de gestión de incidentes— o verticalmente en otros grupos, específicamente en una segunda línea, tercera línea como quieran verlo.

  Obviamente, debe haber reglas en torno a cómo esas cosas se escalan. Una de las cosas que debemos tener aquí es el recuento de rebotes con los que tenemos que trabajar y asegurarnos de que ese espacio sea muy bajo. El recuento de rebotes —para quienes no han escuchado este término entretenido— es todo lo que tiene que ver con el número de veces que el incidente rebota sin volver, si se quiere, entre los diferentes grupos. Es como se dice una "papa caliente". Por lo que alguien dice "¡Oh! No quiero esto, es demasiado complejo" y se lo pasa a otro grupo, que piensa exactamente lo mismo y se lo pasa a otro grupo más. Los incidentes pueden ir rebotando por el sistema como una pelota por la pista de squash muchas veces si no se tiene cuidado de cuántas veces ha pasado realmente de un grupo a otro. Y esa es la función de la mesa de servicio, o de quienquiera que sea el propietario de ese incidente en particular. Y yo diría que la propiedad es una pieza vital de cualquier proceso de gestión de incidentes, de gestión de servicios. Y en la derecha en la parte inferior de nuevo... Datos precisos... [debería haberlo puesto en cada diapositiva en realidad]. Cada vez que se toca algo con un proceso de incidentes... datos precisos durante todo el trayecto

  Resolución del incidente/recuperación y restauración - 20:18

  Diapositiva 16: y luego, por supuesto, llegamos al final del proceso, donde tenemos que resolver, recuperar y restaurar. Así que cuando llegamos a resolverlo [verán esto en un minuto], buscamos errores conocidos [que explicaré en un segundo] o soluciones alternativas existentes. Resolvemos el incidente con soluciones o soluciones alternativas. Y a veces, la solución significa que hay que enviar una solicitud de cambio, una RFC. De modo que el incidente no es sólo un fin en sí mismo, sino que [como veremos en un segundo también] se resuelve a través del proceso del problema y, de hecho, también a través del proceso de cambio. No olvidemos... [y creo que éste debería ser el mantra, que esta pieza en rojo debería estar pegada en la pantalla de todo el mundo, o quizá podamos hablar con ManageEngine para que parpadee en los desktops de la gente cada tres segundos]... Pero el objetivo de la gestión de incidentes es restablecer el servicio, de eso se trata. Sería lo mejor para toda la organización si nunca fallara nada. Pero ese escenario nirvana no sucede. Las cosas suceden, las personas suceden, los equipos fallan, las personas no se presentan a trabajar porque están enfermas. Así que las cosas simplemente no funcionan. Un buen proceso de gestión de incidentes restablece el funcionamiento normal de la empresa lo antes posible. Ese es nuestro mantra, que casi deberíamos estar diciendo cada dos segundos mientras caminamos intentando solucionar incidentes. Pero ese es el objetivo y en eso consiste realmente la gestión de incidentes, ese proceso que acabo de explicar.

  Funciones clave de la gestión de incidentes - 21:42

  Diapositiva 17: por lo tanto, algunas cosas clave que acabo de lanzar aquí y que son muy importantes [no encajan particularmente bien en ningún sitio, así que las pongo justo en medio de la presentación]... asumir la responsabilidad de un incidente ya sea como individuo o como grupo y los conjuntos de herramientas que les permiten hacerlo aún mejor. Tengo una carga de trabajo como la lista de cosas que estoy haciendo. La persona responsable puede decir... "¿Quién tiene esto?" "¡ah!, George por ahí tiene este incidente en particular". Él va a ejecutarlo, hay un punto de contacto para el usuario, hay alguien que tiene la responsabilidad de hacer que estas cosas funcionen. Si él no puede, tiene la responsabilidad de pasárselo a alguien que sí pueda. Y dependiendo de cómo esté trabajando, se queda con el incidente y lo gestiona durante el camino y se asegura de que otras personas hagan el trabajo, o lo pasa y se asegura de que la siguiente persona tome la propiedad —la batuta si se quiere— de su carrera de relevos.

  Queremos mantenernos centrados en el incidente, sin puntos ciegos —perdónenme si utilizo el término equivocado, para los que están aquí en Estados Unidos, pero sin puntos ciegos—, y queremos asegurarnos de que el incidente es lo fundamental. No querrán desanimarse por otras cosas que surjan y que encuentren dentro del incidente. Un incidente puede dar lugar a otros incidentes de distinto tipo, eso está bien. Pero lo que tenemos que hacer es mantenernos muy centrados en el asunto que tenemos entre manos y no dejarnos desviar por otras cosas que se avecinan. Escalar a las personas en el momento adecuado de una manera adecuadamente rápida, y también escalar rápidamente a la gerencia si hay un problema en términos de hacer las cosas o conseguir que se hagan.

  A menudo ocurre que en la mesa de servicio las cosas se quedan ahí porque a la gente no le gusta tocarlas. Es casi como una cuenta de rebotes negativos. Una cuenta de rebotes negativos donde una papa muy caliente pasa un incidente por diferentes personas. Este tipo de incidente se queda ahí, nadie quiere tocarlo y nunca pasa nada. Para eso están los gestores y por eso está la mesa de servicio, una buena gestión de la mesa de servicio ayuda a la gente a entender y asumir el problema.

  Supongo que el siguiente punto debería ir en letras rojas: "mantener informado al cliente". De nuevo, el cliente es el punto clave aquí y creo que en realidad hoy en día todos entendemos que el cliente es el usuario que está al otro lado del teléfono con nosotros. Porque a menudo somos el cliente al otro lado del teléfono con otras personas en nuestra vida cotidiana cuando utilizamos equipos de TI, estamos en el banco, en casa o lo que sea que estemos haciendo en Internet. Nos gusta que nos den servicio muy rápidamente, nos gusta que nos atiendan y nos cuiden muy eficazmente y muy bien. Así que ahora entendemos estas cosas. Y estar informados sobre lo que está pasando es una parte realmente importante para garantizar que el negocio sigue adelante. Porque si el cliente sabe que no va a recibir una entrega rápida por lo que sea, o la resolución, entonces tal vez pueda hacer algo para ayudarse a sí mismo haciendo algo más. Mantenerlos informados, mantenerlos felices.

  Actuar como interfaz entre los diferentes grupos... De nuevo, si usted es el propietario, pero otras personas que hacen cosas en él... Y, luego, controlar el tiempo y las actividades, todo es muy bueno para solucionar un solo problema, pero si su lista de carga de trabajo tiene 20, sólo mantenga un ojo en esas otras cosas. Es muy importante asegurarse de que las llamadas prioritarias que están llegando son atendidas. Puede que estén haciendo algo para alguien que es importante, pero si ustedes son Amazon y el sitio web principal se cae —la parte de pedidos—, entonces realmente tienen que solucionarlo tan pronto como sea posible, todo tiene que ver con esos servicios.

  Proceso de gestión de incidentes de TI - 25:32

  Diapositiva 18: y volviendo a una visión diferente en el proceso de gestión... obviamente, como sabemos por ITIL, aunque hay un par de procesos establecidos dentro del marco ITIL, hay muchas interpretaciones y muchas implementaciones. Eso es lo bueno de ITIL. Es flexible, son las mejores prácticas y les da ideas de cómo hacer las cosas. Así que miren a su proceso de incidentes y vean cómo se puede adaptar a su negocio, a su organización y vean si los ajustes pueden funcionar. Este en particular es bastante interesante, porque tenemos al cliente que contacta a la mesa de servicio, la creación de un ticket de problema que debe identificarse... "¿Es un incidente? No, puede tratarse de una solicitud de servicio" [sobre lo que hablaremos en un minuto]. Si lo es, pasamos a esta cosa llamada errores conocidos e interrupciones. Y si lo es, ¿hay alguna solución alternativa que podamos aplicar? Si no, entonces pasa a escalamiento. Así que lo que vamos a hacer ahora es adentrarnos en toda el área de cómo los incidentes se interrelacionan con cosas como los problemas y ese tipo de cosas también.

  Acuerdos de nivel de servicio (SLA) - 26:32

  Diapositiva 19: sin embargo, en primer lugar, iniciando con los acuerdos de nivel de servicio, estas son las cosas dentro de un incidente que son tan importantes de tener en cuenta, porque estas son las cosas que nos permiten identificar en qué cosa trabajar primero. Ahora, no olviden que los acuerdos de nivel de servicio son aquellas cosas que deberían —aunque no siempre—, deberían negociarse y acordarse con la organización para un determinado nivel de respuesta. No siempre ocurre que los SLA sean impuestos por TI al resto de la organización. Lo que a veces tiene que ocurrir... porque así es como funciona y las organizaciones no siempre ayudan necesariamente... pero estas cosas deberían acordarse con la organización.

  Para que sepan que cuando ocurra algo van a recibir una respuesta en un plazo determinado. De nuevo, estamos estableciendo expectativas, estamos ayudando a la gente, estamos intentando ser buenos miembros de la organización. Así pueden trabajar dentro del marco, si algo tarda cuatro horas u ocho horas o dos semanas en corregirse, eso es lo que tarda. Pero tenemos que decírselo a las empresas y conseguir su acuerdo al respecto. Por lo tanto, podemos empezar a buscar formas de solucionarlo para garantizar que la empresa siga funcionando. Trabajamos con el negocio en términos de los SLA. Diferentes SLA para diferentes cosas, diferentes prioridades y diferentes elementos de configuración. Así que un servidor probablemente tenga una prioridad mucho mayor que el PC de escritorio de alguien. A menos que quizás ese PC de escritorio tenga algo que ver con el sistema de nóminas a final de mes.

  Un usuario en particular —ya saben— el MD, el director general, el director ejecutivo siempre es una persona importante para hacerlo bien, pero ¿son realmente más importantes que el comercial a final de mes? Está intentando conseguir algunos contratos y no puede enviar un correo electrónico concreto —por la razón que sea—, el archivo adjunto no funciona... A veces, esas personas —a final de mes cuando están intentando conseguir contratos— son más importantes que incluso el director general. Sin embargo, puede parecer al contrario. Es muy importante tener muy claro qué es importante, quién es importante y cuándo es importante, y tiene que ser apropiado para la organización. Obviamente, las distintas organizaciones varían considerablemente de una a otra. Pero de nuevo, se resume a lo que son los servicios, y el objetivo aquí es restablecer esas cosas lo antes posible, dada la importancia del servicio. Luego seguiré hablando de esto, pero en realidad es tan vital que nos metamos en la cabeza y nos aseguremos de ello, de que cuando establecemos la herramienta muchas de estas cosas tienen ajustes predeterminados. Simplemente échenles un vistazo, revísenlas, vean si se ajustan a su organización, no las tomen necesariamente como una biblia. Bueno, esto nos lleva al tema de cómo los incidentes se vinculan a los problemas y a otras cosas, no existen por sí solos.

  Incidente mayor - 29:37

  Diapositiva 20: y aquí tenemos la idea de un incidente mayor, pero ¿cuál es la diferencia entre un incidente mayor y un incidente normal? Bueno, es muy difícil de evaluar, creo que esto dependerá de la organización y, a su vez, en algunos sentidos va a ser una cuestión de mirar el servicio, mirar la cosa que está afectada y llegar a una decisión subjetiva. Pero básicamente, se trata de cosas que ocurren de forma imprevista o de interrupciones temporales de un servicio con graves consecuencias negativas. Aquí está una idea. La parte superior de un iceberg, donde está la parte bella y visible que flota por encima de las olas, y por debajo de ella la roca que hundió el Titanic que está flotando alrededor por debajo. Eso de allí es lo que absolutamente puede hundir una organización.

  Así que cuantos más incidentes tengan, más probable es que tengan un problema mayor concreto en camino. Así que cuantos más tengan, más probable es que tengan uno, que es lo que intento mostrarles. Pero también, los incidentes mayores que se combinan para crear uno pueden ser muchos y variados. No necesariamente, obviamente, estén interrelacionados.

  Pueden ser entre cosas que están ocurriendo o procesos, errores humanos, descuidos, atajos. Las cosas siguen su curso, podría tratarse de varias cosas juntas. Pero a medida que nos adentramos más en estas cosas y aparece un enorme iceberg flotando alrededor, es cuando un incidente mayor puede empezar a convertirse casi en un tifón, que se une para luego destrozar la organización. Ahí es donde tenemos que ser muy claros y aquí es donde una buena herramienta y una buena mesa de servicio es absolutamente vital para detectar las tendencias dispares que vienen. Ahora bien, algunas cosas son bastante sencillas: si algo se cae, si un servidor se cae y se lleva por delante una aplicación importante, la mesa de servicio se verá inundada de llamadas sobre lo mismo. Lo que probablemente sea un incidente mayor, dependiendo obviamente del servicio que se haya caído.

  Pero, tengan cuidado y piensen en la cantidad de cosas que pueden estar bajo el agua y que no pueden ver y que podrían equivaler a un incidente mayor. Y ahí es donde empezamos a gestionar los problemas y a pensar "He tenido algunas de estas cosas". Y puede que su instinto les diga que esto indica que tenemos algo más y que es aquí donde los incidentes conducen a los problemas y a todo un proceso de problemas. Todo el punto en torno al proceso de problemas es que podemos acceder a un poco más de datos, analizamos las cosas con un poco más de rigor de lo que lo haríamos de otro modo.

• Gestión de problemas - 32:17

  Diapositiva 21: desde el punto de vista del problema, se trata de llegar a la causa probablemente desconocida de uno o más incidentes. Entonces, las actividades en las que alguien usaría herramientas como el analizar la causa raíz, la búsqueda de soluciones alternativas y la eliminación sistemática de la causa raíz eventualmente mediante solicitudes de cambio, es la cosa clave, estamos viendo cuál es el problema subyacente y hay un proceso en ITIL, un proceso de problema que podemos usar para hacer eso.

  Entonces, lo que normalmente tenemos es una serie de incidentes que vienen juntos, que son del mismo tipo o, como acabo de sugerir, cosas que están vagamente conectadas y que sugieren algo, algo más fundamental que se junta para luego garantizar que resolvamos estas cosas adecuadamente.

  Errores conocidos en la gestión de problemas - 33:03

  Diapositiva 22: ahora, cuando identificamos la causa subyacente, obviamente es posible que se necesiten muchos incidentes para comprender la causa raíz del trabajo; cuando identificamos esa causa o factor, obtenemos lo que se conoce como error conocido. Algo que está ahí, sabemos que si tocamos este sistema en particular de una manera particular, siempre responderá de una manera particular, se caerá o recibiremos un mensaje de error particular. Eso es algo que sabemos y podemos publicar, podemos comunicar ese tipo de cosas.

  Pero, cuando analizamos el proceso del incidente para resolver algunas de estas cosas, necesitamos comprender cuáles son esos errores conocidos. Para que podamos identificarlos fácilmente, de dos maneras: una, podemos contarles a los usuarios sobre ellos, para que no tengamos que seguir levantando el teléfono y contárselos, pero también para que luego podamos identificarlos de manera muy directa y ver qué está sucediendo. Y luego, si es posible, darle a la gente una solución alternativa, si esta existe, y una obviamente, si no existe, eso es lo que se conoce en el sistema como solución alternativa y podemos comenzar a usarla para que la gente vuelva a funcionar rápidamente si tenemos uno de estos problemas conocidos rondando por ahí. Pero, debe ser parte del proceso del incidente, tenemos algo que acaba de surgir y tenemos algo para resolverlo.

  Diapositiva 23: ahí está nuestro proceso de incidentes nuevamente, analizando los errores conocidos y las soluciones alternativas, etc.

  Conocimientos e incidentes - 34:33

  Diapositiva 24: Lo que nos lleva a otra área aquí, justo antes de pasar al lado del cambio de otra forma en que podemos ayudar a que se resuelva nuestro proceso de incidente. Tenemos la capacidad de utilizar el conocimiento y los incidentes juntos de dos maneras particulares. Uno de ellos es el autoservicio, por lo que las personas ingresan para registrar una llamada porque tienen un problema o una cuestión que no entienden. Existe todo el concepto de autoayuda en cosas como el autoservicio.

  Entonces, ingresar a la base de conocimientos es un documento de preguntas frecuentes y utilizar ayuda basada en scripts si está disponible en conjuntos de herramientas. Y lo que intentamos hacer aquí es guiar al usuario para que haga las cosas por sí mismo para tratar de solucionar su propio problema. Siguen siendo incidentes y todavía necesitamos registrar ese hecho, porque necesitamos entender con qué frecuencia estas cosas surgen en la vida cotidiana, pero debemos asegurarnos de que entendemos cuáles son esas cosas. Para que podamos solucionarlos o facilitar las cosas. Esa es la primera manera en que podemos utilizar el conocimiento.

  La segunda forma es darle la vuelta a todo y observar cómo los incidentes pueden generar conocimiento, entonces lo que hay aquí es que tenemos eso y tenemos incidentes que deben incorporarse al sistema. Obviamente contienen una descripción del problema que realmente ocurrió, ahora si hemos estado hablando sobre el hecho de generar datos correctamente, si nos hemos asegurado de eso y los datos están ingresados en un buen formato desde el principio y tal vez tengamos a alguien que responda a las llamadas sobre los incidentes y asegurarse de que se hayan hecho correctamente.

  Luego podemos usar esos incidentes en esas descripciones dentro de la base de conocimientos, de modo que en el futuro podamos averiguar cuál es la resolución de ese incidente en particular y podamos publicarlo para que el usuario pueda ayudarse a sí mismo o sea un recurso disponible para que la mesa de servicio luego vaya y resuelva sus propios problemas y vea si se solucionó en el pasado. Pero, básicamente el conocimiento, se ajusta en ambos sentidos, tratando de ayudar a las personas que llegan a través de un autoservicio o, de hecho, de ser parte del dominio del conocimiento, cómo el conocimiento se basa en sí mismo para ayudar a resolver problemas en el futuro. Y también informan el problema, es decir, la parte de la entrada al proceso del problema, algunas de las descripciones de las cosas que se han probado y algunos de los problemas entran en el proceso del problema y nuevamente pueden informar toda la parte de resolución que llega para resolver un problema en particular.

• Incidencias en mesa de servicio - 37:12

  Diapositiva 25: y, por supuesto, cualquier conversación sobre incidentes no terminaría si no habláramos también de su aplicación dentro del service desk. Para ser honesto, he hablado de esto todo el tiempo, la mesa de servicio es la opción. La mesa de servicio utiliza el proceso de gestión de incidentes, es casi como el sable de luz para protegerse y proteger a la organización, lo que obviamente se logra a través del registro de incidentes, asegurando que los clientes obtengan la satisfacción que necesitan en términos de resolución lo más rápido posible o asegurándose de que se resuelvan lo más rápido posible, priorizando esas llamadas de manera eficiente y efectiva, brindando ese soporte de primera línea en términos de tratar de resolverlas en el primer intento, por lo que en algunos anillos aparece la mejor manera de hacerlo. Es resolverlo allí mismo en lugar de tener que pasarlo a otro grupo de expertos de segunda o tercera línea, o a un grupo de redes o lo que sea. Podemos solucionarlo en primera línea, la persona se asegura de que el cliente se ponga en funcionamiento lo más rápido posible, los servicios estén garantizados y se mantengan lo más rápido posible.

  Escalar a otros miembros del equipo si no sabemos la respuesta nosotros mismos. Los equipos tienen diferentes conocimientos y, obviamente, comunicación entre esos grupos y con el cliente. Y finalmente el service desk es responsable y debería ser responsable de contener, gestionar, cotejar, medir y reunir todas las métricas que produce la gestión de servicios, ¿cuántas teníamos?, ¿cuántas de esta categoría en particular?, ¿cuántas para este elemento de configuración?, ¿qué gravedad?, ¿cuántas para este servicio? Y luego comenzamos a mirar los datos que tenemos aquí para comenzar a resaltar dónde podemos mejorar el servicio y la tercera versión de ITIL introdujo todo este concepto de mejora continua del servicio. Quiero decir, para ser honesto, como si fuera algo grandioso en lo que nadie más había pensado, pero, por supuesto, la gente lo ha estado haciendo durante años, ustedes han estado observando el servicio durante mucho tiempo y han tratado de mejorarlo para ver dónde se podía hacer.

  La tercera versión de ITIL le puso un nombre que es la idea de mejora continua del servicio, pero se hace mirando los datos que hemos estado capturando, analizando las tendencias y manteniendo lo mismo para ver si podemos mejorar donde las cosas han estado fallando. Es casi como una gestión de problemas en los datos de la mesa de servicio en sí, pero obviamente la mesa de servicio tiene una función absolutamente vital y el interior y la paz son una parte vital en su arsenal.

  Sepa cuándo parar - 39:55

  Diapositiva 26:Pero yo diría que solo como advertencia, y esto proviene de años y años de experiencia, lo que he visto con diferentes mesas de servicio y es saber cuándo detenerse cuando se trata de analizar esos datos. Es posible, y lo he visto a veces, que las personas toman más tiempo y esfuerzo tratando de analizar hasta el último detalle, capturando hasta el último fragmento de información, y que a veces se tarda más en registrar una llamada de lo que debería, por lo que empezamos a ser contraproducentes en términos de tomar o ralentizar todo el proceso.

  No queremos entender cuál es el elemento de configuración que está afectado, no necesitamos preguntarle a la persona el número de serie, la RAM o el resto, si estamos pensando en eso y eso es importante, entonces deberíamos comenzar a pensar de dónde debería provenir, tal vez de las bases de datos de gestión de activos configuracionales. Pero, tenemos que empezar a analizar cuál es la información de gestión adecuada para gestionar. El solo hecho de un informe de fin de mes que diga que hemos tenido y cerrado 4.000 llamadas, 4.000 incidentes, es una gran estadística, pero ¿qué significa realmente? ¿Es mejor que hayamos cerrado la única llamada que fue causada por las empresas? sitios web para cerrar. Ese es el tipo de ellos, la resolución del servicio, lo importante es la importancia de los datos que presentamos.

  Los que saben sobre administración de redes, saben que tenemos estas cosas llamadas trampas SNMP, las cosas que los enrutadores, las computadoras y cosas como los servidores se ponen en riesgo cuando tienen una crisis. Ocasionalmente, los concentradores y conmutadores de red y otras cosas pueden producir miles de estas cosas. Ahora bien, decirle a la gente que hemos tenido 45.000 trampas es absolutamente irrelevante, excepto si una de ellas acaba con el servicio clave que le está generando a la empresa una enorme cantidad de dinero. Tenemos que asegurarnos de que los datos sean relevantes y significativos, por lo que deberíamos hablar de cosas como la cantidad de tiempo que los servicios estuvieron activos y disponibles para su uso, la cantidad de personas que tuvieron buenas calificaciones de satisfacción del cliente, si sus clientes externos o incluso internos, analizando hechos clave, datos clave que son importantes para esa organización.

  Entonces, en términos de algunos de esos indicadores clave de rendimiento que deberíamos considerar, nuevamente todo se reduce a lo que es importante, por ejemplo, si eres Amazon, asegúrate de tener un 100 % de tiempo libre en tu tienda web. Si se trata de una planta de fabricación, debe asegurarse de que esté produciendo dentro de cualquier tolerancia con la que sus máquinas estén clasificadas, ya sabe lo que sea que sea 98 %, 100 %, 50 %. Cualquier cosa que sea tan importante para su organización debe incluirse y luego compararse con ello.

  Y algunos de los indicadores clave de rendimiento que yo diría para el Service Desk son cosas como la satisfacción del cliente, porque eso realmente te dice cómo te está yendo. Debido a que el cliente no son las personas que brindan el servicio o lo hacen por negocios, si están contentos en general significa que las cosas van bastante bien.p>

  El tiempo que toma la resolución es obviamente muy importante y la resolución de incidentes clave, siendo los incidentes clave aquellas cosas que afectan los principales servicios, entonces, con qué rapidez se resolvieron, con qué rapidez se resolvieron dentro del nivel de servicio acordado. Entonces, si ha acordado un nivel de servicio de dos horas para algunas de sus aplicaciones y servicios clave, entonces si lo está alcanzando, entonces está bien, está en el objetivo, si comienza a vagar por encima de eso, entonces obviamente ahí es donde el cliente comienza a correr el riesgo de no poder hacer lo que necesita.

  Catálogo de servicios y solicitud de servicio - 43:40

  Diapositiva 27: y finalmente, ¿cómo se siente respecto del catálogo de servicios y la solicitud de servicio? ¿Cuál es la diferencia? Bueno, para ser honesto, es una línea muy fina y el Catálogo de servicios obviamente es un lugar donde se brindan muchos de esos servicios. La solicitud de servicio es la forma en que obtiene acceso a esos servicios, ya sea software, hardware o lo que sea.

  Diapositiva 28: entonces, ¿cómo se determina si se trata de una solicitud de servicio o de un incidente? Bueno, muchas personas ponen solicitudes de servicio como incidentes y en realidad no hay nada de malo en eso, los más puros podrían quejarse un poco y decir que no deberían hacerlo. Yo adopto una visión mucho más pragmática: es lo que funcione para usted como organización. Desde un punto de vista purista, oh sí, es posible separar estas cosas, porque tienen formas definibles de hacer las cosas y es posible hacer las cosas de una manera particularmente diferente. Entonces, lo que debemos hacer es comprender qué es un servicio y cuándo un incidente es un servicio.

  Entonces, algunos de los incidentes alternativos que tenemos aquí son cosas como nuevas contrataciones, salidas, solicitudes de equipos, provisión de software y análisis de virus. No hay una respuesta correcta, ya sea un incidente o un servicio o una solicitud de servicio, pero lo que estamos tratando de hacer aquí es asegurarnos de que tenemos el enfoque correcto, que hacemos las cosas de la manera correcta y en el momento correcto y que los niveles de servicio se toman en consecuencia.

  Diapositiva 29: otras cosas que suceden a partir de ahí es que usted define el proceso para esa cosa en particular y lo administra, luego compra la prioridad del producto y luego establece SLA realistas. Entonces, si se trata de un incidente o de un SLA, realmente depende completamente de usted, pero sea lo que sea, asegúrese de que esas cosas estén definidas correctamente y de comprender cuáles son las solicitudes de servicio, cómo las trata y luego las gestiona en consecuencia.

  Proceso de nueva contratación - 46:02

  Diapositiva 30: Algunas de esas cosas que tiene como procesos de incidentes o solicitudes de servicio diferentes, como las tareas de recursos humanos en términos del proceso de nueva contratación, que una lista de cosas que tiene aquí y en términos de cosas como las tareas de TI que lo acompañan. Entonces, la tarea de RR.HH. desde la solicitud de reclutamiento, el rango de cobertura médica y todas esas piezas y luego las tareas de TI que lo acompañan, y ese es el proceso de nueva contratación que se puede resumir en incidentes o dentro de una solicitud de servicio.

  Diapositiva 31: y, por supuesto, cuando se trata de cambios, muchos incidentes generan un problema y luego el problema se soluciona mediante el proceso de cambio. Eso significa que obtiene un análisis preciso, una identificación de los elementos de configuración que están resueltos y un buen análisis del problema que afecta a todos los incidentes particulares. Y obviamente aquí lo que estamos tratando de hacer es tener un vínculo a errores conocidos y solucionarlos y luego lo que podemos hacer es asegurarnos de que una vez que hayamos visto todos los diferentes incidentes, tengamos un problema particular y luego veamos el cambio de ese vínculo que resuelve el problema, y todos los incidentes particulares.

  Gestión de configuración - 47:00

  Diapositiva 32: y finalmente, obviamente, todo se reduce a la gestión de la configuración, saber qué cosas brindan un servicio, los elementos de configuración y eso está definido por todas las relaciones que están contenidas dentro de la base de datos de gestión de la configuración, saber qué es importante y cómo se conecta entre sí y obviamente eso implica comprender el impacto que luego se tiene en la organización a través del cambio, a través del análisis de impacto.

  Por qué la gestión de incidentes - 47:25

  Diapositiva 33: entonces, finalmente, la gestión de incidentes tiene que ver con saber qué es importante, quién es el servicio más importante, quién es el cliente, quién es el contacto, cuál es el tiempo fijo esperado y lo que intentamos hacer es no combatir los mismos incendios una y otra vez. Lo que estamos tratando de hacer es construir un proceso mejor y más repetible en torno al incidente. De modo que nosotros, en realidad, hacemos esta extinción de incendios mucho mejor, de una manera mucho más eficiente y efectiva posible, basándose en el conocimiento de una llamada, documentando lo que sucedió, quién hizo qué y cuándo lo hizo y, obviamente, si estamos haciendo esto, lo que estamos tratando de hacer es evitar la duplicación del trabajo haciendo las cosas una y otra vez repetidamente. No seguimos cometiendo los mismos errores y permitiendo que el negocio entre en dificultades. Realmente estamos tratando de garantizar que las cosas se hagan correctamente. Y también, como dije antes, evita las tareas difíciles en la cuenta de rebote, etc.

  Y finalmente, debe garantizar que la comunicación se produzca entre el individuo y los usuarios y los grupos que han estado involucrados y también los diferentes grupos que están involucrados en la mesa de servicio, los diferentes grupos de gestión de incidentes, etc. Entonces, para concluir, la gestión de incidentes es una pieza absolutamente vital del rompecabezas en términos de brindar servicio a una organización, restaurar el servicio, el buen servicio que es absolutamente vital en una organización para garantizar que el negocio continúe funcionando. Cuanto más tiempo esté inactivo un servicio, mayor será el riesgo para las empresas de la competencia o de perder dinero o lo que sea.

  Entonces, la gestión de incidentes nos permite restaurar un servicio lo más rápido posible, informa el problema y el proceso de cambio y nos permite hacer de manera efectiva para el negocio lo que necesita para mantener esos servicios vivos y en funcionamiento. En ese sentido, le pasaré a Joseph un pequeño fragmento de ManageEngine.

  Hora de preguntas y respuestas: 52:10

  José: gracias Neil. Fue una presentación maravillosa. Tenemos un par de preguntas para usted, en primer lugar: ¿quién debería ser el principal tomador de decisiones en la creación de un SLA?, ¿TI u otras partes involucradas?

  Neil:bueno, para ser honesto, el servicio que se brinda es un servicio comercial. Entonces, es el servicio que la empresa necesita. En ese caso, yo diría que realmente debería ser la empresa la que esté en el asiento del conductor. Pero, obviamente tiene que ser TI quien realmente pueda darle algo de sentido común, no tiene sentido que la empresa grite y golpee la mesa con el puño y patee y diga, no, no, tenemos que tener una solución en 10 minutos. Ya sabes, simplemente no es realista, tenemos que traer a la mesa la realidad de TI y qué problemas de TI o cuánto tiempo pueden tardar en resolverse. Así que tenemos que ser realistas y también tenemos que traer alternativas, así que a veces también tenemos que traer a la mesa, bueno, serán dos semanas, pero sabemos que eso no será aceptable, pero ¿qué tal si hacemos esto o lo otro? Así que creo que probablemente diría que TI debería estar en el asiento del conductor, pero tiene que tomar su prioridad y su importancia del negocio.

  Joseph: bien, gracias Neil. Vale, una pregunta más antes de pasar al resumen del producto de 10 minutos sobre nuestro ServiceDesk Plus. La última pregunta para Neil sería: normalmente resolvemos los incidentes y dejamos que el sistema los cierre automáticamente después de tres días. ¿Cuál es el enfoque recomendado?

  Neil: bueno, esta es una de esas cosas en las que ITIL se basa en las mejores prácticas y es realmente lo que funciona mejor para usted. En algunos casos, lo que podemos hacer es, ya sabes, lo que hacen algunas mesas de servicio es volver al usuario individual y confirmar con ese uso individual que todo está bien. Ahora podemos hacer eso y si no hemos recibido respuesta en tres días, quiero decir que suena como una forma muy razonable de trabajar y hay otras formas de hacerlo, podríamos decir si no hemos recibido noticias suyas o vamos a cerrarlo a menos que tengamos noticias suyas. Pero creo que tiene que haber cierta participación con los usuarios finales, algún acuerdo con el usuario final de que todo está bien con lo que se ha solucionado. Pero creo que es muy sensato decir que si no han recibido respuesta, entonces sí, adelante y ciérrenlo en tres días. Yo diría que es eminentemente sensato.

  José:está bien, ¡gracias Neil! Ahora tenemos a Bhaskar con nosotros, es consultor de productos y nos llevará a través de una sesión de 10 minutos sobre cómo ServiceDesk Plus maneja la gestión de incidentes y también tenemos un par de preguntas más que Bhaskar respondería después de su informe de 10 minutos sobre el producto. Baskar, hazte cargo.

  Cómo ServiceDesk Plus maneja la gestión de incidentes - 53:16

  Bhaskar: ¡Hola! Soy Bhaskar, consultor de productos de ManageEngine y les voy a explicar cómo ServiceDesk Plus maneja la gestión de incidentes.

  Creando incidente con correo electrónico

  Sigamos con la creación de un incidente en particular. Tenemos diferentes modos de crear solicitudes, uno es un correo electrónico donde puede configurar una dirección de correo electrónico para su soporte y cualquiera que envíe un correo electrónico a esa dirección se convertirá en un incidente como se ve en la pantalla.

  Creando incidente con llamada telefónica

  Y ahora, otra forma es una llamada telefónica en la que un usuario final llama al agente de soporte, quien a su vez presentará una solicitud mediante este formulario.

  Creación de incidencia con portal de autoservicio

  Otra opción es un portal de autoservicio donde se da acceso a un portal para los usuarios finales. Entonces, una vez que vienen aquí para presentar una solicitud, pueden ir a una base de conocimientos, una búsqueda en la base de conocimientos, si encuentran la solución, pueden solucionar su propio problema, en caso de que no lo hagan, pueden seguir adelante y presentar un nuevo incidente. Entonces, una vez que presenten un nuevo incidente, estos incidentes se enumerarán en la pestaña de solicitudes, ya que el técnico puede ver estos tickets y seleccionarlos.

  Y antes de crear un ticket cuando ingresa los detalles solicitados, como el nombre de usuario, ServiceDesk Plus tiene una opción para importar los solicitantes desde el directorio activo, por lo que los detalles de estos usuarios se completarán automáticamente y también se mostrarán aquí los activos que pertenecen al usuario. Con esto estaremos evitando preguntas no deseadas al realizar la solicitud sobre cuál es el activo que está utilizando y la configuración de hardware de los mismos.

  Urgencia, Prioridad e Impacto (Matriz de Prioridades)

  A continuación pasamos a la urgencia y prioridad con el impacto. Puede elegir el impacto y la urgencia, esto se puede configurar como una matriz de prioridades en la sección de administración. Esto le ayudará a determinar la prioridad correcta en función del impacto y la urgencia del negocio. Esta también es una de las mejores prácticas de TI y también le hemos brindado la flexibilidad de modificar el negocio, ya sabe, la urgencia, el impacto y la prioridad, y los usuarios y el técnico pueden anular esta matriz de prioridades, pero no lo recomendamos.

  Clasificación de incidentes

  A continuación veremos la clasificación de incidentes. Puede clasificar diferentes tipos de incidentes en diferentes categorías como ve en la pantalla. Admitimos una jerarquía de categorías, subcategorías y elementos mediante los cuales se puede clasificar de forma granular un tipo de incidente. Por lo tanto, una categorización de incidentes es muy importante, ya que le ayudará a comprender el origen de todos los incidentes. A continuación podrás elegir el grupo y el técnico y presentar una solicitud.

  Automatización de reglas de negocio

  Vamos a analizar las reglas comerciales, todos estos parámetros como categoría, subcategoría, grupo y técnico, que se pueden configurar automáticamente con la ayuda de una regla comercial. La automatización de reglas comerciales y ServiceDesk Plus ayudan a organizar las solicitudes entrantes y realizar cualquier acción, desde categorizar un incidente, entregarlo a un grupo y asignarlo a un técnico. Entonces aquí es donde está la regla comercial, ingresa a administración > reglas comerciales. Podemos definir un criterio, podemos realizar una acción para colocar en un grupo todos los tickets de alta prioridad. Y también tenemos una opción para enviar un correo electrónico y un SMS a un técnico en particular donde se ejecuta una regla comercial, lo que debería ser útil cuando un técnico también sabe cuál es el ticket que se le está asignando.

  Configuración de plantillas para problemas frecuentes

  Y ahora veremos las plantillas disponibles que se pueden configurar en la sección de administración. Los problemas o incidentes que ocurren con frecuencia, como problemas con el correo electrónico o la impresora, se pueden configurar como plantillas. Con todos estos parámetros completados previamente, lo que hace que el registro de incidentes sea mucho más fácil, por lo que puede completar estos campos previamente. Digamos, por ejemplo, que si se trata de una plantilla de problema de impresora, puede configurar estos valores y guardarla como plantilla. Entonces, cada vez que un técnico quiera crear una solicitud para un problema de impresora, puede acceder al botón Nuevo incidente y seleccionar la plantilla de problema de impresora. Esto completará automáticamente la información de esos campos.

  Expresiones de gratitud

  Y a continuación, veremos cómo se envían los acuses de recibo a sus usuarios finales. Entonces, una vez que creo un ticket con el nombre del solicitante, se envía un correo electrónico de confirmación al usuario final con el número del ticket, para que la próxima vez que llame, el servicio de asistencia técnica pueda referir el número del ticket.

  Acuerdo de nivel de servicio

  Y vamos a analizar el acuerdo de nivel de servicio. Una vez que se crea un incidente en la mesa de servicio, el SLA nos ayuda a establecer un plazo para una solicitud en particular. Aquí puede ver la fecha de creación, el vencimiento por tiempo y la respuesta al vencimiento por tiempo. La fecha de vencimiento es la fecha de vencimiento de la resolución y el tiempo de respuesta será la primera respuesta para este ticket en particular y esto se configura en administrador > acuerdo de nivel de servicio.

• Respuesta a incidentes

  Por lo tanto, si una solicitud no es atendida por un agente del servicio de asistencia después de un período determinado, se enviará un correo electrónico de escalamiento automático a otro técnico para informarle que el incidente se ha incumplido. Puede configurar el SLA de nivel de respuesta y el SLA de resolución aquí. Para ello, he establecido una prioridad alta para un problema de recepción de correo; el nivel de respuesta debe ser en una hora, y la primera respuesta y la resolución en ocho horas. También puede habilitar el escalamiento para que el otro técnico reciba una notificación cuando se escale este SLA. De esta manera, una vez creado un ticket con un SLA, un técnico busca la resolución del error para este ticket en particular.

  Búsqueda de una solución/base de conocimientos

  En ServiceDesk Plus, le ofrecemos la comodidad de buscar soluciones para un ticket específico, basándose en el asunto de un correo electrónico específico. Aquí encontrará la lista de soluciones disponibles en la base de conocimientos; puede seleccionar la solución y copiarla al incidente. Una vez copiada, puede cambiar el estado a "resuelto". Como técnico, también puedo agregar el registro de trabajo sobre el tiempo que he trabajado en este ticket, el tiempo dedicado y la resolución de problemas realizada.

  Reglas de cierre de solicitudes / Cierre automático

  Por lo tanto, un incidente solo debe cerrarse si el usuario final confirma que la resolución proporcionada es válida. Para ello, tenemos un parámetro en "Administración > Reglas de cierre de solicitudes". Aquí es donde definiremos los campos obligatorios que deben completarse antes de cerrar una solicitud. A esto me refería: la confirmación del usuario final. Neil también mencionó el cierre automático de un ticket. Aquí se puede configurar un cierre automático una vez que un ticket pasa al estado de resolución, especificando el número de días (tres días después) para el cierre automático. Esta es una importante práctica recomendada de ITIL, ya que el técnico no tiene que realizar un seguimiento constante de la respuesta del usuario final.

  Encuesta de usuarios

  A continuación, analizaremos la satisfacción del usuario final. Tenemos una opción en "Administración > Configuración de la encuesta". Uno de nuestros asistentes también preguntó: "¿cuál es el método que utilizan para evaluar la satisfacción del cliente?". Para ello, contamos con la opción de habilitar una encuesta para cada ticket creado en Service Desk que se haya cerrado. Este nivel de satisfacción se mostrará debajo de los resultados de la encuesta, junto con los comentarios adicionales.

  Módulo de informes

  En el módulo de informes, que analiza cómo evaluar mejor la gestión de incidentes, se han predefinido más de 100 informes que se pueden generar según el incumplimiento del SLA, el número de tickets entrantes por día, los tickets pendientes de cada grupo de técnicos y la lista de tickets con alta prioridad. En la sección de informes, se puede crear un informe personalizado para cada solicitud y elegir los campos necesarios. Por lo tanto, la gestión de incidentes funcionará mejor con ServiceDesk Plus.

  También analizaré otra pregunta de un usuario final: actualmente utilizamos la versión ServiceDesk Plus en nuestro departamento de TI y nos gustaría ampliar el sistema a los departamentos de RR. HH., finanzas y otros para que los usuarios puedan solicitar un servicio ¿Cómo podemos hacerlo?

  En ServiceDesk Plus, la versión Enterprise incluye la función Catálogo de Servicios, que permite agregar categorías de servicio predefinidas. Agregar un servicio a una categoría le permitirá elegir la lista de usuarios a quienes desea mostrar estos servicios. Los grupos de usuarios se pueden configurar en Administrar > Grupos de usuarios. Aquí puede elegir criterios como, por ejemplo, el puesto de trabajo. Puede configurar un filtro para mostrar la lista de usuarios del departamento de TI. Una vez configurada una solicitud de servicio, esta se mostrará solo al departamento de TI, sin que los demás grupos de usuarios tengan acceso a este servicio.

  ICon esto concluimos la sesión sobre cómo optimizar la gestión de incidentes en ServiceDesk Plus. Gracias a todos por su asistencia.