Gestión del Cambio
description
Transcript of Gestión del Cambio
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