unidad profesional interdisciplinaria de ... -...
TRANSCRIPT
INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS
“DISEÑO Y MODELADO DE PROCESOS DENTRO DE LAS MEJORES PRÁCTICAS BASADO EN ITIL”
INFORME DE PRÁCTICA PROFESIONAL
QUE PARA OBTENER EL TÍTULO DE L I C E N C I A D A E N C I E N C I A S D E L A I N F O R M Á T I C A
P R E S E N T A
BRISA SARAI GONZÁLEZ GARCÍA
MÉXICO D.F. 2009
ÍNDICE
RESUMEN………………………………………………………………………………………………. i
INTRODUCCIÓN……………………………………………………………………………………….. ii
CAPITULO 1. DESCRIPCIÓN BREVE DE LA EMPRESA 1.1 GENERALIDADES DE LA EMPRESA………………………………………………………….. 1
1.2 GENERALIDADES DE LA DIRECCIÓN DE TECNOLOGÍA Y OPERACIONES………….. 2
CAPITULO 2. ANÁLISIS DE LA DOCUMENTACIÓN EXISTENTE Y LA METODOLOGÍA DE ITIL 2.1 ¿Qué es ITIL?........................................................................................................................ 3
2.2 ANÁLISIS DE BRECHAS ACTUALES VS ITIL…………………………………………………. 6 2.2.1 Gestión de Incidentes……………………………………………………………………………. 6 2.2.2 Gestión de Mesa de Ayuda…………………………………………………………………….. 7 2.2.3 Gestión de Problemas………………………………………………………………………….. 9 2.2.4 Gestión de Cambios…………………………………………………………………………….. 10
2.3 DOCUMENTACIÓN DE LOS PROCESOS INTEGRADOS A LAS MEJORES PRÁCTICAS DE ITIL………………………………………………………………………………….. 11 2.3.1 Proceso de Gestión de Incidencias……………………………………………………………. 11 2.3.2 Proceso de Mesa de Ayuda……………………………………………………………............ 12 2.3.3 Proceso de Gestión de Problemas..................................................................................... 13 2.3.4 Proceso de Gestión de Cambios……………………………………………………………….. 15
2.4 DISEÑO DE ESTRUCTURAS DE LOS PROCESOS………………………………………….. 16 2.4.1 Gestión de Incidencias…………………………………………………………………………. 16 2.4.2 Mesa de Ayuda………………………………………………………………………………….. 16 2.4.3 Gestión de Problemas………………………………………………………………………….. 16 2.4.4 Gestión de Cambios……………………………………………………………………………. 16
2.5 PROCESO DE GESTIÓN DE INCIDENCIAS…………………………………………………... 16 2.5.1 Objetivo…………………………………………………………………………………………… 16 2.5.2 Alcance…………………………………………………………………………………………… 16 2.5.3 Responsables……………………………………………………………………………………. 16 2.5.4 Secuencia de Eventos………………………………………………………………………….. 17 2.5.5 Procedimiento…………………………………………………………………………………….. 17
2.6 LINEAMIENTOS DE LA GESTIÓN DE INCIDENCIAS………………………………………… 21 2.6.1 Sobre las Terminologías Comunes…………………………………………………………… 21 2.6.2 Asignación de las Incidencias…………………………………………………………………. 22
2.7 POLÍTICAS DE GESTIÓN DE INCIDENCIAS…………………………………………………. 23
2.8 ESTÁNDARES DE LA GESTIÓN DE INCIDENCIAS………………………………………… 24 2.8.1 ATENCIÓN DE INCIDENCIAS………………………………………………………………… 24 2.8.2 WORKAROUNDS……………………………………………………………………………….. 26
2.9 ESTABLECIMIENTO DE UN REPOSITORIO DE DOCUMENTOS DE SOPORTE……….. 29
2.10 PROCESO DE LA MESA DE AYUDA………………………………………………………….. 29 2.10.1 Objetivo………………………………………………………………………………………….. 29 2.10.2 Alcance………………………………………………………………………………………….. 29 2.10.3 Responsabilidades…………………………………………………………………………….. 29 2.10.4 Secuencia de Eventos…………………………………………………………………………. 29 2.10.5 Procedimiento…………………………………………………………………………………… 30
2.11 LINEAMIENTOS DE LA MESA DE AYUDA…………………………………………………… 32
2.12 POLÍTICAS DE LA MESA DE AYUDA…………………………………………………………. 34
2.13 ESTÁNDARES DE GESTIÓN DE LA MESA DE AYUDA……………………………………. 38 2.13.1 RFC (Request For Change) ó Solicitud Formal de Cambio………………………………. 38 2.13.2 SLA (Service Level Agreement) o Acuerdo de Nivel de Servicio…………………………. 40
CAPITULO 3. ELECCIÓN DE SERVICE DESK 3.1 EVALUACIÓN DE OPCIONES DE SERVICE DESK………………………………………….. 42
3.2 CARACTERÍSTICAS DE LA OPCIÓN ELEGIDA………………………………………………. 45
CAPITULO 4. MÉTRICAS DE EVALUACIÓN DE LOS NIVELES DE MADUREZ DE LOS PROCESOS DE ITIL 4.1 ¿QUÉ ES EL CMMI?............................................................................................................. 49
4.2 EVALUACIÓN DE LOS NIVELES DE MADUREZ PARA LOS DIFERENTES PROCESOS……………………………………………………………………………………………... 53
CAPITULO 5. IMPLEMENTACIÓN DE LA MESA DE AYUDA 5.1 INSTALACIÓN……………………………………………………………………………………… 54
5.2 CONFIGURACIÓN…………………………………………………………………………………. 54
5.3 CAPACITACIÓN……………………………………………………………………………………. 56
5.4 PRUEBA PILOTO………………………………………………………………………………….. 56 5.4.1 Creación de un Caso…………………………………………………………………………….. 57 5.4.2 Cerrar un Caso…………………………………………………………………………………… 60
5.5 PLAN DE COMUNICACIÓN DE LA MESA DE AYUDA A LAS ÁREAS USUARIAS………. 62
CONCLUSIÓN…………………………………………………………………………………………... 64
BIBLIOGRAFÍA…………………………………………………………………………………………. 65
ANEXOS Anexo I Diagrama de Gestión de Incidencias………………………………………………………. 66 Anexo II Diagrama de Gestión de Mesa de Ayuda………………………………………………… 67 Anexo III Diagrama de Gestión de Problemas……………………………………………………… 68 Anexo IV Diagrama de Gestión de Cambios………………………………………………………… 69 Anexo V Estándar de Atención de Incidencias…………………………………………………….. 70 Anexo VI Estándar de Workaround…………………………………………………………………… 71 Anexo VII Estándar de Solicitud Formal de Cambios RFC………………………………………... 72 Anexo VIII Estándar de Acuerdos de Niveles de Servicio SLA…………………………………… 75 Anexo IX Estándar de Evaluación de Procesos……………………………………………………. 76 Anexo X Pancarta Informativa Mesa de Ayuda…………………………………………………….. 85 Anexo XI Tarjeta Individual Mesa de Ayuda…………………………………………………………. 86
i
RESUMEN
Actualmente no se puede hablar de Calidad en las organizaciones que presumen de una área de
Tecnología Informática competente, sin hablar de ITIL; la Gestión de Servicios de TI más
ampliamente aceptada en el mundo, ya que provee un conjunto de Mejores Prácticas para adoptar
y adaptar a cualquier organización de cualquier tipo y giro.
En los últimos años esta corriente ha permitido dirigir las actividades, servicios y procedimiento de
TI, enfocándolas a la entrega de Servicios, principalmente en la elaboración de documentación que
acredite o haga constancia de que se realizaron. Lo cual abre un sinfín de posibilidades para que
las empresas desarrollen e implementen herramientas que permitan hacer más fácil dicha
documentación.
Es por eso que TTD Group, decidió alinear sus procesos tanto internos como servicios a usuarios a
la Metodología de ITIL, desarrollando el presente proyecto, llamado Diseño y Modelado de
Procesos dentro de las Mejores Prácticas Basado en ITIL, el cual en primera fase requirió de un
análisis de brechas existentes entre lo que se realizaba y lo que debiera realizarse, para después
empezar con la elaboración de procedimientos, lineamientos, políticas y estándares que normen
dichos servicios. Y así terminar con la implementación de la Mesa de Ayuda, la principal Gestión en
la entrega de Servicios de Tecnología Informática.
Logrando así la normalización de procesos y la centralización, documentación y medida de los
incidentes y las soluciones que se logren dentro de la atención a usuarios, principal función de
cualquier área de Tecnología Informática, que se preocupe por prestar Soporte Técnico a sus
empleados, con calidad mundial.
ii
INTRODUCCIÓN
Hoy en día es de vital importancia para todas las organizaciones el contar con Metodologías que
avalen y rijan sus procesos y servicios de Tecnología Informática, alineándose a las más
prestigiadas prácticas, haciendo así frente a la gran competitividad que existe en el mercado.
Sin embargo TTD Group ha estado posicionada en la industria de Tecnologías de Información por
más de 6 años sin que se norme bajo una Gestión Integral de Servicios, siendo está una
deficiencia ante la creciente demanda y dependencia de servicios informáticos de calidad que
correspondan con los objetivos del negocio y que satisfagan los requerimientos y expectativas de
los clientes.
Resultando muy atrayente integrarse a la revolucionaria corriente que propone ITIL, la Biblioteca
de Infraestructura de Tecnologías de la Información, por ser el estándar mundial de facto en la
Gestión de Servicios Informáticos.
Es por eso que el presente trabajo se enfocó principalmente en una revisión del concepto general
de ITIL, sus alcances y limitantes, para de esta manera establecer un marco que coincidiera con
las actividades que se realizan dentro de la empresa y así empezar a abarcar cada una de las
Gestiones resultantes.
Una vez que se determinaron las Gestiones de ITIL a implementarse en TTD Group, se procedió a
la búsqueda de brechas entre la situación real con las propuestas por la metodología, para
encontrar así los puntos débiles de cada uno y atacarlos en base a la elaboración de Políticas que
normalizaran los servicios, comprendieran las metas y objetivos a alcanzar por la Gestión,
procedimientos que regularan los pasos para llevar a cabo dichos servicios, lineamientos que
establecieran el marco teórico de cómo implementar el procedimiento y por último los estándares
que regularan la dirección para lograr las políticas establecidas.
Después de realizar, revisar y autorizar toda esta documentación, se continuó con la elaboración
de diagramas que permitieran entender en forma visual como se realizarán los procesos,
basándose siempre en los marcos de referencias de la metodología seleccionada.
Concluidas las etapas de documentación se continuó con una evaluación de estas Gestiones,
teniendo como referencia el Modelo de Capacidad y Madurez CMMI, otro marco de mejores
prácticas basado en modelos que comparan mediante niveles el grado de madurez en que los
procesos se llevan a cabo en las organizaciones y el grado en que consiguen los objetivos
establecidos para los mismos. Esta evaluación permitió identificar el nivel en que se encontraban
las gestiones cuando se inicio el proyecto y cuanto avance se logro una vez que se alinearon a las
propuestas de ITIL. Y también determinar cual es el nivel deseado a futuro con la completa
iii
implementación de herramientas automatizadas que ayuden en el logro de servicios de alta
calidad.
Por último se llevo a cabo una búsqueda de proveedores que ofrecieran productos de software
alineados a ITIL y que cubrieran las Gestiones de Incidentes, Cambios, Problemas y
principalmente la Mesa de Ayuda.
Cubriendo así la desventaja competitiva con la que se encontraba operando la Dirección de
Tecnología y Operaciones.
1
CAPITULO 1. DESCRIPCIÓN BREVE DE LA EMPRESA.
1.1 GENERALIDADES DE LA EMPRESA.
Antecedentes
TTD Gruop TRADING TECHNOLOGIES DEVELOPMENT, surgió como una compañía en el ámbito
de las tecnologías de la información, orientada a proporcionar atención integral y personalizada a
las necesidades de cambio de las empresas, comprendiendo desde el diagnóstico de áreas de
mejora hasta la implementación de soluciones, TTD Group asume el compromiso de los clientes,
para garantizar un alto nivel de calidad y desempeño, coadyuvando así a que la empresa
aprovechen al máximo las oportunidades de negocio que se les presenten y otorgando valor
adicional a sus inversiones realizadas.
Misión
Superar las expectativas de satisfacción de nuestros clientes en atención a sus necesidades dentro
del ámbito de las tecnologías de información, mediante soluciones integrales de alta calidad,
implementadas con tecnología de punta y personal altamente calificado.
Visión
Ser reconocida como la empresa líder en el mercado de las tecnologías de información, con base a
las soluciones y a la satisfacción que se brinde a nuestros clientes.
Servicios
TTD Group brinda la mejor solución a las necesidades sus clientes, adecuándose a los recursos de
la empresa del cliente, los principales servicios que brinda son los siguientes:
• Outsourcing: Recursos humanos en Outsourcing y Manpower, mediante consultores
altamente calificados, que ayudan a la implementación, operación y administración de
sistemas, procesos y equipos con los que operan las empresas de los clientes.
• Sistemas: Análisis, evaluación, desarrollo e implementación de sistemas de información,
acordes al tamaño y necesidades de la empresa. Sistemas Ejecutivos de Información,
Sistemas Administrativos, Sistemas de Control y Monitoreo, Sistemas Cliente Servidor,
Sistemas Basados en Tecnología Web.
• Soporte Técnico: Venta, instalación, Soporte Técnico y Mantenimiento a equipos y
sistemas de cómputo y telecomunicaciones.
2
• Infraestructura: Implementación de infraestructura para redes de voz y datos,
conmutadores telefónicos y sistemas de voz sobre IP (Instalaciones internas, cableado
estructurado, redes inalámbrica).
• Capacitación: Desarrollo e impartición de cursos de capacitación, acordes a las
necesidades tecnológicas de los clientes.
1.2 GENERALIDADES DE LA DIRECCIÓN DE TECNOLOGÍA Y OPERACIONES
La Dirección de Tecnología y Operaciones de TTD Group, actúa como una entidad que norma
criterios y apoyo a la toma de decisiones de TI a las diversas áreas que conforman la empresa.
Es la encargada de proporcionar la infraestructura, sistemas y servicios tecnológicos para que los
empleados de la empresa puedan realizar sus actividades apoyados en las mejores tecnologías y
medios disponibles.
Adicional a lo anterior, funge como área de servicio de TI para la empresa, encargándose de
atender requerimientos y solucionar los problemas que se presentan.
La estructura de esta Dirección está conformada por 7 personas que reportan en forma directa a
esta Dirección.
3
CAPITULO 2. ANÁLISIS DE LA DOCUMENTACIÓN EXISTENTE Y LA METODOLOGÍA DE ITIL.
2.1 ¿QUE ES ITIL?
ITIL (Information Technology Infrastructure Library) es una metodología desarrollada a finales de
1980, la Biblioteca de Infraestructura de Tecnologías de la Información, su nombre en español, se
ha convertido en el estándar mundial de facto en la Gestión de Servicios Informáticos. Iniciado
como una guía para el gobierno del Reino Unido, la estructura base ha demostrado ser útil para las
organizaciones en todos los sectores a través de su adopción por innumerables compañías como
base para consulta, educación y soporte de herramientas de software. Hoy, ITIL es conocido y
utilizado mundialmente. Pertenece a la OGC (Open Geospatial Consortium), pero es de libre
utilización.
ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de la
Informática para alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como
resultado una necesidad creciente de servicios informáticos de calidad que se correspondan con
los objetivos del negocio, y que satisfagan los requisitos y las expectativas del cliente. A través de
los años, el énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la gestión de
servicios TI.
A lo largo de todo el ciclo de los productos TI, la fase de operaciones alcanza cerca del 70-80% del
total del tiempo y del costo, y el resto se invierte en el desarrollo del producto (u obtención). De
esta manera, los procesos eficaces y eficientes de la Gestión de Servicios TI se convierten en
esenciales para el éxito de los departamentos de TI. Esto se aplica a cualquier tipo de
organización, grande o pequeña, pública o privada, con servicios TI centralizados o
descentralizados, con servicios TI internos o suministrados por terceros. En todos los casos, el
servicio debe ser fiable, consistente, de alta calidad, y de coste aceptable.1
ITIL en sus inicios constaba de 10 libros centrales cubriendo las dos principales áreas de Soporte
del Servicio y Prestación del Servicio. Estos libros centrales fueron más tarde soportados por 30
libros complementarios que cubrían una numerosa variedad de temas, desde el cableado hasta la
gestión de la continuidad del negocio. A partir del año 2000, se acometió una revisión de la
biblioteca. En esta revisión, ITIL ha sido reestructurado para hacer más simple el acceder a la
información necesaria para administrar sus servicios. Los libros centrales se han agrupado en dos,
cubriendo las áreas de Soporte del Servicio y Prestación del Servicio, en aras de eliminar la
1 http://www.itil-officialsite.com/home/home.asp
4
duplicidad y mejorar la navegación. El material ha sido también actualizado y revisado para un
enfoque conciso y claro.
ITIL como metodología propone el establecimiento de estándares que nos ayuden en el control,
operación y administración de los recursos (ya sean propios o de los clientes). Plantea hacer una
revisión y reestructuración de los procesos existentes en caso de que estos lo necesiten (si el nivel
de eficiencia es bajo o que haya una forma más eficiente de hacer las cosas), lo que nos lleva a
una mejora continua.
Otra de las cosas que propone es que para cada actividad que se realice se debe de hacer la
documentación pertinente, ya que esta puede ser de gran utilidad para otros miembros del área,
además de que quedan asentados todos los movimientos realizados, permitiendo que toda la
gente esté al tanto de los cambios y no se tome a nadie por sorpresa.
ITIL no es un estándar, sino un conjunto de mejores prácticas que se debe adaptar para resolver
las necesidades específicas de una organización, se divide en:
Imagen 1.Fundamentos de la Metodología de ITIL
Soporte a Servicios:
Se centra en asegurar que el cliente tiene acceso a los servicios adecuados para soportar las
funciones de negocio. Los puntos que incluye son Mesa de Servicio o Ayuda, Gestión de
Incidentes, Gestión de Problemas, Gestión de la Configuración, Gestión de Cambios y Gestión de
la Difusión.
También cubre las interacciones necesarias entre estas y otra disciplinas fundamentales de la
Gestión de Servicios, y actualiza las mejores prácticas para reflejar los cambios recientes en la
tecnología y las prácticas de negocio.
5
Prestación de Servicios
Es el segundo elemento de la reestructuración de los procesos de ITIL. Los proveedores de
servicios deben ofrecer a los usuarios un adecuado soporte, la entrega de servicios cubre todos los
aspectos que se deben tener en cuenta. El propósito de la entrega de servicios es mostrar los
vínculos y las principales relaciones entre todos los procesos de gestión de servicios y de
infraestructura.
Los procesos que trata son: Gestión de los Niveles de Servicio, Gestión de la Capacidad, Gestión
Financiera de los Servicios IT, Gestión de la Continuidad, Gestión de la Disponibilidad, Gestión de
las Relaciones con el Cliente.
La Perspectiva de Negocio
Presta atención al conocimiento de la provisión de servicios IT.
Procesos tratados en esta publicación: Gestión de la Continuidad de Negocio, Outsourcing y
Asociaciones, Sobrevivir a los Cambios y Transformación de las Prácticas de Negocio a través del
cambio radical, Comprensión y Mejora.
Gestión de la infraestructura
La Gestión de la Infraestructura cubre la Gestión del Servicio de Red, la Gestión de las
Operaciones, la Gestión de los Procesadores Locales, la Aceptación e Instalación de los
Ordenadores y por primera vez, la Gestión de los Sistemas.
Cubre el ciclo de vida del desarrollo de Software, expandiendo los asuntos tratados en el soporte
del ciclo de vida del software y en las pruebas de los servicios IT. También da más detalles sobre
los Cambios de Negocios con el énfasis puesto en la clara definición de requisitos y la
implementación de soluciones.2
2 Manual ITIL Service Management
TTD G
proces
proces
• • • •
Esto p
fin de
cumpli
2.2 A
2.2.1
El sigu
Tecnol
define
metodo
ModeGes
Incide
Group se bas
sos de Tecn
sos de:
Mesa de SeGestión de Gestión de Gestión de
or motivos de
poder imple
miento de la
ANÁLISIS
Gestión
uiente cuadro
logía y Opera
una “brecha
ología ITIL.
elo de stión
ncias •
Imagen
sará en el an
ología Inform
ervicio Incidencias Problemas Cambios
e tener bien d
ementar el
atención a los
S DE BRE
de Incid
muestra las d
aciones de T
a” que deber
A
El personal
n 2. Metodologí
nterior mode
mática, enfoc
definidos los
uso de algu
s usuarios.
ECHAS AC
entes
diferencias qu
TTD Group v
rá cerrarse p
D
ACTUAL
ejecuta los
ía de ITIL a segu
lo de ITIL, p
cándose en
procedimient
una herramie
CTUALES
ue existen en
s el modelo
para complet
Diferencias D
s servicios
uir en TTD Grou
para aplicar l
la primera f
tos para aten
enta de Help
S VS ITIL
ntre la operac
de Gestión “
ar el proces
Detectadas
• Recibe y
up
as mejores p
fase, principa
nción a los us
p Desk, que
L
ción actual de
“Incidencias”,
o de implem
ITIL
y registra las
prácticas a s
almente en
suarios y con
e ayude en
la Dirección
, con lo que
mentación de
s solicitudes d
6
sus
los
n el
el
de
se
la
de
7
únicamente en base a su nivel de experiencia.
• El personal de tecnología y operaciones en su caso, elabora una propuesta de solución para resolver el requerimiento del usuario y la consulta con sus compañeros antes de aplicarla.
• El personal encargado de atender el servicio del usuario aplica la propuesta de solución que en algunos casos no garantiza que el requerimiento del usuario haya sido cerrado.
• El personal encargado de atender el servicio del usuario en caso de tener problemas solicita del apoyo de otro compañero del área con mayor nivel de experiencia.
• El personal atiende los servicios de manera directa sin analizar su impacto.
• El personal de tecnología y operaciones ejecuta en ocasiones los servicios por intervalos de atención, dejando actividades pendientes para cerrar estos servicios.
• El personal de temas realiza los servicios sin una documentación de control que ayude a futuros servicios.
servicio de los usuarios con base en las prioridades establecidas por el área de tecnología y operaciones.
• Documenta la información necesaria para la correcta atención del servicio identificando el origen del problema reportado por el usuario.
• Escala y asigna la atención de las Incidencias de servicio al personal del área de tecnología y operaciones en base al nivel de servicio (SLA).
• Monitorea el estatus de la atención del servicio desde su asignación hasta su finalización y cumplimiento.
• Documenta la solución ejecutada para futuras consultas y crear estándares.
• Cierra los reportes de cada requerimiento del usuario, verificando los resultados derivados de la atención del servicio.
• Realiza estadísticas del cumplimiento de los niveles de servicio (SLA) con base en las métricas previamente definidas.
• Evalúa las incidencias reportadas para determinar su probabilidad de recurrencia e identificar en su caso, cuando corresponda a un problema crítico.
• Realiza los “Workarounds” con la finalidad de no interrumpir la continuidad de las operaciones del usuario, aplica una solución temporal mientras arregla el problema reportado.
• Elabora los Informes de Gestión correspondientes para obtener los indicadores clave de rendimiento.
• Identifica el número y porcentaje de Incidencias atendidas de manera remota, sin necesidad de cubrir el servicio mediante atención personalizada.
2.2.2 Gestión de Mesa de Ayuda El siguiente cuadro muestra las diferencias que existen entre la operación actual de la Dirección de
Tecnología y Operaciones de TTD Group vs el modelo de Gestión Mesa de Ayuda, como se
8
denominará de aquí en adelante, con lo que se define una “brecha” que deberá cerrarse para
completar el proceso de implementación de la metodología ITIL.
Modelo de Gestión
Diferencias Detectadas
Mesa de Ayuda
ACTUAL ITIL • Recepción de solicitudes de
servicio vía telefónica durante todo el horario de labores, por consiguiente el personal de tecnología y operaciones porta un teléfono móvil con su extensión para poder ser localizados.
• Selección del personal disponible en el área de tecnología y operaciones en base a la cantidad de trabajo de cada personaje.
• Interrogatorio al usuario para conocer el problema que reporta.
• Atención personalizada de cada requerimiento del usuario.
• Por excepción brindan al usuario atención telefónica por el problema reportado.
• Los usuarios canalizan sus requerimientos de manera directa con el analista de su preferencia.
• Es el primer contacto con el usuario que solicita los servicios de tecnología.
• Determina la prioridad de las incidencias en base a los nivelas de servicio (SLA) documentados.
• Registra y canaliza las incidencias para brindar el soporte técnico al usuario que requiere un servicio.
• Mantiene comunicación directa entre el usuario y el personal de tecnología y operaciones, verificando que se cumplan con los tiempos estándares.
• Coordina y registra en su caso, el 2º y 3er nivel de atención para el servicio, en base a la experiencia del personal.
• Identifica en base a los servicios solicitados el nivel de capacitación que requieren los usuarios para el mejor uso de los recursos tecnológicos.
• Contribuye a la correcta identificación y clasificación de los problemas por cada servicio que solicita el usuario.
• Emite los informes del comportamiento de la operación de los servicios por parte del personal responsable de la atención de los requerimientos del usuario.
• Asiste en la identificación de nuevas oportunidades de negocio.
• Retiene el control administrativo de la Incidencia levantada por un reporte de servicio.
• Atiende el requerimiento del usuario pero NO es su responsabilidad encontrar la causa que originó el problema.
• Es el modelo que detona las solicitudes de Cambios, Niveles de Servicio, Configuración, Disponibilidad, Continuidad de los servicios de tecnología de manera ordenada.
• Libera al personal del área de tecnología y operaciones de
9
interrupciones telefónicas por requerimientos de usuarios logrando balancear las cargas de trabajo.
• Mantiene una visión global de los modelos de gestión de servicio que se aplican en la organización.
• Educa a los usuarios en el uso del nuevo servicio de atención de requerimientos.
2.2.3 Gestión de Problemas El siguiente cuadro muestra las diferencias que existen entre la operación actual del Dirección de
Tecnología y Operaciones de TTD Group vs el modelo de Gestión “Problemas”, con lo que se
define una “brecha” que deberá cerrarse para completar el proceso de implementación de la
metodología ITIL.
Modelo de Gestión
Diferencias Detectadas
Problemas
ACTUAL ITIL • El personal de tecnología y
operaciones da solución a problemas referentes a equipo de cómputo dañado, para reclamar la garantía con el proveedor correspondiente
• El personal da solución a los problemas que se presenten en oficinas remotas.
• El personal realiza “Análisis Forense” de los problemas, en base a su impacto.
• El personal atiende los requerimientos del usuario a nivel hardware y software en general a 1er y 2º nivel respectivamente con base en su experiencia.
• El personal atiende los requerimientos del usuario para generar los respaldos de información.
• El personal una vez ejecutada la solución del requerimiento reportado espera la retroalimentación del usuario y da seguimiento.
• No se registran las soluciones de los problemas para futuras referencias, ni se documentan los seguimientos a los problemas reportados.
• Asigna los recursos necesarios para la atención de las fallas reportadas con base en la prioridad establecida en los niveles de servicio (SLA).
• Atiende y controla los problemas reportados por los usuarios.
• Controla las fallas presentadas por Incidencias desconocidas identificando su tendencia.
• Documenta las resoluciones definitivas creando los “Workarounds”.
• Realiza estadísticas de acuerdo a los niveles de servicio (SLA), con base en las métricas establecidas.
• Previene que se presenten recurrencias de las incidencias reportadas.
• Analiza el servicio reportado para enfrentarlo de manera reactiva para resolverlo de inmediato y proactiva para buscar la solución raíz del problema.
• Crea informes de gestión sobre la efectividad y rendimiento.
• Archiva las solicitudes de ”Cambios” y verifica que dicho cambio haya solucionado el problema detectado, en su caso.
• Recibe toda la información
10
disponible sobre las Incidencias para su investigación y atención.
• Detona la Gestión de Cambios. • Identifica el nivel de impacto de las
Incidencias y los usuarios involucrados.
• Determina el tiempo en que puede resolverse la Incidencia.
• Atiende los problemas más importantes con el impacto al negocio más alto, en base a los niveles de servicio (SLA).
• Cierra las Incidencias reportadas. • Identifica en base a las Incidencias
el número de personas que deben atenderla para resolverla en los tiempos estándares previamente definidos.
2.2.4 Gestión de Cambios El siguiente cuadro muestra las diferencias que existen entre la operación actual del Dirección de
Tecnología y Operaciones de TTD Group vs el modelo de Gestión “Cambios”, con lo que se define
una “brecha” que deberá cerrarse para completar el proceso de implementación de la metodología
ITIL.
Modelo de Gestión
Diferencias Detectadas
Cambios
ACTUAL ITIL • En este año existe el cambio de
infraestructura de acceso a la red por red inalámbrica.
• El año pasado se realizó un cambio de plataforma de Novell a toda una infraestructura de servicios de (Exchange, file Server, y proxies) migrándose a la plataforma de Microsoft.
• Los cambios se le dan tratamiento de proyecto, llevando un avance de los mismos por las actividades que se realizan en los mismos.
• Define, desarrolla e implanta los cambios necesarios en la organización de tipo tecnológico de forma planeada y programada.
• Informa a la Dirección de tecnología y operaciones los cambios planeados y programados a través de reportes formales de comunicación.
• Determina las prioridades de los cambios que se van a implantar de acuerdo a la planeación definida.
• Determina el impacto midiendo el costo vs beneficio y riesgo de ejecutar el cambio solicitado.
• Justifica y obtiene las aprobaciones correspondientes de acuerdo con el cambio.
• Gestiona, vigila y coordina la implementación de los cambios.
• Valida y cierra los cambios realizados.
• Informa el estatus de los cambios
11
en todo momento. • Asegura la utilización de
procedimientos y métodos estandarizados para la realización eficiente de los cambios.
• Minimiza el impacto de los cambios sobre los recursos necesarios para garantizar la continuidad y calidad del servicio.
• Recurre a las demás áreas involucradas en el cambio para determinar el esfuerzo necesario para lograr su cumplimiento.
• Gestiona la actividad de valoración del cambio para asignarle la categoría correspondiente.
• Coordina el cumplimiento de todas las fases del cambio: Llamada, Apertura, Valoración, Revisión, Aprobación, Planeación, Construcción, Seguimiento y Revisión.
2.3 DOCUMENTACIÓN DE LOS PROCESOS INTEGRADOS A LAS MEJORES PRÁCTICAS DE ITIL.
2.3.1 Proceso de Gestión de Incidencias
Objetivos:
• Atender y controlar eficientemente las fallas de tecnología, reduciendo el impacto generado
por errores físicos y lógicos de los recursos tecnológicos.
• Minimizar la recurrencia de incidencias relacionadas con los recursos físicos y lógicos de
tecnología, para corregir y en su caso mejorar la operación de los recursos tecnológicos.
• Documentar apropiadamente todos los problemas reportados así como sus resoluciones a
fin de que estén disponibles al personal de 1er nivel y 2º nivel.
Alcance:
Todos los servicios de tecnología con base en los niveles de servicios establecidos por la Dirección
de Tecnología y Operaciones, dirigidos a todas las unidades de negocio del TTD Group.
Funciones:
• Recibir y registrar las solicitudes de servicio con base en las prioridades del servicio.
• Documentar la información suficiente para la atención del servicio identificando el
origen del problema.
12
• Escalar y asignar la atención de incidencias de servicio al personal de tecnología
adecuado con base en niveles de servicio establecidos (SLA).
• Monitorear el estatus del servicio, hasta su finalización.
• Documentar apropiadamente la resolución ejecutada.
• Cerrar reportes y verificar los resultados derivados de la atención del servicio
• Realizar estadísticos de niveles de servicio (SLA) con base a las métricas previamente
establecidas.
Entradas: Información de Configuración Requerimiento de servicio (Gestión La Mesa de Ayuda) RFC Registros de la atención de servicio
Procedimientos:
1. Registro de requerimiento servicio (ticket de servicio) 2. Clasificación de Incidencias 3. Workaround 4. Ciclo de vida de la Incidencia 5. Escalamiento de atención del servicio 6. Monitoreo del estatus del servicio 7. Comunicación a clientes del estatus de servicio 8. Cierre de requerimientos de servicio 9. Elaboración de estadísticos y reportes
Salidas:
Reportes de incidencias (Gestión La Mesa de Ayuda) Asignación a (Gestión de Problemas). Estadísticos y reportes de la atención de los servicios periódicos a la Gerencia de Sistemas (Informes de Gestión)
Elementos clave de medición:
Número total de incidencias Tiempos de atención de servicios desde su inicio hasta su resolución y cierre Índices de servicios atendidos Índices de reportes resueltos Índice de reportes no cerrados Índice de Reincidencias (re-trabajos)
2.3.2 Proceso de Mesa de Ayuda
Objetivos:
• Proporcionar un primer contacto entre los usuarios de TTD Group y la Dirección de
Tecnología y Operaciones, facilitando la restauración de los servicios, así como satisfacer
las necesidades en las distintas plataformas tecnológicas.
• Lograr un nivel óptimo de eficiencia en la atención a requerimientos de servicios
manteniendo un enfoque de procesos y procedimientos.
• Emitir informes periódicos derivados de las métricas de atención y nivel de servicios
proporcionados.
• Cumplir con los niveles de servicio establecidos (SLA) para la atención de problemas y
requerimientos, siendo el canal oficial de comunicación entre los usuarios y la Gerencia de
Sistemas.
13
Alcance:
Todos los servicios de tecnología con base en los niveles de servicios establecidos por la Dirección
de Tecnología y Operaciones, dirigidos a todas las unidades de negocio del TTD Group.
Funciones:
• Primer contacto con el usuario para la recepción de incidencias de servicio.
• Determinar la prioridad de las incidencias y canalizarlas hacia el soporte técnico
adecuado.
• Mantener la comunicación entre el usuario y el personal de soporte técnico con base
en el estatus del avance del servicio.
• Comunicar los cambios programados en atención al servicio
• Coordinar y registrar en su caso, el soporte de segundo y tercer nivel con base al nivel
de atención del servicio.
• Proporcionar recomendaciones básicas a los usuarios para el mejor uso de los
recursos tecnológicos.
• Identificar las necesidades de formación y capacitación de usuarios.
• Contribuir a la correcta identificación de problemas.
• Emitir informes periódicos del comportamiento de la operación del servicio.
Entradas: Solicitudes de servicio (ticket de servicios) Procedimientos:
1.Recepción de llamadas 2.Estructura La Mesa de Ayuda 3.Clasificación de llamadas (requerimiento o incidente) 4.Canalización de la atención del servicio 5.Elaboración de reportes sobre la atención de servicios realizados. 6.Comunicados de mejoras del servicio
Salidas:
Reportes del comportamiento de la atención y resolución de incidencias de servicios (Informes de Gestión). Atención inmediata del reporte (Gestión Incidencias) Escalamiento del reporte (Gestión de Probelmas). Reportes de la operación de la Gerencia de Sistemas con base en los niveles servicios (SLA)
Elementos clave de medición:
Niveles de operación de atención a servicios Comparativos de la situación actual vs. la deseada Elementos cuantitativos de mejoras de atención y resolución del servicios
2.3.3 Proceso de Gestión de Problemas
Objetivos:
• Atender y controlar eficientemente la atención de fallas de tecnología, reduciendo el
impacto generado por errores físicos y lógicos de los recursos tecnológicos.
14
• Minimizar la recurrencia de incidencias relacionadas con los recursos físicos y lógicos de
tecnología, para corregir y en su caso mejorar la operación de los recursos tecnológicos.
• Documentar apropiadamente todos los problemas reportados así como sus resoluciones a
fin de que estén disponibles al personal de 1er nivel y 2º nivel.
• Generar reportes estadísticos y gerenciales sobre la atención a fallas derivados de las
métricas delimitadas por la gestión de problemas.
Alcance:
Todos los servicios de tecnología con base en los niveles de servicios establecidos por la Dirección
de Tecnología y Operaciones, dirigidos a todas las unidades de negocio del TTD Group.
Funciones:
• Asignar los recursos necesarios para la atención de una falla con base en la prioridad
establecida.
• Controlar los problemas con base en incidencias conocidas y reportadas.
• Control de problemas con base en incidencias reportadas cuya causa raíz es
desconocida y dar soluciones permanentes.
• Documentar resoluciones aplicables temporales (workarounds).
• Controlar las errores conocidos generando RFCs para la gestión de Cambios a fin de
eliminar errores conocidos de la infraestructura de tecnología.
• Mantener un bases de datos de conocimiento y errores conocidos y workarounds.
• Publicar los errores conocidos aplicables al proceso de gestión de incidencias
Realizar informes sobre la efectividad y el rendimiento de la Gestión de problemas
para proporcionar esta información a la Dirección y ser utilizados como entrada de
otros procesos.
Entradas: Detalle de incidencias de La Mesa de Ayuda Base Datos de Soluciones Base Datos RFCs
Procedimientos:
1. Control de problemas 2.Control de errores en infraestructura tecnológica 3. Generación de informes
Salidas:
Base Datos (errores conocidos) Actualización Base Datos (RFC) Actualización Base Datos (Workaround) Información de gestión Gestión La Mesa de Ayuda
Elementos clave de medición:
Cantidad de RFCs surgidas. El índice de impacto de las RFCs en la disponibilidad y fiabilidad de los servicios. Cantidad de tiempo trabajado en diagnósticos con relación a los tipos de problemas por área o unidad de negocio. Cantidad de tiempo trabajado en la investigación con relación a los tipos de problemas por área unidad de negocio. Cantidad de incidencias que ocurren antes de que se cierre el
15
problema de raíz o se confirme un error conocido. Proporción del esfuerzo de soporte inmediato, contra el esfuerzo de soporte programado con base en el escalamiento de problemas. Relación de problemas abiertos vs recursos ocupados en ese problema.
2.3.4 Proceso de Gestión de Cambios
Objetivos:
• Asegurar la utilización de procedimientos y métodos estandarizados para el manejo
eficiente y puntual de todos los cambios.
• Minimizar el impacto de los cambios sobre los recursos necesarios para lograr el cambio y
la aprobación de los cambios sobre la calidad del servicio y la continuidad del negocio.
Alcance:
Todos los servicios de tecnología con base en los niveles de servicios establecidos por la Dirección
de Tecnología y Operaciones, dirigidos a todas las unidades de negocio del TTD Group.
Funciones:
• Definir, desarrollar e implantar los cambios de forma planeada y programada
• Informar a la Dirección de Tecnología y Operaciones os cambios planeados y
programados a través de reportes formales de comunicación.
• Determinar las prioridades de los cambios que se van a realizar de acuerdo a la
planeación definida de cambios.
• Determinar el impacto, costo-beneficio y riesgo de los cambios.
• Justificar y obtener las aprobaciones correspondientes de acuerdo con el cambio.
• Gestionar y coordinar la implementación de los cambios.
• Validar y cerrar los cambios realizados.
• Informar a la Dirección de Tecnología y Operaciones el estado de los cambios
implantados así como aquellos que faltan por implantar.
Entradas: Solicitudes de cambio (RFCs) Base de datos de administración de cambios (CMDB) Programas de cambios
Procedimientos:
1. Levantamiento de RFC 2. Categoría de RFC 3. Valoración de Cambios (Impacto) 4. Ciclo del Cambio 5. Prioridades del Cambio 6. Informes de Gestión
Salidas:
Fechas de implementación de cambios en el Programa adelantado de cambios (FCS) Creación de solicitudades de cambios (RFCs) detallados o
16
ajustados. Minutas de resultados de las acciones implantadas dirigidas al Comité autorizado de cambios . Informes o reportes de gestión de cambios.
Elementos clave de medición:
Numero de cambios implementados en el periodo, por tipo de cambio o servicio. Registro de justificaciones para los cambios Número de cambios realizados con éxito Numero de cambios retrocedidos (evaluación incorrecta, mala construcción, errores inesperados) Número de RFC Comparativos de cifras de periodos anteriores Número de RFCs rechazadas Proporción de cambios implementados que no tuvieron éxito (total y desglosado por CIs) Número de atrasos de cambios, desglosados por CI y por etapa en el proceso de gestión de cambios.
2.4 DISEÑO DE ESTRUCTURAS DE LOS PROCESOS.
2.4.1 Gestión de Incidencias (VER ANEXO I)
2.4.2 Mesa de Ayuda (VER ANEXO II)
2.4.3 Gestión de Problemas (VER ANEXO III)
2.4.4 Gestión de Cambios (VER ANEXO IV)
2. 5 PROCESO DE GESTIÓN DE INCIDENCIAS
2.5.1 Objetivo
Restablecer la operación de los recursos de tecnología en el menor tiempo posible a partir de la
atención y control eficiente de incidentes.
2.5.2 Alcance
Todas las incidencias reportadas desde la Mesa de Ayuda serán atendidas por la Gestión de
Incidentes.
2.5.3 Responsables
La Dirección de Tecnología y Operaciones es responsable de:
17
• Autorizar o negar la aprobación en caso de que exista un incidente de prioridad alta que
conlleve un curso de acción o solución temporal que pueda impactar negativamente sobre
otros sistemas o en los niveles de seguridad y riesgo aceptable.
Son responsabilidades de los roles responsables de la gestión de incidentes:
• Recibir y registrar las incidencias.
• Documentar la información suficiente para la atención del servicio identificando el origen
del problema.
• Escalar y asignar la atención de incidencias de servicio al personal de tecnología adecuado
con base en niveles de servicio establecidos (SLA).
• Documentar apropiadamente la solución ejecutada y la recuperación del incidente.
• Cerrar reportes y verificar los resultados derivados de la atención del servicio.
• Realizar estadísticos de niveles de servicio (SLA) con base en las métricas previamente
establecidas.
• Generar los reportes de gestión correspondientes.
• Alimentar la gestión de incidentes y Retroalimentar al La Mesa de Ayuda.
• Seguimiento de las incidencias y Disparar cambios.
2.5.4 Secuencia de eventos
1. Diagnostico de las incidencias conocidas.
2. Solución, documentación y cierre del incidente.
3. Diagnóstico de incidencias no-conocidas.
4. Primer Escalamiento de la incidencia.
5. Asignación del incidente a soporte de 2º. Nivel.
6. Primer Monitoreo del incidente.
7. Solución, documentación y cierre del incidente escalado al soporte de 2º Nivel.
8. Segundo Escalamiento de la incidencia.
9. Asignación del incidente al soporte del 3er. Nivel.
10. Segundo Monitoreo del incidente.
11. Solución, documentación y cierre del incidente escalado.
12. Escalamiento de incidencias al Proveedor.
13. Monitoreo del incidente a Proveedores.
14. Solución, documentación y cierre del incidente escalado.
2.5.5 Procedimiento
I) Diagnostico de las incidencias conocidas.
18
El operador de La Mesa de Ayuda evalúa la incidencia reportada por el usuario y consulta la base
de datos de incidentes o Workarounds para identificar la posible solución de la incidencia.
II) Solución, documentación y cierre del incidente.
Si la incidencia es conocida, el operador de la Mesa de Ayuda atiende, da solución al
requerimiento del usuario y realiza lo siguiente:
1. Atiende el incidente de acuerdo con la solución conocida en la base de datos de incidentes
o Workarounds.
2. Documenta las actividades realizadas para la solución del incidente en el formato de
atención de incidencia.
3. Cierra el reporte de atención de incidencia (registra la fecha y hora del cierre) y completa el
formato de atención de incidencia.
El operador de la Mesa de Ayuda verifica del formato de atención de incidencias lo siguiente:
1. La hora de fin de atención del incidente.
2. El llenado completo de los campos de datos en el formato de atención de incidencias.
3. El llenado de las actividades realizadas para dar solución a la incidencia.
4. Obtiene la firma de satisfacción del usuario (cuando aplique).
III) Diagnóstico de incidencias no-conocidas.
Si el incidente no corresponde a ningún Workaround conocido pero es posible resolverlo, entonces
el operador de la Mesa de Ayuda atiende al incidente y procede a documentar un nuevo
Workaround encontrando la solución a la incidencia.
El responsable de atender el requerimiento:
1. Atiende el incidente con las actividades de solución inmediatas.
2. Documenta las actividades realizadas en el formato de Workaround para la solución
inmediata del incidente.
3. Documenta en el formato de incidencias la hora de fin de atención del incidente y recibe
del cliente la firma de satisfacción del cliente.
4. Cierra el reporte de atención de incidencias (registra la fecha y hora del cierre) y entrega el
formato de atención de incidencias al responsable de la Mesa de Ayuda debidamente
completado en sus campos de datos.
IV) Primer Escalamiento de la incidencia.
Si el incidente no es resuelto a través de la base de datos de Workarounds conocidos y con el
propósito de cumplir con los tiempos de respuesta definidos en el SLA.
19
V) Asignación del incidente a soporte de 2º. Nivel
El operador de La Mesa de Ayuda
• Asigna el incidente al personal de soporte de 2º nivel correspondiente para su atención de
la siguiente forma de acuerdo a los Lineamientos para el Procedimiento de Gestión de
Incidentes.
• Registra en el formato de requerimiento de servicio (Ticket) la fecha, la hora de inicio, el
tipo de incidente reportado y la prioridad para su atención.
VI) Primer Monitoreo del incidente
El operador del La Mesa de Ayuda:
1. Registra la hora de inicio del incidente escalado al responsable del 2º nivel
2. Informa al usuario el estado de la atención de la incidencia y su posible solución.
3. Monitorea el avance de la incidencia hasta su cierre con base en el tiempo de atención de
escalamiento.
VII) Solución, documentación y cierre del incidente escalado al soporte de 2º Nivel
El responsable de 2o Nivel:
1. Atiende y resuelve el incidente con base en el diagnóstico previamente documentado y en
su conocimiento especializado.
2. Documenta las actividades realizadas en el formato de atención de incidencias para la
solución encontrada del incidente, registra la hora de fin de atención del incidente.
3. Cierra el reporte (registra la fecha y hora del cierre) y entrega el formato de atención de
incidencias al responsable de la Mesa de Ayuda debidamente completado en sus campos
de datos.
El operador de la Mesa de Ayuda recibe el formato de atención de incidencias lo siguiente:
1. El llenado completo de los campos de datos.
2. El llenado de las actividades realizadas para dar solución a la incidencia
3. La firma de satisfacción del usuario (cuando aplique).
VIII) Segundo Escalamiento de la incidencia.
Si el incidente no es resuelto por el personal de soporte de 2o Nivel y con el propósito de cumplir
con los tiempos de respuesta definidos en el SLA.
IX) Asignación del incidente al soporte del 3er. Nivel.
El operador del la Mesa de Ayuda escala y asigna el incidente al soporte de 3er nivel a la Gestión
del Segundo Nivel, siendo para este caso atendido en función de la especialidad técnica que
20
logrará restablecer el servicio y de acuerdo a los Lineamientos para el Procedimiento de Gestión
de Incidentes.
X) Segundo Monitoreo del incidente.
El operador de la Mesa de Ayuda:
1. Registra la hora de inicio del incidente escalado al responsable del 3er nivel.
2. Informa al usuario el estado de la atención del incidente y su posible solución
3. Monitorea el avance de la incidencia hasta su cierre con base en el tiempo de atención de
escalamiento.
XI) Solución, documentación y cierre del incidente escalado.
El responsable de 3er Nivel:
1. Atiende y resuelve el incidente con base en el diagnóstico previamente documentado y en
su conocimiento especializado.
2. Documenta las actividades realizadas en el formato de atención de incidencias para la
solución encontrada del incidente, registra la hora de fin de atención del incidente.
3. Cierra el reporte (registra la fecha y hora del cierre) y entrega el formato de atención de
incidencias al responsable de la Mesa de Ayuda debidamente completado en sus campos
de datos.
El operador de la Mesa de Ayuda recibe el formato de atención de incidencias verificando lo
siguiente:
1. El llenado completo de los campos de datos.
2. El llenado de las actividades realizadas para dar solución a la incidencia
3. La firma de satisfacción del usuario (cuando aplique).
XII) Escalamiento de incidencias al Proveedor.
Si el incidente no es resuelto o requiere del soporte del proveedor para la solución del incidente de
acuerdo con el SLA establecido, entonces, el responsable de la atención del incidente informa al
operador de la Mesa de Ayuda para registrar el escalamiento y comunicar al usuario.
El responsable de la atención del incidente (2º o 3er Nivel) realiza las gestiones necesarias para
escalar el problema al proveedor, de acuerdo de nivel de servicio establecido en el SLA con el
proveedor (Garantía o contrato de servicio).
XIII) Monitoreo del incidente a Proveedor.
El operador de la Mesa de Ayuda:
1. Registra la hora de inicio del incidente escalado al proveedor.
2. Informa al usuario el estado de la atención del incidente y su posible solución.
21
3. Monitorea el avance de la incidencia hasta su cierre con base en el tiempo de atención de
escalamiento.
XIV) Solución, documentación y cierre del incidente escalado
El responsable de la atención del incidente (2º o 3er nivel) y el proveedor.
1. Atiende y resuelve el incidente con base en el diagnóstico previamente documentado y en
su conocimiento especializado.
2. Documenta las actividades realizadas en el formato de incidencias para la solución
encontrada del incidente, registra la hora de fin de atención del incidente.
3. Cierra el reporte (registra la fecha y hora del cierre) y entrega el formato de atención de
incidencias al responsable de la Mesa de Ayuda debidamente completado en sus campos
de datos.
El operador de la Mesa de Ayuda recibe el formato de atención de incidencias verificando lo
siguiente:
1. El llenado completo de los campos de datos.
2. El llenado de las actividades realizadas para dar solución a la incidencia.
3. La firma de satisfacción del usuario (cuando aplique).
2.6 LINEAMIENTOS DE LA GESTIÓN DE INCIDENCIAS
Objetivo
Los lineamientos buscan asistir a la compañía y a la Mesa de Ayuda en mitigar los riesgos de
duplicaciones o clasificaciones erróneas que dificulten el diagnostico, estalación y solución del
incidente.
Alcance
Los lineamientos afectan a la Gestión de Incidentes.
2.6.1 Sobre las Terminologías Comunes
Incidencia: Cualquier evento que no es parte de una operación estándar de un servicio y que
causa, o puede causar una interrupción a, o una reducción en, la calidad de dicho servicio.
Gestión de Incidencias: El proceso que busca restaurar la operación de servicio normal lo antes
posible y que minimiza el impacto adverso en operaciones de negocio, asegurando así que se
mantienen los mejores niveles de calidad de servicio y disponibilidad. “Operación de Servicio
Normal” se define aquí como una operación de servicio dentro de los límites de Acuerdos de Nivel
de Servicio (SLA).
22
Gestión de Problemas: El proceso que quiere minimizar el impacto adverso de incidencias y
problemas en el negocio causados por errores dentro de los recursos informáticos y para prevenir
la recurrencia de incidencias relacionadas con estos errores.
Gestión de Cambios: Proceso de controlar cambios a una infraestructura o a cualquier aspecto de
los servicios, de manera controlada, permitiendo cambios aprobados con un trastorno mínimo.
Gestión de Configuraciones: El proceso de identificar y definir los artículos de configuración
(CIs) en un sistema, registrando e informando del estatus de artículos de configuración y
solicitudes de cambio (RFCs) y verificando la integridad y corrección de los artículos de
configuración.
Acuerdo de Nivel de Servicio (SLA): Acuerdo escrito entre un proveedor de servicios y el cliente
que documentan los niveles de servicio acordados para un servicio.
Servicios: Son los entregables de la sección de servicios de TI tal y como los perciben los clientes;
los servicios no consisten meramente en poner a disposición de los clientes los recursos
informáticos.
Soporte de Primera Línea: Se refiere a los grupos de especialistas del La Mesa de Ayuda.
Soporte de Segunda Línea: A menudo se refiere a los departamentos y grupos de soporte
(especialistas) distintos al La Mesa de Ayuda definido como grupo de soporte de segunda línea,
teniendo más habilidades de especialización, tiempo y otros recursos para resolver las incidencias.
Soporte de Tercera línea: A menudo se refiere a los departamentos y grupos de soporte
(especialistas), teniendo más habilidades de especialización que el grupo de soporte de segunda
línea para resolver las incidencias, por lo general proveedores externos.
Proveedor de servicio: Organización externa que suministra servicios o productos a clientes
Workaround: Solución temporal que se da a un error conocido o a una incidencia donde la causa
raíz es conocida.
2.6.2 Asignación de las incidencias
Se asignan las incidencias o tickets de servicio de acuerdo a la siguiente tabla, que representa la
especialización de los expertos.
TIPO DE INCIDENCIA 1er Nivel 2do Nivel 3er Nivel
Hardware
Axel Pardemann Juan Pablo Flores Brisa Sarai Glez Soporte Externo Proveedor
Software
Juan Pablo Flores Antonio Castillo Brisa Sarai Glez Axel Pardemann Proveedor
23
Red Antonio Castillo Jorge Pacheco
Axel Pardemann Proveedor Telefonía Cynthia Bello Antonio Castillo Proveedor
Almacenamiento Juan Pablo Flores Brisa Sarai Glez Axel Pardemann Proveedor
Seguridad Jorge Pacheco Jorge Pacheco Proveedor
Capacitacion
Axel Pardemann Juan Pablo Flores Antonio Castillo Brisa Sarai Glez
Axel Pardemann Juan Pablo Flores
Antonio Castillo Brisa Sarai Glez Proveedor
Apoyo y Soporte de Tecnología Antonio Castillo Axel Pardemann Proveedor
Tabla 1. Asignación de las Incidencias.
2.7 POLÍTICAS DE GESTIÓN DE INCIDENCIAS
Objetivo
• Garantizar la continuidad de la operación a través de la correcta atención y solución de
incidentes.
• Normar y regular los procesos y procedimientos de la gestión de incidentes de TTD Group.
Política
Todas las incidencias son registradas en el repositorio central único de información BDGI(Base de
Datos de Gestión de Incidentes) con el fin de resolver las peticiones de servicio tan pronto como
sea posible y/o al menos en el tiempo planteado en los convenios de servicio (SLA`s). La mesa de
Servicio determina la prioridad a partir del impacto y la urgencia de la incidencia y asigna a los
responsables de atender las peticiones de servicio en base a criterios establecidos. Las incidencias
son escaladas por la mesa de servicio para atender de la manera más efectiva y pronta
minimizando el impacto negativo en el negocio.
Sobre las soluciones temporales o Work-Arounds
• La aplicación de un Workaround o solución temporal probada no debe impactar sobre el
nivel de seguridad del servicio.
Responsabilidades
La Dirección de Tecnología y Operaciones responsable de:
• Autorizar en caso de un incidente de prioridad alta un curso de acción o solución temporal
que pueda impactar negativamente sobre otros sistemas o en los niveles de seguridad y
riesgo aceptable.
Son responsabilidades de los roles responsables de la gestión de incidentes:
24
• Recibir y registrar las solicitudes de servicio con base en las prioridades de la atención del
usuario y el tipo de servicio.
• Documentar la información suficiente para la atención del servicio identificando el origen
del problema.
• Escalar y asignar la atención de incidencias de servicio al personal de tecnología adecuado
con base en niveles de servicio establecidos (SLA)
• Documentar apropiadamente la solución ejecutada y la recuperación del incidente
• Cerrar reportes y verificar los resultados derivados de la atención del servicio
• Realizar estadísticos de niveles de servicio (SLA) con base en las métricas previamente
establecidas.
• Generar los reportes de gestión correspondientes
• Alimentar la gestión de incidentes
• Retroalimentar al La Mesa de Ayuda
• Seguimiento de las incidencias
• Disparar cambios
2.8 ESTANDARES DE LA GESTIÓN DE INCIDENCIAS
2.8.1 Atención de Incidencias
Objetivo
Contar con una documentación ordenada y organizada, de los incidentes reportados. El estándar
de Atención de Incidencias, está diseñado para proveer un formato homogéneo que permita su
consulta a futuro y sea la base para la obtención de métricas o estadísticos.
Alcance
Todos los incidentes que se reportan, deben tener un Formato de Atención de Incidentes, que
respalde la información del incidente y la solución encontrada, o bien sea la base para la
elaboración de un Estándar de Solución Temporal o Workaround.
Normatividad
Política de Gestión de Incidentes
Estándar
Se establece como Estándar de Atención de Incidentes, el que se señala a continuación y que
podrá ser modificado de acuerdo al criterio de la Dirección de Tecnología y Operaciones, en
función a la tecnología y necesidades de la empresa.
25
Cuerpo del estándar.
Toda la documentación de cada una de las incidencias, debe estar contenida en un Formato de
Atención de Incidencias de acuerdo a las políticas y lineamientos autorizados por TTD Group y la
Dirección de Tecnología y Operaciones.
Datos Generales:
Número de Ticket: Es un número consecutivo y único, que identifica a cada uno de los Formatos
de Atención de Incidencias.
Nombre del Usuario: Se escribe el nombre de la persona que reporta la incidencia o bien el
afectado directamente por la misma.
Tipo de Usuario: Se debe de escribir la categoría de usuario, la cual es la siguiente:
• Directores
• Usuario Interno
• Usuario Externo
Tipo de Urgencia: La categoría de urgencia esta daba por:
• Alta
• Media
• Baja
• Programada
Clasificación de la Incidencia: Los tipos de incidencias existentes son:
• Hardware
• Software
• Red
• Telefonía
• Almacenamiento
• Seguridad
• Capacitación
• Apoyo y Soporte de Tecnología
Palabras Clave: Contiene palabras que permitan en búsquedas futuras, saber de manera sencilla
que tipo de incidencia es, que áreas o servicios afecta y si afecta un CI directamente.
Fecha y Hora de Elaboración: Se escribe la fecha y hora en que se recibe la Incidencia.
Fecha y Hora de Cierre: Se escribe la fecha y hora en que se cierra, mediante una solución la
Incidencia.
26
Descripción de la Incidencia:
Se detallan los datos que se tienen en el momento que se reporta la incidencia y los encontrados
en la primera revisión.
Descripción de la Solución:
Se describe la solución que se implementó para dejar solucionada la incidencia. Y en caso de que
así se requiera se hace una lista de actividades realizadas, que permita tener un proceso de
Rollback en caso de contingencia. Estableciendo fecha, hora y la descripción de la actividad. Tiene
un orden cronológico.
Observaciones:
Es una sección para datos que no entran en ningún otro apartado, pero es importante
mencionarlos.
Firmas de Responsables:
Responsable 1er Nivel: Nombre y firma de la persona asignada a 1er nivel de toda la Gestión de
Incidencias, con fecha de cierre de la documentación.
Responsable 2do Nivel: Nombre y firma de la persona asignada a 2do nivel de toda la Gestión de
Incidencias, con fecha de cierre de la documentación.
Responsable 3er Nivel: Nombre y firma de la persona asignada a 3er nivel de toda la Gestión de
Incidencias, con fecha de cierre de la documentación.
(VER ANEXO V)
2.8.2 Workarounds
Objetivo
Contar con una documentación ordenada y organizada, de las soluciones temporales que se
realizan a incidencias o errores conocidos. El estándar de Solución Temporal (Workaround), está
diseñado para proveer un formato homogéneo que permita su consulta a futuro y sea la base para
la obtención de métricas o estadísticos.
Alcance
• Todas las soluciones temporales que se realizan a incidencias reportadas o errores
conocidos, deben tener un Formato de Solución Temporal (Workaround), que respalde la
información de la solución implementada.
• El estándar debe ser requisitado por todos los ejecutores de solicitudes temporales.
27
Normatividad
Política de Gestión de Problemas.
Estándar
Se establece como Estándar de Solución Temporal (Workaround), el que se señala a continuación
y que podrá ser modificado de acuerdo al criterio de la Dirección de Tecnología y Operaciones, en
función a la tecnología y necesidades de la empresa.
Cuerpo del estándar.
Toda la documentación de cada una de las soluciones temporales o Workaround, debe estar
contenida en un Formato de Solución Temporal de acuerdo a las políticas y lineamientos
autorizados por TTD Group y Dirección de Tecnología y Operaciones.
Datos Generales:
Número de Ticket: Es un número consecutivo y único, que se toma del Formato de Atención a
Incidencias, para poder ligar la Solución Temporal con su Incidencia.
Número de Workaround: Es el número consecutivo y único que se le otorga en orden progresivo a
cada Formato de Solución Temporal.
Nombre del Usuario: Se escribe el nombre del usuario o área que va a ser afectada por la solución
temporal.
Tipo de Usuario: Los tipos de usuario permitidos son:
• Directores
• Usuario Interno
• Usuario Externo
Tipo de Urgencia: Esta categoría está dividida en:
• Alta
• Media
• Baja
• Programada
Palabras Clave: Contiene palabras que permitan en búsquedas futuras, saber de manera sencilla
que tipo de workaround es, que áreas o servicios afecta y si afecta un CI directamente.
Tipo de Incidencia: Los tipos de incidencias existentes son:
• Hardware
• Software
• Red
28
• Telefonía
• Almacenamiento
• Seguridad
• Capacitación
• Apoyo y Soporte de Tecnología
Esta debe de ser la misma que la que se encuentra en el Formato de Atención a Incidencias.
Fecha y Hora de Elaboración: Se escribe la fecha y hora en que se realiza el Wokaround.
Descripción de la Incidencia o Error Conocido:
Se detalla, o bien se copia la información de la incidencia o error conocido, donde se detalle las
características de la misma.
Descripción de la Solución Temporal o Workaround utilizado:
Se describe la solución temporal que se implementará y en caso de que así se requiera se hace
una lista de actividades realizadas, que permita tener un proceso de Rollback en caso de
contingencia. Estableciendo fecha, hora y la descripción de la actividad. Tiene un orden
cronológico.
Observaciones:
Es una sección para datos que no entran en ningún otro apartado, pero es importante
mencionarlos.
Firmas de Responsables:
Responsable 1er Nivel: Nombre y firma de la persona asignada a 1er nivel de toda la Gestión de
Problemas, con fecha de cierre de la documentación.
Responsable 2do Nivel: Nombre y firma de la persona asignada a 2do nivel de toda la Gestión de
Problemas, con fecha de cierre de la documentación.
Responsable 3er Nivel: Nombre y firma de la persona asignada a 3er nivel de toda la Gestión de
Problemas, con fecha de cierre de la documentación.
(VER ANEXO VI)
29
2.9 ESTABLECIMIENTO DE UN REPOSITORIO DE DOCUMENTOS DE SOPORTE
Como primer repositorio de Documentos de ITIL, se establecerán carpetas para cada Gestión
ubicadas dentro de una llamada Procesos de ITIL, dentro de la carpeta de red y cada estándar
deberá tener un número consecutivo y único.
2.10 PROCESO DE LA MESA DE AYUDA
2.10.1 Objetivo
• Proporcionar el primer contacto para todas las llamadas de los usuarios del TTD Group,
siendo el canal oficial de comunicación entre los usuarios y la Dirección de Tecnología y
Operaciones.
• Facilitar la restauración de los servicios de acuerdo con las prioridades de atención y los
niveles de servicio establecidos (SLAs) para la atención de incidencias.
• Emitir informes periódicos derivados de las métricas de atención y nivel de servicios
proporcionados.
• Proporcionar valor a la organización manteniendo el estado óptimo de los recursos y
servicios tecnológicos dispuestos a la operación de TTD Group.
2.10.2 Alcance
Todos los servicios de tecnología corporativos con base en los acuerdos de nivel de servicios
establecidos entre la Dirección de Tecnología y Operaciones y las áreas de negocio de TTD
Group.
2.10.3 Responsables
La Mesa de Servicio de la Dirección de Tecnología y Operaciones es responsable de ejecutar este
procedimiento.
2.10.4 Secuencia de eventos
1. Registro de incidencia (ticket de servicio)
2. Clasificación de incidencias
3. Priorización del ticket de incidencias
4. Proporciona r al usuario el número de ticket
5. Escalamiento del incidente de acuerdo con el proceso de Gestión de Incidentes
6. Monitoreo del avance de la solución de la incidencia
7. Comunicación con el usuario del avance del incidente
30
8. Cierre del incidente
9. Verificación de la calidad de la información
10. Elaboración de los reportes de Gestión
2.10.5 Procedimiento
I) Levantamiento del Ticket
El operador de la Mesa de Ayuda:
1. Recibe la llamada del usuario a través de la extensión 6789 registrando en el formato de
requerimiento de servicio identificando al usuario con los siguientes datos:
• Nombre
• Clave del empleado
• Departamento
• Ubicación
• Teléfono/extensión del usuario
2. Registra el incidente en el formato de requerimiento de servicio (Ticket) los siguientes
datos:
• Número de control de incidente (No. Ticket)
• Fecha del incidente registrado
• Hora del incidente reportado por el usuario
II) Clasificación de Incidencias
El operador de la Mesa de Ayuda:
1. Registra en el formato de requerimiento de servicio (Ticket) la clasificación del incidente.
2. Registra la descripción del incidente en el formato de requerimiento de servicio (ticket) tal
como percibe el usuario el incidente.
III) Priorización del ticket de incidencias
El operador de la Mesa de Ayuda:
1. Prioriza la atención del incidente registrando en el formato de requerimiento de servicio
(ticket)
2. Clasifica la prioridad de atención de los incidentes con respecto al tipo de usuario de
acuerdo
IV) Proporcionar al usuario el número de ticket
El operador de la Mesa de Ayuda proporciona al usuario un ticket de servicio que contiene los
siguientes datos:
31
1. Número de incidente (ticket)
2. Fecha de inicio del servicio (DD/MM/AA)
3. Hora de inicio del servicio (HH/MM)
V) Escalamiento del incidente de acuerdo con el proceso de Gestión de Incidentes
El operador de la Mesa de Ayuda atiende el incidente a través del proceso de Gestión de
Incidentes, escalando el incidente al soporte de segundo, tercer nivel o proveedor en caso de que
el incidente no sea resuelto por el soporte de primer nivel (Operador de La Mesa de Ayuda).
VI) Monitoreo del avance de la solución de la incidencia
El operador de la Mesa de Ayuda verifica el avance en la solución del incidente por medio de
registrar la fecha y la hora por cada vez que se de un escalamiento del incidente al soporte de
segundo, tercer nivel o proveedor.
VII) Comunicación con el usuario del avance del incidente
El operador de la Mesa de Ayuda, informa al usuario el estatus de atención de incidencia, y el
tiempo aproximado de solución.
VIII) Cierre del incidente
El operador de la Mesa de Ayuda
1. Cierra el incidente registrando el formato de requerimiento de servicio (Ticket) la fecha
y la hora del cierre.
2. Obtiene el Visto Bueno de la solución a la incidencia reportada por el usuario
IX) Verificación de la calidad de la información
El operador de la Mesa de Ayuda revisa el llenado de los formatos de:
1. Requerimientos de servicio,
2. Atención de incidentes y
3. Workaround y Solución Raíz
4. Verifica que la información contenida en los formatos sea completa clara y detallada.
X) Elaboración de los reportes de Gestión
El Operador de la Mesa de Ayuda elabora mensualmente los reportes operacionales y ejecutivos
de gestión de incidentes y los entrega a la Dirección de Tecnología y Operaciones.
32
2.11 LINEAMIENTOS DE LA MESA DE AYUDA
Objetivo
Los lineamientos buscan asistir a la compañía y a la Mesa de Servicio en mitigar los riesgos de
duplicaciones o clasificaciones erróneas que dificulten el diagnostico, estalación y solución del
incidente.
Alcance
Los lineamientos afectan a la Mesa de Servicio y responsables de Gestión de Incidentes.
Disposiciones Generales
Durante el Registro de la incidencia: Los tipos de tickets (o requerimientos) que podrá recibir el La
Mesa de Ayuda están enfocados a proporcionar información, resolver dudas, atender un
requerimiento o resolver un incidente que afecta a la operación del recurso de IT, este tipo de ticket
en su caso disparar o no la atención de incidencia para su escalamiento, tal como se especifica en
la siguiente tabla:
TIPO DE INCIDENTE DESCRIPCIÓN DE ESTE TIPO
SE REQUIERE
TICKET
SE REQUIERE
INCIDENCIA
INFORMACIÓN
Cuando el incidente reportado requiere de información
al usuario el cual no representa una incidencia que afecte
la operación. SI NO
PREGUNTA
Cuando el incidente reportado se refiere a cuestionamiento de uso de
recursos o aplicaciones. SI NO
REQUERIMIENTO
Cuando el incidente reportado requiere de una acción posterior del área de soporte
especializado de 2º o 3er. Nivel posterior al soporte de La Mesa de Ayuda (1er. Nivel). SI SI
INCIDENTE
Cuando el incidente reportado se refiere a una falla o problema con un recurso,
servicio tecnológico o aplicación el cual requiere del soporte especializado de 2º. O
3er. nivel SI SI Tabla 2. Casos de Asignación de Tickets
Durante la clasificación del Incidente: Las categorías de incidentes listadas a continuación no son
una clasificación definitiva de todos los tipos de incidentes, se proveen como base para guiar en la
gestión de un incidente basado en sus principales.
.
33
Tabla 3. Categorización de Incidencias
Durante la Priorización del ticket de incidencias: El a Mesa de Ayuda tiene la facultad de asignar la
prioridad de atención de la incidencia, cumpliendo para esto con los acuerdos de nivel de servicio
establecidos entre las áreas usuarias.
Las prioridades dependerán básicamente del impacto que un incidente le genera al negocio.
La prioridad se determina en función de la urgencia del incidente, del grado de impacto del
incidente en los servicios de IT y del esfuerzo estimado para resolver el incidente.
En principio, la urgencia es fijada por el usuario. La urgencia se relaciona a la prontitud para
solucionar un incidente de cierto impacto.
CATEGORIA DE INCIDENTES
TIPO
Hardware Impresoras
Fax
Scanners
Equipo de Computo
Software Herramientas de Office
Aplicaciones especiales
Sistema operativo
Desarrollos Internos y Externos
Correo electrónico
Paqueteria comercial
Red Control de acceso
Tiempos de Respuesta muy bajos
Dominios
Internet
Cuentas de usuario
Negación del Servicio
Equipo de Red
Voz y Telefonía Correo de voz
Extensiones Telefónicas
Capacitación
Almacenamiento Respaldo y Recuperación
Seguridad Código malicioso
Violaciones de confifencialidade integridad
Mal uso de los Sistemas de Información
34
Un incidente de alto impacto, por defecto, no necesariamente tiene que ser solucionado
inmediatamente. Por ejemplo, un usuario que tiene dificultades operacionales con el acceso a la
red (impacto medio) puede tener registrado el incidente con urgencia baja si después de registrar
el caso un viernes por la tarde tomará sus vacaciones anuales a partir del lunes próximo.
La prioridad también es afectada por esfuerzo previsto para resolver un incidente. Un incidente con
un impacto bajo, que pueda ser resuelto con un mínimo de esfuerzo, se debe resolver rápidamente
(Ejemplo: Cómo usar un servicio de web mail).
Las siguientes tablas describen un análisis para determinar la prioridad de los incidentes para su
correspondiente atención:
USUARIOS PRIORIDAD
Directores Alta
Usuarios Internos Media
Usuarios Externos Baja Tabla 4. Categorización de Usuarios y Prioridades
2.12 POLITICAS DE LA MESA DE AYUDA
Objetivo
• Normar y regular los procesos y procedimientos de la gestión de La Mesa de Ayuda de
TTD Group.
• Garantizar la continuidad de la operación a través de la correcta asignación, priorización y
escalamiento para atención y solución de incidentes.
Política
TTD Group establece la Mesa de Servicio como parte de la Gerencia de Tecnología y Operaciones
y como punto único y principal de contacto para el reporte de incidentes y solicitud de servicios. La
mesa de Servicio de TTD Group asegura que todos los problemas de hardware y software que se
presenten durante la operación diaria sean documentados apropiadamente y escalados para su
atención y solución con base en los acuerdos de nivel de servicios establecidos entre la Gerencia
de Tecnología y Operaciones y las áreas de negocio.
Sobre los Medios de Contacto
La mesa de servicio puede ser contactada a través de los siguientes medios:
• Extensión 6789
• Correo electrónico: [email protected]
35
Sobre los tipos de tickets reportados al La Mesa de Ayuda
Los tipos de tickets (o requerimientos) que podrá recibir el La Mesa de Ayuda estan enfocados a
proporcionar información, resolver dudas, atender un requerimiento o resolver un incidente que
afecta a la operación del recurso de IT, este tipo de ticket en su caso disparar o no la atención de
incidencia para su escalamiento, tal como se especifica en los Lineamientos para el Procedimiento
de Gestión de Mesa de Servicio.
Sobre la prioridad de la atención de la incidencia
El La Mesa de Ayuda tiene la facultad de asignar la prioridad de atención de la incidencia,
cumpliendo para esto con los acuerdos de nivel de servicio establecidos entre las áreas usuarias,
Direcciones, tomando como base de asignación de prioridades para su atención los Lineamientos
para la Atención de Incidencias.
Sobre las condiciones para cerrar un ticket de incidencia
El operador de La Mesa de Ayuda podrá cerrar un ticket de incidencia cuando suceda una de las
siguientes condiciones en el proceso de atención de dicha incidencia:
• Una solución raíz a la incidencia reportada ha sido implementada.
• Una solución alternativa, solución temporal (Workaround) ha sido implementada.
• El incidente se ha convertido en un cambio el cual involucrará el proceso de Gestión de
cambios
• El usuario y el responsable de la atención del incidente (soporte de 3er. Nivel) concuerdan
que bajo las carácterísticas o limitantes del recurso de TI no pueden hacerse esfuerzos
adicionales, obteniendo la conformidad del primero.
Sobre el Horario de la Mesa de Servicio
El horario de servicio de La Mesa de Ayuda será de lunes a viernes de 8:00 a 19:00 Hrs
Responsabilidades
Las responsabilidades de cada nivel de soporte son:
1er Nivel (Mesa de Servicio)
• Administra y coordina todas las actividades necesarias para detectar, resolver incidentes
de recursos tecnológicos que (potencialmente) afectan los niveles de servicio.
• Asegura una efectiva coordinación de las actividades adecuadas para la recuperación del
servicio al usuario por medio del 2º y 3er Nivel.
• Es el único punto de contacto para los usuarios que busquen información o bien reporten
problemas en los servicios de tecnología y de los sistemas.
36
• Es también el punto de contacto primario de TI para comunicar información operativa hacia
los usuarios.
• Es la primera fuente de información de administración sobre la calidad de los servicios de
TI.
• El Administrador del 1er. Nivel de La Mesa de Ayuda es responsable por la adecuada
asignación de los incidenctes de acuerdo con las habilidades del personal de soporte, el
rendimiento de los mismos y por la efectiva colaboración de estos con otros especialistas
de la actividad de soporte (proveedores).
• Ser el primer contacto con el usuario para la recepción de incidencias de servicio.
• Clasificar, determinar la prioridad de las incidencias y canalizarlas hacia el soporte técnico
adecuado.
• Mantener la comunicación entre el usuario y el personal de soporte técnico con base en el
estado de avance del servicio.
• Comunicar al usuario los cambios programados en atención al servicio.
• Coordinar y registrar en su caso, el soporte de segundo y tercer nivel con base al nivel de
atención del servicio.
• Proporcionar recomendaciones básicas a los usuarios para el mejor uso de los recursos
tecnológicos.
• Identificar las necesidades de formación y capacitación de usuarios.
• Contribuir a la correcta identificación de incidencias.
• Emitir informes periódicos del comportamiento de la operación del servicio.
2o Nivel
• Acepta y recibe llamados del 1er. Nivel (La Mesa de Ayuda )
• Provee al La Mesa de Ayuda actualizaciones relacionadas con el estado de los incidentes
• Resuelve incidentes a partir de soluciones temporales (workarounds o soluciones raíz)
• Puede Asignar incidentes y requerimientos al proveedor correspondiente.
• Interactúa y provee de soporte de 1er. Nivel con sus conocimientos adicionales en áreas
específicas (técnicas, del negocio o sobre aplicaciones) que aseguren una inmediata
resolución de incidentes.
• Registra la documentación necesaria y suficiente en los formatos Workarounds y
soluciones raíz correspondientes para posteriormente alimentar la base de datos de
conocimientos.
3er Nivel
• Acepta y recibe llamados del La Mesa de Ayuda.
37
• Provee al La Mesa de Ayuda de actualizaciones relacionadas con el estado de los
incidentes.
• Resuelve incidentes y provee la documentación de la resolución al La Mesa de Ayuda.
• Puede Asignar incidentes y requerimientos al proveedor correspondiente.
• Interactúa y provee al soporte al 2º Nivel con sus conocimientos adicionales en áreas
específicas (técnicas, o sobre aplicaciones) que aseguren una inmediata resolución de
incidentes
• Provee de información sobre acciones que pueden afectar el tiempo de disponibilidad de
los sistemas provistos y soportados por el La Mesa de Ayuda.
• Provee al soporte de 1er. Y 2º. Nivel de información, documentación, o entrenamiento
sobre actualizaciones de los sistemas provistos y soportados.
Sobre las responsabilidades de los usuarios al levantar un ticket
Los '''usuarios''' son responsables de:
• Toda prestación de servicios estará regulada por el contenido dentro de los SLA´s. La
responsabilidad del usuario en su relación con el La Mesa de Ayuda variará de acuerdo
con el servicio deseado. Sin embargo, se espera que el usuario se adhiera a todas las
políticas, estándares y procedimientos de Infraestructura Tecnológica (IT).
• El usuario que se le presente un incidente referente a su equipo PC, impresora, dispositivo
periférico, servicio de red o aplicación instalada en su equipo PC que esté afectando su
actividad laboral, llamará al La Mesa de Ayuda a la extensión 6789 para reportar dicho
incidente o requerimientos de soporte de tecnología, especialmente aquellos asociados a
los productos y servicios definidos en los SLA´s.
• Al momento de solicitar soporte de IT a través del contacto con el La Mesa de Ayuda,
deberá proveer su nombre, puesto, identificación, área, ubicación y número de teléfono o
extensión.
• Proveerá una clara descripción de la incidencia, problema o requerimiento, sin omitir
detalles de las acciones realizadas antes de la presentación del problema. Indicará, si lo
hubiese, cualquier uso inusual reciente de las aplicaciones o cualquier cambio en el equipo
PC.
• Incluirá en la descripción del incidente o bien información de los equipos periféricos,
mensajes de error, nombre de la aplicación, incidente de red o sistema operativo. Se
espera que esta información sea colectada antes de llamar a La Mesa de Ayuda.
• Proveerá el nombre y teléfono de un contacto alternativo, en caso que el usuario llamante
no esté disponible durante el proceso de resolución de la incidencia, el usuario o el
contacto designado deberán estar localizable por La Mesa de Ayuda durante el proceso de
resolución del incidente.
38
• Deberá tener un conocimiento mínimo específico de operación de las herramientas de
tecnología antes descritas de las cuales hace uso.
• Deberá colaborar en el intento de resolución telefónica del problema, siguiendo y
ejecutando las instrucciones provistas por el personal de La Mesa de Ayuda.
• Informará adecuadamente todo evento relacionado con la resolución en línea. Se espera
que el usuario juegue un rol activo en el proceso de resolución.
• En caso del envío de personal especializado a lugar de trabajo del usuario, dicho usuario
estará presente en el puesto de trabajo a la hora convenida con el La Mesa de Ayuda.
2.13 ESTÁNDARES DE GESTIÓN DE LA MESA DE AYUDA.
2.13.1 RFC (Request For Change) ó Solicitud Formal de Cambio.
Objetivo
Contar con documentación ordenada y organizada, de los cambios para su correcta
implementación y revisión. El estándar de Solicitud Formal del Cambio (RFC) está diseñado para
proveer un formato homogéneo que permita su consulta a futuro y sea la base para la obtención de
métricas o estadísticos.
Alcance
Todos los cambios que se realicen deben de tener una RFC, que respalde la información del
cambio y las actividades realizadas.
El estándar debe ser requisitado por todos los ejecutores de cambios.
Normatividad
Política de Gestión de Cambios
Política de Gestión de La Mesa de Ayuda
Estándar
Se establece como estándar de Solicitud Formal de Cambios (RFC) el que se señala a
continuación y que podrá ser modificado de acuerdo al criterio de la Gerencia de Sistemas y
Comunicaciones, en función a la tecnología y necesidades de la empresa.
Cuerpo del estándar.
Toda la documentación de cada uno de los cambios, debe estar contenida en un RFC´s de
acuerdo a las políticas y lineamientos autorizados por TTD Group y la Dirección de Tecnología y
Operaciones.
39
Datos Generales:
No. de Documento: Es un número consecutivo y único, ayuda a tener control del total de las RFC
recibidas.
Palabras Clave: Contiene palabras que permitan en búsquedas futuras, saber de manera sencilla
que tipo de cambio es y que áreas o servicios afecta.
Categoría de Impacto: De acuerdo a la matriz de Impacto establecida en los Lineamientos de
Gestión de Cambios, se establece una categoría por cada RFC.
Tipo de Prioridad o Urgencia: Se determina la categoría de Prioridad o Urgencia, según la matriz
de establecida en los Lineamientos de Gestión de Cambios.
Categoría de Riesgos: De acuerdo con la evaluación de riegos, debe de escribirse el resultado de
la misma en este apartado.
Fecha de Elaboración: Se escribe la fecha en que se recibe la Solicitud de Cambio.
Fecha de Cierre: Debe de estar la fecha, en que el cambio es implementado, probado y aceptado;
dejando el servicio en funcionamiento óptimo.
Fecha de Revisión Post-Implementación: Se escribe la fecha en que se realiza la Revisión después
de la Implementación con el fin de validar su calidad y funcionalidad.
Descripción del Cambio:
Se detalla a profundidad, el primer análisis que se hace respecto al cambio a realizar, escribiendo
los datos que se tienen en el momento de recibir la Solicitud Formal de Cambio.
Evaluación de Riesgos:
El ejecutor responsable, asesorado por la Junta establece un análisis de Riesgos, el cual lo detalla
en este apartado, mediante a una tabla de evaluación que se realizo previamente.
Minuta de Actividades:
Es la lista de actividades realizadas durante el proceso, estableciendo fecha, hora y la descripción
de la actividad. Tiene un orden cronológico.
Requisitos de CI´s:
Se describen la cantidad de CI´s requeridos para implementar el cambio y su descripción.
Resultado de las Pruebas Antes de la Implementación:
Es un resumen breve del resultado obtenido después de realizar la minuta de actividades.
40
Resultado y Cierre de la Implementación:
Se escribe si fue un éxito el cambio o no y porque. Es el momento preciso para escribir en la parte
de Datos Generales, la fecha del cierre del cambio.
Resultado de la Revisión Post-Implementación:
Cuando la Junta realiza revisiones Post-Implementaciones, coloca la fecha en los Datos Generales
y escribe un breve resumen de lo encontrado en la revisión.
Observaciones:
Es una sección para datos que no entran en ningún otro apartado, pero es importante
mencionarlos.
Firmas de Responsables:
Ejecutor Responsable: Nombre y firma de la persona asignada a toda la Gestión de Cambios, con
fecha de cierre de la documentación.
Autorizador: Nombre y firma de la persona autorizadora del cambio y fecha del día de autorización.
Revisor de la Junta: Nombre y firma de la persona que la Junta asigna como Revisor Post-
Implementación. Con fecha de la revisión. (VER ANEXO VII)
2.13.2 SLA (Service Level Agreement) o Acuerdo de Nivel de Servicio.
Definición y Objetivo del Servicio:
Se escribe una breve definición del servicio, su finalidad y/o objetivos.
Características del Servicio:
Entran los detalles del servicio y sus características.
Línea del Servicio:
Cuando ya existan una línea de servicios similares estos se colocaran agrupados en un mismo
grupo.
Servicios Relacionados y/o Complementarios:
Si existen uno o varios servicios relacionados, necesarios o resultantes del presente, deberán
detallarse.
Servicios Soportados:
Se nombraran los servicios que este puede soportar y sus limitantes.
41
Vigencia:
Tiempo durante el cual el presente proceso y/o servicio será utilizado, soportado y mantenido por
la Gerencia de Tecnología y Operaciones.
Políticas Generales:
Se realizará una lista de políticas de uso y mantenimiento del servicios las cuales tendrán validez
durante la vigencia del mismo.
Alcance:
Limitantes del servicio.
Disponibilidad del Servicio y Atención a Fallas:
Se debe de establecer cuáles serán los horarios de disponibilidad y como serán atendidas la fallas
del servicio.
Soporte y Mantenimiento:
Descripción del soporte y mantenimiento requerido por el servicio.
(VER ANEXO VIII)
42
CAPITULO 3. ELECCIÓN DE LA MESA DE AYUDA
La elección final de la Herramienta de Mesa de Ayuda corrió a cargo, del Director de Tecnología y
Operaciones, pero fue necesario realizar evaluaciones a las aplicaciones que varios proveedores
ofrecieron, entre los cuales se encuentran:
1. The Forrester Wave™: Service Desk Management Tools, Q2 2008 2. Altiris® 6 Helpdesk Solution™ 3. Numara™ FootPrints 8.0 4. BridgeTrak Suite 7.0 5. HEAT® Service and Support™ 6. BMC Service Desk Express Suite (Magic
3.1 EVALUACIÓN DE OPCIONES DE MESA DE AYUDA
Objetivos:
• Proporcionar una herramienta automatizada para alta y seguimiento de los incidentes de
los usuarios.
• Proporcionar el primer contacto para todas las llamadas de los usuarios de TTD Group,
siendo el canal oficial de comunicación entre los usuarios y la Dirección de Tecnología y
Operaciones.
• Facilitar la restauración de los servicios de acuerdo con las prioridades de atención y los
niveles de servicio establecidos (SLAs) para la atención de incidencias.
• Emitir informes periódicos derivados de las métricas de atención y nivel de servicios
proporcionados.
• Proporcionar valor a la organización manteniendo el estado óptimo de los recursos y
servicios tecnológicos dispuestos a la operación de TTD Group.
Criterios de Evaluación.
Funcionalidad:
• Compatible con ITIL.
• Establecimiento de Reglas de Negocio sobre el sistema.
• Escalamientos automáticos sobre los incidentes en base a los SLA.
• Registro de SLA para cada categoría de los incidentes.
• Al menos dos asientos de ingreso de incidentes, consulta por todos los analistas.
• Base de datos de conocimiento con capacidad de almacenar links u objetos.
43
• Base de datos abierta para reportes no contemplados o un reporteador incluido en la
licencia.
• Avisos por correo electrónico.
• Integración con el directorio activo.
Seguridad:
• Control de acceso individual y autentificado.
• Comunicación segura o capacidad de encripción.
Productos Evaluados
• BMC IQ Magic
• Frontrange Heat
• Scriptlogic Bridgetrak
• FootPrints • Altiris Incident Management
Nombre Licencia Implemen- tación
Manteni- miento
Capacita- ción
Inversión Inicial
BMC Service Desk Express Suite (Magic)
14,000.00 11,980.00 2,520.00 - 28,500.00
Altiris - 3,780.00 - 21,000.00 HEAT 7,800.00 6,988.00 4,320.00 2,400.00 17,188.00 Footprints 12,995.00 - 2,339.10 - 15,334.10 Bridge-Track 6,985.05 - 1,257.31 - 6,985.05
Tabla 5. Costos Iníciales y Mantenimiento en Base a Propuestas Económicas (Precios en Dólares Americanos).
Nombre Puntos Dólares Dólares/Punto BridgeTrack 4 6,985.05 2,328.35 Footprints 4 15,334.10 3,833.53 HEAT 4 17,188.00 4,297.00 Altiris 7 21,000.00 3,000.00 BMC La Mesa de Ayuda Express Suite (Magic)
4 28,500.00 7,125.00
Promedio de dólares por Punto 4,116.78 Tabla 6. Análisis Costo Efectivo (Dólares por Punto)
Los siguientes puntos a ser evaluados, corresponden a los procesos de ITIL que cubren cada una de las
aplicaciones de software que están concursando.
Puntos
HEAT Bridge Track ServiceDesk ExpresSuite Footpris 8 Altiris
Tasa W
Nombr
BridgeTrack FootprHEAT Altiris BMC SDesk ESuite (
B
0
1
2
3
4
5
6
7
8
9
Puntos
Mesa de
Servicio
1
1
e 1
ss
int 1
1
Wacc
re VaPr
e $
rints $ $ $
Service Express (Magic)
$
BridgeTrack, $6,985.05
Gestión de
Incidentes
1
1
1
1
1
12.37%
alor resente 9,985.80
20,916.69 27,498.29 30,021.51 34,514.34
Tab
Tabla 7. E
Imagen 3. E
Footprints, $15,334.10
H
Gestión de
Problemas NS
1
1
1
1
1
$ 6,98
$ 15,33 $ 17,18 $ 21,00 $ 28,50
bla 8. Valor Pres
valuación en Pu
Evaluación en P
HEAT, $17,188
Puntos
Gestión de
CMDB
Nivel de Servicio
1
1
1
1
1
0
85.05 $
34.10 $ 88.00 $ 00.00 $ 00.00 $
sente de la Inver
untos
Puntos
8.00
Altiris, $21,00
s
Gestión de
G
Configu- ración
C
1
1
1,257.31
2,339.10 4,320.00 3,780.00 2,520.00
rsión a 3 años
00.00
BMC ServiceExpress Su(Magic)
$28,500.0
Gestión de
Gesd
Cambios Disbil
1
2
$ 1,257.31
$ 2,339.10 $ 4,320.00 $ 3,780.00 $ 2,520.00
e Desk uite ), 00
stión de
PUNTO
poni- idad
4
4
4
4
1 7
2
$ 1,25
$ 2,33 $ 4,32 $ 3,78 $ 2,52
44
OS
3
57.31
39.10 20.00 80.00 20.00
Por m
proces
3.2 C
FootPr
basada
Puede
herram
de reso
Con F
progra
Dispon
desde
autose
niveles
todo el
la prod
3 http://w
$5,0$10,0$15,0$20,0$25,0$30,0$35,0$40,0
edio de la a
sos de ITIL qu
CARACTE
rints integra p
a en web.
automatizar
mienta ganado
olución de inc
ootPrints la
mación ni c
ne de un ento
múltiples can
ervicio para u
s de servicio,
llo con un po
ductividad y re
www.footprints-sp
$‐000.00 000.00 000.00 000.00 000.00 000.00 000.00 000.00
Br
Imag
anterior evalu
ue cubría y qu
ERÍSTICA
potencia, flex
r rápidament
ora de múltip
cidencias, me
solución de
onsultoría y
orno centraliza
nales (teléfon
suarios, base
, plena integr
tente módulo
endimiento de
pain.com/Numara
ridgeTrack
gen 4. Valor Pre
uación se de
ue podrían se
AS DE LA
xibilidad y fac
te servicios
ples premios
ejorar el workf
soporte esta
sin necesid
ado de help d
no, web, emai
e de datos d
ración con el
o de informes
el equipo de t
a_Footprints/Car
Footprints
V
esente de la Inve
etermino que
er útiles para l
A OPCIÓN
cilidad de us
de soporte
lo que ayuda
flow interno y
operativa en
ad de recur
desk que pe
il, chat y disp
e conocimien
l correo elect
y estadística
trabajo.3
racteristicas_Foo
HEA
Valor Pr
ersión a 3 años
e la mejor op
la empresa fu
N LEGIDA
so en una so
internos o
a a reducir co
y prestar sopo
n tan solo u
rsos dedicad
rmitire gestio
positivos móvi
nto, automatiz
trónico, work
as para poder
otprints/
AT A
resente
pción en cos
ue:
A.
olución de He
atención a
ostes, increm
orte 24x7.
nos días, sin
os para su
onar las incide
iles) además
zación de tar
flow y gestió
r controlar en
Altiris BM
sto, beneficio
elp Desk 100
clientes. Es
mentar el tiem
n necesidad
administració
encias recibid
de disponer
reas, control
ón del cambio
n todo momen
MC Service DesExpress Suite
(Magic)
Valor …
45
o y
0%
la
mpo
de
ón.
das
de
de
o y
nto
sk
…
46
Los usuarios de FootPrints únicamente necesitan un navegador para acceder a su instalación de
FootPrints que podrá realizar tanto en un servidor Windows como Unix/Linux.
Gestión y seguimiento centralizado de incidencias, problemas y peticiones
• Gestiona de manera centralizada y multi-canal (web, mail, teléfono y dispositivos wireless)
las peticiones de usuarios y clientes.
• Proporciona a cada uno de sus agentes la información adecuada, alertas y asignaciones a
través de múltiples vías de comunicación.
• Dispone de múltiples proyectos o escenarios de soporte para diferentes funciones,
usuarios o grupos.
Ahorro de tiempo gracias a la arquitectura web de FootPrints orientada a la productividad
• Trabajo con una arquitectura 100% basada en web.
• Interfaz personalizada por usuario gracias a su potencia y flexibilidad.
• Herramientas de FootPrints para archivar, realizar copias, restaurar y purgar datos
históricos.
Adaptación de FootPrints según sus necesidades gracias a su fácil configuración
• Configuración de FootPrints usando asistentes y formularios que permiten adaptar los
formularios de trabajo, campos, informes, consultas, estados y prioridades sin necesidad
de programar.
• Adaptación de FootPrints según las necesidades específicas de la organización creando
reglas de negocio que incluyen notificaciones, asignaciones automáticas, escalados,
alarmas, envío de emails o mensajes a dispositivos móviles.
Entorno óptimo de trabajo
• Creación automática de tickets asociados a la recepción de un email.
• Utilización la base de datos de conocimiento y las listas de preguntas y respuestas
habituales para agilizar el proceso de resolución de una incidencia.
• Agilización de la gestión gracias a una plena integración con el correo electrónico para
notificarle cambios, recordatorios, alarmas y para responder a una petición.
• Optimice los procesos utilizando herramientas de calendario y correctores ortográficos.
47
Acceso dinámico a listas de usuarios o clientes y otro tipo de información, sin necesidad de programar
• Utilización de FootPrints Dynamic Address Book Link* para acceder dinámicamente a sus
listas de contactos almacenadas en su directorio de usuarios LDAP incluyendo Microsoft
Active Directory, Lotus Notes, etc.
• Utilice el FootPrints Dynamic SQL Database Link para acceder dinámicamente a su base
de datos de usuarios o clientes así como a cualquier otra información almacenada en
bases de datos SQL (incluyendo Microsoft SQL Server, Oracle, etc.).
Gestión de acuerdos de niveles de servicios (SLAs)
• Automatización y gestión del cumplimiento de los niveles de servicio establecidos con los
usuarios o clientes con un módulo de gestión de SLAs totalmente configurable.
• Automatización de la gestión de fechas de vencimiento y la generación de alarmas,
avisos e informes relacionados con sus SLAs.
• Definición fácilmente sus niveles de servicio por prioridad, tipo de problema o cliente.
Creación de una base de datos de conocimiento para agentes y usuarios
• Distinción entre la base de datos interna para agentes y la pública para usuarios.
• Gestión de listas de FAQs (preguntas y respuestas típicas) organizándolas por tópico o
popularidad.
• Control la inclusión de nuevas soluciones en la BD de conocimiento mediante un proceso
de aprobación.
• Enlace de la BD de conocimiento con otras BD de conocimiento públicas como la de
Google Groups o Microsoft TechNet.
• Permite que los usuarios busquen en la base de datos de conocimiento.
Plena integración con el correo electrónico
• Creación de incidencias desde el email, incluso con documentos adjuntos.
• Envío de notificaciones y alertas por email con formatos totalmente parametrizables.
• Guarda trazabilidad de las conversaciones mantenidas mediante el intercambio de emails.
• Soporta IMAP, POP y SMTP.
• Soporta email seguro.
48
Automatización de gestión de activos IT integrada con su gestión de helpdesk
• Dispocisión automáticamente del inventario de hardware y software de activos IT mediante
la solución que mejor se adapte a sus necesidades:
FootPrints Asset Management* automatiza la obtención del inventario de hardware
y software, la ubicación de sus dispositivos, el control de licencias de software y la
generación de todo tipo de informes.
FootPrints LANsurveyor* dispone de un diagrama de su red, descubriendo sus
activos y almacenándolos en su base de datos de activos.
Utilice el Módulo de Integración* con Microsoft SMS para dinámicamente acceder
a los datos de inventario almacenados en su Microsoft SMS Asset Management.
Utilice FootPrints Deply Suite* para distribuir parches y actualizaciones previniendo
problemas antes de que ocurran
Disposición automática de informes y estadísticas
• Diseña rápida y fácilmente todo tipo de informes y estadísticas incluyendo gráficos.
• Dispone de la auditoría completa de cada una de sus intervenciones.
• Genera informes parametrizados y planifique su ejecución y distribución por email.
• Controla el tiempo dedicado por sus agentes cruzando la información por departamento,
centros de coste o clientes.
Disposición de la máxima seguridad para sus datos
• Asegura un acceso restringido mediante múltiples niveles de seguridad incluyendo la
utilización de cuentas de usuarios integradas con Microsoft Windows, LDAP, UNIX,
servidor web o la autenticación de FootPrints.
La compra de la herramienta de La Mesa de Ayuda, se llevo a cabo con 5 licencias de Acceso
Nombrado además que incluye Soporte Técnico, Mantenimiento y Capacitación.
49
CAPITULO 4. MÉTRICAS DE EVALUCIÓN PARA LOS NIVELES DE MADUREZ DE LOS PROCESOS DE ITIL.
4.1 ¿QUÉ ES EL CMMI?
El Modelo de Capacidad y Madurez Integrado CMMI (Capability Maturity Model Integration) es un
modelo de referencia de prácticas maduras usadas para evaluar y mejorar la capacidad de los
procesos. Es una ruta evolutiva de implementación de las mejores prácticas en los procesos
organizacionales.
El modelo para software (CMMI) establece 5 niveles de madurez para clasificar a las
organizaciones, en función de qué áreas de procesos consiguen sus objetivos y se gestionan con
principios de ingeniería. Es lo que se denomina un modelo escalonado, o centrado en la madurez
de la organización.4
Niveles:
1- Ejecutado
2 - Administrado - Gestionado
3 - Definido
4 - Administrado - Gestionado Cuantitativamente
5 - Optimizado
Este fue el modelo utilizado para evaluar el grado de Madurez de los Procesos que Recomienda
ITIL, y con base a la documentación revisada se llegó a la realización de la siguiente Matriz, siendo
sus apartados los puntos a evaluar de cada uno de los Procesos, que TTD Group utilizará de las
Mejores Prácticas de ITIL.
Se agregó un nivel cero que representa la etapa Inicial o de Partida.
Conciencia Políticas, Planes Herramientas y NIVEL y Comunicación y Procedimientos Automatización
Nivel 0
No existe conciencia de los procesos necesarios.
No existe diferencia entre procesos, políticas y procedimientos, los empleados realizan sus
No se usan herramientas estandarizadas.
4 http://www.sei.cmu.edu/cmmi/general/index.html
50
actividades sin orden y plan.
La comunicación entre las áreas es deficiente.
Cada área tiene herramientas diferentes y no siempre son compatibles.
Nivel 1
Reconocimiento de la necesidad de procesos emergentes.
Existen enfoques adecuados para los procesos y prácticas.
Algunas herramientas son usadas en base a estándares de herramientas para escritorio.
La comunicación de cuestiones es esporádica.
Los procesos y políticas no están definidos.
Nivel 2
Hay comprensión de la necesidad de actuar.
Existen procesos similares y comunes, pero aplicados de forma intuitiva y e individualmente.
Enfoques comunes para el uso de herramientas existentes pero basados en soluciones y desarrollos individuales.
Gestión de comunicación para las cuestiones generales.
Algunos aspectos de los procesos son repetibles dada la individualidad.
Se adquieren herramientas pero probablemente no son bien aplicadas.
Nivel 3
Existe un conocimiento de la necesidad de actuar.
Surge el uso de buenas prácticas.
Planes bien definidos para uso y estandarización de herramientas de automatización de procesos.
La gestión de comunicación es más formal y estructurada.
Los procesos, políticas y procedimientos son definidos y documentados para todas las actividades.
Las herramientas son usadas para los propósitos básicos porque no están totalmente integrado al plan general.
Nivel 4
Existe una comprensión de todos los requerimientos.
Los procesos son completos y las mejores prácticas internas son aplicadas.
Las herramientas son integradas para el plan estandarizado y pueden integrarse a otras herramientas.
Maduras técnicas de comunicación, son aplicados estándares y herramientas.
Todos los aspectos de los procesos son documentados y repetibles. Las políticas son aprobadas. Existen estándares para desarrollo y mantenimiento de procesos, los cuales son adoptados y usados.
Las herramientas son usadas en varias áreas para automatizar la gestión de procesos y tener monitoreo y control de actividades críticas.
51
Nivel 5
Hay avances con visión a futuro y un entendimiento de los requerimientos.
Son aplicadas las mejores prácticas y losestándares externos.
Los paquetes estandarizados son usados en toda la empresa.
Comunicación proactiva de las cuestiones. Maduras técnicas de comunicación aplicadas e integradas a las herramientas en uso.
El proceso de documentación es automático
Las herramientas son totalmente integradas con otras y están disponibles en todos los procesos.
Procesos, políticas y procedimientos, estandarizados y integrados en toda la gestión.
Las herramientas son usadas para soportar improvistos y detectar automáticamente excepciones de control.
Tabla 9. Primera parte de la Matriz de CMMI
Conocimientos Responsabilidades Objetivos y NIVEL y Experiencia Medición
Nivel 0
No se establece un nivel mínimo de conocimientos requeridos y por lo tanto no existen rangos o diferencias entre los empleados.
La responsabilidad que cada empleado tiene es la que el mismo toma y existe un gran desorden para controlar las actividades de cada empleado.
No existen objetivos y no se establecen métricas de evaluación de resultados.
La propiedad de los procesos no esta definida.
Nivel 1
Los conocimientos requeridos para los procesos no están identificados.
No existe una definición de las responsabilidades.
Los objetivos no son claros y no hay lugar para la medición.
No existe un plan de entrenamiento y no hay un entrenamiento formal.
La gente toma responsabilidades basadas en sus iniciativas o actividades básicas e individuales.
Nivel 2
Mínimos conocimientos requeridos e identificados para áreas críticas.
Los empleados asumen sus responsabilidades en un acuerdo informal.
Existen algunos objetivos y algunas métricas financieras están establecidas pero solo son conocidas por la alta gerencia.
El entrenamiento es siempre en base a las necesidades del plan básico e informal.
Existe una confusión de las responsabilidades cuando ocurren problemas y cuando la cultura de culpa tiende a existir.
Existe inconsistencia y aislamiento en el control de las áreas.
Nivel 3
Los requerimientos de conocimientos son definidos y documentados para todas las áreas.
El proceso de asignación de responsabilidades esta definido e identificado.
Existen algunos objetivos de eficiencia y se establecen medidas, pero no son notificadas y no existe un objetivo claro de
52
ellas.
El plan formal de entrenamiento es desarrollado pero basado en iniciativas individuales.
El proceso de propietarios de los procesos es poco probable que contenga toda la autoridad para ejercer sus responsabilidades.
Surge el proceso de medición pero no es consistentemente aplicado. El cuadro de ideas de IT es adoptado como una ocasional e intuitiva aplicación de análisis.
Nivel 4
Los requerimientos de conocimientos son actualizados rutinariamente para todas las áreas, garantizando y alentando a obtener certificaciones.
El proceso de asignación de responsabilidades es aceptado y se trabaja en la manera que permita al proceso de propietarios delegar su responsabilidad.
La eficiencia y eficacia son medidas y comunicadas alineándolas a los objetivos del negocio y el plan estratégico de IT. El cuadro de ideas es implementado en algunas áreas con excepciones basadas en la medición y el análisis de causas es estandarizado.
Maduras técnicas son aplicadas de acuerdo al plan de entrenamiento e intercambio. Todos los expertos internos son involucrados y el plan de entrenamiento es evaluado.
Una cultura de recompensa en lugar de motivaciones. Surge la mejora continua.
Nivel 5
La organización alenta al continuo incremento de los conocimientos, del personal y de los objetivos de la misma.
El proceso de propietarios de procesos esta facultado para tomar decisiones y acciones.
Existe una integración y mejoramiento del sistema de medición aliniado a la mejora de IT y los objetivos del negocio.
Entrenamiento externo de las mejores prácticas y el uso de conceptos técnicos.
La aceptación de responsabilidades es en forma descendente a trvés de la organización.
Las excepciones son globales y consistentemente establecidas, el análisis de causas es aplicado
El incremento de los conocimientos es una cultura organizacional. Expertos externos y líderes son usados en la orientación.
La mejora continua es una forma de vida.
Tabla 10. Segunda parte de la Matriz de CMMI
53
4.2 EVALUACIÓN DE LOS NIVELES DE MADUREZ PARA LOS DIFERENTES PROCESOS. La tabla anterior se llevo a un estándar el cual se aplicó para cada uno de los procesos utilizados
en este momento en TTD Group, quedando los siguientes resultados:
(VER ANEXO IX)
Imagen 5. Capacidad y Madurez de los Procesos por Dominios
Imagen 6. Comparación de los Niveles Capacidad y Madurez por Procesos
54
CAPITULO 5. IMPLEMENTACIÓN DE LA MESA DE SERVICIO
Una vez que fue comprado el software FootPrints de NUMARA, se procedió a realizar toda la
documentación previa que se requería para su correcta instalación y configuración la cual consistía
en, llenar formatos en Excel que fueron enviados por el proveedor.
Después de revisada internamente dicha información, fue enviada al proveedor para su
configuración en el sistema y de esta forma solo se presentará a la Instalación formal del mismo.
5.1 INSTALACIÓN
El proceso de Instalación fue realizado por el encargado de Seguridad Informática y Servidores de
TTD Group, junto con el técnico de la empresa proveedora del software, y los únicos datos y
requisitos que se nos pidieron fueron:
• Espacio para la instalación de las Bases de Datos y el exe del software en el servidor de
aplicaciones Web de Windows Server 2003.
• Nombre del Servidor SMTP
• User ID para iniciar sesión en FootPrints
• Contraseña del User ID
• Correo Electrónico del Administrador de FootPrints
• Nombre del Proyecto de FootPrints
• Nombre para la Libro de Contactos
• Ruta de instalación de la herramienta dentro del Servidor Web
• Nombre del Servidor SQL, para alojar la Base de Datos
• Contraseña de SA del Servidor de SQL
Este proceso fue muy sencillo y no requirió más de 15 minutos, además de que el paquete de
instalación es tan fácil que solo va pidiendo los datos anteriores, para después ir dando clic en
siguiente, siguiente, siguiente y finalizar, con la instalación tanto del software como de la Base de
Datos.
5.2 CONFIGURACIÓN
Este proceso dependió en gran parte de un proceso previo de captura de Esquemas en Excel, que
fueron solicitados por el proveedor de FootPrints.
Los esquemas de información para la configuración solicitaban básicamente, la siguiente
información:
• Categorización de Estatus para los Casos
55
• Tipos de Prioridades
• Clasificación de Incidencias divididas en:
Categoría
Tipo
Subtipo
Subsubtipo
• Sistemas y/o Servicios
• Áreas que reportan
• Esquemas de Pantallas de Captura de información para la creación de Tickets
• Usuarios bajo Licencias (5 nombradas) cada uno con:
Nombre de Equipo
User ID
Área
Contraseña de Acceso a FootPrints
Correo Electrónico
Rol en FootPrints
• Configuración de Acuerdo de Niveles de Servicio (SLA)
• Notificaciones Especiales
• Asignaciones Automaticas
• Escalonaciones
• Roles y Perfiles
• Permisos para los Roles y Perfiles
• Encuesta de Satisfacción para Clientes
Además fue necesaria la elaboración de una Base de Datos con información de cada uno de los
Clientes y/o Usuarios a los que brindará servicio la Mesa de Servicio.
La información requerida para cada Cliente y/o Usuario fue:
• User ID
• Nombre del Equipo
• Nombre del Usuario
• Marca de PC
• Modelo de PC
• Número de Serie de PC
• Sistema Operativo
• Tamaño de RAM
• Tipo de Preocesador
• BIOS
56
• IP
• MAC
• NIC
• DHCP
• GW
Una vez enviada y revisada esta información el Técnico del proveedor la configuró en el software.
5.3 CAPACITACIÓN
La capacitación por parte del proveedor se dividió dos sesiones:
La primera comprendió un curso presencial para todos los miembros de la Dirección de Tecnología
y Operaciones, el cual duró 5 horas y prácticamente se presentó la herramienta, sus funciones,
beneficios, pantallas de captura y funciones que puede realizar en agente no Administrador, que
utilice el software.
La segunda consistió en 3 horas adicionales con el futuro Administrador del Sistema, y aquí
básicamente se capacito para la administración del proyecto o proyectos futuros, como crear
tickets, métricas del uso del software, como realizar modificaciones a las configuraciones, permisos
y roles ya establecidos.
Además se nos proporcionó un manual de usuario y una memoria técnica de la instalación y
configuración de FootPrints.
5.4 PRUEBA PILOTO
Una vez comprendida la herramienta y después de haber practicado con algunos tickets de
atención, levantados para cada uno de los 4 agentes que se crearon, se procedió a una prueba
piloto durante 2 semanas, la cual se realizó de la siguiente manera:
Se aviso a un número reducido de usuarios, en total 20 usuarios; del nuevo número telefónico de
atención de la Dirección de Tecnología y Operaciones y se les informó el proceso del servicio
brindado por la Mesa de Ayuda, el cual consiste en:
1. Una vez detectada una falla, error o duda tecnológica, el usuario llama a la extensión 6789.
2. Un operador de la Mesa de Ayuda, contestará y solicitará información sobre el caso, en
primer instancia intentar resolverlo vía telefónica, de no ser así solicitará mas información
que ayude a describir el caso e informará al usuario que asignará a un Ingeniero para la
resolución personalizada del caso.
3. El caso será asignado mediante un correo electrónico al Ingeniero en turno, con lo cual el
validará la información recibida y se pondrá en contacto con el usuario, para solucionar la
incidencia ya sea de manera remota o presencial.
57
4. Una vez concluido el caso, el Ingeniero lo reporta en el sistema y lo cierra ya sea con una
descripción de las actividades realizadas o bien creando una solución interna que se
almacenará en la Base de Conocimientos para su futura revisión y uso.
Las llamadas recibidas durante la 1era semana fueron 4. Y durante la segunda semana 6. Más
adelante mostraremos la gráficas ejemplo de dichas llamadas recibidas.
Ahora será necesario explicar como es la creación y cierre de casos en FootPrints.
5.4.1 Creación de un Caso:
Para acceder a la Mesa de Ayuda hay que teclear la Dirección URL en el navegador de Internet,
para después escribir el Login y Password correspondiente al Administrador del Sistema.
Imagen 7. Pantalla de Login de FootPrints
Una vez que son autorizados los datos, el sistema muestra la Pantalla Principal de la Mesa de
Ayuda, la cual se compone del menú izquierdo, tablero de información y el listado de los casos,
abiertos, cerrados, pendientes y atrasados.
Imagen 8. Pantalla Principal de FootPrints
Para crear un caso se debe dar clic en el menú izquierdo en la opción CASO, donde se despliega
una ventana nueva para que sea en esta donde se levante el caso.
58
Imagen 9. Menú de FootPrints, Opción Caso
La parte superior de la pantalla solicita información general del caso y del usuario que la reporta,
en la parte inferior aparece diversas pestañas de información, para complementar la información
del caso.
Imagen 10. Pantalla de Creación de un Nuevo Caso
La primer pestaña carga la información directamente de la Base de Datos, llenando los campos de
información del equipo de cómputo del usuario que lo reporto, esta también puede ser modificada
de manera manual y siempre trae los datos con solo colocar el USER del usuario.
Imagen 11. Información del Contacto, misma que trae de la Base de Datos
La segunda pestaña, permite categorizar de forma más detallada el caso, y en caso de así requerir
solicita más información del mismo, en pantallas emergentes.
59
Imagen 12. Más información del Caso a Detalle
La tercera pestaña permite describir en oraciones la información que el usuario proporciona al
operador y de esta manera poder anexar detalles que sean útiles para la solución del caso.
Imagen 13. Descripción del Caso
La cuarta pestaña, permite anexar archivos adjuntos al caso, de cualquier extensión y que sean
necesarios para describir o bien dar solución al caso.
Imagen 14. Adjuntos del Caso
La quinta pestaña es donde se asigna a un Ingeniero para la resolución del caso y al mismo tiempo
se puede enviar copia del caso a un tercero o a un revisor, que puede ser el Director de Tecnología
de Información o Administrador del Sistema.
Imagen 15. Asignaciones y Notificaciones
La sexta y última pestaña solo valida la fecha y hora de registro del caso.
60
Imagen 16. Tiempo Dedicado
5.4.2 Cerrar un Caso
Después de creado el caso la herramienta envía un mail de asignación del mismo al Ingeniero que
fue asignado, para que este lo tome. Y posteriormente vaya al link que trae el mail y pueda
modificarlo, cerrarlo o escalarlo.
Cada vez que un Ingeniero entra a su cesión este podrá también cerrar o modificar sus casos
asignados.
Imagen 17. Opción de Cerrar el Caso
Una vez elegida la opción de cerrar se muestra la pantalla de Cerrar Caso, donde se muestra un
espacio muy similar al encontrado en la pantalla de crear un caso, descripción, donde se podrá
teclear cual fue la solución y algunos otros datos.
Imagen 18. Información para Cerrar el Caso
61
Si se presentarán varios casos que se solucionen con la misma respuesta, es más práctico crear
un solución en la Base de Conocimiento para su futura consulta, esto se realiza en el Menú
Izquierdo opción Base de Conocimientos, Agregar.
Imagen 19. Menú de FootPrints, Opción Base de Conocimientos
Aparece un pantalla muy similar a la de crear caso, en la que se nos solicita información del caso
global, como se llama en FootPrints y que pueden ser resueltos con la misma solución, además de
una descripción de la misma, también se pueden anexar archivos adjuntos y dejar Ingenieros
asignados preestablecidos.
Imagen 21. Crear nueva solución con Información del Caso
Imagen 22. Descripción de la Solución
62
Existen diversas formas para crear informes tanto por persona, proyecto, equipos y dichos informes
se pueden ir configurando de manera manual en las opciones Informe y Panel de Control del Menú
izquierdo, estas modificaciones solo las puede realizar el Administrador del Sistema, un ejemplo de
Informe es el que a continuación se presenta.
Imagen 22. Un ejemplo de Informe de FootPrints
Dicho informe muestra los tickets que fueron atendidos durante las dos semanas de Prueba Piloto,
por la fecha en que fueron recibidos y cerrados, pero existen más de 20 diferentes métricas de
evaluación de resultados de forma individual y por equipo.
5.5 PLAN DE COMUNICACIÓN DE LA MESA DE AYUDA A LAS ÁREAS USUARIAS
Para dar a conocer de manera general el Servicio de Mesa de Ayuda en TTD Group, se estableció
la siguiente dinámica:
1. Elaborar un mail con la información referente a la Mesa de Ayuda a todos los trabajadores
de TTD Group, siendo el Director de Tecnología y Operaciones el encargado de la emisión
del mismo.
2. Crear carteles de anuncio de la Mesa de Ayuda, mismo que aparecerán en las áreas
comunes de la empresa.
3. Elaborar tarjetas de tamaño presentación que serán entregadas a cada usuario con el
número de extensión de la Mesa de Ayuda, para que la coloquen cerca de su equipo de
cómputo y les recuerde el número que deben marcar en caso de requerir ayuda de la
Dirección de Tecnología y Operaciones. Aunado a la entrega de tarjetas se planea dar una
breve explicación a cada usuario sobre los beneficios de la atención vía la Mesa de Ayuda.
(VER ANEXO X y XI)
63
Una vez que pasen 3 meses de la entrega del Proyecto, se planteó realizar una evaluación en tipo
cuestionario de preguntas cerradas a cada uno de los usuarios, para de esta manera poder
conocer su opinión sobre el servicio y la atención de los Ingenieros y así poder realizar
modificaciones o correcciones en el procedimiento realizado. El cuestionario no deberá de ser
mayor a 10 preguntas y se irán elaborando a lo largo de la utilización del mismo sistema. El
cuestionario será confidencial.
En caso de que la gente por su mala costumbre siga llamando al Ingeniero de su preferencia y no
a la Mesa de Ayuda, se planteó que se deberá desviar la llamada a un correo de voz el cual les
recuerde el número de extensión con el siguiente mensaje:
“El Ingeniero que intento contactar no se encuentra disponible, por lo que le hacemos la más
cordial invitación a llamar a la Mesa de Ayuda Extensión 6789 y un Ingeniero lo atenderá
inmediatamente, gracias.”
64
CONCLUSIONES
Una vez que se terminó con la parte de la documentación y elaboración de diagramas, se
emprendió la búsqueda de alternativas que satisficieran en su totalidad los requerimientos
necesarios para implementar una herramienta eficaz que cubriera la normatividad de ITIL, esta
solución resulto ser FootPrints de Numara Software, la cual cubrió más puntos de los requeridos y
analizados en la evaluación.
La Implementación, Instalación, Configuración, Capacitación y Prueba Piloto del software fue muy
sencilla y logró centralizar las llamadas de los usuarios en un único punto de contacto, al mismo
tiempo que permitió registrar los casos presentados, solicitudes realizadas y las soluciones
resultantes, con lo que las Gestiones de Incidentes, Cambios, Problemas y Mesa de Ayuda
quedaron cubiertas, permitiendo así poder trabajar bajo un estándar óptimo, donde la
documentación es la base del éxito en la entrega de servicios.
Hoy TTD Group cuenta con una Mesa de Ayuda de calidad, permitiendo así a su Dirección de
Tecnología y Operaciones brindar un soporte técnico, ágil, oportuno, personalizado y controlado
además de medido y evaluado con regularidad para no dejar de la mano la premisa de la mejora
continua que es una bandera con la que todas las empresas de clase mundial deberías de laborar.
BIBLIOGRAFÍA LIBROS
• Peltier, Thomas R., “Information Security Policies, Procedures, and Standards:
Guidelines for effective information security management”, (2000), 1ª ed, AUERBACH.
• Baca Urbina,Gabriel, “Evaluación de Proyectos”, (2006), 1ª ed, MCGRAW-HILL
• Combalia, Patricia Lic., “Conceptos Generales sobre ITIL, (2005), itSMF .
• Lloyd, Vernon, “ITIL Planning to Implement Service Management”, (2002). 1ª ed,
HMSO.
REFERENCIAS DE INTERNET • http://www.itil-officialsite.com/home/home.asp+
http://www.itil.org/en/vomkennen/itil/index.php
• http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/fundamentos_de_la_gestion_TI/qu
e_es_ITIL/que_es_ITIL.php
• http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/service_desk/vision_general_servic
e_desk/vision_general_service_desk.php
• http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_incidentes/vision_gene
ral_gestion_de_incidentes/vision_general_gestion_de_incidentes.php
• http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_cambios/vision_genera
l_gestion_de_cambios/vision_general_gestion_de_cambios.php
• https://www.pinkelephant.com/es
• http://www.pmi-v.org.ve/Educacion/madurez_diez.pdf
• http://www.itsmsolutions.com/newsletters/DITYvol2iss17.htm
• http://www.gennoa.com.ar/node/24
• http://www.cioconsultores.cl/Articulos/Art_ITIL.htm
• http://es.tech-faq.com/itil.shtml
• http://www.datati.es/itil-el-manual-de-las-buenas-practicas-de-ti/
• http://www.footprints-
spain.com/Numara_Footprints/Caracteristicas_Footprints/__wCtishAlzgTyf9nk3KwfQ
• http://documents.bmc.com/products/documents/77/15/67715/67715.pdf
• http://www.computernet.co.cr/pdf/uservicedeskv6.pdf
• http://www.ca.com/ar/products/product.aspx?id=191#overview
• http://www.isaca.com.mx/.
• http://www.sei.cmu.edu/cmmi/general/index.html
MANUALES • Manuales de introducción a la implementación de ITIL.
65
ANEXOS
2.4.1 GESTIÓN DE INCIDENCIAS
SALIDAPROCESOENTRADA
CMDB
Reporte de incidencia
Reporte Workaround
Reporte de Información del
Incidente
Asignar el requerimiento del usuario al personal
de Sistemas responsable de las
Incidencias
Registrar el requerimiento del
usuario un número de control de Incidencia
Evalúar la Incidencia reportada por el usuario
Atiende la Incidencia reestableciendo de
inmediato la continuidad del servicio al usuario
Elabora el “workaround” correspondiente de la solución que efectuó
para resolver la Incidencia
Consultar el “Workaround” para
estandarizar los detalles de solución para
resolver la Incidencia
Información de Configuración
(CMDB)
Consultar expedientes de Incidencias anteriores o cambios ya realizados,
en su caso
Consultar la CMBD para identificar la posible solución de la Incidencia
La Incidencia es un problema conocido?
Asignar al personal correspondiente el
requerimiento
Si
NoEs posible resolver
la Incidencia?
Escalar y asignar la Incidencia al proceso de Gestión de problemas
Asignar la incidencia a la Gestión de problemas
para su resolución
Atiende y cierra la Incidencia
No
Si
Realiza los Informes de Gestión
correspondientes
Obtiene la información para la resolución de la Incidencia, en su caso
Proceso de Gestión Service
Desk
Gestión Problemas
Solicitud de servicioInforma a Service Desk
la problemática detectada en la
Incidencia
66
SALIDAPROCESOENTRADA
2.4.2 GESTIÓN DE MESA DE AYUDA
Reporte de Información del Incidente
Recibir llamada telefónica del usuario
Capturar la información del Cliente
Priorizar la atención del Incidente con base en los niveles de servicio
(SLAs)
Inicializa un contador de tiempo para la atención
del Incidente de acuerdo al (SLA) definido
Requerimiento de Servicio
Entrar a un proceso de atención definido por el
personal del área de sistemas:
Incidente pertenece a PRESIDENCIA?
No
Si
Monitorear el Incidente de acuerdo con los niveles de servicio
establecidos (SLAs)
Se dio solución al reporte ? Cierre del Reporte
Entrar al proceso de Gestión de Problemas
Informar al Cliente del estatus el reporte
Si
No
Reporte de Información del Incidente
Documento de Información del
Incidente
Servicio Completado
Herramienta Service Desk:. Nombre Usuario. Fecha de reporte. Descripción del Incidente. Dirigido :A) Primer NivelB) Segundo Nivel. Fecha y hora de reporte. Escalado a 2o nivel. Fecha y hora (fin de reporte)
Proceso de Gestión de incidentes
Proceso de gestión de problemas
67
2.4.3 GESTIÓN DE PROBLEMAS
SALIDAPROCESOENTRADA
REGISTRO de Errores conocidos
REGISTRO EN FORMATOS DE WORKAROUND
REGISTRO EN FORMATOS BASE-LINE
REGISTRO EN FORMATOS RFC
Reporte de incidencias
INCIDENCIAS
Recibir reporte de incidencias
Atender incidente de acuerdo con su prioridad
Determinar si el problema es un error conocido (BASE-
LINE)
1
2
3
Clasificación de la atención del incidente en Alto, Medio, Bajo en
función del tipo de usuario que solicita el servicio PRESIDENCIA O
Empleados
ES UN BASE- LINE?
4
Diagnosticar e Investigar la causa
raíz del error5
Base de datos de soluciones
conocidas
BASE-LINE
INCIDENCIA DEL
SERVICE DESK
1.Evaluación de los medios para resolver el error2. Asignar los recursos necesarios3. Escalamiento del problema
Se requiere escalamiento?
6
NO
SI
A
A
Escalar el error a:Soporte de 3er. NivelProveedor
SI
NO
Reportar a Service Desk el escalamiento y el tiempo
estimado de solución
Turnar el incidente o problema a:
Soporte de 3er. NivelProveedor
SOLUCIONAR ERROR
Problema resuelto ?
TIPO DE SOLUCIÓN
RESOLVER CON CAMBIO RESOLVER CON SOLUCIÓN
PROVISIONAL
SOLUCIÓN DEFINITIVA
SOLUCIÓN TEMPORAL
SOLUCIÓN DEFINITIVA
RESOLVER SIN CAMBIO
PROCESO DE GESTIÓN DE
CAMBIOS
SI
NO
PROCESO DE SOPORTE 2o
NIVEL/PROVEEDOR
Registrar el error en el formato de errores conocidos
B
B
Evaluar y probar soluciones
INCIDENCIA / PROBLEMA RESUELTO
7
8
9
10
11
12
13
1415 16
17
18
Base de datos de soluciones temporales
WORKAROUNDS
Base de datos
de RFCs
REGISTRO DE REPORTES
DE SERVICIO
Actualización de la Base de
Datos de soluciones conocidas
BASE-LINE
Actualización de la Base de Datos de
soluciones temporales
WORKAROUNDS
Actualización de la Base de
Datos de RFCs
68
SALIDAPROCESOENTRADA
2.4.4 GESTIÓN DE CAMBIOS
CMDB
Documento Plan de Cambios
Documento Plan de Cambios
Documento Plan de Cambios
Aprobación (RFC)
Documento de Plan de Cambios
Documento Especificación del
Cambio
Documento Especificación del
Cambio
Documento Especificación del
Cambio
Recopila la información necesaria para efectuar
el cambio
Analiza y determina el impacto, la categoría y las características del
cambio
Asigna una prioridad al cambio
Analiza y evalua los riesgos del cambio
Realiza un plan de cambios involucrando a todas las áreas usuarias que serán afectadas por
el cambio
Solicitud de Cambios (RFC)
Comunica y obtiene aprobaciones del comité
(CAB) para el cambio
Coordina la comunicación de los
cambios y Determina los recursos necesarios para implementar los
cambios
Obtiene los (Cis) correspondientes y
necesarios para ejecutar la implementación de los
cambios
Realiza pruebas en ambiente controlado de
los cambios a implementar
Autoriza las pruebas realizadas por el CAB
Documento Evaluación Post Implementación
Informe Gestión Cambios
PROGRAMA DE CAMBIOS
B
Se efectuará el cambio?
A
Si
PROCESO DE GESTIÓN DE
CONFIGURACIONES
Realiza un plan de comunicación y difusión de cambios a las áreas y
usuarios
Realiza un plan de ROLLBACK de contingenciaNO
A
C
C
Implementa los cambios según el programa
estable
Se implementó el cambio
correctamente?
Revisa y evalua cambios post-Implementación
Si
Aplicar plan ROLLBACK
Revisa y evalua errores en el
cambio
No
B
Actualiza documentación de (Cis) /BASE-LINE
Especifica en documento RFC el
motivo del rechazo del cambio
Programa Adelantado de Cambios (FCS)
RFCs Detallados o Actualizados
69
GESTIÓN DE PROBLEMAS
Número de Ticket.:
Formato de Atención de Incidencia
Página 1 de 1
Nombre del Usuario:
Tipo de de Usuario:
Tipo de Urgencia:
Clasificación de la Incidencia: Palabras Clave: Fecha y Hora del Elaboración: 03 de abril de 2009 09:14
Fecha y Hora del Cierre: 03 de abril de 2009 09:14
Responsable 1er Nivel
Nombre
Responsable 2do Nivel
Nombre
Responsable 3er Nivel
Nombre Fecha: 03 de abril de 2009 Fecha: 03 de abril de 2009 Fecha: 03 de abril de 2009
Descripción De la Incidencia: Descripción de la Solución: FECHA HORA
ACTIVIDAD
03/04/09 11:15 am
Observaciones:
70
GESTIÓN DE INCIDENCIAS
Número de Ticket: Número de Workaround:
Solución Temporal (Workaround) Página 1 de 1
Nombre del Usuario:
Tipo de de Usuario:
Tipo de Urgencia:
Palabras Clave:
Tipo de Incidencia: Fecha y Hora del Elaboración: 07 de abril del 2009 09:45
Responsable 1er Nivel
Nombre
Responsable 2do Nivel
Nombre
Responsable 3er Nivel
Nombre Fecha: 07 de abril del 2009 Fecha: 07 de abril del 2009 Fecha: 07 de abril del 2009 71
Descripción de la Incidencia o Error Conocido: Descripción de la Solución Temporal o Workaround aplicado: FECHA HORA
ACTIVIDAD
07/04/09 11:15 am
Observaciones:
GESTIÓN DE CAMBIOS
Documento No.:
Solicitud Formal de Cambios (RFC).
Página 1 de
Palabras Clave:
Categoría de Impacto:
Tipo de Urgencia:
Categoría de Riesgos:
Fecha de Elaboración: 12 de agosto de 2009
Fecha de Cierre: 12 de agosto de 2009
Fecha de Revisión Post-Implementación: 12 de agosto de 2009
Responsable Ejecutor
Nombre
Autorizador
Nombre
Revisor de la Junta
Nombre Fecha: agosto de 2009 Fecha: agosto de 2009 Fecha: agosto de 2009
72
Descripción del Cambio: Evaluación de Riesgos:
Cuestionario de Evaluación de Riesgos para Cambios 1. ¿Cuántos usuarios se verán afectados por el cambio propuesto? PUNTUACIÓNMas de una área en especifico, toda la compañía o usuarios de presidencia. 3 ptos Un número considerable de usuarios o un área completa. 2 ptos Un usuario interno o externo de BAL. 1 pto 2. ¿Cuál es la estabilidad de la tecnología o de los proveedores del sistema? PUNTUACIÓNTecnología inestable con muy pocos conocimientos sobre ella. 3 ptos Tecnología variable, con un grado medio de conocimientos de la misma. 2 ptos Tecnología estable y bien conocida. 1 pto 3. ¿Cuál es la situación de los CI? PUNTUACIÓNSe conocen los requerimientos de recursos pero no se tienen claramente definidos en cantidad y disponibilidad. 3 ptos Se cuenta con los CI´s indispensables pero se desconoce la disponibilidad de cada uno de ellos. 2 ptos Se tienen listados cada uno de los CI´s necesarios con sus características y cantidades y están disponibles al momento del cambio. 1 pto 4. El procedimiento para la ejecución del cambio ha sido: PUNTUACIÓNNunca antes ejecutado por nadie del área. 3 ptos Ejecutado antes pero no se encuentra documentado. 2 ptos Realizado con anterioridad, esta documentado y sigue un plan de actividades y está constante mente en revisión y evaluación. 1 pto
GESTIÓN DE CAMBIOS
Documento No.:
Solicitud Formal de Cambios (RFC).
Página 1 de
Palabras Clave:
Categoría de Impacto:
Tipo de Urgencia:
Categoría de Riesgos:
Fecha de Elaboración: 12 de agosto de 2009
Fecha de Cierre: 12 de agosto de 2009
Fecha de Revisión Post-Implementación: 12 de agosto de 2009
Responsable Ejecutor
Nombre
Autorizador
Nombre
Revisor de la Junta
Nombre Fecha: agosto de 2009 Fecha: agosto de 2009 Fecha: agosto de 2009
73
5. ¿Cuál es la importancia de la tecnología o de los proveedores del sistema? PUNTUACIÓNProductos muy importantes para la realización de actividades de los usuarios. 3 ptos Productos con uso importante pero pueden ser sustituidos. 2 ptos Productos poco utilizados y no muy importantes. 1 pto
Eje X 15 PUNTOS 6. Basado en la experiencia pasada ¿Cuál es la probabilidad de una falla o problemas que resulten del cambio? PUNTUACIÓNAlto 3 ptos Medio 2 ptos Bajo 1 pto
7. En el caso de que el cambio falle o afecte negativamente a otros sistemas y servicios, ¿Cuál será el impacto de la ejecución del plan de contingencia PUNTUACIÓNAlto 3 ptos Medio 2 ptos Bajo 1 pto
Eje Y 6 PUNTOS Conclusión de la Evaluación de Riesgos: Minuta de Actividades: FECHA HORA
ACTIVIDAD
03/08/08 11:15 am
GESTIÓN DE CAMBIOS
Documento No.:
Solicitud Formal de Cambios (RFC).
Página 1 de
Palabras Clave:
Categoría de Impacto:
Tipo de Urgencia:
Categoría de Riesgos:
Fecha de Elaboración: 12 de agosto de 2009
Fecha de Cierre: 12 de agosto de 2009
Fecha de Revisión Post-Implementación: 12 de agosto de 2009
Responsable Ejecutor
Nombre
Autorizador
Nombre
Revisor de la Junta
Nombre Fecha: agosto de 2009 Fecha: agosto de 2009 Fecha: agosto de 2009
74
Requisitos de CI´s: Resultado de las Pruebas Antes de la Implementación: Resultado y Cierre de la Implementación. Resultado de la Revisión Post-Implementación: Observaciones
GESTIÓN DE CAMBIOS
Documento No.: 1
Acuerdo de Nivel de Servicio (SLA)
Página 1 de 1
Fecha de Elaboración:
Áreas Relacionadas:
Área Generadora:
Nombre del Servicio:
Vigente a partir de:
Elaboración y Emisión
Nombre
Revisó
Nombre
Autorizó
Nombre Fecha: Fecha: Fecha: 0
75
Definición y Objetivo del Servicio:
Características del Servicio:
Línea del Servicio:
Servicios Relacionados y/o Complementarios:
Servicios Soportados:
Vigencia:
Políticas Generales:
Alcance:
Disponibilidad del Servicio y Atención a Fallas:
Soporte y Mantenimiento:
GESTIÓN DE CAPACIDAD Y MADUREZ DE PROCESOS
Número de Evaluación:
Evaluación de los Procesos Página No:
Nombre del Proceso:
Tipo de Proceso:
Fecha y Hora del Elaboración:
Revisor Responsable
Nombre
Verificó
Nombre
Autorizó
Nombre Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009
76
Descripción del Proceso: Matriz de Evaluación para los Procesos:
Resultados
Nivel Objetivo General Objetivo Específico SI NO N/A Recomendaciones
0 Incompleto
Conciencia y Comunicación
Existe conciencia de la necesidad del proceso.
0 Incompleto
Conciencia y Comunicación
Existe comunicación de las cuestiones.
0 Incompleto Políticas, Planes y Procedimientos
Hay aproximamiento a los procesos y practicas.
0 Incompleto Políticas, Planes y Procedimientos
Los procesos y políticas están definidos.
0 Incompleto Herramientas y Automatización
Se cuenta con herramientas o paquetería de escritorio para el proceso que sigue le proceso.
0 Incompleto Herramientas y Automatización
Surge la necesidad de contar con herramientas o paqueterías de escritorio para la realización del proceso.
0 Incompleto Conocimientos y
Experiencia Las habilidades requeridas para los procesos empiezan a ser definidas.
0 Incompleto Conocimientos y
Experiencia Existe necesidad de un plan de entrenamiento formal.
0 Incompleto Responsabilidades
Existe definición de responsabilidades .La gente toma propiedad sobre los incidentes basado en su propia iniciativa y de forma reactiva
0 Incompleto Objetivos y Medición
Existen objetivos.
1 Realizado
Conciencia y Comunicación
La conciencia de la necesidad del proceso esta surgiendo.
GESTIÓN DE CAPACIDAD Y MADUREZ DE PROCESOS
Número de Evaluación:
Evaluación de los Procesos Página No:
Nombre del Proceso:
Tipo de Proceso:
Fecha y Hora del Elaboración:
Revisor Responsable
Nombre
Verificó
Nombre
Autorizó
Nombre Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009
77
1 Realizado
Conciencia y Comunicación
Existe comunicación esporádica de los incidentes.
1 Realizado Políticas, Planes y Procedimientos
Existen aproximamientos ad hoc a los procesos y practicas.
1 Realizado Políticas, Planes y Procedimientos
Los procesos y políticas están definidos.
1 Realizado Herramientas y Automatización
Pueden existir algunas herramientas; el uso esta basado en paquetería de escritorio.
1 Realizado Herramientas y Automatización
Existe un aproximamiento planeado a la utilización de herramientas.
1 Realizado Conocimientos y
Experiencia Las habilidades requeridas para los procesos están definidas.
1 Realizado Conocimientos y
Experiencia Existe un plan de entrenamiento y hay un entrenamiento formal.
1 Realizado Responsabilidades
Existe definición de deslindes y responsabilidades. La gente toma propiedad sobre los eventos surgidos basados en su propia iniciativa y de forma reactiva
1 Realizado Objetivos y Medición
Los objetivos están claros y ocurren mediciones.
2 Gestionado
Conciencia y Comunicación
Existe conciencia de la necesidad de actuar.
2 Gestionado
Conciencia y Comunicación
La gerencia comunica los eventos generales
2 Gestionado Políticas, Planes y Procedimientos
Emergen procesos similares y comunes, pero son en gran parte intuitivos debido al conocimiento individual.
2 Gestionado Políticas, Planes y Procedimientos
Algunos aspectos de los procesos son repetibles debido al conocimiento individual, y existen cierto entendimiento informal de algunas políticas, procedimientos y procesos.
GESTIÓN DE CAPACIDAD Y MADUREZ DE PROCESOS
Número de Evaluación:
Evaluación de los Procesos Página No:
Nombre del Proceso:
Tipo de Proceso:
Fecha y Hora del Elaboración:
Revisor Responsable
Nombre
Verificó
Nombre
Autorizó
Nombre Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009
78
2 Gestionado Herramientas y Automatización
Existen enfoques comunes para el uso y desarrollo de herramientas pero basados en soluciones y desarrollos individuales.
2 Gestionado Herramientas y Automatización
Se adquieren herramientas pero probablemente no son bien aplicadas.
2 Gestionado Conocimientos y
Experiencia
Se han identificado los conocimientos mínimos requeridos para áreas críticas.
2 Gestionado Conocimientos y
Experiencia
El entrenamiento se provee siempre en base a las necesidades, en lugar de un plan acordado, existe cierto entrenamiento informal durante las actividades
2 Gestionado Responsabilidades
Los empleados asumen sus responsabilidades y acciones incluso si no existe un acuerdo formal.
2 Gestionado Responsabilidades
Existe una confusión de las responsabilidades cuando ocurren problemas y una cultura de culpar al otro tiende a existir.
2 Gestionado Objetivos y Medición
Existen algunos objetivos y algunas métricas financieras establecidas pero solo son conocidas por la alta gerencia. Existe monitoreo inconsistente en áreas aisladas.
2 Gestionado Objetivos y Medición
Existe inconsistencia y aislamiento en el control de las áreas.
3 Establecido
Conciencia y Comunicación
Existe un entendimiento de la necesidad de actuar.
3 Establecido
Conciencia y Comunicación
La gerencia es más formal y estructurada en sus comunicaciones.
3 Establecido Políticas, Planes y Procedimientos
Surge el uso de buenas prácticas.
GESTIÓN DE CAPACIDAD Y MADUREZ DE PROCESOS
Número de Evaluación:
Evaluación de los Procesos Página No:
Nombre del Proceso:
Tipo de Proceso:
Fecha y Hora del Elaboración:
Revisor Responsable
Nombre
Verificó
Nombre
Autorizó
Nombre Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009
79
3 Establecido Políticas, Planes y Procedimientos
Los procesos, políticas y procedimientos son definidos y documentados para todas las actividades clave.
3 Establecido Herramientas y Automatización
Se ha definido un plan para el uso y estandarización de herramientas para automatizar los procesos.
3 Establecido Herramientas y Automatización
Las herramientas son usadas para los propósitos básicos, no todas pueden estar de acuerdo al plan, y no pueden integrarse completamente unas con otras
3 Establecido Conocimientos y
Experiencia
Los requerimientos de conocimientos son definidos y documentados para todas las áreas.
3 Establecido Conocimientos y
Experiencia
El plan formal de entrenamiento es desarrollado pero aun esta basado en iniciativas individuales.
3 Establecido Responsabilidades
Las responsabilidades y acciones en un proceso están definidas y los dueños de los procesos han sido identificados identificados.
3 Establecido Responsabilidades
El propietario del procesos es poco probable que tenga toda la autoridad para ejercer sus responsabilidades.
3 Establecido Objetivos y Medición
Existen algunos objetivos y métricas de eficiencia se han establecido, pero no son comunicados, y existe una clara relación entere los objetivos del negocio.
GESTIÓN DE CAPACIDAD Y MADUREZ DE PROCESOS
Número de Evaluación:
Evaluación de los Procesos Página No:
Nombre del Proceso:
Tipo de Proceso:
Fecha y Hora del Elaboración:
Revisor Responsable
Nombre
Verificó
Nombre
Autorizó
Nombre Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009
80
3 Establecido Objetivos y Medición
Surgen procesos de medición pero no son consistentemente aplicados. Se adoptan ideas del Cuadro de Mando de IT, así como su ocasional e intuitiva aplicación en análisis de causa‐efecto.
4 Predecible
Conciencia y Comunicación
Existe una comprensión de todos los requerimientos.
4 Predecible
Conciencia y Comunicación
Se utilizan técnicas de comunicación y herramientas estándar probadas.
4 Predecible Políticas, Planes y Procedimientos
El proceso es coherente y completo; se aplican las mejores prácticas internas.
4 Predecible Políticas, Planes y Procedimientos
Todos los aspectos de los procesos son documentados y repetibles. Las políticas son aprobadas. Existen estándares para desarrollo y mantenimiento de procesos, los cuales son adoptados y usados.
4 Predecible Herramientas y Automatización
Las herramientas son implementadas de acuerdo a un plan estandarizado y algunas han sido integradas a otras herramientas relacionadas.
4 Predecible Herramientas y Automatización
Se utilizan herramientas automáticas en la gestión del proceso y monitoreo de actividades críticas y controles.
4 Predecible Conocimientos y
Experiencia
Los requerimientos de conocimientos son actualizados rutinariamente para todas las áreas, se garantiza el profesionalismo en las áreas críticas y se alienta la obtención de certificaciones.
GESTIÓN DE CAPACIDAD Y MADUREZ DE PROCESOS
Número de Evaluación:
Evaluación de los Procesos Página No:
Nombre del Proceso:
Tipo de Proceso:
Fecha y Hora del Elaboración:
Revisor Responsable
Nombre
Verificó
Nombre
Autorizó
Nombre Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009
81
4 Predecible Conocimientos y
Experiencia
Maduras técnicas son aplicadas de acuerdo al plan de entrenamiento e intercambio. Todos los expertos internos son involucrados y el plan de entrenamiento es evaluado.
4 Predecible Responsabilidades
El proceso de asignación deresponsabilidades y acciones esta aceptado y se utiliza de tal la manera que permite al propietario del proceso delegar completamente sus responsabilidades.
4 Predecible Responsabilidades
Existe una cultura de recompensas que motiva la acciones positivas.
4 Predecible Objetivos y Medición
La eficiencia y eficacia son medidas, comunicadas y alineadas a los objetivos del negocio y el plan estratégico de IT. El Cuadro de Mando de IT es implementado en algunas áreas con excepciones conocidas por la gerencia y el análisis "causa‐efecto" se estandariza. Emerge la mejora continua.
4 Predecible Objetivos y Medición
Surge la mejora continua.
5 En Optimización Conciencia y Comunicación
Existe un entendimiento proactivo de los requerimientos.
5 En Optimización
Conciencia y Comunicación
Comunicación proactiva de las cuestiones basada en tendencias. . Maduras técnicas de comunicación aplicadas e integradas a las herramientas en uso.
5 En Optimización Políticas, Planes y Procedimientos
Son aplicadas las mejores prácticas y los estándares externos.
GESTIÓN DE CAPACIDAD Y MADUREZ DE PROCESOS
Número de Evaluación:
Evaluación de los Procesos Página No:
Nombre del Proceso:
Tipo de Proceso:
Fecha y Hora del Elaboración:
Revisor Responsable
Nombre
Verificó
Nombre
Autorizó
Nombre Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009
82
5 En Optimización Políticas, Planes y Procedimientos
La documentación del proceso ha evolucionado a flujos de trabajo automáticos. Los proceso, políticas y procedimientos están estandarizados ye integrados para permitir gestión y mejora de principio a fin.
5 En Optimización Herramientas y Automatización
Se utilizan herramientas estandarizadas en toda la empresa.
5 En Optimización Herramientas y Automatización
Las herramientas están totalmente integradas con otras herramientas similares para permitir soportar los procesos de principio a fin.
5 En Optimización Herramientas y Automatización
Las herramientas son usadas para soportar la mejora del proceso y detectar automáticamente excepciones de control.
5 En Optimización Conocimientos y
Experiencia
La organización alenta de manera formal la continúa mejora de habilidades y adquisición de conocimientos, basada en objetivos personales y organizacionales claramente definidos.
5 En Optimización Conocimientos y
Experiencia
Entrenamiento externo de las mejores prácticas y el uso de conceptos técnicos.
5 En Optimización Conocimientos y
Experiencia
El incremento de losconocimientos es una cultura organizacional. Expertos externos y líderes son usados en la orientación.
5 En Optimización Responsabilidades
Los dueños de los procesos están facultados para tomar decisiones y acciones.
GESTIÓN DE CAPACIDAD Y MADUREZ DE PROCESOS
Número de Evaluación:
Evaluación de los Procesos Página No:
Nombre del Proceso:
Tipo de Proceso:
Fecha y Hora del Elaboración:
Revisor Responsable
Nombre
Verificó
Nombre
Autorizó
Nombre Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009
83
5 En Optimización Responsabilidades
La aceptación de responsabilidades ha sido permeada en forma descendente a través de la organización de forma consistente.
5 En Optimización Objetivos y Medición
Existe una integración y mejoramiento del sistema de medición aliñado a la mejora de IT y los objetivos del negocio.
5 En Optimización Objetivos y Medición
Las excepciones son consistentemente evaluadas de manera global por la dirección y el análisis de causa‐efecto es aplicado.
5 En Optimización Objetivos y Medición
La mejora continua es una forma de vida.
La escala de evaluación de cada nivel será: Para el Nivel 0 Incompleto: De 0 a 2 respuestas con NO………Nivel Logrado. De 3 a 5 respuestas con NO………El nivel se logro en gran medida. De 6 a 8 respuestas con NO………El nivel se logro en parte. De 9 a 10 respuestas con NO…….No se logró este nivel. Para el Nivel 1 Realizado: De 0 a 2 respuestas con NO………Nivel Logrado. De 3 a 5 respuestas con NO………El nivel se logro en gran medida. De 6 a 8 respuestas con NO………El nivel se logro en parte. De 9 a 10 respuestas con NO…….No se logró este nivel. Para el Nivel 2 Gestionado: De 0 a 2 respuestas con NO………Nivel Logrado. De 3 a 6 respuestas con NO………El nivel se logro en gran medida. De 7 a 10 respuestas con NO………El nivel se logro en parte. De 11 a 12 respuestas con NO…….No se logró este nivel. Para el Nivel 3 Establecido: De 0 a 2 respuestas con NO………Nivel Logrado. De 3 a 6 respuestas con NO………El nivel se logro en gran medida. De 7 a 10 respuestas con NO………El nivel se logro en parte. De 11 a 12 respuestas con NO…….No se logró este nivel. Para el Nivel 4 Predecible: De 0 a 2 respuestas con NO………Nivel Logrado.
GESTIÓN DE CAPACIDAD Y MADUREZ DE PROCESOS
Número de Evaluación:
Evaluación de los Procesos Página No:
Nombre del Proceso:
Tipo de Proceso:
Fecha y Hora del Elaboración:
Revisor Responsable
Nombre
Verificó
Nombre
Autorizó
Nombre Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009 Fecha: 04 de agosto de 2009
84
De 3 a 6 respuestas con NO………El nivel se logro en gran medida. De 7 a 10 respuestas con NO………El nivel se logro en parte. De 11 a 12 respuestas con NO…….No se logró este nivel. Para el Nivel 5 En Optimización: De 0 a 2 respuestas con NO………Nivel Logrado. De 3 a 7 respuestas con NO………El nivel se logro en gran medida. De 8 a 12 respuestas con NO………El nivel se logro en parte. De 13 a 15 respuestas con NO…….No se logró este nivel. Conclusión de la Evaluación:
La Mesa de Ayuda tiene como principales objetivos:
♦ Proporcionar el primer contacto para todas las llamadas de los usuarios de TTD Group, siendo así el canal de comunicación entre los usuarios y la Dirección de Tecnología y Operaciones.
♦ Facilitar la restauración de los servicios de Tecnología de Información, de acuerdo con las prioridades de atención y a los niveles de servicio establecidos para la atención de incidencias.
♦ Proporcionar valor a la organización manteniendo el estado óptimo de los recursos y servicios tecnológicos dispuestos para la operación de TTD Group.
¿Para que sirve ?¿Para que sirve ?¿Para que sirve ?¿Para que sirve ?
Procedimiento para la Procedimiento para la Procedimiento para la Procedimiento para la atención atención atención atención
1. Si tienes dudas o problemas relativos al uso de tu equipo de cómputo, o de los servicios que ofrece la Dirección de Tecnología y Operaciones, llama a la Mesa de Ayuda:
Extensión 6789
2. Un operador intentará dar solución vía telefónica o bien obtener un diagnóstico del problema.
3. Si el problema no es resuelto por el operador, éste asignará a un ingeniero, para su atención personalizada.
Marca la Extensión:
6789
MESA DE AYUDA MESA DE AYUDA MESA DE AYUDA MESA DE AYUDA
D I R E C C I Ó N D E T E C N O L O G Í A Y O P E R A C I O N E S
JULIO 2009JULIO 2009JULIO 2009JULIO 2009
85
D I R E C C I Ó N D E T E C N O L O G Í A Y O P E R A C I O N E S
Extensión:
6789
Servicio de ayuda cuyo
objetivo principal es resolver
problemas y dudas relativos al
uso de los equipos de cómputo
y comunicaciones, siendo el
primer contacto de los usuarios
de TTD Group con la Dirección
de Tecnología y Operaciones. JULIO 2009JULIO 2009JULIO 2009JULIO 2009
MESA DE AYUDA MESA DE AYUDA MESA DE AYUDA MESA DE AYUDA