El documento presentado, busca servir de ayuda para los primeros pasos del aprendizaje de BPM. Este documento está enfocado en el análisis y mejora a un proceso en una empresa desarrolladora de aplicaciones web, utilizando la disciplina Business Process Management para confeccionar un modelo de procesos con un modelo AS IS y TO BE.

1. Control de Cambios Análisis BPM
Integrantes:
Francisco González Millán
Margarita Barros Escalona
Profesor:
Salvador Gandulfo
Curso:
Introducción a Business Process Management
Diplomado Gestión de Proyectos TI Usach
2014

2. TABLA DE CONTENIDOS
1.
Introducción ............................................................................................................... 3
2.
Declaración del Problema ......................................................................................... 3
3.
Roles ......................................................................................................................... 3
4.
Descripción del Proceso ........................................................................................... 4
5.
Como Inicia el Proceso ............................................................................................. 4
6.
Como Termina el Proceso ........................................................................................ 4
7.
Diagrama de Procesos Control de Cambio - AS IS .................................................. 5
8.
Tareas del Proceso Control de Cambio - AS IS ........................................................ 5
9.
Diagrama de Procesos Control de Cambio - TO BE ................................................. 7
10.
Tareas del Proceso Control de Cambio - TO BE .................................................... 8
11.
Diagrama de Sub Proceso CAB – TO BE ............................................................. 10
12.
Tareas del Sub Proceso CAB – TO BE ................................................................ 10
13.
Implementación de Mejores Practicas .................................................................. 11
14.
Conclusión ............................................................................................................ 12
15.
Diccionario de Términos ....................................................................................... 12
2

3. 3
1. Introducción
Este documento está enfocado en el análisis y mejora a un proceso en una empresa
desarrolladora de aplicaciones web, utilizando la disciplina Business Process
Management para confeccionar un modelo de procesos con un modelo AS IS y TO BE.
2. Declaración del Problema
Elegimos como proceso a analizar el paso a producción de componentes, porque
encontramos aquí una oportunidad de mejora con la cual podemos aportar con esta
tarea.
Actualmente los desarrolladores son responsables de realizar las instalaciones en
producción, sin un procedimiento estándar y con un alto riesgo de equivocaciones. El
proceso propuesto tiene como objetivo definir pasos de manera de que sea una
actividad estandarizada y controlada, que nos permita reducir el posible impacto
negativo ante la necesidad de realizar cambios en ambientes productivos.
3. Roles
Grupo Rol
Usuario
Cliente Empresa quien solicita los cambios
Jefe de Proyectos
Responsable de la evaluación e implementación de los
cambios

4. 4
Desarrollador Ejecutor de los cambios solicitados.
QA Encargado de validar los cambios con pruebas de calidad
4. Descripción del Proceso
Nombre Control de Cambio
Descripción Este proceso establece los pasos y validaciones que deben realizarse
durante el paso a producción con el fin de minimizar los impactos
negativos sobre el ambiente productivo.
5. Como Inicia el Proceso
El proceso inicia con la necesidad de pasar un componente o programa a un ambiente
productivo.
6. Como Termina el Proceso
El proceso termina cuando el cliente aprueba la instalación de la solicitud.

5. 5
7. Diagrama de Procesos Control de Cambio - AS IS
El siguiente diagrama es un modelo construido con la herramienta CASE Bizagi.
8. Tareas del Proceso Control de Cambio - AS IS
Tarea Descripción
Solicitud de
instalación
Jefe de proyecto envía un mensaje de solicitud
indicando el paso a producción.
Instalación Desarrolladores despliegue de la instalación en
ambiente productivo.

6. 6
Pruebas Jefe de proyecto verifica los cambios y los aprueba.
Pruebas
Aceptación
Usuario verifica los cambios y da visto bueno
aprobado.
Rollback El equipo de desarrollo regresar el ambiente a la
configuración anterior, dejando sin efecto el pasaje a
producción.

7. 7
9. Diagrama de Procesos Control de Cambio - TO BE
El siguiente diagrama es un modelo construido con la herramienta CASE Bizagi.

8. 8
10. Tareas del Proceso Control de Cambio - TO BE
Tarea Descripción
Ingreso RFC Registro del documento de paso a paso a producción.
Revisar y Completar RFC Revisar que este completo y consistente
Reunión técnica Esta reunión tiene como objetivo analizar desde el punto
de vista técnico los cambios solicitados y evaluar su
impacto técnico sobre el ambiente productivo
Reunión Cab Se presenta al comité ( integrado por las áreas de
plataforma, administradores de Servidores, soporte , QA,
desarrollo ) que tiene como objetivo analizar las solicitudes
de cambio en ambiente productivo , en base a los
antecedentes presentados y previamente revisados en la
reunión técnica.
Pruebas QA Realizar pruebas ruta crítica y desarrollos instalados
Cancela RFC Si el RFC no cumple con los requisitos como haber
realizado las pruebas, haber informado el cambio , o el
riesgo de implementar es mayor No se aplica el cambio , y
parte de cero con otro solicitud
Pruebas Usuario El usuario realiza pruebas de usabilidad
Ejecución Cambio
Aprobado
Se aplica el RFC en los servidores indicados

9. 9
Rollback El Rollback consiste en una serie de actividades que
permiten regresar el ambiente a la configuración anterior,
dejando sin efecto el pasaje a Producción
Cierre de RFC Se confirma a los equipos que participan en el proceso que
finalizo

10. 10
11. Diagrama de Sub Proceso CAB – TO BE
12. Tareas del Sub Proceso CAB – TO BE
Tarea Descripción
Lista RFC Semanal
El comité genera la lista de RFC de la semana y que pasaron
por reunión Técnica
Análisis RFC Se revisan cada uno de los RFC cumplen con la
documentación y pasos necesarios para la instalación como

11. 11
las pruebas y aprobación del usuario , análisis de Impacto,
comunicación de cambios
Presentación del RFC
Se solicita al Jefe de Proyecto a cargo de la aplicación que
será modificada que explique y justifique el cambio
Planificación
Instalación
Se planifican los recursos involucrados en las instalaciones de
la semana
Observaciones del
RFC
Se envía un informe de los temas levantados de los RFC que
se rechazaron
13. Implementación de Mejores Practicas
En la implementación del diagrama de procesos TO-BE se incorporaron buenas
prácticas recomendadas por ITIL para el control cambios, las recomendaciones de ITIL
son:
Se utilizan métodos y procedimientos estándar.
• Todos los cambios se registran en la Base de Datos de Gestión de la Configuración.
• Se tienen en cuenta los riesgos para el negocio.
• Planificación y gestión de cambios
• Planificación de versiones
• Comunicación
• Autorización de cambios
• Definición de planes de recuperación
• Generación de informes

12. 12
• Evaluación de impacto
• Mejora continua
14. Conclusión
Se debe definir métricas para evaluar los errores y buscar el origen que se presentan
posterior a la instalación de un CC, con el objetivo de implementar la mejora continua
aplicando buenas practicas de ITIL.
15. Diccionario de Términos
Solicitud de Cambio - RFC
La Solicitud de Cambio (Request for Change, RFC) es una requisición formal de
Cambio en espera de ser implementada. Incluye detalles del Cambio propuesto, y
puede estar en formato electrónico o en papel. Las siglas (en inglés) RFC a menudo se
usan equivocadamente para referirse al Registro de Cambio o al Cambio mismo.
Consejo Consultor para Cambios (CAB)
Se trata de un grupo de personas que aconseja al Gestor de Cambios en la evaluación,
establecimiento de prioridades y programación de cambios.
El Consejo Consultor para Cambios (Change Advisory Board, CAB) se compone de
representantes de todas las áreas de la organización de TI, la empresa, y terceros
como, por ejemplo, suministradores.