Este documento describe el proceso de gestión de cambios según el marco ITIL en la Municipalidad de Puriscal. La municipalidad propone implementar un servidor proxy y separar las áreas en redes diferentes para mejorar el rendimiento. El proceso incluye registrar las solicitudes de cambio, planificar la implementación, probar los cambios en entornos de desarrollo y prueba, e implementarlos en producción. Después de la implementación, se realiza una encuesta de satisfacción y se registra un incidente relacionado con la falta de UPS que es resuelto

1. GESTIÓN DE CAMBIO
• Ericka Cambronero Chinchilla
• Cedula 0115190410
• Centro universitario: Puriscal
• Proyecto 1
• Gestión del cambio según itil

2. GESTIÓN DEL CAMBIO
La gestión del cambio es un proceso usual en todos los de gestión TI, cuyo proceso tiene
una estructura compleja con múltiples interrelaciones entre varios procesos que
mantienen, modifican o mejoran el servicio.
El proceso del cambio según ITIL lo propone de manera interna, enfocado a que exista
una gestión de cambios estratégico, donde todas las intervenciones que tengan que
realizarse se canalicen para seguir ofreciendo un servicio cada vez mejor y sin interrupción.

3. ITIL
Information Technology Infrastructure Library
‘Biblioteca de Infraestructura de Tecnologías de Información’.
Es un marco de trabajo de las mejores prácticas destinadas a facilitar la entrega de servicios
de tecnologías de la información (TI) de alta calidad.

4. ¿CÓMO SE LOGRA?
• Evaluando cambios por los beneficios, riesgos e impactos.
• Priorizando los cambios; asignando los recursos según las necesidades.
• Realizando pruebas para los cambios y contando con planes de contingencia para
restaurar al estado anterior.

5. BENEFICIOS GESTIÓN DEL CAMBIO
• Agilización, flexibilidad y proactividad.
• Confiabilidad: el proyecto es monitorizado al hacer cambios.
• Confianza: se establecen mecanismos para la toma de decisiones.
• Transparencia.

6. CARACTERÍSTICAS DE ITIL
Dar prioridad a los cambios de forma eficiente sin que
exista impacto negativo.
Mejores practicas para entregar valor a los clientes a
través de servicios.
Mejoras a las tecnologías actuales para satisfacer las
demandas de los usuarios.

7. OBJETIVOS DE ITIL
1. Mejorar la calidad de los servicios IT.
2.Evitar los problemas asociados a los servicios.
3. Menor impacto, mayor brevedad.
4. Tener un marco para actuar en caso que existan
problemas.
5. Normalizar la planificación, entrega y soporte de
servicios de TI.

8. CAMBIOS SEGÚN ITIL
Recomendaciones
Para actualizar los cambios con TIL se disponga de una CMDB (Change
Management Data Base) o base de datos para la gestión del cambio,
donde se recojan los datos provenientes de las RFC (Request for Change -
peticiones de cambio) de la que se obtendrán para su posterior análisis,
evaluación y se planifique un posible cambio.
Todas las interacciones con la CMDB serán la base del gestor de
conocimiento, herramienta actual e incluida a partir de ITIL v3. Estas
interacciones, como se dijo anteriormente, provienen de multitud de
proceso.

9. ITIL PROPONE DOS ATORES
Gestor de cambios: es el responsable de la gestión del cambio en la
organización. De esta persona depende la aceptación y clasificación
de las peticiones de cambio (RFC).
Consejo Asesor del Cambio (CAB – Change Advisory Board): es un
equipo de asesoramiento y consulta que se reúne periódicamente
(en ITIL v3 se aceptan las reuniones on-line) para evaluar, planificar y
priorizar los cambios a llevar a cabo.

10. PROCESOS DE ITIL
ENTRADA
Peticiones de cambio: Toda petición de modificación de la infraestructura, que no
provenga de cambios cíclicos o estandarizados ha de generar un RFC, que posteriormente
tiene que ser registrado.
• Que no provenga de cambios cíclicos
o estandarizados ha de generar un RFC.
• Posteriormente tiene que ser registrado.
Peticiones de
cambio:
• Incluir en la CMDB la petición de
cambio, con cambios como:
• Codificación, Estado. Fecha de entrada.
Fecha de aceptación. Prioridad asignada.
Categoría. Planes de soporte. Planes de
recuperación. Recursos asignados Plan
de implementación. Cronograma.
Revisión. Evaluación. Fecha de cierre.
Registro
• Cuando se ha registrado una RFC
con todos los datos de los que
pueda disponerse debe de ser
evaluado.
• Existe la posibilidad de que la RFC
sea descartada o rechazada.
Aceptación.

11. ENTRADA
• Cuando tiene la aceptación por parte del
gestor de cambios, es necesario su
filtrado por parte de la CAB para que los
cambios aceptados pasen a ser
clasificados.
Filtrado.
• Es la encargada de priorizar y categorizar
la petición.
• La priorización se realizará sobre unos
baremos numéricos que den valor a
aspectos tales como dificultad, coste,
tiempo, recursos necesarios, necesidad,
etc.
Clasificación.
• La organización debe documentar un
procedimiento de mecanismos de acción
rápida, que sean eficaces y monitorizados.
• Se activen las gestiones y los planes
derivados en el menor tiempo posible y se
prevea la continuidad y calidad del
servicio.
Procedimiento
de urgencia

12. PLANIFICACIÓN
Para comenzar a planificar un cambio es preciso que el CAB se reúna para realizar
un análisis de impacto y ver las necesidades de recursos. Como:
Seguridad del
proceso.
Recursos necesarios.
Costes asociados.

13. PLANIFICACIÓN
Capacidad y disminución del
rendimiento de los servicios.
Fiabilidad y recuperación -
planes de recuperación, planes
de contingencia.
Personas necesarias para la
implementación.
Incompatibilidades y posibles
conflictos.
Pérdidas e impacto de la no
implementación.

14. IMPLEMENTACIÓN
Construcción.
• El software que se está desarrollando cumple los
plazos.
• Existe un plan de recuperación.
• Se han estimado los cambios de hardware.
• Existe nueva documentación y procedimientos de
instalación.
• La gestión de la calidad del software se lleva a cabo.

15. IMPLEMENTACIÓN
Pruebas.
• Funcionalidad.
• Usabilidad.
• Accesibilidad.
• Integración.

16. EVALUACIÓN
Evaluación .
• Evaluación de indicadores del proceso.
• Número de cambios implementados en un
período determinado.
• Causas que provocaron los cambios.
• Número de cambios que resultaron exitosos.
• Número de cambios que necesitaron poner en
marcha planes de recuperación.

17. CASO PRACTICO
• Ericka Cambronero Chinchilla
• Cedula 0115190410
• Centro universitario: Puriscal
• Proyecto 1
• Gestión del cambio según itil
• Caso practico en la Municipalidad de
puriscal.

18. CASO INTEGRADOR DE ITIL
MUNICIPALIDAD DE PURISCAL

19. CASO INTEGRADOR DE ITIL V3
La Municipalidad de Puriscal cuenta con 47 funcionarios, distribuidos en 12
áreas, tiene una conexión ADSL de 4 MB, cuenta con 03 servidores (FTP,
Aplicaciones y un Active Directory), cuenta con switch no administrables, su
cableado utiliza Cable UTP. Se aplicó una encuesta a los usuarios que tan
satisfechos se sienten con la red y como consecuencia los resultados fueron
muy desagradables con lo que respecta al área de Asesoría Interna, Recurso
Legal, y Gestión Tecnológica de Información, ya que ellos hacen uso del
Sistema integrado en la Planificación Institucional, que funciona de manera
online para transmitir datos. Las otras áreas no tuvieron calificaciones
negativas a cerca de del acceso a internet, ya que estas áreas debería utilizar
el internet únicamente para el envío de correos entre sí.

20. ENTRADA
• Peticiones de cambio, en el cual se registra el cambio como un cambio planeado, y con
un impacto alto, ya que si hay alguna falla en la instalación afectará a los 47 usuarios que
contiene la red.
• Se pretende implementar el protocolo ARP, el cual es un protocolo estándar específico de
las redes en área de TI piensa en implantar un Servidor Proxy para bloquear el acceso a
determinados usuarios a internet y ver la manera de separar las áreas de la municipalidad
en diferentes redes
• Ahora se comunica a un especialista en Seguridad que trabaja en la Municipalidad para
que implemente el cambio.

21. PLANIFICACIÓN
• Luego se crea un calendario de fechas para instalar y configurará el Proxy SQUID primero
en una máquina Virtual (VirtualBox), y luego se instalará e implemente por un periodo de
15 días en el servidor en un ambiente parecido al de producción.

22. PLANIFICACIÓN
Seguridad en el proceso Costos asociados Plazo
Se guardan los datos que
están implementados
actualmente para hacer los
cambios
Compra de materiales como
switch, cable UTP,
adaptadores, herramientas,
entre otros.
Tres meses para la solicitad e
implementación de los
cambios.
Se registran los nuevos
equipos adquiridos y sus
atributos (ID, nombre, serie,
departamento responsable,
etc) utilizados para la
implementación de la
Solución (1 Servidor IBM, 4
Switch Cisco).
Tiene un presupuesto de 400
000 para la implementación
de cambio.
Un periodo de 15 días
después para la evaluación y
las pruebas del nuevo
implementado

23. IMPLEMENTACIÓN
• El Asistente de Sistemas recibe una llamada del área de Alcaldía, el cual solicita
valorar la solicitud par hacer los cambios, el cual procede instalando primero el
SQUID en una máquina Virtual (entorno de desarrollo) por un período de 7 días.
• Luego se instala en un ambiente parecido al de producción (entorno de pruebas)
por 7 días más.
• Finalmente se realiza una implementación total de la solución un día sábado a
partir de las 8 am en el cual no trabaja el prsonal para evitar retrasos en las
labores del personal. Se conectan los cables de la LAN a las NIC del Servidor y se
reemplazan los switch con sus respectivas VLAN creadas (Entorno de
Producción)..

24. EVALUACIÓN
• Se realiza una encuesta a los usuarios para determinar el nivel de satisfacción en
implementación del nuevo sistema, aunque los resultados son favorables del
nuevo uso del sistema, ya que el intranet tiene una mejor velocidad al responder
las solicitudes, que realizan cada uno.

25. GESTIÓN DE LA SEGURIDAD DE LA INFORMACIÓN
• El servidor estará ubicado en un área protegida ante la intrusión de cualquier
personal que no esté autorizado.
• Todos los switch están ubicados dentro de su respectivo RACK de pared.

26. GESTIÓN DE PROBLEMAS
• Este pasa el incidente al Administrador de Servidores, para que analice el
problema y dé una solución al problema. El administrador de servidores planea
(Gestión de cambios) adquirir 3 UPS para que cubra todos los usuarios de las 4
áreas, se compran los UPS y se instala para las 4 áreas (Gestión de Despliegue)
para finalizar se registra este problema.

27. GESTIÓN DE INCIDENCIAS
• El Asistente de Sistemas recibe una llamada del área de Asesoría Legal que tiene
un problema con el acceso a la red, éste registra el incidente con todos sus
atributos (ID, impacto, Prioridad, etc) en una herramienta Libre CACTI
(Herramienta para gestionar incidentes). Como el Asistente no tiene estudios de
Redes, comunica al Administrador de la Red (Escalamiento). El administrador de
red analiza el incidente y descubre que el Switch Cisco tenía seguridad de capa 2
y había bloqueado el puerto porque un Abogado había conectado una laptop
nueva a ese punto de red.
• El Administrador de la Red desbloquea el puerto y se soluciona el incidente y se
documenta el incidente.

28. RESOLUCIÓN DEL CASO
Gestión del Catálogo de Servicios (Se hacen reajustes de los servicios que se van a ofrecer
Por lo que se implementa el protocolo ARP ya que es un protocolo estándar específico de las
redes. para desea enviar datos a una determinado dirección IP de destino, el mecanismo de
encaminamiento IP determina primero la dirección IP del siguiente salto del paquete y el
dispositivo hardware al que se debería enviar, el cual lo bloquea para que no genere gastos de
licencia a la Municipalidad, que permita acelerar en acceso a internet, filtre dominios de páginas
web, Bloquee las descargas de archivos (exe, mp3, avi, etc) y asigne anchos de banda
personalizados.

29. BIBLIOGRAFÍA
• Sergio Ríos Huércano, S. (s.f.). Manual ITIL V3.
• Herramienta web para la enseñanza de protocolos de informacion. (s.f.). ARP.
Obtenido de http://neo.lcc.uma.es/evirtual/cdd/tutorial/red/arp.html
• Municipalidad de Puriscal . (s.f.). Obtenido de
http://ungl.or.cr/municipalidades/municipalidad-de-puriscal