Diferenças entre o modelo de maturidade do COBIT 4.1 e do modelo de capacidade do COBIT 5

 O COBIT 4.1 e o COBIT 5 apresentam modelos bem distintos de avaliação de processos. Uma forma de ampliar o entendimento entre eles é comparando-os. Vamos fazer umas considerações sobre suas diferenças na teoria e na prática.

De acordo com a ISACA (2012, p. 43-44), as principais diferenças entre o modelo de maturidade do COBIT 4.1 e a avaliação de capacidade de processo do COBIT 5 são:

• A nomenclatura e o significado dos níveis de capacidade definidos para o COBIT 5, com base na ISO/IEC 15504, são diferentes dos níveis de maturidade dos processos do COBIT 4.1.
• No COBIT 5, baseado na ISO/IEC 15504, os níveis de capacidade são definidos por um conjunto de nove atributos de processo. Estes abrangem alguns fundamentos cobertos pelos atributos de maturidade e/ou pelos controles de processos do COBIT 4.1, mas somente até um certo ponto e de uma forma diferente.

Em relação aos atributos, a tabela apresenta um comparativo entre os atributos de maturidade do COBIT 4.1 e os atributos de processo do COBIT 5.

Comparação entre atributos de maturidade do COBIT 4.1 e atributos de processo do COBIT 5

Fonte: ISACA (2012, p. 47).

Na prática, com certeza há importantes reflexos relativos às mudanças nos modelos de avaliação de processo. Algumas delas, conforme a ISACA (2012, p. 45), são:

• As escalas de avaliação, embora apresentem seis níveis, tanto no COBIT 4.1 quanto no COBIT 5, são muito distintas em relação a escopo, foco e intenção.
• No modelo de maturidade do COBIT 4.1, um processo poderia atingir o nível 1 ou 2 sem completar plenamente todos os objetivos do processo; no nível de capacidade de processo do COBIT 5, isso resultaria em uma avaliação mais baixa, como nível 0 ou nível 1.
• No COBIT 5, não há mais um modelo de maturidade específico por processo no conteúdo do processo detalhado porque a abordagem da avaliação da capacidade de processo ISO/IEC 15504, no qual o método se baseia, além de não exigir isso, proíbe essa abordagem.
• Os atributos de maturidade do COBIT 4.1 e os atributos de capacidade de processo do COBIT 5 não são idênticos, conforme foi mostrado na tabela 2. Esses atributos sobrepõem-se ou podem ser mapeados até certo ponto. As organizações que utilizam a abordagem dos atributos do modelo de maturidade do COBIT 4.1 podem reutilizar os atuais dados da sua avaliação e reclassificá-los segundo as avaliações de atributos do COBIT 5.

O modelo de maturidade do COBIT 4.1 produziu um perfil de maturidade, com o objetivo de identificar em quais dimensões ou para quais atributos havia pontos fracos específicos que necessitavam de melhorias em uma organização. Esta abordagem foi utilizada quando havia um foco na melhoria sem necessariamente ter que se obter um número de maturidade para fins de relatório. No COBIT 5, o modelo de avaliação de processos trabalha em uma escala de medição para cada atributo de capacidade e fornece orientações sobre como aplicá-la. Assim, uma avaliação pode ser feita para cada um dos nove atributos de capacidade para cada processo escolhido pela organização.
Fonte: ISACA (2012, p. 45).

As escalas de maturidade do COBIT 4.1 e as escalas de capacidade do COBIT 5 podem ser consideradas para um mapeamento aproximado, conforme mostra o quadro.

Comparação entre níveis de maturidade do COBIT 4.1 e níveis de capacidade do COBIT 5

Nível do Modelo de Maturidade de COBIT 4.1	Capacidade de Processo com Base no ISO/IEC 15504	Contexto
5 Otimizado - Os processos foram refinados ao nível de boa prática, com base nos resultados de melhorias contínuas e modelagem da maturidade com outras organizações. TI é aplicada de forma integrada para automatizar o fluxo de trabalho, oferecendo ferramentas para melhoria de qualidade e da eficácia, fazendo com que a organização se adapte rapidamente.	Nível 5: Processo Otimizado - O processo previsível, nível 4, é continuamente melhorado de modo a atender os objetivos corporativos pertinentes, atuais ou previsots.	Visão da Organização Conhecimento Corporativo
4 Controlado e Mensurável - A administração monitora e mede a conformidade com os procedimentos e toma medidas quando parecer que os processos não estão funcionando efetivamente. Os processos estão em constante melhoria e resultam em boas práticas. Automação e ferramentas são utilizadas de maneira limitada ou fragmentada.	Nível 4: Processo Previsível - O processo Estabelecido, nível 3, opera agora com limites definidos, atingidos nos resultados do processo.
3 Processo Estabelecido - Os procedimentos foram padronizados, documentados e comunicados por meio de treinamento. Seguir esses processos é obrigatório no entanto, é impossível que os desvios sejam detectados. Os procedimentos por si só, não são sofisticados, mas são a formalização das práticas existentes.	Nível 3: Processo Estabelecido - O proceosso Gerenciado, nível 2, é agora implementado usando um processo definido capaz de atingir os resultados do processo.
	Nível 2: Processo Gerenciado - O processo Executado, nível 1, é agora implementado de forma gerenciada (planejado, monitorado e ajustado) e seus produtos do trabalho são adequadamente estabelecidos, controlados e mantidos.	Visão de Instância Conhecimento individual
2 Repetível, mas intuitivo - Os processos se desenvolveram até o estágio em que procedimentos semelhantes são adotados por diferentes pessoas que realizam o mesmo trabalho. Não há treinamento formal ou comunicação de procedimentos padrão e a responsabilidade fica a critério do indivíduo. Há um alto grau de confiança no conhecimento das pessoas e, portanto, erros são possíveis.	Nível 1: Processo Executado - O processo implementado atinge a finalidade do processo. Observação: É possível que alguns processos classificados como Modelo de Maturidade Nível 1 sejam classificados como nível 0 na ISO/IEC15504, se os resultados do processo não forem alcançados.
1 Inicial/Ad hoc - Há evidências de que a organização tenha reconhecido a existência de problemas que deveriam ser tratados. Contudo, não há processos padronizados; em vez disso, há abordagens ad hoc, que tendem a ser aplicadas individualmente ou com base em cada caso. A abordagem geral da gestão é desorganizada.
0 Inexistente - Completa falta de processos reconhecíveis. A organização nem sequer reconheceu que existe um problema a ser tratado.	Nível 0: Processo incompleto - O processo não foi implementado ou não cumpre sua finalidade

Fonte: ISACA (2012, p. 46).

Benefícios do modelo de capacidade de processo do COBIT 5 quando comparado com o modelo de maturidade do COBIT 4.1:

• Maior ênfase no processo que está sendo realizado para confirmar que está efetivamente alcançando seus objetivos e os resultados esperados.
• Simplificação do conteúdo por meio da eliminação da duplicação, porque a avaliação do modelo de maturidade do COBIT 4.1 exigia o uso de diversos componentes específicos, inclusive modelo de maturidade genérico, modelos de maturidades do processo, objetivos de controle e controles de processo, para apoiá-la.
• Maior confiabilidade e repetitividade das atividades e das análises da avaliação da capacidade do processo, reduzindo debates e desentendimentos entre as partes interessadas em relação aos resultados da avaliação.
• Maior uso dos resultados da avaliação da capacidade do processo, visto que o novo modelo estabelece uma base para a realização de avaliações mais rigorosas e formais, tanto para finalidades internas como externas em potencial.
• Conformidade com um padrão de avaliação de processo geralmente aceito e, portanto, um forte apoio à abordagem de avaliação do processo no mercado (ISACA, 2012, p. 47).

O modelo de capacidade do COBIT 5

O modelo de capacidade de processo do COBIT 5 tem como base o padrão de Avaliação de Processo – Engenharia de Software ISO/IEC 15504, que é reconhecido internacionalmente.

Esse modelo busca atingir os mesmos objetivos gerais de avaliação e apoio à melhoria do processo, proporcionando meios para medir o desempenho de qualquer um dos processos de governança (baseados em EDM) ou de gestão (baseados em PBRM), permitindo a identificação das áreas que precisam ser melhoradas.

De acordo com a ISACA (2012, p. 44), um processo pode atingir seis níveis de capacidade, incluindo uma designação de processo incompleto, caso suas práticas não atinjam o objetivo. Esses níveis são:

[0] Nível 0 - Processo incompleto: o processo não foi implementado ou não atingiu seu objetivo. Nesse nível, há pouca ou nenhuma evidência de qualquer atingimento sistemático do objetivo do processo.

[1] Nível 1 - Processo executado (um atributo): o processo implementado atinge seu objetivo.

[2] Nível 2 - Processo gerenciado (dois atributos): o processo realizado descrito no nível 1 agora é implementado de forma administrativa (planejado, monitorado e ajustado), e seus produtos do trabalho são adequadamente estabelecidos, controlados e mantidos.

[3] Nível 3 - Processo estabelecido (dois atributos): o processo controlado descrito no nível 2 agora é implementado utilizando um processo definido capaz de atingir seus resultados.

[4] Nível 4 - Processo previsível (dois atributos): o processo criado descrito no nível 3 opera agora dentro dos limites definidos para produzir seus resultados.

[5] Nível 5 - Processo otimizado (dois atributos): o processo previsível descrito no nível 4 é continuamente melhorado visando ao atingimento dos objetivos corporativos pertinentes, atuais ou previstos.

Modelo de capacidade de processo do COBIT 5
Fonte: ISACA (2012, p. 44).

No COBIT 5, cada nível de capacidade só pode ser atingido quando o nível anterior tiver sido plenamente alcançado.

Caro aluno, observe que há uma diferença significativa entre a capacidade de processo nível 1 e os níveis superiores, de 2 a 5. Para atingir a capacidade nível 1, é necessário que o atributo de desempenho do processo seja amplamente atingido: isso significa que ele está sendo realizado com sucesso e que os resultados esperados estão sendo obtidos pela organização. A partir disso, os níveis de capacidade mais altos adicionam diferentes atributos a ele. Nesse esquema de avaliação, atingir a capacidade nível 1, mesmo em uma escala de 5, já pode ser considerada uma conquista muito relevante para a organização!

A grande flexibilidade desse modelo reside no fato de que cada organização pode definir, com base em critérios próprios, como custo-benefício e viabilidade, sua meta ou seu nível desejado. Na realidade, muito raramente a organização almeja de imediato níveis de capacidade mais altos. A abordagem da capacidade de processo do COBIT 5 pode ser resumida conforme mostra o gráfico 17.

Vejamos um exemplo: uma capacidade de processo nível 3 (processo criado) exige que a definição do processo e os seus atributos de implantação sejam amplamente atingidos depois que a capacidade dos atributos de processo do nível 2 forem atingidos (processo controlado).

Modelo de maturidade do COBIT 4.1

O COBIT 4.1 lida com as três necessidades elencadas, pois oferece às organizações que buscam um modelo de governança de TI:

• um modelo de maturidade, que permite que comparações sejam feitas, de forma a identificar as capacidades que precisam ser aprimoradas;
• objetivos de desempenho e métricas para os processos de TI, que mostram como os processos podem atingir os objetivos de negócios e de TI e como são utilizados para medir o desempenho dos processos internos, com base no BSC;
• objetivos de atividades, que habilitam os processos a atingir seu desempenho efetivo.

Modelo de maturidade do COBIT 4.1
Fonte: ITGI (2007, p. 22).

De acordo com o ITGI (2007, p. 22), o modelo de maturidade para o gerenciamento e controle dos processos de TI do COBIT 4.1 é baseado em um método de avaliar a organização, permitindo que ela seja pontuada de um nível de maturidade não existente (0) a um otimizado (5). Esse enfoque é derivado do modelo de maturidade do CMMI/SEI, definido para a maturidade da capacidade de desenvolvimento de software. O gráfico 16 ilustra esse processo.

Embora siga os conceitos do CMMI/SEI, a implementação do COBIT 4.1 difere deste, pois uma definição genérica é provida para as escalas de maturidade, que são similares às do CMMI, mas interpretadas de acordo com a natureza dos processos de gerenciamento de TI. Além disso, não há intenção de se medir os níveis de maneira precisa ou tentar certificar que aquele nível foi exatamente atingido (ISACA, 2012, p. 19).

Os níveis de maturidade são designados como perfis de processos de TI que a empresa reconheceria como descrição de possíveis situações atuais e futuras. Eles não são designados como um modelo inicial, em que não se pode avançar para o próximo nível sem antes ter cumprido todas as condições do inferior (ISACA, 2012, p. 19).

Esse modelo foi desenvolvido com uma ênfase forte em controles. A vantagem de uma abordagem de modelo de maturidade é a relativa facilidade de os gerentes colocarem a si mesmos em uma escala e avaliar o que está envolvido no aprimoramento da performance, se necessário. A escala inclui o zero, pois é possível que um processo não exista de fato (ISACA, 2012, p. 20).

O modelo de maturidade é uma forma de medir quão bons os processos de gerenciamento são, ou seja, quão capazes eles são. O quanto eles devem ser desenvolvidos ou capacitados deveria primariamente depender dos objetivos de TI e sua conexão com as necessidades de negócios que suportam (ISACA, 2012, p. 21).

É importante ressaltar que os controles a ser aplicados a cada um dos processos devem considerar dois aspectos principais: o apetite de risco da organização e os requisitos de conformidade que sejam aplicáveis.

Cabe aqui uma breve explicação sobre apetite de risco que, de acordo com o site Stakeholder News (2014), é definido como

o apetite de risco é o grau de incerteza que a entidade está disposta a assumir, em antecipação de uma recompensa. O apetite de risco de uma organização mostra o quanto uma organização está disposta a assumir um risco, a fim de crescer. É a quantidade de risco que uma organização está disposta a aceitar para atingir seu objetivo de negócios.

Os níveis da escala do modelo de maturidade do COBIT 4.1 ajudarão os profissionais de TI a indicar aos gerentes onde se encontram as deficiências no gerenciamento do processo e a, juntos, definir as metas para onde devem ir. O nível de maturidade é influenciado pelos objetivos de negócios e pelo ambiente operacional da organização, além de pelas práticas do mercado (ITGI, 2007, p. 23).

Em resumo, o modelo de maturidade fornece um perfil genérico de estágios por meio dos quais cada empresa pode evoluir em gerenciamento e controle de processos de TI.

Modelo de capacidade de processo do COBIT

As organizações e sua necessidade de avaliação da área de TI

Toda organização precisa ter uma ampla compreensão da situação de seus recursos e sistemas de TI para ter condições de decidir qual nível de gerenciamento e controle precisa ser implementado. A alta direção e os executivos têm que saber quão bem a área de TI está sendo gerenciada. Para ajudá-los, o ITGI (2007, p. 21), elenca um conjunto de perguntas, dentre as quais se encontram:

• Quanto devemos investir? O custo justificará o benefício?
• O que deve ser feito para conhecermos o nível de desempenho em que a organização se encontra? O que deve ser avaliado e como avaliar?
• Como estão nossos principais concorrentes e como está nossa posição no mercado em relação a eles?
• Quais são as boas práticas que podem causar impacto positivo em nosso negócio e quão distante estamos delas?
• Como podemos identificar, elencar e planejar o que precisa ser feito para que nossa organização atinja um nível adequado de gerenciamento e controle nos processos de TI?

Conseguir respostas corretas e adequadas para essas perguntas não é tarefa fácil. Mas o uso de ferramentas de benchmarking e de autoavaliação pode auxiliar a organização, de forma determinante, a saber o que deve ser feito para que a governança de TI possa ser implementada de maneira eficiente.

Começando a implantação da governança com as boas práticas do COBIT, os processos devem ser selecionados. Para cada processo a ser implementado, seu proprietário poderá gradativamente ampliar as comparações com os objetivos de controle, de forma a atender a três necessidades essenciais:

1. Obter uma medida relativa de onde a organização se encontra.

2. Conseguir determinar caminhos eficientes que levem a organização a decidir para onde ir.

3. Obter uma ferramenta para avaliar o progresso da implementação em relação às metas a ser alcançadas.

Software x Hardware

De acordo com Pressman (2011, p. 32-33), comparar o software com produtos de hardware auxilia na compreensão das diferenças existentes entre eles e enfatiza as características inerentes a um software. O processo de desenvolvimento do software apresenta diferenças fundamentais em relação ao hardware:

Software x Hardware

Fonte: Moon Light PhotoStudio/shutterstock

• O processo criativo do hardware gera algo físico (por exemplo, placas de circuitos). O desenvolvimento de software resulta em um elemento pertencente a um sistema lógico, intangível;
• O software geralmente é desenvolvido sob medida, ao contrário do hardware, no qual o projetista tem acesso a componentes existentes que executam tarefas definidas. O projetista do software nem sempre terá acesso a módulos prontos para utilização e quando o faz, pode elevar o risco do produto devido a questões de segurança;
• Os custos do software estão concentrados no desenvolvimento e não no processo de manufatura, logo, não pode ser gerido como projeto de manufatura;
• Ao longo do tempo, o produto de software não se desgasta, mas se deteriora em função da introdução de erros oriundos de atividades de manutenção ou evoluções implícitas no processo que devem ser reconsideradas no modelo original.

Desta forma, o software sofre deterioração ocasionada por diversos fatores sendo uma característica peculiar do produto. Ainda segundo Pressman (2011), no caso do hardware, temos um alto índice de falhas no início do seu ciclo de vida ocasionado por defeitos de fabricação e projeto. Posteriormente os defeitos são corrigidos, dando estabilidade nas falhas ou mantendo-a em um nível muito baixo e suportável para a estrutura. Já no final do ciclo de vida do produto podem surgir problemas relacionados ao envelhecimento, acúmulo de poeira, vibração, abuso, temperaturas extremas, entre outros. Este processo pode ser visto no gráfico apresentado na figura.

Curva de falhas do hardware. Fonte: PRESSMAN (2011, p. 32)

Diferentemente da curva teórica de falhas do hardware, a de software leva em conta que o software não sofre processos de envelhecimento como o hardware, pois o software não é algo físico. No início do ciclo de vida do software, teremos problemas (bugs) que serão ajustados no decorrer do desenvolvimento e se estabilizarão, gerando uma tendência de achatamento da curva, conforme pode ser visto na figura.

Curva de falhas do software.

Fonte: PRESSMAN (2011, p. 33)

Notemos que esta é apenas uma teoria, já que a curva real do índice de falhas de um software considera o processo de manutenção e mudanças. Durante o processo de refinamento do produto ou mudanças a probabilidade de inserção de novos erros aumenta consideravelmente, gerando picos na curva de falhas. As sucessivas alterações do software tendem a introduzir mais erros antes da estabilização dos erros de alterações anteriores, ocasionando a tendência crescente do índice de falhas.

Isso nos remete a uma realidade bastante complicada em relação ao software: ele é um produto que quanto mais se conserta, pior fica. Um software em constante manutenção pode ser tornar uma espécie de “colcha de retalhos”, gerando pontos de falhas diversos, difíceis de se identificar e de se ajustar. O melhor modelo é o desenvolvimento de um novo produto após o tempo de vida útil do anterior, considerando-se as novas necessidades e tecnologias disponíveis.

Quando o hardware é projetado e construído, os componentes digitais são inseridos em catálogos. A cada circuito integrado ou componente é assinalado um código, uma função definida e validada, uma interface especificada e um conjunto padrão de integração. Uma vez escolhido no catálogo, o componente desejado pode ser adquirido e utilizado em diferentes projetos de hardware, com alta confiabilidade.

No mundo do software, isso é algo que está apenas começando a ser utilizado em uma escala mais ampla, apesar de existirem alguns casos antigos de reuso, como as bibliotecas de subrotinas científicas. Atualmente, a visão de reuso foi ampliada para abranger não apenas algoritmos consagrados, mas também estruturas de dados, interfaces gráficas e diferentes classes e componentes orientados a objetos.

Elaboração de um estudo de caso

A melhor forma de se iniciar o programa de implementação é pela criação de um estudo de caso, cuja iniciativa deve ser atribuída a um responsável, mas contar com a participação de todas as partes interessadas.

Isso pode ser feito em um alto nível do ponto de vista estratégico, considerando uma visão top-down (de cima para baixo). O estudo de caso poderá se iniciar com uma clara compreensão dos resultados organizacionais desejados e progredir até uma descrição detalhada de tarefas, metas e objetivos críticos, incluindo as funções e as responsabilidades envolvidas dentro da estrutura organizacional.

De acordo com a ISACA (2012, p. 40), o estudo de caso deve incluir:

• os benefícios almejados pela organização, seu alinhamento com a estratégia de negócios e os respectivos responsáveis, considerando os pontos fracos e os eventos desencadeadores que possam gerar risco;
• as mudanças nos negócios necessárias para criar o valor esperado, podendo considerar as verificações de integridade e as análises de falhas na capacidade e devendo indicar claramente o que está incluído no escopo e o que não está;
• os investimentos que são necessários para criar as mudanças na governança e na gestão de TI da organização;
• os custos fixos do negócio e de TI envolvidos em cada iniciativa;
• os benefícios esperados da operação após a mudança;
• os riscos inerentes a cada item elencado, considerando quaisquer restrições ou dependências;
• as funções, as competências e as responsabilidades relacionadas à iniciativa;
• a forma como o investimento e a criação de valor serão monitorados durante todo o ciclo de vida econômico e como os indicadores serão usados.

O estudo de caso não deve ser considerado um documento estático definitivo, mas uma ferramenta operacional dinâmica que deve ser continuamente atualizada para refletir a atual visão do futuro para que a viabilidade do programa possa ser mantida.

Haverá uma dificuldade evidente em quantificar os benefícios da implementação, por isso, cuidados devem ser tomados para que haja comprometimento apenas com benefícios realistas e atingíveis.

Ciclo de vida para a implementação do COBIT

O ciclo de vida da implementação apresenta uma forma de as organizações usarem o COBIT para tratar a complexidade e os desafios geralmente encontrados durante o processo. Esse ciclo é ilustrado no gráfico.

Ciclo de vida da implementação do COBIT 5
Fonte: ISACA (2012, p. 39).

Podemos destacar nesse gráfico três importantes componentes inter-relacionados:

[1] Ciclo de vida principal de melhoria contínua: refere-se ao anel interno, que é um processo crítico e mandatório.

[2] Capacitação da mudança: refere-se ao anel intermediário, envolvendo uma abordagem relativa aos aspectos comportamentais e culturais.

[3] Gestão do programa: refere-se ao anel externo, permeando todas as fases.

Para que a implementação seja bem-sucedida, é essencial que um ambiente adequado seja criado na organização. Além disso, deve existir um fluxo para atender o processo de melhoria contínua, formado por sete fases. Estas podem ser identificadas no gráfico e são assim definidas, de acordo com a ISACA (2012, pp. 39-40):

[1] Primeira fase: inicia-se com a identificação e a aceitação da necessidade da implementação da governança. Identifica as fragilidades atuais que atuam como catalisadores, criando um sentimento, na alta direção, de que é o momento certo para a mudança.

[2] Segunda fase: concentra-se na definição do escopo da implementação usando o mapeamento dos objetivos corporativos do COBIT em objetivos de TI e nos respectivos processos. Define-se um diagnóstico de alto nível com base em riscos para se identificar as áreas com alta prioridade.

[3] Terceira fase: devem ser definidos um processo e uma meta de referência para melhoria, seguindo uma análise mais detalhada, a fim de identificar falhas e possíveis soluções. Algumas soluções podem apresentar resultados rápidos, enquanto outras poderão exigir atividades mais desafiadoras em um prazo maior. Devem-se priorizar as iniciativas mais fáceis de alcançar e que provavelmente produzirão os melhores benefícios.

Fases de implementação
Fonte: Rawpixel.com/shutterstock

[4] Quarta fase: planejam-se ações práticas pela definição de programas e projetos apoiados por estudos de casos justificáveis e tangíveis, alinhadas a um plano de mudança para a implementação, que também deve ser desenvolvido nessa fase.

[5] Quinta fase: os planos de soluções propostos deverão ser implementados de maneira prática e gerenciável. As métricas e os indicadores podem ser definidos, e o monitoramento deve ser estabelecido com o uso das metas e indicadores do COBIT, para garantir que o alinhamento da organização seja atingido e mantido e, também, que o desempenho possa ser medido.

[6] Sexta fase: concentra-se na operação contínua e equilibrada dos habilitadores novos, no aperfeiçoamento e na melhoria dos existentes e no monitoramento do atingimento dos benefícios esperados.

[7] Sétima fase: o sucesso de todas as etapas é analisado, novos requisitos para a governança ou gestão de TI são identificados, e a necessidade de melhoria contínua é reforçada.

Com o tempo, o ciclo de vida é seguido de forma interativa paralelamente à criação de uma abordagem sustentável para a governança e a gestão de TI da organização.

Para garantir o sucesso desse fluxo de implementação, é necessário agir de forma amplamente alinhada e comunicada a toda a organização. Isso pode ser feito apresentando os pontos fracos que estejam gerando impactos ou mostrando a oportunidade de melhoria a ser alcançada com a definição de metas e objetivos. O nível adequado de urgência e importância deve ser exposto, e as prioridades devem ser indicadas e inseridas no contexto gerencial. As principais partes interessadas devem estar cientes dos riscos das tomadas de decisão e dos benefícios da realização do programa, devendo haver equilíbrio no apetite de riscos.