Change Management (Registro)

El primer paso del proceso de cambio es registrar adecuadamente las RFCs.

El origen de una RFC puede ser de muy distinta índole:

  • Gestión de Problemas: se encarga de proponer soluciones a errores conocidos. En la mayoría de los casos esta solución acarrea un cambio en la infraestructura TI. En este caso el RFC debe ser registrado con información del error conocido asociado para que posteriormente pueda ser evaluada correctamente la pertinencia del proceso.
  • Nuevos Servicios: el desarrollo de nuevos servicios usualmente requiere cambios de la infraestructura TI. En este caso es importante coordinar todo el proceso con las Gestiones de Capacidad, Disponibilidad y Niveles de Servicio para asegurar que estos cambios cumplen las expectativas previstas y no deterioran la calidad de los otros servicios prestados.
  • Estrategia empresarial: la dirección puede decidir una redirección estratégica que puede afectar, por ejemplo, a los niveles de servicio ofrecidos o a la implantación de un nuevo CRM, etc. y que por regla general requieren de cambios de hardware, software y/o procedimientos.
  • Actualizaciones de software de terceros: los proveedores pueden dejar de soportar versiones anteriores de paquetes de software o introducir nuevas versiones con grandes mejoras que recomienden la actualización.
  • Imperativo legal: un cambio de legislación (como, por ejemplo, la LOPD) puede exigir cambios en la infraestructura TI.
  • Otro: en principio cualquier empleado, cliente o proveedor puede sugerir mejoras en los servicios que pueden requerir cambios en la infraestructura.

No siempre un cambio implica una RFC. Para cambios de escasa importancia o que se repiten periódicamente pueden acordarse procedimientos estándar que no requiera la aprobación de la Gestión de Cambios en cada caso.

Independientemente de su origen el correcto registro inicial de una RFC requerirá, cuando menos, de los siguientes datos:

  • Fecha de recepción.
  • Identificador único de la RFC.
  • Identificador del error conocido asociado (dado el caso).
  • Descripción del cambio propuesto:
    • Motivación.
    • Propósito.
    • CIs involucrados.
    • Estimación de recursos necesarios para la implementación.
    • Tiempo estimado.
  • Estatus: que inicialmente será el de “registrado”.

Este registro deberá ser actualizado con toda la información generada durante el proceso para permitir un detallado seguimiento del mismo desde su aprobación hasta la evaluación final y cierre.

La información de registro debe ser actualizada durante todo el proceso y debe incluir al menos:

  • Estatus actualizado: “aceptado”, “rechazado”, “implementado”, …
  • Fecha de aceptación (denegación) del RFC.
  • Evaluación preliminar de la Gestión del Cambio.
  • Prioridad y categoría.
  • Planes de “back out”.
  • Recursos asignados.
  • Fecha de implementación.
  • Plan de implementación.
  • Cronograma.
  • Revisión post-implementación.
  • Evaluación final.
  • Fecha de cierre.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s