Gestión de Cambios
Aceptación y Clasificación
Aceptación
Tras el registro del RFC se debe evaluar preliminarmente su pertinencia.
Una RFC puede ser simplemente rechazada si se considera que el cambio no esta
justificado o se puede solicitar su modificación si se considera que algunos
aspectos de la misma son susceptibles de mejora o mayor definición.
En cualquiera de los casos la RFC debe ser devuelta al departamento o
persona que la solicito con el objetivo de que se puedan realizar nuevas alegaciones a
favor de dicha RFC o para que pueda ser consecuentemente modificada.
La aceptación del cambio no implica su posterior aprobación por el CAB y es sólo indicación
de que se ha encontrada justificado su ulterior procesamiento.
Clasificación
Tras su aceptación se deben asignar a la RFC una prioridad y categoría dependiendo de la
urgencia y el impacto de la misma.
La prioridad determinará la importancia relativa de esta RFC respecto a otras
RFCs pendientes y será el dato
relevante para establecer el calendario de cambios a realizar.
La categoría determina la dificultad e impacto de la RFC y será el parámetro relevante para
determinar la asignación de recursos necesarios, los plazos previstos y el nivel de autorización
requerido para la implementación del cambio.
Aunque el rango de posibles prioridades pueda ser tan amplio como se desee se debería considerar
una clasificación que incluyera, al menos, los siguientes niveles de prioridad:
- Baja: puede ser conveniente realizar este cambio junto a otros cuando,
por ejemplo, se decidan actualizar ciertos paquetes de software o se compre
nuevo hardware, etc.
- Normal: Es conveniente realizar el cambio pero siempre que ello no
entorpezca algún otro cambio de más alta prioridad.
- Alta: un cambio que debe realizarse sin demora pues esta asociado a
errores conocidos que deterioran apreciablemente la calidad del servicio.
El CAB debe evaluar este cambio en su próxima reunión y adoptar las medidas
pertinentes que permitan una pronta solución.
- Urgente: es necesario resolver un problema que esta provocando una
interrupción o deterioro grave del servicio. Un cambio de prioridad urgente
desencadena un proceso denominado cambio de emergencia que trataremos de
forma independiente.
La determinación de la categoría se basa en el impacto sobre la organización y el
esfuerzo requerido para su implementación. El abanico de posibilidades incluye desde
cambios que apenas requieren la participación del personal TI y que apenas modifican
la calidad del servicio hasta cambios que necesiten grandes recursos y requieran de la
aprobación directa de la Dirección.
Los cambios menores pueden no necesitar la aprobación del CAB y ser implementados directamente.
Cualquier otro cambio habrá de ser discutido en el CAB y se habrá de solicitar la colaboración de
personal especializado para realizar tareas de asesoramiento.
Los cambios de emergencia muchas veces son a causa de hardware y no por mala planificación. No necesariamente se interrumpe el servicio pero puede degradar el servicio. También, si no se se ejecuta el cambio de emergencia puede llegar a interrumpir el servicio, eg un disco duro, abanico, hasta el aire acondicionado en el Data Room
Marcar mensaje como inapropiado
Por Hernán 26/04/2007
Los cambios de emergencia muchas veces son a causa de hardware y no por mala planificación(POR MAS EFICIENTE Q UNA PLANIFICACION SEA O POR MUY BUEN HARDWARE SE PUEDA TENER UNA EMERGENCIA SE PUEDE PRODUCIR EN CUALQUIER CIRSCUNTANCIA Y SIN RAZON). No necesariamente se interrumpe (NO SE CONTRADIGA USTED MISMO,EL SERVICIO SE INTERRUMPE LA MAYORIA DE LAS VECES Y UNA DEGRADACION DEL SERVICIO PODRIA NO CONLLEVAR UN CAMBIO DE EMERGENCIA TAL VEZ UNA SOLUCION TEMPORAL DEL PROBLEMA "WORKAROUND")el servicio pero puede degradar el servicio. También, si no se se ejecuta el cambio de emergencia puede llegar a "interrumpir el servicio", eg un disco duro, abanico, hasta el aire acondicionado en el Data Room
Marcar mensaje como inapropiado
Por jorge 07/07/2007
Yo pienso que los cambios de emergencia en última instancia si se deben a una mala planificación. Si cae un disco de un servidor y pasa algo, es porque no existe RAID, una arquitectura en CLUSTER o una virtualización dinámica. Por tanto GESTION DE LA DISPONIBILIDAD nos ayudará a planificar, aunque desgraciadamente en muchos casos la GESTION FINANCIERA se encarga de bloquear la iniciativa. Entonces se trata de un margen de riesgo ASUMIDO por la organización.
Marcar mensaje como inapropiado
Por José Luís Colom (Barcelona) 21/04/2008
Yo estoy de acuerdo con lo escrito en el articulo mas podria dividir los cambios URGENTES en dos, Urgentes y Urgentes-Emertgentes, los cambios Urgentes serian aquellos que obedecerian a una llamada de atención por parte de una almarma de algun servicio, y los urgentes-emergentes serian los que obedencen a cualquier interrupción del servicio de alto impacto, ya sea por el número de usuarios afectados o porque se han visto involucrados sistemas o servicios críticos para la organización. Mas no hay que perder de vista y debemos de tener la sifuciente evidencia de que el cambio que documentamos como Urgente es eso y no el resultado de una falta de planeación.
Marcar mensaje como inapropiado
Por Omar García 18/08/2008
Otras veces, los cambios de emergencia se deben al software. Este es, los evolutivos no están bien testeados, y una vez subidos al entorno de producción, empiezan a generar incidencias.
La calidad del software, por desgracia, es muchos casos es deficiente. No hay que buscar culpables en los equipo de desarrollo, sólo, en el tiempo que se les dá para generar los nuevos evolutivos.
Un saludo, Juan Carlos
Marcar mensaje como inapropiado
Por Juan Carlos 02/01/2009
