3.1 Funciones, roles y Procesos en la Gestión de servicios de TI: El Modelo Raci.
Para que la fase de diseño resulte exitosa es imprescindible organizar
adecuadamente todos los procesos y actividades implicados.
Un modelo útil para la asignación de responsabilidades en la ejecución de tareas
o actividades asignadas a un proyecto es el llamado modelo RACI (también
llamado matriz de asignación de responsabilidades) que es el acrónimo de:
--Responsible (Encargado): es la persona
encargada de hacer la tarea en cuestión.
--Responsible (Encargado): es la persona
encargada de hacer la tarea en cuestión.
--Consulted (Consultado): las personas que deben
ser consultadas para la realización de la tarea.
--Informed (Informado): Las personas que deben ser
informadas sobre el progreso de ejecución de la tarea.
Una matriz RACI típicamente tiene un eje vertical donde se
describen las tareas o entregables en orden cronológico y en el
eje horizontal los perfiles o personas implicadas en los mismos.
Existen variaciones menores de este modelo que incluyen
nuevos roles. Por ejemplo en RASCI se incluye:
--Support (Soporte): que se corresponde con las personas encargadas
de facilitar el soporte necesario para la realización de la tarea.
Y el RACI-VS que introduce los roles de:
--Verify (Vericador): encargado de supervisar la tarea y
su adecuación a los estándares preestablecidos.
--Sign (Signatario o firmante): encargado de dar la aprobación.
En líneas generales se debe tener en cuenta que todas las herramientas
utilizadas deben estar al servicio de los procesos y no al contrario. Es habitual
caer en el error de adaptar los procesos a las herramientas en vez de buscar
o adaptar las herramientas para que se ajusten a nuestros requisitos, lo que
puede empañar los esfuerzos de planificación y definición previos.
A la hora de escoger las herramientas adecuadas puede
servir de ayuda el uso de un análisis MoSCoW:
1. M (must have): Funcionalidades esenciales de
las que debe disponer la herramienta
2. S (should have): funcionalidades importantes de las que debe disponer la
herramienta pero que “pueden esperar” y admiten soluciones temporales.
3. C (could have): funcionalidades adicionales que
mejorarían el rendimiento o usabilidad de la herramienta.
4. W (will not have it now): funcionalidades accesorias que sería
interesante añadir en el futuro pero que ahora son prescindibles.