GRUPO 3 - Administracion y Auditoria de Sistemas MDT

Administración y Auditoría de TI
ESCUELA POLITÉCNICA DEL EJÉRCITO

MAESTRÍA EN GERENCIA DE SISTEMAS
MÓDULO: ADMINISTRACIÓN Y AUDITORIA DE LAS TIC’S
TRABAJO: PROCESOS DE TI DEL MINISTERIO DE TRABAJO
DOCENTE: Ing. Giovanni Roldán Crespo
MAESTRANTES:
Alejandro Martínez
Verónica Niza
Fabricio Rivera
Daniel Uribe
Paola Villacrés
QUITO - 2015
1
CONTENIDO
1. RESUMEN EJECUTIVO .........................................................................................................................3

1.1. ANTECEDENTES ...........................................................................................................................4
1.2. INTRODUCCIÓN...........................................................................................................................4
1.3. PRINCIPALES PRODUCTOS Y/O SERVICIOS..................................................................................5
1.4. PRINCIPALES MERCADOS Y CLIENTES .........................................................................................5
1.5. MISIÓN Y VISIÓN .........................................................................................................................5
1.6. ESTRUCTURA Y ORGANIZACIÓN DE LA EMPRESA.......................................................................5
1.6.1. ORGANIGRAMA ESTRUCTURAL DE LA EMPRESA ................................................5
1.6.2. ESTRUCTURA Y ORGANIZACIÓN DE TIC .................................................................6
1.7. NÚMERO DE PERSONAS EN TIC ..................................................................................................6
1.8. VENTAS ANUALES / TAMAÑO DE EMPRESA PRODUCTOS ..........................................................6
2. PROCESOS ESCOGIDOS .......................................................................................................................6
2.1. EVALUACIÓN DEL PROCESO USANDO COBIT 4.1 ........................................................................6
2.1.3. BREVE DESCRIPCIÓN DEL PROCESO ........................................................................6
2.1.4. EVALUAR CADA UNO DE LOS OBJETIVOS DE CONTROL DE PROCESO,
SIGUIENDO LA METODOLOGÍA DE PRUEBAS .........................................................................7
2.4. EVALUACIÓN DEL PROCESO USANDO COBIT 4 ........................................................................ 13
2.4.3. BREVE DESCRIPCIÓN DEL PROCESO ..................................................................... 14
2.4.4. EVALUAR CADA UNO DE LOS OBJETIVOS DE CONTROL DE PROCESO,
SIGUIENDO LA METODOLOGÍA DE PRUEBAS ...................................................................... 14
3. CONCLUSIONES Y RECOMENDACIONES PARA LA GERENCIA .......................................................... 25
3.1. CONCLUSIONES, PRINCIPALES RIESGOS ENCONTRADOS Y ESTADO DE LOS CONTROLES
EXISTENTES .......................................................................................................................................... 25
3.1.1. CONCLUSIONES: ................................................................................................................... 25
3.1.2. PRINCIPALES RIESGOS ENCONTRADOS ................................................................................ 25
3.1.3. RECOMENDACIONES:........................................................................................................... 26
3.2. PRINCIPALES ACCIONES PROPUESTAS ..................................................................................... 26
3.3. ESTIMACIONES DE RECURSOS NECESARIOS INCLUYENDO COSTOS, TIEMPOS Y
RESPONSABLES .................................................................................................................................... 26
3.4. COSTOS DEL PROYECTO ........................................................................................................... 26
2
1. RESUMEN EJECUTIVO
El presente trabajo, describe la Auditoría Informática realizada a dos procesos Tecnológicos, realizado al Ministerio
de Trabajo. Utilizando COBIT, una herramienta desarrollada para, ayudar a los administradores de negocios a
entender y administrar los riesgos asociados con la implementación de nuevas tecnologías. El fin de este estudio
técnico es identificar debilidades y emitir recomendaciones que permitan minimizar riesgos.
Compañía: Ministerio de Trabajo
Negocio de la compañía:
“Alcanzar el buen vivir, impulsando el empleo digno e inclusivo que garantice la estabilidad y armonía en las
relaciones laborales”.
Objetivo del trabajo:
 Evaluar el nivel de madurez de la Dirección de TICS, del Ministerio de Trabajo determinada, para los
procesos “Administración de Cambios” y “Administrar la Mesa de Servicio y los incidentes”.
 Entender los pasos de los proceso de auditoría del área informática que permite a los administradores de
informática saber lo que deben esperar de una auditoria.
Procesos asignados:
 AI6: Administración de Cambios
 DSS02: Administrar la mesa de servicio y los incidentes
Resultados:
En cuanto al proceso AI6 se concluye que se encuentra en nivel de madurez 2. La Empresa no posee un
proceso de administración de cambio consistente para todos los cambios, existen excepciones mínimas. No todos
los cambios están sujetos a una planeación minuciosa y a la evaluación del impacto para minimizar la probabilidad
de tener problemas de post-producción. La planeación e implantación de la administración de cambios en TI no se
integran con los cambios en los procesos de negocio.
En cuanto al proceso DSS02 se concluye que se encuentra en nivel 4 y parcialmente cumple con los
parámetros del nivel 5. En todos los niveles de la Institución existe un total entendimiento de los beneficios del
proceso de administración de incidentes y la función de la mesa de servicio se ha establecido en todas las
unidades organizacionales de forma apropiada. Existe un software de Help Desk llamado Service Desk Plus como
herramienta que permite automatizar el proceso con una base de datos de conocimientos centralizada. Todo el
proceso desde que inicia una incidencia hasta su cierre está debidamente documentado. Se evidencia registro de
soluciones, informes, análisis de las incidencias por categorías, reportes estadísticos y cierres de incidentes. El único
parámetro que no permite que este proceso no se ubique totalmente en el nivel es que no hay herramientas de
software a disposición del usuario, para llevar a cabo autodiagnósticos y poder resolver incidentes.
Resumen de la evaluación:
Una vez analizados los dos procesos de auditoria elegidos, se encontró riesgos que no cumplen con el debido
proceso por lo cual las acciones propuestas son las siguientes:
 Se propone realizar estándares para la administración de cambios dentro del MDT.
 Generar un control de cambios definiendo la categorización y priorización de los cambios.
 Generar un control de cambios mediante CAB’s Emergentes.
 Generar un control del flujo de los incidentes Generados.
 Control continuo sobre los SLA’s definidos.
 Generar un estándar de respuestas en la resolución de incidentes para el usuario final.
Recomendaciones a la Gerencia:
 Como parte del proceso de control interno de toda entidad se debe realizar planificaciones y programas de
auditoría que permitan evaluar los procedimientos de TI, con la finalidad de establecer estrategias y mejoras
en la calidad.
 Debe realizarse una revisión periódica del Proceso de Control de Cambios.
Costos y Tiempos:
RECURSO COSTO OBSERVACIÓN
Software 0,00 Software libre
Recursos Humanos 9.000,00
Materiales e Insumos 400,00
TOTAL 9.400 ,00 USD
Tiempo Estimado:
El proceso se llevará a cabo en un tiempo de 4 meses.
3
1.1. ANTECEDENTES
En el año 2009 Mediante Decreto Ejecutivo Nro. 10, el Presidente de la República fusiona la ex Secretaría
Nacional Técnica de Desarrollo de Recursos Humanos y Remuneraciones del Sector Público (SENRES) y el ex
Ministerio de Trabajo y Empleo (MTE), Creando el nuevo Ministerio de Relaciones Laborales (MRL).
El Presidente de la República firma el Decreto No. 60, el Plan Plurinacional para Eliminar la Discriminación
Racial. El MRL se compromete a adoptar una política laboral con acciones afirmativas para sectores sociales
históricamente discriminados, con el fin de generar oportunidades de trabajo sin discriminación racial.
El Ministerio de Relaciones Laborales coopera con la Vicepresidencia de la República para determinar el

cumplimiento por parte de las empresas de la contratación de personal con discapacidad de acuerdo a lo dispuesto
en el Código del Trabajo.
En el AÑO 2010 el Ministerio de Relaciones Laborales inaugura la primera Agencia Socio Empleo y fija las
escalas remunerativas del año 2010 para los servidores públicos de carrera regulados por la LOSCCA.
Se inicia campaña masiva de concientización y prevención de los derechos y obligaciones de las trabajadoras del
servicio doméstico al igual que la campaña de Erradicación del Trabajo Infantil "Ecuador sin Trabajo Infantil,".
Se firma convenio con el SRI y Superintendencia de Compañías a fin de garantizar el cumplimiento del pago de
utilidades a los trabajadores.
En el mes de Mayo el Ministerio de Relaciones Laborales emite la Norma Técnica de Selección de Personal para
ingreso al Sector Público con un estricto concurso de méritos y oposición para el ingreso al sector público a las
personas con discapacidad para que puedan llenar las vacantes en las respectivas instituciones.
1.2. INTRODUCCIÓN
En el mundo actual, la tecnología de la información juega un papel de alta relevancia para las empresas y
organizaciones públicas y privadas en el desarrollo de sus procesos, por lo que puede decirse que la tecnología
es imprescindible, al hacer uso de ella es posible realizar o ejecutar diversos procesos de alta complejidad de
forma automática, llevando controles, registros y reduciendo notablemente los tiempos de trabajo.
En el contexto, es necesario revisar, monitorear y controlar el uso aplicado a las tecnologías de la información,
de tal forma que pueda aprovecharse al máximo los beneficios que otorga. Para cumplir con esta tarea, se debe
realizar auditorías de forma periódica, las cuales en el área informática es una actividad que permite recoger,
agrupar y evaluar evidencias para determinar si los sistemas de información y la tecnología utilizada, mantienen
la integridad de los datos y promueven el cumplimiento eficaz de los fines de la organización.
Para este caso de estudio se propone la aplicación de una auditoria usando Cobit 4.1 y Cobit 5 a la Dirección de
Tecnologías de la Información del Ministerio de Trabajo del Ecuador, enfocado a dos procesos:
Primer Proceso:
El proceso de Administración de cambios, el cual gestiona de manera ordenada y programada los cambios de
manuales, instructivos, etc., relacionados a la implementación de software del Ministerio de Trabajo.
Segundo Proceso:
4
El proceso de Gestión de Incidentes o Sistema de Mesa de Ayuda, es un sistema que permitirá contar con un
punto único de contacto para gestionar de manera eficiente, el suministro de los servicios de tecnología de
información y comunicaciones, tiene como objetivo “Resolver requerimientos e incidentes de forma efectiva y
eficaz, para reducir los riesgos de producirse un problema mayor”, sin embargo al pasar el tiempo se han
detectado la existencia de falencias y debilidades en la entrega de estos servicios de manera oportuna, los
acuerdos de servicio no se cumplen a satisfacción. El propósito de este trabajo es realizar una auditoría de
tecnología y evaluar la Mesa de Ayuda y los incidentes basada en el estándar internacional COBIT 5 para
identificar posibles debilidades y amenazas que deterioren o impidan brindar un servicio eficiente y oportuno
en el mencionado proceso.
1.3. PRINCIPALES PRODUCTOS Y/O SERVICIOS.
“Alcanzar el buen vivir, impulsando el empleo digno e inclusivo que garantice la estabilidad y armonía en las
relaciones laborales”.
1.4. PRINCIPALES MERCADOS Y CLIENTES
Ciudadanía, Empleadores, Extranjeros, Grupos Prioritarios, Instituciones Públicas, Organizaciones Artesanales

y Servidores Públicos
1.5. MISIÓN Y VISIÓN
a) Misión
La misión declara la razón de ser del nuevo Ministerio del Trabajo, enfocado en ser una institución que busca la
justicia social en el sistema de trabajo, de una manera digna y en igualdad de oportunidades.
b) Visión
La Visión ha sido definida en función a los lineamientos generales de las autoridades; en este contexto se plantea
un propósito estratégico que prioriza su enfoque en garantizar los derechos de la ciudadanía laboral promoviendo
un trabajo digno en todas sus manifestaciones.
1.6. ESTRUCTURA Y ORGANIZACIÓN DE LA EMPRESA
1.6.1. ORGANIGRAMA ESTRUCTURAL DE LA EMPRESA
5
1.6.2. ESTRUCTURA Y ORGANIZACIÓN DE TIC
1.7. NÚMERO DE PERSONAS EN TIC
ÁREA NÚMERO
Director TICS 1
Infraestructura 6
Base de Datos 3
Desarrollo 10
Soporte 7
TOTAL 27
1.8. VENTAS ANUALES / TAMAÑO DE EMPRESA PRODUCTOS
No se posee ventas anuales ya que es una empresa sin fines de lucro.
2. PROCESOS ESCOGIDOS
2.1. EVALUACIÓN DEL PROCESO USANDO COBIT 4.1
2.1.1. NOMBRE DEL PROCESO
AI6 Administración de cambios.
2.1.2. NOMBRE DEL DOMINIO AL QUE PERTENECE EL PROCESO
Adquirir e Implementar.
2.1.3. BREVE DESCRIPCIÓN DEL PROCESO
Establecer directrices para la implementación de soluciones tecnológicas que impliquen el desarrollo de software
incluyendo el mantenimiento de emergencia y parches relacionados con la infraestructura y las aplicaciones
dentro del ambiente de producción, mediante la definición de una metodología de trabajo que permita identificar
las diferentes actividades de cada una de las áreas involucradas, en donde se deberá registrar, evaluar y autorizar
6
previo a la implantación, que garantice una reducción de riesgos en la estabilidad o integridad del ambiente en
producción.
2.1.4. EVALUAR CADA UNO DE LOS OBJETIVOS DE CONTROL DE PROCESO, SIGUIENDO

LA METODOLOGÍA DE PRUEBAS
2.1.4.1. NOMBRE DEL OBJETIVO DE CONTROL
AI6.1 Estándares y Procedimientos para Cambios
2.1.4.2. BREVE DESCRIPCIÓN DEL OBJETIVO DE CONTROL
Establecer procedimientos de administración de cambio formales para manejar de manera estándar todas las
solicitudes (incluyendo mantenimiento y parches) para cambios a aplicaciones, procedimientos, procesos,
parámetros de sistema y servicio, y las plataformas fundamentales.
2.1.4.3. METODOLOGÍA DE REVISIÓN EVIDENCIAS ENCONTRADAS Y EVALUADAS.
N° Control Si No Comentario jefatura de TI Evaluación de la evidencia

El departamento de TI ha
elaborado un Proceso para la
Administración de
Cambios, formalizado y
Se tiene un proceso por
aprobado por el Ministro
C1 X aprobado por el Ministro
del MDT, este es
Carlos Marx Carrasco
Revisar el procedimiento existente actualizado anualmente por
para el control de cambios para lo que se observa un
verificar que el proceso cubra todas las seguimiento por parte del
áreas y personal involucrado. Departamento de TICS
Se tiene la información de
Al poseer un plan de
todos los cambios a
Administración de Cambios
Determinar si la información que se realizarse y las áreas
C2 X se mantiene una bitácora de
está solicitando en el informe de encargadas de realizar las
las versiones de los
control de cambios es la necesaria y pruebas y su respectiva
aplicativos
completa. aprobación
Revisar los estándares propuestos y

C3 verificar si son los adecuados a la X No posee estándares No se posee evidencias
actualidad. definidos.
2.1.4.4. RESULTADO DE LA EVALUACIÓN DEL OBJETIVO DE CONTROL.
El Ministerio de trabajo tiene definido un Procedimiento para la Administración de Cambios de una manera
generalizada cumpliendo con los objetivos de continuidad de las operaciones de los aplicativos de TI.
2.1.5. NOMBRE DEL OBJETIVO DE CONTROL
AI6.2 Evaluación de Impacto, Priorización y Autorización

7
Garantizar que todas las solicitudes de cambio se evalúan de una estructurada manera en cuanto a impactos en
el sistema operacional y su funcionalidad. Esta evaluación deberá incluir categorización y priorización de los
cambios. Previo a la migración hacia producción, los interesados correspondientes autorizan los cambios.

Existe un documento
Se posee documentación de
Revisar si las solicitudes de cambio elaborado por el área de
aprobación de los cambios
C1 realizadas tienen control previo para X Desarrollo donde muestra
realizados y los subprocesos
evaluar el impacto que provocará el los cambios y el impacto
que se verán afectados
cambio. que estos tendrán.
Requerimientos solicitados
Requerimiento registrado
C2 Determinar si existe categorización y X Emergentes se atienden
por sistema de Incidencias.
priorización de cambios. primero
Se posee un documento de
Revisar si están definidas las probación de cada uno de los Documento de autorización
C3 responsabilidades necesarias para las X participantes que de Cambios aprobada por el
autorizaciones correspondientes para intervienen en el proceso de área o la persona requirente
los cambios. cambio
El roll back consiste en

regresar al estado anterior a
la implementación del
C4 X cambio en producción. Se
Validar que los procesos de cambio Se posee un documento de debe ejecutar esta acción en
tengan planes de contingencia. registro de versiones base a lo definido en el plan
de despliegue.
El departamento de TI del Ministerio de Trabajo, respecto a este control ha identificado que hace falta un proceso
que permita priorizar y categorizar los cambios de tal manera que se siga un cronograma y se cumpla con los cambios
que se encuentran registrados de acuerdo a la categoría e importancia que cada uno de los sistemas posee.
AI6.3 Cambios de Emergencia
Establecer un proceso para definir, plantear, evaluar y autorizar los cambios de emergencia que no sigan el
proceso de cambio establecido. La documentación y pruebas se realizan, posiblemente, después de la
implantación del cambio de emergencia.
8

Se registran los cambios de
No se posee evidencia, se
acuerdo a la emergencia e
C1 X registra el cambio como
Revisar si existe un proceso cambios impacto que generen hacia
incidencia
de emergencia reestablecido. las instituciones externas
Cambios emergentes son

solicitados vía correo
Correo Electrónico de
C2 Determinar si el proceso de cambio de X electrónico por el
solicitud de cambio
emergencia tiene los responsables responsable del área
correspondientes. requirente
El roll back consiste en

regresar al estado anterior a
la implementación del
C3 X cambio en producción. Se
Determinar si los planes de cambios de
emergencia tienen planes de Se posee un documento de debe ejecutar esta acción en
contingencia. registro de versiones base a lo definido en el plan
de despliegue.
El Ministerio de Trabajo, junto con el área de TICs, en este control, no posee un lineamiento claro cuando los
requerimientos son de manera emergente, lo cual provoca indisponibilidad de los servicios sin previa
comunicación, lo cual causa molestia en los usuarios finales.
AI6.4 Seguimiento y Reporte del Estatus de Cambio

Establecer un sistema de seguimiento y reporte para mantener actualizados a los solicitantes de cambio y a los
interesados relevantes, acerca del estatus del cambio a las aplicaciones, a los procedimientos, a los procesos,
parámetros del sistema y del servicio y las plataformas fundamentales
Comentario Jefatura de Evaluación de la

N° Control Si No TI evidencia
No se posee
C1 Revisar si existe un procedimiento X Reuniones
evidencia
de seguimiento es el adecuado.
Determinar si los reportes de Reuniones entre área

C2 estatus de cambio existen y son los X requirente y Área No existe evidencias
adecuados. tecnológica
9
Respecto a este control de establecer un sistema de seguimiento y reporte para mantener actualizados a los
solicitantes de cambio, no se posee un registro de esta información, lo que esto puede provocar que los solicitantes
no se encuentren comunicados el momento exacto en el cual se realizó un cambio.
AI6.5 Cierre y Documentación del Cambio
Siempre que se implantan cambios al sistema, actualizar el sistema asociado y la documentación de usuario y
procedimientos correspondientes. Establecer un proceso de revisión para garantizar la implantación completa de
los cambios.

Revisar que la información Acta de Aprobación de
C1 determinada para realizar cambios sea X Cambios y PTR por parte Actas y PRD
completa y la exigida. del área de Desarrollo
Se describen de manera
detallada cada uno de los
C2 Verificar que los procedimientos para X cambios a realizarse y el PRD
realizar los cambios sean claros y procedimiento que se
detallados. llevará a cabo
Verificar que la documentación tengan

C3 las firmas de autorización y X PRD
responsabilidad necesarias.
Obtener una bitácora detallada de

C4 X SVN y Redmine
cambios. Sistema de Versiones
El departamento de TI, respecto a este control ha establecido un documento en el cual se posee la información
necesaria y requerida para poder realizar un cambio planificado de los sistemas del MDT, de igual manera posee un
sistema en el cual se mantiene un registro de todas las versiones detallando cada uno de los procedimientos de
cambio en el cual se carga el documento PRD para su respaldo.
2.2. INDICADORES CLAVES DE RENDIMIENTO DEL PROCESO AI6
Se ha identificado los siguientes indicadores para el procesoAI6:
Nº METRICA VALOR COMENTARIO
10
Porcentaje de interrupciones o errores de
datos provocados por especificaciones
1 90% No existe un registro de este indicador
inexactas o evaluación incompleta de
impacto.
% de cambios totales que son soluciones No existe un SLA entre TI y los usuarios
2 40%
de emergencia internos
3 % de cambios no exitosos a la 10% Bitácora de versiones de los aplicativos

infraestructura debido a especificaciones
de cambio inadecuadas
Número de cambios que no se rastrean
4 formalmente o no se reportan o no se 5% No se han realizado pruebas del Plan
autorizan
5 0% No se posee registro de cambios pendientes

Solicitudes de cambios pendientes
% de cambios registrados y rastreados con Se tiene un registro por medio de SVN y
6 100%
herramientas automatizadas Redmine
Número de versiones diferentes de cada Se registra en SVN, Redmine y archivo de

7 aplicación de negocios o infraestructura en 100%
bitácora de cambio de versiones
mantenimiento
Número y tipo de cambios de emergencia No se posee registro de estos cambios
8 0%
a los componentes de la infraestructura Emergentes
2.3. DETERMINACIÓN DEL NIVEL DE MADUREZ DEL PROCESO DE COBIT 4
MODELO DE MEJORES PRACTICAS – COBIT 4

INSTITUCIÓN: MINISTERIO DEL TRABAJO Fecha de Diagnóstico :
PROCESOS DE TI DEL MINISTERIO DE TRABAJO Pág. 1/1
MODELO DE MADUREZ
DOMINIO: ADQUISICIÓN E IMPLEMENTACIÓN AI6.- Administrar Cambios
OBJETIVO DE CONTROL
El control sobre el proceso de TI Administrar Cambios de TI con el objetivo del negocio de establecer
directrices para la implementación de soluciones tecnológicas que impliquen el desarrollo de software
incluyendo el mantenimiento de emergencia y parches relacionados con la infraestructura y las aplicaciones
dentro del ambiente de producción, mediante la definición de una metodología de trabajo que permita
identificar las diferentes actividades de cada una de las áreas involucradas, en donde se deberá registrar,
evaluar y autorizar previo a la implantación, que garantice una reducción de riesgos en la estabilidad o
integridad del ambiente en producción.
Estado Actual : 2 Estado Proyectado: 3
PARCIALMENTE
NO CUMPLE
CUMPLE
CRITERIOS DE CALIFICACIÓN OBSERVACIONES
Inexistente. No hay un proceso definido de administración X

0 de cambios y se pueden hacer cambios prácticamente sin
control alguno. No hay conciencia de que los cambios
11
pueden causar interrupciones tanto para TI como para las
operaciones de negocios, y ninguna conciencia de los
beneficios de una buena administración de cambios.
Inicial /Ad hoc Se reconoce que los cambios deben ser
administrados y controlados, pero no hay un proceso
consistente para seguimiento. Las prácticas varían y es
probable que ocurran cambios no autorizados. Hay
1 documentación insuficiente o inexistente de cambios, y la X
documentación de configuración está incompleta y no es
confiable. Es probable que ocurran errores junto con
interrupciones en el entorno de producción causada por una
administración deficiente del cambio.
Repetible pero Intuitiva Hay un proceso informal de No posee estándares
administración de cambios y la mayoría de los cambios definidos.
siguen este método; sin embargo, el mismo no está No existe categorización
estructurado, es rudimentario y está propenso a error. La y priorización de
precisión de la documentación de configuración es cambios.
inconsistente y sólo tiene lugar una planeación y un estudio No existe un proceso
de impacto limitados antes de un cambio. Hay considerable cambios de emergencia
ineficiencia y repetición de trabajo. establecida.
El proceso de cambio de
emergencia no tiene los
responsables
correspondientes.
Existe un procedimiento
de seguimiento de los
2 X
procesos de forma
deficiente.
Existen pocos reportes de
estatus de cambio
existentes y no son los
adecuados.
No existen planes de
contingencia para poder
realizar los cambios. Hay
ciertos cambios que se
evidencia documentación
de autorizaciones,
prioridad, emergencia,
etc.
Proceso Definido Está establecido un proceso formal de El Departamento de TI ha
administración de cambios, que incluye procedimientos de elaborado un Proceso
categorización, priorización, emergencia, autorización y para la Administración de
administración de cambios, pero no se impone su Cambios, formalizado y
cumplimiento. El proceso definido no siempre es visto como aprobado por el Ministro
adecuado o práctico y, en consecuencia, ocurren trabajos del MDT, este es
paralelos y los procesos son desviados. Es probable que actualizado anualmente
ocurran errores y los cambios no autorizados ocurrirán por lo que se observa un
3 X
ocasionalmente. El análisis de impacto a los cambios de TI seguimiento por parte del
sobre las operaciones del negocio se está volviendo formales Departamento de TICS.
para soportar la ejecución de los planes para nuevas Al poseer un plan de
aplicaciones y tecnologías. Administración de
Cambios se mantiene una
bitácora de las versiones
de los aplicativos.
Existe un documento
12
elaborado por el área de
Desarrollo donde muestra
los cambios y el impacto
que estos tendrán.
Existe documentos de
autorización de ciertos
cambios aprobados por el
área o la persona
requirente
Administrado y Medible El proceso de administración de
cambios está bien desarrollado y es seguido de manera
consistente para todos los cambios, y la administración
confía en que no hay excepciones. El proceso es eficiente y
efectivo, pero se basa en considerables procedimientos y
controles manuales para asegurar que se logre la calidad.
Todos los cambios están sujetos a una planeación y estudio
de impacto exhaustivos para minimizar la probabilidad de
problemas posteriores a la producción. Está establecido un
proceso de aprobación para los cambios. La documentación
4 X
de administración de cambios está al día y es correcta, y los
cambios son rastreados formalmente. La documentación de
la configuración está generalmente actualizada. La
planeación e implementación de la administración de
cambios de TI se está volviendo más integrada con cambios
en los procesos de negocios, para asegurar ese
entrenamiento, se resuelven cambios organizativos y
problemas de continuidad de negocio. Hay mayor
coordinación entre la administración de cambios de TI y el
rediseño del proceso de negocios.
Optimizado El proceso de administración de cambios se
revisa con regularidad y se actualiza para permanecer en
línea con las buenas prácticas. El proceso de revisión refleja
los resultados del monitoreo. La información de la
configuración es computarizada y proporciona un control de
versión. El rastreo del cambio es sofisticado e incluye
5 X
herramientas para detectar software no autorizado y sin
licencia. La administración de cambio de TI se integra con
la administración de cambio del negocio para garantizar que
TI sea un factor que hace posible el incremento de
productividad y la creación de nuevas oportunidades de
negocio para la organización.
2.4. EVALUACIÓN DEL PROCESO USANDO COBIT 4
GRADO DE MADUREZ.- El proceso de AI6: Administrar Cambios, se encuentra en el nivel 2 y parcialmente

cumple con ciertos parámetros del nivel 3. La Empresa no posee un proceso de administración de cambio
consistente para todos los cambios, existen excepciones mínimas. No todos los cambios están sujetos a una
planeación minuciosa y a la evaluación del impacto para minimizar la probabilidad de tener problemas de post-
producción. La planeación e implantación de la administración de cambios en TI no se integran con los cambios
en los procesos de negocio, para asegurar que se resuelven los asuntos referentes al entrenamiento, cambio
organizacional y continuidad del negocio. Se evidencia documentación de ciertos cambios realizados con sus
respectivas autorizaciones, pero de otros son inexistentes. Mantienen una bitácora donde se evidencia las
versiones de cambios realizados. También se evidencia cierta documentación donde se evalúa el impacto que
provocará un cambio.
13
2.4.1. NOMBRE DEL PROCESO
DSS02 Gestionar las Peticiones y los Incidentes del Servicio
2.4.2. NOMBRE DEL DOMINIO AL QUE PERTENECE EL PROCESO
Entrega, Servicio y Soporte
2.4.3. BREVE DESCRIPCIÓN DEL PROCESO
Proveer una respuesta oportuna y efectiva a las peticiones de usuario y la resolución de todo tipo de incidentes.
Recuperar el servicio normal; registrar y completar las peticiones de usuario; y registrar, investigar, diagnosticar,
escalar y resolver incidentes.
2.4.4. EVALUAR CADA UNO DE LOS OBJETIVOS DE CONTROL DE PROCESO, SIGUIENDO

LA METODOLOGÍA DE PRUEBAS
DSS02.01 Definir esquemas de clasificación de incidentes y peticiones de servicio.
3.2.4.1.1 BREVE DESCRIPCIÓN DEL OBJETIVO DE CONTROL
Definir esquemas y modelos de clasificación de incidentes y peticiones de servicio.
3.2.4.1.2 METODOLOGÍA DE REVISIÓN EVIDENCIAS ENCONTRADAS Y EVALUADAS.
PROCESO: DSS02 Gestionar las Peticiones y los Incidentes del Servicio

PRACTICA ACTIVIDADES CUMPLE OBSERVACIONES EVALUACIÓN DE LA
DE SI NO EVIDENCIA
GESTION
DSS02.01 Definir esquemas de X Se definen los Existe el documento INS-
Definir clasificación y esquemas de GTI-02-02 Instructivo Mesa
esquemas de priorización de clasificación y de Ayuda 25052015, este
clasificación incidentes y peticiones priorización de documento tiene como
de incidentes de servicio y criterios incidentes e finalidad difundir a los
y peticiones para el registro de incidencias, manejando usuarios en general el
de servicio problemas, para el criterio de problemas tratamiento de la
asegurar enfoques mediante el software clasificación y priorización
consistentes en el service desk plus de incidentes y peticiones
tratamiento,
informando a los
usuarios y realizando
análisis de tendencias.
Definir modelos de X Se encuentran Dentro del documento o
incidentes para errores definidos modelos de INS-GTI-02-02 Instructivo
conocidos con el fin de incidencias los cuales Mesa de Ayuda, se
facilitar su resolución facilitan la resolución a encuentran definidos los
eficiente y efectiva primer nivel modelos de incidentes y
donde se almacenan.
Definir modelos de X Se definen los Se evidencia dentro del
peticiones de servicio modelos de peticiones documento INS-GTI-02-02
según el tipo de Instructivo Mesa de Ayuda
petición de servicio 25052015, se encuentran
14
correspondiente para definidos los tipos de
facilitar la auto-ayuda y servicios según el tipo de
el servicio eficiente petición solicitada.
para las peticiones
estándar.
Definir reglas y X Tiempos acordados de Se evidencia dentro del

procedimientos de escalamiento documento INS-GTI-02-02
escalado de incidentes, Instructivo Mesa de Ayuda
especialmente para 25052015, las reglas de
incidentes importantes procedimientos y el
e incidentes de escalamiento de incidentes
seguridad. respectivo
Definir fuentes de X Se tiene el Know how Además ServiceDesk tiene
conocimiento de del personal y se tiene base de conocimiento
incidentes y peticiones una base del flexible, con la opción de
y su uso. conocimiento añadir artículos ilimitados
compartida permite a los usuarios buscar
fácilmente la información. La
Herramienta incluye
características
completamente cargadas
como Base de Conocimiento
adaptable para usuarios y
técnicos finales, proceso de
aprobación de la sumisión del
artículo
3.2.4.1.3 RESULTADO DE LA EVALUACIÓN DEL OBJETIVO DE CONTROL.
Se debe emitir reportes de la actividad de la mesa de ayuda para permitir a la gerencia medir el desempeño de
los incidentes y peticiones de los usuarios. Se debe tener los procedimientos claros a seguir al presentarse un
incidente critico que afecte a la continuidad de los servicios, con estos reportes se debe evaluar continuamente
los tiempos de escalamiento en cada uno de los incidentes.
Al tener una base del conocimiento ayuda al personal a poseer el know how del servicio, con lo cual no se
depende del personal en caso de salida de la institución
DSS02.02 Registrar, clasificar y priorizar peticiones e incidentes
2.4.4.2.1. BREVE DESCRIPCIÓN DEL OBJETIVO DE CONTROL
Identificar, registrar y clasificar peticiones de servicio e incidentes, y asignar una prioridad según la criticidad
del negocio y los acuerdos de servicio.
2.4.4.2.2. METODOLOGÍA DE REVISIÓN EVIDENCIAS ENCONTRADAS Y EVALUADAS.

ACTIVIDADES CUMPLE
15
PRACTICA SI NO OBSERVACIO EVALUACIÓN DE LA
DE NES EVIDENCIA
GESTION
DSS02.02 Registrar todos los X Se tiene un Dentro del documento de Modelo
Registrar, incidentes y registro delos soporte TIC`S ITIL, se muestra la
clasificar y peticiones de incidentes y tks. estructura del service desk plus en
priorizar servicio, el cual se contempla el registro y
peticiones e registrando toda la clasificación y su posterior
incidentes información almacenamiento en una base de
relevante de forma datos.
que pueda ser
manejada de
manera efectiva y
se mantenga un
registro histórico
completo.
Para posibilitar X Se observa la Se verifica que existe un

análisis de identificación de documento en el cual se obtiene la
tendencias, tipo y categoría data de los TKs resueltos por tipo
clasificar y categoría, el documento no fue
incidentes y proporcionado por seguridad de la
peticiones de información
servicio
identificando tipo y
categoría.
Priorizar peticiones X Se mantiene un En el documento INS-GTI-02-02
de servicio e acuerdo de SLAs Instructivo Mesa de Ayuda
incidentes según la con los 25052015, se encuentran
definición de proveedores y establecidos los SLAs de acuerdo
impacto en el dentro de la mesa a las distintas severidades de los
negocio del ANS y de ayuda incidentes.
la urgencia.
2.4.4.2.3. RESULTADO DE LA EVALUACIÓN DEL OBJETIVO DE CONTROL.
Se puede evidenciar que la mesa de ayuda posee la clasificación y priorización de peticiones e incidentes
teniendo tiempos respuesta con el cual se tiene un tiempo estimado en la resolución o escalamiento del mismo,
además posee SLAs definidos internamente y con sus proveedores de servicio, con esto se puede dar una
clasificación y priorización a los incidentes generados en el service desk plus.
El tener una correcta priorización permitirá tener una gestión eficaz de recursos de TI y una gestión de costos
adecuada para su continuidad con lo cual la alta gerencia podrá tomar decisiones acertadas en la resolución de
incidentes
DSS02.03 Verificar, aprobar y resolver peticiones de servicio.
Seleccionar los procedimientos adecuados para peticiones y verificar que las peticiones de servicio cumplen
los criterios de petición definidos.
16

PRACTICA ACTIVIDADES CUMPLE OBSERVACION EVALUACIÓN DE LA
DE SI NO ES EVIDENCIA
GESTION
DSS02.03 Verificar los derechos X Se tiene un flujo En el documento Flujograma
Verificar, para realizar peticiones definido para el Procedimiento Mesa de
aprobar y de servicio usando, proceso de Ayuda21052015, se
resolver cuando sea posible, un cambios encuentra definido el proceso
peticiones de flujo de proceso de flujo de las peticiones de
servicio. predefinido y cambios servicio
estándar.
Obtener aprobación X Se necesita tener Documento de autorización
financiera y funcional o una aprobación de Cambios aprobada por el
firmada, si se requiere, o firmada para área o la persona requirente,
aprobaciones cambios estándar el documento no fue
predefinidas para entregado por debido a
cambios estándar seguridad de la información
acordados.
Completar las peticiones X Si se posee En el documento INS-GTI-
siguiendo el 02-02 Instructivo Mesa de
procedimiento de Ayuda 25052015, se
petición seleccionado, evidencia los procedimientos
utilizando, cuando sea de selección con menús
posible, menús automáticos mediante el
automáticos de service desk plus.
autoayuda y modelos de
petición predefinidos
para los elementos
solicitados
frecuentemente.
Se evidencia la verificación, aprobación y resolución de las peticiones de servicio por lo cual es posible
determinar una causa raíz para solventar las peticiones de servicio, una adecuada verificación permite una
recuperación y solución efectiva de los incidentes o peticiones solicitadas con lo cual la alta gerencia tiene un
tiempo de respuesta real y optimo sobre cada incidente generado.
DSS02.04 Investigar, diagnosticar y localizar incidentes.
Identificar y registrar síntomas de incidentes, determinar posibles causas y asignar recursos a su resolución.
2.4.4.4.2.
METODOLOGÍA DE REVISIÓN EVIDENCIAS ENCONTRADAS Y EVALUADAS.
DE SI NO EVIDENCIA
GESTION
17
DSS02.04 Identificar y X Si se posee una En el documento INFORME
Investigar, describir síntomas estadística de recurso, TÉCNICO_11mayo2015_v2
diagnosticar relevantes para problemas conocidos Errores, se tiene evidencia de
y localizar establecer las estadísticas, causas, impactos y
incidentes. causas más soluciones para establecer un
probables de los plan de soporte frente a
incidentes. Hacer eventualidades de los incidentes
referencia a los generados en la mesa de ayuda.
recursos de
conocimiento
disponibles
(incluyendo
errores y
problemas
conocidos) para
identificar
posibles
resoluciones de
incidentes
(soluciones
temporales y/o
soluciones
permanentes).
Registrar un X Se mantiene un Se mantiene un registro de
nuevo problema si registro de problemas problemas relacionados para
un problema tener una base del conocimiento
relacionado o y generar nuevos planes de
error conocido no mejora. El documento no fue
existe aún y si el proporcionado por seguridad de
incidente satisface la información.
los criterios
acordados para
registro de
problemas.
Asignar incidentes X Se mantiene el nivel En el documento INS-GTI-02-
a funciones de escalamiento 02 Instructivo Mesa de Ayuda
especializadas si 25052015, se encuentran
se necesita de un estipulados los tipos y tiempos
conocimiento más de escalamiento cuando se
profundo, e requiere una solución
implicar al nivel especializada para un incidente
de gestión generado
apropiado, cuando
sea necesario.
El plan de soporte adicional genera una adecuada administración de los incidentes para todos los involucrados.
Se evidencian las posibles causas de los incidentes con la base del conocimiento sociabilizada al personal lo
cual permite una recuperación de los procesos de los sistemas informáticos y del negocio rápida generando un
escalamiento correcto si fuera necesario para la resolución de incidentes
DSS02.05 Resolver y recuperarse ante incidentes.

18
Documentar, solicitar y probar las soluciones identificadas o temporales y ejecutar acciones de recuperación
para restaurar el servicio TI relacionado.

PRACTICA ACTIVIDADES CUMPLE OBSERVACIO EVALUACIÓN DE LA
DE SI NO NES EVIDENCIA
GESTION
DSS02.05 Seleccionar y aplicar X Se tienen En el documento INFORME
Resolver y las resoluciones de resoluciones para TÉCNICO_11mayo2015_v2
recuperarse incidentes más aplicar Errores, se encuentran las
ante apropiadas soluciones evidencia según las estadísticas de
incidentes. (soluciones provisionales o errores generados para seleccionar
provisionales y/o permanentes y aplicar las soluciones
soluciones provisionales o permanentes
permanentes).
Registrar si se usaron X Se registran las En el documento Reporte de
soluciones soluciones incidencias se encuentran
temporales para registrados las soluciones
resolver los utilizadas. . El documento no fue
incidentes. proporcionado por seguridad de la
información.
Ejecutar acciones de X Se ejecutan En el documento de Ejecución de
recuperación, si se acciones de recuperación se encuentran
requieren. recuperación registrados los procedimientos
para realizar las acciones de
recuperación pertinentes.
El documento no fue
proporcionado por seguridad de la
información.
Documentar la X Si se documentan Los procedimientos de resolución
resolución del los se tienen documentados como
incidente y evaluar si procedimientos fuente de conocimiento
puede usarse como
una fuente de
conocimiento en el
futuro.
Se evidencia un procedimiento formal de recuperación y reanudación de servicios ante incidentes facilita la

recuperación de los servicios de forma oportuna y eficaz. El tener un plan de recuperación y reanudación permite
minimizar los tiempos de recuperación, los costos de recuperación priorizando los procesos críticos del negocio.
DSS02.06 Cerrar peticiones de servicio e incidentes.
Verificar la satisfactoria resolución de incidentes y/o satisfactorio cumplimiento de peticiones, y cierre.

19

PRACTICA ACTIVIDADES CUMPLE OBSERVACION EVALUACIÓN DE LA
DE SI NO ES EVIDENCIA
GESTION
DSS02.06 Verificar con los X Se verifica con los En el documento INS-GTI-02-
Cerrar usuarios afectados (si usuarios 02 Instructivo Mesa de Ayuda
peticiones de lo han acordado) que 25052015, se evidencia que
servicio e la petición de servicio existe el proceso de verificación
incidentes. ha sido completada o de cierre de peticiones con los
el incidente ha sido usuarios mediante el service desk
resuelto de manera plus
satisfactoria.
Cerrar peticiones de X Se realiza el cierre En el documento INS-GTI-02-02
servicio e incidentes. de los incidentes Instructivo Mesa de Ayuda
25052015, se evidencia que
existe el proceso para el cierre de
peticiones mediante el service
desk plus
Se evidencia el seguimiento y control adecuado respecto al cierre de peticiones e incidentes, con lo cual se
cumplen los SLA’s y la satisfacción del usuario final, lo que ayuda a la recuperación de los servicios de manera
oportuna lo que genera la continuidad de las operaciones de TI y del negocio.
DSS02.07 Seguir el estado y emitir de informes.
Hacer seguimiento, analizar e informar de incidentes y tendencias de cumplimiento de peticiones,

regularmente, para proporcionar información para la mejora continua.

DE SI NO EVIDENCIA
GESTION
DSS02.07 Supervisar y hacer X Se evidencia el Se evidencia el seguimiento
Seguir el seguimiento del cumplimiento de los de escalamiento de
estado y escalado de incidentes tiempos de incidentes mediante el
emitir de y de resoluciones y de escalamiento y de service desk plus
informes. los procedimientos de resolución
gestión de resoluciones
para progresar hacia la
resolución o
cumplimentación.
20
Identificar la X Se identifica la Se evidencia que el
información para las información para las aplicativo de tickets
partes interesadas y sus partes interesadas automáticamente notificará
necesidades de datos o
al correo electrónico
informes. Identificar la
frecuencia y el medio institucional del usuario
para informarles. interno la resolución del
requerimiento,
Analizar incidentes y X Se identifica los Se evidencia mediciones
peticiones de servicio análisis de incidentes mensuales y revisiones de
por categoría y tipo por categoría las mismas para la
para establecer verificación de
tendencias e identificar cumplimiento de SLA´s,
patrones de asuntos para generar la mejora
recurrentes, continua
infracciones de ANSs o
ineficiencias. Utilizar la
información como
entrada a la
planificación de la
mejora continua.
Producir y distribuir X Se identifica informes Se evidencia en el service
informes en tiempo o desk plus, menú para generar
proporcionar acceso reportes de acuerdo a la
controlado a datos necesidad y con el control de
online. acceso pertinente.
Se evidencia el control y seguimiento establecido para la generación de informes. El seguimiento adecuado del
cumplimiento garantiza la integridad de la resolución de incidentes, al analizar e informar los incidentes, se
generan informes con tendencias de cumplimiento de peticiones para proporcionar información para la mejora
continua.
2.5. INDICADORES CLAVES DE RENDIMIENTO DEL PROCESO DSS02
Se ha identificado los siguientes indicadores para el procesoDSS02:
Nº METRICA VALOR COMENTARIO
1 100% Existen los esquemas definidos

% de esquemas de clasificación y priorización
de incidentes
Existe una bitácora detallada con los incidentes
2 100%
% incidencias frecuentes. frecuentes y su solución.
3 100% Tiempos definidos para escalamiento

Número de reglas y procedimientos para
escalamiento de incidencias.
4 100% Existe un base de conocimiento compartida

% de almacenamiento de conocimiento
Existe un documento que permite la clasificación
5 100%
Tipos de incidencias de Tickets.
21
6 Tipos de priorización para atención de 100% Se encuentra establecidos en los SLAs

incidencias
Existe desk plus que permite revisar el estado de

7 Alarmas para seguimiento de estado de las 100%
las incidencias.
incidencias.
Existe el resumen de incidencias con sus propias
8 100%
% de incidencias frecuentes estadísticas para poder elaborar un plan de soporte.
Existen estadísticas al día de este indicador,
9 % de incidencias recibidas mensualmente 100% incluso pueden ser obtenidas del sistema de Help
Desk inmediatamente.
Se evidencia registro de soluciones, informes,
10 100% análisis de las incidencias por categorías, reportes
% de incidencias resueltas cerradas estadísticos y cierres de incidentes.
debidamente documentadas.
Existen las estadísticas que proporciona el sistema
11 100%
% de eficacia de resolución de incidencias. de Help Desk y documentación de soporte.
12 100%
% de eficiencia de resolución de incidencias de Help Desk y documentación de soporte.
13 Tiempo de respuesta de solución de 100%
problemas e incidentes. de Help Desk.
14 Número de escalamientos de incidentes 100%
realizados de nivel 1 a nivel 2 y 3. de Help Desk.
2.6. DETERMINACIÓN DEL NIVEL DE MADUREZ DEL PROCESO COBIT 5
MODELO DE MEJORES PRACTICAS – COBIT 4

INSTITUCIÓN: MINISTERIO DEL TRABAJO Fecha de Diagnóstico :
PROCESOS DE TI DEL MINISTERIO DE TRABAJO Pág. 1/1
MODELO DE MADUREZ
DOMINIO: ENTREGA Y SOPORTE DSS02 Gestionar las Peticiones y los
Incidentes del Servicio
OBJETIVO DE CONTROL
El control sobre el proceso de TI Gestionar las Peticiones y los Incidentes del Servicio de TI con el objetivo
del negocio de proveer una respuesta oportuna y efectiva a las peticiones de usuario y la resolución de todo tipo
de incidentes. Recuperar el servicio normal; registrar y completar las peticiones de usuario; y registrar,
investigar, diagnosticar, escalar y resolver incidentes.
Estado Actual : 4 Estado Proyectado: 5
PARCIALMENTE
NO CUMPLE
CUMPLE
CRITERIOS DE CALIFICACIÓN OBSERVACIONES
Inexistente. El proceso cumple con todos los objetivos de

control. Existe el soporte adecuado para resolver problemas
0 X
y preguntas de los usuarios. Hay una completa
planificación de procesos para la administración de
22
incidentes. La organización reconoce que hay un problema
que atender.
Inicial /Ad hoc El Ministro reconoce que se requiere un
proceso soportado por herramientas y personal para
responder a las consultas de los usuarios y administrar la
resolución de incidentes. Se trata de un proceso
1 estandarizado brinda soporte reactivo y proactivo. El X
Ministro monitorea las consultas de los usuarios, los
incidentes o las tendencias. Existe un proceso de
escalamiento para garantizar que los problemas se resuelvan.
Repetible pero Intuitivo Las incidencias reportadas por los

usuarios a la mesa de servicios son asignadas al personal de
TI. Muchas de ellas son repetitivas y existe intuición en la
resolución de problemas. Se analiza la causa raíz que genera
repetitivamente un tipo de incidente y se procura por
2 X
solucionarlo. Todas las soluciones quedan documentadas y
se realizan los cierres de las incidencias notificando por
correo electrónico institucional al usuario que reportó la
incidencia que su requerimiento fue atendido y solucionado.
Proceso Definido Hay conciencia organizacional de la

necesidad de una función de mesa de servicio y de un
proceso de administración de incidentes. Existe ayuda
disponible de manera formal a través de una red de
individuos expertos. Estos individuos tienen a su disposición
3 X
algunas herramientas comunes para ayudar en la resolución
de incidentes. Existe entrenamiento formal y la
comunicación sobre procedimientos estándar y la
responsabilidad es delegada al individuo.
Administrado y Medible En todos los niveles de la Se poseen estándares de

organización hay un total entendimiento de los beneficios de Help Desk muy bien
un proceso de administración de incidentes y la función definidos que pueden ser
de mesa de servicio se ha establecido en las unidades medidos mediante el
organizacionales apropiadas. Las herramientas y técnicas
software Service Desk
están automatizadas con una base de conocimientos
centralizada. El personal de la mesa de servicio interactúa Plus.
muy de cerca con el personal de administración de Están definidos los
problemas. Las responsabilidades son claras y se monitorea esquemas de clasificación y
su efectividad. Los procedimientos para comunicar, escalar priorización de incidentes e
y resolver incidentes han sido establecidos y comunicados. incidencias, manejando el
El personal de la mesa de servicio está capacitado y los criterio de problemas
4 procesos se mejoran a través del uso de software para tareas X
mediante el software
específicas. La gerencia ha desarrollado los KPIs y KGIs
Service Desk Plus
para el desempeño de la mesa de servicio.
Se tiene un registro de los
incidentes y tickets con
identificación de tipo y
categoría.
Se evidencia el
cumplimiento de los
tiempos de escalamiento y
de resolución.
Se evidencia registro de
23
soluciones, informes,
análisis de las incidencias
por categorías, reportes
estadísticos y cierres de
incidentes.
El personal de la mesa de
servicio nivel 1 interactúa
muy de cerca con el
personal de administración
de problemas nivel 2 y 3
Optimizado El proceso de administración de incidentes y la El proceso cumple con
función de mesa de servicio están bien organizados y todos los parámetros de
establecidos y se llevan a cabo con un enfoque de servicio al este nivel a excepción de
cliente ya que son expertos, enfocados al cliente y útiles. Los que no hay herramientas de
KPIs y KGIs son medidos y reportados sistemáticamente. software a disposición del
Una amplia y extensa cantidad de preguntas frecuentes son usuario, para llevar a cabo
parte integral de la base de conocimientos. Existen a autodiagnósticos y poder
disposición del usuario, herramientas para llevar a cabo resolver incidentes.
autodiagnósticos y para resolver incidentes. La asesoría es
5 X
consistente y los incidentes se resuelven de forma rápida
dentro de un proceso estructurado de escalamiento. La
gerencia utiliza una herramienta integrada para obtener
estadísticas de desempeño del proceso de administración de
incidentes y de la función de mesa de servicio. Los procesos
han sido afinados al nivel de las mejores prácticas de la
industria, con base en los resultados del análisis de los KPIs
y KGIs, de la mejora continua y de benchmarking con otras
organizaciones.
2.7. EVALUACIÓN DEL PROCESO USANDO COBIT 4
GRADO DE MADUREZ.- El proceso de DSS02 Gestionar las Peticiones y los Incidentes del Servicio, se encuentra
en el nivel 4 y parcialmente cumple con los parámetros del nivel 5. En todos los niveles de la Institución existe un
total entendimiento de los beneficios del proceso de administración de incidentes y la función de la mesa de
servicio se ha establecido en todas las unidades organizacionales de forma apropiada. Existe un software de
Help Desk llamado Service Desk Plus como herramienta que permite automatizar el proceso con una base de datos
de conocimientos centralizada. El personal de la mesa de servicio interactúa muy de cerca con el personal de
administración de problemas. Las responsabilidades son claras y se monitorea su efectividad. Los procedimientos
para comunicar, escalar y resolver incidentes han sido establecidos y comunicados. El personal de la mesa de servicio
está capacitado y los procesos se mejoran a través del uso de software para tareas específicas. La gerencia ha
desarrollado los KPIs y KGIs para el desempeño de la mesa de servicio. Todo el proceso desde que inicia una
incidencia hasta su cierre está debidamente documentado. Se evidencia registro de soluciones, informes, análisis de
las incidencias por categorías, reportes estadísticos y cierres de incidentes. El único parámetro que no permite que
este proceso no se ubique totalmente en el nivel es que no hay herramientas de software a disposición del usuario,
para llevar a cabo autodiagnósticos y poder resolver incidentes.
24
3. CONCLUSIONES Y RECOMENDACIONES PARA LA GERENCIA
3.1. CONCLUSIONES, PRINCIPALES RIESGOS ENCONTRADOS Y ESTADO DE LOS

CONTROLES EXISTENTES
3.1.1. CONCLUSIONES:
 Luego de la revisión se analizó el nivel de madurez en que actualmente se encuentran los procesos
escogidos en el Área de TI del MDT según los riesgos y fallas encontradas, se determina el nivel al que se
puede ascender si se cumplen con las recomendaciones planteadas.
 En el caso del proceso AI6 se concluye que se encuentra en nivel 2 de Madurez y se recomienda pasar al
nivel 3 estandarizando, comunicando y documentando todos los cambios realizados sean programados o
de tipo emergente en todas las áreas de TI del MDT.
 En el caso del proceso DDS02 se concluye que se encuentra en nivel 4 de Madurez y se recomienda
implementar un sistema de autodiagnóstico para el usuario para que puedan resolver incidentes de baja
prioridad.
 Se analizó los procesos y flujos de las distintas gestiones que soporta la entrega de servicios.
 Para la adopción de marcos de referencia y buenas prácticas, se requiere del compromiso de toda la
Organización pero sobre todo, de la decisión de las autoridades para hacer del MDT una institución pública
centrada en el cliente, con un liderazgo de la alta dirección, una administración profesional.
3.1.2. PRINCIPALES RIESGOS ENCONTRADOS
25
3.1.3. RECOMENDACIONES:
 Se recomienda que las auditorías deben ser creíbles, viables y Relevantes.

 Concienciar al equipo de trabajo acerca de la existencia de riesgos asociados al desarrollo interno de
sistemas para poder guiar el proyecto de auditoría.
 Debe realizarse una revisión periódica del Proceso de Control de Cambios.
 El MDT deberá mantener la herramienta informática de mesa de ayuda con especificaciones y
categorizaciones bien definidas que ayuden a gestionar los incidentes y permita tomar la decisión más
acertada frente al requerimiento.
3.2. PRINCIPALES ACCIONES PROPUESTAS
 Se propone realizar estándares para la administración de cambios dentro del MDT

 Generar un control de cambios definiendo la categorización y priorización de los cambios
 Generar un control de cambios mediante CAB’s Emergentes
 Generar un control del flujo de los incidentes Generados
 Control continuo sobre los SLA’s definidos
 Generar un estándar de respuestas en la resolución de incidentes para el usuario final
3.3. ESTIMACIONES DE RECURSOS NECESARIOS INCLUYENDO COSTOS, TIEMPOS Y

RESPONSABLES
CARGO PERFIL FUNCIONES

Líder Proyecto Ing. Sistemas con experiencia en Administrar el Proyecto
proyectos y manejo de personal
Consultor Consultor con Amplios Dar soporte en el área
Conocimientos de Cobit 4 -5
Involucrado en Persona con amplios Proporciona información acerca del nivel de riesgo que
el Negocio conocimientos en los procesos se considera aceptable. Proporciona información de
del Negocio históricos que sirvan de ayuda para la identificación de
riesgos del proyecto
Jefe de IT Ing. Sistemas conocimientos en Desarrolla y mantiene el plan de gestión de riesgos.
Sistemas de TICS Durante el proyecto debe llevar a cabo la monitorización
y control de los riesgos de los que es responsable y
mandar su bitácora al jefe de proyecto y de escalar
situaciones excepcionales al jefe de proyecto.
3.4. COSTOS DEL PROYECTO
RECURSO COSTO OBSERVACIÓN

Software 0,00 Software libre
Recursos Humanos 9.000,00
 1 Líder de Proyecto
 2 Ing. Sistemas
 1 Involucrado Negocio
 1 Consultor
 Capacitación al personal de TI
Materiales e Insumos 400,00
TOTAL 9.400,00 USD
26

GRUPO 3 - Administracion y Auditoria de Sistemas MDT

Cargado por

Copyright:

Formatos disponibles

GRUPO 3 - Administracion y Auditoria de Sistemas MDT

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

GRUPO 3 - Administracion y Auditoria de Sistemas MDT

Cargado por

Copyright:

Formatos disponibles

Administración y Auditoría de TI

ESCUELA POLITÉCNICA DEL EJÉRCITO

MÓDULO: ADMINISTRACIÓN Y AUDITORIA DE LAS TIC’S

TRABAJO: PROCESOS DE TI DEL MINISTERIO DE TRABAJO

DOCENTE: Ing. Giovanni Roldán Crespo

1. RESUMEN EJECUTIVO .........................................................................................................................3

El Ministerio de Relaciones Laborales coopera con la Vicepresidencia de la República para determinar el

1.3. PRINCIPALES PRODUCTOS Y/O SERVICIOS.

1.4. PRINCIPALES MERCADOS Y CLIENTES

Ciudadanía, Empleadores, Extranjeros, Grupos Prioritarios, Instituciones Públicas, Organizaciones Artesanales

1.5. MISIÓN Y VISIÓN

1.6. ESTRUCTURA Y ORGANIZACIÓN DE LA EMPRESA

1.6.1. ORGANIGRAMA ESTRUCTURAL DE LA EMPRESA

1.7. NÚMERO DE PERSONAS EN TIC

1.8. VENTAS ANUALES / TAMAÑO DE EMPRESA PRODUCTOS

No se posee ventas anuales ya que es una empresa sin fines de lucro.

2.1. EVALUACIÓN DEL PROCESO USANDO COBIT 4.1

2.1.1. NOMBRE DEL PROCESO

AI6 Administración de cambios.

2.1.2. NOMBRE DEL DOMINIO AL QUE PERTENECE EL PROCESO

2.1.3. BREVE DESCRIPCIÓN DEL PROCESO

2.1.4. EVALUAR CADA UNO DE LOS OBJETIVOS DE CONTROL DE PROCESO, SIGUIENDO

2.1.4.1. NOMBRE DEL OBJETIVO DE CONTROL

AI6.1 Estándares y Procedimientos para Cambios

2.1.4.2. BREVE DESCRIPCIÓN DEL OBJETIVO DE CONTROL

2.1.4.3. METODOLOGÍA DE REVISIÓN EVIDENCIAS ENCONTRADAS Y EVALUADAS.

N° Control Si No Comentario jefatura de TI Evaluación de la evidencia

Revisar los estándares propuestos y

2.1.4.4. RESULTADO DE LA EVALUACIÓN DEL OBJETIVO DE CONTROL.

2.1.5. NOMBRE DEL OBJETIVO DE CONTROL

AI6.2 Evaluación de Impacto, Priorización y Autorización

2.1.5.1. BREVE DESCRIPCIÓN DEL OBJETIVO DE CONTROL

2.1.5.2. METODOLOGÍA DE REVISIÓN EVIDENCIAS ENCONTRADAS Y EVALUADAS.

N° Control Si No Comentario jefatura de TI Evaluación de la evidencia

El roll back consiste en

2.1.6. NOMBRE DEL OBJETIVO DE CONTROL

AI6.3 Cambios de Emergencia

2.1.6.1. BREVE DESCRIPCIÓN DEL OBJETIVO DE CONTROL

2.1.6.2. METODOLOGÍA DE REVISIÓN EVIDENCIAS ENCONTRADAS Y EVALUADAS.

N° Control Si No Comentario jefatura de TI Evaluación de la evidencia

Cambios emergentes son

El roll back consiste en

2.1.7. NOMBRE DEL OBJETIVO DE CONTROL

AI6.4 Seguimiento y Reporte del Estatus de Cambio

2.1.7.1. BREVE DESCRIPCIÓN DEL OBJETIVO DE CONTROL

2.1.7.2. METODOLOGÍA DE REVISIÓN EVIDENCIAS ENCONTRADAS Y EVALUADAS.

Comentario Jefatura de Evaluación de la

Determinar si los reportes de Reuniones entre área

2.1.7.3. RESULTADO DE LA EVALUACIÓN DEL OBJETIVO DE CONTROL.

2.1.8. NOMBRE DEL OBJETIVO DE CONTROL

AI6.5 Cierre y Documentación del Cambio

2.1.8.1. BREVE DESCRIPCIÓN DEL OBJETIVO DE CONTROL

2.1.8.2. METODOLOGÍA DE REVISIÓN EVIDENCIAS ENCONTRADAS Y EVALUADAS.

N° Control Si No Comentario jefatura de TI Evaluación de la evidencia

Verificar que la documentación tengan

Obtener una bitácora detallada de

2.1.8.3. RESULTADO DE LA EVALUACIÓN DEL OBJETIVO DE CONTROL.

2.2. INDICADORES CLAVES DE RENDIMIENTO DEL PROCESO AI6

Se ha identificado los siguientes indicadores para el procesoAI6:

Nº METRICA VALOR COMENTARIO