dèjá vu

Me ha vuelto a suceder. Proveedor fabricante de los grandes, se acerca a nosotros.

Comenzamos a hablar, parece que nos entendemos, les contamos cual es nuestro enfoque de corresponsabilidad, y de indicadores globales de proceso para todo.

Va bien, parece que lo entiende.

Llega la propuesta, un tocho importante ITIL por aquí, líneas de servicio de preventivo y optimización, todo muy bonito pero ...... ¿dónde están mis métricas?, ¿dónde tengo mis indicadores cutres, sesgados que no miden todo pero que me sirven para medir por igual a todos mis proveedores y hacer que compartan el buen o mal servicio que prestamos al negocio?

Han desparecido, no están. Son "toscos", no miden realmente lo bueno o malo que puede llegar a ser el servicio, realmente, con unos que me traen recien salidos del horno, muy bonitos, que atomizan cada proceso y nos ponen control en cada fase.

Muy bien, muy bonito, pero no es eso lo que yo quiero:

• No quiero un servicio con unos tiempos de respuesta de la leche
• No quiere un servicio con un escalado interno impecable
• No quiero un servicio que tenga mil métricas con valores casi perfectos

Lo que yo quiero, es un servicio que se comprometa con nosotros, y con el resto de proveedores en hacer la vida más fácil a mi cliente interno. Por eso fijamos esos indicadores tan "toscos", y por eso nos medimos todos por ellos (proveedores con su bonus, y empleados con nuestro sueldo variable).

Lógicamente para conseguirlo seguro que tenemos que trabajar en mejorar los tiempos de respuesta, escalados, monitorización, prevención, gestión proactiva de problemas, mejorar la gestión de cambios ..... pero todo esto son medios para un FIN. Dar buen servicio al cliente, eso y solo eso. De nada me vale tener un CPD en perfecto estado de revista, si mi cliente, si la unidad de negocio a la que doy servicio no está contenta, si no le ayudo y le apoyo para que consiga sus objetivos. Porque al final, nuestro objetivo es conseguir clientes e ingresos, y no lo es el tener un CPD y unos sistemas dignos de aparecer en un documental.

Buff ya me he deshaogado, pero me da rabia el contar las cosas tomar mi tiempo en explicar mi visión, para que la entiendan y si dedicen trabajar con nosotros que sepan cuales son las normas del juego, para que después de todo, me lleguen con una propuesta "del manual de delivery".

Los servicios de TI, por mucho que nos cuenten y nos digan, por mucha arquitectura de servicios, virtualización, remotización, gestión dinámica de cargas ..... lo que sea aún no es un commodity. Puede que le falte poco para serlo, pero aún no lo es.

Foto realizad por Dailysnap.

Más notas sobre PRINCE2

Después del comentario que he recibido, en el anterior post en el que hablo sobre los proyectos, me animo a escribir un poco más sobre esta metodología que por lo que he visto, aún no tiene demasiado tirón en España.

PRINCE2 Projects in Controlled Enviroment.
Se trata de una metodología de gestión de proyectos, que en mi opinión es muy consistente.

¿Cómo funciona?

Básicamente todo se inicia si desde la dirección ya sea Ad Hoc, o a través del desarrollo de un programa, un ejecutivo tiene una necesidad y busca el montar un proyecto para darle respuesta.

Lo primero que tiene que hacer es buscar un Jefe de Proyecto, que será el que se responsabilice de llevar a buen puerto el mismo. Con esto nace el proyecto, con lo que se denomina "mandato de proyecto". A partir de ahí entramos en el primer proceso de PRINCE2, Starting Up a Project (SU).

• En SU, hay una serie de subprocesos con los que tenemos que poner en marcha el proyecto. Básicamente se trata de cerrar el equipo de proyecto (resto de miembros de la junta de proyecto), y de trabajar el Business Case y el Project Brief. EL Business Case, es el corazón de la metodología, en este documento debemos reflejar la justificación del proyecto en términos de negocio, los enfoques que manejamos, riesgos, y una estimación previa de costes y beneficios. A lo largo de la vida del proyecto, este documento estará vivo, y se irá actualizando. De hecho, será lo que nos permita en cualquier momento de la vida del proyecto ser justificado por parte del Ejecutivo que ha generado el mismo con su "mandato de proyecto". De SU, se sale invocando al proceso de Dirección del Proyecto (DP), enviando toda la información Business Case, Project Brief con lo que tiene información sobre la justificación, costes estimados (a muy alto nivel), enfoque del proyecto (in house, externalizado, compra, alquiler lo que sea). Con esto, la dirección de proyecto puede o cancelar, o autorizar el inicio del proyecto. De ser así, pasamos al siguiente proceso Initiating a Project (IP).

Me está quedando un post, muy largo, por hoy lo dejo pero en los próximos días continuaré hasta hacer una explicación breve de cada proceso.

Teoría vs Práctica

Ayer mientras leía este post, me daba cuenta de que realmente estaba contando algo muy cercano a lo que se puede vivir en un departamento de TI. Tras pensar esto, reflexioné acerca de si realmente el resto de inquietudes y enfoques que planteamos aquí, son capaces de dar respuesta a este tipo de reflexiones.

Puede ITIL, o COBIT o PRINCE2 o lo que sea dar respuesta a situaciones como esta. Pues la verdad es que por si solos no. Este tipo de problemática hay que atacarla con la capacidad que tenga cada uno para llevar este tipo de situaciones, de todos modos, y esto ya si es mi experiencia personal. Tener unos procesos finos, unas métricas definidas, una gestión de proyectos ponga el acento en la justificación de negocio, pensar en servicios en términos de soporte a procesos de negocio, no soluciona, pero si que nos da muchas armas (tanto ofensivas como defensivas), que pueden ser realmente útiles cuando se presentan estas "batallas internas".

buscando herramientas

Como ya he comentado en anteriores post, parece que este año nos ha tocado llevar temas de Organización y Procesos desde TI, el tema es apasionante, y si bien tengo bastante claro como enfocarlo.

En lo que si que estoy buscando (y agradezco cualquier sugerencia), es qué herramienta utilizar para toda la gestión de contenidos referente a estos temas.

El otro día leía este post, y ya comencé a echar un ojo a esas herramientas.

Os comento lo que estoy buscando, algo flexible, sencillo de usar, con buenas funcionalidades de búsqueda y de control de versiones. Me gusta mucho Mediawiki, pero lo que no me gusta tanto es que no puedes llevar una gestión de usuarios que permita bloquear la edición para un usuario, un grupo ....

Gestión de Configuración

Hola a todos, estamos ya a las puertas de acabar el primer trimestre de 2007, y ya tenemos muy avanzada la parametrización de nuestra CMDB.

La verdad es que da una satisfacción el ver como una vez con el esqueleto ya listo, a través de bastantes reuniones se va poblando cada vez más con múltiples CI's y sus relaciones.

Por ahora, lo tenemos montado en Remedy sin integración con los formularios de gestión de cambios, incidencias y problemas. Estamos un poco en fase Beta, alimentando la BBDD con el inventario de servicios, y con estos hacia abajo identificando y relacionando todos los CI's necesarios para dar soporte al servicio, así como sus relaciones.

En cuanto a la interacción del proceso de Gestión de Configuración con el resto de procesos, también estamos en pruebas. Seleccionamos algunos cambios, para desde el análisis identificar los CI's que se van a modificar, para finalmente cuando se lanza el cambio a producción, proceder a actualizar los cambios en la CMDB identificando los CI's modificados, su versión, el cambio con el que están relacionados.

Las búsquedas para identificar servicios afectados cuando se cae un CI olvidado, ya las hemos usado y la verdad es que con unos resultados muy buenos. Ahora nos toca trabajar en montar indicadores sobre el proceso, y buscar consultas para ayudar a la operativa en otros procesos. He encontrado una buena fuente, para apoyarme en esto en Evergreen.

Si TI construyese aviones

En muchas entradas de este blog, cuando se comentan temas relativos a ITIL, PRINCE2, COBIT... realmente de lo que hablamos es de cómo con estos frameworks, podemos dar a TI esa capa de gestión operativa, y control, necesaria para que nos parezcámos más a otras "disciplinas" más maduras.

Tras ver esta aproximación, a lo que de verdad hacemos en TI, a parte de reirme un poco, me doy cuenta que por muchas capas que pongamos, nuestro trabajo siempre va a estar un poco en el filo de la navaja.



Nota: Tiene gracia que el anuncio sea de EDS, no me imagino yo una versión hispana con Indra, Everis, Accenture o alguna más haciendo una anuncio de este tipo

cerrado por derribo

La verdad es que tengo esto bastante abandonado. Hace mucho que no escribo, y la verdad es que tampoco tengo demasiadas ganas de hacerlo.

El motivo principal es que los cambios organizativos que comentaba en un post anterior, han provocado que me pueda centrar mucho menos en estos temas de lo que hacía unos meses atrás.

Se nos avecina un proyecto muy grande, que va a tener mucho impacto en nuestros sistemas, y además como departamento de TI asumimos la responsabilidad de Organización para toda la compañía.

Todo esto va a hacer que probablemente durante 2007 quite el foco a la organización en TI, para ponerlo en la Organización de los procesos de la compañía y como ligarlos consistentemente con los servicios de TI.

Al menos ya tenemos una CMDB casi totalmente parametrizada, por lo cual presiento que será un buen año para hacer experimentos asociando servicios de TI con procesos de negocio.

Como esto coincide con el superproyecto, y vamos a tener aquí un par de consultoras de las grandes grandes, tendré la oportunidad de ver como está esta gente con estos temas, y como enfoca estos proyectos.

Yo de todos modos seguiré manteniendo mi postura de comunicación, transparencia, información a todo el mundo, y construir los procesos colaborativamente con la gente que trabaja en ellos.