Archivo de la etiqueta: RFC

Gestión de Proyectos y Gestión de Cambios

3d illustration of human head with gear wheels inside

Para implantar procesos ITIL de una manera eficaz es interesante explorar metodologías y áreas de conocimiento que se enfrenten a retos similares para aplicar esas prácticas ya probadas. ¿Podemos aprovechar nuestro conocimiento sobre Gestión de Proyectos para implantar una Gestión de Cambios más eficaz?

Como consultor ITIL y jefe de proyectos de implantación de soluciones de TI me gusta reutilizar conocimientos y prácticas para ofrecer soluciones más eficaces a mis clientes.

En artículos previos del blog (I, II, III, IV, V, VI) ya hemos tratado la relación entre Gestión de Cambios y Gestión de Proyectos. Sin embargo, en este artículo encontrará siete aspectos que son importantes considerar para la Gestión de Proyectos y que me gustaría analizar en relación a la Gestión de Cambios.

Participar desde el inicio del proyecto. Este consejo me hace pensar sobre el papel de los stakeholders. Esto es especialmente importante cuando se empieza a gestionar un cambio. ¿Nos hemos olvidado de algún involucrado/afectado por el cambio? ¿Qué puede suceder si ejecutamos el cambio sin tenerle en cuenta? ¿Qué puede suceder si se da cuenta de que estamos ejecutando el cambio sin su conocimiento?

Habilidad para reunir y mantener el equipo perfecto para el proyecto. Para reunir el personal adecuado primero hay que identificar qué requisitos deben cumplir los miembros del equipo de trabajo del cambio. Por ejemplo ¿hemos identificado la capacitación necesaria? ¿la disponibilidad horaria? ¿hemos tenido en cuenta las vacaciones del personal o su involucración en otros cambios/proyectos? No subestime nunca los recursos humanos, son la parte más valiosa del departamento de TI.

Disponer de herramientas sencillas pero potentes para gestionar proyectos. Una gestión profesional requiere herramientas profesionales. Del mismo modo que utiliza una calculadora en lugar de un lápiz y papel, ¿por qué sigue gestionando sus cambios sin una herramienta específica?

Trabajar con objetivos y requisitos bien definidos. Un cambio sólo se ejecutará de manera eficaz si está bien definido en cuanto a su alcance: ¿qué queremos conseguir? Si no somos capaces de responder a esta pregunta entonces tampoco podremos responder a otras como ¿quién se ve afectado por el cambio? o ¿qué impacto tiene el cambio en otros servicios o sistemas? Por ejemplo, “aumentar la capacidad de almacenamiento” no es un objetivo bien definido. Sin embargo, “aumentar la capacidad de almacenamiento de los buzones de correos del personal de fuerza de ventas hasta un mínimo de 50 GB por empleado” es un alcance bien definido.

Conseguir la aceptación de los involucrados y los usuarios finales. Al principio ya hablamos sobre los involucrados (stakeholders), pero tampoco debemos ignorar a los usuarios finales de los servicios sobre los que se realizan los cambios. Quizás haya tratado con un interlocutor, pero nunca subestime lo que puedan aportar los usuarios finales sobre la realidad de sus necesidades. Si es posible, ensaye el cambio mediante un piloto, contraste los resultados con los objetivos definidos y utilice el feedback de los usuarios finales para identificar oportunidades de mejora antes de extender el cambio a su alcance completo.

Autoridad para modificar la gestión y el enfoque del proyecto sobre la marcha. Si el cambio es complejo y largo en el tiempo es posible que los objetivos y requisitos originales sufran alteraciones. Como gestor del cambio deberá estar atento a esta situación y considerar las variaciones necesarias sobre el plan original. Sin embargo esto no significa que la organización espere cambios improvisados. Una gestión ágil, flexible y concienciada con las necesidades cambiantes del negocio no es lo mismo que la improvisación.

Por último, me permitiré cambiar uno de los consejos del artículo original por uno de mi propia cosecha: no tenga miedo a equivocarse, pero no cometa dos veces el mismo error. Aprenda de los errores, tanto de los suyos como de los de otros.

José Luis Fernández Piñero

#ITILGlossary – RFC

ITILGlossary_RFCAunque siendo estrictos la petición de cambio, el registro del cambio y el cambio en sí mismo no son exactamente lo mismo, en el mundo real todo acaba siendo referido bajo el concepto de RFC (como un todo). Tomando en consideración la RFC como un todo, en muchas ocasiones resulta difícil a su vez diferenciarlas de las peticiones de servicio que llegan al Centro de Servicios: está claro que los “grandes cambios” no serán confundidos nunca con una “simple” petición de servicios, pero no ocurre lo mismo si hablamos de los cambios estándar preautorizados que no requieren de la aprobación del CAB para su ejecución.

¿Dónde termina una petición de servicio y dónde comienza una RFC estándar? La frontera entre uno y otro puede no quedar del todo clara, pero a fin de cuentas, lo importante es definirla en un punto que resulta adecuado para nuestros procesos. El día a día no es un examen de ITIL, así que una vez establezcamos “nuestra” barrera entre petición de servicio y cambio estándar, lo más importante no es seguir pensando en si esa diferenciación es correcta o no según los términos teóricos; lo más importante será ser consecuente con la decisión tomada, y garantizar (medir) que es la más adecuada para nuestra organización (con independencia de lo que nos digan los libros de ITIL).

Jandro Castro

CMDB y RFCs, mejor juntas

cuatro manos

Una de las dificultades a la que se enfrentan las organizaciones a la hora de montar una nueva CMDB es cómo mantenerla actualizada durante la etapa inicial de creación. ¿Si estoy revisando la infraestructura para meterla en la CMDB a la vez que sigo haciendo cambios, cómo garantizo que la versión inicial de mi CMDB no está ya obsoleta? Fácil, haciendo que la gestión de cambios y la gestión de configuración vayan de la mano

La antigua ITIL v2 relacionaba muy estrechamente los procesos de Gestión de Configuración (y su CMDB), Gestión de Cambios (RFCs) y Gestión de Entregas, e incluso les daba un nombre conjunto: “procesos operacionales”. Tanto era así, que en muchas ocasiones se planteaba la necesidad de implantarlos al mismo tiempo.

Como en todo, aquí no hay nada mandatorio, y nadie nos obligará a implantar los 3 procesos simultáneamente, pero si decidimos hacerlo, tendremos muchas ventajas. Una de ellas, entre otras, será que podremos minimizar el riesgo de que nuestra recién creada CMDB ya nazca obsoleta, desactualizada.

El proceso de configurar y meter todos los datos en una nueva CMDB puede ser relativamente laborioso, sobre todo en organizaciones de un tamaño relativamente importante, en las que existe un catálogo de servicios grande, con mucha infraestructura. En ese entorno, identificar los CIs que forman parte de la CMDB, ver cómo se relacionan, determinar qué servicios prestan, e introducir la información en la CMDB puede llevar un tiempo no despreciable, y durante ese intervalo, podrían seguir realizándose cambios que modifiquen la información de la CMDB.

Para evitar las situaciones anteriores, la solución pasa por incorporar la gestión de configuración al proceso de gestión de cambios desde el primer momento, no al final como se hace muchas veces: desde el primer momento, cualquier cambio que se realice, ya debería ser notificado directamente a la CMDB para su actualización.

Algunos pasos (simples, muy simples), de cómo podría realizarse esto:

· Cualquier cambio debería llevar desde el primer momento el detalle de los elementos de configuración que va a actualizar (aunque no esté todavía la CMDB, como ya tendremos el alcance y tipos de elementos, la gestión de cambios podría listarlos, aunque sea de manera textual)

· Los responsables de la gestión de configuración recibirán esa información, y podrán encontrarse ante varios casos distintos:

– Si los CIs ya están en la CMDB, podrán actualizarla sin ningún problema

– Si los CIs no están en la CMDB, ni tampoco forman parte del grupo de CIs con el que estamos trabajando en este momento, no hará falta hacer nada de momento

– Si los CIs no están en la CMDB, pero forman parte de los elementos involucrados en la prestación del servicio que estamos modelando en la CMDB, tendremos que tener muy en cuenta esos cambios para que ya vayan incluidos directamente en nuestro modelado del servicio

Con este planteamiento (muy sencillo), surge además una idea de fondo, que es la necesidad de alimentar la CMDB de manera gradual e iterativa, modelando servicio a servicio (siempre relacionados con el Catálogo de Servicios)

Parece una receta sencilla, y realmente lo es, y permitirá que nuestra CMDB luzca reluciente y actualizada desde el primer día¡! No hay nada más frustrante que invertir el esfuerzo de varias semanas o meses en modelar una CMDB, y que en el momento de su “puesta de largo” tengamos fundadas sospechas de que ya no está actualizada; si nos ha ocurrido eso, sin duda nuestro proyecto ha fracasado, algo hemos hecho mal.

Jandro Castro