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.

Fatores críticos para a implementação do COBIT

Antes de descrevermos o modelo de implementação, devemos ter uma visão clara e, principalmente, estratégica do cenário organizacional. Devemos ter clareza de como a empresa está, como é a sua cultura, seus processos e seu apetite por riscos e se os controles estão dentro do contexto do modelo de gestão e governança.

A governança e a gestão corporativa de TI não ocorrem de forma isolada. Muitas empresas não possuem níveis adequados de gestão e alinhamento das funções de TI com as necessidades de negócio e atuam em um ambiente sem perspectiva holística.

De acordo com a ISACA (2012, p. 37), cada organização deve elaborar seu próprio plano ou roteiro de implantação, considerando fatores específicos do seu ambiente interno e do ambiente externo, como:

• como é o ambiente cultural e ético;
• quais leis, regulamentos e políticas estão dentro do contexto e são aplicáveis;
• qual a sua missão, visão e valores;
• quais políticas e práticas de governança são aderentes;
• quais são o plano de negócios e as intenções estratégicas;
• quais são seu modelo operacional e seu nível de maturidade;
• quais são seus estilos de gestão;
• qual seu apetite ao risco (risk appetite);
• quais são suas capacidades e recursos disponíveis;
• quais práticas da indústria são utilizadas e aplicáveis.

É importante que esteja clara a importância de haver uma abordagem de governança e gestão corporativa de TI, que se trata de um diferencial competitivo.

Fatores de implementação
Fonte: 3dmask/shutterstock

Os principais fatores para uma implementação bem-sucedida, na visão da ISACA (2012), são:

• Deve haver patrocínio e fornecimento, pela alta administração, da orientação e da ordem para a iniciativa, bem como compromisso e apoio visíveis e contínuos.
• Todas as partes devem apoiar os processos de governança e gestão a fim de que haja entendimento dos objetivos de TI e da organização.
• Deve haver garantia de comunicação efetiva e capacitação das mudanças necessárias.
• Deve ocorrer a monitoração da adaptação do COBIT e dos demais padrões e boas práticas de apoio, a fim de atender ao contexto único da organização.
• Deve haver foco em resultados rápidos e priorização das melhorias mais benéficas e que sejam mais fáceis de implementar.

É importante que a implementação dos processos utilizando o COBIT seja devidamente governada e adequadamente gerenciada. Para isso, deve haver uma estrutura organizacional bem estabelecida, com times devidamente treinados e alinhados ao contexto da estratégia e dos objetivos de negócio.

Sabemos que importantes iniciativas de TI podem ser levadas ao fracasso em função da falta de orientação, de suporte e de controle das pessoas e órgãos envolvidos. Implantar o COBIT é um tipo clássico de iniciativa que pode cair na mesma armadilha e falhar.

Apoio e orientação das principais partes interessadas são críticos para que as melhorias sejam adotadas e mantidas. Em um ambiente corporativo fraco (como um modelo operacional geral de negócios pouco claro ou falta de habilitadores de governança em nível corporativo) este apoio e participação são ainda mais importantes.
Fonte: ISACA (2012, p. 38).

Os habilitadores utilizados pelo COBIT devem fornecer uma solução que trate das necessidades e dos problemas reais da organização. Os requisitos baseados nos pontos fracos e nas tendências atuais devem ser identificados e aceitos pela administração como áreas a ser tratadas: alinhamento é a palavra chave.

É importante que a organização utilize instrumentos que levem à realização de verificações de integridade, levantamento de diagnósticos ou análises de capacidade para aumentar a sensibilização quanto à importância da adoção da governança, criando consenso e gerando um comprometimento entre as partes interessadas.

O compromisso e a adesão das partes envolvidas devem ser solicitados desde o início, bem como a definição das metas e dos objetivos de negócio. Para alcançar isso, os objetivos e os benefícios da implementação devem ser expressos usando linguagem e termos claros de negócio e resumidos em uma visão de objetivos de negócio.

Recursos adequados deverão ser fornecidos para apoiar o programa, e as funções e as responsabilidades deverão ser definidas e atribuídas, transformando o envolvimento das partes interessadas em um grande time estratégico. O comprometimento de todos os envolvidos, ao longo de todo o período de implantação do COBIT, é fator crítico de sucesso, e suas funções e responsabilidades devem ser monitoradas e geridas de forma transparente e clara dentro da organização.

As estruturas e os processos apropriados para supervisão e orientação deverão ser criados e mantidos de modo a garantir um alinhamento contínuo e frequente das abordagens de governança e gestão de risco em toda a organização.

Apoio e compromisso claro devem ser oferecidos pelas principais partes interessadas, incorporando a alta direção e os executivos, para definir uma alta sintonia e sinergia, de forma a garantir o compromisso com o programa em altos níveis de gestão e governança.

Outro fator crítico de sucesso é a implantação da mudança de forma adequada, considerando os habilitadores de governança ou gestão apropriados. Mas não se pode deixar de lado a gestão dos aspectos humanos, comportamentais e culturais da mudança, bem como a motivação das partes interessadas para aceitá-la. Esse é um aspecto de criação de divergências e pode gerar riscos para a implementação. Existe a possibilidade real de pessoas ignorarem ou mesmo resistirem às mudanças.

Por isso, deve haver um plano de comunicação eficiente que defina o que será comunicado, de que forma, para quem, ao longo das várias fases do programa. De preferência, isso deve ser feito de cima para baixo, por exemplo, da alta direção para os níveis hierárquicos mais baixos.

As barreiras humanas, comportamentais e culturais devem ser superadas de modo a promover um interesse comum em adotar corretamente a mudança, infundir a vontade e garantir a capacidade de fazer isso.