TI el motor de la generación de valor

la cuenta por favor.

noreply@blogger.com (Manuel) — Mon, 08 Oct 2007 07:48:00 +0000

Tras un mes fuera del mundo TIC, la verdad es que no dejo de sorprenderme de la capacidad humana para "desaprender", olvidarse de todo y cambiar totalmente de tercio.

Después de casi un mes, me ha llegado una invitación de Antonio Valle, para que continúe con una serie de reflexiones acerca de como valorar un servicio profesional.

Todo empezó aquí, para seguir con la anecdota de la guerra fría en este, para tener más tarde otra buena réplica.

Ahora me toca a mi. La verdad es que en este mes de desconexión, me ha servido para ver las cosas desde fuera, y comprender como se ven las cosas desde el otro lado.

La verdad es que el debate surge porque es complicado. En mi opinión es difícil poner precio a la experiencia, habilidad, y capacidad de una persona. Y si estamos hablando de algo, en ocasiones tan intangible como la consultoría TIC, pues aún más.

Para polemizar un poco con lo anterior, he de decir, que es verdad, en ocasiones el cliente no valora la aportación del profesional en su justa medida, por lo que se dan situaciones de ese tipo, no le vas a cobrar lo que crees que vale, y optas por una solución de compromiso que salve tú orgullo y la amistad.

Pese a esto, he de decir que en mis años de experiencia en TI, he visto facturar por cosas, que si te paras a pensarlas no son más que una tomadura de pelo. Supongo que todos habremos visto, más o menos de cerca facturar unos buenos euros por un mal trabajo de copio/pego/copio/pego.

En resumen, que nos encontramos en una situación difícil por dos motivos. El primero es que el cliente en ocasiones no alcanza a ver el valor de nuestra aportación, si esto sucede ya no es un problema de lo duro que sea negociando, sino que no lo va a ver. El segundo, es el mercado quemado que han dejado muchos por ahí, y que hace que la gente vea la consultoría con recelo.

¿cómo lo arreglamos?
Yo creo que lo fundamental son dos pasos. El primero es conocer al cliente, entender sus necesidades, y ver si de verdad nuestro producto encaja o no.

Eso lo veo claro ahora, estoy al frente de una Pyme, con un volumen de facturación decente, tenemos muchos proyectos abiertos, y se(porque vengo de allí), que habría cosas para hacer en TIC, que resultarían muy interesantes. Sin embargo, por el momento, la cultura, la estrategia no vamos a hacerlos. Por lo tanto, difícilmente voy a pagar un servicio a su justo precio, si creo que no lo necesito.

El segundo paso, es poner en valor el servicio. Creo que el precio de un servicio siempre ha de ser función de su resultado, tendrá mayor o menor correlación, pero creo que un servicio ofertado puntualmente tiene que venderse de ese modo.

Si consigues argumentar y explicar la relación entre tú servicio y un valor creado, lo cuantificas y te asignas un importe, el único tema que queda abierto es la negociación de si te llevas más o menos, y eso se arreglará sin lugar a dudas.

Si esto lo llevas a proyectos TIC, se que es complicado. ¿Como valorar el efecto de tu trabajo en un proyecto con su propio y nebuloso Business Case?.

Pues seguro que es difícil, pero yo desde aquí lanzo mi propuesta. Compromiso con los resultados de negocio.

Si hago un proyecto de BI, para analizar las pautas de consumo, y con ello mejorar las ventas, o aumentar la fidelización. Compromete tú servicio con el resultado, € más de ventas, mejora en la fidelización del XXX €.

Ya se que dependes de muchas cosas, del mercado, de la competencia, del tio de marketing que no tiene ni idea, de que si este invierno llueve menos, que si el Euribor ......

Si quieres cobrar lo que vale, demuestra y compromete lo que vale, y si no, factura horas.

Despedida y cierre

noreply@blogger.com (Manuel) — Wed, 08 Aug 2007 18:54:00 +0000

Hola a todos, después de unos meses con este blog, con una actividad modesta, llega el momento del cierre.

Más que cierre reorientación, ya que a finales de este mes dejaré de dedicarme profesionalmente al mundo TIC, para asumir la dirección de un negocio mucho más tradicional.

El cambio es grande, pero espero que todo lo que he aprendido durante estos años me sirva para, desde un ámbito distinto aportar lo máximo posible en esa generación de valor de la que habla el título del blog.

Me voy justo ahora, con la CMDB integrándose en los procesos, con la gestión finaciera en mente ...
pero bueno, espero que todo esto siga su curso y al final se continúe persiguiendo ese objetivo, el alinear y el conseguir ese entendimiento a veces complicado entre negocio y TI.

Os agradezco a todos vuestras visitas, y lecturas, así como los comentarios que me han llenado de ánimo y de ganas para continuar con esto.

Por fin vacaciones

noreply@blogger.com (Manuel) — Tue, 03 Jul 2007 10:20:00 +0000

Bueno, este año ya me he quejado de las muchas horas que paso en la oficina. (porque yo quiero, todo sea dicho). Así que también toca anunciar, las buenas nuevas, cuando toca como es el caso.

Estoy de vacaciones, un par de semanitas que me vendrán muy bien. Y para desconectar, pues nada mejor que dejarlo todo e ir hasta los Pirineos en mi moto. Espero volver con las pilas cargadas.

Nuevos horizontes. Kaizen

noreply@blogger.com (Manuel) — Tue, 03 Jul 2007 09:53:00 +0000

El pasado lunes asistí a unas jornadas sobre Kaizen, organizadas por la Escuela de Negocios Caixanova.

El entorno, tanto en lo referente a asistentes, como ponentes era muy industrial, con una presencia muy importante del automóvil. Algo normal, si se tiene en cuenta que el organizador era el Cluster de Empresas de Automoción de Galicia.

Lo primero que me llamó la atención, es lo lejos que en principio parece estar un entorno fabril, comparado con el entorno de servicios TIC en el que me muevo habitualmente. Da la impresión, de que es un mundo más maduro, un entorno físico dónde las cosas se ven y se tocan.

Sin embargo, escuché con gusto las palabras del Sr. Masaaki Imai, qué más que experiencias prácticas o tangibles, nos dio una deliciosa charla acerca de la filosofía Kaizen.

Me gusto mucho el hecho de que se centrase, en lo que aporta valor. El valor se aporta en el Gemba, el taller, el lugar dónde suceden las cosas.

Su charla hablaba de cómo este el sitio en el que trabajar para conseguir la mejora, siempre pensando en como eliminar la "muda" (desperdicio), para conseguir mejorar los procesos.

Tras la charla me quedó claro como funciona, pero comencé a dar vueltas en cómo esto se podría adaptar a una organización que desarrolla y presta servicios TIC.

Al llegar a mi oficina, empecé a buscar el gemba. ¿dónde está?. Realmente dónde suceden las cosas, es en los puestos de los programadores, de los analistas, de los agentes del Service Desk, de los técnicos de sistemas, de los DBA's ....

Con todo esto de ITIL, COBIT, Gobierno IT, estamos trabajando en crear una capa de control, y de coordinación entre procesos, pero en ocasiones es preciso levantar la vista, y darse cuenta que no son fines, son medios para, dicho en términos Kaizen, eliminar muda en el gemba.

Una de las historias que más me gustó, es cuando comentaba que hacía él cuando llegaba a una planta. Se iba el gemba, siempre. Y una vez allí, la manera de identificar quien está agregando valor y quien no, es la verdad curiosa y sencilla. Los que mueven los dedos, son los que están aportando valor. Los que hablan, pasean, fuman, toman café no están agregando valor. Se que es otro entorno, pero no deja de ser aplicable.

En resumen, la jornada ha sido muy interesante, porque a veces abrir nuevos horizontes, y mirar en otros contextos ayuda a enriquecer la visión que puedes tener de cómo hacer las cosas.

¿Qué ha sido del propósito del fin del overtime?

noreply@blogger.com (Manuel) — Mon, 18 Jun 2007 06:35:00 +0000

Empezaba este 2007, con este post. Totalmente comprometido con la causa de acabar con el tiempo extra en la oficina.

Medio año después, solo puedo decir que recuerdo con cariño las primeras semanas del año, en las que me iba a casa a las 20h.

Cambios organizativos, cambio de proveedor con un servicio importante, nuevas responsabilidades, y un proyecto de lanzamiento han terminado por dinamitar todo esto.

La buena noticia es que mis fines de semana, siguen casi intactos, pero de lunes a viernes, la jornada se vuelve a hacer extra-larga.

Si fuese una situación puntual, pues no me preocuparía, pero empiezo a pensar que esto, en el mundo TIC funciona así.

Mantengo mi idea, acerca de que trabajar así no es bueno. Baja la productividad, pero claro, siendo ya un poco malpensado uno se da cuenta, que asumen más costes el que lo hace que el empleador.

Tal vez sea preciso comenzar a tratar esto como una externalidad. Realmente se están generando costes (personales, sociales ...) que seguramente a nivel agregado son mayores que los beneficios también agregados de esta práctica, sin embargo mientras no los pague el que puede evitarlos, difícilmente desaparecerán.

Nuevo esquema de certificación ITIL

noreply@blogger.com (Manuel) — Sat, 26 May 2007 11:02:00 +0000

Hola a todos, tras un parón en la escritura vuelvo a la carga. La verdad es que los principales motivos para no actualizar más esto, es que lo que cuento es fácilmente identificable por cualquiera que esté trabajando con nosotros, y la verdad es que no quiero que se mezclen opiniones personales, con decisiones que se toman en la compañía.

Dicho esto, contar que de nuevo, pese a ser un "fan" de ITIL, COBIT y demás, he vuelto a entrar en crisis. Creo que ya es un problema personal, les tengo manía a la gente de Delivery de los grandes fabricantes. (en realidad son tios majos, y saben mucho, pero tienen un punto que no).
Ya estoy cansado de sus informes, de su cuestionario sobre procesos ITIL, que con la respuesta que da la gente, ya da un estado de madurez, unas propuestas de mejora, y un comentario muy "molón".

Da miedo, la factoría de industrialización de ITIL está a pleno rendimiento, montones de jovenes salen con sus super excel que generan super informes, han salido a la calle a poner orden en el caos.

Tan receloso estoy, que hasta se me está pasando por la cabeza prohibir citar a ITIL para argumentar cualquier cosa. A veces parece el totem, la piedra filosofal que responde a todo.

Slogan fácil: ITIL si pero no así.

En tono de humor voy a poner una serie de requisitos indispensables, para poder hablar de gestión de servicios TIC:

Haber pisado alguna vez un CPD
Haber vivido una recuperación de BBDD de ese sistema tan crítico, que cuando de verdad pasa, la gente de negocio ya no grita, ni protesta, te mira en silencio, buscando la confianza en esa gente de TI, que habla raro, que no duerme, que están como locos.
Haber pasado una migración a producción, de esas que son necesarias para hacer cualquier cosa que la dirección ha dicho a los cuatro vientos que se va a poder hacer el día xx.
Haber discutido de verdad (no en laboratorio), el famoso PIR después de ese cambio de versión, con un responsable de negocio "de verdad".

Se me ocurren unas cuantas más, pero creo que es suficiente.

Los procesos están muy bien, pero si todos estuviesen en los maravillosos niveles optimizados, no haríamos falta las personas. El proceso, o sus deficiencias no son justificación para los resultados. Para eso estamos nosotros, para hacer que las cosas salgan adelante, si los procesos , si ITIL o sin San Pancracio nos ayudan pues mucho mejor.

Buscando fuentes para procesos de negocio

noreply@blogger.com (Manuel) — Sat, 28 Apr 2007 08:05:00 +0000

Hola a todos, hasta ahora centraba tanto mi actividad profesional como mi actividad bloguera en el mundo TIC.

Ahora, que me tengo que poner con el tema de Organización y procesos, necesito encontrar fuentes menos TIC, y más generales. Si alguno tiene algunas referencias por ahí, estaría muy agradecido si me las pasa.

De todos modos, espero ir ampliando los horizontes tanto de mi blogroll, como de los post que vaya colgando por aquí.

Empresa 2.0

noreply@blogger.com (Manuel) — Tue, 10 Apr 2007 06:41:00 +0000

En estos días en los que me estoy alejando un poco de lo que es la gestión y el gobierno TI, para tratar de hacer algo en lo referente a organización y procesos estoy leyendo todo lo que puedo acerca del uso de herramientas 2.0 en un entorno empresarial.

De hecho, en TI, hace ya casi medio año que hemos montando un blog y una Wiki, para que sirva el primero de canal de comunicación adicional y el segundo de repositorio de información.

Ahora, pensando ya en toda la organización se me plantean un montón de dudas acerca de como enfocar este tema.

Realmente, tanto el blog como la Wiki del departamento no han tenido prácticamente éxito, se publica muy poco. Y yo suelo ser uno de los autores más fecundos, por lo que no deja de ser "mi experimento", en lugar de una plataforma para la colaboración.

Razones por las que creo que sucede esto:

Interface único. La gente, por la experiencia que yo tengo, quiere una única interface para gestionar su trabajo. El Rey en mi empresa es Outlook. O fuerzas el cambio y obligas a que todo el mundo a utilizar la nueva plataforma, o va a ser muy difícil que trabajen con las dos.

Falta de incentivos para aportar contenido. Si seguimos gestionando a la gente con los esquemas tradicionales, y no encuentran incentivos para publicar o compartir su información difícilmente lo van a hacer. De hecho, ya se ha institucionalizado el decir que si alguien escribe cosas de interés en el blog o la wiki, es porque tiene mucho tiempo libre.

Resistencia al cambio. Si bien, a algunos nos encanta experimentar con nuevas herramientas, no debemos de olvidar que se debe a que se trata de "jugar" con algo que nos parece entretenido. No todo el mundo comparte esta visión, y realmente trabajar con un ordenador, les parece exactamente eso, "trabajar", y no perciben ningún tipo de satisfacción por probar herramientas nuevas.

Falta de compromiso de los gestores. Si nosotros como gestores, y nuestros jefes por un lado trasladamos el mensaje de utilidad de este tipo de herramientas, pero después a la hora de la verdad no las utilizamos (comunicaciones importantes, seguimiento de proyectos de gran calado ....) es prácticamente imposible que funcione.

Obsesión por la confidencialidad. En los tramos medios y superiores de la jerarquía, al menos en mi organización, existe una gran concienciación respecto a la confidencialidad. Entendiendo esta como el control de acceso a documentación (no me meto ya en el tema de datos de carácter personal, que ya es otra película). A mi modo de ver es más una obsesión que una amenaza real. Muchas veces se habla de poner a disposición de la gente, únicamente lo estrictamente necesario para que pueda realizar su trabajo, aunque es muy normal que queriendo eso para los demas, para nosotros querramos acceso a múltiples fuentes que nosotros discriminaremos con nuestro criterio. Entiendo que hay mucha documentación, más que confidencial, yo la llamaría sensible, que debe de ser tratada con cautela (temas de organización RRHH, salarios, precios ....), pero el resto, la verdad es que creo que no es necesario censurarla. Es más, si alguién realmente quiere algún documento para hacer algo inadecuado, seguramente lo consiga pese al control que tengamos establecido.

Estas son las principales razones que yo veo para que resulte difícil el difundir el uso de este tipo de plataformas, de todos modos yo creo que cada una de ellas puede ser atacada de manera eficaz. Yo al menos seguiré intentándolo.

dèjá vu

noreply@blogger.com (Manuel) — Fri, 30 Mar 2007 06:31:00 +0000

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

noreply@blogger.com (Manuel) — Wed, 28 Mar 2007 18:52:00 +0000

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

noreply@blogger.com (Manuel) — Wed, 28 Mar 2007 06:21:00 +0000

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

noreply@blogger.com (Manuel) — Mon, 19 Mar 2007 21:54:00 +0000

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

noreply@blogger.com (Manuel) — Sat, 17 Mar 2007 08:27:00 +0000

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

noreply@blogger.com (Manuel) — Fri, 16 Mar 2007 07:19:00 +0000

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

noreply@blogger.com (Manuel) — Wed, 14 Mar 2007 23:11:00 +0000

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.

Nota sobre las fotos

noreply@blogger.com (Manuel) — Fri, 02 Feb 2007 15:47:00 +0000

En este blog, de post en post, suelo acompañar el mismo de alguna foto. Como muchos habréis ya supuesto las fotos no son mías, las busco en Internet y solo las posteo si el contenido está bajo licencia Creative Commons. Sin embargo, pese a no modificar el trabajo inicial, y no tener este blog fines comerciales, he fallado en el reconocimiento.

Debería de haber identificado a los autores de cada foto, y sin embargo no lo he hecho. Ahora es complicado ya que en el enlace a Flickr no nos lleva al autor. Intentare ver si es posible obtener a los autores de una manera sencilla, y corrijo este error.

Aprovecho, y acompaño este post con una foto, de la que, en este caso si soy yo el autor. Se trata de una playa en un pequeño pueblo, el primero si no me equivoco de la "Costa da Morte", un lugar tranquilo y altamente recomendable si lo que quieres es pasear y alejarte del mundanal ruido por unos momentos.

¿y los proyectos?

noreply@blogger.com (Manuel) — Thu, 01 Feb 2007 18:39:00 +0000

Desde que comencé a examinar lo que es ITIL, me di cuenta que uno de los puntos flojos que tenía era todo lo referente a desarrollo de nuevas funcionalidades/sistemas.

Todos los procesos de ITIL, están orientados a mantener la maquinaria funcionando con los niveles de servicio establecidos. Después, tienes algún proceso como gestión de cambios, que podría hacer de puente con la parte de desarrollo, pero que se queda corto para gestionar un flujo de modificaciones en los servicios que se pueda derivar de la actividad normal del negocio.

Para la parte de desarrollo, tenemos CMMi, pero el hecho de que nosotros no desarrollemos sino que gestionamos a equipos de desarrollo de proveedores externos, hace que muy probablemente nos quede un poco grande.

Con este panorama, al final nos fuimos a por algo para gestionar proyectos. Y el ese "algo", finalmente fue PRINCE2.

Los motivos de elegir PRINCE2 y no otra metodología como PMBOk o similar, fueron básicamente la cercanía en nacimiento de PRINCE2 con ITIL, ya que ambas fueron alumbradas en el seno de la oficina de comercio británica (OCG).
Junto con esto, la otra razón era que podríamos repetir la buena experiencia que tuvimos con el proveedor que nos formó en ITIL, ya que en su cartera de cursos también tenían PRINCE2, que por lo que he visto todavía no es muy popular en España.

Una vez realizada la formación a todo el grupo, la verdad es que el sabor de boca que nos ha dejado es bueno.
Estamos en lo de siempre, se trata de una herramienta, y por tanto, ella por si misma no va a solucionar todos esos problemas que nos encontramos durante la ejecución de los proyectos. Pero en lo que si creo que nos va a ayudar es en el de establecer unas reglas de juego, unos criterios transparentes sobre los cuales vamos a evaluar el progreso del proyecto.

En PRINCE2, todo el modelo gira entorno al business case, que define como aquel documento en el que él que solicita el proyecto (normalmente alguien de negocio), justifica la necesidad del mismo. Este documento se debe de mantener vivo a lo largo de todo el proyecto, y es la herramienta básica para la dirección del mismo.

Lo que me ha gustado es que pone especial incapié en el arranque/inicio de proyecto, y después plantea un modelo de dirección por excepción.

Otra cosa que me ha encantado, pero eso ya es debilidad personal que tengo hacia la gente que piensa estas cosas, es su robustez. Es increíble lo coherente que resulta ese conjunto de subprocesos enlazados unos con otros, y que dan salida a todos los "y si ....?, y si ....?" que planteamos durante las jornadas de formación.

Eso si, es enorme por lo que para evitar el convertirse en esclavos de la burocracia será preciso hacer una adaptación, (eliminar documentación y algún subproceso), y emplearlo solo en proyectos de entidad suficiente.

Ya lo hemos puesto en marcha, el primer proyecto que vamos a realizar siguiendo PRINCE2, ya ha sido lanzado. Así que ya iré contando si va bien, o si como se suele decir "del dicho al hecho hay mucho trecho".

parte de Enero

noreply@blogger.com (Manuel) — Tue, 30 Jan 2007 17:17:00 +0000

Pues eso, que ya estamos de lleno en el 2007.

Ha sido un mes complicado, ya que este año estrenábamos con los proveedores la liquidación de variables con cargo a consecución de SLA's. Al final, el resultado general si no excelente, si que se puede calificar de bueno.

Hemos además terminado de ajustar la batería de indicadores con los que vamos a evaluar en 2007.

A todo esto se ha unido el revuelo provocado por un cambio organizativo, mi jefe se va, y ha habido un movimiento bastante grande, tanto en número de personas afectadas como en impacto. Ahora toca esperar como se asienta esto, la verdad es que a mi me ha dejado un poco desconcertado, pero bueno tengo confianza en la dirección, y espero que hayan tomado una decisión acertada.

Todo este conjunto de temas me ha tenido bastante entretenido, y la verdad es que no he podido escribir todo lo que desearía.

retomando la escritura

noreply@blogger.com (Manuel) — Tue, 30 Jan 2007 17:08:00 +0000

La verdad es que cuando comencé a escribir este blog, me preguntaba si tendría cuerda para mucho rato o no. Inicialmente me parecía que tenía muchas cosas que contar, después conforme vas contando algunas ves que cada vez quedan menos.

Sin embargo, lo bueno que tiene esto de los blogs, es que encuentras a gente fantástica que con lo cuentan y dicen te dan gasolina infinita para seguir opinando.

Así que tras un parón que coincide con la cuesta de Enero, espero mantener un discreto ritmo de publicación.

Propósito para 2007. Fin del Overtime

noreply@blogger.com (Manuel) — Sat, 06 Jan 2007 12:44:00 +0000

Overtime, anglicismo que por lo menos en mi experiencia, es algo común, yo diría muy común en el mundo de TI.

Por mi observación personal, creo que por lo general, al menos en mi organización el echar horas de más en la oficina, es algo para lo que la gente de TI podría optar a pelear por el título de mayor tiempo de permanencia en la oficina.

Supongo que es algo que también viene heredado del pasado en consultoría de la mayor parte de nosotros. De hecho, analizando conversaciones, actuaciones, omisiones ... uno se da cuenta de que el tiempo extra es algo bien visto, cuando tal vez debería de ser un gran pecado.

Comentarios como los de, "fulano vive como un rey todos los día se va a la hora", o preguntar por alguién a las 20:30, y decir sorprendido, "pero ¿ya se ha ido?", son cosas que se escuchan todos los días, y que contribuyen a crear y mantener esa ley no escrita, de que profesionalidad y compromiso se demuestran saliendo tarde.

Mi opinión respecto al overtime, pues supongo que será la de la mayoría de vosotros. Es improductivo, hace que no valores tú tiempo de oficina ni el de los demás, ya que la presencia de la gente hasta altas horas, es algo que se da por supuesto.

Favorece un entorno de interrupciones, de trabajo poco intenso ... y sobre todo de queme en la gente que quiere tener vida fuera del trabajo.

En las razones de que exista, yo estoy muy de acuerdo con los autores de Peopleware, sirve para quitarnos sentimiento de culpa. No he cumplido, pero me quedo todos los días hasta las 11.

Dicho todo esto, yo en 2007 he decidido dar un paso más para acabar o por lo menos mitigar este fenómeno en mi organización.

Me he puesto como norma salir todos los días a mi hora. Si algún día salgo más tarde, tendré que anotarlo en una excel en la que indicar el motivo concreto por el que me quedo. (y no valen genéricos como revisar correo, adelantar un informe ...)

Esa norma la aplico a mi equipo, todos tienen la orden de salir a la hora. El que no lo haga, me tiene que justificar por qué se ha quedado más tiempo. (en los mismos términos en los que lo hago yo conmigo mismo).

¿que espero conseguir con esto?, pues que se contagie y que el resto de la gente me copie.

Creo que este tipo de inciciativas tenemos que moverlas desde la gente que tenemos algún nivel de responsabilidad, para que por lo menos arranque con un poco de suerte.

Es posible que en un primer momento cause algún tipo de tensión con compañeros o con mi jefe, (espero que no). Pero creo que la transparencia es siempre lo mejor, y el hecho de que yo haya hecho público mis nuevas normas de comportamiento espero que ayude.

Al final como todo en la vida, no hay soluciones mágicas, yo creo que en ocasiones en 2007 me quedaré más tiempo de lo debido, pero al menos seré consciente de ello, y de que se trata de algo excepcional.

Bueno, ya os iré comentando como va mi propósito. Otra cosa, animo a todo el que lea esto a que haga algo parecido. A ver si conseguimos salir de la lista de país europeo menos productivo, y que más horas "trabaja" o más bien, que más horas está en la oficina.

Indicadores, SLA's y fe

noreply@blogger.com (Manuel) — Sun, 31 Dec 2006 10:15:00 +0000

Hola a todos, el año se termina, por lo que aprovecho para desear a todos un buen 2007, en el que podáis disfrutar y aprender mucho.

El inicio de año, hace que también se tengan que reajustar los indicadores, y si trabajas en un entorno en los que mides y pagas por cumplimiento de los mismos, pues es posible que toque reajustar umbrales.

Aquí viene el problema, por un lado está claro que los procesos medibles, y gestionados te permiten avanzar, y que cada año tienes que fijarte unos objetivos mejores y más exigentes. Pero cuidado, los indicadores son el cemento que dan cohexión al funcionamiento de los procesos.

Mi experiencia práctica en el despliegue, y la vinculación de la evolución de los mismos con el desempeño de cada servicio, es que es una herramienta muy poderosa. Es fijar un objetivo, definir los criterios de medición, y ya tienes a todo el mundo remando hacia ahí.

Pero como decía Spiderman en la película, un gran poder conlleva una gran responsabilidad.

Si te confundes en la fijación del indicador, si la definición tiene una laguna, puedes tener un ejército remando en dirección distinta a la que quieres, y una vez que sucece esto es complicado arreglarlo.

El otro riesgo importante, y es el que quiero evitar para 2007, es fijar unos valores demasiado exigentes, que provoquen que el propio sistema de incentivos pierda su utilidad.

Si te pasas, pierdes el sistema. Además no solo va a afectar a la evaluación, sino que los propios procesos se ven resentidos, si los indicadores con los que los controlas han perdido su valor.

Lo dicho, un saludo y buenos deseos para 2007.

Restricciones que aportan

noreply@blogger.com (Manuel) — Sun, 24 Dec 2006 10:15:00 +0000

El otro día, dediqué media mañana a algo que siempre digo que tengo que hacer más de lo que hago, y que no es otra cosa que hablar de manera amigable con el cliente.

La verdad que es bueno el tener lazos informales con los responsables de negocio a los que das servicio, ya que siempre tienes acceso a más información, te cuentan cuales son sus problemas, y tú puedes siempre vender un poco mejor lo que se está haciendo para ellos.

Durante la conversación, hablamos de cosas que teníamos en marcha, cosas que iban bien, otras que iban fatal, y en un momento dado, él me dijo que tenía la impresión de que desde TI ibámos siempre años atrás de lo que demandaba el negocio, al menos por su parte.

En este punto, pasó a enumerar proyectos que están siendo acometidos ahora, y que ya había solicitado hace 2 años. Aquí, yo contesté indicando que sin embargo se habían realizado otras cosas increibles, y que mejoraban muchísimo alguno de los procesos en los que él estaba trabajando.

La conversación fue muy interesante, ya que ahí lo que comentó es que, es normal ese desfase negocio- TI, ya que (y esto salió de su boca, no de la mía), todas las áreas están contínuamente cambiando y realizando mejoras en sus procesos, y como somos ya tan dependientes de los sistemas, todo acaba pasando por TI. Y lógicamente esto nos lleva a una situación de congestión, en la que es necesario priorizar.

Esto nos ha convertido, en el sentido de Teoría de las Limitaciones, un cuello de botella para el sistema, siendo en este caso el sistema la compañía, en los planos por lo menos operativo y táctico.

Este hecho, provoca que conforme la compañias se hace más TICdependiente, la responsabilidad que asumimos, ya no solo en temas de contingencias ante desastres, garantías de disponibilidad para no parar al negocio .... sino en cuanto a los instrumentos que damos al negocio, para que pueda asignar correctamente las prioridades, y con ello gestionar el cambio de manera óptima, son de vital importancia.

ITIL nos da un marco perfecto para gestionar y evaluar, e incluso valorar financieramente el servicio que ya estamos dándo, pero yo creo que para gestionar el cambio perpétuo en nuestros servicios, nos hace falta algo más.
En próximos artículos, hablaré de como estamos enfocando el tema de los proyectos en mi compañía, y las dudas que me surgen en este proceso.

el valor percibido

noreply@blogger.com (Manuel) — Mon, 18 Dec 2006 21:32:00 +0000

He leído este artículo en el blog de consultoría artesana en la red, que me ha hecho reflexionar sobre el título de mi blog.

TI como motor de la generación de valor, es el nombre de mi blog. Y junto a un título tan "pomposo", surge un artículo en el que se exponen 10 razones por las que los directivos están contra TI.

Más que entrar a analizar las cuestiones, para ello es mucho mejor leer la fuente original, lo que me llama la atención es el título.

Directivos contra las TIC. Es paradójico, que por una lado aquí hablemos de como las Tecnologías de la Información son algo fundamental para la empresa, y que por otro tengamos un artículo, que se hace eco de algo real en el seno de muchos comités de dirección.

Más que desanimarme, esto me motiva aún más para seguir buscando puntos, enfoques, prácticas todo lo que sea, para que consigamos que cada día la percepción de las TIC por parte de los directivos mejore, y mucho.

No perder el norte

noreply@blogger.com (Manuel) — Fri, 15 Dec 2006 20:22:00 +0000

Leo este artículo, y me parece muy interesante como recordatorio de por qué estamos hablando de ITIL, de Gobierno de TI ...

Al final la frase del CEO, de que quiere mayor eficiencia, más proyectos, más fiabilidad y menos coste es algo que no tenemos que olvidar.

Y lo que tenemos que conseguir que no suceda es que la respuesta por parte de nuestra organización, sea la de. Ah, es que yo pensé que el objetivo era implantar ITIL.

Siempre hay que tener en mente al negocio, pero en este punto quiero hacer una matización respecto al artículo.

La postura del director general es clara, el quiere más eficiencia. Ve a TI como un departamento de apoyo al negocio, es más centro de coste que otra cosa.

En una disyuntiva como esta, el CIO, un director de sistemas tiene que dar la vuelta al enfoque, tiene que convencer a su jefe de que TI no resta y el desafío es que reste lo menos posible. No, TI aporta, da valor y eso es lo que tenemos que vender.

ITIL, COBIT, PRINCE2, CMM nos ayudarán en ello, y lo harán que nuestras operaciones sean más controladas y eficientes, pero tenemos que tener en mente siempre el crecimiento.

En una empresa que pretenda ser competitiva hoy en día, la excelencia en la gestión de su información es imprescindible. No hay que pensar en esto como una ventaja tecnológica, sino organizativa.

Ti tiene que proporcionar los engranajes necesarios para que todos los procesos de la cadena de valor funcionen eficientemente, y no solo eso. Tiene también que aportar la flexibilidad necesaria para ajustarse a los cambios en los procesos en un entorno extremadamente cambiante.

Si pensamos así, tal vez nuestro CEO haga con nosotros lo mismo que con el director comercial, primero le pide lo que tiene que vender y después le pregunta lo que le va a costar.

Alcance y detalle

noreply@blogger.com (Manuel) — Wed, 13 Dec 2006 14:35:00 +0000

¿Que alcance quiero para mi CMDB?

El máximo posible. Quiero tener ahí los elementos con los que presto todos los servicios de TI en mi organización.

En cuanto al nivel de detalle, yo aquí diría que tienes que pedir el nivel que seas capaz de mantener, y que sirva al resto de procesos.

Nosotros estamos pensando en una CMDB, que parte de los servicios de soporte a los procesos de negocio, y a partir de ahí va detallando los distintos CI necesarios para la prestación del servicio.

No es una CMDB, al uso con millones de CI's dónde tienes descompuesta toda la infraestructura, sino que tiene varias capas de CI's (software, BBDD, Máquinas, equipamiento de red, equipos humanos ...) relacionados entre si, bajo el agrupador del servicio que están prestando.

Un punto curioso, y que ha llamado la atención a gente que ha pasado por aquí, es el hecho de que metamos a Equipos de Desarrollo dentro de la CMDB, ya que no es muy común tener CI's de naturaleza humana en la CMDB.

Metemos a estos equipos porque a través de los procesos de cambios, gestión de incidencias y gestión de problemas, están modificando de manera contínua la instalación. El hecho de tenerlos dentro me permite que la visión que pueda dar del coste del servicio el proceso de gestión financiera resulte más real, que con el proceso de gestión de capacidad pueda saber cuanta capacidad de desarrollo tengo disponible, y ver con ello que Nivel de servicio en cuanto a time to market puedo dar al negocio.

Creo que al final se trata de dar una visión lo más amplia posible a todos los procesos, de modo que no solo pensemos en que ITIL como un marco que me permite operar servicios dados, sino como algo que me permite gestionar en última instancia el valor que como TI estoy aportando al negocio.

Con esta visión, y enfoque puedes configurar servicios más de negocio, y SLA's que ya no hablen de disponibilidades de red, uptime de servidores .... sino de gestión de incidencias en servicios de soporte al proceso de atención al cliente, o mejora en el time to market en el proceso de definición de la oferta comercial ...

Esto no quita que en la CMDB tengas esquemas complicados, porque las arquitecturas de nuestros sistemas, pese al paso del tiempo siguen siendo complicadas, pero yo creo que es preciso dar ese paso que haga de puente entre los servicios que realmente damos, y todo lo que va por debajo.