ITIL-Gestión de Servicios TI

English   |  Catalá   |   Formación ITIL  |  Productos y servicios "ITIL Compliant"
 
Gestión de Cambios > Proceso > Aceptación y Clasificación
RetrocederAvanzar

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:

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.

RetrocederRetrocederAvanzar
 

Comentarios: "Gestión de Cambios > Proceso > Aceptación y Clasificación"

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

Escribir un nuevo mensaje: [Condiciones]
Nombre:
Mensaje*:
Código de validación*:
Version 2.0