AAU0469 2

Texto completo

(1)UNIVERSIDAD CATÓLICA ANDRÉS BELLO FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA INDUSTRIAL. “DISEÑO DE UN PLAN DE MEJORAS A LOS PROCESOS DE CONTROL DE GESTIÓN DE LAS OPERACIONES DEL DEPARTAMENTO DE TECNOLOGÍA E INFORMACIÓN DE UNA CADENA DE FARMACIAS DE AUTOSERVICIO PARA EL AÑO 2018.”. TOMO II. TRABAJO DE GRADO Presentado ante la UNIVERSIDAD CATÓLICA ANDRÉS BELLO Como parte de los requisitos para optar al título de Ingeniero Industrial. REALIZADO POR: Br. Rondón, Paulina PROFESOR GUÍA: Ing. Luis Gutiérrez.

(2) ÍNDICE DE ANEXOS Anexo 1: Registrar, clasificar, categorizar, diagnosticar y resolver incidentes de lunes a viernes .................................................................................................................................. 1 Anexo 2: Registrar, clasificar, categorizar, diagnosticar y resolver incidentes de lunes a viernes .................................................................................................................................. 2 Anexo 3: Proceso de escalamiento de incidentes ....................................................... 2 Anexo 4: Proceso de cierre de incidentes ................................................................... 3 Anexo 5: Proceso de control de cambios rutinarios ................................................... 3 Anexo 6: Proceso de control de cambios de emergencia ........................................... 4 Anexo 7: Proceso de control de cambio normal ......................................................... 5 Anexo 8: Proceso de análisis y diagnóstico de incidentes masivos: 1er nivel de escalamiento ........................................................................................................................... 6 Anexo 9: Análisis y diagnóstico de incidentes masivos: 2do nivel de escalamiento . 7 Anexo 10: Análisis y diagnóstico de incidentes masivos: 3er nivel de escalamiento 8 Anexo 11: Proceso de solución y monitoreo de incidentes masivos .......................... 9 Anexo 12: Continuación de solución y monitoreo de incidentes masivos ............... 10 Anexo 13: Documentación y cierre de incidentes masivos ...................................... 11 Anexo 14: Registrar y clasificar fallas masivas o recurrentes .................................. 12 Anexo 15: Proceso de diagnosticar la causa raíz ...................................................... 13 Anexo 16: Proceso de resolver y documentar fallas masivas y recurrentes ............. 14 Anexo 17: Proceso de cierre de fallas masivas y recurrentes ................................... 14 Anexo 18: Monitorear infraestructura y soluciones aplicadas ................................. 15 Anexo 19: Proceso de restablecimiento de servicio de enlace en tienda .................. 16 Anexo 20: Continuación de proceso de restablecimiento de servicio de enlace en tienda .................................................................................................................................... 16 Anexo 21: Monitoreo de procesos BATCH en Appworx ........................................ 17 Anexo 22: Monitoreo de plataforma TI en PRTG Network Monitor ....................... 17 Anexo 23: Diagrama causa-efecto del proceso de registro....................................... 18 Anexo 24: Diagrama causa-efecto del proceso de categorización ........................... 18 Anexo 25: Diagrama causa-efecto del proceso de escalamiento .............................. 19 i.

(3) Anexo 26: Diagrama causa-efecto del proceso de documentación .......................... 19 Anexo 27: Diagrama causa-efecto del proceso de cierre .......................................... 20 Anexo 28: Diagrama causa-efecto del proceso de seguimiento y observación ........ 20 Anexo 29: Campos de categorización en la herramienta CA Service Desk Management ......................................................................................................................... 21 Anexo 30: Front propuesto para el módulo de empleados en la herramienta CA Service Desk Management ................................................................................................... 21 Anexo 32: Ficha técnica del top 15 de incidentes atendidos por CUATI ................ 22 Anexo 33: Ficha técnica del top 15 de solicitudes atendidas por CUATI ................ 23 Anexo 34: Ficha técnica de lo asignado a CUATI del universo ............................... 23 Anexo 35: Ficha técnica del % de solución N1 ........................................................ 24 Anexo 36: Ficha técnica del % de backlog ............................................................... 25 Anexo 37: Ficha técnica del histórico de asignación, % solucionado N1 y % backlog .............................................................................................................................................. 25 Anexo 38: Ficha técnica del cumplimiento de SLA general .................................... 26 Anexo 39: Ficha técnica del cumplimiento de SLA por tickets tipo incidente ........ 27 Anexo 40: Ficha técnica del cumplimiento de SLA por tickets tipo solicitud ......... 27 Anexo 41: Ficha técnica de RFC por gerencia y clasificación ................................. 28 Anexo 42: Ficha técnica del origen del RFC ............................................................ 29 Anexo 43: Ficha técnica de resultados de los RFC .................................................. 29 Anexo 44: Ficha técnica de RFC emergentes por incidentes ................................... 30 Anexo 45: Ficha técnica de RFC emergentes por problemas, proyectos o requerimientos ...................................................................................................................... 31 Anexo 46: Ficha técnica de RFC ejecutados no autorizados .................................... 31 Anexo 47: Ficha técnica de histórico de RFC por clasificación ............................... 32 Anexo 48: Ficha técnica de incidentes abiertos y cerrados ...................................... 33 Anexo 49: Ficha técnica de incidentes abiertos y cerrados por servicio .................. 33 Anexo 50: Ficha técnica de incidentes por área solucionadora ................................ 34 Anexo 51: Ficha técnica de MTTR (Medium Time To Repair) ............................... 35 Anexo 52: Ficha técnica de MTBF (Mean Time Between Failures) ........................ 35 ii.

(4) Anexo 53: Ficha técnica de problemas abiertos ....................................................... 36 Anexo 54: Ficha técnica de problemas por estatus ................................................... 37 Anexo 55: Ficha técnica por estatus de área solucionadora ..................................... 38 Anexo 56: Ficha técnica de estatus por tipo de incidencia ....................................... 38 Anexo 57: Ficha técnica de tiempo promedio de grupo solucionador ..................... 39 Anexo 58: Ficha técnica de tiempo de respuesta de proveedor ................................ 40 Anexo 59: Ficha técnica de cumplimiento de notificaciones ................................... 40 Anexo 60: Ficha técnica de seguimiento a proveedor .............................................. 41 Anexo 61: Ficha técnica de seguimiento a grupo solucionador ............................... 42 Anexo 62: Ficha técnica de demanda registrada por tipo de evento, alcance y prioridad .............................................................................................................................................. 42 Anexo 63: Ficha técnica de demanda registrada por herramienta ............................ 43 Anexo 64: Ficha técnica de demanda de eventos registrada por componentes ........ 44. iii.

(5) Anexo 1: Registrar, clasificar, categorizar, diagnosticar y resolver incidentes de lunes a viernes hasta las 10 pm Fuente: Elaboración propia PROCESO DE ADMINISTRACIÓN DE MESA DE SERVICIOS. PAMS01. Registrar / Clasificar / Categorizar / Diagnosticar Y Resolver Incidentes De Lunes A Viernes Hasta Las 10pm. Analista de Soporte de Servicio TI asignado a atender llamadas/correos. Iniciar. Recibe llamadas de usuarios. Validar que la información de la solicitud está completa en la herramienta Service Desk Management. Registrar información de la solicitud en la herramienta Service Desk Management. Activa protocolo de atención telefónica. NO. A. SÍ. Recibe casos vía mail. A. ¿Información completa?. Llamar al solicitante y completar la información en ticket en la herramienta Service Desk Management. NO. Diagnosticar incidente. ¿Incidente de 1er nivel? (5 min). SÍ. NO SÍ. B. B. ¿Incidente nivel 1.5? (30 min). SÍ. Asignar a CUATI remoto. NO. Escalar incidente al área resultora. Fin. 1. Atender incidente/ solicitud. Cerrar Incidente.

(6) Anexo 2: Registrar, clasificar, categorizar, diagnosticar y resolver incidentes de lunes a viernes hasta de 10pm a 7am y fines de semana Fuente: Elaboración propia PROCESO DE ADMINISTRACIÓN DE MESA DE SERVICIOS. PAMS01. Analista de Soporte de Servicio TI asignado a atender llamadas/correos. Registrar / Clasificar / Categorizar / Diagnosticar Y Resolver Incidentes De Lunes A Viernes De 10pm A 7am Y Fines De Semana. Iniciar. Recibe llamadas de usuarios. Activa protocolo de atención telefónica. Registrar información de la solicitud en la herramienta Service Desk Management. Validar que la información de la solicitud está completa en la herramienta Service Desk Management. NO. A. SÍ. Recibe casos vía mail. ¿Información completa?. A. NO. Llamar al solicitante y completar la información en ticket en la herramienta Service Desk Management. Diagnosticar incidente. ¿Incidente nivel 1.5? (30 min). SÍ. Atender incidente/ solicitud. Cerrar Incidente. NO. SÍ. Escalar incidente al área resultora. Fin. Anexo 3: Proceso de escalamiento de incidentes Fuente: Elaboración propia. PROCESO DE ADMINISTRACIÓN DE MESA DE SERVICIOS. Área Resultora. Herramienta Service Desk Management. Escalar Incidente. Iniciar. Enviar mail automático al área resultora. A. B. Enviar mail automático al usuario indicando solventado. Cerrar Incidente. A. Evaluar diagóstico registrado en CUATI. Resolver ticket. Fin. Actualizar estado de ticket en la herramienta de Service Desk Management. 2. B. PAMS02.

(7) Anexo 4: Proceso de cierre de incidentes Fuente: Elaboración propia PROCESO DE ADMINISTRACIÓN DE MESA DE SERVICIOS. PAMS03. Cerrar Incidente. B. Revisar diariamente la cola de tickets resueltos y en espera. Analista de Soporte de Servicio TI. Iniciar. Validar ticket resuelto: envía el mail o llama al usuario. ¿El usuario responde?. SÍ. ¿Ticket resuelto?. SÍ. B. SÍ. Registrar el nombre y cargo del usuario en la herramienta S.D.M. Validar con el usuario que el incidente no persista.. A. Cambiar estatus en la herramienta a ticket cerrado. NO. ¿Más de 72 horas?. NO NO. Herramienta Service Desk Management. Cambiar en la herramienta el estatus del ticket a En Curso . Registrar nombre y cargo y documentar lo dicho por el usuario. Enviar mail automático al usuario indicando ticket cerrado. A. Escalar incidente. Fin. Anexo 5: Proceso de control de cambios rutinarios Fuente: Elaboración propia PROCESO DE ATENCIÓN DE CONTROL DE CAMBIOS Cambio Rutinario. Registrar el RFC (Request For Change) con su debida documentación. Área Responsable. Iniciar. ¿RFC liberado?. A. NO. B. Corregir RFC. SÍ. Gestor de Cambios. Realizar la evaluación primaria del RFC. ¿La documentación está completa?. SÍ. NO. SÍ. Implantar RFC. NO. A. B. ¿RFC aprobado?. A. Cancelar el RFC. 3. Fin. PACC01.

(8) Anexo 6: Proceso de control de cambios de emergencia Fuente: Elaboración propia PROCESO DE ATENCIÓN DE CONTROL DE CAMBIOS. PACC02. Cambio De Emergencia. Registrar el RFC (Request For Change) con su debida documentación. Área Responsable. Iniciar. A. ¿RFC liberado?. B. NO. Corregir RFC. SÍ. Gestor de Cambios. Realizar la evaluación primaria del RFC. B. ¿La documentación está completa?. SÍ. Aprobación de CAB de emergencia. ¿CAB de emergencia aprobado?. NO. NO. A. A. SÍ. Cancelar el RFC. 4. Implantar RFC. Fin.

(9) Anexo 7: Proceso de control de cambio normal Fuente: Elaboración propia PROCESO DE ATENCIÓN DE CONTROL DE CAMBIOS. PACC03. Cambio Normal. Registrar el RFC (Request For Change) con su debida documentación. Área Responsable. Iniciar. ¿RFC liberado?. B. NO. C A. Corregir RFC. ¿RFC liberado?. SÍ. D. Corregir RFC. NO. Gestor de Cambios. SÍ. Realizar la evaluación primaria del RFC. ¿La documentación está completa?. E. Pre-evaluación mesa técnica. SÍ. ¿Pre-evaluación correcta?. NO. NO. A. A. SÍ. Liberar a las áreas contraloras. Aprobar por CAB Operativo. ¿Aprobado?. SÍ. Implantar RFC. Fin. B. Áreas Contraloras. RFC se agenda para Comité. Cancelar el RFC. Realizar evaluación áreas contraloras: Monitoreo Continuidad Auditoría Área Implantadora Seguridad. D. ¿La documentación está completa?. SÍ. ¿Todas las áreas contraloras están conformes?. NO. NO. C. B. SÍ. E. 5. NO. A.

(10) Anexo 8: Proceso de análisis y diagnóstico de incidentes masivos: 1er nivel de escalamiento Fuente: Elaboración propia PROCESO DE ATENCIÓN DE INCIDENTES MASIVOS. PAIM01. Guardia de Área Solucionadora. CUATI. Gestor de Incidentes Masivos. ANÁLISIS Y DIAGNÓSITICO DE INCIDENTES MASIVOS: 1ER NIVEL DE ESCALAMIENTO. Iniciar. Realizar conferencia telefónica con guardia de área solucionadora y coord. CUATI.. Definir y activar plan de diagnóstico inicial (PD1). Enviar correo a Comité de Sistemas e involucrados. A. B. Controlar estatus vía telefónica entre guardia de área solucionadora y coord. CUATI. ¿Existe diagnóstico?. SÍ. Solución y monitoreo. NO. Análisis y diagnóstico de fallas masivas: 2do nivel de escalamiento. Enviar notificación vía correo electrónico a áreas afectadas del negocio. A. Aplicar el plan de diagnóstico inicial (PD1). B. 6. Fin.

(11) Anexo 9: Análisis y diagnóstico de incidentes masivos: 2do nivel de escalamiento Fuente: Elaboración propia. PROCESO DE ATENCIÓN DE INCIDENTES MASIVOS. PAIM02. ANÁLISIS Y DIAGNÓSITICO DE INCIDENTES MASIVOS: 2DO NIVEL DE ESCALAMIENTO. Definir y activar nuevo plan de diagnóstico (PD2). Gestor de Incidentes Masivos. Iniciar. Realizar conferencia telefónica con guardia de área solucionadora, coord. CUATI y gerentes de TI.. B. Tiempo transcurrido 30 minutos. Incorporar proveedor en el diagnóstico de ser necesario. Notificar avances vía correo al Comité de Sistemas e involucrados y destinatarios del negocio.. A. Realizar conferencia telefónica con guardia de área solucionadora, coord. CUATI y gerentes de TI.. Controlar estatus vía telefónica con guardia de área solucionadora. Análisis y diagnóstico de fallas masivas: 3er nivel de escalamiento. NO. ¿Existe diagnóstico?. SÍ. Guardia de Área Solucionadora. CUATI. Fin. Enviar notificación de avance vía correo electrónico a tiendas. A. Aplicar nuevo plan de diagnóstico definido (PD2). B. 7. Solución y monitoreo.

(12) Anexo 10: Análisis y diagnóstico de incidentes masivos: 3er nivel de escalamiento Fuente: Elaboración propia. PROCESO DE ATENCIÓN DE INCIDENTES MASIVOS. PAIM03. ANÁLISIS Y DIAGNÓSITICO DE INCIDENTES MASIVOS: 3ER NIVEL DE ESCALAMIENTO. B. Gestor de Incidentes Masivos. Iniciar. Realizar conferencia telefónica con guardia de área solucionadora, coord. CUATI, Gtes. de TI y VP de TI. Notificar avances vía correo a Comité de Sistemas e involucrados cada 30 min. Y destinatarios del negocio cada 60 minutos. Tiempo transcurrido 30 minutos. Definir y activar nuevo plan de diagnóstico (PD3). ¿Aplica atención conjunta en sitio?. A. NO. Controlar estatus vía telefónica cada 30 minutos con guardia, coord. O gte. Área solucionadora.. SÍ. Atención conjunta en sitio NO. ¿Existe diagnóstico?. Realizar conferencia telefónica cada 30 minutos con guardia de área solucionadora, coord. CUATI, Gtes. TI y VP TI.. SÍ. Solución y monitoreo. Fin. SÍ. ¿Existe diagnóstico?. NO. A. Guardia de Área Solucionadora. VP de TI. CUATI. Enviar notificación de avance vía correo electrónico a tiendas cada 60 minutos. Notificar vía telefónica a Comité Ejecutivo cada 60 minutos. A. Aplicar nuevo plan de diagnóstico definido (PD3). B. 8.

(13) Anexo 11: Proceso de solución y monitoreo de incidentes masivos Fuente: Elaboración propia. PROCESO DE ATENCIÓN DE INCIDENTES MASIVOS. PAIM04. Gestor de Incidentes Masivos. Guardia de Área Solucionadora. SOLUCIÓN Y MONITOREO. A. Identificar y definir acciones para solventar incidente. Iniciar. Informar al gestor de incidentes. B. C. Solucionar incidente. Desarrollar RFC. B. D. Activar conferencia telefónica con involucrados. Detallar solución a aplicar. Solicitar aprobación al Comité de Sistemas. ¿Aprobado?. ¿Requiere RFC?. SÍ. NO. NO. A. B. SÍ. D. Activar conferencia telefónica con involucrados y evaluar los resultados. ¿Aprobado?. NO. Activar conferencia telefónica con involucrados y redefinir solución y revalidar causa identificada. A. CUATI. SÍ. Validar con el área afectada. Notificar vía correo solución y fin de falla a tiendas. A. Monitoreo. Durante 2 horas. Tomar evidencias y enviar al GIM y al GAS. Validar en monitores que no haya alertas y que los procesos se ejecuten correctamente. C. Especialistas Arquitectura/ Aplicaciones. Durante 2 horas. Validar que componentes de TI operan correctamente. Tomar evidencias y enviar al GIM y al GAS. C. Durante 2 horas. 9. Administrar cambios. B. C.

(14) Anexo 12: Continuación de solución y monitoreo de incidentes masivos Fuente: Elaboración propia. PROCESO DE ATENCIÓN DE INCIDENTES MASIVOS. PAIM04. SOLUCIÓN Y MONITOREO. Validar telefónicamente resultados del monitoreo con GAS. Gestor de Incidentes. C. Activar conferencia telefónica con involucrados para formalizar resultados. A ¿Monitoreo exitoso?. NO. Notificar vía correo solución y fin de falla a Comité de Sistemas, involucrados y negocio. SÍ. Análisis y diagnóstico incidentes masivos 3er nivel de escalamiento Documentación y cierre. VP de TI. Fin. B. Notificar vía telefónica a negocio solución y fin de falla. 10.

(15) Anexo 13: Documentación y cierre de incidentes masivos Fuente: Elaboración propia. PROCESO DE ATENCIÓN DE INCIDENTES MASIVOS. Gestor de Problemas e Incidentes. Coordinador de área solucionadora. DOCUMENTACIÓN Y CIERRE. Máximo de 3 días hábiles después de la falla. Iniciar. Redactar informe de incidencia y adjuntar evidencias recabadas en monitoreo. Revisar documentación para validar si debe ser escalada a Gestor de Problemas. Adjuntar el informe a ticket padre. Informar a coord. CUATI que proceda a cerrar tickets asociados a la falla. Enviar el informe a cuenta de Gestión de Incidentes. ¿Escalar a Gestor de Problemas?. Coordinador CUATI. NO. Cerrar tickets asociados a la falla. Fin. 11. SÍ. Administrar problemas. PAIM05.

(16) Anexo 14: Registrar y clasificar fallas masivas o recurrentes Fuente: Elaboración propia PROCESO DE ADMINISTRACIÓN DE PROBLEMAS. PAPR01. Mesa Técnica. Gestor de Problemas. Área Responsable. CUATI. REGISTRAR Y CLASIFICAR FALLAS MASIVAS O RECURRENTES. Iniciar. A. B. D. Reportar e identificar fallas en más de 10 tiendas o fallas de Telecom o Aplicaciones en oficina corporativa/ CENDIS como falla masiva. Atender falla masiva. B. Monitorear resolución de falla. Determinar tipo de falla masiva: hardware, capas de SW (redes, B.D, S.O, aplicaciones y middleware. Asignar caso a área responsable y copiar a gestor de problemas. Convocar mesa técnica de emergencia. C. ¿Lleva más de 2 horas?. E. SÍ. A. E. G. ¿Es posible aplicar paliativo?. NO. NO. A. C. G. Generar paliativo. Solicitar aprobación VP TI.. Aplicar paliativo. SÍ. F. Generar RFC de emergencia para paliativo. G. Convocar a mesa técnica de falla a las áreas resolutorias. ¿Aprobado VP TI?. SÍ. G. D. F. Analizar causa raíz. Fin NO. 12. E.

(17) Anexo 15: Proceso de diagnosticar la causa raíz Fuente: Elaboración propia. PROCESO DE ADMINISTRACIÓN DE PROBLEMAS. PAPR02. DIAGNOSTICAR CAUSA RAÍZ. Mesa Técnica. C. Discutir sobre la base de la información recopilada de la falla. Iniciar. ¿Falla de aplicación casera?. ¿Causa raíz identificada?. SÍ. NO. ¿Causa raíz identificada?. F. SÍ. Resolver y documentar falla masiva. SÍ. NO. Área Responsable. Extender paliativo. Gestor de Problemas. B. Hacer seguimiento a acuerdos establecidos por las áreas. Proveedor Correspondiente. D. A. E. Proveer solución a falla. B. D. NO. Asignar caso al área responsable de la aplicación para análisis. Establecer acuerdos y compromisos. Contactar a proveedor correspondiente. Dar seguimiento al caso. E. C. F. 13. Fin. A.

(18) Anexo 16: Proceso de resolver y documentar fallas masivas y recurrentes Fuente: Elaboración propia. PROCESO DE ADMINISTRACIÓN DE PROBLEMAS. PAPR03. Gestor de Problemas. Área Responsable. RESOLVER Y DOCUMENTAR FALLAS MASIVAS Y RECURRENTES. Iniciar. Almacenar documentación de fallas en carpetas compartidas. A. Documentar fallas y enviar al Gestor de Problemas. Solucionar falla. Gestionar RFC. Cerrar ticket en Service Desk. A. Fin. Anexo 17: Proceso de cierre de fallas masivas y recurrentes Fuente: Elaboración propia. PROCESO DE ADMINISTRACIÓN DE PROBLEMAS. Gestor de Problemas. Gestor de Incidentes. CERRAR FALLAS MASIVAS Y RECURRENTES. Iniciar. A. Generar y presentar al Comité de TI estadísticas semanales de fallas masivas/recurrentes. Generar y presentar estatus de mesas técnicas de fallas masivas/recurrentes activas y cerradas al Comité de TI. A. Fin. 14. PAPR04.

(19) Anexo 18: Monitorear infraestructura y soluciones aplicadas Fuente: Elaboración propia PROCESO DE ADMINISTRACIÓN DE PROBLEMAS. PAPR05. MONITOREAR INFRAESTRUCTURA Y SOLUCIONES APLICADAS. Mesa Técnica. Gestor de Problemas. D. Iniciar. Validar con CUATI y usuario final nuevas incidencias de las fallas masivas cerradas. ¿Nuevas incidencias asociadas?. NO. Recibir semanalmente reportes de PRTG de servidores críticos y analizar tendencias. ¿Servidor crítico con alarma?. SÍ. Discutir sobre la base del análisis realizado. ¿Causa raíz identificada?. Resolver y documentar falla masiva. SÍ. D. C. NO. Área Resolutoria. B. C. B. Aplicar paliativo preventivo. Aplicar correctivos pertinentes. Enviar informe de servidor con posibles fallas a área resultoria. Convocar mesa técnica. NO. Informar a área resolutoria y actualizar en Service Desk. A. SÍ. Resolver y documentar falla masiva. D. 15. A.

(20) Anexo 19: Proceso de restablecimiento de servicio de enlace en tienda Fuente: Elaboración propia PROCESO DE MONITOREO Y PLATAFORMA TI. PMOP01. Restablecimiento De Servicio De Enlace En Tienda. Monitorear alarmas de sensores a través de las vistas en PRTG. Iniciar. Certificar información asociada al sensor con falla y monitorearlo por 10 min para descartar una latencia o parpadeo en el monitoreo. SÍ. ¿Falla persiste?. Notificar vía correo electrónico a la Gerencia de Servicios de TI. Llamar a la tienda para validar si se trata de una falla eléctrica. Preguntar a la tienda si tienen conexión con alguna página de internet. NO SÍ. NO. Analista de Operaciones. NO. ¿Hay ABBA?. Escalar a Telecomunicaciones. SÍ. A. B. H. E. F. NO. A. ¿Hay conexión?. NO. Llamar al proveedor de servicio (Movistar, CANTV o Telcorp). Verificar mediante documentación interna o PRTG si la tienda tiene ABBA. B. ¿Falla eléctrica?. Realizar pruebas de N1: Conectar el equipo a interfaces del switche, verificar que las luces enciendan, verificar si hay conexión o reiniciar el BAM.. SÍ. ¿Hay TP-Link?. SÍ. Reiniciar ABBA desde la tienda. ¿Falla persiste?. Sacar el chip del BAM y conectarlo en un celular Movistar de la tienda para verificar el saldo.. SÍ. NO. Conectarse al router y verificar si la interfaz de ABBA levanta. C. NO. SÍ. Llamar al proveedor de servicio (Movistar, CANTV o Telcorp). G. ¿El chip tiene saldo?. ¿Falla persiste?. NO. D. SÍ. SÍ. E. D. Fin. H. ¿Falla persiste?. NO. Anexo 20: Continuación de proceso de restablecimiento de servicio de enlace en tienda Fuente: Elaboración propia PROCESO DE MONITOREO Y PLATAFORMA TI. PMOP01. Restablecimiento De Servicio De Enlace En Tienda. Analista de Operaciones. NO. C. Mandar a recargar saldo. ¿La tienda le recargó saldo?. NO. Esperar a que la tienda recargue. Llamar al proveedor de servicio (Movistar, CANTV o Telcorp). NO. ¿Recargó?. SÍ. SÍ. SÍ. F. G. 16. Escalar al gerente de tienda. Esperar respuesta. ¿El gerente respondió?.

(21) Anexo 21: Monitoreo de procesos BATCH en Appworx Fuente: Elaboración propia PROCESO DE MONITOREO Y PLATAFORMA TI. PMOP02. Monitoreo De Procesos BATCH En Appworx. B. Analista de Operaciones. Iniciar. Verificar procesos que excedan su tiempo de ejecución o que aborten. Certifico la aplicación que está arrojando el error. Verificar el log haciendo doble click en el proceso. Llamar a guardia de área solucionadora: al especialista de soporte de seguridad N2 (DBA, Aplicaciones, Finanzas, AdminSO). ¿Han pasado 3 intentos?. SÍ. Llamar al supervisor de la guardia solucionadora. ¿Han pasado 3 intentos?. SÍ. Llamar al gerente de la guardia solucionadora. NO NO. A. A. ¿El gerente contestó?. Esperar las instrucciones del área solucionadora. Llamar al VP de TI. NO. ¿Son instrucciones ejecutables por el analista?. NO. Las ejecutan los especialistas del área solucionadora. B NO. SÍ. SÍ. Las ejecuta el analista de monitoreo. Esperar que el programa se restablezca. ¿El programa se restableció?. SÍ. Fin. Anexo 22: Monitoreo de plataforma TI en PRTG Network Monitor Fuente: Elaboración propia PROCESO DE MONITOREO Y PLATAFORMA TI. PMOP03. Monitoreo De Plataforma TI En PRTG Network Monitor. Iniciar. Verificar en cualquiera de las herramientas de monitoreo si hay fallas. ¿Existe una falla?. SÍ. Verificar si la falla tiene campo de acción para que el analista realice un N1. ¿Tienen campo de acción?. Notificar por correo electrónico y por llamada telefónica al especialista, coordinador o al gerente del área. NO. Analista de Operaciones. C. NO. Verificar si el incidente es de impacto. ¿El incidente es de impacto?. SÍ. Realizar el N1 correspondiente. C. NO. ¿La falla persiste?. SÍ. A. Escalar a N2. B. Realizar el seguimiento y la observación de la solución aplicada con un período de tiempo dependiendo de la falla. A. SÍ. D. ¿Falla persiste?. SÍ. Involucrar al gestor de incidentes y al coordinador del Centro de Monitoreo. D. NO. Realizar una conferencia con el gestor de incidentes y las áreas solucionadoras para buscar una solución parcial o total sobre el incidente. Fin. 17. B. NO. A.

(22) Anexo 23: Diagrama causa-efecto del proceso de registro Fuente: Elaboración propia. Anexo 24: Diagrama causa-efecto del proceso de categorización Fuente: Elaboración propia. 18.

(23) Anexo 25: Diagrama causa-efecto del proceso de escalamiento Fuente: Elaboración propia. Anexo 26: Diagrama causa-efecto del proceso de documentación Fuente: Elaboración propia. 19.

(24) Anexo 27: Diagrama causa-efecto del proceso de cierre Fuente: Elaboración propia. Anexo 28: Diagrama causa-efecto del proceso de seguimiento y observación Fuente: Elaboración propia. 20.

(25) Anexo 29: Campos de categorización en la herramienta CA Service Desk Management Fuente: CA Service Desk Management. Anexo 30: Front propuesto para el módulo de empleados en la herramienta CA Service Desk Management Fuente: Elaboración propia. 21.

(26) Anexo 31: Ficha técnica del top 15 de incidentes atendidos por CUATI Fuente: Elaboración propia Descripción:. Razones:. Responsable de la. Top 15 de Incidentes Atendidos por CUATI El top 15 de incidentes atendidos por CUATI mide las categorías de los incidentes que las tiendas reportan con más frecuencia a los que CUATI debe realizar un N1 correspondiente para su atención inmediata. Conocer el Top 15 de Incidentes Atendidos permite:  Identificar los incidentes recurrentes.  Apoyar al Gestor de Incidentes con su gestión y análisis.  Observar el comportamiento de las categorías de los incidentes.  Tomar acciones correctivas. Coordinador CUATI. Administración: Frecuencia:. Unidad de Medida Elementos de los Datos.  Semanal  Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número de incidentes Datos Información general referente a los tickets tipo incidente provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). Aplica:. Tickets categorizados tipo incidente.. Método de Cálculo:. Tablas dinámicas en la herramienta Microsoft Excel.. Resultado. Número de incidentes.. de. la. Medida:. 22.

(27) Anexo 32: Ficha técnica del top 15 de solicitudes atendidas por CUATI Fuente: Elaboración propia Descripción:. Razones:. Responsable de la. Top 15 de Solicitudes Atendidas por CUATI El top 15 de solicitudes atendidas por CUATI mide las categorías de las solicitudes que las tiendas reportan con más frecuencia a los que CUATI debe realizar un N1 correspondiente para su atención inmediata. Conocer el Top 15 de Solicitudes Atendidas permite:  Identificar las solicitudes recurrentes.  Observar el comportamiento de las categorías de las solicitudes.  Tomar acciones correctivas. Coordinador CUATI. Administración:  Semanal  Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número de tickets.. Frecuencia:. Unidad de Medida Elementos de los Datos. Datos Información general referente a los tickets tipo solicitud provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). Aplica:. Tickets categorizados tipo solicitud.. Método de Cálculo:. Tablas dinámicas en la herramienta Microsoft Excel.. Resultado. Número de solicitudes.. de. la. Medida:. Anexo 33: Ficha técnica de lo asignado a CUATI del universo Fuente: Elaboración propia. Descripción: Razones:. Responsable de la. Asignado a CUATI del universo Lo asignado a CUATI del universo mide la cantidad de tickets que atiende CUATI en general. Conocer el Top 15 de Solicitudes Atendidas permite:  Identificar la cantidad de N1 que realizan los analistas.  Observar el comportamiento de los tickets para tomar medidas preventivas. Coordinador CUATI. Administración: Frecuencia:.  Semanal  Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos.. 23.

(28) Unidad de Medida. Número de tickets.. Elementos de los. Datos Información general referente a los tickets provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Datos. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). Aplica:. Tickets categorizados.. Método de Cálculo:. Tablas dinámicas en la herramienta Microsoft Excel. Para sacar su valor en porcentaje se aplica la siguiente fórmula: 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑡𝑖𝑐𝑘𝑒𝑡𝑠 𝑎𝑠𝑖𝑔𝑛𝑎𝑑𝑜𝑠 𝑎 𝐶𝑈𝐴𝑇𝐼 % 𝐴𝑠𝑖𝑔𝑛𝑎𝑐𝑖ó𝑛 𝑎 𝐶𝑈𝐴𝑇𝐼 = 𝑇𝑜𝑡𝑎𝑙 𝑑𝑒 𝑡𝑖𝑐𝑘𝑒𝑡𝑠 % de tickets tipo incidente y solicitud asignados y atendidos por el Centro Único de Atención TI (CUATI) del universo de tickets.. Resultado. de. la. Medida:. Anexo 34: Ficha técnica del % de solución N1 Fuente: Elaboración propia Descripción: Razones:. Responsable de la. % Solución N1 El % de solución N1 indica el % de eficiencia que tuvo el área en cuanto a la solución de los tickets en un primer nivel de atención. Conocer el % de solución N1 permite:  Observar el nivel de eficiencia que tiene el área en la atención de tickets.  Tomar medidas preventivas y mejorar las ya existentes. Coordinador CUATI. Administración: Frecuencia:. Unidad de Medida Elementos de los Datos. Aplica: Método. de. Cálculo:.  Semanal  Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número de tickets. Datos Información general referente a los tickets provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta) Tickets categorizados y en estado “Resuelto” o “Cerrado”.  . Tablas dinámicas en la herramienta Microsoft Excel. Aplicación de la siguiente fórmula:. 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑡𝑖𝑐𝑘𝑒𝑡𝑠 𝑒𝑛 𝑒𝑠𝑡𝑎𝑑𝑜 "𝑅𝑒𝑠𝑢𝑒𝑙𝑡𝑜 𝑜 𝐶𝑒𝑟𝑟𝑎𝑑𝑜" 𝑇𝑜𝑡𝑎𝑙 𝑑𝑒 𝑡𝑖𝑐𝑘𝑒𝑡𝑠 𝑎𝑡𝑒𝑛𝑑𝑖𝑑𝑜𝑠 𝑝𝑜𝑟 𝐶𝑈𝐴𝑇𝐼 % de tickets atendidos por el Centro Único de Atención TI (CUATI). % 𝑆𝑜𝑙𝑢𝑐𝑖ó𝑛 𝑁1 =. Resultado. de. la. Medida:. 24.

(29) Anexo 35: Ficha técnica del % de backlog Fuente: Elaboración propia Descripción: Razones:. Responsable de. % Backlog El % de backlog indica el % de deficiencia que tuvo el área en cuanto a la solución de los tickets en un primer nivel de atención. Conocer el % backlog permite:  Establecer acciones correctivas.  Identificar la deficiencia del área. Coordinador CUATI. la Administración: Frecuencia:. Unidad. de.  Semanal  Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número de tickets.. Medida Elementos. de. los Datos. Aplica: Método. de. Cálculo:. Datos Información general referente a los tickets provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta) Tickets categorizados y en estado “En Curso” o “Esperando respuesta del usuario final”.  . Tablas dinámicas en la herramienta Microsoft Excel. Aplicación de la siguiente fórmula:. % 𝐵𝑎𝑐𝑘𝑙𝑜𝑔 =. Resultado de la. 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑡𝑖𝑐𝑘𝑒𝑡𝑠 𝑒𝑛 𝑒𝑠𝑡𝑎𝑑𝑜 "En Curs𝑜" o "𝐸𝑠𝑝𝑒𝑟𝑎𝑛𝑑𝑜 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎 𝑑𝑒𝑙 𝑢𝑠𝑢𝑎𝑟𝑖𝑜 𝑓𝑖𝑛𝑎𝑙" 𝑇𝑜𝑡𝑎𝑙 𝑑𝑒 𝑡𝑖𝑐𝑘𝑒𝑡𝑠 𝑎𝑡𝑒𝑛𝑑𝑖𝑑𝑜𝑠 𝑝𝑜𝑟 𝐶𝑈𝐴𝑇𝐼. % de tickets no atendidos por el Centro Único de Atención TI (CUATI).. Medida:. Anexo 36: Ficha técnica del histórico de asignación, % solucionado N1 y % backlog Fuente: Elaboración propia Indicador general: Histórico de asignación, % solucionado N1 y % backlog El histórico de asignación, % solucionado N1 y % backlog indica el comportamiento que ha tenido el área en el último año mediante un gráfico. Razones: Conocer el histórico de asignación, % de solucionado N1 y % backlog permite:  Realizar comparaciones con los meses anteriores.  Observar si la meta del negocio fue cumplida con respecto al mes anterior.  Realizar acciones correctivas. Responsable de la Coordinador CUATI Descripción:. Administración:. 25.

(30) Frecuencia:. Unidad de Medida Elementos de los Datos. Aplica:. Método.  Semanal  Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número de tickets. Datos Información general referente a los tickets provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). de. % obtenidos en:  Asignado a CUATI del universo.  % Solución N1  %Backlog Gráfico en la herramienta Microsoft Excel con los tres datos mencionados.. la. Histórico de tickets asignados, atendidos y desatendidos por CUATI.. Cálculo: Resultado. de. Medida:. Anexo 37: Ficha técnica del cumplimiento de SLA general Fuente: Elaboración propia Descripción: Razones:. Responsable de la. Cumplimiento de SLA general El cumplimiento de SLA general indica si el área atendió todos los tickets asignados en el tiempo correspondiente para cada uno de ellos. Conocer el cumplimiento de SLA general permite:  Tener una visión más amplia de la eficiencia de los analistas en atender los casos.  Realizar medidas correctivas. Coordinador CUATI. Administración: Frecuencia:. Unidad de Medida Elementos de los Datos. Aplica:.  Semanal  Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número de tickets. Datos Información general referente a los tickets provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Tickets categorizados.. 26. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta).

(31) Método. de. Cálculo: Resultado. de. la. Tablas y gráficos dinámicos en la herramienta Microsoft Excel. Para obtener el % se aplica la siguiente fórmula: 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑡𝑖𝑐𝑘𝑒𝑡𝑠 𝑒𝑛 𝑒𝑠𝑡𝑎𝑑𝑜 "𝐷𝑒𝑛𝑡𝑟𝑜 𝑑𝑒 𝑆𝐿𝐴" % 𝐶𝑢𝑚𝑝𝑙𝑖𝑚𝑖𝑒𝑛𝑡𝑜 𝑑𝑒 𝑆𝐿𝐴 = 𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑡𝑖𝑐𝑘𝑒𝑡𝑠 𝑎𝑠𝑖𝑔𝑛𝑎𝑑𝑜𝑠 𝑎 𝐶𝑈𝐴𝑇𝐼 Cumplimiento de SLA en %.. Medida:. Anexo 38: Ficha técnica del cumplimiento de SLA por tickets tipo incidente Fuente: Elaboración propia. Descripción: Razones:. Responsable de la. Cumplimiento de SLA de tickets tipo incidente El cumplimiento de SLA de tickets tipo incidente indica si el área atendió todos los incidentes en el tiempo correspondiente para cada uno de ellos. Conocer el cumplimiento de SLA de tickets tipo incidente permite:  Tener una visión más amplia de la eficiencia de los analistas en atender los incidentes.  Realizar medidas correctivas. Coordinador CUATI. Administración: Frecuencia:. Unidad de Medida Elementos de los Datos. Aplica:.  Semanal  Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número de tickets. Datos Información general referente a los tickets provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Tickets categorizados tipo incidente.. Método. de. Cálculo:. Tablas y gráficos dinámicos en la herramienta Microsoft Excel. Para obtener el % se aplica la siguiente fórmula: % 𝐶𝑢𝑚𝑝𝑙𝑖𝑚𝑖𝑒𝑛𝑡𝑜 𝑑𝑒 𝑆𝐿𝐴 =. Resultado. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). de. la. 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑡𝑖𝑐𝑘𝑒𝑡𝑠 𝑡𝑖𝑝𝑜 𝑖𝑛𝑐𝑖𝑑𝑒𝑛𝑡𝑒 𝑒𝑛 𝑒𝑠𝑡𝑎𝑑𝑜 "𝐷𝑒𝑛𝑡𝑟𝑜 𝑑𝑒 𝑆𝐿𝐴" 𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑡𝑖𝑐𝑘𝑒𝑡𝑠 𝑎𝑠𝑖𝑔𝑛𝑎𝑑𝑜𝑠 𝑎 𝐶𝑈𝐴𝑇𝐼. Cumplimiento de SLA de tickets tipo incidente en %.. Medida:. Anexo 39: Ficha técnica del cumplimiento de SLA por tickets tipo solicitud Fuente: Elaboración propia Descripción:. Cumplimiento de SLA de tickets tipo solicitud El cumplimiento de SLA de tickets tipo solicitud indica si el área atendió todos los incidentes en el tiempo correspondiente para cada uno de ellos.. 27.

(32) Razones:. Responsable de la. Conocer el cumplimiento de SLA de tickets tipo solicitud permite:  Tener una visión más amplia de la eficiencia de los analistas en atender las solicitudes.  Realizar medidas correctivas. Coordinador CUATI. Administración: Frecuencia:. Unidad de Medida Elementos de los Datos. Aplica:.  Semanal  Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número de tickets. Datos Información general referente a los tickets provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Tickets categorizados tipo solicitud.. Método. de. Cálculo:. Tablas y gráficos dinámicos en la herramienta Microsoft Excel. Para obtener el % se aplica la siguiente fórmula: % 𝐶𝑢𝑚𝑝𝑙𝑖𝑚𝑖𝑒𝑛𝑡𝑜 𝑑𝑒 𝑆𝐿𝐴 =. Resultado. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). de. la. 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑡𝑖𝑐𝑘𝑒𝑡𝑠 𝑡𝑖𝑝𝑜 𝑠𝑜𝑙𝑖𝑐𝑖𝑡𝑢𝑑 𝑒𝑛 𝑒𝑠𝑡𝑎𝑑𝑜 "𝐷𝑒𝑛𝑡𝑟𝑜 𝑑𝑒 𝑆𝐿𝐴" 𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑡𝑖𝑐𝑘𝑒𝑡𝑠 𝑎𝑠𝑖𝑔𝑛𝑎𝑑𝑜𝑠 𝑎 𝐶𝑈𝐴𝑇𝐼. Cumplimiento de SLA de tickets tipo solicitud en %.. Medida:. Anexo 40: Ficha técnica de RFC por gerencia y clasificación Fuente: Elaboración propia Descripción: Razones:. Responsable de la. RFC por gerencia y clasificación RFC por gerencia y clasificación indica el cantidad de RFC que ha generado cada gerencia. Conocer la cantidad de RFC por gerencia permite:  Conocer la participación de las gerencias en la resolución o mejora de bienes y servicios.  Conocer las áreas solucionadoras frecuentes.  Tomar medidas correctivas. Gestor de Control de Cambios. Administración: Frecuencia:. . Mensual. Unidad de Medida. Cantidad de RFC. Elementos de los. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Datos. 28. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la.

(33) información vaciada en los campos de dicha herramienta) Aplica:. RFC aprobados y ejecutados.. Método. de. Tablas dinámicas en la herramienta Microsoft Excel.. la. Cantidad de RFC generados por gerencia.. Cálculo: Resultado. de. Medida:. Anexo 41: Ficha técnica del origen del RFC Fuente: Elaboración propia Origen del RFC El origen del RFC indica su naturaleza y proveniencia.. Descripción: Razones:. Responsable de la. Conocer el origen del RFC permite:  Conocer los incidentes recurrentes que están afectando el negocio.  Conocer la cantidad de solicitudes, proyectos o mejoras que se están llevando a cabo.  Tomar medidas correctivas. Gestor de Control de Cambios. Administración: . Frecuencia:. Mensual. Unidad de Medida. Cantidad de RFC. Elementos de los. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Datos. Aplica:. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). RFC aprobados y ejecutados.. Método. de. Tablas dinámicas en la herramienta Microsoft Excel.. la. Origen de los RFC generados.. Cálculo: Resultado. de. Medida:. Anexo 42: Ficha técnica de resultados de los RFC Fuente: Elaboración propia Descripción: Razones:. Resultados de los RFC Los resultados de los RFC indican su estado final: Exitoso o no exitoso. Conocer los resultados del RFC permite:  Conocer si el RFC era útil para su servicio afectado.. 29.

(34) Responsable de la.  Conocer el nivel de compenetración que tuvo con el proceso.  Tomar medidas correctivas.  Tomar acciones preventivas. Gestor de Control de Cambios. Administración: . Frecuencia:. Mensual. Unidad de Medida. Cantidad de RFC. Elementos de los. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Datos. Aplica:. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). RFC aprobados y ejecutados.. Método. de. Tablas dinámicas en la herramienta Microsoft Excel.. la. RFC exitosos vs. RFC no exitosos.. Cálculo: Resultado. de. Medida:. Anexo 43: Ficha técnica de RFC emergentes por incidentes Fuente: Elaboración propia. Descripción: Razones:. Responsable de la. RFC emergentes: Incidentes RFC emergentes por Incidentes indica la cantidad de RFC que se tuvieron que aplicar para los diversos incidentes presentados durante el mes en distintas áreas. Conocer los RFC emergentes por incidente permite:  Conocer la cantidad de RFC que se realizaron para un mismo incidente.  Conocer la urgencia de su aplicación debido al servicio afectado.  Cambiar la estrategia de ataque ante los incidentes. Gestor de Control de Cambios. Administración: . Frecuencia:. Mensual. Unidad de Medida. Cantidad de RFC. Elementos de los. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Datos. Aplica: Método. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). RFC aprobados y ejecutados. de. Tablas dinámicas en la herramienta Microsoft Excel.. Cálculo:. 30.

(35) Resultado. de. la. Cantidad de RFC aplicados mediante un CAB.. Medida: Anexo 44: Ficha técnica de RFC emergentes por problemas, proyectos o requerimientos Fuente: Elaboración propia Descripción:. Razones:. Responsable de la. RFC emergentes: Problema/proyecto y requerimiento RFC emergentes por Problemas, Proyectos o Requerimientos indican la cantidad de RFC que se tuvieron que aplicar para los diversos problemas, proyectos o requerimientos presentados durante el mes en distintas áreas. Conocer los RFC emergentes por problemas, proyectos o requerimientos permite:  Conocer la cantidad de RFC que se realizaron para un mismo problema, proyecto o requerimiento.  Conocer la urgencia de su aplicación debido al servicio afectado.  Cambiar la estrategia de ataque ante los problemas  Cambiar la estrategia de abordaje de mejoras, proyectos y requerimientos, Gestor de Control de Cambios. Administración: . Frecuencia:. Mensual. Unidad de Medida. Cantidad de RFC. Elementos de los. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Datos. Aplica:. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). RFC aprobados y ejecutados.. Método. de. Tablas dinámicas en la herramienta Microsoft Excel.. la. Cantidad de RFC aplicados mediante un CAB.. Cálculo: Resultado. de. Medida:. Anexo 45: Ficha técnica de RFC ejecutados no autorizados Fuente: Elaboración propia. Descripción: Razones:. Responsable de la. RFC ejecutados: No autorizados RFC ejecutados no autorizados indican la cantidad de RFC que se realizaron sin pasar por el proceso legal de aprobación de RFC. Conocer los RFC ejecutados no autorizados permite:  Conocer la cantidad de RFC no autorizados que pasaron por encima del proceso legal de aprobación.  Conocer las áreas autoras de las acciones realizadas en el RFC aplicado.  Aplicar amonestaciones de ser necesario. Gestor de Control de Cambios. Administración:. 31.

(36) . Frecuencia:. Mensual. Unidad de Medida. Cantidad de RFC. Elementos de los. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Datos. Aplica: Método. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta) RFC ejecutados sin aprobación de una mesa técnica o un CAB.. de. Tablas dinámicas en la herramienta Microsoft Excel.. la. Cantidad de RFC aplicados no autorizados... Cálculo: Resultado. de. Medida:. Anexo 46: Ficha técnica de histórico de RFC por clasificación Fuente: Elaboración propia Descripción: Razones:. Responsable de la. Histórico: RFC por clasificación RFC por clasificación indica la cantidad de RFC aprobados en un histórico con extensión de hasta 1 año atrás. Conocer los RFC ejecutados no autorizados permite:  Realizar comparaciones con los meses anteriores de los RFC aplicados divididos en su respectiva clasificación.  Conocer la tendencia de los RFC.  Tomar acciones preventivas. Gestor de Control de Cambios. Administración: . Frecuencia:. Mensual. Unidad de Medida. Cantidad de RFC. Elementos de los. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Datos. Aplica:. RFC aprobados y ejecutados.. Método. de. Tablas y gráficos dinámicos en la herramienta Microsoft Excel.. la. Histórico de RFC por su clasificación.. Cálculo: Resultado. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). de. Medida:. 32.

(37) Anexo 47: Ficha técnica de incidentes abiertos y cerrados Fuente: Elaboración propia Descripción:. Razones:. Responsable de la. Incidentes abiertos y cerrados Los incidentes abiertos y cerrados indican aquellos incidentes a los que se les identificó una causa raíz, a éstos últimos se les considera cerrados una vez que aplican la acción correctiva sobre dicha causa raíz conocida. Conocer los incidentes abiertos y cerrados permite:  Cambiar la estrategia de ataque ante los incidentes masivos.  Analizar los incidentes masivos sin causa raíz conocida con detalle.  Identificar los posibles escalamientos a Gestión de Problemas.  Tomar acciones correctivas con aquellos incidentes masivos abiertos.  Llevar un registro de solución de los incidentes cerrados, Gestor de Incidentes. Administración:   . Frecuencia:. Unidad de Medida Elementos de los Datos. Aplica: Método. Semanal Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número tickets tipo incidente. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta) Tickets provenientes de fallas masivas con y sin causa raíz.. de. Tablas y gráficos dinámicos en la herramienta Microsoft Excel.. la. Cantidad de incidentes masivos abiertos y cerrados a la fecha.. Cálculo: Resultado. de. Medida:. Anexo 48: Ficha técnica de incidentes abiertos y cerrados por servicio Fuente: Elaboración propia. Descripción:. Razones:. Incidentes abiertos y cerrados por servicio Los incidentes abiertos y cerrados por servicio indican aquellos incidentes a los que se les identificó una causa raíz por servicio afectado, a éstos últimos se les considera cerrados una vez que aplican la acción correctiva sobre dicha causa raíz conocida. Conocer los incidentes abiertos y cerrados por servicio permite:  Cambiar la estrategia de ataque ante los incidentes masivos.  Analizar los incidentes masivos sin causa raíz conocida con detalle.  Identificar los posibles escalamientos a Gestión de Problemas.  Tomar acciones correctivas con aquellos incidentes masivos abiertos.  Identificar los servicios afectados con más frecuencia y prestarles la urgida y debida atención.. 33.

(38) Responsable de la.  Llevar un registro de solución de los incidentes cerrados, Gestor de Incidentes. Administración:   . Frecuencia:. Unidad de Medida Elementos de los Datos. Aplica: Método. Semanal Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número tickets tipo incidente. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta) Tickets provenientes de fallas masivas con y sin causa raíz.. de. Tablas y gráficos dinámicos en la herramienta Microsoft Excel.. la. Cantidad de incidentes masivos abiertos y cerrados a la fecha por servicio afectado.. Cálculo: Resultado. de. Medida:. Anexo 49: Ficha técnica de incidentes por área solucionadora Fuente: Elaboración propia. Descripción:. Razones:. Responsable de la. Incidentes por área solucionadora Los incidentes por área solucionadora indican las áreas que se encuentran desarrollando planes de acción para poder resolver el incidente que se está presentando. Conocer los incidentes por área solucionadora permite:  Llevar un control de la naturaleza de los incidentes y qué área se adapta mejor a ella.  Realizar seguimiento conociendo ya la guardia solucionadora pertinente.  Tomar acciones correctivas.  Tomar acciones preventivas. Gestor de Incidentes. Administración:   . Frecuencia:. Unidad de Medida Elementos Datos. de. los. Semanal Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número tickets tipo incidente. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. 34. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de.

(39) la información vaciada en los campos de dicha herramienta) Aplica:. Tickets provenientes de fallas masivas.. Método de Cálculo:. Tablas y gráficos dinámicos en la herramienta Microsoft Excel.. Resultado. Cantidad de incidentes masivos atendidos por área solucionadora.. de. la. Medida:. Anexo 50: Ficha técnica de MTTR (Medium Time To Repair) Fuente: Elaboración propia. Descripción: Razones:. Responsable de la. MTTR (Medium Time To Repair) El MTTR indica el tiempo promedio que le toma a una área solucionadora resolver o reparar una falla o incidente. Conocer el MTTR permite:  Conocer la relación existente entre las horas de parada y las paradas totales.  Tomar acciones correctivas.  Tomar acciones preventivas. Gestor de Incidentes. Administración:   . Frecuencia:. Semanal Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos.. Unidad de Medida. Tiempo.. Elementos de los. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Datos. Aplica:. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). Tickets provenientes de fallas masivas.. Método de Cálculo:. Resultado. de. Se aplica la siguiente fórmula considerando el tiempo de parada y el tiempo base dependiendo del mes en curso (24 horas * 28 días (febrero)/30 días/31días): 𝐻𝑜𝑟𝑎𝑠 𝑡𝑜𝑡𝑎𝑙𝑒𝑠 𝑑𝑒 𝑝𝑎𝑟𝑎𝑑𝑎 𝑀𝑇𝑇𝑅 = 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑝𝑎𝑟𝑎𝑑𝑎𝑠 la Tiempo promedio en resolver las fallas.. Medida:. Anexo 51: Ficha técnica de MTBF (Mean Time Between Failures) Fuente: Elaboración propia Descripción:. MTBF (Mean Time Between Failures) El MTBF indica el tiempo transcurrido entre falla y falla.. 35.

(40) Razones:. Responsable de la. Conocer el MTBF permite:  Conocer la relación existente entre las horas totales del período y las paradas totales.  Tomar acciones correctivas.  Tomar acciones preventivas. Gestor de Incidentes. Administración:   . Frecuencia:. Semanal Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos.. Unidad de Medida. Tiempo.. Elementos de los. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Datos. Aplica:. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). Tickets provenientes de fallas masivas.. Método de Cálculo:. Resultado. de. Se aplica la siguiente fórmula considerando el tiempo de parada y el tiempo base dependiendo del mes en curso (24 horas * 28 días (febrero)/30 días/31días): 𝐻𝑜𝑟𝑎𝑠 𝑡𝑜𝑡𝑎𝑙𝑒𝑠 𝑑𝑒 𝑝𝑒𝑟í𝑜𝑑𝑜 𝑀𝑇𝑇𝑅 = 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑝𝑎𝑟𝑎𝑑𝑎𝑠 la Tiempo entre falla y falla.. Medida:. Anexo 52: Ficha técnica de problemas abiertos Fuente: Elaboración propia Descripción: Razones:. Responsable de la. Antigüedad de problemas abiertos La antigüedad de problemas abiertos indica la cantidad de los mismos sobre los cuales hay que enfocarse para su solución. Conocer la antigüedad de los problemas abiertos permite:  Tener una vista global de los problemas sobre los cuales hay que generar mesas de trabajo para poder identificar su respectiva causa raíz.  Generar prioridades a la hora de atender problemas debido al tiempo que lleven éstos sin causa raíz identificada.  Tomar acciones correctivas.  Tomar acciones preventivas. Gestor de Problemas. Administración: Frecuencia:. Unidad de Medida.   . Semanal Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número de tickets tipo incidente.. 36.

(41) Elementos de los Datos. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). Aplica:. Tickets provenientes de fallas masivas.. Método de Cálculo:. Tablas y gráficos dinámicos en la herramienta Microsoft Excel.. Resultado. Antigüedad de problemas sin causa raíz identificada.. de. la. Medida:. Anexo 53: Ficha técnica de problemas por estatus Fuente: Elaboración propia. Descripción: Razones:. Responsable de la. Problemas por estatus En él se indica la cantidad de problemas que se encuentran en un mismo estatus hasta la fecha. Conocer el estatus de los problemas permite:  Realizar seguimiento a aquellos que no estén cerrados.  Tener una vista global de los problemas sobre los cuales hay que generar mesas de trabajo para poder identificar su respectiva causa raíz.  Generar prioridades a la hora de atender problemas debido al tiempo que lleven éstos sin causa raíz identificada.  Tomar acciones correctivas. Gestor de Problemas. Administración:   . Frecuencia:. Semanal Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número de tickets tipo incidente.. Unidad de Medida Elementos de los Datos. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). Aplica:. Tickets provenientes de fallas masivas.. Método de Cálculo:. Tablas y gráficos dinámicos en la herramienta Microsoft Excel.. Resultado. Cantidad de problemas existentes por estatus.. de. la. Medida:. 37.

(42) Anexo 54: Ficha técnica por estatus de área solucionadora Fuente: Elaboración propia Descripción: Razones:. Responsable de la. Estatus por área solucionadora Este indicador señala el estatus que tienen las áreas solucionadoras involucradas en la mesa de trabajo de un problema dado. Conocer la antigüedad de los problemas abiertos permite:  Realizar seguimiento para conocer el estatus de los planes de acción.  Realizar con más frecuencia mesas de trabajo en donde se planteen nuevos diagnósticos y soluciones.  Tomar acciones correctivas. Gestor de Problemas. Administración:   . Frecuencia:. Semanal Mensual Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número de tickets tipo incidente.. Unidad de Medida Elementos de los Datos. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). Aplica:. Tickets provenientes de fallas masivas.. Método de Cálculo:. Tablas y gráficos dinámicos en la herramienta Microsoft Excel.. Resultado. Estatus de las áreas solucionadoras.. de. la. Medida:. Anexo 55: Ficha técnica de estatus por tipo de incidencia Fuente: Elaboración propia. Descripción: Razones:. Responsable de la. Estatus por tipo de incidencia Este indicador señala el estatus dependiendo del tipo de incidencia producida. Conocer el estatus por tipo de incidencia permite:  Realizar seguimiento para conocer el estatus de los planes de acción.  Plantear nuevas soluciones y análisis dependiendo del desarrollo de las incidencias.  Tomar acciones correctivas. Gestor de Problemas. Administración: Frecuencia:.  . Semanal Mensual. 38.

(43) . Nota: La información de los tickets varía minuto a minuto, es por ello que semanal y mensualmente se deben descargar nuevamente los datos. Número de tickets tipo incidente.. Unidad de Medida Elementos de los Datos. Datos Información general referente a los RFC provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta). Aplica:. Tickets provenientes de fallas masivas.. Método de Cálculo:. Tablas y gráficos dinámicos en la herramienta Microsoft Excel.. Resultado. Estatus de las incidencias.. de. la. Medida:. Anexo 56: Ficha técnica de tiempo promedio de grupo solucionador Fuente: Elaboración propia Descripción:. Razones:. Responsable de la. Tiempo promedio de grupo solucionador El tiempo promedio del grupo solucionador indica gráficamente el tiempo que le toma a las áreas solucionadoras diagnosticar y resolver una falla relacionada con el enlace o servidor de una tienda, del CENDIS o de la oficina corporativa. Conocer el tiempo promedio de grupo solucionador permite:  Conocer el área que tiene mayor responsabilidad a la hora de resolver incidencias de enlace o servidores.  Tener un posible diagnóstico al momento de presentarse un incidente con síntomas parecidos.  Tomar acciones correctivas.  Tomar acciones preventivas. Coordinador de Monitoreo y Plataforma TI. Administración: . Frecuencia:. Mensual. Unidad de Medida. Tiempo de solución.. Elementos de los. Datos Información general referente a los incidentes de enlace o servidores provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Aplica:. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta) Tickets categorizados como incidentes con reportes de fallas en enlaces y servidores.. Método de Cálculo:. Tablas y gráficos dinámicos en la herramienta Microsoft Excel.. Resultado. Cantidad de tiempo en formato hh:mm que les toma a las áreas solucionadoras diagnosticar y resolver un incidente relacionado con fallas en los enlaces o servidores.. Datos. Medida:. de. la. 39.

(44) Anexo 57: Ficha técnica de tiempo de respuesta de proveedor Fuente: Elaboración propia Descripción:. Razones:. Responsable de la. Tiempo de respuesta de proveedores El tiempo de respuesta de los proveedores indica gráficamente el tiempo que le toma a los proveedores de servicio diagnosticar y resolver una falla relacionada con el enlace o servidor de una tienda, del CENDIS o de la oficina corporativa. Conocer el tiempo de respuesta de los proveedores permite:  Tener en consideración un tiempo promedio de respuesta de los proveedores a la hora de notificar una falla por parte de los analistas.  Que los analistas pulan las técnicas de restablecimiento de enlace (pruebas N1) mientras el proveedor responde al incidente.  Tener un posible diagnóstico al momento de presentarse un incidente con síntomas parecidos.  Tomar acciones preventivas. Coordinador de Monitoreo y Plataforma TI. Administración: . Frecuencia:. Mensual. Unidad de Medida. Tiempo de solución.. Elementos de los. Datos Información general referente a los incidentes de enlace o servidores provenientes de los campos de llenado de los mismos en la herramienta CA Service Desk Management.. Aplica:. Fuente Documental Matriz de datos descargada de la herramienta CA JASPER (aplicativo ligado a CA Service Desk Management que permite llevar un control minucioso de la información vaciada en los campos de dicha herramienta) Tickets categorizados como incidentes con reportes de fallas en enlaces y servidores.. Método de Cálculo:. Tablas y gráficos dinámicos en la herramienta Microsoft Excel.. Resultado. Cantidad de tiempo en formato hh:mm que les toma a los proveedores diagnosticar y resolver un incidente relacionado con fallas en los enlaces o servidores.. Datos. Medida:. de. la. Anexo 58: Ficha técnica de cumplimiento de notificaciones Fuente: Elaboración propia. Descripción:. Razones:. Cumplimiento de notificaciones El cumplimiento de notificaciones indica gráficamente cuáles analistas cumplieron con el proceso de seguimiento y observación a la falla presentada tanto a las áreas solucionadoras como al proveedor. Conocer el cumplimiento de notificaciones permite:  Conocer el nivel de eficiencia y compromiso de los analistas con las fallas presentadas.  Evaluar a los analistas en sus objetivos semestrales.  Tener un posible diagnóstico al momento de presentarse un incidente con síntomas parecidos.  Tomar acciones preventivas.. 40.