Especificação Formal de Protocolos de Segurança

1.INTRODUÇÂO

No presente artigo iremos falar sobre Especificação Formal de Protocolos de Segurança, que visa através da utilização de métodos formais, os quais são um conjunto de técnicas suportadas pela lógica matemática.

A importância do estudo do tema se dá por causa dos serviços realizados pela Internet como compras on-line (e-commerce), transações bancárias, ou mesmo no cotidiano dos brasileiros como a utilização de cartões como MIFARE (PHILIPS, 2010) utilizado em aplicações de sistema de bilhetagem eletrônica como o sistema BOM (Bilhete de Ônibus Metropolitano), cartões de ponto, cartões de crédito, supermercado, estacionamento e outras aplicações, necessitam de um protocolo confiável de comunicação para trafegar os dados com o máximo de segurança. Essas tecnologias facilitam a vida dos seus operadores.

Em contrapartida há um aumento no número de crimes relacionados às telecomunicações intitulados por alguns autores como crimes modernos (ZANIOLO,2007). Por isso, empresas, áreas governamentais, acadêmicas e militares sentem-se vulneráveis quando a segurança das informações é ignorada. Nas redes de comunicação as mensagens são trocadas entre as entidades e como o ambiente móvel é mais suscetível a ataques, já que usam o ar como meio de transmissão, qualquer um com um receptor apropriado pode interceptar as mensagens sem ser detectado. Expondo informações importantes, como senhas e documentos, a não ser que estejam protegidas de alguma forma.

Para garantir a segurança das informações foram desenvolvidos vários protocolos que utilizam técnicas de criptografia para a implementação de serviços de segurança tais como sigilo do conteúdo das mensagens e da identidade do usuário/entidade, autenticação dos participantes na comunicação, integridade dos dados e não-repúdio (SCHNEIER, 1996).

Porém, se o protocolo criptográfico não for projetado corretamente proporcionará a um intruso a oportunidade de ataque por meio dos seguintes processos: substituição, exclusão, alteração ou criação de mensagens, ou pelo ataque aos algoritmos criptográficos utilizados. Por isso, vários métodos formais têm sido propostos a fim de analisar e projetar protocolos criptográficos.

O principal objetivo deste artigo é mostrar para a área acadêmica e comercial a importância do emprego de métodos formais no desenvolvimento de protocolos criptográficos.

O artigo está dividido da seguinte forma: a seção 2 apresenta os Riscos de Senha; na seção 3 são mencionados os tipos de métodos formais encontrados na literatura; na seção 4 é realizada a análise formal de três protocolos de autenticação do ambiente celular (GSM, CDPD e UMTS). E, finalmente, na seção 5 são feitas as considerações finais.

2. RISCO DA SENHA


As senhas são ainda a base sobre os quais muitos sistemas da informação atribuem sua segurança, porque é o principal mecanismo usado para autenticar usuários humanos aos sistemas informáticos. Na forma de PINs, eles também são usados em muitos sistemas embarcados, a partir de máquinas de dinheiro através de sistemas móveis. Eles levantam muitos problemas, tais como a dificuldade das pessoas têm em escolher senhas difíceis de adivinhar, ou lembrar senhas geradas aleatoriamente pelo sistema.

Segundo (Anderson,2001) considera as limitações dos sistemas embarcados que utilizam senhas. A típica aplicação é o controle remoto usado para abrir a garagem ou para desbloquear as portas dos automóveis fabricados até meados da década de 1990. Esses controles remotos primitivos apenas transmitem seu número de série de 16 bits, que também atua como senha.

Um ataque que se tornou comum era usar um grabber "um dispositivo que gravaria um código e jogá-lo novamente mais tarde”. Esses dispositivos, chegou por volta de 1995 em Taiwan, que permitiam ladrões que espreitavam em um estacionamentos para gravar o sinal usado para bloquear uma porta do carro e, em seguida, jogá-lo novamente para desbloquear o carro uma vez que o proprietário havia deixado.

Uma solução na época foi usar códigos separados para bloquear e desbloquear. Mas isso ainda não era o ideal. Primeiro, o ladrão podia esperar fora do estabelecimento de sua casa e gravar o código de desbloqueio. Em segundo lugar, senhas de 16 bits são muito pequenas e fáceis de serem descobertas por grabber. Em meados da década de 1990, surgiram dispositivos que podiam tentar todos os códigos possíveis, um após o outro. Este código poderia ser descoberto, em média, cerca de 215 países, que em 10 combinações, levaria menos de uma hora para serem descobertos.

Um ladrão que atua em um estacionamento com uma centena de veículos, poderá ser recompensado em menos de um minuto com um carro piscando suas luzes.

3. UTILIZANDO UM CANAL SEGURO

Supondo que para transmissão de uma senha seja transmitida em um canal de comunicação seguro. Para canais inseguros e necessários o compartilhamento de chaves.

Vamos estudar pelo caso proposto: Supondo que em um ônibus utiliza-se um sistema de bilhetagem eletrônico através de cartões, onde cada passageiro possua um cartão que irradia para um leitor o número da identificação e a identificação criptografada. O leitor e o cartão possuem chaves em comum. Em notação de protocolos temos:


C -> L: C {C}kcs

onde:

C -> É o cartão
L -> É o leitor

{C}kcs -> chave que sifra o código do cartão. Essa chave é comum para C e L (cartão e Leitora)

O caso em tela tem alguns problemas pois o intruso pode capturar a irradiação da transação e simplesmente repetir essa irradiação. Uma forma para previnir esse tipo de ataque é introduzir um nonce (number used once – Numero usado uma só vez). Neste caso a notação de protocolos fica:

C ->L : C, {C,N}kcs


Onde N pode ser um número aleatório ou seqüencial.

No caso apresentado manda C, manda C e N. O número N tem que ser conhecido por C e S, de tal forma se alguém tentar repetir ele não tem o nunce. É o que o token de banco faz, o nunce e um número aleatório gerado por C e N. L tem que guardar um histórico de nunce. Isso pode ser problemático pois no caso de um erro de comunicação um lado incrementa e outro não ira perder a referencia.

Desafio e Resposta (Challenge – response) Neste caso o NONCE e gerado aleatoriamente pelo servidor e nenhum dos dois atores precisam armazenar estados.


L -> C:N

C ->L: C {C,N}kCs


Onde:

L : leitora

C: Cartão N: numero do Nonce

KCS -> chave de sifra.

Supondo que o cartão passa pelo leitor e recebe um nonce que vai ler L. L recebe C,N cifrado com kCs. Supondo que o desafio seja a função x+1, ou seja se o cartão manda o numero 5 o leitor retorna o número 6 então ele respondeu ao desafio, junto com a chave C, S.
ATAQUE MAN-IN-THE-MIDDLE


Este ataque consiste em um ataque que via um nonce do servidor para o cartão de outro passageiro e retransmite a resposta deste cartão para o servidor.




1. S-> M: N
2. M ->C: N
3. C-> M: C,{C,N}KCS
4. M -> S: C, ,{C,N}KCS


Dado os protocolo acima iremos explicar passo a passo:

1. Um dispositivo criado M ( dispositivo do invasor ) capta o nunce gerado do servidor

2. Passa o nunce gerado para um outro cartão.

3. O cartão responde para o dispositivo do invasor a chave do cartão , o nunce sifrado com a chave KCS.

4. M envia os dados capturados no passo 3 e envia para o servidor.


4. MÉTODOS FORMAIS

Os protocolos estão sujeitos a ocorrência de erros em qualquer fase de seu projeto (especificação, construção e verificação). Por isso não é incomum que sejam descobertas falhas em protocolos publicados e utilizados por vários anos. Como exemplo, protocolo de (NEEDHAM e SCHROEDER, 1978) foi utilizado durante 4 anos até que (DENNING e SACCO, 1981) demonstraram que ele estava sujeito ao ataque do homem no meio e propuseram um protocolo alternativo. Porém, em 1994 Abadi e Needham demonstraram que este protocolo também possuía falhas (BUTTYÁN, 1999).


O emprego de métodos formais na área de criptografia é recente. Grande parte dos trabalhos nesta área são desenvolvidos na década de 90 (MEADOWS, 1995). Estes métodos permitem fazer uma análise completa do protocolo criptográfico e sua função principal é especificar se os objetivos propostos pelos autores são alcançados. Muitas vezes um protocolo é construído para realizar a distribuição segura de uma chave de sessão e quando analisado verifica-se que essa meta não é atingida.


Existem 4 abordagens diferentes para a análise de protocolos criptográficos (RUBIN e HONEYMAN,1993), (MEADOWS, 2000) e (GRITZALIS, SPINELLIS e GEORGIADIS, 1999). A primeira é a menos popular enquanto que a terceira é a mais utilizada:

1. uso de linguagens de especificação e ferramentas de verificação: o objetivo principal desta abordagem é tratar um protocolo criptográfico como qualquer
programa e tentar provar sua corretude. O principal problema é que estes métodos não são específicos para a análise de protocolos de segurança. Dentre os métodos podem ser destacados: LOTOS (Language of Temporal Ordering Specification) e Ina Jo.(VARADHARAJAN, 1990) utilizou LOTOS para analisar alguns protocolos criptográficos, porém não conseguiu demonstrar qualquer resultado. O autor concluiu que essa ferramenta não era adequada para a análise de segurança.


2. uso de sistemas especialistas: nestes métodos a maioria dos protocolos são modelados como máquinas de estado. São exemplos: Interrogator e NRL Protocol Analyzer. Neles o projetista especifica um estado inseguro e através de pesquisas exaustivas, tenta construir um caminho para este estado. Eles obtiveram mais êxito do que os anteriores, porém, possuem como desvantagem a grande quantidade de possíveis eventos que devem ser examinados;

3. uso de modelos baseados em lógicas modais: estas abordagens analisam os conceitos de crença e de conhecimento dos participantes do protocolo criptográfico. São utilizados principalmente para os protocolos de autenticação e de distribuição de chaves. Dentre eles pode-se destacar: as lógicas BAN e GNY. Apesar de serem mais simples e intuitivas do que as outras abordagens, são eficazes. O artigo da lógica BAN encontrou vários erros e redundâncias em protocolos bastante utilizados. Porém, o analista deve ter cuidado, pois suposições incorretas podem conduzir a erros na análise;


4. uso de sistemas algébricos: nesta abordagem o protocolo criptográfico é modelado como um sistema algébrico, associando um estado como se fosse o conhecimento do participante. São complementares aos métodos de lógica modal, pois também realizam uma formalização de problemas por hipóteses e nas propriedades de autenticação. O primeiro trabalho nesta área é o de Dolev-Yao e os outros trabalhos desenvolvidos são versões estendidas desse modelo. O problema desses sistemas é que são restritos para a análise da maioria dos protocolos. Só podem ser utilizados para descobrir fraquezas de segredos e não permitem que os participantes se lembrem de informações de um estado para o próximo.

O custo-benefício em utilizar uma dessas abordagens, antes de publicar o protocolo, é melhor do que ter que fazer alterações posteriores, já que é mais barato usar os métodos no desenvolvimento do protocolo do que fazer o seu replanejamento.

4.1. LÓGICA BAN


A lógica BAN foi desenvolvida por Burrows, Abadi e Needham (por isso o nome) em 1989. É a primeira lógica a analisar formalmente os protocolos criptográficos, principalmente os de autenticação e distribuição de chaves (BURROWS, ABADI e NEEDHAM, 1990). É a lógica mais popular na literatura para a análise de crenças e de conhecimento entre os participantes dos protocolos criptográficos. Apesar das críticas recebidas ela encontrou erros em
vários protocolos, como o de Needham-Schroeder, CCITT X.509, Yahalom e Kerberos. A lógica BAN também é utilizada como validação dos protocolos propostos em (AZIZ e DIFFIE, 1994) que desenvolveram um protocolo de autenticação para o ambiente celular e em (MYRVANG, 2000) que desenvolveu um protocolo de autenticação para redes locais sem fio.

Outras lógicas começaram a ser desenvolvidas estendendo ou aplicando os mesmos conceitos da lógica BAN. A de maior sucesso entre elas é a GNY (GONG, NEEDHAM e YAHALOM, 1990).

A lógica GNY introduziu novos conceitos, como reconhecimento e posse de fórmulas e a expressão “não originada-aqui” que permite aos participantes detectar mensagens que foram enviadas em sessões anteriores.Porém, a lógica GNY é mais complexa, possui muitas regras (mais de 50) que devem ser aplicadas em cada fase do protocolo e mais difícil de ser utilizada. Alguns autores consideram-na impraticável A complexidade é o maior problema das lógicas estendidas da BAN.

Na dissertação de mestrado (SANTOS, 2002) foi realizada uma comparação entre as duas lógicas, chegando-se à conclusão que a lógica GNY, por conter muitas regras, pode tornar a análise mais suscetível a erros e redundâncias. A lógica BAN também consegue chegar nos mesmos resultados finais, além disso, ela é mais simples e mais fácil de aplicar e de empregar seus postulados. Por estes motivos, a autora decidiu utilizar a lógica BAN, para analisar três importantes protocolos de autenticação da rede celular: GSM (Global System for Mobile Communications), CDPD (Cellular Digital Packet Data) e UMTS (Universal Mobile Telecommunications System). Como a lógica BAN possui muitos símbolos, a autora utilizou uma versão mais intuitiva que será mantida neste trabalho. Por exemplo, a expressão: P Q #(X) é substituida por P acredita Q disse novo(X) (lê-se: P acredita que Q, há algum tempo, disse que X é nova).

As principais expressões da lógica BAN são:


1. P acredita X: o participante P acredita na fórmula X ou está autorizado a acreditar em X, isso significa que P pode agir como se X fosse verdadeira;
2. P recebeu X: P recebeu uma mensagem contendo X e P pode obter X da mensagem (normalmente depois de algum deciframento);
3. P disse X: P uma vez disse X. O participante P, há algum tempo, enviou uma mensagem contendo a fórmula X;
4. P controla X: P tem jurisdição sobre X. O participante P é uma autoridade sobre X e deve ser confiado deste modo;
5. novo(X): (lê-se “X é nova”) a fórmula X é nova, ou seja, a fórmula X foi usada numa mensagem anterior à execução atual do protocolo. Os identificadores são gerados com a finalidade de serem novos;
6. P k Q: (lê-se “k é uma chave satisfatória para P e Q”). A chave k nunca será descoberta por qualquer participante, exceto por P, Q ou por alguém em quem eles confiam;
7. {X}K : fórmula X cifrada com a chave K. As mensagens cifradas somente são legíveis e verificáveis pelo possuidor da chave.
A notação abaixo é usada numa troca de mensagem:

Mi A -> B: {X}k

onde i é a iésima mensagem do protocolo: A envia X cifrada com a chave k para B. Em todas estas expressões, X é uma mensagem ou uma fórmula.


5. Considerações Finais

Este trabalho mostrou que é importante a especificação de protocolos e a utilização de métodos formais e qual a importância de um canal seguro e do risco de senhas que podem ser descoberto através de dispositivos eletrônicos construídos para este fim.
A especificação formal de protocolos de segurança propiciam um canal seguro para a comunicação de informações utilizando os métodos formais, porém esta especificação deve ser testada exaustivamente para detecção de falhas antes de serem implementadas.
Este trabalho fez um levantamento na literatura o qual podemos constatar a importância de uma especificação de protocolo, pois várias aplicações poderão utilizar garantindo a privacidade dos dados.

6. Referências Bibliográficas

ANDERSON, 2001 ANDERSON, R. “Security Engineering: A Guide to Building Dependable Distributed Systems”. Wiley, 2001.

AZIZ e DIFFIE, 1994 AZIZ, Ashar e DIFFIE, Whitfield. Privacy and
Authentication for Wireless Local Area Networks.

IEEE Personal Communications. pp. 25-31.1994.
BUTTYAN, 1999 BUTTYÁN, Levente. Formal methods in the design of cryptographic Protocols. http://citeseer.nj.nec.com/context/1960161/0. Technical, Report SSC/. Novembro 1999.
.
DENNING e SACCO, 1981 DENNING, Dorothy E. e SACCO, Giovanni Maria.
Timestamps in Key Distribution Protocols. Communications of the ACM, vol. 24, no 8 pp. 533-536.Agosto 1981.

GRITZALIS, SPINELLIS e GEORGIADIS, 1999 GRITZALIS, S., SPINELLIS, D. e GEORGIADIS, P.
Security protocols over open networks and distributed systems: formal methods for their analysis, design and verification. Computer Communications, vol. 22, no 8, pp. 697-709. Maio 1999.

MAIFARE,2010 http://www.a3m.eu/pt/Cartoes-contactless-Mifare.html, Acessado em Março de 2010

MEADOWS, 1995 MEADOWS, Catherine. Formal verification of
cryptographic protocols: A survey. ASIACRYPT’94 ,
133-150, http://citeseer.nj.nec.com/134868.html. 1995.

MEADOWS, 2000 MEADOWS, Catherine. Open Issues in Formal Methods
for Cryptographic Protocol Analysis. DISCEX 2000:,
v. 1, p. 237-250. IEEE Computer Society Press. Janeiro
2000.

MYRVANG,2000 MYRVANG, Per Harald. An Infrastructure for
Authentication, Authorization and Delegation. 2000.
Tese, Universidade de TromsÆ, Faculdade de Ciência,
www.cs.uit.no/studier/gradseksamen/myrvang.html

NEEDHAM e SCHROEDER, 1978 NEEDHAM, R. M. e SCHROEDER, M. D. Using
Encryption for Authentication in Large Networks of
Computers. Communications of the ACM, 21 p 12.

RUBIN e HONEYMAN,1993 RUBIN, Aviel D. e HONEYMAN, Peter. Formal Methods for the Analysis of Authentication Protocols. Technical Report CITI TR 93-7. Outubro 1993. www.citi.umich.edu/u/honey/papers.html

SANTOS,2002 SANTOS, Myrna C. M dos. Análise Formal de Protocolos de Autenticação para Redes Celulares. Dissertação de Mestrado. Instituto Militar de Engenharia, 2002.

SCHNEIDER,1996 SCHNEIER, Bruce. Applied Cryptography – Protocols,
Algorithms and Source Code in C – 2 a Edição. John Wiley & Sons, Inc. 1996. ISBN 0-471-12845-7.

VARADHARAJAN, 1990 VARADHARAJAN, V. Use a formal description technique in the specification of authentication protocols. Computer Standards and Interfaces, vol. 9,
pp. 203-215. 1990

ZANIOLO,2007 Zaniolo, Pedro Augusto, Crimes Modernos o Impacto da Tecnologia no Direito, Jurua Editora, 2007

Organização com CMMI nível 2

1. CMMI Nível 2

No nível de maturidade 2, uma organização atingiu todas as metas específicas e genéricas das áreas de processos do nível 2 de maturidade. Em outras palavras, os projetos da organização
asseguraram que os requisitos são gerenciados e que os processos são planejados, executados, medidos e controlados.
A disciplina dos processos refletida pelo nível 2 de maturidade ajuda a assegurar que as práticas existentes são mantidas em momentos de stress. Quando estas práticas existem, os projetos são executados e gerenciados de acordo com seus planos documentados.
No nível 2 de maturidade, os requisitos, processos, produtos de trabalho e serviços são gerenciados. A situação dos produtos de trabalho e a entrega dos serviços são visíveis para o gerenciamento em pontos definidos (por exemplo, nos milestones principais e no momento em que as principais tarefas são completadas).
Compromissos são estabelecidos entre os stakeholders relevantes e são revistos conforme necessário. Os produtos de trabalho são revisados com os stakeholders e controlados. Os produtos de trabalho e serviços satisfazem seus requisitos, padrões e objetivos definidos

• As políticas e procedimentos para GERENCIAR o desenvolvimento do software estão definidas e são obedecidas.
• O planejamento de novos projetos é baseado na experiência anterior em projetos semelhantes, de maneira formalizada e não intuitiva.
• Os projetos usam processos que são definidos, documentados, usados, disseminados, medidos, fiscalizados e com rotinas de melhoria
• Os compromissos são assumidos com bases realistas na experiência acumulada e nos requisitos documentados
  
• O desenvolvimento é acompanhado e os planos são revisados de maneira regular quanto aos prazos, custos, estimativas e funcionalidade
• Existem mecanismos formais para a correção de desvios
• A gestão de requisitos formalizada permite um controle do relacionamento com o cliente e
  assegura que o desenvolvimento está obedecendo às suas expectativas
• O relacionamento com eventuais fornecedores subcontratados é controlado e gerenciado
  formalmente
• Toda a definição e estabelecimento dos processos, no nível 2, é feita por projeto, não há necessidade de padronização na organização
• Existe uma clara visibilidade e controle de todos os aspectos GERENCIAIS do desenvolvimento em toda a cadeia gerencial
• Os processos podem ser repetidos com resultados previsíveis
  
• Os processos afetados são puramente gerenciais (não técnicos) e pertencem aos projetos, e não às pessoas

2. Papéis e responsabilidades para os diferentes processos.

A seção seguinte contém todas as áreas de processos que pertencem ao nível de maturidade 2. As áreas de processos do nível de maturidade 2 do CMMI são:

• Gerenciamento de Requisitos (Requirements Management) -REQM
  
• Planejamento do Projeto (Project Planning) - PP
  
• Monitoramento e Controle do Projeto (Project Monitoring and Control) - PMC
  
• Gerenciamento de Acordos com Fornecedores (Supplier Agreement Management) - SAM
  
• Medições e Análises (Measurement and Analysis) - MA
  
• Garantia da Qualidade do Processo e do Produto (Process and Product Quality Assurance) -PPQA
  
• Gerenciamento de Configurações (Configuration Management) - CM
  

Abaixo estão relacionado os processos exigidos no CMMI Nível 2 para cada profissional da organização da área de TI e suas responsabilidades.

Figura 1: Profissionais de TI relacionado

Engenheiro de Processos: O papel engenheiro de processo é responsável pelo processo de desenvolvimento de software. Isso inclui configurar o processo antes da inicialização do projeto e aprimorar o processo regularmente durante o esforço de desenvolvimento. Uma pessoa que atua como engenheiro de processo deve ter vasto conhecimento do desenvolvimento de software. É fundamental que uma pessoa que desempenha este papel tenha boas habilidades de comunicação.

Figura 2 - Artefatos gerados pelo Engenheiro de Processos

Principais Artefatos a Serem Produzidos.

• Avaliação da Organização de Desenvolvimento: A Avaliação da Organização de Desenvolvimento descreve o status atual da empresa de software em termos de atuais processos, ferramentas, competências e atitudes das pessoas, clientes, concorrentes, tendências técnicas, problemas e áreas de melhoria.
• Caso de desenvolvimento:O Caso de Desenvolvimento descreve o processo de desenvolvimento escolhido para ser seguido no projeto.
• Templates Especificos de Projeto: São os templates para relatórios e artefatos de documento usados no projeto. Podem existir também templates para modelos e elementos de modelagem, como o modelo de design.

Gerente de Projeto: O papel gerente de projeto aloca recursos, ajusta as prioridades, coordena interações com clientes e usuários e geralmente mantém a equipe do projeto concentrada na meta certa. O gerente de projeto também estabelece um conjunto de práticas que garantem a integridade e a qualidade dos artefatos do projeto.

As habilidades e a experiência necessárias para desempenhar o papel Gerente de Projeto dependem do tamanho e da complexidade técnica e de gerenciamento do projeto, porém, em graus variados. Para desempenhar o papel Gerente de Projeto conforme definido pelo Rational Unified Process (RUP), você deve:

• ter experiência no domínio do aplicativo e no desenvolvimento de software
• ter habilidades de análise e gerenciamento de riscos, estimativa, planejamento e análise de decisões
• ter habilidades de apresentação, comunicação e negociação
• mostrar capacidade de liderança e de desenvolver o espírito de equipe
• ter boa capacidade de gerenciamento de tempo e triagem e um histórico de decisões acertadas tomadas rapidamente em situações de stress
• ter boas habilidades de relacionamento interpessoal e mostrar opinião sensata na seleção de pessoal
• ser objetivo na definição e avaliação do trabalho, assegurando a participação de toda a equipe
• compartilhar a visão de arquitetura, mas ser pragmático no escopo e na implementação de planos e completamente honesto na avaliação dos resultados
• ter como objetivo agregar valor ao cliente na forma de software que atenda (ou ultrapasse) às expectativas do cliente.

Figura 3 - Artefatos gerados pelo Gerente de Projeto

Principais artefatos a serem produzidos.

• Avaliação de Interação: captura o resultado de uma iteração, até que ponto os critérios de avaliação foram respeitados, as lições aprendidas e as mudanças que devem ser feitas.
• Plano de Interação: Um conjunto de atividades e tarefas divididas por seqüências de tempo, com recursos atribuídos e dependências de tarefas, para a iteração; um plano sofisticado.
• Caso de Negócio: fornece as informações necessárias do ponto de vista de um negócio, para determinar se vale ou não a pena investir no projeto.Para um produto de software comercial, o Caso de Negócio deve incluir um conjunto de suposições sobre o projeto e a ordem de importância do retorno do investimento (ROI) se essas suposições forem verdadeiras. Por exemplo, o retorno do investimento terá importância cinco, se concluído em um ano, dois, se concluído em dois anos, e um número negativo, após esse tempo. Essas suposições são verificadas novamente no fim da fase de Elaboração, quando o escopo e o plano estiverem definidos com mais exatidão.
• Plano de Garantia de Qualidade é um artefato que oferece uma visão clara de como a qualidade do produto, do artefato e do processo será garantida. Ele contém o Plano de Revisão e Auditoria e faz referência a uma série de outros artefatos desenvolvidos durante a fase de Iniciação. Ele é mantido no decorrer do projeto.
• Plano de Desenvolvimento de Software é um artefato composto e abrangente que reúne todas as informações necessárias ao gerenciamento do projeto. Ele inclui vários artefatos separados, desenvolvidos durante a Fase de Iniciação, e é mantido durante todo o projeto.
• Avaliação de Status: Um dos objetivos do processo é assegurar que as expectativas de todas as partes estejam sincronizadas e consistentes. A Avaliação de Status periódica fornece um mecanismo que permite gerenciar as expectativas de cada pessoa durante o ciclo de vida do projeto.
• Ordem de trabalho: é o meio pelo qual o Gerente de Projeto comunica à equipe responsável o que deve ser feito e quando. A ordem passa a ser um contrato interno entre o Gerente de Projeto e aqueles que têm a responsabilidade de cumpri-lo.
  

Principais Repositórios de dados e documentos a serem utilizados pelo projeto

• Métricas de Projeto: O artefato de métricas de projeto é o repositório ativo de dados de métricas do projeto. Ele contém as métricas mais atuais de produto, processo, recursos e projeto no nível primitivo e derivado

Gerente de Controle de Mudanças: O papel gerente de controle de mudança supervisiona o processo de controle de mudanças. Normalmente, este papel é desempenhado por um Comitê de Controle de Configuração (ou Mudança) (CCB), formado por representantes de todas as partes interessadas, incluindo clientes, desenvolvedores e usuários. Em projetos pequenos, um único membro da equipe, como o gerente de projeto ou o arquiteto de software, pode desempenhar esse papel.

Figura 4: Artefatos produzidos pelo gerente de controle de mudanças

Principais artefatos a serem produzidos

• Solicitação de Mudanças: As mudanças nos artefatos de desenvolvimento são propostas através de Solicitações de Mudança (CRs). As Solicitações de Mudança são usadas para documentar e controlar defeitos, solicitações de melhorias e qualquer outro tipo de solicitação de mudança no produto. A vantagem das CRs é que elas fornecem um registro das decisões e, devido a seu processo de avaliação, garantem que os impactos das mudanças sejam entendidos no projeto.

Gerente de Configuração: Disponibiliza o ambiente e a infra-estrutura geral de Gerenciamento de Configuração (CM) para a equipe de desenvolvimento do produto. A função de CM oferece suporte à atividade de desenvolvimento de produtos para que os desenvolvedores e integradores tenham espaços de trabalho adequados para criar e testar seus trabalhos e, dessa forma, permite que todos os artefatos fiquem disponíveis para inclusão na unidade de implantação, conforme necessário. O gerente de configuração também deve assegurar que o ambiente de CM facilite a revisão do produto e as atividades de controle de mudanças e defeitos. O gerente de configuração também é responsável por redigir o Plano CM e relatar estatísticas de andamento com base nas solicitações de mudança.

Figura 5 - Artefatos e repósitorios de responsabilidade do Gerente de Configuração

• Plano CM: O Plano de Gerenciamento de Configuração (CM) descreve todas as atividades do Gerenciamento de Controle de Configuração e Mudança (CCM) que serão executadas durante o ciclo de vida do produto ou do projeto. Ele detalha o cronograma de atividades, as responsabilidades atribuídas e os recursos necessários, como equipes, ferramentas e computadores.
• Registro de Auditoria de Configuração: identifica uma baseline, qualquer artefato necessário ausente e requisitos reprovados ou testados de forma incompleta.

Principais Repositórios de dados e documentos a serem utilizados pelo projeto

• Repositório de Projeto:Local que fica armazenado todas as mudanças de configuração do projeto

Revisor do Projeto: O papel revisor do projeto é responsável por avaliar os artefatos de planejamento e de avaliação do projeto nos principais pontos de revisão do ciclo de vida do projeto. Esses eventos de revisão são importantes porque marcam pontos nos quais o projeto pode ser cancelado se o planejamento for inadequado ou se o andamento se mostrar intoleravelmente improdutivo.

Figura 6 - Artefatos produzidos pelo revisor de projetos

Principais artefatos a serem produzidos

• Registro de revisão: é criado para capturar os resultados da revisão de um artefato de projeto.

Gerente de Teste: tem a responsabilidade geral pelo êxito do esforço de teste. O papel envolve defesa da qualidade e dos testes, planejamento e gerenciamento de recursos e resolução de problemas que representam um obstáculo para o esforço de teste. Isso inclui:

• Negociar a finalidade e os produtos liberados do esforço de teste
• Assegurar o planejamento e o gerenciamento apropriados dos recursos de teste
• Avaliar o andamento e a eficácia do esforço de teste
• Defender o nível apropriado de qualidade mediante a correção de Defeitos importantes
• Defender um nível apropriado de enfoque na testabilidade durante o processo de desenvolvimento de software

Figura 7 - Gerente de Testes

Principais artefatos a serem produzidos

• Lista de problemas: A Lista de Problemas fornece ao Gerente de Projeto uma maneira de registrar e acompanhar problemas, exceções, anormalidades ou outras tarefas incompletas que requeiram atenção em termos de gerenciamento do projeto. Em geral, são itens que não estão sendo acompanhados durante o Gerenciamento de Mudança ou como tarefas no Plano de Projeto ou no Plano de Iteração, embora possam ser provenientes deles.
• Solicitação de Mudanças: As mudanças nos artefatos de desenvolvimento são propostas através de Solicitações de Mudança (CRs). As Solicitações de Mudança são usadas para documentar e controlar defeitos, solicitações de melhorias e qualquer outro tipo de solicitação de mudança no produto. A vantagem das CRs é que elas fornecem um registro das decisões e, devido a seu processo de avaliação, garantem que os impactos das mudanças sejam entendidos no projeto.

Analista de Sistemas: O papel analista de sistemas lidera e coordena a identificação de requisitos e a modelagem de casos de uso, delimitando o sistema e definindo sua funcionalidade; por exemplo, estabelecendo quais são os atores e casos de uso existentes e como eles interagem

Figura 8 - Artefatos e repositórios gerados pelo Analista de Sistemas

Principais Artefatos a serem Produzidos

• Plano de Gerenciamento de Requisitos: Descreve a documentação de requisitos, os tipos de requisitos e seus respectivos atributos de requisitos, especificando as informações e os mecanismos de controle que devem ser coletados e usados para avaliar, relatar e controlar mudanças nos requisitos do produto.
• Guia de modelagem de Casos de Uso: Descreve como modelar os casos de uso.
• Solicitação dos principais envolvidos: Este artefato contém qualquer tipo de solicitação dos principais envolvidos (cliente, usuário final, pessoal de marketing etc.) em relação ao sistema que será desenvolvido. Ele também pode conter referências a qualquer tipo de fonte externa com a qual o sistema deve estar de acordo.
• Visão: A visão que os envolvidos têm do produto a ser desenvolvido, em termos das necessidades e características mais importantes. Por conter uma descrição dos requisitos centrais pretendidos, ela proporciona a base contratual para requisitos técnicos mais detalhados.

Principais Repositórios de dados e documentos a serem utilizados pelo projeto

• Atriburtos de Requisitos: Este artefato contém um repositório de dependências, atributos e requisitos de projeto para controlar a partir de uma perspectiva de gerenciamento de requisitos.

Revisor do Modelo de Negócio: O revisor do modelo de negócios participa das revisões formais do modelo de casos de uso de negócios e do modelo de objetos de negócios.

Figura 9 - Revisor do modelo de negócio

Analista do Processo de Negócio: lidera e coordena a modelagem de casos de uso de negócios, definindo e delimitando a organização que está sendo modelada; por exemplo, estabelecendo quais são os atores de negócios e casos de uso de negócios existentes e como eles interagem.

Figura 10 - Analista do Processo de Negócio

Principais Artefatos a serem Produzidos

• Documento da Arquitetura de negócio: O Documento de Arquitetura de Negócios fornece uma visão geral abrangente do negócio, usando diversas visões arquiteturais diferentes para descrever diferentes aspectos do negócio.
• Guia de modelagem de Negócio: Descreve as diretrizes de modelagem de negócios.
• Avaliação da Organização Alvo: A Avaliação da Organização-alvo descreve o status atual da organização em que o sistema deverá ser implantado. A descrição é em termos de processos atuais, ferramentas, competências de pessoas, atitudes de pessoas, clientes, concorrentes, tendências técnicas, problemas e áreas de melhoria.

Analista de Teste: O papel Analista de Teste é responsável por inicialmente identificar e posteriormente definir os testes necessários, monitorar a abrangência dos testes e avaliar a qualidade geral obtida ao testar os Itens de Teste-alvo. Este papel também envolve a especificação dos Dados de Teste necessários e a avaliação do resultado dos testes conduzidos em cada ciclo de teste. Às vezes, este papel também é denominado Designer de Teste ou considerado parte do papel Testador. Este papel é responsável por:

• Identificar os Itens de Teste-alvo a serem avaliados pelo esforço de teste
• Definir os testes apropriados necessários e quaisquer Dados de Teste associados
• Coletar e gerenciar os Dados de Teste
• Avaliar o resultado de cada ciclo de teste

Figura 11 - Principais artefatos produzidos pelo Analista de Testes

Principais Artefatos a serem Produzidos

• Plano de Testes: A definição das metas e dos objetivos dos testes no escopo da iteração (ou projeto), os itens-alvo, a abordagem adotada, os recursos necessários e os produtos que serão liberados.
• Lista de ideias de teste: É uma lista enumerada de idéias, geralmente formada parcialmente e que identifica possíveis testes úteis a serem conduzidos.
• Caso de testes: É a definição (geralmente formal) de um conjunto específico de inputs de teste, condições de execução e resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um Item de Teste-alvo.
• Modelo de Analise de Carga de Trabalho: Modelo que identifica um ou mais perfis de carga de trabalho destinados a definir com precisão o estado de interesse de um sistema no qual a avaliação do software e/ou de seu ambiente operacional pode ser realizada. Os perfis de carga de trabalho representam possíveis condições a serem simuladas e comparadas aos Itens de Teste-alvo em uma ou mais Configurações de Ambiente de Teste.

Principais Repositórios de dados e documentos a serem utilizados pelo projeto

• Dados de Testes: A definição (geralmente formal) de um conjunto de valores de entrada de teste que são usados durante a execução de um teste, e os resultados esperados mencionados para fins de comparação durante a execução de um teste.
• Resultados de testes: Um conjunto de informações resumidas determinadas pela análise de um ou mais Registros de Teste e Solicitações de Mudança, que permitem uma avaliação relativamente detalhada da qualidade dos Itens de Teste-alvo e do status de cada esforço de teste. Muitas vezes, é também consultado como um repositório maior de vários Resultados do Teste.

3. Conclusões

A implantação do nível de maturidade CMMI nível 2, exige um time de profissionais com conhecimentos tecnicos e do negócio. Para atingir este nível de maturidade uma serie de artefatos e profissionais são necessários, sendo uma tarefa trabalhosa e que exige que o gerente de projeto mostre os resultados para a alta gerencia para justificar a implementação pois o seu retorno não e imediato.
Uma boa prática e a utilização dos artefados gerados RUP - Rational Unified Process e adapta-los ao CMMI.

Embora RUP cobre 97 por cento das exigências de CMMI para Maturidade Nível 2, e necessário utilizar práticas adicionais. Isso é porque não inclui as duas áreas ed processo do Nível 2 .

O RUP é construído em uma arquitetura extensível que lhe permite adaptar o processo a suas necessidades. Como e o caso dos niveis do CMMI, o qual podemos utilizar os artefatos do RUP
4. Referências

[1] Rational Unified Process, http://www.wthreex.com/rup/index.htm, Acessado em 06/12/2008

[2] CMMI (2008). CMMI Web Site. Disponível em http://www.sei.cmu.edu/cmmi/ . Acesso em: 07/12/08.

[3]Fernandes, Aguinaldo A.; Abreu, Vladimir F. (2008). Implantando a Governança de TI: Estratégia à Gestão dos Processos e Serviços. 2. ed – Rio de Janeiro, Brasport.

[4] A CMMI maturity Level 2 assessment of RUP, Artigo disponivel em http://www.ibm.com/developerworks/rational/library/dec05/grundmann/index.html?S_TACT=105AGX15&S_CMP=EDU

[5] Vivatanavorasin, Vivatanavorasin, A Process Model Designer And Tool Development for Supplient Agreement Management of CMMI: Capability Level 2, Computer Society, 2006

[5] Reaching CMM Levels 2and 3 with the Rational Unified Process, Rational Software White Paper, 2007

Resumo do ITIL e Principais Mudanças da V2 para V3

1. Histórico do Modelo

A ITIL (Information Technology Infrastructure Library) foi desenvolvida pelo (Central Computer and Telecommunications Agency) no final dos anos 80, a de uma encomenda do governo britânico, que não estava satisfeito com o nível de qualidade dos serviços de TI a ele prestado. Neste cenário, foi solicitado o desenvolvimento de uma abordagem de melhores práticas para gerenciar a utililização eficiente e responsável dos recursos de TI, independentemente de fornecedores e aplicável a organizações com necessidades técnicas e de negócio distintas. Em abril de 2001, o CCTA foi incorporado ao OGC47 (Office of Government Commerce) que hoje é o organismo responsável pela evolução e divulgação da ITIL.

2. Objetivos dos modelo

A ITIL é um agrupamento das melhores práticas utilizadas para o gerencia de serviços de tecnologia de informação de alta qualidade, obtidas em consenso após décadas de observação prática, pesquisa e trabalho de profissionais de TI e processamento de dados em todo o mundo. Devido à sua abrangência e profundi­dade, a ITIL tem se firmado continuamente como um padrão mundial de fato para as melhores práticas para o gerenciamento de serviços de TI.

Como um framework, o principal objetivo da ITIL é prover um conjunto de práticas de gerenciamento de serviços de TI testadas e comprovadas no mercado (organiza­das segundo uma lógica de ciclo de vida de serviços), que podem servir como bali­zadoras, tanto para organizações que já possuem operações de TI em andamento e pretendem empreender melhorias, quanto para a criação de novas operações. A adoção das práticas da ITIL pretende levar uma organização a um grau de maturi­dade e qualidade que permita o uso eficaz e eficiente dos seus ativos estratégicos de TI (incluindo sistemas de informação e infra-estrutura de TI), sempre com o foco no alinhamento e na integração com as necessidades dos clientes e usuários.

A ITIL V3 e a sua abordagem de ciclo de vida permite que se tenha uma visão do gerenciamento de serviços pela perspectiva do próprio serviço, em vez de focar em cada processo ou prática por vez. Esta característica realça mais um importante objetivo, que é mensurar e gerenciar o valor que os serviços de TI efetivamente adicionam ao negócio.

3. Visão geral do modelo

A ITIL pode ser considerada uma fonte de boas práticas utilizada pelas organiza­ções para estabelecer e melhorar suas capacitações em gerenciamento de servi­ços, e possui como componentes:

Núcleo da ITIL: Orientações de melhores práticas aplicáveis a todos os tipos de organizações que fornecem serviços para um negócio;

Orientação Complementar à ITIL: Conjunto de publicações complementares destinadas a especializar a implementação e a utilização das práticas do Núcleo para diferentes setores empresariais, tipos de empresas, plataformas tecnológi­cas etc., concebido para ser uma biblioteca dinâmica de conteúdo relacionado, podendo receber contribuições de toda a comunidade.

O Núcleo da ITIL é composto por 5 publicações (conforme mostra a Figura 1 cada uma delas se relacionada a um estágio do ciclo de vida do serviço, contendo orientações para uma abordagem integrada de gerenciamento de serviço.

Figura 1 - O nucleo da ITIL.

Estratégia de Serviço: Orienta sobre como as políticas e processos de gerenciamento de serviço podem ser desenhadas, desenvolvidas e implementada como ativos estratégicos ao longo do ciclo de vida de serviço. Entre os tópicos abordados nesta publicação estão os ativos de serviço, o catálogo de serviço o gerenciamento financeiro, o gerenciamento do portfolio de serviços, o desenvolvimento organizacional, os riscos estratégicos etc.

Desenho de Serviço: Fornece orientação para o desenho e desenvolvimentodos serviços e dos processos de gerenciamento de serviços, detalhando aspectos do gerenciamento do catálogo de serviços, do nível de serviço, da capacidade da disponibilidade, da continuidade, da segurança da informação e dos fornecedores, além de mudanças e melhorias necessárias para manter ou agregar valor aos clientes ao longo do ciclo de vida de serviço.

Transirão de Serviço: Orienta sobre como efetivar a transição de serviços novos e modificados para operações implementadas, detalhando os processos de planejamento e suporte à transição, gerenciamento de mudanças, gerenciamento de mudanças, gerenciamento da configuração e dos ativos de serviço, gerenciamento de liberação,e da distribuição, teste e validação de serviço, avaliação e gerenciamento do conhecimento.

Operação de Serviço: Descreve a fase do ciclo de vida do gerenciamento de serviços que e responsável pelas atividades do dia-a-dia, orientando sobre como garantir a entrega e o suporte a serviços de forma eficiente e eficaz, e detalhando os processos de gerenciamento de eventos, incidentes, problemas, acesso e de execução de requisições.

Melhoria de Servico Continuada: Orienta, através de princípios, práticas e métodos do gerenciamento da qualidade, sobre como fazer sistematicamente melhorias incrementais e de larga escala na qualidade dos serviços, nas metas de eficiência operacional, na continuidade dos serviços etc., com base no modelo PDCA preconizado pela ISO/IEC 20000.

Entre as extensões que a ITIL V3 traz em relação à versão anterior estão estratégias de serviços para modelos de sourcing e de compartilhamento de serviços, abordagens de retorno sobre o investimento (ROI) para serviços, práticas de desenho de serviços, um sistema de gerenciamento de conhecimento sobre os serviços e o gerenciamento de requisições.

Os processos da ITIL V3 encontram-se distribuídos entre os 5 estágios, conforme a Tabela 1 (note que todos os processos de Entrega de Serviços e Suporte a Serviços da versão anterior permanecem no modelo).

Tabela 1 - Processos e Funções do ITIL V3.

4. Diferenças entre o ITIL V2 para V3

Entre as principais mudanças do ITIL V3 esta uma mudança para um serviço de abordagem e orientação mais exigentes. O ITIL V2 delineou o que deveria ser feito para melhorar processos. Já o ITIL V3 explica claramente como é que deve ser feito.

Outro ponto chave ITIL V3 e demonstrar o retorno do investimento para os negócios. Esta foi uma dos pedidos mais freqüentes no setor de consultorias, realizadas como parte do projeto da versão 3.

4.1 Mudanças Estruturais

O ITIL V3 inclui alguma mudanças estruturais significativas. A biblioteca é composta por cinco volumes, estes são:

• Serviço de Estratégia
• Serviço de Designer
• Serviço de Transição
• Serviço de Operação
• Melhoria continua de serviço

A nova biblioteca também inclui informações mais detalhadas sobre os papeis fundamentais, e descreve a responsabilidade de cada um e acompanha com clara incidência a importância da comunicação durante o ciclo de vida. Maior ênfase na utilização de modelos e processos de identificação de todas as partes constituintes e por ultimo a Melhoria Continua de Serviço (CSI), a qual explica a utilização do processo de melhoria e identifica modelos e metricas para apoiar as melhorias.

As revisões feitas no ITIL desde a versão 1 , há duas que se destacam pela sua amplitude: a primeira deu origem à versão dois (ITIL V2) e a segunda deu origem à atual versão três (ITIL V3). A figura 2 mostra um gráfico referente as atuzalições do ITIL.

Figura 2 - Mudança de Versões

Versão 1 (1986-1999): é o ITIL original, baseado em funções de boas práticas, composto por 40 livros, de acordo com a variedade das práticas de TI.

Versão 2 (1999-2006): baseado em processos de boas práticas, é composto por 10 livros. É a versão globalmente aceita como uma estrutura de boas práticas para a gestão de serviços de TI:

• Suporte de Serviços
• Entrega de Serviços
• Planejando para a implementação da gestão de serviços
• Gestão da infra-estrutura TIC
• Perspectivas de negócio Volumes I e II
• Gestão de recursos de software
• Gestão de aplicações
• Gestão de segurança
• ITIL - implementação em pequena escala

Versão 3 (2007-~): baseado em ciclos de vida das boas práticas de serviços, incorpora o melhor do ITIL V1 e V2 e as já testadas melhores práticas para a gestão de serviços de TI. Cinco títulos de ciclo de vida formam o núcleo das práticas do ITIL:

• Estratégias de Serviços
• Desenho de Serviços
• Transição de Serviços
• Operação de Serviços
• Melhoria Contínua de Serviços

5. O esquema do ITIL V3

O núcleo é suportado por uma introdução e orientações de elementos chave, junto com orientações complementares específicas de múltiplos tópicos, e um modelo integrado do ciclo de vida do serviço, incluindo mapas do serviço, mapas organizacionais, e mapas de processos e tecnologias. Esta parte do ITIL V3 foi lançada a partir da Primavera (Européia) de 2007.

A seguir, serão adicionados mais alguns valores, como templates, casos de estudo, sumários de executivos, os quais completarão o portfólio do ITIL V3.

5.1 - O que é "ciclo de vida"

Vamos pensar no exemplo de um serviço qualquer de TI, desde a sua concepção até a sua entrega. A isto chamamos ciclo de vida de gestão do serviço. Há vários indivíduos e várias partes da organização envolvidos no ciclo de vida de um serviço, desde a fase de planejamento, desenho, construção, teste, versionamentos, operação, melhorias, etc. Diferentes níveis da organização e pessoas com papéis diferentes realizam a tomada de decisão, o desenvolvimento e a entrega dos serviços.

Vejamos um exemplo. Se estiver construindo uma casa, trabalhará com uma variedade de indivíduos nas diferentes fases da construção:

Estratégia. Planos do lugar, vendedores e marketing, aprovação da construção…
Desenho. Arquitetos, desenhistas…
Transição. Designers de interior, inspetores verificando a conformidade dos planejamentos, se as coisas estão em conformidade com o regulamento das construções e funcionarão como pretendido, etc.

Cada uma destas equipes desempenhará uma função na construção da casa em vários pontos do processo.

Uma vez construída a casa, ela precisa se manter operacional (através dos recursos tipo eletricistas, bombeiros hidráulicos e serviços como limpeza e pintura). Se a decisão for renovar ou ampliar a casa, então terá que voltar a negociar com os mesmos indivíduos (arquitetos, eletricistas, etc.), mas com vista a melhorar o desenho original e a operação da casa.

A atualização das versões do ITIL reflete a vida dos serviços e apela a um vasto espectro de pessoas que realizam os papéis nos vários estágios no ciclo de vida do serviço.

5.2 - Por que o ciclo de vida ?

Nos últimos 20 anos, a gestão dos serviços de TI mudou dramaticamente. Os conceitos anteriores de negócio e o alinhamento com a TI; a eficácia do valor corrente e os silos de processos operacionais levaram a um pensamento amadurecido sobre a realidade do estado presente da indústria de TI. Aproveitou-se o pensamento existente na V3 e transformou-se a prática anterior em orientações mais relevantes e mais fáceis de utilizar.

Pesquisas confirmaram que existem vários benefícios inerentes à adoção de uma abordagem ao ciclo de vida dos serviços:

• Estabelece a integração das estratégias do negócio com as estratégias dos serviços de TI;
• Permite um desenho detalhado do serviço e do ROI (retorno do investimento);
• Fornece modelos de transição que são desenhados com o propósito de uma variedade de inovações;
• Desmistifica a gestão dos fornecedores;
• Melhora a facilidade de implementação e a gestão de serviços dinâmicos, riscos elevados, e as necessidades de mudança rápida no negócio;
• Melhora a capacidade de medida e de demonstração de valores;
• Identifica os “gatilhos” para a melhoria e a mudança em qualquer ponto do ciclo de vida do serviço;
• Aponta as lacunas e deficiências do ITIL atual.

Foram examinados os desafios enfrentados pela gestão de serviços de TI em todos os níveis e, assim, o ITIL V3 foi desenhado tendo em vista estes desafios, de forma a conseguir as mais elevadas excelências e atender as futuras necessidades da comunidade de gestão de serviços.

5.3 - Evoluções do ITIL versão 2 para a versão 3

Há quatro evoluções importantes identificadas entre a versão 2 para a são elas:

Alinhamento -> Integração

Durante muitos anos, as organizações tem discutido formas de alinhar objetivos empresariais com a TI. Estas discussões observaram que mesmo os negocios e a TI corporativa, compartilhavam a mesma marca, de alguma maneira estavam separados em funções distintas.
A linha entre os processos empresariais e o apoio da tecnologia tem um ponto em que não ha uma necessidade de separá-los. E o caso de uma gestão financeira, apoiando os seus processos de negócio e tecnologia são tão inter-dependentes que se tornaram inseparáveis. Como resultado desta percepção crescente, o termo esta sendo substituido de alinhamento com o conceito de integração.

Alterar Valor de Gestão -> Integração Service Desk

Lendo o Itil Versão 2 você tem a impressão de que a relação de negócios e TI é sempre apoiado por um único fornecedor de serviços de TI interno, porém a relação de entre a prestação de serviços empresariais e de TI é muito mais complexa hoje do que o conceito de um único fornecedor reunindo todas as empresas e suas necessidades.
Temos que considerar que existem funções internas de TI, mas algumas são encontradas dentro de uma unidade de negócio estruturada, onde estão forncecendo um modelo de serviço compartilhados para multiplas unidades empresariais. Com isso podemos utilizar diferentes empresas tercerizadas externas ou elevar o software como um serviço, é como esta referido no ITIL 3, um valor de uma Rede Integrada de Serviços.

Linearizar Serviços de Catálogos -> Serviços de Carteiras Dinâmicas

O ITIL vem sendo referenciado como um Framework de Gerenciamento de Serviços. O principal foco até agora tem sido sobre os 10 Serviços e Apoios de processo. Em versões anteriores do ITIL, o conceito de um "serviço", estava em segundo plano.
Considerando que o ITIL versão 2 no processo de Gerenciamento de nível de Serviço tem como um dos seus muitos resultados um Catalogo de Serviços que pode ser resumido com um cadernos de serviços de TI. A Tecnologia da Informação publica seus serviços prestados com suas caractaristicas e atributos padrão ou em um Catalogo Linear de Serviços.

Processos Integrados -> Gerenciamento de Serviços de Ciclo de Vida

Baseado em informações disponíveis ao público, o ITIL V3 seus livros estão estruturados em torno do Ciclo de Vida do Serviço. Esta nova estrutura organiza os processos ja conhecidos no ITIL versão 2 com conteudo adicional. Com isso destacamos a importancia do Catalogo de Serviços e de ser um dos componentes do Gerenciamento de Nível de Serviço

5.4 - O que há de novo ?

Cada título na biblioteca atual do ITIL foi revisto e foram tomadas decisões sobre os conteúdos que necessitavam de ser trazidos para a V3. Sabe-se que uma grande parte das bibliotecas atuais do ITIL ainda está em uso, ainda são extremamente relevantes e de grande valor e, por isso mesmo, era necessário incluí-las como parte do novo ITIL, desde que permaneçam as melhores práticas globalmente adotadas pela gestão de serviços de TI. Portanto, a este respeito, nada mudou. O ITIL que se usa hoje será parte da V3 amanhã e acompanhará sempre as práticas de gestão de serviços de TI.

O ITIL V3 mostra-se completamente diferente da V2. A seguir enumeramos alguns aspectos básicos que tornam diferente o ITIL V3.

O método do desenvolvimento - foram examinadas minuciosamente várias opiniões em todo o planeta e muitos especialistas fizeram parte da equipe de desenvolvimento da V3. Estas opiniões formaram uma base sólida para os elementos chave do sucesso da V3.

O papel desempenhado pela comunidade de ITSM na V3 - em vez de convidar alguns peritos chave e alguns revisores, foram convidados membros da comunidade para estar ao lado das pessoas e terem um papel ativo no desenvolvimento da V3. O grupo consultivo do ITIL incluiu os mentores, os peritos da matéria, os revisores e os embaixadores do ITIL V3 em quase todo o projeto. Assim, a V3 é inteiramente uma prática desenvolvida por uma comunidade.

Seria preciso um livro para descrever todo o “tudo” que é novo sobre o ITIL V3, mas não há dúvida que o ITIL ruma para um futuro com serviços e produtos inovadores e estimulantes.

O ITIL V3 é parte de um processo para realçar e aperfeiçoar as melhores práticas do ITIL. Ajuda aos fornecedores de serviços a continuarem competitivos e eficazes no fornecimento de valores aos seus clientes. Uma parcela significativa do conteúdo do ITIL V2 é aperfeiçoada e incluída no ITIL V3. A estrutura e os conteúdos do ITIL V3 são baseados em consultas públicas extensivas, contribuições de líderes industriais e partes do ITIL V2 que são ainda extensivamente praticadas e usadas pela comunidade ITSM.

5.5 - Por que a atualização do ITIL ?

A versão dois foi desenvolvida nos anos 90. Desde essa altura, a TI amadureceu a um ritmo elevado, e com os novos modelos de negócio e o desenvolvimento das tecnologias, o que se dizia que eram as melhores práticas, provavelmente agora será “boas práticas”. Com isso, houve a necessidade de atualizar o ITIL, de forma a assegurar que ele vá de encontro às necessidades das comunidades de hoje.

Os processos com que as organizações estão trabalhando atualmente continuarão a fazer parte do novo ITIL. No entanto, os processos de entrega de serviços e suporte a serviços estão integrados num só ciclo de vida de serviços. Isto reflete melhor como a gestão de serviços é aplicada e assim a sua implementação torna-se mais fácil.

Como já se disse anteriormente, uma percentagem significativa do ITIL V2 foi revista e incluída no ITIL V3. Esta percentagem inclui as partes do ITIL que estão sendo amplamente praticadas e utilizadas pela comunidade de gestão de serviços. Existem áreas chave dentro dos processos de entrega de serviços e de suporte a serviços que são diferentes na V3, às quais se deve estar atento ao longo da implementação e transição para a V3.

5.6 - As Ferramentas

Os principais elementos funcionais das ferramentas de gestão de serviços continuarão a ser necessários para a V3, uma vez que os principais elementos dos processos da V2 permanecem. O que se espera, no entanto, é que os fornecedores venham a fazer novos ajustes nas suas ferramentas para poderem aproveitar o poder adicional das novas funções que a V3 introduz.

Pode-se continuar a usar as ferramentas e as práticas baseadas na V2 até se estar preparado para adotar melhorias, ou até se pretender adotar essas melhorias. Naturalmente, a V3 irá seduzir com as novas oportunidades para melhorar as suas práticas de gestão de serviços, mas é aconselhável ser diligente e certificar-se de que esta transição ocorra com facilidade e com tempo.

6. Conclusão

O Gerenciamento de Serviços de Tecnologia da Informação é o instrumento pelo qual a área pode iniciar a ação de uma postura próativa em relação ao entendimento das necessidades da organização, contribuindo para evidenciar a sua participação na geração de valor. O Gerenciamento de Serviços de TI visa alocar adequadamente os recursos disponíveis e gerenciá-los de forma integrada fazendo com que a qualidade do conjunto seja percebida pelos seus clientes e usuários, evitando a ocorrencia de problemas na entrega e na operação dos serviços de Tecnologia da Informação. Para alcançar este objetivo a tatica que vem sendo adotada e o desenho, a implementação e o gerenciamento de processos internos na área de TI de acordo com as práticas reunidas no modelo ITIL.

A ITIL prove um conjunto consistente de melhores práticas para a identificação de projetos na área de TI e o alinhamento dos seus serviços as necessidades da organização promovendo uma abordagem qualitativa para o uso econômico efetivo, eficaz e eficiente da infra-estrutura de TI objetivando obter vantagens para a organização tanto em termo de redução de custos quanto ao incremento da capacidade da organização de gerar receita, permitindo que a área concentre seus esforços em novos projetos.

7. Referências

Magalhães, Ivan Luizio, Gerenciamento de Serviços de TI na Prática, Uma abordagem com base na ITIL, São Paulo, Novatec, 2007

Fernandes, Aguinaldo A.; Abreu, Vladimir F. (2008). Implantando a Governança de TI: Estratégia à Gestão dos Processos e Serviços. 2. ed – Rio de Janeiro, Brasport.

Gartner (2008). Gartner Consulting. Disponível em http://www.gartner.com/ . Acesso em: 20 out. 2008, 17:00:00.

ITIL V.3 (2008). Página oficial do ITIL no site do OGC - Office of Government Commerce. Disponível em http://www.itil.co.uk . Acesso em: 20 out. 2008, 17:00:00.

Case Konica Minolta Business Solutions U.S.A. Inc.: Portfólio de serviços e Catálogo de Serviços de TI

1. Introdução

Segundo Nelson (2006), um interessante fenômeno acontece em escritório de automação industrial. Está ficando mais difícil diferenciar um dispositivo fabricado a partir de outra empresa em termos de tecnologia, desempenho e preço. A verdadeira guerra para a diferenciação é uma vantagem competitiva combatido em duas frentes: solução de venda e serviço ao cliente.

O catalogo de serviço é um portifolio de serviço e tem uma definição dos ativos do cliente (necessidades) e os recursos que estão sendo utilizados. A idéia e que este catalogo funcione como um comercio eletrônico, o qual encontramos os ativos (necessidades) do cliente que gerencia e organiza.

O gerenciamento de portifolio de serviços é um metodo que visa governar os investimentos em gerenciamento de serviços através da empresa e gerenciá-los para que adicionem valor ao negócio. Este processo estabelece que há duas categorias: os serviços de negócio (definidos pelo próprio negócio) e os serviços de TI (fornecidos pela TI ao negócio, mas que este não reconhece como dentro de seus dominios). Embora a linha entre esses dois portifólios de serviços seja tênue, ambos podem ser gerenciados individualmente (dependendo da perpectiva de cada cliente , mas sempre considerando relações existentes entre eles.

Serviços da área de TI:

Soluções completas em imagens para negócio, impressão e de produtos industriais que incluem:

• Análise de fluxo de trabalho (Como é realizado o trabalho no cliente e na empresa)
  
• Hardware ( impressoras, scanners entre outros)
• Software (suporte e desenvolvimento)
• Customização (Prover soluções de acordo com as necessidades dos clientes)
  
• Integração (Integração de Sistemas legados com novos sistemas da empresa )
• Treinamento (Capacitação de usuários para utilização do sistema)
• Apoio Técnico Permanente(Fornecer suporte técnico ao usuário no local ou via wireless)
• Portal de Serviços (Os clientes poderão acessar serviços disponiveis via web através do portal)
  

Clientes:

Empresas interessadas em adquirir sofisticadas impressoras, copiadoras, multifuncionais e periféricos.

Valores desejados pelos clientes:

• Atendimento rápido
• Eficiência no serviço
• Baixo custo
• Qualidade no serviço

A figura 1 mostra o portifolio de serviços da empresa Konica

Figura 1: Portifolio de Serviços da Empresa Konica

Níveis de Serviços:

Os níveis de serviço identificados são:

• Atendimento às solicitações de suporte dentro dos tempos padrões;
• Tempo de reparo
• Tempo médio de reparo por tipo de falha
  
• Atendimento aos prazos e custos dos projetos dentro do orçamento da empresa;
• Índice de satisfação dos clientes dos serviços de suporte;
• Qualidade e produtividade do suporte do suporte;
• Treinamento técnico fornecidos.
• Qualidade no gerenciamento do inventário

Custos e Modelos de Cobrança

Obteve mais conhecimentos e controle sobre a força de trabalho móvel para obter melhor tratar os custos. Melhoram a maneira de acompanhar inventários capturarando dados mais precisos de inventário e evitou erros na encomenda de peças. O sistema antigo exigia dos técnicos injserir manualmente o números das peças, o que acarretava uma demorada e gerava erros no processo. Além disso, como part number mudava ao longo do tempo, era difícil assegurar se as peças eram encomendadas em tempo oportuno.
O novo sistema, AirClic MP, permite capturar informações como horários de viagens de trabalho e as peças usadas durante a chamada. Ela inclui a Motorola AC 25 bar-code-scanning-sistema desenvolvido pela AirClic-o que reduziu significativamente o tempo de rastreamento do inventário.

Bibliografia

Lin, Nelson (2006). Best Practices: Konica Minolta's Mobile Image. Disponível em http://www.informationweek.com/news/showArticle.jhtml?articleID=193403033 . Acesso em: 13 set. 2008, 17:00:00.

ITIL V.3 (2008). Página oficial do ITIL no site do OGC - Office of Government Commerce. Disponível em http://www.itil.co.uk . Acesso em: 13 set. 2008, 17:00:00.

Trabalho do 1º Bimestre de 2008

ITA- INSTITUTO TECNOLÓGICO DE AERONÁUTICA

IEC - DIVISÃO DE CIÊNCIA DA COMPUTAÇÃO

CE-283 GOVERNANÇA DE TECNOLOGIA DE INFORMAÇÃO

Prof. Dr. Edgar Toshiro Yano

1° semestre/2008





Trabalho de BSC Estratégico e o BSC de TI
da Empresa 7-ELEVEN Japan.

Alunos: Alexandre Lopes Machado alexlm@terra.com.br
Fretz Sievers Junior fretz@uol.com.br

Setembro 2008

1- Objetivos do modelo

O Balanced Scorecard é um sistema de gestão estratégica que tem por objetivos (Fernandes; Abreu, 2008):

• Traduzir a estratégia da empresa em termos operacionais;
• Alinhar a organização à estratégia;
• Transformar a estratégia em tarefas de todos;
• Converter a estratégia em processo contínuo; e
• Mobilizar a mudança por meio da liderança executiva.

2- Estrutura do modelo

Esta abordagem de gestão estratégica foi desenvolvida porque até então todas as medidas de desempenho das empresas eram financeiras. De acordo (Kaplan; Norton, 1996), o resultado financeiro é resultado de outros fatores ou perspectivas:

• Clientes;
• Processos internos;
• Aprendizado e crescimento.

O BSC é fundamentado nessas quatro perspectivas e determina uma relação de causa e efeito, assim como relaciona objetivos com medições, metas e iniciativas, que são os projetos e serviços que devem ser implantados para o atendimento aos objetivos e metas .

O BSC é um instrumento que auxilia o alinhamento de todas as iniciativas de todos os níveis da empresa com os objetivos e estratégias do negócio.

As etapas para se construir um BSC são:

• Estabelecer a visão da empresa sobre o futuro que ela deseja atingir;
• Perspectivas: a visão é decomposta nas perspectivas financeira, de cliente, de processos internos e de aprendizado e crescimento ou outras, a critério da empresa;
• Objetivos estratégicos; a visão é expressa em objetivos estratégicos que, uma vez atingidos, permitem a empresa chegar ao futuro desejado (são estabelecidos objetivos estratégicos para cada perspectiva estabelecida);
• Determinação das medições estratégicas: definir tanto os indicadores de resultado (lagging indicators) como os indicadores de desempenho (performance indicators) para cada objetivo estratégico, considerando cada uma das perspectivas;
• Determinar relações de causa e efeito, descrevendo como os objetivos se relacionam entre si;
• Estabelecer o scorecard, representação dos objetivos por perspectiva e pelas relações de causa e efeito;
• Desdobrar o scorecard, relacionando-o às unidades organizacionais da empresa, até o nível mais baixo;
• Determinar metas quantitativas para cada um dos indicadores de resultado e de desempenho;
• Determinar as iniciativas: projetos, ações e serviços que possibilitarão a realização dos objetivos estratégicos (na realidade, são planos de ação);
• Implantar o BSC: comunicar e disseminar por toda a organização;
• Manter o esforço: manter e evoluir continuamente o sistema de gestão estratégica.

A perspectiva financeira descreve os resultados esperados da estratégia em termos financeiros tradicionais.

A perspectiva do cliente descreve a proposição de valor para o cliente.

A perspectiva dos processos internos identifica os processos críticos para geração de valor para o cliente.

A perspectiva de aprendizado e crescimento identifica os ativos intangíveis que são críticos para os processos internos e para a geração de valor para o cliente.

3- Mapas Estratégicos

O Mapa Estratégico é uma representação visual das relações de causa e efeito entre os objetivos estratégicos, nas quatro perspectivas estratégicas compreendidas pelo BSC.

De acordo (Kaplan; Norton, 1996), o Mapa Estratégico representa como a empresa cria valor e é considerado o “elo perdido” entre a formulação da estratégia e a sua execução. O Mapa Estratégico dirige o BSC e, por conseqüência, as iniciativas e os investimentos necessário

4- Aplicabilidade do modelo

O Mapa Estratégico e o Balanced Scorecard constituem-se numa poderosa ferramenta para realizar o alinhamento da TI ao negócio, assim como para desdobrar os objetivos estratégicos de TI em iniciativas que contribuam para o atendimento aos objetivos.

As iniciativas ou projetos a serem implantados podem estar refletidos no Portfolio de TI. Em TI, o BSC deve ser usado durante o planejamento de TI, assim como na gestão do dia-a-dia da realização da estratégia de TI.

5- Case Seven Eleven Japan

Neste trabalho, foi utilizado a descrição do Case Seven Eleven Japan (Nagayama; Weill 2004) para elaborar um modelo de BSC de negócio e um modelo de BSC para a área de TI desta empresa. A Figura 1.0 ilustra o mapa estratégico e o BSC de negócio. A Figura 2.0 ilustra o mapa estratégico e o BSC para a área de TI.

Figura 1 - Modelo de BSC de Negócio da Seven Eleven Japan

Figura 2 - Modelo de BSC de TI da Seven Eleven Japan

6- Vantagens e desvantagens do BSC.

De acordo com os resultados obtidos com a elaboração do BSC de negócio e para a área de TI da Seven Eleven Japan, as seguintes vantagens de utilização da metodologia foram encontradas:

• Alinhamento da organização à estratégia;
• Busca de sinergia organizacional;
• Construção de um sistema de gestão da estratégia;
• Vinculação da estratégia com planejamento e orçamento;
• Definição de metas estratégicas;
• Priorização de iniciativas estratégicas;
• Alinhamento dos indivíduos da organização à estratégia.

As seguintes desvantagens foram encontradas;

• Dificuldade intrínseca na medição dos benefícios quantitativos na adoção do BSC, pois o resultado de uma empresa está condicionado a muitas variáveis que não estão sob o seu controle;
• Se a empresa não optar pelas estratégias corretas, é muito provável que, a despeito do uso de modernas tecnologias de gestão,seu desempenho não seja satisfatório.

Segundo (Fernandes; Abreu, 2008), na área de TI, já existem aplicações do BSC, por força de sua adoção pela empresa com um todo. Entretanto, ainda há poucas informações sobre os resultados de sua aplicação.

7. Bibliografia

Fernandes, Aguinaldo A.; Abreu, Vladimir F. (2008). Implantando a Governança de TI: Estratégia à Gestão dos Processos e Serviços. 2. ed – Rio de Janeiro, Brasport.

Kaplan, Robert S.; Norton, David P. (1996). The Balanced Scorecard: translating strategy into action. Boston, Harvard Business School Press.

Nagayama, Kei; Weill, Peter. (2004). 7-Eleven Japan co., Ltd: Reinventing the Retail Business Model. Disponível em web.mit.edu/cisr/working%20papers/cisrwp351.pdf. Acesso em: 24 set. 2008.

Mapeamento entre os Processos do Cobit 4.1 com as Capacidades Essenciais de Feeney e Willcocks.

Capacidades Essenciais de Feeney e Willcocks.

As capacidades essenciais foram retiradas do artigo Core IS Capabilities for Exploiting Information Technology, de FEENY e WILLCOCKS (1998) os quais segundo o artigo identificam 9 competências essenciais da área de tecnologia da informação que não devem ser tercerizadas, e que as outras podem ser ou não delegadas a fornecedores externos. As nove competências essenciais citadas pelo artigo são:

1. Liderança: Os líderes eficazes de SI/TI criam as ferramentas organizacionais –estruturas, processos, recursos humanos– para enfrentar cada desafio de integrar as iniciativas nas áreas de SI/TI com os objetivos e as atividades empresariais e administrar as interdependências entre as várias áreas. Eles estabelecem metas e direção para cada área e também influenciam a percepção geral da empresa do papel da tecnologia da informação e sua contribuição.Esses líderes cultivam relacionamentos duradouros entre a área de TI e o restante da empresa para ter uma visão comum da tecnologia da informação. Determinam os valores e a cultura da função de SI e semeiam a crença de que a primeira obrigação do pessoal de SI é contribuir para a execução das soluções empresariais.A liderança, naturalmente, é papel tradicional do CIO (chief information officer) ou do diretor de informática (também chamado de diretor de tecnologia da informação) –apesar de o futuro desse papel ser questionado algumas vezes. Nossa própria experiência constantemente reforça o ponto de vista de que o CIO é pessoalmente relevante para a exploração organizacional da tecnologia da informação.

2. Raciocínio baseado nos sistemas empresariais: Trata-se da capacidade de projetar os processos empresariais que a tecnologia tornará possíveis. Muitos executivos das companhias estudada na pesquisa do artigo, preocupados com a falta de progressos na integração entre o desenvolvimento da empresa e a capacidade da tecnologia da informação.

3. Criação de Relacionamentos: A criação é o envolvimento construtivo da empresa nas questões de SI/TI. Ela facilita um diálogo mais amplo entre a empresa e a comunidade de SI. Especificamente, a criação de relacionamentos faz o usuário compreender o potencial da tecnologia da informação, ajudando-o a trabalhar junto com os especialistas de TI e garantindo o sentimento de posse e a satisfação.

4. Planejamento da Arquitetura de Sistemas: Trata-se da elaboração de um plano coerente para a plataforma técnica que corresponda às necessidades atuais e futuras da empresa. A necessidade de planejamento da arquitetura e o desafio de sua supuseram que não; segundo elas, a missão do planejamento da arquitetura caberia a fornecedores externos.

5. Por a Tecnologia para Funcionar: Essa é a competência de conseguir progresso tecnológico rapidamente, por qualquer meio que seja. Requer do técnico incumbido de fazer os “consertos” a intuição de um planejador da arquitetura e mais pragmatismo de curto prazo.

6. Compras Esclarecidas: Trata-se da gestão de uma estratégia de compra de SI/TI que atenda aos interesses da companhia. Cabe a um departamento de compras esclarecido, capaz de analisar o mercado externo de serviços de SI/TI, escolher uma estratégia de compras que atenda às necessidades da empresa e às questões ligadas à tecnologia e coordene o processo de tomada de preços, concorrência, contratação e gerenciamento dos serviços.

7. Facilitação de Contratos: Essa é a competência que garante o sucesso dos contratos de prestação de serviços de SI/TI existentes. Os acordos de prestação de serviços de SI são complexos. Em geral, vários usuários da empresa têm serviços diversos provenientes de fornecedores múltiplos (externos e internos), segundo acordos de prestação de serviços detalhados e longos. A facilitação dos contratos deve proporcionar um único ponto de contato pelo qual o usuário pode ter certeza de que os problemas e conflitos serão solucionados prontamente e com justiça no âmbito dos acordos e dos relacionamentos. Essa capacidade é voltada para a ação. Se os acordos de prestação de serviços e os fornecedores fossem perfeitos, a facilitação dos contratos não seria uma competência essencial do SI. Uma das pessoas entrevistadas observou: “Os usuários sofreram algumas vezes quando precisaram lidar diretamente com os fornecedores; esse é um serviço que podemos prestar e agora decidimos fazer isso”. De modo geral, o facilitador de contratos é um coordenador apreciado tanto por usuários quanto por fornecedores.

8. Monitoramento de Contratos: Trata-se da proteção da posição contratual da empresa de hoje e de amanhã. À medida que as organizações exploram o florescente mercado externo de serviços de SI, o monitoramento dos contratos passa a ser uma competência essencial do SI.

9. Desenvolvimento de Fornecedores: Essa é a capacidade de identificar o possível valor agregado por Fornecedores de serviços de SI/TI, muito importante, já que o aspecto mais ameaçador da terceirização das funções de SI/TI é o custo substancial da mudança. Em um dos casos apurados no artigo, por exemplo, foram necessários mais de 50 homens/ano para chegar a um contrato com duração de dez anos e no valor de aproximadamente US$ 700 milhões e, depois, foi preciso cobrir os custos consideráveis dos requisitos de implementação. Se mais tarde essa empresa tivesse de mudar de fornecedor, o esforço exigido poderia ser igual ao empreendido na mudança inicial. Por isso, a companhia precisa maximizar a contribuição dos fornecedores atuais (o valor que agregam). Além disso, ao fazer a terceirização ela deve se proteger contra o que denominamos “desânimo de meio de contrato”. O fornecedor pode até estar cumprindo o contrato depois de dois anos ou mais, mas sem fazer com que o valor agregado prometido se materialize. O gerente de contratos de um grande banco pesquisado comentou, depois que sua empresa consolidou e terceirizou seus centros de processamento de dados: “Claro, os fornecedores cumprem o contrato, mas cumprem o que está escrito e não o que foi combinado inicialmente. Eles não pensam em agregar valor”. Com a competência de desenvolver fornecedores, as empresas devem ir além das cláusulas escritas nos contratos para explorar o potencial de longo prazo dos fornecedores. Uma grande empresa varejista pesquisada adotou várias formas de fazer isso, inclusive uma reunião anual formal.

Cobit 4.1

O COBIT é um framework que fornece as melhores práticas para o gerenciamento de processos de TI, estruturados de uma forma gerenciável e lógica, atendendo as várias necessidades de gestão da organização, tratando os riscos de negócio, questões técnicas, necessidades de controle e métricas de desempenho. O COBIT não é um padrão definitivo, ele serve como apoio para a implementação de controles na Governança de TI.

Este framework fornece um modelo padrão de referência e uma linguagem comum, permitindo que todos em uma organização sejam capazes de distinguir e gerenciar atividades no âmbito da TI. Neste sentido, utilizando como matriz o ciclo tradicional de melhoria continua (planejar, construir, executar, monitorar), o Cobit identificou 34 processos de TI e os distribuiu em 4 domínios que os espelham os agrupamentos usuais existentes em uma organização de TI. A figura 1.0 ilustra a interação entre estes domínios na estrutura do COBIT e seus processos.

Figura 1 – Domínio do Cobit no Framework.

Planejamento e Organização (PO): este domínio tem abrangência estratégica e tática e identifica as formas através das quais a TI pode contribuir melhor para o atendimento dos objetivos do negócio, envolvendo planejamento, comunicação, gerenciamento em diversas perpectivas.

Aquisição e Implementação (AI): Este domínio cobre a identificação, desenvolvimento e/ou aquisição de soluções de TI para executar a estratégia de TI estabelecida, assim como sua implementação e integração junto aos processos de negócio. Mudanças e manutenções em sistemas existentes também estão cobertas por este domínio, para garantir a continuidade dos respectivos ciclos de vida.

Entrega e Suporte (DS): Este domínio cobre a entrega propriamente dita dos serviços requeridos, incluindo gerenciamento de segurança e continuidade, suporte aos serviços para os usuários, gestão dos dados e a infra-estrutura operacional.

Monitoração e Avaliação (ME): Este domínio visa assegurar a qualidade dos processos de TI, assim como a sua governança e conformidade com os objetivos de controle, através de mecanismos regulares de acompanhamento, monitoração de controles internos e de avaliações internas e externas.

Os aspectos analisados são demonstrados na tabela 1, relacionando o enquadramento das 9 capacidades essenciais com os processos do padrão COBIT.

Tabela 1 – Relação das Competências Essenciais e o padrão COBIT

Referencias

[1] Feeny, David F., Willcoks, Leslie P., Core IS Capabilities for Exploiting Information Technology, Massachusetts Institute of Technology, Volume 39, Number 3, 1998.
[2] Cobit 4.1, Governance Institute, 2007.