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"
lunes, 4 de diciembre de 2006
La correponsabilidad en cumplimiento de indicadores
Lo bueno de ITIL, como ya he contado en algún post anterior es que ordena de una manera bastante coherente, todos los procesos necesarios para prestar tus servicios de TI con calidad.
Nosotros, dentro del departamento tenemos un modelo bastante externalizado, dónde todo lo que es desarrollo, explotación, operación y puesta en producción y Service Desk está externalizado. Además, lo está en un entorno multiproveedor.
Una vez que formalizas los procesos de gestión de incidencias, problemas y cambios les puedes asignar lógicamente indicadores para medir su evolución.
Aquí, la pregunta llega en la forma de: ¿Cómo voy a trasladar los objetivos de cumplimiento de un determinado nivel en estos indicadores a proveedores que participan en una parte del proceso y no en su totalidad?
La respuesta que nosotros hemos encontrado, y que nos está funcionando es:
CADA PROVEEDOR ES RESPONSABLE DEL VALOR FINAL DEL INDICADOR,
independientemente del grado de participación que tenga en el proceso y del "grado de culpa" que pueda tener si el valor no cumple con el nivel mínimo establecido.
La verdad, es que nos ha costado mucho conseguir esto, pero el resultado está siendo muy bueno.
Con esta corresponsabilidad estamos consiguiendo unos niveles de proactividad y comunicación entre servicios que creo que habría sido imposible de lograr con contratos que fragmentasen los procesos para evaluar a cada grupo en su parcela de responsabilidad exclusiva.
Puedes a partir de un proceso extraer los distintos roles que intervienen, y establecer indicadores de rendimiento y resultado para cada uno de ellos. Puedes incluso hacer el ejercicio, de que la conjunción de los indicadores parciales, arrojen un resultado final coherente. Pero yo creo que es imposible definir en un contrato todas aquellas acciones, que contribuyen a mantener saludables las interfaces en los procesos.
Nosotros con la corresponsabilidad hemos conseguido eso, y creo que es un buen camino a seguir. Ya he contado esto en el foro de Outsourcing del IIR, y lo cuento aquí para animar al resto de clientes que comiencen a pedir esto. El proveedor tiene que apostar por el resultado final, es la manera de que todos estemos alineados con dar valor "de verdad".
Nosotros, dentro del departamento tenemos un modelo bastante externalizado, dónde todo lo que es desarrollo, explotación, operación y puesta en producción y Service Desk está externalizado. Además, lo está en un entorno multiproveedor.
Una vez que formalizas los procesos de gestión de incidencias, problemas y cambios les puedes asignar lógicamente indicadores para medir su evolución.
Aquí, la pregunta llega en la forma de: ¿Cómo voy a trasladar los objetivos de cumplimiento de un determinado nivel en estos indicadores a proveedores que participan en una parte del proceso y no en su totalidad?
La respuesta que nosotros hemos encontrado, y que nos está funcionando es:
CADA PROVEEDOR ES RESPONSABLE DEL VALOR FINAL DEL INDICADOR,
independientemente del grado de participación que tenga en el proceso y del "grado de culpa" que pueda tener si el valor no cumple con el nivel mínimo establecido.
La verdad, es que nos ha costado mucho conseguir esto, pero el resultado está siendo muy bueno.
Con esta corresponsabilidad estamos consiguiendo unos niveles de proactividad y comunicación entre servicios que creo que habría sido imposible de lograr con contratos que fragmentasen los procesos para evaluar a cada grupo en su parcela de responsabilidad exclusiva.
Puedes a partir de un proceso extraer los distintos roles que intervienen, y establecer indicadores de rendimiento y resultado para cada uno de ellos. Puedes incluso hacer el ejercicio, de que la conjunción de los indicadores parciales, arrojen un resultado final coherente. Pero yo creo que es imposible definir en un contrato todas aquellas acciones, que contribuyen a mantener saludables las interfaces en los procesos.
Nosotros con la corresponsabilidad hemos conseguido eso, y creo que es un buen camino a seguir. Ya he contado esto en el foro de Outsourcing del IIR, y lo cuento aquí para animar al resto de clientes que comiencen a pedir esto. El proveedor tiene que apostar por el resultado final, es la manera de que todos estemos alineados con dar valor "de verdad".
domingo, 3 de diciembre de 2006
¿Sabe negocio de negocio?
El otro día leía este artículo en el blog, Gobierno de las TIC. Conocimento adquirido.
Comentaba la gran idea y el gran valor que daba al negocio de un restaurante de comida rápida, la implantación de un sistema de recogida de pedidos vía PDA.
En un comentario que yo le dejé, pues comentaba que el origen de la idea, a mi personalmente me daba un poco igual, y que lo realmente importante es favorecer que exista un caldo de cultivo que favorezca el que surjan iniciativas de este tipo.
De ahí, a mi pregunta con la que titulo el post, solo queda un poco de mala leche.
¿Sabe negocio de negocio?.
En ocasiones, nuestro gran pecado con ese rol de consultor de negocio, es creernos que lo sabemos todo, que tenemos una visión de alto nivel de los procesos, y que por ello que mejor que nuestro criterio para decidir como tienen que trabajar los usuarios.
En mi caso lo he vivido muchas veces, y es verdad que nosotros si conocemos los procesos, y en muchas ocasiones conocemos las conexiones de cada proceso con el resto de una manera más profunda que el cliente. Pero tenemos que contar con él, ya que el está a pie de obra, sabe como trabaja la gente, y tiene en cuenta esos "pequeños detalles" (usabilidad, necesidades de información muy operativa, funcionamiento real de los grupos de trabajo ...), que son los que hacen que una implantación de una gran mejora sobre el papel, fracase o no fracase. Sin su implicación, o más que su implicación, sin su compromiso estamos perdidos.
Pero de nuevo me he ido por las ramas, la pregunta no es hacia TI, es hacia negocio.
¿Conocen lo que hacen?, pues en este caso la respuesta va en la línea de coger el párrafo anterior y darle la vuelta. En ocasiones te vas a encontrar con responsables de procesos, que están tan metidos en la operativa que es muy difícil sacarlos de ahí. Conocen a la perfección cada detalle de su proceso, y lo miden y lo gestionan con eficacia, pero no salen de ahí.
Esta es una situación complicada, ya que les resultará muy complicado "repensar" el proceso para sacar más partido a lo que vas a implementar, querrán mejoras puntuales sobre determinadas partes del proceso pero no irán más allá.
Son situaciones seguras, porque es difícil meter la pata (salvo que TI lo salte y haga lo que quiera).
Por otro lado tenemos al responsable de proceso, muy alejado del mismo. Casi no sabe lo que se hace en él, pero si que tiene claro cual es la finalidad del mismo. Es un individuo con el que se pueden obtener grandes resultados, pero es un gran generador de riesgo. Si él no se mete en las tripas del proceso, con el nivel de detalle que hacía el anterior, tendremos que hacerlo nosotros. Claro está siempre que sepamos y podamos. El riesgo está que en esta aproximación de los dos lados, algo se quede en un agujero. Con este modelo, es preciso que salte la chispa entre negocio y TI, en forma de compromiso y colaboración. De otro modo, es más peligroso que jugar a la ruleta rusa
Comentaba la gran idea y el gran valor que daba al negocio de un restaurante de comida rápida, la implantación de un sistema de recogida de pedidos vía PDA.
En un comentario que yo le dejé, pues comentaba que el origen de la idea, a mi personalmente me daba un poco igual, y que lo realmente importante es favorecer que exista un caldo de cultivo que favorezca el que surjan iniciativas de este tipo.
De ahí, a mi pregunta con la que titulo el post, solo queda un poco de mala leche.
¿Sabe negocio de negocio?.
En ocasiones, nuestro gran pecado con ese rol de consultor de negocio, es creernos que lo sabemos todo, que tenemos una visión de alto nivel de los procesos, y que por ello que mejor que nuestro criterio para decidir como tienen que trabajar los usuarios.
En mi caso lo he vivido muchas veces, y es verdad que nosotros si conocemos los procesos, y en muchas ocasiones conocemos las conexiones de cada proceso con el resto de una manera más profunda que el cliente. Pero tenemos que contar con él, ya que el está a pie de obra, sabe como trabaja la gente, y tiene en cuenta esos "pequeños detalles" (usabilidad, necesidades de información muy operativa, funcionamiento real de los grupos de trabajo ...), que son los que hacen que una implantación de una gran mejora sobre el papel, fracase o no fracase. Sin su implicación, o más que su implicación, sin su compromiso estamos perdidos.
Pero de nuevo me he ido por las ramas, la pregunta no es hacia TI, es hacia negocio.
¿Conocen lo que hacen?, pues en este caso la respuesta va en la línea de coger el párrafo anterior y darle la vuelta. En ocasiones te vas a encontrar con responsables de procesos, que están tan metidos en la operativa que es muy difícil sacarlos de ahí. Conocen a la perfección cada detalle de su proceso, y lo miden y lo gestionan con eficacia, pero no salen de ahí.
Esta es una situación complicada, ya que les resultará muy complicado "repensar" el proceso para sacar más partido a lo que vas a implementar, querrán mejoras puntuales sobre determinadas partes del proceso pero no irán más allá.
Son situaciones seguras, porque es difícil meter la pata (salvo que TI lo salte y haga lo que quiera).
Por otro lado tenemos al responsable de proceso, muy alejado del mismo. Casi no sabe lo que se hace en él, pero si que tiene claro cual es la finalidad del mismo. Es un individuo con el que se pueden obtener grandes resultados, pero es un gran generador de riesgo. Si él no se mete en las tripas del proceso, con el nivel de detalle que hacía el anterior, tendremos que hacerlo nosotros. Claro está siempre que sepamos y podamos. El riesgo está que en esta aproximación de los dos lados, algo se quede en un agujero. Con este modelo, es preciso que salte la chispa entre negocio y TI, en forma de compromiso y colaboración. De otro modo, es más peligroso que jugar a la ruleta rusa
sábado, 2 de diciembre de 2006
Entrando en materia
Después de un par de post bastante abiertos, vamos a entrar más en materia.
Tengo por un lado negocio, y por otro a TI. Acualmente para la gestión de TI, ITIL se está convirtiendo en estandar de facto. Buscando ITIL en google, seguramente encontréis un montón de fuentes en las que se explicarán muy detalladamente cada uno de los procesos ITIL. (os paso esta fuente, es un blog que también habla de COBIT, ITIL, ISO y que es muy bueno)
ITIL está muy bien, porque pone orden y hace que no te olvides de nada. Tienes los servicios que TI está dando al negocio, y con estos procesos te aseguras de que gestionas incidencias, problemas (muy importante esta distinción entre problemas e incidencias), cambios, lanzamientos, y ya a nivel táctico te permite controlar la capacidad, el coste financiero del servicio, la disponibilidad, la contingencia y el impacto en los SLA's. Otro día entraremos más en detalle en estos procesos, sobre todo en su vertiente más práctica.
Pero de todo esto, lo que más me gusta de ITIL es el concepto de gestión de servicios, y de la modelización de estos con los componenetes que permiten prestarlos. (documentados en la CMDB).
¿Dónde creo yo que está el primer paso para conseguir que TI aporte mucho valor al negocio?.
Pues en el alineamiento. Y creo que este se consigue si los servicios que metamos en nuestro catálogo, deje de ser un catálogo TI y se convierta en un catálogo de servicios de apoyo al negocio.
Creo que la mejor manera de construir los servicios es pensando en la cadena de valor de negocio.
¿que hacemos y en que orden?
Diseñamos, compramos, fabricamos, almacenamos, vendemos, servimos y cobramos
Pues TI está en cada proceso de negocio, apoyando.
Soportamos el proceso de compras, que estará relacionado con almacén, y este con ventas, y con control de gestión. Y como lo hacemos, pues aquí comenzamos a meter el detalle de elementos TIC que utilizamos, así como sus relaciones.
Un ERP, el correo, la red ... y todo eso lleva una serie de elementos por detrás (Ci's de la CMDB).
¿Hasta dónde llegar?, pues hasta lo que podamos mantener y nos resulte útil. Si soy una PYME y tengo informática de puesto y comunicaciones en un proveedor y el soporte de una aplicación integral a medida en otro, no tiene mucho sentido bajar al nivel de detalle que tendría que llegar si yo tengo y mantengo mucha más infraestructura.
De todos modos, por hoy nos quedamos aquí. Para mi el servicio que debemos de gestionar como tal, es el servicio de Soporte al proceso de negocio. ¿como lo ves?, ¿que te parece?
Tengo por un lado negocio, y por otro a TI. Acualmente para la gestión de TI, ITIL se está convirtiendo en estandar de facto. Buscando ITIL en google, seguramente encontréis un montón de fuentes en las que se explicarán muy detalladamente cada uno de los procesos ITIL. (os paso esta fuente, es un blog que también habla de COBIT, ITIL, ISO y que es muy bueno)
ITIL está muy bien, porque pone orden y hace que no te olvides de nada. Tienes los servicios que TI está dando al negocio, y con estos procesos te aseguras de que gestionas incidencias, problemas (muy importante esta distinción entre problemas e incidencias), cambios, lanzamientos, y ya a nivel táctico te permite controlar la capacidad, el coste financiero del servicio, la disponibilidad, la contingencia y el impacto en los SLA's. Otro día entraremos más en detalle en estos procesos, sobre todo en su vertiente más práctica.
Pero de todo esto, lo que más me gusta de ITIL es el concepto de gestión de servicios, y de la modelización de estos con los componenetes que permiten prestarlos. (documentados en la CMDB).
¿Dónde creo yo que está el primer paso para conseguir que TI aporte mucho valor al negocio?.
Pues en el alineamiento. Y creo que este se consigue si los servicios que metamos en nuestro catálogo, deje de ser un catálogo TI y se convierta en un catálogo de servicios de apoyo al negocio.
Creo que la mejor manera de construir los servicios es pensando en la cadena de valor de negocio.
¿que hacemos y en que orden?
Diseñamos, compramos, fabricamos, almacenamos, vendemos, servimos y cobramos
Pues TI está en cada proceso de negocio, apoyando.
Soportamos el proceso de compras, que estará relacionado con almacén, y este con ventas, y con control de gestión. Y como lo hacemos, pues aquí comenzamos a meter el detalle de elementos TIC que utilizamos, así como sus relaciones.
Un ERP, el correo, la red ... y todo eso lleva una serie de elementos por detrás (Ci's de la CMDB).
¿Hasta dónde llegar?, pues hasta lo que podamos mantener y nos resulte útil. Si soy una PYME y tengo informática de puesto y comunicaciones en un proveedor y el soporte de una aplicación integral a medida en otro, no tiene mucho sentido bajar al nivel de detalle que tendría que llegar si yo tengo y mantengo mucha más infraestructura.
De todos modos, por hoy nos quedamos aquí. Para mi el servicio que debemos de gestionar como tal, es el servicio de Soporte al proceso de negocio. ¿como lo ves?, ¿que te parece?
el valor de las TIC
Desde los 90, con Internet convirtiéndose en algo univerlsa, las acciones de todo lo que sonara a tecnología desbocadas, y un montón de economistas hablando del círculo virtuoso en el que habían entrado las economías occidentales, se ha hablado mucho del impacto de las TIC sobre la economía.
Concretamente sobre la productividad, se hablaba por entonces de que el impacto de las TIC se traduciría en crecimientos de la productividad elevados y sostenibles en el tiempo, que permitirían crecer mucho y sin tensiones inflacionistas. El final de NAIRU, y el inicio de un mundo perfecto.
Como la realidad es tozuda, y la vida siempre se abre paso con grandes oscilaciones, el mito cayo, y todo lo que entonces era oro ahora no lo era.
Sin embargo, lo que si está claro y es indudable es que hoy por hoy, las Tecnologías de la Información constituyen un elemento básico en cualquier empresa. Con la globalización, el incrmento en los niveles competitivos, alcanzan a prácticamente todos los sectores. El uso de TIC, más aún, el buen uso de TIC es imprescindible para tener una posición competitiva.
Desde esta ventana, vamos a intentar ver como podemos usar estas TIC como motor para el negocio, pero sin caer en los viejos vicios. Un uso eficiente y eficaz de la tecnología, no implica para nada la disposición de las últimas herramientas y más novedosas (y generalmente caras de comprar, implantar y mantener), sino de una correcta gestión de los recursos, y un extraordinario sentido de alineamiento entre TI y el negocio.
Ese es el desafío, y esto es lo que vamos a comentar desde aquí. Espero que resulte una experiencia interesante.
Concretamente sobre la productividad, se hablaba por entonces de que el impacto de las TIC se traduciría en crecimientos de la productividad elevados y sostenibles en el tiempo, que permitirían crecer mucho y sin tensiones inflacionistas. El final de NAIRU, y el inicio de un mundo perfecto.
Como la realidad es tozuda, y la vida siempre se abre paso con grandes oscilaciones, el mito cayo, y todo lo que entonces era oro ahora no lo era.
Sin embargo, lo que si está claro y es indudable es que hoy por hoy, las Tecnologías de la Información constituyen un elemento básico en cualquier empresa. Con la globalización, el incrmento en los niveles competitivos, alcanzan a prácticamente todos los sectores. El uso de TIC, más aún, el buen uso de TIC es imprescindible para tener una posición competitiva.
Desde esta ventana, vamos a intentar ver como podemos usar estas TIC como motor para el negocio, pero sin caer en los viejos vicios. Un uso eficiente y eficaz de la tecnología, no implica para nada la disposición de las últimas herramientas y más novedosas (y generalmente caras de comprar, implantar y mantener), sino de una correcta gestión de los recursos, y un extraordinario sentido de alineamiento entre TI y el negocio.
Ese es el desafío, y esto es lo que vamos a comentar desde aquí. Espero que resulte una experiencia interesante.
viernes, 1 de diciembre de 2006
arranque
Pese a mi formación de economista, a los 6 meses de comenzar a trabajar ya estaba en el seno de un departamento de TI, y ahí me he quedado durante los últimos 6 años.
Estos años me han dado una visión de lo que puede ser una empresa, y de lo que puede y deben de ser las Tecnologías de la Información en una compañia. Seguramente esta visión esté sesgada por ver las cosas desde dentro, desde la cocina, pero creo que por mi forma de ser, me gusta sacar la cabeza por la ventana para intentar verme desde el otro lado.
Espero hacer de este blog, un lugar en el que comentar mis reflexiones acerca de como TI debe de servir de motor al negocio, para que este pueda dar cada día un pasito más en la interminable carrera de la aportación de valor.
Me apoyaré en blogs nacionales y foráneos en los que hablan muy bien, y con mucho conocimento de cosas como ITIL, COBIT, ISO y demás, pero intentado siempre dar una aproximación más práctica y basada en mi propia experiencia que una visión académica, que con seguridad aportaría muchísimo menos que cualquier otra fuente.
Además de difundir, espero que esta ventana al mundo me sirva para ponerme en contacto con gente que comparta mis reflexiones y mis inquietudes. El no trabajar en una ciudad grande, dónde la concentración de gente trabajando en estos temas es mucho mayor es un handicap de cara a intentar contrastar opiniones y experiencias, así que aprovecho esto para abrir un hueco desde la periferia, para contar que es lo que hacemos e intentamos hacer desde aquí.
Estos años me han dado una visión de lo que puede ser una empresa, y de lo que puede y deben de ser las Tecnologías de la Información en una compañia. Seguramente esta visión esté sesgada por ver las cosas desde dentro, desde la cocina, pero creo que por mi forma de ser, me gusta sacar la cabeza por la ventana para intentar verme desde el otro lado.
Espero hacer de este blog, un lugar en el que comentar mis reflexiones acerca de como TI debe de servir de motor al negocio, para que este pueda dar cada día un pasito más en la interminable carrera de la aportación de valor.
Me apoyaré en blogs nacionales y foráneos en los que hablan muy bien, y con mucho conocimento de cosas como ITIL, COBIT, ISO y demás, pero intentado siempre dar una aproximación más práctica y basada en mi propia experiencia que una visión académica, que con seguridad aportaría muchísimo menos que cualquier otra fuente.
Además de difundir, espero que esta ventana al mundo me sirva para ponerme en contacto con gente que comparta mis reflexiones y mis inquietudes. El no trabajar en una ciudad grande, dónde la concentración de gente trabajando en estos temas es mucho mayor es un handicap de cara a intentar contrastar opiniones y experiencias, así que aprovecho esto para abrir un hueco desde la periferia, para contar que es lo que hacemos e intentamos hacer desde aquí.
Suscribirse a:
Entradas (Atom)
