Mejorar la reputación de la Gestión de Cambios via cambios estándar

Kafka y Weber recopilando RFCs para el CAB de los miércoles

La adopción de la Gestión de Cambios suele ser de difícil digestión para muchos de los implicados: la primera impresión por parte de técnicos y desarrolladores es que sólo añade burocracia, entorpece a los equipos de desarrollo y obstaculiza la operación de sistemas. A menudo, es fácil convencerles de que el objetivo del proceso es limitar las incidencias derivadas de cambios, pero el factor clave para venderles el proceso puede ser introducir los cambios estándar que incorpora V3.

No sólo porque los de Sistemas se pueden sentir aliviados por no tener que elevar una RFC para algunas actividades que conforman su día a día, sino porque reducirá la carga del proceso de gestión de cambios tambien: un cambio estándar necesita ser aprobado por el CAB una sola vez, y ese cambio estará pre-aprobado para todas sus implementaciones (a no ser que un cambio en el entorno requiera revisarlo).

A lo mejor en las etapas iniciales de despliegue del proceso de gestión de cambios no es fácil detectar qué cambios son candidatos de convertirse en un cambio estándar, pero revisando las RFC pasadas y hablando con los chicos de operaciones y sistemas, seguro que salen algunos candidatos.

Otra ventaja: una vez encontrado un candidato a cambio estándar, se establece el procedimiento de operación necesario y se puede formar  a los equipos de soporte de menor nivel para que ejecuten esos cambios, y esto suele traer solo ventajas:

• Los técnicos de nivel superior, se descargan de operaciones repetitivas, rutinarias y de la carga burocrática implícita a la gestión de cambios
• Los técnicos de nivel inferior, contentos de que se les enseñen cosas nuevas, de que se les deleguen tareas procedentes de equipos superiores y de sentirse parte del proceso de gestión de cambios
• Los implicados en la gestión de cambios (jefes de equipo, miembros del CAB, etc.) se descargan de parte de la carga que los cambios repetitivos les acarrea, y pueden centrar más atención a los cambios que realmente merecen un control más exhaustivo.

Por supuesto, sería necesario crear un proceso separado para la gestión de cambios estándar, que incluya la auditoría de estos cambios y sus implementaciones, la elección y seguimiento de KPIs, fomentando la interfaz con la Gestión de Cambios para tener la seguridad de la vigencia de un cambio a estándar frente a otros cambios propuestos en la organización.

Y vosotros, en vuestras empresas, o en vuestros clientes, ¿habeis tenido ocasión de instaurar los cambios estándar? ¿Os ha aportado beneficios? ¿Habeis necesitado hacer cambios en vuestras herramientas de gestión para integrarlos?

*Imagen: ilustración por  Harald Groven

Deming y la adquisición de herramientas

Estoy leyendo estos días “Out of the crisis” de W. Edwards Deming, en el que básicamente expone las claves de su sistema para mejorar la calidad y la productividad, exhortando a la industria estadounidense a seguir sus 14 claves para alcanzar la calidad total y salir de la decadencia en que su tejido empresarial se encuentra. Desde el primer capítulo, Deming insiste en un punto: no hay que empezar comprando robots, máquinas, ordenadores u otros aparatejos para empezar a mejorar la calidad, sino centrarse en las personas. Para él, el primer paso en la mejora de la calidad es cambiar la forma en la que las personas trabajan, para que trabajen mejor, no más.

Y esto coincide plenamente con uno de los puntos que siempre remarco en los proyectos de adopción de procesos ITIL en los que he trabajado:  no hace falta empezar por la elección de las herramientas de gestión, no hace falta empezar gastando tiempo y dinero en la elección de una herramienta, la configuración, personalización y formación de los usuarios. Es importante hacerlo, pero no debe ser el puntal de un proyecto de cambio de organización, y tampoco es necesario que sea el primer paso. En muchos clientes, nuestro acercamiento empieza por analizar qué hacen y cómo lo hacen, y proponer pequeños cambios iniciales que dan resultados muy rápidamente. Generalmente, esta aproximación genera un cierto recelo por parte de los managers de informática, acostumbrados a adquirir herramientas nuevas para la implantación de nuevos modelos de gestión, pero comprobar cómo, iterando estos ciclos de pequeños cambios, conseguimos grandes resultados, les ayuda a despejar las dudas y a poder replantear la búsqueda de una herramienta de gestión adecuada contando con más argumentos de decisión, al entender cómo va a seguir cambiando su departamento TI y hacia dónde se dirige.

El motivo principal que esgrime Deming para no comenzar un proceso de mejora con la adquisición de productos, es que sin un análisis previo (las preguntas típicas, “cuál es la visión? dónde estamos? dónde queremos estar? cómo llegamos allí?”) y sin revisar primero qué hacen las personas y cómo impacta a la calidad y la productividad, no se puede determinar qué carencias o defectos resolveremos con las adquisiciones ni que beneficios (o qué pérdidas) obtendremos.

Lo cierto es que esta aproximación iterativa de pequeños cambios sobre los “componentes” humanos de un departamento de TI suele ser un éxito, no sólo porque ayudan a vencer la inercia de oposición al cambio natural en cualquier organización (y en cualquier individuo), sino tambien porque permiten la obtención de beneficios rápidamente; podría decirse que se persigue uno de los objetivos de las metodologías ágiles de desarrollo de soft, aunque no sería exacto; de todos modos, Rob England defiende un acercamiento ágil a la gestión de servicios que resulta interesante, y os ánimo a echarle un vistazo. Por otro lado, hay un artículo de Antonio Valle en el que comenta la naturaleza fractal del ciclo de Deming, donde destaca que cada gran vuelta de un ciclo PDCA está compuesta por pequeñas iteraciones del mismo ciclo, como si un sistema orbital fuera. Merece un vistazo.

¿Cómo habeis vivido vosotros los procesos de selección de una herramienta de gestión ITSM? ¿Qué elementos son los que más valoran las empresas para elegir una u otra? ¿Cómo lo habeis vivido?

ITIL engorda

Hay novedades sobre ITIL V3 2011 Edition; no sobre el contenido, en realidad, pero sí sobre el continente, porque ITIL ha crecido… físicamente, quiero decir. Y no veas cómo.

En la nota publicada por ITSMFi tenemos un detalle sobre el aumento en páginas:

the page count has increased from 1,343 to 1,959 pages with the biggest increase being for Service Strategy with over 200 additional pages and SD, ST and SO all having around 100 additional pages each

Y obviamente, esto se traduce en un cambio de peso:

the weight of the suite has increased from 4.459 KG to 6.981 KG

Por suerte, las nuevas ediciones incorporan otro tipo de ventajas; el color de fondo de las sobrecubiertas ha pasado de negro a blanco, para poder diferenciarla de la anterior edición. Ah, y han incorporado la palabra “ITIL” en los títulos. Para que no te hagas líos a la hora de coger el libro de una edición o de otra.

Al final, lo que resulta curioso tambien es que ITIL llame  ”actualización menor” a un aumento en páginas de casi el 50%, la adición de 4 nuevos procesos, otros 2 renombrados, clarificación y mejoras en los workflows de otros cuantos procesos… El debate sobre si esto es una minor release o debería lanzarse como una nueva versión no lo voy a iniciar ahora, pero con esos cambios en mente, no creo que los desarrolladores de software que hayan publicado herramientas de automatización de workflows ITIL estén contentos. Casi siento pena por ellos… Porque a la que se despisten, la TSO les lanza ITIL V4, y vuelve a empezar.

Consumerization: a Manifesto

Brian Madden, que es algo más que un supersabio en lo que a virtualización (sobretodo de escritorios) se refiere, publicó el pasado 2 de junio de 2011 su manifiesto sobre uno de los frentes abiertos más preocupantes (que, cómo no, Gartner ya lo predijo hace años) que afrontan los departamentos de IT: consumerization.

El artículo es un poco largo pero merece una lectura: ayuda a comprender (y a aceptar, aunque duela) la nueva realidad: que los usuarios, tal y como dice Brian en su artículo, le hacen un “fuck you” al departamento IT y, en esencia, van a hacer lo que les dé la gana, porque tienen a su alcance y usan ya de manera efectiva un arsenal tecnológico, hardware y software, con el que hace unos años sólo se podía fantasear: iPhones, Androids, Gmail, Dropbox, conexiones 3G… Y es más: saben cómo usar ese arsenal.

Así que los departamentos IT vamos a tener que aprender qué hacer para sacar provecho de la customerization, porque es imparable y porque luchar contra eso es escupir contra el viento: el usuario va a hacer lo que quiera, y ahora los caminos para hacerlo son infinitos. Mejor sacarle partido, no?

Quedo pendiente de que Brian Madden publique su anunciada parte 2, en la que expondrá estrategias para enfrentarse con el desafío de este mundo nuevo y enloquecido.

Aquí os dejo el enlace al artículo:

The consumerization of IT: why most vendors get it wrong, and why it’s a real challenge today. (Part 1)

PS: no uso una traducción al castellano de ese término porque no encuentro ninguna, supongo que en España nos preocuparemos por esto dentro de 5 años, ¿no?

La estandarización de la continuidad de negocios

Joseba Enjuto fotografía el estado de los estándares de continuidad de negocio y su futuro en su blog; sin duda, lo más destacable es el empleo en los nuevos textos de las normas ISO de las expresiones “readiness” y “societal security”. Como anota Joseba, parece que se hace un esfuerzo por separar el negocio de las TIC, y aunque conozco poco el mundo ISO, no sé si lo hacen para promover que cada uno se meta en lo suyo o porque, como en otro momento apunta Joseba, las normas ISO se enfocan sobre riesgos operacionales y dejan de lado el embrollo economico-financiero del que se ocuparán otros departamentos de la organización, si la continuidad del negocio se ve comprometida. Tengo pendiente explicar ciertas tensiones vividas recientemente con un consultor de ITIL (de la competencia) sobre algo tan básico como que cada uno se dedique a lo suyo e intentar recordar que IT en ITIL se refiere a “Information Technology”; vaya, que no tenemos que salvar ni rediseñar a las empresas, que lo nuestro es la tecnología. Pero ya otro día lo cuento.

De nuevo, para más detalles y una explicación más seria que la mía, pasad por Seguridad y Gestión.