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.
domingo, 31 de diciembre de 2006
domingo, 24 de diciembre de 2006
Restricciones que aportan
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.
lunes, 18 de diciembre de 2006
el valor percibido
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.
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.
viernes, 15 de diciembre de 2006
No perder el norte
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.
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.
miércoles, 13 de diciembre de 2006
Alcance y detalle
¿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.
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.
sábado, 9 de diciembre de 2006
Lo que le falta a ITIL
Hace un par de días, leía un gran artículo de Antonio Valle, en el cual comentaba lo que le falta a ITIL.
Es una excelente reflexión, que va citando punto por punto las carencias que tiene este conjunto de mejores prácticas.
Leyéndolo, recordé mi primera aproximación a ITIL. Cuando comencé a leer los libros, ver la estructura por procesos, pensé que iba a ser algo útil para desplegar en mi organización.
Sin embargo, cuando tuve los primeros contactos con proveedores sobre el tema, fue cuando comencé a no verlo tan claro. Dudaba incluso si había entendido bien lo que era, o lo que se podía hacer con ITIL
Fue un enfoque muy "de hierro", supongo es una herencia derivada de que los primeros en promocionar esto, hayan sido precisamente los fabricantes de hardware. Aún así, tras cada reunión mi ánimo decaía aún más, tras escuchar las maravillas de la CMDB identificando fuentes de alimentación de servidores, y estableciendo el impacto sobre los servicios. Servicios además definidos en términos totalmente ajenos al negocio.
En ese momento, más que carencias lo que encontré fue un problema de compatibilidad (¿necesito yo esto?, ¿me vale? y lo que creía en esos momentos es que NO).
Sin embargo, se hizo la luz y encontramos a un proveedor con otra visión. No está vinculado al mundo del hardware, ni atado a ninguna herramienta, por lo que su visión era mucho más abierta. Fue como un soplo de aire fresco, e ITIL recobró para mi su aspecto inicial.
Está claro que tiene limitaciones, pero yo creo que la fundamental a evitar es la de la manera en la que te aproximas a él.
Espero escribir en breve un pequeño artículo sobre como estamos enfocando Gestión de Capacidad, y CMDB, para ilustrar un poco más esto.
PD: Saludos a todos, he comprobado que tengo lectores. Lo cual me ha alegrado bastane, y me ha animado aún más el hecho de que hayan dejado comentarios.
Muchas gracias.
Es una excelente reflexión, que va citando punto por punto las carencias que tiene este conjunto de mejores prácticas.
Leyéndolo, recordé mi primera aproximación a ITIL. Cuando comencé a leer los libros, ver la estructura por procesos, pensé que iba a ser algo útil para desplegar en mi organización.
Sin embargo, cuando tuve los primeros contactos con proveedores sobre el tema, fue cuando comencé a no verlo tan claro. Dudaba incluso si había entendido bien lo que era, o lo que se podía hacer con ITIL
Fue un enfoque muy "de hierro", supongo es una herencia derivada de que los primeros en promocionar esto, hayan sido precisamente los fabricantes de hardware. Aún así, tras cada reunión mi ánimo decaía aún más, tras escuchar las maravillas de la CMDB identificando fuentes de alimentación de servidores, y estableciendo el impacto sobre los servicios. Servicios además definidos en términos totalmente ajenos al negocio.
En ese momento, más que carencias lo que encontré fue un problema de compatibilidad (¿necesito yo esto?, ¿me vale? y lo que creía en esos momentos es que NO).
Sin embargo, se hizo la luz y encontramos a un proveedor con otra visión. No está vinculado al mundo del hardware, ni atado a ninguna herramienta, por lo que su visión era mucho más abierta. Fue como un soplo de aire fresco, e ITIL recobró para mi su aspecto inicial.
Está claro que tiene limitaciones, pero yo creo que la fundamental a evitar es la de la manera en la que te aproximas a él.
Espero escribir en breve un pequeño artículo sobre como estamos enfocando Gestión de Capacidad, y CMDB, para ilustrar un poco más esto.
PD: Saludos a todos, he comprobado que tengo lectores. Lo cual me ha alegrado bastane, y me ha animado aún más el hecho de que hayan dejado comentarios.
Muchas gracias.
miércoles, 6 de diciembre de 2006
Herramientitis
El escribir estas cosas desde trabajando en TI, me siento un poco extraño, y me recuerda al viejo refrán de "en casa del herrero, cuchillo de palo". Pero, de cuando en cuando me encuentro en situaciones como esta.
Una vez que despliegas los procesos ITIL en la organización, tienes que ayudarte de una herramienta que permita gestionar los mismos.
Nosotros hemos realizado un desarrollo a medida sobre Remedy, que si bien no es perfecto cumple razonablemente bien su cometido. (permite trabajar, extraer mucha información para indicadores, es razonablemente ergonómico...)
Como es lógico en cualquier herramienta, su evolución esta totalmente abierta a las necesidades de la gente que trabaja con ella. Por lo que es muy normal, tener siempre en cartera pequeños proyectos, que dan respuesta a necesidades puntuales.
Hasta aquí todo bien, pero en ocasiones, es cuando te encuentras con lo que yo llamo "Herramientitis", y es un síndrome que consiste en que cuando se comienza a trabajar sobre un proceso, de repente se entra en una dinámica de solicitudes de cambio a la herramienta, y en la que todo está parado a la espera de que el sistema haga esto o lo otro.
Sucedía el otro día, se planteaban cuestiones sobre la mejora de determinados aspectos en el proceso de gestión de incidencias, temas como el escalado, la comunicación a usuarios de incidencias que afectan al servicio, validación para evitar duplicados .... Es decir, un montón de temas que ayudan a que mejoren aún más tanto nuestro nivel de cumplimiento, como la percepción por parte de los usuarios.
Pues en esta situación, la dinámica (y que conste que muchas veces me encuentro esto también en negocio, no solo "en casa") fue: Pues Remedy tiene que validar, tiene que comunicar, tiene que escalar, tiene que......
Y lo que creo yo que tiene que ser, siempre es:
YO tengo que validar,
YO tengo que comunicar,
YO tengo que escalar
o YO tengo que lo que sea,
porque YO asumo un rol en el proceso y tengo responsabilidad sobre los eventos que por el circulan. Asumido este planteamiento, es cuando tengo que pedir a Remedy o a quien sea que me ayude a hacerlo.
Creo que este punto es fundamental, y es algo que tenemos que inculcar a la organización. Sobre todo ahora con temas como ITIL, dónde hay mucho proveedor ( y de esto hablaré en algún post futuro), que vende un proyecto de organización y de cambio, como implantar ITIL, como si fuese un proyecto tecnológico de implantación de una herramienta, que "supuestamente" lo hace todo "automáticamente"
Una vez que despliegas los procesos ITIL en la organización, tienes que ayudarte de una herramienta que permita gestionar los mismos.
Nosotros hemos realizado un desarrollo a medida sobre Remedy, que si bien no es perfecto cumple razonablemente bien su cometido. (permite trabajar, extraer mucha información para indicadores, es razonablemente ergonómico...)
Como es lógico en cualquier herramienta, su evolución esta totalmente abierta a las necesidades de la gente que trabaja con ella. Por lo que es muy normal, tener siempre en cartera pequeños proyectos, que dan respuesta a necesidades puntuales.
Hasta aquí todo bien, pero en ocasiones, es cuando te encuentras con lo que yo llamo "Herramientitis", y es un síndrome que consiste en que cuando se comienza a trabajar sobre un proceso, de repente se entra en una dinámica de solicitudes de cambio a la herramienta, y en la que todo está parado a la espera de que el sistema haga esto o lo otro.
Sucedía el otro día, se planteaban cuestiones sobre la mejora de determinados aspectos en el proceso de gestión de incidencias, temas como el escalado, la comunicación a usuarios de incidencias que afectan al servicio, validación para evitar duplicados .... Es decir, un montón de temas que ayudan a que mejoren aún más tanto nuestro nivel de cumplimiento, como la percepción por parte de los usuarios.
Pues en esta situación, la dinámica (y que conste que muchas veces me encuentro esto también en negocio, no solo "en casa") fue: Pues Remedy tiene que validar, tiene que comunicar, tiene que escalar, tiene que......
Y lo que creo yo que tiene que ser, siempre es:
YO tengo que validar,
YO tengo que comunicar,
YO tengo que escalar
o YO tengo que lo que sea,
porque YO asumo un rol en el proceso y tengo responsabilidad sobre los eventos que por el circulan. Asumido este planteamiento, es cuando tengo que pedir a Remedy o a quien sea que me ayude a hacerlo.
Creo que este punto es fundamental, y es algo que tenemos que inculcar a la organización. Sobre todo ahora con temas como ITIL, dónde hay mucho proveedor ( y de esto hablaré en algún post futuro), que vende un proyecto de organización y de cambio, como implantar ITIL, como si fuese un proyecto tecnológico de implantación de una herramienta, que "supuestamente" lo hace todo "automáticamente"
Suscribirse a:
Entradas (Atom)
