Diferencia entre revisiones de «Procedimiento de Gestión de Incidencias»

De Última Milla Wiki
Saltar a: navegación, buscar
 
 
(No se muestran 15 ediciones intermedias de 2 usuarios)
Línea 1: Línea 1:
 
=OBJETIVO=
 
=OBJETIVO=
−
La '''Gestión de Incidentes''' tiene como objetivo restablecer el funcionamiento normal de servicio lo más rápido posible y minimizar el impacto adverso en las operaciones del negocio, lo que garantiza que se mantengan los mejores niveles posibles de calidad de servicio y disponibilidad.  
+
La '''Gestión de Incidencias''' tiene como objetivo restablecer el funcionamiento normal de servicio lo más rápido posible y minimizar el impacto adverso en las operaciones del negocio, lo que garantiza que se mantengan los mejores niveles posibles de calidad de servicio y disponibilidad.  
  
 
=ALCANCE=
 
=ALCANCE=
Línea 6: Línea 6:
 
La empresa cuenta con un software propio para la Gestión de Incidencias, que se encuentra asociada al SGI, lo cual permite la resolución de los Tickets brindando los estándares básicos para que el servicio funcione correctamente. Las funcionalidad básicas son las siguientes:
 
La empresa cuenta con un software propio para la Gestión de Incidencias, que se encuentra asociada al SGI, lo cual permite la resolución de los Tickets brindando los estándares básicos para que el servicio funcione correctamente. Las funcionalidad básicas son las siguientes:
  
−
*SGT: plataforma web para el cliente donde cargará las incidencias. También tendrá información mínima de los niveles de servicios según el proyecto que tenga habilitado (url:[http://ticket.ultimamilla.com.ar http://ticket.ultimamilla.com.ar]
+
*SGT: plataforma web para el cliente donde cargará las incidencias. También tendrá información mínima de los niveles de servicios según el proyecto que tenga habilitado (url:[http://ticket.ultimamilla.com.ar http://ticket.ultimamilla.com.ar]. Actualmente presenta un nombre comercial denominado '''UMA'''.
  
 
*SGI: internamente el software tendrá 2 interfaces:
 
*SGI: internamente el software tendrá 2 interfaces:
Línea 12: Línea 12:
 
   - Tickets: módulo personal donde cada operario visualizará y gestionará los tickets que tiene asignado.
 
   - Tickets: módulo personal donde cada operario visualizará y gestionará los tickets que tiene asignado.
  
−
 
−
La determinación de significante del item de configuración se definirá en el acuerdo de nivel de servicios (SLA) con el cliente.
 
−
 
−
Los ítems deben ser administrados, versionados y deben mantener una trazabilidad durante todo su ciclo de vida.
 
−
 
−
Los ítem deben estar identificados y nomenclados mediante un método, en consecuencia debe existir una regla para su identificación univoca en todos los procesos o proyectos. También es necesario identificar y diferenciar las diferentes versiones a lo largo de todo el proceso. Este versionado debe ser fácil de identificar para esto se recomienda usar elementos como números o fechas en el caso de los artefactos cuya evolución este fuertemente ligado al momento en el que se genera.
 
−
La elección del ítem de configuración es una parte importante de la Gestión de la configuración. Es recomendable tomar un criterio de agrupación por funcionalidad.
 
  
 
=ROLES Y RESPONSABILIDADES=
 
=ROLES Y RESPONSABILIDADES=
  
−
Los siguientes roles están vinculados a las actividades de gestión del plan:
+
Los siguientes roles están vinculados a las actividades de gestión del tickets:
−
 
+
{| class="wikitable"
−
Rol Responsabilidades
+
!Roles || Actividades
−
Gestor de la configuración Identifica, aprueba y controla la actualización de los elementos de configuración, gestiona el acceso a la información de toda la organización, se encarga de las auditorías de la configuración.
+
|-
−
 
+
|Cliente Admin
−
=PLAN DE GESTIÓN DE LA CONFIGURACIÓN=
+
|Usuario de SGT que el cliente obtiene vía mail. Tiene privilegios especiales que lo hacen Administrador
−
==Identificación de los IC y Herramientas==
+
|-
−
 
+
|Cliente Operario
−
Las siguientes herramientas permiten la identificación de los IC comprendidos en el alcance:
+
|Usuario de SGT que el cliente obtiene vía mail.
−
 
+
|-
−
Cómo la herramienta permite la gestión de los IC? Cómo se organiza la herramienta para cada servicio?
+
|Admin SGI
−
 
+
|Operario Interno del SGI encargado de Administrar los Tickets que cargan los clientes.
−
===Herramienta===
+
|-
−
El Proceso de Gestión de Configuración será administrado por medio de SIGUM.
+
|Operario SGI
−
 
+
|Usuario de SGI encargado de la resolución de los Tickets.
−
*Estructura (Maestro, organización por jerarquías siendo el segundo nivel IC)
+
|}
−
*Nomenclatura
 
−
*Descripción del IC
 
−
*Relaciones entre el IC y otros IC: los IC son opcionales
 
−
*Relaciones entre el IC y los componentes del servicio: los IC son opcionales
 
−
*Versión: definición, qué la compone?
 
−
*Línea Base: definición, qué la compone?, los IC son mandatorios
 
−
*Estado
 
−
*Ubicación
 
−
 
 
−
==Control de los IC==
 
−
 
 
−
===Creación de nuevos IC===
 
  
−
Se especificará el procedimiento genérico que indique de qué manera los ítems de configuración serán creados, revisados y referenciados en la organización.
+
=ACTIVIDADES CLAVES=
  
−
Pasos:
+
==Detección de las Incidencias y registración==
−
• Aceptar la entrega del nuevo IC de parte de un miembro autorizado de operaciones. El mismo deberá detallar el tipo de IC y a qué servicio impactará.
+
El sistema permite la carga de incidencias a través de la plataforma web SGT. Para cargar un Ticket, el cliente deberá completar una serie de atributos (prioridad, tipo de incidencia, etc.), asociados al SLA del Servicio y acorde a los niveles establecidos.
−
• Asignar un identificador al IC según Nomenclatura de los Ítems de Configuración.
+
Finalizada la carga, se notificará vía mail al responsable del Servicio y el Administrador de Tickets visualizará una nueva incidencia en el SGI.
−
• Ubicar físicamente / lógicamente el nuevo IC en el repositorio que corresponda (teniendo en cuenta el tipo de versionado del repositorio).
 
−
• Disponibilizar y notificar al Grupo Operaciones del nuevo IC.
 
  
−
===Actualización de IC===
+
==Clasificación y Soporte Inicial==
 +
La incidencia tiene una pre-clasificación a cargo del cliente. Luego, el Administrador de Tickets, tiene la potestad de re-clasificarlo en caso de que sea necesario.
 +
El SGT permitirá visualizar una Base de "Errores Conocidos", que se alimentará de resoluciones de Tickets anteriores, ésto permitirá al cliente y/o personal, resolver el problema en menor tiempo, además analizar si es necesario aplicar un "cambio" en el módulo específico.
 +
Una vez que el Ticket esté clasificado y sea analizado por el Administrador, éste será el encargado de derivarlo a un personal para su futura resolución, será notificado vía mail y también tendrá un nuevo registro en su bandeja de Tickets.
 +
El encargado de resolver la Incidencia da inicio al Ticket, ésta acción será registrada en la Bitácora del Ticket y ademas notificada al Cliente para que conozca el estado en que se encuentra su problema. El operario, podrá establecer una comunicación con el cliente (de ser necesario) para despejar dudas. En caso de poder dar solución, se cierra el Ticket. Si al evaluar la situación, se observa que requiere otro tipo de tratamiento, se podrá '''escalar''' la incidencia a un nivel superior.
  
 +
Cada Servicio tiene asociado un Contrato SLA con sus respectivos Niveles, Tiempos de Respuesta o Niveles de Complejidad. Tanto el Cliente como el Personal, podrá en todo momento, consultar esos parámetros de Tiempo/Complejidad para evaluar el servicio.
  
−
==Registro, Control y Seguimiento del Versionado==
+
==Investigación y Diagnóstico==
−
Dependiendo de la herramienta que se utilice, el versionado se realizará diferente. A continuación se detalla en forma genérica los pasos necesarios para la herramienta:
+
Por cada incidencia, se deberá realizar un análisis cruzando los datos de la Bitácora, DB de errores conocidos, categoría del ticket y prioridad. También el operario deberá contemplar el SLA acordado, para conocer:
 +
* Tiempos de Respuesta: es el tiempo que tendrá el operario en comunicarse con el cliente para ofrecerle un feedback sobre la incidencia.
 +
* Disponibilidad de Mesa de Ayuda: información sobre los horarios donde se brindará el servicio.
 +
* Tiempo de Resolución: es el tiempo en cuál se deberá resolver el ticket o realizar una escala a un nivel superior.
 +
* Tiempo de Validación: es el tiempo que tendrá el cliente en poder confirmar si el ticket ha sido resuelto satisfactoriamente. En caso de extenderse, automáticamente se dará por cerrado el ticket.
 +
* Complejidad: se utiliza en los casos donde no sea necesario evaluar tiempos, sino nivel de esfuerzo o dificultad.
  
−
===SIGUM===
+
==Resolución y Recuperación==
−
El Software permite registrar cualquier tipo de modificación que se realice sobre un Ítem de Configuración o Línea Base. Se guardan los datos de cada atributo y quién fue el encargado de realizar tal modificación.
+
En cualquier Nivel se deberá resolver el incidente con una solución definitiva o temporal, en su defecto, se podrá elevar un requerimiento de cambio (incluyendo una verificación de la resolución).
−
Las versiones anteriores, no pueden ser eliminadas o modificadas, ya que su función es brindar la información del momento en que se utilizaron, solamente tendrán una baja "lógica" dejando como activa la última versión.
+
Existen casos de Recuperación, donde el cliente podrá realizar la re-apertura de un ticket en caso de ser necesario.
−
En el detalle de cada Ítem, se podrá visualizar el histórico de versiones.
 
  
−
===Alfresco===
+
==Cierre de Incidencias==
−
• Se hace un Check-out del/los ICs al área de trabajo, lo que hace que el/los ICs permanezca bloqueado para cualquier otra modificación.
+
Finalizada la resolución de la incidencias, el cliente deberá confirmar si fue exitoso su desarrollo, ya sea vía mail, teléfono o a través de la misma Bitácora del Ticket. De ésta forma, habilita al operario a cambiar el estado y cerrar la incidencia. Luego si el Ticket lo amerita, se podrá anexar a la DB de Errores Conocidos. Además, el cliente podrá "calificar" el servicio del operario a través del Sistema.
−
• Proceder a realizar los cambios necesarios y verificar que se hayan realizado correctamente
 
−
• Realizar una operación de Check-in, para generar una nueva revisión del IC en el repositorio, y dejarlo disponible a los demás miembros de la organización.
 
−
===Open Project===
 
−
===Wiki===
 
−
==Auditorías==
 
−
Para controlar la consistencia de los IC se realizarán auditorías:
 
−
• Alcance:
 
−
• Periodicidad:
 
−
• Rol y responsabilidades:
 
−
• Template de ckeclist de auditoria:
 
−
• Informes:
 
−
• Gestión de hallazgos:
 
  
−
=DOCUMENTOS RELACIONADOS=
+
=INCIDENCIA/TICKET=
−
• IRAM-ISO 20000:2011.
+
La incidencia se encuentra vinculada con los Servicios que se le brindaron al Cliente, junto con el SLA que acordaron. Ésto permite a la Gestión Interna la carga de horas en cada Ticket y la posibilidad de evaluar el Nivel de Satisfacción del Cliente según las calificaciones realizadas.
−
=DEFINICIONES=
+
Cada Ticket pertenece a una Tarea del EDT, lo cual, facilita la Gestión Contable a la hora de Consultar los Informes (Horas y de Estados de Resultados).
  
−
• Línea de base de la configuración: información de la configuración formalmente establecida en un momento específico de la vida de un servicio o un componente de un servicio.
+
==Errores Conocidos==
−
NOTA 1. Las líneas de base de la configuración, además de los cambios aprobados a partir de esas, constituyen la información de configuración actual.
+
En la plataforma de Tickets (UMA) hay un apartado para la visualización de "Errores Conocidos" para que el Cliente pueda tener un registro previo de todos los Errores en los cuales no sea necesario la creación de un Ticket nuevo.
−
NOTA 2. Adaptada de la ISO/IEC/IEEE 24765:2010.
 
−
Es la configuración (versiones) de los ítems de configuración componen un servicio en un momento determinad. Es una “foto” del estado y versiones de todos los CI que componen un servicio. Considera todos los detalles necesarios para que el servicio pueda restaurarse en caso de necesidad.
 
−
• Gestión de la Configuración: disciplina que se encarga de identificar y documentar ítems de configuración; almacenar, reportar, controlar y verificar la integridad de los cambios con respecto a los requerimientos especificados.
 
−
• Control de Cambios: proceso formal para realizar cambios sobre ítems de configuración.
 
−
• Control de la Configuración: parte de la gestión de la Configuración que consiste en la evaluación, coordinación, aprobación, e implementación de cambios sobre ítems de configuración.
 
−
• Ítem de configuración (IC): elemento que necesita ser controlado para la prestación de uno o más servicios. Es todo componente necesario para la prestación del servicio. Como ejemplo se citan los siguientes:
 
−
o Hardware: servidores, almacenamiento externo, PC, impresoras, equipos de comunicaciones, etc.
 
−
o Software: sistemas operativos, productos software, todo tipo de aplicaciones, scripts, parametrizaciones de productos, etc.
 
−
o Documentación: manuales, acuerdos de niveles de servicio, contratos de soporte, etc.
 
−
o Personas que intervienen en la prestación del servicio.
 
−
o Localizaciones: edificios, oficinas, etc.
 
−
o Servicios que presta TI.
 

Revisión actual del 18:09 6 may 2019

OBJETIVO

La Gestión de Incidencias tiene como objetivo restablecer el funcionamiento normal de servicio lo más rápido posible y minimizar el impacto adverso en las operaciones del negocio, lo que garantiza que se mantengan los mejores niveles posibles de calidad de servicio y disponibilidad.

ALCANCE

La empresa cuenta con un software propio para la Gestión de Incidencias, que se encuentra asociada al SGI, lo cual permite la resolución de los Tickets brindando los estándares básicos para que el servicio funcione correctamente. Las funcionalidad básicas son las siguientes:

  • SGT: plataforma web para el cliente donde cargará las incidencias. También tendrá información mínima de los niveles de servicios según el proyecto que tenga habilitado (url:http://ticket.ultimamilla.com.ar. Actualmente presenta un nombre comercial denominado UMA.
  • SGI: internamente el software tendrá 2 interfaces:
  - Administrador de Tickets: donde el operario podrá re-clasificar la incidencia, derivar a un operario específico, escalar el nivel y realizar un seguimiento.
  - Tickets: módulo personal donde cada operario visualizará y gestionará los tickets que tiene asignado.


ROLES Y RESPONSABILIDADES

Los siguientes roles están vinculados a las actividades de gestión del tickets:

Roles Actividades
Cliente Admin Usuario de SGT que el cliente obtiene vía mail. Tiene privilegios especiales que lo hacen Administrador
Cliente Operario Usuario de SGT que el cliente obtiene vía mail.
Admin SGI Operario Interno del SGI encargado de Administrar los Tickets que cargan los clientes.
Operario SGI Usuario de SGI encargado de la resolución de los Tickets.

ACTIVIDADES CLAVES

Detección de las Incidencias y registración

El sistema permite la carga de incidencias a través de la plataforma web SGT. Para cargar un Ticket, el cliente deberá completar una serie de atributos (prioridad, tipo de incidencia, etc.), asociados al SLA del Servicio y acorde a los niveles establecidos. Finalizada la carga, se notificará vía mail al responsable del Servicio y el Administrador de Tickets visualizará una nueva incidencia en el SGI.

Clasificación y Soporte Inicial

La incidencia tiene una pre-clasificación a cargo del cliente. Luego, el Administrador de Tickets, tiene la potestad de re-clasificarlo en caso de que sea necesario. El SGT permitirá visualizar una Base de "Errores Conocidos", que se alimentará de resoluciones de Tickets anteriores, ésto permitirá al cliente y/o personal, resolver el problema en menor tiempo, además analizar si es necesario aplicar un "cambio" en el módulo específico. Una vez que el Ticket esté clasificado y sea analizado por el Administrador, éste será el encargado de derivarlo a un personal para su futura resolución, será notificado vía mail y también tendrá un nuevo registro en su bandeja de Tickets. El encargado de resolver la Incidencia da inicio al Ticket, ésta acción será registrada en la Bitácora del Ticket y ademas notificada al Cliente para que conozca el estado en que se encuentra su problema. El operario, podrá establecer una comunicación con el cliente (de ser necesario) para despejar dudas. En caso de poder dar solución, se cierra el Ticket. Si al evaluar la situación, se observa que requiere otro tipo de tratamiento, se podrá escalar la incidencia a un nivel superior.

Cada Servicio tiene asociado un Contrato SLA con sus respectivos Niveles, Tiempos de Respuesta o Niveles de Complejidad. Tanto el Cliente como el Personal, podrá en todo momento, consultar esos parámetros de Tiempo/Complejidad para evaluar el servicio.

Investigación y Diagnóstico

Por cada incidencia, se deberá realizar un análisis cruzando los datos de la Bitácora, DB de errores conocidos, categoría del ticket y prioridad. También el operario deberá contemplar el SLA acordado, para conocer:

  • Tiempos de Respuesta: es el tiempo que tendrá el operario en comunicarse con el cliente para ofrecerle un feedback sobre la incidencia.
  • Disponibilidad de Mesa de Ayuda: información sobre los horarios donde se brindará el servicio.
  • Tiempo de Resolución: es el tiempo en cuál se deberá resolver el ticket o realizar una escala a un nivel superior.
  • Tiempo de Validación: es el tiempo que tendrá el cliente en poder confirmar si el ticket ha sido resuelto satisfactoriamente. En caso de extenderse, automáticamente se dará por cerrado el ticket.
  • Complejidad: se utiliza en los casos donde no sea necesario evaluar tiempos, sino nivel de esfuerzo o dificultad.

Resolución y Recuperación

En cualquier Nivel se deberá resolver el incidente con una solución definitiva o temporal, en su defecto, se podrá elevar un requerimiento de cambio (incluyendo una verificación de la resolución). Existen casos de Recuperación, donde el cliente podrá realizar la re-apertura de un ticket en caso de ser necesario.

Cierre de Incidencias

Finalizada la resolución de la incidencias, el cliente deberá confirmar si fue exitoso su desarrollo, ya sea vía mail, teléfono o a través de la misma Bitácora del Ticket. De ésta forma, habilita al operario a cambiar el estado y cerrar la incidencia. Luego si el Ticket lo amerita, se podrá anexar a la DB de Errores Conocidos. Además, el cliente podrá "calificar" el servicio del operario a través del Sistema.

INCIDENCIA/TICKET

La incidencia se encuentra vinculada con los Servicios que se le brindaron al Cliente, junto con el SLA que acordaron. Ésto permite a la Gestión Interna la carga de horas en cada Ticket y la posibilidad de evaluar el Nivel de Satisfacción del Cliente según las calificaciones realizadas. Cada Ticket pertenece a una Tarea del EDT, lo cual, facilita la Gestión Contable a la hora de Consultar los Informes (Horas y de Estados de Resultados).

Errores Conocidos

En la plataforma de Tickets (UMA) hay un apartado para la visualización de "Errores Conocidos" para que el Cliente pueda tener un registro previo de todos los Errores en los cuales no sea necesario la creación de un Ticket nuevo.

Obtenido de «https://wiki.ultimamilla.com.ar/index.php?title=Procedimiento_de_Gestión_de_Incidencias&oldid=1838»