Este documento presenta el proceso de administración de cambios de una empresa. Describe los objetivos y alcance del proceso, los tipos de cambios, prioridades y roles involucrados. Explica el flujo para la creación de solicitudes de cambio, su aprobación, ejecución y cierre. También cubre los controles para garantizar que los cambios se gestionen de manera adecuada y se minimicen los riesgos e impactos en los servicios.
2. Contenido
• Objetivo y alcance de proceso
• Algunos Conceptos Claves
• Tipo de cambios
• Tipos de Prioridad
• Política Administración de Cambios
• Roles del proceso
• Objetivos de los controles CM
• Diagrama de bloques Administración de Cambios
• Flujo de Desarrollo
• CM.2/CM3. Aprobación de los Cambios
• Cambios de emergencia – CM4
3. Objetivo y Alcance
Objetivo:
Asegurar que todos los cambios en la infraestructura TIC sean
gestionados, con el fin de minimizar el impacto en los servicios de los
clientes internos y externos.
Alcance:
El procedimiento contempla toda modificación efectuada sobre
elementos físicos y lógicos como redes, sistemas de información,
software, plataformas, servidores, enrutadores que son utilizados para
proveer y soportar los servicios ofrecidos en la propuesta de valor a los
clientes y que son administrados por la VP de Operaciones, en el
desarrollo de las actividades habituales de la operación de Tigo Colombia.
Inicia con una solicitud para poner un cambio en producción y termina con
la documentación de los resultados del mismo.
4. La Prioridad de un cambio permite identificar la importancia relativa del mismo y establecer los plazos requeridos
para su implementación. Las prioridades definidas en el proceso son: normal, media, extraordinaria y emergencia.
Algunos Conceptos Claves
Tipo: Lo define el riesgo y el impacto y se clasifican en: Estándar, emergencia y normal (menor, significativo y mayor
Origen cambio: Necesidad que origina el cambio, permite identificar si el cambio es de naturaleza técnica o
funcional. Tenemos tres orígenes de cambio, Requerimientos funcionales, Cambios Técnicos y Soporte (fixes).
Impacto: Lo determina el número de clientes/servicios, tecnología o procesos impactados de acuerdo con la matriz
MEC(Matriz de Escalamiento Corporativo). https://comunicacionestigo.com/matriz/ Contraseña: Tigo2020**
El Riesgo de un cambio programado, se evalúa teniendo en cuenta la probabilidad (frecuencia vs controles
existentes) de que se presente un evento no planeado durante la ventana y el impacto de dicho evento.
Capa: Permite identificar la capa del servicio en la que se va a ejecutar el cambio. Infraestructura, Sistema Operativo,
Base de Datos, Aplicación.
5. Cambio menor: Cambio que no afecta los niveles de servicio de los clientes internos/externos e
implica un riesgo bajo de falla.
Cambio significativo: Cambio que afecta los niveles de servicio de los clientes
internos/externos o implica un riesgo medio de generar un impacto no controlado (Falla).
Cambio Mayor: Se caracterizan por implicar un riesgo alto de falla o por cumplir con una de
las siguientes características:
• Servicios o aplicaciones nuevas.
• Desarrollo de componentes o software nuevos.
• Cambios que a nivel transaccional implique modificaciones en 3 o más elementos de la
arquitectura.
• Entrada en servicio de plataformas para soportar servicios existentes.
• Proyectos de optimización, actualización, migración y/o reposición tecnológica.
Cambio Emergencia: Solicitud de cambio que debe ser ejecutado lo antes posible debido a que
tiene una prioridad de emergencia (Ver definición prioridad de emergencia en la tabla
Prioridad de Cambios).
Tipos de cambios
Cambio estándar: Cambio pre-aprobado que es de riesgo mínimo, relativamente común y
sigue un procedimiento o instrucción de trabajo de estricto cumplimiento.
6. Tipos de Prioridad
Prioridad normal (None): Solicitud planeada que cumple todas las etapas y tiempos definidos.
Prioridad Extraordinario (Alta): solicitud para atender requerimientos regulatorios, entes de control, temas de
interés nacional, estrategias comerciales de alto impacto, reprogramación por proyectos de transformación,
riesgo de multas, pérdida de ingresos, fallas, cierres contables, o riesgos de seguridad informática, que no
cumple con una prioridad normal, por lo que debe ser revisada y aprobada por Administración de Cambios en
un tiempo menor.
Las solicitudes deben ingresar al proceso de Lunes a Jueves entre las 7:30 y las 4:00 pm y Viernes entre las
7:00 y las 1:00 pm.
Prioridad de Emergencia:
Solicitud de cambio para resolver un Tiquete Técnico (TT): De TI con prioridad de emergencia (Ver
anexo_AC_Prioridad fallas TI)
- Sin impacto en cualquier aplicación o plataforma con inminente riesgo de afectación de que se genere un
impacto alto o crítico.
- Excepcionalmente se considerarán como cambios de emergencia: - Cambio por cierre contable * - Cambios
para atender requerimientos comerciales que responden de manera inmediata a productos, ofertas o tarifas
de la competencia y requerimientos regulatorios de aplicación inmediata en situaciones de Estado o
régimen de excepción Nacional.
Tipos de Prioridad
Anexo Prioridad fallas TI
*Entre el 26 del mes de cierre y el 9 del mes siguiente
7. Política Administración de Cambios – CM1
• La política de administración de cambios, la documentación del
procedimiento y los anexos referenciados en este documento se
encuentra en Share Point - Gerencia de Procesos (Colombia) –
Procesos Cliente – Gestión TI, en las carpetas 3.PL_Políticas, 2.
PC_Procedimientos y 5.AN_Anexos, respectivamente.
8. Objetivos de los controles CM
CM.1. Garantizar que se establecen políticas y procedimientos para la gestión de los cambios
de TI.
CM.2. Asegurar que todos los cambios (mejoras en el sistema, actualizaciones y correcciones
de errores) son debidamente autorizados antes de ser implementados, de acuerdo a la
establecido en las políticas y procedimientos.
CM.3. Asegurar que todos los cambios (mejoras en el sistema, actualizaciones y correcciones
de errores) son debidamente probados antes de ser implementados, de acuerdo a la
establecido en las políticas y procedimientos.
CM.4. Asegurar que todos los cambios de emergencia son autorizados por el personal
apropiado antes de ser implementados y trasladados a producción.
CM.5. Garantizar que los ambientes de desarrollo, pruebas y producción se encuentran
segregados así como las funciones; que los usuarios autorizados para poner los cambios en
producción no tenga permisos en el ambiente de desarrollo.
CM.6. La población de gestión de cambios procedente de la herramienta de emisión de tickets
es completa y precisa.
La población de cambios se reconcilia con la herramienta de gestión de cambios.
9. Roles del proceso
Solicitante del cambio::
Planea el cambio, identifica el impacto y recopila toda la información requerida para generar la solicitud del cambio y coordina todas
las actividades necesarias con las áreas implicadas, para garantizar el cumplimiento de los objetivos propuestos dentro de los
tiempos establecidos.
Administrador del cambio:
Es el responsable del TTP desde que ingresa al flujo de Administración de cambios , hasta que se cierra. Es el que analiza el
cumplimiento de las políticas y controles y se encarga de la negociación, agendamiento y cierre de los cambios.
Comité de Cambios:
Revisar, aprobar, rechazan o generan recomendaciones a todos los cambios de tipo mayor
Comité de Pasos a Producción:
Revisar y evaluar el impacto de manera transversal de todos los cambios que afecten o generen riesgo de afectación en los servicios
TI del ambiente productivo.
Parte afectada con el cambio:
Clientes internos y externos, para el proceso la parte externa normalmente está representada por los grupos de soporte de las
unidades de negocio.
Responsable del cambio:
Es quien debe responder por la correcta implantación y documentación del cambio de acuerdo a lo solicitado y a lo que se definió
en la planeación y coordinación. Para los cambios en los que se afecta la configuración (Inventario), debe realizar las actualizaciones
correspondientes en el repositorio específico en los tiempos establecidos, o garantizar que el grupo o persona responsable lo haga.
Ejecutor del cambio:
Es quien implementa el cambio dentro de la ventana autorizada. Es el responsable de pasar el TTP de Aprobado a Implementación
en Progreso en el momento de iniciar el cambio, realizar las verificaciones, documentación y demás cambios de estado
correspondientes a la actividad de ejecución del cambio.
10. Planeación de Infraestructura TI
Cambios técnicos (Catálogo)
Planeación de TI y Redes
Cambio Tecnico (Service Desk)
Desarrollo de soluciones
Requerimientos funcionales
(Bizflow – Catálogo/Service
Desk)
Aseguramiento/O&M
Fixes desarrollo y cambios
técnicos
(Service Desk )
Administrador
de cambios/comités
Ejecutor
Diagrama de bloques Administración de Cambios
Crear solicitud
de cambio
(TTP)
Validar
información
Documentar
Resultados
cambio
Estándar?
Aprobar y
Agendar
cambio
Ejecutar
cambio
Analizar
cambio
No
Cerrar cambio
Administración de cambio(TTP)
Aprovisionamiento
Cambios Técnicos
(Service des)
Menor
Si
Solicitante/Responsable
Tipo
cambio
Si
Negociar Comité de
cambios
significativo
Solicitar cita al
comité
Mayor
Cambio TI
Aval comité
Pasos a
producción
Si
No
Parte afectada
Matriz de
aprobadores por tipo
de solicitud
12. CM.2/CM3. Aprobación de los Cambios
• En el archivo resumen de la diapositiva 9 se relacionan los avales
por tipo de TTP con su respectivo impacto y prioridad. Ver detalle
para el aval técnico, usuario solicitante o funcional en el archivo
referenciado: AC _Matriz de Aprobadores por tipo de solicitud.
13. Tabla resumen información para crear TTP
Información requerida Adjuntos Notas
• Ciudad y zonas principalmente impactadas
con el cambio.
• Categoría.
• Elementos de infraestructura* y servicios
relacionados con el cambio.
• Fecha, hora y duración de la ventana.
• Tiempo de indisponibilidad.
• Origen Cambio
• Capa Servicio
• Número del requerimiento origen,(bizflow,
req catálogo, TT, TP, OC, etc) el que activó el
cambio.
• Descripcion de la Solicitud*
• Afecta SOX?
• Justificación - Beneficios
• Descripción
• Riesgos asociados al cambio y acciones de
mitigación.
• Ejecutores.
• Plan de trabajo.
• Plan de retorno.
• Plan de pruebas
• Plan de contingencia (si aplica).
Ruta del share point (desarrollos y
configuraciones)
• Documento de paso entre ambientes o
manual de instalación (Actualización de
aplicaciones y cambios en bases de
datos).
• Población afectada (para actualización
de datos en base de datos).
• Los scripts a ejecutar (tanto para la
ejecución del cambio como para el plan
de retorno).
• Carta de Certificación y aval de
pruebas y paso a producción de acuerdo
con la Política de QA. (Matriz de
aprobadores por tipo de solicitud)
•Blueprint para requerimientos
funcionales.
Aval de Director de Operaciones y
Aseguramiento o del Gerente de
Operaciones TI ( si el cambio es de
prioridad alta)
Si el cambio es significativo, se
debe detallar cuáles serán los
servicios/procesos que se verán
afectados y se debe adjuntar el
aval de las áreas impactadas de
acuerdo con lo definido en el
anexo: AC_Funcionales
operación-
Notificación_Negociación
Indisponibilidad
*En el campo Descripción de la
Solicitud, se debe indicar si es un
proyecto, un Desarrollo Menor
(DM), un Fix, un Cambio Técnico,
un tiquete Técnico (TT), como en
el ejemplo:
PROYECTO;102447908;Transfor
mación Migración BRM-CRM.
También se debe relacionar la
ruta del Share Point en la que se
encuentra toda la
documentación de las pruebas.