Ejemplo: Documento Gestion de Cambios

IMPLEMENTACION NUEVO PROCESO Código: CC-001
GESTION DE CAMBIOS Versión:01
Proceso:
Fecha de emisión: Fecha de versión:
Investigación e
10-05-2014 16-03-2014
Implementación
IMPLEMENTACION NUEVO PROCESO DE CAMBIOS

ENFOCADO EN PROCESOS T.I.
PRESENTADO POR:
CLAUDIA MYLENA SUAREZ VELASQUEZ
MONOGRAFIA PRESENTADA PARA OPTAR POR EL TITULO DE INGENIERA

DE SISTEMAS
ESCUELA COLOMBIANA DE CARRERAS INDUSTRIALES

FACULTAD INGENIERIA DE SISTEMAS
BOGOTA, DC
2014
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
IMPLEMENTACION NUEVO PROCESO DE CAMBIOS

ENFOCADO EN PROCESOS T.I.
PRESENTADO POR:
CLAUDIA MYLENA SUAREZ VELASQUEZ
DIRECTOR
ING. JAIRO PALACIOS
ESCUELA COLOMBIANA DE CARRERAS INDUSTRIALES

FACULTAD INGENIERIA DE SISTEMAS
BOGOTA, DC
2014
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
Nota de Aceptación
___________________________
___________________________
___________________________
___________________________
___________________________
___________________________
Firma del Presidente del Jurado
___________________________
Firma del Jurado
___________________________
Firma del Jurado
Bogotá D.C, Agosto 2014

Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
TABLA DE CONTENIDO
Tabla de Contenido Pág.

1. PRESENTACION ............................................................................................................................7
2. NUEVO PROCESO GESTIÓN CAMBIOS .........................................................................................8
3. PROBLEMA DE INVESTIGACION ...................................................................................................8
3.1. DESCRIPCION DEL PROBLEMA ............................................................................................8
3.2. FORMULACION DEL PROBLEMA ..........................................................................................9
4. OBJETIVOS DE LA INVESTIGACION ...............................................................................................9
4.1. OBJETIVO GENERAL..............................................................................................................9
4.2. OBJETIVOS ESPECIFICOS.......................................................................................................9
5. JUSTIFICACION Y DELIMITACION DE LA INVESTIGACION .......................................................... 10
5.1. JUSTIFICACION .................................................................................................................. 10
5.2. DELIMITACION .................................................................................................................. 11
6. MARCO DE REFERENCIA DE LA INVESTIGACION ....................................................................... 11
6.1. MARCO TEORICO .............................................................................................................. 12
6.2 MARCO LEGAL ............................................................................. Error! Bookmark not defined.
7. DISEÑO METODOLOGICO...................................................................................................... 16
7.1. METODOLOGIA ITIL ........................................................................................................... 16
8. FUENTES PRIMARIAS ................................................................................................................. 43
9. RECURSOS ................................................................................................................................. 44
10. CRONOGRAMA...................................................................................................................... 44
11. GRUPO PROCESO DE CAMBIOS............................................................................................. 44
12. CONCLUSIONES ..................................................................................................................... 45
13. REFERENCIAS (BIBLIOGRAFIA)............................................................................................... 45
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
LISTA DE GRAFICAS
Pág.
Grafica 1. Proceso de Cambios ITIL 12
Grafica 2. Actividades de Gestión de Cambios 13

Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
LISTA DE FORMATOS
Pág.
1. Formato Proceso Interno Telefónica 42

Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
1. PRESENTACION
El siguiente documento es una presentación de la implementación del nuevo proceso de Cambios

dentro de Telefónica, para el debido control de los cambios a ejecutar dentro de la organización y
que causen los más mínimos incidentes en las plataformas y la continuidad del proceso.
7
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
2. NUEVO PROCESO GESTIÓN CAMBIOS
Al unificar la operación Fija y Movil, se identifica que el proceso de Cambios que se implementa no
contemplo algunos aplicativos que trajo la operación movil, y el impacto que causa el hecho de
realizar cambios en ellos.
La Operación Movil, no tiene un proceso para presentar cambios por medio de Comités, por ello se
saltan las reglas establecidas por la operación fija , trayendo consigo incidencias repetitivas al
ejecutar los cambios.
Al ver estos impactos se decidio unificar el proceso para implementarlo en ambas operaciones,
contando con un modelo de proceso formal y estándar, asi llegar a minimizar la ocurrencia de
incidentes con cambios sobre la calidad del servicio, garantizando el cumplimiento de las buenas
prácticas en todas las etapas del cambio e implantar todos los cambios aprobados de manera
exitosa.
3. PROBLEMA DE INVESTIGACION
3.1. DESCRIPCION DEL PROBLEMA
El Proceso de Cambios esta estipulado para cambios de operación Fija, pero al llegar la operación
Movil, quienes no cumplen con este proceso, se presentan muchas incidencias.
Los cambios deben tener un proceso de creación, coordinación, socialización y aprobación, pero la
operación movil, se salta el proceso de coordinación y solicita aprobaciones a los Gerentes, y
Directores, para que se socialicen sin cumplir con todo los pasos del mismo.
Por ello al ingresar a la socialización, se cruza con otros cambios, o perjudica a los mismos, que si
cumplen con el proceso.
Otra causa que se identifico, es el hecho de que crean cambios como normales (categoria principal
del cambio) y al no cumplir con el filtro que Control Cambios realiza, este no ingresa al acta de
cambios a socializar, al no ingresar, los coordinadores cambiaban el cambio a Urgencia (segunda
categoria de cambios), y se saltan el proceso, lo dicho anteriormente no es permitido según el
8
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
proceso actual de Gestión de Cambios, pero al tener autorización del Director, este se debe
presentar en el comité de Urgencias.
Tambien se identifico la inconformidad de los coordinadores con la cantidad de Audios para socializar
el cambio, por ello se busco unificarlos, pues al dia, debian estar hasta en tres comites, llegando asi
a la inconformidad por el tiempo adjudicado a los mismos, ya que debian sustentar el mismo cambio
varias veces.
3.2. FORMULACION DEL PROBLEMA
Como unificar el Proceso, para que se minimice el numero de incidencias, y se garantice una buena
practica del proceso de Gestión de Cambios?
4. OBJETIVOS DE LA INVESTIGACION
4.1. OBJETIVO GENERAL
Implementar el nuevo proceso de Gestión de Cambios, teniendo en cuenta las Tecnologias de la

Información, capacitando a las diferente Gerencias en la buena practica del proceso, para asi llegar
a minimizar las incidencias creadas al no cumplir con el proceso.
4.2. OBJETIVOS ESPECIFICOS
- Garantizar el cumplimiento de las buenas prácticas en todas las etapas del cambio
- Contar con un modelo de proceso formal y estándar
- Implantar todos los cambios aprobados de manera eficiente
9
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
5. JUSTIFICACION Y DELIMITACION DE LA INVESTIGACION
5.1. JUSTIFICACION
Una de las necesidades más apremiantes en el proceso de Cambios, debia ser las reglas a cumplir
para la presentación de los cambios.
En Telefonica el proceso no se ha canalizado de la manera mas adecuada por las diferentes areas,
y los coordinadores quienes deben realizar todo el tramite correspondiente a la presentacipon de los
cambios.
En la actualidad los comites tienen una duración de 7 horas los días Martes y Jueves, para la
preaprobación por parte de Control Cambios y en la tarde nuevamente se debe tener un audio con
los Gerentes y Director, para la aprobación de la ejecución de los mismos, volviendose un proceso
extenso, y tedioso para los coordinadores, por el tiempo dedicado al comité.
El interes principal de la implementación del nuevo proceso, se basa en la importancia de los cambios
a ejecutar, y de los impactos que estos causan en las plataformas, teniendo en cuenta la afectación
que estos tengan sobre el negocio, dedicando menos tiempo con mayor control para la presentación
y ejecución de los cambios.
Es por ello que a traves de esta propuesta se pretende dar resuesta haciendo asi el proceso mas
agil, coordinado, y confiable de la presentación de cambios., ademas de poder tener un consolidado
dee los cambios aprobados y ejecutados, manejando una metrica de cambios (bolsa de cambios)
autorizados a ejecutar por mes.
10
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
5.2. DELIMITACION
A pesar de que que este es un problema que afecta a la compañía en general, hemos optado por
realizar este nuevo proceso, en base y teniendo como objetivo, mejorar el proceso de Gestión
Cambios.
El presente proceso sera desarrollado bajo los criterios y dentro de los fundamentos de la Gestión
ITIL, bajo la asesoria y aprobación de los directivos del area de Tecnologia de Telefonica.
El proyecto es ambicioso, que si bien tiene un impacto fuerte ante el proceso, por ser nuevo, y cambia
el orden de las reglas que se tiene estipulada en el proceso actual, se pretende que a mas tardar en
3 meses el nuevo proceso ya sea sencillo para la creacion y presentacion de los cambios.
Posteriormente en el termino de 4 meses, una vez ya estabilizadas las reglas de la presentación de

cambios , se procedera a realizar una investigación sobre el nuevo proceso y el impacto causado en
el mismo.
En este proyecto principalmente vamos a tartar exclusivamente el cumplimiento de ciertas reglas

para la programación de cambios.
Este proyecto esta dirigido excusivamente a las areas involucradas a la programación, presentación,
sustentación y ejecución de cambios que impactaran a la compañía y su buen manejo.
El presente proyecto estará determinado por la metodología que permita la identificación de las
necesidades de los usuarios del sistema y la necesidad que tenga la compañía de llevar un proceso
detallado y confiable de la aprobación de cambios en las diferentes plataformas de la empresa el
cual una vez realizado se actualizara con la información que se vaya produciendo de modo que
pueda usarse indefinidamente en el tiempo dado el carácter universal de su metodología.
6. MARCO DE REFERENCIA DE LA INVESTIGACION
11
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
6.1. MARCO TEORICO
“La declaraciòn “ los procesos son realizados por personas” es independiente de que apoyen parte
de su labor con tecnologia de variada indole. Hasta ahora, la automatizaciòn total es
practicantemente un mito y es mejor reconocer este simple hecho: los procesos son realizados por
personas” 1
_____________________________
1
Juan Bravo Carrasco. Gestiòn Integral del cambio. Santiago de Chile. Agosto de 2011
Son personas que tienen la inteligencia, el conocimiento, y la experiencia, dedican el tiempo para la
mejora de procesos apoyandose en aplicativos que ayudan a la agilidad del mismo.
En las implementaciones de la gestion de procesos, se ha planteado que las personas son las que
tiene las ideas mas vitales para que un proceso sea el mas apropiado en una organizaciòn
En esta epoca de constantes cambios, pensamos que los cambios traen progreso, y asociamos a la
mejoras a un cambio.
Sin embargo en las organizaciones de tecnologia algunos gestores de T.I. “se rigen por el lema : Si
algo funciona, no lo toques “, y aunque es cierto que al implementar cambios estos traen nuevos
problemas, por ello se deben evaluar las consecuencias, pues podrian traer consecuencias
peligrosas en los servicios y tecnologias de la compañía.
Las principales razones por las cuales se deben realizar cambios de infrestructura y serrvicios T.I.,
es para Desarrollar nuevos Servicios, para solucionar errores conocidos, para mejorar servicios
existentes, o un tipo de obligación legal.
El objetivo principal del proceso de gestión de Cambios es la evaluación y planificación del proceso
para asegurar que al realizarse el cambio este se haga de manera mas eficiente ejecutando los
cambios dentro de los procedimientos establecidos y asegurando que los servicios de T.I. tengan
continuidad.
“La gestion del cambio es un proceso usual en todos los de gestion T.I. e incluso de Gestiòn
empresarial. Normalmente se trata de que los cambios que se van a producir por la puerta en marcha
de nuevas herramientas , elementos o procesos sean aceptados o aprendidos rapidamente por las
personas implicads , evitando posibles problemas y, por lo tanto, restando lo mismo en productividad
a estas y a la orfanizaciòn” 2
12
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
_____________________________
2
http://es.slideshare.net/Biable/manual-itil-integroInformación)
ITIL propone que exista una gestion de cambios con apariencia estrategica, donde todas las
intervenciones que se realizan a nivel operacional se canalicen para asi seguir ofreciendo una
continuidad y calidad en el servicio.
La gestion del cambio es responsable de tramitar el proceso de cambio que incluye, Hardware,
equipo de comunicaciones y software, software del sistema y / o toda la documentaciòn y los
procedimientos asociados con la infraestructura.
Los cambios tambien pueden proceder de diversas fuentes y procesos, pero basicamente por las
causas, ya sean de legalizaciòn, problemas de infraestructura, servicios, procesos, innovaciones, o
nuevos mercados,.
El proceso de cambios tiene una estructura compleja, interrrelacionandose con otros procesos de la
compañía que mantienen el continuo proceso de la organizaciòn.
“ITIL recomienda que esta actuacion se realice y se dispongan de una CMBD o base de datos para
la gestion del cambio , donde se recojan los datos provenientes de la RFC- Peticiones del cambio-
de la que se obtendran para su posterior analisis, evaluaciòn y se planifique un posible cambio” 3
_____________________________
3
13
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
Grafica 1. Proceso de Cambios ITIL
El proceso de Cambios debe asegurar que los cambios que se presentan , esten totalmente
justificados, que se llevan a cabo sin perjudicar los servicios T.I., estan totalmente registrados,
evaluados y aprobados, han sido ejecutados en ambientes de pruebas, estan documentados en la
CMDB, tener Back-Outs (RollBack), en caso de que el cambio genere un funcionamiento incorrecto
en los servicios.
Como lo muestra el siguiente diagrama:
14
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
Grafica 2. Actividades de Gestión de cambios - - RFC - (Seguimiento peticiones de cambio)
15
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
Los beneficios de haber realizado un buen procedimiento para la ejecución de los cambios es que
se reduce el numero de incidentes que se asocian a los mismos, se pueden retomar rapidamente
configuraciones que son estables para los servicios T.I., por si el cambio causa algun impacto
negativo.
La implementación del proceso de cambios tiene ciertas dificultades, como son la aceptación de la
autoridad que tiene la Gestion de Cambios, sobre todo con todo lo que involucra un cambio ,
independientemente si esta resolviendo un problema o mejorar un servicio, ya que no se siguen los
procedimientos, las personas involucradas en el proceso de Gestión de Cambios no tienen las
herramientas adecuadas para hacerle seguimiento a las postimplementación del cambio, tambien se
adoptan procedimientos tan restrictivos que dificultan o pierden importancia a lo que en realidad
pretende mejorar el cambio en cuanto a los servicios T.I.
6.2. MARCO TEORICO
La aplicación que se utiliza para el registro de cambios es Service Manager la cual es provista y
certificada por HP.
7. TIPO DE INVESTIGACION
XXXXXXXXXXXXXXX
8. DISEÑO METODOLOGICO
8.1. METODOLOGIA ITIL
Esta es la metodologia globalmente aceptada para la Gestion de Servicios de Tecnologias de

Inforrmación en el mundo, ya que esta es una recopilación de las mejores preacticas para todos los
sectores economicos.
16
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
Las mejores practicas se dan por experiencias adquiridas con el tiempo en desarrollo de determinada
actividad, y tienen sus respectivos soportes que se basan en esquemas organizacionales complejos,
pero a su vez estan bien definidos y se apoyan en las respectivas herramientas de evaluaciones e
implementaciones.
ITIL como metodología plantea estándares que ayuden en el control, la administración operación de
los recursos propios o de los clientes. Propone realizar estructuraciones de los procesos existentes
si llegan a ser necesarios para el buen manejo de los mismos para llevar a una mejora continua.
También propone que por cada actividad que se realice se debe documentar de la manera más
pertinente, ya que puede ser de gran utilidad para los demás miembros del área, aparte de que
quedan todos los movimientos asentados de lo que se realiza, permitiendo que toda la gente esté
enterada de los cambios realizados a las mismas
17
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
1. OBJETIVO
Establecer un procedimiento que permita gestionar, evaluar y controlar la implementación de los cambios
Normales, Urgencias, Emergencias y Estándar realizados en los diferentes elementos o sistemas que soportan
los servicios de negocio de la compañía.
2. ALCANCE
Este procedimiento aplica para todos los cambios a realizar en las elementos o sistemas de TI.
3. DEFINICIONES
CAC: Comité de Aprobación de Cambios
RFC: Request for change (solicitud de cambios)
Cambio: Es cualquier actividad que altere un elemento de configuración (Adición, modificación o Eliminación).
Incluye la adición o alteración del HW, aplicación, redes, condiciones ambientales, energía y/o cualquier elemento
de infraestructura de los ambientes en producción.
CAB: Comité Asesor del Cambio
Ventana de Mantenimiento: Incluye el tiempo de ejecución de cambio (s) + tiempo de ejecución de pruebas
+ tiempo de ejecución de rollback (si aplica)
RollBack: El plan de reversa del cambio.
Prioridad: Indica la importancia del cambio, es determinada por la evaluación de riesgo impacto.
MR: Matriz de Riesgo, permite medir el impacto del cambio
TI: Tecnología informática
Cambio Aplazado: Cuando el cambio se ha evaluado en el comité de cambios, y se concluye que se debe
ejecutar en otra fecha
Proyecto: Contempla Nuevos Productos, servicios, Evolutivos y adaptativos.
Adaptativo: Son las actividades de desarrollo que responden a peticiones que por su sencillez requieren
fundamentalmente tareas de análisis y programación al no modificar el diseño de la aplicación.
Evolutivo: Son las actividades que responden a peticiones para incorporar una nueva opción al aplicativo ya
existente.
Ventana: Espacio que solicita un usuario para pasar un cambio en un ambiente.
Correctivo: Son las Actividades de solución que tengan como origen un error o fallo originados por el código
del software (Incluye en este servicio la reparación de datos cuando estos sean afectados por errores en el código
del software).
Segregación de Funciones: determinar la acción que el responsable ejecuta en los siguientes escenarios:
E: Ejecutar
A: Aprobar
C: Controlar
I: Informado
CO : Consultado
4. REGLAS
1. El Coordinador de Cambio siempre debe ser un colaborador de Telefónica para asegurar que los cambios
que gestione estén acordes con las políticas, procedimientos, objetivos internos y principios de actuación
de la compañía. Esta función puede ser delegada a otro colaborador de su equipo, mediante el envío de
un correo de aprobación al gestor del cambio por parte del Coordinador de Cambio. Todos los cambios
solicitados por el proveedor, debe ser gestionados y tramitados por el gestor de servicio de operaciones o
líder de aplicación del elemento que se está modificando u optimizando
18
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
2. Los tipos de cambios que se gestionaran son: Cambio Normal, Cambio Estándar, Cambio de Urgencia,
Cambio de Emergencia
3. Si el coordinador del cambio tienen pendientes de cierre de cambios anteriores, no podrá presentar
nuevas solicitudes de cambios al comité.
4. Todos los cambios deben ser aprobados por el Gerente/jefe dueño del cambio.
5. Los cambios normales, urgentes y emergencia que tengan impacto funcional deben ser socializados
antes de registrar el cambio grupo de soporte, incidentes y problemas, de igual forma deberá publicarse
la información de dicha capacitación en la base de conocimiento del Service Manager
6. Los cambios que requieran validaciones de nuevos roles y perfiles o usuarios con altos privilegios,
deben tener validación en Service Manager de la jefatura de seguridad
7. Los cambios de Alto Impacto deben ser programados únicamente los fines de semana
8. Fuera del comité de cambios solo se tramitarán cambios de emergencia, este cambio debe tener como
soporte un incidente masivo o criticidad alta (outage o degradación) del servicio y debe ser relacionado
en la herramienta donde se registra el cambio.
9. El coordinador del cambio deberá involucrar a los usuarios, proveedores, gestores del servicio, lideres
técnico, y lideres de aplicación en la elaboración del plan de trabajo y además deberá levantar toda aquella
información adicional requerida para la ejecución del cambio. (ej: servidores, direcciones IP, bases de
datos, datos de usuario, aplicaciones impactadas.)
10. Toda solicitud de cambios debe incluir la siguientes documentación
 Plan de trabajo detallado ( incluye tareas pos implementación, de ejecución, plan de rollback , pruebas
pos implementación)
 Scrip de mesa (cuando haya indisponibilidad del servicio)
 Certificado de pruebas en ambiente de pruebas
 Check de paso a producción (nuevas aplicaciones)
11. Las tareas reportadas dentro del plan de trabajo detallado, deben ser socializadas a los
implementadores y/o gestores de servicio antes de presentarse al comité de cambios.
12. Cuando se requieran tareas que deben ser ejecutadas por el proveedor esas deben ser comunicadas
y socializadas por el coordinador de cambios(Antes de pasar el cambio al comité)
13. Cuando se requiera cambios en componentes de infraestructura se recomienda al coordinador el check
list de infraestructura, esta es una guía, no se debe incluir en el cambio. Para la implementación de un
cambio, deben haberse cumplido la aprobación de las pruebas correspondientes
14. El coordinador debe definir el tipo de cambio que va a ejecutar dependiendo de las necesidades y o
requerimientos. Para ello primero se debe tener claro que es un cambio
19
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
Cambio:
Es cualquier actividad que altere un elemento de configuración (Adición, modificación o Eliminación).
Incluye la adición o alteración del HW, aplicación, redes, condiciones ambientales, energía y/o cualquier
elemento de infraestructura de los ambientes en producción.
Características:
 Un cambio siempre requiere pruebas de calidad (pruebas de continuidad de la totalidad del
ambiente y/o pruebas de certificación por un área especializada de QA).
 Un cambio puede estar conformado por una o más tareas, las cuales deben tener un orden
definido de ejecución y requieren una coordinación
Los cambios pueden ser:
 Cambio Normal: Son cambios planificados y que se evalúan por el proceso normal de cambios
mediante los comité de cambios normales. El proceso de cambios no aplica para cambios de desarrollo
ni ambientes no productivos
 Cambio de Urgencia: Aquellos eventos identificados sobre la infraestructura o servicio de TI que
son potenciales a crear una interrupción en el servicio, bajo los siguientes criterios y cuya ejecución
no pueda esperar al siguientes comité programado de cambio:
1. Número de usuarios afectados (50% o más de los clientes internos y/o externos)
2. Afectación de sistemas o servicios críticos para la organización y que deban encontrar una
solución en menos de 48 horas
3. Posible Afectación de ingresos
4. Un cambio que contrarresta una acción del mercado
 Cambio de Emergencia: Cambio ejecutado como respuesta a un incidente masivo (Outage,
degradación) que se realiza para restaurar un servicio. Es el único tipo de cambio que podría ser
documentado después de implementado
 Cambio Estándar: Un cambio recurrente, bien conocido, que no implica modificación funcional ni
genera indisponibilidad de la aplicación y/o servicio y para el cual existe un procedimiento predefinido
a seguir, con un riesgo relativamente bajo, ejecutados en ventanas donde el acceso de usuarios sea
menor al 50%. Para este tipo de cambios existe una programación predefinida, y requiere pruebas de
continuidad donde acordado por proceso se realiza su pre aprobado
A. Procedimiento Implementación Cambio Normal
20
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
A-1. Crear el cambio siguiendo el instructivo VTI-IS-01080401 Registro del Cambio Normal y verificar que
no se vaya a ejecutar durante las ventantas registradas en el archivo Cronograma Congelamiento Cambios
TI.xlsx, y para los casos que aplique, en fechas de corte de Facturación
VTI-IS-01080401 Registro del Cambio Normal
A-2. Asegurar que las áreas relacionadas a continuación, conozcan las fechas de ejecución del cambio,
hayan recibido capacitación sobre el mismo y se encuentren preparadas para su operación:
 Usuario final.
 Soporte aplicaciones.
 Operaciones: DBA, SA , Redes, Infraestructura y Equipo de Servicios.
Según lo especificado en el documento Entregas y Despliegues.doc. (en proceso de entrega). En caso de

no encontrar ningún inconveniente con la ejecución del cambio, los representantes de estas áreas deben
enviar un correo al coordinador confirmando la socialización del mismo.
A-3. Una vez se crea el cambio, se debe garantizar que se cumplan los filtros (Filtro1) abajo presentados,
con el fin que sea tenido en comité:
 El cambio debe registrarse según los días establecidos antes de las 14:00
 Cambios que se ejecutan entre 18:00 del día xxxx hasta 17:59 día yyyyy
 El cambio se debe encontrar en la Fase: Aprobación Normal (mover la fase del cambio siguiendo
el instructivo VTI-IS-01080401 Registro del Cambio Normal)
 Plan de trabajo debe estar completo, detallado y asignado a las diferentes torres de operación
(siguiendo el instructivo VTI-IS-01080401 Registro del Cambio Normal)
 Para nivel de afectación, afectación total o perdida de funcionalidad se debe tener aprobación de
usuario final adjunta en SM
 Llevar adjunto un correo con la aprobación del cambio por parte de los Gestores funcionales y/o
Gestores de Torre Midrange SA, Midrange DBA, Gestion de Servicios, Redes e Infraestructura
 Si el cambio impacta alguna aplicación que se encuentre dentro del TOP 10 mensual de
aplicaciones con incidentes asociados, debe tener adjunto un correo con la aprobación del Director
1.
 Tarea de pruebas en ambiente de pruebas cerrada. si no son requeridas las pruebas, crear tarea
y cerrarla con el comentario porque no es requerido.
 Socialización de cambio con el área de Soporte (vi a correo) adjunta a la herramienta SM
 Si aplica Rational el estado debe estar en 330 o 340.
 El coordinador No debe tener cambios pendientes por cerrar
21
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
A-4. Se deben realizar las siguientes verificaciones para determinar si un cambio se tiene en cuenta para
el comité:
 Para los cambios a ejecutarse de lunes a martes, se debe registrar el cambio y tener los puntos
correspondientes al filtro1 a más tardar a las 14:00 del día miércoles de la semana anterior
 Para los cambios a ejecutarse de martes a miércoles, se debe registrar el cambio y tener los
puntos correspondientes al filtro1 a más tardar a las 14:00 del día jueves de la semana anterior
 Para los cambios a ejecutarse de miércoles a jueves, se debe registrar el cambio y tener los puntos
correspondientes al filtro1 a más tardar a las 14:00 del día viernes de la semana anterior
 Para los cambios a ejecutarse de jueves a viernes, se debe registrar el cambio y tener los puntos
correspondientes al filtro1 a más tardar a las 14:00 del día lunes.
 Para los cambios a ejecutarse de viernes a sábado, se debe registrar el cambio y tener los puntos
correspondientes al filtro1 a más tardar a las 14:00 del día martes.
 Para los cambios a ejecutarse de sábado a domingo, se debe registrar el cambio y tener los puntos
correspondientes al filtro1 a más tardar a las 14:00 del día martes.
 Para los cambios a ejecutarse de Domingo a lunes, se debe registrar el cambio y tener los puntos
correspondientes al filtro1 a más tardar a las 14:00 del día miércoles.
 Los cambios que NO cumplan con estos requisitos no se tendrán en cuenta para el comité
A-5. Control Cambios genera de lunes a viernes a las 14:00 el informe consolidado con los cambios que
cumplan con los criterios de filtro 1, este informe se envía a los proveedores (IBM, TERADATA) y a la
Gerencia Operaciones para revisión, validación y asignación de recursos.
A-6. Los jefes de operaciones deben dar el visto bueno por parte de la gerencia de operaciones para la
ejecución de los cambios, esto se realiza autorizando en Service Manager los cambios para que sean
tenidos en cuenta para el comité.
A-7. El Líder Técnico de los proveedores (IBM, TERADATA) revisa las colisiones del cambio con las Service
Line de IBM o TERADATA. Los Service line validan el plan de trabajo, retroalimentan al coordinador de
cambio enviando las observaciones por correo o vía telefónica y asigna los recursos a cada cambio.
El Líder Técnico de los proveedores (IBM, TERADATA), envía a control cambios

(control.cambios.telecom@telefonica.com) el listado de cambios Coordinados y/o observaciones de cada
cambio (máximo a las 10:00 del día anterior a la fecha de socialización del cambio en el comité). En este
informe se entregan los datos de los ejecutores de cada una de las tareas del cambio.
22
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
A-8. El Coordinador del Cambio debe garantizar que se encuentren cerrados los siguientes pendientes
(Filtro 2) a las 10:00 del día anterior al cambio, si esto no es posible el cambio debe cancelarse e iniciar
nuevamente el proceso
 Coordinación de recursos Proveedores (IBM, TERADATA) o áreas internas.

 Retroalimentación con Proveedores (IBM, TERADATA)
 Coordinación recursos
 Tareas validadas y aprobada
 Corrección de las observaciones realizadas por Proveedores (IBM, TERADATA)
 Aprobación Gerencia Operaciones
A-9. Validar que los Cambios tengan la información completa, correctamente diligenciada y cumplan con
el filtro revisado en el punto anterior a más tardar a las 10 de la mañana del día anterior a la ejecución
del cambio.
 Para los cambios a ejecutarse de Lunes a Martes, se deben tener los puntos correspondientes al
filtro 2 a más tardas a las 10:00 del día Viernes de la semana anterior (día hábil anterior a
socialización en comité)
 Para los cambios a ejecutarse de Martes a Miércoles, se deben tener los puntos correspondientes
al filtro2 a mas tardas a las 10:00 del día Lunes (dia hábil anterior a a socialización en comité)
 Para los cambios a ejecutarse de Miércoles a Jueves, se deben tener los puntos correspondientes
al filtro 2 a más tardas a las 10:00 del día Martes (dia hábil anterior a socialización en comité)
 Para los cambios a ejecutarse de Jueves a Viernes, se deben tener los puntos correspondientes al
filtro2 a mas tardas a las 10:00 del día Miércoles (dia hábil anterior a socialización en comité).
 Para los cambios a ejecutarse de Viernes a Sábado, se deben tener los puntos correspondientes
al filtro2 a mas tardas a las 10:00 del día Jueves (día hábil anterior a socialización en comité)
 Para los cambios a ejecutarse de Sábado a Domingo, se deben tener los puntos correspondientes
al filtro2 a mas tardas a las 10:00 del día Jueves (dia hábil anterior a socialización en comité)
 Los cambios que cumplan con este filtro quedarán agendados para revisar en el comité del día
siguiente.
A-10. Generar un Acta con los Cambios que estén correctamente diligenciados y cumplan con el filtro 2,
se consolida acta y se envía a las áreas interesadas a las 16:00 del día anterior a la revisión en comité del
cambio.
23
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
A-11. A las 15:00 se realiza el comité para los cambios a ejecutar a partir de las 18:00 horas y hasta las
17:59 del día siguiente, como se puede ver abajo:
 El comité se realiza en sitio, todos los coordinadores y el comité evaluador deben permanecer en la
sala designada por control cambios hasta el final del comité
 El comité evaluador debe ser un grupo estratégico conformado por jefes de diferentes áreas:
 Un Gerente de la Dirección de Operaciones

 Un Jefe de la Gerencia de Operaciones
 Un Gerente o un Jefe de la Dirección de Desarrollo
 El Jefe de Soporte de Aplicaciones
Otros integrantes del comité son :
 El OnCall de Cambios de Servicios
 El Gestor de Configuración
 Los coordinadores del cambio
 El Jefe de la Jefatura de Proyectos e Incidencia
 El Jefe de Calidad Funcional
 El Jefe de la VMO
 El grupo de control cambios coordina el comité, utilizando el protocolo de actuación que se encuentra
en el archivo Protocolo de actuación comité de cambios.docx
 El jefe/gerente de operaciones es quien realiza las preguntas correspondientes al protocolo según el

archivo Protocolo de actuación comité de cambios.docx.
 Los cambios se socializan según el orden enviado en el acta (primero cambios transversales o de
Redes, luego cambios de Servidores y por último cambios de aplicaciones) y cada coordinador tiene
máximo 5 minutos para socializar su cambio
 Al finalizar el comité, control cambios genera un acta con los cambios a ejecutar ese día.
 Durante el comité se tomarán decisiones respecto si el cambio puede ser ejecutado o no

 Si el coordinador no asiste a la socialización del cambio, este será cancelado.
 El equipo de Control Cambios realiza un llamado a lista a las 15:00 para dar inicio al comité, si no está
presente el coordinador o representante del cambio, el cambio se cancelara. Control Cambios moverá
la Fase del cambio a Prueba de Producción Normal en la Herramienta SM para su respectivo cierre.
24
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
A-12. Una vez finaliza el comité el grupo Control Cambios debe mover la fase del cambio en la herramienta
SM según corresponda: Cambios Aprobados: Implementación de Cambio Normal , Cambios
Aplazados: Aprobación Normal, Cambios Cancelados: Pruebas en Producción Normal esta actividad
se terminara a mas tardas a las 17:00. Control Cambios genera un acta con los cambios que se van a
ejecutar a partir de las 18:00 y hasta las 17:59 del día siguiente como se ve a continuación:
 El lunes a más tardar a las 17:00 Control Cambios envía el acta con los cambios a ejecutarse de
Lunes a las 18:00 hasta el Martes a las 17:59
 El martes a más tardar a las 5:00 pm. Control Cambios envía el acta con los cambios a ejecutarse de
Martes a las 18:00 hasta el Miércoles a las 17:59
 El Miercoles a más tardar a las 17:00 Control Cambios envía el acta con los cambios a ejecutarse de
Miércoles a las 18:00 hasta el Jueves a las 17:59
 El Jueves a más tardar a las 17:00 Control Cambios envía el acta con los cambios a ejecutarse de
Jueves a las 18:00 hasta el Viernes a las 17:59
 El viernes a más tardar a las 17:00 pm. Control Cambios envía el acta con los cambios a ejecutarse
de Viernes a las 18:00 hasta el Lunes a las 17:59
A-13. Coordinar con los Implementadores (recursos proveedores), la ejecución de las tareas de
implementación del cambio, de acuerdo con el cronograma y plan de trabajo establecido. Debe asegurar
que los implementadores actualicen el resultado de la ejecución en SM en la tarea correspondiente del
plan de trabajo.
A-14. El coordinador debe verificar que el plan de trabajo se haya ejecutado correctamente. Debe
coordinar en conjunto con la Gerencia de Pruebas PyS la ejecución de pruebas de funcionalidad y
disponibilidad después de ejecutar el cambio.
Estas pruebas deben estar incluidas como tarea en el plan de trabajo del cambio, y el Coordinador del
Cambio debe asegurar su cierre con las evidencias correspondientes. La certificación de las pruebas pos-
implementación se entrega por correo electrónico y el coordinador de cambio debe cerrar la tarea en SM
adjuntando el correo
A-15. El administrador del Centro de Computo, en caso de no haber recibido cierre exitoso del cambio
debe contactar al coordinador a la hora prevista de ejecución del Rollback y solicitar la ejecución del mismo
mediante el documento Protocolo de solicitud de Rollback.doc
25
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
A-16. Cuando aplique Roll Back, debe coordinar con los Implementadores la realización de tareas de roll
back. Debe realizar pruebas para verificar que el cambio no haya generado ningún impacto. Si se requiere
rollback parcial y no está en el plan de trabajo, debe solicitar la aprobación del Gerente de Operaciones.
Una vez ejecutado el rollback se deben realizar pruebas de disponibilidad y funcionalidad para verificar
que la plataforma afectada quede nuevamente en su estado inicial.
A-17. El coordinador del cambio debe enviar un correo indicando las novedades del cambio a las cuentas:
 control.cambios.telecom@telefonica.com
 AdminCentroComputo.movil.co@telefonica.com
Luego de enviar el correo, debe llamar a la extensión 79344 informando dichas novedades. Un cambio
puede tener las siguientes novedades:
 Aplazamiento: Cuando el cambio fue aprobado en el comité, y por algún incidente no es posible la
instalación del cambio.
 Cancelación: Cuando el cambio fue aprobado en el comité, y por algún motivo el coordinador no
permite la ejecución del mismo o el coordinador no se presentó o llego tarde al comité.
 Finalización Exitosa: Cuando el cambio se implementa y sus pruebas de certificación son exitosas.
 Finalización Rollback: Cuando es necesario ejecutar las tareas de Rollback dentro del cambio
A-18. El administrador del centro de cómputo debe enviar a las 06:00 un correo donde se entrega el acta
con el estado de finalización de los cambios ejecutados durante la noche anterior.
A-19. El administrador del centro de cómputo debe informar en el comité de operaciones con Gonzalo a
las 06:00 el informe del estado de finalización de los cambios ejecutados durante la noche anterior.
A-20. Ejecutado el cambio el Gerente o Jefe dueño del cambio debe certificar que el cambio se realizó
conforme a los establecido y que no hay afectación en operación. Si se realizó rollback en el cambio el
Gerente dueño del cambio deberá certificar que todo quedó como estaba antes del cambio.
Acorde al resultado del cambio, el Gerente dueño del mismo debe realizar la certificación de este resultado.
A-21. El coordinador del cambio debe cerrar el cambio en la herramienta service manager máximo al
siguiente día hábil de su ejecución y debe adjuntarse las evidencias de ejecución
A-22. Actualizar la información de versiones de aplicaciones e infraestructura de acuerdo con los cambios
implementados.
B. Procedimiento Implementación Cambio Urgencia
26
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
B-1. Crear el cambio siguiendo el VTI-IS-01080201 Registro del Cambio de Urgencia y verificar que
no se vaya a ejecutar durante las ventanas registradas en el archivo Cronograma Congelamiento Cambios
TI.xlsx, y para los casos que aplique, en fechas de corte de Facturación
B-2. Una vez se crea el cambio, se debe garantizar que se cumplan los puntos abajo presentados, con el
fin que sea tenido en comité:
 El cambio debe registrarse según los días establecidos antes de las 10:00 ( Verificación del Cambio de
Urgencia)
 Cambios que se ejecutan entre 18:00 del día xxxx hasta 17:59 día yyyyy
 Plan de trabajo debe estar completo, detallado y asignado a las diferentes torres de operación
(siguiendo el VTI-IS-01080201 Registro del Cambio de Urgencia)
 Para nivel de afectación, afectación total o perdida de funcionalidad se debe tener aprobación de
usuario final adjunta en SM
 Validar el acta de cambios normales para ver en el comité de la tarde con el fin de confirmar que no
existan cruces con el cambio planteado.
 Adjuntar en el cambio la aprobación del Jefe/Gerente dueño del área o que el cambio se encuentre
en la fase APROBACIÓN DE CAMBIO NORMAL
 Diligenciar el documento de solicitud de cambio de urgencia y enviar un correo con el formato para
APROBACIÓN DE CAMBIOS DE EMERGENCIA Y URGENCIA a los siguientes correos
admincentrocomputo.movil.co@telefonica.com
control.cambios.telecom@telefonica.com
Cuando el cambio de urgencia es creado sábados, domingos y festivos, una vez se envié el correo con el
formato a Centro de Computo, llamar a la extensión 79344 e indicar que se registró un cambio de urgencia
B-3. Se deben realizar las siguientes verificaciones para determina si un cambio se tiene en cuenta para
el comité:
 Para los cambios de Urgencia a ejecutarse de Lunes a Martes, se debe registrar el cambio y tener los
puntos correspondientes al filtro (Filtro del cambio de Urgencia ) a más tardar a las 10:00 am del día
Lunes
 Para los cambios a ejecutarse de Martes a Miércoles, se debe registrar el cambio y tener los puntos
correspondientes al filtro (Filtro del cambio de Urgencia) a más tardar a las 10:00 am del día Martes
 Para los cambios a ejecutarse de Miércoles a Jueves, se debe registrar el cambio y tener los puntos
correspondientes al filtro (Filtro del cambio de Urgencia) a más tardar a las 10:00 am del día Miércoles
 Para los cambios a ejecutarse de jueves a viernes, se debe registrar el cambio y tener los puntos
correspondientes al filtro (Filtro del cambio de Urgencia) a más tardar a las 10:00 am del día jueves.
27
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
 Para los cambios a ejecutarse de viernes a sábado, se debe registrar el cambio y tener los puntos
correspondientes al filtro (Filtro del cambio de Urgencia) a más tardar a las 10:00 am del día viernes.
Los cambios que NO cumplan con estos requisitos no se tendrán en cuenta para el comité
B-4. Control Cambios genera informe consolidado a las 10:00 con los cambios que cumplan con los
criterios de filtro, este informe se envía a IBM y a la Gerencia Operaciones para revisión, validación y
asignación de recursos.
B-5. El fin de semana y festivos el administrador de Centro de Computo genera un informe consolidado a
las 10:00 tomando los correos con los formatos recibidos antes de dicha hora, este informe se envía al
correo del servicie line proveedores (IBM, TERADATA) y a la Gerencia Operaciones para revisión, validación
y asignación de recursos.
B-6. Control Cambios envía un correo a los proveedores indicando los cambios planificados como urgencia
y que requieren asignación de recursos, así como las torres implicadas para dicha tarea.
B-7. Para la coordinación de cambios el fin de semana y festivos el coordinador del cambio debe solicitar
a IBM la asignación de recursos a los grupos necesarios para la ejecución de actividades del cambio.
B-8. El administrador de Centro de Cómputo se conecta a las extensión 70000, crea el audio 1000 antes
de 11:00 am.
B-9. Asignación de Recursos para cambios de Urgencia Para Sábados, Domingos y Festivos. Se realiza
audio con el Servicie Line de IBM, los Líderes de Torre de IBM y el coordinador del cambio. El servicie Line
solo tendrá en cuenta los cambios relacionados en el informe enviado por centro de computo. Esta
coordinación se debe realizar por la extensión 70000 audio 1000, iniciar a partir de las 11:00 y estar
finalizada a mas tardar a las 12:00
B-10. Para esta actividad Centro de Computo abre audio a las 11:00 y se debe conectar servicie line y
coordinador del cambio.
B-11. Retroalimentación asignación de recursos cambio Urgencia, Una vez coordinado el recurso, el
Servicie Line IBM, envía a control cambios y centro de cómputo el listado de cambios Coordinados y/o
observaciones de cada cambio (máximo a las12:00 del día de socialización del cambio en el comité).
B-12. Generación Acta Comité Cambios de Lunes a Viernes, generar un acta con los Cambios que se van
a ver en el comité pues cumplieron con los filtros de registro, aprobaciones y asignación de recursos a
más tardar a las 14:00 del día de la socialización en comité del cambio.
B-13. Generación Acta Comité Cambios Para Sábados, Domingos y Festivos, Generar un Acta con los
Cambios que se van a ver en el comité pues cumplieron con los filtros de registro, aprobaciones y
asignación de recursos a más tardar a las 14:00 del día de la socialización en comité del cambio. Esta
tarea la realiza Centro de Cómputo.
28
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
B-14. De lunes a viernes el comité de cambios de urgencia se realiza con el comité de cambios normales
a las 15:00, con los cambios a ejecutar a partir de las 18:00 y hasta las 17:59 del día siguiente, Una vez
finaliza el comité el grupo Control Cambios debe mover la fase del cambio en la herramienta SM según
corresponda: Cambios Aprobados: Implementación de Cambio Normal, Cambios Aplazados:
Aprobación Normal, Cambios Cancelados: Pruebas en Producción Normal esta actividad se
terminara a mas tardas a las 17:00
B-15. Los días sábados, domingos y festivos se realizará el comité únicamente si se registraron cambios
de urgencia en esos días. A las 15:00 se realiza el comité para los cambios a ejecutar a partir de las 18:00
y hasta las 17:59 del día siguiente.
B-16. Centro de computo es el encargado de subir a los jefes al comité, y de crear la conferencia 70000
extensión 1000 antes de 15:00
B-17. Una vez finaliza el comité, y a mas tardas a las 17:00 Control Cambios genera un acta con los
cambios que se van a ejecutar a partir de las 18:00 y hasta las 17:59 pm del día siguiente como se ve a
continuación:
 El lunes a más tardar a las 17:00 Control Cambios envía el acta con los cambios a ejecutarse de lunes
a las 18:00 hasta el martes a las 17:59.
 El martes a más tardar a las 17:00 Control Cambios envía el acta con los cambios a ejecutarse de
martes a las 18:00 hasta el miércoles a las 17:59.
 El miércoles a más tardar a las 17:00 Control Cambios envía el acta con los cambios a ejecutarse de
miércoles a las 18:00 hasta el jueves a las 17:59.
 El jueves a más tardar a las 17:00 Control Cambios envía el acta con los cambios a ejecutarse de
jueves a las 18:00 hasta el viernes a las 17:59.
 El viernes a más tardar a las 17:00 Control Cambios envía el acta con los cambios a ejecutarse de
viernes a las 18:00 hasta el lunes a las 17:59.
 El sábado a más tardar a las 17:00 el administrador de centro de cómputo envía el acta con los
cambios a ejecutarse de sábado a las 18:00 hasta el domingo a las 17:59.
 El domingo a más tardar a las 17:00 el administrador de centro de cómputo envía el acta con los
cambios a ejecutarse de domingo a las 18:00 hasta el lunes a las 17:59.
 Los días festivos a más tardar a las 17:00 el administrador de centro de cómputo envía el acta con
los cambios a ejecutarse de ese día a las 18:00 hasta el día siguiente a las 17:59.
B-18. El coordinador de cambio debe coordinar con los Implementadores (proveedores), la ejecución de
las tareas de implementación del cambio, de acuerdo con el cronograma y plan de trabajo establecido.
29
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
Debe asegurar que los implementadores actualicen el resultado de la ejecución en SM en la tarea

correspondiente del plan de trabajo.
B-19. Verificar que el plan de trabajo se haya ejecutado correctamente. Debe coordinar en conjunto con
la Gerencia de Pruebas PyS la ejecución de pruebas de funcionalidad y disponibilidad después de ejecutar
el cambio. Estas pruebas deben estar incluidas como tarea en el plan de trabajo del cambio, y el
Coordinador del Cambio debe asegurar su cierre con las evidencias correspondientes. La certificación de
las pruebas pos- implementación se entrega por correo electrónico y el coordinador de cambio debe
cerrar la tarea en SM adjuntando el correo
B-20. El administrador del Centro de Computo, en caso de no haber recibido cierre exitoso del cambio
debe contactar al coordinador a la hora prevista de ejecución del Rollback y solicitar la ejecución del mismo
mediante el documento Protocolo de solicitud de Rollback.doc
B-21. Cuando aplique Roll Back, debe coordinar con los Implementadores la realización de tareas de roll
back. Debe realizar pruebas para verificar que el cambio no haya generado ningún impacto. Si se requiere
rollback parcial y no está en el plan de trabajo, debe solicitar la aprobación del Gerente de Operaciones.
Una vez ejecutado el rollback se deben realizar pruebas de disponibilidad y funcionalidad para verificar
que la plataforma afectada quede nuevamente en su estado inicial.
B-22. El coordinador del cambio debe enviar un correo indicando las novedades del cambio a las cuentas:
AdminCentroComputo.movil.co@telefonica.com
B-23. Luego de enviar el correo, debe llamar a la extensión 79344 informando dichas novedades. Un
cambio puede tener las siguientes novedades:
 Aplazamiento: Cuando el cambio fue aprobado en el comité, y por algún incidente no es posible
la instalación del cambio.
 Cancelación: Cuando el cambio fue aprobado en el comité, y por algún motivo el coordinador no
permite la ejecución del mismo.
 Finalización Exitosa: Cuando el cambio se implementa y sus pruebas de certificación son exitosas.
 Finalización Rollback: Cuando es necesario ejecutar las tareas de Rollback dentro del cambio.
B-24. El administrador del centro de cómputo debe enviar a las 06:00 un correo donde se entrega el acta
con el estado de finalización de los cambios ejecutados durante la noche anterior.
30
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
B-25. El administrador del centro de cómputo debe informar en el comité de operaciones con Gonzalo a
B-26. Ejecutado el cambio el Gerente o Jefe dueño del cambio debe certificar que el cambio se realizo
conforme a los establecido y que no hay afectación en operación. Si se realizo rollback en el cambio el
Gerente dueño del cambio deberá certificar que todo quedó como estaba antes del cambio. Acorde al
resultado del cambio, el Gerente dueño del mismo debe realizar la certificación de este resultado.
B-27. El coordinador del cambio debe cerrar el cambio en la herramienta Servicie Manager máximo al
B-28. Actualizar la información de versiones de aplicaciones e infraestructura de acuerdo con los cambios
implementados.
C. Procedimiento Implementación Cambio Emergencia
C-1. Crear el cambio siguiendo el VTI-IS-01080201 Registro del Cambio de Emergencia

y verificar que no se vaya a ejecutar durante las ventanas registradas en el archivo Cronograma
Congelamiento Cambios TI.xlsx, y para los casos que aplique, en fechas de corte de Facturación.
C-2. Una vez se crea el cambio, se debe garantizar que se cumplan los puntos abajo presentados,
con el fin que sea tenido en cuenta para audio de Emergencias:
 Plan de trabajo debe estar completo, detallado y asignado a las diferentes torres de operación
(siguiendo el VTI-IS-01080201 Registro del Cambio de Emergencia )
 Para nivel de afectación, afectación total o perdida de funcionalidad se debe tener
aprobación de usuario final adjunta en SM
 Adjuntar en el cambio la aprobación del Jefe/Gerente dueño del área o que el cambio se
encuentre en la fase APROBACIÓN DE CAMBIO NORMAL
 Diligenciar el documento de solicitud de cambio de Emergencia y enviar un correo con el
formato para APROBACIÓN DE CAMBIOS DE EMERGENCIA Y URGENCIA a los siguientes
correos:
 Midrange_SA <Midrange_SA.tc@telefonica.com>;
 Midrange_DBA <Midrange_DBA.tc@telefonica.com>;
 Oscar Jaime Bolivar Gutierrez;
31
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
 Diego German Vanegas Charry;

 Gonzalo Orjuela Pena;
 Rafael Eduardo Barrios Amaya <rafael.barrios@telefonica.com>;
 CONTROL CAMBIOS <control.cambios.telecom@telefonica.com>;
 kdpbaron@co.ibm.com; IBM telefonica (telefoni@co.ibm.com);
 Admin Centro Computo.movil.co AdminCentroComputo.movil.co@telefonica.com;
 Gestion de Servicios e Informacion.movil.co
GestiondeServicioseInformacion.movil.co@telefonica.com
Cuando el cambio de Emergencia es creado sábados, domingos y festivos, una vez se envié el
correo con el formato se validara por la Gestora de Cambios junto con el grupo y Gerente de
Operaciones y se enviara su respectiva aprobación.
C-3. Se deben realizar las siguientes verificaciones para determina si un cambio se tiene en
cuenta para el comité:
 Para los cambios de Emergencia a ejecutarse cualquier día, se debe registrar el cambio y
tener los puntos correspondientes al filtro (Filtro del cambio de Emergencia y Urgencia) en
el momento del audio de socialización del cambio.
 Incidente masivo que esté atendiendo en el momento el área de incidentes ó un PM asociado
que este impactando el negocio.
Los cambios NO se aprobaran para la socialización y respectiva coordinación de tareas hasta no
cumplir con estos requisitos.
C-4. Cuando se envié la aprobación desde el correo de Control cambios como cambio de
Emergencia, se solicitara un audio de urgencia en la línea 70000 bridge 1000, según la hora de
aprobación del cambio, (abre el audio control cambios).
En el audio participan para la socialización del cambio y aprobación del mismo:
 CAB asignado del día

 Coordinador del Cambio
 Gestora de Cambios
Y para la coordinación de las tareas:
 IBM.
32
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
C-5. Centro de computo es el encargado de subir a los jefes al comité.
C-6. El fin de semana y festivos se manejara de la misma manera que entre semana.
C-7. Control Cambios envía un correo a los proveedores indicando los cambios planificados como
Emergencia.
C-8. Una vez finaliza el audio, el grupo Control Cambios debe mover la fase del cambio en la
herramienta SM según corresponda: Cambios Aprobados: Implementación de Cambio
Normal, Cambios Aplazados: Aprobación Normal, Cambios Cancelados: Pruebas en
Producción Normal.
C-9. El coordinador de cambio debe coordinar con los Implementadores (proveedores), la

ejecución de las tareas de implementación del cambio, de acuerdo con el cronograma y plan de
trabajo establecido. Debe asegurar que los implementadores actualicen el resultado de la
ejecución en SM en la tarea correspondiente del plan de trabajo.
C-10. Verificar que el plan de trabajo se haya ejecutado correctamente. Debe coordinar en
conjunto con la Gerencia de Pruebas PyS la ejecución de pruebas de funcionalidad y
disponibilidad después de ejecutar el cambio. Estas pruebas deben estar incluidas como tarea
en el plan de trabajo del cambio, y el Coordinador del Cambio debe asegurar su cierre con las
evidencias correspondientes. La certificación de las pruebas pos- implementación se entrega
por correo electrónico y el coordinador de cambio debe cerrar la tarea en SM adjuntando el
correo
C-11. El administrador del Centro de Computo, en caso de no haber recibido cierre exitoso del
cambio debe contactar al coordinador a la hora prevista de ejecución del Rollback y solicitar la
ejecución del mismo mediante el documento Protocolo de solicitud de Rollback.doc
C-12. Cuando aplique Roll Back, debe coordinar con los Implementadores la realización de tareas
de roll back. Debe realizar pruebas para verificar que el cambio no haya generado ningún
impacto. Si se requiere rollback parcial y no está en el plan de trabajo, debe solicitar la
aprobación del Gerente de Operaciones. Una vez ejecutado el rollback se deben realizar pruebas
de disponibilidad y funcionalidad para verificar que la plataforma afectada quede nuevamente
en su estado inicial.
33
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
C-13. El coordinador del cambio debe enviar un correo indicando las novedades del cambio a las
cuentas:
AdminCentroComputo.movil.co@telefonica.com
C-14. Luego de enviar el correo, debe llamar a la extensión 79344 informando dichas novedades.
Un cambio puede tener las siguientes novedades:
 Aplazamiento: Cuando el cambio fue aprobado en el comité, y por algún incidente no es

posible la instalación del cambio.
 Cancelación: Cuando el cambio fue aprobado en el comité, y por algún motivo el
coordinador no permite la ejecución del mismo.
 Finalización Exitosa: Cuando el cambio se implementa y sus pruebas de certificación son
exitosas.
 Finalización Rollback: Cuando es necesario ejecutar las tareas de Rollback dentro del
cambio.
C-15. El administrador del centro de cómputo debe enviar a las 06:00 un correo donde se entrega
el acta con el estado de finalización de los cambios ejecutados durante la noche anterior.
C-16. El administrador del centro de cómputo debe informar en el comité de operaciones con
Gonzalo a las 06:00 el informe del estado de finalización de los cambios ejecutados durante la
noche anterior.
C-17. Ejecutado el cambio el Gerente o Jefe dueño del cambio debe certificar que el cambio se
realizó conforme a los establecido y que no hay afectación en operación. Si se realizó rollback
en el cambio el Gerente dueño del cambio deberá certificar que todo quedó como estaba antes
del cambio. Acorde al resultado del cambio, el Gerente dueño del mismo debe realizar la
certificación de este resultado.
C-18. El coordinador del cambio debe cerrar el cambio en la herramienta Servicie Manager
máximo al siguiente día hábil de su ejecución y debe adjuntarse las evidencias de ejecución
34
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
C-19. Actualizar la información de versiones de aplicaciones e infraestructura de acuerdo con los

cambios implementados.
D. Procedimiento Implementación Cambio Estándar
D-1. Crear el cambio siguiendo el instructivo registro de cambioEstandar.docx
D-2. Asegurar que las áreas relacionadas a continuación, conozcan las fechas de ejecución del cambio,
hayan recibido capacitación sobre el mismo y se encuentren preparadas para su operación:
 Usuario final.
 Soporte aplicaciones.
 Operaciones: DBA, SA, Redes, Infraestructura y Equipo de Servicios.
D-3. Cuando el coordinador del cambio requiera pasar un cambio normal a cambio estándar, debe solicitar
al comité de cambios su evaluación y aprobación.
Para que un cambio pueda calificarse como estándar, no debe tener afectación del servicio, deberá haber
sido ejecutado como cambio normal, mínimo tres (3) veces con resultado Exitoso, y durante un mínimo
de 2 meses, siempre con las mismas tareas y dentro de lo documentado en la solicitud de cambio, se dará
el calificativo de cambio estándar con una vigencia asociada de un (1) año y se registrara en el formato
“AX-GSI-006 Cambios normales aprobados como Estándar”, el coordinador de cambios enviara la solicitud
para aprobación de cambios normales como estándar, con la documentación solicitada por el comité.
 Plan de Actividades Formato Plan de actividades (Plan de actividades Cambios Estándar.xlsx)

 Extraer los 3 últimos cambios de la herramienta SM (Manual.pdf) Deberá haber sido ejecutado
como cambio normal o estándar, mínimo tres (3) veces con resultado Exitoso, y durante un
mínimo de 2 meses, siempre con las mismas tareas y dentro de lo documentado en la solicitud
de cambio.
El comité de cambios evaluara la solicitud en un plazo máximo de 8 días hábiles.
D-4. Una vez aprobado el cambio, Control Cambios notificara su aprobación como cambio estándar y se
registrara en el formato AX-GSI-006 Cambios normales aprobados como Estándar”
Una vez aprobado el cambio estándar el coordinador debe entregar al grupo de cambios el plan de trabajo
aprobado por el comité donde se definirán entonces esas tareas como la base fija del cambio, así como
sus grupos responsables, Este formato se debe adjuntar siempre en la solicitud de este cambio y solo se
actualizarán fecha y horas de ejecución, ningún otro campo del cambio podrá modificarse, esto incluye:
descripción, justificación, impacto, tareas, duración, rollback. Se ingresará entonces a la hoja de cambios
estándar oficial. Si algún campo se modificara perderá su condición de estándar.
35
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
D-5. El coordinador del cambio debe registrar el cambio en la herramienta correspondiente como un
cambio estándar, anexando la documentación requerida para ser aprobado posteriormente por el
Gerente o Jefe dueño del cambio.
Los cambios estándar deben ser registrados el día de la ejecución del cambio antes de las 14:00 entre
semana, para los fines de semana y festivos deben ser registrados el viernes antes de la 14:00, sin
necesidad de ser evaluados para cada ejecución por el comité.
D-6. El coordinador del cambio debe solicitar a IBM la asignación de recursos antes de las 14:00 horas
del día anterior a la ejecución del cambio informando los grupos necesarios para la ejecución de
actividades del cambio.
Todos los cambios deben tener:
Pruebas en ambiente de pruebas
Plan de trabajo detallado
Evidencias de ejecución del cambio
El plan de reversa del mismo (Rollback)
Pruebas post-implementación
D-7. Una vez enviada la solicitud de recursos, IBM enviara la notificación de los recursos antes de las
10:00 del día de la ejecución del cambio. Cuando el implementador del cambio encuentre diferencias en
los planes de trabajo entrega vs los planes aprobados, deberá informar al coordinador del cambio y a
Gestión de Cambios, y no deberá ejecutar el cambio.
El Servicie Line IBM, envía a control cambios el listado de cambios Coordinados y/o observaciones de
cada cambio
D-8. Cuando un cambio estándar llegara a salirse del proceso establecido y/o a generar algún incidente
perderá su clasificación de estándar, y deberá gestionarse nuevamente como cambio normal. El cierre
del cambio debe realizarse al finalizar la ejecución del mismo. Todos los cambios Estándar deben ser
aprobados por el Gerente o Jefe dueño del cambio para poder ser ejecutados
D-9. A las 15:00 se realiza el comité para los cambios a ejecutar a partir de las 18:00 horas y hasta las
17:59 del día siguiente. Al terminal el comité se enviara acta con los cambios aprobados en el comité
incluyendo los cambios Estándar registrados para este día.
D-10. El coordinador del cambio debe enviar un correo indicando las novedades del cambio a las
cuentas:
36
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
 AdminCentroComputo.movil.co@telefonica.com
 control.cambios.telecom@telefonica.com
Luego de enviar el correo, debe llamar a la extensión 79344 informando dichas novedades. Un cambio
puede tener las siguientes novedades:
 Aplazamiento: Cuando el cambio fue aprobado en el comité, y por algún incidente no es posible
la instalación del cambio.
 Cancelación: Cuando el cambio fue aprobado en el comité, y por algún motivo el coordinador
no permite la ejecución del mismo.
 Finalización Exitosa: Cuando el cambio se implementa y sus pruebas de certificación son
exitosas.
 Finalización Rollback: Cuando es necesario ejecutar las tareas de Rollback dentro del cambio.
D-11. El administrador del centro de cómputo debe enviar a las 06:00 un correo donde se entrega el
acta con el estado de finalización de los cambios ejecutados durante la noche anterior.
D-12. El administrador del centro de cómputo debe informar en el comité de operaciones con Gonzalo a
D-13. Ejecutado el cambio el Gerente o Jefe dueño del cambio debe certificar que el cambio se realizo
conforme a lo establecido y que no hay afectación en operación. Si se realizo rollback en el cambio el
Gerente dueño del cambio deberá certificar que todo quedó como estaba antes del cambio. Acorde al
resultado del cambio, el Gerente dueño del mismo debe realizar la certificación de este resultado.
D-14. El coordinador del cambio debe cerrar el cambio en la herramienta Service Manager máximo al
E. Procedimiento Ingreso por Excepción
E-1. Crear el cambio siguiendo el instructivo VTI-IS-01080401 Registro del Cambio Normal
y verificar que no se vaya a ejecutar durante las ventantas registradas en el archivo Cronograma
Congelamiento Cambios TI.xlsx, y para los casos que aplique, en fechas de corte de Facturación
E-2. El coordinador envía el formato de solicitud de Ingreso de cambio como excepción

totalmente diligenciado (FORMATO DE APROBACION DE EXCEPCIONES.XLS).Los cambios de
Excepción son aprobados por Control Cambios (Gestora de Cambios) dando el visto bueno del
ingreso del mismo.
37
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
E-3. Asegurar que las áreas relacionadas a continuación, conozcan las fechas de ejecución del
cambio y el motivo por el cual solicitan el ingreso (anexando el formato de solicitud):
 Oscar Jaime Bolivar Gutierrez

 Rafael Eduardo Barrios Amaya <rafael.barrios@telefonica.com>
 CONTROL CAMBIOS <control.cambios.telecom@telefonica.com>
 Gestion de Servicios e Informacion.movil.co
GestiondeServicioseInformacion.movil.co@telefonica.com
 Usuario final.
 Soporte aplicaciones.
 Operaciones: DBA, SA , Redes, Infraestructura y Equipo de Servicios.
E-4. Una vez se crea el cambio, se debe garantizar que se cumpla el Procedimiento
Implementación Cambio Normal. y para presentarse como excepción debe también cumplir
con el punto abajo presentado, con el fin que sea tenido en cuenta para el ingreso en el acta
correspondiente:
 Debe tener un PM asociado y debe tener un impacto en el negocio.
E-5. Una vez aprobado el cambio como ingreso de Excepción, el cual aprueba la Gestora de
Cambios junto con el grupo y Gerente de Operaciones, Control Cambios enviara una actualización
al informe consolidado que se generó de lunes a viernes a las 14:00, con los cambios que
cumplieron con los criterios de filtro 1, este informe se envía a los proveedores (IBM, TERADATA)
y a la Gerencia Operaciones para revisión, validación y asignación de recursos.
E-6. Se seguirá manejando el mismo proceso de Cambios normales desde el punto A-6, hasta el
final. Ver Procedimiento Implementación Cambio Normal.
5. ENTRADAS
No. DESCRIPCIÓN RESPONSABLE

Cambio creado para ser validado por el grupo de gestión de Coordinador de cambio
cambio, con la siguiente documentación anexa:
1.
1. Plan de trabajo detallado
2. Evaluación de riesgo e impacto
38
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
3. Script de mesa
4. Certificado de pruebas en ambiente de pruebas
5. Check de paso a producción (nuevas aplicaciones)
2. Aprobación de Gerente/jefe dueño del cambio Coordinador de cambio
Solicitud de aprobación de las áreas de seguridad, soporte, Coordinador de cambio
3.
operaciones
6. PROCEDIMIENTO
No. DESCRIPCIÓN REGISTRO RESPONSABLE E A C I C

Electrónic O
o / físico
Validar la calidad de la información registrada en la
herramienta y la completitud de la información anexa
al mismo
Registro
Descripción del cambio
Validar el registro de los recursos en cada tarea
Validar aprobaciones de acuerdo a cada tipo de
cambio normal o urgencia por cada tipo de cambio en
la herramienta
Documentación anexa
Servicie Gestor/Analista de
1. X
Manager Gestión de Cambios
*Plan de trabajo detallado: validar finalización
prevista de cambio, tiempos de ejecución de cambio,
tiempo de pruebas, tiempos de rollback
* Validar que información de la matriz Evaluación de
riesgos e impacto, sea coherente con la información
registrada en la herramienta.
* Script de mesa ( aplica para los cambios que crean
indisponibilidad )
* Certificado de pruebas en ambiente de pruebas
* Control de versiones para cambios de aplicación
* Check de paso a producción (nuevas aplicaciones)
Generar y comunicar agenda de comité y lista de
Correo Gestor/Analista de
2. cambios a presentar como mínimo con 2 horas de X
electrónico Gestión de Cambios
anticipación
Presentar y/o socializar los cambios al representante Coordinador del
3. X
del área en comité de cambios cambios
Comité de cambios evalúa riesgo, impacto y Service
4. Comité de cambios X
prioridad Manager
Service
Generar y comunicar acta de aprobación de comité
Manager/co Gestor/Analista de
5. de cambios, para los cambios de urgencia no se tiene X
rreo Gestión de Cambios
acta se notificará por correo electrónico
electrónico
39
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
Correo
Coordinar la ejecución de los cambios, validando que las electrónico/ Coordinador de
6. X
partes involucradas estén listas para ejecutar el cambio vía cambio
telefónica
Correo
electrónico/
7. Ejecutar cambio Ejecutor del cambio X
vía
telefónica
Ejecutor de
Realizar pruebas de validación de funcionalidad y Evidencia
cambio/Calidad
8. disponibilidad en Servicie X
funcional/ Soporte
Manager
Aplicaciones y LT
Si las pruebas de funcionalidad y disponibilidad son
exitosas el responsable del calidad funcional generar
notificara el resultado de las pruebas por correo
electrónico a los involucrados en el cambio y
Correo Calidad funcional –
9. notificara el resultado al equipo de cambios a través X
electrónico Líder técnico
de correo electrónico adjuntando el resultado de las
pruebas
Si las pruebas no fueron exitosas se deberá aplicar

Ejecutor de
Rollback, para que la plataforma afectada quede Correo
10. cambio/Coordinador X
nuevamente en su estado inicial electrónico
del cambio
Comunicar el estado de finalización del cambio a los Correo Coordinador del
11. X
involucrados electrónico cambio
Certificar el cambio – monitoreo del cambio pos Services Gerente/jefe dueño
12. X
implementación manager del cambio
Services Coordinador del
13. Realizar la actualización de la CMDB X
manager cambio
Realizar el cierre de cambio en la herramienta,
adjuntando:
 logs de ejecución estos debe tener fecha y hora
de la ejecución de las pruebas
Services Coordinador del
14.  Evidencia de pruebas de funcionalidad y x
manager cambio
disponibilidad
 Evidencia de monitoreo post implementación del
cambio
Generar planificador y reporte de diario de resultado Correo

15. Centro de computo X
de cambios electrónico
7. SALIDAS
No. DESCRIPCIÓN RESPONSABLE
40
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
1. Actas de cambios Gestor/Analista de cambios

2. Cierre del cambio en la herramienta Coordinador de cambios
3. Cambio implementado Coordinador de cambios
2. planificador y reporte de diario de resultado de cambios Comité de Cambios
8. SOPORTE TECNOLÓGICO RESPONSABLES
Service Manager Administrador de Servicie

1.
Manager
2. Correo electrónico Gestor de Cambios
9. POSIBLES FALLAS (RIESGOS POR TRANSACCIÓN)
No. FALLA ACCIÓN RESPON

SABLE
No se presenta la documentación completa Rechazar la solicitud de cambio Comité
1. para el registro del cambio De
Cambio
Cambio no aprobado por el Gerente o jefe Cerrar el cambio como cancelado y documentar Coordinad
2. dueño del cambio or del
Cambio
El cambio no fue aprobado por el comité de Cerrar el cambio como rechazado y gestionar Coordinad
cambios nueva solicitud or del
3.
cambio
Si el cambio es aplazado por el comité de Ajustar cambio y volver a realizar solicitud. Coordinad
cambios. Si se debe realizar actividades no planeadas or de
4.
solicitar aprobación al Gerente de operaciones Cambio
Detección fuera de servicio (cambio sin Activación plan de Rollback Coordinad

afectación) or de
5.
Cambio
Cambio no exitoso Realizar Rollback y volver a tramitar la Coordinad

solicitud de cambio or del
6.
Cambio
10. CONTROLES
RIESGO ASOCIADO Evaluación del proceso después de la ejecución del

1.
cambio
COMO SE CONTROLA Ejecutar las pruebas funcionalidad y disponibilidad
requeridas para garantizar que el cambio cumple con
requerimiento del usuario
FRECUENCIA Cada vez que se ejecute un cambio
41
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
CRITERIO DE ACEPTACIÓN El cambio cumple con el requerimiento del usuario y su

funcionalidad no afecto otras servicios
ACCIONES A TOMAR Realizar rollback
EVIDENCIA Adjuntar pruebas de las validaciones realizadas
RESPONSABLES Ejecutor del cambio
RIESGO ASOCIADO Evaluación del proceso después de la ejecución del
2.
cambio
COMO SE CONTROLA Ejecutar las pruebas disponibilidad pos implementación
requeridas para garantizar que la continua normal
FRECUENCIA Cada vez que se ejecute un cambio
CRITERIO DE ACEPTACIÓN El cambio cumple no afecto la disponibilidad de los
sistemas
ACCIONES A TOMAR Realizar rollback
EVIDENCIA Adjuntar pruebas de las validaciones realizadas
RESPONSABLES Ejecutor del cambio
RIESGO ASOCIADO Cierre del cambio con resultado errado o
3.
documentación incompleta
COMO SE CONTROLA Validación del cierre del cambio con la documentación
completa
FRECUENCIA Diaria
CRITERIO DE ACEPTACIÓN Cambio cerrado con la topología correcta y documentación
completa
ACCIONES A TOMAR Solicitar el cierre correcto del cambio al coordinador del
cambio
EVIDENCIA Correo electrónico/ herramienta SM
RESPONSABLES Gestor De Cambios
11. FORMATOS / REPORTES

1. Acta de comité de cambios
2. Plan de trabajo
3. Matriz de protocolo de pruebas de disponibilidad – pos-implementación
12. CONTROL DE VERSIONES
No. Fecha Cambio /Modificación Aprobado por Validado Por
1. 06/02/2012 Versión inicial del proceso Alejandro Figueroa Ligia Solano
convergente Yanneth Riveros
2. 14/07/12 Se incluyeron política de BI, de Alejandro Figueroa Ligia Solano
arquitectura y propias de cambios Jean Luis Torrado Nubia Sabogal
Elcy Robisson Leivy Orjuela
3. 12/08/2013 Incluir nuevas políticas de tiempos, Alejandro Figueroa Nubia Sabogal
días del comité y comunicación Oscar Bolivar Paola Alzate
Jean Luis Torrado Leivy Orjuela
Procesos:
Manuel Betancourt
42
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
4. 01/07/2014 Modificación proceso, nuevas Oscar Bolivar Gina Maria Herrera

políticas. Adriana Rasch Claudia Mylena
Suàrez
13.METRICAS
Indicador de proceso Nombre del indicador Descripción de
Indicador
(que busca medir)
Ver cuadro de mando
Cómo se mide (Formulación) Frecuencia de seguimiento Meta (target)
Fuente:
Responsable:
1. Formato procesos internos Telefonica
9. FUENTES PRIMARIAS
A medida que se realizaba la gestion de Cambios en Telefonica, se fueron evaluando las deficiencias
que este tenia, y el bajo control que se tenia del mismo.
El proceso de cambios en la Organización es muy importante, pues se requiere llevar un control del
mismo para bajar los incidentes relacionados a la ejecución de los cambios.
Las metricas mostraban el poca revision, evaluación e investigación que se le realizaba a los cambios
y por ello, se planeo reestructurar el proceso para que asi se le realizara el seguimiento respectivo a
la Gestión de Cambios.
43
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
10. RECURSOS
Nombres y Función básica dentro del

N° Profesión Básica
Apellidos Proyecto
1 Gina Herrera Profesional Operaciones T.I. Jefe de Proyecto
2 Claudia Suárez Gestora de Cambios Jefe de Proceso
11. CRONOGRAMA
12. GRUPO PROCESO DE CAMBIOS
44
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
13. CONCLUSIONES
De los obstáculos más difíciles al implementar el proceso dentro de la Organización, es el salto al

proceso, ya que en algunas ocasiones hay cambios demasiado importantes que tiene el negocio, y
no cumplen con el control de cambios, ya que se debe ejecutar en caliente para así seguir con la
operación sin afectación, teniendo estos la aprobación de los Directores T.I.
Por ello se le realiza seguimiento constante al proceso, teniendo reuniones con la Gerencia de
Operaciones, detectando como se podrían manejar este tipo de cambios sin que afecten la métrica
del proceso, y sin ser un obstáculo para la compañía en cuanto a agilidad de cambios se trate.
14. REFERENCIAS (BIBLIOGRAFIA)
Fundamentos de la GestionT.I.
45
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/fundamentos_de_la_gestion_TI/que_es_ITIL/q
ue_es_ITIL.php
Gestión de Cambios
http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_cambios/vision_general_gestion_d
e_cambios/vision_general_gestion_de_cambios.php
El Proceso de Gestion de Cambios según el enfoque ITIL

http://www.pmi-mad.org/index.php?option=com_content&view=article&id=547:el-proceso-de-
gestion-de-cambios-segun-el-enfoque-de-itil-&catid=137:articulos&Itemid=88
Gestiòn Integral del Cambio

Juan Bravo Carrasco. Gestiòn Integral del cambio. Santiago de Chile. Agosto de 2011
Manual ITIL V3
Gestiòn de Cambios T.I. y evaluaciòn de proyectos y servicios

http://libertad3punto0.wordpress.com
Foundations of IT Service Management based on ITIL V3 (Spanish Version)

Volumen 3, Best practice, ITSM Library, Jan Van Bon, Arjen de Jong, Axel Kolthof, ilustrada, Bernan
Assoc, 2008
46
Proceso:
Investigación e
10-05-2014 16-03-2014
Implementación
47

Ejemplo: Documento Gestion de Cambios

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ejemplo: Documento Gestion de Cambios

Caricato da

Copyright:

Formati disponibili

IMPLEMENTACION NUEVO PROCESO Código: CC-001

GESTION DE CAMBIOS Versión:01

IMPLEMENTACION NUEVO PROCESO DE CAMBIOS

CLAUDIA MYLENA SUAREZ VELASQUEZ

MONOGRAFIA PRESENTADA PARA OPTAR POR EL TITULO DE INGENIERA

ESCUELA COLOMBIANA DE CARRERAS INDUSTRIALES

IMPLEMENTACION NUEVO PROCESO DE CAMBIOS

CLAUDIA MYLENA SUAREZ VELASQUEZ

ING. JAIRO PALACIOS

ESCUELA COLOMBIANA DE CARRERAS INDUSTRIALES

Firma del Presidente del Jurado

Firma del Jurado

Firma del Jurado

Bogotá D.C, Agosto 2014

Tabla de Contenido Pág.

Grafica 1. Proceso de Cambios ITIL 12

Grafica 2. Actividades de Gestión de Cambios 13

1. Formato Proceso Interno Telefónica 42

El siguiente documento es una presentación de la implementación del nuevo proceso de Cambios

2. NUEVO PROCESO GESTIÓN CAMBIOS

3.1. DESCRIPCION DEL PROBLEMA

3.2. FORMULACION DEL PROBLEMA

4.1. OBJETIVO GENERAL

Implementar el nuevo proceso de Gestión de Cambios, teniendo en cuenta las Tecnologias de la

4.2. OBJETIVOS ESPECIFICOS

5. JUSTIFICACION Y DELIMITACION DE LA INVESTIGACION

Posteriormente en el termino de 4 meses, una vez ya estabilizadas las reglas de la presentación de

En este proyecto principalmente vamos a tartar exclusivamente el cumplimiento de ciertas reglas

6. MARCO DE REFERENCIA DE LA INVESTIGACION

6.1. MARCO TEORICO

Grafica 1. Proceso de Cambios ITIL

Como lo muestra el siguiente diagrama:

Grafica 2. Actividades de Gestión de cambios - - RFC - (Seguimiento peticiones de cambio)

6.2. MARCO TEORICO

8.1. METODOLOGIA ITIL

Esta es la metodologia globalmente aceptada para la Gestion de Servicios de Tecnologias de

Los cambios pueden ser:

A. Procedimiento Implementación Cambio Normal

Según lo especificado en el documento Entregas y Despliegues.doc. (en proceso de entrega). En caso de

El Líder Técnico de los proveedores (IBM, TERADATA), envía a control cambios

 Coordinación de recursos Proveedores (IBM, TERADATA) o áreas internas.

 Un Gerente de la Dirección de Operaciones

 Un Gerente o un Jefe de la Dirección de Desarrollo

 El Jefe de Soporte de Aplicaciones

Otros integrantes del comité son :

 El OnCall de Cambios de Servicios

 Los coordinadores del cambio

 El Jefe de la Jefatura de Proyectos e Incidencia

 El Jefe de Calidad Funcional

 El jefe/gerente de operaciones es quien realiza las preguntas correspondientes al protocolo según el

 Durante el comité se tomarán decisiones respecto si el cambio puede ser ejecutado o no

B. Procedimiento Implementación Cambio Urgencia

Debe asegurar que los implementadores actualicen el resultado de la ejecución en SM en la tarea

C. Procedimiento Implementación Cambio Emergencia

C-1. Crear el cambio siguiendo el VTI-IS-01080201 Registro del Cambio de Emergencia

 Diego German Vanegas Charry;

En el audio participan para la socialización del cambio y aprobación del mismo:

 CAB asignado del día

Y para la coordinación de las tareas:

C-5. Centro de computo es el encargado de subir a los jefes al comité.

C-9. El coordinador de cambio debe coordinar con los Implementadores (proveedores), la

 Aplazamiento: Cuando el cambio fue aprobado en el comité, y por algún incidente no es

C-19. Actualizar la información de versiones de aplicaciones e infraestructura de acuerdo con los

D. Procedimiento Implementación Cambio Estándar