Elaborar planes para conseguir objetivos es complejo y muchos detalles deben tenerse en cuenta. En este artículo analizaremos el método de los 6 puntos.

Leer más

Cualquier equipo de trabajo requiere una gestión de tareas para repartir la actividad a realizar entre los miembros. ProactivaNET ofrece herramientas de gestión -por ejemplo el módulo de Gestión de Incidencias y Peticiones- pero a veces es necesario gestionar cuestiones ajenas a procesos ITSM. ¿Cómo hacerlo?

Seguro que en su organización tiene que coordinar la realización de tareas dentro de equipos de trabajo.

Leer más

Los próximos 29 y 30 de abril, Xpertis, partner oficial de ProactivaNET en Santiago de Chile, impartirá un taller teórico-práctico sobre el proceso de ITIL® de “Gestión de Cambios”.  No dude en inscribirse ahora en el e-mail info@xpertis.com   Leer más

Cuando se lee bibliografía ITIL-ica sobre Gestión de Entregas y el despliegue automático de los cambios en la infraestructura de TI muchas veces nos encontramos con limitaciones técnicas. En este artículo explicaremos como una buena práctica debe ser realizable y no sólo un concepto interesante.

Supongamos que tiene una organización basada en infraestuctura Windows. Seguramente se encuentre con la necesidad de hacer instalaciones de software, cambios de configuración, etc. ¿Cómo lo está haciendo estas tareas?

Leer más

Una proceso de Gestión de Cambios maduro permite la realización de estos con confianza y minimizando las posibilidades de error. Pero incluso cuando algo se complica proporciona una forma de volver a la situación previa y un aprendizaje para hacerlo mejor en otras ocasiones.

En este artículo utilizaré una entrada del conocido blog de Wardog donde se plantea en tono jocoso la situación provocada por un consultor especialista en “vender humo”.

Sin embargo, lo que me interesa en este caso es que en el artículo se realiza un cambio muy importante en la infraestructura que soporta los servicios de TI de una organización que, a su vez, sostienen los procesos de negocio. Este cambio se realiza sin ningún tipo de análisis previo riguroso y siguiendo sin más la moda del cloud como solución mágica que vale para todo. Resumiendo, el cambio termina siendo un desastre de proporciones épicas.

Analizando el cambio desde un enfoque ITIL echo en falta, por ejemplo, todos los puntos que en ProactivaNET se rellenan en la pestaña investigación del formulario de RFC y que al rellenar nos obliga a hacer una reflexión seria sobre el cambio que queremos realizar.

Por ejemplo, no hay un plan de roll-out y menos aún de back-out. Incluso ante un cambio de tal magnitud no se ha definido un plan de pruebas. Podemos ver cómo se inicia el cambio (lo que formalmente sería la entrega) sin tener en cuenta las limitaciones técnicas:

[…] Giro una pantalla de mi PC y le señalo una cifra. 1097 días, 16 horas, 22 minutos, 11 segundos para completar la transferencia. […]

Ni tampoco el impacto en la actividad de negocio:

[…] Y por supuesto, después habría que establecer el corte de operaciones hasta que se sincronizasen los cambios que la gente haya hecho en el intervalo en los servidores de Suprakillminds. […]

Tampoco hay unos objetivos claros que permitan definir unos criterios de aceptación. Podemos ver como sobre la marcha se van improvisando el dimensionamiento de la nueva capacidad:

[…] Que estaba yo pensando, MKII… que si en lugar de dimensionar todo a 2.5x, dimensionamos a lo que tenemos ahora mismo y le ponemos un poquito más, qué sé yo, un 20% como mucho no nos quedará algo más acorde con lo que necesitamos? […]

E incluso si dentro del alcance se incluye toda la infraestructura o sólo los servidores:

[…] MKII desaparece en un departamento y aparece a los pocos segundos con un papel en la mano con el precio del dimensionamiento para los servidores. Obviamente, mucho más asequible y se lo entrega a $Hyperboss que lo coge y lo mira rápidamente. […]

Por supuesto, la relación coste-beneficio no se considera en ningún momento, aspecto bastante importante y que debería ser el resultado del análisis de cualquier cambio.

La lectura del artículo de Wardog garantiza risas aseguradas, pero en nuestro interior todos deberíamos reflexionar si nuestra organización de TI tiene prácticas “peligrosamente parecidas” a las que se mencionan.

José Luis Fernández Piñero

Leer más

Las organizaciones de TI requieren recursos humanos valiosos, que aporten valor y que permitan la entrega de servicios de calidad. ¿Qué podemos hacer para mejorar la Gestión de RRHH?

Los departamentos de TI de cualquier organización y las empresas cuyo núcleo de negocio son las TI requieren disponer de personal adecuado para satisfacer sus objetivos de negocio.

Leer más

Muchas organizaciones piensan que definir un proceso y documentarlo en papel es lo mismo que implantarlo, y nada más lejos de la realidad, son cosas bien distintas.

Para implantar un proceso, claro está, el primer paso es definirlo, tener bien claro y documentado qué debe hacer, cuáles son sus entradas y salidas, especificar sus responsables, definir como lo vamos a medir,…

Leer más

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?

Leer más

Este artículo enumera los tipos de desperdicio que las técnica de Lean Management pretenden eliminar. Quizás vea reflejada aquí alguna actividad de su organización sobre la que pueda aplicar una acción de mejora. ¿Se reconoce en los ejemplos? Si es así felicidades. Acaba de dar el primer paso para mejorar.

Leer más

 

Este artículo enumera los tipos de desperdicio que las técnica de Lean Management pretenden eliminar. Quizás vea reflejada aquí alguna actividad de su organización sobre la que pueda aplicar una acción de mejora. ¿Se reconoce en los ejemplos? Si es así felicidades. Acaba de dar el primer paso para mejorar.

La aplicación del Lean Management a la Gestión de Servicios de TI es un tema muy de moda y sobre el que hay extensa literatura en internet al respecto (por ejemplo aquí y aquí).

 Sin embargo, aunque todo esto suene a algo muy nuevo es bastante más viejo. La búsqueda de la eliminación del desperdicio, el núcleo de los enfoques LEAN, está en el centro de la filosofía y la metodología de trabajo de Toyota.

El TPS  incluye como actividad fundamental para la mejora la continua eliminación del muda, es decir, la eliminación de todo aquello que es desperdicio y, por tanto, no aporta valor añadido.

 Jeffrey K. Liker enuncia en su libro sobre el TPS las ocho categorías del muda, es decir, los ocho tipos de actividades que no aportan valor y que deberíamos esforzarnos en eliminar de nuestros procesos, que son:

1. Sobreproducción.
2. Esperas evitables.
3. Movimientos innecesarios de los productos.
4. Sobreprecesado.
5. Exceso de inventario.
6. Movimientos innecesarios de los empleados.
7. Defectos de calidad.
8. Creatividad desaprovechada.

El mero hecho de repasar estos ocho tipos de actividades a evitar seguro que le permite identificar alguna que está sucediendo en su organización y sobre la que podría poner el foco para la mejora continua. Sin embargo, se me acaba el espacio en este artículo, así que tras esta introducción que espero haya despertado su interés, dejaremos para una segunda parte repasar estas ocho categorías con detalle.

Jose Luis Fernández

Leer más

Muchas veces se confunden y se consideran iguales,  pero lejos de ser lo mismo, los cambios (RFCs) y las solicitudes de cambio no son lo mismo. Sin entrar en grandes tratados ni estudios “ITILicos” detallados, a continuación trataremos de aportar un poco de luz al respecto…

Aunque no me considero ni ejerzo de consultor de procesos ITIL, sí es verdad que mi vida profesional gira en torno al ese marco de gestión de servicios TI, y de la mano de ProactivaNET me toca orientar y asesorar a clientes y potenciales sobre cómo enfocar la implantación de algunos procesos utilizando nuestra herramienta. Uno de los procesos sobre el que más dudas surgen y sobre el que más preguntas recibo es sobre la gestión de cambios,  y al profundizar en el tema,  en muchas ocasiones descubro que realmente estamos hablando de peticiones,  no de cambios.

El proceso de gestión de peticiones es un proceso ejecutado la mayoría de las ocasiones por el Centro de Servicios, típicamente de manera muy cercana al de gestión de incidencias (aunque son cosas totalmente distintas), que recepciona las nuevas solicitudes realizadas por parte de los usuarios finales,  conforme al un catálogo de servicios que deberíamos tener definido y publicado. Las peticiones pueden ser de muchos tipos: peticiones de compra, solicitudes de nuevos servicios, peticiones para adaptar informes, consultas técnicas, resolución de dudas, asesoramiento,… En ningún caso el servicio se ve comprometido (todo debería estar funcionando bien).

Uno de esos tipos de peticiones puede ser precisamente una petición expresa de cambio (por ejemplo en un informe), pero en otras ocasiones una petición podría derivar en un cambio sin que el usuario realmente sea consciente de ello. La solicitud del usuario es el mecanismo por el cual nos piden las cosas, de manera pública, y que puede desencadenar (o no) una RFC en la gestión de cambios, que quizá ya no sea visible para el usuario final,  al ser un proceso interno de las TI.  Es más, en muchas organizaciones las peticiones que derivan un cambio incluso salen del ámbito del Service Desk, pasando a equipos de gestión de proyectos externos gestionados por PMOs (no digo que sea lo más recomendable ni mucho menos, pero la realidad es esa en muchos casos…)

Una regla que ayudará a determinar de qué estamos hablando, podría ser la siguiente:

• Si lo que necesitas es gestionar el flujo de peticiones de cambio por parte de tus usuarios (establecer un mecanismo para que te pidan cosas) , estamos hablando de gestión de peticiones,  no de gestión de cambios (aunque derivado del primero quizá necesites al segundo); muchas peticiones se resolverán sin necesidad de realizar ningún cambio.
• Sí lo que necesitas es gestionar el propio cambio en sí (no tanto la propia solicitud y comunicación con el usuario, si no más bien el “proyecto”) , haya llegado a partir de una petición de usuario o de cualquier otro origen, estamos hablando de gestión de cambios; un volumen importante de cambios vendrán derivados de orígenes muy diversos,  no de ninguna petición del usuario.

Como casi siempre en ITIL, todo es cuestionable y “depende” de cada caso, pero espero que esta sencilla reflexión sirva para sacar de la duda a algún que otro despistado 😉

Jandro Castro.

Leer más

El proceso de Gestión de Cambios indica y sugiere cómo liderar los cambios que se realizan en los activos participantes para la prestación de servicios. Sin embargo, muchos cambios son complejos y merecen ser considerados como un proyecto. ¿Qué puede aprender Gestión de Cambios de prácticas y metodologías sobre Gestión de Proyectos?

Continuamos repasando las cuestiones clave que pueden hacer fracasar un proyecto para ver las similitudes con Gestión de Cambios a partir de este artículo de www.cio.com.

13.- Reuniones excesivas o muy largas.

Si bien la comunicación es necesaria, el exceso de reuniones es contraproducente ya que, por lo pronto, supone un sobrecoste importante en la realización del cambio. Por ejemplo, una reunión de una hora en la que participen ocho personas cuesta tanto como una jornada de trabajo.

Para mejorar la comunicación intente proporcionar canales alternativos a las reuniones, por ejemplo un foro web o un tablero kanban.

No obstante, algunas reuniones seguirán siendo necesarias. En esos casos asegúrese de que todas tienen un orden del día, una duración concreta, unos objetivos y que los participantes la preparan antes de asistir. Por ejemplo, si una reunión debe servir para decidir a qué proveedor se compra cierto material, asegúrese de que los asistentes disponen de información sobre los distintos proveedores antes de la reunión y de que la reunión termina con una decisión firme.

14.- Descuidar la calidad.

La calidad en la realización de un cambio empieza por una buena definición de los criterios de aceptación que ayuden a garantizar que se entrega lo que se esperaba. Sin embargo, el punto de control clave para impedir que descuidemos la calidad son las revisiones post-implementación (PIR) de los cambios. Concédales el valor y la importancia que tienen un realícelas dedicándoles el tiempo que merecen.

Para que sean más ágiles y estandarizadas quizás las PIR podrían ser una lista de comprobación (checklist) que permitan análisis agregados más rápidos.

15.- No aprender de los errores del pasado.

La calidad está siempre relacionada con la mejora continua. Cada cambio debe realizarse mejor que el anterior y, para ello, debemos hacer uso de dos herramientas fundamentales que nos sugiere ITIL: las revisiones post-implementación (PIR) de los cambios, que son el mecanismo fundamental de reflexión sobre la calidad de lo realizado, así como el proceso de Gestión de Problemas, que permite identificar oportunidades de mejora a partir de distintos inputs, como por ejemplo las PIR de los cambios. En este artículo hay más sugerencias al respecto.

Con este artículo termina, por fin, esta larga serie donde repasamos los puntos más importantes que tienen en común la Gestión de Cambios y la Gestión de Proyectos.

José Luis Fernández

Leer más

El proceso de Gestión de Cambios indica y sugiere cómo liderar los cambios que se realizan en los activos participantes para la prestación de servicios. Sin embargo, muchos cambios son complejos y merecen ser considerados como un proyecto. ¿Qué puede aprender Gestión de Cambios de prácticas y metodologías sobre Gestión de Proyectos?

Continuamos repasando las cuestiones clave que pueden hacer fracasar un proyecto para ver las similitudes con Gestión de Cambios a partir de este artículo de www.cio.com.

10.- Miedo a decir “no”.

No todos los cambios son apropiados. Quizás la parte más importante del proceso de Gestión de Cambios sea rechazar los inadecuados. Para saber cuándo decir “no” debemos tener claro que hay más criterios que un cambio debe cumplir que ser técnicamente viable. Es más, el personal de TI suele centrarse en cuestiones de viabilidad técnica olvidando otros aspectos como el coste, la rentabilidad o limitaciones no técnicas (como por ejemplo las restricciones legales).

11.- No saber trabajar en equipo.

La realización de un cambio es una actividad compleja que es mejor realizar en equipo. Cuando se trabaja en equipo pueden surgir dificultades de comunicación y coordinación, pero también aparecen ventajas como el reparto de tareas para evitar la sobrecarga de trabajo o el uso de personal especializado que garantice los mejores resultados para cada actividad. Es más, no debemos olvidar que suele ser mal criterio ser juez y parte, por lo que separar tareas de manera que quien concede la aprobación no es el mismo que quien solicita el cambio y que tampoco es el mismo que quien hace el análisis de impacto suele producir resultados mejores al basarse en juicios más objetivos y certeros.

12.- Comunicación deficiente.

Si bien el trabajo en equipo es positivo, la comunicación y la coordinación entre los miembros es fundamental. Por este motivo aunque las tareas se deleguen en distintas personas siempre debe existir una única persona responsable del cambio en su conjunto y que debe actuar de líder y coordinador entre los miembros del equipo. El responsable del cambio deberá favorecer la comunicación entre los participantes (interna) sin olvidar la comunicación con los stakeholders (externa).

En posteriores artículos seguiremos revisando más cuestiones claves que pueden hacer fracasar la ejecución de un cambio. Ir al artículo 5 de 5. 

 José Luis Fernández

Leer más

El proceso de Gestión de Cambios indica y sugiere cómo liderar los cambios que se realizan en los activos participantes para la prestación de servicios. Sin embargo, muchos cambios son complejos y merecen ser considerados como un proyecto. ¿Qué puede aprender Gestión de Cambios de prácticas y metodologías sobre Gestión de Proyectos?

Continuamos repasando las cuestiones clave que pueden hacer fracasar un proyecto para ver las similitudes con Gestión de Cambios a partir de este artículo de www.cio.com.

6.- Falta de visibilidad o de información.

Si los resultados del cambio son invisibles hasta prácticamente la finalización (lo que se denomina modelo de la cascada de agua) seguramente no podamos reaccionar ante situaciones adversas. Por ejemplo, ¿qué pasa si el cambio consiste en sustituir los routers de marcas heterogéneas por un modelo concreto de router CISCO para así simplificar la gestión y descubrimos que hay alguna incompatibilidad importante con la necesidad de alguna sede de la empresa? En Gestión de Proyectos suelen recomendarse metodologías iterativas o ágiles que ofrecen entregables intermedios, en Gestión de Cambios podríamos hablar de una Gestión de Entregas que haga despliegues progresivos de manera que se vaya testeando y consolidando el cambio.

7.- Falta de definición de quién toma las decisiones.

Un cambio puede requerir muchas decisiones, pero al menos una es clave y fundamental y es su aprobación para ser realizado. ¿Tenemos un procedimiento claro que establezca a qué comité de autorización le corresponde autorizar (o rechazar) al cambio en función de sus características?

8.- No utilizar software de apoyo.

Cualquier actividad puede realizarse con lápiz y papel, pero eso no significa que sea la manera más eficaz de hacerla. Del mismo modo que hace operaciones matemáticas con una calculadora y no con un ábaco, ¿por qué no utiliza la herramienta adecuada para gestionar cambios?

9.- Permitir modificaciones en el alcance u otros parámetros del cambio.

Como ya comentamos en el primer artículo de esta serie, cada cambio debería tener unos objetivos y unos criterios de aceptación claros y definidos. Partiendo de ellos se ha realizado el análisis de impacto, la identificación de stakeholders e incluso se ha obtenido la aprobación. Si permitimos modificaciones, en el alcance u otros aspectos, o rehacemos los pasos previos o corremos el riesgo de enfrentarnos a situaciones imprevistas que pongan en riesgo el éxito del cambio.

Por ejemplo, si hemos obtenido aprobación para realizar la sustitución de un servidor MS SQL Server por Oracle pero en el último momento instalamos MySQL, ¿estamos seguros de que el software que se iba a migrar de MS SQL Server a Oracle se puede migrar a MySQL sin incurrir en sobrecostes o limitaciones técnicas?

En posteriores artículos seguiremos revisando más cuestiones claves que pueden hacer fracasar la ejecución de un cambio. Ir al artículo 4 de 5. 

 José Luis Fernández

Leer más

El proceso de Gestión de Cambios indica y sugiere cómo liderar los cambios que se realizan en los activos participantes para la prestación de servicios. Sin embargo, muchos cambios son complejos y merecen ser considerados como un proyecto. ¿Qué puede aprender Gestión de Cambios de prácticas y metodologías sobre Gestión de Proyectos?

Continuamos repasando las cuestiones clave que pueden hacer fracasar un proyecto para ver las similitudes con Gestión de Cambios a partir de este artículo de www.cio.com

4.- Utilizar siempre la misma metodología.

Hay un dicho que dice que quien tiene un martillo todo lo que ve son clavos. Debemos comprender que no se puede aplicar la misma metodología a todos los cambios porque un cambio muy complejo gestionado con una metodología muy simple será propenso a errores mientras que un cambio muy simple gestionado con una metodología muy compleja será muy caro por los costes de la gestión.

Por lo tanto, debemos diferenciar los cambios segmentándolos en varias clasificaciones y gestionándolos con metodologías acordes. Empecemos cuestionando si hace falta usar Gestión de Cambios para realizar la modificación que queremos hacer o si podríamos usar Gestión de Peticiones. Si hace falta Gestión de Cambios, ¿el cambio requiere autorización o podemos evitar esta etapa? Si el cambio requiere autorización, ¿el comité que concederá la autorización está formado por las personas oportunas o hay demasiadas personas en el comité? Si el cambio es urgente, ¿estamos usando un procedimiento más ágil? Seguro que se le ocurren más cuestiones que podríamos plantear para encontrar aspectos de la Gestión de Cambios que pueden hacerse de manera diferente en función de la entidad del cambio.

5.- Sobrecargar a los miembros del equipo.

Recuerde que proceso no es sinónimo de departamento. Por lo tanto lo más probable es que Gestión de Cambios no sea un departamento de personas que se dediquen sólo a las tareas relacionadas con los cambios. Así que cuando planifique los cambios tenga en cuenta el impacto de la carga de trabajo derivada de los cambios en otros procesos. Por ejemplo, ¿qué pasa si uno de los miembros del equipo que realiza un cambio es a su vez técnico de tercera línea de Gestión de Incidencias? ¿Dispone el técnico de tiempo suficiente o podemos estar poniendo en riesgo el cumplimiento de algún Acuerdo de Nivel de Servicio?

En posteriores artículos seguiremos revisando más cuestiones claves que pueden hacer fracasar la ejecución de un cambio. Ir al artículo 3 de 5. 

 José Luis Fernández

Leer más