• Author / Uploaded
• KoLach0 NiKoLach0

Citation preview

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

Nota de Aceptación ___________________________ ___________________________ ___________________________ ___________________________ ___________________________

___________________________ Firma del Presidente del Jurado

___________________________ Firma del Jurado

___________________________ Firma del Jurado

Bogotá D.C, Agosto 2014

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

LISTA DE GRAFICAS

Pág. Grafica 1. Proceso de Cambios ITIL

12

Grafica 2. Actividades de Gestión de Cambios

13

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

LISTA DE FORMATOS

Pág. 1. Formato Proceso Interno Telefónica

42

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

5.2.

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

6.1.

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

_____________________________ 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 cambiode la que se obtendran para su posterior analisis, evaluaciòn y se planifique un posible cambio” 3 _____________________________ 3

http://es.slideshare.net/Biable/manual-itil-integroInformación)

13

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

15

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

([email protected]) 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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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 posimplementació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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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: 

[email protected]



[email protected]

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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 [email protected]

[email protected] 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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación



Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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: [email protected] [email protected] 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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

B-25. 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. 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 siguiente día hábil de su ejecución y debe adjuntarse las evidencias de ejecución 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_DBA ; 

Oscar Jaime Bolivar Gutierrez;

31

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

  

Diego German Vanegas Charry; Gonzalo Orjuela Pena; Rafael Eduardo Barrios Amaya ;

   

CONTROL CAMBIOS ; [email protected]; IBM telefonica ([email protected]); Admin Centro Computo.movil.co [email protected]; Gestion de Servicios e Informacion.movil.co [email protected]

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

C-13. El coordinador del cambio debe enviar un correo indicando las novedades del cambio a las cuentas: [email protected] [email protected] 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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación



[email protected]



[email protected]

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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 las 06:00 el informe del estado de finalización de los cambios ejecutados durante la noche anterior. 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 siguiente día hábil de su ejecución y debe adjuntarse las evidencias de ejecución

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

  

CONTROL CAMBIOS Gestion de Servicios e Informacion.movil.co [email protected] 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. 1.

DESCRIPCIÓN Cambio creado para ser validado por el grupo de gestión de cambio, con la siguiente documentación anexa: 1. 2.

RESPONSABLE Coordinador de cambio

Plan de trabajo detallado Evaluación de riesgo e impacto

38

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

2. 3.

No.

Fecha de emisión: 10-05-2014

3. Script de mesa 4. Certificado de pruebas en ambiente de pruebas 5. Check de paso a producción (nuevas aplicaciones) Aprobación de Gerente/jefe dueño del cambio Solicitud de aprobación de las áreas de seguridad, soporte, operaciones 6. PROCEDIMIENTO DESCRIPCIÓN

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

Coordinador de cambio Coordinador de cambio

REGISTRO Electrónic o / físico

RESPONSABLE

E

Servicie Manager

Gestor/Analista de Gestión de Cambios

X

Correo electrónico

Gestor/Analista de Gestión de Cambios

X

Coordinador del cambios

X

A C I C O

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 1.

2. 3. 4.

5.

Documentación anexa *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 cambios a presentar como mínimo con 2 horas de anticipación Presentar y/o socializar los cambios al representante del área en comité de cambios Comité de cambios evalúa riesgo, impacto y prioridad Generar y comunicar acta de aprobación de comité de cambios, para los cambios de urgencia no se tiene acta se notificará por correo electrónico

Service Manager Service Manager/co rreo electrónico

Comité de cambios Gestor/Analista de Gestión de Cambios

X

X

39

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

6.

Coordinar la ejecución de los cambios, validando que las partes involucradas estén listas para ejecutar el cambio

7.

Ejecutar cambio

8.

Realizar pruebas de validación de funcionalidad y disponibilidad

9.

10. 11. 12. 13.

14.

15.

No.

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 notificara el resultado al equipo de cambios a través de correo electrónico adjuntando el resultado de las pruebas Si las pruebas no fueron exitosas se deberá aplicar Rollback, para que la plataforma afectada quede nuevamente en su estado inicial Comunicar el estado de finalización del cambio a los involucrados Certificar el cambio – monitoreo del cambio pos implementación Realizar la actualización de la CMDB 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  Evidencia de pruebas de funcionalidad y disponibilidad  Evidencia de monitoreo post implementación del cambio Generar planificador y reporte de diario de resultado de cambios 7. SALIDAS DESCRIPCIÓN

Fecha de emisión: 10-05-2014

Correo electrónico/ vía telefónica Correo electrónico/ vía telefónica

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

Coordinador de cambio

X

Ejecutor del cambio

X

Evidencia en Servicie Manager

Ejecutor de cambio/Calidad funcional/ Soporte Aplicaciones y LT

X

Correo electrónico

Calidad funcional – Líder técnico

X

Correo electrónico

Ejecutor de cambio/Coordinador del cambio

Correo electrónico Services manager Services manager

Coordinador del cambio Gerente/jefe dueño del cambio Coordinador del cambio

Services manager

Coordinador del cambio

x

Correo electrónico

Centro de computo

X

X X X X

RESPONSABLE

40

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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 1. 2.

No. 1. 2.

3.

4.

5.

RESPONSABLES

Service Manager

Administrador de Servicie Manager Correo electrónico Gestor de Cambios 9. POSIBLES FALLAS (RIESGOS POR TRANSACCIÓN) FALLA

ACCIÓN

RESPON SABLE No se presenta la documentación completa Rechazar la solicitud de cambio Comité para el registro del cambio De Cambio Cambio no aprobado por el Gerente o jefe Cerrar el cambio como cancelado y documentar Coordinad 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 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 solicitar aprobación al Gerente de operaciones Cambio

Detección fuera de servicio (cambio sin Activación plan de Rollback afectación) Cambio no exitoso

6.

Realizar Rollback y solicitud de cambio

volver a tramitar

Coordinad or de Cambio la Coordinad or del Cambio

10. CONTROLES 1.

RIESGO ASOCIADO COMO SE CONTROLA FRECUENCIA

Evaluación del proceso después de la ejecución del cambio Ejecutar las pruebas funcionalidad y disponibilidad requeridas para garantizar que el cambio cumple con requerimiento del usuario Cada vez que se ejecute un cambio

41

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

CRITERIO DE ACEPTACIÓN

2.

ACCIONES A TOMAR EVIDENCIA RESPONSABLES RIESGO ASOCIADO COMO SE CONTROLA FRECUENCIA CRITERIO DE ACEPTACIÓN

3.

ACCIONES A TOMAR EVIDENCIA RESPONSABLES RIESGO ASOCIADO COMO SE CONTROLA FRECUENCIA CRITERIO DE ACEPTACIÓN ACCIONES A TOMAR EVIDENCIA RESPONSABLES

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

El cambio cumple con el requerimiento del usuario y su funcionalidad no afecto otras servicios Realizar rollback Adjuntar pruebas de las validaciones realizadas Ejecutor del cambio Evaluación del proceso después de la ejecución del cambio Ejecutar las pruebas disponibilidad pos implementación requeridas para garantizar que la continua normal Cada vez que se ejecute un cambio El cambio cumple no afecto la disponibilidad de los sistemas Realizar rollback Adjuntar pruebas de las validaciones realizadas Ejecutor del cambio Cierre del cambio con resultado errado o documentación incompleta Validación del cierre del cambio con la documentación completa Diaria Cambio cerrado con la topología correcta y documentación completa Solicitar el cierre correcto del cambio al coordinador del cambio Correo electrónico/ herramienta SM 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 1. 06/02/2012 Versión inicial del proceso Alejandro Figueroa convergente 2. 14/07/12 Se incluyeron política de BI, de Alejandro Figueroa arquitectura y propias de cambios Jean Luis Torrado Elcy Robisson 3. 12/08/2013 Incluir nuevas políticas de tiempos, Alejandro Figueroa días del comité y comunicación Oscar Bolivar Jean Luis Torrado

Validado Por Ligia Solano Yanneth Riveros Ligia Solano Nubia Sabogal Leivy Orjuela Nubia Sabogal Paola Alzate Leivy Orjuela Procesos: Manuel Betancourt

42

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

4.

01/07/2014

Modificación proceso, nuevas políticas.

Fecha de emisión: 10-05-2014

Oscar Bolivar Adriana Rasch

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

Gina Maria Herrera 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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

10. RECURSOS

N° 1 2

Nombres y Apellidos Gina Herrera Claudia Suárez

Profesión Básica Profesional Operaciones T.I. Gestora de Cambios

Función básica dentro del Proyecto Jefe de Proyecto Jefe de Proceso

11. CRONOGRAMA

12. GRUPO PROCESO DE CAMBIOS

44

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

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-degestion-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 http://es.slideshare.net/Biable/manual-itil-integroInformación)

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

IMPLEMENTACION NUEVO PROCESO GESTION DE CAMBIOS Proceso: Investigación e Implementación

Fecha de emisión: 10-05-2014

Código: CC-001 Versión:01 Fecha de versión: 16-03-2014

47