gerencia informatica

1. LAS FIJAS
1. CUALES SON LOS OBJETIVOS DE UNA BUENA GESTION DE SERVICIOS DE TI EN
EL MARCO ITIL
2. EXPLIQUE ACERCA DE LOS 3 PILARES PARA EL SOPORTE AL SERVICIO SEGÚN
ITIL
3. EN QUE CONSISTE UNA SOLICITUD DE CAMBIO RFC EN EL MARCO DE ITIL,
EJEMPLO
Un Solicitud de Cambio (RFC) es una solicitud formal para la implementación de un
Cambio. Se envía una Solicitud de Cambio a la Gestión de Cambios para cualquier
Cambio que no sea estándar (la Gestión de Cambios define usualmente un conjunto de
Cambios estándares/ de rutina; estos son cambios menos importantes que no
requieren ser sometidos al proceso de la Gestión de Cambios).
Un Cambio tiene el apoyo de un Propietario del Cambio, y tiene un presupuesto para
su implementación. En muchos casos el Propietario del Cambio es también el que
inicia el RFC. Normalmente, actúan como Propietarios de Cambio los propietarios de
roles de la Gestión de Servicios de TI (por ej. el Gestor de Problemas o Gestor de la
Capacidad) o a la Dirección de TI.
El Solicitud de Cambio (RFC) es un precursor del Registro de Cambio y contiene toda
la información requerida para aprobar el Cambio. Se añade información adicional
según pasa el Cambio por su ciclo de vida.
 Un cambio se generacon unasolicitudde cambio(RFC) que puede originarse
de un incidente,errorconocidoosolicituddirecta.
 Los RFC lospide normalmenteProblemManagementperoalgunosotros
procesoslos Gestióndel Cambio (Transición) pidende formaestándar.
 Los RFC puedenvenirtambiénde cambiosenlalegislación,unproyecto,un
proveedor, enfinde dentroofuerade la organizaciónsinque yasignifique
aceptación.
4. QUE ES UN ACUERDO DE NIVEL DE SERVICIO SLA EN EL MARCO DE ITIL,
EJEMPLO
Un Acuerdo de Nivel de Servicio (Service Level Agreement, SLA) es un
documento formal que delinea un compromiso de servicio proporcionado por
un proveedor de servicios de TI a uno o más clientes. Este SLA, describe los
servicios de TI, documenta los objetivos de nivel de servicio y especifica las
responsabilidades del proveedor de servicios TI y del cliente. Los SLAs dan
forma a los contratos legales que establecen el marco de los servicios TI y
permiten una mayor flexibilidad operativa entre las dos partes.
Ejemplo:

2. Algunos ejemplos de LSA’s son los acuerdos firmados por una organización y
una empresa que le provee servicios de protección de datos en los puntos
centrales de recepción y distribución de su red; otro ejemplo podría
considerarse el acuerdo firmado por la organización y una empresa que
proporciona el servicio de instalación y mantenimiento de software base a las
instalaciones de la primera.
Obs: Por si alguien quiere tirarse todo el examen escribiendo un LSA aquí les
dejo el resumen de uno XD:
Acuerdo de nivel de servicio para Avira Managed Email
Security
I. Ámbito de aplicación del Acuerdo de Nivel de Servicio
a. Este documento describe las prestaciones de servicios desempeñadas para los clientes
de los servicios de Avira Managed Security Services por Avira y por las empresas
vinculadas a ella de conformidad con el artículo 15 de la Ley de Sociedades Anónimas.
Igualmente,describe los criterios de rendimiento,la disponibilidad de los servicios,las
medidas a adoptar en casos de fallo del servicio y los correspondientes tiempos de
reacción y de reparación aplicados por estas empresas.
b. El siguiente Acuerdo de Nivel de Servicio (en adelante denominado “SLA”) se aplica a
todos los contratos de licencia entre la sociedad de responsabilidad limitada y
comanditaria colectiva Avira Operation GmbH y sus clientes acerca del desempeño de
los “Managed Email Security Services”, y en especial acerca de la prestación de
servicios administrados.
c. Avira puede modificar,actualizar o complementar este SLAen cualquier momento.Al
cliente se le informará por escrito de estas modificaciones (un correo electrónico se
considerará suficiente).El cliente tiene derecho a oponerse a las modificaciones que le
hayan sido comunicadas.En caso de que un cliente no se opusiera a todas o a algunas
de las modificaciones que le hubieran sido comunicadas en el plazo de cuatro (4)
semanas tras haber recibido la comunicación (en adelante denominada “plazo de
oposición”),las modificaciones comunicadas se considerarán reconocidas por el cliente.
II. Objeto del acuerdo y otras definiciones
Además de las definiciones que se encuentran a continuación se remitirá a las que se
encuentran en las Condiciones Generales de Contratación de Avira.
a. Malware conocido: designa al Malware que sea identificado por los software de
antivirus existentes que integran la prestación de servicios.
b. Fallo del servicio: hace referencia a una interrupción de la prestación del servicio
excepto cuando ésta se deba al mantenimiento sistemático.

3. c. Disponibilidad del servicio: designa en términos de porcentaje el tiempo durante el
cual el servicio está a disposición del cliente dentro de un período de tiempo
definido.
d. Tiempo de escaneo de correos electrónicos: hace referencia al espacio de
tiempo durante el cual un correo electrónico se encuentra en proceso de escaneo
por Avira. No incluye el tiempo de entrega de y a los Sistemas de Avira.
e. Falso positivo: hace referencia a la clasificación errónea como spam o malware de
un correo electrónico legitimado a través de la técnica de escaneo,asícomo a las
molestias resultantes de lo anterior y que afecten a la entrega.
f. Horario comercial: designa el horario de lunes a viernes entre las 8:00 y las 17:00
horas exceptuando los días festivos de ámbito nacional en Alemania.Todas las
indicaciones temporales según la Hora de Europa Central CET (GMT/UTC + 1 hora).
g. MyAccount: designa la página web a través de la cual los clientes pueden acceder
mediante login (identificación del usuario) a los servicios ya su configuración.
h. Open Relay: hace referencia a un servidor de correo electrónico mal configurado al
que pueden acceder terceros de forma abusiva.
i. Mantenimiento sistemático: designa los trabajos de mantenimiento realizados por
Avira o por los submandatarios designados por ella sobre sus propias redes,centros
de cálculo,servidores y medios de producción.
j. Tiempo de reparación: designa el tiempo medido por Avira que dentro del horario
comercial ha transcurrido entre la recepción en Avira de la notificación de error de un
cliente y el restablecimiento del servicio por Avira.
k. Filtro de spam: designa un dispositivo de seguridad con cuya ayuda se reduce la
cantidad de mensajes de spam transferidos al sistema de correo electrónico.
III. Niveles de servicio
Los servicios de Avira Managed Email Security Services serán fundamentalmente
desempeñados como sigue:
Disponibilidad del servicio (al
año)
99,9%
Tiempo de escaneo de correo
electrónico (un correo electrónico
de tamaño medio)
3 segundos
Cuota del filtro de spam 99,9%*
Identificación de malware 100% del malware conocido
Cuota de falsos positivos 0,00001%*
Tiempo de reparación
De conformidad con las
categorías de errores según
el apartado 7
IV. * para una configuración estándar

4. V. Comunicación
Los clientes pueden comunicarse por correo electrónico con Avira Support a través
de support@avira.com o telefónicamente durante el horario comercial:
0049/(0)1805/2684847 (14 céntimos por minuto desde la red de telefonía fija alemana,
máx. 42 céntimos por minuto para llamadas desde la red de telefonía móvil alemana).
Tenga en cuenta que el soporte de Avira está disponible en inglés o alemán.
VI. Mantenimiento
a) Cualquier mantenimiento sistemático que implique una interrupción del servicio de
más de cinco minutos será puesto en conocimiento del cliente con los siguientes datos
como mínimo 48 horas antes del mantenimiento sistemático:
i) hora del mantenimiento,
ii) duración previsible de la interrupción y
iii) grado previsible de la gravedad de la interrupción.
b) Siempre que sea posible,todo mantenimiento sistemático que implique una
interrupción del servicio de más de cinco minutos será realizado entre las 19:30 y las 7
horas.
VII. Fallo del servicio y proceso de notificación
a. El cliente notificará de forma inmediata a Avira todos los fallos del servicio y Avira en
contrapartida informará al cliente acerca de la naturaleza del fallo del servicio
correspondiente y del tiempo de reparación previsible.
b. De cara al restablecimiento del servicio el cliente deberá prestar si fuera necesario todo
el apoyo necesario yrazonable.
c. Avira informará al cliente lo más rápido posible cuando el mal funcionamiento no esté
relacionado con el servicio.
d. Avira avisará al cliente tan pronto como el fallo del servicio haya sido reparado.
VIII. Tiempo de reparación y categoría de errores
Avira procurará reparar cualquier interrupción del servicio lo antes posible de acuerdo
con el protocolo según la tabla mostrada a continuación.
Categoría
de error 1
Error crítico
Fallo grande y crítico
del servicio debido al
cual el servicio queda
totalmente
interrumpido.
El 95% de todas las averías
serán reparadas en el
transcurso de dos horas
durante el horario
comercial.

5. Categoría
de error 2
Error
considerable
Fallo esencial del
servicio debido al
cual el servicio queda
interrumpido de
forma masiva o que
tiene como
consecuencia grandes
retrasos.
El 85% de todas las averías
serán reparadas en el
transcurso de cuatro horas
durante el horario
comercial.
Categoría
de error 3
Error de
gravedad
media
Fallo del servicio
estándar que o no
influye nada en el
escaneo de correos
electrónicos y en su
reenvío o lo hace de
forma no
considerable.
El 75% de todas las averías
serán reparadas en el
transcurso de ocho horas
durante el horario
comercial.
Categoría
de error 4
Error
mínimo
Solicitudes de
información en
relación con los
servicios
El 65% de todas las averías
serán reparadas en el
transcurso de ocho horas
durante el horario
comercial.
IX. Protección de datos
a. Avira y el cliente se obligan a respetar las leyes de protección de datos.
b. En caso necesario,se llegará a un acuerdo acerca del procesamiento de datos de
pedidos en un documento separado.
X. Exclusión
a) El cliente no podrá remitirse a este SLA en los siguientes casos:
i) el fallo del servicio se debe al mantenimiento sistemático,
ii) el fallo del servicio del servicio está relacionado con servicios que no son
funciones de los Managed Services.
iii) el fallo del servicio se debe a un fallo de usuario o de administración del
servicio,como por ejemplo un “open Relay”.
iv) el fallo ha sido causado de forma intencionada por acción u omisión del cliente
o de un tercero.
5. EN QUE CONSISTE UNA PETICION DE SERVICIO EN EL MARCO DE ITIL

6. Se ocupa de los servicios ofrecidos en si mismos. En particular de los Niveles de
servicio, su disponibilidad, su continuidad, su viabilidad financiera, la capacidad
necesaria de la infraestructura TI y los niveles de seguridad requeridos
El siguiente diagrama interactivo resume sucintamente los principales aspectos
de la metodología de provisión del servicio según los estándares ITIL
6. EN QUE CONSISTE UN CHECKLIST POST IMPLEMENTACION REVIEW (PIR)
La Revisión de la Implementación Post (PIR) se lleva a cabo después de la
finalización del proyecto, pero antes de hacer mejoras finales. Idealmente, debería
ocurrir después de que el sistema ha estado en vigor el tiempo suficiente para
permitir la adopción de criterios sobre cómo se va a realizar a largo plazo. Su
propósito es evaluar cómo se cumplieron con éxito los objetivos del proyecto y la
eficacia de las prácticas de gestión de proyectos fuera. Documentar los resultados
del PIR en un informe de cerca fuera llamado el informe posterior a la revisión de la
implementación.
La realización de un PIR oportuna y exhaustiva ayudará a identificar las lecciones
aprendidas y las deficiencias identificadas previamente. Estos, a su vez, ayudará a
hacer mejoras finales al sistema que está siendo implementado elementos de las
lecciones aprendidas también ayudará en la planificación, la gestión y el
cumplimiento de los objetivos de los proyectos futuros.
La siguiente lista pretende ser bastante completo y se puede reducido a satisfacer
sus necesidades y la escala del proyecto.
7. EXPLIQUE LA GESTION DE INCIDENCIAS EN EL MARCO DE ITIL
8. QUE RELACION TIENE LA GESTION DE INCIDENCIAS Y LA GESTION DE
PROBLEMAS?’’
9. QUE PASOS SE SIGUEN PARA EVALUAR EQUIPAMIENTO INFORMATICO?

7. a) DeterminarNecesidadde Equipamiento
b) Definirrequerimientosdel equipamiento
c) Recolectarinformacióndel equipamientoenproveedoresde equipos
d) Determinaralternativasde evaluaciónde equipos
e) Definirfactoresde evaluación
f) DefinirPonderadosparacada factor
g) DefinirPonderadosparacada factor
h) RealizarMatrizde Evaluación
i) Realizarlasconclusionesdelestudio
10. REALICE UNA EVALUACION DE POVEEDOR DEINTERNET PARA LA FACULTAD?
11. REALICE UNA EVALUACION DE MOTORES DE DATOS PARA UNA
ORGANIZACIÓN?
12. REALICE UNA MATRIZ DE DIAGNOSTICO DE PROBLEMAS INFORMATICOS
PARA EL AREA DE DESARROLLO DE SISTEMAS EN UNA ENTIDAD BANCARIA
Normalmente un área informática tiene algunos de estos elementos mostrados
a continuación:

8. Jefatura del Área
Informática
Secretaría general
Documentadores
Dpto. de Calidad
Analistas de calidad
Testers
Dpto. de Desarrolloy
Producción
Jefes de Proyecto
Analistas Programadores
Programadores
Dpto. de Mantenimiento
Técnicos de Redes
Técnicos de
mantenimiento de
HW/SW
Técnicode
Mantenimientode BD
Dpto. de Análisis
Analistas Funcionales
Analistas delNegocio
Analistas de
requerimientos
Dpto. de Seguridad de la
Información
Administradorde
Seguridad de redes
Administradorde base de
datos

9. Para cada área se encontró algunos problemas, de los cuales podemos detallar los siguientes:
AREA TEMA PROBLEMAS MOTIVO SOLUCION
AREAINFORMATICAENGENERAL
POLITICASDE
FUNCIONAMIENTO
YREGLASDELA
EMPRESA
No hay un usuario específico para elaborar
las tareas
Los roles no están definidos o no están
claros en el departamento
Redactar o revisar el documento de roles
(MOF) con el fin de definir los roles de cada
empleado dentro del área
No hay rotación en la asignación de roles de
personal. Riesgo de corrupción de personal
Existe una fuerte idelogía sobre fijar
responsabilidades sin cambios.
Elaborar un cronograma de roles cada cierto
tiempo con el fin de reducir riesgos en la
gestión de la información
IDENTIFICACIONDE
RIESGOS
PORELACCESODE
TERCEROS
Ingreso de personal no autorizado en
lugares críticos del área.Ejemplo oficinas
donde se encuentra el servidor de base de
datos.
Poco compromiso por parte del personal,
falta de equipo de vigilancia.
Regular las normas y penalizaciones,
implementación de equipos de seguridad en
el área
Robos, asaltos y hurtos. Falla en la seguridad de personal.
Implementar equipos de vigilancia,
contratos con personal de vigilancia.
SEGURIDADLIGADAAL
PERSONAL
Falta de compromiso con la empresa. Puede
generar riesgos de corrupción.
Falta de incentivos, ambiente,estrés .
Crear incentivos para el personal
(aguinaldos), eventos (partido, celebración
de cumpleaños) cada cierto tiempo.
Paradigmas en la ideología del personal.
Genera que el trabajo no se elabora de
acuerdo a los procesos establecidos.
Antecedentes en trabajos previos,
costumbre.
Pre- selección adecuada. Capacitaciones
cada cierto tiempo. Transparencia sobre las
actividades que se harán y cómo se harán, de
ser posible por escrito.
OUTSOURCING
No se utiliza política de confidencialidad en
todos los casos.
Se cuenta con clausualas de confidencialidad
pero no se aplica en todos los casos,lo cual
puede casusar fuga de información
Definir directiva que exija que todas las
contrataciones incluyan la cláusula de
confidencialidad.
Los Términos y Condiciones del Contrato de
Outsourcing Informática aplican a cualquier
divulgación de información confidencial
entre las partes.
No se realizó una correcta especificación del
contrato de Outsourcing respecto a la
política de confidencialidad
Anexar claúsulas que permitan establecer
normas de confidencialidad con las personas
que hacen uso de información crítica

10. AREA TEMA PROBLEMAS MOTIVO SOLUCIONDEPARTAMENTODEDESARROLLO/ANALISIS
POLITICASDEFUNCIONAMIENTO
YREGLASDELAEMPRESA
El personal elabora los avances a ciegas, no
se conocen los avances reales de las tareas.
Riesgo de no tener una transparencia en el
trabajo. (No se conocen los avances reales
del personal)
Utilizar un manejador de avance de personal
(Ejemplo: Remind).
Se desconoce la versión de avance del
producto. Existen muchas copias del
produto.
No existe un repositorio de codigo producto
a desarrolllar
Utilizar un repositorio de codigo para el
desarrollo adecuado del producto.
Las peticiones de uso de información para
desarrollo se hacen en base de palabra.
Riesgo de no tener una transparencia de
trabajo.(No se conoce quién solocitó los
permisos y bajo qué motivo).
El personal debe de usar algúm medio para
formalizar las peticiones o pases
solicitados(Ejemplo: correo empresarial.)
No es posible detectar el bloque de cógido
ligado a un defecto en el producto.
Bugs del producto no son guardados en logs
de error.
Tener un log de seguimiento y fallas dentro
del producto con el fin de detectar bugs y
corregirlos
IDENTIFICACIONDE
RIESGOSPOREL
ACCESODETERCEROS
Acceso de codigo malicioso (malware,
virus,otros) al equipo de desarrollo.
Antivirus desactualizado, personal que usa el
equipo contribuye al acceso de codigo
malicioso.
Actualizaciones constantes en cada revisión
de equipos. Concientizar y capacitar
internamente al personal sobre lo básico de
seguridad.
Acceso remoto no deseado (Ejemplo:
Hackers).
Fallas de seguridad en el sistema.
Se debe hacer revisiones continuas con el fin
de reducir las fallas de seguridad, tener lo
más actualizado los respaldos de seguridad.
AREA TEMA PROBLEMAS MOTIVO SOLUCION
DEPARTAMENTODE
MANTENIMIENTO
POLITICASDE
FUNCIONAMIENTO
YREGLASDELAEMPRESA
No hay una fecha fija de revisión de equipo
técnico.
No existe un registro de avance del personal
o de asignación de tareas
Elaborar un cronograma de revisión de
equipo técnico.
Los usuarios pueden acceder desde su casa a
ordenadores del trabajo sin un control.
No hay políticas definidas para accesos
remotos
Establecer políticas de acceso remoto.
No se encuentran reemplazos suficientes
para hacer reparaciones
El taller de soporte no posee los materiales
suficientes.
Implementar y solicitar cada cierto tiempo
piezas para las reparaciones.

11. AREA TEMA PROBLEMAS MOTIVO SOLUCIONDEPARTAMENTODESEGURIDADDELAINFORMACION
POLITICASDE
FUNCIONAMIENTO
YREGLASDELA
EMPRESA
Los backups se elaboran en fechas diferentes
cada mes
Aún no existe un cronograma definido de
elaboración de copias de seguridad
Elaborar un cronograma de generación de copias de
seguridad, tanto internas como externas
Ante una incidencia, el personal no sigue un
procedimiento estándar para solucionarla
El negocio no cuenta con alguna certificación
(ejemplo ISO), o cuenta con ella pero aún no
se está ejecutando.
En caso no halla alguna certificación se debe de definir las
políticas de como proceder ante incidencias, y en caso la
halla se debe de poner en ejecución bajo un análisis previo.
IDENTIFICACIONDERIESGOSPOREL
ACCESODETERCEROS
Permisos de acceso no definidos a nivel de
software. Ejemplo: otorgar a un
programador permisos de acceso a datos de
producción para uso de desarrollo.
Falla en asignación de permisos de acceso.
Crear y ejecutar un protocolo de asignación y autorización
de permisos de acceso. Agrupar los equipos hw/sw para
usos exclusivos de desarrollo/producción (e incluso,
pruebas).
Ingreso de personal no autorizado en
lugares críticos del área (Ejemplo Oficina
donde se encuentra el servidor de base de
datos).
Poco compromiso por parte del personal,
falta de equipo de vigilancia.
Regular las normas y penalizaciones, implementación de
equipos de seguridad en el área
Acceso remoto no deseado (Ejemplo:
Hackers).
Fallas de seguridad en el sistema.
Se debe hacer revisiones continuas con el fin de reducir las
fallas de seguridad, tener lo más actualizado los respaldos
de seguridad.

12. 13. QUE ES EL KAISEN INFORMATICO? APLIQUELO AL AREA DE SOPORTE DE
LAFACULTAD
Una estrategia de Kaizen mantiene y mejora el estándar de trabajo mediante
mejoras pequeñas y graduales.
El Kaizen se enfoca pues en la mejora continua de los estándares en materia de
calidad, productividad, costos, seguridad, y entrega. Para ello da primacía a la
calidad como componente central que permite y facilita a través de su concreción
el cumplimiento de los demás objetivos.
El Kaizen informático implica tanto la aplicación de la filosofía y estrategias, como
de los diversos instrumentos, métodos y herramientas de análisis y gestión que le
son propias a la mejora continua de las actividades y procesos informáticos.
Kaizen aplicado al área de soporte
Un elemento central en la práctica del kaizen lo constituye la identificación y
eliminación sistemática de los desperdicios o despilfarros (mudas), entre los cuales
se tienen:
Mudas de Inventario.
Mudas de Transporte.
Mudas de Reparaciones.
De tal forma y sólo a título de ejemplo podemos mencionar los siguientes casos:
Inventario
Exceso de insumos y repuestos. Entre los insumos se tienen las distintas
maquinas utilizadas en la facultad (pc’s, proyectores, monitores), los dispositivos
de repuestocomo estabilizadores, fuentes de alimentación, placas madre, case de
CPU, etc.
Transporte
Podemos disminuir el flujo de transporte, si en lugar de transportar insumos y
repuestos, los mismos se encuentran inventariados en cada sector de la facultad
(aulas, áreas de atención, etc.)
De igual forma en lugar de que un alumno y/o docente solicite un software de
instalación, este software se encuentre almacenado en un servidor del cual tengan
acceso mediante credenciales privadas.
Reparaciones
Entre las reparaciones se tienen las de hardware y/o software (sistemas
operativos, aplicaciones) provocadas por una falta de política de prevención en
materia de protección (Ejemplo: la falta de uso de baterías de energía lleva a

13. daños en los archivos o en los dispositivos internos, debido a los problemas de
corte de suministro de energía).
Los casos mencionados pueden ser ampliados haciendo para ello uso de las más
diversas herramientas tales como la Tormenta de Ideas, el Diagrama de Ishikawa
entre otros.
APLICACIÓN DE LAS 5 S (housekeeping)
1. Seiri: diferenciar entre los elementos necesarios de los innecesarios en el
lugar de trabajo, descartando a estos últimos.
2. Seiton: disponer en forma ordenada todos los elementos que quedan
después de aplicado el Seiri.
3. Seiso: mantener limpias las máquinas y los ambientes de trabajo.
4. Seiketsu: extender hacia uno mismo el concepto de limpieza y practicar
continuamente los tres pasos anteriores.
5. Shitsuke: construir autodisciplina y formar el hábito de comprometerse en las
5 S mediante el establecimiento de estándares.
14. ES POSIBLE APLICAR DE MANERA CONJUNTA ITIL Y COBIT? PORQUE?
Si es posible. ITIL no puede dominar una empresa por sí solo, esta es una buena
práctica llevada por la gente de TI pero no tiene una forma de gobierno.
ITIL requiere un marco de políticas, procesos, procedimientos y métricas que
puedan dar directrices para las operaciones que se llevarán a cabo. CobiT.
15. EN QUE CONSISTE LA GESTION DE PROBLEMAS?
Consiste en :
• Investigar las causas subyacentes a toda alteración, real o potencial, del
servicio TI.
• Determinar posibles soluciones a las mismas.
• Proponer las peticiones de cambio (RFC) para restablecer la calidad del
servicio.
• Realizar Revisiones Post Implementación (PIR) para asegurar que los
cambios han surtido los efectos buscados sin crear problemas de
carácter secundario.
Reactiva: Analiza los incidentes ocurridos para descubrir su causa y
propone soluciones a los mismos.

14. • Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su
configuración con el objetivo de prevenir incidentes incluso antes de
que estos ocurran.
Objetivo:
 Restablecer lo más rápidamente la calidad del servicio y no el
determinar cuales han sido los orígenes y causas del mismo.
 Cuando algún tipo de incidente se convierte en recurrente o tiene un
fuerte impacto en la infraestructura TI es la función de la Gestión de
Problemas el determinar sus causas y encontrar posibles soluciones.
16. EN QUE CONSISTE LA GESTION DE CAMBIOS?
17. EN QUE CONSISTE LA GESTION DE VERSIONES?
La Gestión de Versiones es la encargada de la implementación y control de
calidad de todo el software y hardware instalado en el entorno de producción.
La Gestión de Versiones debe colaborar estrechamente con la Gestión de
Cambios y de Configuraciones para asegurar que toda la información relativa
a las nuevas versiones se integra adecuadamente en la CMDB de forma que
ésta se halle correctamente actualizada y ofrezca una imagen real de la
configuración de la infraestructura TI.
La Gestión de Versiones también debe mantener actualizada la Biblioteca de
Software Definitivo (DSL), donde se guardan copias de todo el software en
producción, y el Depósito de Hardware Definitivo (DHS), donde se almacenan
piezas de repuesto y documentación para la rápida reparación de problemas
de hardware en el entorno de producción.
La Gestión de Versiones debe mantener actualizada:
Biblioteca de Software Definitivo (DSL): Guardan copias de todo el software
en producción
Depósito de Hardware Definitivo (DHS): Almacenan piezas de repuesto y
documentación para la rápida reparación de problemas de hardware en el
entorno de producción
Tipos:
Mayores: Importantes despliegues de sw y hw y que introducen
modificaciones importantes en la funcionalidad, características técnicas, etc.
Menores: Corrección de varios errores conocidos puntuales y que a menudo
son modificaciones que vienen a implementar de una manera correctamente
documentada soluciones de emergencia.

15. De emergencia: modificaciones que reparan de forma rápida un error
conocido
Ejm: Versiones mayores: 1.0, 2.0, etc.
Ejm: Versiones menores: 1.1, 1.2, 1.3, etc.
Ejm: Versiones de emergencia: 1.1.1, 1.1.2, etc.
18. EN QUE CONSISTE UN SERVICE DESK PARA ITIL?
Un ServiceDesk, o centro de Servicios es una interfaz para los clientes y
usuarios de todos los servicios TI con un enfoque centrado en los procesos de
negocio, que funciona como un centro neurálgico de todos los procesos de
soporte al servicio y una de las partes que ayuda a brindar este soporte es el
call center, gestionando llamadas y redirigiendo a los usuarios a otras
instancias de soporte y/o comerciales, entonces un call center en sí no es un
servicedesk, pero si forma parte de este y junto con otras entidades logran
formar un centro de servicios. El centro de servicios esta formado del call
center + HelpDesk + Supervicion de los contratos y canalización de las
peticiones de servicios de los clientes y mas la Gestion de las licencias de
software, y centralización de todos los procesos asociados a la Gestion TI.
19. ES UN CALL CENTER UN SERVICE DESK EN EL MARCO DE ITIL... POR QUE?
Si, debido que un call center tiene como objetivo gestionar un alto volumen de llamadas
y redirigir a los usuarios, excepto en los casos más triviales, a otras instancias de soporte
y/o comerciales.
Ademas de ello,según la definición de servicedesk viene ser aquella que proporciona un
punto de comunicación entre los usuarios y el servicio y un punto de coordinación entre
grupos y procesos del servicio.
Y debe cumplir los siguientes puntos:
 Sea fácilmente accesible.
 Ofrezca un servicio de calidad consistente y homogéneo.
 Mantenga puntualmente informados a los usuarios y lleve un registro de
toda la interacción con los mismos.
Por lo tanto un call center es un servicedesk en el marco de Itil.