Transcripción del webinar

• Introducción:

  Joseph: El presentador de este seminario web es Neil Thomas, director gerente y vicepresidente de servicios profesionales de Service Sphere. Tiene una amplia experiencia en la industria de TI, soporte de TI y consultoría de ITIL. Se especializó en catálogo de servicios y CMDB. Neil se hace cargo.

  Neil: Genial, gracias Joseph, bienvenidos a todos y es bueno tenerlos de nuevo en esta serie de seminarios web, 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ó su nombre recientemente a SERVICE SYMMETRY, somos una rama de lo que era Service Sphere. Así que hacemos un montón de piezas sobre ITIL, formación de ITIL, consultoría de formación de instituto de mesa de servicio, aprendiendo todas esas cosas buenas que tienes allí. Entonces, si está interesado, comuníquese conmigo, pero lo más importante es el hecho de que todas esas cosas buenas me han permitido tener muchos años de experiencia dentro de la industria, especialmente en términos de ITIL como consultor, pero también como gerente de producto trabajando. para un proveedor en términos de construcción y construcción de conjuntos de productos de gestión de servicios de TI desde el incidente hasta el Catálogo de servicios.

  Serie de seminarios web - 1:27

  Diapositiva 4: Así que, sin más preámbulos, esta es la tercera de la serie de ManageEngine, que realmente nos lleva directamente desde el Catálogo de servicios, habla sobre cómo los servicios son efectivos en el negocio y cómo los utiliza la empresa, lo que les brinda las cosas en la base de datos de administración de configuración , elementos de configuración y similares y luego, por supuesto, las cosas buenas con las que todos estamos familiarizados sobre incidentes, problemas y cambios y luego el último de la serie dentro de unas semanas será cómo medimos el rendimiento de la mesa de servicio .

  Así que hoy se trata de incidentes y es muy interesante ver a algunos de ustedes en la llamada hoy y ¿por qué la gente está tan interesada en los incidentes? ha existido durante una gran cantidad de años y lo que estamos viendo es volver a algunos de los conceptos básicos, y es muy interesante que debamos estar haciendo esto porque, en mi función de consultor, me encuentro con muchos organizaciones que usted conoce, qué hacer gestión de incidentes, marcan la casilla y, lamentablemente, se equivocan. Es muy frecuente que se olviden los principios fundamentales de la gestión de incidentes. Así que, siendo ManageEngine las buenas personas que son, pensó que sería un buen momento para volver a visitar algunas de esas cosas. Entonces, para aquellos de ustedes que están ahí fuera, es un poco ponerse al día, para aquellos de ustedes que son los primeros en el juego y quieren saber un poco más al respecto. Luego, esto cubre algunos de los conceptos básicos que tenemos sobre la gestión de incidentes.

• Temas de hoy - 2:48

  Diapositiva 5: Por lo tanto, veremos dónde encaja dentro de todo el marco de ITIL, simplemente hacer incidentes no es suficiente, porque hay muchas otras partes y piezas que no necesariamente tiene que hacer, pero ciertamente tiene para comprender, considerar y poner la cosa en su contexto observando un poco cómo encaja en la mesa de servicio, cómo se compara el incidente con las solicitudes de servicio. Otro flujo de trabajo de incidentes analiza un poco de conocimiento y cómo encaja, así como todo el asunto de los acuerdos de nivel de servicio y la buena relación antigua entre incidente y problema e incidente y cambio. Todo es parte del mismo marco de ITIL.

  Diapositiva 6: Entonces, sin más preámbulos, llegamos a una diapositiva que ha visto varias veces antes, estos son los servicios que la empresa ofrece y que TI está brindando y brindando. Entonces, estas son cosas que puede encontrar en el Catálogo de servicios, pero ciertamente son cosas que la empresa hace, desde ventas hasta marketing, soporte de campo y verificación de crédito en finanzas, lo que sea, todas las piezas, todas las funciones dentro de una organización que necesita para La supervivencia, por supuesto, está respaldada por TI y servicios de TI y, por supuesto, esos servicios de TI a veces no funcionan como deberían, que es donde entra todo el incidente.

  Diapositiva 7: Echemos un vistazo a eso en contexto, de modo que esos son servicios en el medio e ITIL está ahí y la gestión de servicios de TI está ahí para respaldar esos servicios y esa es la clave, la gestión de incidentes no solo existe para convertirnos en sentirse bien y conseguir que trabajemos un lunes, aunque proporciona a mucha gente muchos trabajos. No, la gestión de incidentes se trata de asegurarse de que los servicios que se prestan a una organización se sigan prestando porque sin ellos la empresa no está siendo tan eficiente como debería y es probable que tenga problemas.

  Por lo tanto, el usuario necesita algo para que se le entregue un servicio mediante solicitud de servicio o al Catálogo de servicios y si algo sale mal con ese servicio, ese es el buen trabajo de la gestión de incidentes. Es fundamental que si algo se rompe, tenemos que arreglarlo, tenemos que volver a poner en funcionamiento ese servicio porque cada minuto que el servicio no funciona le cuesta a la empresa dinero, tiempo, ineficiencia, la competencia se interpone en el camino, etc. así que una pieza muy vital de todo el rompecabezas, obviamente una mentira es la rapidez con la que esas personas, esos servicios son respaldados. Así que toda la idea de la gestión del nivel de servicio entra aquí, lo abordamos brevemente hoy.

  Ahora bien, si algo sigue saliendo mal de nuevo, el vínculo entre el incidente y el problema entra aquí, algo sigue saliendo mal, entonces obviamente pasamos al principio completo de la gestión de problemas , y estos son procesos, mejores prácticas que ITIL ha puesto en marcha como parte de su marco de la versión 3.

  Ahora, si sigue yendo mal, descubrimos cuál es el problema y queremos solucionarlo, entonces obviamente comenzamos a buscar en la gestión del cambio, cambiando las cosas de una manera muy rigurosa y definida en un proceso. Para que no tengamos riesgos introducidos en la organización, administre el riesgo fuera de ella. La cuestión es que la forma en que proporcionamos esos cambios al negocio tiene que ver con la gestión de versiones, luego tenemos lo que ofrece la gestión de la configuración, cómo nos aseguramos de que todos esos servicios estén allí en el futuro, todas esas otras partes y piezas esotéricas que obtenemos de ITIL de disponibilidad, capacidad, gestión de la continuidad del servicio y luego, por supuesto, finalmente lo sentimos, pasamos a la gestión de esos servicios con la cartera de servicios y la gestión financiera.

• Gestión de incidencias 6:40

  Diapositiva 8: Entonces, vamos a la gestión de incidentes., así que realmente esta diapositiva resume lo que he estado diciendo acerca de que todo está ahí para restaurar el servicio normal lo más rápido posible. Creo que ciertamente la gente de la mesa de servicio, cualquiera de ustedes que esté ahí fuera y ciertamente desde mi propio punto de vista, haya hecho esto en mi historia. La clave que los usuarios quieren y por lo que se sienten frustrados es continuar con su trabajo, ellos saben que cada minuto que no están trabajando allí, es una desventaja para el negocio en la que las eficiencias podrían entrar y, a veces, por supuesto, con grandes interrupciones. , con grandes problemas, tenemos que abordar estas cosas rápidamente. Por lo tanto, tener un buen proceso de gestión de incidentes y poder gestionarlo correctamente es absolutamente vital. Así que supongo que una definición es un buen material de ITIL aquí,

• Elementos clave - 7:34

  Diapositiva 9: Entonces, las cosas clave, algunos hechos clave, supongo, acerca de los incidentes, bueno, 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 tratarse instalaciones, podría ser sobre recursos humanos, podría ser sobre servicios o equipos de TI. Puede abarcar una amplia gama de cosas diferentes, que el lapso y la respiración realmente depende de ustedes y, por supuesto, estos días pueden informarse por cualquier medio posible, no solo las personas que en mi día corren hacia ustedes y dicen "Mira, tengo un problema, ¿cómo puedo hacer esto? O mi computadora está rota". pero es informado por correo electrónico, por teléfono, por principiantes de autoservicio. Ahora entramos en todo el aspecto de las redes sociales con cosas como Twitter y Facebook, algo que yo '

  Otra área en la que las cosas han salido mal, si lo desea, es en la infraestructura, y hay una pieza completa que ahora se ha creado 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 generan automáticamente un incidente. y casualmente también puede cerrar incidentes automáticamente. Pero al menos tienes una visibilidad de lo que ha sucedido, no voy a tocar mucho eso hoy, excepto que se pueden plantear de una manera particular y obviamente estos son normalmente todos estos incidentes que se reportan registrados en la mesa de servicio para asegurar que exista es alguien que está gestionando todo el proceso y averiguando qué está pasando y todo eso produce datos, los datos son absolutamente vitales en ITIL para poder continuar y mejorar y resolver los servicios,

• 9:16

  Diapositiva 10: Ahí tenemos los elementos clave bajando un poco más en detalle detectándolos, registrándolos, clasificándolos, investigándolos, diagnosticando y luego resolviéndolos y luego recuperando y luego cerrándolos y en ese cierre, entonces este tipo de proceso que ha presentado ITIL, el punto aquí es que la información correcta se mantiene y se captura en todo momento y que se sigue el proceso.

  Gestión de incidencias con las mejores prácticas de ITIL:

  ITIL tiene que ver con las mejores prácticas y con la gestión de incidentes, debe atenerse al proceso o procesos, como veremos más adelante. Y es muy importante asegurarse de que se cumplan todas las diferentes piezas, de lo contrario, las cosas comenzarán a salir mal y, ciertamente, con la gestión de incidentes, he visto tantos grupos en los que tienen un proceso, conjuntos de herramientas fantásticos, pero el problema es que simplemente ponen en datos basura y, por supuesto, cuando está sacando datos basura del back-end, los datos basura entran y salen basura. Debe poder asegurarse de que las personas ingresaron los datos en primer lugar que el diagnóstico es preciso, que está verificado y que las resoluciones una vez que ingresan y responden a esos incidentes, también son correctas y obviamente forman parte de esto. así como todo el aspecto de la propiedad, poseer un incidente en particular o un grupo dentro de la mesa de servicio poseer un incidente monitorearlo, trabajar para aprovecharlo, rastrearlo a través de los diversos grupos y comunicarse con los diversos grupos dentro de la mesa de servicio. Y, por supuesto, al buen usuario al final, que es la persona que está sentada allí esperando que se le restituya ese servicio. La gestión de incidentes, ITIL y Service Desk no existen para su propio beneficio, existen para el beneficio de la organización para garantizar que los servicios se restablezcan lo más rápido posible. Y, por supuesto, al buen usuario al final, que es la persona que está sentada allí esperando que se le restituya ese servicio. La gestión de incidentes, ITIL y Service Desk no existen para su propio beneficio, existen para el beneficio de la organización para garantizar que los servicios se restablezcan lo más rápido posible. Y, por supuesto, al buen usuario al final, que es la persona que está sentada allí esperando que se le restituya ese servicio. La gestión de incidentes, ITIL y Service Desk no existen para su propio beneficio, existen para el beneficio de la organización para garantizar que los servicios se restablezcan lo más rápido posible.

  Proceso / flujo de trabajo de gestión de incidentes - 11.03

  Diapositiva 11: Hay un proceso de gestión de incidentes que muestra las diferentes fuentes desde la parte superior, y vale la pena analizar algunas de estas cosas aquí, independientemente de la forma en que se presente, identificamos el incidente que comenzaríamos a categorizar e ITIL y, de hecho, Todo el principio de la mesa de servicio consiste en tratar de gestionar las cosas mediante la clasificación. Observamos los tipos, observamos los diferentes tipos preexistentes que tenemos, de modo que podamos comenzar a determinar si se trata de hardware, software, una pieza de software en particular, una persona en particular, una hora del día o un grupo. Entonces, queremos comenzar a comprender los datos y luego, una vez que los tengamos, podemos verlos y usar el análisis de tendencias para asegurarnos de que entendemos lo que está sucediendo.

  Entonces, alterne con los datos, los categorizamos y veremos algunas de estas piezas en un minuto, ¿es una solicitud de servicio? Si no es así, la solicitud de servicio es algo que alguien quiere y no dice lo que regresa en un minuto, entonces comenzamos a decir ¿cuál es la prioridad? Y por supuesto priorizamos según el servicio que se está viendo afectado. ¿Es un incidente importante?nuevamente, algo a lo que llegaremos en un minuto o es solo una cosa común y corriente si es importante, se trata de una manera diferente, luego hace un diagnóstico inicial, míralo rápidamente. Ahora bien, ¿es necesario intensificar ese incidente? ¿Tenemos todos los datos? ¿Tenemos un conjunto de habilidades y las herramientas para poder resolver eso aquí y ahora? Si es así, seguimos adelante y lo hacemos. Si no lo hemos hecho, se dispara y se dirige a otros grupos para una jerarquía o escalamiento de pares. Y, por supuesto, a medida que llegamos al final del proceso, buscamos resolverlo asegurándonos de que tenemos la resolución guardada con precisión dentro del incidente, y luego miramos la recuperación y lo que se debe hacer para volver a un nivel completo de servicio. Puede ser algo más que decirle al tipo del otro lado cómo lo arregló,

  Y finalmente, por supuesto que hay un cierre de incidente, realmente deberíamos estar mirando con un cierre de incidente, asegurándonos de que el usuario esté contento con lo que ha sucedido. Muy a menudo veo incidentes cerrados por diferentes equipos y lo que sucedió es que lo cerraron sin siquiera referirse al usuario. Bueno, tienes que averiguar si el usuario está realmente satisfecho con lo sucedido. Por lo tanto, una parte de un buen cierre es la satisfacción del cliente o volver a la persona para asegurarse de que se resuelva a su satisfacción.

• Registro de incidentes - 13:40

  Diapositiva 12:Así que aquí vamos a entrar en un poco más de detalle, lo registramos, observamos estas cosas que normalmente se registran en la mesa de servicio, registramos todos los incidentes, aunque hablaremos de eso en unos minutos si registramos absolutamente todos y cada uno one y echamos un vistazo, ¿cumple con el acuerdo de nivel de servicio para un servicio en particular? Entonces, cuando comenzamos a ver el servicio que se ve afectado, observamos el nivel de servicio que ya se ha acordado para asegurarnos de que lo trataremos de la manera correcta. Registre todos los datos relevantes y esa pequeña oración allí como yo '

  Es muy importante que la base de registro se realice correctamente y, obviamente, existe la posibilidad de que otras personas que no están en la mesa de servicio también informen incidentes rápidamente. Les animo a aquellos de ustedes, que aún no se han metido en algún tipo de modo de autoservicio, sea lo que sea por correo electrónico o en Internet o incluso por Facebook y Twitter, a que realmente lo consideren como un mecanismo para ingresar datos. el sistema para registrar llamadas. Sin embargo, hablando del lado de los datos, sí significa que tenemos que considerar bastante bien lo que ha sucedido con los datos y tal vez tener que masajearlo para asegurarnos de que entendemos cuál es el verdadero problema, el verdadero incidente y ponerlo al día. . Para que se asiente en la base de datos con datos suficientes y suficientes.

  Categorización de incidentes - 15:30

  Diapositiva 13:Luego lo categorizamos, ahora que mencioné nuevamente esta categorización, hay dos aspectos que realmente estamos tratando de determinar el tipo de incidente, ya sabes, por ejemplo, el servicio de TI se ha degradado y lo que se ha afectado y de lo que hablamos la última vez. las cosas que brindan servicio y esas cosas son activos o, como los llamamos en ITIL, elementos de configuración. Observamos los que se han visto afectados y, cuando anotamos el incidente, realmente debemos comprender 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 determinarán cómo rápidamente deberíamos responder a ella y obviamente deberíamos utilizar algún tipo de criterio de codificación estandarizado. Normalmente, estas cosas se manejan muy bien con los conjuntos de herramientas que tiene con ManageEngine. Para que esté listo para usted y solo tenga que elegir de una lista predeterminada, cualquiera de los conjuntos de herramientas es simplemente perfecto. ITIL clama y ha estado clamando durante mucho tiempo por buenos conjuntos de herramientas para poder ayudar a las personas a hacer estas cosas de manera más efectiva y, por supuesto, eso es lo que tenemos aquí.

  Priorización de incidentes (gravedad) - 16:35

  Diapositiva 14:Luego lo priorizamos y, por supuesto, todas estas cosas aquí categorizando y luego especialmente la priorización tiene que ver con el servicio. No solo miramos un incidente y decimos "¡bueno! Eso se siente señor, oh, creo que es bastante severo quién está en la llamada, oh, es alguien muy amable, el otro amigo mío por quien voy a hacer eso", no, lo hacemos sobre la base de una rutina establecida, una serie de cosas como la importancia de ese servicio para la organización. Realmente no puede entrar mucho en los acuerdos de nivel de servicio en este seminario web, pero en realidad no es como asegurarse de los acuerdos entre TI y la empresa. Para que TI entienda lo que es importante. Entonces, si la empresa dice que el departamento de finanzas a fin de mes es absolutamente vital, debe mantenerlos en funcionamiento,

  Entonces, aquí tenemos una lista de ejemplo de priorización y severidad para eso, por lo que en el nivel 4, no hay impacto comercial como si no hubiera pérdida de servicio. Nivel 3, una pérdida menor de servicio hasta una pérdida total del servicio. Ahora, algunas de estas cosas son cosas muy estándar que obtiene de los libros de ITIL o puede crearlas usted mismo y algunas de las herramientas las tienen predefinidas. Pero vale la pena ser bastante simple en estas cosas.No entraría en muchas prioridades y severidades, hay una organización como el otro día que tenía 18 niveles diferentes de severidad cuando llegas a usar eso en el escritorio es muy difícil trabajar es a los 17 o 16? Hmm, no sé, ¿brilla el sol? se vuelve muy, muy esotérico en ese punto, no,

  Escalada de incidentes - 18:27

  Diapositiva 15: Entonces se trata de escalarlo y los conjuntos de herramientas lo ayudan a escalar de manera muy, muy efectiva. Porque lo que tenemos que hacer es gestionar y qué sucede con esos incidentes si la primera persona que se apodera de ellos dentro de un proceso de incidentes no puede resolverlos no tiene el conjunto de herramientas o la experiencia, entonces obviamente necesitan ser escalados como lo más rápido posible para asignar los recursos correctos 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 quiera verlo.

  Y obviamente, debería haber reglas sobre cómo esas cosas escalan y una de las cosas que necesitamos tener aquí es el legendario recuento de rebotes que debemos resolver y asegurarnos de que, ese espacio muy bajo, recuento de rebotes para aquellos que ' No me he encontrado con este término entretenido tiene que ver con una serie de veces que los incidentes rebotan no regresa si quieres entre los diferentes grupos como dice alguien. Es un poco como patatas calientes, así que alguien dice "¡oh! esto es un poco complejo ”y entréguelo a otro grupo, que piensa exactamente lo mismo y transmítalo a otro grupo. Los incidentes pueden ir rebotando alrededor del sistema como una pelota alrededor de la cancha de squash muchas veces si no tiene un ojo atento a cuántas veces se ha pasado realmente de un grupo a otro y eso ' s la mesa de servicio de la función o quien sea el dueño de ese incidente en particular y yo diría que la propiedad es una pieza vital de cualquier proceso de gestión de incidentes y servicios. Y he enviado esos datos precisos en la parte inferior. Debería haberlos puesto en cada diapositiva en realidad, cada vez que se toca algo con un incidente, procesa datos precisos hasta el final.

  Resolución de incidencias / 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. Entonces, cuando lleguemos a resolverlo y verá esto en un minuto, buscaremos errores conocidos, lo explicaré en un segundo o soluciones alternativas existentes. Resolvemos el incidente con las soluciones o la solución alternativa y, a veces, la solución significará que se debe enviar una solicitud de cambio y un RFC, de modo que el incidente no es solo un fin en sí mismo, en realidad sigue adelante como veremos en un segundo después de ser resuelto a través del proceso del problema y, de hecho, también a través del proceso de cambio y no lo olvidemos y creo que este debería ser el mantra, esta pieza en rojo debería pegarse en la pantalla de todos o tal vez podamos hablar con ManageEngine para que brille en escritorios de las personas cada tres segundos. Pero el objetivo de la gestión de incidentes es restaurar el servicio, de eso se trata, lo mejor para toda la organización si nada falla. Pero ese escenario nirvana o lo que no sucede, suceden cosas, las personas suceden, el equipo falla, las personas no se presentan al trabajo porque están enfermas, entonces las cosas simplemente no funcionan, un buen proceso de gestión de incidentes restaura el negocio a funcionamiento normal lo más rápido posible. Ese es nuestro mantra que casi deberíamos decir cada dos segundos mientras caminamos tratando de arreglar los incidentes. Pero ese es el objetivo y por eso realmente se trata la gestión de incidentes, ese proceso que acabo de realizar. Sucede, suceden cosas, suceden personas, el equipo falla, las personas no se presentan a trabajar porque están enfermas, por lo que las cosas simplemente no funcionan, un buen proceso de gestión de incidentes restaura el negocio a la operación normal lo más rápido posible. Ese es nuestro mantra que casi deberíamos decir cada dos segundos mientras caminamos tratando de arreglar los incidentes. Pero ese es el objetivo y por eso realmente se trata la gestión de incidentes, ese proceso que acabo de realizar. Sucede, suceden cosas, suceden personas, el equipo falla, las personas no se presentan a trabajar porque están enfermas, por lo que las cosas simplemente no funcionan, un buen proceso de gestión de incidentes restaura el negocio a la operación normal lo más rápido posible. Ese es nuestro mantra que casi deberíamos decir cada dos segundos mientras caminamos tratando de arreglar los incidentes. Pero ese es el objetivo y por eso realmente se trata la gestión de incidentes, ese proceso que acabo de realizar. Estás caminando tratando de arreglar los incidentes. Pero ese es el objetivo y por eso realmente se trata la gestión de incidentes, ese proceso que acabo de realizar. Estás caminando tratando de arreglar los incidentes. Pero ese es el objetivo y por eso realmente se trata la gestión de incidentes, ese proceso que acabo de realizar.

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

  Diapositiva 17:Entonces, algunas cosas clave que simplemente lanzo aquí que son muy importantes no encajan particularmente bien en ningún lugar, así que las coloco justo en el medio de la presentación, me hago cargo de un incidente, ya sea como individuo o como grupo. y conjuntos de herramientas que le permiten hacerlo aún mejor. Tengo una lista de carga de trabajo de las cosas que estoy haciendo, la persona responsable puede decir, ¿verdad quién tiene esto? ¡ah !, George tiene esta instancia en particular, la va a ejecutar, hay un punto de contacto para el usuario, hay alguien que tiene la responsabilidad de hacer que estas cosas funcionen. Si no puede

  Queremos mantenernos enfocados en el incidente, no hay engaños, perdóneme si uso el término equivocado aquí, para aquellos de ustedes aquí en los Estados Unidos, pero sin lado ciego y queremos asegurarnos de que el incidente sea la clave. No querrá dejarse intimidar por otras cosas que surjan y que encontremos en el incidente. Un incidente puede generar otros incidentes de diferente tipo, está bien, pero lo que tenemos que hacer es mantenernos realmente, realmente concentrados en lo que tenemos entre manos y no dejarnos desanimar por otras cosas en el borde, escalar a las personas en el en el momento adecuado de una manera adecuada y rápida, y también escalar rápidamente a la gerencia si hay un problema en términos de hacer cosas o hacer cosas.

  Eso sucede a menudo en la mesa de servicio, que las cosas simplemente gotean y se quedan allí porque a la gente no le gusta tocarlas, es casi como un recuento de rebotes negativo, el recuento de rebotes va de un incidente de papa muy caliente a diferentes personas. Casi tengo este tipo de incidente, nadie quería tocarlo y nunca le pasa nada, nuevamente, para eso están los gerentes y es por eso que la mesa de servicio y la buena administración del servicio ayudan a las personas a comprender y se responsabilizan del problema.

  Supongo que el siguiente punto debería ser en letras rojas pulsantes "mantener al cliente informado" nuevamente, el cliente es el punto clave aquí y creo que en realidad en estos días todos entendemos que el cliente es el usuario que está al otro lado del teléfono para nosotros. , debido a que a menudo somos el cliente al final del teléfono con otras personas en nuestra vida cotidiana cuando usamos equipos de TI, estamos en el banco en casa o lo que sea que estamos haciendo en Internet, nos gusta tener servicio nos han dado muy rápido, nos gusta que nos sirvan y nos cuiden de forma muy, muy eficaz y muy bien. Entonces entendemos estas cosas ahora y estar informado sobre lo que está sucediendo es una parte realmente importante para garantizar que el negocio continúe porque si el cliente sabe que no va a recibir una entrega rápida debido a cualquier resolución,

  Actúe como una interfaz entre los diferentes grupos nuevamente si lo posee, pero otras personas hacen cosas en él y luego realizan un seguimiento del tiempo y las actividades, todo está muy bien, solo soluciona un problema, pero si su lista de carga de trabajo tiene 20 en Eso, solo esté atento a esas otras cosas, es muy importante asegurarse de que se atiendan las llamadas prioritarias que están entrando. Es posible que esté haciendo algo para alguien que es importante, pero si es Amazon y el sitio web principal baja la pieza de pedido, entonces realmente tiene que hacerlo lo más rápido posible, todo tiene que ver con esos servicios.

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

  Diapositiva 18:Y volviendo a una visión diferente del proceso de gestión, obviamente, ya que sabemos por ITIL que, aunque hay un par de procesos establecidos dentro del marco de ITIL. Hay muchas interpretaciones y muchas implementaciones, eso es lo bueno de ITIL. Es flexible, se trata de las mejores prácticas y le brinda ideas sobre cómo hacer las cosas. Así que mire su proceso de incidentes y vea cómo se puede adaptar a su negocio a su organización y vea si los ajustes pueden funcionar, este en particular es bastante interesante, porque tenemos que el cliente deje de comunicarse con la mesa de servicio para la creación de un problema de ticket. siendo identificado, ¿es un incidente? Pero no, podría ser una solicitud de servicio en un minuto. Si es así, llegamos a esta cosa llamada errores conocidos e interrupciones, si es así, ¿hay alguna solución que podamos aplicar? si no, entonces va a la escalada. Entonces, lo que vamos a hacer ahora es avanzar en el área completa de cómo los incidentes se interrelacionan con cosas como problemas y ese tipo de cosas también.

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

  Diapositiva 19: En primer lugar, sin embargo, al tocar los acuerdos de nivel de servicio, estas son las cosas dentro de un incidente que es muy importante tener en cuenta, porque estas son las cosas que nos permiten identificar en qué cosa trabajar primero. Ahora no olvide que los acuerdos de nivel de servicio son aquellas cosas que deberían ser, pero no siempre lo son, deberían ser negociadas y acordadas con la organización de un cierto nivel de respuesta. A veces, no siempre sucede SLA impuesto por TI al resto de la organización, lo que a veces tiene que suceder porque así es como funciona y las organizaciones no siempre ayudan, pero estas cosas deben acordarse con la organización.

  Entonces saben que cuando algo sucede, van a obtener una respuesta en un cierto período de tiempo, nuevamente estamos estableciendo expectativas, estamos ayudando a la gente, estamos tratando de ser buenos miembros de la organización. Para que puedan trabajar dentro del marco, si algo tarda cuatro horas u ocho horas o dos semanas en solucionarlo, ese es el tiempo que lleva. Pero debemos decirle eso a la empresa y obtener su acuerdo al respecto. Por lo tanto, podemos comenzar a buscar formas de evitarlo para asegurarnos de que el negocio siga funcionando. Trabajamos con la empresa en términos de SLA, diferentes AFT diferentes SLA, diferentes cosas, diferentes prioridades y diferentes elementos de configuración. Entonces, un servidor probablemente tenga una prioridad mucho más alta que la PC de escritorio de alguien, a menos que tal vez esa PC de escritorio tenga algo que ver con el sistema de nómina a fin de mes.

  Un usuario en particular, ya sabes, el director general, el director general, el director ejecutivo siempre es una persona importante para hacerlo bien, pero ¿son realmente más importantes que el vendedor al final del mes? Está tratando de obtener algunos contratos y usted no puede obtener un sistema de correo electrónico en particular por alguna razón, el archivo adjunto no funciona, a veces esas personas al final del mes cuando están tratando de obtener un contrato son más importantes que incluso el director ejecutivo, sin embargo, podría parecer al revés 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 diferentes organizaciones varían considerablemente entre sí. Pero nuevamente ha vuelto al servicio cuáles son los servicios y el objetivo aquí es restaurar esas cosas lo antes posible, dada la importancia del servicio. Ahora sigo hablando de esto, pero en realidad es tan vital que lo tengamos en la cabeza y nos aseguremos de que cuando configure la herramienta, muchas de estas cosas tengan configuraciones predeterminadas. Solo échales un vistazo, revísalos, ve si se ajustan a tu organización no necesariamente los toma como un evangelio. Ok, lo que nos lleva al área completa de cómo los incidentes se relacionan con problemas y otras cosas, no solo existen por sí mismos. pero en realidad es tan vital que tengamos eso en la cabeza y nos aseguremos de que cuando configure la herramienta, muchas de estas cosas tengan la configuración predeterminada. Solo échales un vistazo, revísalos, ve si se ajustan a tu organización no necesariamente los toma como un evangelio. Ok, lo que nos lleva al área completa de cómo los incidentes se relacionan con problemas y otras cosas, no solo existen por sí mismos. pero en realidad es tan vital que tengamos eso en la cabeza y nos aseguremos de que cuando configure la herramienta, muchas de estas cosas tengan la configuración predeterminada. Solo échales un vistazo, revísalos, ve si se ajustan a tu organización no necesariamente los toma como un evangelio. Ok, lo que nos lleva al área completa de cómo los incidentes se relacionan con problemas y otras cosas, no solo existen por sí mismos.

  Incidente mayor - 29:37

  Diapositiva 20: Y aquí tenemos la idea de un incidente importante, pero ¿cuál es la diferencia entre un incidente importante y un incidente normal? Bueno, es muy difícil de evaluar, creo que esto dependerá de la organización y, a su vez, y en cierto sentido, será una cuestión de mirar el servicio, mirar lo que está afectado y llegar a una decisión crítica. Pero básicamente estas son cosas que están sucediendo interrupciones temporales o no planificadas en un servicio con graves consecuencias negativas. Aquí hay una idea, aquí arriba de un iceberg donde tiene la agradable porción visible y esponjosa de flotar sobre los caminos y debajo de ella la roca que se hunde del Titanic que está flotando debajo, que está absolutamente allí para hundir una organización.

  Por lo tanto, cuanto más tenga de un incidente, más probable será que tenga un problema importante en la ruta. Entonces, cuanto más tenga, más probable será que tenga uno, que es lo que esto está tratando de mostrar. Aquí, pero también en un incidente importante, los incidentes que se combinan para crear uno pueden ser muchos y variados y no necesariamente, obviamente, interrelacionados.

  Pueden estar entre cosas que están sucediendo o procesos, errores humanos, descuidos, atajos. Las cosas simplemente están sucediendo, podrían ser varias de estas cosas todas juntas. Pero a medida que entras en más y más de estas cosas y obtienes un enorme iceberg flotando, es cuando un incidente importante puede comenzar a juntarse casi como un tifón que se junta para luego arruinar la organización y ahí es donde debemos estar. muy claro y aquí es donde es absolutamente probable que una buena herramienta y un buen servicio de atención al cliente detecten las tendencias dispares. Ahora, algunas cosas son bastante sencillas si algo falla, si un servidor falla, se lleva una aplicación importante. va a hacer que la mesa de servicio se inunde con una serie de llamadas sobre lo mismo, eso es probablemente bastante,

  Pero tenga cuidado de pensar en la variedad de cosas que pueden estar debajo del agua y que no puede ver que podrían equipararse a un incidente importante y ahí es donde comenzamos a llevar la gestión de problemas y comenzamos a pensar en que tuve algunos de estos. cosas y pueden sentir intuitivamente es, esto indica que tenemos algo más sucediendo y aquí es donde los incidentes conducen a problemas y a todo un proceso de problemas y el punto en torno al proceso de problemas es que podemos tener acceso a un poco más de datos, entramos en las cosas con un poco más de rigor de lo que haríamos de otra manera.

• Gestión de problemas - 32:17

  Diapositiva 21: Entonces, desde el punto de vista del problema, está tratando de llegar a la causa probablemente desconocida de uno o más incidentes. Entonces, las actividades en las que alguien usaría cosas como el análisis de la causa raíz, buscar soluciones alternativas y la eliminación sistemática de la causa raíz eventualmente mediante solicitudes de cambio, es lo clave que estamos viendo, cuál es el problema subyacente y hay un proceso en ITIL, un proceso problemático que podemos usar para hacer eso.

  Entonces, lo que normalmente tenemos es una serie de incidentes que se juntan, ya sea que son del mismo tipo o, como acabo de sugerir, cosas que están vagamente conectadas y sugieren algo, algo mucho más fundamental que se une para usar y luego garantizar que resolvemos estas cosas correctamente.

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

  Diapositiva 22: Ahora, cuando identificamos la causa subyacente clave, obviamente podríamos y podríamos necesitar 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 pinchamos este sistema en particular de una manera particular, siempre responderá de una manera particular, se cae o recibimos un mensaje de error en particular. Entonces eso es algo que sabemos y podemos publicar, podemos comunicar ese tipo de cosas.

  Pero también cuando estamos analizando el proceso de incidentes 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 decirles a los usuarios sobre ellos, de modo que no tengamos que seguir dejando el teléfono y les decimos, pero también para que podamos identificarlos de manera muy sencilla y ver Qué esta pasando. Y luego, si es posible, dar a las personas una solución alternativa si existe una, y obviamente si no existe una solución alternativa, entonces eso es lo que se conoce en el sistema como una solución alternativa y podemos comenzar a usar eso para que las personas vuelvan a funcionar rápidamente si tiene uno de estos problemas conocidos flotando. Pero debe ser parte del proceso del incidente, tenemos algo que acaba de surgir y tenemos algo para resolverlo.

  Diapositiva 23: Está nuestro proceso de incidentes nuevamente mirando los errores conocidos y soluciones, 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 resolver nuestro proceso de incidentes. Tenemos la capacidad de utilizar el conocimiento y los incidentes juntos de dos formas particulares. Uno de ellos es el autoservicio, por lo que las personas ingresan para registrar una llamada porque tienen un problema o un problema que no entienden algo, existe todo el concepto de autoayuda en cosas como el autoservicio .

  Por lo tanto, entrar en la base de conocimientos es un documento de preguntas frecuentes y utilizar la ayuda basada en secuencias de comandos si está disponible en conjuntos de herramientas. Y lo que estamos tratando de hacer aquí es guiar al usuario a hacer las cosas por sí mismo para tratar de resolver su propio problema. Siguen siendo incidentes y todavía necesitamos registrar ese hecho, porque necesitamos entender con qué frecuencia estas cosas aparecen en la vida cotidiana, pero tenemos que asegurarnos de que entendemos cuáles son esas cosas. Para que podamos arreglarlos o hacer las cosas más fáciles. Entonces esa es la primera forma en que podemos usar el conocimiento.

  La segunda forma es darle la vuelta a todo el asunto y observar cómo los incidentes pueden generar conocimiento, así que lo que hay aquí es que tenemos eso y tenemos incidentes que deben introducirse en el sistema. Obviamente, contienen una descripción del problema que realmente ocurrió, ahora si hemos estado hablando sobre el hecho de hacer los datos correctamente, si nos hemos asegurado de que los datos se coloquen en un buen formato en primer lugar y tal vez tengamos a alguien que participe en las llamadas sobre los incidentes después y se asegure de que se hayan realizado correctamente.

  Luego, podemos usar eso y esos incidentes en esas descripciones dentro de la base de conocimientos como algo en lo que se debe buscar, para que en el futuro, podamos averiguar cuál es la resolución para ese incidente en particular y podemos publicarlo para que el usuario pueden ayudarse a sí mismos o es un recurso disponible para que la mesa de servicio vaya y luego resuelva sus propios problemas y vea si se ha solucionado en el pasado. Pero básicamente conocimiento, conformarse en ambos sentidos tratando de ayudar a las personas a medida que ingresan para un autoservicio o, de hecho, para 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,

• Incidencias en la mesa de servicio - 37:12

  Diapositiva 25:Y, por supuesto, cualquier conversación sobre incidentes no estaría terminada si no habláramos también sobre su aplicación dentro de la mesa de servicio. Para ser honesto, he hablado de ello todo el tiempo, la mesa de servicio es la elección, la mesa de servicio usa el proceso de gestión de incidentes, es casi como un sable de luz para protegerse y proteger a la organización que obviamente viene 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 asegurando 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 primero ve, Así que, en algunos casos, la mejor manera de hacerlo es resolverlo allí mismo en lugar de tener que pasarlo a otro grupo de expertos de segunda línea, tercera línea o 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 garantizados y el mantenimiento lo más rápido posible.

  Escalar a otros miembros del equipo si no conocemos la respuesta nosotros mismos, otros miembros del equipo, equipos que tienen diferente experiencia y, obviamente, comunicación entre esos grupos y de regreso al cliente. Y finalmente la mesa de servicio es la responsable y debe encargarse de contener y gestionar y cotejar, midiendo juntando todas esas métricas que produce la gestión de servicios, ¿cuántas teníamos ?, ¿cuántas de esta categoría en particular ?, cuántas para esta configuración artículo ?, ¿qué gravedad ?, ¿cuántos para este servicio? Y luego comenzamos a ver los datos que tenemos aquí para comenzar a resaltar dónde podemos mejorar el servicio y la versión 3 de ITIL incorporó todo este concepto de mejora continua del servicio. Quiero decir, como si fuera realmente honesto, como si fuera algo genial,

  La versión 3 de ITIL le puso un nombre que es la idea completa de mejora continua del servicio, pero se hace observando los datos que hemos estado capturando, analizando las tendencias que siguen lo mismo y viendo si podemos mejorar donde las cosas han estado rompiendo. Casi como una gestión de problemas en los datos de la propia mesa de servicio, pero obviamente la mesa de servicio tiene una función absolutamente vital y el interior y la paz una parte vital en su arsenal.

  Sepa cuándo parar - 39:55

  Diapositiva 26: Pero diría solo como una advertencia aquí y esto proviene de años y años de experiencia, lo que he visto con diferentes mesas de servicio, sé cuándo parar cuando se trata de mirar esos datos. Es posible y lo he visto a veces que la gente se toma más tiempo y esfuerzo en tratar de analizar hasta el último detalle, capturando hasta el último dato que a veces lleva más tiempo registrar una llamada de lo que debería hacer que empecemos 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 se ve afectado, no necesitamos pedirle a la persona el número de serie, la RAM o el resto, si estamos pensando en eso y eso es importante, entonces Debería empezar a pensar de dónde debería venir, tal vez de las bases de datos de gestión de activos configuracionales. Pero tenemos que empezar a ver qué información de gestión es adecuada para gestionar. El simple hecho de un informe de fin de mes que dice que hemos tenido y hemos cerrado 4.000 llamadas, 4.000 incidentes, es una gran estadística, pero ¿qué significa realmente? ¿Mejor que hayamos cerrado la única llamada que fue provocada por las empresas? sitios web para cerrar. Ese es el tipo de ellos, es la resolución del servicio lo que es importante, es la importancia de los datos que estamos presentando.

  Aquellos de ustedes que saben acerca de la administración de redes saben que tenemos estas cosas llamadas trampas SNMP, las cosas que los enrutadores y las computadoras y cosas como los servidores sacan el cuello cuando están teniendo una crisis. Ocasionalmente, los concentradores y conmutadores de red y las cosas pueden producir muchos miles principales de estas cosas. Ahora, simplemente decirle a la gente que hemos tenido 45.000 trampas es absolutamente irrelevante, excepto si una de ellas elimina el servicio clave que le está produciendo a la empresa una gran 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 obtuvieron buenas calificaciones de satisfacción del cliente si sus clientes externos o incluso clientes internos, mirando hechos clave,

  Entonces, en términos de algunos de esos indicadores clave de rendimiento que deberíamos considerar, nuevamente se trata de lo que es importante, por lo que es como si usted fuera Amazon, asegúrese de tener un 100% de tiempo en su web. Tienda. Si se trata de una planta de fabricación, asegúrese de que está produciendo dentro de cualquier tolerancia que le ocurra a sus máquinas, ya que sabe que sea lo que sea que sea 98, 100%, 50%. Lo que sea que sea tan importante para su organización, debe incluirse y luego medirse en función de ello.

  Y algunos de los indicadores clave de rendimiento que diría para la mesa de servicio son cosas como la satisfacción del cliente, porque eso realmente te dice cómo te está yendo. Debido a que el cliente no es el tipo que presta el servicio o lo hace por negocios, si está contento en general, significa que las cosas van bastante bien.

  El tiempo de resolución es obviamente muy importante y la resolución de incidentes clave, los incidentes clave son aquellas cosas que afectan a los servicios clave, por lo tanto, ¿qué tan rápido se resolvieron, qué tan rápido 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á logrando, entonces está bien, está en el objetivo, si comienza a vagar por encima de eso, entonces, obviamente, ahí es donde el cliente es si la empresa comienza a correr el riesgo de no poder hacer lo que tiene que hacer.

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

  Diapositiva 27: Y finalmente, ¿cómo se siente con respecto al 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 prestan muchos de esos servicios. La solicitud de servicio es la forma de acceder 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 un incidente? Bueno, muchas personas, algunas personas, presentan solicitudes de servicio como un incidente y, en realidad, no hay nada de malo en eso, el más puro podría quejarse un poco y decir que no debería hacerlo. Tengo una visión mucho más pragmática de que sea lo que sea que funcione para usted como organización. Desde un punto de vista purista, oh sí, es posible ordenar estas cosas, porque tienen formas definibles de hacer las cosas y es posible hacer las cosas de una manera particularmente diferente. Entonces, lo que necesitamos hacer es entender 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, abandono, solicitud de equipo, provisión de software y escaneo de virus. No hay una respuesta correcta si debería ser un incidente o un servicio, una solicitud de servicio, pero lo que estamos tratando de hacer aquí es asegurarnos de que tenemos el enfoque correcto para hacer las cosas de la manera correcta y en el momento adecuado y que los niveles de servicio se tomen 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 si se trata de un SLA, realmente depende completamente de usted, pero cualquiera que sea, asegúrese de que esas cosas estén definidas correctamente y comprenda qué es una solicitud de servicio, cómo las trata y luego se administra en consecuencia.

  Proceso de nueva contratación - 46:02

  Diapositiva 30: Algunas de esas cosas que tiene como incidentes o solicitudes de servicio diferentes procesan cosas 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 acompañan eso. Entonces, la tarea de recursos humanos de la contratación solicita el rango de cobertura de salud 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 encapsular dentro de los incidentes o dentro de una solicitud de servicio.

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

  Gestión de la configuración - 47:00

  Diapositiva 32: Y finalmente, obviamente, todo se reduce a la administración de la configuración, saber qué cosas brindan un servicio, los elementos de configuración, y eso se define por todas las relaciones que están contenidas en la base de datos de administració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, ¿por qué la gestión de incidentes tiene que ver con saber qué es importante, quién es el servicio más importante para 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 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 lucha contra incendios mucho mejor de una manera mucho más eficiente y efectiva posible, basándonos 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 de trabajo continuamente haciendo las cosas una y otra vez, lo mismo repetidamente. No seguimos cometiendo los mismos errores y permitiendo que el negocio entre en dificultades. Realmente estamos tratando de asegurarnos de 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. Así que, para terminar, el incidente la administración 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, más riesgo correrán las empresas frente a la competencia o perder dinero o lo que sea.

  Entonces, la gestión de incidentes funciona, 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 por la empresa lo que debe hacer para mantener esos servicios activos y en funcionamiento. Así que en esa nota voy a volver a pasar a Joseph por un pequeño fragmento de ManageEngine.

  Hora de preguntas y respuestas: 52:10

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

  Neil:Bueno, quiero ser honesto, el servicio que se está brindando es un servicio comercial. Por tanto, es el servicio que necesita la empresa. Entonces, en ese caso, diría que realmente debería ser el negocio el que esté en el asiento del conductor. Pero obviamente tiene que ser TI el que realmente pueda poner algo de sentido común al respecto, no tiene sentido que el negocio grite y golpee la mesa con el puño y golpee y diga, no, no, tenemos que tener un arreglar en 10 minutos. Ya sabes, es poco realista, tenemos que poner sobre la mesa la realidad de TI y qué problemas de TI o cuánto tiempo pueden tardar los problemas de TI en resolverse. Así que tenemos que ser realistas y también tenemos que traer alternativas, así que a veces también necesitamos traer a la mesa, bueno, van a ser dos semanas pero lo sabemos ''. No va a 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 priorización, su importancia del negocio.

  Joseph: OK, gracias Neil, ok, una pregunta más antes de entrar en el resumen del producto de 10 minutos sobre nuestro ServiceDesk Plus. La última pregunta para Neil sería, normalmente resolvemos 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 de las que se trata ITIL, es la mejor práctica 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 tenido noticias de ellos en tres días, quiero decir que parece una forma muy razonable de trabajar y hay otras formas de hacerlo, podríamos decir si no hemos tenido noticias tuyas. o lo cerraremos a menos que tengamos noticias suyas. Pero creo que tiene que haber alguna 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 ha recibido respuesta, sí, continúe y ciérrelo en tres días. YO'

  Joseph: ¡ Bien, gracias Neil! Ahora tenemos a Bhaskar con nosotros, es un consultor de productos y nos guiará 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 solicitud, uno es un correo electrónico donde puede configurar una dirección de correo electrónico para su soporte y cualquier persona 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, la otra forma es una llamada telefónica donde un usuario final llama al agente de soporte, quien a su vez presentará una solicitud utilizando este formulario.

  Creando incidente 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 ingresan aquí para presentar una solicitud, pueden buscar una base de conocimientos, una búsqueda en la base de conocimientos, si encuentran la solución, realmente pueden solucionar su propio problema en caso de que no lo hagan, pueden ir adelante y presentar una nueva incidencia. 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 boletos y recogerlos.

  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 del directorio activo, por lo que los detalles de estos usuarios se completarán automáticamente y también se mostrarán los activos que pertenecen al usuario. aquí. Con esto, estaremos evitando preguntas no deseadas pidiendo a la solicitud cuál es el activo que está usando 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 según el impacto y la urgencia del negocio. Esta es también una de las mejores prácticas de ITIL y también le hemos dado la flexibilidad para modificar el negocio, ya sabe, la urgencia y 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ía, una subcategoría y un elemento mediante el cual se puede categorizar de forma granular un tipo de incidente. Por lo tanto, una categorización de incidentes es muy importante, ya que le ayuda a comprender el origen de todos los incidentes. A continuación, puede elegir el grupo y el técnico y presentar una solicitud.

  Automatización de reglas comerciales

  Vamos a analizar las reglas comerciales, todos estos parámetros como categoría, subcategoría, el grupo y el técnico que se pueden configurar automáticamente con la ayuda de una regla comercial. La automatización de reglas de negocio y ServiceDesk Plus ayudan a organizar las solicitudes entrantes y realizar cualquier acción, desde categorizar un incidente, entregarlas a un grupo y asignarlas a un técnico. Así que 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 de todos los tickets de alta prioridad. Y también tenemos la opción de 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 qué ticket se le está asignando.

  Configurar plantillas para problemas frecuentes

  Y ahora vamos a ver las plantillas disponibles que se pueden configurar en la sección de administración. Los problemas o incidentes que ocurren con frecuencia, como el correo electrónico o el problema de la impresora, se pueden configurar como plantillas. Con todos estos parámetros rellenados previamente, lo que facilita el registro de incidentes, por lo que puede rellenar previamente estos campos. Digamos, por ejemplo, que si se trata de una plantilla de problemas de impresora, puede configurar estos valores y guardarlos como plantilla. Entonces, cuando un técnico desea crear una solicitud para un problema de impresora, puede ingresar al botón de nuevo incidente y seleccionar la plantilla de problema de impresora. Esto completará automáticamente esa información de campo.

  Agradecimientos

  Y a continuación, veremos cómo se envían los reconocimientos a sus usuarios finales. Entonces, una vez que creo un ticket con un nombre de 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 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 una fecha límite para una solicitud en particular. Entonces, aquí puede ver la fecha de creación, la fecha de vencimiento por hora y la respuesta a la fecha de vencimiento por hora. 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 admin> acuerdo de nivel de servicio.

• Respuesta al incidente

  Entonces, para una solicitud después de un período de tiempo establecido, si la solicitud no es atendida por un agente de la mesa de servicio, enviará un correo electrónico de escalamiento automático a otro técnico que la mesa de servicio, usted sabe que el incidente fue violado. Entonces puede configurar el nivel de respuesta SLA y el SLA de resolución aquí. Para esto, he establecido una prioridad alta para un problema de obtención de correo, el nivel de respuesta debe ser dentro de una hora, la primera respuesta y una resolución dentro de las ocho horas. También puede habilitar la escalada, de modo que la otra tecnología reciba una notificación cuando se escale este SLA. Entonces, una vez que se crea un ticket con un SLA, un técnico busca la resolución de errores para este ticket en particular.

  Buscando una solución / base de conocimientos

  En ServiceDesk Plus, le hemos brindado la conveniencia de buscar una solución en un ticket en particular basado en su conocimiento, el tema de una búsqueda de resolución de servicio de correo electrónico en particular. Entonces, aquí obtiene la lista de soluciones disponibles en la base de conocimientos, puede seleccionar la solución y copiarla en el incidente real. Y una vez que se copia, puede hacer uso del estado que se cambiará aquí para resolverlo y, como técnico, también puedo agregar el registro de trabajo de cuánto tiempo he estado trabajando en este ticket en particular, el tiempo dedicado y la resolución de problemas. que he pasado por este incidente en particular.

  Solicitar reglas de cierre / Automatizar el cierre

  Por lo tanto, un incidente debe cerrarse solo si el usuario final confirma que la resolución que he proporcionado es válida. Para esto, tenemos un parámetro en admin> reglas de cierre de solicitudes, así que aquí es donde vamos a definir los campos obligatorios que deben completarse antes de cerrar una solicitud en particular y esto es de lo que estaba hablando, reconocimiento de un usuario final y también Neil estaba hablando sobre el cierre de automatización de un ticket en particular, aquí puede configurar una vez que un ticket se mueve a un estado de resolución, puede configurar un cierre de automatización donde puede especificar el número de días, tres días después de los cuales un un ticket en particular se cierra automáticamente. Esta es también una de las mejores prácticas importantes de ITIL en las que el técnico no tiene que hacer un seguimiento constante de la respuesta del usuario final.

  Encuesta de usuarios

  Y a continuación, analizaremos la satisfacción del usuario final. Tenemos una opción en admin> configuración de la encuesta, también hubo una pregunta de uno de nuestros asistentes, ¿cuál es el método que utiliza para evaluar la satisfacción del cliente? Entonces, para eso, tenemos una opción para habilitar la encuesta que se puede habilitar para cada ticket creado en Service Desk que se haya cerrado. Este nivel de satisfacción puede ser conocido, los resultados de la encuesta se mostrarán debajo del resultado de la encuesta y los comentarios adicionales también se enumerarán a continuación.

  Módulo de informes

  Y yendo al módulo de informes de cómo se puede evaluar mejor la gestión de incidentes aquí, ha predefinido más de 100 informes predefinidos que puede generar en función de la violación del SLA, el número de tickets entrantes por día y los tickets pendientes para cada grupo de técnicos y lista de tickets con alta prioridad, puede tomar un informe en la sección de informes y tiene la opción de hacer sus propios informes personalizados para todas las solicitudes y elegir el tipo de campos que necesita. Por lo tanto, mediante esta gestión de incidentes funcionará mejor con ServiceDesk Plus.

  Así que también analizaré otra pregunta que envió un usuario final. Actualmente estamos usando la versión ServiceDesk Plus en nuestro departamento de TI, nos gustaría expandir el sistema al departamento de recursos humanos, finanzas y otros también para que los usuarios ingresen una solicitud de servicio, ¿cómo podemos hacer esto?

  En ServiceDesk Plus, la versión Enterprise tiene la función de Catálogo de servicios mediante la cual, puede agregar una categoría de servicio, por lo que estas son categorías de servicio predefinidas que están disponibles y agregar un servicio a una categoría de servicio le permitirá elegir la lista de sus usuarios a quien desea mostrar estos servicios. Por tanto, los grupos de usuarios se pueden configurar en admin> grupos de usuarios. Y tienes un criterio que puedes elegir aquí, entonces el título del trabajo es ... para que puedas seleccionar, puedes configurar un filtro con el cual te mostrará la lista de usuarios que pertenecen al departamento de TI y una vez que se solicita un servicio configurado, puede mostrar esto solo al departamento de TI por el cual los otros grupos de usuarios no tendrán acceso a este servicio.

  Así que con esto concluimos la sesión sobre la mejor manera de utilizar la gestión de incidentes en ServiceDesk Plus. Gracias a todos por asistir.