¿Qué es una matriz de prioridades?

Una matriz de prioridades es una herramienta que sirve para determinar la prioridad de cada tarea de la gestión de servicios de TI (IT Service Management, ITSM). Como su nombre sugiere, utiliza una matriz, es decir, un cuadro de doble entrada con filas y columnas. La prioridad de una tarea se determina asignándole un valor numérico para cada eje y observando en cuál casillero de la tabla queda ubicada. De esta manera, los equipos pueden definir de forma sistemática y coherente el orden en que abordarán sus tareas.

Una matriz de prioridades proporciona una visión general fácilmente comunicable de la manera en que la organización define sus prioridades en la gestión diaria de los problemas y desafíos. Su uso permite identificar las tareas urgentes y actuar con rapidez, mientras que las tareas de menor prioridad pueden tratarse a un ritmo más lento (pero siempre dentro de un plazo aceptable). Una matriz de prioridades también puede contribuir a mejorar la actitud y la forma de trabajar de los equipos de soporte técnico.

Las matrices de prioridades suelen utilizar dos parámetros: “impacto” y “urgencia”, de tal modo que muchos directamente la llaman “matriz de impacto y urgencia”. Aunque estos términos parecen fáciles de definir, son difíciles de aplicar en situaciones reales; por eso, es una buena práctica complementar una matriz de prioridades con una guía sobre cómo calificar las tareas y una serie de ejemplos ilustrativos, algo que veremos más adelante en este artículo.

¿Cuáles son las ventajas de utilizar una matriz de prioridades?

En primer lugar, le ayudará a resolver las tareas en el orden que más le convenga a su empresa, y esto incluye tareas de la gestión de incidentes, problemas, cambios y proyectos (con la matriz de prioridades de proyectos). Ahora bien, determinar adecuadamente la prioridad de las tareas no solo permitirá a su personal ser coherente a la hora de decidir qué tarea abordar y en qué secuencia hacerlo, sino que también le proporcionará la confianza necesaria para actuar, ya que toda la empresa conocerá y utilizará la matriz de prioridades. Otra ventaja es que aumentará la satisfacción de los usuarios de sus servicios. ¿Cómo? Si comparte la matriz de prioridades con sus clientes, estos podrán comprender por qué determinados incidentes se tratan antes que otros. Por último, si todas las áreas funcionales desarrollan en conjunto la matriz de prioridades, cada una de ellas comprenderá mejor las razones de las demás a la hora de priorizar su trabajo y eso mejorará las relaciones entre TI, ITSM y las demás áreas de la empresa.

Articular y documentar cómo se utilizan el impacto y la urgencia para determinar las prioridades eliminará cualquier incertidumbre sobre cómo los informáticos deciden qué tarea abordar a continuación. El uso de una matriz de prioridades también evita que, a la hora de determinar las prioridades de las tareas, el departamento de TI favorezca a un área de la empresa o a una persona en particular.

También es importante señalar que una matriz de prioridades es especialmente beneficiosa cuando los equipos de soporte están sobrecargados y tienen más tareas de las que pueden manejar. Sin una matriz, existe el riesgo de que el personal elija aquello en lo que quiere trabajar (por ejemplo, las tareas más sencillas o rápidas de realizar), lo que puede retrasar la resolución de tareas urgentes y de alto impacto, como los incidentes. Además, el uso de una matriz de prioridades evitará que se asignen excesivos recursos a un incidente que solo ha sido priorizado por la presión de un usuario, pero que, en realidad, no tiene un alto impacto. El verdadero problema de dejarse presionar por los usuarios es que otros incidentes que deberían ser prioritarios son empujados hacia abajo en la lista de espera.

¿Cuándo debería utilizar una matriz de prioridades?

Todas las organizaciones deberían utilizar una matriz de prioridades en todos los procesos de ITSM orientados a las tareas, en los que hay que decidir en cuál tarea trabajar a continuación. Esto incluye los siguientes procesos de ITSM:

El uso de una matriz de prioridades en todos estos procesos evitará que se asignen altos niveles de recursos a una tarea que se ha priorizado por presión de un usuario o un área o, simplemente, por falta de información.

Dicho de otro modo, debe incluirse una matriz de prioridades siempre que haya que decidir en qué tarea se va a trabajar a continuación, ya que eso ayudará a tomar la decisión de forma coherente y transparente. Se debe analizar cada proceso de ITSM para localizar estos momentos de decisión y, por supuesto, es necesario diseñar una matriz de prioridades adecuada. El proceso de diseño debe involucrar a todas las partes implicadas y afectadas (que probablemente sean TI, ITSM y otras áreas de la empresa), y la vara para medir la prioridad debe ser el impacto que cada tarea tiene en el día a día de la organización.

La gestión de incidentes es el proceso en el que más organizaciones utilizan las matrices de prioridades. Este es un proceso ideal para aprender a definir y utilizar esta herramienta porque, al menos en la mayoría de las empresas, la gestión de incidentes maneja el mayor volumen de tareas y la carga de trabajo suele superar a la capacidad disponible. Sin embargo, la matriz de prioridades ofrece beneficios en todos los procesos mencionados anteriormente, y su inclusión en el diseño inicial de cada uno de dichos procesos sería ideal para evitar la realización de cambios posteriores en las herramientas de software.

Impacto vs. urgencia en una matriz de prioridades

Lo ideal sería priorizar tareas utilizando una combinación de factores, como el impacto, la urgencia, el tamaño, el alcance, la complejidad y los recursos necesarios para su resolución. Sin embargo, incluir todos estos factores puede ser complejo de modelar e imposible de implementar. Por ello, la mayoría de los ejemplos de matrices de prioridades son una versión simplificada que solo tiene en cuenta el impacto y la urgencia.

Ahora bien, las definiciones precisas de impacto y urgencia dependerán del proceso en el que se utilice la matriz, de las características y requisitos de la organización, de las actividades del negocio a las que da soporte el proceso y de los niveles de servicio que se espera alcanzar. Para una explicación más clara, definiremos “impacto” y “urgencia” en el contexto de la gestión de incidentes. Veamos.

El impacto del incidente es la medida de la interrupción de la actividad diaria de la organización. Obsérvese que hablamos del impacto con respecto a la empresa y no a un usuario individual. Evaluar el impacto puede ser un reto para un agente de soporte técnico o un software, por lo que muchas organizaciones lo determinan con una métrica simple y fácil de conocer: el número de usuarios afectados, es decir, el impacto es directamente proporcional a la cantidad de usuarios que se ven perjudicados por el incidente. En consecuencia, el incidente de mayor impacto en la matriz de prioridades será aquel que afecte a todos los usuarios y el de menor impacto, aquel que afecte a un solo usuario.

Pero este enfoque esconde una trampa, ya que puede crear problemas en los servicios críticos que tengan un bajo número de usuarios. Por eso, es mejor considerar el porcentaje de usuarios afectados en relación con el total que utiliza cada servicio. Así, el impacto es máximo si el 100 % de los usuarios se ven afectados, independientemente de cuántos sean. Además, esta otra forma de ver el problema es especialmente útil cuando los servicios críticos fallan durante la noche o un fin de semana, momentos en los que el número de usuarios casi siempre es menor que en los horarios laborales.

En tanto, la urgencia se refiere a la velocidad con la que se necesita resolver el incidente y suele estar asociada a los objetivos de nivel de servicio para los servicios afectados, donde la urgencia aumenta si los contratos incluyen plazos cortos para la resolución de incidentes. La urgencia también puede depender de la criticidad del servicio afectado. Cuando se utiliza este enfoque, la matriz de prioridades debe incluir las diferentes criticidades de los servicios, información que debe estar disponible para poder realizar una evaluación correcta. También hay que tener en cuenta que la urgencia de ciertos servicios puede tener ciclos de variación (por ejemplo, los servicios de nómina son más críticos a fin de mes); sin embargo, esto puede ser difícil de considerar a menos que se disponga de una herramienta que realice cálculos automáticos, funcionalidad que incluyen algunos softwares.

 

Ejemplo de matriz de prioridades

El diseño de una matriz variará según la organización y el proceso en el que se aplique. Sin embargo, hay un ejemplo de matriz de prioridades básico para determinar la prioridad de una tarea en función del impacto y la urgencia, y es el siguiente:

ejemplo de matriz de prioridades ejemplo de matriz de prioridades

En esta sencilla matriz de prioridades, usted puede observar:

Teniendo todo esto en cuenta, hagamos el ejercicio de considerar un incidente que está afectando al servicio de reserva de la sala de reuniones. El incidente tiene un impacto alto, ya que afecta a todos los usuarios; en tanto, la urgencia es baja, ya que la criticidad del servicio es baja. A partir de la búsqueda de estos valores en la matriz de prioridades, podemos encontrar que la prioridad del incidente es nivel 3 (este es el casillero donde la columna “Impacto alto” intercepta la fila “Urgencia baja”). La prioridad de nivel 3 le señalará al personal de soporte técnico si es momento de abordar ese incidente o si hay otros más prioritarios.

Entendiendo las prioridades

Al utilizar una matriz de prioridades, es importante que todo el personal implicado entienda de qué depende la prioridad. Por ejemplo, en el proceso de gestión de incidentes, la matriz de prioridades suele contemplar solo el impacto y la urgencia. Pero, cuidado, porque a la hora de diseñar la matriz, la mayoría de las organizaciones no tiene problemas para definir los diferentes niveles de impacto y cómo evaluarlos; en cambio, definir la urgencia suele ser más enrevesado. En lugar de lanzarse a definir los parámetros para determinar la urgencia, es mejor analizar primero cuáles son las prioridades de su organización. Por lo general, hay cinco aspectos que deben considerarse con respecto a la urgencia de un incidente:

Antes de aprobar el diseño de una matriz, es importante definir estos factores y probarlos en escenarios simulados para chequear que la matriz arroja prioridades adecuadas. Si no lo hace, entonces debe revisar los parámetros de su matriz de prioridades, así como las condiciones que los determinan. Quizá descubra que necesita más de una matriz: por ejemplo, una que se utilice en los períodos más críticos de su empresa y otra para el resto del tiempo.

Para simplificar el asunto, algunas organizaciones determinan el impacto en función de los niveles de la organización que se ven afectados. Por ejemplo, niveles como toda la organización, una sede, un departamento, un equipo y un individuo. Esto permite hacer una evaluación del riesgo que implica no abordar la tarea.

¿Cuántos niveles de prioridad debería tener?

Una matriz de prioridades puede admitir cualquier número de niveles de prioridad. Sin embargo, lo recomendable es no tener más de cinco, y a muchas organizaciones les alcanza con tener solo tres. Esto se debe a que, a medida que aumenta el número de niveles, también lo hace la complejidad de la matriz de prioridades y la posible confusión a la hora de utilizarla. La mayoría de las personas entiende fácilmente los conceptos de prioridad alta, media y baja, cada una con un valor numérico asociado. Si incluye más niveles, puede ser difícil encontrar las palabras adecuadas para nombrar a cada uno.

Normalmente, una prioridad es mayor cuando el número de su nivel es menor, y viceversa. Por lo tanto, una prioridad de 1 es la más alta y debe tratarse siempre antes que al resto. Esto puede entrar en conflicto con otros sistemas de numeración, como los niveles de seguridad, en los que el número más alto presenta la mayor prioridad y el mayor riesgo para una organización. Es muy importante tener claro qué significa cada valor numérico en una matriz de prioridades, para así evitar confusiones.
 

Ejemplos de diferentes prioridades en una matriz

Siempre es recomendable proporcionar al personal ejemplos de los diferentes niveles de prioridad que pueden derivarse de una matriz de prioridades. Esto ayudará a su comprensión y hará más probable que el personal la utilice de forma inteligente.

Si tomamos el ejemplo de matriz de prioridades dado anteriormente, podemos determinar cinco niveles de prioridad, con la prioridad 1 (P1) como la más alta y la prioridad 5 (P5) como la más baja.

cómo acomodar las prioridades dentro de la matriz cómo acomodar las prioridades dentro de la matriz
Tareas de prioridad crítica

En el anterior ejemplo de matriz de prioridades, una tarea definida como P1 tiene un impacto alto y una urgencia alta. Estas tareas suelen ser críticas para el funcionamiento de una organización o presentan el mayor riesgo para ella. Las siguientes podrían ser tareas P1:

Ejemplos de fallos que podrían dar lugar a una tarea P1 en la matriz de prioridades son las interrupciones totales de la red, las infecciones de virus generalizadas, los ataques de denegación de servicio y las caídas del servicio de correo electrónico o de las aplicaciones.

 

Tareas de prioridad alta

Una tarea P2 tiene un impacto medio y una urgencia alta, o un impacto alto y una urgencia media. Son tareas en las que el tiempo de resolución sigue siendo importante, pero el efecto sobre la organización no es tan grande como el de una tarea P1. Las tareas P2 podrían incluir:

Algunos ejemplos de fallos que podrían dar lugar a una tarea P2 son las interrupciones parciales de la red, las infecciones de virus localizadas, la pérdida de alguna funcionalidad del correo electrónico y las interrupciones de aplicaciones no críticas.

 
Tareas de prioridad normal

Las tareas de prioridad “normal” suelen ser asignadas como P3 o P4 dentro de la matriz de prioridades. Se trata de tareas caracterizadas por lo siguiente:

A menudo se trata de problemas informáticos rutinarios, como fallos en impresoras o problemas en aplicaciones que solo afectan a unos pocos usuarios. Estos problemas deben ser resueltos, pero no son tan prioritarios como las tareas P1 o P2. Por lo tanto, si hay tareas pendientes con una prioridad más alta, deben tratarse antes que estas tareas P3 y P4.

 
Tareas de prioridad baja

Por último, las tareas identificadas como P5 en nuestro ejemplo de matriz de prioridades tienen un impacto bajo y una urgencia baja. Estas tareas son las de menor prioridad. Se trata de cuestiones cosméticas o problemas menores que permiten que los usuarios sigan realizando sus actividades. Ejemplos de tareas P5 son las faltas de ortografía en los informes o la mala disposición del contenido en una página web. Debe arreglarse, pero jamás priorizarse por encima de otras tareas con mayor impacto en la organización.

 

Guía para utilizar una matriz de prioridades

Es recomendable que cada organización redacte una guía para utilizar la matriz de prioridades, la cual debe incluir ejemplos ilustrativos de tareas con distintos niveles de prioridad. Esta guía debe actualizarse a medida que haya cambios en la organización o se experimenten problemas con prioridades mal asignadas.

Además, la guía debería utilizar números concretos. Por ejemplo, la afirmación “cuando se vean afectados varios usuarios” está abierta a la interpretación. En cambio, deben utilizarse números precisos que sean relevantes para la organización en cuestión. Por ejemplo, “cuando se vean afectados más de 10 y menos de 100 usuarios”. La guía para el uso de la matriz de prioridades también debe ser inequívoca, ya que lo que puede resultar obvio para la persona que redacta la guía puede no serlo para quienes la utilizarán.

También es aconsejable poner a prueba la guía. Para ello se deben presentar diferentes escenarios al personal que utilizará la matriz de prioridades y pedirle que determine la prioridad de la tarea a partir de lo que señala la guía. A continuación, quien diseñó la matriz de prioridades y el personal deben revisar los resultados para verificar que la tarea de priorización se haya llevado a cabo correctamente. Si se detecta algún problema, habrá que revisar la guía y la propia matriz de prioridades y, si es necesario, modificarlas. A continuación, la guía y la matriz deben volver a probarse en todos los escenarios, ya que un cambio realizado para solucionar un problema en un determinado escenario podría provocar problemas en otros escenarios en los que anteriormente no los había.

Matriz de prioridades y niveles de servicio

Muchas organizaciones tienen niveles de servicio que especifican el tiempo permitido para resolver solicitudes, incidentes y problemas. Cuando esto ocurre, el diseño de la matriz de prioridades debe tenerlo en cuenta, especialmente si el nivel de servicio para la resolución varía en función de la prioridad. Por ejemplo, si un contrato tiene niveles de servicio con diferentes objetivos para tareas de prioridad alta, media y baja, entonces la matriz de prioridades solo debería dar como resultado P1, P2 o P3.

El contrato debe definir con palabras cuáles son estas diferentes prioridades y qué criterios deben tenerse en cuenta para clasificar las tareas. Lo ideal sería que esto se plasmara en una matriz de prioridades y que esta sea parte del contrato. Los tiempos especificados para resolver las tareas variarán de una organización a otra, pero he aquí un ejemplo:

Estos plazos se definirán en los niveles de servicio documentados, pero no se incluirán en la matriz de prioridades. De todos modos, es buena práctica poner en los niveles de servicio un enlace que lleve a la matriz. ¿Por qué un enlace? Porque incluir una copia de la matriz de prioridades en los niveles de servicio puede causar problemas si posteriormente se debe cambiar la matriz.

Escalamiento de incidentes y matriz de prioridades

El escalonamiento es un mecanismo que ayuda a resolver los incidentes a tiempo y en ITSM los hay de dos tipos.

Escalamiento funcional

El escalamiento funcional tiene lugar cuando un incidente se reasigna a otro grupo de soporte porque el grupo actual que trabaja en él no tiene las habilidades necesarias para resolverlo. Algunas organizaciones optan por reasignar los incidentes a un grupo de soporte más experimentado después de que pase un cierto tiempo, el cual se define de acuerdo a lo establecido por el nivel de servicio. Además, ese tiempo suele variar en función del nivel de prioridad del incidente, de modo tal que es más corto para los incidentes de mayor prioridad.

 

Escalamiento jerárquico

El escalamiento jerárquico tiene lugar cuando el personal de soporte notifica a un nivel superior de autoridad sobre un incidente (casi siempre su gerente) o al propietario del servicio afectado.

El momento en que se debe escalar jerárquicamente depende de la prioridad del incidente y del nivel de servicio. Si hay peligro de incumplir el nivel de servicio, entonces se debe informar al gerente y al propietario del servicio para que puedan ayudar a no perder el objetivo de nivel de servicio y tomar medidas proactivas para garantizar la satisfacción del cliente. Obtener una prioridad correcta de la matriz de prioridades es más importante que nunca, ya que evita los escalamientos jerárquicos innecesarios. Este es el caso, sobre todo, de los incidentes de alta prioridad, ya que muchas organizaciones quieren alertar a la dirección y a los propietarios del servicio apenas los identifican mediante la matriz de prioridades.

Veámoslo con un ejemplo: Una organización puede tener un nivel de servicio para resolver un incidente P1 en dos horas, pero escalarlo jerárquicamente a la media hora (si aún no se resolvió). De este modo, la dirección estará al tanto del problema de prioridad 1 antes de que se incumpla el nivel de servicio. En cambio, para una incidencia P2 con un tiempo de resolución de cuatro horas, el escalamiento podría producirse pasadas tres horas. Por último, es posible que un incidente P3 con un tiempo de solución de dos días no se escale hasta que el nivel de servicio se incumpla, mientras que un P4 o P5 puede no escalar nunca.

En los casos en que se han establecido escalamientos jerárquicos, es importante comprobar que sus tiempos sean idóneos. También deben realizarse revisiones periódicas de los escalamientos producidos, lo que incluye al personal de soporte y a la dirección, para identificar si hay algún problema con la matriz de prioridades o con la guía asociada.

 

Utilización de una matriz de prioridades para los incidentes

La gestión de incidentes es el proceso más común en el que se utiliza una matriz de prioridades, ya que todas las organizaciones gestionan incidentes (incluso aquellas que no tienen un servicio de atención al cliente). El diseño y la utilización de una matriz de prioridades para priorizar las incidencias reportadas por los usuarios es esencial para garantizar la satisfacción del cliente. La mayoría de las veces, los equipos de soporte de su empresa tendrán más incidencias abiertas de las que pueden atender. Una matriz de prioridades les ayudará a secuenciar sus actividades para trabajar primero en los incidentes más importantes.

En la gestión de incidentes, primero se debe evaluar cómo el incidente está afectando a los usuarios, tanto en términos de impacto como de urgencia, para determinar niveles de prioridad acordes a lo establecido en la matriz de prioridades. De esta manera, garantizará que los incidentes que afectan a la empresa se solucionen lo más rápido posible, lo que eliminará las conjeturas del personal de soporte y evitará que elijan aquellas tareas que prefieren hacer primero.

La mayoría de los software admite la asignación automática de prioridades. Esto acelera el proceso de gestión de incidentes, aunque se recomienda que el personal de la mesa de servicio utilice la matriz para revisar la prioridad asignada automáticamente, ya que puede haber introducido incorrectamente los niveles de impacto y urgencia.

En tanto, algunas herramientas permiten que determinados usuarios, como los directores de la empresa y los usuarios críticos, sean identificados como “personas muy importantes” (Very Important People, VIP). Entonces, cuando se recibe un incidente de estos usuarios, aumenta automáticamente la urgencia o el impacto para su uso en la matriz de prioridades, lo que permite la asignación de prioridades más altas de lo habitual para este tipo de incidentes.

Por último, hay software con capacidad para evaluar el impacto de los incidentes según diversos factores, como la criticidad de los sistemas o servicios, el momento del día o la semana y los grupos de usuarios afectados. Estas herramientas registrarán estos factores en relación con cada incidente, algo útil para analizar la prioridad asignada en caso de una disputa.

Con respecto a las disputas sobre las prioridades asignadas, es aconsejable diseñar un procedimiento para resolverlas. Aunque una matriz de prioridades simplifica la asignación de las prioridades, estas siguen dependiendo de la información obtenida de los usuarios y de los sistemas de monitoreo. Ahora bien, la expectativa de cada usuario es diferente y, por lo tanto, habrá ocasiones en las que la matriz de prioridades otorgue al incidente una prioridad diferente a la esperada por él o ella. Cuando esto ocurre, el usuario debe poder disputar la prioridad que se le ha asignado a su incidente, con la posibilidad de que el servicio de soporte modifique la prioridad si considera que el usuario tiene razón.

Hay otras razones por las que debe ser posible cambiar la prioridad de un incidente durante su ciclo de vida. Por ejemplo, cuando se subestima el impacto total del incidente apenas este es reportado. En esos casos, el incidente primero recibe una prioridad baja, ya que la matriz de prioridades le adjudica un impacto bajo. A medida que más usuarios informan síntomas idénticos o similares, el impacto aumenta y la matriz de prioridades le debería reasignar una prioridad más alta. Para este tipo de incidentes, en los que el impacto conocido aumenta con el tiempo, es importante seguir utilizando la matriz de prioridades para determinar las nuevas prioridades. De esta manera, los servicios de soporte no aumentan las prioridades injustificadamente como producto de la presión de los usuarios, una dinámica que da lugar a incoherencias y fomenta que los usuarios tengan comportamientos poco útiles para la empresa o, directamente, perjudiciales para ella.

Utilización de una matriz de prioridades para los incidentes graves

Un incidente grave es un incidente con un impacto adverso extremo para la empresa. Puede tratarse de una perturbación excesiva de los servicios o del riesgo de que ocurra en el futuro debido a acontecimientos como el ataque de un virus informático. Es práctica estándar tener una variante del proceso de gestión de incidentes para estos casos graves, que reconoce la urgencia con que deben resolverse. Su matriz de prioridades debe ser capaz de identificar claramente qué incidentes son importantes en función del impacto y de la urgencia. Los incidentes graves tienen, por definición, la máxima prioridad. Es clave verificar mediante pruebas de escenarios que su matriz de prioridades puede identificar qué incidentes son graves y cuáles son solo de prioridad alta.

Qué características tienen los incidentes graves dependerá de cuántos niveles diferentes se incluyan en su matriz de prioridades. Los incidentes graves serán siempre P1; sin embargo, si solo tiene tres niveles de prioridad, corre el riesgo de invocar el proceso de incidentes graves de forma regular. Es mejor tener más niveles en su matriz de prioridades y reservar P1 para los incidentes realmente importantes que tienen un impacto adverso extremo en la empresa. Esto requiere un análisis cuidadoso de sus servicios, incluidas la evaluación de su verdadera criticidad para el negocio y una comprensión cabal de cómo los usuarios utilizan esos servicios.

Utilizar una matriz de prioridades para los problemas

Así como con los incidentes, una matriz de prioridades puede ser útil para evaluar los problemas. Las consideraciones para los problemas son las mismas que para los incidentes y los parámetros principales pueden seguir siendo el impacto y la urgencia. Las evaluaciones de cada una de estas dimensiones serán similares, pero la orientación y la prioridad resultante serán diferentes. El impacto puede seguir basándose en la proporción de usuarios afectados por el problema concreto, de modo que, a medida que aumente su porcentaje, también lo haga la prioridad. Sin embargo, la urgencia debe tener en cuenta algo más que la criticidad del servicio afectado para la organización.

Otros factores que debe contemplar son la viabilidad de la resolución del problema, el costo de la resolución en relación con su beneficio y, lo más importante, la existencia de opciones alternativas. Por ejemplo, una matriz de prioridades podría determinar una prioridad baja para un problema en un servicio que está afectando a todos los usuarios, pero que tiene un servicio alternativo. Con el mismo razonamiento, también podría determinar una prioridad baja para un problema que esté afectando a varios usuarios, pero cuya resolución tenga un costo significativamente mayor que el beneficio que se obtendrá con su solución.

Esta puede ser un área compleja de modelar. Por eso, la mayoría de las organizaciones que adoptaron una matriz de prioridades solo la utilizan para obtener una orientación inicial de la prioridad de los problemas. Los equipos de desarrollo tienen una capacidad finita y, por lo tanto, es probable que tengan más problemas con el mismo nivel de prioridad de los que pueden tratar al mismo tiempo. Entonces, la prioridad inicial derivada de la matriz de prioridades es revisada conjuntamente por los representantes de los usuarios y del personal informático teniendo en cuenta los otros problemas y otros factores, incluida una estimación del tiempo que demandará la solución.

Utilizar una matriz de prioridades para los cambios

Una matriz de prioridades también es útil en la gestión del cambio, en especial cuando hay más cambios de los que el consejo asesor puede revisar en el tiempo disponible. El impacto y la urgencia pueden utilizarse al igual que para la gestión de incidentes y la gestión de problemas. Sin embargo, en este caso, el impacto debe considerarse de dos maneras: El impacto adverso para la organización si el cambio no se hace y el impacto beneficioso de hacerlo. Esto debería reflejarse en la matriz de prioridades, ya que deberá evaluar cambios que resuelven problemas, cambios que hacen mejoras y cambios que añaden nuevas funcionalidades.

En la gestión del cambio, la matriz de prioridades puede seguir considerando la urgencia en función de la criticidad, pero debe basarse en lo esencial que es el cambio para la organización. Algunos cambios deben realizarse para mantener la competitividad en la economía digital actual, mientras que otros deben realizarse para resolver incidentes de gran impacto. Evaluar la urgencia de este modo también ayuda a programar el cambio, lo que garantiza que aquellos más urgentes tengan prioridad para su implementación.

Una matriz de prioridades también puede ayudar a los auditores a obtener una visión global de los cambios, ya que la matriz ilustrará el impacto relativo y urgencia de cada uno. Por último, una matriz puede evitar que el departamento de TI presione para implementar un cambio que, en realidad, tiene un valor limitado para el negocio.

Utilización de una matriz de prioridades para la gestión de la continuidad del servicio

La gestión de la continuidad del servicio de TI, a menudo denominada “recuperación de desastres”, es el proceso que restablece el servicio tras una pérdida importante del mismo. Una matriz de prioridades puede ser muy útil para organizaciones con un gran número de sistemas, ya que, en caso de desastre, es imposible que haya recursos suficientes para recuperar todos los sistemas al mismo tiempo. Entonces, habrá que decidir qué restablecer primero y una matriz de prioridades sirve exactamente para eso. Lo ideal es que la matriz se diseñe y se pruebe antes de que ocurra la catástrofe.

Las dimensiones de la matriz de prioridades serán el impacto y la urgencia, del mismo modo que ocurre en otros procesos de ITSM. El objetivo es utilizar la matriz para priorizar la recuperación de los sistemas en función de las necesidades de la empresa. Por lo tanto, las definiciones de impacto y urgencia dependerán totalmente de cada organización. Veamos un ejemplo: para una organización que vende sus productos por Internet, todos los sistemas que permiten el servicio de venta deberían tener una mayor urgencia, ya que son los más críticos de recuperar. El impacto puede basarse en el número de usuarios afectados, que se combinaría con la urgencia para dar una prioridad adecuada al restablecimiento del servicio.

Conclusión

Si se utiliza correctamente, una matriz de prioridades es una herramienta útil y valiosa para todos los procesos de ITSM. El concepto de matriz de prioridades ayuda a impulsar la consistencia y la comprensión, a no depender de los conocimientos de un solo individuo y a alinear el trabajo de la ITSM con los intereses de la empresa.