Gestión del Cambio

• Objetivo principal:– Minimizar impacto sobre el negocio– Comunicar los cambios, asegurar comunicación

en cascada

• Alcance:– Cambios en las aplicaciones, roll-up de nuevas

versiones de software preparados para producción

– Cambios en Infraestructura– Excluidos los proyectos – Tienen su propio plan

de comunicación

• Condiciones:– No aumentar burocracia– Reducir trámites en papel

Gestión del Cambio

• A definir:– Periocidad – Planificación: Los lunes– Asignar ventanas de cambios

• Sistemas de venta (XML, Catalogo excursiones, Ultramarservices.com, ultramarexpress.com, Hostingtravel – Web de venta) de 01h – 08h

• Back office – No de venta, afecta sólo a usuarios oficina / central: 21h – 08h y cambios de corta duración de 14h – 15:30h, salvo periodos de cierre

• Aviso al usuario mínimo 48 horas, externos 72 horas• Ventana UE Transport – Salva• Proveedores externos, deben ajustarse a estas ventanas

– Sistema de comunicación:• Servicios afectados -> A quién avisar• Anticiparse al cambio• Lista de contactos

– Canales de comunicación:• Email – revisión de plantillas Footprints• Distinción afectación usuario – detalle técnico

Proceso

1. Gestores de relación con negocio y de aplicación solicitan cambios y/o Infraestructura (Todos)

2. Registra el cambio quien ejecuta el cambio o el responsable del servicio

3. Todos los cambios se avisa a Soporte4. Los cambios se revisan los lunes mañana5. Soporte avisa a los usuarios / clientes

una vez aprobado el cambio6. Validación: Responsable de negocio +

Usuarios (si es necesario)

Cambios Footprints

• Toni, por favor esto es lo que habría que cambiar en proyecto:

– Eliminar / ocultar prioridad del cambio– Cambiar Ejecutor por Responsable– Cambiar MotivoParada por Motivo del cambio– Crear plantilla de petición (visible para todo el mundo) donde salga:

• Pasos a realizar en el cambio• Pasos de marcha atrás del cambio• Teléfonos de contacto de todas las personas involucradas en el cambio

– Estado Nueva - Para peticiones que se están escribiendo y aun no queremos que se aprueben

– Eliminar estado denegado, se quedarán siempre en pdte. aprobación

• Workflow:

– Cuando se realiza una nueva petición se queda en nueva. Cuando se quiera enviar a aprobación se cambia estado manualmente a pdte. aprobacion

– Recibir mail automático Marian, Salva, JC Vaquer, Miquel Henales y Adi, responsable del cambio y otros asignados (si los hay, peticionario)

– Marian (en su ausencia Salva o Adi) aprueban el cambio, si hay dudas/problemas para aprobar el cambio se queda en pendiente aprobación.

– Si se aprueba se envía email al responsable y asignados y se pone en el calendario del proyecto

– 24h horas antes del cambio aparece en gestión de incidencias como global• Paso de aprobado a finalizado: Una vez realizado el cambio, el

renponsable debe indicar si el cambio ha finalizado OK y no OK, y en caso de no OK (marcha atrás) incluir el motivo, tendría que ser una checkbox OK/NO OK