TI el motor de la generación de valor

la cuenta por favor.

2007-10-08T00:48:00.000-07:00

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

2007-08-08T11:54:00.000-07:00

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

2007-07-03T03:20:00.000-07:00

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

2007-07-03T02:53:00.000-07:00

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?

2007-06-17T23:35:00.000-07:00

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

2007-05-26T04:02:00.000-07:00

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

2007-04-28T01:05:00.000-07:00

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

2007-04-09T23:41:00.000-07:00

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

2007-03-29T23:31:00.000-07:00

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

2007-03-28T11:52:00.000-07:00

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

2007-03-27T23:21:00.000-07:00

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

2007-03-19T14:54:00.000-07:00

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

2007-03-17T01:27:00.000-07:00

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

2007-03-16T00:19:00.000-07:00

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

2007-03-14T16:11:00.000-07:00

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

2007-02-02T07:47:00.000-08:00

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?

2007-02-01T10:39:00.000-08:00

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

2007-01-30T09:17:00.001-08:00

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

2007-01-30T09:08:00.001-08:00

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

2007-01-06T04:44:00.000-08:00

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

2006-12-31T02:15:00.001-08:00

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

2006-12-24T02:15:00.000-08:00

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

2006-12-18T13:32:00.000-08:00

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

2006-12-15T12:22:00.000-08:00

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

2006-12-13T06:35:00.000-08:00

¿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.

Lo que le falta a ITIL

2006-12-09T01:13:00.000-08:00

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.

Herramientitis

2006-12-06T00:31:00.000-08:00

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"

La correponsabilidad en cumplimiento de indicadores

2006-12-04T23:24:00.000-08:00

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".

¿Sabe negocio de negocio?

2006-12-03T01:48:00.000-08:00

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

Entrando en materia

2006-12-02T01:27:00.000-08:00

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?

el valor de las TIC

2006-12-02T00:52:00.000-08:00

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.

arranque

2006-12-01T12:37:00.000-08:00

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í.