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.

Operações e Liderança

Operações e Liderança

O artigo fala sobre as experiências de operação e liderança do General Peter Schoomaker, 53, Comandante do Comando de Operações Especiais norte-americano, o qual vê um mundo novo de crise e conflitos as quais exigem que os militares do grupo de Special Operations Forces (SOF) tenham um novo papel sendo diplomatas de conflitos. Ele crítica o modelo tradicional que unidades militares tem provável sucesso no campo quando segue rigidamente procedimentos de comando e controle e seguem um sistema hierárquico rígido de pirâmide seguindo ordens do topo da pirâmide até sua base rígido de baixo para cima. Ele acredita que esse modelo e antiquado, inexato e perigoso para a liderança. Ele acredita que as guerras do futuro serão ganhas por exércitos que empreenderão em campanhas prósperas ou um Marechal de soluções criativas em circunstâncias ambíguas.

Schoomaker entende os desafios das mudanças e as demandas de adaptabilidade para um novo mundo. “Com o colapso da União Soviética veio uma necessidade para SOF de reavaliar o seu papel e reinventar, pois o futuro aguarda menos guerras e muito mais conflitos” , há necessidade de um militar prosperar em incertezas. Alinhado com a missão da organização que é “apoiar os EUA em grandes conflitos antes de começar e mantendo também habilidade de transição a combater operações e, se necessário, encabeçar uma vitória decisiva".

Para fundamentar a sua visão Schoomaker, da exemplos de como a missão que a SOF recebeu em 1991. A missão abrangia soldados treinados que eram derrubados em acampamento de refugiados curdos ao longo da borda Iraquiano-Turca. Os refugiados tinham fugidos de suas casas depois de uma rebelião mau sucedida contra Sadam Husseim, os quais passavam situação de frio, fome e até casos de chegar a falecer.

Quando as tropas do SOF chegaram ao local, uma revolta começou ao redor de uma escolta por causa de comida, mas o Capitão da unidade Steve Damon,32 reuniu um grupo de 12 pessoas e foi fazer uma avaliação do local. Para Damon era a primeira experiência com um acampamento de refugiados e afirmou que não sabia o que estava fazendo mas sabia que teria que fazer algo. Ao entrar no acampamento foram recebidos por lutadores curdos bravos, era tantas pessoas que poderia ser feita uma analogia como um tapete de pessoas.

A equipe do SOF teve que manter a calma e entender como resolver a situação e desenvolver um remédio construtivo para os problemas dos refugiados. O SOF escutou os problemas e reclamações sobre o lugar e dentro de um dia conseguiram listar problemas específicos e sugerir soluções particulares, e logo após recrutado lutadores curdos para ajudar a distribuir comida. E dentro de alguns dias, o grupo tinha montado um oleoduto para levar água potável. Durante 3 meses os refugiados puderam voltar para a casa. O SOF que incluía 70 pessoas conseguiu administrar uma cidade de 150.000 no processo e salvou milhares de vidas. Neste exemplo podemos ver a liderança do grupo SOF em administrar problemas ainda não vividos pelo grupo. Outro exemplo citado pelo autor e a crise na Bósnia, em clarear as minas na Namíbia e participar em exercícios de treinamento e uma situação vivida na Somália para montar um programa de treinamento.A seguir são apresentados os princípios e práticas de Schoomaker e outros líderes do SOF, que podem operar em todos os níveis de uma organização:

1. Membros devem saber sua missão e ter uma identidade: os membros devem ter suas habilidades únicas combinadas com capacidades de comunicação, cultura, habilidades de negociação, de resolver problemas, ser criativos para proceder em situações difíceis.;

2. Selecionar pessoas corretas e construir o melhor time: nunca confunda entusiasmo com capacidade. Sempre cumprir suas metas;

3. Para ser um líder, demonstre liderança: Liderança significa selecionar pessoas que façam com que outras pessoas façam o que por si só não fariam;

4. Ensine para as pessoas “Como pensar” e não “O que pensar”: As pessoas devem desenvolver e internalizar habilidades para resolver problemas em diferentes situações sem utilizar checklist;

5. Mantenha valores centrais: Todos devem saber quais são os recursos de determinadas ferramentas de uma organização, utilizando criatividade e ver várias maneiras de se utilizar uma mesma ferramenta em diferentes situações;

6. Aprenda com os erros: os erros cometidos durantes às operações deve ser revistos para que não sejam cometidos novamente;

7. Transforme todos em professores: Devemos treinar os lideres não somente em um nível de hierarquia mas dois níveis abaixo, para que na falta de um outros lideres assumam.

Bibliografia

COHEN E., TICHY N. Operation – Leadership, 1999. Disponível em http://www.fastcompany.com/node/37511/print . Acesso em: 09 ago. 2008, 20:00:00.