GAID POL Gestión de Cambios v5.10

Gerencia Arquitectura e Ingeniería de Datos
POLITICA GESTIÓN DE CAMBIOS

Fecha vigencia: 25 febrero de 2014
GAID
Versión: 5.10 – 20210513
GERENCIA DE ARQUITECTURA E
INGENIERIA DE DATOS

ARQUITECTURA E
INGENIERIA DE DATOS
FIJA Y MOVIL
1
GAID
Versión: 5.10 – 20210513
1. PROPÓSITO ............................................................................................................ 3
2. ROLES PROCESO DE CAMBIOS .......................................................................... 3
3. GENERALIDADES PROCESO DE CAMBIOS ........................................................ 4
3.1 SOLICITUD DE CODIGO DE SERVICIO ................................................................. 4
3.2 SOLICITUD Y ACTUALIZACION DE LINEA BASE: ................................................ 6
4. AGENDAMIENTO DE VENTANAS ......................................................................... 7
4.1 CANCELACIONES .................................................................................................. 8
5. COMITÉ DE ARQUITECTURA ................................................................................ 9
5.1 REQUISITOS Y GENERALIDADES PARA LA PRESENTACIÓN AL COMITÉ DE
ARQUITECTURA............................................................................................................... 10
6. IMPLEMENTACIÓN AMBIENTE PREPRODUCTIVO ........................................... 10
6.1 REQUISITOS IMPLEMENTACIÓN AMBIENTE PREPRODUCTIVO .................... 10
7. CAPACITACIÓN A OPERADORES ...................................................................... 12
8. IMPLEMENTACIÓN AMBIENTE PRODUCTIVO ................................................... 13
8.1 REQUISITOS IMPLEMENTACIÓN AMBIENTE PRODUCTIVO ............................ 13
9. AVAL DE PAP ....................................................................................................... 14
10. PRUEBAS DE CALIDAD DE SOFTWARE ............................................................ 14
11. DILIGENCIAMIENTO HOJAS DE VIDA PRODUCTOS INFORMACIÓN .............. 15
12. IMPLEMENTACIÓN PRODUCTIVA CAMBIOS SOX ............................................. 16
13.1 TCAB: ........................................................................................ 16
13.2. CAB.......................................................................................... 18
13. GESTIÓN DE CAMBIOS HERRAMIENTA MAXIMO ............................................. 19
14. GLOSARIO ............................................................................................................ 31
15. PROCESOS ASOCIADOS A CAMBIOS SOX....................................................... 32
2
GAID
Versión: 5.10 – 20210513
1. PROPÓSITO
El presente documento tiene como fin establecer los lineamientos generales para la
gestión y control de los cambios de la GAID (Gerencia de Arquitectura e Ingeniería de
Datos). Esta política está sujeta a modificaciones de acuerdo con lo definido por las
directrices de la Gerencia de Arquitectura e Inteligencia de Datos y el Comité de
Cambios de Claro IT, lo cual será notificado cuando suceda.
Todo el equipo de GAID debe estar involucrado con el cumplimiento de los lineamientos
presentados.
2. ROLES PROCESO DE CAMBIOS
Nombre del Rol Definición Procesos Nombre del

responsable
Ingeniero de fábrica o de
GAID encargada de la gestión
Líder del cambio El asignado El asignado
del cambio, la misma
registrada en MAXIMO.
Usuario solicitante del cambio,
Usuario solicitante El asignado El asignado
ya sea de IT o de externo a IT.
Ingeniero GAID encargado de
la revisión de todo lo Jehimmy Viviann
Revisor de cambios Todos
relacionado con el cambio y López Beltrán
los estándares de desarrollo.
Ingeniero de Claro encargado
de la gestión de cada uno de
Líder del proceso Todos Jehimmy Viviann
los procesos de la gestión del
cambio. López Beltrán
Ingeniero de Claro encargado
Administrador de
de la administración de las Todos Jehimmy Viviann
versiones
líneas base López Beltrán
Encargado de la gestión de
las Pruebas, Aceptación con
el usuario solicitante, PO de claro
Líder de pruebas Todos
validación y aprobación de asignado
pruebas unitarias para paso a
QA
Aprobador de PO de claro
Cierre de la tarea Todos
Pruebas asignado
Analista de la Gerencia de QA
Analista de
encargado de realizar las El asignado El asignado
pruebas
pruebas funcionales.
3
GAID
Versión: 5.10 – 20210513
3. GENERALIDADES PROCESO DE CAMBIOS
a. La gerencia maneja los siguientes tipos de implementaciones:

 Ambiente Preproductivos
 Ambiente Productivo
b. Para realizar implementaciones en ambiente productivo es obligatorio realizar una
capacitación previa al equipo de operaciones.
c. Las implementaciones y capacitaciones de cualquier tipo deben ser cargadas en
SharePoint. Para más detalle (ver sección 4. Agendamiento de Ventanas)
d. Únicamente para las implementaciones que afecten los siguientes procesos que se
asocian a cambios SOX se deben presentar ante el respectivo TCAB o CAB según
categoría del riesgo y estos son:
 Compensación.
 Prepago.
 Trafico (Voz, Datos, SMS).
 DOC 1 (Facturación Postpago)
En cuanto al detalle de los códigos de servicio que se asocian a los procesos antes
mencionados se encuentran en el Anexo No 1.
e. Toda la documentación asociada a cada requerimiento debe encontrarse
almacenada en SharePoint según las políticas de la gerencia.
f. Todos los requerimientos deben pasar por el Comité de Arquitectura y obtener el
visto bueno de la misma.
3.1 SOLICITUD DE CODIGO DE SERVICIO
Cada equipo de desarrollo luego del análisis del requerimiento (EPICA) debe consultar el
catálogo de servicios disponible en SharePoint y así evaluar la codificación correspondiente
para trabajar en el desarrollo asignado.
Ruta: 01_Administrativo/ 01 – Información General/ 07 – Catálogo de Servicios
En caso que el código de servicios aplique para el desarrollo, se procede con la solicitud de la
Línea Base. (3.2 Solicitud Linea Base).
Si en el análisis y revisión del catálogo de servicios NO existe ningún código que aplique para el
correcto desarrollo del requerimiento, se debe realizar la Solicitud del Código del Servicio,
el formato de solicitud se encuentra en la siguiente ruta:
Ruta: 01_Administrativo/ 01 – Información General/05 – Formatos Documentación/Cambios/EPIC-

XXXX-Solicitud código de servicio-Nombre Corto.
4
GAID
Versión: 5.10 – 20210513
Formato establecido (SharePoint):
Solicitud código de servicio
Cordial saludo,
Por favor su colaboración con la generación del código de servicio para el siguiente proceso:
No Épica: EPIC-XXXX
No requerimiento IT. BRIEF-XXX
País: Colombia
Móvil /Fija / Transversal
Operación:
Relacione una opción según corresponda
VOZ / DATOS /PREPAGO / MENSAJERIA / VENTA / CLIENTES /

Proceso: COMISIONES / HOGARES / PERSONAS / EMPRESAS / GAI /
TRAFICO / ADMINISTRACION
Relacione una opción según corresponda
<Tipo de entregable, qué contiene, periodicidad, volumetría

Descripción proceso: (aproximada), y medio de entrega de la información (ejemplo
Nombre del servidor, Portal Cognos, Portal de Reporte de DWH,
etc. (no es la ruta, ni la url )) + Información adicional que pueda ser
de interés
ODI/NETEZZA/Nifi – Kafka – Flink – Druid – Superset / Teradata /
Herramientas a emplear:
Hive
Nombre del Job padre: JP_####_NOMBRE_CORTO (Según política de desarrollo)
Entregables: <Cubo, Reporte Cognos, Tabla, ETL, Tablero Avanza, etc.>

Nombre de los
Relación de los nombres
entregables:
Área usuaria: <Área de Claro (Gerencia o Dirección>
Nombre de los usuarios: <Dos nombres completos de personal directo de Claro
Enviar correo con la solicitud a Monica Duque monica.duque@claro.com.co (Remitente Principal)

con copia GDI_GAID_REQUERIMIENTOS GDI_GAID_REQUERIMIENTOS@claro.com.co,
GDI_GAID_ARQUITECTURA GDI_GAID_ARQUITECTURA@claro.com.co y al personal del grupo
de trabajo.
Luego de recibir respuesta de la asignación del nuevo código de servicio, es responsabilidad del
Equipo de Desarrollo registrar el Código de Servicio como LB BLOQUEADA en Share Point.
5
GAID
Versión: 5.10 – 20210513
3.2 SOLICITUD Y ACTUALIZACION DE LINEA BASE:
Si el proceso es una modificación a un proceso existente se debe crear la tarea en Azure Devops,
la tarea debe ser asignada al administrador de versiones (Jehimmy López jehimmy.lopezb@claro.com.co).
Registrar la solicitud en el formulario de SharePoint:
Ruta del Formulario:

http://portalesclaro/sites/portalgdwh/_layouts/15/start.aspx#/Lists/Gestin%20Lneas
%20Base/Buscador.aspx
Una vez el equipo de Desarrollo tenga PAP exitoso y libere la Linea Base debe:
 Cambiar el estado del registro EN ACTUALIZACION

 Crear tarea de actualización de Linea Base en Azure Devops y asignarla a
Jehimmy López.
 Diligenciar los siguientes campos en el formulario de Share Point:
6
GAID
Versión: 5.10 – 20210513
 Una vez finalice la implementación con resultado EXITOSO, El equipo de

desarrollo debe garantizar que él Operador cargue la Linea Base implementada
en la carpeta Actualización Linea Base del código de servicio y Epica
implantada.
4. AGENDAMIENTO DE VENTANAS
El agendamiento se realiza en la vista POR APROBAR del SharePoint máximo a las 9 am

del viernes, con el fin de validar las fechas de Capacitación e Implementación del
desarrollo. Los días de aprobación de las fechas para capacitación e implementación son
los días viernes de 2:00 p.m a 4:00 p.m. En caso de que el viernes sea festivo se
programará el día hábil anterior a este.
Los registros que se encuentran en la matriz POR EJECUTAR, NO pueden ser modificados
por ningún integrante de los equipos de Desarrollo de las diferentes Fábricas.
En el caso de solicitar algún tipo de cambio, la fábrica debe enviar un correo solicitando
dicho cambio a Alicia Cuesta (alicia.cuesta@claro.com), Sindy Reyes (sindy.reyes@claro.com)
Jehimmy López (jehimmy.lopezb@claro.com) y Jhon Jairo Salazar
(jairo.salazar@claro.com.co) con copia al PO Claro y PO fabrica con el número de la Épica,
Brief o número de cambio si aplica, explicando:
 El motivo por el cual se requiere hacer el cambio y el nombre del campo que
desean cambiar.
Las únicas personas autorizadas para realizar cambios en la matriz POR EJECUTAR
son: Alicia Cuesta (Analista de Soporte de Operaciones) y Sindy Reyes (Coordinador
Soporte Sistemas Información).
IMPORTANTE:
 La fábrica de desarrollo NO debe diligenciar los campos de la sección de

APROBACIÓN GGE.
 Una vez se cargue el nuevo registro, este se mantendrá en la vista de 01- Por
aprobar.
 Una vez aprobados los registros, el agendamiento se verá reflejado en la vista

de 02- Por Ejecutar.
7
GAID
Versión: 5.10 – 20210513
 Las Capacitaciones deben celebrarse con mínimo 5 días de anterioridad a la

fecha aprobada de la Implementación en ambiente Productivo. (Para ambiente
Pre-Productivo NO se realiza capacitación.)
 Las Capacitaciones que sean exitosas tienen una vigencia de 90 días (3

Meses) antes de la implementación en ambiente Productivo. Si este tiempo
caduca, se requiere volver a capacitar para pasar a producción.
 La citación (Reunión Microsoft Teams o ZOOM) para las capacitaciones e

implementaciones debe ser enviada mínimo 15 minutos antes de la hora
programada en la matriz de implementación, por el equipo de Operaciones al
desarrollador que se encuentra registrado en la matriz y copiar a Alicia Cuesta
(alicia.cuesta@claro.com) y Jehimmy López (jehimmy.lopezb@claro.com).
NOTA: Si no se cargan registros con antes de las 9:00 am del viernes, no se tendrá en
cuenta en la reunión de agendamiento.
4.1 CANCELACIONES
4.1.1 CANCELACIÓN DE REGISTROS APROBADOS EN LA MATRIZ DE IMPLEMENTACIÓN:
Para cancelar un registro en la matriz POR EJECUTAR (matriz de implementación) en

ambiente pre productivo, productivo y capacitaciones, se debe enviar un correo
(plantilla de correo) a Alicia Cuesta (alicia.cuesta@claro.com), Sindy Reyes
(sindy.reyes@claro.com) Jehimmy López (jehimmy.lopezb@claro.com) y Jhon Jairo Salazar
(jairo.salazar@claro.com.co) con copia al PO Claro y PO fábrica, explicando:
 El motivo por el cual se cancela dicha implementación argumentando porque

este paso a pre productivo o productivo no se dio a tiempo.
 Cuando la justificación sea por falta de aval del usuario se debe especificar la
razón por la que el usuario no dio dicho aval.
Nota: El tiempo estimado para realizar la cancelación de estos registros debe ser con 12
horas de antelación.
Ruta: /01 - Información General/05 - Formatos Documentación/Cambios/EPIC-XXXX-

BRIEF- (Si aplica) - Cancelación Ventana Implementación-Capacitación-Código de
Servicio.
8
GAID
Versión: 5.10 – 20210513
Formato establecido (SharePoint):
5. COMITÉ DE ARQUITECTURA
La finalidad del comité de arquitectura es realizar una presentación de un modelo del

desarrollo, en dicho comité se reciben comentarios y sugerencias con el fin de que el
desarrollo se realice bajo las mejores prácticas.
Durante la realización del desarrollo se debe tener en cuenta las recomendaciones dadas
por el equipo de arquitectura de la gerencia.
Una vez finalizado el desarrollo se procede con la construcción del documento de

arquitectura. Este documento deber ser enviado al equipo de arquitectura de la gerencia.
El equipo evalúa el documento y en caso de que requiera alguna corrección se le informa
a líder del desarrollo.
Finalmente, si el documento cumple a cabalidad con los lineamientos establecidos por el

equipo de arquitectura, se da por aprobado.
IMPORTANTE: Es indispensable que el documento de arquitectura haya sido

aprobado por el equipo de Arquitectura, con dicha aprobación el desarrollo podrá ser
enviado al área de pruebas de la gerencia.
Equipo de Arquitectura GAID

Jhon Jairo Salazar Coordinador Gestión Información BI
Alejandro Marin Coordinador Arquitectura Analítica
Guioner Alexander Pardo Mateus Arq. Sistemas de Información
José Carreño Ibáñez Consultor Arquitectura
Jaime Andres Ramirez Aroca Consultor Arquitectura
9
GAID
Versión: 5.10 – 20210513
A continuación, se relacionan los horarios del Comité de AQ:
Horario
Martes 11:00 am - 12:00 pm
Jueves 2:00 pm - 3:00 pm
5.1 REQUISITOS Y GENERALIDADES PARA LA PRESENTACIÓN AL COMITÉ DE

ARQUITECTURA:
 Revisar los avances para la etapa de diseño y arquitectura que los requerimientos.
 No es una reunión para la elaboración del diseño de la solución. Ésta tarea está a cargo
de las fábricas de desarrollo.
 Se revisará: HLS de la solución aterrizada para el DWH, modelo dimensional planteado
y documentación adicional que facilite la aclaración del requerimiento.
 El líder del requerimiento deberá entregar la información (plantilla establecida) 1 hora
antes de la reunión. Enviarla vía correo electrónico al grupo GDI_GAID_ARQUITECTURA
GDI_GAID_ARQUITECTURA@claro.com.co.
 Ruta de Share Point para descargar la plantilla:
ADMINISTRATIVO/01 - Información General/05-Formatos Documentación/Cambios.
Nombre del Archivo: EPIC-XXXXX-Comité AyD.pptx
 Las presentaciones serán revisadas de acuerdo al orden de llegada.
 En caso de no alcanzar a revisarlas todas en el tiempo definido se posterga para la
próxima sesión.
 No está dentro del alcance de la reunión validaciones en tipos de datos y estructuras de
objetos. Ésta información deberá ser enviada y se revisará bajo el esquema actual.
6. IMPLEMENTACIÓN AMBIENTE PREPRODUCTIVO
Si el desarrollo afecta los siguientes servicios, tenga en cuenta que no será posible
realizar la implementación en ambiente Preproductivo:
 Modelo prepago
 Extrae Datos Contratos
 Confidenciales
6.1 REQUISITOS IMPLEMENTACIÓN AMBIENTE PREPRODUCTIVO
 Contar con el Aval de Jhon Jairo Salazar, diligenciar los tres primeros ITEM la
sección de APROBACIÓN PREPRODUCCIÓN GAID en la matriz de implementación en
SharePoint:
10
GAID
Versión: 5.10 – 20210513
- Al momento de realizar la aprobación por parte de Alicia Cuesta y Jehimmy López

en registro en la matriz debe aparecer como último actualizador Jhon Jairo o
Alejandro Marin como Coordinadores.
- En caso de que aparezca otro usuario como último actualizador no se aprobará la

ventana y queda para la siguiente reunión entre Operaciones y GAID.
- Adjuntar en Share Point con 24 horas de anticipación a la implementación los

siguientes documentos:
o Implementación & RollBack.
o Presentación AQ - revisada en el comité de arquitectura de GAID
o Documento de historias.
o Aval de Usuario.
6.2 Observaciones y Generalidades:
 La corrección de las fallas reportadas por GOGE deben ser acordadas y

corregidas en compañía del Product Owner de Claro.
 La legalización del cambio debe realizarse en el menor tiempo posible.
 La capacitación informal al operador se realizará en el momento de la
implementación, no se debe dejar acta.
 El desarrollo no requiere ser enviado previamente a pruebas de QA.
 La implementación para el caso de Data Manager se hará en el catálogo
CAT_COL_PREPRODUCCION (WINTSERV01), en la carpeta correspondiente a
cada módulo.
 La tarea programada se debe crear en el task en la carpeta 03_PREPRODUCCION
(WINTSERV01).
 Los cubos y reportes de Cognos se deben publicar en el ambiente de
PREPRODUCCION (WINTSERV01).
11
GAID
Versión: 5.10 – 20210513
 Los discos para la creación de las carpetas del servicio son los mismos de
producción.
 Las bases de datos y esquemas son las mismas de producción.
 Las conexiones deben estar apuntando únicamente a fuentes productivas.
 Al finalizar la implementación se debe enviar al usuario el correo de “Fin de la
implementación en preproducción”. Formato establecido (SharePoint).
7. CAPACITACIÓN A OPERADORES
 El Ingeniero de Desarrollo debe liderar la capacitación al Analista de la GOGE sobre

el desarrollo realizado.
 Durante la capacitación se debe levantar el Acta de Capacitación.
 Una vez finalice la capacitación, el Analista de GOGE debe enviar un correo
adjuntando el acta (Formato establecido).
 Ruta de Share Point para descargar la plantilla: ADMINISTRATIVO/01 - Información
General/05-Formatos Documentación/Cambios. Nombre del Archivo: EPIC-XXX-
(Abrev Proceso)-Acta de Capacitación v1.0
 Indicando si hay pendientes o solicitando aprobación de esta, a los siguientes
correos de GOGE (GOGE@claro.com.co), con copia al líder del cambio y a
jehimmy.lopezb@claro.com.co.
 Para los casos donde el usuario entrega archivos o tablas específicas, el Operador
debe solicitar el ANS acordado con el usuario. El ANS debe estar registrado
(Responsabilidad Fabrica de Desarrollo) y el estado (Enviado para Aprobación y/o
Aprobado) en el formulario de SharePoint DWH.
 Por parte de la fábrica se debe garantizar que los compromisos se cumplan antes
de la implementación.
 Restricciones o condiciones que tenga el proceso para su ejecución, deben explicar
dependencias del proceso y hora indicada para su ejecución.
 En el caso que queden puntos pendientes por validar después de la capacitación,
se deben indicar en el acta de capacitación y en el correo de envío del acta con el
formato establecido (este proceso lo realiza el operador).
Nota: Si las documentación se encuentra incompleta se debe notificar por correo, a las
Gerencia GAID, Coordinación Soporte Sistemas Información, para que se realicen las
respectivas correcciones antes de la capacitación, esto con el fin de que al momento de
recibir la capacitación del proceso ya debe estar completa y corregida la documentación.
 Adjuntar en Share Point con 24 horas de anticipación a la capacitación los

- Historia de Usuario
- Mapa Fuente Destino: Solo si se modifican los elementos fuente y/o destino.
- Arquitectura y Diseño
- Manual Técnico y de Usuario
- Si es un error conocido en los documentos debe estar adjunto el Formato de
Escalamiento enviado por el grupo de Analistas 3.
12
GAID
Versión: 5.10 – 20210513
8. IMPLEMENTACIÓN AMBIENTE PRODUCTIVO
Para las implementaciones en ambiente Productivo hay dos opciones pasando por
comité de cambios de IT o no. Únicamente los cambios SOX deben pasar por comité
de cambios de IT (TCAB o CAB según corresponda).
Todas las implementaciones productivas deben de haber realizado una

capacitación previa al equipo de operaciones.
8.1 REQUISITOS IMPLEMENTACIÓN AMBIENTE PRODUCTIVO
 Contar con la fecha de implementación aprobada por parte del equipo de

operaciones.
 Realizar presentación ante el comité de Arquitectura y contar con el aval de los
documentos de arquitectura y diseño.
 Capacitar al equipo de operaciones y cumplir los compromisos adquiridos.
 Para los casos donde el usuario entrega archivos o tablas específicas que son
fuente del Desarrollo, el ANS debe estar APROBADO vía correo electrónico por el
usuario y con estado APROBADO en el SharePoint DWH (Plantilla establecida)
(Este documento se debe entregar a más tardar el día de la implementación).
 Adjuntar en Share Point con 24 horas de anticipación a la implementación los

o FSP (si aplica).

o Mapa Fuente Destino.
o Arquitectura y Diseño.
o Documento de historias de usuario.
o Manual Técnico y de Usuario.
o Informe de Pruebas de Desarrollador (incluido el log de ejecución del
proceso, cantidad de datos cargados y tiempos de ejecución “óptimos”).
o Minuto grama.
o Implementación & RollBack.
o Aval de PaP por parte del Coordinador de Operaciones.
Únicamente para GAI (Aseguramiento de Ingresos) se debe verificar lo siguiente:
• Manual Técnico y de usuario

• Manual de Arquitectura y Diseño
• Manual de Implementación y Rollback
• Aval de la Arquitectura
• Aval de la Coordinación Soporte de Sistemas de Información
13
GAID
Versión: 5.10 – 20210513
 Al finalizar la implementación se debe enviar al usuario el correo de “Fin de la

implementación en Producción”. Formato establecido (SharePoint).
9. Aval de PAP
Al obtener la aprobación de la ventana de Implementación es necesario solicitar el AVAL

de PAP por parte del área de Operaciones según el formato establecido por la gerencia.
Únicamente para los cambios SOX es necesario solicitar el aval al gerente del área de
operaciones para todos los demás el aval requerido es dado por el Coordinador de
Operaciones.
Requisitos:
En el correo de solicitud de AVAL de PAP adjuntar:
 Aval de Arquitectura *Correo. (Documentos Arquitectura y Diseño).

 Aval área usuaria.
 Informe de Pruebas de Desarrollador.
 Acta de Capacitación.
** En cuanto al acta de capacitación solo se puede adjuntar si y solo si, todos
compromisos pendientes ya están resueltos, si quedó algún compromiso en
la capacitación debe estar ya resuelto cuando sea enviado a la Coordinación
de Operaciones.
10. PRUEBAS DE CALIDAD DE SOFTWARE
Solo Aplica Para REQ. De IT el paso por la Gerencia de Calidad de Software (QA).
A partir de JUNIO 2020 – Los desarrollo de la Gerencia GAID No pasan por la Gerencia
de Calidad de Software (QA. Las fábricas de Desarrollo deben garantizar la Calidad
del Desarrollo a entregar.
Formato establecido: Informe de Pruebas de Desarrollador. Garantizando:
Tener en cuenta finalmente que si el requerimiento afecta un cambio SOX debe tener
asociado un cambio en MAXIMO y se deben gestionar las tareas correspondientes de esta
fase.
14
GAID
Versión: 5.10 – 20210513
11. DILIGENCIAMIENTO HOJAS DE VIDA PRODUCTOS INFORMACIÓN
Para pasos a Producción o Preproducción donde el resultado de la Implementación y

ejecucion sean EXITOSAS y sea un cambio Nuevo, por instrucción de la Gerencia GAID
los líderes de cada una de las células de Desarrollo, tienen como compromiso el correcto
diligenciamiento de la Hoja de Vida para Productos de Información que se generen desde
la Gerencia Arquitectura e Inteligencia de Datos.
Lo anterior hace parte del proyecto denominado Democratización de la Información que

lidera la Gerencia de Gobierno y Estrategia Datos, cual tiene como objetivo
centralizar todos los productos de información producidos en la Dirección de Analítica e
Inteligencia de Datos; estos serán insumos para el “Inventario de Productos de Información
DAID”.
El diligenciamiento de esta información se realizará en el Share Point de la Gerencia de

Gobierno y Estrategia Datos.
URL: https://claromovilco.sharepoint.com/sites/HojasdeVidaProductosdeInformacion/
Recomendaciones Generales GAID:
 El registro debe realizarse para todos los Productos Nuevos a partir del mes de Abril
de 2021.
 Responsables del registro PO, Scrum Master y/o PM de las células de Desarrollo.
 Usar adecuadamente la nemotecnia definida para los nombres de los tableros
(Prefijos, direcciones corporativas y palabras como “Reporte, Informe Tablero”.
 No anteceder el nombre de PoI (Producto de Información) con el tipo (Modelo, Base,
Tablero).
 Los registros ya creados, no deben ser eliminados, se pueden editar.
 Actualizar la información documentada según su último estado.
 En el Campo Nombre Custodio Técnico para todos los casos nombrar al
Coordinador de Operaciones (Sindy Yelid Reyes Rodriguez).
 En el Campo Gerencia Custodio Técnico para todos los casos será Gerencia
Operaciones Sistemas de Información.
 Documentación en el campo Link Acceso que no cuente con url:
Link de Acceso: https://claro.com
Mostrar este texto: BD_Esquema_tabla
El instructivo completo para el diligenciamiento se encuentra en Share Point:
Ruta: ADMINISTRATIVO/01 - Información General/05-Formatos Documentación/Cambios.

Nombre del Archivo: Instructivo Hojas de Vida Productos Información.
15
GAID
Versión: 5.10 – 20210513
12. IMPLEMENTACIÓN PRODUCTIVA CAMBIOS SOX
Lo primero a tener en cuenta es que para esta modalidad se requiere la creación de un

cambio en MAXIMO el cual debe ser gestionado como se menciona más adelante, esto con
el fin de que sea evaluado por el área de cambios de IT en los comités respectivos.
Los requerimientos que deben pasar por el proceso de legalización del cambio deben tener
en cuenta que se deben presentar ante un comité que avalaran el paso a producción, estos
son TCAB y CAB.
12.1 TCAB:
De acuerdo lo establecido en los procesos de auditoria de Claro, todos los cambios SOX
debe presentarse ante un TCAB. Los cambios categorizados como riesgo bajo o medio
deben ser presentados y aprobados por un TCAB, para los cuales el riesgo sea mayor
deben ser avalados por un CAB y para ello contar con el aval del director del área.
A continuación, se relacionan los servicios que son auditados por la compañía:
a. Compensación.
b. Prepago.
c. Trafico (Voz, Datos, SMS).
d. DOC 1 (Facturación Postpago)
Durante esta sesión se aprueban los cambios que a juicio del comité sean de riesgo bajo o
medio, los cambios deben estar en la fase auto implementación CAB en la herramienta
MAXIMO antes de la fecha de corte establecida.
Los manuales de la herramienta Máximo se encuentran en la siguiente Ruta:

/01 - Información General/04 - Manuales - Tutoriales/MAXIMO/
16
GAID
Versión: 5.10 – 20210513
Horarios y cortes del TCAB
Horario Corte Horario TCAB
Lunes 5:00 pm Miércoles 10:00 am - 12:00 pm

Miércoles 5:00 pm Viernes 2:00 pm - 5:00 pm
En caso de que el día del corte sea festivo, este será el día hábil anterior al
indicado.
Para presentar un cambio en el TCAB tener en cuenta lo siguiente:
En la herramienta MAXIMO el cambio debe de llegar a la fase de Auto implementación

CAB y contener adjunto el Minutograma.
En SharePoint, se deben adjuntar los siguientes correos y documentos:
Correos de aprobación de:
 Ambiente QA
 Pruebas QA
 Pruebas Usuario
 Acta de Capacitación
 Operaciones PaP (Coordinador)
Documentos:
 FSP (si aplica)

 Historias de usuario
 Arquitectura y Diseño
 Mapa Fuente Destino
 Manual Técnico y de Usuario
 Informe de Pruebas de Desarrollador (incluido el log de ejecución si aplica)
 Implementación y Rollback
 Minutograma
IMPORTANTE: Una vez presentado el cambio ante el TCAB los avales del gerente de
operaciones y del gerente de desarrollo serán tramitados por el área de Gestión de
Cambios en conjunto con el equipo de GAID. El cambio es Aprobado si luego del aval
del TCAB se reciben estos avales.
17
GAID
Versión: 5.10 – 20210513
12.2. CAB
Los cambios normales categorizados como riesgo Alto o Extremo deben ser presentados y
aprobados por el CAB o Comité de Cambios, estos cambios deben contar con el aval del
Director del área.
Para presentar un cambio en el CAB tener en cuenta lo siguiente: deben haber pasado a
un TCAB previo en el cual se determine el nivel de riesgo Alto o extremo.
En SharePoint, se deben adjuntar los siguientes correos y documentos:
Correos de aprobación de:
 Ambiente QA
 Pruebas QA
 Pruebas Usuario
 Acta de Capacitación
 Aval Gerente Desarrollo (estos avales son gestionados por parte del área de
cambios)
 Aval Gerente Operaciones (estos avales son gestionados por parte del área de
cambios)
Nota: tener en cuenta que los avales con asterisco son gestionados por parte
del área de cambios en conjunto con el PO de Claro asignado.
Documentos:
 FSP (si aplica)

 Historias de usuario
 Arquitectura y Diseño
 Mapa Fuente Destino
 Manual Técnico y de Usuario
 Informe de Pruebas de Desarrollador (incluido el log de ejecución si aplica)
 Implementación y Rollback
 Minutograma
Horarios y cortes del CAB
Horario Corte Horario Comite

TCAB del viernes anterior Martes 2:00 pm - 5:00 pm
TCAB del miércoles anterior Jueves 2:00 pm - 5:00 pm
18
GAID
Versión: 5.10 – 20210513
13. GESTIÓN DE CAMBIOS HERRAMIENTA MAXIMO
Todos los cambios SOX deben pasar por el siguiente proceso en la herramienta MAXIMO.
Al ingresar a MAXIMO (LOCAL  http://100.126.20.133/maximo/ui/login WEB 

https://190.144.215.103/maximo/ui/login ) en el menú de la parte izquierda seleccionar
Cambios, luego seleccionar la opción Abrir nuevo cambio, seguidamente seleccionar el
tipo de cambio que desea crear Cambio Normal o Cambio Emergente, en éste momentos
se empiezan a diligenciar los campos que solicita la herramienta en cada fase así:
Fase Registro del cambio
a) ID del cambio: Consecutivo generado automáticamente al crear el cambio.
b) Fase: Las fases de los cambios son las siguientes y se generan automáticamente
al iterar o avanzar el cambio a medida que se completan los prerrequisitos para
poder avanzar.
c) Estado: Se genera automáticamente por la herramienta.
d) Estado de aprobación: Se genera automáticamente por la herramienta.
e) Origen del Cambio (Lista): Seleccionar una de las siguientes opciones:
Origen Descripción
Incidente Es ser soportada con un INCIDENTE registrado en MAXIMO y debe
relacionarse en el campo observaciones del cambio, dicho incidente
debe ser creado por el área que detectó el incidente.
Solicitud área Es soportada por un número de BRIEF, indicarlo en el campo No
usuaria BRIEF del cambio y una SOLICITUD QXXXX registrada en
MAXIMO, debe ser asociada al cambio. Dicha solicitud debe ser
creada por el área que solicitó el cambio.
Solicitud Interna Es soportada por una SOLICITUD QXXXX registrada en MAXIMO,
de TI debe ser asociada al cambio. Dicha solicitud debe ser creada por
el área que solicitó el cambio.
Predicción de fallo Es soportada con el formato de PREDICCION DE FALLO –
AFECTACIÓN DEL SERVICIO DEL NEGOCIO el cual debe estar
firmado por el Director del Negocio que solicita el emergente. El
formato debe ser diligenciado por Líder del cambio, y ser enviado
al Coordinador de GAID para su respectiva aprobación.
Problema Es soportado por número de PROBLEMA registrado en MAXIMO,
para registrar dicho problema el líder del cambio debe enviar un
correo al Coordinador de GAID adjuntando el formato de registro de
problema, quien enviará la solicitud a la Gerencia de Servicios IT
para su inclusión
19
GAID
Versión: 5.10 – 20210513
f) Tipo de cambio: Se llena automáticamente al indicar el tipo de cambio que se desea

crear.
g) Naturaleza del cambio (Lista):
Software: Todo tipo de cambio que implique modificación del Software

Infraestructura: Todo lo relacionado con Hardware
h) Área responsable: Siempre seleccionar COL-IT-GGIBI-GERENCIA.
i) Líder del cambio: Persona encargada (fábrica) del avance de las fases y gestión
del cambio.
j) Correo líder del cambio: Se diligencia automáticamente al seleccionar el Líder.
k) Teléfono líder del cambio: Digitar el número de celular del líder del cambio, NO
puede ser extensión.
l) Compañía y Tenant: Se llenan automáticamente al seleccionar el solicitante del

cambio.
m) Solicitante del cambio: Ingresar el nombre del usuario interno o externo que
solicita el cambio.
n) Nro. Brief: Ingresar el número del BRIEF que originó el cambio, sólo aplica para
cambios con origen Solicitud Área Usuaria.
o) Cambio de Garantía: Se habilita cuando se selecciona Garantía en el campo

Categoría del Cambio, aquí se debe registrar el número del cambio clasificado como
“No exitoso” y para el cual se está presentando la garantía.
p) Gerencia: Siempre se debe seleccionar DDS_GGIBI - Gerencia Desarrollo,

Gestión, Información y BI
q) Aprobador de pruebas: Se debe seleccionar el Product Owner de claro

responsable del cambio, quien será el encargado de cerrar la tarea en MAXIMO.
r) Título: Debe tener el siguiente estándar
DWH (Colombia) o PPDWH (Panamá)-Consecutivo código de servicio-Abreviatura

del proceso-Descripción breve del cambio a realizar.
Ejemplo: DWH-0764-PREP-Inclusión dimensión de agentes en el reporte de

activaciones.
s) Descripción del cambio: Indicar de forma clara el cambio o nueva funcionalidad a

desarrollar para GAID, NO la necesidad del usuario descrita en el FSP. Debe cumplir
con el siguiente estándar:
20
GAID
Versión: 5.10 – 20210513
1. OBJETIVO: Generar la liquidación para el pago de comisiones de los indicadores de gestión.

2. NECESIDAD: Automatizar el proceso de pago de liquidaciones a los diferentes asesores de la compañía en
el tiempo estimado.
3. RIESGO DE NO HACERLO: Se podría generar el no pago o pago tardío de las comisiones, incurriendo en el
aumento de reclamaciones.
4. PEOR ESCENARIO: No generar la información correspondiente a la fecha estimada.
5.TIEMPO DE AFECTACION DEL PEOR ESCENARIO: 15 minutos
6. MITIGACIÓN Y CONTINGENCIA AL PEOR ESCENARIO: Solicitar al área de operaciones la ejecución del
proceso nuevamente para la generación de la información.
7.NIVEL DE IMPACTO (BAJO, MEDIO, ALTO): Bajo
8.PROBABILIDAD EN QUE SE MATERIALICE EL PEOR ESCENARIO (1-4 SIENDO 1 EL MAS BAJO): 1
9.NIVEL DE RIESGO (se define en Tcab):
10.GERENTE LIDER DEL CAMBIO: José Luis Fajardo
11.GERENTE DE OPERACIONES LIDER TECNICO: Juan Carlos Ruiz Diaz
12.APROBACION DEL NEGOCIO: No genera indisponibilidad -No aplica
13.HORA Y FECHA DE INICIO Y FIN DE AFECTACIÓN: No aplica
14.USUARIO PRUEBAS FUNCIONALES: Sonia Carolina Calderon - 7429797 Ext.63134
15.EL DESARROLLO FUE EJECUTADO Y PROBADO EN UN AMBIENTE HOMOGENEO AL PRODUCTIVO:
SI
16.EL DESARROLLO FUE REALIZADO SOBRE LA ULTIMA VERSIÓN Y CUENTA CON VALIDACION DE
ESTANDARES:SI
17.ESTE CAMBIO ACTUALIZA LA LINEA BASE: SI
18.RECURSO : COL-IT-GOGE-OPER2
19.SERVICIOS INVOLUCRADOS: 0480_VENT_INDICADORES/0486_VENT_INFORMES_CONFIDENCIALE
En azul el ejemplo
t) Justificación del cambio: Indicar el por qué se hará el cambio indicado en la

descripción, en éste caso si se puede colocar la necesidad que quiere suplir el
usuario con el cambio.
21
GAID
Versión: 5.10 – 20210513
**En caso de requerir la cancelación del cambio (una vez guardado) se debe
seleccionar en la parte superior de los detalles del cambio la siguiente opción:
u) Cancelar cambio: Si por algún motivo se desea cancelar un cambio, se debe

seleccionar SI y se habilitará un nuevo cuadro de texto en la parte inferior para
diligenciar el motivo de la cancelación.
Para realizar la cancelación de un cambio que ha sido aprobado por el comité el Líder del
Cambio debe notificar vía telefónica y correo electrónico a los grupos ejecutores del
cambio hasta 30 minutos antes de la implementación, si los grupos ejecutores son
GBDM y/o GIIT, copiar el correo a itadmincambios.co@claro.com.co y
cambiosvpp@claro.com.co. De lo contrario el cambio debe ser No exitoso.
v) Comentarios por cancelar cambio: Este campo se habilita al seleccionar –SI- en

el campo “Cancelar cambio”, se debe indicar el motivo por el cual se cancela el
cambio.
Validación e Integración de Fuentes (de 1 a 20 CIs): Si el formato de evaluación

de riesgo lo solicita, se debe crear al mismo tiempo que la tarea de solicitud de línea
base, y debe ser asignada al líder del proceso, quien se encargará de cerrarla.
Diligenciar la encuesta de impacto de acuerdo a lo requerido por el cambio que está

presentando. El siguiente es un ejemplo de como se ve la encuesta en la
herramienta.
22
GAID
Versión: 5.10 – 20210513
Categorías del cambio
✔ Mantenimiento
Se debe seleccionar cuando se realiza la modificación a un proceso a ya existente, debe

coincidir con la respuesta dada en la evaluación del riesgo.
✔ Nueva funcionalidad
Se debe seleccionar cuando es un nuevo desarrollo o proyecto, debe coincidir con la

respuesta dada en la evaluación del riesgo.
a) Impacto: Al guardar los cambios de la encuesta de impacto se auto llena éste

campo.
b) Urgencia: Seleccionar la opción de la lista que se ajusta al cambio a presentar.
Fase Aprobación del desarrollo
a) Servicio Afectado: Se debe diligenciar con el proceso al que pertenece el

desarrollo, debe ser el mismo que tiene en la abreviatura del proceso el código de
servicio.
MÓDULO
Mis Aplicaciones Claro::DWH::01_Voz
Mis Aplicaciones Claro::DWH::02_Datos
Mis Aplicaciones Claro::DWH::03_Prepago
Mis Aplicaciones Claro::DWH::04_Mensajería
Mis Aplicaciones Claro::DWH::05_Ventas
Mis Aplicaciones Claro::DWH::06_Clientes
Mis Aplicaciones Claro::DWH::07_Comisiones
Mis Aplicaciones Claro::DWH::08_Hogares
Mis Aplicaciones Claro::DWH::09_Personas
23
GAID
Versión: 5.10 – 20210513
Mis Aplicaciones Claro::DWH::10_Empresas

Mis Aplicaciones Claro::DWH::99_Administración
b) Componentes CI Afectado: se debe diligenciar con el (los) elemento(s) que se

verán involucrados en la implementación del cambio (servidores, bases de datos,
servicios, etc.)
Nota: hacer la búsqueda del CI por *DWH*, en caso de no estar el componente

afectado en la lista, se debe seleccionar Otros y al final de la descripción del cambio
se debe colocar “Componentes CI afectados: y relacionar el o los componentes”.
c) Proveedor: se debe diligenciar con el nombre de la fábrica para la que trabaja el

proveedor. Los ingenieros de Claro deberán seleccionar “Interno – GGI”.
Fase Construcción del cambio
Para realizar el envió a pruebas de calidad de software el cambio debe encontrarse en

esta fase y debe de tener creadas las siguientes tareas:
a) Tarea Ejecución de Paso a Test: Debe ser asignada al Líder de Pruebas, quien se
encargará de cerrarla cuando las pruebas sean finalizadas por la Gerencia de QA.
b) Tarea Ejecución de Rollback en Test: Debe ser asignada al Líder de Pruebas,

quien se encargará de cerrarla cuando las pruebas sean finalizadas por la Gerencia
de QA.
Fase Pruebas del cambio (Aceptación de Usuario)
a) Tarea Aprobación de pruebas: Esta tarea es creada automáticamente por la

herramienta y se asigna a la persona seleccionada en el campo Aprobador de
Pruebas.
La tarea debe ser cerrada por la persona seleccionada en el campo Aprobador de

Pruebas. El correo de solitud de aprobación al área usuaria se debe adjuntar el Acta de
Aprobación de Pruebas enviada por QA y el informe de pruebas de desarrollador.
24
GAID
Versión: 5.10 – 20210513
b) Tarea Validación estándares de desarrollo: El Líder del Cambio debe crear esta
tarea y asignarla al Revisor de Cambios para la respectiva revisión y cierre.
La tarea debe ser creada máximo dos días hábiles antes del comité de cambios antes
de las 9:00 a.m.
Se harán máximo dos revisiones por cambio para un mismo comité, es decir, si el cambio
requiere ser revisado por tercera vez, el revisor de cambios definirá si dispone del tiempo
para realizarla, pero no es su obligación hacerlo.
En caso de requerir una segunda revisión o más se debe crear nuevamente la tarea, si la
tarea fue creada sin realizar los ajustes solicitados completamente o si se pasa a una
tercera revisión, se reportará al Coordinador de GAID para aplicar las penalizaciones
respectivas por calidad en los entregables.
Es responsabilidad del líder del cambio revisar que todos los campos que solicita la Fase
de Preparación CAB se encuentren correctamente diligenciados y coincidan con lo
registrado en los documentos. Lo anterior debido a que la revisión de estándares se hace
en una fase anterior y no puede ser revisado por GAID
Fase Preparación CAB - Comité
a) Presentar en Comité: Seleccionar el comité en el cual presentará el cambio, por lo

general es Comité de Cambios Móvil.
b) Fecha/Hora inicio y fin PaP: Corresponde a la ventana de tiempo requerida para

el paso a producción del cambio, éste tiempo debe incluir el roll back de la actividad
(en caso de requerirse). Dicho horario debe ser aprobado previamente por la
Gerencia de Control de Procesos - GOGE. (Ver ANEXO N° 1)
c) Fecha de evaluación: Es la fecha en la que se valida que la implementación se

llevó a cabo de manera exitosa (al siguiente día), esto sin validar si se ejecuta
correctamente el proceso. En ese momento el operador puede cerrar la tarea de
paso a producción con el respectivo resultado (Exitoso o No Exitoso).
Cuando ésta fecha no se ha vencido NO se debe cerrar la fase de “Implementación cambio”

hasta no estar seguros que el cambio fue Exitoso en Producción.
Cuando la fecha de Evaluación se vence, la fase debe ser cerrada con el resultado de la
implementación, de lo contrario GAID será sancionada y no podrá presentar
cambios ante el comité.
25
GAID
Versión: 5.10 – 20210513
d) Escalar a cambios del negocio: Se debe seleccionar NO
e) Recursos: Se debe seleccionar el grupo GCP_OPER2 que corresponde a los

analistas de la Gerencia de Control de Procesos Informáticos, quienes son los
encargados de realizar la implementación del cambio.
f) Responsable post implementación cambio: Se debe seleccionar el mismo líder

del cambio.
g) Teléfono responsable post implementación cambio: Número de contacto del

Líder del cambio, debe ser un número de celular, NO puede ser extensión
h) Tiempo Contingencia (minutos): Si se requiere indicar cuantos minutos se

requieren de contingencia, de lo contrario dejar en cero. Los tiempos deben coincidir
con lo registrado en tiempo total de Roll Back en el Minutograma.
i) Disponibilidad del Servicio: Seleccionar SI, NO o Intermitencia, según lo requiera

la implementación del cambio.
En caso de NO disponibilidad del servicio y afectar a usuarios externos, debe existir

aprobación de la ventana solicitada por parte del área externa solicitante, y en el
caso que la NO disponibilidad sea sólo en interna (GAID debe existir aprobación del
Gerente de GAID. En el correo se debe especificar el horario y que NO habrá
disponibilidad y el nombre del servicio afectado.
j) Fecha comité de cambios: seleccionar la fecha y hora del TCAB correspondiente.
26
GAID
Versión: 5.10 – 20210513
Fase Auto implementación CAB
a) Tarea Evaluación del Riesgo: Esta tarea se crea automáticamente y es asignada

al grupo evaluador de riesgos GGCS_CAMBIOS para la respectiva evaluación,
quien realizará la evaluación del riesgo junto con toda la documentación requerida,
en caso de no cumplir cerrarán la tarea como No Exitoso y elevarán la categoría
del riesgo.
El grupo GGCS_CAMBIOS sólo hará máximo dos revisiones a un mismo cambio por
comité, es decir, si un cambio requiere una tercera revisión, este NO podrá ser presentado
en el comité en curso, y tendrá que presentarse en el próximo.
Si la evaluación del riesgo fue No exitosa, se debe crear una nueva tarea -Evaluación de
Riesgo- dirigida al grupo GGCS_CAMBIOS donde se encuentre la información faltante y/o
el nivel de aprobación requerido para continuar con el proceso de cambios, si las tareas
son creadas nuevamente sin realizar los ajustes solicitados, el cambio será reportado a la
Gerencia para tomar las acciones correctivas pertinentes.
Nota: La tarea de validación de riesgo debe ser creada antes de las 2 pm del día
anterior al comité en caso de ser cerrada como no exitosa debe crearse nuevamente
la tarea con lo faltante antes de la 6 pm del día anterior al comité (mismo día donde
se entrega el corte al comité)
b) Fecha solicitud usuario: Indicar la fecha en la cual el usuario hizo la solicitud del
cambio, es decir, fecha del BRIEF, del incidente, del problema, etc.
c) Categoría del Riesgo en IT (Pre-Evaluación): Se debe seleccionar si el resultado

del formato de evaluación del riesgo fue Baja, Moderada, Alta, Extrema o si no se
presentó
d) Categoría del Riesgo en IT (Evaluación): El área de cambios de Claro será la

encargará de diligenciar éste campo.
Guardar los cambios y dejarlo en ésta fase con la documentación completa hasta que
pase la hora fin del comité y se notifique si el cambio fue aprobado o no.
Fase Implementación del cambio
a) Tarea Ejecución de paso a producción: Esta tarea debe ser creada y asignada al
Analista de GOGE que realizará la implementación, dicha tarea debe ser cerrada
por el Analista al momento de finalizar la implementación del cambio, no debe
27
GAID
Versión: 5.10 – 20210513
superar la fecha fin de implementación registrada en el cambio, adicionalmente debe

informar por correo a todos los interesados del cambio el resultado y adjuntar la
evidencia. Luego terminar el documento de Implementación y RollBack la
comunicación entre el analista de operaciones y el líder del cambio debe ser
Únicamente a través de GAID.
b) El implementador debe hacer un Backup de cómo estaba el ambiente antes de
Implementar y ubicarlo en la carpeta Backup-RollBack y de cómo quedó después
de implementar en la Carpeta Actualización de Línea base del cambio
correspondiente.
c) Tarea Actualización de Línea Base: Debe ser creada y asignada al Administrador

de versiones, quien se encargará de revisar que la carpeta de Actualización de
Línea Base del Share Point contenga el Backup de todo lo implementado, adicional
a ello se validará que se realice el cierre correspondiente de la Q para cerrar de
manera exitosa la tarea de actualización de Línea Base.
d) Exitoso: Seleccionar la opción SI o NO, según sea el resultado de la ejecución del

proceso. En caso de que después de haberse cerrado el cambio como Exitoso y por
parte de Operaciones sea reportado a BI fallo en la ejecución del proceso se
solicitara a cambios el cambio del estado del cambio a No Exitoso.
e) Acciones de mejora para no exitoso: En caso de seleccionar NO en el campo

Exitoso, se debe diligenciar éste campo con las acciones a realizar para que el
cambio en próximas ocasiones sea Exitoso. Como evidencia se debe adjuntar el
correo del implementador a los interesados y el correo de finalización al usuario
indicando el motivo por el cual el cambio no fue exitoso.
Fase Evaluación y cierre del cambio
Una vez finalizada la fecha de evaluación o seguimiento del cambio, el cambio debe ser
avanzado a ésta fase, de aquí en adelante el grupo de cambios de Claro será en el
cargado de evaluar la documentación final del cambio y de Cerrar el Cambio.
28
GAID
Versión: 5.10 – 20210513
Le evaluación del cambio se compone de tres aspectos:
- Ejecutado exitosamente (10%): Se da cuando el cambio es ejecutado

satisfactoriamente y cumpliendo los tiempos de ejecución, éste resultado es
retroalimentado por el líder del cambio.
- Cumplimiento del proceso de cambios (20%): El cambio cumple con todas las
evidencias y políticas del proceso de cambios, éste resultado es dado por el gestor
de cambios.
- Evaluación del usuario (70%):Si el solicitante del cambio es externo a la

vicepresidencia IT se le realizan las siguiente preguntas:
o ¿Se cumplió el objetivo del cambio?
o ¿Quedo satisfecho con la solución?
o ¿Se le informo de la fecha del paso a producción? (Retroalimentación)
o ¿Se le mantuvo informado durante el proceso de construcción del cambio?
(Retroalimentación)
- Si el cambio cumple con el 100% de la evaluación se determina como cambio
“Exitoso”, de lo contrario se evaluará “No exitoso”
- Si el solicitante del cambio es interno de la Vicepresidencia IT, las preguntas 1 y 2
se evalúan de acuerdo al resultado de la ejecución.
a) Teniendo en cuenta que para realizar la implementación se debe contar con el aval del
gerente de Operaciones, se debe realizar la capacitación mínimo 15 días antes de la
implementación con el fin de realizar la gestión correspondiente al aval del acta de
capacitación y la del gerente del área de Operaciones.
b) Para presentar los cambios al Comité de Cambios deben contener creada la tarea de
Evaluación de Estándares de desarrollo dos (2) días hábiles ANTES del TCAB
(3:00P.M.), de lo contrario GAID no se hará responsable de que el cambio no pase a
comité como exitoso.
29
GAID
Versión: 5.10 – 20210513
c) Para que el cambio quede en el corte del TCAB que realiza el área de cambios este
debe estar ITERADO a la fase Auto Implementación CAB junto con la documentación
completa, debido a que en esta fase se crea automáticamente la tarea de Evaluación
de Riesgos asignada al grupo del Comité de Cambios de Claro, quienes harán la
revisión tan pronto se crea la tarea. (El cambio debe encontrarse en la fase de Auto
Implementación CAB antes de las 11:59 p.m. dos días hábiles anteriores al CAB o TCAB
al cual se va a presentar el cambio, ya que en este momento se realiza el corte oficial
de los cambios por parte del grupo de Cambios).
d) En el caso de no cumplir con la documentación el cambio no será presentado en el
comité.
e) Los horarios del corte de los cambios a presentar a comité y del comité de cambios se
describen a continuación:
Horario Corte Horario TCAB Horario CAB

Lunes 11:59 pm Viernes 2:00 pm - 5:00 pm Martes 2:00 pm - 5:00 pm
Miércoles 11:59 pm Miércoles 10:00 am – 12:00 pm Jueves 2:00 pm - 5:00 pm
En caso de que el día del corte sea festivo el corte será el día hábil anterior al
indicado Para los cambios Emergentes si es posible que el corte sea el mismo día
del comité
f) Toda documentación requerida para la gestión de los cambios debe adjuntarse en

Share Point de GAID de acuerdo a lo definido en la presente política, ver ítem
publicación de documentos.
g) La omisión en la presentación de una evidencia de ejecución de una actividad que haga
parte del control de riesgos (ver formato de evaluación de riesgos IT) eleva la categoría
de riesgo según lo descrito en la Política General de Control de Cambios de Claro.
h) Los correos de aprobación de documentos NO pueden ser reenviados por otra persona,
deben ser los originales aprobados, en caso que el aprobador responda sin los
documentos adjuntos se debe adjuntar el correo que fue enviado por el líder.
i) Ningún cambio normal puede ser implementado sin tener la aprobación previa del
Comité de Cambios, para esto el Líder del Cambio recibe una notificación automática
de MAXIMO o un correo de Cambios VPP donde le informa que el cambio fue aprobado
por el Comité.
j) Los cambios emergentes, primero se ejecutan, luego se documentan y socializan en el
comité más cercano (CAB o TCAB).
30
GAID
Versión: 5.10 – 20210513
14. GLOSARIO
Cambio: Es la adición, modificación o eliminación de un evento o suceso que podría

afectar uno o más servicios de TI.
Configuración: Término usado para describir un grupo de Elementos de Configuración

que actúan o funcionan juntos para proveer un Servicio de TI, o un subconjunto
representativo de un Servicio de TI.
Requerimiento: Nueva funcionalidad, mejoramiento evolutivo o correctivo o cambios a la

funcionalidad existente.
Usuario Solicitante: Registra la solicitud de cambio, verifica los cambios efectuados y

genera la aprobación de acuerdo con las pruebas efectuadas.
Herramienta de Control de Cambios: Software o aplicación que permite realizar gestión

y tener el control de todas las solicitudes de cambios que se realizan en los sistemas de
información.
CI o elemento de configuración: Cualquier componente que necesite ser gestionado

con el objeto de proveer un servicio. La información sobre cada CI se almacena en un
registro de configuración dentro del sistema de gestión de gestión de la configuración y es
mantenido durante todo su ciclo de vida. Los CI pueden ser servicios hardware, software,
Edificios, rack, documentación, licencias, etc.
CMDB: Es la base de datos donde están todos los servidores, bases de datos,
almacenamientos, etc.
TCAB: Comité de Cambios Técnico
CAB: Comité de Cambios Directores Claro
ECAB: Comité de cambios de emergencia
31
GAID
Versión: 5.10 – 20210513
Anexo N. 1
15. PROCESOS ASOCIADOS A CAMBIOS SOX
Los siguientes procesos están asociados a cambios SOX y para su implementación

deben pasar por el proceso de cambios de IT pasando para ello por un TCAB y un
CAB según corresponda y lo especificado anteriormente.
PREPAGO
0001 COLOMBIA 03_PREPAGO MOVIL 0001_PREP_CALL_TICKETS

0002 COLOMBIA 03_PREPAGO MOVIL 0002_PREP_CONF_TICKETS
0030 COLOMBIA 03_PREPAGO MOVIL 0388_PREP_FOTO_PREPAGO
0039 COLOMBIA 03_PREPAGO MOVIL 0039_PREP_CONSOL_CALL_CONF_DCH
0268 COLOMBIA 03_PREPAGO MOVIL 0268_PREP_DATACHARGING
0388 COLOMBIA 03_PREPAGO MOVIL 0388_PREP_TRAFICO_CONSOLIDADO
COMPENSACIÓN
0088 COLOMBIA 01_VOZ MOVIL 0088_VOZ_COMPENSA_INDIVIDUAL

0230 COLOMBIA 01_VOZ MOVIL 0230_VOZ_COMP_NO_DISPONIB_48H
0274 COLOMBIA 06_CLIENTES MOVIL 0274_CLIEN_COMPENSA_FALLA_TERM
TRAFICO (VOZ, MENSAJERIA, DATOS)
0023 COLOMBIA 01_VOZ MOVIL 0023_VOZ_CARGUE CDRS

0111 COLOMBIA 01_VOZ MOVIL 0111_VOZ_LD_CDRS
0080 COLOMBIA 02_DATOS MOVIL 0080_DATOS_CARGUE
0166 COLOMBIA 02_DATOS MOVIL 0166_DATOS_TRAFICO_MEDIADO
0027 COLOMBIA 04_MENSAJERIA MOVIL 0027_SMS_CARGUE_MDRS
0033 COLOMBIA 04_MENSAJERIA MOVIL 0033_SMS_TRAFICO_MEDIADO
0476 COLOMBIA 01_VOZ MOVIL 0476_VOZ_TRAFICO_CONSOLIDADO
DOC1
0232 COLOMBIA 06_CLIENTES MOVIL 0232_CLIEN_PROCESO_DOC1
32
GAID
Versión: 5.10 – 20210513
17. HISTORIAL DE VERSIONES
Ver Elaborado por Fecha Elaboración Aprobado por Fecha Aprobación Comentario
1.0 Paola Triviño 25-02-2014 Carlos Alberto Cely 03-03-2014 Versión inicial del documento
1.1 Paola Triviño 05-03-2014 Carlos Alberto Cely 05-03-2014 Se adiciona ítem 4 – g)
Jhon Jairo Salazar Se adiciona ítem 4 – c)
1.2 Paola Triviño 27-03-2014 27-03-2014
Carlos Alberto Cely Se adiciona ítem 3 – NOTA 1
Se actualizan los enlaces hacia el nuevo Share
Point de la gerencia.
Se actualiza el responsable de la revisión de la
Paola Triviño
1.3 07-11-2014 Carlos Alberto Cely 07-11-2014 documentación del cambio.
Carlos A. Cely
Se actualiza el repositorio donde se debe
almacenar la información del cambio.
Se adicionan los documentos autorización del

1.4 Paola Triviño 27-11-2014 Carlos Alberto Cely 27-11-2014
director y lista de chequeo para todos los cambios.
Se actualiza la política con base en el nuevo
Paola Triviño procedimiento de Gestión de Cambios de la
2.0 31-03-2015 Carlos Alberto Cely 01-04-2015
Carlos A. Cely Compañía.
Se modifica ítem de documentación del cambio, se

incluye el mail de aprobación del área de procesos.
Se realizan aclaraciones al ítem de tareas de los
cambios y documentación de los cambios.
Se incluye paso a paso del registro del cambio en
MAXIMO, se hace claridad en las tareas a crear.
Se hace claridad en la estructura de las carpetas en
3.2 Paola Triviño 24-11-2015 Carlos Alberto Cely 24-11-2015 el Share Point, y en algunas aclaraciones dadas en
el Comité de Cambios.
Se incluyen responsables de las actividades de
gestión de autorizaciones área financiera y
evaluación de riesgos. Se aclaran algunas
preguntas de la evaluación de riesgo.
Se incluye política para la fase de implementación,
documentación 48 horas antes.
Carpeta de implementación
Actualización de documentos en formatos nuevos.
3.4.1 Paola Triviño 16-03-2016 Carlos Alberto Cely 16-03-2016 Se modifican los nombres de los líderes del proceso
Jair Campos Se incluye el procedimiento para la solicitud de
3.5 Paola Triviño 23-03-2016 Sindy Reyes 23-03-2016 agenda para PaP y capacitación a GCPI
Jose Alfonso
Se hacen algunas aclaraciones en algunos ítems y
3.6 Paola Triviño 29-03-2016 Carlos Alberto Cely 29-03-2016 se mueve de fase las tareas de Estándares de
Desarrollo.
3.7 Paola Triviño 20-04-2016 Carlos Alberto Cely 20-04-2016 Se hace claridad en algunos ítems.
Se incluye anexo de transición de cambios.
Se mueven de fase las tareas de solicitud de línea
Carlos Alberto Cely
3.8 Paola Triviño 06-05-2016 06-05-2016 base, Implementación y Rollback en test en las
Jose Alfonso
fases donde estaban no estaba la opción de
crearlas.
Se incluye el límite de revisiones por cambio del
grupo de cambios.
Se incluye que en MAXIMO solo se debe adjuntar
las evidencias que pide la evaluación del riesgo,
Se incluye la tarea de Integración.
Se modifica el aprobador del acta de capacitación.
Carlos Alberto Cely Se incluye el rol Revisor de Cambios.
4.1 Paola Triviño 01-06-2016 01-06-2016
Jose Alfonso
Jose Luis Fajardo Se incluyen los roles Líder de Pruebas y Analista de
Carlos Alberto Cely Pruebas y el proceso de pruebas de sistema.
4.2 Paola Triviño 27-06-2016 27-06-2016
Jhon Jairo Salazar
Jose Luis Alfonso
Carlos Alberto Cely Se realizan algunas aclaraciones al proceso de
4.3 Paola Triviño 12-07-2016 12-07-2016
Jhon Jairo Salazar prueba de sistema.
33
GAID
Versión: 5.10 – 20210513
Jose Luis Fajardo Se hace claridad en algunos puntos de pruebas y

4.4 Paola Triviño 29-08-2016 Carlos Alberto Cely 29-08-2016 de validación de estándares de desarrollo.
Jhon Jairo Salazar
Se incluyen cambios resaltados en rojo.
Jose Luis Fajardo Se mueve de fase la capacitación al usuario.
4.5 Paola Triviño 29-09-2016 Carlos Alberto Cely 04-10-2016 Se pasa como anexo el procedimiento de agendar
Jhon Jairo Salazar la capacitación e implementación.
Se incluye tarea para reagendamiento de Cambios
Jose Luis Fajardo
Carlos Alberto Cely Se realizan aclaraciones al proceso.
4.6 Paola Triviño 24-01-2017 24-01-2017
Jhon Jairo Salazar Se incluyen políticas para la operación fija.
Rafael Soto
Se incluye aclaración anexo 2 cambios
Jose Luis Fajardo
Se modifican responsables de roles
Se modifica el proceso de Pruebas Funcionales
Jhon Jairo Salazar
Se hacen aclaraciones varias.
Se modifican responsables de roles
Se ajusta el proceso de pruebas funcionales.
4.9 Zulay Viloria 31-05-2017 Jhon Jairo Salazar 02-06-2017 Se realiza aclaraciones para el proceso de paso a
comité.
Se incluyen cambios resaltados en rojo.
Se ajusta horario de comité de cambios
Se ajusta procedimiento de agendamiento
5.0 Diana Triviño 31-07-2017 Jhon Jairo Salazar 01-08-2017
Todos los cambios se encuentran resaltados en
rojo.
Se ajusta horario de corte del comité de cambios
Se ajusta la tarea de solicitud de línea base
Se ajusta el ejecutor de la tarea de actualización de
línea base
5.1 Diana Triviño 19-09-2017 Jhon Jairo Salazar 19-09-2017
Se ajusta procedimiento de agendamiento
Aprobación del Minutograma(FIJA)
Todos los cambios se encuentran resaltados en
rojo.
Jhon Jairo Salazar / Se realiza ajustes al proceso, los ajustes se
5.2 Zulay Viloria 15/01/2018 Carlos Alberto Cely / 12/02/2018 encuentran en color rojo.
Paola Triviño
Se ajusta horario de corte del comité de cambios
Se agrega acta TCAB
Laura Camila
5.3 8/06/2018 Maryory Cuesta 15/06/2018 Se ajusta documento Riesgo IT
Solaque
Se realiza aclaraciones para el proceso de paso a
comité. Los ajustes se encuentran en color rojo.
Natalia Hernández Se ajusta la política de cambios de acuerdo al
5.4 24/04/2019 Jhon Jairo Salazar 25/04/2019
Maryory Cuesta nuevo proceso establecido por la GAID.
Se ajusta fase de planeación del cambio – Tarea
5.5 Natalia Hernández 29/05/2019 Carlos Alberto Cely 29/05/2019 Solicitud de Línea Base en ODI. - Pag 20
Se ajusta Hora máxima de agendamiento y correo
5.6 Jehimmy López 31/07/2019 Jhon Jairo Salazar 02/08/2019 de cancelación – Pag 5
*Aclaración sobre Modificación de Matriz POR
EJECUTAR Pag.5 (Agendamiento).
*Agendamiento y vigencia de Capacitaciones.
Pag.6
*Tiempo mínimo para Cancelación de
Implementaciones. Pag.6
*Cancelación de panorama de entrega a QA. Pag.7
*Integrantes equipo de Arquitectura. Pag.7
*Solicitud Aval para implementar en ambiente de
5.7 Jehimmy López 27/11/2019 Jhon Jairo Salazar 03/12/2019 preproducción – Formato. Pag.8
*Cambio nombre Proveedor de Pruebas. Antes
Choucair - Ahora SQA e INDRA. Todas las Pag.
del Documento.
*POLITICAS IMPLEMENTACIONES ODI Pag.11
* Cambio nombre de herramienta 123 MIC por
MAXIMO para TCAB.Todas las Pag. Del
Documento.
*Solicitud de Líneas Base Pag.20 y 21.
34
GAID
Versión: 5.10 – 20210513
*Aclaración de Implementaciones en ODI para

5.7 Jehimmy López 16/12/2019 Jhon Jairo Salazar 16/12/2019 ambientes Productivos y Preproductivos. Pag. 11
*3.1 SOLICITUD DE CODIGO DE SERVICIO.
5.8 Jehimmy López 31/12/2019 Jhon Jairo Salazar 31/12/2019 Pag. 4
*Aclaración envió de citaciones para

capacitaciones e implementaciones. Pag. 7
* Se elimina el paso de creación casos a Oracle
para acompañamiento en implementaciones.
* Para cancelación de capacitaciones e
implementaciones se crea plantilla de correo. Pag.
8
* Aval para Preproductivos – Registro en
SharePoint pag. 9
* Para aval de PAP - El Informe de Pruebas de
Desarrollador debe contener (log de ejecución del
5.9 Jehimmy López 21/08/2020 Jhon Jairo Salazar 31/08/2020
proceso, cantidad de datos cargados y tiempos de
ejecución “óptimos”).
* PRUEBAS DE CALIDAD DE SOFTWARE Desde
Junio 2020 la Gerencia GAID no pasa por la
Gerencia de QA Claro, únicamente Req de IT. Pag
12
* Se incluyen rutas para descarga de Manuales
MAXIMO, caso de pasar por el TCAB de IT. Pag
15
*Solicitud de Líneas Base Pag.20 y 21 – Formato
de SharePoint.
*Registro de Hoja de vida Productos de Información
* Generalidades para pasar al comité de
Arquitectura.
5.10 Jehimmy López 13/05/2021 Jhon Jairo Salazar 13/05/2021 * Generalidades para capacitaciones
* Aclaración para Actualización de LB
* Aclaraciones al proceso de pruebas de Calidad
de Software.
35

GAID POL Gestión de Cambios v5.10

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

GAID POL Gestión de Cambios v5.10

Cargado por

Copyright:

Formatos disponibles

Gerencia Arquitectura e Ingeniería de Datos

POLITICA GESTIÓN DE CAMBIOS

POLITICA GESTIÓN DE CAMBIOS

2. ROLES PROCESO DE CAMBIOS

Nombre del Rol Definición Procesos Nombre del

3. GENERALIDADES PROCESO DE CAMBIOS

a. La gerencia maneja los siguientes tipos de implementaciones:

3.1 SOLICITUD DE CODIGO DE SERVICIO

Ruta: 01_Administrativo/ 01 – Información General/ 07 – Catálogo de Servicios

Ruta: 01_Administrativo/ 01 – Información General/05 – Formatos Documentación/Cambios/EPIC-

Formato establecido (SharePoint):

Solicitud código de servicio

No requerimiento IT. BRIEF-XXX

VOZ / DATOS /PREPAGO / MENSAJERIA / VENTA / CLIENTES /

Relacione una opción según corresponda

<Tipo de entregable, qué contiene, periodicidad, volumetría

Entregables: <Cubo, Reporte Cognos, Tabla, ETL, Tablero Avanza, etc.>

Nombre de los usuarios: <Dos nombres completos de personal directo de Claro

Enviar correo con la solicitud a Monica Duque monica.duque@claro.com.co (Remitente Principal)

3.2 SOLICITUD Y ACTUALIZACION DE LINEA BASE:

Registrar la solicitud en el formulario de SharePoint:

Ruta del Formulario:

 Cambiar el estado del registro EN ACTUALIZACION

 Una vez finalice la implementación con resultado EXITOSO, El equipo de

El agendamiento se realiza en la vista POR APROBAR del SharePoint máximo a las 9 am

 La fábrica de desarrollo NO debe diligenciar los campos de la sección de

 Una vez aprobados los registros, el agendamiento se verá reflejado en la vista

 Las Capacitaciones deben celebrarse con mínimo 5 días de anterioridad a la

 Las Capacitaciones que sean exitosas tienen una vigencia de 90 días (3

 La citación (Reunión Microsoft Teams o ZOOM) para las capacitaciones e

4.1.1 CANCELACIÓN DE REGISTROS APROBADOS EN LA MATRIZ DE IMPLEMENTACIÓN:

Para cancelar un registro en la matriz POR EJECUTAR (matriz de implementación) en

 El motivo por el cual se cancela dicha implementación argumentando porque

Ruta: /01 - Información General/05 - Formatos Documentación/Cambios/EPIC-XXXX-

Formato establecido (SharePoint):

La finalidad del comité de arquitectura es realizar una presentación de un modelo del

Una vez finalizado el desarrollo se procede con la construcción del documento de

Finalmente, si el documento cumple a cabalidad con los lineamientos establecidos por el

IMPORTANTE: Es indispensable que el documento de arquitectura haya sido

Equipo de Arquitectura GAID

A continuación, se relacionan los horarios del Comité de AQ:

5.1 REQUISITOS Y GENERALIDADES PARA LA PRESENTACIÓN AL COMITÉ DE

6. IMPLEMENTACIÓN AMBIENTE PREPRODUCTIVO

6.1 REQUISITOS IMPLEMENTACIÓN AMBIENTE PREPRODUCTIVO

- Al momento de realizar la aprobación por parte de Alicia Cuesta y Jehimmy López

- En caso de que aparezca otro usuario como último actualizador no se aprobará la

- Adjuntar en Share Point con 24 horas de anticipación a la implementación los

6.2 Observaciones y Generalidades:

 La corrección de las fallas reportadas por GOGE deben ser acordadas y

 El Ingeniero de Desarrollo debe liderar la capacitación al Analista de la GOGE sobre

 Adjuntar en Share Point con 24 horas de anticipación a la capacitación los

8. IMPLEMENTACIÓN AMBIENTE PRODUCTIVO

Todas las implementaciones productivas deben de haber realizado una

8.1 REQUISITOS IMPLEMENTACIÓN AMBIENTE PRODUCTIVO

 Contar con la fecha de implementación aprobada por parte del equipo de

 Adjuntar en Share Point con 24 horas de anticipación a la implementación los

o FSP (si aplica).

Únicamente para GAI (Aseguramiento de Ingresos) se debe verificar lo siguiente:

• Manual Técnico y de usuario

 Al finalizar la implementación se debe enviar al usuario el correo de “Fin de la

Al obtener la aprobación de la ventana de Implementación es necesario solicitar el AVAL

En el correo de solicitud de AVAL de PAP adjuntar:

 Aval de Arquitectura *Correo. (Documentos Arquitectura y Diseño).

10. PRUEBAS DE CALIDAD DE SOFTWARE

Nota: hacer la búsqueda del CI por DWH, en caso de no estar el componente