Conozca la importancia, políticas y buenas prácticas de la gestión de cambios.

1. Gestión de Cambios
Javier Amil
Argentina / Mayo / 2011

2. …………
Meta
El objetivo primordial de la Gestión de Cambios es que se realicen e
implementen adecuadamente todos los cambios necesarios en la
infraestructura y servicios TI garantizando el seguimiento de procedimientos
estándar.

3. Responsabilidades
La Gestión de Cambios debe asegurar que los cambios:
• Están justificados.
• Se llevan a cabo sin perjuicio de la calidad del servicio TI.
• Están convenientemente registrados, clasificados y documentados.
• Han sido cuidadosamente testeados en un entorno de prueba.
• Se ven reflejados en la CMDB.
• Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en
caso de un incorrecto funcionamiento tras su implementación.
• Revisar y cerrar los RFC (Requests For Change)
• Convocar reuniones del CAB, excepto en el caso de cambios menores, para la
aprobación de las RFCs y la elaboración del FSC.
• Coordinar el desarrollo e implementación del cambio.
• Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.
© Aranda Software

4. Tipos de Cambio
• CAMBIOS BASICOS:
 Prioridad basado en el IMPACTO+URGENCIA (alta, media, baja…urgente)
 Categoría basado en el IMPACTO EN EL NEGOCIO (menor,
significante,mayor)
•CAMBIOS URGENTES (cambio que necesita ser implementado lo mas pronto
posible)
•CAMBIOS ESTANDAR (una solución aceptada, identificable y relativamente
común)
© Aranda Software

5. Proceso de Control De Cambios (Normal)
Implement change
Change Manager Change Manager Change Manager
using appropriate
Start
Allocates initial priority Decide category and/or Standard Change
Filters requests
use of standard model model
major significant minor
Change Manager Change Manager Change Manager
Approves / rejects and
Circulates RFCs to Board Circulates RFCs to CAB schedules Changes,
members members reports action to CAB
Senior management / board Senior management / board
level level Change Builder
Approve / reject Changes Approve / reject Changes Builds Change, devises
(Financial / Technical / (Financial / Technical / back-out & testing plans
Business) Business)
Change Manager Change Manager Independent tester
Closed
Co-ordinates Change Tests Changes
Change review implementation
© Aranda Software

6. Definición / Objetivos
Change Manager Change Manager Change Manager
Start
Filters requests Allocates initial priority
Calls CAB or CAB / EC
meeting
Change Manager Independent tester Change Builder CAB or CAB / EC
Co-ordinates Change Builds Change, devises
Quickly assesses impact
implementation Urgent testing back-out & testing plans
resources and urgency
Change Manager Change Manager Closed
Ensures records are
brought up to date Review Change
© Aranda Software

7. Principales Similitudes y Diferencias
RFC
Stage 1 • Registro, aceptación, prioridad Urgente?
Stage 2 • Categoría, impacto, evaluación, autorización y
programación.
Stage 3
 Construir
 Testiar
Stage 4
• Implementar SI / NO ? (Backout)
Stage 5 • Revisar, cerrar RFC
© Aranda Software

8. Las 7 R’s de Change Management
• Quien origino (Raised) el cambio?
• Cual es la razón (Reason) o justificación del cambio?
• Cual es el retorno (Return) esperado para este cambio?
• Cuales son los riesgos (Risk) involucrados en el cambio?
• Que recursos (Resources) se requieren para realizar el cambio?
• Quien es el responsable (Responsible) por la construcción, prueba e
implementación del cambio?
• Cual es la relación (Relationship) entre este cambio y otros en
progreso?
© Aranda Software

9. Beneficios
• Se reduce el número de incidentes y problemas potencialmente asociados a todo
cambio.
• Se puede retornar a configuraciones estables de manera sencilla y rápida en caso de
que el cambio tenga un impacto negativo en la estructura TI.
• Se reduce el número de "back-outs" necesarios.
• Los cambios son mejor aceptados y se evitan "tendencias inmovilistas".
• Se evalúan los verdaderos costes asociados al cambio y por lo tanto es más sencillo
valorar el retorno real a la inversión.
• La CMDB está correctamente actualizada, algo imprescindible para la correcta
gestión del resto de procesos TI.
• Se desarrollan procedimientos de cambio estándar que permiten la rápida
actualización de sistemas no críticos.
• Incrementar la visibilidad de cambios para ambos Negocio y staff de soporte.
• Reducir el impacto adverso de los cambios, impacto técnico y evaluación de riesgos.
• Mejorar la productividad de los usuarios a través de minimizar las interrupciones y
proveer alta calidad en el servicio.
• Mejor evaluación de los costos de los cambios propuestos.
© Aranda Software

10. Consideraciones
• CHANGE ADVISORY BOARD (CAB): Evaluación de RFC’s,
reuniones regulares.
• CATEGORIA DEL CAMBIO (Menor, mayor, significante).
•Emergency CAB (ECAB): Es responsable de evaluar el impacto
de cambios urgentes.
• FORWARD SCHEDULE OF CHANGES (FSC).
© Aranda Software

11. Desafíos: Cambios
• Los diferentes departamentos no siempre aceptan la autoridad de
la Gestión de Cambios
• No se siguen los procedimientos establecidos
• No se actualiza correctamente la información sobre los CIs en la
CMDB.
• Falta de conocimiento de los encargados de la Gestión de
Cambios ( no conocen a fondo las actividades, servicios,
Cambios
necesidades y estructura TI ).
• Los Gestores del Cambio no disponen de las herramientas
adecuadas de software para monitorizar y documentar
adecuadamente el proceso.
• No existe el compromiso suficiente de la dirección por implementar
rigurosamente los procesos asociados.
• Se adoptan procedimientos excesivamente restrictivos que
dificultan la mejora o por el contrario el proceso de cambio se
trivializa provocando una falta de estabilidad necesaria para la
calidad del servicio.
© Aranda Software

12. Gracias
Javier Amil
Javier.amil@arandasoft.com
© Aranda Software