Gestión del Cambio

1. 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

2. 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

3. Proceso • Gestores de relación con negocio y de aplicación solicitan cambios y/o Infraestructura (Todos) • Registra el cambio quien ejecuta el cambio o el responsable del servicio • Todos los cambios se avisa a Soporte • Los cambios se revisan los lunes mañana • Soporte avisa a los usuarios / clientes una vez aprobado el cambio • Validación: Responsable de negocio + Usuarios (si es necesario)

4. 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