Los roles en una matriz RACI

0

Cuando explico una matriz RACI a alguien siempre me cuesta un poco más explicar es la diferencia entre “Responsible” la R de la matriz RACI y “Accountable” la A de la matriz RACI. Son dos figuras diferenciadas, muy importantes cuando se definen los roles en una tarea. Y también veo confusión con lo que significa ubicar a alguien en los roles “Consult” la C de la matriz RACI, e “Inform” la I de la matriz RACI.

Vamos a ver estos roles en detalle.

Introducción a la matriz RACI

Ya hice una breve introducción de la matriz RACI. Pero creo que me quedé corto y asumí que el lector ya conocía perfectamente esta herramienta. Así que vamos a hacer una introducción a la matriz.

La matriz RACI es una herramienta que que permite identificar a las personas o áreas de una organización que están involucradas con determinadas tareas o responsabilidades. Es la herramienta que sirve tanto para:

  • Definir quién hace qué en cada momento.
  • Poder consultar rápidamente quién hace qué.

Es decir, es una herramienta para ayudarnos a definir el procedimiento y para luego distribuirlo. Lo que se hace es tan simple como para cada tarea definir qué personas ocupan los 4 roles clave de esa tareas. Esos roles son los siguientes, y se corresponden con las letras de la matriz RACI:

  • Responsible: Encargado o encargados de realizar la tarea.
  • Accountable: Responsable en última instancia de que se ejecute la tarea.
  • Consult: Personas que deben ser consultadas para realizar la tarea, ya sea por su conocimiento o por implicaciones.
  • Inform: Personas que deben ser informadas del avance de la tarea.

Así por ejemplo podríamos coger una tarea que la de hacer el simulacro del SAI del CPD durante cada sábado.

  • Responsible: El técnico de operaciones asignado a la guardia ese sábado.
  • Accountable: El Administrador Jefe del CPD.
  • Consult: Los 3 lideres de los equipos de adminsitración.
  • Inform: A todos los miembros de operaciones de TI, personal del Help Desk y lideres de los equipos de desarrollo.

Así de un plumazo vemos que será el técnico quien hará el simulacro. Que es responsabilidad del administrador jefe del CPD. Que antes de hacerlo hay que preguntar a los tres lideres de los equipos de administración y que tras hacerlo hay que informar a mucha gente. No da la instrucción técnica, ni dice cómo preguntar o como informar, pero ya da una idea.

Responsible

La traducción al castellano no debe ser “Responsable”, sino de “Encargado”, “Asignado” o “Ejecutor”. Es quién tiene que hacer la tarea. Puede ser un equipo y que no esté claro del todo quién lo tiene que hacer. Alguno o algunos tendrán que hacerlo. Los otros roles no son quienes lo hacen.

Como es obvio, siempre tiene que haber como mínimo un “Responsible”, pero puede haber muchos más.

Accountable

La traducción al castellano es “Responsable”. Es la persona que debe asegurarse de que se haga, y de que se haga bien. No tiene por qué hacerlo esa persona, pero es la que tiene que vigilar el proceso. Accountable tiene que haber uno y sólo uno. No puede haber dos. Si no corremos el riesgo de crear una responsabilidad compartida y que el uno por el otro “se quede la casa sin barrer”.

Normalmente el Accountable suele tener el poder de definir las reglas de juego. Suele poder modificar procesos o herramientas para asegurar que el trabajo se haga y se haga correctamente.

Diferencia entre Responsible y Accountable

La diferencia puede parecer sutil, pero es clara. El Responsible es quien hace la tarea y el Accountable es a quien van a cortar la cabeza si no se hace o se hace mal. Podrían ser la misma persona, pero no siempre tiene por qué serlo. De hecho es sano que no lo sean. Esto es porque primero es sano que haya más de un Responsible, ya que si no se crea una dependencia con la persona. Si esa persona esta de baja o vacaciones, ya no se hace. Entonces si hay más de uno, no pueden ser todos Accountable, porque crearíamos una responsabilidad compartida. Además ser Responsible y Accountable a la vez, significa que pones toda la carne en una persona. No creas una dualidad. Cuando son dos personas permites un doble control. Si uno de los dos falla (el responsible no hace o el accountable no controla) el sistema sigue funcionando, porque con una de las dos piezas se controla el proceso. Si el accountable no controla, el responsible habra hecho y no pasará nada. Si el responsible no hace, el accountable se dará cuenta y moverá fichas para que se haga.

Consult

La traducción correcta sería “Preguntar a” o “pedir permiso a”. Son personas o roles que deben dar su OK al proceso. Este OK puede tener muy diversas maneras de implementarse y puede ir desde requerir una aprobación formal hasta ser informados y tener la capacidad de pararlo. Normalmente incluir a alguien en Consult es sinónimo de tener que pedir la aprobación a esas personas.

Las personas en Consult suelen ser interesados en la tarea cuyo trabajo puede verse seriamente impactado y tienen el derecho a autorizar el proceso para asegurar que no les impacta en exceso. Otra opción es que tienen un rol de control de alto nivel porque suele haber un gasto involucrado y deben aprobarlo.

Puede (y de hecho es lo normal) no haber nadie en Consult. Incluir a alguien en Consult es como incluir una fase de aprobación previa.

Inform

La traducción correcta sería “Mantener informado a”. Es la lista de interesados en la tarea. Te da la lista de personas a las que hay que informar de que se ha hecho la tarea. Al contrario que los consult, de estas personas no se espera que puedan “parar” el proceso. Sólo estar informados.

Normalmente se sobreentiende que cualquier persona en la R, la A o la C, automáticamente se incluye en la I, por lo que no se suelen volver a nombrar.

Relación entre Consult e Inform

Son dos roles muy parecidos. En conjunto los dos conforman la lista de interesados en el proceso. Pero hay una sutil diferencia. La C tiene capacidad de aprobacion y la I no.

Una manera de verlo es que a la C hay que avisarle antes de que se realice la tarea, y dotarle de mecanismos para la aprobación, ya sea formal o por silencio. En cambio a la I hay que avisarle después de que se realice la tarea.

Lo anterior no siempre es cierto, ya que hay ocasiones en las que a la I hay que avisarle, para que esté preparada. Pero no con motivo de aprobación, sólo para que esté preparada. Un ejemplo típico es el aviso por una pérdida de servicio programada. Hay personas (el CAB, por ejemplo) que deben aprobar esa actuación. Pero hay otras que deben ser informadas de que a tal hora no habrá sistemas. Este aviso es para que no les pille sin estar preparados, no para que avisen de que les va mal esa hora. De eso ya se ha encargado el CAB.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

No comments

Te puede interesar...