Guías Técnicas de Interoperabilidad. Anexo G16-A02. Políticas de Mesa de Servicio. Fecha: 03 de febrero de 2016

Transcripción

1 Guías Técnicas de Interoperabilidad Anexo G16-A02 Políticas de Mesa de Servicio Fecha: 03 de febrero de 2016

2 HOJA 2 DE 7 Contenido 1. Objetivo Categorización y priorización de incidentes Severidades Severidad Severidad Severidad Severidad Herramientas de registro y seguimiento de incidentes Base de datos histórica de incidentes (Base de conocimiento) Acceso a Reportes, Estadísticas y Métricas Monitoreo de servicios Interfaz amigable para el usuario Basado en las mejores prácticas de la industria (ITIL/COBIT) Situaciones excepcionales... 7

3 HOJA 3 DE 7 1. Objetivo Definir el proceso para las actividades de soporte en producción las cuales van a suceder cuando se despliegue el o los trámites. Considerando las siguientes actividades: Herramientas para dar seguimiento a problemas e incidentes de la plataforma de GOB.MX Atención de incidentes y problemas. 2. Categorización y priorización de incidentes Las actividades se definen dependiendo del nivel de incidente producido, los cuales se basan en criterios para indicar su nivel de severidad, se define también el tiempo y la escalación que se debe seguir Severidades Las incidencias deberán ser tratadas en base a su nivel de criticidad y serán catalogadas en 4 severidades Severidad 1 Caída completa de un servicio / Aplicación crítica, se considera una falla con severidad crítica cuando: Impide la operación total de una aplicación que soporta una función de negocio. Se está excediendo más de lo esperado el tiempo de recuperación. Forma parte de la lista de Aplicaciones críticas. Deberá notificarse inmediatamente al inicio de detección de incidente, posteriormente comunicar actualizaciones cada 30 minutos hasta la solución del incidente, tal como se indica en el siguiente cuadro: Severidad 1 1 Nivel 2 Nivel 3 Nivel

4 HOJA 4 DE min min min Severidad 2 Degradación o falta parcial de un servicio indispensable. Se considera un incidente con severidad 2 cuando: Es una falla a los sistemas que afecta una sola área, pero existe una forma alterna de operar. Un incidente con severidad alta deberá ser notificado al inicio de la falla y posteriormente comunicar actualizaciones cada 4 horas hasta la solución del incidente, tal como se indica en el siguiente cuadro: Severidad 2 1 Nivel 2 Nivel 3 Nivel 0-4 hrs. 4-8 hrs hrs Severidad 3 Degradación Parcial de un servicio, se cuenta con un método alterno para operar y/o se tiene un Workaround definido. Se considera un incidente con severidad 3 cuando: Hay una falla en los sistemas que afecta a un grupo de usuarios reducido, pero existe una forma alterna de operar. Hay un solo usuario donde reporta una falla individual pero el aplicativo es de los considerados importantes para el negocio. Se notificará al inicio de la falla y posteriormente se deberá actualizar estatus de fallo cada 24 horas. Severidad 3 1 Nivel 2 Nivel 3 Nivel

5 HOJA 5 DE hrs hrs hrs Severidad 4 Solicitudes de los usuarios. Falla en un servicio que no represente un riesgo para el negocio. Se considera una falla con severidad 4 cuando: El proceso tiene un bajo impacto en la operación del negocio, su atención y solución puede ser calendarizada. Existen alternativas de trabajo. Se notificará al inicio de la falla y posteriormente actualizar estatus cada 240 minutos durante todo el seguimiento del fallo. Severidad 4 1 Nivel 2 Nivel 3 Nivel 0-48 hrs hrs hrs. 3. Herramientas de registro y seguimiento de incidentes. Las dependencias y entidades serán responsables de que la información o datos contenidos en sus sistemas o aplicaciones para la prestación de servicios digitales cuenten y cumplan con un nivel de servicio comprometido entre ellas y, en su caso, con los usuarios. En lo que respecta a dar respuesta a incidentes técnicos o solicitudes de servicio, la base de cualquier sistema de Mesa de Servicios debe ser el manejo eficiente y registro de requerimientos o incidentes a través de tickets Base de datos histórica de incidentes (Base de conocimiento).

6 HOJA 6 DE 7 En base al acuerdo sobre el Esquema de Interoperabilidad y de Datos Abiertos de la Administración Pública Federal, para alcanzar la Interoperabilidad Organizacional deberán fomentar la colaboración y participación con otras dependencias y entidades para facilitar la gestión del conocimiento. Las dependencias y entidades compartirán información y conocimiento para la prestación de servicios digitales integrados, así como para la adecuada toma de decisiones contando con una base de conocimientos que sirva al equipo de Mesa de Servicios obtener de manera práctica y ágil la información relacionada en base a escenarios pasados obteniendo un impacto significativo en el tiempo de resolución y reducción de carga de trabajo Acceso a Reportes, Estadísticas y Métricas. El software de Mesa de Servicios debería permitir el análisis y evaluación de las respuestas, tratamientos de todos los incidentes reportados. Por medio de lo que muestran los gráficos y estadísticas, se podrá medir la retroalimentación del cliente, evaluar el desempeño y rendimiento del equipo especializado y gerentes Monitoreo de servicios. El monitoreo consiste en el seguimiento periódico de las actividades sobre la gestión del servicio, busca hacer correcciones y ajustes a tiempo, utiliza indicadores de insumo, proceso y producto principalmente, y se realiza sobre la base de la Matriz de monitoreo y evaluación definida específicamente. Los avances obtenidos del monitoreo, van a permitir comparar las actividades y metas programadas versus las ejecutadas a la fecha de corte, con el fin de analizar el grado de cumplimiento de los objetivos planteados y realizar los ajustes correspondientes de ser el caso. El monitoreo puede conducir a la reformulación de actividades/proyectos y tareas e, incluso, al cambio en las prioridades, lineamientos u objetivos de la operación Interfaz amigable para el usuario.

7 HOJA 7 DE 7 La herramienta de la Mesa de Servicios deberá ofrecer una interfaz amigable para el usuario, también beneficiará a la Institución al liberarlos de un proceso de implementación complejo Basado en las mejores prácticas de la industria (ITIL/COBIT). El software de Mesa de Servicios deberá coincidir con las necesidades de la Institución, adoptar el software basado en ITIL o una estructura similar. 4. Situaciones excepcionales Todos los tickets que se apertura como Severidad 1 requieren al finalizar un reporte especial de Incidente Mayor (Post Mortem). Todos los equipos involucrados deben estar reunidos en algún meeting room (audio de conferencia) para la rápida recuperación del servicio. Todos los incidentes con una Severidad 2 se consideran con impacto a la operación por lo cual se debe dar el mismo tratamiento que un incidente con severidad 1, y se deberá involucrar desde un inicio a los soportes especializados, líderes técnicos y responsables sea el caso. Se deberá contar con un listado Top que incluya los elementos más críticos correspondientes a Hardware y Software para la consideración y aplicación de criterios que propone esta guía. Si al final de la incidencia no se cuenta con la causa raíz se deberá iniciar con el proceso de análisis de Causa Raíz (RCA - Root Cause Analysis), en base a la metodología de Gestión de Problemas. Para incidentes con Severidad 2 al igual que un incidente Severidad 1 aplicará una solicitud de investigación que deberá emitir el grupo de Gestión de Problemas siempre y cuando el error sea el mismo y genere como mínimo de recurrencia 3 incidentes dentro de una semana. Para incidentes con Severidad 3 se puede solicitar un RCA si el responsable lo considera pertinente, siendo esto una actividad bajo demanda. En caso de que el equipo de equipo especializado no encuentre una solución al problema, canalizará el incidente con el proveedor responsable de la tecnología utilizada.