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.

4 comentarios:

K. dijo...

La has clavao, colega. Las ventajas e inconvenientes de cada situación ya me las he encontrado así que voy a mirarme lo que comentas de la solución intermedia (modelos MOF y eso).

Una pregunta más (igual da para otro artículo).

Si mantenemos departamentos, ¿tu experiencia es que es mejor agrupar por área de actividad (proyectos, explotación...)o conocimientos (redes, software, SGBD...)? para adaptarse a ITIL u otros mdoelos...

Anónimo dijo...

Lo primero, indicar que hoy he descubierto tu blog, y la verdad es que ha sido una sorpresa muy agradable, lo segundo:
Me ha parecido muy acertado tu artículo. Yo personalmente no soy partidario de una reorganización drástica del departamento, yo me encargo de los temas de organización y estoy embarcado en el despliegue de los procesos ITIL, respecto a Problemas e Incidencias, mi opción ha sido la creación de 2 grupos multidisciplinares, compuestos por técnicos de desarrollo, Service Desk, explotación y lanzamiento para que analicen los indicadores y propongan mejoras operativas. La verdad es que la experiencia es muy positiva.

. dijo...

Buen post Antonio. Te dejo mi dirección de blog ISO 27001 por si fuese de tu interés. Estoy metido con ITIL ahora para posible implantación en uno de nuestros despachos profesionales y lo que he leído en tu post parece coherente.

Lo dicho: Felicidades.

YVeintim dijo...

Estimados, necesito una pronta respuesta bien clara:
Debo entonces indicar que la "mejor" alternativa es organizar al area de IT como tradicionalmente ha venido aconteciendo: MANTENIMIENTO, DESARROLLO, SOPORTE TECNICO, PROYECTOS, SEGURIDAD.

Y luego armar equipos basados en los procesos que propone ITIL, aclarando y definiendo roles y responsabilidades basados en los procesos de ITIL?

Pueden alguien enviarme un grafico de como seria en la vida real?

Gracias,