A matriz de prioridade, ou matriz de priorização, é uma técnica de gerenciamento de serviços de TI (ITSM) que pode ser utilizada para determinar a prioridade de uma tarefa sobre outras. Como sugere o nome, a matriz é utilizada para determinar a prioridade que contém valores predefinidos para duas características diferentes, uma em cada eixo da matriz. A prioridade é definida mapeando a situação enfrentada para esses valores na matriz. O resultado de utilizar a matriz de prioridade é que, dessa forma, as equipes podem definir consistentemente em qual ordem devem lidar com as tarefas e ações.
Uma matriz de prioridade oferece uma visão geral fácil de comunicar sobre como a empresa define suas prioridades no gerenciamento cotidiano de problemas e desafios. Usar uma matriz de priorização significa que tarefas de alta prioridade podem ser facilmente identificadas e prontamente acionadas, enquanto permite lidar em um ritmo mais calmo com as tarefas de menor prioridade, mas ainda dentro de um prazo aceitável. Uma matriz de prioridade também pode ajudar a mudar atitudes e comportamentos da equipe de suporte, bem como a entender como priorizar corretamente tarefas e ações.
Uma matriz de prioridade geralmente utiliza as características "Impacto" e "Urgência". Estes termos simples podem ser difíceis de aplicar em situações reais, por isso, uma boa prática é suplementar a matriz de priorização com diretrizes e exemplos. Algumas empresas se referem à matriz de prioridade como "Matriz de Urgência e Impacto".
Utilizar uma matriz de prioridade vai te ajudar a lidar com as tarefas da melhor forma para o negócio. Isso inclui gestão de incidentes, problemas, mudanças e projetos. Determinar a prioridade mais apropriada usando a matriz possibilitará que sua equipe seja consistente em como decide qual tarefa abordar e em qual sequência. Isso oferece ao time a confiança para fazer o que acreditam ser certo, já que a matriz de prioridade será usada da mesma forma por toda a equipe. Em retorno, isso melhora a satisfação dos clientes com seus serviços. Se você compartilhar a matriz de priorização com seus clientes, eles poderão entender o por que de certos incidentes serem atendidos antes de outros. Uma matriz de prioridade pode melhorar o relacionamento entre TI, ITSM e o negócio. Se você desenvolver uma matriz de prioridade como um esforço conjunto envolvendo todas essas áreas, cada uma delas conseguirá entender melhor as perspectivas dos demais ao priorizar trabalhos.
Os eixos de Impacto e Urgência são usados para determinar prioridades através da matriz. Isso ajudará a remover quaisquer incertezas sobre como a área de TI decide a sequência em que irá trabalhar nas tarefas. Utilizar uma matriz de prioridade também ajuda a evitar que o TI favoreça uma parte do negócio ou um indivíduo ao determinar as tarefas prioritárias.
Uma matriz de prioridade é particularmente benéfica quando uma equipe de suporte fica sobrecarregada, com mais tarefas do que consegue lidar ao mesmo tempo. A menos que uma matriz de comum acordo seja usada para determinar prioridades, há um risco de que a equipe "escolha a dedo" no que deseja trabalhar, o que pode causar atrasos na resolução de tarefas urgentes e de alto impacto como incidentes. Utilizar uma matriz de prioridade para determinar quando um incidente é considerado grave evitará uma situação na qual altos níveis de recursos são atribuídos a um incidente priorizado por pressão do negócio, mas que não é de alto impacto. A consequência indireta de considerar a pressão do usuário no lugar da matriz de prioridade é que outros incidentes que deveriam ter sido priorizados acabam indo para o fim da fila.
Todas as empresas devem usar uma matriz de priorização em cada processo de ITSM orientados a tarefas, onde decisões precisam ser tomadas sobre qual em tarefa trabalhar na sequência, incluindo:
Utilizar uma matriz de prioridade nessas atividades evita que altos níveis de recursos sejam despendidos em uma tarefa que foi priorizada por pressão ou por falta de informação.
Uma matriz de prioridade deve ser incluída na definição de cada etapa do processo onde uma decisão precisa ser tomada sobre qual tarefa será trabalhada a seguir. A matriz de priorização vai auxiliar essa decisão de forma consistente e transparente. Cada processo de ITSM deve ser examinado para localizar estes pontos de decisão, e a criação de uma matriz de prioridade deve incluir todas as partes envolvidas e afetadas, que geralmente são TI, ITSM e o negócio. O impacto para os negócios cotidianos das empresas deve ser o condutor para determinar quais são as tarefas de maior prioridade na matriz.
O processo mais comum onde as empresas usam uma matriz de prioridade é a gestão de incidentes, onde ela é utilizada para determinar a prioridade dos incidentes. Este é um processo ideal para aprender como definir e usar uma matriz de priorização, pois na maioria das empresas os processos de gestão de incidentes lidam com o maior volume de tarefas e a carga de trabalho geralmente ultrapassa a capacidade de atendimento. Contudo, benefícios podem ser obtidos ao incluir o uso de uma matriz de prioridade em outros processos listados acima. Idealmente, a matriz de prioridade deve ser incluída no projeto inicial desses outros processos, para evitar o retrabalho e alterações nos toolsets utilizados.
Idealmente, as tarefas devem ser priorizadas usando uma combinação de fatores incluindo impacto, urgência, tamanho, escopo, complexidade e recursos necessários para resolução. Contudo, incluir todos esses fatores pode ser complexo para o modelo e difícil de entender. Por isso, a maioria dos exemplos de matriz de priorização são versões simplificadas que consideram somente Impacto e Urgência para determinar prioridade.
As definições exatas de Impacto e Urgência na matriz de prioridade dependem do processo onde a matriz está sendo usada, as características e os requisitos da empresa, os processos de negócios que o processo suporte, e quaisquer níveis de serviço contratados que se espera alcançar. Para oferecer uma compreensão melhor, as definições a seguir são usadas em uma matriz de priorização para determinar a prioridade de um incidente em um processo de gestão de incidentes.
O Impacto do incidente é a medida de disrupção dos negócios cotidianos da empresa. Perceba que este é o Impacto para a empresa, não para um usuário individual, portanto reflete o quão crítica é a perda de serviço para a empresa. Como isso pode não ser simples para um agente de service desk ou um toolset definir utilizando a matriz de prioridade, muitas empresas aplicam uma métrica simples para determinar o Impacto com base no número de usuários afetados pelo incidente. Assim, o maior Impacto na matriz de prioridade é aquele onde todos os usuários foram afetados pelo incidente, e o menor Impacto é aquele onde apenas um usuário foi afetado. Isso pode criar diversos problemas para serviços essenciais com um número baixo de usuários, portanto uma abordagem melhor para avaliar o Impacto em uma matriz de prioridade é usar a porcentagem de usuários afetados para o(s) serviço(s) impactados. Portanto, o Impacto é maior se 100% dos usuários são afetados, independentemente do número de usuários. Esta abordagem é útil quando serviços essenciais são afetados à noite ou durante o fim de semana, quando o número de usuários é bem menor do que durante o horário de trabalho convencional em dias de semana.
A Urgência é a velocidade necessária para resolver o incidente. Ela é frequentemente associada com o prazo de resolução dos serviços afetados, de modo que a Urgência na matriz de prioridade aumenta quando o contrato inclui tempos curtos de resolução de incidentes. A Urgência também pode depender da criticidade do serviço afetado pelo incidente. Onde esta abordagem for utilizada, a matriz de priorização deverá incluir informações sobre as diferentes criticidades dos serviços, para que as avaliações sobre Urgência possam ser feitas corretamente. Alguns toolsets podem realizar cálculos automáticos para determinar a Urgência com base nesses fatores. A Urgência para determinados serviços pode variar com o tempo, por exemplo, serviços de folha de pagamento no fim do mês. Contudo, pode ser difícil incluir isso em uma matriz de prioridade, a menos que cálculos automáticos estejam disponíveis.
O design da matriz de prioridade varia conforme a empresa e seus processos. Aqui está um exemplo de uma matriz genérica que determina a prioridade com base no Impacto e na Urgência:
Nesta matriz de prioridade simples, existem:
Por exemplo, considere um incidente que está afetando todos os usuários de um serviço de baixa criticidade, como um serviço para reservar salas de reunião. O incidente possui alto Impacto caso esteja afetando todos os usuários. A Urgência é baixa, pois a criticidade do serviço é baixa. Ao usar a matriz de prioridade para procurar estes valores, a prioridade do incidente será definida como 3 — este é o valor onde a coluna de Alto Impacto intercede com a linha de Baixo Impacto. Essa prioridade conforme determinada pela matriz de prioridade será então atribuída ao registro de incidentes para que a equipe de suporte possa ver qual é a prioridade.
Ao usar uma matriz de prioridade, ainda é importante que todos os funcionários envolvidos entendam o que conduz a prioridade. Por exemplo, no processo de gestão de incidentes, a matriz costuma usar somente Impacto e Urgência para determinar a prioridade do incidente. Ao projetar a matriz de prioridade, a maioria das empresas não encontra dificuldades em definir os diferentes níveis de Impacto e como avaliá-los, mas definir a Urgência pode ser mais desafiador. Você precisa decidir no mundo real o que conta para esses fatores. Ao invés de simplesmente definir valores para Urgência, uma melhor ideia é se distanciar por um momento da matriz de prioridade e discutir o que determina as prioridades para sua empresa. Geralmente são estes cinco aspectos diferentes que devem ser considerados e entendidos ao projetar uma matriz de priorização:
É importante usar esses fatores para modelar diferentes cenários usando a matriz de prioridade para validar que a mesma te entregará a prioridade apropriada. Se não entregar, você deverá rever os valores em sua matriz de priorização, bem como os valores das condições que os determinam. Pode ser necessário utilizar mais de uma matriz, por exemplo, uma matriz de prioridade que será usada em períodos críticos para o negócio, e outra usada o restante do tempo.
Para ilustrar, algumas empresas determinam o Impacto na matriz de prioridade com base em quais níveis da empresa são afetados. Por exemplo, considerando a empresa, a localização, o departamento, a equipe e o indivíduo. Isso possibilita fazer uma avaliação usando a matriz de prioridade como escala do risco caso a tarefa não seja abordada.
Uma matriz de prioridade pode atender qualquer número de diferentes prioridades. Contudo, a recomendação é não passar de cinco prioridades, e muitas empresas usam somente três. Isso porque a complexidade e a confusão aumentam conforme o número de prioridades sobe. A maioria das pessoas aceita prontamente o conceito de alta, baixa e média prioridade, cada uma associada a um valor numérico. Quando sua matriz de prioridade inclui mais de três valores, pode ser difícil associar as palavras certas a cada prioridade.
Geralmente, o valor para uma prioridade é maior quando a prioridade é baixa e vice-versa. Sendo assim, em uma matriz de priorização, a prioridade 1 é a mais alta, e deve ser a primeira a tratar. Isso pode conflitar com outros sistemas numéricos como níveis de segurança, onde o número maior apresenta maior prioridade e risco para a empresa. É muito importante entender o que cada valor numérico significa em uma matriz de prioridade, pois isso evita confusão.
Na sua empresa, é uma boa ideia oferecer aos funcionários exemplos de diferentes prioridades que podem ser derivadas de uma matriz de prioridade. Isso ajudará no entendimento e provavelmente resultará em uma equipe que usa a matriz de prioridade de forma inteligente.
Tome como exemplo a matriz de prioridade que vimos anteriormente, onde há cinco prioridades possíveis, com a Prioridade 1 (abreviada como P1), como a mais alta:
Uma tarefa definida no exemplo de matriz de prioridade como P1 possui alto Impacto e alta Urgência. Essas tarefas geralmente são críticas para a operação contínua da empresa, ou apresentam maior risco para ela. Tarefas P1 da matriz de prioridade podem incluir:
Exemplos de falhas que podem obter como resultado uma P1 na matriz de prioridade são interrupções completas da rede, infecções generalizadas de vírus, ataques de negação de serviço, interrupções de e-mail e interrupções completas de aplicativos.
Uma tarefa P2 no exemplo de matriz de prioridade possui médio Impacto e alta Urgência, ou alto Impacto e média Urgência. Essas são tarefas onde a rápida resolução é importante, mas o efeito para a empresa não é tão sério como na tarefa P1. As tarefas P2 na matriz de prioridade podem incluir:
Exemplos de falhas que podem obter como resultado uma P2 na matriz de prioridade são interrupções parciais da rede, infecções locais de vírus, perda de algumas funções de e-mail e interrupções em aplicações não-críticas.
Tarefas de prioridade "normal" têm prioridade P3 ou P4 atribuída pela matriz de prioridade. São as tarefas onde:
Costumam ser problemas rotineiros de TI, como problemas na impressora ou em aplicações que afetam poucos usuários. Estes problemas ainda precisam ser resolvidos, porém, não são tão urgentes como as tarefas identificadas com alta prioridade pela matriz de prioridade. Então, se há tarefas pendentes com prioridade mais alta, elas devem ser tratadas antes das tarefas P3 e P4.
Tarefas identificadas como P5 pela matriz de prioridade têm baixo Impacto e baixa Urgência. Essas tarefas possuem a menor prioridade. São problemas secundários, e os usuários ainda conseguem continuar com suas atividades de negócios. Tarefas P5 tendem a ser questões cosméticas ou pequenos acontecimentos. Alguns exemplos incluem erros ortográficos em relatórios, ou um layout ruim para o conteúdo de uma página web. Ainda precisam ser resolvidos, mas não devem ser priorizados em relação às demais tarefas.
Criar um guia com orientações de como usar a matriz de prioridade é uma boa ideia para todas as empresas. Essas orientações devem incluir exemplos significativos para a empresa em questão, considerando tarefas de diferentes prioridades da matriz. O guia para usar a matriz de prioridade deve ser atualizado de tempos em tempos conforme novos exemplos forem encontrados, e quaisquer problemas com prioridades incorretas sejam identificados.
As orientações devem incluir intervalos específicos envolvendo números. Por exemplo, "quando muitos usuários foram afetados" fica aberto a interpretações. Números precisos, que sejam relevantes para a empresa em questão, devem ser usados no guia da matriz de prioridade. Por exemplo, "quando mais de 10, porém menos de 100 usuários forem afetados". As orientações da matriz de prioridade também precisam ser livres de ambiguidade. O que é óbvio para a pessoa que está criando o guia pode ser menos óbvio para a pessoa que irá usar a matriz de prioridade.
É indicado testar as orientações em um "piloto de sala de conferência". Ou seja, diferentes cenários devem ser apresentados à equipe que vai usar a matriz de prioridade. A equipe determinará a prioridade da tarefa utilizando o cenário, as orientações e a própria matriz de prioridade. O criador da matriz de prioridade e a equipe então devem conferir os resultados, verificando se a prioridade correta foi derivada da matriz. Se ainda houver algum problema, as orientações e a própria matriz de prioridade deverão ser revisadas e atualizadas, caso necessário. Todos os cenários devem ser executados novamente, pois uma mudança para corrigir um problema pode inadvertidamente causar novos problemas em cenários que foram anteriormente considerados com a prioridade adequada.
Muitas empresas possuem níveis de serviço que especificam o prazo para resolver problemas, solicitações e incidentes. Onde existem níveis de serviço, o desenho da matriz de prioridade deve levá-los em consideração, principalmente onde o nível de serviço para resolução varia conforme a prioridade. Se níveis de serviço que dependem de prioridades forem definidos em um contrato, então a matriz de prioridade deve incluir as mesmas prioridades com precisão, do contrário pode haver confusão. Por exemplo, se um contrato tem níveis de serviço com diferentes metas para tarefas com prioridade 1, prioridade 2 e prioridade 3, então a matriz de prioridade só pode trazer como resultado P1, P2 ou P3. O contrato deve definir em palavras quais são essas diferentes prioridades e o que deve ser usado para derivá-las. Idealmente, isso deve estar na matriz de prioridade, como parte do contrato.
Os prazos especificados para resolver tarefas dependendo da prioridade obtida na matriz de prioridade variam de empresa para empresa, mas aqui vai um exemplo:
Estes prazos serão definidos nos níveis de serviço documentados, e não serão incluídos na matriz de prioridade. É uma boa ideia fornecer um link para a matriz de prioridade nos níveis de serviço. Copiar a matriz de prioridade para os níveis de serviço documentados pode causar problemas de consistência caso ocorram futuras alterações na matriz de prioridade.
Escalonamentos de incidentes são mecanismos que ajudam a resolver incidentes no prazo. Os escalonamentos usam a prioridade do incidente derivada a partir da matriz de prioridade. Em ITSM existem duas categorias de escalonamento de incidente:
O escalonamento funcional ocorre quando um incidente é transferido para outro grupo de suporte porque o atual grupo trabalhando no incidente não possui as habilidades necessárias para resolver o incidente. Algumas empresas escolhem transferir incidentes para um grupo de suporte mais experiente após um intervalo de tempo pré determinado, de acordo com o nível de serviço. O intervalo de tempo geralmente varia conforme a prioridade do incidente obtida através da matriz de prioridade, sendo mais curto para incidentes com prioridade mais alta.
O escalonamento hierárquico ocorre quando a equipe alerta um nível superior de autoridade sobre um incidente, geralmente a gestão ou o proprietário do serviço afetado pelo incidente. O gatilho para quando utilizar o escalonamento hierárquico dependerá da prioridade obtida através da matriz de prioridade e o nível de serviço do incidente. Se o nível de serviço corre o risco de ser violado, então a gestão e o proprietário do serviço devem ser informados, de modo que ajudem a preservar o cumprimento da meta de nível de serviço para essa prioridade de incidente, e tomar medidas proativas para manter a satisfação do cliente. Derivar a prioridade correta da matriz é uma etapa importante, pois ajuda a evitar escalonamentos hierárquicos desnecessários. É o caso principalmente em incidentes de alta prioridade, já que muitas empresas querem alertar a gestão e o proprietário do serviço assim que a prioridade for identificada utilizando a matriz.
Por exemplo, uma empresa pode ter um nível de serviço para responder a um incidente P1 em até 30 minutos, mas caso não consiga resolver em até 20 minutos, deverá escalonar para a gestão. Isso garante que a gestão esteja a par do problema de prioridade 1 antes que o nível de serviço seja violado. Em contraste a isso, para um incidente P2 com prazo de 4 horas para resolução, o escalonamento não deve ocorrer até que ao menos 3 horas tenham se passado. Um incidente P3 com prazo de resolução de 1 hora não deve ser escalonado até que o nível de serviço tenha sido violado, e incidentes P4 e P5 nunca devem ser escalonados para a gestão.
Onde ocorrem escalonamentos hierárquicos, é importante incluir o teste dos escalonamentos na etapa de teste de cenários. Também devem haver constantes revisões dos escalonamentos que já ocorreram, incluindo a equipe de suporte e a gestão, para identificar se há algum problema com a matriz de prioridade, ou com a orientação de prioridade associada, que precisem ser tratados.
A gestão de incidentes é o processo mais comum onde uma matriz de prioridade é usada. Praticamente toda empresa realiza a gestão de incidentes, mesmo aquelas que não possuem um service desk. Projetar e usar uma matriz de prioridade para determinar a prioridade de todos os incidentes reportados pelos usuários é essencial para construir e manter a satisfação do usuário. Na maior parte do tempo, suas equipes de suporte terão mais incidentes em aberto do que conseguem tratar. Uma matriz de prioridade vai ajudar o time a sequenciar suas atividades, trabalhando primeiro nos incidentes mais importantes. Para a gestão de incidentes, a matriz de prioridade utilizará uma análise de como os incidentes estão afetando os usuários em termos de impacto e urgência para definir a prioridade. Usar uma matriz de prioridade dessa forma garante que os incidentes afetando os negócios tenham prioridade, removendo qualquer suposição feita pela equipe de suporte, e ajudando a evitar que os agentes "escolham a dedo" em quais tarefas preferem trabalhar primeiro.
A maioria dos toolsets possibilita a alocação automática da prioridade de um incidente, utilizando uma prioridade embutida. Isso pode ajudar a acelerar o processo de gestão de incidentes, porém, ainda é uma boa ideia que a equipe de service desk use a matriz para conferir a prioridade atribuída automaticamente, pois o impacto e a urgência podem ter sido informados incorretamente.
Alguns toolsets permitem que usuários específicos, como diretores de negócios e usuários importantes, sejam identificados como VIPs. Quando um incidente for recebido por um desses usuários, o toolset automaticamente aumentará a urgência e/ou o impacto utilizado na matriz de prioridade, possibilitando a alocação de prioridades mais altas que o usual para estes incidentes.
Os toolsets também possuem funcionalidades que podem definir o impacto do incidente com base em fatores como a criticidade de sistemas ou serviços específicos, horas do dia e grupos de usuários, questões usadas para determinar a prioridade do incidente. O toolset irá registrar esses fatores em relação ao incidente, que poderá ser usado para apoiar a prioridade derivada da matriz no caso de qualquer disputa posterior.
Também é recomendável desenvolver um procedimento de disputa para prioridades de incidentes. Enquanto uma matriz de prioridade irá simplificar a definição de prioridades de incidentes, a prioridade resultante ainda depende de informações reunidas a partir de usuários e sistemas de monitoramento, e as expectativas dos usuários podem variar. Portanto, haverá ocasiões em que a matriz de prioridade atribuirá ao incidente uma prioridade diferente daquela esperada pelo usuário. Quando isso ocorrer, o usuário poderá abrir uma disputa sobre a prioridade atribuída a partir da matriz, possibilitando que o service desk corrija a prioridade se a disputa for aceita.
Também deve ser possível modificar a prioridade de um incidente ao longo do seu ciclo de vida. Em muitos casos, o impacto total de um incidente ainda não é conhecido quando reportado por um único usuário. Pode ocorrer de um incidente ser considerado de baixa prioridade porque a matriz o atribuiu baixo impacto, e conforme mais usuários reportam sintomas iguais ou parecidos, a matriz atribuirá uma prioridade mais alta. Para este tipo de incidente, onde o impacto conhecido aumenta com o tempo, é importante continuar usando a matriz para definir a nova prioridade. Os service desks podem reagir à pressão dos usuários sem usar a matriz, causando inconsistências e incentivando comportamentos do usuário que não ajudam.
Um incidente grave é um incidente com um impacto extremamente adverso para o negócio. Isso pode ser a interrupção excessiva de serviços, ou risco de futuras interrupções por eventos como ataques de vírus. A prática padrão é ter uma variação separada do processo de gestão de incidentes para esses incidentes graves, que possa reconhecer a urgência necessária para resolver o incidente. Sua matriz de prioridade deve conseguir identificar com clareza quais incidentes são graves, com base no impacto e na urgência. Incidentes graves, por definição, têm a mais alta das prioridades. É importante verificar através do teste de cenário se a sua matriz de prioridade consegue identificar com clareza quais incidentes são graves e quais são somente de alta prioridade.
Quais prioridades são definidas como incidentes graves dependerá de quantas prioridades diferentes foram incluídas na sua matriz de prioridade. Se você possui apenas três prioridades, então os incidentes graves sempre serão P1. Porém, com apenas três níveis de prioridade, você corre o risco de acionar seu processo de incidentes graves com mais frequência. É bem melhor ter mais prioridades na matriz, deixando a P1 reservada para incidentes genuinamente graves que terão um impacto extremamente adverso para o negócio. Os diferentes níveis de Impacto e Urgência em sua matriz de prioridade devem ser cuidadosamente projetados para resultarem em P1 para todos os casos reais de incidentes graves. Isso requer uma análise cuidadosa dos seus serviços, incluindo a avaliação da verdadeira criticidade para o negócio e também a compreensão de como os usuários utilizam esses serviços.
Uma matriz de prioridade pode ser útil para avaliar a prioridade de problemas, assim como de incidentes. As considerações para problemas são as mesmas que para incidentes e os eixos primários da matriz de prioridade também podem ser Impacto e Urgência. As avaliações para cada uma dessas dimensões em uma matriz de priorização serão similares. Porém, as orientações e a prioridade resultante serão diferentes. O impacto na matriz de prioridade ainda pode ser baseado na proporção de usuários afetados pelo problema específico, para que a prioridade aumente à medida que mais usuários forem afetados. Contudo, a urgência na matriz de prioridade deve considerar mais do que apenas a criticidade do serviço afetado para a empresa. Outros fatores devem ser levados em consideração ao usar a matriz de prioridade, como a viabilidade da resolução do problema, o custo da resolução em relação ao benefício da mesma, e mais importante, a existência de soluções alternativas aceitáveis. Por exemplo, a matriz de prioridade pode atribuir baixa prioridade para um problema que está afetando todos os usuários, mas que possui uma solução alternativa aceitável mesmo se for um serviço de alta criticidade. Da mesma forma, a matriz de priorização pode determinar baixa prioridade para um problema que está afetando diversos usuários, mas cujo custo de resolução é consideravelmente maior que o benefício obtido ao resolver.
Essa pode ser uma área complexa de se modelar, por isso, a maioria das empresas que adota uma matriz de prioridade para problemas usa a matriz para oferecer um indicador inicial da prioridade do problema. Equipes de desenvolvimento têm capacidade limitada. Portanto, é provável que tenham mais problemas com a mesma prioridade acontecendo ao mesmo tempo do que conseguem lidar. A prioridade inicial derivada da matriz de prioridade é revisada em conjunto por representantes do usuário e a equipe de TI, levando em conta os outros fatores e os outros problemas, incluindo o tempo estimado para resolver cada problema.
Uma matriz de prioridade pode ser útil para a gestão de mudanças quando há mais mudanças do que o conselho de mudanças pode revisar em tempo hábil. Impacto e Urgência podem ser usados na matriz de prioridade da mesma forma que na gestão de incidentes ou de problemas. Porém, em uma matriz de prioridade para gestão de mudanças, o Impacto deve ser pensado de duas maneiras: o impacto adverso para a empresa se a mudança não for feita, e o impacto benéfico para a empresa em realizar essa mudança. Isso deverá refletir na matriz de priorização, pois haverá um mix de mudanças que resolvem as questões, mudanças que trazem melhorias, e mudanças que adicionam uma nova funcionalidade. A matriz de prioridade pode considerar a Urgência com base na criticidade, mas na gestão de mudanças, a avaliação deve ser baseada em quão essencial é a mudança para a empresa. Algumas mudanças devem ser realizadas para manter a competitividade na economia digital atual, outras para resolver incidentes de alto impacto. Avaliar a urgência a partir da matriz de prioridade neste caso ajuda a agendar a mudança, garantindo que as mudanças mais urgentes tenham prioridade na implementação.
Uma matriz de prioridade para mudanças também ajuda os revisores a ter mais compreensão geral da mudança, já que a matriz vai ilustrar o impacto e a urgência relativos. A matriz pode ajudar a evitar uma situação na qual o TI insiste em implementar com urgência uma mudança que possui valor limitado para o negócio.
A gestão de continuidade de serviços de TI é o processo que restaura um serviço após uma grande perda, geralmente chamada de "recuperação de desastres". Uma matriz de prioridade pode ser de grande utilidade para empresas com um grande número de sistemas. No caso de um desastre, é bem provável que não haverá recursos suficientes para recuperar todos os sistemas ao mesmo tempo. Decisões precisarão ser tomadas a respeito de qual sistema restaurar primeiro, e uma matriz de prioridade pode ajudar com isso. Idealmente, a matriz de prioridade deve ser projetada e testada antes do desastre. As dimensões da matriz de prioridade serão Impacto e Urgência, da mesma forma que as matrizes de prioridade usadas nos outros processos. O objetivo é utilizar a matriz de prioridades para priorizar a recuperação dos sistemas com base nos requisitos do negócio. Portanto, as definições de Impacto e Urgência na matriz de priorização precisam refletir isso. As definições dependerão totalmente de cada empresa. Por exemplo, para uma empresa que vende pela internet, todos os sistemas que possibilitam o serviço de vendas devem ser alocados com alta urgência na matriz de prioridade, por serem mais críticos para recuperar. O Impacto na matriz de prioridade pode ser baseado no número de usuários afetados, e combinado com a Urgência na matriz para definir uma prioridade apropriada à restauração do serviço.
Se usada corretamente, a matriz de prioridade é uma ferramenta útil e valiosa para cada processo de ITSM. O conceito de matriz de priorização ajudará a aumentar a consistência e a compreensão, reduzir a dependência de conhecimentos individuais, e desafiar as funções de ITSM a focar na priorização de tarefas com base no benefício para o negócio.
Sorry, our deep-dive didn’t help. Please try a different search term.