ProactivaNET Blog
Visita el blog de referencia en el mundo de TI, ITSM, ITIL y descubre como aplicar las mejores prácticas a tu organización
En él podrás ver casos de éxito, artículos de opinión, eventos del sector y hasta un glosario de términos ITIL que te ayudarán a ver desde una perspectiva práctica como mejorar la gestión de servicios de TI
En muchos ámbitos profesionales se pueden encontrar acrónimos y abreviaturas que son útiles en los Sistemas de Gestión, como las 4P del marketing. ¿Conoce 5W1H? Seguro que le resultará útil.
Continuamos en este artículo comentando acrónimos que pueden ser útiles como recurso fácil para recordar aspectos clave (si quiere, puede consultar la entrada de la semana pasada)
Leer más
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
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
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:
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
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
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?
Este artículo de www.cio.com enumera quince cuestiones clave que pueden hacer fracasar un proyecto. Un repaso sobre cada una de ellas nos permitirá ver las similitudes entre Gestión de Cambios y Gestión de Proyectos.
1.- Alcance mal definido o inexistente.
Un cambio debería tener un objetivo concreto. Para ello deberíamos ser capaces de enunciar qué se debe hacer y cómo se comprueba que el resultado es exitoso. Por ejemplo, si el objetivo de un cambio está enunciado como “aumentar la capacidad de almacenamiento de los buzones de e-mail de los empleados” deberíamos tener un método para validar si el aumento es el adecuado.
Este método recibe el nombre de criterio de aceptación y debería ser algo cuantificable, por ejemplo “que cada empleado disponga de 2 GB”. Así, cuando se haya completado la ejecución del cambio y se quiera realizar la PIR para validar el cierre, podremos saber fácilmente si el cambio está bien realizado o por el contrario el resultado no es satisfactorio.
2.- No gestionar las expectativas.
Cada stakeholder se ve afectado por el cambio de una manera distinta. Además de comunicar correctamente a cada stakeholder qué se espera que haga y cuando, no debemos olvidar que hay stakeholders que no participan activamente en la ejecución del cambio pero sí se verán afectados por la modificación. Estas personas o grupos tienen expectativas y debemos gestionarlas.
Por ejemplo, si estamos realizando un cambio para poner en producción un nuevo servicio ¿hemos tenido en cuenta las expectativas de los futuros usuarios? Por ejemplo, si el nuevo servicio es soporte on-line, ¿se prestará en el horario/idioma/formato que los usuarios esperan? Es más, ¿hemos hecho el esfuerzo de identificar a todos los stakeholders? Cada stakeholder ignorado se convertirá en un elemento reactivo al cambio.
3.- No disponer de respaldo adecuado.
Un cambio puede afectar a muchas personas y partes distintas de la organización y quizás no todas estén igual de receptivas. Si debemos convencer o incluso imponer la realización del cambio, ¿disponemos del respaldo adecuado? Todo cambio debe disponer de un sponsor.
Por ejemplo, si el cambio implica la sustitución de tecnología Microsoft por tecnología Oracle, ¿tenemos un sponsor que nos ayude a conseguir presupuesto y a convencer de la idoneidad del cambio?
En posteriores artículos seguiremos revisando más cuestiones claves que pueden hacer fracasar la ejecución de un cambio. Ir al artículo 2 de 5.
José Luis Fernández
Leer más
Aunque 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
Leer más
ITIL Glossary-Línea base
Las lineas base (o “lineas de base”), tienen gran cantidad de aplicaciones distintas, en muchos procesos y con muchos objetivos distintos, pero cabe destacar su especial importancia en el proceso de gestión de configuración y activos del servicio, en la que la CMDB tendrá la colección de las líneas base para cada uno de sus CIs (algo así como un 2certificado” que acredita y vela por la información recogida en cada uno de los CIs, de tal manera que se deja constancia de que esa información es correcta y adecuada en un momento determinado). Cualquier modificación posterior en cualquiera de los atributos del CI debería invalidar la línea base anterior, y mantener un histórico detallado de qué cambios se han producido desde la linea base anterior, para revisar si dichos cambios son adecuados o no (al margen de que dichos cambios deberían ir relacionados con su correspondiente RFC en Gestión de Cambios); tras realizar todos los cambios oportunos, y una vez validada la nueva información del CI, se deberá establecer una nueva línea base (con un niuevo número de versión para distinguirla de la anterior), y repetir de nuevo el proceso de manera iterativa tantas veces como sea necesario a lo largo de todo el ciclo de vida del CI.
Jandro Castro Leer más
Los departamentos de Desarrollo y Sistemas mantienen, incluso hoy en día, un importante gap funcional y metodológico que llegar a penalizar el buen transcurso de un proyecto. El concepto de “DevOps” es una idea relativamente reciente que pretende sinergizar ambos mundos tradicionalmente separados.
El concepto de DevOps afronta el desafío que radica en la separación entre el ámbito del Desarrollo y el de las Operaciones. Desarrollo entrega nuevas funcionalidades, y bajo la influencia de los métodos ágiles, lo hace cada vez con más rapidez y continuidad.
Operaciones, por su parte, es una función tradicionalmente desempeñado por el Departamento de Sistemas (o similares) donde el objetivo es la estabilidad y un alto control de los servicios productivos. Minimización del riesgo.
En definitiva: Novedad vs Estabilidad. Cambios vs Control.
Adicionalmente la cada vez mayor variedad, complejidad y ubicuidad de los entornos de desarrollo, pruebas, preproducción y producción empieza a requerir que el equipo de Desarrollo esté menos abstraído y más ligado de las cuestiones de despliegue y configuración.
DevOps comprende una colección de métodos y principios para afrontar esta problemática. ¿Cómo podemos conseguirlo? Veamos algunas ideas al respecto:
Plantear procedimientos conjuntos de despliegue, donde estén integrados todos los departamentos implicados.
Desarrollo continuo y realimentación participada por el equipo de Operaciones.
Pruebas conjuntas, especialmente pruebas de integración y pruebas no funcionales.
Establecer canales de comunicación definidos y correctos para los diferentes equipos.
Ciclos cortos de correcciones… ¡y perder el miedo a las entregas continuas!
Todas estas ideas, y muchas más, vienen de la mano de las tendencias Agile y Lean, y tiene importantes lazos con la Gestión del Cambio.
DevOps no es una metodología: es una filosofía de trabajo, un cambio de mentalidad para los equipos de organización tradicional, cuya adopción puede reportar interesantes ventajas a la organización:
Reducción de los tiempos de despliegue de nuevos servicios.
Mejor comprensión de los entornos de producción (y sus restricciones) por parte de los desarrolladores.
Mayor visibilidad de los cuellos de botella en las puestas en producción.
Importantes referencias del sector, como IBM o HP, utilizan ya DevOps desarrollar y entregar sus productos y servicios. ¿Por qué no probarlo en nuestra organización?
David Menéndez Cisterna
Leer más
Argentina
Chile
Colombia
Ecuador
España
México
Panamá
Perú
