Búsqueda


24 de mayo de 2006

Para Mr. K: Implantacion de ITIL y los cambios organizativos

Esta semana un amigo de los viejos tiempos de la Universidad me ha pasado un mail.En él, me preguntaba si las organizaciones que implementan ITIL acompañan la implantación de los procesos con una reorganización de sus departamentos hacia la formación de equipos de trabajo especialmente estructurados según los procesos implantados, o si por el contrario se suele mantener la estructura departamental y a existente, asignando las funciones, roles, responsabilidades y actividades necesarias para la correcta ejecución de los procesos. Esta es una de aquellas preguntas que fácilmente se podría clasificar como FAQ, ya que es una duda que aparece en cada cliente con que trabajo, y la respuesta no es siempre fácil de dar ni fácil de asimilar.

¡Me encanta que me propongan temas sobre los que escribir, gracias! Aquí tienes tu respuesta, Mr. K:

La solución rápida al dilema es: “depende”. Depende del calibre de la organización, de los procesos que se vayan a implementar, de la sensibilidad al cambio que presente el personal de TI, del beneficio que se vaya a obtener de semejante reorganización, y principalmente del nivel de esponsorización que tengamos para acometer tan titánica tarea. Pero claro, si te contestara eso y nada más, me dirías que se nota que soy consultor. ¿Te sabes el chiste del consultor y el pastor?

Así que vamos a darle un par de vueltas al asunto, a ver si llegamos a alguna conclusión un poco más inteligente. Si tomamos un proceso como por ejemplo la Gestión de Problemas, ¿qué necesidad tenemos de reorganizar un departamento IT “clásico” para su implantación? Lo importante de un proceso es su resultado, los entregables que se generan. En el caso de la Gestión de Problemas, los entregables más importantes son los elementos que conforman la Base de Datos de Errores Conocidos (es decir, listas de problemas con sus sintomatologías debidamente descritas e identificadas y con las posibles soluciones temporales o workarrounds debidamente documentadas) y las propuestas de cambio (RFC) planteadas para resolver de una forma definitiva las causas raíces de los problemas que afectan a los servicios TIC.

Analicemos ahora una empresa más o menos “estándar” como es Tornillos Enroscados, S.A. y su Departamento de TI. Es muy posible que antes de la implantación del proceso de Gestión de Problemas ya existan algunas actividades orientadas a obtener estos resultados, sólo que no estarán formalizados. Al implantar el proceso lo que estamos haciendo precisamente es formalizar las actividades, definir roles y responsabilidades y añadirle a este coctel unas cuantas métricas que nos permitan medir la calidad del resultado y el rendimiento de todo el proceso.

Si nos fijamos en la estructura departamental de Tornillos Enroscados, S.A. veremos que las áreas dentro del departamento de TI están organizadas por tipo de actividad: desarrollo, sistemas, operaciones… pero el flujo de las actividades del proceso es horizontal, atravesando e involucrando a las personas de las diferentes áreas. Cuando aparece un problema y se decide comenzar las tareas de investigación de sus causas originales es muy probable que tengan que intervenir miembros de los diferentes equipos. Pongamos por caso que los sistemas de monitorización detectan que los tiempos de respuesta de nuestro sistema de e-business han subido de una forma escandalosa. Hasta descubrir que está fallando la negociación full-duplex de la toma 8 del switch que conecta el balanceador de carga, habrán intervenido los chicos de sistemas (¡mira a ver qué le pasa al servidor, que esto va muy lento!), los chicos de comunicaciones (“el servidor esta bien, seguro que esto es problema de la red”), los de desarrollo (“yo le hago ping y todo va bien. Seguro que es la aplicación que se ha quedado colgada”), los del middleware (“la aplicación siempre ha funcionado bien, seguro que hay algo en la máquina que no va”) y los de monitorización (“nos lo hemos mirado todo y está todo bien. ¿Seguro que funciona bien ese monitor?”).

Es decir, en cada una de las áreas de nuestro Departamento de TI tendrían que existir las actividades que cubran las diferentes facetas del proceso de Gestión de Problemas; esto nos va a desembocar en dos situaciones que no son en absoluto positivas para la organización y que tendrán que ser abordadas en el momento en que se ponga en marcha el proceso:

  • la diferente percepción en las prioridades: el equipo de desarrollo, por poner un ejemplo, no percibirá como algo prioritario la necesidad de investigar un problema esporádico de tiempos de respuesta ya que su foco está puesto en el desarrollo, ya sea de nuevas funcionalidades o bien de nuevos proyectos. Es muy fácil que la investigación de un problema se convierta en una “patata caliente” que nadie quiere tener en sus manos demasiado tiempo.
  • la falta de autoridad: el responsable del proceso de Gestión de Problemas querrá que todas las áreas participen de activamente en la investigación de las causas rices de los problemas, pero si contamos con una organización vertical, las órdenes transversales no circulan de una forma eficiente y si el Gestor de Problemas pertenece, por ejemplo, al Area de Soporte, se encontrará con que no tiene autoridad sobre el personal del Area de Desarrollo como para exigirles la dedicación de tiempo y recursos en la investigación.

Ahora bien, si se reorganiza el Departamento y se crea un área específica para la Gestión de Problemas con componentes de cada una de las áreas anteriores nos encontraremos con que el Gestor de Problemas tendrá a un magnífico equipo a su cargo, pero habrán aparecido al menos dos problemáticas nuevas:

  • El estancamiento profesional de los integrantes del equipo: dado que toda su actividad se centra en la investigación y propuesta de soluciones (ya sean temporales o definitivas), perderán el contacto con toda la parte de proyectos de generación de nuevos servicios, sistemas y plataformas por lo que en un plazo de no más de 5 años tendremos un equipo obsoleto y desmotivado.
  • El incremento considerable de los costes: salvo que podamos ocupar el 100% del tiempo productivo del equipo de resolución de problemas, habremos desviado capacidad productiva hacia un proceso que no la utilizará eficientemente. Si necesitamos un equipo multidisciplinar para la resolución de problemas y ponemos a un especialista en Bases de Datos en este equipo, este individuo sólo ocupará su tiempo en actividades de Gestion de Problemas cuando sea necesaria su intervención, y el resto del tiempo ¿qué haremos con él?

Así pues, empezamos a ver que las soluciones puras no nos sirven del todo y tendremos que plantear una solución mixta: mantenemos a las personas agrupadas por área de actividad o conocimientos tal y como dictan los cánones tradicionales de estructuración vertical, planteamos equipos interdepartamentales que puedan trabajar conjuntamente en la resolución de probleas y pactamos con la dirección de cada área unos tiempos mínimos y máximos de dedicación a las actividades del proceso en cuestión. Lo que irá ocurriendo es que el tiempo de las personas se verá ocupado por actividades de diferentes procesos, la priorización del trabajo la irá marcando el responsable del área funcional en cooperación con los responsables de cada proceso y los equipos de proceso serán mixtos y ricos en cuanto a áreas de conocimiento. (una aproximación a los equipos multidisciplinares es la que da Microsoft en su modelo MOF, quizás te pueda interesar echarle un ojo).

Esta última solución es mucho menos traumática que una reorganización completa del Departamento (que ya bastante lío tendrá con la definición y puesta en marcha de los procesos) y permite aprovechar el tiempo de las personas (en definitiva, la capacidad productiva del Departamento de TI) entre las diferentes actividades de los procesos.

Por último, solo queda comentar que lo que sí que es muy habitual es asignar los diferentes Responsables de Proceso entre las áreas del departamento buscando la máxima aproximación conceptual. De esta forma, es muy normal que el proceso de Gestión de Incidencias caiga en el Area de Operaciones, o que el proceso de Gestión de Capacidad caiga en Soporte Tecnico o en Desarrollo.

¿Es una respuesta definitiva? Seguro que no… es una respuesta generalista que tiene que servir para darte argumentos para pensar por ti mismo en cómo afectará esto a tu propia organización, porque hay demasiados grados de libertad como para que una única respuesta sirva para todo el mundo.

Espero que te sirva de ayuda.

18 de mayo de 2006

Novedades en el blog

Hoy he hecho un par de cambios más o menos importantes en el blog, y tenía ganas de explicarlos porque así tú, que eres el “apreciado navegante” al que nombro en la barra de navegación de la derecha, te enterarás y podrás sacarle partido.

La primera modificación ha sido crear una cuenta en FeedBlitz, un sistema que lee los feeds Atom o RSS para sindicación de contenidos, los resume y agrega y te los pasa por mail cada día. De esta forma, puedes suscribirte a un servicio de notificaciones diarias de los nuevos artículos que se publiquen en Gobierno TIC que te enviará cada día un mail indicando las novedades que se vayan produciendo en el blog.

Claro, el primer temor es el de saber si esta gente no te va a machacar a mails de spam si metes ahí tu dirección de correo, así que lo primero que he hecho ha sido suscribir una cuenta de gMail que he creado a tal efecto para asegurarme. Si en pocos días comienzan a aparecer spams en esa cuenta, te aseguro que eliminaré el link y cualquier referencia a FeedBlitz. Ahora bien, si no es así, usalo tranquilo que no pasa nada.

El segundo temor que se te puede plantear es qué pienso hacer yo con las direcciones de correo que se vayan registrando en el servicio. La respuesta es fácil: nada. Prometo formalmente no hacer nada con las direcciones de correo, excepto si tengo que hacer alguna notificación especialmente importante a los lectores/suscriptores de este blog (un cambio de plataforma, un cambio de dominio, un cierre temporal o una invitación a tomar cervezas).

La segunda modificación es puramente un capricho que me he dado: siempre he tenido curiosidad por saber cómo va esto de la publicidad pagada por Google, los servicios Google Ad-Sense. Así que he creado una cuenta de adSense y he puesto un poco de publicidad en el blog (en teoria debe ser relacionada con los contenidos publicados), aunque la he puesto en lugares en los que no creo que altere demasiado el aspecto y el espíritu inicial del blog.

Cuando haya visto cómo va el asunto, y quizás cobrado mi primer cheque, lo eliminaré del blog, a no ser que vea que realmente me puedo retirar con esto!! (no lo creo, la verdad, pero todo se andará).

En fin, esto es un poco lo que quería compartir contigo, “apreciado navegante”.

¿Tienes una página y usas AdSense? ¡Cuéntame cómo te ha ido!

 

11 de mayo de 2006

Los 6 mitos de ITIL

He realizado una lectura en diagonal de Debunking the Six Most Common ITIL Myths y he visto una lista de los 6 mitos más comunes de ITIL y comentarios al respecto. Me ha parecido un ejercicio interesante quedarme únicamente con la lista de los mitos y comentarlos yo mismo según mi criterio… después leeré el artículo de ITSM Watch y sacaré mis propias conclusiones, simplemente un ejercicio de músculo intelectual.

MITO 1: ITIL es para los “techies”

Techies? Qué es eso? ;-)

No, vamos a ver.. los techies suelen ser los primeros sorprendidos cuando se inicia un proyecto de definición y/o implantación de procesos. No están (estamos, que también me considero un poco techie!) acostumbrados a la burocracia y el orden que plantea la utilización de procedimientos estandarizados y es una labor entretenida el explicar y convencer de la necesidad. Suele tener más éxito entre la gente de los departamentos de Organización, así que es útil comenzar por aquellos que más fácilmente asimilarán y aceptarán los conceptos para que te hagan de sponsors, impulsores o “apoyadores” en las tareas de definición e implantación. (Les recomiendo leer un artículo buenísimo del Service-Talk —la publicación del ITSMF — sobre la aplicación de la Teoría de la Red de Actores en los proyectos de implantación de ITIL)

MITO 2: ITIL sólo habla de procesos y personas

Ya están aquí las famosas 3 Patas o Pilares de ITIL: People, Process and Technology, que luego algún avispado comercial convirtió de forma mnemónica en las más famosas tres pes de ITIL: Personas, Procesos y Productos. Es decir, son necesarias las tres patas para que todo funcione, pero en los libros de ITIL no habla excesivamente de la pata de la tecnología.

Ahora bien.. sin tecnología a dónde quieres llegar? ¿O esperas acaso hacer una estimación del impacto de un cambio planificado sobre tus servicios en horario crítico usando una regla, un folio en blanco y un taco de post-its para comunicarlo a tus usuarios? Evidentemente sin un conjunto de herramientas sobre las que soportar todos y cada uno de los procesos que se vayan implantando no llegaremos a ningún lado!

Para pensar en este aspecto, quiero hacer hincapié en que no sólo de procesos vive el departamento de IT. Los procesos tienen Entradas, Salidas, Recursos y CONTROL! y este control es muy difícil llevarlo sin herramientas que nos permitan auditar, medir, correlar, documentar, notificar, etc. etc. etc.


















MITO 3: ITIL es la única respuesta

Este es uno de los errores más frecuentes que me encuentro en el día a día, y uno de los motivos por los que me decidí a iniciar este blog. ITIL no es lo único, es más: se queda corta en muchísimos aspectos. Es necesario complementarlo con otros estándares como son Six-Sigma, CMMI, Cobit, e-Scm, ISO17799, etc.

Para más información, sigue conectado a este blog.

MITO 4: La mayor inversión se realiza en formación

Craso error, Pompeyo!. Efectivamente, las primeras fases son fuertemente dedicadas a la formación, sobre todo en entornos en los que no se ha oído hablar nunca de orientación a procesos. Pero posteriormente hay que diseñar los procesos, hay que madurarlos, comprar plataforma y herramientas, implantarlos… y con eso sólo hemos empezado porque en realidad después viene el ciclo continuo de mejora y madurez de los procesos.

No es en formación donde va a estar tu mayor inversión, pero es importantísimo que inviertas en formación si no quieres quedar atado para siempre con la consultora que te ayude a implantar ITIL o si no quieres que el proyecto fracase estrepitosamente por culpa del rechazo que provoca aquello que desconocemos.

MITO 5: Hazlo pasito a pasito.

Hombre… a priori, estoy de acuerdo con hacerlo de a poco. Un cambio organizativo como este no es recomendarlo morderlo todo de golpe, porque no lo podremos masticar. No olvidemos que como ITIL no es una ciencia exacta, a la gente le cuesta asimilar y comprender todo lo que estamos intentando hacer. Pero claro, hay cosas que es necesario iniciar en paralelo: una gestión de Incidencias sin gestión de Configuraciones se queda coja, y una simple Gestión de Configuraciones sin nada más es difícilmente vendible a la organización.

Además, en ITIL soy partidario de la frase típica de que 1+1=3, o que “en una visión holística, el todo es más que la suma de las partes”, así que a medida que vayamos añadiendo procesos podremos impulsar o complementar los ya previamente implantados.

MITO 6: Selecciona sólo herramientas “ITIL Compliant”

¿ITIL Compliant? ¿Y qué es eso?

ITIL no define ningún mecanismo que permita evaluar herramientas y poner un sello de “ITIL Ready” o “ITIL Inside” en la caja de un producto, así que todo aquel que lo diga miente como un bellaco. Ahora bien, es cierto que hay herramientas mas cercanas a ITIL o más alejadas, que nos permiten implementar más o menos procesos pero eso no da un sello de “ITIL Compliant”.

La gente de Pink Elephant tiene un servicio denominado Pink Verify que me gusta especialmente porque hacen públicos los checklists que pasan para decidir si un producto permite o no la implementación de un determinado procesos ITIL, y eso hace que sea mas objetivo o al menos que sepamos exactamente cual es el significado del sello PinkVerify.

Ahora bien, ITIL es un traje a medida que debe ser desarrollado en cada casa de una forma diferente, así que las herramientas serán diferentes en cada caso. Mi principal recomendación a la hora de escoger herramienta es que sea flexible, que sea muy flexible para poderse adaptar a la realidad actual del departamento de IT y especialmente para adaptarse a los cambios que quedan por venir, que serán muchos y rápidos.

Bueno, pues hasta aquí mis comentarios sobre los 6 mitos de ITIL… ahora me voy a leer en serio el artículo del ITSM Watch y a pensar un rato.

¿¿ Y tú, qué opinas de todo esto??

10 de mayo de 2006

Quién le debe a quién

Hoy pensaba escribir uno o incluso dos artículos para el blog. Tengo la lista de "ideas pendientes de desarrollar" que va creciendo rápidamente, pero siempre me falta tiempo para dedicar a desarrollarlas porque es impensable "robar" este tiempo de las horas laborables y es inaceptable robárselas a la familia, así que aprovecho cuando tengo tiempo mio, solo mio como mi tessssoro.

Cuando me senté en el PC a escribir, se conectó al messenger mi hermano y entre otras cosas me pasó un documento que, al leerlo, eclipsó el interés por los artículos por desarrollar y pensé que, a pesar de ser este un blog dedicado al Gobierno de las TIC, algo profundamente ligado al mundo laboral en el que me desenvuelvo y que tiene un nivel de especialización bastante alto, debía publicar y ayudar a promover.

No se si lo que se cuenta en este texto es verdad (me cuesta un poco de creerlo a pies juntillas) pero el hilo argumental, el fondo, la idea que trasciende de todo esto es cierta como la vida misma. Quiero expresar desde aquí mi apoyo a este texto y mi repulsa al modelo macro-económico en el que me ha tocado vivir.

#----------------------< AQUÍ COMIENZA EL TEXTO >------------------------

Exposición del Cacique Guaicaipuro Cuatemoc ante la reunión de Jefes de Estado de la Comunidad Europea, 1992

Con lenguaje sencillo, que era trasmitido en traducción simultanea a más de un centenar de Jefes de Estado y dignatarios de la Comunidad Europa, el Cacique Guaicaipuro Cuatemoc logró inquietar a su audiencia cuando dijo:

"Aquí pues yo, Guaicaipuro Cuatemoc he venido a encontrar a los que celebran el encuentro. Aquí pues yo, descendiente de los que poblaron la América hace cuarenta mil años, he venido a encontrar a los que la encontraron hace solo quinientos años. Aquí pues, nos encontramos todos. Sabemos lo que somos, y es bastante. Nunca tendremos otra cosa.

El hermano aduanero europeo me pide papel escrito con visa para poder descubrir a los que me descubrieron. El hermano usurero europeo me pide pago de una deuda contraída por Judas, a quien nunca autorice a venderme. El hermano leguleyo europeo me explica que toda deuda se paga con intereses, aunque sea vendiendo seres humanos y países enteros sin pedirles consentimiento. Yo los voy descubriendo.


También yo puedo reclamar pagos y también puedo reclamar intereses. Consta en el Archivo de Indias, papel sobre papel, recibo sobre recibo y firma sobre firma, que solamente entre el año 1503 y 1660 llegaron a San Lucas de Barrameda 185 mil kilos de oro y 16 millones de kilos de plata provenientes de América. ¿Saqueo? ¡No lo creyera yo! Porque sería pensar que los hermanos cristianos faltaron a su Séptimo Mandamiento. ¿Expoliación? ¡Guárdeme Tanatzin de figurarme que los europeos, como Caín, matan y niegan la sangre de su hermano! ¿Genocidio? ¡Eso sería dar crédito a los calumniadores, como Bartolomé de las Casas, que califican al encuentro como de destrucción de las Indias, o a ultrajosos como Arturo Uslar Pietri, que afirma que el arranque del capitalismo y la actual civilización europea se deben a la inundación de metales preciosos!

¡No! Esos 185 mil kilos de oro y 16 millones de kilos de plata deben ser considerados como el primero de muchos otros préstamos amigables de América, destinados al desarrollo de Europa. Lo contrario seria presumir la existencia de crímenes de guerra, lo que daría derecho no solo a exigir devolución inmediata, sino la indemnización por daños y perjuicios. Yo, Guaicaipuro Cuatemoc, prefiero pensar en la menos ofensiva de estas hipótesis. Tan fabulosa exportación de capitales no fue más que el inicio de un plan "Marshalltezuma", para garantizar la reconstrucción de la bárbara Europa, arruinada por sus deplorables guerras contra los cultos musulmanes, creadores del álgebra, el baño cotidiano y otros logros superiores de la civilización.

Por eso, al celebrar el Quinto Centenario del Empréstito, podremos preguntamos: ¿han hecho los hermanos europeos un uso racional, responsable o por lo menos productivo de los fondos tan generosamente adelantados por el Fondo Indo-americano Internacional? Deploramos decir que no. En lo estratégico, lo dilapidaron en las batallas de Lepanto, en armadas invencibles, en terceros reichs y otras formas de exterminio mutuo, sin otro destino que terminar ocupados por las tropas gringas de la OTAN, como en Panamá, pero sin canal. En lo financiero, han sido incapaces, después de una moratoria de 500 años, tanto de cancelar el capital y sus intereses, cuanto de independizarse de las rentas líquidas, las materias primas y la energía barata que les exporta y provee todo el Tercer Mundo. Este deplorable cuadro corrobora la afirmación de Milton Friedman según la cual una economía subsidiada jamás puede funcionar y nos obliga a reclamarles, para su propio bien, el pago del capital y los intereses, que tan generosamente hemos demorado todos estos siglos en cobrar.

Al decir esto, aclaramos que no nos rebajaremos a cobrarle a nuestros hermanos europeos las viles y sanguinarias tasas del 20 y hasta el 30 por ciento de interés, que en ocasiones los hermanos europeos les cobran a los pueblos del Tercer Mundo. Nos limitaremos a exigir la devolución de los metales preciosos adelantados, más el módico interés fijo del 10 por ciento, acumulado solo durante los últimos 300 años, con 200 años de gracia. Sobre esta base, y aplicando la formula europea del interés compuesto, informamos a los descubridores que nos deben, como primer pago de su deuda, una masa de 484.147 Billones de kilos de oro y 42 Trillones de kilos de plata. Es decir, masas que hoy equivalen a 212.345 millones de veces la producción mundial de oro por año, y 3.164 Billones de veces la de plata. El total también corresponde al 70% de toda la corteza terrestre, o al 0,7% de todo el planeta. Muy pesadas son esas moles de oro y plata. ¿Cuánto pesarían, calculadas en sangre?

Aducir que Europa, en medio milenio, no ha podido generar riquezas suficientes para cancelar ese módico interés, seria tanto como admitir su absoluto fracaso financiero y/o la demencial irracionalidad de los supuestos del capitalismo. Tales cuestiones metafísicas, desde luego, no nos inquietan a los indo-americanos. Pero sí exigimos la firma de una Carta de Intención que discipline a los pueblos deudores del Viejo Continente; y que los obligue a cumplir su compromiso mediante una pronta privatización o reconversión de Europa, que les permita entregárnosla entera, como primer pago de la deuda histórica... "

Cuando el Cacique Guaicaipuro Cuatemoc dio su conferencia ante la reunión de Jefes de Estado de la Comunidad Europea, no sabía que estaba exponiendo una tesis de Derecho Internacional para determinar LA VERDADERA DEUDA EXTERNA. Ahora solo resta que algún gobierno latinoamericano tenga el valor suficiente para hacer el reclamo ante los Tribunales Internacionales.