5.3 Solicitud de paso a producción

1. ALCANCE
Este instructivo cubre las actividades a realizar cuando se enfrenta un evento que puede
afectar el ambiente productivo, ya sea actual o futuro de manera que permita: crear un
calendario de cambios, planear, analizar el impacto los riesgos, establecer un plan de
actividades, medidas alternativas, todo con el fin de mejorar la calidad del servicio.
La entrada para el proceso de Administración de Cambios es una solicitud de cambio
(RFC), un incidente o un reporte de resolución de problemas, la insatisfacción del usuario /
cliente expresada mediante una solicitud de servicio (Servicenter), una actualización
propuesta para algunos componentes de la infraestructura, o incluso cambio de ubicación
de un sistema de información.
2. BENEFICIOS

Reducción de Riesgo
El control y Administración de un cambio minimiza el riesgo de resultados inesperados debido a la
introducción de un cambio al ambiente de producción.

Reducción de Costos
Mantener los registros de los cambios contribuye a la mejora continua de los procesos operacionales en el
ambiente de producción, y agiliza la resolución de los problemas relacionados con los cambios.

Mejora de la agilidad en el servicio
Los procedimientos estructurados en la implementación de los cambios le permiten a las organizaciones
alinearse rápida y efectivamente a los cambiantes requerimientos del negocio.

Mejora en la Calidad de los servicios
Una apropiada evaluación de impacto de los cambios previene caídas del servicio no planeadas, en
consecuencia se incrementa la calidad de los servicios.
3. GLOSARIO
Cambio: cualquier nuevo componente de IT introducido en el ambiente que pueda afectar
el nivel de servicio, la funcionalidad del ambiente o uno de sus componentes.
Solicitud de cambio: requerimiento formal que incluye: descripción, componentes
afectados, necesidades del negocio, impacto, evaluación de riesgos, requerimiento de
recursos, estado de aprobación.
Comité de administración de cambios: grupo interdisciplinario que evalúa las
solicitudes de cambio, de acuerdo a las necesidades del negocio, prioridades, relación
costo/beneficio e impacto potencial en otros sistemas o procesos
1
DIM: Grupo encargado de distribuir herramientas de software a las diferentes
áreas de la empresa.
DBA: Administrador de base de datos, es el encargado de compilar paquetes en el
ambiente productivo, asignar permisos y monitorear el desempeño de la base de datos,
entre otros.
Línea base: Especificación o producto revisado formalmente que sirve como base para
un desarrollo posterior. Sólo puede cambiarse siguiendo una serie de procedimientos
formales de control de cambios.
Hallazgo: situación detectada durante la ejecución de un plan de pruebas que puede
generar un posible cambio en un sistema.
Item de configuración (IC): Es un componente físico o lógico de la infraestructura de
GSPI, el cual está bajo control de la Administración de Configuraciones. Un IC puede
variar ampliamente en cuanto a su complejidad, tamaño y tipo, desde un sistema completo
(Incluyendo todo el hardware, software y documentación) hasta un simple módulo de un
programa, componente menor de hardware o un documento y sus versiones.
ITIL: Information Technology Infrastructure Library. Marco de referencia para la
administración de la infraestructura de IT.
Requerimiento de cambio (RFC): Request For Change, Es un formato electrónico o en
papel que permite registrar los detalles de una petición de cambio para cualquier
componente de la infraestructura de IT o cualquier aspecto de los servicios de ETB Informática.
4. RESPONSABLES
Los roles de los encargados de realizar las actividades relacionadas con administración de
cambios y configuraciones se pueden apreciar de manera general en la siguiente gráfica
Pág. 2 de 9
y sus responsabilidades se describen a continuación:
Roles
Solicitante del cambio
Coordinador aplicaciones







Responsable del cambio









Responsabilidades
Proponer el cambio
Proveer retroalimentación un vez implantado el cambio
Asignan a los responsables de los cambios
Asignan o distribuyen las actividades relacionadas con
los cambios
Coordinar las fases de desarrollo del proyecto
Informa el estado o evolución de los cambios
Participa del comité de cambios aportando su
conocimiento del negocio para establecer el impacto de
los cambios
Presenta la solicitud de cambios
Planea los cambios aprobados
Analizar los riesgos involucrados, planear las
contingencias para mitigarlos
Informa el estado o evolución de los cambios
Cumplir con los requisitos del comité
Preparar y liderar la verificación post-implantación
Probar que luego del cambio todo funcione
correctamente
Identificar problemas presentados e informarlos al
comité
Responsable de las actividades de reversión en caso de
Pág. 3 de 9
Líder del comité de cambios







Comité de cambios







ser necesario
Recibe los requerimientos de cambio
Lidera la reunión del comité de cambios
Prepara la agenda de la reunión
Conduce el análisis del impacto y evaluación de riesgos
Notifica aprobaciones o rechazos
Mantenimiento y mejoramiento de la administración de
cambios
Monitorear la evolución de las actividades relacionadas
con la administración de cambios
Analizar, priorizar, clasificar y programar los cambios
Aprobar, aplazar o rechazar los cambios
Seguimiento al estado de los cambios
Revisar el estado de los cambios de emergencia
Comunicar el estado de los cambios a la gerencia
Determinar la forma correcta de evaluar los problemas
Evaluar el progreso de los cambios aprobados
5. DESCRIPCION DE ACTIVIDADES
A continuación se describen las actividades necesarias para realizar un cambio
5.1 Generación de línea base:
Una vez terminado el desarrollo se debe generar una línea base para pruebas, para esto
deberá hacerse una solicitud al coordinador de paso a producción indicándole que items
conformarán la línea base.
5.2 Pruebas del sistema:
Las pruebas deben realizarse sobre la línea base diseñada para tal fin, la cual debe ser
generada antes de solicitar el paso a producción. En caso de evidenciar hallazgos durante
las pruebas, el desarrollador debe ser informado para que realice los ajustes necesarios.
Si el resultado de las pruebas es satisfactorio, se aprueba la línea base para
posteriormente solicitar su paso a producción.
5.3 Solicitud de paso a producción
Esta solicitud se hace a través del formato de solicitud de cambio donde se debe
especificar lo siguiente:




Fecha de solicitud
Tipo de cambio
Título del cambio
Descripción
Pág. 4 de 9









Justificación, razón y beneficios del cambio.
Impacto del cambio, riesgos identificados.
Impacto si no se efectúa.
Solución alterna
Impacto en el servicio
Recuperabilidad a fallas
Usuarios afectados
Prioridad sugerida.
Plan de trabajo donde se especifica fecha, hora, tarea a realizar, fuentes a compilar,
formas a distribuir, responsable y comentarios.
Los tipos de cambio se detallan a continuación:
Tipo de Cambio
Descripción
Requerimiento de
Se requiere una nueva funcionalidad para un servicio
negocio
existente o un nuevo servicio, con la justificación de
negocio correspondiente, generalmente corresponde a
solicitudes de nuevas funcionalidad por parte de los
gerentes de producto.
Incidente/problema El cambio tiene como objetivo implantar una solución
temporal o eliminar la causa raíz de algún problema
detectado o incidente reportado.
Legislación
Cambios en la legislación y normativas obligan a
adaptar uno o varios CIs de un servicio.
Cambio por
El producto/servicio de terceras partes ha cambiado de
terceras partes
características o composición, lo que requiere de una
adaptación de la infraestructura (ej cambio a causa de
otro cambio)
5.4 Evaluación del paso a producción realizada por el comité
El comité evalúa la información registrada en el formato de solicitud de cambio verificando
la adecuada planeación del mismo, identificando riesgos que hasta el momento no habían
sido reconocidos y determinando el impacto del cambio
8.4.1. Impacto
Está directamente relacionado con el servicio que reciben los Clientes/Usuarios, es decir,
como afectará la implantación de un cambio el servicio que reciben los mismos. Además,
está expresado en función de la complejidad técnica requerida para la ejecución del
cambio.
A continuación se definen los niveles de impacto que puede tener un cambio:
Impacto Criterio
Alto
Se considera que el nivel del impacto es alto, cuando se trata de un
servicio crítico o “core” del negocio, cuando tenga complejidad
técnica mediana o mayor, o cuando el cambio afecte a más de 500
usuarios, o cuando las implicaciones legales o financieras criticas
Pág. 5 de 9
Medio
Bajo
El impacto del cambio se considera como moderado cuando requiere
de un nivel significativo de recursos para su construcción, o cuando
el número de clientes afectados esté entre 100 y 500.
Se dice que el cambio tiene bajo impacto, o impacto menor, cuando
su implementación es sencilla o posee baja complejidad técnica, por
lo tanto no impacta el servicio.
8.4.2. Prioridad
Secuencia en la que un cambio debe implantarse, teniendo en cuenta la urgencia con que
será atendido. A continuación se definen los distintos tipos de prioridades, que aplican
tanto para la solicitud como para la aceptación del mismo:
Prioridad
Urgencia
Alta
Media
Baja
Definición
Se dice que el cambio es urgente, cuando se busca evitar o
solucionar la pérdida del servicio. Este tipo de cambios
deben ser implementados inmediatamente a fin de corregir
un problema que afecte seriamente la disponibilidad de un
servicio crítico.
El cambio tiene una prioridad alta, si busca evitar que se
afecte severamente la disponibilidad del servicio, o cuando
corresponde a una necesidad imperiosa del negocio.
Se habla de prioridad media cuando los cambios son
requeridos para adicionar funcionalidades, o modificar
contenidos, es decir no afectan en gran manera el servicio,
pero esto no implica que se puedan postergar.
Se le da prioridad baja a los cambios que pueden esperar por
su implantación, debido a que no esta dirigido a corregir
algún problema. Se define como un cambio justificado que
puede esperar al siguiente calendario de actualización
(siguiente “release”).
-Como resultado de la evaluación de estas variables se puede obtener la aprobación o no
del paso a producción lo cual implica registrar en el formato de solicitud de cambio la
decisión tomada y la información correspondiente a las causas por las cuales se tomo la
decisión de no aprobar el paso a producción.
-Si el comité decide aplazar el paso a producción debe registrar la decisión en el formato
de solicitud de cambio y el desarrollador debe solicitar nuevamente el paso a producción
una vez se hallan cumplido las observaciones hechas por el comité.
-Si el comité aprueba el paso a producción se debe registrar la decisión tomada en el
formato de solicitud de cambio e informar de la aceptación de la línea base para
producción.
5.5 Actualización de repositorio en producción
El coordinador exporta del repositorio de desarrollo los ítems autorizados por el comité al
repositorio de producción.
Pág. 6 de 9
5.6 Compilación DBA-DIM:
El coordinador de paso a producción envía a los dbas los IC autorizados para que estos
los compilen en producción, en caso de necesitar distribuir alguna forma esta se enviará al
DIM, los dbas y el DIM solo realizarán las acciones solicitadas por los coordinadores de
paso a producción.
5.7 Probar el cambio:
El responsable del cambio es el encargado de revisar que los cambios aplicados
funcionen adecuadamente y que las aplicaciones que pudieren verse afectadas continúen
funcionando adecuadamente, para esto deberá probar, inmediatamente después de la
compilación el éxito del cambio.
Se puede presentar que la aplicación no funcione correctamente en caso de ser así se
debe realizar Reversión del cambio.
El responsable del cambio deberá informar al comité de los resultados del mismo.
5.8 Seguimiento del cambio:
Dentro del formato de solicitud de cambio se manejan los siguientes campos de
información para realizar el seguimiento del cambio:
-Resultados obtenidos
-Cumplimiento de cronograma
-Registro sobre la acción de reversar el cambio.
5.9 Reversión del cambio:
Si al probar el cambio este no fue exitoso se debe realizar la reversión del cambio
actividad que consta de los siguientes pasos:
5.9.1 Solicitud de cargar línea base anterior:
Esta solicitud se realiza al coordinador de paso a producción.
5.9.2 Descartar línea base nueva y activar la anterior
El coordinador de paso a producción cambiará el estado de la línea base en la
herramienta al estado de rechazada y activará la línea base anterior
5.9.3 Compilación DBA y DIM:
Envía los DBA los ítems a compilar o al DIM las formas a distribuir.
5.9.4 Probar la reversión del cambio:
Se debe revisar que la aplicación funcione y si puede tener implicaciones sobre otras
aplicaciones debe probarse que estas continúen con su operación normal.
Si la reversión fue exitosa se debe informar al comité y presentar una nueva solicitud
cuando se desee volver a realizar el cambio.
Si la reversión no es exitosa se debe documentar las posibles causas, escalar al
comité y al proveedor con el fin de encontrar una solución el comité deberá
permanecer enterado y apoyar la solución del problema.
Pág. 7 de 9
5.10
ORIGEN DE LA INFORMACIÓN
La información se obtiene a través del formato de solicitud de cambio el cual registra:
 Descripción del cambio:
Aplicación, producto, titulo del cambio, descripción, justificación, impacto del cambio e
impacto del cambio sino se realizara, solución alterna y una evaluación de los
siguientes ítems:
o Impacto en el servicio (en horas), recuperabilidad de fallas (en horas),
usuarios afectados, prioridad sugerida.

Plan de trabajo:
Tareas a Realizar con fecha y hora, Fuentes a compilar incluyendo la versión del ITEM
que debe tomarse del repositorio de desarrollo, formas a distribuir, responsable y fecha de
realización.
5.11
DESTINO DE LA INFORMACIÓN
La información suministrada se utiliza para realizar la evaluación por parte del comité
de administración de cambio y de igual forma realizar el seguimiento correspondiente.

Evaluación:
Observaciones (¿requiere mas detalle?, ¿mejor control de riesgos?, planeación, etc.):
Resultados / Recomendaciones: (fue o no exitoso, lecciones aprendidas)
Impacto, Prioridad, Aprobado.
Cumplió cronograma, seguimiento fue necesario revertir el cambio.
5.12
PERIODICIDAD
El comité de cambios se reúne los miércoles a las 2:00 pm, hora en la cual debe
contarse con las solicitudes a evaluar, RFC recibidos después de esta hora no serán
tenidos en cuenta.
Compilaciones: se realizan los jueves después de las 7:00 pm teniendo en cuenta las
observaciones realizadas por el comité.
Los cambios urgentes serán aprobados vía telefónica por al menos dos de los
coordinadores de cambio del comité, y se aprobarán de acuerdo a su impacto, de ser
aprobados estos pueden generar una compilación de urgencia de acuerdo con las
observaciones de las personas del comité que aprobaron su realización, igualmente
debe presentarse el formato diligenciado en el próximo comité.
5.12.1 Estadísticos
Pág. 8 de 9
Id.
Estadísticos de
gestión
Definición
Frecuencia
Unidad
1
Tipificación de
cambio por área
Determina el número de los diferentes tipos de cambio por área:
cuantos se presentaron por solicitud del negocio (nuevo
desarrollo o modificación), debido a un problema, debido a
cambios de terceros (consecuencia de otros cambios) o
corresponden a una mejora detectada internamente
Mensual
# por semana
2
Cambios urgentes
Cantidad de cambios que no pasaron por aprobación en reunión
de cambio (por área)
Mensual
# por semana
3
Tipificación de
cambio por área
Numero de cambios por cada prioridad presentados por semana
Mensual
# por semana
4
Cumplimiento del
tiempo planeado
Numero de cambios que cumplieron con los tiempos
programados clasificados por área y prioridad
Mensual
# por semana
5
Cantidad de
cambios
reversados
Numero de cambios que no lograron entregarse en producción y
fue necesario volver a la versión original por área y prioridad
Mensual
# por semana
6. DOCUMENTACIÓN DE REFERENCIA
Pág. 9 de 9