La resistencia al cambio (Parte II)

Ya sé que prometí no escribir, desconectar y aprovechar las vacaciones… ya lo sé! Pero parte de ese desconectar ha sido ordenar un poco el cuarto donde tengo mis cosas, tirar papeles y tratar de organizar un poco el desorden, que una vez al año no está mal. Entre todo el desorden apareció un papel que me hizo recordar…

Debía ser Noviembre del 2005 cuando fuí por primera vez a aquel cliente. Los primeros contactos siempre me ponen un poco nervioso; no conozco a quien voy a ver, no sé nada de él/ella y en todo caso tengo la poca información que me pueda haber pasado el comercial si no es la primera de las primeras visitas… en esas reuniones hay que estar muy alerta y esforzarse por pillar rápidamente cuáles son las necesidades del cliente (no lo que te está pidiendo, sino realmente qué necesita).

En este caso, Mr. X tardó un poco más de la cuenta en venir a atenderme y maté el tiempo echando un vistazo al tablón de anuncios que había en el pasillo… y de repente me encontré con un trozo de folio que al leerlo me hizo poner los pelos de punta: ¿¿ Pero en qué clase de encerrona me habían metido esta vez ??

Cuando ya hubo un poco más de confianza le pedí a Mr. X que me dejara fotocopiarlo, y ahora he reencontrado esa fotocopia que transcribo literalmente:

“[..]¿Cuál es la parte más difícil del trabajo de un desarrollador de software? ¿La arquitectura, el análisis funcional, el técnico, la programación? No. La parte dura de verdad es tener que oir gilipolleces. Uno recibe un mail del ITIL manager, ese individuo que, según currículum ha “colaborado en la conceptualización de proyectos de convergencia” y ha sido “director de expansión de estrategias de cuarta generación” y cuyo trabajo consiste en reenviar los mails de los clientes a los técnicos y viceversa, y leer cosas en Internet para tener algo que decir (con Google y un par de reglas de outlook ya se podía ahorrar la empresa 80.000 euros al año). El mail lleva por subject “Brainstorming”. Ahí ya estás bien jodido.

El “brainstorming” o “tormenta de cerebros” es (o debería ser) la reuniín en la que todos aportan su talento y su experiencia para encontrar soluciones óptimas a problemas. La realidad es que en la tormenta de cerebros, el manager suele poner la tormenta y tú tienes que poner el cerebro. Y en la tormenta, como en el río revuelto, la ganancia es para los pescadores. Tú piensas, diseñas y solucionas, que para algo querías ser ingeniero. Él se apunta el gol, que para algo hizo un master en “strategy business janderklander for ITIL manager. […]”

Bueno, como primera entrada para hacer un proyecto de definición de Catálogo de Servicios, no está mal, ¿no?. Era como entrar directamente en terreno hostil y que te lo avisaran "sutilmente".Después resultó ser un proyecto súper agradable, interesante y que aportó un montón de conocimiento y experiencias a ambas partes.

De todas formas, ahora siempre va conmigo el papelote, para recordarme que es así como nos ven y es contra esa imagen contra la que hemos de luchar. Nunca debemos dejar que nuestro equipo de trabajo, ya sea propio, del cliente o mixto, nos vea como ese tipo de “consultor janderklander de mierda que sólo viene a parasitar mi conocimiento y a ponerse él las medallas”.

Al fin, ¡vacaciones!

Bueno, chicos:

Al fin ha llegado la hora de las deseadas merecidas vacaciones. Me voy 3 semanas y, salvo que mis neuronas que nunca se callan me obliguen a sentarme delante del PC a escribir, no creo que haya posts por aquí. No es que lleve todo el año esperándolas, pero cuando llegan se agradecen, y mucho. ( y el cuerpo las necesita también, para qué nos vamos a engañar!)

Mientras tanto les recomiendo que sigan de cerca las noticias que puedan aparecer en el ITSM Portal y, ¡cómo no! las nuevas batallas que vaya presentando el ITIL Skeptic... uno de los sitios más entretenidos en este mundillo poque tiene una visión especialmente crítica e interesante del mercado.

¡Hasta Pronto!

Antonio

Catálogos de Servicios - ¿ Fast Food o 'a la carte' ?

Hoy he leido el post publicado por Rodrigo Flores en su blog Service Catalogs al respecto de la definición del concepto de Servicio, algo que se echa en falta en todas las ocasiones en que pensamos en ITSM. Me ha encantado la comparación de un departamento de TI con un McDonalds o con un Burguer King y me ha dado que pensar en cuanto a la relación que existe entre la flexibilidad que le damos a los servicios y la forma de organizar los SLA.

Me explicaré un poco mejor: según los libros y las matemáticas combinatorias, hay principalmente 3 formas de organizar un ANS, a saber:

• MODELO 1: Un SLA para un servicio concreto S acordado con los "n" clientes de este servicio. En este caso tenemos un único documento de especificaciones del servicio con unos valores uniformes de Objetivos de Nivel de Servicio (SLO). De esta forma, proporcionaremos el servicio S a los "n" bajo las mismas especificaciones.
• MODELO 2: Un SLA para un cliente C con todos los servicios consumidos por este cliente. En este caso podremos parametrizar cada servicio de forma especial para cada uno de los clientes y tendremos un único documento que lo cubre todo.
• MODELO 3: Un SLA por cliente y por servicio. Es el modelo "producto cartesiano", que en una organización aunque sólo sea un pelín grande ya es inmanejable porque significa un volumen de documentos brutal.

Bueno, y frente a estas tres posibilidades, ¿Cuál es la correcta para mi organización?

Y aquí es donde entra el concepto McDonalds frente al concepto Burguer King, al concepto Restaurante Mibistec o a la cocina de mi casa: si voy al McDonalds no puedo customizar la hamburguesa ni pedir un bistec, si voy al Burguer King puedo customizar la hamburguesa, pero no pedir un bistec; si voy al restaurante, puedo pedir cualquier cosa que haya en la carta y customizarla y por último, si me quedo a comer en casa, hago lo que quiera (y/o pueda) con mi comida.

¿Cuán flexible es la provisión de los servicios hecha desde nuestra organización TIC? Habrá servicios con una gran flexibilidad, que requerirán un SLA especial para cada cliente que contrate y habrá servicios absolutamente rígidos que nos van a permitir firmar un único SLA con todos los clientes.

Desde el punto de vista del proveedor de servicios, cuanto más rígidos sean los servicios más simple es su gestión pero menor valor añadido de cara al cliente; de modo que como lo que pretendemos es alinearnos con nuestro cliente, tendremos que dar el nivel de flexibilidad que requiera la organización y aquí está el secreto: ajustaremos la complejidad de la gestión de nuestros servicios en tanto en cuanto seamos capaces de acordar unos niveles de flexibilidad adecuados.

Rafa ha añadido un comentario interesante a este post:

“Creo que lo que busca un cliente (sea interno o no) es la satisfacción de una necesidad (y quizás estoy pensando más en nuevos proyectos que en soporte). En ese caso, no creo que la rigidez vaya siempre en contra del valor añadido.
...
Quizás la flexibilidad no es tanto ser el restaurante (o la casa), sino ser McDonalds-Burguer-Restaurante-Casa en función del cliente y la necesidad. ”

Efectivamente, estoy de acuerdo contigo. Ahora bien, creo que el problema aparece cuando en realidad tienes muchos clientes (ya sean internos o no) y tienes que adecuar el servicio en función de cada uno de ellos. El extremo más radical sería que cada usuario pudiera pedir (o exigir bajo contrato de SLA) unas características diferentes en términos de calidad y cantidad para un servicio determinado: ¿Qué pasaría si cada usuario pudiera pedir diferentes SLOs para el servicio de correo --el más clásico de los servicios --?

Si cada usuario pudiera "ajustarse" sus características, tendrías que controlar las quotas, los filtros anti-spam, las listas de correo, etc por cada uno de ellos!! --INVIABLE--

Claro, si nos vamos al otro extremo, llegamos al nivel "Café para todos": el correo en esta casa es asi, asi y así para todos los usuarios y no hay excepciones. --INVIABLE--

Así, y como casi siempre, la solución no está en los extremos sino que en un punto medio en el que la satisfacción de los clientes y usuarios se equilibre con el coste en el que incurres para gestionar el servicio de una forma adecuada.

MEHGEST cobra vida propia

A la vista de la situación en que la documentación de MEHGEST iba creciendo y creciendo y me iba copando el blog de Gobierno TIC, he pensado que lo mejor sería que MEHGEST tuviera su propio espacio y viviera una vida independiente pero seguida de cerca.

Es por esta razón hoy ha celebrado la inauguración de su nuevo entorno, y a partir de ahora, toda la información relativa a MEHGEST la podrán encontrar en http://mehgest.blogspot.com

¡¡Buena Suerte y Larga Vida!!

El nacimiento de MEHGEST

A la vuelta de vacaciones habrá que plantearse nuevos retos, nuevos proyectos y posiblemente nuevos presupuestos para el siguiente año. Algunos de estos nuevos retos incluirán el pensar seriamente en escoger una herramienta adecuada para implantar una buena gestión de servicios, y uno nunca sabe por dónde empezar; así que si el tiempo lo permite empezaremos con una serie de consejos para tener al menos unos criterios válidos para escoger una de las muchas herramientas que propone el mercado (o decidirse a desarrollar una herramienta propia que se adapte a lo que queremos).

Para poder escribir este post con “cara y ojos”, primero pensé que debía hacer un índice de todos aquellos requisitos o características que se deben mirar en una herramienta, listarlos y luego ir desarrollando cada uno de los temas en sucesivos posts, pero a medida que iba haciendo la lista se fue haciendo más y más grande, así que me emocioné, cambié del Word al Excel, y casi sin darme cuenta me he montado la primera versión de la Matriz de Evaluación de Herramientas de Gestión de Servicios TIC (MEHGEST).

El trabajo que queda por hacer ahora se “reduce” a puntos como pueden ser:

• Explicar detalladamente qué significa cada uno de los criterios de evaluación que aparecen.
• Ampliar la herramienta con los criterios generales que cada uno de los lectores o usuarios propongan
• Ampliar la herramienta con una pestaña por cada proceso (con criterios específicos para el proceso)

Por lo pronto, MEHGEST queda a disposición del público bajo una licencia Common Rights de tal forma que puedes usarla y modificarla siempre y cuando compartas las modificaciones y cites la fuente.

Espero comentarios sobre su uso y cualquier tipo de sugerencia al respecto, pero has de saber que no soy ningún experto en Excel y no implementaré grandes virguerias porque no se me da.