Management

Share
Ya estamos aqui otra vez, continuando el artículo de la semana anterior...En el anterior artículo empezamos orientando una organización de TI basada en servicios. Además empezamos a estructurarlos de forma ordenada y tambien, como no siendo un obsesionado como soy de los indicadores, detallamos una forma sencilla de realizar un seguimiento de cada uno de los servicios de forma individual, agregando sus resultados para poder finalmente analizar como funcionaba nuestro departamento de forma global, siempre pero, desde el punto de vista de servicios.

Con esta estructura podiamos por ejemplo definir 30 indicadores de servicio y que estos me sirvieran para medir el 'ambiente', pudiendo no solo saber cosas concretas, como por ejemplo: como estan los backups de mi ERP, pero a la vez tambien pudiendo saber: como estan los backups de servicios de negocio.

Uno de los principales retos a los que se enfrenta siempre un responsable de una organización es: puedo gestionar lo que conozco, pero como puedo estar seguro que conozco todo lo necesario para poder hacer una gestion correcta de mi area de responsabilidad? O ejemplificando esta pregunta: Estoy pilotando un avión y para hacerlo tengo un estupendo indicador que se llama 'velocidad'. Es suficiente para pilotar o necesito alguno mas, y si es así, si añado un segundo, necesitaré tambien un tercero? o con dos ya tengo bastante? 

En el caso de TI, tenemos por fortuna un par de estándares sobre los que basar mi organización, y poder ver además como de lejos estoy de ellos en el caso de TI, y que además son ámpliamente conocidos: ISO20.000 y ITIL. En mi caso, y por lo que sé por mi experiencia de cada uno, diria que es como compar los 10 mandamientos y la legislación española. En los dos te dice eso de 'no mataras', pero en el segundo te lo explica mediante miles de librons de a 1.000 páginas a letra 6pt...

Si nos centramos pues en ISO20.000 (para no deprimirnos quizá o perdernos en la selva de ITIL), veremos que definine una organización de TI mediante una estructura de procesos. Veamoslos:

 

Codigo Proceso
PRC03 03. Requisitos de un sistema de gestión
PRC04 04. Planificación e implantación de la gestión
PRC05 05. Planificación e implementación de servicios
PRC06 06. Provisión del servicio
PRC061 06.1. Gestión de niveles de servicio
PRC062 06.2. Generación de informes de los servicios
PRC063 06.3. Gestión de la continuidad y disponibilidad
PRC064 06.4. Presupuestar y contabilizar servicios
PRC065 06.5. Gestión de la capacidad
PRC066 06.6. Gestión de la seguridad de la información
Codigo Proceso
PRC07 07. Relaciones
PRC072 07.2. Gestión de relaciones con el negocio
PRC073 07.3. Gestión de proveedores
PRC08 08. Resolución
PRC082 08.2. Gestión d'incidentes
PRC083 08.3. Gestión de problemas
PRC09 09. Control
PRC091 09.1. Gestión de la configuración
PRC092 09.2. Gestión de cambios
PRC10 10. Entrega
PRC101 10.1. Gestión de entregas

Como podemos ver disponemos de un listado completo de todas las actividades que son necesarias para el desarrollo y mantenimiento de un departamento de TI... pero eso como lo puedo plasmar en mi organización...Esto puede pareceros interesante, pero a ver... donde estan los programadores, donde los helpdesk y donde los adminsitradores aqui!!!!

Por otro lado, para aquellos más acostumbrados a ITIL, echareis en falta quizá una ordenación de los procesos más tipo ciclo de vida, y de hecho tenéis razón... para aquellos no familiarizados con Demming o con el ciclo de vida de ITIL, os enseño el siguiente diagrama:

 ITIL Ciclo de vida

Ya que estamos intentando hacer algo que nos valga en el futuro... podríamos organizar los procesos anteriormente descritos usando este ciclo de vida? Que creeis? Pues claro! Vamos a verlo:

Como podeis ver, en este diseño hemos colocado los procesos siguiendo el ciclo de vida de ITIL, usando procesos ISO2K, pero que ha pasado con la calidad y el control?? Bueno, en realidad podríamos definir la caja y definir tambien algunos procesos en el, como por ejemplo el de generación de informes de servicio, pero en relidad la función de calidad representa más una característica que han de tener todos los procesos, con el objeto de controlar que no solo se sigue un modelo de mejora en los servicios, sino tambien en los propios procesos, y que puede acabar siendo una figura de 'auditor interno'.

Ahora me gustaria hacer una pequeña reflexión-resumen de lo que hemos hablado hoy, junto lo que hablamos en el anterior artículo de esta serie. En relidad hemos mostrado un modelo de gestión basado en 2 principios: orientación a servicio y orientación a procesos. Esto en realidad son las 2 caras de una misma moneda, y precisamente aquí radica su fortaleza: existen responsables de servicio que exigiran al responsable de diseño, o de desarrollo, o de operación el cumplimiento de sus indicadores de gestión, y a su vez este mismo responsable de servicio será además un dueño de proceso que recibirá el control y la exigencia del responsable de otros servicios.

Con este modelo además estamos repartiendo las responsabilidad, ya que no vale que los 3 jefecillos de turno sean los responsables de todo: hay que repartir las responsabilidades de forma general por toda la organización para que todo el mundo haga girar este engranaje con 2 ejes, ya que sino volveríamos a nuestro modelo jerárquico de toda la vida... Como lo veis? Estais preparados para afrontar un cambio en vuestra organización como este?

Add comment


Security code
Refresh